• Blog
  • Get Help Now!
  • Customer Portal

BlueGecko Denmark

  • Why you need us
    • Why act now
    • Why are we unique
  • What we do
    • Products Supported 24/7
      • MySQL
      • Postgres
      • SQL Server
      • Open Source
      • OS & Storage
  • How we do it
    • Consulting
    • System Monitoring
    • Security
  • Support
    • Blog
      • Oracle
      • MySQL
      • News & Events
      • Oracle Applications
      • Amazon Web Services
      • Jeremiah Wilton’s Oradeblog
      • OurSQL Community Podcast
      • Remote DBA
    • Team viewer
    • Whitepapers
  • About Us
    • Philosophy
    • The Blue Gecko Teams
    • Employment Opportunities
    • Partners
    • News
    • Press
  • Contact Us

June 26, 2013 by kanthonisen

Case: Oracle Dataguard switchover test

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 11.2.0.3 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.

Filed Under: Oracle

Categories

  • Amazon Web Services
  • Configuration Management
  • downtime
  • Drizzle
  • ebs
  • Education
  • elastic block store
  • elastic compute cloud
  • hosting
  • hot backup
  • ignorance
  • Infrastructure
  • IOUG
  • Jeremiah Wilton's Oradeblog
  • misconception
  • misconceptions
  • Monocle
  • MySQL
  • MySQL Council
  • News
  • News & Events
  • Oracle
  • Oracle APEX
  • Oracle Applications
  • Oracle Data Guard
  • Oracle Database
  • Oracle Database Appliance
  • Oracle Linux
  • Our People
  • OurSQL Community Podcast
  • outage
  • parallel
  • performance
  • podcast
  • proof
  • Remote DBA
  • replication
  • S3
  • Security
  • SQL Server
  • System monitoring
  • Tomcat
  • Uncategorized

Contact Blue Gecko

  • This field is for validation purposes and should be left unchanged.

Get Our Newsletter

  • This field is for validation purposes and should be left unchanged.

The Fine Print

  • Privacy Policy
  • Terms of Use
  • When is remote DBA the right solution
  • What are remote DBA services
  • Get Help

Blog Categories

  • 24/7 support
  • Blue Gecko 360° Services
  • Products Supported 24/7

Virtual runs

Contact Blue Gecko

Blue Gecko A/S
Slotsgade 21
DK – 4200 Slagelse
Denmark
Phone: (DK) +45 70 60 51 20

Networks

  • Email
  • Twitter

© Blue Gecko Group