Mejores prácticas para el rendimiento XML en Db2

Elija detenidamente la granularidad de los documentos XML

Cuando diseñe la aplicación XML, en concreto la estructura de los documentos XML, puede definir qué datos empresariales se deben guardar juntos en un solo documento XML.

Por ejemplo, cada documento XML de los datos de los departamentos de ejemplo contiene información sobre un departamento.

CREATE TABLE DEPT(UNITID CHAR(8), DEPTDOC XML);

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

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

Esta granularidad intermedia es una opción razonable si un departamento es la granularidad predominante con la que la aplicación accede a los datos y los procesa. Como alternativa, puede optar por combinar varios departamentos en un solo documento XML, como, por ejemplo, los que pertenecen a una sola unidad. Sin embargo, esta basta granularidad no es la óptima si la aplicación suele procesar los departamentos de uno en uno.

También puede elegir un documento XML por empleado con un atributo "dept" adicional para cada empleado a fin de indicar a qué departamento pertenece. Esta granularidad fina constituye una buena opción si los empleados utilizan los objetos empresariales que les interesan, a los que generalmente acceden y procesan independientemente de otros empleados del mismo departamento. Sin embargo, si la aplicación suele procesar todos los empleados de un departamento juntos, un documento XML por departamento puede ser una opción mejor.

Utilice los atributos y los elementos correctamente en XML

Una pregunta común relacionada con el diseño de documentos XML es cuándo utilizar atributos en lugar de elementos y cómo esta opción afecta al rendimiento.

Esta pregunta es mucho más relevante para el modelado de datos que para el rendimiento. Sin embargo, como regla general, los elementos XML son más flexibles que los atributos porque se pueden repetir y anidar.

Por ejemplo, los documentos de departamento que se han mostrado en el ejemplo anterior utilizan un elemento "phone" que permite varias apariciones de "phone" para un empleado que tenga varios números. Este diseño también se amplia en el caso de que más adelante tengamos que dividir los números de teléfono en fragmentos, como elementos hijo para un código de país, código de área, extensión, etc.

Por el contrario, si "phone" es un atributo del elemento empleado, solo puede haber uno por empleado y no puede añadir elementos hijo. Estas limitaciones pueden impedir una futura evolución del esquema.

Aunque probablemente modelará todos los datos sin utilizar atributos, estos pueden resultar una opción intuitiva para elementos de datos sobre los que se sabe que no se repiten para un solo elemento y que no tienen subcampos. Los atributos pueden reducir ligeramente el tamaño de los datos XML porque solo tienen un par nombre-valor, al contrario que los elementos, que tienen un código de inicio y uno de finalización.

En Db2, puede utilizar atributos en consultas, predicados y definiciones de índice con la misma facilidad que los elementos. Como los atributos son menos extensibles que los elementos, Db2 puede aplicar determinadas optimizaciones de almacenamiento y acceso. Sin embargo, estas ventajas se pueden considerar una adición extra al rendimiento en lugar de un incentivo para convertir elementos en atributos para mejorar el rendimiento, especialmente cuando las consideraciones sobre el modelado de datos sugieren el uso de elementos.

Tenga en cuenta la sobrecarga que supone la validación del esquema XML

La validación del esquema XML es una actividad opcional durante el análisis de XML. Los estudios sobre rendimiento muestran que el análisis de XML en general consume bastante más CPU si la validación de esquemas está habilitada.

Esta sobrecarga puede varias significativamente en función de la estructura y del tamaño de los documentos XML y en particular del tamaño y la complejidad del esquema XML utilizado. Por ejemplo, puede que se consuma un 50% más de CPU debido a la validación del esquema con esquemas moderadamente complejos. A no ser que las inserciones XML estén estrechamente vinculadas a E/S, el aumento en el consumo de CPU suele traducirse en un menor rendimiento de las inserciones.

