Technischer Blog

Veeam hat sich ja, zumindest meiner Wahrnehmung nach, in den letzten Jahren zur bevorzugten Lösung gemausert, um die Infrastruktur zu sichern und hier auch inbesondere die SQL Server Infrastruktur. Die Vorteile liegen auf der Hand, einmal richtig konfiguriert kann hat man von zentraler Stelle einen Überblick über sämtliche Backup-Prozesse. Veeam arbeitet robust und stabil und es ist zudem noch ziemlich bequem einfach über das SQL Server TransactionLog-Backup einen beliebigen Restore Point auszuwählen und diesen Stand der Datenbank ebenso beliebig auch woanders wiederherzustellen. (Dies sollte aber unbedingt getestet werden) Falls es keine Änderungen an der Firewall, im Netzwerk oder Updates durch Veeam selbst gibt läuft es einfach! Somit spreche ich für dieses Backup-Tool eine Empfehlung aus. Aber es ist natürlich nicht alles Gold was glänzt. Der Microsoft Empfehlung für SQL Server Best Practise folgend, würde der DBA natürlich die Disken des Servers entsprechend konfigurieren. Heisst auch, daß es eine Dedicated Disk für das Backup gibt und die Disk für das OS im besten Falle nur noch OS-Dinge beinhaltet.

Was aber, wenn dies nicht jeder weiß oder eine andere Meinung zur "Schwere des Vergehens" hat, Programme auf der OS-Disk zu installieren und Dateien dort abzuzulegen. Je nachdem wie großzügig die Disk für das OS konfiguriert ist, taucht dann gerne mal eine Warnung im Monitoring auf (falls konfiguriert) wenn der Platz eng wird. Ein ungutes Gefühl kommt aber definitiv auf, wenn der Server produktiv genutzt wird und so richtig "Dampf" auf der Kiste ist. Veeam verwendet für das TransactionLog-Backup nämlich im Standard die OS-Disk. Dies ist auch nicht über Veeam konfigurierbar, sondern muss auf dem Server in der Registry explizit verändert werden. Dazu öffnet man den Registry-Editor auf dem Server und navigiert zu HKEY_LOCAL_MACHINE - SOFTWARE - Veeam - Veeam Backup and Replication und ändert den Wert von "SqlTempLogpath" auf den entsprechenden Wert der dedizierten Backup Disk. Der Support Artikel von Veeam zu diesem Thema findet sich hier (Externer Link). Mit der Änderung dieses Schlüssels in der Registry benutzt Veeam fortan die dedizierte Backup Disk. Voila!

Nach der Vorstellung des neuen Berechtigungskonzepts sind sich im Gespräch mit dem Kunden in der Regel alle Beteiligten einig, es ab jetzt anders und besser zu machen als bisher. Die Realität holt einen dann aber oft schneller ein als einem lieb ist, denn häufig scheitert es krachend an der Umsetzung bzw. dem "Leben" des neuen Berechtigungskonzept. Das mag auf der einen Seite bei dem ein-oder anderem Beteiligten, an mangelndem Verständnis der Notwendigkeit liegen, in jedem Falle spielt der Faktor Zeit eine Rolle. Es ist ja auch nur zu bequem "einfach" einen SQL-Login zu erstellen, um den Kollegen einen Zugang zum SQL Server (am besten auch noch mit SA-Rechten! ;) ) zu ermöglichen. Oder es wird aufgrund eines fehlendes Konzepts ein Active-Directory Account direkt auf der Datebank-Instanz berechtigt. In jedem Falle verliert man so in kürzester Zeit den Überblick wer eigentlich was darf und wo eigentlich. Systemsicherheit sieht anders aus!

Ein wiederkehrendes Szenario bei Auftraggebern ist, das neue Berechtigungskonzept auf neuen SQL Server Instanzen umzusetzen, und die bestehenden Instanzen zu bereinigen. Oft genug verändern sich AD-Accounts, werden gelöscht oder der Accountname ändert sich. Diese Änderung spiegelt sich jedoch nicht auf der SQL Server Instanz wieder, das heißt die Accounts bleiben dort bestehen und der Name ändert sich nicht entsprechend. Um hier wieder etwas Ordnung zu haben, empfiehlt sich ein Abgleich dieser Accounts mit dem Active Directory, anhand der SID. Für diesen Zweck habe ich die folgende Lösung hier (Externer Link) implementiert. Das SQL zur Auswertung der AD-Accounts wird auf der SQL Server Instanz ausgeführt und als CSV gespeichert. Anschliessend führt man das Powershell-Script aus, um die jeweilige SID gegen das Active-Directory zu prüfen. So wird es möglich, in einer effizienten Art und Weise die Logins einer SQL Server Datenbankinstanz zu bereinigen.

Spätestens dann wenn es um das Thema Index Maintenance geht und der Wartungsscript wiederholt mehrere Stunden läuft sollte man sich das Thema "Index Fillfactor" etwas genauer ansehen. Standardmäßig füllt SQL Server die Indexseiten zu 100%, das heisst sobald es eine Änderung gibt, kann diese nicht mehr auf diesselbe Index-Seite geschrieben werden, sondern muss am Schluss des Index angefügt werden. Dies ist maßgeblich für eine Fragementierung des Index ursächlich und erzeugt Overhead, weil die SQL Server Engine die nötige Information von verschiedenen Stellen des Index lesen muss. Mit setzen des Fillfactors wird standardmäßig Platz auf jeder Indexseite freigehalten, sodass Änderungen, und damit Änderungen am Index direkt auf der jeweiligen Indexseite fortgeschrieben werden können. Dies beugt einer wiederholten zeitnahen Fragementierung vor. Mit dem setzen eines Fillfactors von z.B. 90%, bleiben 10% jeder Indexseite frei für das fortschreiben von Veränderungen. Doch vorsichtig, diese Änderung hat unmittelbare Auswirkung auf die Performance eines Index, da so Index-Informationen auf mehrere Seiten aufgeteilt und nicht mehr im ganzen gelesen werden. Brent schreibt hier (Externer Link), das ein setzen des Fillfactors von 10% eine Verschlechterung der Index-Performance von 10% zur Folge hat.

Daher ist es eine Abwägung wie sich ein fragmentierter Index oder ein niedrigerer Fillfactor auf die Index-Performance auswirken wird. Nicht akzeptabel ist jedoch auch in meinen Augen wenn das Thema Index Maintenance unübersichtlich wird. Und wenn man nie weiß was zu erwarten ist, sozusagen eine Black-Box. Eine Ausführungszeit von 25-40 Stunden pro Woche ist eine Hausnummer und wirkt sich unmittelbar auf das Produktivsystem und die Leistung aus. Um herauszufinden welcher Indizes für eine lange Laufzeit verantwortlich sind, sollte man die Ausführungszeit der Index Pflege überwachen. Die SQL Server Maintenance Solution von Ola Hallengren (Externer Link), https://ola.hallengren.com, protokolliert standardmäßig die Ausführungszeit in der Tabelle Commandlog. Um sich einen Überblick zu verschaffen werten wir diese Tabelle mit einem definierten Zeitraum aus. Ziel ist es durch das setzen des Fill-Factors eine schnelle Fragmentierung des Index zu vermeiden. Ein Beispiel Kommando um den Fillfactor zu setzen ist: Example: ALTER INDEX [IndexName] ON [dbo].[Tabelle] REBUILD WITH (FILLFACTOR = 90, SORT_IN_TEMPDB = OFF, ONLINE = OFF) Diese Abfrage hier (Externer Link) prüft dynamisch den Fillfactor und erzeugt die jeweiligen Kommandos um den Fillfactor für einen Index neu zu setzen.