Import von Derby nach Oracle

[matthiasforberg]

Hallo,

mich würde mal das Standardverhalten interessieren, wenn man ein Datenschema aus einer Derby DB in einen Oracle Layer importiert. Und bitte jetzt nicht sagen: "das macht man nicht" - das wissen wir auch . Lässt sich aber leider in diesem Fall nicht vermeiden. Ich möchte gerne wissen, wie man das am besten handhaben kann, ohne Datenverlust.

Erst einmal, sind folgende Annahmen richtig?

1. Oracle hat eine Zeichenbeschränkung für Tabellennamen von 30 Zeichen (32 Bytes, aber 2 davon sind Steuerzeichen), Derby dagegen erlaubt deutlich mehr Zeichen
2. Bearbeitet man ein Oracle-Schema manuell in FirstSpirit, werden zu lange Namen (dbName) automatisch auf 30 Zeichen begrenzt
3. Importiert man ein ganzes Projekt mit Derby-Anbindung in einen Oracle-Layer, werden die langen Namen auf 30 Zeichen gekürzt
4. Importiert man ein einzelnes Derby-Schema in eine Oracle-Anbindung, werden die langen Namen ebenfalls auf 30 Zeichen gekürzt
5. Aktualisiert man ein Schema durch Update des Schema.xml (externes Bearbeiten), werden die langen Namen auch automatisch auf 30 Zeichen gekürzt

Soweit so gut, meine Beoabachtung ist aber nun, dass durch diese Kürzung Mehrdeutigkeiten entstehen können, die offenbar von FS nicht aufgelöst werden. Meine zweite Beobachtung ist, dass nicht alle Namen auf 30 Zeichen gekürzt werden, sondern teilweise auf 32.

1. Beobachtung

Lege ich im Schema z.B. "Eine_tolle_Tabelle_mit_mehr_als_30_Zeichen" an, wird der dbName artig auf 30 Zeichen gekürzt: dbName="EINE_TOLLE_TABELLE_MIT_MEHR_AL"

Dann lege ich eine weitere Tabelle an, wobei die ersten 30 Zeichen identisch sind: "Eine_tolle_Tabelle_mit_mehr_als_30_Zeichen_im_Namen", wird hier nicht gekürzt, sondern es kommt beim Speichern die folgende Fehlermeldung:

Fehler beim Datenbankzugriff:
    java.sql.SQLException: ORA-00972: Bezeichner ist zu lang
FSVersion=4.2.461.48921#2372;JDK=1.6.0_32 32bit Sun Microsystems Inc.;OS=Windows XP 5.1 x86;Date=26.06.2012 14:33:13
de.espirit.or.SchemaException: java.sql.SQLException: ORA-00972: Bezeichner ist zu lang
    at de.espirit.or.impl.generic.GenericTableSynchronizer.updateDB(GenericTableSynchronizer.java:171)
...usw.

Hier muss man also offenbar genau aufpassen, was man tut, um Mehrdeutigkeiten zu vermeiden...

2. Beobachtung

Gibt es keine o.g. Mehrdeutigkeiten, lässt sich das Schema zunächst speichern und alles scheint in Ordnung. Aber beim nächsten Bearbeiten kann es evtl. zu der folgenden Fehlermeldung kommen:

FSVersion=4.2.446.45868#2463;JDK=1.6.0_31 32bit Sun Microsystems Inc.;OS=Windows 7 6.1 x86;Date=21.06.2012 14:56:37 
de.espirit.or.SchemaException: de.espirit.or.SchemaException: java.sql.SQLException: ORA-00955: name is already used by an existing object 
...

Hier haben wir herausgefunden, dass zwar die Namen der eigentlichen Tabellen richtig gekürzt werden, z.B.

<xs:complexType dbName="EINE_TOLLE_TABELLE_MIT_MEHR_AL" name="Eine_tolle_Tabelle_mit_mehr_als_30_Zeichen">

die Index Namen hingegen werden auf 32 statt 30 Zeichen gekappt:

<xs:key dbName="PK_EINE_TOLLE_TABELLE_MIT_MEHR_0" name="pk_Eine_tolle_Tabelle_mit_mehr_als_30_Zeichen">

Warum das genau passiert, habe ich noch nicht ganz begriffen. Ist das ein Bug oder liege ich generell falsch damit, dass FirstSpirit diese Kürzungen vornimmt und es ist am Ende gar nicht vorgesehen, dass man überhaupt aus Derby in Oracle importieren kann?

Ich weiß, das waren jetzt mehrere Dinge gleichzeitig, aber gibt es zu dem Thema eine Aussage, bzw. wie wird das Verhalten in 5.0 sein? Ist das alles ein alter Hut oder hat es nur bislang keiner gemerkt.

Grüße

Matthias

[feddersen]

Hallo Matthias,

ich bezweile, dass schon jemand in solche Probleme gelaufen ist. Das Problem ist schon speziell und es müssen einige Faktoren zusammen kommen:

• Man nutzt die Derby für irgendwas anderes als Testprojekte
• Man will dann auch noch in eine Oracle migrieren
• Man hat dazu auch noch Tabellen die in den ersten 30 Zeichen identisch sind

An der Einschränkung von Oracle kann FirstSpirit auch nichts drehen und wie weit die Intelligenz von FirstSpirit in solchen Fällen gehen muss ist fraglich. Du kannst an unseren Helpdesk mal das Projekt schicken (am besten nur den wesentlichen Teil, sofern es größer ist) und genauere Informationen in welche Oracle-Version das importiert wurde etc. Aber ich kann dir nicht versprechen, dass das als Bug eingestuft wird.

Der praktische und schnelle Rat wäre das Datenmodell in Oracle neu zu modellieren. Die Daten aus der Derby zu exportieren (als SQL-Statements oder CSV), in der Datei die Tabellennamen zu patchen und diese dann in die Oracle zu importieren.

[matthiasforberg]

Hallo Christoph,

vielen Dank für die schnelle Antwort. Ich kann nicht glauben, dass ich nach über 12 Jahren Produktgeschichte der erste bin, dem das auffällt. Aber da ich ja nach dem Standardverhalten von FS in so einer Situation gefragt habe, ist meine Frage damit beantwortet. Offenbar ist dieser Fall nicht vorgesehen und wird auch nicht abgefangen. Damit ist unser Fix, nämlich manuelle Nachbearbeitung des XML, schon die Lösung und zukünftige Erweiterungen des Schemas machen wir nur noch auf Oracle, dann sollten wir einigermaßen sicher sein.

[feddersen]

Hallo Matthias,

ich habe jetzt nicht alle Tickets durchforscht, ob schon mal jemand ein ähnliches Problem hatte, aber wie gesagt, es kommen ja schon einige Bedinungen zusammen. Die Idee das XML im Export zu patchen sollte eigentlich auch funktionieren und auch weniger Aufwand bedeuten.

Viele Grüße

Christoph