Come escludere gli indici dai backup in SQL Server 2008

19

I nostri backup notturni completi (e periodici differenziali) stanno diventando piuttosto grandi, principalmente a causa della quantità di indici sui nostri tavoli; circa la metà della dimensione del backup è composta da indici.

Stiamo utilizzando il modello di recupero semplice per i nostri backup.

Esiste un modo, tramite l'utilizzo FileGroupso qualche altro metodo di partizionamento dei file, di escludere gli indici dai backup?

Sarebbe bello se questo potesse essere esteso anche ai cataloghi full-text.

— Jarrod Dixon
fonte

15

Se passi alla modalità di recupero completo, puoi farlo con i filegroup, ma è davvero, molto goffo. Lascia i dati nel filegroup primario e inserisci gli indici in un filegroup separato (non predefinito, questa è la chiave).

Quindi scaglionare i backup in modo da eseguire backup di filegroup del primario ogni notte e backup del registro delle transazioni ogni X minuti.

Quando si verifica un disastro, ripristini il filegroup primario da solo. I dati sono improvvisamente online, ma gli indici no. Tuttavia, per tornare alla normalità, dovrai esportare quei dati in un nuovo database pulito e aggiungere indici da lì. Non puoi portare il database completamente online senza ripristinare tutti i filegroup e non puoi dire "Non ho più bisogno di quell'altro filegroup".

Per ulteriori informazioni su come funziona, dai un'occhiata al mio video tutorial sui ripristini di filegroup.

— Brent Ozar
fonte

Hehe, avevo spostato gli indici non cluster nel loro filegroup; il modello Simple Recovery mi ha completamente ostacolato. Gli indici erano in realtà più grandi dei dati - come mi hanno provocato! Vabbè, forse qualche terza parte rilascerà un suggerimento di suggerimento per proiettili magici :)

— Jarrod Dixon

1

E forse, solo forse, otterrai licenze gratuite per questo. ;-)

— Brent Ozar

5

Onestamente, non vuoi davvero farlo, anche se superi le altre questioni sollevate da altri.

Quando ripristini il backup in caso di emergenza, non vuoi aspettare la ricostruzione degli indici e subirai prestazioni abominevoli fino a quando non lo fai.

Non riesco a pensare a una situazione in cui vorresti ripristinare un backup senza indici, quindi in tutti i casi vorrai davvero eseguirne il backup allo stesso tempo.

Probabilmente dovrai cercare altre soluzioni a questo problema ...

-Adamo

— Adam Davis
fonte

1

"non vuoi aspettare che gli indici vengano ricostruiti" molto presuntivo, IMO

— Jeff Atwood,

2

Sì, ma tieni presente che sto generalizzando qui. Non sono stato convinto che ci siano più situazioni in cui è meglio abbandonare gli indici e ricostruirle che ci sono situazioni in cui è meglio eseguire il backup degli indici ed evitare una ricostruzione. In altre parole, un caso è generalmente migliore e, a meno che una particolare situazione non lo richieda, si dovrebbe sbagliare sul lato del backup. Detto questo, ogni situazione è diversa. Sono curioso di sapere quanto tempo ci vuole per ricostruire gli indici SO e quanto le prestazioni del sito subiscono fino a quando non sono terminate (supponendo che siano aumentate durante la ricostruzione).

— Adam Davis,

Il backup di archivio a lungo termine è il caso d'uso specifico che sto esaminando ora che mi ha portato a questa domanda. Ho un progetto completo e non voglio più il database online, ma non ho bisogno di ingombrare la nostra unità di rete con un file di backup più grande del necessario. Non voglio perdere le definizioni dell'indice, ma non mi dispiacerebbe ricostruirle se dovessi mai ripristinarle.

— richardtallent,

3

Sembra che questo non sia supportato. Da questa segnalazione bug informazioni :

C'è stato molto interesse in questo, quindi entrerò un po 'più in dettaglio su ciò che sta accadendo dietro le quinte e cosa significherebbe implementare questa funzionalità. Alcuni tipi di pagine di indice sono separati in unità di allocazione separate, mentre altri sono mescolati con le pagine di dati. Laddove attualmente guardiamo solo la bitmap di allocazione per vedere se un'estensione è allocata, ora dovremmo andare e interpretare ciò che è memorizzato in ogni unità di allocazione. Inoltre, ora non saremmo in grado di eseguire solo una scansione lineare dei file di dati copiando i dati, saltando nel file. Tutta questa interpretazione delle strutture dati rallenterebbe drasticamente il backup. Il ripristino diventa ancora più interessante, perché ci sono molte strutture che dovrebbero essere riparate per tenere conto dei buchi nel backup. Altrimenti avresti mappe di allocazione che puntano a pagine di cui non è stato eseguito il backup, e quindi contengono spazzatura in esse, ecc. Ecc. Quindi, implementando questo significherebbe che risparmieremmo meno dati, impiegheremmo più tempo a farlo e impiegheremmo molto ripristinandolo più a lungo. L'altro aspetto da considerare è che ciò richiederebbe una grande quantità di sforzi ingegneristici per ottenere tutto a posto. Anche se questo non è il tuo problema in superficie, considera che significa che altre funzionalità che potresti voler vedere non verranno sviluppate.

— Jon Galloway
fonte

Non sarebbe un problema per gli indici full-text, vero? Quelli tendono ad essere piuttosto grandi.

— Michael Teper,

1

potrebbe essere un'idea folle, ma qui va.

rilasciare gli indici non cluster che occupano molto spazio
fare un backup
ricrea gli indici che hai lasciato cadere

Ovviamente puoi farlo davvero solo se il tuo database consente alcuni tempi di inattività nel corso della giornata.

Inoltre, non eliminare gli indici cluster poiché SQL Server sprecherà molto tempo convertendoli in un heap.

L'acquisto di quello spazio su disco aggiuntivo sembra ancora una soluzione più semplice?

Hai pensato di fare backup compressi ? questa è una nuova funzionalità del 2008, potrebbe essere un'opzione per te.

— Nick Kavadias
fonte

Sì, abbiamo attivato la compressione per i backup, ma la compressione integrata non è eccezionale. In realtà abbiamo un backup non compresso di fine settimana, quindi 7zip per noi sviluppatori da abbattere; è circa 1/3 della dimensione, ma richiede del tempo per l'esecuzione!

— Jarrod Dixon

Per quanto riguarda i tempi di inattività del DB, potremmo davvero vivere senza serverfault.com e stackoverflow.com il più possibile? Rabbrividisco a quel pensiero :)

— Jarrod Dixon

Non l'ho provato da solo, ma sospettavo altrettanto. Non è molto configurabile. Se stai ancora guardando la compressione come opzione dai un'occhiata a SQL Lightspeed (costoso, ma fantastico, ma il prezzo è molto negoziabile) e SQL Backup di RedGate. Risultati molto configurabili ed eccellenti

— Nick Kavadias,