Un esquema XML define la estructura, los elementos y atributos, los tipos de datos y los rangos de valores permitidos en un conjunto de documentos XML. Db2 le permite validar documentos XML con respecto a esquemas XML. Si elige validar documentos, generalmente esto se realiza en el momento de la inserción. La validación asegura que los datos insertados en la base de datos cumplen con la definición del esquema, lo que significa que se mejora la integridad de los datos que entren en las tablas.

Piense en el impacto sobre el rendimiento al determinar si la aplicación necesita la comprobación de tipo más estricto para consultas XML y conformidad de esquemas XML. Por ejemplo, si utiliza un servidor de aplicaciones que recibe, valida y procesa documentos XML antes de que se almacenen en la base de datos, es probable que los documentos no tengan que volverse a validar en Db2. En este momento ya sabe que son válidos. Paralelamente, si la base de datos recibe documentos XML de una aplicación fiable, incluso de una que el usuario controla, y sabe que los datos XML siempre son válidos, evite la validación para mejorar el rendimiento de las inserciones. Pero si la base de datos de Db2 recibe datos XML de orígenes que no son fiables y necesita asegurarse de que se cumple el esquema en el nivel de Db2, debe pasarse algunos ciclos de CPU adicionales en eso.

Para obtener más información, consulte:

• Validación del esquema XML
• Requisitos previos para utilizar pureXML

Especifique vías de acceso completas en expresiones XPath siempre que sea posible

Cuando sepa en qué punto de la estructura de un documento XML está ubicado el elemento, es mejor proporcionar dicha información en forma de una vía de acceso completa para evitar una sobrecarga innecesaria.

Observe la tabla que se crea mediante la siguiente sentencia de SQL.

CREATE TABLE customer(info XML);

La siguiente figura muestra datos de ejemplo en la columna info.

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

Si desea recuperar números de teléfono de clientes o las ciudades en las que viven, puede elegir entre varias expresiones de vías de acceso posibles para obtener estos datos.

Tanto /customerinfo/phone como //phone le ofrecen los números de teléfono. Paralelamente, tanto /customerinfo/addr/city como /customerinfo/*/city devuelven la ciudad. Para un mejor rendimiento, se prefiere la ruta totalmente especificada en lugar de utilizar * o // porque la ruta totalmente especificada permite a Db2 navegar directamente a los elementos, omitiendo las partes no relevantes del documento. Si pregunta por //phone en lugar de por /customerinfo/phone, pregunta por elementos de teléfono en cualquier punto del documento. Esto requiere que el navegador Db2 se desplace hacia abajo en el subárbol "addr" del documento para buscar elementos de teléfono en cualquier nivel del documento.

Utilizar * y // también puede producir resultados de consulta inesperados (por ejemplo, si algunos de los documentos "customerinfo" también contienen información sobre "assistant", como se muestra en la siguiente figura). La vía de acceso //phone devolvería los teléfonos de los clientes y los números de teléfono de los ayudantes, sin distinguir entre ellos. A partir de los resultados de la consulta podría procesar por error el teléfono del ayudante como si fuera el número de teléfono de un cliente.

<customerinfo Cid="1004">
    <name>Matt Foreman</name>
    <addr country="Canada">
          <street>1596 Baseline</street>
          <city>Toronto</city>
          <state/>Ontario
          <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>

Defina índices de apoyo para datos XML a fin de evitar una sobrecarga

Supongamos que las consultas suelen buscar documentos XML "customerinfo" por nombre de usuario. Un índice en el elemento de nombre de cliente, tal como se muestra en las siguientes sentencias, puede mejorar significativamente el rendimiento de estas consultas.

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 evaluar el predicado XMLEXISTS en el nombre de cliente. Sin embargo, el índice custname2 puede ser significativamente mayor que el índice custname1 porque contiene entradas de índice no solo de nombres de cliente, sino también de nombres de ayudante. Esto se debe a que el patrón XML //name coincide con elementos name del cualquier punto del documento. Sin embargo, si nunca buscamos por nombre de ayudante, no necesitamos indexarlos.

