|
Действия ...
|
09.03.2004, 17:24
|
|||
|---|---|---|---|
|
|||
Построчная блокировка в таблицах c разм < page_size |
|||
|
|
|
09.03.2004, 18:04
|
|||
|---|---|---|---|
|
|||
Построчная блокировка в таблицах c разм < page_size |
|||
|
|
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
09.03.2004, 09:55
|
|||
|---|---|---|---|
|
|||
Построчная блокировка в таблицах c разм < page_size |
|||
|
#18+
Возникла следующая проблема: таблица с lock mode row, первоначально данные занимают меньше PAGE SIZE'а (2kb). При эксклюзивной (update) блокировке одной строки блокируются все данные таблицы (244: Could not do a physical-order read to fetch next row. 107: ISAM error: record is locked.). При объёме данных больше одной страницы и выполнении update statistics high for table ... блокировка становится действительно построчной. Далее, возвращаемся к объёму данных < 2кб - всё работает корректно. Выполненяем update statistics high for table ... и снова выходим на (244: Could not do a physical-order read to fetch next row. 107: ISAM error: record is locked.) Как побороть эту ошибку на малых объёмах ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.03.2004, 09:59
|
|||
|---|---|---|---|
|
|||
Построчная блокировка в таблицах c разм < page_size |
|||
|
#18+
Добавлю: Informix Dynamic Server 2000 Version 9.21.UC4 UnixWare 5 7.1.1 i386 x86at SCO UNIX_SVR5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.03.2004, 17:24
|
|||
|---|---|---|---|
Построчная блокировка в таблицах c разм < page_size |
|||
|
#18+
Проблема скорее всего в том, что оптимизатор считает, что на маленькой табличке проще выполнить данную операцию через seqscan, а не через index. Обойти можно указав директивы оптимизатору на принудительное использование индекса. Мониторить, как именно хочет сделать этот апдейт сервер - через set expalin on. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.03.2004, 18:04
|
|||
|---|---|---|---|
|
|||
Построчная блокировка в таблицах c разм < page_size |
|||
|
#18+
авторПроблема скорее всего в том, что оптимизатор считает, что на маленькой табличке проще выполнить данную операцию через seqscan, а не через index. Обойти можно указав директивы оптимизатору на принудительное использование индекса. Когда на маленькой табличке создается индекс, информикс не блокирует эту табличку эксклюзивно, поэтому у меня возникает вопрос, а создается ли индекс вообще? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.03.2004, 18:59
|
|||
|---|---|---|---|
|
|||
Построчная блокировка в таблицах c разм < page_size |
|||
|
#18+
Ну если его заставлять директивами оптимизатора использовать этот индекс, то он его и на маленькой таблице таки использует. Сам на этот эффект sequential scan'а попадал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=44&tablet=1&tid=1609311]: |
0ms |
get settings: |
7ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
58ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 11ms |
| total: | 141ms |
| 0 / 0 |
