SOP

Dataguard Configuration By RMAN

On: OEL 5.6 64bit operating system (TESTING)
Assumptions

You have two servers (physical or VMs) with an operating system and Oracle installed on them. In this
case I've used Oracle Linux 5.6 and Oracle Database 11.2.0.2.

The primary server has a running instance.

The standby server has a software only installation.

STEP TO STEP PROCEDURE

Database Name and Server Name:
Primary db name: lprod hostname prod-primary.oratech.com machine ip
is 192.168.10.104
Standby db name: lprod hostname prod-standby.oratech.com machine ip
is 192.168.10.105
The Enviroment :
Oracle Home is on identical path on both nodes =

/u01/app/oracle/product/11.2.0/dbhome_1
Update HOSTS file : Path /etc/hosts

Add IP and hostname of standby-server in Primary-server And

Add IP and host name of primary-server in standby-server

Primary Database Steps

Step # 1 : Archive log Mode : Convert the database in archive log mode
SQL> SELECT LOG_MODE FROM V$DATABASE;
SQL> ALTER DATABASE ARCHIVELOG; (For Archiving on database must be in
mount mode)
Database altered.

Step # 2 : Enable Forced Logging

: In order to implement Standby Database we enable

'Forced Logging'. This option ensures that even in the event that a 'nologging' operation is done, force logging
takes precedence and all operations are logged into the redo logs.

SQL> SELECT FORCE_LOGGING FROM V$DATABASE;

SQL> ALTER DATABASE FORCE LOGGING;
Database altered.

Step # 3 : Set Primary Database Initialization Parameters :

Data Guard must

use spfile, in order to configure it we create and configure the standby parameters on a regular pfile, and once
it is ready we convert it to an spfile. Several init.ora parameters control the behavior of a Data Guard
environment. In this example the Primary database init.ora is configured so that it can hold both roles, as
Primary
or
Standby.

SQL> CREATE PFILE=/u01/initprimary.ora FROM SPFILE;

Edit the pfile to add the standby parameters, here shown

highlighted:
Check the setting for the DB_NAME and DB_UNIQUE_NAME parameters. In this case they are both set to
"DB11G" on the primary database.

*.DB_NAME='lprod'
*.DB_UNIQUE_NAME='lprod'

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

*.LOG_ARCHIVE_CONFIG='DG_CONFIG=( lprod, lprod_stby)'

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

*.LOG_ARCHIVE_DEST_1='LOCATION=use_db_recovery_file_dest
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=lprod'
*.LOG_ARCHIVE_DEST_2='SERVICE=lprod_standby
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=lprod_stby'
*.LOG_ARCHIVE_DEST_STATE_1='ENABLE'
*.LOG_ARCHIVE_DEST_STATE_2='ENABLE'
The LOG_ARCHIVE_FORMAT and LOG_ARCHIVE_MAX_PROCESSES parameters must be set to appropriate
values and the REMOTE_LOGIN_PASSWORDFILE must be set to exclusive.

*.LOG_ARCHIVE_FORMAT='%t_%s_%r.arc'
*.LOG_ARCHIVE_PROCESSES=30
*.REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
In addition to the previous setting, it is recommended to make sure the primary is ready to switch roles to
become a standby. For that to work properly we need to set the following parameters.

*.FAL_CLIENT='lprod_primary'
*.FAL_SERVER='lprod_standby'
Set the *CONVERT parameters if primary and standby are on different file system. My standby is on /u02 file
system while primary is on /u01.

*.DB_FILE_NAME_CONVERT='u02','u01'
*.LOG_FILE_NAME_CONVERT='u02','u01'
Set the *STANDBY_FILE_MANAGEMENT to auto.

*.STANDBY_FILE_MANAGEMENT='AUTO'

Step # 4 : Configure a Standby Redo Log :

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) with the same size as the online redo logs. If you are not using OMF's you then must pass
the full qualified name.
It's a good ideology to match the online redo log configuration of the primary server.
My primary database has 3 groups with 1 log member each of 50M, so I started with GROUP 4. It is important
that you have an extra standby redo log member than the online redo log. Here I added two groups more than
the online redo log with size of 100M.

SQL> SELECT GROUP#,TYPE,MEMBER FROM V$LOGFILE;

GROUP#
---------- -------

