Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
21.04.2004, 14:53
|
|||
|---|---|---|---|
|
|||
порядок восстановления индексов |
|||
|
#18+
Нужна помощь. 1. Эксплуатируется Informix9.2 под Linux 2.2х. В БД существует довольно большая таблица. Иногда происходит неконтролируемой сбой ("портятся индексы"), так что при работе с таблицей время отклика увеличивается на порядки для статистических выгрузок. Подскажите порядок восстановления индексов. Есть ли специальные утилиты типа repaire table или надо сначала остановить сервис, скопировать таблицу, воссоздать ее заново (drop table + create table) и скопиравать данные назад. Данные очень критичные. Может кто-то составлял подобную инструкцию для сисадминов по действию в подобных случаях. Я не специалист в БД, поэтому буду очень признателен за любое руководство в данном вопросе. 2. Имеет ли смысл перейти на более свежую версию Informix? И есть ли такие?Насколько велик риск проблем (потеря данных и т.д.) и на какое время придеться остановить сервис. Заранее благодарен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.04.2004, 15:31
|
|||
|---|---|---|---|
|
|||
порядок восстановления индексов |
|||
|
#18+
автор1. Эксплуатируется Informix9.2 под Linux 2.2х. В БД существует довольно большая таблица. Иногда происходит неконтролируемой сбой ("портятся индексы"), Как проявляется сбой? Что ты под этим подразумеваешь? По моему дело совсем не в индексах. автортак что при работе с таблицей время отклика увеличивается на порядки для статистических выгрузок Надо смотреть план запроса. Только он покажет объективную реальность. А возможно запрос натыкается на блокировки, ждет ресурсов PDQ, ..... Индексы можно пересоздавать не "трогая" таблицу, drop index -> create index. "Утилиту" для себя я написал, но она использует утилиту myschema Арта Кагеля из набора utils2_ak, если сможешь ее собрать то вот мой скрипт: в файл ix_rebiuld.lst помести список таблиц индексы которых хочешь пересоздать, в файле index.sql получишь скрипт для пересоздания. Переменная FHOST - имя информикс сервера, FDB - имя базы. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.04.2004, 15:38
|
|||
|---|---|---|---|
порядок восстановления индексов |
|||
|
#18+
1. Из чего видно, что индексы "портятся" ? Увеличение время отклика - это не есть признак. 2. Для проверки целостности базы используется утилита oncheck. 3. Для приведение планов запросов в порядок необходимо выполнять update statistics для таблиц и процедур на регулярной основе. 4. Для просмотра плана запроса необходимо перед выполнением его сказать set explain on; после начала выполнения запроса смотреть план запроса в файле sqexplain.out в текущем каталоге (если запрос идет через сеть, то текущим катологом скорее всего будет $HOME). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.04.2004, 23:09
|
|||
|---|---|---|---|
|
|||
порядок восстановления индексов |
|||
|
#18+
ОК. Спасибо за ответ. Я постараюсь разобраться в причинах. Внешние признаки такие: доступ к таблице (в ней содержится информация о транзакциях клиентов) становится затрудненным, а именно: 1. Определенные транзакции (клиентов) вообще не удается просмотреть 2. Соответственно процедуры статистики (которые работают по всем записям таблицы) не выполняются успешно. Такая ситуация происходит редко (раз в полгода), но хотелось бы зафиксить эту проблему. И еще: у нас два сервера Информикс (одинаковая версия) и проблемы бывают на обоих базах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.04.2004, 08:54
|
|||
|---|---|---|---|
|
|||
порядок восстановления индексов |
|||
|
#18+
авторОК. Спасибо за ответ. Я постараюсь разобраться в причинах. Внешние признаки такие: доступ к таблице (в ней содержится информация о транзакциях клиентов) становится затрудненным, а именно: 1. Определенные транзакции (клиентов) вообще не удается просмотреть 2. Соответственно процедуры статистики (которые работают по всем записям таблицы) не выполняются успешно. Информикс блокировочник, т.е. бывают ситуации когда запись(и) в таблице транзакций клиентов блокируются эксклюзивно одной или несколькими сесиями например при редактировании, при этом другие сессии их возможно не смогут прочитать, тогда они отвалятся с ошибкой -154 ISAM error: Lock Timeout Expired. У вас такая ошибка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.04.2004, 09:41
|
|||
|---|---|---|---|
порядок восстановления индексов |
|||
|
#18+
Откуда вы знаете, что проблема в запорченных индексах ? Полную уверенность может дать только oncheck (который может так же и пофиксить индекс, а если нет - то пометить его как запорченный, и он будет пересоздан при рестарте информикса). Если не хотите ждать рестарта - убейте индекс и создайте его заново. Естественно, на время создания таблица будет залочена. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.04.2004, 09:43
|
|||
|---|---|---|---|
порядок восстановления индексов |
|||
|
#18+
Да, 9.2 довольно старая и (была) довольно глючная версия. Возможно, имеет смысл перейти на 9.3 или 9.4. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.04.2004, 09:46
|
|||
|---|---|---|---|
порядок восстановления индексов |
|||
|
#18+
Естественно, как и при любой миграции, данные необходимо забэкапить. Риск, что что-то пойдет не так, невелик, но он есть. При миграции с 9.2 на 9.3 или 9.4 никаких особых внутренних преобразований не делается, так что теоретически вся миграция должна занять минуты. Подробнее описано в руководстве по миграции (см IBM сайт, доки по информиксу). В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.05.2004, 18:29
|
|||
|---|---|---|---|
|
|||
порядок восстановления индексов |
|||
|
#18+
Еще одно: такое явление происходит при некорректном завершении работы сервера. Например, выключение питания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.05.2004, 19:15
|
|||
|---|---|---|---|
порядок восстановления индексов |
|||
|
#18+
Проверьте режим журнализации базы. Если буферизованная журнализация, и (как это бывает по умолчанию в 9.x) используются Fuzzy Checkpoint, то именно это сочетание (по устойчивым слухам) и может быть причиной "порчи" индексов. Отсюда простой рецепт "предотвращения": - перейти на небуферизованную журнализацию (ontape -s -L 0 -U db_name) - отключить Fuzzy Checkpoint (set NOFUZZYCKPT=1) - проверить, не станет ли лучше... Чемберлен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=44&tablet=1&tid=1609275]: |
0ms |
get settings: |
6ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
32ms |
get topic data: |
8ms |
get forum data: |
1ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
| others: | 242ms |
| total: | 358ms |

| 0 / 0 |
