RMAN backup job statistics:

col STATUS format a9
col hrs format 999.99
col TIME_TAKEN_DISPLAY format a10
col INPUT_BYTES_PER_SEC_DISPLAY format a10
col OUTPUT_BYTES_PER_SEC_DISPLAY format a10
select
SESSION_KEY, INPUT_TYPE, STATUS,
to_char(START_TIME,’mm/dd/yy hh24:mi’) start_time,
to_char(END_TIME,’mm/dd/yy hh24:mi’) end_time,
ELAPSED_SECONDS,
elapsed_seconds/3600 hrs,
TIME_TAKEN_DISPLAY,
COMPRESSION_RATIO,
INPUT_BYTES_PER_SEC_DISPLAY,
OUTPUT_BYTES_PER_SEC_DISPLAY
from V$RMAN_BACKUP_JOB_DETAILS
order by session_key;

Advertisements

11g RMAN: Archive log deletion policy

RMAN> configure archivelog deletion policy to backed up 2 times to sbt;

new RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO ‘SBT_TAPE’;
new RMAN configuration parameters are successfully stored
RMAN>

The preceding configure command specifies that once an archived redo log has been backed up twice to tape, it’s eligible for deletion from all archived redo log locations, including the flash recovery area. The configuration of an archived redo log deletion policy is a new feature introduced in the Oracle Database 11g release.

11g RMAN Compression algorithms

When using the RMAN compression feature, you can choose among different compression algorithms. You can query the view V$RMAN_COMPRESSION_ALGORITHM to view the compression algorithms available to you:

SQL> select algorithm_name,algorithm_description, is_default from v$rman_compression_algorithm;
ALGORITHM ALGORITHM DESCRIPTION IS_DEFAULT
—————————————————————- —
ZLIB fast but little worse compression ratio YES
BZIP2 good compression ratio but little slower NO

As the query shows, the ZLIB compression algorithm offers speed but not a good compression ratio. The alternate compression algorithm, BZIP2, is slower but provides a better compression ratio. You can use the show command to check the current compression algorithm in use:

RMAN> show compression algorithm;
RMAN configuration parameters are:
CONFIGURE COMPRESSION ALGORITHM ‘ZLIB’; # default
RMAN>
■Note If you set the compatible initialization parameter to 11.1 or newer, ZLIB will be the default compression algorithm. You can’t choose the compression algorithm if you set the compatible parameter to anything older than 11.0.

Remember that the choice of the compression algorithm is available only in Oracle Database 11g. In earlier versions of the database, you only have a single choice—the default algorithm BZIP2.

RMAN – When do you require DBID for database recovery

dbid integer  

specifies the db identifier, which is a unique 32-bit identification number computed when the database is created. The DBID column of the V$DATABASE data dictionary view displays the identifier. The DBID is also stored in the DB table of the recovery catalog.

The set dbid command is useful for restoring the control file when each of these conditions is met:

  • The control file has been lost and must be restored from a backup.

  • You are using a recovery catalog.

  • Multiple databases registered in the recovery catalog share a database name.

  • You receive the “RMAN-20005: target database name is ambiguous” message when you attempt to restore the control file.

If these conditions are not met, RMAN will correctly identify the control file to restore, so you do not need to use the set dbid command.

RMAN accepts set dbid only if you have not yet connected to the target database, i.e., set dbid must precede the connect target command. If the target database is mounted, then RMAN verifies that the user-specified DBID matches the DBID from the database; it not, RMAN signals an error. If the target database is not mounted, RMAN uses the user-specified DBID to restore the control file. Once you have restored the control file, you can mount the database to restore the rest of the database.

Do you need to put tablespaces hot backup mode when using RMAN

To understand why RMAN does not require extra logging or backup mode, you must first understand why those features are required for non-RMAN online backups.

A non-RMAN online backup consists of a non-Oracle tool, such as cp or dd, backing up a datafile at the same time that DBWR is updating the file. Oracle can’t prevent the tool from reading a particular block at the exact same time that DBWR is updating that block. When that happens, the non-Oracle tool might read a block in a half-updated state, so that the block which is copied to the backup media might only have been updated in its first half, while the second half contains older data. This is called a “fractured block”. If this backup needs to be restored later, and that block needs to be recovered, recovery will fail because that block is not usable.

The ‘alter tablespace begin backup’ command is oracle solution for the fractured block problem. When a tablespace is in backup mode, and a change is made to a data block, instead of logging just the changed bytes to the redo log, oracle also log a copy of the entire block image before the change, so that it can reconstruct this block if media recovery finds that this block was fractured. That block image logging is what causes extra redo to be generated while files are in backup mode.

The reason that RMAN does not require extra logging is that it guarantees that it will never back up a fractured block. it can make that guarantee because we know the format of Oracle data blocks, and it verify that each block that it read is complete before it copy it to the backup. If it read a fractured block, it will read the block again to obtain a complete block before backing it up. non-Oracle tools are not able to do the same thing because they do not know how to verify the contents of an Oracle data block.

