Phát hiện nóng trong bối cảnh thêm tệp vào tempdb là gì?


12

Tôi đang cố gắng tìm hiểu xem có thể thêm tệp tempdb vào Máy chủ SQL mà không phải khởi động lại dịch vụ SQL Server hay không. Tôi thấy câu trả lời này ở đây trên Quản trị viên cơ sở dữ liệu:

Và một câu trả lời nêu rõ:

THÊM - không mất điện. Mặc dù như Sean từ Microsoft đã chỉ ra, SQL sẽ thích sử dụng các tệp được điền thấp hơn. Nếu bạn đang đi từ 1 tệp dữ liệu và thêm nhiều hơn, thì SQL sẽ sử dụng các tệp mới trong một thời gian, nhưng hiệu suất của bạn sẽ không tệ hơn là chỉ có một tệp. Tuy nhiên, nếu bạn đã có 2+ và thêm một cái nữa, thì nó sẽ hotspot trên cái mới và giảm hiệu suất.

Tuy nhiên, một bình luận cảnh báo như sau:

Tôi sẽ đặt phần phụ lục vào phần "Thêm": "Thêm: Không, nhưng rất có thể bạn sẽ bị mất cân bằng vì vậy bạn sẽ bị phát hiện nóng khiến mọi thứ tồi tệ hơn nhiều."

Tôi có những câu hỏi sau đây về nhận xét đó nhưng được hướng dẫn đặt những câu hỏi đó trong một câu hỏi mới của riêng tôi (câu hỏi này) thay vì hỏi người bình luận qua nhận xét trong câu trả lời của câu hỏi đó.

Đặc biệt:

  1. Đốm nóng là gì? (Tôi đã nhận được một số thông tin qua Google nhưng không chi tiết về những gì xảy ra với điểm nóng trên tempdb sau khi thêm tệp)
  2. Điều gì về đốm nóng làm cho mọi thứ tồi tệ hơn nhiều trong tempdb?
  3. Những điều cụ thể trong DB sẽ trở nên tồi tệ hơn nhiều?

Câu trả lời:


16
  1. Đốm nóng là gì?

    "Phát hiện nóng" trong ngữ cảnh này có nghĩa là, mặc dù tempdb có nhiều tệp, tất cả công việc I / O đang được thực hiện trong một tệp duy nhất. Nếu tempdb đủ bận để biện minh cho việc thêm tệp, sự mất cân bằng dẫn đến phát hiện nóng (do tỷ lệ lấp đầy ) sẽ tồn tại trong thời gian ngắn, vì vậy tôi nghĩ rằng các cảnh báo có thể là một chút Chicken Little. Theo kinh nghiệm của tôi, dù sao đi nữa.

  2. Điều gì về đốm nóng làm cho mọi thứ tồi tệ hơn nhiều trong tempdb?

    Tôi nghĩ rằng nó được coi là tồi tệ hơn trong tempdb bởi vì nó chiếm phần lớn hoạt động ghi trong hầu hết các khối lượng công việc. Bạn chắc chắn có thể gặp vấn đề tương tự trong cơ sở dữ liệu người dùng, nhưng vì bạn đã cố gắng giải quyết vấn đề trong tempdb ...

  3. Những điều cụ thể trong DB sẽ trở nên tồi tệ hơn nhiều?

    Viết lần, chủ yếu. Hãy tưởng tượng mọi người đang cố gắng sử dụng cùng một máy ATM, ngay cả khi có 7 máy ATM khác ở gần đó. Chỉ có rất nhiều có thể được viết tại bất kỳ thời điểm nào; mọi thứ khác phải chờ. Với nhiều tệp hơn (và đủ lõi để sắp xếp công việc), I / O có thể được trải đều hơn.

    Chỉ cần chắc chắn:


10
  1. Đố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.

  1. Đ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.

  1. 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 waitresourcetrê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.

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.