Здравствуйте, _ABC_, Вы писали:

_AB>Здравствуйте, Somescout, Вы писали:

S>>Таблиц много, данные обновляются по множеству из них (заранее неизвестному).
S>>Есть ещё репликация, но для неё рекомендуют регулярно делать полную синхронизацию.
_AB>По существующей постановке задачи, я бы смотрел в сторону периодической подгрузки данных в отчетную
_AB>БД и их модифицикации там по необходимости.
А как можно на уровне sql синхронизировать таблицы? т.е. определить минимально необходимый объём данных, которые нужно скопировать в таблицу чтобы привести её к исходной? (Если исходить из того, что я не знаю какие именно таблицы менялись и время должно быть меньше, чем развёртывание бэкапа)

_AB>Нет. Лог шиппинг по своей сути — это банальное восстановление цепочки логов.
_AB>Перевод БД в режим, позволяющий менять данные, автоматически эту цепочку разрушает.
_AB>Всё что остается — это полное восстановление из бэкапа и повторный накат всей цепочки логов.
Понятно.

Здравствуйте, _ABC_, Вы писали:

_AB>Здравствуйте, Somescout, Вы писали:

S>>Таблиц много, данные обновляются по множеству из них (заранее неизвестному).
S>>Есть ещё репликация, но для неё рекомендуют регулярно делать полную синхронизацию.
_AB>По существующей постановке задачи, я бы смотрел в сторону периодической подгрузки данных в отчетную
_AB>БД и их модифицикации там по необходимости.
А как можно на уровне sql синхронизировать таблицы? т.е. определить минимально необходимый объём данных, которые нужно скопировать в таблицу чтобы привести её к исходной? (Если исходить из того, что я не знаю какие именно таблицы менялись и время должно быть меньше, чем развёртывание бэкапа)
(возможно с помощью стороннего софта)

_AB>Нет. Лог шиппинг по своей сути — это банальное восстановление цепочки логов.
_AB>Перевод БД в режим, позволяющий менять данные, автоматически эту цепочку разрушает.
_AB>Всё что остается — это полное восстановление из бэкапа и повторный накат всей цепочки логов.
Понятно.