Delete Orphaned Datafile Copies

Oracle Incrementally Updated Backups : Detect and Delete Orphaned (Expired) Datafile Copies

Oracle recommends adopting a merged incremental disk backup strategy to ensure efficient database protection and faster recovery times. This approach involves maintaining an up-to-date image copy of the database as the base backup while continuously applying incremental backups to it on the fly.

When using the Oracle recommended disk backup strategy, the retention policy should be set to REDUNDANCY 1, and the image copy should ideally be created within the Fast Recovery Area (FRA). FRA provides a centralized and managed location for backup and recovery files. Block Change Tracking (BCT) is highly recommended as it enhances incremental backup efficiency by recording changes to database blocks since the last backup, eliminating the need to scan the entire database during backup operations. Cumulative incremental backups should be taken and applied daily to roll forward the base backup.

We use a script similar to provided below.

This strategy enables quick failover using the SWITCH DATABASE TO COPY command, allowing the database to point directly to the updated image copy without requiring a restore operation. Fewer archive logs are needed for recovery since the image copy is consistently rolled forward. For instance, only logs from the last 24 hours might be necessary if incremental updates are applied daily.

However, maintaining a full image copy of the database requires additional disk space, which may be a limitation for larger databases. Another limitation is that point-in-time recovery is restricted to dates after the last incremental backup was applied to the image copy. For example, if the image copy is updated daily, recovery to a point earlier than 24 hours may require alternative backup strategies.

This strategy works best when the retention policy is set to REDUNDANCY 1. If a different retention policy, such as RECOVERY WINDOW, is used, RMAN may not satisfy the policy with only one up-to-date image copy. To address this, DBAs need to create custom scripts to retain older versions of the image copy. For example, if a recovery window of seven days is required, the image copy must be retained for at least eight days using the UNTIL clause.

The database copy cannot be compressed or encrypted.

I want to share another important point I recently encountered, which I believe is often forgotten.

When you drop a tablespace or delete a datafile in Oracle, the datafiles associated with the base image copy are not automatically removed from the file system or ASM (Automatic Storage Management).

While the original datafile is dropped during the operation, its corresponding backup or image copy remains intact in the backup location. This behavior ensures that any backups, particularly those created for recovery purposes, are preserved unless explicitly removed. Since backup policies are typically written once and not revisited, these datafile copies are often forgotten in fast recovery area

To handle these leftover image copies, you must either manually delete the files from the file system or use RMAN commands to manage them. In our case, there were 20 datafiles leftover in the Fast Recovery Area. You can also detect the anomaly by comparing the count from v$datafile with the number_of_files value in v$recovery_area_usage.

SQL> select count(*) as datafile_count from v$datafile

DATAFILE_COUNT

————————————

298

SQL> select number_of_files from v$recovery_area_usage where file_type = ‘IMAGE COPY’;

NUMBER_OF_FILES

—————————————-

318

After identifying discrepancies in the number of datafiles between the database and the image copy, you can compare the outputs of v$datafile and v$datafile_copy, or use the RMAN command LIST DATAFILECOPY ALL.

You may delete the current database copy and take a new base backup. However, this method will require backing up all datafiles again, without utilizing incremental backups, which may result in a longer backup duration, especially for large databases. Alternatively, you can manually remove the leftover datafiles from the file system or ASM using the rm command. Afterward, perform a crosscheck in RMAN to detect the absence of these datafile copies. Then, you can run the DELETE EXPIRED command to remove the metadata of these backups from the catalog or control file.

You may feel comfortable deleting them once you’re certain that you’re in the fast_recovery_area and not in the db_create_file_dest location.

Implementing a merged incremental disk backup strategy ensures efficient database protection and faster recovery by maintaining an up-to-date image copy as the foundation for incremental updates. Additionally, DBAs must remain proactive in managing orphaned datafiles after tablespace deletions to keep the base image copy synchronized with the database and prevent unnecessary storage consumption.

Hope it helps.


Discover More from Osman DİNÇ


Comments

Leave your comment