Loại bỏ các tệp dữ liệu thứ cấp. DBCC SHRINKFILE: Không thể di chuyển trang vì đây là trang bảng làm việc


10

Tôi có quá nhiều tệp dữ liệu thứ cấp (.ndf) được tạo cho tempdb. Để xóa các tệp thừa, tôi cần làm trống tệp (nội dung sẽ được chuyển sang các tệp khác):

DBCC SHRINKFILE('tempdbfile8', EMPTYFILE);

và sau đó xóa tệp:

ALTER DATABASE tempdb REMOVE FILE tempdbfile8;

Nhưng EMPTYFILElệnh trả về lỗi:

DBCC SHRINKFILE: Page 8:41920 could not be moved because it is a work table page.
Msg 2555, Level 16, State 1, Line 2
Cannot move all contents of file "tempdbfile8" to other places to complete the emptyfile operation.

Đừng lo lắng, tôi chỉ cần xác định vị trí của đối tượng đang sử dụng trang này để làm gì đó với nó:

DBCC TRACEON (3604)
DBCC PAGE(2,8,41920) --dbid=2, fileid=8, pageid=41920

Lệnh trả về rất nhiều thông tin, object_id trong số đó. Nhưng:

Metadata: ObjectId = 0 

Tôi không biết phải làm gì về nó. Con mèo nào ngăn trang này khỏi bị di chuyển? Làm thế nào để xác định vị trí của đối tượng, quá trình, phiên hoặc bất cứ điều gì? Bất kỳ trợ giúp sẽ được đánh giá cao, nhưng xin lưu ý rằng để lại mọi thứ như nó là hoặc loại bỏ các tập tin khác thay vào đó không phải là một giải pháp hợp lệ cho vấn đề này;).

BIÊN TẬP:

Tôi đang xóa các tệp vì chúng tôi thường tuân theo "thực tiễn tốt nhất" về việc tạo một tệp cho mỗi lõi bộ xử lý (cùng kích thước ban đầu, cùng tốc độ tăng trưởng). Nhưng theo như tôi biết, cho đến khi bạn gặp phải vấn đề tranh chấp, sẽ không có điểm nào để tạo các tệp tempdb bổ sung trên cùng một thiết bị. Trong trường hợp của chúng tôi, điều đó có ý nghĩa, bởi vì chúng tôi đã bật MPIO và thiết bị lưu trữ có thể xử lý 4 đường dẫn. Nhưng có một lỗi và chúng tôi đã kết thúc với tổng số 5 tệp với cpu 6 lõi. Đó là nhiều hơn các đường dẫn MPIO, ít hơn các lõi CPU và nó không phải là một số chẵn. Nó có thể không gây ra bất kỳ vấn đề nào, nhưng có vẻ không đúng :).

Cuối cùng tôi đã có thể làm trống và xóa tệp mà không cần khởi động lại máy chủ bằng cách đặt một trong các cơ sở dữ liệu (mà tôi nghi ngờ gây ra sự cố) sang chế độ người dùng (quay lại ngay lập tức). Nó đã làm việc, nhưng tôi đã gặp may mắn. Điều tôi thực sự muốn, là luôn có thể theo dõi trang này :).


Lệnh DBCC PAGE không chính xác, nó phải giống như trang dbcc (2.41920,1). 1,2,3 phụ thuộc vào những gì bạn muốn ở đầu ra.
Shanky

Nếu ở trên không hoạt động, bạn có thể phải làm điều đó trong phần cứng bằng cách xóa các tệp và sau đó khởi động lại máy chủ sql để nó chỉ sử dụng các tệp không bị xóa. Bạn có thể tham khảo liên kết này daveturpin.com/2011/07/how-to-drop-a-tempdb-database-file
Shanky

2
@Shanky Lệnh này đúng. 0..3 có thể được thông qua dưới dạng tham số thứ 4: dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])Về giải pháp của bạn: nó sẽ hoạt động, nhưng tôi thực sự muốn làm điều này mà không đưa trường hợp xuống.
Adam Luniewski

Ok..Tôi đã nói với bạn hình thức trang dbcc đơn giản hơn. Xin lưu ý là lệnh không có giấy tờ. Bạn đã kiểm tra liên kết tôi đã đăng chưa
Shanky

1
Tôi không nghĩ rằng có thể giải quyết vấn đề này mà không cần khởi động lại ví dụ. Rõ ràng là bạn đã cố gắng theo dõi xem bàn làm việc này là gì (điều này sẽ giúp xác định ai sở hữu nó) và điều đó đã thất bại. Hãy nhấn hoặc sống với các tệp bổ sung cho đến khi bạn có thể khởi động lại.
Aaron Bertrand

