Physical Standby Setup

Systems & Databases Administrator (2014) | Physical Standby Setup |
pg. 1

Data Guard Physical Standby Setup in Oracle Database 11g Release 2

Primary Server Setup
Logging
Initialization Parameters
Service Setup
Backup Primary Database
Create Standby Controlfile and PFILE
Standby Server Setup (Manual)
Copy Files
Start Listener
Restore Backup
Create Redo Logs
Standby Server Setup (DUPLICATE)
Copy Files
Start Listener
Create Standby Redo Logs on Primary Server
Create Standby using DUPLICATE
Start Apply Process
--Test Log Transport
--Protection Mode
--Database Switchover
--Failover
--Flashback Database
--Read-Only Standby and Active Data Guard
--Snapshot Standby

Assumptions
You have two servers (physical or VMs) with an OS and Oracle installed on them.
The primary server has a running instance.
The standby server has a software only installation.
The Standby/Duplicate database is being created on a separate server, using the
same SID

Database Name: TZDB
Primary db_unique_name: TZDB
Standby db_unique_name: TZDR
Primary Database Server Name: DB01 {10.140.40.24}
Standby Database Server Name: DB02 {10.140.40.40}

Primary Server Setup (10.140.40.24)
Check that the primary database is in archivelog mode.
SQL>SELECT STATUS FROM V$INSTANCE;
SQL>SELECT LOG_MODE FROM V$DATABASE;
SQL> ARCHIVE LOG LIST;

If it is in noarchivelog mode, switch is to archivelog mode.
pg. 2

SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP MOUNT;
SQL>ALTER DATABASE ARCHIVELOG;
SQL>ALTER DATABASE OPEN;

Enabled forced logging by issuing the following command.
SQL>SELECT FORCE_LOGGING FROM V$DATABASE;
SQL>ALTER DATABASE FORCE LOGGING;

Initialization Parameters
Check the setting for the DB_NAME and DB_UNIQUE_NAME parameters.
SQL> SHOW PARAMETER DB_NAME
SQL> SHOW PARAMETER DB_UNIQUE_NAME

If the databases (Primary and Standby) are on the same machine, then you must
use different SID name, but if they are on different machine, you may use same SID
name.

The DB_NAME of the standby database will be the same as that of the primary, but it must
have a different DB_UNIQUE_NAME value. The DB_UNIQUE_NAME values of the primary and
standby database should be used in the DG_CONFIG setting of the LOG_ARCHIVE_CONFIG
parameter. For this example, the standby database will have the value "TZDR".

SQL>SELECT * FROM v$dataguard_config;
SQL>ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(TZDB,TZDR)';

Set suitable remote archive log destinations.
In this case I'm using the flash recovery area for the local location, but you could specify a
location explicitly if you prefer. Notice the SERVICE and the DB_UNIQUE_NAME for the remote
location reference the standby location.

SQL>SELECT * FROM v$archive_dest;
SQL>ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=TZDR NOAFFIRM ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=TZDR';

SQL>ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

The LOG_ARCHIVE_FORMAT and LOG_ARCHIVE_MAX_PROCESSES parameters must be set to
appropriate values and the REMOTE_LOGIN_PASSWORDFILE must be set to exclusive.

SQL>ALTER SYSTEM SET LOG_ARCHIVE_FORMAT='%t_%s_%r.arc' SCOPE=SPFILE;
SQL>ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=30;
SQL>ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;

In addition to the previous setting, it is recommended to make sure the primary is ready to
switch roles to become a standby. For that to work properly we need to set the following
parameters.

pg. 3

SQL>ALTER SYSTEM SET FAL_SERVER=TZDR;
--- SQL>ALTER SYSTEM SET DB_FILE_NAME_CONVERT='TZDR','TZDB' SCOPE=SPFILE;
--- SQL>ALTER SYSTEM SET LOG_FILE_NAME_CONVERT='TZDR',TZDB SCOPE=SPFILE;
SQL>ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

Set FILE_NAME_CONVERT parameter incase if directory structure is different in primary and
standby databases. Adjust the *_CONVERT parameters to account for your filename and path
differences between the servers.

Some of the parameters are not modifiable, so the database may need to be
restarted before they take effect.

Service Setup
Entries for the primary and standby databases are needed in the
"$ORACLE_HOME/network/admin/tnsnames.ora" files on both servers. You can create
these using the Network Configuration Utility (netca) or manually.

tnsnames.ora >>>> (for both primary and standby databases)
TZDB =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.140.40.24)(PORT = 1521))
)
(CONNECT_DATA =
(SID = TZDB)
(SERVICE_NAME = TZDB)
)
)

TZDR =
(DESCRIPTION =
(ADDRESS_LIST =
)
(CONNECT_DATA =
(SID = TZDB)
(SERVICE_NAME = TZDB)
)
)

listener.ora >>>> (for both primary and standby databases)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = TZDB)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
(SID_NAME = TZDB)
)
)

LISTENER =
pg. 4

(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)

ADR_BASE_LISTENER = /u01/app/oracle

Backup Primary Database
If you are planning to use an active duplicate to create the standby database, then this step
is unnecessary. For a backup-based duplicate/manual restore, take a backup of the primary
database.

$ rman target=/
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

a. Create Standby Controlfile and PFILE
Create a controlfile for the standby db by issuing the following command on the primary
db.
SQL>ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/TZDR.ctl';

b. Create a parameter file for the standby database.
CREATE PFILE='/tmp/initTZDR.ora' FROM SPFILE;

Amend the PFILE created, making the entries relevant for the standby database. I'm making
a replica of the original server, so in my case I only had to amend the following parameters.
i. Change db_unique_name ii. Change fal_server iii. Change log_archive_dest_n

Modify initTZDR.ora file
$ vi /tmp/initTZDR.ora
*.db_unique_name='TZDR'
*.fal_server='TZDB'
*.log_archive_dest_2='SERVICE=TZDB ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=TZDB'

Standby Server Setup (Manual)
The destination server requires static listener configuration in a "listener.ora" file. In this
case I used the following configuration. Remember to restart or reload the listener.

listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = TZDB)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
(SID_NAME = TZDB)
)
pg. 5

)

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)

ADR_BASE_LISTENER = /u01/app/oracle

Create the necessary directories on the standby server.
$mkdir -p /u01/app/oracle/oradata/TZDB
$mkdir -p /u01/app/oracle/flash_recovery_area/TZDB
$mkdir -p /u01/app/oracle/admin/TZDB/adump

Copy the files from the primary to the standby server.
Standby controlfile to all locations.
$scp -r oracle@10.140.40.24:/tmp/TZDR.ctl /u01/app/oracle/oradata/TZDB/control01.ctl
$cp /u01/app/oracle/oradata/TZDB/control01.ctl
/u01/app/oracle/flash_recovery_area/TZDB/control02.ctl

Archivelogs and backups
$scp -r oracle@10.140.40.24:/u01/app/oracle/flash_recovery_area/TZDB/archivelog
/u01/app/oracle/flash_recovery_area/TZDB
$scp -r oracle@10.140.40.24:/u01/app/oracle/flash_recovery_area/TZDB/backupset
/u01/app/oracle/flash_recovery_area/TZDB

Parameter file.
$scp oracle@10.140.40.24:/tmp/initTZDR.ora /tmp/initTZDR.ora

Remote login password file.
$scp oracle@10.140.40.24:$ORACLE_HOME/dbs/orapwTZDB $ORACLE_HOME/dbs
SQL> select * from v$pwfile_users;

Notice, the backups were copied across to the standby server as part of the FRA copy. If
your backups are not held within the FRA, you must make sure you copy them to the
standby server and make them available from the same path as used on the primary server.

Start Listener
Make sure the listener is started on the standby server.
$lsnrctl start

update oratab file
vi /var/opt/oracle/oratab .for Solaris 11 or vi /etc/oratab RedHat based OS, add this line
TZDB:/u01/app/oracle/product/11.2.0/db_1:Y
pg. 6

SQL>oraenv ----just to be sure you are connected to TZDB instance
ORACLE_SID = [TZDB] ?

Restore Backup
Create the SPFILE form the amended PFILE.

$ export ORACLE_SID=TZDB
$ sqlplus / as sysdba -----(if logged in as the Oracle software owner)
SQL> CREATE SPFILE FROM PFILE='/tmp/initTZDR.ora';

Restore the backup files.
$ rman target=/
RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE;

Create Redo Logs
Find the size and details of the log files in the primary database, Create online redo logs for
the standby. It's a good idea to match the configuration of the primary server.
SQL> SELECT GROUP#, BYTES FROM V$LOG;
SQL> SELECT GROUP, TYPE, MEMBER FROM V$LOGFILE;

SELECT GROUP#, SEQUENCE#, BYTES, ARCHIVED, STATUS FROM V$LOG
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;
ALTER DATABASE ADD LOGFILE ('/u01/app/oracle/oradata/TZDB/online_redo01.log') SIZE 150M;
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

In addition to the online redo logs, you should create standby redo logs on both the
standby and the primary database (in case of switchovers). The standby redo logs should
be at least as big as the largest online redo log and there should be one extra group per
thread compared the online redo logs. In my case, the following is standby redo logs must
be created on both servers.

ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oracle/oradata/TZDB/standby_redo01.log') SIZE
150M;
150M;
150M;
*******************Once this is complete, we can start the apply process*********************

Standby Server Setup (DUPLICATE)
The article assumes the duplicate database is being created on a separate server, using the
same SID (TZDB) and the same file structure as the source database

pg. 7

Create the necessary directories on the standby server.
$mkdir -p /u01/app/oracle/oradata/TZDB
$mkdir -p /u01/app/oracle/flash_recovery_area/TZDB
$mkdir -p /u01/app/oracle/admin/TZDB/adump

Standby controlfile to all locations.
$ scp oracle@10.140.40.24:/tmp/TZDR.ctl /u01/app/oracle/oradata/TZDB/control01.ctl
$ cp /u01/app/oracle/oradata/TZDB/control01.ctl
/u01/app/oracle/flash_recovery_area/TZDB/control02.ctl

Parameter file.
$ scp oracle@10.140.40.24:/tmp/initTZDR.ora /tmp/initTZDR.ora

Remote login password file.
$ scp oracle@10.140.40.24:$ORACLE_HOME/dbs/orapwTZDB $ORACLE_HOME/dbs

Start Listener
$ lsnrctl start

Create Standby Redo Logs on Primary Server
The DUPLICATE command automatically creates the standby redo logs on the standby. To
make sure the primary database is configured for switchover, we must create the standby
redo logs on the primary server. Perform the following query on a redo source database to
determine the size of each log file and the number of log groups in the redo log:

SQL> SELECT GROUP#, BYTES FROM V$LOG;
SQL> SELECT MEMBER FROM V$LOGFILE;
SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;

150M;
150M;
150M;

Create an Online Redo Log on the Standby Database
Although this step is optional, Oracle recommends that an online redo log be created
when a standby database is created. By following this best practice, a standby database will
be ready to quickly transition to the primary database role.

SELECT GROUP#, SEQUENCE#, BYTES, ARCHIVED, STATUS FROM V$LOG
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
pg. 8

The size and number of redo log groups in the online redo log of a standby database
should be chosen so that the standby database performs well if it transitions to the primary
role.

Create Standby Using DUPLICATE
Start the auxillary instance on the standby server by starting it using the temporary
"init.ora" file.
$ sqlplus / as sysdba
SQL> STARTUP NOMOUNT PFILE='/tmp/initTZDR.ora';

Connect to RMAN, specifying a full connect string for both the TARGET and AUXILLARY
instances.
$ rman TARGET sys/password@TZDB AUXILIARY sys/password@TZDR
$ rman TARGET / AUXILIARY sys/Oracle11gR2@TZDR
rman TARGET / AUXILIARY sys/Oracle11gR2@TZDR
connected to target database: TZDB (DBID=4061336827)
connected to auxiliary database: TZDB (not mounted)

Now issue the following DUPLICATE command.
DUPLICATE TARGET DATABASE
FOR STANDBY
FROM ACTIVE DATABASE
DORECOVER
SPFILE
SET db_unique_name='TZDR' COMMENT 'Is standby'
SET LOG_ARCHIVE_DEST_2='SERVICE=TZDB ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=TZDB'
SET FAL_SERVER='TZDB' COMMENT 'Is primary'
NOFILENAMECHECK;

A brief explanation of the individual clauses is shown below.
FOR STANDBY: This tells the DUPLICATE command is to be used for a standby, so it will not
force a DBID change.

FROM ACTIVE DATABASE: The DUPLICATE will be created directly from the source datafile,
without an additional backup step.

DORECOVER: The DUPLICATE will include the recovery step, bringing the standby up to the
current point in time.

SPFILE: Allows us to reset values in the spfile when it is copied from the source server.

NOFILENAMECHECK: Destination file locations are not checked.
Once the command is complete, we can start the apply process.

--Start the Apply Process on Standby Server.
pg. 9

Once the duplication is completed, close the RMAN prompt and connect to the standby
database through SQL. Check the status of the standby database by making sure it is in
mount stage.
SQL>SELECT STATUS, INSTANCE_NAME, DATABASE_ROLE FROM V$INSTANCE,V$DATABASE;

You can specify that Redo Apply runs as a foreground session or as a background process,
and enable it with real-time apply.

To start Redo Apply in the foreground, issue the following SQL statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
If you start a foreground session, control is not returned to the command prompt until
recovery is canceled by another session.

To start Redo Apply in the background, include the DISCONNECT keyword on the
SQL statement.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

This statement starts a detached server process and immediately returns control to the
user. While the managed recovery process is performing recovery in the background, the
foreground process that issued the RECOVER statement can continue performing other
tasks. This does not disconnect the current SQL session.

To start real-time apply, provided you have configured standby redo logs, include the
USING CURRENT LOGFILE clause on the SQL statement.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

Stopping Redo Apply
To stop Redo Apply, issue the following SQL statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

If you prefer, you can set a delay between the arrival of the archived redo log and it being
applied on the standby server using the following commands.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 30 DISCONNECT FROM SESSION;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY DISCONNECT FROM SESSION;

--Test Log Transport (Verify the Physical Standby Database Is Performing Properly)
Once you create the physical standby database and set up redo transport services, you may
want to verify database modifications are being successfully transmitted from the primary
database to the standby database.
a. Identify the existing archived redo log files.
On the standby database, query the V$ARCHIVED_LOG view to identify existing files in the
archived redo log.

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

b. Force a log switch to archive the current online redo log file.
On the primary database, issue the ALTER SYSTEM SWITCH LOGFILE statement to force a log
switch and archive the current online redo log file group.

ALTER SESSION SET nls_date_format='DD-MON-YYYY HH24:MI:SS';
ALTER SYSTEM SWITCH LOGFILE;

c. Verify the new redo data was archived on the standby database.
On the standby database, query the V$ARCHIVED_LOG view to verify the redo data was
received and archived on the standby database
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

d. Verify that received redo has been applied.
On the standby database, query the V$ARCHIVED_LOG view to verify that received redo has
been applied:

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

--Read-Only Standby and Active Data Guard
Once a standby database is configured, it can be opened in read-only mode to allow query
access. This is often used to offload reporting to the standby server, thereby freeing up
resources on the primary server. When open in read-only mode, archive log shipping
continues, but managed recovery is stopped, so the standby database becomes
increasingly out of date until managed recovery is resumed.

To switch the standby database into read-only mode, do the following.
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN READ ONLY;

To resume managed recovery, do the following.
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

In 11g, Oracle introduced the Active Data Guard feature. This allows the standby database
to be open in read-only mode, but still apply redo information. This means a standby can
be available for querying, yet still be up to date. There are licensing implications for this
feature, but the following commands show how active data guard can be enabled.

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Since managed recovery continues with active data guard, there is no need to switch back
to managed recovery from read-only mode in this case.
pg. 11

--Protection Mode
There are three protection modes for the primary database
i. Maximum Availability
Transactions on the primary do not commit until redo information has been written to the
online redo log and the standby redo logs of at least one standby location. If no standby
location is available, it acts in the same manner as maximum performance mode until a
standby becomes available again.

ii. Maximum Performance
Transactions on the primary commit as soon as redo information has been written to the
online redo log. Transfer of redo information to the standby server is asynchronous, so it
does not impact on performance of the primary. By default, for a newly created standby
database, the primary database is in maximum performance mode.
SELECT PROTECTION_MODE FROM V$DATABASE;

iii. Maximum Protection
Transactions on the primary do not commit until redo information has been written to the
online redo log and the standby redo logs of at least one standby location. If not suitable
standby location is available, the primary database shuts down.

The mode can be switched using the following commands. Note the alterations in the redo
transport attributes.

-- Maximum Availability.
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=TZDR AFFIRM SYNC
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

-- Maximum Performance.
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=TZDR NOAFFIRM ASYNC
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

-- Maximum Protection.
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=TZDR AFFIRM SYNC
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
ALTER DATABASE OPEN;

Physical Standby Setup

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

Physical Standby Setup

Uploaded by

Copyright:

Available Formats

Systems & Databases Administrator (2014) | Physical Standby Setup |

You might also like