Hầu hết các kế hoạch truy vấn được tạo lại trong 4 giờ qua


9

Tôi gặp vấn đề với hiệu suất của cơ sở dữ liệu SQL Server. Tôi đã tìm thấy công cụ này sp_BlitzCache . Sau khi thực thi lệnh, tôi nhận được tuyên bố này:

Bạn có 92,00% kế hoạch được tạo trong 24 giờ qua và 92,00% được tạo trong 4 giờ qua.

Trong khi tôi xác định sự cố (sử dụng SQL Server Profiler, tôi đã kiểm tra các sự kiện StmtRecompile), tôi chỉ có thể tìm thấy một vài truy vấn tìm kiếm toàn văn bản thường được xây dựng lại. Tuy nhiên, truy vấn tìm kiếm toàn văn chỉ chiếm khoảng 5% trong số tất cả các truy vấn.

Bạn có bất cứ đề xuất nào có thể gây ra sự giải trí của các kế hoạch 87% còn lại không?

Tôi đã có SQL Server 2012 (phiên bản 11.0,6567.0).

Chỉnh sửa: Tôi đã thêm bộ đếm hiệu suất của mình

+---------------------------+--------------------------------+--------------+
|        object_name        |          counter_name          |  cntr_value  |
+---------------------------+--------------------------------+--------------+
| SQLServer:Buffer Manager  | Background writer pages/sec    |            0 |
| SQLServer:Buffer Manager  | Buffer cache hit ratio         |        28436 |
| SQLServer:Buffer Manager  | Buffer cache hit ratio base    |        28436 |
| SQLServer:Buffer Manager  | Checkpoint pages/sec           |      8259452 |
| SQLServer:Buffer Manager  | Database pages                 |      4434337 |
| SQLServer:Buffer Manager  | Free list stalls/sec           |            9 |
| SQLServer:Buffer Manager  | Integral Controller Slope      |            0 |
| SQLServer:Buffer Manager  | Lazy writes/sec                |         5608 |
| SQLServer:Buffer Manager  | Page life expectancy           |       438901 |
| SQLServer:Buffer Manager  | Page lookups/sec               | 122694703703 |
| SQLServer:Buffer Manager  | Page reads/sec                 |     60994608 |
| SQLServer:Buffer Manager  | Page writes/sec                |    126076564 |
| SQLServer:Buffer Manager  | Readahead pages/sec            |     45305420 |
| SQLServer:Buffer Manager  | Target pages                   |    130990080 |
| SQLServer:Buffer Node     | Database pages                 |      4434337 |
| SQLServer:Buffer Node     | Page life expectancy           |       438901 |
| SQLServer:Buffer Node     | Local node page lookups/sec    |            0 |
| SQLServer:Buffer Node     | Remote node page lookups/sec   |            0 |
| SQLServer:Memory Manager  | External benefit of memory     |            0 |
| SQLServer:Memory Manager  | Connection Memory (KB)         |         3304 |
| SQLServer:Memory Manager  | Database Cache Memory (KB)     |     35474784 |
| SQLServer:Memory Manager  | Free Memory (KB)               |     13229808 |
| SQLServer:Memory Manager  | Granted Workspace Memory (KB)  |            0 |
| SQLServer:Memory Manager  | Lock Memory (KB)               |       455928 |
| SQLServer:Memory Manager  | Lock Blocks Allocated          |      1798154 |
| SQLServer:Memory Manager  | Lock Owner Blocks Allocated    |      3568588 |
| SQLServer:Memory Manager  | Lock Blocks                    |        10562 |
| SQLServer:Memory Manager  | Lock Owner Blocks              |        10617 |
| SQLServer:Memory Manager  | Maximum Workspace Memory (KB)  |     43368000 |
| SQLServer:Memory Manager  | Memory Grants Outstanding      |            0 |
| SQLServer:Memory Manager  | Memory Grants Pending          |            0 |
| SQLServer:Memory Manager  | Optimizer Memory (KB)          |         1400 |
| SQLServer:Memory Manager  | Reserved Server Memory (KB)    |            0 |
| SQLServer:Memory Manager  | SQL Cache Memory (KB)          |       229112 |
| SQLServer:Memory Manager  | Stolen Server Memory (KB)      |      8063232 |
| SQLServer:Memory Manager  | Log Pool Memory (KB)           |         4192 |
| SQLServer:Memory Manager  | Target Server Memory (KB)      |     56934400 |
| SQLServer:Memory Manager  | Total Server Memory (KB)       |     56767824 |
| SQLServer:Memory Node     | Database Node Memory (KB)      |     35474784 |
| SQLServer:Memory Node     | Free Node Memory (KB)          |     13229808 |
| SQLServer:Memory Node     | Foreign Node Memory (KB)       |            0 |
| SQLServer:Memory Node     | Stolen Node Memory (KB)        |      8063208 |
| SQLServer:Memory Node     | Target Node Memory (KB)        |     56934376 |
| SQLServer:Memory Node     | Total Node Memory (KB)         |     56767800 |
+---------------------------+--------------------------------+--------------+

Có lẽ ai đó đã chạy DBCC FREEPROCCACHE? : P
Daniel Bjork

@ DanielBjork Tôi là người duy nhất được phép làm những việc như thế này nên tôi không nghĩ đó là lý do. Tuy nhiên, tôi sẽ kiểm tra nó.
Marcin Topolewski

Bạn đang sử dụng truy vấn tham số hoặc thủ tục lưu trữ? hoặc là vấn đề mà bạn có chuỗi ký tự / số trong SQL của bạn và do đó các kế hoạch không thể được sử dụng lại?
James Z

@JamesZ Có, tôi đang sử dụng rất nhiều truy vấn tham số. Công cụ mà tôi đã đề cập trong bài đăng của mình, BlitzCache, nói rằng tôi có vấn đề với việc đánh hơi thông số.
Marcin Topolewski

1
Bạn đang xây dựng lại các chỉ mục hoặc cập nhật số liệu thống kê hàng đêm? Có lẽ có áp lực bộ nhớ trên máy chủ?
Erik Darling

Câu trả lời:


6

Truy vấn được sử dụng để kiểm tra thời gian tạo kế hoạch là đây

WITH x AS (
SELECT SUM(CASE WHEN DATEDIFF(HOUR, deqs.creation_time, SYSDATETIME()) <= 24 THEN 1 ELSE 0 END) AS [plans_24],
       SUM(CASE WHEN DATEDIFF(HOUR, deqs.creation_time, SYSDATETIME()) <= 4 THEN 1 ELSE 0 END) AS [plans_4],
       SUM(CASE WHEN DATEDIFF(HOUR, deqs.creation_time, SYSDATETIME()) <= 1 THEN 1 ELSE 0 END) AS [plans_1],
       COUNT(deqs.creation_time) AS [total_plans]
FROM sys.dm_exec_query_stats AS deqs
)
SELECT CONVERT(DECIMAL(3,2), NULLIF(x.plans_24, 0) / (1. * NULLIF(x.total_plans, 0))) * 100 AS [percent_24],
       CONVERT(DECIMAL(3,2), NULLIF(x.plans_4 , 0) / (1. * NULLIF(x.total_plans, 0))) * 100 AS [percent_4],
       CONVERT(DECIMAL(3,2), NULLIF(x.plans_1 , 0) / (1. * NULLIF(x.total_plans, 0))) * 100 AS [percent_1],
       @@SPID AS SPID
INTO #plan_creation
FROM x
OPTION (RECOMPILE) ;

SP cũng cung cấp một số manh mối về nơi bắt đầu nghiên cứu tiếp theo của bạn

Nếu tỷ lệ phần trăm này cao, đó có thể là dấu hiệu của áp lực bộ nhớ hoặc không ổn định bộ nhớ cache

Khác với manh mối trên, kiểm tra xem máy chủ của bạn đã được khởi động lại chưa.

