Pipelined functions über mehrere Datenbanken

Der Titel dieses Eintrags beschreibt vermutlich eher vage, worum es geht: Jonathan Lewis erklärt in seinem Blog, wie man eine pipelined function verwenden kann, um den Hint driving site für eine über mehrere Datenbanken verteilte Operation einsetzen zu können (was zumindest für CTAS und INSERT AS SELECT ohne diesen Trick nicht funktioniert):

The idea is simple. If you can write a distributed select statement that takes advantage of the /*+ driving_site */ hint to work efficiently, you can wrap the statement in a pl/sql cursor loop and stick that loop into a pipelined function to maximise the efficiency of create or insert as select.

Da pipelined functions nicht unbedingt zu meinen Standardwerkzeugen gehören, hier auch noch ein Link auf Tim Halls einführende Erläuterung zum Thema und seine Definition der besonderen Eigenschaften dieser Objekte:

Table functions are used to return collections that mimic tables. They can be queried like a regular table by using the TABLE function in the FROM clause. Regular table functions require collections to be complete before they are returned causing bottlenecks during large Extraction Transformation Load (ETL) operations. Pipelining negates the need to build huge collections by piping rows out of the function as they are created, allowing subsequent processing to start before the entire collection is fully populated.

Dump-Kompression

Die durch das Export-Utility expdp erzeugten Oracle-Dumps kann man meiner Erfahrung nach mit Komprimierungssoftware üblicherweise auf etwa ein Fünftel der Ursprungsgröße packen. Vor kurzem ist mir aber aufgefallen, dass sich Tabellen mit einem hohen Anteil von LOBs mit einigen Komprimierungsverfahren deutlich besser packen lassen:

Fall 1: Dumpfile eines Schemas ohne LOBs

Format      Größe(MB)     komprimiert auf       Laufzeit(min)
-------------------------------------------------------------
Ungepackt       2500                                        -
zip              500               20,00%                  10
rar              426               17,04%                   7
7z               347               13,88%                  17

Fall 2: Dumpfile eines Schemas mit hohem LOB-Anteil

Format      Größe(MB)     komprimiert auf       Laufzeit(min)
-------------------------------------------------------------
Ungepackt       2500                                        -
zip              696               27,84%                   7
rar               78                3,12%                   5
7z                62                2,48%                  13

Wahrscheinlich spielt der Inhalt der LOBs auch noch eine Rolle, aber für den Moment merke ich mir nur, dass der LOB-Anteil und das verwendete Verfahren die Größe des Dumps stark beeinflussen.

Bindvariablen auslesen

Tanel Poder erläutert in seinem Blog, wie man in 11.2 mit Hilfe der View V$SQL_MONITOR die Bindewerte einer aktuellen Query ermitteln kann - und warum das über das ältere Hilfsmittel V$SQL_BIND_CAPTURE nicht (zuverlässig) möglich war (was ich bisher eigentlich angenommen hatte; allerdings muss ich mich im DWH-Bereich selten um Bindewerte kümmern.

NoSQL

Eine Menge Leute haben in letzter Zeit allerlei Interessantes über NoSQL geschrieben. Da das Thema für mich nur von akademischem Interesse ist, hier nur der Link auf Curt Monashs Zusammenfassung dazu.

Inside Oracle - Julian Dyke

Von Julian Dyke stammt eine extrem hilfreiche Präsentation zum Thema Bitmap Indizes, auf die meiner Erinnerung nach selbst Richard Foote und Jonathan Lewis gelegentlich verweisen. Seit kurzem unterhält der Herr Dyke jetzt ein Blog, und ich kann mir fast nicht vorstellen, dass darin nicht allerlei Interessantes auftauchen wird.

Shrink LOB Segment

Vor ein paar Jahren habe ich hier beschrieben, wie man Lob-Segmente verkleinern kann, und das Verfahren seither auch noch ein paar Mal verwendet. Seit heute bin ich vorsichtiger, da ich Bug 5636728 begegnet bin: "FALSE ORA-1555 WHEN READING LOBS AFTER SHRINK". Die SHRINK-Operation lief erfolgreich, aber anschließend scheitern diverse Queries, die auf LOBs zugreifen, mit ora-01555-Fehlern, obwohl gar keine gleichzeitigen DML-Operationen im Spiel sind (wobei Lobs ihre Rollback-Informationen anscheinend selbst enthalten, so dass die Rollback Segmente in diesem Fall gar keine Rolle spielen). Besonders unerfreulich ist, dass auch die Dump-Erstellung mit diesem Fehler abbricht - es scheint keine Möglichkeit zu geben, die Lobs zu reorganisieren und wieder verfügbar zu machen. Da Oracle auch keinen Workaround anbieten kann, ist man auf die letzte Sicherung vor dem SHRINK angewiesen. Nein, das ist nicht ganz richtig, Oracle nennt doch einen Workaround: "Avoid using SHRINK on tables with LOB columns". Herzlichen Dank!

Grouping - Nachtrag

Im Januar hatte ich hier auf einen Artikel von Rob van Wijk verwiesen, der den ambitionierten Titel All about grouping trägt - und diesem Anspruch auch ziemlich gerecht wird. Jetzt hat der Herr van Wijk allerdings noch einen Nachtrag geliefert, der den Sonderfall des Gruppierens ohne GROUP BY näher erläutert und ebenfalls lesenswert ist.

Nologging für Indizes

Nur als kurze Aktennotiz: beim Neuaufbau von Indizes in einer Oracle 11.1 Datenbank hatte ich heute den Eindruck, dass die nologging-Option nicht den erwarteten Einfluss auf die Laufzeit hatte: mit und ohne logging benötigte die Operation die gleiche Zeit. Eine Prüfung der redo size in v$sesstat bestätigte die Annahme, dass hier tatsächlich kein Unterschied bestand.

In einer Oracle 10 Datenbank konnte ich für die gleichen Operationen deutliche Unterschiede der Laufzeiten und der Redo-Nutzung beobachten - und fing schon an, über eine grundsätzliche Umgestaltung der Logik für das Logging von CREATE INDEX-Operationen in Oracle 11 nachzudenken (da auch die Pläne der Queries sehr ähnlich aussahen).

Erst ein 10046er Trace zeigte mir dann meinen Denkfehler: die Unterschiede im Verhalten ergaben sich nur indirekt aus dem Logging. Unmittelbar verantwortlich war der Zugriff, der für 10.2.0.4 über scattered read und für 11.1.0.7 über direct path read temp erfolgte - und für direct path Operationen erfolgt aus naheliegenden Gründen kein Logging. Ein paar weiterführende Erläuterungen zur Möglichkeit der Verwendung von direct reads für FTS liefert Christian Antognini.

Hash und Nested Loop Joins - Teil 2

Zum Thema der Entscheidung zwischen Hash Joins und Nested Loop Joins hat auch Charles Hopper zuletzt einiges geschrieben - und wie beim Herrn Hopper üblich sind das recht umfangreiche Artikel mit einem sehr hohen Anteil nachvollziehbarer Tests (was ich durchaus schätze):

• http://hoopercharles.wordpress.com/2010/10/01/first-table-is-550mb-second-table-is-26gb-nested-loops-or-full-table-scan/
• http://hoopercharles.wordpress.com/2010/10/02/first-table-is-550mb-second-table-is-26gb-%E2%80%93-nested-loops-or-full-table-scan-2/
• http://hoopercharles.wordpress.com/2010/10/03/first-table-is-550mb-second-table-is-26gb-nested-loops-or-full-table-scan-3/
• http://hoopercharles.wordpress.com/2010/10/04/first-table-is-550mb-second-table-is-26gb-nested-loops-or-full-table-scan-4/

Wahrscheinlich wäre es lohnend, die Einflussfaktoren zusammenfassend aufzuschreiben.

Hash und Nested Loop Joins

Tanel Poder fragt in seinem Blog nach dem fundamentalsten Unterschied zwischen Hash und Nested Loop Joins und gibt anschließend die Antwort zur Frage:

• http://blog.tanelpoder.com/2010/09/28/q-the-most-fundamental-difference-between-hash-and-nested-loop-joins/ - enthält die Frage und erstaunlich viele Kommentare dazu, die zeigen, dass der Herr Poder zu den ersten Adressen in Oracle-Performance-Fragen gehört.
• http://blog.tanelpoder.com/2010/10/06/a-the-most-fundamental-difference-between-hash-and-nested-loop-joins/ - liefert die Antwort;

und die lautet:

"Hash joins can not look up rows from the inner (probed) row source based on values retrieved from the outer (driving) row source, nested loops can."

Ausführlicher und mit Beispielen führt er das dann unter folgender Adresse aus: http://tech.e2sn.com/oracle/sql/the-fundamental-difference-between-nested-loops-and-hash-joins. Interessant ist das allemal, obwohl ich mir fast etwas Tiefgründigeres erwartet hatte. Beinahe noch interessanter fand ich Christian Antogninis Kommentar zur Frage:

Honestly, I’m not able to say what is the *most fundamental difference*. In fact, I see four main differences:
1) HJ processes the right input at most one time; NL might process the right input many times
2) HJ are not able to apply join conditions through indexes; NL are able to do so
3) HJ does not support cross joins, theta joins, and partitioned outer joins; NL supports all types of joins
4) HJ joins supports all types of trees; NL do not support right-deep and zig-zag trees

Nr. 1 war mir halbwegs klar, Nr. 2 leuchtet ein (und wird in Tanel Poders Artikel schön illustriert), aber Nr. 3 und Nr. 4 sind mir völlig neu. Bei Tom Kyte liest man immer wieder, dass er jeden Tag etwas Neues über Oracle lernt. Ich lerne zwar auch, aber leider vergesse ich schneller, als ich lerne...