Vous êtes sur la page 1sur 17

INSTITUTO POLITÉCNICO NACIONAL

INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE CÓMPUTO

INVESTIGACIÓN SOBRE DB2

ALUMNOS:

Becerril Bernal Malinali


Díaz Gómez Alfredo Tonatiuh
Hernández Malacara Luis Alfonso

PROFESOR:

Alejandro Botello Castillo

MATERIA:

Bases de datos
Estadísticas de DB2

Si bien, dentro de una base de datos relacional, el componente principal son las
tablas, existen otros componentes importantes como lo son las vistas y los índices.
Todos estos objetos tienen un tamaño máximo para ser creados y manipulados.

Ahora bien, antes de comenzar a hablar de las estadísticas es importante conocer el


concepto de ​espacio de tabla​, el cual no es más que una asignación de espacio
físico.
Al crear una tabla, automáticamente se crea el espacio de tabla, sin embargo,
también es posible generar un espacio de tabla sin crear una tabla. Dentro de este
espacio de tabla no solo se almacena la estructura de tabla, si no que también se
encuentran los índices, los cuales son punteros ordenados de fila a una columna.
Los índices se encuentran separados de los datos de la tabla.

Para comenzar, el máximo de objetos que pueden ser creados en DB2 es de ​32767,
sin embargo, este dato es poco preciso y confiable, ya que en este momento no se
encuentra dentro de la documentación de DB2, fue obtenido de una respuesta
dentro de un foro de hace un año y medio.
Por otro lado, sí se tiene definido un número preciso de tablas y triggers máximo por
un solo archivo de base de datos, el cual es de 11767.

Uno de los datos más relevantes dentro de DB2 es el tamaño máximo de una tabla;
este es 128TB para tablas que no contengan LOB(Large objects).
Ahora bien, este tamaño depende de la acción que estemos realizando con SQL,
por ejemplo, al realizar un SELECT, únicamente es posible hacer referencia 255
tablas en la cláusula FROM.

El máximo número de columnas soportadas por una tabla o una vista es de 750,
esta restricción está dada por el soporte de SQL.

Además de estas estadísticas de objetos de DB2, es importante conocer también


algunas restricciones sobre los tipos de datos que este manejador soporta.
El tipo más utilizado es VARCHAR, del cual, su tamaño está definido por el tamaño
del espacio de tabla en el que se encuentra la tabla.
Para espacios de tablas de tamaño de 4KB por página, el tamaño máximo es de
4046 bytes.
Para páginas de 8KB, el máximo es de 8128KB.
Para páginas de 16KB, el máximo es de 16320KB.
Para páginas de 32KB, el máximo es de 32704KB.
Otro tipo de dato importante es el BLOB(Binary Large Objects), derivado de los
LOB, es un tipo de dato de muy gran tamaño, “debe ser manipulado de una manera
especial” por sus características.
DB2 soporta BLOB de un tamaño máximo de ​2147483647 bytes (2GB - 1).

Otros números de relevancia son:


Tamaño máximo de un nombre de columna: 30 bytes.
El máximo número de datos(en este contexto, un dato = un valor de columna) que
pueden ser ingresados en una sola sentencia de INSERT es de 32767.
El tamaño máximo de una sentencia SQL es de 2097152 bytes.
El máximo número de referencias a procedimientos almacenados, triggers y
funciones que se puede hacer en una sola sentencia de SQL es de 64.
Dentro de DB2 se puede tener un máximo de 65217 bases de datos.

Procesamiento

Aislamiento

DB2 soporta cuatro niveles de aislamiento en las transacciones y estos son las
siguiente; están ordenadas desde la que no permite anomalias hasta la que las
permite completamente:
● Lectura repetible
Se bloquean las tablas de la transacción para que otras transacciones que
añaden valores a la tabla o los eliminan de la misma no puedan cambiar
condiciones WHERE. Esto impide todos los tipos de anomalías de base de
datos.
● Estabilidad de lectura
Este nivel indica que las filas que se leen retienen bloqueos para que otra
transacción no pueda cambiarlas si la transacción no ha finalizado. Esto no
permite las lecturas sucias y las lecturas no repetibles. Las lecturas fantasma
siguen siendo posibles.
● Estabilidad del cursor
Este nivel indica que los cambios efectuados dentro de una transacción no
son visibles fuera de ella hasta que se compromete la transacción. Esto
impide que las lecturas sucias sean posibles.
● Lectura no confirmada
Este nivel permite que las transacciones vean los cambios no comprometidos
en los datos. En este nivel son posibles todas las anomalías de base de
datos.
Ahora, los tipos de anomalías pueden ser: lecturas sucias, lecturas no repetibles y
lecturas fantasma. Las lecturas sucias son producidas una primera transacción
inserta una tupla, una segunda transacción lee la nueva tupla y la primera
transacción cancela la inserción de la tupla. Las lecturas no repetibles ocurren
cuando una primera transacción lee una tupla, una segunda transacción modifica la
misma tupla y la primera transacción vuelve a leer la tupla obteniendo los nuevo
valores de la tupla. Y por último las lecturas fantasma ocurren cuando una primera
transacción realiza un consulta con una cláusula where, una segunda transacción
hace una inserción que cumple con la misma cláusula where y la primer transacción
vuelve a hacer la misma consulta y obtiene la nueva tupla

Seguridad en DB2

En general la seguridad de DB2 es denominada seguridad de varios niveles. Está


basado en la clasificación de datos y usuarios en sistemas de seguridad jerárquicos
y no jerárquicos. Esto permite que un usuario no autorizado no tenga acceso a
ciertos datos. Lo anterior lo logra por medio identificadores, privilegios y
autorizaciones.

La seguridad que implementa DB2 consta de dos fases: la autenticación y la


autorización. La primer fase no la realiza directamente DB2, por lo general es
realizado por el sistema operativo, un método de autenticación de red o algún
plug-in del lado del cliente. Esto se realiza en el momento de conexión a la base de
datos. La segunda fase se verifica las acciones y secciones a las que tiene acceso
un usuario (previamente autenticado) dentro de la base de datos.

DB2 utiliza identificadores para manejar el acceso a los datos. DB2 asigna id’s a
cada proceso e inicio de sesión que se solicitan, estos id’s son llamados ID de
autorización (IDA). Estos ID mantienen privilegios que es lo que les permite realizar
ciertas acciones y niega otras. Los privilegios son:

● Privilegios relacionados
Db2 define los conjuntos de privilegios relacionados, denominados
autorizaciones administrativas. Al otorgar una autorización administrativa a un
ID, se otorgan todos los privilegios asociados con ésta, en una sentencia.
● Privilegios de objeto
La propiedad de un objeto conlleva un conjunto de privilegios relacionados
sobre el objeto. Un ID puede ser el propietario de un objeto que crea o puede
crear un objeto que pertenecerá a otro ID. La creación y propiedad de los
objetos se controlan de forma separada.
● Privilegios de paquete y plan de aplicación
El privilegio para ejecutar un plan de aplicación o un paquete requiere
atención especial. La ejecución de un plan o un paquete ejerce
implícitamente todos los privilegios que el propietario del plan o paquete ha
necesitado para vincularlo. Por lo tanto, el otorgamiento del privilegio para
ejecutar puede proporcionar un conjunto detallado de privilegios y puede
eliminar la necesidad de otorgar otros privilegios por separado.
● Etiquetas de seguridad
La seguridad de varios niveles limita el acceso a un objeto o a una fila
basándose en la etiqueta de seguridad del objeto o fila y en la etiqueta de
seguridad del usuario.
● Roles
Un rol es una entidad de base de datos que agrupa uno o más privilegios. Un
rol sólo está disponible cuando el proceso se ejecuta en un contexto fiable.
Un contexto fiable es una entidad de base de datos basada en un ID de
autorización del sistema y en un conjunto de atributos de fiabilidad de
conexión. Puede crear y utilizar un contexto fiable para establecer una
conexión acreditada entre Db2 y una entidad externa como, por ejemplo, un
servidor de middleware.
Los usuarios se asocian a un rol en la definición de un contexto fiable. Un
contexto fiable puede tener un rol por omisión, roles específicos para
usuarios individuales o ningún rol.
Los privilegios son organizados en autorizaciones de manera jerárquica así cada
autorización tiene privilegios y los privilegias de las autorizaciones que están por
debajo. Se clasifican en autorizaciones del sistema, de base de datos y de
colección.

