Indizierung von NULL-Werten

Randolf Geist hat nach einer längeren Pause zuletzt wieder begonnen Blog-Artikel zu veröffentlichen, was mir sehr gut gefällt. In zwei Artikeln behandelt er die Effekte der Indizierung von NULL-Werten, insbesondere in Kombination mit IN/OR Prädikaten:

• Indexing Null Values - Part 1: zeigt zunächst ein Beispiel, in dem ein Index auf einem einzelnen Attribut durch Ergänzung einer Konstante dazu gebracht wird, auch NULL-Werte zu indizieren, was ein übliches Verfahren für derartige Fälle ist. Dieser Index wird dann auch für IS NULL Prädikate verwendet. Im Plan ist erwartungsgemäß zu sehen, dass ein weiteres Prädikat mit einer IN-Liste als Filter-Prädikat für die Tabelle auftaucht. Wenn man den Index neu erzeugt und dieses zweite Attribut als zweite Spalte des Index verwendet, führt die gleiche Query zu einem access-Prädikat für die NULL-Prüfung und einem Filter-Prädikat für die IN-Liste beim Index-Zugriff. Diese Filterung auf dem Index ist zwar günstiger als die Filterung in der Tabelle, aber eigentlich sollte es möglich sein, beide Prädikate im access zu verwenden. Dieser Effekt ist dann offenbar auch dafür verantwortlich, dass hier kein "inlist iterator" verwendet werden kann: anscheinend erlaubt die Implementierung hier keine Kombination der Prädikate aus IS NULL Prüfung und IN/OR Einschränkungen. Dieses Verhalten ändert sich, wenn man die Reihenfolge der Spalten im Index ändert und die Spalte der IS NULL Bedingung ans Ende der Spaltenliste setzt.
• Indexing Null Values - Part 2: behandelt das Verhalten von Bitmap Indizes in vergleichbaren Fällen. Hier ist der Bitmap Index mit mehreren Spalten natürlich eine unübliche Wahl - obwohl er bei entsprechender Datenverteilung ausgesprochen kompakt sein kann. Sichtbar wird, dass Oracle hier sehr merkwürdige Cost-Angaben erzeugt, die wenig mit dem tatsächlichen Aufwand beim Zugriff haben. Auch scheint die Darstellung von Filter- und Acces-Prädikaten im Plan nicht unbedingt viel mit der tatsächlichen Arbeit der runtime engine zu tun zu haben. Plausible Werte erhält man nur mit der vorgesehenen Verwendung einspaltiger Bitmap Indizes, obwohl der mehrspaltige Bitmap Index im Beispiel tatsächlich geringfügig effizienter ist.

Sollte die Serie fortgesetzt werden, ergänze ich die zugehörigen Artikel - vielleicht.

dbms_job Umwandlung bei der Migration zu Oracle 19

Mike Dietrich informiert in seinem Blog darüber, dass mit Oracle 19 die mit dbms_job definierten Jobs in Aufträge des dbms_scheduler umgewandelt werden. Da dbms_scheduler seit den Tagen von Oracle 10 existiert, in so ziemlich allen mir erinnerlichen Punkten robuster und flexibler als dbms_job ist, bessere Überwachungsmechanismen besitzt und da dbms_job mit Oracle 12.2.0.1 endlich als deprecated klassifiziert wurde, halte ich das persönlich erst mal für eine sinnvolle Entwicklung.

Trotzdem muss man im Rahmen des Upgrades natürlich darauf achten, dass es bei der Konvertierung nicht zu unerwarteten Effekten kommt. Zur Umwandlung sind noch folgende Punkte relevant:

1. während des Upgrades auf 19c wird zu jedem dbms_job-Job ein entsprechender dbms_scheduler-Job erstellt
2. das dbms_job-Interface funktioniert weiterhin, aber es wird immer zur Anlage von scheduler-Jobs führen
3. ein zugehöriger Check in preupgrade.jar prüft auf Inkonsistenzen

Somit kann man also dbms_job weiterhin verwenden, aber unter der Haube wird alles in scheduler-Jobs umgewandelt. Ob die weitere Verwendung von dbms_job unter diesen Umständen besonders sinnvoll ist, sei dahingestellt - aber diese Frage stellte sich ja schon von dem Umzug auf Version 19.

OLTP und basic compression ab 12.1 für Datensätze mit mehreren row pieces

Randolf Geist weist in seinem Blog auf eine interessante Änderung hin, die mit Oracle 12.1 eingeführt wurde - aber mir (wie vermutlich auch vielen anderen) entgangen war: inzwischen funktionieren die OLTP und die basic compression auch für Datensätze mit mehr als einem row piece - also mehr als 254 Spalten. Dazu wurde ein neuer interner Parameter "_widetab_comp_enabled" eingeführt, der per default auf true gesetzt wurde. Allerdings gab es in diesem Zusammenhang wohl diverse Probleme im Kontext des redo apply, weshalb das Feature in späteren PSUs für 12.1 teilweise deaktiviert wurde. Anscheinend wurden diese Beschränkungen in 12.2 aufgehoben, aber zumindest die Dokumentation ist in diesem Zusammenhang nicht ganz klar. Der Artikel enthält diverse Testfälle, mit denen man das Verhalten für unterschiedliche Szenarien noch genauer überprüfen kann.