Dienstag, Januar 31, 2012

Bug Fix Links

Wenn Jonathan Lewis eine Liste von Links erstellt, dann sind diese mit hoher Wahrscheinlichkeit relevant. Im gegebenen Fall geht es um Bug Fixes für aktuelle Oracle Releases.

Nachtrag 02.02.2012: Interessant ist auch der Hinweis eines weiteren Artikels, dass in 11.2.0.3 diverse Bugs aus dem CTE-Umkreis behoben sind. CTEs sind ein großartiges Mittel um Abfragen übersichtlicher zu gestalten und wenn sie jetzt auch noch robust werden, werde ich sie mit noch größerer Begeisterung einsetzen.

Donnerstag, Januar 26, 2012

Materialisierung von CTEs

Dom Brooks liefert eine Reihe interessanter Beobachtungen zur Materialisierung von CTEs, die entweder durch den Hint MATERIALIZE oder durch die mehrfache Referenzierung einer solchen Subquery hervorgerufen wird. Unter anderem zeigt er im 10046er Trace die DDL der erzeugten GTT (Global Temporary Table) und erklärt, dass diese Struktur für folgende Ausführungen des Cursors nicht neu erzeugt werden muss (und dass sie sogar für andere Sessions erreichbar ist). Außerdem weist er auf einige zugehörige Bugs im Zusammenhang mit Distributed Transactions hin.

Mittwoch, Januar 25, 2012

Execution Plans für DAX

Seitdem ich mich mit MDX beschäftige, hoffe ich darauf, über das Stadium der "Optimierung durch Ausprobieren" hinauszukommen. Voraussetzung dafür wären Execution Plans - aber die sind anscheinend ein Geheimnis der SSAS-Entwickler. Insofern wundere ich mich darüber, dass der SQL Server Profiler für Microsofts neue DAX-Sprache ein Event DAX Query Plan liefert. Eine Einführung dazu liefert Jeffrey Wang - und falls ich mal ernsthaft mit DAX arbeiten sollte, würde mir das vermutlich helfen.

Samstag, Januar 21, 2012

Fixed Object Statistics für X$-Objekte

Maria Colgan schreibt im Blog der CBO-Entwickler über die Bedeutung der Erhebung von Statistiken für Fixed Objects (als X$-Tabellen und -Indizes) mit Hilfe von:
DBMS_STATS.GATHER_FIXED_OBJECTS_STATS.
Wichtig sind die Statistiken, da der CBO für die X$-Objekte kein dynamic sampling durchführt, sondern Defaults verwendet, die natürlich in vielen Fällen unpassend sind. Gespeichert werden grundsätzlich die gleichen Statistiken, die auch für normale Tabellen erfasst werden, obwohl die X$-Objekte nur im Memory existieren (daher wird Blocks auf 0 gesetzt). Frau Colgan empfiehlt, die Statistiken unter repräsentativer Workload zu erzeugen. In den Kommentaren beantwortet sie auch noch die Frage, warum diese Statistikerfassung noch nicht  automatisiert wurde (die Antwort lautet: sie arbeiten dran, aber der passende Zeitpunkt für die Erfassung ist nicht leicht zu bestimmen). Gelegentlich ergänze ich hier vielleicht noch den Link auf einen Eintrag von Charles Hooper, der das Thema auch schon mal genauer beleuchtet hatte.

SCN

Zuletzt haben sich Martin Decker und Riyaj Shamsudeen ausführlicher zum Thema System Change Number (SCN) geäußert:
  • Martin Decker weist auf einen häßlichen Bug hin, der sich ergibt, wenn die SCN ihren Maximalwert erreicht - was unter bestimmten Umständen sehr viel schneller passieren kann, als man angesichts des gigantischen Werteraums, der für sie zur Verfügung steht, erwarten würde.
  • Bei Riyaj Shamsudeen erfährt man Grundsätzliches zum Thema, beispielsweise zum gerade angesprochenen Wertebereich: "SCN is a huge number with two components to it: Base and wrap. Wrap is a 16 bit number and base is a 32 bit number. It is of the format wrap.base. When the base exceeds 4 billion, then the wrap is incremented by 1. Essentially, wrap counts the number of times base wrapped around 4 billion." Außerdem wird erläutert, wo die SCN verwendet und wann sie erhöht wird, und auch die Bugs, die der Herr Decker anspricht, werden beleuchtet.

Donnerstag, Januar 19, 2012

Cost für Scalar Subqueries

Dom Brooks weist in seinem Blog darauf hin, dass Oracle auch in aktuellen Releases die Kosten von scalar subqueries (also Subqueries in der SELECT-Liste, die für jeden einzelnen Ergebnissatz ausgeführt werden) nicht in in die Gesamtkosten einer Query einrechnet (was Jonathan Lewis in einem verlinkten Artikel damit begründet, dass der cbo nicht schätzen möchte, wie oft diese Unterabfrage ausgeführt wird - obwohl er ja die Menge der Ergebnissätze der Haupt-Query durchaus prognostiziert). Außer auf den Herrn Lewis wird auch noch auf Randolf Geist (der grundsätzlich darauf hinweist, dass Oracle "obviously treats work that has to be performed as part of the projection differently than work that has to be performed as part of the selection part"; der Fall ist demnach verwandt mit den problematischen Kostenschätzungen für user-defined functions, zu denen der Herr Geist in jüngerer Vergangenheit einiges geschrieben hat) und Gary Myers verwiesen, die sich auch schon gelegentlich zum Thema geäußert haben.

Ein Hinweis also, dass man scalar subqueries mit Vorsicht zu verwenden hat - aber das sollte man ohnehin, weil sie ab einer gewissen Größe der Ergebnismenge unheimlich kostspielig werden.

Bei nochmaliger Durchsicht des Absatzes wird mir klar, dass ich mir nicht nur über den Einsatz von scalar subqueries, sondern auch über den von Parenthesen Gedanken machen sollte.

Mittwoch, Januar 18, 2012

Richard Foote über IOTs

