C'è un vantaggio a non partizionare l'allineamento di un indice?

9

Ho il privilegio di gestire una grande tabella OLAP partizionata. Durante la revisione di questa tabella ho notato che uno degli indici non è allineato con lo schema di partizionamento. Poiché l'autore non è disponibile e le ricerche di Google attentamente elaborate non hanno restituito risultati utili, non sono sicuro che ciò sia intenzionale o accidentale.

C'è qualche motivo per non allineare la partizione di un indice su SQL Server 2008?

— pettirosso
fonte

1

Possibilmente. Interroga l'utilizzo delle statistiche dell'indice per vedere se quell'indice viene utilizzato. In tal caso, utilizzare eventi estesi o una traccia lato server per acquisire le query che colpiscono quell'indice. Se si comportassero meglio su un indice allineato alle partizioni, ottimo. In caso contrario, controlla se effettivamente hanno bisogno di indici partizionati non allineati. In caso contrario, direi che la partizione è allineata comunque poiché le query future possono trarne vantaggio. Naturalmente, se il costo / sforzo / interruzione è troppo elevato, allora non farlo.

— Ali Razeghi,

Da quello che ho letto le migliori pratiche per indicizzare una tabella partizionata è allineare l'indice con lo schema di partizionamento. Questa particolare tabella mi ha fatto pensare che voglio capire un caso d'uso per non allineare un indice con lo schema di partizione. Non sto cercando di risolvere un problema specifico, quindi non ho una query che deve essere analizzata.

— Robin,

Un altro motivo per progettare un indice non allineato è un indice univoco (inclusa chiave primaria o vincolo univoco) che non include la colonna di partizionamento. In questo caso, l'indice non deve essere affatto partizionato o partizionato usando una funzione / schema diverso.

— Dan Guzman,

11

Il principale vantaggio di non partizionamento di un (non univoco) indice su un oggetto di base partizionato è che funziona intorno ad un limite di query optimizer di lunga data relative a richieste di dati ordinati, come MIN, MAXo TOP (n)query.

Su un indice partizionato, l'ottimizzatore non può generalmente tradurre MIN, MAXo TOP (n)nella stessa operazione per partizione , seguito da un aggregato globale finale sugli aggregati parziali per partizione. L'ottimizzatore sceglie invece un piano di esecuzione che analizza tutte le partizioni dell'indice. L'eccezione a questo è il singolo caso in cui l'operazione aggregata o superiore è specificata sulla colonna di partizionamento.

Devo dire che ci sono anche ottime ragioni per non avere indici non allineati. La scelta di utilizzare un indice non allineato dovrebbe essere una scelta molto informata. L'ho fatto da solo (raramente) in passato, ma in circostanze molto specifiche in cui i benefici superavano chiaramente i costi o non esistevano alternative ragionevoli.

Articolo di Itzik Ben-Gan che spiega il problema.

— Paul White 9
fonte

3

Esiste l'ovvio problema relativo ad alcuni vincoli (ad es. Unici) che richiedono un indice non allineato.

A parte questo, gli indici non allineati hanno un grande costo (in primo luogo impediscono a molti operatori paralleli di utilizzare thread per partizione e le alternative sono costose in termini di memoria) e quindi sconsiglio vivamente tali indici. Anche con i casi elencati da Paul, vorrei comunque sconsigliare gli indici non allineati.

— Remus Rusanu
fonte

1

Sì. La scelta di un indice non allineato dovrebbe essere una scelta molto informata. L'ho fatto da solo (raramente) in passato, ma in circostanze molto specifiche in cui i benefici hanno superato i costi.

— Paul White 9

2

Gli indici non allineati annullano il vantaggio principale del partizionamento che sta cambiando le partizioni. Se non dipendi da questo e stai partizionando per altri motivi (archiviazione diversa, partizioni di sola lettura, statistiche incrementali, ...) vai avanti e crea un indice non allineato.

Gli indici non allineati sono utili perché è possibile applicare vincoli univoci sull'intera tabella con essi. Inoltre, gli indici non allineati non richiedono che la chiave di partizionamento sia un prefisso di ricerca implicito. Immagina di avere 10000 partizioni e query non basate sulla chiave di partizionamento. Il piano di esecuzione dovrà quindi cercare in 10000 partizioni se l'indice fosse allineato. Le altre risposte hanno ulteriori esempi.

— usr
fonte