Экземпляр "Минус день" в дополнение к DEV, TEST и PROD

[Kasper]

Написал статью, как организовать "Минус день с подхватом логов".

Что это даёт?

1. оперативность решения проблем
2. снижение рисков и затрат

Возможные сценарии применения МДПЛ

1. Тестирование новой функциональности
2. Уменьшить количество сторно
3. Снижение ошибок при обучении новых сотрудников
4. Моделирование расчёта себестоимости
5. Избегать сторнирования при разноске входящих сальдо

Статья здесь
http://yaroslavbat.blogspot.com/2014/10/blog-post.html

У кого есть замечания\пожелания\дополнения ?

[Владимир Максимов]

Не знаю даже как назвать. Замечания, что ли...

Замечание 1

FULL Backup базы данных необходимо делать регулярно вне зависимости от его дальнейшего использования. Минимум, раз в неделю. Описанная технология не может заменить создание FULL Backup. При этом Backup логов начинает "отсчет" от момента создания последнего FULL Backup. Это значит, что после выполнения FULL Backup все ранее созданные Backup логов можно смело выбрасывать. Они больше не нужны. А созданный FULL Backup необходимо будет скопировать на машину с базой "минус день".

В момент создания FULL Backup описанная технология не имеет никаких преимуществ

Замечание 2

Использование Backup логов предполагает, что они создаются друг за другом без разрывов. Это значит, что если в какой-то момент создание Backup-лога "сбойнуло" и был "пропущен" кусок за очередные 15 минут, то процесс восстановления из Backup станет невозможен. Точнее, восстановление остановится на "пропущенном" участке. А запустить повторное создание "пропущенного" куска - невозможно. Необходимо будет сделать полный или дифференциальный Backup базы данных.

В случае сбоя создания очередного "фрагмента" Backup-лога описанная технология перестает работать.

[Kasper]

Владимир, спасибо за замечания. Вот мои ответы

Цитата:

Сообщение от Владимир Максимов

FULL Backup базы данных необходимо делать регулярно вне зависимости от его дальнейшего использования. Минимум, раз в неделю. Описанная технология не может заменить создание FULL Backup.

Технология "Минус день с подхватом логов" не предназначена для замены FULL BACKUP и не влияет на принятую корпоративную политику резервного копирования.
Эта технология имеет иные цели: для сотрудников -- снизить количество сторно, для консультантов -- дать бОльшую оперативность решения проблем

Цитата:

Сообщение от Владимир Максимов

При этом Backup логов начинает "отсчет" от момента создания последнего FULL Backup. Это значит, что после выполнения FULL Backup все ранее созданные Backup логов можно смело выбрасывать. Они больше не нужны. А созданный FULL Backup необходимо будет скопировать на машину с базой "минус день".

Нет, это не так.
Transaction Log'и содержат записи об изменениях. Каждое изменение имеет LSN -- Log Sequence Number. Они должны быть без промежутков. При выполнении FULL BACKUP "дырок" в LSN не образуется.
Я проверил это ещё раз -- сделал в середине цикла FULL BACKUP -- база "Минус день" проигнорировала факт создания большого бэкапа и продолжила накатывать логи по цепочке.
В том, что "дырок" в LSN не образуется, Вы можете убедиться выполнив запрос

select a.BACKUP_SET_ID, a.NAME, a.USER_NAME
     , FIRST_LSN, LAST_LSN, CHECKPOINT_LSN
     , DATABASE_BACKUP_LSN, TYPE, b.PHYSICAL_DEVICE_NAME
from msdb..BACKUPSET a, msdb..BACKUPMEDIAFAMILY b
where a.MEDIA_SET_ID = b.MEDIA_SET_ID

Результат выполнения на моей БД я выложил здесь
Вы можете увидеть, что между зелёными клетками нет промежутка в LSN, хотя между ними был FULL BACKUP

Цитата:

Сообщение от Владимир Максимов

Использование Backup логов предполагает, что они создаются друг за другом без разрывов. Это значит, что если в какой-то момент создание Backup-лога "сбойнуло" и был "пропущен" кусок за очередные 15 минут, то процесс восстановления из Backup станет невозможен. Точнее, восстановление остановится на "пропущенном" участке. А запустить повторное создание "пропущенного" куска - невозможно. Необходимо будет сделать полный или дифференциальный Backup базы данных.

Transaction Log является важной частью базы данных и утеря его недопустима, как для "Минус дня", так и для штатного backup. Если всё-же такое произойдёт -- да, нужно сделать полный backup. Это в равной степени относится и к штатному backup.

Механизм TLS очень похож на ARCHIVELOG в Oracle. Там та-же ситуация и такое-же решение.
Обычно этого не происходит

[Kabardian]

Наверняка подразумевалось, но добавил бы что организации таких "минус один день" приложений важно и скрипты по отключению настроек интеграции с внешними системами предусмотреть (банк-клиент, ftp-сервер 3PL-оператора, кассовые сервера, EDI и т. п.).

Иначе тестирование может задеть данные приложение PROD.

[Владимир Максимов]

Цитата:

Сообщение от Kasper

Я проверил это ещё раз -- сделал в середине цикла FULL BACKUP -- база "Минус день" проигнорировала факт создания большого бэкапа и продолжила накатывать логи по цепочке.

Вот именно этот момент меня и смущал. Если создание Full Backup не приводит к необходимости "начинать сначала", то возражение снимается. Я просто не проверял этот момент.

Кстати, не подскажите, насколько описанная Вами технология требовательна к дисковому пространству? Если за единицу отсчета брать размер рабочей базы данных, то сколько дискового пространства требуется для виртуальных дисков? Ну, например, если рабочая база 2ТБ, то сколько потребуется на виртуальную машину?

[Kasper]

Цитата:

Сообщение от Kabardian

...важно и скрипты по отключению настроек интеграции с внешними системами предусмотреть...
Иначе тестирование может задеть данные приложение PROD.

Да, это очень важно.
Об этом написано в Пререквизитах п.5 и в шаге.5.6

[Kasper]

Цитата:

Сообщение от Владимир Максимов

Кстати, не подскажите, насколько описанная Вами технология требовательна к дисковому пространству? Если за единицу отсчета брать размер рабочей базы данных, то сколько дискового пространства требуется для виртуальных дисков? Ну, например, если рабочая база 2ТБ, то сколько потребуется на виртуальную машину?

Требования к ресурсам таковы:

RAM: + 1 ГБ для внутреннего гипервизора

Диски -- объём складывается из трёх компонентов:
1) Сама база
2) Transaction Logs (хранятся за 72 часа или как настроите) -- мне оценить сложно, поскольку это зависит от того, сколько операций у Вас выполняется
3) Дифференциальный диск -- я бы принял объём диффдиска в 20...25% от базового диска

Таким образом, для базы в 2ТБ Вам будет комфортно, если выделить 4...5 ТБ, при этом такую большую БД ставить надо по сети, не копируя на внутреннюю машину

[Kasper]

Уважаемые коллеги !

Подскажите, сделал ли кто ни-будь себе такую базу ?
Есть первопроходцы ?

[Ярослав Щекин]

Цитата:

Сообщение от Kasper

Подскажите, сделал ли кто ни-будь себе такую базу ?
Есть первопроходцы ?

У нас используется уже более 7 лет, а что Вас интересует?

[Kasper]

Здравствуйте, Ярослав!

Первая версия Hyper-V была включена в состав Windows Server 2008.
Windows Server 2008 была выпущена 27 февраля 2008 года.
7 лет с этого момента наступит лишь через 2 недели.
Поэтому методика, описанная в статье, не может использоваться "более 7 лет".
Могу предположить, что у Вас используется экземпляр "Минус день" (он может существовать указанное Вами время).
Но я задал вопрос относительно экземпляра "Минус день с подхватом логов"
Ярослав, Ваш сарказм неуместен

[Ярослав Щекин]

Цитата:

Сообщение от Kasper

Могу предположить, что у Вас используется экземпляр "Минус день" (он может существовать указанное Вами время).

Да, извините, неправильно понял вопрос.

Цитата:

Сообщение от Kasper

Но я задал вопрос относительно экземпляра "Минус день с подхватом логов"
Ярослав, Ваш сарказм неуместен

Никакого сарказма.

Я просмотрел Вашу статью, и мне непонятно, почему "Когда размер БД приближается к сотне гигабайт, подход Backup\Restore уже не работает". Вот у нас размер БД около 500 гигабайт, и полный Backup (Restore) выполняется меньше часа. IMHO, полные Backup-ы всё равно должны быть, а ежедневное восстановление их в виде экземпляра "минус день" заодно проверяет их на корректность.

[Kasper]

Цитата:

Сообщение от Ярослав Щекин

Вот у нас размер БД около 500 гигабайт, и полный Backup (Restore) выполняется меньше часа.

500 ГБ -- пограничное состояние -- вообще то это уже немало. Ежедневный полный backup даёт серьёзную нагрузку на систему, восстановление его -- тоже. А учитывая, что меняется лишь малая часть от 500 ГБ, можно задуматься об инкрементном backup.

Но это вопрос предпочтений системного администратора -- на месте виднее

А мой вопрос касался следующего: автоматизация того алгоритма (МДПЛ) -- непроста, вот в голове у меня крутятся какие-то мысли, как это сделать, но я этого не реализовал.
Интересовался, сделал ли кто ни-будь ?
Надо ведь снаружи заслать команды внутрь виртуалки

[Kasper]

В разделе "Похожие темы" внизу форума мне показало сслыку на интересную статью, как отключать TEST от PROD
Это имеет отношение к этой статье
dynamics-ax-dev: Copying a Production Environment into a Development/Test Environment

[Vadik]

Цитата:

Сообщение от Kasper

В разделе "Похожие темы" внизу форума мне показало сслыку на интересную статью, как отключать TEST от PROD
Это имеет отношение к этой статье
dynamics-ax-dev: Copying a Production Environment into a Development/Test Environment

Ага, замечательный скрипт, только вот неполный. Навскидку -
- AIF забыт совсем. Запускаем скрипт, а на выходе - TEST среда смотрящая всеми исходящими портами на продуктивы внешних систем.
- Пароли SMTP перебиваются некорректно - там содержимое BLOB-а с паролем зависит от имени хоста для которого генерится, так что просто его (имя хоста) поменять явно недостаточно

>А мой вопрос касался следующего: автоматизация того алгоритма (МДПЛ) -- непроста, вот в голове у меня крутятся какие-то мысли, как это сделать, но я этого не реализовал

Давно хотел решить подобную задачу для AX 2012 "наоборот" - сначала выгрузить все настройки специфичные для инстанса, а после восстановления БД - залить их обратно. Но руки все никак не доходят