Các Compilations SQL ảnh hưởng xấu đến hiệu năng của SQL Server như thế nào?


20

Tôi đang định hình một phiên bản của SQL Server 2005 và tôi, thông qua SQLServer:SQL Statistics - SQL Compilations/secsố liệu của PerfMon , tôi thấy rằng trung bình là khoảng 170 hoặc hơn.

Tôi đã xóa SQL Profiler và tìm kiếm các sự kiện SP: Compile hoặc SQL: Compile. Rõ ràng chúng không tồn tại. Tôi đã tìm thấy Stored Procedure/SP:RecompileTSQL/SQL:StmtRecompilecác sự kiện. Lượng dữ liệu tôi thấy trong Profiler cho thấy đây là những sự kiện sai để xem xét, mặc dù tôi không chắc chắn.

Vì vậy, câu hỏi của tôi. Câu trả lời cho bất kỳ trong số này sẽ là tuyệt vời.

  1. Làm cách nào tôi có thể thấy chính xác những gì đang biên dịch trong SQL Server?
  2. Tôi đã chọn sai số liệu để xem xét? Trong Perfmon hoặc SQL Profiler?
  3. Liên quan đến Stored Procedure/SP:RecompileTSQL/SQL:StmtRecompilecác sự kiện trong SQL Profiler ... chúng không bao gồm số liệu Thời lượng. Làm cách nào tôi có thể đánh giá tác động của các sự kiện này đến hệ thống nếu chúng không cung cấp cách nào để xem tác động thời gian đến hệ thống.

Câu trả lời:


33

SQL Compilations / giây là một số liệu tốt, nhưng chỉ khi được kết hợp với Yêu cầu hàng loạt / giây . Chính nó, các phần tổng hợp mỗi giây không thực sự cho bạn biết nhiều.

Bạn đang nhìn thấy 170. Nếu req lô mỗi giây chỉ là 200 (hơi phóng đại về hiệu quả) thì có, bạn cần phải đi xuống tận cùng của nguyên nhân (rất có thể là lạm dụng các kế hoạch truy vấn và sử dụng một lần). Nhưng nếu req lô mỗi giây của bạn đo được khoảng 5000 thì 170 tổng hợp mỗi giây không tệ chút nào. Đó là một quy tắc chung rằng Tổng hợp / giây phải ở mức 10% hoặc ít hơn tổng số Yêu cầu hàng loạt / giây .

Nếu bạn thực sự muốn đi sâu vào những gì đang được lưu trong bộ nhớ cache, hãy chạy truy vấn sau sử dụng DMV phù hợp:

select
    db_name(st.dbid) as database_name,
    cp.bucketid,
    cp.usecounts,
    cp.size_in_bytes,
    cp.objtype,
    st.text
from sys.dm_exec_cached_plans cp
cross apply sys.dm_exec_sql_text(cp.plan_handle) st

Để có được tất cả các gói sử dụng một lần (tính):

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
)
select count(*)
from PlanCacheCte
where usecounts = 1

Để có được tỷ lệ số lượng gói sử dụng một lần bạn có so với tất cả các gói được lưu trong bộ nhớ cache:

declare @single_use_counts int, @multi_use_counts int

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
    where cp.cacheobjtype = 'Compiled Plan'
)
select @single_use_counts = count(*)
from PlanCacheCte
where usecounts = 1

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
    where cp.cacheobjtype = 'Compiled Plan'
)
select @multi_use_counts = count(*)
from PlanCacheCte
where usecounts > 1

select
    @single_use_counts as single_use_counts,
    @multi_use_counts as multi_use_counts,
    @single_use_counts * 1.0 / (@single_use_counts + @multi_use_counts) * 100
        as percent_single_use_counts

Đối với thời lượng được ghi lại thông qua Dấu vết máy chủ SQL, nó không có sẵn cho các sự kiện Biên dịch lại. Sẽ không quá quan trọng để xem thời lượng hoặc nỗi đau mà việc biên soạn kế hoạch gây ra, vì bạn không thể làm gì nhiều cho tình huống từng trường hợp cụ thể. Giải pháp là cố gắng hạn chế biên dịch và biên dịch lại thông qua việc sử dụng lại kế hoạch (truy vấn tham số, thủ tục lưu trữ, v.v.).


9

Có ba bộ đếm liên quan nên được ghi lại bằng PerfMon (hoặc một giải pháp bên thứ 3 khác). Điểm mấu chốt là ghi lại những chỉ số này bằng cách nào đó.

  • Thống kê SQL \ Yêu cầu hàng loạt / giây
  • Thống kê SQL \ Tổng hợp SQL / giây
  • Thống kê SQL \ Biên dịch lại SQL / giây

Như Thomas Stringer đã đề cập , thật tốt khi theo dõi tỷ lệ tổng hợp / yêu cầu lô. Rõ ràng, thấp hơn là tốt hơn, nhưng chỉ có hướng dẫn cho những gì là "tốt", và chỉ bạn mới có thể quyết định những gì được chấp nhận. Lượng lợi ích hoàn hảo mà bạn sẽ thấy bằng cách giảm số lượng các phần tổng hợp phụ thuộc vào nhiều yếu tố.

Tôi cũng muốn xem xét tỷ lệ biên dịch lại / biên dịch , để hiểu được mức độ sử dụng lại kế hoạch truy vấn. Một lần nữa, thấp hơn là tốt hơn. Tuy nhiên, trong trường hợp này, bạn muốn có các biên dịch lại xảy ra trong hệ thống khi số liệu thống kê thay đổi (nếu DB chỉ đọc và bạn đã biên dịch lại ... có thể có gì đó không đúng). Giống như tôi đã nói trước đây, chỉ có hướng dẫn cho những gì là "tốt".

Những gì bạn thực sự muốn làm là xu hướng những con số này theo thời gian, vì vậy nếu bạn thấy một sự tăng đột biến ở một trong hai tỷ lệ, một cái gì đó đã được triển khai không sử dụng kế hoạch truy vấn một cách chính xác (lý tưởng, điều này bị bắt trong khi thử nghiệm) - hãy sử dụng Shark phân tích truy vấn để tìm ra thủ phạm. Ngoài ra, đây là một để tìm các truy vấn được biên dịch lại thường xuyên:

SELECT TOP 50
    qs.plan_generation_num,
    qs.execution_count,
    qs.statement_start_offset,
    qs.statement_end_offset,
    st.text
    FROM sys.dm_exec_query_stats qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
    WHERE qs.plan_generation_num > 1
    ORDER BY qs.plan_generation_num DESC

Nếu bạn cũng đang ghi lại các số liệu thống kê cho việc sử dụng CPU, tất cả các số liệu thống kê có thể được tương quan với nhau để tìm ra mức độ tổn thương và mức độ khắc phục của bạn giúp ích. Trong thực tế, tôi đã thấy rằng thậm chí chỉ một chiến lược kế hoạch truy vấn xấu duy nhất trên một trục chính có thể khiến máy chủ quỳ xuống; rõ ràng là YMMV.

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.