● Autorizaciones del sistema


○ SYSADM
La autorización de administración del sistema incluye todos los
privilegios de Db2 (salvo unos pocos reservados para instalación), los
cuales se pueden otorgar todos a otros.
Puede limitar la capacidad de SYSADM de gestionar el acceso a los
roles. También puede limitar la capacidad de SYSADM de otorgar o
revocar autorizaciones y privilegios.
○ SYSCTRL
La autorización de control del sistema incluye la mayoría de los
privilegios SYSADM, pero excluye los privilegios para leer o modificar
datos del usuario.
○ SYSOPR
La autorización de operador del sistema incluye los privilegios para
emitir la mayoría de los mandatos de Db2 y terminar cualquier trabajo
de programa de utilidad.
● Autorizaciones de base de datos
○ DBADM
La autorización de administración de base de datos incluye los
privilegios para controlar una base de datos específica. Los usuarios
con autorización DBADM pueden acceder a tablas y modificar o
descartar espacios de tablas, tablas o índices de la base de datos.
○ DBCTRL
La autorización de control de base de datos incluye los privilegios para
controlar una base de datos específica y ejecutar programas de
utilidad que pueden modificar datos de dicha base de datos.
○ DBMAINT
La autorización de mantenimiento de base de datos incluye los
privilegios para trabajar con determinados objetos y emitir
determinados programas de utilidad y mandatos en una base de datos
específica.
● Autorizaciones administrativas
○ ACCESSCTRL
La autorización de control de acceso permite a SECADM delegar la
capacidad de otorgar y revocar privilegios de objetos y la mayoría de
las autorizaciones administrativas.
○ DATAACCESS
La autorización de acceso a datos controla el acceso de DBA a datos
de usuario en Db2.
○ EXPLAIN
La autorización EXPLAIN permite a un usuario emitir sentencias
EXPLAIN, PREPARE y DESCRIBE sin que se requiera el privilegio
para ejecutar la sentencia.
○ PACKADM
La autorización de administrador de paquetes proporciona acceso a
colecciones determinadas.
○ SECADM
La autorización de administrador de seguridad permite a un usuario
gestionar el acceso a una tabla en Db2, pero no puede crear, modificar
ni descartar una tabla.
○ SQLADM
La autorización de administrador de SQL proporciona la capacidad de
supervisar y ajustar el SQL sin privilegios adicionales.

Formas de variar la seguridad


La primer forma de variar la seguridad es mediante el archivo de configuración del
manejador de base de datos o en sus siglas en ingles dbm cfg específicamente con
el parámetro AUTHENTICATION. Para este comando existen siete diferentes
valores posibles, estos son: SERVER, CLENT, SERVER_ENCRYPT, KERBEROS,
SQL_AUTHENTICATION_DATAENC, SQL_AUTHENTICATION_DATAENC_CMP,
GSSPLUGIN. La siguiente tabla ilustra el comportamiento de cada uno:

Otra forma en que podemos implementar seguridad en una base de datos en BD2
es mediante el uso de vistas. El uso de las vistas y la asignación de privilegios en
esta nos permiten tener control de los datos a los cuales puede tener acceso
además de que encapsula las sentencias SQL dentro de la base de datos. A esto se
le denomina control de acceso de nivel de campo o sensibilidad de nivel de campo.

Modulos Agregados.

Soporte para 4GL(Lenguaje de programación de 4ª generación).

El sistema de administración de bases de datos DB2 no cuenta con el soporte para 4GL.
Sin embargo, IBM maneja INFORMIX, el cuál permite el uso de 4GL.

Utilidades de respaldo y recuperación​.


Para el tratamiento de respaldos y recuperaciones de información con DB2 en la
versión 11.0.0, el SABD se basa en el registro y el BSDS para registrar los cambios
de datos a medida que estos se producen.

¿Qué es el registro? El registro DB2 ​registra cambios en los datos y eventos


significativos a medida que ocurren. Db2 escribe cada registro de anotaciones en el
registro activo, que es un conjunto de datos de disco. Cuando el conjunto de datos
de registro activo está lleno, Db2 copia su contenido al registro de archivo, que es
un disco o un conjunto de datos de cinta, conformando al proceso que se denomina
como descarga.
El registro de archivo puede constar de hasta 10000 conjuntos de datos. Cada
registro de archivo es un conjunto de datos secuencial (secuencial físico) que reside
en un disco o volumen de cinta magnética.
Con Db2 , puede elegir entre registro único o registro dual. Un solo registro activo
contiene hasta 93 conjuntos de datos de registro activos. Con el registro dual, Db2
conserva dos copias idénticas de los registros de registro. El registro dual es la
mejor opción para una mayor disponibilidad.

El conjunto de datos de arranque (​BSDS bootstrap data set)​ es un repositorio de


información sobre los conjuntos de datos que contienen el registro (el cuál definimos
arriba).

El BSDS contiene la siguiente información:

● Un inventario de todos los conjuntos de datos de registro activos y


archivados que son conocidos por Db2 ​. Db2 registra datos sobre el
conjunto de datos de registro en el BSDS cada vez que se define un nuevo
conjunto de datos de registro de archivo o se reutiliza un conjunto de datos
de registro activo. El inventario de BSDS incluye la hora y la fecha en que se
creó el registro, el nombre del conjunto de datos, su estado y otra
información. Db2 utiliza esta información para rastrear los conjuntos de datos
de registro activos y archivados. Db2 también utiliza esta información para
ubicar los registros de registro para las solicitudes de lectura de registros que
se producen durante la actividad normal del subsistema Db2 y durante el
reinicio y el proceso de recuperación.
● Un inventario de toda la actividad reciente de punto de control​​ que Db2
utiliza durante el proceso de reinicio.
● Un registro de comunicación de facilidad de datos distribuidos​​ (DDF).
● Información sobre las agrupaciones de almacenamiento intermedio​​.
Debido a que el BSDS es esencial para la recuperación en caso de una falla del
subsistema, Db2 crea automáticamente dos copias del BSDS durante la instalación.
Si es posible, Db2 coloca las copias en volúmenes separados.

Las siguientes utilidades se usan comúnmente para copia de seguridad y


recuperación:

● COPY, QUIESCE, MERGECOPY y BACKUP SYSTEM para copia de


seguridad

● RECUPERACIÓN, ÍNDICE DE RECONSTRUCCIÓN, INFORME, Y SISTEMA


DE RESTAURACIÓN para la recuperación

En general, utiliza estas utilidades para prepararse para la recuperación y restaurar


datos. Cada utilidad desempeña un papel en el proceso de copia de seguridad y
recuperación.

COPY
La utilidad COPY crea hasta cuatro copias de imágenes de espacios de tablas,
índices y conjuntos de datos.
Los dos tipos de copias de imagen son los siguientes:

● Copia de imagen completa : una copia de todas las páginas en un espacio de


tabla, partición, conjunto de datos o espacio de índice.
● Copia de imagen incremental : una copia de solo las páginas de espacio de
tabla que han cambiado desde el último uso de la utilidad COPY.
Mientras se ejecuta COPY, puede usar una opción de SHRLEVEL para controlar si
otros programas pueden acceder o actualizar el índice o el espacio de la tabla.

● SHRLEVEL REFERENCE le da acceso a otros programas de solo lectura.


● SHRLEVEL CHANGE permite que otros programas cambien el espacio de
tabla o el espacio de índice.

En general, cuanto más a menudo haga copias de imágenes, menos tiempo llevará
la recuperación. Sin embargo, si realiza copias de imágenes frecuentes, también
pasa más tiempo haciendo copias.
La utilidad RECOVER utiliza estas copias cuando recupera un espacio de tabla o
espacio de índice en el momento más reciente o en un momento anterior. La tabla
de catálogo SYSIBM.SYSCOPY registra información sobre copias de imágenes.

QUIESCE
La utilidad QUIESCE establece un único punto de coherencia, denominado punto de
inactividad , para uno o más conjuntos de páginas. Para establecer puntos de
recuperación regulares para la posterior recuperación en un momento dado, debe
ejecutar QUIESCE frecuentemente entre ejecuciones regulares de COPY.

MERGECOPY
La utilidad MERGECOPY fusiona las copias de imagen que produjo la utilidad
COPY o las copias en línea que produjeron las utilidades LOAD o REORG.
MERGECOPY puede combinar varias copias incrementales de un espacio de tabla
para hacer una copia incremental. También puede combinar copias incrementales
con una copia de imagen completa para hacer una nueva copia de imagen
completa.

BACKUP SYSTEM
La utilidad en línea BACKUP SYSTEM invoca z / OS® DFSMShsm (Versión 1,
versión 5 o superior). BACKUP SYSTEM copia los volúmenes en los que residen los
datos Db2 y la información de registro Db2 para un subsistema Db2 que no
comparte datos o un grupo para compartir datos Db2 .

RECOVER
La utilidad RECOVER recupera los datos al estado actual o a un punto anterior en el
tiempo mediante la restauración de una copia y, a continuación, mediante la
aplicación de registros.

REBUILD INDEX
La utilidad REBUILD INDEX reconstruye los índices de la tabla a la que hacen
referencia.

REPORT
La utilidad REPORT proporciona información que se necesita para recuperar un
espacio de tabla, un índice o un espacio de tabla y todos sus índices. También
puede usar la utilidad REPORT para obtener información de recuperación sobre el
catálogo.

RESTORE SYSTEM
La utilidad en línea RESTORE SYSTEM invoca z / OS DFSMShsm (versión 1,
versión 5 o superior). RESTORE SYSTEM utiliza datos que se copian con la utilidad
BACKUP SYSTEM.

Herramienta de recuperación de aplicaciones para bases de datos IMS y Db2


Una herramienta que simplifica y coordina la recuperación de los datos de IMS ™ y
Db2 a un punto común, lo que reduce el tiempo y el costo de la recuperación y
disponibilidad de los datos.

Db2 Archive Log Accelerator


Una herramienta que reduce la sobrecarga asociada con la administración de
registros de la base de datos para equilibrar los aumentos en el crecimiento del
registro de archivos.

Db2 Change Accumulation Tool para z / OS


Una herramienta que restaura rápidamente los objetos de la base de datos con
precisión y con una interrupción mínima, estableciendo el alcance y la especificidad
de la creación de copias de imágenes mediante el uso de tarjetas de control.

Db2 Log Analysis Tool para z / OS


Una herramienta que le proporciona una herramienta potente para garantizar una
alta disponibilidad y un control completo sobre la integridad de los datos. Esta
herramienta le permite monitorear los cambios de datos mediante la creación
automática de informes de cambios que se realizan en las tablas de base de datos.

Db2 Object Restore para z / OS


Una herramienta que le permite recuperar activos de datos valiosos al restaurar
rápidamente los objetos eliminados sin tiempo de inactividad, incluso si ya no
existen en el catálogo Db2 . Dichos objetos eliminados pueden incluir bases de
datos, espacios de tablas, tablas, índices, datos y autorizaciones de tablas.

Reporteador

No existe como tal un reporteador como en Oracle. Sin embargo podemos obtener
reportes de datos e informes históricos.

DB2® Query Patroller, a través de su análisis histórico, proporciona información


sobre a qué tablas, índices y columnas se ha accedido y cuáles no. DB2 incluye un
conjunto de scripts Perl como muestra que proporciona una funcionalidad similar a
la función Análisis Histórico de Query Patroller utilizando información capturada por
el monitor de eventos de actividades WLM. Esta herramienta de análisis histórico de
WLM se escribió en Perl para que pueda ver o incluso modificar los scripts para
producir informes de análisis históricos adicionales que se adapten a sus
necesidades.
La herramienta de análisis histórico WLM consta de 2 scripts:

● wlmhist.pl: genera datos históricos


● wlmhistrep.pl: produce informes a partir de los datos históricos.

Paso 1: Crear las tablas de explicación.

Para generar algunos datos históricos, las tablas de explicación deben existir bajo el
esquema del usuario que ejecuta la herramienta. Para crear las tablas de
explicación, vaya al directorio / sqllib / misc y ejecute lo siguiente:
db2 CONNECT TO SAMPLE
db2 –tvf EXPLAIN.DDL

Paso 2: Modificar la clase de servicio para recopilar datos de actividad

Habilite la recopilación de actividades especificando la cláusula COLLECT


ACTIVITY DATA en el objeto de WLM de interés. Para este ejercicio, queremos
generar datos históricos para las actividades que se ejecutan en la subclase de
servicio predeterminada de la súper clase de servicio de usuario predeterminada:

ALTER SERVICE CLASS SYSDEFAULTSUBCLASS UNDER


SYSDEFAULTUSERCLASS
COLLECT ACTIVITY DATA ON COORDINATOR WITH DETAILS

Paso 3: Habilitar el monitor de eventos de actividades.

Dado que el supervisor de eventos de actividades se creó en el Paso 1 del Ejercicio


1, habilítelo ahora si aún no está habilitado.

SET EVENT MONITOR DB2ACTIVITIES STATE 1

Paso 4: Ejecutar algunas actividades


Ejecute algunas actividades para que los datos de actividad se recopilen para
generar datos históricos.

db2 –tvf work1.db2


db2 –tvf work2.db2

Paso 5: Desactivar el monitor de actividad

Se recomienda encarecidamente que desactive el supervisor de eventos para las


actividades antes de generar datos históricos. Si no lo hace, cualquier actividad de
DML que se ejecute como resultado del generador de datos históricos también
puede capturarse y colocarse en las tablas de actividad del monitor de eventos de
DB2, lo que aumenta dramáticamente el número de actividades reales para las
cuales se generan datos de actividad.
CONNECT TO SAMPLE

SET EVENT MONITOR DB2ACTIVITIES STATE 0

Paso 6: Generar datos históricos

Ejecute el script del generador de datos históricos, wlmhist.pl, para generar datos
históricos para las actividades que se capturan en las tablas del monitor de eventos
de actividades. El formato es el siguiente:

wlmhist.pl dbname user password [fromTime toTime workloadid


serviceClassName serviceSubclassName activityTable activityStmtTable]

Utilice un guión (-) para omitir cualquier parámetro opcional.


Información adicional: El script del generador de datos históricos (wlmhist.pl)
generará solo datos históricos para DML. Si anteriormente ejecutó el script del
generador de datos históricos (wlmhist.pl) una o más veces, se recomienda que,
antes de ejecutarlo nuevamente, borre las tablas activityTable y activityStmtTable
para evitar la duplicación de datos. Si elige no borrar estas dos tablas, asegúrese de
usar los parámetros de entrada fromTime y toTime para asegurarse de que no
genere datos históricos para actividades que ya hayan generado datos para ellos.
Para este ejercicio, genere datos históricos para todas las actividades que se han
capturado en el monitor de eventos de actividades.

Perl wlmhist.pl sample db2inst1 password

Puede notar algunos errores similares a los siguientes:

Error running explain [IBM][CLI Driver][DB2/LINUXX8664] SQL0418N A


statement contains a use of a parameter marker that is not valid. SQLSTATE=42610
for statement VALUES (TABLE_SCHEMA(:H00002 , :H00003 )) INTO :H00007

DBD::DB2::db do failed: [IBM][CLI Driver][DB2/LINUXX8664] SQL0418N A


statement
contains a use of a parameter marker that is not valid. SQLSTATE=42610
Al generar datos históricos, la explicación se ejecuta en la declaración real. En
algunos casos, la explicación no se puede ejecutar en algunas declaraciones con
marcadores de parámetros y se devuelve un error. Cualquier actividad que muestre
tal error no tendrá datos históricos generados para ello.
Una vez que la herramienta haya completado la generación de datos históricos, le
dirá para cuántas actividades ha generado con éxito datos históricos.

Paso 7: Generar informes de datos históricos

Ejecute el script de informe de datos históricos wlmhistrep.pl para generar informes


basados ​en los datos que se generaron en el paso 1. El formato es el siguiente:

wlmhistrep.pl dbAlias userId passwd [outputFile report schemaName fromTime


toTime submitter]

Utilice un guión (-) para omitir los parámetros opcionales.


El parámetro de informe puede ser cualquier combinación de las siguientes letras:

● A: Tablas golpeadas
● B: tablas no golpeadas
● C: Índices de éxito
● D: Índices no golpeados
● E: Peticionarios
Si el parámetro userId que especifica no es el mismo que el que se usó para
ejecutar el script wlmhist.pl cuando se creó la tabla wlmhist, debe especificar el
nombre de esquema correcto. Los parámetros fromTime y toTime deben
especificarse en formato de marca de hora (por ejemplo, 2007-06-06-17.00.00).
Para este ejercicio, genere informes para tablas de éxito y no índices de aciertos:

Perl wlmhistrep.pl sample db2inst1 password - AD

La salida se verá algo como lo siguiente


:
TABLES HIT REPORT FOR DATABASE sample
_______________________________________________________

TABLE NAME TABLE SCHEMA % HITS TOTAL HITS


______________________ __________________ _____________
____________
EMPLOYEE KARENAM 7.14285714 2
INVENTORY KARENAM 14.28571429 4

ORG KARENAM 28.57142857 8


SALES KARENAM 14.28571429 4
SYSROUTINES SYSIBM 7.14285714 2
SYSTABLES SYSIBM 21.42857143 6
SYSTABLESPACES SYSIBM 7.14285714 2

INDEXES NOT HIT REPORT FOR DATABASE sample


___________________________________________________________

TABLE NAME TABLE SCHEMA INDEX NAME INDEX SCHEMA


INDEX TYPE
__________________ _______________ __________________ _______________
__________
EXPLAIN_ARGUMENT KARENAM ARG_I1 KARENAM
REG
HMON_ATM_INFO SYSTOOLS ATM_UNIQ SYSTOOLS
REG
CUSTOMER KARENAM CUST_CID_XMLIDX KARENAM
XVIL
CUSTOMER KARENAM CUST_NAME_XMLIDX KARENAM
XVIL
CUSTOMER KARENAM CUST_PHONES_XMLIDX KARENAM
XVIL
CUSTOMER KARENAM CUST_PHONET_XMLIDX KARENAM
XVIL
EXPLAIN_DIAGNOSTIC KARENAM EXP_DIAG_DAT_I1KARENAM
REG
HMON_COLLECTION SYSTOOLS HI_OBJ_UNIQ SYSTOOLS
REG
ADVISE_INDEX KARENAM IDX_I1 KARENAM REG
ADVISE_INDEX KARENAM IDX_I2 KARENAM REG
SYSATTRIBUTES SYSIBM INDATTRIBUTES01 SYSIBM REG
SYSATTRIBUTES SYSIBM INDATTRIBUTES02 SYSIBM REG
Paso 8: Restablecer para el próximo ejercicio.

Deshabilite la recopilación de actividades para la subclase de servicio


predeterminada de la superclase de servicio de usuario predeterminada y limpie las
tablas de actividades.

ALTER SERVICE CLASS SYSDEFAULTSUBCLASS UNDER


SYSDEFAULTUSERCLASS
COLLECT ACTIVITY DATA NONE

DELETE FROM ACTIVITY_DB2ACTIVITIES


DELETE FROM ACTIVITYSTMT_DB2ACTIVITIES

Referencias:
[1] Conceptos de Db2 ​IBM Knowledge center. ​[Online] Disponible:
https://www.ibm.com/support/knowledgecenter/es/SSEPEK_11.0.0/intro/src/tpc/db2z
_db2concepts.html
[2] Limits in Db2 ​IBM Knowledge center. ​[Online] Disponible:
https://www.ibm.com/support/knowledgecenter/es/SSEPEK_11.0.0/sqlref/src/tpc/db2
z_limits.html