SQL Server 2016 Enterprise hoạt động kém

Xin lỗi vì đã lâu, nhưng tôi muốn cung cấp cho bạn càng nhiều thông tin càng tốt để có thể hữu ích cho việc phân tích.

Tôi biết có một số bài viết có vấn đề tương tự, tuy nhiên, tôi đã theo dõi các bài đăng khác nhau này và các thông tin khác có sẵn trên web, nhưng vấn đề vẫn còn.

Tôi gặp vấn đề nghiêm trọng về hiệu năng trong SQL Server đang khiến người dùng phát điên. Vấn đề này kéo dài trong vài năm và cho đến cuối năm 2016 được quản lý bởi một thực thể khác và từ năm 2017 đã được quản lý bởi tôi.

Vào giữa năm 2017, tôi đã có thể giải quyết vấn đề bằng cách làm theo các gợi ý lập chỉ mục được chỉ định bởi Báo cáo Bảng điều khiển Hiệu suất của Microsoft SQL Server 2012. Hiệu quả là ngay lập tức, nó nghe như ma thuật. Bộ xử lý trong những ngày qua hầu như luôn luôn ở mức 100%, trở nên siêu thanh thản và phản hồi của người dùng rất vang dội. Ngay cả kỹ thuật viên ERP của chúng tôi cũng rất vui mừng, vì thường mất 20 phút để có được danh sách nhất định và cuối cùng anh ấy có thể làm điều đó trong vài giây.

Tuy nhiên, theo thời gian, nó dần bắt đầu xấu đi. Tôi tránh tạo ra nhiều chỉ mục hơn, vì sợ rằng quá nhiều chỉ mục sẽ làm giảm hiệu suất. Nhưng đến một lúc nào đó, tôi phải xóa những cái không sử dụng và tạo ra những cái mới mà Bảng điều khiển hiệu suất gợi ý cho tôi. Nhưng không có tác động.

Sự chậm chạp cảm thấy về cơ bản là khi tiết kiệm và tư vấn, trong ERP.

Tôi có Windows Server 2012 R2 dành riêng cho SQL Server 2016 Enterprise (64-bit) với cấu hình sau:

• CPU: CPU Intel Xeon E5-2650 v3 @ 2.30GHz
• Bộ nhớ: 84 GB
• Về lưu trữ, máy chủ có một khối lượng dành riêng cho hệ điều hành, một khối khác dành riêng cho dữ liệu và một khối khác dành riêng cho nhật ký.
• 17 cơ sở dữ liệu
• Người dùng:
  • Trong DB lớn nhất được kết nối đồng thời ít nhất 113 người dùng
  • Trong một người khác có khoảng 9 người dùng
  • Trong hai trong số đó là 3 + 3
  • Phần còn lại chỉ có 1 người dùng
  • Chúng tôi có một trang web cũng viết cho cơ sở dữ liệu lớn hơn, nhưng việc sử dụng ít thường xuyên hơn và nên có khoảng 20 người dùng.
• Kích thước của DB:
  • Cơ sở dữ liệu lớn nhất có 290 GB
  • Lớn thứ hai có 100GB
  • Lớn thứ ba có 20 GB
  • 14 GB thứ tư
  • Phần còn lại chỉ hơn 3 GB mỗi

Đây là ví dụ sản xuất, nhưng chúng tôi cũng có một trường hợp phát triển mà tôi tin rằng có thể coi nhẹ mục đích này, bởi vì hầu hết thời gian tôi là người duy nhất kết nối ở đó, nhưng vấn đề này xảy ra liên tục, ngay cả khi tôi không kết nối .

Bộ xử lý hầu như luôn luôn như thế này:

Chúng tôi có thói quen chạy vào ban đêm (không có vấn đề) và một số hoạt động vào ban ngày.

Người dùng kết nối thông qua Remote Desktop với các máy khác được ODBC 32 định cấu hình để truy cập SQL Server.

Trung tâm dữ liệu nơi đặt máy chủ có 100/100 Mbps, cũng như nơi tôi đang ở. Hầu hết các trang web được liên kết bởi MPLS và các trang khác bằng IPSec (từ FO đến 4G). Các nhà cung cấp thực hiện nhiều phân tích và các mạch là ok.

Tỷ lệ truy cập bộ nhớ cache là 99% (cả Yêu cầu người dùng và Phiên người dùng)

Sự chờ đợi trông như thế này:

