FAQ
Let me try this again.
I am working on upgrading our Linux servers running Oracle database to a newer generation with faster CPUs and more RAM. I just wanted to share my plan to the list and see if there are any holes or gotchas that I have missed.

Setup:

Current servers:
64 bit AMD architecture
Oracle Linux 5.6
Mix of 10.2.0.4 and 11.2.0.3
Data/Oracle Home stored on LUNs from EMC SAN

New servers:
64 bit Intel architecture
Oracle Linux 5.6
Same database versions
Use same LUNs moved to this new server

Plan:
Pre go-live
1. Install Oracle Linux 5.6 on new servers with temporary hostnames
2. Copy critical OS config files or match the Oracle OS requirements
3. Do a fresh Oracle Home installs (I believe this would be the recommended way if not mandatory when changing CPU architecture?)
4. Copy all individual database config files, *.ora files, etc.
5. Prep the new servers for RMAN backups, scripts

Go live day
6. Shutdown databases on old servers
7. Unmount LUNs from old server
8. Shutdown old servers
9. Do the EMC magic to attach the LUNs to new hosts
10. Change the hostname on new server to production hosts
11. Mount LUNS on new server verifying the LUN-mount point matches old environment
12. Fire up the databases and the listener
13. Enjoy a cold one
I have just listed the core database move steps and of course there will be lot more prep work to get the scripts, cron jobs and scheduled processes moved over. I would love to hear from anyone else who has done a similar task or if you have any inputs.

Thanks in advance,
Karthik
Senior Oracle DBA

