Re: Move to new hardware and upgrade o/s
- From: Martin Berger <martin.a.berger@xxxxxxxxx>
- To: k3nnyp@xxxxxxxxx
- Date: Fri, 13 Jun 2014 21:37:57 +0200
In case you even want to scope with the time DNS needs to synchronize you
can
* make sure local_listener of the new DB points to the IP of your local
listeners
* add the IP(s) of the old listeners to remote_listener of the new DB
* of course ensure the same service names are used
* beware of all additional features/limitations after COST was discovered/
implemented (
https://blogs.oracle.com/security/entry/security_alert_for_cve_2012 )
by these steps the new instances register (also) to the old listeners
(which are still accessed by "old" DNS entries) - but those redirect the
client to the new IPs.
maybe this helps,
Martin
On Fri, Jun 6, 2014 at 8:55 PM, Kenny Payton <k3nnyp@xxxxxxxxx> wrote:
> You could consider creating a VIP for your databases so in the future you
> can move them without affecting DNS or firewall rules. We do this for
> each database so we can also stagger database moves separately if needed.
> Additionally we create binaries per database with separate inventories on
> SAN storage. Changing hosts requires moving storage, mounting the
> binaries and bringing the VIP up on the new machine after shutting it down
> on the old.
>
> Kenny
> On Jun 6, 2014 1:25 PM, "Kumar Madduri" <ksmadduri@xxxxxxxxx> wrote:
>
>> I am working on moving the current boxes to new ones and upgrade to
>> 11.2.0.4
>> The original idea was to do this.
>> Install software and move the databases one by one. Create new firewall
>> rules for this because host name and ip change.
>>
>> But another thing came to mind since we have firewalls and I would have
>> to redefine new firewall rules
>>
>> 1. Get new box with new hostname.
>> 2. Install 11.2.0.4 Grid, 11.2.0.2 rdbms, 11.2.0.4 rdbms.
>> 3. All our development, int environments are on NAS. So the same storage
>> can be mounted on new boxes
>> 4. When ready to cut over, shutdown old development box; bring up new
>> box; re-ip the new box to have same ip address as old box (still keep the
>> new host name. Just change ip address to old one).
>> 5. Tell asm on new box about the new databases (alter system set
>> asm_diskstring =''''').
>> 6. Bring up the databases
>> 7. Do the upgrade when developers are ok (one by one since we have more
>> than one database on the same box in dev and int)
>> The advantange in this method is
>> 1. We move all databases in one shot from old to new.
>> 2. We can upgrade to 11.2.0.4 one after other
>> 3. Most important, I think is we dont have to worry about firewall rules
>> because we are getting same ip address back.
>>
>> The one issue I think in this approach is
>> Since we use oracle apps, fnd_nodes would not be updated with the new
>> database server name till we run autoconfig again (thiss would be done as
>> part of 11.2.0.4 upgrade). Till then the topology would be out of sync. But
>> we have not really enabled 'autoconfig' on our database server. So even
>> though topology would be out of sync (temporarily),l am thinking we would
>> be ok since tnsnames would be updated manually for those environments that
>> are not upgraded.
>>
>> Do you see any issues or is there a better way to accomplish the same ?
>> The reason I think about this approach is I wanted to avoid redefining all
>> the firewall rules if I can (with change in IP) and I can decommision the
>> old box relatively earlier once I am done with the move and it is stable
>> for couple of weeks.
>>
>>
Other related posts:
