Làm thế nào để trả lời tại sao đột nhiên chúng ta cần thay đổi chỉ mục hoặc truy vấn cần phải thay đổi

Tôi là DBA cơ sở với 3 năm kinh nghiệm. Công việc của chúng tôi là tinh chỉnh các truy vấn hoặc tư vấn cho các nhà phát triển rằng mã cụ thể nên được viết lại hoặc cần lập chỉ mục.

Một câu hỏi đơn giản mà nhóm phát triển thường hỏi là: "Hôm qua nó chạy tốt, điều gì đã thay đổi đột ngột?" và chúng tôi sẽ được yêu cầu kiểm tra phía cơ sở hạ tầng. Phản ứng đầu tiên về bất kỳ vấn đề nào luôn xuất hiện là đổ lỗi tối đa cho cơ sở hạ tầng luôn là điều đầu tiên được xác nhận.

Làm thế nào chúng ta nên trả lời các câu hỏi "những gì đã thay đổi" của nhóm phát triển? Các bạn đã bao giờ phải đối mặt với tình huống tương tự? Nếu vậy, hãy chia sẻ kinh nghiệm của bạn.

Làm thế nào để trả lời những gì thay đổi câu hỏi của dev?

Đây là một câu hỏi rất phổ biến không chỉ với DEV, nó áp dụng cho mọi nhóm trong CNTT và kinh doanh.

Những gì đã thay đổi ? ==> có thể được trả lời bằng thực tế và số liệu.

Sự kiện tham khảo ví dụ

• tăng lượng người dùng đang truy cập cơ sở dữ liệu?
• Bất kỳ thay đổi trong tham số cấu hình máy chủ?
• Bảo trì cơ sở dữ liệu - cập nhật số liệu thống kê, sắp xếp lại / xây dựng lại các chỉ mục không được thực hiện? Do đó, các kế hoạch đang được tạo ra không chính xác!
• Lượng dữ liệu đã tăng?
• Các thay đổi đã được thực hiện ở phía mạng, HĐH đã được vá và / hoặc gói dịch vụ mới hoặc CU cho máy chủ sql đã được triển khai - mà không thực hiện kiểm tra hồi quy đầy đủ cho chu kỳ kinh doanh ứng dụng của bạn ?
• SAN cơ bản đã trở nên chậm đột ngột?

Số liệu có thể được lấy nếu bạn có dữ liệu để hiển thị. Ví dụ :

• Liên kết máy chủ của bạn là rất quan trọng trong tình huống này. Điều này sẽ làm giảm bớt trò chơi đổ lỗi vì bạn có thể hỗ trợ các sự kiện với các số liệu vững chắc.
• Bắt đầu thu thập dữ liệu bằng DMV hoặc sp_whoisactive vào bảng để dữ liệu được duy trì sau khi khởi động lại máy chủ sql.

(bạn phải tập luyện dựa trên môi trường và nhu cầu của mình, về tần suất thu thập dữ liệu / dữ liệu nào cần thu thập và thời gian lưu giữ là bao nhiêu) hoặc (bạn có thể đầu tư vào phần mềm của bên thứ ba như sqlsentry hoặc idera sẽ làm những công việc trên cho bạn) .

Chà, bạn có thể nhận được một kế hoạch khác bởi vì:

• kế hoạch có thể đã bị đuổi khỏi bộ đệm, do:
  • khởi động lại dịch vụ
  • xóa thủ công bộ đệm kế hoạch
  • một dịch vụ khởi động lại hoặc chuyển đổi dự phòng
  • một sự thay đổi vô tình, ví dụ như một số sp_configurethay đổi nhất định có thể xóa bộ đệm
  • một số thay đổi đối với các đối tượng cơ bản, chỉ mục, số liệu thống kê hoặc các phụ thuộc khác đã kích hoạt biên dịch lại
• bạn chỉ có thể nhận được một gói khác so với (các) người dùng khác hoặc các yêu cầu trước đó bởi vì:
  • văn bản truy vấn có thể không giống nhau (điều này bao gồm độ nhạy trường hợp và khoảng trắng, không bao giờ để ý các cột khác nhau, tiêu chí tham gia, bộ lọc, v.v.)
  • truy vấn có thể được chạy bởi những người dùng khác nhau với các tùy chọn thiết lập khác nhau (hoặc các lược đồ mặc định khác nhau, nếu bất kỳ đối tượng nào trong kế hoạch không có tên đủ điều kiện, bao gồm cả lược đồ )
