IDUG Content Committee

Universal Table Space (UTS)

El concepto de Universal Table Space (UTS) fue introducido en Db2 9 para unir las ventajas de table spaces particionados, donde pueden tener una capacidad mayor a 64Gb, y table spaces segmentados que tienen el beneficio de gestión de los spacemaps dentro de cada partición, además de que también es posible hacer “mass deletes”, los cual no era posible con table spaces del tipo non-UTS table controlled partitioning.

Partition by Range (PBR) sigue de la mejora en Db2 8 de “Table Controlled Partitioning” con la adición del parámetro SEGSIZE en la definición del table space, lo que permite disfrutar los beneficios de particionar por rango pero con el beneficio adicional de rendimiento que viene con gestión de spacemaps de table spaces segmentados.

Partition by Growth (PBG) table spaces también tienen el parámetro SEGSIZE, y eso, junto con el parámetro MAXPARTITIONS lo hace Partition by Growth, en lugar de un Partition by Range table space.

A partir de la versión 12 de Db2, hay un tipo nuevo de UTS: Partition by Range - Relative Page Numbering (PBR RPN). Esto significa que el tipo PBR que fue introducido en Db2 9 ahora es oficialmente PBR Absolute Page Numbering para diferenciar entre los 2 tipos de Partition by Range table space.

Los table spaces UTS tienen el potencial de crecer hasta 128Tb en Db2 11 (o 4Pb para PBR RPN en Db2 12 – 4096 * 1Tb particiones). Los table spaces universales (UTS, de cualquier tipo) necesitan ser en table spaces de sola una tabla.

En este blog, vamos a discutir table spaces de tipo Partition by Growth (PBG).

Las bases de PBGs

PBGs son al mismo tiempo particionados y segmentados, y cuando los datos son insertados, Db2 empieza a llenar la primera partición o particiones que ya existen. Una vez que se llena una partición, se genera una partición extra de manera automática y se puede utilizar de inmediato. Esto es similar a la manera en que los table spaces segmentados funcionan cuando crecen hasta 32 data sets de 2Gb cada uno (esto es, un tamaño máximo de 64Gb). Las particiones de un table space PBG son de tienen un límite de tamaño indicado por el parámetro DSSIZE.

Cuando se genera una partición nueva, sus características se toman de la partición anterior:

FREEPAGE

PCTFREE

LOGGED/ NOT LOGGED

TRACKMOD YES/ NO

COMPRESS YES/ NO

COMPRESSION DICTIONARY (en caso de que exista)

La acción de crear una partición nueva también inserta un registro en la tabla de SYSCOPY, con ICTYPE = A (ALTER), con esto es posible rastrear la fecha y hora en que las particiones nuevas son creadas. Por ejemplo, aquí se muestran 4 particiones nuevas que fueron agregadas automáticamente a un table space del tipo PBG.

SELECT TSNAME, DSNUM, ICTYPE, ICDATE, ICTIME

FROM SYSIBM.SYSCOPY

WHERE ICTYPE = 'A'

AND   TSNAME = 'SACH007'

AND   ICDATE > '180829'

ORDER BY ICDATE, ICTIME ASC

WITH UR;

---------+---------+---------+---------+---------+---------

TSNAME          DSNUM  ICTYPE  ICDATE  ICTIME

---------+---------+---------+---------+---------+---------

SACH007           295  A       180830  074606

SACH007           296  A       180830  152811

SACH007           297  A       180831  102728

SACH007           298  A       180831  170619

DSNE610I NUMBER OF ROWS DISPLAYED IS 4

Creación/Conversión

Podemos crear un table space como PBG de 3 maneras:

• Explícitamente, usando DDL para especificar las características del table space.
• Implícitamente, permitiendo que Db2 y nuestros zParms definan el table space.
• Convertir de un table space simple o segmentado con ALTERs en SQL y un REORG en línea.

PBG table space con DDL Explícito

Cuando definimos nuestro DDL explícitamente para crear un PBG, la palabra clave más importante es MAXPARTITIONS. Este puede ser un npumero entre 1 y 4096 y es el máximo número de particiones que queremos permitir crear (pero también podemos utilizar ALTER para crecer o reducir el número de particiones de ser necesario). Aunque podría ser tentador simplemente poner MAXPARTITIONS 4096 y no pensar más sobre este tema, puede ser un gasto de almacenamiento y CPU relativo al valor de MAXPARTITIONS en lugar de ser el número de particiones definidos/usados, de ahí que vale la pena pensar en un número máximo realista. Un número grande de MAXPARTITIONS va a resultar en una gran cantidad de almacenamiento asignado al thread, pero si nunca se va a requerir esas particiones puede causar un impacto innecesario al almacenamiento disponible y posiblemente también al CPU ocasionado por otros threads de Db2.

