Database Reference
In-Depth Information
In the above configuration you find three standby databases and a primary. The database name has to be
consistent in the initialization file for all databases in the Data Guard configuration. The database name is defined
in the
db_name
initialization parameter at the database creation time and cannot easily be changed. Each database
however has its own
unique
name. The unique name often matches the Oracle SID and has a reference to the
data center where the database is located. Refer to the section “Naming conventions” in the next chapter for an
explanation of why this naming scheme has been chosen. The
db_unique_name
initialization parameter for each
database (including the primary) is added when the standby database is created. In the absence of a
db_unique_name
initialization parameter the value defaults to the
db_name
. Setting the
db_unique_name
is often forgotten on the
primary database.
All databases in a Data Guard Broker configuration are said to have a state associated with them. The state
depends on the database role (primary, physical standby, etc.). The primary database can either be in state
“transport-on”, which means it ships redo to the destinations defined in the configuration, or it can be in state
“transport-off ” which has the opposite effect. Changing the state to “transport-off ” is not allowed in higher protection
modes. The standby databases in turn can be in state “apply-on” which starts managed recovery including Real Time
Apply if there are standby redo logs. Alternatively managed recovery can be turned off by transitioning the standby
database into the state “apply-off.”
WhY Data GUarD aND raC are COMpLeMeNtarY
Very often during user group meetings you meet participants confusing the Real Application Clusters option
with a disaster recovery solution. A quote heard often is: “We use a stretch cluster-we do not need Data Guard.”
This confusion is not limited to user groups though, generally speaking, RAC and Data Guard can be the source
of some controversy. The discussion can get quite heated, especially when extended distance clusters are
mentioned. Why that confusion? Let's remember the following two simple points:
•
Real Application Clusters are built to protect Oracle database instances from failure.
•
Data Guard is designed to provide an additional copy of your production database.
The significance lies in the scope: remember that as per Table
9-1
the scope of RAC is the instance. To make
this clearer, imagine a migration weekend, and the script turns out to have a bug corrupting the schema you are
migrating. The consequence is logical corruption on the database level: you can start as many RAC instances
now, the fundamental problem is that your schema is logically corrupt, no matter what. The common solutions are
to either perform a Flashback Database operation if possible, or to do a point-in-time recovery.
A standby database on the other hand can be very beneficial in such a scenario. If the release procedure instructs
the database administrator to either cancel or delay the redo application on the standby database you have a
perfectly valid copy of the production database as it was when the release started. Remember that a standby
database does not necessarily have to be in a remote data center! You could have situations where a primary
database has a local and remote standby database. The local standby would be used in exactly the way just
described and could be used to take over from production on very short notice. The remote standby database
serves as the life insurance if the primary data center fails for whatever reason, and possibly to take backups
and/or reporting.
To come full circle, Data Guard does not protect you from instance failure; remember the scope again. For this
reason, RAC and Data Guard are complementary technologies. The existence of RAC or even stretched RAC does
not make a Data Guard configuration redundant, and neither does Data Guard protect you from instance failure.
Search WWH ::
Custom Search