Professional Documents
Culture Documents
Data Guard
Oracle 9i Data Guard is the new name for Oracle 8i Standby Server, incorporating a large number of
new features. In this article I shall only focus on those relevant to the "Oracle9i Database: New
Features For Administrators" OCP exam. For more detailed information read the Oracle 9i Data
Guard Concepts and Administration documentation.
Architecture
Setup No-Data-Divergence
Database Switchover
Database Failover
Related articles.
Data Guard Quick Links : 11gR2, 12cR1, 12cR2, 18c, 19c, All Articles
Architecture
Primary Database - A production database that is used to create standby databases. The archive logs
from the primary database are transfered and applied to standby databases. Each standby can only
be associated with a single primary database, but a single primary database can be associated with
multiple standby databases.
Network Configuration - The primary database is connected to one or more standby databases using
Oracle Net.
Log Apply Services - Apply the archived redo logs to the standby database. The Managed Recovery
Process (MRP) actually does the work of maintaining and applying the archived redo logs.
Role Management Services - Control the changing of database roles from primary to standby. The
services include switchover, switchback and failover.
Data Guard Broker - Controls the creation and monitoring of Data Guard. It comes with a GUI and
command line interface.
Log Writer Process (LGWR) - Collects redo information and updates the online redo logs. It can also
create local archived redo logs and transmit online redo to standby databases.
Archiver Process (ARCn) - One or more archiver processes make copies of online redo logs either
locally or remotely for standby databases.
Fetch Archive Log (FAL) Server - Services requests for archive redo logs from FAL clients running on
multiple standby databases. Multiple FAL servers can be run on a primary database, one for each
FAL request. .
Fetch Archive Log (FAL) Client - Pulls archived redo log files from the primary site. Initiates transfer of
archived redo logs when it detects a gap sequence.
Remote File Server (RFS) - Receives archived and/or standby redo logs from the primary database.
Archiver (ARCn) Processes - Archives the standby redo logs applied by the managed recovery process
(MRP).
Managed Recovery Process (MRP) - Applies archive redo log information to the standby database.
Data Guard can be configured to run with varying synchronization modes indicating the potential for
data loss.
No-Data-Loss mode : This simply means that the log transport services will not acknowledge
modifications to the primary database until they are available to the standby database. This doesn't
mean that the modifications have been applied to the standby database, merely that the log
information is available to the log apply services should failover occur. This mode is implemented
using standby redo logs on the standby server.
No-Data-Divergence mode : This is an extension of the no-data-loss mode whereby modifications to
the primary database are prevented if conectivity between the primary and at least one standby
database is unavailable.
Minimal-Data-Loss mode : When the performance requirements of the primary database are the top
priority this mode provides the optimum balance of data protection and performance.
Setup No-Data-Divergence
To setup no-data-divergence, the most extreme level of data protection, then do the following.
Add an entry for the standby server into the "tnsnames.ora" file.
stby1=
(DESCRIPTION =
(ADDRESS_LIST =
(CONNECT_DATA =
(SERVICE_NAME = stby1.world)
Assuming your database in already in ARCHIVELOG mode one of the archive destinations will be set.
Add the other entries.
CONTROL_FILES=primary.ctl
COMPATIBLE=9.0.1.0.0
LOG_ARCHIVE_START=true
LOG_ARCHIVE_DEST_STATE_1=enable
LOG_ARCHIVE_DEST_STATE_2=enable
LOG_ARCHIVE_FORMAT=arc%t_%s.arc
REMOTE_ARCHIVE_ENABLE=true
The LGWR SYNC AFFIRM keywords indicate that the Logwriter should synchronously write updates
to the online redo logs to this location and wait for confirmation of the write before proceeding. The
remote site will process and archive these standby redo logs to keep the databases synchronized.
This whole process can impact performance greatly but provides maximum data security.
Create standby database controlfile using: ALTER DATABASE CREATE STANDBY CONTROLFILE AS
'c:\stbycf.f';
SERVICE_NAMES = stby1
CONTROL_FILES=standby.ctl
COMPATIBLE=9.0.1.0.0
LOG_ARCHIVE_START=true
LOCK_NAME_SPACE=stby1
FAL_SERVER=prim1
FAL_CLIENT=stby1
#DB_FILE_NAME_CONVERT=("/primary","/standby")
#LOG_FILE_NAME_CONVERT=("/primary","/standby")
STANDBY_ARCHIVE_DEST=C:\Oracle\Oradata\TSH1\Archive
LOG_ARCHIVE_DEST_1='LOCATION=C:\Oracle\Oradata\TSH1\Archive'
LOG_ARCHIVE_TRACE=127
LOG_ARCHIVE_FORMAT=arc%t_%s.arc
STANDBY_FILE_MANAGEMENT=auto
REMOTE_ARCHIVE_ENABLE=true
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = myHost)(PORT = 1512))
STANDBY_LISTENER = (ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1512)(HOST=myHost))
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS_LIST =
(ADDRESS_LIST =
(DESCRIPTION =
(PROTOCOL_STACK =
(PRESENTATION = GIOP)
(SESSION = RAW)
)
)
STANDBY_LISTENER = (ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1512)(HOST=myHost))
SID_LIST_LISTENER =
(SID_LIST =
Reload the listener file using lsnrctl reload from the command prompt.
stby1=
(DESCRIPTION =
(ADDRESS_LIST =
(CONNECT_DATA =
(SERVICE_NAME = stby1.world)
Create standby redo logs on the standby database to receive online redo information from the
Logwriter on the primary database. The minimum number of groups required is an exact match,
number and size, of the primary database, but performance may be increased by adding more.
Copy all archive logs from the primary to the standby server. This is the only time you should need to
do this.
Now that Data Guard is configured and running the primary database can be prevented from
applying updates unless the update has been sent to at least one standby location. Connect to the
primary database and execute the following.
SQL>
If the primary database is not available the standby database can be activated as a primary database
using the following statements.
Since the standby database is now the primary database it should be backed up immediately. The
previous primary database can then be configured as a standby.
Backups of the standby database can only be performed if the database is shut down or in read only
mode. Read only mode is best for managed recovery systems as archive logs will still be transfered
during the backup process, thus preventing gap sequences. Once the server is in the desired mode
simply copy the appropriate database files.
Database Switchover
A database can be in one of two mutually exclusive modes (primary or standby). These roles can be
altered at runtime without loss of data or resetting of redo logs. This process is known as a
Switchover and can be performed using the following statements.
SHUTDOWN IMMEDIATE;
STARTUP PFILE=C:\Oracle\Admin\TSH1\pfile\init.ora
This process has no affect on alternative standby locations. The process of converting the instances
back to their original roles is known as a Switchback. The switchback is accomplished by performing
another switchover.
Database Failover
Graceful Database Failover occurs when database failover causes a standby database to be
converted to a primary database.
This process will recovery all or some of the application data using the standby redo logs, therefore
avoiding reinstantiation of other standby databases. If completed successfully, only the primary
database will need to be reinstatiated as a standby database.
Forced Database Failover changes one standby database to a primary database. Application data
may be lost neccessitating the reinstantiation of the primary and all standby databases.
Automatic Archive Gap Detection
Gaps in the sequence of archive logs can be created when changes are applied to the primary
database while the standby database is unavailable. In Oracle8i the archive redo logs associated with
these gaps had to be identified using the V$ARCHIVE_GAP view and copied manually to the standby
server before managed recovery could be initiated again. In Oracle9i most of these gap sequences
can be resolved automatically. The following parameters must be added to the standby init.ora file
where the values indicate net services names.
FAL_SERVER = 'primary_db1'
FAL_CLIENT = 'standby_db1'
The FAL server is normally the primary database, but can be another standby database. Once the
standby database is placed in managed recovery mode it will automatically check for gap sequences.
If it finds any it will request the appropriate files from the primary database via the FAL server. If the
gap sequences cannot be resolved the files have to be recovered manually.
In Oracle8i managed recovery caused the user session to hang until the process was stopped by the
user. This type of recovery is still available along with a background recovery that spawns a new
background process and frees the user session
Application of the archived redo logs to the standby database can be delayed using the DELAY
keyword. If a rogue statement significantly damages the primary database the DBA can choose to
switch to the standby database, which will be in a state prior to this action