SQL – Fragen und Antworten: Auf der Suche nach Leistung

  • Artikel

Verringerung der Arbeitsbelastung und Spiegelung Funktionen Glätten ist immer eine gute Idee — aber Verkleinern von Datenbanken ist nicht.

Paul S. Randal

Arbeitslast Abhilfe

F: Ich arbeite mit einem Team von Entwicklern, die eine Anwendung verwenden SQL Server zum Speichern von Daten ändern. Die Daten wurde zuvor auf Client-Rechnern lokal gespeichert. Können Sie mir eine Liste der Überlegungen für die Entwickler so dass sie die am wenigsten-möglich Höhe der Arbeitsauslastung zu SQL Server fahren können?

**A.**Durch das Streben, die Anwendung der Datenebene rufen Sie so wenig wie möglich zu machen, nehmen Sie einen hervorragenden Ansatz. Schwerpunkt der Anwendungdes ist leider atypisch. Primär zu berücksichtigen, ist die Anwendung zum Abrufen von Daten aus SQL Server so wenig wie möglich sein. Wenn es Daten abrufen, haben Sie es nur Abrufen der Daten, die sie so effizient wie möglich benötigt.

Hier sind einige Dinge für Ihre Entwickler bei der Art und Weise zu beachten, in denen die Anwendung SQL Server Daten abfragt. Aufmerksamkeit auf diese unnötige Arbeitsbelastung und negative Auswirkungen auf die CPU, Speicher und i/o vermeiden:

  • **Wird verarbeitet:**Für die Daten, die vom SQL Server eingezogen werden, sollten die Anwendung die Daten zeilenweise Verarbeitung, zu einem Zeitpunkt vermeiden. Dies nennt man gemeinhin RBAR, oder --qualvollen-zeilenweise, Verarbeitung. Jedes Mal, wenn SQL Server Daten an die Anwendung sendet, hat es einen Thread, wartet die Anwendung, die durch gesendeten Daten zu bestätigen. RBAR Verarbeitung führen zu hohen ASYNC_NETWORK_IO wartet in SQL Server. Die Anwendung sollte eingehende Daten lokal zwischengespeichert und schnell Antworten zurück zu SQL Server die Daten hat.
  • **Filterung:**Filtern von Daten vor dem lokal verwenden oder anzeigen, dass die Daten vermeiden die Anwendung. Es ist sehr viel effizienter zu schieben das Filterprädikat bis auf SQL Server und haben die Mindestmenge an Daten an die Anwendung zurückgegeben. SQL Server ist sehr gut bei Filtern von Daten, gegeben die richtige nicht gruppierte Indizes, die Filterprädikate zu unterstützen.
  • **One Size Fits All (OSFA):**Minimieren Sie die Spalten der Tabelle zurückgegeben wird, nur die notwendigen. Entwickler sollten auch versuchen, einen "one Size fits all" Dialog aufzubauen. Mit eine gezielte Auswahlliste anstelle von SELECT * wird reduzieren die Menge an Daten verarbeitet und zurückgegeben. Mit weniger Spalten angefordert möglicherweise SQL Server weitere optimale Wege, um auf diese Daten, die Leistung verbessern würde.
  • **Bestellung:**Wenn die zurückgegebenen Daten nicht mit ORDER BY sortiert werden müssen, dann vermeiden Sie ORDER BY angeben, da dies einen Sortiervorgang Ausschneiden kann. Sortieroperationen können oft teuer, da sie am Ende eine kostspielige Art-verschütten in Tempdb erfordern.
  • **Nur für den Fall:**SELECT-Operationen zu verschieben, bis sie wirklich erforderlich sind. Wenn eine Anwendung eine SELECT-Anweisung nur für den Fall ausgibt, klickt der Benutzer auf eine Anwendungsschaltfläche. Dann könnte es verschwendet werden verarbeitet. Es ist besser zu warten, bis der Knopf gedrückt tatsächlich vor der Ausgabe auswählen, entfernen alle verarbeiten, wenn die Taste nicht gedrückt ist.
  • **Betrachten Sie das Zwischenspeichern:**Wenn Sie immer wieder die gleichen Daten Abfragen sind, lokal zwischenzuspeichern Sie und stellen Sie einer neuen SELECT nur aus, wenn sich die Daten ändern. Dies ist ideal, wenn die Daten sich nicht häufig ändern oder wenn Sie minutengenaue Daten nicht erforderlich.

Unter Berücksichtigung dieser Faktoren haben tiefgreifende Auswirkungen auf die Menge an Arbeit, die SQL Server hat zu tun, vor allem, wenn eine einzelne Änderung in der Anwendungslogik Abfrage mit Hunderten oder Tausenden von Instanzen der Anwendung gleichzeitig ausgeführte multipliziert wird.

Fragen Sie Ihr Entwicklungsteam Anwendung überprüfen, wie die Anwendung SQL Server verwendet wird. Dies könnte Ihre vorhandenen Arbeitslast sehr profitieren. Die eigentliche Ursache für Leistungsprobleme wird allzu oft als SQL Server, anstatt die Art und Weise werden die Anwendung SQL Server verwendet wird.

