Dienstag, Februar 13, 2018

Ergänzungen zu coalesce und NVL

Vor längerer Zeit hatte ich hier gelegentlich auf Artikel verwiesen, die sich mit dem unterschiedlichen Verhalten von NVL und coalesce beschäftigten und einerseits auf die short-circuit evaluation mit coalesce und andererseits auf deren Ausklammerung im Fall von Sequencen hinwiesen. Jetzt haben die Herren Lewis und McDonald dazu ergänzende Beobachtungen geliefert.
  • Jonathan Lewis weist darauf hin, dass coalesce beim costing schlechter abschneidet als NVL, weil es mit dem Standardwert von 1% für Gleichheit operiert, der für viele Funktionsaufrufe verwendet wird. NVL hingegen kann vorhandene Histogramme sinnvoll einsetzen.
  • Connor McDonald zeigt eine nette Optimierung für Queries mit Bindevariablen der Form coalesce bzw. NVL(:search_criteria, column) = column. In diesem Fall kann NVL die beiden Fälle in zwei Varianten aufsplitten, während coalesce immer einen Full Table Scan einsetzt.
Wie üblich hängt die Auswahl der passenden Funktion also von den Umständen ab.

Donnerstag, Februar 08, 2018

Artikel zu redo internals von Frits Hoogland

Um sie leichter wiederzufinden, verlinke ich hier eine Liste der Artikel, die Frits Hoogland in seiner Serie "A look into Oracle redo" veröffentlicht. Vermutlich werde ich hier wenig Inhaltliches ergänzen, da sich diese Artikel nur schwer exzerpieren lassen: sie enthalten einfach zu viele interessante technische Details:
  • A look into Oracle redo, part 1: redo allocation latches: der log buffer enthält mindestens zwei public redo strands, die über x$kcrfstrand dargestellt werden. Die Anzahl wird über den internen Parameter _log_parallelism_max gesteuert: Systeme mit einer höheren CPU-Anzahl könnten unter Umständen von einer Erhöhung des Wertes profitieren. Jeder Strand wird von einem "redo allocation latch" geschützt. Neben den public strands gibt es private strands, die ebenfalls von solchen Latches geschützt werden (so dass statt 2 insgesamt 20 Latches sichtbar sind). Es folgt eine intensivere Untersuchung der latch Verwendung unter Verwendung elaborierterer Tools. Sichtbar wird, dass im Fall einer Verwendung aller vorhandenen Latches eine folgende Anforderung zunächst ein spinning im willing to wait Modus durchführt und anschließend in den sleep Modus mit semaphore (über den eine Benachrichtigung erfolgt, wenn das Latch wieder verfügbar wird) übergeht (was Andrey Nikolaev, den ich hier auch gelegentlich irgendwo verlinkt habe, umfassend dargestellt hat). Um den Zusammenhang von redo allocation latch und verwendetem public strand zu bestimmen, muss man aber noch tiefer graben und die memory Nutzung des Prozesses untersuchen. Hier wird dann erläutert, welche Funktion im einzelnen intern aufgerufen werden, aber spätestens hier ist die Nacherzählung nicht mehr hilfreich.
  • A look into Oracle redo, part 2: the discovery of the KCRFA structure: geht noch tiefer in die technischen Details der Implementierung und den Aufbau der zugehörigen Memory-Strukturen ein, was ebenso interessant wie schwer exzerpierbar ist.
Die folgenden Links werde ich hier voraussichtlich ebenfalls noch ergänzen, aber vermutlich werde ich dazu auch nicht viel mehr zu sagen  haben als zum zweiten Artikel.

Donnerstag, Februar 01, 2018

Anzeigeoptionen für dbms_xplan

Noch ein Verweis auf einen Artikel von Franck Pachot, in dem er Dokumentationslücken zu Oracle schliesst. In diesem Fall erläutert er die Format-Optionen zu dbms_xplan, die ich mit einer gewissen Regelmäßigkeit nachschlagen muss - was durch diesen Link möglicherweise vereinfacht wird.