Загрузка IO. с чего начать?

Sleepy_PIP
Дата: 07.06.2006 21:46:14
Наверняка вопрос набил осокмину. Тогда по возможности не ругайтесь, а сошлите куда нито где по вообщем-то _простейшей_ ситуации можно почитать _конкретно_ что предпринять.
Ситуация, которую наблюдал сегодня.
Есть 2-х прцовый сервер. Линукс.
Оракл 9.2.0.5 (пропатченный с 9.2.0.2)
Дисковая подстиситема - зеркало на 2-х SCSI по 39Г каждый. (всего логически - 1 диск , просто зеркалом на 2-х).
Объем (файловый) БД - 17Г, объем пользовательских данных при экспорте - 5.3Г
Действия.
1. сессия1- update inventory set xmlbody=null . в inventory - ~400000 записей. xmlbody - BLOB, хранящийся в отдельном таблспейсе. да, не малая часть всех данных.

2. сессия2 - select * from city

действие 1 почти полностью блокировало действие 2.
т.е. на несколько порядков.
Что можно подкрутить так, что-бы одна сессия не блочила все остальных просто вусмерть. - Это первый вопрос.

Второй вопрос. как экстренно бороться.
Хорошо, имеем эту сессию1 - с манаджерской машинки с Энтерпрайзманагером заходим, и пытаемся удалить сессию1 - она становится killed и не более - нагрузка не спадает.
С линуксового сервера посылаем 15 процессу сесси1 - нулевой эффект.
я предпологаю что пошел собственно откат ... при нашей IO это равносильно.
Из манагера пытаемся стказать shutdown immideately - и дооолго ждем пока не закончится процесс сесси1. только потом shutdown.
Вопрос - а можно было кильнуть процесс сессии по kill -9 ???
И вообще - что делать в такой ситуации (контора просто вся стояла. :( ).
Ну наверное типа правил на случай пожара ...
Да, ДБА у нас нет (.
Спасибо!
Не ругайтесь!
Relic Hunter
Дата: 07.06.2006 22:18:49
Sleepy_PIP
update inventory set xmlbody=null . в inventory - ~400000 записей. xmlbody - BLOB, хранящийся в отдельном таблспейсе. да, не малая часть всех данных
...
Да, ДБА у нас нет (.
Видимо не только ДБА
Sleepy_PIP
Дата: 07.06.2006 22:22:09
Relic Hunter
Sleepy_PIP
update inventory set xmlbody=null . в inventory - ~400000 записей. xmlbody - BLOB, хранящийся в отдельном таблспейсе. да, не малая часть всех данных
...
Да, ДБА у нас нет (.
Видимо не только ДБА

Браво. 5 баллов. еще чего-то желаете?.
Fucker
Дата: 07.06.2006 23:45:06
Купить поболе дисков...

Fucker
Вячеслав Любомудров
Дата: 08.06.2006 05:30:12
Я бы предложил посмотреть ожидания
В частности, имеющие отношения к DBWR.
Есть хорошая статья Стива Адамса "Mysteries of DBWR Tuning"
Там, например есть хорошие скрипты, позволяющие найти затык:
prompt DBWR related waits
prompt ==================
select
  event,
  total_waits,
  time_waited,
  average_wait
from
  sys.v_$system_event
where
  event like 'db file %' or
  event = 'io done' or
  event = 'free buffer waits' or
  event = 'write complete waits'
order by
  time_waited desc
/
prompt DBWR waiting for LGWR
prompt =====================
select
  event,
  total_waits,
  time_waited,
  average_wait
from
  sys.v_$session_event
where
  event = 'log file sync' and
  sid = 2
/
В частности, на одной из БД у меня была проблема с "free buffer waits" -- DBWR не успевал сбрасывать грязные блоки на диск. В принципе, решение понятно -- быстрые диски и/или больший кеш буфер (как правило, это лишь отложит проблему, да и небыло такой возможности).
Но есть и другой подход -- заставить DBWR сбрасывать блоки почаще, но равномернее, т.е. сделать более жадную инкрементальную контрольную точку.
При инсталляции (ставилось производителем и трогать не рекомендовалось) было установлено FAST_START_MTTR_TARGET=600, поменял на 150 (слишком мало тоже плохо) -- проблема ушла.

PS. Просто очень знакомые симптомы и порядок аппаратных средств