Tôi đã thu thập dữ liệu với Perfmon và tôi có kết quả nếu nó giúp phân tích của bạn - cá nhân tôi không nhận được bất kỳ kết luận nào từ phân tích.

Tôi tin tưởng vào sự hỗ trợ của bạn trong việc giải quyết vấn đề này, sẵn sàng cung cấp thông tin mà bạn cho là cần thiết cho việc giải quyết.

Cảm ơn rât nhiều.

Đây là sp_blitz markdown (Tôi đã thay thế tên công ty bằng bút danh):

Ưu tiên 1: Độ tin cậy :

• DBCC CHECKDB cuối cùng tốt hơn 2 tuần tuổi

  • bậc thầy

  • mô hình - CHECKDB thành công lần cuối: 2018/02/07 15: 04: 26.560

  • msdb - CHECKDB thành công lần cuối: 2018/02/07 15: 04: 27.740

Ưu tiên 10: Hiệu suất :

• CPU w / Số lẻ của lõi

  • Nút 0 có 5 lõi được gán cho nó. Đây là một cấu hình NUMA thực sự xấu.

  • Nút 1 có 5 lõi được gán cho nó. Đây là một cấu hình NUMA thực sự xấu.

Ưu tiên 20: Cấu hình tệp :

• TempDB trên C Drive tempdb - Cơ sở dữ liệu tempdb có các tệp trên ổ C. TempDB thường xuyên phát triển một cách khó lường, khiến máy chủ của bạn có nguy cơ hết dung lượng ổ C và gặp sự cố nghiêm trọng. C cũng thường chậm hơn nhiều so với các ổ đĩa khác, vì vậy hiệu năng có thể bị ảnh hưởng.

Ưu tiên 50: Độ tin cậy :

• Lỗi được ghi gần đây trong Dấu vết mặc định
  • master - 2018-03-07 08: 43: 11.72 Lỗi đăng nhập: 17892, Mức độ nghiêm trọng: 20, Trạng thái: 1. 2018-03-07 08: 43: 11.72 Đăng nhập Đăng nhập thất bại khi đăng nhập 'example_user' do thực thi kích hoạt. [KHÁCH HÀNG: IPADDR]

(lưu ý: nhiều lỗi như thế này do trình kích hoạt được kích hoạt giới hạn các phiên của người dùng - đối với kiểm soát sử dụng cấp phép ERP)

• Xác minh trang không tối ưu

  • DATABASE_A - Cơ sở dữ liệu [DATABASE_A] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_B - Cơ sở dữ liệu [DATABASE_B] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_C - Cơ sở dữ liệu [DATABASE_C] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_D - Cơ sở dữ liệu [DATABASE_D] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_E - Cơ sở dữ liệu [DATABASE_E] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_F - Cơ sở dữ liệu [DATABASE_F] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_G - Cơ sở dữ liệu [DATABASE_G] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_H - Cơ sở dữ liệu [DATABASE_H] KHÔNG CÓ để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_I - Cơ sở dữ liệu [DATABASE_I] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_Z - Cơ sở dữ liệu [DATABASE_Z] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_K - Cơ sở dữ liệu [DATABASE_K] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_J - Cơ sở dữ liệu [DATABASE_J] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_L - Cơ sở dữ liệu [DATABASE_L] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_M - Cơ sở dữ liệu [DATABASE_M] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_O - Cơ sở dữ liệu [DATABASE_O] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_P - Cơ sở dữ liệu [DATABASE_P] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_Q - Cơ sở dữ liệu [DATABASE_Q] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_R - Cơ sở dữ liệu [DATABASE_R] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_S - Cơ sở dữ liệu [DATABASE_S] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_T - Cơ sở dữ liệu [DATABASE_T] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_U - Cơ sở dữ liệu [DATABASE_U] KHÔNG CÓ để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_V - Cơ sở dữ liệu [DATABASE_V] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

  • DATABASE_X - Cơ sở dữ liệu [DATABASE_X] có KHÔNG để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

• Remote DAC bị vô hiệu hóa - Truy cập từ xa vào Kết nối quản trị viên chuyên dụng (DAC) không được bật. Bộ xử lý có thể giúp xử lý sự cố từ xa dễ dàng hơn nhiều khi SQL Server không phản hồi.

Ưu tiên 50: Thông tin máy chủ :

• Khởi tạo tệp tức thì không được bật - Cân nhắc bật IFI để khôi phục nhanh hơn và tăng trưởng tệp dữ liệu.

Ưu tiên 100: Hiệu suất :

