0

i need to restore my backup at different database server with following sequence on daily basis

level 0 incremental only once level 1 incremental everyday

i did the level 0 restore successfully however when i was restoring the incremental backup using the incremental backup level 1 control file i noticed that RMAN was reading the full backup files and allocating almost the same space used to restore the level 0 back .

my question is can i restore incremental level 1 backups on daily basis without restoring the level 0 backup ? also why the rman allocate more space for each restore if the datafiles already exists from the level 0 backup ?

below are the scripts used for full and inc backup

Full

#!/bin/bash ORACLE_HOME=/u01/app/oracle/product/12.2.0.1/dbhome_1

ORACLE_SID=cdb11

PATH=$PATH:$ORACLE_HOME/bin

DD=date +%Y-%m-%d-%H-%M

export ORACLE_HOME ORACLE_SID PATH DD

mkdir /ArchiveDBBackup/DAILY_RMAN/${DD}

LOGFILE=/ArchiveDBBackup/DAILY_RMAN/log/DAILY_FULLBKP_date +%Y%m%d.log

rman target / LOG $LOGFILE <<EOF run { backup as compressed backupset incremental level 0 DEVICE TYPE DISK TAG='DAILY_BACKUP' FORMAT '/ArchiveDBBackup/DAILY_RMAN/${DD}/DAILY_FULLBKP_%D_%T_%s-%p' check logical database plus archivelog; backup current controlfile format '/ArchiveDBBackup/DAILY_RMAN/${DD}/CDB1_CONTROLFILE_%D_%T_%s-%p'; backup spfile format '/ArchiveDBBackup/DAILY_RMAN/${DD}/CDB1_SPFILE_%D_%T_%s-%p'; } EOF

INC

#!/bin/bash

ORACLE_HOME=/u01/app/oracle/product/12.2.0.1/dbhome_1

ORACLE_SID=cdb11

PATH=$PATH:$ORACLE_HOME/bin

DD=date +%Y-%m-%d-%H-%M

export ORACLE_HOME ORACLE_SID PATH DD

mkdir /ArchiveDBBackup/DAILY_INC/${DD}

LOGFILE=/ArchiveDBBackup/DAILY_INC/log/DAILY_INCBKP_date +%Y%m%d.log

rman target / LOG $LOGFILE <<EOF run { backup as compressed backupset INCREMENTAL LEVEL 1 DEVICE TYPE DISK TAG='DAILY_INC' FORMAT '/ArchiveDBBackup/DAILY_INC/${DD}/DAILY_INCBKP_%D_%T_%s-%p' check logical database plus archivelog; backup current controlfile format '/ArchiveDBBackup/DAILY_INC/${DD}/CDB1_CONTROLFILE_%D_%T_%s-%p'; backup spfile format '/ArchiveDBBackup/DAILY_INC/${DD}/CDB1_SPFILE_%D_%T_%s-%p'; } EOF

0

2 Answers 2

0

Incremental backups make copies of all data blocks changed since the previous incremental backup. If you have updated a lot of data, or if the daily amount of archive logs is significantly larger than the size of most data files, that could add up to almost as much space required as a full backup.

As for the restore, RMAN must always start from the most recent complete level 0 backup and then apply all incremental changes on top of that to reach the desired point in time or SCN value. You can't restore from just a level 1 backup because it only contains changes, not the baseline starting point for all data.

Have you considered using rman's "duplicate database" feature, as described here: https://docs.oracle.com/database/121/BRADV/rcmdupdb.htm#BRADV010 ?

3
  • appreciate your response alot , i do understand that incremental backups must be restore on top of level 0 backups . but i mean if i restore level 0 backup and opened the database , can i restore the incremental backups that been taken after on the source database ? Jun 28, 2021 at 11:48
  • 1
    No. Every restore must start from the same point. Once you open the database you have introduced new changes not present in the backups, so if you want to restore to a different point in time you have to go back to the baseline.
    – pmdba
    Jun 28, 2021 at 11:51
  • Thanks , that answered it ^_^ Jun 29, 2021 at 7:25
0

You don't state the purpose of the second database, but you might want to consider using DataGuard to create a Snapshot Standby database. (That's the plain vanilla, "free" sort of DataGuard, not the "Active" version that costs you money - although the latter might be another option for you).

DataGuard is a Disaster Recovery technology that can use log shipping to maintain copies of a Primary database. In this case, you start by creating a Physical Standby database, a complete copy of your Primary database which is is permanently in Recovery mode, receiving redo from the Primary.

Then, when you want to use this Standby, you "unplug" it from DataGuard and open it, just like any other database - this is the Snapshot Standby. You can use this database in any way you like, even writing changes to it (but don't).

When you want to "refresh" the Standby from the Primary, you "plug" it back into DataGuard, which will then "catch-up" all the redo logs generated on the Primary, bringing the Standby back up to date.

Warning: This requires a lot of disk space.
Not only do you need to buffer all of the redo logs generated on the Primary (which are held in the FRA on both the Primary and the Standby) but you'll also need Flashback [Database] logging in place. This is used by DataGuard to "flashback" the Standby database to the point it was "unplugged" from the Primary, so that redo Apply can pick up where it left off.
(Remember when I said you shouldn't make changes to the Snapshot Standby? This is why!)

If you have the money for it, you might also consider "Active" DataGuard.
In this arrangement, you have a Physical Standby database, permanently connected to the Primary and receiving redo all the time, but the "Active" part allows you to run queries against it as well. I'm pretty sure you can't make any changes, though.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.