Scripts para monitorear eventos de espera históricos



Cuando se realiza un análisis en una base de datos Oracle no podemos realizar una sugerencia si sólo conocemos un punto de análisis, no podemos ver un AWR de las 09:00 a 10:00 de la mañana y decir cual es el problema , esto le suele suceder a muchas personas que por analizar un punto dan las recomendaciones, pues muchas veces son comportamientos normales y los problemas van por otro lado.

Lo que se debe hacer es analizar la curva de comportamiento de alguna estadística de Oracle y chequear su comportamiento histórico, para poder realizar este análisis es que les muestro unas consultas entretenidas que todo buen cocinero DBA debe tener y usar (por supuesto) ;D




Para poder consultar sobre eventos de la espera en la base de datos, ejecutamos la siguiente consulta
Eventos_espera_tabulado.sql

El modo de ejecución es simplemente una llamada a SQL*Plus , con lo cual aparecerá lo siguiente

SQL> start eventos_espera.sql

Puede consultar todos los eventos de espera disponibles en la siguiente vista
SELECT name FROM V$EVENT_NAME ORDER BY name

Ingrese texto para buscar evento de espera :

Se ingresa un trozo del evento de espera, por ejemplo al ingresar la palabra log se filtran los eventos de espera que sean similares y los mostrará por pantallarong>log

----- (texto cortado) -----
log file sync
log switch/archive
log write(even)
log write(odd)
logout restrictor
recovery area: computing applied logs
simulated log write delay
switch logfile command

35 rows selected.

Ingrese nombre de evento de espera :

Se ingresa el nombre del evento de espera completo, por ejemplo log file sync y pedirá el número de días a analizar y el intervalo

Ejemplo :

Ingrese nombre de evento de espera : log file sync
Ingrese numero de dias a analizar : 10
Ingrese intervalo de horas a medir : 1

Después de lo anterior , nos arroja información tabulada proveniente de las tablas históricas del AWR

center



Y podemos proceder a generar nuestro magnífico gráfico

center

Espero les sirva para poder analizar su base de datos ;)

by Ligarius
13.11.15. 08:57:39. 347 words, 1987 views. Categories: Tuning / Performance ,

¿Qué es un Snapshot Controlfile?



¿Qué es un Snapshot controlfile? . Yo creo que está pregunta ha aparecido en nuestras mentes desde el inicio de los días, pero la verdad ....es bastante sencillo, he acá la explicación






Esto es para alegrar la lectura :>

Tal cual como lo dice la documentación de Oracle
https://docs.oracle.com/cd/E11882_01/rac.112/e41960/rman.htm#RACAD851

Un Snapshot controlfile es simplemente una copia del controlfile de una base de datos , que se crea en el sistema operativo en una ruta en partícular, la cual está dada por un seteo a nivel de RMAN, que se puede ver si ejecutamos el comando SHOW ALL dentro de RMAN

CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'C:\APP\LIGARIUS\PRODUCT\12.1.0\DBHOME_1\DATABASE\SNCFPROD12C.ORA';

PD : Se que es horrible, pero tenía a mano Windows para elaborar la nota :'(


Esta copia de controlfile (Snapshot) sirve para cuando se hace la resincronización con el catálogo RMAN (entre el encabezado del controlfile y le base de datos catálogo) o para cuando se respalda el mismísimo controlfile, con esta copia a disco se mantiene la consistencia en la Lectura (READ-CONSISTENT) y es este propio archivo el que se lee para geenerar la copia de RMAN.

La gran diferencia con el seteo del AUTOBACKUP del CONTROLFILE (CONFIGURE AUTOBACKUP ON) a nivel de RMAN , es que el Snapshot Controlfile se genera antes del respaldo (comandos BACKUP o COPY) y el AUTOBACKUP del controlfile se genera después de haberse ejecutado el respaldo (comandos BACKUP o COPY), aunque ambos sirven para por ejemplo llevar a cabo una restauración de base de datos.

Para un ambiente Stand Alone, el Snapshot COntrolfile debe estar seteado en una ruta cualquiera, para un ambiente de RAC , la ruta del Snapshot COntrolfile debe estar seteada en un dispositivo compartido (por ejemplos discos en CLUSTER) que sea visualizado por los nodos que comparten el RAC, esto es obligación desde Oracle RAC 11gr2 (11.2.0.2).

Espero les sirva

by Ligarius
09.11.15. 08:05:30. 331 words, 2548 views. Categories: Base de datos, RMAN (Recovery Manager) ,

ORA-12801: error signaled in parallel query server



Era sólo un pequeño e indefenso alter de una constraint , sólo eso.... gatilló todo...fue horrible 88| (fue para darle algo más de emoción)



Super simple, era habilitar una constraint, nada más....pero dió un error algo trágico

SQL> ALTER TABLE PROD1.MOVIMIENTOS ENABLE CONSTRAINT FK_1_MOVINTDETAILS ;

ALTER TABLE PROD1.MOVIMIENTOS ENABLE CONSTRAINT FK_1_MOVINTDETAILS ;
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-12801: error signaled in parallel query server P003
ORA-01157: cannot identify/lock data file 5001 - see DBWR trace file
ORA-01110: data file 5001: '+DATG01'

SQL>


Obviamente , lo que pensé en un primer instante es ir a ver el susodicho datafile, el cual para mi mala suerte y sorpresa, no existía.

SQL> select name , file# from v$datafile where file# = 5001;

no rows selected

SQL>


Lo busqué entonces como un TEMPFILE y acá dieron los primeros errores que me indicaban el problema

SQL> select FILE_ID , FILE_NAME , TABLESPACE_NAME from dba_temp_files;
ERROR:
ORA-01157: cannot identify/lock data file 5001 - see DBWR trace file
ORA-01110: data file 5001: '+DATG01'

no rows selected

SQL>


Hice el chequeo en la vista V$TEMPFILE y aparece solamente el diskgroup, no la ruta completa donde está el tempfile, por ende...hay que recrear, hay un error...

1 select FILE# , NAME from v$tempfile

FILE# NAME
---------- ----------------------------------------
1 +DATG01


Chequeamos el tablespace temporal que existe

SQL> select tablespace_name from dba_tablespaces where tablespace_name like '%TEMP%';

TABLESPACE_NAME
------------------------------
TEMP2


Creamos un nuevo tablespace temporal , de un tamaño fijo

SQL> create temporary tablespace temp1 tempfile '+DATG01' size 5g;

Tablespace created.

SQL> alter tablespace temp1 add tempfile '+DATG01' size 5g;

Tablespace altered.


Y alteramos la base de datos, para que todos los ordenamientos pasen por el nuevo tablespace temporal

SQL> alter database default temporary tablespace temp1;

Database altered.

SQL>


Borramos el anterior tablespace temporal.

SQL> drop tablespace temp2 ;

Tablespace dropped.

SQL>


Con la modificación del tablespace temporal, pues arreglamos el inconveniente y el grandioso, potente a increíble ALTER CONSTRAINT , se ejecuta sin problemas

SQL> ALTER TABLE PROD1.MOVIMIENTOS ENABLE CONSTRAINT FK_1_MOVINTDETAILS ;

Table altered.

SQL>

:)

by Ligarius
03.11.15. 13:04:22. 362 words, 3370 views. Categories: Base de datos, ASM (Automatic Storage Management) ,

SELECT TO_NUMBER('MUST_HAVE_RUN_PRE-UPGRADE_TOOL_FOR_TIMEZONE')




Haciendo una migración/upgrade de bases de datos, al momento de actualizar el catálogo (catupgrd.sql) , me apareció el siguiente error

SELECT TO_NUMBER('MUST_HAVE_RUN_PRE-UPGRADE_TOOL_FOR_TIMEZONE')
*
ERROR at line 1:
ORA-01722: invalid number

Obviamente mi primera impresión fue la de ahorcarme, pero menos mal que no lo hice y simplemente ...aplique una nota Oracle para resolver el tema :>> he acá el relato de los hechos..

- Se tiene una base de datos en versión 10.2.0.2 en ambiente Windows de 32 bits y se quiere migrar a una versión 11.2.0.3 en ambiente Linux de 64 bits

- Se realiza el proceso básico para migrar una base de datos (no es el objetivo de la nota, por eso se explica como un punteo)

  • Se toma un respaldo con RMAN (Full con la base abajo)
  • Se copia al destino (Un scp a la máquina destino)
  • Se procede a levantar una instancia en el destino (Instancia con los parámetros básicos)
  • Se hace la restauración del control file (Restore controlfile from)
  • Se procede a limpiar el controlfile de todos los respaldos anteriores (Crosschek)
  • Se cataloga el respaldo que se copio en el ambiente de restino (Catalog start with)
  • Se realiza una restauración (Restore database con RMAN)
  • Se abre la base de datos en modo upgrade con resetlogs (alter database open resetlogs upgrade)
  • Una vez abierta, se procede a actualizar el catálogo con la ejecución del archivo catupgrd.sql

    - Cuando se ejecuta el archivo de actualización del catálogo , aparece el inefable error

    DOC>#######################################################################
    DOC>#######################################################################
    DOC> The following error is generated if the pre-upgrade tool has not been
    DOC> run in the old ORACLE_HOME home prior to upgrading a pre-11.2 database:
    DOC>
    DOC> SELECT TO_NUMBER('MUST_HAVE_RUN_PRE-UPGRADE_TOOL_FOR_TIMEZONE')
    DOC> *
    DOC> ERROR at line 1:
    DOC> ORA-01722: invalid number
    DOC>
    DOC> o Action:
    DOC> Shutdown database ("alter system checkpoint" and then "shutdown abort").
    DOC> Revert to the original oracle home and start the database.
    DOC> Run pre-upgrade tool against the database.
    DOC> Review and take appropriate actions based on the pre-upgrade
    DOC> output before opening the datatabase in the new software version.
    DOC>
    DOC>#######################################################################
    DOC>#######################################################################
    DOC>#

    Session altered.

    Table created.

    Table altered.

    SELECT TO_NUMBER('MUST_HAVE_RUN_PRE-UPGRADE_TOOL_FOR_TIMEZONE')
    *
    ERROR at line 1:
    ORA-01722: invalid number

    Con lo anterior, deberíamos proceder a abrir nuestra base de datos en el orígen Windows con motor 10.2.0.2, para ejecutar el script utlu112i.sql y hacer todos los cambios pertinentes, pero ....con el respaldo efectuado, en disco... y ya realizada la restauración procedemos a hacer un cambio para no efectuar todo el trabajo nuevamente..

    Solución :

  • Consultamos la tabla registry$database y vemos el valor que contiene

    SQL> select platform_id , platform_name from registry$database;

    PLATFORM_ID PLATFORM_NAME
    ----------- -----------------------------------------
    7 Microsoft Windows IA (32-bit)

  • Debemos borrar la información errónea de la tabla registry$database e incorporar la nueva versión de nuestra base de datos

    delete registry$database;
    commit;

  • Incorporamos la nueva versión de nuestro sistema operativo

    INSERT into registry$database
    (platform_id, platform_name, edition, tz_version)
    VALUES ((select platform_id from v$database),
    (select platform_name from v$database),
    NULL,
    (select version from v$timezone_file))
    ;

  • Chequemos el sistema operativo donde estamos trabajando (destino final de nuestra base de datos)

    SQL> !uname -a
    Linux nodo1-server-A 3.8.13-68.1.2.el6uek.x86_64 #2 SMP Mon Mar 30 11:56:28 PDT 2015 x86_64 x86_64 x86_64 GNU/Linux

  • Chequeamos el valor de nuestra tabla registry$database, que debe coincidir con nuestro sistema operativo

    SQL> select platform_id , platform_name from registry$database;

    PLATFORM_ID PLATFORM_NAME
    ----------- -----------------------------------------
    13 Linux 64-bit for AMD

    Posterior a esos cambios, podemos ejecutar nuestra actualización de catálogo sin problemas..teniendo en cuenta que para este caso en partícular se debe cambiar la base de 32 bits a 64 bits ;)

  • by Ligarius
    23.10.15. 09:32:06. 647 words, 1862 views. Categories: Base de datos ,

    ORA-38760: This database instance failed to turn on flashback database



    Ese es un error que sucedió cuando un disco de +ASM que contenía los FlashBack logs no pudo ser montado por ASM, simplemente una corrupción, sin respaldo y sin espejamiento de discos, o sea, simplemente murió.
    Documentación relacionada a FlashBack Database Logs : Flashback Database logs



    Sucedió después de un corte de electricidad y se vino todo abajo, una vez que se quiso levantar la base, no montando el diskgroup malo, apareció este error en la base de datos

    SQL> alter database open;
    alter database open
    *
    ERROR at line 1:
    ORA-38760: This database instance failed to turn on flashback database


    Pues bien, simplemente se consulto en la documentación y lo que había que hacer era deshabilitar los FlashBack logs , mediante el siguiente comando

    SQL> alter database flashback off;
    Database altered.


    Posterior a eso, se levanta la base de datos , pero arroja el mismo error

    SQL> alter database open;
    alter database open
    *
    ERROR at line 1:
    ORA-38760: This database instance failed to turn on flashback database


    De hecho, al tratar de dejar el FlashBack en ON, da un error de Recovery

    SQL> alter database flashback on;
    alter database flashback on
    *
    ERROR at line 1:
    ORA-38706: Cannot turn on FLASHBACK DATABASE logging.
    ORA-38714: Instance recovery required.


    El error está relacionado a la creación de puntos de restauración (restore point)
    Documentación relacionada : Restore Points


    Se consulta el registro completo de los puntos de restauración , pero da un error pues simplemente no tiene acceso a ellos, ya no existen los FlashBack logs , pues no hay Diskgroup disponible

    SQL> select * from v$restore_point;
    select * from v$restore_point
    *
    ERROR at line 1:
    ORA-38701: Flashback database log 3 seq 3 thread 1:
    "+DGFL/prod11/flashback/log_3.545.886173601"
    ORA-17503: ksfdopn:2 Failed to open file
    +DGFL/prod11/flashback/log_3.545.886173601
    ORA-15012: ASM file '+DGFL/prod11/flashback/log_3.545.886173601' does not exist



    El procedimiento para solucionarlo es el siguiente :

    - Primero consultamos el estado de nuestra base de datos, con lo cual se chequea que la base de datos posee puntos de restauración

    SQL> select flashback_on from v$database;
    FLASHBACK_ON
    ------------------
    RESTORE POINT ONLY


    - Consultamos sólo el nombre del punto de restauración , no el registro completo pues nos daría el mismo error que apareción antes en la nota

    SQL> select name from v$restore_point;
    NAME
    --------------------------------------------------------------------------------
    A1


    - Borramos el punto de restauración

    SQL> drop restore point A1;
    Restore point dropped.


    - Desactivamos el FlashBack Database logs

    SQL> SQL> alter database flashback off;
    Database altered.


    - Consultamos el estado de nuestra base de datos relacionado al FlashBack logs

    SQL> select flashback_on from v$database;
    FLASHBACK_ON
    ------------------
    NO


    - Procedemos a abrir la base de datos, tema solucionado

    SQL> alter database open;
    Database altered.

    ;)

    by Ligarius
    03.09.15. 14:16:58. 458 words, 4954 views. Categories: Base de datos, FlashBack , • Send a trackback »

    << 1 2 3 4 5 6 7 8 9 10 11 ... 44 >>