[SQL Server] 為什麼Restore會比Backup久?

本文說明:

  1. Full Backup步驟
  2. Restore步驟
  3. 如何減少Restore時間
  4. 什麼是Instant file initialization

 

Full Backup的主要步驟:

  1. 做checkpoint (將dirty page寫入data files)
  2. 讀data files裡有被分配使用到的extent
  3. 讀取所有還沒commit的transaction log,直到check point結束 (詳細說明網址)
  4. (Option) 做備份壓縮,或備份加密

Restore的主要步驟:

  1. 創建Data files (如果沒有Enable Instant File Initialization, 會做Zero Initialize)
  2. 從備份檔複製資料進去Data files
  3. 創建Log files(Zero Initialize)
  4. 從備份檔複製Transaction log進去Log files
  5. 開始做recovery,把在backup過程中來不及commit的transaction rollback
  6. (Option) 做解壓縮,或解密備份檔

其中Restore的步驟1和2是分開做的,而不是同時做。

而Restore的步驟中,步驟3有可能會是時間花最長的,因為創建log files沒辦法使用 Instant File Initialization,導致在創建新的log file時,需要將page都寫0,需要花額外時間(詳細說明網址

WHY Log file不適用?

Data file裡面有GAM、SGAM、PFS...etc,很多內部的page來指向正確的Extent和Page頁,所以不會將不屬於自己的Page當成自己的,導致讀到錯誤的Page,但Log file沒有這個功能,所以為了避免讀到錯誤的Page,就必須要將所有新創建的Page都重新寫0

如何減少Restore的時間?

  1. 確保Instant file initialization是Enable
  2. 如果可以,就使用replace現有db的功能,不要刪掉現有的files,可以省掉一些重新創建files的時間,特別是log files
  3. 可以使用備份壓縮,加速備份和還原
  4. 拆開備份檔也能使備份與還原的速度加快 (詳細說明網址)
  5. 避免在備份DB時有跑很久的running transaction,會導致recovery時花很多時間roll back
  6. 避免過多的Virtual log files,也會導致recovery速度過慢 (可以shrink Log file降低VLF)

Zero file initialization:

想要create新的space時,系統會自動用0填滿新的file space

Instant file initialization

只有data file可以用,直接把space create出來,不要用0填滿,好處是快,不會耗時間把新的data files寫成0,然後有資料進來後再直接覆蓋掉

三種情況會發生Instant file initialization:

  1. Create new DB
  2. Expand page
  3. DB backup and restore

PS: 關於Instant Initialization如何設定可以參考此篇文章