SQL Patch zur Ergänzung von Dynamic Sampling in einem gegebenen Statement

Der Titel ist diesmal länger als der Eintrag...

Jonathan Lewis zeigt in seinem Blog, wie man mit Hilfe eines SQL Patch (erzeugt über dbms_sqldiag_internal.i_create_patch) einem vorliegenden SQL-Statement, dessen Text man nicht verändern kann/darf, nachträglich einen dynamic_sampling-Hint spendieren kann, um z.B. Spaltenkorrelationseffekte zu behandeln. Der Artikel enthält auch Links auf Dominic Brooks Artikelserie zum Thema und auf einen entsprechenden Beitrag im Blog der CBO Entwickler - bei genauerem Hinsehen fällt mir auf, dass ich die hier auch schon mal zusammengefasst hatte.

Heat Maps mit sqlplus

Vor kurzem hat Luca Canali in seinem Blog ein SQL*plus Script vorgestellt, das eine grafische und - vor allem - farbige Visualisierung von wait event latency (insbesondere von I/O latency) in Form einer Heat Map liefert. Bei Kyle Hailey gibt's noch ein paar ergänzende Vorschläge zum Thema. Immer wieder erstaunlich, was man mit SQL*plus alles machen kann.

Ein paar Hinweise zum Farbeinsatz in SQL*plus findet man übrigens im Artikel SQL*Plus tips #6: Colorizing output von Sayan Malakshinov.

Deadlock Ursachen

In den letzten Wochen gab es eine bemerkenswerte Häufung von interessanten Artikeln zum Thema deadlocks:

• Arup Nanda - Application Design is the only Reason for Deadlocks? Think Again: liefert eine instruktive Einführung zum Thema, erklärt, welche Lock-Typen im Spiel sind, wie man die zugehörigen trace files liest und führt aus, in welchen Fällen sich deadlocks ergeben, die nicht auf Fehler in der Anwendungslogik zurückzuführen sind (ITL shortage, unindexed foreign keys, direct load operations, bitmap index contention, PK overlap beim INSERT)
• Jonathan Lewis - deadlocks: erklärt, dass den rowid Angaben in deadlock Graphen in vielen Fällen nicht zu trauen ist: "When I see a deadlock graph on transaction locks and the waits are for S mode I tend to assume that the information about the rows waited on is probably misleading; when the slot number for the rowid is zero this increases my confidence that the rowid is rubbish."
• Christian Antognini - ITL Deadlocks (script): liefert ein Test-Script zu Erzeugung eines Beispiels für die (auch beim Herrn Nanda erwähnte) ITL shortage. Interessant ist am Artikel neben dem Script auch die hübsche Präsentation eines Mitschnitts der Scriptausführung.

Materialized View Fast Refresh für Outer Joins in 11.2.0.3

Alberto Dell'Era erläutert in seinem Blog die aktuelle Implementierung von Fast Refresh Operationen für Materialized Views auf der Basis von Outer Join Queries:

• fast refresh of outer-join-only materialized views – algorithm, part 1: erklärt, dass eine solche Fast Refresh Operation relativ übersichtlich ist, wenn es einen unique constraint auf den Join-Spalten gibt, der sicherstellt, dass die Gesamtzahl der Datensätze der Anzahl der Sätze der outer table entspricht, weil es zu jedem Satz dieser Tabelle genau ein oder kein Gegenstück in der inner table gibt. Außerdem wird erklärt, welche Indizes zur Beschleunigung der Refresh Operationen angelegt werden können.
  
• fast refresh of outer-join-only materialized views – algorithm, part 2: erklärt die komplexeren SQL-Operationen, die im Fall eines Fast Refreshs einer Outer-Join-MV ohne unique constraint auf den Join-Spalten erforderlich sind - und erläutert die Indizes, die zur Optimierung dieser Operationen angelegt werden können.

Meine Zusammenfassung erhebt einmal mehr nicht den Anspruch, eine erschöpfende Zusammenfassung zu sein, sondern soll nur als Verweis und Erinnerungsstütze dienen.

Details zum Hakan Factor

Vor zwei Jahren habe ich hier ein paar Bemerkungen zum Hakan Factor und zur MINIMIZE RECORDS_PER_BLOCK Option notiert. Jetzt hat Jonathan Lewis in seinem Blog ein paar der Informationen ergänzt, die mir damals fehlten: zunächst liefert er eine Procedure show_hakan, die die SPARE1-Angabe in TAB$ auswertet. Darüber hinaus bestätigt er die Beobachtung, dass man den Hakan Factor über MINIMIZE RECORDS_PER_BLOCK nicht dazu bringen kann, die Satzanzahl im Block auf 1 zu reduzieren, was anscheinend daran liegt, dass der Factor immer um 1 niedriger ist als die angestrebte Satzanzahl im Block und nicht auf 0 gesetzt werden kann. Anlass für den Artikel des Herrn Lewis war dabei ein Thread im OTN Forum, in dem Matthias Rogel auf einen Artikel von Karsten Spang hinwies, der noch ein paar zusätzliche Aussagen zum Thema enthält:

• Unterschiede im Hakan Factor sind eine wahrscheinliche Ursache für "ORA-14642: Bitmap index mismatch" beim Partition Exchange.
• da der Hakan Factor die Anzahl der rows pro Block angibt, muss er für alle Indizes der Tabellenpartitionen identisch sein, um bit Operationen (AND/OR) zu ermöglichen.
• mit ALTER TABLE ... MINIMIZE RECORDS_PER_BLOCK wird der aktueller aktuelle Maximalwert für die Sätze in einem Block bestimmt und als Limit für folgende INSERTs gesetzt. Das Kommando kann nur ausgeführt werden, wenn noch keine bitmap indizes für die Tabelle angelegt sind.
• Zur Interpretation von SPARE1 liefert Karsten Spang folgende Informationen:
• "Lower bits (at least 12, perhaps as many as 15): Håkan factor"
• "0×08000: MINIMIZE RECORDS_PER_BLOCK in effect"
• "0×10000: Seems to mean that the Håkan factor has been fixed higher than the value calculated from non-null columns."
• "0×20000: Table compression is enabled"
• mit Hilfe von Event 14529 kann man dafür sorgen, dass eine CTAS-Operation eine neue Tabelle mit dem Hakan Factor der Quell-Tabelle anlegt, was zur Lösung von Problemen mit ORA-14642 beitragen kann.

Da die angesprochenen Details nicht offiziell dokumentiert sind, handelt es sich natürlich bei allen Angaben um - begründete - Vermutungen.