Si bien las bases de datos son cada vez más y más consciente de sí mismo y auto-curación, que todavía requieren una cierta supervisión para que sigan funcionando tan eficientemente como sea posible. Al igual que su coche, una base de datos requiere un poco de control para que siga funcionando de manera óptima. Este documento se divide en las tareas o los controles que se pueden ejecutar en diferentes intervalos de tiempo para asegurarse de que sus bases de datos DB2 es el mejor, y detectar posibles problemas antes de que sucedan.

El primer conjunto de controles o tareas se debe ejecutar todos los días para asegurarse de que no hay problemas actuales o inminentes. El segundo conjunto se debe ejecutar semanalmente para comprobar si existen problemas o problemas que pueda haber ocurrido durante la semana o es probable que se produzca la próxima semana. El conjunto final de los controles o tareas no es necesario correr todos los días o semanas, pero se debe ejecutar mensualmente para mantener el sistema funcionando sin problemas, y para evitar futuros problemas en caso de que un problema se produce.

El control del sistema

Hay una serie de razones por las que debe controlar su bases de datos, sin embargo, la razón principal es asegurarse de que no existen actualmente problemas con el sistema o son inminentes. Siempre es mejor para detectar un problema y tomar medidas para evitar que suceda que tener que reaccionar ante un problema una vez que ha sucedido. Mediante el control de sus sistemas de base de datos DB2 como se describe en este artículo, usted será capaz de detectar muchos problemas antes de que sucedan, y mantener el rendimiento de su sistema.

herramientas de supervisión disponibles

Normalmente, tendrá que combinar de DB2 y el control del sistema operativo con el fin de obtener el cuadro completo de lo que está pasando en el servidor de base de datos. herramientas de DB2 solos normalmente no dan la imagen completa.

Al capturar la información para el análisis, asegúrese de que el DB2 y la información del sistema operativo se captura al mismo tiempo, como no se puede correlacionar la información capturada en momentos diferentes.

La captura de la información del sistema

Cuando la supervisión del sistema, tomar las instantáneas en un período de tiempo. Tomarlos sólo por un período de uno o dos minutos no dan una visión real de la actividad del sistema. Le sugiero que tome la foto cada uno a 5 minutos, por un período de por lo menos una hora.

Herramientas de Windows

En Windows, se puede ver en el uso de CPU y uso de memoria en el Administrador de tareas como se ve abajo, pero no se puede capturar esta información en un archivo, como usted puede con vmstat y iostat:

Figure 1. Windows Task Manager

herramientas de DB2

DB2 tiene una serie de herramientas que pueden utilizarse para monitorizar la actividad de las bases de datos e instancias. Estos incluyen:

El Monitor de la Salud / Centro de Salud Instantánea de Monitores / Funciones SQL de instantáneas Evento Monitores También hay otras herramientas y registros disponibles que proporcionan información sobre las bases de datos y los casos que incluyen:

El registro de notificaciones de administración Este es un archivo independiente en Linux y UNIX y se incorporan en el registro de sucesos de Windows. Db2diag.log Visualizador de la memoria

1. Health Monitor

En la Versión 8, DB2 introducido dos nuevas características que le ayudarán a controlar la salud de los sistemas DB2: el Monitor de la Salud y el Centro de Salud. Estas herramientas añadir una capacidad de gestión por excepción a DB2 9 alertando a los posibles problemas del sistema de salud. Esto le permite hacer frente a problemas de salud antes de que se conviertan en problemas reales que afectan el rendimiento del sistema.

El Monitor de la Salud se ejecuta en el servidor DB2 y un seguimiento permanente de la salud de la instancia de DB2 y bases de datos. Si el Monitor de Salud detecta que un umbral definido por el usuario se ha excedido (por ejemplo, el espacio de registro disponible ha caído por debajo de un determinado porcentaje del espacio total disponible), o si se detecta un estado anormal de un objeto (por ejemplo, la instancia de DB2 ya no se ejecuta), el Monitor de Salud lanzará una alerta.

Cuando una alerta se produce dos cosas pueden ocurrir:

La notificación de alerta será enviado. Esto puede ser enviado por correo electrónico o un buscapersonas Pre-configurado acciones se pueden tomar. Un script de CLP o una tarea Centro de tareas se pueden ejecutar. Un indicador de salud es una característica del sistema que los controles del monitor de la Salud. El Monitor de la Salud viene con un conjunto de umbrales predefinidos para estos indicadores de salud. El Monitor de la Salud comprueba el estado de su sistema en contra de estos umbrales de los indicadores de salud para determinar si emite una alerta. Uso del Centro de Salud, los comandos, o API, puede personalizar la configuración de umbral de estos indicadores de salud, y definir quién debe ser

notificado y qué secuencia de comandos o la tarea se debe ejecutar si se emite una alerta.

El Centro de Salud proporciona la interfaz gráfica para el Monitor de la Salud. Se usa para configurar el monitor de la Salud, y para ver el estado enrollado de alerta de las instancias y los objetos de base de datos. Uso de perforar el Centro de Salud de abajo capacidad, puede acceder a los detalles acerca de las alertas actual y obtener una lista de acciones recomendadas que se describe cómo resolver la alerta. También puede optar por seguir un derecho de acción recomendada dentro de la herramienta. El Centro de Salud se configura fácilmente para mostrar el estado de salud balizas línea y / o que aparezca un cuadro de diálogo que indica que el Centro de Salud tiene un objeto en estado de alerta.

