Cómo Db2 asigna hebras

1. Creación de hebras

La lista siguiente muestra los pasos principales de la creación de hebras.

1. Db2 comprueba si se ha excedido el número máximo de hebras activas. Los umbrales se especifican mediante los siguientes parámetros de subsistema:
   • CTHREAD para hebras aliadas. Ver campo MAX USERS (parámetro del subsistema CTHREAD ).
   • MAXDBAT para hebras de acceso a base de datos. Véase el campo MAX REMOTE ACTIVE (parámetro del subsistema MAXDBAT ).

   Si se ha excedido el límite aplicable, la solicitud espera. La espera de hilos no se rastrea, pero el número de solicitudes en cola se proporciona en el registro de seguimiento del rendimiento con IFCID 73.

2. Db2 comprueba el ID de autorización de un plan de aplicación en la tabla del catálogo de la IFCID ( SYSIBM.SYSPLANAUTH ) (IFCID 15). Si esta comprobación no se pasa satisfactoriamente, se comprueba si la tabla SYSUSERAUTH tiene el privilegio especial SYSADM.

3. Para los planes de aplicación, Db2 carga las estructuras de control asociadas al plan. El bloque de control de un plan de aplicación está dividido en secciones. La cabecera y el directorio contienen información de control; la sección de SQL contiene sentencias SQL de la aplicación. Se realiza una copia de la estructura de control del plan para cada hebra que ejecuta el plan. Solamente se cargan la cabecera y el directorio cuando se crea la hebra.
4. Db2 carga los descriptores necesarios para procesar el plan. Algunas de las estructuras de control describen los espacios de tabla, las tablas y los índices de Db2 utilizados por la aplicación.

2. Asignación de recursos

Algunas de las estructuras necesarias para procesar la sentencia se almacenan en páginas de 4 KB. Si las estructuras no están ya presentes, estas se leen en la agrupación de almacenamiento intermedio de base de datos BP0 y se copian desde allí a la agrupación EDM.

Para cargar las estructuras de control necesarias para procesar la sección de SQL, Db2 utiliza el proceso siguiente:

1. Si todavía no está en la agrupación EDM, Db2 carga la sección de la estructura de control que corresponde a la sentencia de SQL.
2. Db2 carga estructuras a las que se hace referencia en la sentencia de SQL que aún no están en la agrupación EDM.
3. Asigne y abra conjuntos de datos. Cuando se carga la estructura de control, Db2 bloquea los recursos utilizados.

3. Ejecución de sentencias SQL

Si la sentencia reside en un paquete, el directorio y la cabecera de la estructura de control para el paquete se cargan en el momento de la primera ejecución de la sentencia en el paquete.

La estructura de control del paquete se asigna durante la ejecución de la sentencia. La cabecera de la estructura de control correspondiente al plan se asigna en el momento de la creación de la hebra.

Cuando se asigna el paquete, Db2 utiliza la caché de autorización de paquetes o la tabla de catálogo SYSPACKAUTH comprueba la autorización. Db2 verifica que el titular del plan tenga autoridad para ejecutar el paquete. Durante la primera ejecución, la información no está en la memoria caché; por tanto, se utiliza el catálogo. Después de la primera ejecución, se utiliza la memoria caché.

Para la vinculación dinámica, la comprobación de la autorización también se realiza durante la ejecución de las sentencias.

Un registro resumido, elaborado al final de la declaración (IFCID 58), contiene información sobre cada escaneo que se realiza.

Desde la perspectiva del rendimiento del sistema, el factor más importante en el rendimiento de la ejecución de las sentencias de SQL es el tamaño de la agrupación de almacenamiento intermedio de la base de datos. Si la agrupación de almacenamiento intermedio es lo suficientemente grande, algunas páginas de índice y páginas de datos pueden permanecer en ella y se puede acceder de nuevo a las páginas sin una operación adicional de E/S.

4. Confirmación y terminación de hebra

El proceso de confirmación puede producirse varias veces mientras haya una hebra activa. Por ejemplo, un programa de aplicación que se ejecute bajo la estructura de control de la hebra puede emitir una sentencia COMMIT o SYNCPOINT explícita varias veces durante su ejecución. Cuando el programa de aplicación o la hebra terminan, se emite una sentencia COMMIT o SYNCPOINT implícita.

Cuando se emite un COMMIT o SYNCPOINT desde una aplicación de IMS que se ejecuta con Db2, el proceso de confirmación en dos fases comienza si se han modificado los recursos de Db2 desde el último punto de confirmación. En una aplicación CICS® o RRSAF, el proceso de confirmación en dos fases comienza solo si los recursos de Db2 han cambiado y un recurso fuera de Db2 ha cambiado dentro del mismo ámbito de confirmación.

Los sucesos significativos que se muestran en un rastreo de rendimiento de una operación de terminación de confirmación y hebra se producen en la siguiente secuencia:

1. En la fase de compromiso 1 (IFCID 84), Db2 escribe un registro de fin de fase 1 en el registro (IFCIDs 0032 y 0033). El rastreo muestra dos operaciones de E/S, una para cada conjunto de datos de registro activo (IFCID 0038 y 0039).
2. En la fase de compromiso 2 (IFCID 70), Db2 escribe un registro de inicio de la fase 2 en el registro. De nuevo, el rastreo muestra dos operaciones de E/S. Los bloqueos de página y de fila retenidos en un punto de confirmación se liberan. Un desbloqueo (IFCID 21) con un token solicitado de ceros libera cualquier bloqueo durante el tiempo especificado. Se genera un registro de bloqueo resumido (IFCID 20), que indica el número máximo de bloqueos de página mantenidos y el número de escalaciones de bloqueo. Db2 escribe un registro de fin de fase 2 en el registro.
   Si se utiliza RELEASE(COMMIT), también se producen los siguientes sucesos:

   • Los bloqueos de espacio de tabla se liberan.
   • Se libera todo el almacenamiento utilizado por la hebra, incluido el almacenamiento de tablas de cursor esqueleto (SKCT), tablas de paquete esqueleto (SKPT) y áreas de trabajo.
   • Los recuentos de uso de DBD se reducen en uno. Si se necesita espacio en la memoria caché de DBD de EDM, se puede liberar un DBD cuando su recuento de uso llegue a cero.
   • Los espacios de tabla y los espacios de índice que no tengan reclamantes se convierten en candidatos para un cierre diferido.
3. La hebra se termina y se graba el registro de contabilidad. El registro de contabilidad no notifica la actividad de transacción que tiene lugar antes de que se cree la hebra.

   Si se utiliza RELEASE(DEALLOCATE) para liberar bloqueos de espacio de tabla, el recuento de uso de DBD se reduce y el almacenamiento de la hebra se libera.