I am not sure if column archive_gap in v$archive_dest_status on primary is updated correctly and always accurate. For standby monitoring I collect information from both primary and standby which will give 100% accuracy. On Tue, Sep 20, 2011 at 8:09 PM, Michael Dinh <mdinh@xxxxxxxxx> wrote: > I use cron to monitor > > > select message, severity, timestamp > from v$dataguard_status > where severity in ('Error','Fatal') > and timestamp > sysdate-15/1440; > > SELECT sysdate, > dest_id,status,db_unique_name,recovery_mode,archived_seq#,applied_seq#, > (CASE WHEN archived_seq#-applied_seq# > 10 > THEN 'Error-' || TO_CHAR (archived_seq# - applied_seq#) > ELSE TO_CHAR (archived_seq# - applied_seq#) > END ) archive_gap, > gap_status > FROM v$archive_dest_status > WHERE dest_id = 2; > > v$archive_dest_status.gap_status is 11.2.0.2 NF > > Michael Dinh > > Disparity Breaks Automation (DBA) > > NOTICE OF CONFIDENTIALITY - This material is intended for the use of the > individual or entity to which it is addressed, and may contain information > that is privileged, confidential and exempt from disclosure under applicable > laws. BE FURTHER ADVISED THAT THIS EMAIL MAY CONTAIN PROTECTED HEALTH > INFORMATION (PHI). BY ACCEPTING THIS MESSAGE, YOU ACKNOWLEDGE THE FOREGOING, > AND AGREE AS FOLLOWS: YOU AGREE TO NOT DISCLOSE TO ANY THIRD PARTY ANY PHI > CONTAINED HEREIN, EXCEPT AS EXPRESSLY PERMITTED AND ONLY TO THE EXTENT > NECESSARY TO PERFORM YOUR OBLIGATIONS RELATING TO THE RECEIPT OF THIS > MESSAGE. If the reader of this email (and attachments) is not the intended > recipient, you are hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. Please notify the > sender of the error and delete the e-mail you received. Thank you. > > -----Original Message----- > From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] > On Behalf Of Uzzell, Stephan > Sent: Tuesday, September 20, 2011 10:51 AM > To: Oracle L > Subject: Physical Standby Montoring > > Hey Listers, > Any cool tricks for monitoring a bunch of physical standby environments? We > have 20 or so physical standby databases, and are having trouble figuring > the best strategy to monitor them. We do not currently have enough DBAs to > sit around watching them. > > We are currently using two scheduled tasks to grab the current_scn from > v$database, alternating every 45 minutes or so; we then parse the two output > files using perl, do some quick math, and as long as there is a change in > the SCN, we feel things are probably OK. > > The problem is that the SCN does not advance at a regular interval. Some > database are busier than others. Some database therefore do not have the SCN > advance between a pair of tests; other times one of the scheduled tasks > hangs. So we get periodic "BAD" reports that are not really bad. > > Definitely not the best system. Any recommendations for the best way to > monitor - to only get alerts if / when there is actually something wrong? > > Thanks! > > Stephan Uzzell > > > -- > //www.freelists.org/webpage/oracle-l > > > -- > //www.freelists.org/webpage/oracle-l > > > -- //www.freelists.org/webpage/oracle-l