Creating a 10gr2 Data Guard Physical Standby database with Real-Time apply [ID 343424.1]

Creating a 10gr2 Data Guard Physical Standby database with Real-Time apply [ID 343424.1]
	Modified 14-OCT-2009Type BULLETINStatus PUBLISHED

In this Document
Purpose
Scope and Application
Creating a 10gr2 Data Guard Physical Standby database with Real-Time apply

---

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.5
Information in this document applies to any platform.

Purpose

This document has been created with step-by-step instructions on how to create a Data Guard Physical Standby configuration manually without the aid of the broker. All steps are derived from the 10GR2 documentation.

It is assumed that the reader is aware of the features of RDBMS such as SPFILE usage, storage such as ASM, OCFS. Please avail these features where appropriate and test them before implementing in production.

Scope and Application

This document should aid testers, dba's and support analyst's with step-by-step instructions and additional information has been provided as notes to elaborate or clarify a point. All steps shown here were tested on a linux platform, however the steps are generic enough for all flavours of unix.

Creating a 10gr2 Data Guard Physical Standby database with Real-Time apply

Primary host : rhclu1
Standby host : rhclu2
ORACLE_SID=v102p
Kernel :Linux x86 2.4.21-27.EL
Service names : Primary rhclu1p / Standby rhclu2p

Primary Initialization parameters
db_name='v102p'
db_unique_name=rhclu1p
##COMMON TO BOTH PRIMARY AND STANDBY ROLES
LOG_ARCHIVE_CONFIG='DG_CONFIG=(rhclu1p,rhclu2p)'
LOG_ARCHIVE_DEST_1='LOCATION=/u01/app/oracle/admin/v102p/arch
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=rhclu1p'
LOG_ARCHIVE_DEST_2='SERVICE=rhclu2p
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=rhclu2p'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_MAX_PROCESSES=2
log_archive_format='%t_%s_%r.dbf'
#SPECIFIC TO STANDBY ROLE
STANDBY_FILE_MANAGEMENT=AUTO
STANDBY_ARCHIVE_DEST='/u01/app/oracle/admin/v102p/arch'
FAL_SERVER=rhclu2p
FAL_CLIENT=rhclu1p

Standby Initialization parameters
db_name='v102p'
db_unique_name=rhclu2p
#COMMON TO BOTH PRIMARY AND STANDBY ROLES
LOG_ARCHIVE_CONFIG='DG_CONFIG=(rhclu1p,rhclu2p)'
LOG_ARCHIVE_DEST_1='LOCATION=/u01/app/oracle/admin/v102p/arch
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=rhclu2p'
LOG_ARCHIVE_DEST_2='SERVICE=rhclu1p LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=rhclu1p'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_MAX_PROCESSES=2
log_archive_format='%t_%s_%r.dbf'
#SPECIFIC TO STANDBY ROLE
STANDBY_FILE_MANAGEMENT=AUTO
STANDBY_ARCHIVE_DEST='/u01/app/oracle/admin/v102p/arch'
FAL_SERVER=rhclu1p
FAL_CLIENT=rhclu2p

Note 1:
- Create just one initialization parameter file that contains parameters used in both Roles (primary / standby)
Parameters specific to that role will be used eg: FAL_ parameter will be used only when the database is in standby role
For Log_archive_dest_n the VALID_FOR attribute will differentiate the roles, if not specified the default is(ALL_LOGFILES,ALL_ROLES). This VALID_FOR attribute allows us to use the same initialization parameter file for both the primary and standby roles.

Note 2:
- Since the file structure is the same on both the nodes I have not specifed the file name convert strings.
If the file structure is different then we will need to specify the additional two parameters :
DB_FILE_NAME_CONVERT - Converts the path names of the primary database data files to the standby data file pathnames
LOG_FILE_NAME_CONVERT - Converts the path names of the primary database log files to the path names on the standby database

Example :
string1 is the pattern of the primary database filename /u01/prim/
string2 is the pattern of the standby database filename /u01/stdby/
string3 is the pattern of the primary database filename /u02/prim/
string4 is the pattern of the standby database filename /u02/stdby/

DB_FILE_NAME_CONVERT = 'string1' , 'string2' , 'string3' , 'string4' , ...
= ‘/u01/prim/’,’/u01/stdby, ‘/u02/prim/’,’/u02/stdby’

LOG_FILE_NAME_CONVERT = 'string1' , 'string2' , 'string3' , 'string4' , ...
= ‘/u01/prim/’,’/u01/stdby, ‘/u02/prim/’,’/u02/stdby’

Enable Archiving :
Ensure that the primary is in archive log mode
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;

Note 3:

- LOG_ARCHIVE_START = TRUE has been deprecated since 10gr1

Net Services :

Set up the net services as entries in the tnsnames.ora such a way that you can sqlplus to the remote database using this alias.

Eg: from the primary

sqlplus sys/<password>@rhclu2p as sysdba

SQL>SELECT DB_UNIQUE_NAME FROM V$DATABASE;

DB_UNIQUE_NAME
--------------------------
rhclu2p

Do the same from the standby to the primary.

TNSNAMES.ORA sample

- The ip addresses are dummy in this context use the appropriate ip / hostname.

RHCLU1P =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.103)(PORT = 1521)))
(CONNECT_DATA =
(SERVER = DEDICATED) (SERVICE_NAME = v10g))
)

RHCLU2P =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.104)(PORT = 1521)))
(CONNECT_DATA =
(SERVER = DEDICATED) (SERVICE_NAME = v10g))

)

Standby Redo Log (SRL) creation :

SQL>SELECT * FROM V$LOGFILE;

