Oracle, Hot Backups, and Redo Logs

W. Curtis Preston

In September's edition of lost+found, I explained the different parts of Oracle architecture, and especially how they relate to backup. This month's column centers around two very important issues: how a hot backup of an Oracle database actually works, and how you can manage your archived redo logs. If some of the terms used in this article seem new to you, the September column should help define them. (http://www.sysadminmag.com/documents/sam0109g/)

Inside a Hot Backup

What happens during a hot backup is widely misunderstood. Many people believe that while a tablespace is in backup mode, the datafiles within that tablespace are not written to. They believe that all changes to these files are kept in the redologs until the tablespace is taken out of backup mode, at which point all changes are applied to the datafiles just as they are during a media recovery. Although this explanation is easier to understand (and swallow) than how things really work, it is absolutely not how hot backups work in Oracle.

A common reaction to this statement is a very loud "What?" followed by crossed arms and a really stern look. (I reacted the same way the first time I heard it.) "How could I safely back up these files if they are changing as I'm backing them up?" Don't worry -- Oracle has it all under control. Remember that every Oracle datafile has an SCN that is changed every time an update is made to the file. Also remember that every time Oracle makes a change to a datafile, it records the vector of that change in the redolog. Both of these behaviors change during hot backups. When a tablespace is put into backup mode, the following three things happen:

1.