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:

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:

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

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:

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.