Вы находитесь на странице: 1из 6

ORACLE DATA GUARD CONFIGURATION

1. Identify the Primary Database Data Files


SQL> SELECT NAME FROM V$DATAFILE;
NAME
----------------------------------------------------------------------------
/disk1/oracle/DEV/sapdata1/system_1/system01.dbf
/disk1/oracle/DEV/sapdata1/prd640_1/data1.dbf
/disk1/oracle/DEV/sapdata1/prd640_2/data2.dbf
/disk1/oracle/DEV/sapdata1/prd640_3/data3.dbf
/disk1/oracle/DEV/sapdata1/prd640_4/data4.dbf
2. Make a Copy of the Primary Database
a. Step 1 Shut down the primary database.
Issue the following SQL*Plus statement to shut down the primary database:
SQL> SHUTDOWN IMMEDIATE;
b. Step 2 Copy the datafiles to a temporary location.
a) Copy the datafiles that you identified above to a temporary location using an operating
system utility copy command. The following example uses the UNIX cp command:
b) cp /disk1/oracle/DEV/sapdata1/system_1/system01.dbf
/disk1/oracle/DEV_stdby/sapdata1/prd640_1/data1.dbf
c) Copying the data files to a temporary location will reduce the amount of time that the primary
database must remain shut down. (Restore from the Backup)
c. Step 3 Restart the primary database.
a) Issue the following SQL*Plus statement to restart the primary database:
b) SQL> STARTUP;
3. Create a Control File for the Standby Database
a) On the primary database, create the control file for the standby database, as shown in the
following example:
b) SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS
'/disk1/oracle/DEV/standby/cntrl.ctl';
c) The filename for the newly created standby control file must be different from the filename of
the current control file of the primary database. The control file must also be created after the
last time stamp for the backup data files.
4. Prepare the Initialization Parameter File to be Copied to the Standby Database
SQL> CREATE PFILE=’/disk1/oracle/dev/standby/init<DEV>.ora’ FROM SPFILE;
5. Copy Files from the Primary System to the Standby System

a) Backup datafiles created in step 2


b) Standby control file created in step 3
c) Initialization parameter file created in step 4
6. Configure tnsnames.ora for the Standby Databases in Primary Database
stdby=
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = dcmprd)
(PORT = 1521)
)
)
(CONNECT_DATA =
(SERVICE = stdby.world)
)
)

Physical Standby Databases


