Что я могу добавить на сервер, чтобы ускорить восстановление SQL?

У меня есть база данных SQL объемом 2,8 ТБ (в основном файлы данных, около 400 ГБ файлов журналов), восстановление которой в настоящее время занимает около 9 часов. Эта база данных используется в целях тестирования и должна быть удалена и восстановлена из резервной копии между каждым запуском, чтобы убедиться, что мы всегда начинаем с одной и той же точки.

Мой вопрос заключается в том, что сервер в настоящее время имеет 12 ядер и 92 ГБ оперативной памяти с дисковой подсистемой RAID 5, в которой находится база данных. Какие области обычно вызывают узкие места для процессов восстановления SQL? Это диск, память или процессор?

sql-server performance

— Шон Лонг
источник

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

— Крис Мак-

.Bak (8 из них разделены) находятся в том же массиве RAID 5, в который они восстанавливаются, что позволяет мне понять, что я, вероятно, справлюсь с этим в будущем. У меня нет другого массива, достаточно большого, чтобы вместить все файлы .bak, но я мог бы разделить их на разные диски с прямым подключением. Кроме того, хорошее замечание по поводу RAID 5. Я знаю об этом, но мы еще не проводим стресс-тестирование, так что хорошо, если оно сейчас является узким местом на диске во время реальных нагрузочных тестов. Как только мы продвинемся немного дальше, мы увеличим производительность диска с помощью SAN, RAID 0 или RAID 1 + 0

— Шон Лонг,

Конечно, ваши чрезмерные страдания из-за наличия резервных копий на диске, который вы также восстанавливаете. Сколько дисков в вашем текущем RAID5?

— Марк Стори-Смит

Я полагаю, вы используете сжатие. Какие еще варианты резервного копирования вы используете? Как ваши данные разделены? Можете ли вы интеллектуально распределить данные по файловым группам (тогда вы можете просто делать резервные копии файловых групп и восстанавливать измененные данные)?

— swasheck

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

— Шон Лонг

Ответы:

Основным узким местом восстановления будет дисковый ввод-вывод. Чтобы это исправить, вам нужны либо более быстрые диски, либо другая конфигурация. Я не знаю достаточно о RAID или SAN, чтобы предложить что-то там, хотя. Вы могли бы даже рассмотреть SSD. Они ослепительно быстрые. Я не хотел бы использовать их для чего-то, что не воссоздается на регулярной основе (tempdb всегда является хорошим кандидатом для этого), но, поскольку вы часто его восстанавливаете, это может быть нормально. С другой стороны, вы, вероятно, хотите убедиться, что ваш тестовый сервер максимально приближен к вашему рабочему серверу, если вы проводите тестирование производительности.

Есть несколько других вещей, которые вы можете сделать, чтобы помочь себе. Сначала сожмите свои резервные копии, если вы еще этого не сделали. Это, конечно, предполагает SQL 2008 или выше. Это сократит не только дисковое пространство для хранения резервной копии, но и ввод-вывод для ее чтения. При этом необходимо учитывать затраты ЦП, так что имейте это в виду. Также не удаляйте свою базу данных, просто восстановите ее. Таким образом, файлы уже на месте, и нет никаких накладных расходов на их создание. Вы можете включить мгновенную инициализацию файла (это разрешение на уровне сервера), чтобы значительно ускорить создание / рост файла для вашего файла данных, но он не будет работать для вашего файла журнала.

— Кеннет Фишер
источник

Хорошая информация, я не осознавал, что восстановление поверх существующего лучше, чем удаление / восстановление из резервной копии. Мы уже используем сжатие, и я планирую убедиться, что для учетной записи, выполняющей восстановление, включена мгновенная инициализация файла. Я очень ценю четкость вашего ответа, спасибо!

— Шон Лонг

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

— Кеннет Фишер

Хороший звонок. Также спасибо за понимание того, что тестирование производительности не всегда означает стресс-тестирование (и что я довольно ограничен тем, как настроена моя производственная конфигурация, в настоящее время).

— Шон Лонг

ОТ: «Рассмотрим SSD. ... Я бы не хотел использовать их для чего-то, что не воссоздается на регулярной основе» ... почему?

— Мартин

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

— Кеннет Фишер

Не делайте резервную копию и восстанавливайте; использовать снимки SQL Server. Требуется много места на диске для хранения разреженных файлов того же размера, что и файлы, которые вы сделали моментальными снимками, но откат выполняется в сотни раз быстрее.

Они доступны в редакциях SQL Server Enterprise и SQL Server Developer.

— Марк Хендерсон
источник

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

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

— Марк Хендерсон

Предложение @SeanLong Марка, вероятно, лучший вариант для вашего сценария. Я думаю, что вы неправильно понимаете, когда и что вы делаете снимок. План на тестовом сервере будет состоять в том, чтобы восстановить тестовую базу данных из вашей оперативной резервной копии, затем сделать снимок тестовой базы данных, запустить тестовый цикл, а затем отменить моментальный снимок, промыть и повторить. Периодически вы можете возвращаться к шагу 1 и восстанавливать оперативную резервную копию для повторного тестирования.

— Марк Стори-Смит

Ах я вижу. Я думал, что поддержание моментального снимка потребует постоянной нагрузки от тестовой базы данных, что повлияет на наши (очень тяжелые записи / чтения) нагрузки. Я не возражаю, если наша рабочая нагрузка вызывает узкое место на диске, я просто не хочу, чтобы внешний фактор (который я думал db snapshotting будет) вызвать его.

— Шон Лонг