Microsoft hesabıyla oturum açın
Oturum açın veya hesap oluşturun.
Merhaba,
Farklı bir hesap seçin.
Birden çok hesabınız var
Oturum açmak istediğiniz hesabı seçin.

Özet

Bu makalede, "bağlantı" terimi, tek bir oturum açma oturumunda veritabanı için başvurur. Her bağlantı, oturum kimliği (SPID) olarak görünür. Genel anlamıyla ayrı bir işlem bağlamında olmasa da her biri bu SPID genellikle bir işlem olarak adlandırılır. Bunun yerine, her SPID belirli bir istemciden gelen tek bir bağlantı isteklerine hizmet vermek gerekli veri yapıları ve sunucu kaynaklarını oluşur. Tek bir istemci uygulamasının bir veya daha fazla bağlantıları olabilir. SQL Server'ın açısından bakıldığında, tek bir istemci bilgisayar üzerinde bir istemci uygulamasından gelen birden çok bağlantı ve birden çok bağlantı birden çok istemci uygulamaları veya birden çok istemci bilgisayarlar arasında fark yoktur. Bir bağlantı olup bunlar aynı uygulama veya iki farklı istemci bilgisayarlarda farklı uygulamaları yayılan ne olursa olsun başka bir bağlantıyı engelleyebilir.

Daha fazla bilgi

Engelleme, kilit tabanlı eşzamanlama ile tüm ilişkisel veritabanı yönetim sistemi (RDBMS) kaçınılmaz bir özelliğidir. SQL Server'da engelleme ikinci bir SPID'nin aynı kaynağı çakışan bir kilit türü almaya çalışır ve bir SPID belirli bir kaynak Kilit tutan oluşur. Tipik olarak, kendisi için ilk SPID'nin kaynağı kilitleme zaman dilimi çok kısadır. Kilidi serbest bıraktığında, ikinci bağlantının kendi kaynak Kilitle ve işleme devam etmek ücretsizdir. Bu normal davranıştır ve sistem performansı üzerinde fark edilebilir bir etkisi yok ile bir gün boyunca birçok kez ortaya çıkabilir.

Bir sorgunun süresi ve hareket bağlamı belirlemek ne kadar onun kilitleri tutulur ve böylece diğer sorgular üzerindeki etkilerini. Sorgu bir hareket içinde yürütülür değil (ve kilit ipuçları kullanılan varsa), SELECT deyimlerinin kilitleri yalnızca bir kaynak düzenlenecek gerçekten okunduğu zaman, sorgu süresince değil. INSERT, UPDATE ve DELETE deyimlerini hem veri tutarlılığı ve gerekirse geri alınması için sorguyu sorgu süresince kilitleri tutulur.

Bir hareket içinde yürütülen sorgular için kilitleri tür sorgu, hareket yalıtım düzeyine göre belirlenir ve olup olmadığı kilitlemek tutulduğu süre ipuçları sorguda kullanılır. Bir açıklama kilitleme, kilit ipuçları ve hareket izolasyon düzeyleri, SQL Server Books Online'da aşağıdaki konulara bakın:

  • Veritabanı Altyapısı'kilitleme

  • Özelleştirme kilitleme ve satır sürüm oluşturma

  • Kilit modları

  • Kilit Uyumluluğu

  • Satır Veritabanı Altyapısı'ndaki sürüm tabanlı yalıtım düzeyleri

  • Hareketleri (veritabanı altyapısı) denetleme

Kilitleme ve engelleme noktasına artış sistem performansı üzerinde detrimental bir etkisi olduğu genellikle aşağıdaki nedenlerden dolayı biridir:

  • SPID bırakmadan önce uzun bir süre için bir kaynak kümesini kilitli tutar. Bu tür engelleme zaman içinde kendi kendine giderilir, ancak performans düşüşüne neden olabilir.

  • Bir SPID bir kaynak kümesini kilitli tutar ve serbest bırakmaz. Bu tür engelleme kendi kendine çözümlenmez ve etkilenen kaynaklara erişimi süresiz olarak önler.

SPID'nin kilitleri serbest olarak Yukarıdaki ilk senaryoda, engelleme sorunu kendisi zamanla giderir. Ancak, durum değişkenliği zaman içinde farklı kaynaklar üzerinde bağlantı noktalarının engellenmesi, hareketli hedef oluşturma farklı SPID'ler neden olabilir. Bu nedenle, bu gibi durumlarda SQL Server Enterprise Manager ya da tek tek SQL sorguları kullanarak sorun giderme zor olabilir. İkinci durum daha kolay tanımak tutarlı bir duruma neden olur.

Engelleme bilgilerini toplama

Engelleme sorunlarını giderme konusundaki güçlüklere yönelik olarak, veritabanı yöneticisi, kilitleme ve SQL Server'da engelleme durumunu sürekli olarak izleyen SQL komut dosyalarını kullanabilirsiniz. Bu komut dosyaları, zamanla, sorunu genel bir bakış için önde gelen belirli örneklerin anlık sağlayabilir. SQL komut dosyalarıyla engelleme izlemek nasıl bir açıklaması için Microsoft Bilgi Bankası'ndaki aşağıdaki makalelere bakın:

271509 SQL Server 2000 ve SQL Server 2005'te engelleme izlemek nasıl

