Docker 20.10.14 (lanzado el 23 de marzo de 2022) cambia las funcionalidades que Linux da a los contenedores de una manera que es incompatible con el Linux capability checkeren los contenedores de InterSystems IRIS 2021.1 (y posteriores). 

Los usuarios ejecutando Docker 20.10.14 en Linux encontrarán que los contenedores de IRIS 2021.1+ fallarán al iniciarse y los logs reportarán de forma incorrecta que las funcionalidades requeridas de Linux no se encuentran. Por ejemplo:

[ERROR] Required Linux capability cap_setuid is missing.[ERROR] Required Linux capability cap_dac_override is missing.

De vez en cuando, recibimos la pregunta anterior en soporte, algo o alguien está usando más licencias de las esperadas y necesitamos encontrar qué está pasando.

Tenemos dos escenarios. El primer escenario es cuando nos damos cuenta que las licencias están agotadas porque la aplicación no funciona o porque intentamos conectarnos a través del terminal y sale el "encantador" mensaje <LICENSE LIMIT EXCEEDED>: 

El segundo escenario es cuando el usuario final se queja de que no pudo conectarse en algún momento y no nos dió tiempo a conectarnos y ver el problema cuando estaba sucediendo.

Soporte te está ayudando a resolver una incidencia con un informe y necesitan reproducir el problema en su sistema local. ¡Es una pena que no puedan ejecutar el informe porque la conexión JDBC al origen de datos fallará! O... ¿hay alguna forma?

Hay una forma de ejecutar un informe offline sin acceso a la base de datos origen. Debes proporcionar los resultados de una query cacheada exportada desde Designer. Es un fichero que contiene los datos de la query. Soporte lo usará para evitar el origen de datos del informe. Cuando ejecuten el informe, cogerá los datos del fichero, no de la conexión JDBC. 

15 de marzo de 2022

InterSystems ha corregido un defecto que provoca la compilación incorrecta de rutinas de ObjectScript.

Este defecto solo ocurre en la versión 2021.1.1, recientemente liberada, de:

            InterSystems IRIS Data Platform

            InterSystems IRIS for Health

            HealthShare Health Connect

Trabajando en soporte generalmente me preguntan cuántos días hay que mantener los journals. ¿Debería ser dos días o después de dos copias de seguridad? ¿Más? ¿Menos? ¿Por qué dos?

La respuesta correcta (para la mayoría de los entornos) es que se debería conservar los ficheros de journal desde la última copia de seguridad validada. Es decir, hasta que no verifique si una copia de seguridad es válida (restaurando el archivo y verificándolo con la utilidad Integrity), no puede estar seguro de que haya una buena copia de los datos y no por tanto no se deberían purgar los journals de manera segura.

Hola a todos.

Me encontré con algunos problemas cuando configuré los scripts por lotes de freeze/thaw para usarlos con VMWare en un ecosistema de Windows, y quería compartir lo que encontré por si pudiera ayudar a otros. Esto se llevó a cabo en un entorno que utiliza HealthConnect 2019.1.x.

IRIS no se ejecutó (2)

Parece que el script de ejemplo de la documentación, en mi caso, me indicaba que el entorno no se estaba ejecutando (a pesar de que se estaba ejecutando). Para corregir esto, proporcioné la ruta de acceso a la ubicación de Mgr, de la siguiente forma:

c:\InterSystems\HealthConnect\bin\iris

Siguiendo la serie de artículos de mi compañero Murray vamos a centrarnos en el artículo donde analizamos la CPU.

Un cliente me pidió que le aconsejara sobre el siguiente escenario: sus servidores de producción se están acercando al final de su vida útil y es el momento de actualizar el hardware. También están pensando en consolidar los servidores por medio de la virtualización y quieren ajustar la capacidad, ya sea con servidores de hardware dedicado o virtualizados.

Hoy analizaremos la CPU. En artículos posteriores explicaré el enfoque para dimensionar correctamente otros "grupos alimenticios de hardware": la memoria y las Entradas/Salidas.

Aunque la integridad de las bases de datos Caché e InterSystems IRIS está completamente protegida de las consecuencias de un fallo de sistema, los dispositivos de almacenamiento físico sí que pueden fallar, corrompiendo los datos que almacenan.

Por esa razón, muchos sitios optan por realizar chequeos o verificaciones periódicas de integridad de bases de datos, sobre todo en coordinación con las copias de seguridad, para validar que se pueda confiar en una determinada copia de seguridad en caso de que ocurra algún desastre.

Esta publicación es la traducción de un artículo que publicó mi compañero Murray hace un tiempo. Durante mi trabajo en soporte la he recomendado muchas veces, pues lo que aquí se explica es bastante común y los ejemplos que se dan pueden ayudar a muchos de vosotros.

En esta publicación muestro estrategias para realizar copias de seguridad de Caché utilizando un Backup externo, con ejemplos de integración con soluciones basadas en snapshots. La mayoría de soluciones que veo hoy en día se implementan en Linux con VMware, por lo que gran parte de este artículo muestra, como ejemplos, cómo las

¡Hola Comunidad! 

Voy a empezar a traducir los artículos de mi compañero Murray sobre rendimiento, pues son muy interesantes y merece la pena echarles un vistazo. Aprovecho para comentar que si tenéis preguntas y /o problemas de rendimiento os animéis a escribir y entre todos trataremos de ayudaros. Empecemos...

Tu aplicación está implementada y todo funciona bien. ¡Genial, enhorabuena! Pero, de repente, el teléfono empieza a sonar sin parar: son usuarios que se quejan de que la aplicación a veces se vuelve "lenta". Pero... ¿qué quiere decir eso? ¿A veces? ¿De qué herramientas dispones y a qué estadísticas deberías prestar atención para encontrar y resolver la lentitud? ¿La infraestructura de tu sistema está a la altura de la carga de usuarios? ¿Qué preguntas de diseño de infraestructura deberías haber hecho antes de haber pasado a producción? ¿Cómo puedes hacer la planificación de capacidad para nuevo hardware con confianza y sin gastar en más hardware del necesario? ¿Cómo hacer que el teléfono deje de sonar? ¿Cómo podrías haber evitado que sonara desde un principio?

¡Hola Comunidad!

En publicaciones anteriores, mi compañero Murray mostró cómo se pueden recopilar métricas históricas de rendimiento utilizando los pButtons. Hablamos primero de los pButtons porque se instalan con cada instancia de las plataformas de datos (Ensemble, Caché, …). Sin embargo, existen otras formas para recopilar, procesar y desplegar las métricas de rendimiento de Caché, en tiempo real, ya sea con la finalidad de realizar una supervisión sencilla o, lo más importante, para llevar a cabo operaciones analíticas mucho más sofisticadas y obtener la capacidad de planificación. Uno de los métodos utilizados más comunes para recopilar datos es el SNMP (Protocolo simple de administración de la red).

Si quieres probar mirroring de una manera simple y sencilla puedes hacerlo con estos simples scripts (ver link)

• El fichero docker-compose.yml crea 2 contenedores con la versión que necesites
• El script installer.sh arranca el  ISCAgent, carga la clase Installer.cls y la llama
• Lo más interesante está en la clase Installer.cls. Esta clase contiene unos métodos muy sencillos de seguir para montar un mirror, unirse  y crear un namespace y base de datos en mirror.  Son scripts sencillos que puedes reutilizar para crear mirrors en tus propios scripts

¡Hola a todos!

En esta publicación me gustaría hablar sobre la tabla syslog: qué es, cómo analizarla, cuáles son realmente las entradas y por qué puede ser importante para usted. La tabla syslog puede contener información de diagnóstico importante. Si su sistema tiene algún problema, es importante entender cómo analizar esta tabla y qué información contiene.

¿Qué es una tabla syslog?