En primer lugar hay que entender como funciona y se maneja la base de datos de Caché, eso esta descrito en este capitulo de la documentación (http://docs.intersystems.com/ens20121/csp/docbook/DocBook.UI.Page.cls?KEY=GSA_manage#GSA_manage_databases).
Caché aumenta el tamaño conforme lo va necesitando, cuando en el CACHE.DAT ya no queda espacio entonces se aumenta el tamaño del fichero y lo hace en trozos del 12% del tamaño actual de la base de datos (o en 10 MB dependiendo de lo que sea más grande). Por ejemplo, si tu base de datos ocupa 1 GB (1.024 MB) entonces cuando le toca crecer lo hará en 124 MB aproximadamente.
El fichero CACHE.DAT nunca decrece, es decir, nunca reduce su tamaño de forma automática. De esta forma, si por ejemplo recibes 10.000 mensajes de 10 KB cada uno es posible que necesites más de 100 MB para almacenarlos, si como en el caso anterior la base de datos crece en 124 MB, entonces tienes un restante de 24 MB. Pero imagina que luego se purgan esos mensajes, entonces el espacio se libera pero el fichero no decrece en tamaño y se quedará con un tamaño de 1.148 MB pero con 124 MB de espacio libre. Esto seguirá así hasta que sea necesario crecer de nuevo.
Siempre es posible "truncar" y/o "compactar" el espacio para reducir el volumen del fichero CACHE.DAT. Es por esto que las bases de datos de Ensemble se suelen mantener en un tamaño "constante".
Por otro lado está el journal (http://docs.intersystems.com/ens20121/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_journal). Los ficheros de journal son unos ficheros muy simples que registran cada una de las operaciones que se realizan de forma atómica en los globals. Recuerda que finalmente uses objetos o SQL la información reside en los globals. Las operaciones en los globals son SET y KILL y si miras el contenido del global desde el Operaciones >> Journal veras algo como:
Off
|
Hora
|
Proceso
|
Tipo
|
Global
|
Base de datos
|
|
13..
|
20..
|
25..
|
KILL
|
^SYS("Task","TaskI","ScheduleIndex",62748,0,0,1)
|
/Users/ensemble/mgr/
|
|
13..
|
20..
|
25..
|
SET
|
^SYS("Task","TaskI","ScheduleIndex",62749,0,0,1)
|
/Users/ensemble/mgr/
|
|
13..
|
20..
|
25..
|
SET
|
^SYS("Task","TaskAttemptCount",5)
|
/Users/ensemble/mgr/
|
|
13..
|
20..
|
25..
|
SET
|
^SYS("Task","TaskD",1)
|
/Users/ensemble/mgr/
|
Como ves refleja cada uno de los SET y KILL en cualquier base de datos de la instancia.
Los journals se utilizan como mecanismo de recuperación ante desastre. De hecho cuando Caché se recupera de una caída el automáticamente aplica de forma redundante las entradas existentes en el JOURNAL que hayan podido quedar pendientes por estar en memoria o en el WIJ (http://docs.intersystems.com/ens20121/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_wij). Además se usan para otras estrategias de replicación o de restauración.
En cualquier caso, y como te puedes imaginar, el journal, crece, crece y crece. El journal se compone de ficheros, normalmente limitados a 1GB como máximo, sin embargo hay una tarea que de manera automática cambia el fichero del journal cada día. De manera que puedes encontrarte con muchos ficheros de menos de 1GB (cambio por tiempo) o de 1GB (cambio por tamaño).
Los ficheros de journal no son necesarios eternamente. Por ejemplo si has hecho un Backup los journal hasta la fecha del Backup se suelen eliminar porque ya no recuperas del journal sino del Backup. Por lo tanto, normalmente hay una tarea programada que purga (elimina) los ficheros de journal que ya no son útiles. También se puede realizar esta tarea con la rutina PURGE^JOURNAL desde el namespace %SYS.
Mucho crecimiento en journal describe mucho movimiento en base de datos, pero ese movimiento puede ser igualmente repartido en SET y KILL de manera que la base de datos se queda igual. Por otro lado es normal no ver crecimiento en la base de datos porque es posible que el espacio libre internamente sea bastante.
El consumo de disco por parte de los journals no se puede evitar. Pero se puede gestionar, es decir, puedes purgarlos más a menudo tratando de conservar el espacio consumido. Esto se puede hacer ejecutando la tarea de purgado más a menudo o con unos criterios más relajados. En la opción de configuración de sistema >> configuración de journal puedes editar esos criterios de borrado.
Espero que sea de utilidad
2 comentarios:
Gracias david por tus conocimientos, una lástima que no te prodigues más.
Un salu2.
Muy buenos consejos!
Aqui algunos comentarios y algún consejo más:
David cuando dices
"Los globals se utilizan como mecanismo de recuperación ante desastre"
querías decir:
"Los journals se utilizan como mecanismo de recuperación ante desastre"
Un problema común en sistemas Ensemble que no se están constantemente administrando es el aumento del tamaño de las bases de datos por tener muchos mensajes.
Es aconsejable tener tareas de purgado de mensajes (Seguro que David tiene algo escrito en su blog o en el foro de usuarios de Ensemble). Con estas tareas de purgado vamos a evitar que las bases de datos crezcan mucho, pues la idea es ir borrando todos aquellos mensajes que ya no se van a utilizar ni a consultar.
Por ejemplo, es común trabajar y conservar el último mes o los últimos 3 meses de mensajes. Todo lo anterior es factible purgarlo.
Una vez que se tengan estas tareas de purgado, las bases de datos crecerán más lentamente, pues la purga hará espacio para los nuevos mensajes.
Ojo, que también es muy común el purgar ocasionalmente una gran cantidad de mensajes, por ejemplo, entrar en el portal y purgar los 2 últimos años. Si hacemos esto, tendremos mucho crecimiento de journal temporal que irá registrando el purgado de mensajes, pues lo hace en modo transaccional. Este crecimiento de journal, si la máquina dispone de espacio, será temporal y se eliminará posteriormente. Pero, no es raro ver que al hacer la purga nos quedamos sin espacio en disco por el crecimiento puntual de los journals.
Si estamos en ese caso, lo mejor será, purgar de poco en poco e ir viendo como crecen los journals y qué espacio libre disponemos.
Cuando se hayan purgado todos esos mensajes, las bases de datos tendrán más espacio libre que se usará para crecer sin aumentar el propio tamaño físico de la base de datos (es decir, los cache.dat).
Si os encontrárais con bases de datos grandes en disco y medio vacías que queráis disminuir el tamaño, tendréis que usar una utilidad llamada GBLOCKCOPY (o esperar a ver si se confirma que en la 2013.2 finalmente dispondremos de una utilidad que lo hará en caliente y desde el propio portal).
Publicar un comentario