SQLskills запускає нову ініціативу щодо розміщення записів з базовими знаннями, ми назвали її SQL101. Ми будемо писати про речі, які, як ми часто бачимо, робляться неправильно, технологіях, які використовуються не так, і про багато непорозумінь, які призводять до серйозних проблем. Якщо ви хочете знайти всі записи в цій серії, перевірте посилання SQLskills.com/help/SQL101 (англійська).
Одне з питань, який мені постійно задають, це чому відновлення бази даних з повною резервної копії займає більше часу, ніж створення повної резервної копії. Відповідь полягає в тому, що в більшості випадків процес відновлення вимагає виконання більшої роботи.
Створення повної резервної копії включає в себе наступні основні стадії:
- Створення контрольної точки.
- Читання всіх використовуваних даних з файлів даних (технічно, читання всіх розміщених екстентів, незалежно від того, яка кількість з 8 сторінок в екстенти насправді використовується).
- Читання журналу транзакцій з початку найстарішою незафіксованою транзакції з початкової контрольної точки до моменту, коли була завершена друга стадія. Це необхідно, щоб база даних могла бути відновлена в узгоджене стан на момент часу, що належить періоду створення резервної копії (подивіться цю статтю (англійська) для докладного пояснення).
- (За бажанням тестування контрольних сум всіх сторінок, опціонально виконання стиснення резервної копії і опціонально шифрування резервної копії).
Відновлення повної резервної копії включає в себе наступні основні стадії:
Стадія 3 часто буває найдовшої стадією при відновленні, і вона пропорційна розміру журналу транзакцій. Цей процес виконується в окремій стадії, замість того, щоб виконуватися паралельно з 1-2 стадією, і для глибокого вивчення дивіться недавню запис в блозі Боба Варда.
Стадія 5 може бути найдовшої стадією в процесі відновлення, якщо в процесі створення резервної копії існували довгі незафіксовані транзакції. І ще більш довгої вона може бути, якщо в журналі транзакцій знаходиться велика кількість віртуальних лог-файли (тисячі), оскільки вони дуже сильно уповільнюють механізм відкату незафіксованих транзакцій.
Тут перелік речей, які ви можете зробити, щоб забезпечити швидке відновлення повної резервної копії:
- Переконайтеся, що миттєва ініціалізація файлів включена для екземпляра SQL Server, який виконує операцію відновлення, щоб уникнути витрати часу на заповнення нулями будь-яких файлів даних, які повинні бути створені. Це може врятувати годинник часу простою для дуже великих файлів даних.
- Якщо можливо - відновлюйте поверх існуючої бази даних - не видаляйте існуючі файли. Це дозволить уникнути необхідності створення і потенційного заповнення нулями повного обсягу файлів, особливо файлів журналу транзакцій. Будьте дуже обережні, використовуючи цей пункт, оскільки існуюча база даних буде безнадійно знищена, як тільки процес відновлення почне перезаписувати її.
- Розгляньте можливість використання стиснення резервних копій, це може прискорити операції і створення та відновлення з резервних копій, і зберегти дисковий простір і витрати на місце зберігання.
- Розгляньте можливість використання декількох файлів резервних копій, кожен з них - на окремому томі. SQL Server розпізнає таку ситуацію і буде використовувати паралельний запис (по одному потоку на том) для записів файлів при створенні резервної копії і при читанні в процесі відновлення - прискорюючи всі процеси. Якщо у вас є кілька файлів бази даних, відбудеться схоже розпаралелювання процесів введення / виводу - забезпечуючи ще більше прискорення.
- Намагайтеся уникати довгих транзакцій, так як вони зажадають довгого часу в процесі відкоту.
- Керуйте вашим журналом транзакцій так, щоб уникнути наявності надлишкової кількості віртуальних файлів журналу, щоб при наявності транзакцій, що вимагають відкату, відкат проводився настільки швидко, наскільки це можливо. Дивіться цей запис в блозі (англійська) для докладного пояснення.
Сподіваюся, це було корисно!