Всем привет!

Есть "большая" база ASA 9.02 c высокой степенью фрагментации, которая работает в режиме 24/7 и которую решено перевести на версию 17.

Перевод выполнялся через выгрузку данных утилитой dbunload в новую базу.

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

Из полезного нашел только это

Rebuilding databases involved in synchronization or replication (manual)
https://help.sap.com/viewer/e38b2f6217f24bdb90a3ff8ae57b1dd5/17.0/en-US/819e16296ce21014a17ce2edaf3dc6cf.html?q=dbtran

Но инструкцию я до конца не понял (на всякий, приведу ее ниже)

1. Shut down the database.
2. Perform a full offline backup by copying the database and transaction log files to a secure location.
3. Run the dbtran utility to display the starting offset, ending offset, and current timeline, of the database's current transaction log file.
Note the ending offset and timeline for use in Step 8.

4. Rename the current transaction log file so that it is not modified during the unload process, and place this file in the dbremote offline logs
directory.
5. Rebuild the database.
6. Shut down the new database.
7. Erase the current transaction log file for the new database.
8. Use dblog on the new database with the ending offset and timeline noted in Step 3 as the -z option, and also set the relative offset to
zero.

dblog -x 0 -z 0000698242 -ft timeline -ir -is database-name.db (где 0000698242 - волшебное число после запуска dbtran)

9. When you run the Message Agent, provide it with the location of the original offline directory on its command line.
10. Start the database. You can now allow user access to the reloaded database.

Поправьте меня пожалуйста
1. На п. 3. старая база должна быть обязательно выключена?
2. на п. 8. текущий лог удален, нужно ли подсовывать старый лог с п. 4.? отсюда непонятен последний пункт
3. п.10. с каким логом стартует сконвертированная база, она "поймет" лог версии 9 ?

Когда знаешь, - и вопрос ни о чем, a нет - топчешься на месте ...
Вобщем, очень нужна помощь!

Sergey Orlov,
большое спасибо за отклик.

Да, делал бекап с урезанием лога, поднимал базу из бекапа, и через dbtran, транслировал урезанный и уже увеличенный за сутки
transaction log в sql. Потом применял.

Очень огорчило наличие "странных" ошибок, связанных с кириллицей, хотя в базе cyr1251 и то, что ошибки вообще появляются ...
Их же не было, транзакции-то прошли, и "железно" должны быть в "новой" базе.

Т.е. такой способ инкремента изменений должен был быть простым и надежным, но по факту оказался только простым.
dbtran применял 9-ки к 9-ке, другие варианты пока не пробовал.

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

Ну то есть примерно так, как это происходит в ms sql при восстановлении из дифференциального бекапа...

С другой стороны, как мне известно sybase, компания у которой ASA - продукт решающий задачу репликации в любом виде.

те синхронизация - задача для него штатная, и я просто не знаю как правильно ее выполнить.

Буду очень благодарен за любую помощь.

Да, странные ошибки с кириллицей... оказались "тяжелым наследством" и связаны с именованием объектов русскими буквами.
Есть и другие ошибки. Все их соберем и будем исправлять уже на 17-м sybase.

Чуть позже все же опробую алгоритм по статье и опишу результат, сейчас регламент не позволяет.

В моем случае, т.к. при конвертировании меняется размер страницы, говорить о синхронизации через лог не совсем корректно.

Тут действительно может помочь только трансляция скрипта.

Я только учусь. Вопросов много.

Спасибо Sergey Orlov.