Oracle RMAN 11g Backup and Recovery (14 page)

Within redo logs are records called
change vectors.
Each change vector represents an atomic database change, in SCN order. During recovery (RMAN or manual), Oracle applies those change vectors to the database. This has the effect of applying all change records to the database in order, thus recovering it to the point in time of the failure (or another, earlier time if required). The LGWR

process is responsible for writing the change vectors (cumulatively known as redo) to the online redo logs from the redo log buffer. We discuss this in more detail shortly in the section, “The Combined Picture.”

Archived Redo Logs
A
log switch
occurs when Oracle stops writing to one online redo log and begins to write to another. As the result of a log switch, if the database is in ARCHIVELOG mode and the ARCH process is running, a copy of the online redo log will be made. This copy of the online redo log is called an archived redo log. Oracle can actually copy the archived redo log files to up to ten different destinations. During media recovery, the archived redo logs are applied to the database to recover it. We discuss this in more detail shortly, in “The Combined Picture.”
Database Control Files
Each Oracle database has one or more database control files. The control file contains various database information, such as the current SCN, the state of the database datafiles, and the status of the database. Of interest to the RMAN DBA is the fact that the control file also stores critical information on various RMAN operations, such as the backup status of each database datafile. If you lose your control file, you will need to follow specific procedures to re-create the RMAN catalog within it. Also of interest might be the fact that the checkpoint SCN

(or the SCN of the last update of a given datafile) is stored in the control file. Oracle will crosscheck this checkpoint SCN with the checkpoint SCNs stored in the datafile headers. If they all match, the database requires no recovery whatsoever. If the SCNs do not match, then some form of recovery will be required. Typically this will be crash recovery, which is automated. Sometimes, for example if a data file is missing, media recovery will be required.

Oracle Tablespaces
Our tour continues into a somewhat metaphysical part of Oracle.

Tablespaces are the link between the physical world of Oracle, in the form of the database datafiles, and the logical world, in the form of the Oracle tablespace. Often, we refer to a tablespace as a physi-logical structure. Oracle stores objects within tablespaces, such as tables and indexes.

A tablespace is physically made up of one or more Oracle database datafiles. Thus, the overall space allocation available in a tablespace depends on the overall allocated size of these database datafiles. A tablespace can be OFFLINE or ONLINE, and may also be in either READ

WRITE or READ ONLY mode. If a tablespace is in READ ONLY mode, the contents of the tablespace will not change. Because the contents of a READ ONLY tablespace do not change, DBAs often only back up READ ONLY tablespace database datafiles once, immediately after they are made read only. Of course, if the tablespace is ever taken out of READ ONLY mode, you need to start backing up the tablespace again.

16
Part I: Getting Started with RMAN in Oracle Database 11
g
Flashback Logs
Oracle Database 10
g
introduced the capability to flashback the Oracle database to a time other than the current time. This capability is facilitated through the use of flashback logs. Flashback logs are stored in the FRA. Oracle is solely responsible for the management of flashback logs, so it will create, remove, and resize them as required. Also note that flashback logs are not archived by Oracle and are not needed for recovery. RMAN supports flashback recovery.

The Flash Recovery Area

Oracle Database 10
g
introduced the concept of the FRA, which allows you to define a central area of disk space for recovery-related files such as RMAN backups and archived redo logs. The flash recovery area should not be confused with Oracle’s Flashback Database features, though the FRA does participate in Flashback Database operations. The FRA is so much more than Flashback Database, though. The following structures can be stored in the FRA:

■ Archived redo logs

■ RMAN backup set pieces

■ RMAN datafile copies

■ Flashback logs

■ A copy of the database control file

■ One member of each redo log group

■ Control file autobackups and copies

We will discuss the FRA in much more detail in Chapters 2 and 3.

Oracle Automatic Storage Management

Oracle ASM is Oracle’s answer to the need for an integrated system to manage database files.

ASM supports a number of different file system types, from cooked disk drives, to raw disk drives, to NetFiler devices. The idea of ASM is to simplify the life of the DBA by making Oracle responsible for basic disk management operations such as load balancing and data protection. RMAN supports the ASM infrastructure in that you can place your database FRA on ASM disks, or you can back up directly to ASM disks.

While ASM has its place, we feel that it is mega-overkill for most Oracle installations. If you have a single, non-RAC server with two or three databases, you do not need ASM. In this book, we provide ASM coverage so that if you are using RMAN and ASM, you can back up and recover using ASM.

More About the Oracle Redo Logs

We have talked about the Oracle redo logs somewhat already, but they are such important things, even when talking about RMAN, that we wanted to dive into a bit more detail. You might ask,

“But doesn’t RMAN take care of everything for me?” RMAN certainly tries to take care of everything for you, but you will find times that it’s your knowledge that will give you the insight to truly save the day. Indeed, just having a recipe to follow might well not be enough. You need to understand the whys and mechanics behind Oracle backup and recovery. As Carl Jung said: “The shoe that Chapter 1: Oracle Database 11
g
Backup and Recovery Architecture Tour
17

fits one person pinches another; there is no recipe for living that suits all cases.” Just knowing the rudiments of backup and recovery does not prepare you for all potential problems you will face.

Redo logs are typically created when the database is first created, and as the database changes, you may find that you need to modify the online redo log files by creating more of them, making them larger, or perhaps renaming them. Since you are an enlightened DBA and want to know everything you can about backup and recovery of your database, you will want to understand online and archived redo logs. In this section, we will talk about redo logs in a bit more detail.

First, we will look at redo logs in general. Next, we will look at the multiplexing of online redo log groups and the redo log sequence number. Finally, we will address administration of online redo logs.

An Overview of Redo Logs

Oracle redo logs come in two flavors:

■ Online redo logs

■ Archived redo logs

Redo logs are one of the most critical components when restoring and recovering an Oracle database. This is because redo logs store a history of almost everything that happens in your database. During normal database operations, the Oracle LGWR process will write to an online redo log, creating a change record that you really hope you never have to use.

The LGWR process will write information called redo to the online redo log files as the redo is generated by Oracle transactions.
Redo
is simply a record of what occurs in the database and the order that those events happen in. Redo is generated by almost every Oracle operation including DML, DDL, and transactional commit operations. During recovery, Oracle will read the redo and essentially replay the redo in the order it was generated to recover the database. Sometimes this recovery is behind the covers and requires no DBA activity (as with crash recovery), but sometimes, such as in the case of database or datafile recovery, the DBA has to get involved.

Online redo log files are fixed in size. Once the LGWR process has reached the end of a given online redo log file, it will close that file and try to find another online redo log file to write to. This process is called a
log switch.
A log switch is a serial process, and potentially very expensive from a performance point of view. This isn’t a performance book though, so we won’t go into the performance aspects of a log switch.

During a log switch, LGWR will look for an available online redo log file that it can write to.

If it finds an available online redo log file, it will open that file and begin to write to it. If LGWR

cannot find an available file, then it will wait for an online redo log to become available. While it’s waiting, LGWR will be busy writing complaining messages to the alert log and other places, and database operations will be suspended. Database managers typically are not too happy if your databases stop, so we want to avoid that if at all possible!

Each online redo log file that is created is assigned to an
online redo log group.
In a nonclustered configuration, Oracle will only write to one redo log group at a time. If you are running Real Application Clusters (RAC), each RAC instance will write to its own set of redo log groups.

Online redo log groups can have one of several different statuses:

■
Current
This is the online redo log that is in use.

■
Active
This is an online redo log that is not in the current redo log file group, but it’s still waiting for the ARCH process to finish copying redo to the archived redo logs.

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

■
Inactive
This is an online redo log that isn’t active and has been archived.

■
Unused
This is an online redo log that has yet to be used by the Oracle database.

The status of an online redo log group can be seen by querying the V$LOG view as seen here: SQL> select group#, status from v$Log;

GROUP# STATUS

---------- ----------------

1 INACTIVE

2 INACTIVE

3 INACTIVE

4 CURRENT

Multiplexing Online Redo Logs

If you want to have a really bad day, then just try losing your active online redo log. If you do, it’s pretty likely that your database is about to come crashing down and that you will have experienced some data loss. This is because recovery to the point of failure in an Oracle database is dependent on the availability of the online redo log. As you can see, the online redo log makes the database vulnerable to loss of a disk device, mistaken administrative delete commands, or other kinds of errors. To address this concern, you can create mirrors of each online redo log. When you have created more than one copy of an online redo log, the group that log is a member of is called a
multiplexed online redo log group.
Typically these multiplexed copies are put on different physical devices to provide additional protection for the online redo log groups. For highest availability, we recommend that you separate the members of each online redo log group onto different disk devices, different everything… Here is an example of creating a multiplexed online redo log group:

alter database add logfile group 4

('C:\ORACLE\ORADATA\BETA1\REDO04a.LOG','C:\ORACLE\ORADATA\BETA1\REDO04b.LOG') size 100m reuse;

Each member of a multiplexed online redo log group is written to in parallel, and having multiple members in each group rarely causes performance problems.

The Log Sequence Number

As each online redo log group is written to, that group is assigned a number. This is the
log
sequence number.
The first log sequence number for a new database is always 1. As the online redo log groups are written to, the number will increment by one during each log switch operation.

So, the next online redo log being written to will be log sequence 2, and so on.