Việc ghi vào TempDB luôn dẫn đến việc ghi vật lý thực tế vào đĩa, hoặc ghi TempDB được lưu trữ bởi SQL Server để ghi chậm như trong bộ đệm của hệ thống tệp Windows?
Họ có luôn không? Chắc chắn là không. Họ có bao giờ? Có nhưng không phải là kết quả của cơ chế điển hình. Tham khảo ở đây là Checkpoint làm gì cho tempdb? .
Trong một hệ thống "hoạt động tốt", ghi vào tệp cơ sở dữ liệu người dùng xảy ra trên điểm kiểm tra. Trong một hệ thống hoạt động kém, việc viết cũng sẽ xảy ra khi người lười biếng cần xóa các trang từ nhóm bộ đệm để nhường chỗ cho các trang khác.
Một điểm kiểm tra chỉ được thực hiện cho tempdb khi tệp nhật ký tempdb đạt đầy đủ 70% - điều này là để ngăn chặn nhật ký tempdb phát triển nếu có thể (lưu ý rằng một giao dịch dài hạn về cơ bản vẫn có thể giữ con tin nhật ký và ngăn chặn nó xóa , giống như trong cơ sở dữ liệu người dùng).
Nhưng không cần phải xóa tempdb vào đĩa, vì phục hồi sự cố không bao giờ chạy trên tempdb, nó luôn được tạo lại khi khởi động.
Tempdb không được phục hồi trong trường hợp xảy ra sự cố và do đó không cần phải buộc các trang tempdb bẩn vào đĩa, ngoại trừ trong trường hợp quy trình lười viết (một phần của vùng đệm) phải tạo khoảng trống cho các trang từ cơ sở dữ liệu khác.
Điều đáng chú ý này (đó là một bất ngờ đối với tôi) là cơ chế duy nhất mà các trang tempdb sẽ được ghi vào đĩa. Nếu có áp lực nhóm bộ đệm, các trang tempdb có thể được xóa vào đĩa. Nếu không, nó không nên xảy ra.
Chỉnh sửa: Tranh cãi liệu "hành vi xấu" có phải là một mô tả phù hợp cho cơ sở dữ liệu người dùng đang viết các trang bên ngoài điểm kiểm tra hay không. Không bình thường, không điển hình, hoặc chỉ không lý tưởng có thể?
Chỉnh sửa bổ sung (theo ý kiến / trò chuyện với @PaulWhite):
Thiếu sót rõ ràng ở trên là các bảng tạm thời không phải là nguồn lưu lượng tempdb duy nhất. Trích dẫn từ việc hiểu các sự kiện tràn, sắp xếp và trao đổi :
Một số hoạt động thực thi truy vấn SQL Server nhất định được hiệu chỉnh để hoạt động tốt nhất bằng cách sử dụng một lượng lớn bộ nhớ (phần nào) làm bộ nhớ trung gian. Trình tối ưu hóa truy vấn sẽ chọn gói và ước tính chi phí dựa trên các toán tử này bằng cách sử dụng thẻ nhớ này. Nhưng điều này, tất nhiên, chỉ là một ước tính. Khi thực hiện các ước tính có thể chứng minh sai và kế hoạch phải tiếp tục mặc dù không có đủ bộ nhớ. Trong một sự kiện như vậy, các toán tử này tràn vào đĩa.
Tôi đã giả định không chính xác rằng cơ chế đằng sau một ghi vật lý cho hoạt động tràn chính xác giống như được mô tả trước đó, ví dụ như kẻ lười biếng buộc các trang tempdb vào đĩa do áp lực lên vùng đệm (do sự cố tràn).
@PaulWhite giải thích tôi đã sai ở đâu (cảm ơn Paul!):
Tôi nghĩ bạn đang hỏi tại sao hoạt động tempdb vật lý xảy ra khi một truy vấn vượt quá cấp bộ nhớ vùng làm việc của nó, thay vì chỉ sử dụng tempdb trong bộ nhớ Nếu làm như vậy, truy vấn sẽ sử dụng nhiều bộ nhớ hơn cấp của nó, đánh bại điểm hạn chế bộ nhớ tài trợ ở nơi đầu tiên.
Sự cố tràn thực sự đặc biệt bằng văn bản thông qua lưu trữ. Hoạt động tempdb vật lý được nhìn thấy trên một sự cố tràn, ngay cả khi đối mặt với vô số bộ nhớ trống và áp lực bằng không đối với tempdb.
Paul cũng chỉ cho tôi bài viết trên blog của mình Điều chỉnh TSQL nâng cao: Tại sao các vấn đề kiến thức nội bộ bao gồm các kịch bản ví dụ để thể hiện sự cố tràn, cho những người muốn tìm hiểu sâu hơn.