Para el Administrador de Base de Datos (ABD) que recién se inicia en el mundo de DB2 o para el futuro ABD, las opciones de diseño y rendimiento para una base de datos nueva pueden ser muy confusas. En este artículo abordaremos dos áreas en los cuales el ABD tiene que hacer elecciones importantes: espacios de tablas y grupos de buffers. El diseño y la adaptación de sus espacios de tablas y grupos de buffers pueden tener un impacto importante en el funcionamiento de su servidor DB2.
En este artículo, los ejemplos usan DB2 versión 9.7, Enterprise Server Edition. La mayoría de los ejemplos también se aplican a versiones de menor nivel, excepto que se indique lo contrario.
El artículo se aboca a:
- Definir los tipos de espacios de tablas y explicar cómo DB2 almacena datos en los espacios de tablas
- Incluir las opciones de configuración y lo guía a través del proceso de creación y administración de un espacio de tablas
- Describe los grupos de buffers, definiendo qué es un grupo de buffer y cómo crearlo y usarlo
- Sugiere qué elementos se deben tener en cuenta antes de decidir mover bases de datos
- Describe cómo se deben organizar los grupos de buffers y los espacios de tablas para maximizar el rendimiento
Aprendiendo sobre espacios de tablas
Todos los datos para una base de datos se almacenan en una cantidad de espacios de tablas. Imagínese a un espacio de tablas como si fuera un niño y la base de datos su padre, en donde el espacio de tablas (el niño) no puede tener más de una base de datos (padre). Como los espacios de tablas tienen diferentes usos, se clasifican según su uso y la forma en que se administrarán. Hay cinco espacios de tablas diferentes, nombrados según su uso:
- Espacio de tablas de catálogo
- Hay sólo un espacio de tablas de catálogo por base de datos y se crea cuando se emite el comando CREATE DATABASE (Crear base de datos). Llamado SYSCATSPACE por DB2, el espacio de tablas de catálogo contiene las tablas de catálogo del sistema. Este espacio de tablas siempre se origina al crearse la base de datos.
- Espacio de tablas común
- Un espacio de tablas común almacena todos los datos permanentes, incluyendo índices y tablas comunes. También puede contener datos grandes como LOB (objetos grandes) a menos que se almacenen explícitamente en espacios de tablas grandes. Una tabla y sus índices se pueden dividir en espacios de tablas comunes si los espacios de tabla son espacios administrados por bases de datos (Database Managed Space - DMS). Una tabla y sus índices se pueden dividir en espacios de tabla comunes separados si los espacios de tabla son espacios administrados por bases de datos(DMS) para tablas no particionadas o espacios administrados por sistema(SMS) para tablas particionadas. DMS y SMS se describen en la sección Administración de espacios de tablas. El espacio de tabla de catálogo es un ejemplo de espacio de tabla común. De manera predeterminada, el espacio de tabla de catálogo es el único espacio de tabla común que se genera durante la creación de la base de datos.
- Espacio de tabla grande
- El espacio de tabla grande almacena todos los datos permanentes así como lo hace un espacio de tabla común, incluyendo objetos LOB. Este tipo de espacio de tabla debe ser DMS que es el tipo predeterminado. Una tabla creada en un espacio de tabla grande puede ser más grande que una tabla en un espacio de tabla común. Una tabla grande puede soportar más de 255 filas por página de datos, mejorando la utilización de espacio en las páginas de datos. DB2 crea un espacio de tabla grande llamado USERSPACE1 al crear la base de datos.
- Espacio de tabla temporal de sistema
- El espacio de tabla temporal de sistema almacena datos temporales internos requeridos durante las operaciones SQL, como clasificación, reorganización de tablas, creación de índices y fusión de tablas. Debe existir por lo menos un temporal de sistema por base de datos. El espacio creado de manera predeterminada con la base de datos se llama TEMPSPACE1.
- Espacio de tabla temporal de usuario
- El espacio de tablas temporales de usuario almacena tablas temporales globales declaradas. No existen espacios de tablas temporales de usuario cuando se crea una base de datos. Se debe crear por lo menos un espacio de tabla temporal de usuario para permitir la definición de tablas temporales declaradas. Los espacios de tablas temporales de usuario son opcionales y ninguno se creará de manera predeterminada.
Administración de los espacios de tablas
Los espacios de tablas se pueden administrar de dos maneras diferentes:
- Espacio administrado por sistema (SMS)
- El sistema operativo administra los espacios de tablas SMS. Los contenedores se
definen como archivos comunes de sistema operativo y se accede a ellos mediante
llamadas al sistema operativo. Esto significa que todas las funciones comunes
del sistema operativo administrarán lo siguiente:
- La E/S será almacenada en buffer por el sistema operativo
- El espacio se asignará según las convenciones del sistema operativo
- El espacio de tablas se ampliará automáticamente cuando fuera necesario
Sin embargo, no se pueden quitar contenedores de los espacios de tablas SMS, y la posibilidad de agregar nuevos se limita a las bases de datos particionadas. Los tres espacios de tablas predeterminados que se explicaron en la sección anterior son SMS.
- Espacio administrado por base de datos (DMS)
- DB2 administra los espacios de tablas DMS. Los contenedores se pueden definir tanto como archivos (que se asignarán totalmente con el tamaño asignado al crear el espacio de tablas) o como dispositivos. DB2 administrará tantas E/S como el método de asignación y el sistema operativo lo permitan. Se puede ampliar los contenedores usando el comando ALTER TABLESPACE (Modificar espacio de tablas). Las porciones de contenedores DMS no usadas también pueden ser liberadas (a partir de la versión 8).
El Listado 1 muestra cómo aumentar los tamaños de contenedor:
Listado 1. Aumento del tamaño de contenedor
ALTER TABLESPACE TS1 RESIZE (FILE '/conts/cont0' 2000, DEVICE
'/dev/rcont1' 2000, FILE 'cont2' 2000) |
También puede usar las opciones EXTEND (Aumentar) o REDUCE (Reducir) para incrementar o disminuir el tamaño de un contenedor.
Cómo crear y ver sus espacios de tablas
Cuando usted crea una base de datos, se crearán tres espacios de tablas (SYSCATSPACE, TEMPSPACE1 y USERSPACE1). El Listado 2 le muestra cómo crear una base de datos llamada testdb, cómo conectarse a la misma y listar los espacios de tabla usando DB2 command window o la línea de comandos UNIX.
Listado 2. Creación, conexión y listado
CREATE DATABASE testdb CONNECT TO testdb LIST TABLESPACES |
El Listado 3 muestra los datos de salida del comando LIST TABLESPACES (Listar espacios de tablas).
Listado 3. Datos de salida del comando LIST TABLESPACES
Tablespaces for Current Database Tablespace ID = 0 Name = SYSCATSPACE Type = Database managed space Contents = All permanent data. Regular table space. State = 0x0000 Detailed explanation: Normal Tablespace ID = 1 Name = TEMPSPACE1 Type = System managed space Contents = System Temporary data State = 0x0000 Detailed explanation: Normal Tablespace ID = 2 Name = USERSPACE1 Type = Database managed space Contents = All permanent data. Large table space. State = 0x0000 Detailed explanation: Normal |
El comando CREATE DATABASE crea automáticamente los tres espacios de tablas en el Listado 3. El usuario puede anular la creación de espacio de tablas predeterminado incluyendo especificaciones de espacio de tabla, pero al momento de crear la base de datos se debe crear un espacio de tablas de catálogo y por lo menos uno común o uno grande y uno temporal de sistema. Se pueden crear más espacios de tablas de todo tipo (excepto espacio de tablas de catálogo) ya sea con el comando CREATE DATABASE, o posteriormente usando el comando CREATE TABLESPACE (Crear espacio de tablas).
Cada espacio de tablas tiene uno o más contenedores. Nuevamente, puede pensar en un contenedor como si fuera un niño y el espacio de tablas su padre. Cada contenedor sólo puede pertenecer a un único espacio de tablas, pero un espacio de tablas puede tener varios contenedores. Se puede agregar o eliminar contenedores en el espacio de tablas DMS y sus tamaños pueden modificarse. Los contenedores sólo se pueden agregar a espacios de tablas SMS en bases de datos particionadas las cuales no tengan aún un contenedor asignado para el espacio de tablas. Cuando se agregan contenedores nuevos, se iniciará un reacomodamiento automático para distribuir los datos en todos los contenedores. Este reacomodamiento no evitará el acceso simultáneo a la base de datos.
Configuraciones de espacios de tablas
Hay varias configuraciones que usted puede especificar para espacios de tablas, ya sea al crearlos o posteriormente con una instrucción ALTER TABLESPACE. La siguiente lista describe las configuraciones.
- Tamaño de página
- Define el tamaño de las páginas usadas para el espacio de tablas. Los tamaños soportados son 4K, 8K, 16K y 32K. El tamaño de la página limita el largo y la cantidad de columnas de tablas que se pueden colocar en el espacio de tablas según los límites que se muestran en la Tabla 1.
Tabla 1. Implicancias del tamaño de página
| Tamaño de página | Límite del tamaño de fila | Límite de cantidad de columnas | Capacidad máxima (espacio de tablas DMS) |
|---|---|---|---|
| 4 KB | 4 005 | 500 | 64 GB |
| 8 KB | 8 101 | 1 012 | 128 GB |
| 16 KB | 16 293 | 1 012 | 256 GB |
| 32 KB | 32 677 | 1 012 | 512 GB |
Los espacios de tablas se limitan a 16.384 páginas. Por lo tanto si se elige un tamaño de página más grande aumentará la capacidad del espacio de tablas.
- Extent size (Tamaño de extensión)
- Especifica la cantidad de páginas que se escribirán a un contenedor antes de pasar al contenedor siguiente. Se repiten los ciclos de administrador de base de datos a través de los contenedores a medida que se almacenan los datos. Este parámetro sólo tiene efecto cuando hay múltiples contenedores para el espacio de tablas.
- Prefetch size (Tamaño de captura previa)
- Especifica la cantidad de páginas que se leerán del espacio de tablas al realizar la captura previa de datos. La captura previa lee los datos requeridos por una consulta antes de ser referenciados por la consulta para que esta última no deba esperar que se efectúe la E/S. La captura previa es seleccionada por el administrador de base de datos cuando determina que la E/S secuencial es adecuada y que la captura previa puede ayudar a mejorar el rendimiento.
- Overhead and transfer rate (Sobrecarga y tasa de transferencia)
- Determina el costo de E/S durante la optimización de consultas. Ambos valores se miden en milisegundos y deben ser el promedio para todos los contenedores. La sobrecarga es el tiempo asociado con la actividad del controlador de E/S, el tiempo de búsqueda de disco y la latencia rotacional. La tasa de transferencia es la cantidad de tiempo necesaria para leer una página en memoria. Los valores predeterminados para una base de datos creada en DB2 Versión 9 son 7,5 y 0,06 milisegundos, respectivamente. Los valores predeterminados para una base de datos que migra de una versión anterior de DB2 a la Versión 9 o alguna posterior son 12,67 y 0,18 milisegundos, respectivamente. Estos valores se pueden calcular en función de las especificaciones de hardware.
Ejemplo de una instrucción CREATE TABLESPACE
El Listado 4 crea un espacio de tablas común, incluyendo todas las configuraciones de este artículo.
Listado 4. Creación de un espacio de tablas
CREATE TABLESPACE USERSPACE3 PAGESIZE 8K MANAGED BY SYSTEM USING
('d:\usp3_cont1', 'e:\usp3_cont2', 'f:\usp3_cont3')
EXTENTSIZE 64 PREFETCHSIZE 32
BUFFERPOOL BP3 OVERHEAD 7.5 TRANSFERRATE 0.06 |
Cómo ver sus atributos de espacio de tablas y contenedores
Especificando la opción SHOW DETAIL (Mostrar detalle) del comando LIST TABLESPACES se
mostrará información adicional: LIST TABLESPACES SHOW
DETAIL.
El Listado 5 muestra los datos de salida para el espacio de tablas USERSPACE1. De manera predeterminada, se listarán los tres espacios de tablas creados al momento de crearse la base de datos.
Listado 5. Datos de salida del comando LlST TABLESPACES SHOW DETAIL
Tablespaces for Current Database Tablespace ID = 2 Name = USERSPACE1 Type = Database managed space Contents = All permanent data. Large table space. State = 0x0000 Detailed explanation: Normal Total pages = 8192 Useable pages = 8160 Used pages = 96 Free pages = 8064 High water mark (pages) = 96 Page size (bytes) = 4096 Extent size (pages) = 32 Prefetch size (pages) = 32 Number of containers = 1 |
Para listar los contenedores necesitamos usar la Tablespace id (Identificación de
espacio de tablas) de los datos de salida recién mencionados, ingreseLIST TABLESPACE CONTAINERS FOR 2.
Listado 6. Datos de salida del comando LlST TABLESPACES CONTAINERS
Tablespace Containers for Tablespace 2 Container ID = 0 Name =
C:\DB2\NODE0000\SQL00004\SQLT0002.0 Type = Path |
El comando listará todos los contenedores para el espacio de tablas especificado. La ruta de acceso, que se muestra en el Listado 6, señala dónde reside físicamente el contenedor.
El grupo de buffers se vincula a una única base de datos y puede ser usado por más de un espacio de tablas. Al considerar un grupo de buffers para uno o más espacios de tabla, usted debe asegurarse que el tamaño de página del espacio de tablas y el tamaño de página del grupo de buffers sea iguales para todos los espacios de tablas que asiste el grupo de buffers. Un espacio de tablas sólo puede usar un grupo de buffers.
Cuando se crea la base de datos, se crea un grupo de buffers predeterminado llamado IBMDEFAULTBP, el cual es compartido por todos los espacios de tablas. Se pueden agregar más grupos de buffers usando la instrucción CREATE BUFFERPOOL (Crear grupo de buffers). El tamaño del grupo de buffers se establece de manera predeterminada en el tamaño especificado por el parámetro de configuración de base de datos BUFFPAGE, pero usted puede anularlo especificando la palabra clave SIZE (Tamaño) en el comando CREATE BUFFERPOOL. El tamaño adecuado del grupo de buffers es esencial para el buen funcionamiento de la base de datos ya que reducirá la E/S en disco, la operación que más tiempo consume. Los grupos de buffers grandes también impactarán en la optimización de las consultas, ya que gran parte del trabajo se puede realizar en la memoria.
- Grupos de buffers basados en bloques
- La versión 8 y otras posteriores le permiten separar una porción del grupo de buffers (hasta el 98%) para la captura previa basada en bloques. La E/S basada en bloques mejora la eficacia de la captura previa al leer un área contigua de la memoria en lugar de cargarlo dispersamente en páginas diferentes. El tamaño de los bloques debe ser uniforme por grupo de buffers y es controlado por el parámetro BLOCKSIZE (Tamaño de bloque). El valor es el tamaño de bloque medido en páginas, de 2 a 256, siendo 32 el valor predeterminado.
Ejemplo de instrucción CREATE BUFFERPOOL
Para un ejemplo de la instrucción CREATE BUFFERPOOL, ingrese:CREATE BUFFERPOOL BP3 SIZE 2000 PAGESIZE 8K
Este grupo de buffers se asigna a USERSPACE3 en el ejemplo de este artículo CREATE
TABLESPACE y se crea antes de crear el espacio de tablas. Observe que los tamaños de
página de 8K para el grupo de buffers y el espacio de tablas son iguales. Si usted
crea el espacio de tablas después de crear el grupo de buffers, puede omitir la
sintaxis BUFFER POOL BP3 en la instrucción CREATE TABLESPACE. En cambio, puede usar
el comando ALTER TABLESPACE para agregar el grupo de buffers al espacio de tablas
existente ingresando: ALTER TABLESPACE USERSPACE3 BUFFERPOOL
BP3.
Cómo ver los atributos de su grupo de buffers
Usted puede listar la información de grupo de buffers consultando la vista de sistema SYSCAT.BUFFERPOOLS, como se muestra en el Listado 7.
Listado 7. Consulta de SYSCAT.BUFFERPOOLS
SELECT * FROM SYSCAT.BUFFERPOOLS BPNAME BUFFERPOOLID DBPGNAME NPAGES PAGESIZE ESTORE NUMBLOCKPAGES BLOCKSIZE ------------ ------------ -------- ------ -------- ------ ------------- --------- IBMDEFAULTBP 1 - 1000 4096 N 0 0 1 record(s) selected. |
Para averiguar qué grupo de buffers está asignado a los espacios de tablas, ejecute la consulta que se muestra en el Listado 8.
Listado 8. Consulta de SYSCAT.TABLESPACES
SELECT TBSPACE, BUFFERPOOLID FROM SYSCAT.TABLESPACES TBSPACE BUFFERPOOLID ----------- ------------ SYSCATSPACE 1 TEMPSPACE1 1 USERSPACE1 1 3 record(s) selected. |
La identificación de grupo de buffers BUFFERPOOLID se muestra en la consulta que aparece en el Listado 8, permitiéndole ver qué grupo de buffers está asociado a cada espacio de tablas.
Diagrama visual de los espacios de tabla contenidos en una base de datos
Ya describimos qué es un espacio de tablas y un grupo de buffers y cómo crearlos, ahora la Figura 1 muestra un ejemplo que refleja la forma en que se organizan visualmente dentro de una base de datos.
Figura 1. Espacios de tablas y grupos de buffers
La base de datos de ejemplo tiene cinco espacios de tablas: un catálogo, dos comunes, uno grande y uno temporal de sistema. No se creó espacio de tablas temporal de usuario. Hay ocho contenedores. En este ejemplo, los grupos de buffer se podrían asignar de la siguiente manera:
- BP1 (4K) a SYSCATSPACE y USERSPACE2
- BP2 (8K) a USERSPACE1
- BP3 (32K) a LARGESPACE y SYSTEMP1
Análisis de las implicancias en el rendimiento
En general, al diseñar la ubicación de contenedores y espacios de tablas en dispositivos físicos, el objetivo es maximizar el paralelismo E/S y la utilización de buffer. Para lograr este objetivo, usted debe comprender exhaustivamente las aplicaciones y el diseño de la base de datos. Recién después puede determinar ciertas cuestiones, por ejemplo si separar o no dos tablas en dispositivos diferentes conducirá a E/S paralela, o si una tabla se debe crear o no en un espacio de tablas separado, para que pueda cargarse totalmente en buffer.
Comience a diseñar la disposición física de una base de datos nueva diseñando la organización de los espacios de tablas, como se muestra en los pasos siguientes.
- Determine las limitaciones que presentan los diseños de tablas. Esto podría requerir el uso de más de un espacio de tabla común.
- Considere si tener tablas con diferentes configuraciones en los espacios de tablas aumentará significativamente el rendimiento.
- Diseñe un espacio de tablas tentativo.
- Considere la utilización del grupo de buffers. Esto podría obligarlo a hacer ciertos cambios en el diseño de espacio de tablas anterior.
- Asigne los contenedores a los espacios de tablas.
Este proceso es iterativo, y el diseño se deberá verificar con prueba de esfuerzo y evaluación comparativa. Es obvio que obtener el diseño óptimo puede demandar un gran esfuerzo, y sólo se justifica si el rendimiento de la base de datos debe ser el mejor posible. Como regla:
- Comience por el diseño factible más simple.
- Agregue complejidad sólo cuando exista una justificación suficiente para el rendimiento según las pruebas efectuadas.
A menudo una leve degradación del rendimiento es válida para reducir la complejidad en la administración y actualización de un diseño de base de datos más simple. DB2 tiene una sofisticada lógica de administración de recursos y por lo general produce muy buen rendimiento sin un diseño elaborado.
Organización del espacio de tablas
Cada tabla, según la forma más frecuente en la que se accede a ella, tiene el conjunto de configuraciones de espacio de tablas más eficaz: PAGESIZE, EXTENTSIZE y PREFETCHSIZE.
El espacio de tablas de catálogo y los espacios de tablas temporales de sistema se deberán asignar habitualmente como SMS. No hay razones para tener más de un espacio de tablas temporal del mismo tamaño de página y por lo general uno con el tamaño de página más grande será suficiente.
La cuestión que se plantea es si fragmentar o no los datos de usuario en múltiples espacios de tabla. Una consideración a tener en cuenta es la utilización de páginas. Las filas no se pueden fragmentar entre páginas, por lo tanto las tablas con filas largas requieren un tamaño de página adecuado. Sin embargo, no puede haber más de 225 filas en una página, por ende las tablas con filas cortas no utilizarán la página completa.
Por ejemplo una tabla con un largo de fila de 12 bytes ubicada en un espacio de tabla con tamaño de página de 32K utilizará sólo un 10% de cada página (es decir ((255 filas x 12 bytes) + 91 bytes de sobrecarga) / tamaño de página de 32k = ~10%). Esto sólo se considera si la tabla es grande, y por lo tanto el espacio desaprovechado es significativo. También puede hacer que la E/S y la carga en buffer sean menos eficaces, ya que el contenido útil real de cada página será pequeño.
Si una tabla se puede ubicar dentro de un tamaño de página más pequeño o utilizar totalmente un tamaño de página más grande, entonces el método de acceso más frecuente determinará cuál es mejor. Si habitualmente se accede secuencialmente a una mayor cantidad de filas (tal vez la tabla esté agrupada en clústeres), entonces el tamaño de página más grande será más eficaz. Si se accede a las filas de manera aleatoria, entonces el tamaño de página más pequeño le permitirá a DB2 aprovechar mejor el buffer, ya que cabrán más páginas en la misma área de almacenamiento.
Una vez que agrupó las tablas por tamaño de página, la frecuencia y el tipo de acceso determinarán si se garantiza que los datos seguirán agrupándose en espacios de tablas separados. EXTENTSIZE es la cantidad de páginas de datos que se escribirán en un contenedor antes de escribir en el siguiente contenedor (si existen múltiples contenedores en el espacio de tablas).
PREFETCHSIZE especifica la cantidad de páginas que se leerán desde el espacio de tablas cuando se efectúe la captura previa de datos. Se usa la captura previa cuando el Administrador de Bases de Datos determina que la E/S secuencial es adecuada y la captura previa puede ayudar a mejorar el rendimiento (por lo general grandes escaneos de tablas). Es recomendable configurar explícitamente el valor PREFETCHSIZE como múltiplo del valor EXTENTSIZE para su espacio de tabla y la cantidad de contenedores de espacio de tablas. Por ejemplo, si el valor de EXTENTSIZE es 32 y hay cuatro contenedores, entonces valores adecuados para PREFETCHSIZE serían 128, 256, etc. Si una o varias tablas que se usan intensamente requiere/n un conjunto diferente de estos parámetros con respecto a los valores que son los mejores para el resto del rendimiento del espacio de tablas, coloque estas tablas en un espacio de tablas separado podría mejorar el rendimiento general.
Si la captura previa es un factor importante en el espacio de tablas, entonces considere reservar parte del buffer para E/S basada en bloques. El tamaño del bloque deberá ser igual al de PREFETCHSIZE.
Utilización de grupos de buffers
El motivo más importante para usar más de un espacio de tablas de usuario es administrar la utilización de buffer. Un espacio de tablas sólo se puede asociar a un grupo de buffers, aunque un grupo de buffers se puede usar para más de un espacio de tablas.
El objetivo del ajuste de grupos de buffers es ayudar a que DB2 use de la mejor manera posible la memoria disponible para buffers. El tamaño de buffer general produce un efecto importante en el rendimiento de DB2, ya que una cantidad grande de páginas puede reducir significativamente la E/S, que es la operación que más tiempo consume. No obstante, si el tamaño total de buffer es demasiado grande, y no hay suficiente almacenamiento para asignarle, se asignará un conjunto de buffers mínimo para cada tamaño de página, reduciéndose así el rendimiento de manera rotunda. Para calcular el tamaño máximo de buffer, DB2 considera toda otra utilización de almacenamiento, el sistema operativo y cualquier otra aplicación. Una vez que se determinó el tamaño total disponible, esta área se puede dividir en diferentes grupos de buffers para mejorar la utilización. Si hay espacios de tablas con espacios de página diferentes, entonces deberá haber por lo menos un grupo de buffers por tamaño de página.
Tener más de un grupo de buffers puede preservar los datos en los buffers. Por ejemplo, usted podría tener una base de datos con muchas tablas pequeñas de uso muy frecuente, las cuales normalmente estarán totalmente en el buffer para acceder a ellas muy rápidamente. Usted podría tener además una consulta que se ejecuta contra una tabla muy grande que usa el mismo grupo de buffers e implica leer más páginas que las admitidas para el tamaño total de buffer. Cuando se ejecute esta consulta, se perderán las páginas de las tablas pequeñas de uso muy frecuente. Esto obligará a releerlas cuando se las necesite nuevamente. Si las tablas pequeñas tienen su propio grupo de buffer, lo cual exige que tengan su propio espacio de tablas, sus páginas no pueden ser anuladas por la consulta a tabla grande. Esto probablemente brindará un mejor rendimiento general del sistema, aunque a costa de un pequeño efecto negativo en la consulta de la tabla grande.
Frecuentemente ajustar estos procesos consiste en buscar el equilibrio entre las diferentes funciones de un sistema para obtener una ganancia en el rendimiento general. Es esencial fijar las prioridades de las funciones y no perder de vista el uso y la capacidad de procesamiento total al hacer ajustes en el rendimiento de un sistema.
Con DB2 Versión 8 y posteriores usted puede cambiar los tamaños de los grupos de buffers sin cerrar la base de datos. La instrucción ALTER BUFFERPOOL con la opción IMMEDIATE (Inmediato) se aplicarán inmediatamente, excepto cuando no haya suficiente espacio reservado en la memoria de la base de datos compartida para asignar espacio nuevo. Esta característica se puede usar para ajustar el rendimiento de bases de datos por cambios periódicos en el uso, por ejemplo pasar de uso interactivo durante el día a trabajo por lotes durante la noche. DB2 Versión 9.1 y posteriores permiten administrar de manera totalmente automática el tamaño de un grupo de buffers. El Gestor de memoria de ajuste automático (self-tuning memory manager - STMM) DB2 controla este proceso de automatización
Organización del almacenamiento físico
Una vez que las tablas se distribuyen entre espacios de tablas, usted deberá determinar su almacenamiento físico. Un espacio de tablas se puede almacenar en múltiples contenedores y puede ser SMS o DMS. SMS es más fácil de administrar y podría ser una buena elección para los espacios de tabla que contienen muchas tablas pequeñas y diversas (por ejemplo el espacio de tablas de catálogo), especialmente si estas tablas contienen objetos LOB.
Para reducir la sobrecarga que representa extender los contenedores SMS de a una
página por vez, se deberá ejecutar el comando db2empfa.
Esto establecerá el valor del parámetro de configuración de base de datos
MULTIPAGE_ALLOC en YES.
DMS habitualmente ofrece un mejor rendimiento y la flexibilidad de almacenar índices y datos LOB de manera separada. Los contenedores múltiples para un espacio de tablas se deberán ubicar normalmente en volúmenes físicos separados. Esto puede mejorar el paralelismo de ciertas E/S. Cuando usted tenga múltiples espacios de tablas de usuario y múltiples dispositivos, considere la lógica de aplicación, de manera tal que la carga de trabajo se distribuya tan uniformemente como sea posible entre estos dispositivos.
Los dispositivos RAID (matriz redundante de discos independientes) tienen sus propias
consideraciones especiales. El valor de EXTENTSIZE debe ser igual a, o múltiplo del
tamaño de bandas RAID. El valor PREFETCHSIZE deberá ser el tamaño de bandas RAID
multiplicado por la cantidad de dispositivos paralelos RAID (o múltiplo de este
producto), y un múltiplo del valor EXTENTSIZE. DB2 viene con sus propias variables
de registro, permitiéndole mejorar su entrono específico. Ingrese el comando
siguiente para habilitar el paralelismo E/S dentro de un mismo contenedor: db2set DB2_PARALLEL_IO=*.
Como ocurre en otras áreas de evaluación de rendimiento, la única manera segura de saber si un cambio produce un efecto beneficioso es hacer evaluaciones comparativas. Estas evaluaciones son bastante más complicadas de usar para cambios en la organización física porque se requiere un esfuerzo comparativamente mayor para cambiar espacios de tablas. La forma más práctica es minimizar la cantidad de casos durante la fase de diseño, para que se necesite evaluar comparativamente menos casos después. Tal vez la única situación que amerita dedicar tiempo y energía para evaluar comparativamente, de una manera exhaustiva, con respecto a diseños de la competencia es cuando el rendimiento es sumamente importante, y es probable que existan diferencias significativas de rendimiento entre los distintos diseños. Se deberán enfatizar los grupos de buffers, asegurándose de que no se asignen en memoria virtual y que se utilicen de la manera más eficaz.
Siempre se debe reevaluar el ajuste de los parámetros y la organización física de la base de datos antes de moverla a un sistema diferente, aún cuando estos sistemas estén en el mismo tipo de plataforma. Los resultados pueden ser inesperados y requerir un trabajo sustancial para resolverlos.
En una situación de la vida real, un ABD copió una base de datos bien ajustada de un servidor Windows con un GB de almacenamiento a una computadora portátil que ejecutaba Windows con 256 MB de almacenamiento. La conexión que llevó subsegundos en el servidor, tardó 45 minutos en la computadora portátil. El ABD resolvió el problema reduciendo el tamaño del grupo de buffers y otros parámetros de memoria.
La cuestión se torna cada vez más difícil si las plataformas son diferentes. Aún entre UNIX y Windows, aquello que es óptimo en un sistema podría no serlo en otro. A continuación se describen algunos consejos a tener en cuenta:
- Si la copia de base de datos se realiza con fines de producción, entonces deberá repetirse el proceso de ajuste.
- Si la base de datos se debe mover a la plataforma z/OS®, consulte los manuales y los Redbooks IBM correspondientes®.
- En DB2 for i, la configuración y el ajuste físico se realizan fuera del entorno de base de datos. Consulte los manuales de administración de sistemas IBM i.
En este artículo abarcamos bastante material, pero de ninguna manera incluye todo lo que usted debería saber sobre diseño y rendimiento de base de datos. Nos focalizamos en algunas cuestiones más importantes del diseño de base de datos sin entrar en detalles de optimización de consultas y consideraciones de aplicaciones. Diseñar su base de datos es un tema prioritario y esencial ya que todo lo demás se basará en eso, por lo tanto su planificación inicial debe ser exhaustiva. Para facilitar su tarea, a continuación suministramos otras referencias online para que pueda profundizar sus conocimientos sobre este tema.
Agradecemos a Gabor Wieser y David J. Kline, quienes escribieron la versión original de este artículo en 2002.
Aprender
- Consulte el DB2 for
Linux, UNIX, and Windows Information Center para obtener más detalles sobre
sintaxis SQL para los comandos usados en este artículo, así como también detalles
sobre espacios de tablas y grupos de buffers.
- Consulte "DB2 Storage Trivia" (developerWorks, Agosto 2001) para obtener sugerencias
y técnicas para administrar datos en un sistema de almacenamiento DB2.
- Busque "Tuning up for OLTP and Data Warehousing [Ajustes para OLTP y almacenamiento de
datos]" (IBM Database Magazine, 4º trimestre de 2002) para obtener
sugerencias sobre ajustes a bases de datos DB2 tanto en entornos OLTP como de
almacenamiento de datos.
- Consulte el área de
DB2 for Linux, UNIX, and Windows en developerWorks para obtener los recursos
que necesita para desarrollar sus habilidades en DB2.
- Conozca más sobre DB2Express-C, la
versión gratuita de DB2 Express Edition para la comunidad.
- Conozca más sobre Gestión de Información en la
zona zona Information
Management de developerWorks. Encuentre documentación técnica, instructivos,
capacitación, descargas, información de producto y más.
- Manténgase actualizado con eventos técnicos
y transmisiones por Internet de developerWorks.
Obtener los productos y tecnologías
- Descargue DB2
Express-C para obtener una versión gratuita de DB2 Express Edition para la
comunidad que ofrece las mismas características de datos principales que DB2 Express
Edition y ofrece una base sólida para construir e implantar aplicaciones.
- Construya su próximo
proyecto de desarrollo con IBM
trial software [software de prueba IBM], disponible para descarga
directamente de developerWorks.
Comentar
- Participar en el foro de debate.
- Consulte developerWorksblogs y
participe en developerWorks
community [comunidad developerWorks].

Ani Patel trabaja actualmente en IBM Toronto Lab como DB2 Advance Support Analyst de Nivel 2, y trabajó con soporte DB2 durante más de 7 años. Sus áreas de especialización incluyen almacenamiento, copia de seguridad, recuperación e inicio de sesión. Es Licenciada en Ingeniería de Computación de la Universidad de Ryerson en Toronto, Canadá.