Data Guard

DATA GUARD
Architecture
The Oracle9i Data Guard architecture incorporates the following items:
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.
Standby Database - A replica of the primary database.
Log Transport Services - Control the automatic transfer of archive redo log files from the
primary database to one or more standby destinations.
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.
The services required on the primary database are:
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. .
The services required on the standby database are:
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.
Database Synchronization Options
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:
Setup Primary Database

Shutdown the database using: SHUTDOWN IMMEDIATE
Backup all database files.
Add an entry for the standby server into the tnsnames.ora file:
stby1=
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = myServerName)(PORT = 1512))
)
(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 entires:
CONTROL_FILES=primary.ctl
COMPATIBLE=9.0.1.0.0
LOG_ARCHIVE_START=true
LOG_ARCHIVE_DEST_1='LOCATION=C:\Oracle\Oradata\TSH1\Archive MANDATORY
REOPEN=30'
LOG_ARCHIVE_DEST_2='SERVICE=stby1 LGWR SYNC AFFIRM'
LOG_ARCHIVE_DEST_STATE_1=enable
LOG_ARCHIVE_DEST_STATE_2=enable
LOG_ARCHIVE_FORMAT=arc%t_%s.arc
REMOTE_ARCHIVE_ENABLE=trueThe 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.
Startup the database using: STARTUP PFILE=C:\Oracle\Admin\TSH1\pfile\init.ora
Create standby database controlfile using: ALTER DATABASE CREATE STANDBY

CONTROLFILE AS 'c:\stbycf.f';
Setup Standby Database
Copy the production backup files to the standby server.

Copy the standby controlfile to the standby server.
Alter the control_files and archive parameters of the init.ora as follows:
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
# Uncomment is filename conversion is needed

#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=trueAdd the following entries into the listener.ora file:
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = myHost)(PORT = 1512))
)
STANDBY_LISTENER = (ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1512)(HOST=myHost))
)The file should resemble the following:
# LISTENER.ORA Network Configuration File: C:\Oracle\Ora901\network\admin\listener.ora

# Generated by Oracle configuration tools.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
(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 =
(SID_DESC = (SID_NAME = PLSExtProc)(ORACLE_HOME = C:\Oracle\Ora901)
(PROGRAM = extproc))
(SID_DESC = (ORACLE_HOME = C:\Oracle\Ora901) (SID_NAME = TSH1)
)
)Reload the listener file using lsnrctl reload from the command prompt.
Add the following entry into the tnsnames.ora file:
stby1=
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = myServerName)(PORT = 1512))
)
(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:
ALTER DATABASE ADD STANDBY LOGFILE GROUP 10

('C:\Oracle\Oradata\TSH1\redo1a.log','C:\Oracle\Oradata\TSH1\redo1b.log') SIZE 500K;Start
Managed Standby Recovery
During managed recovery the transfer of archivelogs is controlled by the servers without user
intervention.
Copy all archive logs from the primary to the standby server. This is the only time you should
need to do this.
From sqlplus do the following:
SQL> CONNECT sys/password AS SYSDBA

SQL> STARTUP NOMOUNT PFILE=C:\Oracle\Admin\TSH1\pfile\init.ora
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM
SESSION;Protect Primary Database
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:
ALTER DATABASE SET STANDBY DATABASE PROTECTED;Cancel Managed Standby

Recovery
To stop managed standby recovery:
SQL> -- Cancel protected mode on primary
SQL> CONNECT sys/password@primary1 AS SYSDBA
SQL> ALTER DATABASE SET STANDBY DATABASE UNPROTECTED;
SQL>
SQL> -- Cancel recovery if necessary
SQL> CONNECT sys/password@standby1 AS SYSDBA
SQL> RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE OPEN READ ONLY;The database can subsequently be switched
back to recovery mode as follows:
SQL> -- Startup managed recovery
SQL> CONNECT sys/password@standby1 AS SYSDBA

SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP NOMOUNT PFILE=C:\Oracle\Admin\TSH1\pfile\init.ora
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
SQL> -- Protect primary database
SQL> CONNECT sys/password@primary1 AS SYSDBA
SQL> ALTER DATABASE SET STANDBY DATABASE PROTECTED;Activating A
Standby Database
If the primary database is not available the standby database can be activated as a primary
database using the following statements:
SQL> -- Cancel recovery if necessary

SQL> RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;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.
Backup Standby Database

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:
-- Convert primary database to standby

CONNECT sys/change_on_install@prim1 AS SYSDBA
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;
-- Shutdown primary database

SHUTDOWN IMMEDIATE;
-- Mount old primary database as standby database
STARTUP NOMOUNT PFILE=C:\Oracle\Admin\TSH1\pfile\init.ora
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
-- Convert standby database to primary

CONNECT sys/change_on_install@stby1 AS SYSDBA
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
-- Shutdown standby database

SHUTDOWN IMMEDIATE;
-- Open old standby database as primary

STARTUP PFILE=C:\Oracle\Admin\TSH1\pfile\init.oraThis 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:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

ALTER DATABASE ACTIVATE STANDBY 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.
Background Managed Recovery

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:
-- User session hangs

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
-- User session released

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT
FROM SESSION;Delayed Redo Application
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:
-- Delay application of archived redo logs by 30 minutes.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 30;
-- Return to no delay (Default).

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

Data Guard

Uploaded by

Copyright:

Available Formats

Data Guard

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Data Guard

Uploaded by

Copyright:

Available Formats

DATA GUARD

The Oracle9i Data Guard architecture incorporates the following items:

Database Synchronization Options

No-Data-Divergence mode : This is an extension of the no-data-loss mode whereby

Setup Primary Database

Startup the database using: STARTUP PFILE=C:\Oracle\Admin\TSH1\pfile\init.ora

Create standby database controlfile using: ALTER DATABASE CREATE STANDBY

Copy the production backup files to the standby server.

# Uncomment is filename conversion is needed

# LISTENER.ORA Network Configuration File: C:\Oracle\Ora901\network\admin\listener.ora

ALTER DATABASE ADD STANDBY LOGFILE GROUP 10

From sqlplus do the following:

SQL> CONNECT sys/password AS SYSDBA

ALTER DATABASE SET STANDBY DATABASE PROTECTED;Cancel Managed Standby

SQL> CONNECT sys/password@standby1 AS SYSDBA

SQL> -- Cancel recovery if necessary

Backup Standby Database

-- Convert primary database to standby

-- Shutdown primary database

-- Convert standby database to primary

-- Shutdown standby database

-- Open old standby database as primary

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

Automatic Archive Gap Detection

Background Managed Recovery

-- User session hangs

-- User session released

-- Delay application of archived redo logs by 30 minutes.

-- Return to no delay (Default).

You might also like