Блокировки

← →
BorisUK (2003-03-14 12:01) [0]

СУБД ORACLE
Трехзвенка.
На сервере приложений доступ через ODAC к базе.
На клиент все отображается через связку
1. TOraQuery -> TOraProvider - > TClientDataSet. (это только для отображения - просто SELECT)
есть связка на добавление документа
2. TOraStoredProc -> TOraProvider->TClientDatSet.
И сдесь в процедуре кроме INSERT есть еще и UPDATE так как нужно после добавления нового документа обновить остаток на счете, к которому документ привязан.

Работает несколько клиентов.
Иногда Происходит следующее:
При добавлении документа (2) программа подвисает.
Есть большие подозрения что это происходит потому, что происходит попытка обновить данные на странице данных, уже заблокированных другим пользователем.

Вопрос.!!!
Что сдесь может быть?
Зависшая сессия? Но т к обновление данных в обной записи одной таблици не такой уж долгий процесс, то непонятно почему вообще происходят такие зависания - и разве не должно быть сообщение об ошибке типа "Данные заблокированы..", но нет... просто висим.

или при попытке обновить данные, которые обновляет другой сразу случается DeadLock??? (Тогда может быть и так, но разве ORACLE не автоматом разруливает такие ситуации?)

Как можно поточнее выяснить причину?

Какие есть приемы работы с данными чтоб избежать такие ситуации?
Пока делается StartTransaction в начале сессии.
Затем при каждом вызове проци ждем результат выполнения процедуры и по её итогам commit либо rollback.

Может что в ORACLE настроить?
Поделитесь пожалуста вашими соображениями по этому поводу.

← →
BorisUK (2003-03-14 14:49) [1]

так понял что или это для всех слишком просто... и подсказать чтото ломает...
либо слишком сложно и сказать нечего...
Либо я непонятно описал проблему...
что именно :) ?

← →
myor (2003-03-14 15:36) [2]

раз oracle молчит, значит- прога.

← →
petr_v_a (2003-03-14 17:52) [3]

коммитить надо вовремя

← →
id_privin (2003-03-15 12:39) [4]

a) смотреть в Enterprise Managere раздел locks
b) если есть взаимная блокировка Oracle будет просто стоять и ждать. Ничего тебе не говоря.
с) если есть подозрения на взаимоблокировки надо обеспечить синхронизацию. Те что бы при попытке выполнить второй запрос он блокировался сразу не успевая нагадить первому. Если код в базе на Java делается это элементарно. Иначе либо первый запрос перед выполнением себя должен лочить все что ему понадобиться, либо надо еще как то извращаться

← →
BorisUK (2003-03-17 13:04) [5]

> id_privin © (15.03.03 12:39)

Спасибо за советы... именно на это я и думал..
Проверил, что при блокировке записей последующие обращения обрабатываются нормально... Тоесть СУБД ругается матом, но это правильно.
В моем случае происходит именно ожидание.... причем непонятно по какой причине ... её и ищем :)
Прога просто ждет ответа.. удачного или нет - всеравно (оба обрабатываю как мне надо), но не получает никаких ответов.

проблема еще в том, что базу я не админю поэтому
<< ... код в базе на Java делается это элементарно.
Вот сдесь поточнее если можно...

Если это может быть из за взаимных блокировок, то нельзя ли поточнее. Из за чего они возникают? и как с ними бороться?
Я слышал чтото про разрешение таких конфликтов самой СУБД (отказывает одной - выбирая её случайным образом) уже согласен и на это (хотя лучше конечно найти причину и предотвращать)... как включить такой режим?

Еще есть мысль
"Одна из проблема транзакциями в любой базе данных состоит в том, что транзакции, которые являются активными в течение длительного времени, уменьшают способность другого пользователя модифицировать базу данных. Это случается, потому что каждый раз измененная запись должна быть блокирована, и блокировка должна быть задержана, пока транзакция не завершится, чтобы гарантировать, что никакой другой пользователь не может изменять запись. Эта проблема особенно актуальна, если база данных использует блокировку страницы, это делает невозможным для других пользователей изменение строк на блокированной странице."

Хотел уточнить... Транзакция начинается при коннекте пользователя (это точно). А вот
<<..быть задержана, пока транзакция не завершится...
Когда делается commit данные разблокируются, если перед этим были заблокированы или только после выхода пользователя из базы?

ORACLE использует блокировку страницы. режим "стабильность курсора" - (cursor stability), при котором
блокируется только одна запись в каждый момент времени...
Правда ли это - либо в ORACLE все равно будет заблокирована страница?

← →
petr_v_a (2003-03-17 14:45) [6]

Oracle блокирует запись. Но при умелом администрировании либо его отсутствии можно добиться, что будет блокироваться блок ( когда много транзакций одновременно обращаются к блоку и не хватает места на ITL-слоты ), можно - целый сегмент ( таблица, индекс), это если очень много транзакций одновременно пишут в таблицу и не хватает FreeList`ов.
Правда, скорее всего, это не про Вас, параметры по умолчанию пусть и самые эфеективные, но безопасные, и в такие ситуации можно попасть только при очень большой нагрузке.
В Вашем случае достаточно вызывать commit СРАЗУ после модификации "популярных" таблиц

← →
myor (2003-03-17 15:48) [7]

по BorisUK © (17.03.03 13:04) выходит, что транзакция подтверждается при выходе пользователя из бд. ессно это нужно делать сразу после завершения транзакции (как уже советовали). т. е., нужно просмотреть клиентские запросы, которые приводят к блокировке бд, и добавить в них подтверждение или откат.

← →
BorisUK (2003-03-17 17:35) [8]

> по BorisUK © (17.03.03 13:04) выходит, что транзакция
> подтверждается при выходе пользователя из бд. ессно это
> нужно делать сразу после завершения транзакции

Так и происходит... я это описал.

> Пока делается так StartTransaction в начале сессии.
> Затем при каждом вызове проци ждем результат выполнения
> процедуры и по её итогам commit либо rollback.

Другое дело что в некоторых случаях некоректно вызывать commit по итогам первой процедуры... поэтому происходит блокирование на некоторое время... Время выполнения процов варьируется в зависимости от наличия/отсутствия траблов в сети, загрузке сервака, скорости тачки итд... Обращений к таблице много...!!! тоесть в идеале если предположить, что все одновременно ломануться, то это много много запросов - порядка сотни. Вот тут и нужно видеть всю картину. Что именно и кому нехватает? Как ведет себя сервак в подобноу ситуации? Если блокировка постранична, то тоды все может быть ясно! На это и грешу. Вопрос в том - ЕСТЬ ЛИ У ORACLE ВОЗМОЖНОСТЬ позаписьного блокирования...? Или какие опции еще включить?
<<petr_v_a © (17.03.03 14:45)
Oracle блокирует запись.
Так ли это???

Пока нашел тока сравнение ... итут видно что:
ЙНННННННННННННННННННННННННННННННННННННННННННННННННННННННННННННННННННН»
є Ashton-Tate/ Gupta Tech- Oracle Cor- XDB є
є Фирма Microsoft nologies Novell poration Systems є
ЗДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДД¶
є Продукт SQL SQLBase NetWare ORACLE XDB є
є Server SQL Server Server є
ЗДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДД¶
єРЕЖИМЫ ЗАЩИТЫ є
є-------------..... є
єСтабильность
є курсора + + + +
.....

єБЛОКИРОВАНИЕ, УПРАВЛЯЕМОЕ ПРИКЛАДНЫМ ПРОГРАММИСТОМ є
є-------------------------------------------------- є
єУровень таблиц - - - + + є
єУровень страниц - - - - - є
єУровень записей - - + - -
___
.....
________________________________________________________________

Из сего видно что блокировки по записям нет!!!
Что посоветуете?
Есть ли возможность чтонибудь сделать с постраничным блокированием?
Потому как на уровне программы все сделано грамотно (ИМХО) каждый юзверь отвечает за определенный набор записей... и он один может их апдейтить в определенный момент времени => колизий и DeadLock"ов быт не должно, есть...
Такое может быть тока из за постраничного блокирования! А пишу я это чтоб вы мне сказали правильно ли я мыслю, или вру :)
И посоветуйте чтонибудь ЛЮЮЮДИИИ!!!! :-)

← →
myor (2003-03-17 17:51) [9]

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

← →
BorisUK (2003-03-17 18:01) [10]

> myor © (17.03.03 17:51)

Есть документы к которым нужно создать связь мастер деталь...
Создается первый... идет блокировка на таблицу остатка...
Затем ожидание пока подцепляется список... По итогам этого комит либо ролбак ВСЕГО...
Разве не так?
Вооот... ну а как уде писал..

> Время выполнения процов варьируется в зависимости от наличия/отсутствия
> траблов в сети, загрузке сервака, скорости тачки итд

← →
Sergey13 (2003-03-18 10:14) [11]

2BorisUK © (17.03.03 18:01)
Перед началом транзакции заблокируй все необходимые записи сам. Это делается select ..... for update [Of,NoWait]
Опция NOWAIT позволяет прервать работу если запись уже заблокирована кем либо. Далее по желанию - либо откат либо долбиться в цикле пока не пустит.
Подробнее об этом почитай в доках. У меня сейчас нет под рукой.

← →
myor (2003-03-18 10:31) [12]

2 BorisUK © (17.03.03 18:01)
все равно не очень понятно. юзер должен явно подтвердить/откатить транзакцию. как это ...Время выполнения процов варьируется в зависимости от...а если 2 юзера заблокировали таблицы друг для друга и ждут, пока другой отпустит? нужно чаще делать commit.
ладно, это я чуток отвлекся.
блокировка строки:
lock table <table_name> in share row mode
или
lock table <table_name> in share row exclusive mode
проверяй код транзакций.
если проблема в нехватке ресурсов для блокировки, установи максимальные значения для параметров dml_locks и enqueue_resourses.
если юзеры деруться, увеличь mts_servers, mts_max_servers, mts_dispatchers и mts_max_dispatchers.
проверяй v$lock, dba_blockers, dba_waiters, v$shared_server.

← →
Sergey13 (2003-03-18 11:08) [13]

2myor © (18.03.03 10:31)
>если 2 юзера заблокировали таблицы друг для друга и ждут, пока другой отпустит? нужно чаще делать commit.
Поздно, дядя, пить Боржоми когда печень отвалилась. (не мое)
Commit надо делать не часто, а вовремя. А в этом случае помогает только KILL SESSION 8-)

>lock table <table_name> in share row mode
Вот не советовал бы. Уж пусть сервер сам рулит блокировками. Иначе, ИМХО, можно дофига до чего доблокироваться.

2BorisUK © (17.03.03 18:01)
Посмотри еще наличие индексов на форинкеи. Если из нет - при апдейте главной таблицы будет лочиться вся подчиненная, если есть то только нужные записи.

← →
myor (2003-03-18 12:18) [14]

2 Sergey13 © (18.03.03 11:08)

kill them all!
конечно пусть сам рулит, так ведь пока что-то не очень.
хорошо бы определить стопорящую операцию (может это один юзер одной транзакцией воду мутит), и поковырять ее связи и блокировки.

← →
BorisUK (2003-03-18 12:51) [15]

Спасибо.. тем для размышления много.
Буду пробовать все советы и тестить. Может что еще всплывет.

Блокировки Найти похожие ветки