Bu makaledeki komut dosyalarını aşağıdaki görevleri gerçekleştirmeniz gerekmektedir. Mümkünse, SQL Server Management Studio'dan bu bilgileri edinme yöntemi verilir.

  1. Engelleme zincirinin başındaki SPID (oturum kimliği) ve SQL deyimi tanımlar.
    Yukarıda sözü edilen Bilgi Bankası makalesinde komut dosyalarını kullanmanın yanı sıra, engelleme zincirinin başındaki SQL Server Management Studio üzerinden sağlanan özellikleri kullanarak tanımlayabilirsiniz. Bunu yapmak için aşağıdaki yöntemlerden birini kullanın:

    • Sunucu nesnesini sağ tıklatın, Raporlar' ı genişletin, Standart raporlar' ı genişletin ve Etkinlik – tüm engelleme işlemleri'nitıklatın. Bu rapor, engelleme zincirinin kafası hareketlerini gösterir. Hareket genişletirseniz, rapor kafa hareket tarafından engellenen hareketleri gösterir. Bu rapor "engelleme SQL Statement" ve "Engellenen SQL deyimini." de Göster

    • DBCC INPUTBUFFER(<spid>), bir SPID tarafından gönderilen son ifade bulmak için kullanın.

  2. İç içe geçmiş hareket düzeyini ve engelleyen SPID'nin işlem durumunu bulun.
    SPID'nin iç içe geçmiş hareket düzeyini @@TRANCOUNT genel değişkeninde bulunur. Ancak, bu gelen SPID dışından sysprocesses tablosu aşağıdaki gibi sorgulayarak belirlenebilir:

    SELECT open_tran FROM master.sys.sysprocesses WHERE SPID=<blocking SPID number>
    go

    Döndürülen değer SPID'nin @@TRANCOUNT değerdir. Bu sırayla neden kilitli tutan açıklayan engelleyen SPID'nin iç içe geçmiş hareket düzeyini gösterir. Örneğin, değer sıfırdan büyükse SPID ortasında (Bu durumda, onu da, hareket yalıtım düzeyine bağlı olarak edindiği bazı kilitleri tutması beklenir) bir hareket olur.

    DBCC OPENTRAN kullanarak uzun süredir açık hareket veritabanında olup olmadığını görmek için kontrol edebilirsiniz
    database_name.

SQL Server Profiler izleme bilgilerini toplama

Yukarıdaki bilgilere ek olarak, SQL Server'da engelleme sorunu iyice araştırmak için sunucu üzerindeki etkinliklerin Profiler izleme yakalamak gereklidir. Bir SPID bir hareketin içinde birden çok ifadeleri yürütür, yalnızca son statementthat gönderildiği gösterir rapor, giriş arabelleği veya etkinlik İzleyicisi çıktı. Ancak, kilitlerin hala tutulmasının nedeni önceki komutlardan biri olabilir. Profiler izlemesi geçerli hareket içinde SPID tarafından yürütülen komutların tümünü görmenize olanak sağlar. Aşağıdaki adımlar izleme yakalamak için SQL Server Profiler'ı ayarlamak yardımcı olur.

  1. SQL Server Profiler'ı açın.

  2. Dosya menüsünde Yeni' nin üzerine ve İzle' yi tıklatın.

  3. Genel sekmesinde, izleme adını ve veri yakalamak için bir dosya adı belirtin.

    Önemli İzleme dosyasının hızlı yerel veya paylaşılan diske yazılması gerekir. Yavaş bir disk veya ağ sürücüsüne izleme kaçının. Ayrıca veri seçili izleme sunucusu işler emin olun.

  4. Olayları seçimi sekmesinde, tüm olayları göstermek ve tüm sütunları göster onay kutularını seçmek için tıklatın.

  5. Olayları seçimi sekmesinde, Tablo 1'de listelenen olay türlerini izlemenize ekleyin.

    Ayrıca, daha fazla bilgi için Tablo 2'de listelenen ek olay türlerini içerebilir. Yüksek hacimli üretim ortamında çalıştırıyorsanız, çoğu engelleme sorunlarını çözmek için genellikle yeterli olduğu gibi yalnızca olayları Tablo 1'de kullanmak isteyebilirsiniz. Tablo 2'de ek olaylar da dahil olmak üzere hemen bir sorunun kaynağını belirlemek kolaylaştırabilir (veya bu olaylar çoklu deyimli yordam culprit deyiminde tanımlamak gerekli olabilir). Ancak, olaylar Tablo 2'de dahil olmak üzere ayrıca sistem üzerindeki yükü ekleyin ve İzleme çıkışı boyutunu artırır.

Tablo 1: Olay türleri

Başlık

Olay

Hatalar ve uyarılar

Özel durum

Hatalar ve uyarılar

Dikkat

Güvenlik denetimi

Denetim oturum açma

Güvenlik denetimi

Denetim kapatma

Oturumlar

Varolan bağlantı

Saklı yordamlar

RPC:Starting

TSQL

SQL:BatchStarting


Tablo 2: Ek olay türleri

Başlık

Olay

Hareketleri

Misc.

Hareketleri

SQLTransaction

Saklı yordamlar

RPC:Completed

TSQL

SQL:BatchCompleted

Saklı yordamlar

SP:StmtStarting

Saklı yordamlar

SP:StmtCompleted


Lütfen SQL Server Profiler'ı kullanma hakkında daha fazla bilgi için SQL Server Books Online'dan bakın.

Tanımlama ve çözme sık karşılaşılan engelleme senaryoları

Yukarıdaki bilgileri inceleyerek, birçok engelleme sorununun nedenini belirleyebilirsiniz. Bu makalenin geri kalanında tanımlamak ve bazı sık karşılaşılan engelleme senaryolarını çözümlemek için bu bilgileri kullanma konusunda bir tartışma bulunmaktadır. Bu tartışma yukarıda açıklanan olaylarla engelleyen SPID'ler hakkında bilgi yakalamak ve Profiler izlemesi yaptığınız için (daha önce başvurulan) makalesinde 271509 engelleme komut dosyalarını kullandığınız varsayılmaktadır.

Engelleme komut dosyası çıkışını görüntüleme

Kafaları engelleme zincirinin başını belirlemek için sys.sysprocesses çıkışını inceleyin

