Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
21.10.2010, 20:19
|
|||
---|---|---|---|
|
|||
Строчные блокировки |
|||
#18+
ASE 15 Может конечно глупость спрашиваю, но... Есть таблица с построчной блокировкой, делаем update на уровне изоляции 1, который работает 4сек. В момент update-а смотрим monLock и видим много построчных блокировок. Вопрос: Почему ASE держит построчные блокировки до конца транзакции, уровень изоляции же 1??? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
22.10.2010, 12:38
|
|||
---|---|---|---|
Строчные блокировки |
|||
#18+
On 21.10.2010 21:19, _devel wrote: > Есть таблица с построчной блокировкой, делаем update на уровне изоляции 1, > который работает 4сек. В момент update-а смотрим monLock и видим много > построчных блокировок. > Вопрос: Почему ASE держит построчные блокировки до конца транзакции, уровень > изоляции же 1??? Для обеспечения целостности данных он держит. UPDATE работает вообще-то на уровне изоляции 0, и обязан держать эксклюзивную WRITE-блокировку до конца транзакции. Так все СУБД поступают, если они ACID поддерживают. Если этого не делать, автоматом получится несериализуемая транзакция. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
23.10.2010, 06:58
|
|||
---|---|---|---|
Строчные блокировки |
|||
#18+
_devel, By definition of level 1 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
23.10.2010, 14:00
|
|||
---|---|---|---|
Строчные блокировки |
|||
#18+
On 23.10.2010 7:58, Zhora wrote: > _devel, > > By definition of level 1 Только не 1, а 0. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.02.2011, 12:59
|
|||
---|---|---|---|
|
|||
Строчные блокировки |
|||
#18+
У меня еще один вопрос такого же плана, ASE 15.0.3 , уровень изоляции 1, построчная блокировка. Один запрос делает select, сканируя индекс на таблице, накладывает shared блокировки на строки, а потом, насколько я понимаю срабатывает ескалация и я вижу sh_table. Второй такой - же запрос тоже сканирует этот же индекс и тоже пытается наложить sh_table, но у первого запроса появляется Sh_table-blk. Второй select блокируется первым. Выходит нельзя одновременно накладывать 2-е и более Sh_table блокировки ? Ткните в доку, пожалуйста, а то не могу найти. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.02.2011, 14:29
|
|||
---|---|---|---|
|
|||
Строчные блокировки |
|||
#18+
Или по-другому, откуда берутся Sh_table-blk блокировки ? Насколько я понимаю, они выставляются, когда shared блокировка таблицы конфликтует с блокировкой, которую другой процесс хочет наложить на эту таблицу. Но как два select-а могут конфликтовать ??? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.02.2011, 19:52
|
|||
---|---|---|---|
|
|||
Строчные блокировки |
|||
#18+
bamka, Два select-а не могут конфликтовать!!!! Покажите запросы и DDL таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.02.2011, 21:00
|
|||
---|---|---|---|
|
|||
Строчные блокировки |
|||
#18+
cherrex_Den, По-моему я понял в чем дело, осталось протестировать. На сервере работает много отчетов, все они readonly. Но есть еще репликация (это standby), которая в момент "общего капута" тоже была заблокирована первым отчетом. Получается что сами по себе отчеты друг друга не блокируют, но после того как первый отчет заблокировал реплику(и это естественно, так как отчет держал Sh_tablel lock), его Sh_tablel lock превратился в Sh_tablel-blk. И вот теперь он блокирует не только реплику, но идругие readonly отчеты, так как они хотят наложить Sh_tablel lock а там уже Sh_tablel-blk. Сбивало с толку то, что в процессах показывает readonly отчеты, заблокированы readonly отчетом. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
17.02.2011, 00:49
|
|||
---|---|---|---|
Строчные блокировки |
|||
#18+
On 16.02.2011 12:59, bamka wrote: > Один запрос делает select, сканируя индекс на таблице, накладывает shared > блокировки на строки, а потом, насколько я понимаю срабатывает ескалация и я > вижу sh_table. Вообще эскалация Shared-ов -- это что-то странное. Sh-локи снимаются тут же после чтения. Что их эскалировать ? Есть правда режим принудительного оставления Shared-ов, тогда разве что. Но его редко кто использует. > Второй такой - же запрос тоже сканирует этот же индекс и тоже пытается наложить > sh_table, но у первого запроса появляется Sh_table-blk. Второй select > блокируется первым. Не бывает такого. Ты что-то путаешь или неправильно интерпретируешь. > Выходит нельзя одновременно накладывать 2-е и более Sh_table блокировки ? Да я сам тебе скажу. Sh - lock-и друг с другом совместимы. Не совместимы они с Upd и Ex. Найди в доке таблицу совместимости блокировок. Можно в русской так и искать прямо. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
17.02.2011, 00:56
|
|||
---|---|---|---|
Строчные блокировки |
|||
#18+
On 16.02.2011 14:29, bamka wrote: > Или по-другому, откуда берутся Sh_table-blk блокировки ? > Насколько я понимаю, они выставляются, когда shared блокировка таблицы > конфликтует с блокировкой, которую другой процесс хочет наложить на эту таблицу. Значить для начала блокировки Sh_table-blk не существует. Есть Sh_(row-page-table) и признак того, что блокировка кому-то мешает. При установленном этом признаке ASE добавляет суффикс "blk". Sh_(row-page-table)-blk -- это любая Sh-блокировка, которая мешает получить кому-то другие блокировки на этот же ресурс. Это могут быть Upd-(row-page-table) или Ex-(row-page-table) Ещё есть Upd-Intent, ей тоже может мешать Sh-блокировка, но только некоторое время. Потом Upd-Intent преобразуется в Upd-Demand и "побеждает" Sh. > Но как два select-а могут конфликтовать ??? В смысле, два Shared-а ? Никак не могут. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
17.02.2011, 00:57
|
|||
---|---|---|---|
Строчные блокировки |
|||
#18+
On 16.02.2011 21:00, bamka wrote: > По-моему я понял в чем дело, осталось протестировать. Вряд ли. Не получается стройной картинки у тебя. Read-only запросы не могут себя блокировать никогда. Они могут блокировать только модифицирующие запросы. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
17.02.2011, 11:45
|
|||
---|---|---|---|
|
|||
Строчные блокировки |
|||
#18+
MasterZiv, Может быть я что-то и упускаю ... Попробую еще раз. - Запускается отчет, соединяет таблицы с помощью MERGE JOIN, таблицы большие, поэтому срабатывает эскалация и Sh_table удерживается пока все данные запишутся в worktable merge join-а. (Или тут эскалация не должна срабатывать, а Sh_row должны сниматься по мере копирования данных в worktable ?) - Появляется реплика и хочет установить конфликтирующую Ex блокировку. Ждет. - Запускаются еще несколько отчетов, которые тоже хотят наложить на Sh_table. 2 из них реплика пропускает, а после третьего, лезущего вне очереди, устанавливает Ex_(table/row)-demand-blk (blk потому что есть еще несколько отчетов в очереди на Sh_(table/row) после реплики. ). Хотя в этом случае остальные отчеты (после 3-го в очереди) должны быть заблокированы репликой, а не первым отчетом .... sp_who показывает что все процессы заблокированы именно первым отчетом. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
17.02.2011, 15:33
|
|||
---|---|---|---|
Строчные блокировки |
|||
#18+
On 17.02.2011 11:45, bamka wrote: > - Запускается отчет, соединяет таблицы с помощью MERGE JOIN, таблицы большие, > поэтому срабатывает эскалация и Sh_table > удерживается пока все данные запишутся в worktable merge join-а. Вот не должна вроде бы эскалация срабатывать. Я же говорю, Shlock снимается сразу же после чтения строки/страницы, зачем ему эскалироваться? Эскалация происходит когда кол-во локов увеличивается. Возможно, конечно, merge join их держит дольше, я не очень в курсе. (Или тут > эскалация не должна срабатывать, а Sh_row должны > сниматься по мере копирования данных в worktable ?) Должна по идее сниматься после чтения каждой строки/страницы. Чтение вообще обысно идёт так: накладывается Sh на строку/страницу, читается строка/страница, накладывается Sh на следующую строку/страницу, снимается Sh с предыдущей строки/страницы, читаются данные, и т.д. > - Появляется реплика и хочет установить конфликтирующую Ex блокировку. Ждет. С чего это она хочет ? Что она делает ? INSERT-ы ? UPDATE-ы ? DELETE_ы ? > - Запускаются еще несколько отчетов, которые тоже хотят наложить на Sh_table. 2 > из них реплика пропускает, а после третьего, > лезущего вне очереди, устанавливает Ex_(table/row)-demand-blk (blk потому что > есть еще несколько отчетов в очереди на > Sh_(table/row) после реплики. ). ОК, где же там читатели, блокирующие читателей ? > Хотя в этом случае остальные отчеты (после 3-го в очереди) должны быть > заблокированы репликой, а не первым отчетом .... > sp_who показывает что все процессы заблокированы именно первым отчетом. Это можнет быть просто особенностью показа. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
26.02.2011, 20:50
|
|||
---|---|---|---|
|
|||
Строчные блокировки |
|||
#18+
спасибо, нашёл то, что нужно ... |
|||
:
Нравится:
Не нравится:
|
|||
|
01.03.2011, 13:38
|
|||
---|---|---|---|
|
|||
Строчные блокировки |
|||
#18+
MasterZiv, Спасибо за помощь, так и есть - то просто особенность отображения блокировок (как в Sybase Central так и в sp_who). Читающих блокировала реплика, которая ожидала возможности поставить эксклюзивную блокировку, а Central и sp_who показывали что блокирует select (а он держал Sh_table lock). ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=55&mobile=1&tid=2010394]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
53ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 297ms |
total: | 449ms |
0 / 0 |