Как обновить тестовый экземпляр SQL-сервера производственными данными без использования полных резервных копий - PullRequest
2 голосов
/ 29 августа 2009

У меня есть два сервера MS SQL 2005, один для производства и один для тестирования, и оба имеют модель восстановления Full. Я восстанавливаю резервную копию производственной базы данных на тестовом сервере и затем пользователи вносят изменения.

Я хочу иметь возможность:

  • Откатить все изменения, внесенные в тестовый сервер SQL
  • Применить все транзакции, которые произошли на производственном сервере SQL с момента первоначального восстановления тестового сервера, чтобы эти два сервера имели одинаковые данные

Я не хочу делать полное восстановление базы данных из файла резервной копии, поскольку это занимает слишком много времени с нашей базой данных + 200 ГБ, особенно когда все измененные данные меньше 1 ГБ.

EDIT

На основании приведенных ниже предложений я попытался восстановить базу данных с помощью NoRecovery, но вы не можете создать снимок базы данных, которая находится в этом состоянии.

Я также попытался восстановить его в режиме ожидания только для чтения, который работает, и я могу сделать снимок базы данных и при этом применить журналы транзакций к исходной базе данных, но я не могу снова сделать базу данных доступной для записи, пока есть снимки для Это.

Продолжительность:

restore database TestDB with recovery

Приводит к следующей ошибке:

Msg 5094, Level 16, State 2, Line 1 The operation cannot be performed on a database with database snapshots or active DBCC replicas

Ответы [ 6 ]

4 голосов
/ 29 августа 2009

Прежде всего, после того, как вы восстановили резервную копию и установите базу данных в «восстановленную», вот и все - вы никогда не сможете применить к ней другую резервную копию журнала транзакций.

Однако, есть снимки базы данных. Я никогда не использовал их, но я верю, что вы можете использовать их для этой цели. Я думаю, что вам нужно восстановить базу данных, оставить ее в «не восстановленном» режиме - определенно не в режиме ожидания - и затем сгенерировать снимки на основе этого. (Или это было зеркальное отражение? Я читал об этом материале много лет назад, но у меня никогда не было причин его использовать.)

Затем, когда вы хотите обновить базу данных, вы удаляете снимок, восстанавливаете «следующий» набор резервных копий журнала транзакций и создаете новый снимок.

Однако я не думаю, что это сработало бы очень хорошо. Помимо этих затрат на управление и обслуживание, если тестировщики / разработчики сделают много изменений, ваш снимок базы данных может стать очень большим, даже больше, чем исходная база данных - и это место на жестком диске, используемое в дополнение к " оригинальная "база данных. Для нечасто измененных баз данных это может сработать, но для больших систем OLTP у меня есть серьезные сомнения.

2 голосов
/ 06 сентября 2009

Итак, что вам действительно нужно, так это копию Production, которая будет сделана в Test. Во-первых, у вас должна быть текущая резервная копия производства. Обычно в базе данных полные резервные копии такого размера создаются в воскресенье вечером, а затем разностные резервные копии создаются каждую ночь в течение недели.

Возьмите резервную копию Sunday и восстановите ее как другое имя базы данных на вашем сервере, скажем, TestRestore. Вы должны быть в состоянии начать это в 5:00 вечера, и это должно занять около 10 часов. Если это займет больше времени, см. Оптимизация производительности резервного копирования и восстановления в SQL Server.

Когда вы возвращаетесь утром восстановить последнюю разностную резервную копию предыдущей ночи, это не должно занять много времени.

Затем выгоните пользователей из тестовой базы данных и переименуйте Test в TestOld (кому-то что-то понадобится), затем переименуйте вашу базу данных TestRestore в тестовую базу данных. См. Как переименовать базу данных SQL Server.

Долгосрочным решением является доставка журналов из Production в TestRestore. В мгновение ока вы можете переименовать вещи и получить новую тестовую базу данных.

1 голос
/ 06 сентября 2009

Для отката, возможно, самый простой способ - использовать виртуальную машину, а не сохранять изменения при ее закрытии. Чтобы скопировать изменения из рабочей в тестовую, не могли бы вы восстановить дифференциальную резервную копию или резервную копию журнала транзакций из рабочей в тестовую базу данных?

0 голосов
/ 31 марта 2016

На сервере Server 1 существует задание, которое сжимает последнюю полную резервную копию На сервере Server2 есть задание, которое выполняет следующие шаги: Копирует сжатый файл на локальный диск Распаковывает файл, чтобы сделать полную резервную копию доступной Убивает все сеансы в базе данных, которая должна быть восстановлена Восстанавливает базу данных Устанавливает модель восстановления в Simple Предоставляет разработчикам привилегии db_owner

Ref: http://weblogs.sqlteam.com/tarad/archive/2009/02/25/How-to-refresh-a-SQL-Server-database-automatically.aspx

0 голосов
/ 17 января 2014

Поставщики хранилищ (как netapp) предоставляют возможность создавать записываемые снимки. Это дает вам возможность в течение нескольких секунд создать снимок на рабочем месте, выполнить тесты и удалить / воссоздать снимок. Это долгосрочное решение, но ... оно работает

0 голосов
/ 09 сентября 2009

Перепробовав все предложенные здесь предложения, я не нашел никаких средств для выполнения того, что я изложил в этом вопросе, с помощью SQL. Если кто-то может найти способ и опубликовать его или у него есть другое предложение, я был бы рад попробовать что-то еще, но на данный момент, похоже, нет способа сделать это.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...