Halten Sie (Teil-) Sicherungen klein, wenn Sie SQL Server FILESTREAM verwenden

Ich habe eine Datenbank mit fast 1 TB FILESTREAMDaten, die ich nicht sichern muss (wenn die Daten gelöscht wurden, werden sie in ein paar Stunden automatisch neu erstellt, es ist also einfach nicht wichtig). Die meisten Daten werden alle paar Tage geändert, sodass differenzielle Sicherungen nicht wirklich dazu beitragen würden, die Größe niedrig zu halten.

Ich hatte die Backups so, wie ich es brauchte, indem ich den Wiederherstellungsmodus auf Fullstellte, ein separates Backup FILEGROUPfür das erstellte FILESTREAMund dann Backups nur für das "Primäre" erstellte FILEGROUP. Das dadurch verursachte Problem bestand darin, dass die Protokolldatei (die ebenfalls gesichert wird) jetzt unnötig groß ist, da sie die FILESTREAMDaten enthält.

SIMPLEDer Wiederherstellungsmodus nimmt mir die Möglichkeit, Backups bestimmter FILEGROUPDateien zu erstellen, und ich denke, dass dies auch keine Option sein wird.

Ich denke nur daran, die FILESTREAMDaten in eine separate Datenbank zu verschieben, aber jetzt verliere ich die referenzielle Integrität und erbe sicherlich auch eine Reihe anderer Probleme.

Gibt es eine Möglichkeit, Teilsicherungen im SimpleWiederherstellungsmodus zu erstellen (ohne die FILESTREAMTabelle schreibgeschützt zu machen)? Wenn nicht, gibt es andere vernünftige Lösungen für mein Problem?

Das dadurch verursachte Problem bestand darin, dass die Protokolldatei (die ebenfalls gesichert wird) jetzt unnötig groß ist, da sie die FILESTREAM-Daten enthält.

Ich bin mir nicht sicher, ob die Protokolldatei selbst zu groß ist oder ob die Sicherungskopien der Protokolldateien zu groß werden.

Wenn es das erstere ist, wie oft haben Sie dann das Protokoll gesichert? Abhängig vom Anwendungsdesign können Sie die Größe möglicherweise durch häufigeres Sichern reduzieren (und alle 5 Minuten ist dies nicht zu häufig). Wenn Sie dies jedoch bereits getan haben und es immer noch im Aufschwung war, haben Sie wahrscheinlich kein Glück. Warum ist die große Protokolldatei wieder ein Problem?

Wenn es das letztere ist, hat es sich angehört, als wären Sie froh, mit dem einfachen Wiederherstellungsmodell fortzufahren, und es wird zu keinem Zeitpunkt wiederhergestellt, wenn Sie kleinere Sicherungen haben. In diesem Fall sollten Sie im Vollmodus bleiben und Ihre Protokollsicherungen verwerfen.

Eine Lösung für eine Datenbank, die auf den Wiederherstellungsmodus SIMPLE eingestellt ist, besteht darin, die FILESTREAM-Daten in einer schreibgeschützten Dateigruppe zu speichern (was nicht die ideale Option ist) und dann nur die Lese- / Schreibdateigruppen mit DIFFERENTIAL wie folgt zu sichern:

BACKUP DATABASE [name] READ_WRITE_FILEGROUPS TO DISK = '' WITH DIFFERENTIAL, COMPRESSION;

Es werden alle Daten abgerufen, die sich in Lese- / Schreibdateigruppen geändert haben. Dies ist die einfachste Möglichkeit, Teilsicherungen ohne Abruf der FILESTREAM-Daten zu verwalten. Es wäre jedoch erforderlich, dass der Ladevorgang für die oben genannten Daten die Dateigruppe zum Lesen / Schreiben ändern, zusätzliche Daten laden und dann erneut auf Lesen festlegen muss. Mit Sicherheit nicht ideal.

Ich fühle mich schmutzig, wenn ich dies als Option zur Verfügung stelle. Wenn Sie jedoch die FILESTREAM-Daten in eine eigene Datenbank aufteilen, können Sie RI zwischen den Tabellen in den separaten DBS mithilfe von Triggern verwalten :

Trigger -> Bemerkungen -> Einschränkungen:
Ein Trigger wird nur in der aktuellen Datenbank erstellt. Ein Trigger kann jedoch auf Objekte außerhalb der aktuellen Datenbank verweisen.

Erwarten Sie, dass Leistungsprobleme und ein Teil Ihrer Kopfhaut haarlos werden, nachdem Sie sich frustriert die Fellbüschel vom Kopf gezogen haben. Theoretisch könnten Sie dies jedoch tun. Ich empfehle diesen Ansatz auf keiner Ebene, sondern empfehle nachdrücklich, die Häufigkeit Ihrer Protokollsicherungen zu erhöhen und / oder auf das massenprotokollierte Wiederherstellungsmodell zu wechseln, um zu sehen, wie viel Speicherplatz Sie sparen, ABER dies ist eine mögliche Lösung. Eigentlich müssten Sie den Vorteil abwägen, diese Daten zu trennen und sich mit einem Frankensteinschen Datenbankdesign zu befassen, aber es ist eine Option.

... Ich muss jetzt duschen gehen ...

Ich weiß, dass diese Frage bereits beantwortet ist, aber es gibt eine andere Lösung, die anderen helfen könnte. Kürzlich habe ich aus dem Blog von Brent Ozar erfahren, dass es eine Option gibt, um Ihre Protokollsicherungen sofort zu verwerfen:

BACKUP LOG MyDb TO DISK='NUL:'

So können Sie Ihre Datenbank im FullWiederherstellungsmodus belassen und Sicherungskopien von Dateigruppen erstellen. Wenn Ihr Transaktionslog zu groß wird, geben Sie einfach den Befehl backup log ein und Sie sind fertig.