Optimizing RMAN Recovery

Pete Dinin @ Hotsos Symposium

March 9, 2016
 Disclaimer
• The views and opinions expressed in this
presentation are solely mine, and not that of
my employer.
• Products, features and techniques discussed
in this presentation are not necessarily
endorsed by my employer.
• As always, please test any scripts and
techniques before using in production!
 About Me
• Degrees in Music Performance and
Mathematics
• Oracle DBA since 1999
• Active member and President of North East
Ohio Oracle Users Group
• Married 25 years to Tracy
– Liz (19) is sophomore in Art School
– Andrew (16) is sophomore in High School
– Rebecca (12) is in 5th grade
 Objective
• Think about RMAN differently
– You should not be thinking
“How fast can I back up my database?”
– But, you should be thinking
“How fast can I restore & recover my database?”
 Topics
• RMAN Basics
• Identify and Manage Bottlenecks
• Avoiding Restore/Recover Work
• Tips
RMAN BASICS
 RMAN
• Recovery Manager (RMAN) is an Oracle
Database client that performs backup and
recovery tasks on your databases and
automates administration of your backup
strategies. It greatly simplifies backing up,
restoring, and recovering database files.
– (12c RMAN User Guide)
 Why RMAN?
• “Recommended” by Oracle for Database
Backup and Recovery
• Is a mature “feature” of all Oracle Database
– No extra costs for almost all functionality

• There are other technologies that may provide

faster recovery options in some situations
 RMAN Architecture
Target (Production) Databases

RMAN Repository
Catalog
RMAN
RMAN RMAN (opt)
Channels
RMAN
Client Channels
RMAN
Channels
DBA Channels Control
Files

Backup Storage Media

 Sample Database in Demos
• Database PETE
– 5Tb Total Size, 1 Instance In Test
– 8 Gb SGA, 4 Gb PGA
– Oracle Enterprise Edition 12.1.0.2
• Testing Tablespace PETE_TS
– 24 Datafiles, 196 Gb total size
• RMAN Configuration (unless specified)
– No Compression, 4 Channels, 1 File Per set
• Server – Exadata X4-2 (1 Node of ½ Rack)
• NFS Mount – DataDomain 9500
– “Traditional” NFS (not dNFS)
– 10 Gb network connectivity
• Note: This is not an “isolated” environment
– Some results may be impacted by varying workloads
IDENTIFY AND MANAGE
BOTTLENECKS
 RMAN Backup/Restore Phases
Backup Channel 1 Channel 2 Channel 3 Channel 4 Recover
Primary Database Disk Subsystem

Read IO Buffers IO Buffers IO Buffers IO Buffers Write

Copy DB Server CPU Processing Copy

• Validate • Build File
• Build Set • Validate
• Compress • Decompress
• Encrypt • Decrypt
Write IO Buffers IO Buffers IO Buffers IO Buffers Read

Backup Storage Subsystem

 Channel Phases – Backup
• Read
– Data blocks (below HWM) are read from target database files
• Copy
– Data blocks are validated
– Assemble backup sets from data blocks
– Backup sets are compressed (optional)
• May require Advanced Compression Option
– Backup sets are encrypted (optional)
• Requires Advanced Security Option
• Write
– Backup sets written to backup storage subsystem
– May be Synchronous or Asynchronous
 Channel Phases – Restore
• Read
– Backup set is read from backup storage media (disk/tape)
• Copy
– Decrypt RMAN-encrypted backups (optional)
• Requires Advanced Security Option
– Decompress RMAN-compressed backups (optional)
• May require Advanced Compression Option
– Validate block
– Create database file for writing
• Write
– Database files are written back to primary storage
 Backup Bottlenecks
• Described in RMAN Performance Tuning
Chapter of Oracle Docs
– https://docs.oracle.com/database/121/BRADV/rc
mtunin.htm#GUID-4189FC87-CD02-49CD-A311-
887ABAA34004
• Most content is on Backup optimization
– Essentially, compare the elapsed time of “Backup
Validate” to “Backup” commands
• Can also adapt this to Restore Optimization
 Validate Functionality

Backup
Validate

Restore
Validate
 Validate Functionality
• Backup Validate
– Read data blocks from primary disk
– RMAN validation
– No write or compression/encryption
• Restore Validate
– Read backup from backup storage
– Decompress and decrypt if needed
– RMAN validation
– No write to primary disk
 Quick comparison with Validate
• This chart is just a comparison of time
between Backup Validate and Backup, as well
as Restore Validate and Restore
Command NFS Filer 1 NFS Filer 2 +FRA on ASM

Backup Validate 0:44 0:44 0:52

Backup 10:53 9:46 1:57
Backup Delta 10:09 8:02 1:05
Restore Validate 7:01 16:00 0:50
Restore 7:44 16:53 1:47
Restore Delta 0:43 0:53 0:57
 V$BACKUP_ASYNC_IO
• This query summarizes Asynchronous IO waits for RMAN (disk)
SELECT rman_status_recid,
'ASYNC' io_type,
COUNT (1) file_count,
TYPE,
ROUND (SUM (bytes) / 1024 / 1024 / 1024, 3) bytes_gb,
SUM (elapsed_time) / 100 channel_sec,
SUM ( (short_wait_time_total + long_wait_time_total) / 100) channel_io_wait_sec,
TO_CHAR (MIN (open_time), 'DD-Mon-YYYY HH24:MI:SS') start_time,
(MAX (close_time) - MIN (open_time)) * 1440 * 60 elapsed_sec,
ROUND ((SUM (bytes) / 1024 / 1024) /
( (MAX (close_time) - MIN (open_time)) * 1440 * 60 +1), 3) net_mb_per_sec
FROM GV$BACKUP_ASYNC_IO
WHERE TYPE IN ('INPUT', 'OUTPUT')
GROUP BY rman_status_recid, TYPE
ORDER BY rman_status_recid DESC, TYPE
FETCH FIRST 10 ROWS ONLY;
 V$BACKUP_SYNC_IO
• This query summarizes synchronous IO waits for RMAN (tape)
SELECT rman_status_recid,
'SYNC' io_type,
COUNT (1) file_count,
TYPE,
ROUND (SUM (bytes) / 1024 / 1024 / 1024, 3) bytes_gb,
SUM (elapsed_time) / 100 channel_sec,
SUM ( (io_time_total) / 100) channel_io_wait_sec,
TO_CHAR (MIN (open_time), 'DD-Mon-YYYY HH24:MI:SS') start_time,
(MAX (close_time) - MIN (open_time)) * 1440 * 60 toal_elapsed_sec,
ROUND ( (SUM (bytes) / 1024 / 1024) /
( (MAX (close_time) - MIN (open_time)) * 1440 * 60 +1), 3) net_mb_per_sec
FROM GV$BACKUP_SYNC_IO
WHERE TYPE IN ('INPUT', 'OUTPUT')
GROUP BY rman_status_recid, TYPE
ORDER BY rman_status_recid DESC, TYPE
FETCH FIRST 10 ROWS ONLY;
 Copy Time and Wait Time
• Copy time can use CPU information can be
captured from ps -ef output
• Other waits can be captured from
v$session_wait

• In both cases, need to capture information for

processes associated with the RMAN channels
• Can also be computed
 Example – Backup Validate
• Backup Validate – 45 Seconds
RMAN> backup filesperset 1 validate tablespace pete_ts;
Starting backup at 27-Jan-2016 09:24:55 …
Finished backup at 27-Jan-2016 09:25:40

RMAN_STATUS_RECID IO_TY FILE_COUNT TYPE BYTES_GB CHANNEL_SEC

----------------- ----- ---------- --------- ---------- -----------
11554 ASYNC 24 INPUT 196.191 124

CHANNEL_IO_WAIT_SEC START_TIME ELAPSED_SEC NET_MB_PER_SEC

------------------- -------------------------- ----------- --------------
78.39 27-Jan-2016 09:24:57 42 4672.093

oracle 74647 73555 13 09:24 ? 00:00:13 oraclePETE1

