Performance bei Zugriff auf Oracle-Datenbank

Contributor

Probleme bei Nutzung Connection JDBC to Oracle:

 

Verwendete Scripte (Auszug):

-- For JDBC Connection
CREATE OR REPLACE CONNECTION JDBC_ORACLE --Install JDBC driver first via EXAoperation
--see https://www.exasol.com/support/browse/SOL-179
TO 'jdbc:oracle:thin:@//10.101.100.20:1521/B3ATBETA'
USER 'ORAB3ATSAND'
IDENTIFIED BY 'Oracle1';

--Test Connection von Exasol auf die B3AT-Datenbank
select * from
(
import from jdbc at JDBC_ORACLE
statement 'select * from AD_ORG'
);
--Test lokal in Exasol
select * from AD_ORG;


Wir haben ein komplette DB mit > 1000 Tabellen erfolgreich in die Exasol-Datenbank importiert, basierend auf dem Script oracle_to_exasol.sql
Allerdings hat dieser Job ca. 17 Stunden gedauert, obwohl kaum Datensätze in der DB vorhanden sind.

Das Problem ist, dass grundsätzlich jeder Zugriff über den JDBC-Treiber unvorhersehbar lange dauert. Das gleiche Statement mehrfach hintereinander ausgeführt dauert unterschiedlich lange, mal lang, mal kurz, dann wieder lang.
Beispiel aus dem Script oben auf die Tabelle AD_ORG, in der nur 3 Datensätze vorhanden sind:
Dieses Script dauert zwischen 10 Sekunden und 2 Minuten. Wir vermuten also ein Problem in der JDBC-Connection aus Exasol heraus.

Einige Male wurde auch folgender Fehler geworfen:
[Code: 0, SQL State: 42636] ETL-5402: JDBC-Client-Error: Connecting to 'jdbc:oracle:thin:@//10.101.100.20:1521/B3ATBETA' as user='ORAB3ATSAND' failed: No more data to read from socket (Session: 1666959610520476465)

Was können wir prüfen, um dieses Problem zu beheben?

 

5 REPLIES 5

Contributor

Hallo MaMerker

Wir haben in einem Proof of Concept Daten ab Oracle geladen. Wie in einem anderen Post erwähnt kamen wir auch zum Schluss, dass OCI an Stelle von JDBC zu verwenden sei.

Habt Ihr auch mit der Parallelität gespielt? Wir hatten für grosse Tabellen die Statements mit bis zu 40 facher Parallelität abgesetzt, mehr hat dann die Oracle Instanz nicht verkraftet.

Wenn ich es richtig verstehe, dann wäre es auch Sinvoll, die Parallelität "am Partitioning auf Oracle auszurichten", dann hätte man die beste Performance, dies war in unserem Fall leider nicht möglich, also haben wir für die Parallelität einfach PK mod 40 genommen (Was auf der Oracle Seite auch nicht optimal ist)

Gruss

Gallus

Moderator
Moderator

Und warum nehmt ihr nicht den empfohlenen OCI Treiber? Hab hier ein Video aufgenommen, wo das beschrieben wird: https://www.youtube.com/watch?v=39c3ZeL_w20 Das würd ich doch mal als erstes ausprobieren.

Contributor

Vielen Dank, siehe meine Rückmeldung an mwellbro.

Xpert

Hallo MaMerker,

wurden auf der ORA Seite ASH und AWR geprüft ? Und ist die ORA-seite an sich ruhig im Sinne von "es läuft nicht alles auf Anschlag" ( ich denke in die Richtung das die Quellseite eventuell zu stark unter Last steht ) ?

Ich hatte ohnehin schonmal geplant die JDBC-Cons gegen die "Native"-Versionen zu testen, maybe it´s time 🙂

Beste Grüße,

 

Contributor

Hallo, danke für die Rückmeldung, aber auf der Oracle-DB läuft sonst nichts. Ich habe es jetzt mal mit folgendem Connect ausprobiert:

-- For JDBC Connection
CREATE OR REPLACE CONNECTION OCI_ORACLE --Install JDBC driver first via EXAoperation
--see https://www.exasol.com/support/browse/SOL-179
TO '10.101.100.20:1521/B3ATBETA'
USER 'ORAB3ATSAND'
IDENTIFIED BY 'Oracle1';

--Test Connection von Exasol auf die B3AT-Datenbank
select * from
(
import from ora at OCI_ORACLE
statement 'select * from AD_ORG'
);

 

Nun dauern die Statements alle gleich lang, 714 ms. Da kann ich erstmal it weiterarbeiten. Daher vielen Dank.

 

Zur Info: Wir sind auf JDBC gegangen und nicht auf den nativen Oracel Zugang, da wir vermutlich demnächst auch aus MS SQL-Servern importieren müssen.