• Yếu tố điền thay đổi

  • DATABASE_A - Cơ sở dữ liệu [DATABASE_A] có 417 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_B - Cơ sở dữ liệu [DATABASE_B] có 318 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_C - Cơ sở dữ liệu [DATABASE_C] có 346 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_D - Cơ sở dữ liệu [DATABASE_D] có 663 đối tượng với hệ số điền = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_E - Cơ sở dữ liệu [DATABASE_E] có 335 đối tượng với hệ số điền = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_F - Cơ sở dữ liệu [DATABASE_F] có 1705 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_G - Cơ sở dữ liệu [DATABASE_G] có 671 đối tượng với hệ số điền = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_H - Cơ sở dữ liệu [DATABASE_H] có 2364 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_I - Cơ sở dữ liệu [DATABASE_I] có 1658 đối tượng với hệ số điền = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_Z - Cơ sở dữ liệu [DATABASE_Z] có 673 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_K - Cơ sở dữ liệu [DATABASE_K] có 312 đối tượng với hệ số điền = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_J - Cơ sở dữ liệu [DATABASE_J] có 864 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_L - Cơ sở dữ liệu [DATABASE_L] có 1170 đối tượng với hệ số điền = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_M - Cơ sở dữ liệu [DATABASE_M] có 382 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_O - Cơ sở dữ liệu [DATABASE_O] có 356 đối tượng với hệ số điền = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • msdb - Cơ sở dữ liệu [msdb] có 8 đối tượng với hệ số điền = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_P - Cơ sở dữ liệu [DATABASE_P] có 291 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_Q - Cơ sở dữ liệu [DATABASE_Q] có 343 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_R - Cơ sở dữ liệu [DATABASE_R] có 2048 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_S - Cơ sở dữ liệu [DATABASE_S] có 325 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_T - Cơ sở dữ liệu [DATABASE_T] có 322 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_U - Cơ sở dữ liệu [DATABASE_U] có 351 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_V - Cơ sở dữ liệu [DATABASE_V] có 312 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • DATABASE_X - Cơ sở dữ liệu [DATABASE_X] có 352 đối tượng với hệ số lấp đầy = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

  • tempdb - Cơ sở dữ liệu [tempdb] có 2 đối tượng với hệ số điền = 70%. Điều này có thể gây ra vấn đề về hiệu năng bộ nhớ và lưu trữ, nhưng cũng có thể ngăn chặn việc chia trang.

• Nhiều kế hoạch cho một truy vấn - 20763 kế hoạch có mặt cho một truy vấn duy nhất trong bộ đệm của kế hoạch - có nghĩa là chúng tôi có thể có vấn đề về tham số hóa.

• Kích hoạt máy chủ được kích hoạt - Kích hoạt máy chủ [Connection_limit_trigger] được bật. Hãy chắc chắn rằng bạn hiểu những gì kích hoạt đang làm - công việc càng ít thì càng tốt.

• Thủ tục lưu trữ với RECOMPILE

  • master - [master]. [dbo]. [sp_AllNightLog] có VỚI RECOMPILE trong mã thủ tục được lưu trữ, điều này có thể làm tăng mức sử dụng CPU do biên dịch lại mã liên tục.

  • master - [master]. [dbo]. [sp_AllNightLog_Setup] có RECOMPILE trong mã thủ tục được lưu trữ, điều này có thể làm tăng mức sử dụng CPU do biên dịch lại mã liên tục.

Ưu tiên 110: Hiệu suất :

• Bảng hoạt động không có chỉ mục cụm

  • DATABASE_A - Cơ sở dữ liệu [DATABASE_A] có rất nhiều - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_B - Cơ sở dữ liệu [DATABASE_B] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_C - Cơ sở dữ liệu [DATABASE_C] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_E - Cơ sở dữ liệu [DATABASE_E] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_F - Cơ sở dữ liệu [DATABASE_F] có rất nhiều - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_H - Cơ sở dữ liệu [DATABASE_H] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_I - Cơ sở dữ liệu [DATABASE_I] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_K - Cơ sở dữ liệu [DATABASE_K] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_O - Cơ sở dữ liệu [DATABASE_O] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_Q - Cơ sở dữ liệu [DATABASE_Q] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_S - Cơ sở dữ liệu [DATABASE_S] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_T - Cơ sở dữ liệu [DATABASE_T] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_U - Cơ sở dữ liệu [DATABASE_U] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_V - Cơ sở dữ liệu [DATABASE_V] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DATABASE_X - Cơ sở dữ liệu [DATABASE_X] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

Ưu tiên 150: Hiệu suất :

(Lưu ý: Nany khuyên ở đây, nhưng tôi không thể đưa chúng vào vì giới hạn của các ký tự. Nếu có cách khác để chia sẻ, vui lòng cho biết.)

Bạn đã cho chúng tôi một câu hỏi dài (và rất chi tiết). Bây giờ bạn phải đối phó với một câu trả lời dài. ;)

Có một số điều tôi sẽ đề nghị thay đổi trên máy chủ của bạn. Nhưng hãy bắt đầu với vấn đề cấp bách nhất.

Các biện pháp khẩn cấp một lần:

Thực tế là hiệu suất đã được thỏa mãn sau khi triển khai các chỉ mục trên hệ thống của bạn và độ hoàn hảo giảm dần là một gợi ý rất mạnh mẽ rằng bạn cần bắt đầu duy trì số liệu thống kê của mình và (ở mức độ thấp hơn) quan tâm đến việc xáo trộn chỉ số.

Là một biện pháp khẩn cấp, tôi sẽ đề nghị cập nhật số liệu thống kê thủ công một lần trên tất cả các cơ sở dữ liệu của bạn. Bạn có thể nhận được TSQL không cần thiết bằng cách thực thi tập lệnh này:

DECLARE @SQL VARCHAR(1000)  
DECLARE @DB sysname  

DECLARE curDB CURSOR FORWARD_ONLY STATIC FOR  
   SELECT [name]  
   FROM master..sysdatabases 
   WHERE [name] NOT IN ('model', 'tempdb') 
   ORDER BY [name] 

OPEN curDB  
FETCH NEXT FROM curDB INTO @DB  
WHILE @@FETCH_STATUS = 0  
   BEGIN  
       SELECT @SQL = 'USE [' + @DB +']' + CHAR(13) + 'EXEC sp_updatestats' + CHAR(13)  
       PRINT @SQL  
       FETCH NEXT FROM curDB INTO @DB  
   END  

CLOSE curDB  
DEALLOCATE curDB

Nó được cung cấp bởi Tim Ford trong blogpost của mình trên mssqltips.com và ông cũng đang giải thích lý do tại sao việc cập nhật số liệu thống kê.

Xin lưu ý rằng đây là nhiệm vụ chuyên sâu của CPU và IO không nên được thực hiện trong giờ kinh doanh.

Nếu điều này giải quyết vấn đề của bạn, xin đừng dừng lại ở đó!

Bảo trì thường xuyên:

Hãy xem Giải pháp bảo trì Ola Hallengren và sau đó thiết lập ít nhất hai công việc này:

• Một công việc cập nhật số liệu thống kê (nếu có thể mỗi đêm). Bạn có thể sử dụng mã CMD này trong công việc đại lý của bạn. Công việc này phải được tạo ra từ đầu.

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d MSSYS -Q "EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @MaxDOP = 0, @LogToTable = 'Y'" -b

• Một chỉ số duy trì công việc. Tôi sẽ đề nghị bắt đầu với một thực hiện theo lịch trình mỗi tháng một lần. Bạn có thể bắt đầu với các mặc định mà Ola cung cấp cho Công việc IndexOptizing.

Có một số lý do tôi đề xuất công việc đầu tiên để cập nhật số liệu thống kê riêng:

• Việc xây dựng lại chỉ mục sẽ chỉ cập nhật số liệu thống kê của các cột được bao phủ bởi chỉ mục đó trong khi việc sắp xếp lại chỉ mục hoàn toàn không cập nhật số liệu thống kê. Ola phân chia phân mảnh trong ba loại. Theo mặc định, chỉ các danh mục cao sẽ được xây dựng lại.
• Thống kê cho các cột không được bao phủ bởi một chỉ mục sẽ chỉ được cập nhật bởi công việc IndexOptizing.
• Để giảm thiểu vấn đề chính tăng dần .

SQL Server sẽ tự động cập nhật số liệu thống kê nếu mặc định được bật. Vấn đề với đó là các ngưỡng (ít xảy ra sự cố với SQL Server 2016 của bạn). Thống kê được cập nhật khi một số lượng hàng nhất định thay đổi (20% trong các Phiên bản SQL Server cũ hơn). Nếu bạn có các bảng lớn, điều này có thể có rất nhiều thay đổi trước khi số liệu thống kê được cập nhật. Xem thêm thông tin về ngưỡng ở đây .

