Oracle RMAN 11g Backup and Recovery (41 page)

An additional use of the FRA has to do with Flashback Database–related features. We discuss Oracle’s Flashback Database features in more detail in Chapter 15.

The FRA and ASM

RMAN supports the use of Automatic Storage Management (ASM) for the storage of RMAN backups.

What is ASM? ASM is a disk management tool that eliminates the need for the DBA to manage the physical files associated with a given database. ASM is somewhat like the logical volume groups you might be used to in Unix. ASM uses
ASM disk groups,
which are logical units of storage.

Physical disks are assigned to an ASM disk group, providing the overall storage capability of that ASM disk group. ASM disk groups can exist on previously allocated file systems or on raw disks.

Combined with OCFS, clustered servers can share ASM disks in RAC configurations. Having configured ASM and having defined the various disk groups, you can then assign datafiles, control files, online redo logs, and various RMAN backup files to the ASM disk groups.

ASM offers a number of features including load balancing, data redundancy, and easy addition and removal of new disks to the ASM disk groups. It is beyond the scope of this book to discuss configuration of ASM in general. However, be aware that RMAN does support ASM disk groups should you wish to use them. We are not necessarily recommending ASM in this book. Most non-RAC sites probably will find little value in an ASM implementation. However, if you are a RAC

site, you might want to consider ASM coupled with OCFS as an alternative to other clustering options, depending on your platform.

If you are using ASM, you can configure the FRA such that it will be created in the ASM file system, as shown in this example:

alter system set db recovery file dest '+ASMV01';

In this case, Oracle will use the ASM disk volume ASMV01 for the FRA. We can then use RMAN to back up to the FRA. We will discuss backups in Chapter 11.

Chapter 3: RMAN Setup and Configuration
71

Should You Use the FRA?

We think the idea behind the FRA is a good one. We also like to copy those backups to some other media, such as tape, so we can send them offsite for disaster recovery purposes (nothing like a good flood, bomb, or tornado to make your disaster recovery planning seem really important).

We also like the FRA for the archived redo logs, but we also like the idea of copying archived redo logs to more than one location (and more specifically, to more than one disk). Keep in mind that the archived redo logs are critical to database recovery, and if you lose one, all the others after that one are pretty much worthless. So, we tend to configure our databases using FRA and at least one other archive log destination that is on a different disk. This means that we use the LOG_ARCHIVE_DEST_
n
parameters to configure the database to use both the FRA and another, separate file system to store our archived redo logs.

Another benefit of the FRA we like is the implementation of space quotas. Many database servers these days run more than one database. We have seen cases where one database has consumed all of the physical disk space with archived redo logs. This caused problems not only for the database that filled up the archived redo log destination directory, but also for all of the other databases on the system. By using a quota system, you can limit one database’s ability to impact others.

We could go beyond this and tell you how much we like things such as standby databases and the like, but that’s not what this book is about. The bottom line is that you need to protect the data in your charge, because there is no worse feeling than coming into work on Monday morning and finding out that the system crashed over the weekend and that the entire database is lost…along with all your backups.

Switching Between ARCHIVELOG Modes

Once you have configured the database to run in ARCHIVELOG mode, you can switch it between NOARCHIVELOG and ARCHIVELOG mode quite easily. To put the database in ARCHIVELOG mode, you must first shut down the database in a consistent state using one of these commands:
shutdown
,
shutdown immediate
, or
shutdown transactional
. Once the database has been cleanly shut down, mount the database by issuing the
startup mount
command. Once the database is mounted, issue the command
alter database archivelog
to put the database in ARCHIVELOG mode. You can then open the database with the
alter database
open
command.

If you wish to take the database out of ARCHIVELOG mode, reverse the process. First shut down the database. Once the database has been shut down, mount the database by issuing the
startup mount
command. Once the database is mounted, issue the command
alter database
noarchivelog
to put the database in NOARCHIVELOG mode. You can then open the database with the
alter database open
command.

If You Created Your Database with the Oracle Database

Configuration Assistant

If you created your database with the Oracle Database Configuration Assistant (ODBCA), it is likely that Oracle has configured much of RMAN for you. ODBCA will configure the database in ARCHIVELOG mode, configure the FRA, and even offer you the chance to schedule RMAN

72
Part II: Setup Principles and Practices

backups. For smaller installations, this may well be all that is needed, and you will not need to worry about any other basic RMAN configuration issues. Still, it’s a good idea to be aware of all the options that RMAN offers. For example, encryption of backups is not enabled when you create a database with the ODBCA, and you might want to enable that feature.

RMAN Workshop:
Put the Database in ARCHIVELOG Mode

Workshop Notes

For this workshop, you need an installation of the Oracle software, and a database that is up and running in NOARCHIVELOG mode. Before you start the workshop, determine where you want the flash recovery area to reside. You will also need to decide where a second archive log destination directory will be, as this workshop will have you archiving to two locations.

Step 1.
Configure both the FRA and a separate archive log destination for the archived redo logs.

First, set the FRA parameters DB_RECOVERY_FILE_DEST_SIZE and DB_RECOVERY_FILE_DEST: SQL> alter system set db recovery file dest size 2G;

System altered.

SQL> alter system set

db recovery file dest 'c:\oracle\product\10.2.0\flash recovery area';

System altered.

Step 2.
Now, define two archive log destination directories, one of which will be the FRA. Set the database parameter file, and set the LOG_ARCHIVE_DEST_1 parameter so that it is pointing to a predefined file system that will be our first archive log directory. Since we are configuring LOG_ARCHIVE_DEST_1 and we want to use the FRA, we need to set the LOG_ARCHIVE_DEST_

10 parameter to point to the FRA by using the parameter USE_DB_RECOVERY_FILE_DEST. Use the
show parameter
command to verify that the settings are correct: SQL> alter system set log archive dest 1 'location d:\archive\rob10R2'; System altered.

SQL> alter system set

log archive dest 10 'LOCATION USE DB RECOVERY FILE DEST';

SQL> show parameter log archive dest

NAME TYPE VALUE

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

log archive dest 1 string

location d:\archive\rob10R2

log archive dest 10 string

LOCATION USE DB RECOVERY FILE DEST

Step 3.
Shut down the database:

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

Chapter 3: RMAN Setup and Configuration
73

Step 4.
Mount the database:

SQL> startup mount

ORACLE instance started.

Total System Global Area 84700976 bytes

Fixed Size 282416 bytes

Variable Size 71303168 bytes

Database Buffers 12582912 bytes

Redo Buffers 532480 bytes

Database mounted.

Step 5.
Put the database in ARCHIVELOG mode:

SQL> alter database archivelog ;

Database altered.

Step 6.
Open the database:

SQL> alter database open;

Database altered.

Although it is not part of the workshop, the process of taking the database out of ARCHIVELOG

mode is as simple as reversing the process described in the workshop. Shut down the database, restart the database instance by issuing the
startup mount
command, and put the database in NOARCHIVELOG mode by issuing the command
alter database noarchivelog
. Note that you are not required to shut down the database in a consistent manner when moving from ARCHIVELOG mode to NOARCHIVELOG mode. Here is an example of switching back into NOARCHIVELOG mode: SQL> shutdown

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

Total System Global Area 84700976 bytes

Fixed Size 282416 bytes

Variable Size 71303168 bytes

Database Buffers 12582912 bytes

Redo Buffers 532480 bytes

Database mounted.

SQL> alter database noarchivelog;

Database altered.

SQL> alter database open;

Database altered.

Finally, you should do a backup of the database once you have completed either task.

The Oracle Database 11
g
Fault

Diagnosability Infrastructure

One of the major new features in Oracle Database 11
g
is the new Fault Diagnosability Infrastructure. We will cover various features associated with the new Fault Diagnosability throughout this book. This infrastructure is designed to help prevent, detect, diagnose, and resolve
74
Part II: Setup Principles and Practices

problems such as database bugs and various forms of corruption. This new infrastructure changes some things, such as where the alert log is generated, and adds a great deal of new functionality to the Oracle Database. Throughout this text we will discuss the Fault Diagnosability Infrastructure in more detail. In Chapter x, we will discuss the Support Workbench, which provides for automated responses to database problems. Chapter 13 will also discuss the health checkers, another new component associated with the Oracle Automatic Diagnostic Repository (ADR). In Chapters 12

and 13, we will talk about using the Recovery Advisor, closely linked to the ADR, during database restores.

For the purposes of setting up the Fault Diagnosability Infrastructure for an Oracle Database, what we are concerned with in this chapter is the setting of the new parameter DIAGNOSTIC_

DEST. The new DIAGNOSTIC_DEST parameter defines the root of the ADR and deprecates several parameters including USER_DUMP_DEST, CORE_DUMP_DEST, and BACKGROUND_

DUMP_DEST. As a result, if you create a new Oracle Database 11
g
database with the DBCA, you will not find the alert log or user trace files where you previously would have expected them.

By default, the DIAGNOSTIC_DEST parameter is set to $ORACLE_BASE. If $ORACLE_BASE

is not set, then it is set to the value of $ORACLE_HOME. The root directory of the ADR directory structure starts with a directory called diag, under which is a subdirectory that references the product type. For example, for the database, the product is called rdbms. Under rdbms is a directory for each database, followed by a directory for each individual instance.

For example, if $ORACLE_BASE is
/u01/oracle,
the database name is
mydb,
and the database instance is
mydb1,
then the structure of the ADR directory for that database will be /u01/oracle/

diag/rdbms/mydb/mydb1. This directory structure is called the ADR home, and each instance has its own ADR home. If you are using RAC, you can use shared storage for ADR, or individual storage on each node. We would recommend shared storage in a RAC environment since you can see the aggregate diagnostic data from any node. Also, a shared ADR allows for more robust recovery options for the Data Recovery Advisor.

Under this directory structure will be a number of other directories. Some of the most common directories include the following:

■
Alert
This is the location of the XML-formatted alert log.

■
cdump
This is the location of the core dumps for the database.

■
Trace
This contains trace files generated by the system, as well as a text copy of the alert log.

■
Incident
This directory contains multiple subdirectories, one for each incident.

Here is diagram of the ADR Base structure: