Skip to content
≡

Administrator

Developer

Tools

External Tools

11. Incremental Backup and Recovery#

This chapter explains incremental backups and recovery with incremental backups offered by Altibase.

Incremental Backup#

Altibase can recover lost or damaged data with incremental or full backup.

An incremental backup is a type of backup which only backs up changed data pages from data files after the most recent incremental backup was performed. Compared to a full backup, an incremental backup backs up a lesser amount of data. Not only is disk space necessary for backup saved, but due to lesser disk I/O, backup performance is also faster. Altibase offers incremental backups which physically back up pages of data files and can be executed when the server is online.

Incremental backups are classified as level 0 and level 1. The types of incremental backups are described in the following sections.

The original full backup backs up all data files. For more detailed information on full backups, please refer to Chapter 10. Backup and Recovery of Administrator's Manual.

Types of Incremental Backups#

Incremental backups are classified into level 0 and level 1. A level 0 incremental backup is similar to a full backup, but is a prerequisite for the execution of a level 1 incremental backup. Level 0 incremental backups store backup information to the backupInfo file which enables level 1 incremental backups.

  • Level 0 incremental backups
  • Level 1 incremental backups
    • Differential incremental backups
    • Cumulative incremental backups

Level 0 Incremental Backups#

A level 0 incremental backup is equivalent to a full backup in the sense that all pages of the data files are backed up. However, a full backup cannot be part of an incremental backup strategy. Depending on strategic needs, an incremental backup at either level 0 or level 1 can be selected for use; however, a level 1 incremental backup requires the precedence of a level 0 incremental backup at least once.

The following describes the difference between a level 0 incremental backup and a full backup.

  • A level 0 incremental backup operates in the same manner as a full backup(online full backup); however, a level 0 incremental backup records information about the point in time at which a backup is performed.
  • A level 0 incremental backup establishes criteria for determining whether or not changes have been made to database pages.

Level 1 Incremental Backups#

A level 1 incremental backup only backs up pages that have been changed after the most recently performed incremental backup; therefore, the size of the backup file is small and takes little time to back up. Level 1 incremental backups can be divided into differential incremental backups and cumulative incremental backups.

Differential Incremental Backups#

A differential incremental backup backs up pages that have been changed after the most recently performed incremental backup at level 0 or level 1. For a differential incremental backup, Altibase tracks the most recently performed level 1 incremental backup and backs up all pages which have been changed thereafter.

If a level 1 incremental backup does not exist, all of the pages which have been changed after a level 0 backup are backed up. If even a level 0 incremental backup does not exist, an error is returned that a level 1 backup is impossible.

The size of the backup file generated by a differential incremental backup is smaller than the size of the backup file generated by a cumulative incremental backup and, therefore, takes lesser time to back up. However, if many differential incremental backups are performed and the number of backup files increases, recovery can take longer for a media restoration, due to as many backup files having to be restored.

Cumulative Incremental Backup#

A cumulative incremental backup backs up pages that have been changed after the most recently performed level 0 incremental backup.

As time elapses after a level 0 incremental backup, the size of the backup file of a cumulative incremental backup increases; therefore, it takes longer to back up.

However, if media is restored with a cumulative incremental backup, recovery is faster than with a differential incremental backup, since only the backup file of the most recently performed level 1 incremental backup need to be restored.

Page Change Tracking#

The page change tracking feature enhances the performance of incremental backups by recording changed pages in each data file into page change tracking files.

The page change tracking feature manages the information of pages which have been changed after a level 0 incremental backup in the page change tracking file as bitmaps. Altibase checks these bitmaps and only backs up changed pages when performing a level 1 incremental backup.

One bit of a bitmap corresponds to one or more pages. A bundle of such pages corresponding to one bit is defined as an incremental chunk. If one page of an incremental chunk is changed, all pages of the incremental chunk are backed up. The size of an incremental chunk can be controlled with the INCREMENTAL_BACKUP_CHUNK_SIZE property. For more detailed information on this property, please refer to General Reference > Chapter 2. Altibase Properties.

When tracking is enabled, the server uses the page change tracking file to identify the changed files for an incremental backup, instead of tracking all pages of the data files.

Page change tracking can be enabled with the following statement.

iSQL(sysdba)> ALTER DATABASE ENABLE INCREMENTAL CHUNK CHANGE TRACKING;

This statement can only be executed in the SERVICE phase by the sysdba privilege. When tracking is enabled, the change tracking file and the backupInfo file are created in the $ALTIBASE_HOME/dbs directory.

To disable page change tracking, use the following statement: 

iSQL(sysdba)> ALTER DATABASE DISABLE INCREMENTAL CHUNK CHANGE TRACKING;

This statement can be executed in all phases by the sysdba privilege. When tracking is disabled, the change tracking file is deleted from the $ALTIBASE_HOME/dbs directory.

Note: Even if page change tracking is enabled, changed pages are not immediately tracked. The tracking of changed pages starts when a level 0 incremental backup is performed.

changeTracking File#

The information of changed pages is stored as bitmaps to the changeTracking file. The changeTracking file is a prerequisite for performing an incremental backup. The deletion of the backupinfo file is referenced in the description of the backupinfo file.

The changeTracking file is located in the $ALTIBASE_HOME/dbs directory.

Note:

  • If the changeTracking file is lost or invalid, the SYS user must recreate it by executing a SQL statement which enables changeTracking by the sysdba privilege. When the changeTracking file is recreated, accumulated information of changed pages that have been tracked disappears. Therefore, a level 0 incremental backup must precede a level 1 incremental backup.
  • Change tracking can decrease Altibase server performance. If tracking is disabled in this case, server performance can be improved; however, an incremental backup cannot be performed.

backupInfo File#

The backupInfo file stores information of incremental backups. The incremental backup level, backup type, backup tag name, backup start time, backup completion time and backup file location for each incremental backup are chronologically stored to the backupInfo file.

The backupInfo file provides information necessary for assessing the order of backup files to be restored for a media restoration. if the backupInfo file does not exist, recovery is not possible even if the backup file exists.

The backupInfo file is located in the $ALTIBASE_HOME/dbs directory.

Note: Backup information is stored in chronological order of incremental backups to the backupInfo file. If the backupInfo file is lost, incremental backup files created theretofore can no longer be used. Consequently, the backupInfo file is automatically backed up when an incremental backup is performed.

Deletion of the backupinfo file#

The following command can be executed in the Process phase with sysdba privileges.

iSQL(sysdba)> ALTER DATABASE REMOVE BACKUP INFO FILE;

Examples of Incremental Backups#

The following examples show how to perform a level 0 incremental backup and a level 1 incremental backup for each database and tablespace.

Setting the Backup Path#

The Altibase server manages incremental backup files. Therefore, the following statement must specify the location where the incremental backup file will be stored: 

iSQL(sysdba)> ALTER DATABASE CHANGE BACKUP DIRECTORY '/backup_dir';

Note: This statement can only be executed when change tracking is enabled.

Level 0 Incremental Backups#

As described above, level 0 incremental backups are equivalent to full backups, except that level 0 incremental backups record backup information to the backupInfo file and that level 0 incremental backup files, which are criteria for incremental backups cannot be replaced with full backup files.

Incremental backups on databases#

This is an example of a statement that backs up without specifying a backup tag.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 0 DATABASE;

This is the result of checked files in the backup path after performing backup:

$ ls /backup_dir
TAG_20121030_214906

$ ls /backup_dir/TAG_20121030_214906
SYS_TBS_MEM_DATA-0-0_TAG_20121030_214906.ibak
backupinfo
loganchor1
loganchor0
loganchor2
system001.dbf_TAG_20121030_214906.ibak
SYS_TBS_MEM_DIC-0-0_TAG_20121030_214906.ibak
undo001.dbf_TAG_20121030_214906.ibak

The following example shows how to backup by specifying a backup tag:

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 0 DATABASE WITH TAG 'MONDAY';

This is the result of checked files in the backup path after performing backup:

$ ls /backup_dir
TAG_MONDAY

$ ls /backup_dir/TAG_MONDAY
SYS_TBS_MEM_DATA-0-0_TAG_MONDAY.ibak
backupinfo
loganchor1
loganchor0
loganchor2
system001.dbf_TAG_MONDAY.ibak
SYS_TBS_MEM_DIC-0-0_TAG_MONDAY.ibak
undo001.dbf_TAG_MONDAY.ibak

Incremental Backups on Tablespace#

The following example shows how to back up without specifying a backup tag: 

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 0 TABLESPACE SYS_TBS_MEM_DIC;

This is the result of checked files in the backup path after performing backup:

$ ls /backup_dir
TAG_20121031_040537

$ ls backup_dir/TAG_20121031_040537
SYS_TBS_MEM_DIC-0-0_TAG_20121031_040537.ibak
backupinfo

The following example shows how to backup by specifying a backup tag: 

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 0 TABLESPACE SYS_TBS_MEM_DIC WITH TAG 'MONDAY';

This is the result of checked files in the backup bath after performing backup: 

$ ls /backup_dir
TAG_MONDAY

$ ls backup_dir/TAG_MONDAY
SYS_TBS_MEM_DIC-0-0_TAG_MONDAY.ibak
backupinfo

Level 1 Incremental Backups#

Note: A level 1 incremental backup requires only if the level 0 incremental backup has been performed before at least once.

1 Incremental backups on databases#

This is an example of a statement which performs a differential incremental backup.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 DATABASE;

This is the result of checking files in the backup path after performing backup: 

$ ls /backup_dir
TAG_20121031_043507

$ ls /backup_dir/TAG_20121031_043507
SYS_TBS_MEM_DATA-0-0_TAG_20121031_043507.ibak
backupinfo
loganchor1
loganchor0
loganchor2
system001.dbf_TAG_20121031_043507.ibak
SYS_TBS_MEM_DIC-0-0_TAG_20121031_043507.ibak
undo001.dbf_TAG_20121031_043507.ibak

This is an example of a statement which performs a cumulative incremental backup.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

There is no difference in the names of the files generated from cumulative incremental backups and the names of the files generated from differential incremental backups; however, there is a difference in the file contents.

This is an example of a statement which performs an incremental backup at level 1 by specifying a backup tag.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 DATABASE WITH TAG 'TUESDAY';

This is the result of checking files in the backup path after performing backup: 

$ ls /backup_dir
TAG_TUESDAY

$ ls /backup_dir/TAG_TUESDAY
SYS_TBS_MEM_DATA-0-0_TAG_TUESDAY.ibak
SYS_TBS_MEM_DIC-0-0_TAG_TUESDAY.ibak
backupinfo
loganchor0
loganchor1
loganchor2
system001.dbf_TAG_TUESDAY.ibak
undo001.dbf_TAG_TUESDAY.ibak

Incremental backups on tablespaces#

This is an example of a statement which performs a differential incremental backup.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 TABLESPACE SYS_TBS_MEM_DIC;

This is the result of checking files in the backup path after performing backup:

$ ls /backup_dir
TAG_20121031_211432

$ ls /backup_dir/TAG_20121031_211432
SYS_TBS_MEM_DIC-0-0_TAG_20121031_211432.ibak
backupinfo

This is an example of a statement which performs a cumulative incremental backup.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 CUMULATIVE TABLESPACE SYS_TBS_MEM_DIC;

There is no difference in the names of the files generated from cumulative incremental backups and the names of the files generated from differential incremental backups; however, there is a difference in the file contents.

This is an example of a statement which performs an incremental backup at level 1 by specifying a backup tag.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 TABLESPACE SYS_TBS_MEM_DIC WITH TAG 'WEDNESDAY';

This is the result of checking files in the backup path after performing backup:

$ ls /backup_dir
TAG_WEDNESDAY

$ ls /backup_dir/TAG_WEDNESDAY
SYS_TBS_MEM_DIC-0-0_TAG_WEDNESDAY.ibak
backupinfo

Media Recovery with Incremental Backups#

This section describes media restoration and media recovery with incremental backup files.

Media Restore and Recovery#

Media restoration and recovery using incremental backup files can be performed in the CONTROL startup phase of Altibase.

Media Restore#

If database files are lost due to media failure, the process of copying backup files and replacing the lost files with them is called a restoration

When performing a media restoration with full backup files, DBAs can restore lost data files by using copy commands(e.g., cp); however, when performing a media recovery with incremental backup files, lost data can be restored with the following SQL statement.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE;

Media Recovery#

The application of archive logs to data files that are restored as backup files is called a recovery. Recovery with incremental backups can be performed with the following SQL statement, in the same manner as for recovery with full backups.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE;

Note: Once a media recovery with incremental backup files is complete, a subsequent media recovery can be performed in the same manner as a media recovery with online full backup files, and the recovery steps are also the same.

Recovery Steps with Incremental Backups#

This section outlines the steps of database recovery with incremental backups. First, this section will describe how to restore the changeTracking file and the backupInfo file, and then explains how to perform a database recovery will be explained.

If a media failure occurs and the changeTracking file or the backupInfo file in the $ALTIBASE_HOME/dbs directory is lost, the server cannot be started in the CONTROL phase. In this case, the server must be started in the PROCESS phase and the following operations must be executed on the changeTracking file and the backupInfo file.

changeTracking file#

This file is not needed for a media restoration. Thus, the following statement must be executed to disable the server from further tracking this file.

iSQL(sysdb)> ALTER DATABASE DISABLE INCREMENTAL CHUNK CHANGE TRACKING;

backupInfo file#

This file is needed for a media recovery and is automatically backed up when an incremental backup is performed. Thus, this file must be restored from the path of the most recently performed incremental backup, with the copy command.

$ cp /backup_dir/BACKUP_TAG/backupInfo $ALTIBASE_HOME/dbs

As described in the previous chapter, the following two incomplete recovery methods are supported for full backups.

Incomplete recovery to a specific point in time:#

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL TIME '2012-10-31:17:55:00';

Incomplete recovery to the point in time of a valid log:#

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL CANCEL;

For incremental backups, apart from the aforementioned two methods, incomplete restoration and recovery with backup tag names are supported.

Incomplete restoration with backup tag names:#

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE FROM TAG 'TUESDAY';

Incomplete recovery with backup tag names:#

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE FROM TAG 'TUESDAY';

Since log files are not used for media restoration with incremental backups, the ALTER DATABASE RESTORE DATABASE UNTIL CANCEL statement is not supported (however, the UNTIL TIME statement is supported).

For recovery after an incomplete restoration with backup tag names, the backup tag name used for restoration and recovery must be the same. If different backup tag names are used for restoration and recovery, as shown below, recovery fails. 'TUESDAY', instead of 'SUNDAY', must be used to ensure a successful recovery.

ALTER DATABASE RESTORE DATABASE FROM TAG 'TUESDAY';
ALTER DATABASE RECOVER DATABASE FROM TAG 'SUNDAY';

If the user wishes to restore with the backup tag 'TUESDAY' and perform an incomplete recovery to a point in time thereafter, the UNTIL TIME or UNTIL CANCEL statement must be used as follows.

ALTER DATABASE RESTORE DATABASE FROM TAG 'TUESDAY';
ALTER DATABASE RECOVER DATABASE UNTIL CANCEL;

Examples of Media Restoration#

Before giving examples of media restoration and recovery, let us assume that the following incremental backups have been made.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 0 DATABASE WITH TAG 'MONDAY';
iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 DATABASE WITH TAG 'TUESDAY';
iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 DATABASE WITH TAG 'WEDNESDAY';
iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 0 DATABASE WITH TAG 'THURSDAY';
iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 DATABASE WITH TAG 'FRIDAY';
iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE WITH TAG 'SATURDAY';
iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 DATABASE WITH TAG 'SUNDAY';

Complete Restoration#

A complete restoration can be performed with the following statement.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE;

The execution of this statement restores to the most recently performed level 0 incremental backup (tag name: 'THURSDAY') first. This statement then restores to the level 1 cumulative incremental backup (tag name: 'SATURDAY') and ultimately restores to the level 1 differential incremental backup (tag name: 'SUNDAY').

Incomplete Restoration#

Incomplete restoration to the backup tag name 'WEDNESDAY'#

An incomplete restoration to the backup tag name 'WEDNESDAY' can be performed with the following statement.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE FROM TAG 'WEDNESDAY';

The execution of this statement restores to the most recently performed level 0 incremental backup with the tag name 'MONDAY', prior to the backup tag name 'WEDNESDAY'. This statement then restores to a level 1 differential incremental backup with the tag names, 'TUESDAY' and 'WEDNESDAY'

Incomplete restoration to the backup tag name 'SATURDAY'#

An incomplete restoration to the backup tag name 'SATURDAY' can be performed with the following statement.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE FROM TAG 'SATURDAY';

The execution of this statement restores to the most recently performed level 0 incremental backup with the tag name 'THURSDAY', prior to the backup tag name 'SATURDAY'. This statement then restores to a level 1 differential incremental backup with the tag name 'SATURDAY'.

Examples of Media Recovery#

Complete Recovery#

Complete recovery after complete restoration#

With the following statement, restore data files from the most recently performed backup with the backup tag 'SUNDAY'.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE;

Using media restoration, apply the archive logs to the current point in time.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE;

Since the files for the system temporary tablespace SYS_TBS_DISK_TEMP cannot be backed up, manually create the files and then start the server.

iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE 'temp001.dbf';
iSQL(sysdba)> STARTUP SERVICE;

Complete recovery after incomplete restoration#

With the following statement, perform an incomplete restoration from the backup tag name 'WEDNESDAY'.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE FROM TAG 'WEDNESDAY';

Using media recovery, apply the archive logs, from the backup tag name 'WEDNESDAY' to the current point in time.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE;

Since the files for the system temporary tablespace SYS_TBS_DISK_TEMP cannot be backed up, manually create the files and then start the server.

iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE 'temp001.dbf';
iSQL(sysdba)> STARTUP SERVICE;

