Nehmen wir an, Sie haben eine MS SQL 2000 oder 2005 Datenbank geerbt, und Sie wissen, dass einige der Tabellen, Ansichten, Prozesse und Funktionen nicht tatsächlich im Endprodukt verwendet werden.
Gibt es eine Art interne Protokollierung oder einen anderen Mechanismus, der mir sagen könnte, welche Objekte NICHT aufgerufen werden? oder wurden nur einige Male im Vergleich zu Tausenden aufgerufen.
Diese SO-Frage Identifizieren nicht verwendeter Objekte in Microsoft SQL Server 2005 , könnte relevant sein.
Die Antwort hängt ein wenig davon ab, wie die Datenbank zusammengestellt wurde, aber mein Ansatz für ein ähnliches Problem war dreifach:
Finde heraus, welche Objekte keine internen Abhängigkeiten haben. Sie können dies aus Abfragen gegen sysdepends wie zum Beispiel:
ausführen %Vor%Sie sollten dies mit dem Sammeln des Objekttyps (sysobjects.xtype) kombinieren, da Sie nur die Tabellen, Funktionen, gespeicherten Prozeduren und Ansichten isolieren möchten. Ignorieren Sie auch alle Prozeduren, die "sp_" starten, es sei denn, Benutzer haben Prozeduren mit diesen Namen für Ihre Anwendung erstellt!
Viele der zurückgegebenen Prozeduren können die Einstiegspunkte Ihrer Anwendung sein. Das heißt, die Prozeduren, die von Ihrer Anwendungsschicht oder von einem anderen Remote-Aufruf aufgerufen werden und keine Objekte haben, die innerhalb der Datenbank von ihnen abhängen.
Unter der Annahme, dass der Prozess nicht zu invasiv ist (es wird eine zusätzliche Last erzeugen, wenn auch nicht zu viel), können Sie nun einige Profilerstellung der SP: Starting, SQL: BatchStarting und / oder SP: StmtStarting Ereignisse aktivieren. Führen Sie das so lange durch, wie Sie es für richtig halten, und loggen Sie sich idealerweise in eine SQL-Tabelle ein, um die Querverweise zu vereinfachen. Sie sollten in der Lage sein, viele der Prozeduren zu eliminieren, die direkt von Ihrer Anwendung aufgerufen werden.
Durch Querverweisen auf die Textdaten aus diesem Protokoll und Ihrer abhängigen Objektliste haben Sie hoffentlich die meisten nicht verwendeten Prozeduren isoliert.
Schließlich möchten Sie vielleicht Ihre Kandidatenliste, die sich aus diesem Prozess ergibt, übernehmen und Ihre Quellcode-Basis gegen sie auffüllen. Dies ist eine mühsame Aufgabe und nur weil Sie Referenzen in Ihrem Code finden, bedeutet das nicht, dass Sie sie brauchen! Es kann einfach sein, dass der Code nicht entfernt wurde, obwohl er logisch nicht zugänglich ist.
Das ist alles andere als ein perfekter Prozess. Eine relativ saubere Alternative besteht darin, ein viel detaillierteres (und daher invasives) Profiling auf dem Server einzurichten, um alle Aktivitäten zu überwachen. Dies kann jede SQL-Anweisung einschließen, die während der Zeit aufgerufen wird, in der das Protokoll aktiv ist. Sie können dann die abhängigen Tabellen oder sogar datenbankübergreifende Abhängigkeiten von diesen Textdaten zurückverarbeiten. Ich habe die Zuverlässigkeit des Log-Details gefunden (zu viele Zeilen pro Sekunde, die versucht wird, analysiert zu werden) und die schiere Menge an Daten, mit denen schwer umzugehen ist. Wenn Ihre Anwendung weniger davon betroffen ist, dann kann es ein guter Ansatz sein.
Vorbehalt:
Denn soweit ich weiß, gibt es keine perfekte Antwort darauf, besonders vorsichtig beim Entfernen von Tischen. Prozeduren, Funktionen und Ansichten können leicht ersetzt werden, wenn etwas schief geht (obwohl Sie sicherstellen müssen, dass Sie sie in der Quellcodeverwaltung haben, bevor Sie sie natürlich brennen!). Wenn Sie wirklich nervös sind, warum benennen Sie die Tabelle nicht um und erstellen Sie eine Ansicht mit dem alten Namen, dann haben Sie ein leichtes aus.
Wir können auch unbenutzte Spalten und Tabellen mithilfe der folgenden Abfrage finden. Ich bin müde, um den Cursor zu schreiben. Cursor gibt Ihnen Informationen über jede Spalte in jeder Tabelle.
%Vor%Tags und Links sql-server logging