Come evitare che il registro delle transazioni si riempia durante la riorganizzazione dell'indice?

Abbiamo più macchine in cui abbiamo pre allocato la dimensione del registro delle transazioni a 50 GB. La dimensione della tabella che sto cercando di riorganizzare è di 55 - 60 GB, ma aumenterà continuamente. Il motivo principale per cui voglio riorganizzare è quello di recuperare spazio e qualsiasi vantaggio in termini di prestazioni a causa di ciò è un ulteriore vantaggio.

Il livello di frammentazione della tabella è del 30 - 35%. Su alcune di queste macchine viene visualizzato l'errore "Registro transazioni pieno" e la riorganizzazione non riesce. La dimensione del registro delle transazioni raggiunge fino a 48 GB. Qual è un buon modo per contrastare questo? Non abbiamo attivato l'incremento automatico e sono riluttante a farlo.

Posso aumentare le dimensioni del registro a un valore maggiore, ma poiché le dimensioni della tabella aumentano in futuro, il valore potrebbe non essere sufficiente. Inoltre vanifica lo scopo di riorganizzare per recuperare spazio se intendo aumentare le dimensioni del registro allo stesso modo. Qualche idea su come posso contrastare efficacemente questo? L'uso della modalità Bulked non è un'opzione poiché la perdita di dati non è accettabile.

La migliore pratica è quella di REORGANIZEsotto la frammentazione di circa il 30% e REBUILDoltre. Semplicemente, REBUILDcrea una copia pulita, lo REORGANIZEfa in situ.

Controlla cosa stai effettivamente facendo: non hai un piano di manutenzione per entrambi?

Su tavoli più grandi (la tabella da 50 GB sta arrivando lì) ho visto REORGANIZEconsumare tutto lo spazio del registro delle transazioni se segui questa regola. Non spesso: un solo sistema con un determinato schema di carico. L' REORGANIZEappena eseguito fino a quando il registro ampliato e consumato tutto lo spazio su disco.

Siamo passati REBUILDinvece a non avere più problemi, ma abbiamo ignorato la frammentazione al di sotto del 25%. Questo ha funzionato meglio per noi: dovrai vedere se funziona per te.

REBUILDpuò influire sulle prestazioni più che REORGANIZEsulla produzione, ma a volte ciò può essere mitigato ONLINEdall'opzione (Enterprise Edition richiesta).

RIORGANIZZARE (come in ALTER INDEX ... RIORGANIZE) è un'operazione molto veloce (beh, soprattutto ...), che richiede una piccola quantità di log, può essere interrotta in qualsiasi momento e ripresa in seguito e funziona internamente in transazioni batch di piccole dimensioni :

la deframmentazione viene eseguita come una serie di transazioni brevi, pertanto non è necessario un registro di grandi dimensioni se i backup del registro vengono eseguiti frequentemente o se l'impostazione del modello di ripristino è SEMPLICE.

Sei sicuro di non parlare di una ricostruzione ? Un indice REBUILD è lento, costoso, consuma un'enorme quantità di log (se non è offline e non può essere minimamente registrato , la ricostruzione online non può essere minimamente registrata), è una singola transazione gigante e non può essere interrotta senza perdere tutto il lavoro.

Mi sembra che tu stia facendo una ricostruzione, che è un'operazione davvero eccezionale che non dovresti fare se non hai una ragione estremamente ben ponderata. Per quale tipo di recupero di spazio stai saltando? Qualcosa che DBCC CLEANTABLEnon gestirà? Hai controllato la struttura fisica della tabella, è stata spostata dalla struttura logica (vedi le colonne della tabella di SQL Server sotto il cofano per i dettagli)?

Se devi davvero ricostruire il tavolo, temo che non hai altra scelta che mordere il proiettile e allocare il registro necessario. Non lasciarlo crescere automaticamente, rallenterà solo il processo. Pre-crescere a 2,5 volte le dimensioni del tavolo.

Se la tabella è partizionata, è possibile ricostruire offline (e riorganizzare) una partizione alla volta. La ricostruzione online può essere eseguita solo a livello di intero tavolo.

Ho avuto questo problema prima.

• Hai un grande database e una piccola unità di registro. Vuoi riorganizzare (per una serie di motivi).
• Quando si tenta di eseguire questa operazione su una tabella frammentata di grandi dimensioni, il registro si riempie fino a quando l'unità di registro non è piena e quindi il comando si interrompe.
• Se è in modalità semplice, altre transazioni potrebbero non riuscire fino a quando il registro non viene cancellato nel punto di controllo successivo e se è in modalità completa, altre transazioni potrebbero non riuscire fino al backup del registro successivo. Interruzione!
• Se si è in modalità completa, si aumenta la frequenza di backup del registro ma ciò non aiuta a evitare il problema poiché la riorganizzazione viene eseguita in una transazione implicita, il registro non viene cancellato fino a quando la transazione non termina o si interrompe o viene interrotta.
• E vuoi davvero che la riorganizzazione venga completata.

È un po 'controintuitivo perché sai che se interrompi la riorganizzazione può continuare da dove era stata interrotta, è solo che una interruzione commette la transazione piuttosto che il rollback.

Ecco cosa fai. È un po 'lungo ma semplice.

• Pre-crescere il file di registro in dimensioni relativamente grandi, ma non al massimo. Fondamentalmente vuoi lasciare abbastanza spazio per fare un lavoro utile, oltre ad alcune piccole crescite se si verificano, in modo che le normali operazioni non si fermino.
• Creare un processo per eseguire la riorganizzazione dell'indice ("Riorganizza").

• Creare un avviso WMI agente ('Riorganizza valvola di sicurezza') su una condizione di prestazione.

  • Oggetto: SQLServer: database
  • Contatore: registro percentuale utilizzato
  • Istanza: (il tuo nome di database grande)
  • Avviso se il contatore sale sopra: 80
  • Risposta: Esegui processo ('Riorganizza controllo')

• Crea un lavoro ('Riorganizza assegno')

  • Nel lavoro controllare msdb.dbo.sysjobactivity per vedere se il lavoro 'Riorganizza' è in esecuzione. E se è ...
  • Interrompere il processo e eseguire il polling fino a quando non si interrompe. Questo può richiedere alcuni secondi.
  • (Se si è in modalità completa) Attivare il processo di backup del registro e confermare al termine.
  • Ricontrolla i contatori sys.dm_os_performance_co che il contatore dello spazio libero nel registro ha ridotto al di sotto della soglia.
  • Avviare il lavoro "Riorganizza".

• Prova questo da qualche parte, anche una sandbox di sviluppo, per assicurarti che funzioni correttamente prima di attaccarlo sul tuo server di produzione.

Quello che vedrai è che il lavoro 'Riorganizza' inizia e inizia a riempire il registro. Quando il registro raggiunge una percentuale piena, attiva l'avviso WMI (entro circa 30 secondi) che esegue l'altro lavoro che vede che il lavoro "Riorganizza" è in esecuzione e quindi probabilmente in errore. Quindi interrompe "Riorganizza", esegue un backup, conferma che lo spazio disponibile nel registro torna a un valore ragionevole, quindi avvia nuovamente il processo "Riorganizza" che riprenderà da dove era stato interrotto.

Quindi, come è possibile, il motivo per cui le dimensioni del log sono ridimensionate a una cifra ragionevole in questo scenario è quella di ridurre il numero di crescita / trigger / lavoro / arresto / riavvii, in modo che possa essere più efficiente e anche mantenere spazio sufficiente per il escrescenze occasionali che non vengono catturate nel tempo.

Questo è un tipo di strano scenario. Sono abbastanza sicuro che mi sarei lasciato sfuggire qualche anno fa e ovviamente ci sono problemi fondamentali alla base qui. Ma se hai a che fare con centinaia di server, emergeranno alcuni casi limite come questo che non possono essere risolti in alcun modo, per qualsiasi motivo commerciale, tranne MacGyvering, una soluzione temporanea che porta a termine il lavoro.

Finché è sicuro, logico, testato e ben documentato, non dovrebbero esserci problemi.

Questo è ciò che di solito ho fatto (ho anche alcune tabelle con 80 + GB di larghezza ciascuna) per il reorg dell'indice (perché il reorg dell'indice può essere interrotto in qualsiasi momento senza perdere il lavoro di reorg precedente).

1. Durante la reindirizzamento dell'indice aumenterò il backup di tlog dalla mia normale frequenza di 30 minuti a ogni 10 minuti di frequenza
2. Ho un'altra sessione che esegue il controllo dello spazio libero su tlog ogni 1 minuto e se lo spazio libero su tlog è al di sotto di una soglia, interromperò la sessione di rimbalzo dell'indice e avvierò (o aspetterò) il backup di tlog. Quindi riavviare l'indice reorg.

Nel mio framework di manutenzione degli indici, categorizzo gli indici in due gruppi, uno per la ricostruzione dell'indice e un altro per il rimbalzo dell'indice. Per la ricostruzione dell'indice, userò un approccio leggermente diverso perché non voglio interrompere una sessione di ricostruzione dell'indice (che causerà un rollback e perderà tutto il lavoro precedente). Durante la ricostruzione dell'indice, se la mia sessione di monitoraggio rileva uno spazio libero nel file tlog esaurito lo scenario, la sessione di monitoraggio pre-aumenta automaticamente il file tlog e, nel peggiore dei casi (ovvero il disco è pieno), la mia sessione di monitoraggio creerà un altro file di registro ( ma dopo lo lascerò cadere) su un'altra unità (l'unità di backup)

Ho avuto lo stesso problema dell'autore della domanda e, guardando i suoi commenti, posso dire di avere la stessa configurazione. Mentre stavo provando a fare un REORGANIZE, il registro diventa pieno, indipendentemente dalle dimensioni, anche a più volte la dimensione dell'intera tabella.

Il problema è stato causato dalla replica transazionale . Apparentemente, non è possibile eseguire il backup del registro fino al termine REORGANIZEdell'operazione. Ho letto da qualche parte che era un problema noto di Microsoft, ma non sono sicuro di dove.

Una volta disabilitata la replica transazionale, i backup dei log hanno funzionato di nuovo normalmente e l'esecuzione dei backup dei log ogni 30 secondi durante la riorganizzazione ha funzionato bene per me.

Suppongo che stai eseguendo qualcosa sulla falsariga di:

ALTER INDEX ON RIORGANIZE

Sfortunatamente, non è possibile eseguire un'organizzazione parziale (ad esempio il modo in cui è possibile ridurre parzialmente un file di registro). I modi in cui posso pensare a questi problemi sono:

1) imposta il database in modalità di recupero semplice mentre esegui la riorganizzazione, ma hai detto che non è accettabile

2) partizionare l'indice - se riesci a pensare a un modo per partizionare l'indice per ottenere partizioni approssimativamente uguali, sarai in grado di riorganizzare (o ricostruire con l'opzione online) ogni partizione in modo indipendente e quindi limitare la crescita del file di registro

Sono sicuro che lo stai facendo, ma se non lo sei, potresti voler avviare un backup del file di registro prima e dopo aver fatto le ottimizzazioni dell'indice, che gli consentiranno di recuperare spazio utilizzato.