archive_lag_target

I’ve been involved in an interesting discussion over on the oracle forums. Disregarding the fact that one of the people posting would seem to want to blast me off into outerspace, I think after spending a brief amount of time on the forums I’ve come up with a couple of conclusions. First off you must be exceedingly precise in what you post and try and not overgeneralise, related to this it is important (as in most walks of life) to read the information presented by the previous posts very, very carefully. Lastly, but I think by no means least, you have to bear in mind that a lot of the people posting may not have english as their first language. There frankly is a lot of dross on there, but there are quite a few nuggets as well, I guess it’s all about sifting out that gold.

I do think archive_lag_target is a useful parameter and with appropriate sizing of your redo logs you can ensure you will only ever switch logs when you want to, not when you have filled them up. The paramter would have originally been useful for a dataguard environment running in managed recovery mode whereby redo would not have been applied to the standby until an archive log switch. This of course is not necessarily the case now with the introduction in 10g of real time apply (though this may have it’s own drawbacks).

I think archive_lag_target is as useful in a standalone environment as in a dataguard one and the point of giving a bound on the amount of data lost should you suffer media failure on your online redo logs is a sound one I think. Though, of course if you do have dataguard then hopefully upon media failure you could always failover to your DR site and suffer minimal disruption and data loss. Oh and it’s a real good idea to have your redo logs mirrored (or indeed multiplexed), but you knew that, right?

Advertisements

3 thoughts on “archive_lag_target

  1. Hi,

    1. What is the need for archive_lag_target in RAC as idle instances will be forced to switch logs [posting archive and Force checkpoint SCN] anyway.

    2. Based on RPO when RMAN backups are configured to backup archive logs every 15min there will be a global switch of log files [alter system archive log
    current]

    Regards,

    Abhilash

    • Hello,

      The whole thrust of this is to ensure that you balance having large archive logs to ensure you do not switch too frequently during peaks of activity, with not limiting your exposure to data loss.

      The rman option you mention sounds like it effectively will do a similar job, give you a guaranteed length of time in terms of data loss.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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