Suchen Sie nach Prozeduren, die seit <n> Tagen nicht mehr aufgerufen wurden


7

Wir löschen alte gespeicherte Prozeduren und Tabellen.

Wie kann ich wissen, welche Verfahren in letzter Zeit nicht aufgerufen wurden?

dm_exec_procedure_statsund dm_exec_query_statssind nicht zuverlässig, da sie nur Prozeduren im Plan-Cache zurückgeben.


Haben Sie versucht, Ihren Quellcode nach jedem Prozedurnamen zu durchsuchen?
Jon Seigel

2
@ JonSeigel das wird nicht wirklich helfen; Eine Prozedur kann sich im Quellcode einer Methode befinden, die Benutzer nicht sehr oft aufrufen. Das können Sie dem Quellcode nicht entnehmen.
Aaron Bertrand

3
@ Aaron: Selten! = Niemals, obwohl die Frage "vor kurzem" lautet, aber vielleicht unter der Annahme einer Lösung. Wenn ein bestimmter Name einer gespeicherten Prozedur nie im Quellcode gefunden wird, hilft das ziemlich viel.
Jon Seigel

1
@ JonSeigel das ist wahr, vorausgesetzt, niemand ruft jemals gespeicherte Prozeduren manuell auf. Es sind immer noch nicht genügend Informationen bekannt, um davon auszugehen, und selbst wenn dies angenommen wird, glaube ich nicht, dass ich mich guten Gewissens darauf verlassen kann.
Aaron Bertrand

1
@ Aaron: Das hängt auch stark von der Umgebung ab, also stimme ich Ihnen im Allgemeinen zu. Ich denke zumindest, wenn eine gespeicherte Prozedur oder ein Tabellenname in keinem Code vorkommt, ist dies ein sehr guter Hinweis darauf , dass das Objekt nicht verwendet wird. Ich nehme an, ein komplizierter Faktor wären frühere Versionen der Anwendung, wenn es sich um eine Herstelleranwendung handelt. Wieder situativ.
Jon Seigel

Antworten:


12

Wenn sys.dm_exec_procedure_statsdies für Sie nicht zuverlässig ist (wahrscheinlich mehr, weil die Informationen Neustarts nicht überleben als alles, was mit dem Plan-Cache zu tun hat), verfolgt SQL Server dies auf keine andere Weise.

Die einzige Möglichkeit, dies zu tun, besteht darin, Ihren gespeicherten Prozeduren (oder der App, die sie aufruft, wenn dies machbar und umfassend genug ist) eine Protokollierung hinzuzufügen oder eine sehr zielgerichtete serverseitige Ablaufverfolgung fortlaufend auszuführen und die Ablaufverfolgung zu überprüfen.

Beachten Sie auch, dass eine Prozedur, die in einer Woche nicht aufgerufen wurde, nicht bedeutet, dass sie morgen nicht aufgerufen wird. Möglicherweise haben Sie Berichterstattungsverfahren, die nur monatlich oder jährlich aufgerufen werden, oder obskure Vorgänge, die nicht sehr häufig vorkommen. Das Löschen dieser gespeicherten Prozedur kann in Tagen oder Wochen katastrophale Folgen haben, möglicherweise über jede Sicherung hinaus, die Sie zu diesem Zeitpunkt haben (und vorausgesetzt, Sie befolgen nicht die Best Practices und speichern Ihre gespeicherten Prozeduren in der Quellcodeverwaltung).

Der sicherste Weg, IMHO, besteht darin , gespeicherte Prozeduren (möglicherweise mit einem zzz_Präfix, damit sie am Ende aller Listen sortiert werden) umzubenennen , die Sie bereits auf andere Weise als potenzielle Kandidaten für "zu alt" identifiziert haben - zumindest dann, wenn Sie dies tun Wenn Sie dies versehentlich tun, und etwas kaputt geht, ist es einfach genug, es erneut umzubenennen und die Funktionalität wiederherzustellen, ohne in Backups nach altem Code suchen zu müssen. Nur löschen , die Verfahren , wenn ein Konjunkturzyklus durchlaufen hat und niemand beschwert hat.


