Loading . . .
SQL Server Backup – Performance Probleme durchs Backup ???

SQL Server Backup – Performance Probleme durchs Backup ???

Ich habe einen SQL Server 2008 R2 in der Betreuung auf dem es immer wieder zu Engpässen oder besser gesagt “Performance-Löchern” kommt, diese galt es zu finden und zu beheben. Dass das SQL Server Backup hierbei eine gewichtige Rolle spielt, habe ich zu diesem Zeitpunkt noch nicht gewußt… aber der Reihe nach.

Bei dem SQL Server handelt es sich um eine virtuelle Maschine mit 4 vCPUs und 32 GB RAM (aber 3 SQL Server Instanzen), das Betriebssystem ist ein Windows Server 2008 R2, der SQL Server 2008 R2 (10.50.6259) Standard Edition. Da wir den SQL Server damals nicht selber aufgesetzt haben, sondern aus der Betreuung anderer übernommen haben, mussten wir teilweise bei den Grundlagen der Best-Practices anfangen und konnte so mit der Umsetzung einer Vielzahl von Empfehlungen für einen stabilen und performanten Betrieb umgesetzen.

  • Max Memory angepasst
  • maxDOP und Threshold optimiert
  • lokale Sicherheits-Richtlinien angepasst
  • Backup Compression aktiviert
  • Network Packet Size erhöht
  • Optimize for ad hoc Workloads aktiviert

Aktuell sind wir dabei, die Datenbank-Files (welche bereits getrennt waren) auf neue (bessere) Platten zu verteilen, wobei wir auch auf die Blocksize bei der Formatierung geachtet haben. Bisher waren alle Platten mit dem “Default” von einer 4k-Blocksize formatiert… nun haben wir dies für die Datenplatten auf 64k Blocksize geändert.

Vorarbeiten / Umsetzung der Best-Practices

Der Kunde ist schon zufriedener mit der Performance, wobei man sicherlich bei der Datenbank-Struktur, den Indexen und/oder den Abfragen noch eine ganze Menge Performance herausholen kann. Aber diese liegen nicht in unserer Verantwortung, so dass wir nur analysieren und Empfehlungen aussprechen können.

Vor einigen Tagen habe ich eine Video von Brent Ozar (ich glaube es kam von ihm) gesehen, in diesem Video ging es in der Hauptsache um Storage unter anderem darum, wie moderne Storage-Systeme Daten intern verteilen und welchen Einfluß dieser Algorithmus auf die Performance des SQL Servers haben kann. Unter anderem auch auf die SQL Server Backup Performance. High Level IO kommt auf Highspeed Discs und weniger wichtige Daten werden auf langsamer drehende Platten “ausgelagert”…

Was aber tun, wenn alle Daten dieser Vielzahl von Datenbanken mindestens einmal am Tag “angefasst” werden… dann ist das Storage-System der Meinung alle Daten sind wichtig und werden ständig gebraucht… also müssen alle Daten auf Highspeed-Platten… aber nicht alle Daten passen vielleicht in eben diesen Bereich, also müssen einige Daten des SQL Servers doch wieder “ausgelagert” werden. In meinem Fall hatten wir (auf Kundenwunsch und von uns vielleicht ein wenig blauäugig) einen House-Keeping Job eingerichtet, der einmal täglich alle (!) Datenbanken bzw deren Indexe reorganisert hat.

Dieser tägliche Rebuild/Reorg führte nicht nur dazu, dass das Storage-System ständig seinen Algorithmus für die Datenverteilung anpassen musste, sondern auch das Backup alle diese “geänderten” Daten erneut und wiederholt sichern musste. Wie ich bereits anfangs erwähnt habe, handelt es sich bei etwa 2/3 der Datenbanken um Audit- und Archiv-Datenbanken, müssen diese tatsächlich täglich reorganisiert und somit gesichert werden?

Nun werden nur noch alle relevanten Datenbanken täglich reorgansiert, das zuständige Wartungsskript haben wir auch gegen die Maintenance-Solution von Ola Hallengren ausgetauscht, diese Skript ist wesentlich ausgereifter und intelligenter als unsere alte Lösung.

Jetzt sind wir an einem Punkt (den wir in diesem Fall als DBAs direkt beeinflussen können), an dem man eigentlich nichts mehr zusätzlich ändern kann… durch das Video stolperte ich auch noch über weitere Beiträge von Brent Ozar zum Thema Backup, die mich erneut zum Nachdenken bzw Überdenken der Situation brachten.

Optimierung und Anpassung der SQL Agent Jobs

Also habe ich mir den SQL Server nochmals angeschaut, wann welche Belastung auftritt und welche SQL Agent Jobs zu welchem Zeitpunkt laufen. Dabei fiel mir auf, dass der SQL Server den ganzen Tag über ständig irgendwelche Backups (hier TransactionLog-Backups) macht.

Visualize the timeline of your SQL jobs using Google graph and email
Visualize the timeline of your SQL jobs using Google graph and email
http://www.sqlservercentral.com/articles/Jobs/127346/

Ok, gegen die Häufigkeit kann ich in diesem Fall nichts tun, da wir vertraglich zugesichert haben eine “Maximale Datenverlust Zeit” von 20 Minuten zu garantieren. (siehe hierzu auch meinen Beitrag über SQL Server Backup Grundlagen). Aber warum dauern diese Backups so lange, so groß können die verarbeiteten Datenmengen (auf diesem SQL Server) nicht sein…

Nach einem Studium der Beiträge von Brent Ozar zum Thema MSDB und was passiert mit der Backup-Performance, wenn man die Daten der Backup-Historie in der msdb nicht regelmäßig löscht, konnte ich zumindest für mich festhalten… “daran lag es zum Glück nicht!”. Ein anderes Skript von Brent für mich dann auf eine heiße Spur…

Wir sichern diesen Server (und die meisten der won uns betreuten SQL Server) mittels Online Backup mittels Legato Networker (Module for Applications oder den SQL Client) direkt auf einem Backup-Server. Die Anbindung an diesen Backup Server erfolgt auf jedem Server mit einer zusätzlichen Netzwerkkarte, welche eine Verbindung ins dedizierte Backup-LAN hat. Diese Netzwerkkarte hat in der Regel (zumindest bei diesem Server) eine angegebene Geschwindigkeit von 10GBit. Also sollte doch zumindest die Anbindung schnell genug sein…

Eine genauere Analyse der vorhandenen Daten aus der msdb-Datenbank und einem sehr nützlichen Skript zur Ermittlung der SQL Server Backup Leistung zeigte dann doch erstaunliche Werte.

miserabler SQL Server Backup Durchsatz trotz guter Netzwerk-Anbindung

Durch diese neue Erkenntnis kann/muss ich nun, in Zusammenarbeit mit den Netzwerk- und Backup-Kollegen, eine Analyse dieser schlechten Backup-Performance erstellen. Liegt es am Netzwerk Richtung Backup Server oder am Backup Server selber oder am eigentlichen Backup, dass hier in der Parametrisierung etwas optimiert werden kann.

Ich werde euch auf dem Laufenden halten, wie das Thema weiter geht und ob ich den SQL Server entlasten konnte.

weitere Links und Quellen zur obigen Analyse von SQL Server Backup Problemen:

SQL Sysadmin : Clear Backup History (nibble delete)
http://sqlsolace.blogspot.com/2007/05/sql-sysadmin-clear-backup-history.html

Brent’s Backup Bottleneck: MSDB
http://www.brentozar.com/archive/2009/05/brents-backup-bottleneck-msdb/

Blitz Result: MSDB History Not Purged
http://www.brentozar.com/blitz/msdb-history-not-purged/

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

SQL PASS - Die Community rund den SQL Server - Logo Previous post SQL PASS – RGV Hannover – Treffen Februar 2016
TSQL - Getting SQL Server Informations Next post TSQL – wichtige Informationen über die SQL Server Instanz ermitteln

SQL aus Hamburg

Das bin ich ;-)

Björn Peters - MVP - Data Platform

Ich habe das erste Mal mit MS SQL Datenbanken im Jahr 2000 zu tun gehabt und diese Datenbank-Systeme rund 7 Jahre vollumfänglich betreut. Von 2007 bis 2019 war ich als Datenbank-Administrator angestellt und betreute eine Vielzahl von unterschiedlichen SQL-Servern von mittelständischen Firmen und Großkonzernen aus unterschiedlichen Branchen.
Ich verfüge zwar über einige Zertifikate, beziehe meine Erkenntnisse und mein Wissen rund um den SQL Server rein aus dem Tagesgeschäft, dem Lesen/Verfolgen von zahlreichen Foren/Blogs.
Ich habe mich auch nicht wirklich auf ein Fachgebiet spezialisiert, lege meinen Schwerpunkt aber dann doch auf die Performance-Analyse.
Seit Ende 2016 bin ich Organisator des Azure Meetup Hamburg und vom April 2017 bis Juni 2018 Cloud- und Datacenter Management MVP und seit Juli 2018 Data-Platform MVP.