A complete recovery after incomplete restoration is a recovery method which can be used when incremental backup files have been lost. In this case, after performing restoration with backup files prior to the lost incremental backup files, a complete recovery with archive logs can be performed.

Incomplete Recovery#

Incomplete recovery after complete restoration#

The loganchor file and the backupInfo file of the past are necessary for an incomplete restoration. After an incomplete recovery with the loganchor file and the backupInfo file is performed to a point in time in the past, and the logs are reset with the ALTER DATABASE MYDB META RESETLOGS statement, the backup files corresponding to backup information which exist in the most recent backupInfo file prior to the recovery, but do not exist in the backupInfo file restored to the past, are no longer available for use.

Restore the loganchor file and the backupInfo file using the loganchor and backupInfo files of a point in time in the past at which an incomplete recovery is desired, as follows.

$ cp /backup_dir/TAG_WEDNESDAY/ loganchor* $ALTIBASE_HOME/logs
$ cp /backup_dir/TAG_WEDNESDAY/ backupinfo $ALTIBASE_HOME/dbs

Since the loganchor file has been restored to an older version, the changeTracking file is no longer valid. Thus, the changeTracking file must be deleted by disabling change tracking with the following statement when the server is in the PROCESS phase.

iSQL(sysdba)> ALTER DATABASE DISABLE INCREMENTAL CHUNK CHANGE TRACKING;

The following statement restores the datafile from the most recent backup with tag name 'SUNDAY'.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE;

After restoring the database, perform an incomplete recovery using archive logs.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL CANCEL;

Since the files for the system temporary tablespace SYS_TBS_DISK_TEMP cannot be backed up, execute resetlogs and then start the server, after manually creating the files.

iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE 'temp001.dbf';
iSQL(sysdba)> ALTER DATABASE MYDB META RESETLOGS;
iSQL(sysdba)> STARTUP SERVICE;

Incomplete recovery after incomplete restoration#

Restore the loganchor file and the backupInfo file using the loganchor file and the backupInfo file of a point in time in the past at which an incomplete recovery is desired, as follows.

$ cp /backup_dir/TAG_WEDNESDAY/ loganchor* $ALTIBASE_HOME/logs
$ cp /backup_dir/TAG_WEDNESDAY/ backupinfo $ALTIBASE_HOME/dbs

Since the loganchor file has been restored to an older version, the changeTracking file is no longer valid. Thus, the changeTracking file must be deleted by disabling change tracking with the following statement when the server is in the PROCESS phase.

iSQL(sysdba)> ALTER DATABASE DISABLE INCREMENTAL CHUNK CHANGE TRACKING;

Restore the datafile from the most recently performed incremental backup, prior to the point in time at which an incomplete recovery is desired, with the following statement.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE FROM TAG 'WEDNESDAY';

Perform an incomplete recovery, after an incomplete restoration.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL CANCEL;

Execute resetlogs and start the server.

iSQL(sysdba)> ALTER DATABASE MYDB META RESETLOGS;
iSQL(sysdba)> STARTUP SERVICE;

Managing Backup Files#

Unlike full backups, backup files generated from incremental backups are managed by the Altibase server, instead of the DBA.

Specifying/Changing the Backup Path#

The location of backup files generated by performing an incremental backup can be specified with the following statement. The backup path must be specified before performing a backup.

iSQL(sysdba)> ALTER DATABASE CHANGE BACKUP DIRECTORY '/backup_dir';

If the previously specified path has insufficient disk space, a new backup path can be specified with the above statement.

If the transfer rate of backup files is slow or the size of the generated backup files cannot be retained in one backup device, changing the backup path is an appropriate way to manage disk space.

Transferring Backup Files#

When the backup path lacks disk space, backup files can be transferred to a path of another device in either of the following ways:

  1. Change only the backup file path in the backupInfo file with a SQL statement, and manually transfer old backup files with the copy command(cp).

    iSQL(sysdba)> ALTER DATABASE MOVE BACKUP FILE TO '/backup_dir2';

    $ cp ... /backup_dir2

  2. Simultaneously change the backup file path in the backupInfo file and transfer backup files with a SQL statement.

    iSQL(sysdba)> ALTER DATABASE MOVE BACKUP FILE TO '/backup_dir2' WITH CONTENTS;

Deleting Backup Files#

Extra disk space can be secured by deleting backup files past the expiration date with the following statement.

iSQL(sysdba)> ALTER DATABASE DELETE OBSOLETE BACKUP FILES;

This statement only deletes the backup files displayed in the V$OBSOLETE_BACKUP_INFO performance view. No files will be deleted if nothing is queried in this performance view.