Eigentlich ist es nicht zuverlässig, nicht weil es neu startet. Wir starten die Datenbank seit Monaten nicht mehr neu. Wenn ich diese Ansicht abfrage, wird nur der zuletzt zuletzt ausgeführte Prozess zurückgegeben, und ich weiß, dass einige Prozesse heute nicht ausgeführt wurden. MSDN sagt: "Die Ansicht gibt eine Zeile für jeden zwischengespeicherten Plan für gespeicherte Prozeduren zurück, und die Lebensdauer der Zeile ist so lange, wie die gespeicherte Prozedur zwischengespeichert bleibt"
Felipe Fujiy Pessoto

1
Wenn Sie nur Pläne für Prozeduren zwischenspeichern können, die heute ausgeführt wurden, ist Ihr Server entweder in Bezug auf den Arbeitsspeicher (entweder physisch oder künstlich über den maximalen Serverspeicher) extrem unterversorgt, oder Sie haben viel, viel, viel zu viele eindeutige Prozeduren angerufen und / oder ihre Pläne sind viel komplexer als sie sein sollten. Wie viel Speicher hat Ihr Server? Wie viele Pläne werden gleichzeitig zwischengespeichert?
Aaron Bertrand

Beachten Sie, dass, wenn Ihr Unternehmen etwas Ähnliches wie einen 4-4-5-Kalender verwendet , ein Geschäftszyklus in der Größenordnung von 5/6 Jahren liegen kann , wenn jedes Schaltjahr / jede Woche etwas ausgeführt wird.
Uhrwerk-Muse

6

Wenn Sie die Prozeduren ändern können, fügen Sie zu Beginn jeweils eine Zeile hinzu (dies ist ziemlich einfach zu automatisieren):

exec sp_trace_generateevent 82, N'<procedure__name>';

Die Verwendung sp_trace_generateeventist ziemlich harmlos und hat keinen Einfluss auf den Ablauf / das Ergebnis / das Ergebnis der Prozedurausführung. Am wichtigsten ist, dass es keine Interaktion mit der aktuellen Transaktion gibt. Eine schreibgeschützte Prozedur wird nicht in eine Datenschreibprozedur mit allen Auswirkungen auf die Protokollierung und Sperrung umgewandelt. Wenn es kein Trace-Überwachungsereignis 82 gibt, ist der execAnruf grundsätzlich kostenlos (no-op).

Erstellen Sie als Nächstes eine serverseitige Ablaufverfolgung und erfassen Sie das Ereignis 82 (das erste Benutzerereignis). Sammeln Sie nach n Tagen die generierten Spuren und aggregieren Sie die Nutzung. Stellen Sie sicher, dass Ihre Ablaufverfolgung auf eine Festplatte mit ausreichend Speicherplatz und ausreichender E / A-Bandbreite schreibt. Für zusätzliche Gutschrift können Sie die Traces auch regelmäßig überprüfen und Anrufe execaus allen dort gefundenen Verfahren entfernen , da nachweislich aufgerufen wird.


Welchen Vorteil hat es gegenüber der Einrichtung einer serverseitigen Ablaufverfolgung zur Erfassung aller RPC: Startereignisse (und nur zur Erfassung der Datenbank / des Namens), da hierfür alle Verfahren geändert werden müssen? Dass Sie nach einiger Zeit aufhören können, einige der Ereignisse zu erfassen? Ansonsten scheint es mehr Arbeit zu sein, als nur eine Ablaufverfolgung einzurichten.
Aaron Bertrand

