Beruflich Dokumente
Kultur Dokumente
Recovery manager is a platform independent utility for coordinating your backup and restoration procedures across multiple servers. In my opinion it's value is limited if you only have one or two instances, but it comes into it's own where large numbers of instances on multiple platforms are used. The reporting features alone mean that you should never find yourself in a position where your data is in danger due to failed backups. The functionality of RMAN is too diverse to be covered in this article so I shall focus on the basic backup and recovery functionality. Create Recovery Catalog Register Database Full Backup Restore & Recover The Whole Database Restore & Recover A Subset Of The Database Incomplete Recovery Disaster Recovery Lists And Reports
Register Database
Each database to be backed up by RMAN must be registered: C:>rman catalog=rman/rman@w2k1 target=sys/password@w2k2 Recovery Manager: Release 9.2.0.1.0 - Production Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
connected to target database: W2K2 (DBID=1371963417) connected to recovery catalog database RMAN> register database; database registered in recovery catalog starting full resync of recovery catalog full resync complete RMAN> Existing user-created backups can be added to the catalog using: RMAN> catalog datafilecopy 'C:\Oracle\Oradata\TSH1.dbf'; RMAN> catalog archivelog 'log1', 'log2', 'log3', ... 'logN';
Full Backup
First we configure several persistant parameters for this instance: RMAN> configure retention policy to recovery window of 7 days; RMAN> configure default device type to disk; RMAN> configure controlfile autobackup on; RMAN> configure channel device type disk format 'C:\Oracle\Admin\W2K2\Backup%d_DB_%u_%s_%p'; Next we perform a complete database backup using a single command: RMAN> run { 2> backup database plus archivelog; 3> delete noprompt obsolete; 4> } The recovery catalog should be resyncronized on a regular basis so that changes to the database structure and presence of new archive logs is recorded. Some commands perform partial and full resyncs implicitly, but if you are in doubt you can perform a full resync using the follwoing command: RMAN> resync catalog;
} This will result in all datafiles being restored then recovered. RMAN will apply archive logs as necessary until the recovery is complete. At that point the database is opened. If the tempfiles are still present you can issue a command like like the following for each of them: sql "ALTER TABLESPACE temp ADD TEMPFILE ''C:\Oracle\oradata\W2K2\temp01.dbf'' REUSE"; If the tempfiles are missing they must be recreated as follows: sql "ALTER TABLESPACE temp ADD TEMPFILE ''C:\Oracle\oradata\W2K2\temp01.dbf'' SIZE 100M AUTOEXTEND ON NEXT 64K";
Incomplete Recovery
As you would expect, RMAN allows incomplete recovery to a specified time, SCN or sequence number: run { shutdown immediate; startup mount; set until time 'Nov 15 2000 09:00:00'; # set until scn 1000; # alternatively, you can specify SCN # set until sequence 9923; # alternatively, you can specify log sequence number restore database; recover database; alter database open resetlogs; } The incomplete recovery requires the database to be opened using the RESETLOGS option.
Disaster Recovery
In a disaster situation where all files are lost you can only recover to the last SCN in the archived redo logs. Beyond this point the recovery would have to make reference to the online redo logs which are not present. Disaster recovery is therefore a type of incomplete recovery. To perform disaster recovery connect to RMAN: C:>rman catalog=rman/rman@w2k1 target=sys/password@w2k2 Once in RMAN do the following: startup nomount;
restore controlfile; alter database mount; From SQL*Plus as SYS get the last archived SCN using: SQL> SELECT archivelog_change#-1 FROM v$database; ARCHIVELOG_CHANGE#-1 -------------------1048438 1 row selected. SQL> Back in RMAN do the following: run { set until scn 1048438; restore database; recover database; alter database open resetlogs; } If the "until scn" were not set the following type of error would be produced once a redo log was referenced: RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 03/18/2003 09:33:19 RMAN-06045: media recovery requesting unknown log: thread 1 scn 1048439 With the database open all missing tempfiles must be replaced: sql "ALTER TABLESPACE temp ADD TEMPFILE ''C:\Oracle\oradata\W2K2\temp01.dbf'' SIZE 100M AUTOEXTEND ON NEXT 64K"; Once the database is fully recovered a new backup should be perfomed. The recovered database will be registered in the catalog as a new incarnation. The current incarnation can be listed and altered using the following commands: list incarnation; reset database to incarnation x;
# recovery within the last week report obsolete recovery window of 7 days; delete obsolete recovery window of 7 days; # Show/Delete items with more than 2 newer copies available report obsolete redundancy = 2 device type disk; delete obsolete redundancy = 2 device type disk; # Show datafiles that connot currently be recovered report unrecoverable database; report unrecoverable tablespace 'USERS'; It's worth spending some time looking at all the reporting capabilities whilst deciding whether you should switch from shell scripting to RMAN. It might just influence your decision. For more information see:
CONFIGURE This! Taking Advantage of Oracle 9i Recovery Manager (RMAN) Features During Backups
By Jim Czuprynski
Synopsis. Oracle Recovery Manager (RMAN) features have been expanded significantly in Oracle 9i. This article discusses several of these new features and includes examples on how to implement them to make any Oracle DBA's backup, restoration, and disaster recovery plans more effective. Oracle Recovery Manager (RMAN) is one of the most versatile tools in any Oracle DBA's toolbox to insure that a database is highly available. Our DBA group has been using it as our prime tool for database backup, recovery, duplication, and migration since we created our first Oracle 8i production databases in early 2001, and we continue to use it for those tasks after upgrading our databases to Oracle 9i Release 2 (9iR2). The Oracle 8i RMAN command set is backward compatible, so when I upgraded our databases to 9iR2, I did not have to change our backup scripts. When I recently had a chance to refresh my Oracle 9i backup and recovery skills at Oracle University, however, I found out that I had been missing out on several of RMAN's newer features. Here is a short list of several RMAN features that were enhanced as of 9iR2:
CONFIGURE This
The new CONFIGURE command encapsulates and replaces a number of older RMAN directives. For example, I can configure default settings for automatic backup channels so that my backup scripts do not require channel configuration statements each time they are run.
For example, to set default channels to use disk, set the default degree of parallelism to 2, and set up the default disk channel settings to be used during backup and recovery operations, the following commands would be issued: CONFIGURE DEFAULT DEVICE TYPE TO DISK; CONFIGURE DEVICE TYPE DISK TO PARALLELISM 2; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT = 'k:\rmanbkup\df0_%d_%s_%t'; (Note that I can also use these directives to configure default settings for media management software layers - often a tedious task prior to implementation of CONFIGURE - but this is beyond the scope of this article.) The standard ALLOCATE CHANNEL command can be used to override the default settings for channels created via the CONFIGURE command. For example, issuing the following command will change the destination of the RMAN backups created, but still leave the default destination intact: ALLOCATE CHANNEL d1 TYPE DISK FORMAT 'k:\rmanbkup\df0_%d_%s_%t';
copies of datafiles and controlfiles. For example, to make sure I have enough backups to recover the database as it stood up to three days ago, I would issue: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS; Moreover, to insure that I have at least two copies of each datafile and controlfile backup, I would issue: CONFIGURE RETENTION POLICY TO REDUNDANCY 2; RMAN keeps all archived redo logs and incremental backups necessary to insure the retention policies can be met. When a backup piece is no longer needed, RMAN marks it as obsolete. If I want to clear out all obsolete backup files, I simply need to run the DELETE OBSOLETE; RMAN command and RMAN handles the deletion of the corresponding physical files.
Tools: Add databasejournal.com to your favorites Add databasejournal.com to your browser search box IE 7 | Firefox 2.0 | Firefox 1.5.x Receive news via our XML/RSS feed