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.

[tsteinmaurer]

Mir erschließt sich nicht ganz, warum man sich noch mit InterBase 6 abgibt, womöglich die Open Source Variante, die ein Rattennest an Bugs darstellt. Aber ich denke die Diskussion hatten wir in diesem Forum schon ein paarmal. :-D

[Perlsau]

Zitat:

Zitat von RSE (Beitrag 1228526)

@Perlsau:
Wenn 20 Stunden vergangen sind, bedeutet das mitnichten, dass ich 20 Stunden in die Lösung dieses Problems investiert habe.

Könntest du mir zeigen, wo ich behauptet hätte, du habest 20 Stunden oder auch nur 10 Stunden "in die Lösung dieses Problems investiert"? Denn eigentlich dachte ich lediglich geschrieben zu haben: "... nach gut 10 Stunden, noch immer nicht gelöst." :roll:

Nachtrag: Ja, da weiß er nun nichts mehr, der Herr RSE ...

[Hansa]

Zitat:

Zitat von RSE (Beitrag 1228526)

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.

Jetzt mal mit Verlaub gesagt : wer hat diesen Unsinn zu verantworten ? :shock: 1. Mehrere Projekte pro Woche. 2. Jedes Projekt braucht seine eigenen Tabellen ? 3. 2 GB Grenze ist wichtig, bzw. diese Grenze wird schon mal erreicht ? Ist Dir überhaupt klar, was Projekt heisst ? Das ist ein (Haupt-)Programm. welches einen gewissen Datenbestand hat. Vielleicht gehören zu diesem "Projekt" auch noch einige Tools, Zusatzprogramme etc., wobei allerdings alles auf gemeinsamem Datenbestand aufbaut. Nennen wir das ganze dann eben "Projekt".

Jetzt erkläre mir mal, inwiefern da andauernd Tabellen angelegt, "entsorgt" werden müssen usw. ? Wenn wochenlang jede Woche mehrere Projekte neu angelegt werden, das wäre dann wohl 3-stellige Projektanzahl. Wird da etwa jede benötigte Tabelle in ein und dieselbe Datenbank gespeichert ? Das würde einiges erklären (auch die vielen Generatoren). 8-) Im Zusammenhang mit IB 6.1 deutet da wirklich einiges auf eine gehörige Portion Beratungsresistenz hin. :P Von denen die hier geantwortet haben ist keiner, der nicht weiss (und zwar ziemlich genau), von was er spricht ! "Redesign" ist da eher noch harmlos. :mrgreen:

[Blup]

Da das böse Wort "Redesign" nun schon gefallen ist, wozu benötigt ihr für jede Tabelle einen Generator?
Einer genügt für die ganze Datenbank (Spezialfälle mal ausgenommen).

[RSE]

Die ganze Geschichte, warum wir noch mit IB6.1 arbeiten und warum unsere DB so designt ist, wie sie ist, ist nicht auf meinem Mist gewachsen. Da diese Fragen hier nicht zur Diskussion stehen, werde ich sie hier auch weder verteidigen noch euch zustimmen. Ich spreche euch keine Kompetenz ab, aber um die Qualität einer Designentscheidung beurteilen zu können, sollte man schon wissen um was es geht - dann erscheint da nämlich einiges in anderem Licht, nicht alles ist Standardfall. Bevor weitere Kommentare in diese Richtung kommen: Ich werde nicht weiter darauf eingehen, da ich keine Lust habe, in jedem meiner Threads unsere gesamte Programmstruktur incl. Hintergrundinfos und Zukunftsplänen offenzulegen.

@Perlsau:
Dann hatte ich dich da offenbar missverstanden. Sorry dafür.

[hstreicher]

Autoincrement Wert werden bei Interbase / Firebird über Generatoren und Trigger erzeugt,
also JA man braucht ne menge davon mit den beiden Datenbanken

[QuickAndDirty]

Wir halten die Struktur der Datenbank vollständig in einer Konfigurationsdatei in einem datenbankneutralen Format vor.
Beim Anlegen von Autoinc Feldern, werden dann automatisch Trigger und der dazugehörige Generator angelegt.
Wenn man die Datenbank reorganisiert, werden alle Daten in temporäre Tabellen kopiert alle Trigger, Schlüssel, Generatoren und Tabellen werden gelöscht.
Die Datenbank wird aus den Strukturdaten in der Konfigurationsdatei wiederhergestellt und der Inhalt der temporären Tabellen in die neu angelegten Tabellen übertragen.

Wenn du also DB-Modell-Informationen hättest, könntest du dich ziemlich leicht aller unnötigen Generatoren entledigen.
Da man sowas eigentlich sowie so dokumentiert braucht, würde ich mich daran machen, sowas in maschienenlesbarer Form anzufertigen.

[Blup]

Zitat:

Zitat von hstreicher (Beitrag 1228658)

