Ето някои от обичайните събития за изчакване на Oracle, които всеки трябва да знае.
Събития за изчакване
Можете да намерите коя сесия на събитието го чака, като следвате заявка
select event from V$session_wait where sid=&1
Опитвам се да обясня няколко често срещани събития на изчакване на Oracle, има причини и решения
на опашка
Процесът чака на опашка на оракул (заключване, което можете да видите във v$lock). Това обикновено се случва, когато един потребител се опитва да актуализира ред в таблица, която в момента се актуализира от друг потребител. Блокерите могат да бъдат намерени чрез следната заявка
select * from dba_waiters
щифт за кеш на библиотеката
Процесът иска да закачи обект в паметта в кеша на библиотеката за проверка, като гарантира, че други процеси не могат да актуализират обекта по едно и също време. Това се случва, когато компилирате или анализирате PL/SQL обект или изглед. Избягвайте компилирането на PL/SQL обект или изглед на оракул при голямо време на използване, за да избегнете това събитие на изчакване
заключване на зареждането на кеша на библиотеката
Процесът чака възможността да зареди обект или част от обект в кеша на библиотеката. (Само един процес може да зареди обект или част от обект наведнъж.)
без закопчаване
Процесът чака заключване, задържано от друг процес. (Това събитие за изчакване не се прилага за процеси, които се въртят, докато чакат заключване; когато процесът се върти, той не чака.). Решетките са леки устройства за сериализиране, използвани за координиране на многопотребителския достъп до споделени структури от данни, обекти, и файлове.
Ключовете са ключалки, предназначени да се задържат за изключително кратки периоди от време, например времето, необходимо за промяна на структура от данни в паметта. Те се използват за защита на определени структури на паметта, като например буферния кеш на блока на базата данни или кеша на библиотеката в споделения пул.
Резетата на Oracle обикновено се изискват вътрешно в режим „готови да чакат“. Това означава, че ако ключалката не е налична, заявещата сесия ще заспи за кратък период от време и ще опита отново операцията по-късно. Други ключалки могат да бъдат поискани в „незабавен“ режим, който е подобен по концепция на SELECT FOR UPDATE NO-WAIT, което означава, че процесът ще направи нещо друго, като например опит за хващане на еквивалентно закопчаване на брат и сестра, което може да е безплатно, вместо да седнете и да чакате това резе да стане достъпно. Тъй като много заявки може да чакат за заключване по едно и също време, може да видите някои процеси да чакат по-дълго от други.
Ключалките се задават доста произволно, въз основа на късмета на тегленето, ако щете. Която сесия поиска фиксатор веднага след освобождаването, ще го получи. Няма опашка от затворени сервитьори, а тълпа сервитьори, които непрекъснато се опитват.
буферът е зает с изчакване
Процесът иска да получи достъп до блок от данни, който в момента не е в паметта, но друг процес вече е издал I/O заявка за четене на блока в паметта. (Процесът чака другият процес да завърши пренасянето на блока в паметта.). Горещите блокове могат да бъдат намерени с помощта на изглед V$BH
db файл разпръснато четене
Процесът е издал I/O заявка за четене на поредица от последователни блокове от файл с данни в кеша на буфера и изчаква операцията да завърши. Това обикновено се случва по време на пълно сканиране на таблицата или пълно сканиране на индекс.
Трябва да проверим дали заявката трябва да използва пълно сканиране на таблицата. Уверете се, че статистиката на оптимизатора на Oracle е актуална. Използвайте подрязване на дялове, за да намалите броя на посетените блокове
Ако заявка, която работи добре известно време, внезапно отчита много време в събитието за четене на разпръснато четене на db файл и не е имало промяна на кода, може да искате да проверите дали един или повече индекси са изпуснати или стават неизползваеми.
последователно четене на db файл
Процесът е издал I/O заявка за четене на един блок от файл с данни в буферния кеш и чака операцията да завърши. Това обикновено се случва по време на търсене на индекс или извличане от таблица на оракул от ROWID, когато необходимият блок данни вече не е в паметта. Не се подвеждайте от объркващото име на това чакащо събитие!
Трябва да проверим дали се използват правилните индекси. Грешен индекс може да доведе до лошо представяне на заявката. Уверете се, че статистическите данни на оптимизатора са актуални.
паралелно четене на db файл
Процесът е издал множество I/O заявки паралелно за четене на блокове от файлове с данни в паметта и изчаква всички заявки да завършат. В документацията се казва, че това изчакване се случва само по време на възстановяване, но всъщност се случва и по време на редовна дейност, когато процес събира много единични блокови I/O заявки заедно и ги издава паралелно. (Въпреки името, няма да видите това изчакване по време на паралелна заявка или паралелен DML. В тези случаи вместо това се случват изчакващи събития с PX в имената.)
паралелно записване на db файл
Процесът, обикновено DBWR, е издал множество I/O заявки паралелно, за да запише мръсни блокове от кеша на буфера на диск и чака всички заявки да завършат.
директен път за четене, директен път за запис
Процесът е издал асинхронни I/O заявки, които заобикалят кеша на буфера, и чака да завършат. Тези чакащи събития обикновено включват сегменти за сортиране.
SQL изрази с функции, които изискват сортиране, като ORDER BY, GROUP BY, UNION, DISTINCT и ROLLUP, сортирането при запис се изпълнява към временното пространство за таблици, когато размерът на входа е по-голям от работната площ в PGA
Уверете се, че статистическите данни на оптимизатора са актуални и заявката използва правилната таблица за управление. Проверете дали колоните на съставния индекс могат да бъдат пренаредени, за да съответстват на клаузата ORDER BY, за да избегнете изцяло сортирането.
Уверете се, че е зададена подходяща стойност PGA_AGGREGATE_TARGET. Ако е възможно, използвайте UNION ALL вместо UNION.
Заключване на споделен басейн
Резето на споделения пул се използва за защита на критични операции при разпределяне и освобождаване на памет в споделения пул. Споровете за ключалките на кеша на споделения пул и библиотеката се дължат главно на интензивен твърд синтактичен анализ. Твърд синтактичен анализ се прилага за нови курсори и курсори, които са остарели и трябва да бъдат изпълнени повторно
Цената за синтактичен анализ на нов SQL израз е скъпа както по отношение на изискванията на процесора, така и по отношение на броя пъти кеша на библиотеката и споделения пул ключалките може да се наложи да бъдат придобити и освободени.
Елиминирането на литералния SQL също е полезно, за да се избегне блокирането на споделения пул
контролен файл последователно четене
Процесът чака блоковете да бъдат прочетени от контролен файл. Това се случва обикновено
- правене на резервно копие на контролните файлове
- споделяне на информация (между екземпляри) от контролния файл
- четене на други блокове от контролните файлове
- четене на заглавния блок
Ако това е основно чакащо събитие, това означава, че местоположението на контролния файл трябва да се промени на по-бързо местоположение на диска
паралелно записване на контролния файл
Процесът е издал множество I/O заявки паралелно за записване на блокове във всички контролни файлове и изчаква всички записвания да завършат.
пространство в буфера на журнала
Процесът изчаква свободното място в буфера на дневника (Пространството става достъпно само след като LGWR запише текущото съдържание на буфера на дневника на диск.) Това обикновено се случва, когато приложенията генерират повторно изпълнение по-бързо, отколкото LGWR може да го запише на диск.
Това също може да се случи, ако I/O към диска, където се намират регистрационните файлове за повторно изпълнение, е бавен
В базата данни не трябва да има изчакване на буфера на регистрационните файлове като такова. Помислете за увеличаване на буфера на регистрационните файлове, ако е малък, или помислете за преместване на регистрационни файлове на по-бързи дискове, като например дискове с ленти.
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');
pct_buff_alloc_retries трябва да е нула или по-малко от 0,01 (<1%). Ако е по-голямо, помислете за увеличаване на буфера на журнала. Ако е по-голямо, помислете за преместване на регистрационните файлове на по-бързи дискове, като например дискове с ленти.
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';
последователно четене на регистрационния файл
Процесът чака блоковете да бъдат прочетени от онлайн лог за повторно изпълнение в паметта. Това се случва предимно при стартиране на екземпляра и когато архивите на процеса ARCH попълват онлайн регистрационни файлове за повторно изпълнение.
паралелно записване на лог файл
Процесът чака блоковете да бъдат записани на всички членове на онлайн дневника за повторно изпълнение в една група. LGWR обикновено е единственият процес, който вижда това събитие за изчакване. Ще изчака, докато всички блокове бъдат записани на всички членове.
синхронизиране на регистрационни файлове
Процесът изчаква LGWR да завърши изчистването на буфера на журнала на диск. Това се случва, когато потребителят извърши транзакция. (Транзакция не се счита за извършена, докато цялото повторение за възстановяване на транзакцията не бъде успешно записано на диска.)
Бавен процес на LGWR може да въведе изчаквания за синхронизиране на регистрационни файлове, което кара потребителя да изпита време за изчакване по време на комит или връщане назад. Събитията за паралелно записване на регистрационния файл и изчакване на синхронизиране на регистрационния файл са взаимосвързани и трябва да се обработват едновременно.
Трябва да се опитаме да разпределим регистрационните файлове за повторение на високопроизводителен диск (Solid state disk). Също така трябва да се опитаме да намалим натоварването на LGWR, като намалим комитациите в приложенията.
Частта за ръчно горещо архивиране също може да внесе стрес в системата, като генерира много повторени неща, така че избягвайте това по време на пиково време
Понякога LGWR изпитва глад за ресурс на процесора. Ако сървърът е много натоварен, LGWR също може да гладува за CPU. Това ще доведе до по-бавен отговор от LGWR, увеличавайки изчакването на „синхронизиране на регистрационни файлове“. В крайна сметка тези системни и I/O повиквания трябва да използват CPU. В този случай „синхронизирането на регистрационните файлове“ е вторичен симптом и разрешаването на основната причина за високото използване на процесора ще намали изчакването на „синхронизиране на регистрационни файлове“.
Поради проблеми с гладуването на паметта, LGWR също може да бъде изведен. Това може да доведе и до по-бавен отговор от LGWR.
разширение за отмяна на сегмент
Сесията чака сегмент за отмяна да бъде удължен или свиен.
напишете завършени изчаквания
Сесията чака исканият буфер да бъде записан на диск; буферът не може да се използва, докато се записва.
Заключване:вериги на кеш буфер
Резетата на веригите на кеш буферите се използват за защита на списък с буфери в кеша на буфера. Тези ключалки се използват при търсене, добавяне или премахване на буфер от кеша на буфера.
Блоковете в кеша на буфера се поставят в свързани списъци (вериги на кеш буфер), които висят на хеш таблица. Хеш веригата, върху която е поставен блок, се основава на DBA и CLASS на блока. Всяка хеш верига е защитена от едно дете ключалка. Процесите трябва да получат съответното ключалка, за да им позволят да сканират хеш верига за буфер, така че свързаният списък да не се променя под тях.
Споровете относно това ключалка обикновено означават, че има блок, който е в голяма борба (известен като горещ блок).
За да идентифицирате буферната верига с голям достъп, а оттам и блока, който се бори, вижте статистическите данни за заключване за ключалките на вериги на кеш буфери, като използвате изгледа V$LATCH_CHILDREN. Ако има конкретен кеш буфер вериги за заключване на деца, който има много повече GETS, MISSES и SLEPS в сравнение с другите дъщерни ключалки, тогава това е оспорваното заключване за деца.
Това ключалка има адрес на паметта, идентифициран от колоната 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 /
Използвайте стойността в колоната ADDR, свързана с изгледа V$BH, за да идентифицирате блоковете, защитени от това ключалка. Например, като се има предвид адреса (V$LATCH_CHILDREN.ADDR) на силно оспорвана ключалка, това прави заявка за номера на файла и блока:
SELECT file#, dbablk, class, state, TCH FROM X$BH WHERE HLADDR='address of latch';
X$BH.TCH е брой докосвания за буфера. Висока стойност за X$BH.TCH показва горещ блок.
Много блокове са защитени от всяко резе. Един от тези буфери вероятно ще бъде горещият блок. Всеки блок с висока стойност на TCH е потенциален горещ блок. Изпълнете тази заявка няколко пъти и идентифицирайте блока, който постоянно се появява в изхода.
След като идентифицирате горещия блок, заявете DBA_EXTENTS, като използвате номера на файла и номера на блока, за да идентифицирате сегмента.
Важна информация за събитие за изчакване
Изгледът v$session_wait показва информация за изчакващи събития, за които в момента се изчакват активни сесии. Следва описанието на този изглед и съдържа някои много полезни колони, особено препратките P1 и P2 към обектите, свързани със събитията на чакане.
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)
С помощта на v$session_wait е лесно да се интерпретира всеки параметър на събитието на чакане, като се използват съответните описателни текстови колони за този параметър. Освен това бяха добавени колони за клас на чакане, така че различни събития на чакане да могат да бъдат групирани в свързани области на обработка, като мрежа, приложение, празен ход, едновременност и т.н.
Тези колона също беше добавена към таблицата v$session от 10g нататък . Така че можете просто да използвате v$session, за да намерите всички подробности
Всяко събитие на чакане съдържа други параметри, които предоставят допълнителна информация за събитието.
Как да намерите информацията за събитието на чакане и неговия параметър
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';
Да кажем например, че взехме
Входните стойности на event_name:db file scattered read
Оригинална стойност на 3:WHERE NAME =‘&event_name A’
Новата стойност 3:WHERE NAME =‘db file scattered read’
Името P1 P2 P3
db файл разпръснат прочетен файл # блок # блокове
файл #:номер на файл с данни
Блок #:номер на начален блок
блокове:за четене на номера на блока с данни
Сега нека видим как горната информация може да ни помогне да заснема различни неща
Да предположим , че конкретна сесия изчаква събитие за изчакване на зает буфер, обектът на базата данни, причиняващ това събитие на чакане, може лесно да бъде определен:
select username, event, p1, p2 from v$session_wait where sid = 4563;
Резултатът от тази заявка за конкретна сесия със SID 4563 може да изглежда така:
USERNAME EVENT SID P1 P2 ---------- ----------------- --- -- --- APPS buffer busy waits 4563 11 545
Колони P1 и P2 позволяват на DBA да определи номерата на файлове и блокове, които са причинили това чакане. Заявката по-долу извлича името на обекта, който притежава блок данни 155, стойността на P2 по-горе:
SQL> select segment_name,segment_type from dba_extents where file_id = 11 and 45 between block_id and block_id + blocks – 1;
Възможността за анализиране и коригиране на изчакващи събития в Oracle Database е от решаващо значение за всеки проект за настройка. По-голямата част от дейността в база данни включва четене на данни, така че този тип настройка може да има огромно, положително въздействие върху производителността.
Забележка:Когато правите анализ на изчакване, е важно да запомните, че всички бази данни на Oracle изпитват изчакващи събития и че наличието на изчаквания не винаги показва проблем. Всъщност всички добре настроени бази данни имат известно затруднение.
можем да използваме събитие 10046, за да проследим и събитието на чакане на сесията
Също чете
Документация на Oracle
v$active_session_history
Обяснение на плана в Oracle
