Sebagian besar rencana permintaan dibuat kembali dalam 4 jam terakhir


9

Saya punya masalah dengan kinerja database SQL Server saya. Saya telah menemukan alat ini sp_BlitzCache . Setelah perintah dieksekusi, saya mendapat pernyataan ini:

Anda memiliki 92,00% paket dibuat dalam 24 jam terakhir, dan 92,00% dibuat dalam 4 jam terakhir.

Sementara saya mengidentifikasi masalah (menggunakan SQL Server Profiler, saya telah memeriksa kejadian peristiwa StmtRecompile), saya dapat menemukan hanya beberapa permintaan pencarian teks lengkap yang sering dibangun kembali. Namun, permintaan pencarian teks lengkap hanya mewakili sekitar 5% dari semua permintaan.

Apakah Anda punya saran apa yang mungkin menyebabkan rekreasi dari 87% rencana yang tersisa?

Saya sudah mendapatkan SQL Server 2012 (versi 11.0.6567.0).

Sunting: Saya telah menambahkan penghitung kinerja saya

+---------------------------+--------------------------------+--------------+
|        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 |
+---------------------------+--------------------------------+--------------+

Mungkin seseorang menjalankan DBCC FREEPROCCACHE? : P
Daniel Björk

@ DanielBjörk Saya satu-satunya orang yang memiliki izin untuk melakukan hal-hal seperti ini jadi saya tidak berpikir itu alasannya. Namun, saya akan memeriksanya.
Marcin Topolewski

Apakah Anda menggunakan kueri parametrized atau prosedur tersimpan? atau apakah masalah yang Anda miliki string / angka literal dalam SQL Anda, dan karenanya rencana tidak dapat digunakan kembali?
James Z

@ JamesZ Ya, saya menggunakan banyak pertanyaan parametrized. Alat yang saya sebutkan di posting saya, BlitzCache, mengatakan bahwa saya punya masalah dengan parameter sniffing.
Marcin Topolewski

1
Apakah Anda membangun kembali indeks atau memperbarui statistik setiap malam? Mungkin ada tekanan memori di server?
Erik Darling

Jawaban:


6

Kueri yang digunakan untuk menguji waktu pembuatan paket adalah ini

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) ;

juga SP memberikan beberapa petunjuk juga di mana untuk memulai penelitian lebih lanjut Anda

Jika persentase ini tinggi, itu mungkin merupakan tanda tekanan memori atau ketidakstabilan rencana cache

Selain petunjuk di atas, periksa apakah server Anda telah dihidupkan ulang.

jika server Anda tidak direstart, maka di bawah ini adalah pendekatan yang akan saya ambil

  • periksa apakah tekanan memori Anda menghadap

Pertama lihat, jika pengaturan memori Anda dikonfigurasi secara optimal. Jika demikian, Anda dapat menggunakan penghitung di bawah ini untuk melihat apakah Anda menghadapi tekanan memori.

Memori: Tersedia MB
SQL Buffer: Halaman
SQL Buffer Gratis : Kehidupan Halaman
SQL Buffer: Menulis Malas

jika Anda menghadapi tekanan memori, maka Anda dapat melihat dan menyetel kueri yang menggunakan lebih banyak memori atau mencoba menambahkan lebih banyak memori

Anda mungkin telah menjalankan kueri yang menyebabkan kompilasi. Beberapa di antaranya termasuk

  • Perubahan yang dilakukan pada tabel atau tampilan yang dirujuk oleh kueri (ALTER TABLE dan ALTER VIEW).

  • Perubahan dibuat untuk satu prosedur, yang akan menghapus semua paket untuk prosedur itu dari cache (ALTER PROCEDURE).

  • Perubahan pada indeks apa pun yang digunakan oleh rencana eksekusi

  • Pembaruan pada statistik yang digunakan oleh rencana eksekusi, dihasilkan baik secara eksplisit dari pernyataan, seperti STATISTIK PEMBARUAN, atau dihasilkan secara otomatis.

  • Menjatuhkan indeks yang digunakan oleh rencana eksekusi.

Anda juga dapat melihat buku putih ini untuk detail lebih lanjut tentang paket caching

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


Saya telah menambahkan penghitung kinerja saya, dapatkah Anda membantu saya menafsirkan nilai-nilai ini?
Marcin Topolewski

Anda dapat melihat keluar untuk rinci memori terkait counter di sini: blogs.msdn.microsoft.com/teekamg/2007/11/06/...
TheGameiswar

@TheGameiswar Anda mengatakan "Anda mungkin telah menjalankan kueri yang menyebabkan kompilasi ... seperti perubahan indeks, pembaruan statistik". Jika saya melakukan indeks reorg / membangun kembali berdasarkan statistik fragmentasi + pembaruan setiap malam, apakah itu berarti rencana saya semua akan (atau hampir semua) dibuat kembali setiap hari? apakah itu masalah?
Danielle Paquette-Harvey

2

Untuk menambahkan apa yang dikatakan @TheGameiswar, Anda juga dapat menjalankan kueri ini untuk melihat detail paket yang tidak diperoleh dari cache.

;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;
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.