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?