Dependencies für Generatoren ermitteln

[RSE]

Hallo,

wir sind am Aufräumen unserer DB. Bei den Generatoren scheint IB keine Dependencies zu führen, was eine Google-Suche bestätigt hat. Nun möchte ich natürlich vor dem Löschen eines Generators mit

Code:

delete from RDB$GENERATORS where RDB$GENERATOR_NAME = 'MY_GEN';

möglichst sichergehen, dass er nicht mehr benutzt wird. Die einzige Möglichkeit, die mir dazu einfällt, ist folgende Abfragen für jeden einzelnen zu löschenden Generator auszuführen - UNION unterstützt IB6.1 ja nicht:

Code:

select *
  from rdb$triggers t
  where (t.rdb$trigger_source containing 'MY_GEN');

select *
  from rdb$procedures p
  where (p.rdb$procedure_source containing 'MY_GEN');

Das ist natürlich mühselig für 101 zu löschende Generatoren.

Dazu folgende Fragen:

1. Ist die Prüfung vollständig (nur auf Benutzung von innerhalb der DB bezogen - Zugriffe auf Generatoren über SQL von außen müssen natürlich anderweitig gecheckt werden)?
2. Fällt euch eine weniger mühselige Methode für die Checks ein?

[D-User]

wäre das nicht ne typische Frage für Holger und IBExperts(gogl)?

[RSE]

Irgendwie bin ich nicht auf die Idee gekommen, dass IBExperts ein eigenes Forum hat. Danke für den Tipp. Ich habe mich dort eben angemeldet, meinen Beitrag übersetzt und kurz vor dem Abschicken kam mir folgende simple Idee:

Code:

select *
  from rdb$triggers t
  where (t.rdb$trigger_source containing 'MY_GEN1')
    or (t.rdb$trigger_source containing 'MY_GEN2')
    or (t.rdb$trigger_source containing 'MY_GEN3')
    or ...

select *
  from rdb$procedures p
  where (p.rdb$procedure_source containing 'MY_GEN1')
    or (p.rdb$procedure_source containing 'MY_GEN2')
    or (p.rdb$procedure_source containing 'MY_GEN3')
    or ...

Damit weiß ich zwar noch nicht welcher Generator noch benutzt wird (falls noch einer benutzt wird), aber ich kann die Anzahl notwendiger Abfragen durch die Intervallhalbierungsmethode (immer die Hälfte der Generatoren aus der Abfrage löschen) auf O(log2) verringern Das werde ich am Montag tun.

Was Frage 1 betrifft gehe ich Aufgrund fehlender Widersprüche der vielen hier anwesenden DB-Experten davon aus, dass die Methode so vollständig ist, wie sie sein kann.

@Perlsau: Das wäre mein zweiter Lösungsansatz geworden, aber da die Aufgabe nicht sooo oft vorkommt, macht meine Idee weniger Aufwand

[Perlsau]

Zitat von RSE:

@Perlsau: Das wäre mein zweiter Lösungsansatz geworden, aber da die Aufgabe nicht sooo oft vorkommt, macht meine Idee weniger Aufwand

Nicht für untug äh ungut, aber diesbezüglich hege ich doch leise Zweifel: Du beschäftigst dich meines Wissens nach seit 14.09.2013 15:56 Uhr damit, und wie ich sehe, ist dein Problem am 15.09.2013 um 02:20, also nach gut 10 Stunden, noch immer nicht gelöst. Da würde eine kleine Anwendung, geschrieben in sagen wir mal großzügig allerhöchstens 1 bis 2 Stunden, doch wesentlich weniger Aufwand erfordern, oder nicht?

Noch etwas: Offenbar arbeiten mehrere Leute in eurer Firma mit und an dieser Interbase-Datenbank. Wäre es da nicht am einfachsten, diese Leute zu fragen, ob sie irgend welche Generatoren erstellt und welche davon sie noch in Verwendung haben? Wenn es mehr als eine DP-Application gibt, die auf die Datenbank zugreift, durchforstet man die ebenfalls nach Generatorenbenutzung. So hat man schon mal eine Liste von Generatoren, die keinesfalls gelöscht werden dürfen. Dann würde ich mich den Generatoren widmen, die in der Datenbank notwendige Indexwerte (z.b. sämtliche PK-Generatoren) erzeugen bzw. erhöhen und diese ebenfalls der Liste hinzufügen. Und dann würde ich alles löschen – falls dir nicht noch weitere schützenswerte Kriterien einfallen –, was nicht auf der Liste steht – selbstverständlich mit vorangegangenem Backup. Dieses gut aufbewahren für den Fall, daß in ein zwei Wochen der eine oder andere angerannt kommt und sich beschwert, daß sein Generator nicht mehr funktioniert ...

[haentschman]

Moin...
Ich finde, daß dein Vorhaben mit Aufräumen nix mehr zu tun hat. Das ist schon ein Redesign. Ich denke, daß du es dir schwer machst.
Vorschlag:
1. Design der neuen DB
2. ggf. die Anwendung auf das bessere Design anpassen.
3. mit IBExpert ein Differenzscript zur alten DB erstellen lassen.
4. ggf. alte DB damit updaten.

...funktioniert bestens.

[tsteinmaurer]

Folgende Abfrage in Firebird gibt dir eine Liste an Objekten, die Generatoren referenzieren:

Code:

select * from rdb$dependencies where rdb$depended_on_type = 14

Solltest du wirklich InterBase 6 einsetzen, dann kann es sein, dass dies ev. nicht verläßlich funktioniert, weil es bei InterBase 6 vorkommen konnte, dass die Abhängigkeiten in der RDB$DEPENDENCIES nicht sauber eingetragen wurden. Aber ein Versuch wäre es wert.

[Perlsau]

Zitat von RSE:

Das ist natürlich mühselig für 101 zu löschende Generatoren.

Dazu folgende Fragen:

1. Ist die Prüfung vollständig (nur auf Benutzung von innerhalb der DB bezogen - Zugriffe auf Generatoren über SQL von außen müssen natürlich anderweitig gecheckt werden)?
2. Fällt euch eine weniger mühselige Methode für die Checks ein?

Wäre da nicht eine kleine Delphi-Anwendung angebracht, die das automatisch erledigt?

[Hansa]

Zitat von RSE:

Nun möchte ich natürlich vor dem Löschen eines Generators mit

Code:

delete from RDB$GENERATORS where RDB$GENERATOR_NAME = 'MY_GEN';

möglichst sichergehen, dass er nicht mehr benutzt wird.

Dazu reicht es aber bei weitem nicht, nur auf eventuell vorhandene Trigger zu überprüfen. Der Generator kann doch überall gesetzt werden. Z.B. von Hand : SET GENERATOR GEN_X TO 123, in SP usw. Da ist nun in der Tat guter Rat teuer, wie man den übeflüssigen Krempel wieder wegkriegt, ohne Schaden anzurichten. Ich würde mir mal den momentanen Stand de Generatoren ansehen. Stehen da welche auf 0, das wären dann schon mal potentielle Löschkandidaten.

Mal schnell mit Delphi-Mitteln so was gebaut :

Delphi-Quellcode:

procedure TForm1.ZeigeDaten;
var GeneratorWert,
    GeneratorName : string;
begin
  DbDS.Close;
  DbDS.SelectSQL.Text := 'select * from RDB$GENERATORS';
  DbDS.Open;
  DbDS.First;
  re1.Lines.Add('Datenbank : '+Database.DatabaseName);
  while not DbDS.Eof do begin
    GeneratorName := DbDS.FieldByName ('RDB$Generator_name').AsString;
    if Copy (GeneratorName,1,4) = 'GEN_' then begin // Systemgeneratoren ausklammern
      DetailDS.Close;      //   ^^ bei mir fangen sie so an
      DetailDS.SelectSQL.Text := 'SELECT GEN_ID(' + GeneratorName + ', 0) G FROM RDB$DATABASE ';
      DetailDS.Open;
      GeneratorWert := DetailDS.FieldByname ('G').AsString;
      re2.Lines.Add(GeneratorName + blanks (20-length (GeneratorName))  + '  '+ GeneratorWert);
    end;
    DbDS.Next;
  end;
end;

[mjustin]

Zitat von Hansa:

Ich würde mir mal den momentanen Stand de Generatoren ansehen. Stehen da welche auf 0, das wären dann schon mal potentielle Löschkandidaten.

Richtig, man könnte auch durch einen Vergleich zweier Schnappschüsse (über ein diff, z.B. aus TortoiseSVN) alle Generatoren auffinden die sich über einen längeren Zeitraum nicht geändert haben und gezielt prüfen, ob diese durch Wegfall von Code auch nicht mehr angesprochen werden. Alle die sich ändern, kann man auf die "Negativliste" setzen (d.h. diese Generatoren dürfen nicht gelöscht werden).

Mit IBExpert kann man die Metdaten der Datenbank als SQL extrahieren und dabei alle Objekte ausser den Generatorwerten ausfiltern - damit hat man die Werte in einer Textdatei und braucht keinen Code dazu schreiben.