Aracılığıyla paylaş

Ayrılmış bir SQL Havuzundaki tempdb hatalarını giderme

Şunlar için geçerlidir: Azure Synapse Analytics

Ayrılmış bir SQL havuzunda tempdb veritabanı geçici tablolar ve veri taşımaları için ara alan (örneğin, karıştırma hareketleri, kırpma hareketleri), sıralamalar, yükler, bellek taşması ve diğer işlemler için kullanılır. Ayrıca, tempdb veritabanıyla etkileşim kuran bir oturumdaki kaydedilmemiş bir işlem, günlüğün diğer tüm oturumları temizlemesini engelleyerek günlük dosyalarının dolmasına neden olur. Tempdb veritabanı paylaşılan bir kaynak olduğundan, tempdb alanının büyük ölçüde tüketilmesi diğer kullanıcıların sorgularının başarısız olmasına neden olabilir ve yeni bağlantıların kurulmasını önlemek için bu sorguların yükseltilmesine neden olabilir.

Ayrılmış SQL havuzuna bağlanamıyorsam ne yapmalıyım?

Sorunlu bağlantıları veya sorguları tanımlamak için mevcut bağlantınız yoksa, yeni bağlantı oluşturamama sorununu çözmek için tek yöntem Duraklatma ve Sürdürme veya ayrılmış SQL havuzunu ölçeklendirmektir. Bu eylem, bu soruna yol açan kullanıcı işlemlerini sonlandırır ve hizmet yeniden başlatıldığında tempdb veritabanını yeniden oluşturur.

Not: Bu senaryoda duraklatma ve ölçeklendirme işlemlerinin tamamlanması normalden uzun sürebileceğinden, hizmete çalışan tüm işlemleri geri alması için ek süre verdiğinizden emin olun.

Tam tempdb veri dosyalarının sorunlarını giderme

1. Adım: Tempdb veritabanını dolduran sorguyu tanımlama

ETL çerçevenize bir günlük bileşeni uygulamadıysanız veya ayrılmış SQL havuzu deyimlerinizi denetlemediğiniz sürece sorgu yürütülürken tempdb veritabanını dolduran sorguyu tanımladığınızdan emin olun. Çoğu durumda, her zaman değil, sorunun oluştuğu zaman diliminde yürütülen en uzun süre çalışan sorgu tempdb yetersiz alan hatalarının nedenidir. Uzun süre çalışan sorguların listesini almak için aşağıdaki sorguyu çalıştırın:

SELECT TOP 5 *
FROM sys.dm_pdw_exec_requests
WHERE status = 'running'
ORDER BY total_elapsed_time desc;

Makul derecede şüpheli bir sorguya sahip olduktan sonra aşağıdaki seçeneklerden birini deneyin:

  • İfadeyi yok edin .
  • Uzun çalıştırıcının tamamlayabilmesi için diğer iş yüklerinin tempdb alanını daha fazla kullanmasını engellemeye çalış.

2. Adım: Yinelenmeyi engelleme

Sorumlu sorguyu tanımlayıp buna karşı eylemde bulunduktan sonra sorunun yinelenmesini önlemek için azaltmalar uygulamayı göz önünde bulundurun. Aşağıdaki tabloda tempdb tam hatalarının en yaygın nedenleri için azaltmalar gösterilmektedir:

Neden Açıklama Risk azaltma
Hatalı dağıtılmış plan Belirli bir sorgu için oluşturulan dağıtılmış plan, düşük bakımlı tablo istatistiklerinin sonucu olarak yanlışlıkla yüksek frekanslı veri taşımaya neden olabilir. İlgili tabloların istatistiklerini güncelleştirin ve bunların düzenli bir zamanlamaya göre korundığından emin olun.
Hatalı kümelenmiş columnstore dizini (CCI) durumu Bellek taşmalarından dolayı tempdb alanını tüketir. CCI'leri yeniden derleyin ve bunların düzenli bir zamanlamaya göre korundığından emin olun.
Büyük işlemler Büyük hacimli CREATE TABLE AS SELECT (CTAS) veya INSERT SELECT deyimleri, veri taşıma işlemleri sırasında tempdb'yi doldurur. CTAS veya INSERT SELECT deyiminizi daha küçük birkaç işleme bölün.
Yetersiz bellek ayırması Yetersiz bellek ayrılan sorgular (kaynak sınıfı veya iş yükü grubu aracılığıyla) içine tempdbtaşabilir. Sorgularınızı daha büyük bir kaynak sınıfı veya daha fazla kaynağı olan bir iş yükü grubu ile yürütün.
Son kullanıcı dış tablo sorguları Altyapının verileri işlemeden önce dosyanın tempdb tamamını okuması gerektiğinden, dış tablolardaki sorgular son kullanıcı sorguları için en uygun değildir. Verileri kalıcı bir tabloya yükleyin ve ardından kullanıcı sorgularını oraya yönlendirin.
Yetersiz genel kaynaklar Ayrılmış SQL havuzunuzun yüksek etkinlik sırasında en yüksek tempdb kapasitesine yakın olduğunu fark edebilirsiniz. Yukarıdaki risk azaltmalarından herhangi biriyle birlikte ayrılmış SQL havuzunuzun ölçeğini artırmayı göz önünde bulundurun.

Tam tempdb işlem günlüğü dosyalarının sorunlarını giderme

Tempdb işlem günlüğü genellikle yalnızca bir istemci/kullanıcı tarafından doldurulduğunda:

  • Açık bir işlem açar ancak hiçbir zaman veya COMMIT ROLLBACKoluşturmaz.
  • Kümeler IMPLICIT_TRANSACTION = ON (özellikle AutoCommit özelliklerini kullanan JDBC istemcileri ve araçları için).

1. Adım: Açık işlemleri tanımlama

Sorunlu bağlantılar, açık bir işleme sahip olan ancak "Boşta" durumda olan istemcilerden olabilir. Bu senaryoyu tanımlamaya yardımcı olması için aşağıdaki sorguyu çalıştırın:

SELECT *
FROM sys.dm_pdw_exec_sessions
WHERE is_transactional = 1
AND status = 'Idle';

Not: Bu sorgunun sonucu olarak döndürülen tüm bağlantılar mutlaka sorunlu değildir. Yürütmeler arasında 15 dakikadan fazla süreyle sorguyu en az iki kez çalıştırın ve bu durumda hangi bağlantıların kalıcı olduğunu görün.

2. Adım: Sorunu azaltma ve önleme

Hangi istemcilerin açık işlem tuttuğunu belirledikten sonra, kullanıcılarla birlikte çalışarak veya her ikisini birden değiştirin:

  • Sürücü yapılandırması (örneğin: JDBC AutoCommit ayarı olarak offayarlanır IMPLICIT_TRANSACTIONS = ON)
  • Geçici sorgu davranışları (örneğin: olmadan COMMIT/ROLLBACKyanlış yürütülüyor)BEGIN TRAN

Alternatif olarak, bu senaryoları düzenli aralıklarla algılamak ve sorunlu olabilecek oturumları sonlandırmak için otomatik bir işlem oluşturmayı düşünebilirsiniz.

Kaynaklar