Wiederherstellungsmodell und die Auswirkung auf die Performance

[Coldasice 12]

Hallo Leute,

 

mich interessiert aktuell die Frage, ob sich das Wiederherstellungsmodell auf die Performance auswirkt.

Generell muss eine Produktivdatenbank immer im Vollständigen Modus laufen, vor allem wenn wir über kritische Daten/Anwendungen sprechen.

Ich persönlich kann mir auch nicht vorstellen, das sich das auf die Performance auswirken kann.

Evtl. kann es für den Moment der Logsicherung zu erhöhter CPU- und Plattenlast kommen, aber wenn die Logs nicht gerade mehrere GBs haben sollte sich das doch auch in Grenzen halten.

 

Habe ich hier etwas übersehen oder liege ich richtig?

 

Danke schon mal.

[NilsK 2.934]

Moin,

 

im Wesentlichen liegst du richtig. Mögliche Performance-Auswirkungen entstehen durch das Logging selbst (welches man nicht abschalten kann), aber nicht durch das Recovery Model. Wenn es also kritisch auf Performance ankommt, braucht man für die Logs ein Storage, das lineare Schreibvorgänge schnell erledigt.

 

Gruß, Nils

[zahni 554]

Zum Recovery-Modell: Hier  muss man sich wirklich darüber im Klaren sein, ob man eine Recovery-Möglichkeit bis  hin zur einzelnen Transaktion auf jeder Datenbank benötigt.

Bei unseren MS-SQL-Datenbanken habe wir uns darüber Gedanken gemacht und sind zu dem Schluss gekommen, dass ein tägliches Backup ausreicht. Daher Recovery-Modell Simple und Backup-Software macht immer ein Full-Backup am Abend.

Das Vereinfacht  ein Restore, z.B. in eine Testumgebung, auch ungemein.

 

Unsere unternehmenskritischen Daten liegen auf Datenbanken anderer Hersteller. Hier machen wir täglich auch ein Offline Full-Backup, wobei hier teilweise anwendungsseitig Änderungen historisiert werden.

[NilsK 2.934]

Moin,

 

ja, das ist genau der richtige Ansatz. Viele Admins stellen das Recovery Model pauschal auf "Full" in der Annahme, das sei das einzige, was zum Produktionsbetrieb taugt. Das ist aber, wie du richtig sagst, mitnichten so, es gibt viele Szenarien, in denen man für die Wiederherstellung keine höhere Auflösung braucht als "täglich" - und damit eben auch einfachere Prozesse. Insgesamt sehe ich das "Full Recovery Model" als Ausnahmefall für besondere Anforderungen an.

 

Hier habe ich das mal diskutiert:

 

https://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/

 

Gruß, Nils

[monstermania 53]

@zahni

@NilsK

Mir hat das SQL Full Recovery schon mehrfach den A..ch gerettet.  :)

Einfach weil wir im Problemfall die Sicherung bis fast an den Crash wieder herstellen konnten. Und nein, die Probleme wurden nicht durch mich/uns verursacht, sondern immer durch andere Consultants/Techniker oder Software-Bugs. Da werden dann mal eben irgendwelche Änderungen im Echtbetrieb an der Datenbank gemacht, die dann voll in die Hose gehen, oder im RAID die falsche Platte gezogen...

 

Ich richte eigentlich immer standardmäßig ein Full Recovery für SQL-Datenbanken ein. Täglich erfolgt eine Vollsicherung und dann stündlich eine Sicherung des Transaktionsprotokolls (Agent).

Frei nach dem Motto: Lieber zuviel sichern, als hinterher der Dumme sein.

[Dukel 454]

Wenn man weiß was man tut ist da ja in Ordnung. Andere richten das Full Recovery Model ein und wundern sich wenn der SQL Server steht, da die Disk mit den Transaktionsprotokollen vollläuft.

[zahni 554]

@montermania,

 

wir haben selbstverständlich auch ein Change-Verfahren implementiert. Hier führt nicht jeder "irgendwelche Skripte" auf Produktion-DBs aus. Und  bevor ich irgendein Update installiere, gibt es ein manuelles Backup.

Und aus der Netapp ziehe ich nur Platten raus, wenn die kaputt sind und entsprechend blinken, etc pp.

[Dukel 454]

Da werden dann mal eben irgendwelche Änderungen im Echtbetrieb an der Datenbank gemacht, die dann voll in die Hose gehen, oder im RAID die falsche Platte gezogen....

 

 

Alle Firmen haben eine Testumgebung, manche zusätzlich eine Produktive.

[NilsK 2.934]

Moin,

 

es steht ja auch nirgends, dass man "Full" nicht einsetzen soll. Es ist nur eben oft nicht nötig (meine These ist: über alles betrachtet, ist es sogar meistens nicht nötig). Und wenn man es einsetzt, muss man ein regelmäßiges Log-Backup einrichten, wie Dukel schon richtig sagt und wie auch in meinem Artikel ausführlich steht. Geh nicht davon aus, dass alle Unternehmen durchdachte Prozesse haben ...

 

Gruß, Nils

[zahni 554]

Das "Hauptproblem" ist hier meiner Meinung nach, dass da Recovery-Modell Full immer der Standard ist, wenn eine neue DB angelegt wird. Ganz im Gegensatz zu anderen Datenbanken.

Bei DB2 z.B. müsste man für "archive logging" Einiges konfigurieren. Allerdings kann ich bei DB2 ohne "archive logging" kein Online-Backup machen. Für das Offline-Backup müssen per "Holzhammer" alle Verbindungen zur DB getrennt werden.

[NilsK 2.934]

Moin,

 

da ist was dran.

 

Gruß, Nils

[monstermania 53]

Es ist nur eben oft nicht nötig (meine These ist: über alles betrachtet, ist es sogar meistens nicht nötig). Und wenn man es einsetzt, muss man ein regelmäßiges Log-Backup einrichten, wie Dukel schon richtig sagt und wie auch in meinem Artikel ausführlich steht.

Wie so oft, merkt man es leider immer erst zu spät, ob es nun nötig gewesen wäre!  ;) Ist fast so wie beim Backup. Keiner braucht Backup aber jeder will Restore.

Ich setze eigentlich voraus, dass man beim Einrichten der SQL-Backup-Jobs weiß, was man da tut bzw. sich vorher Gedanken macht. 

[v-rtc 88]

Es macht große Freude Euch zu zuhören... wusste gar nicht, dass Du DB2 Admin bist @zahni

Aber da hast Du schon recht Nils, man sollte sich fragen, was brauche ich im Restore Fall.

Es gab bei mir auch Datenbanken, die wir nur ein mal gesichert haben am Tag, ohne Logs. Dort wurde morgens neue Daten rein geschrieben, auf die man immer wieder zugreifen hätte können usw.

[NilsK 2.934]

Moin,

 

Ich setze eigentlich voraus, dass man beim Einrichten der SQL-Backup-Jobs weiß, was man da tut bzw. sich vorher Gedanken macht. 

 

ach, das wäre so schön. :D Ich predige das seit bald zwanzig Jahren, aber nur wenige Admins wollen überhaupt zuhören ...

 

Gruß, Nils

[NorbertFe 2.034]

Ist aber nicht auf SQL beschränkt dieses Verhalten. ;)