Я пытаюсь сэкономить время на повторяющейся задаче, которую меня постоянно просят выполнить.
У нас есть внутреннее приложение, которое мы назовем «Приложение».
Это приложение имеет базу данных под названием «AppLive».
У нас есть «тестовый» экземпляр того же приложения, которое использует базу данных «AppTesting». Это сделано для того, чтобы мы могли выполнять тесты и т. Д., Не влияя на наши живые данные.
Когда пользователи хотят начать играть с тестовым экземпляром приложения, меня просят «импортировать данные в реальном времени в тестовую базу данных». Им нужен самый последний набор живых данных из нашей базы данных AppLive, импортированный в базу данных AppTesting.
Мой текущий процесс таков:
Сделайте последнюю еженедельную полную резервную копию действующей базы данных. Удалите тестовую базу данных. «Восстановите» файл резервной копии AppLive в новую базу данных с именем AppTesting (то же имя, что и удаленная база данных).
Это дает нам самые свежие ночные данные в тестовой базе данных.
Проблема в том, что база данных становится огромной. Это около 11 ГБ, а файлы резервных копий удаленно хранятся на диске NAS.
Поэтому мне нужно подождать 45 минут, чтобы передать файл резервной копии базы данных на SQL-сервер, а затем начать импорт. Что опять же требует абсолютного возраста.
Моим идеальным решением было бы:
Продолжаю делать мои ночные полные резервные копии базы данных AppLive (для наших обычных требований к резервному копированию) и для инкрементной резервной копии, сделанной мне в дополнение к этому - чтобы, когда мне нужно импортировать живые данные в нашу тестовую базу данных, мне не нужно было играть с огромным файлом размером 11 ГБ. В идеале я хотел бы иметь возможность сказать студии управления MSSQL: «Пожалуйста, обновите базу данных AppTest всеми новыми данными из AppLive» - хотя я не хочу, чтобы это планировалось, тестовые данные должны оставаться статичными, пока нас не попросят обновить это с новыми данными.
Я надеюсь, что это достаточно ясно и что кто-то сможет указать мне правильное направление.
У вас есть несколько вариантов.
1) Напишите сценарий PowerShell или что-нибудь для автоматизации восстановления. Это превращает его в огонь и забывает. Затем вы можете объединить это с запланированным запуском инструмента (например, по воскресеньям) в третьей базе данных. Это означало бы сесть с потребителем тестовой базы данных, чтобы выяснить, какова их устойчивость к устаревшим данным (т.е. насколько свежей должна быть база данных). Затем, когда поступает запрос на обновление данных, вы удаляете текущую тестовую базу данных, переименовываете восстановленную в копию (вы, вероятно, также захотите переименовать физические файлы), и все готово.
2) Доставка журналов
3) Зеркальное отображение базы данных.
Варианты 2 и 3 кажутся излишними для того, что вы пытаетесь достичь.