Nachdem Martin Widlake im vergangenen Jahr eine interessante Serie über Index Organized Tables veröffentlichte, hat jetzt auch Richard Foote begonnen, das Thema genauer zu erläutern. Hier eine Liste der bisher veröffentlichten Artikel:
  • Index Organized Tables – An Introduction Of Sorts (Pyramid Song): zeigt - unter anderem anhand von Index Block Dumps - inwiefern eine IOT einem entsprechenden Index überlegen ist (soll heißen: kompakter ist), der alle für eine Query relevanten Spalten enthält (also einem "fat" oder "covering" index): der zentrale Unterschied liegt darin, dass in der IOT keine rowid gespeichert werden muss, da der Verweis auf das zugehörige Tabellensegment entfallen kann (da es kein solches Segment gibt).
  • Index Organized Tables – Overflow Segment (Shadow Man): erklärt den Sinn des Overflow-Segments, in das Spalten abgeschoben werden können, auf die eher selten zugegriffen wird. Solche Spalten würden die Index-Struktur unnötig aufblähen. Stattdessen kann man sie ins Overflow-Segment auslagern, das mehr oder minder einer Heap-Tabelle entspricht, aber nicht alle Spalten enthält (sondern nur die nutzlosen). Der erforderliche Pointer in der Index-Struktur nennt sich im Dump "consisting of a 6 byte relative block address and row directory number". Während der Zugriff auf die Spalten im Index-Segment dadurch beschleunigt wird, erhöhen sich (natürlich) die Kosten für den Zugriff auf die ausgelagerten Spalten gegenüber einer entsprechenden IOT ohne Overflow-Segment.
  • Index Organized Tables – Overflow Segment Part II (The Loneliest Guy): hier erklärt Herr Foote, dass er  (wie vermutlich die meisten Leute) PK-Spalten gerne an den Anfang der Spaltenliste einer Heap-Tabelle stellt, obwohl es durchaus auch Gründe dafür gäbe, sie nicht dort zu positionieren (da man ohnehin häufig über den PK zugreift und dann erst einmal über die bereits bekannten PK-Infos drüberlesen muss). Für IOTs ist die Platzierung der PK-Spalten an führende Stelle entscheidend. Tatsächlich ignoriert Oracle jede abweichende Definition und ordnet die PK-Spalten intern an den Anfang der Tabelle (was in der SEGMENT_COLUMN_ID in DBA_TAB_COLS abzulesen ist). Eine solche Umordnung kann dann unerfreuliche Wirkungen darauf haben, welche Spalten im Overflow-Segment landen, was man vor kurzem auch schon mal bei Jonathan Lewis lesen konnte.
  • Index Organized Tables – PCTTHRESHOLD (The Wedding Song): liefert (wie der Titel bereits andeutet) eine nähere Erläuterung zur PCTTHRESHOLD-Angabe, mit deren Hilfe sich exakter steuern lässt, welche Attribute im IOT-Segment und welche im Overflow-Segment landen: "with a PCTTHRESHOLD of (say) 5, the non-PK columns up to the INCLUDING clause will be included within the IOT but only if the resultant row size is less than 5% of the blocksize."
  • Indexed Organized Tables – An Introduction to IOT Secondary Indexes (A Second Face): erläutert die Definition von sekundären Indizes zu einer IOT: da ein solcher Index nicht die rowid des Tabellensatzes enthalten kann (da die Sätze in der IOT ja ihren physikalischen Speicherort ändern können), besteht er aus den indizierten Spaltenwerten, dem PK der IOT und einer Angabe des initialen physikalischen Speicherortes des Satzes in der IOT: falls der Satz noch dort steht, wo er ursprünglich angelegt wurde, hat man Glück. Wenn nicht, dann wird ein zusätzlicher Scan des PK-Index erforderlich. Relevant ist jedenfalls, dass der sekundäre Index nicht aktualisiert wird, wenn sich die Position von Sätzen in der IOT verändert (was allerdings auch ein ziemlich teures Verfahren wäre).
  • IOT Secondary Indexes: Primary Key Considerations (Beauty And The Beast): zeigt, dass die sekundären Indizes einer IOT größer sind als Indizes von Heap-Tabellen, da sie den PK der IOT enthalten müssen (und somit auch redundante Speicherung hervorrufen, die die IOT ja eigentlich vermeiden will). Für Fälle, in denen ein sekundärer Index eine Teilmenge der Spalten des PK enthält, kann der Overhead entfallen (was die Spalte iot_redundant_pkey_elim in dba_indexes anzeigt).
  • IOT Secondary Indexes – The Logical ROWID Guess Component Part I (Lucky): erläutert die Rolle des rowid "guesses" mit dem ein sekundärer Index auf die ursprüngliche rowid des zugehörigen IOT-Satzes verweist: ursprünglich treffen dieses Vermutungen alle zu, aber wenn neue Sätze in die Tabelle eingefügt werden, ergeben sich Block-Splits und die Angaben werden unzutreffend. In diesem Fall ist ein Neuaufbau des sekundären Index mit der Option "UPDATE BLOCK REFERENCES" nützlich.
  • IOT Secondary Indexes – The Logical ROWID Guess Component Part II (Move On): weist darauf hin, dass die Invalidierung der "rowid guesses" nur bei 50:50-Block-Spilts erfolgt. Im Fall eines Hinzufügens von Einträgen am Endes des Index, also z.B. über einen monoton steigenden PK-Wert, und 90:10-Splits (die ja eigentlich 100:0-Splits sind, da ein neuer (nahezu) leerer Block in die Index-Struktur eigefügt wird) ergibt sich keine physikalische Verschiebung in der IOT. Außerdem erklärt der Herr Foote, dass ein MOVE für eine IOT als ONLINE-Operation erfolgen kann und sekundäre Indizes dabei VALID bleiben - allerdings leidet ihre Effizienz, da alle  "rowid guesses" jetzt falsch sind.
Da es kaum jemanden gibt, der komplexe Sachverhalte in Oracle so klar darstellt wie der Herr Foote - und wahrscheinlich so gut wie niemanden, der sich mit Indizes besser auskennt -, lohnt es sich auf jeden Fall, die Artikel im Original zu lesen.

Christian Antognini vertritt in seinem Performance Tuning Buch übrigens die Ansicht, dass die Verwendung von Overflow-Segmenten in IOTs weitgehend sinnfrei ist, da man damit die Vorzüge des Tabellentyps (zumindest zum Teil) wieder verliere. Ich vermute, das ist mal wieder ein Fall von "It depends".

Aus Gründen der Vollständigkeit auch noch der Link auf Julian Dykes ausführliche Präsentation zum gleichen Thema.

Dienstag, Januar 17, 2012

Inkrementelle Statistiken

Randolf Geist beschäftigt sich in seinem Blog mit den Eigenschaften der in 11g eingeführten inkrementellen Partitions-Statistiken: "The most important point to understand is that Incremental Partition Statistics are not "cost-free", so anyone who is telling you that you can gather statistics on the lowest level (partition or sub-partition in case of composite partitioning) without any noticeable overhead in comparison to non-incremental statistics (on the lowest level) is not telling you the truth." Die angesprochenen Kosten liegen im Bereich der Laufzeiten und beim Speicherplatzbedarf in SYSAUX. Außerdem werden ein paar wichtige Detailbeobachtungen aufgeführt (z.B. wird bei Verwendung von INCREMENTAL die ESTIMATE_PERCENT-Angabe ignoriert).

Ein paar (geringfügig) ältere Stellungnahmen zum Feature hatte ich vor kurzem hier verlinkt.

Nachtrag 21.01.2012: Doug Burns, der dem Thema der Statistiken für Partitioned Tables im Jahr 2010 eine ganze Artikelserie gewidmet hat, gibt in seinem Blog mit Bezug auf Randolfs Aussagen noch zwei Kommentare zu den inkremetellen Statistiken:
  • dass Oracle beim initialen Aufbau von inkrementellen Statistiken die komplette Tabelle lesen muss, um die Synopsis aufzubauen, erscheint selbstverständlich: diese lange Laufzeit ist unvermeidbar
  • "Incrementals are a replacement for GRANULARITY=>'GLOBAL AND PARTITION' and not 'PARTITION'! Expecting an option which gathers Partition stats and then goes around updating synposes to perform as well as a simple partition gather is unrealistic*. Any performance improvement needs to be measured against both gathering the Partition stats and maintaining the Global stats. Incrementals will almost definitely be quicker than that!"
Der Vollständigkeit halber noch der Hinweis, dass diese Aussagen keinen Widerspruch zu den Geist'schen Ausführungen darstellen.

Nachtrag 18.03.2012: Maria Colgan erläutert im Blog der CBO-Entwickler, wann eine Erhebung inkrementeller Statistiken erfolgt: "incremental statistics maintenance will gather statistics on any partition, whose data has changed and that change will impact the global level statistics."

Mittwoch, Januar 11, 2012

Löschung eines verwendeten DB-Links

Was passiert, wenn man einen DB-Link löscht, der gerade in einer anderen Session verwendet wird? Die Antwort lautet: der Link wird gelöscht, ohne dass die zweite Session sich daran stört.

-- Session 1
-- Anlage eines DB-Links 
-- (in diesem Fall ein loopback Link auf die gleiche Instanz,
-- was aber wohl keine Rolle spielt)
create database link loopback using 'TestDB';

-- Session 2
select count(*) from t_remote@loopback;

-- Session 1
drop database link loopback;

-- Session 2
--> liefert das Ergebnis der Abfrage

  COUNT(*)
----------
  24800000

