Detalles de la réplica de objetos de base de datos

Comportamiento de la E/S de base de datos con Db2 Mirror

Cuando cambia el contenido de un archivo de base de datos replicado, independientemente de la interfaz utilizada, los cambios de datos se replican de forma síncrona en el nodo de destino. Cuando el estado de réplica es ACTIVE, los cambios de datos se pueden iniciar desde el nodo primario o el secundario. En el nodo secundario, cuando el estado de réplica es BLOCKED, cualquier intento de cambiar objetos replicados fallará.

Cuando se utiliza el registro por diario, las entradas de diario de datos pueden no ser idénticas en los dos nodos. Cuando los cambios de datos replicados están gestionados por Db2 Mirror, la implementación de réplica de los datos puede utilizar operaciones diferentes en cada nodo para llegar a la misma conclusión. Independientemente de las operaciones utilizadas, las filas activas son idénticas y residen en números de registro relativos (RRN) idénticos.

Cuando la réplica se suspende por cualquier motivo, los cambios de datos pueden continuar realizándose en el nodo primario, y se realiza un seguimiento de dichos cambios dentro del objeto de archivo en el nivel de fila. Cuando se reanuda la réplica, el proceso de resincronización de Db2 Mirror bloquea los objetos y filas monitorizados, y continúa sincronizando los cambios de datos en el nodo secundario. Cuando se completa la resincronización, los archivos vuelven a estar sincronizados.

Cuando se suspende la réplica, el comportamiento de las transacciones interrumpidas está bien definido si se utiliza el control de compromiso. Bajo el control de compromiso, la transacción en el nodo primario continuará sin que la aplicación o usuario noten ningún cambio. Sin embargo, en el nodo secundario, una transacción interrumpida al suspender la réplica da como resultado la retrotracción de la transacción. Si el usuario o la aplicación no está utilizando el control de compromiso (COMMIT *NONE), los cambios en la base de datos se realizan sin la posibilidad de retrotracción. Esto significa que, si no se utiliza el control de compromiso, no está garantizado que los cambios de datos lleguen a un punto previsible cuando se suspende la réplica. Todos los cambios realizados hasta el momento en que se ha producido la suspensión existirán en ambos nodos.

La gestión de la réplica de bases de datos incluye funciones para el movimiento de datos. Esta optimización de la réplica podría dar lugar a una diferencia en el número de registros suprimidos que residen al final del archivo. Una diferencia en el número de registros suprimidos al final del archivo es normal y no es indicativa de desincronización.

Utilizar objetos de secuencia

Las secuencias incluyen un valor CACHE opcional, que mejora el rendimiento de la expresión de secuencia NEXT VALUE mediante la preasignación de valores en la memoria. Con Db2 Mirror, la réplica síncrona de una secuencia se produce cuando se agotan los valores almacenados en memoria caché y el objeto *DTAARA correspondiente se actualiza para reflejar la asignación de un nuevo conjunto de valores almacenados en memoria caché.

Consideración acerca del control de compromiso

Si se utilizan la sentencia SQL RENAME, el mandato CL Renombrar objeto (RNMOBJ) o la sentencia SQL ALTER TABLE para cambiar el estado de réplica del objeto de destino de exclusión a inclusión, toda la operación debe utilizar COMMIT(*NONE).

Es necesario que cualquier operación de réplica de DDL que utilice COMMIT (*NONE) se inicie en un límite de compromiso. Si no se encuentra en un límite de compromiso, la operación fallará con SQL7061.