Engelleme komut dosyaları için hızlı modu belirtmediyseniz, komut dosyası çıktısında diğer SPID'leri engelleyen SPID'leri listeleyen "Engelleme zincirlerinin başındaki SPID'ler" başlıklı bir bölüm olur.

SPIDs at the head of blocking chains

Hızlı seçeneği belirttiyseniz, sys.sysprocesses çıktı ve engellenen sütununda bildirilen SPID hiyerarşisi aşağıdaki bakarak engelleme başlangıçlarını belirleyebilirsiniz.

Engelleme zincirinin başındaki SPID'ler hakkında bilgi için sys.sysprocesses çıkışını inceleyin.

Aşağıdaki sys.sysprocesses alanlarının değerlendirilmesi önemlidir:

Durum

Bu sütun, belirli bir SPID durumunu gösterir. Genellikle, uyku durumu SPID'nin yürütmeyi tamamladığını ve uygulamanın başka bir sorgu veya toplu işlem göndermesini beklediğini gösterir. Runnable, çalışanveya sos_scheduler_yield durumu SPID'nin şu anda bir sorguyu işlediğini gösterir. Aşağıdaki tabloda çeşitli durum değerlerinin kısa açıklamaları verilmiştir.

Durum

Anlamı

Arka plan

SPID bir arka plan görevi, karşılıklı kilitlenme algılaması gibi çalışıyor.

Uyku

SPID şu anda yürütülmüyor. Bu genellikle SPID'nin uygulamadan komut bekliyor gösterir.

Çalışan

SPID şu anda bir zamanlayıcı üzerinde çalışıyor.

Runnable

SPID bir Zamanlayıcı ve Zamanlayıcı saati almak için bekliyor runnable kuyrukta bulunuyor.

Sos_scheduler_yield

SPID çalışıyordu, ancak gönüllü olarak kendi zaman dilimi üzerinde başka bir SPID Zamanlayıcı saati almaya izin vermek için Zamanlayıcı sağladığını.

Askıya alındı

SPID kilit veya bir tutma gibi bir olayı bekliyor.

Geri alma

SPID bir hareketin içinde rollback olur.

SPID

SPID'nin serbest bırakılmakta olan bir kaynak için beklediğini gösterir. Söz konusu kaynak waitresource alanı belirtmeniz gerekir.


Open_tran

Bu alan SPID'nin iç içe geçmiş hareket düzeyini gösterir. Bu değer 0'dan büyük ise, SPID açık bir hareket içinde olduğu ve hareketin içindeki herhangi bir deyim tarafından alınan kilitleri tutabilir.

Lastwaittype, waittype ve waittime

Ayrılmış iç ikili sütundur waittype alanı dize halinde temsilini lastwaittype alanıdır. Waittype 0x0000 ise, SPID şu anda herhangi bir şey için bekliyor değil ve SPID vardı son waittype lastwaittype değeri gösterir. Waittype sıfır değilse, SPID geçerli waittype lastwaittype değeri gösterir.

Farklı lastwaittype ve waittype değerlerinin kısa açıklaması için Microsoft Bilgi Bankası'ndaki aşağıdaki makaleye bakın:

822101 waittype ve lastwaittype sütunları master.dbo.sysprocesses tablosunda SQL Server 2000 ve SQL Server 2005'in açıklaması

Sys.dm_os_wait_statshakkında daha fazla bilgi için SQL Server Books Online'dan bakın.

Waittime değeri SPID'nin ilerleme olmadığını belirlemek için kullanılabilir. Karşı sys.sysprocesses tablo sorgu waittime sütununda sys.sysprocesses, önceki bir sorgudan waittime değerinden daha küçük olan bir değer geri döndüğünde, bu önceki kilidin alındığını gösterir ve serbest ve şimdi yeni bir kilidin bekleniyor (sıfırdan farklı waittime). Bu sys.sysprocesses çıktı arasındaki değerleri karşılaştırarak doğrulanabilir.

Waitresource

Bu alan bir SPID'nin beklediği kaynağı gösterir. Aşağıdaki tabloda, yaygın waitresource biçimleri ve anlamları listelenmiştir:

Kaynak

Biçim

Örnek

Tablo

DatabaseID:ObjectID:IndexID

SEKMESİ: 5:261575970:1
Bu durumda, veritabanı kimliği 5 pubs örnek veritabanı olan ve titles tablosunu nesne kimliği 261575970 olan ve 1 kümelenmiş dizin.

Sayfa

DatabaseID:FileID:PageID

SAYFA: 5:1:104
Bu durumda, pubsveritabanı kimliği 5 ise, birincil veri dosyasının dosya kimliği 1 olan ve sayfa 104 Başlıklar tablosuna ait bir sayfadır.

Sayfanın ait olduğu nesne kimliği belirlemek için DBCC PAGE (DBID, dosyasını Win32_FileSpecification ', pageid, output_option) komutunu kullanın ve m_objId bakın. Örneğin:

DBCC TRACEON ( 3604 )
DBCC PAGE ( 5 , 1 , 104 , 3 )

Anahtar

DatabaseID:Hobt_id (dizin anahtarı için karma değeri)

Anahtar: 5:72057594044284928 (3300a4f361aa)

Bu durumda, veritabanı kimliği 5 Pubs, Hobt_ID 72057594044284928 olmayan kümelenmiş index_id 2 nesne kimliği 261575970 (Başlıklar tablosu) karşılık gelir. Sys.partitions Katalog görünümü, belirli dizin kimliği ve nesne kimliği için hobt_id ilişkilendirmek için kullanın. Dizin anahtar karma bir belirli dizin anahtarı değerine karmadan yoktur.

Satır

DatabaseID:FileID:PageID:Slot(row)

RID: 5:1:104:3

Bu durumda, pubs veritabanı kimliği 5 olan birincil veri dosyasının dosya kimliği 1 olan sayfa 104 başlıklar tablosuna ait bir sayfadır ve yuva 3 satırın sayfadaki konumunu gösterir.

Derleme

Pubs [[derleme]]

SEKMESİ: 5: Bu değil 834102012, [[derleme]] saklı bir yordamın tablo kilidi, ancak derleme yerine kilitleyin. Veritabanı kimliği 5 pubs, nesne kimliği 834102012 saklı yordamı usp_myprocedure. Bilgi Bankası makalesi 263889 derleme kilitleri neden olduğu engelleme hakkında daha fazla bilgi için bkz.

Diğer sütunlar

Kalan sütunları sys.sysprocesses sorunun köküne anlayış sağlar. Kendi kullanışlılığı sorun koşullara göre değişir. Örneğin, yalnızca belirli istemcilerde (ana bilgisayar adı) sorun ortaya çıkarsa belirli (bir SPID tarafından gönderilen son toplu (last_batch) net_library), ağ kitaplıklarının vb. belirleyebilirsiniz.

DBCC INPUTBUFFER çıkışını inceleyin.

Engelleme zincirinin başındaki veya sıfırdan waittype ile başlangıçta herhangi bir SPID için SPID için geçerli sorguyu belirlemek için DBCC INPUTBUFFER engelleme komut dosyası yürütülür.

Çoğu durumda, bu tutulması için diğer kullanıcıları engelleyen kilitleri neden olan sorgudur. SPID bir hareketin içinde ise, ancak, kilitler, geçerli olanı gibi önceden yürütülmüş bir sorgu tarafından alınmış olabilir. Bu nedenle, yalnızca inputbuffer değerini SPID için Profiler çıkışını da görüntülemelisiniz.

Not: Engelleme komut dosyası birden çok adımdan oluştuğundan, bir SPID ilk bölümde engelleme zincirinin başındaki görünebilir, ancak DBCC INPUTBUFFER sorgusu yürütüldüğünde göre artık engelleme ve INPUTBUFFER'ın mümkündür. Bu engelleme kendisi bu SPID'nin periyotunda ve bir sorun olmayabilir veya olabilir gösterir. Bu noktada, engelleme komut dosyasının hızlı sürümünü (olmasına rağmen hala garanti) temizlenmeden önce inputbuffer değerini yakalamak emin olmak denemek için kullanabilir, veya SPID'nin yürüttüğü sorguları belirlemek için bu zaman dilimi profil oluşturucu veriyi görüntülemek.

Profiler verilerini görüntüleme

Profiler verilerinin etkin bir şekilde görüntülenmesi, engelleme sorunlarını giderme açısından çok önemlidir. Her şeye bakmak gerekmez yakalanan bilmeniz gereken en önemli şey; Seçici olun. Profiler yakalanan verileri etkin bir şekilde yardımcı olacak olanaklar görüntülemek sağlar. Özellikler iletişim kutusunda ( Dosya menüsünde Özellikler' i tıklatın), Profiler veri sütunlarını veya olayları kaldırarak, veri sütunlarına göre gruplandırarak (sıralayarak) ve filtre uygulayarak görüntülenen verileri sınırlamanıza olanak tanır. Tüm izleme veya yalnızca belirli değerleri için özel bir sütunda arayabilirsiniz ( Düzen menüsünden Bul' u tıklatın). Profiler verilerini bir SQL Server tablosuna kaydedebilirsiniz ( Dosya menüsünde Farklı Kaydet'ın üzerine ve Tablo' yu tıklatın) ve bu tabloyu kullanarak SQL sorguları çalıştırın.

Dikkatli olun, yalnızca önceden kaydedilmiş izleme dosyasına filtre gerçekleştirmek. Bu adımları etkin izleme üzerinde gerçekleştirirseniz, izleme başlatıldıktan sonra yakalanan verileri kaybetme riski doğar. İlk tablo veya etkin bir izleme bir dosyaya kaydedin ( Dosya menüsünde farklı Kaydet' i tıklatın) ve sonra yeniden açın ( Dosya menüsünde, Aç' ı tıklatın) devam etmeden önce. Kaydedilmiş bir izleme dosyasında üzerinde çalışırken, filtreleme kalıcı filtre uygulanan verileri kaldırmaz, tüm verileri yalnızca görüntülemez. Ekleyebilir ve olaylar ve veri sütunları odaklanmasına yardımcı olmak için aramalarınızı kaldırabilirsiniz.

Dikkat edilmesi gerekenler:

  • Hangi komutları, geçerli hareket içinde engelleme zincirinin başındaki SPID'nin var mı?
    Engelleme zincirinin SPID'nin izleme verilerini filtreleyin ( Dosya menüsünde, Özellikler' i tıklatın; ardından filtreler sekmesinde SPID değerini belirtin). Sonra onu diğer SPID'leri engellemeden önce yürüttüğü komutları inceleyebilirsiniz. Hareket olaylarını eklerseniz, hareketin başlatıldığı zaman onlar kolayca tanımlayabilirsiniz. Aksi takdirde, metin sütununun başlangıç için arayabilirsiniz SAVE, COMMIT veya ROLLBACK TRANSACTION işlemlerini. Tüm hareket olaylarını yakaladığınızdan emin olmak için sysprocesses tablosu open_tran değerini kullanın. Yürütülen komutların ve hareket bağlamının bilinmesi SPID'nin kilitleri neden tuttuğunu belirlemenize izin verir.

    Olaylar ve veri sütunlarını kaldırabileceğinizi unutmayın. Başlatılan her iki bakan yerine ve tamamlanan olayları, bunlardan birini seçin. Engelleyen SPID'ler saklı yordamlar değilse Kaldır
    SP: Başlangıç veya SP: Tamamlanan olayları; yordam çağrısı SQLBatch ve RPC olayları gösterir. Yalnızca ilgili ayrıntı düzeyini görmeniz gerektiğinde SP olaylarını görüntüleyin.

  • Engelleme zincirlerinin kafası SPID'ler için sorgu süresi nedir?
    Yukarıdaki tamamlanan olayları eklerseniz, Duration sütunu sorgu yürütme süresini gösterir. Bu engellemeye neden uzun süre çalışan sorguları belirlemenize yardımcı olabilir. Sorgunun yavaş çalışma nedenini belirlemek için CPU, Okumave Yazar sütunların yanı sıra Execution Plan olay görüntüleyin.

