Mejora del rendimiento de LOAD

En función de los datos, el objeto de destino y los recursos disponibles, puede realizar determinadas acciones que pueden mejorar el rendimiento de la utilidad LOAD. Por ejemplo, puede preprocesar los datos de entrada o especificar una determinada opción LOAD.

Para mejorar el rendimiento de LOAD, complete una o más de las siguientes acciones recomendadas según corresponda:

• Cargar datos numéricos en formato interno.
  DB2 el formato interno es el formato que se produce al ejecutar UNLOAD con la opción FORMATINTERNAL.
• Si especifica LOAD REPLACE, especifique LOG NO con COPYDDN o RECOVERYDDN para crear una copia en línea.
• Procesar previamente los datos de entrada:

  Realizar cualquier procesamiento previo de los datos de entrada, como se describe en Antes de ejecutar LOAD.

• Clasificar previamente los datos de entrada:

  Para asegurarse de que los datos de entrada están en el orden óptimo, especifique la opción PRESORT. También puede preseleccionar los datos manualmente de la siguiente manera:

  • Ordenar los datos en orden de agrupación para evitar tener que reorganizarlos después de cargarlos.
  • Si está cargando una sola tabla que tiene, como máximo, una clave foránea o una clave de índice, ordene los datos en secuencia de clave. (Se permite un índice sobre una clave externa) Si la clave es una clave de índice, ordene los datos en orden ascendente o descendente, dependiendo de cómo se haya definido el índice. Si la clave es una clave externa, ordene los datos en orden ascendente. Los valores de clave nulos se tratan como valores altos.
  • Si va a cargar más de una tabla, elija uno de los siguientes métodos:
    • Cargue cada tabla por separado. Si utiliza este método, puede seguir las reglas que se enumeran en el punto anterior para cargar tablas individuales.
    • Utilice la cláusula WHEN debajo de cada opción INTO TABLE en su sentencia LOAD para agrupar sus datos de entrada por tabla.
    Dentro de cada tabla, ordene los datos en secuencia de clave.

  Si preclasifica los datos manualmente, especifique la opción PRESORTED YES en la sentencia LOAD.

  
• Evitar conversiones:
  • Si es posible, evite la conversión de datos, como de entero a decimal o de decimal a coma flotante.
  • Evite las conversiones de CCSID y de esquema de codificación, si es posible, cargando datos que tengan el mismo CCSID que la tabla de destino. Si especifica una opción CCSID o de esquema de codificación que no coincide con la de la tabla que se está cargando, pueden producirse conversiones CCSID.

  Información relacionada:

  • Situaciones en las que se produce la conversión de caracteres
• Evite la materialización LOB y XML : Para eliminar la necesidad de cargar LOB grandes o documentos XML en el almacenamiento virtual mientras se ejecuta LOAD, utilice variables de referencia de archivo para los siguientes datos:
  • Para datos XML de más de 32 KB de tamaño.
  • Para datos LOB grandes en una fila con solo 1 LOB. (Los LOB grandes suelen considerarse de 2 MB o más de tamaño)

  En estos casos, LOAD no materializa los datos LOB o XML en la memoria.

