Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
IDS 7.31 UD8 БД с buffered logging таблица на 11 млн записей, не фрагментирована, 30 столбцов а-ля INTEGER, DATE, DECIMAL время: вчера :) создаю уникальный констрейнт на 9 INTEGER полей этой таблицы Table altered. (!) после этого пытаюсь сделать ещё десяток операций ALTER TABLE ADD CONSTRAINT UNIQUE... CREATE INDEX .... CREATE INDEX .... ... На каждую попытку получаю отлуп следующего содержания: 242: Could not open database table <owner.tablename> 154: ISAM error: Lock Timeout Expired Пользователи с таблицей не работают, внешних ключей пока нет. ? (риторически) Разбирая блокировки видим таки родимую от имени ... daemon thread! Y--PR-D ... (сейчас привести полностью информацию о блокировке и вывод "onstat -u" привести не могу - всё что вспомнил :( - но обещаю попытаться воспроизвести ситуацию в ближайшее время, а также выяснить расклад по onstat -g ath :) после длительных коллективных раздумий - UPDATE STATISTICS LOW FOR TABLE <tablename>; ALTER TABLE ADD CONSTRAINT ... прошло! очередной ALTER TABLE ADD CONSTRAINT ... тот же отлуп с блокировкой :( повторный UPDATE STATISTICS LOW FOR TABLE <tablename>; и опять ALTER TABLE ADD CONSTRAINT ... опять прошло! Теперь вопросы: 1) нет ли УЖЕ идей, что это за daemon thread МОГ БЫТЬ? 2) не прояснит ли кто, почему помогает UPDATE STATISTICS? текущие варианты: а) UPDATE STAT идёт так долго, что daemon thread к моменту окончания таки снимает свою блокировку б) UPDATE STAT "подталкивает" daemon thread к снятию блокировки в) ... П.С.: заранее спасибо за ЛЮБЫЕ идеи :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2006, 17:18 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
HADR есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2006, 17:31 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
Ага, ещё уточнения по поводу идей (МЫСЛИ ВСЛУХ): в) Включена HADR! в логе обнаружилось 00:14:17 Checkpoint Completed: duration was 2 seconds. 00:14:17 Checkpoint loguniq 131831, logpos 0x3474 00:18:36 DR: Sending index <db>:<owner>.<table># 1402_245065 : Started 00:18:51 DR: Sending index <db>:<owner>.<table># 1402_245065 : Completed. 00:19:18 Checkpoint Completed: duration was 1 seconds. 00:19:18 Checkpoint loguniq 131831, logpos 0xa018 может 00:18:36 - 00:18:51 и есть то время, когда informix на primary server держит заблокированной пресловутую таблицу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2006, 17:36 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
АнатоЛойАга, ещё уточнения по поводу идей (МЫСЛИ ВСЛУХ): в) Включена HADR! в логе обнаружилось 00:14:17 Checkpoint Completed: duration was 2 seconds. 00:14:17 Checkpoint loguniq 131831, logpos 0x3474 00:18:36 DR: Sending index <db>:<owner>.<table># 1402_245065 : Started 00:18:51 DR: Sending index <db>:<owner>.<table># 1402_245065 : Completed. 00:19:18 Checkpoint Completed: duration was 1 seconds. 00:19:18 Checkpoint loguniq 131831, logpos 0xa018 может 00:18:36 - 00:18:51 и есть то время, когда informix на primary server держит заблокированной пресловутую таблицу? да-да, именно из-за этого. Я для HADR в скриптах с alter пишу set lock mode to wait; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2006, 17:46 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
ТанЯ для HADR в скриптах с alter пишу set lock mode to wait; И в очередной раз "Моё почтение!" :) Эта идея оказалась ОЧЕНЬ своевременной! А DEADLOCK_TIMEOUT не беспокоит при работе с HADR? То есть, не возникало ли ситуаций, когда создание индекса на вторичном сервере длится больше, чем DEADLOCK_TIMEOUT на первичном? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2006, 18:50 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
АнатоЛойАга, ещё уточнения по поводу идей (МЫСЛИ ВСЛУХ): в) Включена HADR! ...Че-то там с хадром у них не так. Мы однажды с Тан сильно попали, до 4-х утра индексы пересоздавали. Т.е. дропаешь индексы, создаешь 1-й (за 20 мин.) он начинает передаваться, сидишь куришь 2 часа (он передается в 5 раз дольше чем создается) создаешь следующий. При этом если секондари погасить, создаешь 1-й, 2-й, 3-й индексы, включаешь секондари они начинают передаваться. При всем при том что теперь индексы создаются онлайн -- таблица не блокируется для читающих. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2006, 20:25 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
АнатоЛой... А DEADLOCK_TIMEOUT не беспокоит при работе с HADR? DEADLOCK_TIMEOUT к хадр отношения не имеет абсолютно никакого. Это параметр предотвращающий длительные блокировки при distributed транзакциях (insert into d:t@remoteserver ...). DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env. Крайне неудачное название кстати, к обычным DEADLOCKs отношения никакого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2006, 20:45 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
Журавлев ДенисКрайне неудачное название кстати, к обычным DEADLOCKs отношения никакого. Как сказать. Сервер должен обязательно иметь механизм по распознаванию дидлоков. При работе на одном сервере он просматривает для этого таблицы блокировок разных запросов и сравнивает их на предмет пересечения. Другой сервер не имеет никакой возможности посмотреть блокировки на другом серваке (это м.б. огромные объемы, да еще и требуемые очень часто, чтобы передавать их постоянно по сети), поэтому решили по простому - если от сервака ответ не пришел в течении такого то времени, то значит там какая то неразрешимая блокировка (типа дидлока), которая не дает возможности выполниться удаленному запросу. Значит надо рубить текущий запрос, чтобы ситуация не подвисла и не вышла из под контроля :) Конечно, ответ может задержаться по разным причинам (просто 2-й сервер перегружен работой или медленная сетка), поэтому время DEADLOCK_TIMEOUT устанавливают достаточно большим (по умолчанию 60) и на медленных сетях и объемных запросах рекомендуют его увеличивать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2006, 21:42 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
vasilis Как сказать. Сервер должен обязательно иметь механизм по распознаванию дидлоков. При работе на одном сервере он просматривает для этого таблицы блокировок разных запросов и сравнивает их на предмет пересечения. Другой сервер не имеет никакой возможности посмотреть блокировки на другом серваке (это м.б. огромные объемы, да еще и требуемые очень часто, чтобы передавать их постоянно по сети), поэтому решили по простому - если от сервака ответ не пришел в течении такого то времени, то значит там какая то неразрешимая блокировка (типа дидлока), которая не дает возможности выполниться удаленному запросу. Значит надо рубить текущий запрос, чтобы ситуация не подвисла и не вышла из под контроля :) Конечно, ответ может задержаться по разным причинам (просто 2-й сервер перегружен работой или медленная сетка), поэтому время DEADLOCK_TIMEOUT устанавливают достаточно большим (по умолчанию 60) и на медленных сетях и объемных запросах рекомендуют его увеличивать.Василь, я с тобой абсолютно согласен, и что это deadlock и что по другому этот дидлок не найти. Только назвать надо было distributed_transaction_timeout. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2006, 08:41 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис АнатоЛойАга, ещё уточнения по поводу идей (МЫСЛИ ВСЛУХ): в) Включена HADR! ...Че-то там с хадром у них не так. Мы однажды с Тан сильно попали, до 4-х утра индексы пересоздавали. Т.е. дропаешь индексы, создаешь 1-й (за 20 мин.) он начинает передаваться, сидишь куришь 2 часа (он передается в 5 раз дольше чем создается) создаешь следующий. При этом если секондари погасить, создаешь 1-й, 2-й, 3-й индексы, включаешь секондари они начинают передаваться. При всем при том что теперь индексы создаются онлайн -- таблица не блокируется для читающих. индексы стало можно создавать онлайн только в 10, а тогда у нас еще 9.3 был ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2006, 09:40 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
Тан... индексы стало можно создавать онлайн только в 10, а тогда у нас еще 9.3 былЯ помню, у меня не такой сильный склероз пока. Просто я так понимаю муру с передачей (которая длится дольше чем создание, и блокирует таблицу) на секондари все еще не пофиксили, даже в 10-ке (где можно создавать индексы не только онлайн, но и передавать индексы с секондари на праймари). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2006, 09:51 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Тан... индексы стало можно создавать онлайн только в 10, а тогда у нас еще 9.3 былЯ помню, у меня не такой сильный склероз пока. Просто я так понимаю муру с передачей (которая длится дольше чем создание, и блокирует таблицу) на секондари все еще не пофиксили, даже в 10-ке (где можно создавать индексы не только онлайн, но и передавать индексы с секондари на праймари). помнишь, но про это не написал. По-моему, это важно. последний раз (10.00.FC4) делала alter fragment для 110 мб таблицы и 5 ее индексов, каждый по 100 мб. времени ушло 6 минут, причем индексы передались 2 раза - сначала они перестраивались при переносе таблицы, а потом они переезжали в другой dbspace ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2006, 10:11 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
Танпомнишь, но про это не написал. По-моему, это важно.Ок, согласен. Танпоследний раз (10.00.FC4) делала alter fragment для 110 мб таблицы и 5 ее индексов, каждый по 100 мб. времени ушло 6 минут, причем индексы передались 2 раза - сначала они перестраивались при переносе таблицы, а потом они переезжали в другой dbspaceТ.е. передачу ускорили, а блокирование на время передачи осталось? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2006, 10:52 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Танпоследний раз (10.00.FC4) делала alter fragment для 110 мб таблицы и 5 ее индексов, каждый по 100 мб. времени ушло 6 минут, причем индексы передались 2 раза - сначала они перестраивались при переносе таблицы, а потом они переезжали в другой dbspaceТ.е. передачу ускорили, а блокирование на время передачи осталось? не знаю, ускорили или нет. Какого размера таблицы и индексы были тогда (на 9.3), я не помню А блокирование осталось. Но мы не делаем CREATE INDEX ... ONLINE, мы делаем alter fragment ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2006, 11:17 |
|
||
|
Блокировка таблицы demon thread
|
|||
|---|---|---|---|
|
#18+
Журавлев ДенисВасиль, я с тобой абсолютно согласен, и что это deadlock и что по другому этот дидлок не найти. Только назвать надо было distributed_transaction_timeout. Я тоже абсолютно с тобой согласен :) И я бы многие названия параметров из onconfig поменял на более понятные и запоминающиеся, а то ни произнести вслух ни написать по памяти правильно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2006, 13:04 |
|
||
|
|
start [/forum/topic.php?fid=44&msg=34065077&tid=1608578]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
79ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 257ms |
| total: | 459ms |
| 0 / 0 |
