SQLskills запускает новую инициативу по размещению записей с базовыми знаниями, мы назвали ее SQL101. Мы будем писать о вещах, которые, как мы часто видим, делаются неправильно, технологиях, которые используются неверно, и о многих недопониманиях, которые приводят к серьезным проблемам. Если вы хотите найти все записи в этой серии, проверьте ссылку SQLskills.com/help/SQL101 (английский).
Один из вопросов, который мне постоянно задают, это почему восстановление базы данных из полной резервной копии занимает больше времени, чем создание полной резервной копии. Ответ заключается в том, что почти всегда процесс восстановления требует выполнения большей работы.
Создание полной резервной копии включает в себя следующие главные стадии:
- Создание контрольной точки.
- Чтение всех используемых данных из файлов данных (технически, чтение всех размещенных экстентов, независимо от того, какое количество из 8 страниц в экстенте на самом деле используется).
- Чтение журнала транзакций с начала самой старой незафиксированной транзакции с начальной контрольной точки до момента, когда была завершена вторая стадия. Это необходимо, чтобы база данных могла быть восстановлена в согласованное состояние на момент времени, принадлежащий периоду создания резервной копии (посмотрите эту статью (английский) для подробного объяснения).
- (Опционально тестирование контрольных сумм всех страниц, опционально выполнение сжатия резервной копии и опционально шифрование резервной копии).
Восстановление из полной резервной копии включает в себя следующие главные стадии:
- Создание файлов данных (и заполнение их нулями, если не разрешена мгновенная инициализация файлов (английский, хорошая альтернатива на русском).
- Копирование данных из резервной копии в файлы данных.
- Создание файла журнала транзакций и заполнение его нулями. Файл журнала транзакций должен быть всегда заполнен нулями при создании (посмотрите эту статью (английский) для подробного объяснения).
- Копирование журнала транзакций из резервной копии в файл журнала.
- Запуск восстановления после сбоя на базе данных.
- (Опционально тестирование контрольных сумм всех страниц во время второй фазы, выполнение распаковки, если резервная копия была сжата, выполнение расшифровки, если резервная копия была зашифрована.)
Стадия 3 часто бывает самой долгой стадией при восстановлении, и она пропорциональна размеру журнала транзакций. Этот процесс выполняется в отдельной стадии, вместо того, чтобы выполняться параллельно с 1-2 стадией, и для глубокого изучения смотрите недавнюю запись в блоге Боба Варда.
Стадия 5 может быть самой долгой стадией в процессе восстановления, если в процессе создания резервной копии существовали долгие незафиксированные транзакции. И еще более долгой она может быть, если в журнале транзакций находится большое количество виртуальных файлов журнала (тысячи), поскольку они очень сильно замедляют механизм отката незафиксированных транзакций.
Здесь перечень вещей, которые вы можете сделать, чтобы сделать восстановление из полной резервной копии быстрее:
- Убедитесь, что мгновенная инициализация файлов включена для экземпляра SQL Server, который выполняет операцию восстановления, чтобы избежать траты времени на заполнение нулями любых файлов данных, которые должны быть созданы. Это может спасти часы времени простоя для очень больших файлов данных.
- Если возможно — восстанавливайте поверх существующей базы данных — не удаляйте существующие файлы. Это позволит избежать необходимости создания и потенциального заполнения нулями полного объема файлов, особенно файлов журнала транзакций. Будьте очень осторожны, используя этот пункт, поскольку существующая база данных будет безнадежно уничтожена, как только процесс восстановления начнет перезаписывать ее.
- Рассмотрите возможность использования сжатия резервных копий, это может ускорить операции и создания и восстановления из резервных копий, и сохранить дисковое пространство и затраты на место хранения.
- Рассмотрите возможность использования нескольких файлов резервных копий, каждый из них — на отдельном томе. SQL Server распознает такую ситуацию и будет использовать параллельную запись (по одному потоку на том) для записей файлов при создании резервной копии и при чтении в процессе восстановления — ускоряя все процессы. Если у вас есть несколько файлов базы данных, произойдет похожее распараллеливание процессов ввода/вывода — обеспечивая еще большее ускорение.
- Пытайтесь избегать долгих транзакций, так как они потребуют долгого времени в процессе отката.
- Управляйте вашим журналом транзакций так, чтобы избежать наличия избыточного количества виртуальных файлов журнала, чтобы при наличии транзакций, требующих отката, откат производился настолько быстро, насколько это возможно. Смотрите эту запись в блоге (английский) для подробного объяснения.
Надеюсь, это было полезно!
Автор: minamoto
