что можно выудить из latch free в v$session_wait? / Oracle

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Oracle [игнор отключен] [закрыт для гостей] / что можно выудить из latch free в v$session_wait?

51 сообщений из 51, показаны все 3 страниц

все

что можно выудить из latch free в v$session_wait?

#35469713

latch free

Гость

пытаюсь разобраться, почему висит программа на одном запросе около минуты, хотя если его выполняю в sqlplus - выполняется миллисекунды и план нормальный - без фулл скэнов. Смотрю v$session_wait. вот типичный пример:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

 SID   SEQ#   EVENT#  EVENT                    P1TEXT             P1  P2TEXT        P2  P3TEXT    P3   WAIT_TIME   WAIT_COUNT  
-------------------------------------------------------------------------------------------------------------------------------
  284        1        117   db file scattered read   file#                7   block#     212291   blocks     16             0              1   
  284        2        117   db file scattered read   file#                7   block#     212275   blocks     16             0              1   
  284        3        291   latch free               address     2158731500   number        127   tries       0           243              1   
  284        4        117   db file scattered read   file#                8   block#     200365   blocks     16             0              1   
  284        5        117   db file scattered read   file#                8   block#     200349   blocks     16             0              1   
  284        6        117   db file scattered read   file#                8   block#     200493   blocks     16             0              1   
  284        7        117   db file scattered read   file#                8   block#     200477   blocks     16             0              1   
  284        8        117   db file scattered read   file#                8   block#     200461   blocks     16             0              1   
  284        9        117   db file scattered read   file#                8   block#     200445   blocks     16             0              1   
  284       10        117   db file scattered read   file#                8   block#     200429   blocks     16             0              1

ну db file scattered read - вроде ясно, читает эту несчастную таблицу (около млн. записей), с 120 экстентами рассеянную по нескольким файлам. Нехорошо, но не смертельно. А какую информацию можно вытащить из latch free? Могут они быть источником зла?

...

Рейтинг:

0 / 0

04.08.2008, 19:09

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35469725

jan2ary

Участник

Откуда: Киев

Сообщения: 1 766

Рейтинг: 0 / 0

Отсюда много не увидишь: латчи - они такие, что без них никуда. Другое дело, как часто приходится их перезапрашивать и переперезапрашивать и пере...
Хорошо бы трассировку сделать, или посмотреть v$session_event по сессии.

...

Рейтинг:

0 / 0

04.08.2008, 19:18

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35469742

latch free

Гость

jan2ary
Хорошо бы трассировку сделать, или посмотреть v$session_event по сессии.
сорри, это конечно был v$session_wait_history, не v$session_wait... Вот привожу v$session_event - не очень хорошо я понимаю, как это нужно расшифровывать...

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.

Select EVENT, TOTAL_WAITS, TOTAL_TIMEOUTS, TIME_WAITED from V$SESSION_event
where sid= 284  order by TIME_WAITED desc
----------------------------------------------------------------------------------------------------

EVENT                            TOTAL_WAITS   TOTAL_TIMEOUTS   TIME_WAITED  
-----------------------------------------------------------------------------
SQL*Net message from client          13006885                  0       276538332   
db file scattered read                1965249                  0          803054   
log file sync                         1134547                297          579909   
read by other session                   21072               3267          476654   
events in waitclass Other               11075                  0          256810   
latch: cache buffers chains              3149                  0           83615   
db file sequential read                285798                  0           30239   
SQL*Net more data to client           1655885                  0           27120   
SQL*Net message to client            13006886                  0           21506   
latch: library cache                      396                  0            1318   
log file switch completion                106                  0             446   
enq: TX - index contention                 41                  0             367   
buffer busy waits                        1070                  0             299   
latch: In memory undo latch               217                  0             134   
cursor: pin S wait on X                    75                 74              89   
latch: shared pool                          7                  0              72   
enq: TX - row lock contention              21                  0              41   
db file parallel read                     214                  0               9   
latch: library cache lock                  12                  0               4   
latch: row cache objects                    7                  0               1   
latch: redo copy                            1                  0               0   
latch: library cache pin                    1                  0               0

...

Рейтинг:

0 / 0

04.08.2008, 19:34

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35469802

jan2ary

Участник

Откуда: Киев

Сообщения: 1 766

Рейтинг: 0 / 0

Судя по топовому ожиданию и его отрыву от ближайших преследователей - где-то Ваша программа слишком долго думает (над возвращенными результатами, либо о чем-то своем). В таком случае база тут ни при чем, весь затык в приложении.

...

Рейтинг:

0 / 0

04.08.2008, 20:26

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35469811

$RA\/EN$

RA\/EN

Участник

Сообщения: 2 941

Рейтинг: 0 / 0

По сравнению с количеством roundtrips с клиентом (13 миллионов) все остальное - ерунда.
"Нехорошие" ожидания из-за того, что эту табличку слишном интенсивно читают несколько сессий, отсюда "read by other session" - сессия хочет блок, но ждет, пока его читает другая сессия.
Хотя, конечно, в среднем 0.2 секунды многовато на один RbOS, но при большом объеме LIO вполне может быть.

А возвращаясь к начальному вопросу (плчему висит программа) - это у программы и спрашивайте, судя по всему она очень уж много резурсов тратит на обработку каждой строки получаемого запроса. Вполне возможно, что она умеет брать только строчка-за-строчкой, а не пакетно, что вполне объясняет 0.2 секунды на сетевое взаимодействие + время обработки одной строки.

...

Рейтинг:

0 / 0

04.08.2008, 20:31

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470337

sql+

Гость

latch freeпытаюсь разобраться, почему висит программа на одном запросе около минуты, хотя если его выполняю в sqlplus - выполняется миллисекунды и план нормальный - без фулл скэнов. Смотрю v$session_wait. вот типичный пример:

Код: plaintext

1.
2.

 SID   SEQ#   EVENT#  EVENT                    P1TEXT             P1  P2TEXT        P2  P3TEXT    P3   WAIT_TIME   WAIT_COUNT  
-------------------------------------------------------------------------------------------------------------------------------
  284        3        291   latch free               address     2158731500   number        127   tries       0

А какую информацию можно вытащить из latch free

Наименование можно выцепить. И посмотреть на металинке инфу насчёт него.

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

SQL> variable v_latch number
exec :v_latch:= 127 ;
select *
from v$latchname
where latch# = :v_latch;
SQL> 
PL/SQL procedure successfully completed.

SQL>    2      3   
    LATCH# NAME                                                     HASH
---------- -------------------------------------------------- ----------
        127  simulator lru latch                                  405505728

...

Рейтинг:

0 / 0

05.08.2008, 09:55

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470365

StarBlade

Участник

Откуда: Хорошо хоть не из МСК

Сообщения: 386

Рейтинг: 0 / 0

Латчи - лишь симптом. Причина похоже не в базе а в ожидании реакции клиента.

...

Рейтинг:

0 / 0

05.08.2008, 10:06

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470379

sql+

Гость

StarBladeЛатчи - лишь симптом. Причина похоже не в базе а в ожидании реакции клиента.

Если ты не в курсе, ожидания типа SQL*Net message from client как правило в расчёт не берутся.
Рекация клиента тут непричём.

...

Рейтинг:

0 / 0

05.08.2008, 10:08

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470409

StarBlade

Участник

Откуда: Хорошо хоть не из МСК

Сообщения: 386

Рейтинг: 0 / 0

sql+
Если ты не в курсе, ожидания типа SQL*Net message from client как правило в расчёт не берутся.
Рекация клиента тут непричём.

В расчет чего? В плюсе мгновенно - а в приложении (судя по всему) медленно. Ну и на рабочей базе (если это действительно рабочая) все не так однозначно.

...

Рейтинг:

0 / 0

05.08.2008, 10:20

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470424

wurdu

Участник

Откуда: Владивосток

Сообщения: 4 443

Рейтинг: 0 / 0

sql+Если ты не в курсе, ожидания типа SQL*Net message from client как правило в расчёт не берутся.Я бы не обобщал. SQL*Net Message from client - Idle Time or your Problem?

...

Рейтинг:

0 / 0

05.08.2008, 10:23

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470439

$RA\/EN$

RA\/EN

Участник

Сообщения: 2 941

Рейтинг: 0 / 0

sql+ StarBladeЛатчи - лишь симптом. Причина похоже не в базе а в ожидании реакции клиента.

Если ты не в курсе, ожидания типа SQL*Net message from client как правило в расчёт не берутся.
Рекация клиента тут непричём.
Вы очень категоричны
Вы знаете, что "как правило в расчет не берутся", но можете объяснить, что это за "правило", позволяющее игнорировать ожидание, возникающее в 10 раз чаще любого другого?

...

Рейтинг:

0 / 0

05.08.2008, 10:27

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470483

sql+

Гость

Я бы был категоричен если бы это была исключительно моя точка зрения. Однако в любом отчёте statspack вы увидете такую фразу:ordered by wait time desc, waits desc ( idle events last )

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.

Wait Events for DB:
> ordered by wait time desc, waits desc (idle events last)
Top  5  Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read                         17 , 050 , 605       276 , 209      37 . 06 
CPU time                                                       226 , 484      30 . 39 
db file scattered read                           3 , 241 , 322        61 , 014       8 . 19 
direct path read (lob)                           3 , 419 , 503        36 , 753       4 . 93 
io done                                          1 , 269 , 406        21 , 155       2 . 84 
          -------------------------------------------------------------
Wait Events for DB: WF  Instance: wf  Snaps:  229  - 238 
-> s  - second
-> cs - centisecond -     100th of a second
-> ms - millisecond -    1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)

                                                                   Avg
                                                     Total Wait   wait    Waits
Event                               Waits   Timeouts   Time (s)   (ms)     /txn
---------------------------- ------------ ---------- ---------- ------ --------
db file sequential read         17 , 050 , 605            0      276 , 209       16       19 . 0 
db file scattered read           3 , 241 , 322            0       61 , 014       19        3 . 6 
direct path read (lob)           3 , 419 , 503            0       36 , 753       11        3 . 8 
io done                          1 , 269 , 406      404 , 412       21 , 155       17        1 . 4 
buffer busy waits                  967 , 353          473       16 , 308       17        1 . 1

В самом конце

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.

                                                                   Avg
                                                     Total Wait   wait    Waits
Event                               Waits   Timeouts   Time (s)   (ms)     /txn
---------------------------- ------------ ---------- ---------- ------ --------
SQL*Net message from client     17 , 265 , 432            0  ##########     813       19 . 3 
jobq slave wait                  1 , 110 , 737      920 , 582    2 , 899 , 755     2611        1 . 2 
wakeup time manager                 47 , 006       46 , 523    1 , 114 , 978    23720        0 . 1 
i/o slave wait                   1 , 731 , 859        3 , 428        5 , 507        3        1 . 9 
SQL*Net more data from clien     2 , 753 , 313            0        2 , 627        1        3 . 1 
SQL*Net message to client       17 , 265 , 391            0           23        0       19 . 3

Поэтому как правило, данное ожидание не должно браться в расчёт.

По той информации, которую выдал автор темы, нет никаких оснований утверждать иное.

...

Рейтинг:

0 / 0

05.08.2008, 10:39

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470486

sql+

Гость

RA\/EN sql+ StarBladeЛатчи - лишь симптом. Причина похоже не в базе а в ожидании реакции клиента.

Если ты не в курсе, ожидания типа SQL*Net message from client как правило в расчёт не берутся.
Рекация клиента тут непричём.
Вы очень категоричны
Вы знаете, что "как правило в расчет не берутся", но можете объяснить, что это за "правило", позволяющее игнорировать ожидание, возникающее в 10 раз чаще любого другого?

А объяснить проще простого - клиент ничего не делает в приложении- пъёт чай, курит, пошёл пописать, вызвали к начальсту, смотрит почту, переписывается в аське - а приложение загружено - но ничего не делает, а событие SQL*Net message from client тем временем увеличивается.

...

Рейтинг:

0 / 0

05.08.2008, 10:42

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470552

$RA\/EN$

RA\/EN

Участник

Сообщения: 2 941

Рейтинг: 0 / 0

sql+Я бы был категоричен если бы это была исключительно моя точка зрения. Однако в любом отчёте statspack вы увидете такую фразу:ordered by wait time desc, waits desc ( idle events last )
...

Поэтому как правило, данное ожидание не должно браться в расчёт.

По той информации, которую выдал автор темы, нет никаких оснований утверждать иное.
latch freeпочему висит программа на одном запросе около минуты, хотя если его выполняю в sqlplus - выполняется миллисекунды
Не, не оно?
Соотношение TOTAL WAITS у SQL*Net message from client и db file scattered read тоже ни о чем не говорит?
Рассмотрение каждого отдельного ожидания в отрыве от остальных - что-то вроде утверждения "90-60-90 - идеальная девушка!", не обращая внимание на то, что это "рост-возраст-вес"
P.S. Я не утверждаю, что возможная проблема в клиенте - единственно верный и окончательный диагноз (хотя по симптомам - именно оно), но отвергать версию ("Рекация клиента тут непричём.") с аргументацией в виде сортировки статспаковских отчетов - юношеский максимализм. Еще раз подумайте над КОЛИЧЕСТВОМ ожиданий SQL*Net message from client.

...

Рейтинг:

0 / 0

05.08.2008, 11:05

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470557

Timm

Участник

Откуда: Moscow, Ё-burg

Сообщения: 3 678

Рейтинг: 0 / 0

sql+А объяснить проще простого - клиент ничего не делает в приложении- пъёт чай, курит, пошёл пописать, вызвали к начальсту, смотрит почту, переписывается в аське - а приложение загружено - но ничего не делает, а событие SQL*Net message from client тем временем увеличивается.
... либо лопатит кучу данных _построчно_ с огромным количеством roundtrip'ов (что характерно для топикстартера).
Оракл ведь считает что они idle потому что для него они действительно idle, но не для клиента - они входят в респонс тайм приложения точно так же как и другие ивенты.

...

Рейтинг:

0 / 0

05.08.2008, 11:07

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470563

latch free

Гость

sql+
А объяснить проще простого - клиент ничего не делает в приложении- пъёт чай, курит, пошёл пописать, вызвали к начальсту, смотрит почту, переписывается в аське - а приложение загружено - но ничего не делает, а событие SQL*Net message from client тем временем увеличивается.
Да, всё так :-). Программа (это фоновый процесс) и ORACLE не находятся в состоянии непрерывного обмена данными, но остаются connected. Т.е. в цикле есть период активности, потом программа засыпает на 10 секунд, просыпается и снова что-то делает...

единственно, что не очень понятно - что количество SQL*Net message from client и SQL*Net message to client одинаково (хотя время существенно различается). SQL*Net message to client чего ждет?

...

Рейтинг:

0 / 0

05.08.2008, 11:09

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470589

latch free

Гость

ступил, сорри... :-/ Всё понятно: при N сеансах работы есть N*M SQL*Net message to client и N*M SQL*Net message from client (ну может на один меньше :-). Из SQL*Net message from client олько один - последний - тянется до начала следующего сеанса, а среди SQL*Net message to client таких длинных нет вообще

...

Рейтинг:

0 / 0

05.08.2008, 11:19

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470599

sql+

Гость

RA\/EN
"Нехорошие" ожидания из-за того, что эту табличку слишном интенсивно читают несколько сессий, отсюда "read by other session" - сессия хочет блок, но ждет, пока его читает другая сессия.

Подозреваю что ты неправильно понимаешь смысл данного события. Связи между "эту табличку слишном интенсивно читают несколько сессий" и данным ожиданием нет никакой.

...

Рейтинг:

0 / 0

05.08.2008, 11:24

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470690

latch free

Гость

...

Рейтинг:

0 / 0

05.08.2008, 11:50

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470696

sql+

Гость

Предлагаю сначала послушать RAVEN-а, как он это понимает.

...

Рейтинг:

0 / 0

05.08.2008, 11:51

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470712

Timm

Участник

Откуда: Moscow, Ё-burg

Сообщения: 3 678

Рейтинг: 0 / 0

...

Рейтинг:

0 / 0

05.08.2008, 12:00

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470733

sql+

Гость

Timm sql+ RA\/EN
"Нехорошие" ожидания из-за того, что эту табличку слишном интенсивно читают несколько сессий, отсюда "read by other session" - сессия хочет блок, но ждет, пока его читает другая сессия.

Подозреваю что ты неправильно понимаешь смысл данного события. Связи между "эту табличку слишном интенсивно читают несколько сессий" и данным ожиданием нет никакой.
Да ну? а по-моему, такая связь прослеживается очень часто. Две сессии, читающие данные таблички, желают видеть в кэше один и тот же блок. одна читает, другая ждет - очень распространенная ситуевина.

Так как ты это описал - может. В том как сформулировал RAVEN мне показалось не совсем.
Я надеюсь что он всё таки появится и уточнит что он имел ввиду.

...

Рейтинг:

0 / 0

05.08.2008, 12:09

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470833

$RA\/EN$

RA\/EN

Участник

Сообщения: 2 941

Рейтинг: 0 / 0

sql+ RA\/EN
"Нехорошие" ожидания из-за того, что эту табличку слишном интенсивно читают несколько сессий, отсюда "read by other session" - сессия хочет блок, но ждет, пока его читает другая сессия.

Подозреваю что ты неправильно понимаешь смысл данного события. Связи между "эту табличку слишном интенсивно читают несколько сессий" и данным ожиданием нет никакой.
2sql+:
Первая же ссылка в гугле:

Read By Other Session
Definition: When information is requested from the database, Oracle will first read the data from disk into the database buffer cache. If two or more sessions request the same information, the first session will read the data into the buffer cache while other sessions wait. In previous versions this wait was classified under the "buffer busy waits" event. However, in Oracle 10.1 and higher this wait time is now broken out into the "read by other session" wait event. Excessive waits for this event are typically due to several processes repeatedly reading the same blocks, e.g. many sessions scanning the same index or performing full table scans on the same table. Tuning this issue is a matter of finding and eliminating this contention.
Перевести на русский?

2latch free:
latch freeпытаюсь разобраться, почему висит программа на одном запросе около минуты
latch freeДа, всё так :-). Программа (это фоновый процесс) и ORACLE не находятся в состоянии непрерывного обмена данными, но остаются connected. Т.е. в цикле есть период активности, потом программа засыпает на 10 секунд, просыпается и снова что-то делает...
Так, значит, не "программа", а "фоновый процесс". Объясните, что значит "висит"? Для того, чтобы не знаниматься гаданием на кофейной гуще, приведите 2 факта:
1. Загрузка ЦПУ "висящим" процессом
2. Трейс сессии за 10 минут (лучше непарсеный в архиве) - как снять трассировку - в разделе FAQ данного сайта.

...

Рейтинг:

0 / 0

05.08.2008, 12:43

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470846

sql+

Гость

На русский не нужно переводить. Я просто хотел понять как ты понимаешь суть ожидания, чего именно ждут сессии. В данном твоя случае ссылка на документ этого не раскрывает.

...

Рейтинг:

0 / 0

05.08.2008, 12:48

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470869

sql+

Гость

Ты просто объясни своими словами это и закончим на этом.
авторtwo or more sessions request the same information, the first session will read the data into the buffer cache while other sessions wait.

...

Рейтинг:

0 / 0

05.08.2008, 12:53

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470877

$RA\/EN$

RA\/EN

Участник

Сообщения: 2 941

Рейтинг: 0 / 0

sql+На русский не нужно переводить. Я просто хотел понять как ты понимаешь суть ожидания, чего именно ждут сессии. В данном твоя случае ссылка на документ этого не раскрывает.
Ну свое понимание данного ожидания я раскрыл - добавить больше к процитированному ничего не имею.
Ваше слово, товарищ маузер! (с) - что Вы подразумеваете под этим ожиданием?

...

Рейтинг:

0 / 0

05.08.2008, 12:55

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35470915

sql+

Гость

то же самое что в документации.

...

Рейтинг:

0 / 0

05.08.2008, 13:07

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35471042

$RA\/EN$

RA\/EN

Участник

Сообщения: 2 941

Рейтинг: 0 / 0

sql+то же самое что в документации.
Ну хоть бы процитировал (а то я документацию не читаю ) и обсновал вот это свое глубокомысленное высказывание в мой адрес:
sql+Подозреваю что ты неправильно понимаешь смысл данного события.
--
BTW, для остальных, демка появления RbOS:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.

SQL> create table rboswait(id primary key,v) as select level,lpad('x', 2000 ,'x') from dual connect by level<= 120000 ;
 
Table created
 
SQL> 
SQL> SELECT e.total_waits, e.time_waited FROM v$session_event e
   2    WHERE e.sid = sys_context('USERENV','SID') AND e.event = 'read by other session'
   3   /
 
TOTAL_WAITS TIME_WAITED
----------- -----------
 
SQL> -- предварительно запускаем аналогичный блок в другой сессии, только c FOR i IN 1..1e7
SQL> BEGIN
   2     FOR i IN  1 ..1e5 LOOP
   3       FOR r1 IN (SELECT to_number(to_char(systimestamp,'ssff3'))* 2  n FROM dual) LOOP
   4         FOR r2 IN (
   5           SELECT COUNT(v) FROM rboswait WHERE ID BETWEEN r1.n- 10  AND r1.n+ 10 ) LOOP
   6             NULL;
   7           END LOOP;
   8       END LOOP;
   9     END LOOP;
  10   END;
  11   /
 
PL/SQL procedure successfully completed
 
SQL> 
SQL> SELECT e.total_waits, e.time_waited FROM v$session_event e
   2    WHERE e.sid = sys_context('USERENV','SID') AND e.event = 'read by other session'
   3   /
 
TOTAL_WAITS TIME_WAITED
----------- -----------
        3604            94 
 
SQL>

SQL написан так, чтобы обе сессии одновременно хотели один и тот же блок, не находящийся в кэше.

...

Рейтинг:

0 / 0

05.08.2008, 13:50

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35471164

sql+

Гость

RA\/EN
Ну хоть бы процитировал (а то я документацию не читаю ) и обсновал вот это свое глубокомысленное высказывание в мой адрес:
sql+Подозреваю что ты неправильно понимаешь смысл данного события.

Я написал "подозреваю, что непонимаешь", а не "уверен, что непонимаешь".
А обосновать я не могу по причине твоего отказа прокомментировать.
Я уже сказал, что квотирование документации нераскрывает твоего понимания.

Хотя я без претензий, потому что что-то знать и уметь рассказать это что-то другому - суть разная.

...

Рейтинг:

0 / 0

05.08.2008, 14:22

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35471626

Попрошайка

Гость

sql+, достаточно будет мне добавить, что происходит вымывание из buffer cache наиболее часто востребованных блоков, что приводит к необходимости копирования их с диска в ОЗУ в рамках конкурирующих за данный блок процессов? Теперь от RAVEN'a ты отстанешь?...:)

...

Рейтинг:

0 / 0

05.08.2008, 16:29

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35471638

Попрошайка

Гость

Попрошайка sql+, достаточно будет мне добавить, что происходит вымывание из buffer cache наиболее часто востребованных блоков, что приводит к необходимости копирования их с диска в ОЗУ в рамках конкурирующих за данный блок процессов? Теперь от RAVEN'a ты отстанешь?...:)

И что вариантов ДВА:

1. сделай так, чтобы блоки учавствующие в 'read by other session' сидели в кеше долго и с пользой,
2. сделай так, чтобы строчки в таких блоках ('read by other session') стали строчками дополнительных блоков, тем самым снимая нагрузку с "горячих" блоков.

...

Рейтинг:

0 / 0

05.08.2008, 16:32

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35473354

latch free

Гость

Попрошайка Попрошайка sql+, достаточно будет мне добавить, что происходит вымывание из buffer cache наиболее часто востребованных блоков, что приводит к необходимости копирования их с диска в ОЗУ в рамках конкурирующих за данный блок процессов? Теперь от RAVEN'a ты отстанешь?...:)

И что вариантов ДВА:

1. сделай так, чтобы блоки учавствующие в 'read by other session' сидели в кеше долго и с пользой,
2. сделай так, чтобы строчки в таких блоках ('read by other session') стали строчками дополнительных блоков, тем самым снимая нагрузку с "горячих" блоков.
вопрос: эти два варианта могут/должны быть реализованы на уровне приложения (если да, то как - не могу себе представить!) или Вы что-то другое имели в виду?

...

Рейтинг:

0 / 0

06.08.2008, 12:53

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35473516

Попрошайка

Гость

Дело в том, что одна сессия читает блок с диска и помещает его в buffer cache. Понятно, что Oracle использует принцип хранить в buffer cache одну копию текущего блока, который потом уедет на диск (всякие там клоны блоков не рассматриваем). Поэтому он блокирует все другие сесии на предмет копирования того же самого блока - иначе будет каша, да и с точки производительности это так же не правильно и не логично. Но почему другие сесии ждут этот блок? Напрашивается ответ: "Потому, что другая сессия читает уже его, ну так получилось, что процессор обработал быстрее..., как вариант". А почему она читает? Потому, что его нет в buffer cache его нет. Почему его там нет? Потому, что:
1. его там никогда не было, а тут появилась необходимость ему там быть,
2. его кто-то выдавил из buffer cache.

Отсюда:

1. Пробуем понять по какой причине его там нет. Вдруг его кто-то вымывает из buffer cache, например другие не эффективные SQL. таким образом убрав причину исчезновения блока из buffer cache можно решить проблему с данным ожиданием.

По пункту два можно сказать так. Если смотреть с другой стороны, то возникает и другой вопрос: "Почему один и тот же блок понадобился одновременно разным сессиям?". Напрашивается ответ: "В нем либо много строк, либо это блок индекса (нарастающая нумерация, например) и т.п.". Соответственно, если такой блок разрядить, то есть сократить в нем количество строк на два три и более блоков, то эффект hot можно с него снять. Для индексов, как правило используется прием reverse, для таблицы, как правило pctfree.

Как бы так думаю.

...

Рейтинг:

0 / 0

06.08.2008, 13:27

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35473681

sql+

Гость

ПопрошайкаДело в том, что
.......
Вдруг его кто-то вымывает из buffer cache, например другие не эффективные SQL . таким образом убрав причину исчезновения блока из buffer cache можно решить проблему с данным ожиданием.
...
Соответственно, если такой блок разрядить, то есть сократить в нем количество строк на два три и более блоков, то эффект hot можно с него снять . Для индексов, как правило используется прием reverse, для таблицы, как правило pctfree.

Как бы так думаю.

1)Совсем необязательно, что неэффективные, могут и эффективные
2)Совсем необязательно, что данная проблема связана с горячими блоками. Если каждый блок запрашивается два раза в день одновременно несколькими сессиями , значит ли что он горячий? Нет. Но таких блоков запрашиваемых два раза на дню может быть мульон. В итоге статистика по данному ожиданию будет большая
3)Причина ожидания может быть очень простой - банально нехватает памяти - буферный кэш мал.

...

Рейтинг:

0 / 0

06.08.2008, 14:04

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35473736

Попрошайка

Гость

sql+ ПопрошайкаДело в том, что
.......
Вдруг его кто-то вымывает из buffer cache, например другие не эффективные SQL . таким образом убрав причину исчезновения блока из buffer cache можно решить проблему с данным ожиданием.
...
Соответственно, если такой блок разрядить, то есть сократить в нем количество строк на два три и более блоков, то эффект hot можно с него снять . Для индексов, как правило используется прием reverse, для таблицы, как правило pctfree.

Как бы так думаю.

1)Совсем необязательно, что неэффективные, могут и эффективные
2)Совсем необязательно, что данная проблема связана с горячими блоками. Если каждый блок запрашивается два раза в день одновременно несколькими сессиями , значит ли что он горячий? Нет. Но таких блоков запрашиваемых два раза на дню может быть мульон. В итоге статистика по данному ожиданию будет большая
3)Причина ожидания может быть очень простой - банально нехватает памяти - буферный кэш мал.

А никто и не говорит, что все просто и все обязательно. Но когда блок одновременно запрашивается несколькими сессиями раз в три часа, то это НЕ есть проблема. Проблема - это когда она ухужшает производительность. В случае, который описываете вы, а именно якобы маленький buffer cache тождественно равно "блок вымывается" и никак не равен случаю, когда миллион разных блоков накручивают счетчик. Ради таких блоков (я бы их назвад множеством случайных блоков) никто и не собирался buffer cache раздвигать. Тут логичнее такие блоки расщепить. пусть они и Не горячие на столько, чтобы о них говорить, как о горячих.

...

Рейтинг:

0 / 0

06.08.2008, 14:14

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35473760

Попрошайка

Гость

Кстати, эффективность SQL ведь не только по отношению к ресурсам сервера определяется, но и по отношению к другим SQL. Как вы считаете? Ведь, если два SQL мешают друг другу, то необходимо выявить причину и устранить ее, тем самым устранить не эффективность одного из них или обоих одновременно!

...

Рейтинг:

0 / 0

06.08.2008, 14:19

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35473769

Попрошайка

Гость

...

Рейтинг:

0 / 0

06.08.2008, 14:22

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35473826

sql+

Гость

ПопрошайкаКстати, эффективность SQL ведь не только по отношению к ресурсам сервера определяется, но и по отношению к другим SQL. Как вы считаете? Ведь, если два SQL мешают друг другу, то необходимо выявить причину и устранить ее, тем самым устранить не эффективность одного из них или обоих одновременно!

Я бы сказал не по отношению к другому SQL, а пот отношению к тому же SQL, но по другому написаному и оптимизированному в иной степени.

Совсем необязательно, что это разные запросы. Этот может быть абсолютно тот же самый функционал и один и тот же запрос, причём идеально написанный и отлаженный. Просто двое или трое дядек в одном отделе, сидящие в одной комнате решили посмотреть один и тот же документ в своём корпоративном документообороте, что бы обсудить его. Вот вам и "buffer buzy waits(130)", он же "read by other session" в 10g. В совокопнусти с перегруженной дисковой системой и маленьким буферным кэшем.

...

Рейтинг:

0 / 0

06.08.2008, 14:34

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35474022

Попрошайка

Гость

Хрен с ним, пусть будет, как будет. Как там с вопросом темы...:) "latch free в v$session_wait"

...

Рейтинг:

0 / 0

06.08.2008, 15:21

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35474277

latch free

Гость

ПопрошайкаХрен с ним, пусть будет, как будет. Как там с вопросом темы...:) "latch free в v$session_wait"
с большим интересом следил за развязанноой мною дискуссией, почерпнул много для себя полезного, всем огромное спасибо!

Думаю, что стоит описать ситуевину, приведшую к проблемам (тут я думаю скорее всего был ближе к реальности sql+ в своем последнем посте).

Нужно распределить вновь прибывшие записи из одной таблицы (TAB1, PK1, примерно 910000 записей) на N терминалов, чтобы те - случись что - могли работать и оффлайн дальше. Распределение происходит по определенным правилам, т.е. не все записи должны попасть на каждый терминал, но связь N:M.Решается это так (может не оптимально, прошу не бить сразу, но решение уже принято, запущено, уже так быстро не изменить): в промежуточную таблицу TAB2 пишутся после анализа кому какая запись принадлежит записи типа <TERM - номер терминала> <PK1 от таблицы TAB1>. Дальше есть процесс, распределяющий записи по терминалам, он делает SELECT ... FROM TAB1 JOIN TAB2 ON TAB1.PK1=TAB2.PK1 WHERE TAB1.TERM=NR1 и после успешной отсылки записей уничтожает свои (NR1) записи из TAB2, так что количество записей в ней всегда очень небольшое и этот SQL должен работать очень хорошо. Но не работает - см. топик! Наверно корень зла в том, что запускаются несколько ипостасей этого процесса (каждый обслуживает свою группу терминалов), запускаются они одновременно, просыпаются синхронно после паузы и одновременно пытаются поиметь одни и те же блоки из TAB1. Похоже на причину RbOS? Там еще кстати и таймоуты есть, т.е. бывает, что и не дожидается своего блока, так что ли?

Что смущает, что это не основное время ожидания, db file scattered read гораздо больше. Обычно они связываются с full table scan, но когда я смотрю план, то никаких full table scan нет... Может это быть от сильной фрагментации таблицы TAB1?

...

Рейтинг:

0 / 0

06.08.2008, 16:41

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35474324

Попрошайка

Гость

Вы сделайте трассировку 10046 именно работы этих процессов, которые работают на терминалы. Можете?

...

Рейтинг:

0 / 0

06.08.2008, 16:53

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35474442

$RA\/EN$

RA\/EN

Участник

Сообщения: 2 941

Рейтинг: 0 / 0

latch free ПопрошайкаХрен с ним, пусть будет, как будет. Как там с вопросом темы...:) "latch free в v$session_wait"
Дальше есть процесс, распределяющий записи по терминалам, он делает SELECT ... FROM TAB1 JOIN TAB2 ON TAB1.PK1=TAB2.PK1 WHERE TAB1.TERM=NR1 и после успешной отсылки записей уничтожает свои (NR1) записи из TAB2,
...
Похоже на причину RbOS? Там еще кстати и таймоуты есть, т.е. бывает, что и не дожидается своего блока, так что ли?
...
Что смущает, что это не основное время ожидания, db file scattered read гораздо больше. Обычно они связываются с full table scan, но когда я смотрю план, то никаких full table scan нет... Может это быть от сильной фрагментации таблицы TAB1?
1. Процесс, я правльно понял, внешнее приложение?
2. Надо трейс одного "порбега" одного из процессов.
...
3. Похоже - не то слово Похоже, авторы задались целью украсить статспак своего приложения экзотический событием ожидания
...
4.... а также INDEX FAST FULL SCAN
Приведите план запроса.

P.S. Ну и трассу бы (не обработанную tkprof) не помешало бы приложить - однако она будет немного "кривой" - думаю, трассировка настолько тормознет трассируемый процесс, что он будет выполняться параллельно с остальными лишь небольшую часть времени.

...

Рейтинг:

0 / 0

06.08.2008, 17:30

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35474489

Попрошайка

Гость

Добавлю к RAVEN "2. Надо трейс одного "пробега" одного из процессов." ВО ВРЕМЯ РАБОТЫ ВСЕХ ОДНОВРЕМЕННО!

...

Рейтинг:

0 / 0

06.08.2008, 17:44

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35474865

Стив

Гость

Я вот чего хочу спросить у автора - не знаю, может это к данной проблеме и не относится - а почему в самом первом посте у вас блоки по 16 считываются? у вас db_file_multiblock_read_count, или как он там, в 16 выставлен? может стоит поболее поставить, ну там 64, например. Понимаю, что данный параметр зависит от железа ввода/вывода, но обычно данный параметр при фулсканах помогает.
хотя с конкуренцией за блоки он не помощник, конечно.

...

Рейтинг:

0 / 0

06.08.2008, 21:10

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#35474944

Попрошайка

Гость

СтивЯ вот чего хочу спросить у автора - не знаю, может это к данной проблеме и не относится - а почему в самом первом посте у вас блоки по 16 считываются? у вас db_file_multiblock_read_count, или как он там, в 16 выставлен? может стоит поболее поставить, ну там 64, например. Понимаю, что данный параметр зависит от железа ввода/вывода, но обычно данный параметр при фулсканах помогает.
хотя с конкуренцией за блоки он не помощник, конечно.

Кстати, db_file_multiblock_read_count=0 в 10ке автоматически регулирует этот параметр на основе своего интеллекта.

...

Рейтинг:

0 / 0

06.08.2008, 22:52

| Ответить | Цитировать | Написать

Период между сообщениями больше года.

что можно выудить из latch free в v$session_wait?

#36585051

Foxter

Участник

Откуда: Fairfield, CS, USA

Сообщения: 439

Рейтинг: 0 / 0

Уважаемые, а не подскажете как мне отследить время выполнения конкретного запроса для вывода индикации его исполнения (или в секундах, оставшихся до завершения или в %). Понимаю, что надо брать значения из V$SESSION_WAIT, но как мне узнать именно мой запрос?

...

Рейтинг:

0 / 0

19.04.2010, 10:47

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#36585533

Foxter

Участник

Откуда: Fairfield, CS, USA

Сообщения: 439

Рейтинг: 0 / 0

FoxterУважаемые, а не подскажете как мне отследить время выполнения конкретного запроса для вывода индикации его исполнения (или в секундах, оставшихся до завершения или в %). Понимаю, что надо брать значения из V$SESSION_WAIT, но как мне узнать именно мой запрос?

Никаких соображений нет? Ммм... жаль, то есть получается, что прогресс выполнения запроса вообще никак контролировать нельзя?

...

Рейтинг:

0 / 0

19.04.2010, 14:02

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#36585594

suPPLer

Участник

Откуда: Харків, Україна

Сообщения: 7 838

Рейтинг: 0 / 0

Foxter,

STFF прогресс выполнения запроса . Вкратце - рисуйте анимированное "Идёт работа, в Reset не тыкать!". :)

...

Рейтинг:

0 / 0

19.04.2010, 14:27

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#36586882

Foxter

Участник

Откуда: Fairfield, CS, USA

Сообщения: 439

Рейтинг: 0 / 0

Спасибо, видимо так и придется поступить :)

...

Рейтинг:

0 / 0

20.04.2010, 10:05

| Ответить | Цитировать | Написать

Период между сообщениями больше года.

что можно выудить из latch free в v$session_wait?

#39362485

VDom

Гость

Foxter,
Дело конечно прошлое, но может это кому поможет.
Есть такая вьюшка
SQL> desc v$session_longops
Name Null? Type
----------------------------------------- -------- ----------------------------
SID NUMBER
SERIAL# NUMBER
OPNAME VARCHAR2(64)
TARGET VARCHAR2(64)
TARGET_DESC VARCHAR2(32)
SOFAR NUMBER
TOTALWORK NUMBER
UNITS VARCHAR2(32)
START_TIME DATE
LAST_UPDATE_TIME DATE
TIMESTAMP DATE
TIME_REMAINING NUMBER
ELAPSED_SECONDS NUMBER
CONTEXT NUMBER
MESSAGE VARCHAR2(512)
USERNAME VARCHAR2(30)
SQL_ADDRESS RAW(8)
SQL_HASH_VALUE NUMBER
SQL_ID VARCHAR2(13)
QCSID NUMBER

Обычно её используют для оценки времени выполнения долгоиграющих вещей.
Например завершения бакапа, или время завершения отката большой транзакции.
Зная SQL_ID интересующего запроса можно узнать перспективы его завершения.

...

Рейтинг:

0 / 0

08.12.2016, 12:53

| Ответить | Цитировать | Написать

что можно выудить из latch free в v$session_wait?

#39362503

Nobody1111

Гость

VDom, в общем случае это будут перспективы завершения одного из шагов в плане выполнения запроса.

...

Рейтинг:

0 / 0

08.12.2016, 13:04

| Ответить | Цитировать | Написать

51 сообщений из 51, показаны все 3 страниц

все

Форумы / Oracle [игнор отключен] [закрыт для гостей] / что можно выудить из latch free в v$session_wait?

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?all=1&fid=52&tid=1886867]:	0ms
get settings:	6ms
get forum list:	18ms
check forum access:	3ms
check topic access:	3ms
track hit:	149ms
get topic data:	9ms
get forum data:	4ms
get page messages:	77ms
get tp. blocked users:	1ms
others:	222ms

total:	492ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы