Offene Anfragen auf einem Datenbankserver?

[Valentin Velazquez]

Hi,
ich habe folgendes Problem:
In meinem java code frage ich über jdbc den server nach einem resultset (sql statement wird abgeschickt). Die Resultsetvariable im code wird unter umständen aber erst 10 std. später verwendet, um die Daten vom DBServer abzufragen (Bitte nicht drüber diskutieren, die erklärung würde Seiten dauern und es geht auch eher um ein mögliches Konzept).

Wie sieht es bei einem solchen Szenario mit der Dateninkonsistenz aus?
bekomme ich die Daten, die auf dem Server waren, als das statement abgesetzt wurde? Oder bekomme ich die Daten, die dann in der Datenbank sind, wenn ich mit dem resultset tatsächlich darauf zugreife? (Bedenke Daten könnten sich in der Zwischenzeit geändert haben)

Gruss

Val

[Bernhard Geyer]

Du bekommst die Daten zum Abfragezeitpunkt. Deine Daten liegen (außer bei großen Resultsets) sofort auf dem Client vor.

[dimitri]

Hi,

Du bekommst die Daten zu dem Zeitpunkt als die Query abgeschickt wurde. Und da liegt vermutlich auch dein Problem.
Sollten in diesen 10 Stunden die Daten geändert und committet werden, muss Oracle, um einen konsistenten Stand zu bekommen, aus dem UNDO nachlesen. Da die andere Transaktion aber schon committet wurde, kann der entsprechende Block im UNDO bereits überschrieben worden sein. Du bekommst dann einen ORA-01555 Snapshot too old Fehler und musst die Query nochmal starten.
Als Lösung könnte man die undo_retentention entsprechend hoch setzen, allerdings hätte das ggf. zur Folge, dass dein UNDO TS, je nach dem wieviele Änderungen auflaufen, sehr sehr groß wird.

Bitte nicht drüber diskutieren, die erklärung würde Seiten dauern und es geht auch eher um ein mögliches Konzept

Ja ist besser so, denn dann könnten ja andere Lösungsmöglichkeiten hervorkommen wie z.B. Flashback Query o.ä. Aber neue Konzepte sollte man besser nicht hinterfragen.

Dim

[Falk Prüfer]

Hallo Val,

bei Oracle gibt es absolute Datenkonsistenz, d.h. du würdest nach 10h die Daten zum Abfragezeitpunkt bekommen. Da Oracle diesen Snapshot vorhalten und alle anderen Transaktionen ebenfalls völlig transparent halten muß, ist es allerdings wahrscheinlicher, daß du nach 10h einen "ORA-01555: snapshot too old" bekommst, da irgendwann das benutzte Rollback-Segment voll ist.

P.S.: Über die Sinnhaftigkeit einer "10h-Pause" möchte ich an der Stelle auch lieber nicht diskutieren Ich kann mir tatsächlich nichts vorstellen was dies rechtfertigen würde.

Gruß Falk

[Valentin Velazquez]

@dimitri: NP, ich kann mit Sarkasmus gut umgehen^^.

Was für Alternativen könntest du denn anbieten? Ich möchte halt die Daten so haben, wie wie beim abschicken der Anfrage, aber sie erst später "abholen".

Gruss

Val

[Valentin Velazquez]

ok, hab da ma gegoogelt nach "Flashback Query". ist das was ich brauche^^.
Gibt es solche Konzepte auch für andere Datenbanken? (zB MSSQLServer, etc).

Gruss

Val

[dimitri]

Gibt es solche Konzepte auch für andere Datenbanken? (zB MSSQLServer, etc).

Da kann ich nichts dazu sagen, aber wenn es darum geht die Daten erst später abzuholen, könnte man ja auch ein INSERT INTO um das sql packen und es in eine extra Tabelle schreiben.
Das hätte den Vorteil, dass man nicht ständif an der DB angemeldet sein muss (kann ja mal Probleme mit dem netzwerk o.ä. geben) und auch der UNDO Bereich muss nicht bis ins Unendliche wachsen damit man einen historischen Stand von anno dazumal abrufen kann.
Ist dann auch datenbankunabhängig.

Geht natürlich nur, wenn die Abfragen immer gleich sind bzw. es nur eine handvoll unterschiedlicher Abfragen gibt.

Dim

[Valentin Velazquez]

Ich kann ja mal das Szenario hier kurz erläutern:

Ich habe einen Client (keine DB sondern ein Prog), einen eigenen DB Server (der auch importiert) und zusätzlich jetzt noch eine FremdDB (die nicht unbedingt eine Oracle sein muss).

Der Client trifft eine Auswahl, was von der FremdDB importiert werden soll (auswahl vordefinierter Statements). Gedacht war es eine ImportSpec zu erzeugen, wo halt die nötigen Infos für den DBServer sind, um die Daten dann aus der FremdDB zu holen)
Der eigene DBServer hat eine ImportQueue in der die imports nacheinander abgearbeitet werden. Deshalb kann es ja auch zu den verzögerungen kommen.

Wir reden hier von Datengrössen im GB Bereich. In der FremdDB sind teilweise Tabellen mit MEHREREN millionen Datensätzen.

-Netzwerkverkehr von den Clients sind zu minimieren
-Clients sollen auch nicht unbedingt schreibzugriffe auf die FremdDB bekommen.

Vlt fällt euch ja mit diesem Wissen ne Möglichkeit ein, wie man die Daten aus der FremdDB gut in den DBServer importieren kann.

Der grosse Vorteil, wenn man den Import erst dann ausführt, wenn er in der Jobqueue dran ist, ist, dass man die Daten nur einmal aus der FremdDB anfragen muss.

Gruss

Val

[dimitri]

Ok. Also wenn ich die Datenmengen sehe, dann würde ich das Javaprogramm auch direkt wieder vergessen. Hier muss man ein bissl anders herangehen.

Es gibt von Oracle die sog. Heterogeneous services, mit denen man dann per Database Link auf Datenbanken anderer Hersteller zugreifen kann.

Dann würde ich über deinen Client nur noch die SQLs in eine Tabelle (ImportQueue) schreiben die dann abzuarbeiten sind.

Den Umweg über JDBC halte ich für viel zu langsam wenn es um solche Datenmengen geht - hier muss man direkt und ohne Umwege auf die andere DB zugreifen.

Hier ist mal ein kleines Beispiel wie das vom Umfang her läuft.

Transparent Gareways läuft ähnlich kostet aber extra wenn ich mich recht entsinne, während bei der anderen Methode über einen ODBC Treiber gegangen wird. Muss man eben testen, ob letzteres schnell genug ist.

Dim