25
The restore session report is in the Appendix C under Session 6.
Restore Recommendations Summary
This is a summary of the restore recommendations:
•
Edit the RMAN restore script before execution
•
Allocate channels manually on the selected instances
•
Use the same concurrency as used in the backup
•
Assign SAN devices to hosts using the Preferred Multipath host option
Recovery Considerations
When performing a database restore, the level of parallelism is determined by the number of RMAN
channels allocated. This is also true when restoring incremental backups. However, when performing
media recovery, Oracle will automatically select the optimal level of parallelism.
After we have restored the full backup, RMAN starts with the recovery phase. RMAN will always first
apply any suitable incremental backup and once finished, the required archived logs will be used for
media recovery.
Parallel recovery is enabled automatically for media recovery using the optimal parallelism degree
based on the number of available CPUs in the system. While it is enabled by default, it can be
disabled by using the NOPARALLEL clause in the RMAN recover command.
When tuning parallel recovery, standard parallel query tuning recommendations apply. In our
environment, the highest recovery performance improvement was achieved by increasing the Oracle
parameter PARALLEL_EXECUTION_MESSAGE_SIZE. For more information, review the Media recovery
best practices for 10g in the Appendix A.
Although media recovery is done in parallel, it is important to note that media recovery just takes
place on ONE RAC instance. As in a backup scenario, we have to guarantee that all archive logs are
available from the instance performing the media recovery.
To simulate a recovery scenario, we start an update of the table BENCH_1G in the tablespace POOL.
It has 52 Partitions (WEEK column), each partition with 20 million rows (each row is of approximately
200 Bytes)
1.
Perform a Full Backup of the POOL tablespace
From every RAC instance, we issue simultaneously an update of the table, in a way that every
instance updates only one table partition; on RAC1, we update the table as follows:
SQL> update bench_1g set a07=a07+1 where week=1;
20000000 rows updated.
Elapsed: 00:51:15.95
SQL>
Approximately, 130 archive logs per RAC instance were generated during the update.
2.
Perform an incremental backup (just for the recovery scenario with incremental backup
3.
Perform the restore of the tablespace POOL (as in the previous section)
4.
There are different recovery scenarios:
–
Use archived logs generated during the update
–
Use incremental backup taken after the update
