Recently, we migrated a large customers database environments to new databases on new hardware.
The new setup consists of a cold failover Linux Cluster, which is located in the preferred production site, and two Dataguard(standby) databases in a remote DR site. Oracle 11gR2 Grid Infrastructure is used as basis for ASM diskgroups and
for controlling the cold-failover (database defined as a cluster service). For the database Oracle 18.104.22.168 EE is used.
Monitoring the complete setup is done using Oracle Cloud Control 12c, which also handles scheduling of database backups, maintenance jobs. We also use Oracle Cloud Control for realtime performance monitoring and administration.
One standby database is maintained as a physical standby database, the other is opened in snapshot standby mode every day for testing and educationional purposes, and every night, it is sync’ed up with the changes made to the primary database during the day. The physical standby database is running as an Active Dataguard database which means that it can be used for (read only) reporting purposes etc.
We chose Oracle Enterprise Linux 6.4, so the support for the software stack is kept within the same organization (Oracle). The migration was made using Oracle Datapump.
After we had migrated production, we established the standby databases, and then we arranged a service window for testing switchover to the physical standby database.
The switchover was made using Oracle Dataguard Broker, a part of Oracle Dataguard, and it worked seamlessly. Changes made to the new primary database was replicated instantly to the new standby database. However, the test revealed a number of minor setup issues, as some of the applications was unable to connect to the new primary database. Most clients was fixed by correcting the tnsnames.ora file, but we also found a missing firewall rule. Another issue found was a missing init.ora parameter (utl_smtp_server).
Conclusion: Having corrected the issues we had found, and tested again, we now know with confidence that running on the standby database is truly an option.