COMPAREX AG
SQL Server: Was tun, wenn die Applikation nicht mehr funktioniert? (Header)

SQL Server: Was tun, wenn die Applikation nicht mehr funktioniert?

Die Arbeit mit SQL Server birgt einige Fehler, die sich jedoch mit entsprechendem Wissen vermeiden lassen. Dieser Blogbeitrag thematisiert schwerwiegende Probleme der Art „Meine Applikation funktioniert nicht mehr“. Wir analysieren die gängigsten Fälle und geben Lösungsanregungen, wie man sie umgehen oder begrenzen kann.

Ein Blogbeitrag von Frank Sander, SQL Server Consultant

Während der Blogbeitrag „SQL Server: Lösungen für die 5 häufigsten Performance-Probleme“ Fälle der Art „Meine Applikation läuft langsam.“ behandelte, liegt der Schwerpunkt dieses Blogs eher auf Problemen der Art „Meine Applikation funktioniert nicht mehr.“ Gern wiederhole ich auch an dieser Stelle, dass ich keinen Datenbank-Administrator an den Pranger stellen möchte, sondern vielmehr Verständnis für jene zeigen möchte, die neben Datenbanken noch eine Handvoll andere komplexe Themengebiete administrieren (müssen).

Die 5 häufigsten Probleme hinsichtlich "Meine Applikation funktioniert nicht"

  • Problem 1: Eine iubezüglich Ausfallzeit kritische Datenbank ist inkonsistent.
  • Problem 2: Eine bezüglich Datenverlust kritische Datenbank ist seit mindestens drei Tagen inkonsistent.
  • Problem 3: Die Festplattenpartition für Transaktionsprotokolle muss ständig erweitert werden.
  • Problem 4: Bei der Verwendung von AlwaysOn Verfügbarkeitsgruppen können sich nach erfolgtem Failover einzelne Logins nicht anmelden.
  • Problem 5: Während der Installation einer weiteren Instanz von SQL Server innerhalb einer hochproduktiven Betriebssystem-Umgebung sind die schon vorhandenen Instanzen nicht erreichbar.

 

Problem 1

Eine bezüglich Ausfallzeit kritische Datenbank ist inkonsistent.

Analyse

Der täglich ausgeführte Wartungsplan für Backup und Datenbank-Konsistenzprüfung meldete für letzteren Teil einen Fehler während der Ausführung. Die entsprechende Datenbank wurde in einer Produktionsstrecke aktiv genutzt. Eine sonst übliche Wiederherstellung der letzten konsistenten Vollsicherung in Verbindung mit allen relevanten Transaktionsprotokoll-Sicherungen sollte daher aus Zeitgründen vermieden werden.

Lösung

Im ersten Schritt wurde die Tabelle, welche die inkonsistenten Daten enthält, ermittelt. Anhand älterer Backups konnten ihre Inhalte in einer Testumgebung wiederhergestellt werden. Anschließend wurde die gleiche Tabelle in der Produktivumgebung geleert und mit den in der Testumgebung erstellten Datensätzen befüllt.

Fazit

Ein Wartungsplan zur Überprüfung von Datenbank-Inkonsistenzen ist zwingend notwendig. Bei entsprechender Kontrolle des Ergebnisses und zeitnaher Reaktion kann ein Datenverlust auf verschiedene Arten verhindert werden. Außerdem sollten – unabhängig von Inkonsistenzen –  Datenbanken, für die eine hohe Verfügbarkeit gewährleistet sein muss, dementsprechend innerhalb einer Hochverfügbarkeitslösung betrieben werden. SQL Server bietet mit AlwaysOn Failover Cluster und seit Version 2012 mit AlwaysOn Verfügbarkeitsgruppen zwei entsprechende Möglichkeiten. Welche der beiden Hochverfügbarkeitslösungen eingesetzt wird, ist dabei abhängig von den konkreten Anforderungen.

 

Problem 2

Eine bezüglich Datenverlust kritische Datenbank ist seit mindestens drei Tagen inkonsistent.

Analyse

