Jump to content

Wiederherstellungsmodell und die Auswirkung auf die Performance


Direkt zur Lösung Gelöst von NilsK,
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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.

Link zu diesem Kommentar
  • Beste Lösung

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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar

@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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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. 

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...