T4.3: Ensures Data Integrity

Knowledge Review - InterSystems IRIS Development Professional

1. Comprende comportamiento de journaling dentro de transacciones

Puntos Clave

  • Journaling automático: Todas las actualizaciones de globales dentro de transacciones se journalizan independientemente del estado de journal de la base de datos
  • TSTART a TCOMMIT: Los límites de transacción definen el alcance journalizado
  • Transacciones anidadas: Cada TSTART incrementa $TLEVEL, creando contextos de journaling anidados
  • Garantía de commit: Los cambios solo se confirman cuando el TCOMMIT más externo establece $TLEVEL a 0
  • Capacidad de rollback: Las entradas de journal permiten rollback completo de la transacción al estado pre-TSTART

Notas Detalladas

Resumen

InterSystems IRIS automáticamente journaliza cualquier actualización de global que sea parte de una transacción, independientemente de la configuración de estado de journal del global para la base de datos en la que reside el global afectado. Esto asegura integridad transaccional completa y recuperabilidad incluso para bases de datos no journalizadas. Cuando una transacción comienza con TSTART, la variable especial $TLEVEL se incrementa para rastrear la profundidad de anidamiento. Todas las operaciones SET y KILL en globales dentro de la transacción se registran en el journal con marcadores de transacción.

El journal contiene tipos específicos de registros de transacción: BT (Begin Transaction) cuando $TLEVEL era cero, y BTL (Begin Transaction with Level) para transacciones anidadas. Durante una transacción, las entradas de journal se acumulan pero el commit real se difiere hasta que el TCOMMIT más externo decrementa $TLEVEL a 0. Este commit diferido permite que las transacciones anidadas sean individualmente rollback mientras se mantiene la consistencia transaccional general. El ciclo de escritura de journal asegura que las operaciones TCOMMIT soliciten un flush de datos de journal al disco, con el comportamiento de commit sincrónico configurable determinando si la operación espera la finalización de escritura a disco.

Dentro de transacciones, el journal proporciona tanto atomicidad como durabilidad. Si ocurre un fallo del sistema durante una transacción, InterSystems IRIS usa entradas de journal durante la recuperación de inicio para hacer rollback de cualquier transacción incompleta, asegurando que no permanezcan cambios parciales de transacción en la base de datos. El journal también registra marcadores de transacción que identifican límites de transacción, habilitando herramientas como %SYS.Journal.System.GetImageJournalInfo() para analizar historial de transacciones e identificar transacciones abiertas. Este journaling comprehensivo de operaciones transaccionales es fundamental para el cumplimiento ACID en InterSystems IRIS.

Referencias de Documentación

2. Comprende comportamiento de journaling fuera de transacciones

Puntos Clave

  • Estado de journal de base de datos: Journaling controlado por propiedad Global Journal State (Yes/No)
  • Comportamiento predeterminado: Todas las bases de datos creadas por usuario journalizadas por defecto
  • Bases de datos de sistema: IRISAUDIT, IRISSYS, USER journalizadas; IRISLIB, IRISTEMP no journalizadas
  • Excepción IRISTEMP: Operaciones a globales temporales nunca journalizadas
  • Actualizaciones no transaccionales: Journalizadas solo si el Global Journal State de la base de datos es Yes

Notas Detalladas

Resumen

Fuera de transacciones, el comportamiento de journaling está controlado por la propiedad Global Journal State a nivel de base de datos, que puede ser Yes o No. El estado de journaling es una propiedad de la base de datos, no de globales individuales. Por defecto, todas las bases de datos que crea están journalizadas. En instancias de InterSystems IRIS recién instaladas, las bases de datos IRISAUDIT, IRISSYS y USER están journalizadas por defecto, mientras que las bases de datos IRISLIB, IRISTEMP e IRISLOCALDATA no están journalizadas. Las operaciones a globales en IRISTEMP nunca se journalizan; debe mapear globales temporales a la base de datos IRISTEMP para evitar overhead de journal innecesario.

Cuando ocurre una actualización de global fuera de una transacción, InterSystems IRIS verifica el Global Journal State de la base de datos que contiene ese global. Si el estado es Yes, la operación SET o KILL se journaliza. Si el estado es No, la operación no se journaliza. Esto difiere fundamentalmente del comportamiento transaccional, donde las actualizaciones se journalizan independientemente del estado de journal de la base de datos. El ciclo de escritura de journal opera continuamente, con operaciones de sincronización de journal disparadas cada dos segundos cuando el sistema está inactivo, o más frecuentemente bajo carga activa.

El journaling no transaccional proporciona capacidad de recuperación de fallos pero no garantías de atomicidad. Si ocurre un fallo del sistema, la recuperación de journal al inicio reaplica todas las operaciones journalizadas desde el último pase del daemon de escritura, asegurando que las actualizaciones de globales confirmadas se preserven. Sin embargo, sin límites de transacción, no hay rollback automático de operaciones incompletas. Las operaciones en variables locales, globales privados de proceso, y variables especiales como $TEST nunca se journalizan, ya sea dentro o fuera de transacciones. Comprender esta distinción es crítico para diseñar aplicaciones robustas que balanceen requisitos de integridad de datos con optimización de rendimiento a través de journaling selectivo.

Referencias de Documentación

3. Minimiza volumen de journal e impacto en rendimiento

Puntos Clave

  • Compresión de archivos de journal: Habilitar configuración CompressFiles para minimizar espacio en disco (habilitado por defecto)
  • Dispositivos de almacenamiento separados: Colocar directorios de journal en drives físicos separados de bases de datos y WIJ
  • Primario y alterno: Configurar directorios de journal primario y alterno separados para resiliencia
  • Globales temporales: Mapear datos transitorios a IRISTEMP para evitar overhead de journaling
  • Journaling selectivo: Deshabilitar journaling para bases de datos que contienen solo datos transitorios o reconstruibles

Notas Detalladas

Resumen

Minimizar el volumen de journal y el impacto en rendimiento requiere planificación cuidadosa de la configuración de journal y el diseño de aplicación. La compresión de archivos de journal debe habilitarse usando la configuración CPF CompressFiles, que está habilitada por defecto para nuevas instalaciones de InterSystems IRIS. Esto reduce significativamente la cantidad de espacio en disco consumido por archivos de journal sin impactar la capacidad de recuperación. Para la arquitectura de almacenamiento, InterSystems recomienda colocar los directorios de journal primario y alterno en dispositivos de almacenamiento que estén separados de los dispositivos usados por bases de datos y el write image journal (WIJ). Aunque estos diferentes dispositivos pueden ser diferentes números de unidad lógica (LUNs) en la misma red de área de almacenamiento (SAN), la regla general es que cuanta más separación mejor, con conjuntos separados de drives físicos altamente recomendados.

Los beneficios principales de separar almacenamiento de base de datos/WIJ del almacenamiento de journal primario y alterno incluyen aislar directorios de journal de fallos que pueden comprometer las bases de datos, asegurar que el journaling pueda continuar cuando el directorio primario no esté disponible, y lograr concurrencia de I/O que la mayoría de aplicaciones requieren. La instalación predeterminada crea un solo directorio de journal como primario y alterno, pero esto debe reconfigurarse tan pronto como sea posible después de la instalación. Las decisiones de diseño de aplicación también impactan significativamente el volumen de journal: mapear globales temporales y datos de trabajo a la base de datos IRISTEMP, que nunca se journaliza, y considerar deshabilitar journaling para bases de datos que contienen solo datos transitorios o datos que pueden reconstruirse fácilmente desde otras fuentes.

Estrategias de optimización adicionales incluyen gestionar políticas de retención de archivos de journal apropiadamente - solo purgar archivos de journal que fueron cerrados antes del último backup bueno conocido. Establecer el número de días y número de backups exitosos después de los cuales mantener archivos de journal basado en sus objetivos de tiempo de recuperación y capacidad de almacenamiento. Considerar implementar archivado de journal para copiar archivos de journal a almacenamiento de archivo cuando alcancen tamaño máximo, opcionalmente purgando el original después de archivado exitoso. Monitorear rendimiento de I/O de journal a través de métricas del Management Portal y ajustar el tamaño del buffer de journal si es necesario. La configuración Freeze on error debe considerarse cuidadosamente: establecerla a Yes prioriza integridad de datos sobre disponibilidad al congelar el sistema si ambos dispositivos de journal primario y alterno fallan, mientras que No permite que el sistema continúe con journaling deshabilitado.

Referencias de Documentación

4. Gestiona transacciones efectivamente

Puntos Clave

  • Emparejamiento TSTART/TCOMMIT: Cada TSTART debe tener TCOMMIT o TROLLBACK coincidente
  • Monitoreo de $TLEVEL: Rastrear profundidad de anidamiento de transacción (0=sin transacción, max 255 niveles)
  • Soporte de transacciones anidadas: Usar TSTART dentro de transacciones para diseño de código modular
  • Manejo de errores: Siempre implementar TRY-CATCH con TROLLBACK en bloque CATCH
  • Retención de locks: Locks adquiridos en transacciones mantenidos hasta TCOMMIT/TROLLBACK más externo

Notas Detalladas

Resumen

La gestión efectiva de transacciones comienza con el emparejamiento apropiado de comandos TSTART y TCOMMIT. TSTART marca el comienzo de una transacción e incrementa $TLEVEL, mientras que TCOMMIT marca la finalización exitosa y decrementa $TLEVEL. La transacción solo se confirma cuando $TLEVEL retorna a 0, significando que el TCOMMIT más externo ha sido ejecutado. Llamar TCOMMIT cuando $TLEVEL ya es 0 resulta en un error COMMAND, así que siempre verifique el estado de transacción antes de emitir comandos de control de transacción. InterSystems IRIS soporta transacciones anidadas hasta 255 niveles, permitiendo que módulos emitan sus propios pares TSTART/TCOMMIT independientemente del código llamador.

La gestión de transacciones requiere manejo comprehensivo de errores. Use bloques TRY-CATCH con TROLLBACK en la sección CATCH para asegurar que las transacciones se hagan rollback ante errores. TROLLBACK tiene dos formas: TROLLBACK 1 hace rollback solo del nivel de anidamiento actual y decrementa $TLEVEL en 1, mientras que TROLLBACK (sin argumento) hace rollback de todas las transacciones y restablece $TLEVEL a 0. Sea cauteloso con transacciones anidadas - si hace TROLLBACK 1 de una transacción interna y luego TCOMMIT de la transacción externa, el rollback interno se preserva. Conversamente, si hace TCOMMIT de una transacción interna pero TROLLBACK de la transacción externa, todos los cambios incluyendo la transacción interna "confirmada" se hacen rollback porque el commit real se difiere hasta que $TLEVEL alcanza 0.

La gestión de locks dentro de transacciones requiere atención especial. Por defecto, los locks emitidos dentro de una transacción se mantienen hasta el final de la transacción, incluso si se liberan explícitamente. Este comportamiento predeterminado puede anularse al establecer el lock. La suspensión de transacción usando %SYSTEM.Process.TransactionsSuspended() suspende el journaling de cambios, y TROLLBACK no puede hacer rollback de cambios hechos mientras las transacciones estaban suspendidas. Para optimización de rendimiento, considere usar commit sincrónico (%SYSTEM.Process.SynchCommit()) para controlar si TCOMMIT espera que los datos de journal se escriban a disco. El modo predeterminado es asincrónico (más rápido pero ligeramente menos durable), mientras que el modo sincrónico asegura durabilidad al costo de latencia de transacción. Monitoree la duración de transacción y evite transacciones de larga ejecución que mantienen locks y aumentan el overhead de rollback.

Referencias de Documentación

5. Comprende causas de rollback automático y prevención

Puntos Clave

  • Recuperación de fallo del sistema: Transacciones incompletas automáticamente rollback al inicio
  • Terminación de proceso: Detener o terminar procesos dispara rollback de transacción
  • Errores ROLLFAIL: Journal no disponible o corrupto durante rollback causa ROLLFAIL
  • Freeze on error: La configuración determina comportamiento del sistema cuando rollback falla
  • Operaciones no rollback: Variables locales, $INCREMENT, $SEQUENCE, operaciones LOCK, cambios de namespace

Notas Detalladas

Resumen

InterSystems IRIS automáticamente hace rollback de transacciones incompletas en varios escenarios. Durante la recuperación después de un fallo del sistema, que ocurre como parte del inicio de InterSystems IRIS, el sistema usa entradas de journal para hacer rollback de cualquier transacción que estaba en progreso al momento del fallo. Cuando detiene su proceso mientras las transacciones están en progreso, el sistema automáticamente hace rollback de esas transacciones. Si termina un proceso usando la opción Terminate desde la página Processes del Management Portal (System Operation > Processes), el sistema maneja el rollback diferentemente dependiendo de cómo fue iniciado el proceso: para procesos iniciados con el comando Job, las transacciones se hacen rollback automáticamente; para procesos de usuario, el sistema pregunta si confirmar o hacer rollback de transacciones incompletas.

Los errores ROLLFAIL ocurren cuando TROLLBACK no puede completar exitosamente la operación de rollback. Las causas comunes incluyen archivos de journal no disponibles, corruptos o eliminados; la base de datos siendo desmontada durante la transacción; o journaling siendo deshabilitado antes de que se hicieran cambios de base de datos. El comportamiento del sistema cuando ocurre un ROLLFAIL depende de la configuración de journal Freeze on error. Si Freeze on error no está establecido (el predeterminado), el proceso recibe un error ROLLFAIL, la transacción se cierra, y cualquier lock retenido para la transacción se libera - esto intercambia integridad de datos por disponibilidad del sistema. Si Freeze on error está establecido, el proceso se detiene y el daemon de trabajo de limpieza (CLNDMN) reintenta hacer rollback de la transacción, potencialmente causando que el sistema se cuelgue mientras los locks permanecen mantenidos - esto intercambia disponibilidad por integridad de datos.

La prevención de fallos de rollback requiere comprender qué no puede hacerse rollback. TROLLBACK no restaura cambios a variables locales, globales privados de proceso, variables especiales como $TEST, el namespace actual, u operaciones LOCK. Adicionalmente, las operaciones $INCREMENT y $SEQUENCE en globales no se hacen rollback - estas operaciones son atómicas pero no transaccionales. Para prevenir errores ROLLFAIL, asegure que el journaling permanezca habilitado durante las transacciones, evite desmontar bases de datos que contienen globales modificados en transacciones activas, mantenga espacio en disco adecuado para archivos de journal, y configure directorios de journal primario y alterno apropiados. Al diseñar aplicaciones, estructure las transacciones para que sean lo más cortas posible, implemente manejo apropiado de errores con TROLLBACK explícito en bloques CATCH, y valide que las operaciones críticas se completaron exitosamente antes de confirmar transacciones.

Referencias de Documentación

Resumen de Preparación para el Examen

Conceptos Críticos a Dominar:

  1. Journaling Transaccional vs No Transaccional: Comprender que las actualizaciones transaccionales siempre se journalizan independientemente del estado de journal de la base de datos, mientras que las actualizaciones no transaccionales honran la configuración Global Journal State de la base de datos
  2. Gestión de $TLEVEL: Saber que $TLEVEL=0 significa sin transacción, TSTART lo incrementa, y el commit real solo ocurre cuando TCOMMIT lo retorna a 0
  3. Comportamiento de Transacciones Anidadas: Comprender que el commit de transacción anidada se difiere hasta el TCOMMIT más externo, y hacer rollback de transacciones externas también hace rollback de transacciones internas "confirmadas"
  4. Optimización de Volumen de Journal: Reconocer estrategias incluyendo compresión, dispositivos de almacenamiento separados, IRISTEMP para datos temporales, y journaling selectivo de base de datos
  5. Escenarios de Rollback: Conocer las tres situaciones de rollback automático (recuperación de fallo, detención de proceso, terminación de proceso) y qué operaciones no pueden hacerse rollback

Escenarios Comunes de Examen:

  • Predecir valores de $TLEVEL después de secuencias de comandos TSTART, TCOMMIT y TROLLBACK
  • Identificar qué operaciones de base de datos se journalizarán en contextos transaccionales vs no transaccionales
  • Reconocer patrones apropiados de manejo de errores con TRY-CATCH y TROLLBACK
  • Determinar el estado final de globales y variables locales después de operaciones TROLLBACK
  • Seleccionar configuraciones apropiadas de journal para requisitos de rendimiento vs integridad
  • Comprender causas de error ROLLFAIL y comportamiento del sistema basado en configuración Freeze on error

Recomendaciones de Práctica Práctica:

  • Escribir código con transacciones anidadas y experimentar con diferentes combinaciones TCOMMIT/TROLLBACK
  • Crear bases de datos de prueba y alternar Global Journal State para observar diferencias de comportamiento de journaling
  • Implementar manejo de errores con fallos intencionales para disparar y observar rollback automático
  • Usar Management Portal para configurar ajustes de journal y monitorear creación/rollover de archivos de journal
  • Practicar con $INCREMENT y $SEQUENCE para comprender operaciones que no pueden hacerse rollback
  • Simular condiciones ROLLFAIL deshabilitando journaling a mitad de transacción
  • Examinar archivos de journal usando utilidad ^JOURNAL para comprender marcadores de transacción (BT, BTL)

Comandos y Variables Clave:

  • TSTART: Comenzar transacción, incrementar $TLEVEL
  • TCOMMIT: Confirmar transacción, decrementar $TLEVEL (commit real cuando $TLEVEL=0)
  • TROLLBACK: Hacer rollback de todas las transacciones, restablecer $TLEVEL a 0
  • TROLLBACK 1: Hacer rollback de un nivel de anidamiento, decrementar $TLEVEL en 1
  • $TLEVEL: Nivel de anidamiento de transacción (0=sin transacción, max=255)
  • %SYSTEM.Process.SynchCommit(): Configurar commit sincrónico vs asincrónico
  • %SYSTEM.Process.TransactionsSuspended(): Suspender/reanudar journaling de transacción

Referencia Rápida de Documentación:

  • Data Integrity Guide (GCDI): Secciones 5 (Journaling Overview) y 6 (Configuring Journaling)
  • ObjectScript Reference (RCOS): Referencia de comandos TSTART, TCOMMIT, TROLLBACK
  • Using ObjectScript (GCOS): Capítulo Transaction Processing
  • Management Portal: System Configuration > Journal Settings para opciones de configuración

Report an Issue