Backup mode has another effect, which is to ‘freeze’ the checkpoint in the header of the file until the file is removed from backup mode. Oracle does this because it cannot guarantee that the third-party backup tool will copy the file header prior to copying the data blocks. RMAN does not need to freeze the file header checkpoint because it knows the order in which it will read the blocks, which enables it to capture a known good checkpoint for the file.

ORA-27054: NFS file system where the file is created or resides is not mounted with correct options

NFS Mount Options

You must mount NFS volumes used for storing database files with special mount options on the host where the database server is running. When mounting an NFS file system, Oracle recommends that you use the same mount point options that your NAS vendor used when certifying the device. Refer to your device documentation or contact your vendor for information about recommended mount-point options.

In general, most vendors recommend that you use the NFS mount options listed in the following table.

Option Requirement Description
hard Mandatory Generate a hard mount of the NFS file system. If the connection to the server fails or is temporarily lost, connection attempts are made until the NAS device responds.
bg Optional Try to connect in the background if connection fails.
tcp Optional Use the TCP protocol rather than UDP. TCP is more reliable than UDP.
nfsvers=3 Optional Use NFS version 3. Oracle recommends that you use NFS version 3 where available, unless the performance of version 2 is higher.
suid Optional Allow clients to run executables with SUID enabled. This option is required for Oracle software mount points.
rsize Mandatory The number of bytes used when reading from the NAS device. This value should be set to the maximum database block size supported by this platform. A value of 8192 is often recommended for NFS version 2 and 32768 is often recommended for NFS version 3.
wsize Mandatory The number of bytes used when writing to the NAS device. This value should be set to the maximum database block size supported by this platform. A value of 8192 is often recommended for NFS version 2 and 32768 is often recommended for NFS version 3.
nointr (or intr) Optional Do not allow (or allow) keyboard interrupts to kill a process that is hung while waiting for a response on a hard-mounted file system.

Note: Different vendors have different recommendations about this option. Contact your vendor for advice.

actime=0 or noac Mandatory Disable attribute caching.

Note: You must specify this option for NFS file systems where you want to install the software. If you do not use this option, Oracle Universal Installer will not install the software in the directory that you specify.

The mandatory mount options comprise the minimum set of mount options that you must use while mounting the NFS volumes. These mount options are essential to protect the integrity of the data and to prevent any database corruption. Failure to use these mount options may result in the generation of file access errors. Refer to your operating system or NAS device documentation for more information about the specific options supported on your platform.

For AIX:
cio,rw,bg,hard,nointr,rsize=32768,wsize=32768,proto=tcp,noac,vers=3,timeo=600

For HP-UX:
forcedirectio,rw,bg,hard,nointr,rsize=32768,wsize=32768,proto=tcp,noac,vers=3,timeo=600,suid

Restoring Rman backup on a different node with different backup directory structures and different database directory structures .

Oracle Server – Enterprise Edition – Version: 10.1.0.2 to 11.1.0.8
Information in this document applies to any platform.
Goal

++ Rman backup of database is done on NODE 1.
++ The database has to be has to be restored from the Rman backup on NODE 2.
++ The directory structures for the backups and the database files are different on NODE 2.
++ The Rman backups have to put in new directory structure on NODE 2 unlike as they were on NODE 1.
++ Also the database has to be restored to a different directory structure on NODE 2.
Solution

ASSUMPTIONS
———————–
++ The backups on NODE 1 are done to ‘/node1/database/backup’
++ The database files on NODE 1 are in ‘/node1/database/prod’
++ The backups on NODE 2 will be in location ‘/node2/database/backup’
++ The database files on NODE 2 will be restored to ‘/node2/database/prod

Steps to acheive the goal:

1) Connect to the target database using rman and backup the database —> ON NODE 1
$ rman target /

Recovery Manager: Release 10.2.0.1.0 – Production on Tue Feb 13 00:29:33 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: ORA10G (DBID=3932056136)

RMAN> backup database plus archivelog;

Starting backup at 13-FEB-07
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=143 recid=109 stamp=614392105
channel ORA_DISK_1: starting piece 1 at 13-FEB-07
channel ORA_DISK_1: finished piece 1 at 13-FEB-07
piece handle=/node1/database/backup/o1_mf_annnn_TAG20070213T002825_2x21kbds
_.bkp tag=TAG20070213T002825 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 13-FEB-07

Starting backup at 13-FEB-07
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00003 name=/node1/database/prod/sysaux01.dbf
input datafile fno=00001 name=/node1/database/prod/system01.dbf
input datafile fno=00002 name=/node1/database/prod/undotbs01.dbf
input datafile fno=00004 name=/node1/database/prod/users01.dbf
input datafile fno=00005 name=/node1/database/prod/1.dbf
input datafile fno=00006 name=/node1/database/prod/sysaux02.dbf
input datafile fno=00007 name=/node1/database/prod/undotbs02.dbf
channel ORA_DISK_1: starting piece 1 at 13-FEB-07
channel ORA_DISK_1: finished piece 1 at 13-FEB-07
piece handle=/node1/database/backup/o1_mf_nnndf_TAG20070213T002827_2x21kd12
_.bkp tag=TAG20070213T002827 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:55
Finished backup at 13-FEB-07

Starting backup at 13-FEB-07
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=144 recid=110 stamp=614392165
channel ORA_DISK_1: starting piece 1 at 13-FEB-07
channel ORA_DISK_1: finished piece 1 at 13-FEB-07
piece handle=/node1/database/backup/o1_mf_annnn_TAG20070213T002925_2x21m6ty
_.bkp tag=TAG20070213T002925 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 13-FEB-07

Starting Control File and SPFILE Autobackup at 13-FEB-07
piece handle=/u01/oracle/product/ora10g/dbs/c-3932056136-20070213-02 comment=NONE
Finished Control File and SPFILE Autobackup at 13-FEB-07

RMAN> exit

2) Move the following files to the NODE 2:

+ The database backup pieces to location ‘/node2/database/backup’
+ Controlfile backup piece to the location ‘/node2/database/backup’
+ The parameter file i.e init.ora file to the default location i.e $ORACLE_HOME/dbs

3) Edit the PFILE on NODE 2 to change the environment specific parameters like .
user_dump_dest =
background_dump_dest =
control_files =

4) Once the PFILE is suitably modified invoke Rman on the NODE 2 after setting the Oracle environment variables and start the database in nomount mode:

[oracle@test-br test]$ export ORACLE_HOME=/u01/oracle/product/ora10g
[oracle@test-br test]$ export ORACLE_SID=ora10g
[oracle@test-br test]$ export PATH=$ORACLE_HOME/bin:$PATH
[oracle@test-br test]$ rman target /
Recovery Manager: Release 10.2.0.1.0 – Production on Tue Feb 13 00:36:55 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database (not started)
RMAN> startup nomount
Oracle instance started
Total System Global Area 205520896 bytes
Fixed Size 1218508 bytes
Variable Size 75499572 bytes
Database Buffers 121634816 bytes
Redo Buffers 7168000 bytes

5) Restore the controlfile from the backup piece.
RMAN> restore controlfile from ‘/node2/database/backup/c-3932056136-20070213-02’;
Starting restore at 13-FEB-07
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete,
elapsed time: 00:00:02
output filename=/node2/database/prod/control01.ctl
Finished restore at 13-FEB-07

6) Mount the database
RMAN > alter database mount

7) Now catalog the backup pieces that were shipped from NODE 1

RMAN> catalog backuppiece ‘/node2/database/backup/o1_mf_annnn_TAG20070213T002925_2x21m6ty_.bkp’;

RMAN> catalog backuppiece ‘/node2/database/backup/o1_mf_annnn_TAG20070213T002825_2x21kbds_.bkp’;

RMAN> catalog backuppiece ‘/node2/database/backup/o1_mf_nnndf_TAG20070213T002827_2x21kd12_.bkp’;

This feature of cataloging backup pieces is available from ORACLE 10g versions. Prior to Oracle 10g we were not able to catalog the backup pieces. For more information on cataloging options refer the metalink note 470463.1

8) Get to know the last sequence available in the archivelog backup using the following command.This will help us in recovering the database till that archivelog.

RMAN > list backup of archivelog all;

Let us assume the last sequence of last archivelog in the backup is 50.

9) Rename the Redologfiles,so that they can be created in new locations when opened the database is opened in resetlogs

SQL> alter database rename file ‘/node1/database/prod/redo01.log’ to ‘/node2/database/prod/redo01.log’;
……
……
……

10) Now restore the datafiles to new locations and recover. Since we are recovering the database here till the archivelog sequence 50 the sequence number in the SET UNTIL SEQUENCE clause should be 50 (+1)

RMAN> run
{
set until sequence 51;
set newname for datafile 1 to ‘/node2/database/prod/sys01.dbf’;
set newname for datafile 2 to ‘/node2/database/prod/undotbs01.dbf’;
set newname for datafile 3 to ‘/node2/database/prod/sysaux01.dbf’;
set newname for datafile 4 to ‘/node2/database/prod/users01.dbf’;
set newname for datafile 5 to ‘/node2/database/prod/1.dbf’;
set newname for datafile 6 to ‘/node2/database/prod/sysaux02.dbf’;
set newname for datafile 7 to ‘/node2/database/prod/undotbs02.dbf’;
restore database;
switch datafile all;
recover database;
alter database open resetlogs;
}