Вот такая вот фигня вылазит в удаленной базе. Естественно база цела, но лог необходим, отрезать не могу, так как участвует в репликации. Лог повредился в результате нехватки места на диске. Сейчас получу базу + поврежденный лог, попытаюсь восстановить. Соответственно вопрос, стоит ли мучаться, или сразу выгружать новый вариант.
Спасибо за любые предложения.

ASA 9.0.0 1312 (это был промежуточный EBF, сейчас его на сайте нет)

Backup имеется... сутки назад.
Только при восстановлении из него будет восстановлен старый transaction log.
А в consolidated базе уже есть инфа, что эта ремотная получила данные.
Воспользоваться волшебной кнопкой Synchronize? или ну его нафиг и заново выгрузить базу?

При использовании "волшебной кнопки" в удаленной базе что произойдет? основная откатится до сломанной удаленной (тогда не надо)? или консолидированная заново получит все данные за сутки?

авторПри использовании "волшебной кнопки" в удаленной базе что произойдет? основная откатится до сломанной удаленной (тогда не надо)? или консолидированная заново получит все данные за сутки?

Сори, опечатался

При использовании "волшебной кнопки" в удаленной базе что произойдет? основная откатится до сломанной удаленной (тогда не надо)? или удаленная заново получит все данные за сутки?

Значит так. Вчера ночью провел эксперименты на трех тестовых базах (одна консолидированная, две удаленные), состоящих из двух табличек, поскольку на production database было очень страшно. И правильно сделал, как оказалось.
Странно, но кнопочка Synchronize в Централе не срабатывала, наверное глюк в данном EBF.
Выполнил команды synchronize subscription. Сначала на удаленной базе, которую вытащили из бэкапа, при этом в консолидированной и в другой удаленной (неповрежденной), все откатилось до состояния бэкапа первой бэкапной. Это не есть гуд, так как теряем результат работы за сутки во всех точках.
При выполнении synchronize subscription в консолидированной для сломанной-удаленной, в поврежденную первую заливается текущая инфа из первой. При этом выключается автоматическая подписка (на обоих концах: в консолидированной и удаленной-сломанной). Главное не забыть ее включить прежде чем начать работать. Но есть интересная штука: в момент синхронизации пользователь, от имени которого работает dbremote, намертво блокирует все и вся, нельзя редактировать данные. Причем у меня не получилось дождаться, чтобы этот пользователь отпустил ресурсы. Т.е. в жизни воспользоваться этим вряд ли получится, все пользователи в консолидированной будут курить бамбук, тем более по низким каналам пока пролезут десятки мегабайт. Вобщем, проще сделать extract...

У меня маленьких вопрос. Если я выгружаю базу для удаленного пользователя, который содержит publication, в которую не включены какие-либо таблички, то в полученной удаленной базе, таблички не включенные в публикацию не создаются, а надо :). Не совсем понятно. Может я где галочку какую забыл?

Aleksey Kh. Рыжий КотУ меня маленьких вопрос. Если я выгружаю базу для удаленного пользователя, который содержит publication, в которую не включены какие-либо таблички, то в полученной удаленной базе, таблички не включенные в публикацию не создаются, а надо :). Не совсем понятно. Может я где галочку какую забыл?

можно включить такие таблицы в подписку и в условии "where" указать что-нибудь типа "1=0", т.е. таблицы выгружаться будут, но данные под условия никакие не попадут.

При выгрузке в удаленной базе условия "1=0" не сохраняются. Их надо будет прописывать заново. В моем случае я могу это сделать, поскольку этих табличек мало. А как же это делать в "мировых масштабах"? :).

Я думал про такие методы, можно например, даже создать глобальную подписку на все объекты. После выгрузки ее отключать для данного пользователя. Но это все "сделано на коленках".