Zwei verschiedene (=> anderer Hersteller) Datenbanken synchronisieren?

[Wursel]

Hallo Forum,

aktuell laufen Daten einer Anwendung in eine Sybase ASE Datenbank. Da ich für Auswertungen ein paar Features benötige und die Sybase ASE DB so einiges nicht unterstützt und auch teilweise nicht sehr performant ist, überlege ich aktuell, ob ich die Daten in eine andere Datenbank überspiele (z.B. Oracle 11g) und dann darüber die Auswertungen fahre. Damit hätte ich alle Features, die ich brauche und die Geschwindigkeit wäre besser. Ich könnte auch zusätzlich mehr Indizes über wichtige Spalten anlegen. Von der Sybase ASE lasse ich die Finger weg, da der Hersteller der Anwendung diese verwaltet.

Habt ihr mir Tipps, wie ich das am besten automatisch synchronisieren könnte? Die Richtung ist immer nur von ASE zu Oracle. Das müsste auch nur selten (z.B. ein Mal am Wochenende) abgeglichen werden, da die Auswertungen immer retrospektiv sind.

Grüße
Wursel

[defo]

kommt auf die Lizensierung bei Oracle an und vielleicht auf das Datenvolumen.
Oracle auf Linux oder auf Windows? (wg Connectivity ODBC & Co)
ASE Export > Oracle sql loader
client export ASE > client import Oracle
Oracle Heterogenous Services > ASE transparent auslesen
irgendein ETL tool
irgendein DWH tool

Zu den Oracle Lizenzen. Eine Express Edition ginge ja bis 10 oder 11 Gb Volumen-weiß nicht genau-, reicht vielleicht für eine Woche. Ob die HS dabei hat weiß ich nicht, ist glaube ich in den großen Editions eine Option (Zukauf).

[kuemmelchen]

Zu Oracle 11g Express sagt Oracle:

Oracle Database XE can be installed on any size host machine with any number of CPUs (one database per machine), but XE will store up to 11GB of user data, use up to 1GB of memory, and use one CPU on the host machine.

[defo]

Ich habe auch irgendwo einen Kommentar gesehen, dass HS bei der Express Edition enthalten sind. War aber von einem Anwender nicht von Oracle selbst diese Aussage.

[Wursel]

Vielen Dank für die Antworten!

Ich versuche mich nun an folgendem Vorgehen: Unter Windows (wegen ODBC) habe ich eine Oracle XE Datenbank aufgesetzt und werde aus einer eigenen kleinen Anwendung heraus die benötigten Tabellen von Sybase zu Oracle übertragen. Da ich nur bestimmte Teile daraus brauche, liegen die Daten schätzungsweise bei unter 2 GB, sodass noch Luft nach oben ist.

Es gibt wohl noch die "Oracle Standard Personal Edition" die mit Enterprise vergleichbar sein soll, aber Singleuser. Evtl. wäre das auch interessant, da die Auswertung nur einer (i.d.R. ich selbst) gleichzeitig verwendet. Was meint ihr dazu? Ist das eine gleichzeitige Connection zur DB oder eine Person an sich, die das nutzt?

Meint ihr mit "HS" das Einbinden von Fremddatenbanken in Oracle, sodass ich dann direkt innerhalb einer Query auf beide Datenbanken zugreifen könnte? Falls ja, dann wäre das definitiv interessant. Evtl. könnte man dann sogar ziemlich schnell feststellen, welche Teile geändert wurden und dann nur speziell diese erneut zum Ziel übertragen bzw. am Ziel löschen.

[defo]

Es gibt wohl noch die "Oracle Standard Personal Edition" die mit Enterprise vergleichbar sein soll, aber Singleuser. Evtl. wäre das auch interessant, da die Auswertung nur einer (i.d.R. ich selbst) gleichzeitig verwendet. Was meint ihr dazu? Ist das eine gleichzeitige Connection zur DB oder eine Person an sich, die das nutzt?

Ich hab keine Ahnung, würde eher auf eine Person tippen (anhand der Benennung).

Meint ihr mit "HS" das Einbinden von Fremddatenbanken in Oracle, sodass ich dann direkt innerhalb einer Query auf beide Datenbanken zugreifen könnte? Falls ja, dann wäre das definitiv interessant. Evtl. könnte man dann sogar ziemlich schnell feststellen, welche Teile geändert wurden und dann nur speziell diese erneut zum Ziel übertragen bzw. am Ziel löschen.

Ja, Oracle Heterogeneous Services ist dafür gemacht. Ich würde nicht schwören, dass es in der Edition drin ist.
Wie das so ist bei Oracle, die Konfiguration zu Anfang macht nicht unbedingt Spaß, ich kann mich erinnern, dass ich mal ziemlich Schwierigkeiten mit Informix Anbindung hatte. Das lag aber vermutlich daran, das die Informixverison uralt war.
Aber wenn es läuft ist es nett. Ich würde nicht unbedingt wilde Sachen damit machen, (gezielt) Daten absaugen und den Rest nativ auf Oracle. Das sollte gut funktionieren.

P.S.: Sowas ähnliches gibt es auch von MS, da fällt mir grad der Name nicht ein. Vielleicht geht das sogar besser, aus historischen Gründen. Wenn die Datenlage übersichtlich und die Struktur halbwegs stabil ist, kann man den reinen Transport von DB A zu DB B aber evtl auch mit einem kleinen Eigenbauprogramm machen. Dann können Dir die DB Editionen und Lizenzkosten egal sein, die Server müssen sich nicht sehen usw usw.

[Wursel]

Ich habe mittlerweile ein Skript geschrieben, um die Daten zu kopieren, hänge aber gerade an einem ziemlich blöden Problem fest: Die Quelltabellen haben teilweise Spaltennamen mit über 30 Zeichen d.h. ich kann diese so nicht anlegen, sonst laufe ich in ein ORA-00972: identifier is too long.
Außer die Namen nach dem 30. Zeichen einfach abzuschneiden, fällt mir gerade nichts ein. Oder eine Datenbank nehmen, die dieses "Feature" unterstützt... Habt ihr noch eine Idee?

Bei den "Heterogeneous Services" würde ich mit diesen langen Namen vermutlich ebenfalls auf die Nase fallen. Es gibt einen Eintrag dazu, der lediglich empfiehlt, die Namen via View zu kürzen und diese View dann einzubinden. Das könnte ich insofern nicht machen, da ich die Finger von der Quelldatenbank lasse. Die wird fremdsupportet und da halte ich mich raus. Abgesehen davon will man solche Workarounds eigentlich auch nicht machen (müssen)...
http://knowledgebase.progress.com/articles/Article/5753

Grüße,
Wursel

[defo]

Welcher Art ist denn Dein Script? Wie greifst Du die Daten darin ab?
Es spricht ja nichts gegen Abschneiden, wenn die Feldnamen dabei eindeutig bleiben.
eine Option:
Schritt a) Daten irgendwie exportieren > CSV, ..
Schritt b) Daten per External Table in Oracle einlesen, dabei kann man Feldnamen mappen.

Meines Wissens nach gibt es selbst unter Oracle12 keine längeren Feldnamen und auch keine direkten Workarounds.

Und wie oben irgendwo gesagt, das Prinzip von HS gibt es alternatiiv auch unter MS SQL Server, weiß immer noch nicht, wie die das nennen.

[Wursel]

Ich habe ein PHP-Skript geschrieben, welches via ODBC auf die beiden Datenbanken zugreift und die Tabellen von A nach B kopiert. Dort habe ich nun das Abschneiden der Spaltennamen auf max. 30 Zeichen reingebaut und das funktioniert jetzt (am Ziel wurden die Tabellen natürlich auch mit gekürzten Spaltennamen angelegt). Aktuell bin ich testweise am rüberziehen der kompletten Daten und schaue, ob und falls ja wo es noch knallt und wie lange das unterm Strich dauern wird.

Eigentlich hätte ich mir auch mal eine MS-SQL DB anschauen können - die ist ja von der Struktur und historisch her am ähnlichsten zur Sybase DB.

[defo]

Ich habe ein PHP-Skript geschrieben, ..

Das stelle ich mir nicht ganz so schnell vor oder zumindest nicht so schnell, wie möglich. Liegt PHP auf dem gleichen System wie Oracle?
Dann würde ich External Tables einsetzen (also im Prinzip, wenn man die CSV Quellen problemlos auf den Oracle Server bekommt):
- CSV aus Quellsystem auf Oracle Server bereitstellen,
- ExternalTable(s) definieren und
- transpranet abfragen, nicht laden.

ETL:
Aus den external Tables alles extrahieren, transformieren was notwendig ist für die Auswertung, wenn möglich schon mit größt möglicher Aggregation und die Daten dann in separaten Reportingtabellen bereitstellen.
Bei Bedarf Auswertung der .bad und .log files
Ab da hast Du alles mit Oracle im Griff (auch Importfehler) und es ist recht flott.

[Wursel]

Das stelle ich mir nicht ganz so schnell vor oder zumindest nicht so schnell, wie möglich.

Ja das stimmt allerdings - das ginge mit Sicherheit sehr viel schneller, wenn ich das anders machen würde. Für meinen Bedarf reicht es, da ich das nur am Wochenende aktualisieren brauche. Die Auswertungen werden immer über länger zurückliegende Zeiträume gezogen. D.h. bis zum letzten Monatsende innerhalb des laufenden Monats. Für ganz aktuelle Sachen gibts ja nach wie vor den aktuellen Datenbestand wie bislang auch. Aber... schneller ist natürlich immer besser.

Liegt PHP auf dem gleichen System wie Oracle?

Nein das liegt alles verteilt im Netzwerk. Sybase ASE liegt auf einem Server, PHP auf einem anderen und die Oracle XE auf einem dritten. D.h. die Daten wandern aktuell über drei Server hinweg (ASE-Server => PHP-Server => XE-Server).

Die Haupttabellen sind in ca. 15 Minuten überspielt (Holzhammer: DELETE FROM tableX und dann mit INSERT INTO tableX alles neu rein). Die Faktentabellen brauchen jedoch ~4h 10Min. Insgesamt liege ich also bei etwa ~4 1/2 Stunden. Das ist alles natürlich vollkommen unoptimiert. Sozusagen Proof-of-Concept und das was ich wollte, ist erreicht. Der Flaschenhals in der Kette ist ganz klar der Platten I/O vom Oracle XE Server. Da könnte man sicherlich noch was rausholen (kein Transaktionslog und mehr cachen?).

Jedoch überlege ich natürlich schon, ob ich da noch was beschleunigen könnte. Beispielsweise könnte ich den Zeitstempel der Quelldatensätze prüfen (wird mitgeführt) und nur die Zeilen selektieren, die neu (also nach dem Exportzeitpunkt) sind und ausschließlich diese übertragen. Wobei dann das gewohnte Spiel los geht: INSERT oder UPDATE und zudem extra überprüfen was ggf. DELETEd werden muss...

Wegen External Tables: Wie sieht es da mit der Abfrageperformance aus, wenn die nicht rein geladen werden? Werden dann extra Indices aufgebaut?

[defo]

Wegen External Tables: Wie sieht es da mit der Abfrageperformance aus, wenn die nicht rein geladen werden? Werden dann extra Indices aufgebaut?

Das ist ein direkter Zugriff auf die CSV oder was auch immer, meines Wissens nach, gibt es da keine Indizierung.
Aber apropos Indizierung: Du solltest die auf den Zieltabellen erst nach dem Befüllen der Tabellen aktivieren. Das spart die Indexverwaltung während des Ladens.

Ich würde nur einmal auf die CSV zugreifen, eben zum Laden. Wenn Du auf PHP verzichtest, kannst Du auch den Oracle Loader einsetzen. Ich weiß allerdings nicht, wieviel das bringt im Vergleich zu CSV external Tables.

[dimitri]

(Holzhammer: DELETE FROM tableX und dann mit INSERT INTO tableX alles neu rein).

Statt DELETE FROM ein TRUNCATE TABLE xyz verwenden. Den Insert als direct path load durchführen: INSERT /*+APPEND*/ INTO ...
Dann brauchst du dir auch keine Gedanken wegen der Indices zu machen, die werden beim direct path load separat aufgebaut und dann hinzugefügt.

Die Tabelle mit NOLOGGING definieren: alter table xyz nologging; Damit werden beim direct path load keine Redo Logs geschrieben.

Externe Tabellen sollten nur zum Laden von echten Tabellen verwendet werden, für normale ad hoc Abfragen ist das viel zu langsam.

@defo: SQLLoader und external tables sind gleichwertig zu sehen. Jedes Tool hat Vor- und Nachteile bei der Benutzung, die Performance ist identisch.

[defo]

Den Insert als direct path load durchführen: INSERT /*+APPEND*/ INTO ...
Dann brauchst du dir auch keine Gedanken wegen der Indices zu machen, die werden beim direct path load separat aufgebaut und dann hinzugefügt.

Die Tabelle mit NOLOGGING definieren: alter table xyz nologging; Damit werden beim direct path load keine Redo Logs geschrieben.

@defo: SQLLoader und external tables sind gleichwertig zu sehen. ..die Performance ist identisch.

Direct path mit auto indexing, das wusste ich nicht, prima.
Ist für nologging nicht auch ein extra nologging tablespace notwendig?

Ich hab immer "das Gefühl", dass die External Tables eh über den Loader realisiert sind. Also andere Feature, gleiche Engine.

[dimitri]

Ist für nologging nicht auch ein extra nologging tablespace notwendig?

Nein brauchst nicht. Ein TS der mit NOLOGGING angelegt wird, vererbt diesen Parameter an "seine" Tabellen.
Wichtig ist zu wissen, dass solche Tabellen nicht durch ein RMAN Backup wiederherstellbar sind, wenn nicht nach dem Direct Load mit NOLOGGING ein Full Backup gefahren wird.

Ich hab immer "das Gefühl", dass die External Tables eh über den Loader realisiert sind. Also andere Feature, gleiche Engine.

Das ist vermutlich auch so. :-)