- Đốm nóng là gì?
Aaron là chính xác và tôi sẽ không làm lại những gì anh ấy đã nói ở trên, tuy nhiên đó không chỉ là về đĩa IO. Phần chính mà hầu hết mọi người gặp vấn đề với TempDB là do sự tranh chấp về các cấu trúc theo dõi nhất định.
Vì việc có nhiều tệp tempdb cho phép thuật toán điền và làm tròn theo tỷ lệ có hiệu quả diễn ra trong việc "công bằng" trong các phân bổ, thêm một tệp mới không có phân bổ sẽ loại bỏ một chút. Tôi không đồng ý rằng đó là một cảnh báo "gà nhỏ" (xem các cập nhật sản phẩm bên dưới) nếu bạn bắt đầu thấy PAGELATCH_*
chờ đợi trên tệp mới đã nói và không có nhiều hoặc bất kỳ tệp nào khác. Điều này thường xảy ra trên các hệ thống có hoạt động TempDB cao và đã có nhiều hơn một tệp.
Xin lưu ý rằng có các tùy chọn trong SQL Server 2019 để thay đổi một số bảng hệ thống cơ bản thành các bảng trong bộ nhớ có thể có sự cải thiện vì các đối tượng trong bộ nhớ được phân bổ khác với các bảng nướng đĩa. Các bảng dựa trên đĩa là các bảng truyền thống mà tất cả chúng ta đã làm việc trong nhiều năm qua. SQL Server 2014 đã giới thiệu các bảng được tối ưu hóa bộ nhớ . SQL Server 2019 có thể xử lý một số siêu dữ liệu phân bổ trong các bảng được tối ưu hóa bộ nhớ.
Một thay đổi khác đã được thực hiện trong SQL Server 2019 để giúp thay đổi PFS đồng thời, thường là sự tranh chấp về cấu trúc trong bộ nhớ trong phân bổ đang PAGELATCH_*
chờ đợi.
- Điều gì về đốm nóng làm cho mọi thứ tồi tệ hơn nhiều trong tempdb?
Không có gì IMHO. Có, TempDB có nhiều mục có thể gây ra ghi vào nó mà không được sử dụng trực tiếp để có thể cản trở một số mục. Tuy nhiên, một cơ sở dữ liệu người dùng rất bận rộn về tốc độ thay đổi dữ liệu cũng tệ như vậy. Nó không giới hạn chỉ với TempDB.
- Những điều cụ thể trong DB sẽ trở nên tồi tệ hơn nhiều?
Tôi thực sự thích sự tương tự của Aaron! Đó là bản chất của những gì đang xảy ra. Điều thực sự trở nên tồi tệ hơn là sự phân bổ và theo dõi không gian cho các đối tượng trong cơ sở dữ liệu. Nếu cơ sở dữ liệu người dùng của bạn chủ yếu là tĩnh (tốc độ thay đổi thấp) hoặc TempDB của bạn không thực sự được sử dụng, bạn sẽ không nhận thấy bất cứ điều gì. Tuy nhiên, nếu đó là một máy chủ khá bận rộn, bạn có thể bắt đầu hoặc làm trầm trọng thêm sự chờ đợi của trang web có thể dẫn đến việc chặn các đoàn xe.
Aaron đã chỉ ra rằng trên phiên bản cũ hơn có cờ theo dõi để đảm bảo rằng mức độ đồng đều được sử dụng và tất cả các tệp trong một nhóm fileg cùng phát triển (Aaron chỉ ra 1117 và 1118 là NOP trong năm 2016+). Một điều khác tôi muốn chỉ ra một lần nữa là điều này không chỉ dành cho TempDB mà là cho bất kỳ cơ sở dữ liệu nào và bố cục vật lý nên được suy nghĩ tùy theo nhu cầu.
Điều này không chỉ dành cho các vấn đề về điểm nóng mà còn có thể áp dụng cho các phần khác của hệ thống như sao lưu / khôi phục, quản lý tệp, phân mảnh siêu dữ liệu hệ thống tệp, v.v., tất cả có thể được trợ giúp bằng cách có nhiều tệp.
Bạn có thể thấy sự tranh chấp cấu trúc phân bổ bằng cách tìm kiếm waitresource
trên một trang PFS (là trang 1, và sau đó là mỗi 8088 trang). Nếu bạn thấy rằng tất cả trong cùng một tệp (2: file: page) thì bạn biết điều này đang xảy ra.