-- erneute Ausführung
select count(*) from t_remote@loopback
                              *
FEHLER in Zeile 1:
ORA-02019: Verbindungsbeschreibung für Fern-Datenbank nicht gefunden

Somit bleibt die Verbindung also für die Dauer der Query bestehen. Wenn ich darüber nachdenke, ist das Verhalten auch ganz plausibel: selbst die Löschung einer Tabelle führt ja nicht (notwendigerweise) zum Abbruch einer Query.

Nachtrag 30.04.2012: in manchen Fällen führt das Löschen eines verwendeten DB-Links aber offenbar auch zum Fehler "ORA-02018: Datenbank-Link desselben Namens hat eine offene Verbindung", aber die genauen Bedingungen für das Auftreten des Fehlers sind mir noch unklar. Grundsätzlich halte ich DB-Links aber für statische Objekte, die man nicht nach Lust und Laune löschen oder umdefinieren sollte.

Freitag, Januar 06, 2012

Index-Größenschätzung durch Explain Plan

Heute ist mir zum ersten Mal aufgefallen, dass Explain Plan für ein CREATE INDEX eine Größenschätzung liefert:

explain plan for
create index idx_t1 on t1(a);

select * from table(dbms_xplan.display);

Plan hash value: 2186317495

---------------------------------------------------------------------------------
| Id  | Operation              | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------
|   0 | CREATE INDEX STATEMENT |        |   257K|  3264K|  1001   (1)| 00:00:13 |
|   1 |  INDEX BUILD NON UNIQUE| IDX_T1 |       |       |            |          |
|   2 |   SORT CREATE INDEX    |        |   257K|  3264K|            |          |
|   3 |    TABLE ACCESS FULL   | T1     |   257K|  3264K|   858   (1)| 00:00:11 |
---------------------------------------------------------------------------------

Note
-----
   - estimated index size: 7340K bytes

Bisher war ich nie auf die Idee gekommen, dass Explain Plan für einen Index interessant sein könnte. Der Versuch herauszufinden, seit wann diese Option existiert, hat mich dann mal wieder zu Randolf Geists Blog geführt, wo sich ein Artikel EXPLAIN PLAN on DDLs findet, der diese und manch andere Frage beantwortet:
Starting with Oracle 10.2 you'll get an indication of the size of the index based on the dictionary statistics in the "Notes" section, so the estimate is only as good as your statistics allow for, in addition above points apply regarding the accuracy of the estimate in case of null values or function-based indexes. The size estimate is obviously based on the average column length recorded in the statistics.
Insgesamt scheint die Aussagekraft der Schätzung allerdings recht beschränkt zu sein, da sie diverse relevant Punkte ignoriert (Anzahl NULLs, implizite Tablespace-Zuordnung, Kompression, FBI, keine Unterscheidung zwischen B*Tree und Bitmap), wie Randolf anhand praktischer Tests nachweist.

Nachtrag 08.01.2012: kaum schreibe ich darüber, da sehe ich, dass Jonathan Lewis gerade gezeigt hat, dass die Schätzung einen recht massiven Bug enthält (zumindest bis inklusive 11.2.0.2)

Nachtrag 24.04.2014: einen Artikel zum Thema gibt's jetzt auch von Richard Foote.

Mittwoch, Januar 04, 2012

Oracle Core von Jonathan Lewis