oracle 74660 73555 13 09:24 ? 00:00:13 oraclePETE1
oracle 74723 73555 12 09:24 ? 00:00:12 oraclePETE1
oracle 74824 73555 13 09:24 ? 00:00:13 oraclePETE1

SESSION_EVENT AVG(TIME_SEC)
------------------------------ -------------
RMAN backup & recovery I/O 19.4375
SQL*Net message from client 6.9725
events in waitclass Other 6.46
 Example – Backup
• Backup – 9:47 Minutes (587 seconds)
RMAN> backup filesperset 1 tablespace pete_ts;
Starting backup at 27-Jan-2016 09:28:43 …
Finished backup at 27-Jan-2016 09:38:30

RMAN_STATUS_RECID IO_TY FILE_COUNT TYPE BYTES_GB CHANNEL_SEC

----------------- ----- ---------- --------- ---------- -----------
11556 ASYNC 24 INPUT 189.753 2167
11556 ASYNC 24 OUTPUT 189.752 2169

CHANNEL_IO_WAIT_SEC START_TIME ELAPSED_SEC NET_MB_PER_SEC

------------------- -------------------------- ----------- --------------
1.26 27-Jan-2016 09:28:46 576 336.755
2069.55 27-Jan-2016 09:28:46 576 336.751

oracle 96145 95539 3 09:28 ? 00:00:25 oraclePETE1

oracle 96155 95539 3 09:28 ? 00:00:24 oraclePETE1
oracle 96156 95539 3 09:28 ? 00:00:24 oraclePETE1
oracle 96182 95539 3 09:28 ? 00:00:24 oraclePETE1

SESSION_EVENT AVG(TIME_SEC)
------------------------------ -------------
RMAN backup & recovery I/O 517.3025
SQL*Net message from client 48.2275
events in waitclass Other 5.4375
 Example – Restore Validate
• Restore Validate – 8:00 Minutes (480 Seconds)
RMAN> restore tablespace pete_ts validate;
Starting restore at 31-Jan-2016 13:20:25 …
Finished restore at 31-Jan-2016 13:28:25

RMAN_STATUS_RECID IO_TY FILE_COUNT TYPE BYTES_GB CHANNEL_SEC

----------------- ----- ---------- --------- ---------- -----------
11612 ASYNC 24 INPUT 189.752 1724

CHANNEL_IO_WAIT_SEC START_TIME ELAPSED_SEC NET_MB_PER_SEC

------------------- -------------------------- ----------- --------------
1693.09 31-Jan-2016 13:20:33 462 419.666

oracle 916 124257 1 13:20 ? 00:00:08 oraclePETE1

oracle 962 124257 1 13:20 ? 00:00:08 oraclePETE1
oracle 1044 124257 1 13:20 ? 00:00:08 oraclePETE1
oracle 1207 124257 1 13:20 ? 00:00:08 oraclePETE1

SESSION_EVENT AVG(TIME_SEC)
------------------------------ -------------
RMAN backup & recovery I/O 422.92
SQL*Net message from client 46.56
 Example – Restore
• Restore – 8:31 Minutes (511 Seconds)
RMAN> restore tablespace pete_ts;
Starting restore at 31-Jan-2016 13:29:55 …
Finished restore at 31-Jan-2016 13:38:26

RMAN_STATUS_RECID IO_TY FILE_COUNT TYPE BYTES_GB CHANNEL_SEC

----------------- ----- ---------- --------- ---------- -----------
11614 ASYNC 24 INPUT 189.752 1880
11614 ASYNC 24 OUTPUT 196.191 1878

CHANNEL_IO_WAIT_SEC START_TIME ELAPSED_SEC NET_MB_PER_SEC

------------------- -------------------------- ----------- --------------
1790.1 31-Jan-2016 13:30:03 495 391.745
.11 31-Jan-2016 13:30:03 495 405.04

oracle 47166 46832 4 13:29 ? 00:00:24 oraclePETE1

