|
|
|
Enterprise Manager
|
|||
|---|---|---|---|
|
#18+
Братья по разуму, выручайте (Enterprise Manager вижу сегодня первый раз). Есть. Oracle 19c Enterprise Manager 13c Что было: начал тормозить сервер БД (1.5 часа тормозил, Deadlock серврер не квалифицировал), отстрелили сессии с большими ожиданиями, всё поехало в штатном режиме. Вопрос: как используя Enterprise Manager можно понять, что случилось? Пока докопался до того, что сессии (выполняющие Select) ждали Select, как такое может быть, хинтов на Select-е нет, причем этот запрос работает много лет? Вообщем, помогите кто чем может :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2021, 14:35 |
|
||
|
Enterprise Manager
|
|||
|---|---|---|---|
|
#18+
Не поймите превратно, но в Вашем случае, судя по вводным, вероятно, лучшим решением станет привлечение специалиста по оптимизации/траблшутингу. Тема слишком обширная, чтобы действовать на основе форумных советов. Из известных мне специалистов в этой области могу уверенно рекомендовать Саяна Малакшинова, который иногда присутствует на этом форуме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2021, 14:47 |
|
||
|
Enterprise Manager
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, Хорошо. Мне для начала не понятно, как Select может заблокировать Select, скрипты которые блокируются вижу, планы запросов вижу - в планах либо Table Access Full, либо Index Range Scan, либо Index Full Scan, естественно на одну и туже табличку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2021, 14:53 |
|
||
|
Enterprise Manager
|
|||
|---|---|---|---|
|
#18+
PaulWist Мне для начала не понятно, как Select может заблокировать Select, скрипты которые блокируются вижу, планы запросов вижу - в планах либо Table Access Full, либо Index Range Scan, либо Index Full Scan, естественно на одну и туже табличку. Для начала не очевидно, что речь идет именно о блокировке, а не о конкуренции за ресурсы (от ввода-вывода до буферного кэша). Далее не очевидно, что select-ы не for update Если же речь именно о блокировке и именно простых селектов, то такой сценарий возможен при возникновении in-doubt распределенных транзакций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2021, 15:03 |
|
||
|
Enterprise Manager
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous Для начала не очевидно, что речь идет именно о блокировке, а не о конкуренции за ресурсы (от ввода-вывода до буферного кэша). Далее не очевидно, что select-ы не for update Если же речь именно о блокировке и именно простых селектов, то такой сценарий возможен при возникновении in-doubt распределенных транзакций. Отлично, спасибо. 1. Блокировки действительно нет!!! 2. select-ы не for update есть, НО они заканчиваются успешно. 3. Распределенные транзакции есть, как посмотреть в каком они были состоянии? 4. I/O тоже есть, но в исчезающе малых количествах, не влияет. 5. SGA не свопился, настроены алерты. На какие ещё буферы посмотреть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2021, 16:32 |
|
||
|
Enterprise Manager
|
|||
|---|---|---|---|
|
#18+
PaulWist 3. Распределенные транзакции есть, как посмотреть в каком они были состоянии? select * from dba_2pc_pending; PaulWist На какие ещё буферы посмотреть? select * from v$session_event; select * from v$session_wait; select * from v$session_wait_history; select * from v$session_wait_class; Но "смотреть" надо было в то время, когда всё было плохо. Если ситуация не воспроизводится, то можно начать с AWR-отчёта за период, когда было плохо. Или, возможно, нагляднее будет выполнить дифференциальный AWR за периоды "хорошо" и "плохо". Однако для корректной интерпретации этой информации требуется определённая квалификация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2021, 17:20 |
|
||
|
Enterprise Manager
|
|||
|---|---|---|---|
|
#18+
PaulWist используя Enterprise Manager можно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2021, 19:59 |
|
||
|
Enterprise Manager
|
|||
|---|---|---|---|
|
#18+
2 andrey_anonymous, ma1tus Спасибо мужики!!!! (все ваши посты в "кассу") Докладываю результат: 1. Проблема была в latch: cache buffers chains класса Concurrency. 2. Проблему вызвал простой запрос на табличку в >500К записей, типа: Код: plsql 1. Причина: указанный в хинте индекс, типа: Код: plsql 1. не пересекался по полям с предикатом запроса, в итоге получался Index Full Scan, косяк программёра. Ещё раз спасибо!!! PS для истории, может кому пригодиться https://iusoltsev.wordpress.com/2009/11/25/latch-cache-buffers-chains-cardinality-feedback/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2021, 11:24 |
|
||
|
|
start [/forum/topic.php?fid=52&msg=40120697&tid=1879673]: |
0ms |
get settings: |
16ms |
get forum list: |
6ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
39ms |
get topic data: |
3ms |
get forum data: |
1ms |
get page messages: |
154ms |
get tp. blocked users: |
0ms |
| others: | 396ms |
| total: | 617ms |
| 0 / 0 |
