Sürekli tarama 0 saniye veya 2-3 dakika sürer

Aşağıdaki gibi, herhangi bir satır döndürmemesi garanti edilen bir sorgu, sunucularımızdan birinde 0 ila 160 saniye arasında bir şey alır:

select col1, col2, col3
from tab1
where 0 = 1

İki hafta önce, bu 48 saatlik bir aralıkta altı kez oldu. Geçen hafta aynı sorgu ~ 0 saniye sürdü. Uygulamamızın SQL'lerinin günlükleri var, ancak henüz şüpheli bulamadım. Ayrıca, bir üst 0 / nerede 0 = 1 tipi sorgu veri sayfaları vurmak asla düşündüm, bu yüzden satır / sayfa / tablo düzeyinde veri kilitlerine dayanıklı olmalıdır? Şemaya (bilinen) SQL'ler tarafından dokunulmaz.

Sorun tutarlı olmadığı ve sunucu çok ağır yük altında olduğu için SQL profiler eklemeden önce neler olduğunu teoriyi anlamak istiyorum. Bu gecikmeler sırasında diğer sorgular sorunsuz çalışır. Uygulamada bilinen bir sorun, dinamik olarak oluşturulmuş çok sayıda SQL sorgusu - 48 saatlik bir süre boyunca toplam 850 bin (günlük) sorgu yaklaşık 200k benzersiz sorgu, bu gibi sorunlara neden olabilir mi?

Sunucu SQL Server 2005 standart sürümü, 96 GB RAM, SAN diskleri ve 4 CPU / 16 çekirdek çalıştırıyor. Veritabanı dosyaları ve dosya grupları iyi bir şekilde optimize edilmiştir ve sorun olmamalıdır (ancak bunu ayrıca inceliyoruz).

Nereye bakılacağı herhangi bir işaretçi büyük takdir.

Düzenleme: Mükemmel! Yürütme planını eklemek için sorguyu yeniden oynattı ve 1 dakika 35 saniye sürdü. Sorgu süresini gösteren yürütme planı ve ekran görüntüsü:

Düzenleme 2: ikinci bir çalıştırma için istatistik zaman ayrıntıları. Şu anda sürekli yavaş görünüyor, bu yüzden profiler ve perfmon ekleyeceğiz:

SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 97402 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

Bir cümleyle bile ... WHERE 0 = 1, yine de IStabloda bir niyet ( ) kilidi için bir gereksinim olacağı anlaşılıyor . Bunu kanıtlayalım:

Bir test tablosu oluşturarak başlayacağım:

use TestDb1;
go

create table dbo.MyTestTable1
(
    Id int identity(1, 1) not null,
    SomeInt int not null
);
go

insert into dbo.MyTestTable1 (SomeInt)
values (10), (20), (30), (40), (50);
go

Şimdi benim test tablo var, bir oturumda (sorgu penceresi) ben özel ( X) kilit koymak için aşağıdaki yürütmek olacak dbo.MyTestTable1:

use TestDb1;
go

begin tran;
    select
        Id, SomeInt
    from dbo.MyTestTable1 with (tablockx);
--commit tran;

Özel kilidi sys.dm_tran_locksDMV'ye bakarak doğrulayabilirim . Sonra başka bir oturumda (yeni sorgu penceresi) tam olarak sorgunuz ne yapar:

use TestDb1;
go

select
    Id, SomeInt
from dbo.MyTestTable1
where 0 = 1;

İlk bakışta bunun tamamlanmadığını görüyorum. Baktığımda, sys.dm_exec_requeststam olarak neden böyle olduğunu görüyorum:

select
    r.session_id,
    r.status,
    r.wait_type,
    r.wait_time,
    r.wait_resource,
    r.blocking_session_id
from sys.dm_exec_requests r
cross apply sys.dm_exec_sql_text(r.sql_handle) st
where st.text like '%where 0 = 1%'
and r.session_id <> @@spid;

Burada benim ... WHERE 0 = 1sorgu ISbu nesne (bu object_id çevirir dbo.MyTestTable1) için bir kilit bekliyor olduğunu görebilirsiniz .

Hiçbir zaman eşzamanlılığın sizin probleminiz olduğunu söylemiyorum , ama onun sesleriyle belirtileri sergiliyorsunuz. Yukarıdaki örnek, WHEREasla veri döndürmeyecek bir maddeyle bile kilitleme ve engellemekten muaf olmadığınızı kanıtlamaktır .

Yapabileceğimiz tek şey tahmin etmek, bu yüzden "uzun zaman aldığında" yapmanız gereken şey, bu talebin ne kadar uzun sürdüğünü tam olarak görmek. Bir şey bekliyorsa, o zaman ne beklediğine bakın.

Sorgularınızı ne kadar dikenli ve iplik gerektirdiğine bağlı olarak, sisteminiz bu sorguyu kuyruğa alıyor olabilir. Kurulumunuz için varsayılan çalışan sayısı (yani, eşzamanlı SQL sunucu iş parçacığı sayısı) yaklaşık 700 olmalıdır.

Bunun bir sorun olup olmadığını görmek için sys.dm_os_schedulers ve sys.dm_os_waiting_tasks'e bakın.