SELECT'te Bölümlenmiş Sütun Deposu Kilitlenmeleri Nasıl Engellenir

10

SQL Server 2016'da üç Kümelenmiş Sütun Dizini (CCI) tablosu var. Bu CCI'lerin tümü Kiracı Kimliğine göre aynı bölümleme şemasındadır. Son zamanlarda ve tutarsız bir şekilde, birleşimlerden bu tablolara kadar basit seçme ifadeler üzerinde kilitlenmeler alıyorum. Kilitlenmeyi engelleyen örnek sorgu:

SELECT  TOP 33 r.tenantid
FROM    Table_r r
        INNER JOIN Table_cm cm ON r.MyKey=cm.MyKey 
        INNER JOIN Table_pe pe ON r.MyKey=pe.MyKey 
WHERE   r.TenantId = 69
        AND pe.TenantId = 69
        AND cm.TenantId = 69

Hata mesajı:

İşlem (İşlem Kimliği 56) jenerik bekleme nesnesi kaynakları üzerinde başka bir işlemle kilitlendi ve kilitlenme kurbanı olarak seçildi. İşlemi yeniden çalıştırın.

İpuçları:

Sorgu CCI dışında başka bir dizin kullanırsa, kilitlenmez.
Üç kiracı filtreden ikisini kaldırırsam kilitlenmez.
En üst 32 veya altını SEÇERSEN kilitlenmez.
SEÇENEK (MAXDOP 1) eklersem kilitlenmez.
Bunu şifreli PROD kopyamda, PROD ONADE Sekonder ve PROD'un kendisinde çoğaltabilirim.
DEV veya INT'de bu davranışı yeniden oluşturamıyorum.
3 tablo birleşimine WITH (NOLOCK) eklersem hala kilitlenme
Sorgu kendini kilitler. Başka aktif süreç olmadığında kilitlenecektir.
Paralelliksiz sorgu planları çıkmaz

Kilitlenme xml burada

PROD Sürümümüz:

Microsoft SQL Server 2016 (SP2-CU5) (KB4475776) - 13.0.5264.1 (X64) 10 Ocak 2019 18:51:38 Telif Hakkı (c) Windows Server 2012 R2 Standard 6.3 (Derleme 9600) üzerinde Microsoft Corporation Enterprise Edition (64 bit) :) (Hipervizör)

Bu sorgudaki kilitlenmeleri nasıl önleyebilirim?

— Cyndi Baker
kaynak

8

SQL Server 2016'da olduğunuz için, sütun deposu dizinlerini içeren paralel kilitlenmeler için en az bir genel hata düzeltmesi olduğunu belirtmek gerekir:

Düzeltme: SQL Server 2016 ve 2017'de kümelenmiş bir sütun deposu dizininde paralel bir sorgu çalıştırdığınızda bir kilitlenme oluşur

( başlangıçta bağlantıyı sağladığı için Denis Rubashkin'e teşekkürler )

Bu, SP1 CU7'nin bir parçası olarak piyasaya sürüldü. Eğer bu CU'ya bağlı değilseniz, bunu denemelisiniz. Bu düzeltme SP2'ye (CU'lardan herhangi biri) de dahil edilir.

Genel olarak, sorgu içi paralellik kilitlenme kilitlerini düzeltmek için iki yaklaşım:

(Bu paralel gitmez böylece kullanarak, sorgu ayar yaparak önlemek paralellik MAXDOPipucu, vb) - Bu kaplıdır diğer cevap tarafından Thomas Costers
SQL Server'a en son hizmet paketini / toplu güncelleştirmeleri uygulama

— Josh Darnell
kaynak

2

Intra-Query Parallel Thread Deadlocks ile ilgili aşağıdaki blogu kontrol ettiniz mi?

SyncPointBen karıştırıyorsun değilim eğer kaynak bir değişim olayının kullanımını gösterir.
Kilitlenmenizin katılımcılarına bakıldığında, hepsinin aynı örümcek (55) ve parti (0) 'dan geldiğini, ancak farklı iplikler kullandığını görebilirsiniz. Bu, hepsinin aynı paralel sorgunun bir parçası olduğunu ve sorguyu her çalıştırdığınızda herhangi bir kilitlenme almamanızla onaylandığını gösterir MAXDOP 1. Sorgu İçi Paralel İş Parçacığı Kilitlenmeleri durumunda, tek bir sorgunun iş parçacıkları, sizin durumda eşitleme nesneleri olan SyncPoints'i bekleyen birbirini kilitleyerek sonuçlanır.

Son kez bu tür davranışlara tanık olduğumda, sorguyu daha da optimize edebildim ve böylece sorgunun paralel bir yürütme planı kullanmasını engelledim. Sonuç kümenizi 32 kayıtla sınırlandırarak veya farklı bir dizin kullanarak aynı şeyi yaptığınızdan şüpheleniyorum.
Başka bir seçenek MAXDOP 1, bu seçeneğin büyük bir hayranı olmasa da sorgunuza eklemek olacaktır .

Ancak bu iki seçenekle uğraşmadan önce, en son SP / CU'da olup olmadığınızı kontrol edin.

— Thomas Costers
kaynak