Transport Daten MSSQL --> ORACLE

Sorry, dass ich einen neuen Artikel aufmache, ist aber einfach zu dringend…

Erst mal ein Dankeschön an Euch drei.

Ich muß die Daten alle fünf Minuten aus der MSSQL Datenbank holen, wollte das halt mit JavaThreads lösen. Der Treiber für die JDBC-ODBC-Bridge ist mit installiert. Das Problem ist, es gibt scheinbar keine ODBC Treiber (für MSSQL Datenbanken), für die Sparc-Plattform.

noch mal das Konstrukt

Sparc Server
Sun Solaris 5.8
lokale DB ORACLE
Webserver

NT-Server
Intel
MSSQL DB

Meine DB auf dem Sparc Server muß nun regelmäßig mit verschiedensten Daten gefüllt werden, so auch mit Datensätzen aus der MSSQL DB.

Danke schon im voraus
Dennis

P.S. an Dieter, was ist DT5 ???

Sorry, dass ich einen neuen Artikel aufmache, ist aber einfach
zu dringend…

? Meinst Du, dann wissen die Leute schneller, was Sache ist?

Ich muß die Daten alle fünf Minuten aus der MSSQL Datenbank
holen, wollte das halt mit JavaThreads lösen.

Der Treiber für
die JDBC-ODBC-Bridge ist mit installiert.

Soweit ich das in Erinnerung habe, ist die JDBC-ODBC-Bridge von Sun nur ein Spielzeug, um die Programmierung zu üben. Für Produktiveinsätze sollte sie nicht verwendet werden.

Das Problem ist, es
gibt scheinbar keine ODBC Treiber (für MSSQL Datenbanken), für
die Sparc-Plattform.

Vielleicht kannst Du das vom anderen Ende aus betrachten. Für NT gibt es ODBC-Treiber in allen möglichen Variationen, also sowohl für MSSQL als auch für Oracle. Schalte dann irgend etwas dazwischen, das sich auf beide Datenbanken connectet, z.B. Access.
Dann kannst Du sowohl die Oracle- als auch die MSSQL-Tabellen einbinden und per Abfrage ineinander übertragen.

Per at-Befehl kannst Du dies alle 5 Minuten ausführen lassen (Halt! Mit soon.exe, da at nicht minutengenau arbeitet).
Alternativ kannst Du die Access-Anwendung ständig laufen lassen und die Abfragen per Timerereigneis steuern.

Gruß

J.

es ist auch denkbar, die datenreplikation über das web ablaufen zu lassen. ich sage nur xml!!

/sf

Da fällt mir noch das Oracle Transparent Gateway ein: installieren, DB-Link auf die MSSQL-DB erstellen und inserts/updates über DBMS_JOB laufen lassen…

Gruß

J.

ich sage nur xml!!

Das hab ich dem ADAC-Mitarbeiter das letzte Mal auch gesagt, und trotzdem hat er nur abschleppen können. :frowning:

Grüße, Robert

Dank
Danke Euch für Eure Tips, werde mir da was einfallen lassen (müssen).

Dennis

Auch nach maximalster abstraktester Betrachtung Deines Statements erkenne ich keinen Sinn und keinen Zusammenhang mit XML. Bitte kläre mich auf!!

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Auch nach maximalster abstraktester Betrachtung Deines
Statements erkenne ich keinen Sinn und keinen Zusammenhang mit
XML. Bitte kläre mich auf!!

Hmmm, also was ich damit sagen wollte ist, das XML sehr viel Hype (wie so vieles andre) war und vielleicht noch ist.

Einige Zeit lang hat man von gewissen Marketing- und Vertriebsmenschen zum Thema Anwendungsintegration sehr oft hören müssen „Warum nehmt ihr nicht einfach XML?“

Und deine Aussage „Ich sag nur XML“ hat mich da einfach ein bißchen daran erinnert, war nicht böse gemeint. :o)

Es wäre zwar eine Möglichkeit das über Web (also HTTP) und XML-Daten zu machen, das würde aber einen relativ grossen Aufwand erfordern. AFAIK kann Oracle zwar XML exportieren, MS SQL Server weiss ich aber nicht ob da schon Funktionen hat, geschweige davon, dass beide dann dieselben XML-Dateien erzeugen würden.

Würde dann schon irgendwie ein bißchen in Richtung Middleware gehen. :o)

Grüße, Robert

kann man mit diesem gateway auch db-links zu anderen rdbms erstellen (z.b. zu einer SQLBase von Centura)??

der jan

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

SQL unterstützt XML, definitiv. Ob die Files gleich aussehen ist nicht die Frage sondern der Sinn von XML! Keine Datenbank hat ihr eigenes Format - ja vielleicht durch Wizards, aber XML heißt auch erstmal Inhalt und die Struktur (Tags) definieren und dann ist’s gleich.
Middleware ist meines Erachtens in diesem Fall nicht sinnvoll - obwohl aus IT-Sicht die Beste. Die Schnittstelle zwischen nur 2 Datenbanken legitimiert keinesfalls den Aufwand und die Anschaffungskosten, geschweige von den Unterhaltskosten oder dem TCO. Ein richtiges Datawarehousing á la Corba o.ä. rentiert sich IMHO erst mit >5 RDMS - wenn man überhaupt einen ROI daraus bekommen will. Die weitere Schwierigkeit beim Einsatz einer Middleware ist die lange Preimplementierungsphase, die sicherlich nötig ist, um sich nicht in eine Sackgasse zu manövrieren (ich spreche aus schlechter Erfahrung ;])

Grüße, Stefan.

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Hi,

kann man mit diesem gateway auch db-links zu anderen rdbms
erstellen (z.b. zu einer SQLBase von Centura)??

Das habe ich noch nicht gesehen, ich vermute mal ja. Der TG läßt die entfernte Datenbank so aussehen, als wäre sie eine Oracle-Datenbank (siehe http://otn.oracle.com/products/gateways/faq.html). Dort steht Centura nicht drauf, aber es gibt eine „generic connectivity“, die es vielleicht doch schafft. Aber eigentlich bin ich überfragt.

Gruß

J.

…aber Robert auch.
Middleware ist hier ganz klar zuviel Aufwand. Für eine reine Datenübernahme, bei der sowohl Quell- als auch Zielsystem bekannt sind, und worüber man die Datenhoheit hat, ist eine XML-Konvertierung aber auch nicht nötig. Am simpelsten geht das wohl über einen Zwischenteil, der beide Systeme kennt - da ist ODBC die günstigste Alternative.

Gruß

J.

Gleich vorweg, war ein Mißverständnis, ich wollte nicht vorschlagen, da jetzt eine irgendwie geartete Middleware einzusetzen, siehe unten. :o)

SQL unterstützt XML, definitiv. Ob die Files gleich aussehen
ist nicht die Frage sondern der Sinn von XML! Keine Datenbank
hat ihr eigenes Format - ja vielleicht durch Wizards, aber XML
heißt auch erstmal Inhalt und die Struktur (Tags) definieren
und dann ist’s gleich.

Was ich meinte, ist das ich mir nicht sicher wäre ob es möglich ist mit beiden Datenbanken dasselbe Format zu definieren. :o)

Falls das machbar ist, dann wäre es sicher eine Variante, auch wenn ich Datenaustausch über das lokale bzw. über Netzwerk-Dateisystemen HTTP vorziehen würde.

Middleware ist meines Erachtens in diesem Fall nicht sinnvoll

Nein, wäre überzogen.

Hier meinte ich wiederum nur, dass eine Lösung bei der man selber Schnittstellen die XML Daten generieren implementiert und die dann über HTTP kommunizieren läßt schon in Richtung der Funktionalität einer Middleware geht.

Wie gesagt, ich hätte nicht gedacht, dass beide Datenbanken schon entsprechende Tools besitzen, dann fällt das natürlich weg und XML wird zu einem leichter gangbaren Weg. :smile:

  • obwohl aus IT-Sicht die Beste. Die Schnittstelle zwischen
    nur 2 Datenbanken legitimiert keinesfalls den Aufwand und die
    Anschaffungskosten, geschweige von den Unterhaltskosten oder
    dem TCO.

Job, das Zeug ist verdammt teuer. :o)

Grüße, Robert

Ich stimme Dir zu, das eine ODBC-Connection wohl die naheliegenste Lösung ist - aber ohne Zwischensystem. Am einfachsten die Angelegenheit passiert vom SQL-Server aus, da Microsoft sich in letzter Zeit viel Gedanken über Migration gemacht hat (warum wohl?). Obwohl hoffentlich niemand ernsthaft sein Oracle rausschmeißt und dafür MSSQL reinsetzt sind diese Migrations- bzw. Lagacytools ganz brauchbar geworden.

LG, Stefan.

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]