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.

The cache hit ratio is one of the indicators used for tuning tasks. It Measures the percentage of hits in memory, specifically in the bufferpools (each of them).

To get the cache hit ratio for each buffer pool configured to run this 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
 

This query shows the ratio for each cache buffer, separating between the ratio obtained with data blocks and index blocks.

If the value of this ratio is above 90%, it’s ok, if not: may indicate a problem with the memory size assigned to the instance.

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

 It’s relatively simple and unfamiliar tool for the novices: db2top.

Using the option “T” (tables) and sorting the list (key “z”) using column 1.

The first position will be for the most accessed table.

If there is much difference between that and the rest during an appreciable period of normal use of the database, these tables would be candidates to improve their access or optimice their access to improve the overall performance,

Maybe there are other methods, in this short article, a simple way to know the port that serves DB2 server.

We get the name of the service TCP / IP:

> db2 get dbm cfg | grep SVCENAME

Capture the result:

TCP/IP Service name (SVCENAME) = db2TRP

Look at /etc/services:

> cat /etc/services | grep sapdb2QRP

db2TRP 5912/tcp # DB2 Communication Port

The listening port is 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….

This mini tip show you how to know when was the last time you restart a DB2 server on a UNIX / LINUX.

> db2 get snapshot for dbm | grep Start

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

Simple, isn't it?

SQL Command to obtain the Top Ten of SELECT SQL sentences with more execution time in your DB2 database:

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 sentence to obtain the SQL TOP TEN with more executions of my BD2 database:

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"

When doing a snapshot from a storage array, if the server contains a DB2 instance running, there is no certainty that the snapshot contains a consistent copy of the database.

To launch a snapshot and ensure consistent copy in DB2 is possible to put the database at “write suspend”, that is, it overrides the disk access in write mode, and work in the buffer pool memory. Queries whether it will record but writes are performed only in memory.

> db2 set write suspend for database

Once launched this command, you can make a snapshot that guarantees consistency.
To return to leave the database without “write suspend”:

> db2 set write resume for database

Although it would enter into another discussion, to recover the snapshot you should use db2initdb instruction:

> db2inidb database as snapshot

Every time it’s more common SAP environments running with DB2.

Attached a video regarding the capabilities of DB2 with BLU Acceleration applied to SAP and all SAP notes to consider.

Surprising comparative with SAP HANA, and as with less complexity and investment, you get more performance.

Pay attention to the comparison with SAP HANA:

Attached also the IBM Redbook 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.

DB2, from version 9.7, allows to know easily what indexes are not being used in a Database. The query is also for tables and packages.

This is a useful tool for tuning indexes and detecting problems in their use.

After version 9.7 DB2 includes a new LASTUSED field in the SYSCAT.INDEXES, SYSCAT.TABLES and SYSCAT.PACKAGES tables.

This field indicates the date of last use of indexes, tables or packages.

For example, to query unused indexes since 1/1/2019, you could use this simple query:

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

Very useful to drop nonsense indexes.

Below are a list with the more common status of IBM DB2 tablespaces

The most used method to show the status of the tablespaces is, from the console command line:

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

DB2 tablespaces status:

               0x0                         Normal

               0x1                         Quiesced : SHARE

               0x2                         Quiesced : UPDATE

               0x4                         Quiesced : EXCLUSIVE

               0x8                        Pending load

               0x10                      Pending delete

               0x20                      Pending backup

               0x40                      Roll Forward in Progress

               0x80                      Roll Forward Pending

               0x100                    Pending restore

               0x100                    Pending recovery (don't used)

               0x200                    Pending disable

               0x400                    Reorganization in progress

               0x800                    Backup in Progress

               0x1000                  Storage Must be Defined

               0x2000                  Restore in Progress

               0x4000                  Offline and Not Accessible

               0x8000                  Drop Pending

               0x2000000         Storage May be Defined

               0x4000000         Storage definition in final 'status'

               0x8000000         Storage definition changed before recovering

               0x10000000       Active DMS

               0x20000000       Drop tables space in progress

               0x40000000       Table Space Creation in Progress

               0x8                     Only for service use

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

To give a specific format to the date obtained throught DB2 “current date”, you can use the following method.

Get date with European format

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

1

----------

22.03.2012

1 record(s) selected.

Get date with USA format

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

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

1 record(s) selected.

Others formats:

• USA - Use IBM standard for U.S. date and time format.
• EUR - Use IBM standard for Europe date and time format.
• DEF - Use date and time format associated with the territory code.
• ISO - Use date and time format of the International Standards Organization.
• JIS - Use date and time format of the Japanese Industrial Standard.
• LOC-  Use date and time format in local form associated with the territory code of the database.

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

Actually DB2TOP is a real-time tool, however many DBA’s don’t know that it can be run in REPLAY mode with captured session information. So, next time you have a big crisis with your database, you can capture all the data from db2top and do the analysis afterwards.

How to capture the data? Option -C to capture. Press N to create a file. The option “-m” to gather data during n minutes.

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]?

You can also capture data on real-time, pressing “C”.

How to replay capture data? Option -f to indicate the file with the data collection:

> db2top -f db2snap-DFI-AIX64.bin

When you replay you could see the time/date when the data was gathered, and you can use db2top options on the normal way of use. Futhermore, you can skip entries during “n” seconds indicating as it follows:

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

This article shows the query to obtain the history of DB2 versions and patching. That is, not only shows the current version, but since when is installed / updated.

select versionnumber, version_timestamp

from sysibm.sysversions

The result of the query shows the version history / patch installation:

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

Another methods to know the version and patch level of current DB2 installation is to use the utility “db2level” or by using another query over the DB2 catalog.

db2level utility: It provides information on the general characteristics of the installation DB2 (DB2 software path, version, patch,…)

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

The same information, with a query over the database catalog is:

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

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.

By using the auxiliar table sysdummy1 you can query information about a server with DB2 installed.

Next query shows how to obtain the DB2 server name where the session is connected:

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

DB2 command line utility has different options. In this post we show how to disable the autocommit of DML statements that by default is active. In case you want to do some test, for example, simulating the use of locks could be helpful to disable this feature.

Options from DB2 command line can be obtained with the following sentences:

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

While the first sentence shows only the information about the options with their default values ​​(attention! not actual values), the second one shows the active values​.

The default options can be determined by DB2OPTIONS environment variable, indicating a ‘+’ or a ‘-‘ to activate/deactivate an option.

The methods to change the value of an option are:

1. From the DB2 command line call using the option as argument:

> db2 +c

2. With the command UPDATE COMMAND at any time. For example, to disable the AUTOCOMMIT feature:

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

To tune a database is useful to create snapshots that capture information from different structures/components of the instance.

In this post we show how they can be used to perform an analysis of tuning.

First of all, the monitor switches must be on to collect data from the different structures.

The state monitors are available as follows:

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

In case they are disabled, they can be activated by the sentence “update monitor switches”, or through “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

One way to do a study of tuning may be:
1. Check status monitors
2. Reset all metrics
3. Launch the processes/querys that needs the tuning, or just the normal workload of the database
4. Capture the appropriate snapshot

Reset all metrics:

db2 -v reset monitor all

Capture of the different types of snapshots: (usually for performance problems with dbm / db / bufferpool is enought)

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

Applications    
db2 get snapshot for applications on pqr

Dynamic SQL     
db2 get snapshot for dynamic sql on pqr

Tables   
db2 get snapshot for tables on pqr

In this shosrt post we will show how to obtain the N first rows from a Query on IBM DB2.

With Oracle SQL would be with ROWNUM, and with SQL Server we'd use TOP.

This is the Top 10 query syntax:

select *

from My_Table

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.

Through DB2 we can get the average time in ms disk access is having DB2. These times are crucial for the detection of a IO problem with DB2 instance.

Usually we take into consideration that a value close to 2-3ms is good, more than 10ms can indicate problems.

Avg ms/write:

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

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

from sysibmadm.snaptbsp

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

To obtain correct values, you must have activated monitor switches, you can view the status with the sentence “get monitor switches”.

With version 9.7 of DB2 LUW, IBM winks at all Oracle DBA’s, grater in number than DB2 DBA's.

This version introduced Oracle compatibility modes that allow to perform tasks in DB2 at the 'Oracle way'. 

However, is important to know the translation of terminology between Oracle and DB2 if you have the intention to get into the DB2 world.

In this tables, I relate general terminology, versions, utilities and views from IBM DB2 and Oracle databases.

Db2look is an utility to extract the definition of database objects. It also allows some really interesting statistics to extract objects for export to other test environments / integration plans and get the same access to objects.

In this article we will see more frequent usefulness.

DDL extraction of the objects in my schema:

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

Extraction of the DDL of the DEPT table:

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

To include statistics to have to use the “-m” option.

I hope that you find it useful!