Home > Oracle 12c Datenbank > "latch free" Wait Event nach Upgrade auf 12c

"latch free" Wait Event nach Upgrade auf 12c

Wait Event "latch free" nach Upgrade auf 12c

Nach einem Upgrade - 11gR2 Standard 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").