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.
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.
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/
Björn arbeitet auch weiterhin aus Mexiko als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.
