Po ostatniej aktualizacji do 12.1.0.2 pracowałem nad kilkoma problemami z wydajnością. Wiele takich problemów jest związanych ze słabym SQL, a udowodniłem, że kilka rozwiązanych przeze mnie problemów dotyczyło starej wersji 11.2.0.4. To po prostu oznacza, że zawsze był to problem. Ale ludzie korzystają z możliwości aktualizacji, abym mógł naprawić rzeczy, które zostały zepsute od dłuższego czasu.
Patrząc na problemy z wydajnością, natknąłem się na dwie instrukcje SQL, które stają się świniami w naszym systemie. Oto zrzut ekranu dwóch instrukcji SQL widocznych w Lighty:
Widzimy, że pierwsza instrukcja SQL (identyfikator SQL 4b4wp0a8dvkf0) zużywa procesor i czeka na odczyty z pliku kontrolnego. Druga instrukcja SQL (identyfikator SQL frjd8zfy2jfdq) zużywa dużo procesora i ma również wiele innych zdarzeń oczekiwania. Oto tekst SQL tych instrukcji.
Identyfikator SQL:frjd8zfy2jfdq
SELECT
executions
,end_of_fetch_count
,elapsed_time / px_servers elapsed_time
,cpu_time / px_servers cpu_time
,buffer_gets / executions buffer_gets
FROM
(
SELECT
SUM (executions) AS executions
,SUM (
CASE
WHEN px_servers_executions > 0
THEN px_servers_executions
ELSE executions
END
) AS px_servers
,SUM (end_of_fetch_count) AS end_of_fetch_count
,SUM (elapsed_time) AS elapsed_time
,SUM (cpu_time) AS cpu_time
,SUM (buffer_gets) AS buffer_gets
FROM
gv$sql
WHERE
executions > 0
AND sql_id = : 1
AND parsing_schema_name = : 2
Identyfikator SQL:4b4wp0a8dvkf0
SELECT
executions
,end_of_fetch_count
,elapsed_time / px_servers elapsed_time
,cpu_time / px_servers cpu_time
,buffer_gets / executions buffer_gets
FROM
(
SELECT
SUM (executions_delta) AS EXECUTIONS
,SUM (
CASE
WHEN px_servers_execs_delta > 0
THEN px_servers_execs_delta
ELSE executions_delta
END
) AS px_servers
,SUM (end_of_fetch_count_delta) AS end_of_fetch_count
,SUM (elapsed_time_delta) AS ELAPSED_TIME
,SUM (cpu_time_delta) AS CPU_TIME
,SUM (buffer_gets_delta) AS BUFFER_GETS
FROM
DBA_HIST_SQLSTAT s
,V$DATABASE d
,DBA_HIST_SNAPSHOT sn
WHERE
s.dbid = d.dbid
AND bitand (
nvl (
s.flag
,0
)
,1
) = 0
AND sn.end_interval_time > (
SELECT
systimestamp AT TIME ZONE dbtimezone
FROM
dual
) - 7
AND s.sql_id = : 1
AND s.snap_id = sn.snap_id
AND s.instance_number = sn.instance_number
AND s.dbid = sn.dbid
AND parsing_schema_name = : 2
)
)
Oba te elementy są częścią nowych funkcji Adaptacyjnej Optymalizacji Zapytań w 12c. Dokładniej, odnoszą się one do części tej funkcji automatycznych statystyk dynamicznych. Identyfikator SQL frjd8zfy2jfdq to Oracle pozyskujący informacje o wydajności instrukcji SQL z GV$SQL. Identyfikator SQL 4b4wp0a8dvkf0 to Oracle uzyskujący te same informacje o wydajności instrukcji SQL z tabel historii aktywnej sesji.
Bertand Drouvot omawia to na swoim blogu tutaj:https://bdrouvot.wordpress.com/2014/10/17/watch-out-for-optimizer_adaptive_features-as-it-may-have-a-huge-negative-impact/
Dodatkowo uczestniczyłem w sesji Christiana Antogniniego na Oak Table World 2015, podczas której wspomniał o tych instrukcjach SQL. Jego slajdy z OTW są prawie takie same jak te:
http://www.soug.ch/fileadmin/user_upload/SIGs/SIG_150521_Tuning_R/Christian_Antognini_AdaptiveDynamicSampling_trivadis.pdf
Powyższe linki i notatki MOS, do których odnoszę się poniżej, dostarczyły wielu podstaw informacji, które tutaj przedstawiam.
Wszystkie funkcje Adaptive Query Optimization mają na celu poprawę życia DBA. Mają one pomóc Optymalizatorowi w podejmowaniu lepszych decyzji, nawet po rozpoczęciu wykonywania instrukcji SQL. W tym konkretnym przypadku te zapytania mają pomóc CBO w uzyskaniu lepszych statystyk, nawet jeśli ich brakuje. Może to pomóc w poprawie wydajności SQL, ale jak zauważyłem w moim przypadku, zmniejsza ogólną wydajność systemu.
Więcej informacji na temat adaptacyjnej optymalizacji zapytań zawiera uwaga 2031605.1. Doprowadzi to do innych notatek, ale w szczególności do tej dyskusji, Notatki 2002108.1 Automatyczne statystyki dynamiczne.
Co gorsza, mój system produkcyjny, który widzi to zachowanie, to Oracle RAC. Gdy identyfikator SQL ID frjd8zfy2jfdq jest wykonywany w systemach Oracle RAC, używane jest zapytanie równoległe, co jest oczywiste z mojego zrzutu ekranu z enq:PS – rywalizacja i zdarzenia oczekiwania „PX%”.
Próbkowanie dynamiczne możemy wyłączyć w następujący sposób:
zmień zestaw systemowyOptimizer_dynamic_sampling=0 scope=oba;
Domyślna wartość tego parametru to 2.
Dla mnie te zapytania zużywają zasoby i wpływają na ogólną wydajność bazy danych. Jednak te funkcje mają na celu ulepszenie występ. Zawsze istnieje ryzyko, że jeśli wyłączę tę funkcję, aby poprawić wydajność w jednym obszarze, obniży to wydajność w innym obszarze. Ale odkąd Optimizer_dynamic_sampling<>11 dla mnie nie korzystam w pełni z tej funkcji, więc nie uzyskuję wszystkich korzyści, jakie mógłbym osiągnąć. Ponadto nasz kod nie opiera się na dynamicznym próbkowaniu. Więc mogę bezpiecznie to wyłączyć.
Po zmianie parametru mogłem zobaczyć natychmiastową zmianę, jak pokazano poniżej.
Czerwona linia wskazuje czas, w którym dokonałem zmiany. Oczywiste jest, że wersja ASH tego zapytania nie jest już wykonywana. Wersja V$SQL nadal jest wykonywana, ale nie widzi już zdarzeń oczekiwania na zapytania równoległe. Teraz głównie zużywa procesor. Uważam ten postęp, ale nie pełną rozdzielczość.
Na marginesie mogłem wyłączyć wszystkie funkcje adaptacyjnej optymalizacji zapytań w następujący sposób:
alter system set optimizer_adaptive_features=false scope=both;
Ale wiem, że mam zapytania „korzystające z” Adaptive Join Optimization i nie chcę tego wszystkiego wyłączać, tylko dynamiczne próbkowanie.
Więc co teraz zrobić z identyfikatorem SQL frjd8zfy2jfdq? Zobaczmy, czy możemy rozwiązać pozostały problem. Z jednej z notatek MOS, które połączyłem powyżej, wiem, że możemy ustawić ten ukryty parametr:
alter system set "_optimizer_dsdir_usage_control"=0 scope=both;
Domyślna wartość tego ukrytego parametru to 126 w moim systemie 12.1.0.2. Znalazłem domyślne ustawienie z następującymi danymi:
select a.ksppinm name, b.ksppstvl value, b.ksppstdf deflt,
from
sys.x$ksppi a,
sys.x$ksppcv b
where a.indx = b.indx
and a.ksppinm like '\_%' escape '\'
and a.ksppinm like '%dsdir%'
order by name;
Ta wartość jest ważna w przypadku, gdy chcę ją przywrócić bez konieczności wyjmowania parametru z SPFILE, co wymagałoby przestoju.
Mogę teraz przystąpić do zmiany tego ukrytego parametru i ustawienia go na zero. Oto jak ta instrukcja SQL wygląda w Lighty po zmianie:
Wygląda na to, że „misja zakończona” w zatrzymaniu wykonywania tych dwóch instrukcji SQL.
Osoby korzystające z 12.1.0.2 na Oracle RAC mogą chcieć sprawdzić, czy te dwie instrukcje SQL same w sobie nie powodują problemów z wydajnością.
Wydaje się, że jest to jeden z tych przypadków, w których funkcja, która ma poprawić wydajność, faktycznie działa odwrotnie.
