Tablas con FULL SCAN en la Buffer Cache

Feliz 2010 a los posible lectores :D

La verdad este año tengo el propósito de escribir un poco más a menudo (Siempre digo lo mismo, jejeje). Bueno, empiezo con algo muy rapidito. Buscando y buscando y buscando en google, encontré la descripción de la columna flag.x$bh. Interesante, y encontré que:

FLAG
KCBBHFSQ 0x80000 sequential scan only flag

KCB = Kernel Cache Buffer.

El objetivo es conocer todos los objetos que están en la buffer cache que se suben de forma secuencial, esto "PUEDE" implicar que si son tablas, se un FULL SCAN forma de acceso.
¿Para qué sirve?
Pues para conocer las POSIBLES tablas que están en la Buffer Cache con FULL SCAN, importante por temas de rendimiento y esas cosas :D. Por aquello de "menos CR mejor", aunque como todo "depende", pero en general o porque no, menos I/O mejor.

¿Cómo puedo entonces sacar la lista de esas tablas?
Aquí está una consulta, ya después es a gusto del consumidor lo que hagan con ella. Yo excluyo los las tablas de los objetos, propios de algunos componentes de Oracle.

SELECT distinct o.owner,o.object_name,o.object_type,o.owner
FROM dba_objects o,x$bh x
WHERE x.obj=o.object_id
AND o.object_type='TABLE'
AND standard.bitand(x.flag,524288)>0
AND o.owner not in ('SYS','PATROL','FLASHBACKSTATS','INVENTORY', 'SCOTT'
,'OUTLN','TSMSYS','EXFSYS','SYSMAN','SYSTEM', 'MDSYS', 'DMSYS', 'CTXSYS'
,'DBSNMP','WMSYS','SMSEXP', 'ORDPLUGINS', 'ORDSYS', 'PUBLIC', 'OLAPSYS');

El 524288 es el decimal del hexadecimal 80000, por tanto, la columna FLAG contiene muchísima información. Hasta la 9i se de 38 datos sobre el estado del bloque en la buffer cache.

Nota:
Según un compi mío, del cual no quiero dar el nombre porque se cabrea :). Él me dijo que si la cantidad de bloques de la consulta son mayores que el 10% del tamaño de la buffer cache (se puede contralar por parámetro oculto, creo) entonces Oracle protege la SGA y no va a memoria esta cantidad de bloques sino directamente a la UGA. Así bien para server processes dedicados, sería su PGA, pero cuando usan Shared Server, en teoría debería ir a la Large Pool, pero esto todavía lo tendría que confirmar :), si alguien ya lo ha probado me gustaría verlo.

Ellas no tienen la culpa...

Buenas,

He estado de vacaciones. Les recomiendo ir a visitar antes de morir, alguna isla griega, bueno, Grecia en general.
Estoy preparando otro examen de los de Oracle, pero no quiero dejar pasar la oportunidad de decirles algo, que he venido pensando desde hace tiempo, y que hoy quiero compartir. Si alguien leé este blog :).
Las bases de datos que administran, crean o afinan, no tienen que ser las afectadas directas de sus personalidades.
Si eres inteligente, tarado, amargado, alegre, egosita, generoso, petulante, humilde, etc. Como sea que seas. Las bases de datos, son las que se ven altamente perjudicadas por tu forma de se; si no tienes un método a seguir, en tu trabajo contidiano con ellas.
Si eres una persona descuidada, te dejaras cosas sin analizar, sin revisar. Si eres demasiado obstinado, te enfocas en un solo objetivo y no tendras una visión holística de esa bases de datos. Si eres charlatan, buscas cualquier excusa para decir que no es la base de datos, y que es la aplicación, el sistema operativo, la red, ó lo que sea. Si eres un holganzán, simplemente no investigas el error.
Todo esto, es una de las causas reales del mal funcionamiento de los sistemas, por tanto las bases de datos. Y además, porque también chocamos frontalmente y a diario con otras mentalidades ó personalidades, y como conclusión las grandes perjudicadas son ellas, las bases de datos.
Esto es matemática, es informática, y por tanto, una ciencia. No es en ningun momento un arte.
En una cadena de producción (gracias Ford), hay un tiempo en el que se hace cada labor. Así bien, debemos intentar llegar a un punto cercano.
Creo fielmente que debemos buscar ese objetivo, y no es más, que ser objetivos.
Cuando te piden resolver un problema matemático, simplemente buscas la fórmula que aplica, y lo intentas solucionar.
¿Quien no se queja de algunos médicos?
Pues esto, es algo parecido. Cuando vas al doctor, si el doctor de turno está de mal genio, ó el doctor de turno es una persona "demasiado alegre", ó no es objetivo. Probablemente no haga su labor, y esto lleva a tu enfado ó molestia, con la posibilidad que la enfermedad se agrave.
Este trabajo ó profesión, la informática, tiene mucho en común. Pero las que sufren son maquinas, y ellas no se quejan. Simplemente dejan de funcionar, ó tienen un rendimiento paupérrimo
Por favor, recuerden SIEMPRE una fórmula muy simple, pero bastante efectiva, de muchos documentos oficiales de Oracle:

Tiempo de respuesta = Tiempo de Servicio + Tiempo de espera

A diferencia de los médicos, aquí en las bases de datos 1 + 1, si que es igual a 2. Si haces un FULL SCAN, ó RANGE SCAN, ó UNIQUE INDEX, deberías saber cuantos bloques usas (No en todos los casos ;).
Si tarda 50 segundos en ejecutar una consulta, tarda eso 50 segundos. Son números. Para los médicos, 1 + 1 no son 2, así que ellos lo tienen más complicado, y su ciencia sigue en pie, creciendo, y en la que muchos confiamos.
Existen muchos documentos públicos y gratis, donde explican razonamientos metódicos de resolución de problemas. Ahora está de moda el troubleshooting. También bastantes documentos de tuning, algo que es bastante más complicado que el troubleshooting.
Espero algún día no muy lejano, sintetizar varios de los documentos de lo que les hablo y que he medio leído, y regalarlo. Si, regalarlo aquí, en este blog. Por si a alguien le sirve.
Así, si están de mal genio, si tienen hambre, si tienen frio, si están contentos, si están nerviosos. Estén como estén, sus bases de datos no sufren sus cambios temporales de humor, y tampoco de sus respectivas personalidades. Porque podrán seguir un guión, para cada una de las situaciones correspondientes a sus diversos problemas diarios con las bases de datos, no con sus vidas.
Personalmente intento a diario aplicarme este pensamiento. En ocasiones lo consigo, pero en muchas otras, me dejo llevar de mi pasión por mi profesión.

El gran misterio del log_buffer

Buenas de nuevo, escribo algo muy sencillo, pero que he visto que está extendido en varias bases de datos que he tocado. Lo llamaré “El gran misterio log_buffer”. Y es que he visto en más de una ocasión que el valor de este parámetro está puesto a 10M y hasta 32M. Y me pregunto ¿Por qué y para qué?
He notado que algunos administradores tienden a aumentar el tamaño de este valor cada vez que aumentan el tamaño de su SGA, pero esto sin duda alguna, es una “mala” práctica, y ahora les explico porqué. Para ello primero me pregunto ¿Para que uso ese pedacito de memoria y como funciona? Cada vez que realizo hago cambios (Insert, Delete, Update, y más cosas) estos cambios se guardan en memoria temporalmente, justo ahí, en el redo log buffer, y el tamaño de este buffer lo determina el parámetro log_buffer. Si ocurren ciertos eventos, un proceso llamado Log Writer (LGWR) “escribe” la información que está en esa parte de la memoria a los Online Redo logs, mejor, realmente “vuelca” (flush en ingles) la información de memoria a disco, y reutiliza ese espacio. Con esto se esta intentando guardar la integridad de los datos y de la base de datos (a groso modo).
Pero ¿Cada cuanto vuelco esta información que está en la memoria a disco?
Existen varios eventos por los que se producen estas escrituras. Quien lo describe perfectamente es Tom Kyte en su libro “Expert Oracle database architecture” en la página 176, donde dice que estos eventos (LGWR despierta para trabajar) se ejecutan cada:

- Tres segundos
- “COMMIT” de cualquier transacción
- Cuando se llega a un tercio del tamaño del redo log buffer
- Cuando llega a 1M de información

También pueden encontrar esta información en METALINK en la nota “Tuning the Redolog Buffer Cache and Resolving Redo Latch Contention” con id 147471.1, ó también esto mismo lo podemos leer en el documento "Performance Tuning Guide " ya sea 9i ó 10g, en el capitulo de "Memory Configuration and Use" en la parte de "Configuring and using the Redo Log Buffer".

Entonces teniendo en cuenta que se va a realizar un volcado de esta información cada vez que llegue a 1M, ¿Por qué tengo 14M ó incluso 30M de redo log buffer? La verdad, no lo se y no lo entiendo, el caso es que he encontrado estos “detalles” en muchísimas bases de datos. Y los argumentos de algunos son : que es un OLTP (gran volumen de transacciones), o que su SGA es muy grande, y otra razón que también escucho es que como tienen muchas CPU pues deducen (ejemplo: 32*512K dan 16M de log_buffer) tal y como dice el DBA Reference. Pero realmente creo que muchos DBAs no ven normal que el resto de “pools” de la SGA vayan creciendo según la carga y/o el tipo de uso de la base de datos y que esta parte de la memoria no lo crezca también, y simplemente la aumentan por si acaso, creo.

Pero es cierto es una “mala” practica, sino pruébenlo, pasen de 14M (si lo tienen) a 3M, en sus base de datos (8i, 9i ó 10g), miren si el rendimiento de su base de datos decrece.
Realmente no importa mucho si tienes 32 Gigas de memoria y de SGA tienes 24. Al final lo único que estas haciendo es desperdiciar unos pocos megas, tal y como lo dice Tom.
Este pequeño espacio de memoria le viene muy bien a otras partes de la SGA, y no veo conveniente desperdiciar ni bloque del sistema para nada, solo por un mal mito repartido en muchos sitios.
Si después de esta prueba ven que el rendimiento decrece o es malo por este cambio, por favor envíenme la demostración "real" que estoy deseoso de verla, ya que confío y creo que esto no se produce.

Por cierto, si realmente consumen menos de 300K de información de redo por segundo (el dato aparece en los reportes AWR), no es necesario ni siquiera llegar hasta los 3M, con menos de esto valor nos vale (calcúlalo con lo antes explicado ;). Es poco común, pero este mundo es muy grande. Claro, que tampoco es correcto poner un valor muy pequeño, y ese es el momento donde posiblemente tengas algún problema, reduciéndolo demasiado.