Oracle CLOB-Leistung

8

Ich führe Abfragen gegen eine Oracle 10g mit JDBC (mit den neuesten Treibern und UCP als DataSource), um CLOBs (durchschnittlich 20k Zeichen) abzurufen. Die Performance scheint jedoch ziemlich schlecht zu sein: Der Batch-Abruf von 100 LOBs dauert im Durchschnitt 4 Sekunden. Die Operation ist auch nicht I / O noch CPU oder Netzwerk gebunden, nach meinen Beobachtungen zu urteilen.

Mein Test-Setup sieht so aus:

%Vor%

Ich experimentierte mit den Abrufgrößen, aber ohne Erfolg. Mache ich etwas falsch? Gibt es eine Möglichkeit, die CLOB-Abfrage bei Verwendung von JDBC zu beschleunigen?

    
yawn 06.10.2009, 13:59
quelle

4 Antworten

2

Danke für all die hilfreichen Vorschläge. Trotz der Antwort auf das Problem ist meine Antwort, dass es keine gute Lösung zu geben scheint. Ich habe versucht, parallele Anweisungen, verschiedene Speichereigenschaften, vorsortierte temp. Tische und andere Dinge. Die Operation scheint nicht an irgendwelche Merkmale gebunden zu sein, die durch Spuren sichtbar sind oder Pläne erklären. Selbst die Abfrageparallelität scheint bei Verwendung von CLOBs lückenhaft zu sein.

Zweifellos gäbe es bessere Möglichkeiten, mit großen CLOBs (insbesondere Kompression) in einer 11g-Umgebung, aber atm umzugehen. Ich bin mit 10g stecken.

Ich habe mich jetzt für einen zusätzlichen Roundtrip zur Datenbank entschieden, in dem ich die CLOBs zu einem größenoptimierten binären RAW vorverarbeiten werde. In früheren Bereitstellungen war dies immer eine sehr schnelle Option und wird wahrscheinlich die Mühe kosten, einen offline berechneten Cache zu verwalten. Der Cache wird ungültig und mit einem persistenten Prozess und AQ aktualisiert, bis jemand eine bessere Idee hat.

    
yawn 12.10.2009, 19:58
quelle
6
  

Die Gesamtgröße der Ergebnismenge liegt in den Zehntausenden - gemessen über die Spanne des gesamten Abrufs der Anfangskosten

Gibt es in der Abfrage eine Reihenfolge? 10K Zeilen sind ziemlich viel, wenn es sortiert werden muss.

Auch das Abrufen der PK ist kein fairer Test im Vergleich zum Abruf des gesamten CLOB. Oracle speichert die Tabellenzeilen mit wahrscheinlich vielen in einem Block, aber jeder der CLOBs (wenn sie & 4K sind) wird außerhalb der Zeile gespeichert, jeder in einer Reihe von Blöcken. Das Durchsuchen der PK-Liste wird daher schnell sein. Außerdem gibt es wahrscheinlich einen Index für den PK, so dass Oracle die Indexblöcke schnell durchsuchen kann und nicht einmal auf die Tabelle zugreifen kann.

4 Sekunden scheinen etwas hoch zu sein, aber es sind 2 MB, die von der Festplatte gelesen und über das Netzwerk zu Ihrem Java-Programm transportiert werden können. Netzwerk könnte ein Problem sein. Wenn Sie eine SQL-Ablaufverfolgung der Sitzung ausführen, zeigt es Ihnen genau an, wo die Zeit (Datenträger liest oder Netzwerk) verbracht wird.

    
Stephen ODonnell 07.10.2009 13:32
quelle
5

Meine bisherige Erfahrung mit Orakel-LOB-Daten zum Speichern großer Datenmengen war nicht gut. Es ist in Ordnung, wenn es unter 4k ist, da es es wie varchar2 lokal speichert. Sobald es über 4k ist, beginnt die Leistung zu sinken. Vielleicht haben sich die Dinge verbessert, seit ich es das letzte Mal vor ein paar Jahren versucht habe, aber hier sind die Dinge, die ich in der Vergangenheit für Ihre Informationen gefunden habe:

Da Clients LOBs über Oracle Server beziehen müssen, können Sie die folgende interessante Situation in Betracht ziehen.

  • lob Daten konkurrieren begrenzte SGA Cache mit anderem Datentyp bei Oracle beschließen, es zu cachen. Wie Clob Daten sind allgemein groß, so kann es andere drücken Daten
  • lob Daten erhalten schlechte Festplatte gelesen, wenn Orakel beschließen, es nicht zu cachen, und streamen Sie die Daten zum Client.
  • Fragmentierung ist wahrscheinlich etwas das hast du noch nicht gesehen. Sie werden sehen, ob Ihre Anwendungen lobs löschen, und Oracle versucht, den lob wiederzuverwenden. Ich weiß nicht, ob Orakel unterstützt Online-Defragmentierung der Festplatte für lob (sie haben für Indizes, aber es dauert lange, wenn wir es vorher versuchten).

Du hast 4s für 100 lobs von durchschnittlich 20k erwähnt, also sind es 40ms pro lobs. Denken Sie daran, dass jeder Lob über den separaten Lob-Locator abgerufen werden muss (er ist standardmäßig nicht im Ergebnis). Das ist eine zusätzliche Hin- und Rückfahrt für jeden Lob, nehme ich an (ich bin mir da nicht 100% sicher). Wenn das der Fall ist, nehme ich an, dass pro Runde in Serienreihenfolge mindestens 5ms mehr Zeit sein werden , Recht? Wenn dies der Fall ist, ist Ihre Leistung bereits durch sequenzielle Lob-Abrufe begrenzt. Sie sollten dies überprüfen können, indem Sie die Zeit aufspüren, die Sie in der SQL-Ausführung im Vergleich zum Abruf von Lob-Inhalten verbracht haben. Oder Sie können dies überprüfen, indem Sie die Lob-Spalte ausschließen, wie von der vorherigen Antwort im Beitrag vorgeschlagen, die Ihnen sagen sollte, ob sie lobbezogen ist.

Viel Glück

    
Oscar Chan 07.10.2009 17:52
quelle
3

Ich hatte ein ähnliches Problem und habe festgestellt, dass die JDBC Lobs beim Zugriff auf die Lobs einen Netzwerkanruf tätigten.

Ab Oracle 11.2g JDBC Driver können Sie einen Prefetch verwenden. Dies beschleunigte den Zugriff um das 10-fache ...

%Vor%     
Robin Morris 17.04.2014 15:52
quelle

Tags und Links