Here’s a simple script that anyone can use to check for lags in Data Guard. Basically, there’s two kind of lags in Data Guard that we want to monitor. The first is the apply_lag which is the amount of time the standby database is lagging behind relative to the primary database due to application of redo data. The second is the transport_lag which provides information about how much redo data is behind (in terms of time) because it is not available or applicable on the standby database. The transport lag can be used to determine bandwidth issues between the primary and stanby database sites.

You can specify the MIN_THRESHOLD parameter which will be the 2nd parameter that is passed into the dg_check_lag.ksh script (below). For lot of our customers who are on Active Data Guard, we change this script to determine seconds that the transport and apply lag is behind by. It is common for us to send alerts when the transport or apply lag is greater than 30 seconds for Active Data Guard customers.

Stay tuned as I will reveal scripts to monitor gaps in archive log sequences. I use the term gap loosely here as it is not determining the gap from v$archive_gap but looking at the number of applied archive logs on the standby database and comparing the applied archive logs to the maximum sequence number based on the thread number.

Come visit Viscosity North America for latest updates to local events, white papers and case studies.

Comments are closed