Concetti di base su indici e tabelle partizionate

Il partizionamento semplifica la gestione di indici e tabelle di grandi dimensioni in quanto consente di gestire e accedere in modo rapido ed efficace a subset di dati, salvaguardando al contempo l'integrità di una raccolta di dati. Grazie al partizionamento operazioni quali il caricamento di dati da un sistema OLTP a un sistema OLAP richiedono solo pochi secondi e risultano quindi molto più rapide rispetto a quanto richiesto nelle versioni precedenti di SQL Server. Le operazioni di manutenzione eseguite sui subset di dati sono anch'esse più efficienti, perché sono relative ai soli dati necessari e non all'intera tabella.

I dati di tabelle e indici partizionati vengono divisi in unità distribuibili tra più filegroup in un database. I dati sono partizionati in senso orizzontale, in modo che gruppi di righe vengano mappati in singole partizioni. La tabella o indice viene gestito come singola entità logica quando query o aggiornamenti vengono eseguiti sui dati. Tutte le partizioni di un singolo indice o di una singola tabella devono risiedere nello stesso database.

Le tabelle e gli indici partizionati supportano tutte le proprietà e le caratteristiche associate alla progettazione e all'esecuzione di query su tabelle e indici standard, inclusi i vincoli, le impostazioni predefinite, i valori identity e timestamp, nonché i trigger. Se pertanto si desidera implementare una vista partizionata locale su un server, è preferibile implementare una tabella partizionata.

La scelta relativa all'implementazione del partizionamento dipende principalmente dalle dimensioni correnti e future della tabella, dalla modalità di utilizzo della tabella, nonché dalle prestazioni in caso di query utente e operazioni di manutenzione.

È in genere consigliabile partizionare una tabella di grandi dimensioni in presenza delle condizioni seguenti:

• La tabella contiene, o si prevede conterrà, molti dati utilizzati in modo diversi.

• Le query o le operazioni di aggiornamento sulla tabella non vengono eseguite in modo efficace oppure i costi di manutenzione sono superiori ai periodi di manutenzione predefiniti.

Se ad esempio si utilizza principalmente il mese corrente per operazioni INSERT, UPDATE, DELETE e MERGE sui dati mentre i mesi precedenti vengono utilizzati prevalentemente per query SELECT, la gestione di questa tabella potrebbe risultare più agevole se viene partizionata in base al mese. I vantaggi sono ancora più evidenti se le normali operazioni di manutenzione sulla tabella devono interessare solo un subset dei dati. Se la tabella non è partizionata, l'esecuzione di queste operazioni su un intero set di dati implica un elevato consumo di risorse. Se il partizionamento è attivo, è possibile eseguire operazioni di manutenzione quali ricompilazioni di indici e deframmentazione su un unico mese di dati in sola scrittura, lasciando ad esempio disponibili i dati in sola lettura per l'accesso online.

Per espandere questo esempio, si supponga di dover spostare un mese di dati in sola lettura da questa tabella a una tabella di data warehouse a scopo di analisi. Se il partizionamento è attivo, è possibile separare rapidamente subset di dati in aree temporanee per la manutenzione offline e quindi aggiungerli come partizioni alle tabelle partizionate esistenti, presupponendo che tali tabelle siano tutte incluse nella stessa istanza di database. Operazioni di questo tipo richiedono in genere pochi secondi, anziché i minuti o le ore richieste nelle versioni precedenti.

Il partizionamento di una tabella o di un indice può inoltre contribuire a migliorare le prestazioni delle query se le partizioni sono progettate in modo corretto, in base ai tipi di query eseguite di frequente e alla configurazione hardware. Per ulteriori informazioni, vedere Progettazione di partizioni per migliorare le prestazioni di esecuzione delle query.

Il partizionamento viene spesso utilizzato congiuntamente alla replica di SQL Server. L'utilizzo delle partizioni potrebbe consentire di ottimizzare le prestazioni della replica transazionale e della replica di tipo merge riducendo efficacemente la quantità di dati e di metadati che devono essere gestiti dal sistema di replica. La replica supporta un massimo di 1024 partizioni per tabella. Per ulteriori informazioni, vedere Replica di tabelle e indici partizionati.

Per un esempio relativo all'applicazione di una soluzione di partizionamento in un database reale, è possibile implementare lo scenario di partizionamento disponibile nel database di esempio AdventureWorks2008R2. Questo scenario viene illustrato in Partizionamento nel database di esempio AdventureWorks2008R2.