Oracle Data Guard is a very useful tool to help maintain high availability and to protect your data. It is not uncommon to see "must have experience with RAC and Data Guard" in job postings on Monster and Dice. If you are not using Data Guard at work or do not work in an environment where it is used (a development shop versus a production environment), how do you get experience using it? This is one of those Catch-22 situations where it takes experience to get experience, and the unstated question is, "How do you get experience in the first place?"
The purpose of this series is to give you the little push you may have needed to get up and running with Data Guard. When viewed as a whole, it may seem like a lot is required, but really, it is very easy to accomplish. The first part of this series will cover the hardware and networking setup and provide a brief overview of what Data Guard offers. The second and third parts will cover the actual setup and use of the types of copies (i.e., standby databases), namely, physical and logical copies.
What is Data Guard?
To start off, what was Data Guard? Oracle8i introduced the Standby Database and the basic concept remains the same in Oracle9i, but the feature was renamed to Data Guard, and many new features were added. As a major tool or feature for use with an Oracle database, it warrants its own set of feature-specific documentation. The two guides are Data Guard Concepts and Administration and Data Guard Broker.
The concepts and admin guide provides a good explanation of the Data Guard environment. Third party Oracle database administration books generally cover Data Guard (or Standby Database from 8i days). A more in-depth book from Oracle Press by Matthew Hart and Scott Jesse (Oracle Database 10g High Availability with RAC, Flashback & Data Guard) serves as an excellent cookbook or "how to" guide for configuring a database to use Data Guard. Technically speaking, you are configuring a minimum of two databases, but "database" by itself refers to the primary database you are trying to protect.
I find it curious that in the more than 1300 pages of Oracle Database 10g The Complete Reference that Data Guard is never mentioned once. RAC and Flashback are covered, but why did Data Guard get the short shrift? Part of the title ("The Complete Reference") may sound familiar if you have purchased books from Osborne/McGraw-Hill and those books are a lot closer to being complete references. If you look closely at Oracle Press' information, you will see that it is a subsidiary of Osborne/McGraw-Hill. The complete reference is not, and the Hart/Jesse book fills that gap quite nicely.
The best description of Data Guard comes from the concepts and admin guide, and it is provided here for your reference.
Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions. Data Guard maintains these standby databases as transactionally consistent copies of the production database. Then, if the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, thus minimizing the downtime associated with the outage. Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability.
In this case, a picture (from Oracle's documentation) helps clarify the Data Guard environment.
You have two choices as to the type of standby database: physical and logical. Each has its advantages and disadvantages, benefits and shortcomings. Whichever type you wind up using, one thing that is common to both is the mode in which the primary database operates - archivelog mode. A benefit (and requirement) of using Data Guard is that you will become better at using archive logs, so if this is a rusty area for you, you may want to read up on backup & recovery and user managed recovery.
Physical standbys offer:
- An identical physical copy of the primary database
- Disaster recovery and high availability
- Data protection
- Reduction in primary database workload
Logical standbys offer:
- Simultaneous use for reporting, summations and queries
- Efficient use of standby hardware resources
- Reduction in primary database workload
- Some limitations on the use of certain datatypes
Some general operational requirements include the following:
- All databases must use the same edition of Oracle Enterprise Edition
- Use of the same Oracle software release
- Same type of operating system, but not necessarily the same version
- Same hardware and OS architecture (32-bit to 32-bit, Sun to Sun, etc.)
- User accounts on both databases must have sysdba privileges
Although you can operate a standby database on the same system as the primary, it rather defeats the purpose of having a physically remote standby available for disaster recovery. As a vehicle for learning, that may be acceptable, but for real life use, you are just creating extra work for yourself.