Un error (WARNING) típico que se puede apreciar en el alertlog es:

ORA-19815: WARNING: db_recovery_file_dest_size of 85899345920 bytes is 100.00% used, and has 0 remaining bytes available.
Mon Mar 30 01:11:02 2009
**********************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
**********************************************************************

En este caso, el WARNING se convierte en un error grave, no hay espacio suficiente (“100.00% used”) configurado para la generación de archivelog, luego comienzan errores como:

Mon Mar 30 01:11:02 2009
Errors in file /u01/app/oracle/db/admin/jimydb/bdump/caefdb2_arc0_10217.trc:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 97741824 bytes disk space from 85899345920 limit
ARC0: Error 19809 Creating archive log file to ‘/u02′
ARCH: Archival stopped, error occurred. Will continue retrying
Mon Mar 30 01:11:02 2009
ORACLE Instance jimydb – Archival Error
Mon Mar 30 01:11:02 2009
ORA-16038: log 11 sequence# 54433 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 11 thread 2: ‘/u02/jimydb/onlinelog/group_11.315.681334097′
ORA-00312: online log 11 thread 2: ‘/u02/jimydb/onlinelog/group_11.789.681334099′

Como se puede observar el error es grave, la base de datos ya no puede escribir archivelogs, el error indica que no se puede escribir en el directorio /u02, realmente esto no significa que el directorio no tenga espacio disponible (aunque podría ser causa del error), realmente el error es que se han almacenado archivelog ocupando más espacio que los permitidos por el parametro db_recovery_file_dest_size, para este caso se ha excedido el límite de 80 GB:

SQL> sho parameters db_recovery_file_dest_size
NAME                                 TYPE       VALUE
db_recovery_file_dest_size           big integer 80G
SQL>

Una salida rápida es el aumento del valor de este parámetro (si el espacio físico y real lo permite):

SQL> alter system set db_recovery_file_dest_size = 90G scope=both;
System altered.
SQL> sho parameters db_recovery_file_dest_size
NAME                                 TYPE       VALUE
db_recovery_file_dest_size           big integer 90G
SQL>

Listo!, la base de datos comienza a operar nuevamente, la acción inmediata tras esta alteración es eliminar los archivelog (previo respaldo) .

Lo importante es ser proactivo y no esperar a que se congele la base de datos, la siguiente query ayuda a monitorear el espacio disponible en el directorio db_recovery_file_dest  según lo configurado en db_recovery_file_dest_size:

SELECT
  NAME AS “Directorio Raiz Recovery Dest”,
  space_limit
    / 1024
    / 1024 AS “Max Espacio Configurado [MB]“,
  TRUNC(space_used
          / 1024
          / 1024,2) AS “Espacio Utilizado [MB]“,
  number_of_files AS “Cantidad De Archivos”,
  TRUNC(space_used
          * 100
          / space_limit,2) AS “% Utilizado Recovery Dest”
FROM
  v$recovery_file_dest;

Resultado:

El resultado muestra:

Directorio Raiz Recovery Dest: Directorio donde se generan los archivelog. Se puede revisar con “show parameters db_recovery_file_dest” .

Max Espacio Configurado [MB]: Espacio configurado el parametro db_recovery_file_dest_size y que significa el máximo espacio asignado para archivelog.

Espacio Utilizado [MB]: Espacio utilizado del directorio db_recovery_file_dest.

Cantidad De Archivos: Cantidad de archivelog que actualmente residen es el directorio db_recovery_file_dest.

% Utilizado Recovery Dest: Porcentaje del espacio total utilizado por archivelog en el directorio db_recovery_file_dest.

Descargar Articulo Completo Formato PDF

Saludos!
Jimy Godoy

Artículos relacionados

• Modo ArchiveLog Sun 19 Apr 2009

No Archive Mode indica que nuestra base de datos no se encuentra en modo archivelog, USE_DB_RECOVERY_FILE_DEST indica que el destino por defecto para los archivelog es el db_recovery_file_dest.
Para identificar el destino de los archivelog verificamos el parámetro db_recovery_file_dest:

Ahora dejaremos nuestra base de datos en modo archivelog, para ello es necesario que la base de datos se levante modo mount:

Verificamos nuevamente el modo de nuestra base de datos:

Para probar se genera un archivelog:

Verificamos el archivelog generado en el direcotrio db_recovery_file_dest, dentro de este directorio se creará un directorio con el nombre de la base de datos y dentro de este otro directorio con la fecha de hoy:

Si se desea cambiar el formato y directorio de archivelog log_archive_dest_1 y log_archive_format. Para este ejemplo dejaremos como formato de los archivelog el thread seguido del número de secuencia y el stamp con la extensión arc, los archivelogs los guardaremos en el directorio /u02/archivelog:

Luego verificamos:

Espero la información les sea de utilidad.

Descargar Articulo Completo Formato PDF

Saludos!
Jimy Godoy Maureira

Artículos relacionados

• Monitoreo db_recovery_file_dest_size Mon 08 Jun 2009
• Clonar Base De Datos con RMAN Tue 09 Sep 2008