Why_RMAN

8/2/2019 Why_RMAN

1/9

Michael S. AbbeyNtirety Technologies LLC 1

______________________________________________________________________

Not Using rmanIt's Time

Session S645 Oracle Open World 2005

Not Using rman? It's time

Session S645 Michael S. Abbey Database Office Oracle Practice

Ntirety LLC [email protected]

Recovery Manager ( rman )the flagship of Oracle's Backup and Recovery tools for the past

four releases of the server software. There was never anything wrong per se with any other

of Oracle's backup solutions; suffice to say rman is THE place to be by Database 10 g if not

sooner. The following verbiage is going to fast-track you into the wonderful world of rman

and help you avoid some of the frustrations that all too many of us have encountered. It's

these frustrations that seem insurmountable; they tempt us to put off the transition to rman

to a "better and more convenient time". More and more of the fancy flashback and block

level change tracking capabilities are imbedded in the rman technology. Savvy DBA's would

be smart to wrap their arms around rman now instead of trying to hit the ground running

with an unfamiliar piece of software when disaster strikes. First let's look at some decisions

and offer advice on the best practices.

Why Rman The decision to use rman is driven by many of the following reasons:

Does not explicitly rely on any operating system commands to perform its work.

Traditional online backups use the O/S copy command to get a copy of the database

files from their current locations to a backup area or media.

Does not require any signaling to the database that an item is being backed up.

Traditional backups involve an alter tablespace begin backup; and alter tablespace

end backup; commands at the start and end of the backup. Alternative

mechanisms are used to ensure backups are consistent and usable.

Is more tightly integrated with the software, and therefore less prone to DBA error.

Can be integrated directly with a wide assortment of tape and alternative storage

media.

8/2/2019 Why_RMAN

2/9


______________________________________________________________________



Backup set piece sizes are related to the amount of activity on the database since the

most recent backup, not the size of the database files.

Backup and recovery performed by server sessions, taking advantage of performance

enhancing and throughput boosters introduced to all other database activities. Performs integrity checks on the backed up data similar to that done when data is

assembled for query result sets in SQL*Plus.

Offers true block level incremental backups by ignoring data blocks that have never

contained any data or whose contents have not changed.

Natively spawns parallel backup and recovery processes (is using Enterprise Edition).

Assists the process of duplicating a database elsewhere or preparing a standby

database.

Permits the DBA to test the recoverability of a backup without actually restoring any

data.

Metadata about backups is automatically stored in the rman catalogue, making the

retrieval of backup details turnkey. This metadata is especially helpful when mapping

out a recovery exercise.

MetadataCatalog or Nocatalog

As rman interacts with the database, it writes metadata related to the work it is performing.

That metadata is automatically stored in an instance control file. Picture the following

2AM, and for some reason all copies of your control files are unreadable. As an efficient and

savvy DBA, you have incorporated daily runs of the alter database backup controlfile to trace;

commands into your backup arsenal. The quickest way to rebuild the controlfile is using

fresh output from that command. Suppose you have 30 days of rman information in your

control filesguess what happens as the control files are re-created? You guessed itbye

bye metadata. It gets even worse from time-to-time, Oracle overwrites records in itscontrol files and, if those records contain rman metadata information, it is lost.

Best practice : Always use a recovery catalog with rman. You have redundant metadata about your backups.

8/2/2019 Why_RMAN

3/9


______________________________________________________________________



The Catalog Instance

Fortunately, this is nothing other than a standard Oracle database. Whether you use the

database configuration assistance, or do it yourself, the following decisions have to be made

prior to creation.

Where Should it Reside

Initially, one considers storing the catalog instance on a separate server. In a situation where

the catalog is going to serve a handful of databases, one selects a location accessible from all

sites. Often licensing constraints determine the recovery catalog location. Some companies

have multiple servers licensed for Oracle and can implement the bullet-proof backup

solution for their catalog instancethe physical standby. "Recovey catalog" is a fancy way of

