| Team Fly | |
Once the backup is complete, you will need to ensure that all of the log records created during the backup operation have been subsequently archived. Do this with the sql statement archive log current. This command ensures that all redo logs have been archived and it will wait for the archive to complete. You should note that the ocopy utility is required in Windows environments to allow a file to be shared between the copy utility and Oracle. It is not needed in UNIX environments.
After a hot backup has been successfully completed, the database can be recovered to a particular point in time by restoring the data files from the hot backup and rolling forward archive logs to the time required. Online redo logs should never be backed up during a hot backup. Rather, archive the current redo logs and back those up. As a result, you will create the redo logs at the end of recovery when an alter database open resetlogs is performed (resetlogs is discussed later in this chapter in the section ''Recovery Using Backup Control Files").
In order to recover from a hot or cold backup it is important to remember that all of the files that make up the database must be recovered to the same point in time in order to keep the entire database consistent. The exception to this rule is that read-only tablespaces can be restored to the point that they were made read-only. This makes sense since the tablespace cannot be changed once it has been made read-only. In order to recover a tablespace that is open for read-write operations to a point in time that is different from the rest of the database, a special operation called Tablespace Point In Time Recovery (TSPITR) must be performed which requires a clone database and is beyond the scope of this chapter.
Whenever a tablespace status changes to read-only or read-write, it should be backed up. You will need to keep track of these backups so that you know where they are when it comes time to use them in a recovery situation. Consider backing up "read only" tablespaces periodically to deal with potential expiry dates on tape as well as other tape management problems that could result from older tapes.
TIP
Run hot backups when the system is not busy. Also, only put one tablespace between the begin and end backup operations to reduce the amount of system overhead associated with this activity since system logging is increased on tablespaces that are in backup mode. You can group multiple tablespaces together in cases where change activity will not be high on them during the backup.
Hot backups and archivelogs will be a requirement of every system that has true high-availability requirements.
| Team Fly | |