Kế hoạch tái tạo máy chủ SQL mỗi ngày


14

Chúng tôi có vấn đề này trong môi trường sản xuất của chúng tôi.

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) - Phiên bản doanh nghiệp (64-bit) trên Windows NT 6.1 (Bản dựng 7601: Gói dịch vụ 1).

SQL Server đang bỏ tất cả (gần như 100%) các kế hoạch thực hiện cũ và tạo lại chúng hàng ngày qua đêm (từ 11:00 PM đến 8:00 AM). Điều này thậm chí đã xảy ra khi 'số liệu thống kê cập nhật tự động' ở trạng thái bị vô hiệu hóa. Chúng tôi đã bật 'thống kê cập nhật tự động' trong 2-3 tuần qua. Nhưng nó vẫn xảy ra.

Chúng tôi thực sự không biết điều gì kích hoạt việc tạo lại kế hoạch này nhưng chúng tôi chắc chắn rằng chúng tôi không thực hiện thủ công.

Điều duy nhất thực sự trùng khớp với thời gian của các kế hoạch được tái tạo là công việc bảo trì DB mà chúng ta có: sắp xếp lại chỉ số hàng ngày (khi phân mảnh là 5-30%) và xây dựng lại chỉ số hàng ngày (khi phân mảnh là hơn 30% ) việc làm. Thông thường công việc bảo trì hàng ngày này chỉ tổ chức lại (vì sự phân mảnh chỉ số không bao giờ quá 30% trên cơ sở hàng ngày).

Sự va chạm:

Các gói mới được tạo này làm cho một số cuộc gọi / cuộc gọi truy vấn UDF (được gọi từ các trang web / giao diện người dùng) diễn ra lâu hơn (phút so với dưới 1 giây), và do đó, các phiên chỉ được chồng chất lên với CPU gần 90% .

Vấn đề sẽ biến mất ngay khi các phiên bị kẹt đó bị xóa mạnh (về phía DB) và 1) khi tất cả các kế hoạch thực hiện tương ứng được xóa thủ công (đối với các truy vấn) hoặc 2) khi UDF bị thay đổi (đối với các hàm). Bất kỳ kế hoạch mới nào được tạo bởi máy chủ SQL từ thời điểm đó đều hoạt động hoàn hảo suốt cả ngày cho đến khi nó kết thúc với cùng một vấn đề vào sáng hôm sau. Ngoài ra, hành vi này không nhất quán 100%, chúng tôi không thực sự nhìn thấy nó mỗi sáng. Nhưng đã có những khoảng thời gian chúng ta thấy nó liên tục trong 4-5 ngày liên tiếp.

Vấn đề xảy ra vào buổi sáng kinh doanh, đó là khi các trang web UI / web được truy cập mạnh mẽ hơn, dường như.

Có ai có manh mối gì gây ra điều này và làm thế nào để giải quyết vấn đề này? Bất kì sự trợ giúp nào đều được đánh giá cao.


3
Plancache có thể được giải phóng khi máy chịu áp lực bộ nhớ hoặc nếu bạn thay đổi cài đặt ở mức db db. (thay đổi db). Vì bạn nói rằng bạn không xóa chúng "thủ công", tôi cho rằng đó có thể là áp lực bộ nhớ. Máy có bao nhiêu bộ nhớ? cài đặt bộ nhớ tối đa của bạn là gì? Bạn có một môi trường ảo và có thể RAM tổng thể?
RayofCommand

6
Tại sao bạn ở SP1. Trước khi bạn làm bất cứ điều gì áp dụng SP3. SQL Server có thể buộc các kế hoạch ra ngoài nếu nó tìm thấy áp lực bộ nhớ và cần thêm bộ nhớ để chứa các trang đặc biệt từ việc xây dựng lại chỉ mục đặc biệt nếu bạn có các bảng lớn. Xây dựng lại chỉ mục sẽ cố gắng mang lại càng nhiều trang càng tốt. Những gì bạn có thể làm là ngừng sử dụng MP và sử dụng giải pháp Ola Hallengren và xem điều này có giúp ích gì không. Bộ nhớ máy chủ tối đa là gì?
Shanky

1
Các bạn, tôi không phải là một DBA, chỉ là một nhà phát triển SQL. Tôi chỉ hỏi tất cả những điều này vì nó đã diễn ra khá lâu. Cảm ơn ý kiến ​​của bạn, tôi sẽ cố gắng trả lời tất cả chúng, mặc dù bây giờ tôi cảm thấy khó theo dõi (và tất cả có vẻ khá rõ ràng đối với bạn). MP là gì?
peter.petrov

1
@ peter.petrov chúng tôi đang cố gắng giúp bạn bằng cách tìm hiểu môi trường của bạn. MP = Kế hoạch bảo trì.
Kin Shah

1
Vấn đề thực sự là các kế hoạch truy vấn của bạn rất mong manh. Tái hợp có thể xảy ra bất cứ lúc nào, ngay cả trong ngày. Không đảm bảo. Sửa các truy vấn của bạn để các kế hoạch trở nên ổn định. TÙY CHỌN TÙY CHỌN hoặc TỐI ƯU HÓA CHO UNKNOWN là những cách tiếp cận búa tạ có thể phù hợp và là một sửa chữa nhanh chóng.
usr

Câu trả lời:


2

Vâng, tôi có một số ý tưởng có thể gây ra hành vi này.

  1. Bạn có theo dõi áp lực bộ nhớ của bạn? Có thể các truy vấn của bạn tăng một giới hạn nhất định sẽ gây ra lỗi bộ đệm của kế hoạch. Tôi không biết ứng dụng của bạn, nhưng điều này có tương ứng với nhật ký của bạn từ các máy chủ lối vào của bạn không? Có áp lực quá trong thời gian này?
  2. Bạn có Máy chủ SQL chuyên dụng hay máy chủ chia sẻ phần cứng của nó với các quy trình / dịch vụ khác không? Nếu không, hãy thử cân nhắc thuê ngoài SQL Server của bạn cho một máy chuyên dụng. Điều này sẽ làm giảm tác dụng phụ từ các dịch vụ khác.
  3. Bạn có thể muốn sử dụng optimize for ad hoc workloads, nó sẽ chỉ lưu sơ đồ kế hoạch và biên dịch nó nếu cần. Điều này sẽ làm giảm tải của plancache của bạn, điều này sẽ làm giảm khả năng bị plancache. Bạn có thể kích hoạt nó bằng cách sử dụng sp_configure 'optimize for ad hoc workloads',1; reconfigure. Điều này có thể được thực hiện nếu bạn đã kích hoạt việc advanced optionssử dụng sp_configure 'show advanced options',1; reconfigure.
  4. Một ý tưởng khác có thể được sao lưu. Chỉ cần sao lưu đơn giản. Nếu họ hung hăng, có thể máy của bạn cũng chịu áp lực. Thời gian đề cập của bạn nghe có vẻ như là một khoảng thời gian tốt để lập kế hoạch sao lưu.
  5. Có lẽ nó khá đơn giản là một lỗi trong tập lệnh bảo trì của bạn. Bạn đã kiểm tra xem có vấn đề logic nào khiến tập lệnh của bạn xây dựng lại tất cả các chỉ số thay vì chỉ những người phù hợp với tiêu chí hay không. Điều này có thể có thể gây ra nó quá.

Chỉ cần bên cạnh tất cả các khả năng này, nó có thể hữu ích để kiểm tra các tập tin log cho một số thay đổi các tùy chọn affinity mask, affinity I/O maskvà các đối tác x64 của họ. Một điều khác có thể là một sự thay đổi của MAXDOPtùy chọn của trường hợp của bạn. Vui lòng kiểm tra các bản ghi cho họ quá. Họ cũng sẽ cần phải xả plancache.

Cuối cùng nhưng không kém phần quan trọng, bạn vẫn có thể chạy theo dõi máy chủ (chỉ cần thiết lập nó bằng cách sử dụng trình lược tả, khởi động nó, dừng nó và sử dụng lệnh sql để bắt đầu lại trên máy chủ). Bên cạnh đó perfmonlà bạn của bạn. Nó có thể xem và theo dõi các giá trị hiệu suất của bạn trong một thời gian. Có lẽ bạn có thể thấy sự tương đồng trong áp lực với một số hành động nhất định trên máy chủ của bạn có thể gây ra những hành động đó.

Hy vọng rằng điều này sẽ giúp bạn, ngay cả khi câu trả lời đến sau một chút.

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.