-
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:
Code:
SELECT * from View
For Read Only
With NC;
-
Zitat von Fuerchau
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?to...nce-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.
-
Habe im ACS folgendes probiert:
"SQL - Anweisung und CL Befehle ausführen"
select * from LIB.VIEW for read only with NC
"Auswahl ausführen"
Bild mit Daten, rechts unten ein download Symol, das gedrückt.
Anzeige wird zum Subfile, links unten steht "in Arbeit" und zählt die Sätze hoch.
nach 35 Minuten hat er die 3,2 Mio Sätze in der Anzeige, das klappt also.
gegenprobe, ohne "for read only with NC"
geht nicht!
Also:
- 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.
Ja.
Wenn ACS mit JDBC zugreift, und man da was einstellen / kontrollieren kann
Wie komme ich da dran? Warum liest der mit Sperre als default? ein Interaktiver select!
Habe Rückmeldung vom Oracle Team:
Durch umstellen des Transaktionslevels hat alles geklappt, vielen Dank!
@Baldur
"..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?
Stammdatenpflege sperrt den Satz blöderweise so lange, bis der Anwender aus der Porzelanabteilung zurück kommt, alle privaten Telefonate erledig hat und sich erbahmt seine (ggf nicht einmal gemachte) Änderung wieder frei zu geben.
Das braucht ihr überigens nicht als Designfehler zu benennen!
Danke
@D*B:
wäre schön wenn du noch beschreiben könntest wie wir die JDBC Treiber Einstellungen finden können.
Danke
Der ILEMax
-
... sorry, ich vermeide es, mir ACS anzutun. Da gibt es m.E. bessere Alternativen, zumindest für das, was ich da brauche.
D*B
Similar Threads
-
By dibe in forum NEWSboard Programmierung
Antworten: 7
Letzter Beitrag: 21-01-19, 13:52
-
By dibe in forum NEWSboard Programmierung
Antworten: 5
Letzter Beitrag: 13-10-15, 08:48
-
By svit in forum IBM i Hauptforum
Antworten: 14
Letzter Beitrag: 28-08-15, 19:25
-
By HelgeNielsen in forum IBM i Hauptforum
Antworten: 12
Letzter Beitrag: 23-04-02, 15:40
-
By chr in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 01-02-01, 11:00
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks