Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 dml lock allocation  [new]
ять
Guest
Указанного типа ожидания длительные latch free. Откуда ноги растут, что делать ?
11g
18 янв 11, 09:50    [10088421]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Для начала покажи секции AWR из которых ясно, что есть проблема. top 5 с этим латчем, Latch Sleep breakdown Latch Miss Sources и т.д. по этому латчу, а лучше весь AWR, т.к. там может быть много интересного открывающее свет на проблему, если она есть. Также можно посмотреть в v$latch_children, может оно все по одной таблице.
18 янв 11, 10:10    [10088527]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
ять
Guest
wurdu
Для начала покажи секции AWR из которых ясно, что есть проблема. top 5 с этим латчем

непосредственно из trace по одной из ждущих сессий
WAIT #N: nam='latch free' ela= 8157 address=... number=232 tries=0 ...
WAIT #N: nam='latch free' ela= 8060 address=... number=232 tries=0 ...
и тд
18 янв 11, 10:20    [10088585]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Желательно все-таки AWR, т.к. это конкуренция и причин может быть много, включая перегруженные CPU. address одинаковый? Раз есть trace, значит можно увидеть после DML на каких объектах возникает ожидание. Это разные объекты?
18 янв 11, 10:33    [10088702]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
ять
Guest
wurdu
Желательно все-таки AWR, т.к. это конкуренция и причин может быть много, включая перегруженные CPU. address одинаковый? Раз есть trace, значит можно увидеть после DML на каких объектах возникает ожидание. Это разные объекты?

в сессии (и trace) select only (нет insert/update и тд)
18 янв 11, 10:39    [10088752]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
ять
Guest
address один и тот же
18 янв 11, 10:49    [10088825]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1814
232-это вроде менеджер ресурсов (resmgr:gang list). Так, что вполне вероятно недостаток cpu.
18 янв 11, 10:52    [10088851]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1814
Я и ёжик
232-это вроде менеджер ресурсов (resmgr:gang list). Так, что вполне вероятно недостаток cpu.

Упс... сори в 11-м изменилось.
18 янв 11, 10:58    [10088894]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
ять
address один и тот же
Значит конкуренция скорее всего идет за один и тот же объект. Правда этот латч для DML, поэтому я не понимаю, как может он появляться в простом select. Интересно было бы взглянуть на сырой trace. Ну и на это
select addr, latch#, name, gets, misses, sleeps, wait_time from v$latch_children where name = 'DML lock allocation';
18 янв 11, 11:15    [10089057]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
оraguеst.
Guest
ять
в сессии (и trace) select only (нет insert/update и тд)

а случайно не на массовых запросах к каким-нибудь v$*lock* ?
где-то встречалась похожая бяка
19 янв 11, 18:26    [10099170]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
у меня тоже самое
Guest
2 оraguеst.

У меня такая проблема. вы нашли решение?
17 май 11, 14:32    [10664791]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
тэкс.
Guest
у меня тоже самое

У меня такая проблема. вы нашли решение?

опишите конкретнее свою ситуацию (и версию)
17 май 11, 15:50    [10665541]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
Гость--
Guest
Все рассуждения бессмысленны пока не будет показан Top 5 и суммарный результат ожиданий в trace
Пока мы видели только 2 ожидания по 8миллисекунд.
17 май 11, 16:04    [10665713]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
Corner
Member

Откуда:
Сообщений: 1270
Возникают ожидания "latch free".

SQL> select name
  from v$latch
 where addr in (select p1raw from v$session where event = 'latch free')  2    3  ;

NAME
----------------------------------------------------------------
DML lock allocation

сессии, который ждут latch free выполняют как раз выборку по v$lock. но вот на что обратил внимание

OPTIMIZER_MODE               SQL_TEXT
------------------           ------------------------------------------------------------------------------------------
RULE                         SELECT L.SID FROM V$LOCK L WHERE L.TYPE IN ('TM', 'TX') AND L.ID1 = :B1
FIRST_ROWS                   SELECT L.SID FROM V$LOCK L WHERE L.TYPE IN ('TM', 'TX') AND L.ID1 = :B1


В бд стоит
SQL> show parameter optimizer_mode

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_mode                       string      FIRST_ROWS
откуда взялся Rule

SQL> select * from v$version where rownum<2;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
17 май 11, 16:04    [10665724]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: dml lock allocation  [new]
Владимир СА
Member

Откуда:
Сообщений: 7660
wurdu
Для начала покажи секции AWR из которых ясно, что есть проблема. top 5 с этим латчем, Latch Sleep breakdown Latch Miss Sources и т.д. по этому латчу, а лучше весь AWR, т.к. там может быть много интересного открывающее свет на проблему, если она есть. Также можно посмотреть в v$latch_children, может оно все по одной таблице.
Может быть поможешь с разбиранием AWR.
13 мар 19, 16:50    [21831530]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
Владимир СА
Member

Откуда:
Сообщений: 7660
AWR

К сообщению приложен файл (AWR Rpt - oradb Snap 38976 thru 38979.zip - 120Kb) cкачать
13 мар 19, 16:52    [21831532]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
Валерий Юринский
Member

Откуда: Москва, "ФОРС Дистрибуция"
Сообщений: 1104
Владимир СА
wurdu
Для начала покажи секции AWR из которых ясно, что есть проблема. top 5 с этим латчем, Latch Sleep breakdown Latch Miss Sources и т.д. по этому латчу, а лучше весь AWR, т.к. там может быть много интересного открывающее свет на проблему, если она есть. Также можно посмотреть в v$latch_children, может оно все по одной таблице.
Может быть поможешь с разбиранием AWR.
Напишите мне письмо. Поможем с разбиранием AWR.
13 мар 19, 16:53    [21831534]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
Владимир СА
Member

