Para DBA’s que provengan del mundo Oracle, a partir de la versión 9.7, el motor de DB2 ofrece un modo de compatibilidad que permite usar el CLP PLUS (Command Line Processor Plus) con las mismas sentencias que Oracle.

En este artículo se habla de esta interesante capacidad para hacer menos pesado el uso de DB2 si eres un Oracle DBA convencido.

El primer paso para utilizar esta sentencia en DB2 es dar el valor apropiado a la variable de entorno DB2_COMPATIBILITY_VECTOR:

db2set DB2_COMPATIBILITY_VECTOR=ORA

Después de asignar el valor deberemos reiniciar la instancia:

db2start

db2stop

La compatibilidad entre Oracle y DB2 se da en los siguientes aspectos:

PL/SQL features

• PL/SQL procedures/functions/anonymous blocks
• Built-in packages (DBMS_OUT.PUT_LINE, DBMS_PIPE, DBMS_UTL, and so on)
• User-defined packages
• Varrays
• Associative (INDEX BY) arrays
• Triggers
• Ref-Cursors
• %TYPE
• %ROWTYPE
• EXCEPTIONS

Truncate table

Otros

• Tabla Dual en vez de sysibm.sysdummy1
• ROWNUM
• Tipo DATE
• Tipo NUMBER
• Select con Outer join (+)
• Vistas de catalogo compatibles

En resumen, una opción muy interesante sobre todo al inicio de tus andanzas con DB2.

El ratio hit cache es uno de los indicadores más usados para tareas de tuning. Mide el porcentaje de aciertos en la búsqueda de datos en memoria, en concreto en la/las buffer pool.

Para obtener el ratio hit cache por cada buffer pool configurado se debe ejecutar esta query:

SELECT SUBSTR(DB_NAME,1,8) AS DB_NAME, SUBSTR(BP_NAME,1,14) AS BP_NAME,

     TOTAL_HIT_RATIO_PERCENT, DATA_HIT_RATIO_PERCENT,

     INDEX_HIT_RATIO_PERCENT

FROM SYSIBMADM.BP_HITRATIO ORDER BY DBPARTITIONNUM

Esta query muestra el ratio por cada buffer cache, separando entre el ratio que se obtiene con bloques de datos y bloques de índices.

El valor al que debe tender este ratio debe ser por encima del 90%, lo más cercano a un 100%.

A continuación comparto un ejemplo de sintaxis de un trigger en DB2.

Aunque en la documentación está más que claro, siempre va bien contar con un ejemplo concreto y típico de su utilización.

CREATE TRIGGER verificacion_datos NO CASCADE BEFORE UPDATE ON facturas

REFERENCING OLD AS O NEW AS N

FOR EACH ROW MODE DB2SQL

BEGIN ATOMIC

IF (O.FACT_NOMBRE <> N.FACT_NOMBRE) THEN

SIGNAL SQLSTATE 'Z0001' ('UPDATE CON NOMBRE DISTINTO');

END IF;

IF (O.FACT_NIF <> N.FACT_NIF) THEN

SIGNAL SQLSTATE 'Z0002' ('UPDATE CON NIF DISTINTO');

END IF;

IF (O.ID_EMPRESA <> N.ID_EMPRESA) THEN

SIGNAL SQLSTATE 'Z0003' ('UPDATE CON ID_EMPRESA DISTINTO');

END IF;

END

Es relativamente simple, y poco conocido, con la utilidad db2top.

Accediendo a la opción “T” (tablas) y ordenando la lista (pulsar “z”) e indicar que lo realice por la columna 1.

En primera posición aparecerá la tabla más accedida. Si existe mucha diferencia entre las primeras y el resto durante un periodo de tiempo apreciable de uso normal de la base de datos, esas tablas serían candidatas a intentar mejorar su acceso a ellas o intentar que sus tiempos de acceso sean óptimos para mejorar el rendimiento global.

Aunque seguro que hay otros métodos, en este pequeño artículo, una manera sencilla de conocer el puerto por el que da servicio el servidor DB2.

Obtenemos el nombre del servicio TCP/IP:

> db2 get dbm cfg | grep SVCENAME

Capturamos el resultado:

TCP/IP Service name (SVCENAME) = db2TRP

Lo buscamos en /etc/services:

> cat /etc/services | grep sapdb2QRP

db2TRP 5912/tcp # DB2 Communication Port

El puerto de escucha es el 5912.