2. Instantánea de Monitores / Funciones SQL de instantáneas

DB2 mantiene datos sobre su funcionamiento, su rendimiento y las aplicaciones que están accediendo a ella. Estos datos se mantiene como el gestor de base de datos se ejecuta, y puede proporcionar un rendimiento importante y solución de problemas. Por ejemplo, usted puede encontrar:

El número de aplicaciones conectadas a una base de datos, su estado, y que las sentencias SQL de cada aplicación se está ejecutando, en su caso. La información que muestra lo bien que el administrador de base de datos y base de datos se configuran, y le ayuda a "desconectar". Cuando se produjeron bloqueos de base de datos especificada, las aplicaciones que estaban involucrados, y que las cerraduras estaban en disputa. La lista de bloqueos que tienen una aplicación o base de datos. Si la aplicación no puede continuar porque está esperando un bloqueo, hay información adicional sobre el bloqueo, incluyendo la aplicación que lo sostiene. La lista de sentencias SQL ejecutadas contra una base de datos, ¿cuántas veces se ejecutan, cómo muchas clases se llevaron a cabo en nombre de la declaración y la cantidad total de tiempo de CPU utilizado por cada declaración. El número de clases que se han producido y el número actualmente en curso. Debido a que los monitores no añadir un poco de sobrecarga en el sistema, los interruptores del monitor se puede activar o desactivar de forma independiente. También se pueden establecer para toda la instancia, y todas las bases de datos en la instancia, o se puede establecer en una sesión de base de datos. Si los conmutadores de supervisor están permitidas dentro de una sesión, sólo son "activos" para ese período de sesiones, y una instantánea tomada desde otra sesión no se captura la información del monitor. Si los interruptores se activan con los parámetros de configuración de instancia de DB2, que están habilitados para todas las sesiones, salvo que se apaga dentro de un período de sesiones.

Para configurar los conmutadores de supervisor dentro de una sesión, utilice el comando UPDATE MONITOR conmutadores o los sqlmon () API.

Por ejemplo, para habilitar agrupación de almacenamientos intermedios, de bloqueo, y el seguimiento sentencia de SQL dinámico, a su vez en el monitor el detector con el comando

update monitor switches using bufferpool on lock on statement on

NOTA: Debe tener SYSADM, SYSCTRL, SYSMAINT o SYSMON (nuevo en DB2 9) autoridad para actualizar los conmutadores de supervisor y / o tomar una instantánea de DB2.

Usted puede acceder a los datos que el administrador de base de datos mantiene, ya sea tomando una instantánea o utilizando un monitor de eventos. Usted puede tomar una instantánea en una de las siguientes maneras:

Utilizando el comando GET Descripción de la línea de comandos Llamando a las funciones de SQL de instantáneas de mesa Uso del Centro de Control Escribe tu propia aplicación, que hace que el sqlmonss () llamada a la API.

3. Evento Monitores

Una vez que un supervisor de sucesos se ha creado y activado, se recopilará información sobre la base de datos y las aplicaciones de base de datos cuando se produce el evento especificado. Un evento es un cambio en la actividad de base de datos que puede ser causada por uno de los siguientes:

Una base de datos de conexión / desconexión Un callejón sin salida, o tiempo de espera de bloqueo La ejecución de la instrucción Una transacción de comienzo o fin Un supervisor de sucesos se crea basándose en el tipo de evento que desee que para detectar y registrar. Por ejemplo, un supervisor de sucesos estancamiento espera que se produzca un punto muerto, y cuando uno se da garantizará la recogida y registro de información sobre las aplicaciones y los bloqueos que participan en la condición de interbloqueo.

Los supervisores de sucesos se crean mediante la sentencia CREATE EVENT MONITOR, y recopilará la información de eventos sólo cuando están activos. Un supervisor de sucesos se activa y desactiva mediante el comando SET EVENT MONITOR declaración ESTADO. La función EVENT_MON_STATE devolverá el estado actual del supervisor de sucesos especificado.

Cuando la sentencia CREATE EVENT MONITOR se ejecuta, la definición del supervisor de sucesos se crean y se almacenan en las tablas de catálogo del sistema.

SYSCAT.EVENTMONITORS: Evento monitores definidos para la base de datos. SYSCAT.EVENTS: Tipos de Eventos está supervisando la base de datos. SYSCAT.EVENTTABLES: Los nombres de las tablas de destino para los supervisores

de sucesos de mesa. Herramientas del sistema operativo

herramientas de base de datos / fotos por sí mismos normalmente no te dan la imagen completa de su rendimiento del sistema. Por ejemplo, una base de datos puede ser 100% óptima sintonía, pero no será capaz de realizar bien si E / S afirmación está ocurriendo en el servidor. Por lo tanto, es importante tener en cuenta el panorama completo para asegurarse de que todo el sistema está funcionando bien.

Compruebe que todas las instancias están en marcha

Esto se puede hacer en un número de maneras:

Utilice el Centro de Salud. exportación establecidos DB2INSTANCE instancename = y ejecutar db2start. Adjuntar a todas las instancias. En UNIX o Linux, ejecutar ps-ef | grep db2sysc Compruebe que haya un proceso de db2sysc para cada instancia. En Windows, compruebe que el servicio para cada instancia de DB2 se ha iniciado. El método se puede conectar fácilmente secuencias de comandos, siempre y cuando todos los casos (es decir, los nodos) son catalogados en su estación de trabajo.

Compruebe que todas las bases de datos se activa o se ajuste

La definición de la constante puede ser confuso, y como se ha informado por el comando GET DB CFG causa a menudo preguntas.

Por definición, una base de datos es coherente cuando todas las transacciones confirmadas se han escrito en el disco, y las transacciones no confirmadas no están en el disco Cuando una base de datos se está ejecutando con las aplicaciones conectadas a la misma, no serán las operaciones que han cambiado las páginas, que pueden haber cometido, pero las páginas cambiado no han sido eliminados del grupo de búferes en el disco. Además, es posible que las transacciones que se deshacen, pero sus cambios se vuelca en disco. En este caso, el GET DB CFG informará de que la base de datos es incoherente, pero en realidad está muy bien. Por lo tanto, sólo tiene que conseguir la información de configuración de base de datos para todas las bases de datos no es suficiente.

Un buen método, ya que también hará que las bases de datos inconsistentes coherente y por lo tanto reducir los tiempos para las futuras solicitudes de conexión, es conectar con éxito a todas las bases de datos. Esto también puede ser fácilmente secuencias de comandos, siempre y cuando todas las bases de datos se catalogan en su estación de trabajo.

Puedes buscar nueva Iniciar sesión Administración de notificación y / o entradas db2diag.log

Es importante asegurarse de que no había problemas que se produjeron durante la noche. Desde la versión 8 de DB2 ha estado escribiendo mensajes de diagnóstico a dos lugares, la Administración de notificación de registro (donde los mensajes destinados a los DBAs están escritos), y el archivo db2diag.log (donde los mensajes destinados al equipo de servicio de DB2 se escriben).

En Windows, el registro de la Administración de notificación está escrito en el registro de sucesos de aplicación y se pueden ver utilizando el Visor de sucesos eligiendo el registro de la aplicación y la búsqueda de eventos por escrito por la aplicación denominada DB2.

Figure 2. Windows Event Viewer

En Linux y UNIX, el registro se escribe en un archivo llamado <instance_ID>. NFY que se encuentra en el directorio especificado por el parámetro de configuración de ejemplo DIAGPATH nivel. Para ver el registro de notificación se puede: • Conectar a cada uno de los servidores mediante telnet o servicios de terminales remotas. • Para cada caso, vaya al directorio DIAGPATH. • En el símbolo del sistema: o Ejecutar el comando de cola en el registro de notificaciones para descargar las últimas 100 entradas

o Editar el archivo y ver las entradas más recientes en la parte inferior del archivo. Compruebe que las copias de seguridad de la noche anterior tuvieron éxito No hay nada peor que tener un problema en el sistema, y la decisión de restaurar la copia de seguridad más recientes, y luego encontrar que la copia de seguridad no se ha tenido o no está completa. Por lo tanto, es importante comprobar que copia de seguridad de la noche anterior (s) tuvieron éxito y que han sido almacenados en un lugar seguro. El primer paso es asegurar que las copias de seguridad tuvieron éxito. Esto se hace usando el comando del historial de la siguiente manera:

list history backup all for db_name

Esto puede ser un guión para que se ejecute para todos los bases de datos después de las copias de seguridad completa, y el informe enviado por correo electrónico. A continuación, puede simplemente verificar el informe de cada mañana.

En el caso de que todo el servidor se cae durante un período prolongado de tiempo, puede que tenga que volver a su plan de recuperación de desastres, restaurar la base de datos a otro servidor, tal vez en otro lugar. Por lo tanto, es importante que las imágenes de copia de seguridad se almacenan en un sitio seguro, no sólo en el servidor donde se toma la copia de seguridad. Esto se puede lograr fácilmente mediante la copia de la imagen de copia de seguridad en una unidad de LAN, una unidad montada NFS o un dispositivo de cinta.

Compruebe los registros de base de datos han sido archivados con éxito

Si la base de datos es de sólo lectura, o puede ser reconstruido a partir de cero con facilidad, es probable que no tiene registro de mantener habilitado para que pueda saltarse este paso. Sin embargo, para las bases de datos transaccionales en las que no puede permitirse el lujo de perder las transacciones confirmadas, es importante para hacer registro de seguro de conservar es permitido, y que los registros están archivados con éxito para que la base de datos puede ser reconstruido y las transacciones repite en el caso de un desastre.

Mientras que la recuperación puede ser la razón principal para la verificación de los registros se archivan con éxito, hay otra razón importante. Si los registros no están archivados, que permanecerá en el LogPath. Desde la LogPath está normalmente en un sistema de archivos con un tamaño del conjunto, si los archivos de registro no se están archivados, como los nuevos registros se creó el sistema de archivos se llena. Cuando esto ocurre, DB2 no será capaz de crear los archivos de registro más y se detendrá por lo tanto.

Cuando un userexit se llama al archivo de un archivo de registro, se escribe información en dos lugares. El primer lugar será el registro de auditoría userexit donde se escribe una entrada para cada solicitud de registro de archivo recibido por el userexit. En el caso de un error durante el procesamiento userexit, un mensaje se escribe en el archivo userexit registro de errores también. Estos archivos de registro se encuentran en el LogPath y se denominan ARCHIVE.LOG y USEREXIT.ERR respectivamente.

Para examinar estos registros se puede escribir un script para tomar los últimos 50 a 100 líneas de estos ficheros (utilizando el comando tail) para todas las instancias y enviarlas por correo electrónico a usted. Entonces usted puede estudiar junto con la información de la historia de recuperación de cada mañana.

get dbm cfg get db cfg for db_name

Asegúrese de que la captura de la salida de los comandos en un archivo, y el nombre del archivo para que se tenga la fecha como parte del nombre, como DB_DBM_CFG.07152006.out. A continuación, puede utilizar una herramienta como esta para comparar la corriente de salida con la salida del día anterior de la siguiente manera:

diff DB_DBM_CFG.07142006.out DB_DBM_CFG.07152006.out

De esta manera, si hay un cambio que va a ver algo como lo siguiente:

< Degree of parallelism (DFT_DEGREE) = 1---> Degree of parallelism (DFT_DEGREE) = 4

Compruebe el rendimiento importantes medidas basadas en la carga de trabajo

Mientras que el grupo de búferes proporción de aciertos es muy importante para los sistemas OLTP, es imposible tener un grupo de búferes alta proporción de aciertos en un almacén de base de datos, por lo que examinar las medidas que son importantes para la carga de trabajo. Algunas de las medidas de rendimiento importante, y cómo se puede calcular se muestran a continuación. Calcular los datos, el índice combinado del grupo de búferes y golpeó relaciones, así como el porcentaje de lectura asincrónica mediante el siguiente

select substr(bp_name,1,20) as BP_NAME, int (( 1 - (decimal(pool_data_p_reads) /

nullif(pool_data_l_reads,0) )) * 100) as data_hit_ratio,int (( 1 - (decimal(pool_index_p_reads) /

nullif(pool_index_l_reads,0) )) * 100) as index_hit_ratio,int (( 1 - (decimal(pool_data_p_reads + pool_index_p_reads) /

nullif( (pool_data_l_reads + pool_index_l_reads),0) )) * 100) as BP_hit_ratio,

int (( 1 - (decimal(pool_async_data_reads + pool_async_index_reads) /

nullif( (pool_async_data_reads + pool_async_index_reads + direct_reads),0) )) * 100) as Async_read_pct,

int (( 1 - (decimal(direct_writes) / nullif(direct_reads,0) )) * 100) as Direct_RW_Ratiofrom table (snapshot_bp ('sample', -1) ) as snapshot_bp ;

Nota: La función NULLIF se utiliza en la consulta anterior para devolver un valor nulo cuando el número en el interior del soporte (es decir, pool_data_l_reads o pool_index_l_reads) es cero (0), de lo contrario el cálculo podría causar una división por cero error y la declaración de un error.

Examinar los patrones de uso de las tablas de la base de datos mediante la consulta más adelante. Esta consulta examinar cuántas filas se han leído, escrito, y el número de registros de desbordamiento de acceder mediante la siguiente declaración.

select substr(table_schema,1,8) as Schema, substr(table_name,1,30) as Table_Name, rows_read, rows_written, overflow_accessesfrom table (snapshot_table ('sample', -1) ) as snapshot_table;

Examinar los patrones de uso de base de datos general con la consulta más adelante. Esta consulta se examina:

¿Cuántas filas se lee vs seleccionados ¿Cómo bloqueo producido muchas espera, el bloqueo total de tiempo de espera y el bloqueo de medio tiempo de espera Cómo muchos callejones sin salida y las extensiones de bloqueo se detectaron ¿Cómo ocurrió muchas clases, el tiempo total de clase, y el tiempo de clase media, el porcentaje de clases que se desbordó

select db_name, SNAPSHOT_TIMESTAMP, rows_read, rows_selected, lock_waits, lock_wait_time, lock_wait_time/nullif(lock_waits,0) as avg_wt_time, deadlocks, lock_escals, total_sorts, total_sort_time, total_sort_time/nullif(total_sorts,0) as avg_sort_time, sort_overflows, sort_overflows/nullif(total_sorts,0) as pct_ovflow_sorts from table (snapshot_database (' ', -1) ) as snapshot_database;

Compruebe para DB2 acciones automáticas ha tomado en su nombre

Con la creciente capacidad de DB2 para adaptarse a los cambios en el rendimiento y la utilización de forma automática, gran parte de la administración cotidiana ya no es necesario, pero aún así puede ser que desee ver, y entender, los cambios de DB2 ha hecho a la base de datos de parámetros de configuración, así en cuanto a la asignación de espacio de tabla subyacente.

Usted puede seguir los cambios en la asignación de espacio de tabla con los espacios de tabla se presenta la lista de comandos detalles. Las modificaciones introducidas por la memoria de sintonización automática auto está en el sistema de archivos con el nombre stmm. #. Registro en el directorio stmmlog. Este directorio se encuentra en el directorio sqllib para el propietario de la instancia en Linux y UNIX, en el directorio sqllib \ Instancia en Windows.

Asegúrese de que haya suficiente memoria libre

Otra cosa importante tener en cuenta en el servidor es el uso de memoria de DB2 y el servidor. En Windows, puede determinar la cantidad de RAM en el servidor al abrir Mi PC y seleccionando Ayuda y Acerca de Windows.

En UNIX y Linux, el comando free muestra la cantidad de memoria real (RAM) en el sistema, y cuánto está actualmente en uso y disponible. En el caso, por debajo hay 1 GB de memoria real

en este servidor, y aproximadamente 717MB se asigna a las aplicaciones. total used free shared buffers cachedMem: 1036248 717240 319008 0 60200 430736-/+ buffers/cache: 226304 809944Swap: 1048784 0 1048784

Estudio de DB2

Nada es más valioso a largo plazo que un DBA, que tiene amplia experiencia, y tan ampliamente leído como sea posible. Este estudio debería incluir manuales de DBA, revistas, grupos de noticias y listas de correo.

El comp.databases.ibm-db2 grupo de noticias es un gran lugar para aprender y compartir información con, su DBA compañeros.

Para obtener información más detallada también debe buscar nuestra Guía de Certificación de DB2 serie, ya que estos libros son muy informativos.

Semanal de los procedimientos

Puedes buscar nuevos objetos

Es importante saber si las personas están creando nuevas tablas, índices, procedimientos almacenados, etc en su base de datos de producción. Nuevos objetos generalmente indican que una nueva aplicación se ha instalado en el servidor y las aplicaciones nuevas y / o objetos afectará las características operacionales del sistema.

Además, los nuevos objetos que ocupan espacio en la base de datos, por lo que es importante identificar estos objetos antes de que crezcan demasiado grande y, potencialmente, podría llenar un espacio de tabla. Si estos objetos no son creados por un DBA, que muy probablemente pueden haber sido creados en el espacio de tablas mal, que puede causar el espacio y / o problemas de rendimiento.

Hay pocas alternativas disponibles para comprobar si hay nuevos objetos en el sistema:

Db2look Ejecutar y escribir el informe en un archivo de todas las semanas. Compruebe si hay diferencias entre la nueva salida y la salida de la semana anterior. Seleccione los nombres de objeto de SYSCAT.TABLES, SYSCAT.INDEXES, SYSCAT.PROCEDURES Compruebe si hay diferencias entre la nueva salida y la salida de la semana anterior. Para cualquier diferencia, a determinar el creador del objeto de la tabla de catálogo y seguimiento de la información a la persona que creó el objeto.

