2016-07-24 34 views
0

Wir haben eine gespeicherte Prozedur, die von einem täglichen Jobplan aufgerufen wird, der innerhalb eines angemessenen Zeitrahmens arbeitete, aber jetzt sehr schlecht funktioniert und fehlschlägt. Was auch immer die Ursache ist, es scheint auch unser gesamtes System zu zerstören. Wir haben versucht, den Computer neu zu starten, aber das Problem ist weiterhin aufgetreten.SQL Server geplante gespeicherte Prozedur funktionierte, aber jetzt sehr langsam

Die gespeicherte Prozedur dient als ETL, um Daten von einer Datenbank in eine andere zu importieren und einige Aktualisierungen vorzunehmen. Wenn es vom Job aufgerufen wurde, lief es innerhalb einer Stunde, aber vor ungefähr 7 Tagen dauerte es 10-15 Stunden, um es zu starten. Dann die letzten 3 Tage ist es insgesamt gescheitert. Heute habe ich es 10 Stunden laufen lassen und dann abgebrochen.

Die Fehlermeldung für die fehlgeschlagenen Läufe hat festgestellt, dass sie fehlgeschlagen ist, da in der Protokolldatei kein Speicherplatz mehr verfügbar ist. Also habe ich versucht, die Protokolldatei mit dem folgenden Code zu verkleinern. Es hat funktioniert, aber es hat die Dateigröße überhaupt nicht verringert. Da der Code nicht funktioniert hat, hat ich versucht, SSMS Schrumpfung verwenden, aber das konnte aufgrund des Fehler:

Lock request time out period exceeded

Ich lief sp_who2 und, ohne sicher zu wissen (Ich bin ein Entwickler kein DBA), gefunden die folgende, die relevant schien:

SPID: 63, Status: Suspended, Command: Delete, CPU Time: 1142382, DiskIO: 1254258

dachte ich, dass das Problem sein könnte, so habe ich versucht, diese Transaktion Kill 63 mit zu beenden. Allerdings scheint es, dass nicht, weil nicht funktionierte, wenn ich sp_who2 laufe jetzt liest er

SPID: 63, Status: Suspended, Command: Killed/Rollback, CPU Time: 1142803, DiskIO: 1261601

Jede Hilfe des Problem zu beheben, würde geschätzt! Speziell:

  1. Irgendwelche Ideen, was die schlechte Leistung plötzlich verursachen könnte?

  2. Wie kann ich die Protokolldatei verkleinern? Könnte das die schlechte Leistung verursachen?

Hier ist der Code, den ich versucht:

USE MyDatabase; 
GO 

ALTER DATABASE MyDatabase 
SET RECOVERY SIMPLE; 
GO 

DBCC SHRINKFILE (MyDatabase_log, 1); 
GO 

ALTER DATABASE MyDatabase 
SET RECOVERY FULL; 
GO 
+1

Obwohl es viele Leute mit DB-Wissen hier auf SO gibt, haben Sie vielleicht mehr Glück auf [dba.se] zu fragen, da diese Seite möglicherweise mehr auf nicht entwicklungsbezogene Aspekte fokussiert ist. – jpw

+1

Die Informationen, die Sie gaben, ist nicht sehr hilfreich..Please Ausführungsplan von gespeicherten proc.also versuchen Sie aktualisieren Statistiken der Objekte in gespeicherten Proc ... Post Ihre sql-Version.Meistens sehen Sie hier und sehen, wie man fragt und Hilfe bekommen schnell. Obwohl es ein tsql-Format ist, versuchen Sie, die Essenz zu verstehen..https: //spaghettidba.com/2015/04/24/how-to-post-at-sql-question-on-a-public-forum/ – TheGameiswar

+0

Sie müssen sehen, ob die Daten, die mit Ihren Abfragen verknüpft sind, zugenommen haben. Wenn Sie sich "lang laufende Abfragen" ansehen, können Sie möglicherweise einige Trends sehen - oder zumindest ausführen (wenn sie Daten lesen) und dann Ihre Server-Statistiken und die zugrunde liegende Hardware überwachen. –

Antwort

0

Dieses endete Problem eine Festplatte ist. Anfangs bestand das Hardware-Team darauf, dass es nicht war, aber nach weiteren Tests und Reviews war es tatsächlich eine schlechte Festplatte.