Wo fange ich an, eine unbekannte Datenbank zu verstehen?

Der Titel bringt es auf den Punkt.

Ich habe eine SQL Server-Datenbank mit 28 Tabellen und 86 gespeicherten Prozeduren, die rückentwickelt werden müssen. Ich bin mir ziemlich sicher, dass einige Tabellen nie verwendet werden und dass nicht alle Procs auch verwendet werden.

Das größte Problem ist, dass alle für diese Datenbank erstellten Windows-Dienste sowie die gesamte Software- und Datenbankdokumentation verloren gehen und die Person, die das gesamte System entwickelt hat, nicht mehr zu finden ist.

Ich habe es bereits geschafft, ein ER-Diagramm zu erstellen, um die Zusammenhänge besser zu verstehen. Da ich jedoch keine Erfahrung in der Datenbankverwaltung habe, weiß ich nicht, wo ich anfangen soll.

Es tut mir auch leid, wenn diese Art von Frage hier nicht gestellt werden soll.

Drei sehr schnelle Schritte für den Einstieg:

1)

USE DatabaseName

SELECT    [TableName] = OBJECT_NAME(object_id),
last_user_update, last_user_seek, last_user_scan, last_user_lookup
FROM    sys.dm_db_index_usage_stats
WHERE    database_id = DB_ID('DatabaseName')

Zeigt an, wann jeder Index zum letzten Mal verwendet wurde, einschließlich des Clustered-Index. Geben Sie also zumindest einen Vorgeschmack darauf, auf welche Tabellen zugegriffen wird (und auf welche nicht.)

2) Aktivieren Sie eine Extended Events-Sitzung (oder eine serverseitige Profiler-Ablaufverfolgung, wenn Sie Pre-SQL 2012 ausführen) für etwa eine Stunde, während die App verwendet wird. Sie können einen Benutzer auch auffordern, verschiedene Aktionen in der Anwendung in einer bestimmten Reihenfolge auszuführen, damit Sie sie mit dem Trace / der Sitzung korrelieren können.

Ein hilfreicher Vorschlag: Wenn Sie die von der App verwendete Verbindungszeichenfolge ändern können, hängen Sie "; Anwendungsname = AppNameGoesHere" an, damit Sie eine Ablaufverfolgungsfilterung für diesen bestimmten Anwendungsnamen ausführen können. Trotzdem gute Praxis.

3) Laden Sie eine Version der Anwendung herunter, die auf einem Nicht-Produktionsserver ausgeführt wird. Entwickeln Sie eine Liste verhaltensabhängiger Tests für die Anwendung ("Wenn der Benutzer auf die Schaltfläche Neues Element klickt, wird ein neues Element für diesen Benutzer erstellt" usw.). Beginnen Sie mit dem sanften Löschen von Objekten, die Ihrer Meinung nach keinen Einfluss auf die Tests haben, indem Sie sie umbenennen (Ich verwende ein Format wie objectName_DEPRECATED_YYYYMMDD - wobei das Datum der Tag ist, an dem ich es tatsächlich löschen möchte.) Überprüfen Sie alle Ihre Tests erneut.

Durch eine Kombination aus der Extended Events-Sitzung, der Indexverwendung DMV und dem vorläufigen Löschen sollten Sie in der Lage sein, die von der Anwendung verwendeten Hauptobjekte zu identifizieren und einen guten allgemeinen Konsens darüber zu erzielen, welches Objekt was tut.

Viel Glück!

Beginnen Sie am besten mit der Dokumentation Ihrer Datenbank mit SQL Power Doc

SQL Server- und Windows-Dokumentation mit Windows PowerShell

SQL Power Doc ist eine Sammlung von Windows PowerShell-Skripts und -Modulen, mit denen SQL Server-Instanzen und ihre zugrunde liegenden Windows-Betriebssystem- und Maschinenkonfigurationen erkannt, dokumentiert und diagnostiziert werden. SQL Power Doc funktioniert mit allen Versionen von SQL Server von SQL Server 2000 bis 2014 sowie mit allen Versionen von Windows Server und Windows-Betriebssystemen für Endverbraucher von Windows 2000 und Windows XP bis Windows Server 2012 R2 und Windows 8. SQL Power Doc unterstützt auch Dokumentieren von Windows Azure SQL-Datenbanken.

Hinweis: Ich habe es verwendet und es gibt Ihnen einen wirklich guten Einstieg in die Dokumentation und das Verständnis Ihrer Datenbankserverinstanz.