Sintaxis: db2look DBName-d [e] [x] [-xDir rutaDeAcceso] [u-Creador] [-z esquema]                           [-T Tname1 Tname2 TnameN ...] [tname-tw] [-h]                           [-O Fname] [-a] [-m] [-c] [-r] [-l] [x] [xD] [-f]                           [Fd] [td-x] [-noview] [-i ID de usuario] [-w contraseña]                           [V Vname1 Vname2 ... VnameN] [dp]] ct [                           [-Wrapper WrapperName] [servidor nombreDeServidor] [nofed]

        db2look [-h]

        -D: Nombre de base de datos: Esto debe ser especificado

        -E: Extracto DDL archivo necesario para duplicar la base de datos        -X: objetos de exportación XSR y generar una secuencia de comandos que contiene instrucciones DDL      -XDir: nombre de Ruta de acceso: el directorio en el que los objetos XSR se colocará         -U: Creador ID: u Si-y-uno no se especifica a continuación, tanto $ USUARIO será u sed         -Z: Nombre de esquema: Si-z y-a son los especificados a continuación,-z se tendrá en cuenta

        -T: Generar estadísticas de las tablas especificadas        -TW: Generar DDL para tablas cuyos nombres coinciden con los criterios de patrones (Wil dcard caracteres) del nombre de la tabla         -H: mensaje de ayuda más detallada         -O: Redirige la salida al nombre de archivo dado         -A: Generar estadísticas para todos los creadores         -M: Ejecute la utilidad db2look en imitar el modo de             -C: No genera COMMIT para imitar             -R: No genera estados RUNSTATS para imitar         -L: Generar bases de datos de diseño: los grupos de base de datos de la partición, y Bufferpools  Espacios de tabla         -X: Generar DDL declaraciones sin autorización del definidor original  del objeto        -Xd: Generar DDL declaraciones de autorización como el definidor de la original  del objeto         -F: Extracto de los parámetros de configuración y variables de entorno        -Td: Especifica x como delimitador de sentencias (por defecto es un punto y coma (;))         -I: ID de usuario para iniciar sesión en el servidor donde reside la base de datos         -W: Contraseña para iniciar sesión en el servidor donde reside la base de datos

   -Noview: No genera CREATE VIEW declaraciones ddl   -Wrapper: Genera DDL para objetos federados que se aplican a este contenedor    -Servidor: Genera DDL para objetos federados que se aplican a este servidor     -Nofed: No genera Federados DDL        -FD: Genera declaraciones db2fopt para opt_buffpage y opt_sortheap a lo largo de  cfg con otros parámetros y env.         -V: Generar DDL para ver sólo, esta opción se omite al-t es específico IED        -DP: Generar instrucción DROP antes de sentencia CREATE        -CT: Generar DDL por el tiempo de creación de objetos

Puedes buscar aplicaciones nuevas o modificadas

Una vez que ha optimizado su base de datos basada en su carga de trabajo actual, no hay nada más frustrante que recibir una llamada que la base de datos no está funcionando bien, y la constatación de que el rendimiento fue causado por una nueva aplicación, o cambios en las aplicaciones existentes que nadie le dijo a usted acerca de. Por desgracia, esto sucede con demasiada frecuencia. Mediante el control de su base de datos para las nuevas aplicaciones y / o modificados que se espera que puedan detectar estos cambios antes de que causen problemas de rendimiento.

Para buscar nuevas aplicaciones que pueden utilizar las aplicaciones de la lista comando show detalles. Si redirigir la salida de este comando a un archivo y guardar estos archivos por un período de tiempo, usted puede comparar los archivos de cada semana para ver si un nuevo nombre de la aplicación aparece de repente en la salida.

Para buscar aplicaciones cambios que usted puede ver lo que SQL se está ejecutando en el sistema con el tiempo, y buscar nuevas SQL que no se ha ejecutado con anterioridad. Para hacer esto usted puede crear una tabla de la siguiente manera:

create table SQLstmts (stmt varchar(200), tstamp timestamp not null with default)

A continuación, puede recuperar las sentencias SQL del caché de paquete actual e insertarlos en una tabla para el análisis con la siguiente declaración:

insert into SQlstmts (stmt) select substr(stmt_text,1,200) as SQL_Stmt from table (snapshot_dyn_sql ('sample', -1) ) as snapshot_dyn_sql

A continuación, puede examinar esta tabla por cualquier declaración SQL que no se han ejecutado con anterioridad mediante la instrucción:

select distinct stmt, count(stmt), tstamp from sqlstmts group by stmt, tstamp

En la salida de esta declaración, una declaración con una cuenta de 1, y la columna de fecha y hora que indique la fecha actual es que no se ha ejecutado con anterioridad.

Puedes buscar tablas y / o índices que necesitan REORG

Al insertar, actualizar y eliminar filas en las tablas, los datos en las tablas puede ser necesario REORGed a:

Re-grupo de los datos en el orden de su índice más importante Quitar espacio libre intercaladas en la tabla Eliminar registros de desbordamiento

La herramienta reorgchk revisará sus cuadros e indicar las tablas que puede ser necesario reorged. Puede ejecutar la herramienta reorgchk contra una sola tabla, todas las tablas de usuario, todas las tablas de un esquema concreto, o todas las tablas de catálogo del sistema. También puede indicar si la herramienta debe utilizar las estadísticas actuales en las tablas del catálogo de base, o reunir las nuevas estadísticas en primer lugar.

Para ejecutar la herramienta reorgchk en contra de todas las tablas, y asegurarse de que está utilizando las estadísticas actuales, utilice el comando:

reorgchk update statistics on table user

Debe redirigir la salida de este comando a un archivo para su posterior análisis.

Al ver la salida de la herramienta reorgchk, y encuentra las columnas F1, F2 y F3 para las tablas, y la F4, F5, F6, F7 y F8 columnas de los índices. Si hay un asterisco (*) en cualquiera de estas columnas, que indica que DB2 ha calculado que la tabla actual y / o los índices de incumplimiento en la actualidad de ese umbral.

Es importante señalar que para las tablas, si usted ve un asterisco en cualquiera de las columnas, a continuación, normalmente se necesita reorg la mesa. Sin embargo, las tablas, ya que muchos tienen más de un índice, por definición, si uno de ellos es de 100% en clúster, los otros índices no se agrupan. Por lo tanto, es necesario seguir investigando la parte de índice de la producción reorgchk con más detalle y considerar todos los índices de la tabla para determinar si procede o no reorg el índice.

Los cálculos para las medidas utilizadas por reorgchk son:

F1: el porcentaje de filas que son registros de desbordamiento. Cuando ésta es superior a 5%, habrá un asterisco (*) en la columna de F1 de la salida.

F2: el porcentaje de espacio utilizado en las páginas de datos. Cuando se trata de menos del 70% habrá un asterisco (*) en la columna F2 de la salida.

F3: el porcentaje de páginas que contienen datos que contienen algunos registros. Cuando este sea inferior al 80% habrá un asterisco (*) en la columna F3 de la salida.

F4: la relación de grupo, es decir, el porcentaje de filas en la tabla que se encuentran en el mismo orden en el índice. Cuando este sea inferior al 80% habrá un asterisco (*) en la columna F4 de la salida.

F5: el porcentaje de espacio que se utiliza en cada página de índice que se utiliza para las claves de índice. Cuando se trata de menos del 50% habrá un asterisco (*) en la columna F6 de la salida.

F6: el número de claves que se pueden almacenar en cada nivel del índice. Cuando se trata de menos de 100 habrá un asterisco (*) en la columna F6 de la salida.

F7: el porcentaje de ID de registros (claves) en una página que se han marcado como eliminado. Cuando se trata de más del 20% habrá un asterisco (*) en la columna de F7 de la salida.

F8: el porcentaje de páginas vacías de la hoja en el índice. Cuando se trata de más del 20% habrá un asterisco (*) en la columna de la F8 de la salida.

Cuando la reorganización de una tabla si lo desea, puede especificar que el índice de DB2 que debe agrupar los datos. Para reorg la tabla ORG basado en el índice ORGX, utilice el comando

reorg table org index orgx

Para capturar las estadísticas de la tabla ORG, y sus índices se puede utilizar el comando

runstats on table <schema>.org with distribution and detailed indexes allNOTA: Debe especificar el esquema de la tabla cuando se utiliza el comando runstats.

Puedes buscar tablas e índices que necesitan RUNSTATS

Usted puede comprobar que no existen tablas o índices, sin estadísticas, o con las estadísticas que son más de 7 días de edad con las siguientes declaraciones:

select substr(name,1,30),substr(creator,1,10),stats_time from sysibm.systables where stats_time < ((current timestamp) - 7 days) or stats_time is null

select substr(name,1,30),substr(creator,1,10),stats_time from sysibm.sysindexes where stats_time < ((current timestamp) - 7 days) or stats_time is null

Busque el 10 mesas más activos

Al considerar que las tablas para ejecutar reorg o runstats en usted también debe considerar la actividad en las tablas. Para encontrar las 10 mesas leer, en función del número de filas que leer, usar la siguiente declaración:

select substr(table_schema,1,10) as tbschema, substr(table_name,1,30) as tbname, rows_read, rows_written, overflow_accesses, page_reorgs from table (SNAPSHOT_TABLE(' ',-1)) as snapshot_table order by rows_read desc fetch first 10 rows only

Para encontrar las 10 tablas actualizadas, basadas en el número de registros escritos, utilice la siguiente declaración:

select substr(table_schema,1,10) as tbschema, substr(table_name,1,30) as tbname, rows_read, rows_written, overflow_accesses, page_reorgs from table (SNAPSHOT_TABLE(' ',-1)) as snapshot_table order by rows_written desc fetch first 10 rows only

Estas tablas también son posibles candidatos por lo menos un runstats si no, un reorg y runstats uno.

Archivar todos los registros de alertas y archivos db2diag.log

Es una buena práctica para limpiar los registros de diagnóstico sobre una base regular. En el caso de un error se produce, a continuación, no hace falta ir más de 6 meses a partir de la información en los registros, y los registros son mucho más pequeños y más fáciles de editar. Antes de purgar los archivos, haga una copia de ellos en caso de que quiera volver en algún momento en el futuro para investigar lo que estaba ocurriendo en el sistema en un momento dado.

En Windows, puede guardar el registro de eventos a otro archivo en el visor de sucesos, seleccione el menú Acción y, a continuación, elegir la opción Guardar archivo de registro como opción. A continuación, puede purgar las entradas del registro, seleccione el menú Acción y, a continuación, elegir la opción Borrar todos los eventos.

NOTA: Es una buena práctica para el nombre del archivo con la fecha actual para que sea más fácil mirar hacia atrás en los archivos en una fecha posterior.

Para el archivo db2diag.log así como la notificación de la administración del archivo de registro en Linux y UNIX, debe comprimir estos archivos, a continuación, y el nombre con la fecha actual en el nombre del archivo también.

En Linux o UNIX, puede tar la PNP y los archivos *. db2diag.log juntos, y luego utilizar gzip o comprimir para reducir el tamaño del archivo resultante.

Compruebe si hay actualizaciones de software

Siempre es bueno saber si hay actualizaciones para el software que está ejecutando. Si el sistema está funcionando sin problemas, es posible que no desee aplicar todo el servicio a su servidor. Al leer la información acerca de las correcciones contenidas en el Service Pack FixPak /, usted puede tomar una decisión más informada sobre si desea o no aplicar el fixpack. Si encuentra problemas, se puede ver en las descripciones de fijar para ver si una de las soluciones disponibles podría ser la solución a sus problemas.

Desde el punto de vista de DB2, el sitio web más importante es el de DB2 para Linux, UNIX y Windows Soporte Técnico de la página:

http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/download.d2w/WINV8FP

Una manera de estar seguro de que saber cuando un FixPak se disponga de nueva es suscribirse a alertas de DB2 en este sitio:

http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/db2alert.d2w/report

procedimientos mensuales

Puedes buscar los indicadores de crecimiento excepcional

Revisión de las tablas y los espacios de tabla para ver cuánto han crecido en el último mes. Al conocer la rapidez con las tablas y los espacios de tabla están creciendo, y cuánto espacio está disponible, puede detectar posibles problemas de espacio antes de que sucedan.

Puede recuperar el tamaño del espacio de tabla y la cantidad de espacio disponible mediante la instrucción a continuación.

select substr(tablespace_name,1,120) as TBSPC_NAME, used_pages, free_pages, from table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg

Usted puede ver lo grande que cada uno de sus cuadros es mirar las tablas de catálogo del sistema. Mientras que las estadísticas estén al día, esta información será exacta. Para obtener el tamaño de las tablas de utilizar la instrucción

select tabname, npages from syscat.tables where tabname not like 'SYS%'

NOTA: Si las estadísticas no han sido capturados por una mesa, que tendrá un valor de -1 para npages.

Crear una tabla de la historia o una hoja de cálculo para almacenar esta información para que pueda examinar el uso del espacio para sus mesas y espacios de tabla con el tiempo. Una manera fácil de hacer esto es crear una declaración de exportación con los estados por encima de seleccionar y crear un delimted ASCII (DEL) archivo que luego se pueden importar directamente en una hoja de cálculo.

Proyecto de futuro basado en el desempeño en el crecimiento proyectado

Compara la información que ha sido recogida en la CPU de nivel de sistema, memoria, red y la utilización del disco, así como la información del objeto de DB2 que se han estado reuniendo, para identificar las tendencias que podrían llevar a la afirmación o la falta de alguno de estos recursos en el futuro.

Con base en su análisis de la información anterior, usted puede planear para estas situaciones antes de que sucedan y tomar medidas para evitar que estas situaciones se produzcan.

Los apéndices siguientes contienen scripts útiles que pueden ser utilizados para monitorear el sistema y base de datos. Tenga en cuenta que estos guiones fueron escritos en los archivos que se llevaron a cabo utilizando el CLP, y por lo tanto contienen comentarios. Los comentarios están precedidos por los guiones dobles (-) y necesitan ser removidos si está ejecutando estos comandos directamente en la línea de comandos.

Apéndice 1: plaza de la tabla secuencia de comandos de información

- Crear la tabla denominada tablespaceinfo para almacenar la información de las instantáneas de espacio de tablas para el análisis.

create table TablespaceInfo( timestmp timestamp, tablespace_name char(128), pct_free int, -- Percent of space free in the table space type char(5), -- SMS or DMS contents char(5), total_pages int, -- total # of pages usable_pages int, -- useable pages, total - tag, etc.. used_pages int, -- # of pages used free_pages int, -- # of free pages page_size int); -- page size

Introduzca la información de instantáneas en la tabla tablespaceinfo a guardar para el análisis

insert into tablespaceinfo select current timestamp, substr(tablespace_name,1,120) as TBSPC_NAME, (case -- We can calculate pct free for DMS table spaces only as total_pages is set to 0 for SMS by this stmt... -- Therefore, check if DMS, and then calculate pct_free as 1- (used/total) * 100% when tablespace_type = 0 then (int( (1- (decimal(used_pages) / decimal(total_pages))) * 100) ) -- For SMS set pct_free to 100... Could set to any numeric value. else 100 end) as pct_free, (case -- Display the table space type, i.e. DMS or SMS as a string, not the numeric value in the info. when tablespace_type = 0 then 'DMS' when tablespace_type = 1 then 'SMS' -- Only 0 and 1 are VALID, therefore return an error for anything else. else 'Error' end) as Managed_By, (case

-- Display the type of data that can stored in the table space, i.e. TEMP, LARGE/LOB OR ALL, not the numeric value in the info. when tbs_contents_type = 2 then 'TEMP' when tbs_contents_type = 1 then 'LARGE' when tbs_contents_type = 0 then 'ALL' end) as Data_Type, -- Also return the total_pages using the heading ALLOCATED PAGES, total_pages as allocated_pages, usable_pages, used_pages, free_pages, page_size from table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg order by pct_free; select tablespace_name, date(timestmp) as dte, pct_free from tablespaceinfo group by tablespace_name, pct_free, timestmp ;

Apéndice 2: plaza de la tabla de contenedores secuencia de comandos de información

- Informe de los contenedores, su tamaño y el tipo asociado a cada espacio de tablas

- Grupo de tablespace_name para obtener todos los contenedores de un espacio de tabla, junto - Como los contenedores será único en este informe.

- Establecer el nombre de base de datos en NULL para obtener información sobre la actualidad relacionada - Base de datos.

select substr(tablespace_name,1,12) as TBSPC_Name, substr(Container_name,1,67) as Cont_Name, (case when container_type = 0 then 'SMS Directory' when container_type = 6 then 'DMS File' else 'DMS Device' end) as Container_Type, usable_pages from table (snapshot_container (' ', -1) ) as snapshot_container;

Apéndice 3: piscina tampón - Información sobre el espacio de tabla

- Informe sobre el nombre de grupo de búfer y el tamaño junto con el tamaño y el nombre de cada espacio de tabla - Asignado al búferes. Esto puede ser usado para ayudar a Bufferpools el tamaño de la forma más adecuada .- - Grupo de bpname primero en conseguir todos los espacios de tabla para un conjunto de búferes en los espacios de tabla - Será único en este informe.

select substr(b.bpname,1,12) as BufferPool, b.npages as BP_Pages, substr(t.tbspace,1,12) as TableSpace, usable_pages as TBSPC_Pages from table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg ,

syscat.tablespaces t, syscat.bufferpools b where t.bufferpoolid = b.bufferpoolid and t.tbspace = tablespace_name group by b.bpname, t.tbspace, usable_pages, npages;