sil_bo_prd_dr

8/12/2019 SIL_BO_PRD_DR

1/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 databaseSQL Query:

STARTUP MOUNT;


2/8

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


3/8

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 DELAY 30 DISCONNECT FROMSESSION;


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;


4/8

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:


5/8

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;


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


SQL Query:




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:


6/8


SEQUENCE#;

18

11. Maintenance of the Primary and Standby Database

Stop Standby Database

SQL Query:


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;



SQL Query:




SQL Query:



7/8

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>


8/8

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

sil_bo_prd_dr

Documents