Текущий архив: 2002.12.12;
Скачать: CL | DM;
Вниз
Look Wait - как правильно отработать ситуацию на клиенте? Найти похожие ветки
← →
EternalWonderer (2002-11-21 12:46) [0]Хотелось бы услышать мнение профессионалов, как они борятся с проявлениями указанного явления в клиентской программе. Версия Oracle - 8.1.6, ODAC3.3.
← →
EternalWonderer (2002-11-21 12:48) [1]Извините, конечно же, Lock Wait :)
← →
Prooksius © (2002-11-21 12:52) [2]Почитай вот это (для IB):
http://www.ibase.ru/devinfo/0111.htm
Наверно, принцип тот же...
← →
EternalWonderer (2002-11-21 16:00) [3]Да, там есть интересные советы. В частности, не держать транзакции открытыми длительное время. Однако, меня интересует несколько иной аспект проблемы: как защититься от блокировки, а не как её предотвратить.
Поясню: в нашей системе после двух лет надёжной работы вдруг неожиданно начали систематически появляться эти самые Lock Wait"ы. С причиной мы разобрались на второй день :), но в течении этих самых двух дней клиенты работали в постоянном ожидании "подвисания" программы - кому нравится так работать?
← →
Prooksius © (2002-11-21 16:45) [4]Так и в чем же был глюк? Может, избавившись от него, вы и решите проблему?
← →
Jeer © (2002-11-21 16:52) [5]IB - многоверсионник
Oracle - блокировочник
разные принципы.
Попадание клиента на блокировку определяется совокупностью факторов. Защитится от нее ? Это же вероятностный процесс.
Только изменением вероятности.
← →
EternalWonderer (2002-11-22 09:19) [6]Да нет же! Попробую сформулировать вопрос по-другому.
Какие меры можно предпринять при написании клиентской программы, чтобы при возникновении Lock Wait"а она не "подвисала", а, например, предлагала откатить транзакцию?
← →
Sergey13 © (2002-11-22 09:25) [7]2EternalWonderer (21.11.02 12:46)
select ...for update ...nowait - ты это имел ввиду?
2Prooksius © (21.11.02 16:45)
Присоединяюсь к вопросу.
← →
EternalWonderer (2002-11-22 09:53) [8]Вопрос - ответ.
Причина Lock Wait"ов, как выяснилось, была в следующем:
В таблице, в которую активно добавлялись данные, в триггере BEFORE INSERT FOR EACH ROW имелась строка (смысл не объясняю:):
SELECT GEN_LIST.NEXTVAL INTO :new.ID FROM dual;
Записи в таблицу добавлялись так:
INSERT INTO table1 (ID,...) VALUES (0,...)
Всё это работало на протяжении около полутора лет, в течении которых в таблицу было вставлено около 100000 записей, однако по невыясненным обстоятельствам в какой - то момент появились эти самые Lock Wait"s, появляющиеся при приблизительно одновременной вставке записи с разных машин, при этом одна из клиентских программ "висла" напрочь.
Проблема была решена следующим образом:
В указанной таблице, в триггере BEFORE INSERT FOR EACH ROW строка была изменена на (смысл опять не объясняю:):
If (:new.ID is NULL) Or (:new.ID=0) Then
SELECT GEN_LIST.NEXTVAL INTO :new.ID FROM dual;
End If;
Записи в таблицу стали добавляться так:
Сначала отдельным запросом на клиента запрашивался NEXTVAL (n),
затем:
INSERT INTO table1 (ID,...) VALUES (n,...)
,
После этого всё третий день работает как часы (тьфу-тьфу),
почему - понятия не имею.
Но хочется бОльшего - чтобы при следующем таинственном появлении LockWait"ов мы были "во всеоружии".
← →
Sergey13 © (2002-11-22 10:22) [9]2EternalWonderer (22.11.02 09:53)
Странно. Вроде и так итак должно работать. Первый вариант даже предпочтительней, ИМХО, потому что данные о некствале по сети не гоняются(хотя это мелочь). Одно непонятно - зачем в инсерте вообще указывать id, если он в тригере заполняется. Хотя и ошибки в этом нет.
← →
EternalWonderer (2002-11-22 10:30) [10]Вот и я так же думаю. Но вопрос-то в другом!
← →
Sergey13 © (2002-11-22 10:46) [11]2EternalWonderer (22.11.02 10:30)
А как вы решили что проблема именно в этом тригере? Что и как смотрели? Мне кажется мало вероятно чтоб это могло лочить.
← →
EternalWonderer (2002-11-22 11:11) [12]А решили очень просто:
1) выдавали из TOAD два INSERT"а подряд (в одном скрипте) по первой схеме, с нулями - TOAD подвисал, при этом с другой машины в DBA-> Kill/Trace можно было посмотреть на номер LockWait - 0382CCCC - кстати, он означает что-то осмысленное?;
2) ввели изменения в триггер;
3) выдавали те же два INSERTA, но вставляли в них значения ID не нули, а произвольно выбранные разные (с обеспечением уникальности, разумеется:)- вставка проходила без проблем;
4) внесли соотв. изменения в программу (слава Богу, у нас организован автоапгрейд клиентов).
Думаю, здесь имеет место какой - то локальный глюк, который, возможно, пропал бы после shutdown-sturtup ORACLE (последний раз его делали месяц назад).
← →
Sergey13 © (2002-11-22 11:33) [13]2EternalWonderer (22.11.02 11:11)
>Думаю, здесь имеет место какой - то локальный глюк
Похоже
← →
EternalWonderer (2002-11-22 11:37) [14]Как я понимаю, работа должна быть организована по следующей схеме:
1) выполнение SQL;
2) ожидание подтверждения завершения транзакции в течении n секунд;
3) если пришло подтверждение - выход;
4) если подтверждения не пришло, попытаться определить причину "зависания";
5) Если причина - LockWait, запросить пользователя, что делать: ждать,откатить или выдать снова;
6) если ждать - к п.2;
7) если откатить - выполнить откат и выход;
8) если выдать снова - откатить и к п.1;
9) выход.
Однако есть много вопросов, как это реализовать. Неужели никто не занимался решением этой задачи?
← →
Sergey13 © (2002-11-22 11:52) [15]2EternalWonderer (22.11.02 11:37)
>2) ожидание подтверждения завершения транзакции в течении n секунд;
Как определить это "n"? 8-)
>3) если пришло подтверждение - выход;
Какое подтверждение?
>Однако есть много вопросов, как это реализовать
Не заморачивайся ты на это - мой совет. Был глюк и прошел. 8-)
← →
EternalWonderer (2002-11-22 13:54) [16]Придёт лето, будет работать второй состав, - вот тогда-то оно и всплывёт по "закону подлости".
← →
petr_v_a © (2002-11-22 18:03) [17]Для начала посмотрите row_wait_object# в v$session, будет по крайней мере понятно, что блокировано.
lock_wait смысл имеет
v$session.lock_wait=v$lock.kaddr
если заблокирован объект (таблица,индекс) v$lock.id21=v$locked_object.xidqsn
ЗЫ АДМИН Вам нужен
← →
EthernalWonderer (2002-11-22 22:01) [18]Спасибо за подсказку!
Что имеется в виду под "ЗЫ АДМИН" (извините, может, я не совсем понимаю местный сленг)?
Страницы: 1 вся ветка
Текущий архив: 2002.12.12;
Скачать: CL | DM;
Память: 0.51 MB
Время: 0.017 c