Read Pro Oracle Database 11g Administration Online

Authors: Darl Kuhn

Tags: #Oracle DBA

Pro Oracle Database 11g Administration (72 page)

hardware (RAID disks, multiple controllers, and so on) to ensure high availability and recoverability.

Step 3: Determine Which Files Need to Be Backed Up

For this step, you only need to know the locations of the datafiles:

SQL> select name from v$datafile;

When you get to step 5, you may want to consider altering tablespaces one at a time into backup mode. If you take that approach, you need to know which datafiles are associated with which tablespace: select

tablespace_name

,file_name

from dba_data_files

order by 1,2;

Step 4: Note the Maximum Sequence Number of the Online-Redo Logs

To recover successfully using a hot backup, you require at minimum all the archive-redo logs that were generated during the backup. For this reason, you need to note the archivelog sequence before starting the hot backup:

431

CHAPTER 16 ■ USER-MANAGED BACKUP AND RECOVERY

select

thread#

,max(sequence#)

from v$log

group by thread#

order by thread#;

Step 5: Alter the Database/Tablespaces into Backup Mode

You can put all your tablespaces into backup mode at the same time using the ALTER DATABASE BEGIN

BACKUP statement:

SQL> alter database begin backup;

If it’s an active OLTP database, doing this can greatly degrade performance. This is because when a tablespace is in backup mode, Oracle copies a full image of any block (when it’s first modified) to the redo stream. This is discussed in detail later in the chapter.

The alternative is to alter only one tablespace at a time into backup mode. After the tablespace has been altered into backup mode, you can copy the associated datafiles (step 6) and then alter the tablespace out of backup mode (step 7). You have to do this for each tablespace: SQL> alter tablespace begin backup;

Step 6: Copy the Datafiles with an OS Utility

Use an OS utility (Linux/Unix cp command) to copy the datafiles to the backup location. In this example, all the datafiles are in one directory, and they’re all copied to the same backup directory: $ cp /ora01/dbfile/O11R2/*.dbf /oradump/hbackup/O11R2

Step 7: Alter the Database/Tablespaces Out of Backup Mode

After you’re finished copying all your datafiles to the backup directory, you need to alter the tablespaces out of backup mode. This example alters all tablespaces out of backup mode at the same time: SQL> alter database end backup;

If you’re altering your tablespaces into backup mode one at a time, you need to alter each tablespace out of backup mode after its datafiles have been copied:

SQL> alter tablespace end backup;

If you don’t take the tablespaces out of backup mode, you can seriously degrade performance and compromise the ability to recover your database.

432

CHAPTER 16 ■ USER-MANAGED BACKUP AND RECOVERY

Step 8: Archive the Current Online-Redo Log and Note the Maximum Sequence Number of the Online-Redo Logs

The following statement instructs Oracle to archive any unarchived online-redo logs and also to initiate a log switch. This ensures that an end-of-backup marker is written to the archive-redo logs: SQL> alter system archive log current;

Also note the maximum online-redo log sequence number. If a failure occurs immediately after the hot backup, you need any archive-redo logs generated during the hot backup to fully recover your database:

select

thread#

,max(sequence#)

from v$log

group by thread#

order by thread#;

Step 9: Back Up the Control File

For a hot backup, you can’t use an OS copy command to make a backup of control file. Oracle’s hot-backup procedure specifies that you must use the ALTER DATABASE BACKUP CONTROLFILE statement. This example makes a backup of the control file and places it in the same location as the database backup files:

SQL> alter database backup controlfile

to '/oradump/hbackup/O11R2/controlbk.ctl' reuse;

The REUSE clause instructs Oracle to overwrite the file if it already exists in the backup location.

Step 10: Back Up Any Archive-Redo Logs Generated During the Backup

Back up the archive-redo logs that were generated during the hot backup. You can back up the archive-redo logs with an OS copy command:

$ cp This guarantees that you have the logs in the event of a failure that occurs soon after the hot backup finishes. Be sure you don’t back up an archive-redo log that is currently being written to by the archiver process—doing so results in an incomplete copy of that file. Sometimes, DBAs script this process by checking the maximum SEQUENCE# with the maximum RESETLOGS_ID in the V$ARCHIVED_LOG view. Oracle updates that view when it’s finished copying the archive-redo log to disk. Therefore, any archive-redo log file that appears in the V$ARCHIVED_LOG view should be safe to copy.

433

CHAPTER 16 ■ USER-MANAGED BACKUP AND RECOVERY

Scripting Hot Backups

The script in this section covers the minimal tasks associated with a hot backup. For a production environment, a hot backup script can be quite complex. The script listed here provides you with a baseline of what you should include in a hot-backup script.

You need to modify these variables in the script for it to work in your environment:

• hbdir

• dbname

The SQL*Plus variable hbdir points to the base directory for the hot backups. The script also needs the dbname to be set to the Oracle system identifier (SID) of your database. The script copies files to a directory that is the concatenated string of the hbdir and dbname variables. For example, if you set hbdir to /oradump/hbackup and set dbname to O11R2, the backup files are copied to the /oradump/hbackup/O11R2

directory:

#!/bin/bash

# Either hardcode or source the OS variables via a script,

# see chapter 2 for more details on the oraset script.

. /var/opt/oracle/oraset $1

#

sqlplus -s <

/ as sysdba

set head off pages0 lines 132 verify off feed off trimsp on

define hbdir=/oradump/hbackup

define dbname=O11R2

spo hotback.sql

select 'spo &&hbdir/&&dbname/hotlog.txt' from dual;

select 'select max(sequence#) from v\$log;' from dual;

select 'alter database begin backup;' from dual;

select '!cp ' || name || ' ' || '&&hbdir/&&dbname' from v\$datafile; select 'alter database end backup;' from dual;

select 'alter database backup controlfile to ' || '''' || '&&hbdir' || '/'

|| '&&dbname' || '/controlbk.ctl' || '''' || ' reuse;' from dual; select 'alter system archive log current;' from dual;

select 'select max(sequence#) from v\$log;' from dual;

select 'select member from v\$logfile;' from dual;

select 'spo off;' from dual;

spo off;

@@hotback.sql

EOF

exit 0

The script generates a hotback.sql script. This script contains the commands to perform the hot backup. Here’s a listing of the hotback.sql script for a test database: spo /oradump/hbackup/O11R2/hotlog.txt

select max(sequence#) from v$log;

alter database begin backup;

!cp /ora01/dbfile/O11R2/system01.dbf /oradump/hbackup/O11R2

!cp /ora01/dbfile/O11R2/sysaux01.dbf /oradump/hbackup/O11R2

!cp /ora02/dbfile/O11R2/undotbs01.dbf /oradump/hbackup/O11R2

434

CHAPTER 16 ■ USER-MANAGED BACKUP AND RECOVERY

!cp /ora02/dbfile/O11R2/users01.dbf /oradump/hbackup/O11R2

!cp /ora01/dbfile/O11R2/appdata.dbf /oradump/hbackup/O11R2

!cp /ora01/dbfile/O11R2/inv_mgmt_data01.dbf /oradump/hbackup/O11R2

!cp /ora01/dbfile/O11R2/inv_mgmt_index01.dbf /oradump/hbackup/O11R2

!cp /ora01/dbfile/O11R2/mvdata01.dbf /oradump/hbackup/O11R2

!cp /ora01/dbfile/O11R2/mvindex01.dbf /oradump/hbackup/O11R2

alter database end backup;

alter database backup controlfile to '/oradump/hbackup/O11R2/controlbk.ctl' reuse; alter system archive log current;

select max(sequence#) from v$log;

select member from v$logfile;

spo off;

You can run this script manually from SQL*Plus like this:

SQL> @hotback.sql


Caution
If the previous script fails on a statement before ALTER DATABASE END BACKUP is executed, you must take your database (tablespaces) out of backup mode by manuallly running ALTER DATABASE END BACKUP as SYS

from SQL*Plus.

At the same time that you generate the hot-backup script, it’s prudent to generate a script that you can use to copy the datafiles from a backup directory. You have to modify the hbdir and dbname variables in this script to match your environment. Here’s a script that generates the copy commands:

#!/bin/bash

# source oracle OS variables

. /var/opt/oracle/oraset $1

#

sqlplus -s <

/ as sysdba

set head off pages0 lines 132 verify off feed off trimsp on

define hbdir=/oradump/hbackup

define dbname=O11R2

spo hotrest.sql

select '!cp ' || '&&hbdir' || substr(name,instr(name,'&&dbname')-1)

|| ' ' || name from v\$datafile;

spo off;

#

exit 0

Here’s a listing of the code you can execute from SQL*Plus to copy the datafiles back from the backup directory in the event of a failure:

!cp /oradump/hbackup/O11R2/system01.dbf /ora01/dbfile/O11R2/system01.dbf

!cp /oradump/hbackup/O11R2/sysaux01.dbf /ora01/dbfile/O11R2/sysaux01.dbf

!cp /oradump/hbackup/O11R2/undotbs01.dbf /ora02/dbfile/O11R2/undotbs01.dbf

!cp /oradump/hbackup/O11R2/users01.dbf /ora02/dbfile/O11R2/users01.dbf

!cp /oradump/hbackup/O11R2/appdata.dbf /ora01/dbfile/O11R2/appdata.dbf

!cp /oradump/hbackup/O11R2/inv_mgmt_data01.dbf \

435

CHAPTER 16 ■ USER-MANAGED BACKUP AND RECOVERY

/ora01/dbfile/O11R2/inv_mgmt_data01.dbf

!cp /oradump/hbackup/O11R2/inv_mgmt_index01.dbf \

/ora01/dbfile/O11R2/inv_mgmt_index01.dbf

!cp /oradump/hbackup/O11R2/mvdata01.dbf /ora01/dbfile/O11R2/mvdata01.dbf

!cp /oradump/hbackup/O11R2/mvindex01.dbf /ora01/dbfile/O11R2/mvindex01.dbf In this output, you can remove the ! character from each line if you prefer to run the commands from the OS prompt. The main idea is that these commands are available in the event of a failure so you know what files have been backed up to what location and how to copy them back. In the prior code listing, also notice that two lines have been wrapped with the \ character. This is to fit the output within the page width constraints of this book.


Tip
Don’t use user-managed hot-backup technology for online backups. Use RMAN for backups. RMAN doesn’t need to place tablespaces in backup mode and automates nearly everything related to B&R.

Understanding the Split-Block Issue

To perform a hot backup, one critical step is to alter a tablespace into backup mode before you copy any of the datafiles associated with the tablespace using an OS utility. To understand why you have to alter a tablespace into backup mode, you must be familiar with what is sometimes called the
split
(or
fractured
)
block issue
.

Recall that a database block is often a different size than the OS block. For example, a database block may be sized at 8KB, whereas the OS block size is 4KB. As part of the hot backup, you use an OS

utility to copy the live datafiles. While the OS utility is copying the datafile, the possibility exists that database writers are writing to a block at the same time the OS utility is copying the block. Because the Oracle block and the OS block are different sizes, the following may happen: 1.

The OS utility copies part of the Oracle block.

2.

A moment later, a database writer updates the entire block.

3.

A split second later, the OS utility copies the latter half of the Oracle block.

This can result in the OS copy of the block being inconsistent with what Oracle wrote to the OS.

Figure 16–1 illustrates this concept.

Looking at Figure 16–1, the block copied to disk at time 3 is corrupt as far as Oracle is concerned.

The first half of the block is from time 1, and the latter half of the block is copied at time 3. This is why you can’t copy datafiles in an open Oracle database to make a backup. When you make a hot backup, you’re guaranteeing block-level corruption in the backups of the datafiles.

To understand how Oracle resolves the split-block issue, first consider a database operating in its normal mode (not in backup mode). The redo information that is written to the online-redo logs is only what Oracle needs to reapply transactions. The redo stream doesn’t contain entire blocks of data. Oracle only records a change vector in the redo stream that specifies which block changed and how it was changed. Figure 16–2 shows Oracle under normal operations.

436

Other books

Shapeshifters by Amelia Atwater-Rhodes
Blue Moon by Linda Windsor
Diary of a Witness by Catherine Ryan Hyde
Heaven's Fall by David S. Goyer, Michael Cassutt
Claimed by Three by Rebecca Airies
London in Chains by Gillian Bradshaw
Borrowing Trouble by Stacy Finz
Steamed by Katie Macalister