Спасайте уважаемые гуру!

ASA 11.0.1

E. 03/19 11:15:42. *** ERROR *** Assertion failed: 106200 (11.0.0.1562)
Unable to undo index changes during rollback
I. 03/19 11:16:09. Recovery complete
E. 03/19 11:16:09. Internal database error *** ERROR *** Assertion failed: 106
Unable to undo index changes during rollback -- transaction rolled back
I. 03/19 11:16:24. Database server shutdown due to startup error

был сломан индекс в таблице как я понимаю, т.е.
Insert - ошибка что такой Primary Key есть, rollback - Assertion failed: 106200 (11.0.0.1562) - сервер остановлен.

Как теперь поднять базу?

проблема в том что эта база включена в обмен.
Есть ли способ запустить ее (например без лога) - перестроить индекс и снова подсунуть ей лог по которому она отрековерится? Главное что бы все смещения по логу сохранились (для обмена)

в общем-то я и поднимаю пока ее из бэкапа ... только процесс идет уже 4 часа ;(
Нервирует то что не видно сколько осталось и сколько сделано ;(
Загрузка одного проца 100% ... финт потиху шуршит ...
(лог 300 метров. база 35 гигов) ...

У кого был опыт такого восстановления БД?
(с размером базы более 20 гигов)

Сколько это заняло времени? на сейчас уже 6-ть часов молчания в логе сервера и 100% загрузки проца. Очень надеюсь что он (процесс) не завис ;(

Значит где-то что-то я делал не так (хотя трудно ошибиться в одной команде на выполенение)

Итог - 24 часа спустя после старта накатывания лога процессы были убиты на двух машинах.
Активность процессора 100%, активность винта - только чтение, 0-16кб в минуту.

Данный вид восстановления не помог. После того как восстановлю работу БД - буду пробовать восстановить (надо же понять что и как и где и почему не хочет восстанавливаться).

Мелкий эксперимент с логом 10 мегов (на этой же базе, просто взят был другой бэкап - проделаны эмуляция работы что бы лог накопился ...) накатился за 30 минут и все заработало.

Как будут результаты - отпишусь.

Результаты:
1. За 4 дня стандартная функция восстановления "применение лога на бэкап" так и не отработала
2. Репликация была восстановлена следующим образом
- Поднят последний бэкап
- оттранслирован лог поломанной базы (получилось чуть больше 1 гига sql)
- применен этот sql на бэкапе (к сожалению, пришлось вмешиваться в процесс применения, т.к. по какой-то причине не всегда соблюдался правильная последовательность sql команд, особенно это касается тригеров. Например, в логе команды на удаление из master table шло раньше чем удаление из slave - приходилось ручками помогать базе. Поэтому этот процесс занял много времени) В результате получили базу с синхронными данными. НО! Запустить обмен невозможно, т.к. мы не применяли транзакции по которым был Rollback, т.е. смещене лога полученное ну никак не совпадает с тем что было (текущее смещение меньше чем было).

- меняем смещения в sysRemoteUser на текущие
- запускаем обмен
- обламываемся, не смотря на то что мы установили новые смещения база удаленная отказалась принимать письма мотивирую тем что "пришло меньшее смещение чем было подтверждено ранее".

Как заставить забыть ту базу о том, что было подтверждено - не нашли. Все что было в документации не помогло, видать где-то еще спрятали эту цифру.

- запустили процедуру которая выполняет безобидные действия (вставка - удаление из таблицы) - цель этой процедуры догнать смещение лога до цифры большей чем было.

- Второй запуск обмена - все прошло успешно. Обмен пошел, ошибок нет.

Осталось выяснить один вопрос - почему не смотря на принудительную установку смещений (SYS.sa_setremoteuser) в обоих базах, подчиненная база не забыла предыдущее подтвержденное значение и упорно желала получить данные именно с него или позднее.

P.S. После ряда тестов именно на нашей БД комбинация из:
Win2008 64bit + 16Kb cluster disk + 16 kb page size DB = Internal database error *** ERROR *** Assertion failed: 106 Unable to undo index changes during rollback

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

Удачная комбинация: Win2008 64bit + 8Kb cluster disk + 8 kb page size DB = нормальная работа.

один из тестов выглядел так:
Win2008 64 bit

исходная база - dbunload -ar 8192
исходная база - dbunload -ar 16384

Получаем две абсолютно одинаковые БД отличающиеся только размером страницы.

Два диска - один форматируем под 16Кб второй под 8Кб.

Запускаем базы с абсолютно одинаковыми параметрами. Начинаем накатывать sql (см выше).

Результат 16Kb cluster disk + 16 kb page size:
Ошибки индексов (много). После каждой ошибки делаем rebuild индексу и продолжаем. В конечном счете получаем Assertion и упавшая база.

Результат 16Kb cluster disk + 16 kb page size:
Отработал скрипт без ошибок.

Результат 16Kb cluster disk + 8 kb page size:
Отработал скрипт без ошибок но медленне

Результат 8Kb cluster disk + 16 kb page size:
Ошибки индексов (много). После каждой ошибки делаем rebuild индексу и продолжаем. В конечном счете получаем Assertion и упавшая база.

Повторить на "маленькой тестовой базе" не удалось. Видимо тут играет роль и кол-во данных...

Прошу прощения за опечатку!!!

Запускаем базы с абсолютно одинаковыми параметрами. Начинаем накатывать sql (см выше).

Результат 16Kb cluster disk + 16 kb page size:
Ошибки индексов (много). После каждой ошибки делаем rebuild индексу и продолжаем. В конечном счете получаем Assertion и упавшая база.

(вот тут опечатался)
Результат 8Kb cluster disk + 8 kb page size:
Отработал скрипт без ошибок.

Результат 16Kb cluster disk + 8 kb page size:
Отработал скрипт без ошибок но медленне

Результат 8Kb cluster disk + 16 kb page size:
Ошибки индексов (много). После каждой ошибки делаем rebuild индексу и продолжаем. В конечном счете получаем Assertion и упавшая база.

Повторить на "маленькой тестовой базе" не удалось. Видимо тут играет роль и кол-во данных...

To White Owl

То что опасная это факт, но у меня не было другого выбора ...

По смещению приводу пример утрированный.

Slave - подтвердила от Master принятие лога со смешением 99999

меняю на обоих сторонах что
Master выслал и получил подтверждение о получении на смещение 88888
call SYS.sa_setremoteuser(117,88888,88888,2322,5,011756868999,011756868999,3602,19); commit;

Slave получил и отослал подтверждение о получении лога 88888
call SYS.sa_setremoteuser(102,011756868999,011756868999,3602,19,88888,88888,2322,5); commit;

Все сообщения убиты. Запускаю сначала обмен на Master - ушло сообщение.
Запускаю на Slave - принято и apply сообщения от Master, сканирование лога - отправка сообщения
Запускаю снова на Master - ошибка - типа удаленная база ожидала лог со смещением 99999 а получила 88888. разумеется смещения 99999 в Master еще нет и обмен отваливался.

Если поменять порядок запуска то Master принимает данные, сканирует лог - отправляет - Slave принимает - отправляет - Master снова падает с ошибкой "типа удаленная база ожидала лог со смещением 99999 а получила 88888".

А вот если догнать лог до 199999 (т.е. больший чем был) - то никаких проблем, обе базы сразу соглашаются с новыми значениями смещения.

To Ggg_old
Сегодня, спустя 4 дня я пристрелил последний процесс накатки. Нет - это процесс что-то делал, т.к. загрузка проца 100% и периодически читает-пишет на диск (примерно 16К в минуту, т.е. как раз одну страницу БД).

На 11-й есть еще проблемы ;(
Сейчас столкнулся с непонятными тормозами в запросе который на старом EBF работал быстро, что-то подправили в оптимизаторе в очередной раз. Пришлось переписать запрос и сделать его процедурой - отработал быстро (даже быстрее чем было ;))

White OwlСтоп! В этот момент, в мастере уже существует реальный чекпоинт на 88888?

"Стаю ... баюсь ..." :)

Этот чекпоинт получен путем остановки базы и натравливания на лог базы утилиты dblog - циферки взяты из нее.

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

Приведу пример из реальной жизни своей ...

пришло сообщение от удаленной базы. Около 300 коротких транзакций. (сделаны изменения были максимум в течении минуты, т.е. 100% внутри одного чекпоинта)

Но на горе для этого сообщения произошла ошибка и применение было прервано примерно посередине (у меня принудительная остановка обмена в случае ошибки).

Так вот - смещенее отосланное моей базой в удаленную (после того как база поняла что следующие сообщения не то что надо и сказала missing) было как раз то самое число которое указывает на транзакцию следующую за ошибочной (за той где была ошибка). Это я специально проверял натравливая dbtran на лог удаленной базы.

Если бы обмен шел только чекпоинтами то больший куски данных просто бы терялись ...

Про то что посылаются именно смещения относительно COMMIT (завершенной транзакции) я вывел из SQL_Remote_User_Guide (глава 10. Администрирование SQL Remote) (лень переводить английский - проще для цитирования скопировать русский) и личных наблюдений.

"В столбце log_sent содержится смещение в локальном журнале транзакций для
последнего сообщения, отправленного подписчику. При отправке сообщения Message Agent устанавливает значение log_sent в значение смещения последнего оператора COMMIT в сообщении."

"sp_remote: Данная команда активизирует все подписки для удаленного пользователя в одной
транзакции. Она задает значения log_sent и confirm_sent в таблице sr_remoteuser
в соответствии с текущей позицией в журнале транзакций."

про Check point в руководстве ни слова (ни слова в связке с SQL Remote)

Значит стоит непонятная защита внутри SyBase куда нам простым смертным админам нет доступа ;( (защита от ...?)
Поменять в меньшую сторону дает через процедуру но при первом же обмене возвращает значение обратно. Что на Master что на Slave базах.