Chapter 2

Creating a Physical Standby Database by Using SQL and RMAN Commands

On Both Nodes check.
# cat /etc/hosts
127.0.0.1
localhost.localdomain localhost
192.168.1.100 11gr2.rhel5.com
11gr2
192.168.1.200 11gr2sb.rhel5.com
11gr2sb
Ping each nodes.
Create Directories
On standby
mkdir /u01/app/oracle/admin/stdy
mkdir -p /u01/app/oracle/admin/stdy/adump
mkdir -p /u01/app/oracle/admin/stdy/bdump
mkdir -p /u01/app/oracle/admin/stdy/cdump
mkdir -p /u01/app/oracle/admin/stdy/udump
mkdir -p /u01/app/oracle/admin/stdy/dpdump
mkdir -p /u01/app/oracle/admin/stdy/pfile
mkdir -p /u01/app/oracle/oradata/stdy
chown -R oracle:oinstall /u01/app/oracle/admin/stdy/
chown -R oracle:oinstall /u01/app/oracle/oradata/stdy
$ . oraenv
+ASM
$ asmcmd
ASMCMD> ls
DATA/
FRA/
ASMCMD> cd data
ASMCMD> ls
ASM/
ASMCMD> pwd
+data
ASMCMD> mkdir stdy

On Standby
$ crsctl start resource -all
On Primary
See the DB & ASM & Listener are up
$ crs_stat -t
Name
Type
Target State Host
-----------------------------------------------------------ora.DATA.dg ora....up.type ONLINE ONLINE 11gr2
ora.FRA.dg ora....up.type ONLINE ONLINE 11gr2
ora....ER.lsnr ora....er.type ONLINE ONLINE 11gr2
ora.asm
ora.asm.type ONLINE ONLINE 11gr2
ora.cssd
ora.cssd.type ONLINE ONLINE 11gr2
ora.diskmon ora....on.type ONLINE ONLINE 11gr2
ora.orcl.db ora....se.type ONLINE ONLINE 11gr2
On Primary
SQL> show parameter spfile
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------spfile
string
+DATA/orcl/spfileorcl.ora
SQL> show parameter memory
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------hi_shared_memory_address
integer 0
memory_max_target
big integer 1216M
memory_target
big integer 1216M
shared_memory_address
integer 0
SQL> archive log list;
Database log mode
Automatic archival
Archive destination

Archive Mode
Enabled
USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence 23

Next log sequence to archive 25
Current log sequence
25
SQL> select flashback_on from v$database;
FLASHBACK_ON
-----------------NO
SQL> select force_logging from v$database;
FOR
--NO
SQL> ALTER DATABASE FORCE LOGGING;
Database altered.
SQL> ALTER DATABASE FLASHBACK ON;
Database altered.
Now create standby redo files
SQL> SELECT group#, member, status FROM V$LOGfile;
SQL> ALTER DATABASE ADD STANDBY LOGFILE size 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE size 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE size 50M;
SQL> SELECT GROUP#, BYTES/1024, STATUS FROM V$STANDBY_LOG;
GROUP# BYTES/1024 STATUS
---------- ---------- ---------4
51200 UNASSIGNED
5
51200 UNASSIGNED
6
51200 UNASSIGNED

Setting Enviornment & Listener & Tnsnames.ora files

On Standby
Edit .bash_profile
Change the ORACLE_SID=stdy
$ env |grep ORA
ORACLE_SID=stdy
ORACLE_BASE=/u01/app/oracle
ORACLE_TERM=xterm
ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1
Configure listener.ora & tnsnames.ora on both servers to hold entries for both
databases
On Primary
$ . oraenv
orcl
$ cd /u01/app/oracle/product/11.2.0/db_1/network/admin/
$ vi tnsnames.ora
STDY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 11gr2sb.rhel5.com)(PORT =
1521))
)
(CONNECT_DATA =
(SID = stdy)(UR = A)
)
)
ORCL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 11gr2.rhel5.com)(PORT = 1521))
)
(CONNECT_DATA =

(SERVER = DEDICATED)
(SERVICE_NAME = orcl.rhel5.com)
)
)
$ tnsping stdy

$ . oraenv
+ASM
$ cd /u01/app/oracle/product/11.2.0/grid/network/admin/
$ vi listener.ora

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 11gr2.rhel5.com)(PORT = 1521))
)
)
ADR_BASE_LISTENER = /u01/app/oracle
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON
added by Agent

# line

Notice the value (UR=A) in the CONNECT_DATA of the tns entry

This will allow the primary database to connect remotely to a database in nomount or
mount mode. Its a feature introduced in oracle 10g.

On the Standby
Edit listener.ora or use netmgr by setting (+ASM environment) & Add static service
(stdy) to the listener
$ cd /u01/app/oracle/product/11.2.0/grid/network/admin
$ vi listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = stdy.rhel5.com)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
(SID_NAME = stdy)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 11gr2sb.rhel5.com)(PORT =
1521))
)
)
ADR_BASE_LISTENER = /u01/app/oracle
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER = ON
$ lsnrctl status
Bounce the listener
$ lsnrctl reload
$ lsnrctl status

Add service (orcl) on the standby

export ORACLE_SID=stdy
export ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1
$ env|grep ORA
$ cd /u01/app/oracle/product/11.2.0/db_1/network/admin
$ vi tnsnames.ora

STDY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 11gr2sb.rhel5.com)(PORT =
1521))
)
(CONNECT_DATA =
(SID = stdy)(UR = A)
)
)
ORCL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 11gr2.rhel5.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = orcl.rhel5.com)
)
)
Tnsping from both servers
$ . oraenv
orcl
On Standby
$ tnsping orcl
On Primary
$ tnsping stdy

Copy the password file from Primary to Standby, sys password must be identical
On Primary
$ cd /u01/app/oracle/product/11.2.0/db_1/dbs
$ scp orapworcl oracle@11gr2sb:/u01/app/oracle/product/11.2.0/db_1/dbs/orapwstdy
Configuring primary database initialization parameters
SQL> show parameter db_unique
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------db_unique_name
string
orcl
SQL> show parameter db_name
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------db_name
string
orcl
SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl,stdy)';
System altered.
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=STDY
VALID_FOR=(PRIMARY_ROLE,ONLINE_LOGFILES)
DB_UNIQUE_NAME=STDY';
System altered.
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
System altered.
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
System altered.
SQL> ALTER SYSTEM SET FAL_SERVER=STDY;

System altered.
SQL> ALTER SYSTEM SET FAL_CLIENT=ORCL;
System altered.

Check All the Parameters

SELECT DEST_ID,VALID_TYPE,VALID_ROLE,VALID_NOW FROM
V$ARCHIVE_DEST;
DEST_ID VALID_TYPE VALID_ROLE VALID_NOW
---------- --------------- ------------ ---------------1 ALL_LOGFILES ALL_ROLES YES
2 ONLINE_LOGFILE PRIMARY_ROLE YES
SQL> select * from v$dataguard_config;
DB_UNIQUE_NAME
-----------------------------orcl
stdy
SQL> archive log list;
Database log mode
Archive Mode
Automatic archival
Enabled
Archive destination
USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 26
Next log sequence to archive 28
Current log sequence
28
SQL> show parameter log_archive_dest_2
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------log_archive_dest_2
string
SERVICE=STDY VALID_FOR=(PRIMAR
Y_ROLE,ONLINE_LOGFILES) DB_UNI
QUE_NAME=STDY
SQL> show parameter log_archive_config

NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------log_archive_config
string
DG_CONFIG=(orcl,stdy)
SQL> show parameter fal_
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------fal_client
string
ORCL
fal_server
string
STDY
SQL> show parameter standby_file_management
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------standby_file_management
string AUTO
SQL>
On Standby
In Oracle Home/dbs directory, create a file initstdy.ora containing add below lines. This
will serve as the initialization file for the standby instance.
export ORACLE_SID=stdy
export ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1
cd /u01/app/oracle/product/11.2.0/db_1/dbs
$ vi initstdy.ora
db_name=orcl
Start the instance stdy in NOMOUNT state
sqlplus / as sysdba
SQL> startup nomount
SQL> show parameter spfile
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------spfile
string

SQL> show parameter local_listener

NAME TYPE VALUE
------------------------------------ ----------- -----------------local_listener string
Primary
SQL> alter system set local_listener=
'(ADDRESS=(PROTOCOL=TCP)(HOST= 11gr2.rhel5.com)(PORT=1521))'
scope=memory;
Standby
SQL> alter system set local_listener=
'(ADDRESS=(PROTOCOL=TCP)(HOST= 11gr2sb.rhel5.com)(PORT=1521))'
scope=memory;
Active DataGuard
Now that all initial preparation is completed, it's time to call the all-powerful RMAN
script that creates the standby database. On orcl, start RMAN and run the following
script. You will find it easier to save this in a file and run the script from the RMAN
prompt. In case of RMAN connection error restart auxiliary instance and listener.
On Primary
$ rman
RMAN> connect target sys/oracle@orcl
connected to target database: ORCL (DBID=1223873454)
RMAN> connect auxiliary sys/oracle@stdy
connected to auxiliary database: ORCL (not mounted)
run {
allocate channel prmy1 type disk;
allocate channel prmy2 type disk;
allocate channel prmy3 type disk;
allocate channel prmy4 type disk;

allocate channel prmy5 type disk;

allocate auxiliary channel stby1 type disk;
duplicate target database for standby from active database nofilenamecheck
spfile
parameter_value_convert 'orcl','stdy'
set 'db_unique_name'='stdy'
set control_files='+DATA/stdy/control.ctl'
set db_create_file_dest='+DATA'
set db_recovery_file_dest='+FRA'
set DB_RECOVERY_FILE_DEST_SIZE='10G'
set log_archive_max_processes='5'
set fal_client='stdy'
set fal_server='orcl'
set standby_file_management='AUTO'
set log_archive_config='dg_config=(orcl,stdy)'
set log_archive_dest_2='service=orcl LGWR ASYNC
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=orcl';
}

output.txt

This script creates the standby database, places the appropriate parameters in the spfile
for the standby instance, creates the diagnostic destination for the standby database, and
restarts the standby.
NOFILENAMECHECK:
Prevents RMAN from checking whether datafiles of the source database share the same
names as the standby database files that are in use.
The NOFILENAMECHECK option is required when the standby and primary datafiles
and online redo logs have identical filenames. Thus, if you want the duplicate database
filenames to be the same as the source database filenames, and if the databases are in
different hosts, then you must specify NOFILENAMECHECK
PARAMETER_VALUE_CONVERT:
Replaces the first string with the second string in all matching initialization parameter
values. Note that DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT
are exceptions to this rule and are not affected.
You can use PARAMETER_VALUE_CONVERT to set a collection of initialization
parameter values and avoid explicitly setting them all. For example, if the source
database uses disk group +ALPHA while the standby database will use +BETA, then you
could modify all parameters that refer to these disk groups by specifying SPFILE
PARAMETER_VALUE_CONVERT (+ALHPA,'+BETA).

Add entry into Standby

$ vi /etc/oratab
+ASM:/u01/app/oracle/product/11.2.0/grid:N
stdy:/u01/app/oracle/product/11.2.0/db_1:N
Data Guard & Oracle Restart in 11gR2
$ srvctl add database -d stdy -o /u01/app/oracle/product/11.2.0/db_1 -r
PHYSICAL_STANDBY -s MOUNT
$ srvctl config database -d stdy
Database unique name: stdy
Database name:
Oracle home: /u01/app/oracle/product/11.2.0/db_1
Oracle user: oracle
Spfile:
Domain:
Start options: MOUNT
Stop options: immediate
Database role: PHYSICAL_STANDBY
Management policy: AUTOMATIC
Disk Groups:
Services:

Test the DataGuard Configuration

On the Primary database, connect as HR and add a row to the HR.REGIONS table
SQL> connect hr/hr@orcl
Connected.
SQL> insert into HR.REGIONS values (30,'OpenWorld');
1 row created.
SQL> commit;
Commit complete.
ON Standby
SQL> select * from hr.regions;
Test2

On Primary
SQL> archive log list;
Database log mode
Archive Mode
Automatic archival
Enabled
Archive destination
USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 28
Next log sequence to archive 30
Current log sequence
30
On Standby
SQL> select status from v$instance;
STATUS
-----------MOUNTED
SQL> archive log list;
Database log mode
Archive Mode
Automatic archival
Enabled
Archive destination
USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 0
Next log sequence to archive 0
Current log sequence
30
On Primary
SQL> alter system archive log current;
System altered.
SQL> archive log list;
Database log mode
Archive Mode
Automatic archival
Enabled
Archive destination
USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 29
Next log sequence to archive 31
Current log sequence
31
On Standby
SQL> archive log list;
Database log mode
Automatic archival

Archive Mode
Enabled

Archive destination
USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 30
Next log sequence to archive 0
Current log sequence
31
SQL> SELECT SEQUENCE#, FIRST_TIME, APPLIED FROM V$ARCHIVED_LOG
ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TIM APPLIED
---------- --------- --------1 03-MAR-12 NO
29 03-MAR-12 YES
30 03-MAR-12 YES
31 03-MAR-12 YES
32 03-MAR-12 YES
33 03-MAR-12 YES
34 03-MAR-12 YES
New Columns in v$database
Primary
SQL> select controlfile_type from v$database;
CONTROL
------CURRENT
Standby
SQL> select controlfile_type from v$database;
CONTROL
------STANDBY
SQL> select protection_mode, protection_level from v$database;
PROTECTION_MODE PROTECTION_LEVEL
-------------------- -------------------MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
SQL> select archivelog_compression from v$database;
ARCHIVEL
-------DISABLED

SQL> select db_unique_name, PRIMARY_DB_UNIQUE_NAME from v$database;

DB_UNIQUE_NAME
PRIMARY_DB_UNIQUE_NAME
------------------------------ -----------------------------stdy
orcl
SQL> select dataguard_broker from v$database;
DATAGUAR
-------DISABLED
SQL> select CONTROLFILE_CONVERTED from v$database;
CON
--NO
SQL> select remote_archive from v$database;
REMOTE_A
-------ENABLED
Enable Recovery on the Standby
SQL> select recovery_mode from v$archive_dest_status;
SQL> alter database recover managed standby database using current logfile disconnect;
SQL> select recovery_mode from v$archive_dest_status;
Cancel Recovery
SQL> alter database recover managed standby database cancel;
Chapter 3 & 4
Creating a Data Guard Broker Configuration
Enable Flashback Database on the Primary and Standby databases.
On Primary
SQL> select flashback_on from v$database;

FLASHBACK_ON
-----------------YES
SQL> show parameter spfile
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------spfile
string
+DATA/orcl/spfileorcl.ora
SQL> show parameter undo_
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------undo_management
string AUTO
undo_retention
integer 900
undo_tablespace
string
UNDOTBS1
SQL>
On Standby
SQL> show parameter spfile
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------spfile
string
/u01/app/oracle/product/11.2.0
/db_1/dbs/spfilestdy.ora
SQL> show parameter undo_
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------undo_management
string AUTO
undo_retention
integer 900
undo_tablespace
string
UNDOTBS1
SQL> select flashback_on from v$database;
FLASHBACK_ON
-----------------NO
SQL> alter database flashback on;

Implementation of Data Guard Broker

SQL> show parameter DG_BROKER_START
NAME TYPE VALUE
------------------------------------ ----------- ------dg_broker_start boolean FALSE
Enable Data Guard Broker Start on the Primary and Standby databases
SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE SCOPE=BOTH;
System altered
Alert log shows
DMON started with pid=36, OS id=26022
2012-03-04 12:06:42.362000 +05:30
Starting Data Guard Broker (DMON)
2012-03-04 12:06:50.601000 +05:30
INSV started with pid=38, OS id=26039
SQL> show parameter dg_broker
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------dg_broker_config_file1
string
/u01/app/oracle/product/11.1.0
/db_1/dbs/dr1stdy.dat
dg_broker_config_file2
string
/u01/app/oracle/product/11.1.0
/db_1/dbs/dr2stdy.dat
dg_broker_start
boolean TRUE
Setup the Local_Listener parameter on both the Primary and Standby databases
SQL> show parameter local_listener
NAME TYPE VALUE
------------------------------------ ----------- -----------------local_listener string
If not Set
SQL> alter system set local_listener=

'(ADDRESS=(PROTOCOL=TCP)(HOST= 11gr2.rhel5.com)(PORT=1521))'
scope=both;
SQL> alter system set local_listener=
'(ADDRESS=(PROTOCOL=TCP)(HOST= 11gr2sb.rhel5.com)(PORT=1521))'
scope=both;
Setup the tnsnames & listener to enable communication with both the Primary and
Standby databases
To enable the Data Guard broker to restart instances during the course of broker
operations, a service with a specific name must be statically registered with the local
listener of each instance. The value of the GLOBAL_DBNAME attribute must be set to a
concatenation of db_unique_name_DGMGRL.db_domain
Prior to Oracle11g Release 2, you had to use the static entry format of
GLOBAL_DBNAME attribute of db_unique_name_DGMGRL.db_domain, or in our
case, orcl_DGMGRL and stdy_DGMGRL. The Broker in Oracle11g Release 2 has a
new property called StaticConnectIdentifier that you can set to tell the Broker to use your
own static listener entry.
On Primary
$ cd /u01/app/oracle/product/11.2.0/grid/network/admin/
$ vi listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = orcl_DGMGRL.rhel5.com)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
(SID_NAME = orcl)
)
)
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 11gr2.rhel5.com)(PORT = 1521))
)
ADR_BASE_LISTENER = /u01/app/oracle
$ . oraenv
+ASM

$ lsnrctl reload
On Primary
$ cd /u01/app/oracle/product/11.2.0/db_1/network/admin/
$ vi tnsnames.ora
STDY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 11gr2sb.rhel5.com)(PORT =
1521))
)
(CONNECT_DATA =
(SERVICE_NAME = stdy_DGMGRL)
)
)
ORCL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 11gr2.rhel5.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl_DGMGRL.rhel5.com)
)
)
On Standby
$ cd /u01/app/oracle/product/11.2.0/grid/network/admin/
$ vi listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = stdy_DGMGRL)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
(SID_NAME = stdy)
)
)

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 11gr2sb.rhel5.com)(PORT =
1521))
)
)
ADR_BASE_LISTENER = /u01/app/oracle
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER = ON
$ lsnrctl reload
On Standby
$ cd /u01/app/oracle/product/11.2.0/db_1/network/admin/
$ vi tnsnames.ora
STDY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 11gr2sb.rhel5.com)(PORT =
1521))
)
(CONNECT_DATA =
(SERVICE_NAME = stdy_DGMGRL)
)
)
ORCL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 11gr2.rhel5.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = orcl_DGMGRL.rhel5.com)
)
)

Setup the tnsnames to enable communication with both the Primary, Standby &
Observer databases
$ tnsping orcl
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS =
(PROTOCOL = TCP)(HOST = 11gr2.rhel5.com)(PORT = 1521))) (CONNECT_DATA =
(SERVICE_NAME = orcl_DGMGRL.rhel5.com)))
OK (10 msec)
$ tnsping stdy
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS =
(PROTOCOL = TCP)(HOST = 11gr2sb.rhel5.com)(PORT = 1521))) (CONNECT_DATA
= (SERVICE_NAME = stdy_DGMGRL)))
OK (10 msec)
On Primary:
SQL> show parameter dg_broker_config
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------dg_broker_config_file1
string
/u01/app/oracle/product/11.1.0
/db_1/dbs/dr1orcl.dat
dg_broker_config_file2
string
/u01/app/oracle/product/11.1.0
/db_1/dbs/dr2orcl.dat
On Standby:
SQL> show parameter dg_broker_config
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------dg_broker_config_file1
string
/u01/app/oracle/product/11.1.0
/db_1/dbs/dr1stdy.dat
dg_broker_config_file2
string
/u01/app/oracle/product/11.1.0
/db_1/dbs/dr2stdy.dat

Next create from within the DGMGRL the configuration

On Primary
$ dgmgrl
DGMGRL>
DGMGRL> CONNECT sys/oracle
Connected.
DGMGRL> CREATE CONFIGURATION ORCL_STDY AS PRIMARY DATABASE IS
ORCL CONNECT IDENTIFIER IS ORCL;
Configuration "orcl" created with primary database "orcl"
DGMGRL> ADD DATABASE STDY AS CONNECT IDENTIFIER IS STDY
MAINTAINED AS PHYSICAL;
Database "stdy" added
DGMGRL> edit database orcl set property StaticConnectIdentifier='orcl';
DGMGRL> edit database stdy set property StaticConnectIdentifier='stdy';
DGMGRL> SHOW CONFIGURATION;
Configuration
Name: orcl
Enabled: NO
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
orcl - Primary database
stdy - Physical standby database
Current status for "orcl":
DISABLED
DGMGRL> SHOW DATABASE VERBOSE STDY;
Database - stdy
Role:
PHYSICAL STANDBY
Intended State: OFFLINE
Transport Lag: (unknown)
Apply Lag:
(unknown)
Real Time Query: OFF

Instance(s):
stdy
Properties:
DGConnectIdentifier
= 'stdy'
ObserverConnectIdentifier
= ''
LogXptMode
= 'ASYNC'
DelayMins
= '0'
Binding
= 'OPTIONAL'
MaxFailure
= '0'
MaxConnections
= '1'
ReopenSecs
= '300'
NetTimeout
= '30'
RedoCompression
= 'DISABLE'
LogShipping
= 'ON'
PreferredApplyInstance
= ''
ApplyInstanceTimeout
= '0'
ApplyParallel
= 'AUTO'
StandbyFileManagement
= 'AUTO'
ArchiveLagTarget
= '0'
LogArchiveMaxProcesses
= '5'
LogArchiveMinSucceedDest
= '1'
DbFileNameConvert
= ''
LogFileNameConvert
= ''
FastStartFailoverTarget
= ''
StatusReport
= '(monitor)'
InconsistentProperties
= '(monitor)'
InconsistentLogXptProps
= '(monitor)'
SendQEntries
= '(monitor)'
LogXptStatus
= '(monitor)'
RecvQEntries
= '(monitor)'
HostName
= '11gr2sb.rhel5.com'
SidName
= 'stdy'
StaticConnectIdentifier
= 'stdy'
StandbyArchiveLocation
= 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation
= ''
LogArchiveTrace
= '0'
LogArchiveFormat
= '%t_%s_%r.dbf'
TopWaitEvents
= '(monitor)'
Database Status:
DISABLED

DGMGRL> SHOW DATABASE VERBOSE ORCL;

Database - orcl
Role:
PRIMARY
Intended State: OFFLINE
Instance(s):
orcl
Properties:
DGConnectIdentifier
= 'orcl'
ObserverConnectIdentifier
= ''
LogXptMode
= 'ASYNC'
DelayMins
= '0'
Binding
= 'optional'
MaxFailure
= '0'
MaxConnections
= '1'
ReopenSecs
= '300'
NetTimeout
= '30'
RedoCompression
= 'DISABLE'
LogShipping
= 'ON'
PreferredApplyInstance
= ''
ApplyInstanceTimeout
= '0'
ApplyParallel
= 'AUTO'
StandbyFileManagement
= 'AUTO'
ArchiveLagTarget
= '0'
LogArchiveMaxProcesses
= '4'
LogArchiveMinSucceedDest
= '1'
DbFileNameConvert
= ''
LogFileNameConvert
= ''
FastStartFailoverTarget
= ''
StatusReport
= '(monitor)'
InconsistentProperties
= '(monitor)'
InconsistentLogXptProps
= '(monitor)'
SendQEntries
= '(monitor)'
LogXptStatus
= '(monitor)'
RecvQEntries
= '(monitor)'
HostName
= '11gr2.rhel5.com'
SidName
= 'orcl'
StaticConnectIdentifier
= 'orcl'
StandbyArchiveLocation
= 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation
= ''
LogArchiveTrace
= '0'
LogArchiveFormat
= '%t_%s_%r.dbf'
TopWaitEvents
= '(monitor)'
Database Status:

DISABLED
DGMGRL> enable configuration;
Enabled.
DGMGRL>
DGMGRL> enable database STDY;
Enabled.
DGMGRL> show configuration;
Configuration
Name:
orcl
Enabled:
YES
Protection Mode: MaxPerformance
Databases:
orcl - Primary database
stdy - Physical standby database
Fast-Start Failover: DISABLED
Current status for "orcl":
SUCCESS
Shutdown Both Primary & Standby from DGBroker and Take snapshot from
Vmware workstation
Chapter 5
Creating a Physical Standby Database by Using Enterprise Manager Grid Control

Oracle 11gR2
DataGuard with Grid Control.doc

In case of ERROR NMO either run root.sh again from agent_home/bin on both the nodes
or use below doc to fix it.

ERROR NMO.txt

Chapter 6

Creating a Logical Standby Database by Converting from Physical to Logical

Standby
You can now easily convert a physical standby database to a logical one. Here are the
steps:
1. On the standby database, stop the managed recovery process:
SQL> alter database recover managed standby database cancel;
Database altered.
Or
DGMGRL> edit database stdy set state='APPLY-OFF';
2. The standby database will need to get the data dictionary information from somewhere.
The dictionary information should be put in the redo stream that comes from the primary.
So, on the primary database, issue the following to build the LogMiner tables for
dictionary:
SQL> begin
dbms_logstdby.build;
end;
/
PL/SQL procedure successfully completed.
Alert log.
Logminer Bld: Build started
ALTER SYSTEM SWITCH ALL LOGFILE start (orcl)
2012-03-05 13:49:50.416000 +05:30
ALTER SYSTEM SWITCH ALL LOGFILE complete (orcl)
Thread 1 advanced to log sequence 41 (LGWR switch)
Current log# 2 seq# 41 mem# 0: +DATA/orcl/onlinelog/group_2.264.719142951
Current log# 2 seq# 41 mem# 1: +DATA/orcl/onlinelog/group_2.265.719142957
Mon Mar 05 13:49:50 2012
Logminer Bld: Lockdown Complete. DB_TXN_SCN is 0 1013551 LockdownSCN is
1013568
2012-03-05 13:49:55.952000 +05:30
Archived Log entry 44 added for thread 1 sequence 40 ID 0x4a53118e dest 1:
2012-03-05 13:49:59.315000 +05:30
ARC3: Standby redo logfile selected for thread 1 sequence 40 for destination
LOG_ARCHIVE_DEST_2
2012-03-05 13:50:38.821000 +05:30

ALTER SYSTEM ARCHIVE LOG

2012-03-05 13:50:40.303000 +05:30
Thread 1 advanced to log sequence 42 (LGWR switch)
Current log# 3 seq# 42 mem# 0: +DATA/orcl/onlinelog/group_3.266.719142961
Current log# 3 seq# 42 mem# 1: +DATA/orcl/onlinelog/group_3.267.719142965
2012-03-05 13:50:45.058000 +05:30
Archived Log entry 46 added for thread 1 sequence 41 ID 0x4a53118e dest 1:
Mon Mar 05 13:50:45 2012
Logminer Bld: Done

SQL> select SUPPLEMENTAL_LOG_DATA_MIN,

SUPPLEMENTAL_LOG_DATA_PK, SUPPLEMENTAL_LOG_DATA_UI from
v$database ;
SUPPLEME SUP SUP
-------- --- --IMPLICIT YES YES
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE
DICTIONARY_BEGIN='YES' and STANDBY_DEST='NO';
NAME
--------------------------------------------------------------------------------+FRA/stdy/archivelog/2012_03_05/thread_1_seq_41.277.777131459
3. Now, issue the command in standby side to convert it to logical:
SQL> alter database recover to logical standby lstdy;
Database altered.
If you didn't execute Step 2, the above command will wait since the dictionary
information is not found. Don't worry; just execute the Step 2 at this point. If you have
enabled RTA, the information will immediately appear on the standby database.
4. Issue a few log switches on primary to make sure the archived logs are created and sent
over to the standby:
SQL> alter system switch logfile;
System altered.
5. On the standby side, you can see that the alter database command has completed, after
some time. Now the standby is a logical one.

Alert log
alter database recover to logical standby lstdy
Media Recovery Start: Managed Standby Recovery (stdy)
2012-03-05 13:53:35.624000 +05:30
started logmerger process
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 2 slaves
2012-03-05 13:53:36.677000 +05:30
Media Recovery Log
+FRA/stdy/archivelog/2012_03_05/thread_1_seq_40.276.777131407
2012-03-05 13:53:53.679000 +05:30
Using STANDBY_ARCHIVE_DEST parameter default value as
USE_DB_RECOVERY_FILE_DEST
2012-03-05 13:54:02.997000 +05:30
Media Recovery Log
+FRA/stdy/archivelog/2012_03_05/thread_1_seq_41.277.777131459
2012-03-05 13:54:21.718000 +05:30
Media Recovery Log
+FRA/stdy/archivelog/2012_03_05/thread_1_seq_42.278.777131463
Incomplete Recovery applied until change 1014941 time 03/05/2012 13:50:46
Media Recovery Complete (stdy)
krsv_proc_kill: Killing 4 processes (all RFS)
2012-03-05 13:54:24.439000 +05:30
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
RESETLOGS after complete recovery through change 1014941
Resetting resetlogs activation ID 1246957966 (0x4a53118e)
Online log +DATA/stdy/onlinelog/group_1.262.776967645: Thread 1 Group 1 was
previously cleared
Online log +FRA/stdy/onlinelog/group_1.256.776967651: Thread 1 Group 1 was
previously cleared
Online log +DATA/stdy/onlinelog/group_2.263.776967657: Thread 1 Group 2 was
previously cleared
Online log +FRA/stdy/onlinelog/group_2.257.776967663: Thread 1 Group 2 was
previously cleared
Online log +DATA/stdy/onlinelog/group_3.264.776967673: Thread 1 Group 3 was
previously cleared
Online log +FRA/stdy/onlinelog/group_3.258.776967677: Thread 1 Group 3 was
previously cleared
2012-03-05 13:54:26.926000 +05:30
Standby became primary SCN: 1014939
Setting recovery target incarnation to 4
RECOVER TO LOGICAL STANDBY: Complete - Database shutdown required after
NID finishes
*** DBNEWID utility started ***

DBID will be changed from 1246923666 to new DBID of 2386946899 for database
ORCL
DBNAME will be changed from ORCL to new DBNAME of LSTDY
Starting datafile conversion
Datafile conversion complete
Database name changed to LSTDY.
Modify parameter file and generate a new password file before restarting.
Database ID for database LSTDY changed to 2386946899.
All previous backups and archived redo logs for this database are unusable.
Database has been shutdown, open with RESETLOGS option.
Succesfully changed database name and ID.
*** DBNEWID utility finished succesfully ***
2012-03-05 13:54:28.351000 +05:30
Completed: alter database recover to logical standby lstdy
2012-03-05 13:54:34.755000 +05:30
destination database instance is 'started' not 'mounted'
6. Bounce the database:
SQL> shutdown
SQL> startup mount
SQL> alter database open resetlogs;
SQL> select open_mode from v$database;
OPEN_MODE
---------READ WRITE
SQL> select name from v$database;
NAME
--------LSTDY
SQL> select database_role from v$database;
DATABASE_ROLE
---------------LOGICAL STANDBY
SQL> select guard_status from v$database;
GUARD_S

------ALL
7. Now that this is a logical standby database, you should start the SQL Apply process.
SQL> alter database start logical standby apply immediate;
The logical standby database is now fully operational! Once you convert the physical
standby to a logical one, you can't convert it back to a physical one unless you use the
special clause ("keep identity"), described in the section below.
Output from Alert logs

output.txt

Verify That the Logical Standby Database Is Performing Properly

a. Verify that the archived redo log files were registered on logical standby:
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME,
DICT_BEGIN,DICT_END FROM DBA_LOGSTDBY_LOG ORDER BY
SEQUENCE#;
SEQUENCE# FIRST_TIM NEXT_TIME DIC DIC
---------- --------- --------- --- --40 03-MAR-12 05-MAR-12 NO NO
41 05-MAR-12 05-MAR-12 YES YES
42 05-MAR-12 05-MAR-12 NO NO
SQL>
b. Begin sending redo data to the standby database:
Connect to the primary database and issue the following command to begin sending redo
data to the standby database
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
c. Query the DBA_LOGSTDBY_LOG view to verify that the archived redo log files
were registered.
Connect to the logical standby database and re-query the DBA_LOGSTDBY_LOG view
as shown in step a. This enables you to verify that the new archived redo log files were
registered.

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME,

DICT_BEGIN,DICT_END FROM DBA_LOGSTDBY_LOG ORDER BY
SEQUENCE#;
SEQUENCE# FIRST_TIM NEXT_TIME DIC DIC
---------- --------- --------- --- --40 03-MAR-12 05-MAR-12 NO NO
41 05-MAR-12 05-MAR-12 YES YES
42 05-MAR-12 05-MAR-12 NO NO
43 05-MAR-12 05-MAR-12 NO NO
44 05-MAR-12 05-MAR-12 NO NO
SQL>
d. Verify that redo data is being applied correctly:
On the logical standby database, query the V$LOGSTDBY_STATS view to verify that
redo data is being applied correctly:
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
WHERE NAME = 'coordinator state';
NAME
VALUE
------------------------------ ---------------------------------------------------------------coordinator state
INITIALIZING
SQL>
e. View the V$LOGSTDBY view to see current
Query the V$LOGSTDBY view on the logical standby database to see a current snapshot
of SQL Apply activity. A text message describing the current activity of each process that
is involved in reading and applying changes is displayed.
SQL> SELECT TYPE, HIGH_SCN, STATUS
FROM V$LOGSTDBY;
TYPE
HIGH_SCN STATUS
------------------------------ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------COORDINATOR
1014941 ORA-16116: no work available
ANALYZER
1013570 ORA-16116: no work available
APPLIER
ORA-16116: no work available
APPLIER
ORA-16116: no work available
APPLIER
ORA-16116: no work available
APPLIER
ORA-16116: no work available

APPLIER
ORA-16116: no work available
READER
1014928 ORA-16127: stalled waiting for additional
transactions to be applied
BUILDER
1014166 ORA-16117: processing
PREPARER
1014168 ORA-16117: processing
10 rows selected.
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
TYPE
HIGH_SCN STATUS
------------------------------ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------COORDINATOR
ORA-16117: processing
READER
624900 ORA-16117: processing
BUILDER
ORA-16117: processing
PREPARER
ORA-16117: processing
f. Check the overall progress of SQL Apply:
Query the V$LOGSTDBY_PROGRESS view on the logical standby database to check
the overall progress of SQL Apply:
SQL> SELECT APPLIED_SCN, LATEST_SCN FROM
V$LOGSTDBY_PROGRESS;
SELECT APPLIED_SCN, LATEST_SCN
2 FROM V$LOGSTDBY_PROGRESS;
APPLIED_SCN LATEST_SCN
----------- ---------1015278 1015278
Add theLogical Standby to the Broker Configuration
DGMGRL> remove database stdy;
DGMGRL> SHOW CONFIGURATION;
DGMGRL> ADD DATABASE STDY AS CONNECT IDENTIFIER IS STDY
MAINTAINED AS logical;
DGMGRL> SHOW CONFIGURATION;
DGMGRL> enable database stdy;
DGMGRL> SHOW CONFIGURATION;

Chapter 7
Creating and Managing a Snapshot Standby Database
Snapshot Standby
Here's a typical scenario: Say a new application is being deployed on the database and
you are wondering about the impact on database performance. In Oracle Database 11g,
there is that perfect tool (Database Replay), which captures the SQL statements and
replays them, but there is a caveat: you have to run them to see the impact. You capture
from a test system but replaying on the production system is not feasible. First, it's
not deployed; and second, even if it were deployed, you couldn't afford to have the app
making changes to other tables. So what do you do to see the impact of the app?
The perfect answer awaits you in Oracle Database 11g, where the physical standby
database can be temporarily converted into an up dateable one called Snapshot Standby
Database. In that mode, you can run your appwhich may modify a lot of tablesand
gauge its impact. Once the impact is assessed, you can convert the database into a
standby undergoing the normal recovery. This is accomplished by creating a restore point
in the database, using the Flashback database feature to flashback to that point and undo
all the changes. Let's see how it is done:
On Standby
SQL> alter database flashback on;
Database altered.
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database flashback on;
Database altered.
Alert log
Starting background process RVWR
RVWR started with pid=25, OS id=21816
2012-03-03 18:18:47.119000 +05:30
Allocated 8388608 bytes in shared pool for flashback generation buffer
2012-03-03 18:18:48.171000 +05:30
Flashback Database Enabled at SCN 1010028

SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL> select force_logging from v$database;
FOR
--YES
First, start recovery on the standby, if not going on already:
SQL> select max(sequence#) from v$log;
MAX(SEQUENCE#)
-------------40
On Standby
At this point, you may create the snapshot standby database. Remember, it enables
Flashback logging, so if you haven't configured the flash recovery area, you will get a
message like this:
ORA-38784: Cannot create restore point
'SNAPSHOT_STANDBY_REQUIRED_01/12/2008
00:23:14'.
ORA-38786: Flash recovery area is not enabled.
SQL> show parameter recovery
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------db_recovery_file_dest
string
+FRA
db_recovery_file_dest_size
big integer 10G
Now that the formalities are completed, you can convert this standby database to
snapshot standby using this simple command:
SQL> alter database recover managed standby database cancel;
Database altered.

SQL> alter database convert to snapshot standby;

Database altered.
Alert log
Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_03/03/2012
18:23:20
krsv_proc_kill: Killing 3 processes (all RFS)
2012-03-03 18:23:21.732000 +05:30
All dispatchers and shared servers shutdown
CLOSE: killing server sessions.
CLOSE: all sessions shutdown successfully.
SMON: disabling cache recovery
2012-03-03 18:23:22.882000 +05:30
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
RESETLOGS after incomplete recovery UNTIL CHANGE 1010028
Resetting resetlogs activation ID 1246957966 (0x4a53118e)
Online log +DATA/stdy/onlinelog/group_1.262.776967645: Thread 1 Group 1 was
previously cleared
Online log +FRA/stdy/onlinelog/group_1.256.776967651: Thread 1 Group 1 was
previously cleared
Online log +DATA/stdy/onlinelog/group_2.263.776967657: Thread 1 Group 2 was
previously cleared
Online log +FRA/stdy/onlinelog/group_2.257.776967663: Thread 1 Group 2 was
previously cleared
Online log +DATA/stdy/onlinelog/group_3.264.776967673: Thread 1 Group 3 was
previously cleared
Online log +FRA/stdy/onlinelog/group_3.258.776967677: Thread 1 Group 3 was
previously cleared 2012-03-03 18:23:23.916000 +05:30 Standby became primary SCN:
1010026 Setting recovery target incarnation to 3 CONVERT TO SNAPSHOT
STANDBY: Complete - Database mounted as snapshot standby Completed: alter
database convert to snapshot standby
SQL> select * from v$restore_point;
SCN DATABASE_INCARNATION# GUA STORAGE_SIZE
---------- --------------------- --- -----------TIME
--------------------------------------------------------------------------RESTORE_POINT_TIME
PRE
--------------------------------------------------------------------------- --NAME
-------------------------------------------------------------------------------1013455
2 YES 15941632
20-FEB-13 05.50.41.000000000 PM

YES
SNAPSHOT_STANDBY_REQUIRED_02/20/2013 17:50:41
Now bounce the database:
SQL> select status from v$instance;
STATUS
-----------MOUNTED
SQL> select open_mode from v$database;
OPEN_MODE
-------------------MOUNTED
SQL> startup force
ORACLE instance started.
Total System Global Area 422670336 bytes
Fixed Size
1300352 bytes
Variable Size
343935104 bytes
Database Buffers
71303168 bytes
Redo Buffers
6131712 bytes
Database mounted.
Database opened.
Now the database is open for read/write operations:
SQL> select open_mode, database_role from v$database;
OPEN_MODE DATABASE_ROLE
---------- ---------------READ WRITE SNAPSHOT STANDBY
Alert log
RFS[1]: Assigned to RFS process 22430
RFS[1]: Identified database type as 'snapshot standby': Client is ARCH pid 10428

You can do changes in this database now. This is a perfect place to replay the captured
workload using Database Replay. You can then perform the system changes in this
database and replay several times to see the impact of the changes. As this is a copy of
the production database, the replay will be an accurate representation of the workload.
After your testing is completed, you would want to convert the snapshot standby database
back to a regular physical standby database. Just follow the steps shown below:
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 422670336 bytes
Fixed Size
1300352 bytes
Variable Size
343935104 bytes
Database Buffers
71303168 bytes
Redo Buffers
6131712 bytes
Database mounted.
SQL> alter database convert to physical standby;
Database altered.
Alert log
krsv_proc_kill: Killing 1 processes (all RFS)
2012-03-03 18:30:01.164000 +05:30
Flashback Restore Start
2012-03-03 18:30:09.992000 +05:30
Flashback Restore Complete
Guaranteed restore point dropped
Clearing standby activation ID 1304761003 (0x4dc512ab)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;

Completed: alter database convert to physical standby

2012-03-03 18:30:21.930000 +05:30
destination database instance is 'started' not 'mounted'
SQL> shutdown immediate
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 422670336 bytes
Fixed Size
1300352 bytes
Variable Size
343935104 bytes
Database Buffers
71303168 bytes
Redo Buffers
6131712 bytes
Database mounted.
SQL> select open_mode, database_role from v$database;
OPEN_MODE DATABASE_ROLE
---------- ---------------MOUNTED PHYSICAL STANDBY
Alert log
RFS[1]: Assigned to RFS process 22688
RFS[1]: Identified database type as 'physical standby': Client is ARCH pid 10428
Start the managed recovery process:
SQL> alter database recover managed standby database disconnect;
Now the standby database is back in managed recovery mode. Needless to say, when the
database was in snapshot standby mode, the archived logs from primary were not applied
to it. They will be applied now and it may take some time before it completely catches
up. Snapshot standby database allows you to use the standby database to accurately
predict changes to production database before they were made. But that's not it; there is
another advantage as well. Remember, we could have used RTA in this case, which
causes the changes made to the primary appear instantly on the standby, provided the
network is available? Well, what if someone makes a mistake on the primary database,
such as running a massive update or changing some code? In previous versions we
deliberately use a delay in the standby database to stop these errors propagating to the
standby. But that delay also means the standby can't be activated properly or be used as
an active copy of production. Not anymore. Since you can flashback the standby

database, you need not keep the delay. If there is a problem, you can always flashback to
a previous state.
Chapter 8
Using Oracle Active Data Guard in 11g
SQL> select recovery_mode from v$archive_dest_status;
RECOVERY_MODE
----------------------IDLE
SQL> alter database recover managed standby database disconnect;
Database altered.
SQL> select recovery_mode from v$archive_dest_status;
RECOVERY_MODE
----------------------MANAGED
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> select recovery_mode from v$archive_dest_status;
RECOVERY_MODE
----------------------IDLE
Alert Log Contents
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /u01/app/oracle/diag/rdbms/stdy/stdy/trace/stdy_pr00_18386.trc:
ORA-16037: user requested cancel of managed recovery operation
Recovery interrupted!
Waiting for MRP0 pid 18384 to terminate
Errors in file /u01/app/oracle/diag/rdbms/stdy/stdy/trace/stdy_pr00_18386.trc:
ORA-16037: user requested cancel of managed recovery operation
MRP0: Background Media Recovery process shutdown (stdy)

Managed Standby Recovery Canceled (stdy)

Completed: alter database recover managed standby database cancel
2012-03-03 16:40:11.937000 +05:30
SQL> alter database open read only;
Database altered.
Alert log
Physical standby database opened for read only access.
2012-03-03 16:41:17.796000 +05:30
Completed: alter database open read only
SQL> alter database recover managed standby database disconnect;
Database altered.
Alert log
alter database recover managed standby database disconnect
Attempt to start background Managed Standby Recovery process (stdy)
MRP0 started with pid=35, OS id=18613
MRP0: Background Managed Standby Recovery process started (stdy)
2012-03-03 16:42:01.136000 +05:30
started logmerger process
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 2 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Waiting for thread 1 sequence 31 (in transit)
Completed: alter database recover managed standby database disconnect
SQL> select recovery_mode from v$archive_dest_status;
RECOVERY_MODE
----------------------MANAGED
SQL> select status from v$instance;
STATUS
-----------OPEN

SQL> select open_mode from v$database;

OPEN_MODE
-------------------READ ONLY WITH APPLY
SQL>
On Primary
SQL> alter system switch logfile;
System altered.
SQL> select max(sequence#) from v$log;
MAX(SEQUENCE#)
-------------32
SQL> create table test (col1 number);
Table created.
SQL> desc test
Name
Null? Type
----------------------------------------------------------------------------------------------------------COL1
NUMBER
SQL> alter system switch logfile;
System altered.
SQL> alter system switch logfile;
System altered.
SQL> alter system switch logfile;
System altered.
SQL>

On Standby
SQL> select max(sequence#) from v$log;
MAX(SEQUENCE#)
-------------32
SQL>
SQL> desc test
Name
Null? Type
----------------------------------------------------------------------------------------------------------COL1
NUMBER
SQL>
Alert log of Standby
Primary database is in MAXIMUM PERFORMANCE mode
Re-archiving standby log 4 thread 1 sequence 32
2012-03-03 16:56:45.733000 +05:30
Archived Log entry 4 added for thread 1 sequence 32 ID 0x4a53118e dest 1:
RFS[40]: Assigned to RFS process 19113
RFS[40]: Identified database type as 'physical standby': Client is ARCH pid 10428
2012-03-03 16:56:47.136000 +05:30
Media Recovery Log
+FRA/stdy/archivelog/2012_03_03/thread_1_seq_32.266.776969805
2012-03-03 16:56:48.360000 +05:30
RFS[39]: Selected log 4 for thread 1 sequence 33 dbid 1246923666 branch 719142938
2012-03-03 16:56:51.337000 +05:30
Media Recovery Waiting for thread 1 sequence 33 (in transit)
2012-03-03 16:57:12.349000 +05:30
Using STANDBY_ARCHIVE_DEST parameter default value as
USE_DB_RECOVERY_FILE_DEST
2012-03-03 16:57:51.429000 +05:30
RFS[41]: Assigned to RFS process 19150
RFS[41]: Identified database type as 'physical standby': Client is ARCH pid 10428

Real Time Apply

Now create standby redo files if not created (pre-req to enable "Real Time Apply")
SQL> select * from v$logfile;
Configure a Standby Redo Log On Standby
A Standby Redo log is added to enable Data Guard Maximum Availability and Maximum
Protection modes. It is important to configure the Standby Redo Logs (SRL) on Primary
and Standby Database with the same size as the online redo logs.
SQL> SELECT group#, member, status FROM V$LOGfile
SQL> ALTER DATABASE ADD STANDBY LOGFILE size 50M;
Database altered.
SQL> ALTER DATABASE ADD STANDBY LOGFILE size 50M;
Database altered.
SQL> ALTER DATABASE ADD STANDBY LOGFILE size 50M;
Database altered.
SQL> SELECT group#, member, status FROM V$LOGfile;
SQL> select * from v$logfile
where type='STANDBY';

Real Time Apply Enable

Now create standby redo files (pre-req to enable "Real Time Apply")
NOTE:
1)This should match exactly what was done on primary database (see above "Configure
Standby Redo Logs")

2)This is optional in fact the first time around I forgot to create these logs on standby and
recovery process was still working it just reports the following error: RFS[1]: Unable to
open standby log 5: 313 and uses ARCHIVE logs instead
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database recover managed standby database using current logfile
disconnect from session;
Database altered.
Alert log
alter database recover managed standby database using current logfile disconnect from
session
Attempt to start background Managed Standby Recovery process (stdy)
MRP0 started with pid=32, OS id=19330
MRP0: Background Managed Standby Recovery process started (stdy)
2012-03-03 17:03:32.891000 +05:30
started logmerger process
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 2 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Completed: alter database recover managed standby database using current logfile
disconnect from session
2012-03-03 17:03:33.912000 +05:30
Media Recovery Waiting for thread 1 sequence 33 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 33 Reading mem 0
Mem# 0: +DATA/stdy/onlinelog/group_4.265.776967679
Mem# 1: +FRA/stdy/onlinelog/group_4.259.776967685
2012-03-03 17:03:52.680000 +05:30
RFS[47]: Assigned to RFS process 19362
RFS[47]: Identified database type as 'physical standby': Client is ARCH pid 10428
Real Time Apply Disable
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database recover managed standby database disconnect from session;
Database altered.
Alert log
alter database recover managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (stdy)

MRP0 started with pid=32, OS id=19441

MRP0: Background Managed Standby Recovery process started (stdy)
2012-03-03 17:06:07.994000 +05:30
started logmerger process
Managed Standby Recovery not using Real Time Apply
Drill to test Real-time apply:
SQL> select recovery_mode from v$archive_dest_status;
RECOVERY_MODE
----------------------MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
SQL> alter database recover managed standby database cancel;
SQL> alter database recover managed standby database disconnect;
SQL> select recovery_mode from v$archive_dest_status;
RECOVERY_MODE
----------------------MANAGED
MANAGED
Switch logfiles on Primary
SQL> alter system switch logfile;
System altered
On Standby
SQL> select process,status,client_process,sequence#,block#,active_agents,known_agents
from v$managed_standby;
PROCESS STATUS
CLIENT_P SEQUENCE# BLOCK# ACTIVE_AGENTS
KNOWN_AGENTS
PROCESS STATUS
CLIENT_P SEQUENCE# BLOCK# ACTIVE_AGENTS
KNOWN_AGENTS
--------- ------------ -------- ---------- ---------- ------------- -----------RFS
RECEIVING N/A
0
0
0
0
MRP0 WAIT_FOR_LOG N/A
33
0
3
3

PROCESS STATUS
CLIENT_P SEQUENCE# BLOCK# ACTIVE_AGENTS
KNOWN_AGENTS
--------- ------------ -------- ---------- ---------- ------------- -----------RFS
OPENING
LGWR
34
0
0
0
MRP0 APPLYING_LOG N/A
33
29753
3
3
8 rows selected.
SQL>
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM
V$ARCHIVED_LOG ORDER BY FIRST_TIME DESC;
SEQUENCE# FIRST_TIM NEXT_TIME
---------- --------- --------34 03-MAR-12 03-MAR-12
33 03-MAR-12 03-MAR-12
32 03-MAR-12 03-MAR-12
31 03-MAR-12 03-MAR-12
30 03-MAR-12 03-MAR-12
29 03-MAR-12 03-MAR-12
Remember, we could have used Real Time Apply in this case, which causes the changes
made to the primary appear instantly on the standby, provided the network is available?
RTA is not an absolute necessity for ADG but makes the ADG even more useful as you
can expect to see the latest changes on the primary.
Security conscious readers might be little concerned however. The database is in read
only mode, so nothing can be written to it. If the audit_trail parameter is set to DB on the
primary (the default in Oracle Database 11g), it will be the same on standby as well, but
the audit trails can't be written to the database since it's read only. So where do they go?
Note a line that shows up innocuously in alert log:
AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for
database opened with readonly access Aha! The audit trails don't stop; rather, they
automatically switch to OS files when the database is open. When you activate the
standby database, the audit_trail is automatically resets to DB.
11gR2 DataGuard New Features (ABMR)

Oracle 11gR2
Dataguard New Features.doc

Chapter 9
Configuring Data Protection Modes
DRILL Set the Data Protection Mode by Using SQL (Maximum Performance to
Maximum Availability)
Maximum protection: LGWR, SYNC, AFFIRM, and standby redo logs files
Maximum availability: LGWR, SYNC, AFFIRM, and standby redo logs files for
physical standby databases
Maximum performance: Any combination of LGWR or ARCH
Using the following SQL statement on the primary database, you can configure the
Data Guard environment to maximize data protection, availability, or performance:
SQL> SELECT PROTECTION_MODE FROM V$DATABASE;
PROTECTION_MODE
-------------------MAXIMUM PERFORMANCE
SQL> select name, open_mode,protection_mode,protection_level,database_role,switchover_status
from v$database;
NAME
OPEN_MODE
PROTECTION_MODE PROTECTION_LEVEL
DATABASE_ROLE SWITCHOVER_STATUS
--------- -------------------- -------------------- -------------------- ----------------------------------ORCL READ ONLY WITH APPLY MAXIMUM PERFORMANCE MAXIMUM
PERFORMANCE PHYSICAL STANDBY NOT ALLOWED
SQL> show parameter log_archive_dest_2
NAME TYPE VALUE
------------------------------------ ----------- -----------------------------log_archive_dest_2 string SERVICE=STDY
VALID_FOR=(PRIMARY_ROLE,ONLINE_LOGFILES) DB_UNIQUE_NAME=STDY

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=STDY LGWR

SYNC VALID_FOR=(PRIMARY_ROLE,ONLINE_LOGFILES)
DB_UNIQUE_NAME=STDY';
System altered.

SQL> show parameter log_archive_dest_2

NAME TYPE VALUE
------------------------------------ ----------- -----------------------------log_archive_dest_2 string SERVICE=STDY LGWR SYNC VALID_F
OR=(PRIMARY_ROLE,ONLINE_LOGFIL
ES) DB_UNIQUE_NAME=STDY
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE
AVAILABILITY;
SQL> select name, open_mode,protection_mode,protection_level,database_role,switchover_status from
v$database;
NAME
OPEN_MODE
PROTECTION_MODE PROTECTION_LEVEL
DATABASE_ROLE SWITCHOVER_STATUS
--------- -------------------- -------------------- -------------------- ----------------------------------ORCL READ ONLY WITH APPLY MAXIMUM AVAILABILITY
RESYNCHRONIZATION PHYSICAL STANDBY NOT ALLOWED
NAME
OPEN_MODE
PROTECTION_MODE PROTECTION_LEVEL
DATABASE_ROLE SWITCHOVER_STATUS
--------- -------------------- -------------------- -------------------- ----------------------------------ORCL READ ONLY WITH APPLY MAXIMUM AVAILABILITY MAXIMUM
AVAILABILITY PHYSICAL STANDBY NOT ALLOWED
output_protection_m
ode.txt

Downgrading the Protection Mode

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=STDY ARCH

VALID_FOR=(PRIMARY_ROLE,ONLINE_LOGFILES)
DB_UNIQUE_NAME=STDY';
System altered.
SQL> show parameter log_archive_dest_2
NAME TYPE VALUE
------------------------------------ ----------- -----------------------------log_archive_dest_2 string SERVICE=STDY ARCH VALID_FOR=(P
RIMARY_ROLE,ONLINE_LOGFILES) D
B_UNIQUE_NAME=STDY
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE
PERFORMANCE;
Database altered.
SQL> select name,
open_mode,protection_mode,protection_level,database_role,switchover_status from
v$database;
NAME
OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL
DATABASE_ROLE SWITCHOVER_STATUS
--------- ---------- -------------------- -------------------- ---------------- -------------------ORCL READ WRITE MAXIMUM PERFORMANCE MAXIMUM
PERFORMANCE PRIMARY
TO STANDBY
DRILL Set the Data Protection Mode by Using Broker (Maximum Performance to
Maximum Availability)
DGMGRL> EDIT DATABASE orcl SET PROPERTY LogXptMode='SYNC';
DGMGRL> EDIT DATABASE stdy SET PROPERTY LogXptMode='SYNC';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS
MAXAVAILABILITY;
Downgrading the Protection Mode
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS
MAXPERFORMANCE;
Succeeded.
DGMGRL> EDIT DATABASE stdy SET PROPERTY LogXptMode='ASYNC';

Property "logxptmode" updated

DGMGRL> EDIT DATABASE orcl SET PROPERTY LogXptMode='ASYNC';
Property "logxptmode" updated

Chapter 10
Performing Role Transitions
Performing Switchover and Failover
Switchover
SQL> select database_role from v$database;
DATABASE_ROLE
---------------PRIMARY
SQL> select database_role from v$database;
DATABASE_ROLE
---------------PHYSICAL STANDBY
On Standby
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-------------------NOT ALLOWED
On Primary Database
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-------------------TO STANDBY

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY

WITH SESSION SHUTDOWN WAIT;
SQL> SHUTDOWN IMMEDIATE;
SQL> startup mount
ORACLE instance started.
Total System Global Area 452984832 bytes
Fixed Size 1297244 bytes
Variable Size 213910692 bytes
Database Buffers 230686720 bytes
Redo Buffers 7090176 bytes
Database mounted.
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-------------------TO PRIMARY
SQL> select database_role from v$database;
DATABASE_ROLE
---------------PHYSICAL STANDBY
On Standby Database (Should not be in Recovery)
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-------------------SWITCHOVER PENDING
SQL> alter database recover managed standby database cancel;
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
shut down and restart the new primary database.
SQL> select database_role from v$database;
DATABASE_ROLE
---------------PRIMARY

Issue the following statement on the new primary database

SQL> alter database open;
Database altered.
SQL>
SQL> ALTER SYSTEM SWITCH LOGFILE;
Check with archive log list
Or
SQL> select sequence#, first_time, next_time, applied from v$archived_log order by
sequence#;

output_switchover.t
xt

Failover
Check Gaps first
SQL> select protection_mode from v$database;
PROTECTION_MODE
-------------------MAXIMUM PERFORMANCE
SQL>
On Standby
SQL> SELECT thread#, low_sequence#, high_sequence# FROM v$archive_gap;
no rows selected
SQL> select database_role from v$database;
DATABASE_ROLE
---------------PHYSICAL STANDBY
SQL> alter database recover managed standby database finish force;
Database altered.
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Database altered.
SQL> select database_role from v$database;

DATABASE_ROLE
---------------PRIMARY
SQL> select open_mode from v$database;
OPEN_MODE
---------MOUNTED
SQL> alter database open;
Database altered.
SQL> show parameter unique
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------db_unique_name
string
stdy
SQL> select standby_became_primary_scn from v$database;
STANDBY_BECAME_PRIMARY_SCN
-------------------------619042
SQL>

output_failover.txt

Perform a Switchover with DG Broker

Connect to DGMGRL on the observer server:
$ dgmgrl
DGMGRL> connect sys/oracle@ORCL
Connected.
DGMGRL>
Check that primary and standby are healthy. This check must return 'SUCCESS' as the
status for both databases, otherwise it means there is a configuration problem.
DGMGRL> show database ORCL;

Database
Name:
orcl
Role:
PRIMARY
Enabled:
YES
Intended State: TRANSPORT-ON
Instance(s):
orcl
Current status for "orcl":
SUCCESS
DGMGRL>
DGMGRL> show database STDY;
Database
Name:
stdy
Role:
PHYSICAL STANDBY
Enabled:
YES
Intended State: APPLY-ON
Instance(s):
stdy
Current status for "stdy":
SUCCESS
DGMGRL>
Execute the switchover
DGMGRL> SWITCHOVER TO STDY;
DGMGRL> show database STDY;
Database
Name: stdy
Role: PRIMARY
Enabled: YES
Intended State: ONLINE
Instance(s):
stdy
Current status for "stdy":
SUCCESS
DGMGRL>
DGMGRL> show database ORCL;

Database
Name: orcl
Role: PHYSICAL STANDBY
Enabled: YES
Intended State: ONLINE
Instance(s):
orcl
Current status for "orcl":
SUCCESS
DGMGRL>
DGMGRL> SHOW CONFIGURATION VERBOSE;
Configuration
Name: orcl
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
orcl - Physical standby database
- Fast-Start Failover target
stdy - Primary database
Fast-Start Failover
Threshold: 30 seconds
Observer: punjab-cc977a23
Shutdown Primary: TRUE
Current status for "orcl":
SUCCESS
DGMGRL>
Performing a Manual Failover with DG Broker

Reinstate Failed.txt

Chapter 11
Flashback standby after resetlogs on primary

FLASHBACK
STANDBY AFTER RESETLOGS ON PRIMARY.txt

Chapter 12

Enabling Fast Start Failover and the Observer

Ensure standby redo logs are configured on both primary and standby databases
SQL> SELECT GROUP#, BYTES/1024, STATUS FROM V$STANDBY_LOG;

Ensure the LogXptMode Property is set to SYNC

DGMGRL> EDIT DATABASE ORCL SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated
DGMGRL>
DGMGRL> EDIT DATABASE STDY SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated
DGMGRL>
Alert log
ALTER SYSTEM SET log_archive_dest_2='service="stdy"','LGWR SYNC AFFIRM
delay=0 optional compression=disable max_failure=0 max_connections=1 reopen=300
db_unique_name="stdy" net_timeout=30','valid_for=(all_logfiles,primary_role)'
SCOPE=BOTH;
ALTER SYSTEM SWITCH ALL LOGFILE start (orcl)
Thread 1 cannot allocate new log, sequence 72
Checkpoint not complete
Current log# 2 seq# 71 mem# 0: +DATA/orcl/onlinelog/group_2.264.719142951
Current log# 2 seq# 71 mem# 1: +DATA/orcl/onlinelog/group_2.265.719142957
2012-08-28 17:34:32.652000 +05:30
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
******************************************************************
LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
******************************************************************
NSS2 started with pid=43, OS id=29520
2012-08-28 17:34:36.838000 +05:30
LGWR: Standby redo logfile selected for thread 1 sequence 72 for destination
LOG_ARCHIVE_DEST_2
ALTER SYSTEM SWITCH ALL LOGFILE complete (orcl)
Thread 1 advanced to log sequence 72 (LGWR switch)
Current log# 3 seq# 72 mem# 0: +DATA/orcl/onlinelog/group_3.266.719142961
Current log# 3 seq# 72 mem# 1: +DATA/orcl/onlinelog/group_3.267.719142965
Archived Log entry 105 added for thread 1 sequence 71 ID 0x4a53118e dest 1:
2012-08-28 17:34:39.158000 +05:30

Specify the FastStartFailoverTarget property

DGMGRL> EDIT DATABASE ORCL SET PROPERTY
FastStartFailoverTarget='STDY';
Property "faststartfailovertarget" updated
DGMGRL> EDIT DATABASE STDY SET PROPERTY
FastStartFailoverTarget='ORCL';
Property "faststartfailovertarget" updated
DGMGRL>
Upgrade the protection mode to MAXAVAILABILITY, if necessary.
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS
MAXAVAILABILITY;
Succeeded.
DGMGRL>
ENABLE FAST START FAILOVER
DGMGRL> show configuration;
Configuration
Name: orcl
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: DISABLED
Databases:
orcl - Primary database
stdy - Physical standby database
Current status for "orcl":
SUCCESS
DGMGRL> SHOW DATABASE STDY;
Database
Name:
stdy
Role:
PHYSICAL STANDBY
Enabled:
YES
Intended State: APPLY-ON
Instance(s):
stdy
Current status for "stdy":
SUCCESS

DGMGRL> ENABLE FAST_START FAILOVER;

Enabled.
DGMGRL>
Alert log
2012-03-04 17:25:35.344000 +05:30
FSFP started with pid=45, OS id=3550
DGMGRL> SHOW CONFIGURATION;
Configuration - orcl_stdy
Protection Mode: MaxAvailability
Databases:
orcl - Primary database
Warning: ORA-16819: fast-start failover observer not started
stdy - (*) Physical standby database
Warning: ORA-16819: fast-start failover observer not started
Fast-Start Failover: ENABLED
Configuration Status:
WARNING
Start the observer
From Another Terminal Start Observer and let it run connect. May need to bounce
Listener once.
$ dgmgrl
DGMGRL> connect sys/oracle
Connected.
DGMGRL>
DGMGRL> start observer
Observer started
OR

To start Observer in background

$ dgmgrl -logfile ./observer_log
DGMGRL> connect sys/oracle
Connected.
DGMGRL> start observer
From another session
$ tail -100f observer_log
$ ps -ef|grep observer
oracle 24282 23873 0 09:11 pts/6 00:00:00 rlwrap dgmgrl sys/oracle@orcl start
observer
oracle 24283 24282 0 09:11 pts/7 00:00:00 dgmgrl
start observer
oracle 24320 23873 0 09:12 pts/6 00:00:00 tail -100f observer_log
oracle 24363 24338 0 09:12 pts/8 00:00:00 grep observer
[oracle@server ~]$
Verify the fast-start failover configuration
DGMGRL> SHOW CONFIGURATION VERBOSE;
Configuration - orcl_stdy
Protection Mode: MaxAvailability
Databases:
orcl - Primary database
stdy - (*) Physical standby database
(*) Fast-Start Failover target
Fast-Start Failover: ENABLED
Threshold:
30 seconds
Target:
stdy
Observer:
11gr2.rhel5.com
Lag Limit:
30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Configuration Status:
SUCCESS

DGMGRL> SHOW DATABASE STDY;

Database - stdy
Role:
PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag:
0 seconds
Real Time Query: OFF
Instance(s):
stdy
Database Status:
SUCCESS

output_dgbroker.txt

Perform Fast_Start_Failover
DGMGRL> show fast_start failover;
Fast-Start Failover: ENABLED
Threshold:
30 seconds
Target:
stdy
Observer:
11gr2.rhel5.com
Lag Limit:
30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile
YES
Corrupted Dictionary
YES
Inaccessible Logfile
NO
Stuck Archiver
NO
Datafile Offline
YES
Oracle Error Conditions:
(none)

DGMGRL> EDIT CONFIGURATION SET PROPERTY

FASTSTARTFAILOVERLAGLIMIT=45;
Property "faststartfailoverlaglimit" updated
DGMGRL> show fast_start failover;
Fast-Start Failover: ENABLED
Threshold:
30 seconds
Target:
stdy
Observer:
11gr2.rhel5.com
Lag Limit:
45 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile
YES
Corrupted Dictionary
YES
Inaccessible Logfile
NO
Stuck Archiver
NO
Datafile Offline
YES
Oracle Error Conditions:
(none)
SQL> select database_role from v$database;
DATABASE_ROLE
---------------PRIMARY
On Primary
SQL> shutdown abort
On Standby
SQL> select database_role from v$database;
DATABASE_ROLE
---------------PHYSICAL STANDBY

See the Observer Terminal

DGMGRL> start observer
Observer started
10:28:52.96 Sunday, June 21, 2009
Initiating fast-start failover to database "stdy"...
Performing failover NOW, please wait...
Failover succeeded, new primary is "stdy"
12:46:39.08 Sunday, June 21, 2009
Hangup
On Standby
SQL> select database_role from v$database;
DATABASE_ROLE
---------------PRIMARY
Before Failover on Standby
SQL> SELECT fs_failover_status, fs_failover_current_target, fs_failover_threshold,
fs_failover_observer_present, fs_failover_observer_host FROM v$database;
FS_FAILOVER_STATUS FS_FAILOVER_CURRENT_TARGET
FS_FAILOVER_THRESHOLD FS_FAIL FS_FAILOVER_OBSERVER_HOST
--------------------- ------------------------------ --------------------- --------------------------------------------------------------SYNCHRONIZED
stdy
30 YES server.rhel5.com
Before Reinstating on New Primary but After Failover
SQL> SELECT fs_failover_status, fs_failover_current_target, fs_failover_threshold,
fs_failover_observer_present, fs_failover_observer_host FROM v$database;
FS_FAILOVER_STATUS FS_FAILOVER_CURRENT_TARGET
FS_FAILOVER_THRESHOLD FS_FAIL FS_FAILOVER_OBSERVER_HOST
-----------------------------------------------------------------------------------------------------------------------------------------------------------------REINSTATE REQUIRED orcl
30 YES server.rhel5.com
On Old Primary
SQL> startup
ORACLE instance started.

Total System Global Area 213909504 bytes

Fixed Size
1266656 bytes
Variable Size
83889184 bytes
Database Buffers
125829120 bytes
Redo Buffers
2924544 bytes
Database mounted.
ORA-16649: database will open after Data Guard broker has evaluated Fast-Start
Failover status
SQL> SQL> SELECT fs_failover_status, fs_failover_current_target,
fs_failover_threshold, fs_failover_observer_present, fs_failover_observer_host FROM
v$database;
FS_FAILOVER_STATUS FS_FAILOVER_CURRENT_TARGET
FS_FAILOVER_THRESHOLD FS_FAIL FS_FAILOVER_OBSERVER_HOST
---------------------- ------------------------------ --------------------- -------------------------------------------------------------------------------------BYSTANDER
30 YES

SQL> show parameter unique

NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------db_unique_name
string
ORCL
SQL> select database_role from v$database;
DATABASE_ROLE
---------------PHYSICAL STANDBY
SQL> select open_mode from v$database;
OPEN_MODE
---------READ ONLY
SQL>
On Observer Host
DGMGRL> connect sys/oracle@ORCL
Connected.

DGMGRL> START OBSERVER

Error: ORA-16795: database resource guard detects that database re-creation is required
Observer started
11:55:51.63 Sunday, June 21, 2009
Initiating reinstatement for database "orcl"...
Reinstating database "orcl", please wait...
Operation requires shutdown of instance "ORCL" on database "orcl"
Shutting down instance "ORCL"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "ORCL" on database "orcl"
Starting instance "ORCL"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "orcl" ...
Reinstatement of database "orcl" succeeded
11:57:15.24 Sunday, June 21, 2009
Hangup
After Reinstating on New Primary
SQL> SELECT fs_failover_status, fs_failover_current_target, fs_failover_threshold,
fs_failover_observer_present, fs_failover_observer_host FROM v$database;
FS_FAILOVER_STATUS FS_FAILOVER_CURRENT_TARGET
FS_FAILOVER_THRESHOLD FS_FAIL FS_FAILOVER_OBSERVER_HOST
--------------------- ------------------------------ --------------------- --------------------------------------------------------------SYNCHRONIZED
orcl
30 NO linux.com
On Old Primary
SQL> select database_role from v$database;
DATABASE_ROLE
---------------PHYSICAL STANDBY
SQL> show parameter db_unique
NAME
TYPE
VALUE
------------------------------------ ----------db_unique_name
string
ORCL
SQL>
Dataguard Broker Configuration after reinstating

DGMGRL> connect sys/oracle@ORCL

Connected.
DGMGRL> SHOW CONFIGURATION;
Configuration
Name:
orcl
Enabled:
YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
orcl - Physical standby database
- Fast-Start Failover target
stdy - Primary database
Current status for "orcl":
SUCCESS
DGMGRL>
Disable Fast Start Failover
DISABLE FAST-START FAILOVER;
Application Triggered FSFO

Application
Triggered FSFO.doc

Chapter 13
Managing Client Connectivity

Managing Client
Connectivity.txt

If the prmy service does not start. Set the local_listener value to null as it is only needed
for Non-default listener port to do dynamic registeration with the service.
Chapter 14
Backup and Recovery Considerations in an Oracle Data Guard Configuration

DRILL FOR CREATING RMAN CATALOG

Before creating the catalog user we want to create a catalog database cat & tablespace
rcat_ts to hold the catalog.
On Primary Host Machine
Create database using dbca & create tablespace rcat_ts having 100MB datafile and give
200MB memory to this database.
CREATE TABLESPACE rcat_ts
DATAFILE '/u01/app/oracle/rcat_ts.dbf'
SIZE 100M AUTOEXTEND ON NEXT 1M;
SQL> Create user rcat identified by rcat
Default tablespace rcat_ts
Temporary tablespace temp
Quota unlimited on rcat_ts;
SQL> Grant recovery_catalog_owner to rcat;
STEPS TO BE FOLLOWED BEFORE CONNECTING
Database should be in archive log mode
Configure Listeners & Service names of both the target and catalog database

listener & tnsnames

files.txt

Recovery catalog database should be always up and running

Target database should be in the mount phase (to read control files)
CREATING RMAN CATALOG
$ RMAN
RMAN > Connect target sys/oracle@orcl
RMAN > Connect catalog rcat/rcat@cat
RMAN > Create catalog tablespace rcat_ts;
RMAN > Register database;
RMAN> list db_unique_name of database;
List of Databases
DB Key DB Name DB ID

Database Role

Db_unique_name

------- ------- ----------------- --------------- -----------------2

ORCL 1246923666
PRIMARY
ORCL
RMAN> report schema for db_unique_name orcl;
RMAN> list archivelog all for db_unique_name orcl;
RMAN> show all for db_unique_name orcl;

Configuring RMAN Parameters

In your RMAN session (connected to your primary database), configure the backup
retention policy to allow for recovery for seven days
RMAN> configure retention policy to recovery window of 7 days;
Specify that archived redo log files can be deleted after they are applied to the
standby database.
RMAN> configure archivelog deletion policy to applied on all standby;
Configure the connect identifier for your primary database.
RMAN> configure db_unique_name orcl connect identifier 'orcl';
Configure the connect identifier for your physical standby database.
RMAN> configure db_unique_name stdy connect identifier 'stdy';
RMAN> list db_unique_name of database;
List of Databases
DB Key DB Name DB ID
Database Role Db_unique_name
------- ------- ----------------- --------------- -----------------2
ORCL 1246923666
PRIMARY
ORCL
2
ORCL 1246923666
STANDBY
STDY
RMAN> report schema for db_unique_name stdy;
Report of database schema for database with db_unique_name STDY

List of Permanent Datafiles

===========================
File Size(MB) Tablespace
RB segs Datafile Name
---- -------- -------------------- ------- -----------------------1 680
SYSTEM
YES
2 520
SYSAUX
NO
3 150
UNDOTBS1
YES
4 5
USERS
NO
5 100
EXAMPLE
NO

Invoke RMAN again and connect to your physical standby database and the recovery
catalog.
$ rman target sys/oracle@stdy catalog rcat/rcat@cat
RMAN> show all for db_unique_name stdy;
Configure automatic backup of the control file and the server parameter file.
RMAN> configure controlfile autobackup on;
Configure backup optimization.
RMAN> configure backup optimization on;
Set the archived log deletion policy to BACKED UP 1 TIMES TO DEVICE TYPE
DISK.
RMAN> configure archivelog deletion policy to backed up 1 times to device type disk;

Recovering a Data File in Your Primary Database

In this practice, you recover a data file in your primary database by using a data file from
your physical standby database. ASM will not let you delete or rename a data file being
used by the database. For this reason, you will create a new data file outside of ASM in
order to simulate a disaster
On Primary
SQL> create tablespace example2 datafile '/home/oracle/example2.dbf' size 5M;

On Standby
SQL> show parameter standby_file_management
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------standby_file_management
string AUTO
Alert log of standby
Successfully added datafile 6 to media recovery
Datafile #6: '+DATA/stdy/datafile/example2.269.811884835'
Datafile 6 added to flashback set
SQL> select file#,name from v$datafile;
On Primary
SQL> create table hr.employees2 tablespace example2 as select * from hr.employees;
On Primary
$ cd /home/oracle
$ ls -la example2.dbf
-rw-r----- 1 oracle dba 5251072 Apr 4 19:36 example2.dbf
$ mv example2.dbf example3.dbf
$ sqlplus hr/hr
SQL> select * from employees2;
select * from employees2
*
ERROR at line 1:
ORA-01116: error in opening database file 6
ORA-01110: data file 6: '/home/oracle/example2.dbf'
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3
Invoke RMAN and connect to your physical standby database as the target and your
primary database as the auxiliary database

$ rman target sys/oracle@stdy auxiliary sys/oracle@orcl

connected to target database: ORCL (DBID=1246923666)
connected to auxiliary database: ORCL (DBID=1246923666)

Back up data file 6 from the physical standby database host to a new location named
/home/oracle/newex01.dbf on your primary database host.
RMAN> backup as copy datafile 6 auxiliary format '/home/oracle/newex01.dbf';

Invoke RMAN again. Connect to your primary database as the target and to the
recovery catalog
$ rman target sys/oracle@orcl catalog rcat/rcat@cat
connected to target database: ORCL (DBID=1246923666)
connected to recovery catalog database
Catalog the data file copy
RMAN> catalog datafilecopy '/home/oracle/newex01.dbf';
Take the tablespace offline
RMAN> sql 'alter tablespace example2 offline immediate';
Use the RMAN SET NEWNAME and SWITCH DATAFILE commands to update the
data file name in the RMAN repository
RMAN> run {
set newname for datafile 6 to
'/home/oracle/newex01.dbf';
switch datafile 6;
}
RMAN> recover tablespace example2;
Bring the tablespace online
RMAN> sql 'alter tablespace example2 online';

Chapter 15
Patching and Upgrading Databases in a Data Guard Configuration
Rolling Upgrade
It's no secret that one of the pain points in a DBA's job is to justify the need to shut down
the database for a reasonably long period of time to perform upgrades. In Oracle
Database 11g, this has become considerably easier if you have a standby database of any
type via this rolling upgrade process:
1. Upgrade the standby.
2. Move the apps to the standby.
3. Upgrade the primary.
4. Move the apps back to the original primary.
If it's a logical standby, the process is fairly straightforward because the standby merely
applies the SQLs mined from the primary. As the SQLs are applied, the upgrade can
easily be done on that database. You can stop the recovery, upgrade the standby, continue
the recovery to catch up, and then convert the standby to primary. Later, you can make
the original primary to be the standby, which will be upgraded. Finally, you reverse the
roles to make the original primary the new primary.
However, many standby databases are physical in nature for ease of use and management.
If the standby is not logical but physical, then the steps are pretty much the same, with a
slight difference: you need to convert the standby to logical temporarily and then convert
back to physical standby.
The keyword is temporarily, not permanently; therefore you issue the conversion
command with the new clause "keep identity", as shown below:
SQL> alter database recover to logical standby keep identity;
Database altered.
11g Release 2 Rolling Upgrade using Transient Logical Standby database
This note illustrates how we can perform a rolling upgrade from Oracle 11g Release 1
to Oracle 11g Release 2 using a Transient Logical Standby database. This approach will
miminise the downtime required for an upgrade which can potentially run into several
hours down to just the time required to perform a switchover which could be a few
minutes in most cases.
A rolling upgrade using a Transient Logical Standby database at a very high level will
involve three main stages or steps:
1) Temporarily convert a physical standby database to a logical standby database using
the new KEEP IDENTITY clause

2) Perform a database upgrade of the logical standby database

3) Return the logical standby database back to its identity or original status as a physical
standby database once the upgrade is complete
The assumption here is that .
1)We already have configured a Physical Standby Database using Data Guard best
practices and both Primary and Standby databases are in sync and Redo Transport and
Redo Apply are working properly.
2)Data Guard Broker if configured is disabled
3) Standby database is operating in Maximum Availability or Maximum Protection mode
4) Flashback Database is enabled

