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)?

[Perlsau]

Zitat:

Zitat von RSE (Beitrag 1228185)

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?

[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 ;-)

[Hansa]

Zitat:

Zitat von RSE (Beitrag 1228185)

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;

[Perlsau]

Zitat:

Zitat von RSE (Beitrag 1228509)

@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. :thumb:

[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.

[RSE]

In unserer Firma gibt es Projekte (mehrere pro Woche), die jeweils ihre eigenen Tabellen etc. benötigen. Nach einiger Zeit (wenn die 2GB-Grenze von IB6 naht) werden alte Projekttabellen etc. entsorgt. In Einzelfällen entstehen auch Abhängigkeiten zwischen Projekten, und hier liegt die potenzielle Gefahr.

@Hansa:
Damit fällt also die Suche nach nie genutzten Generatoren (mit Nullwert) nicht in das aktuelle Problem.

@Perlsau:
Wenn 20 Stunden vergangen sind, bedeutet das mitnichten, dass ich 20 Stunden in die Lösung dieses Problems investiert habe. Manchmal ist es sinnvoll, mehrere Aufgaben nach Problemen zu durchdenken, bevor man die erste umsetzt, um Zeit für Forenanfragen zu haben. Dies ist so ein Fall.

Dass ich zusätzlich zur DB auch die Anwendung, die diese benutzt durchsuchen muss, ist klar. Diese Anwendungssuche ist aber ebenfalls nicht Teil dieses Threads, da sie in meinem Fall kein Problem darstellt, da die betroffenen Projekte längst inaktiv sind.

PK-Generatoren werden in IB6 mittels Triggern umgesetzt, welche in meinem Ansatz abgedeckt sind.

Backups machen wir mehrmals täglich, da ist also eine gute Auswahl vorhanden. Eines wird speziell von direkt vor dem Aufräumen vorgehalten.

@haentschman:
Wie du siehst, hat das Ganze in meinem Fall nichts mit einem Redesign zu tun.

@tsteinmaurer:
Wie in meinem ersten Beitrag geschrieben, führt IB6 keine Dependencies für Generatoren. Das funktioniert leider erst ab Firebird.


Bis hier also keine Neuerungen an meinem Lösungsansatz. Trotzdem danke für eure Gedanken.

[mjustin]

Zitat:

Zitat von Hansa (Beitrag 1228514)

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.