У чому полягає користь відновлення в головному періоді при виконанні резервного копіювання?

Коли я стежу за резервними копіями, виконуючи наступний запит:

SELECT      command, percent_complete,
            'elapsed' = total_elapsed_time / 60000.0,
            'remaining' = estimated_completion_time / 60000.0
FROM        sys.dm_exec_requests
WHERE       command like 'BACKUP%'
or command like 'RESTORE%'

Я зауважую, що перед тим, як створити резервну копію, SQL Server виконає відновлення головним чином, а потім резервне копіювання.

Мені було цікаво, для чого це було корисно і чи час його виконання можна якось скоротити. Здається, це займе більше часу, ніж фактичне резервне копіювання.

Я зауважую, що перед тим, як створити резервну копію, SQL Server виконає відновлення головним чином, а потім резервне копіювання.

Це може бути частиною етапів відновлення, які виконуються внутрішньо сервером sql.

Ви можете переглянути фази відновлення за допомогою DBCC TRACEON(3604, 3605, 3004);. Використовуйте його лише з навчальною метою на сервері NON PROD.

Як ви бачите вище, що по суті є 3 основні фази відновлення - копіювання даних, скасування та повтор фази разом з іншими підфазами, де в ньому відкривається і завантажується також резервний набір.

Здається, це займе більше часу, ніж фактичне резервне копіювання.

Щоб покращити час відновлення, слід

• Увімкнути миттєву ініціалізацію файлів.
• Використовуйте T-SQL та відновіть with REPLACEнаявну базу даних замість того, щоб випадати та відновлювати.
• Переконайтеся, що ви правильно підтримуєте msdb.
• Перевірте наявність ЛЗС. Чим більше VLF, тим довше час відновлення.

Зверніться до няні для повільної резервної копії або відновлення за допомогою @AaronBertrand .

RESTORE HEADERONLY дозволяє SQL Server перевіряти цільовий файл на певні властивості перед фактичною резервною копією.

Ви можете запобігти цьому, запустивши резервні копії за допомогою T-SQL BACKUP DATABASE ...у завданні агента SQL Server замість використання графічного інтерфейсу плану технічного обслуговування, що рясніє проблемами.

RESTORE HEADERONLYможе зайняти багато часу, якщо ваша резервна копія містить багато віртуальних файлів журналу (VLF). Ви можете мати певний успіх у вирішенні періоду часу, необхідного для відновлення, якщо зменшити та переробити файл журналу джерел баз даних до відповідного розміру.