SQL DE LOTE
Válido para
Replicat
Descripción
Utilice el parámetro BATCHSQL para aumentar el rendimiento de Replicat. BATCHSQL hace que Replicat organice sentencias SQL similares en matrices y las aplique a un ritmo acelerado. En su modo normal, Replicat aplica una sentencia SQL a la vez.
BATCHSQL es válido para:
-
Db2 para i (excepto V5R4 o i 6.1)
-
Db2 LUW
-
Db2 en z/
OS -
Oracle
-
PostgreSQL
-
SQL Server
-
Sybase
-
Teradata
-
Diez veces
Cuándo se utiliza BATCHSQL
Antes de utilizar BATCHSQL, utilice Replicat paralelo y compruebe si eso alivia cualquier retraso de Replicat. Si no es así, intente activar BATCHSQL. Si la activación de BATCHSQL mejora el rendimiento, manténgalo activado de lo contrario, desactívelo y considere otros ejercicios de ajuste alternativos para el Replicat, como garantizar que todas las tablas tengan claves primarias o únicas, operaciones de lotes grandes limitadas y garantizar que el Replicat paralelo tenga mucha memoria y E/S para un rendimiento óptimo, lo que implica que el Replicat no esté enlazado a E/S ni a memoria.
Cuando Replicat está en modo BATCHSQL, los cambios de fila más pequeños mostrarán una mayor ganancia de rendimiento que los cambios de fila más grandes. Con un cambio de 100 bytes de datos por fila, se sabe que BATCHSQL mejora el rendimiento de Replicat hasta en un 300 %, pero los beneficios de rendimiento reales variarán según la combinación de operaciones. En torno a los 5.000 bytes de datos por fila cambian, las ventajas de utilizar BATCHSQL disminuyen.
Restricciones de uso
Entre las sentencias SQL tratadas como excepciones se incluyen:
-
Sentencias que contienen datos
LOBoLONG. -
Sentencias que contienen filas de más de 25k de longitud.
-
Sentencias en las que la tabla de destino tiene una o más claves únicas además de la clave primaria. Estas sentencias no se pueden procesar en lotes porque
BATCHSQLno garantiza el orden correcto para las claves no primarias si sus valores pueden cambiar. -
Sentencias (SQL Server) en las que la tabla destino tiene un disparador.
-
Sentencias que causan errores.
Cuando Replicat encuentra excepciones en el modo por lotes, realiza un rollback de la operación por lotes y, a continuación, intenta aplicar las excepciones de las siguientes formas, manteniendo siempre la integridad de la transacción:
-
First Replicat intenta utilizar el modo normal: una sentencia SQL a la vez dentro de los límites de transacción definidos con el parámetro
GROUPTRANSOPS. Consulte "GROUPTRANSOPS" para obtener más información. -
Si el modo normal falla, Replicat intenta utilizar el modo de origen: aplique el SQL dentro de los mismos límites de transacción que se utilizaron en el origen.
Cuando haya terminado de procesar las excepciones, Replicat reanuda el modo BATCHSQL.
Tabla 9 Modos de replicación
| Transacciones de origen (se asume la misma tabla y lista de columnas) | Replicar transacción en modo normal | Transacción de Replicat en modo BATCHSQL |
Replicación de transacciones en modo de origen |
|---|---|---|---|
Transacción 1: `INSERTAR` `SUPRIMIR` Transaction2: `INSERTAR` `SUPRIMIR` Transacción 3: `INSERTAR` `SUPRIMIR` |
`INSERTAR` `SUPRIMIR` `INSERTAR` `SUPRIMIR` `INSERTAR` `SUPRIMIR` |
"INSERTAR" (x3) `SUPRIMIR` (x3) |
Transacción 1: `INSERTAR` `SUPRIMIR` Transacción 2: `INSERTAR` `SUPRIMIR` Transacción 3: `INSERTAR` `SUPRIMIR` |
Funcionamiento de BATCHSQL
En el modo BATCHSQL, Replicat organiza sentencias SQL similares en lotes en una cola de memoria y, a continuación, aplica cada lote en una operación de base de datos. Un lote contiene sentencias SQL que afectan a la misma tabla, tipo de operación (insertar, actualizar o suprimir) y lista de columnas. Por ejemplo, cada uno de los siguientes es un lote:
-
Inserta en la tabla A
-
Inserciones en la tabla B
-
Actualizaciones de la tabla A
-
Actualizaciones de la tabla B
-
Supresiones de la tabla A
-
Supresiones de la tabla B Nota: Oracle GoldenGate analiza las dependencias referenciales de clave ajena en los lotes antes de ejecutarlos. Si existen dependencias entre sentencias que están en lotes diferentes, es posible que se necesite más de una sentencia SQL por lote para mantener la integridad referencial.
Control del número de sentencias en caché
El parámetro MAXSQLSTATEMENTS controla el número de sentencias que se almacenan en caché. Consulte "MAXSQLSTATEMENTS" para obtener más información. Las sentencias antiguas se reciclan mediante un algoritmo de uso menos reciente. Los lotes se ejecutan en función de un umbral especificado (consulte).
Valor por defecto
Desactivado (Proceso en modo Replicat normal)
Sintaxis
BATCHSQL
[CHECKUNIQUEKEYS | NOCHECKUNIQUEKEYS]
[THREADS (<threadID>[, <threadID>][, ...][, <thread_range> [,<thread_range>][, ...])]
[CHECKUNIQUEKEYS |
NOCHECKUNIQUEKEYS] |
Válido para Replicat.
CHECKUNIQUEKEYS fuerza un vaciado cuando se encuentra una tabla con una clave única que omite el procesamiento BATCHSQL. Esto garantiza que el orden original de las operaciones se mantenga si cambia la clave única.
El valor por defecto es NOCHECKUNIQUEKEYS y no fuerza un vaciado cuando se encuentra una tabla con claves únicas que permite que el procesamiento BATCHSQL continúe.
THREADS (<threadID>[, <threadID>][, ...][, <thread_range>[, <thread_range>][, ...])
Válido para BATCHESPERQUEUE, BATCHTRANSOPS y BYTESPERQUEUE. Aplica estas opciones al thread o threads especificados de un Replicat coordinado.
<threadID>[, <threadID>][, ...]
Especifica un thread ID o una lista delimitada por comas de threads con el formato threadID, threadID, threadID.
[, <thread_range>[, <thread_range>][, ...]
Especifica un rango de threads con el formato de threadIDlow-threadIDhigh o una lista de rangos delimitados por comas con el formato de threadIDlow-threadIDhigh, threadIDlow-threadIDhigh.
Se permiten una combinación de estos formatos, como threadID, threadID, threadIDlow-threadIDhigh.