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

Please also mark the comments that contributed to the solution of the article

Content-Key: 289306

Url: https://administrator.de/contentid/289306

Printed on: April 20, 2024 at 03:04 o'clock

9 Comments

Latest comment

Hallo,

Zitat von @Looser27:
um das Ganze zu beschleunigen?

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

Der Datenabgleich läuft derzeit ca. 6,5h. Das heißt, dass ich das immer nur am Wochenende machen kann. Der Abgleich beinhaltet derzeit ca. 160.000 Datensätze, welche mit der CRM-DB abgeglichen werden müssen. Die Frage aus meiner Sicht ist, wie hoch der mögliche Performancegewinn ist, wenn man das Sicherungsverfahren ändert und eben nicht jede Änderung über den Transaktionslog mitschreibt.

Das Ziel ist die Zeit für den Abgleich so weit zu reduzieren, dass man das auch in der Woche Abends machen könnte und eben nicht jedes Wochenende dafür drauf geht.

Gruß

Looser

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

Hallo,

Zitat von @Looser27:
Der Datenabgleich läuft derzeit ca. 6,5h. Das heißt

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

Der Server hat 48GB RAM mit nem Windows 2008R2 Enterprise.

Bzgl. der Zeit hast Du glaube ich was falsch verstanden. Es geht um den Abgleich mit der DB. Aber dem Hinweis mit den Platten werde ich mal nachgehen.

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

Natürlich nicht

Dafür haben wir ein Tool, welches die Daten mit der DB abgleicht und bei Bedarf updated.
Ich habe gerade mal die Leistung der Platten (2 x 500GB SATA als RAID 1) angesehen:

Random Read 4KiB (Q= 32,T= 1) : 22.111 MB/s [ 5398.2 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 3.367 MB/s [ 822.0 IOPS]

Random Read 4KiB (Q= 1,T= 1) : 5.982 MB/s [ 1460.4 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 3.334 MB/s [ 814.0 IOPS]

Verglichen mit meinem Testsystem ist das schon deutlich mehr.....obwohl der gleiche Durchlauf auf eben diesem Testsystem nur ca. 90min (!) benötigt.
Das hat mich stutzig werden lassen, denn das Testsystem ist ein alter PC mit Celeron ohne RAID und 2GB (!) RAM. Verglichen mit dem Livesystem (2 x XEON mit 16 core und 48 GB) also eine lahme Krücke....

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.