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 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)

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:

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.

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.

En este 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..

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.

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.

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

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: