View Full Version : View lesen
Moin *all
wir haben eine view mit 3,29 Mio Sätzen
Holen wird diese Daten über ODBC auf einen PC, bricht der Vorgang nach ca 2,5 mio Sätze ab.
Lese ich die Daten im ACS über "Sql ausführen" hört er auch nach rd. 2,5 Mio Sätzen auf.
(oben in der Kopfleiste: Keine Rückmeldung)
Kopiere ich die View in eine Datei
create table L/F as (select * from V) with data
und lasse die Datei abholen, klappt alles
einer ne Idee?
der
ILEMax
Ach ja ....
Die View wird von 'Oracle' mit einem IBM I Treiber (von Oracle) abgeholt.
select * from lib.view@DB2
Kann es sein das da ein "for read only" oder ähnliches noch gemacht werden muß?
Im Joblog des QRWTSRV Jobs habe ich
"..Satz xxx wird von Job oder Transaktion NR/USER/JOB benutzt"
gefunden.
Ich dachte eine View ist 'per se' nur lesend, wenn sie über mehrere Dateien geht.
Kann ICH die View als nur lesbar deklarieren?
Alles was ich im Netz gefunden habe klappt nicht. War wohl für ander DB's
Nein, das liegt am Transaktionsverhalten.
Da von Oracle ggf. der Transaktionstyp Snapshot oder CursorStability oder ReadCommitted gewählt wird, verlangt Oracle eben, dass während des Lesevorganges keine Daten geändert werden sollen.
Bei Satzsperren schlägt dann die Satzwartezeit oder die SQL-Timeoutzeit (meist 30 Sekunden) zu.
Da dies i.d.R. bei so vielen Sätzen in der verfügbaren Zeit nicht gewährleistet werden kann, so sollte hier ein anderer Transaktionstyp (ReadUncommited) gewählt werden, oder du kopierst die Daten halt, wie du es schon gemacht hast.
Kann es sein das da ein "for read only" gemacht werden muss?
Hast Du das mal probiert?
Vielleicht setzt Du dann auch noch explizit ein WITH NC (ohne Commitment Control) dazu:
SELECT * from View
For Read Only
With NC;
Nein, das liegt am Transaktionsverhalten.
Da von Oracle ggf. der Transaktionstyp Snapshot oder CursorStability oder ReadCommitted gewählt wird, verlangt Oracle eben, dass während des Lesevorganges keine Daten geändert werden sollen.
Bei Satzsperren schlägt dann die Satzwartezeit oder die SQL-Timeoutzeit (meist 30 Sekunden) zu.
Da dies i.d.R. bei so vielen Sätzen in der verfügbaren Zeit nicht gewährleistet werden kann, so sollte hier ein anderer Transaktionstyp (ReadUncommited) gewählt werden, oder du kopierst die Daten halt, wie du es schon gemacht hast.
... die Hypothese könnte man ja noch verifizieren, per DSPRCDLCK auf eine der PFs.
D*B
Zumindest deuete dies auch nicht auf einen ODBC-Zugriff sondern auf einen DRDA-Zugriff hin:
Im Joblog des QRWTSRV Jobs habe ich
"..Satz xxx wird von Job oder Transaktion NR/USER/JOB benutzt"
gefunden.
ODBC verwendet einen QZDASOINIT-Job.
Trotzdem würde ich bei der Verbindung in Oralce die Transaktion auf ReadUncommitted stellen.
Vielen dank
ich habe Eure Erkentnisse mal weiter gegeben.
@Birgitta
ich kann es nicht probieren. Die Oracle Leute kenn ich nicht. Ich weis nur das es nicht klappt und die nicht schuld sind.
@Baldur
Habe das mit den Transaktionstypen mal so weitegegeben, hoffe die Oracle leute können damit was anfangen.
@ODBC/DRDA Hmm, lt Oracle Team greifen die mit ODBC zu.
Wikipedia schreibt aber u.a.
Oracle Database Provider for DRDA - enables Oracle database to act as a DRDA server, providing Oracle database access to remote clients (e.g. IBM i systems using DB2/400 DRDA client library)
Das kann also sein dases DRDA ist (wobei ich den Unterschied nie ergründet habe, muß man das wissen?)
@D*B
die Rekord locks gibt es definitiv
Danke
der ILEMax
DRDA ist ein, ich glaube, von der IBM mal entwickeltes Interface:
"Distributed Remote Database Access".
Wenn du mal per WRKRDBDIRE die Datenverbindungen prüfst, so ist eine IBM i-zu-IBM i-Verbindung eben mit *DRDA erreichbar.
DRDA ist das Standradprotokoll der DB2-Derivate.
Dies ist allerdings nicht so unterschiedlich zu Microsoft's ODBC.
... um mal zu rekapitulieren:
- das Problem tritt beim Zugriff von Oracle (ODBC, Treiber ?) und von ACS (JDBC) auf
=> hat mit Art des Oracle Treibers (ob DRDA oder MS CLI) nix zu tun, da JDBC über MS CLI zugreift.
zu untersuchen: Sperrlevel ist Eigenschaft der Connection, der default wird im Treiber eingestellt (bei JDBC in der url) üblich ist hier maximal change, was beim lesenden Zugriff keine Sperren setzt.
Um Treiber Probleme auszuschließen, Version des JDBC Treibers wechseln.
- das Problem tritt bei der View, nicht bei der materialisierten PF auf
=> das liegt schnöde daran, dass bei der View die maximale Anzahl zu sperrender records (das sind alle der darunterliegenden PFs!) die maximal-Zahl der Satzsperren in einer Transaktion überschreitet, bei der PF liegt die Zahl darunter.
anzunehmende Ursache: Fehler im DB2 (oder dB2 oder Db2) der AS/400 (oder wie das Ei heute heißen mag)
=> wahrscheinlich gibt es da ein PTF
D*B
Ich kann den Sperrlevel aber auch mittles Transaktion festlegen.
Oracle hat ein DB2-Gateway, dass dann wohl auf DRDA basiert.
Die maximale Anzahl der Locks in einer Transaktion beträgt 500.000.000.
https://www.ibm.com/docs/en/i/7.1?topic=reference-sql-limits
2,5 Mio sind da nicht das Limit.
"..Satz xxx wird von Job oder Transaktion NR/USER/JOB benutzt"
Welcher Job ist dies und warum hält dieser einen Lock über die Satzwartezeit hinaus?
Dies könnte auch wiederum durch den Commandtimeout auf Clientseite festgelegt werden.
Der Default ist da eher nur 30 Sekunden, während der Satztimeout auf der Ei eben 60 Sekunden beträgt.