Tomcat von MySQL auf Oracle

Helios co.

Lt. Commander
Registriert
März 2005
Beiträge
1.863
Hallo @all,

hoffentlich bin ich mit meiner Frage im richtigen Forum. Falls dem nicht so sein sollte hier shcon mal im Voraus meine Entschuldigung.

Und jetzt zur Frage: Ich habe eine Anwendung, die Tomcat und MySQL benutzt. Nun möchte ich aber MySQL gegen Oracle eintauschen. Leider kenne ich mich mit Tomcat nicht sonderlich gut aus und weiß nicht wo und welche Anpassungen ich vorzunehmen habe.

Ich denke, dass in der context.xml einiges anzupassen ist. Wo und was aber noch?

Bin dankbar für jeden Rat.
 
Tomcat ist ein Webserver, ein Webserver nutzt gar keine Datenbank.
Deine Web-Anwendung, die du innerhalb von Tomcat nutzt, muss geändert werden. Ein einfaches austauschen der Datenbankverbindung wird garantiert nicht reichen, da die SQL-Dialekte von beiden nicht komplett kompatibel sind (proprietäre Erweiterungen).
 
entscheidender ist nicht der Dialekt, -der könnte sogar kompatibel sein, man braucht aber gänzlich verschiedene Treiber..

Soll heissen der für Oracle ist der Kommerzielle Ora Client 8/9/10/11 und dann kommt es auch noch auf die Anwendung drauf an, bei Tomcat tippe ich einfach mal auf Java..
MySql ist ja bei allen Webentwicklungssprachen schon meist dabei...
 
Zuletzt bearbeitet:
@ice-breaker:

Tomcat ist ein Webserver, ein Webserver nutzt gar keine Datenbank.

Habe ich das falsch verstanden: Ich war immer der Meinung, dass die Anwendung via Tomcat mit der Datenbank kommuniziert?

bei Tomcat tippe ich einfach mal auf Java..

Richtig.

entscheidender ist nicht der Dialekt der könnte sogar kompatibel sein, man braucht aber gänzlich verschiedene Treiber..

Leider gibt es kleinere Unterschiede. So kennt Oracle beispielsweise kein "LIMIT" und auch einige Datentypen unterscheiden sich, so dass ich zumindest noch das Schema anpassen und damit eigentlich alle Queries ändern muss.

Welche Treiber meinst du? Den Oracle jdbc? Der liegt bereits im /lib/ vom Tomcat. Das ist ja im Grunde meine Frage: Was muss ich am Tomcat ändern, wenn ich meine Anwendung auf eine andere Datenbank migrieren will.


Schon mal vielen Dank für die Antworten!
 
Das wird dir niemand sagen können weil niemand weiss wie du den Datenbankzugriff implementiert hast.
Evtl. reicht schon das Ändern eines import an der richtigen Stelle.


Ohne stored procedures und nur mit Standarddatentypen wie zb number / varchar / timestamp und schon migrierter Datenbank sollte es eigentlich keine Probleme geben.

So sachen wie limit / row count tauchen in durchdachten Abfragen sowieso nicht auf^^
 
Zuletzt bearbeitet:
DerYvo schrieb:
MySql ist ja bei allen Webentwicklungssprachen schon meist dabei...
da die MySQL-Treiber mitlerweile unter der GPL stehen, sind sie nicht immer dabei ;)

Helios co. schrieb:
Habe ich das falsch verstanden: Ich war immer der Meinung, dass die Anwendung via Tomcat mit der Datenbank kommuniziert?
neija es funktioniert so:
  • du rufst in deinem Browser eine Webseite auf:
    1. eine HTTP-Verbindung zum Webserver (Tomcat) wird durchgeführt
    2. Tomcat behandelt das ganze HTTP Protokoll und ruft dann deine Webserver-Anwendung auf
    3. deine Webserver-Anwendung arbeitet und gibt Daten zurück
    4. Tomcat schickt diese an den Browser
also ist die Aufgabe von Tomcat als Webserver nur das HTTP-Protokoll zu sprechen und deine Endpoints in deiner Webanwendungen aufzurufen. Jegliche Verarbeitung, Datenbankgeschickten usw. macht deine Anwendung, also dein Web Archive