Câu trả lời:


5

Khởi động lại máy chủ là đủ - những bàn làm việc đó sẽ bị xóa. Nhưng tôi có thể khởi động nó ở chế độ người dùng (-m) để ngăn các quá trình khác tạo các bàn làm việc trước khi bạn xóa thành công các tệp đó. Sau đó xác định lại các tập tin cần thiết cho tempdb; có lẽ xóa các tệp không cần thiết, thay đổi kích thước, v.v. Bạn cũng nên đảm bảo rằng bạn có số lượng tệp chẵn, tất cả chúng đều được đặt ở cùng kích thước và tất cả chúng đều có cùng cài đặt tự động phát triển (tính bằng MB, không phải%). Và đây có thể là thời điểm tốt để xem xét TF 1117 và TF 1118 ( điểm bắt đầu ).

Tôi sẽ rất cảnh giác về đề xuất chỉ xóa các tệp khỏi hệ thống tệp trước khi khởi động lại SQL Server - nó có thể không bắt đầu.

(Tuy nhiên, tôi cũng tò mò về vấn đề thực sự là gì. Có quá nhiều tệp không thực sự làm bạn tổn thương.)


@@ Aaron ofcference bạn cần thận trọng về việc loại bỏ nó phải trống, nhưng điều đó được ghi lại ở đây msdn.microsoft.com/en-gb/l Library / ms175574.aspx . Đã dùng thử và máy chủ tempdb SQl trực tuyến.
Shanky

5
@Shanky tôi đã cố gắng lái xe 138 dặm một giờ một lần, và tôi đã không nhận được kéo lên. Điều đó có nghĩa là tôi nên tiếp tục làm điều đó, và rằng không có cơ hội nào tôi sẽ bị kéo vào ngày mai? An toàn hơn nhiều để thử cách thích hợp trước, trước khi đề xuất một cách mạo hiểm hơn. IMHO. Đặc biệt là vì anh ấy không thể làm trống tập tin ngay bây giờ - bạn có nghĩ rằng có thể có bất cứ điều gì khác trong đó ngoài khả năng thông báo lỗi đang phàn nàn không? Lỗi không tạo ra một danh sách đầy đủ của tất cả các đối tượng, nó chỉ xuất ra đối tượng đầu tiên .
Aaron Bertrand

Có một cái gì đó thực sự đang sử dụng tempdb vì vậy nó không cho phép nó để trống tập tin khó đoán. Có thể anh ta đã sử dụng toán tử sort là một số truy vấn vẫn cần tempdb. DMV có thể giúp tìm kiếm sys.dm_db_task_space_usage sys.dm_db_session_space_usage sys.dm_db_file_space_usage
Shanky

Khởi động lại là tùy chọn ở đây nhưng ngay cả khi anh ta không làm trống tệp và thử thả tệp tempdb, nó sẽ nói rằng tệp tempdb không thể bị hủy nhưng đồng thời danh mục hệ thống được cập nhật và sau khi khởi động lại, tệp sẽ biến mất. Đây là tôi đoán hành vi mặc định với tempdb vì vậy tôi đã đề xuất và vẫn nghĩ rằng việc xóa tệp dữ liệu sẽ hoạt động ngay cả khi nó được sử dụng. Tương tự là có trong liên kết tôi đã đăng trong bình luận thứ hai của tôi.
Shanky

1
@Shanky những DMV đó có thể trả về hàng ngàn hàng cho tất cả các loại điều không liên quan đến tệp đang được đề cập - vậy bạn dự định thu hẹp nó như thế nào? Ngoài ra, với phương pháp của bạn, bạn cũng phải khởi động lại, tại sao không thử cách đơn giản hơn trước? Tôi chỉ không đồng ý với bạn rằng "cách khó khăn" nên là gợi ý đầu tiên, xin lỗi.
Aaron Bertrand

2

https://social.msdn.microsoft.com/Forums/en-US/2a00c314-f35e-4900-babb-f42dcde1944b/dbcc-shrinkfile-page-411283400-could-not-be-mbed-because-it-is a-work-table-page? forum = sqldatabaseengine

Theo đề xuất của Mike trong diễn đàn msDN, các bảng công việc chủ yếu được liên kết với bộ đệm kế hoạch. Xóa chúng cũng sẽ loại bỏ bảng làm việc và sau đó bạn có thể thu nhỏ Tempdb. Điều này làm việc cho tôi. Và điều này giúp bạn tiết kiệm khởi động lại máy chủ. Sẽ có một số chi phí vì máy chủ SQL sẽ phải tạo lại các kế hoạch thực hiện.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.