Ausschließen von Indizes von Sicherungen in SQL Server 2008

19

Unsere nächtlichen vollständigen (und periodischen differenziellen) Sicherungen werden ziemlich umfangreich, was hauptsächlich auf die Anzahl der Indizes in unseren Tabellen zurückzuführen ist. Etwa die Hälfte der Sicherungsgröße besteht aus Indizes.

Wir verwenden das einfache Wiederherstellungsmodell für unsere Sicherungen.

Gibt es eine Möglichkeit, durch Verwendung einer FileGroupsoder einer anderen Dateipartitionierungsmethode Indizes von den Sicherungen auszuschließen ?

Es wäre schön, wenn dies auch auf Volltextkataloge ausgeweitet werden könnte.

— Jarrod Dixon
quelle

15

Wenn Sie in den vollständigen Wiederherstellungsmodus wechseln, können Sie dies mit Dateigruppen tun, aber es ist wirklich sehr, sehr umständlich. Sie belassen die Daten in der primären Dateigruppe und platzieren die Indizes in einer separaten Dateigruppe (nicht standardmäßig, das ist der Schlüssel).

Anschließend werden die Sicherungen gestaffelt, sodass jede Nacht Dateigruppensicherungen der Primärdatenbank und Transaktionsprotokollsicherungen alle X Minuten ausgeführt werden.

Im Katastrophenfall stellen Sie die primäre Dateigruppe selbst wieder her. Die Daten sind plötzlich online, die Indizes jedoch nicht. Um jedoch zur Normalität zurückzukehren, müssen Sie diese Daten in eine neue saubere Datenbank exportieren und von dort Indizes hinzufügen. Sie können die Datenbank nicht vollständig online stellen, ohne alle Dateigruppen wiederherzustellen, und Sie können nicht sagen, dass ich diese andere Dateigruppe sowieso nicht mehr benötige.

Weitere Informationen zur Funktionsweise finden Sie in meinem Video-Tutorial zu Dateigruppenwiederherstellungen.

— Brent Ozar
quelle

Hehe, ich hatte die nicht gruppierten Indizes in ihre eigene Dateigruppe verschoben. Das Simple Recovery-Modell hat mich völlig behindert. Die Indizes waren tatsächlich größer als die Daten - wie verspottet es mich! Na ja, vielleicht veröffentlichen Dritte einen magischen Hinweis :)

— Jarrod Dixon

1

Und vielleicht, nur vielleicht, erhalten Sie dafür eine kostenlose Lizenz. ;-)

— Brent Ozar

5

Ehrlich gesagt, wollen Sie das wirklich nicht, auch wenn Sie die anderen Probleme überwinden, die andere hier ansprechen.

Wenn Sie die Sicherung im Notfall wiederherstellen, möchten Sie nicht warten, bis die Indizes neu erstellt wurden, und Sie werden eine abscheuliche Leistung erleiden, bis Sie dies tun.

Ich kann mir keine Situation vorstellen, in der Sie eine Sicherung ohne Indizes wiederherstellen möchten. In jedem Fall möchten Sie sie also wirklich gleichzeitig sichern.

Sie werden wahrscheinlich nach anderen Lösungen für dieses Problem suchen müssen ...

-Adam

— Adam Davis
quelle

1

"Sie wollen nicht darauf warten, dass die Indizes neu erstellt werden", vermutet IMO

— Jeff Atwood

2

Ja, aber denken Sie daran, ich verallgemeinere hier. Ich war nicht davon überzeugt, dass es mehr Situationen gibt, in denen es besser ist, die Indizes fallen zu lassen und neu zu erstellen, als Situationen, in denen es besser ist, die Indizes zu sichern und eine Neuerstellung zu vermeiden. Mit anderen Worten, ein Fall ist im Allgemeinen besser, und wenn eine bestimmte Situation dies nicht erfordert, sollte man sich auf die Seite des Sicherns dieser Fälle begeben. Davon abgesehen ist jede Situation anders. Ich bin gespannt, wie lange es dauert, die SO-Indizes neu zu erstellen, und wie stark die Leistung der Site leidet, bis sie fertig ist (vorausgesetzt, sie ist während der Neuerstellung aktiv).

— Adam Davis

Langzeitarchivierung ist der spezielle Anwendungsfall, den ich gerade betrachte und der mich zu dieser Frage geführt hat. Ich habe ein Projekt, das abgeschlossen ist und die Datenbank nicht mehr online haben möchte, aber ich muss auch unser Netzlaufwerk nicht mit einer größeren Sicherungsdatei überladen als nötig. Ich möchte die Indexdefinitionen nicht verlieren, hätte aber nichts dagegen, sie neu zu erstellen, wenn ich sie jemals wieder herstellen müsste.

— richardtallent

3

Es hört sich so an, als ob dies nicht unterstützt wird. Aus diesem Fehlerbericht :

Es gab großes Interesse an diesem Produkt, daher werde ich etwas näher darauf eingehen, was sich hinter den Kulissen abspielt und was es bedeuten würde, diese Funktionalität zu implementieren. Einige Arten von Indexseiten werden in separate Zuordnungseinheiten unterteilt, während andere mit den Datenseiten gemischt werden. Wo wir uns derzeit nur die Zuordnungsbitmap ansehen, um festzustellen, ob eine Ausdehnung zugeordnet ist, müssen wir jetzt untersuchen, was in jeder Zuordnungseinheit gespeichert ist. Außerdem könnten wir jetzt nicht nur einen linearen Scan der Datendateien durchführen, um Daten zu kopieren. Wir würden in der Datei herumspringen. All diese Interpretation der Datenstrukturen würde das Backup drastisch verlangsamen. Die Wiederherstellung wird noch interessanter, da es viele Strukturen gibt, die repariert werden müssten, um die Lücken in der Sicherung zu schließen. Andernfalls hätten Sie Zuordnungszuordnungen, die auf Seiten verweisen, die nicht gesichert wurden, und in denen sich also Abfall befindet, usw. usw. Wenn Sie dies implementieren, würden wir weniger Daten speichern, länger brauchen und viel Zeit in Anspruch nehmen länger wiederherstellen. Die andere zu berücksichtigende Facette ist, dass dies einen großen technischen Aufwand erfordern würde, um alles in Ordnung zu bringen. Auch wenn dies an der Oberfläche nicht Ihr Problem ist, bedeutet dies, dass andere Features, die Sie möglicherweise sehen möchten, nicht erstellt werden.

— Jon Galloway
quelle

Dies wäre kein Problem für Volltextindizes, oder? Diese neigen dazu, ziemlich groß zu sein.

— Michael Teper

1

vielleicht eine verrückte idee, aber hier geht.

Löschen Sie Ihre nicht gruppierten Indizes, die viel Speicherplatz beanspruchen
mache ein Backup
Erstellen Sie die abgelegten Indizes neu

Natürlich können Sie dies nur dann wirklich tun, wenn Ihre Datenbank tagsüber einige Ausfallzeiten zulässt.

Löschen Sie auch nicht Ihre Clustered-Indizes, da SQL Server viel Zeit damit verschwendet, diese in einen Heap zu konvertieren.

Scheint der Kauf dieses zusätzlichen Speicherplatzes noch eine einfachere Lösung zu sein?

Haben Sie darüber nachgedacht, komprimierte Backups zu erstellen ? Dies ist ein neues Feature von 2008, es kann eine Option für Sie sein.

— Nick Kavadias
quelle

Ja, wir haben die Komprimierung für Backups aktiviert, aber die integrierte Komprimierung ist nicht besonders gut. Wir haben tatsächlich ein nicht komprimiertes Backup erstellt, das am Ende der Woche erstellt wurde, und es dann für uns Entwickler komprimiert, um es herunterzufahren. es ist ungefähr 1/3 der Größe, aber es dauert einige Zeit, um zu laufen!

— Jarrod Dixon

Könnten wir in Bezug auf DB-Ausfallzeiten wirklich so weit wie möglich ohne serverfault.com und stackoverflow.com auskommen ? Ich schaudere bei diesem Gedanken :)

— Jarrod Dixon

Ich habe es nicht selbst getestet, aber ich habe es auch vermutet. Es ist nicht sehr konfigurierbar. Wenn Sie immer noch die Komprimierung als Option in Betracht ziehen, schauen Sie sich SQL Lightspeed (teuer, aber großartig, aber der Preis ist sehr verhandelbar) und RedGates SQL Backup an. Sehr konfigurierbar und hervorragende Ergebnisse

— Nick Kavadias