Helios co. schrieb:
Leider gibt es kleinere Unterschiede. So kennt Oracle beispielsweise kein "LIMIT" und auch einige Datentypen unterscheiden sich, so dass ich zumindest noch das Schema anpassen und damit eigentlich alle Queries ändern muss.
gut das du das weist, in deinem Eingangspost klang es nämlich so, als ob du dachtest, dass du einfach den Datenbanktreiber ändern musst und du bist fertig.

Helios co. schrieb:
Welche Treiber meinst du? Den Oracle jdbc? Der liegt bereits im /lib/ vom Tomcat. Das ist ja im Grunde meine Frage: Was muss ich am Tomcat ändern, wenn ich meine Anwendung auf eine andere Datenbank migrieren will.
Java kann von Haus aus nicht mit Datenbanken sprechen, dafür ist ein Datenbanktreiber (Connector) notwendig (JDBC). Diesen musst du dir eben für eine Oracle-Datenbank besorgen. Wie gesagt muss dann auch nicht Tomcat geändert werden sondern deine Applikation, die mit MySQL arbeitet.

DerYvo schrieb:
So sachen wie limit / row count tauchen in durchdachten Abfragen sowieso nicht auf^^
natürlich braucht man diese. Schonmal an Pagination gedacht? Und es gibt noch viele weitere Fälle.
 
Ka wie das bei Java aussieht, bei allen anderen Sprachen die ich (besser) kenne, c, c++, php, python, perl geht im Grunde ohne Oracle Client nix.

Und den kann man sich nicht einfach wo runterladen wie den MySql...
 
@DerYvo

Ich bin mir nicht ganz sicher was du in diesem Fall unter dem "Oracle Client" verstehst. Im Grunde reicht für Java die ojdbc6.jar um mit einer Oracle Instanz zu kommunizieren.

Der Instant Client von Oracle ist übrigens durchaus frei erhältlich und Oracle ist für nicht-kommerzielle Zwecke auch kostenlos. Oder reden wir hier an einander vorbei?


Hmm ok, dann schaue ich zunächst in der Anwendung, ob ich irgendwo DB spezifischen Kram finde.
 
Der Oracle Instant Client ist meines wissens nach nur frei für Entwickler aber nagel mich nicht drauf fest.

@ice-breaker für so Dinge wie pagination bringt das jeweilige fetch im Normalfall schon mehr als genug Funktionen mit..
 
Zuletzt bearbeitet:
Hmm, in der Anwendung selbst finde ich keine Angaben zur Datenbank. Zumindest nicht direkt. Das Diong wurde mit Hilfe von Maven erstellt und hat dadurch eine einheitliche Struktur.

Es gibt Testklassen und Testressourcen, in denen auch eine Testdatenbank angegeben wird. Diese hat aber nichts mit der eigentlichen Datenbank zutun.

In der context.xml vom Tomcat habe ich jedoch für die Anwendung und einige zusätzliche Module die etwas mit der Anwendung zutun haben, folgende Einträge:

Code:
<Ressource
 name="jdbc/[B]anwendung[/B]"
 type="javax.sql.DataSource
   .
   .
   .
 DriverClassName="com.mysql.jdbc.Driver"
 url="jdbc:mysql://localhost/[B]anwendungsdatenbank?autoreconnect=true&amp usw.[/B]
 username="xxx"
 password="yyy"
   .
   .
   .
/>

D.h. wenn ich das richtig interprätiere, muss ich im Prinzip hier die Änderungen vornehmen. Und zwar für jedes Modul.

Die Frage ist nur, wie die DriverClassName für Oracle heißt?
 
Zuletzt bearbeitet:
Helios co. schrieb:
Die Frage ist nur, wie die DriverClassName für Oracle heißt?
Das kannst du im Zweifelsfall direkt aus der .jar-Datei auslesen. Das sind im Prinzip nichts anderes als zip-Archive mit anderer Endung, du kannst sie also mit jedem zip-Programm öffnen und findest die .class-Dateien.
 
