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 un insieme 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.
[!NOTA]
Il partizionamento di indici e tabelle è disponibile solo nelle edizioni Enterprise, Developer ed Evaluation di SQL Server.
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 l'indice viene comunque considerato come una singola entità logica quando si eseguono query o aggiornamenti 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 funzionalità 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 ricostruzioni 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 in linea.
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 non in linea 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.
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 AdventureWorks. Questo scenario è illustrato nell'argomento Partizionamento nel database di esempio AdventureWorks.
Architettura di partizionamento
In SQL Server tutte le tabelle e tutti gli indici di un database vengono considerati partizionati anche se costituiti da un'unica partizione. Le partizioni rappresentano l'unità di base dell'organizzazione nell'architettura fisica di tabelle e indici. L'architettura logica e fisica di tabelle e indici che includono più partizioni rispecchia pertanto quella di tabelle e indici costituiti da un'unica partizione. Per ulteriori informazioni, vedere Organizzazione di tabelle e indici.