Кто может пояснить разницу в сабже.
cI показывает ошибки на фрагментированной таблице у которой нет rowid.
ci на эту же таблицу говорит, что все нормально.

Informix 7.31 FD10

АнатоЛой,

Спасибо,
а что Вы думаете о прогонах oncheck -cI на secondary сервере?

IDS7.31 FD10

АнатоЛой,

на secondary ловятся ошибки.
Есть мнение что надо останавливать репликацию, но этот вариант мне лично не нравится.
Тестирую на копии восстановленной через ontape

АнатоЛой,

На вторичном сервере на рабочей системе oncheck -cI предлагает пересоздать индекс.

Тестируем копию системы, которая восстановлена с помощью ontape.

про ontape -cI ничего не писал

АнатоЛой,

Копия системы это похожий сервер с аналогичной дисковой подсистемой.
экземпляр восстанавливаем из архива системы, заподозренной в рзвале индексов

АнатоЛой,

Последовательность такова

1. oncheck показывает на вторичном ошибки.
2. На вторичном идут активные изменения данных, остановить репликацию возможности нет. Остановить первичный сервер тоже нельзя.
3.Для проверки наличия ошибок делаю архив уровня 0 и восстанавливаю на отдельном сервере.
4. Проверяю наличие ошибок на восстановленном сервере.

victor16,

там в самом верху написаон, что речь идет о IDS 7.31

АнатоЛой,

>cpr, сформулируйте чётко цели ваших действий.
Выяснить есть ли разрушения индексов. Если есть, то индексы пересоздать.

>> Последовательность такова
>> 1. oncheck показывает на вторичном ошибки.
>На первичном же не показывает, правильно?
На первичном нет возможности запустить oncheck т.к. система постоянно в работе. Время возможного даунтайма посредине рабочей недели значительно меньше времени, требуемого для oncheck -cI. Отсюда и все заморочки.

>> 2. На вторичном идут активные изменения данных,
>??? В смысле, активное использование данных?
Я конечно выразился весьма криво. Возможно здесь все и запутались. Активное изменение данных идет на первичке, а на вторичке данные естественно также меняются вследствии синхронной репликации.

>> остановить репликацию возможности нет.
>Завести пользователей вторичного на первичный точно никак нельзя?
Вторичный сервер read-only и получает на себя строго ограниченный набор запросов на чтение данных. Мое высказывание было сказано к тому, что я не могу себе позволить остановить HADR и чекнуть индексы пока данные на вторичке неизменны.

>> Остановить первичный сервер тоже нельзя.
>Для чего вам это? Чтобы пересоздать индекс на первичном (и, соответственно, индекс пересоздатся на вторичном)?
Объемы слишком большие. У меня в режиме HADR только удаление больших индексов занимает очень долгое время. Для переиндексации больших таблиц HADR разбираем. Вся процедура занимает более суток.

>> 3.Для проверки наличия ошибок делаю архив уровня 0 и восстанавливаю на отдельном сервере.
>Сам архив 0-го уровня вы же снимали с первичного, не так ли?
Ну хоть в чем то нам удалось друг друга понять. С secondary сервера снять архив нулевого уровня физически нельзя.
Архив уровня ноль делается на первичном сервере в период наименьшей нагрузки.

>> 4. Проверяю наличие ошибок на восстановленном сервере.
>Не понимаю, что вам даст результат.
>Что будет, если ошибок на восстановленном вы не найдёте?
В этом весь вопрос. На текущий момент я буду считать что ошибок в индексах нет. Т.к. похоже , что ошибки показанные oncheck-ом на вторичном сервере при работающем HADR ненастоящие.

>И что будет, если ошибки не восстановленном вы найдёте?
Возрадуюсь.

>П.С.: Такое ощущение, что у вас БОЛЬШАЯ запара, и вы суетитесь, вместо спокойного, но эффективного анализа ситуации....
Нет, все как обычно, каков вопрос - таков ответ. У нас как в том анекдоте:
- приборы
- 40
...
- чего 40 ?
- а чего приборы?

Вопрос стоит так :
Исходные данные -
1. IDS 7.31 , HADR
2. Объем БД требует на выполнения oncheck -cID -n например двое суток.
3. Возможное время останова системы в сутки не более нескольких часов.

Вопрос - как хотя бы раз в неделю делать проверку индексов?
Примечание: говорим исключительно о возможностях собственно Informix 7.31.

АнатоЛой,

Спасибо, попробую.
В субботу и воскресенье нагрузка на систему значительно снижается. Если oncheck -cIw не будет мешать работать оставшимся пользователям то шансы есть.

мда
уже более двух суток чекается на копии, которая без нагрузки совсем и еще не закончилось.
Надежды на проверку с опцией w на продуктивной системе стремительно тают

запрос в sysmaster

select round(sum(chksize*2)/(1024*1024)) as size_gb,
round(sum(nfree*2)/(1024*1024)) as free_gb
from syschunks


дает следущее

size_gb free_gb

2174 1080

АнатоЛой,

Причина проверки - падение сервера по причине старого доброго бага mtex.c

АнатоЛой,

Ну и рекомендации регулярной проверки

АнатоЛой,

В общем да. Но забивать не наш метод.
Будем переодически чекать на копии.
А переход к сожалению процесс не быстрый.