• truy vấn và kế hoạch có thể giống nhau, nhưng bạn có thể nhận được hiệu suất khác nhau vì:
  • kế hoạch được lưu trữ bằng cách sử dụng các tham số khác nhau và kế hoạch đó không tối ưu cho bộ thông số hiện tại (điều này thường được gọi là "đánh hơi tham số")
  • lượng dữ liệu dựa trên các tham số hoặc đơn giản là do thay đổi dữ liệu trong khi đó là khác nhau đáng kể
  • dữ liệu đã thay đổi đủ để thay đổi cách hiệu quả nhất để truy cập dữ liệu, nhưng không đủ để kích hoạt cập nhật hoặc biên dịch lại thống kê (tìm kiếm vấn đề chính tăng dần cũng như thuật toán thống kê tự động)
  • dữ liệu đã bị xóa khỏi vùng đệm và bây giờ phải đọc từ đĩa
  • có sự đồng thời cao hơn, chặn hoặc các chủng khác về tài nguyên cần thiết để đáp ứng truy vấn

Tôi đi qua rất nhiều trong số này chi tiết hơn ở đây:

• Nhiều kế hoạch cho một truy vấn "giống hệt"

Nếu chúng chạy trên các môi trường khác nhau, thì tôi có cả loạt thứ cần kiểm tra ở đây:

• Các kế hoạch khác nhau cho máy chủ "giống hệt"

Ngoài ra, điều quan trọng cần lưu ý là việc tạo chỉ mục hoặc thay đổi truy vấn có thể không phải là lý do trực tiếp khiến truy vấn đột nhiên hoạt động tốt hơn - đôi khi chỉ vì những thay đổi đó thực sự tạo ra một kế hoạch mới và / hoặc vô hiệu hóa kế hoạch đã tồn tại .

Như thường lệ Aaron Bertrand và Kin cung cấp câu trả lời tuyệt vời. Tuy nhiên cả hai câu trả lời đều chứa một chủ đề chung. Nếu bạn phân tích một trong hai câu trả lời, bạn sẽ thấy rằng lý do tại sao XYZ không hoạt động như ngày hôm qua không phải là do bạn / họ / người X đã làm. Lý do tại sao mọi thứ thay đổi là vì cơ sở dữ liệu quyết định làm những điều khác biệt vì lý do XYZ.

Một cơ sở dữ liệu là một thực thể sống, thở . Cơ sở dữ liệu sẽ đưa ra quyết định và thay đổi ý định do sự kết hợp của các giả định, số liệu thống kê và các công cụ heuristic khác. Điều này khác biệt đáng kể so với hầu hết lập trình lớp ứng dụng (máy học là một ngoại lệ đáng chú ý).

_{Tôi sẽ sử dụng một số tài liệu tham khảo quân sự bởi vì tôi không thể nghĩ ra thứ gì đó tốt hơn ngay bây giờ. Một phép ẩn dụ tổng quát hơn sẽ được đánh giá cao (không có ý định chơi chữ).}

Trong hầu hết các ứng dụng, lập trình viên đóng vai trò là người hướng dẫn khoan. Họ nói với máy tính chính xác những gì cần làm, theo thứ tự và đôi khi trong bao lâu. Lập trình một cơ sở dữ liệu giống như là một sĩ quan chỉ huy. Bạn nói với nó những gì bạn muốn nó làm ở mức cao, và cung cấp một số hướng dẫn khi cần thiết. Cơ sở dữ liệu đảm nhận công việc tìm ra cách tốt nhất để thực hiện kế hoạch dựa trên trí thông minh hiện tại như các sĩ quan cấp dưới và hạ sĩ quan.

Bằng cách làm rõ sự khác biệt này trong tâm trí lập trình viên khác, họ hy vọng sẽ bắt đầu thấy rằng bạn không có quyền lực độc tài như họ làm trong môi trường của họ. Bạn đang hướng dẫn cơ sở dữ liệu đến giải pháp và đôi khi cơ sở dữ liệu bị lạc hướng vì những lý do tốt hay xấu. Nhắc nhở họ rằng cuối cùng không có vấn đề gì tại sao * cơ sở dữ liệu bị lạc hướng, nhưng chúng ta có thể làm gì để đưa nó trở lại.

_{* Tôi nhận ra "tại sao" rất có giá trị cho việc phòng ngừa, học tập trong tương lai, nhưng có vẻ như OP đang phải đối mặt với sự kháng cự từ những người không cố gắng tìm hiểu hoặc giúp đỡ vấn đề.}