40. Incremental Backup (Differential, Cumulative), Restoring all the datafiles along with control file - Agnivo102/Database_Architect GitHub Wiki

Backup of Undo File:

We don't restore undo data file in industry. In undo data file only those data block resides which currently has a lock applied to it due to an incomplete transaction. So we don't need to restore this data file though we take it in backup. Because see when we take backups we need that restore the files later if it got deleted. So undo data file which is in backup will be never needed in a later point of time when the transactions are already over. If it got deleted we create a new one and change the default undo tablespace to a new one by alter system command.

Create undo tablespace undo2 datafile 'path' size 20M autoextend on next 10M maxsize 100M;

Alter system set undo_tablespace = undo2 scope = both;

This is how it's done in the industry using these commands.

Incremental Backup:

In real time database which are huge in industries like 100 TB. To take that backup it will be take a lot of time. So a scheduled backup is only taken when the transaction traffic is very less like midnight. So the concept of this Incremental Backup come into picture.

2 types:-

Incremental Differential Backup:

As we can see from the image this is how its works.

In a sunday a level 0 backup is taken.

Level 0 Backup:

Same as Full backup i,e taken from the database creation time up to current point of time. Just at the end of the backup a note is attached with the time when the backup is taken. One difference of level 0 backup with the full backup is that level 0 backup will check if there is any last 0 level backup present. If the last level 0 backup is found, then it will take the backup for the changes that happened after the last level 0 backup. If there is no last level 0 backup present the rman will take the full backup. Incremental Level 0 backup falls under incremental backup but it also a type of full backup.

From monday a level 1 Backup is taken.

Level 1 Backup:-

When taking a level 1 backup it will look for the time when the last level 1 backup is taken. If there is no level 1 backup present then it will look for the last level 0 backup. After finding it, only those datafiles backup will be taken which has been modified after the time of the last level 0 backup. If it finds a level 1 backup first then it will take the backup of those data files which has been modified later after the time of the last backup.

If the process didn't find any previous level 0 backup it will take a level 0 backup.

Reason for using this type of backup:

This is used because in industry the database is huge like 100 TB. We don't have that much storage to take Full backup everytime as storage is expensive. So for that this is done. The size of a level 0 backup will be the same as the size of the database i,e 100 TB. The size of a level 1 backup taken from the time of the last level 0 or level 1 backup will be max 1- 10 TB (max only if there is a huge amount of transaction that day). This saves a huge amount of space. Also due to this mechanic that does a full backup at one time, the next backups taken in continuation after a regularly interval of time, continuing the flow of taking the backup of the changes that happens after the last backup, this makes sure we don't miss a thing and everything happening to the data's is backed up sequentially.

Now how is this feature works. In control files the timestamp of every backups taken is stored. Also it stores the SCN of each commits taking place. Through the time of commit it knows which modifications is done at which point of time and it can easily compare that time with he backup taking time which it stores.

How it happens in industry:

Incremental Differential backup happens like this. In sunday there is a level 0 backup. In Monday a level 1 backup is taken which takes the backup from the time of last level 0 backup which is sunday. In Tuesday another level 1 backup is taken which is from last level 1 backup which is monday. This is how the cycle goes. In an industry after some specific amount of time depending on the industry another level 0 Incremental backup is taken. Then the cycle goes on.

Now if in Wednesday the Tuesday's backup got deleted then there is no problem as the new backup is taken from the last available level 1 backup i,e from Monday. This is not problem.


Problem with Incremental Differential Backup:

The problem arises when Tuesday's backup got deleted in Thursday and Wednesday's backup is ok. Because in Thursday the process will try to find the last level 1 backup which it will find in Wednesday and it will start taking the backup after Wednesday's backup. The Tuesday's backup remains absent. Since the cycle got broken and the backups are taken part by part in continuous small backups (level 1 backup), Tuesday' data will be lost and cannot be recovered. This is a disadvantage with Incremental Differential backup.

In this case Wednesday's level 1 backup is available so the incremental differential backup process will take the backup from Wednesday. Tuesday's backup which got deleted has no way to be recovered and the cycle got broken.

Commands:

backup incremental level 0 database;: To take incremental level 0 backup.

backup incremental level 0 database tag 'Level 0';: Add a tag to the backup to know which backup is which better.

backup incremental level 1 database tag 'Level_1';: Takes a level 1 incremental backup.

Lets take a incremental differential backup:

See with list backup we can see the tag and the type of backup (0 or 1).

We can use restore database level_0; (the tag name we used and it will start restoring from this backup.

Level 1:

Incremental Cumulative Backup;

For Incremental Cumulative Backup the first step is the same as taking a Incremental Differential Backup which is taking a level 0 backup. The place where it differents is that in case of Cumulative level 1 backup, the backup is always taken from the time of the last level 0 backup, it will not be taken from last level 1 backup like in case of differential even if last level 1 backup is present like shown in the picture.

Pros:

This makes it much more durable and has less risk of breaking the cycle like it can with Incremental Differential backup. And in the end of a weak the backups of the starting days of the weak can be safely deleted to save more space as nothing is getting lost in this case as long as the last level 1 backup stays intact.

Cons:

The disadvantage is that that this takes nuch more space than Incremental Differential Backup for obvious reasons as in this case the size of level 1 backups is much more. So this is more expensive.

Commands:

For cumulative and differential backup the command is same for level 0 backup.

backup incremental level 0 database tag 'level_0_cumulative';

backup incremental level 1 cumulative database tag 'level_1_cumulative'; Takes a cumulative type level 1 backup.

By using tag we can differentiate between cumulative and differential tyoe backup as there is no other way to differentiate them.

View to checkup details on backups:

v$backup_set_details

select incremental_level, to_char(start_time, 'dd/mm/yyyy HH24:mi:ss'), to_char(completion_time, 'HH24:mi:ss'), pieces, status from v$backup-set_details;

Status A is available.

Now lets delete one backup and see in the view.

Doing a alter system log switch refreshes the control file in database memory. So after deleting the backup and deleting expired backup in rman tool using log switch refresh the comtrol file and removes the deleted backup from the list.

Restoring the database if everything got deleted with control files:

Deleting the files:

Deleting the other control file in fast recovery area.

Now shutdown abort the database as there is no control file other shutdowns will fail.

Now start the database in nomount. We can do that since the spfile is still here.

Now go to rman and first restore control file.

restore controlfile from 'location of the control file in backup';

This time you have to give the location of the backup mnaually. Since control file is gone and it is the physical repository of the backup, so this time the rman tool doesn't know the location of the backup.

Restore the control file from the most recent backup.

Now we can alter the database to mount now that the control file is back.

Now we have to run a script to restore the database in rman tool. We can write the statements separately too but we can to it together using this:

run { restore database; recover database; alter database open resetlogs; //We can run an sql statement inside rman tool like alter database open. And whenever we restore the control file we have to reset the logs. }

See everything got restored and the database got opened.

See all the data file and control files are back.