Tại sao tình trạng của DbccFilesCompact có thể bị đình chỉ?

Tôi đang chạy tệp SHRINK trên tệp dữ liệu 600G.

Hiện tại, trạng thái được báo cáo là "bị treo" và sys.dm_exec_requests.percent_completeđối với DbccFilesCompactcác báo cáo lệnh rằng nó đang chạy (nhưng rất chậm)

Có cách nào để kiểm tra tại sao nó bị treo và làm thế nào để nó chạy mượt hơn không?

FYI - Truy vấn SQL để kiểm tra trạng thái

select T.text, R.Status, R.Command, DatabaseName = db_name(R.database_id)
       , R.cpu_time, R.total_elapsed_time, R.percent_complete
from   sys.dm_exec_requests R
       cross apply sys.dm_exec_sql_text(R.sql_handle) T
order by Command

Không, bạn không thể kiểm tra lý do tại sao nó chạy chậm, nhưng tôi có thể cung cấp cho bạn một số gợi ý:

1) Trong SQL 2005, việc quản lý các chỉ mục không bao gồm đã thay đổi từ Bộ lưu trữ (nhóm của tôi) thành Bộ xử lý truy vấn. Điều này có nhiều tác dụng phụ, một trong số đó là tốc độ mà các trang dữ liệu heap có thể được di chuyển bằng cách thu nhỏ. Tất cả các bản ghi chỉ mục không bao gồm chứa một liên kết ngược đến bản ghi dữ liệu mà chúng đang lập chỉ mục - trong trường hợp của một heap, đây là một liên kết vật lý đến một số bản ghi trên một trang dữ liệu cụ thể. Khi một trang dữ liệu heap được di chuyển bằng cách thu nhỏ, tất cả các bản ghi chỉ mục không bao gồm các liên kết ngược tới các bản ghi trên trang đó phải được cập nhật với vị trí mới của trang. Năm 2000, việc này được thực hiện rất hiệu quả bởi chính Storage Engine. Trong năm 2005 trở đi, điều này phải được thực hiện bằng cách gọi Bộ xử lý truy vấn để cập nhật các bản ghi chỉ mục không bao gồm. Điều này đôi khi chậm hơn tới 100 lần so với năm 2000.

2) Giá trị LOB ngoài hàng (dữ liệu LOB thực tế hoặc dữ liệu tràn hàng) không chứa liên kết ngược đến dữ liệu hoặc bản ghi chỉ mục mà chúng là một phần của. Khi một trang của các bản ghi LOB được di chuyển, toàn bộ bảng hoặc chỉ mục chúng là một phần phải được quét để tìm ra bản ghi dữ liệu / chỉ mục nào trỏ đến chúng, để chúng có thể được cập nhật với vị trí mới. Điều này cũng rất, rất chậm.

3) Có thể có một quy trình khác sử dụng cơ sở dữ liệu khiến cho việc thu hẹp bị chặn chờ các khóa mà nó cần để di chuyển các trang xung quanh.

4) Bạn có thể bật tính năng cách ly ảnh chụp nhanh và thu nhỏ không thể di chuyển các trang có liên kết cửa hàng phiên bản cho đến khi các giao dịch yêu cầu các phiên bản cũ hơn hoàn thành.

5) Hệ thống con I / O của bạn có thể bị thiếu. Độ dài hàng đợi đĩa cao hơn các chữ số đơn thấp có nghĩa là hệ thống con I / O của bạn trong nút cổ chai.

Bất kỳ hoặc tất cả những điều này có thể góp phần làm chậm thời gian thu hẹp.

Nói chung, bạn không muốn chạy co lại. Xem bài đăng trên blog này để biết chi tiết: Tại sao bạn không nên thu nhỏ tệp dữ liệu của mình .

Hi vọng điêu nay co ich!

Bạn có thể chạy tập lệnh này để kiểm tra tỷ lệ phần trăm hoàn thành!

SELECT 
    percent_complete, 
    start_time, 
    status, 
    command, 
    estimated_completion_time, 
    cpu_time, 
    total_elapsed_time
    --,*
FROM 
    sys.dm_exec_requests
WHERE
    command = 'DbccFilesCompact'

Tôi đang thu hẹp cơ sở dữ liệu trong SQL Server 2008 SP1 và một cách tôi có thể cho biết tiến trình của lệnh Shrink là bằng cách thực thi sp_lock spid và đối với hầu hết tôi có thể thấy rằng nó đặt khóa trên tệp 1 sau đó khi thực hiện xong khóa trên tệp id 2, v.v. và bằng cách này tôi có thể biết khi nào nó hoạt động trên id tệp cuối cùng và đây là dấu hiệu của tôi gần như đã hoàn tất.

Cảm ơn,

Alex

Tôi đã phát hiện ra vấn đề là gì (trong trường hợp của tôi) và tôi đưa ra giải pháp tôi đã sử dụng ở đây.

Tôi không có gì khi sử dụng cơ sở dữ liệu và chủ là cơ sở dữ liệu mặc định trong phiên của tôi, tôi đã xác minh rằng sử dụng sp_who2. Sau đó, tôi nhấp chuột phải vào cơ sở dữ liệu, chọn "tác vụ" và sau đó "thu nhỏ" và vào hộp thoại "ok". Cheking một lần nữa với sp_who2, trạng thái bị "treo" trong vài phút và sau đó bị hủy bỏ "không thể có được khóa độc quyền". Tự đoán, nhưng tôi chắc chắn rằng chính hộp thoại là nguyên nhân gây ra điều đó.

Vì vậy, tôi quyết định đi qua dòng lệnh bằng cách sử dụng:

DBCC SHRINKDATABASE (myDataBase)

(Phù thủy ở khắp mọi nơi được ghi lại), Sau đó, thu nhỏ chỉ mất vài giây.