1
@AaronBertrand: RPC: Beim Starten wird jedes RPC-Ereignis erfasst, z. B.: INSERT ... (@var), Das kein Prozeduraufruf ist. Und hat nicht einen Prozeduraufruf in einem Batch eingebettet erfassen, z. B. exec sp_foo 'bar'. Neben der Korrektheit kann die handgemachte Nachverfolgung offensichtlich bekannte, häufig genannte Verfahren eliminieren und sich nur auf diejenigen konzentrieren, bei denen der Verdacht besteht, dass sie niemals aufgerufen werden. Ich sehe viele Vorteile.
Remus Rusanu

Sie können nach Objektnamen filtern, um andere Nicht-Prozedur-Aufrufe sowie solche, von denen Sie wissen, dass sie verwendet werden, zu eliminieren. Und schließen Sie SP ein: Beginnen Sie, Dinge zu fangen, die Teil einer Charge sind. Ich denke immer noch, dass das viel einfacher ist. Denken Sie nicht, dass die Automatisierung dieser Änderung für jede auf dem System gespeicherte Prozedur so einfach ist, wie Sie sie vornehmen. Außerdem werden weitere Informationen zu den Prozeduren eliminiert, indem Sie "modify_date" überschreiben.
Aaron Bertrand

3

Zu wissen, was in letzter Zeit aufgerufen wurde, hilft nur bei häufig aufgerufenen Dingen, und viele Objekte in einer komplexen Datenbank werden nicht so oft aufgerufen, werden aber dennoch benötigt. Ich kenne keinen einfachen Weg, um festzustellen, was nicht verwendet wird.

Was ich tun würde, ist Profiler auf meiner Entwickler- oder QA-Box zu starten und dann jede Anwendung, die darauf trifft, zu nehmen und die Funktionalität auszuführen. (Wenn Sie eine formelle Qualitätssicherung haben, hilft eine gute Reihe von Regressionstests dabei). Ich würde meine Ablaufverfolgung so einrichten, dass sie in eine Tabelle schreibt. Jetzt wissen Sie zumindest, was die Anwendungen aufrufen, und können sie aus der Liste streichen.

Stellen Sie sicher, dass jeder Job auf dem Produktserver einen entsprechenden Job auf Ihrem Testserver hat, und führen Sie ihn aus. Das sollte noch mehr finden.

Inzwischen ist Ihre Liste potenzieller SPs viel kleiner.

Ihre Liste der aktiven Tabellen sollte nur diejenigen enthalten, die in einem der Prozesse und Tabellen aufgeführt sind, von denen Sie wissen, dass Sie sie benötigen, z. B. Audittabellen. YoOu kann eine Liste von Potenzialen für die Beseitigung von dort erstellen.

Sobald Sie die Liste der zu eliminierenden Potenziale haben, werden Sie wahrscheinlich einige ziemlich offensichtliche wie usp_my_proc_Old sehen (wenn Sie einen USP_My_proc in der Datenbank haben). Das sind meine ersten Kandidaten, die eliminiert werden. Tabellen ohne Daten sind an dieser Stelle weitere offensichtliche Tabellen. Tabellen / Prozesse, die eindeutig auf eine Funktionalität verweisen, von der Sie wissen, dass sie entfernt wurde, sind die nächsten. Angenommen, Sie haben kürzlich die Funktionalität zum Speichern von Umfrageergebnissen durch ein neues Design ersetzt. Möglicherweise möchten Sie die Tabelle behalten (möglicherweise benötigen Sie die Daten), aber die Prozesse, die diese Tabelle aufrufen, sind wahrscheinlich alle veraltet und können gelöscht werden.

Abhängig von Ihren rechtlichen Einschränkungen möchten Sie möglicherweise keine Tabelle mit Daten entfernen. Wir haben kundenspezifische Daten für Kunden, die wir nicht mehr haben, da wir uns in einer regulierten Branche befinden und gelegentlich gebeten werden, Wirtschaftsprüfern, Aufsichtsbehörden und Anwälten Daten zur Verfügung zu stellen. Sie können diese Tabellen jedoch in eine andere Archivdatenbank verschieben, wenn Sie Ihre eigentliche Produktionsdatenbank bereinigen möchten.

Dann schauen Sie sich an, was sie tun. Sie können jeden Prozess entfernen, der nicht ausgeführt wird, insbesondere wenn eine der Tabellen, auf die er verweist, nicht mehr vorhanden ist. Wenn eine Tabelle ein Datumsfeld hat, gibt es aktuelle Daten? Wenn das Datenfeld das letzte Mal mit einem Datum gefüllt wurde, war dies ein guter Kandidat für eine Tabelle, die wir nicht mehr benötigen.

Sobald Sie eine Liste mit mehreren potenziellen Objekten zum Löschen haben, senden Sie die Liste an alle Ihre Entwickler und fragen Sie sie, ob sie die Tabelle / den Prozess verwenden oder wissen, wofür sie gedacht sind. Tun Sie dies nicht mit einer riesigen Liste von Tausenden von Objekten. Senden Sie nicht mehr als 10 bis 20 gleichzeitig und versuchen Sie, sie zu gruppieren, damit sie eindeutig zu verwandten Themen gehören.

Um potenzielle Probleme zu beseitigen, können Sie dem Prozess einen Protokollierungsprozess oder der Tabelle einen Protokollierungsauslöser hinzufügen und ein Datum festlegen, an dem das Objekt entfernt wird, wenn bis zu diesem Datum keine Einträge vorhanden sind.


2

Führen Sie eine Ablaufverfolgung für Folgendes aus:

  • SP: Abgeschlossen
  • SP: StmtCompleted
  • RPC: Abgeschlossen
  • SQL: BatchCompleted
  • SQL: StmtCompleted

Ziehen Sie in Betracht, nach Datenbank-IDs zu filtern. Sobald Sie genügend Daten zusammengestellt haben, können Sie Ihre Entscheidungen treffen. Beachten Sie natürlich, dass ein Trace einen Leistungseinbruch aufweist. Stellen Sie daher sicher, dass dieser Treffer keine betrieblichen Probleme verursacht.


2
Für die Spur würde ich behaupten, dass Sie wirklich nur RPC erfassen müssen: Starten. Sie müssen keine Ad-hoc-Stapel oder alle zusätzlichen Informationen erfassen, die mit der abgeschlossenen Hälfte der Ereignisse geliefert werden, um festzustellen, welche gespeicherten Prozeduren aktiv verwendet werden. Dies wird natürlich auch nur dazu beitragen, die künftigen Verfahren zu identifizieren.
Aaron Bertrand

1

Einer meiner Kunden hat genau das gleiche Problem, aber es ist das schlimmste Beispiel, das ich je gesehen habe. Einige betrügerische Entwickler haben Tausende von gespeicherten Prozeduren (über 6 KB) generiert, von denen die meisten nicht verwendet werden.

Sie rufen jetzt alle 5 Minuten sys.dm_exec_cached_plans ab und fügen sie zur Verfolgung in eine Tabelle ein. Es werden nur gespeicherte Prozedurnamen eingefügt, die noch nicht in der Tabelle vorhanden sind.

Wie bereits erwähnt, wird dringend empfohlen, vierteljährliche / jährliche Geschäftszyklen zu durchlaufen.


0

Das Problem ist nicht, dass DMVs unzuverlässig sind, sondern dass sie nicht die gewünschten Informationen erfassen. Erstellen Sie einen Job, der regelmäßig ausgeführt wird und mit dem die gewünschten Informationen erfasst werden. Führen Sie ihn zweimal täglich aus, wenn Ihre Daten innerhalb von 24 Stunden abfallen. Angesichts der Tatsache, dass die DMVs nicht wirklich intensiv sind, auch nicht stündlich, wenn Sie möchten.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.