A ra\u00edz de una pregunta que me hicieron, me pareci\u00f3 que es un tema sumamente interesante y que muy pocos \u201cnuevos\u201d 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\u00e9s de la versi\u00f3n 11, a partir de la cual \u00e9ste algoritmo de CKPT fue optimizado terriblemente.<\/p>\n
Para comprender un poco m\u00e1s, es necesario repasar un poco la importancia, criticidad y funcionamiento del CKPT.<\/p>\n
Es cr\u00edtico porque es un punto de control donde todos los data files quedan sincronizados seg\u00fan el LSN (Last Serial Number), donde todas las dirty pages son bajadas a disco (flush), y que de haber una ca\u00edda o crash, es el punto de partida a partir del cual el motor arranca la recuperaci\u00f3n (recovery), para que todos los datos sean consistentes, y mantengan integridad. Tambi\u00e9n 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 \u00d3PTIMO 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\u00e1s \u00f3ptima 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\u00edda, a partir del \u00faltimo CKPT que encuentra inicia el recovery.<\/p>\n
El proceso de CKPT consta de dos etapas, 1) Analizar y recorrer las LRUs en los BUFFERS buscando todas aquellas p\u00e1ginas modificadas o “dirty\/sucias”, y 2) Hacer persistentes las p\u00e1ginas 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\u00e1ginas de la lista en 1), y de cambiar esas p\u00e1ginas de dirty a NOT dirty (para que puedan ser reescritas), y de liberar el PHYSLOG de las BEFORE IMAGES.<\/p>\n
Habiendo descripto brevemente la criticidad, importancia y pasos del CKPT, podemos entonces entender por qu\u00e9 requiere EXCLUSIVIDAD. Esto quiere decir que durante su ejecuci\u00f3n nada m\u00e1s debe suceder, es decir el procesamiento de TXs se congela (BLOCKED).<\/p>\n
Resulta que a partir de la versi\u00f3n 11, el proceso de CKPT sufre unos enromes cambios y optimizaci\u00f3n. Uno de los cambios es que el BLOQUEO deja de incluir al paso 1) descripto m\u00e1s arriba, reduciendo as\u00ed el tiempo donde el motor debe dejar de procesar TXs mientras realiza la b\u00fasqueda de p\u00e1ginas sucias o modificadas, y del paso 2) tampoco deja de procesar TXs mientras hace persistentes las p\u00e1ginas modificadas o sucias (salvo que la misma se encuentre en \u00e9se preciso momento siendo modificada por alguna transacci\u00f3n en proceso, con lo cual ser\u00e1 la \u00fanica transacci\u00f3n que ser\u00e1 bloqueada). Vemos entonces que el BLOQUEO ha cambiado y optimizado considerablemente!<\/p>\n
Pero ah\u00ed no termina toda la optimizaci\u00f3n!, 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\u00e1ginas que se van a modificar, o recuperarse de un crash donde usar\u00e1 tanto el LLOG (donde el motor logue\u00f3 todas las transacciones ejecutadas a partir del \u00faltimo CKPT) como el PHYLOG (con todas las BEFORE IMAGES de las p\u00e1ginas que fueron modificadas).<\/p>\n
El nuevo proceso de CKPT, ahora hace un uso m\u00e1s intenso del PHYSLOG para guardar las BEFORE IMAGES por m\u00e1s tiempo, porque los CKPTs pueden ser m\u00e1s espaciados y no regulares. Es por esto que el tama\u00f1o del PHYSLOG tiene que tener una relaci\u00f3n directa con el tama\u00f1o de los BUFFERS. Vemos entonces que el motor no necesita estar regularmente procesando CKPTs seg\u00fan 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\u00fan momento del d\u00eda m\u00e1s tranquilo.<\/p>\n
Asimismo se introdujo entonces otro interesant\u00edsimo par\u00e1metro de SLA (Service Level Agreement), relativo al tiempo de recuperaci\u00f3n en caso de una ca\u00edda (crash), llamado RTO_SERVER_RESTART, donde se le indica la cantidad m\u00e1xima de segundos que deseamos que el motor se tome para recuperase de la ca\u00edda.<\/p>\n
Estos son los eventos que pod\u00edan ya antes y a\u00fan pueden desencadenar un CKPT:<\/p>\n
1) CKTPITVL (mayor a 0 y por m\u00e1s que el AUTO_CKPTS est\u00e9 en 1 \u00f3 activo),<\/p>\n
2) PHYSLOG est\u00e9 al 75% de uso,<\/p>\n
3) onmode \u2013c (manualmente),<\/p>\n
4) Backup (lo 1ro que hace al arrancar un full backup es ejecutar un CKPT),<\/p>\n
5) onspaces\/onparams (al agregar un chunk o modificar los LLOGS\/PHYSLOG,<\/p>\n
6) LLOGs (antes de reescribir el LLOG donde est\u00e1 el \u00faltimo CKPT),<\/p>\n
M\u00e1s \u00e9ste otro evento que se suma:<\/p>\n
7) RTO_SERVER_RESTART (mayor a 0, y AUTO_CKPTS est\u00e9 en 1 \u00f3 activo, por m\u00e1s que CKPTINTVL sea mayor a 0)<\/p>\n
Existen otros eventos m\u00e1s que tambi\u00e9n disparan un CKPT, pero que no son relevantes al algoritmo o frecuentes o dependen de si se tiene HDR o no.<\/p>\n
Como vemos podemos tener la posibilidad de optimizar los recursos del host al m\u00e1ximo, y tal vez ejecutar un solo CKPT en todo el d\u00eda. Obviamente que depender\u00e1 de la actividad que haya (DMLs\/DDLs), para eso tenemos que saber dimensionar el PHYSLOG en relaci\u00f3n al tama\u00f1o de los BUFFERS que en general salvo algunas excepciones de calcularlo de aproximadamente un 110% del tama\u00f1o de los BUFFERS, y de los LLOGs tanto en tama\u00f1o de c\/u, cantidad, y total.<\/p>\n
Tengo un dicho: Administradores de Bases de Datos eran los de ANTES (de la versi\u00f3n 11), o los que tienen que SUFRIR administrando motores que NO SON INFORMIX.<\/p>\n
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\u00eda de tiempo, estad\u00edsticas, experiencia y dedicaci\u00f3n para no caer en CKPTs largos, ni tampoco demasiado cortos, porque los dos ten\u00edan sus PROs y CONTRAs, y no hab\u00edan muchas opciones con las cuales contar, antes incluso estaban los LRU MAX y MIN, que hoy tambi\u00e9n existen, pero un poco m\u00e1s oculto, dentro de los BUFFERS, pero que casi no tienen tanta relevancia, e incluso el motor los maneja autom\u00e1ticamente si as\u00ed se lo permitimos. Antes para evitar que los CKPTs largos nos bloquearan por m\u00e1s de 10 segundos, hab\u00eda que tunear los MAX y MIN con valores decimales!, para que el motor hiciera algunos LRU writes seg\u00fan los niveles de dirty pages %, y los CHUNK writes que son los del CKPT (esto se ve con un onstat \u2013F | head, y el nivel de las dirty pages de las LRUs con un onstat \u2013R | more). Los DBAs de INFORMIX de m\u00e1s de 10 a\u00f1os de experiencia van a entenderme bien lo que digo.<\/p>\n
Es verdad que antes no hab\u00eda tanto requerimiento de procesos OLAP, en realidad se programaban para la noche como procesos batch largos, para que durante el d\u00eda la performance fuera la mayor para los procesos OLTP.<\/p>\n
Antes el motor era principalmente configurado para procesos OLTP, y con los RA (Read Ahead) manej\u00e1bamos un poco los procesos OLAP, pero los CKPTs eran est\u00e1ticos y regulares, los RA tambi\u00e9n, y las LRUs de los BUFFERS tambi\u00e9n!!!<\/p>\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\u00f3n por la cual INFORMIX requiere menos dedicaci\u00f3n, less cost ownership (menos costos indirectos), tambi\u00e9n permite que sea embebido en procesadores como lo est\u00e1 haciendo SHAPSA\/TATUNG para Casa Inteligentes o devices como CISCO, entre otros.<\/p>\n
Hay que prestarle atenci\u00f3n en el Engine Log, a \u00e9stos eventos:<\/p>\n
Physical log is too small for bufferpool size.<\/p>\n
System performance may be less than optimal.<\/p>\n
Increase physical log size to at least ##Kb.<\/p>\n
Transaction blocking has taken place. The physical log is too small.<\/p>\n
Please increase the size of the physical log to ##Kb<\/p>\n
Algunos onstats b\u00e1sicos \u00fatiles:<\/p>\n
onstat \u2013F<\/p>\n
onstat \u2013R<\/p>\n
onstat \u2013g ckp<\/p>\n
onstat \u2013l<\/p>\n
Espero que les sirva!,<\/p>\n","protected":false},"excerpt":{"rendered":"