Para conocer la versión y el nivel de parcheado actual de una instalación en DB2, qunque existen diversos métodos, el más simple es la utilización de la utilidad “db2level”, pero también puede usarse una query sobre el catálogo de datos de DB2.

Instrucción db2level: Nos proporciona información de las características generales de la instalación DB2 (path del software DB2, versión, parcheado,…)

DB21085I  Instance "db2prueba" uses "64" bits and DB2 code release "SQL09054" with level identifier "06050103".Informational tokens are "DB2 v9.5.0.4", "special_21925", "U825478_21925", and Fix Pack "4".Product is installed at "/db2/db2prueba/db2_software"

La query que permite obtener la misma información del catálogo de datos es:

SELECT * FROM TABLE (sysproc.env_get_inst_info()) as INSTANCEINFO

En DB2 es posible priorizar procesos entre los mismos procesos que tengan prioridad.

Me explico: existe un parámetro a nivel de instancia que indica el porcentaje máximo de CPU disponible para procesos priorizados (UTIL_IMPACT_LIM).

Por defecto, tiene el valor 10%. Ello implica que si varios procesos priorizados luchan entre sí por recursos de CPU, podrán obtener como máximo entre ellos un 10% de la CPU. El resto de procesos no compiten por este porcentaje de la CPU.

Las sesiones se priorizan a través del comando SET UTIL_IMPACT_PRIORITY:

SET UTIL_IMPACT_PRIORITY FOR 2344 TO 70

En el ejemplo, a la sesión con application_id 2344 se le asigna el 70% de la CPU configurada en el UTIL_IMPACT_LIM.

En el siguiente ejemplo se indica que el limite de CPU se marca en el 50% del total:

db2 UPDATE DBM CFG USING UTIL_IMPACT_LIM 50

Aplica a partir de: DB2 9.5 LUW

Suele ser habitual necesitar una réplica de una base de datos en otro entorno distinto, y además, necesitar que esa nueva base de datos tenga un nuevo nombre. Por ejemplo, para actualizar una base de datos de preproducción, realizar una copia homogénea de SAP o simplemente para cambiar el nombre de la base de datos por alguna necesidad.

La utilidad “db2relocatedb” permite realizar las siguientes funciones:

• Cambio de nombre de base de datos
• Cambio del directorio de logs
• Cambio del db_path
• Cambio de la localización de los containers y/o directorios de almacenamiento

En este artículo sólo explicaremos la primera función, aunque su implementación es realmente sencilla.

Basta con crear un fichero de configuración (chg_config.txt) con los siguientes valores:

DB_NAME=PROD,PREPROD

DB_PATH=/db2/PREPROD/sapdata1

INSTANCE=db2preprod

NODENUM=0

En cada valor, se indica inicialmente el valor antiguo y seguido de una coma el valor nuevo. En caso de que no haya cambio basta con el valor actual.

Después, con la instancia apagada (db2stop) ejecutar el db2relocatedb:

db2relocatedb -f chg_config.cfg

Así de simple….

Este mini post indica como saber cuándo fue la última vez que se reinició un servidor DB2 en un entorno UNIX/LINUX.

> db2 get snapshot for dbm | grep Start

Start Database Manager timestamp = 04/02/2011 13:45:20.516473

Sencillo, no? Espero que te sea útil

Si quieres obtener el Top Ten de sentencias SELECT con mayor tiempo de ejecución en tu base de datos DB2:

db2 "SELECT AVERAGE_EXECUTION_TIME_S as TIME_SECONDS, 

        NUM_EXECUTIONS as EXECUTIONS,

        STMT_TEXT as TEXT

        FROM SYSIBMADM.TOP_DYNAMIC_SQL

        WHERE upper(STMT_TEXT) like 'SELECT%'

       ORDER BY AVERAGE_EXECUTION_TIME_S DESC

        FETCH FIRST 10 ROWS ONLY"

SQL para obtener el top ten de SQL con más ejecuciones de mi base de datos DB2:

db2 "SELECT NUM_EXECUTIONS as EXECUTIONS,

        AVERAGE_EXECUTION_TIME_S as TIME_SECONDS,

        STMT_TEXT as TEXT  

        FROM SYSIBMADM.TOP_DYNAMIC_SQL  

        WHERE upper(STMT_TEXT) like 'SELECT%'  

        ORDER BY NUM_EXECUTIONS DESC

        FETCH FIRST 10 ROWS ONLY"

Cuando se realiza un snapshot desde una cabina de almacenamiento, en el caso de exista un servidor DB2 (o cualquier Base de Datos), no hay certeza de que el snapshot contenga una copia consistente de la base de datos.

