A la hora de configurar un backup incremental en el que esté involucrado BCT (Block Change Tracking) tendremos que tener en cuenta lo siguiente:
Referencia documentación RMAN
The change tracking file maintains bitmaps that mark changes in the data files between backups. The database performs a bitmap switch before each backup. Oracle Database automatically manages space in the change tracking file to retain block change data that covers the 8 most recent backups. After the maximum of 8 bitmaps is reached, the most recent bitmap is overwritten by the bitmap that tracks the current changes.
The first level 0 incremental backup scans the entire data file. Subsequent incremental backups use the block change tracking file to scan only the blocks that have been marked as changed since the last backup. An incremental backup can be optimized only when it is based on a parent backup that was made after the start of the oldest bitmap in the block change tracking file.
Consider the 8-bitmap limit when developing your incremental backup strategy. For example, if you make a level 0 database backup followed by 7 differential incremental backups, then the block change tracking file now includes 8 bitmaps. If you then make a cumulative level 1 incremental backup, RMAN cannot optimize the backup because the bitmap corresponding to the parent level 0 backup is overwritten with the bitmap that tracks the current changes.
Por lo que hemos visto, para ajustarlo debemos tener claro. ¿Cuántas copias de seguridad incrementales se van a realizar desde la última copia de seguridad completa?
Si nos pasamos del valor por defecto de 8 nos encontraremos con la siguiente problemática:
2024-07-04T00:01:45.557560+02:00
PDB_EJEMPLO(3):highscn criteria not met for file: 35, scn: 12807114812509183, highscn: 12807114813773776
PDB_EJEMPLO(3):The change tracking is not used for file: 35 during backup due to above mentioned reason.
2024-07-04T00:01:45.557903+02:00
PDB_EJEMPLO(3):highscn criteria not met for file: 32, scn: 12807114812509183, highscn: 12807114813773815
PDB_EJEMPLO(3):The change tracking is not used for file: 32 during backup due to above mentioned reason.
2024-07-04T00:01:45.560075+02:00
PDB_EJEMPLO(3):highscn criteria not met for file: 49, scn: 12807114812509183, highscn: 12807114813773820
PDB_EJEMPLO(3):The change tracking is not used for file: 49 during backup due to above mentioned reason.
2024-07-04T00:01:45.578492+02:00
PDB_EJEMPLO(3):highscn criteria not met for file: 51, scn: 12807114812509183, highscn: 12807114813773815
PDB_EJEMPLO(3):The change tracking is not used for file: 51 during backup due to above mentioned reason.
2024-07-04T00:01:45.596404+02:00
PDB_EJEMPLO(3):highscn criteria not met for file: 41, scn: 12807114812509183, highscn: 12807114813773776
PDB_EJEMPLO(3):The change tracking is not used for file: 41 during backup due to above mentioned reason.
PDB_EJEMPLO(3):highscn criteria not met for file: 40, scn: 12807114812509183, highscn: 12807114813773776
PDB_EJEMPLO(3):The change tracking is not used for file: 40 during backup due to above mentioned reason.
PDB_EJEMPLO(3):highscn criteria not met for file: 52, scn: 12807114812509183, highscn: 12807114813773776
PDB_EJEMPLO(3):The change tracking is not used for file: 52 during backup due to above mentioned reason.
Además, si hemos realizado más de 8 copias de seguridad incrementales desde la última copia de seguridad completa, deberemos realizar otra copia de seguridad completa antes de que se aplique el cambio, debido a que los mapas de bits históricos ya se han eliminado.
El cambio a nivel de BBDD sería de la siguiente manera atendiendo al calculo de incrementales entre copias full. En este caso concreto tenemos una ventana de 10 días:
SYS@cdbpro> alter system set "_bct_bitmaps_per_file"=10 scope=both sid='*';
NOTA: también aplica a las copias de seguridad acumulativas.
