Сообщение Re[4]: Работа с log shipping в SQL Server от 25.09.2014 13:11
Изменено 25.09.2014 13:12 Somescout
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Somescout, Вы писали:
S>>Таблиц много, данные обновляются по множеству из них (заранее неизвестному).
S>>Есть ещё репликация, но для неё рекомендуют регулярно делать полную синхронизацию.
_AB>По существующей постановке задачи, я бы смотрел в сторону периодической подгрузки данных в отчетную
_AB>БД и их модифицикации там по необходимости.
А как можно на уровне sql синхронизировать таблицы? т.е. определить минимально необходимый объём данных, которые нужно скопировать в таблицу чтобы привести её к исходной? (Если исходить из того, что я не знаю какие именно таблицы менялись и время должно быть меньше, чем развёртывание бэкапа)
(возможно с помощью стороннего софта)
_AB>Нет. Лог шиппинг по своей сути — это банальное восстановление цепочки логов.
_AB>Перевод БД в режим, позволяющий менять данные, автоматически эту цепочку разрушает.
_AB>Всё что остается — это полное восстановление из бэкапа и повторный накат всей цепочки логов.
Понятно.
_AB>Здравствуйте, Somescout, Вы писали:
S>>Таблиц много, данные обновляются по множеству из них (заранее неизвестному).
S>>Есть ещё репликация, но для неё рекомендуют регулярно делать полную синхронизацию.
_AB>По существующей постановке задачи, я бы смотрел в сторону периодической подгрузки данных в отчетную
_AB>БД и их модифицикации там по необходимости.
А как можно на уровне sql синхронизировать таблицы? т.е. определить минимально необходимый объём данных, которые нужно скопировать в таблицу чтобы привести её к исходной? (Если исходить из того, что я не знаю какие именно таблицы менялись и время должно быть меньше, чем развёртывание бэкапа)
(возможно с помощью стороннего софта)
_AB>Нет. Лог шиппинг по своей сути — это банальное восстановление цепочки логов.
_AB>Перевод БД в режим, позволяющий менять данные, автоматически эту цепочку разрушает.
_AB>Всё что остается — это полное восстановление из бэкапа и повторный накат всей цепочки логов.
Понятно.
Re[4]: Работа с log shipping в SQL Server
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Somescout, Вы писали:
S>>Таблиц много, данные обновляются по множеству из них (заранее неизвестному).
S>>Есть ещё репликация, но для неё рекомендуют регулярно делать полную синхронизацию.
_AB>По существующей постановке задачи, я бы смотрел в сторону периодической подгрузки данных в отчетную
_AB>БД и их модифицикации там по необходимости.
А как можно на уровне sql синхронизировать таблицы? т.е. определить минимально необходимый объём данных, которые нужно скопировать в таблицу чтобы привести её к исходной? (Если исходить из того, что я не знаю какие именно таблицы менялись и время должно быть меньше, чем развёртывание бэкапа)
(возможно с помощью стороннего софта)
Либо синхронизация баз с помощью сторонних решений.
_AB>Нет. Лог шиппинг по своей сути — это банальное восстановление цепочки логов.
_AB>Перевод БД в режим, позволяющий менять данные, автоматически эту цепочку разрушает.
_AB>Всё что остается — это полное восстановление из бэкапа и повторный накат всей цепочки логов.
Понятно.
_AB>Здравствуйте, Somescout, Вы писали:
S>>Таблиц много, данные обновляются по множеству из них (заранее неизвестному).
S>>Есть ещё репликация, но для неё рекомендуют регулярно делать полную синхронизацию.
_AB>По существующей постановке задачи, я бы смотрел в сторону периодической подгрузки данных в отчетную
_AB>БД и их модифицикации там по необходимости.
А как можно на уровне sql синхронизировать таблицы? т.е. определить минимально необходимый объём данных, которые нужно скопировать в таблицу чтобы привести её к исходной? (Если исходить из того, что я не знаю какие именно таблицы менялись и время должно быть меньше, чем развёртывание бэкапа)
(возможно с помощью стороннего софта)
Либо синхронизация баз с помощью сторонних решений.
_AB>Нет. Лог шиппинг по своей сути — это банальное восстановление цепочки логов.
_AB>Перевод БД в режим, позволяющий менять данные, автоматически эту цепочку разрушает.
_AB>Всё что остается — это полное восстановление из бэкапа и повторный накат всей цепочки логов.
Понятно.