Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It only takes a minute to sign up.
Sign up to join this community
Oracle® Database Backup and Recovery Basics 10g Release 2 (10.2) says that
Archived redo logs are the key to successful media recovery. Back them up regularly.
But, I wonder, why backups of archive logs is so important. Would it be possible to do point-in-time recovery just using regular RMAN full and incremental datafile backups.
No, you still need archived redo logs. An RMAN backup is not the same as a cold backup; when you restore it you need to apply all the redo generated from the time you started the backup until the time the backup completed in order to get the SCN consistent across all the datafiles and the controlfile.
Let us consider the old fashioned hot backup. In this mode, entire changed database blocks are written to the redo log stream, and the file is copied in the OS. This causes fractured blocks, i.e. the block has changed during the read by the backup. So to recover the database, we restore the DBFs, then the recovery process overlays the changed blocks from the archived redo logs onto the fractured blocks in the file, and we get back to a consistent database.
In an RMAN backup the problem of fractured blocks is eliminated because the blocks are read by Oracle via the SGA not by a Unix tool like cp. However the DBF changes between the time the first block is read and the last block, so it is the same problem, just at a larger scale. That is to say, the SCN changes between the first and last blocks in a backup. The archived redo logs cover this as well.
RMAN gives you the manageability of the catalog, and a means to do hot backups without needing to generate redo at a much higher rate (which puts its own stress on the disks, the backup system etc). However BACKUP DATABASE will not give you a consistent database in and of itself; the only way to do that in Oracle is the cold backup.
Backing up Archive logs is only necessary when running in Archive log mode, so the question comes back to whether the database should do this or not. This is covered in the same document you reference under the heading Deciding Between ARCHIVELOG and NOARCHIVELOG Mode. Here is an excerpt:
Deciding Between ARCHIVELOG and NOARCHIVELOG Mode
The redo logs of your database provide a complete record of changes to the datafiles of your database (with a few exceptions, such as direct path loads).
You can run your database in one of two modes: ARCHIVELOG mode or NOARCHIVELOG mode. In ARCHIVELOG mode, a used online redo log group must be copied to one or more archive destinations before it can be reused. Archiving the redo log preserves all transactions stored in that log, so that they can be used in recovery operations later. In NOARCHIVELOG mode, the online redo log groups are simply overwritten when the log is reused. All information about transactions recorded in that redo log group is lost.
2.3.3.1 Implications of Running in NOARCHIVELOG Mode
Running your database in NOARCHIVELOG mode imposes severe limitations on your backup and recovery strategy.
You cannot perform online backups of your database. You must shut your database down cleanly before you can take a backup in NOARCHIVELOG mode.
You cannot use any data recovery techniques that require the archived redo logs. These include complete and point-in-time media recovery, as described in "Forms of Data Recovery", and more advanced recovery techniques such as point-in-time recovery of individual tablespaces and Flashback Database (described in Oracle Database Backup and Recovery Advanced User's Guide.).
If you are running in NOARCHIVELOG mode and you must recover from damage to datafiles due to disk failure, you have two main options for recovery:
Drop all objects that have any extents located in the affected files, and then drop the files. The remainder of the database is intact, but all data in the affected files is lost.
Restore the entire database from the most recent backup, and lose all changes to the database since the backup. (Recovering changes since the backup would require performing media recovery, which uses the archived redo logs.)
...
When performance requirements are extreme or disk space limitations are severe, it may be preferable to run in NOARCHIVELOG mode in spite of the limitations that this choice imposes upon your recovery options.
You almost always will want to run in ARCHIVELOG mode, therefore you almost always want to backup your archive logs.