Откуда:
Сообщений: 7660
Валерий Юринский
Владимир СА
пропущено...
Может быть поможешь с разбиранием AWR.
Напишите мне письмо. Поможем с разбиранием AWR.
Письмо отправил
13 мар 19, 17:02    [21831542]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
Валерий Юринский
Member

Откуда: Москва, "ФОРС Дистрибуция"
Сообщений: 1104
Владимир СА
Валерий Юринский
пропущено...
Напишите мне письмо. Поможем с разбиранием AWR.
Письмо отправил
Ловите ответ!
13 мар 19, 17:59    [21831625]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
Владимир СА
Member

Откуда:
Сообщений: 7660
Спасибо, получил...
14 мар 19, 12:01    [21832294]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
Alexander Anokhin
Member

Откуда: Хабаровск
Сообщений: 428
Господа, давно вы перешли на приватные анализы публично выложенных AWR по email? Всё-таки мы должны делиться знаниями друг с другом.

Владимир СА,

Top 10 Foreground Events by Total Wait Time

Event				Waits	Total Wait Time (sec)	Wait Avg(ms)	% DB time	Wait Class
DB CPU	 				42,6K	 				32.2	 
latch free			34,665	302,1			9		.2		Other
log file sync			13,186	48,8			4		.0		Commit
db file sequential read		237,416	26,3			0		.0		User I/O
direct path read		14,658	14,3			1		.0		User I/O
SQL*Net more data to client	155,245	5,6			0		.0		Network
db file parallel read		472	1,6			3		.0		User I/O
SQL*Net message to client	304,588	,8			0		.0		Network
db file scattered read		7,535	,6			0		.0		User I/O
latch: cache buffers chains	57	,4			7		.0		Concurrency

Первое, что здесь бросается в глаза, это то, что только ~33% от DB time зарепорчено. Это очень мало, в идеале должно быть 100%. Остальные 77% это то что называют unaccounted time, здесь это скрытые ожидания.
В данном случае эту секцию можно читать как
Top 10 Foreground Events by Total Wait Time

Event				Waits	Total Wait Time (sec)	Wait Avg(ms)	% DB time	Wait Class
Unaccounted time                        89K					77.6
DB CPU	 				42,6K	 				32.2	 
Остальные ожидания около .0% от DB time как "latch free", "log file sync" и другие здесь можно игнорировать, поскольку если бы их не было, стало бы быстрее примерно на .0%.

Смотрим как себя чувствует хост
Host Name			Platform		CPUs	Cores	Sockets	Memory (GB)
				Linux x86 64-bit	4	4	1	31.36

Load Profile
		Per Second	Per Transaction	Per Exec	Per Call
DB Time(s):	12.2		10.5		0.77		0.42
DB CPU(s):	3.9		3.4		0.25		0.14

Host CPU
CPUs	Cores	Sockets	Load Average Begin	Load Average End	%User	%System	%WIO	%Idle
4	4	1	0.18			15.71			98.8	0.8	0.0	0.4

Instance CPU
%Total CPU	%Busy CPU	%DB time waiting for CPU (Resource Manager)
98.9		99.3		0.0

Видно, что хост имеет всего 4 logical CPU на 4 ядрах, все они заняты, load average сильно выше кол-ва CPU (хотя на Linux load avg включает процессы в D state, тут это явно runable процессы). Хост явно перегружен по CPU, и все эти 4 CPU загружены этим инстансом, это видно по DB CPU per sec = 4 или 99% "%Busy CPU" в "Instance CPU". Скрытые ожидания выше в top timed events это CPU latency. Поскольку процессов, которые ждут когда их посадят на CPU больше, чем количество CPU, все они вынуждены время от времени ждать когда OS scheduler посадит их на CPU, сидя в run queue. В это время их DB time растёт, а DB CPU нет.

Далее смотрим сюда
Time Model Statistics
Statistic Name			Time (s)	% of DB Time
sql execute elapsed time	131,940.74	99.81

SQL ordered by CPU Time
CPU Time (s)	Executions	CPU per Exec (s)	%Total	Elapsed Time (s)	%CPU	%IO	SQL Id	SQL Module	SQL Text
39,759.45	25	1,590.38	93.27	122,198.97	32.54	0.02	5n5rt0yjq36kg	w3wp.exe	select TITLE_TYPE_ID as title...
470.64	230	2.05	1.10	1,666.82	28.24	0.04	190n91x4147nz	w3wp.exe	select max(fiv.value/1000) kee...
442.80	1	442.80	1.04	1,732.08	25.56	0.00	afmujv9zqhbz7	w3wp.exe	WITH SRC AS (SELECT MAX(BD_ACT...
218.91	111	1.97	0.51	760.69	28.78	0.00	dc8rcs6y6f5vm	w3wp.exe	SELECT t.id Id, t.title_number...
150.80	77	1.96	0.35	531.48	28.37	0.00	9xw6mawqgy9v7	w3wp.exe	select * from (select rownum r...

видим, что 99% DB time это SQL execution, и вся эта загрузка порождена всего одним запросом-лидером. Оптимизируем его.
15 мар 19, 15:21    [21833959]     Ответить | Цитировать Сообщить модератору
 Re: dml lock allocation  [new]
xtender
Member

Откуда: Мск
Сообщений: 5043
Alexander Anokhin
Господа, давно вы перешли на приватные анализы публично выложенных AWR по email? Всё-таки мы должны делиться знаниями друг с другом.
Поддерживаю полностью. К тому же для объективности надо показывать результат анализа.

зы. Alexander Anokhin, рад снова тебя тут видеть и что у тебя появилось время заглядывать сюда :)
15 мар 19, 16:57    [21834092]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить