Optimieren der Leistung von Microsoft SQL Server (Teil I)

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 110352 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel wurde zuvor veröffentlicht unter D35983
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
110352 INF: Optimizing Microsoft SQL Server Performance
Alles erweitern | Alles schließen

Zusammenfassung

Zur effektiven Leistungsoptimierung von Microsoft SQL Server sollten Sie sich auf die Bereiche konzentrieren, in denen die größten Leistungsverbesserungen in einer breiten Situationsvielfalt erzielt werden können und diese anschließend analysieren. Sie können so den Einsatz von Zeit und Arbeit in Bereichen vermeiden, die nicht zu nennenswerten Verbesserungen führen.

Die folgenden Informationen beziehen sich zum überwiegenden Teil nicht auf die Leistungsprobleme, die sich aus den konkurrierenden Zugriffen mehrerer Benutzer ergeben. Auf dieses komplexe Thema wird gesondert in dem Dokument "Maximizing Database Consistency and Concurrency" eingegangen, das Sie im "Programmer's Reference for C", Anhang E, zu SQL Server, Version 4.2x, finden, sowie auch in anderen Knowledge Base-Artikeln. Dieses Dokument ist in der Dokumentation zu Version 6.0 nicht enthalten, kann aber auf der MSDN (Microsoft Developer Network)-CD unter dem genannten Titel eingesehen werden.

Dieser Artikel enthält keine theoretischen Erörterungen, sondern konzentriert sich in erster Linie auf Bereiche, die, wie die jahrelange Erfahrung des Microsoft SQL Server Support-Teams gezeigt hat, für die Praxis von besonderer Bedeutung sind.

Die Erfahrung hat gezeigt, dass die größte Steigerungsrate an SQL Server-Leistung in den allgemeinen Bereichen des logischen Datenbankentwurfs, des Indexentwurfs, des Abfrageentwurfs und des Anwendungsentwurfs erzielt werden kann. Umgekehrt resultieren die größten Leistungsprobleme meist aus Defiziten in diesen Bereichen. Wenn Sie sich mit der Leistung befassen, sollten Sie sich zuerst auf diese Bereiche konzentrieren, da sehr große Leistungsverbesserungen oft mit relativ kleinem Zeitaufwand erreicht werden können.

Obwohl andere Leistungsfaktoren auf Systemebene, wie z. B. Speicher, Cache-Puffer, Hardware usw. auch in Betracht kommen, hat die Praxis doch gezeigt, dass die Leistungszunahme aus diesen Bereichen oft minimal ist. SQL Server verwaltet Hardware-Ressourcen größtenteils automatisch und verringert somit die Notwendigkeit (und damit auch den Leistungsgewinn) von umfassender, manueller Systemabstimmung.

Microsoft SQL Server 6.0 bietet neue Möglichkeiten für Leistungsverbesserungen auf Plattformebene mit großen Speichermengen, symmetrischem Multiprozessorbetrieb, paralleler Datendurchsicht, Optimierer-Erweiterungen und Disk Striping. So groß diese Verbesserungen auch sind, sie sind in ihrem Anwendungsbereich beschränkt. Der schnellste Computer kann mit ineffizienten Abfragen oder schlecht entworfenen Anwendungen in die Knie gezwungen werden. Aus diesem Grund ist es trotz der zusätzlichen Leistungssteigerung, die mit SQL Server 6.0 erzielt werden kann, von besonderer Wichtigkeit, für ein optimiertes Design von Datenbank, Indizes, Abfragen und Anwendungen zu sorgen.

Die meisten Leistungsprobleme können nicht allein von der Serverseite aus gelöst werden. Der Server ist im Wesentlichen eine "Marionette" des Client, da dieser steuert, welche Abfragen gesendet werden und somit auch, welche Sperren erhalten und freigegeben werden. Obwohl einige Verbesserungen auf Serverseite möglich sind, hängt die erfolgreiche Lösung von Problemen bezüglich der Leistung normalerweise davon ab, dass die dominante Rolle des Clients für das Problem erkannt und das Verhalten der Clientanwendung analysiert wird.

Weitere Informationen

Die größten Optimierungserfolge erzielen Sie erfahrungsgemäß durch das Verbessern der folgenden Bereiche:

Normalisieren des logischen Datenbankentwurfs:

Durch vernünftiges Normalisieren eines logischen Datenbankentwurfs wird die beste Leistung erzielt. Eine größere Anzahl von kompakten Tabellen (mit weniger Spalten) ist ein Charakteristikum einer normalisierten Datenbank. Wenige breite Tabellen (mit mehr Spalten) verweisen auf eine nicht normalisierte Datenbank. Eine stark normalisierte Datenbank ist gewöhnlich mit komplexen relationalen Verknüpfungen verbunden, die die Leistung beeinträchtigen können. Stehen sinnvolle Indizes zur Verfügung, kann der Optimierer von SQL Server schnelle und effektive Verknüpfungen zwischen einer sinnvollen Anzahl von Tabellen auswählen.

Im Folgenden werden einige Vorteile der Normalisierung aufgezeigt:
  • Schnelle Sortierung und Indexerstellung aufgrund der kompakten Tabellen
  • Mehr gruppierte Indizes sind aufgrund der größeren Tabellenanzahl möglich
  • Kompaktere und schmalere Indizes
  • Weniger Indizes pro Tabelle, wodurch die Leistung von Aktualisierungsoperationen verbessert wird
  • Weniger NULL- und redundante Daten, wodurch die Datenkompaktheit vergrößert wird
  • Verbessert Parallelität mit der DBCC-Diagnose, da die erforderlichen Tabellensperrungen weniger Daten betreffen
Bei SQL Server dient eine vernünftige Normalisierung der Leistung meist eher, als dass sie ihr schadet. Mit der Normalisierung steigt auch die Anzahl und Komplexität der Verknüpfungen, die für die Datenabfrage erforderlich ist. Als Faustregel empfiehlt Microsoft, den Normalisierungsvorgang so lange laufen zu lassen, bis eine größere Anzahl von Abfragen Verknüpfungen mit vier oder mehr Tabellen verwenden.

In einigen Fällen ist der Entwurf der logischen Datenbank bereits fertiggestellt, und eine komplette Erneuerung ist nicht durchführbar. Doch selbst dann ist es in bestimmten Fällen möglich, eine große Tabelle selektiv zu normalisieren, wenn sich diese Tabelle in der Analyse als Engpass herausstellt. Erfolgt der Zugriff auf die Datenbank mittels gespeicherter Prozeduren, könnte dieser Schemawechsel ohne Auswirkungen auf die Anwendungen stattfinden. Andernfalls ist es möglich, die Änderung durch Erstellen einer Ansicht, bei der nur eine einzige Tabelle angezeigt wird, zu verbergen.

Verwenden eines effizienten Indexentwurfs:

Anders als viele nicht rationalen Systeme, werden relationale Indizes nicht als Teil des logischen Datenbankentwurfs angesehen. Indizes können entfernt, hinzugefügt und geändert werden, ohne dass das Datenbankschema oder der Anwendungsentwurf in einem anderen Bereich als der Leistung beeinflusst wird. Ein effizienter Indexentwurf ist von größter Wichtigkeit, um eine gute SQL Server-Leistung zu erzielen. Aus diesen Gründen sollten Sie unbedingt mit verschiedenen Indizes experimentieren.

Der Optimierer sucht meist zuverlässig die nützlichsten Indizes aus. Die allgemeine Strategie sollte darin bestehen, dem Optimierer eine gute Auswahl von Indizes bereitzustellen und ihm die Entscheidung zu überlassen. Dies reduziert die Analysezeit und bietet in zahlreichen Situationen gute Leistungsergebnisse.

Im Folgenden werden einige Empfehlungen für den Indexentwurf gegeben:
  • Prüfen Sie die WHERE-Klausel Ihrer SQL-Abfragen, da hier der primäre Schwerpunkt des Optimierers liegt:
Jede in der WHERE-Klausel aufgelistete Spalte ist ein möglicher Kandidat für einen Index. Müssen Sie zu viele Abfragen untersuchen, so suchen Sie sich eine repräsentative Menge oder einfach die langsameren heraus. Wenn Ihr Entwicklungs-Tool SQL-Code transparent erzeugt, ist das schwieriger. Viele dieser Tools lassen zum Zweck der Fehlerbehebung das Protokollieren der erzeugten SQL-Syntax in einer Datei oder auf dem Bildschirm zu. Wenden Sie sich an Ihren Händler, um in Erfahrung zu bringen, ob diese Funktion verfügbar ist.
  • Verwenden Sie kompakte Indizes:
Kompakte Indizes sind meist effektiver als mehrspaltige, zusammengesetzte Indizes. Kompakte Indizes verfügen über mehr Zeilen pro Seite und weniger Indexebenen und verbessern so die Leistung.

Der Optimierer kann schnell und effektiv eine sehr große Anzahl von Index- und Verknüpfungsmöglichkeiten analysieren. Durch eine größere Zahl kompakter Indizes erhält der Optimierer mehr Auswahlmöglichkeiten, was gewöhnlich der Leistung zugute kommt. Eine geringere Anzahl breiter, mehrspaltiger Indizes bietet dagegen weniger Auswahlmöglichkeiten, was sich nachhaltig auf die Leistung auswirken kann.

Oft ist es beim Auswählen einer Strategie am günstigsten, den Schwerpunkt nicht auf vollständig überdeckende Abfragen zu legen. Wenn alle Spalten in der SELECT-Klausel durch nicht gruppierte Indizes erfasst sind, kann der Optimierer dies zwar erkennen und eine ausgezeichnete Leistung liefern, die Wahrscheinlichkeit, dass er tatsächlich diese Strategie wählt, ist jedoch sehr gering, da die Indizes in diesem Fall oft übertrieben breit sind. Üblicherweise sollten Sie eine größere Zahl kompakter Indizes verwenden, mit denen oft eine bessere Leistung über einen weiteren Bereich von Abfragen hinweg erzielt wird.

Aufgrund des Aufwands, der mit dem Aktualisieren dieser Indizes verbunden ist, sollten nicht mehr Indizes vorhanden sein, als für eine adäquate Leseleistung notwendig sind. Allerdings benötigen sogar hauptsächlich aktualisierungsbezogene Operationen mehr Lese- als Schreibvorgänge. Daher sollten Sie in jedem Fall einen neuen Index ausprobieren, falls dies hilfreich erscheint. Sie können ihn später immer noch entfernen.
  • Verwenden Sie gruppierte Indizes.
Die geeignete Verwendung von gruppierten Indizes kann die Leistung enorm verbessern. Selbst UPDATE- und DELETE-Operationen werden häufig von gruppierten Indizes beschleunigt, da diese Operationen viele Lesevorgänge erfordern. Da nur ein gruppierter Index pro Tabelle vorliegen darf, sollten Sie ihn sinnvoll verwenden. Mehrere Zeilen zurückliefernde Abfragen oder einen großen Wertebereich umfassende Abfragen sind für das Beschleunigen durch einen gruppierten Index prädestiniert.

Beispiele:
   SELECT * FROM TELEFONBUCH
   WHERE NACHNAME='SMITH'
-oder-
   SELECT * FROM MITGLIEDER
   WHERE  MITGLIED_NR > 5000
   AND MITGLIED_NR < 6000
Die oben genannten Spalten NACHNAME und MITGLIED-NR sind in der Regel weniger für einen nicht gruppierten Index geeignet, sofern der Abfragetyp allgemein ist. Nicht gruppierte Indizes sollten bevorzugt auf Spalten gesetzt werden, für die nur eine kleine Zahl von Zeilen zurückgegeben wird.
  • Überprüfen Sie die Eindeutigkeit von Spalten.
Dies hilft Ihnen bei der Entscheidung, ob eine Spalte für einen gruppierten Index, einen nicht gruppierten Index oder keinen Index geeignet ist.

Die folgende Beispielabfrage ermöglicht Ihnen, die Eindeutigkeit von Spalten zu überprüfen:
   SELECT COUNT (DISTINCT SPALTENNAME)
   FROM TABLELLENNAME
Diese Abfrage gibt die Anzahl der eindeutigen Werte in der Spalte zurück. Vergleichen Sie diese mit der Gesamtzahl der Zeilen in der Tabelle. In einer Tabelle mit 10.000 Zeilen würden 5.000 eindeutige Werte bedeuten, dass die Spalte für einen nicht gruppierten Index geeignet ist. Bei 20 eindeutigen Werten in einer Tabelle sollte ein gruppierter Index gesetzt werden. Drei eindeutige Werte sollten überhaupt nicht indiziert werden. Es handelt sich hierbei nur um Beispiele und nicht um starre Regeln. Denken Sie daran, die Indizes in den individuellen Spalten anzugeben, die in den WHERE-Klauseln der Abfragen aufgelistet sind.
  • Untersuchen Sie die Datenverteilung in indizierten Spalten.
Eine lang andauernde Abfrage wird oft dadurch verursacht, dass einer Spalte mit wenigen eindeutigen Werten ein Index zugewiesen wird, oder dass eine JOIN-Anweisung für eine solche Spalte ausgeführt wird. Dabei handelt es sich um ein fundamentales Problem mit den Daten und der Abfrage selbst, dessen Lösung voraussetzt, dass diese Situation erkannt wird. Beispielsweise kann in einem physischen Telefonverzeichnis, in dem die Namen alphabetisch geordnet sind, nicht nach einer bestimmten Person gesucht werden, wenn sämtliche Einwohner der Stadt nur entweder "Smith" oder "Jones" heißen. Zusätzlich zu der obigen Abfrage, die einen einzigen Wert zur Eindeutigkeit der Spalte liefert, können Sie eine GROUP BY-Abfrage verwenden, um die Datenverteilung der indizierten Schlüsselwerte zu sehen. Dies liefert eine höhere Auflösung für das von den Daten erstellte Bild sowie eine bessere Perspektive der Darstellungsart der Daten durch den Optimierer.

Mit der folgenden Beispielabfrage können Sie die Datenverteilung der indizierten Schlüsselwerte untersuchen, vorausgesetzt, auf SPAL1, SPAL2 befindet sich ein Zweispaltenschlüssel:
   SELECT SPAL1, SPAL2, COUNT(*)
   FROM TABELLENNAME
   GROUP BY SPAL1, SPAL2
Dieses Beispiel gibt eine Zeile für jeden Schlüsselwert zurück und einen Zähler für die Instanzen jedes Wertes. Um die Anzahl der zurückgegebenen Zeilen zu reduzieren, könnte es hilfreich sein, einige von ihnen mit der HAVING-Klausel auszuschließen. Beispielsweise können Sie mit Hilfe der Klausel
   HAVING COUNT(*) > 1
alle Zeilen ausschließen, die einen eindeutigen Schlüssel besitzen.

Die Anzahl der Zeilen, die in einer Abfrage zurückgegeben werden, ist auch ein wichtiger Faktor bei der Indexwahl. Der Optimierer nimmt für einen nicht gruppierten Index mindestens eine E/A-Operation pro zurückgegebener Zeile an. In diesem Fall ist eine Tabellendurchsicht effektiver als ein nicht gruppierter Index. Dies ist ein weiterer Grund dafür, die Größe der Ergebnismenge einzuschränken, oder eine große Ergebnismenge mit einem gruppierten Index zu suchen.

Die Verwendung eines Index kann nicht immer mit guter Leistung gleichgesetzt werden und umgekehrt. Wenn die Verwendung eines Index immer die beste Leistung zur Folge hätte, bestünde die Aufgabe des Optimierers nur darin, stets jeden verfügbaren Index zu verwenden. Tatsächlich aber kann die falsche Wahl der indizierten Suche zu schlechter Leistung führen. Deshalb ist es die Aufgabe des Optimierers, die indizierte Suche dann auszuwählen, wenn sie die Leistung erhöht und zu vermeiden, wenn sie diese verringert.

Verwenden eines effizienten Abfrageentwurfs:

Einige Abfragetypen sind strukturbedingt besonders ressourcenintensiv. Dies liegt an grundlegenden Datenbank- und Indexstrukturen, die bei den meisten RDBMs (Relational Database Management Systems) und nicht nur speziell bei SQL Server vorliegen. Die Abfragen werden dadurch jedoch nicht ineffektiv, da der Optimierer sie so effektiv wie möglich durchführt. Allerdings bleiben sie ressourcenintensiv, und die mengenorientierte Struktur von SQL lässt sie ineffektiv erscheinen. Kein noch so intelligenter Optimierer kann den Ressourcenaufwand dieser Konstrukte reduzieren. Der Unterschied fällt vor allem im Gegensatz zu einer einfachen Abfrage auf. Obwohl SQL Server den optimalen Zugriffsplan verwendet, liegt eine Einschränkung durch die grundlegenden Möglichkeiten vor.

Die folgenden Abfragecharakteristika sind beispielsweise ressourcenintensiv:
  • Große Ergebnismengen
  • IN-, NOT IN- und OR-Abfragen
  • Höchst uneindeutige WHERE-Klauseln
  • != (Ungleich-) Vergleichsoperatoren
  • Bestimmte Spaltenfunktionen wie SUM
  • Ausdrucks- und Datenumwandlungen in der WHERE-Klausel
  • Lokale Variablen in der WHERE-Klausel
  • Komplexe Sichten mit GROUP BY oder ORDER BY
Verschiedene Faktoren können die Verwendung einiger dieser Abfragekonstrukte erfordern. Deren Auswirkungen werden vermindert, wenn der Optimierer die Ergebnismenge beschränken kann, bevor der ressourcenintensive Teil der Abfrage ausgeführt wird, wie dies in den Beispielen der folgenden Tabelle gezeigt wird:

Ressourcenintensiv:
   SELECT SUM(EINKOMMEN) FROM TABELLE
Weniger ressourcenintensiv:
   SELECT SUM(EINKOMMEN) FROM TABELLE WHERE
   PLZ='66606'
Ressourcenintensiv:
   SELECT * FROM TABELLE WHERE
   NNAME=@VAR
Weniger ressourcenintensiv:
   SELECT * FROM TABELLE
   WHERE NNAME=@VAR AND PLZ='66606'
Im ersten Beispiel kann die SUM-Operation nicht mit einem Index beschleunigt werden. Jede Zeile muss gelesen und aufsummiert werden. Angenommen, es gibt einen Index für die Spalte PLZ, dann wird der Optimierer diesen wahrscheinlich verwenden, um zuerst die Ergebnismenge zu beschränken, bevor er die SUM-Anweisung ausführt. Das kann viel schneller sein.

Im zweiten Beispiel wird die lokale Variable bis zur Laufzeit nicht aufgelöst. Der Optimierer kann jedoch die Wahl des Zugriffsplans nicht bis zur Laufzeit aufschieben, sondern muss ihn zur Kompilierzeit auswählen. Noch zur Kompilierzeit, wenn der Zugriffsplan erstellt wird, ist der Wert von @VAR unbekannt und kann folglich nicht als Eingabe für die Indexauswahl verwendet werden. Die dargestellte Verbesserungstechnik besteht aus einem Beschränken der Ergebnismenge mit einer AND-Klausel. Eine alternative Technik wäre die Verwendung einer gespeicherten Prozedur, wobei der Wert von @VAR der gespeicherten Prozedur als Parameter übergeben wird.

In manchen Fällen ist es besser, eine Gruppe einfacher Abfragen zu verwenden und die Zwischenergebnisse in temporären Tabellen zu speichern, als eine einzelne, komplexe Abfrage zu verwenden.

Große Ergebnismengen sind bei den meisten RDBMSs ressourcenintensiv. Vermeiden Sie, große Ergebnismengen an den Client zur abschließenden Datenauswahl über Durchsuchen zurückzugeben. Es ist effizienter, die Größe der Ergebnismenge zu beschränken und dem Datenbanksystem die Aufgabe zu überlassen, für die es vorgesehen ist. Dies reduziert ferner die Netzwerk-E/A-Operationen und vereinfacht den Einsatz der Anwendung über langsame Kommunikationsverbindungen. Darüber hinaus wird die Leistung bei parallel durchgeführten Prozessen verbessert, so dass die Anwendung mehr Benutzern zur Verfügung stehen kann.

Verwenden eines effizienten Anwendungsentwurfs:

Die Rolle, die der Anwendungsentwurf bei der SQL Server-Leistung spielt, kann nicht hoch genug eingeschätzt werden. Anstatt dem Server die dominante Rolle zuzuschreiben, trifft es eher zu, den Client als die kontrollierende Einheit anzusehen und den Server als dessen 'Marionette'. Der SQL-Server befindet sich vollständig unter dem Kommando des Clients, betrachtet man den Abfragetyp, wann die Abfrage vorgelegt wird und wie die Ergebnisse verarbeitet werden. Dies hat wiederum eine erhebliche Auswirkung auf die Art und Dauer von Sperren, auf die Höhe der E/A- und CPU-Belastung auf dem Server sowie auf die Leistung.

Aus diesem Grund ist es wichtig, während der Entwurfsphase der Anwendung die richtigen Entscheidungen zu treffen. Auch wenn ein Problem mit einer betriebsfertigen Anwendung auftritt, für die Änderungen an der Clientanwendung unmöglich erscheinen, ändert dies nichts an den grundlegenden, die Leistung beeinflussenden Tatsachen, nämlich dass der Client eine dominante Rolle spielt, und dass viele Leistungsprobleme nicht ohne Änderungen am Client gelöst werden können.

Unter der Verwendung einer sinnvoll strukturierten Anwendung ist SQL Server in der Lage, Tausende von Benutzern gleichzeitig zu unterstützen. Mit einer schlecht strukturierten Anwendung kann auch die leistungsfähigste Serverplattform selbst bei geringer Benutzerzahl keine gute Leistung erbringen. Erfahrungsgemäß führt die Beachtung folgender Regeln zu einer guten SQL Server-Leistung:
  • Verwenden Sie kleine Ergebnismengen. Das Abrufen unnötig großer Ergebnismengen (z. B. mehrere Tausend Zeilen) zum Durchsuchen auf dem Client erhöht die CPU- und E/A-Belastung des Netzwerks, schränkt die Benutzbarkeit der Anwendung über das Netzwerk ein und kann die Mehrbenutzer-Skalierbarkeit einschränken. Es ist besser, die Anwendung so zu entwerfen, dass sie vom Benutzer ausreichende Eingaben anfordert, damit nur Abfragen übermittelt werden, die gemäßigte Ergebnismengen erzeugen.
Zu den Techniken des Anwendungsentwurfs, mit deren Hilfe eine kleine Ergebnismenge erzielt werden kann, gehören das mäßige Einsetzen von Stellvertreterzeichen beim Erstellen von Abfragen, das Erzwingen von Eingaben in bestimmten Eingabefeldern und das Unterbinden von Ad-hoc-Abfragen.
  • Achten Sie auf eine korrekte Verwendung von dbcancel() in DB-Library-Anwendungen. Alle Anwendungen sollten den Abbruch einer Abfrage erlauben, die gerade bearbeitet wird. Der Benutzer sollte durch keine Anwendung gezwungen werden, den Client-Computer neu zu starten, um eine Abfrage abzubrechen. Bei Nichtbeachtung dieses Grundsatzes kann es zu Leistungsproblemen kommen, für die es keine Lösungsmöglichkeiten gibt. Bei der Verwendung von dbcancel() sollte entsprechende Vorsicht im Hinblick auf die Transaktionsebene geübt werden. Weitere Informationen hierzu finden Sie in dem folgenden Artikel der Microsoft Knowledge Base:
       ARTIKEL-NR: Q117143
       TITEL     : INF: When and How to Use dbcancel() or sqlcancel()
Die gleichen Punkte ergeben sich für ODBC-Anwendungen, bei denen der ODBC-Aufruf sqlcancel() verwendet wird.
  • Verarbeiten Sie immer alle Ergebnisse vollständig. Entwerfen Sie keine Anwendung bzw. verwenden Sie keine betriebsfertige Anwendung, die die Bearbeitung von Zeilen der Ergebnismenge stoppt, ohne die Abfrage abzubrechen. Dieses Verhalten führt gewöhnlich zu Blockierungen und niedriger Leistung.
  • Implementieren Sie immer eine Abfragezeitüberschreitung. Lassen Sie es nicht zu, dass Abfragen unendlich lange ausgeführt werden. Verwenden Sie die entsprechenden DB-Library- oder ODBC-Aufrufe, um eine Abfragezeitüberschreitung einzustellen. Bei DB-Library geschieht dies mittels dbsettime(), bei ODBC mittels SQLSetStmtOption().
  • Verwenden Sie kein Entwicklungstool für Anwendungen, das keine ausdrückliche Kontrolle über die zum Server gesendeten SQL-Anweisungen gestattet. Verwenden Sie kein Tool, das auf Objekten höherer Ebene basierende SQL-Anweisungen transparent erzeugt, wenn es nicht so entscheidende Funktionen wie Abfrageabbruch, Abfragezeitüberschreitung und vollständige Transaktionskontrolle zur Verfügung stellt. Es ist oft nicht möglich, eine gute Leistung aufrechtzuerhalten oder Leistungsprobleme zu lösen, wenn die Anwendung unabhängig "transparentes SQL" erzeugt, da dies keine explizite Kontrolle über Transaktions- und Sperrkriterien gestattet, die für das Leistungsbild entscheidend sind.
  • Vermischen Sie keine Abfragen zur Unterstützung von Entscheidungen mit OLTP-Abfragen (Online Transaction Processing).
  • Entwerfen Sie keine Anwendung oder verwenden Sie keine betriebsfertige Anwendung, durch die der Benutzer gezwungen wird, den Client-Computer neu zu starten, um eine Abfrage abzubrechen. Dies kann eine Reihe von Leistungsproblemen hervorrufen, die aufgrund möglicher verwaister Verbindungen schwierig zu lösen sind. Weitere Informationen zu diesem Thema finden Sie in dem folgenden Artikel der Microsoft Knowledge Base:
       ARTIKEL-NR: Q137983
       TITEL     : How to Troubleshoot Orphaned Connections in SQL Server
  • Die Weiterführung dieses Artikels finden Sie in Teil 2: D36014
Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, daß nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachige(n) Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.

Eigenschaften

Artikel-ID: 110352 - Geändert am: Donnerstag, 8. Januar 2004 - Version: 3.0
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Keywords: 
kbother KB110352
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.
Disclaimer zu nicht mehr gepflegten KB-Inhalten
Dieser Artikel wurde für Produkte verfasst, für die Microsoft keinen Support mehr anbietet. Der Artikel wird deshalb in der vorliegenden Form bereitgestellt und nicht mehr weiter aktualisiert.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com