Para poder lanzar un snapshot y asegurar la copia consistente, en DB2 existe la posibilidad de poner la base de datos en “write suspend”, esto es, se anula el acceso a disco en modo de escritura, y se trabaja en el buffer pool de memoria. Las consultas si accederán a disco, pero las escrituras se realizaran exclusivamente en memoria.

> db2 set write suspend for database

Una vez lanzado este comando, se puede realizar un snapshot sin problemas y con garantías de consistencia.

Para volver a dejar la base de datos sin “write suspend”:

> db2 set write resume for database

Aunque entraría dentro de otra discusión, para poder recuperar el snapshot se debiera usar la instrucción db2inidb:

> db2inidb database as snapshot

Cada vez conozco más entornos SAP corriendo con DB2.

Este es un video muy interesante respecto a las capacidades de DB2 con BLU Acceleration aplicadas a SAP, así como las notas SAP a considerar.

Sorprendente la comparativa con SAP HANA, y como con menor complejidad e inversión dicen obtener mayor rendimiento.

Adjunto también presentación de la Tech Talk Use DB2 with BLU Acceleration for SAP, de la que destaco las sorprendentes conclusiones de esta comparación de BD2 BLU Acceleration con SAP HANA:

Por último, adjunto también el completísimo Redbook de IBM Architecting and Deploying DB2 with BLU Acceleration.

Para parar una instancia db2 existe la instrucción db2stop, que puede ser ejecutada como comando cmd o desde sistema operativo. ¿Pero qué hacer si la BBDD no se para y deja el sistema inestable? db2_kill puede librar de muchas crisis.

Cuando hay problemas para parar una BBDD DB2, los pasos habituales suelen ser:

1)

db2stop

2)

db2 force application all + db2stop

3)

db2stop force

La primera de las opciones es la habitual para parar una instancia db2, pero ante la presencia de transacciones activas puede dar un error y no permitirte parar la instancia. Entonces se intenta parar todas las sesiones para después volver a probar el db2stop. Esta última opción es exactamente lo mismo que el db2stop force del 3er caso.

¿Pero, y si después de hacerlo la instancia no está parada pero tampoco esta en marcha? Esto es: el db2stop no funciona o indica que la instancia ya está parada, y además, el db2start dice que la instancia está en marcha.

El problema radica en que en estas circunstancias las estructuras de memoria del sistema operativo han quedado reservadas pero no se han podido liberar. Estas estructuras son la shared memory de los procesos, las colas y los messages. Estos pueden ser consultados con la instrucción ipcs (en unix).

Una solución sería ir eliminando uno a uno estas estructuras “enganchadas” hasta que todas quedaran eliminadas con ipcrm, pero es pesado, tedioso y un tanto peligroso al poder eliminar por error un semáforo de sistema y hacer caer todo el sistema.

Para realizar esta tarea existe un script llamado “db2_kill”, que elimina todas las estructuras de memoria colgadas por parte de un db2 de manera fiable.

En DB2 es posible crear columnas autoincrementales, es decir, cuyo valor en caso de no definirse en una inserción se vaya incrementando a partir de unos valores definidos. Este tipo de columnas también se pueden definir en SQL Server, y en Oracle se realiza a través de secuencias.

La mejor manera de explicarlo es con un ejemplo: a continuación se muestra la creación de una tabla con una columna autoincremental que es primary key.

Creación de la tabla ESTUDIANTES con la columna ID definida como autoincremental:

CREATE TABLE ESTUDIANTES ( 
     ID_ESTUDIANTE SMALLINT NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 500, INCREMENT BY 1), 
     NOMBRE VARCHAR(36), 
     APELLIDOS VARCHAR(80), 
     PRIMARY KEY(ID_ESTUDIANTE) )

Inserción de diversos registros sin especificar el campo:

db2 => insert into estudiantes (nombre, apellidos) values ('PEPE','SANCHEZ')

DB20000I The SQL command completed successfully.

db2 => insert into estudiantes (nombre, apellidos) values (‘JOHN’,’SMITH’)

DB20000I The SQL command completed successfully.

Seleccionamos los datos para ver los valores asignados al campo ID:

db2 => select * from estudiantes

ID_ESTUDIANTE NOMBRE APELLIDOS

——————— ———— ————–

500 PEPE SANCHEZ

501 JOHN SMITH

2 record(s) selected.

Como se puede observar se han asignado valores consecutivos a partir de 500.

A partir de la versión 9.7 de DB2, se puede conocer que índices no están siendo usados en una Base de Datos. La consulta es igualmente trasladable a tablas y packages.

DB2 proporciona así una herramienta útil para tunear los índices y detectar problemas en su uso.

La novedad que incluye la versión 9.7 es la inclusión de un nuevo campo LASTUSED en las tablas SYSCAT.INDEXES, SYSCAT.TABLES y SYSCAT.PACKAGES.

Este campo indica la fecha de último uso del índice, tabla o packages.

Por ejemplo, para consultar los índices no usados desde el 1/1/2019 se podría utilizar esta simple query:

SELECT INDSCHEMA, INDNAME, TABNAME
FROM SYSCAT.INDEXES
WHERE LASTUSED = '01/01/2019';

Espero que os sea de utilidad para eliminar índices absurdos.

En este artículo podrás consultar los estados más habituales de los tablespaces en DB2.

Estos estados pueden ser consultados de distintas formas, aunque la más habitual desde la linea de comandos en la siguiente.

db2 > list tablespaces show detail

Tablespace ID = 32

Name = JRP#DDICI2

Type = Database managed space

Contents = All permanent data. Large table space.

State = 0x0000

Detailed explanation:

Normal

Total pages = 76552

Useable pages = 76544

Used pages = 74854

Free pages = 1690

High water mark (pages) = 74854

Page size (bytes) = 16384

Extent size (pages) = 2

Prefetch size (pages) = 8

Number of containers = 4

Estados existentes tablespaces DB2:

               0x0                         Normal

               0x1                         Inmovilizado: SHARE

               0x2                         Inmovilizado: UPDATE

               0x4                         Inmovilizado: EXCLUSIVE

               0x8                         Carga pendiente

               0x10                      Supresión pendiente

               0x20                      Copia de seguridad pendiente

               0x40                      Recuperación en curso

               0x80                      Recuperación (en avance) pendiente

               0x100                    Restauración pendiente

               0x100                    Recuperación (recovery) pendiente (no se utiliza)

               0x200                    Inhabilitación pendiente

               0x400                    Reorganización en curso

               0x800                    Copia de seguridad en curso

               0x1000                  El almacenamiento debe estar definido

               0x2000                  Restauración en curso

               0x4000                  Fuera de línea y no accesible

               0x8000                  Eliminación pendiente

               0x2000000         Puede que el almacenamiento esté definido

               0x4000000         Definición de almacenamiento en estado ‘final’

               0x8000000         Defin. de almacen. cambiada antes de recup. en avan.

               0x10000000       Reequilibrador DMS activo

               0x20000000       Supresión de espacio de tablas en curso

               0x40000000       Creación de espacio de tablas en curso

               0x8                         Para uso de servicio solamente

Para realizar la exportación típica de una tabla DB2, os paso la sintaxis de manera simple y con opciones habituales (export de todos los datos de una tabla):

db2 export to destino_fichero.dmp of ixf messages fichero_mensajes.txt select * from tabla_bbdd

Aplica desde: DB2 9.5 LUW

Para dar un formato especifico a la fecha obtenida a través de DB2 mediante “current date” se puede usar el siguiente método.

Obtención de la fecha con formato de hora europeo

select CHAR(current date, EUR) from sysibm.sysdummy1

1

----------

22.03.2012

1 record(s) selected.

Obtención de la fecha con formato de hora americana

db2 => select char(current date, USA) from sysibm.sysdummy1

1
----------
03/22/2012

1 record(s) selected.

Otros formatos que pueden usarse:

USA — Usa el IBM standard para el formato de fechas y tiempos de USA.

EUR — Usa el IBM standard para Europa.

DEF — Usa el formato de fechas y tiempos asociadas al código de territorio.

ISO — Usa el formato de fechas y tiempos del International Standards Organization.

JIS — Usa el formato de fechas y tiempos del Japanese Industrial Standard.

LOC — Usa el formato de fechas y tiempos local asociada al código de territorio de la base de datos.

El catalogo de DB2 determina las BBDD gestionadas desde la instancia a la que uno se conecta.

Para listar las BBDD catalogadas por la instancia actual se puede realizar:

db2> list database directory

Para ver las BBDD existentes en un determinado database path:

db2> list database directory on /db2/BBDD

La información de las BBDD catalogadas se guarda en los ficheros:

/db2/INSTANCIA/db2INSTANCIA/NODE0000/sqldbdir

Para catalogar una determinada BBDD, se le debe pasar el database path:

