Monday, October 22, 2007

Successful DR/BC/BR using RMAN

Anthony D Noriega, MSCS, MBA, OCP, BSSE, Independent Oracle Consultant, ADN


While RMAN is the most commonly used method of Oracle backup, either standalone or in conjunction with other backup and storage technologies, few studies have been made in relation to backup duration, consistency, and reliability. This study focuses on metrics and statistics in an effort to derive some consensus in relation to factors affecting RMAN backup and restore duration, reliability, and consistency, such as database size, channel speed, device type, database infrastructure and architecture, and various others associated with the concurrency of events. The study expands to standard and point-in-time recovery scenarios, with an outlook in RMAN’s positioning in the database Business Continuity (BC) and Disaster Recovery (DR) markets.


RMAN has proven to be a consistent and resilient database backup and recovery management tool, especially, when properly used. Likewise, companies that have used RMAN from previous releases have learned enough to best utilize it, with or without the recovery catalog. The incremental enhancements provided in Oracle versions 9i and 10g. In general, it is expected that when benchmarking comparable Oracle9i and Oracle10g databases, in terms of table contents and overall density, that Oracle10g RMAN backups and related restores will run faster than Oracle9i, in particular, in 10g features have been enabled with a speed-up seeking goal. Although an actual and native Oracle10g performance improvement holds over Oracle9i releases, the customization of Oracle10g features could further enhance backup and recovery performance and reliability over previous releases.


The RMAN metric problem consists of the following considerations:
• Determining the window of time and related duration to perform a backup
• Establishing a window of time and related duration to perform the corresponding restore with all the relevant scenario considerations
• Establishing a cost analysis in relation to the appropriate version for any process, namely, backup, recovery, or cloning.
• Creating a policy framework in order to consistently maintain archived redo log files in backup sets, or available accordingly in the file system. This extremely practical for recovery processes independently from whether backup set or image backups are being used. Neglecting this policy accounts for a large percent of causes for restore failures, backup invalidation, and other related inconsistencies.
• Utilizing available features and capabilities such as Block Change Tracking, control file auto-backup, native backup compression, or point-in-time recovery when appropriate.
• Establishing a historic log in connection with the above policy framework to correlate backup/restore metrics with some factorial considerations such as availability of resources, and other IT configuration management concerns.


The experimental environments discussed in this study are fundamentally Unix-based environments, yet other environments were partly considered both with recorded information and for qualitative observation in relation to the quantitative analysis involved.


The experiments and studies presented are based on dedicated architectures using Oracle9i and 10g instances with projection factors from 9i over 10g versions time improvements. The main most important factor to be considered is block change tracking, since most performance correlations prevail. Obviously, there is a consideration inherit to Oracle10g, based on its improved performance over previous releases. This is particularly true when using incremental backups.


In general, the time to restore an RMAN backup varies due to various factors, including –but not limited to- device and computing resources availability, and network issues, if applicable. However, statistically the restore time is usually commensurate with the backup time, and usually longer if a backup verification policy is in practice. The RMAN restore time increment is usually from a small percent of the backup time without the recovery catalog and up to nearly doubling of that time when both the recovery catalog and verification process is put in place. However, these statements are all relative under the Oracle10g perspective when using Block Change Tracking, which can significantly minimize this overhead.


The cases presented here include general backup with and without a recovery catalog, and a database point-in-time recovery without a catalog, with some general observations on restore cases.


The following table summarizes a list of data related to RMAN backup sizes and durations for a set of RMAN backup on different databases without using the recovery catalog (Table 1). This information is reorganized and presented once more on Table 2.

RMAN Backup Size and Duration Statistics

Instance Name Host Name RMAN Backup Size Range Duration Range
Prd1 Host1 4.0GB-7.0GB 2 to 7 minutes
Prd2 Host2 3.5GB-4GB 2 to 4 minutes
Dev1 Host3 1.8GB-2.0GB 2 to 3 minutes
Dev2 Host4 5.0GB-6.0GB 5 to 9 minutes
QA1 Host5 23.0GB-24.0GB 28 to 29 minutes

Table 1. RMAN Backup Duration for Oracle Instances Studied (without a Recovery Catalog)

This information is realigned with further details, as presented in the next table. :

Instance Name Host Name Avg DB Size (GB) Rman Backup
Min Size (GB) Rman Backup
Max Size (GB) Min Duration Max Duration
Prod1 Host1 256 4.0 7.0 2 7
Prod2 Host2 198 3.5 4.0 2 4
Dev1 Host3 128 1.8 2.0 2 3
Dev2 Host4 248 5.0 6.0 5 9
Qa1 Host5 300 23.0 24.0 28 29

Table 2. Enhanced Detail for RMAN Backup Duration for Oracle Instances Studies (without a Recovery Catalog)

The RMAN backup restore time without a recovery catalog is about the same as the backup time itself with a slight percent trend to take longer based on the scenario where the restore takes place. Therefore, in consideration to the size of the backup, the restore table is essentially equivalent to the backup table exhibited, since duration discrepancies are as granular as fractions of a second and only up to a few seconds for this case, in particular.

Instance Name Host Name MinSize (GB) MaxSize (GB) MinTime (m) MaxTime (m)
Prod1 Host1 4.0 7.0 2 7
Prod2 Host2 3.5 4 2 4
Dev1 Host3 1.8 2.0 2 3
Dev2 Host4 5.0 6.0 5 9
Qa1 Host5 23.0 24.0 28 29
Table 3. RMAN Restore Fact Data Table (without a Recovery Catalog)

Exhibit 1. RMAN NOCATALOG Instance-Host vs. Duration Line Chart


The following table consolidates observations made on several database instances using the recovery catalog.
RMAN Backup Size and Duration Statistics
Instance Name Host Name Average Database Size Rman Backup
Min Size (GB) Rman Backup
Max Size (GB) Min Duration
(Minutes) Max Duration
Prd1 Host1 512GB 21 81 55 88
Dv1 Host2 512GB 22 99 65 90
Risk1 Host3 256GB 12 31 45 68
Uat1 Host4 300GB 30 105 45 77
Risk2 Host5 628GB 23.0 121 65 116
Table 4. RMAN Backup Data Summary using the Recovery Catalog

RMAN Backup Size and Duration Statistics with Backup Validation
Instance Name Host Name Average Database Size Rman Backup
Min Size (GB) Rman Backup
Max Size (GB) Min Duration
(Minutes) Max Duration
Prod1 Host1 512GB 21 81 85 128
Prod2 Host2 512GB 22 99 95 135
Dev1 Host3 256GB 12 31 77 102
Dev2 Host4 300GB 30 105 85 105
Qa1 Host5 628GB 23.0 121 97 159

Table 5. RMAN Backup Data Summary using the Recovery Catalog with Backup Validation

The restore table is nearly comparable to that provided by backup with validation, as follows:
RMAN Restore Statistics Using the Recovery Catalog
Instance Name Host Name Average Database Size Rman Backup Min Size (GB) Rman Backup Max Size (GB) (Minutes)
Min Duration (Minutes)
Max Duration
Prod1 Host1 512GB 21 81 81 115
Prod2 Host2 512GB 22 99 90 121
Dev1 Host3 256GB 12 31 72 89
Dev2 Host4 300GB 30 105 77 95
Qa1 Host5 628GB 23.0 121 89 125
Table 6. RMAN Restore Data Summary using the Recovery Catalog


From the entire set, involving both Catalog-based and Catalog-less observations, it is possible derive the following statistical analytic results using Oracle SQL:

Exhibit 2. Some Regression Information Correlating the Average Database Size and the Maximum Backup Duration.

Exhibit 3. Other Regression Metric Analysis

In addition to the observations made by the SQL regression aggregate functions, it is possible to encounter the following correlation among variable with interactions:
• Minimum Duration and RMAN Backup Maximum Size
• Maximum Duration and RMAN Backup Maximum Size
• Maximum and Minimum Duration
• Catalog Option and Minimum Duration
• Catalog Option and Maximum Duration.

Avg DB Size (GB) RMAN Backup Min Size (GB) RMAN Backup Max Size (GB) Min Duration Max Duration Cat Opt
Avg DB Size (GB) 1
RMAN Backup Min Size (GB) 0.672812809 1
RMAN Backup Max Size (GB) 0.850083343 0.856779215 1
Min Duration 0.856536148 0.834302561 0.910370414 1
Max Duration 0.873295324 0.804858853 0.942746843 0.981002475 1
Cat Opt 0.706810637 0.717007196 0.867454307 0.926638071 0.945848466 1
Table 7. Correlation Table Showing Variable Interaction


