Oracle Standby configuration with database 11g release 2

Table of Contents
Configuration of Oracle Physical standby ................................................................................................ 3
Oracle Database Enterprise Edition Requirement .............................................................................. 3
Hardware Configuration of the oracle data guard .............................................................................. 3
Primary Database .............................................................................................................................. 3
Physical Standby Database: .............................................................................................................. 4
Configuration of Physical Database:..................................................................................................... 4
Enable Archiving: .............................................................................................................................. 4
Enable force logging: ......................................................................................................................... 5
Enable Login with password file: ..................................................................................................... 5
Configuration of initialization parameters: ..................................................................................... 6
Standby file management ................................................................................................................. 9
Create standby redo log files: ......................................................................................................... 10
Create a full backup of the primary database and the control file: .............................................. 11
Prepare initialization file for the standby database: ..................................................................... 11
Transfer the backup set and pfile created to the standby host: ................................................... 11
Configuration of Standby Network Components: ............................................................................. 12
Oracle Net alias on primary database: ........................................................................................... 12
Oracle net alias on standby database: ............................................................................................ 13
Configure the listener of primary database: .................................................................................. 14
Configure the listener of standby database: .................................................................................. 15
Configure the standby database: ........................................................................................................ 16
Configure the password file: ........................................................................................................... 16
Create spfile form the previously configured pfile: ....................................................................... 16
Create and start Standby Instance: ................................................................................................ 16
Start redo apply for the standby database: .................................................................................... 17
Start Remote Archiving: ...................................................................................................................... 17
Verify the physical standby configuration is valid: ........................................................................... 18
Test Redo Transport: ...................................................................................................................... 18
Test redo apply: ............................................................................................................................... 18
Some useful dynamic views for Trouble shooting: ....................................................................... 19
Configuration of Oracle Physical standby
Oracle Data Guard (known as Oracle Standby Database prior to Oracle9i), forms an
extension to the Oracle RDBMS and provides organizations with high availability, data
protection, and disaster recovery for enterprise databases. Oracle Data Guard provides the
DBA with services for creating, maintaining, managing, and monitoring one or more
standby databases. The functionality included with Oracle Data Guard enables enterprise
data systems to survive both data corruption as well as major disasters .

Oracle Database Enterprise Edition Requirement

Oracle Data Guard is only available as a bundled feature included within its Enterprise
Edition release of the Oracle Database software. It is not available with Oracle Database
Standard Edition. With the exception of performing a rolling database upgrade using logical
standby database, it is mandatory that the same release of Oracle Database Enterprise
Edition be installed on the primary database and all standby databases!

Hardware Configuration of the oracle data guard

Primary Database

Parameters Description

Oracle Release Oracle 11g Release 2 — (11.2.0.3)

Host Name orahost.oracle.com — (192.168.1.200)

Operating System Oracle Enterprise Linux (5.5)

Database Name (db_name) ora11g

Database Domain (db_domain) oracle.com

Global database name ora11g.oracle.com

Oracle SID ora11g

Database Unique Name ora11g

Service Names ora11g.oracle.com, ora11g

Database Files /storage

Fast Recovery Area /recovery

Ram 1GB

HDD 35 GB
Physical Standby Database:

Parameters Description

Oracle Release Oracle 11g Release 2 — (11.2)

Host Name standby.oracle.com — (192.168.1.201)

Operating System Oracle Enterprise Linux (5.5)

Database Name (db_name) ora11g

Database Domain (db_domain) oracle.com

Global database name ostandby.oracle.com

Oracle SID orastandby

Database Unique Name orastandby

Service Names orastandby.oracle.com, orastandby

Database Files /storage

Fast Recovery Area /recovery

RAM 1 GB

HDD 35 GB

Configuration of Physical Database:

The steps required for Configuration of oracle standby database are:

Enable Archiving:
Oracle Data Guard relies on redo from the primary database in order to maintain the standby. This
requires the primary database be placed into archivelog mode. So check the database is checked if it
is in archive log mode or not by issuing following command.
SQL> archive log list
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 3
Current log sequence

As the database is not in archive log mode it was changed to archive log mode as:
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 609624064 bytes

Fixed Size 2255672 bytes
Variable Size 419431624 bytes
Database Buffers 184549376 bytes
Redo Buffers 3387392 bytes
Database mounted.

SQL> alter database archivelog;

Database altered.

And the database was opened.

Enable force logging:

Any nologging operations performed on the primary database do not get fully logged within the
redo stream. As Oracle Data Guard relies on the redo stream to maintain the standby database, this
can result in data inconsistencies between the primary and standby along with a massive headache
for the DBA to resolve. To prevent this from occurring, one solution is to place the primary database
into force logging mode. In this mode, all nologging operations are permitted to run without error,
however, the changes will be placed in the redo stream anyway. So we issued the following
command to enable force logging in the primary database using the following command:
SQL> alter database force logging;
Database altered.

SQL> select force_logging from v$database;

FOR
---
YES

Before making the critical decision to enable or not to enable force logging, you should be aware
that:
 Temporary tablespaces and temporary segments are never logged
 If you enable force logging on the primary database while the database is open, force
logging will not be enabled until all of the current nologging activities are complete

Enable Login with password file:

As part of the new redo transport security and authentication features, it is now mandatory that
each database in an Oracle Data Guard configuration utilize a password file . In addition , the
SYS password must be identical on every database in order for redo transport to function . If a
password file does note exists for the primary database, the parameter file is created using the
command orapwd command utility. Check the remote login parameter for the primary database as:
SQL> show parameter remote_login
NAME TYPE VALUE
-------------------------- ----------- -------------------------
remote_login_passwordfile string EXCLUSIVE
If the password file exits and remote login is exclusive then proceed ahead otherwise create
password file and set parameter remote_login_passwordfile to exclusive.

Configuration of initialization parameters:

As the oracle datagurad is all about configuring initialization parameters. The parameters that are
configured. As some parameters can be altered dynamically while some parameters needs to
bounce the database to put into effect and the configured parameters are:
SQL> show parameter db_name;
NAME TYPE VALUE
------------------------------------ ----------- ----------------
db_name string ora11g

SQL> show parameter db_unique_name

