Sorgu planlarının çoğu son 4 saat içinde yeniden oluşturuldu


9

SQL Server veritabanımın performansıyla ilgili bir sorunum var. Bu aracı sp_BlitzCache buldum . Komut yürütüldükten sonra şu ifadeyi aldım:

Son 24 saatte% 92.00 ve son 4 saatte% 92.00 planlarınız var.

Sorunu tanımlarken (SQL Server Profiler kullanarak, StmtRecompile olay olaylarını kontrol ettim), yalnızca yeniden oluşturulan yalnızca birkaç tam metin arama sorgusu bulabildim. Ancak, tam metin arama sorguları, tüm sorguların yalnızca% 5'ini temsil eder.

Kalan% 87'lik planların yeniden oluşturulmasına neden olabilecek herhangi bir öneriniz var mı?

SQL Server 2012 (sürüm 11.0.6567.0) var.

Düzenleme: Performans sayaçlarımı ekledim

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

Belki birisi DBCC FREEPROCCACHE'i yönetti? : P
Daniel Björk

@ DanielBjörk Böyle şeyler yapma iznine sahip tek kişi benim, bu yüzden bunun sebebi olduğunu düşünmüyorum. Ancak, kontrol edeceğim.
Marcin Topolewski

Parametreli sorgular veya saklı yordamlar mı kullanıyorsunuz? ya da SQL'inizde dize / sayı değişmezleri olması sorunudur ve bu nedenle planlar yeniden kullanılamaz mı?
James Z

@JamesZ Evet, birçok parametreli sorgu kullanıyorum. Yazımda bahsettiğim araç BlitzCache, parametre koklama ile ilgili bir sorunum olduğunu söylüyor.
Marcin Topolewski

1
Endeksleri yeniden oluşturuyor veya istatistikleri her gece güncelliyor musunuz? Belki sunucuda bellek baskısı var mı?
Erik Darling

Yanıtlar:


6

Plan oluşturma süresini test etmek için kullanılan sorgu şudur:

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

ayrıca SP daha fazla araştırmanıza nereden başlayacağınıza dair bazı ipuçları da sunar

Bu yüzdeler yüksekse, bellek baskısı veya önbellek kararsızlığı işareti olabilir

Yukarıdaki ipuçları dışında, sunucunuzun yeniden başlatılıp başlatılmadığını kontrol edin.

sunucunuz yeniden başlatılmazsa, aşağıda alacağım yaklaşım

  • hafıza belleğinizin karşı olup olmadığını kontrol edin

Öncelikle, bellek ayarlarınız en iyi şekilde yapılandırılmışsa bakın. Eğer öyleyse, bellek baskısıyla karşılaşıp karşılaşmadığınızı görmek için aşağıdaki sayaçları kullanabilirsiniz

Bellek: Kullanılabilir MB
SQL Buffer: Ücretsiz Sayfalar
SQL Buffer: Page Life
SQL Buffer: Lazy Writes

bellek baskısıyla karşılaşıyorsanız, daha fazla bellek kullanan sorguları görebilir ve ayarlayabilirsiniz veya daha fazla bellek eklemeyi deneyebilirsiniz

Eğer recompilation neden koştu sorguları olabilir içerir bunlardan .some

  • Sorgu tarafından başvurulan bir tablo veya görünümde yapılan değişiklikler (ALTER TABLE ve ALTER VIEW).

  • Tek bir prosedürde yapılan ve bu prosedürle ilgili tüm planları önbellekten kaldıracak değişiklikler (ALTER PROCEDURE).

  • Yürütme planı tarafından kullanılan dizinlerde yapılan değişiklikler

  • Yürütme planı tarafından kullanılan, UPDATE STATISTICS gibi bir ifadeden açıkça oluşturulan veya otomatik olarak oluşturulan istatistiklerle ilgili güncellemeler.

  • Yürütme planı tarafından kullanılan bir dizini bırakmak.

Plan önbelleğe alma hakkında daha fazla bilgi için bu tanıtım belgesini de görebilirsiniz

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


Performans sayaçlarımı ekledim, bu değerleri yorumlamama yardımcı olabilir misiniz?
Marcin Topolewski

bellekle ilgili ayrıntılı sayaçları burada bulabilirsiniz: blogs.msdn.microsoft.com/teekamg/2007/11/06/…
TheGameiswar

@TheGameiswar "yeniden derlemeye neden olan sorgular çalıştırmış olabilirsiniz ... dizin değişiklikleri, istatistik güncellemeleri" gibi. Her gece parçalanma + güncelleme istatistiklerine göre dizin yeniden düzenleme / yeniden oluşturma yapıyorsam, bu, planlarımın her gün (veya neredeyse tümü) her gün yeniden oluşturulacağı anlamına mı geliyor? Bu bir problem mi?
Danielle Paquette-Harvey

2

@TheGameiswar'ın söylediklerini eklemek için, önbellekten edinilmeyen planların ayrıntılarını görmek için bu sorguyu da çalıştırabilirsiniz.

;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;
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.