Para operaciones de lectura, el índice custname1 es menor y por lo tanto potencialmente ofrece un mejor rendimiento. Para operaciones de inserción, actualización y supresión, el índice custname1 incurre en una sobrecarga de mantenimiento de índice solo para nombres de cliente, mientras que el índice custname2 requiere un mantenimiento de índice para nombres de cliente y de ayudante. Definitivamente no deseará pagar el precio adicional si desea obtener un máximo rendimiento de inserción, actualización y supresión y no necesita un acceso indexado basado en nombres de ayudante.

Para obtener más información, consulte:

• Estructura de almacenamiento para datos XML
• Indexación de datos XML
• Métodos de acceso con índices XML

Utilice XMLEXISTS para predicados que filtren a nivel de documento

Consideremos la tabla y los datos de ejemplo siguientes:

CREATE TABLE customer(info XML);

<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 Clark</name>
    <phone>905-890-0763</phone>
</customerinfo>

Supongamos por ejemplo que desea devolver los nombres de los clientes que tienen el número de teléfono "905-555-4789". Puede estar tentado de escribir la siguiente consulta.

SELECT XMLQUERY('$i/customerinfo[phone = "905-555-4789"]/name' passing info as "i") 
FROM customer;

Sin embargo, esta consulta no es lo que desea por varios motivos:

• Devuelve el siguiente conjunto de resultados, que tiene tantas filas como tiene la tabla. Esto se debe a que la sentencia de SQL no tiene cláusula where, y por lo tanto no puede eliminar ninguna fila. El resultado se muestra en la siguiente figura.

  <name>Matt Foreman</name>
  
  3 record(s) selected

• Para cada fila de la tabla que no coincide con el predicado se devuelve una fila que contiene una secuencia XML vacía. Esto se debe a que la expresión XQuery de la función XMLQUERY se aplica a una fila, o documento, cada vez y nunca elimina una fila del conjunto de resultados, únicamente modifica su valor. El valor generado por esta XQuery es el elemento name del cliente si el predicado es verdadero o la secuencia vacía si no lo es. Estas filas vacías son semánticamente correctas, según el estándar SQL/XML, y deben devolverse si la consulta se escribe tal como se ha mostrado.
• El rendimiento de la consulta es bajo. En primer lugar, no se puede utilizar un índice existente en /customerinfo/phone porque esta consulta no puede eliminar ninguna fila. En segundo lugar, el hecho de devolver muchas filas vacías hace que la consulta resulte innecesariamente lenta.

Para resolver los problemas de rendimiento y obtener la salida que desea, utilice la función XMLQUERY en la cláusula select para extraer solo los nombres de cliente y mover la condición de búsqueda, que debería eliminar filas, a un predicado XMLEXISTS de la cláusula WHERE. Esto permitirá utilizar el índice, filtrar las filas y evitar la sobrecarga derivada de las filas resultantes vacías. Podría escribir la consulta tal como se muestra en la siguiente figura.

SELECT XMLQUERY('$i/customerinfo/name' passing info as "i") 
FROM customer
WHERE XMLEXISTS('$i/customerinfo[phone = "905-555-4789"]' passing info as "i")

Para obtener más información, consulte:

• Predicado XMLEXISTS para consultar datos XML
• Predicado XMLEXISTS

Utilice corchetes para evitar predicados booleanos en XMLEXISTS

Un error común consiste en escribir la consulta anterior sin los corchetes en la función XMLEXISTS, tal como se muestra en la siguiente consulta.

SELECT XMLQUERY('$i/customerinfo/name' passing info as "i") 
FROM customer
WHERE XMLEXISTS('$i/customerinfo/phone = "905-555-4789"' passing info as "i")

Esta consulta genera los resultados que se muestran en la siguiente figura.

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

3 record(s) selected

