SQL – Fragen und AntwortenDatenbankgröße, Spiegelung, markierte Transaktionen und mehr

Herausgegeben von Nancy Michell

Verschieben eines Clusters

F Ich muss einen SQL Server 2000-Cluster zu neuen IP-Adressen verschieben, und zwar sowohl für die physischen Server als auch die Windows®- und SQL Server™-Cluster. Muss ich dazu die ganze Lösung neu erstellen?

A Nein, Sie müssen nur das SQL Server-Setup ausführen und die IP-Adressen ändern. Hier ist ein Knowledge Base-Artikel mit Anleitungen.

Datenbankgröße

F Ich führe SQL Server 2000 SP4 mit einer wichtigen Datenbank von fast 10 GB, einem Wiederherstellungsmodell des Typs SIMPLE, einer primären Datei von 9850 MB und einer Transaktionsprotokolldatei von 88 MB aus. Die Größe der Datenbanksicherung beträgt ebenfalls fast 10 GB. Soll ich die Größe der Datenbank verringern, um die Leistung zu verbessern? Falls ja, soll ich DBCC SHRINKDATABASE oder DBCC SHRINKFILE verwenden? (Leider stehen mir für diese Wartungsaktion nur die Hauptlastzeiten zur Verfügung.)

A DBCC SHRINKDATABASE oder DBCC SHRINKFILE sind nur dann von Nutzen, wenn in der Datenbank viele Löschungen und Aktualisierungen vorgenommen werden, die zu einem kleineren Volumen der Daten führen. Die eigentliche Frage ist jedoch, warum Ihnen dies so wichtig ist. Ein 10-GB-Speicher kostet heutzutage ca. 20 Euro. Wäre es nicht sinnvoller, einen zusätzlichen Speicher von 100 GB hinzuzufügen und die Ausführung fortzusetzen? Die Leistung wird sich durch die erhöhte Fragmentierung verschlechtern, doch wenn Sie keine Wartung vornehmen können, haben Sie kaum eine andere Wahl. In solchen Fällen setzen manche Benutzer eine zweite Kopie der Datenbank ein. Sie erstellen eine Sicherungskopie mit aktueller Replikation, nehmen eine Wartung der Sicherungskopie vor und verknüpfen dann die Anwendungen mit der Sicherungskopie. Hierfür sind natürlich einige Codeänderungen und ein Wechsel vom Wiederherstellungsmodell des Typs SIMPLE (zum Typ FULL oder BULK_LOGGED) erforderlich. Dies könnte jedoch langfristig eine gute Lösung darstellen.

Aktualisieren und Leistung

F Ich muss zwei Anwendungen von SQL Server 2000 zu SQL Server 2005 verschieben. Wie kann ich Leistungseinbußen während der Aktualisierung vermeiden?

A In der Regel können die folgenden Szenarien einen Leistungsabfall verursachen und sollten nach Möglichkeit vermieden werden:

  1. Sie haben die Statistik nach dem Aktualisieren auf SQL Server 2005 nicht neu erstellt.
  2. Sie verwenden JOINS- und WHERE-Klauseln, die zwei verschiedene Datentypen miteinander vergleichen. Dies führt insbesondere dann zu einer Leistungsverminderung, wenn auf dem Server SQL Server 2000 SP3 oder eine vorherige Version ausgeführt wurde (siehe support.microsoft.com/kb/271566/).
  3. Die SQL Server 2005-Instanz ist nicht richtig konfiguriert. Speicher, Erweiterungen für die Adressfenstersteuerung, Treiber und so weiter sind falsch konfiguriert. Das System, auf dem SQL Server 2000 ausgeführt wird, wurde optimiert, doch der dafür verantwortliche Benutzer hat die Firma verlassen, ohne das Verfahren zu dokumentieren. Aus diesem Grund wurde die Optimierung für die SQL Server 2005-Instanz nicht durchgeführt.
  4. Die Hardware ist fehlerhaft. Oft wird neue Hardware gekauft, weil sie in der Werbung angepriesen wurde. In der Praxis hält sie jedoch oft den Anforderungen nicht stand.

