Fragen und Antworten zu SQL Temporäre Tabellen, 64-Bit-Verarbeitung, Spiegelung und mehr

Herausgegeben von Nancy Michell

Temporäre Tabellen

F: Ich habe gehört, dass es manchmal keine so gute Idee ist, die temporäre Datenbank Tempdb zu verwenden, um Konflikte zu vermeiden. Stimmt das? Ich habe sie bisher verwendet, weil ich auf Daten zugreifen musste, die auf viele Tabellen verteilt sind, und diese dabei modifizieren musste. Mit Ansichten kann ich das nicht ohne weiteres tun.

A: Es stimmt, dass bei einer intensiv genutzten Tempdb Konflikte auftreten können. In der Regel treten Konflikte jedoch nur in seltenen Fällen auf, wenn z. B. Hunderte von SPID (Server Process Identifiers) vorliegen, die alle gleichzeitig eine große Zahl von temporären Tabellen erstellen. Dies wird im Knowledge Base-Artikel support.microsoft.com/kb/328551 beschrieben.

Die Verwendung einer temporären Tabelle (wobei übrigens unerheblich ist, ob diese in Tempdb ist) kann tatsächlich eine recht annehmbare Lösung sein. Die Schlüsselfrage ist, ob die erhöhte Leistung, die Sie erhalten, wenn Sie Daten aus der temporären Tabelle abrufen, den durch die Erstellung der Tabelle bedingten Mehraufwand wettmachen.

Bevor Sie sich gegen diese Lösung entscheiden, sollten Sie die Größe, Lebensdauer, Verwendungshäufigkeit und insbesondere die Anzahl der aktiven Instanzen von temporären Tabellen berücksichtigen. Die Servergröße spielt ebenfalls eine Rolle, da ein Tempdb-Konflikt hardwarebedingt sein kann.