GROUP# STATUS TYPE MEMBER IS_RECOVERY_DEST_FILE
------ ------- ------- ----------------------------------------------------------------------------
1 ONLINE /u01/app/oracle/admin/v102p/redo01.log NO
2 ONLINE /u01/app/oracle/admin/v102p/redo02.log NO
3 ONLINE /u01/app/oracle/admin/v102p/redo03.log NO

SQL>SELECT BYTES FROM V$LOG;

BYTES
======
10485760
10485760
10485760

Create the SRL's :

SQL>ALTER DATABASE ADD STANDBY LOGFILE GROUP 4
('/u01/app/oracle/admin/v102p/srl01.log') SIZE 10M;

SQL>ALTER DATABASE ADD STANDBY LOGFILE GROUP 5
('/u01/app/oracle/admin/v102p/srl02.log') SIZE 10M;

SQL>ALTER DATABASE ADD STANDBY LOGFILE GROUP 6
('/u01/app/oracle/admin/v102p/srl03.log') SIZE 10M;

Backup the Primary

Take a cold backup of the primary. ( You can also take a hot backup or oracle recommends the usage of RMAN.)

SQL>SHUTDOWN IMMEDIATE

- Backup the datafiles, online redologs and the standby logs if created and ftp / restore it on the standby site;

Note 4:
- Standby redo logs can be created even after the standby has been created. In this case we created the SRL's on the primary before the creation of the standby database. Also, we have used the default ARCH to ship the logs across in the log_archive_dest_2 parameter. In 10g the archiver (ARCn) process or the log writer (LGWR) process on the primary database can transmit redo data directly to remote standby redo logs.

-MAXLOGFILEdefaults to 16,To create online redologs + standby redologs more than this ensure that you recreate the control file to modify maxlogfile to accomodate this number.


Create the standby controlfile :

Primary :

SQL>STARTUP MOUNT;
SQL>ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/stdby.ctl';
SQL>ALTER DATABASE OPEN;

- ftp / scp the stdby.ctl file to the standby site. we can multiplex this by making copies of this stdby.ctl on different mountpoints on the standby and editing the control_files parameter in the init.ora to reflect this.
- Copy the orapw<sid>.ora file from the OH/dbs directory of the primary to the same location on the standby.

Starting the standby :

SQL>STARTUP MOUNT
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Verify the Standby :

- Identify the existing files on the standby

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME
FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

.......................
.......................
115 29-NOV-05 29-NOV-05
116 29-NOV-05 29-NOV-05

- Switch a log on the primary

SQL>ALTER SYSTEM SWITCH LOGFILE;

- Run the above sql again on the standby to see the new log that has arrived from the primary.

.......................
.......................
115 29-NOV-05 29-NOV-05
116 29-NOV-05 29-NOV-05
117 29-NOV-05 29-NOV-05

Verify that these logs were applied :

SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG
ORDER BY SEQUENCE#;

...........
115 YES
116 YES
117 YES

- Standby Set up is complete.

Note 5: ARCH processing :
- In our setup so far we have used the arch process for log_archive_dest_2 ( if nothing is specified then default is arch ) and SRL's are created on the standby;
- Archiving happens when there is a log switch on the primary.
- On the primary database, after the ARC0 process successfully archives the local online redo log to the local destination (LOG_ARCHIVE_DEST_1), the ARC1 process transmits redo from the local archived redo log files (instead of the online redo log files) to the remote standby destination (LOG_ARCHIVE_DEST_2).
- On the remote destination, the remote file server process (RFS) will, in turn, write the redo data to an archived redo log file from a standby redo log file. Log apply services use Redo Apply ( MRP ) to apply the redo to the standby database.

Real-time apply :

When real-time apply is enabled, the log apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archived.

In this example we are going to use LGWRon the primary for redo transport just to prove that a committed record on the primary without switching a log will show up on the standby. However real-time apply will work with both LGWR and ARCH using SRL's.

- Set up log_archive_dest_2 on the primary with LGWR ASYNC or SYNC

log_archive_dest_2='SERVICE=rhclu2p LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=rhclu2p'

- shutdown and startup the primary or if done dynamically switch a log file
- You will see the following message in the alert log
****************************************************************
LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
*****************************************************************

- On the standby cancel out of the current managed recovery

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

- Place it back in recovery with Real time apply

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT
LOGFILE DISCONNECT;

Test Real time apply :

Primary : create a table 'test' and insert a record.

SQL>INSERT INTO test VALUES ( 101, 'testing');
SQL>COMMIT;

Do not switch a log

On the standby :

SQL>SELECT PROCESS, STATUS,SEQUENCE#,BLOCK#,BLOCKS, DELAY_MINS FROM
V$MANAGED_STANDBY;

Notice the block# for the RFS and MRP0 increasing
Cancel out of real time apply and open it in read only mode

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL>ALTER DATABASE OPEN READ ONLY;
SQL>SELECT * FROM.test;

You will see the committed record.

Place the standby back in managed recover mode

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT
LOGFILE DISCONNECT;
( This will take the standby directly from read only mode and place it in managed recovery mode )

Note 6:

- There is no requirement that the standby recovery once started in real-time apply should only be run in this mode. We can go between the two modes as desired, but only one recovery can occur at a given time. please refer the Online documentation for the details of the Syntax.

---

---------------------------------------------------------------------------------------------------

Blog： http://blog.csdn.net/tianlesoftware

网上资源： http://tianlesoftware.download.csdn.net

相关视频：http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx

DBA1 群：62697716(满); DBA2 群：62697977(满) DBA3 群：62697850(满)

DBA 超级群：63306533(满); DBA4 群： 83829929 DBA5群： 142216823

聊天 群：40132017

--加群需要在备注说明Oracle表空间和数据文件的关系，否则拒绝申请