Zum Inhalt wechseln


Foto

Wiederherstellungsmodell und die Auswirkung auf die Performance


  • Bitte melde dich an um zu Antworten
14 Antworten in diesem Thema

#1 Coldasice

Coldasice

    Member

  • 169 Beiträge

 

Geschrieben 10. April 2017 - 15:50

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.



#2 NilsK

NilsK

    Expert Member

  • 12.401 Beiträge

 

Geschrieben 11. April 2017 - 06:48   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


  • Coldasice gefällt das

Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#3 zahni

zahni

    Expert Member

  • 16.474 Beiträge

 

Geschrieben 11. April 2017 - 07:55

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.


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#4 NilsK

NilsK

    Expert Member

  • 12.401 Beiträge

 

Geschrieben 11. April 2017 - 08:13

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:

 

[SQL Server: Wie Datenablage, Backup und Recovery funktionieren | faq-o-matic.net]
https://www.faq-o-ma...-funktionieren/

 

Gruß, Nils


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#5 monstermania

monstermania

    Board Veteran

  • 1.189 Beiträge

 

Geschrieben 11. April 2017 - 09: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.



#6 Dukel

Dukel

    Board Veteran

  • 9.299 Beiträge

 

Geschrieben 11. April 2017 - 10:21

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.


  • NilsK gefällt das

Stop making stupid people famous.


#7 zahni

zahni

    Expert Member

  • 16.474 Beiträge

 

Geschrieben 11. April 2017 - 10:57

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


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#8 Dukel

Dukel

    Board Veteran

  • 9.299 Beiträge

 

Geschrieben 11. April 2017 - 11:03

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 gefällt das

Stop making stupid people famous.


#9 NilsK

NilsK

    Expert Member

  • 12.401 Beiträge

 

Geschrieben 11. April 2017 - 13:55

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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#10 zahni

zahni

    Expert Member

  • 16.474 Beiträge

 

Geschrieben 11. April 2017 - 14:32

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.


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#11 NilsK

NilsK

    Expert Member

  • 12.401 Beiträge

 

Geschrieben 11. April 2017 - 14:34

Moin,

 

da ist was dran.

 

Gruß, Nils


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#12 monstermania

monstermania

    Board Veteran

  • 1.189 Beiträge

 

Geschrieben 11. April 2017 - 14:45

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. 



#13 RolfW

RolfW

    Expert Member

  • 1.144 Beiträge

 

Geschrieben 11. April 2017 - 16:50

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.
- Carpe Diem -

"Ist mir jetzt egal, ich lass das jetzt so."

#14 NilsK

NilsK

    Expert Member

  • 12.401 Beiträge

 

Geschrieben 12. April 2017 - 04:56

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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#15 NorbertFe

NorbertFe

    Expert Member

  • 30.834 Beiträge

 

Geschrieben 12. April 2017 - 06:03

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

Make something i***-proof and they will build a better i***.