Usar efectivamente las utilidades de movimiento de datos de DB2 en un entorno de depósito de datos

Formas sencillas de renovar su depósito de datos que no es de producción desde la producción

Elegir las utilidades y metodologías apropiadas de movimiento de datos es clave para mover eficientemente datos entre distintos sistemas en un entorno grande de depósito de datos. Para ayudarle con sus tareas de movimiento de datos, este artículo proporciona conocimientos sobre los pros y contras de cada método con IBM® InfoSphere® Warehouse e incluye un estudio comparativo de los diversos métodos usando código real de DB2® para el movimiento de datos.

Mohankumar Saraswatipura, DB2 Database Administrator, Reckitt Benckiser plc

Mohankumar Saraswatipura photoMohan trabaja como un DB2 Database Administrator líder en Reckitt Benckiser plc enfocándose en soluciones de inteligencia empresarial de almacenes balanceados, el ajuste del rendimiento de aplicaciones y la migración/implementación de DB2. Mientras que con IBM Software Lab, India, trabajó con el equipo de High Performance On Demand Solutions (HiPODS) para proporcionar las soluciones de rendimiento para clientes. Antes trabajó con el equipo de desarrollo de productos de DB2 en la India. Mohan es un DB2 Advanced Database Administrator, DB2 Application Developer y DB2 Problem Determination Master certificado por IBM. Mohan completó su M Tech (Maestría en Tecnología) en ciencias computacionales en el año 2004 y su MBA Ejecutivo en IIMC en el año 2007.



30-04-2012

Introducción

Las utilidades de movimiento de datos en DB2 son fáciles de usar con un entorno de base de datos de una sola partición. Sin embargo, existen consideraciones extra cuando se trata de un entorno grande de depósito de datos que tiene terabytes de tablas STAGING, STORE y DATAMART en el entorno de Database Partition Feature (DPF) de InfoSphere Warehouse. En este artículo, veremos las opciones de movimiento de datos disponibles en DB2 y los mejores métodos adecuados para el entorno de depósito de datos.

Opciones de movimiento de datos de DB2

La tabla a continuación lista las opciones de movimiento de datos disponibles en DB2 9.7, junto con una descripción de cómo es comúnmente usada cada una y un ejemplo.

Tabla 1. Opciones de movimiento de datos disponibles en DB2
Nombre de la utilidadPropósitoUso prácticoEjemplo
ExportPara exportar datos de una tabla de base de datos a un archivoEste método puede ser usado si desea mantener los datos de tabla en un archivo para su uso futuro o para renovar otro entorno a partir de los datos actuales.EXPORT TO DATAMART. F_CUST_PROF.DEL OF DEL MESSAGES DATAMART. F_CUST_PROF.EXPORT.MSG SELECT * FROM DATAMART.F_CUST_PROF;
LoadPara realizar inserciones de datos rápidas en una tabla existente en la base de datosEsta es la utilidad que está buscando si su principal preocupación es el rendimiento de la inserción de datos. Inserta páginas formateadas en la base de datos en lugar de una inserción de fila por fila. El administrador/usuario de la base de datos también puede elegir no registrar la actividad en los registros de transacción. Pero tenga en cuenta que esta utilidad tiene la posibilidad de explotar completamente los recursos del sistema.LOAD FROM DATAMART. F_CUST_PROF.DEL OF DEL SAVECOUNT 10000 MESSAGES DATAMART. F_CUST_PROF.LOAD.MSG INSERT INTO DATAMART.F_CUST_PROF;
ImportPara insertar datos de un archivo en una tabla o vistaEsta utilidad es benéfica al insertar datos en una vista y tabla que tengan una restricción y cuando su intención no sea colocar la tabla en el estado 'set integrity'. También es útil si tiene desencadenantes y desea que sean activados mientras se insertan los datos.IMPORT FROM DATAMART. F_CUST_PROF.DEL OF DEL COMMITCOUNT 1000 MESSAGES DATAMART. F_CUST_PROF.IMPORT.MSG INSERT INTO DATAMART. F_CUST_PROF;

Si tiene un archivo de datos de formato IXF, puede crear una tabla e insertar datos en un solo comando, si la tabla no existe en el entorno de destino
db2moveCopia tablas de un entorno en otro al nivel de esquema (múltiples tablas en general)Cuando tiene muchas tablas que necesiten ser copiadas entre entornos con base en el esquema, esto puede conseguirse fácilmente usando db2move con la opción COPY.Exportar todas las tablas desde el esquema STAGING:
db2move SourceDB EXPORT –sn STAGING

Exportar todas las tablas desde la base de datos:
db2move SourceDB EXPORT

Importar todos los datos de tabla en una base de datos de destino:
db2move TargetDB IMPORT

Copiar datos del origen al destino: db2move SourceDB COPY –co TARGET_DB TargetDB USER <username>USING <password>

Retos del movimiento de datos

Los administradores de bases de datos frecuentemente encuentran difícil copiar un gran volumen de datos de un servidor de base de datos a otro en la red. Algunos de los principales retos para superar esta tarea son:

  1. El volumen de datos
    1. Terabytes de datos
    2. Cientos de tablas
    3. Tablas con cientos de millones de registros junto con miles de particiones de rango
  2. La necesidad de transferencias de datos y recargas de datos más rápidas
  3. El requisito para distribuir equitativamente los datos a través de los nodos de partición de base de datos

Ahora que tiene una visión general de las opciones de movimiento en DB2, observe detalladamente las técnicas con el código real para el movimiento de datos.


Técnicas de movimiento de datos de almacén de DB2

En esta sección, examinaremos las técnicas disponibles para mover DATAMART de la base de datos de origen a la de destino. Evaluaremos los pros y contras de cada método, con la meta de facilitar el trabajo para los administradores de bases de datos durante la transferencia de datos.

Los ejemplos fueron probados en IBM Balanced Warehouse D5100 con la siguiente configuración:

  • 11 nodos físicos y 41 nodos lógicos
  • Cada servidor tiene 4 CPUs, 2800 MHz
  • Cada servidor tiene 32 GB RAM
  • SUSE Linux 10 2.6.16.60-0.66.1-smp
  • DB2 9.5 FP7
  • Tamaño de la base de datos: 6.8 TB
  • Las tablas de hechos principales son de intervalos particionados y el número de particiones en cada tabla es aproximadamente de 21237

La copia de datos fue de la producción de Balanced Warehouse para el Balanced Warehouse de prueba de aceptación de usuario (UAT) de una infraestructura y versión de DB2 similares.

Como un requisito empresarial, los dos esquemas de base de datos de UAT, DATASTORE y DATAMARTS, fueron renovados desde producción.

Como se discutió anteriormente, existen muchas técnicas disponibles en DB2 para renovar grandes conjuntos de datos de un entorno a otro. Esas técnicas son:

  1. Exportar datos en el servidor de base de datos local, transferir el archivo de datos y cargar datos localmente en el servidor de base de datos de destino (tablas pequeñas con particionamiento de hash o sin partición de hash)
  2. Exportar datos del servidor de base de datos local y cargar datos remotamente al servidor de base de datos de destino
  3. Exportar datos del servidor de base de datos remoto y cargar datos localmente al servidor de base de datos de destino
  4. Exportar datos a un conducto de sistema operativo e importar o cargar datos del conducto al servidor de base de datos remota de destino
  5. Exportar datos en el servidor de base de datos local en paralelo (cada parte residiendo en su sistema de archivos de partición respectivo), usar una transferencia de archivo de datos y después cargar las partes localmente en paralelo

Las siguientes secciones examinan cada una de estas técnicas, con ejemplos.

Técnica #1

Exportar datos en el servidor de base de datos local, transferir el archivo de datos y cargar datos localmente en el servidor de base de datos de destino (tablas pequeñas con particionamiento de hash o sin partición de hash)

Figura 1. Técnica #1
Técnica #1

