You are on page 1of 8

9.

Building Standby Database


Standby database can be built either by using Offline backup of Primary database or by Online
backup.
a) Primary database: Enable force logging
Make sure the primary database is running in archive log mode and enable force logging.
SQL Query: ALTER DATABASE FORCE LOGGING;
SELECT FORCE_LOGGING FROM V$DATABASE;
b) Primary database: Create Standby Control file
Create standby control file from Primary database
SQL Query:
STARTUP MOUNT;









c) Primary Database: Backup
Backup the primary (Offline / Online Backup).
As there is only incremental backup available with RMAN ,we can not follow online restore.
So we have followed suggested /KT offline method of moving

D:\EDGEBIBO4PRD (all files)
D:\oracle\BOP\oraarch (all files )
D:\oracle\oradata (all files , can skip old orcl folders)

d) Standby Database: Restore and Recover
Restore the backup in the standby database. Distribute the created standby control file in the
standby system in the control file locations. Copy the required archive logs from Primary database
and recover the database.
Note: Do not open the database. Standby database should be always in mount;
SQL Query: (To recover database)
STARTUP MOUNT;
RECOVER DATABASE;

14
e) Create Standby Redo Log File: Primary and Secondary
Standby redo log will be created in Standby database and it is also recommended to create
standby redo log in primary database also as the Primary database may have role transition from
Primary to Standby in future.
SQL Query:
f) Verify the below again
Verify the database parameters by using show parameter <parametername>
Verify the standby redo log files created in Secondary and Primary
Verify the online redo log files created in Primary
Verify whether the Primary and Secondary database are in archive log mode
Verify whether the standby is mounted
Verify whether the Primary and Secondary is running by using SPFILE
Verify Listener and tnsping
g) Secondary Database: Start Apply Process
Start the redo apply process in the Standby Database
Background Redo Apply:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
To Cancel the Apply Process:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
To set Delay and No Delay in applying archived redo log:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 30 DISCONNECT FROM
SESSION;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY DISCONNECT FROM
SESSION;
15
To set parallel apply:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 4 DISCONNECT FROM
SESSION;
h) Verify whether Apply Process works
On the Primary database, check the latest archived logs and perform log switch
SQL Query:
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
ALTER SYSTEM SWITCH LOGFILE;
Verifiy the Database Role:
SELECT DATABASE_ROLE FROM V$DATABASE;
On the Standby database, check whether the latest archived logs arrived and applied
SQL Query:
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM V$ARCHIVED_LOG ORDER BY
SEQUENCE#;
SELECT SEQUENCE#, ARCHIVED, APPLIED FROM v$ARCHIVED_LOG;
SELECT NAME, SEQUENCE#, ARCHIVED, APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE;
To check the Standby Processes Status:
SELECT SEQUENCE#, STATUS, PROCESS FROM V$MANAGED_STANDBY;
Verifiy the Database Role:
SELECT DATABASE_ROLE FROM V$DATABASE;
i) Verify Protection mode in Standby Database
To verify the protection mode. We are using Maximum Performance as protection mode.
SQL Query:
SELECT PROTECTION_MODE FROM V$DATABASE
We are using Maximum Performance as protection mode.
16
10. Database Switch Over
Convert Primary database to Standby
Stop SAP Instance and then proceed with the below
SQL Query:
CONNECT / AS SYSDBA
Check the connected Session:
SQL> select program, username from v$session;
SQL> select switchover_status from v$database;
If the switchover status is:
TO STANDBY
then change the primary to standby with the following commands
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;
SHUTDOWN IMMDEDIATE;
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Convert Standby database to Primary
SQL Query:
CONENCT / AS SYSDBA;
SQL> select switchover_status from v$database;
If the switchover status is:
TO PRIMARY
then change the standby to primary with the following commands
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE OPEN;
17
Start the SAP Instance in the Secondary Site
On the Primary database, check the latest archived logs and perform log switch
SQL Query:
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
ALTER SYSTEM SWITCH LOGFILE;
On the Standby database, check whether the latest archived logs arrived and applied
1. Check whether the archive logs are transported from Primary to Secondary, check
the archive logs under standy_archive_log directory
2. Check whether the logs are applied below is the query for the same.
SQL Query:
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM V$ARCHIVED_LOG ORDER BY
SEQUENCE#;
18
11. Maintenance of the Primary and Standby Database
Stop Standby Database
SQL Query:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SHUTDOWN IMMEDIATE;
Stop Primary Database
SQL Query:
SHUTDOWN IMMEDIATE;
Once after the maintenance is completed start the Primary and Standby database
Start Primary Database
SQL Query:
STARTUP;
SELECT FORCE_LOGGING FROM V$DATABASE; (Result should be yes, else execute the command
ALTER DATABASE FORCE LOGGING;)
Start Standby Database
STARTUP MOUNT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
On the Primary database, check the latest archived logs and perform log switch
SQL Query:
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
ALTER SYSTEM SWITCH LOGFILE;
On the Standby database, check whether the latest archived logs arrived and applied
SQL Query:
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM V$ARCHIVED_LOG ORDER BY
SEQUENCE#;
19
Notable Maintenance:
Maintenance of Operating System / SAP related activities performed in the Primary Server should
be replicated in Secondary System as well.
Activities like,
1. Installation / Update of Operating System Software
2. Changes at file system
3. SAP Kernel upgrade
4. SAP Profile Parameter Changes
5. SAP Backup Parameter Changes
6. Oracle Instance Parameter Changes
7. Database Patch
20
12. Check archive gap in Standby Database
To determine if there is an archive gap on your physical standby database, query the
V$ARCHIVE_GAP view as shown in the following example:
SELECT * FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
----------- ------------- --------------
1 7 10
The output from the previous example indicates your physical standby database is currently
missing log files from sequence 7 to sequence 10 for thread 1. After you identify the gap, issue the
following SQL statement on the primary database to locate the archived redo log files on your
primary database (assuming the local archive destination on the primary database is
LOG_ARCHIVE_DEST_1):
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND 2>
SEQUENCE# BETWEEN 7 AND 10;
NAME
--------------------------------------------------------------------------------
/primary/thread1_dest/arcr_1_7.arc /primary/thread1_dest/arcr_1_8.arc
/primary/thread1_dest/arcr_1_9.arc
Copy these log files to your physical standby database and register them using the ALTER
DATABASE REGISTER LOGFILE statement on your physical standby database. For example:
SQL> ALTER DATABASE REGISTER LOGFILE
'/physical_standby1/thread1_dest/arcr_1_7.arc';
SQL> ALTER DATABASE REGISTER LOGFILE
'/physical_standby1/thread1_dest/arcr_1_8.arc';
After you register these log files on the physical standby database, you can restart Redo
Apply.
21
13. Fail Over
If the primary database is not available the standby database can be activated as a primary
database using the following statements.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
ALTER DATABASE ACTIVATE STANDBY DATABASE;
Since the standby database is now the primary database it should be backed up immediately.
Post Fail Over:
1. New IP Address of the SAP System should be published to the end user desktop to access
the new Primary System.
Host Name IP Address
Primary vSAPBOPRD 10.10.8.26
Standby vSAPBOPRD 172.16.11.254
Note: To build the standby database, follow the process of Disaster Recover Setup to build it