Why Use
RMAN?
Most production database systems
impose stringent requirements on backup and recovery. As a DBA in charge of
backup and recovery, you must:
Before
getting into the configure command, let’s first take a look at our default
settings by using the show command:
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE
DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO
1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK
TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/u01/app/oracle/product/9.2.0/dbs/snapcf_TARGDB.f'; # default
From the above listing, you can see that the
RMAN allows you to set default values for some of the following:
·
The
default retention policy. This determines which backups and copies are eligible
for deletion because they are no longer needed.
·
Turning
ON and OFF backup optimization. Backup optimization eliminates duplicate
backups of identical datafiles (like those associated with a read-only
tablespace) and archived redo logs.
·
A
default device type for RMAN jobs, (disk
or tape [sbt])
·
The
default for automated backups of the control file to ON or OFF. You can also
control the default format of the control file backup output files and the
default device on which to create these backups.
·
The
number of channels (for parallelization) that are automatically allocated when
performing automated backup and recovery/restore jobs.
·
A
tablespace exclusion policy to configure specific tablespaces to be excluded
during full database backup operations. If there are no tablespace exclusion
policies defined, nothing will be displayed by the show all command.
·
The
maximum size for any given backup piece and the size of any backup set when
performing automated backups.
·
The
default filename for the snapshot controlfile.
Backup
Archive Logs (All)
·
In
the following example, I provide an RMAN command to backup all archive logs and
to delete the archive redo log files from their archive destination (on disk)
when the backup it complete.
RMAN> backup archivelog all delete input;
RETENTION
POLICY
Used to control how
long RMAN will keep backups. This can be configured by the "number"
of backups taken, or by the numbers of "days" to keep. Here is an
example of both:
CONFIGURE RETENTION POLICY TO RECOVERY
WINDOW OF 3 DAYS;
Note that when configuring a retention policy, RMAN will not cause backups to be automatically
deleted. The retention policy will, however, mark backups as OBSOLETE that have
fallen outside the retention period. RMAN commands like "REPORT OBSOLETE" and "DELETE
OBSOLETE" will work with these obsolete backups.
BACKUP
OPTIMIZATION
·
Used
to enable or disable backup optimization. Backup file optimization can assist
in reducing the space used to backup the database. When performing an RMAN
backup, a check is done on the file before backup to see if the file already
exists in a backupset with the same information: (dbid, checkpoint, and
resetlogs data).
·
For
archive logs, the same file means the same dbid, thread, sequence, and
resetlogs data. If the DELETE INPUT option is used, RMAN deletes all the files
that would have been backed up, even when the file is not included due to file
optimization.
·
The
two possible values for backup optimization is ON and OFF as shown in the
following example syntax:
·
CONFIGURE
BACKUP OPTIMIZATION ON;
To do a full backup:
backup as compressed backupset database plus
archivelog delete all input tag = '${tag};
To determine if more than 50% of your data has changed
during incremental backups:
select file# incremental_level,
completion_time, blocks, datafile_blocks from v$backup_datafile
where incremental_level > 0 and
blocks/datafile_blocks > .5 order by completion_time
To backup a database incrementally:
backup incremental level # database tag =
'${tag}';
To see how much space is used and what's using it in the
flash recovery area:
SQL> select * from
v$flash_recovery_area_usage;
FILE_TYPE
PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------
------------------------- ---------------
CONTROLFILE 0 0 0
ONLINELOG 0 0 0
ARCHIVELOG .22 0 1
BACKUPPIECE 8.45 0 22
IMAGECOPY 0 0 0
FLASHBACKLOG 0 0 0
To see how much space is used/reclaimable in the flash
recovery area:
SQL> select * from v$recovery_file_dest;
NAME SPACE_LIMIT
SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
------------------------------ -----------
---------- ----------------- ---------------
/oracle/flash_recovery_area 2.1475E+10 1861050368 0 23
To enable
alter database enable block change
tracking;
or
alter database enable block change tracking
using file '${file}' reuse;
The reuse tells the system to overwrite any file that's
there.
To determine if block change tracking is on:
SQL> select status from
v$block_change_tracking;
STATUS
----------
DISABLED
to enable block change tracking:
SQL> alter database enable block change
tracking using file '/oracle/oradata/oci1/rman_bct.tab' reuse;
To ID the file being used for block change tracking:
SQL> select filename from
v$block_change_tracking;
FILENAME
-----------------------------------------------------------------------------------------------
/oracle/oradata/oci1/rman_bct.tab
RMAN Backup Formats: Image Copies and Backup Sets
RMAN backups can be stored
in one of two formats:
- Image
Copy
- Backup
Set
Image Copies
An image copy is an exact
copy of a single datafile, archived redo log file, or control file. Image
copies are not stored in an RMAN-specific format. They are identical to the results
of copying a file with the UNIX cp command. This is the same
as a Cold Backup.
Backup Sets
A backup set is a
collection of files (called backup pieces) each of which contain
the backup to one or more database files. A backup set contains the data from
one or more datafiles or archived redo logs, or control files or spfile.
Datafiles and archivelogs cannot be mixed together in the same backup set.
Binary Compression of Backup Sets
You can use binary
compression to reduce the size of your backup sets. The compression algorithm
built into the Oracle server is tuned specifically for efficient compression of
Oracle archived logs and datafiles, and will generally yield better compression
than general-purpose compression utilities not tuned for Oracle database files.
Restoring Default
Values for Configured Settings
--
-- Reset any CONFIGURE setting to its default by running
the command with the CLEAR option
--
RMAN> configure retention policy clear;
RMAN> configure controlfile autobackup format for
device type disk clear;
Viewing Current
Settings
RMAN> show all;
SQL> COLUMN
name FORMAT a20 wrap
COLUMN value FORMAT a65
SELECT name, value FROM v$rman_configuration;
Backing up
Database Files
Use the BACKUP AS COPY to make image
copies of the database files (a.k.a. cold backup).
Use the BACKUP AS BACKUPSET to backup up files
into backup sets. A backup set consists of one or more backup
pieces, physical files containing the data. A backup set usually contains only
one backup piece. Only RMAN can create and restore backup sets. You will
usually configure the persistent settings in advance of
the BACKUP command.
--
-- make an image copy (cold backup) of a database
--
RMAN> backup as copy database;
--
-- backup a database and archived logs to disk; in backup
set format
--
RMAN> backup as backupset device type disk database
plus archivelog;
Incremental
Backups
If you specify BACKUP INCREMENTAL, RMAN will create
incremental backups of your database. Incremental backups capture on a
block-by-block basis changes in your database since a previous incremental
backup. The starting point for an incremental backup strategy is a level 0
incremental backup, which backs up all blocks in the database. Level 1
incremental backups, taken at regular intervals, contain only changed blocks
since a previous incremental backup. These can be cumulative (including all
blocks changed since the most recent level 0 backup) or differential (including
only blocks changed since the most recent incremental backup, whether it is
level 0 or level 1).
During a restore from incremental backup, the level 0
backup is used as the starting point, then changed blocks are updated based on
level 1 backups where possible to avoid re-applying changes from redo one at a
time. If incremental backups are available, RMAN will use them during recovery.
Validating Backups
Validation confirms that a backup could be run, by
confirming that all database files exist, are in their correct location, and
are free of physical and logical corruption:
RMAN> backup validate database archivelog all;
Recovering a
Database
Use the RESTORE DATABASE and RECOVER
DATABASE commands on the whole database.
RMAN> startup force mount;
RMAN> restore database;
RMAN> recover database;
RMAN> alter database open;
The database must not be open when restoring or
recovering the entire database.
Recovering
Individual Data Blocks
RMAN can recover individual corrupted datafile blocks.
When RMAN performs a complete scan of a file for a backup, any corrupted blocks
are listed in V$DATABASE_BLOCK_CORRUPTION. Corruption can be reported in alert
logs, trace files or results of SQL queries.
--
-- repair all corrupted blocks
--
RMAN> blockrecover corruption list;
--
-- recover individual blocks
--
RMAN> blockrecover datafile datafile# block block#;
Validating
Restores
You can run a RESTORE VALIDATE operation to
confirm that a restore operation can be performed successfully. RMAN decides
which backup sets, datafile copies, and archived logs are needed for the
operation, and scans them to verify that they are usable.
--
-- confirm the recovery of a database
--
RMAN> restore database validate;
Lists and Reports
RMAN has extensive listing and reporting functionality
allowing you to monitor you backups and maintain the recovery catalog:
--
-- Show copy information for all image copies
--
RMAN> list copy;
--
-- Show backup information for all backup pieces
--
RMAN> list backup;
--
-- Show all backup details for backup sets
--
RMAN> list backup of database;
RMAN> list copy of datafile 1, 2, 3;
--
-- which files need backing up under current retention
policy
--
RMAN> report need backup database;
--
-- list all datafiles for which an unrecoverable
operation has been performed
-- against an object in the datafile since the last
backup of the datafile.
--
RMAN> report unrecoverable;
--
-- Show items that beed 7 days worth of
-- archivelogs to recover completely
--
RMAN> report need backup days = 7 database;
--
-- Show/Delete items not needed for recovery
--
RMAN> report obsolete;
RMAN> delete obsolete;
--
-- Show/Delete items not needed for point-in-time
-- recovery within the last week
--
RMAN> report obsolete recovery window of 7 days;
RMAN> delete obsolete recovery window of 7 days;
--
-- Show/Delete items with more than 2 newer copies
available
--
RMAN> report obsolete redundancy = 2 device type disk;
RMAN> delete obsolete redundancy = 2 device type disk;
--
-- Show datafiles that connot currently be recovered
--
RMAN> report unrecoverable database;
RMAN> report unrecoverable tablespace USERS;
Monitoring RMAN through V$ views
Status information
for jobs in progress and completed jobs is stored in V$RMAN_STATUS.
V$RMAN_OUTPUT contains the text ouptut of all RMAN jobs.
--
-- display status information on running RMAN job
--
SQL>
SELECT operation
,
status
,
mbytes_processed
,
start_time
,
end_time
FROM v$rman_status
/
--
-- To calculate the progress of an RMAN job,
-- run the following query in SQL*Plus while the RMAN job
is executing
--
SQL>
SELECT sid
,
serial#
,
context
,
sofar
,
totalwork
,
ROUND(sofar/totalwork*100,2) "% Complete"
FROM v$session_longops
WHERE opname like 'rman%'
AND opname NOT LIKE '%aggregate%'
AND totalwork != 0
AND sofar <> totalwork
/
Managing the RMAN
Repository
RMAN repository metadata is always stored in the control
file of the target database. You can also create a recovery catalog in a
separate database, and RMAN will record its metadata there as well.
Monitoring Control File Records
If you do not use a recovery catalog, you must
pre-determined how log the control file will keep RMAN information.
The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter will set
how long records RMAN control file records are kept.
--
-- init.ora parameter
--
control_file_record_keep_time = number_of_days_to_keep
Crosschecking
Backups
The CROSSCHECK command checks whether RMAN
backups and copies in the repository can still be accessed.
Use the
CROSSCHECK command
to synchronize the physical reality of backups and copies with their logical
records in the RMAN repository.
--
-- checks RMAN backups on configured devices
--
RMAN> crosscheck backup;
Deleting Backups and Copies
The DELETE command removes RMAN backups and
copies from disk and tape devices, marks the objects as DELETED in the control
file, and removes the records from the recovery catalog (if you use a catalog).
RMAN> delete backupset 101, 102, 103;
RMAN> delete noprompt archivelog until sequence =
7300;
RMAN> delete backup of spfile tablespace USERS device
type disk;
RMAN> delete archivelog all backed up 2 times to
device type disk;
--
-- delete backups marked as EXPIRED ("not
found" by the CROSSCHECK command)
--
RMAN> delete expired;
--
-- delete backups that are obsolete under the retention
policy
--
RMAN> delete noprompt obsolete;
RMAN and Scripting
RMAN supports the use of stored scripts and command
files. A command file is a client-side text file containing RMAN
commands, exactly as you enter them at the RMAN prompt.
--
-- execute the contents of a command file using the RMAN
@ command
--
RMAN> @/directory/command_file.txt
--
-- launch RMAN
with a command file to run
--
% rman @/directory/command_file.txt
Any file extension may be used.
Creating a
Recovery Catalog
Allocating Disk Space for the Recovery Catalog Database
|
Type of Space
|
Space Requirement
|
|
SYSTEM tablespace
|
400 MB
|
|
Temp tablespace
|
16 MB
|
|
Rollback or undo tablespace
|
16 MB
|
|
Recovery catalog tablespace
|
16 MB for each database registered in the recovery
catalog
|
|
Online redo logs
|
4 MB each (3 groups, each with 2 members)
|
Typical Recovery Catalog Space Requirements for 1 Year
Create the Recovery Catalog Schema in the Recovery
Catalog Database
% sqlplus sys/password as sysdba@catalogDB
SQL>
create tablespace RECOVERY
datafile
'/fsysx/ORACLE/SID/recovery01.dbf' SIZE 100M REUSE
extent management
local
/
--
-- create the RMAN schema
--
create user rman identified by password;
alter user rman
temporary
tablespace TEMP
default
tablespace RECOVERY
quota unlimited
on RECOVERY
/
grant create session to rman
/
--
-- grant rman the recovery_catalog_owner role.
--
grant recovery_catalog_owner to rman
/
Create the Recovery Catalog
--
-- create the catalog
--
% rman catalog rman/password@rmanSID
RMAN> create CATALOG tablespace rman_tablespace;
Register a Database
Each database to be backed up by RMAN must be registered:
--
-- register the database in the recovery catalog
--
% rman TARGET sys/password@targetSID CATALOG
rmanuser/password@rmanSID
RMAN> register database;
--
-- verify that the registration was successful
--
RMAN> report schema;
Registering Multiple Databases in a Recovery Catalog
You can register multiple target databases in a single
recovery catalog, if they do not have duplicate DBIDs. RMAN uses the DBID to
distinguish one database from another.
The following table provides a functional
summary of RMAN recovery catalog views.
|
Corresponding V$ View
|
Catalog View Describes ...
|
|
|
Archived and unarchived redo logs
|
||
|
Details about archived redo log
backups for Enterprise Manager
|
||
|
Summary of information about
archived redo log backups for Enterprise Manager
|
||
|
Control files backed up in backup
sets
|
||
|
Details about control file
backups for Enterprise Manager
|
||
|
Summary of information about
control file backups for Enterprise Manager
|
||
|
Details about datafile image copy
backups for Enterprise Manager
|
||
|
Summary of information about
datafile image copy backups for Enterprise Manager
|
||
|
Corrupt block ranges in datafile
backups
|
||
|
Datafiles in backup sets
|
||
|
Details about datafile backups
for Enterprise Manager
|
||
|
Summary of information about
datafile backups for Enterprise Manager
|
||
|
RMAN backups and copies known to
the repository.
|
||
|
Backup pieces
|
||
|
Details about backup pieces for
Enterprise Manager
|
||
|
Archived redo logs in backup sets
|
||
|
Backup sets for all incarnations
of databases registered in the catalog
|
||
|
Details about backup sets for
Enterprise Manager
|
||
|
Summary of information about
backup sets for Enterprise Manager
|
||
|
Server parameter files in backups
|
||
|
Details about server parameter
file backups for Enterprise Manager
|
||
|
Summary of information about
server parameter file backups for Enterprise Manager
|
||
|
n/a
|
Deprecated in favor ofRC_RESYNC
|
|
|
Control file copies on disk
|
||
|
Corrupt block ranges in datafile
copies
|
||
|
Databases registered in the
recovery catalog
|
||
|
Database blocks marked as
corrupted in the most recent RMAN backup or copy
|
||
|
Database incarnations registered
in the recovery catalog
|
||
|
Datafiles registered in the recovery
catalog
|
||
|
Datafile copies on disk
|
||
|
Online redo log history
indicating when log switches occurred
|
||
|
Offline ranges for datafiles
|
||
|
Archived log backups taken with
the proxy copy functionality
|
||
|
Details about proxy archived redo
logs for Enterprise Manager
|
||
|
Summary of information about
proxy archived redo logs for Enterprise Manager
|
||
|
Control file backups taken with
the proxy copy functionality
|
||
|
Details about datafile proxy
copies for Enterprise Manager
|
||
|
Summary of information about
datafile proxy copies for Enterprise Manager
|
||
|
Datafile backups that were taken
using the proxy copy functionality
|
||
|
Online redo logs for all
incarnations of the database since the last catalog resynchronization
|
||
|
All redo threads for all
incarnations of the database since the last catalog resynchronization
|
||
|
All restore points for all
incarnations of the database since the last catalog resynchronization
|
||
|
n/a
|
Recovery catalog
resynchronizations
|
|
|
Details about backup jobs for
Enterprise Manager
|
||
|
Details about backup subjobs for
Enterprise Manager
|
||
|
Used internally by Enterprise
Manager
|
||
|
RMAN configuration settings
|
||
|
Output from RMAN commands for use
in Enterprise Manager
|
||
|
Historical status information
about RMAN operations.
|
||
|
n/a
|
Databases in a Data Guard
environment
|
|
|
n/a
|
Names of scripts stored in the
recovery catalog
|
|
|
n/a
|
Contents of the scripts stored in
the recovery catalog
|
|
|
All tablespaces registered in the
recovery catalog, all dropped tablespaces, and tablespaces that belong to old
incarnations
|
||
|
All tempfiles registered in the
recovery catalog
|
||
|
Unusable backup files registered
in the recovery catalog
|
When Duplicating a
database from A Raw Backup
RMAN> SET NEWNAME FOR DATAFILE
'?/oradata/trgt/tools01.dbf' TO '/tmp/tools01.dbf';
RMAN> RESTORE DATAFILE '?/oradata/trgt/tools01.dbf';
Resynchronizing the
Recovery Catalog
When RMAN performs a resynchronization, it compares the
recovery catalog to either the current control file of the target database or a
backup control file and updates the recovery catalog with information that is
missing or changed. When resynchronizing, RMAN does the following:
1.
Creates a snapshot control file.
2.
Compares the recovery catalog to the snapshot
control file.
3.
Updates the recovery catalog with missing or
changed information.
RMAN performs resynchronizations automatically as needed
when you execute certain commands, including BACKUP. You can also manually
perform a full resynchronization using the RESYNC CATALOG command.
Three types of resynchronization are possible in RMAN:
1. Full
resynchronization
2. Partial resynchronization
3. Reverse
resynchronization
No comments:
Post a Comment