Las 15 mejores prácticas para el rendimiento de pureXML en DB2

DB2 9 presenta el soporte para pureXML, que significa que los datos XML se guardan y consultan en su formato jerárquico inherente. Para la consulta de datos XML, DB2 ofrece dos lenguajes: SQL/XML y XQuery. Además, DB2 9 cuenta con sofisticadas capacidades de indización y soporte para la validación de XML Schema. Si bien la mayor parte de los lineamientos para DB2 también corresponden a los datos XML, este artículo brinda consejos adicionales para el rendimiento específico de XML. El presente artículo ha sido actualizado para DB2 9.5.[26 de mayo de 2009: Código corregido en los Listados 12 y 13.--Ed.]

Matthias Nicola, Senior Technical Staff Member, IBM Silicon Valley Lab

Author photo: Matthias NicolaMatthias Nicola es un ingeniero sénior de software del Laboratorio de IBM de Silicon Valley en San Jose, CA. Se centra en el rendimiento de DB2 y benchmarking, XML, temporal data management, in-database analytics, y otras tecnologías emergentes. También trabaja en estrecha colaboración con los clientes y socios para ayudarles a diseñar, optimizar, e implementar soluciones DB2. Anteriormente, Matthias trabajó en el rendimiento del depósito de datos en Informix Software. Recibió su Doctorado en ciencias de la computación de la Universidad Técnica de Aachen, Alemania.


Nivel de autor contribuyente en developerWorks

26-05-2009 (Primera publicación 05-10-2006)

Introducción

El soporte de pureXML en DB2 9 ofrece capacidades eficientes y versátiles para la administración de sus datos XML. El rendimiento constituye una alta prioridad para numerosas aplicaciones XML; y los DBA, así como los diseñadores de aplicaciones, realizan un trabajo considerable para asegurar un buen rendimiento. En primer lugar, existen los tradicionales lineamientos de rendimiento DB2 para configuraciones equilibradas de CPU/memoria/disco, espacio de tabla y afinación de grupos de búferes, bloqueo, conexión, planes de ejecución de consultas, etc. Todos estos temas ya han sido tratados en artículos anteriores sobre DB2 (ver Recursos) y continúan teniendo relevancia cuando usted maneje datos XML en DB2.

Afortunadamente, muchas de estas cuestiones son manejadas por las capacidades automáticas de DB2, como el almacenamiento automático y la administración de memoria autoajustable. Proporcionan altos niveles de rendimiento para numerosas aplicaciones y requieren muy poca intervención manual. Pero las aplicaciones XML con altos requerimientos de desempeño pueden beneficiarse con consideraciones adicionales sobre rendimiento. El presente artículo se ocupa de estas situaciones, y ofrece consejos y pautas para lograr el máximo rendimiento de las aplicaciones relacionadas con XML en DB2 9.

A continuación presentamos 15 consejos para el rendimiento de XML (sin un orden particular) que trataremos e ilustraremos en el artículo. Estos 15 consejos se refieren a una variedad de áreas, aunque la experiencia muestra que las aplicaciones con problemas de rendimiento a menudo requieren la aplicación de uno o dos de estos consejos para lograr el rendimiento deseado.

En el desarrollo de estos consejos de rendimiento, partimos del supuesto de que usted se encuentra familiarizado con las prácticas básicas de administración y ejecución de DB2, así como con el soporte básico DB2 pureXML. Por ejemplo, usted deberá contar con conocimientos sobre columnas XML, índices XML, y sobre cómo realizar consultas a datos XML con SQL/XML y XQuery. Todos estos requisitos previos se trataron en artículos anteriores publicados en developerWorks (ver Recursos ).


Consejos de rendimiento de DB2 XML

Consejo 1: Elija cuidadosamente la granularidad de sus documentos XML

Cuando usted diseña su aplicación XML y particularmente la estructura de sus documentos XML, quizás cuente con la opción de definir cuáles son los datos de negocios que se mantendrán juntos en un único documento XML. Por ejemplo, en la tabla departamental que presentaremos a continuación, utilizamos un documento XML por departamento (granularidad media). Esta resultará una elección razonable si el departamento es la granularidad predominante a la cual accede nuestra aplicación para procesar los datos. De manera opcional, podríamos haber decidido combinar consejos múltiples o numerosos de departamentos en un único documento XML, como por ejemplo, todos aquellos que pertenecen a una unidad (granularidad gruesa). Esto, sin embargo, no resulta óptimo si normalmente procesamos un departamento por vez.

Tabla 1. Crear tabla departamental( unitID char(8), deptdoc xml)
unitIDdeptdoc
WWPR
<dept deptID='PR27'>    
 <employee id='901'>       
  <name>Jim Qu</name>       
  <phone>408 555 1212</phone>    
   </employee>    
	<employee id='902'>       
	 <name>Peter Pan</name>       
	  <office>216</office>    
	 </employee> 
</dept>
WWPR
<dept deptID='V15'>    
 <employee id='673'>       
  <name>Matt Foreman</name>       
   <phone>416 891 7301</phone>       
    <office>216</office>   
</employee>    
 <description>This dept supports sales world wide</description>
</dept>
S-USE...
......

También podríamos haber decidido tener un documento XML por empleado granularidad fina), con un atributo adicional "dept" para cada empleado a fin de indicar a qué departamento pertenece el empleado. Esta podría resultar una muy buena elección si los empleados usan objetos de negocios de interés a los cuales acceden para procesar independientemente de los demás empleados del departamento. Pero si la aplicación normalmente procesa a todos los empleados de un departamento juntos, puede ser mejor contar con un documento XML por departamento.

En particular, no se recomienda crear lotes para muchos objetos de negocios en un único documento. DB2 usa índices para datos XML con el fin de aplicar un filtro a nivel de cada documento individual. En consecuencia, cuanto más fina es la granularidad del documento XML, mayor será el beneficio potencial del acceso basado en índices. Además, si su aplicación usa un analizador DOM para absorber el XML recuperado de DB2, los documentos pequeños permitirán un mejor rendimiento.

En relación con el diseño de los documentos XML, una pregunta que surge con frecuencia es cuándo se deben usar atributos vs elementos y de qué manera esta elección afecta el rendimiento. Esta pregunta se relaciona mucho más con el modelado de datos que con el rendimiento. Como tal, esta pregunta es tan Antigua como SGML, precursor de XML, y ha sido debatida sin llegar a un consenso universalmente aceptado. Sin embargo, un hecho importante para seguir es que los elementos XML son más flexibles que los atributos debido a que pueden repetirse y anidarse. Por ejemplo, en los documentos de nuestro departamento, usamos un elemento “teléfono” que nos permite tener múltiples ocurrencias de "teléfono" si un empleado tiene múltiples números. Es, además, extensible, en caso que tengamos que descomponer más tarde los números telefónicos en fragmentos, es decir, el elemento “teléfono” podría tener elementos secundarios para los códigos de país, los códigos de área, los internos, etc. Si “teléfono” fuera un atributo del elemento empleado, podría existir solamente una vez por empleado, y no podríamos agregarle elementos secundarios, lo cual podría con el tiempo, dificultar la evolución del esquema. Si bien es posible modelar todos los datos sin atributos, éstos pueden constituir una opción muy intuitiva para los artículos de datos que se sabe por adelantado que no se repetirán (por elemento) y que no tendrán sub-campos. Los atributos pueden ayudar a acortar de alguna manera los XML porque tienen una única etiqueta, opuestamente a los elementos, que tienen una etiqueta de inicio y una etiqueta de cierre. En DB2, los atributos se pueden usar en consultas, predicados y definiciones de índices tan fácilmente como los elementos. Debido a que los atributos son menos extensibles que los elementos, DB2 puede aplicar ciertas optimizaciones de almacenamiento y acceso. Esto deberá considerarse como una bonificación extra en cuanto al rendimiento más que como un incentive para convertir los atributos en elementos, en especial cuando las consideraciones del modelado de datos de hecho requieren elementos.

En suma, elija la granularidad de sus documentos XML respecto de la granularidad de acceso predominante anticipada. Ante cualquier duda, es preferible inclinarse por la granularidad más fina y los documentos XML más pequeños.

Consejo 2: Use DMS y páginas más grandes para lograr un mejor rendimiento de XML

Los espacios de tablas gestionados por base de datos (database managed table spaces o DMS) brindan un mayor rendimiento que los espacios de tablas gestionados por el sistema operativo (operating system managed table spaces o SMS). Esto ocurre con los datos relacionales y aún más con el acceso a lectura y procesamiento de XML. En DB2 9, los recientemente creados espacios de tablas son DMS por default. Se recomienda también utilizar espacios de tablas DMS con almacenamiento automático de manera que los contenedores de DMS aumenten según las necesidades sin intervención manual. En caso que un documento XML sea demasiado grande para una única página en un espacio de tabla, DB2 dividirá el documento en múltiples regiones que luego quedarán almacenadas en múltiples páginas. Esto resulta transparente para su aplicación y permite que DB2 maneje los documentos XML hasta el límite de enlace de 2GB por documento.

Por lo general, cuanto menor sea la cantidad de regiones (divisiones) por documento, mejor será el rendimiento, particularmente de la inserción y de la recuperación de todo el documento. Cuando un documento no quepa en una página, la cantidad de divisiones por documento dependerá del tamaño de la página (4KB, 8KB, 16KB, o 32KB). Cuanto más grande sea el tamaño de página de su espacio de tabla, menor será la cantidad de potenciales divisiones por documento. Por ejemplo, supongamos que un documento determinado se divide en cuarenta páginas de 4KB. Entonces, ese documento podrá almacenarse en solo veinte páginas de 8KB, en diez páginas de 16KB o en cinco páginas de 32KB. Si los documentos XML son significativamente menores que el tamaño de página seleccionado, no se perderá espacio, ya que pueden almacenarse múltiples documentos pequeños dentro de una misma página.

Como norma general, para los datos XML elija un tamaño de página que no sea inferior al doble del tamaño promedio esperado para el documento, sujeto al máximo de 32KB. Si usted utiliza un único tamaño de página para los datos relacionales y XML, recuerde que el tamaño de página de 32KB puede resultar beneficioso para los datos XML pero de alguna manera puede resultar perjudicial para los datos relacionales y el acceso a índices. En estos casos, las páginas de 16KB o 8KB son una mejor elección, ya que funcionan para ambos.

Consejo 3: Saque provecho de las opciones de almacenamiento para XML: espacio de tabla alineado, comprimido o dividido

Consideremos el siguiente ejemplo de tabla para ocuparnos de las opciones de almacenamiento de datos XML. la tabla contiene datos relacionales y XML:

Listado 1. Ejemplo de tabla con datos relacionales y XML
create table product(pid bigint, name varchar(20), 
brand varchar(35), category integer, price decimal, description XML);

Con esta definición de tabla, los datos XML y los datos relacionales de la tabla quedan almacenados de manera predeterminada en el mismo espacio de tabla. Esto significa que utilizan el mismo tamaño de página y quedan almacenados en el mismo conjunto de buffers. Dentro del espacio de tabla, los datos relacionales se almacenan en el objeto DAT, mientras que los datos XML residen en el objeto XDA. Esto ocurre debido a que los documentos XML, al igual que los LOB, pueden resultar demasiado pesados para una única fila en una página de datos de la tabla. El diseño predeterminado proporciona un buen rendimiento para la mayor parte de los escenarios de las aplicaciones.

Si usted ha realizado un análisis de rendimiento y descubre que necesita un mayor tamaño de página para los datos XML y un tamaño de página menor para los datos relacionales o índices, podrá utilizar espacios de tablas independientes para ambos. Cuando defina una tabla, podrá direccionar los datos “extensos” a un espacio de tabla independiente con un tamaño de página diferente. Los datos extensos incluyen datos LOB y XML.
En el siguiente ejemplo se definen dos conjuntos de buffers y dos espacios de tablas, cada uno de ellos con páginas de 4KB y 32KB. (Obsérvese que un espacio de tabla siempre requiere un conjunto de buffers con un tamaño de página correspondiente.) La tabla"producto"está asignada al espacio de tabla"relData"con páginas de 4KB. Todas sus columnas caben en dicho espacio de tabla, a excepción de la columna XML"descripción", que está almacenada en páginas de 32KB en el espacio de tabla"xmldata".

Listado 2. Datos XML y relacionales en espacios de tablas y conjuntos de buffers independientes
create bufferpool bp4k pagesize 4k; 
create bufferpool bp32k pagesize 32k;  
	
create tablespace relData 
pagesize 4K 
managed by automatic storage 
bufferpool bp4k;
  
create tablespace xmlData 
pagesize 32K managed by automatic storage 
bufferpool bp32k;  

create table product(pid bigint, name varchar(20), brand varchar(35), 
category integer, price decimal, description XML) 
in relData  long in xmlData;

Los espacios de tablas predeterminados en DB2 9 difieren de los de DB2 V8. A menos que se lo especifique explícitamente, se crean nuevos espacios de tablas como DMS con IDs para grandes filas. Esto significa que un espacio de tabla con páginas de 4KB puede aumentar hasta 2TB en lugar de 64GB en V8, y uno con páginas de 32KB puede hacerlo hasta 16TB en lugar de 512GB. Además, desaparece el límite de 255 filas por página, permitiendo hasta 2335 filas en páginas de 32KB. De este modo, el límite de filas por página ya no constituye un motivo para utilizar páginas pequeñas para los datos relacionales.

DB2 9.5 también le permite almacenar datos XML “entre líneas” ycomprimidos. Si todos o algunos de sus documentos XML son lo suficientemente pequeños para caber en su fila correspondiente en la página base de tablas del objeto DAT, pueden estar entre líneas dentro de la fila relacional. Esto brinda un acceso más directo a los datos XML y evita el acceso redireccionado al objeto XDA. Si algunos documentos de la columna XML siguen siendo demasiado grandes para colocarlos entre líneas, éstos quedarán almacenados “fuera de líneas” en el objeto XDA, como de costumbre. La conexión en línea puede reducir el tamaño de las regiones de manera notable, ya que los documentos entre líneas no requieren ningún ingreso de índice de región: siempre constan de una única región entre líneas. Los documentos que se colocan entre líneas pueden comprimirse mediante una compresión regular de fila DB2, como se muestra en el Listado 3:

Listado 3. Almacenamiento de XML comprimidos y entre líneas
create table product(pid bigint, name varchar(20), brand varchar(35), 
                   category integer, price decimal, 
                   description XML inline length 3000) compress yes;

En este ejemplo, la columna XML se define dentro de la opción"inline length 3000". Esto significa que cualquier documento que pueda almacenarse en 3000 bytes o menos quedará entre líneas. Resulta relevante para la conexión en línea el tamaño del documento luego del análisis de XML en DB2, y no el tamaño del documento XML textual en su sistema de archivos. La extensión de la conexión en línea debe ser menor que el tamaño de la página menos el tamaño de las demás columnas de la página. Los datos XML entre líneas siempre se ubican en el mismo espacio de tabla, debido que las columnas relacionales de la tabla no pueden almacenarse en un tamaño de página diferente o en un espacio de tabla independiente.

