Gesucht: Script, das zu job alle tabellen, views, sp, ..ausgibt

[RedNeck]

Hallo,

ich bin wie die Jungfrau zum Kind zum Administrator eines SQL-Servers geworden.

Der Server wurde von vielen verschiedenen Praktikanten über Jahre für IDV-Insellösungen missbraucht.
Alles natürlich ohne Dokumentation!

Jetzt kann der Server nicht mehr betreut werden, weil kein Mensch mehr weiss, welche Tabellen, Views, etc..zu welcher IDV-Insellösung gehören.


um ein bisschen Struktur rein zu bringen, habe ich mir überlegt, von den Jobs ausgehend zu analysieren.


Dabei würde mir folgendes helfen

Script, das alle Tabellen, views, functions, SP listet, die bei Ausführung des Job verwendet werden bzw. die vorhanden sein müssen.

Script, dass die Aufrufreihenfolge von StoredProcedures listet


Hat von Euch schon jemand diese eierlegende Wollmilchsau geschrieben?


Bin für tipps dankbar, zumal ich in den letzten 15 Jahren kein SQL mehr angewendet habe...
RedNeck

 

[ukulele]

Ich würde sagen sowas als generelle Lösung für eine DB zu schreiben dauert Jahre und erfordert viel Know-how und Geduld.

Du wirst dir die Jobs angucken müssen und alles was durch die Jobs ausgeführt und aufgerufen wird wirst du dir weitergehend angucken müssen.

Bei MSSQL kann man ein ERD automatisch erzeugen, sofern mit echten Constraints gearbeitet wurde, auch wenn das viele Aplikationen gar nicht nutzen. Das würde dir zumindest die Zusammenhänge der Tabellen deutlich machen.

 

[RedNeck]

Mein Hauptproblem ist, dass ich schon Jahre raus bin aus dem Thema...
Ich habe diverse Scripts gefunden, die
-alle steps zu einem job
-alle sp, tables zu einem step
-alle tabellen zu sp liefern
etc...
die Infos liegen also auswertbar vor.
Nur reicht aktuell mein KnowHow nicht, aus diesen Teilen ein Ganzes zu machen...
Ich denke nicht, dass so ein Script "jahre" dauert...
Vielleicht wirds kein Script, sondern kleines vb-Progrämmchen.

Was mich wundert, ist, dass ich im gesamten Netz niemand gefunden habe, der mit einem geerbten SQL-Server kämpft.

Scheinbar bin ich da allein auf weiter Flur

greets
RedNeck

 

[ukulele]

Geerbt schon, bastel auch grade an einem Datenimport. Da gehts aber nur im Tabellenstruktur etc, da ist wenig mit Triggern oder SPs.

Was genau verstehst du denn unter "auswerten"? Wenn du weisst welche SP aufgerufen wird musst du in der SP gucken welche Tabellen und Spalten betroffen sind. Da Elemente wie SPs die Eigenschaft haben sehr unterschiedlich / individuell aufgebaut zu sein ist es schwer das einheitlich darzustellen oder zu analysieren. Der kleinste gemeinsamme Nenner ist TSQL als Sprache, und das wird man sich anschauen müssen um zu verstehen was passiert.

 

[RedNeck]

Hallo,
Problem ist, dass ich nicht manuell guggen will, sondern automatisch.
Dazu möchte ich die dependencies benutzen.

Es gibt z. Bsp ein ,Script das alle Tabellen Views zurückgibt die in einer SP (und wenn ich es richtig verstanden habe, auch in allen darunter aufgerufenen SP) zurück gibt.


Jetzt will ich dieses Script nict für jede SP einzeln aufrufen, sondern nur für die, die in einem Step eines Jobs sind.

Ich habe ebenfalls ein Listing, dass mir alle Steps zu einem Job zurück gibt.

Staffelt man die Scripts hintereinander, erhält man zu einem Job alle Steps, dazu alle Sp, dazu alle Tabellen.

Voila, das will ich.
Leider reichen meine aktuellen Kenntnisse nicht dazu aus, die Scripts in eine gesamtes zu packen oder ein VB-Progrämmchen dazu zu schreiben.

Ich dachte, dass womöglich hier schon einer das Problem ebenfalls hatte; sieht aber nicht danach aus.

 

[ukulele]

Also ich habe mir, grade vor ein paar Tagen erst, ein Script gebastelt um Tabellen, Spalten, Datentypen aufzulisten und die Inhalte zu "umschreiben". Das will ich gerne mal zur Verfügung stellen. Im wesentlichen werden die Systemtabellen sysobjects, syscolumns und systypes genutzt um dann im Anschluss mit dynamischen SQL eine Index Tabelle um Informationen zu ergänzen. In sysobjects stehen auch die SPs gelistet.

Bei der Anwendung sind nur 2 Sachen zu beachten, die Tabelle Index sollte noch nicht existieren und bei der Anwendung des dynamischen SQLs kann es theoretisch zu Fehlermeldungen kommen. Ich hab das erst über eine einzige MSSQL DB gejagt.

PS: Ein bischen Laufzeit hat es auch, nicht wundern.