In this demo the database version is 10.2.0.1.0.

The Primary database and Standby database are

located on different machines.

The Primary database is called db1 and the Standby database is called sdb1. I use Flash Recovery
Area.

I. Before you get started:

1. Make sure the operating system and platform architecture on the primary and standby systems
are the same;
2. Make sure that the same Oracle 10g binaries installed on both servers, and Oracle home
paths are identical.
3. Concerning Oracle, all directory structures are identical on both servers; i.e. datafiles, dumps,
etc. go to the same places - or, in other words, concerning Oracle the only difference in both
servers is that one database will be "open", while the other will be mounted, that is "standby"
4. The master (primary) database ready, up and running on Oracle 10g
5. File Recovery Area (FRA) is configured and used for Backups and ArchiveLog
6. Test the Standby Database creation on a test environment first before working on the
Production database.

II. On the Primary Database Side:

1. Enable Archiving on Primary.

If your primary database is not already in Archive Log mode, enable the archive log mode:

SQL>shutdown immediate;
SQL>startup mount;
SQL>alter database archivelog;
SQL>alter database open;
SQL>archive log list;

2. Enable forced logging on your primary database:

SQL> select force_logging from v$database;

If no then

SQL> ALTER DATABASE FORCE LOGGING;

3. Create a password file if it doesn’t exist.

1) To check if a password file already exists, run the following command:

SQL> select * from v$pwfile_users;

2) If it doesn't exist, use the following command to create one:

$cd $ORACLE_HOME/dbs
$orapwd file=pwddb1.ora password=xxxxxxxx force=y

(Note: Replace xxxxxxxxx with your actual password for the SYS user.)

(IMPORTANT: The file name must be orapw$ORACLE_SID, and the file must be in the
$ORACLE_HOME/dbs directory, or it will not be found by the instance. So copied the
$ORACLE_HOME/dbs/orapwdb1 file from the master (primary) site to the same location on the
standby site with the name of orapwsdb1.
Furthermore, the password must be identical on the master and the standby side.
These steps are necessary to make a login AS SYSDBA possible via Oracle Net.

4. Configure a Standby Redo log.

1) The size of the standby redo log files should match the size of the current Primary database online
redo log files. To find out the size of your online redo log files:

SQL> select (bytes/1024)/1024 MEGA_BYTES from v$log;

MEGA_BYTES
----------
50
50
50

Get the max group# of online redo logs on db12 database

SELECT max (group#) from v$logfile;

Create the standby redo logs on the primary database with the same size of that of online redo logs.
If the above query returns the value of 3 and each logfile is 50M in size (from the above query) then,
create atleast 4 standby redo logs of the size of 50M per thread.

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 '/ora_home/oradata/db1/sredo4.log' SIZE 50M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 '/ora_home/oradata/db1/sredo5.log' SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 '/ora_home/oradata/db1/sredo6.log' SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 '/ora_home/oradata/db1/sredo7.log' SIZE 50M;
4) To verify the results of the standby redo log groups creation, run the following query:

SQL>select * from v$standby_log;

5. Set Primary Database Initialization Parameters

Create a text initialization parameter file (PFILE) from the server parameter file (SPFILE), to add the
new primary role parameters.

i. Create pfile from spfile for the primary database:

SQL> create pfile='ora_home/oradata/initDB1.ora' from spfile;

ii. Edit initDB1.ora to add the new primary and standby role parameters:
NOTE: A DB_UNIQUE_NAME is needed, since both databases will share the same SID and DBID -
and thus need to be distinguished by something else

