Faster switching into ASM



Following rapidly on from the last post - for larger databases the switch command and subsequent recover could take a while - so here we can make sue of a nice feature that allows an incremental backup to be applied to the image copy in ASM to mean there is less archive redo to apply to the copy after the switch to get back to current time.

First up we create yet another database in the minimal way - then we do a normal image backup - putting the files into ASM - the only real addition to the normal command is giving this image copy an explicit tag.


RMAN> backup as copy database format '+DATA' tag 'demo';

Starting backup at 28-FEB-14
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile file number=00001 name=/oracle/ENDCON/oradata2/DEMO/datafile/o1_mf_system_9k150760_.dbf
output file name=+DATA/DEMO/DATAFILE/system.270.840723357 tag=DEMO RECID=8 STAMP=840723357
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile copy
input datafile file number=00005 name=/oracle/ENDCON/oradata2/DEMO/datafile/o1_mf_sys_undo_9k150g03_.dbf
output file name=+DATA/DEMO/DATAFILE/sys_undots.269.840723359 tag=DEMO RECID=9 STAMP=840723359
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile copy
input datafile file number=00003 name=/oracle/ENDCON/oradata2/DEMO/datafile/o1_mf_sysaux_9k150cqq_.dbf
output file name=+DATA/DEMO/DATAFILE/sysaux.268.840723359 tag=DEMO RECID=10 STAMP=840723360
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile copy
input datafile file number=00006 name=/oracle/ENDCON/oradata2/DEMO/datafile/o1_mf_test_9k1521dt_.dbf
output file name=+DATA/DEMO/DATAFILE/test.271.840723361 tag=DEMO RECID=11 STAMP=840723360
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile copy
input datafile file number=00007 name=/oracle/ENDCON/oradata2/DEMO/datafile/o1_mf_test2_9k1527m0_.dbf
output file name=+DATA/DEMO/DATAFILE/test2.272.840723361 tag=DEMO RECID=12 STAMP=840723362
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile copy
input datafile file number=00002 name=/oracle/ENDCON/oradata2/DEMO/F378B6BA9C69203DE0430200007FF5F6/datafile/o1_mf_system_9k1508s7_.dbf
output file name=+DATA/DEMO/F378B6BA9C69203DE0430200007FF5F6/DATAFILE/system.273.840723363 tag=DEMO RECID=13 STAMP=840723363
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile copy
input datafile file number=00004 name=/oracle/ENDCON/oradata2/DEMO/F378B6BA9C69203DE0430200007FF5F6/datafile/o1_mf_sysaux_9k150f1d_.dbf
output file name=+DATA/DEMO/F378B6BA9C69203DE0430200007FF5F6/DATAFILE/sysaux.274.840723365 tag=DEMO RECID=14 STAMP=840723364
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 28-FEB-14

Starting Control File and SPFILE Autobackup at 28-FEB-14
piece handle=/oracle/12.0.0.1/dbs/c-3584792132-20140228-02 comment=NONE
Finished Control File and SPFILE Autobackup at 28-FEB-14

RMAN>

OK - so that was fine - and in my example the database is tiny so takes no time at all - however if this was multi terabyte the backup could run for hours (if not days) and loads of redo could be generated during that time - if we were to switch to this copy we would have to apply all that redo to recover the file to current time.

To get round this we can take an incremental backup and apply it to the image copy in ASM. This incremental should be much quicker (especially if using BCT) and we can do multiple of these if needed to catch up the system as much as possible towards current time.

We have to give a special syntax to tell oracle we have a special use foe this file


RMAN>  backup incremental level 1 for recover of copy with tag 'demo' format '+DATA' database;

Starting backup at 28-FEB-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=361 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=00001 name=/oracle/ENDCON/oradata2/DEMO/datafile/o1_mf_system_9k150760_.dbf
input datafile file number=00005 name=/oracle/ENDCON/oradata2/DEMO/datafile/o1_mf_sys_undo_9k150g03_.dbf
input datafile file number=00003 name=/oracle/ENDCON/oradata2/DEMO/datafile/o1_mf_sysaux_9k150cqq_.dbf
input datafile file number=00006 name=/oracle/ENDCON/oradata2/DEMO/datafile/o1_mf_test_9k1521dt_.dbf
input datafile file number=00007 name=/oracle/ENDCON/oradata2/DEMO/datafile/o1_mf_test2_9k1527m0_.dbf
channel ORA_DISK_1: starting piece 1 at 28-FEB-14
channel ORA_DISK_1: finished piece 1 at 28-FEB-14
piece handle=+DATA/DEMO/BACKUPSET/2014_02_28/nnndn1_demo_0.276.840723585 tag=DEMO comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
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=00002 name=/oracle/ENDCON/oradata2/DEMO/F378B6BA9C69203DE0430200007FF5F6/datafile/o1_mf_system_9k1508s7_.dbf
skipping datafile 00002 because it has not changed
input datafile file number=00004 name=/oracle/ENDCON/oradata2/DEMO/F378B6BA9C69203DE0430200007FF5F6/datafile/o1_mf_sysaux_9k150f1d_.dbf
skipping datafile 00004 because it has not changed
channel ORA_DISK_1: backup cancelled because all files were skipped
Finished backup at 28-FEB-14