TYPE
MEMBER
----------------------------------------

3 ONLINE /u01/app/oracle/oradata/novav10g/redo03.log
2 ONLINE / u01/app/oracle/oradata/novav10g/redo02.log
1 ONLINE / u01/app/oracle/oradata/novav10g/redo01.log

SQL> select bytes from v$log;

BYTES
---------52428800
52428800
52428800

SQL> SHOW PARAMETER STANDBY_FILE_MANAGEMENT;

NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------standby_file_management
string
MANUAL

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4

'/u01/app/oracle/oradata/lprod/standby_redo04.log' size 100m;
Database altered.

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5

'/u01/app/oracle/oradata/lprod/standby_redo05.log' size 100m;
Database altered.

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6

'/u01/app/oracle/oradata/lprod/standby_redo06.log' size 100m;
Database altered.

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 7

'/u01/app/oracle/oradata/lprod/standby_redo07.log' size 100m;
Database altered.

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 8

'/u01/app/oracle/oradata/lprod/standby_redo08.log' size 100m;
Database altered.

Note: you have to create this standby redolog in standby database also.

Step # 5: Now start the instance with new parameter file and create spfile
from it:

Shutdown immediate;
Startup nomount pfile=/u01/initprimary.ora;
Create spfile from pfile= /u01/initprimary.ora;
Shut immediate ;
Startup ;

Step # 6 : Create a Password File : A password file must be created on the

Primary and copied over to the Standby site. The sys password must be identical on
both sites. This is a key pre requisite in order to be able to ship and apply archived logs
from Primary to Standby.
[oracle@rac6 ~]$ cd $ORACLE_HOME/dbs
[oracle@rac6 dbs]$ orapwd file=orapwnovav10g password=oracle force=y
SQL> select * from v$pwfile_users;
USERNAME
---------------------SYS

SYSDB SYSOP
--------------TRUE TRUE

Step # 7 : Tranfer parameter file and password file to standby destination

using scp command

Scp: /u01/initprimary.ora oracle@192.168.10.105:/u01/initstanby.ora

Scp /u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwlprod
oracle@192.168.10.105:/u01/app
/oracle/product/11.2.0/dbhome_1/dbs/orapwlprod

Service and Listener Setup

Entries for the primary and standby databases are needed in the
"$ORACLE_HOME/network/admin/tnsnames.ora" files on both servers.
You can create these using the Network Configuration Utility (netca)or
(netmgr) or manually. The following entries were used during this
setup
Primary Database Server.

[oracle@prod-primary admin]$ cat tnsnames.ora

# tnsnames.ora Network Configuration File:
/u01/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.
LPROD_STANDBY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = prod-standby.oratech.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = lprod)
)
)
LPROD_PRIMARY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = prod-primary.oratech.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = lprod)
)
)

Standby Database Server.

[oracle@prod-standby admin]$ cat tnsnames.ora

# tnsnames.ora Network Configuration File:
/u01/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.
LPROD_PRIMARY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = prod-primary.oratech.com)(PORT =
1521))
)
(CONNECT_DATA =
(SERVICE_NAME = lprod)
)
)
LPROD_STANDBY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = prod-standby.oratech.com)(PORT =
1521))
)
(CONNECT_DATA =
(SERVICE_NAME = lprod)
)
)

Note: Make Sure Listener is Configure on Both Server and running.

Standby Database Steps

Step # 1 : Set Standby Database Initialization Parameters :
Check the setting for the DB_NAME and DB_UNIQUE_NAME parameters. In this case they are both set to
"DB11G" on the primary database.

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

*.LOG_ARCHIVE_CONFIG='DG_CONFIG=( lprod, lprod_stby)'

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

*.LOG_ARCHIVE_DEST_1='LOCATION=use_db_recovery_file_dest
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=lprod_stby'
*.LOG_ARCHIVE_DEST_2='SERVICE=lprod_standby
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=lprod'
*.LOG_ARCHIVE_DEST_STATE_1='ENABLE'
*.LOG_ARCHIVE_DEST_STATE_2='ENABLE'
The LOG_ARCHIVE_FORMAT and LOG_ARCHIVE_MAX_PROCESSES parameters must be set to appropriate
values and the REMOTE_LOGIN_PASSWORDFILE must be set to exclusive.

