Как восстановить согласованную резервную копию нескольких баз данных
Для администратора баз данных резервное копирование — вещь обязательная. Не важно какими базами вы управляете, большими или маленькими, делать бэкапы необходимо. Разработчики СУБД это понимают и стараются сделать процедуру резервного копирования максимально простой и понятной для администратора. Но есть в резервном копировании баз данных один момент, в котором СУБД вам помочь не сможет…
Современные приложения всё чаще проектируются так, чтобы работать с данными не в одной базе данных, а в нескольких. Это действительно полезно — таким образом можно повысить масштабируемость, производительность, надёжность и управляемость приложения. Но, как всегда бывает в инженерном деле, это не обходится без сопутствующих недостатков. Главный из которых — усложнение системы. Возможности системы растут вместе с её сложностью, что повышает требования к обслуживанию многобазовых приложений. Одна из проблем, которую придётся решать при эксплуатации таких приложений — создание (и последующее восстановление) согласованных резервных копий нескольких баз данных.
Перед вами аналог приложения, работающего с несколькими БД. Оно постоянно обрабатывает данные в базах, согласовывая изменения при помощи транзакций.
Если вы будете восстанавливать из резервных копий каждую из баз независимо друг от друга, то базы восстановятся в состояниях на разные моменты времени, что означает нарушение целостности. Каждая база данных вроде бы восстановлена и сама по себе находится в согласованном состоянии, но приложению необходимо, что ещё и все базы были согласованы между собой.
SQL Server позволяет восстанавливать базу в состоянии не только на момент создания резервной копии, но и на любой произвольный момент времени. Чтобы добиться максимальной точности, следует восстанавливать состояние базы на момент фиксации определённой транзакции, а саму транзакцию провести так, чтобы она внесла изменения сразу во все базы.
Можно, к примеру, создать в каждой базе табличку и в транзакции добавлять в неё строку. А чтобы эту транзакцию при восстановлении можно было отличить от остальных, снабдим её меткой.
Теперь, когда эта метка сохранена в журнале транзакций, можно создать резервную копию журнала. А при восстановлении не забудьте указать параметр STOPATMARK (или STOPBEFOREMARK), чтобы все базы восстановились на момент фиксации нашей контрольной транзакции.
Проверяем базы после восстановления из резервной копии:
Аналогично можно восстанавливать согласованные резервные копии баз данных, работающих на разных серверах. Только не забудьте при этом модифицировать код контрольной транзакции так, чтобы транзакционная метка распространялась на все серверы.
0 комментариев