Fabric Data Warehouse'de sorgu engelleme sorunlarını giderme

Şunlara uygulanır:✅ Warehouse in Microsoft Fabric

Warehouse'taki sorgularınızın çalışması olağandışı şekilde uzun sürüyorsa veya takılı kalmış gibi görünüyorsa, olası nedenlerden biri kilitlemedir. Bir oturum diğer sorguların devam etmesini engelleyen bir kilit tuttuğunda kilitleme gerçekleşir.

Bu makalede, kilitlemenin iş yükünüzü etkileyip etkilemediğini ve gerçekleştirebileceğiniz eylemleri nasıl belirleyebileceğiniz gösterilir.

Tip

Warehouse, tablo düzeyinde kilitleme kullanır. Herhangi bir DML işlemi, etkilenen satır sayısına bakılmaksızın tablonun tamamında bir kilit alır. Bu davranış, satır düzeyi ve sayfa düzeyi kilitleri destekleyen SQL Server farklıdır.

Prerequisites

Etkin iş yüklerine sahip bir Ambar.
Görüntüleyici çalışma alanı rolü üyeliği, bu makaledeki dinamik yönetim görünümlerini (DMV) sorgulamak için en düşük izindir.
- DMV'lerle ilgili sorun giderme hakkında daha fazla bilgi için bkz. DMV kullanarak bağlantıları, oturumları ve istekleri izleme.

1. Adım: Sorguların kilitlerde bekleyip beklemediğini denetleyin

İşe, şu anda kilitlerde bekleyen herhangi bir sorgu olup olmadığını kontrol ederek başlayın.

Aşağıdaki sorguyu çalıştırın:

SELECT
    request_session_id,
    resource_type,
    resource_description,
    request_mode,
    request_status
FROM sys.dm_tran_locks
WHERE request_status = 'WAIT';

Sorgu satır döndürürse, bazı oturumlar diğer oturumlar tarafından tutulan kaynakları bekler. Her satır, şu anda verilmeyen bir kilit isteğini gösterir.

Tip

sys.dm_tran_locks görünümü, verilen kilitlere ilişkin çok sayıda satır döndürebilir. request_status = 'WAIT' ile filtreleme, engellenmiş oturumlara odaklanır.

2. Adım: Engellenen sorguları tanımlama

Ardından, hangi sorguların engellendiğini ve hangi oturumun engellendiğini denetleyin.

SELECT
    session_id,
    status,
    blocking_session_id,
    wait_type,
    total_elapsed_time,
    open_transaction_count
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Bu sorgu şunu döndürür:

Engellenen sorguyu (session_id) çalıştıran oturum
Şu anda bunu engelleyen oturum (blocking_session_id)
Ne kadar süredir bekliyor (total_elapsed_timemilisaniye cinsinden)
Engelleme oturumunun açık bir işlemi olup olmadığı (open_transaction_count)

Bir sorgu, blocking_session_id değerinin sıfır olmadığını ve open_transaction_count > 0 gösteriyorsa, kilidi tutan başka bir oturumu bekliyordur.

3. Adım: Engelleme oturumunu bulma

Hangi kaynağın kilitlendiğini anlamak için, engelleyen oturum tarafından şu anda tutulan kilitleri inceleyin. Aşağıdaki örnek sorguda, <blocking_session_id> yerine daha önce belirlediğiniz bir session_id koyun:

SELECT
    request_session_id,
    resource_type,
    resource_associated_entity_id,
    request_mode,
    request_status
FROM sys.dm_tran_locks
WHERE
    request_status = 'GRANT'
    AND request_session_id = <blocking_session_id>;

Aşağıdakileri belirlemek için bu sorguyu kullanın:

Engelleyen oturumun şu anda kilit bulundurduğu kaynaklar. Örneğin, resource_type = OBJECT’nin bulunduğu resource_associated_entity_id’i tanımlamak için sys.objects kullanabilirsiniz.
Kilit modu (örneğin, Münhasır (X), Şema Değişikliği (Sch-M))
Kilidin bir DDL işlemi veya istatistik güncelleştirmesi (UPDSTATS) ile ilgili olup olmadığı

Note

İstatistiklerle ilgili kilitler (UPDSTATS kaynaklı olanlar gibi) sys.dm_tran_locks içinde de görünür. Schema-Modification (Sch-M) ve Özel (X) kilitler en yaygın engelleyicilerdir, ancak herhangi bir kilit türü çakışan bir isteği engelleyebilir (örneğin, Sch-S bloklar Sch-M).

4. Adım: Engelleyen işlem sahibini bulma

Çoğu durumda, oturumu sonlandırmak yerine engelleme işleminin sahibine COMMIT veya ROLLBACK bu işlemin çalışmasına sormayı tercih edebilirsiniz. COMMIT veya ROLLBACK ile hata işleme için TRY ve CATCH yapılarını kullanmayı göz önünde bulundurun. Daha fazla bilgi için TRY...CATCH bölümüne bakın.

