Does RMAN backup undo optimization also work for image copies?
- Written by: ilmarkerm
- Category: Blog entry
- Published: March 7, 2016
Since 11.1 RMAN has had a silent new feature – RMAN Backup Undo Optimization. This feature will exclude undo from committed transactions (after undo_retention time has also passed) from backups, possibly making the undo tablespace backup much smaller. The documentation just says that it will work for disk backups and Oracle Secure Backup tape backups. Since lately I’m been playing around a lot with image copy backups I wanted to find out if this feature only works with backupsets or does it also work for incrementally refreshed image copies.
I first thought that it cannot possibly work with image copies, since image copies should be exact datafile copies, but on the other hand when you refresh and image copy, then you at first also have to create incremental backupset of the changes that you then apply to the image copy, so maybe the optimization is applied silently there also 🙂 Would be really good. Better to test it out. Fingers crossed.
I’m using 12.1.0.2 on OEL 7.2.
Before taking the test I created an image copy from my undo tablespace (309 338 112 bytes):
RMAN> BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'image_copy_backup' TABLESPACE UNDOTBS1;
-rw-r-----+ 1 oracle oinstall 309338112 Dec 28 05:06 data_D-ORCL_I-1433672784_TS-UNDOTBS1_FNO-3_04qvtmir
Yes I know, my filesystem dates were wrong at that point 🙂 Ignore this, NTP wasn’t running on the storage box.
Also a level 0 uncompressed backupset of the same tablespace (207 110 144 bytes, so it has already been optimized, but I’m interested in the next incremental backup size):
RMAN> BACKUP INCREMENTAL LEVEL 0 TABLESPACE UNDOTBS1;
-rw-r-----+ 1 oracle oinstall 207110144 Dec 28 05:16 0kqvtpaj_1_1
Next I ran a large UPDATE statement and committed it immediately. I also had snapper running to catch the amount of undo my update caused. Snapper reported that my update generated 146MB of undo:
STAT, undo change vector size , 146 042 740
Now immediately I run incremental backup for both, backupset and to incrementally update the image copy.
BACKUP INCREMENTAL LEVEL 1 TABLESPACE UNDOTBS1 command produced file named 0mqvtpkf_1_1 and command BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG ‘image_copy_backup’ tablespace undotbs1 produced file named 0oqvtpm2_1_1. As you can see, both are almost equally as big and close to the reported undo change vector size.
No surprise herem undo optimization did not kick in since undo_retention time has not yet passed.
-rw-r-----+ 1 oracle oinstall 151470080 Dec 28 05:21 0mqvtpkf_1_1
-rw-r-----+ 1 oracle oinstall 181190656 Dec 28 05:22 0oqvtpm2_1_1
Then I deleted both these files and removed them from RMAN catalog.
After 30 minutes or so (my undo_retention time is 600 = 10 minutes) I ran the backup commands again:
RMAN> backup incremental level 1 tablespace undotbs1;
Starting backup at 07-MAR-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=45 device type=DISK
channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00003 name=/u01/app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_cfvpb5hx_.dbf
channel ORA_DISK_1: starting piece 1 at 07-MAR-16
channel ORA_DISK_1: finished piece 1 at 07-MAR-16
piece handle=/nfs/backup/orcl/14qvtsgf_1_1 tag=TAG20160307T230238 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 07-MAR-16
RMAN> BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'image_copy_backup' tablespace undotbs1;
Starting backup at 07-MAR-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=61 device type=DISK
channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00003 name=/u01/app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_cfvpb5hx_.dbf
channel ORA_DISK_1: starting piece 1 at 07-MAR-16
channel ORA_DISK_1: finished piece 1 at 07-MAR-16
piece handle=/nfs/backup/orcl/16qvtsj0_1_1 tag=IMAGE_COPY_BACKUP comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
Finished backup at 07-MAR-16
This can’t be good.. regular backupset took only 1 second to execute and taking an incremental backup for image copy refresh took 7 seconds.
Looking at the file sizes the difference is clear – 1,7MB for the incremental backup and 181MB (no change) for the image copy refresh:
-rw-r-----+ 1 oracle oinstall 1794048 Mar 7 23:02 14qvtsgf_1_1
-rw-r-----+ 1 oracle oinstall 181567488 Mar 7 23:04 16qvtsj0_1_1
So the backup undo optimization works, but only if you use backupsets.