Sık karşılaşılan engelleme senaryolarını kategorilere ayrılması

Aşağıdaki tabloda, yaygın belirtiler bunların olası nedenleri için eşleştirir. Senaryo sütununda belirtilen rakama karşılık gelen sayıya bu makalenin "Sık karşılaşılan engelleme senaryoları ve çözümleri" bölümüne. Waittype Open_Tranve Durum sütunlarının sysprocesses bilgilere bakın. Çözümler? sütun engelleme, kendi çözümler olup olmadığını gösterir.

Senaryo

Waittype

Open_Tran

Durum

Çözümler?

Diğer Belirtiler

1

Sıfır olmayan

> = 0

runnable

Evet, sorgu tamamlandığında.

Sütunları waittype, CPU ve/veya bellek kullanımı zamanla artar. Sorgu süresi tamamlandığında yüksek olacaktır.

2

0x0000

> 0

Uyku

Hayır, ancak SPID sonlandırılabilir.

Profiler izlemesinde bu SPID için sorgu zaman aşımı gösteren bir dikkat sinyali görülebilir veya iptali oluştuğunu.

3

0x0000

> = 0

runnable

No İstemci tüm satırları getirir veya bağlantıyı kapatır kadar çözümlenmez. SPID sonlandırılabilir, ancak bu işlem 30 saniye kadar sürebilir.

Yoksa open_tran = 0 ve SPID, kilitleri tutar, hareket yalıtım düzeyi (READ COMMMITTED) varsayılan olmakla birlikte, bu olası bir nedendir.

1

Değişir

> = 0

runnable

No İstemci sorgu iptal eder veya bağlantılarını kapatn kadar çözümlenmez. SPID'ler sonlandırılabilir, ancak 30 saniye kadar sürebilir.

Engelleme zincirinin başındaki SPID için sysprocesses ana bilgisayar adı sütununda onu engelleyen SPID'nin biriyle aynı olacaktır.

5

0x0000

> 0

geri alma

Evet.

Profiler izlemesinde bu SPID için sorgu zaman aşımı gösteren bir dikkat sinyali görülebilir veya iptali oluştuğunu veya yalnızca rollback deyimi yayınlandığını.

6

0x0000

> 0

Uyku

Sonuçta. Windows NT oturum etkin olmadığını belirlediğinde, SQL Server bağlantısı kesilir.

Sysprocesses last_batch değeri geçerli saatten daha öncedir.

Sık karşılaşılan engelleme senaryoları ve çözümleri