The following are estimated and adjusted metrics for the Oracle10g versions of this upgraded databases when Block Change Tracking is used, as follows :
• The number of blocks changed as a percent of the total backup, useful with incremental backup policies.
• The global block density in the database being backed up.
• The nature of the block changes in terms of DML transaction types.

The combined effect of these factors should count as a total discount factor in terms of time, in comparison to a conventional backup not using block change tracking.


Although RMAN backup configuration is flexible to accommodate to most scenarios, it is important to understand which parameters apply. In the cases studied, backing up first to disk was the strategy. In all cases, a copy of the database backup was available on disk, while a compressed tape backup was made of the original backup. No compressed backup sets were sent directly to tape. The duration of the overall process varied based on daily database activity and computing resources allocated to a SAN environment and other storage devices involved.
RMAN long session impact is possibly affected by settings of parameters such as FAST_START_MTTR_TARGET or its omission. Similarly, architectural considerations, namely, the usage of an inadequate sizing of the LARGE_POOL parameter or a shared architecture could lead to unconventional results. In the latter case, a dedicate session needs to be set for RMAN to work properly. Other considerations, relate to Oracle10g capabilities to run partial RMAN backup or use explicit options to either run at full speed or running in a controlled fashion within the window of time. On the other hand, in some scenarios, long waits relate to asynchronous RMAN tasks conveying bottlenecks that need to be carefully identified and fixed.

Exhibit 4. A sample RMAN Configuration Without a Recovery Catalog

Exhibit 5. Monitoring RMAN Long Running Jobs for Corrective Action

Exhibit 6. RMAN NOCATALOG Configuration and Database Incarnations

Exhibit 7. Listing RMAN Backup Sets

Exhibit 8. Listing RMAN Archived Logs in Backup Sets


The RMAN Database Point-in-Time Recovery without using a recovery catalog is a special case of an RMAN restore, where determining the point-of-failure is critical to utilizing any type of metrics whether estimated restore time, required resources, such as disk space, and restore strategy based on components to restore. Therefore, it is critical to determine whether the point-in-time to recover is within the backup or outside the backup to restore. If the point of time is after the entire backup set, the solution is trivial and it consists of restoring the entire backup and then applying the required archived redo logs until the desired point in time to recover. The shell provided in the appendix provides both validation and actual point-in-time recovery for the non-trivial case.

Exhibit 9. RMAN DBPITR Duration and Cost Analysis.

Although the study only contemplated the recovery without a catalog, the decision tree provided in the exhibit above does consistently advise about the appropriate way to account for the duration and related costs of the point-in-time recovery. Furthermore, when the point-in-time to recover is found within the backup file, the reduction in time is proportional to the location within the backup. Therefore, point in time locations with older SCNs or timestamps, will have greater reduction than those closer to the last SCN available in the backup. Besides, the DBPITR is not necessarily constrained by the all conditions applying to TSPITR recovery, such as support of snapshot logs, which is simply relative. Also, no auxiliary database is needed for DBPITR However, there are important considerations to properly backing up the archived redo logs within the backup set and maintaining file system copies to attain the desired level of consistency.


Based on the consistency provided by the current medium and large database models studied, and due to the difficulties in testing these statistics and metrics on Very Large Databases (VLDBs), it is still possible to suggest that the same type of correlation among variables are valid at large scale. Similarly, VLDBs tend to have many business and operational constraints with usually reduced windows of time for backups, for which other high-availability solutions are mostly used. Nonetheless, for some of the experiments designed in these case studies, somewhat presented in this paper, the Database, System, and SAN Administrators utilized a comparable level of HARD-based high availability environment, where the SAN acted as a Maximum Availability Architecture (MAA) providing both Clusters and Data Guard capabilities, such as graceful switchover, failover, and controlled switchback. The database sizes were in the threshold of large databases, but could not compare to a VLDB range.
Consequently, this study can serve as a scalable benchmark for more comprehensive corporate studies on VLDB, as part of a disaster recovery and efficient business continuity practice.


The elicitation of requirements involving Disaster Recovery (DR) or Business Continuity (BC) practices require explicit information on backup and recovery times, in an effort to allocate windows of time to periodic utility tasks. Similarly, these durations of time can be greatly associated with an IT infrastructure’s ability to respond to any DR scenario. Therefore, educing requirements for windows of time, and estimating backup and restore durations becomes foundational to DR/BC.
Another important aspect of any RMAN business analysis focused on DR or BC practices needs to allocate the technical and human resources to perform a large number of quality assurance (QA) and tuning tasks, beyond any required coding or automation. The QA tasks can involve, but are not limited to, backup validation, backup and restore timeliness, shell scripts reliability and robustness through different platform configurations , scheduling, source saving, documentation, and other relevant tasks.