A physical standby database is physically identical to the primary database, with on-disk database structures
that are identical to the primary database on a block-for-block basis. The database schema, including
indexes,
must be the same.
Data Guard maintains a physical standby database by performing managed recovery operations. When it is
not
performing recovery operations, a physical standby database can be open for read-only operations.
Managed recovery
The physical standby database is maintained by applying the archived redo logs on the standby system using
the Oracle recovery mechanism. The recovery operation applies changes block-for-block using the physical
row ID. The database cannot be opened for read or read/write operations while redo data is being applied.
Open read-only
The physical standby database can be open for read-only operations so that you can execute queries on the
database. While open for read-only operations, the standby database can continue to receive redo logs but
application of the data from the logs is deferred until the database resumes managed recovery operations.
Although the physical standby database cannot perform both managed recovery and read-only operations at
the same time, you can switch between them. For example, you can run a physical standby database to
perform managed recovery operations, then open it so applications can perform read-only operations to run
reports, and then change it back to perform managed recovery operations to apply outstanding archived redo
logs. You can repeat this cycle, alternating between managed recovery and read-only operations, as
necessary. In either case, the physical standby database is available to perform backup operations.
Furthermore, the physical standby database will continue to receive redo logs even if they are not being
applied at that moment.
Benefits of a Physical Standby Database
A physical standby database provides the following benefits:
􀂷
Disaster recovery and high availability
􀂷
Easy-to-manage switchover and failover capabilities allow easy role reversals between primary and physical
standbyA physical standby database enables a robust and efficient disaster recovery and high availability
solution.
SECONDARY DATABASE OPERATION
1. Set Initialization Parameters on a Physical Standby Database
*.control_files='/oracle/PRD/origlogA/cntrl/cntrlPRD.ctl','/oracle/PRD/sapdata1/system_/cntrl/cntrlPRD.ctl','
/oracle/PRD/s
aparch/cntrl/cntrlPRD.ctl'
*.core_dump_dest='/oracle/PRD/saptrace/background'
*.db_block_size=8192
*.db_cache_size=688820060
*.db_file_multiblock_read_count=8
*.db_files=254
*.db_name='PRD'
*.dml_locks=4000
*.enqueue_resources=8000
*.fast_start_mttr_target=900
*.hash_join_enabled=false
*.log_archive_dest_1='LOCATION=/oracle/PRD/oraarch MANDATORY REOPEN=30'
*.log_archive_dest_2='SERVICE=stdby LGWR SYNC AFFIRM'
*.log_archive_dest_state_1='enable'
*.log_archive_dest_state_2='enable'
*.log_archive_format='arc%t_%s.dbf'
*.log_archive_start=true
*.remote_archive_enable='true'
*.SERVICE_NAMES = stdby
*.FAL_SERVER=PRD
*.FAL_CLIENT=PRD
# Uncomment is filename conversion is needed
#DB_FILE_NAME_CONVERT=("/primary","/standby")
#LOG_FILE_NAME_CONVERT=("/primary","/standby")
*.STANDBY_ARCHIVE_DEST=/oracle/PRD/oraarch
*.LOG_ARCHIVE_TRACE=127
*.STANDBY_FILE_MANAGEMENT=auto
2. Configure Listeners on Standby Databases to listen to Primary Database
Add the Entry in Listener.ora for Production System
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = saprps)(PORT = 1527))
)
3. Enable Dead Connection Detection on the Standby System
Enable dead connection detection by setting the SQLNET.EXPIRE_TIME parameter to 2 in the
SQLNET.ORA
parameter file on the standby system. For example: SQLNET.EXPIRE_TIME=2
4. Create a Server Parameter File for the Standby Database
On an idle standby database, use the SQL CREATE statement to create a server parameter file for the
standby
database from the text initialization parameter file that was edited above in step 1
SQL> CREATE SPFILE FROM PFILE=’init<PRD>.ora’
5. Start the Physical Standby Database
On the standby database, issue the following SQL statements to start and mount the database in standby
mode:
SQL> STARTUP NOMOUNT;
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
6. Initiate Log Apply Services
On the standby database, start log apply services as shown in the following example:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM
SESSION;
The example includes the DISCONNECT FROM SESSION option so that log apply services run in
a background session
.7.Enable Archiving to the Physical Standby Database
To configure archive logging from the primary database to the standby site the LOG_ARCHIVE_DEST_n
and
LOG_ARCHIVE_DEST_STATE_n parameters must be defined.
The following example sets the initialization parameters needed to enable archive
logging to the standby site:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=stdby’ SCOPE=BOTH;
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;
8. Start Remote Archiving.
Archiving of redo logs to the remote standby location does not occur until after a log switch. A log switch
occurs, by default, when an online redo log becomes full. To force the current redo logs to be archived
immediately, use the SQL ALTERSYSTEM statement on the primary database.
For example:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
9. Verify the Standby Database Logging
On the standby database, query the V$ARCHIVED_LOG view to identify existing archived redo logs.
For example:
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY
SEQUENCE#;
SEQUENCE# FIRST_TIME NEXT_TIME
---------- ------------------ ------------------
101 17-oct-08 17:50:45 17-oct-08 17:50:53
102 17-oct-08 17:50:53 17-oct-08 17:50:58
103 17-oct-08 17:50:58 17-oct-08 17:51:03
3 rows selected
START-UP/SHUTDOWN AND SWITCHOVER
1. Starting Up a Physical Standby Database
To start up a physical standby database, use SQL*Plus to connect to the database with administrator
privileges, and then use the SQL*Plus STARTUP command with the NOMOUNT option. (You must use the
NOMOUNT option with a standby database.)
If both the primary and standby databases are offline, then always (if possible) start the standby
database before starting the primary database.
After the database is started, mount the database as a standby database. Once it is mounted, the
database can receive archived redo data from the primary database.
You then have the option of either starting a managed recovery operation or opening the database for
read-only access. Typically, you start a managed recovery operation. The following example shows how to
start a standby database:
1. Start the database:
SQL> STARTUP NOMOUNT;
2. Mount the standby database:
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
3. Start the managed recovery operation:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM
SESSION;
Once the database is performing managed recovery, log apply services apply the archived redo logs to the
standby database.
2. Shutting Down a Physical Standby Database
To shut down a physical standby database, use the SQL*Plus SHUTDOWN command. If the database is
performing managed recovery, you must cancel managed recovery operations before issuing the
SHUTDOWN
command. Control is not returned to the session that initiates a database shutdown until shutdown is
complete.
If the primary database is up and running, defer the archive log destination on the primary database and
perform a log switch operation (to make the defer operation take effect) before shutting down the standby
database. Otherwise, log transport services will not be able to transmit redo data to this standby site.
The following steps show you how to shut down a standby database:
1. Find out if the standby database is performing managed recovery. If the MRP0 or MRP process exists,
then
the standby database is performing managed recovery.
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
2. Cancel managed recovery operations.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Using a Standby Database That Is Open for Read-Only Access
Database
Managing a Physical Standby
3. Shut down the standby database.
SQL> SHUTDOWN IMMEDIATE;
3. Opening the Database in Read only Mode
To open a standby database for read-only access when it is currently shut down:
1. Start the Oracle instance for the standby database without mounting it:
SQL> STARTUP NOMOUNT;
2. Mount the standby database:
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
3. Open the database for read-only access:
SQL> ALTER DATABASE OPEN READ ONLY;
To open a standby database for read-only access when it is currently performing managed
recovery:
1. Cancel log apply services:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
2. Open the database for read-only access:
SQL> ALTER DATABASE OPEN READ ONLY;
To change the standby database from being open for read-only access to performing
managed recovery:
1. Terminate all active user sessions on the standby database.
2. Restart log apply services:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
2> DISCONNECT FROM SESSION;
ACTIVATE STANDBY DATABASE
This statement performs a forced failover operation, in which the primary database is removed from the Data
Guard environment and a standby database assumes the primary database role. The standby database must
be mounted before it can be activated with this statement. The SQL statement syntax is:
SQL> ALTER DATABASE ACTIVATE Physical STANDBY DATABASE
SQL> Alter Database open;
PRIMARY DATABASE SETUP