SQL Server - Temporäre oder physische Tabellen

14

An meiner Arbeitsstelle ist eine Bewegung im Gange, um von der Verwendung von # temporären Tabellen abzurücken und stattdessen permanente physische Tabellen mit SPIDs zu verwenden. Wann immer man zuvor IN eine #temp-Tabelle eingefügt hatte, ist jetzt eine INSERT INTO dbo.MyPermanentTable (SPID, ...) VALUES (@@SPID, ...)erforderlich - zusammen mit einer Reihe von DELETE FROM dbo.MyPermanentTable WHERE SPID = @@SPIDAnweisungen am Anfang zB einer gespeicherten Prozedur. Darüber hinaus ist es selbstverständlich, dass überall, wo diese "permanenten Tabellen zum Speichern temporärer Daten" verwendet werden, darauf geachtet werden muss, a einzuschließen WHERE SPID = @@SPID.

Die Logik hinter dieser Vorgehensweise besteht darin, die Gesamtleistung des Servers zu verbessern, auf dem die Abfragen ausgeführt werden (indem E / A und Konflikte in Tempdb reduziert werden). Ich bin aus mehreren Gründen nicht an diesem Ansatz interessiert - er ist hässlich, potenziell gefährlich und scheint die Leistung der Abfragen zu beeinträchtigen, die das neue Schema verwenden.

Hat jemand Erfahrung mit diesem oder ähnlichen Ansätzen zum Entfernen von # temporären Tabellen?

sql-server performance

— Will A
quelle

18

Es kann ziemlich leicht gezeigt werden, dass es nicht IO oder Konkurrenz reduziert, sondern beide erhöht .

IO : Jede Zeile, die in eine #temp-Tabelle eingefügt, daraus gelesen oder daraus gelöscht wird, wird nun in die @@ SPID-Tabelle eingefügt, daraus gelesen oder daraus gelöscht. Jede Zeile wird jedoch mit einer zusätzlichen @@ SPID-Spalte breiter, sodass sich die Anzahl der benötigten Seiten geringfügig erhöht und der E / A-Aufwand noch geringfügig zunimmt. Wichtiger ist jedoch, dass das Löschen einer #temp-Tabelle und das Initialisieren der #temp-Tabelle einer neuen Sitzung durch eine Sitzung nun mit einem simuliert werden DELETE FROM @@spidTable WHERE spid = @@SPIDmuss und somit die Kürzungs- / Erstellungsoperation (dh Seitenumfangsverwaltungsoperationen) transformiert wird im reihenbetrieb unvergleichlich langsamer.
Streit : Bei jedem Scan, bei dem Seitensperren für die Tabelle #temp verwendet wurden, kann jetzt eine Seite mit nicht verwandten spid-Zeilen gesperrt werden, wodurch zuvor nicht vorhandene Konflikte entstehen. Jedes Update, das mehr tut, als den Schwellenwert für die Sperreneskalation überschreitet, hat die Möglichkeit, die Sperre auf die Tabellensperre zu eskalieren und somit alle anderen Spids zu blockieren.

Während es stimmt, dass Sie die mythische IAM / SGAM / GAM-Konkurrenz in Tempdb nicht treffen werden, ist der einzige Grund, warum dies passieren würde, dass Ihre Operationen aufgrund gewöhnlicher zusätzlicher E / A und zusätzlicher Konkurrenz viel langsamer werden.

— Remus Rusanu
quelle

Ich stimme Remus voll und ganz zu - und danke für die hervorragende Resonanz. Das Problem ist, dass wir einen vermeintlichen Leistungseinbruch bei Anwendungen von Drittanbietern verursachen (mit mehreren Datenbanken auf einem Server, auf dem wir eine eigene Datenbank haben - wir müssen Abfragen im Vergleich zu deren Daten durchführen). Ich denke immer noch, dass Sie Recht haben, egal, was ich denke, ich würde davon ausgehen, dass der neue Ansatz erheblich schlechter abschneidet als zuvor. In Bezug auf Konflikte werden die Dinge aus Sicht der Zeit besser sein - aus unserer Sicht etwas schlechter.

— Will A

Wie viele Tempdb-Dateien haben Sie? Das Standard-Setup ist überhaupt nicht skalierbar - Sie sollten mehrere temporäre Datenbank- und Protokolldateien haben, eine pro sichtbarem Prozessorkern (jeweils 2, wenn Hyper-V).

— TomTom

1

Sie müssen diese beiden Artikel lesen: sqlskills.com/BLOGS/PAUL/post/… und sqlskills.com/BLOGS/PAUL/post/…, da sie die häufigsten Probleme mit der Tempdb-Skalierbarkeit beheben.

— Remus Rusanu

@ TomTom whoa, whoa. Mehrere Protokolldateien? "Ja wirklich?"

— Aaron Bertrand

5

Dies scheint eine drastische Lösung zu sein. Es sind viele Artikel online über das Reduzieren von Tempdb-Konflikten (und das Optimieren ihrer Verwendung). Hat Ihre Organisation diese Möglichkeit gründlich untersucht?

http://www.sql-server-performance.com/tips/tempdb_p1.aspx

http://www.sqlservercentral.com/blogs/robert_davis/archive/2010/03/05/Breaking-Down-TempDB-Contention.aspx

http://searchsqlserver.techtarget.com/tip/Optimize-tempdb-in-SQL-Server-by-striping-and-splitting-to-multiple-files

etc.

+1 stimme vollkommen zu - optimiere Tempdb, erfinde das Rad nicht neu, da deine Implementierung schlechter wird. :)

Ich bin alle dafür, dass ich diesen Weg nicht eingeschlagen habe, wenn es nicht gerechtfertigt ist - danke für die Information, Ben - ich werde nachforschen und unserem DBA gegebenenfalls Vorschläge unterbreiten.

— Will A

2

Klingt für mich wie sollten Sie die Performance - Probleme innerhalb tempDB werden zur Fehlerbehebung gibt ein paar Vorschläge ist in hier

— SPE109
quelle

Sieht nützlich aus - danke SPE109, ich werde dies überprüfen und Empfehlungen an unseren Datenbankadministrator richten.

— Will A