nếu máy chủ của bạn không được khởi động lại, thì dưới đây là cách tiếp cận tôi sẽ thực hiện

  • kiểm tra xem áp lực bộ nhớ của bạn

Trước tiên hãy xem, nếu cài đặt bộ nhớ của bạn được cấu hình tối ưu. Nếu vậy, bạn có thể sử dụng các bộ đếm bên dưới để xem bạn có đang đối mặt với áp lực bộ nhớ không

Bộ nhớ:
Bộ đệm SQL SQL có sẵn: Bộ đệm SQL miễn phí
: Trang cuộc sống
Bộ đệm SQL: Lazy Writes

nếu bạn đang đối mặt với áp lực bộ nhớ, thì bạn có thể xem và điều chỉnh các truy vấn đang sử dụng nhiều bộ nhớ hơn hoặc thử thêm bộ nhớ

bạn có thể đã chạy các truy vấn gây ra biên dịch lại. một số trong số chúng bao gồm

  • Các thay đổi được thực hiện đối với bảng hoặc dạng xem được tham chiếu bởi truy vấn (ALTER TABLE và ALTER VIEW).

  • Các thay đổi được thực hiện cho một thủ tục duy nhất, sẽ loại bỏ tất cả các kế hoạch cho thủ tục đó khỏi bộ đệm (THỦ TỤC THAY ĐỔI).

  • Thay đổi đối với bất kỳ chỉ mục nào được sử dụng bởi kế hoạch thực hiện

  • Cập nhật về số liệu thống kê được sử dụng bởi kế hoạch thực hiện, được tạo rõ ràng từ một câu lệnh, chẳng hạn như CẬP NHẬT THỐNG KÊ, hoặc được tạo tự động.

  • Bỏ một chỉ số được sử dụng bởi kế hoạch thực hiện.

bạn cũng có thể xem tờ giấy trắng này để biết thêm chi tiết về Kế hoạch bộ nhớ đệm

https://technet.microsoft.com/en-us/l Library / ee343986 (v = sql.100) .aspx


Tôi đã thêm bộ đếm hiệu suất của mình, bạn có thể giúp tôi diễn giải các giá trị này không?
Marcin Topolewski

bạn có thể tìm cho ra quầy nhớ liên quan đến chi tiết ở đây: blogs.msdn.microsoft.com/teekamg/2007/11/06/...
TheGameiswar

@TheGameiswar bạn nói "bạn có thể đã chạy các truy vấn gây ra việc biên dịch lại ... chẳng hạn như thay đổi chỉ mục, cập nhật về số liệu thống kê". Nếu tôi thực hiện chỉ mục reorg / xây dựng lại dựa trên phân số + cập nhật thống kê mỗi đêm, điều đó có nghĩa là tất cả các kế hoạch của tôi sẽ được (hoặc gần như tất cả) được tạo lại mỗi ngày? đó có phải là vấn đề không?
Danielle Paquette-Harvey

2

Để thêm những gì @TheGameiswar nói, bạn cũng có thể chạy truy vấn này để xem chi tiết về các gói không lấy được từ bộ đệm.

;with
    xmlnamespaces (N'http://schemas.microsoft.com/sqlserver/2004/07/showplan' as DYN)
select
    db_name(st.dbid) as DBName
    , object_schema_name(st.objectid, st.dbid) as SchemaName
    , object_name(st.objectid, st.dbid) as ObjectName
    , ecp.objtype
    , st.text
    , qp.query_plan.value('(/DYN:ShowPlanXML/DYN:BatchSequence/DYN:Batch/DYN:Statements/DYN:StmtSimple/@RetrievedFromCache)[1]', 'varchar(100)') as RetrievedFromCache
    , qp.query_plan
into #temp
from sys.dm_exec_cached_plans ecp
    outer apply sys.dm_exec_query_plan(ecp.plan_handle) qp
    outer apply sys.dm_exec_sql_text(ecp.plan_handle) st

select
    *
from #temp t
where t.RetrievedFromCache is null
    and t.DBName is not null
order by t.DBName, t.SchemaName, t.ObjectName;
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.