1 / 11

Smooth Hardware Migration with Data Guard: A Case Study

Follow the detailed steps of migrating the ATLAS conditions database to new hardware using Data Guard, ensuring minimal downtime and smooth transition. Learn about backup, copy, standby creation, switchover, and post-migration tasks.

csessions
Download Presentation

Smooth Hardware Migration with Data Guard: A Case Study

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Hardware migration using Data Guard Jon Westgaard NDGF / University of Oslo November 2009

  2. The ATLAS conditions database at NDGF was migrated to new hardware in October • We used the migration procedure with Data Guard from the CERN Twiki pages:https://twiki.cern.ch/twiki/bin/viewauth/PDBService/MigrationWithDataGuard32to64

  3. The database was migrated from: • Single instance • 32 bit, RHEL4 • Located in Helsinki, Finland (CSC) • migrated to: • 3 node RAC • 64 bit, RHEL5 • Located in Oslo, Norway (University of Oslo) • Size of database during migration: ~350GB

  4. Step 1 – Backup the old DB • Full backup of the old database to local disk (outside of ASM) including archivelogand current controlfile for standby • We had to use RMAN compressed backupset due to lack of disk space • RMAN compression algorithm in 10gR2 is really slow - CPU intensive • Elapsed time for the backup: 1.5 hour

  5. Step 2 – Copy backup files • Copied the RMAN backup files from the old server to the new cluster • This step was required since the old and new servers did not have any shared disk or shared RMAN tape device • The path and filename of the backup files on the new server and the old server must be identical • Elapsed time for copying the backup files fromHelsinki to Oslo: 10 minutes

  6. Step 3 – create stdby database • Created standby database withDUPLICATE TARGET DATABASE FOR STANDBY DORECOVER; • I did an initial duplicate with dorecover to get a consistent database that could be activated and opened for testing without starting redo apply • Elapsed time for “duplicate … for standby dorecover”: 2.5 hours (using compressed backupsets from local disk)

  7. Step 4 – start redo apply • Started redo apply and prepared for switchover • Read note 751600.1 Data Guard Physical Standby Switchover: • Pre-switchover checks: no apply delay, no large gaps • The note has some useful information about fallback options if switchover fails

  8. Step 5 - switchover • Turned on redo apply tracing:alter system set log_archive_trace=8191(optional, might be useful if something fails) • Stopped streams propagation from Tier 0 • Switched the old database from primary to standby (and verified that the new database had received end-of-redo from the old database) • Switched the new database from standby to primary

  9. Step 6 – post switchover tasks • Additional step due to switchover from 32 to 64 bit: • Recompile PL/SQL code(see note: 414043.1 Role Transitions for Data Guard Configurations Using Mixed Oracle Binaries) • Switched to cluster database - added RAC node 2 and 3 • Restarted streams propagation from Tier 0 using the new connect string

  10. Conclusion • The migration procedure using Data Guard worked fine giving: • Minimal service downtime • Downtime independant of the size of the database

  11. One comment:If the spfile is created from pfile when thedatabase is down (as in this procedure) it is created in the following directory:+dg/DB_UNKNOWN/PARAMETERFILE/and not in:+dg/<db_name>/PARAMETERFILE/We should possibly create the spfile again withdatabase in mount so that it is moved to the correct directory

More Related