Uso de una base de datos de almacenamiento provisional en Parallel Data Warehouse (PDW)

SQL Server Parallel Data Warehouse (PDW) usa una base de datos de almacenamiento provisional para almacenar datos temporalmente durante el proceso de carga. De forma predeterminada, SQL Server PDW usa la base de datos de destino como base de datos de almacenamiento provisional, y esto puede provocar la fragmentación de tablas. Para reducir la fragmentación de tablas, puede crear una base de datos de almacenamiento provisional definida por el usuario. O bien, cuando la reversión de un error de carga no sea un problema, puede usar el modo de carga fastappend para mejorar el rendimiento, omitiendo la tabla temporal y cargando directamente en la tabla de destino.

Conceptos básicos de la base de datos de almacenamiento provisional

Una base de datos de almacenamiento provisional es una base de datos de PDW creada por el usuario que almacena los datos temporalmente mientras se cargan en el dispositivo. Cuando se especifica una base de datos de almacenamiento provisional para una carga, el dispositivo copia primero los datos en la base de datos de almacenamiento provisional y, a continuación, copia los datos de tablas temporales de la base de datos provisional en tablas permanentes de la base de datos de destino.

Cuando no se especifica una base de datos provisional para una carga, Sistema de plataforma de análisis (PDW) de SQL Server crea las tablas temporales en la base de datos de destino y las usa para almacenar los datos cargados antes de insertar los datos cargados en las tablas de destino permanentes.

Cuando una carga usa el modo fastappend, Sistema de plataforma de análisis (PDW) de SQL Server omite completamente el uso de tablas temporales y anexa los datos directamente a la tabla de destino. El modo fastappend mejora el rendimiento de carga para escenarios de ELT donde los datos se cargan en una tabla que es temporal desde el punto de vista de la aplicación. Por ejemplo, un proceso de ELT podría cargar datos en una tabla temporal, procesar los datos mediante la limpieza y la deduplicación y, a continuación, insertar los datos en la tabla de hechos de destino. En este caso, no es necesario que el PDW cargue primero los datos en una tabla temporal interna antes de insertar los datos en la tabla temporal de la aplicación. El modo fastappend evita el paso de carga adicional, con lo que se mejora significativamente el rendimiento de la carga. Para usar el modo fastappend, debe usar el modo de varias transacciones, que significa que la recuperación de una carga con errores o anulada debe controlarse mediante su propio proceso de carga.

Ventajas de la base de datos provisional

La principal ventaja de una base de datos provisional es la reducción de la fragmentación de tablas. Si no se usa una base de datos provisional, los datos se cargan en tablas temporales de la base de datos de destino. Cuando se crean y o se eliminan tablas temporales en la base de datos de destino, las páginas de las tablas temporales y las tablas permanentes se intercalan. Con el tiempo, se produce la la fragmentación de las tablas y se degrada el rendimiento. Por contra, una base de datos de almacenamiento provisional garantiza que las tablas temporales se creen y se eliminen en un espacio de archivo independiente respecto a las tablas permanentes.

Estructuras de las tablas de base de datos de almacenamiento provisional

La estructura de almacenamiento de cada tabla de base de datos depende de la tabla de destino.

• Para las cargas en una pila o un índice de almacén de columnas agrupado en clúster, la tabla de almacenamiento provisional es una pila.

• Para las cargas en un índice agrupado en clúster de almacén de filas, la tabla de almacenamiento provisional es un índice agrupado en clúster de almacén de filas.

Permisos

Requiere el permiso CREATE (para crear una tabla temporal) en la base de datos de almacenamiento provisional.

Procedimientos recomendados para crear una base de datos de almacenamiento provisional

1. Solo debe haber una base de datos de almacenamiento provisional por dispositivo. Todos los trabajos de carga de todas las bases de datos de destino pueden compartir la base de datos de almacenamiento provisional.

2. El tamaño de la base de datos de almacenamiento provisional es específico del cliente. Inicialmente, cuando se rellena por primera vez el dispositivo, la base de datos de almacenamiento provisional debe ser lo suficientemente grande como para dar cabida a los trabajos de carga iniciales. Estos trabajos de carga tienden a ser grandes porque se pueden producir varias cargas simultáneamente. Cuando se hayan completado los trabajos de carga iniciales y el sistema esté en el entorno de producción, es probable que el tamaño de cada trabajo de carga sea menor. Cuando las cargas son pequeñas, puede reducir el tamaño de la base de datos de almacenamiento provisional para adaptarse a los tamaños de carga más pequeños. Para reducir el tamaño, puede eliminar la base de datos de almacenamiento provisional y volver a crearla con asignaciones de tamaño más pequeñas, o bien puede usar la instrucción ALTER DATABASE.

   Al crear la base de datos de almacenamiento provisional, siga las directrices siguientes.

   • El tamaño de la tabla replicada debe ser el tamaño estimado, por nodo Proceso, de todas las tablas replicadas que se cargarán simultáneamente. Normalmente, el tamaño es de 25-30 GB.

   • El tamaño de la tabla distribuida debe ser el tamaño estimado, por dispositivo, de todas las tablas distribuidas que se cargarán simultáneamente.

   • El tamaño del registro suele ser similar al tamaño de la tabla replicada.

Ejemplos

A Creación de una base de datos de almacenamiento provisional

En el ejemplo siguiente se crea una base de datos de almacenamiento provisional, Stagedb, para su uso con todas las cargas del dispositivo. Supongamos que calcula que cinco tablas replicadas con un tamaño de 5 GB se cargarán simultáneamente. Esta simultaneidad da como resultado la asignación de al menos 25 GB para el tamaño replicado. Supongamos que calcula que seis tablas distribuidas con unos tamaños de 100, 200, 400, 500, 500 y 550 GB se cargarán simultáneamente. Esta simultaneidad da como resultado la asignación de al menos 2250 GB para el tamaño de la tabla distribuida.

CREATE DATABASE Stagedb  
WITH (  
  
    AUTOGROW = ON,  
  
    REPLICATED_SIZE = 25 GB,  
  
    DISTRIBUTED_SIZE = 2250 GB,  
  
    LOG_SIZE = 25 GB  
  
);