CATALOG DATABASE BBDD ON /db2/INSTANCIA

Para descatalogarla:

UNCATALOG DATABASE BBDD

Aplica: DB2 9.5 LUW

DB2TOP es una herramienta muy útil en la administración de BBDDs que habitualmente se usa de manera online, pero también se puede usar para grabar la información y que pueda ser analizada cuando los teléfonos dejen de sonar y el problema haya pasado. En este artículo verás como capturar toda la información de db2top y como poder volver a verla en tiempo real de nuevo.

¿Cómo capturar la info de DB2TOP? Con la opción “-C”. Pulsar “N” para la creación de un fichero con los datos. La opción “-m” sirve para indicar el número de minutos a recolectar, si tienes problemas de espacio.

defidb2:db2dfi 4> db2top -C -m 10

[18:20:30] Starting DB2 snapshot data collector, collection every 2 second(s), max duration unlimited, max file growth/hour 100.0M, hit to cancel...

[18:20:31] Writing to 'db2snap-DFI-AIX64.bin', should I create a named pipe instead of a file [N/y]?

En vez de por línea de comandos, puedes capturar la info desde dentro de la consola de db2top pulsando la opción “C”.

¿Cómo reproducir los datos capturados? Con la opción “-f” para indicar el fichero de datos recogidos en el paso anterior.

> db2top -f db2snap-DFI-AIX64.bin

Al reproducir los datos, puedes observar que la consola mostrada simula estar en la hora y fecha que se capturaron los datos, pudiendo navegar por todas las opciones de db2top como si estuviera en directo.

Existe adicionalmente la opción de saltar “n” segundos de reproducción indicando +n segundos como se indica a continuación:

> db2top -f db2snap-DFI-AIX64.bin +50

DB2TOP es una utilidad que permite además tener una visión rápida de distintas características de rendimiento de una BBDD DB2.

Permite entre otros conocer características de la memoria, cpu, sesiones, bufferpools, deadlocks, fecha de último backup, status de la BBDD, etc, etc… Con lo que puede ser muy útil si no sabes como obtenerlo con otras utilidades y/o en base a querys.

Para entornos Windows no está disponible, pero se puede catalogar la BBDD en un sistema UNIX para poder acceder al db2top para Windows.

Este artículo muestra cómo obtener con una query el historial de versiones de DB2 y sus parcheos.

Es decir, no sólo muestra la versión actual, sino desde cuando está instalada/actualizada, incluyendo todas la versiones/parches anteriores.

select versionnumber, version_timestamp

from sysibm.sysversions

El resultado de la query nos muestra el historial de versiones/parches de la instalación:

VERSIONNUMBER VERSION_TIMESTAMP
------------- --------------------------
9050000 2009-09-18-13.06.42.998615
9050300 2010-03-21-21.58.42.326805
9070300 2011-03-07-09.21.03.802135

IBM [InfoSphere] Optim Database Administrator (antes conocido como IBM Data Studio Administrator) proporciona un entorno de gestión del ciclo de cambios de un entorno de Bases de Datos para facilitar el trabajo entre desarrolladores, arquitectos y Administradores de Base de Datos.

La Gestión del Cambio en entornos de Bases de Datos complejos con participación de distintos equipos en generación constante de cambios, conlleva la necesidad de una herramienta para gestionarlos para poner orden, coherencia y seguridad en los cambios que se implementan y permitir mejorar la productividad.

IBM Optim database administrator

IBM Optim Database Administrator permite, entre otros:

• Modelar, automatizar e implementar cambios complejos en schemas de Bases de Datos
• Garantizar la seguridad de los datos, dependencias de objetos y aplicaciones
• Mejorar la colaboración entre DBAs, Arquitectos y Desarrolladores
• Reducir el riesgo de downtime determinando el impacto de los cambios antes de aplicarlos
• En caso de problemas en los cambios aplicados, permite dar marcha atrás de manera rápida.
• Mantiene un histórico de cambios introducidos en una Base de Datos

Es una herramienta con coste, se puede descargar una trial desde IBM para probarla con toda la funcionalidad durante 30 días.

Las opciones principales nos dan una idea de la potencia en distintos ámbitos que tiene la herramienta:

• DISEÑO
  • View a Diagram of database objects
  • Reverse engineer a database to a model
• DESARROLLO
  • Create and run SQL or XQuery statements
  • Create a stored procedurel
  • Debug stored procedure and UDFs