Vì bạn đang thực hiện CHECKDB theo như tôi có thể nói rằng bạn có thể tiếp tục thực hiện chúng như trước đây hoặc bạn cũng sử dụng giải pháp bảo trì cho việc đó.

Để biết thêm thông tin về phân mảnh chỉ số và bảo trì, hãy xem:

Tổng quan về phân mảnh chỉ mục máy chủ SQL

Ngừng lo lắng về phân mảnh máy chủ SQL

Xem xét hệ thống con lưu trữ của bạn, tôi khuyên bạn không nên sửa nhiều về "phân mảnh bên ngoài" vì dữ liệu không được lưu theo thứ tự trên SAN của bạn.

Tối ưu hóa cài đặt của bạn

Kịch bản sp_Blitz cung cấp cho bạn một danh sách tuyệt vời để bắt đầu.

Ưu tiên 20: Cấu hình tệp - TempDB trên C Drive: Nói chuyện với quản trị viên lưu trữ của bạn. Hỏi họ xem ổ C của bạn có phải là đĩa nhanh nhất có sẵn cho SQL Server của bạn không. Nếu không, hãy đặt tempdb của bạn ở đó ... giai đoạn. Sau đó kiểm tra xem bạn có bao nhiêu tệp temdb. Nếu câu trả lời là một sửa chữa đó . Nếu chúng không cùng kích thước sửa hai cái đó.

Ưu tiên 50: Thông tin máy chủ - Không khởi tạo tệp tức thì: Không theo liên kết, tập lệnh sp_Blitz cung cấp cho bạn và bật IFI.

Ưu tiên 50: Độ tin cậy - Xác minh trang không tối ưu: Bạn nên đặt điều này trở lại mặc định (CHECKSUM). Theo liên kết, tập lệnh sp_Blitz cung cấp cho bạn và làm theo hướng dẫn.

Ưu tiên 100: Hiệu suất - Yếu tố điền thay đổi: Hãy tự hỏi tại sao có quá nhiều đối tượng có hệ số lấp đầy được đặt thành 70. Nếu bạn không có câu trả lời và không có nhà cung cấp ứng dụng nào yêu cầu nghiêm ngặt. Đặt nó trở lại 100%.

Điều này về cơ bản có nghĩa là SQL Server sẽ để lại 30% dung lượng trống trên các trang này. Vì vậy, để có được cùng một lượng dữ liệu (so với 100% trang đầy đủ), máy chủ của bạn phải đọc thêm 30% trang và chúng sẽ chiếm thêm 30% dung lượng trong bộ nhớ. Lý do nó thường được thực hiện là để ngăn chặn sự phân mảnh chỉ số.

Nhưng một lần nữa, bộ nhớ của bạn đang lưu các trang đó trong các phần khác nhau. Vì vậy, tôi sẽ đặt nó trở lại 100% và lấy nó từ đó.

Phải làm gì nếu mọi người đều vui vẻ:

• Xem phần còn lại của đầu ra của sp_Blitz và quyết định xem bạn có thay đổi chúng theo đề xuất không.
• Thực thi sp_Blitz Index và xem xét các chỉ mục bạn đã tạo, nếu chúng được sử dụng hoặc nơi có thể có cơ hội để thêm / thay đổi.
• Hãy xem dữ liệu Cửa hàng Truy vấn của bạn (theo đề xuất của Peter). Bạn có thể tìm thấy một giới thiệu ở đây .
• Thưởng thức ngôi sao nhạc rock sống một DBA xứng đáng. ;)

Không bỏ qua tất cả các câu trả lời của bạn rất hữu ích và tôi đã áp dụng hoặc sẽ áp dụng, vấn đề lớn nhất không dễ tìm thấy.

Vấn đề trở nên tồi tệ hơn trong những ngày sau tin nhắn cuối cùng của chúng tôi.

Vì chúng tôi dựa trên đám mây, cả tôi và công ty quản lý cơ sở hạ tầng và hỗ trợ chúng tôi đều có quyền truy cập vào các máy chủ vật lý.

Một cái gì đó làm tôi tự hỏi khi tôi nhận thấy rằng một số ngày bộ xử lý trung bình ở mức 20% và những ngày khác nó cao hơn nhiều, hơn 60%, khi khối lượng công việc, mặc dù không bao giờ giống hệt nhau, là tương tự. Có cùng số lượng người thực hiện ít nhiều cùng loại hoạt động.

Đầu tuần này, người dùng bắt đầu bị kẹt trong vài phút và chỉ có bộ xử lý bị bóp nghẹt. Tôi đã yêu cầu một số người dùng đăng xuất (những người đang tiêu tốn nhiều tài nguyên hơn nhưng vẫn không có gì khác thường), tôi đã tắt các dịch vụ khác nhau được liên kết với cơ sở dữ liệu và cuối cùng không có gì thay đổi. Tôi đã hỏi sysadmin hỗ trợ chúng tôi và có thể liên lạc với những người trong đám mây của chúng tôi để điều khiển máy của tôi để xem những gì tôi đang thấy và giúp tôi tìm thứ gì đó, vì tôi không thể làm tốt hơn để tìm ra vấn đề.

Kỹ thuật viên cũng không tìm thấy gì. Cuối cùng anh ấy bắt đầu cho tôi một số lý do rằng một cái gì đó khác phải gây ra vấn đề này và là khi anh ấy liên lạc với đám mây. Trong đám mây, họ không nhận ra bất cứ điều gì, chỉ vì có cấu hình cân bằng tải giữa các máy chủ vật lý, VM hỗ trợ SQL Server của chúng tôi đã được di chuyển một vài lần trong ngày giữa các máy chủ vật lý. May mắn thay, tôi đã nói với kỹ thuật viên của chúng tôi chính xác vào thời điểm các sự cố bắt đầu xảy ra vào ngày hôm đó, trùng với thời điểm VM được chuyển lần cuối cùng đến một trong những máy chủ vật lý mà nó không rời khỏi phần còn lại của ngày.

Nếu kỹ thuật viên không theo dõi sát sao vấn đề này, thì đây sẽ là một trong những lần anh ta thậm chí có thể nói chuyện với những người trên đám mây, nhưng khi họ nhìn thấy các mẫu hiệu suất, họ sẽ không nhận được gì, vì một lần nữa đám mây chỉ nhìn thấy các mẫu có CPU theo thứ tự 40/50%, trong khi thực tế nó trung bình trên 80% và thường bị kẹt ở mức 100%.

Bây giờ máy đang đứng trên một máy chủ vật lý (không di chuyển giữa các máy chủ) và mặc dù chúng tôi chưa đạt được hiệu suất hoàn hảo, mọi người đều làm việc và cho phản hồi tích cực hơn nhiều, bởi vì CPU trung bình là khoảng 20% ​​với tất cả người dùng của chúng tôi và dịch vụ.

Trong khi đó, chúng tôi cũng đặt tempdb trên một đĩa khác (nó nằm trên đĩa Hệ điều hành) và chúng tôi đã tăng các tệp, để phù hợp hơn với số lượng lõi của CPU.

Số lượng lõi cũng được điều chỉnh dựa trên các khuyến nghị của sp_Blitz.

Ngoài ra còn có một thói quen tự động chạy cả ngày dựa trên một ngày cũ ... và vì nó không kết thúc vào buổi sáng khi chúng tôi đến, và chúng tôi không có cách nào để kiểm tra xem nó có chạy hay không, tôi vẫn bắt đầu chạy thủ công. Nhưng có lẽ người kia vẫn đang chạy và đã chạy hai lần trong thời gian đó. Chúng tôi đã thay đổi ngày để giảm thời gian và bây giờ là tối muộn. Nhưng đây không phải là giải pháp, vì nó đã được giải quyết trước nhiều vấn đề chúng tôi gặp phải như đã mô tả ở đây.

Chúng tôi cũng đã tìm được trợ lý ERP để sắp xếp một cuộc họp với nhà sản xuất, vì vậy chúng tôi sẽ trình bày hệ thống của mình và tìm kiếm các đề xuất, cũng như làm rõ một số nghi ngờ, vì có những khuyến nghị trong các video đào tạo trái với hầu hết các đề xuất, bao gồm cả chính Microsoft, như Boost Priority và Fill Factor 70%.

Vì ứng dụng cũng có màn hình bảo trì, tôi sẽ tìm kiếm tính định kỳ cần thiết của các bảo trì này và những gì còn lại phải làm bên ngoài ứng dụng. Ý tưởng của tôi là sử dụng các kế hoạch của Ola Hallengren.

Tôi tin rằng câu trả lời của Thomas Kronawitter là hoàn toàn chính xác và tôi đang áp dụng nó, tuy nhiên, tôi nghĩ rằng mô tả này có thể quan trọng đối với những người khác rằng sau khi làm theo tất cả các thực tiễn tốt vẫn không thể khắc phục được vấn đề vì nó có thể nằm trong máy chủ vật lý . Cảm ơn Thomas.