View lesen

[Fuerchau]

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.

[ILEMax]

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

[Fuerchau]

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.

[BenderD]

... 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

[Fuerchau]

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.

[ILEMax]

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

[BenderD]

... sorry, ich vermeide es, mir ACS anzutun. Da gibt es m.E. bessere Alternativen, zumindest für das, was ich da brauche.

D*B

[Fuerchau]

In Verbindung => Connected => JDBC-Konfiguration bearbeiten => System => Isolationsstufe.

@D*B:
Wenn man Alternativen verwenden darf, gehts.
Ansonsten ist ACS ganz OK, nur bei manchen Dingen wie z.B. Intellisense (Autovervollständigen) etwas schwach. Wenn man aber mindestens einmal STRG+Leerzeichen verwendet hat und die Geduld aufbringt (Kaffee holen oder wegbringen) dann gehts auch.
Was andere nicht anbieten ist die Zugriffsanalyse (ob meine selbst erstellten Indizes verwendet werden).

35 Minuten für nur 3,2 Mio Sätze? Bist du da Remote via VPN drauf oder läuft dein Java in 32-Bit?
Ich habe native Tests mal gemacht, da konnten bis 200Mio Zeilen/Stunde abgeholt werden, allerdings mit ODBC. Der OLEDB IBMDASQL/IBMDA400 sowie der native .Net-Treiber waren da sogar langsamer.

[B.Hauser]

In Verbindung => Connected => JDBC-Konfiguration bearbeiten => System => Isolationsstufe.

Das ist noch der iSeries Navigator!
In ACS kann man Verbindungen festlegen, die man beim Connect angibt.
Die Verbindungen können gepflegt werden über:
Edit --> JDBC Configuartions

Das Loglevel (bzw. Commit) stellt man dann in der Verbindung unter System --> Isolation Level ein.
(Default ist an dieser Stelle allerdings *NONE)


Die entsprechende Verbindung kann dann beim Verbinden ausgewählt werden.

[Fuerchau]

Nö, ich habe mich auf ACS bezogen;-).
Ich habe halt nur die deutsche Sprache eingeschaltet.

[BenderD]

... naja, ich tobe halt auf etlichen verschiedenen Datenbanken rum und vermeide nicht nur ACS, sondern auch MS-SQL Server Management studio und alles, was Datenbank spezifisch ist. Zusammenknipsen mit Auto Completion etc. mache ich auch nicht. Das trainiert und sorgt dafür, dass vor dem Bildschirm mehr Intelligenz sitzt als hinter dem Blech.

D*B

In Verbindung => Connected => JDBC-Konfiguration bearbeiten => System => Isolationsstufe.

@D*B:
Wenn man Alternativen verwenden darf, gehts.
Ansonsten ist ACS ganz OK, nur bei manchen Dingen wie z.B. Intellisense (Autovervollständigen) etwas schwach. Wenn man aber mindestens einmal STRG+Leerzeichen verwendet hat und die Geduld aufbringt (Kaffee holen oder wegbringen) dann gehts auch.
Was andere nicht anbieten ist die Zugriffsanalyse (ob meine selbst erstellten Indizes verwendet werden).

35 Minuten für nur 3,2 Mio Sätze? Bist du da Remote via VPN drauf oder läuft dein Java in 32-Bit?
Ich habe native Tests mal gemacht, da konnten bis 200Mio Zeilen/Stunde abgeholt werden, allerdings mit ODBC. Der OLEDB IBMDASQL/IBMDA400 sowie der native .Net-Treiber waren da sogar langsamer.

[Fuerchau]

Nunja, bei Einwicklungen mit SQL, ILERPG und langen Namen vermeide ich gerne das ständige Neutippen von Namen wie zu SEU-Zeiten. Selbst da habe ichmir häufig auf einer 2. Sitzung die Namen anzeigen lassen um sie mit Copy/Paste zu transportieren.

In der Entwicklung mit VisualStudio käme ich gar nicht damit aus. Das erzeugen von Code ist du um kaum messbare Faktoren effektiver, schneller und dadurch auch weniger fehleranfällig.
Warum also nicht auch für die IBM i?

Da würde ich mir auch bei SQL die Vervollständigung wünschen.