Jugando con las estadisticas de un esquema

Hoy vamos a ver algunas consultas practicas de las estadisticas de sistema

Esquemas o objetos de un esquema con las estadisticas bloqueadas

Veamos algunas consultas utiles para comprobar cuales son las tablas que estan bloqueadas o para trabajar con las estadistias del esquema APPSCHEMA

Tablas conlas estadisticas bloqueadas para un esquema


select owner, table_name, stattype_locked
from dba_tab_statistics
where
stattype_locked is not null and OWNER=’APPSCHEMA’;

Cuando fueron bloqueadas las estadisticas en estas tablas?


set linesize 200
set pagesize 0
col owner format a20;
col table_name format a30;
Select table_name,last_analyzed from dba_tables
where table_name in
(select table_name from dba_tab_statistics where stattype_locked is not null and OWNER=’APPSCHEMA’)
order by last_analyzed asc ;

Tenemos una metaconsulta para desbloquearlas todas?

  select 'exec dbms_stats.unlock_table_stats('||chr(39)||'APPSCHEMA'||chr(39)||','||chr(39)||TABLE_NAME||chr(39)||' );'
       from dba_tab_statistics where stattype_locked is not null and OWNER='APPSCHEMA';

Ver las fechas de las estadisticas que han sido analizadas en los ultimos 2 dias

set pagesize 9000;
column owner format a20;
column TABLE_NAME format a30;
column PARTITION_NAME format a30;
select owner,table_name,partition_name,to_char(LAST_ANALYZED,'dd-mm-yy hh:mi'),NUM_ROWS,STATTYPE_LOCKED from dba_TAB_STATISTICS
where OWNER='APPSCHEMA' 
and LAST_ANALYZED  < sysdate-2
order by LAST_ANALYZED asc ;

Ver la fecha en la que fueron obtenidas las estadisticas de una tabla en concreto

set pagesize 9000;
column owner format a20;
column TABLE_NAME format a30;
column PARTITION_NAME format a30;
select owner,table_name,partition_name,to_char(LAST_ANALYZED,'dd-mm-yy hh:mi'),NUM_ROWS,STATTYPE_LOCKED from dba_TAB_STATISTICS
where TABLE_NAME='APPSCHEMA' 
order by LAST_ANALYZED asc ;

Como salvamos las estadisticas de un determinado esquema

Creamos una tabla de estadisticas llamada «MISTATS bajo el esquema APPSCHEMA

exec dbms_stats.create_stat_table(ownname => 'APPSCHEMA', stattab => 'MISTATS');

Si quisiesemos guardar solo las estadisticas de una tabla

  
exec dbms_stats.export_table_stats(ownname=>'APPSCHEMA', tabname=>'MISTATS', statown=>'APPSCHEMA', stattab=>'MISTATS', cascade=>true);

Si queremos salvar los de un esquema

EXEC DBMS_STATS.export_schema_stats('APPSCHEMA','MISTATS',NULL,'APPSCHEMA');

Mas informacion en

Sqltunning desde sqlplus

Vamos a volver a la entradas para dummies con un error muy comun.

Uno de los errores mas frecuentes que tenemos desde el enterprise manager es cuando intentamos lanzar el SQL Tuning Advisor sobre una consuta pesada y obtenemos el error

ORA-01555 caused by SQL statement below (SQL ID: g5wg4kxu9m4g3, Query Duration=14163 sec, SCN: 0x09a1.42a95c42):

Este error no nos lo esta dando el advisor en si, sino que es un error del enterprise manager, para poder obtener este advice lo haremos de la siguiente manera

Supongamos que buscamos llevarlo a cabo sobre la SQLID g5wg4kxu9m4g3 y que tenemos identificada esta consulta entre dos snapshots, los 73485 & 73486

Los pasos que debemos de seguir son :

Definimos la tarea


begin_snap  => 73485,
end_snap    =>73486,
sqlidf => g5wg4kxu9m4g3

--create task 
DECLARE
l_sql_tune_task_id  VARCHAR2(100);
BEGIN
l_sql_tune_task_id := DBMS_SQLTUNE.create_tuning_task (
sql_id=> 'g5wg4kxu9m4g3',
time_limit=> 1500,
task_name=> 'g5wg4kxu9m4g3_tuning_task',
description=> 'Tuning task for statement g5wg4kxu9m4g3',
scope    => DBMS_SQLTUNE.scope_comprehensive
);
   
  DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
END;
/

Ejecutamos la tarea

EXEC DBMS_SQLTUNE.execute_tuning_task(task_name => 'g5wg4kxu9m4g3_tuning_task');

Obtenemos el resultado

set pagesize 999
set long 65536
set longchunksize 65536
set linesize 200
select dbms_sqltune.report_tuning_task('g5wg4kxu9m4g3_tuning_task') from dual;

Como podemos ver, el uso basico del paquete DBMS_SQLTUNE es extremadamente sencillo

Evento de espera enq: HW

Hoy vamos a ver un tipo de evento relaccionado habitualmente con las inserciones.

El HW High Water enqueue enq: HW se da cuando varios procesos compiten para aumentar el high water mark de una tabla .

Si disponemos del Enterprise manager console, podremos ver como aparece claramente un area marron de configuracion.

Esta carga se asocia claramente a una consulta de insert

Este caso puede ser comun en procesos de aplicacion con actualizaciones en paralelo sobre la misma tabla.

La manera de la resolución del mismo puede pasar por ampliar los freelists.

Mas informacion como siempre en soporte oracle

  • WAITEVENT: «enq: HW – contention» Reference Note (Doc ID 2098543.1)
  • Analyzing ‘enq: HW – contention’ Wait Event (Doc ID 740075.1)

Runaway queries : Consultas que tardan mas de lo esperado

Hoy vamos a ver otra entrada para dummies.

¿Que es una Runaway query?

Una «Runaway query» es una consulta que tarda mas de lo esperado, pero …
¿Como podemos definir «lo esperado»?

La definición que toma oracle de ese «mas de lo esperado » es que su ejecución se demora mas allá de lo esperado por el planificador , pero , en terminos corrientes llamamos así a las consultas que «no terminan nunca».

Como véis, inaguramos el mes con una entrada muy sencilla, pero es un concepto importante a tener en cuenta

Estudio de traza de un Deadlock

Hoy vamos a ver como obtener algo mas de información de una incidencia que probablemente tengamos a menudo.

Los deadlocks no implican mal funcionamiento de la base de datos

Lo primero que tenemos que tener muy claro es que un deadlock no es un mal funcionamiento de la base de datos, un deadlock (la traducción posiblemente sea interbloqueo) es una situación en la que dos o mas usuarios están esperando cada uno a un recurso bloqueado por el otro.
La manera en la que Oracle soluciona esta situación es rolling back una de las sentencias implicadas en el deadlock, al liberar uno de estos bloqueos la otra finaliza su solicitud.
Cuando esta situación ocurre, Oracle deja un fichero de traza en el $DIAG_DEST , que nos indica cuales eran los procesos y sentencias implicados. El análisis de esa traza es lo que vamos a mirar hoy.

Deadlock Graph

Seguramente el apartado mas importante de la traza sea el llamado «deadlock graph», estas dos líneas que parecen tan crípticas son las que mas información nos van a dar sobre el bloqueo.

Deadlock graph:
--------Blocker(s)------- --------Waiter(s)--------
Resource Name           process session_holds waits process session_holds waits
TX-000e001a-002dd880     65               414    X       24          9       X
TX-00090006-01e831ca     24                 9    X        65        414      X

Viendo el tipo de bloqueo en «resource_name» y los distintos waits podremos obtener el tipo de bloqueo que ha sido, para ello tenemos una tabla maestra en la nota de soporte How to Identify ORA-00060 Deadlock Types Using Deadlock Graphs in Trace (Doc ID 1507093.1).
En nuestro caso, por ejemplo,tendríamos según soporte un claro caso de bloqueo de aplicación.
Bloqueo TX X X

Información de la sesión

Otro apartado interesante es el de la información de la sesión. En este apartado nos indica de manera mas sencilla cuales son las sesiones implicadas y cuales son los objectos en los que hemos tenido el problema .
Mediante esta información podemos buscar los objetos por los que se han causado el interbloqueo

session 414: DID 0001-0041-000592FB session 9: DID 0001-0018-00004FD9 
session 9: DID 0001-0018-00004FD9 session 414: DID 0001-0041-000592FB
Rows waited on:
Session 414: obj - rowid = 001272E0 - AAExowAQAAAACF5AAUv (dictionary objn - 1209056, file - 1024, block - 8569, slot - 20)
Session 9:   obj - rowid = 001272E0 - AAExowAQAAAACMNAAJ  (dictionary objn - 1209056, file - 1024, block - 8973, slot - 9)

SQL implicado

Finalmente llegamos al apartado que puede ser mas clarificador de cara al equipo de desarrollo encargado de depurar el código.
Este tercer bloque nos amplia la información de las sesiones implicadas, contándonos esquema, terminal y las consultas implicadas en el deadlock

----- Information for the OTHER waiting sessions -----
Session 9:
sid: 9 ser: 37801 audsid: 206118217 user: 103/SCHEMA1    flags: (0x45) USR/- flags_idl: (0x1) BSY/////- flags2: (0x40009) //INC  pid: 24 O/S info: user: SYSTEM, term: SERVERTEST, ospid: 12260  image: ORACLE.EXE (SHAD)

client details:
O/S info: user: launcherusr, term: , ospid: 13041768  machine: client2 program: schema2@client2 (TNS V1-V3)  application name: schema2@client2 (TNS V1-V3), hash  alue=54028978

current SQL:
UPDATE SCOTT2.TIPO_COCHE  SET COLOR = :1, CILINDRADA = :2 WHERE MATRICULA = :3 AND ANCHO = :4
----- End of information for the OTHER waiting sessions -----

Information for THIS session:
----- Current SQL Statement for this session (sql_id=8zqxt1a6d7ts1) -----
UPDATE SCOTT2.TIPO_COCHE SET TIPO = :1, PERSONA = :2 WHERE MATRICULA = :3 AND LARGO = :4

El fichero de traza es mucho mas amplio, pero, como habéis podido ver, mediante el estudio de la cabecera de la traza podemos recopilar mucha información para poder depurara el código de aplicación para que no vuelva a ocurrir

Como siempre, tenemos mas información en soporte, en las notas

  • Master Note for Database Error ORA-00060 «deadlock detected while waiting for resource» (Doc ID 1509919.1)
  • Master Note: Locks, Enqueues and Deadlocks (Doc ID 1392319.1)
  • How to Identify ORA-00060 Deadlock Types Using Deadlock Graphs in Trace (Doc ID 1507093.1)