Wenn Sie eine große Zahl von kleinen, kurzlebigen Tabellen benötigen, können Sie es mit Tabellenvariablen versuchen, die temporären Tabellen gegenüber einige Vorteile haben. (Nähere Einzelheiten über die Unterschiede zwischen Tabellenvariablen und temporären Tabellen entnehmen Sie bitte der Antwort auf unsere nächste Frage. Weitere Informationen finden Sie außerdem unter Häufig gestellte Fragen - SQL Server 2000 - Tabellenvariablen (möglicherweise in englischer Sprache).

Wenn alle Datenbankabfragen über die Erstellung temporärer Datenbanken erfolgen müssen, könnte es in Ihrem Fall auch ratsam sein, das Originaldatenmodell abzufragen, statt zu versuchen ohne dieses auszukommen.

F: Was versteht man unter Tabellenvariablen und wie gut funktionieren sie? Kann man sie wirklich anstelle von temporären Tabellen verwenden?

A: Temporäre Tabellen und Tabellenvariablen bieten dieselben Grundfunktionen; beide sind als temporäre Tabellen in der Tempdb-Datenbank vertreten. Werden hingegen nur ein paar wenige Zeilen eingefügt, können Tabellenvariablen eine bessere Leistung erbringen. Das rührt daher, dass Tabellenvariablen weder Statistiken noch Indizes verwalten und daher ein geringerer Verwaltungsaufwand anfällt. Solange der Inhalt der Tabelle ein paar 8 KB große Datenbankseiten nicht übersteigt, die das Datenbankmodul im Zwischenspeicher bereit hält, ist Tabellenvariablen der Vorzug zu geben.

Siehe SQL Server™-Onlinedokumentation:

• Eine Tabellenvariable verhält sich wie eine lokale Variable. Sie besitzt einen exakt definierten Gültigkeitsbereich, nämlich die Funktion, das gespeicherte Verfahren oder die Batchdatei, in der sie deklariert ist. Innerhalb ihres Gültigkeitsbereichs kann eine Tabellenvariable wie eine normale Tabelle verwendet werden.
• Tabellenvariablen werden am Ende der Funktion, des gespeicherten Verfahrens oder der Batchdatei, in der sie definiert sind, automatisch bereinigt.
• Tabellenvariablen, die bei gespeicherten Verfahren verwendet werden, verursachen weniger Rekompilierungen der gespeicherten Verfahren als temporäre Tabellen.
• Tabellenvariablen erfordern weniger Sperrungs- und Protokollierungsressourcen.
• In manchen Fällen kann die Leistung verbessert werden, wenngleich keine statistischen Daten darüber erhoben werden.

Spiegelung

F: Ich habe vor, SQL Server 2005-Spiegelung zu nutzen, um eine hohe Verfügbarkeit zu unterstützen. Das System wird in einem Modus mit hoher Verfügbarkeit betrieben werden, um automatisches Failover zu unterstützen. Um die Ressource ganz auszuschöpfen, will ich jedoch noch ein paar weitere Anwendungen auf dem Spiegel laufen lassen. Der Spiegelserver wird zwei Datenbanken unterstützen: Die Produktionsdatenbank als Spiegel zur primären Datenbank und die Stagingdatenbank als eigenständige Datenbank. Er wird auch zwei Arten von Clients unterstützen: einer ist mit dem Spiegelungsfailover konfiguriert, um auf die Produktionsdatenbank zuzugreifen, und der andere ist unmittelbar an die Stagingdatenbank angeschlossen.

Außerdem werden einige SQL Server Integration Services (SSIS)-Pakete auf dem Spiegelserver laufen. Sie werden auf beide Datenbanken zugreifen und die Daten aus der Stagingdatenbank auf dem lokalen Server auf die Produktionsdatenbank überspielen, die auf dem primären Server läuft. Während des Failovers werden die SSIS-Pakete die Daten von der lokalen Stagingdatenbank auf die lokale Produktionsdatenbank überspielen (Failover). Wirft diese Konfiguration Probleme auf, die mir bewusst sein sollten?

A: Generell ist zu sagen, dass eine derartige Konfiguration nicht zu empfehlen ist, weil der neue Prinzipal nach einem Failover überfordert sein könnte.

Was die Funktionalität angeht, sieht es nicht so aus, als würden aus der Spiegelungsperspektive heraus Probleme auftreten. Sie sollten jedoch umfassende Tests durchführen, bevor Sie diese Lösung umsetzen. Die Test sollten bei Spitzenbeanspruchung, in der Standardkonfiguration und nach einem Failover durchgeführt werden. Als Spitzenbeanspruchung sollte nicht Ihre derzeitige sondern die geschätzte zukünftige Spitzenbeanspruchung angenommen werden. Wenn Sie es versäumen, Ihren zukünftigen Geschäftsbedarf zu berücksichtigen, funktioniert die Lösung für Sie nicht mehr, sobald die Beanspruchung die Kapazitätsgrenze übersteigt.

Die Tests können durchaus Engpässe bei Netzwerk, Festplatte und selbst CPU ans Licht bringen, die sich in langsamen Anwendungsreaktionszeiten, einem inakzeptablen Durchsatz, Timeout-Fehlern oder extrem langen Wiederholungswarteschlangen auf dem Spiegelserver niederschlagen würden (was je nach der tatsächlichen Wiederholungsrate zu unerwartet langen Failoverzeiten führen könnte).

Außerdem geht während eines Failovers die Verbindung mit dem fehlerhaften Prinzipal verloren, wenn Pakete laufen. Wenn ein Failover beendet ist und die Datenbank auf dem neuen Prinzipal verfügbar ist, sollten die Pakete eine Verbindung zum neuen Prinzipal herstellen können. Immer vorausgesetzt natürlich, die Pakete sind mit Konnektivitäts-Wiederholungsmechanismen ausgestattet und können Verbindungsfehler problemlos bewältigen, indem Sie „abgebrochene“ Verbindungen wiederherstellen.

SQL Server und 64-Bit-Betriebssysteme

F: Stimmt es, dass ich bei Verwendung einer 64-Bit-Version eines Windows Server® Betriebssystems SQL Server 2000 Enterprise Edition (64 Bit) verwenden muss und den 32-Bit SQL Server 2000 nicht verwenden kann?

A: Was den SQL Server 2000 angeht, so ist ia64 von Intel die einzige systemeigene 64-Bit-Architektur, die unterstützt wird. Spricht man bei SQL Server 2000 von 64-Bit-Support, ist daher immer ia64 gemeint. Die einzige Version von SQL Server 2000, die auf systemeigenen 64 Bit unterstützt wird, ist Enterprise Edition. Es gibt keinen Standard Edition SQL Server 2000, der auf ia64 läuft, sei es systemeigen als 64-Bit-Anwendung oder unter ia64 Windows® auf Windows (WOW, ein Betriebssystem-Subsystem, auf dem 32-Bit-Anwendungen laufen).

Bei einem AMD x64 Computer haben Sie bei SQL Server 2000 zwei Wahlmöglichkeiten: Entweder Sie verwenden ein 32-Bit-Betriebssystem, wobei Sie jede beliebige Version von SQL Server 2000 und jedes Servicepaket (SP) verwenden können, oder Sie verwenden ein 64-Bit-Betriebssystem und SQL  Server 2000 (beliebige Version) SP4 unter WOW. In dieser Umgebung ist SQL Server 2000 keine systemeigene 64-Bit-Anwendung. Sie läuft unter WOW im 32-Bit-Modus und ist komplett vom 64-Bit-Universum abgeschirmt.

Weiter erschwert wird die Lage dadurch, dass ia64 WOW und x64 WOW zwei völlig unterschiedliche Subsysteme sind. Auf dem ia64 muss WOW sowohl einen beschränkten virtuellen Adressraum emulieren als auch eine Emulation der Computeranweisungen durchführen. Die Anweisungen für den ia64-Computer sind völlig anders als für x86. Es handelt sich um einen ganz anderen Computer. SQL Server unterstützt keine seiner Komponenten (SQL  Server 2000 oder SQL Server 2005) unter ia64 WOW.

Unter x64 WOW ist die Sachlage anders. x86- und x64-Computer weisen eine sehr ähnliche Architektur auf. Der Anweisungssatz ist identisch (oder nahezu identisch), so dass nur der 32-Bit virtuelle Adressraum emuliert werden muss, wofür eine Hardwarehilfe existiert. Es gibt also viele SQL Server-Komponenten, die x64 WOW unterstützen, wie z. B. SQL Server 2000 SP4 und alle Editionen von SQL Server 2005.

Aktualisierung auf SQL Server 2005

F: Ich möchte von SQL Server 2000 auf SQL Server 2005 aktualisieren. Welche Anwendungsänderungen muss ich neben der SQL-Codekorrektur vornehmen? Beispiel: Angenommen ich stelle mit einem Microsoft® .NET Framework-Client die Verbindung zu SQL Server 2005 her. Muss ich meine Desktop-Clients in diesem Fall auf Windows XP SP2 aktualisieren?

Ich verwende Windows XP SP1 und Visual Basic® 6.0 sowie einige Anwendungen, die .NET nutzen. Sind SQL Server Native Client, .NET Framework 2.0 und Windows XP SP2 erforderlich? Mit anderen Worten: Welche Mindestanforderungen in puncto Client bestehen generell für eine Aktualisierung? Und ändern sich die Client-Erfordernisse, falls ich mich zum Einsatz der SQL Server 2005-Spiegelung entscheiden sollte?

A: Um alle Vorteile der Spiegelung auszunutzen, müssen Sie SQL Native Client (für OleDb oder ODBC) oder den ADO.NET 2.0 SqlClient verwenden. Ferner sollte die Verbindungszeichenfolge geändert werden, sodass sowohl auf den Prinzipal als auch auf den Spiegel Bezug genommen wird.

Sie benötigen jedoch nur SQL Native Client oder .NET Framework 2.0, damit der Client den Spiegel erkennt. Ältere Clients können zwar eine Verbindung herstellen, versuchen es jedoch nicht automatisch mit dem Spiegel, wenn der Prinzipal ausgefallen ist.

Sie können, ohne die Clients zu berühren, einen BIG-IP-Schalter zwischen den Clients und dem Server einbauen, um sie bei einem Failover manuell zu verschieben. Oder Sie können den Code in der Anwendung verändern, um eine Verbindung zum Spiegelserver zu versuchen, wenn die Verbindung zum Prinzipal fehlschlägt.

Zu den Systemanforderungen gehört Folgendes: Windows Installer 3.0, Microsoft Windows XP SP1 oder höher, Microsoft Windows 2000 SP4 oder höher oder Microsoft Windows Server 2003. Weitere Informationen zu den Systemanforderungen finden Sie unter Verwenden von ADO mit SQL Native Client, Aktualisieren einer Anwendung auf SQL Native Client von MDAC aus und Systemanforderungen für SQL Native Client (möglicherweise in englischer Sprache).

SQL Server 2000 – Nicht genügend Arbeitsspeicher

F: Auf meinem Produktions-SQL Server 2000 Enterprise Edition SP4 auf Windows Server 2003 SP1 treten seltsame Ausnahmebedingungen aufgrund unzureichenden Arbeitsspeichers auf. Abbildung 1 zeigt die Fehlermeldung, die in den Protokollen erscheint.

Figure 1 Nicht genügend Arbeitsspeicher

2006-06-23 14:41:40.72 spid77    WARNING:  Failed to reserve contiguous memory of Size= 24641536.
2006-06-23 14:41:40.85 spid77    Buffer Distribution:  Stolen=4800 Free=1744 Procedures=39391
                                Inram=0 Dirty=90621 Kept=0
                                I/O=0, Latched=99, Other=3063345
2006-06-23 14:41:40.85 spid77    Buffer Counts:  Commited=3200000 Target=3200000 Hashed=3154065
                                InternalReservation=587 ExternalReservation=0 Min Free=1024 Visible= 173320
2006-06-23 14:41:40.85 spid77    Procedure Cache:  TotalProcs=9555 TotalPages=39391 InUsePages=1031
2006-06-23 14:41:40.85 spid77    Dynamic Memory Manager:  Stolen=44191 OS Reserved=7648 
                                OS Committed=7619
                                OS In Use=7603
                                Query Plan=39088 Optimizer=0
                                General=4183
                                Utilities=140 Connection=7651
2006-06-23 14:41:40.85 spid77    Global Memory Objects:  Resource=1617 Locks=313 
                                SQLCache=1836 Replication=204
                                LockBytes=2 ServerGlobal=42
                                Xact=63
2006-06-23 14:41:40.85 spid77    Query Memory Manager:  Grants=0 Waiting=0 Maximum=94533 Available=94533
2006-06-23 14:41:40.88 spid77    Error: 17803, Severity: 20, State: 12
2006-06-23 14:41:40.88 spid77    Insufficient memory available..

Mein Server verfügt über genug RAM (32 GB). Seltsamerweise scheint dieses Problem willkürlich aufzutreten. Bei der gespeicherten Prozedur, die diesen Fehler verursacht, tritt er etwa jedes zehnte bis zwanzigste Mal auf.

Die Leistungsindikatoren des Servers zeigen, dass viel freier Arbeitsspeicher zur Verfügung steht. Verläuft das Paging des Lazy Writer zum Datenträger nicht schnell genug? Warum wird für den Prozess so viel Arbeitsspeicher benötigt, wenn mein gespeicherter Prozess ausgeführt wird? Liegt es an der Anzahl der Select-Anweisungen oder der Verwendung temporärer Tabellen?

A: Es ist in diesem Fall unerheblich, über wie viel physischen Speicher der Computer verfügt. Je nach dem Setup Ihrer Datei boot.ini verfügen Anwendungen über 2 bis 3 GB virtuellen Adressraum. Bei 32-Bit-Systemen ist der virtuelle Adressraum ein wertvolles Gut. Die Pufferpools besetzen in der Standardeinstellung bis auf 384 MB den gesamten virtuellen Adressraum. Diese 384 MB werden für Threadstapel und Zuweisungen von Komponenten bereitgestellt, die entweder zu groß für den Pufferpool sind oder nicht vom Pufferpool aus zugewiesen werden können (Dritt-xprocs, verknüpfte Server, COM-Komponenten).

Die Warnung zeigt an, dass eine Zuweisung von ungefähr 23 MB fehlschlug. Der Erfolg oder Misserfolg von Zuweisungen dieser Größenordnung hängt von der Anzahl und Position anderer Zuweisungen innerhalb des 384-MB-Blocks ab.

Sie sollten in Betracht ziehen, einige der auf das System geladenen Drittanbieter-xprocs zu löschen, und bestimmen, ob COM-Komponenten über sp_oacreate oder verknüpfte Server verwendet werden.

Es ist durchaus möglich, dass der Prozess zur Ausführung Ihres gespeicherten SQL-Prozesses aufgrund der Verwendung der FOR XML-Klausel in Ihrem Sproc (der hier nicht erneut abgedruckt wurde) so viel Arbeitsspeicher benötigt . Sollten Sie weitere Informationen wünschen, erfahren Sie unter Process\sqlservr\Virtual Bytes, wie viel virtueller Adressraum noch verfügbar ist. Ferner gibt es ein Tool namens VMStat (auf der CD für das Buch „Programming Applications for Microsoft Windows“ von Jeffrey Richter), das den größten virtuellen Adressblock bestimmt. Der Lazy Writer ist an dieser Zuweisung nicht beteiligt; der für diese Zuweisung verwendete Speicherplatzbereich ist nicht in bpool.

Unser Dank gilt den folgenden Microsoft IT-Experten für ihre fachliche Unterstützung: Ramon Arjona, Stephen Borg, Sandu Chirica, Robert Djabarov, Guillaume Fourrat, Osamu Hirayama, Alejandro Mihanovich, Maxwell Myrick, Uttam Parui, Shashi Ramaka, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson, Madhusudhanan Vadlamaani, Jian Wang und Dave Wickert.

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