Oto niektóre ze wspólnych zdarzeń oczekiwania na Oracle, które każdy powinien znać.
Wydarzenia oczekiwania
Możesz sprawdzić, która sesja wydarzenia na nią czeka, wykonując zapytanie
select event from V$session_wait where sid=&1
Próbuję wyjaśnić kilka typowych zdarzeń oczekiwania Oracle, ich przyczyny i rozwiązania
kolejkuj
Proces czeka na kolejkę wyroczni (blokadę, którą możesz zobaczyć w v$lock). Dzieje się tak często, gdy jeden użytkownik próbuje zaktualizować wiersz w tabeli, która jest aktualnie aktualizowana przez innego użytkownika. Blokery można znaleźć za pomocą następującego zapytania
select * from dba_waiters
Pin w pamięci podręcznej biblioteki
Proces chce przypiąć obiekt w pamięci w pamięci podręcznej biblioteki w celu sprawdzenia, zapewniając, że żaden inny proces nie może zaktualizować obiektu w tym samym czasie. Dzieje się tak, gdy kompilujesz lub analizujesz obiekt PL/SQL lub widok. Unikaj kompilowania obiektu PL/SQL lub widoku oracle przy wysokim czasie użytkowania, aby uniknąć tego zdarzenia oczekiwania
Blokada ładowania pamięci podręcznej biblioteki
Proces czeka na możliwość załadowania obiektu lub fragmentu obiektu do pamięci podręcznej biblioteki. (Tylko jeden proces może załadować obiekt lub fragment obiektu na raz.)
bez zatrzasku
Proces czeka na zatrzask wstrzymany przez inny proces. (To zdarzenie oczekiwania nie dotyczy procesów, które obracają się podczas oczekiwania na zatrzask; gdy proces się obraca, nie czeka). i pliki.
Zatrzaski to blokady zaprojektowane do utrzymywania przez bardzo krótkie okresy czasu, na przykład czas potrzebny do zmodyfikowania struktury danych w pamięci. Służą do ochrony niektórych struktur pamięci, takich jak pamięć podręczna bufora bloków bazy danych lub pamięć podręczna biblioteki w puli współdzielonej.
Zatrzaski Oracle są zazwyczaj wymagane wewnętrznie w trybie gotowości do czekania. Oznacza to, że jeśli zatrzask nie jest dostępny, sesja żądająca będzie spać przez krótki czas i ponowić operację później. Inne zatrzaski mogą być wymagane w trybie „natychmiastowym”, który jest podobny w koncepcji do WYBIERZ DO AKTUALIZACJI NO-WAIT, co oznacza, że proces będzie wykonywał coś innego, na przykład spróbuje złapać odpowiedni zatrzask rodzeństwa, który może być wolny, zamiast siedzieć i czekać, aż ten zatrzask stanie się dostępny. Ponieważ wiele żądań może jednocześnie czekać na zatrzask, niektóre procesy mogą czekać dłużej niż inne.
Zatrzaski przydzielane są raczej losowo, na podstawie szczęścia w losowaniu, jeśli wolisz. Każda sesja prosi o zatrzask zaraz po zwolnieniu, otrzyma go. Nie ma kolejki kelnerów, tylko tłum kelnerów nieustannie ponawiających próbę.
bufor zajęty czeka
Proces chce uzyskać dostęp do bloku danych, którego aktualnie nie ma w pamięci, ale inny proces już wysłał żądanie wejścia/wyjścia, aby wczytać blok do pamięci. (Proces czeka, aż drugi proces zakończy wprowadzanie bloku do pamięci.). Gorące bloki można znaleźć za pomocą widoku V$BH
Rozproszony odczyt pliku db
Proces wysłał żądanie wejścia/wyjścia, aby odczytać serię ciągłych bloków z pliku danych do bufora podręcznego i czeka na zakończenie operacji. Zwykle dzieje się tak podczas pełnego skanowania tabeli lub pełnego skanowania indeksu.
Powinniśmy sprawdzić, czy zapytanie powinno używać pełnego skanowania tabeli. Upewnij się, że statystyki optymalizatora Oracle są aktualne. Użyj przycinania partycji, aby zmniejszyć liczbę odwiedzanych bloków
Jeśli zapytanie, które przez jakiś czas działało poprawnie, nagle odmierza dużo czasu w zdarzeniu rozproszonego odczytu pliku db i nie nastąpiła zmiana kodu, możesz chcieć sprawdzić, czy jeden lub więcej indeksów zostało usuniętych lub stają się bezużyteczne.
odczyt sekwencyjny pliku db
Proces wysłał żądanie wejścia/wyjścia, aby odczytać jeden blok z pliku danych do bufora pamięci podręcznej i czeka na zakończenie operacji. Zwykle dzieje się to podczas wyszukiwania indeksu lub pobierania z tabeli Oracle według ROWID, gdy wymagany blok danych nie znajduje się już w pamięci. Nie daj się zwieść mylącej nazwie tego wydarzenia oczekiwania!
Powinniśmy sprawdzić, czy używane są właściwe indeksy. Nieprawidłowy indeks może spowodować złe działanie zapytania. Upewnij się, że statystyki optymalizatora są aktualne.
odczyt równoległy pliku db
Proces wysłał wiele żądań we/wy równolegle w celu odczytania bloków z plików danych do pamięci i czeka na zakończenie wszystkich żądań. Dokumentacja mówi, że to zdarzenie oczekiwania występuje tylko podczas odzyskiwania, ale w rzeczywistości występuje również podczas normalnej aktywności, gdy proces grupuje wiele jednoblokowych żądań we/wy i wysyła je równolegle. (Pomimo nazwy, nie zobaczysz tego zdarzenia oczekiwania podczas równoległego zapytania lub równoległego DML. W takich przypadkach zamiast tego występują zdarzenia oczekiwania z PX w nazwie.)
równoległy zapis pliku db
Proces, zazwyczaj DBWR, wysłał wiele żądań I/O równolegle, aby zapisać brudne bloki z bufora pamięci podręcznej na dysk i czeka na zakończenie wszystkich żądań.
bezpośredni odczyt ścieżki, bezpośredni zapis ścieżki
Proces wysłał asynchroniczne żądania we/wy, które pomijają pamięć podręczną bufora, i czeka na ich zakończenie. Te zdarzenia oczekiwania zazwyczaj obejmują segmenty sortowania.
Instrukcje SQL z funkcjami wymagającymi sortowania, takimi jak ORDER BY, GROUP BY, UNION, DISTINCT i ROLLUP, zapisują sortowanie do tymczasowego obszaru tabel, gdy rozmiar wejściowy jest większy niż obszar roboczy w PGA
Upewnij się, że statystyki optymalizatora są zgodne z danymi, a zapytanie korzysta z właściwej tabeli kierującej. Sprawdź, czy kolumny indeksu złożonego można zmienić tak, aby pasowały do klauzuli ORDER BY, aby całkowicie uniknąć sortowania.
Upewnij się, że ustawiono odpowiednią wartość PGA_AGGREGATE_TARGET. Jeśli to możliwe, użyj UNION ALL zamiast UNION.
Zatrzask wspólnej puli
Zatrzask puli współużytkowanej służy do ochrony operacji krytycznych podczas przydzielania i zwalniania pamięci w puli współużytkowanej. Spory o zatrzaski puli współużytkowanej i pamięci podręcznej biblioteki są spowodowane głównie intensywnym analizowaniem twardym. Twarda analiza dotyczy nowych kursorów i kursorów, które są przestarzałe i muszą zostać ponownie wykonane.
Koszt analizowania nowej instrukcji SQL jest drogi zarówno pod względem wymagań dotyczących procesora, jak i liczby przypadków, gdy pamięć podręczna biblioteki i pula współdzielona zatrzaski mogą wymagać nabycia i zwolnienia.
Wyeliminowanie dosłownego SQL jest również przydatne, aby uniknąć zatrzasku wspólnej puli
kontrolny odczyt sekwencyjny pliku
Proces czeka na odczytanie bloków z pliku kontrolnego. Zwykle tak się dzieje
- tworzenie kopii zapasowej plików kontrolnych
- udostępnianie informacji (pomiędzy instancjami) z pliku kontrolnego
- odczytywanie innych bloków z plików kontrolnych
- czytanie bloku nagłówka
Jeśli jest to poważne zdarzenie oczekujące, oznacza to konieczność zmiany lokalizacji pliku kontrolnego na szybszą lokalizację dysku
zapis równoległy do pliku kontrolnego
Proces wysłał wiele żądań we/wy równolegle, aby zapisać bloki do wszystkich plików kontrolnych i czeka na zakończenie wszystkich zapisów.
przestrzeń bufora dziennika
Proces czeka na udostępnienie miejsca w buforze dziennika (spacja staje się dostępna dopiero po zapisaniu bieżącej zawartości bufora dziennika na dysku przez LGWR). Dzieje się tak zwykle, gdy aplikacje generują ponowne wykonanie szybciej niż LGWR może to zapisać. na dysk.
Może się to również zdarzyć, jeśli wejście/wyjście na dysk, na którym znajdują się logi ponawiania, jest powolne
W bazie danych nie powinno być miejsca na bufor dziennika. Rozważ zwiększenie bufora dziennika, jeśli jest on mały, lub rozważ przeniesienie plików dziennika na szybsze dyski, takie jak dyski z paskiem.
Select event, total_waits, total_timeouts, time_waited, average_wait
from v$system_event
where event = 'log buffer space';
Select sid, event, seconds_in_wait, state
from v$session_wait
where event = 'log buffer space';
Select name, value
from v$sysstat
where name in ('redo log space requests');
Wartość pct_buff_alloc_retries powinna wynosić zero lub mniej niż 0,01 (<1%). Jeśli jest większy, rozważ zwiększenie bufora dziennika. Jeśli jest większy, rozważ przeniesienie plików dziennika na szybsze dyski, takie jak dyski z paskiem.
Select v1.value as redo_buff_alloc_retries, v2.value as redo_entries, trunc(v1.value/v2.value,4) as pct_buff_alloc_retries from v$sysstat v1, v$sysstat v2 where v1.name = 'redo buffer allocation retries' and v2.name = 'redo entries';
odczyt sekwencyjny pliku dziennika
Proces czeka na odczytanie bloków z ponownego logowania online do pamięci. Dzieje się tak przede wszystkim podczas uruchamiania instancji i gdy proces ARCH archiwizuje wypełnione dzienniki przeróbek online.
Zapis równoległy do pliku dziennika
Proces czeka na zapisanie bloków do wszystkich członków dziennika przeróbek online w jednej grupie. LGWR jest zazwyczaj jedynym procesem, który widzi to zdarzenie oczekiwania. Będzie czekać, aż wszystkie bloki zostaną zapisane do wszystkich członków.
Synchronizacja pliku dziennika
Proces czeka, aż LGWR zakończy opróżnianie bufora dziennika na dysk. Dzieje się tak, gdy użytkownik zatwierdzi transakcję. (Transakcja nie jest uważana za zatwierdzoną, dopóki wszystkie powtórzenia mające na celu odzyskanie transakcji nie zostaną pomyślnie zapisane na dysku).
Powolny proces LGWR może wprowadzić oczekiwanie na synchronizację pliku dziennika, co powoduje, że użytkownik doświadcza czasu oczekiwania podczas zatwierdzania lub wycofywania. Zdarzenia związane z równoległym zapisem pliku dziennika i oczekiwaniem na synchronizację pliku dziennika są ze sobą powiązane i muszą być obsługiwane jednocześnie.
Musimy spróbować przydzielić dzienniki ponownego wykonania do dysku o wysokiej wydajności (dysku półprzewodnikowego). Powinniśmy również spróbować zmniejszyć obciążenie LGWR, zmniejszając zobowiązania w aplikacjach.
Ręczna kopia zapasowa może również powodować stres w systemie, generując wiele czynności związanych z przeróbkami, więc unikaj tego w godzinach szczytu
Czasami LGWR brakuje zasobów procesora. Jeśli serwer jest bardzo zajęty, LGWR może również głodować procesora. Doprowadzi to do wolniejszej odpowiedzi ze strony LGWR, zwiększając czas oczekiwania na „synchronizację pliku dziennika”. W końcu te wywołania systemowe i wywołania I/O muszą wykorzystywać procesor. W takim przypadku „synchronizacja pliku dziennika” jest objawem drugorzędnym, a usunięcie głównej przyczyny wysokiego użycia procesora zmniejszy czas oczekiwania na „synchronizację pliku dziennika”.
Ze względu na problemy z brakiem pamięci LGWR można również stronicować. Może to również prowadzić do wolniejszej odpowiedzi ze strony LGWR.
cofnij rozszerzenie segmentu
Sesja czeka na rozszerzenie lub skrócenie segmentu cofania.
napisz kompletne oczekiwania
Sesja czeka na zapisanie na dysku żądanego bufora; bufor nie może być używany podczas zapisywania.
Zatrzask:łańcuchy buforów pamięci podręcznej
Zatrzaski łańcuchów buforów pamięci podręcznej służą do ochrony listy buforów w pamięci podręcznej bufora. Te zatrzaski są używane podczas wyszukiwania, dodawania lub usuwania bufora z bufora pamięci podręcznej.
Bloki w buforze bufora są umieszczane na połączonych listach (łańcuchach bufora bufora), które zwisają z tablicy mieszającej. Łańcuch mieszający, na którym umieszczany jest blok, jest oparty na DBA i KLASIE bloku. Każdy łańcuch haszujący jest chroniony przez pojedynczy zatrzask podrzędny. Procesy muszą uzyskać odpowiedni zatrzask, aby umożliwić im skanowanie łańcucha mieszającego w poszukiwaniu bufora, aby połączona lista nie zmieniała się pod nimi.
Rywalizacja o ten zatrzask zwykle oznacza, że istnieje blok, który jest w dużej rywalizacji (znany jako gorący blok).
Aby zidentyfikować mocno dostępny łańcuch buforów, a tym samym rywalizujący o blok, spójrz na statystyki zatrzasków dla zatrzasków łańcuchów buforów pamięci podręcznej przy użyciu widoku V$LATCH_CHILDREN. Jeśli istnieje określony łańcuch buforów pamięci podręcznej, który ma znacznie więcej pobrań, chybień i uśpienia w porównaniu z innymi zatrzaskami podrzędnymi, to jest to rywalizacja o zatrzask podrzędny.
Ten zatrzask ma adres pamięci, identyfikowany przez kolumnę ADDR.
SELECT addr, sleeps FROM v$latch_children c, v$latchname n WHERE n.name='cache buffers chains' and c.latch#=n.latch# and sleeps > 100 ORDER BY sleeps /
Użyj wartości w kolumnie ADDR połączonej z widokiem V$BH, aby zidentyfikować bloki chronione przez ten zatrzask. Na przykład, biorąc pod uwagę adres (V$LATCH_CHILDREN.ADDR) mocno rywalizującego zatrzasku, to wysyła zapytanie o numery plików i bloków:
SELECT file#, dbablk, class, state, TCH FROM X$BH WHERE HLADDR='address of latch';
X$BH.TCH to liczba dotknięć bufora. Wysoka wartość X$BH.TCH oznacza gorący blok.
Wiele bloków jest chronionych przez każdy zatrzask. Jednym z tych buforów będzie prawdopodobnie gorący blok. Każdy blok o wysokiej wartości TCH jest potencjalnym gorącym blokiem. Wykonaj to zapytanie kilka razy i zidentyfikuj blok, który konsekwentnie pojawia się na wyjściu.
Po zidentyfikowaniu gorącego bloku zapytaj DBA_EXTENTS, używając numeru pliku i numeru bloku, aby zidentyfikować segment.
Ważne informacje dotyczące zdarzenia oczekiwania
Widok v$session_wait wyświetla informacje o zdarzeniach oczekiwania, na które aktualnie czekają aktywne sesje. Poniżej znajduje się opis tego widoku, który zawiera kilka bardzo przydatnych kolumn, zwłaszcza odniesienia P1 i P2 do obiektów powiązanych ze zdarzeniami oczekiwania.
desc v$session_wait Name Null? Type --------------------------- -------- ------------ SID NUMBER SEQ# NUMBER EVENT VARCHAR2(64) P1TEXT VARCHAR2(64) P1 NUMBER P1RAW RAW(4) P2TEXT VARCHAR2(64) P2 NUMBER P2RAW RAW(4) P3TEXT VARCHAR2(64) P3 NUMBER P3RAW RAW(4) WAIT_CLASS_ID NUMBER WAIT_CLASS# NUMBER WAIT_CLASS VARCHAR2(64) WAIT_TIME NUMBER SECONDS_IN_WAIT NUMBER STATE VARCHAR2(19)
Korzystając z v $session_wait, można łatwo zinterpretować każdy parametr zdarzenia oczekiwania przy użyciu odpowiednich opisowych kolumn tekstu dla tego parametru. Ponadto dodano kolumny klasy wait, aby różne zdarzenia oczekiwania mogły być pogrupowane w powiązane obszary przetwarzania, takie jak sieć, aplikacja, bezczynność, współbieżność itp.
Ta kolumna została również dodana do tabeli v$session od 10g . Możesz więc po prostu użyć v$session, aby znaleźć wszystkie szczegóły
Każde zdarzenie oczekiwania zawiera inne parametry, które dostarczają dodatkowych informacji o zdarzeniu.
Jak znaleźć informacje o zdarzeniu oczekiwania i jego parametrze
The meaning of each wait event corresponds know by querying the V$EVENT_NAME p1, p2, p3 of col name format a25; col p1 format a10; col p2 format a10; col p3 format a10; SELECT NAME, PARAMETER1 P1, PARAMETER2 P2, PARAMETER3 P3 FROM V$EVENT_NAME WHERE NAME = '&event_name';
Powiedzmy na przykład, że wzięliśmy
Wartości wejściowe nazwa_zdarzenia:odczyt rozproszony pliku db
Oryginalna wartość 3:WHERE NAME =„&nazwa_zdarzenia A”
Nowa wartość 3:WHERE NAME =„odczyt rozproszony pliku db”
Nazwa P1 P2 P3
plik db rozproszony odczyt pliku # blok # bloków
plik nr:numer pliku danych
Blok nr:początkowy numer bloku
bloki:odczyt numeru bloku danych
Zobaczmy teraz, jak powyższe informacje mogą pomóc nam uchwycić różne rzeczy.
Załóżmy, że konkretna sesja czeka na zdarzenie oczekiwania zajętości bufora, obiekt bazy danych powodujący to zdarzenie oczekiwania można łatwo określić:
select username, event, p1, p2 from v$session_wait where sid = 4563;
Wynik tego zapytania dla konkretnej sesji o identyfikatorze SID 4563 może wyglądać tak:
USERNAME EVENT SID P1 P2 ---------- ----------------- --- -- --- APPS buffer busy waits 4563 11 545
Kolumny P1 i P2 pozwalają administratorowi danych na określenie numerów plików i bloków, które spowodowały to zdarzenie oczekiwania. Poniższe zapytanie pobiera nazwę obiektu, który jest właścicielem bloku danych 155, wartość P2 powyżej:
SQL> select segment_name,segment_type from dba_extents where file_id = 11 and 45 between block_id and block_id + blocks – 1;
Możliwość analizowania i korygowania zdarzeń oczekiwania Oracle Database ma kluczowe znaczenie w każdym projekcie dostrajania. Większość czynności w bazie danych polega na odczytywaniu danych, więc ten rodzaj dostrajania może mieć ogromny, pozytywny wpływ na wydajność.
Uwaga:podczas wykonywania analizy oczekiwania należy pamiętać, że wszystkie bazy danych Oracle mają zdarzenia oczekiwania, a obecność oczekiwania nie zawsze wskazuje na problem. W rzeczywistości wszystkie dobrze dostrojone bazy danych mają pewne wąskie gardło.
możemy również użyć zdarzenia 10046 do śledzenia zdarzenia oczekiwania sesji
Też czyta
Dokumentacja Oracle
v$active_session_history
Wyjaśnij plan w Oracle