DerYvo schrieb:
@ice-breaker für so Dinge wie pagination bringt das jeweilige fetch im Normalfall schon mehr als genug Funktionen mit..
und wie sollte fetch die Ergebnissanzahl begrenzen können, wenn es keinen LIMIT-Befehl gibt? ;)
 
Du bist ja schon fast soweit.

Du musst in der context.xml 2 Stellen anpassen

DriverClassName="oracle.jdbc.driver.OracleDriver"
url="jdbc:oracle:thin:@HOSTNAME_DER_ORACLE:1521:INSTANZNAME_DEINER_DATENBANK"


Die url ist der sogenannte JDBC-Connection String und dessen Syntax ist abhängig vom verwendeten Datenbanktreiber.

Dieser ganze Resource-Abschnitt in der context.xml definiert eine "Datasource". Über diese kann deine Webanwendung Datenbankverbindungen anfordern, mit der Datenbank arbeiten und dann die Verbindung wieder zurückgeben. Gleichzeitig wird bei Tomcat i.d.R. auch ein ConnectionPool eingerichtet, damit das Aufbauen einer Verbindung nicht so auf die Performancebremse tritt.


Die eigentliche Migration der Datenbank ist etwas schwerer:

Du musst, wie du schon erkannt hast das Schema soweit anpassen, dass Oracle damit klar kommt.
Als zweiten Schritt musst du deine Anwendung mal prüfen, wie sie auf die Datenbank zugreift. Je nachdem, was benutzt wird ist es deutlich aufwändiger.

Wenn die Anwendung die Datenbank direkt mit SQL anspricht, dann musst du prüfen, ob die Statements alle Oracle-kompatibel sind, d.h. alle MySQL spezifischen Befehle müssen durch Oracle-Varianten ersetzt werden. Als Beispiel ist ein großer Unterschied zwischen MySQL und Oracle ist z.B. wie Primärschlüssel erzeugt werden. Bei MySQL gibt es autoincrement-Spalten und bei Oracle nicht, dort werden Schlüssel über sogenannte Sequenzen erzeugt, die man vor dem INSERT abfragen muss.

Wenn soetwas wie JPA/Hibernate verwendet wird, dann ist es deutlich einfacher. Dort stellt man den SQL-Dialekt einfach auf Oracle um und kann sich das Schema sogar direkt erzeugen lassen. Um Statements muss man sich normalweise dann auch nicht mehr kümmern, die werden zur Laufzeit automatisch generiert.


Als letztes wirst du vermutlich die existierenden Daten migrieren wollen. Je nachdem wie unterschiedlich die Schemate ausfallen kann das sehr kompliziert werden. Im einfachsten Fall erzeugst du einen Dump der aus lauter INSERT-Befehlen besteht und im schlimmsten Fall musst du ein eigenes Programm schreiben, was die Daten aus der alten DB in die neue transformiert.



EDIT:
Kleine Anmerkung noch. Die Stelle wo in deiner Anwendung die Datenbank angesprochen wird muss ja den Namen der Datasource verwenden, d.h. dass irgendwo "jdbc/anwendung" auftauchen muss.
 
@All:

Vielen Dank für die zahlreichen Beiträge!

@Banthor

Vielen Dank für deine Anleitung! Habs genau wie beschrieben gemacht und es scheint auch zu klappen. Aktuell wirft er zwar noch eine Exception, was aber daran liegen dürfte, dass das Schema und Queries noch nicht angepasst sind.

Hierzu auch direkt meine nächste Frage: Und zwar bin ich mir nicht sicher, wie ich einige MySQL Datentypen zu Oracle Datentypen überführen soll. In erster Linie stellen die Zeit-Datentypen ein Problem dar:

Code:
reg_date TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
request_time DATETIME NOT NULL DEFAULT '1850-01-01 00:00:00'
birthday DATE

Hat jemand eine Idee welche Oracle Datentypen ich für die 3 Beispiele verwenden könnte?

Vielen Dank im Voraus!



Nachtrag:

Hat sich erledigt. Hier : http://download.oracle.com/docs/cd/B10501_01/win.920/a97249/ch3.htm gibt es eine gute Übersicht.
 
Zuletzt bearbeitet:
Zurück
Oben