Da ich einmal in einer ähnlichen Situation war, kann ich Ihnen sagen, dass dies ein schwieriger bis unmöglicher Job sein wird. Ich hatte nur Quellcode (> 100.000 Codezeilen), den ausgeführten Dienst, die ausgeführte Datenbank (~ 50 Tabellen) und keine Dokumentation und niemanden, der danach gefragt hätte, außer einem Benutzer dieser Anwendung und einer Kopie der Datenbank und Dienste, in denen ausgeführt wird eine Testumgebung (die ein paar Versionsnummern voraus war, aber ohne Quellcode). Eine weitere Anforderung bestand darin, dass die Dienste rund um die Uhr ausgeführt werden mussten, da sie sich außerhalb der Kunden befanden. Die Situation entstand, weil die meisten Mitarbeiter, einschließlich der Entwickler und der Dokumentation, ungefähr zur gleichen Zeit gingen und im Chaos verschwanden. Ich habe mehr als 6 Monate gebraucht, um einen groben Überblick / eine grobe Dokumentation zu bekommen. Es gab viele Tabellen und Funktionen, die keine Auswirkung hatten, weil sie für die zukünftige Verwendung bestimmt waren oder nie vollständig implementiert wurden. fehlerhafte oder veraltete oder unveröffentlichte Funktionen. Nach den 6 Monaten musste ich die Dokumentation umschreiben, weil ich neue Dinge oder Beziehungen zwischen Dingen entdeckte und zuvor falsche Annahmen hatte.

Warum erzähle ich das? Denn manchmal ist es in einer solchen Situation einfacher und billiger, von vorne zu beginnen und eine neue Anwendung zu schreiben, die die Anforderungen der alten erfüllt (oder neue, wenn sie sich im Laufe der Zeit geändert haben oder Sie eine neue Hauptversion wünschen). Oder um Ihnen zu sagen, was Sie zu erwarten haben.

Wenn Sie es wirklich zurückentwickeln möchten, würde ich die folgenden Schritte empfehlen:

• Machen Sie ein Backup des gesamten Systems! (Erstens: Sie werden nie wissen, wann Sie es brauchen werden. Zweitens: Sie brauchen es für den nächsten Schritt.)
• Erstellen Sie eine Kopie des Systems (Dienste und Datenbank) neu, damit Sie damit arbeiten können, und notieren Sie sich, wie Sie es erstellen können, da Sie dies in den nächsten Monaten mit Sicherheit mehrmals tun müssen, da Sie es beim Reverse Engineering mehrmals durcheinander bringen werden
• Erstellen Sie ein ER-Diagramm mit den Abhängigkeiten zwischen den Tabellen
• Anzeigen und Dokumentieren der Abhängigkeiten jeder Tabelle, gespeicherten Prozedur, ..., da diese meist nicht in ER-Diagrammen enthalten sind
• Verstehen Sie, was die Software tun soll, indem Sie Benutzer fragen und sie selbst verwenden (am besten auf dem Testsystem)
• Wenn der Quellcode der Dienste verfügbar ist: Verschaffen Sie sich einen Überblick und rufen Sie die Datenbank auf und dokumentieren Sie ihn (doxygen ist ein gutes Werkzeug, um eine grobe Dokumentation mit Funktionsaufrufhierarchien zu erhalten).
• Versuchen Sie sich einen groben Überblick über die Datenbank zu verschaffen, indem Sie sich die Tabellennamen und ihre Spalten ansehen
• Beobachten Sie die Datenbank, während Sie sie verwenden
• Bei den vorherigen 4 Schritten werden die Tabellen in 3 Kategorien unterteilt (kann je nach Anwendung für Sie unterschiedlich sein): statische Daten (Daten, die sich beim Ausführen des Servers nicht ändern, wie Serverkonfiguration), Aufzählungen, um gültige Werte in anderen Tabellen mithilfe von Fremdschlüsseln einzuschränken , ...), Konfigurationsdaten (Daten, die sich selten ändern, wie Benutzereinstellungen, ...) und OLTP-Daten (Benutzermeldungen auf dem Chat-Server, Beiträge in einem Forum, Messwerte in einem Maschinensteuerungssystem, Kämpfe in einem Online-Spiel, ...)
• Wiederholen Sie die vorherigen 5 Schritte, bis Sie zufrieden sind oder aufgeben
• Dokument und Code, als wäre der Typ, der am Ende IHREN Code / Ihr System / Ihre Datenbank verwaltet, ein gewalttätiger Psychopath, der weiß, wo Sie leben.

Wünsche dir viel Glück ;)

Ich habe nicht genug Repräsentanten, um einen Kommentar zu schreiben, wollte aber bei Ihrer Frage zu helfen

getting the SQL Power Doc to work.

Wenn Sie die Schritte auf ihrer Dokumentationsseite befolgen, funktioniert es ziemlich einfach. Fangen Sie einfach von oben an.

https://sqlpowerdoc.codeplex.com/wikipage?title=Guide%20For%20PowerShell%20Beginners