Debido a que el ejemplo de tabla se define con la opción"compress yes", los datos relacionales y los documentos XML entre líneas se comprimen. No es poco común comprimir datos XML entre líneas en un 70 - 85 por ciento. El siguiente enunciado puede ser utilizado para verificar la relación de compresión de la tabla"producto":

Listado 4. Función administrativa para verificar la relación de compresión
select tabname,pages_saved_percent,bytes_saved_percent
from table(sysproc.admin_get_tab_compress_info('MYSCHEMA','PRODUCT','ESTIMATE')) as t

La compresión de datos XML puede brindar un gran impulso al rendimiento del sistema si el mismo está más vinculado a I/O que a la CPU. Sin embargo, obsérvese que la conexión en línea aumenta significativamente el tamaño de las filas en sus páginas de datos. Esto, a su vez, disminuye la cantidad de filas por página. Las consultas con acceso exclusivamente a las columnas relacionales de la tabla deberán ahora leer un número mucho mayor de páginas sin conexión en línea. Esto puede generar más I/O y un menor rendimiento de las consultas. Si las consultas que usted realiza normalmente se relacionan con la columna XML, esto no lo afectará.

En suma, aplique el sentido común cuando considere utilizar espacios de tablas independientes para los datos XML. Una menor cantidad de conjuntos de buffers, espacios de tablas y tamaños de páginas diferentes generarán un diseño de base de datos físicos más simple que será más fácil de manejar, actualizar y ajustar. Evite la introducción de múltiples tamaños de páginas a menos que usted esté seguro de que brindan numerosos beneficios de rendimiento. Utilice conexiones en línea y compresiones para reducir el espacio de almacenamiento y aumentar el rendimiento de I/O.

Consejo 4: Cómo configurar DB2 para la rápida inserción masiva de datos XML

DB2 9 brinda soporte a dos opciones para pasar datos XML desde un sistema de archivos a una tabla DB2: insertar e importar. Ambas opciones tienen características similares desde el punto de vista del rendimiento y el ajuste, porque el utilitario importar de hecho realiza una serie de inserciones.

Desde la aparición de DB2 9.5, usted puede, además, utilizar el utilitario DB2 LOAD para pasar datos XML a una tabla. Las ventajas clave del utilitario LOAD son las mismas para los datos XML y para los datos relacionales, como por ejemplo, el hecho de que los datos no quedan registrados y se utiliza automáticamente el paralelismo para aumentar el rendimiento. DB2 determina un grado de paralelismo predeterminado en base a la cantidad de CPU y contenedores de espacios de tablas. Además, usted puede configurar el paralelismo entre CPU e I/O con los parámetros CPU_PARALLELISM y DISK_PARALLELISM en la sintaxis del comando LOAD.

Independientemente del hecho de que su aplicación realice o no inserciones masivas, posiblemente a través de hilos de inserción concurrentes, o de si utiliza importar o cargar, corresponderá la aplicación de los siguientes lineamientos:

  • Como requisito previo clave, asegúrese de utilizar espacios de tablas DMS con un gran tamaño de página (ver Consejo 2 ).
  • Incluso si usted no ha definido aún ningún índice para la tabla destino, el mecanismo de almacenamiento de pureXML de DB2 mantiene de manera transparente las denominadas regiones y los denominados path indexes para lograr un eficaz acceso al almacenamiento de XML. En consecuencia, usted deberá proporcionar un espacio de conjunto de buffers suficiente para soportar las lecturas de los índices.
  • Si usted necesita múltiples índices XML definidos por los usuarios, normalmente será mejor definirlos antes de realizar la inserción en masa más que crearlos posteriormente. Durante la inserción, cada documento XML será procesado sólouna vez para generar ingresos de índice paratodoslos indices XML. Sin embargo, si usted emite múltiples enunciados "create index" (crear índice), todos los documentos de la columna XML serán recorridos en múltiples ocasiones.
  • Si usted necesita pasar una gran cantidad de archivos XML de un sistema de archivos a una tabla DB2, mejorará el rendimiento tenerlos en un sistema de archivos dedicados para el cual se deshabilite la captura del sistema. Debido a que cada archivo se lee solamente una vez, no es necesaria la captura. En AIX, se ha descubierto el beneficio de instalar este sistema de archivos con la opción -o cio.

Tome en cuenta los siguientes lineamientos para las operaciones insertar e importar:

  • "ALTER TABLE<tablename> APPEND ON" habilita el modo Anexar para la tabla. Los datos nuevos quedan anexados al final de la tabla, en lugar de buscar espacio libre en las páginas existentes. Con esto se logra un mejor rendimiento del tiempo de ejecución de las inserciones masivas.
  • El aumento del tamaño del buffer de registro (LOGBUFSZ) y del tamaño del archivo de registro (LOGFILSIZ) ayuda a aumentar el rendimiento de las inserciones. Esto resulta de particular importancia para las inserciones XML ya que el volumen de datos por fila tiende a ser muy superior al de los datos relacionales. Se recomienda el uso de un dispositivo de rápida I/O para el registro.
  • Usted puede evitar la generación de registros con el uso de "ALTER TABLE<tablename> ACTIVATE NOT LOGGED INITIALLY" (NLI). Sin embargo, tenga en cuenta que de ocurrir un error de enunciado, la tabla quedará marcada como inaccesible y deberá dares de baja. A menudo, esto prohíbe NLI para las inserciones masivas incrementales en los sistemas de producción, pero puede resultar útil para poblar inicialmente una tabla vacía. Tenga en cuenta que NLI evita que se produzcan inserciones/importaciones concurrentes en una tabla destino y que el paralelismo puede generar un mejor rendimiento que NLI.
  • Si usted utiliza importar, el rendimiento tiende a dañarse con un valor bajo en el parámetro COMMITCOUNT. Si se confirma cada 100 filas o más se obtendrá un mejor rendimiento que cuando se confirma cada fila. Asimismo, usted puede omitir el parámetro COMMITCOUNT y permitir que DB2 confirme tan a menudo como resulte adecuado.
  • Para poder utilizar de mejor manera múltiples CPUs y discos, usted puede ejecutar concurrentemente múltiples comandos importar. Asegúrese de que cada importación se ejecute en su propia conexión a la base de datos y utilice la cláusula "ALLOW WRITE ACCESS" (permitir acceso a procesamiento) a fin de evitar bloqueos de tabla. Usted no necesita que archivos de entrada independientes (DEL files) ejecuten importaciones concurrentes. Cada importación puede leer una sección diferente del mismo archivo de entrada debido a que el comando importar le permite especificar "SKIPCOUNTm ROWCOUNTn" para leer las filas m+1 am+n del archivo de entada.

Para ver otros lineamientos de rendimiento, consulte el artículo “Consejos para mejorar el rendimiento de INSERT en la Base de Datos Universal DB2 " [ver Recursos ].

En suma, conviene ajustar el rendimiento tradicional de las inserciones y los registros para las inserciones e importaciones de XML. Usted podrá ejecutar sesiones de importación paralelas si agrega la cláusula ALLOW WRITE ACCESS (permitir acceso a procesamiento) a cada comando de importación. En DB2 9.5, utilice cargar (load) en lugar de importar.

Consejo 5: Utilice los nuevos elementos del monitor de vistas instantáneas para analizar el rendimiento de XML