oracle 47171 46832 4 13:29 ? 00:00:24 oraclePETE1
oracle 47174 46832 4 13:29 ? 00:00:24 oraclePETE1
oracle 47277 46832 4 13:29 ? 00:00:25 oraclePETE1

SESSION_EVENT AVG(TIME_SEC)
------------------------------ -------------
RMAN backup & recovery I/O 447.5975
SQL*Net message from client 39.2575
 Example – Summary
Backup Restore
Time
Validate
Backup
Validate
Restore
• Questions
CPU 13.00 24.00 8.00 24.00
IO Input 19.60 0.32 422.92 447.60
– Why is there no IO Input
IO Output N/A 517.39 N/A 0.03 time for backup?
Other Waits
Total
13.43
46.03
53.67
595.37
46.56
477.48
39.26
510.89
– Why is there no IO
Actual 45.00 587.00 480.00 511.00 Output time for restore?

Note that total time of components

are close to the actual elapsed time
 Example on Diagram

511 Total Time

==============

20 Read IO 40 Misc Waits

0 Write IO

13 Validate CPU 24 – 8 =
16 Build CPU
24 – 13 =
11 Other CPU 8 = Validate CPU

517 Write IO 447 Read IO

48 – 20 (read IO)
= 28 Misc Waits
==============
589 Total Time
 What to look for
• Which phase is taking longest?
• Read/Write bottleneck show high % IO Wait
• Copy bottleneck show low % IO Wait and high
CPU time on process (from ps)
 Compression & Performance
• May increase throughput, if the bottleneck is
on the backup storage IO
• There is overhead in the COPY phase to
compression both on the backup and restore
– The key is to find the balance between IO waits
and CPU time
 Compression Example
• Next slides shows impact of compression
using different backup storage systems
• Basic Compression is included with Oracle
– However, the best things in life are not always free
• Low, Medium and High Compression require
Advanced Compression Option
 Compression Example 1
• +FRA on Exadata

Compression Compress Backup Time Restore Time Maximum Net

Level Ratio Elapsed Elapsed Throughput
None 1.034 x 1:53 1:40 1943.06 MB/sec
Basic 8.283 x 14:40 18:44 27.561 MB/sec
Low 5.728 x 1:26 1:39 398.714 MB/sec
Medium 7.359 x 7:16 1:37 281.453 MB/sec
High 11.641 x 1:17:05 15:13 18.901 MB/sec
Datafile Copy 1.000 x 2:24 1:47 1877.57 MB/sec
 Compression Example 2
• NFS Volume

Compression Compress Backup Time Restore Time Maximum Net

Level Ratio Elapsed Elapsed Throughput
None 1.034 x 9:25 7:58 406.497 MB/sec
Basic 8.305 x 15:03 18:46 26.790 MB/sec
Low 5.736 x 2:34 2:20 250.196 MB/sec
Medium 7.376 x 7:34 2:02 223.267 MB/sec
High 11.687 x 1:23:08 18:43 15.307 MB/sec
Datafile Copy 1.000 x 9:35 8:01 417.672 MB/sec
 Compression Comparison
• Fast backup system, no need to compress
• Free compression has a cost
Compression Backup Time Backup Time Restore Time Restore Time
Level +FRA NFS +FRA NFS
None 1:53 9:25 1:40 7:58
Basic 14:40 15:03 18:44 18:46
Low 1:26 2:34 1:39 2:20
Medium 7:16 7:34 1:37 2:02
High 1:17:05 1:23:08 15:13 18:43
Datafile Copy 2:24 9:35 1:47 8:01
 Storage Network Congestion
• Where is the mirroring done for your
database?
• If mirroring with ASM, you need to watch the
SAN on the write phase – for every block you
restore, you must write 2 or 3 blocks to disk
– Yes – this applies to Exadata too
• If backups and primary disk are on same
storage network, congestion is more likely
 Parallelism
• Obtained by increasing the number of RMAN
channels
• Increasing number of channels may improve
restore time if
– IO Channels (DB and Backup) are not saturated
– Underlying storage is not saturated
• If you change the number of channels and
there is no change in performance, something
is saturated
 Beware of PETs
