0% found this document useful (0 votes)
54 views2 pages

Monitoring Data Guard Configuration Health Using SQL:: Primary Database Queries

The validate command was run on the primary database tin and the physical standby database can. For the primary database tin, it is ready for switchover and has 2 instances and 2 threads. For the physical standby database can, it is ready for failover but not switchover, has tin as the primary database, 1 instance and 2 threads, and fewer instances than the primary database which may impact performance. The apply state on can is not running, the apply lag is unknown, and the apply delay is 0 minutes.

Uploaded by

janmarkowski23
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
54 views2 pages

Monitoring Data Guard Configuration Health Using SQL:: Primary Database Queries

The validate command was run on the primary database tin and the physical standby database can. For the primary database tin, it is ready for switchover and has 2 instances and 2 threads. For the physical standby database can, it is ready for failover but not switchover, has tin as the primary database, 1 instance and 2 threads, and fewer instances than the primary database which may impact performance. The apply state on can is not running, the apply lag is unknown, and the apply delay is 0 minutes.

Uploaded by

janmarkowski23
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

DGMGRL> validate database tin

Database Role: Primary database


Ready for Switchover: Yes

DGMGRL> validate database can;

Database Role: Physical standby database


Primary Database: tin

Ready for Switchover: No


Ready for Failover: Yes (Primary Running)

Capacity Information:
Database Instances Threads
tin 2 2
can 1 2
Warning: the target standby has fewer instances than the
primary database, this may impact application performance

Standby Apply-Related Information:


Apply State: Not Running
Apply Lag: Unknown
Apply Delay: 0 minutes

The validate command does not provide a SUCCESS or WARNING status and must be examined to determine if any action
needs to be taken.

Monitoring Data Guard Configuration Health Using SQL:


The following queries can be used to assess overall health on both the primary and the standby.

Primary Database Queries

Goal Query Expected Results

Check if any remote standby archive select sysdate,status,error from


Good behavior - no rows returned.
destination is getting errors. gv$archive_dest_status where
If query returns rows, then raise an alert
Check if all remote standby archive type='PHYSICAL' and status!='VALID'
with the returned data.
destinations is enabled or "VALID". or error is not null;

select file#, name,


unrecoverable_change#,
unrecoverable_time Good behavior - no rows returned.
Check if any nologging activity has
from v$datafile If query returns rows, then the standby
occurred on the primary for the last
day. where unrecoverable_time > (sysdate - is vulnerable and the subsequent file
1); needs to be refreshed on the standby.

Good behavior - no rows returned.


If query returns rows, then there's an
existing gap between the primary and
select the standby. Subsequent action is to
sysdate,database_mode,recovery_mode, run the same query on the standby, if
Detect gaps on the standby gap_status from v$archive_dest_status the output is identical, then no action
where type='PHYSICAL' and gap_status required. If the output on the standby
!='NO GAP'; does not match the primary then the
datafile on the standby should be
refreshed.
Assess if any severe Data Guard event select * from v$dataguard_status Good behavior - no rows returned.
occurred in the last day where If query returns rows then the result
severity in ('Error','Fatal') and should raise an alert with the returned
timestamp > (sysdate -1); output.

FOR SYNC ENVIRONMENTS ONLY:


select sysdate,protection_mode,
Good behavior - no rows returned.
synchronized, synchronization_status
If query returns rows then the result
from v$archive_dest_status where
Assess if running in Maximum should raise an alert with the returned
type='PHYSICAL' and
Availability mode and configuration is output.
synchronization_status !='OK';
in sync.

Physical Standby Database Queries

Goal Query Expected Results

Good behavior - no rows are


returned.
select name,value,time_computed,datum_time from
Determine if there is a If no rows are returned then this
v$dataguard_stats where name='transport lag' and
transport lag implies that there is no transport
value > '+00 00:01:00';
lag

Good behavior - no rows are


select name,value,time_computed,datum_time from returned.
Determine if there is an
v$dataguard_stats where name='apply lag' and value If no rows are returned then this
apply lag
> '+00 00:01:00'; implies that there is no apply lag

Good behavior - no rows returned.


Standby data file check select * from v$datafile_header where Any rows returned will show which
(offline files or files that are status ='OFFLINE' file(s) are having IO or recovery
not accessible) or ERROR is not null; issues.

Verify that the Media Good behavior - rows returned.


select * from v$managed_standby
Recovery Process is If no rows are returned then the
where process like 'MRP%';
currently running. MRP process is not running.

Good behavior - no rows returned.


Assess if any severe Data select * from v$dataguard_status where
If query returns rows, then the
Guard event occurred in the severity in ('Error','Fatal') and
result should raise an alert with the
last day timestamp > (sysdate -1);
returned output.

Didn't find what you are looking for?

You might also like