Como parte de un proyecto de upgrade a Oracle 19c, estaba analizando la generación diaria de archived redo logs para poder dimensionar correctamente el Fast Recovery Area, y para una de las bases de datos llegué a la conclusión de que era suficiente con asignarle 500 GB en lugar de sus actuales 4 TB.
Grande fue mi sorpresa cuando OEM me indicaba que estaban ocupados casi 3 TB, y sin posibilidad de reutilizarlos, mientras que a nivel de Disk Group me mostraba que +FRA01 estaba vacío.
Estaba presenciando un escenario en el cual el Fast Recovery Area está lleno y vacío a la vez!
El problema
SELECT name,
ROUND(space_limit/1024/1024/1024,2) space_limit_gib,
ROUND(space_used/1024/1024/1024,2) space_used_gib,
ROUND(space_reclaimable/1024/1024/1024,2) space_reclaimable_gib,
number_of_files
FROM v$recovery_file_dest;
SELECT file_type, percent_space_used as used,
percent_space_reclaimable as reclaimable,
number_of_files
FROM v$recovery_area_usage;
NAME SPACE_LIMIT_GIB SPACE_USED_GIB SPACE_RECLAIMABLE_GIB NUMBER_OF_FILES
------- --------------- -------------- --------------------- ---------------
+FRA01 4,096.00 2,711.05 1.32 2,143
FILE_TYPE USED RECLAIMABLE NUMBER_OF_FILES
------------------------- ---------- ----------- ---------------
CONTROL FILE 0 0 0
REDO LOG 0 0 0
ARCHIVED LOG 2.29 2.27 18
BACKUP PIECE .02 0 1
IMAGE COPY 0 0 0
FLASHBACK LOG 0 0 0
FOREIGN ARCHIVED LOG 0 0 0
Inmediatamente se nota la discrepancia: la columna number_of_files en la vista v$recovery_file_dest registra mas de 2 mil archivos, mientras que en v$recovery_area_usage no llega a 20.
La solución
Luego de investigar en My Oracle Support, se encuentra un puñado de notas responsabilizando de esta discrepancia a bugs, presentes en distintas versiones de Oracle.
Las causas son múltiples, y las alternativas de solución son igual de variadas, pero una de ellas siempre es mencionada y parece ser la más simple de implementar: reinicializar el Fast Recovery Area.
Esto se logra ejecutando los siguientes comandos:
SQL> alter session set events 'immediate trace name kra_options level 1';
Session altered.
SQL> execute dbms_backup_restore.refreshagedfiles;
PL/SQL procedure successfully completed.Comprobamos que ahora sí hay coherencia entre los datos registrados por ambas vistas: el número de archivos es ahora 19, y el espacio usado pasó de 2,700 GB a tan solo 46.
NAME SPACE_LIMIT_GIB SPACE_USED_GIB SPACE_RECLAIMABLE_GIB NUMBER_OF_FILES
--------------- --------------- -------------- --------------------- ---------------
+FRA01 4,096.00 46.10 45.32 19
FILE_TYPE USED RECLAIMABLE NUMBER_OF_FILES
------------------------- ---------- ----------- ---------------
CONTROL FILE 0 0 0
REDO LOG 0 0 0
ARCHIVED LOG 4.58 4.53 18
BACKUP PIECE .03 0 1
IMAGE COPY 0 0 0
FLASHBACK LOG 0 0 0
FOREIGN ARCHIVED LOG 0 0 0Como ya está todo en orden, podemos reconfigurar el espacio asignado a los 500 GB originalmente calculados, y con ello damos por cerrado el incidente.
Para complementar lo aquí expuesto, les recomiendo la lectura de las notas:
| 1471471.1 | v$Flash_recovery_area_usage is not Being Updated |
| 2780810.1 | SPACE_USED column in v$recovery_file_dest not Updated After a Change in the FRA Location |
| 2564464.1 | v$recovery_file_dest.number_of_files Shows Incorrect Value after Restoring Controlfile At Standby |