HOME ORACLERAC DATAGUARD PERFORMANCETUNING SCRIPTS REFRESHES ORAERRORS INTERVIEWQUESTIONS DAILYSCRIPTS

SRIDBA

BLOGARCHIVE
DATAGUARD
2014(48)

Monitoring Primary And Physical Standby Databases October(1)

Refreshisascenariowherewemigratedatafromo...

November(47)
There are a number of Oracle background processes that play a key role, first the primary
database
OURBLOGS
LGWR log writer process flushes from the SGA to the ORL files
LNS LogWriter Network Service reads redo being flushed from the redo buffers by ORACLEONLINEDBADMIN
the LGWR and performs a network send of the redo to the standby SRIDBA
ARCH archives the ORL files to archive logs, that also used to fulfill gap resolution
requests, one ARCH processes is dedicated to local redo log activity only and never
0
communicates with a standby database

The standby database will also have key processes

RFS Remote File Server process performs a network receive of redo transmitted
from the primary and writes the network redo to the standby redo log (SRL) files.
ARCH performs the same as the primary but on the standby
MRP Managed Recover Process coordinates media recovery management, recall that
a physical standby is in perpetual recovery mode
LSP Logical Standby Process coordinates SQL apply, this process only runs in a logical
standby
PR0x recovery server process reads redo from the SRL or archive log files and apply
this redo to the standby database.
the above mentioned process can be verified using the SQL script below. Corresponding process
related to primary and standby will be displayed depends where this SQL is executed i.e.
Primary or Standby

Monitor Log shipping on Primary database

SET PAGESIZE 124

COL DB_NAME FORMAT A8
COL HOSTNAME FORMAT A12
COL LOG_ARCHIVED FORMAT 999999
COL LOG_APPLIED FORMAT 999999
COL LOG_GAP FORMAT 9999
COL APPLIED_TIME FORMAT A12

SELECT DB_NAME,
HOSTNAME,
LOG_ARCHIVED,
LOG_APPLIED,
APPLIED_TIME,
LOG_ARCHIVED LOG_APPLIED LOG_GAP
FROM (SELECT NAME DB_NAME FROM V$DATABASE),
(SELECT UPPER (
SUBSTR (
HOST_NAME,
1,
(DECODE (INSTR (HOST_NAME, '.'),
0, LENGTH (HOST_NAME),
(INSTR (HOST_NAME, '.') 1)))))
HOSTNAME
FROM V$INSTANCE),
(SELECT MAX (SEQUENCE#) LOG_ARCHIVED
FROM V$ARCHIVED_LOG
WHERE DEST_ID = 1 AND ARCHIVED = 'YES'),
(SELECT MAX (SEQUENCE#) LOG_APPLIED
FROM V$ARCHIVED_LOG
WHERE DEST_ID = 2 AND APPLIED = 'YES'),
(SELECT TO_CHAR (MAX (COMPLETION_TIME), 'DDMON/HH24:MI') APPLIED_TIME
FROM V$ARCHIVED_LOG
WHERE DEST_ID = 2 AND APPLIED = 'YES');

see if the MRP process is running on standby

SELECT PROCESS from V$MANAGED_STANDBY where PROCESS like 'MRP%';

last log applied and received along with log time on Standby database

SELECT 'Last Applied : ' Logs,

TO_CHAR (next_time, 'DDMONYY:HH24:MI:SS') Time
FROM v$archived_log
WHERE sequence# = (SELECT MAX (sequence#)
FROM v$archived_log
WHERE applied = 'YES')
UNION
SELECT 'Last Received : ' Logs,
TO_CHAR (next_time, 'DDMONYY:HH24:MI:SS') Time
FROM v$archived_log
WHERE sequence# = (SELECT MAX (sequence#) FROM v$archived_log);

Last sequence # received and applied on the standby database

SELECT al.thrd "Thread", almax "Last Seq Received", lhmax "Last Seq Applied"
FROM ( SELECT thread# thrd, MAX (sequence#) almax
FROM v$archived_log
WHERE resetlogs_change# = ( SELECT resetlogs_change# FROM v$database)
GROUP BY thread#) al,
( SELECT thread# thrd, MAX (sequence#) lhmax
FROM v$log_history
WHERE first_time = ( SELECT MAX (first_time) FROM v$log_history)
GROUP BY thread#) lh
WHERE al.thrd = lh.thrd;

Apply rate: To find out the speed of media recovery in a standby database, you can use this
query:

setlines200
coltypeformata30
colITEMformata20
colcommentsformata20
select*fromv$recovery_progress

Archive Lag Histogram: The V$STANDBY_EVENT_HISTOGRAMview came with 11gR2 and shows
the historical occurance of archive lags in terms of seconds.

SQL>colnameformata10
SQL>select*fromV$STANDBY_EVENT_HISTOGRAM

VerifyfromPrimaryiftheRealtimeapplyisbeingused

SQL> SELECT DEST_ID, RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUSWHERE DEST_ID=2;

DEST_ID RECOVERY_MODE

2 MANAGED REAL TIME APPLY

Managing A Physical Standby Database

Below steps are related to daytoday operations of the Oracle Data Guard environment. These
operations include starting the standby database, enabling managed recovery, opening the
standby in readonly, as well as general maintenance tasks.

Starting a Physical Standby

Before Oracle 10g

SQL> startup nomount;

SQL> alter database mount standby database;

Starting with Oracle 10g, the startup task can be done in single step

SQL> startup mount;

During startup, Oracle will read the controlfile when mounting the database to make the
determination to mount the database as astandby database or as a primary database.

Starting Managed Recovery:

Once the standby database has been started, it will begin receiving redo data from the primary
database. This redo data will stack up in the form of archivelogs until we instruct the standby
database to begin applying the redo data to the standby database. For a physical standby, the
redo application is performed via the MRP.

SQL> alter database recovery managed standby database;

This above command will appear to hang because MRP is part of the session that it was started
in. If we cancel out of this session, the MRP will also exit. To avoid this we need to run the MRP
in the background as below

SQL> alter database recover managed standby database disconnect;

If the physical standby has standby redo logs configured, it is possible to have the MRP begin
applying changes as soon as they arrive to the standby instead of waiting for the standby redo log
to be archived. This functionality was introduced in 10g and is called RealTime Apply. Real
Time Apply can shorten the role transition time by minimizing the redo that needs to be applied

To start RealTime Apply, you initiate MRP by issuing the following command:

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

Stopping Managed Recovery:

We could simply perform a normal shutdown on the database, or we could cancel managed
recovery,
leaving the standby database up and running. To cancel managed recovery, issue the following:

SQL> alter database recover managed standby database cancel;

Starting andStoppingActive Data Guard:

The actual process of enabling Active Data Guard is simple: Open the physical standby database
in readonly mode and start Redo Apply. A physical standby database instance cannot be opened
if Redo Apply is active on a mounted instance of that database. The Data Guard physical standby
should be in
one of two states prior to enabling Active Data Guard:

1. The standby database is mounted and Redo Apply is running.

2. The standby database has been shut down cleanly and Redo Apply was stopped.

In the first scenario, proceed as follows using SQL*Plus

1. Stop Redo Apply:

SQL> RECOVER MANAGED STANDBY DATABASE CANCEL;

2. Open the database readonly:

SQL> ALTER DATABASE OPEN READ ONLY;

3. Restart Redo Apply:

SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT USING CURRENT LOGFILE;

In the second scenario, where the physical standby and Redo Apply are already shut down,
proceed as follow using SQL*Plus alone,

1. Start the physical standby in readonly mode.

SQL> STARTUP

2. Start Redo Apply.

SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT USING CURRENT LOGFILE;

SQL> select open_mode from v$database;

OPEN_MODE

READ ONLY WITH APPLY

Snapshot Standby Database

Oracle11ghasafeatureinthisareacalled:Snapshotstandbydatabase.ASnapshotStandby
Databaseisafullyupdateablestandbydatabasethatiscreatedbyconvertingaphysicalstandby
databaseintoasnapshotstandbydatabaseforreadandwriteoperationforashortperiodoftime
thusmakingitpossibletoprocesstransactionsindependentlyoftheprimarydatabase

ThesestepsappliestoOracleServerEnterpriseEditionVersion11.1.0.6to11.2.0.2[Release
11.1to11.2]

AspertheMOSID443720.1Snapshotdatabasehasfollowingcharacteristics

1.Snapshotstandbydatabasecontinuestoreceiveandarchiveredodatafromprimarybutdoes
notarchiveit
notarchiveit

2.Redodatareceivedfromtheprimarydatabaseisappliedautomaticallyonceitisconvertedback
intoaphysicalstandbydatabase.

3.Datafromtheprimarydatabaseisalwaysprotectedasthearchivesarebeingreceivedand
storedinplace.

4.Alllocalupdateswillbediscardedwhensnapshotdatabaseisconvertedbacktophysical
standbydatabase.

5.Iftheprimarydatabasemovestonewdatabasebranch(forexample,becauseofaFlashback
DatabaseoranOPENRESETLOGS),thesnapshotstandbydatabasewillcontinueacceptingredo
fromnewdatabasebranch.

6.Snapshotstandbydatabasecannotbethetargetofaswitchoverorfailover.Asnapshotstandby
databasemustfirstbeconvertedbackintoaphysicalstandbydatabasebeforeperformingarole
transitiontoit.

7.Afteraswitchoverorfailoverbetweentheprimarydatabaseandoneofthephysicalorlogical
standbydatabasesinaconfiguration,thesnapshotstandbydatabasecanreceiveredodatafrom
thenewprimarydatabaseaftertheroletransition.

8.SnapshotstandbydatabasecannotbetheonlystandbydatabaseinaMaximumProtectionData
Guardconfiguration.

StepstoconvertthePhysicalStandbytoSnapshotStandbyDatabase

1)Ifnotalreadyconfigured,configureflashrecoveryareaasgivenbelow

SQL>ALTERSYSTEMSETDB_RECOVERY_FILE_DEST_SIZE=5G
SQL>ALTERSYSTEMSETDB_RECOVERY_FILE_DEST='/u01/ora/flashback'

2)Bringthephysicalstandbydatabasetomountstage.

SQL>SHUTDOWNIMMEDIATE

SQL>STARTUPMOUNT
3)Stopmanagedrecoveryifitisactive.

SQL>ALTERDATABASERECOVERMANAGEDSTANDBYDATABASECANCEL

4)Convertphysicalstandbydatabasetosnapshotstandbydatabase.
ALTERDATABASECONVERTTOSNAPSHOTSTANDBY
Thedatabaseisdismountedduringconversionandmustberestarted.

SQL>STARTUP
Oncethedatabaseisrestartedanytransactioncanbeexecuted.
SQL>selectopen_mode,database_rolefromv$database
OPEN_MODEDATABASE_ROLEREADWRITESNAPSHOTSTANDBY

StepstoconvertSnapshotStandbyDatabasebacktoPhysicalStandby

SQL>SHUTDOWNIMMEDIATE

SQL>STARTUPMOUNT

SQL>ALTERDATABASECONVERTTOPHYSICALSTANDBY

SQL>SHUTDOWNIMMEDIATE

SQL>STARTUPMOUNT

SQL>selectopen_mode,database_rolefromv$database

OPEN_MODEDATABASE_ROLE

MOUNTEDPHYSICALSTANDBY

Startthemediarecoveryprocess.

SQL>ALTERDATABASERECOVERMANAGEDSTANDBYDATABASEDISCONNECT

OrforActivedataguard

SQL>alterdatabaserecovermanagedstandbydatabasedisconnectfromsessionusing
SQL>alterdatabaserecovermanagedstandbydatabasedisconnectfromsessionusing
currentlogfile

Open Physical Standby For Read Write Testing And

Flashback
HereIamdiscussingthestepstoopentheStandbydatabaseinreadwritemodetestingpurposes
andthenmoveitbacktostandbydatabaseusingtheflashbacktechnology.

In Standby database

A ) Set up a flash recovery area.

B ) Make sure to give enough space for to FRA

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=5G;

SQL>ALTERSYSTEMSETDB_RECOVERY_FILE_DEST='/u01/ora/flashback'

B ) Cancel Redo Apply and create a guaranteed restore point.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> CREATE RESTORE POINT restore_point_standby GUARANTEE FLASHBACK DATABASE;

To Confirim the details of restore point, query the below

SQL> select NAME,SCN,TIME from v$restore_point;

In Primary Database

SwitchlogssotheSCNoftherestorepointisarchivedonthephysicalstandbydatabase

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

Deferlogarchivedestinationspointingtothestandby

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;

In Standby database

A ) Activate the physical standby database:

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

SQL> select CONTROLFILE_TYPE from v$database;

CONTROL

CURRENT

B) Then open the database.

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

SQL> ALTER DATABASE OPEN;

Revert the active standby database back to Physical standby database

Once done with your testing

A1. Mount the database.

A2. Flashback the database to restore point.

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

SQL> FLASHBACK DATABASE TO RESTORE POINT restore_point_standby ;

SQL> select controlfile_type from v$database;

CONTROL

BACKUP

B ) Convert to Standby database

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

 SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

SQL> select controlfile_type from v$database;

CONTROL

STANDBY

A ) Put the standby database in managed recovery mode. Let archive gap resolution fetch all
missing archived redo log files and allow Redo Apply to apply the gap

In Primary database

A ) Reenable archiving for the physical standby database:

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

In Standby database

A ) Open the database in Read only mode

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> ALTER DATABASE OPEN READ ONLY;

B ) Drop the restore point

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

SQL> DROP RESTORE POINT restore_point_standby ;

Home

Subscribeto:Posts(Atom)
SRTECHNOLOGIES.PoweredbyBlogger.

SRIDBACopyright2011.AllRightsReserved. Designedbypavan