1. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t Using Data Guard for hardware migration UKOUG RAC & HA SIG, Feb 2008 Miguel Anjo, CERN Physics Databases LCG

2. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t Motivation Commodity hardware has small warranty periods Hardware specifications progress very fast Minimal downtime required Easy to fallback in case of error Can include – Version change – Migration to 64bit – Different hardware sizing Our use cases: migrate hardware (storage + servers) and – upgrade 10.2.0.2 to 10.2.0.3 – upgrade 32bit to 64bit OS+RDBMS Using Data Guard for Hardware migration - 2

3. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t Outline I.Preparation steps – Standby DB II.Preparation steps – Primary DB III.Configuration and startup – Standby DB IV.Final steps – Primary DB V.Checks VI.Database switchover / migration completion VII.Final cleanup Using Data Guard for Hardware migration - 3

4. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t Configure new hw: OS, storage, oracle account Install clusterware (latest version if upgrading) Install rdbms software (exactly same version) – Use cloning from primary/source: sudo tar cfpz rdbms_PRE_migr.tgz $ORACLE_HOME/rdbms on standby/destination untar: tar xfp ; edit/remove instance specific files: minimal set is $ORACLE_HOME/dbs + $ORACLE_HOME/network/admin Configure listeners (netca) Configure ASM instances, create diskgroups Don’ t create database Using Data Guard for Hardware migration - 4

5. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t Needs to be in ARCHIVE LOG mode Set force logging Copy $ORACLE_HOME/network/admin/ + spfile to stage directory in Standby DB Make at least level 1 backup after setting force logging Save service definitions for later recreation Using Data Guard for Hardware migration - 5

6. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t Change tnsnames.ora copied from primary with standby hosts – Add new possible nodes – Add entry old_db pointing to primary database – Copy on all standby nodes (also sqlnet.ora ) Create password file (SYS pw needs to be the same as in primary) Change pfile copied from primary with dataguard parameters – log_archive_dest_2, standby_file_management, fal_server, fal_client – If diskgroup names are different, set also conversion parameters and location of FRA – Add new nodes ( instance_name, instance_nu,ber, thread, undo_tablespace, local_listener ) Create dump directories Using Data Guard for Hardware migration - 6

7. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t Create controlfile directory in ASM Create DB spfile (and pfiles) SQL> startup nomount; Configure RMAN/backups Start DB duplication with RMAN: $ rman target admin@old_db auxiliary / nocatalog RUN { ALLOCATE AUXILIARY CHANNEL t1 DEVICE TYPE sbt_tape; ALLOCATE AUXILIARY CHANNEL t2 DEVICE TYPE sbt_tape; DUPLICATE TARGET DATABASE FOR STANDBY; } Using Data Guard for Hardware migration - 7

8. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t Start redo apply: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; Register with clusterware the DB, instances and services srvctl add database -d {DB_NAME} -o $ORACLE_HOME srvctl add instance -d {DB_NAME} -i {INSTANCE_NAME} -n {NODE_NAME} srvctl modify instance -d {DB_NAME} -i {INSTANCE_NAME} -s {ASM_INSTANCE_NAME} srvctl add service -d {DB_NAME} -s {SERVICE_NAME} -R {PREF_NODES} –a {AV_NODES} Add entries on /etc/oratab on all nodes Using Data Guard for Hardware migration - 8

9. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t Add entry in tnsnames.ora on all nodes pointing to standby DB Modify Dataguard parameters SQL> alter system set log_archive_dest_2 ='service=standbydb valid_for=(online_logfiles,primary_role)' scope=both sid='*'; SQL> alter system set standby_file_management =auto scope=both sid='*'; Using Data Guard for Hardware migration - 9

10. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t V - Checks Using Data Guard for Hardware migration - 10

11. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t Shutdown all services on primary Shutdown all instances but one On running instance set primary to standby role SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN; SQL> SHUTDOWN IMMEDIATE SQL> STARTUP MOUNT Using Data Guard for Hardware migration - 11

12. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t Verify switchover_status on v$database (should be TO_PRIMARY ) Switch to primary role SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; SQL> ALTER DATABASE OPEN; Do any necessary upgrade, patchset to target system Start up other nodes of new primary DB Using Data Guard for Hardware migration - 12

13. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t VII – Final clean-up Disable archivelog mode and force logging, if applicable Remove DataGuard parameters from spfile Grant sysdba privileges to any specific user Backups: – Crosscheck backups, delete expired ones, do full backup – If no backups needed, remove ones created for migration Remove pointers to old db on tnsnames.ora Shutdown primary cluster Add RAC nodes to new setup – Redologs, undo tablespaces, add to CRS, public tnsnames.ora Using Data Guard for Hardware migration - 13

14. CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/i t Questions? …and answers Work done mostly by Jacek Wojcieszuk and Dawid Wojcik with collaboration of Eva DaFonte, Luca Canali and Miguel Anjo name.surname@cern.ch Thanks, Miguel.Anjo@cern.ch Using Data Guard for Hardware migration - 14