Oracle DBA – A lifelong learning experience

Standby databases – a few of gotchas

Posted by John Hallas on October 27, 2011

All of these items refer to Dataguard standby databases on 11GR1 and the  active dataguard license comment is applicable in 11GR2 as well.

LGWR: Insufficient standby redo logfiles to archive

The first is an error I see on a few databases and had assumed that it was to do with insufficient standby log files. The recommendation is that there should be at least one more than the normal redo log files so that applying the redo will not be delayed on standby, which would be critical in maximum protection mode when the primary would wait until log was applied remotely.

Wed Oct 19 11:58:13 2011
LGWR: Insufficient standby redo logfiles to archive thread 1 sequence 47505
LGWR: Standby redo logfile selected for thread 1 sequence 47505 for destination LOG_ARCHIVE_DEST_2
Thread 1 advanced to log sequence 47505 (LGWR switch)
Current log# 20 seq# 47505 mem# 0: +DATA/SID/onlinelog/group_20.2083.735986363
Current log# 20 seq# 47505 mem# 1: +FRA/SID/onlinelog/group_20.1668.735986365

MyOracleSupport document  798361.1 “LGWR: Insufficient standby redo logfiles to archive” Messages in Primary Database

This states:- Bug 8358103 – will be fixed in and “Insufficient standby redo logfiles” message is misleading as it is followed by “Standby redo logfile selected”, which indicates the standby redo logs is selected and being used. You can safely ignore these messages.  Note that is unlikely to happen as is the terminal release

Lag apply alert on standby database

The second is something I came across yesterday after we had performed a switchover from primary to standby. Normally we set the lag apply metric in OEM to alert us if standby gets more than 900 seconds behind). This is set in OEM for each database (unless you want to issue a modified template)

Database > Metric and Policy Settings > then first metric is Apply Lag (seconds) In order to see graph, you can go to all metrics > Data Guard Performance > Apply Lag (Seconds).

The alert is set on standby and yet when a switchover is invoked (I am assuming either by DG broker or manually as we did it, then we would expect that alert to be still in place. However it is removed and has to be re-applied.

Block change tracking on a standby requires active dataguard license

From 11GR1 onwards running a standby database with the block change tracking file enabled (which helps make incremental backups much faster) requires an active dataguard license to be in place. Whilst I think this policy is very mean spirited, especially when a license was not required in a similar situation on 10G it is a requirement and should not be ignored.

Hope these heads-up are useful

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: