Diagnosis Oracle Logical Standby Data Guard

Configuration
-- NAME: DG_Logical_Standby_Diagnosis.sql 
-- ------------------------------------------------------------------------ 
-- AUTHOR: Mohammad Abdul Momin Arju
-- January 2010.
-- ------------------------------------------------------------------------ 
-- PURPOSE: 
-- This script is used to troubleshoot Oracle Data Guard issues for 
-- Logical standby database.
-- ------------------------------------------------------------------------ 
-- DISCLAIMER: 
-- This script is provided for educational purposes only. 
-- Test it before you run in your production database. 
-- ------------------------------------------------------------------------ 
-- Content of the Script 

set echo off

set feedback off
column timecol new_value timestamp
column spool_extension new_value suffix
select to_char(sysdate,'Mondd_hhmi') timecol,
'.out' spool_extension from sys.dual;
column output new_value dbname
select value || '_' output
from v$parameter where name = 'db_name';
spool DG_Logical_Standby_&&dbname&×tamp&&suffix

set linesize 79
set pagesize 180
set long 1000
set trim on
set trims on
alter session set nls_date_format = 'MM-DD-YYYY HH24:MI:SS';
set feedback on
select to_char(sysdate) time from dual;

set echo on

-- The following select will give us the generic information about how
-- this standby is setup. The database_role should be logical standby
as
-- that is what this script is intended to be ran on.

column ROLE format a7 tru

column NAME format a8 wrap
select name,database_role,log_mode,protection_mode
from v$database;

-- ARCHIVER can be (STOPPED | STARTED | FAILED). FAILED means that the

-- archiver failed to archive a log last time, but will try again
within 5
-- minutes. LOG_SWITCH_WAIT The ARCHIVE LOG/CLEAR LOG/CHECKPOINT event
log
-- switching is waiting for. Note that if ALTER SYSTEM SWITCH LOGFILE
is
-- hung, but there is room in the current online redo log, then value
is
-- NULL

column host_name format a20 tru

column version format a9 tru
select instance_name,host_name,version,archiver,log_switch_wait
from v$instance;

-- The following query give us information about catpatch.

-- This way we can tell if the procedure doesn't match the image.

select version, modified, status from dba_registry

where comp_id = 'CATPROC';

-- Force logging and supplemental logging are not mandatory but are
-- recommended if you plan to switchover. During normal operations it
is
-- acceptable for SWITCHOVER_STATUS to be SESSIONS ACTIVE or NOT
ALLOWED.

column force_logging format a13 tru

column remote_archive format a14 tru
column dataguard_broker format a16 tru

select force_logging,remote_archive,supplemental_log_data_pk,
supplemental_log_data_ui,switchover_status,dataguard_broker
from v$database;

-- This query produces a list of all archive destinations. It shows

if
-- they are enabled, what process is servicing that destination, if
the
-- destination is local or remote, and if remote what the current
mount ID
-- is.

column destination format a35 wrap

column process format a7
column archiver format a8
column ID format 99
column mid format 99

select dest_id "ID",destination,status,target,

schedule,process,mountid mid
from v$archive_dest order by dest_id;

-- This select will give further detail on the destinations as to what

-- options have been set. Register indicates whether or not the
archived
-- redo log is registered in the remote destination control file.

set numwidth 8
column ID format 99

select dest_id "ID",archiver,transmit_mode,affirm,async_blocks async,

net_timeout net_time,delay_mins delay,reopen_secs reopen,
register,binding
from v$archive_dest order by dest_id;

-- Determine if any error conditions have been reached by querying the

-- v$dataguard_status view (view only available in 9.2.0 and above):

column message format a80

select message, timestamp

from v$dataguard_status
where severity in ('Error','Fatal')
order by timestamp;

-- Query v$managed_standby to see the status of processes involved in

-- the shipping redo on this system. Does not include processes
needed to
-- apply redo.

select process,status,client_process,sequence#
from v$managed_standby;

-- Verify that log apply services on the standby are currently

-- running. If the query against V$LOGSTDBY returns no rows then
logical
-- apply is not running.

column status format a50 wrap

column type format a11
set numwidth 15

SELECT TYPE, STATUS, HIGH_SCN

FROM V$LOGSTDBY;

-- The DBA_LOGSTDBY_PROGRESS view describes the progress of SQL apply

-- operations on the logical standby databases. The APPLIED_SCN
indicates
-- that committed transactions at or below that SCN have been applied.
The
-- NEWEST_SCN is the maximum SCN to which data could be applied if no
more
-- logs were received. This is usually the MAX(NEXT_CHANGE#)-1 from
-- DBA_LOGSTDBY_LOG. When the value of NEWEST_SCN and APPLIED_SCN are
the
-- equal then all available changes have been applied. If your
-- APPLIED_SCN is below NEWEST_SCN and is increasing then SQL apply is
-- currently processing changes.

set numwidth 15

select
(case
when newest_scn = applied_scn then 'Done'
when newest_scn <= applied_scn + 9 then 'Done?'
when newest_scn > (select max(next_change#) from dba_logstdby_log)
then 'Near done'
when (select count(*) from dba_logstdby_log
where (next_change#, thread#) not in
(select first_change#, thread# from dba_logstdby_log)) > 1
then 'Gap'
when newest_scn > applied_scn then 'Not Done'
else '---' end) "Fin?",
newest_scn, applied_scn, read_scn from dba_logstdby_progress;

select newest_time, applied_time, read_time from

dba_logstdby_progress;

-- Determine if apply is lagging behind and by how much. Missing

-- sequence#'s in a range indicate that a gap exists.

set numwidth 15
column trd format 99

select thread# trd, sequence#,

first_change#, next_change#,
dict_begin beg, dict_end end,
to_char(timestamp, 'hh:mi:ss') timestamp,
(case when l.next_change# < p.read_scn then 'YES'
when l.first_change# < p.applied_scn then 'CURRENT'
else 'NO' end) applied
from dba_logstdby_log l, dba_logstdby_progress p
order by thread#, first_change#;

-- Get a history on logical standby apply activity.

set numwidth 15

select to_char(event_time, 'MM/DD HH24:MI:SS') time,

commit_scn, current_scn, event, status
from dba_logstdby_events
order by event_time, commit_scn, current_scn;

-- Dump logical standby stats

column name format a40

column value format a20
select * from v$logstdby_stats;

-- Dump logical standby parameters

column name format a33 wrap

column value format a33 wrap
column type format 99

select name, value, type from system.logstdby$parameters

order by type, name;

-- Gather log miner session and dictionary information.

set numwidth 15

select * from system.logmnr_session$;

select * from system.logmnr_dictionary$;
select * from system.logmnr_dictstate$;
select * from v$logmnr_session;

-- Query the log miner dictionary for key tables necessary to process
-- changes for logical standby Label security will move AUD$ from SYS
to
-- SYSTEM. A synonym will remain in SYS but Logical Standby does not
-- support this.

set numwidth 5
column name format a9 wrap
column owner format a6 wrap

select o.logmnr_uid, o.obj#, o.objv#, u.name owner, o.name

from system.logmnr_obj$ o, system.logmnr_user$ u
where
o.logmnr_uid = u.logmnr_uid and
o.owner# = u.user# and
o.name in ('JOB$','JOBSEQ','SEQ$','AUD$',
'FGA_LOG$','IND$','COL$','LOGSTDBY$PARAMETER')
order by u.name;

-- Non-default init parameters.

column name format a30 tru

column value format a48 wra
select name, value
from v$parameter
where isdefault = 'FALSE';

spool off

Posted by Unknown at 10:53 PM 0 comments   Labels: Data Guard, Scripts

Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Reactions: 
Tuesday, March 22, 2011
Scripts to Monitor a Data Guard Environment
From Oracle documentation followings are the list of views which can be used to monitor in Oracle Data
Guard Environment. Based on these views you can get monitoring script that is mentioned in Diagnosis
Oracle Physical Standby Data Guard Configuration and in Diagnosis Oracle Data Guard Primary Site
Configuration. At the end of this topic I have also mentioned some script which you can run in your
environment.

View
DBA_LOGSTDBY_EVENTS
DBA_LOGSTDBY_HISTORY
DBA_LOGSTDBY_LOG
DBA_LOGSTDBY_NOT_UNIQUE
DBA_LOGSTDBY_PARAMETERS
DBA_LOGSTDBY_SKIP
DBA_LOGSTDBY_SKIP_TRANSACT
ION
DBA_LOGSTDBY_UNSUPPORTED
V$ARCHIVE_DEST
Databas
e Description
Logical Contains information about the activity of a
only logical standby database. It can be used to
determine the cause of failures that occur when
SQL Apply is applying redo to a logical standby
database.
Logical Displays the history of switchovers and failovers
only for logical standby databases in a Data Guard
configuration. It does this by showing the
complete sequence of redo log streams
processed or created on the local system, across
all role transitions. (After a role transition, a new
log stream is started and the log stream
sequence number is incremented by the new
primary database.)
Logical Shows the log files registered for logical standby
only databases.
Logical Identifies tables that have no primary and no
only non-null unique indexes.
Logical Contains the list of parameters used by SQL
only Apply.
Logical Lists the tables that will be skipped by SQL
only Apply.
Logical Lists the skip settings chosen.
only
Logical Identifies the schemas and tables (and columns
only in those tables) that contain unsupported data
types. Use this view when you are preparing to
create a logical standby database.
Primary, Describes all of the destinations in the Data
 Databas
View e Description
physical, Guard configuration, including each destination's
snapshot, current value, mode, and status.
and Note: The information in this view does not
logical persist across an instance shutdown.
V$ARCHIVE_DEST_STATUS Primary, Displays runtime and configuration information
physical, for the archived redo log destinations.
snapshot, Note: The information in this view does not
and persist across an instance shutdown.
logical
V$ARCHIVE_GAP Physical, Displays information to help you identify a gap in
snapshot, the archived redo log files.
and
logical
V$ARCHIVED_LOG Primary, Displays archive redo log information from the
physical, control file, including names of the archived redo
snapshot, log files.
and
logical
V$DATABASE Primary, Provides database information from the control
physical, file. Includes information about fast-start failover
snapshot, (available only with the Data Guard broker).
and
logical
V$DATABASE_INCARNATION Primary, Displays information about all database
physical, incarnations. Oracle Database creates a new
snapshot, incarnation whenever a database is opened with
and the RESETLOGS option. Records about the current
logical and the previous incarnation are also contained
in the V$DATABASE view.
V$DATAFILE Primary, Provides datafile information from the control
physical, file.
snapshot,
and
logical
V$DATAGUARD_CONFIG Primary, Lists the unique database names defined with
physical, the DB_UNIQUE_NAME and LOG_ARCHIVE_CONFIGinitializ
snapshot, ation parameters.
and
 Databas
View e Description
logical
V$DATAGUARD_STATS Primary, Displays various Data Guard statistics, including
physical, apply lag and transport lag. This view can be
snapshot, queried on any instance of a standby database.
and No rows are returned if queried on a primary
logical database. n.
V$DATAGUARD_STATUS Primary, Displays and records events that would typically
physical, be triggered by any message to the alert log or
snapshot, server process trace files.
and
logical
V$FS_FAILOVER_STATS Primary Displays statistics about fast-start failover
occurring on the system.
V$LOG Primary, Contains log file information from the online redo
physical, log files.
snapshot,
and
logical
V$LOGFILE Primary, Contains information about the online redo log
physical, files and standby redo log files.
snapshot,
and
logical
V$LOG_HISTORY Primary, Contains log history information from the control
physical, file.
snapshot,
and
logical
V$LOGSTDBY_PROCESS Logical Provides dynamic information about what is
only happening with SQL Apply. This view is very
helpful when you are diagnosing performance
problems during SQL Apply on the logical
standby database, and it can be helpful for other
problems.
V$LOGSTDBY_PROGRESS Logical Displays the progress of SQL Apply on the logical
only standby database.
V$LOGSTDBY_STATE Logical Consolidates information from
 Databas
View e Description
only the V$LOGSTDBY_PROCESS and V$LOGSTDBY_STATS view
s about the running state of SQL Apply and the
logical standby database.
V$LOGSTDBY_STATS Logical Displays LogMiner statistics, current state, and
only status information for a logical standby database
during SQL Apply. If SQL Apply is not running,
the values for the statistics are cleared.
V$LOGSTDBY_TRANSACTION Logical Displays information about all active transactions
only being processed by SQL Apply on the logical
standby database.
V$MANAGED_STANDBY Physical Displays current status information for Oracle
and database processes related to physical standby
snapshot databases.
Note: The information in this view does not
persist across an instance shutdown.
V$REDO_DEST_RESP_HISTOGRAM Primary Contains the response time information for
destinations that are configured
for SYNC transport.
Note: The information in this view does not
persist across an instance shutdown.
V$STANDBY_EVENT_HISTOGRAM Physical Contains a histogram of apply lag values for the
physical standby. An entry is made in the
corresponding apply lag bucket by the Redo
Apply process every second. (This view returns
rows only on a physical standby database that
has been open in real-time query mode.)
Note: The information in this view does not
persist across an instance shutdown.
V$STANDBY_LOG Physical, Contains log file information from the standby
snapshot, redo log files.
and
logical

Run the following queries in your standby database in order to know details about your Data Guard
environment.

1) In order to know when your log last applied as well as last received log time issue following query:
select 'Last Applied : ' Logs, to_char(next_time,'DD-MON-
YY: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,'DD-MON-
YY:HH24:MI:SS') Time
from v$archived_log
where sequence# = (select max(sequence#) from v$archived_log);

Example output:

SQL> select 'Last Applied : ' Logs, to_char(next_time,'DD-MON-

YY:HH24:MI:SS') Time
2 from v$archived_log
3 where sequence# = (select max(sequence#) from
v$archived_log where applied='YES')
4 union
5 select 'Last Received : ' Logs,
to_char(next_time,'DD-MON-YY:HH24:MI:SS') Time
6 from v$archived_log
7 where sequence# = (select max(sequence#) from
v$archived_log);

LOGS TIME
---------------- ------------------
Last Applied : 08-MAR-11:19:18:30
Last Received : 22-MAR-11:14:20:28

2) Verify the last sequence# received and the last sequence# applied to standby database by following
query:
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;
Example output:

SQL> select al.thrd "Thread", almax "Last Seq Received", lhmax "Last
Seq Applied"
2 from (select thread# thrd, max(sequence#) almax
3 from v$archived_log
4 where resetlogs_change#=(select resetlogs_change# from
v$database)
5 group by thread#) al,
6 (select thread# thrd, max(sequence#) lhmax
7 from v$log_history
8 where first_time=(select max(first_time) from v$log_history)
 9 group by thread#) lh
10 where al.thrd = lh.thrd;

Thread Last Seq Received Last Seq Applied

---------- ----------------- ----------------
1 33978 2074

3)In order to know about transport lag time, apply lag and apply finish time issue,
set lines 180
col name for a40
col value for a40
col unit for a40
select
NAME,
VALUE,
UNIT
from v$dataguard_stats
union
select null,null,' ' from dual
union
select null,null,'Time Computed: '||MIN(TIME_COMPUTED)
from v$dataguard_stats;

Example output:

SQL> set lines 180

SQL> col name for a40
SQL> col value for a40
SQL> col unit for a40
SQL> select
2 NAME,
3 VALUE,
4 UNIT
5 from v$dataguard_stats
6 union
7 select null,null,' ' from dual
8 union
9 select null,null,'Time Computed: '||MIN(TIME_COMPUTED)
10 from v$dataguard_stats;

NAME VALUE
UNIT
----------------------------------------
----------------------------------------
----------------------------------------
apply finish time
day(2) to second(3) interval
apply lag +13 16:29:57
day(2) to second(0) interval
estimated startup time 45
second
transport lag
day(2) to second(0) interval

Time Computed: 03/22/2011 14:24:26

6 rows selected.

4)In order to know the status of the processes involved in Data Guard configuration issue following query,
select
process,status,client_process,sequence#,block#,active_agents,known_age
nts
from v$managed_standby;
Example output:

SQL> select
process,status,client_process,sequence#,block#,active_agents,known_age
nts
from v$managed_standby;

PROCESS STATUS CLIENT_P SEQUENCE# BLOCK# ACTIVE_AGENTS

KNOWN_AGENTS
--------- ------------ -------- ---------- ---------- -------------
------------
ARCH CLOSING ARCH 33979 61441 0
0
ARCH CLOSING ARCH 33976 61441 0
0
ARCH CONNECTED ARCH 0 0 0
0
ARCH CLOSING ARCH 33977 61441 0
0
ARCH CLOSING ARCH 33978 61441 0
0
RFS IDLE LGWR 33980 42566 0
0
MRP0 WAIT_FOR_LOG N/A 24128 0 25
25
RFS IDLE UNKNOWN 0 0 0
0

8 rows selected.

Where the types of PROCESS may be,

- RFS - Remote file server
- MRP0 - Detached recovery server process
- MR(fg) - Foreground recovery session
- ARCH - Archiver process
- FGRD
- LGWR
- RFS(FAL)
- RFS(NEXP)
- LNS - Network server process

The process status may be,

UNUSED - No active process
ALLOCATED - Process is active but not currently connected to a primary database
CONNECTED - Network connection established to a primary database
ATTACHED - Process is actively attached and communicating to a primary database
IDLE - Process is not performing any activities
ERROR - Process has failed
OPENING - Process is opening the archived redo log
CLOSING - Process has completed archival and is closing the archived redo log
WRITING - Process is actively writing redo data to the archived redo log
RECEIVING - Process is receiving network communication
ANNOUNCING - Process is announcing the existence of a potential dependent archived redo log
REGISTERING - Process is registering the existence of a completed dependent archived redo log
WAIT_FOR_LOG - Process is waiting for the archived redo log to be completed
WAIT_FOR_GAP - Process is waiting for the archive gap to be resolved
APPLYING_LOG - Process is actively applying the archived redo log to the standby database

The client process may be,

Archival - Foreground (manual) archival process (SQL)
ARCH - Background ARCn process
LGWR - Background LGWR process

5) In the primary database ensure that everything is fine by issuing following commands. In case of RAC
database ensure that these output is ok across all the instances.

select status,error from v$archive_dest where status <>'INACTIVE';

select * from v$archive_processes where status <> 'STOPPED';
show parameter dest_2
show parameter state_2
alter system set log_archive_dest_state_2=enable scope=both sid='*';
alter system switch logfile;
alter system switch logfile;
select status,error from v$archive_dest where status <>'INACTIVE';