• ADMINISTRACIÓN
  • Connect and browse a Database
  • Create and run a script
  • Create, alter o drop database objects
  •  Create change scripts for multiple objects Migrate using copy and paste
  • Migrate using the compare editor
  • Grant or revoke security privileges
     
• TUNING
  • Visualize explain / access plans
• MONITOR
  • View a health summary
  • View alerts list
  • View application connections
  • View table space storage usage

Recomendada para entornos complejos y/o con muchos equipos involucrados y con poder de decisión sobre los cambios a aplicar.

La versión gratuita de DB2 (DB2 Community Edition, que sustituye a DB2 Express-C) tiene mucho menos limitaciones que las existentes en Oracle y SQL Server: Oracle 18c Express Edition y SQL Server 2017 Express.

En este artículo se muestra está ventaja que se obtiene con IBM DB2 Community Edition en comparación con sus rivales.

Como se puede observar DB2 Community Edition ofrece el menor número de limitaciones, y puede ser una buena opción para soluciones productivas sin gran necesidad de recursos.

Mediante el uso de la tabla sysdummy1 se pueden consultar distintos datos de un servidor con DB2.

La siguiente query muestra como obtener el nombre del servidor DB2 al que se está conectado:

SELECT CURRENT SERVER

FROM SYSIBM.SYSDUMMY1

A partir de la información de las instantáneas, se puede obtener el tamaño de las tablas en DB2 (datos, longs, lobs) y de todos sus indices.

db2 "select * from table (SNAP_GET_TAB('BBDD',-1)) as aaa" > /tmp/space.txt

El fichero resultante contiene cuatro columnas que dan la información del tamaño que ocupa la BBDD:

• DATA_OBJECT_PAGES
• INDEX_OBJECT_PAGES
• LOB_OBJECT_PAGES
• LONG_OBJECT_PAGES

Los datos están en bloques, por lo que, para calcular el tamaño total de una tabla con todos sus índices, bastará con multiplicarlo por el tamaño del bloque (habitualmente 16Kb).

Aplica a partir de: DB2 9.5 LUW

La utilidad db2 command line tiene una serie de opciones por defecto. En este artículo mostraremos como eliminar el autocommit de las sentencias DML que por defecto está activado. En el caso de querer hacer alguna prueba, por ejemplo, simulando bloqueos o uso de logs puede ser útil eliminar esta característica, que está por defecto, para evitar que una sesión sin commit haga que usemos un número de logs activos superior al necesario.

Las opciones activas del DB2 command line se pueden obtener con las siguientes instrucciones:

db2 => ? options

db2 [option ...] [db2-command | sql-statement |

[? [phrase | message | sqlstate | class-code]]]

option: -a, -c, -d, -e{c|s}, -finfile, -i, -lhistfile, -m, -n, -o,

-p, -q, -rreport, -s, -t, -td;, -v, -w, -x, -zoutputfile.

Option Description Default Setting

------ ---------------------------------------- ---------------

-a Display SQLCA OFF

-c Auto-commit ON

-d Retrieve and display XML declarations OFF

-e Display SQLCODE/SQLSTATE OFF

-f Read from input file OFF

......

-x Suppress printing of column headings OFF

-z Save all output to output file OFF

db2 => LIST COMMAND OPTIONS

Command Line Processor Option Settings


Backend process wait time (seconds) (DB2BQTIME) = 1

No. of retries to connect to backend (DB2BQTRY) = 60

Request queue wait time (seconds) (DB2RQTIME) = 5

Input queue wait time (seconds) (DB2IQTIME) = 5

Command options (DB2OPTIONS) =


Option Description Current Setting

------ ----------------------------------------        ---------------

-a Display SQLCA OFF

-c Auto-Commit ON

-d Retrieve and display XML declarations OFF

-e Display SQLCODE/SQLSTATE OFF

-f Read from input file OFF

........

-x Suppress printing of column headings OFF

-z Save all output to output file OFF

Mientras que la primera sólo muestra la información de la sintaxis y opciones existentes con sus valores por defecto (atención! no valores actuales), la segunda muestra los valores actuales en vigor.

Las opciones por defecto se pueden determinar con la variable de entorno DB2OPTIONS, indicando con un ‘+’ o con un ‘-‘ la activación o no de esta opción.

Los métodos para cambiar una opción existente son:

1. Desde la llamada al DB2 command line utilizando las opciones como argumento:

> db2 +c

2. Con el comando UPDATE COMMAND en cualquier momento. Por ejemplo, para eliminar la característica de AUTOCOMMIT seria:

db2 => UPDATE COMMAND OPTIONS USING c OFF

DB20000I The UPDATE COMMAND OPTIONS command completed successfully.

En el siguiente artículo se muestran ejemplos sencillos sobre cómo operar con fechas en DB2 desde sentencias SELECT de SQL.

Suma de 8 años a la fecha actual

select current date + 8 YEAR 
from sysibm.sysdummy1

Sumas y restas en un ejemplo absurdo

select current date + 3 YEARS + 2 MONTHS - 15 DAYS + 10 SECONDS 
from sysibm.sysdummy1

Días desde el 22/10/2010

select days (current date) - days (date('2010-10-22')) 
from sysibm.sysdummy1

En este artículo muestro un método para ver los índices no-usados de nuestra base de datos desde el último reinicio.

Ya traté este tema en el artículo Detección de índices, tablas y packages no usados en DB2 9.7, pero dicho artículo utiliza la columna LASTCOLUMN incluida en la versión 9.7. Si tienes otra versión, o incluso la 9.7, este artículo te permitirá conocer que índices no están siendo usados, con el desperdicio de recursos que conlleva.

La utilidad “DB2 Problem Determination” o db2pd para los conocidos, permite entre muchísimas otras cosas, la obtención de la información que buscamos mediante las siguientes opciones:

> db2pd -db TRP -tcbstats index

La información retornada se estructura en 4 apartados:

TCB Table Information:

Address TbspaceID TableID PartID MasterTbs MasterTab TableName SchemaNm

ObjClass DataSize LfSize LobSize XMLSize

0x0700000050A88BD8 32 2640 n/a 32 2640 CRMPAROLTP SAPTRP Perm 1 0 0 0

0x0700000052138358 32 9127 n/a 32 9127 T5ES4 SAPTRP Perm 1 0 0 0

TCB Table Stats:

....

....


TCB Index Information:

....

....


TCB Index Stats:

Address TableName IID PartID EmpPgDel RootSplits BndrySplts PseuEmptPg

EmPgMkdUsd Scans IxOnlyScns KeyUpdates InclUpdats NonBndSp

ts PgAllocs Merges PseuDels DelClean IntNodSpl

0x070000005F7F58D0 CRMPAROLTP 1 n/a 0 0 0 0 0 1 0 0 0 0

0 0 0 0 0

0x0700000052138DD0 T5ES4 1 n/a 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0

0x07000000401A9B50 A746 1 n/a 0 0 0 0 0 273 0 0 0 0

0 0 0 0 0

0

La que nos interesa en este artículo, es el último apartado “TCB Index Stats”, y en concreto la columna “Scans”, que nos indica el número de usos de dicho indice.

No hace falta decir, que si la columna Scans está a 0, el índice es candidato a ser eliminado o a estudiar el porqué de su falta de uso.
 

Durante la instalación de un fixpatch o cualquier otra aplicación que requiera tener parado los procesos de DB2, se obtiene un error indicando que existe un proceso db2fmd que está en marcha.

Al intentar matar el proceso, se arranca de manera automática constantemente. Si se reinicia el servidor, ocurre lo mismo.

La solución pasa por comentar la línea siguiente del fichero /etc/inittab y reiniciar el servidor.

fmc:2345:respawn:/opt/IBM/db2/V8.1/bin/db2fmcd #DB2 Fault Monitor Coordinator

Para realizar un estudio de tuning es util la la creación de snapshots para capturar información de distintas estructuras/componentes de la instancia de base de datos.

En este articulo mostramos como se pueden utilizan para realizar un análisis de tuning.

Lo primero de todo, es tener activos los monitor switches que van recolectando datos de las distintas estructuras.

El estado de los monitores se pueden consultar de este modo:

db2pqr 2> db2 -v get monitor switches

Monitor Recording Switches


Switch list for db partition number 0


Buffer Pool Activity (BUFFERPOOL) = ON 01/19/2012 18:10:56.183312

Lock Information (LOCK) = ON 01/19/2012 18:10:56.183312

Sorting Information (SORT) = ON 01/19/2012 18:10:56.183312

SQL Statement Information (STATEMENT) = ON 01/19/2012 18:10:56.183312

Table Activity Information (TABLE) = ON 01/19/2012 18:10:56.183312

Take Timestamp Information (TIMESTAMP) = ON 01/19/2012 18:10:56.183312

Unit of Work Information (UOW) = ON 01/19/2012 18:10:56.183312