La expresión del predicado XMLEXISTS se ha escrito de modo que XMLEXISTS siempre se evalúe como verdadero. Por lo tanto, no se elimina ninguna fila. Para una determinada fila, el predicado XMLEXISTS solo se evalúa como falso si la expresión XQuery que contiene devuelve la secuencia vacía. Sin embargo, sin los corchetes la expresión XQuery es una expresión booleana que siempre devuelve un valor booleano y nunca la secuencia vacía. Observe que XMLEXISTS comprueba la existencia de un valor y se evalúa como verdadero si el valor existe, aunque dicho valor sea el valor booleano "false". El comportamiento es correcto según el estándar SQL/XML, aunque probablemente no sea lo que pretende expresar.

De nuevo, el efecto es que no se puede utilizar un índice sobre phone porque no se eliminará ninguna fila y recibirá muchas más filas de las que desea. Tenga también cuidado de no caer en el mismo error cuando utilice dos o más predicados, tal como se muestra en la siguiente consulta.

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")

La expresión XQuery sigue siendo una expresión booleana porque tiene el formato "exp1 and exp2." Podría escribir la consulta tal como se muestra en el siguiente ejemplo para filtrar filas y permitir el uso de un í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")

Para más información, consulte Expresiones lógicas.

Utilice RUNSTATS para recopilar estadísticas para datos XML e índices

El programa de utilidad RUNSTATS se ha ampliado para recopilar estadísticas sobre tablas e índices XML y el optimizador de Db2 utiliza estas estadísticas para generar un plan de ejecución eficaz para consultas XML. Por lo tanto, continúe utilizando RUNSTATS en tablas XML e índices, tal como lo haría para datos relacionales. Es necesario que especificar nombres de espacios de tabla XML de forma explícita o utilizar LISTDEF para incluir todos los objetos (ALL) o solo objetos XML a fin de obtener las estadísticas de la tabla XML.

Para obtener más información, consulte:

• Recopilación de estadísticas sobre objetos XML
• RUNSTATS

Utilice vistas de publicación SQL/XML para exponer datos relacionales como XML

Puede incluir columnas relacionados en una vista de publicación SQL/XML y, cuando consulte la vista, exprese los predicados sobre estas columnas en lugar de hacerlo sobre el XML construido.

Las funciones de publicación de SQL/XML le permiten convertir datos relacionales al formato XML. Puede resultar recomendable ocultar las funciones de publicación de SQL/XML en una definición de vista. Las aplicaciones u otras consultas pueden simplemente seleccionar los documentos XML construidos a partir de la vista en lugar de tener que utilizar las propias funciones de publicación. Las siguientes sentencias crean una vista que contiene funciones de publicación de SQL/XML ocultas.

CREATE TABLE unit( unitID char(8), name char(20), manager varchar(20));

CREATE VIEW UnitView(unitID, name, unitdoc) as
   SELECT unitID, name, 
          XMLELEMENT(NAME "Unit",
             XMLELEMENT(NAME "ID", u,unitID),
             XMLELEMENT(NAME "UnitName", u.name),
             XMLELEMENT(NAME "Mgr", u.manager)
                  )
   FROM unit u;

Observe que la definición de vista incluye columnas relacionales. Esto no crea ninguna redundancia física, ya que es solo una vista, no una vista materializada. El hecho de exponer las columnas relacionales ayuda a consultar esta vista de forma eficiente.

La siguiente consulta utiliza un predicado relacionas para asegurar que solo se construye el documento XML correspondiente a "WWPR", lo que reduce el tiempo de ejecución, especialmente en el caso de conjuntos de datos grandes.

SELECT unitdoc
FROM UnitView
WHERE unitID = "WWPR";

Utilice vistas XMLTABLE para exponer datos XML en formato relacional

Es posible que también desee utilizar una vista para exponer datos XML en formato relacional. Se tiene que tener cuidado como en el caso anterior, pero en el orden inverso. En el siguiente ejemplo, la función de SQL/XML XMLTABLE devuelve valores procedentes de documentos XML en formato de tabla.

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;

La definición de la vista incluye una columna XML para ayudar a consultar la vista de forma eficiente. Supongamos que desea recuperar una lista en formato de tabla de los ID de cliente y nombres correspondientes a un determinado código postal (ZIP). Ambas consultas pueden hacerlo, pero la segunda tiene a ofrecer un mejor rendimiento que la primera.

En la primera consulta, el predicado de filtrado se expresa en la columna CHAR "Zip" que genera la función XMLTABLE. Sin embargo, no todos los predicados relacionales se pueden aplicar a la columna XML o a los índices subyacentes. Por lo tanto, la consulta necesita que la vista genere filas para todos los clientes y luego elige la correspondiente al código postal "95141".

SELECT CustomerID, Name 
FROM myview
WHERE Zip = '95141';

La segunda consulta utiliza un predicado XML para asegurar que solo se generan filas correspondientes a "95141", lo que reduce el tiempo de ejecución, especialmente en un conjunto de datos de gran tamaño.

SELECT CustomerID, Name
FROM myView
WHERE xmlexists('$i/customerinfo[addr/pcode = "95141"]' passing info as "i");

Utilice sentencias de SQL y XML con marcadores de parámetros para reducir las consultas y aplicaciones OLTP

Las funciones de SQL/XML XMLQUERY, XMLTABLE y XMLEXISTS dan soporte a parámetros externos.

Las consultas de base de datos muy cortas suelen ejecutarse tan rápido que el tiempo necesario para compilarlas y optimizarlas constituye una parte importante del tiempo total de respuesta. Por lo tanto, es posible que desee compilarlas, o "prepararlas," solo una vez y pasar únicamente valores literales de predicado para cada ejecución. Esta técnica se recomienda para aplicaciones con consultar cortas y repetitivas. La siguiente consulta muestra cómo puede utilizar marcadores de parámetro para conseguir el resultado del ejemplo anterior.

SELECT info 
FROM customer
WHERE xmlexists('$i/customerinfo[phone = $p]' 
                passing info as "i", cast(? as varchar(12)) as "p")

Evite la conversión de página de códigos durante inserciones y recuperaciones de XML

XML es diferente de otros tipos de datos de Db2 porque se puede codificar interna y externamente. La codificación interna significa que la codificación de los datos XML se puede derivar de los propios datos. La codificación externa significa que la codificación se deriva de información externa.

El tipo de datos de las variables de aplicación que se utilizan para intercambiar datos XML con Db2 determina cómo se deriva la codificación. Si la aplicación utiliza variables de tipo carácter para XML, se codifica externamente. Si utiliza tipos de datos de aplicación binaria, los datos XML se consideran codificados internamente.

La codificación interna significa que la codificación se determina mediante una marca de orden de bytes Unicode (BOM) o una declaración de codificación en el propio documento XML, como por ejemplo: <?xml version="1.0" encoding="UTF-8" ?>

Desde el punto de vista de rendimiento, el objetivo es evitar conversiones de página de códigos siempre que sea posible porque consumen ciclos adicionales de CPU. Los datos XML codificados internamente resultan más recomendables que los datos codificados externamente, ya que evitan la conversión innecesaria de página de códigos.

Esto significa que la aplicación debe elegir tipos de datos binarios sobre datos de tipo carácter. Por ejemplo, en ODBC, cuando utiliza SQLBindParameter() para enlazar marcadores de parámetro con almacenamientos intermedios de datos de entrada, debe utilizar almacenamientos intermedios de datos SQL_C_BINARY en lugar de SQL_C_CHAR, SQL_C_DBCHAR o SQL_C_WCHAR. En aplicaciones de sistema principal, utilice XML AS BLOB como tipo de variable de lenguaje principal.

Al insertar datos XML desde aplicaciones Java™, es mejor leer los datos XML como un flujo binario (setBinaryStream) que como una cadena (setString). Del mismo modo, si su aplicación Java recibe XML de Db2 y lo escribe en un archivo, puede producirse una conversión de página de código si el XML se escribe como datos no binarios.

