Tu, administrador, eres solo otro tipo de operador

Hablando con un buen administrador de Unix me comentó, en un día un poco aburrido para él, que iba a cambiar en su firma de “Administrador Unix” a “Operador nivel 2”, que al final muchas veces se siente que hace justo eso. Y me hizo pensar en escribir sobre esto, sobretodo por varios comentarios entre los diversos clientes en los que he estado, acerca del trabajo de los operadores. Sin ir más lejos, yo mismo, cuando me dijeron en un proyecto que las migraciones se llevaban con solo operadores, contratados para darle a al botón de “Press Button to Migrate” de una herramienta que migraba de 8i y 9i a 10g (Que realmente con ejecutar un par de comandos, mentira gorda), el caso es que yo mismo pensé “¿Un operador puede hacer eso? Vaya herramienta”. Al final creo que estaba siendo un poco despectivo con los operadores, y la verdad “Yo soy también un operador”.
Y esa es la cruel realidad, somos “operadores” de “alto” nivel, de herramientas como Unix, Oracle, Veritas, SAP, etc. Entonces al final, creo que muchos deberían replantearse el tratar despectivamente a los operadores y a los programadores, por que, los primeros son como nosotros pero con algo menos de conocimiento (algunos administradores ni eso). Y ellos, al igual que nosotros, cogen su “manual de operaciones” para resolver ciertas incidencia, y las incidencias que no se pueden apuntar en ese manual, son las hacemos nosotros.
Los administradores también tiene su “manual de operaciones”, y un ejemplo es el “SQL Reference” ó el manual del administrador ó el de “Tuning de Unix” ó el de “Backup & Recover Advance”, pero al final si la analizas bien, siguen siendo unos manuales de operaciones, más extensos, eso si. Y para bajarnos un poco más de la nube, los programadores si que son los importantes en todo esto, ya que sus programitas hacen que nuestra vida sea más o menos fácil. Si ellos se equivocan tenemos un “BUG” y a consultar parches, ó si ellos lo hacen bien y su analista también lo hace bien, pues tienes amplias opciones para configurar y optimizar una base de datos, un sistema operativo ú otro producto. Pero al final son ellos los buenos, así que replanteemos ¿Qué voy a hacer cuando un operador te llama a las 4 de la mañana a reportarte un problema que para ti no es problema? Pensar que no encontró la solución en “su manual” y que te llama por ese motivo, así como te puede pasar a ti, cuando los manuales súper avanzados, no te dan la respuesta.
Otro tema que está dentro de éste, es lo que Oracle llama DBA 2.0. Interesante, para los que no tienen idea de lo que es esto, pues simplemente como Oracle ya tiene un Oracle Linux Enterprise 4 y 5, como además tienes Clusterware y ASM, pues para ellos el administrador a “dado un paso adelante” en lo que es el ”todo” de los sistemas, porque estas incluyendo para los roles de un “ operador avanzado de Oracle” un sistema operativo, el almacenamiento y el clustering. Pero además te mete herramientas “avanzadas” de optimización, como son todos los “..ADVICE” (las vistas que terminan en eso), también tienes el replay (a partir de la 10.2.0.4), también tenemos el ADDM y todos los “automatic managemente” (UNDO, SGA, PGA, MEMORY) y que quede claro que no estoy en contra de estas opciones, de lo que estoy en contra es de no saber al final lo que realmente está pasando “dentro” de la base de datos. Y todo porque no te da tiempo a leer como montar ó como manejar en todo lo nuevo que están introduciendo Oracle.
Hace un tiempo le dije a un cliente que revisara el almacenamiento de una tabla, y me contesta que el “Segment Advisor” no le da ninguna recomendación, y que por eso no va a hacer nada, y me preguntó que más hacía con esa tabla. Y es esto, es precisamente a lo que me refiero, el DBA 2.0, sin querer te va a llevar hasta esta situación. Si damos un par de pasos atrás, ser OCP 8i era todo un reto, y ahora ser OCP 10g hasta hace poco no te exigían ni el examen de SQL (lo cambiaron en diciembre de 2008). Antes eran 5 exámenes, el de SQL, PL/SQL, Administración I y II, y tuning. Después quitaron la parte de PL/SQL, y por último pasaron a solo 2 exámenes (Primero OCA y después OCP), y es algo en lo que estoy de acuerdo, porque ASM, FLASHBACK, RMAN, Advisors, los nuevos tipos de segmentos, etc. es mucho material, pues si, si quieres saber que hay por dentro. Pero entonces con todo esto ¿Donde queda tu “control” o el control de lo que haces? La verdad, personalmente (y otros amigos también me lo comentan) prefiero al DBA 1.1 y si puede ser el DBA 0.7, ese que pasó de la versión 7.3.3 a la 8.1.4 y después se deslumbró con la 9.2.0.4. Prefiero a ese que sabía en la 9i como iban los rollback segments, ese que también conocía como tratar los diferentes parámetros para la PGA en dedicado (bitmap, sort, hash y merge), ese que hacia el examen de tuning.
Con la 10g, tienes un mundo inmenso por conocer, y es realmente impresionante todo lo nuevo que hay. Pero no le daría “tanta” importancia a las herramientas que te “facilitan” la vida. Le daría más importancia a saber ó intentar entender, que es lo que se cuece por dentro. Para realmente decirle a los clientes que es lo que realmente necesitan, y de acuerdo a cada situación implementar justo lo necesario. Si que hay muchas cosas que ver y conocer, es más, ejemplo clarísimo, sql_id, que para mi es un alivio, ver mis consultas completas (sql_fulltext.v$sqlstats), y que también puedo ver con las DBA_HIST_% (Es una licencia aparte en la 10g y en la 11g viene incluidas, según lo leído en otros blogs) información de varios días atrás para intuir algunos problemas.
En conclusión, los administradores no debemos ponernos muchas más medallas que los operadores, porque al final lo somos. Y además, creo que es bonito seguir intentando entender como va la LRU y la LRUW del buffer cache, saber como van los latch, mutex, enqueues, ó saber todos los parámetros que hay por ejemplo en el log_archive_dest_n ó como intentar hacer que una consulta tenga menos lecturas lógicas, prefiero estos antes que saber como sacar un reporte ADDM ó como se usa el DBMS_SQLTUNE. Que repito, está bien conocerlos y probarlos, pero no basar tu vida de operador nivel 2 en ellos.

Mas del 4031 y sub-pools

Se va a hacer de rogar el post de CPU Costing de Ricardo, pero es que tengo un pequeño detalle que intenté dejarle a un comentario a Tanel Poder del post que puso hace unos días, pero al final no pude. Así que primero, incentivarlos leer el blog de Tanel Poder que me parece genial, y decirles que allí hay un buen post sobre los errores 4031 y de la shared pool y los sub-pools en:

ORA-04031 errors and monitoring shared pool subpool memory utilization with sgastatx.sql

El caso es que se habla de una sub-pool 0, y que es memoria que no se le da al resto de las sub-pools de la shared pool. Bueno solo añadir que este espacio de memoria que describe Tanel en su blog no existe cuando está desactivado el manejo automático de memoria conocido como ASMM (Automatic Shared Memory Management), que pasa cuando tienes el parámetro SGA_TARGET a 0 ó el parametro STATISTICS_LEVEL en “BASIC”. Realicé una pequeña prueba y este fue el resultado:

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.