Estas son las etapas para implementar esta técnica.

  1. Conéctese a SourceDB localmente en el servidor de base de datos de origen.
     CONNECT TO SourceDB;
  2. Realice una exportación de DB2 en la tabla en el servidor de base de datos de origen.
     EXPORT TO DATAMARTS.SCENARIO_CALENDAR.DEL OF DEL MESSAGES 
    DATAMARTS.SCENARIO_CALENDAR.MSG
     SELECT * FROM DATAMARTS.SCENARIO_CALENDAR;
  3. Comprima el archivo exportado para reducir el tiempo requerido para la transferencia de archivos entre los servidores.
     gzip DATAMARTS.SCENARIO_CALENDAR F.DEL
  4. Transfiera el archivo comprimido del servidor SourceDB al servidor TargetDB usando sftp o scp.
     cd <export file path> 
    sftp username@<targetDB Server hostname> put DATAMARTS.SCENARIO_CALENDAR.DEL.gz OR scp DATAMARTS.SCENARIO_CALENDAR.DEL.gz username@<targetDB Server hostname>:/<PATH>
  5. Descomprima el archivo transferido en el servidor de base de datos de destino.
     gunzip DATAMARTS.SCENARIO_CALENDAR.DEL.gz
  6. Conéctese a TargetDB localmente en el servidor de base de datos de destino.
     CONNECT TO TargetDB;
  7. Realice una carga o importación.
     LOAD FROM DATAMARTS.SCENARIO_CALENDAR.DEL OF DEL SAVECOUNT 10000 MESSAGES
             DATAMARTS.SCENARIO_CALENDAR.LOAD.MSG INSERT INTO 
    DATAMARTS.SCENARIO_CALENDAR;
  8. En el caso del comando de carga, ejecute SET INTEGRITY al final de la operación.
      SET INTEGRITY FOR DATAMARTS.SCENARIO_CALENDAR IMMEDIATE CHECKED;
  9. Ejecute RUNSTATS para mantener las estadísticas actualizadas.
    RUNSTATS ON TABLE DATAMARTS.SCENARIO_CALENDAR WITH DISTRIBUTION AND DETAILED INDEXES
    ALL;

Técnica #2

Exportar datos del servidor de base de datos local y cargar datos remotamente al servidor de base de datos de destino.

Figura 2. Técnica #2
Técnica #2

Siga estas etapas para implementar esta técnica.

  1. Catalogue la base de datos de destino en el servidor de base de datos de origen.
    CATALOG TCPIP NODE TargetND REMOTE TargetDBServer.ibm.com SERVER 50001;
    CATALOG DATABASE TargetDB AT NODE TargetND;
  2. Conéctese a SourceDB localmente en el servidor de base de datos de origen.
     CONNECT TO SourceDB;
  3. Realice una exportación de DB2 desde la tabla en el servidor de base de datos de origen.
     EXPORT TO DATAMARTS.SCENARIO_CALENDAR.DEL OF DEL MESSAGES 
    DATAMARTS.SCENARIO_CALENDAR.msg
    SELECT * FROM DATAMARTS.SCENARIO_CALENDAR;
  4. Conéctese a TargetDB remotamente en el servidor de base de datos de destino.
    CONNECT TO TargetDB user <username> using <Password>;
  5. Realice una carga o importación remotamente del origen al destino.
    LOAD CLIENT FROM DATAMARTS.SCENARIO_CALENDAR.DEL OF DEL SAVECOUNT 10000 MESSAGES 
           DATAMARTS.SCENARIO_CALENDAR.LOAD.msg INSERT INTO DATAMARTS.SCENARIO_CALENDAR;
  6. En el caso del comando de carga, ejecute SET INTEGRITY al final de la operación.
    SET INTEGRITY FOR DATAMARTS.SCENARIO_CALENDAR IMMEDIATE CHECKED;
  7. Ejecute RUNSTATS para mantener las estadísticas actualizadas.
     RUNSTATS ON TABLE DATAMARTS.SCENARIO_CALENDAR WITH DISTRIBUTION 
    AND DETAILED INDEXES ALL;

Técnica #3

Exportar datos del servidor de base de datos remoto y cargar datos localmente al servidor de base de datos de destino.

Figura 3. Técnica #3
Técnica #3

Siga estas etapas para implementar esta técnica.

  1. Catalogue la base de datos de origen en el servidor de base de datos de destino.
     CATALOG TCPIP NODE SourceND REMOTE SourceDBServer.ibm.com SERVER 50001;
    CATALOG DATABASE SourceDB AT NODE SourceND;
  2. Conéctese a la base de datos de origen remotamente desde el servidor de destino.
    CONNECT TO SourceDB user <username> using <password>;
  3. Realice una exportación de DB2 desde la tabla remotamente.
    EXPORT TO DATAMARTS.SCENARIO_CALENDAR.DEL OF DEL MESSAGES 
    DATAMARTS.SCENARIO_CALENDAR.msg
            SELECT * FROM DATAMARTS.SCENARIO_CALENDAR;
  4. Conéctese a TargetDB localmente en el servidor de base de datos de destino.
     CONNECT TO TargetDB user <username> using <Password>;
  5. Realice una importación o carga local.
     LOAD FROM DATAMARTS.SCENARIO_CALENDAR.DEL OF DEL SAVECOUNT 10000 MESSAGES 
         DATAMARTS.SCENARIO_CALENDAR.LOAD.msg INSERT INTO DATAMARTS.SCENARIO_CALENDAR;
  6. En el caso del comando de carga, ejecute SET INTEGRITY al final de la operación.
     SET INTEGRITY FOR DATAMARTS.SCENARIO_CALENDAR IMMEDIATE CHECKED;
  7. Ejecute RUNSTATS para mantener las estadísticas actualizadas.
      RUNSTATS ON TABLE DATAMARTS.SCENARIO_CALENDAR WITH DISTRIBUTION 
    AND DETAILED INDEXES ALL;

Técnica #4

Exportar datos a un conducto de sistema operativo y cargar datos del conducto al servidor de base de datos remota de destino.

Figura 4. Técnica #4
Técnica #4

Siga estas etapas para implementar esta técnica.

  1. Catalogue la base de datos de origen en el servidor de base de datos de destino:
    CATALOG TCPIP NODE SourceND REMOTE SourceDBServer.ibm.com SERVER 50001;
    CATALOG DATABASE SourceDB AT NODE SourceND;
  2. Cree un conducto de sistema operativo en el servidor de base de datos de destino.
     mkfifo datapipe
     ls –ltr datapipe
     prw-r--r--  1 bculinux bcuigrp     0 2011-09-18 16:32 datapipe
  3. Conéctese a la base de datos de origen remotamente desde el servidor de destino.
     CONNECT TO SourceDB user <username> using <password>;
  4. Exporte datos de la base de datos de origen y grábelos en un lado del conducto de SO (datapipe). En el escenario empresarial, el equipo de administración de la base de datos renovó UAT desde PROD. sólo para el periodo de 2011 de los registros 12904084.
     EXPORT TO datapipe OF DEL MODIFIED BY COLDEL, MESSAGES
         FACT_CUST_FPI_VALIDATION.EXP.msg SELECT * FROM DATAMARTS.F_CUST_FPI_VALIDATION 
         WHERE REC_LOAD_DT > '2011-01-01-00.00.00.000000' WITH UR;
  5. Conéctese a la base de datos de origen remotamente desde el servidor de destino.
    CONNECT TO TargetDB user <username> using <password>;
  6. Importe o cargue datos de otro lado del conducto de SO en una tabla de intervalos particionados de hash regular.
    IMPORT FROM datapipe OF DEL MODIFIED BY COLDEL, MESSAGES
          FACT_CUST_FPI_VALIDATION.IMP.msg INSERT INTO
          DATAMARTS.FACT_CUST_FPI_VALIDATION;
                
     LOAD FROM datapipe OF DEL MODIFIED BY COLDEL, MESSAGES
          FACT_CUST_FPI_VALIDATION.LD.msg INSERT INTO
          DATAMARTS.FACT_CUST_FPI_VALIDATION;

    Nota: tenga cuidado al usar el comando de carga en una base de datos particionada que tenga muchas particiones de intervalo. La carga puede fallar con SQLCODE SQL0973N y puede perder datos en la tabla de destino.

Tome una instantánea de la aplicación en la base de datos de destino. Verá una inserción ocurriendo en la tabla del servidor de base de datos de destino. Hasta que la transferencia de datos esté completa, verá la exportación hacia el conducto y la importación desde el conducto ejecutándose en el servidor.

Los siguientes listados resumen el estado en el origen y el destino después de completarse:

Listado 1. Desde la conexión de base de datos de origen
db2 "EXPORT TO datapipe OF DEL MODIFIED BY COLDEL, MESSAGES FPI_VALIDATION.EXP.msg 
		SELECT * FROM DATAMARTS.F_CUST_FPI_VALIDATION WHERE REC_LOAD_DT >
		'2011-01-01-00.00.00.000000' WITH UR"
Number of rows exported: 	12904084
Listado 2. Desde la conexión de base de datos de destino
db2 "IMPORT FROM datapipe OF DEL MODIFIED BY COLDEL, MESSAGES
        FPI_VALIDATION.IMP.msg INSERT INTO
		DATAMARTS.FACT_CUST_FPI_VALIDATION"
Number of rows read         	= 12904084
Number of rows skipped      	= 0
Number of rows inserted     	= 12904084
Number of rows updated    		= 0
Number of rows rejected     	= 0
Number of rows committed		= 12904084

Para eliminar el conducto de sistema operativo después de la finalización, use el siguiente comando:

rm datapipe

Limitaciones y soluciones para la técnica #4

Al cargar datos en una tabla con muchos intervalos particionados en un entorno particionado de base de datos, puede encontrar el siguiente error.

SQL0973N Not enough storage is available in the "UTIL_HEAP_SZ" heap to process the statement. SQLSTATE=57011

Estas son algunas formas de solucionar este problema:

  1. Incremente el valor del parámetro de configuración de base de datos UTIL_HEAP_SZ a un máximo de 524288 páginas con un tamaño de páginas de 4K. Después fuerce todas las aplicaciones y reactive la base de datos.
  2. Disminuya el número de DATA BUFFER mientras carga los datos.
  3. Si las dos etapas anteriores no le permiten completar la carga, realice una finalización de carga.
  4. Cree una tabla temporal DATAMARTS.FACT_CUST_FPI_VALIDATION_TMP sin particiones de intervalo y realice una carga en la tabla temporal desde el conducto con una cláusula no recuperable para hacer la carga más rápida.
  5. Después de la finalización, ejecute INSERT INTO ... SELECT * FROM.... Puede ejecutar una inserción NOT LOGGED INITIALLY para mejorar el rendimiento de las cargas de datos. El listado a continuación muestra dicha inserción.
Listado 3. Inserciones NOT LOGGED INITIALLY
db2 +c "ALTER TABLE DATAMARTS.FACT_CUST_FPI_VALIDATION
     ACTIVATE NOT LOGGED INITIALLY"
db2 "INSERT INTO DATAMARTS.FACT_CUST_FPI_VALIDATION SELECT * 
     FROM DATAMARTS.FACT_CUST_FPI_VALIDATION_TMP"

Nota: si una inserción NOT LOGGED INITIALLY falla por alguna razón, debe volver a crear la tabla.

Técnica #5

Exportar datos en el servidor de base de datos local, transferir el archivo de datos y cargar datos localmente en el servidor de base de datos de destino (tablas pequeñas con particionamiento de hash o sin partición de hash).

Figura 5. Técnica #5
Técnica #5

En el servidor de base de datos de origen, realice las siguientes etapas para exportar datos.

  1. Cree enlaces dinámicos desde el directorio de exportación de nodo de admin hacia todos los nodos de datos. En este ejemplo, el directorio de exportación es $HOME/db2backup/exports.
    ln -s /db2fs/bculinux/NODE0001 NODE1
    ln -s /db2fs/bculinux/NODE0002 NODE2
    .........
    ln -s /db2fs/bculinux/NODE0040 NODE40
  2. El siguiente listado muestra los archivos resultantes después de crear los enlaces dinámicos.
    ls –ltr
    lrwxrwxrwx 1 bculinux bcuigrp  24 2011-04-13 19:25 NODE1 -> /db2fs/bculinux/NODE0001
    lrwxrwxrwx 1 bculinux bcuigrp  24 2011-04-13 19:25 NODE2 -> /db2fs/bculinux/NODE0002
    .........
    lrwxrwxrwx 1 bculinux bcuigrp  24 2011-04-13 19:28 NODE40 -> /db2fs/bculinux/NODE0040
  3. En cada servidor de nodo de datos físico, cree una estructura de directorios similar a esta.
    mkdir –p /db2fs/bculinux/NODE0001/exports/datamarts
    mkdir –p /db2fs/bculinux/NODE0002/exports/datamarts
    .........
    mkdir –p /db2fs/bculinux/NODE0040/exports/datamarts
  4. Encuentre las columnas de partición de hash en SYSCAT.COLUMNS para la tabla que necesita ser exportada.
     db2 "SELECT SUBSTR(COLNAME,1,20) COLNAME, PARTKEYSEQ FROM
           SYSCAT.COLUMNS WHERE TABNAME=''F_CUST_PROFTBLTY_TMP' AND
           TABSCHEMA='DATAMARTS'"
           
     COLNAME              PARTKEYSEQ
    -------------------- ----------
    ACCT_KEY                      0
    BUSS_UNIT_KEY                 1
    CALENDAR_MONTH_KEY            2
    CRNCY_CODE                    0

    En esta tabla tenemos dos columnas de partición de hash. Elegimos una de las columnas de hash para exportar datos en la partición respectiva.

  5. Exporte datos en todas las particiones en paralelo usando el comando DB2 EXPORT como se muestra en este listado.
     db2_all "\"|| db2 \"EXPORT TO 
    $HOME/db2backup/exports/NODE##/exports/datamarts/
         DATAMARTS.F_CUST_PROFTBLTY_TMP.del OF DEL SELECT * FROM 
         DATAMARTS.F_CUST_PROFTBLTY_TMP WHERE DBPARTITIONNUM 
    (BUSS_UNIT_KEY)=##\""

    Este comando exporta cada dato de partición en nodos de partición respectivos.

  6. Realice la copia de archivos de cada nodo de servidor de base de datos de origen en el servidor de base de datos de destino usando scp.
     scp -p <File Name>  <User Name>@<Host Name>:<File Name>