Chapter 16
Monitoring a Data Guard Broker Configuration
Some Important Scripts
On Primary
select dest_id,dest_name,status,database_mode, error from v$archive_dest_status;
Standby database
SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG
where applied='NO';
Standby database
select SEQUENCE# ,REGISTRAR,ARCHIVED,APPLIED ,status from v$archived_log
where sequence#>(select max(sequence#)-20 from v$log_history);
SEQUENCE# REGISTR ARC APPLIED S
---------- ------- --- --------- 29 RFS YES YES
A
30 RFS YES YES
A
31 RFS YES YES
A
32 RFS YES YES
A
33 RFS YES YES
A
34 RFS YES YES
A
35 RFS YES YES
A
36 RFS YES YES
A

Check transport Lag +++

Run this script on primary database
SELECT (SELECT name FROM V$DATABASE),
(SELECT MAX (sequence#)
FROM v$archived_log
WHERE dest_id = 1)
Current_primary_seq,
(SELECT MAX (sequence#)
FROM v$archived_log
WHERE trunc(next_time) > SYSDATE - 1
AND dest_id = 2)
max_stby,
(SELECT NVL (
(SELECT MAX (sequence#) - MIN (sequence#)
FROM v$archived_log
WHERE trunc(next_time) > SYSDATE - 1
AND dest_id = 2
AND applied = 'NO'),
0)
FROM DUAL)
"To be applied",
( (SELECT MAX (sequence#)
FROM v$archived_log
WHERE dest_id = 1)
- (SELECT MAX (sequence#)
FROM v$archived_log
WHERE dest_id = 2))
"To be Shipped"
FROM DUAL;
(SELECTNA CURRENT_PRIMARY_SEQ MAX_STBY To be applied To be Shipped
--------- ------------------- ---------- ------------- ------------ORCL
36
0
0
Show message
Run this query on primary database.
select message, timestamp from v$dataguard_status where dest_id = 2;
MESSAGE
--------------------------------------------------------------------------------

TIMESTAMP
--------PING[ARC2]: Heartbeat failed to connect to standby 'STDY'. Error is 12505.
29-AUG-12
FAL[server, ARC3]: Error 12505 creating remote archivelog file 'STDY'
29-AUG-12
FAL[server, ARC3]: Error 12505 creating remote archivelog file 'STDY'
29-AUG-12

Is physical standby currently performing managed recovery?

select process, status from v$managed_standby;
PROCESS STATUS
--------- -----------ARCH
CLOSING
ARCH
CLOSING
ARCH
CONNECTED
ARCH
CLOSING
ARCH
CLOSING
RFS
IDLE
RFS
IDLE
MRP0 APPLYING_LOG
RFS
IDLE
Check level of synchronization
select archived_thread#, archived_seq#, applied_thread#, applied_seq# from
v$archive_dest_status;
ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ#
---------------- ------------- --------------- -----------1
36
0
0
1
36
1
35
1
36
0
0
1
36
0
0
Set sqlplus prompt for standby database
login.sql

column global_name new_value gname

select lower(user) || '@' ||
lower(substr( global_name, 1, decode( dot,
0, length(global_name),
dot-1) )) global_name
from (select global_name, instr(global_name,'.') dot
from global_name );
set sqlprompt '&gname> '
I use the script below to extract DB_UNIQUE_NAME from USERENV namespace
of a session.
column value new_value newsqlprompt
with a as
(select sys_context('USERENV', 'DB_UNIQUE_NAME') db_uniq_name from dual)
select lower(user || '@' || db_uniq_name) value from a;
set sqlprompt '&newsqlprompt> '
Chapter 17
Optimizing a Data Guard Configuration
Redo Compression
Data Guard is premised on shipping the archived logs from the primary to the standby
database server and applying them to the database. One of the key components of the
time lag between the primary and standby is the time to transport the archived logs. This
can be somewhat expedited If the redo stream is compressed.
In Oracle Database 11g you can compress the redo stream that goes across to the standby
server via SQL*Net using a parameter compression set to true. This works only for the
logs shipped during the gap resolution. Here is the command you can use to enable
compression in the example shown in the beginning of this installment.
alter system set log_archive_dest_2 = 'service=stdy LGWR ASYNC
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=stdy
compression=enable'
Net Timeout
The Data Guard environment works by sending the redo data to the standby server by
connecting to the database instance there. If the instance does not respond in time, the log
shipping service will wait for a specified timeout value and then give up. This timeout

value can be set in Oracle Database, using a parameter called net_timeout. In maximum
protection mode, the log shipping service will retry for 20 times before giving up.
But first you have to know who much delay is currently present in the log shipping. A
new view v$redo_dest_resp_histogram shows that time in histograms of values:
SQL> desc v$redo_dest_resp_histogram
Name Null? Type
---------------------- ------- -------------DEST_ID NUMBER
TIME VARCHAR2(20)
DURATION NUMBER
FREQUENCY NUMBER
The view shows you how many times the time was taken in the shipment in that given
bucket. If you examine the view after a few days of operation, you will be able to get an
idea of the timeout value to set. Then you can set the set the timeout value by issuing:
alter system set log_archive_dest_2 = 'service=stdy LGWR ASYNC
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=stdy
compression=enable net_timeout=20'
Again, this is from the example shown above. Note the clause "net_timeout=20" in the
parameter value.
Dynamically Alterable Parameters
In the process of operating a logical standby database environment, you will need to tune
the process and tweak some parameter values. In Oracle Database 11g, most of these
parameters can be updated online. You can find them by querying the view
dba_logstdby_parameters.
col name format a30
col value format a10
col unit format a10
col setting format a6
col dynamic format a7

SQL> select *
from dba_logstdby_parameters
order by name;
NAME

VALUE

UNIT

SETTING

DYNAMIC

------------------------------ -------------------- ----------------------------------------------------------------------------------- ----APPLY_SERVERS

5
SYSTEM YES
EVENT_LOG_DEST
DEST_EVENTS_TABLE
SYSTEM YES
LOG_AUTO_DELETE
TRUE
SYSTEM YES
LOG_AUTO_DEL_RETENTION_TARGET 1440
MINUTE
SYSTEM YES
MAX_EVENTS_RECORDED
10000
SYSTEM YES
MAX_SERVERS
9
SYSTEM YES
MAX_SGA
30
MEGABYTE
SYSTEM YES
PREPARE_SERVERS
1
SYSTEM YES
PRESERVE_COMMIT_ORDER
TRUE
SYSTEM
NO
RECORD_APPLIED_DDL
FALSE
SYSTEM YES
RECORD_SKIP_DDL
TRUE
SYSTEM YES
RECORD_SKIP_ERRORS
TRUE
SYSTEM YES
RECORD_UNSUPPORTED_OPERATIONS FALSE
SYSTEM YES
Note the column DYNAMIC, which shows the value is dynamic alterable or not. Almost
all the parameters are dynamic. For instance, to modify the parameter APPLY_SERVERS
without stopping standby, you can issue:
SQL> begin
2 dbms_logstdby.apply_set('APPLY_SERVERS',2);
3 end;
4/
This sets the value of apply_servers to 2, which can be done without shutting down the
standby.
SQL Apply Event Table
In Oracle Database 10g, the events related to SQL Apply are written to the alert log,
which is not very useful since you may want to write scripts to check them for alerts or
reporting. In Oracle Database 11g, the events are by default written to a new table called
LOGSTDBY$EVENTS in the SYSTEM schema. Here is a sample query:
select event_time, error
from system.logstdby$events
order by 1;
EVENT_TIME
ERROR
------------------------------------------------------------------------------------------------------------------------------------------30-AUG-09 05.54.32.707066 PM
ORA-16111: log mining
and apply setting up
30-AUG-09 05.54.32.750806 PM
Apply LWM 623981,
HWM 623981, SCN 623981

30-AUG-09 06.05.24.738491 PM
initiated stop apply successfully completed
31-AUG-09 09.01.12.427823 AM
and apply setting up
31-AUG-09 09.01.12.445669 AM
HWM 625224, SCN 625244
31-AUG-09 09.01.17.914841 AM
skipped due to lack of support

ORA-16128: User
ORA-16111: log mining
Apply LWM 625224,
ORA-16226: DDL

It's very useful to have the events in a table for a lot of reasons; for one; it's easier to
manipulate and report. But sometimes it's also useful to see them on alert log as well,
especially if you have built on some monitoring tool to scan the alert log for errors and
messages. You can set the logical standby database apply parameter "event_log_dest" to
"DEST_ALL" to accomplish that:
begin
dbms_logstdby.apply_set('EVENT_LOG_DEST','DEST_ALL');
end;
This can be done dynamically and now the events will go to both the table and the alert
log. After this command, you can check alert log; it will have alt least these two lines, in
addition to possibly a large number of SQL Apply events:
LOGSTDBY: APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL
LOGSTDBY status: EVENT_LOG_DEST changed to DEST_ALL
Fix the bug if there is an error.

bug.txt

Data Guard & Oracle Restart in 11gR2

$ srvctl add database -d stdy -o /u01/app/oracle/product/11.2.0/db_1 -r
PHYSICAL_STANDBY -s MOUNT
$ srvctl config database -d stdy
Database unique name: stdy
Database name:
Oracle home: /u01/app/oracle/product/11.2.0/db_1
Oracle user: oracle
Spfile:
Domain:
Start options: MOUNT

Stop options: immediate

Database role: PHYSICAL_STANDBY
Management policy: AUTOMATIC
Disk Groups:
Services:
ROLE BASED SERVICES
I will now add an Application Service to my Configuration but without having
to use DBMS_SERVICE. Instead, Oracle Restart will take care for the start of
the services in my Data Guard environment according to the assigned
Database Role. The creation of a Database Trigger for that purpose is no
longer necessary. Instead, the usage of Oracle Restart is recommended:
On Primary
$ srvctl add service -d orcl -s orclserv -l PRIMARY -e SELECT -m BASIC -y
AUTOMATIC
$ srvctl modify service -d orcl -s orclserv -z 180 -w 1
$ srvctl config service -d orcl -s orclserv -a
Service name: orclserv
Service is enabled
Cardinality: SINGLETON
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: SELECT
Failover method: BASIC
TAF failover retries: 180
TAF failover delay: 1
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
On Standby
The same has to be done for the Standby Database also the -l PRIMARY
parameter takes care that the service will not be offered unless this database
becomes Primary:
$ srvctl add service -d stdy -s orclserv -l PRIMARY -e SELECT -m BASIC -y
AUTOMATIC
$ srvctl modify service -d stdy -s orclserv -z 180 -w 1
$ srvctl config service -d stdy -s orclserv a

Service name: orclserv

Service is enabled
Cardinality: SINGLETON
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: SELECT
Failover method: BASIC
TAF failover retries: 180
TAF failover delay: 1
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
On Primary
$ srvctl start service -d orcl -s orclserv
On Standby
$srvctl start service -d stdy -s orclserv
On Primary ONLY service is running.
[oracle@11gr2 dbs]$ lsnrctl status
LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 30-AUG-2012 16:20:47
Copyright (c) 1991, 2009, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)
(KEY=EXTPROC1521)))
STATUS of the LISTENER
-----------------------Alias
LISTENER
Version
TNSLSNR for Linux: Version 11.2.0.1.0 - Production
Start Date
29-AUG-2012 12:35:58
Uptime
1 days 3 hr. 44 min. 49 sec
Trace Level
off
Security
ON: Local OS Authentication
SNMP
OFF
Listener Parameter File
/u01/app/oracle/product/11.2.0/grid/network/admin/listener.ora
Listener Log File
/u01/app/oracle/diag/tnslsnr/11gr2/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=11gr2.rhel5.com)
(PORT=1521)))
Services Summary...
Service "+ASM" has 1 instance(s).
Instance "+ASM", status READY, has 1 handler(s) for this service...
Service "orcl.rhel5.com" has 1 instance(s).
Instance "orcl", status READY, has 1 handler(s) for this service...
Service "orclXDB.rhel5.com" has 1 instance(s).
Instance "orcl", status READY, has 1 handler(s) for this service...
Service "orcl_DGB.rhel5.com" has 1 instance(s).
Instance "orcl", status READY, has 1 handler(s) for this service...
Service "orclserv.rhel5.com" has 1 instance(s).
Instance "orcl", status READY, has 1 handler(s) for this service...
The command completed successfully
Service will run on Standby when Switchover will be done.

Miscellaneous Drills
Executing SQL statements from within the Data Guard broker (DGMGRL). This
new feature became available after installing the first Oracle Database 11g release 2
patchset (11.2.0.2.0).
DGMGRL> help sql
DGMGRL> sql "alter system switch logfile";
DGMGRL> sql "alter database open";
Recovering a lost Data Guard broker configuration file (ORA-16572)
In most situation recovering lost Data Guard broker configuration files is handled
automatically by the broker itself, but can be manually triggered by forcing an update to
the broker configuration. Only in case of the loss of all broker configuration files on the
primary database user intervention is required. All we need to do is copy a broker
configuration file from one of its standby databases to the primary database followed by
re-enabling any disabled databases.
Resizing datafiles with Data Guard
A resize of a datafile on the primary database would also be reproduced at the standby
database
Adding Tablespaces/Datafiles with Logical Standby DB present
If we have a Logical Standby Database and want to add datafiles to the primary, while the
Logical Standby DB uses an other directory structure than the Primary. Putting the

parameter standby_file_management to auto and also setting db_file_name_convert

appropriately is not sufficient in this case, as it is for a Physical Standby Database
Connect to the Logical Standby DB as sys and then
SQL> create or replace procedure sys.handle_tbs_ddl
(
old_stmt in varchar2,
stmt_typ in varchar2,
schema in varchar2,
name in varchar2,
xidusn in number,
xidslt in number,
xidsqn in number,
action out number,
new_stmt out varchar2
) as
begin
new_stmt := replace(old_stmt,
'/home/oracle/prima',
'/home/oracle/logst');
action := dbms_logstdby.skip_action_replace;
exception
when others then
action := dbms_logstdby.skip_action_error;
new_stmt := null;
end;
/
SQL> alter database stop logical standby apply;
SQL> begin
dbms_logstdby.skip (stmt=>'tablespace',proc_name=>'sys.handle_tbs_ddl');
end;
/
SQL> alter database start logical standby apply immediate;
Record DDL Statements in DBA_LOGSTDBY_EVENTS & alert.log
SQL> exec dbms_logstdby.apply_set('RECORD_APPLIED_DDL','TRUE')
PL/SQL procedure successfully completed.

SQL> exec dbms_logstdby.apply_set('EVENT_LOG_DEST','DEST_ALL')

PL/SQL procedure successfully completed.
SQL> connect scott/tiger
Connected.
SQL> create table test as select * from dept;
Table created.
Check alert logs

Performance Impact of Logical Standby on the Primary

A special case is the use of a Logical Standby Database, because there is an additional
possible Performance Impact, regardless of the protection level: Because the actualization
of the Logical Standby is done with SQL Apply, more Redo is generated on the Primary
to enable the retrievement of the changed rows on the Standby. With Physical Standby,
that is not necessary, because the ROWID recorded on the Primary is the same on the
Standby. But on Logical Standby Databases, rows can reside in completely different
blocks, so the ROWID from the Primary is meaningless.
Therefore, with Logical Standby present, at least additionally the Primary Key resp. a
Unique Column of rows, modified on the Primary Database is recorded. If there is no
Primary Key on the table where rows where modified, we record all columns
additionally. So depending on the number of columns and the absence of Primary Keys
resp. Unique Columns on the production system, a Logical Standby may significantly
impact the performance of the Primary Database. Fortunately, we can test that
easily before we actually implement a Logical Standby this posting is designed to show
how to do that.
Delete/Clean Data Guard Broker Configuration
$ dgmgrl sys/oracle@orcl
DGMGRL> show configuration
On Primary & Standby
SQL> alter system set dg_broker_start=false;
Then delete the Broker Config Files.

$ rm $ORACLE_HOME/dbs/dr*
SQL> alter system set dg_broker_start=true;
$ dgmgrl sys/oracle@orcl
DGMGRL> create configuration orcl_stdy as primary database is orcl connect identifier
is orcl;
DGMGRL> add database stdy as connect identifier is stdy maintained as physical;
DGMGRL> enable configuration;
DGMGRL> enable database stdy;
Monitoring the Data Guard Broker Configuration
If we receive any error or warnings we can obtain more information about the same
running the commands as shown below. In this case there is no output seen because
currently we are not experiencing any errors or warning.
DGMGRL> show database orcl statusreport
DGMGRL> show database orcl logxptstatus
DGMGRL> show database orcl InconsistentProperties
Errors: Warning: ORA-16792
DGMGRL> show configuration;
Configuration - orcl_stdy
Protection Mode: MaxAvailability
Databases:
orcl - Primary database
stdy - Physical standby database
Warning: ORA-16792: configurable property value is inconsistent with database
setting
Fast-Start Failover: DISABLED
Configuration Status:
WARNING

DGMGRL> show database stdy InconsistentProperties

INCONSISTENT PROPERTIES
INSTANCE_NAME
PROPERTY_NAME
MEMORY_VALUE
SPFILE_VALUE
BROKER_VALUE
stdy ArchiveLagTarget
0
0
stdy LogArchiveMinSucceedDest
1

DGMGRL> edit database stdy set PROPERTY LOGARCHIVEMINSUCCEEDDEST=1;

Property "logarchiveminsucceeddest" updated

DGMGRL> edit database stdy set PROPERTY ARCHIVELAGTARGET=0;
Property "archivelagtarget" updated
DGMGRL> show database stdy InconsistentProperties
INCONSISTENT PROPERTIES
INSTANCE_NAME
PROPERTY_NAME
MEMORY_VALUE
SPFILE_VALUE
BROKER_VALUE

Oracle 11g Cross platform Active Standby - Windows Primary database and Linux
Active Standby

11g-cross-platform-a
ctive-standby.doc