Uso di un database dell'area di gestione temporanea in Parallel Data Warehouse (PDW)

SQL Server Parallel Data Warehouse (PDW) usa un database dell'area di gestione temporanea per archiviare temporaneamente i dati durante il processo di caricamento. Per impostazione predefinita, SQL Server PDW usa il database di destinazione come database dell'area di gestione temporanea, che può causare la frammentazione della tabella. Per ridurre la frammentazione della tabella, è possibile creare un database dell'area di gestione temporanea definito dall'utente. In alternativa, quando il rollback dà un errore di carico non costituisce un problema, è possibile usare la modalità di caricamento fastappend per migliorare le prestazioni ignorando la tabella temporanea e caricando direttamente nella tabella di destinazione.

Nozioni di base sul database dell’area di gestione temporanea

Un database dell'area di gestione temporanea è un database PDW creato dall'utente che archivia temporaneamente i dati durante il caricamento nell'appliance. Quando si specifica un database dell'area di gestione temporanea per un carico, l'appliance copia prima i dati nel database dell'area di gestione temporanea e quindi copia i dati dalle tabelle temporanee nel database dell'area di gestione temporanea in tabelle permanenti nel database di destinazione.

Quando un database dell'area di gestione temporanea non viene specificato per un carico, la Piattaforma di strumenti analitici (PDW) crea le tabelle temporanee nel database di destinazione e le usa per archiviare i dati caricati prima di inserire i dati caricati nelle tabelle di destinazione permanenti.

Quando un carico usa la modalità fastappend, la Piattaforma di strumenti analitici (PDW) ignora completamente l'uso di tabelle temporanee e accoda i dati direttamente alla tabella di destinazione. La modalità fastappend migliora le prestazioni di caricamento per gli scenari ELT in cui i dati vengono caricati in una tabella che rappresenta una tabella temporanea dal punto di vista dell'applicazione. Ad esempio, un processo ELT potrebbe caricare i dati in una tabella temporanea, elaborare i dati tramite pulizia e deduplicazione e quindi inserire i dati nella tabella dei fatti di destinazione. In questo caso, non è necessario prima che PDW carichi i dati in una tabella temporanea interna prima di inserire i dati nella tabella temporanea dell'applicazione. La modalità fastappend evita il passaggio di caricamento aggiuntivo, migliorando significativamente le prestazioni di caricamento. Per usare la modalità fastappend, è necessario usare la modalità multi-transazione, il che significa che il ripristino da un carico non riuscito o interrotto deve essere gestito dal processo di caricamento.

Vantaggi del database dell'area di gestione temporanea

Il vantaggio principale di un database dell'area di gestione temporanea consiste nel ridurre la frammentazione delle tabelle. Se non viene usato un database dell'area di gestione temporanea, i dati vengono caricati in tabelle temporanee nel database di destinazione. Quando le tabelle temporanee vengono create ed eliminate nel database di destinazione, le pagine per le tabelle temporanee e le tabelle permanenti vengono interleaved. Nel corso del tempo, la frammentazione delle tabelle si verifica e peggiora le prestazioni. Al contrario, un database dell'area di gestione temporanea garantisce che le tabelle temporanee vengano create e eliminate in uno spazio file separato rispetto alle tabelle permanenti.

Strutture delle tabelle di database dell'area di gestione temporanea

La struttura di archiviazione per ogni tabella di database dipende dalla tabella di destinazione.

• Per i caricamenti in un indice columnstore cluster o heap, la tabella di staging è un heap.

• Per i caricamenti in un indice cluster rowstore, la tabella di staging è un indice cluster rowstore.

Autorizzazioni

È richiesta l'autorizzazione CREATE (per la creazione di una tabella temporanea) nel database dell'area di gestione temporanea.

Procedure consigliate per la creazione di un database dell'area di gestione temporanea

1. Dovrebbe essere presente un solo database dell'area di gestione temporanea per appliance. Il database dell'area di gestione temporanea può essere condiviso da tutti i processi di caricamento per tutti i database di destinazione.

2. Le dimensioni del database dell'area di gestione temporanea sono specifiche del cliente. Inizialmente, quando si popola l'appliance, il database dell'area di gestione temporanea deve essere sufficientemente grande per supportare i processi di caricamento iniziali. Questi processi di caricamento tendono a essere di grandi dimensioni perché più carichi possono verificarsi simultaneamente. Dopo il completamento dei processi di caricamento iniziali e il sistema è in produzione, è probabile che le dimensioni di ogni processo di carico siano inferiori. Quando i carichi sono di piccole dimensioni, è possibile ridurre le dimensioni del database dell'area di gestione temporanea per supportare le dimensioni di carico più piccole. Per ridurre le dimensioni, è possibile eliminare il database dell'area di gestione temporanea e crearlo di nuovo con allocazioni di dimensioni inferiori oppure usare l'istruzione ALTER DATABASE.

   Quando si crea il database dell'area di gestione temporanea, usare le linee guida seguenti.

   • Le dimensioni della tabella replicate devono essere le dimensioni stimate, per nodo di calcolo, di tutte le tabelle replicate che verranno caricate contemporaneamente. Le dimensioni sono in genere di 25-30 GB.

   • Le dimensioni della tabella distribuita devono essere le dimensioni stimate, per appliance, di tutte le tabelle distribuite che verranno caricate contemporaneamente.

   • Le dimensioni del log sono in genere simili alle dimensioni della tabella replicata.

Esempi

R. Creare un database dell'area di gestione temporanea

Nell'esempio seguente viene creato un database dell'area di gestione temporanea, Stagedb, da usare con tutti i carichi nell'appliance. Si supponga di stimare che cinque tabelle replicate di dimensioni pari a 5 GB verranno caricate contemporaneamente. Questa concorrenza comporta l'allocazione di almeno 25 GB per le dimensioni replicate. Si supponga di stimare che sei tabelle distribuite di dimensioni pari a 100, 200, 400, 500, 500 e 550 GB verranno caricate contemporaneamente. Questa concorrenza comporta l'allocazione di almeno 2250 GB per le dimensioni della tabella distribuita.

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