Песочница SQL Server

Я пытаюсь настроить «песочницу» для наших разработчиков отчетов, чтобы они могли работать. Мой текущий план состоит в том, чтобы «сбрасывать» базу данных каждый вечер, но я не знаю, как это сделать. Под сбросом я подразумеваю, что я хочу по существу удалить любые пользовательские таблицы, представления, хранимые процедуры и т. Д. Из всех, кроме одной базы данных на сервере. Я полагаю, что другой вариант - удалить и заново создать базу данных, но я уверен, что это будет означать предоставление доступа ко всем соответствующим группам / людям AD тоже.

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

Для ясности мы по существу хотим сделать это с нашей базой данных: http://try.discourse.org/t/this-site-is-a-sandbox-it-is-reset-every-day/57 . Единственное отличие состоит в том, что мы не хотим воссоздавать наших пользователей каждый день.

Версия: SQL Server 2008
Edition: разработчик и предприятие

sql-server sql-server-2008

— Kittoes0124
источник

Ответы:

Другой идеей было бы просто настроить ночную работу, которая выполняет резервное копирование copy_only и восстанавливает его на сервере dev (или на том же сервере, если он у вас есть, но это может быть не очень хорошей идеей). Приятно то, что восстановление может выполняться на любом сервере (или нескольких серверах) и может быть полностью отделено от любого действия в первичной базе данных.

На сервере 1:

BACKUP DATABASE db TO DISK = '\\someshare\file.bak' 
  WITH COPY_ONLY, INIT, COMPRESSION;

На сервере 2:

RESTORE DATABASE db_dev FROM DISK = '\\someshare\file.bak'
  WITH REPLACE, RECOVERY;

Вам также может понадобиться добавить MOVEкоманды, если расположение дисков между серверами отличается (или если вы размещаете копию на одном сервере).

RESTORE DATABASE db_dev FROM DISK = '\\someshare\file.bak'
  WITH REPLACE, RECOVERY,
  MOVE 'data_file_name' TO 'D:\somepath\somefile.mdf',
  MOVE 'log_file_name'  TO 'E:\somepath\somefile.ldf';

Если вы восстанавливаете на том же сервере, у вас не должно быть проблем с пользователями. Если вы восстановите на другом сервере, ваши пользователи будут существовать, но учетные записи на уровне сервера могут отсутствовать. Есть сценарии, чтобы исправить это , и новая функция в SQL Server 2012 ( Contained Databases ), которая полностью устраняет проблему.

— Аарон Бертран
источник

У нас есть dev / prod, но dev - единственный сервер, на котором это происходит. Прод только для готовых процессов.

— Kittoes0124

Это решение, которое я бы выбрал, просто имейте в виду, что в большинстве случаев вы не хотите просто копировать производство в среду разработки. Пожалуйста, используйте меру (сценарий?), Которая, например, удалит или замаскирует адреса электронной почты пользователей, контактные данные и т. Д. Вы не хотите, чтобы ваши разработчики случайно начали отправлять электронные письма пользователям.

— zeroDivisible

Поскольку у вас есть экземпляр с движком Enterprise Edition, я бы использовал снимки базы данных .

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

Обратите внимание, что если разработчики планируют загружать большие объемы данных (похоже, что нет?), То это может не подходить.

— Джон Сайгель
источник

Почему не было бы уместно, если бы они выполняли большие загрузки данных? Наши могут загружать скажем .... 8 миллионов строк по 100 столбцов время от времени (даже если они «не должны»), но мы не обязательно хотим помешать им сделать это. Все, что нас действительно волнует, - это то, что в конце дня все становится ядерным.

— Kittoes0124

@Kittoes, потому что моментальный снимок должен сохраняться при изменении исходных данных. Он должен извлекать существующие страницы из источника, если источник изменяется, чтобы он поддерживал представление «до». Это не происходит до тех пор, пока исходные данные не изменятся (снимок использует разреженный файл, который является пустым, за исключением дельт). Это обслуживание может стать довольно дорогим. Посмотрите, как работают снимки базы данных .

— Аарон Бертран

@AaronBertrand Хорошо, поэтому, если база данных увеличится до 8 ГБ в течение дня, то при восстановлении снимка все новые данные будут удалены, но размер базы данных все равно будет 8 ГБ? Или я недоразумение?

— Kittoes0124

@Kittoes снимок доступен только для чтения, поэтому вы сможете загружать только новые данные в исходную базу данных. Если вы добавите 8 ГБ в течение дня, он не будет виден на снимке. Когда вы возвращаете / удаляете снимок, исходная база данных по-прежнему будет иметь 8 ГБ данных и будет иметь соответствующий размер. Если затем сделать еще один снимок, новые данные будут видны. Если вы удалите 8 ГБ в течение дня, он будет добавлен в снимок.

— Аарон Бертран

@Kittoes, если вы хотите отменить загрузку данных 8 ГБ, вернувшись к моменту времени, когда был сделан снимок, да, он должен вернуть ваши файлы данных к их размеру (если вы действительно хотите, чтобы файлы снова были маленькими, так Вы можете просто увеличить автоматически, когда вы снова загрузите 8 ГБ, завтра это еще одна проблема). Но я не проверял этот сценарий явно. И, как упоминается в статье, на которую я ссылаюсь, это не обязательно надежно, поскольку также зависит от надежности основного хранилища. Резервное копирование - более безопасный способ сделать это.

— Аарон Бертран

Позвольте мне добавить мои несколько центов, чтобы посмотреть, поможет ли это вам:

В моей компании такая же ситуация, что каждую ночь разработчики хотят обновлять базы данных, которые они использовали в течение дня. Это означает , что у нас есть множество баз данных, Дэв не трогать - позволяет скажем А и другой набор баз данных , которые являются точной копией А , но они делают свои вещи , но хотят получить обновляется каждую ночь - позволяет сказать , что B . Это происходит на одном экземпляре сервера.

То, что я реализовал, - это НОЧНОЙ ПРОЦЕСС ВОССТАНОВЛЕНИЯ для достижения этой цели Вот как это работает:

Создайте таблицу драйверов со списком баз данных, которые необходимо восстанавливать каждый вечер (как вы уже упоминали).

Таблица: nightly_restore (OriginalDB, RestoreDB, резервное расположение, enabled_YN, результаты, PASS_FAIL)

Затем вы можете написать некоторый TSQL, который будет циклически проходить по списку баз данных из приведенной выше таблицы, а затем выполнять восстановление и регистрировать любые успехи или неудачи в Результатах и бит 1 = Проход или 0 = Неудача. Enabled_YN определит, нужно ли восстанавливать эту базу данных.

Если в будущем будет добавлено больше баз данных, вам нужно просто вставить их в таблицу и установить для бита enabled_YN значение Y (включено).

Таким образом, процесс будет более гибким и управляемым.

Если вам нужен написанный мною SQL (уверен, вы сможете его написать :-)), просто пингуйте меня или добавьте комментарий, и я поделюсь им.

НТН

— Кин Шах
источник