{"id":2650,"date":"2019-03-12T15:13:22","date_gmt":"2019-03-12T12:13:22","guid":{"rendered":"https:\/\/sysdba.org\/?p=2650"},"modified":"2019-03-12T15:13:22","modified_gmt":"2019-03-12T12:13:22","slug":"oracle-recovery-manager-rman-recovery-catalog-2","status":"publish","type":"post","link":"https:\/\/sysdba.org\/en\/oracle-recovery-manager-rman-recovery-catalog-2\/","title":{"rendered":"Oracle Recovery Manager (RMAN & Recovery Catalog)"},"content":{"rendered":"

IT professionals should strive to check and answer the following :<\/span><\/p>\n

\u2022 If access to a database server is lost, what would the cost to a company be (monetary and reputation) ?<\/p>\n

\u2022 What is the maximum duration that a loss of access can be tolerated ?<\/p>\n

\u2022 If server X crashes, how long would it take to fully recover ? (Business continuity planning, working out the time to recover by carrying out a recovery procedure)<\/p>\n

\u2022 Are backups being taken and checked regularly ?<\/p>\n

\u2022 Verifying that the backups are working and are periodically tested<\/p>\n

\u2022 If the RAC1 server is offline, how quickly can it be put back online ?<\/p>\n

\u2022 What to do in a situation where RAC2 goes offline while RAC1 is offline ?<\/p>\n

\u2022 How soon can a RACx server be put back online ?<\/p>\n

\u2022 It is strongly advised to keep a step-by-step recovery guide ready, taking precautions is considered vital.<\/p>\n

(For example: Is there backup media ready and waiting to be removed immediately if there was a disaster such as a fire at a workplace ?)<\/p>\n

\u2022 Prepare documents that are easy to understand and could guide anyone to restore backups, in case of an emergency where you are unavailable and people couldn’t contact you.<\/p>\n

 <\/p>\n

In this article we try to explain the subject of Oracle backups and in a separate article we will discuss restoring\/recovery.<\/p>\n

 <\/p>\n

RMAN (Recovery Manager)<\/h3>\n

This a built-in tool that comes with Oracle. It can be used to take backups of a database while it is open and can perform incremental backups.<\/p>\n

In addition to being able to perform block media recoveries, RMAN has many other features.<\/p>\n

 <\/p>\n

Terminology<\/span><\/h4>\n

Target Database:<\/strong> The db to be backed up and restored.<\/p>\n

RMAN Repository:<\/strong> The metadata collection about dbs used for backup, maintenance and recovery. This information is stored in control file records.<\/p>\n

Recovery Catalog schema:<\/strong> The schema that holds the backup metadata, held in the recovery catalog database.<\/p>\n

RMAN Client:<\/strong> A command line program used by client computers to connect to a database server, using specific connections and requires authentication, like SQL*Plus.<\/p>\n

Backup Piece:<\/strong> The physical files that together form RMAN backup sets. Each piece file is in a proprietary binary RMAN format.<\/p>\n

Backup Set:<\/strong> A number of files, including control files, datafiles, archived redo log files. There are one or more binary files per backup set.<\/p>\n

Image Copy:<\/strong> An identical copy of single datafiles, archived redo log files or control files. They can be used to perform recovery without needing any modification.
\n[crayon]configure device type disk backup type to copy ;[\/crayon]<\/p>\n

RMAN backup information can be stored in 2 locations:<\/p>\n

1. In a controlfile<\/p>\n

2. In a recovery catalog<\/p>\n

If there are 1 or 2 Oracle servers in your company then you can use a controlfile. In scenarios where you have numerous databases, it would be better to store all their backup information in separate locations from a recovery standpoint, rather than in a single recovery catalog.<\/p>\n

A recovery catalog itself is an RMAN set of tables and views where repository data about one or more databases are kept.<\/p>\n

Additionally the catalog can store more metadata history information than a control file. RMAN scripts can also be kept in a recovery catalog that can be used to automate RMAN tasks.<\/p>\n

Perhaps the best feature of recovery catalogs are that it is possible to use them even if control files are damaged (using CONFIGURE CONTROLFILE AUTOBACKUP ON), however the recovery process takes longer using a recovery catalog instead of a control file. This becomes more apparent in the recovery\/restore scenario articles.<\/p>\n

NOTE: After every backup of target databases, a copy should be made of recovery catalog databases as they would contain the latest data.<\/p>\n

Some Recovery Catalog recommendations:<\/strong><\/p>\n

The RC server should be in archive mode and the backup copies in a seperate location.<\/p>\n

A retention policy of higher than 1.<\/p>\n

Activating automatic backup of the control file.<\/p>\n

Not changing CONTROL_FILE_RECORD_KEEP_TIME values so that they are higher than the default values.<\/p>\n

To take online or hot backups using RMAN, the database needs to be in archive mode.<\/p>\n

Archivelog Mode:<\/strong> Redo logs are stored as archives in order to return the database to a certain time. This is similar to a Windows restore point.<\/p>\n

For example: If a full backup was made on a Sunday and the system failed on a Wednesday. The database is first restored to its state as it was on Sunday, using a full backup, and archivelogs are then used to restore the database to its state between Sunday and Wednesday.<\/p>\n

Please refer to the article on placing a database into ArchiveLog Mode.<\/p>\n

NoArchiveLog Mode:<\/strong> Redo logs can’t be archived in this mode.<\/p>\n

You can restore back to the point where a full backup was taken, which was Sunday in the example above, however it isn’t possible to access the data from then on until system failure.<\/p>\n

Logical Backups:<\/strong> Backups made using the exp\/imp and exdp\/imdp tools. (Questions about logical backups appear in Oracle Certified Professional exams (version 9i)).<\/p>\n

Physical Backups:<\/strong> A backup of the physical files, including data files, archive logs and control files.<\/p>\n

Having the target database and recovery catalog in separate instances\/servers is strongly recommended.<\/p>\n

Levels of backup<\/strong><\/p>\n

\u2022 Backup of all database files (data file, control file, archivelog)<\/p>\n

\u2022 Backups made at the tablespace level (all of the datafiles in the tablespace)<\/p>\n

\u2022 A backup of the tablespace’s datafile can be made if the database is in archivelog mode.<\/p>\n

 <\/p>\n

The configuration of the machines running the examples in this articles are as follows:<\/p>\n\n\n\n\n\n\n\n\n\n
Machine A<\/strong><\/td>\nMachine B<\/strong><\/td>\n<\/tr>\n
Oracle 10G 10.2.0.5<\/td>\nOracle 10G<\/td>\n<\/tr>\n
RHEL 5.5<\/td>\nOracle Solaris 10<\/td>\n<\/tr>\n
i386 CPU, 1284MB RAM<\/td>\n<\/td>\n<\/tr>\n
5 disk<\/td>\n<\/td>\n<\/tr>\n
Disk 1: OS<\/td>\n<\/td>\n<\/tr>\n
Disks 2,3,4,5: Included in the data and recovery asm (automatic storage management) group<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

Creating a Recovery Catalog<\/strong><\/p>\n

1. Creating a tablespace<\/p>\n

2. Creating a user and granting privileges[crayon]CREATE TABLESPACE rec_cat DATAFILE
\n‘+DATA\/orcl\/datafile\/rec_cat01’ SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE 1024M
\nLOGGING
\nPERMANENT
\nEXTENT MANAGEMENT LOCAL AUTOALLOCATE
\nBLOCKSIZE 8K
\nSEGMENT SPACE MANAGEMENT AUTO
\nFLASHBACK ON;[\/crayon]<\/p>\n

[crayon]CREATE USER cat IDENTIFIED BY cat
\nDEFAULT TABLESPACE rec_cat
\nTEMPORARY TABLESPACE “TEMP”
\nQUOTA UNLIMITED ON rec_cat;[\/crayon]<\/p>\n

[crayon]GRANT CONNECT,RESOURCE TO cat;
\nGRANT “RECOVERY_CATALOG_OWNER” TO CAT;
\nALTER USER CAT DEFAULT ROLE “RECOVERY_CATALOG_OWNER”;[\/crayon]<\/p>\n

[crayon]rman catalog cat\/cat
\ncreate catalog;[\/crayon]<\/p>\n

Procedures to run on the server where the Recovery Catalog is to be stored. (Backup information will be stored on a catalog server)<\/p>\n

As this is a test environment the recovery catalog server and the server where backup information is stored are the same.<\/p>\n

However in a production environment it is recommended having both sets of data on separate servers.<\/p>\n

[crayon]$rman target \/
\nRMAN> connect catalog cat\/cat@orcl<br< a=””> \/>RMAN> register database;[\/crayon]<\/p>\n

The previous syntax shows that RMAN backups will now be stored in the recovery catalog.
\nConnecting with RMAN:<\/p>\n

[crayon]$rman
\nconnect target \/
\nalternatively
\n$rman target \/
\nRecovery Manager: Release 10.2.0.5.0 – Production on Thu Jun 16 14:15:13 2011
\nCopyright (c) 1982, 2007, Oracle. All rights reserved.
\nconnected to target database: ORCL (DBID=1257644776)[\/crayon]<\/p>\n

[crayon]$rman target sys\/sys@orcl
\nRecovery Manager: Release 10.2.0.5.0 – Production on Thu Jun 16 14:16:59 2011
\nCopyright (c) 1982, 2007, Oracle. All rights reserved.
\nconnected to target database: ORCL (DBID=1257644776)[\/crayon]<\/p>\n

It is now possible to connect to the target database.<\/p>\n

To connect to the remote machine the rman client needs to be compatible with the server. If they are not compatible:<\/p>\n

[crayon]RMAN-06429: TARGET database is not compatible with this version of RMAN \u00ab error message[\/crayon]
\nConnecting to the target database and catalog:
\n[crayon]rman TARGET sys\/sys@orcl CATALOG cat\/cat@orcl \u00ab recovery database is the same as the target database
\nRecovery Manager: Release 10.2.0.5.0 – Production on Thu Jun 16 14:14:34 2011
\nCopyright (c) 1982, 2007, Oracle. All rights reserved.
\nconnected to target database: ORCL (DBID=1257644776)
\nconnected to recovery catalog database[\/crayon]<\/p>\n

Connecting to the target database without a recovery catalog:
\n[crayon]$ rman TARGET sys\/sys@orcl NOCATALOG
\nRecovery Manager: Release 10.2.0.5.0 – Production on Thu Jun 16 14:13:18 2011
\nCopyright (c) 1982, 2007, Oracle. All rights reserved.
\nconnected to target database: ORCL (DBID=1257644776)
\nusing target database control file instead of recovery catalog[\/crayon]<\/p>\n

Running the parameter file (RMAN commands can be run after entering them into a parameter file)<\/p>\n

[crayon]$ rman @\/home\/oracle\/Batches\/rman.txt
\n$ rman sys\/sys@orcl catalog cat\/cat@orcl CMDFILE RmanParameter.txt log Rman.log[\/crayon]<\/p>\n

Connecting to the target db, creating a log and trace
\n[crayon]$ rman TARGET sys\/password NOCATALOG debug trace=rman.trc log=rman.log[\/crayon]<\/p>\n

Connecting to the target db, creating a log
\n[crayon]$ rman TARGET sys\/password log=rman.log APPEND[\/crayon]<\/p>\n

Backup information can be queried from the tables and views in the CAT schema.<\/p>\n

Example Scenario:<\/strong> The Oracle database is not connected to the recovery catalog. If backups taken using RMAN were later saved on the recovery catalog, they might later need to be manually synchronized.<\/p>\n

The BACKUP and COPY commands to be used on the target database get automatically synchronized with the recovery catalog. A situations where changes made to the physical structure and there a high number of log switches might also need to be manually synchronized.<\/p>\n

[crayon][oracle@asm ~]$ rman TARGET sys\/sys@orcl CATALOG cat\/cat@orcl
\nRecovery Manager: Release 10.2.0.5.0 – Production on Thu Jun 16 14:21:22 2011
\nCopyright (c) 1982, 2007, Oracle. All rights reserved.
\nconnected to target database: ORCL (DBID=1257644776)
\nconnected to recovery catalog database[\/crayon]<\/p>\n

[crayon]RMAN> RESYNC CATALOG;
\nstarting full resync of recovery catalog
\nfull resync complete[\/crayon]<\/p>\n

Scripting<\/strong><\/p>\n

RMAN scripts can be copied to the recovery catalog or a text file.<\/p>\n

If using a Recovery Catalog, you could run a RC script directly.<\/p>\n

If you’re not using a recovery catalog then use the RMAN by entering this command: @\/path\/rman.txt<\/p>\n

[crayon]CREATE SCRIPT COMPRESSED_FULL_BACKUP {
\nALLOCATE CHANNEL C1 TYPE DISK ;
\nBACKUP AS COMPRESSED BACKUPSET DATABASE FORMAT ‘\/u01\/Rman\/%u’ ;}[\/crayon]<\/p>\n

[crayon]CREATE SCRIPT COMPRESSED_FULL_BACKUP_ARC {
\nbackup as compressed backupset database format ‘\/u01\/Rman\/dbf_%d_%t_%s.rman’ Tag=’DBF_Manual_%U’
\nplus archivelog format ‘\/u01\/Rman\/arc_%d_%t_%s.rman’ tag=’Arc_Manual_%U’ ;}[\/crayon]<\/p>\n

[crayon]CREATE SCRIPT TBS_USERS {
\nbackup as compressed backupset tablespace users format ‘\/u01\/Rman\/users-tbs.rman’ Tag=’users-tbs_Manuel_16062011′ ;}[\/crayon]<\/p>\n

Running the scripts<\/strong><\/p>\n

[crayon]RUN
\n<\/strong>{
\nALLOCATE CHANNEL C1 TYPE SBT ;
\nALLOCATE CHANNEL C2 TYPE SBT ;
\nBACKUP
\nFORMAT ‘FULL BACKUP_u%’
\nFILEPERSET 15
\nDATABASE;
\nRELEASE C1;
\nRELEASE C2;
\n}[\/crayon]<\/p>\n

Checking the scripts<\/strong><\/p>\n

[crayon][oracle@asm ~]$ rman checksyntax @\/home\/oracle\/Scripts\/COMPRESSED_BACKUP
\nRecovery Manager: Release 10.2.0.5.0 – Production on Fri Jun 17 14:53:04 2011
\nCopyright (c) 1982, 2007, Oracle. All rights reserved.
\nbackup as compressed backupset database format ‘\/u01\/Rman\/dbf_%d_%t_%s.rman’ Tag=’DBF_Manual_16062011′
\nplus archivelog format ‘\/u01\/Rman\/arc_%d_%t_%s.rman’ tag=’Arc_Manual_16062011′ ;
\nThe cmdfile has no syntax errors
\nRecovery Manager complete.[\/crayon]<\/p>\n

Saving the script to a text file<\/p>\n

[crayon]print script COMPRESSED_FULL_BACKUP_ARC to file ‘backupscript.txt’ ;
\nscript COMPRESSED_FULL_BACKUP_ARC written to file backupscript.txt[\/crayon]<\/p>\n

The file should be in the same directory where RMAN was run.<\/p>\n

By creating global scripts it will be possible to use them in all databases that were saved to the recovery catalog.<\/p>\n

[crayon]create global script glb_full_backup
\n{
\nbackup database plus archivelog;
\ndelete obsolete;
\n}[\/crayon]<\/p>\n

To view the contents of the global scripts<\/strong><\/p>\n

[crayon]print global script global_full_backup ;[\/crayon]<\/p>\n

Listing the scripts<\/strong><\/p>\n

[crayon]LIST SCRIPT NAMES;
\nLIST GLOBAL SCRIPT NAMES;
\nLIST ALL SCRIPT NAMES;[\/crayon]<\/p>\n

[crayon]SELECT script_name FROM cat.rc_stored_script; –recovery catalog un sahibi
\nSELECT script_name, line, text FROM cat.rc_stored_script_line[\/crayon]<\/p>\n

 <\/p>\n

Deleting the scripts<\/strong><\/p>\n

[crayon]delete script ‘script_ismi’ ;
\ndelete global script ‘script_ismi’ ;[\/crayon]<\/p>\n

Running scripts on RMAN startup<\/strong><\/p>\n

[crayon]rman TARGET sys\/sys@orcl CATALOG cat\/cat@orcl SCRIPT ‘\/home\/oracle\/Scripts\/backup.sh'[\/crayon]<\/p>\n

Configuring the backup channel and tool<\/strong><\/p>\n

[crayon]configure default device type to sbt ; –tape
\nconfigure default device type to disk ; –disk[\/crayon]<\/p>\n

The device selected by default can be changed for a pending backup<\/p>\n

[crayon]run
\n{
\nbackup database ;
\n}[\/crayon]<\/p>\n

Tagging the backups<\/strong><\/p>\n

[crayon]backup tag ‘daily_full_backup’ database ;
\nbackup format=’DBF_%d_%t_%s_%p’ archivelog like ‘%Arc_dest%’ ;[\/crayon]<\/p>\n

Copying the RMAN backups<\/strong><\/p>\n

[crayon]run {
\nBACKUP DEVICE TYPE DISK
\nCOPIES 2 DATAFILE 5
\nFORMAT ‘\/u01\/y1\/dbf5_%U’, ‘\/u01\/y2\/dbf5_%U’ ;
\n}[\/crayon]<\/p>\n

The syntax below shows how backups can be taken from an operating system to a separate location, the catalog command could be included in RMAN when required. There is an example scenario where this is shown.<\/p>\n

Copying a backup to a different disk or tape<\/strong><\/p>\n

[crayon]backup device type disk as backupset database plus archivelog format ‘\/u01\/y2\/yy_%U’ ;
\nbackup device type sbt as backupset database plus archivelog \u00ab from disk to tape
\nbackup device type sbt as backupset ALL[\/crayon]<\/p>\n

Backup commands<\/strong><\/p>\n

[crayon]backup database ;
\nbackup tablespace tablespace_name ;
\nbackup datafile ‘+DATA\/orcl\/datafile\/examples’ ; \u00ab Retrieve the datafile information from dba_data_files
\nbackup as copy database ;
\nbackup as copy tablespace examples ;
\nbackup as copy datafile ‘+DATA\/orcl\/datafile\/examples’ ;
\nbackup tablespace examples TAG = ‘Daily_Backup’ ;
\n[\/crayon]<\/p>\n

Incremental Backup<\/strong><\/p>\n

Differential Incremental: The differences or changes since the last backup.<\/p>\n

Incremental level 0 = Full Backup (a backup of every used block, this is the base of the incremental backup)<\/p>\n

Listed below is an example of a weekly plan backup plan:<\/p>\n

Sunday level 0 \u00ab Take a full backup<\/p>\n

Monday incremental level 2 \u00ab No previous level 2 backup, so a backup of the difference since level 0<\/p>\n

Tuesday incremental level 2 \u00ab A previous level 2 backup, so the differences since the level 2 backup<\/p>\n

Wednesday incremental level 2 \u00ab A previous level 2 backup, so the differences since the level 2 backup<\/p>\n

Thursday incremental level 1 \u00ab No previous level 1 backup, if there was, a backup would have been made of the difference. Instead a backup is made from 0, this is a difference from a full backup from the middle of the week.<\/p>\n

Checking to see if any backups were made at the current level or at a more base level, if backups were made at a more base level (lower number) then a backup is made of the difference.<\/p>\n

[crayon]sun mon tues wed thurs fri sat sun
\n0 3 3 2[\/crayon]<\/p>\n

A full backup is taken on Sunday<\/p>\n

On Monday, the difference since Sunday is what gets taken as a backup.<\/p>\n

On Tuesday, a backup is made of the difference in the database state since Monday.<\/p>\n

On Wednesday, has a backup been made at the same level ? If not, a backup is made since the last closest level of backup, in this case a level 2 which was on Sunday.<\/p>\n

Logically it would be quicker to take a daily incremental backup after the full backup but taking a backup in this way is suprisingly slow, at least until the “block_change_tracking” feature has been activate.<\/p>\n

[crayon]set linesize 121
\ncol filename format a60
\nSELECT filename, status, bytes
\nFROM v$block_change_tracking;[\/crayon]<\/p>\n

[crayon]ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
\nUSING FILE ‘\/oracle\/flash_recovery_area\/ORATR\/bctf01.log’ ;[\/crayon]<\/p>\n

[crayon]SELECT filename, status, bytes
\nFROM v$block_change_tracking;[\/crayon]<\/p>\n

[crayon]ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;[\/crayon]<\/p>\n

[crayon]SELECT filename, status, bytes
\nFROM v$block_change_tracking;[\/crayon]<\/p>\n

[crayon]backup incremental level 0 database plus archivelog;
\nbackup incremental level 1 database plus archivelog;[\/crayon]<\/p>\n

First backup example<\/strong>
\n[crayon]–Sunday
\nbackup incremental level 0 database plus archivelog;
\n–Monday
\nbackup incremental level 1 database ;
\n–Tuesday
\nbackup incremental level 1 database ;
\n–Wednesday
\nbackup incremental level 1 database ;
\n–Thursday
\nbackup incremental level 1 database ;
\n–Friday
\nbackup incremental level 1 database ;
\n–Saturday
\nbackup incremental level 1 database ;
\n–Sunday
\nbackup incremental level 0 database plus archivelog;[\/crayon]<\/p>\n

Commands<\/strong><\/p>\n

The ALLOCATE CHANNEL and SWITCH parameters need to be placed in curly bracket. <>.
\n[crayon]run backup datafile 1;[\/crayon]
\n[crayon]backup as copy datafile 5 ;[\/crayon]<\/p>\n

Deleting backups<\/strong><\/p>\n

If RMAN suggests deleting backups from the operating system, even though there is a solution for dealing with deleted backups it is recommended to not delete them.<\/p>\n

[crayon]delete archivelog all backed up 2 times to device type disk \u00ab Deletes archivelogs that have been backup up at least twice
\nBACKUP ARCHIVELOG ALL DELETE INPUT; \u00ab All archivelogs that have been backed up get deleted.
\n[\/crayon]<\/p>\n

Deleting backups that aren’t required (in accordance with the retention policy, more details ahead).<\/p>\n

[crayon]delete obsolete ;[\/crayon]<\/p>\n

Crosschecking whether Rman backups have been deleted by the operating system. Backups that can’t be found are marked as expired and erased using “delete expired”.<\/p>\n

[crayon]crosscheck archivelog all
\ncrosscheck backupset
\ncrosscheck backup[\/crayon]<\/p>\n

Deleting backups that have been marked as expired.<\/p>\n

[crayon]delete expired ;
\ndelete noprompt expired ; \u00ab Deletes the backups that are marked expired without prompting[\/crayon]<\/p>\n

Occasionally Rman scripts stops responding and without being able to control a script the archive logs start to get filled up. This could be followed by running out of diskspace and losing access. The only remaining option is to regain access at a local level.<\/p>\n

To create space as quickly as possible, in this situation, the oldest of the archive logs should be moved to another location or in the worst case should be deleted, however this is not recommended as it could cause problems.<\/p>\n

If the archive logs have been deleted by the operating system or moved to another disk, at this point it is possible to access the system by entering commands.<\/p>\n

[crayon]crosscheck archivelog all
\ndelete noprompt expired archivelog all
\nalter system switch logfile;[\/crayon]<\/p>\n

Report commands<\/strong><\/p>\n

[crayon]report schema ; \u00ab Lists the data files in the target database[\/crayon]<\/p>\n

report obsolete ; \u00ab Lists the backups marked as obsolete (unused or unnecessary) according to the database’s retention policy. These backups can be deleted using the “delete obsolete” command. If the flash recovery area is used as the backup path, as long as there is available space in the path obsolete backups would continue being stored there, otherwise they get deleted. If backups are stored in a different area then they would need to be deleted manually (Scripts generally get deleted by writing into them, examples such as these will be shown in the scenario section inshALLAH)<\/p>\n

[crayon]report need backup ; \u00ab Files that require backups get listed according to the retention policy setting.
\nREPORT NEED BACKUP DEVICE TYPE sbt;
\nREPORT NEED BACKUP DEVICE TYPE disk;
\nREPORT NEED BACKUP TABLESPACE users DEVICE TYPE sbt;
\nREPORT UNRECOVERABLE ; \u00ab Shows database files that need to be urgently backed up due to nologging operations such as Direct-Path INSERT (As they haven’t created redo logs. (As they haven’t created redo logs, files that need to be backed up are listed).[\/crayon]<\/p>\n

Backup files that are unknown to Rman (not in its records) are used to inform Rman after the following has taken place:<\/p>\n

\u2022 The process of restoring the control file<\/p>\n

\u2022 Re-creating the control file<\/p>\n

\u2022 Changes to the db_recovery_file_dest parameters<\/p>\n

\u2022 Needing to restore backup files from a disk, separate to the one where the backups have been taken.<\/p>\n

[crayon]catalog datafilecopy ‘\/u01\/y1\/accounts01.dbf’ ;
\ncatalog backuppiece ‘\/u01\/Rman\/ORCL_DB_1hmfeu60_49_1’ ;
\ncatalog start with ‘\/u02\/Rman\/’ ;[\/crayon]<\/p>\n

If there are inconsistencies between the physical backups on the disk and the backup records in Rman, they may get deleted. (There should be a backup of the backup before any deletion takes place. If there are any problems you could get support from Oracle and do a restore.)<\/p>\n

[crayon]delete force archivelog sequence 23 ;[\/crayon]<\/p>\n

Listing the backups<\/strong><\/p>\n

[crayon]LIST BACKUP;
\nLIST BACKUP SUMMARY;
\nLIST COPY;
\nLIST ARCHIVELOG ALL;
\nLIST BACKUP OF DATABASE;
\nLIST INCARNATION;
\nLIST BACKUP BY FILE;
\nLIST COPY OF DATABASE ARCHIVELOG ALL;
\nLIST COPY OF DATAFILE 1, 2, 3;
\nLIST BACKUP OF DATAFILE 1 SUMMARY;
\nLIST BACKUP OF ARCHIVELOG FROM SEQUENCE 1453;
\nLIST CONTROLFILECOPY “\/u02\/backup\/CNTRLFILE.CP”;
\nLIST BACKUPSET OF DATAFILE 1;
\nLIST SCRIPT NAMES;
\nLIST GLOBAL SCRIPT NAMES;[\/crayon]<\/p>\n

Checking the usability of the backups.<\/strong><\/p>\n

[crayon]validate backupset 5;[\/crayon]<\/p>\n

[crayon]RMAN-00571: ===========================================================
\nRMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
\nRMAN-00571: ===========================================================
\nRMAN-03002: failure of validate command at 06\/22\/2011 13:09:06
\nRMAN-06004: ORACLE error from recovery catalog database: RMAN-20215: backup set not found
\nRMAN-06159: error while looking up backup set[\/crayon]<\/p>\n

[crayon]validate backupset 879;[\/crayon]<\/p>\n

[crayon]using channel ORA_DISK_1
\nchannel ORA_DISK_1: starting validation of datafile backupset
\nchannel ORA_DISK_1: reading from backup piece \/u01\/Rman\/19mfe9nl
\nchannel ORA_DISK_1: restored backup piece 1
\npiece handle=\/u01\/Rman\/19mfe9nl tag=TAG20110621T100748
\nchannel ORA_DISK_1: validation complete, elapsed time: 00:00:46[\/crayon]<\/p>\n

RMAN settings<\/strong><\/p>\n

[crayon]show all; \u00ab Shows all available settings[\/crayon]<\/p>\n

The “# default” at the end of a sentence indicates that the values haven’t been changed at that they are still at their default settings.<\/p>\n

[crayon]CONFIGURE RETENTION POLICY TO REDUNDANCY 1; \u00ab Just stores a single backup, a value of 4 would mean setting it to store 4 backups.<\/p>\n

CONFIGURE BACKUP OPTIMIZATION ON; \u00ab If the tablespaces are read-only & if there are backups of data that hasn’t been changed, another backup is made.<\/p>\n

CONFIGURE DEFAULT DEVICE TYPE TO DISK; \u00ab The default backup device could be set as a disk or tape.<\/p>\n

CONFIGURE CONTROLFILE AUTOBACKUP ON; \u00ab Ensures that the control file and spfiles are backed up when the structure of the database changes (adding or deleting dbf or redolog) and backups are made<\/p>\n

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; \u00ab Should be in %F format, it may be difficult to restore if changed.<\/p>\n

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;<\/p>\n

CONFIGURE DEVICE TYPE DISK PARALLELISM 1; \u00ab Can be increased according to the number of processors in order to speed up the backup process. This then increases the number of files that are created.<\/p>\n

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; \u00ab Indicates the number of copies of the Datafile backups.<\/p>\n

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; \u00ab Indicates the number of copies of the Archivelog files.<\/p>\n

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘\/u01\/Rman\/%d_DB_%u_%s_%p’; \u00ab The backup device, path and format.<\/p>\n

CONFIGURE MAXSETSIZE TO UNLIMITED; –CONFIGURE MAXSETSIZE TO 10G; \u00ab To set restrictions such as the backup files not being over 10Gb or restrictions on the hardware or the operating system.<\/p>\n

CONFIGURE ENCRYPTION FOR DATABASE OFF; \u00ab Encrypting the backups is vital for security purposes.<\/p>\n

CONFIGURE ENCRYPTION ALGORITHM ‘AES128’; \u00ab The setting for the encryption method or algorithm.<\/p>\n

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; \u00ab If this is set to 2, backup Np 1. would be marked as obsolete and backup No. 2, i.e. the latest backup, would be set as the backup to be restored from.<\/p>\n

CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘\/u01\/y1\/snapcf_orcl.f’ \u00ab The location where a snapshot of the control file is kept, used to synchronize with the catalog database.<\/p>\n

configure retention policy to recovery window of 7 days; \u00ab Retains all of the backups that have been taken for a period of 7 days, would not mark them as obsolete. Either one of the “windows” or “redundancy” keywords may be used but not both at the same ti\u00f6e<\/p>\n

Typing clear at the end of the statements would reset the setiting back to its defaults.<\/p>\n

CONFIGURE CONTROLFILE AUTOBACKUP clear ;<\/p>\n

configure backup optimization clear;[\/crayon]<\/p>\n","protected":false},"excerpt":{"rendered":"

IT professionals should strive to check and answer the following<\/p>\n","protected":false},"author":1,"featured_media":3464,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[348,338],"tags":[345],"class_list":["post-2650","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dba_ii","category-oracle-tr","tag-oracle"],"_links":{"self":[{"href":"https:\/\/sysdba.org\/en\/wp-json\/wp\/v2\/posts\/2650","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sysdba.org\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sysdba.org\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sysdba.org\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sysdba.org\/en\/wp-json\/wp\/v2\/comments?post=2650"}],"version-history":[{"count":0,"href":"https:\/\/sysdba.org\/en\/wp-json\/wp\/v2\/posts\/2650\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sysdba.org\/en\/wp-json\/"}],"wp:attachment":[{"href":"https:\/\/sysdba.org\/en\/wp-json\/wp\/v2\/media?parent=2650"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sysdba.org\/en\/wp-json\/wp\/v2\/categories?post=2650"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sysdba.org\/en\/wp-json\/wp\/v2\/tags?post=2650"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}