Cuando se recuperan datos XML de Db2 en la aplicación, se serializan. La serialización es la operación inversa al análisis de XML. Es el proceso que Db2 utiliza para convertir el formato XML interno, que es una representación parecida a un árbol, al formato XML de texto que la aplicación puede entender. En la mayoría de los casos es mejor dejar que Db2 realice una serialización implícita. Esto significa que las sentencias SQL/XML seleccionan simplemente valores de tipo XML como se muestra en el ejemplo siguiente y que Db2 realiza la serialización en las variables de aplicación de la forma más eficaz posible.

CREATE TABLE customer(info XML);

SELECT info FROM customer WHERE...;

SELECT XMLQUERY('$i/customerinfo/name' passing info as "i")
FROM customer
WHERE...;

Si la aplicación utiliza documentos XML muy grandes, puede resultar beneficioso utilizar localizadores de LOB para la recuperación de datos. Esto requiere una serialización explícita a un tipo LOB, preferiblemente BLOB, puesto que la serialización explícita a un tipo carácter como CLOB puede conllevar problemas de codificación y una conversión innecesaria de página de códigos. La serialización explícita utiliza la función XMLSERIALIZE, tal como se muestra en el siguiente ejemplo.

SELECT XMLSERIALIZE(info as BLOB(1M)) FROM customer WHERE...;

Utilice la sentencia XMLMODIFY para actualizar parte de un documento XML

Cuando necesita modificar sólo una parte de un documento XML, puede utilizar la función XMLMODIFY para realizar los cambios en los datos XML mejor que sustituyendo todo el documento XML, especialmente cuando los documentos XML tienen un gran tamaño. En el caso de documentos XML pequeños, no se logra ninguna ventaja de rendimiento mediante la sentencia XMLMODIFY para documentos que caben en un registro único.

Cuando una aplicación no utiliza la sentencia XMLMODIFY para actualizar una columna XML, el documento XML de la columna XML se suprime completamente y se sustituye por un nuevo documento XML. Cuando se utiliza XMLMODIFY para actualizar una columna XML, sólo se deben suprimir o sustituir las filas del espacio de tablas XML que se han modificado con la función XMLMODIFY.

Para obtener más información, consulte:

• Actualizaciones parciales de documentos XML
• Función escalar XMLMODIFY

Utilice el Extensible Dynamic Binary XML Db2 Client/Server Binary XML Format para los datos de entrada para documentos XML analizados

El análisis de datos XML es uno de los factores más importantes que afectan al rendimiento durante las operaciones INSERT, LOAD y UPDATE de datos XML. Si utiliza Extensible Dynamic Binary XML Db2 Client/Server Binary XML Format cuando se insertan, actualizan o cargan datos, la sobrecarga de CPU se reduce. Db2 DRDA zIIP redirección no se ve afectada por XML binario, pero z/OS Servicios de sistemas XML zIIP y zAAP se ven afectados por el XML binario porque no es necesario el análisis.

El envío de datos de un Extensible Dynamic Binary XML Db2 Client/Server Binary XML Format a desde una aplicación Java en un cliente reduce el tiempo de CPU necesario en el servidor de Db2 . Sin embargo, el análisis de los datos XML en formato binario lo realiza el IBM® Data Server Driver for JDBC and SQLJ que se ejecuta en el cliente. El tiempo transcurrido de la clase 1 en el cliente puede aumentar si se compara con el envío de XML textual. Utilice XML binario para reducir el tiempo de CPU en el servidor Db2 si el aumento del tiempo transcurrido no afecta a su entorno.

Tenga en cuenta el rendimiento cuando decida utilizar XPath o XQuery

En general, si realiza operaciones similares mediante XQuery y XPath, el rendimiento debería ser similar. Sin embargo, en determinadas situaciones, XPath podría proporcionar un mejor rendimiento.

Para obtener más información, consulte:

• Aplicaciones recomendadas de XQuery o XPath
• Visión general de XQuery
• Selección de datos XML

Acceso rápido a datos XML mediante FETCH WITH CONTINUE

Utilice la sentencia FETCH WITH CONTINUE para mejorar el rendimiento de algunas consultas que hacen referencia a columnas XML con longitudes máximas desconocidas o muy grandes.