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