Gracias David, el tema de los globals es algo complejo de asimilar cuando tienes a diferentes actores en la vida de un producto, en nuestro caso debemos poner de acuerdo a desarrolladores, gestores de base de datos y administradores de sistema, cada uno buscando la mejor eficiencia de su tiempo, pero que lamentablemente chocan entre ellos.

Por mi parte, ahora que estoy centrado en la administración de sistemas creo que estaría bien un artículo sobre las implicaciones a nivel de almacenamiento de los cambios de desarrollo, me explico, en ocasiones algunos servicios reciben actualizaciones, creando nuevas clases, dejando de utilizar otras, cambiando propiedades de otras... esto se realiza mediante la subida de nuevas producciones. Tengo la impresión de que aquellas clases que ya no se usan en la nueva producción, almacenarán datos en caché ad eternum, ¿es correcto?.

Del mismo modo, la purga de datos en BBDD grandes se nos antoja lenta, está bien para una tarea noctura pero en ocasiones es necesario realizar una limpieza pues el espacio compromete la estabilidad del sistema. En este caso he buscado y no encuentro información sobre las implicaciones de borrar directamente algunos globals "innecesarios" desde el Portal de Gestión, hablo principalmente de ^Ens_Util.Log , algunos de traza creados por usuarios y otros con datos temporales. ¿es seguro eliminarlos directamente?¿afecta su eliminación a los journals?. Nos ocurre que en ocasiones estos globals que no aportan información consumen varias decenas de gigas en algún día de errores y una vez solventado el error sería necesario eliminarlos.  En la actualidad estamos lanzando instrucciones sql para borrar días concretos.

Por tanto, ampliando tu artículo creo que estaría bien:

* Globals: cuándo, cómo eliminarlos y cómo se recrean.

* Globals y su impacto en sistemas en Mirror.

*Globals : ¿es posible almacenarlo en otra base de datos diferente?.