Search Discussions

  • Rich Jesse at Oct 5, 2012 at 1:15 pm

    Karthik writes:

    Let me try this again.
    Glad to see you got it! :)
    Current servers:
    64 bit AMD architecture

    New servers:
    64 bit Intel architecture

    Plan:
    Pre go-live
    1. Install Oracle Linux 5.6 on new servers with temporary hostnames
    2. Copy critical OS config files or match the Oracle OS requirements
    3. Do a fresh Oracle Home installs (I believe this would be the
    recommended way if not mandatory when changing CPU architecture?)
    For your purposes, AMD = Intel. A fresh install may not be necessary, but
    as long as you have the time, it should be fine, as the linking will catch
    differences in OS libraries, if there are any. Make sure that you have the
    same Oracle options installed! Use the installer on each server to compare,
    either side-by-side or output to a file for comparison.
    13. Enjoy a cold one
    My favorite step!

    GL!

    Rich
  • Ramadoss, Karthik at Oct 5, 2012 at 1:31 pm
    Thanks for your input. I think it works better for me to skip the fresh installs if it's not required when switching from AMD to Intel CPUs. This is because my Oracle Homes in the current servers are on EMC LUNS as well and can be easily moved over.

    May be I will add a step to relink the Oracle Homes in the new server before starting up the databases.

    -----Original Message-----
    From: oracle-l-bounce@freelists.org On Behalf Of Rich Jesse
    Sent: Friday, October 05, 2012 9:15 AM
    To: oracle-l@freelists.org
    Subject: Re: 3rd try: Linux database server upgrade (hardware only)

    Karthik writes:
    Let me try this again.
    Glad to see you got it! :)
    Current servers:
    64 bit AMD architecture

    New servers:
    64 bit Intel architecture

    Plan:
    Pre go-live
    1. Install Oracle Linux 5.6 on new servers with temporary hostnames
    2. Copy critical OS config files or match the Oracle OS requirements
    3. Do a fresh Oracle Home installs (I believe this would be the
    recommended way if not mandatory when changing CPU architecture?)
    For your purposes, AMD = Intel. A fresh install may not be necessary, but as long as you have the time, it should be fine, as the linking will catch differences in OS libraries, if there are any. Make sure that you have the same Oracle options installed! Use the installer on each server to compare, either side-by-side or output to a file for comparison.
    13. Enjoy a cold one
    My favorite step!

    GL!

    Rich
  • Niall Litchfield at Oct 5, 2012 at 2:37 pm
    Not being flippant this time.
    You'll want to consider how you handle the Oracle inventory, oratab and
    root.sh. It sounds likely that all of your /u[01-09] mount points are
    actually on a SAN and that includes all the homes, inventory etc. In that
    case I'd expect your plan to work pefectly happily so long as step 6 really
    means

    shutdown databases, listeners, agents , dbconsole etc (ps -ef|grep oracle
    should return nothing).

    What I would do (which is likely being paranoid) before step 12 is to
    backup and then remove the existing inventory, create a new inventory
    location and run clone.pl for each home. I've written about oracle home
    cloning before at http://orawin.info/blog/2011/07/27/in-praise-of-clones/ and
    the metalink note is
    https://supporthtml.oracle.com/ep/faces/secure/km/DocumentDisplay.jspx?id=300062.1-
    you of course have a quicker method of "transferring the image to the
    new
    hosts".

    I keep meaning to write up my notes on cloning RAC homes which is almost as
    simple as my note above (but the above link isn't valid for RAC).

    On Fri, Oct 5, 2012 at 2:30 PM, Ramadoss, Karthik wrote:

    Thanks for your input. I think it works better for me to skip the fresh
    installs if it's not required when switching from AMD to Intel CPUs. This
    is because my Oracle Homes in the current servers are on EMC LUNS as well
    and can be easily moved over.

    May be I will add a step to relink the Oracle Homes in the new server
    before starting up the databases.

    -----Original Message-----
    From: oracle-l-bounce@freelists.org
    On Behalf Of Rich Jesse
    Sent: Friday, October 05, 2012 9:15 AM
    To: oracle-l@freelists.org
    Subject: Re: 3rd try: Linux database server upgrade (hardware only)

    Karthik writes:
    Let me try this again.
    Glad to see you got it! :)
    Current servers:
    64 bit AMD architecture

    New servers:
    64 bit Intel architecture

    Plan:
    Pre go-live
    1. Install Oracle Linux 5.6 on new servers with temporary hostnames
    2. Copy critical OS config files or match the Oracle OS
    requirements
    3. Do a fresh Oracle Home installs (I believe this would be the
    recommended way if not mandatory when changing CPU architecture?)
    For your purposes, AMD = Intel. A fresh install may not be necessary, but
    as long as you have the time, it should be fine, as the linking will catch
    differences in OS libraries, if there are any. Make sure that you have the
    same Oracle options installed! Use the installer on each server to
    compare, either side-by-side or output to a file for comparison.
    13. Enjoy a cold one
    My favorite step!

    GL!

    Rich

    --
    http://www.freelists.org/webpage/oracle-l


    --
    http://www.freelists.org/webpage/oracle-l


    --
    Niall Litchfield
    Oracle DBA
    http://www.orawin.info


    --
    http://www.freelists.org/webpage/oracle-l
  • Ramadoss, Karthik at Oct 5, 2012 at 9:49 pm
    Thank you Niall. Yes, everything indeed is in SAN except the /etc stuff which I plan to copy over.
    I will look into your article on Oracle Home cloning article.. I have done that in the Oracle E-Business suite world a lot but it's been a couple of years since I have done one. Appreciate your input.

    From: Niall Litchfield
    Sent: Friday, October 05, 2012 10:36 AM
    To: Ramadoss, Karthik
    Cc: rjoralist2@society.servebeer.com; oracle-l@freelists.org
    Subject: Re: 3rd try: Linux database server upgrade (hardware only)

    Not being flippant this time.

    You'll want to consider how you handle the Oracle inventory, oratab and root.sh. It sounds likely that all of your /u[01-09] mount points are actually on a SAN and that includes all the homes, inventory etc. In that case I'd expect your plan to work pefectly happily so long as step 6 really means

    shutdown databases, listeners, agents , dbconsole etc (ps -ef|grep oracle should return nothing).

    What I would do (which is likely being paranoid) before step 12 is to backup and then remove the existing inventory, create a new inventory location and run clone.pl<http://clone.pl> for each home. I've written about oracle home cloning before at http://orawin.info/blog/2011/07/27/in-praise-of-clones/ and the metalink note is https://supporthtml.oracle.com/ep/faces/secure/km/DocumentDisplay.jspx?id00062.1 - you of course have a quicker method of "transferring the image to the new hosts".

    I keep meaning to write up my notes on cloning RAC homes which is almost as simple as my note above (but the above link isn't valid for RAC).


    On Fri, Oct 5, 2012 at 2:30 PM, Ramadoss, Karthik wrote:
    Thanks for your input. I think it works better for me to skip the fresh installs if it's not required when switching from AMD to Intel CPUs. This is because my Oracle Homes in the current servers are on EMC LUNS as well and can be easily moved over.

    May be I will add a step to relink the Oracle Homes in the new server before starting up the databases.

    -----Original Message-----
    From: oracle-l-bounce@freelists.org On Behalf Of Rich Jesse
    Sent: Friday, October 05, 2012 9:15 AM
    To: oracle-l@freelists.org
    Subject: Re: 3rd try: Linux database server upgrade (hardware only)
    Karthik writes:
    Let me try this again.
    Glad to see you got it! :)
    Current servers:
    64 bit AMD architecture

    New servers:
    64 bit Intel architecture

    Plan:
    Pre go-live
    1. Install Oracle Linux 5.6 on new servers with temporary hostnames
    2. Copy critical OS config files or match the Oracle OS requirements
    3. Do a fresh Oracle Home installs (I believe this would be the
    recommended way if not mandatory when changing CPU architecture?)
    For your purposes, AMD = Intel. A fresh install may not be necessary, but as long as you have the time, it should be fine, as the linking will catch differences in OS libraries, if there are any. Make sure that you have the same Oracle options installed! Use the installer on each server to compare, either side-by-side or output to a file for comparison.
    13. Enjoy a cold one
    My favorite step!

    GL!

    Rich
  • Jorgensen, Finn at Oct 5, 2012 at 2:39 pm
    Karthik,

    Your method of moving the databases is largely how "cold failover clusters" like VCS work. Your method will work fine. You don't even need the same host names so if you currently have a host called prod01 you can just call the new one prod02 and be done with it.

    Don't forget you need the files in the dbs/pfile directory such as orapw* init*.ora and spfile*.ora. You also need listener.ora, tnsnames.ora and sqlnet.ora etc. plus oraInventory files and oratab/oraenv/dbhome etc. as well. All of these may be stored outside the filesystems you're moving over.

    Thanks,
    Finn


    -----Original Message-----
    From: oracle-l-bounce@freelists.org On Behalf Of Ramadoss, Karthik
    Sent: Friday, October 05, 2012 9:30 AM
    To: 'rjoralist2@society.servebeer.com'; oracle-l@freelists.org
    Subject: RE: 3rd try: Linux database server upgrade (hardware only)

    Thanks for your input. I think it works better for me to skip the fresh installs if it's not required when switching from AMD to Intel CPUs. This is because my Oracle Homes in the current servers are on EMC LUNS as well and can be easily moved over.

    May be I will add a step to relink the Oracle Homes in the new server before starting up the databases.

    -----Original Message-----
    From: oracle-l-bounce@freelists.org On Behalf Of Rich Jesse
    Sent: Friday, October 05, 2012 9:15 AM
    To: oracle-l@freelists.org
    Subject: Re: 3rd try: Linux database server upgrade (hardware only)

    Karthik writes:
    Let me try this again.
    Glad to see you got it! :)
    Current servers:
    64 bit AMD architecture

    New servers:
    64 bit Intel architecture

    Plan:
    Pre go-live
    1. Install Oracle Linux 5.6 on new servers with temporary hostnames
    2. Copy critical OS config files or match the Oracle OS requirements
    3. Do a fresh Oracle Home installs (I believe this would be the
    recommended way if not mandatory when changing CPU architecture?)
    For your purposes, AMD = Intel. A fresh install may not be necessary, but as long as you have the time, it should be fine, as the linking will catch differences in OS libraries, if there are any. Make sure that you have the same Oracle options installed! Use the installer on each server to compare, either side-by-side or output to a file for comparison.
    13. Enjoy a cold one
    My favorite step!

    GL!

    Rich

    --
    http://www.freelists.org/webpage/oracle-l


    --
    http://www.freelists.org/webpage/oracle-l

    This e-mail and any attachments are confidential, may contain legal, professional or other privileged information, and are intended solely for the addressee. If you are not the intended recipient, do not use the information in this e-mail in any way, delete this e-mail and notify the sender. -IP1
    --
    http://www.freelists.org/webpage/oracle-l
  • Ramadoss, Karthik at Oct 5, 2012 at 8:58 pm
    Finn,

    Great points. I appreciate your input. We have a need to retain the hostnames to keep this upgrade transparent to the enterprise users.

    Thanks!

    -----Original Message-----
    From: Jorgensen, Finn
    Sent: Friday, October 05, 2012 10:38 AM
    To: Ramadoss, Karthik; 'rjoralist2@society.servebeer.com'; oracle-l@freelists.org
    Subject: RE: 3rd try: Linux database server upgrade (hardware only)

    Karthik,

    Your method of moving the databases is largely how "cold failover clusters" like VCS work. Your method will work fine. You don't even need the same host names so if you currently have a host called prod01 you can just call the new one prod02 and be done with it.

    Don't forget you need the files in the dbs/pfile directory such as orapw* init*.ora and spfile*.ora. You also need listener.ora, tnsnames.ora and sqlnet.ora etc. plus oraInventory files and oratab/oraenv/dbhome etc. as well. All of these may be stored outside the filesystems you're moving over.

    Thanks,
    Finn


    -----Original Message-----
    From: oracle-l-bounce@freelists.org On Behalf Of Ramadoss, Karthik
    Sent: Friday, October 05, 2012 9:30 AM
    To: 'rjoralist2@society.servebeer.com'; oracle-l@freelists.org
    Subject: RE: 3rd try: Linux database server upgrade (hardware only)

    Thanks for your input. I think it works better for me to skip the fresh installs if it's not required when switching from AMD to Intel CPUs. This is because my Oracle Homes in the current servers are on EMC LUNS as well and can be easily moved over.

    May be I will add a step to relink the Oracle Homes in the new server before starting up the databases.

    -----Original Message-----
    From: oracle-l-bounce@freelists.org On Behalf Of Rich Jesse
    Sent: Friday, October 05, 2012 9:15 AM
    To: oracle-l@freelists.org
    Subject: Re: 3rd try: Linux database server upgrade (hardware only)

    Karthik writes:
    Let me try this again.
    Glad to see you got it! :)
    Current servers:
    64 bit AMD architecture

    New servers:
    64 bit Intel architecture

    Plan:
    Pre go-live
    1. Install Oracle Linux 5.6 on new servers with temporary hostnames
    2. Copy critical OS config files or match the Oracle OS requirements
    3. Do a fresh Oracle Home installs (I believe this would be the
    recommended way if not mandatory when changing CPU architecture?)
    For your purposes, AMD = Intel. A fresh install may not be necessary, but as long as you have the time, it should be fine, as the linking will catch differences in OS libraries, if there are any. Make sure that you have the same Oracle options installed! Use the installer on each server to compare, either side-by-side or output to a file for comparison.
    13. Enjoy a cold one
    My favorite step!

    GL!

    Rich

    --
    http://www.freelists.org/webpage/oracle-l


    --
    http://www.freelists.org/webpage/oracle-l

    This e-mail and any attachments are confidential, may contain legal, professional or other privileged information, and are intended solely for the addressee. If you are not the intended recipient, do not use the information in this e-mail in any way, delete this e-mail and notify the sender. -IP1
    --
    http://www.freelists.org/webpage/oracle-l
  • Yechiel Adar at Oct 24, 2012 at 6:30 am
    You also need to retain the same IP address:
    1) Firewall laws.
    2) Tns names that specify IP.
    3) Avoid the need to update the DNS servers.

    I suggest that after you rebuild your new servers, you will clone the
    database and bring it up on the new servers to be sure it will work OK.

    Yechiel Adar
    On 05/10/2012 22:57, Ramadoss, Karthik wrote:
    Finn,

    Great points. I appreciate your input. We have a need to retain the hostnames to keep this upgrade transparent to the enterprise users.

    Thanks!
    --
    http://www.freelists.org/webpage/oracle-l
  • Ramadoss, Karthik at Oct 24, 2012 at 3:09 pm
    Thank you for your reply.

    I just successfully finished this move last weekend. Here is the top level steps I performed after a lot of testing and everything worked great. Everyone who replied had great input and I took a route that made most sense for the time window I had to perform this.

    Prep steps:

    - Installed same version of linux
    - Set a temporary host name
    - Copy all necessary linux config files
    - Install all misc software - netbackup, etc.

    Go live:

    - Shutdown databases and all other oracle processes on old server
    - Take cold backup of all databases (SAN copy)
    - Unmount LUNs
    - Shutdown old server
    - Startup new server
    - Mount LUNs - verify mount points
    - Rename hostname
    - Relink all Oracle Homes
    - Startup database, listsners, agents, etc.

    This worked very well for us. But next time around, I would try cloning Oracle Homes instead of just copy and relink. I had to forego that route since I didn't have enough testing window.

    Again appreciate all your help.

    Karthik


    -----Original Message-----
    From: oracle-l-bounce@freelists.org On Behalf Of Yechiel Adar
    Sent: Wednesday, October 24, 2012 2:27 AM
    Cc: oracle-l@freelists.org
    Subject: Re: 3rd try: Linux database server upgrade (hardware only)

    You also need to retain the same IP address:
    1) Firewall laws.
    2) Tns names that specify IP.
    3) Avoid the need to update the DNS servers.

    I suggest that after you rebuild your new servers, you will clone the database and bring it up on the new servers to be sure it will work OK.

    Yechiel Adar
    On 05/10/2012 22:57, Ramadoss, Karthik wrote:
    Finn,

    Great points. I appreciate your input. We have a need to retain the hostnames to keep this upgrade transparent to the enterprise users.

    Thanks!
    --
    http://www.freelists.org/webpage/oracle-l


    --
    http://www.freelists.org/webpage/oracle-l
  • William Muriithi at Oct 5, 2012 at 1:20 pm

    Plan:
    Pre go-live
    1. Install Oracle Linux 5.6 on new servers with temporary hostnames
    2. Copy critical OS config files or match the Oracle OS requirements
    3. Do a fresh Oracle Home installs (I believe this would be the
    recommended way if not mandatory when changing CPU architecture?)
    You are not changing CPU architecture. Both of them are implementation of
    x86-64 instructions from AMD
    4. Copy all individual database config files, *.ora files, etc.
    5. Prep the new servers for RMAN backups, scripts

    Go live day
    6. Shutdown databases on old servers
    7. Unmount LUNs from old server
    8. Shutdown old servers
    9. Do the EMC magic to attach the LUNs to new hosts
    10. Change the hostname on new server to production hosts
    11. Mount LUNS on new server verifying the LUN-mount point matches old
    environment
    12. Fire up the databases and the listener
    Sound like setting up a database from raw backups. This will work with
    MySQL but I don't think Oracle database will be cooperative. Depends if it
    can load the control file.

    If it fails, you need to start it with nomount option and then manual point
    it to the necessary file through the alter directives. Then all these are
    on spfile so may be it will start fine

    Very junior as far as oracle is concerned so wouldn't be surprised if I am
    wrong. Hope someone senior will correct me though
    13. Enjoy a cold one
    I have just listed the core database move steps and of course there will
    be lot more prep work to get the scripts, cron jobs and scheduled processes
    moved over. I would love to hear from anyone else who has done a similar
    task or if you have any inputs.
  • Ramadoss, Karthik at Oct 5, 2012 at 1:27 pm
    Sorry I wrongly worded it about the architecture.
    Good point about step 12.

    Thanks!

    From: William Muriithi
    Sent: Friday, October 05, 2012 9:19 AM
    To: Ramadoss, Karthik
    Cc: oracle-l@freelists.org
    Subject: Re: 3rd try: Linux database server upgrade (hardware only)

    Plan:
    Pre go-live
    1. Install Oracle Linux 5.6 on new servers with temporary hostnames
    2. Copy critical OS config files or match the Oracle OS requirements
    3. Do a fresh Oracle Home installs (I believe this would be the recommended way if not mandatory when changing CPU architecture?)
    You are not changing CPU architecture. Both of them are implementation of x86-64 instructions from AMD
    4. Copy all individual database config files, *.ora files, etc.
    5. Prep the new servers for RMAN backups, scripts

    Go live day
    6. Shutdown databases on old servers
    7. Unmount LUNs from old server
    8. Shutdown old servers
    9. Do the EMC magic to attach the LUNs to new hosts
    10. Change the hostname on new server to production hosts
    11. Mount LUNS on new server verifying the LUN-mount point matches old environment
    12. Fire up the databases and the listener
    Sound like setting up a database from raw backups. This will work with MySQL but I don't think Oracle database will be cooperative. Depends if it can load the control file.

    If it fails, you need to start it with nomount option and then manual point it to the necessary file through the alter directives. Then all these are on spfile so may be it will start fine

    Very junior as far as oracle is concerned so wouldn't be surprised if I am wrong. Hope someone senior will correct me though
    13. Enjoy a cold one
    I have just listed the core database move steps and of course there will be lot more prep work to get the scripts, cron jobs and scheduled processes moved over. I would love to hear from anyone else who has done a similar task or if you have any inputs.

    Thanks in advance,
    Karthik
    Senior Oracle DBA


    --
    http://www.freelists.org/webpage/oracle-l
    --
    http://www.freelists.org/webpage/oracle-l

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedOct 5, '12 at 1:15p
activeOct 24, '12 at 3:09p
posts11
users6
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase