Oracle RMAN

Oracle RMAN Backup, Recover, and Restore Demos Version 19c

General Information
Library Note	[an error occurred while processing this directive]
Purpose	???

Add the RMAN Repository To TNSNAMES.ORA
-- as the owner of the Oracle Database to be backed up perform the following actions. -- from the location of the production server you will be backing up. -- for the pings, substitute the location of the repository database you will build. $ ping bigdog.mlib.org $ ping bigdog $ ping 192.168.1.119 $ cd $ORACLE_HOME/network/admin $ vi tnsnames.ora -- add the following: REPOS = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.119)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = repos) ) ) -- save change <Esc> zz $ tnsping repos

Place The Production Database Into Archive Log Mode
-- as the operating system user that owns the Oracle software installation files $ sqlplus /nolog SQL> conn / as sysdba SQL>col name format a30 SQL>col value format a30 SQL>SELECT name, value FROM gv$parameter WHERE name LIKE '%arch%'; SQL> shutdown immediate; SQL> startup mount exclusive; SQL> alter database archivelog; SQL> alter database open; SQL> SELECT group#, thread#, sequence#, archived, status, first_time FROM v$log; SQL> alter system switch logfile; SQL> SELECT group#, thread#, sequence#, archived, status, first_time FROM v$log; SQL> alter system switch logfile; SQL> SELECT group#, thread#, sequence#, archived, status, first_time FROM v$log; SQL> SELECT dbid, name FROM v$database; -- save the dbid for future reference

Create RMAN Repository Database
-- in the database that will be the home of the RMAN repository schema -- the following demo code assumes that the repository is a container database conn sys@repos AS SYSDBA password: ************ SELECT file_name FROM dba_data_files; SELECT name, value FROM v$parameter WHERE name like '%block%'; -- size based on the formula extent_size > (block_size * 14) +1 CREATE BIGFILE TABLESPACE cattbsp DATAFILE '/u01/orabase18/oradata/orabase/repos/cattbsp.dbf' SIZE 100M AUTOEXTEND ON BLOCKSIZE 8K DEFAULT NOCOMPRESS EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K SEGMENT SPACE MANAGEMENT AUTO ONLINE; CREATE BIGFILE TEMPORARY TABLESPACE cattemp TEMPFILE '/u01/orabase18/oradata/orabase/repos/cattemp.dbf' SIZE 20G AUTOEXTEND OFF BLOCKSIZE 8K EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K; CREATE USER rmanadmin IDENTIFIED BY oracle1 -- use a real password, the catalog must be secure DEFAULT TABLESPACE cattbsp TEMPORARY TABLESPACE cattemp QUOTA UNLIMITED ON cattbsp; GRANT recovery_catalog_owner TO rmanadmin; GRANT execute ON dbms_stats TO rmanadmin; -- required for class only CREATE OR REPLACE SYNONYM dbms_stats FOR sys.dbms_stats; -- required for class only conn rmanadmin/oracle1@repos SELECT COUNT(*) FROM user_objects;

Create RMAN Catalog and Register the Database
$ rman target / catalog rmanadmin/oracle1@repos -- if the tablespace already exists: RMAN> create catalog; -- if CATTBSP is not the default tablespace RMAN> create catalog tablespace cattbsp; RMAN> register database; RMAN> report need backup; RMAN retention policy will be applied to the command RMAN retention policy is set to redundancy 1 Report of files with less than 1 redundant backups File #bkps Name ---- ----- ----------------------------------------------------- 1 0 /u01/orabase18/oradata/ORABASE\SYSTEM01.DBF 2 0 /u01/orabase18/oradata/ORABASE\PDBSEED\SYSTEM01.DBF 3 0 /u01/orabase18/oradata/ORABASE\SYSAUX01.DBF 4 0 /u01/orabase18/oradata/ORABASE\PDBSEED\SYSAUX01.DBF 5 0 /u01/orabase18/oradata/ORABASE\UNDOTBS01.DBF 6 0 /u01/orabase18/oradata/ORABASE\USERS01.DBF 7 0 /u01/orabase18/oradata/ORABASE\PDBORCL\SYSTEM01.DBF 8 0 /u01/orabase18/oradata/ORABASE\PDBORCL\SYSAUX01.DBF 9 0 /u01/orabase18/oradata/ORABASE\PDBORCL\SAMPLE_SCHEMA_USERS01.DBF 10 0 /u01/orabase18/oradata/ORABASE\PDBORCL\EXAMPLE01.DBF 11 0 /u01/orabase18/oradata/ORABASE\PDBDEV\SYSTEM01.DBF 12 0 /u01/orabase18/oradata/ORABASE\PDBDEV\SYSAUX01.DBF 13 0 /u01/orabase18/oradata/ORABASE\PDBDEV\ORADATA01.DBF 14 0 /u01/orabase18/oradata/ORABASE\PDBDEV\UWDATA01.DBF 15 0 /u01/orabase18/oradata/ORABASE\PDBDEV\CATTBSP.DBF

Explore the RMAN Catalog Using SQL*Plus
`conn rmanadmin/oracle1@repos SELECT object_type, COUNT() FROM user_objects GROUP BY object_type; SELECT object_name, object_type FROM user_objects WHERE object_type <> 'INDEX' ORDER BY 2,1; desc rc_listbackuppipe SELECT DISTINCT package_name, object_name FROM all_arguments WHERE owner = 'RMANADMIN' AND package_name LIKE 'DBMS%'; conn sys@repos AS SYSDBA password: *********** SELECT owner, object_name, object_type FROM dba_objects_ae WHERE object_name LIKE 'DBMS_RCV%';`

Configure Backup Parameters
RMAN> show all -- the FORCE option can be used to override optimization on a specific BACKUP command RMAN> CONFIGURE BACKUP OPTIMIZATION ON; -- avoid backing up unchanged data files RMAN> CONFIGURE MAXSETSIZE TO 16G; -- make filesize <= 2GB RMAN> CONFIGURE ENCRYPTION FOR DATABASE ON; -- encrypt backups (requires license) RMAN> CONFIGURE ENCRYPTION ALGORITHM 'AES256'; -- use 256 bit encryption (requires license) RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; -- default but good to do self-documenting -- configure the number of server processes (channels) that write backups to DISK RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2; -- Set the retention policy to a recovery window of 30 days -- to ensure that RMAN retains all backups needed to recover for 30 days -- you can use the DELETE OBSOLETE command to delete backups that are no longer required by the retention policy -- to exclude a backup from consideration by the policy, use the KEEP option with the BACKUP command RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS; -- enable automatic controlfile backup after each database or archivelog backup RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON; RMAN> show all;

Run Full Backup
RMAN> report need backup; RMAN> RUN { ALLOCATE CHANNEL d1 DEVICE TYPE DISK FORMAT '/orabase18/recovery_area/orabase18/full_%d_%T_%S.bkp'; # AS COPY is default when backing up to disk BACKUP DATABASE PLUS ARCHIVELOG; CROSSCHECK ALL; DELETE NOPROMPT OBSOLETE; RELEASE CHANNEL d1; } RMAN> report need backup; RMAN> list backup summary; SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS'; SQL> desc v$rman_status SQL> SELECT operation, status, mbytes_processed, start_time, end_time FROM v$rman_status;

Validate Backup
RMAN> crosscheck backup of database; RMAN> crosscheck backup of database; using channel ORA_DISK_1 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=C:\APPS18\RECOVERY_AREA\ORABASE18\9E849C89ACFF49158DAC79F74FAE2E31\BACKUPSET\2018_11_24\O1_MF_NNNDF_TAG20181124T110121_FZM0Z24K_.BKP RECID=2 STAMP=993034882 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle = C:\APPS18\RECOVERY_AREA\ORABASE18\BACKUPSET\2018_11_24\O1_MF_NNNDF_TAG20181124T110121_FZM0ZKGV_.BKP RECID=3 STAMP=993034897 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=C:\APPS18\RECOVERY_AREA\ORABASE18\39B602C7A32A46A08436AEB94EABAB45\BACKUPSET\2018_11_24\O1_MF_NNNDF_TAG20181124T110121_FZM10BLC_.BKP RECID=4 STAMP=993034922 Crosschecked 3 objects -- need to look at data dictionary too

Trash Control File and Recover
`-- note, review above, did the controlfile get backed up? where? $ cd /app/oracle/product/OracleHomes/oradata/orcl $ ls -la $ rm control02.ctl $ cd /app/oracle/product/OracleHomes/admin/orcl/bdump $ tail alert_orcl.log`

Trash Log File and Recover
`-- error when you try to start db after copying one logfile to another (a common mistake) ORA-00341: log 1 of thread 1, wrong log # in header ORA-00312: online log 1 thread 1: '/app/oracle/product/oradata/prod/redo01.log' -- to recover alter database clear unarchived logfile group 1; alter database drop logfile group 1; -- then recreate the log file alter database add logfile group 1 ('/app/oracle/product/oradata/prod/redo01.log') SIZE 512M;`

Trash Data File and Recover
TBD

Trash Temp File and Recover
TBD

Trash Undo Data File File and Recover
TBD

Trash SYSAUX Data File and Recover
TBD

Trash System Data File and Recover
TBD

Damage Single Block(s) and Recover
TBD

Spread the backup across several disk drives. Allocate one DEVICE TYPE DISK channel for each disk drive and specify the format string so that the filenames are on different disks
`RUN { ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT '/disk1/backups/full_%d_%T_%S.bkp'; ALLOCATE CHANNEL disk2 DEVICE TYPE DISK FORMAT '/disk2/backups/full_%d_%T_%S.bkp'; # AS COPY is default when backing up to disk BACKUP DATABASE PLUS ARCHIVELOG; RELEASE CHANNEL d1; RELEASE CHANNEL d2; }`

When creating multiple copies of a backup, you can specify the SET BACKUP COPIES command. The following example generates a single backup of the database to disk, and then creates two identical backups of datafile 1 to two different file systems
`RUN { ALLOCATE CHANNEL c1 DEVICE TYPE DISK MAXPIECESIZE 5G; # AS COPY is the default, so RMAN creates image copies BACKUP DATABASE PLUS ARCHIVELOG; SET BACKUP COPIES = 2; BACKUP DATAFILE 1 FORMAT '/disk1/backups/%U', '/disk2/backups/%U'; RELEASE CHANNEL c1; }`

When creating a duplicate database, allocate a channel by using the AUXILIARY option
`RUN { ALLOCATE AUXILIARY CHANNEL c1 DEVICE TYPE sbt; ALLOCATE AUXILIARY CHANNEL c2 DEVICE TYPE sbt; DUPLICATE TARGET DATABASE TO ndbnewh LOGFILE '?/oradata/aux1/redo01.log' SIZE 20G, '?/oradata/aux1/redo02.log' SIZE 20G, '?/oradata/aux1/redo03.log' SIZE 20G SKIP READONLY; NOFILENAMECHECK; RELEASE CHANNEL c1; RELEASE CHANNEL c2; }`

Auxiliary Database Startup From RMAN
`$ rman TARGET / CATALOG rman/cat@catdb RMAN> STARTUP MOUNT; $ rman TARGET SYS/oracle@trgt NOCATALOG $ rman TARGET / CATALOG rman/cat@catdb AUXILIARY SYS/oracle@auxdb`

RMAN Backup Demo
`$ rman RMAN> connect rcvcat rman/rman RMAN> connect target sys/coi@infradb RMAN> run { 2> allocate channel c1 type disk; 3> backup database format '/nfs/curly/rman/o1/%u'; 4> release channel c1; 5> } database registered in recovery catalog starting full resync of recovery catalog full resync complete RMAN> exit`

RMAN Demo 1
Target Database Not Running in Archive Log Mode CONFIGURATION There are various parameters that can be used to configure RMAN operations to suit your needs. Some of the things that you can configure are: - the required number of backups of each datafile - the number of server processes that will do backup/restore operations in parallel - the directory where on-disk backups will be stored This case study assumes that you want: - 5 backups of each datafile - backups to be stored on disk in the /backup directory - 2 server processes to do backup/restore operations in parallel - no backups for tablespace tbl_exclude, because it is easy to recreate It should be noted that configuration settings are stored persistently, and will be used by RMAN for all subsequent backup, restore, recovery, and maintenance operations.
Configure backups to be written to disk `CONFIGURE DEFAULT DEVICE TYPE TO DISK;` Configure RMAN to keep at least 5 backups of each datafile. If you have certain backups which must be retained longer than this retention policy, you can use the KEEP option with the BACKUP command when creating those backups. `CONFIGURE RETENTION POLICY TO REDUNDANCY 5;` Configure RMAN to use two disk channels for backup, restore, recovery, and maintenance operations. `CONFIGURE DEVICE TYPE DISK PARALLELISM 2;` Configure RMAN to write disk backups to the /backup directory. The format specifier %t is replaced with a 4-byte timestamp, %s with the backup set number, and %p with the backup piece number. `CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/ora_df%t_s%s_s%p';` Configure RMAN to back up the control file after each backup. `CONFIGURE CONTROLFILE AUTOBACKUP ON;` Configure RMAN to write controlfile autobackups to the /backup directory.br> `CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/ora_cf%F';` Excludes tbs_exclude from full database backups. NOEXCLUDE can be specified with the BACKUP command to override this configuration. `CONFIGURE EXCLUDE FOR TABLESPACE tbl_exclude;` NOTES: If you want backups to go to tape, refer to the configuration section in case2.rcv on how to configure tape backups. However in case of disaster recover if RMAN is not connected to recovery catalog, you will have to manually allocate all channels where backups were taken. - Use the SHOW ALL command to see your current configuration settings. - Save the database id displayed in the RMAN output if you are taking RMAN backups in nocatalog mode or database name is ambiguous in recovery catalog. The database id is required during disaster recovery (See Section 5). You will see the database id in RMAN output on connecting to target database like : `connected to target database: INVENTORY (DBID=1670954628)`
BACKUP Since you are operating the database in no-archivelog mode, only the following kinds of backups are allowed: - whole database backups when the database is cleanly closed and the instance is mounted - tablespace backups of tablespaces that are offline clean or read only The following scenario assumes that you want to take one full database backup every week, and one incremental database backup every day. The backup cycle starts on Friday. A full backup is taken on Friday, and an incremental backup is taken every other day. The retention policy of REDUNDANCY 5 applies only to full (not incremental) backups, so the combination of that policy and this backup schedule ensures that you can restore to any incremental backup time for the last 5 weeks. Start script for backup cycle The following commands are run each Friday to start the backup cycle. The steps are: - Re-start the database to perform crash recovery, in case the database is not currently open, and was not shut down consistently. The database is started in DBA mode so that normal users cannot connect. - Shut down with the IMMEDIATE option to close the database consistently. - Startup and mount the database. - Backup database with incremental level 0. - Open database for normal operation. `STARTUP FORCE DBA; SHUTDOWN IMMEDIATE; STARTUP MOUNT; BACKUP INCREMENTAL LEVEL 0 DATABASE FILESPERSET 4; ALTER DATABASE OPEN;` If the above backup fails for any reaon, you can use the NOT BACKED UP SINCE option on the BACKUP command (9i restartable backup feature) to continue from the point of failure. The small value of FILESPERSET is good for restartable backups. However you should note that smaller FILESPERSET produces more backup sets. To re-start from the point of failure, run following commands: `BACKUP INCREMENTAL LEVEL 0 DATABASE FILESPERSET 4 NOT BACKED UP SINCE TIME 'SYSDATE-1'; ALTER DATABASE OPEN;` Script for other days of the backup cycle The following commands can be run from Saturday through Thursday to take cumulative incremental backups. They are same as in section 2.1, except that LEVEL 1 is specified on BACKUP command. The steps are the same as in section 2.1, except that the options LEVEL 1 CUMULATIVE indicate that only the blocks that have changed since the last level 0 backup will be backed up. If the CUMULATIVE option was not specified, then only the blocks that have changed since the last level 1 backup will be backed up. The advantage of a cumulative backup is that only one incremental backup ever needs to be applied during recovery. `STARTUP FORCE DBA; SHUTDOWN IMMEDIATE; STARTUP MOUNT; BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE FILESPERSET 4; ALTER DATABASE OPEN;` Taking backups of readonly tablespaces The database does not have to be closed to back up a readonly tablespace. The following command can be used to backup a readonly tablespace. BACKUP TABLESPACE read_only_tablespace_name;
RESTORE VALIDATION The following commands can be run any time to check if RMAN is capable of restoring database/tablespace using existing backups. # check if database can be restored `RESTORE DATABASE VALIDATE;` # check if tablespace is restorable `RESTORE TABLESPACE read_only_tablespace_name VALIDATE;`
MAINTENANCE COMMANDS Basic steps for maintenance are: Verify all backups on backup media are intact `CROSSCHECK BACKUP OF DATABASE;` - Display a list of files that need to be backed up based on the retention policy. For this case study, files that don't have at least 5 backups will be reported. `REPORT NEED BACKUP;` Delete un-necessary backups. This command deletes backups based on the retention policy. For this case study, all backups older than the 5 most recent backups of each datafile will be deleted. `DELETE OBSOLETE;` get complete list of existing backups `LIST BACKUP SUMMARY;`
RESTORE AND RECOVERY In case of any user error or media failure you would have to do complete database recovery. However using the SET UNTIL command, it is possible to recover to different points in time when incrementals were taken. Because redo logs are not archived, only full and incremental backups are available for restore and recovery. It is assumed that you have all the configuration files like the server parameter file (spfile - equivalent of init.ora in 9i), tnsnames.ora, and listener.ora in the appropriate places, and that you can startup the Oracle instance in nomount mode and connect from RMAN to the target instance. The steps are: - If not using a recovery catalog, or if the database name is ambiguous in, the recovery catalog you need to start RMAN without TARGET option and set the dbid before restoring the controlfile from autobackup. - Startup database in nomount mode (you should have restored initialization files for database, and listener files (only if connecting over SQLNET)). - restore controlfile. - restore all database files. Use CHECK READONLY, to make sure all read-only files are correct. If not RMAN will restore them. - apply all incrementals. - open database with resetlogs mode to re-create online logs. `SET DBID <database_id>; CONNECT TARGET <target_connect_string>; STARTUP NOMOUNT; RUN { # uncomment the SET UNTIL command to restore database to the # incremental backup taken three days ago. # SET UNTIL TIME 'SYSDATE-3'; SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/ora_cf%F'; RESTORE CONTROLFILE FROM AUTOBACKUP; ALTER DATABASE MOUNT; RESTORE DATABASE CHECK READONLY; RECOVER DATABASE NOREDO; ALTER DATABASE OPEN RESETLOGS; }`

RMAN Demo 2
Target Database Running in Archive Log Mode
This case study can be used as basis for developing your own backup, maintenance, restore, and recovery scripts for a single instance database running in archivelog mode. The examples provided in this case study will use a disk area (/backup directory) to hold the most recent one week of backups, in order to expedite backup/restore operations. The size of this area may vary depending on database size, redo generated, etc. If you want all backups to go to tape, remove DEVICE TYPE DISK option from the BACKUP commands given in this case study. Only the incremental backups are stored on disk for one week. The level 0 backup goes immediately to tape. This means that RMAN will always have to read tape for recovery. NOTES: You should not run all of the commands in this file in a single RMAN session. Rather, the various sections in this file should be separated into individual RMAN scripts which can be run to configure, backup, restore, and recover the database. Organization: This case study is divided into the following sections: # 1. Configuring RMAN parameters # 2. Backup # - start script for backup cycle # (full database backup and archivelog backups) # - script for other days of backup cycle # (cumulative incremental level 1 backups and archivelog backups) # 3. Restore validation # - verify that the database/tablespace is restorable # 4. Maintenance commands # 5. Restore and Recovery # - Datafile recovery # - Tablespace recovery # - Controlfile recovery # - Block recovery # - Disaster recovery # - Database Point-in-time recovery # # How to run the file containing RMAN commands: # Here is an example of how to run the file that contains RMAN commands: rman target internal/pwd@prod1 catalog rman/rman@rcat cmdfile command.rcv CONFIGURATION There are various parameters that can be used to configure RMAN operations to suit your needs. Some of the things that you can configure are: - the recovery window, to keep backups so that it is possible to recover the database to any point in time during last X days. - the number of server processes that can do backups/restore operations in parallel - default device type for backups - the directory where on-disk backups will be stored This case study assumes that you - have 1 tape drive - want parallelization for disk to two and for tape to one - want to be able to recover your database to any point in time during the last 30 days - want all full database backups to go only to tape - want to keep incrementals on disk for seven days - want to leave archivelogs on disk for seven days - want one copy of each archivelog backup saved on tape - want to back up archivelogs once per day - want to exclude tablespace tbl_exclude from database backups and restores because it is easier to re-create it than to restore and recover it. It should be noted that configuration setting is done just once, and these settings are used by RMAN to perform all subsequent backup, restore, recovery, and maintenance operations. Configure backups to be written to tape, via a 3rd-party media management product. `CONFIGURE DEFAULT DEVICE TYPE TO SBT;` If the media manager requires an RMAN PARMS string, configure it here. The media manager documentation will specify whether this configuration is needed. `CONFIGURE CHANNEL DEVICE TYPE SBT PARMS '<media manager parameter string>';` Configure the number of server processes (channels) that write backups to DISK. You can delete these three lines if you want to only back up to tape. `CONFIGURE DEVICE TYPE DISK PARALLELISM 2; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/ora_df%t_s%s_s%p'; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/%F';` Set the retention policy to a recovery window of 30 days. This ensures that RMAN retains all backups needed to recover the database to any point in time in the last 30 days. You can use the DELETE OBSOLETE command to delete backups that are no longer required by the retention policy. To exclude a backup from consideration by the policy, you can use KEEP option with the BACKUP command. `CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;` Enable the autobackup feature to backup the controlfile after each database or archivelog backup. `CONFIGURE CONTROLFILE AUTOBACKUP ON;` Enable the backup optimization feature introduced in 9i to make sure that RMAN won't backup an archivelog or datafile if there already exists a backup of that file. The FORCE option can be used to override optimization on a specific BACKUP command. `CONFIGURE BACKUP OPTIMIZATION ON;` # Exclude tbs_exclude from full database backups. NOEXCLUDE can be specified with backup command to override this configuration. CONFIGURE EXCLUDE FOR TABLESPACE tbl_exclude; # IMPORTANT: Save the database id displayed in the RMAN output if you are # operating RMAN backups in nocatalog mode, since it is required during # disaster recovery. You will see the database id in output from RMAN on # connecting to target database like: # # connected to target database: INVENTORY (DBID=1670954628) # Use the SHOW ALL command to see the current configuration settings.
BACKUP Running database in archivelog mode provides following advantages high availability, i.e., database is available during backups. - point in time recovery within recovery window for database/tablespace. You can also follow the procedure given in case1.rcv for taking consistent backups. Only disadvantage of taking consistent backups is that you have to close database cleanly, and open in restricted mode. Hence database is not available for general use during consistent backup. Following scenario assumes that you want to take one full database once a week, doing every day incrementals. Backup cycle starts on friday, i.e., every friday full backup, and on other days incrementals. # Section 2.1 - Start script for backup cycle # ------------------------------------------- # The following commands are run each Friday to start the backup cycle. # The steps are: # - Take an incremental level 0 backup of the database. A level 0 backup is # a complete backup of the entire file which can be used as the basis # for a subsequent incremental backup. # - Backup all archivelogs that have not already been backed up. # - Delete on-disk archivelogs older than seven days. BACKUP INCREMENTAL LEVEL 0 DATABASE FILESPERSET 4; BACKUP ARCHIVELOG ALL; DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7'; If the above backup fails for any reaon, you can use the NOT BACKED UP SINCE option on the BACKUP command (9i restartable backup feature) to continue from the point of failure. The small value of FILESPERSET is good for restartable backups. However you should note that smaller FILESPERSET produces more backup sets. Use the following commands to re-start backups after a failure: BACKUP INCREMENTAL LEVEL 0 DATABASE FILESPERSET 4 NOT BACKED UP SINCE TIME 'SYSDATE-1'; BACKUP ARCHIVELOG ALL; DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7'; # Section 2.2 - script for other days of backup cycle # ----------------------------------------------------- # The following commands can be run from Saturday through Thursday to take # cumulative incremental backups. # The steps are: # - delete incrementals on disk that were taken before 7 days. # - take differential incremental backup of complete database. # - copy incrementals to tape. # - backup all archiveogs that are not backed up. # - deletes any copies of archivelog on disk older than 7 days. DELETE BACKUP COMPLETED BEFORE 'SYSDATE-7' DEVICE TYPE DISK; BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DEVICE TYPE DISK DATABASE FILESPERSET 4; BACKUP BACKUPSET ALL; # copies backups from disk to tape BACKUP ARCHIVELOG ALL; DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7'; CONCEPT NOTE ON CUMULATIVE INCREMENTAL BACKUPS: Cumulative incremental level 1 backups will backup the blocks that changed since the last level 0 backup. Incremental backups are similar in function to archived logs and RMAN uses them in favor of archived logs during recovery. If the CUMULATIVE option was not specified, then only the blocks that have changed since the last level 1 backup will be backed up. The advantage of a cumulative backup is that only one incremental backup ever needs to be applied during recovery. As in section 2.1, you can use the NOT BACKED UP SINCE option with the BACKUP command (9i re-startable backup feature) to continue from the point of failure. Use the following commands to re-start backups after a failure: DELETE BACKUP COMPLETED BEFORE 'SYSDATE-7' DEVICE TYPE DISK; BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DEVICE TYPE DISK DATABASE FILESPERSET 4 NOT BACKED UP SINCE TIME 'SYSDATE -1 '; BACKUP BACKUPSET ALL; # copies backups from disk to tape BACKUP ARCHIVELOG ALL; DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7';
RESTORE VALIDATION The following commands can be run any time to check if RMAN is capable of restoring the database/tablespace using existing backups. check if database can be restored RESTORE DATABASE VALIDATE; check if tablespace tst_tbs can be restored RESTORE TABLESPACE tst_tbs VALIDATE; check if controlfile can be restored RESTORE CONTROLFILE VALIDATE; check if archivelogs for the past two weeks can be restored RESTORE ARCHIVELOG FROM TIME 'SYSDATE-14' VALIDATE;
MAINTENANCE COMMANDS The following commands can be run any time for maintenance of backups. Verify that all backups which RMAN thinks are stored by the third-party media manager still exist, and generate a report of backups that need to be taken to satisfy the retention policy. CROSSCHECK BACKUP; REPORT NEED BACKUP; Delete backups that are no longer needed to satisfy the retention policy. Since we have set the retention policy to a recovery window of 30 days, any datafile backups (generated without the KEEP option) not required to recover within 30 days are deleted. After deciding which datafile backups are no longer needed, RMAN can then decide which archivelog backups are no longer needed. Archivelog backups are not needed if they are older than ANY existing datafile backup. DELETE OBSOLETE; get complete list of existing backups LIST BACKUP SUMMARY;
RESTORE AND RECOVERY Section 5.1 - Datafile recovery This section assumes that datafile 5 has been damaged and needs to be restored and recovered, and that the current controlfile and all other datafiles are intact. The database is open during the restore and recovery. The steps are: - offline the datafile that needs recovery - restore the datafile from backups - apply incrementals and archivelogs as necessary to recover. - make online recovered datafile RUN { SQL 'ALTER DATABASE DATAFILE 5 OFFLINE'; If you want to restore to a different location, uncomment the following command. # SET NEWNAME FOR DATAFILE 5 TO '/newdirectory/new_filename.f'; RESTORE DATAFILE 5; # If you restored to a different location, uncomment the command below to # switch the controlfile to point to the file in the new location. # SWITCH DATAFILE ALL; RECOVER DATAFILE 5; SQL 'ALTER DATABASE DATAFILE 5 ONLINE'; } Section 5.2 - Tablespace recovery This section assumes that tablespace tbs_5, containing datafiles 5, 6, and 7 has been damaged and needs to be restored and recovered, and that the current controlfile and all other datafiles are intact. The database is open during the restore and recovery. The steps are: - Offline the tablespace that needs recovery. - Restore the tablespace from backups. - Apply incrementals and archivelogs as necessary to recover. - Online the recovered tablespace. RUN { SQL 'ALTER TABLESPACE TBS_5 OFFLINE'; If you want to restore to a different location, uncomment the following commands. # SET NEWNAME FOR DATAFILE 5 TO '/newdirectory/new_filename_for_5.f'; # SET NEWNAME FOR DATAFILE 6 TO '/newdirectory/new_filename_for_6.f'; # SET NEWNAME FOR DATAFILE 7 TO '/newdirectory/new_filename_for_7.f'; RESTORE TABLESPACE TBS_5; If you restored to different locations, uncomment the commands below to switch the controlfile to point to the files in their new locations. # SWITCH DATAFILE ALL; RECOVER TABLESPACE TBS_5; SQL 'ALTER TABLESPACE TBS_5 ONLINE'; } Section 5.3 - Controlfile recovery Oracle bly recommends that you specify multiple controlfiles, on separate physical disks and controllers, in the CONTROL_FILES initialization parameter. - If one copy is lost due to media failure, copy one of the others over the lost controlfile and restart the instance. - If you lose all copies of the controlfile, you must re-create it using the CREATE CONTROLFILE sql command. You should use RMAN to recover a backup controlfile only if you have lost all copies of the current controlfile, because after restoring a backup controlfile, you will have to open RESETLOGS and take a new whole database backup. This section assumes that all copies of the current controlfile have been lost, and that all initialization parameter files, datafiles and online logs are intact. Ensure you set your NLS_LANG environment variable. e.g. in unix (csh): > setenv NLS_LANG american_america.we8dec Start RMAN without the TARGET option, and use the following commands to restore and recover the database: SET DBID <database_id>; # use database id from RMAN output as # explained in Section 2.1, # not required if using recovery catalog CONNECT TARGET <target_connect_string>; STARTUP NOMOUNT; RUN { # You need to allocate channels if not using recovery catalog. Media # manager parameter string must be same as in Section 1. ALLOCATE CHANNEL FOO TYPE SBT PARMS '<media manager parameter string>'; ALLOCATE CHANNEL FOO2 TYPE DISK; RESTORE CONTROLFILE FROM AUTOBACKUP; ALTER DATABASE MOUNT; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; # You must take a new whole database backup after resetlogs (as # in Section 2.1), since backups of previous incarnation are not easily # usable. } # Section 5.4 - Block recovery # Block recovery can be used to recover a corrupted block(s). It is not # intended to recover complete datafile. # Usually, the corruption is reported in alert logs, trace files or # results of SQL commands # # For example, as a result of SQL command # SQL> select * from emp; # #NAME #ORA-01578: ORACLE data block corrupted (file # 7, block # 233) #ORA-01578: ORACLE data block corrupted (file # 7, block # 235) #ORA-01578: ORACLE data block corrupted (file # 4, block # 101) #ORA-01110: data file 7: '/oracle/dbs/tbs_07.f' #ORA-01110: data file 4: '/oracle/dbs/tbs_04.f' # Use the following BLOCKRECOVER command to recover the corrupted blocks # listed above: BLOCKRECOVER DATAFILE 7 BLOCK 233, 235 DATAFILE 4 BLOCK 101; # The BLOCKRECOVER command can also be used to repair all corrupted blocks # listed in V$BACKUP_CORRUPTION and V$COPY_CORRUPTION. These views are # populated whenever an RMAN process peforms a complete scan of a file for the # purpose of backing it up, such as with the BACKUP or COPY command. Use the # following command to repair all blocks listed in the V$xxx_CORRUPTION views: # command: BLOCKRECOVER CORRUPTION LIST; Section 5.5 - Disaster recovery # A disaster recovery scenario assumes that you have lost everything. To # perform recovery in this case, you would have to restore initialization # parameters manually. Then use RMAN to restore and recover the database as # described in this section. # # The commands below assume that all initialization parameter files are in # place and the complete directory structure for datafiles is recreated. # # Ensure you set your NLS_LANG environment variable. # e.g. in unix (csh): # > setenv NLS_LANG american_america.we8dec # # Start RMAN without the TARGET option, and use the following commands to # restore and recover the database: SET DBID <database_id>; # use database id from RMAN output as # explained in Section 2.1, # not required if using recovery catalog CONNECT TARGET <target_connect_string>; STARTUP NOMOUNT; RUN { # You need to allocate channels if not using recovery catalog. Media # manager parameter string must be same as in Section 1. ALLOCATE CHANNEL FOO TYPE SBT PARMS '<media manager parameter string>'; ALLOCATE CHANNEL FOO2 TYPE DISK; # Optionally you can use SET NEWNAME and SWITCH commands as described in # Section 5.2 to restore datafiles to a new location. RESTORE CONTROLFILE FROM AUTOBACKUP; ALTER DATABASE MOUNT; RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; # You must take a new whole database backup after resetlogs (as # in Section 2.1), since backups of previous incarnation are not easily # usable. } Section 5.6 - Database Point-in-time recovery # This scenario assumes that all initialization files and the current # controlfile are in place and you want to recover to a point in time # '2001-04-09:14:30:00'. # # Ensure you set your NLS_LANG environment variable. # e.g. in unix (csh): # > setenv NLS_LANG american_america.we8dec STARTUP MOUNT FORCE; RUN { SET UNTIL TIME "TO_DATE('2001-04-09:14:30:00','yyyy-dd-mm:hh24:mi:ss')"; RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; # You must take a new whole database backup after resetlogs (as # in Section 2.1), since backups of previous incarnation are not easily # usable. }

RMAN Demo 3
# DESCRIPTION # This case study outlines the basic steps to perform tablespace # point-in-time recovery (TSPITR) using Recovery Manager. # # The examples in this case study assume that all backups are stored on # disk. However if you have backups on tape and channels are configured as # described in case2.rcv, Section 1, the same procedures will work. # # This case study assumes that # - You want to recover tablespaces TBS1 and TBS2 to the point in time # '2000-APR-01:07:05:30'. # - TSPITR is performed on the same machine as the target database. # - ORACLE_HOME is /oracle. # - ORACLE_SID for the target database is PROD. # - target database files and online logs are in $ORACLE_HOME/dbs/. # - ORACLE_SID for the auxiliary instance is AUX. # - all temporary files (except password file) for the auxiliary # instance are created in $ORACLE_HOME/auxiliary. # # NOTES # You should not run all of the commands in this file in a single RMAN # session. Rather, the various sections in this file should be studied # thoroughly before performing TSPITR. # # MODIFIED (MM/DD/YY) # banand 04/17/01 - re-write case for tablespace point-in-time recovery # banand 04/17/01 - Creation # # Organization: # # This case study is organized into the following sections: # 1. TSPITR usage and restrictions # 2. Resolving referential dependencies # 3. Preparing for TSPITR - setup auxiliary instance # 4. Performing TSPITR # 5. Preparing the target database to use recovered files # 6. Cleaning up the auxiliary instance and temporary files # Section 1 - TSPITR usage and restrictions Section 1.1 - When to do TSPITR TSPITR can be performed: - to recover from an erroneous drop or truncate table operation - to recover a table that has become logically corrupted - to recover from a batch job or DML that has affected only a subset of the database Section 1.2 - Restrictions of TSPITR It should be noted that TSPITR: - cannot recover a dropped tablespace - cannot recover a tablespace that was dropped and recreated with same name - will not recover optimizer statistics; statistics must be recalculated after TSPITR - cannot recover a tablespace containing any of the following object types: - replicated master tables - tables with varray columns - tables with nested tables - tables with external bfiles - snapshot logs - snapshot tables - IOTs - objects owned by SYS (including rollback segments) After TSPITR you should take a new backup of the recovered tablespace(s), since it is not possible to recover using the pre-TSPITR backups. Section 1.3 - RMAN specific restrictions for TSPITR RMAN specific TSPITR restrictions are : - cannot recover partitioned tables unless all partitions are contained in the recovery set - cannot recover tablespaces containing rollback segments
Section 2. Resolving referential dependencies. The main issue to consider when deciding whether or not to proceed with TSPITR is the possibility of application-level inconsistencies between tables in recovered and unrecovered tablespaces due to implicit rather than explicit referential dependencies. You should understand these dependencies and have means to resolve any possible inconsistencies before proceeding. Oracle provides the TS_PITR_CHECK view to assert that no referential integrity constraints will be broken after TSPITR. If this view returns rows when queried then the reason should be investigated and resolved. Only when TS_PITR_VIEW returns no rows TSPITR will be able to proceed (since this view is checked by imp/exp utilities called by RMAN during TSPITR). All actions taken at this stage should be noted in order that these relationship can be rebuilt after TSPITR is complete. You should check view TS_PITR_OBJECTS_TO_BE_DROPPED to see which objects will be lost after TSPITR. If you want certain object listed by this view, then TSPITR should not be performed. Run the following queries to prepare for performing TSPITR on TBS1 and TBS2 to time '2000-APR-01:07:05:30':> `"SELECT OWNER, NAME, TABLESPACE_NAME FROM SYS.TS_PITR_OBJECTS_TO_BE_DROPPED WHERE TABLESPACE_NAME IN ('TBS1', 'TBS2') AND CREATION_TIME > TO_DATE('2000-APR-01:07:05:30', 'YYYY-MON-DD:HH24:MI:SS') ORDER BY TABLESPACE_NAME, CREATION_TIME;` `SELECT * FROM SYS.TS_PITR_CHECK WHERE (TS1_NAME IN ('TBS1', 'TBS2') AND TS2_NAME NOT IN ('TBS1', 'TBS2')) OR (TS1_NAME NOT IN ('TBS1', 'TBS2') AND TS2_NAME IN ('TBS1', 'TBS2'));`
Preparing for TSPITR This section shows how to set up the auxiliary instance which will be used by RMAN to perform TSPITR on the desired tablespaces. RMAN will connect to this database using the AUXILIARY connect option. Section 3.1 - Setting up the auxiliary instance Section 3.1.1 - Preparing to connect to the auxiliary instance. The following steps should be followed to connect to the auxiliary instance: - create a password file for the auxiliary instance using the orapwd utility: `orapwd file=/oracle/dbs/orapwAUX password=auxpwd entries=100` Add listener.ora and tnsnames.ora entries so that RMAN can connect to the auxiliary database. Section 3.1.2 - Preparing the parameter file for the auxiliary instance. You can use the production instance parameter file as the basis for the auxiliary instance. However certain parameters like db_block_buffers, shared_pool_size, large_pool_size, enqueue_resources, etc which allocate shared memory can probably be reduced, because the auxiliary instance does not have the same memory requirements as the production instance. The following parameters must be set for the auxiliary instance: db_name must be the same as in the production instance `db_name=PROD` control_files must be different than the production instance `control_files=/oracle/auxiliary/ctl.f` lock_name_space must be different than the production instance `lock_name_space=_PROD` db_file_name_convert and log_file_name_convert are used only in the parameter file of the auxiliary instance. They establish the rules that are used to convert the datafile and log file names from the production to the auxiliary database. Note that starting in Oracle9i, more than one pair of substitutions can be specified in both of these parameters, which allows more flexibility in converting file names. Use the RMAN SET NEWNAME command to convert any file names that cannot be converted with the xxx_file_name_convert parameters. `db_file_name_convert=('/dbs/', '/auxiliary/') log_file_name_convert=('/dbs/', '/auxiliary/')` # log_archive_dest_n and log_archive_format can be the same as the target instance `log_archive_dest_1='LOCATION=/oracle/log' log_archive_format=r_%t_%s.arc` It is important to note that ALL controlfiles, online logs, and datafiles must have different names at the auxiliary instance than they have at the production instance, otherwise RMAN may restore files to those locations, and overwrite the production files. Use the control_files, db_file_name_convert, and log_file_name_convert parameters to make sure that the files at the auxiliary instance all have different names. Section 3.1.3 - Starting the auxiliary instance You should start the auxiliary instance in nomount mode before performing TSPITR. You can connect using SQLPLUS and start the auxiliary using the following commands: CONNECT sys/syspwd@auxiliary_db_connect_string as sysdba; STARTUP PFILE=/oracle/auxiliary/initAUX.ora NOMOUNT;
Performing TSPITR using RMAN The auxiliary database must be in nomount state and the target instance must be mounted or open state to perform TSPITR. The steps in RMAN TSPITR are: - connect to auxiliary instance - connect to target database - connect to recovery catalog (optional) - recover tablespace TBS1 and TBS2 `CONNECT AUXILIARY <sys@auxiliary_db_connect_string> CONNECT TARGET <sys@target_db_connect_string> CONNECT CATALOG <catalog_db_user_connect_string> RUN { # optionally, use SET NEWNAME here for file name translation # SET NEWNAME FOR DATAFILE 1 TO '/oracle/auxiliary/file1.f' # SET NEWNAME FOR DATAFILE 2 TO '/oracle/auxiliary/file2.f' RECOVER TABLESPACE TBS1, TBS2 UNTIL TIME "TO_DATE('2000-APR-01:07:05:30', 'YYYY-MON-DD:HH24:MI:SS')"; }` All the recovered tablespaces will be OFFLINE in target database on successful execution of RECOVER command. If the RECOVER command fails, then after resolving the error you can re-execute the commands. If export fails due to lack of temporary space, you can create a temporary tablespace. Search for tspitr_7 in /oracle/rdbms/admin/recover.bsq and see comments to create temporary tablespace. If import fails because of import tables not existing, you can run CATEXP.SQL on target database to create import schema.
Preparing the target database to use the recovered tablespaces After the RECOVER command in Section 4 runs successfully, you should backup the recovered tablespaces, because after they are brought online, they can no longer be recovered using backups taken prior to the TSPITR. `CONNECT TARGET sys/syspwd@target_db_connect_string; BACKUP TABLESPACE TBS1, TBS2; SQL 'ALTER TABLESPACE TBS1, TBS2 ONLINE';`
Cleanup auxiliary instance The auxiliary instance is not usable after successful completion of TSPITR. This instance must be cleaned using following steps: - Connect to the auxiliary instance as explained in Section 3.1.3 - mount the database using 'ALTER DATABASE MOUNT CLONE DATABASE' - Delete the temporary files restored by RMAN when performing TSPITR. You can use following queries to list them: `SELECT d.name FROM gv$datafile d, gv$tablespace t WHERE d.ts#=t.ts# AND status in ('SYSTEM', 'ONLINE') AND t.name not in ('TBS1', 'TBS2'); SELECT member FROM gv$logfile; SELECT name FROM gv$controlfile;` - Shutdown the auxiliary instance and delete the above files. All these files in this case should be in the /oracle/auxiliary directory. - You can also delete initAUX.ora and orapwAUX

RMAN Demo 4
# The following script creates a duplicate database that you can use # for testing purposes. This scenario assumes: # - You wish to duplicate the target database to a new database # named newdb. # - The target database is mounted or open. # - The auxiliary instance is started in NOMOUNT state. # - The INIT.ORA file of the duplicate database must contain: # - DB_NAME = newdb # - CONTROL_FILES = ... (see script) # - The INIT.ORA file of the duplicate database can also contain: # - DB_FILE_NAME_CONVERT = ... (see script) # - LOG_FILE_NAME_CONVERT = ... (see script) # - Any other parameters required by the auxiliary database. # # The following script creates a duplicate database using the most recent # backup. After the DUPLICATE command has finished succesfully, # you can register the duplicate database (if using a recovery catalog) # and perform backups as with any other database. # # Make sure to set your NLS_LANG and NLS_DATE_FORMAT environment variables. # You can set these values to whatever you wish. The UNIX example # below keeps the date format to the standard date format used # for recovery: # # %> setenv NLS_LANG AMERICAN # %> setenv NLS_DATE_FORMAT 'YYYY-MM-DD:hh24:mi:ss' # # # Connect to RMAN and run the script by executing the following at # the O/S command line # (a single-line command is shown here on multiple lines for the # sake of clarity): # rman # TARGET # <target_userid</<target_password>@<target_net_service_name> # CATALOG # <catalog_userid>/<catalog_password>@<catalog_net_service_name> # AUXILIARY # <auxiliary_userid>/<auxiliary_password>@<auxiliary_net_service_name> # @case4.rcv # LOG case4.log # # For more information about the commands in this script, see the "Recovery # Manager Command Syntax" in the Oracle 8i Backup and Recovery Guide. # For a description of the procedures for creating a duplicate database, # see the chapter "Creating a Duplicate Database." RUN { # The target database can be mounted with the following command # if not already opened or mounted: # STARTUP MOUNT; # By default the DUPLICATE command will try to create the duplicate database # using the most recent backup of the target database. If you wish to # recover the duplicate database to a non-current time issue a SET UNTIL # command to speceify the time. # SET UNTIL TIME '1998-10-31:14:30:00'; # There are several ways to convert the filenames for the duplicate # database. For a complete account, see the chapter "Creating a # Duplicate Database" in the Oracle8i Backup and Recovery Guide. Note # the following guidelines: # (1) If the duplicate database is in the same host as the target, # and the target datafiles cannot be transformed with # DB_FILE_NAME_CONVERT rule from the INIT.ORA file of the # duplicate database, then issue a SET NEWNAME command for each # datafile that cannot be converted automatically. # # (2) If you are connected to a recovery catalog database and have issued # SET AUXNAME commands for some datafiles, the DUPLICATE command # will use the AUXNAME value. Disable the use of the AUXNAME # with the command: SET AUXNAME FOR DATAFILE ... TO NULL; # # (3) When the duplicate database is in a different host from the # target database, the same disk structure is present at the new # host, and you want to keep the same datafile names, then use # the NOFILENAMECHECK clause # SET NEWNAME FOR DATAFILE 1 TO '?/dbs/newdb_datafile1.dbf'; # SET NEWNAME FOR DATAFILE 2 TO '?/dbs/newdb_datafile2.dbf'; # ... # SET NEWNAME FOR DATAFILE 10 TO '?/dbs/newdb_datafile10.dbf'; # ... # You must allocate at least one auxiliary channel needs before issuing # the DUPLICATE command. The channel type (DISK or SBT) must match # the media where the backups of the target database are stored. If you # allocate TYPE DISK, then the more channels that are allocated, the # faster the duplicate process will be. For other types the number of # channels should be limited to the actual number of devices available # for the operation: ALLOCATE AUXILIARY CHANNEL ch1 TYPE DISK; # ALLOCATE AUXILIARY CHANNEL ch2 TYPE SBT; # newdb is the name of the auxiliary database as specified in the # INIT.ORA parameter DB_NAME: DUPLICATE TARGET DATABASE TO newdb; # The LOGFILE clause is needed if the online logs cannot be # automatically generated from the target datafile names after # applying the LOG_FILE_NAME_CONVERT parameter of the # auxiliary database. # for example, for two groups each with two members of 512K bytes: # LOGFILE # GROUP 1 ('?/dbs/new_g1_l1.dbf', # '?/dbs/new_g1_l2.dbf') SIZE 512K, # GROUP 2 ('?/dbs/new_g2_l1.dbf', # '?/dbs/new_g2_l2.dbf') SIZE 512K # If restoring to a host with the same structure as the target host, use the # NOFILENAMECHECK clause: # NOFILENAMECHECK # Note that read-only datafiles are duplicated by default. If this is not # desired, use the SKIP READONLY clause: # SKIP READONLY; # release the auxiliary channel RELEASE CHANNEL ch1; # RELEASE CHANNEL ch2; }

RMAN Demo 5: Flashback Recovery Area
SELECT SUM(bytes) FROM gv$datafile; SELECT SUM(blocks * block_size) BYTES FROM gv$archived_log WHERE completion_time > SYSDATE-1; SELECT SUM(blocks * block_size) BYTES FROM gv$archived_log WHERE status = 'A'; ALTER SYSTEM SET db_recovery_file_dest_size = 2237460480 SCOPE=BOTH; ALTER SYSTEM SET db_recovery_file_dest = '/app/oracle/...' SCOPE=BOTH;

RMAN Demo 6
RMAN> backup incremental level 0 tag 'BU1_LEV0' database; RMAN> backup incremental level 1 for recover of copy tag 'BU1_LEV0' database; RMAN> recover copy of database with tag 'BU1_LEV0';

RMAN Demo 7: Complete Failure
RMAN> backup incremental level 0 tag 'BU1_LEV0' database; RMAN> backup incremental level 1 for recover of copy tag 'BU1_LEV0' database; RMAN> recover copy of database with tag 'BU1_LEV0';

RMAN Demo 8: Large Database Recovery
`-- the imagefile copies must be in the FRA to be found. RMAN> switch datafile 4 to copy; RMAN> alter database datafile 4 online;`

Demo 9
-- has an issue called out by Brian Pace ORACLE_HOME=/u01/app/oracle/product/11.2.0 export ORACLE_HOME ORACLE_SID=UPGR export ORACLE_SID PATH=$PATH:$ORACLE_HOME/bin export PATH DD='date +%d%m%y' RMAN_BACKUP=/tmp/backup rman target / log=$RMAN_BACKUP/rman_fullbackup_${DD}.log <<! run { allocate channel d1 type disk format '/tmp/backup/df_t%t_s%s_p%p'; allocate channel d2 type disk format '/tmp/backup/df_t%t_s%s_p%p'; crosscheck backup ; delete expired backup; setlimit channel d1 kbytes 2097150 maxopenfiles 32 readrate 200; setlimit channel d2 kbytes 2097150 maxopenfiles 32 readrate 200; backup as compressed backupset incremental level = 0 (database); release channel d1; release channel d2; sql 'alter system archive log current'; allocate channel d1 type disk; allocate channel d2 type disk; crosscheck archivelog all; backup filesperset 5 format '/tmp/backup/arch_df_t%t_s%s_p%p' archivelog all delete input; release channel d1; release channel d2; } !