The RMAN metrics cases discussed here corroborate a relationship between backup and database sizes and backup duration regardless of the catalog-related considerations. While this statement is nearly trivial to assert, there are many environmental factors that could partially change its validity. The most interested aspect of the variability study contemplates the minimum and maximum backup duration, whose variance point the number of a certain number of infrastructure and scenario-based factors involved. The Analysis of Variance (ANOVA) presented in the Appendix attempts to explain this variability. Likewise, a two-way ANOVA table with repetitions is presented.
Disaster Recovery and Business Continuity Teams need to strategically plan on the implementation of a comprehensive set of factors, bottlenecks, and time and resource constraints that could make the derived statistics and analysis useful in those IT administrative areas. By doing so, it is at least evident that technical stakeholders have congruently worked towards the appropriate preparedness in the event of a disaster, and are working on a daily basis with a robust DR/BC infrastructure.
Finally, the most important concluding remarks are summarized in the following table:

Feature/Issue Benefit

9i to 10g Congruent Metrics Allows for post-upgrade and multi-version DR/BC time allocation.
Configuration Bottlenecks Initialization parameter configuration as part of OFA-driven architecture can be further optimized in 10g in relation to 9i releases. The overall benefits translate into faster performance and throughput.
Planning and Risk Analysis Using historic backup/restore historic data can lead to overcoming unplanned process and limiting the risk involved.
Block Change Tracking Extremely useful with incremental backups, reduces CPU cycles, and enables faster backups and shorter recovery time.
DBPITR A parallel strategy to Flashbackup database. It is supported by RMAN with or without a recovery catalog.
Backup Time vs. Restore/Recovery Time Although backup and restore times tend to be comparable, having gather data and statistics on duration can enhance robustness and preparedness in DR/BC processes.
Table 8. Concluding Remarks

Instance Name Host Name Avg DB Size (GB) Rman Backup Min Size (GB) Rman Backup Max Size (GB) Min Duration Max Duration 0 = nocat
1 = cat
Cat Opt
Prod1 Host1 256 4 7 2 7 0
Prod2 Host2 198 3.5 4 2 4 0
Dev1 Host3 128 1.8 2 2 3 0
Dev2 Host4 248 5 6 5 9 0
Qa1 Host5 300 23 24 28 29 0
Prd1 Host1 512 21 81 55 88 1
Dv1 Host2 512 22 99 65 90 1
Risk1 Host3 256 12 31 45 68 1
Uat1 Host4 300 30 105 45 77 1
Risk2 Host5 628 23 121 65 116 1
Table 9. Source Data Gathered for Statistical Analysis

Statistics Analytics

Two-way Anova with Repetitions for RMAN NOCATALOG Data

SUMMARY 256 4 7 2 7 Total
Count 2 2 2 2 2 10
Sum 326 5.3 6 4 7 348.3
Average 163 2.65 3 2 3.5 34.83
Variance 2450 1.445 2 0 0.5 4836.133

Count 2 2 2 2 2 10
Sum 548 28 30 33 38 677
Average 274 14 15 16.5 19 67.7
Variance 1352 162 162 264.5 200 12063.12

Count 4 4 4 4 4
Sum 874 33.3 36 37 45
Average 218.5 8.325 9 9.25 11.25
Variance 5374.333 97.4225 102.6667 158.25 146.9167

Source of Variation SS df MS F P-value F crit
Sample 5402.185 1 5402.185 11.75808 0.006449 4.964591
Columns 139856.7 4 34964.18 76.10099 1.9E-07 3.47805
Interaction 7642.138 4 1910.535 4.158358 0.030764 3.47805
Within 4594.445 10 459.4445

Total 157495.5 19

Table 10. Two-Way ANOVA