Starting Control File and SPFILE Autobackup at 28-FEB-14
piece handle=/oracle/12.0.0.1/dbs/c-3584792132-20140228-04 comment=NONE
Finished Control File and SPFILE Autobackup at 28-FEB-14

There are some skips happening here (this is because this is a cdb/pdb and the PDB$SEED never changes and only needs to be backed up 'once')

Now we have to apply this incremental backup to the image copy in ASM

RMAN> recover copy of database with tag 'demo';

Starting recover at 28-FEB-14
using channel ORA_DISK_1
no copy of datafile 2 found to recover
no copy of datafile 4 found to recover
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile copies to recover
recovering datafile copy file number=00001 name=+DATA/DEMO/DATAFILE/system.270.840723357
recovering datafile copy file number=00003 name=+DATA/DEMO/DATAFILE/sysaux.268.840723359
recovering datafile copy file number=00005 name=+DATA/DEMO/DATAFILE/sys_undots.269.840723359
recovering datafile copy file number=00006 name=+DATA/DEMO/DATAFILE/test.271.840723361
recovering datafile copy file number=00007 name=+DATA/DEMO/DATAFILE/test2.272.840723361
channel ORA_DISK_1: reading from backup piece +DATA/DEMO/BACKUPSET/2014_02_28/nnndn1_demo_0.275.840723395
channel ORA_DISK_1: piece handle=+DATA/DEMO/BACKUPSET/2014_02_28/nnndn1_demo_0.275.840723395 tag=DEMO
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile copies to recover
recovering datafile copy file number=00001 name=+DATA/DEMO/DATAFILE/system.270.840723357
recovering datafile copy file number=00003 name=+DATA/DEMO/DATAFILE/sysaux.268.840723359
recovering datafile copy file number=00005 name=+DATA/DEMO/DATAFILE/sys_undots.269.840723359
recovering datafile copy file number=00006 name=+DATA/DEMO/DATAFILE/test.271.840723361
recovering datafile copy file number=00007 name=+DATA/DEMO/DATAFILE/test2.272.840723361
channel ORA_DISK_1: reading from backup piece +DATA/DEMO/BACKUPSET/2014_02_28/nnndn1_demo_0.276.840723585
channel ORA_DISK_1: piece handle=+DATA/DEMO/BACKUPSET/2014_02_28/nnndn1_demo_0.276.840723585 tag=DEMO
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished recover at 28-FEB-14

Starting Control File and SPFILE Autobackup at 28-FEB-14
piece handle=/oracle/12.0.0.1/dbs/c-3584792132-20140228-05 comment=NONE
Finished Control File and SPFILE Autobackup at 28-FEB-14

RMAN>

Now lets do the switch as normal

[ oracle@server]:DEMO :[ /oracle/12.0.0.1/dbs ]# rman target=/

Recovery Manager: Release 12.1.0.1.0 - Production on Fri Feb 28 14:26:16 2014

Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

connected to target database: DEMO (DBID=3584792132)

RMAN> shutdown;

using target database control file instead of recovery catalog
database closed
database dismounted
Oracle instance shut down

RMAN> startup mount

connected to target database (not started)
Oracle instance started
database mounted

Total System Global Area    1403060224 bytes

Fixed Size                     2681464 bytes
Variable Size               1342178696 bytes
Database Buffers              50331648 bytes
Redo Buffers                   7868416 bytes

RMAN> switch database to copy with tag 'demo';

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "with": expecting one of: ";"
RMAN-01007: at line 1 column 25 file: standard input

Hmm - why can i not tell rman to use that tag name - seems it's not allowed syntax. (a quick read of the docs reveals that switch is always switching to the most recent image backup). So lets do that.

RMAN> switch database to copy;

datafile 1 switched to datafile copy "+DATA/DEMO/DATAFILE/system.270.840723357"
datafile 2 switched to datafile copy "+DATA/DEMO/F378B6BA9C69203DE0430200007FF5F6/DATAFILE/system.273.840723363"
datafile 3 switched to datafile copy "+DATA/DEMO/DATAFILE/sysaux.268.840723359"
datafile 4 switched to datafile copy "+DATA/DEMO/F378B6BA9C69203DE0430200007FF5F6/DATAFILE/sysaux.274.840723365"
datafile 5 switched to datafile copy "+DATA/DEMO/DATAFILE/sys_undots.269.840723359"
datafile 6 switched to datafile copy "+DATA/DEMO/DATAFILE/test.271.840723361"
datafile 7 switched to datafile copy "+DATA/DEMO/DATAFILE/test2.272.840723361"

RMAN> recover database;

Starting recover at 28-FEB-14
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=288 device type=DISK

starting media recovery
media recovery complete, elapsed time: 00:00:00

Finished recover at 28-FEB-14

RMAN> alter database open;

Statement processed

RMAN> 

 And there we have it - we reduced our switching in time to near zero (even for a huge database). Now if you've read the 12c docs you may also have seen that online move of datafiles is allowed here using a simple command - this really does give a zero downtime approach to getting in to ASM.

Comments