• Usa el paralelismo:
  Habilitar LOAD para usar paralelismo cuando sea posible para reducir el tiempo transcurrido para cargar grandes cantidades de datos. Para habilitar el paralelismo, realice una de las siguientes acciones:

  • Si el espacio de la tabla es simple, segmentado (no UTS), particionado (no UTS) o particionado por rango y todos los datos que se van a cargar están en un único conjunto de datos, especifique la palabra clave PARALLEL. Esta palabra clave permite a LOAD utilizar varias subtareas paralelas. Cuando determine el grado de paralelismo que debe especificar en la palabra clave PARALLEL, tenga en cuenta que un alto grado de paralelismo puede dar lugar a un aumento del tiempo de procesamiento. El valor recomendado es especificar PARALLEL(0) o PARALLEL sin un número para que Db2 pueda determinar el grado óptimo de paralelismo.
  • Si el espacio de la tabla está particionado y existen uno o más índices secundarios no particionados, y usted tiene un conjunto de datos de entrada separado para cada partición, utilice el paralelismo de particiones. El paralelismo de particiones carga todas las particiones en un solo trabajo. Para invocar el paralelismo de particiones, especifique la cláusula INTO TABLE PART con una especificación INDDN para cada partición.

  De forma alternativa, si no puede habilitar el paralelismo, utilice varios trabajos para ejecutar LOAD simultáneamente en particiones separadas. Este método también requiere que tenga un conjunto de datos de entrada independiente para cada partición.

  Si habilita el paralelismo, asigne recursos adicionales según sea necesario y ajuste su sistema para evitar una degradación significativa del rendimiento. En concreto, para beneficiarse de las operaciones paralelas cuando se utiliza LOAD SHRLEVEL CHANGE o inserciones paralelas, especialmente cuando se utilizan índices secundarios, realice las siguientes acciones:

  • Utilice un búfer de memoria más grande para mejorar la tasa de aciertos del búfer de memoria.
  • Defina un umbral de escritura diferida más alto para reducir el número de páginas que se escriben en el disco, lo que reduce el tiempo de E/S y la contención.
  • Defina un intervalo de comprobación más largo para reducir el número de páginas que se escriben en el disco, lo que reduce el tiempo de E/S y la contención.
  • Utilice el volumen de acceso paralelo (PAV) de ESS para admitir múltiples E/S simultáneas en el mismo volumen que contiene conjuntos de datos de índices secundarios.
  • Utilice piezas de índice secundario para admitir múltiples E/S de índice secundario simultáneas.

  Para maximizar completamente las tareas paralelas al cargar desde un único conjunto de datos de entrada, especifique explícitamente la palabra clave PARALLEL. Si se carga desde un único conjunto de datos de entrada y no se especifica PARALLEL, el parámetro del subsistema PARAMDEG_UTIL restringe el grado de paralelismo solo para la construcción de índices paralelos.

• Utilizar SORTKEYS:
  La opción SORTKEYS mejora el rendimiento de la clasificación por clave de índice. Con SORTKEYS, las claves de índice se pasan en memoria en lugar de escribirse en archivos de trabajo. Evitar esta E/S en los archivos de trabajo mejora el rendimiento de LOAD. LOAD con SORTKEYS también reduce los requisitos de espacio en disco para los conjuntos de datos de entrada ( SYSUT1 ) y salida (SORTOUT), especialmente si proporciona una estimación del número de claves que se van a ordenar. La opción SORTKEYS reduce el tiempo transcurrido desde el inicio de la fase RELOAD hasta el final de la fase BUILD.

  Para estimar el número de claves a ordenar:

  1. Cuente 1 por cada índice.
  2. Cuente 1 por cada clave externa en la que las definiciones de la clave externa y del índice no sean idénticas.
  3. Para cada clave foránea en la que las definiciones de la clave foránea y del índice sean idénticas:
     1. Cuenta 0 para la primera relación en la que participa la clave externa.
     2. Cuenta 1 para relaciones posteriores en las que participe la clave externa (si la hay).
  4. Multiplique el recuento por el número de filas que se van a cargar.

  Si se está cargando más de una tabla, repita los pasos anteriores para cada tabla y sume los resultados.

• Cree los índices en paralelo:
  Puede reducir el tiempo transcurrido de un trabajo LOAD para un espacio de tabla o partición con más de un índice definido haciendo que LOAD cree los índices en paralelo. Ver Creación de índices en paralelo para LOAD.
• Especifique PREFORMATO:
  PREFORMAT elimina la necesidad de Db2 preformatear nuevas páginas en un espacio de tabla durante el tiempo de ejecución.

  Db2 el preformateo a veces causa un retraso, lo que puede afectar al rendimiento o a la coherencia del tiempo de ejecución de las aplicaciones que realizan muchas inserciones o trabajos de CARGA con CAMBIO DE NIVEL DE SISTEMA. Cuando se produzcan estos retrasos y pueda predecir el tamaño de la tabla para un ciclo de procesamiento empresarial, considere la posibilidad de utilizar LOAD PREFORMAT o REORG PREFORMAT. Esta técnica solo es útil cuando Db2 el preformateo provoca un retraso medible en el procesamiento o provoca tiempos de aplicación inconsistentes transcurridos para operaciones INSERT o trabajos LOAD RESUME YES SHRLEVEL CHANGE.

  Recomendación : Evalúe el rendimiento antes y después de utilizar LOAD PREFORMAT o REORG PREFORMAT para cuantificar su valor en su entorno.

  El uso de PREFORMAT podría eliminar los retrasos en el tiempo de ejecución, pero añade tiempo de configuración antes de la ejecución de la aplicación. El coste de esta mejora es un aumento en el tiempo de CARGA o REORGANIZACIÓN, porque la utilidad debe preformatear todas las páginas entre los datos que se cargan o reorganizan y el RBA de alta asignación. El tiempo adicional de CARGA o REORGANIZACIÓN que se requiere depende de la cantidad de espacio en disco que se está preformateando. Cuando se utiliza este espacio preformateado y Db2 es necesario ampliar el espacio de la tabla, se produce la ampliación y el preformateo normales del conjunto de datos.

  Considere utilizar el preformateo para el procesamiento LOAD SHRLEVEL CHANGE o INSERT en las siguientes situaciones:

  • Para tablas en las que se realizan muchas inserciones y que reciben una cantidad predecible de datos. En este caso, todo el espacio necesario puede preasignarse antes de la ejecución de la aplicación.
  • Para una tabla que actúa como un repositorio de elementos de trabajo que entran en un sistema y que luego se utilizan para una tarea de fondo que procesa los elementos de trabajo.
  • Para espacios de tabla que empiezan vacíos y se rellenan con muchas inserciones antes de que se ejecute cualquier consulta de acceso contra el espacio de tabla.

  No se recomienda CARGAR PREFORMATO o REORGANIZAR PREFORMATO para tablas que tienen una alta proporción de lecturas a inserciones si las lecturas dan como resultado escaneos de espacio de tabla. En este caso, el preformateo de un espacio de tabla que contiene una tabla que se utiliza para el procesamiento de consultas puede hacer que los escaneos del espacio de tabla lean páginas vacías adicionales. Esta lectura adicional puede prolongar el tiempo transcurrido para estas consultas.

  La combinación de inserciones y consultas no indexadas en un espacio de tabla preformateado podría tener un impacto negativo en el rendimiento de la consulta sin proporcionar una mejora compensatoria en el rendimiento de la inserción. Por lo general, PREFORMAT ofrece los mejores resultados cuando existe una alta proporción de inserciones con respecto a las operaciones de lectura.

  Además, tenga en cuenta las siguientes implicaciones de PREFORMAT en sus conjuntos de datos:

  • Para los conjuntos de datos gestionados por el usuario, Db2 no los elimina ni los reasigna durante el procesamiento de la utilidad. El tamaño del conjunto de datos no se reduce al tamaño de asignación del conjunto de datos original, sino que permanece igual o aumenta de tamaño si se añade más espacio o datos. Esta característica tiene implicaciones cuando se utiliza LOAD o REORG PREFORMAT debido al preformateo que se realiza para todas las páginas libres entre el RBA (o página) de alta utilización y el RBA de alta asignación. Este preformateo incluye extensiones secundarias que han sido asignadas.
  • Para Db2 -conjuntos de datos gestionados, Db2 los elimina y reasigna si especifica REPLACE en el trabajo LOAD o REORG. Este comportamiento da como resultado que los conjuntos de datos se redimensionen a su tamaño de asignación original. Mantienen ese tamaño si los datos que se están recargando no llenan la asignación primaria y fuerzan una asignación secundaria. Por lo tanto, CARGAR PREFORMATO o REORGANIZAR PREFORMATO con Db2 -datos gestionados hace que al menos la cantidad total de asignación primaria de un conjunto de datos se preformatee después de que los datos se vuelvan a cargar en el espacio de tabla.
  • Tanto para los conjuntos de datos gestionados por el usuario como para los Db2 -conjuntos de datos gestionados, si el conjunto de datos pasa a extensiones secundarias durante el procesamiento de la utilidad, el RBA de alta asignación se convierte en el final de la extensión secundaria. Ese valor se convierte en el valor alto para el preformateo.