Академический Документы
Профессиональный Документы
Культура Документы
SRIDBA
BLOGARCHIVE
DATAGUARD
2014(48)
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
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
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');
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
DEST_ID RECOVERY_MODE
Starting with Oracle 10g, the startup task can be done in single step
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.
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.
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;
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:
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:
2. The standby database has been shut down cleanly and Redo Apply was stopped.
In the second scenario, where the physical standby and Redo Apply are already shut down,
proceed as follow using SQL*Plus alone,
SQL> STARTUP
OPEN_MODE
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
In Standby database
SQL>ALTERSYSTEMSETDB_RECOVERY_FILE_DEST='/u01/ora/flashback'
In Primary Database
SwitchlogssotheSCNoftherestorepointisarchivedonthephysicalstandbydatabase
Deferlogarchivedestinationspointingtothestandby
In Standby database
CONTROL
CURRENT
CONTROL
BACKUP
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
In Standby database
Home
Subscribeto:Posts(Atom)
SRTECHNOLOGIES.PoweredbyBlogger.
SRIDBACopyright2011.AllRightsReserved. Designedbypavan