*.LOG_ARCHIVE_FORMAT='%t_%s_%r.arc'
*.LOG_ARCHIVE_MAX_PROCESSES=30
*.REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
In addition to the previous setting, it is recommended to make sure the primary is ready to switch roles to
become a standby. For that to work properly we need to set the following parameters.

*.FAL_CLIENT='lprod_standby'
*.FAL_SERVER='lprod_primary'
Set the *CONVERT parameters if primary and standby are on different file system. My standby is on /u02 file
system while primary is on /u01.

*.DB_FILE_NAME_CONVERT='u01','u02'
*.LOG_FILE_NAME_CONVERT='u01','u02'
Set the *STANDBY_FILE_MANAGEMENT to auto.

*.STANDBY_FILE_MANAGEMENT='AUTO'

Step # 2 : Create Necessary Directories For Standby Database:

mkdir -p u01/app/oracle/admin/lprod/adump/
mkdir -p u01/app/oracle /oradata/lprod

mkdir -p u01/app/oracle / flash_recovery_area/ lprod

Step # 3: Once the new parameter file is ready we create from it the spfile:
Startup nomount pfile=/u01/initstandby.ora;
Create spfile from pfile= /u01/initstandby.ora;
Shut immediate ;
Startup nomount;

Step # 4: Create the standby database using rman:

[oracle@prod-standby flash_recovery_area]$ rman target
sys/oracle@lprod_primary
Recovery Manager: Release 11.2.0.1.0 - Production on Tue Feb 18
15:22:54 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights
reserved.
connected to target database: LPROD (DBID=320470164)
RMAN> CONNECT AUXILIARY SYS/oracle@lprod_standby
connected to auxiliary database: LPROD (not mounted)
RMAN> DUPLICATE TARGET DATABASE FOR STANDBY from active
database;

Step # 5: Start recovery process:

SQL> alter database recover managed standby database disconnect

from session;

Test the configuration by generating archive logs from the primary and
then querying the standby to see if the logs are being successfully
applied.

On the Primary:
SQL> alter system switch logfile;
SQL> alter system archive log current;
SQL> archive log list
Database log mode
Automatic archival
Archive destination
Oldest online log sequence
Next log sequence to archive
Current log sequence

Archive Mode
Enabled
/oracle/10gdg/admin/prim/arch
14
16
16

Standby database
SQL> archive log list
Database log mode
Automatic archival
Archive destination
Oldest online log sequence
Next log sequence to archive
Current log sequence

Archive Mode
Enabled
/oracle/10gdg/admin/stand/arch
14
0
16

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

SEQUENCE#;

SWITHC OVER
We can perform switch over case when we want to perform certain
maintenance work on primary server and we want shutdown the
database
In this scenario we can perform switch over and convert standbyserver to primary-server (temporary use) and perform maintenance on
primary-server
For this
First check any active user connected to the primary-server should be
disconnected and stop any oracle job queue program.
Then check the database status is available for standby. For this we
can perform certain queries on primary-server.

On PRIMARY (we are converting this database to standby)

select username, program from v$session
where type='USER' and sid<>(select sid from v$mystat where rownum<=1);

Disconnect all users and kill all job que process