El DDL podría parecer algo como este:

CREATE TABLESPACE EXPLTS

    IN MYDB

    USING STOGROUP MYSTOG

    DSSIZE 2 G

    SEGSIZE 32

    MAXPARTITIONS 32

    BUFFERPOOL BP1

    CCSID UNICODE

;

Esto va a generar un table space con un máximo de 32 particiones, cada una con un tamaño límite de 2GB y en total el table space tendrá un tamaño máximo de 64Gb.

PBG table space con DDL Implícito

Para obtener los table spaces de PBG creados implícitamente, el DDL tiene que tener una de las siguientes opciones:

1. Omitir utilizar la cláusula “IN DATABASE.TABLESPACE” , lo que resulta en una base de datos creada implícitamente y un table space de tipo PBG. Por ejemplo,

CREATE TABLE

  MYSCHEMA.MYTABLE

   (

   COLUMN1   CHAR(5)

    FOR SBCS DATA

  ,COLUMN2   CHAR(5)

    FOR SBCS DATA

  ,COLUMN3   TIMESTAMP

   )

;

Esto resulta en el DDL siguiente que muestra los parámetros adicionales y los valores generado por Db2, muchos de los cuales se toman de los valores de las zParms para el miembro o subsistema en el que se crea el objeto:

CREATE

 TABLESPACE MYTABLE <- Db2 crea el table space con una semejanza al nombre de la tabla    IN DSN01333 <- Db2 crea una base de datos implícitamente como DSNnnnnn

    USING STOGROUP SYSDEFLT

    PRIQTY -1

    SECQTY -1

    ERASE NO

    FREEPAGE 0

    PCTFREE 5

    GBPCACHE CHANGED

    COMPRESS NO

    TRACKMOD YES

    LOGGED

    DSSIZE 4 G <- default en Db2

    SEGSIZE 32 <- default obtenido de DPSEGSZ

    MAXPARTITIONS 256 <- default de Db2

    BUFFERPOOL BP0 <- default obtenido de TBSPOOL

    LOCKSIZE ROW <- default de Db2

    LOCKMAX SYSTEM

    CLOSE YES

    CCSID EBCDIC <- default de CCSID

    MAXROWS 255

;

1. Si la sentencia CREATE TABLE DDL solamente tiene la cláusula “IN DATABASE dbname” sin especificar el table space, esto resulta en un table space PBG creado de manera implícita dentro de una base de datos definida previamente ( y de manera explícita). Por ejemplo:

CREATE TABLE

  MYSCHEMA.MYTABLE2

   (

   COLUMN1   CHAR(5)

    FOR SBCS DATA

  ,COLUMN2   CHAR(5)

    FOR SBCS DATA

  ,COLUMN3   TIMESTAMP

   )

IN DATABASE MYDB

;

Esto genera el DDL siguiente con características heredadas de la base de datos, y otras de los defaults de Db2:

CREATE

 TABLESPACE MYTABLE2

    IN D205040

    USING STOGROUP SGMYSTOG

    PRIQTY -1    SECQTY -1

    ERASE NO

    FREEPAGE 0

    PCTFREE 5

    GBPCACHE CHANGED

    COMPRESS NO

    TRACKMOD YES

    LOGGED

    DSSIZE 4 G

    SEGSIZE 32

    MAXPARTITIONS 256

    BUFFERPOOL BP3

    LOCKSIZE ROW

    LOCKMAX SYSTEM

    CLOSE YES

    CCSID UNICODE

    MAXROWS 255

;

En ambos ejemplos, con o sin una base de datos creada explícitamente, el DDL de la tabla que se genera después de la creación del table space incluye la línea PARTITION BY SIZE EVERY 4 G :

CREATE TABLE

  MYSCHEMA.MYTABLE

   (

   COLUMN1   CHAR(5)

    FOR SBCS DATA

  ,COLUMN2   CHAR(5)

    FOR SBCS DATA

  ,COLUMN3   TIMESTAMP

   )

    CCSID EBCDIC

    NOT VOLATILE

    APPEND NO

  PARTITION BY SIZE EVERY 4 G

;

Por otro lado, la sección PARTITION BY SIZE EVERY 4 G no aparece cuando el table space ha sido creado explícitamente. Estos DDLs han sido generados por una herramienta externa, pero se vería lo mismo en Db2 Admin Tool o Data Studio.

Los table spaces creados implícitamente siempre son PBG, a menos que la sentencia de CREATE TABLE DDL tenga definiciones para el tipo Partition by Range.

El table space implícito de PBG será definido con las características siguientes cuando la base de datos y el table space serán creados implícitamente, mientras que cuando solamente creamos el table space dentro de una base de datos que ya existe, algunas características serán heredadas de la base de datos (marcados en la tabla con un X)

El table space tendrá un nombre que será generado por Db2 y que se derivará del nombre de la tabla.

En el caso de que también se genere una base de datos implícita, seguirá la convención DSNnnnnn. El número de la base de datos aumenta cada vez que se crea una nueva base de datos, y cada base de datos creada implícitamente solo puede contener un table space.

Convertir de Table Space Simple o Segmentado a PBG

La tercera forma de obtener table spaces de tipo PBG es convertir un table space simple o segmentado existente a PBG.

Si el table space original es un table space simple con una sola tabla, entonces con un mínimo de solo 1 ALTER puede convertirse a PBG. Primero tienen que ejecutar el ALTER para MAXPARTITIONS. Deben ejecutar este ALTER primero; de lo contrario, los ALTER subsiguientes para SEGSIZE o DSSIZE fallarán (porque solo se pueden ejecutar en un UTS). Ejecutar un ALTER para DSSIZE o SEGSIZE antes de MAXPARTITIONS dará como resultado un SQLCODE -650 con REASON CODE 7 u 8 respectivamente.

Si el table space ya está segmentado, pero con un SEGSIZE < 32, Db2 lo aumentará a 32 durante el REORG a menos que especifique una instrucción ALTER TABLESPACE para SEGSIZE antes del REORG. Si el SEGSIZE es de 64 y no se especifica un ALTER con un SEGSIZE más pequeño, SEGSIZE 64 permanecerá después del REORG.

Para DSSIZE, si no especifica ningún valor, se obtiene el valor predeterminado de 4G, o se puede ejecutar ALTER TABLESPACE para configurar DSSIZE antes del REORG que materializa el cambio.

Se puedne ejecutar los 3 ALTER en un solo paso, seguido de un solo REORG y se materializan los 3 cambios.

ALTER TABLESPACE dbname.tsname MAXPARTITIONS n;

ALTER TABLESPACE dbname.tsname SEGSIZE n;

ALTER TABLESPACE dbname.tsname DSSIZE nG

Estos ALTERs, o “Pending Definition Changes” (PDC), se insertarán en la tabla SYSIBM.SYSPENDINGDDL y el SQL se regresará un SQLCODE de +610, lo cual es una advertencia de que el table space está en estado AREOR (“advisory REORG pending”) como resultado de los PDC.

Un REORG de SHRLEVEL CHANGE o REFERENCE materializará los cambios. El REORG no necesita ejecutarse inmediatamente después de que se hayan ejecutado los ALTERs; se puede programar para otra hora, por ejemplo, durante una ventana de mantenimiento. No hay ningún impacto en las aplicaciones que utilizan el table space, mientras que el objeto está en AREOR, pueden continuar leyendo y escribiendo en la tabla.

Para objetos grandes donde puede que no haya suficiente espacio disponible en el disco para el SORT, o para reducir el tiempo de ejecución del REORG que materializa el cambio, se puede utilizar SHRLEVEL CHANGE con las palabras clave SORTDATA NO y RECLUSTER NO.

Nota: un REORG con SHRLEVEL NONE ignorará el estado de AREOR y NO materializará los cambios pendientes.

Resumen

Así que ahí lo tenemos, 3 formas en que podemos obtener table spaces del tipo Partition by Growth. En la siguiente parte, veremos el uso de los PBG con más detalle; vivir con PBG y los cambios adicionales que podríamos necesitar, las ventajas y desventajas de los PBG y recomendaciones basadas en expertos y experiencia.

Referencia:

IBM Knowledge Center: Partition by Growth Tablespaces