Kurz nach Weihnachten hat mir Amazon das bei Apress erschienene Buch Oracle Core. Essential Internals for DBAs and Developers von Jonathan Lewis zugeschickt. Bei Amazon gibt's dazu aktuell fünf Customer Reviews, die dem Buch jeweils fünf Sterne zusprechen - die erste und ausführlichste hat (natürlich) Charles Hooper geliefert (und man findet sie - natürlich - auch in seinem Blog). Wenn man berücksichtigt, dass ich hier vermutlich auf keinen anderen Blog so viele Links setze, wie auf das Lewis'sche Scratchpad und dass ich kein anderes Buch so oft erwähne wie Cost-Based Oracle, überrascht's vermutlich nicht allzu sehr, dass ich jetzt in die allgemeinen Lobeshymnen einstimmen werde: der Herr Lewis hat da - zum dritten Mal (nach dem CBO-Buch und dem selbst heute noch relevanten Practical Oracle 8i aus dem Jahr 2000) - ein grundlegendes Buch zum Verständnis des Oracle Servers vorgelegt. Tanel Poder, der offizielle Technical Reviewer des Bandes (was ein weiteres Qualitätssiegel wäre, wenn man noch eines brauchte), schreibt in seinem Amazon-Kommentar: "It will probably become THE technical source for Oracle internals information for the next 10 years, just like Steve Adams'es Oracle Internal Services book was in the previous decade." Und damit hat er vermutlich recht.

Was der Herr Lewis in seinem Buch leistet, ist das, was Tom Kyte in Expert Oracle Database Architecture explizit verweigert: "Time and time again, I get questions regarding the exact bits and bytes of redo and undo. People seem to want to have a very detailed specification of exactly, precisly, what is in there. I never answer those questions." (S. 299) Der Herr Kyte hat dafür durchaus gute Gründe: er will die grundsätzlichen Konzepte erläutern und erklären, wozu redo und undo gedacht sind und wie sie zusammenarbeiten. Möglicherweise sieht er auch ähnliche Problem wie Tanel Poder, dessen (in Oracle Core zitierte) Erklärung, warum er selbst kein Buch über Oracle Internals schreibe, lautet: "I think the subject just changes too fast." (S. XIV) Dass Jonathan Lewis trotzdem ein Buch geschrieben hat, dessen Halbwertszeit - meiner Einschätzung nach - recht hoch sein wird, liegt daran, dass er in erster Linie über die grundlegendsten Mechanismen des Oracle Servers schreibt, und diese Mechanismen sind letztlich doch recht stabil. Vieles von dem, was man in Oracle Core findet, konnte man auch schon anderswo lesen: vor allem in den zahlreichen hochklassigen Blogs der Oracle-Community. Aber die konsistente Darstellung dieser Einzelbeobachtungen im Zusammenhang ist die große Leistung des Herrn Lewis, der meiner Meinung nach ohnehin einer der besten Stilisten unter den Oracle-Autoren ist.

Es folgt eine kurze Zusammenfassung der Kapitel des relativ schmalen Bandes (266 Seiten), aber die wird hier als work-in-progress erst allmählich entstehen, weil mich die nachvollziehende Lektüre sehr viel Zeit kosten wird:

Kapitel 1: Getting Started: liefert auf vier Seiten eine ganz knappe Übersicht zu den Prozessen und Speicherstukturen in einer Oracle Instanz.

Kapitel 2: Redo and Undo: erläutert das Zusammenspiel von Redo und Undo bei einer Blockänderung: zu jeder Änderung werden eine redo-Information und eine undo-Information erzeugt, wobei auch für die undo-Information noch einmal eine redo-Information geschrieben werden muss. Erst dann kann die Änderung im data block erfolgen. Die Reihenfolge ist dabei:
  • change vector für undo record erzeugen
  • change vector für data block erzeugen
  • change vektoren kombinieren und redo in den log buffer schreiben
  • undo record in den undo block schreiben
  • Änderung des data blocks durchführen
In älteren Releases wurde für jede Änderung einer Session ein redo record in den log buffer eingetragen, aber seit Oracle 10 werden mehrere Änderungen in einem privaten Speicherbereich (private strand) gesammelt und dann zusammengefasst gespeichert, was eine Reduzierung der erforderlichen Latches (redo copy, redo allocation) herbeiführt (allerdings kommen neue In memory undo Latches hinzu), die dadurch noch signifikanter wird, dass es mehrere child latches für die In memory undo Latches gibt, während die Latches für den zentralen Log Buffer notwenigerweise eine knappe Ressource waren.

Wie die folgenden Kapitel basiert auch dieses auf der detaillierten Auswertung von Block Dumps, die alle relevanten Informationen zu den Zusammenhängen enthalten - man muss sie nur interpretieren können ...

Sonntag, Januar 01, 2012

SSD für Oracle-Datenbanken

Bei Gwen Shapira findet man ein paar grundlegende Informationen zum Einsatz von SSDs in Oracle-Datenbanken - interessant sind dabei auch die zahlreichen Kommentare zum Artikel. Zu den wichtigsten Hinweisen gehören die Erläuterungen zur Performance bei Lese- und Schreiboperationen unterschiedlichen Typs. Ohne den Artikel komplett exzerpieren zu wollen hier ein paar der wichtigsten Punkte:
  • SSD ist nur interessant, wenn die Hauptlast einer DB im I/O-Bereich liegt (was bei den meisten DBs, die ich sehe, der Fall ist).
  • wenn man es bezahlen kann, sollte man alle data files auf SSD legen.
  • für die redo logs sind SSDs nicht geeignet, da sie bei sequentiellem Schreiben keine Vorteile gegenüber spinning disks haben.
  • man kann SSDs über die Option Database Smart Flash Cache als sekundären Cache der SGA verwenden - dort können dann Blöcke zwischengespeichert werden, die aus dem Buffer Cache heraus gefallen sind, was das erneute Laden natürlich beschleunigt.
  • Für Exadata sieht alles noch mal ganz anders aus, aber Exadata ist dieser Tage nicht mein Thema.

CBO Verbesserungen in 11g

Christian Antognini hat die Powerpoint-Folien zu seiner Präsentation Challenges and Chances of the 11g Query Optimizer auf seiner Webseite verfügbar gemacht - und liefert damit eine sehr kompakte Zusammenfassung der in Version 11 ergänzten Features des CBO und der Statistikerfassung. Hier ein paar der aufgeführten Punkte:
  • Indizes
    • invisible indexes
    • Verwendung von linguistic indexes bei LIKE
    • Statistik Historie bleibt nach Index Rebuild erhalten (erst in 11.2)
  • CBO
    • FULL OUTER JOIN wird intern nicht mehr durch  UNION ALL abgebildet
    • Join-Filter Pruning (ist mir noch nicht völlig klar)
    • Table Expansion: unterschiedliche Teile einer partitionierten Tabelle können über unterschiedliche Zugriffswege abgearbeitet werden (FTS + Index-Zugriff)
    • Join Factorization: ein für mehrere Teile eines UNION ALL gemeinsamer Zugriff kann heraus faktoriert und nur einmal ausgeführt werden (erst in 11.2)
    • OR Expansion funktioniert auch mit FBI
    • Join Elimination: ein überflüssiger Join kann vermieden werden, wenn entsprechende Constraints existieren
    • Subquery Unnesting: NOT IN und NOT EXISTS werden in Joins umgewandelt, mit denen der CBO besser zurecht kommt
  • Statistiken
    • Bugs für System Statistics beseitigt
    • Präferenzen für Objekt-Statistiken definierbar
    • Auto Sample Size funktioniert jetzt richtig
    • Pending Statistics: werden nicht unmittelbar nach der Anlage veröffentlicht
    • Incremental Statistics für partitionierte Tabellen (dazu gibt's hier ein paar weiterführende Anmerkungen)
    • Extended Statistics für Expressions und Spaltengruppen (in 11.2.0.2 kann man automatisch bestimmen lassen, für welche Spaltengruppen solche Korrelationsstatistiken angelegt werden sollten)
    • Funktionen zum Vergleich von Statistiken
  • Plan Stabilität
    • cursor_sharing = similar ist deprecated; es wurde gelegentlich als Krücke für Applikationen, die keine Bindevariablen verwenden, vorgeschlagen
    • Einführung von SPM
    • Adaptive Cursor Sharing
    • Cardinality Feedback