Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Look Wait - как правильно отработать ситуацию на клиенте?

EternalWonderer © (2002-11-21 12:46:00)
Хотелось бы услышать мнение профессионалов, как они борятся с проявлениями указанного явления в клиентской программе. Версия Oracle - 8.1.6, ODAC3.3.

EthernalWonderer (2002-11-22 22:01:00) [1]
Спасибо за подсказку!
Что имеется в виду под "ЗЫ АДМИН" (извините, может, я не совсем понимаю местный сленг)?

petr_v_a (2002-11-22 18:03:00) [2]
Для начала посмотрите row_wait_object# в v$session, будет по крайней мере понятно, что блокировано.
lock_wait смысл имеет
v$session.lock_wait=v$lock.kaddr
если заблокирован объект (таблица,индекс) v$lock.id21=v$locked_object.xidqsn

ЗЫ АДМИН Вам нужен

EternalWonderer (2002-11-22 13:54:00) [3]
Придёт лето, будет работать второй состав, - вот тогда-то оно и всплывёт по "закону подлости".

Sergey13 (2002-11-22 11:52:00) [4]
2EternalWonderer (22.11.02 11:37)
>2) ожидание подтверждения завершения транзакции в течении n секунд;
Как определить это "n"? 8-)
>3) если пришло подтверждение - выход;
Какое подтверждение?

>Однако есть много вопросов, как это реализовать
Не заморачивайся ты на это - мой совет. Был глюк и прошел. 8-)

EternalWonderer (2002-11-22 11:37:00) [5]
Как я понимаю, работа должна быть организована по следующей схеме:
1) выполнение SQL;
2) ожидание подтверждения завершения транзакции в течении n секунд;
3) если пришло подтверждение - выход;
4) если подтверждения не пришло, попытаться определить причину "зависания";
5) Если причина - LockWait, запросить пользователя, что делать: ждать,откатить или выдать снова;
6) если ждать - к п.2;
7) если откатить - выполнить откат и выход;
8) если выдать снова - откатить и к п.1;
9) выход.
Однако есть много вопросов, как это реализовать. Неужели никто не занимался решением этой задачи?

Sergey13 (2002-11-22 11:33:00) [6]
2EternalWonderer (22.11.02 11:11)
>Думаю, здесь имеет место какой - то локальный глюк
Похоже

EternalWonderer (2002-11-22 11:11:00) [7]
А решили очень просто:
1) выдавали из TOAD два INSERT"а подряд (в одном скрипте) по первой схеме, с нулями - TOAD подвисал, при этом с другой машины в DBA-> Kill/Trace можно было посмотреть на номер LockWait - 0382CCCC - кстати, он означает что-то осмысленное?;
2) ввели изменения в триггер;
3) выдавали те же два INSERTA, но вставляли в них значения ID не нули, а произвольно выбранные разные (с обеспечением уникальности, разумеется:)- вставка проходила без проблем;
4) внесли соотв. изменения в программу (слава Богу, у нас организован автоапгрейд клиентов).

Думаю, здесь имеет место какой - то локальный глюк, который, возможно, пропал бы после shutdown-sturtup ORACLE (последний раз его делали месяц назад).

Sergey13 (2002-11-22 10:46:00) [8]
2EternalWonderer (22.11.02 10:30)
А как вы решили что проблема именно в этом тригере? Что и как смотрели? Мне кажется мало вероятно чтоб это могло лочить.

EternalWonderer (2002-11-22 10:30:00) [9]
Вот и я так же думаю. Но вопрос-то в другом!

Sergey13 (2002-11-22 10:22:00) [10]
2EternalWonderer (22.11.02 09:53)
Странно. Вроде и так итак должно работать. Первый вариант даже предпочтительней, ИМХО, потому что данные о некствале по сети не гоняются(хотя это мелочь). Одно непонятно - зачем в инсерте вообще указывать id, если он в тригере заполняется. Хотя и ошибки в этом нет.

EternalWonderer (2002-11-22 09:53:00) [11]
Вопрос - ответ.
Причина 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 09:25:00) [12]
2EternalWonderer (21.11.02 12:46)
select ...for update ...nowait - ты это имел ввиду?
2Prooksius © (21.11.02 16:45)
Присоединяюсь к вопросу.

EternalWonderer (2002-11-22 09:19:00) [13]
Да нет же! Попробую сформулировать вопрос по-другому.

Какие меры можно предпринять при написании клиентской программы, чтобы при возникновении Lock Wait"а она не "подвисала", а, например, предлагала откатить транзакцию?

Jeer (2002-11-21 16:52:00) [14]
IB - многоверсионник
Oracle - блокировочник
разные принципы.

Попадание клиента на блокировку определяется совокупностью факторов. Защитится от нее ? Это же вероятностный процесс.
Только изменением вероятности.

Prooksius (2002-11-21 16:45:00) [15]
Так и в чем же был глюк? Может, избавившись от него, вы и решите проблему?

EternalWonderer (2002-11-21 16:00:00) [16]
Да, там есть интересные советы. В частности, не держать транзакции открытыми длительное время. Однако, меня интересует несколько иной аспект проблемы: как защититься от блокировки, а не как её предотвратить.
Поясню: в нашей системе после двух лет надёжной работы вдруг неожиданно начали систематически появляться эти самые Lock Wait"ы. С причиной мы разобрались на второй день :), но в течении этих самых двух дней клиенты работали в постоянном ожидании "подвисания" программы - кому нравится так работать?

Prooksius (2002-11-21 12:52:00) [17]
Почитай вот это (для IB):
http://www.ibase.ru/devinfo/0111.htm
Наверно, принцип тот же...

EternalWonderer (2002-11-21 12:48:00) [18]
Извините, конечно же, Lock Wait:)

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »