Hallo Zusammen,

die Frage vorab: ist es möglich alle Indexe zu deaktivieren um Daten zu importieren und danach die Indexe wieder zu aktivieren?

Ich bin gerade dabei eine Datenbank FB 1.5 Dialect1 auf Dialect3 umzubauen.
Ich gehe so vor:
-Zuerst ein Backup-/Restore der Datenbank durchgeführt um sicher zu sein dass sie in Ordnung ist.
-Eine neue Datenbank angelegt mit Dialect3
-Metadaten über IBExpert in ein File schreiben.
-Im File alle Felder von Typ Date in Timestamp umbauen. In Dialect1 konnte ein Date Datum und Uhrzeit enthalten,
in Dialect3 gibt es ein Date, Time und Timestamp.
-Alle Daten über IBExpert incl Blobs in ein Textfile exportieren.
-Alle Indexe deaktivieren
-Das Textfile importieren.
-Alle Indexe wieder aktivieren
Wenn keine Fehler vorkommen sollte es gewesen sein.

Der Hintergrund warum ich die Indexe deaktivieren muss ist, ich verwende zirkulare Refrenzen in manchen Tabellen.
Es gibt also Tabellen die haben ein FK auf ein PK der gleichen Tabelle. Deshalb müssen die Indexe deaktiviert sein
da es vorkommen kann dass ein FK auf ein Datensatz referenziert welcher erst später importiert wird.

http://www.firebirdfaq.org/faq274/
Hier ist beschrieben wie alle Indexe als Script abgerufen werden können um sie danach zu aktivieren,
doch das deaktivieren funktioniert so nicht. z.B.

markieren

Code:

ALTER INDEX FK_ABR_POS_1 INACTIVE

In IBExpert habe ich auch keine Möglichkeit gesehen alle Indexe zu deaktivieren-/aktivieren
Hat jemand eine Idee?


[Edit]
Ich habe jetzt doch noch eine Möglichkeit gefunden. Nicht die Indexe deaktivieren sondern alle FKs löschen
somit werden auch die Indexe gelöscht.
Über dieses Statement bekommt man ein Script um alle FKs zu entfernen.
http://www.firebirdfaq.org/faq176/
Nach dem Datenimport könnte man über IBExpert eine Strukturvergleich durchführen und die FKs wieder herstellen lassen.


Gruß Kostas

Zitat:

http://www.firebirdfaq.org/faq274/

Ich hätte jetzt blind gedacht, dass man in dem Script einfach nur das ACTIVE gegen INACTIVE tauscht und eventuell noch die Prüfung des rdb$system_flag irgendwie anpassen müsste, falls dort drinsteht, ob der Trigger (in)aktiv ist.

http://stackoverflow.com/questions/1...n-firebird-2-1

Zitat:

RDB$INDICES has a field RDB$INDEX_INACTIVE

Das klingt auch gut, so daß man Dieses für das WHERE verwenden könnte.



[add]
http://en.martinusso.com/2012/08/ena...-firebird.html

Hallo himitsu,

das deaktivieren scheint nicht zu funktionieren zumindest nicht mit FB1.5
ich importiere gerade die Daten. Mal sehen ob weitere Fehler auftauchen.
Ich würde eher keine erwarten da der Backup und Restore einwandfrei funktioniert hat
dabei werden ja auch die FKs erst am Schluss erzeugt. Dann ist auch klar warum
IBExpert eine Option dafür hat.

Ich melde mich noch einmal wenn alles durch ist und berichte.

Gruß Kostas

Funktioniert leider nicht so wie dachte.

nach ca. 1.5Mio importiere Daten kommt ein Fehler.

markieren

Code:

can't format message 13:99 -- message system code -4.index unexpectedly deleted.

Das Textfile welches importiert wird ist ca. 750MB groß. Ich kann es wegen der Grösse nicht öffnen
auch nicht mit Notepad++ um zu sehen was er genau importieren möchte. Die Meldung "index unexpectedly deleted"
muss nicht unbedingt auf ein Index deuten.
Der Unterschied zwischen der original DB dialect1 und der neuen mit Dialaect3 ist das alle DATE Felder in TIMESTAMP
umgestellt wurde vor dem einlesen der Daten. Daran kann es nicht liegen denn er hat vorher eine Tabelle importiert
indem ein Datumsfeld auch eine Uhrzeit enthielt und die hat er einwandfrei in das neue Feld vom Typ TIMESTAMP importiert.
Es muss also etwas anderes sein.
Ich lasse es jetzt mal laufen mal sehen was noch kommt.



[Edit]
Himitsu, du hattest mir den richtigen Hinweis gegeben mit dem letzten Link. Ich muss natürlich auch die Triggers deaktivieren, das geht jetzt mit IBExpert. Alles nochmal von vorne....

Hab den Thread nur quergelesen, also vielleicht gibt's sinnlose Wiederholungen.

Ein Index hat NICHTS mit der Funktionalität des Foreign Key zu tun.
Ein Foreign oder Primary Key ist eine Regel, die die Existenz des Fremdschlüssels zusichert oder die Eindeutikeit (Primärschlüssel) usw...

Ein zusätzlich definierter Index (ob automatisch angelegt oder per SQL erzeugt) beschleunigt lediglich den Zugriff auf die Werte in der Schlüsselspalte, um die notwendigen Prüfungen für den FK Constraint möglichst schnell prüfen zu können. Lässt man die Indizes weg, löscht sie oder disabled sie, ändert das nichts an der Funktionalität! Nur die Performnace dürfte bei größeren Tabellen deutlich in den Keller gehen.

Hier http://www.firebirdfaq.org/faq176/ gefunden:

markieren

Code:

If you use Firebird 1.x, you can run the following query to get statements to execute and then copy/paste the result and execute:

select 'ALTER TABLE '||r.rdb$relation_name
||' DROP CONSTRAINT '||r.rdb$constraint_name||';'
from rdb$relation_constraints r
where (r.rdb$constraint_type='FOREIGN KEY')

Hab das Fazit vergessen. Man muss also die Constraints (ebenfalls) entfernen/disablen, dazu der Beispielcode, der ein Löschskript erzeugt.
(Ratsam ist natürlich, auch ein Script für die Neuerstellung nach erfolgreicher Migration zu haben / anzufertigen)

Zitat von jobo:

...
(Ratsam ist natürlich, auch ein Script für die Neuerstellung nach erfolgreicher Migration zu haben / anzufertigen)

Ich verwende IBExpert. Damit kann ich nach erfolgreichem Import aller Daten die Struktur der leeren Datenbank(Dialect3)
vergleichen mit den befüllten Datenbank. Als Resultat ist das Delta und damit kann ich die Fehlenden Objekte die PK
wieder herstellen. nach dem PKs werden noch die Trigger wieder aktiviert. Danach sollte alles einwandfrei funktionieren.

Gruß Kostas

@Kostas: Was passiert eigentlich, wenn du das Backup, das du mit der alten FB-Version (Dialect 1) erzeugt hast, unter der neuen FB-Version (Dialect 3) unverändert mit IbExpert einliest? Kommt da beim Restore eine Fehlermeldung wegen Inkombatibilität der Datum-Felder?

Zitat von Perlsau:

@Kostas: Was passiert eigentlich, wenn du das Backup, das du mit der alten FB-Version (Dialect 1) erzeugt hast, unter der neuen FB-Version (Dialect 3) unverändert mit IbExpert einliest? Kommt da beim Restore eine Fehlermeldung wegen Inkombatibilität der Datum-Felder?

Hallo,
ich habe es nicht ausprobiert wegen dem Datumsproblem. Ich verwende jede Menge Datumsfelder die auch in Triggers und SPs
verwendet werden. Die meisten davon haben nur Datumswerte, einige jedoch auch Zeit. Bei der Umstellung habe ich
alle DATE in TIMSTAMP umgestellt, bei den Tabellen, Triggers, und SPs.
Mittlerweile ist alles importiert und funktioniert Fehlerfrei. Jetzt ersetze ich alle Vorkommnisse über dynamische SQLs
in meiner Anwendung. Der nächste Schritt wird sein hochziehen auf FB 3.x aber das hat noch Zeit. Auf FB 2.5 kann ich
nicht gehen da ich eine alte Version der IBO Komponenten verwende. Die Umstellung auf die neue IBO-Version ist ein recht
großer Aufwand. Deshalb warte ich bis sich FB 3.x etabliert hat und mach den Wechsel auf ein mal.

Gruß Kostas