Löschung von automatisch erzeugten Indizes in Oracle 19c

Die automatische Generierung von Indizes durch das "Auto Indexing" in Oracle 19c sieht auf den ersten Blick wie ein ausgesprochen interessantes Feature aus. Das ist sie zweifellos auch. Wie gut sie funktioniert, ist ein anderes Thema. Franck Pachot zeigt, dass es zumindest nicht ganz leicht ist, die automatisch generierten Indizes wieder los zu werden: mit einem simplen "drop index" klappt das schon mal nicht - und ob manuelle Anpassungen in sys.ind$ tatsächlich eine gute (more...)

AWK-Skripte zur Auswertung von CBO Traces

Die durch das Trace Event 10053 erzeugten Optimizer Traces sind eine großartige Hilfe, wenn es darum geht, die Entscheidungen des Optimizers nachzuvollziehen. Leider sind die Ausgaben aber so umfangreich und unübersichtlich, dass es unter Umständen ziemlich lange dauert, bis man die relevanten Details daraus exzerpiert hat. Zu Vereinfachung des Vorgehens hat Nenad Noveljic ein paar Skripte auf AWK-Basis veröffentlicht:

Prepared Statements und Bindewerte in Postgres

Franck Pachot erläutert in seinem Blog die unterschiedlichen Straegien bei der Verwendung von Bindevariablen bei Oracle und Postgres. Interessant sind aus meiner Sicht vor allem die Aussagen zu Postgres:
  • normalerweise werden Queries bei jeder Ausführung neu optimiert.
  • Ausnahme von dieser Regel sind Statements, die prepared wurden.
  • Für diese gilt, dass sie bei den ersten fünf Ausführungen jeweils neu kompiliert werden. 
  • Ab der sechsten Ausführung wird dann ein generischer Plan verwendet, der sich aber nicht (more...)

Informationen zur Hint-Verwendung in 19c

Eine schöne Ergänzung für dbms_xplan in 19c ist die Ergänzung des Formats HINT_REPORT - im verknüpften Artikel beschrieben von Gavin Soorma. Das Format liefert Informationen zu den im Statement angegebenen Hints und erklärt, warum ein Hint nicht berücksichtigt wurde. Diese Information musste man bislang über ein CBO Trace (Event 10053) ermitteln.

Fehler beim Mview-Refresh mit Lateral Join in 12.2

Da ich in den ODC Foren (früher OTN Foren) kaum etwas wiederfinde, hier ein Link auf eine Frage, die ich zu einem Verhalten gestellt habe, das mir zuletzt beim Refresh einer Materialized View mit Lateral Join begegnet war:

-- 12.2.0.1 SE
create table t(
col1 number
, col2 varchar2(4000)
);

insert into t(col1, col2) values(1, '[{"type":1,"target":42}]');
insert into t(col1, col2) values(2, '[{"type":1,"target":42},{"type":2,"target":43}]');

create materialized view t_mv
as
select t.col1, t.col2, (more...)

Partitionierung mit Postgres 12

Daniel Westermann hat im dbi Services Blog eine interessante Serie begonnen, die sich mit den aktuellen Möglichkeiten der Partitionierung in Postres 12 (das sich noch im Beta-Status befindet) beschäftigt:
  • PostgreSQL partitioning (1): Preparing the data set: beschreibt die Erzeugung einer Testtabelle aus einer öffentlich verfügbaren Datenquelle der US-Regierung. Die Ladeoperation erfolgt über ein copy-Kommando. Zu dieser Tabelle wird eine Materialized View erzeugt. Wenn eine MV einen unique index besitzt kann der Refresh concurrently erfolgen (more...)

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 (more...)

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 (more...)

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 (more...)

Gestern ging’s noch

Brent Ozar hat in seinem Blog eine Liste mit 15 Gründen veröffentlicht, die dazu führen können, dass eine Query im SQL Server plötzlich langsamer wird, als sie das bisher gewesen war - und in den Kommentaren wurden noch ein paar weitere Begründungen aufgeführt. Vor ein paar Jahren hatte Jonathan Lewis eine ähnliche Liste mit 20 Punkten für Oracle erstellt, für die mir Hemant Chitale via Twitter den passenden Link geliefert hat. Zu den aufgeführten Gründen (more...)

Automatisches SQL Plan Management mit 19c

Nigel Bayliss erläutert im Oracle Optimizer Blog das in Oracle 19c eingeführte "automatic SQL plan management", das die bekannten SPM Mechanismen automatisiert: da es in 19c per default aktiv ist, werden demnach in diesem Release grundsätzlich Alternativpläne erstellt, bewertet und per Baseline festgeschrieben. Um das das Feature zu deaktivieren oder zumindest auf eine manuelle Freigabe der Vorschläge umzustellen, gibt es diverse Aufrufe im DBMS_SPM-Package, die im Artikel erläutert werden.

Recursive IM_DOMAIN$ Zugriffe

Jonathan Lewis liefert in seinem Scratchpad eine Lösung für ein Problem, das Franck Pachot vor einiger Zeit angesprochen hatte: in Oracle 18c kann es dazu kommen, dass die folgende Query extrem häufig ausgeführt wird und zu Performance-Problemen führt (oder dazu beiträgt):
select domain# from sys.im_domain$ where objn = :1 and col# = :2
Diese interne Query (sprich: recursive query) gehört - wie der Name schon andeutet - in den InMemory Kontext, erscheint beim Parsen (more...)

Deaktivierung des APPEND Hints

Jonathan Lewis erläutert in seinem Scratchpad, welche Optionen es gibt, um einen APPEND-Hint zu deaktivieren. Eine solche Deaktivierung kann z.B. wünschenswert sein, wenn die APPEND-Operationen zu einer massiven Verschwendung von Speicherplatz führen, da die durch sie gefüllten Blöcke immer oberhalb der highwater mark (HWM) ergänzt werden. Nicht in Frage kommt in diesem Fall die naheliegende Lösung eines SQL Patches mit einem Hint ignore_optim_embedded_hints, da APPEND kein Optimizer-Hint ist, sondern in die Kategorie "behaviour" gehört. (more...)

Optimierung skalarer Subqueries für Oracle und SQL Server

Nenad Noveljic hat zuletzt in zwei Artikel das Verhalten von skalaren Subqueries im SQL Server und in Oracle untersucht und dabei darauf hingewisen, dass dies einer der (nicht allzu häufigen) Fälle ist, in denen der Optimizer des SQL Servers eine bessere Lösung bietet als Oracles Optimizer. Grundsätzlich bereiten skalare Subqueries Schwierigkeiten, können aber in vielen Fällen in einen Join umgewandelt werden. Der SQL Server schafft das intern - also ohne eine explizite Umformulierung durch den (more...)

CTEs ohne Materialisierung in Postgres 12

Jonathan S. Katz weist in einem Artikel auf eine wichtige Verbesserung hin, die mit Postgres 12 verfügbar werden soll: CTEs werden dann nicht mehr automatisch materialisiert. In der commit message findet man dazu folgende Beschreibung:
By default, we will inline [CTEs] into the outer query (removing the optimization fence) if they are called just once. If they are called more than once, we will keep the old behavior by default, but the user can override (more...)

Erweiterte Analytische Funktionen in Postgres 11

Markus Winand zeigt, welche Verbesserungen Postgres 11 im Bereich der analytischen Funktionen bringt: insbesondere werden jetzt "Frame Units" in der OVER clause unterstützt - also Einschränkungen wie:
row between unbound preceeding and current row.
Wobei neben "row" auch "range" und "groups" als Einheit erscheinen können. Insbesondere "groups" ist dabei eine interessant Ergänzung, die nicht die Anzahl der Datensätze, sondern die der distinkten Werte berücksichtigt. Eine weitere wichtige Neuerung, die bisher nur Postgres anbietet, ist die (more...)

Formatierungsoption hint_report für dbms_xplan

Eine schöne Ergänzung für die dbms_xplan.display%-Funktionen in Oracle 19 hat Nigel Bayliss im Oracle Optimizer Blog angesprochen: die Formatierungsoption hint_report. Diese liefert, was bisher nur über Trace Events wie 10053 zu erkennen war: eine Information dazu, welche explizit gesetzten Hints bei der Generierung eines Ausführungsplans tatsächlich berücksichtigt wurden. Die Option liefert einen Abschnitt "Hint Report" unter dem Ausführungsplan (und unterhalb der "Predicate Information") und in diesem Report erscheinen vor den Hints auf einzelne Buchstaben (more...)

Dokumentation für Statspack

Oracle ist ziemlich gut bei der Entwicklung von relationalen Datanbankmanagementsystemen. Weniger gut ist die Firma beim Dokumentieren der eigenen Software - und bei der geeigneten Präsentation dieser Dokumentation im Internet. Ein Stück Dokumentation, das ich auch schon gelegentlich gesucht und nicht gefunden habe, liefert Pierre Forstmann in seinem Blog: die Dokumentation für Statspack. Dass man eine komplexe Dokumentation auch über viele Releases in angemessener Form im Netz präsentieren kann, beweist übrigens Postgres.

Erweiterte pg_stat_statements_reset Funktion in Postgres 12

Auf eine interessante Ergänzung der Funktion pg_stat_statements_reset in Postgres 12 weist Daniel Westermann hin: war es bisher nur möglich, die pg_stat_statements Datenbasis komplett zu löschen, erhält die Funktion in der kommenden Version zusätzliche Parameter, die eine Löschung auf den Ebenen userid, dbid und queryid erlauben. Dadurch wird dann eine bessere Kontrolle der Statistiken zu den im System ablaufenden Queries möglich. Da die pg_stat_statements für mich das zentrale Werkzeug der Performance-Analyse in Postgres darstellt, sind solche (more...)

Verhalten von Index Splits

Wieder mal bin ich spät dran und exzerpiere relevante Artikel, kurz bevor sie aus dem 30-Tage-Korridor meines Blog Aggregators fallen. Und wieder mal ist es der zur Zeit ungeheuer produktive Jonathan Lewis, dessen Beiträge ich zusammenfasse. In den fraglichen Artikel beschäftigt sich der Herr Lewis mit dem Verhalten von "Index Splits", die auftreten, wenn ein neuer Index-Eintrag nicht mehr in den vorgesehenen Block der Index-Struktur passt: