Technischer Blog

Eine interessanter Auftrag für eine Implementation, was die Notwendigkeit, zumindest Ansatzweise die Logins einer SQL Server Instanz zu pflegen und aktuell zu halten. Grundsätzlich empfehle ich dem Kunden einen Best Practice-Orientierten Ansatz anhand von AD-Gruppen zur Verwaltung der Zugäe für einen SQL Datenbankserver. Dies verlagert die Verwaltung ins Active Directory und bietet gleichzeitig einen Überblick, wer wo was auf der Datenbankserver Instanz machen darf.

Im Gegensatz zur Bad Practice, die die Administration erschwert und in der Regel das darstellt, was mit "Chaos" am besten umschrieben ist. Eine Umstellung dessen erfordert einen erheblichen Arbeitsaufwand, als wenn man am besten direkt von Anfang an der Best Practice folgt. Im Hinblick auf die Server Lifetime ist es dann eine Abwägung, ob man die Maßnahme umsetzt. WEITERLESEN Automatisierte Überwachung von AD Account Login Mappings

Die Überwachung des erfolgreichen Transactionlog-Backups ist ein wichtiger Aspekt für die Verfügbarkeit und Sicherheit eines Datenbank Systems. Im Falle das die Backups über einen lokalen SQL Server Agent Job, bzw. über einen Maintenance Plan erfolgen, kann man dort auch direkt eine Überwachung für den Fehlerfall integrieren. Wie sieht es aber für den Fall aus, wenn das Backup über externe Software, wie z.B. Veeam, erfolgt? Dort kann man ebenso eine Überwachung, in Form einer Benachrichtigungsemail konfigurieren.

Gerade bei Veeam ist es aber so, das ich für eine Benachrichtigung nicht zwischen den einzelnen Backup-Jobs differenzieren kann. D.h. man kann nur eine bzw. mehrere Emailempfänger zentral konfigurieren an die sämtliche Ergebnisse versendet werden. Dies kann bei entsprechende Beachtung auch durchaus ausreichend sein. Um eine Benachrichtigung über alle Kanäle zu erhalten, ist es aber notwendig, zusätzliche Maßnahmen zu ergreifen.. WEITERLESEN Maßnahmen zur Überwachung des TransactionLog-Backup

Die Anzahl der Verbindungen die eine SQL Server Instanz verwalten kann ist abhängig von der Konfiguration der Instanz. In jedem Falle gibt es eine endliche Obergrenze und eine Erschöpfung der möglichen Verbindungen aus dem Verbindungspool wird eintreten was zu Performanceproblemen oder sogar Verbindungsverweigerungen führen kann. Häufig ist die Ursache ein fehlerhaftes Verbindungsmanagement. Eine Verbindung zum SQL Server wird geöffnet und nicht mehr geschlossen. Im Idealfall wird dieselbe Verbindung immer wieder verwendet und am Ende einer "Session"

als "kann geschlossen werden" markiert (Wenn man z.b. das managen der Connections dem .NET Framework überlässt). Weitere Ursachen können Transaktionen darstellen, die nicht explizit abgeschlossen werden mittels eines "Commit" oder "Rollbacks" oder etwa das im Falle einer Ausnahme (Exception) die Verbindung offen bleibt und verwaist. Hier fallen ebenso asynchrone Operationen mit rein. Oder aber ein Entwickler "debugged" mittels Breakpoints und beendet das ganze, wobei die Connection weiterhin bestehen bleibt. WEITERLESEN Connection Leak Ursachen und Vermeidung

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. WEITERLESEN Ändern des SQL Server Transactionlog Backup Verzeichnisses für Veeam

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. WEITERLESEN Active Directory Logins auf SQL Server Instanzen pflegen? Gute Vorsätze, schlechte Praxis

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. WEITERLESEN Warum und Wieso und Wie? Gedanken zum SQL Server Index Fillfactor