alter system kill session (sid,serial#);
System altered.
alter system set job_queue_processes=0;
System altered.
select username, program from v$session
where type='USER' and sid<>(select sid from v$mystat where rownum<=1);
no rows selected

If no row selected it means no user connected to the database and no

oracle job queue process is running.
Now check the status of the database. If switch over status show
to_standby it means we can switch the primary database to standby
database.
select switchover_status from v$database;
SWITCHOVER_STATUS
-------------------TO STANDBY

Alter database commit to switchover to standby with session shutdown;

On STANDBY ( we are converting this database to primary

Select database_role from v$database;
Alter database commit to switchover to primary ;
Shut immediate

Startup

NOW STANDBY previous Primary

Shut immediate
Startup mount
Now start recovery
Alter database recover managed standby database Using current logfile disconnect;
select max(sequence#) from v$archived_log where applied='YES';
alter system switch logfile ;

several times on PRIMARY DATABASE pervios standby

select max(sequence#) from v$archived_log where applied='YES';

FAILOVER
For failover scenario we must flashback on for both databases
The advantage of flashback on is that we can up the primary database
when recover.
Otherwise once failover is performed we cannot up the primary
machine and the dataguard is lost.

For Flashback turn ON

ON PRIMARY
Shut immediate
Startup mount
Alter database flashback on ;
Alter database open ;

ON STANDBY

Cancel recovery process

Alter database recover managed standby database cancel;
Alter database flashback on;

Restart the recovery process

Alter database recover managed standby database Using current logfile disconnect;

Now suddenly our primary data center lost due to any reason
(flood, fire, bomb any other reason) In this case we just assume.
Thats why we manually shutdown primary database

ON PRIMARY
Shut abort;

ON STANDBY

we are convert to primary

alter database recover managed standby database finish force;

alter database commit to switchover to primary;

Now we assume our primary data center recover and we want to

convert primary (previously lost database) to standby
There is a column in v$database view
STANDBY_BECAME_PRIMARY_SCN

This column shows from which SCN number this database become
primary.
Select STANDBY_BECAME_PRIMARY_SCN from v$database;

Note the SCN number 549647

On PRIMARY (priviuosly lost) are converting to Standby

Startup mount

Flashback database to SCN 549647

Shut immediate
Startup mount;
Select database_role from v$database ;
Alter database convert to physical standby ;

ON PRIMARY NEW
Shut immediate
Startup
Alter system switch logfile ;
Alter system switch logfile ;
Select status, error from v$archivedest;
Alter system set log_archive_dest_2=defer;
Alter system set log_archive_dest_2=enable;
Alter system switch logfile;

ON STANDBY ( Recover from disaster)

START recovery process may me this process suddenly abnormal
terminate
Then again restart the process.
Alter database recover managed standby database Using current logfile disconnect;

How to Setup Active datagurad in 11g

The main advantage of setting up dataguard in 11g is that the
database can be opened in Read-Only mode allowing the Users to
access the physical standby database for fetching reports and on the
same time the physical standby database can be in recovery mode.
In other words, the physical standby database would be in recovery
mode and hand in hand the standby database can be used for
reporting purposes.
The read-only physical standby database can be used to offload query
from the primary database. Users can use select statements and
complex queries against this this database and thereby decreasing the
load on the primary database. While the standby is open read-only, the
following operations are disallowed.
Any Data Manipulation Language (DML) except for select

statements
Any Data Definition Language (DDL)
Access of local sequences
DMLs on local temporary tables

Step # 1: Check the status of the Primary database and the latest sequence
generated in the primary database.

SQL> select status,instance_name,database_role from

v$instance,v$database;
STATUS

INSTANCE_NAME

DATABASE_ROLE

OPEN

lprod

PRIMARY

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

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

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

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
-----------------------------------------

40

Step # 2: Check the status of the physical standby database and the latest
sequence applied on the physcial standby database.
SQL> select process,status,sequence# from v$managed_standby;
STATUS

INSTANCE_NAME

DATABASE_ROLE

MOUNTED

lprod

PHYSICAL STANDBY

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

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

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

SQL> select max(sequence#) from v$archived_log where

applied=YES;
MAX(SEQUENCE#)
-----------------------------------------

40

Step # 3: Check if the Managed Recovery Process (MRP) is active on the

physcial standby database.

SQL> select status,instance_name,database_role from

v$instance,v$database;
PROCESS STATUS
------------- -----------ARCH CONNECTED
ARCH CONNECTED
ARCH CONNECTED

SEQUENCE#
---------0
0
0

ARCH CONNECTED
RFS
IDLE
RFS
IDLE
RFS
IDLE
RFS
IDLE
MRP0 WAIT_FOR_LOG
9 rows selected.

0
41
0
0
0
41

Here, MRP is active. The PROCESS Column above shows that MRP is active
and is waiting for the log sequence 41.

Step # 4: Cancel the MRP on the physical standby database and open the
standby database. The standby database would be opened in the READ-ONLY
Mode.

SQL> alter database recover managed standby database cancel;

Database altered.

SQL> alter database open;

Database altered.

SQL> select status,instance_name,database_role,open_mode from

v$database,v$instance;
STATUS

INSTANCE_NAME DATABASE_ROLE

OPEN_MODE

-----------

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

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

OPEN

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

lprod

PHYSICAL STANDBY

READ ONLY

Step # 5: Now start the MRP on the physical standby database.

SQL> alter database recover managed standby database disconnect
from session;
Database altered.

SQL> select process,status,sequence# from v$managed_standby;

PROCESS

STATUS

SEQUENCE#

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

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

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

ARCH
ARCH
ARCH
ARCH
RFS
RFS
RFS
RFS
MRP0

9 rows selected.

CONNECTED
CONNECTED
CONNECTED
CONNECTED
IDLE
IDLE
IDLE
IDLE
WAIT_FOR_LOG

0
0
0
0
41
0
0
0
41

How to Setup Snapshot Standby in 11g (New

Feature)
Oracle provides an unique feature where the physical standby
database can be opened in READ WRITE mode to perform update able
transactions. Quite often we have the standby database opened in
READ Only mode for reporting purposes and optionally have the active
dataguard implemented, but a snapshot standby database can be used
to perform both READ and WRITE activities. Most importantly, a
snapshot standby database keeps receiving the redo data from the
primary database but does not apply them. These redo data received
from the primary database would be applied only when the snapshot
standby database is converted back to the Physical standby mode.
There by the snapshot standby database provides data protection on
primary database.
A snapshot standby database will allow you to make use of the data
available on the physical standby database (which is a mirrored copy
of the primary database). This allows the users to test the application
on a standby database which has the primary data before
implementing it in the Real production environment. When a physical
standby database is converted to a snapshot standby database, a
guaranteed restore point is automatically created. Once when the
updateable transactions are completed for testing purposes on the
snapshot standby database and when you are converting back the
snapshot standby to physical standby, oracle flashbacks to the restore
point that was created earlier which means that the transactions that
were made when the standby database was opened in READ WRITE
mode will be flushed out.
The only requirement to have the snapshot standby is that FRA (Flash
Recovery Area) must be configured on physical standby database. It is
not necessary to have flashback enabled. Below are the steps on how
to convert a physical standby database to a snapshot standby
database and viceversa.

Step # 1:
Detail of Primary Database.

SQL> select status,instance_name,database_role,open_mode from

v$database,v$Instance;
STATUS

INSTANCE_NAME

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

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

OPEN

lprod

DATABASE_ROLE

OPEN_MODE

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

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

PRIMARY

READ WRITE

SQL> select thread#,max(sequence#) from v$archived_log group by

thread#;
THREAD#
----------

MAX(SEQUENCE#)
--------------

15

Detail of Standby Database.

SQL> select status,instance_name,database_role,open_mode from

v$database,v$Instance;
STATUS

INSTANCE_NAME

DATABASE_ROLE

OPEN_MODE

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

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

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

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

OPEN

lprod

PHYSICAL STANDBY READ ONLY WITH APPLY

SQL> select thread#,max(sequence#) from v$archived_log where

applied='YES' group by thread#;
THREAD#

MAX(SEQUENCE#)

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

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

15

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------

NO

You can observe that the standby database is in sync with the primary
database. Below outcome shows that the Flash Recovery Area is
configured on the physical standby database.
SQL> show parameter db_recovery_file_dest
NAME
--------------------------db_recovery_file_dest
db_recovery_file_dest_size

TYPE
----------string
big integer

VALUE
------------+FRA_NEW
4122M

Step # 2: Cancel the MRP on the physical standby database and then
shutdown the database and startup mount

SQL> alter database recover managed standby database cancel;

Database altered.

SQL> shut immediate

Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.
Total System Global Area
Fixed Size
Variable Size
Database Buffers
Redo Buffers
Database mounted.

1269366784
2227984
805306608
452984832
8847360

bytes
bytes
bytes
bytes
bytes

Step # 3: Once the standby database is mounted, convert the Physical

standby database to snapshot standby database.

SQL> alter database convert to snapshot standby;

Database altered.

Step # 4: You can now open the snapshot standby database and check its
mode.

SQL> alter database open;

Database altered.

SQL> select status,instance_name,database_role,open_mode from

v$database,v$Instance;
STATUS

INSTANCE_NAME DATABASE_ROLE

-----------

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

OPEN

lprod

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

SNAPSHOT

OPEN_MODE
------------------

STANDBY READ WRITE

Step # 5: Small Test on the snapshot standby database. 1. Create a user

called SNAPTEST
2. Create a table called TEST whose owner is SNAPTEST and insert some
records in it. You can also update some of the records as well.

SQL> create user snaptest identified by oracle;

User created.

SQL> grant connect,resource to snaptest;

Grant succeeded.

SQL> conn snaptest/oracle@srps

Connected.

SQL> create table test(code number, name char(20));

Table created.

SQL> insert into test values (101,'RAHEEL');

1 row created.

SQL> insert into test values(201,'REHMAN');

1 row created.

SQL> commit;
Commit complete.

SQL> select * from test;

CODE

NAME

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

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

101
201

RAHEEL
REHMAN

SQL> update snaptest.test set code=500 where name='RAHEEL';

1 row updated.

SQL> commit;
Commit complete.

SQL> select * from snaptest.test;

CODE

NAME

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

500
201

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

RAHEEL
REHMAN

In the meantime, you can also see that the redo data from the primary
database is received by the snapshot standby database but would not be
applied.
On primary database the latest sequence generated is 208 and that on the
standby database, the RFS process is idle for sequence 209.
On Primary

SQL> select thread#,max(sequence#) from v$archived_log group by

thread#;
THREAD#

MAX(SEQUENCE#)

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

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

18

On Standby

SQL> select process,status,sequence# from v$managed_standby;

PROCESS

STATUS

SEQUENCE#

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

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

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

ARCH
ARCH
ARCH
ARCH
RFS
RFS
RFS

CLOSING
CONNECTED
CONNECTED
CONNECTED
IDLE
IDLE
IDLE

1
0
0
0
0
18
0

7 rows selected.

Steps on converting back a snapshot standby database to

physical standby database.

Step # 1: Shut down the snapshot standby database and open it in Mount
mode.

SQL> shut immediate

Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.
Total System Global Area 1269366784 bytes
Fixed Size
2227984 bytes
Variable Size
805306608 bytes
Database Buffers
452984832 bytes
Redo Buffers
8847360 bytes
Database mounted.

Step # 2: Convert the snapshot standby database to physical standby

database.

SQL> alter database convert to physical standby;

Database altered.

Step # 3: Once done, bounce the physical standby database and start the
Managed Recovery Process (MRP) on it.

SQL> shut immediate

ORA-01507: database not mounted
ORACLE instance shut down.

SQL> startup
ORACLE instance started.
Total System Global Area
Fixed Size
Variable Size
Database Buffers
Redo Buffers
Database mounted.
Database opened.

1269366784
2227984
805306608
452984832
8847360

bytes
bytes
bytes
bytes
bytes

SQL> select status,instance_name,database_role,open_mode from

v$database,v$Instance;
STATUS

INSTANCE_NAME

DATABASE_ROLE

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

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

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

OPEN

lprod

PHYSICAL STANDBY

OPEN_MODE
----------------

READ ONLY

SQL> alter database recover managed standby database disconnect

from session;
Database altered.

SQL> select process,status,sequence# from v$managed_standby;

PROCESS STATUS
SEQUENCE#
------------- --------------------ARCH
CONNECTED
0
ARCH
CONNECTED
0
ARCH
CONNECTED
0
ARCH
CONNECTED
0
RFS
IDLE
0
RFS
IDLE
0
RFS
IDLE
0
MRP0
WAIT_FOR_LOG
18
8 rows selected.

Step # 4: Crosscheck whether the physical standby database is in sync with

the primary database.
On Primary database:

SQL> select thread#,max(sequence#) from v$archived_log group

bythread#;
THREAD#
----------

MAX(SEQUENCE#)
--------------

21

On Standby database:

SQL> select thread#,max(sequence#) from v$archived_log where

applied='YES' group by thread#;
THREAD#

MAX(SEQUENCE#)

----------

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

21

Step # 3: You can see below that the transactions that were carried out

when the standby database is opened in READ WRITE mode are flushed out
after it was converted back to physical standby database mode.

SQL> select * from snaptest.test;

select * from snaptest.test
*
ERROR at line 1:
ORA-00942: table or view does not exist

SQL> select username,account_status from dba_users where

username='SNAPTEST';
no rows selected

CONCLUSION
Now Database is successfully Configured.
Perform Testing , Switchover and failover scenarios and with active
dataguard and snapshot standby features..