DBA Hub

📋Steps in this guide1/4

Incrementally Updated Backups : Rolling Forward Image Copies Using RMAN

Speed up backup and recovery time by rolling your image copy backups forward using incremental backups.

oracle miscconfigurationintermediate
by OracleDba
15 views
1

Incrementally Updated Backups

The following example shows how an incrementally updated backup can be used. The line will not do anything until the script has been running for more than 7 days. The line will perform image copy backups the first day it is run (and for any new datafiles), with all subsequent backups being level 1 incremental backups. After 7 days, the line will start to take effect, merging all incremental backups older than 7 days into the level 0 backup, effectively moving the level 0 backup forward. The effect of this is that you will permanently have a 7 day recovery window with a 7 day old level 0 backup and 6 level 1 incremental backups. Notice that the tag must be used to identify which incremental backups apply to which image copies. The following script uses the same method, but includes the archivelog backups and management of obsolete backups. If you wanted to keep your image copy as up to date as possible you might do the following. In this example the incremental backup is merged into the image copy as soon as it is completed. For best performance, this method should be combined with block change tracking, explained below.

Code/Command (click line numbers to comment):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
RUN {
  RECOVER COPY OF DATABASE WITH TAG 'mydb_incr_backup' UNTIL TIME 'SYSDATE - 7';
  BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'mydb_incr_backup' DATABASE;
}

RUN {
  RECOVER COPY OF DATABASE WITH TAG 'mydb_incr_backup' UNTIL TIME 'SYSDATE-7';
  DELETE NOPROMPT OBSOLETE DEVICE TYPE DISK;
  BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'mydb_incr_backup' DATABASE;
  BACKUP DEVICE TYPE DISK TAG 'mydb_incr_backup' ARCHIVELOG ALL NOT BACKED UP DELETE ALL INPUT;
  DELETE NOPROMPT OBSOLETE DEVICE TYPE DISK;
}

RUN {
  BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'mydb_incr_backup' DATABASE;
  RECOVER COPY OF DATABASE WITH TAG 'mydb_incr_backup';
}
2

Incrementally Updated Backups and Compression

Binary compression can be used in conjunction with incrementally updated image copy backups. In the following example, the clause is added to both the backup commands. This will cause both incremental and archivelog backups to be compressed, since they are backup set backups. If there is no level 0 backup, the presence of the clause causes an image copy backup to be performed, rather than a backup set backup. Image copies are never compressed. So you end up with an uncompressed level 0 image copy backup, but all subsequent incremental and archivelog backups are compressed backup set backups.

Code/Command (click line numbers to comment):

1
2
3
4
5
6
RUN {
  RECOVER COPY OF DATABASE WITH TAG 'mydb_incr_backup' UNTIL TIME 'SYSDATE-7';
  BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'mydb_incr_backup' DATABASE;
  BACKUP AS COMPRESSED BACKUPSET DEVICE TYPE DISK TAG 'mydb_incr_backup' ARCHIVELOG ALL NOT BACKED UP DELETE ALL INPUT;
  DELETE NOPROMPT OBSOLETE DEVICE TYPE DISK;
}
3

Restoring From Image Copies

Using image copy backups allow two recovery options. - Conventional restore and recovery : Image copies are copied from the backup location to the original datafile location, then they are recovered using any existing incremental backups and archived redo logs. - : To improve recovery time, the restore of the image copy can be omitted and the image copy can be used in place as the new datafile. The image copies must still be recovered using any existing incremental backups and archived redo logs, so only the file copy time is saved. Remember, if the image copy is used in place, you have lost your image copy backup! Examples of conventional recoveries are shown below. Examples of the approach are shown below.

Code/Command (click line numbers to comment):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# Complete
RUN {
  SHUTDOWN IMMEDIATE;
  STARTUP MOUNT;
  RESTORE DATABASE;
  RECOVER DATABASE;
  ALTER DATABASE OPEN;
}

# Incomplete - Point In Time Recovery (PITR)
RUN { 
  SHUTDOWN IMMEDIATE;
  STARTUP MOUNT;
  SET UNTIL TIME "TO_DATE('15-NOV-2004 00:09:00','DD-MON-YYYY HH24:MI:SS')";
  #SET UNTIL SCN 1000;       # alternatively, you can specify SCN
  #SET UNTIL SEQUENCE 9923;  # alternatively, you can specify log sequence number
  RESTORE DATABASE;
  RECOVER DATABASE;
  ALTER DATABASE OPEN RESETLOGS;
}

# Switch whole database to image copy backups.
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
SWITCH DATABASE TO COPY; # No restore, just switch
RECOVER DATABASE;
ALTER DATABASE OPEN;

# Switch an individual file.
SQL "ALTER DATABASE DATAFILE 3 OFFLINE";
SWITCH DATAFILE 3 TO COPY;
RECOVER DATAFILE 3;
SQL "ALTER DATABASE DATAFILE 3 ONLINE";
4

Block Change Tracking

There are performance issues associated with incremental backups as the whole of each datafile must be scanned to identify changed blocks. From Oracle 10g onward it is possible to track changed blocks using a change tracking file. Enabling change tracking does produce a small overhead, but it greatly improves the performance of incremental backups. The current change tracking status can be displayed using the following query. Change tracking is enabled using the command. By default the change tracking file is created as an Oracle Managed File (OMF) in the location pointed to by the parameter. An alternate location can be specified using the following command. The tracking file is created with a minumum size of 10M and grows in 10M increments. It's size is typically 1/30,000 the size of the datablocks to be tracked. Change tracking can be disabled using the following command. Renaming or moving a tracking file can be accomplished in the normal way using the command. If the instance cannot be restarted you can simply disable and re-enable change tracking to create a new file. This method does result in the loss of any current change information. For more information see: Hope this helps. Regards Tim...

Code/Command (click line numbers to comment):

1
2
3
4
5
6
7
8
SELECT status FROM v$block_change_tracking;

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING 
  USING FILE '/u01/oradata/mydb/rman_change_track.f' REUSE;

ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

Comments (0)

Please to add comments

No comments yet. Be the first to comment!