SQL View auf variable Liste von Datenbanken erstellen / DDL Trigger

Eld0r

Ensign
Registriert
Dez. 2008
Beiträge
131
Hallo zusammen,

ich brauche eure Hilfe, wir haben schon ein paar Arbeitsstunden dran gesessen.
Schönes kniffliges MS SQL Problem.

Wir haben in einem MS SQL Server ~90 Datenbanken die zyklisch wechseln: Name_varStr. Alle beinhalten die gleiche Tabelle. Wir brauchen ein View auf die Tabellen aller Datenbanken.

Bisher haben wir:
Eine stored procedure erstellt mit dynamic SQL eine Anweisung für das ALTER VIEW auf all diese Datenbanken. Mit UNION ALL werden alle Tabellen der Datenbanken aneinander gehängt.
Funktioniert Bombe
Allerdings ändern sich diese Datenbanken täglich. Es werden neue erstellt und alte detached.

Überwachung:
Ein DDL Trigger auf master ON ALL SERVER AFTER CREATE_DATABASE, der das stored procedure aufruft, funktioniert prima. Neue Datenbanken werden erkannt und das View ist immer aktuell. Auch das ATACH von datenbanken löst das DDL Event CREATE_DATABASE aus.
Es gibt auch ein Event DROP_DATABASE, aber keins für detach.

PROBLEM:
Leider werden die datenbanken detached und detach löst kein DROP_DATABASE aus...
(program, was von uns nicht geändert werden kann)
Wenn direkt nach dem detach der Alten eine Neue erstellt wird, fällt das garnicht auf, das View wurde dann wegen des create trigger richtig erstellt.
Aber detach kann auch nach dem neu erstellen einer Datenbank passieren...

Workaround:
Die stored procedure wird bisher zyklisch aufgerufen um das ungültige View zu verhindern. Zusätzlich wird die letzte -wahrscheinlich bald detach- Datenbank nicht in das View aufgenommen... Ein Abfragen auf detach wäre aber wesentlich geiler...

FRAGE:
- Idee, wie wir das detach mitbekommen?
Haben wir uns verrannt?
- Generell eine ganz andere Idee, wie wir ein View auf alle Datenbanken bekommen?

Gruß
Eld0r
 
Zuletzt bearbeitet:
Hi,

hört sich interessant an.
Ich habe mal kurz geschaut und auch gefunden, dass der Trigger bei DetachDB wohl nicht feuert.
Allerdings scheint es wohl mit EVENT NOTIFICATION zu gehen (kein Trigger), s. z.B. hier.
Das Event sollte auch im Profiler-Trace zu finden sein.

Ich kann es jetzt nicht direkt ausprobieren, aber vielleicht bringt es dich auf eine Spur ;).
 
Muss es denn eine View sein? Wenn nicht, könnte man darüber nachdenken eine Stored Procedure zu machen, welche die Daten in einem ResultSet zurückliefert und dafür den Query dynamisch zusammenbaut.
 
Ich konnte leider noch nicht Testen ob EVENT NOTIFICATION den Anforderungen entspricht.
Müssten wahrscheinlich trotzdem die älteste DB draußen lassen, wäre aber okay. 👍

Ich befürchte ein gleichzeitiger Zugriff zu einem DETACH DATABASE könnte zu einem inkonsistenten VIEW führen.
Korrigiert mich, wenn ich mich irre:
TRIGGER gewähren Konsistenz und EVENT NOTIFICATION ist leicht Zeit verzögert.

Leider müssen wir mit der rudimentären Oberfläche eines Programms zurecht kommen.
Gehen nur standard SQL Abfragen auf Datenbanken / Views.

Danke für die Tipps,
ich melde mich spätestens wieder, wenn wir es testen konnten.
 
Zurück
Oben