Si usted se encuentra analizando el beneficio de contar con diferentes tamaños de páginas u otros aspectos del rendimiento de XML, es probable que le resulte conveniente utilizar el monitor de vistas instantáneas de la manera en que lo haría para los datos relacionales. Usted descubrirá que DB2 9 ofrece nuevos elementos del monitor de vistas instantáneas de conjuntos de buffers para los datos XML que corresponden a los contadores existentes para datos e índices relacionales. Debido a que los datos e índices relacionales se almacenan en diferentes objetos de almacenamiento dentro de un espacio de tabla, los mismos tienen contadores de lectura y escritura independientes. El almacenamiento de pureXML en DB2 9 introduce un nuevo objeto de almacenamiento para datos XML, llamado XDA, que también cuenta con sus propios contadores de conjuntos de buffers.

El ejemplo que se presenta a continuación es un fragmento de código de la información de salida del monitor de vistas instantáneas. Usted verá los diversos elementos del monitor de vistas instantáneas para los tres diferentes objetos de almacenamiento: datos, índice y XDA. Esto le permite monitorear y analizar la actividad de almacenamiento en buffer y de I/O para datos XML de manera independiente de los datos relacionales. Toda actividad relativa a los índices XML se incluye en los contadores de índices existentes. La interpretación de los nuevos contadores XDA es la misma que la de sus correspondientes contadores relacionales. Por ejemplo, una baja proporción de lecturas físicas de XDA en relación con las lecturas lógicas de XDA indica una alta frecuencia de aciertos en el conjunto de buffers para los datos XML, lo cual es de desear. Para más detalles sobre los elementos del monitor de vistas instantáneas del conjunto de buffers, consulte la documentación sobre DB2.

Listado 5. Información de salida del monitor para datos, índices y objetos de almacenamiento XDA
Buffer pool data logical reads  = 221759 
Buffer pool data physical reads = 48580 
Buffer pool temporary data logical reads  = 10730 
Buffer pool temporary data physical reads  = 0 
Buffer pool data writes                    = 6
 
Asynchronous pool data page reads          = 0 
Asynchronous pool data page writes         = 6  
Buffer pool index logical reads            = 8340915 
Buffer pool index physical reads           = 54517 
Buffer pool temporary index logical reads  = 0 
Buffer pool temporary index physical reads = 0 
Buffer pool index writes                   = 0 
Asynchronous pool index page reads         = 0 
Asynchronous pool index page writes        = 0  

Buffer pool xda logical reads              = 2533633 
Buffer pool xda physical reads             = 189056 
Buffer pool temporary xda logical reads    = 374243 
Buffer pool temporary xda physical reads   = 0 
Buffer pool xda writes                     
                   = 0 
Asynchronous pool xda page reads           = 97728 
Asynchronous pool xda page writes          = 0 
Asynchronous data read requests            = 0 
Asynchronous index read requests           = 0 
Asynchronous xda read requests             = 83528

En suma, los nuevos contadores XDA en la información de salida del monitor de vistas instantáneas reflejan la actividad de XML. Resultan útiles para comprender el uso de los conjuntos de buffers, la I/O y el espacio temporal correspondientes a sus datos XML.

Consejo 6: Tenga en cuenta la sobrecarga de la validación del XML Schema

El XML Schema puede definir la estructura, los elementos y atributos, los tipos de datos, los rangos de valores, etc., que se permiten en un conjunto de documentos XML DB2 le permite (de manera opcional) validar documentos XML en función de los XML Schemas. Si usted elige validar documentos, en general lo hará en el momento de la inserción, por dos motivos fundamentales. En primer lugar, la validación asegura que los datos que se insertan en la base de datos cumplen con la definición del esquema: usted evita que ingresen a sus tablas “datos basura”. En segundo lugar, la validación del esquema agrega anotaciones de tipos del esquema a cada uno de los elementos y atributos XML, y estos tipos quedan en el almacenamiento de XML de DB2. Por ejemplo, si un XML Schema define que las ID de los empleados en nuestra tabla departamental (que se muestra en el Consejo 1 ) son tipos de datos enteros, y los documentos se validan en función de ese esquema, DB2 recordará en cada documento que las ID de los empleados son del tipo xs:entero. Todo intento de realizar una comparación de cadenas sobre una ID de un empleado producirá un error de tipo en el momento de la ejecución de la consulta.

La validación del XML Schema es una actividad opcional durante el análisis de la sintaxis de XML. Los estudios de rendimiento han demostrado que el análisis de la sintaxis de XML consume en general mucha más CPU si se encuentra habilitada la validación de esquema [vínculo]. Esta sobrecarga puede variar de manera drástica, según la estructura y el tamaño de sus documentos XML y, en especial, según el tamaño y la complejidad del XML Schema utilizado. Por ejemplo, usted podrá descubrir un consumo de CPU 50% mayor debido a la validación de esquema en esquemas moderadamente complejos. A menos que las inserciones XML dependan en gran medida de I/O, el mayor consumo de CPU se traduce normalmente en una menor capacidad de proceso para las inserciones.

Determine si su aplicación requiere un chequeo de tipos más estricto para las consultas XML y el cumplimiento del XML Schema. Por ejemplo, si usted utiliza un servidor de aplicaciones que recibe, valida y procesa documentos XML antes de que se guarden en la base de datos, los documentos probablemente no necesiten ser validados nuevamente en DB2. En ese momento, usted ya sabe que son válidos. O puede ocurrir quizás que la base de datos recibe documentos XML de una aplicación de confianza, incluso de una que usted controla, y usted sabe que los datos XML son siempre válidos. En ese caso, evite la validación del esquema para lograr una mayor capacidad de proceso de las inserciones. No obstante, si su base de datos DB2 recibe datos XML de fuentes no confiables y usted debe asegurarse del cumplimiento del esquema en el nivel DB2, se verá obligado a gastar algunos ciclos adicionales de CPU en esta tarea.

En suma, para obtener una mayor capacidad de proceso de inserciones, evite realizar validación de esquema en DB2 si no es absolutamente necesario.

Consejo 7: En las expresiones XPath, use rutas de acceso totalmente especificadas en la mayor medida posible

Supongamos que tenemos una tabla con una columna XML

create table customer(info XML);

para gestionar documentos "customerinfo" con la siguiente estructura:

Listado 6. Ejemplo de documento XML
<customerinfo Cid="1004">     
 <name>Matt Foreman</name>     
 <addr country="Canada">           
  <street>1596 Baseline</street>           
  <city>Toronto</city>           
  <state>Ontario</state>           
  <pcode>M3Z-5H9</pcode>     
 </addr>     
 <phone type="work">905-555-4789</phone>     
 <phone type="home">416-555-3376</phone> 
</customerinfo>

Si usted desea recuperar los números telefónicos de los clientes o la ciudad de residencia de los mismos, existen numerosas expresiones de rutas de acceso para obtener estos datos, independientemente de si usted utiliza XQuery o SQL/XML. Tanto de /customerinfo/phone como de //phone se obtendrán los números telefónicos. De la misma manera, /customerinfo/addr/city y /customerinfo/*/city devolverán la ciudad. Para obtener un mejor rendimiento, es preferible utilizar el recorrido totalmente especificado que utilizar *// porque permite que DB2 navegue directamente a los elementos deseados, pasando por sobre las partes irrelevantes del documento.

En otras palabras, si usted conoce la ubicación del elemento deseado dentro del documento, será de ayuda brindar esta información en forma de un recorrido totalmente especificado. Si usted solicita //phone en lugar de /customerinfo/phone, solicitará elementos “teléfono” en cualquier lugar del documento. Esto exigirá a DB2 que navegue al subárbol "addr" del documento para buscar elementosphone en cualquier nivel del documento, lo cual es una sobrecarga que puede evitarse.

