Skip to Main Content

Breadcrumb

Undokumentierte Optimizer Verhaltensänderung

Undokumentierte Optimizer Verhaltensänderung mit Windows Patchbundle 12.1.0.1.160319

Die Ausgangssituation

Oracle 12.1.0.1.0 SE (inkl. Patch 22617408 - WINDOWS DB BUNDLE PATCH 12.1.0.1.160419) unter Windows Server 2012 (64bit)- Datenbank läuft problemlos und ohne Performanceprobleme.

Folgende Optimizer-relevante Parameter wurden bereits angepasst:

optimizer_index_cost_adj = 15
optimizer_index_caching = 80
query_rewrite_enabled = false
_optim_peek_user_binds = false
_optimizer_use_feedback = false

Das Problem

Nach der Installation von Patch 23530410 (WINDOWS DB BUNDLE PATCH 12.1.0.1.160719) laufen einige Datenbankabfragen wesentlich langsamer.

Die Beschreibungen der "neuen" Bug Fixes geben keinerlei Hinweis auf etwaige Änderungen rund um den Optimizer.

Die beobachteten Planänderungen sind konstant, mehrfache Ausführungen der Abfragen beeinflussen die Performance in keiner Weise.

Durch eine nähere Analyse mittels Event 10053 konnten noch weitere Eckpunkte festgemacht werden:

  • Die zwischen Patch 23530410 und Patch 22617408 eingeführten Bug Fixes bewirken keine Änderungen an der Optimizer Umgebung ("Underscore Parameter", "Fix Controls", etc.).
  • Allen Planänderungen liegt eine Kostenänderung für einen Index zu Grunde, obwohl weder die Systemstatistiken, Objektstatistiken noch der Index selbst verändert wurden.

ohne Patch 23530410:

...
Access Path: index (AllEqRange)
Index: LCD_IX3_VAN
resc_io: 1375.00 resc_cpu: 27773020
ix_sel: 0.336465 ix_sel_with_filters: 0.336465
Cost: 206.70 Resp: 206.70 Degree: 1
...

mit Patch 23530410:

...
Access Path: index (AllEqRange)
Index: LCD_IX3_VAN
resc_io: 4.00 resc_cpu: 28901
ix_sel: 0.000004 ix_sel_with_filters: 0.000004
Cost: 1.00 Resp: 1.00 Degree: 1
...

Seltsamerweise erfahren alternative Indices auf der gleichen Tabelle keinerlei sprunghafte Kostenänderungen.

Durch die radikale Änderung der Zugriffskosten für diesen Index werden in weiterer Folge auch die Spalten / Selektivität für den Zugriff auf die Tabelle sowie die Filterbedingungen geändert, welche zu einem ineffektiven Zugriffsplan führen.

Der Workaround

Eine Änderung von Datenbank-Parametern kam wegen der potentiellen Beeinflussung anderer Abfragen nicht als Lösung in Frage.

Nachdem eine Änderung der Abfragen selbst rasch und einfach möglich war, wurden diese mittels "Hints" entsprechend angepasst.

Anmerkung: auch der Einsatz des Rule-Based Optimizers (z.B. mittels "Hint") hätte in diesem Fall zum Erfolg geführt!