hot backups and archivelog mode

Hot Backups and Archivelog Mode Backup and Recovery Tips

Copyright © Howard Rogers 2001 19/10/2001 of 2

Must I take Hot Backups in archivelog mode? What does archivelog mode mean? Merely that an Online Redo Log which has a status of ACTIVE may not be overwritten, and that an Online Redo Log will remain in an ACTIVE state unless and until it has been copied. That’s all it means. It doesn’t even arrange for the copy to be taken (that’s the job of ARCH, and is provided for only when the init.ora is adjusted to include the line LOG_ARCHIVE_START=TRUE) –which is why your database will eventually hang if all you do is put it into archivelog mode (eventually, all your Online Redo Logs will fill, loop back on top of themselves, and the first one will still be sitting there with an ACTIVE status, because ARCH has not been switched on and taken its copy). So whether you are in archivelog mode or not makes precisely zilch difference to whether or not you have to take hot or cold backups. The choice is still yours, and either would be acceptable. The real point, of course, is that hot backups are simply not possible unless the database is in archivelog mode and ARCH has been switched on. Hot copies of datafiles will be internally inconsistent, and unusable… but the application of redo will make them consistent and useable. So hot backups depend upon the supply of all redo since the time the backup started, if they are to be rendered usable –and that rather suggests that archives (which represent an uninterrupted redo stream reaching back in time much further than the online logs alone could manage) need to be available to make hot backups useful in the event of disaster. So only in archivelog mode can you perform hot backups. But the syllogism is not commutative –in plain English, the fact that hot backups require you to be in archivelog mode does not imply that archivelog mode requires you to take hot backups. Put yet another way: archivelog mode guarantees that you’ll be able to perform complete database recovery, with zero data loss (because you’ll be able to supply all required redo). But that can be achieved just as well by restoring from a cold backup as it can from a hot one: it’s the application of redo that recovers data, not the type of data file backup that its being applied to. I’d go so far as to suggest that the best possible backup strategy, combining ease of backup with total data recoverability, would be a closed (‘cold’) database backup taken whilst in archivelog mode. Cold backups are dead easy to perform (COPY *.* springs to mind as the script required!), and the presence of archives merely means that a restore from that backup can be rolled forward right to the time of failure –hence no data loss.

hot backups and archivelog mode

Documents