Engelleyen oturumla ilişkili sorguyu ve sahibini belirleyebilirsiniz. Aşağıdaki örnek sorguda, <blocking_session_id> yerine daha önce belirlediğiniz bir session_id kullanın:

SELECT
    r.session_id,
    s.login_name,
    s.program_name,
    r.status,
    r.blocking_session_id,
    r.command,
    r.total_elapsed_time,
    s.last_request_start_time,
    s.last_request_end_time
FROM sys.dm_exec_requests r
JOIN sys.dm_exec_sessions s
    ON r.session_id = s.session_id
WHERE r.session_id = <blocking_session_id>;

login_name engelleme oturumunun sahibidir.
program_name , oturumu başlatan uygulamadır. DMS_user değer, Fabric portal sorgu düzenleyicisini gösterir.
command şu anda çalışmakta olan komut.

Ardından, uygunsa işlemi onaylaması veya geri alması için işlem sahibiyle iletişime geçebilirsiniz.

5. Adım: Engelleme oturumunun boşta olup olmadığını veya ilerlemediğini denetleyin

Bloke eden bir oturum etkin görünebilir, ancak gerçekte ilerleme kaydetmiyor olabilir.

Boşta veya durdurulmuş bir oturumun göstergeleri şunlardır:

status = 'sleeping' etkin sorgu çalıştırmadığını gösterir.
Geçerli zamandan önemli ölçüde daha eski olan ve uzun süredir açık kalan bir isteği gösteren bir last_request_start_time arayın.
Denetimler arasında artmayan ve takılmış bir oturuma işaret eden bir total_elapsed_time arayın.

SELECT
    session_id,
    status,
    last_request_start_time,
    last_request_end_time,
    open_transaction_count
FROM sys.dm_exec_sessions
WHERE session_id = <blocking_session_id>;

Oturum durumu sleeping ve open_transaction_count > 0 ise, oturumun aktif sorgusu olmayan açık bir işlemi vardır; herhangi bir iş yapmadan bir kilidi elinde tutar.
Oturum içinde sys.dm_exec_requests görünürse ve total_elapsed_time denetimler arasında artmaya devam ederse oturum etkin bir şekilde ilerler. İşlemi sonlandırmak ve geri almayı zorlamak yerine işlemin tamamlanmasını beklemek tercih edilebilir.

6. Adım: Engellemeyi çözmek için eylem gerçekleştirme

Note

Engelleme durumları genellikle engelleme oturumu işlemi tamamladıktan sonra kendi kendine çözülür. İş yükünüz gecikmeyi tolere edebilirse en güvenli seçenek beklemektir.

Aşağı akış sorgularının engellemesini kaldırmanız gerekiyorsa, engelleme oturumunun aşağıdaki özelliklere sahip olup olmadığını göz önünde bulundurun:

Açık bir işlem var
Boşta görünüyor veya ilerlemiyor
Engelleyici bir kilit tutuluyor mu (örneğin, Exclusive (X) veya Sch-M)

Bu durumda, Yönetici çalışma alanı rolünün bir üyesi aşağıdakileri kullanarak oturumu sonlandırabilir:

KILL <session_id>;

Komut KILL şu şekilde olur:

Oturumu sonlandırma
O oturumun etkin işleminde yapılan tüm değişiklikleri geri al
Kilidi serbest bırakma
Aşağı akış sorgularının devam etmesine izin ver

Caution

Bir oturumun sonlandırılması, o oturum tarafından gerçekleştirilen tüm kaydedilmemiş işlemleri geri alır. Bu eylem, kullanıcı veya uygulama tarafından yapılan veri değişikliklerini geri alabilir. Bu seçeneği yalnızca işlemi sonlandırmanın iş yükünüzü olumsuz etkilemediğinden emin olduğunuzda kullanın.

7. Adım: Gelecekteki kilitleme sorunlarını önleme

Benzer sorunları önlemeye yardımcı olmak için:

Açık işlemleri açık bırakmaktan kaçının (BEGIN TRANSACTION karşılık gelen COMMIT veya ROLLBACKolmadan).
İşlemleri kısa süreli tutun. Yalnızca işlem içinde gerekli işlemleri gerçekleştirin.
Tamamlandığında her zaman COMMIT veya ROLLBACK işlemler.
Düşük trafikli pencereler sırasında DDL işlemlerini (örneğin ALTER TABLE) zamanlayın.

Aşağıdakini kullanarak açık işlemleri proaktif olarak izleyin:

SELECT
    session_id,
    login_name,
    open_transaction_count,
    program_name,
    status,
    blocking_session_id,
    last_request_start_time
FROM sys.dm_exec_sessions
WHERE open_transaction_count > 0;

Açık işlemleri düzenli olarak izlemek ve uygun olduğunda araya girip zincirlerin oluşmasını engelleme olasılığını azaltmaya yardımcı olur.

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2026-06-14