En el servidor de base de datos de destino, realice las siguientes etapas para exportar los datos.

  1. Cree enlaces dinámicos como se ilustra en la base de datos de origen, como se muestra en el Listado 4.
  2. Cargue desde cada conjunto de datos de partición en paralelo usando el comando de carga de DB2.
    Listado 4. Comando LOAD paralelo
     db2_all "<<-0<<\" db2 -v \"LOAD FROM db2backup/exports/NODE##/exports/datamarts
        DATAMARTS.F_CUST_PROFTBLTY_TMP.del OF DEL INSERT INTO
        DATAMARTS.F_CUST_PROFTBLTY_TMP NONRECOVERABLE \""

    Este comando cargaría cada conjunto de datos de partición en nodos de partición respectivos.


Pros y contras de cada técnica

La Tabla 2 resalta los beneficios y desventajas de estas técnicas.

Tabla 2. Pros y Contras
TécnicaProsContras
1. Exportar localmente y cargar localmente
  • Uso fácil
  • Método eficiente para usar con datos de tabla de dimensiones que reside en el nodo de admin
  • Requiere que el espacio del sistema de archivos aloje el archivo de datos de exportación en los servidores de origen y de destino
  • Si los datos son distribuidos en todos los nodos de datos en un depósito, tal vez no pueda usar eficientemente los recursos del sistema de nodo de datos, así que este no es un método recomendable durante una renovación grande de tablas de hechos.
2. Exportar localmente y cargar remotamente
  • Uso fácil
  • Requiere espacio del sistema de archivos en el servidor de origen
  • Mientras se realiza la carga remotamente desde un servidor de origen, los procesos de carga usan los recursos del sistema de servidor de origen, así que esto no es ideal la mayoría de las veces cuando el servidor de origen es el servidor de producción
3. Exportar remotamente y cargar localmente
  • Uso fácil
  • requiere espacio del sistema de archivos en el servidor de destino
  • Este método en su mayoría hace uso de los recursos del sistema del servidor de destino, así que no hay preocupaciones en el rendimiento de producción, asumiendo que sólo hay informes ejecutándose en el sistema de producción y realizando la exportación con nivel de aislamiento de lectura sin confirmar
4. Exportar y cargar usando el conducto
  • No requiere espacio del sistema de archivos para almacenar el archivo de datos ni el servidor de origen ni en el de destino
  • Si el conducto se interrumpe en el medio, la única forma de empezar a progresar es iniciar la exportación y la carga desde cero.
5. Exportación paralela y carga paralela
  • Muy rápida en comparación con cualquier otra técnica para grandes tablas de hechos que tienen los datos distribuidos en todas las particiones
  • No necesita una gran parte de espacio en disco en un sistema de archivos
  • Hace uso del espacio en cada sistema de archivos del nodo de partición
  • Hace uso de los recursos de sistema equitativamente en todos los nodos de datos
  • Este método requiere espacio en el sistema de archivos para almacenar los datos exportados en el origen así como en los sistemas de archivos del nodo de partición de datos de destino.
  • Esta técnica necesita crear enlaces dinámicos y estructura de directorios para cada partición en los servidores de origen y de destino.

Conclusión

Este artículo ha descrito cómo usar las utilidades de movimiento de datos de DB2 para satisfacer los requisitos en un entorno de almacén equilibrado con consideraciones especiales para tablas de hechos con múltiples particiones. Ahora debe tener un mejor entendimiento de los problemas que pueden ocurrir al trabajar con tablas de datos enormes que tienen muchas particiones de intervalos. Si encuentra datos protegidos por LBAC, consulte el Centro de Información de IBM para obtener más detalles.


Agradecimientos

Agradecimientos especiales para Nelson Coish, President, Coish Consulting Inc por ayudar al autor a completar y afinar el artículo.

Recursos

Aprender

Obtener los productos y tecnologías

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=811608
ArticleTitle=Usar efectivamente las utilidades de movimiento de datos de DB2 en un entorno de depósito de datos
publish-date=04302012