NAME TYPE VALUE
------------------------------------ ----------- ----------------
db_unique_name string ora11g
NOTE:
This parameter defines the unique name for a database. Since the DB_NAME parameter name must
be same on all standby databases DB_UNIQUE_NAME parameter was introduced to identify the each
databases in data guard configuration. The DB_UNIQUE_NAME parameter is limited to 30 characters.
It can contain alphanumeric, underscore (_), dollar ($), and pound (#) characters but must begin
with an alphabetic character. This parameter is static, so it requires bouncing the database in order
to change this parameter. If this parameter is not set explicitly, its value will be the same as that of
the DB_NAME parameter.

SQL> show parameter background_dump_dest

NAME TYPE VALUE
--------------------- ----------- ------------------------------
background_dump_dest string /u01/app/oracle/diag/rdbms/ora
11g/ora11g/trace

SQL> show parameter audit_file_dest

NAME TYPE VALUE
--------------------- ----------- ------------------------------
audit_file_dest string /u01/app/oracle/admin/ora11g/a
dump

SQL> show parameter core_dump_dest

NAME TYPE VALUE
--------------------- ----------- ------------------------------
core_dump_dest string /u01/app/oracle/diag/rdbms/ora
11g/ora11g/cdump

SQL> show parameter user_dump_dest

NAME TYPE VALUE
--------------------- ----------- ------------------------------
user_dump_dest string /u01/app/oracle/diag/rdbms/ora
11g/ora11g/trace
SQL> show parameter archive_lag_target
NAME TYPE VALUE
--------------------- ----------- ------------------------------
archive_lag_target integer 0

SQL> show parameter compatible

NAME TYPE VALUE
--------------------- ----------- ------------------------------
compatible string 11.2.0.4.0

SQL> show parameter control_files;

NAME TYPE VALUE
--------------------- ----------- ------------------------------
control_files string /storage/ora11g/control01.ctl,
/recovery/ora11g/control02.ctl

SQL> show parameter db_create_file_dest

NAME TYPE VALUE
--------------------- ----------- ------------------------------
db_create_file_dest string

SQL> show parameter db_recovery_file_dest

NAME TYPE VALUE
--------------------------------- ----------- ------------------
db_recovery_file_dest string /recovery
db_recovery_file_dest_size big integer 4500M

SQL> show parameters dispatchers

NAME TYPE VALUE
--------------- ----------- ------------------------------
dispatchers string (PROTOCOL=TCP) (SERVICE=ora11g
XDB)
max_dispatchers integer

SQL> show parameter instance_name

NAME TYPE VALUE
---------------- ----------- ------------------------------
instance_name string ora11g

SQL> show parameter log_archive_config

NAME TYPE VALUE
------------------- ----------- ------------------------------
log_archive_config string

Start Configuring Dynamic parameters:

SQL> alter system set
log_archive_config='dg_config=(ora11g,orastandby)';
System altered.
NOTE:
This consist unique name of databases who are the candidates of the standby configuration.

SQL> alter system set log_archive_max_processes=8;

System altered.

SQL> alter system set

log_archive_dest_1='location=use_db_recovery_file_dest
valid_for=(all_logfiles,all_roles) db_unique_name=ora11g';
System altered.

NOTE:
The destinations from LOG_ARCHIVE_DEST_1 through LOG_ARCHIVE_DEST_10 can contain either the
LOCATION or SERVICE attribute, while destinations from LOG_ARCHIVE_ DEST_11 through
LOG_ARCHIVE_DEST_31 can contain only the SERVICE attribute, which does not support the LOCAL
destination. For the LOCAL destination, you can specify a disk location or FRA. When specifying the
SERVICE attribute, a valid Oracle Net Service name that identifies the remote Oracle database
instance is used, where the redo data will be sent.
e.g. alter system set log_archive_dest_1='LOCATION=/u01/app/oracle/ oraarch';
alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_ DEST';

SQL> alter system set

log_archive_dest_2='service=orastandby.oracle.com
valid_for=(online_logfiles, primary_role) db_unique_name=orastandby';
System altered.

SQL> alter system set log_archive_dest_state_1='enable';

System altered.

SQL> alter system set log_archive_dest_state_2='defer';

System altered.
(It is better to defer the log archive for standby databases)

SQL> alter system set fal_server='ora11g','orastandby';

System altered.
NOTE:
This parameter specifies from where the standby database should request missing archived logs if
there is a gap in the logs. It is used only when the database is in the standby role and has a gap in
the received archived logs. A redo gap occurs when the redo transport doesn't run for a while. A
maintenance operation on the standby server or a network interruption may cause this. Setting this
parameter allows the standby to find the missing redo and have it transported. The contents are net
service name.
SQL> alter system set fal_client='ora11g';
System altered.

SQL> alter system set standby_file_management='auto';

System altered.
NOTE:
The STANDBY_FILE_MANAGEMENT parameter is used only for the environment of the physical
standby databases. By default, its value is MANUAL. By setting this parameter to AUTO, we'll make
sure that, when we add or drop datafiles on our primary database, those files are also added or
dropped on the standby database. Setting this parameter to AUTO can cause files to be created
automatically on the standby database and it can even overwrite existing files; we should be careful
when we set both DB_FILE_NAME_CONVERT and STANDBY_ FILE_MANAGEMENT and ensure that the
existing datafiles on standby won't be overwritten.

Parameters that cannot be changed dynamically are

SQL> alter system set db_file_name_convert='/ORASTANDBY/','/ORA11G/';
alter system set db_file_name_convert='/ORASTANDBY/','/ORA11G/'
*
ERROR at line 1:
ORA-02096: specified initialization parameter is not modifiable with
this option

SQL> alter system set db_file_name_convert='/ORASTANDBY/','/ORA11G/'

scope=spfile;
System altered.

SQL> alter system set log_file_name_convert='/ORASTANDBY/','/ORA11G/'

scope=spfile;
System altered.
NOTE:
In some cases, the directory structure may not be the same in source/primary and destination/
standby database locations. The DB_FILE_NAME_CONVERT parameter is used to convert the file
locations of datafiles. When you add a datafile in the primary database, assuming you have a
STANDBY_FILE_MANAGEMENT parameter setting of AUTO, it will create a datafile on the standby
database according to the settings of the DB_FILE_NAME_CONVERT parameter. Before setting
DB_FILE_NAME_CONVERT, make sure that filesystem exists and is writable.

Standby file management

Standby file management should always be set to TRUE. The DG Tooklit’s ALTER SYSTEM syntax for
the primary and standby database will always set the initialization parameter
STANDBY_FILE_MANAGEMENT=AUTO. With the STANDBY_FILE_MANAGEMENT set to TRUE, you
will not be able to perform the following commands:
 alter database rename
 alter database add or drop logfile
 alter database add or drop standby logfile member
 alter database create datafile as
If you need to issue the above commands, you will need to reset STANDBY_ FILE_MANAGEMENT
Create standby redo log files:
The SRL files are where the Remote File Server (RFS) process at your standby database writes the
incoming redo so that it is persistent on disk for recovery. They not need to be configured on
primary database as well for a role transition. The redo received by a standby database via redo
transport is written to the current SRL group by the Remote File Server (RFS) background
process. When a log switch occurs on the primary database, RFS writes the redo to the next standby
redo log group and the previously used standby redo log group is archived on the standby database
by an ARCn process.

This step in the configuration of oracle datagurad that we are configuring is optional as we are
configuring in maximum performance mode. But the protection modes like maximum availability
and maximum protection mandates the creation of the standby redo logs. But the oracle suggests to
create the standby redo log files with any protection mode so we are configuring standby redo log
files here. When creating standby redo logfiles it is recommended to create the standby logs more
than the number of redo log groups with same size of the redo log groups.
The generalize formula to calculate the standby redo log files is:
(# of online redo log file groups on primary + 1) * maximum # of threads
So as our database consists of three redo log groups and consists of one threads so we are
configuring 4 standby redo log groups as:
SQL> select group#, thread#, bytes/1024/1024 "Size in MB"
2 from v$Log;
GROUP# THREAD# Size in MB
---------- ---------- ----------
1 1 50
2 1 50
3 1 50

SQL> alter database add standby

logfile('/storage/ora11g/std_redo01.log')size 50m;
Database altered.

SQL> alter database add standby

logfile('/storage/ora11g/std_redo02.log') size 50m;
Database altered.

SQL> alter database add standby

logfile('/storage/ora11g/std_redo03.log') size 50m;
Database altered.

SQL> alter database add standby

logfile('/storage/ora11g/std_redo04.log') size 50m;
Database altered.

SQL> select group#, type from v$logfile;

GROUP# TYPE
---------- -------
3 ONLINE
2 ONLINE
1 ONLINE
4 STANDBY
5 STANDBY
6 STANDBY
7 STANDBY
7 rows selected.

Create a full backup of the primary database and the control file:
The standby database can be configured by either hot or cold backup, but we are using the hot
backup but full using the RMAN utility and using the backup to restore in the standby site.
[oracle@orahost ~]$ mkdir -p /storage/db_staging/
[oracle@orahost ~]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Sat Apr 19
11:05:19 2014
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights
reserved.
connected to target database: ORA11G (DBID=4241441809)
RMAN> backup device type disk format '/storage/db_staging/%U' database
plus archivelog;

RMAN> backup device type disk format '/storage/db_staging/%U' current

controlfile for standby;

Prepare initialization file for the standby database:

Prepare the initialization parameter for the standby database using reference the pfile of the
primary database and replacing the keywords unique database name of primary to unique database
name of the standby database:

SQL> create pfile='/storage/dg_stating/initorastandby.ora' from

spfile;
File created.

Transfer the backup set and pfile created to the standby host:
The next step is to transfer the backup sets of the primary database and the edited pfile to the
standby database for configuring the standby database.
[oracle@orahost ~]$ scp /storage/db_staging/*
oracle@192.168.179.142:/storage/db_staging/
Configuration of Standby Network Components:
Oracle data guard depends on Oracle Net as the transport mechanism to propagate changes made
on primary database to the standby. The oracle net listener and oracle net aliases must be
configured on both the primary and standby host in order to facilitate Data Guard’s communication
requirements. So the following components are needed to configure for oracle Data Guard’s
commutation.

 An coracle net listener running on primary database

 An oracle net listener running on secondary database
 An oracle net alias on primary must point to the standby database
 An oracle net alias on standby must point to the primary database

Oracle Net alias on primary database:

Oracle net alias on standby database:
Configure the listener of primary database:
The listener is configured by adding the static listener entity in the listener.ora file
Configure the listener of standby database:
Configure the standby database:
Configure the password file:
If the password file is copied from the primary database rename it with the orapwd<database
unique name> and transfer it to the location $ORACLE_HOME/dbs. If not then create the password
file using the utility orapwd.

Create spfile form the previously configured pfile:

Create the spfile from the pfile copied from the primary database as:
SQL> conn /as sysdba
Connected to an idle instance.
SQL> create spfile from pfile='/storage/db_staging/initora.ora';
File created.

SQL> !ls -l $ORACLE_HOME/dbs

total 24
-rw-rw---- 1 oracle oinstall 1544 Apr 18 10:30 hc_ora11g.dat
-rw-r--r-- 1 oracle oinstall 2851 May 15 2009 init.ora
-rw-r----- 1 oracle oinstall 24 Apr 16 09:44 lkORASTADNDBY
-rw-r----- 1 oracle oinstall 1536 Apr 18 10:29 orapworastandby
-rw-r----- 1 oracle oinstall 4608 Apr 18 10:35 spfileorastandby.ora

Create and start Standby Instance:

Create the dump directories specified in the pfile as:

[oracle@orastandby admin]$ mkdir orastandby

[oracle@orastandby admin]$ ls
orastandby
[oracle@orastandby admin]$ cd orastandby/
[oracle@orastandby orastandby]$ pwd
/u01/app/oracle/admin/orastandby
[oracle@orastandby orastandby]$ mkdir adump
[oracle@orastandby orastandby]$ mkdir bdump
[oracle@orastandby orastandby]$ mkdir pfile
[oracle@orastandby orastandby]$ mkdir dpdump
[oracle@orastandby orastandby]$ ls
adump bdump dpdump pfile
[oracle@orastandby orastandby]$ pwd
/u01/app/oracle/admin/orastandby

After successful creation of the directories check if the environmental variables are properly set or
not as:
[oracle@standby admin]$ env |grep ORACLE
ORACLE_DBUNQNAME=orastandby
ORACLE_SID=orastandby
ORACLE_HOSTNAME=standby.oracle.com
ORACLE_BASE=/u01/app/oracle
ORACLE_TERM=xterm
ORACLE_HOME=/u01/app/oracle/product/11.2.0.3/dbhome1
[oracle@standby admin]$ echo $LD_LIBRARY_PATH
/u01/app/oracle/product/11.2.0.3/dbhome1/lib:/lib:/usr/lib
[oracle@standby admin]$ echo $PATH
/u01/app/oracle/product/11.2.0.3/dbhome1/bin:/usr/sbin:/usr/kerberos/b
in:/usr/local/bin:/bin:/usr/bin:/home/oracle/bin

With the verification start the instance in nomount mode as:

[oracle@standby admin]$ sqlplus “/as sysdba”
SQL> startup nomount;

Restore the standby database from the rman backup sets:

[oracle@orastandby /]$ rman target sys/oracle@ora11g auxiliary
sys/oracle@orastandby
Recovery Manager: Release 11.2.0.4.0 - Production on Fri Apr 18
12:23:08 2014
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights
reserved.
connected to target database: ORA11G (DBID=4241327482)
connected to auxiliary database: ORA11G (not mounted)

RMAN> duplicate target database for standby;

Start redo apply for the standby database:

With the successful restoration of the standby database now start the redo apply on the standby
database issuing the following query as:
SQL> alter database recover managed standby database disconnect from
session;
Database altered.

Start Remote Archiving:

This is the final step in the configuration of the oracle datagurad as database till now is already in
managed recovery mode and the next final step is to start the shipping of the redo data to the
standby from the primary. Initally the parameter log_archive_dest_state_2 was set to defer so not it
is set to enable for shifting of redo logs from primary to standby database as:
SQL> alter system set log_archive_dest_state_2=enable scope=both;
System altered.
Verify the physical standby configuration is valid:
With the final step in physical standby it is necessary to check if the configuration is valid and is
working. So it can be verified by querying the dynamic views and monitoring the archive log status
and alter logs.

The validity of the configuration can be viewed by issuing query on views like v$datagurad_status,
v$archived_log, v$archive_dest;

Test Redo Transport:

The successful of redo transport for the primary database is check by issuing query over the
dynamic view like v$archive_dest;
SQL> select status , error from v$archive_dest where dest_id=2;
STATUS ERROR
--------- ------------------------------------------------------------
VALID

It shows that the transmission was successful as the status is valid and need to trouble shoot by
looking the alert log file if the status was invalid.

Test redo apply:

To verify that the archived log is being applied on standby database query the view v$archived_log
and archive log status in standby and primary database as:
SQL> -- query on standby database
SQL> select sequence#, first_time, next_time, archived,
2 applied from v$archived_log order by sequence#;
SEQUENCE# FIRST_TIM NEXT_TIME ARC APPLIED
---------- --------- --------- --- ---------
8 19-APR-14 19-APR-14 YES YES
9 19-APR-14 19-APR-14 YES YES
10 19-APR-14 19-APR-14 YES YES
11 19-APR-14 19-APR-14 YES YES
12 19-APR-14 19-APR-14 YES YES
13 19-APR-14 19-APR-14 YES YES

SQL> -- query on physical database

SQL> select sequence#, first_time, next_time, archived,
2 applied from v$archived_log order by sequence#;

SEQUENCE# FIRST_TIM NEXT_TIME ARC APPLIED

---------- --------- --------- --- ---------
3 18-APR-14 18-APR-14 YES NO
4 18-APR-14 18-APR-14 YES NO
5 18-APR-14 18-APR-14 YES NO
6 18-APR-14 18-APR-14 YES NO
7 18-APR-14 19-APR-14 YES NO
8 19-APR-14 19-APR-14 YES NO
 8 19-APR-14 19-APR-14 YES YES
9 19-APR-14 19-APR-14 YES YES
9 19-APR-14 19-APR-14 YES NO
10 19-APR-14 19-APR-14 YES NO
10 19-APR-14 19-APR-14 YES YES

SEQUENCE# FIRST_TIM NEXT_TIME ARC APPLIED

---------- --------- --------- --- ---------
11 19-APR-14 19-APR-14 YES YES
11 19-APR-14 19-APR-14 YES NO
12 19-APR-14 19-APR-14 YES YES
12 19-APR-14 19-APR-14 YES NO
13 19-APR-14 19-APR-14 YES YES

Some useful dynamic views for Trouble shooting:

 V$MANAGED_STANDBY
 V$DATAGUARD_STATS
 V$ARCHIVE_DEST
 V$ARCHIVED_LOG
 V$STANDBY_EVENT_HISTOGRAM