Aşağıda listelenen senaryolar yukarıdaki tabloda listelenen özelliklere sahiptir. Bu bölümde, uygun olduğunda ek ayrıntıların yanı sıra çözüm yolları da sağlar.

  1. Neden olduğu engelleme normal çalışan sorgu yürütme zaman ile

    Çözünürlük:
    Bu tür engelleme sorununun çözümü, sorguyu eniyileştirme yollarını aramaktır. Aslında, bu sınıftaki bir engelleme sorunu sadece bir performans sorunu olabilir ve bu şekilde izlenmesi gerekir. Belirli bir yavaş çalışan sorguda sorun giderme hakkında daha fazla bilgi için aşağıdaki Microsoft Bilgi Bankası makalesine bakın:

    243589 nasıl SQL Server 7.0 veya sonraki sürümlerde yavaş çalışan sorgularda sorun giderme

    Genel Uygulama performansı sorunlarını giderme için aşağıdaki Bilgi Bankası makalesine bakın:

    224587 nasıl yapılır: SQL Server ile uygulama performansı sorunlarını giderme

    Daha fazla bilgi için aşağıdaki MSDN Web sitesinde bulunan Performans izleme ve ayarlama nasıl yapılır konuları SQL Server 2008 Books Online'da konusuna bakın:

    http://msdn.microsoft.com/en-us/library/ms187830.aspxDiğer kullanıcıları engelleyen ve hale getirilemeyen bir uzun süre çalışan sorgunun varsa OLTP ortamından taşımak için bir karar destek sistemi düşünün.

  2. İşlem iç içe geçme düzeyi izini kaybetmiş bir Uyuyan SPID'nin neden olduğu engelleme

    Bu tür engelleme genellikle Uyuyan veya komut bekleyen, ancak, işlem iç içe geçme düzeyini (@@TRANCOUNT, open_tran sysprocessesdan) sıfırdan büyük olan bir SPID tarafından belirlenebilir. Bu uygulama sorgu zaman aşımıyla karşılaşırsa ya da gerekli ROLLBACK ve/veya COMMIT deyimi sayısını yayınlamadan iptal sorunlar oluşabilir. Bir SPID bir sorgu zaman aşımı veya iptal aldığında görüntülenecektir geçerli sorguyu ve toplu işlemi sonlandırmak ancak otomatik olarak geri veya hareketi tamamlamak. SQL Server tüm bir hareket iptal edilmekte tek bir sorgunun nedeniyle geri alınması gerektiğine karar veremeyeceği Bu, sorumlu bir uygulamadır. Sorgu zaman aşımı veya iptali Profiler izlemesinde SPID için ATTENTION sinyal olayı görünür.

    Bunu göstermek için Sorgu Çözümleyicisi'nden aşağıdaki basit sorguyu yayınlayın:

    BEGIN TRAN 
    SELECT * FROM SYSOBJECTS S1, SYSOBJECTS S2

    -- Issue this after canceling query
    SELECT @@TRANCOUNT
    ROLLBACK TRAN

    Sorgu yürütülürken, kırmızı'ı İptal düğmesi. Sorgu iptal edildikten sonra SELECT @@TRANCOUNT iç içe geçmiş hareket düzeyi bir olduğunu gösterir. Bu bir DELETE veya UPDATE sorgusu olsaydı veya Seç, tüm alınan kilitlerin hala Tutuluyor olurdu SELECT deyiminde HOLDLOCK kullanılsaydı. Başka bir sorgu alıp tuttuysa önceki işlem kilitleri tutulur, yukarıdaki SELECT iptal edildiğinde bile ile Yukarıdaki sorgu, bunlar hala Tutuluyor olurdu.

    Çözünürlük:

    • Uygulamaları iç içe geçmiş hareket düzeylerini düzgün yönetmesi gerekir ya da bu şekilde sorgu iptali ardından engelleme sorununa neden olabilir. Bu yollardan biriyle gerçekleştirilebilir:

      1. İstemci uygulamasının hata işleyicisinde IF gönderme @@TRANCOUNT > 0 ROLLBACK TRAN istemci uygulaması bir hareketi düşünen değil olsa bile aşağıdaki herhangi bir hata olduğu açık. Toplu işlem sırasında çağrılan bir saklı yordam istemci uygulamanın bilginiz dışında bir hareket başlatmış olabileceğinden, bu gereklidir. Sorgu iptal etme gibi belirli koşullar geçerli deyimin ilerisinde, böylece bile yordam hareketi iptal mantık kontrol edin, eğer @@ERROR <> 0 varsa, bu geri alma kodunun içinde gibi yürütülmez yürütme yordamı önlemek unutmayın Servis talepleri.

      2. Bağlantı için veya hareket başlatan ve bir hatadan sonra temizleme yapmayan saklı yordamlarda SET XACT_ABORT ON deyimini kullanın. Çalışma zamanı hatası oluştuğunda, bu ayar açık hareketleri iptal ve denetimi istemciye döndürür. Hataya neden olan deyimden sonraki T-SQL deyimlerinin yürütülmeyeceğine dikkat edin.

      3. Az sayıda bağlantıyı bırakmadan önce sorguları gibi Web tabanlı bir uygulama havuzuna yeniden çalıştırır ve bağlantı açılır bir uygulamada bağlantı havuzu kullanılıyorsa, geçici bağlantı havuzu devre dışı çözmenize yardımcı olabilir istemci uygulaması hataları düzgün işleyecek şekilde değiştirilene kadar sorun. Bağlantı havuzu oluşturmayı devre dışı bırakarak, bağlantı serbest kaynaklanan sunucunun açık hareketleri geri alma SQL Server bağlantısının fiziksel bir logout neden olur.

      4. Bağlantı havuza alma etkinleştirildiğinde ve hedef sunucu SQL Server 2000 ise, istemci bilgisayarın MDAC 2.6 veya sonraki bir sürüme yükseltilmesi faydalı olabilir. "Yeniden kullanılmadan önce bağlantının sıfırlanması" MDAC Bileşenleri bu sürüm kodu ODBC sürücüsünü ve OLE DB sağlayıcısı ekler. Bu sp_reset_connection çağrısı (istemci uygulaması tarafından başlatılan DTC hareketleri etkilenmez) sunucu tarafından başlatılan hareketleri iptal eder, varsayılan veritabanı seçeneklerini ayarlama ve benzeri sıfırlar. Böylece kullanıcı bir hareket açmak ve sonra bağlantı için bağlantı havuzu bırakın, ancak hangi sırada birkaç saniye için yeniden olası bağlantı havuzundan yeniden alınana kadar bağlantı sıfırlanmaz unutmayın Hareket açık kalır. Bağlantı yeniden kullanılmazsa, bağlantı zaman aşımına uğradı ve bağlantı havuzundan kaldırıldığında hareket iptal edilir. Böylece, hareketleri kendi hata işleyicilerinde iptal veya bu olası gecikmeyi önlemek için SET XACT_ABORT ON deyimini kullanmak istemci uygulaması için en iyi olur.

    • Aslında, bu sınıftaki bir engelleme sorunu ayrıca bir performans sorunu olabilir ve bu şekilde izlenmesi gerekir. Sorgu yürütme süresi azaltılabilirse sorgu zaman aşımı veya iptali oluşmaz. Uygulama zaman aşımı veya iptal senaryolarının mümkün önemlidir çıktıkları, ancak sorgu performansını incelerken gelen de yarar sağlayabilir.

  3. Neden olduğu, ilgili istemci uygulaması için tamamlama tüm sonuç satırlarını getirme bir SPID tarafından engelleme

    Sunucuya bir sorgu gönderdikten sonra tüm uygulamaları hemen tüm sonuç satırlarını sonuna alması gerekir. Bir uygulamanın tüm sonuç satırlarını almazsa, diğer kullanıcıları engelleyen tablolar kilitli bırakılabilir. SQL deyimlerini sunucuya saydam olarak gönderen bir uygulama kullanıyorsanız, uygulamanın tüm sonuç satırlarını alması gerekir. Yeterli yer yoksa (ve bunun için yapılandırılamazsa), engelleme sorunu çözmek mümkün olabilir. Bu sorunu önlemek için davranmayan uygulamaları raporlama veya karar destek veritabanıyla kısıtlayabilirsiniz.

    Çözünürlük:

    Uygulamanın tüm sonuç satırlarını sonuna getirmek için yeniden yazılması gerekir.

  4. Dağıtılmış istemci/sunucu kilitlenmesinin neden olduğu engelleme

    Sıradan kilitlenmeden farklı olarak, dağıtılmış kilitlenme RDBMS kilit yöneticisi algılanamaz kullanarak değil. Kilitlenmeyle ilgili kaynaklardan yalnızca biri SQL Server kilit olan due için bu olabilir. Diğer tarafında kilitlenme hiçbir denetime sahip olduğu SQL Server istemci uygulama düzeyinde bulunur. Bu nasıl olabilir, iki örnek aşağıda verilmiştir ve olası yolları uygulama kaçının.

    1. Bir tek istemci iş parçacığı ile istemci/sunucu dağıtılmış kilitlenmesi
      İstemci, birden çok açık bağlantısı ve tek bir yürütme iş parçacığı varsa, aşağıdaki dağıtılmış kilitlenme oluşabilir. Kısaltma amacıyla kullanılan "dbproc" terimi buraya istemci bağlantı yapısı anlamına gelir.


      SPID1------blocked on lock------->SPID2
      /\ (waiting to write results
      | back to client)
      | |
      | | Server side
      | ================================|==================================
      | <-- single thread --> | Client side
      | \/
      dbproc1 <------------------- dbproc2
      (waiting to fetch (effectively blocked on dbproc1, awaiting
      next row) single thread of execution to run)
      Yukarıda gösterilen durumda bir tek istemci uygulaması iş parçacığının iki açık bağlantısı bulunmaktadır. Bu zaman uyumsuz olarak dbproc1 üzerinde bir SQL işlemi gönderir. Başka bir deyişle, devam etmeden önce çağrının beklemez. Uygulama dbproc2 üzerinde başka bir SQL işlemi gönderir ve döndürülen verileri işlemeye başlamak için sonuçları bekler. Veriler gelmeye başladığında (hangi dbproc önce yanıtlarsa; dbproc1 olduğunu varsayalım), tüm verileri ilgili dbproc ile döndürülen tamamlanması için işler. SPID1 (iki sorgu zaman uyumsuz olarak sunucuda çalıştığından) SPID2 tarafından tutulan kilit üzerine engellenmiş kadar dbproc1 ' sonuçlar getirir. Bu noktada, dbproc1 daha fazla veri için sonsuza kadar bekleyecektir. SPID2 üzerinde bir Kilitle engellenmez, ancak dbproc2, istemciye veri göndermeye çalışır. Tek iş parçacığı yürütme uygulaması için kullanımda olduğundan ancak, dbproc2 etkili uygulama katmanı dbproc1 üzerinde dbproc1 tarafından engellenir. Bu durum SQL Server'ın algılayamayacağı veya gideremeyeceği ilgili kaynaklardan yalnızca biri SQL Server kaynağı olduğundan bir kilitlenmeyle sonuçlanır.

    2. Bağlantı başına iş parçacığı ile istemci/sunucu dağıtılmış kilitlenmesi

      İstemcideki her bağlantı için ayrı bir iş parçacığı var olsa bile, yine aşağıda gösterildiği gibi bu dağıtılmış kilitlenmenin çeşidini ortaya çıkabilir.


      SPID1------blocked on lock-------->SPID2
      /\ (waiting on net write) Server side
      | |
      | |
      | INSERT |SELECT
      | ================================|==================================
      | <-- thread per dbproc --> | Client side
      | \/
      dbproc1 <-----data row------- dbproc2
      (waiting on (blocked on dbproc1, waiting for it
      insert) to read the row from its buffer)
      Bu durumda, dbproc2 ve SPID2 zamanda tek satır işleme ve her bir arabellek satırı dbproc1'e bir INSERT, UPDATE, teslim etmeden gerçekleştirme niyetiyle bir SELECT deyimi çalıştıran veya DELETE deyimi aynı tabloda dışında Örnek A'ya benzer. Sonuçta, SPID1 (INSERT, UPDATE veya DELETE gerçekleştirerek) olur bloke SPID2 tarafından tutulan kilit üzerinde (SELECT gerçekleşir). SPID2, istemci dbproc2'ye sonuç satırı yazar. Sonra dbproc2 çalışır bir arabellek satırı dbproc1'e geçirmeye, ancak meşgul dbproc1 bulur (SPID1, SPID2 üzerinde geçerli INSERT üzerinde bekleyen bloke edildiğinde). Bu noktada dbproc2, SPID (SPID1) SPID2 tarafından veritabanı düzeyinde engellenen dbproc1 tarafından uygulama katmanında engellenir. Yine, bu, SQL Server'ın algılayamayacağı veya gideremeyeceği ilgili kaynaklardan yalnızca biri SQL Server kaynağı olduğundan bir kilitlenmeyle sonuçlanır.

    Örnek A ve B uygulama geliştiricilerin farkında olması gereken temel sorunlardır. Bunlar, uygulamalar bu durumları düzgün işleyebilecek şekilde kodlamaları gerekir.

    Çözünürlük:

    İki güvenilir çözümler, sorgu zaman aşımı veya bağlı bağlantılar kullanmak üzeresiniz.

    • Sorgu zaman aşımı
      Dağıtılmış kilitlenme oluştuğunda sorgu zaman aşımı sağlanmış zaman aşımı onu ne zaman kesilir. DB-Library veya ODBC belgeleri daha fazla bilgi için bkz: kullanarak bir sorgu zaman aşımı.

    • Bağlı bağlantılar
      Bu özellik birden fazla bağlantıya sahip bir istemci bağlantılarını birbirinin önüne geçmeyecek şekilde bunları tek bir hareket alanına, bağlamak izin verir. Daha fazla bilgi için SQL Server 7.0 Çevrimiçi Kitapları'nda "Bağlı bağlantılar kullanma" konusuna bakın.

  5. SPID, "Golden" veya geri alma durumundaki neden olduğu engelleme

    Sonlandırılan veya kullanıcı tanımlı bir hareketin dışında iptal geri alınacak bir veri değiştirme sorgusu. Bu istemci bilgisayarı yeniden başlatmayı ve kendi ağ oturumunun bağlantısının kesilmesinin yan etkisi olarak da oluşabilir. Benzer şekilde, kilitlenme kurbanı olarak seçilen sorgu geri alınır. Veri değiştirme sorgusu genellikle geri başlangıçta değişikliklerin uygulanma daha hızlı alınamaz. DELETE, INSERT veya UPDATE deyimi bir saattir çalışıyorsa, örneğin, bunu en azından geri almak için bir saat sürer. Çünkü yapılan değişiklikleri tümüyle geri alınması ya da veritabanında işlem ve fiziksel bütünlük tehlikeye Beklenen davranış budur. Bunun yapılması gerektiğinden, SQL Server "golden" veya geri alma durumundaki SPID'nin işaretler (hangi anlamına gelir öldürülüyor edemez veya kilitlenme kurbanı olarak seçilen). Bu, ROLLBACK komutunu gösterebilen sp_who, çıkışı izlenerek genellikle belirlenebilir. Durum sütununda sys.sysprocesses sp_who çıkışındaki veya SQL Server Management Studio etkinlik İzleyicisi de görünür bir ROLLBACK durumunu gösterir.
    Çözünürlük:

    SPID'nin yapılan değişiklikleri geri bitirmek beklemeniz gerekir.

    Bu işlemin ortasında sunucu kapatılmış, veritabanı yeniden başlatıldığında kurtarma modunda olur ve tüm açık kadar erişilemez hareketler işlenir. Başlangıç kurtarma kurtarma çalışma zamanı olarak hareket başına temelde aynı miktarda alır ve bu süre boyunca veritabanı erişilemez. Bu nedenle, sunucunun geri alma durumundaki bir SPID'yi düzeltmek zorlamak genellikle ters etki olacaktır.

    Bu durumdan kaçınmak için büyük toplu INSERT, UPDATE, gerçekleştirmek veya değil OLTP sistemlerinde yoğun saatlerde silme işlemleri. Mümkünse, etkinliğin az olduğu dönemlerde bu tür işlemleri gerçekleştirir.

  6. Artık bağlantının neden olduğu engelleme

    İstemci uygulaması Tuzağa yakalanırsa veya istemci iş istasyonu yeniden başlatılırsa, ağ oturumu sunucuya bazı koşullarda hemen iptal edilemeyebilir. Sunucunun açısından, istemci hala var gibi görünüyor ve alınmış olan kilitler korunmaya devam eder. Daha fazla bilgi için Microsoft Bilgi Bankası'ndaki makaleyi görüntülemek üzere aşağıdaki makale numarasını tıklatın:

    137983 artık SQL Server bağlantı sorunlarını giderme


    Çözünürlük:

    İstemci uygulaması kendi kaynaklarını uygun şekilde temizlik olmadan kesti, KILL komutu kullanarak SPID'yi sonlandırabilirsiniz. KILL komutu girdi SPID değerini alır. Örneğin, SPID 9'u sonlandırmak için basitçe aşağıdaki komutu yayınlayın:

    KILL 9


    Not: KILL komutu tamamlamak için KILL komutu denetimleri arasındaki aralıklar nedeniyle 30 saniye kadar sürebilir.

