Wie die Leistung in SQL Server-Tabelle zu verbessern, mit Bildfeldern?

Question

Ich bin bei der Arbeit ein ganz besonderes Performance-Problem zu haben!

Im System wir benutzen es gibt eine Tabelle, die Informationen über den aktuellen Workflow-Prozess hält. Eines der Felder enthält eine Tabelle, die Metadaten über das Verfahren enthält (fragen Sie mich nicht, warum !! und nein, ich kann es nicht ändern IT !!)

Das Problem ist, dass diese Tabelle in einem Bildfeld in einem SQL Server 2005 (in einer Datenbank Set mit SQL 2000-Kompatibilität) gespeichert ist.

Diese Tabelle hat derzeit 22K + Linien und sogar eine einfache Abfrage wie folgt:

SELECT TOP 100 *
  FROM OFFENDING_TABLE

dauert 30 Sekunden, um die Daten in Query Analyzer abgerufen werden.

Ich denke an die Kompatibilität zu SQL 2005 zu aktualisieren (einmal, dass ich informiert wurde, dass der App kann damit umgehen).

Das zweite, was ich denken bin, ist der Datentyp der Spalte varbinary(max) zu ändern, aber ich weiß nicht, ob dies tun wird die Anwendung beeinflussen.

Eine andere Sache, dass ich überlege, ist sp_tableoption zu verwenden, um die large value types out of row zu 1 zu setzen, wie es zur Zeit 0, aber ich habe keine Informationen, wenn diese Leistung verbessern tun.

Wer weiß, wie die Leistung in einem solchen Szenario verbessern?

---

Edited zu klären

Mein Problem ist, dass ich keine Kontrolle darüber, was die Anwendung fragt nach dem SQL Server, und ich habe auf sie eine Reflexion (die App ist eine .NET 1.1-Website) und verwendet die problematische Feld für einige interne Sachen, die ich haben keine Ahnung, was es ist.

Ich brauche die gesamte Leistung dieser Tabelle zu verbessern.

Answer 1

Ich würde empfehlen, schauen Sie in die betreffenden Tabellenlayout Gesundheit:

select * from sys.dm_db_index_physical_stats(
       db_id(), object_id('offending_table'), null, null, detailed);

Dinge zu suchen sind avg_fragmentation_in_percent, PAGE_COUNT, avg_page_space_used_in_percent, Record_Count und ghost_record_count. Cues wie hohe Fragmentierung, oder eine hohe Anzahl von Geisterdatensätzen oder einer niedrigen Seite verwendet Prozent weisen auf Probleme und die Dinge können durch den Wiederaufbau der Index ziemlich viel nur verbessert werden, von Grund auf neu (dh der Tabelle.):

ALTER INDEX ALL ON offending_table REBUILD;

Ich sage dies bedenkt, dass Sie nicht in der Tabelle noch die App ändern können. Wenn Sie in der Lage sein würde, um die Tabelle und die App zu ändern, wird der Rat, den Sie bereits bekommen ist ein guter Rat (nicht verwenden ‚*‘, nicht‘wählen w / oa Bedingung, verwenden Sie die neuere varbinary (max) Typ etc etc) .

Ich würde auch die durchschnittliche Seite Lebensdauer in Leistungsindikatoren sieht in zu verstehen, wenn der Systemspeicher verhungert ist. Aus Ihrer Beschreibung der symptomps sucht das System IO gebunden Das führt mich zu denken, ist wenig Seiten-Caching geht, und mehr RAM könnte, sowie ein schnelleres IO-Subsystem helfen. Auf einem SQL 2008-System würde ich auch empfehlen, drehe Seite Kompression auf, aber auf 2005 kann man nicht.
Und, nur um sicher zu sein, stellen Sie sicher, dass die Anfragen nicht durch Konkurrenz aus der App selbst gesperrt, dh. wird die Abfrage nicht mehr als 90% dieser 30 Sekunden ausgeben für eine Reihe Sperre warten. Schauen Sie sich sys.dm_exec_requests , während die Abfrage ausgeführt wird, finden Sie in der wait_time , Wait_type und wait_resource. Ist es PAGEIOLATCH_XX? Oder ist es ein Schloss? Auch, wie ist das sys.dm_os_wait_stats in Ihrem Server, was top Warte Gründe?

Answer 2

Zu allererst - Sie jemals nicht SELECT * tun in der Produktion Code - Berichterstattung oder nicht.

Sie haben drei grundlegende Möglichkeiten:

• bewegen, dass BLOB-Feld in eine separate Tabelle, wenn es nicht immer gebraucht wird; wahrscheinlich nicht praktisch, da Sie erwähnen Sie können das Schema ändern

• vorsichtiger sein mit Ihren SELECT Aussagen nur die Felder auszuwählen, die Sie wirklich brauchen - und lassen Sie das BLOB-Feld

• Sie, ob Sie Ihre Abfrage beschränken können eine WHERE Klausel aufzunehmen, und einen Weg finden, den Abfrageplan zum Beispiel durch Optimierung einen geeigneten Index zu der Tabelle hinzugefügt (wenn Sie können)

Es gibt keine magischen „machen diesen schnellen“ -Schalter - aber Sie können Ihre Abfrage optimieren oder Ihr Tabellenlayout optimieren. Beide Hilfe. Wenn Sie nichts ändern können - weder das Tabellenlayout, noch einen Index hinzufügen, noch die Abfragen ändern, haben Sie eine harte Zeit, etwas zu optimieren, ich habe Angst ....

Sie einfach das Feld Ändern zu VARBINARY (MAX) wird gar nichts ändern -. Keine Leistungssteigerung nur zu erwarten, von dem Datentyp zu ändern

Answer 3

Eine kurze Antwort ist nur tun SELECTs gegen mehrere Zeilen, wenn die Felder zurück enthält nicht beleidigen Bildfeld, also keinen SELECT *. Wenn Sie den Wert des Bildfeldes möchten, rufen Sie es auf einer Fall-zu-Fall-Basis.

Answer 4

Einstellen der großen Werttypen aus Zeilenoption sollte auf jeden Fall die Leistung zu helfen. Die Zeilengröße wird deutlich kleiner, SQL Server viel weniger physische tun können, liest throught den Tisch zu bekommen.