Tại sao phục hồi cơ sở dữ liệu mất nhiều thời gian?

Trong phiên bản SQL Server 2012 x64 Std của tôi, tôi đã gặp một lỗi giao dịch lớn do nhật ký giao dịch được điền vào ngày hôm qua, nó không thể được khôi phục và SQL Server đã khởi động lại DB cụ thể để thực hiện phục hồi.

DB có dung lượng khoảng 750 GB với tlog đạt 170 GB (công việc ETL rất lớn đang chạy). Công việc chỉ chạy trong vài giờ nhưng quá trình phục hồi đã mất> 24 giờ (hoàn thành 70%, vào giai đoạn 3 của 3).

Những gì tôi không thể hiểu nó tại sao nó mất quá nhiều thời gian? Dường như không có bất kỳ áp lực nào đối với các đĩa, sys.dm_exec_requestscho thấy nó đang chờ PAGEIOLATCH_EX/SH, điều mà tôi mong đợi. Tôi đã có thể khôi phục toàn bộ DB trong thời gian này ...

Nếu bất cứ ai có thể làm sáng tỏ, nó sẽ được đánh giá rất cao.

EDIT: Theo yêu cầu, nhận đầu ra của nhật ký lỗi:

Recovery of database 'MyDB' (6) is 77% complete (approximately 28100 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.
Recovery of database 'MyDB' (6) is 77% complete (approximately 28095 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.
Recovery of database 'MyDB' (6) is 77% complete (approximately 28099 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.
Recovery of database 'MyDB' (6) is 77% complete (approximately 28102 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.
Recovery of database 'MyDB' (6) is 77% complete (approximately 28097 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.

Ngoài ra, sys.dm_exec_requeststhông tin bạn sau:

session_id  command status  percent_complete
35  DB STARTUP  background  86.06061

IFI và "Thực hiện các nhiệm vụ bảo trì khối lượng" được bật / cấp.

Tôi đã có một giao dịch lớn thất bại do nhật ký giao dịch được lấp đầy vào ngày hôm qua, nó không thể được khôi phục và SQL Server đã khởi động lại DB cụ thể để thực hiện phục hồi.

Điều này không hoàn toàn chính xác khi một giao dịch bắt đầu trong SQL Server, nó dự trữ không gian trong nhật ký giao dịch trong trường hợp giao dịch phải quay trở lại. Từ kiến trúc Nhật ký giao dịch BOL doc

Hoạt động rollback cũng được ghi lại. Mỗi giao dịch dự trữ không gian trên nhật ký giao dịch để đảm bảo có đủ không gian nhật ký để hỗ trợ cho việc khôi phục được gây ra bởi một tuyên bố khôi phục rõ ràng hoặc nếu gặp phải lỗi. Lượng không gian dành riêng phụ thuộc vào các hoạt động được thực hiện trong giao dịch, nhưng nhìn chung nó bằng với dung lượng được sử dụng để ghi nhật ký mỗi hoạt động. Không gian dành riêng này được giải phóng khi giao dịch hoàn tất

Vì vậy, tôi đoán bạn có thể hiểu bây giờ.

Những gì tôi không thể hiểu nó tại sao nó mất quá nhiều thời gian?

Hoạt động rollback truy vấn là mostly single threadedtrong khi khi cùng một truy vấn thực thi, nó có thể sử dụng song song / nhiều luồng để thực hiện cùng một thao tác làm cho nó rất nhanh so với rollback. Tôi đề nghị bạn đọc những gì Bob Dorr nói về việc rollback mất nhiều thời gian . Để hiểu rõ hơn về những gì xảy ra khi rollback đang diễn ra, vui lòng đọc bài viết này . Khởi động lại dịch vụ SQL Server sẽ không giúp được gì nhiều, sau khi khởi động lại quy trình rollbak phải bắt đầu lại. Bạn phải chờ và để quá trình rollback hoàn thành.

Bạn cũng có thể sử dụng sys.dm_exec numquests để theo dõi rollback của mình.

select    
session_id,     
command,     
status,     
percent_complete    
from sys.dm_exec_requests    
where command IN ('killed/rollback','rollback','db_startup')

Một lý do khác mà Remus đề cập là quá nhiều VLF . Nếu bạn phải phục hồi nhiều VLF có thể mất nhiều thời gian. Ngoài ra yếu tố khác có thể trì hoãn phục hồi là nếu tài khoản dịch vụ SQL Server không có Perform Volume maintenacce task right or instant file initialization. Bạn có thể sử dụng liên kết này để kiểm tra xem IFI có mặt hay không.

BIÊN TẬP:

Từ đầu ra bạn đã đăng

session_id  command status  percent_complete
35  DB STARTUP  background  86.06061

Quá trình khởi động 86 % complete.chỉ cần tiếp tục theo dõi nó, cuối cùng nó sẽ hoàn thành. Cũng như quy trình rollback đã nêu có thể bị chặn và có thể phải chờ đợi, vì vậy hãy tiếp tục theo dõi điều đó.

Tiêu chuẩn 2012 x64 SP2

Bạn có phiên bản tiêu chuẩn không thể tận dụng phục hồi nhanh hiện có trong phiên bản doanh nghiệp. Với cơ sở dữ liệu phục hồi nhanh có thể xuất hiện trực tuyến sau giai đoạn phục hồi thứ hai (giai đoạn làm lại) tuy nhiên đây không phải là trường hợp nên xin vui lòng đọc bài viết. Là một bài đọc bổ sung, bạn có thể đọc Khi nào phục hồi nhanh được sử dụng . Giới hạn phiên bản tiêu chuẩn có thể là một lý do nữa khiến nó mất thời gian cơ sở dữ liệu để trực tuyến.

Một điều khác, phiên rollback (35) tự nó chặn quá trình hệ thống khác thực hiện CHECKPOINT

Có, nó có thể và bạn không thể làm bất cứ điều gì vì bạn không kiểm soát được quy trình hệ thống theo cách bạn không thể giết nó.