Jump to content
Melde dich an, um diesen Inhalt zu abonnieren  
Coldasice

Wiederherstellungsmodell und die Auswirkung auf die Performance

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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.

  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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. 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
Melde dich an, um diesen Inhalt zu abonnieren  

×