Oracle RMAN 11g Backup and Recovery (27 page)

The
insert
statements (as well as
update
and
delete
commands) are collectively known as Data Manipulation Language (DML). As a statement is executed, redo is generated and stored in the redo log buffer in the Oracle SGA. Note that redo is generated by this command, regardless of the presence of the
commit
command. The
delete
and
update
commands work generally the same way with respect to redo generation.

One of the results of DML is that
undo
is generated and stored in
rollback segments.
Undo
consists of instructions that allow Oracle to undo (or roll back) the statement being executed.

Using
undo
, Oracle can roll back the database changes and provide
read consistent images
(also

Chapter 1: Oracle Database 11
g
Backup and Recovery Architecture Tour
25

known as read consistency) to other users. Let’s look a bit more at the
commit
command and read consistency.

Committing the Change

Having issued the
insert
command, Fred wants to ensure that this change is committed to the database, so he issues the
commit
command:

COMMIT;

The effects of issuing the
commit
command include the following:

■ The change becomes visible to all users who query the table at a point in time after the commit occurs. If Eliza queries the DEPT table after the commit occurs, then she will see department 60. However, if Eliza had already started a query before the commit, then this query would not see the changes to the table.

■ The change is recoverable if the database is in NOARCHIVELOG mode and if crash or instance recovery is required.

■ The change is recoverable if the database is in ARCHIVELOG mode (assuming a valid backup and recovery strategy) and media recovery is required and if all archived and online redo logs are available.

The
commit
command causes the Oracle LGWR process to flush the online redo log buffer to the online redo logs. Uncommitted redo is flushed to the online redo logs regardless of a commit (in fact, uncommitted changes can be written to the datafiles, too). When a commit is issued, Oracle writes a
commit vector
to the redo log buffer, and the buffer is flushed to disk before the commit returns. It is this commit vector, and the fact that the commit issued by Fred’s session will not return until his redo has been flushed to the online redo logs successfully, that will ensure that Fred’s changes will be recoverable.

The commit Command and Read Consistency
Did you notice that Eliza was not able to see Fred’s change until he issued the
commit
command? This is known as
read consistency.
Another example of read consistency would be a case where Eliza started a report before Fred committed his change. Assume that Fred committed the change during Eliza’s report. In this case, it would be inconsistent for department 60 to show up in Eliza’s report, since it did not exist at the time that her report started. As Eliza’s report continues to run, Oracle checks the start SCN of the report query against the SCNs of the blocks being read in Oracle to produce the report output. If the time of the report is earlier than the current SCN on the data block, then Oracle goes to the rollback segments and finds undo for that block that will allow Oracle to construct an image consistent with the time that the report started.

As Fred continues other work on the database, the LGWR process writes to the online redo logs on a regular basis. At some point in time, an online redo log will fill up, and LGWR will close that log file, open the next log file, and begin writing to it. During this transition period, LGWR also signals the ARCH process to begin copying the log file that it just finished using to the archive log backup directories.

26
Part I: Getting Started with RMAN in Oracle Database 11
g
Checkpoints

Now, you might be wondering, when does this data actually get written out to the database datafiles? Recall that a checkpoint is an event in which Oracle (through DBWR) writes data out to the datafiles. There are several different kinds of checkpoints. Some of the events that result in a checkpoint are the following:

■ A redo log switch

■ Normal database shutdowns

■ When a tablespace is taken in or out of online backup mode (see “Oracle Physical Backup and Recovery” later in this chapter)

Note that ongoing incremental checkpoints occur throughout the lifetime of the database, providing a method for Oracle to decrease the overall time required when performing crash recovery. As the database operates, Oracle is constantly writing out streams of data to the database datafiles. These writes occur in such a way as to not impede performance of the database. Oracle provides certain database parameters to assist in determining how frequently Oracle must process incremental checkpoints.

Oracle Backup and Recovery Primer

Before you use RMAN, you should understand some general backup and recovery concepts in Oracle. Backups in Oracle come in two general categories, logical and physical. In the following sections, we quickly look at logical backup and recovery and then give Oracle physical backup and recovery a full treatment.

Logical Backup and Recovery

Oracle Database 11
g
uses the Oracle Data Pump architecture to support logical backup and recovery. These utilities include the Data Pump Export program (
expdp
) and the Data Pump Import program (
impdp
). With logical backups, point-in-time recovery is not possible. RMAN

does not do logical backup and recovery, so this topic is beyond the scope of this book.

Oracle Physical Backup and Recovery

Physical backups are what RMAN is all about. Before we really delve into RMAN in the remaining chapters of this book, let’s first look at what is required to manually do physical backups and recoveries of an Oracle database. While RMAN removes you from much of the work involved in backup and recovery, some of the principles remain the same. Understanding the basics of manual backup and recovery will help you understand what is going on with RMAN and will help us contrast the benefits of RMAN versus previous methods of backing up Oracle.

We have already discussed ARCHIVELOG mode and NOARCHIVELOG mode in Oracle. In either mode, Oracle can do an offline backup. Further, if the database is in ARCHIVELOG mode, then Oracle can do offline or online backups. We will cover the specifics of these operations with RMAN in later chapters of this book.