Entire Set Multi-Regression Analysis for both With and Without the Recovery Catalog
(Maximum Duration is the Independent Variable (Regressand)


Regression Statistics
Multiple R 0.9506126
R Square 0.9036643
Adjusted R Square 0.8458629
Standard Error 16.87026
Observations 9

df SS MS F Significance F
Regression 3 13348.53 4449.509062 15.63394 0.005662277
Residual 5 1423.028 284.605674
Total 8 14771.56

Coefficients Standard Error t Stat P-value Lower 95% Upper 95% Lower 95.0% Upper 95.0%
Intercept -4.9598797 17.78092 -0.278943945 0.791457 -50.66711281 40.74735 -50.6671 40.7473533
256 0.077939 0.068482 1.138093711 0.306659 -0.098099465 0.253977 -0.0981 0.25397749
4 0.0677914 1.087778 0.062320971 0.952722 -2.728425992 2.864009 -2.72843 2.86400873
7 0.589539 0.328242 1.796050497 0.132429 -0.254232257 1.43331 -0.25423 1.4333103


Observation Predicted 7 Residuals Standard Residuals Percentile 7
1 13.067471 -9.06747 -0.679867656 5.555555556 3
2 6.3174165 -3.31742 -0.248735753 16.66666667 4
3 18.245187 -9.24519 -0.693192563 27.77777778 9
4 34.129962 -5.12996 -0.384638181 38.88888889 29
5 84.121175 3.878825 0.290829482 50 68
6 94.800669 -4.80067 -0.359948139 61.11111111 77
7 34.081714 33.91829 2.543150806 72.22222222 88
8 82.357163 -5.35716 -0.401673384 83.33333333 90
9 116.87924 -0.87924 -0.065924613 94.44444444 116

Exhibit 10. Multiple Regression and ANOVA


Exhibit 11. Oracle Analytic Statistics

Exhibit 12. Oracle Analytic Statistics

RMAN> list backup;

List of Backup Sets

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
334 Incr 0 1G DISK 00:00:53 19-NOV-05
Piece Name:
SPFILE Included: Modification time: 03-OCT-05
List of Datafiles in backup set 334
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 0 Incr 51691876 19-NOV-05 /data1/oradata/mgnss/system01.dbf
5 0 Incr 51691876 19-NOV-05 /data1/oradata/mgnss/perfstat01.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
335 Incr 0 2G DISK 00:02:00 19-NOV-05
Piece Name:
List of Datafiles in backup set 335
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
2 0 Incr 51691875 19-NOV-05 /data1/oradata/mgnss/undotbs1.dbf
3 0 Incr 51691875 19-NOV-05 /data1/oradata/mgnss/tools01.dbf
4 0 Incr 51691875 19-NOV-05 /data1/oradata/mgnss/users01.dbf
6 0 Incr 51691875 19-NOV-05 /data1/oradata/mgnss/v7data01.dbf

BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
336 588M DISK 00:00:31 19-NOV-05
BP Key: 336 Status: AVAILABLE Tag: TAG20051119T010713
Piece Name:

List of Archived Logs in backup set 336
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 8945 50427811 18-NOV-05 50429822 18-NOV-05
1 8946 50429822 18-NOV-05 50429825 18-NOV-05
1 8947 50429825 18-NOV-05 50441825 18-NOV-05

1 9244 51974291 21-NOV-05 51976461 21-NOV-05
1 9245 51976461 21-NOV-05 51976464 21-NOV-05

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
350 Full 3M DISK 00:00:01 21-NOV-05
BP Key: 350 Status: AVAILABLE Tag: TAG20051121T010742
Piece Name:
Controlfile Included: Ckp SCN: 51976475 Ckp time: 21-NOV-05



# set -x
## ***********************************************************
## rman sample validat script
## prepared by: Anthony D. Noriega, ADN, Oracle Consultant
## Syntax: r_rval_bkp.ksh $ORACLE_SID $R=1_OR_V=0 $TS $DBID
## Example: r_rval_bkp.ksh devtwbg 1 "'01-JAN-2006 01:01:55'"\
## 1885319376
## After recovery temp tbs file(s) must be added manually
## ***********************************************************
echo $UNTIL_TS
echo '#*******************************'
echo '# Values Read: *'
echo '# $SID='$SID
echo '# $DBID='$DBID
echo '# $OPT:[1=R,0=V] => '$VALOPT
echo '# $UNTIL_TS='$UNTIL_TS
echo '# *'
echo '#******************************'
sleep 10
export ORATAB=/var/opt/oracle/oratab
i=`cat $ORATAB|grep -v "^#"|grep $ORACLE_SID`
ORACLE_HOME=`echo $i | cut -d: -f2`;
DT=`date '+%Y%m%d_%H%M'`
MoDir=`date +%Y%m`
PATH=$ORACLE_HOME/bin:/bin:/usr/bin:/usr/sbin:/etc;export PATH
INSTCOUNT=`ps -ef|fgrep $SID|fgrep smon|grep -v grep|wc -l`

if [[ ! -d ${LOGDIR} ]]
chown oracle:dba ${LOGDIR}
chmod 755 ${LOGDIR}
echo 'Directory already exists'
mkdir -p ${LOGDIR}
chown oracle:dba ${LOGDIR}
chmod 755 ${LOGDIR}
echo 'Validated directory '$LOGDIR
if [[ $VALOPT -eq 1 ]] || [[ $INSTCOUNT -eq 0 ]]
$ORACLE_HOME/bin/sqlplus -s '/as sysdba' << EOSQL1 >> $LOG
set echo on
set feedback on
startup nomount force
show sga
$ORACLE_HOME/bin/sqlplus -s '/as sysdba' << EOSQL >> $LOG
set heading off
set pagesize 0
set linesize 144
set echo off
set feedback off
alter session set nls_date_format = 'dd-mon-yyyy hh24:mi:ss';
spool /tmp/nretrodays.dat
FROM dual;
spool off
spool /tmp/hr.dat
FROM dual;
spool off
spool /tmp/mn.dat
FROM dual;
spool off
spool /tmp/sc.dat
FROM dual;
spool off
spool /tmp/dbstatus.dat
FROM v\$instance;
spool off
#) | tee -a $LOG
NRETRODAYS=`cat /tmp/nretrodays.dat`
HR=`cat /tmp/hr.dat`
MN=`cat /tmp/mn.dat`
SC=`cat /tmp/sc.dat`
DBST=`cat /tmp/dbstatus.dat`
#rm -f /tmp/*.dat
if [[ $VALOPT -eq 1 ]]
echo '#####'
echo '#############################################' >> $LOG
echo '# Using '${NLS_DATE_FORMAT}' as date format #' >> $LOG
echo '# Validating recovery started at '`date`' #' >> $LOG
echo '#############################################' >> $LOG
echo '#####'
rman nocatalog << EORMAN >> $LOG
connect target /
allocate channel for maintenance device type disk;
set dbid=$DBID;
restore spfile.ora to '$DBADMIN/$SID/pfile/spfile$SID.ora' from
release channel;
startup force nomount;
restore controlfile to '/tmp/control01.dbf' from autobackup maxseq 120;
restore controlfile from '/tmp/control01.dbf';
alter database mount;
show all;
set until
restore database until
set until
restore archivelog from time= "trunc(sysdate,'dd')-$NRETRODAYS" until
time= "trunc(sysdate,'dd')-$NRETRODAYS+$HR/24+$MN/1440+$SC/86400";
allocate channel dc1 device type disk;
set until
recover database until
release channel dc1;
sql "alter database open resetlogs";
#) | tee -a $LOG
rman nocatalog << EORMANV >> $LOG
connect target /
allocate channel for maintenance device type disk;
set dbid=$DBID;
restore spfile.ora to '$DBADMIN/$SID/pfile/spfile$SID.ora' from
release channel;
startup force nomount;
restore controlfile to '/tmp/control01.dbf' from autobackup validate;
restore controlfile from '/tmp/control01.dbf' validate;
alter database mount;
show all;
set until time =
crosscheck backupset of controlfile;
alter database mount ;
crosscheck backupset of database;
crosscheck backupset of archivelog all;
crosscheck archivelog all;
set until time =
restore controlfile to 'xx' until time="trunc(sysdate,'dd')-$NRETRODAYS
+ $HR/24 + $MN/1440 + $SC/86400" validate;
restore database until time="trunc(sysdate,'dd')-$NRETRODAYS + $HR/24 +
$MN/1440 + $SC/86400" validate;
restore archivelog time between "trunc(SYSDATE-$NRETRODAYS,'dd')" and
"trunc(SYSDATE-$NRETRODAYS,'dd') + $HR/24+$MN/1440 + $SC/86400"
#) | tee $LOG
mailx -s 'RMAN restore validated for '$SID \ < $LOG
cat $LOG

For the reader interested in obtaining a pdf version of my paper, please send me email at: or retrieve it from the Collaborate07 proceedings knowledgebase.

1 comment:

Anonymous said...

Este blog é uma representação exata de competências. Eu gosto da sua recomendação. Um grande conceito que reflete os pensamentos do escritor. Consultoria RH