Wait Event "latch free" nach Upgrade auf 12c
Nach einem Upgrade - 11gR2 Enterprise Edition unter Windows nach 12cR1 unter Linux - treten bei gewissen Verarbeitungen signifikante Performanceeinbußen gegenüber dem Altsystem auf, die die für das Neusystem getätigten Investitionen in Frage stellen.
Die Nutzung des Datenbank Diagnostic Pack ist diesem Fall durch die vorhandenen Lizenzen abgedeckt, es können daher Auswertungen über das Automatic Workload Repository zur Problemlösung herangezogen werden.
In einem entsprechenden AWR Report finden sich u.a. folgende Informationen:
Top 10 Foreground Events by Total Wait Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Total Wait Wait % DB Wait
Event Waits Time (sec) Avg(ms) time Class
------------------------------ ----------- ---------- ---------- ------ --------
latch free 717,849 654,6K 911.86 77.1 Other
Welcher Latch könnte das sein ?
Pct Avg Wait Pct
Get Get Slps Time NoWait NoWait
Latch Name Requests Miss /Miss (s) Requests Miss
------------------------ -------------- ------ ------ ------ ------------ ------
...
Result Cache: RC Latch 14,818,298 5.4 1.0 7.E+05 0 N/A
...
Result Cache?
SYS> show parameter result_cache_mode
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
result_cache_mode string MANUAL
SYS> select * from v$result_cache_objects;
...
34 Result Invalid 3843 3154099971 SELECT /* DS_SVC */ /*+ dynamic_sampling(0) ....
...
Der Result Cache ist zur Gänze mit Resultaten von Queries der Form "SELECT /* DS_SVC */ ...." gefüllt, die offensichtlich die o.a. Waits verursacht haben.
Was sind das für Queries?
Diese Queries werden durch Adaptive Dynamic Sampling verursacht, welches Bestandteil der Optimizer Adaptive Features ist (neu in 12c).
Standardmäßig werden diese Abfragen zur Ermittlung fraglicher Kardinalitäten während des Parsens durchgeführt und im Result Cache gespeichert.
Ist der Result Cache nicht dafür optimiert oder werden aufgrund der Applikationscharakteristik unnötig viele Parses innerhalb kurzer Zeit durchgeführt, kommt es zu "latch free" Waits, weil jedes neue Resultat beim Einfügen in den Result Cache den entsprechenden Latch (kurzfristige Sperre) exklusiv beansprucht.
Wie kann das Problem kurzfristig behoben werden?
Wir empfehlen folgendes schrittweises Vorgehen (i.e. erst falls eine Maßnahme nicht den gewünschten Effekt erzielt, wird die jeweils nächste Maßnahme aktiviert):
-
Parameter "_optimizer_ads_use_result_cache" auf "FALSE" setzen (alle Funktionalitäten der Optimizer Adaptive Features bleiben aktiviert, nur die Speicherung im Result Cache wird deaktiviert)
-
Parameter "_optimizer_dsdir_usage_control" auf 0 setzen (SQL Plan Direktiven für Adaptive Dynamic Sampling werden deaktiviert)
-
Parameter "_sql_plan_directive_mgmt_control" auf 0 setzen (Erstellung von SQL Plan Direktiven wird deaktiviert)
-
Parameter "_optimizer_use_feedback" und "_optimizer_gather_feedback" auf "FALSE" setzen (Statistics / Cardinality Feedback wird deaktiviert)
-
Parameter "optimizer_adaptive_features" auf "FALSE" setzen (alle Funktionalitäten der Optimizer Adaptive Features werden deaktiviert)
-
Parameter "optimizer_features_enable" auf "11.2.0.4" setzen (alle Optimizer Features aus 12c werden deaktiviert)
Wie kann das Problem langfristig behoben werden?
Mit dem Upgrade auf 12cR2 (12.2.0.1.0) werden ADS Query Resultate im Data Dictionary abgespeichert (SQL Plan Directive Repository).
Desweiteren sind mit 12cR2 alle "adaptive Statistics" Features standardmäßig deaktiviert (Parameter "optimizer_adaptive_statistics").