Vor dem Einsatz einer SQL Server-Instanz sollte ein Leistungsvergleich vorgenommen werden, um sicherzustellen, dass die von Ihnen erwartete Leistung tatsächlich erzielt werden kann. Dadurch kann die Infrastruktur als mögliches Problem ausgeschlossen werden. Prüfen Sie dazu Leistungsindikatoren wie z. B. Datenträger, E/A und Speicher, und vergleichen Sie diese bei den verschiedenen Instanzen.

Datenbankspiegelung

F Ich verwende die Datenbankspiegelung und möchte die Datenbankoption READ_COMMITTED_SNAPSHOT aktivieren. Wenn ich versuche, die Option zu aktivieren, nachdem die Spiegelung eingerichtet wurde, erhalte ich eine Fehlermeldung mit der Information, dass die sich Datenbank in einer Spiegelungssitzung befindet, und der Befehl kann nicht ausgeführt werden.

A Zum Einrichten der Option READ_COMMITTED_SNAPSHOT ist ein Neustart der Datenbank erforderlich. Daher müssen Sie die Spiegelungssitzung unterbrechen, die Option festlegen und die Datenbank neu starten. Nachdem diese Schritte durchgeführt wurden, können Sie die Spiegelung neu einrichten. Die Spiegeldatenbank ruft die Option ab, sobald die Sitzung eingerichtet ist, und verwendet sie im Falle eines Failovers.

F Ich versuche, eine asynchrone Spiegelung einzurichten, und erhalte den Fehler 1418. Beim Ausführen von Netstat -ano zeigt sich, dass SQL Server auf allen Servern auf dem richtigen Port abfragt. Der Fehler wird angezeigt, wenn ich versuche, die Spiegelung zu starten. Was ist die Ursache des Problems?

A Eine Möglichkeit ist, dass Ihre Firewall die Kommunikation blockiert. Dies ist ein relativ häufiges Problem, das Sie untersuchen sollten. Weitere Informationen finden Sie in den folgenden Whitepapers: Troubleshooting Database Mirroring Setup (in englischer Sprache) unter und MSSQLSERVER_1418.

Beachten Sie dabei, dass sich dieses Problem nicht spezifisch auf die asynchrone Spiegelung bezieht. Es kann ebenso bei einer synchronen Spiegelung auftreten.

Die angezeigte Fehlermeldung (die besagt, dass die Servernetzwerkadresse nicht erreicht werden kann oder nicht vorhanden ist und in der Sie aufgefordert werden, den Netzwerkadressennamen zu prüfen und den Befehl erneut einzugeben) ist korrekt. Oft liegt es nicht daran, dass der Remotepartner nicht vorhanden ist, sondern dass der Remotepartner einfach nicht erreicht werden kann.

Dies kann passieren, wenn der Remotepartner heruntergefahren ist, den Port nicht abruft oder sogar wenn der Endpunkt heruntergefahren ist (möglicherweise können die Partner nicht den gleichen Verschlüsselungsmechanismus verwenden, oder es liegt ein anderes Authentifizierungsproblem vor). Außerdem kann dies passieren, wenn der Partner blockiert wird, was möglicherweise auf die Firewall des Partners zurückzuführen ist, der den Befehl initiiert.

Überprüfen Sie auch, ob möglicherweise ein Problem mit den Datenquellennamen (DSN) oder bei der Namensauflösung vorliegt. Die allgemeine Empfehlung lautet, vollständig qualifizierte Domänennamen zu verwenden. Auch wenn das Problem oft auf Ihre Firewall zurückzuführen ist, sollten Sie bedenken, dass es noch viele andere Ursachen gibt.

F Ich möchte die SQL Server 2005-Spiegelung verwenden, habe jedoch gehört, dass sie nicht empfohlen wird, wenn mehrere Anwendungen eine Verbindung zu mehreren Datenbanken auf der gleichen SQL Server-Instanz herstellen. Ist dies richtig?

A Das hängt davon ab, ob jede Anwendung über ihre eigene Datenbank verfügt oder ob die Anwendungen datenbankübergreifende oder DTC-Transaktionen (Distributed Transaction Coordinator) verwenden. Wenn datenbankübergreifende Transaktionen vorliegen, kann das Spiegeln logische Inkonsistenzen zur Folge haben, in denen Transaktionen nicht erwartungsgemäß übermittelt werden. Eine gute Erklärung dafür, was unter diesen Umständen geschieht, erhalten Sie hier.

Wenn es mehrere Datenbanken gibt, die von mehreren Anwendungen verwendet werden, und jede Anwendung über ihre eigene Datenbank verfügt, wird das Spiegeln diese Probleme nicht verursachen.

Markierte Transaktionen

F Was sind markierte Transaktionen, und können sie verwendet werden, wenn es sich bei einer der Datenbanken um eine SQL Server- und bei der anderen um eine Oracle-Datenbank handelt?

A Das Markieren einer Transaktion ist eine vom Datenbankadministrator regelmäßig durchgeführte Aktion, durch die in allen Protokollen an der gleichen Stelle eine Markierung eingefügt wird. Zusammen mit der Möglichkeit, eine Tabelle bis zu einer Transaktionsmarkierung wiederherzustellen, wird es Ihnen durch diese Aktion erlaubt, alle Datenbanken bis zum gleichen Punkt wiederherzustellen. Die Wiederherstellung kann insgesamt recht unerfreulich sein, da Sie alle relevanten Datenbanken wiederherstellen müssen und dabei in allen Datenbanken Daten verloren gehen. Deshalb sollten Sie dies vermeiden, indem Sie sicherstellen, dass Sie Ihre Protokolldateien nicht verlieren. Markierte Transaktionen sind SQL Server-spezifisch. Falls Ihre verteilten Transaktionen andere Datenbanken als SQL Server-Datenbanken umfassen, kann für diese keine Transaktionsmarkierung vorgenommen werden. Im Allgemeinen verwenden nur wenige verteilte Datenbanksysteme Transaktionsmarkierungen. In diesen Systemen ist der Verlust eines Transaktionsprotokolls ein schwerwiegendes Ereignis, für das viel manuelle Arbeit erforderlich ist, um den vorherigen Zustand wiederherzustellen.

Access-To-T-SQL-Konvertierungstool

F Gibt es ein automatisiertes Access™-To-T-SQL-Konvertierungstool, das für gespeicherte Prozeduren verfügbar ist?

A Versuchen Sie es mit SSMA (SQL Server Migration Assistant). Diese Komponente steht als Download zur Verfügung. Dort finden Sie außerdem SQL Server Migration Assistant for Oracle, SQL SQL Server Migration Assistant for Sybase und Migrating Informix Databases to Microsoft® SQL Server 2000.

Zum Aktualisieren von Access auf SQL Server könnten Sie auch den Office Upsizing-Assistenten verwenden. SSMA for Access (siehe Abbildung 1), bietet jedoch mehr Features, einschließlich Konvertierungsbewertungsberichte und Netzwerkscans. SSMA for Access behebt außerdem viele Probleme, die derzeit vom Office Upsizing-Assistenten nicht korrekt gehandhabt werden.

Abbildung 1 SQL Server Migration Assistant for Access

Abbildung 1** SQL Server Migration Assistant for Access **(Klicken Sie zum Vergrößern auf das Bild)

Nicht gruppierte Indizes

F Ich habe eine Tabelle vorliegen, in der der Primärschlüssel aus zwei GUID besteht (GUID1 und GUID2). Ich verfüge bereits über einen eindeutigen gruppierten Index für GUID1 und GUID2. Aus Leistungsgründen will ich jetzt den zweiten nicht gruppierten Index für GUID2 und GUID1 erstellen. Ist ein zusätzlicher Leistungsaufwand erforderlich, wenn ich den Index als eindeutig deklariere?

A Die Leistung wird nicht beeinträchtigt, wenn Sie den nicht gruppierten Index als eindeutig deklarieren. Dies könnte sogar weniger Ebenen in der Indexstruktur zur Folge haben.