Of course, if you back up a database, it would be nice to be able to recover it. Following the sections on online and offline backups, we will discuss the different Oracle recovery options available. Finally, in these sections, we take a very quick, cursory look at Oracle manual backup and recovery.

Chapter 1: Oracle Database 11
g
Backup and Recovery Architecture Tour
27

NOARCHIVELOG Mode Physical Backups

We have already discussed NOARCHIVELOG mode in the Oracle database. This mode of database operations supports backups of the database only when the database is shut down. Also, only full recovery of the database up to the point of the backup is possible in NOARCHIVELOG

mode. To perform a manual backup of a database in NOARCHIVELOG mode, follow these steps (note that these steps are different if you are using RMAN, which we will cover in later chapters):
1.
Shut down the database completely.

2.
Back up all database datafiles, the control files, and the online redo logs.

3.
Restart the database.

ARCHIVELOG Mode Physical Backups

If you are running your database in ARCHIVELOG mode, you can continue to perform full backups of your database with the database either running or shut down. Even if you perform the backup with the database shut down, you will want to use a slightly different cold backup procedure:

1.
Shut down the database completely.

2.
Back up all database datafiles.

3.
Restart the database.

4.
Force an online redo log switch with the
alter system switch logfile
command. Once the online redo logs have been archived, back up all archived redo logs.

5.
Create a backup of the control file using the
alter database backup control file to trace
and
alter database backup controlfile to ‘file_name’
commands.

Of course, with your database in ARCHIVELOG mode, you may well want to do online, or hot, backups of your database. With the database in ARCHIVELOG mode, Oracle allows you to back up each individual tablespace and its datafiles while the database is up and running. The nice thing about this is that you can back up selective parts of your database at different times.

To do an online backup of your tablespaces, follow this procedure:

1.
Use the
alter tablespace begin backup
command to put the tablespaces and datafiles that you wish to back up in online backup mode. If you want to back up the entire database, you can use the
alter database begin backup
command to put all the database tablespaces in hot backup mode.

2.
Back up the datafiles associated with the tablespace you have just put in hot backup mode. (You can opt to just back up specific datafiles.)

3.
Take the tablespaces out of hot backup mode by issuing the
alter tablespace end backup
command for each tablespace you put in online backup mode in Step 1. If you want to take all tablespaces out of hot backup mode, use the
alter database end backup
command.

4.
Force an online redo log switch with the
alter system switch logfile
command.

5.
Once the log switch has completed and the current online redo log has been archived, back up all the archived redo logs.

28
Part I: Getting Started with RMAN in Oracle Database 11
g
Note the log switch and backup of archived redo logs in Step 5. This is required, because all redo generated during the backup must be available to apply should a recovery be required. While Oracle continues to physically update the datafiles during the online backup (except for the datafile headers), there is a possibility of block splitting during backup operations, which will make the backed up datafile inconsistent. Further, since a database datafile might be written after it has been backed up but before the end of the overall backup process, it is important to have the redo generated during the backup to apply during recovery because each datafile on the backup might well be current as of a different SCN, and thus the datafile backup images will be inconsistent.

Redo generation changes when you issue the
alter tablespace begin backup
command or
alter database begin backup
command. Typically, Oracle only stores change vectors as redo records. These are small records that just define the change that has taken place. When a datafile is in online backup mode, Oracle will record the entire block that is being changed rather than just the change vectors. This means total redo generation during online backups can increase significantly. This can impact disk space requirements and CPU overhead during the hot backup process. RMAN enables you to perform hot backups without having to put a tablespace in hot backup mode, thus eliminating the additional I/O you would otherwise experience. Things return to normal when you end the online backup status of the datafiles.

Note that in both backups in ARCHIVELOG mode (online and offline), we do not back up the online redo logs, and instead back up the archived redo logs of the database. In addition, we do not back up the control file, but rather create backup control files. We do this because we never want to run the risk of overwriting the online redo logs or control files during a recovery.

You might wonder why we don’t want to recover the online redo logs. During a recovery in ARCHIVELOG mode, the most current redo is likely to be available in the online redo logs, and thus the current online redo log will be required for full point-in-time recovery. Because of this, we do not overwrite the online redo logs during a recovery of a database that is in ARCHIVELOG mode. If the online redo logs are lost as a result of the loss of the database (and hopefully this will not be the case), then you will have to do point-in-time recovery with all available archived redo logs.

For much the same reason that we don’t back up the online redo logs, we don’t back up the control files. Because the current control file contains the latest online and archived redo log information, we do not want to overwrite that information with earlier information on these objects. In case we lose all of our control files, we will use a backup control file to recover the database.

Finally, consider performing supplemental backups of archived redo log files and other means of protecting the archived redo logs from loss. Loss of an archived redo log directly impacts your ability to recover your database to the point of failure. If you lose an archived redo log and that log sequence number is no longer part of the online redo log groups, then you will not be able to recover your database beyond the archived redo log sequence prior to the sequence number of the lost archived redo log.