• Many backup storage systems contain
Performance Enhancing Technologies (PETs) to
improve performance, increase capacity or
deliver additional functionality
• Many of these PETs benefit backup operations
more than restore/recover operations
• Some of these PETs are transparent to the
DBA and are managed by the Storage
Administrator
 PETs
• Asynchronous writes and write caches
– These will improve the performance of taking
backups, but are of no value during restores
– The time to read your backup may be significantly
longer than the time it took to write it
• Post-write compression and de-duplication
– Backups are de-duplicated and compressed “in the
background” after the backup set is written
– For restore, backup sets must be “re-hydrated” in real
time (while you are waiting for them)
– The backup sets may be “larger than they appear” (on
your backup server) when you restore/recover
 More PETs
• Post-write Encryption
– If there is sensitive data, encryption features can
be enabled on backup storage devices
– If encryption is truly needed, encrypt it in the
database – the RMAN backup set will be
encrypted automatically
 Exotic PETs
• DDBoost – EMC software that is integrated with
EMC Data Domain backup appliance
– Allows RMAN backup set de-duplication to happen at
the client-side within the RMAN channel, plus
additional compression on the storage appliance
– Backup times can be phenomenal: a 5Tb database
level 0 backup in 20 minutes with ~100x compression
ratio (32 channels)
– This can set unrealistic expectations for restore times:
the same 5Tb database took 105 minutes to restore
– Regularly running “restore validate” is the only way to
effectively know the restore/recover time
AVOIDING WASTED WORK
 Multiplexing
• This is the number of database files contained in
a backup set
– Determined by the filesperset attribute
• If not specified, RMAN divide the number of files
to be backed up by the number of channels
– If there are 4 channels and 36 files to backup up, each
channel will (probably) get 9 files for its backup set
• Multiplexing generally means fewer backup sets
to create and manage
 How does RMAN read backup sets?
• Backup sets are read sequentially
• Even if you only need one file in a backup set,
you must (generally) read the entire file
• If you only need one file out of a multiplexed
backup set, all the Read, Decrypt and
Uncompress steps need to be performed for
files you do not need as well
 Restoring multiplexed backups
• If the entire backup set is restored, it does not
matter if you have multiplexed backup sets
• Cases where you may not restore the entire
backup set (partial database restore)
– Restore/recover a lost or corrupt data file
– Tablespace point-in-time recovery
– Archived log restores (for point-in-time recovery)
– Table-level recovery (12c new feature)
– Block Recovery
 Multiplexing Demo
RMAN> backup filesperset 24 tablespace pete_ts;
Starting backup at 25-Jan-2016 16:56:41
allocated channel: ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=01023 name=+DATA/PETE/DATAFILE/pete_ts.3142.900324977
… < Part of datafile list removed >
input datafile file number=01009 name=+DATA/PETE/DATAFILE/pete_ts.3042.900324965
channel ORA_DISK_1: starting piece 1 at 25-Jan-2016 16:56:42
channel ORA_DISK_1: finished piece 1 at 25-Jan-2016 17:32:37
channel ORA_DISK_1: backup set complete, elapsed time: 00:35:55
Finished backup at 25-Jan-2016 17:32:37

RMAN> restore datafile 1022;

Starting restore at 25-Jan-2016 20:09:39
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 01022 to
+DATA/PETE/DATAFILE/pete_ts.17166.900324977
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:10:15
Finished restore at 25-Jan-2016 20:19:57
 No Multiplexing Demo
RMAN> backup filesperset 1 tablespace pete_ts;
Starting backup at 25-Jan-2016 19:44:22
channel ORA_DISK_21: starting full datafile backup set
channel ORA_DISK_21: specifying datafile(s) in backup set
input datafile file number=01022 name=+DATA/PETE/DATAFILE/pete_ts.17166.900324977
channel ORA_DISK_21: starting piece 1 at 25-Jan-2016 19:44:31
channel ORA_DISK_21: finished piece 1 at 25-Jan-2016 19:49:06
piece handle=/backup/PETE/rman/PETE_set27425_piece1-date20160125.bck
tag=TAG20160125T194428 comment=NONE
channel ORA_DISK_21: backup set complete, elapsed time: 00:04:35
Finished backup at 25-Jan-2016 19:49:06

RMAN> restore datafile 1022;

Starting restore at 25-Jan-2016 21:28:51
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 01022 to
+DATA/PETE/DATAFILE/pete_ts.17166.900324977
channel ORA_DISK_1: reading from backup piece
/global/dd_backup/PETE/rman/PETE_set27425_piece1-date20160125.bck
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
Finished restore at 25-Jan-2016 21:29:28
 Idle Time – Between Backup Sets
• With many backup sets, there may be idle time
between restoring sets
• Query:
SELECT rman_Status_recid, SUM (idle_time)
FROM (SELECT rman_Status_recid,
sid, serial, open_time, close_time,
( open_time - LAG ( close_time )
OVER
(PARTITION BY rman_Status_recid, sid, serial
ORDER BY open_time)) * 1440 * 60
AS idle_time
FROM V$BACKUP_ASYNC_IO
WHERE TYPE = 'INPUT')
GROUP BY rman_Status_recid
ORDER BY rman_Status_recid desc;
 Multiplexing Comparison
• Single file restore faster with lower filesperset
• Full restore times similar for all
– More idle time with more backup sets
Files Per Datafile 1022 Tablespace PETE_TS Tablespace PETE_TS
Backupset Restore Time Restore Time Idle Time
24 10:18 10:44 0:00
8 2:37 10:51 0:04
4 2:07 8:54 0:19
1 0:37 10:58 1:22
 Multiplexing Conclusions
• Reading backups are like Full Table Scans –
sometimes they are necessary, but not always
• Large multiplexed backup sets are likely to
have “wasted work” for partial restores
• Smaller backupsets (such as filesperset 1) can
reduce wasted work on a partial restores
• Too many backup sets increases restore time
because of the “idle time” between each set
• Find the sweet spot for your use cases
 A look at Archivelog backups
• Is this similar to your backup script?
backup tablespace pete_ts plus
archivelog tag 'LEVEL_0';
backup archivelog all delete input tag
'ARCH';

• There will be two copies of some archivelogs

– In the following example archive log sequence #854
was generated during the backup and is in both
LEVEL_0 & ARCH
Which backup will be faster to restore?
RMAN> list backup of archivelog sequence 854;
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ --------------------
33001 334.04M DISK 00:00:05 31-Jan-2016 15:28:23
BP Key: 36453 Status: AVAILABLE Compressed: NO Tag: LEVEL_0
Piece Name: /backup/PETE/rman/PETE_set27571_piece1-date20160131.bck

List of Archived Logs in backup set 33001

Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- -------------------- ---------- ---------
1 854 10374348808812 31-Jan-2016 15:24:21 10374348809485 31-Jan-2016 15:28:15

BS Key Size Device Type Elapsed Time Completion Time

------- ---------- ----------- ------------ --------------------
33006 9.57G DISK 00:01:22 31-Jan-2016 15:31:30
BP Key: 36458 Status: AVAILABLE Compressed: NO Tag: ARCH
Piece Name: /backup/PETE/rman/PETE_set27575_piece1-date20160131.bck

List of Archived Logs in backup set 33006

Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- -------------------- ---------- ---------
1 854 10374348808812 31-Jan-2016 15:24:21 10374348809485 31-Jan-2016 15:28:15
 Which one will RMAN use?
RMAN> restore archivelog sequence 854;
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=854
channel ORA_DISK_1: reading from backup piece
/backup/PETE/rman/PETE_set27575_piece1-date20160131.bck
channel ORA_DISK_1: restored backup piece 1

• If there is more than one available backup,

RMAN will choose the latest one
• In our case, the backup set used was 29x
larger than the other set
 Reverse the order
• Backup archivelogs first, then database
backup archivelog all delete input
tag 'ARCH';
backup tablespace pete_ts plus
archivelog tag 'LEVEL_0';

• Archivelog #899 was generated during the

