Esplorazione delle operazioni sugli indici online a livello di partizione in SQL Server 2014 CTP1

SQL Server 2014 CTP1 introduce estensioni alle opzioni operative online che saranno una buona notizia per le aziende che ospitano database molto grandi che richiedono tempi di inattività minimi o nulli.

Per impostare il contesto, immagina di utilizzare SQL Server 2012 Enterprise Edition per la gestione dell'indice online e le funzionalità di partizionamento dell'indice e di provare a ricostruire l'indice seguente su una tabella partizionata:

ALTER INDEX [PK_FactInternetSales_SalesOrderNumber_SalesOrderLineNumber]
ON [dbo].[FactInternetSales]
REBUILD PARTITION = ALL
WITH (ONLINE= ON);

Testandolo in SQL Server 2012, siamo in grado di ricostruire tutte le partizioni online senza errori. Ma cosa succede se vogliamo specificare una partizione specifica invece di tutte le partizioni?

ALTER INDEX [PK_FactInternetSales_SalesOrderNumber_SalesOrderLineNumber]
ON [dbo].[FactInternetSales]
REBUILD PARTITION = 1
WITH (ONLINE= ON);

Se si tenta di eseguire questa operazione in SQL Server 2012 o versioni precedenti, verrà visualizzato il seguente messaggio di errore:

Ma a partire da SQL Server 2014 (a partire da CTP1), le operazioni di indice di partizione singola online sono ora supportate. E questo è sicuramente un grosso problema per scenari di manutenzione dei tavoli molto grandi in cui si preferisce, o addirittura si deve suddividere la manutenzione complessiva in parti più piccole per un periodo di tempo. Potresti anche voler eseguire la manutenzione a livello di partizione solo per quelle partizioni che effettivamente lo richiedono, ad esempio quelle partizioni che superano effettivamente un livello di frammentazione specifico.

Per testare questa funzionalità CTP1 di SQL Server 2014 ho utilizzato AdventureWorksDW2012 con una versione di FactInternetSales che contiene 61.847.552 righe e partizionata dalla colonna ShipDate.

Ricostruire tutte le partizioni online per la tabella utilizzando PARTITION = ALL nel mio ambiente di test ci sono voluti 3 minuti e 23 secondi. Per quanto riguarda la durata complessiva, i miei test riguardavano indici non così frammentati, quindi la durata di 3 minuti e 23 secondi rappresenta una durata media su alcuni test. Tieni inoltre presente che in quel momento non avevo carichi di lavoro concorrenti in esecuzione, quindi la ricostruzione online sta avvenendo senza dover competere con altri carichi di lavoro significativi contro l'indice in questione.

La forma del piano di esecuzione della query per la ricostruzione dell'indice online utilizzando PARTITION = ALL era il seguente:

Piano di esecuzione per la ricostruzione online di tutte le partizioni

Si noti che le operazioni sono abilitate in parallelo, ad eccezione dell'operatore Scansione costante. Nel piano di esecuzione della query puoi vedere 39 righe nella scansione costante di riferimento esterno che vengono passate all'operatore Distribute Streams e quindi guidano il ciclo nidificato.

Il significato delle 39 righe? La query seguente convalida il numero massimo di partizioni da sys.dm_db_partition_stats . Per il mio ambiente di test, il risultato è stato 39 per il numero massimo di partizione, corrispondente a quello che ho visto per le righe effettive di Constant Scan:

SELECT MAX([partition_number]) AS [max_partition_number]
FROM [sys].[dm_db_partition_stats]
WHERE [object_id] = OBJECT_ID('FactInternetSales');