En caso de que esten desactivados, se pueden activar mediante la sentencia “update monitor switches”, o a través de “update dbm config”:db2 -v update monitor switches using bufferpool on

db2 -v update monitor switches using lock on

db2 -v update monitor switches using sort on

db2 -v update monitor switches using statement on

db2 -v update monitor switches using table on

db2 -v update monitor switches using timestamp on

db2 -v update monitor switches using UOW on

Una manera de realizar un estudio de tuning podría consistir en:

1. Verificar estado monitores

2. Reset de todas las métricas

3. Lanzamiento de los procesos/querys que se quieran estudiar, o simplemente el trabajo normal de la base de datos

4. Lanzamiento de los snapshots apropiados

Reset de todas las métricas:

db2 -v reset monitor all

Lanzamiento de los distintos tipos de snapshots: (habitualmente para problemas de rendimiento con los de dbm/db/bufferpool es suficiente)

Locks    
db2 get snapshot for locks on pqr

Database Manager         
db2 get snapshot for dbm

Database            
db2 get snapshot for database on pqr

Tablespace         
db2 get snapshot for tablespaces on pqr

Bufferpool         
db2 get snapshot for bufferpools on pqr

Applicationes    
db2 get snapshot for applications on pqr

Dynamic SQL     
db2 get snapshot for dynamic sql on pqr

Tablas   
db2 get snapshot for tables on pqr

En este artículo veremos como obtener los N primeros resgistros de una Query en DB2.

Lo que en Oracle se puede hacer con ROWNUM y en SQL Server con TOP.

La forma de realizarlo es la siguiente:

select *

from MI_TABLA

fetch first 10 rows only

Si vienes del mundo Oracle, sabrás que existe una tabla “ficticia” llamada DUAL que sirve para operaciones auxiliares, pero en algún caso muy importantes. En DB2 esta tabla es se llama sysibm.sysdummy1.

La tabla sysibm.sysdummy1 igual que su homologa de Oracle, tiene un único registro, y permite realizar operaciones del estilo:

db2> select current date from sysibm.sysdummy1

22/12/2010

Como curiosidad notad que la columna de la tabla DUAL en Oracle se llama DUMMY (tonto), similar al nombre de la tabla en DB2.

A través de DB2 se pueden obtener los tiempos medios en ms de acceso a disco que está teniendo DB2. Estos tiempos son determinantes para la detección de un problema de IO en los discos que tienen los datos de DB2.

Habitualmente se tiene en consideración que un valor cercano a 2-3ms es bueno, más allá de 10ms puede estar indicando problemas.

Promedio milisegundos/escritura (avg ms/write):

select trunc(decimal(sum(pool_write_time))/decimal(

(sum(pool_data_writes)+sum(pool_index_writes))),3)

from sysibmadm.snaptbsp

Promedio milisegundos/lectura (avg ms/read)

select trunc(decimal(sum(pool_read_time))/decimal(

(sum(pool_data_p_reads)+sum(pool_index_p_reads))),3)

from sysibmadm.snaptbsp

Para obtener valores, debes tener activados los monitores a nivel de IBM DB2. Los puedes consultar mediante la intrucción “get monitor switches”.

Con la versión 9.7 de DB2 LUW, IBM hace un guiño a todos los DBA’s de Oracle, mucho más

numerosos en el mercado que los de DB2.

Para ello, en la versión 9.7 ha introducido modos de compatibilidad de Oracle que permiten

realizar tareas en DB2 con la facilidad y conocimiento que todos los DBA’s de Oracle tienen. Sin

embargo, es importante conocer la traslación de terminología entre Oracle y DB2 si tienes la

intención de meterte en el mundo DB2.

En este primer artículo, relaciono una serie de elementos para que esa introducción sea

sencilla y se pueda leer documentación de DB2 fácilmente. Entre ellos, terminología general,

versiones, utilidades y vistas.

La utilidad db2look permite extraer la definición de los objetos de base de datos. Además, permite algo realmente interesante: extraer las estadísticas de los objetos para exportarlas a otros entornos de prueba/integración y obtener los mismos planes de acceso a los objetos.

En este artículo veremos su utilidad más frecuente.

Extracción del DDL de los objetos de mi esquema:

db2look -d MI_BBDD -a -e -x -o FICHERO_SALIDA.txt

Extración del DDL de la tabla DEPT:

db2look -d MI_BBDD -t DEPT -a -e -x -o FICHERO_SALIDA.txt

Para incluir las estadísticas se debe usar la opción “-m”.