LEVEL_0 and this looks good for now…
 Log 899 is part of LEVEL_0
RMAN> backup tablespace pete_ts plus archivelog tag 'LEVEL_0';
Starting backup at 31-Jan-2016 15:57:47
< datafile backups here >
current log archived
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=899 RECID=1095 STAMP=902592445

RMAN> list backup of archivelog sequence 899;

List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ --------------------
33023 6.34M DISK 00:00:00 31-Jan-2016 16:07:25
BP Key: 36475 Status: AVAILABLE Compressed: NO Tag: LEVEL_0
Piece Name: /backup/PETE/rman/PETE_set27596_piece1-date20160131.bck
List of Archived Logs in backup set 33023
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- -------------------- ---------- ---------
1 899 10374348826737 31-Jan-2016 15:57:47 10374348827457 31-Jan-2016 16:07:25
Look at Log 899 after the next backups
RMAN> backup archivelog all delete input tag 'ARCH';
Starting backup at 31-Jan-2016 16:25:29
current log archived
……
channel ORA_DISK_4: starting archived log backup set
channel ORA_DISK_4: specifying archived log(s) in backup set
input archived log thread=1 sequence=897 RECID=1097 STAMP=902593114
input archived log thread=1 sequence=898 RECID=1098 STAMP=902593178
input archived log thread=1 sequence=899 RECID=1099 STAMP=902593190

• After the next backup there are now two

backups of Log 899…
 Remember which one will be used
RMAN> list backup of archivelog sequence 899;
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ --------------------
33023 6.34M DISK 00:00:00 31-Jan-2016 16:07:25
BP Key: 36475 Status: AVAILABLE Compressed: NO Tag: LEVEL_0
Piece Name: /backup/PETE/rman/PETE_set27596_piece1-date20160131.bck

List of Archived Logs in backup set 33023

Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- -------------------- ---------- ---------
1 899 10374348826737 31-Jan-2016 15:57:47 10374348827457 31-Jan-2016 16:07:25

BS Key Size Device Type Elapsed Time Completion Time

------- ---------- ----------- ------------ --------------------
33028 7.84G DISK 00:01:19 31-Jan-2016 16:26:52
BP Key: 36480 Status: AVAILABLE Compressed: NO Tag: ARCH
Piece Name: /backup/PETE/rman/PETE_set27604_piece1-date20160131.bck

List of Archived Logs in backup set 33028

Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- -------------------- ---------- ---------
1 899 10374348826737 31-Jan-2016 15:57:47 10374348827457 31-Jan-2016 16:07:25
How to avoid duplicating Log backups?
• Backup archivelogs separately, at beginning and at end
backup archivelog all delete input tag
'ARCH';
backup filesperset 1 tablespace pete_ts tag
'LEVEL_0';
backup archivelog all delete input tag
'LEVEL_0';

• Use the “delete input” with the “plus archivelog”

backup archivelog all delete input tag
'ARCH';
backup filesperset 1 tablespace pete_ts plus
archivelog tag 'LEVEL_0' delete input;
CONCLUDING TIPS
 Tips
• Practice your restore/recovery using duplicate
database on a production-like server
– This will give you the best estimates of how long it
will take to restore/recover your database
• Restore validate is your friend
– It is non-disruptive to your operating database
– Use it as a gauge to predict the performance of
your actual restore time
 Tips
• Locate your bottleneck
– Every system has one. Once you find it, you can
manage around it
• Design your backup scripts knowing how the
backup pieces will be used in recovery
– That will help avoid wasted work when time really
matters
 Tips
• Multiplexing – take small bites
– Do not multiplex data file backups (filesperset 1)
– Limit multiplexing for archivelog backups (a
reasonable number)
• Archivelog backups
– Perform archivelog backup and deletion before
database and datafiles
– Keep archivelogs required for database backup
consistency in their own backup set (and only 1
copy)
 Contact Info
• Follow-up Questions Email
– [email protected]

• Hope to see you at the Great Lakes Oracle Conference

(GLOC) on May 16-18 in Cleveland, Ohio