Programación para mejorar la simultaneidad

Puede diseñar programas de aplicación para proteger la integridad de los datos a los que se accede sin impedir que otros procesos accedan a los mismos datos durante largos periodos de tiempo.

Para diseñar las aplicaciones para la simultaneidad:

• Programe aplicaciones para acceder a datos en el mismo orden.
  Cuando dos aplicaciones acceden a las mismas filas de la tabla en el mismo orden, es posible que una aplicación tenga que esperar a la otra, pero no pueden entrar en punto muerto. Por lo tanto, la recomendación es probar a programar diferentes aplicaciones para acceder a las filas y a las tablas en el mismo orden.
• Confirme el trabajo tan pronto como resulte práctico para evitar contenciones de bloqueo innecesarias, incluso en aplicaciones de solo lectura.

  Tomar puntos de confirmación con frecuencia en una unidad de recuperación (UR) de larga ejecución tiene las siguientes ventajas, con el posible coste de un mayor uso de CPU y de más E/S de escritura de registro:

  • Reduce la contención de bloqueo, especialmente en un entorno de uso compartido de datos.
  • Mejora la eficacia del método para evitar bloqueos, especialmente en un entorno de uso compartido de datos.
  • Reduce el tiempo transcurrido para reiniciar el sistema de Db2 , tras un fallo del sistema
  • Reduce el tiempo transcurrido para la retrotracción de una unidad de recuperación tras un anomalía de una aplicación o una solicitud de retrotracción explícita por parte de la aplicación.
  • Proporciona más oportunidades para que intervengan programas de utilidad, como REORG en línea.

  Piense en utilizar el parámetro de subsistema URCHKTH o el parámetro de subsistema URLGWTH para identificar aplicaciones que no se confirman frecuentemente. URCHKTH identifica cuándo se han producido demasiados puntos de comprobación sin que ninguna UR emitiera una confirmación. Resulta útil supervisar la actividad general del sistema. URLGWTH permite detectar las aplicaciones que escriban demasiados registros entre puntos de confirmación, lo que podría crear una situación en la que la recuperación fuera muy larga en caso de tablas críticas.

  Aunque una aplicación pueda cumplir con los estándares de frecuencia de confirmación de la instalación bajo condiciones operativas normales, pueden producirse variaciones en función de las fluctuaciones de la carga de trabajo del sistema. Por ejemplo, una aplicación de prioridad baja puede emitir una confirmación con frecuencia en un sistema que esté poco cargado. Sin embargo, en caso de que la carga del sistema sea grande, puede preferirse que sea la aplicación la que use la CPU y, como resultado, la aplicación podría infringir la regla establecida por el parámetro de subsistema URCHKTH. Por este motivo, añada lógica a la aplicación para confirmar en función del tiempo transcurrido desde la última confirmación, y no solamente en función de la cantidad de proceso SQL realizado. Además, tome puntos de confirmación frecuentes en una unidad de trabajo de ejecución larga que sea de sólo lectura a fin de reducir la contienda de bloqueo y de proporcionar oportunidades a los programas de utilidad, como REORG en línea, para que accedan a los datos.

  La confirmación frecuente es igualmente importante en objetos que no se registren como en objetos que se registren. Asegúrese, por ejemplo, de confirmar el trabajo con frecuencia incluso si el trabajo se realiza en un espacio de tablas definido con la opción NOT LOGGED. Incluso cuando una determinada transacción modifica únicamente las tablas que residen en espacios de tablas no registrados, se establece una unidad de recuperación antes de que se realicen actualizaciones. El proceso de deshacer continuará leyendo el registro hacia atrás en busca de registros de deshacer que se deban aplicar hasta que detecte el principio de esta unidad de recuperación, tal y como se registrara en el registro. Por lo tanto, estas transacciones deben realizar confirmaciones frecuentes para limitar la distancia que el proceso de deshacer debe retroceder en el registro para encontrar el principio de la unidad de recuperación.

• Incluya lógica en el programa de aplicación para reintentar, tras un punto muerto o un tiempo de espera excedido, la recuperación desde la situación de contienda sin ayuda.
  Este método puede ayudarle a recuperase de una situación sin la ayuda del personal de operaciones. Puede utilizar los métodos siguientes para determinar si se excede un tiempo de espera o se produce un punto muerto:

  • El campo SQLERRD(3) en SQLCA
  • Una sentencia GET DIAGNOSTICS
• Enlazar la mayoría de las aplicaciones con las opciones ISOLATION(CS) y CURRENTDATA(NO).
  Estas opciones permiten a Db2 liberar los bloqueos antes de tiempo y evitarlos en muchos casos.
  ISOLATION(CS) normalmente permite que Db2 libere los bloqueos adquiridos lo antes posible. CURRENTDATA(NO) normalmente permite que Db2 adquiera el menor número de bloqueos, para evitarlos mejor.
  Si se utiliza ISOLATION(CS) y CURRENTDATA(NO), piense en utilizar el valor YES del parámetro del subsistema SKIPUNCI para que los lectores no tengan que esperar el resultado de las inserciones no confirmadas.
• Si no utiliza ISOLATION(CS) y CURRENTDATA(NO), utilice las siguientes opciones de enlace, en orden de preferencia descendente:
  1. ISOLATION(CS) con CURRENTDATA(YES), cuando los datos devueltos a la aplicación no se deban cambiar antes de la siguiente operación FETCH.
  2. ISOLATION(RS), cuando los datos devueltos a la aplicación no se deban cambiar antes de que la aplicación confirme o retrotraiga. Sin embargo, no le preocupa si otros procesos de aplicación insertan filas adicionales.
  3. ISOLATION(RR), si los datos evaluados como resultado de una consulta no deben cambiarse antes de que la aplicación confirme o retrotraiga. No se pueden insertar filas nuevas en el conjunto de respuestas.
• Tenga cuidado a la hora de utilizar la opción ISOLATION(UR).
  La instalación anexa de servicios de recuperación de recursos UR isolation no adquiere casi ningún bloqueo en filas o páginas. Es rápido y ocasiona muy poca contienda, pero lee datos no confirmados. No lo utilice a no ser que esté seguro de que las aplicaciones y usuarios finales pueden aceptar las incoherencias lógicas que pueden producirse.

  Como alternativa, piense en utilizar la cláusula SKIP LOCKED DATA si en la aplicación es preferible omitir datos a leer datos no confirmados.

• Utilice objetos de secuencia para generar números secuenciales exclusivos.
  El uso de una columna de identidad es una manera de generar números secuenciales exclusivos.

  Sin embargo, al ser una columna de una tabla, una columna de identidad está asociada a la tabla y enlazada a ella, y una tabla solo puede tener una columna de identidad. Es posible que las aplicaciones tengan que utilizar una sola secuencia de números exclusivos para muchas tablas, o varias secuencias para cada tabla. Como objeto definido por el usuario, las secuencias proporcionan una forma para que las aplicaciones tengan un Db2 o que genere valores de clave numéricos únicos y coordinar las claves a través de múltiples filas y tablas.

  El uso de secuencias puede evitar problemas de contención de bloqueo que pueden producirse cuando las aplicaciones implementan sus propias secuencias, como en el caso de una tabla de una sola fila que contenga un número de secuencia que cada transacción debe incrementar. Con las secuencias de tipo " Db2 ", muchos usuarios pueden acceder a la secuencia e incrementarla simultáneamente sin esperar. Db2 no espera a que una transacción que haya incrementado una secuencia se confirme antes de permitir que otra transacción incremente la secuencia de nuevo.

• Examine las operaciones de varias filas, como inserciones de varias filas, actualizaciones posicionadas y supresiones posicionadas, que tienen el potencial de expandir la unidad de trabajo.
  Esta situación puede afectar a la simultaneidad de otros usuarios que acceden a los datos. Puede minimizar la contienda si ajusta el tamaño de la matriz de variables de host, confirman entre inserciones y actualizaciones y evita el escalamiento de bloqueo.
• Utilizar transacciones globales, lo que permite a Db2 y otros gestores de transacciones participar en una sola transacción y, por lo tanto, compartir los mismos bloqueos y acceder a los mismos datos.
  La instalación anexa de Servicios de Recuperación de Recursos (RRSAF) se basa en un z/OS® componente denominado Servicios de Recuperación de Recursos (RRS). RRS proporciona servicios a todo el sistema para coordinar las operaciones de confirmación en dos fases a través de z/OS productos. Para las aplicaciones RRSAF y las transacciones IMS que se ejecutan bajo RRS, puede agrupar varios agentes Db2 en una única transacción global.

  Una transacción global permite que varios agentes de Db2 participen en una sola transacción global y, por lo tanto, compartan los mismos bloqueos y accedan a los mismos datos. Cuando dos agentes que están en una transacción global acceden al mismo objeto de la clase " Db2 " dentro de una unidad de trabajo, esos agentes no se bloquean ni se agotan el tiempo de espera entre sí. Se aplican las siguientes restricciones:

  • Parallel Sysplex® no es compatible con transacciones globales.
  • Puesto que cada una de las "ramas" de una transacción global comparte bloqueos, las actualizaciones sin confirmar emitidas por una rama de la transacción resultan visibles para las otras ramas de la transacción.
  • El proceso de reclamación/drenaje no está soportado entre las ramas de una transacción global, lo que significa que cualquier intento por emitir CREATE, DROP, ALTER, GRANT o REVOKE puede producir un punto muerto o que se exceda un tiempo de espera si se solicitan desde distintas ramas de la misma transacción global.
  • LOCK TABLE puede producir un punto muerto o que se supere un tiempo de espera entre las ramas de una transacción global.
• Utilice un control de simultaneidad optimista.
  Un control de simultaneidad optimista representa una alternativa de bloqueo más rápida y escalable que el bloqueo de base de datos para el acceso simultáneo a los datos. Minimiza el tiempo durante el que un determinado recurso no está disponible para otras transacciones.

  Si una aplicación utiliza un control de simultaneidad optimista, se obtienen bloqueos inmediatamente antes de una operación de lectura y se liberan inmediatamente. Los bloqueos de actualización se obtienen inmediatamente antes de una operación de actualización y se retienen hasta el final de la transacción. El control de simultaneidad optimista utiliza el RID y una señal de cambio de fila para probar si otra transacción ha modificado los datos desde la última operación de lectura.

  Db2 , que puede determinar cuándo se ha modificado una fila, puede garantizar la integridad de los datos y limitar al mismo tiempo el tiempo que se mantienen los bloqueos. Con un control de concurrencia optimista, Db2 libera los bloqueos de fila o página inmediatamente después de una operación de lectura. Db2 también libera el bloqueo de fila después de cada FETCH, tomando un nuevo bloqueo en una fila solo para una actualización o eliminación posicionada para garantizar la integridad de los datos.

  Para implementar un control de simultaneidad optimista, es necesario establecer una columna de indicación de fecha y hora de cambio de fila con una sentencia CREATE TABLE o una sentencia ALTER TABLE. La columna debe definirse con una de las siguientes características nulas:

  • NOT NULL GENERATED ALWAYS FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP
  • NOT NULL GENERATED BY DEFAULT FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP

  Después de que establezca una columna de marca de tiempo de cambio de fila, Db2 mantiene el contenido de esta columna. Cuando se desee utilizar esta señal de cambio como una condición al realizar una actualización, es posible especificar un predicado adecuado para esta columna en una cláusula WHERE.