|
И опять блокировки
|
|||
---|---|---|---|
#18+
Добрый день всем! ASE 15 Проблема такая: Есть таблица(0.5 млн записей). Есть процедура, которая по расписанию апдэйтит в ней 90% записей. Работает процедура примерно 1 мин. Но с этой таблицей еще работает куча юзеров(insert, delete, update). Когда процедура запускается, таблица эксклюзивно блокируется и все юзеры могут идти курить примерно на одну минуту. Это и вызывает проблемы. Не проходит даже insert, хотя таблица с построчной блокировкой. Так как апдэйтиться почти вся таблица блокировка эскалирует до табличной. Может как-то можно порешать эти проблемы? Временем апдэйтовой процедуры можно пренебречь, ну если сейчас она работает 1 мин, то не будет проблем, если она будет работать 10 мин. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2010, 19:30 |
|
И опять блокировки
|
|||
---|---|---|---|
#18+
_devel wrote: > Есть таблица(0.5 млн записей). Есть процедура, которая по расписанию > апдэйтит в ней 90% записей. Работает процедура примерно 1 мин. Но с этой > таблицей еще работает куча юзеров(insert, delete, update). Когда > процедура запускается, таблица эксклюзивно блокируется и все юзеры могут > идти курить примерно на одну минуту. Это эскалации блокировок. Это и вызывает проблемы. Не > проходит даже insert, хотя таблица с построчной блокировкой. Так как > апдэйтиться почти вся таблица блокировка эскалирует до табличной. А это просто решается. Берёте таблицу, делаете её на DPL или DRL, и укручиваете эскалацию блокировок почти в 0. Т.е. чтобы эскалация никогда не происходила. Только при этом надо под локи выделить больше памяти, (number of locks), потому что жрать их будет сервак немилосердно (вместо одного лока на всю таблицу будут по локу на страницу или по локу на запись). При этом insert, delete, update будут пролетать на этой таблице на ура, никому ваш фоновый UPDATE мешать не будет. Но это на DRL-таблице. DPL таблица будет немного компромиссным вариантом, поскольку тут конфликты возможны, но зато локов меньше (в число строк на странице раз). Будет хорошо, если это возможно, разбить один большой UPDATE на маленькие пачки по N строк где N что-то типа 1000 - 5000. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2010, 23:26 |
|
И опять блокировки
|
|||
---|---|---|---|
#18+
_devel Я бы эскалацию бы не трогал! Много блокировок = много памяти. А вот разбить на несколько updae-ов, как советует MasterZiv, это наилучший выход. Также обезопасите себя от переполнения лога. Это можно сделать курсором, хотя я не уверен! Курсор может накладывать блокировку не на одну строку, которая изменяется, а на всю выборку, по которой бежит курсор. Это надо проверять!!! Но не что не мешает сделать это циклом(while), @@rowcount, и select top(в ASE 15 top есть). ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2010, 08:47 |
|
И опять блокировки
|
|||
---|---|---|---|
#18+
MasterZiv, cherrex_Den А можно пример такого Update? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2010, 09:15 |
|
И опять блокировки
|
|||
---|---|---|---|
#18+
cherrex_Den select top(в ASE 15 top есть). с 12.5.3 есть ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2010, 10:01 |
|
И опять блокировки
|
|||
---|---|---|---|
#18+
_devel wrote: > А можно пример такого Update? set rowcount 1000 update theTable set ... where <условие> set rowcount 0 Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2010, 19:41 |
|
И опять блокировки
|
|||
---|---|---|---|
#18+
_develДобрый день всем! ASE 15 Проблема такая: Есть таблица(0.5 млн записей). Есть процедура, которая по расписанию апдэйтит в ней 90% записей. Может быть посмотреть в сторону изменения структуры базы? Что именно обновляется в таблице? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2010, 22:32 |
|
|
start [/forum/topic.php?fid=55&msg=36814061&tid=2010533]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
52ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 141ms |
0 / 0 |