SQL 2008 R2 Sicherungsstrategie
Moin allerseits,
ich versuche gerade unseren SQL zu verbessern. Auf diesem laufen u.a. Datenbanken für unser CRM-System und die dazugehörigen DMS-Datenbanken.
Die CRM-DB unterliegt einer hohen Änderungsfrequenz, insbesondere weil ich einmal pro Woche einen Datenabgleich über ein externes Programm mache.
Bisher wird diese Datenbank einmal täglich mit einer Vollsicherung und Transaktionslog-Sicherungen gesichert (Sicherungstyp FULL der DB).
Wie sind Eure Erfahrungen um das Ganze zu beschleunigen? Die Serverhardware ist bei weitem nicht ausgelastet (CPU-Last bei ca.5-10%; RAM bei ca. 60% unter Vollast).
Meine Idee wäre nun die DB auf "Einfache Sicherung" umzustellen und dann eine tägliche Vollsicherung plus alle 4h eine Differenzielle Sicherung zu machen. Die Frage ist nur: Bringt das was?
Tipps und Denkanstöße sind wie immer herzlich willkommen
Gruß
Looser
ich versuche gerade unseren SQL zu verbessern. Auf diesem laufen u.a. Datenbanken für unser CRM-System und die dazugehörigen DMS-Datenbanken.
Die CRM-DB unterliegt einer hohen Änderungsfrequenz, insbesondere weil ich einmal pro Woche einen Datenabgleich über ein externes Programm mache.
Bisher wird diese Datenbank einmal täglich mit einer Vollsicherung und Transaktionslog-Sicherungen gesichert (Sicherungstyp FULL der DB).
Wie sind Eure Erfahrungen um das Ganze zu beschleunigen? Die Serverhardware ist bei weitem nicht ausgelastet (CPU-Last bei ca.5-10%; RAM bei ca. 60% unter Vollast).
Meine Idee wäre nun die DB auf "Einfache Sicherung" umzustellen und dann eine tägliche Vollsicherung plus alle 4h eine Differenzielle Sicherung zu machen. Die Frage ist nur: Bringt das was?
Tipps und Denkanstöße sind wie immer herzlich willkommen
Gruß
Looser
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 289306
Url: https://administrator.de/forum/sql-2008-r2-sicherungsstrategie-289306.html
Ausgedruckt am: 01.04.2025 um 21:04 Uhr
9 Kommentare
Neuester Kommentar
Hallo,
Auf was soll kommen - 12.000 km/S? Oder vielleicht nur 400 meter in 3 Sekunden? Oder einfach nur auf 16-fache Erd Schwerkraft?
Gruß,
Peter
Auf was soll kommen - 12.000 km/S? Oder vielleicht nur 400 meter in 3 Sekunden? Oder einfach nur auf 16-fache Erd Schwerkraft?
Die Frage ist nur: Bringt das was?
Bezogen auf was?Gruß,
Peter
Hi
6,5h für 160k Datensätze? Das ist schon arg langsam... Wir nutzen auch ein CRM, sowie ECM, PDM, ERP usw. die gesamten Datenbanken sind ~ 5 Tb inkl. Logs, die Sicherung dauert ca. 4,5h mit SQL Bordmitteln, das wird dann Tagsüber via Veeam Endpoint Backup in das Veeam Repository gesichert.
Für die Verfügbarkeit der Primärdatenbanken haben wir einen SQL im Standby laufen und dann via Log-Shipping wird die transferiert. Du kannst Sicherlich auch einen Spiegel erstellen, allerdings repliziert der dir dann auch direkt jeden Fehler auf den Standbyserver
.
Und Primär-DBs auf "Simple" stellen ist wohl ein ziemlich großes Risiko, dann musst bei einem Crash das letzte Backup (evtl. vom Vorabend) einspielen und hast auch den Datenstand von da, wenn du das auf "Full" stehen hast kannst nachher noch die Logs in die DB schieben und hast einen weitaus aktuelleren Stand, ich könnte hier nicht einfach ein Backup vom Vortag einspielen, alleine die Buchhaltung würde mit den Hals umdrehen wenn die alles neu buchen müsste (1-2 h gehen sicherlich aber nicht mehr).
Peformancegewinn wird gegen 0 gehen, ob der nun weitere Logs erstellt / schreibt oder das rotiert, die Menge bleibt die gleiche nur die Größe ändert sich. Das klingt eher nach einem schlechten Storage bzw. falsche Konfiguration der Platten das die nicht genug IOs mit passender Latenz liefern. Da würde ich mal einhaken, evtl. mal Performance Logs mitschneiden um zu schauen wo der Flaschenhals ist. Da dein RAM nur zu 60% belegt ist, werden die Datenbanken nicht gerade groß sein (es sei denn deine Kiste hat >128Gb RAM ...)
Just my 2 Cent
@clSchak
6,5h für 160k Datensätze? Das ist schon arg langsam... Wir nutzen auch ein CRM, sowie ECM, PDM, ERP usw. die gesamten Datenbanken sind ~ 5 Tb inkl. Logs, die Sicherung dauert ca. 4,5h mit SQL Bordmitteln, das wird dann Tagsüber via Veeam Endpoint Backup in das Veeam Repository gesichert.
Für die Verfügbarkeit der Primärdatenbanken haben wir einen SQL im Standby laufen und dann via Log-Shipping wird die transferiert. Du kannst Sicherlich auch einen Spiegel erstellen, allerdings repliziert der dir dann auch direkt jeden Fehler auf den Standbyserver
Und Primär-DBs auf "Simple" stellen ist wohl ein ziemlich großes Risiko, dann musst bei einem Crash das letzte Backup (evtl. vom Vorabend) einspielen und hast auch den Datenstand von da, wenn du das auf "Full" stehen hast kannst nachher noch die Logs in die DB schieben und hast einen weitaus aktuelleren Stand, ich könnte hier nicht einfach ein Backup vom Vortag einspielen, alleine die Buchhaltung würde mit den Hals umdrehen wenn die alles neu buchen müsste (1-2 h gehen sicherlich aber nicht mehr).
Peformancegewinn wird gegen 0 gehen, ob der nun weitere Logs erstellt / schreibt oder das rotiert, die Menge bleibt die gleiche nur die Größe ändert sich. Das klingt eher nach einem schlechten Storage bzw. falsche Konfiguration der Platten das die nicht genug IOs mit passender Latenz liefern. Da würde ich mal einhaken, evtl. mal Performance Logs mitschneiden um zu schauen wo der Flaschenhals ist. Da dein RAM nur zu 60% belegt ist, werden die Datenbanken nicht gerade groß sein (es sei denn deine Kiste hat >128Gb RAM ...)
Just my 2 Cent
@clSchak
Hallo,
6,83 Datensätze pro Sekunde. Warum so schnell?
Wenn deine Hardware nur mit 200 Kilobyte/Sek Daten wegsichern kann ist es natürlich anders als wenn diese 900 Kilobyte/Sek kann. Ebdenso ist es ein unterschied ob Dateibasierend oder sektorbasierend gesichert wird. Weiterhin stellt sich die Frage ob du zwingend diese Transaktionsprotokolle benötigst oder nicht. Welche leerlaufzeiten sind im Tagesbetrieb diese Datenbanken möglich wo dann ein konsistente datensicherung der DB's erfolgen kann? Sind Schattenkopien möglich? Warum soviel gegenfragen - nun wir kennen weder deine Umgebung noch Zeitrahmen noch zeitbedarf für die Sicherung(en) noch in welchem Umfang Transaktionsprotokolle bisher gebraucht wurden.....
Gruß,
Peter
6,83 Datensätze pro Sekunde. Warum so schnell?
Die Frage aus meiner Sicht ist, wie hoch der mögliche Performancegewinn ist
Keine. Denn was hat deine Sicherung mit den datenabgleich zu tun. Nichts. Das sind doch zwei völlig getrennte Vorgänge.wenn man das Sicherungsverfahren ändert und eben nicht jede Änderung über den Transaktionslog mitschreibt.
Da wir weder die Datenbankgößen kennen, noch die größen deiner Transaktionsprotokolle, noch welche Hardware im Spiel ist, wieviel RAM verbaut, Festplattentypen und RAID, weitere Anbindungen und auch wie deine Sicherungsmedien angebunden sind noch welcher Art deine Sicherung ist bzw. welche Software genutzt wird - wird eine Antworte eher einem Orakeln gleichkommen.Wenn deine Hardware nur mit 200 Kilobyte/Sek Daten wegsichern kann ist es natürlich anders als wenn diese 900 Kilobyte/Sek kann. Ebdenso ist es ein unterschied ob Dateibasierend oder sektorbasierend gesichert wird. Weiterhin stellt sich die Frage ob du zwingend diese Transaktionsprotokolle benötigst oder nicht. Welche leerlaufzeiten sind im Tagesbetrieb diese Datenbanken möglich wo dann ein konsistente datensicherung der DB's erfolgen kann? Sind Schattenkopien möglich? Warum soviel gegenfragen - nun wir kennen weder deine Umgebung noch Zeitrahmen noch zeitbedarf für die Sicherung(en) noch in welchem Umfang Transaktionsprotokolle bisher gebraucht wurden.....
Das Ziel ist die Zeit für den Abgleich so weit zu reduzieren
Und dazu Wissen wir nur das es eben 160000 Datensätze sind, 6,5 Stunden oder 6,83 Datensätze / Sek. Zeit benötigt. Erwartest du allen ernstes eine vernünftige Antwort? Ist als wenn du fragst ob eine Reise zum Mond möglich sei aber die komplett ausgearbeiteten Pläne für Raumschiff(e) und Flug/Flüge erwartest.dass man das auch in der Woche Abends machen könnte und eben nicht jedes Wochenende dafür drauf geht.
Musst du dabei sitzen und jeden Datensatz anfassen?Gruß,
Peter
Kontrollierst du die Daten von Hand? ôÔ
Eine nette Anekdote zum Thema "alles was länger wie 90s braucht benötigt ein Script": https://www.jitbit.com/alexblog/249-now-thats-what-i-call-a-hacker/
(jaja ist von Fefes Blog geklaut ...
)
Und den "Leitsatz" setzen wir auch immer mehr um (auch wenn wir keine Kaffeemaschine mit LAN Interface haben ...).
Eine nette Anekdote zum Thema "alles was länger wie 90s braucht benötigt ein Script": https://www.jitbit.com/alexblog/249-now-thats-what-i-call-a-hacker/
(jaja ist von Fefes Blog geklaut ...
Und den "Leitsatz" setzen wir auch immer mehr um (auch wenn wir keine Kaffeemaschine mit LAN Interface haben ...).
erm. SATA liefert die o.g. IOPS nicht, und du hast keine 4k Blöcke in deinem System, das ist augenwischerei, was für eine IO Latenz hast du denn, die ist viel wichtiger ... Mach den Test mal mit Random Access und unterschiedlichen Blockgrößen, das sind dann reelle Werte und die Latenz halt ...
Mit 4k Blöcken liefert dir meine SSD im Rechner auch IOPS >10k ohne Probleme und das als Einzeplatte, effektiv aber nicht...
Wenn Ihr SQL Tools zur Messung einsetzt, dann Stryck (http://www.stryk.info/) das liefert dir messbare und belastbare Werte.
Mit 4k Blöcken liefert dir meine SSD im Rechner auch IOPS >10k ohne Probleme und das als Einzeplatte, effektiv aber nicht...
Wenn Ihr SQL Tools zur Messung einsetzt, dann Stryck (http://www.stryk.info/) das liefert dir messbare und belastbare Werte.
Hallo,
Gruß,
Peter
Zitat von @Looser27:
Ich habe gerade mal die Leistung der Platten (2 x 500GB SATA als RAID 1) angesehen:
7200 U/min Platten? Dann sind deine IOPs auch augenwischerei. Womit sollen diesen grottenschlechten Leistungswerte bestimmt worden sein?Ich habe gerade mal die Leistung der Platten (2 x 500GB SATA als RAID 1) angesehen:
Verglichen mit
Was wurde verglichen? Wir können nicht folgen was du tust.obwohl der gleiche Durchlauf
Welcher oder was für ein testlauf? Wir wissen es nicht!Livesystem (2 x XEON mit 16 core und 48 GB) also eine lahme Krücke....
CPU Defekt? RAM kaputt? Falsches OS? Aber wenn du meinst wir müssen dir alles einzeln aus deiner Nase ziehen, dann bin ich draussen.Gruß,
Peter