sábado, 25 de octubre de 2008

¿La auditoría llenó el tablespace System? Pues ¡muévala a otro tablespace!

Ya sea en cumplimiento de alguna regulación o por medida preventiva, en algún momento haremos uso de la auditoría standard y, ¿por qué no?, de la auditoria fina (FGA). Pues bien, si escogiste como destino la base de datos, ésta será registrada en tablas residentes en el tablespace System; tarde o temprano éste se llenará y allí empiezan los problemas. Hay algunas soluciones documentadas y otras no tanto, pero si tienes Oracle 10gR2 10.2.0.3 o superior, hay una forma simple y, lo que es mejor, soportada de hacerlo.

Estamos hablando del flamante package DBMS_AUDIT_MGMT, mismo que nos permite, sin mucho esfuerzo, dar mantenimiento a los registros de auditoria, incluyendo tareas como eliminación de los registros, creación de tareas para la eliminación de los registros y tambien para trasladar las tablas aud$ y fga_log$ a un tablespace de usuario, que es lo que justamente veremos ahora en acción.
  1. Primero crearé el tablespace al cual trasladaré las tablas de auditoría.
  2. SQL> create tablespace auditoria datafile size 100M;Tablespace created.
  3. Ahora a mover las tablas a su nuevo destino.
  4. SQL> BEGIN
      2  DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(
      3  audit_trail_type=> DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD,
      4  audit_trail_location_value => 'AUDITORIA' );
      5  END;
      6  /
    PL/SQL procedure successfully completed.
  5. Verificando que el traslado se completó.
  6. SQL> select owner, segment_name, segment_type
      2  from dba_segments
      3  where tablespace_name = 'AUDITORIA';
    OWNER      SEGMENT_NAME                   SEGMENT_TYPE
    ---------- ------------------------------ ---------------
    SYS        SYS_LOB0000059750C00028$$      LOBSEGMENT
    SYS        SYS_LOB0000059750C00013$$      LOBSEGMENT
    SYS        SYS_IL0000059750C00028$$       LOBINDEX
    SYS        SYS_IL0000059750C00013$$       LOBINDEX
    SYS        FGA_LOG$                       TABLE
    SYS        AUD$                           TABLE
    6 rows selected.

Tarea cumplida, y en contados minutos, adios procedimientos engorrosos  y sujetos a errores, ¡bienvenida la simplicidad!

Para poder usar este package debes obtener de Metalink el patch que corresponde a la versión que estés usando, recuerda que solo están disponibles para versiones 10.2.0.3 y superiores. Empieza por revisar el Note 731908.1 New Feature DBMS_AUDIT_MGMT To Manage And Purge Audit Information y luego dale una leída a la documentación, para que te enteres de todas las posibilidades de esta nueva facilidad.
Siga leyendo >>

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o envíame un email y para que NO te pierdas ningún Post, suscríbete por email ahora mismo!

¿Borró el OraInventory? No todo está perdido

El OraInventory o Central Inventory, contiene la información relacionada con todos los productos Oracle instalados en un servidor. Su presencia no es requerida para la operatividad del software pero sí cuando queremos actualizar el software, por ejemplo, para aplicar el patch que nos solucionará aquel bug que hemos encontrado. Si el OraInventory ya no existe o está corrupto entonces estamos entrampados. Por ello es una buena práctica respaldarlo cada vez que instalemos o actualizemos software Oracle; pero ¿y qué si nunca lo hicimos? Si estás usando 10g o superior la solución no podía ser más simple.

Primero veamos la situación inicial, Oracle Universal Installer nos muestra que el OraInventory está vacio.

Teniendo en cuenta que en este servidor tenía instalado Oracle EE, Oracle SE y el Agente de Grid Control, el procedimiento a seguir para reconstruir el Central Inventory, registrando en él el software ya instalado, es:
  1. Nos posicionamos en el home de OUI
  2. [oracle@caliope ~]$ cd $ORACLE_HOME/oui/bin
    [oracle@caliope bin]$
  3. Registramos nuestro primer producto, Oracle EE.
  4. [oracle@caliope bin]$ ./runInstaller -silent -ignoreSysPrereqs -attachHome ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_1" ORACLE_HOME_NAME="DB10g_EE"
    Starting Oracle Universal Installer...
    
    No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.
    
    >>> Ignoring required pre-requisite failures. Continuing...
    
    The inventory pointer is located at /etc/oraInst.loc
    The inventory is located at /u01/app/oracle/oraInventory
    'AttachHome' was successful.
    [oracle@caliope bin]$
    
  5. Registamos ahora el segundo producto, Oracle SE.
  6. [oracle@caliope bin]$ ./runInstaller -silent -ignoreSysPrereqs -attachHome ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_2" ORACLE_HOME_NAME="DB10g_SE"
    Starting Oracle Universal Installer...
    
    No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.
    
    >>> Ignoring required pre-requisite failures. Continuing...
    
    The inventory pointer is located at /etc/oraInst.loc
    The inventory is located at /u01/app/oracle/oraInventory
    'AttachHome' was successful.
    [oracle@caliope bin]$
    
  7. Finalmente registramos el Agente de Grid Control.
  8. [oracle@caliope bin]$ ./runInstaller -silent -ignoreSysPrereqs -attachHome ORACLE_HOME="/u01/app/oracle/product/agent10g" ORACLE_HOME_NAME="Agent10g"
    Starting Oracle Universal Installer...
    
    No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.
    
    >>> Ignoring required pre-requisite failures. Continuing...
    
    The inventory pointer is located at /etc/oraInst.loc
    The inventory is located at /u01/app/oracle/oraInventory
    'AttachHome' was successful.
    [oracle@caliope bin]$
    

El proceso ha concluido, ahora OUI nos muestra el OraInventory reconstruido.


Recuerda que esto no funciona para las versiones previas a 10g por lo que si tienes en uso alguna version anterior, ¿qué esperas para obtener un respaldo?

Si quieres empaparte más con el tema de los Inventarios, te recomiendo los Notes: 564192.1 FAQs on Central Inventory and Oracle Home Inventory (Local Inventory) in Oracle RDBMS y 556834.1 Steps To Recreate Central Inventory(oraInventory) In RDBMS Homes. ¡Suerte con la lectura!

Posts Relacionados:
Siga leyendo >>

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o envíame un email y para que NO te pierdas ningún Post, suscríbete por email ahora mismo!

viernes, 17 de octubre de 2008

Desapareció mi tabla, confiesen: ¿quién fue?

Seguramente que alguna vez has pasado algo similar, alguien eliminó alguna tabla, índice, usuario, borró información o la modificó y luego cuando los problemas aparecen nadie confiesa, "yo no estaba", "yo hace tiempo que ni me conecto a la base de datos", "debe ser un bug de Oracle", son algunas de las cosas que nos irán respondiendo cuando hacemos las indagaciones. ¿Qué hago si no tengo la auditoria habilitada, ni triggers que hagan seguimiento? Simple: usar LogMiner.

LogMiner, ques es parte de Oracle Database, permite consultar la información contenida en los online y archived redo logs haciendo uso de SQL. Recordemos que en los redo log files se registra información sobre la actividad en la base de datos.

Veamos mediante un ejemplo como podríamos beneficiarnos de él para nuestro caso hipotético:
  1. Marco se conecta a desarrollo y decide borrar una tabla que había copiado para hacer unas pruebas.
  2. MARCO@orcl> drop table oltp.importante;
    Table dropped.
  3. Se empiezan a recibir llamadas de queja por una aplicación fallando permanentemente y revisando los logs se encuentra que la tabla oltp.importante ha sido eliminada. Marco siente un nudo en la garganta mientras piensa "¿será posible que me haya conectado a producción en lugar de a desarrollo?".
  4. Todos niegan la autoría de tal error, habrá que investigar con LogMiner, para ello primero se registran los online redo logs.
  5. SYS@orcl>  begin
      2  dbms_logmnr.add_logfile(
      3    '/logs/redo01.log', dbms_logmnr.new );
      4  dbms_logmnr.add_logfile(
      5    '/logs/redo02.log', dbms_logmnr.addfile );
      6  dbms_logmnr.add_logfile(
      7    '/logs/redo03.log', dbms_logmnr.addfile );
      8  end;
      9  /
    PL/SQL procedure successfully completed.
  6. Se activa la minería.
  7. SYS@orcl> execute dbms_logmnr.start_logmnr;
    PL/SQL procedure successfully completed.
  8. Buscamos DDLs sobre la tabla en cuestión.
  9. SYS@orcl> select scn, timestamp, username, sql_redo
      2  from v$logmnr_contents
      3  where seg_owner='OLTP'
      4  and seg_name='IMPORTANTE'
      5  and operation = 'DDL';
    
        SCN TIMESTAMP           USERNAME
    ------- ------------------- ----------
    SQL_REDO
    ----------------------------------------------------------------------------
    3720771 04/09/2008 15:16:52 MARCO
    ALTER TABLE "OLTP"."IMPORTANTE" RENAME TO "BIN$VheiNLbMC5bgQKjAMndYmA==$0" ;
    3720771 04/09/2008 15:16:52 MARCO
    drop table oltp.importante AS "BIN$VheiNLbMC5bgQKjAMndYmA==$0" ;
  10. Marco, ¿qué dijiste que estabas haciendo a eso de las 3pm? :-)

Acabamos de ver a LogMiner en acción, pero esto es solo una fracción de lo que prodemos hacer, si deseas saber más de su uso y posibilidades, encontrarás todo lo que necesitas en el manual Oracle Database Utilities.
Siga leyendo >>

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o envíame un email y para que NO te pierdas ningún Post, suscríbete por email ahora mismo!

domingo, 12 de octubre de 2008

¿Archive log perdido? No reconstruya su Standby

Otro problema recurrente con las bases de datos standby es la pérdida de uno o más archive logs aún no aplicados. La solución era usualmente el reconstruir nuevamente la base de datos standby, lo cual si bien es relativamente fácil, puede consumir bastante tiempo. Esto fue lo que algunos sugirieron a un afligido DBA que pedía ayuda en el foro de Oracle Technet, afortunadamente si estás usando Oracle 10gR2 la solución es mucho más simple y rápida, ¿suena bien? entonces vamos con el procedimiento.

  1. Detener la sincronización de la base de datos standby
  2. STDB> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
    
  3. Obtener el SCN al cual se ha llegado en la base de datos standby
  4. STDB> SELECT CURRENT_SCN FROM V$DATABASE;
    
  5. Obtener un backup incremental de la base de datos primaria con RMAN, a partir del SCN obtenido en el paso previo
  6. RMAN> BACKUP INCREMENTAL FROM SCN <SCN from previous step>
    DATABASE FORMAT '/tmp/ForStandby_%U' tag 'FORSTANDBY';
    
  7. Catalogar el backup del paso previo en la base de datos standby
  8. RMAN> CATALOG START WITH '/tmp/ForStandby';
    
  9. Recuperar la base de datos standby con el backup ya catalogado
  10. RMAN> RECOVER DATABASE NOREDO;
    
  11. En la base de datos primaria crear un nuevo standby controlfile
  12. RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/tmp/ForStandbyCTRL.bck';
    
  13. Detener la base de datos standby y levantarla con nomount
  14. RMAN> SHUTDOWN;
    RMAN> STARTUP NOMOUNT;
    
  15. Restaurar el standby controlfile obtenido en el paso (6) en la base de datos standby
  16. RMAN> RESTORE STANDBY CONTROLFILE FROM '/tmp/ForStandbyCTRL.bck';
    
  17. Detener la base de datos standby levantarla con mount
  18. RMAN> SHUTDOWN;
    RMAN> STARTUP MOUNT;
    
  19. Limpiar los standby redo logs en la base de datos standby
  20. STDB> ALTER DATABASE CLEAR LOGFILE GROUP 1;
    STDB> ALTER DATABASE CLEAR LOGFILE GROUP 2;
    STDB> ALTER DATABASE CLEAR LOGFILE GROUP 3;
    
  21. Si estaba activo Flashback Database, reiniciarlo
  22. STDB> ALTER DATABASE FLASHBACK OFF;
    STDB> ALTER DATABASE FLASHBACK ON;
    
  23. Reiniciar el recovery de la base de datos standby
  24. STDB> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
    

Este procedimiento aplica no sólo cuando un archive log se ha perdido, sino también cuando se han realizado operaciones con nologging en la base de datos principal o cuando hay un gran retraso en la sincronización. Puedes revisar el texto completo en el manual Oracle Data Guard Concepts and Administration.

Posts Relacionados:
Siga leyendo >>

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o envíame un email y para que NO te pierdas ningún Post, suscríbete por email ahora mismo!

sábado, 11 de octubre de 2008

Sincronización detenida: ORA-01274

Recientemente una amiga se comunicó conmigo pues tenía una emergencia: su base de datos standby había dejado de sincronizar. Revisando el alert.log se encontró el error ORA-01274, llegándose a la conclusión que se había agregado un datafile en la base de datos primaria y al tratar de replicar el cambio en el standby, este datafile no se había creado por falta de espacio en disco.

Ayer por la noche, en el foro de Oracle Technet, alguien reportaba una situación similar, pero en este caso el origen del error era menos claro, el resultado el mismo: no se replicó la creación de uno o más datafiles. ¿Qué hacer en una situación como ésta?

Ya antes me había tocado ayudar a otros DBAs en la resolución de este problema, la clave está en seguir los pasos indicados en el Note 221130.1 Recovery failed with error 1274 ORA-19502 ORA-27063 skgfospo SVR4 Error 28.

En una situación como esta, en la que no se logra crear un datafile en la base de datos standby, el datafile es registrado en el controlfile con un nombre similar a UNNAMED0000 y la sincronización se suspende con el error  ORA-1274: cannot add datafile.

Los pasos a seguir para superar el impase son:

  1. Desactivar el manejo automático de archivos
  2. SQL> alter system set standby_file_management = manual scope=memory;
    
  3. Hallar el nombre del datafile no creado
  4. SQL> select name from v$datafile where name like '%UNNAMED%';
    NAME
    --------------------------------------------------------
    e:\oracle\product\10.2.0\database\UNNAMED00033
    
  5. Crear el datafile faltante
  6. SQL> alter database create datafile 
    'e:\oracle\product\10.2.0\database\UNNAMED00033' as 'e:\oradata\orcl\dat04.dbf';
  7. Activar el manejo automático de archivos
  8. SQL> alter system set standby_file_management = auto scope=memory;
    

Ahora ya se puede reiniciar el recovery, problema resuelto!

Posts Relacionados:
Siga leyendo >>

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o envíame un email y para que NO te pierdas ningún Post, suscríbete por email ahora mismo!