Block change tracking and incremental backup
The constant enhancement of Oracle products and its supporting technologies offer the Oracle end-user community a treasure trove of feature-rich backup modalities. The media management layer (MML) is one example of a technology that improved over time and afforded database administrators (DBAs) the ability to back up their relational databases with either a tape or disk methodology. In some organizations, both modalities were leveraged to afford a guarantee of business continuity with multiple backup and recovery methods and storage modalities. This was particularly prevalent in production environments. Yet, as was mentioned in part one of this Oracle blog series, Oracle ultimately gave up developing the MML in concert with other third-party vendors, and opted for a mutually exclusive development life cycle that was less onerous to manage and certify. In response to this change by Oracle, third-party backup vendors strove to enhance their backup software suites and maintain a robust certification and partnering program with Oracle. Free from the MML cycle, Oracle could now develop and enhance more feature-rich functionalities.
The release of 10gR1 (10g “release one”) was greatly anticipated and hailed as a great achievement in Oracle development circles as well as in the end-user community. In the second iteration of this release, 10.1.0.2, a new RMAN feature known as incremental merge was released. The technology was innovative and offered many advantages over the traditional RMAN backupset. Incremental merge leverages RMAN image copies not backupsets.
In our first blog, we discussed that an RMAN image copy is tantamount to an OS copy of every block in the database. The RMAN backupset is the default modality for RMAN backups to tape or disk; the image copy feature only works with disk backups. An image copy is a byte-for-byte backup of the Oracle datafile, whereas a backupset is in RMAN proprietary format, created with PL/SQL blocks of code. The backupset is the technology used for tape-based backups, though it also works with disk. RMAN image copies afford a number of advantages over backupsets as they lend themselves to database cloning more efficiently, and offer a number of ways to clone a database with image copies that do not exist with the backupset modality. When image copies are leveraged with what is known as block change tracking (BCT) this allows a DBA to perform incremental level one backups in perpetuity. This incremental level one forever approach also offers other advantages in that all files backed up (datafiles, archive logs, and control files) will have a single level zero backup (a full image copy), and all subsequent backups will be level one incremental backups. One key point to remember here — the only difference between a level zero incremental backup and a full backup is that a full backup is never included in an incremental strategy. These level one incrementals are ultimately merged with the level zero to create a living, breathing copy of the database that is continuously rolling forward through Oracle recovery mechanisms.
Enabling BCT entails either creating a BCT file or enabling the feature at the SQL*Plus command line connected sys as sysdba. For more information, read Oracle’s document (Doc ID 262853.1) on fast incremental backups using BCT.
Example:
SQL> alter database enable block change tracking using file '/<path>/change_tracking.f';
SQL> alter database enable block change tracking;
BCT allows the DBA to enable the mechanism in the Oracle relational database being backed up. Once the feature is enabled, RMAN then tracks all the blocks in the database that have changed in a change tracking file. This is a type of Oracle datafile in which bitmaps store information about the changed Oracle blocks such that when an incremental backup is executed, RMAN will only back up the changed Oracle blocks as well as no longer needing to scan thru Oracle blocks to ascertain whether or not the block has changed and therefore is a candidate for backup via RMAN.
Another reason that incremental merge became a popular backup modality is the ease of use it affords a DBA when backing up a very large database (VLDB). Since incremental merge is constantly rolling the level zero forward by recovering the level one incrementals on top of it, or merging them with the level zero, this can dramatically reduce the recovery times that are required to recover a VLDB. As a result, this helps meet the very stringent recovery point objectives (RPO) and/or recovery time objectives (RTO) common in service-level agreements (SLAs).
RPO designates the variable amount of data that will be lost or will have to be re-entered during network downtime. RTO designates the amount of “real time” that can pass before the disruption begins to seriously, and unacceptably, impede the flow of normal business operations. For more information on RPO and RTO, read Druva CEO Jaspreet Singh’s blog on the topic.
In addition, there is always a gap between the actuals – Recovery Time Actual (RTA) and Recovery Point Actual (RPA) – and objectives introduced by various manual and automated steps to bring the business application up. These actuals can only be exposed by disaster and business disruption rehearsals.
In its documentation (Doc ID 745798.1), Oracle describes the process as follows:
“Merged Incremental creates a level zero image copy backup of all of your database's datafiles in a disk location. All datafiles are backed up using the same tag name. The Oracle Database 10g feature Block Change Tracking can be used for the incremental level one backups for Fast Incremental Backups. Once a level zero backup copy is created on disk, there is no need for future level 0 backups to be taken. This reduces the load and backup window for VLDB systems. All future backups will be level one backupsets and are used to recover the image copies on disk, thus making the current level zero image backup copies more current each time the level one incremental is applied. Having the level zero image copy newer with each level one incremental backupsets means there is no need to make another level zero backup/image copy of your database.”
As a result, there is no need to merge the incrementals with the full as this has already occurred. A DBA will easily see that this is faster than an RMAN backupset methodology, which would require RMAN to go back to the latest full in a restore scenario and merge the intervening incrementals with the full causing the restore and recovery process to take more time. This is illustrative of how fast database restoration and recovery is with incremental merge, particularly for a VLDB.
The following is from our Druva RMAN incremental merge proprietary script, which invokes RMAN with the appropriate RMAN incremental merge arguments.This proprietary scripting entails using the same RMAN tag name. A run block of the code will reference the tag accordingly.
Code snippet:
run
{
sql 'alter system archive log current';
backup incremental level 1 for recover of copy with tag 'phoenix_oracle_backup' database;
recover copy of database with tag 'phoenix_oracle_backup';
sql 'alter system archive log current';
backup as backupset format '${RMANBACKUP_MOUNTPOINT_FULL}/archivelogs/%d_%h_%e_%s_%t.arc' archivelog all not backed up;
As one can see, the script only invokes a level one incremental backup. RMAN is designed to always perform a level zero baseline, so even if the script uses the following syntax the first full backups will always be a level zero full. The first portion of the script runs the incremental merge, and the second is a backup of the archive logs in a proprietary backupset format. Incremental merge may use the backups of the archive logs in either an image copy format or a backupset format. According to the referenced incremental merge metalink note, you may run the merge nightly like the above Druva proprietary script, or you may choose a date range interval. An example of the code block required to perform the merge at an interval can be found below. The “SYSDATE-7” argument is used, meaning the merge will occur on the eighth day of level one backups.
RECOVER COPY OF DATABASE WITH TAG 'MIB_LEVEL_0' UNTIL TIME "SYSDATE-7" FROM TAG 'MIB_LEVEL_0';
The merge is also written to the Oracle RDBMS alert_SID.log as well. Here is an example of how it looks in our Druva lab environment:
Incremental restore complete of datafile 7 to datafile copy /phoenixbackup/dev18c1/full/full_bk_datafile_data_D-DEV18C1_I-4202439969_TS-USERS_FNO-7_5iutqb9q.rbk
checkpoint is 30116602
last deallocation scn is 29498659
Incremental restore complete of datafile 5 to datafile copy /phoenixbackup/dev18c1/full/full_bk_datafile_data_D-DEV18C1_I-4202439969_TS-USERS_FNO-5_5kutqb9q.rbk
checkpoint is 30116602
last deallocation scn is 29498661
Incremental restore complete of datafile 4 to datafile copy /phoenixbackup/dev18c1/full/full_bk_datafile_data_D-DEV18C1_I-4202439969_TS-UNDOTBS1_FNO-4_5mutqba9.rbk
checkpoint is 30116602
last deallocation scn is 30115666
2021-01-13T10:23:40.341320-05:00
Incremental restore complete of datafile 1 to datafile copy /phoenixbackup/dev18c1/full/full_bk_datafile_data_D-DEV18C1_I-4202439969_TS-SYSTEM_FNO-1_5lutqb9q.rbk
checkpoint is 30116602
last deallocation scn is 1515740
2021-01-13T10:23:42.288370-05:00
Incremental restore complete of datafile 3 to datafile copy /phoenixbackup/dev18c1/full/full_bk_datafile_data_D-DEV18C1_I-4202439969_TS-SYSAUX_FNO-3_5jutqb9q.rbk
checkpoint is 30116602
last deallocation scn is 30099029
2021-01-13T10:23:46.009300-05:00
Control autobackup written to DISK device
handle '/phoenixbackup/dev18c1/dev18c1/full/full_controlfile_DEV18C1_c-4202439969-20210113-00.bkp'
The alert log reveals that RMAN is using SCNs, or Oracle system change numbers, to merge the level one incremental backup with the level zero backup, thus continuously rolling the database forward at each backup with a nightly merge syntax. Were the “SYSDATE -7” argument to be used, the merge would postpone until the eighth day of backups as previously mentioned.
The manner in which DBAs choose to retain their RMAN image copies or backupsets once the backup is completed is called an “RMAN recovery window.” A typical recovery window is seven days of image copy backups. This is hard coded in the controlfile as a persistent parameter that RMAN uses once executed and entered via the command line interface.
Example:
[oracle@oracle_lab_vm ~]$ rman target /
Recovery Manager: Release 19.0.0.0.0 - Production on Wed Jan 13 17:44:36 2021
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
connected to target database: DEV19C1 (DBID=1976305474)
RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name DEV19C1 are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
The first line in the output of the “show all;” command displays the recovery window setting. In the example, when Druva’s Oracle protection solutions utilize incremental merge, the customer will keep seven days of RMAN image copies in the NFS mount that the product has defined for the database. The customer will also have the ability to set retention of RMAN image copies in the Druva Cloud when the mount is created in the Druva console as an administrative user. This retention is mutually exclusive from the RMAN retention, and is highly customizable such customers may set up a retention schedule that covers daily, weekly, monthly, or yearly retention needs.
Next steps
This covers our initial discussions about RMAN and incremental merge as well as RMAN backupsets. We will continue this series in our next blog with a deep dive into Oracle and SBT, and how it works with RMAN and RMAN backupsets. The blog will continue with an exploration of Druva’s new direct-to-cloud product that leverages RMAN backupsets, and our new proprietary SBT tape library that is capable of streaming a RMAN backup from on-premises direct to the Druva Cloud or RMAN SBT backups direct to the Druva Cloud within an AWS EC2 environment. This new technology removes the need for tape and gives organizations the ability to protect their Oracle workloads with the penultimate in Oracle and Druva technology by streaming data directly to the Druva Cloud in AWS with no dependency on intermediate appliances, tapes, tape libraries, hardware, or software.
Download the Druva for Oracle solution brief to learn more about how Druva empowers database, backup, and cloud teams.
References:
- RMAN Fast Incremental Backups using BCT = Block Change Tracking file (Doc ID 262853.1)
- RMAN: Merged Incremental Backup Strategies (Doc ID 745798.1)