nicht angemeldet
Migration von Access nach Oracle
Hallo, zusammen!
Ich stehe vor einem mittleren Problem. Man hat die Aufgabe zugetragen, Access-DB nach Oracle zu migrieren. Leider komme ich absolut nicht weiter. Die Access-DB´s sind über Jahre gewachsen und von Leuten nach und nach erstellt worden, die anscheinend noch nie etwas von ER-Modell, Redundanz, Transparenz usw. gehört haben.
Ich habe zwar eine Idee, indem ich die Tabellen manuell in Oracle anlege und dann die Daten per CSV-Datei nach Oracle rüberschaufele. Aber das will erst mal vermeiden, damit ich zeigen kann, daß ich mit den vorhandenen DB´s in Oracle nichts anfangen kann.
Wenn mir jemand helfen kann und eine Idee hat, so möge er oder sie mir dies bitte mitteilen.
Vielen Dank...
-
Hi!!!
Oh, was für eine nette Aufgabe, da kann ich aus meiner aktuell kürzlichsten Tätigkeit erzählen.
Vorab eine Frage: um welche Version von Oracle handelt es sich?
7.3.x
8i
9i ?In Oracle kann man mittels imp/exp sogenannte Dumps importieren, es handelt sich dabei (beim Dump) um eine sql-ähnliche Struktur, in der neben den eigentlichen Daten auch alle wichtigen Oracle-Daten drin.
Leider hat man jedoch mit Access nicht die Möglichkeit soetwas erzeugen. Schade.
Ich habe neulich zwei Möglichkeiten ausprobiert:
für Oracle9i gibt es eine Migration-Workbench, mit der man von verschiedenen anderen DB-Systemen (einzeln erhältliche Plug-Ins sei Dank) über Dialoge in Oracle (ab version 7.3.2 (not absolutely sure) und höher migrieren kann, die Versionsschwelle hängt mWn an einer bestimmten Dumpformatversion)... jedenfalls, man erwirbt diese Omwb von Oracle in irgendeiner Weise und dazu das Plugin für Access. Danach kann man mit etwas Zeitaufwand eine Access-Datenbank vollständig oracle-importfähig machen, Indizes;Constraints;Keys etc werden mit angelegt. Allerdings erzeugt dieses Omwb einige zusätzliche Objekte und man muß ziemlich herumfriemeln um ein vernünftiges Ergebnis zu bekommen. Ich habe es nicht geschafft, die DB in ein bestehendes Schema zu importieren. Aber funktionieren tutet es grundsätzlich.
Meine andere Methode war: die Tabellen aus Access per ODBC-Exportschnittstelle nach Oracle zu portieren, dabei haben sich aber mit jeder der o.g. Oracle Versionen Probleme gezeigt, nämlich alle Datenfelder waren plötzlich vom Typ VarChar2 und leer... das geschah unabhängig von der Wahl des DB-Treibers (MS ODBC für Oracle/Oracle ODBC Driver)
Außerdem konnte man direkt nach dem Export weder eine der Tabellen lesen noch hineinschreiben. Erst ein Extrahieren des Tabellen-SQLs in Oracle und ein Löschen der Tabelle und dann wieder die Erstellung der Tabelle mittels des SQLs über z.b. SQL+ Worksheet machte die Tabelle verfügbar. Darüber hinaus wurden keine Indizes, Keys, Constraints erzeugt.Deswegen habe ich mehr oder minder beide Wege verworfen und mir mittels VBS, ADOX, ADO2.5 sql-scriptdateien aus meiner Datenbank erzeugt und die Daten als XML-Offline-Recordsets aus Access gezogen.
mittels SQL+ Worksheet von Oracle konnte man die sql-scripts (CREATE TABLE ...) hintereinander ausführen, dann mit dem 2. Batchscript die Indizes erzeugen und mit einem 3. alle benötigten Sequenzen anlegen.
Die Datenübername habe ich dann mittels vbs gemacht wobei ich die XML-Recordset eingelesen habe und durchlaufen habe... do until .eof usw....Letzterer war der für mich und meinen Kunden beste Weg, zumal ich als "Abfallprodukt" dieses Vorganges jetzt auch ein unidirektionales (bald bidirektionales) Datenabgleichtool habe...
Ich hoffe, das hat dich etwas weiter gebracht.
Gruß, FrankÜberigens, zum Datenaustausch zwischen verschiedenen Oracle-Versionen klappt nicht ohne weiteres, man muß da gewisse goldene Regeln befolgen... ich schau mal in meinem Mail-Archiv nach, da stehen diese drin... kann aber 2-3 Tage dauern.
-
Hallo!
Vorab noch eine Info über meine Person. Ich bin Student des Fachbereichs Angewandte Informatik im 5. Semester und bestreite seit 1.09.02 ein Praxissemester in einer Firma. Ich habe erst ein Semester Datenbankenvorlesung genossen, wo nur die absoluten Basics vermittelt wurden. D.h.: ich bin (noch) nicht der absolute Crack. Hab also Nachsicht, wenn ich nicht alles auf Anhieb verstehe.
Da mittlerweile die Access-DB´s zu instabil, schlecht von der Performance her usw. geworden sind, soll ich (wie sonst alle Produkte der Firma) die Access-DB´s nach Oracle schiffen. Ich leiste also Pionierarbeit in dieser Firma.
Vorab eine Frage: um welche Version von Oracle handelt es sich?
7.3.x
8i
9i ?Es handelt sich um Oracle 8i.
für Oracle9i gibt es eine Migration-Workbench, mit der man von verschiedenen anderen DB-Systemen (einzeln erhältliche Plug-Ins sei Dank) über Dialoge in Oracle (ab version 7.3.2 (not absolutely sure) und höher migrieren kann, die Versionsschwelle hängt mWn an einer bestimmten Dumpformatversion)... jedenfalls, man erwirbt diese Omwb von Oracle in irgendeiner Weise und dazu das Plugin für Access. Danach kann man mit etwas Zeitaufwand eine Access-Datenbank vollständig oracle-importfähig machen, Indizes;Constraints;Keys etc werden mit angelegt. Allerdings erzeugt dieses Omwb einige zusätzliche Objekte und man muß ziemlich herumfriemeln um ein vernünftiges Ergebnis zu bekommen. Ich habe es nicht geschafft, die DB in ein bestehendes Schema zu importieren. Aber funktionieren tutet es grundsätzlich.
Den Omwb mit Access-Plugin habe ich auch schon ausprobiert. Leider hängt sich das Tool beim Migrieren der Table data von der Source database zur Oracle database immer auf.
Weiterhin gibt es noch den Oracle Migration Assistent for MS Access, der aber auch nicht funktioniert, bzw. nicht zu verstehen ist, weil gar nicht dokumentiert.
Deswegen habe ich mehr oder minder beide Wege verworfen und mir mittels VBS, ADOX, ADO2.5 sql-scriptdateien aus meiner Datenbank erzeugt und die Daten als XML-Offline-Recordsets aus Access gezogen.
mittels SQL+ Worksheet von Oracle konnte man die sql-scripts (CREATE TABLE ...) hintereinander ausführen, dann mit dem 2. Batchscript die Indizes erzeugen und mit einem 3. alle benötigten Sequenzen anlegen.
Die Datenübername habe ich dann mittels vbs gemacht wobei ich die XML-Recordset eingelesen habe und durchlaufen habe... do until .eof usw....Das habe ich nicht ganz verstanden!
Letzterer war der für mich und meinen Kunden beste Weg, zumal ich als "Abfallprodukt" dieses Vorganges jetzt auch ein unidirektionales (bald bidirektionales) Datenabgleichtool habe...
Ich hoffe, das hat dich etwas weiter gebracht.
Gruß, FrankDas hat mir schon mal sehr geholfen. Vielen Dank...
Gruß, Erik
Überigens, zum Datenaustausch zwischen verschiedenen Oracle-Versionen klappt nicht ohne weiteres, man muß da gewisse goldene Regeln befolgen... ich schau mal in meinem Mail-Archiv nach, da stehen diese drin... kann aber 2-3 Tage dauern.
Lass Dir Zeit. Ich bin schon froh, daß mir überhaupt jemand helfen will!! Danke!
-
Hi Erik,
ich kürz mal alles etwas ein :-)
Niemand hat gleich als Crack angefangen, auch ich nicht... (indirektes Eigenlob stinkt nicht ;-))
okay, ne kurze Beschreibung meines Weges:
mit Access ist man ja in einer Windows-Umgebung, d.h. man kann (ich kann es zumindest auf all meinen PCs) VB-Scripte laufen lassen, die Arbeit verrichten können. Dazu brauch man nicht unbedingt gleich VB6 Pro oder so. Dann gibt es zwei COM+ "Objekte", Active Data Objects (ADO) sowie Active Data Objects Extension for DDL & Security (ADOX)
Mit letzterem hast du besonders flexiblen Zugriff auf die Objekte (Tabellen,views etc) in einer Access-Datenbank und kannst dort auch die Feldinformation (Datentyp, Länge, Genauigkeit) usw. erfahren.
Also habe ich ein VB-Script geschrieben, was mittels ADOX auf meine Quelldatenbank zugreift und habe über eine Auflistung jede einzelne Tabelle in einer Schleife verarbeitet:
Felder erfassen, Quell-Datentypen erkennen
Datentypen korrekt umsetzen Access->Oracle-Daten
SQL-Statements (CREATE TABLE ADD...) erstellen und in eine .sql-Datei speichern. Das habe ich dem Admin zukommen lassen mit Angabe, welches Schema und welche Rechte etc.....danach habe ich dann mittels dem normalen ADO und der .save Methode die Daten aus jeder meiner Tabellen ("SELECT * FROM tabelleX") im XML-Format als Datei gespeichert.
Der Import in Oracle verlief dann mittels eines vbscriptes, welches die abgelegten XML-Recordsets eingelesen und Datensatz für Datensatz mittels .addNew in das leere Recordsetobjekt der Oracle-Verbindung geschrieben hat.
Ist halt ein selbst zusammenprogrammierter Weg... ich hoffe, mit der Erklärung hier kommst du etwas weiter.
An deiner Stelle würde ich aber wirklich mal analysierend über die alten Datenbanken drüberschauen und deinen Chefs darlegen, was da wie unperformant ist, soweit du das einschätzen kannst und darfst.
Tschö, so far, Frank
-
-
-
Ich stehe vor einem mittleren Problem. Man hat die Aufgabe zugetragen, Access-DB nach Oracle zu migrieren. Leider komme ich absolut nicht weiter. Die Access-DB´s sind über Jahre gewachsen und von Leuten nach und nach erstellt worden, die anscheinend noch nie etwas von ER-Modell, Redundanz, Transparenz usw. gehört haben.
Ich habe zwar eine Idee, indem ich die Tabellen manuell in Oracle anlege und dann die Daten per CSV-Datei nach Oracle rüberschaufele. Aber das will erst mal vermeiden, damit ich zeigen kann, daß ich mit den vorhandenen DB´s in Oracle nichts anfangen kann.
Was willst Du denn jetzt eigentlich?
Tabellen manuell anlegen und Daten rüberschaufeln geht, keine Frage, sollte auch nicht mehr als 1 Tag Aufwand sein (das meiste fürs Tabellenanlegen).Du willst aber einen Weg, der nicht funktioniert, damit Du ein Argument hast, das alte Schema wegzuschmeißen, oder wie habe ich Dich verstanden?
Natürlich ist so ein Umstieg der richtige Moment, das alte Modell wegzukippen - allerdings muß dann ja auch meist jede daranhängende Applikation neu gemacht werden...
-
Was willst Du denn jetzt eigentlich?
Tabellen manuell anlegen und Daten rüberschaufeln geht, keine Frage, sollte auch nicht mehr als 1 Tag Aufwand sein (das meiste fürs Tabellenanlegen).Ich hätte gerne eine oder mehrere Alternativen, um zu zeigen, daß es mit den vorhandenen DB-Strukturen nicht besser wird in Oracle bzw. gar nicht funktioniert.
Natürlich ist so ein Umstieg der richtige Moment, das alte Modell wegzukippen - allerdings muß dann ja auch meist jede daranhängende Applikation neu gemacht werden...
Die Applikationen werde ich so weit es geht übernehmen oder neu programmieren.
-