Sự tranh chấp DDL trên TempDB

Tôi có SQL Server 2005 Standard x64 đang gặp sự cố với sự tranh chấp DDL của TempDB trong vài tháng qua. Máy chủ sẽ gặp phải sự tranh chấp về tài nguyên chờ 2: 1: 103 (loại chờ là PAGELATCH_EX).

Vấn đề dường như xảy ra không thường xuyên khi máy chủ đang tải tốt. Tôi đã theo dõi tỷ lệ "Các bảng tạm thời để phá hủy" và nó có thể tăng lên hơn 5.000 trong thời gian chúng tôi gặp vấn đề về PAGELATCH_EX trên 2: 1: 103. Từ những gì tôi đã đọc bộ đếm này sẽ là 0 phần lớn thời gian, nhưng chúng ta dường như ở bất cứ nơi nào từ 300-1100 phần lớn thời gian. Bộ đếm chỉ về 0 khi có rất ít người dùng trên hệ thống.

Làm cách nào tôi có thể thu hẹp những gì gây ra tranh chấp DDL trên tempdb mà không phải tìm kim trong ngăn xếp cỏ khô?

Tôi đã thấy vấn đề này rất lớn và hotfix cuối cùng đã được phát hành để sửa nó thực sự là kết quả trực tiếp của trường hợp của tôi với Microsoft CSS. Không có bài viết KB công khai để sửa chữa. Vui lòng đảm bảo rằng bạn đã áp dụng Gói dịch vụ 4 và bản cập nhật tích lũy gần đây nhất cho SQL Server (tại thời điểm viết bài, đó là Cập nhật tích lũy số 3 (9.00.5259) ).

Cho đến khi hotfix được phát hành, đề xuất của Microsoft chỉ đơn giản là ngừng tạo các bảng #temp (giống như KB # 916086 ). Vì điều này có nghĩa là phải viết lại đáng kể hàng chục và hàng chục thủ tục báo cáo, cách giải quyết trong trường hợp của tôi (bất kể cờ theo dõi hoặc bố cục tệp tạm thời) là để khởi động lại cụm của chúng tôi vào mỗi cuối tuần khác. Kinh quá.

Để theo dõi việc sử dụng tempdb, có một số tập lệnh xung quanh có thể giúp ích, ví dụ như xem sp_whoIsActive của Adam Machanic , cụ thể:

• sp_whoisactive: Phân tích sự tham gia của Tempdb
• Làm cách nào để xác định truy vấn nào đang điền vào nhật ký giao dịch tempdb?

Và tập lệnh này (và các tập lệnh trong các bình luận) từ @QuerySoldier:

• Phá vỡ sự tham gia của TempDB

Tôi sẽ đảm bảo tất cả các con trỏ của bạn đang sử dụng LOCAL STATIC READ_ONLY FORWARD_ONLY(xem cái này và cái này ), và xem liệu có bất kỳ truy vấn đắt tiền nào đã sử dụng rộng rãi các bảng #temp / @table, CTE hoặc có thể chứa các loại không cần thiết hoặc dẫn đến tham gia băm không ... tất cả những điều này có thể góp phần gây ra vấn đề (tôi nghi ngờ bạn sẽ tìm thấy một nguyên nhân vàng). Cách khắc phục dễ dàng nhất như điểm bắt đầu "bang-for-your-buck" sẽ là sử dụng các tùy chọn con trỏ phù hợp và rẻ tiền thay vì mặc định.

Trong khi đó, tôi sẽ (a) cài đặt CU # 3 và (b) gọi PSS. Nói với họ rằng bạn đang sửa một lỗi rất cụ thể đã được xác nhận là lỗi và được phát hành cho người dùng khác dưới dạng hotfix riêng tư: "VSTS # 109112 - Bảng tạm hoãn giảm không quy mô cho khối lượng công việc nhất định." Bạn có thể phải trả lệ phí trường hợp ban đầu, nhưng vì đó là một lỗi, nên hoàn trả phí.

Bạn có thể cần cờ theo dõi 1118

Trước tiên hãy xem những huyền thoại của Paul Randal về tempdb và bài viết về TF 1118 của anh ấy

TF được mô tả ở đây trong KB 328551

Tôi không có kinh nghiệm trực tiếp về điều này nhưng có vẻ như những gì tôi đã đọc

Tôi đoán rằng bạn đã tách ra các tệp dữ liệu TempDB của mình để cố gắng giảm bớt sự tranh chấp (rõ ràng trước khi sản xuất trước). Nếu bạn dũng cảm hơn, hãy xem xét cờ theo dõi mà Paul Randal có thẩm quyền đề cập đến: http://www.sqlskills.com/BLOGS/PAUL/post/A-Query-Server-DBA-myth-a-day-(1230) -tempdb-nên-luôn-có-một-dữ liệu-tệp-mỗi-bộ xử lý-core.aspx

Về những gì gây ra nỗi đau, bạn cần thực hiện một số công việc điều tra:

• điều này mới chỉ bắt đầu xảy ra? những gì đã thay đổi?
• là máy chủ chịu áp lực bộ nhớ, vì vậy các loại phải được thực hiện trong TempDB?
• Có bất kỳ quy trình DBA nào như CheckDB, hoặc lập chỉ mục lại trực tuyến, đang chạy không?
• mức độ cô lập kỳ lạ hơn được sử dụng, hoặc môi giới dịch vụ? hãy xem sys.database

Có một truy vấn đẹp ở dưới cùng của tài liệu Microsoft TempDB này để cố gắng tìm ra những gì đang sử dụng tempdb: http://technet.microsoft.com/en-gb/l Library / cc966545.aspx

Nếu bạn vẫn đang tìm cách theo dõi điều này, gần đây tôi đã có một vấn đề hiệu suất kỳ lạ tương tự với việc giảm bảng đồng bộ. Nếu bạn có số lượng lớn cơ sở dữ liệu (> 100 hoặc hơn) trên một cá thể sql chạy SQL 2005 và bạn có rất nhiều câu lệnh tạo và thả bảng tạm thời, bạn có thể nhận được các giọt bảng tạm thời chậm. Kiểm tra số hàng được trả về từ sys.dm_db_index_usage_stats có thể loại trừ điều này ngay lập tức là thủ phạm.

Bài viết KB mô tả vấn đề. http://support.microsoft.com/kb/2003031

Hiệu suất truy vấn giảm khi sys.dm_db_index_usage_stats có số lượng hàng lớn

Hãy xem xét kịch bản sau đây:

Trong Microsoft SQL Server 2005, bạn thường xuyên thực hiện thao tác DDL liên quan đến việc thả và giải trí rất nhiều bảng (đặc biệt là các bảng tạm thời trong cơ sở dữ liệu tempdb). Bạn có một số lượng lớn các mục (100.000 trở lên) trong chế độ xem quản lý động sys.dm_db_index_usage_stats (DMV).

Lấy từ câu trả lời được chấp nhận của tôi cho câu hỏi này. Có một số chi tiết ở đó là tốt. Bảng temp chậm giảm trong sql 2005