saying database; it is just that, similar in structure to any other instance but playing a special

role in one's disaster recovery toolset. Table 1 outlines the most common plus' and minus' of

choosing locations for a recovery catalog instance.Location + -

Same server No SQL*Net involved in backups Loss of catalog at same time asproduction

Easy implementation of production-ready backup routines

Resources required to performcatalog backups

More frequent accessibility tosecondary storage device(s) like tape

Memory required for catalog SGA

Different server Immune from production serveroutages

License costs

Production shielded from catalog instance resource requirements

Failure could result in loss of transactions in 1 archived redo log

Best practice : If possible, run your catalog instance on the same server as production with a physical standby in the same location as production's.

Setup Checklist

The following checklist outlines the steps involved in fast-tracking you to rman nirvana.Create admin directories to accommodate trace files and archived redo

Make an initialization parameter file from an existing instance; edit to suit the catalog instancememory structures and file locationsEnsure UNDO _ MANAGEMENT = AUTO and UNDO _ TABLESPACE = UNDOTBS are set in the init file

Create data directories to accommodate the infrastructure to support the catalog instance

8/2/2019 Why_RMAN

4/9


______________________________________________________________________



Create the database using scripts similar to those shown next

Create the catalog user's tablespace

Create the catalog user, and tweak its environment to permit owning a catalog schema

Create a tnsnames.ora entry for the catalog instance

Ensure the catalog instance is accessible via SQL*Net

Set the ORACLE _ SID to point at the production databaseConnect to rman, and create the catalog

Register the target database in the catalog

Repeat for as many databases that need to be backed up

The following few sections present code to accomplish some of the tasks in the above

checklist.

Create Database

set echo on sqlbl onstartup nomount

create database rcatcontrolfile reusemaxlogfiles 16maxlogmembers 4maxdatafiles 16384maxinstances 2maxloghistory 2048character set we8iso8859p1

logfile group 1 (' {location}/{SID} /log1_g1.rdo',' {location}/{SID} /log2_g1.rdo') size 50m,

group 2 (' {location}/{SID} /log1_g2.rdo',' {location}/{SID} /log2_g2.rdo') size 50m,

group 3 (' {location}/{SID} /log1_g3.rdo',' {location}/{SID} /log2_g3.rdo') size 50m

datafile ' {location}/{SID} /system01.dbf' size 300mautoextend on next 100m maxsize 2001m extent management local

sysaux datafile ' {location}/{SID} /sysaux01.dbf' size 300mautoextend on next 100m maxsize 2001m

default temporary tablespace loc_temp tempfile' {location}/{SID} /loc_temp01.dbf' size 1024mextent management local uniform size 10m

undo tablespace undotbs datafile' {location}/{SID} /undotbs01.dbf' size 1024m

The text in red is where you would substitute your site-specific directory names and chosebn

ORACLE _ SID.

Administration Scripts conn / as sysdba

set echo off

@?/rdbms/admin/catalog

8/2/2019 Why_RMAN

5/9


______________________________________________________________________



@?/rdbms/admin/catproc@?/rdbms/admin/catrep@?/rdbms/admin/catexp@?/rdbms/admin/catldr@?/rdbms/admin/dbmsutil@?/rdbms/admin/prvtutil.plb@?/rdbms/admin/dbmssql@?/rdbms/admin/prvtsql.plb

@?/rdbms/admin/dbmsdefr@?/rdbms/admin/prvtdefr.plb@?/rdbms/admin/catqueue@?/rdbms/admin/dbmsaqad@?/rdbms/admin/prvtaqad.plb@?/rdbms/admin/catcr@?/rdbms/admin/prvtcr.plb

connect system/manager

@?/rdbms/admin/catdbsyn@?/sqlplus/admin/pupbld.sql

conn / as sysdba@?/rdbms/admin/utlrp

The Catalog Owner's Tablespace

create tablespace rman datafile' {location}/{SID} /rman01.dbf' size 200mextent management local autoallocatesegment space management auto;