Autoincrement Wert werden bei Interbase / Firebird über Generatoren und Trigger erzeugt,
also JA man braucht ne menge davon mit den beiden Datenbanken

Ich arbeite seit mindestens 10 Jahren mit Interbase/Firebird und kann dir berichten das zumindest in den Datenbanken unserer Kunden so bis 10GB ein 32-Bit Generator für alle Tabellen genügt. Ein Trigger für jede Tabelle, aber alle können den selben Generator nutzen.

[Hansa]

Genau so siehts aus. :thumb: Ausnahme : Online-verarbeitete Daten, d.h., wenn z.B. pro Sekunde 100 eingehende Bestellungen anfallen mit jeweils mehreren Positionen. Von Hand lässt sich ein Generatorwert jedenfalls kaum komplett füllen (auch in Jahren nicht). Hätte man sich das mal vorher überlegt, oder würde eben jetzt handeln, dann wäre das Problem gar nicht erst aufgetaucht.

[IBExpert]

wenn du nur die Referenzen deiner Steinzeit DB wissen willst, dann mach es dir doch einfach und mache ein Backup und ein Restore unter unter FB2.X und schau dann einfach mit den SQLs in die DB. So holt sich übrigens IBExpert Dependencies für Generatoren (kann man in IBExpert sehen, wenn man vorm Öffnen der Seite Dependecies im Menü Tools den SQL Monitor anwirft (in diesem Beispiel hieß der Generator ID).

select D1.RDB$DEPENDENT_NAME, D1.RDB$FIELD_NAME, D1.RDB$DEPENDENT_TYPE, R1.rdb$relation_name
from RDB$DEPENDENCIES D1
left join rdb$relations r1 on ((D1.RDB$DEPENDENT_NAME = r1.rdb$relation_name) and (not (r1.Rdb$View_Blr is null)))
where (D1.RDB$DEPENDED_ON_TYPE = 14)
and (D1.RDB$DEPENDENT_TYPE <> 3)
and (D1.RDB$DEPENDED_ON_NAME = 'ID')
union
select distinct f2.rdb$relation_name, d2.rdb$field_name, d2.rdb$dependent_type, r2.rdb$relation_name
from rdb$dependencies d2, rdb$relation_fields f2
left join rdb$relations r2 on ((f2.rdb$relation_name = r2.rdb$relation_name) and (not (r2.Rdb$View_Blr is null)))
where (d2.rdb$dependent_type = 3) and
(d2.rdb$dependent_name = f2.rdb$field_source)
and (d2.rdb$depended_on_name = 'ID')
order by 1, 2

[Furtbichler]

Zitat:

Zitat von Blup (Beitrag 1228701)

Ich arbeite seit mindestens 10 Jahren mit Interbase/Firebird und kann dir berichten das zumindest in den Datenbanken unserer Kunden so bis 10GB ein 32-Bit Generator für alle Tabellen genügt. Ein Trigger für jede Tabelle, aber alle können den selben Generator nutzen.

Ich habe eine FB mit einem Generator bei einer Messdatenerfassung im Einsatz und muss leider feststellen, das bei ca. 600 Messwerten pro Sekunde FB zwar locker mitkommt, aber das Ganze dann doch etwas knapp wird. Ich habe auf den PK per ID hier verzichtet.

Es kommt -wer hätte das gedacht- immer auf den Einsatzzweck an. Ein Durchrechnen des Szenarios über alle Unbekannten, wie z.B. Durchsatz, Spitzensatz, #IDs, Speicher sollte immer vor dem DB-Design erfolgen.

[mkinzler]

Bei BigInt sollte da genügend Luft nach oben sein

[Furtbichler]

Zitat:

Zitat von mkinzler (Beitrag 1228767)

Bei BigInt sollte da genügend Luft nach oben sein

Natürlich, ich wollte nur anmerken, das 4 Milliarden Datensätze nicht notwendigerweise ausreichen. Es gibt Datenbanken, da kommen und gehen die Daten (wie bei der Messadatendatenbank) und da geht das dann recht schnell. BigInt sollte dann aber doch reichen, bis die Garantiezeit beendet ist.

[mkinzler]

Der BigInt von Firebird hat 64 Bit (vorzeichenlos). Das wären bei 600 Werte pro Sekunde ca. 975 Mio Jahre! Ich glaube länger hält keine Garantie! ;)

[RSE]

Sorry, ich habe keine Benachrichtigungen mehr bekommen, werde das mal überprüfen müssen...

@ User IBExpert:
Ich glaube ein Restore unserer IB6.1 DB unter Firebird 2.x würde diverse andere Fehler bringen. Wir verwenden z.B. START und STOP als Feldbezeichner und das sind doch jetzt reservierte Worte. Von daher ist das eine gute Idee, die recht schnell alle Dependencies aufzeigen würde, wenn man nicht diverse Fehler dabei korrigieren müsste.