Engelleme sorunlarında uygulamanın payı

Sunucu tarafı ayarlama ve platform sorunları engelleme sorunuyla karşı karşıya kalındığında odaklanma eğilimi olabilir. Ancak, bu genellikle bir çözüm götürmez ve zaman ve daha iyi istemci uygulaması ve gönderdiğinde sorguları incelemeye harcanması enerji tüketebilir. Yapılan veritabanı çağrılarıyla ilgili uygulamanın sunduğu görünebilirlik düzeyi ne olursa olsun, bir engelleme sorunu yine de sık sık İnceleme uygulama ve uygulama tarafından tam gönderilen tam SQL deyimlerinin gerektirir Sorgu iptali, bağlantı yönetimi, tüm getirme ile ilgili davranışı sonuç satırlarını ve benzeri. Geliştirme aracı bağlantı yönetimi, sorgu iptali, sorgu zaman aşımı, sonuç getirme ve benzeri üzerinde açık denetime izin vermez, engelleme sorunları çözülemeyebilir. Bu olasılığın özellikle iş açısından kritik OLTP ortamlarında SQL Server için uygulama geliştirme aracı seçmeden önce yakından incelenmelidir.

Veritabanı ve uygulama tasarım ve yapım aşamasında çok dikkatli olunması önemlidir. Özellikle, her sorgu için kaynak tüketimi, yalıtım düzeyi ve hareket yolu uzunluğu değerlendirilmelidir. Her sorgunun ve hareketin olabildiğince sade olması gerekir. İyi bağlantı yönetimi prensipleri uygulanmalıdır. Bu yapılmadığı takdirde, az sayıda kullanıcıyla kabul edilebilir bir performansa sahip görünebilir, ancak kullanıcı sayısı olarak önemli ölçüde performans düşebilir mümkündür.

Microsoft SQL Server düzgün uygulama ve sorgu tasarımı ile çok az engellemeyle tek bir sunucuda binlerce eşzamanlı kullanıcıyı destekleme özelliğine de sahiptir.

Daha fazla yardıma mı ihtiyacınız var?

Yeteneklerinizi geliştirin

Eğitimleri keşfedin >

Yeni özellikleri ilk olarak siz edinin

Microsoft Insider’a katılın >

Bu bilgi yararlı oldu mu?

Dil kalitesinden ne kadar memnunsunuz?
Deneyiminizi ne etkiledi?

Geri bildiriminiz için teşekkürler!

×