Sự tranh chấp TempDB

Chúng tôi có cơ sở dữ liệu OLTP 40GB hoạt động trên SQL Server 2014 SP1. Các truy vấn được phát hiện là chậm với chờ đợi IO_Completion, Độ dài hàng đợi đĩa tăng lên 900 và SQL Server ngừng đáp ứng. Những gì chúng tôi đã cố gắng:

1. Khởi động lại ví dụ và trong một phút, nó bắt đầu hành xử theo cùng một cách.

2. Sau khi khởi động lại lần thứ hai, chúng tôi đã thay đổi kích thước ban đầu của mỗi tệp dữ liệu tempdb (có 16 tệp dữ liệu được tạo) và nó bắt đầu hoạt động chính xác.

Lưu ý: Chúng tôi đang sử dụng các biến bảng cho các tập kết quả trung gian. Những bộ kết quả này rất nhỏ.

Nó đã xảy ra hai lần trong một tháng. Mỗi lần tôi thêm một chút dung lượng thủ công vào các tệp dữ liệu, thì nó sẽ bắt đầu hoạt động bình thường. Điều thú vị hơn là cùng một thiết lập (cùng phần cứng, cùng thiết lập thư mục và tệp, cùng khối lượng công việc) chúng tôi có trên SQL Server 2008 R2 và SQL Server 2012 đang hoạt động tốt.

Vui lòng giúp chúng tôi tìm một giải pháp lâu dài.

Kích thước ban đầu của tất cả các tệp dữ liệu là 1000MB, mỗi tệp là 1500 MB. Tất cả đều giống hệt nhau. Autogrowth là 100MB cho mỗi. Trước đó, chúng tôi đã phải đối mặt với sự tranh chấp giữa các trang PFS và GAM và chúng tôi đã tăng lên 16 và vấn đề được giải quyết. Cả hai cờ theo dõi 1117 & 1118 đều được bật. 24 lõi trên 2 nút NUMA. Tất cả các tệp dữ liệu trên cùng một khối lượng. Đĩa đơn giản, không có SAN.

Sơ thẩm là trên một máy vật lý. Các truy vấn với Biến bảng và truy vấn với Hash Joins thường tạo ra chờ đợi IO_Completion nhất.

Câu trả lời chi tiết của wBob đã thúc đẩy chúng tôi tìm kiếm chi tiết hơn. Làm thế nào chúng ta đã bỏ lỡ nó trước đây:

Tự động lưu tệp 'templog' trong cơ sở dữ liệu 'tempdb' đã bị hủy bởi người dùng hoặc hết thời gian sau 7704 mili giây. Sử dụng ALTER DATABASE để đặt giá trị TÀI LIỆU nhỏ hơn cho tệp này hoặc đặt rõ ràng kích thước tệp mới.

Điều này chúng tôi tìm thấy trong nhật ký khi bao giờ loại vấn đề này xảy ra. Chúng tôi đang di chuyển TempDB để tách ổ đĩa nhanh.

Tôi nghĩ rằng bạn đã làm quá mức tempdb của mình và có sự không phù hợp giữa CPU máy chủ và thiết lập đĩa, nhưng hãy thu thập thêm một số thông tin:

Câu hỏi / Yêu cầu thêm thông tin

• Vui lòng xác nhận tên và loại bộ xử lý (về cơ bản tôi đang cố gắng thiết lập nếu đó là 2 x hex-core với HT). Sử dụng thông tin hệ thống (ví dụ Bảng điều khiển> Hệ thống và bảo mật> Hệ thống trên Windows Server 2012 R2) và / hoặc công cụ sysiternals CoreInfo để xác nhận.
• Vui lòng xác nhận maxdop máy chủ (ví dụ EXEC sp_configure 'max degree of parallelism'). Nếu các CPU là hex-core, maxdop của máy chủ nên có nhiều nhất là 6 (theo như ở đây ), hoặc thấp hơn nhiều so với hệ thống OLTP. Tôi thường giữ các tệp tempdb của mình phù hợp với DOP máy chủ của tôi tối đa là 8 nhưng chúng tôi sẽ đến đó.
• Vui lòng xác nhận tổng bộ nhớ máy chủ trên hộp và nắp bộ nhớ Máy chủ SQL (ví dụ EXEC sp_configure 'max server memory (MB)').
• Vui lòng xác nhận nếu có bất kỳ dịch vụ nào khác đang chạy trên hộp (ví dụ: SSIS, SSAS, SSRS, ứng dụng, iTunes, v.v.)
• Vui lòng xác nhận Khởi tạo tệp tức thì được bật cho tài khoản dịch vụ SQL Server. (Cách để kiểm tra nó ở đây ).
• Tại sao có sự khác biệt lớn như vậy giữa CPU (thiết lập NUMA 2 nút) cho một đĩa (PC gia đình)? Xem xét thêm đĩa, phân loại, SSD cho tempdb (mặc dù tránh phản ứng quá mức :).
• Vui lòng thêm một kế hoạch thực hiện thực tế cho một trong các truy vấn vấn đề. Ẩn danh với SQL Sentry Plan Explorer nếu bạn muốn.

• Hash tham gia với các biến bảng trong một hệ thống OLTP? Điều này cho thấy thiếu lập chỉ mục trên biến bảng, bảng chính hoặc cả hai. Bạn đang khai báo các biến bảng của bạn như thế này (không có chỉ mục)?

  DECLARE @t TABLE ( x INT )

• Đừng bỏ qua định nghĩa biến bảng mặc dù nó đang giữ các kết quả nhỏ. Tốt nhất là luôn cung cấp cho trình tối ưu hóa càng nhiều thông tin càng tốt, vì vậy hãy rõ ràng với tính không hợp lệ, tính duy nhất, cho dù chỉ mục có được phân cụm / không phân cụm hay không, vd

  DECLARE @t TABLE ( x INT PRIMARY KEY )
  DECLARE @u TABLE ( x INT PRIMARY KEY NONCLUSTERED, u INT NOT NULL UNIQUE CLUSTERED, z INT NOT NULL UNIQUE, a CHAR(1) NULL ) -- not sure why you would do this but you can
  DECLARE @v TABLE ( x INT NOT NULL, y INT NOT NULL, PRIMARY KEY ( x, y ) )   -- multi-column primary key

• Đăng kế hoạch thực hiện sẽ giúp chẩn đoán điều này.

• Kiểm tra mã ngăn chặn bộ đệm ẩn biến theo bảng ở đây , ở đây . Tôi nghĩ rằng SQL động và Proc được thực thi VỚI RECOMPILE là những cái duy nhất ảnh hưởng đến các biến của bảng.

  DECLARE @u TABLE ( x INT )
  
  INSERT @u
  EXEC('DECLARE @t TABLE ( x INT ); INSERT INTO @t VALUES ( 1 ); SELECT x FROM @t;' )
  
  SELECT *
  FROM @u

• Kiểm tra Nhật ký máy chủ SQL (Object Explorer> Quản lý> Nhật ký máy chủ SQL) để biết các thông báo, ví dụ như cảnh báo IO.

• Kiểm tra Trình xem sự kiện Windows
• Đã có một số bản dựng được phát hành kể từ SP1. Xem lại các bản sửa lỗi CU được đưa vào kể từ SP1 . Có thể có lỗi trong SP1 được sửa trong các CU tiếp theo, ví dụ FIX: Sắp xếp toán tử tràn sang tempdb trong SQL Server 2012 hoặc SQL Server 2014 khi số lượng hàng và kích thước hàng ước tính là chính xác https://support.microsoft.com/en- chúng tôi / kb / 3088480
• Thiết lập đây là nguyên nhân của bạn trước khi áp dụng bất kỳ hotfix nào, mặc dù điều quan trọng hơn là phải cập nhật các CU với SQL Server 2014, do số lượng các tính năng mới (OLTP trong bộ nhớ, kho lưu trữ cột).
• Cuối cùng, nhu cầu về một tệp tempdb cho mỗi lõi là một huyền thoại và nhìn vào thiết lập đĩa của bạn, tôi đoán là tempdb bị phân mảnh quá mức. Tôi có một cảm giác khó chịu khi bạn có một đầu đĩa, tempdb có một filegroup, nhiều tệp.

Tuy nhiên hãy quên những gì chúng ta nghĩ rằng chúng ta biết; tạo một thử nghiệm tái tạo vấn đề của bạn và thử nghiệm giảm số lượng tệp tạm thời ... bắt đầu từ 1, 2, 4, 6, vv thu thập thông tin, để đưa ra quyết định dựa trên bằng chứng. Bây giờ đây là một chút khó khăn hơn vì vấn đề của bạn có vẻ không liên tục và bạn có thể không thể gây rối với thiết lập tempdb của mình, nhưng đó là cách tôi sẽ tiếp cận vấn đề này.

Chúc may mắn. Hãy cho chúng tôi biết bạn lấy như thế nào.