Las Profile Tables son herramientas muy poderosas en Db2 for z/OS que permiten a los administradores monitorizar, controlar y personalizar diversos aspectos del subsistema en contextos específicos de aplicación. Esta funcionalidad es especialmente valiosa para entornos con conectividad remota TCP/IP y aplicaciones que requieren un control granular sobre su comportamiento en la base de datos.
Esta entrada se basa en la documentación oficial de IBM Db2 for z/OS versión 13.0.0 y proporciona una guía comprensiva para administradores que buscan implementar u optimizar el uso de profile tables en sus subsistemas.
¿Qué son las Profile Tables?
Un profile es un conjunto de criterios que identifica un contexto específico dentro del subsistema Db2. Este contexto puede corresponder a threads, conexiones, sentencias SQL u otros procesos que comparten ciertos atributos comunes. El concepto fundamental es definir reglas de filtrado que determinen cuándo aplicar ciertos comportamientos o políticas a los procesos que cumplan esas condiciones.
Las profile tables funcionan con dos tablas principales:
- DSN_PROFILE_TABLE: Define los criterios de filtrado para cada profile.
- DSN_PROFILE_ATTRIBUTES: Especifica las acciones que el Db2 debe ejecutar cuando un proceso cumple los criterios de filtrado definidos.
Además de estas 2 tablas, existen otras 2 que se utilizan para guardar los registros históricos:
- DSN_PROFILE_HISTORY: Guarda el registro histórico de cambios que se han hecho en DSN_PROFILE_TABLE.
- DSN_PROFILE_ATTRIBUTES_HISTORY: Guarda el registro histórico de cambios que se han hecho en DSN_PROFILE_ATTRIBUTES.
Componentes del Conjunto de Profile Tables
Cuando instalas Db2 for z/OS mediante el job DSNTIJSG, se crean automáticamente varios objetos relacionados con profiles:
| Objeto | Propósito |
|---|---|
| SYSIBM.DSN_PROFILE_TABLE | Almacena los criterios de filtrado de los profiles |
| SYSIBM.DSN_PROFILE_HISTORY | Registro histórico de cambios en DSN_PROFILE_TABLE |
| SYSIBM.DSN_PROFILE_ATTRIBUTES | Define las acciones a ejecutar para cada profile |
| SYSIBM.DSN_PROFILE_ATTRIBUTES_HISTORY | Registro histórico de cambios en DSN_PROFILE_ATTRIBUTES |
| SYSIBM.DSN_PROFILE_TABLE_IX_ALL | Índice sobre DSN_PROFILE_TABLE |
| SYSIBM.DSN_PROFILE_TABLE_IX2_ALL | Índice secundario sobre DSN_PROFILE_TABLE |
| SYSIBM.DSN_PROFILE_ATTRIBUTES_IX_ALL | Índice sobre DSN_PROFILE_ATTRIBUTES |
Estructura de DSN_PROFILE_TABLE
Esta tabla define los criterios de filtrado para identificar contextos específicos. Cada fila representa un profile único.
| Columna | Tipo de dato | Descripción |
|---|---|---|
| AUTHID | VARCHAR(128) | ID de autorización del usuario monitorizado. Soporta wildcard * (ej: TEMP*). Solo un perfil default con * en AUTHID/ROLE. |
| PLANNAME | VARCHAR(24) | Nombre del plan. |
| COLLID | VARCHAR(128) | Collection ID del paquete. * wildcard permitido. Solo un perfil default con * en COLLID/PKGNAME. |
| PKGNAME | VARCHAR(128) | Nombre del paquete. * wildcard permitido. Solo un perfil default con * en COLLID/PKGNAME. |
| LOCATION | VARCHAR(254) | IP, FQDN o hostname TCP/IP (ej: stlmvs1.svl.example.com, ::FFFF:9.30.137.28). *, ::0, 0.0.0.0 para todos. No case-sensitive. |
| PROFILEID | INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY NOT NULL | Identificador único del profile |
| PROFILE_TIMESTAMP | TIMESTAMP NOT NULL WITH DEFAULT | Timestamp de inserción/actualización. |
| PROFILE_ENABLED | CHAR(1) NOT NULL WITH DEFAULT ‘Y’ | ‘Y’ = activo, ‘N’ = inactivo. |
| GROUP_MEMBER | VARCHAR(24) | Miembro data sharing group (vacío = todos los miembros). |
| REMARKS | VARCHAR(762) | Comentarios sobre el profile. |
| ROLE | VARCHAR(128) WITH DEFAULT NULL | Rol activo del usuario. * wildcard permitido. Solo un default con * en ROLE/AUTHID. |
| PRDID | CHAR(8) WITH DEFAULT NULL | Product ID requester remoto (formato pppvvrrm, ej: DSN13xx*). * wildcard. |
| CLIENT_APPLNAME | VARCHAR(255) | Nombre aplicación cliente (CURRENT CLIENT_APPLNAME). Case-sensitive. * wildcard. |
| CLIENT_USERID | VARCHAR(255) | User ID cliente (CURRENT CLIENT_USERID). Case-sensitive. Truncado a 128 bytes. * wildcard. |
| CLIENT_WRKSTNNAME | VARCHAR(255) | Workstation cliente (CURRENT CLIENT_WRKSTNNAME). Case-sensitive. * wildcard. |
Nota clave: Solo una categoría de filtrado por fila (resto NULL).
Estructura de DSN_PROFILE_ATTRIBUTES
| Columna | Tipo de dato | Descripción |
|---|---|---|
| PROFILEID | INTEGER | FK a DSN_PROFILE_TABLE. |
| KEYWORD | VARCHAR(64) | Acción: MONITOR THREADS, SPECIAL_REGISTER, GLOBAL_VARIABLE, etc. |
| ATTRIBUTE1 | VARCHAR(255) | Valor principal (EXCEPTION, YES, nombre registro). |
| ATTRIBUTE2 | VARCHAR(255) | Umbral/valor secundario (números, valores específicos). |
| ATTRIBUTE3 | VARCHAR(255) | Valor adicional (opcional). |
Estructura de los Criterios de Filtrado
Un aspecto crítico del diseño de profiles es entender las categorías de filtrado. Cada fila en DSN_PROFILE_TABLE debe especificar criterios de filtrado que pertenezcan a una sola categoría de filtrado válida.
Punto importante: Una fila válida de DSN_PROFILE_TABLE contendrá valores null en las columnas de filtrado que no pertenezcan a la categoría especificada. Esto asegura que los criterios sean claros y evita ambigüedades en la evaluación de profiles.
Limitaciones y Restricciones
Db2 for z/OS soporta un máximo de 4096 filas activas en DSN_PROFILE_TABLE. Este límite es importante considerarlo al diseñar tus estrategias de profiles, especialmente en entornos grandes con múltiples criterios de filtrado.
Flujo General a la hora de definir y activar Profiles
El proceso para crear y activar un profile sigue estos pasos:
- Insertar criterios de filtrado: Agregar filas a DSN_PROFILE_TABLE con un PROFILEID único y los criterios de filtrado apropiados
- Definir acciones: Insertar filas en DSN_PROFILE_ATTRIBUTES con el mismo PROFILEID, especificando el keyword (MONITOR, SPECIAL_REGISTER, GLOBAL_VARIABLE, etc.) y los valores de atributo correspondientes
- Cargar en memoria: Ejecutar el comando START PROFILE para cargar o recargar los profiles en memoria
- Verificar estado: Consultar las columnas STATUS en DSN_PROFILE_HISTORY y DSN_PROFILE_ATTRIBUTES_HISTORY para confirmar que los profiles se iniciaron correctamente
Nota importante: Es posible que no todos los profiles se activen con éxito después de ejecutar START PROFILE. Verifica siempre las tablas de historial para asegurar que el status comience con ‘ACCEPTED’.
Reglas de Precedencia para Profiles Múltiples
Cuando varios profiles tienen criterios de filtrado superpuestos, Db2 aplica un orden de precedencia específico:
- Db2 selecciona solo un profile por categoría de filtrado, basándose en reglas de precedencia definidas
- Los valores exactos tienen precedencia sobre valores que utilizan wildcard (*)
- Si múltiples filas de DSN_PROFILE_TABLE especifican criterios de filtrado idénticos, solo la fila más nueva es aceptada cuando se inician los profiles; las duplicadas son rechazadas
- Profiles de diferentes categorías de filtrado pueden aplicarse simultáneamente al mismo proceso
Casos de Uso y Características Principales
Las profile tables admiten múltiples escenarios de uso, cada uno con sus propias categorías de filtrado:
Monitorización de Conexiones Remotas TCP/IP
Puedes crear profiles para monitorizar conexiones TCP/IP desde ubicaciones específicas:
- Conexiones específicas: Filtra por dirección IP o nombre de dominio completamente cualificado (FQDN). Por ejemplo, puedes crear un profile para controlar todas las conexiones desde lpar1.example.com
- Todas las conexiones: Utiliza valores especiales como ‘*’, ‘::0’, o ‘0.0.0.0’ para aplicar el profile a todas las conexiones
- Los valores de ubicación no son sensibles a mayúsculas, permitiendo flexibilidad en la especificación de nombres de dominio
Ejemplo 1: Limitar conexiones desde una IP concreta
DSN_PROFILE_TABLE
| PROFILEID | LOCATION | PROFILE_ENABLED |
|---|---|---|
| 1001 | server1.example.com | Y |
DSN_PROFILE_ATTRIBUTES
| PROFILEID | KEYWORD | ATTRIBUTE1 | ATTRIBUTE2 | ATTRIBUTE3 |
|---|---|---|---|---|
| 1001 | MONITOR CONNECTIONS | EXCEPTION | 100 | NULL |
Explicación: Este profile limita a 100 conexiones simultáneas desde la IP server1.example.com. Si se supera este umbral, el Db2 genera excepciones y mensajes DSNT772I/DSNT773I.
Monitorización de Threads Remotos
Puedes aplicar políticas específicas a threads remotos, incluyendo:
- Monitorización de threads activos
- Detección y control de threads inactivos
- Aplicación de políticas globales a todos los threads remotos
Ejemplo 1: Límite de threads activos desde un servidor específico
DSN_PROFILE_TABLE
| PROFILEID | LOCATION | PROFILE_ENABLED |
|---|---|---|
| 2001 | server1.example.com | Y |
DSN_PROFILE_ATTRIBUTES
| PROFILEID | KEYWORD | ATTRIBUTE1 | ATTRIBUTE2 | ATTRIBUTE3 |
|---|---|---|---|---|
| 2001 | MONITOR THREADS | EXCEPTION | 50 | NULL |
Explicación: Controla threads activos desde un application server específico. Útil para evitar que un servidor mal configurado sature el subsistema.
Ejemplo 2: Límite de threads activos desde un servidor específico
DSN_PROFILE_TABLE
| PROFILEID | LOCATION | PROFILE_ENABLED | CLIENT_APPLNAME |
|---|---|---|---|
| 2002 | Y | App1 |
DSN_PROFILE_ATTRIBUTES
| PROFILEID | KEYWORD | ATTRIBUTE1 | ATTRIBUTE2 | ATTRIBUTE3 |
|---|---|---|---|---|
| 2002 | MONITOR THREADS | EXCEPTION | 0 | NULL |
Explicación: Controla threads activos desde una aplicación llamada App1. Cómo el Attribute2 está a 0, indica que esta aplicación no puede ejecutar ningún thread contra Db2. Equivaldría a tener el parámetro de configuración MAXDBAT a 0, pero en este caso, solo para esta aplicación. Útil en casos en que una aplicación está causando problemas de saturación del subsistema.
Seguridad y Conectividad
Controla aspectos de seguridad en conexiones TCP/IP remotas especificando filtros basados en AUTHID para monitorizar conexiones seguras.
Ejemplo 1: Limitar conexiones por AUTHID
DSN_PROFILE_TABLE
| PROFILEID | AUTHID | PROFILE_ENABLED |
|---|---|---|
| 3001 | APPUSER1 | Y |
DSN_PROFILE_ATTRIBUTES
| PROFILEID | KEYWORD | ATTRIBUTE1 | ATTRIBUTE2 | ATTRIBUTE3 |
|---|---|---|---|---|
| 3001 | MONITOR CONNECTIONS | EXCEPTION | 20 | NULL |
Explicación: Controla conexiones concurrentes por usuario de aplicación. Detecta pools mal configurados o abuso de credenciales compartidas.
Ejemplo 2: Control por CLIENT_USERID
DSN_PROFILE_TABLE
| PROFILEID | CLIENT_USERID | PROFILE_ENABLED |
|---|---|---|
| 3002 | web-front | Y |
DSN_PROFILE_ATTRIBUTES
| PROFILEID | KEYWORD | ATTRIBUTE1 | ATTRIBUTE2 | ATTRIBUTE3 |
|---|---|---|---|---|
| 3002 | MONITOR THREADS | EXCEPTION | 80 | NULL |
Explicación: Separa el workload de un servidor web específico, protegiendo el subsistema de problemas en la capa de presentación.
Parámetros de Package Release
Personaliza el comportamiento de release de package para threads locales y conexiones DBAT remotas, anulando la opción RELEASE(DEALLOCATE) cuando sea necesario.
Ejemplo 1: Modificar el RELEASE(DEALLOCATE) a RELEASE(COMMIT)
DSN_PROFILE_TABLE
| PROFILEID | PROFILE_ENABLED | COLLID |
|---|---|---|
| 4001 | Y | DEALLOC |
DSN_PROFILE_ATTRIBUTES
| PROFILEID | KEYWORD | ATTRIBUTE1 | ATTRIBUTE2 |
|---|---|---|---|
| 4001 | RELEASE_PACKAGE | COMMIT | 1 |
Explicación: Para ahorrar CPU y optimizar el elapsed time, se hace bind a los package con RELEASE(DEALLOCATE). Sin embargo, esto impide que un DBA pueda intervenir con actualizaciones DDL críticas.
Configuración Dinámica de Parámetros
Puedes optimizar parámetros del subsistema para sentencias SQL específicas sin necesidad de modificar configuraciones globales. Esto es especialmente útil cuando diferentes aplicaciones tienen requisitos de optimización distintos.
Ejemplo 1: Modificar dinámicamente el tamaño de un bufferpool
DSN_PROFILE_TABLE
| PROFILEID | PROFILE_ENABLED | LOCATION |
|---|---|---|
| 5001 | Y |
DSN_PROFILE_ATTRIBUTES
| PROFILEID | KEYWORD | ATTRIBUTE1 | ATTRIBUTE2 |
|---|---|---|---|
| 5001 | BP1 | NULL | 20000 |
| 5001 | SORT_POOL_SIZE | NULL | 307200 |
Explicación: Útil para modelar temporalmente un entorno de producción en un entorno de test.
Registros Especiales y Variables Globales
Establece registros especiales y variables globales de forma dinámica para contextos específicos, permitiendo que diferentes aplicaciones tengan configuraciones personalizadas sin impactar otras.
Ejemplo 1: Hacer que las conexiones que vienen a través de un driver obsoleto se ejecuten con los package del driver de una versión anterior
DSN_PROFILE_TABLE
| PROFILEID | PROFILE_ENABLED | PRDID |
|---|---|---|
| 6001 | Y | JCC03720 |
DSN_PROFILE_ATTRIBUTES
| PROFILEID | KEYWORD | ATTRIBUTE1 | ATTRIBUTE2 |
|---|---|---|---|
| 6001 | SPECIAL_REGISTER | SET CURRENT PACKAGE = ‘NULLID_V11R1’ | NULL |
Explicación: Las ejecuciones que vengan a través de un driver de versión 3.72 (no soporta nuevas funcionalidades de V13), se ejecute con la versión de package de SYSLH* cuyo bind se hizo en versión 11 de Db2.
Aceleración de Consultas
Define profiles para identificar y dirigir consultas hacia aceleradores especializados cuando corresponda.
Conclusión
Las profile tables representan una herramienta sofisticada que permite a los administradores de Db2 for z/OS implementar políticas granulares de monitorización y control, sin requerir cambios en la configuración global del subsistema.
Su flexibilidad las hace especialmente valiosas en ambientes complejos con múltiples aplicaciones con requisitos distintos. Sin embargo, requieren una comprensión sólida de las categorías de filtrado, reglas de precedencia y procedimientos de activación para obtener el máximo beneficio.