*.audit_file_dest='/ora_home/oracle/oracle/product/10.2.0/db_1/admin/db1/adump'
*.background_dump_dest='/ora_home/oracle/oracle/product/10.2.0/db_1/admin/db1/bdump'
*.compatible='10.2.0.1.0'
*.control_files='/ora_home/oradata/db1/control01.ctl','/ora_home/oradata/db1/control02.ctl','/ora_hom
e/oradata/db1/control03.ctl'
*.core_dump_dest='/ora_home/oracle/oracle/product/10.2.0/db_1/admin/db1/cdump'
*.db_block_size=8192
*.db_domain='dbs.com'
*.db_file_multiblock_read_count=16
*.db_name='db1'
*.db_recovery_file_dest='/ora_home/FRA'
*.db_recovery_file_dest_size=2147483648
*.dispatchers='(PROTOCOL=TCP) (SERVICE=db1XDB)'
*.job_queue_processes=10
*.log_archive_format='%t_%s_%r.arc'
*.open_cursors=300
*.pga_aggregate_target=144703488
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=434110464
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/ora_home/oracle/oracle/product/10.2.0/db_1/admin/db1/udump'
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(db1,sdb1)'
*.LOG_ARCHIVE_DEST_1='LOCATION=/ora_home/FRA/DB1/archivelog/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=db1'
*.LOG_ARCHIVE_DEST_2='SERVICE=sdb1 LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=sdb1'
*.LOG_ARCHIVE_DEST_STATE_1='ENABLE'
*.LOG_ARCHIVE_DEST_STATE_2='ENABLE'
*.FAL_CLIENT='db1'
*.FAL_SERVER='sdb1'
*.DB_FILE_NAME_CONVERT='/ora_home/oradata/sdb1/','/ora_home/oradata/db1/'
*.LOG_FILE_NAME_CONVERT='/ora_home/oradata/sdb1/','/ora_home/oradata/db1/'
*.standby_archive_dest='/ora_home/FRA/DB1/archivelog/'
*.STANDBY_FILE_MANAGEMENT='AUTO'
*.DB_UNIQUE_NAME=db1

6. Create spfile from pfile, and restart primary database using the new spfile.
Data Guard must use SPFILE. Create the SPFILE and restart database.

SQL> shutdown immediate;

SQL>create spfile from pfile='/ora_home/oradata/initDB1.ora';
SQL>Startup;

9. Prepare initialization parameter file for standby database and copy (scp) to the standby server in
the corresponding directory.

NOTE: A DB_UNIQUE_NAME is needed, since both databases will share the same SID and DBID -
and thus need to be distinguished by something else

*.audit_file_dest='/ora_home/oracle/oracle/product/10.2.0/db_1/admin/sdb1/adump'
*.background_dump_dest='/ora_home/oracle/oracle/product/10.2.0/db_1/admin/sdb1/bdump'
*.compatible='10.2.0.1.0'
*.control_files='/ora_home/oradata/sdb1/control01.ctl','/ora_home/oradata/sdb1/control02.ctl','/ora_ho
me/oradata/sdb1/control03.ctl'
*.core_dump_dest='/ora_home/oracle/oracle/product/10.2.0/db_1/admin/sdb1/cdump'
*.db_block_size=8192
*.db_domain='dbs.com'
*.db_file_multiblock_read_count=16
*.db_name='db1'
*.db_recovery_file_dest='/ora_home/FRA'
*.db_recovery_file_dest_size=2147483648
*.dispatchers='(PROTOCOL=TCP) (SERVICE=sdb1XDB)'
*.job_queue_processes=10
*.log_archive_format='%t_%s_%r.arc'
*.open_cursors=300
*.pga_aggregate_target=144703488
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=434110464
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/ora_home/oracle/oracle/product/10.2.0/db_1/admin/sdb1/udump'
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(db1,sdb1)'
*.LOG_ARCHIVE_DEST_1='LOCATION=/ora_home/FRA/SDB1/archivelog/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=sdb1'
*.LOG_ARCHIVE_DEST_2='SERVICE=db1 LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=db1'
*.LOG_ARCHIVE_DEST_STATE_1='ENABLE'
*.LOG_ARCHIVE_DEST_STATE_2='ENABLE'
*.FAL_CLIENT='sdb1'
*.FAL_SERVER='db1'
*.DB_FILE_NAME_CONVERT='/ora_home/oradata/db1/','/ora_home/oradata/sdb1/'
*.LOG_FILE_NAME_CONVERT='/ora_home/oradata/db1/','/ora_home/oradata/sdb1/'
*.standby_archive_dest='/ora_home/FRA/SDB1/archivelog/'
*.STANDBY_FILE_MANAGEMENT='AUTO'
*.DB_UNIQUE_NAME=sdb1

10. Configure listeners for the primary and standby databases on both server.

Adjust the listener.ora files & tnsnames.ora files for both database on both server

Add following line in Listener.ora

On Primary Site

(SID_DESC =
(GLOBAL_DBNAME = db1.dbs.com)
(ORACLE_HOME = /ora_home/oracle/oracle/product/10.2.0/db_1)
(SID_NAME = db1)
)

