Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Организация тестовой базы, с каждодневной актуализацией  [new]
Alderego
Member

Откуда:
Сообщений: 110
Добрый день.
Хотелось бы узнать мнение знатоков, как лучше всего решить задачу. Сам обдумывал уже все известные мне возможности MS SQL Server и полностью удовлетворяющего меня решения найти не смог, надеюсь это ввиду небольшого опыта и вы дадите мне совет какое решение будет оптимальным.

Итак, исходные данные:
Есть продакшн с базой более 1Тб, есть тестовый сервер. Версия СУБД - MS SQL Server 2008R2. Необходимо чтобы на тесте каждый день была актуальная копия боевой базы(не 1 в 1 с боевой, но по состоянию на утро). Тест обязательно должен быть read\write, а не read only.

В чём я вижу сложность:
База не самая маленькая и процесс резервного копирования, как и процесс восстановления занимает несколько часов. Плюс каждый день записывать на диск более 1Тб, а в конце дня удалять наверное не очень хорошо для дисков.
После всех раздумий, пока что оптимальным вариантом представляется такой:
1) Раз в неделю копируем фул бэкап на тест.
2) Каждый день копируем диф бэкап на тест.
3) Каждый день удаляем существующую тестовую базу, поднимаем фул и диф за текущий день.
(Опционально) 4) "Одновременно" поднимаем 2 фула, на тесте, чтобы сэкономить время подготовки тестовой базы для разработчиков(т.е. работают с одной, пока работают у нас поднимается вторая база и просто ждёт дифа), главный минус тут ещё большее издевательство над дисками, ну и в целом данная схема кажется очень кривой и не покидает чувство, что это можно реализовать как-то более красиво. Поскольку если с 1Тб эта схема ещё как-то работает то скажем с 10Тб базой, эта схема вызывает вопросы, но задача же всё равно должна быть решаема.

Чего бы хотелось:
Хотелось бы чего-то типа стэндбая, чтобы накатывалось логами, в течении дня чтобы разработчики мучили базу, после чего она бы возвращалась к исходному состоянию и просто докатывалась логами до актуального состояния, но я такого варианта не нашёл(snapshot и восстановление из него, меняет lsn и не позволяет дальше катить логи от боевой базы).
Подскажите пожалуйста возможные решения задачи.
3 янв 13, 18:56    [13720020]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
Ennor Tiegael
Member

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

Вы у них спрашивали, их это устраивает?
3 янв 13, 19:30    [13720134]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
Alderego
Member

Откуда:
Сообщений: 110
Ennor Tiegael
Вот ваш разработчик начал мучить базу, что-то там понаписал, на следующее утро приходит, пытается продолжить с того места, где остановился - а все его изменения тю-тю, и вместо них - куча всего нового.

Вы у них спрашивали, их это устраивает?

Это как раз их пожелание. Это для узких задач,поэтому именно такие требования. Для долгосрочных правок и тестов у них уже есть тестовая база.
3 янв 13, 19:45    [13720188]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
Alderego
Хотелось бы узнать мнение знатоков, как лучше всего решить задачу
Бакап/рестор

Alderego
После всех раздумий, пока что оптимальным вариантом представляется такой:
1) Раз в неделю копируем фул бэкап на тест.
2) Каждый день копируем диф бэкап на тест.
3) Каждый день удаляем существующую тестовую базу, поднимаем фул и диф за текущий день.
Да, нормально.
Alderego
Хотелось бы чего-то типа стэндбая, чтобы накатывалось логами, в течении дня чтобы разработчики мучили базу, после чего она бы возвращалась к исходному состоянию и просто докатывалась логами до актуального состояния
Можно и так - восстановили полный бакап, накатили логи. Но скорее всего это будет медленнее.
Alderego
главный минус тут ещё большее издевательство над дисками
Ничего с ними не случится.

Тем более бакапы продакшена делаются в любом случае, вопрос только в восстановлении. Заодно и проверять рабочие бакапы будете, а то некоторые их только делают :-)
3 янв 13, 20:33    [13720322]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7582
А миррроринг и снэпшот чем не вариант?
3 янв 13, 20:42    [13720351]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
Alderego
Member

Откуда:
Сообщений: 110
Relic Hunter
А миррроринг и снэпшот чем не вариант?

Мысль такая была,поскольку казалась оптимальной. Но на практике не получилось,может что-то неправильно делал...
Во время зеркалирования нельзя работать с зеркалом,создал снэпшот с зеркала,но он read only.
3 янв 13, 20:54    [13720393]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Relic Hunter
А миррроринг и снэпшот чем не вариант?


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

2 Alderego

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

насчет оптимизации рестора - вряд ли у вас все данные активно меняются
выделите RO часть, вынесите в отдельную RO ФГ и не бакапьте / не ресторьте ее, только оперативную часть
вариант?
3 янв 13, 20:57    [13720407]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7582
Alderego,
Да, вы правы он толко для чтения. Я такое делаю возможностями стореджа (rw snapshots). Осталньное все УГ. Линуксовые файловые системы такое умеют, LVM2, ZFS. про виндовс не знаю.
3 янв 13, 21:00    [13720423]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
Relic Hunter
Я такое делаю возможностями стореджа (rw snapshots). Осталньное все УГ. Линуксовые файловые системы такое умеют, LVM2, ZFS.
И что, всякие ораклы и дб2 поверх этого будут нормально работать?

Да, в принципе наверное это эффективный путь... Но на Windows и MSSQL я про такое не слышал.
3 янв 13, 21:03    [13720441]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7582
>> И что, всякие ораклы и дб2 поверх этого будут нормально работать?

Ну работают-же.

>> Да, в принципе наверное это эффективный путь... Но на Windows и MSSQL я про такое не слышал.

Ну почему? Если на таком файлере разместить базу...
3 янв 13, 21:07    [13720455]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
Crimean
а зачем вам так часто "большую" базу актуализировать?
на нее обычно выносят "ресурсные" тесты, когда важны объемы. а это не нужно каждый день
"методологические" тесты проще / удобнее делать на мелких базах с заранее известными "простыми" / "показательными" данными
В принципе это правильно, но если технически несложно перенести рабочую базу, то это дешевле (не требует дополнительного труда), и данные более полные и разнообразные (иногда на урезанных данных можно не поймать какую то ошибку, не отладить какую то функциоенальность), это плюс.

Ну и бакапы рабочие тестируются, это реально большой плюс.
3 янв 13, 21:07    [13720456]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
Relic Hunter
>> Да, в принципе наверное это эффективный путь... Но на Windows и MSSQL я про такое не слышал.

Ну почему? Если на таком файлере разместить базу...
Не будет сиквел работать "на таком файлере" :-)
3 янв 13, 21:08    [13720462]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7582
alexeyvg,

Уже и довольно даво работает.

http://www.netapp.com/us/company/news/press-releases/news-rel-20120904-910321.aspx
3 янв 13, 21:12    [13720477]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
Alderego
Member

Откуда:
Сообщений: 110
Crimean
насчет оптимизации рестора - вряд ли у вас все данные активно меняются
выделите RO часть, вынесите в отдельную RO ФГ и не бакапьте / не ресторьте ее, только оперативную часть
вариант?

это вариант,но он влечёт за собой изменение прома, хотелось бы обойтись без этого пока,система критичная и простоев для перестройки базы желательно избежать. Данный вопрос, он у разработчиков возник как пожелание,соответсвенно если можно обойтись "малой кровью", то сделать. Если нет, то будут на старом варианте.

Для меня самого вопрос интересен, еще и с познавательной точки зрения,вдруг в будущем пригодится.
3 янв 13, 21:13    [13720481]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
Crimean
Member

Откуда:
Сообщений: 13147
alexeyvg
если технически несложно перенести рабочую базу


ну так RO файлгруппы никто не отменял. зачем их по 100 раз бакапить / ресторить? ну не поверю я, что там ежедневно полтера данных обновляется
3 янв 13, 21:14    [13720485]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7582
Alderego,

Мы заради таких хотелок как ваши купили специалный сторедж и не дешовый.
3 янв 13, 21:16    [13720493]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Alderego,

а у вас, сильно подозреваю, с таким объемом де-факто RO часть данных есть. иначе вы в обновлении статистик / перестроении индексов погрязнете в смысле временных затрат. покопайте в эту сторону. может просто не рассказывают или должным образом не используют?
3 янв 13, 21:16    [13720496]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
Crimean
alexeyvg
если технически несложно перенести рабочую базу


ну так RO файлгруппы никто не отменял. зачем их по 100 раз бакапить / ресторить? ну не поверю я, что там ежедневно полтера данных обновляется
Да ничего сложного, если они есть, эти группы :-)

Но если нет, редизайнить базу ради этого не стоит. Слишком много труда в какой нибуть 1С разделить данные по RO и RW файлгруппам.
По крайней мере для террабайтной базы, чего там экономить-то, полчаса времени?

Конечсно, если это несложно, то можно такое использовать.
Relic Hunter
alexeyvg,

Уже и довольно даво работает.

http://www.netapp.com/us/company/news/press-releases/news-rel-20120904-910321.aspx
Спасибо, почитаю.
3 янв 13, 23:57    [13720992]     Ответить | Цитировать Сообщить модератору
 Re: Организация тестовой базы, с каждодневной актуализацией  [new]
Alderego
Member

Откуда:
Сообщений: 110
Crimean
Alderego,

а у вас, сильно подозреваю, с таким объемом де-факто RO часть данных есть. иначе вы в обновлении статистик / перестроении индексов погрязнете в смысле временных затрат. покопайте в эту сторону. может просто не рассказывают или должным образом не используют?

У нас довольно специфическое приложение и не самая лучшая архитектура. Возможно скорее секционирование для отделения ро файловых групп,но пока не сильно актуально. Индексы и статистика пока не напрягают)
4 янв 13, 00:45    [13721185]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить