A raíz de una pregunta que me hicieron, me pareció que es un tema sumamente interesante y que muy pocos “nuevos” DBAs lo conocen bien. Por nuevos me refiero a los que se iniciaron con las versiones 11 en adelante. Hagamos un poco de historia. Hay un antes y un después de la versión 11, a partir de la cual éste algoritmo de CKPT fue optimizado terriblemente.

Para comprender un poco más, es necesario repasar un poco la importancia, criticidad y funcionamiento del CKPT.

Es crítico porque es un punto de control donde todos los data files quedan sincronizados según el LSN (Last Serial Number), donde todas las dirty pages son bajadas a disco (flush), y que de haber una caída o crash, es el punto de partida a partir del cual el motor arranca la recuperación (recovery), para que todos los datos sean consistentes, y mantengan integridad. También es importante entender que es un proceso sumamente costoso para el motor, ya que utiliza disk I/O para que todos los cambios se hagan persistentes o durables, y que por ende debe ser ÓPTIMO y ROBUSTO. Todos estos son varios de los atributos necesarios que un motor RDBMS debe cumplir: ACID (Atomicidad, Consistencia, Integridad y Durabilidad). Dado que es un proceso sumamente costoso, y justamente es la clave de buscar la menera más óptima de realizar el acceso a disco, entonces en vez de estar por cada TX que termina grabando a disco, se almacenan las TXs en los LLOGs y que junto con las BEFORE IMAGES del PHYSLOG, de haber una caída, a partir del último CKPT que encuentra inicia el recovery.

El proceso de CKPT consta de dos etapas, 1) Analizar y recorrer las LRUs en los BUFFERS buscando todas aquellas páginas modificadas o “dirty/sucias”, y 2) Hacer persistentes las páginas modificadas en los BUFFERS con los cambios en los data files o chunks (flush). Hay unos procesos llamados CLEANERS que se encargan de tanto hacer persistentes las páginas de la lista en 1), y de cambiar esas páginas de dirty a NOT dirty (para que puedan ser reescritas), y de liberar el PHYSLOG de las BEFORE IMAGES.

Habiendo descripto brevemente la criticidad, importancia y pasos del CKPT, podemos entonces entender por qué requiere EXCLUSIVIDAD. Esto quiere decir que durante su ejecución nada más debe suceder, es decir el procesamiento de TXs se congela (BLOCKED).

Resulta que a partir de la versión 11, el proceso de CKPT sufre unos enromes cambios y optimización. Uno de los cambios es que el BLOQUEO deja de incluir al paso 1) descripto más arriba, reduciendo así el tiempo donde el motor debe dejar de procesar TXs mientras realiza la búsqueda de páginas sucias o modificadas, y del paso 2) tampoco deja de procesar TXs mientras hace persistentes las páginas modificadas o sucias (salvo que la misma se encuentre en ése preciso momento siendo modificada por alguna transacción en proceso, con lo cual será la única transacción que será bloqueada). Vemos entonces que el BLOQUEO ha cambiado y optimizado considerablemente!

Pero ahí no termina toda la optimización!, el nuevo algoritmo de CKPT hace un uso intenso del PHYSLOG, el cual es utilizado para: realizar un restore, ejecutar un full backup, almacenar las BEFORE IMAGES de páginas que se van a modificar, o recuperarse de un crash donde usará tanto el LLOG (donde el motor logueó todas las transacciones ejecutadas a partir del último CKPT) como el PHYLOG (con todas las BEFORE IMAGES de las páginas que fueron modificadas).

El nuevo proceso de CKPT, ahora hace un uso más intenso del PHYSLOG para guardar las BEFORE IMAGES por más tiempo, porque los CKPTs pueden ser más espaciados y no regulares. Es por esto que el tamaño del PHYSLOG tiene que tener una relación directa con el tamaño de los BUFFERS. Vemos entonces que el motor no necesita estar regularmente procesando CKPTs según el CKPTINTVL, y menos durante horarios diurnos donde queremos que todo el potencial de CPU se utilice para procesar TXs (OLTP), y diferir el CKPT a algún momento del día más tranquilo.

Asimismo se introdujo entonces otro interesantísimo parámetro de SLA (Service Level Agreement), relativo al tiempo de recuperación en caso de una caída (crash), llamado RTO_SERVER_RESTART, donde se le indica la cantidad máxima de segundos que deseamos que el motor se tome para recuperase de la caída.

Estos son los eventos que podían ya antes y aún pueden desencadenar un CKPT:

1) CKTPITVL (mayor a 0 y por más que el AUTO_CKPTS esté en 1 ó activo),

2) PHYSLOG esté al 75% de uso,

3) onmode –c (manualmente),

4) Backup (lo 1ro que hace al arrancar un full backup es ejecutar un CKPT),

5) onspaces/onparams (al agregar un chunk o modificar los LLOGS/PHYSLOG,

6) LLOGs (antes de reescribir el LLOG donde está el último CKPT),

Más éste otro evento que se suma:

7) RTO_SERVER_RESTART (mayor a 0, y AUTO_CKPTS esté en 1 ó activo, por más que CKPTINTVL sea mayor a 0)

Existen otros eventos más que también disparan un CKPT, pero que no son relevantes al algoritmo o frecuentes o dependen de si se tiene HDR o no.

Como vemos podemos tener la posibilidad de optimizar los recursos del host al máximo, y tal vez ejecutar un solo CKPT en todo el día. Obviamente que dependerá de la actividad que haya (DMLs/DDLs), para eso tenemos que saber dimensionar el PHYSLOG en relación al tamaño de los BUFFERS que en general salvo algunas excepciones de calcularlo de aproximadamente un 110% del tamaño de los BUFFERS, y de los LLOGs tanto en tamaño de c/u, cantidad, y total.

Tengo un dicho: Administradores de Bases de Datos eran los de ANTES (de la versión 11), o los que tienen que SUFRIR administrando motores que NO SON INFORMIX.

Digo esto porque era una tarea sumamente complicada y no simple la de conseguir un perfecto balance en el motor para administrar los recursos, se requería de tiempo, estadísticas, experiencia y dedicación para no caer en CKPTs largos, ni tampoco demasiado cortos, porque los dos tenían sus PROs y CONTRAs, y no habían muchas opciones con las cuales contar, antes incluso estaban los LRU MAX y MIN, que hoy también existen, pero un poco más oculto, dentro de los BUFFERS, pero que casi no tienen tanta relevancia, e incluso el motor los maneja automáticamente si así se lo permitimos. Antes para evitar que los CKPTs largos nos bloquearan por más de 10 segundos, había que tunear los MAX y MIN con valores decimales!, para que el motor hiciera algunos LRU writes según los niveles de dirty pages %, y los CHUNK writes que son los del CKPT (esto se ve con un onstat –F | head, y el nivel de las dirty pages de las LRUs con un onstat –R | more). Los DBAs de INFORMIX de más de 10 años de experiencia van a entenderme bien lo que digo.

Es verdad que antes no había tanto requerimiento de procesos OLAP, en realidad se programaban para la noche como procesos batch largos, para que durante el día la performance fuera la mayor para los procesos OLTP.

Antes el motor era principalmente configurado para procesos OLTP, y con los RA (Read Ahead) manejábamos un poco los procesos OLAP, pero los CKPTs eran estáticos y regulares, los RA también, y las LRUs de los BUFFERS también!!!

Ahora, el motor de “self healing” con lo cual todo eso es AUTO_algo (AUTO_CKPTS, AUTO_READAHEAD y AUTO_LRUS). Esta es la razón por la cual INFORMIX requiere menos dedicación, less cost ownership (menos costos indirectos), también permite que sea embebido en procesadores como lo está haciendo SHAPSA/TATUNG para Casa Inteligentes o devices como CISCO, entre otros.

Hay que prestarle atención en el Engine Log, a éstos eventos:

Physical log is too small for bufferpool size.

System performance may be less than optimal.

Increase physical log size to at least ##Kb.

Transaction blocking has taken place. The physical log is too small.

Please increase the size of the physical log to ##Kb

Algunos onstats básicos útiles:

onstat –F

onstat –R

onstat –g ckp

onstat –l

Espero que les sirva!,