Microsoft empfiehlt bei inkonsistenten Datenbanken die Wiederherstellung aus der letzten konsistenten Vollsicherung, ggf. unter Verwendung weiterer differentieller Sicherungen und/oder Transaktionsprotokollsicherungen. Da sich die Datenbank nur im einfachen Wiederherstellungsmodell befand, wäre eine solche Wiederherstellung mit dem Verlust der Daten von mindestens drei Tagen verbunden gewesen. Eine von Datenverlust freie Reparatur der Datenbank mittels

SQL Server: Was tun, wenn die Applikation nicht mehr funktioniert? (Codeschnipsel 1)

war aufgrund der Fehlermeldung der Datenbankkonsistenzprüfung nicht möglich.

Lösung

Die verlustärmste Lösung bestand daher in der Reparatur der Datenbank unter Verwendung von

SQL Server: Was tun, wenn die Applikation nicht mehr funktioniert? (Codeschnipsel 2)

und anschließender Sicherstellung der referentiellen Integrität.

Fazit

Wie auch im ersten Beispiel wird deutlich, dass Datenbanken zwingend regelmäßig, am besten in Verbindung mit vollständigen Sicherungen, auf Konsistenz zu prüfen sind. Im Falle einer Fehlermeldung muss gerade bei der Verwendung des einfachen Wiederherstellungsmodells schnellstmöglich gehandelt werden. Andernfalls droht ein immer größer werdender Datenverlust. Außerdem muss geklärt werden, wieviel Datenverlust überhaupt tolerierbar ist. Wiederherstellungsmodell und Sicherungskonzept müssen dementsprechend angepasst werden.

 

Problem 3

Die Festplattenpartition für Transaktionsprotokolle muss ständig erweitert werden.

Analyse

Das Transaktionsprotokoll wird immer größer. Ein Wartungsplan für die Durchführung von Transaktionsprotokoll-Sicherungen und ein entsprechender Auftrag des SQL Server Agents wurden zwar eingerichtet, der Auftrag brach jedoch immer mit Fehlermeldung ab. Die Durchführung des Auftrags wurde nicht überwacht.

Lösung

Der Wartungsplan wurde korrigiert. Nach erfolgter Sicherung des Transaktionsprotokolls konnte das Transaktionsprotokoll verkleinert werden. An dieser Stelle eine Anmerkung: Die Verkleinerung des Transaktionsprotokolls ist unproblematisch, die Verkleinerung der Datendatei ist hingegen in der Regel performancekritisch. Sie sollte niemals regelmäßig in Wartungsplänen durchgeführt werden.

Fazit

Kritisch an diesem Beispiel ist vor allem das „Was wäre, wenn die Transaktionsprotokollsicherung benötigt werden würde?“. Wartungspläne beziehungsweise deren Ausführungen als Auftrag des SQL Server Agents müssen zwingend überwacht werden. Dazu bietet SQL Server z.B. den Versand einer E-Mail im Fehlerfall an. Außerdem muss der Status des SQL Server Agent Dienstes überwacht werden. Denn ist dieser deaktiviert, werden weder Aufträge ausgeführt noch E-Mails versandt.

 

Problem 4

Bei der Verwendung von AlwaysOn Verfügbarkeitsgruppen können sich nach erfolgtem Failover einzelne Logins nicht anmelden.

Analyse

Logins verfügen über eine SID. Außerdem ist ihnen auf einer oder mehreren Datenbank(en) jeweils ein Datenbank-Nutzer zugeordnet. Um dies abzubilden, wird beim Datenbank-Nutzer die SID des Logins hinterlegt (=Benutzerzuordnung). Für eine erfolgreiche Anmeldung benötigt man die Angabe eines Logins sowie einer Datenbank, die über einen wie soeben beschriebenen Datenbank-Benutzer verfügt. In der unteren Abbildung ist dies für Instanz1 der Fall.

Angenommen für die Datenbank DB1 auf Instanz1 wird eine Verfügbarkeitsgruppe eingerichtet, Instanz2 soll ein sekundäres Replikat von DB1 verwalten. Dann müssen alle Logins mit Berechtigungen auf DB1 auf Instanz2 ebenfalls angelegt werden, da deren Informationen nicht in der Nutzer-Datenbank, sondern in der master-Datenbank gespeichert sind. Geschieht dies über die GUI wird für alle passwortgeschützten SQL Logins automatisch eine SID generiert, die i.d.R. von der ursprünglichen abweicht. Für den in der Datenbank enthaltenen Nutzer John.Doe wird allerdings die ursprüngliche SID im Rahmen der Datenbankspiegelung übertragen. Solange Instanz1 das primäre Replikat verwaltet und der Zugriff auf DB1 nur über sie erfolgt, ist dies unproblematisch. Fällt jedoch Instanz1 geplant (z.B. wegen Update) oder ungeplant aus und die sich auf Instanz2 befindende Datenbank DB1 wird primäres Replikat, kann sich John.Doe mangels gültiger Zuordnung nicht anmelden.

SQL Server: Was tun, wenn die Applikation nicht mehr funktioniert? (Grafik Instanz1 und Instanz2)

Bei Windows-Anmeldungen wird im Übrigen die SID des Logins aus dem AD bezogen. Wird ein Windows Login auf einer ein sekundäres Replikat verwaltenden Instanz angelegt, hat dieser also die gleiche SID wie der Login der das primäre Replikat haltenden Instanz, kann das oben geschilderte Problem dementsprechend nicht auftreten.

Lösung

Die Erstellung der SQL Logins auf den sekundären Replikaten muss unter Angabe der SID des Logins des primären Replikats geschehen. Nach einem Failover reicht die Anpassung der Benutzerzuordnung der vor allem bei Migrationen gängigen Art

SQL Server: Was tun, wenn die Applikation nicht mehr funktioniert? (Codeschnipsel 3)

nicht aus. Für den Moment würde die Anmeldung auf Instanz2 zwar funktionieren, da die beim Datenbank-Nutzer John.Doe gespeicherte Login-SID auf 987654 geändert werden würde. Diese Änderung würde aber auch mittels Spiegelung auf Instanz1 übertragen werden, man stünde bei einem Failover auf Instanz1 somit wieder vor dem gleichen Problem.

 

Problem 5

Während der Installation einer weiteren Instanz von SQL Server innerhalb einer hochproduktiven Betriebssystem-Umgebung sind die schon vorhandenen Instanzen nicht erreichbar.

Analyse

Schon vorhanden waren je zwei Instanzen SQL Server 2012 bzw. 2014, installiert wurde SQL Server 2012. Diese Installation überschrieb einige .dll’s des SQL Server Browsers, was wiederum das Stoppen des Dienstes zur Folge hatte.

Lösung

Eine Reparaturinstallation mittels des Installationsmediums von SQL Server 2014 beseitigte die aufgetretenen Probleme zuverlässig.

Fazit

Gerade in Produktivsystemen empfehle ich von der Verwendung mehrerer Versionen von  SQL Server innerhalb einer Betriebssystem-Umgebung abzusehen. Auf keinen Fall sollten erst jüngere und anschließend ältere Versionen von SQL Server in eine Betriebssystem-Umgebung installiert werden. Werden schon ein oder mehrere Instanzen in der entsprechenden Betriebssystem-Umgebung betrieben, sollte die Installation innerhalb eines Wartungsfensters für diese Instanzen und natürlich nach der Erstellung von Datenbanksicherungen geschehen.

Zusammenfassung

Ich hoffe ich konnte mit diesem Blogbeitrag vor allem die Notwendigkeit von Datenbank-Konsistenzprüfungen herausstellen. Führen Sie diese mit jeder Vollsicherung durch, überprüfen Sie das Ausführungsergebnis Ihrer Aufträge sowie den Status der SQL Server Dienste und verwenden Sie Prüfsummen für die Seitenüberprüfung innerhalb Ihrer Datenbanken.

SQL 2016 Workshop Reihe – Next Generation

Erfahren Sie, was der SQL Server 2016 kann, was er nicht kann, wann sich eine Migration lohnt und wie die Lizenzierung funktioniert.

Die eintägigen Workshops finden in sechs Orten in Deutschland statt und sind für Sie kostenfrei. Empfohlen für IT-Administratoren und IT-Entscheider.

Ich möchte mich anmelden »

Diesen Artikel teilen

Artikel vom:
01.06.2017

geschrieben von:

TAGS:
SQL Server

Thema:

Kommentieren sie diesen Artikel...

© COMPAREX AG
Zurück nach oben