Wenn ein nicht gruppierter Index als nicht eindeutig deklariert wird, wird der Zeilenlokalisierer an den Hauptteil der Indexeinträge in den Seiten des Stamms und des inneren Knotens angehängt. Dadurch wird das Löschen und Aktualisieren von Indexeinträgen erleichtert, was das Scannen einer Synonymkette vermeidet, falls Duplikate eines Schlüssels vorhanden sind. Der entsprechende Eintrag, der geändert werden soll, kann über einen Systemsuchvorgang nach Schlüssel und Lokalisierer gefunden werden. Das Ergebnis ist, dass die Einträge länger sind (und zwar beachtlich länger für den ausgewählten Gruppierungsschlüssel). Demzufolge werden die Seiten des Stamms und des inneren Knotens natürlich schneller gefüllt. Wenn der Index eindeutig ist, sollten Sie ihn als solches deklarieren.

Unabhängig davon, ob die Tabelle einen gruppierten Index enthält oder nicht, wird bei jedem nicht gruppierten Tabellenindex, der nicht als eindeutig deklariert ist, der Lokalisierer an die Indexeinträge in den Stammseiten und anderen Seiten des inneren Knotens angehängt.

Auch wenn Sie eine int-Kennungsspalte als Ersatzschlüssel verwenden und dann zwei eindeutige Indizes, (GUID1, GUID2) und (GUID2, GUID1), hinzufügen, wird die Leistung dadurch wahrscheinlich verbessert, da die Indizes über einen 4-Byte-Gruppierungsschlüssel anstelle eines 32-Byte-Gruppierungsschlüssels verfügen.

Aktualisierungssperren

F Ich habe eine gespeicherte Prozedur mit der folgenden Struktur:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances 
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId ) 
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION

Diese gespeicherte Prozedur lässt nur einen Abruf durch die Sperre, während alle anderen Abrufe warten müssen. Kann ich das gleiche Verhalten durch Herabsetzen der Isolierungsstufe erreichen?

READ COMMITTED scheint die richtige Isolierungsstufe zu sein, weil diese Transaktion nur eine Abfrage enthält. Wenn eine andere Transaktion gerade den gleichen Datensatz aktualisiert, wartet diese Transaktion auf die andere. Ist dies richtig?

A Es ist nicht die serialisierbare Einstellung in Ihrem Beispiel, die die anderen Abrufe warten lässt, es ist die Aktualisierung selbst. Sie können die Isolierung auf READ COMMITTED einstellen. In diesem Falle wird durch die Aktualisierung automatisch eine Aktualisierungssperre auf den derzeit verwendeten Index angewendet. Dies verursacht Probleme für andere Prozesse, die die gleiche Anweisung ausführen, und die Prozesse werden blockiert, bis die Aktualisierung abgeschlossen ist. (Sie benötigen auch keine explizite Transaktion, wenn die Aktualisierung die einzige Anweisung ist. Jede Anweisung befindet sich implizit in ihrer eigenen Transaktion, falls sie sich nicht in einer expliziten befindet.)

Wenn es jedoch keine Zeilen gibt, die mit der WHERE-Klausel in der UPDATE-Anweisung übereinstimmen, dann verhindert die Verwendung der serialisierbaren Isolierungsstufe, dass solche Zeilen in anderen Transaktionen eingefügt oder geändert werden. Wenn Sie die Aktualisierungsanweisung in der READ COMMITTED-Isolierung ausführen, ist dies nicht der Fall, und andere Transaktionen können Zeilen einführen, die für die Aktualisierung in Frage kommen. Wenn der Code für die gespeicherte Prozedur dem Code entspricht, den Sie angegeben haben, macht es möglicherweise keinen Sinn, diese Aktionen auszuführen (weder die serialisierbare Variante noch die Transaktionsvariante). Führen Sie einfach nur die Aktualisierung durch.

Unser Dank gilt den folgenden Microsoft-IT-Experten für ihre fachliche Unterstützung: Gaurav Aggarwal, Anthony Bloesch, Todd Briley, Shaun Cox, Roberto Di Pietro, Michael Epprecht, Kevin Farlee, Umachandar Jayachandran, Chuck Ladd, Kaloian Manassiev, Luciano Moreira, Ward Pond, Mark Prazak, Arunachalam Thirupathi, Roger Wolter, Clement Yip und Frankie Yuen.

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