Ora noterai anche l'operatore di inserimento dell'indice online nel piano precedente. Rimozione del ONLINE = ON opzione dal mio ALTER INDEX REBUILD (rendendolo un'operazione offline) e mantenendo il PARTITION = ALL opzione, l'unico cambiamento è stato avere un operatore "Inserimento indice" invece di un "Inserimento indice online" nel piano di esecuzione della query - e anche una riduzione della durata, in cui il mio test ha mostrato una durata di esecuzione di 1 minuto e 9 secondi rispetto a quella online 3 minuti e 23 secondi.

Ho quindi testato una ricostruzione online di una partizione con 5.678.080 righe (ricorda che il conteggio totale delle righe della tabella è 61.847.552 righe). Per questo test, la durata complessiva ha richiesto esattamente 1 minuto e aveva la seguente forma del piano di esecuzione della query:

Piano di esecuzione per la ricostruzione online di una singola partizione

La prima osservazione è che si tratta di un piano seriale. Nota anche che ho detto di aver scelto una partizione dalla 39 originale, sebbene quella particolare partizione rappresentasse circa il 9% delle righe nella tabella in generale. Nota anche che la scansione costante mostra 1 riga invece di 39, come mi aspetterei.

Che dire della durata di una singola partizione, ricostruzione offline? Nel mio ambiente di test, ci sono voluti 11 secondi rispetto alla ricostruzione online di 1 minuto. La forma del piano di esecuzione della query per la ricostruzione offline di una singola partizione era la seguente:

Piano di esecuzione per la ricostruzione offline di una singola partizione

Si noti che non esiste un processo di scansione costante o di cicli annidati associato e si noti inoltre che questo piano ora include operatori paralleli rispetto al piano seriale precedente, anche se entrambi stanno eseguendo una scansione dell'indice cluster per 5.678.080 righe. Anche la ricerca per parola chiave di "partizione" nel testo del piano XML per l'operazione sull'indice parallelo offline della singola partizione non ha prodotto corrispondenze, rispetto al piano seriale, l'operazione sull'indice della singola partizione online che aveva Partitioned ="true" per il Scansione indice cluster e Indice in linea Inserire operatori fisici.

Torna all'esplorazione principale...

Posso scegliere alcune, ma non tutte, le partizioni in un'unica esecuzione? Sfortunatamente no.

Il ALTER INDEX e ALTER TABLE i comandi hanno il PARTITION = ALL argomento e poi PARTITION = <partition number> argomento, ma non la possibilità di elencare più partizioni per una singola operazione di ricostruzione. Tuttavia non mi lamento troppo forte di questo, dato che sono felice di avere la possibilità di ricostruire una singola partizione online e non è terribilmente complicato eseguire l'operazione una volta per ogni ricostruzione, tuttavia l'impatto cumulativo sulla durata è stato qualcosa Volevo approfondire.

Quanto tempo ci vorrebbe per ricostruire tutte le 39 partizioni separatamente e online rispetto a PARTITION = ALL durata di 3 minuti e 23 secondi?

Sappiamo che un vantaggio delle ricostruzioni in linea è la possibilità di accedere comunque alla tabella o all'indice associati durante l'operazione sull'indice. Ma in cambio di quell'operazione online, perderemo il vantaggio in termini di prestazioni della ricostruzione rispetto a una ricostruzione offline. E quello che volevo sapere dopo era come si sarebbe comportata una ricostruzione online di una partizione una per una rispetto a PARTITION = ALL alternativa.

Eseguendo 39 operazioni di ricostruzione separate (una ricostruzione per ogni partizione univoca), la durata totale dell'esecuzione è stata di 9 minuti e 54 secondi rispetto a PARTITION = ALL che ha richiesto 3 minuti e 23 secondi, quindi chiaramente l'approccio frammentario non è cumulativamente veloce come una ricostruzione online di tutte le partizioni in un'unica istruzione. Sebbene io sia stato in grado di eseguire una partizione alla volta, il vantaggio generale è la possibilità di dividere le nostre attività di manutenzione nel tempo e mantenere l'accesso agli oggetti mentre vengono ricostruiti, ma se stai cercando una ricostruzione più breve finestra, le opzioni offline sono ancora le più veloci, seguite da online per PARTITION = ALL e poi all'ultimo posto, facendo una partizione alla volta.

La tabella seguente riassume i confronti delle durate e, ancora una volta, questi test erano basati su SQL Server 2014 CTP1 e una dimensione della tabella molto specifica e una configurazione guest della macchina virtuale, quindi presta maggiore attenzione alle durate relative tra i test piuttosto che alle durate stesse:

Ora ci sono anche altri aspetti da esplorare su questo argomento. Solo perché un'operazione è online non significa che non ci siano alcuni momenti (o più) in cui sono ancora mantenuti i blocchi sull'oggetto preso di mira. Le operazioni sugli indici hanno ancora un comportamento di blocco per le operazioni online e anche SQL Server 2014 ha fornito opzioni che esplorerò in un post separato.