Spieglein, Spieglein

F: Wir habe seit mehreren Jahren die Datenbankspiegelung verwendet. Erst in jüngster Zeit haben wir keine Probleme gehabt. Wir einen Failover durchgeführt und die Spiegeldatenbank dauerte mehrere Stunden online, kommen die war völlig unerwartet. Gibt es Leistungsindikatoren überwachen wir können um zu sagen, ob dies wieder auftreten?

**A.**Datenbankspiegelung ist sehr beliebt geworden, da es korrekt in SQL Server 2005 SP1 eingeführt wurde. Allerdings gibt es ein weit verbreitetes Problem auf Client-Systemen. Es scheint eine Annahme, dass, sobald Sie die Datenbankspiegelung implementieren, können Sie sicher es vergessen und auf es perfekt funktioniert bauen, wenn ein Fehler auftritt – er holt die geschützte Datenbank online immer auf dem Spiegelserver ohne Verlust von Daten und minimaler Ausfallzeit.

Während dies in einigen Fällen wahr sein könnte, ist es eine gefährliche Annahme. Um das Potenzial für eine Katastrophe zu reduzieren, ist es unbedingt erforderlich, die Größe des SEND sowohl die REDO-Warteschlange einer Spiegelungssitzung überwachen:

  • Die Größe der Warteschlange senden zeigt wieviel Transaktionsprotokoll auf dem Prinzipalserver generiert wurde, aber noch nicht an den Spiegelserver gesendet wurde. Wenn es nicht NULL ist, bedeutet dies der Spiegelungsstatus ist nicht synchronisiert und es nicht nur ein automatisches Failover. Darüber hinaus gibt die Größe der Sendewarteschlange den Betrag von Datenverlust, die stattfindet, wenn die Prinzipaldatenbank eine Katastrophe aufweist. Sie überwachen, um sicherzustellen, der Größe der Sendewarteschlange nicht überschreitet die maximale zulässige Datenverlust Service Level Agreement (SLA) müssen — oder Recovery Point Objective (RPO) — für die Datenbank gespiegelt wird.
  • Die REDO-Warteschlangenlänge zeigt wieviel Transaktionsprotokoll in der Spiegeldatenbank vorhanden ist, die noch in der Spiegeldatenbank wiedergegeben wurden, noch nicht. Denken Sie daran, dass Protokolldatensätze nur noch gehärtet werden — nicht wiedergegeben — auf die Spiegeldatenbank auf dem Laufwerk. Das geschieht als ein kontinuierlicher Prozess auf dem Spiegelserver. Wenn ein Datenbankspiegelungs-Failover auftritt, können nicht Sie die Spiegeldatenbank zugreifen, bis alle Protokolleinträge der Transaktion in der Wiederholungswarteschlange der Spiegeldatenbank wiedergegeben wurden. Dies bedeutet, dass die Wiederherstellung nach eine Systemabsturz zu erfolgen hat. Je größer die Wiederholungswarteschlange, je länger ein Failover dauert. Denken Sie daran, dass in der Enterprise Edition, schnelle Wiederherstellung ins Spiel kommt, und die Datenbank verfügbar, wird nachdem die Rollforwardphase der Wiederherstellung ist abgeschlossen, aber bevor die UNDO Phase beginnt. Sie überwachen, um die Größe der Wiederholungswarteschlange nicht überschreiten Ihre maximale zulässige Ausfallzeit SLA gewährleisten müssen — oder Recovery Time Objective (RTO) — für die Datenbank gespiegelt wird.

Die älteste, nicht gesendete Transaktion ist eine weitere Möglichkeit, den momentanen Datenverlust überwachen, die, den Sie im Katastrophenfall Prinzipaldatenbank leiden würde. Es gilt in allen Modi der Datenbankspiegelung, denn selbst wenn Sie synchrone Spiegelung verwenden, der Prinzipal und der Spiegel getrennt werden können oder Sie möglicherweise angehalten, Spiegelung.

Sie können überwachen die Warteschlangen senden und "Wiederherstellen" mit dem Datenbankspiegelungs-Monitor in SQL Server Management Studio Benachrichtigungen festlegen. Sie können auch direkt mit die Datenbankspiegelung Objektleistungsindikatoren Protokoll senden Warteschlange KB und Redo Queue KB überwachen.

Wenn Sie die wachsende Größe die REDO finden, bedeutet dies, dass der Spiegelserver mit der Umfang des Protokolls gesendet wird aus dem Prinzipalserver nicht mithalten kann. Es könnte sein, dass es zusätzliche Arbeitsbelastung auf dem Spiegelungs-Server, der das Protokoll das Spiegel verhindert so schnell wie möglich wiedergeben. Es kann auch sein, dass die physische Hardware auf dem Spiegelserver ist genauso gut wie die, die auf dem Prinzipalserver nicht.

Bis zu verkleinern

F: Einer der Anbieter von Anwendungen ist vorzuschreiben, dass wir regelmäßige Datenbank-Konsistenzüberprüfung (DBCC) SHRINKDATABASE Operationen gegen den Anwendungsdatenbanken und Tempdb laufen. Der Hersteller besteht darauf, dass dies für die ordnungsgemäße Ausführung zu pflegen ist. Können Sie mir einen Rat geben?

**A.**Diese Frage kommt ziemlich regelmäßig. Ein Hersteller der Anwendung möglicherweise nicht zulassen, dass Sie regelmäßige Verkleinerungsvorgänge zu entfernen, denn sie sind als "notwendig für die Leistung." Verkleinern von Datenbanken Indexfragmentierung verursacht, verbraucht viel CPU und i/o-Ressourcen. Es erzeugt auch eine Menge des Transaktionsprotokolls. Dadurch können Probleme für die Datenbankspiegelung AlwaysOn Availability Groups, Replikation und alles andere, das Schiff Protokolldatensätze herum. Gibt es jedoch einige Umstände in denen einmalige Verkleinerungsvorgänge erforderlich sind.

Datenbanken sollten nie regelmäßig verkleinert werden. Regelmäßig Verkleinern von Datenbanken ist etwas Schlechtes zu tun, denn wenn die Datenbank wächst immer wieder nach verkleinert wird, ist alles, was Arbeit schrumpfen völlig vergebliche Mühe. Es ist verwandt mit automatische Verkleinerung für die Datenbank aktiviert.

Viele Anbieter Anwendung Teams wissen nicht, dass diese Dinge zu verkleinern. Dies ist häufig, da sie die Anwendung aus einer anderen Datenbanksystem portiert haben und ungern auf jeden, der versucht, sie zu erziehen, zur Funktionsweise von SQL Server zu hören sind.

Ich werde gelegentlich mit einem Client und die Anwendung Hersteller Team beteiligt. Die Nachweise vom Hersteller Anwendungsteam sind in der Regel nach dem Vorbild der folgenden (paraphrasieren):

  • Die Indizes in der Datenbank sind bereits fragmentiert, so schrumpft es irgendwie schlechter nicht.
  • Niemand jemals beschwerten sich über Leistung vor, also warum bist du?
  • Wir haben ein regelmäßiger schrumpfen zu haben, weil die Operationen wir die Datenbank führen um einiges zu erweitern und Kunden ihre Speicherplatz zurück wollen.
  • Wir haben Tempdb verkleinern, da die Vorgänge verursachen wir es kontinuierlich wachsen.

Keine von diesen sind stichhaltige Gründe für die regelmäßig Verkleinern von Datenbanken. In der Tat, es ist dokumentiert, Knowledge Base-Artikel 307487 , dass Tempdb verkleinern, wenn Benutzeraktivitäten zu Tempdb Korruption führen kann. Auch die "Arbeiten mit Tempdb in SQL Server 2005" Weißbuch (gilt für alle Versionen) heißt es: "Verkleinern von Dateien wird nicht empfohlen."

Jedes Mal, wenn ein Hersteller behauptet, dass schrumpfende notwendig ist, zeigt es, dass entweder ein grundlegendes Missverständnis wie Sie SQL Server oder ein Fehler in das Verhalten der Anwendung verwalten sollte durch regelmäßige schrumpfen vertuscht. Die beste Möglichkeit, mit Anbietern zu engagieren, die regelmäßige schrumpfen Mandat ist sie auf den Microsoft KB-Artikel oder Whitepaper zeigen. Dann können nicht sie argumentieren, dass sie an best Practices von Microsoft fest sind.

Leider gibt es keine Möglichkeit, Verkleinerungsvorgänge zu verhindern, wenn sie Anbieter-beauftragt sind. Entfernen den Verkleinerungsvorgang würde einen Support-Vertrag ungültig. Das beste was, das man tun könnte, ist ein SQL Server Agent-Auftrag haben, die ausgeführt wird alle 15 Sekunden auf der Suche nach Verbindungen, die Datenbanken schrumpfen und dann töten. Einen Verkleinerungsvorgang töten wird nicht Korruption oder andere Probleme verursachen. Dieser Ansatz könnte helfen, Sie bleiben innerhalb der Support-Vereinbarung, während auch Performance-Probleme auf dem Produktionsserver zu verhindern.

Paul S. Randal

Paul S. Randal ist der Geschäftsführer der SQLskills.com, Microsoft regional Director und SQL Server MVP. Er arbeitete an der SQL Server-Speicher-Engine-Team bei Microsoft von 1999 bis 2007. Er schrieb DBCC CHECKDB/Repair für SQL Server 2005 und war verantwortlich für das Kernspeichermodul während der Entwicklung von SQL Server 2008. Randal ist Experte für Disaster Recovery, hohe Verfügbarkeit und Datenbankwartung und ein regelmäßiger Referent auf Konferenzen weltweit. Er Blogs auf SQLskills.com/blogs/paul, und Sie finden ihn auf Twitter bei twitter.com/PaulRandal.

Verwandte Inhalte