create user rman identified by rmantemporary tablespace loc_tempdefault tablespace rman quota unlimited on rman;

grant recovery_catalog_owner to rman;grant connect,resource to rman;

SQL*Net Considerations If the rman catalog is to be accessed from anywhere not local to the server upon which it

resides, this section applies. On each server that needs to access the rman catalog instance,

proceed to the $ ORACLE _ HOME /network/admin directory where the target database resides

and make an entry in its tnsnames.ora referring to the recovery catalog instance. This

resembles something like:rcat =(DESCRIPTION =

(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = rman.instance.ip.address)(PORT = 1521)))

(CONNECT_DATA =(SERVICE_NAME = rcat )

))

8/2/2019 Why_RMAN

6/9


______________________________________________________________________



The listener.ora where the catalog resides needs an entry to intercept request connections to

the catalog. This resembles:(SID_DESC =

(ORACLE_HOME = /fully/pathed/location/of/$ORACLE_HOME)(SID_NAME = rcat)

)

Registering Database(s) in Catalog

All that is left is to register databases in the recovery catalog as follows:rman target / catalog rman/rman@rcat

Recovery Manager: Release 10.1.0.4 - Production

Copyright (c) 1995, 2004, Oracle Corporation. All rights reserved.

connected to target database: RM1 (DBID=3810339942)connected to recovery catalog databaserecovery catalog is not installed

RMAN> create catalog;recovery catalog createdRMAN> register database;

database registered in recovery catalogstarting full resync of recovery catalogfull resync completeRMAN>

This is run once for each database that is destined to be backed up using the just-created

catalog.

Note : If possible, run your catalog instance on the same server as production with a physical standbythe same location as production's.

Backing up the Catalog Database

The catalog instance is backed up using rman itself as well as Oracle Data Pump. The

following suggestions should get you on the right track:

1. Do a nocatalog backup; when invoking rman, use the nocatalog construct. There is no

need to have a separate script to backup this catalog. Whatever operating system you

are using, build the rman connection string dynamically as follows:if [ "$ORACLE_SID" = "rcat" ]; then

CONN_STR=nocatalogelse

CONN_STR="catalog rman/rman@rcat"fi......rman target / "$CONN_STR" ...

8/2/2019 Why_RMAN

7/9


______________________________________________________________________



2. Write two data pump exports: FULL= Y CONTENT = METADATA _ ONLY gets the infrastructure of the catalog

instance FULL= Y

3. Generate the code to recreate the instance control file; this can be easily edited to

become a CREATE DATABASE script. Enter SQL*Plus as sysdba, and issue the "alter

database backup controlfile to trace;" command then get a copy of the most recent

file in USER _ DUMP _ DEST to use if and when required.

All that is left for this discussion is the backup script itself. If you are able to attend the

presentation at Open World, I will delve into incremental backup levels, some additional

considerations for recovery testing, and look at a handful of common errors; these errors, if

not forewarned, can derail the best intentions to get started with rman.

Rman Backup Script

And now, the fun begins. There are many ways to do this scripting, but this is what we

started with and have been most successful with implementing:1 #!/bin/ksh23 SCRIPT=1 ; export SCRIPT45 . ~oracle/.profile > /dev/null 2>&167 export ORACLE_SID=$18 export LEVEL=$29 export BACKUP_BASE=$3

10 export ARCH_BASE=$41112 export PATH=$ORACLE_HOME/bin:$PATH:/usr /sbin13 export TIMESTAMP=`date +'%Y%m%d'`14 export BACKUP_DIR=${BACKUP_BASE}/${ORACLE_SID}15 export ARCH_DIR=${ARCH_BASE}/${ORACLE_SID}16 export LOGFILE=${BACKUP_DIR}/rman-level${LEVEL}-${TIMESTAMP}.log1718 unset LD_PRELOAD19 unset TWO_TASK20 unset LD_LIBRARY_PATH2122 cd $HOME/working2324 $ORACLE_HOME/bin/sqlplus /

8/2/2019 Why_RMAN

8/9


______________________________________________________________________



32 delete noprompt expired archivelog all;33 run {34 allocate channel ch1 type disk format35 '${BACKUP_DIR}/%d_level${LEVEL}_${TIMESTAMP}_%s_U%U.bak';36 set limit channel ch1 kbytes=2000000;37 backup incremental level ${LEVEL} (database);38 sql 'alter system archive log current';39 copy current controlfile to

40 '${BACKUP_DIR}/${ORACLE_SID}_level${LEVEL}_${TIMESTAMP}_control01.bak';41 backup current controlfile for standby42 format '${BACKUP_DIR}/%d_SCF_%U.bak';43 release channel ch1;44 resync catalog;45 }46 EOF

Now, using the line numbers in the above, let's discuss some notable lines.Line Notes

1 The magic causing the script to run in the korn shell3 Used in a lot of cases by .profile to suppress screen I/O.

5 Keep the running of .profile "error-free" by suppressing stdout and stderr.7-10 Ingest command-line parameters and set some environment variables.12-16 Expand on some variables set by command-line parameters.18-20 We want these 3 unset (if running 9i or 10 g ) and LD _ LIBRARY _ PATH left alone if

running 8i .25 A stake in the ground, archive redo log-wise. This is the point in the redo stream

where the rman backup commences.28 Invoke rman using a catalog, sending output to the specified logfile, and accepting

inline commands until the subsequent EOF .29 Another log file switch, unlike the first, done inside rman.30 Checks for existence of archived redo logs in the instance-specified location. They

are marked AVAILABLE or EXPIRED depending on the success or failure of thecheck on disk for their existence.

31 Allocation of disk channel for the ensuing maintenance activity.32 Catalog records of archived redo logs that were found to be expired are wiped

from the rman repository.33 The start of the famous "run" block.

34-35 Channel allocation; would be type 'SBT _ TAPE ' with appropriate ENV parametersfor writing directly to tape. Notice how the channel is defined using some of theenvironment variables that were set in the script. The "%d", "%s", and "%U" areincluded, their meaning specific things to rman. They are used to help establishS/S file name uniqueness for each backup set piece.

36 Size of each backups et piece is set to 2000Mb.

37 The heart of the script, where the database is backed up to the appropriate device.38 The finish of backup log switch.

39-40 A manual backup of the control file. If controlfile autobackup is turned on, this isredundant, but hey ... in the backup world, nothing is redundant nothing isredundant nothing is redundant nothing is redundant.

41-42 Create a standby controlfile.

8/2/2019 Why_RMAN

9/9


______________________________________________________________________



44 A catalog resync is not required, but why not!.

Wrapup

The material presented in this paper can fast track your move to rman. We have discussed

instance creation, infrastruture setup, catalog instance backup, and presented a sample rman

backup script with discussion. Like most technies, once you get started, the complete

functionality of the rman product and the bells and whistles of an rman environment will

jump out at you and you will get deeper into the tool's functionality. The accompanying

PowerPoint presentation will discuss:

Incremental backup levels Controlfile autobackup Recovery testing

1. using the same ORACLE _ SID and the same directory structures2. using a different ORACLE _ SID with a different directory structure

Catalog cleanup Retention policies and their enforcement Cleanup on disk and tape Validating backups

Michael S. Abbey is a frequent presenter at technical events in North America and Europe. He has

accumulated an avid following in the Oracle user group community, having served on the board of directothe IOUG from 1992 until 2000. Michael was re-elected to the Board in the 2002 election process. Michais co-author of 13 successful works in the Oracle Press series, the most recent being "Oracle10/g/ Databa

A Beginner's Guide." In March 2005, Michael joined Ntirety LLC, an Oracle and SQL Server services company in Eastern Massachusetts. He is responsible for service delivery in the Oracle practice.

A

Why_RMAN

Documents

Transcript of Why_RMAN