Tenga en cuenta que * y // también pueden generar resultados de consultas indeseables o inesperados. Por ejemplo, si algunos de los documentos "customerinfo" también contienen información sobre "assistant"(asistente), como el que aparece a continuación, el recorrido //phone devolverá los teléfonos de los clientes y de los asistentes, sin distinciones entre ellos. Del resultado de la consulta, usted no podrá distinguir entre ellos, y podrá procesar erróneamente los números telefónicos de los asistentes como si fueran los de los clientes.

Listado 7. Elementos teléfono y nombre en múltiples niveles del documento
<customerinfo Cid="1004">     
 <name>Matt Foreman</name>     
 <addr country="Canada">           
  <street>1596 Baseline</street>           
  <city>Toronto</city>           
  <state>Ontario</state>           
  <pcode>M3Z-5H9</pcode>     
</addr>     
<phone type="work">905-555-4789</phone>     
<phone type="home">416-555-3376</phone>     
<assistant>           
      <name>Peter Smith</name>           
      <phone type="home">416-555-3426</phone>      
      </assistant> </customerinfo>

En suma, evite * y // en sus expresiones de recorrido, usando en su lugar rutas de acceso totalmente especificadas, en la medida de lo posible.

Consejo 8: Defina índices XML eficientes, y evite catalogar todo

Supongamos que nuestras consultas a menudo buscan documentos “customerinfo" por nombre de cliente. El índice de los elementos nombre del cliente podrá mejorar en gran medida el rendimiento de estas consultas. Veamos el siguiente ejemplo:

Listado 8. Índices que soportan la búsqueda por nombre de cliente
create table customer(info XML); 
 
create index custname1 on customer(info)  
generate key using xmlpattern '/customerinfo/name' as sql varchar(20); 

create index custname2 on customer(info)  
generate key using xmlpattern '//name' as sql varchar(20);  

select * from customer 
where xmlexists('$i/customerinfo[name = "Matt Foreman"]' passing info as $i);

Los dos índices definidos anteriormente pueden ser utilizados para evaluar el predicado XMLEXISTS en el nombre del cliente. No obstante, el índice custname2 puede resultar sustancialmente más grande que el índice custname1 debido a que contiene entradas no solo de nombres de clientes, sino también de nombres de asistentes. Esto ocurre porque el patron XML //name busca correspondencias de elementos nombre en todo el documento. Pero si nunca realizamos búsquedas por nombre de asistente, no es necesario que estos nombres estén catalogados.

Para las operaciones de lectura, el índice custname1 es más pequeño y por lo tanto tiene un mayor rendimiento potencial. Para las operaciones de inserción, actualización y eliminación, el índice custname1 incurre en sobrecarga de actualización de índice solamente para los nombres de clientes, mientras que el índice custname2 requiere actualización de índice para los nombres de los clientes y los asistentes. Obviamente no le conviene pagar el precio adicional si usted requiere un rendimiento máximo de inserción/actualización/eliminación y no necesita contar con índices para el acceso a los nombres de los asistentes.

Además, considere el siguiente heavyIndex que "cataloga todo". Contiene entradas de índice para todos los nodos de texto, es decir, para cada valor de elemento hoja de cada documento XML de la columna XML. La actualización de este índice es muy costosa durante las operaciones de inserción/actualización /eliminación, ya que consume mucho espacio de almacenamiento, por lo cual no se la recomienda. Como única excepción, se podrían mencionar las aplicaciones con poca actividad de escritura y una carga de trabajo de consultas impredecible de modo tal que resultaría difícil definir índices más específicos.

create index heavyIndex on customer(info)  
generate key using xmlpattern '//text()' as sql varchar(20);

En suma, sea lo más preciso posible al definir índices XML y evite el uso de * y // si puede hacerlo.

Consejo 9: Coloque los predicados de los filtros de documentos en XMLEXISTS en lugar de en XMLQUERY

Analicemos la tabla y los datos siguientes:

create table customer(info XML);
Tabla 2. Tres filas de datos en la tabla de clientes
<customerinfo>
  <name>Matt Foreman</name>     
  <phone>905-555-4789</phone> 
</customerinfo>
<customerinfo>
  <name>Peter Jones</name>     
  <phone>905-123-9065</phone> 
</customerinfo>
<customerinfo>
  <name>Mary Poppins</name>     
  <phone>905-890-0763</phone> 
</customerinfo>

En esta tabla, suponga que desea obtener los nombres de los clientes que tienen el número telefónico "905-555-4789". Usted puede verse tentado de ingresar la siguiente consulta

select xmlquery('$i/customerinfo[phone = "905-555-4789"]/name' passing info as "i")  
from customer;

No obstante, ésta no es la consulta que conviene realizar por múltiples motivos:

  1. La consulta produce el siguiente conjunto de resultados que tiene la misma cantidad de filas que la tabla. Esto ocurre porque el enunciado SQL no incluye una cláusuladóndey por lo tanto no es capaz de eliminar filas.

    <name>Matt Foreman</name>

    3 registro(s) seleccionados

  2. Para cada fila de la tabla que no corresponde al predicado, se genera una fila que contiene una secuencia XML vacía. Esto ocurre porque la expresión XQuery en la función XMLQUERY se aplica a una fila (documento) por vez y nunca elimina una fila del conjunto de resultados, sino que sólo modifica su valor. El valor producido por esa XQuery puede ser el elemento nombre del cliente si el predicado es verdad, o la secuencia vacía en caso contrario. Estas filas vacías son semánticamente correctas (según la norma SQL/XML) y deben ser devueltas si la consulta se escribe de este modo.
  3. El rendimiento de esta consulta no será bueno. En primer lugar, no se puede usar un índice que probablemente exista en /customerinfo/phone porque esta consulta no puede eliminar ninguna fila. Segundo, la obtención de un resultado con numerosas filas vacías hace que la consulta se vuelva innecesariamente lenta.

A fin de resolver los problemas de rendimiento y obtener el resultado deseado, deberá utilizar la función XMLQUERY en la cláusula seleccionar solamente para extraer los nombres de los clientes, y pasar la condición de búsqueda, que eliminará las filas, a un predicado XMLEXISTS en la cláusula dónde. Esto permitirá el uso de índices y filtro de filas, y evitará la sobrecarga de filas de resultados vacías. Formule la consulta de la siguiente manera:

select xmlquery('$i/customerinfo/name' passing info as "i")  
from customer 
where xmlexists('$i/customerinfo[phone = "905-555-4789"]' passing info as "i")
<name>Matt Foreman</name>

1 registro(s) seleccionado(s)

En suma, los predicados en la función XMLQUERY solo se aplican dentro de cada valor XML, de manera que nunca eliminan filas. Los predicados de filtro de documentos y filas deberán colocarse en la función XMLEXISTS.

Consejo 10: Utilice corchetes [ ] para evitar los predicados bulianos en XMLEXISTS

Un error común consiste en formular la consulta anterior sin colocarla entre corchetes en la función XMLEXISTS:

select xmlquery('$i/customerinfo/name' passing info as "i")  
from customer 
where xmlexists('$i/customerinfo/phone = "905-555-4789"' passing info as "i")

Esto producirá el siguiente resultado:

<name>Matt Foreman</name>
<name>Peter Jones</name>
<name>Mary Poppins</name>

3 registro(s) seleccionados

La expresión en el predicado XMLEXISTS se escribe de tal manera que XMLEXISTS siempre evalúa a verdadero En consecuencia, no se elimina ninguna fila. Esto ocurre porque, para una fila dada, el predicado XMLEXISTS evalúa a falso solamente si la expresión XQuery que contiene da como resultado una secuencia vacía. Sin embargo, sin los corchetes, la expresión XQuery es una expresión buliana que siempre produce un valor buliano y nunca produce una secuencia vacía. Obsérvese que XMLEXISTS verifica realmente la existencia de un valor y evalúa a verdadero si existe un valor, incluso cuando dicho valor resulta ser un valor buliano “falso”. Este es el comportamiento correcto según la norma SQL/XML, aunque probablemente no sea lo que usted intenta expresar.

Nuevamente, el impacto consiste en que no se puede usar un índice dephoneporque no se eliminará ninguna fila, y usted recibirá muchas más filas que las que en realidad desea. Además, tenga cuidado de no cometer el mismo error cuando utilice dos o más predicados, como en la siguiente consulta:

Listado 9. Uso incorrecto de dos predicados en XMLEXISTS
select xmlquery('$i/customerinfo/name' passing info as "i")  
from customer 
where xmlexists('$i/customerinfo[phone = "905-555-4789"] and     
               $i/customerinfo[name = "Matt Foreman"]'        
      passing info as "i")

Esta consulta utiliza corchetes. Entonces, ¿qué es lo que está mal? La expresión XQuery sigue siendo una expresión buliana, porque asume la forma de "exp1 y exp2". El siguiente es el modo correcto de formular esta consulta para que filtre filas y permita el uso del índice:

Listado 10. Consulta correcta para filtrar filas y permitir el uso del índice
select xmlquery('$i/customerinfo/name' passing info as "i")  
from customer 
where 
xmlexists('$i/customerinfo[phone = "905-555-4789" and name = "Matt Foreman"]'
passing info as "i")

En suma, no utilice predicados bulianos en XMLEXISTS. Coloque los predicados entre corchetes, incluyendo todas las “y” y “o”.

Consejo 11: Utilice RUNSTATS para reunir estadísticas para los datos e índices XML

El utilitario RUNSTATS ha sido ampliado para recolectar estadísticas sobre datos XML e índices XML. El optimizador de costos de DB2 emplea estas estadísticas para generar planes de ejecución eficientes para las consultas XQuery y SQL/XML. En consecuencia, siga utilizando RUNSTATS como lo haría para los datos relacionales. Si su tabla incluye datos relacionales y XML y usted desea actualizar solamente las estadísticas relacionales, puede ejecutar RUNSTATS con la nueva cláusula "EXCLUDING XML COLUMNS (EXCLUYENDO COLMNAS XML)". Sin esta cláusula, el comportamiento predeterminado y preferido será siempre obtener estadísticas para los datos relacionales y XML.

Tanto para los datos relacionales como para los XML, usted puede habilitar un muestreo con el fin de reducir el tiempo de ejecución de los runstats. En un conjunto mayor de datos, las estadísticas del 10% de los datos (o incluso menos) a menudo resultan representativas de la población total. Cualquiera sea el porcentaje de muestra que usted elija, los runstats le permiten obtener una muestra de las filas (muestreo Bernoulli) o páginas (muestreo del sistema). El muestreo a nivel de las filas lee todas las páginas de datos pero solamente toma en cuenta un porcentaje de las filas de cada página, y por lo tanto, solamente un subconjunto de las páginas XDA correspondientes. El muestreo a nivel de las páginas reduce significativamente la I/O ya que sólo lee un porcentaje de las páginas de datos. En consecuencia, el muestreo de páginas puede mejorar significativamente el rendimiento si su tabla no sólo incluye XML pero también una cantidad considerable de datos relacionales. Sin embargo, el muestreo a nivel de las filas puede producir estadísticas más precisas si los valores de los datos relacionales se encuentran muy agrupados en clusters.

A continuación presentamos algunos ejemplos. El primer comando runstats obtiene las estadísticas más integrales y detalladas para la tabla clientes y todos sus índices sin realizar muestreo alguno. Esto resulta ideal si el tiempo de ejecución lo permite. El segundo comando obtiene las mismas estadísticas pero solamente para el 10% de las páginas. En muchos casos, esto brindará al optimizador estadísticas casi tan precisas como las del primer comando, pero devolverá resultados de manera mucho más rápida. El tercer comando realiza un muestreo del 15 % de todas las filas, no obtiene estadísticas de distribución y aplica el muestreo a los índices, lo cual no fue realizado ni por el primero ni por segundo comando.

Listado 11. Use RUNSTATS para obtener estadísticas
runstats on table myschema.customer  
with distribution on all columns and detailed indexes all; 
 
runstats on table myschema.customer  
with distribution on all columns and detailed indexes all tablesample system (10);  

runstats on table myschema.customer  o
n all columns and sample detailed indexes all tablesample bernoulli (15);

En suma, DB2 genera mejores planes de ejecución si se dispone de estadísticas XML. Use runstats como lo haría normalmente, o use runstats con un muestreo para reducir el tiempo de ejecución.

Consejo 12: Cómo utilizar las vistas de publicación SQL/XML a fin de exponer datos relacionales como XML

Las funciones de publicación de SQL/XML le permiten convertir datos relacionales a un formato XML. Puede resultar beneficioso esconder las funciones de publicación de SQL/XML en una definición de vista, de manera que las aplicaciones u otras consultas puedan simplemente seleccionar los documentos XML construidos desde la vista en lugar de tener que ocuparse de las funciones de publicación mismas

Listado 12. Funciones de publicación de SQL/XML que están escondidas en una vista
create table unit( unitID varchar(8), name varchar(20), manager varchar(20)); 
 
create view UnitView(unitID, name, unitdoc) as    
 select unitID, name,         
  XMLDOCUMENT(           
  XMLELEMENT(NAME "Unit",           
  XMLELEMENT(NAME "ID", u.unitID),           
  XMLELEMENT(NAME "UnitName", u.name),           
  XMLELEMENT(NAME "Mgr", u.manager)             
    )   )   
 from unit u;

Obsérvese que hemos incluido algunas de las columnas relacionales en la definición de la vista. Esto no genera ninguna redundancia física porque se trata solamente de una vista, y no una vista materializada. La exposición de las columnas relacionales ayuda a la consulta eficiente de la vista. Supongamos que debemos obtener un documento XML para una unidad particular. Puede hacerlo con cualquiera de las siguientes tres consultas, aunque la tercera es la que tiende a producir mejores resultados que las dos primeras.

En las primeras dos consultas, el predicado del filtro se expresa en la XML construida. Pero los predicados de XML no pueden aplicarse a la columna relacional subyacente ni a sus índices. Por lo tanto, estas consultas requieren que la vista construya XML para todas las unidades, y que luego elija uno para la unidad "WWPR". Esto no es lo óptimo.

Puede funcionar de una manera que no es óptima:

Listado 13. Consultas que no funcionan de manera óptima
select unitdoc 
from UnitView 
where xmlexists('$i/Unit[ID = "WWPR"]' passing unitdoc as "i");  

for $u in db2-fn:xmlcolumn('UNITVIEW.UNITDOC')/Unit 
where $u/ID = "WWPR" 
return $u;

La tercera consulta utiliza un predicado relacional para asegurar que solamente se construya el documento XML para "WWPR", lo cual producirá un menor tiempo de ejecución, especialmente cuando se trata de grandes conjuntos de datos. Esta consulta funcionará correctamente:

Listado 14. Consultas que funcionan correctamente
select unitdoc 
from UnitView 
where UnitID = "WWPR";

En suma, incluya columnas relacionales en la vista de publicación de SQL/XML, y cuando realice consultas a dicha vista, la misma expresará los predicados solamente en esas columnas, en lugar de en el documento XML construido.

Consejo 13: Cómo utilizar las vistas XMLTABLE para exponer datos XML en formatos relacionales

De la misma manera que puede resultar útil crear una vista para exponer datos relacionales en formato XML, quizás usted desee utilizar una vista para exponer datos XML en formato relacional. Deberán tomarse precauciones similares a las mencionadas en el Consejo 12, pero de modo inverso. Veamos el siguiente ejemplo, donde la función XMLTABLE de SQL/XML se utiliza para producir valores de documentos XML en formato tabular:

Listado 15. Valores producidos a partir de documentos XML en formato tabular
create table customer(info XML);  

create view myview(CustomerID, Name, Zip, Info) as  
SELECT T.*, info  
FROM customer, XMLTABLE ('$c/customerinfo' passing info as "c"     
COLUMNS     
"CID"     INTEGER      PATH './@Cid',    
"Name"    VARCHAR(30)  PATH './name',    
"Zip"     CHAR(12)     PATH './addr/pcode' ) as T;

Obsérvese que hemos incluido información de la columna XML en la definición de la vista para ayudar a que las consultas a esta vista sean eficientes. Supongamos que deseamos recuperar una lista tabular de ID y nombres de clientes para un código postal dado. Esto se puede hacer con las siguientes dos consultas, si bien la segunda tiende a producir mejores resultados que la primera. En la primera consulta, el predicado del filtro se expresa en la columna de caracteres (CHAR) "Zip" generada por la función XMLTABLE. Pero los predicados relacionales no se pueden aplicar a la columna XML subyacente ni a sus índices. Por lo tanto, esta consulta exige que la vista genere filas para todos los clientes, y que luego elija uno para el código postal "95141", lo cual no resulta óptimo. La segunda consulta utiliza un predicado XML para asegurar que sólo se generen las filas para "95141", lo cual produce un tiempo de ejecución menor, especialmente en un gran conjunto de datos..

Listado 16. Consulta con predicado XML
-- may perform suboptimal:  
select CustomerID, Name 
 
from myview 
where Zip = "95141";   

-- will perform well:  

select CustomerID, Name 
from myView 
where xmlexists('$i/customerinfo[addr/pcode = "95141"]' passing info as "i");

Si la tabla base sobre la cual se define la vista contiene no solamente una columna XML sino también columnas relacionales con índices, usted deberá incluir estas columnas relacionales en la definición de la vista. Si las consultas realizadas a la vista contienen predicados altamente restrictivos en las columnas relacionales, DB2 utiliza índices relacionales para filtrar las filas correspondientes hasta llegar a un número menor, y luego aplica XMLTABLE y cualquier otro predicado restante a este resultado interino antes de devolver el conjunto de resultados finales.

En suma, tenga cuidado con las vistas XMLTABLE, que exponen datos XML de manera relacional. Cuando sea posible, agregue columnas adicionales en la definición de la vista de manera que los predicados de filtro puedan quedar expresados en dichas columnas en lugar de en las XMLTABLE.

Consejo 14: Para las consultas breves o aplicaciones OLTP, utilice enunciados SQL/XML con marcadores de parámetros

Las consultas muy breves a bases de datos a menudo se ejecutan tan rápidamente que el tiempo que demanda su compilación y optimización es una porción substancial del tiempo total de respuesta. En consecuencia, resultará útil compilarlas ("preparar") sólo una vez y pasar exclusivamente valores literales de predicado para cada ejecución. Si bien DB2 9 XQuery no admite parámetros externos, las funciones XMLQUERY, XMLTABLE y XMLEXISTS de SQL/XML lo hacen. Le permiten pasar marcadores de parámetros como una variable a las expresiones XQuery insertadas. Esto resulta recomendable para aplicaciones con consultas breves y repetitivas.

Listado 17. Valores literales de predicado de datos insertados
for $c in db2-fn:xmlcolumn('CUSTOMER.INFO')/customer 
where $c/phone = "905-555-4789" 
return $c;  

select info  
from customer 
where xmlexists('$i/customerinfo[phone = "905-555-4789"]'                  
                 passing info as "i")
Listado 18. Con marcador de parámetros
select info  
from customer 
where xmlexists('$i/customerinfo[phone = $p]'                  
                passing info as "i", cast(? as varchar(12)) as "p")

En suma, las consultas breves y las transacciones OLTP son más rápidas cuando cuentan con enunciados preparados con marcadores de parámetros. Para XML, esto requiere que SQL/XML pase parámetros de estilo SQL a las expresiones XQuery.

Consejo 15: Evite la conversión de páginas de códigos durante la inserción y la recuperación de XML

XML difieren de otros tipos de datos en DB2 porque pueden estar codificados interna y externamente. La expresión “codificados internamente” significa que la codificación de nuestros datos XML puede derivarse de los datos mismos. La expresión “codificados externamente” significa que la codificación deriva de información externa. Los tipos de datos de las variables de la aplicación que usted utiliza para intercambiar datos XML con DB2 determina el modo en que se deriva la codificación. Si su aplicación emplea variables del tipo carácter para XML, entonces está extremadamente codificada, es decir, en la página de códigos de la aplicación. Si usted emplea tipos de datos binarios en la aplicación, entonces se considera que los datos XML se encuentran codificados internamente, lo cual significa que la codificación está determinada por ya sea una marca de orden de byte Unicode (BOM) o una declaración de codificación en el documento XML mismo, como por ejemplo

<?xml version="1.0" encoding="UTF-8" ?>

Desde el punto de vista del rendimiento, la meta es evitar en lo posible las conversiones de páginas de códigos, ya que consumen ciclos adicionales de CPU. Los datos XML internamente codificados son preferibles a los datos externamente codificados, ya que pueden evitar las conversiones de páginas de códigos innecesarias. Esto significa que en su aplicación, serán preferibles los tipos de datos binarios sobre los tipos de datos de caracteres. Por ejemplo, en CLI, cuando usted utiliza SQLBindParameter() para vincular marcadores de parámetros a buffers de datos de entrada, deberá utilizar buffers de datos SQL_C_BINARY más que SQL_C_CHAR, SQL_C_DBCHAR, o SQL_C_WCHAR. Al insertar datos XML de aplicaciones Java, la lectura en los datos XML como una cadena binaria (setBinaryStream) resultará mejor que como una cadena (setString). De manera similar, si su aplicación Java recibe XML de DB2 y lo pasa a un archivo, podrá ocurrir la conversión de páginas de códigos si el XML se encuentra escrito como datos no binarios.

Cuando usted recupera datos XML desde DB2 a una aplicación, estos datos se serializan. La serialización es la operación inversa del análisis sintáctico de XML. Es el proceso de convertir el formato XML interno de DB2 (representación similar a un árbol con sintaxis analizada) en un formato XML textual que su aplicación pueda comprender. En la mayoría de los casos, es mejor dejar que DB2 realice una serialización implícita. Esto significa que sus enunciados SQL/XML simplemente eligen valores del tipo XML como en el ejemplo que se muestra a continuación, y DB2 realiza la serialización en las variables de su aplicación de la manera más eficiente posible:

Listado 19. Consulta con serialización implícita
create table customer(info XML);  

select info from customer where...; 
select xmlquery('$i/customerinfo/name' passing info as "i")  
from customer 
where...;

Si su aplicación se ocupa de documentos XML de gran tamaño, puede resultar beneficioso utilizar localizadores LOB para la recuperación de datos. Esto requiere una serialización explícita al tipo LOB, preferiblemente BLOB, porque la serialización explícita a un tipo de carácter como CLOB puede introducir problemas de codificación y conversiones de páginas de códigos innecesarias. La serialización explícita utiliza la función XMLSERIALIZE:

select XMLSERIALIZE(info as BLOB(1M)) from customer where...;

En suma, utilice tipos de datos binarios en su aplicación para intercambiar XML con DB2 ya que de esta manera se evita la conversión de páginas de códigos. Tenga en cuenta los problemas de codificación y ante la menor duda, siga los lineamientos detallados en la documentación sobre DB2 9


Resumen

Un buen comienzo para alcanzar el máximo rendimiento de XML en DB2 consiste en utilizar las características autónomas de DB2, como por ejemplo, el almacenamiento automático y la gestión de memoria auto- ajustable. De esta manera se puede obtener un rendimiento adecuado sin necesidad de configuración para muchas aplicaciones. Además, deja tiempo libre para DBA, lo cual resulta valioso para realizar ajustes más dedicados en cuanto al rendimiento, cada vez que sea necesario. Todos los conocimientos convencionales sobre rendimiento de DB2 corresponden a XML, y los mismos son tratados en una variedad de artículos de developerWorks que se enumeran más adelante.

Además, los 15 consejos de este artículo pueden servir de ayuda para encarar los aspectos de rendimiento más comunes específicos a XML. Si usted necesita mejorar el rendimiento de su aplicación XML, no deberá aplicar los 15 consejos aquí incluidos, sino solamente elegir 1 o 2 de ellos que realmente sirvan para su situación. Por ejemplo, reducir la conversión innecesaria de páginas de códigos no va a ayudarlo si su sistema está muy vinculado a I/O debido a una desafortunada configuración de espacios de tablas. Del mismo modo, el uso de marcadores de parámetros SQL/XML no será de ayuda para el rendimiento de las consultas si usted, en realidad, debe ejecutar runstats para permitir mejores planes de ejecución de consultas. En suma, los consejos de este artículo lo ayudarán a evitar problemas de rendimiento, pero la solución a los problemas de rendimiento observados requiere en primer lugar identificar la causa principal y los cuellos de botella. Las herramientas de diagnóstico estándar de DB2, tales como Visual Explain, db2exfmt, y el monitor de vistas instantáneas, pueden ser utilizadas para investigar el rendimiento de XML , al igual que para los datos relacionales.


Reconocimientos

Agradecemos a Cindy Saracco, Irina Kogan, Henrik Loeser, Nikolaj Richers y Marcus Roy por sus revisiones y por la ayuda que nos prestaron para este artículo.

Recursos

Aprender

  • Artículos relacionados con XML
    • What’s new in DB2 Viper: XML to the core, escrito por Cynthia M. Saracco, analiza la nueva tecnología XML y explica por qué IBM actualmente considera a DB2 como un sistema de gestión de bases de datos (DBMS) “híbrido” o multiestructurado.
    • Query DB2 XML Data with XQuery, escrito por Cynthia M. Saracco, explica cómo consultar los datos almacenados en las columnas XML utilizando SQL y SQL/XML.
    • En Query DB2 XML data with XQuery, escrito por Don Chamberlin y Cynthia M. Saracco, aprenda a consultar datos almacenados en columnas XML usando XQuery.
    • Lea XML Support in DB2 Universal Database, por Matthias Nicola y Bert van der Linden.
    • Lea pureXML in DB2 9: Which way to query your XML data?, escrito por Matthias Nicola y Fatma Ozcan, para obtener información sobre cómo realizar consultas sus datos XML.
    • En DB2 9 XML performance characteristics, escrito por Irina Kogan, Matthias Nicola, y Berni Schiefer, conozca las características de rendimiento y escalabilidad de un entorno de procesamiento de transacciones de corretaje de valores usando DB2 9 pureXML, IBM POWER5+, AIX 5.3, y TotalStorage DS8100.
    • Lea Update XML in DB2 9.5, escrito por Matthias Nicola y Uttam Jain, y descubra cómo modificar datos XML en DB2 de manera eficiente.
    • En XMLTABLE by example, escrito por Matthias Nicola y Vitor Rodrigues, analice el poder de la manipulación de datos XML con SQL/XML.
    • Lea XML Parsing: A Threat to Database Performance, escrito por Matthias Nicola y Jasmi John, para descubrir los temas de investigación que resultan más promisorios para el rendimiento del Analizador XML en los sistemas de bases de datos.
    • Visite el Wiki DB2 pureXML para mantenerse actualizado sobre la tecnología XML en DB2.
  • Lea el artículo Best practices for tuning DB2 UDB v8.1 and its databases, escrito por Fraser McArthur, para obtener la ayuda que necesita para lograr un rendimiento óptimo en su base de datos DB2® UDB y sus aplicaciones.
  • Lea atentamente Top 10 performance Tips, escrito por Scott Hayes, para conocer los consejos de rendimiento para las aplicaciones OLTP de comercio electrónico en DB2 UDB, para los entornos Unix, Windows, y OS/2.
  • Lea DB2 and AIX tuning essentials for DB2 performance, escrito por Artis Walker, para aprender qué es lo que usted puede hacer dentro de AIX para generar mejoras notables en el rendimiento de DB2.
  • DB2 Tuning Tips for OLTP Applications, por Yongli An y Peter Shum, se centra en una variedad de consejos sobre ajustes a DB2 en base a lecciones aprendidas a partir de ejecutar referencias de rendimiento de tipo OLTP (Online Transaction Processing) como TPC-C, TPC-W, Trade2, etc. El rendimiento de una aplicación de base de datos puede estar influenciado por numerosos factores. Este artículo se centra en el aspecto de configuración de DB2.
  • En Tips for improving INSERT performance in DB2 Universal Database el autor, Bill Wilkins, explica exactamente qué es lo que sucede cuando se produce una inserción, analiza alternativas y examina los problemas que afectan el rendimiento de la inserción, como por ejemplo, el bloqueo, la actualización de índices y la gestión de limitaciones.
  • Lea Improve database performance on file system containers in IBM DB2 UDB V8.2 using Concurrent I/O on AIX, escrito por Allen Lee, para comprender los numerosos modelos de I/O de aplicaciones que se encuentran disponibles en AIX y de qué manera DB2 aprovecha la característica CIO.
  • Lea RUNSTATS in DB2 UDB Version 8.2 escrito por Larry Pay, para comprender de qué manera se debe utilizar RUNSTATS, tanto con las opciones existentes como con las nuevas, a fin de obtener el mejor rendimiento para su base de datos.
  • DB2 UDB OLTP tuning illustrated with a Java program por Xiaomei Wang, Wini Mark, Ken Lau y Raul F. Chong, enseña paso a paso las técnicas a seguir para el monitoreo y ajuste de un servidor de bases de datos IBM® DB2® Universal Database™ (UDB).
  • Visite la página de recursos de developerWorks para DB2 para Linux, UNIX, y Windows a fin de leer artículos e instructivos y conectarse con otros recursos para ampliar sus conocimientos de DB2.
  • Aprenda sobre DB2 Express-C, la versión sin costo de DB2 Express Edition para la comunidad.

Obtener los productos y tecnologías

  • Visite el DB2 Snapshot Monitor para descubrir las últimas novedades acerca de esta herramienta y obtener el producto.
  • Descargue una versión de prueba gratuita de DB2 Enterprise 9.
  • Ahora usted puede usar DB2 de manera gratuita. Descargue DB2 Express-C, versión sin costo de DB2 Express Edition para la comunidad, que ofrece las mismas características de datos centrales que DB2 Express Edition y provee una base sólida para construir e implementar aplicaciones.
  • Descargue el DB2 Developer Workbench para obtener un entorno de desarrollo integrado para DB2.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=964111
ArticleTitle=Las 15 mejores prácticas para el rendimiento de pureXML en DB2
publish-date=05262009