(SID_DESC =
(GLOBAL_DBNAME = sdb1.dbs.com)
(ORACLE_HOME = /ora_home/oracle/oracle/product/10.2.0/db_1)
(SID_NAME = sdb1)
)
On Standby Site

(SID_DESC =
(GLOBAL_DBNAME = db1.dbs.com)
(ORACLE_HOME = /ora_home/oracle/oracle/product/10.2.0/db_1)
(SID_NAME = db1)
)

(SID_DESC =
(GLOBAL_DBNAME = sdb1.dbs.com)
(ORACLE_HOME = /ora_home/oracle/oracle/product/10.2.0/db_1)
(SID_NAME = sdb1)
)

Add following line in TNSNAMES.ORA file on both site

DB1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = linux8.dbs.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = db1.dbs.com)
)
)

SDB1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = linux9.dbs.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = sdb1.dbs.com)
)
)
a) On Primary server: use Oracle Net Manager to configure a listener for db1 and sdb1. Then restart
the listener.
$lsnrctl stop
$lsnrctl start

b) On Standby server: use Oracle Net Manager to configure a listener for db1 and sdb1. Then restart
the listener.
$lsnrctl stop
$lsnrctl start

Create Oracle Net service names.

c) On Primary system: use Oracle Net Manager to create network service names for db1 and sdb1.
Check tnsping to both services:
$tnsping db1
$tnsping sdb1

d) On Standby system: use Oracle Net Manager to create network service names for db1 and sdb1.
Check tnsping to both services:
$tnsping db1
$tnsping sdb1

11. Checking the database status:

Now we go to check the status of our databases. We use SQL*Plus to connect as SYSDBA, and
issue the command SELECT status FROM v$instance. On our master database, this should return
OPEN or at least MOUNTED, on the standby we need NOMOUNT. If this is not the case, we need to
take the necessary steps: On the master, issue a startup (or at least startup mount) command, and
on the standby startup nomount.

Check also if you can connect to the databases remotely. From the master, try connecting the
standby and vice versa, both times as SYSDBA. If this fails, the standby creation will fail as well.

On Primary server

$ sqlplus “sys/password@db1 as sysdba”

SQL> startup

On Standby server

$ export ORACLE_SID=sdb1
$ sqlplus “/ as sysdba”
Or
$ sqlplus “sys/password@sdb1 as sysdba”
SQL>
SQL>create spfile from pfile='/ora_home/oradata/initSDB1.ora';
SQL>startup nomount;

12. RMAN Backups.

We need a full backup of the master (primary) database, plus a copy of the controlfile for standby

oracle$ rman target /

rman> BACKUP CURRENT CONTROLFILE FOR STANDBY;

rman> BACKUP DATABASE PLUS ARCHIVELOG;

13. These commands have to be executed on the master server for primary database. To finish
preparations, we now need to copy the backups to the standby server. The easiest way is to login to
the standby server, cd to the recovery area, and rsync the files:

rsync -Pae oracle@192.168.1.10:/ora_home/FRA .

or

scp –r /ora_home/FRA oracle@192.168.1.20:/ora_home/FRA

14. Use RMAN to create the standby database using DUPLICATE command

oracle$ rman target sys/password@db1 auxiliary sys/password@sdb1

rman> DUPLICATE TARGET DATABASE FOR STANDBY NOFILENAMECHECK;

After command is finished, your standby database is created and mounted.

15. Start Redo apply

On the standby database, to start redo apply:

SQL>alter database recover managed standby database disconnect from session;

If you ever need to stop log apply services:

SQL> alter database recover managed standby database cancel;

16. Verify the standby database is performing properly:

a) On Standby perform a query:

ALTER SESSION SET NLS_DATE_FORMAT='DD-MM-YYYY HH24:MI:SS'

select sequence#||' '||first_time||' '||next_time from v$archived_log;

select dest_id||' '||sequence#||' '||archived||' '||applied||' '||status||' '||STANDBY_DEST||'

'||name from v$archived_log order by sequence#;

select dest_id||' '||sequence#||' '||archived||' '||applied||' '||status||' '||STANDBY_DEST from

v$archived_log order by sequence#;

b) On Primary, force a logfile switch:

SQL>alter system switch logfile;

c) On Standby, verify the archived redo log files were applied:

SQL>select sequence#, applied from v$archived_log order by sequence#;

17. If you want the redo data to be applied as it is received without waiting for the current standby
redo log file to be archived, enable the real-time apply.

To start real-time apply:

SQL> alter database recover managed standby database using current logfile disconnect from
session;

===================================XXXXXXXXXX==============================
Testing Real-time Apply:

On Primary Database, create a table 'test' and insert a record.

INSERT INTO test VALUES (sysdate);

COMMIT;

Do not make a log switch because I set up the LGWR ASYNC option so that the redo should be
transferred and applied to the standby server in real time.

On the STANDBY DB server:

SELECT PROCESS, STATUS,SEQUENCE#,BLOCK#,BLOCKS, DELAY_MINS FROM

V$MANAGED_STANDBY;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

ALTER DATABASE OPEN READ ONLY;

SELECT * FROM test;

You should see the committed transaction. Now, Place the standby back in managed recover mode

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE

DISCONNECT;

This will take the standby directly from read only mode and place it in managed recovery mode.

========================================

Starting Up a Physical Standby Database

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

To start a physical standby database, use SQL*Plus to connect to the database with
administrator privileges, and then use either the SQL*Plus STARTUP or STARTUP
MOUNT statement. When used on a physical standby database:

■ The STARTUP statement starts the database, mounts the database as a physical

■ standby database, and opens the database for read-only access. The STARTUP MOUNT
statement starts and mounts the database as a physical

standby database, but does not open the database. Once mounted, the database can receive
archived redo data from the primary
database. You then have the option of either starting Redo Apply or real-time apply, or opening the
database for read-only access.
For example:

1. Start and mount the physical standby database:

SQL> STARTUP MOUNT;

2. Start Redo Apply or real-time apply:

To start Redo Apply, issue the following statement:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM

SESSION;

To start real-time apply, issue the following statement:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT

LOGFILE;

On the primary database, query the RECOVERY_MODE column in the

V$ARCHIVE_DEST_STATUS view, which displays the standby database’s operation as
MANAGED_RECOVERY for Redo Apply and MANAGED REAL TIME APPLY for real-time apply.

select recovery_mode from v$archive_dest_status;

Note: When you first start Redo Apply on a newly created physical standby database that has not yet
received any redo data from the primary database, an ORA-01112 message may be returned. This
indicates that Redo Apply is unable to determine the starting sequence number for media recovery. If
this occurs, you must either manually retrieve and register an archived redo log file
on the standby database, or wait for the automatic archiving to occur before restarting Redo Apply.

Opening a Physical Standby Database for Read-Only Access

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

You can alternate between having a physical standby database open for read-only access and
performing Redo Apply using the following procedures.

To open a standby database for read-only access when it is currently shut down:

Start, mount, and open the database for read-only access using the following statement:

SQL> STARTUP;
 To open a standby database for read-only access when it is currently performing Redo Apply:

Cancel Redo Apply:

1. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Open the database for read-only access:

2. SQL> ALTER DATABASE OPEN;

You do not need to shut down the instance to open it for read-only access.

Note: By default, the ALTER DATABASE OPEN statement opens physical standby databases in
read-only mode. The Oracle database
determines if this is a physical standby database based on information in the control file.

To change the standby database from being open for read-only access to performing Redo Apply:
---------------------------------------------------------------------------------------------

1. Terminate all active user sessions on the standby database.

2. Restart Redo Apply. To start Redo Apply, issue the following statement:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

DISCONNECT FROM SESSION;

To enable real-time apply, include the USING CURRENT LOGFILE clause:

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

You do not need to shut down the instance to start either of these apply modes.

Shutting Down a Physical Standby Database

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

To shut down a physical standby database and stop Redo Apply, use the SQL*Plus SHUTDOWN
statement. Control is not returned to the session that initiates a database shutdown until shutdown is
complete.
If the primary database is up and running, defer the destination on the primary database and perform
a log switch before shutting down the standby database.

To stop Redo Apply before shutting down the database, use the following steps:

1. Issue the following query to find out if the standby database is performing Redo Apply or
real-time apply. If the MRP0 or MRP process exists, then the standby database is applying redo.

SQL> SELECT PROCESS,STATUS,SEQUENCE#,BLOCK#,BLOCKS,DELAY_MINS

FROM V$MANAGED_STANDBY;

2. If Redo Apply is running, cancel it as shown in the following example:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

3. Shut down the standby database.

SQL> SHUTDOWN IMMEDIATE;

=============================================================

Data Guard switchover Step by Step

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