DBA preoccupato di riorganizzare o ricostruire gli indici può causare la perdita di dati?

Abbiamo alcuni database con una frammentazione dell'indice> 95%. Come meglio posso dire che gli indici non sono mai stati ricostruiti molto meno riorganizzati. In anni.

(In tutta onestà, in queste tabelle sembra che siano abilitate le statistiche di aggiornamento automatico. Inoltre, in tutta onestà, è diligente sui backup: registri giornalieri completi e trx ogni ora.)

Quando ho chiesto, il DBA ha detto che era riluttante a ricostruire o riporgiare gli indici. Quando ho chiesto il perché, non è stato in grado di articolarlo davvero. Alla fine ha detto di essere preoccupato per la potenziale perdita di dati. Ad esempio, uno dei database è utilizzato dalla nostra applicazione di contabilità di Great Plains Dynamics e sembrava molto preoccupato per questo.

Non sono un DBA ma da quello che ho letto, la sua ansia sembra ... difficile per me capire.

Non sono sicuro di cosa farò dopo. Suggerimenti come devo procedere?

sql-server maintenance

— Greg Hendershott
fonte

A meno che quel database non sia colpito duramente 24 ore su 24, 7 giorni su 7, e il mondo finirà se non è in linea, non ci sono scuse per tale comportamento. Scrivo reorgs e statistiche ogni settimana su oltre 12.000 database senza pensarci due volte. In 16 anni ho avuto solo un danneggiato a causa di un controller difettoso.

— Brain2000,

Risposte:

La ricostruzione di un indice del database non dovrebbe causare alcuna perdita di dati. Tuttavia, probabilmente causerà un sostanziale peggioramento delle prestazioni poiché gli indici da ricostruire non saranno normalmente disponibili per l'uso fino al termine della ricostruzione. Per tale motivo, dovrebbe essere eseguito durante le ore di inattività quando i sistemi interessati sono inattivi.

La paranoia è una buona cosa in un DBA - Se sono preoccupati per la perdita di dati, li farei fare un test adeguato dei backup (ripristinarli su un sistema separato e assicurarsi che i dati siano tutti lì), e se sono preoccuparsi ancora di eseguire un backup completo prima di ricostruire gli indici sarebbe una ragionevole precauzione da prendere.

— voretaq7
fonte

+1 per Paranoia è un buon tratto DBA

— Joel Coel,

Comprendo e apprezzo completamente la paranoia sana. Misura due volte, taglia una volta. Dove sono sconcertato sembra che ciò sia dovuto alla mancanza di comprensione piuttosto che alla cautela. E piuttosto che "determiniamo un modo per provarlo, attentamente", è "sì, non accadrà". Potremmo (dire) eseguire lo spooling di un'istanza di test EC2 con una copia dei dati, riprogrammare gli indici, cronometrare, delta le righe della tabella dei risultati per confermare che nessun dato è stato danneggiato. Quel tipo di piano sarebbe prudente ... al contrario di inazione?

— Greg Hendershott,

Solo un promemoria che la riorganizzazione dell'indice è sempre online (tutti gli indici sono disponibili durante la deframmentazione) e la ricostruzione dell'indice può essere effettuata anche online ( WITH (ONLINE=ON)purché l'indice non contenga colonne BLOB.

— Remus Rusanu

@Greg Sì, la mentalità "Non limitiamoci a toccare gli indici che sono così frammentati che probabilmente fanno male alla performance" mi confonde anche l'inferno - L'occasionale REINDEXcome "manutenzione preventiva" sui tavoli in cui il contenuto dell'indice cambia molto è bello comune nella mia esperienza (se l'indice è per lo più statico è meno di una cosa)

— voretaq7

@Remus buon consiglio - Questo riduce l'impatto delle prestazioni (avrai ancora I / O su disco elevato, che ti rallenterà alcuni, ma almeno le cose che potrebbero usare un indice possono comunque usarlo piuttosto che ricorrere a scansioni sequenziali )

— voretaq7,

Non vi è alcun rischio di perdita di dati dovuta alla ricostruzione o alla deframmentazione degli indici.

— mrdenny
fonte

A meno che tu non abbia già un certo grado di corruzione dei dati o hardware difettoso. Ma in entrambi i casi, la frammentazione dell'indice è l'ultima delle tue preoccupazioni!

— db2,

Ma questo non sarebbe corruzione da una ricostruzione dell'indice, ma da qualche altro problema.

— mrdenny,

La riorganizzazione degli indici richiederà meno tempo e meno sforzi dal server SQL, pertanto possono essere eseguiti in un tipo di istanze settimanali. Se quello che stai dicendo è vero, anche riorganizzare gli indici che non sono mai stati, potresti avere un impatto maggiore anche sul server. La ricostruzione degli indici richiederà un notevole sforzo dal server SQL poiché vengono eliminati e ricostruiti. Fare una ricostruzione durante una settimana non vale il rischio che il server sia occupato con gli indici e non serva le persone che lo usano.

Concordo con voretaq7, se è così preoccupato di lavorare con gli indici, provalo prima sullo sviluppo o sui server di prova per vedere come reagisce.

— controllo della frequenza
fonte

Un altro approccio da adottare potrebbe essere quello di esplicitamente DROP INDEXe ri CREATE INDEX- Non sono sicuro di SQL Server, ma so che PostgreSQL a volte fa meglio a soffiare via un indice e ricominciare da zero piuttosto che provare a ricostruirlo ( REINDEX).

— voretaq7,

Sono abbastanza sicuro che non è necessario eliminare e ricreare su SQL Server.

— Justin Dearing

@Justin Sono abbastanza sicuro che tu abbia ragione (in effetti dai miei giorni di Sybase ricordo che un comportamento reindicizzante è effettivamente un calo / creazione, quindi non c'è stranezza che blocca l'indice come in Postgres)

— voretaq7

La riorganizzazione degli indici può richiedere meno tempo. Quale impiegherà più tempo dipenderà dalla quantità di frammentazione dell'indice.

— mrdenny,