ORA-46258: Cleanup not initialized for the audit trail

Intentando limpiar la estadísticas me he encontrado con este error:

BEGIN
 DBMS_AUDIT_MGMT.clean_audit_trail(
 audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
 use_last_arch_timestamp => false);
 END;
 /
BEGIN
 *
 ERROR at line 1:
 ORA-46258: Cleanup not initialized for the audit trail
 ORA-06512: at "SYS.DBMS_AUDIT_MGMT", line 144
 ORA-06512: at "SYS.DBMS_AUDIT_MGMT", line 2979
 ORA-06512: at "SYS.DBMS_AUDIT_MGMT", line 829
 ORA-06512: at line 2

Solución y como bien dice el error inicializar el audit trail

BEGIN
 DBMS_AUDIT_MGMT.INIT_CLEANUP(
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
 DEFAULT_CLEANUP_INTERVAL => 12 );
 END;
 /
Anuncios

Cómo limpiar las tablas de auditorias.

Antes de comenzar se debe inicializar la infraestructura que controla las auditorias.

BEGIN
 DBMS_AUDIT_MGMT.INIT_CLEANUP(
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
 DEFAULT_CLEANUP_INTERVAL => 12 );
 END;
 /
Luego limpiamos
 BEGIN
 DBMS_AUDIT_MGMT.clean_audit_trail(
 audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
 use_last_arch_timestamp => false);
 END;
 /
Dejmaos todo como estaba
 BEGIN
 DBMS_AUDIT_MGMT.deinit_cleanup(
 audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL);
 END;
 /

Tamaño de los tablespaces

Tamaño de los tablespaces, solo los de datos no incluye los temporales:

SELECT a.tablespace_name,
b.size_kb/1024 SIZE_MB,
a.free_kb/1024 FREE_MB,
Trunc((a.free_kb/b.size_kb) * 100) "FREE_%"
FROM (SELECT tablespace_name,
Trunc(Sum(bytes)/1024) free_kb
FROM dba_free_space
GROUP BY tablespace_name) a,
(SELECT tablespace_name,
Trunc(Sum(bytes)/1024) size_kb
FROM dba_data_files
GROUP BY tablespace_name) b
WHERE a.tablespace_name = b.tablespace_name
ORDER BY 4 desc
/

 La forma más exacta de saber lo que “realmente” está consumido de los data files es sumando los bytes de la DBA_EXTENTS:

Select
                Tablespace_name,
                Sum(bytes) total
From
                Dba_extents
Group by
                Tablespace_name
/

Si se quiere, eventualmente, también se puede agrupar por OWNER y saber  los consumos por esquema.

Y para saber el tamaño exacto asignado al tablespace, la consulta es sobre DBA_DATA_FILES:

Select
                Tablespace_name,
                Sum(bytes) total
From
                Dba_data_files
Group by
                Tablespace_name

ORA-1653: unable to extend table

Cuando nos encontramos este error es porque nos hemos quedado sin espacio en él datafile. En el ejemplo que se muestra vemos que el tablespace que no puede crecer en el de SYSTEM

ORA-1653: unable to extend table SYS.IDL_UB1$ by 16 in   tablespace SYSTEM

Para solucionar este problema, lo primero que tenemos que hacer es comprobar que tenemos suficiente espacio libre en disco:

Para mostrar el espacio libre en disco en porcentajes utilizaremos:

df –kl

Luego podemos comprobar que espacio libre tenemos en los tablespace, con esta consulta obtendremos el nombre del tablespace y el espacio en Megas libre:

sqlplus ‘/ as sysdba’
SELECT tablespace_name,
ROUND(sum(bytes)/1024/1024,0)  free_space
FROM dba_free_space
GROUP BY tablespace_name;
exit

Para obtener el nombre del tablespace y el espacio total en Megas que puede llegar a tener:

sqlplus ‘/ as sysdba’
SELECT tablespace_name,
round(sum(BYTES/1024/1024),0)
FROM dba_data_files b
WHERE tablespace_name NOT LIKE ‘TEMP%’
GROUP BY b.tablespace_name;
exit

Si se tiene espacio de sobra en el sistema operativo se puede modificar el data file, para que crezca sin problema,

Para obtener el nombre del datafile que le corresponde a ese tablespace:

sqlplus ‘/ as sysdba’
select FILE_NAME from dba_data_files where TABLESPACE_NAME = ‘SYSTEM’;
exit

En caso de que tenga más de uno solo es necesario aumentar el espacio del último.

sqlplus ‘/ as sysdba’
alter database datafile
   '/volumes/oradata/QCDB/QCDB_system01.dbf'
autoextend on;
exit

Recuperar un datafile

Existen varias opciones dependiendo de si la base de datos esta en mode archivelog o no y de si el archive dañado es crítico para el funcionamiento de oracle o simplemente contiene datos de usuario.

 Recuperar un datafile en modo noarchivelog.

 No existe el concepto de recuperar un datafile en modo noarchivelog, porque los archivos archivelog necesarios para recuperar la base de datos no existen. Sin embargo si se puede restaurar. La única opción es restaurar toda la base de datos a partir del último backup y que los usuarios apliquen los cambios que han realizado desde el último backup.

Pasos a seguir desde la interfaz Database Control:

 1. Para la instancia si es que no está parada

 2. Hacer click en Perform Recovery en la página de Maintenance properties.

 3. Seleccionar como tipo de recuperación: “Whole Database”.

 Pasos a seguir desde el sistema operativo:

 1. Para la instancia si es que no está parada.

 2. Restaurar los ficheros de la base de datos.

 3. Una vez restaurado todo, la base de datos habrá perdido los redo logfiles, porque de estos archivos nunca se hace backup, por eso es necesario restaurarlos, con la base de datos montada hacer ALTER DATABASE CLEAR LOGFILE GROUP .

 4. Abrir la base de datos.

Recuperar un archive no crítico en modo archivelog.

En una base de datos Oracle, todos los datafiles menos los de system y el especificado en el parámetro UNDO_TABLESPACE están considerados como no críticos. Si cualquiera de estos archivos se daña la base de datos puede seguir operando. Oracle marca el archivo dañado como offline, haciendo sus contenidos inaccesibles, la forma en que la aplicación reaccione ante esto depende de cómo este estructurada. Si el backup se ha hecho con RMAN la recuperación de datafile se hará de forma totalmente automática. RMAN se encargará de realizar la recuperación del archivo de la manera más efectiva, decidiendo entre full backups o incrementales y aplicando los archivelog necesarios. Si RMAN está vinculado a una librería de cintas, se encargara de cargar las cintas automáticamente y extraer los archivos que necesita. La restauración del datafile solo será correcta si todos los archivelog generados desde el último backup están disponibles. Si uno de los ficheros falta, la única forma de recuperar el datafile es hacer un recuperación completa y luego a través de de una recuperación incompleta, llegar hasta el archivelog perdido, y a partir de ahí se pierde todo el trabajo.

 1. Hacer Click en página Maintenance properties, en la sección Perform Recovery.

 2. Selecciona como tipo de recuperación “Datafiles” y la opción “Restore to current time.”

 3. añade todos los datafiles necesarios para la recuperación

 4. Determine si se quiere restaurar en el mismo sitio o en uno nuevo.

 5. Añadir un trabajo en RMAN que restaure y recupere los archives perdidos.

Recuperar la perdida de un datafile crítico

Los datafile que pertenecen al tablespace de SYSTEM y de Undo son considerados críticos por oracle, esto significa que no se puede mantener la base de datos abierta si estos archives están dañados. Si una parte del tablespace de SYTEM no está disponible, se pierden partes del diccionario de datos y Oracle no puede funcionar sin acceso completo al diccionario. Lo mismo ocurre con el tablespace de UNDO, si hay partes no disponibles implica que pueden fallar la integridad transaccional con lo cual oracle no puede trabajar. Por la tanto la perdida de cualquiera de estos datafiles implica que la instancia se cae inmediatamente. Para recuperar la base de datos en caso de pérdida de uno de estos ficheros se procederá de la misma manera que un archivo no critico, pero la recuperación se hará con la base de datos montada.

Manejo de extent

Hoy nos meteremos un poco en el denso mundo de los extends. Vamos a obviar una descripción detallada de que es un extends y nos vamos en a centrar en las dos formas que tiene Oracle de manejar los extends: 

Dictionary Manager: Esta era la forma antigua de controlar los extends, la base de datos registraba dentro del diccionario los extends libres y ocupados. Cada vez que se producía un movimiento en los extens se tenían que actualizar las tablas correspondientes. Consultaba constantemente las tablas FET$ y UET$ (la primera guarda los segmentos libres y la segunda los usados) localizadas en el diccionario. Esto provocaba contención en el tablespace de system.

Ejemplo de la creación de tablespace dictionary manager:

 CREATE TABLESPACE users
  DATAFILE '/u10/app/oradata/TESTDB/user01.dbf' SIZE 50M
  EXTENT MANAGEMENT DICTIONARY
  DEFAULT STORAGE (
    INITIAL 64K
    NEXT 64K
    MINEXTENTS 2
    MAXEXTENTS 121
    PCTINCREASE 0);

Locally manager : Con este nuevo sistema que aparece a partir de Oracle 9, el registro de extends se hace a través de bitmaps. Cada bit dentro del bitmap corresponde a un bloque o grupo de bloques, cuando a un extends se le asigna espacio el servidor de oracle cambia los valores del bitmap para mostrar el nuevo status de los bloques. En oracle 9 si el parámetro COMPATIBLE =9.0.0 será la opción por defecto, si es inferior se creara como dictionary. A partir de Oracle 10 es la opción por defecto. Oracle recomienda la utilización de esta opción. 

Con locally manager tablespaces existen dos opciones para asignar el espacio de los extends: UNIFORM o AUTOLLOCATE:

La opción uniform  asigna y desasigna el espacio en los extens de un tamaño uniforme. Este es el valor por defecto en los tablespaces temporales y no se puede especificar en los tablespaces de undo.

Ejemplo de la creación de un tablespace locally uniform:

 CREATE TABLESPACE users
  DATAFILE '/u10/app/oradata/TESTDB/user01.dbf' SIZE 50M
  EXTENT MANAGEMENT LOCAL UNIFORM SIZE 512K;

 El autoallocate (or automatic) sin embargo le dice a la base de datos que varíe el tamaño de los extends para cada segmento. Por ejemplo, en Windows y en Linux con bloques de datos de 8KB, los primero 16 extends de un segmento serán de 64 KB. Los siguientes 63 extends serán de 1MB, de 8MB los siguientes 64 extend, y así progresivamente. Este algoritmo permite que los segmentos pequeños sean pequeños, mientras los grandes irán creciendo si afectar a los demás segmentos.

Ejemplo de la creación de un tablespace localy autoallocate:

CREATE TABLESPACE users
  DATAFILE '/u10/app/oradata/TESTDB/user01.dbf' SIZE 50M
  EXTENT MANAGEMENT LOCAL AUTOALLOCATE;

Ventajas de la utilización de locally manager:

  1. Como no guarda la información sobre el espacio sobre en el diccionario, reduce la contención sobre estas tablas.
  2. Automáticamente rastrea el espacio adyacente libre, eliminando la necesidad de unirlo.
  3. Evita operaciones recurrentes sobre las tablas del diccionario.
  4. El tamaño de los extens puede ser determinado automáticamente por system,
  5. Los cambios en los bitmaps no generan información de rollback, porque no actualizan las tablas en el diccionario. (excepto casos especiales como información de cuota del tablespace).
  6. Reduce la fragmentación