Incremental update backup as DBMS backup strategy
To date, there are many backup options for Oracle DBMS, which allow administrators to sleep at night without worrying about what could have happened and how this could have been avoided. Also to help - a lot of software that allows you to simplify the daily routine tasks.
Using Recovery Manager (RMAN), according to official documentation, is the recommended and one of the most optimal ways to backup and restore an Oracle database. And the ability to perform “hot” backups, while leaving the database available for readings and changes, makes this utility a powerful tool for backing up highly available systems.
In this article, I will not talk about all the features of the Recovery manager, but I will describe one of the interesting backup strategies that allows you to take a fresh look at building a fault tolerance system in an enterprise. Technology incrementally updated backup appeared in the 10th version of Oracle. It provides the same recovery capabilities as image image copying, but faster and less stress on system resources. This option also reduces the recovery time due to the smaller number of logs that need to be used to update the data.
The essence of saving data using the Recovery manager is that we once make a complete copy of the database, and then only copy the changes, while every time an incremental backup is executed, the previous one rolls over to the base image, updating the data. As a result, our backup at the physical level always consists of a copy of the data and a change file.
')
Consider an example of execution:
RUN
{
RECOVER COPY OF DATABASE
WITH TAG 'incremental';
Backpack
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incremental'
DATABASE;
}
We can put this team in the schedule for daily execution. Here is how it will be interpreted:
Thanks to the chosen backup strategy, we can restore the database at the time of the last incremental backup. It is permissible to extend the interval while maintaining the possibility of recovery for the period we need in the past, for example, to make a weekly recovery interval: thus, the incremental copy will not update the data until 7 days have passed since it was removed. In this case, a new file with differential changes will be generated every day, which will be taken into account from the previous backup.
Consider an example of a restore command with a window in 7 days:
RUN
{
RECOVER COPY OF DATABASE
WITH TAG 'incremental'
UNTIL TIME 'SYSDATE - 7';
Backpack
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incremental'
DATABASE;
}
Together with an incrementally updated backup, we can use another technology - BLOCK CHANGE TRACKING. When backing up, the recovery manager examines each block of data, tracking changes. The execution time of such a procedure is directly proportional to the size of the data files. It can be quite long, even if only a few blocks have been changed. Starting from version 10, Oracle introduced a new technology - BLOCK CHANGE TRACKING, we can create a special file that records modified blocks from the moment of the previous backup. Then RMAN uses it to determine the changes. It is no longer necessary to fully explore all the available data. Thus, the speed of the incremental copy is directly proportional to the modified blocks. Thanks to the implementation of such a functional, it is possible to significantly reduce the time required to perform a backup.
Using the above strategy for backing up a DBMS, we can quickly recover individual damaged files:
In this case, the instance will now operate on a file that is located in the new location. The same method can return it to its former location.
In case of loss of all files, we can fully restore the entire database, having previously mounted it with the help of the following command:
SWITCH DATABASE TO COPY;
RECOVER DATABASE;
The backup strategy presented in this article is a very effective way to protect a DBMS from data loss. The technology of fixing the already changed blocks in a pair with incremental backup allows you to significantly speed up the daily “hot” backup procedure. And the ability to quickly switch a damaged file to a fresh copy makes it a great help in systems that are critical to recovery time. It is also worth noting the simplicity of deploying a clone base, for example, for the development environment, because our backup is a complete copy that does not require separate file manipulations.
The author - Oleg Konstantinov.
Using Recovery Manager (RMAN), according to official documentation, is the recommended and one of the most optimal ways to backup and restore an Oracle database. And the ability to perform “hot” backups, while leaving the database available for readings and changes, makes this utility a powerful tool for backing up highly available systems.
In this article, I will not talk about all the features of the Recovery manager, but I will describe one of the interesting backup strategies that allows you to take a fresh look at building a fault tolerance system in an enterprise. Technology incrementally updated backup appeared in the 10th version of Oracle. It provides the same recovery capabilities as image image copying, but faster and less stress on system resources. This option also reduces the recovery time due to the smaller number of logs that need to be used to update the data.
Concept
The essence of saving data using the Recovery manager is that we once make a complete copy of the database, and then only copy the changes, while every time an incremental backup is executed, the previous one rolls over to the base image, updating the data. As a result, our backup at the physical level always consists of a copy of the data and a change file.
')
Consider an example of execution:
RUN
{
RECOVER COPY OF DATABASE
WITH TAG 'incremental';
Backpack
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incremental'
DATABASE;
}
We can put this team in the schedule for daily execution. Here is how it will be interpreted:
Day 0
- RECOVER - since there is no incremental backup or full copy, the command has no effect.
- BACKUP - since there is no copy of the data (level 0), the command creates it with the specified tag. This level is required to create a loop.
Day 1
- RECOVER - this time there are copies of the database, but there is no incremental backup of the first level that could be applied. The team has no effect.
- BACKUP - the team creates an incremental backup of the first level and assigns it the necessary tag. It contains changes made from day 0 to 1.
Day 2 and the next
- RECOVER - an incremental backup of the first level, made the previous day, is applied to the base copy, rolling forward the recorded changes.
- BACKUP - the team creates an incremental backup of the first level and assigns it the necessary tag. It contains changes made from day 1 to day 2.
Thanks to the chosen backup strategy, we can restore the database at the time of the last incremental backup. It is permissible to extend the interval while maintaining the possibility of recovery for the period we need in the past, for example, to make a weekly recovery interval: thus, the incremental copy will not update the data until 7 days have passed since it was removed. In this case, a new file with differential changes will be generated every day, which will be taken into account from the previous backup.
Consider an example of a restore command with a window in 7 days:
RUN
{
RECOVER COPY OF DATABASE
WITH TAG 'incremental'
UNTIL TIME 'SYSDATE - 7';
Backpack
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incremental'
DATABASE;
}
Optimization
Together with an incrementally updated backup, we can use another technology - BLOCK CHANGE TRACKING. When backing up, the recovery manager examines each block of data, tracking changes. The execution time of such a procedure is directly proportional to the size of the data files. It can be quite long, even if only a few blocks have been changed. Starting from version 10, Oracle introduced a new technology - BLOCK CHANGE TRACKING, we can create a special file that records modified blocks from the moment of the previous backup. Then RMAN uses it to determine the changes. It is no longer necessary to fully explore all the available data. Thus, the speed of the incremental copy is directly proportional to the modified blocks. Thanks to the implementation of such a functional, it is possible to significantly reduce the time required to perform a backup.
- It should be noted that the size of the change tracking file is very small and does not need any administration at all (the proportion to the total size of all data files is approximately 1 / 30,000).
- By default, the file is located in the FRA zone, but can also be placed in any place that is designated when this functionality is enabled.
- RMAN does not reserve a change tracking file, so if it is damaged or accidentally deleted, you can simply create a new one (respectively, the initial entry of the changed data will be performed anew).
Fast recovery
Using the above strategy for backing up a DBMS, we can quickly recover individual damaged files:
- if the database is open, place the file in offline mode;
- execute the command: switch datafile 'datafile_name' to copy;
- execute the recover command to apply current logs;
- put the file in online mode.
In this case, the instance will now operate on a file that is located in the new location. The same method can return it to its former location.
In case of loss of all files, we can fully restore the entire database, having previously mounted it with the help of the following command:
SWITCH DATABASE TO COPY;
RECOVER DATABASE;
Conclusion
The backup strategy presented in this article is a very effective way to protect a DBMS from data loss. The technology of fixing the already changed blocks in a pair with incremental backup allows you to significantly speed up the daily “hot” backup procedure. And the ability to quickly switch a damaged file to a fresh copy makes it a great help in systems that are critical to recovery time. It is also worth noting the simplicity of deploying a clone base, for example, for the development environment, because our backup is a complete copy that does not require separate file manipulations.
The author - Oleg Konstantinov.
Source: https://habr.com/ru/post/264571/
All Articles