Leistungsproblem mit 8 verschachtelten gespeicherten Prozeduren

Question

Ich habe ein Leistungsproblem
Ich muss eine gespeicherte Prozedur von .NET 1.1 ausführen. Diese gespeicherte Prozedur ruft 8 Stored Procedures auf. Jeder von ihnen verarbeitet Informationen, um einen Vergleich zwischen alten und neuen Informationen zu erstellen und die physische Tabelle in DataBase zu beeinflussen.

Das Problem kommt, da ich versuche, es direkt von SSMS auszuführen. Server stürzen ab, werden so langsam und fast unmöglich zu arbeiten. Ich denke, Infrastruktur-Leute müssen den Dienst direkt auf dem Server wiederherstellen.

Ich arbeite in Entwicklungsumgebung, so gibt es kein großes Problem, aber ich kann dies nicht in Produktionsumgebung hochladen.

Ich habe in Verwendung Verfahren nur zu Vergleichszwecken gedacht und beeinflussen nie physikalische Daten. Erhalte Informationen von ihnen in Temporären Tabellen in der Prinzipalprozedur und öffne dann meine Try-Catch- und Begin-End-Transaktionsblöcke und beeinflusse die Datenbank in meinem Principal, die mit der Information in Temp-Tabellen gespeichert ist.

Meine wichtigsten gespeicherten aussehen wie folgt: Ist das der beste Weg, ich kann dies tun?

create proc spTest
as
/*Some processes here, temporary tables, etc...*/
begin try
begin distributed transaction
sp_nested1
sp_nested2
sp_nested3
sp_nested4
sp_nested5
sp_nested6
sp_nested7
sp_nested8
/*more processes here, updates, deletes, extra inserts, etc...*/
commit transaction
end try
begin catch
rollback transaction
DECLARE @ERROR VARCHAR(3000)
SELECT @ERROR = CONVERT(VARCHAR(3000),ERROR_MESSAGE())
RAISERROR(@ERROR,16,32)

end catch

Die Grundstruktur jedes verschachtelte gespeicherte Prozedur ähnlich ist, aber nicht nennen andere proc, nur jeder hat seinen eigenen Versuch und Catch-Blöcke.

Jede Hilfe wird sehr geschätzt werden ... Die Version Im SQL Server 2005 ist

Ihnen allen im Voraus Danke ....

Answer 1

Zuerst, wenn die Dinge langsam sind, ist es wahrscheinlich ein Problem in was du geschrieben hast. Der erste zu untersuchende Ort ist der Ausführungsplan jedes gespeicherten Proc. Haben Sie Table Scans?

Haben Sie jeden einzeln ausgeführt und gesehen, wie schnell jeder ist? Dies würde Ihnen helfen zu definieren, ob das Problem die 8 Procs oder etwas anderes ist.Sie scheinen eine Menge Schritte dabei zu haben, die Procs sind vielleicht sogar das Problem.

Verarbeiten Sie Daten zeilenweise mit einem Cursor, einer While-Schleife oder einem Skalar Benutzerdefinierte Funktion oder korrelierte Unterabfrage? Dies kann die Geschwindigkeit stark beeinflussen. Hast du die richtige Indizierung? Sind Ihre Abfrageanweisungen sargable? Ich sehe, dass Sie eine verteilte Transaktion haben, sind Sie sicher, dass der Benutzer, der den Proc ausführt, die richtigen Rechte auf anderen Servern hat? Und dass die Server existieren und laufen? Geht dir in der temp db der Platz aus? Müssen Sie dies in Batches ausführen, anstatt zu versuchen, Millionen von Datensätzen auf mehreren Servern zu aktualisieren?

Ohne dieses Chaos zu sehen, ist es schwer zu bestimmen, was die Ursache dafür sein könnte, dass es langsamer wird.

Aber ich werde teilen, wie ich mit langen komplexen Procs arbeite. Zuerst haben sie alle eine Testvariable, die ich benutze, um die Transaktionen am Ende zurückzusetzen, bis ich sicher bin, dass ich die richtigen Aktionen durchführe. Ich gebe auch die Ergebnisse dessen zurück, was ich eingefügt habe, bevor ich das Rollback durchführe. Das wird dem Geschwindigkeitsproblem zunächst nicht helfen. Aber stellen Sie es trotzdem auf, denn wenn Sie nicht herausfinden, was das Problem aus dem Ausführungsplan sein würde, dann sollten Sie wahrscheinlich alles außer dem ersten Schritt auskommentieren und dann den Proc im Testmodus (und Rollback) ausführen fügen Sie weitere Schritte hinzu, bis Sie den Punkt sehen, an dem es hängen bleibt. Natürlich kann es mehr als eins sein.