The subsequent incremental backups will rman incremental backups

Backup Best Practices for Data Warehouses 313

WITH TAG 'incremental_update';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incremental_update' DATABASE PLUS ARCHIVELOG DELETE INPUT;
}

Run {
RECOVER COPY OF DATABASE
WITH TAG 'incremental_update';
BACKUP AS COMPRESSED BACKUPSET
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incremental_update' DATABASE PLUS ARCHIVELOG DELETE INPUT;
}

The Third Execution of the Command

The keyterm is retention, or, how long do we need to be able to go back in time and restore the database (or a copy of the database) for business purposes. Currently, our script offers us pretty much no retention criteria. As soon as we run it, the ability to restore the database to the previous day with RMAN is no longer possible.

So, you need to determine what the requirements for point-in-time recovery actually are.

Run {
RECOVER COPY OF DATABASE
WITH TAG 'incremental_update'
UNTIL TIME ’SYSDATE-7’;
BACKUP AS COMPRESSED BACKUPSET
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incremental_update' DATABASE PLUS ARCHIVELOG DELETE INPUT;
}

The effect of adding the UNTIL TIME clause is that the incremental backups will not be wrapped into the image copies of the database until seven days has passed. This results in more incremental backups being stored on media to support the required recovery point. Table 7.3 provides a quick look at the progress of a backup and its backup files given the previous command.