SQL – Fragen und AntwortenClustering, mysteriöse Abstürze, das SA-Konto und mehr

Herausgegeben von Nancy Michell

F: Ich möchte mehr darüber erfahren, wie Clustering funktioniert. Unsere Umgebung besteht aus der 64-Bit-Edition von Windows Server® 2003, auf der SQL Server™ 2005 ausgeführt wird, sowie aus einer SSRS-Webfarm (SQL Server Reporting Services) (eine Skalierungsbereitstellung des Berichtsservers), einem SSRS TempDB-Katalogserver und SQL Server, der Daten aus einer Drittanbieterdatenbank über einen verknüpften Server weiterleitet und die Daten für SSRS speichert.

Es soll ein 3-Knoten-Cluster (aktiv/aktiv/passiv) implementiert werden. Knoten 1 ist soll aktiv sein und die Daten speichern, die aus der Drittanbieterdatenbank weitergeleitet werden. Knoten 2 soll aktiv sein und den SSRS-Katalog speichern. Knoten 3 soll passiv sein und als Failover für Knoten 1 oder 2 dienen. Können Sie weiterhelfen?

A: Leider werden viele Benutzer von den Begriffen „aktiv/aktiv“ und „aktiv/passiv“ in Bezug auf das SQL Server-Clustering irregeführt. Sie sind der Meinung, dass SQL-Clustering das „Ausskalieren“ einer Datenbank oder SQL-Instanz über mehrere Server unterstützen kann. Dies ist nicht der Fall. Bei SQL Server gibt es keine aktiv/aktiv-Datenbank oder Instanz. Eine „Instanz“ ist eine Installation von SQL Server mit entsprechenden Datenbanken. Das Clustering pro SQL Server-Instanz ist immer aktiv (1) nach passiv (n) (der Wert n liegt abhängig von Ihrer SQL Server-Version zwischen 1 und 7). Deswegen heißt es Failoverclustering.

Wenn dies klar ist, kann die Installation mehrerer Instanzen von Failoverclustering auf mehreren Knoten in Betracht gezogen werden. Drei physische Server beispielsweise, die alle freigegebene Datenträger verwenden, könnten eine standardmäßig aktive Instanz auf Knoten 1 und eine zweite standardmäßig aktive Instanz auf Knoten 2 haben, und bei beiden kann ein Failover zu Knoten 3 stattfinden. Die Instanzen sind völlig getrennt. Sie geben keine Daten frei und sind nicht aktiv/aktiv. Beide sind aktiv/passiv und haben dieselbe Failoverinstanz. Wenn bei beiden Knoten ein Failover zu Knoten 3 stattfindet, besteht die Herausforderung darin, abzuschätzen, ob diese Last mit der Zeit zu viel für Knoten 3 sein wird. Vom Entwurf her soll beim Failover eine gleichwertige Verarbeitungsleistung zur Verfügung stehen. Wenn bei Spitzenbeanspruchung zwei Knoten für die Verarbeitung im Normalbetrieb erforderlich sind, ist es unwahrscheinlich, dass Knoten 3 die Spitzenbeanspruchung überstehen würde, die normalerweise zwei Knoten zugewiesen ist.

Aufgrund der relativen Kosten der zum Ausführen eines Clusters fähigen Hardware ist es natürlich verständlich, dass die Wahrscheinlichkeit des gleichzeitigen Versagens beider Hauptknoten und Übertragen der Gesamtlast auf einen Knoten von einem Unternehmen abgewogen wird. Daher treffen Unternehmen oft die Entscheidung, das Risiko einzugehen, statt 100 Prozent Failoverkapazität zu gewährleisten.

Glücklicherweise gibt es ein paar guten Nachrichten: SQL Server 2005 bietet viele weitere Optionen für hohe Verfügbarkeit (High Availability, HA) einschließlich Alternativen, bei denen ein Failover schneller stattfindet als bei einem Cluster und sogar Duplikate von Daten möglich sind (beim Clustering wird ein einzelnes SAN eingesetzt). Die Optionen umfassen Spiegelung, Peer-to-Peer-Replikation und mehr. Mit diesen neuen Alternativen stehen erheblich mehr Optionen zur Verfügung, um unterschiedliche Anforderungen zu erfüllen, so auch einige, bei denen eine Reihe von HA-Features kombiniert werden.

Der Microsoft® Cluster Configuration Validation Wizard (ClusPrep), der jetzt als Download zur Verfügung steht, ersetzt die HCL-Tests (Hardware Certification List, Hardwarezertifizierungsliste), die bisweilen Monate zum Überprüfen einer Konfiguration brauchten, um sie für das Clustering als „supportfähig“ einzustufen. Dies stellt dem Datenbankadministrator ein Tool zur Hardwareüberprüfung zur Verfügung, sodass der Kosten- und Zeitaufwand bei der Installation zertifizierter Hardware weiter reduziert wird. Hierdurch wird u. U. sogar die Überprüfung und Bereitstellung heterogener Hardware innerhalb eines Clusterknotensatzes ermöglicht.

F: Ein Löschverfahren auf einem meiner Computer scheint nach 12 Stunden nicht mehr zu reagieren. Es ist nicht blockiert. Im langsamsten Abfrageplan wird ein Auslöser angezeigt, der für 87.327 Sekunden ausgeführt wird. Daher nehme ich an, dass das Verfahren in diesem Auslöser zum Stillstand kommt. Wie kann ich genau feststellen, welche Anweisung nicht reagiert?

A: Es ist durchaus möglich, dass eine Schleife innerhalb des Auslösers aus verschiedenen Gründen nicht beendet wird. Wenn längere Zeit keine Reaktion erfolgt und Sie sehen wollen, welche Anweisung ausgeführt wird, führen Sie den Code in Abbildung 1 aus. Sie erfahren, welche Anweisung derzeit ausgeführt wird. Dies dürfte die Anweisung sein, die dazu führt, dass Ihr Computer nicht reagiert.

Figure 1 Suche nach der derzeit ausgeführten Anweisung

-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20), 
        @start int, 
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle, 
        @start = stmt_start, 
        @end = stmt_end 
FROM Master..sysProcesses(NOLOCK) 
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

F: Ich muss die Transaktionsreplikation über eine Firewall unterstützen. Der Herausgeber und der Verteiler befinden sich außerhalb und der Abonnent innerhalb der Firewall. Der Abonnent ist zum Abhören von Port 1433 eingestellt. Die Computernamen lauten wie folgt: Herausgeber: PUBMACHINE, Verteiler: DISTMACHINE, Abonnent: SUBMACHINE. Welche Ports muss ich öffnen, damit der ursprüngliche Snapshot und der Veröffentlichungspush erfolgreich sind?

A: Wenn Sie ein Pushabonnement verwenden, sollte das Öffnen des SQL Server-Ports (in Ihrem Fall 1433) ausreichen, da der Verteilungsagent auf dem Verteilercomputer (außerhalb der Firewall) ausgeführt wird und wahrscheinlich lokalen Zugriff auf die Snapshotdateien hat, die vom Snapshotagent generiert werden. Wenn Sie dagegen ein Pullabonnement verwenden, muss der Verteilungsagent, der auf dem Abonnentencomputer ausgeführt wird, irgendwie über die Firewall auf die Snapshotdateien zugreifen. Sie können folgende Optionen in Betracht ziehen.

Angenommen die Snapshotdateien sind bereits von einer Dateifreigabe außerhalb der Firewall zugänglich. In diesem Fall können Sie die Windows®-Dateifreigabeports über die Firewall öffnen, sodass der innerhalb der Firewall ausgeführte Verteilungsagent auf die Snapshotdateien zugreifen kann, die sich außerhalb befinden. (Sie sollten jedoch die Sicherheitsimplikationen bedenken, die dies für andere Teile Ihrer Infrastruktur haben könnte.) Beachten Sie, dass Sie bei Konfiguration eines lokalen Pfads als Standard-Snapshotspeicherort (SSMS-Standard) möglicherweise die Option „/AltSnapshotFolder“ des Verteilungsagents verwenden müssen, um den PICKUP-Pfad für die Snapshotdatei zu überschreiben.

Sie können außerdem die Replikation konfigurieren, um FTP für das Übertragen von Snapshotdateien zu verwenden. (Dafür müssten Sie Port 21 öffnen.)

F: Ich möchte wissen, ob es Nachteile gibt, wenn das SA-Konto in SQL Server 2005 deaktiviert wird, und ob die SA-Deaktivierung die Sicherheit wirklich erhöht. Gibt es ein Whitepaper zu dieser Frage?

A: Bei einer neuen SQL Server 2005-Installation ist das SA-Konto bei nicht aktiviertem gemischtem Modus standardmäßig deaktiviert. Für dieses Konto wird ein zufälliges Kennwort generiert. Sie können es auch selbst deaktivieren. Es gibt zu diesem Thema kein Whitepaper, aber das Deaktivieren und Umbenennen von Anmeldungen wird in einem Artikel zu Best Practices erörtert.

Wenn Sie das SA-Konto vor Zerstörungsversuchen schützen wollen, können Sie es auch umbenennen. Doch denken Sie daran, dass Sie ein neues Kennwort festlegen sollten, wenn Sie ein deaktiviertes Konto aktivieren.

Zu Ihrer Frage, ob dies wahre Sicherheit bietet: Bedenken Sie, dass die zusätzliche Sicherheit durch Deaktivieren des Kontos darauf zurückzuführen ist, dass das Erraten eines Kennworts nutzlos ist, solange das Konto deaktiviert ist. Egal, wie viel Zeit ein Hacker oder Virus hat, wird ein Brute-Force-Angriff auf ein gesperrtes Konto nicht gelingen. Das Umbenennen oder Deaktivieren des SA-Kontos zerstört Anwendungen, die für ihre Konnektivität von der Verwendung des SA-Kontos abhängig sind. Die Suche nach diesen Anwendungen und ihre anschließende Reparatur oder Eliminierung sollte sowieso eine Priorität sein. Wie bereits erwähnt, kann das Konto erst für eine Verbindung zur Datenbank verwendet werden, wenn es wieder aktiviert wird. Da zudem der Authentifizierungsprozess früher fehlschlägt, wirkt sich ein fehlgeschlagener Versuch weniger auf das angegriffene System aus.

F: In einer meiner größeren OLTP-Datenbanken befindet sich eine Protokolldatei, die doppelt so groß wie die Datendatei ist. Ich habe bereits die folgenden Befehle ausprobiert, um die Protokolldatei auf eine vernünftige Größe zu reduzieren, aber ich muss sie noch weiter verkleinern:

backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

A: Sie sollten die Sicherungsdatenbank in eine Sicherungsprotokollanweisung umändern. Als Alternative könnten Sie die Datenbank in den einfachen Wiederherstellungsmodus setzen und die shrinkfile-Anweisung ausgeben. Nach Verkleinern des Protokolls setzen Sie die Datenbank auf ihr vorheriges Wiederherstellungsmodell zurück. Sichern Sie anschließend die Datenbank. Wenn die Datei immer noch nicht kleiner wird, prüfen Sie (mithilfe von dbcc opentran), ob offene Transaktionen vorhanden sind. Der folgende Knowledge Base-Artikel enthält weitere Informationen: support.microsoft.com/kb/907511.

F: Wenn während eines geplanten SQL Server-Agent-Auftrags ein Failover stattfindet, was geschieht dann mit diesem Auftrag nach dem Failover? Muss er manuell neu gestartet werden?

A: Ja, er muss manuell gestartet werden, wenn kein anderer Prozess vorhanden ist. Wenn Sie Aufträge nicht manuell neu starten möchten, könnten Sie ein Skript schreiben, das eine Tabelle nach Auftragsabschluss aktualisiert. Wenn der Wert gleich 1 ist, wurde der Auftrag ausgeführt. Andere Werte zeigen an, dass der Auftrag nicht abgeschlossen wurde, und ein zweiter Auftrag wird später gestartet, um den Startbefehl auszugeben. Obwohl der Auftrag erneut ausgeführt werden muss, wenn ein Failover während des Vorgangs erfolgt, können Sie mit einem Skript zumindest sicherstellen, dass wichtige Aufträge über Nacht vor dem nächsten Arbeitstag abgeschlossen werden können.

Tipp: Aktualisieren und DBCC UPDATEUSAGE

Aktualisieren Sie von SQL Server 2000 auf SQL Server 2005?

In diesem Fall sollten Sie unbedingt DBCC UPDATEUSAGE direkt nach Aktualisieren der Datenbanken ausführen.

DBCC UPDATEUSAGE meldet und korrigiert Ungenauigkeiten bei der Seiten- und Zeilenanzahl in den Katalogansichten. Diese Ungenauigkeiten müssen korrigiert werden, da sie dazu führen könnten, dass von dem im System gespeicherten sp_spaceused-Verfahren falsche Berichte zur Speicherplatznutzung zurückgegeben werden. In SQL Server 2005 werden diese Werte immer richtig verwaltet, sodass es bei diesen Datenbanken nie zu einer falschen Anzahl kommen sollte. Doch auf SQL Server 2005 aktualisierte Datenbanken können eine ungültige Anzahl enthalten, sodass Sie DBCC UPDATEUSAGE nach der Aktualisierung ausführen sollten.

So funktioniert DBCC UPDATEUSAGE: Es korrigiert die Anzahl der Zeilen, verwendeten Seiten, reservierten Seiten, Blattseiten und Datenseiten für jede Partition in einer Tabelle oder einem Index. Wenn in den Systemtabellen keine Ungenauigkeiten enthalten sind, gibt DBCC UPDATEUSAGE keine Daten zurück. Wenn Ungenauigkeiten gefunden und korrigiert werden und Sie WITH NO_INFOMSGS nicht verwendet haben, gibt DBCC UPDATEUSAGE die Zeilen und Spalten zurück, die in den Systemtabellen aktualisiert werden.

DBCC UPDATEUSAGE kann auch zum Synchronisieren von Speicherplatznutzungsindikatoren verwendet werden. Da das Ausführen von DBCC UPDATEUSAGE bei großen Tabellen oder Datenbanken einige Zeit dauern kann, sollte dieses Tool normalerweise nur verwendet werden, wenn Sie meinen, dass falsche Werte von sp_spaceused zurückgegeben werden. Beachten Sie, dass sp_spaceused einen optionalen Parameter zum Ausführen von DBCC UPDATEUSAGE akzeptiert, bevor Informationen zur Speicherplatznutzung für die Tabelle oder den Index zurückgegeben werden.

DBCC CHECKDB wurde in SQL Server 2005 verbessert, sodass jetzt auch erkannt wird, wenn eine Seiten- oder Zeilenanzahl negativ wird. Wenn negative Zahlen entdeckt werden, gibt DBCC CHECKDB eine Warnung und die Empfehlung aus, DBCC UPDATEUSAGE zum Beheben des Problems auszuführen. Obwohl es den Anschein haben könnte, dass die Aktualisierung der Datenbank auf SQL Server 2005 dieses Problem verursacht hat, kann davon ausgegangen werden, dass die ungültigen Anzahlen bereits vor dem Upgradeverfahren vorhanden waren.

Als Beispiel sehen Sie hier, wie eine Seiten- oder Zeilenanzahl oder beides für alle Objekte in der aktuellen Datenbank aktualisiert wird. Der folgende Befehl gibt 0 für den Datenbanknamen an, und DBCC UPDATEUSAGE meldet aktualisierte Informationen für die aktuelle Datenbank:

DBCC UPDATEUSAGE (0);
GO

Um beispielsweise eine Seiten- oder Zeilenanzahl oder beides für AdventureWorks zu aktualisieren und gleichzeitig Informationsmeldungen zu unterdrücken, führen Sie einen Befehl ähnlich wie den folgenden aus, der AdventureWorks als Datenbanknamen angibt und dann alle Informationsmeldungen unterdrückt:

USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO

Weitere Informationen finden Sie in der SQL Server-Onlinedokumentation unter DBCC UpdateUsage.

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.