Моя ситуация такова: у меня есть производственная база данных Sql Server 2005. Раз в день я хочу дублировать эту базу данных в другую базу данных аварийного переключения, которая находится на том же экземпляре сервера. Я не хочу, чтобы эти базы данных синхронизировались чаще одного раза в день (например, без зеркалирования). Я знаю, что могу сделать это с помощью резервного копирования / восстановления, но мне было интересно, есть ли одношаговое решение для этого.
Кто-нибудь знает хороший способ сделать это без резервного копирования / восстановления?
Почему вы хотите избежать резервного копирования / восстановления?
Вы можете создать сценарий команд резервного копирования и восстановления и создать их как задание SQL, чтобы оно выполнялось автоматически. Будет ли что-нибудь подключаться к базе данных копий во время обычных операций? (потому что это может вызвать проблемы с восстановлением)
Есть два способа скопировать базу данных оптом: резервное копирование / восстановление и отсоединение / присоединение - ни один из них не является одноэтапным процессом, и резервное копирование / восстановление определенно будет предпочтительнее, учитывая описанный вами сценарий.
Если «отказоустойчивую» базу данных необходимо поддерживать в оперативном режиме во время ее обновления, вы в значительной степени застряли в репликации. Однако, поскольку базы данных находятся в одном экземпляре, вы можете просто использовать запросы между базами данных для перемещения данных.
Я не хочу выходить за рамки этого вопроса, но база данных «аварийного переключения» в том же экземпляре, что и производственная среда, не обеспечивает многого в плане отказоустойчивости. От каких сбоев вы надеетесь защититься?
Изменить: то, что вы, возможно, ищете (если вы используете корпоративную версию 2005+), это снимки базы данных, как предлагает JMusgrove. Вы можете сделать снимок в любой момент времени, а затем вернуть базу данных к этому снимку, если в этом возникнет необходимость. Снимок доступен только для чтения до тех пор, пока вы к нему не вернетесь. См. Эту статью MSDN на Возврат к моментальному снимку базы данных. Я бы предположил, что это между моментальными снимками и резервным копированием / восстановлением.
Есть ли необходимость в изменении полученной копии каким-либо образом, или будет достаточно копии только для чтения? В последнем случае вы можете использовать моментальный снимок базы данных для создания своей «копии» базы данных - и это в значительной степени одноэтапный процесс, как описано в эта статья Technet
Пример:
CREATE DATABASE myCopy ON (
NAME = originalLogicalName,
FILENAME = 'path\to\new\snapshotfile'
) AS SNAPSHOT OF myOriginal
Если первое, то одноэтапный подход немного сложнее. Для простых баз данных без хранимых процедур, сложных отношений и т. Д. Вы можете создать пакет SSIS (задание DTS) для копирования данных из одной базы данных в другую, но это может довольно быстро стать ужасно беспорядочным.
Как предлагает codeulike, что не так с резервным копированием и восстановлением. Это звучит как наиболее близкое семантическое соответствие тому, что вы пытаетесь сделать.
Практически любое действие, которое вы можете выполнить в SQL Server Management Studio, имеет возможность сгенерировать сценарий для выполнения действия вместо того, чтобы фактически выполнять действие тут же.
Найдите кнопку «Сценарий» в верхней части каждого всплывающего окна. Остальное просто - просто создайте сценарий, используя стандартные блоки, сгенерированные для вас SSMS, и создайте задание SQL Server для автоматизации.
Можно настроить одностороннюю репликацию снимков. Он будет перемещаться от источника к месту назначения один раз в день, когда вы его планируете. После того, как он окажется на целевом сервере, пункт назначения будет работать точно так же, как источник. Однако любые изменения, которые вы вносите в место назначения, будут потеряны при следующей репликации, поскольку в следующий запланированный момент времени источник перезапишет место назначения.
Итак, если ваш пункт назначения является копией источника, чтобы ваши разработчики могли взломать базу данных с реальными данными в ней, и не имеет значения, будет ли она перезаписана при следующей копии, тогда это сработает для вас.
Почему бы не настроить репликацию снимков? Сделать производственную БД публикацией, а резервную копию - подпиской? Установите репликацию каждые 24 часа, и все готово.
Эта реплицированная БД также будет иметь все свойства и разрешения производной БД, поэтому ее можно без проблем подключить как продукт.