Aracılığıyla paylaş

Ayrılmış SQL Havuzundaki yavaş sorgu sorunlarını giderme

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

Bu makale, Azure Synapse Analytics ayrılmış SQL havuzundaki sorgularla ilgili yaygın performans sorunlarının nedenlerini belirlemenize ve azaltmalar uygulamanıza yardımcı olur.

Sorunu gidermek için adımları izleyin veya Azure Data Studio aracılığıyla not defterinde adımları yürütebilirsiniz. İlk üç adım, bir sorgunun yaşam döngüsünü açıklayan telemetriyi toplama işleminde size yol gösterir. Makalenin sonundaki başvurular, toplanan verilerde bulunan olası fırsatları analiz etmene yardımcı olur.

Not

Bu not defterini açmaya çalışmadan önce yerel makinenizde Azure Data Studio'yu yüklediğinizden emin olun. Yüklemek için Azure Data Studio'yu yüklemeyi öğrenin bölümüne gidin.

Azure Data Studio'da Not Defteri'ni açma

Önemli

Bildirilen performans sorunlarının çoğu şunlardan kaynaklanıyor:

  • Eski istatistikler
  • İyi durumda olmayan kümelenmiş columnstore dizinleri (CCI)

Sorun giderme süresinden tasarruf etmek için istatistiklerin oluşturulduğundan ve güncel olduğundan emin olun ve ayrılmış SQL havuzunda kümelenmiş columnstore dizinlerini yeniden oluşturun.

1. Adım: request_id tanımlama (QID olarak da bilinir)

request_id Yavaş sorgunun nedeni, yavaş sorgunun olası nedenlerini araştırmak için gereklidir. Sorun gidermek istediğiniz sorguyu tanımlamak için başlangıç noktası olarak aşağıdaki betiği kullanın. Yavaş sorgu tanımlandıktan sonra değeri not edin request_id .

İlk olarak etkin sorguları izleyin. Bu sorgu önce en yeni satırlara göre sıralanır.

-- Monitor active queries
SELECT *
FROM sys.dm_pdw_exec_requests
WHERE [status] NOT IN ('Completed', 'Failed', 'Cancelled')
      AND session_id <> session_id()
-- AND [label] = '<YourLabel>'
-- AND resource_allocation_percentage is not NULL
ORDER BY submit_time DESC;

Ardından, en uzun süre çalışan sorgularla başlayarak en uzun çalışma süresine sahip etkin sorguları bulun.

-- Find top 10 longest running queries
SELECT TOP 10 *
FROM sys.dm_pdw_exec_requests
ORDER BY total_elapsed_time DESC;

Yavaş sorguları daha iyi hedeflemek için betiği çalıştırırken aşağıdaki ipuçlarını kullanın:

  • Sonuç kümesinin en üstünde en uzun süre çalışan sorguların mevcut olması için veya total_elapsed_time DESC ölçütüne göre submit_time DESC sıralayın.
  • Sorgularınızda kullanın OPTION(LABEL='<YourLabel>') ve sonra bunları tanımlamak için sütunu filtreleyin label .
  • Hedef deyimin bir toplu işte bulunduğunu bildiğinizde değeri resource_allocation_percentage olmayan QID'leri filtrelemeyi göz önünde bulundurun. Diğer oturumlar tarafından engellenen bazı sorguları da filtreleyebileceğinden bu filtreye dikkat edin.

2. Adım: Sorgunun nerede zaman aldığını belirleme

Sorgunun performans sorununa neden olabilecek adımı bulmak için aşağıdaki betiği çalıştırın. Betikteki değişkenleri aşağıdaki tabloda açıklanan değerlerle güncelleştirin. @ShowActiveOnly Dağıtılmış planın tam resmini almak için değerini 0 olarak değiştirin. Sonuç kümesinden StepIndextanımlanan yavaş adımın , Phaseve Description değerlerini not alın.

Parametre Açıklama
@QID Değer request_id 1. Adımda elde edilir.
@ShowActiveOnly değerini olarak 0 ayarlamak, sorgunun tüm adımlarını gösterir.
değerini olarak 1 ayarlamak yalnızca şu anda etkin olan adımı gösterir.		 
DECLARE @QID AS VARCHAR (16) = '<request_id>', @ShowActiveOnly AS BIT = 1;
-- Retrieve session_id of QID

DECLARE @session_id AS VARCHAR (16) = (SELECT session_id
                                       FROM sys.dm_pdw_exec_requests
                                       WHERE request_id = @QID);
-- Blocked by Compilation or Resource Allocation (Concurrency)
SELECT @session_id AS session_id, @QID AS request_id, -1 AS [StepIndex], 'Compilation' AS [Phase],
   'Blocked waiting on '
       + MAX(CASE WHEN waiting.type = 'CompilationConcurrencyResourceType' THEN 'Compilation Concurrency'
                  WHEN waiting.type LIKE 'Shared-%' THEN ''
                  ELSE 'Resource Allocation (Concurrency)' END)
       + MAX(CASE WHEN waiting.type LIKE 'Shared-%' THEN ' for ' + REPLACE(waiting.type, 'Shared-', '')
             ELSE '' END) AS [Description],
   MAX(waiting.request_time) AS [StartTime], GETDATE() AS [EndTime],
   DATEDIFF(ms, MAX(waiting.request_time), GETDATE())/1000.0 AS [Duration],
   NULL AS [Status], NULL AS [EstimatedRowCount], NULL AS [ActualRowCount], NULL AS [TSQL]
FROM sys.dm_pdw_waits waiting
WHERE waiting.session_id = @session_id
      AND ([type] LIKE 'Shared-%'
           OR [type] IN ('ConcurrencyResourceType', 'UserConcurrencyResourceType', 'CompilationConcurrencyResourceType'))
      AND [state] = 'Queued'
GROUP BY session_id
-- Blocked by another query
UNION ALL
SELECT @session_id AS session_id,
       @QID AS request_id,
       -1 AS [StepIndex],
       'Compilation' AS [Phase],
       'Blocked by ' + blocking.session_id + ':' + blocking.request_id + ' when requesting ' + waiting.type + ' on ' + QUOTENAME(waiting.object_type) + waiting.object_name AS [Description],
       waiting.request_time AS [StartTime],
       GETDATE() AS [EndTime],
       DATEDIFF(ms, waiting.request_time, GETDATE()) / 1000.0 AS [Duration],
       NULL AS [Status],
       NULL AS [EstimatedRowCount],
       NULL AS [ActualRowCount],
       COALESCE (blocking_exec_request.command, blocking_exec_request.command2) AS [TSQL]
FROM sys.dm_pdw_waits AS waiting
     INNER JOIN
     sys.dm_pdw_waits AS blocking
     ON waiting.object_type = blocking.object_type
        AND waiting.object_name = blocking.object_name
     INNER JOIN
     sys.dm_pdw_exec_requests AS blocking_exec_request
     ON blocking.request_id = blocking_exec_request.request_id
WHERE waiting.session_id = @session_id
      AND waiting.state = 'Queued'
      AND blocking.state = 'Granted'
      AND waiting.type != 'Shared'
-- Request Steps
UNION ALL
SELECT @session_id AS session_id,
       @QID AS request_id,
       step_index AS [StepIndex],
       'Execution' AS [Phase],
       operation_type + ' (' + location_type + ')' AS [Description],
       start_time AS [StartTime],
       end_time AS [EndTime],
       total_elapsed_time / 1000.0 AS [Duration],
       [status] AS [Status],
       CASE WHEN estimated_rows > -1 THEN estimated_rows END AS [EstimatedRowCount],
       CASE WHEN row_count > -1 THEN row_count END AS [ActualRowCount],
       command AS [TSQL]
FROM sys.dm_pdw_request_steps
WHERE request_id = @QID
      AND [status] = CASE @ShowActiveOnly WHEN 1 THEN 'Running' ELSE [status] END
ORDER BY StepIndex;

3. Adım: Adım ayrıntılarını gözden geçirme

Önceki adımda tanımlanan adımın ayrıntılarını gözden geçirmek için aşağıdaki betiği çalıştırın. Betikteki değişkenleri aşağıdaki tabloda açıklanan değerlerle güncelleştirin. @ShowActiveOnly Tüm dağıtım zamanlamalarını karşılaştırmak 0 için değerini olarak değiştirin. Dağıtım için performans sorununa neden olabilecek değeri not wait_type alın.

Parametre Açıklama
@QID Değer request_id 1. Adımda elde edilir.
@StepIndex Değer StepIndex 2. Adımda tanımlanır.
@ShowActiveOnly değerini olarak 0 ayarlamak, verilen StepIndex değerin tüm dağıtımlarını gösterir.
değerini olarak 1 ayarlamak, yalnızca verilen StepIndex değer için geçerli olan etkin dağıtımları gösterir.		 
DECLARE @QID VARCHAR(16) = '<request_id>', @StepIndex INT = <StepIndex>, @ShowActiveOnly BIT = 1;
WITH dists
AS (SELECT request_id, step_index, 'sys.dm_pdw_sql_requests' AS source_dmv,
       distribution_id, pdw_node_id, spid, 'NativeSQL' AS [type], [status],
       start_time, end_time, total_elapsed_time, row_count
    FROM sys.dm_pdw_sql_requests
    WHERE request_id = @QID AND step_index = @StepIndex
    UNION ALL
    SELECT request_id, step_index, 'sys.dm_pdw_dms_workers' AS source_dmv,
       distribution_id, pdw_node_id, sql_spid AS spid, [type],
       [status], start_time, end_time, total_elapsed_time, rows_processed as row_count
    FROM sys.dm_pdw_dms_workers
    WHERE request_id = @QID AND step_index = @StepIndex
   )
SELECT sr.step_index, sr.distribution_id, sr.pdw_node_id, sr.spid,
       sr.type, sr.status, sr.start_time, sr.end_time,
       sr.total_elapsed_time, sr.row_count, owt.wait_type, owt.wait_time
FROM dists sr
   LEFT JOIN sys.dm_pdw_nodes_exec_requests owt
      ON sr.pdw_node_id = owt.pdw_node_id
         AND sr.spid = owt.session_id
         AND ((sr.source_dmv = 'sys.dm_pdw_sql_requests'
                 AND sr.status = 'Running') -- sys.dm_pdw_sql_requests status
              OR (sr.source_dmv = 'sys.dm_pdw_dms_requests'
                     AND sr.status not LIKE 'Step[CE]%')) -- sys.dm_pdw_dms_workers final statuses
WHERE sr.request_id = @QID
      AND ((sr.source_dmv = 'sys.dm_pdw_sql_requests' AND sr.status =
               CASE WHEN @ShowActiveOnly = 1 THEN 'Running' ELSE sr.status END)
           OR (sr.source_dmv = 'sys.dm_pdw_dms_workers' AND sr.status NOT LIKE
                  CASE WHEN @ShowActiveOnly = 1 THEN 'Step[CE]%' ELSE '' END))
      AND sr.step_index = @StepIndex
ORDER BY distribution_id

4. Adım: Tanılama ve azaltma

Derleme aşaması sorunları

Engellendi: Derleme Eşzamanlılığı

Eşzamanlılık Derleme blokları nadiren oluşur. Ancak, bu tür bir blokla karşılaşırsanız, çok büyük miktarda sorgunun kısa bir süre içinde gönderildiğini ve derlemeye başlamak için kuyruğa alındığını belirtir.

Risk Azaltıcı Etkenler

Eşzamanlı olarak gönderilen sorgu sayısını azaltın.


Engellendi: kaynak ayırma

Kaynak ayırmanın engellenmesi, sorgunuzun şu temellere göre yürütülmesini beklediği anlamına gelir:

  • Kullanıcıyla ilişkilendirilmiş kaynak sınıfına veya iş yükü grubu atamasına göre verilen bellek miktarı.
  • Sistem veya iş yükü grubundaki kullanılabilir bellek miktarı.
  • (İsteğe bağlı) İş yükü grubunun/sınıflandırıcının önemi.

Risk Azaltıcı Etkenler

Karmaşık sorgu veya eski JOIN söz dizimi

Derleme aşaması uzun sürdüğünden varsayılan sorgu iyileştirici yöntemlerinin etkisiz olduğu bir durumla karşılaşabilirsiniz. Sorgu şu durumda oluşabilir:

  • Çok sayıda birleştirme ve/veya alt sorgu (karmaşık sorgu) içerir.
  • Yan tümcesinde FROM birleştiricileri kullanır (ANSI-92 stil birleşimleri değil).

Bu senaryolar atipik olsa da, sorgu iyileştiricisinin plan seçme süresini kısaltmak için varsayılan davranışı geçersiz kılmaya yönelik seçenekleriniz vardır.

Risk Azaltıcı Etkenler

  • ANSI-92 stil birleşimlerini kullanın.
  • Sorgu ipuçları ekleyin: OPTION(FORCE ORDER, USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION')). Daha fazla bilgi için bkz. FORCE ORDER ve Kardinalite Tahmini (SQL Server).
  • Sorguyu birden çok, daha az karmaşık adımlara bölün.
Uzun süre çalışan DROP TABLE veya TRUNCATE TABLE

Yürütme süresi verimlilikleri için ve TRUNCATE TABLE deyimleri depolama DROP TABLE temizleme işlemini bir arka plan işlemine erteler. Ancak, iş yükünüz kısa bir süre içinde çok sayıda DROP/TRUNCATE TABLE deyim gerçekleştiriyorsa, meta verilerin kalabalıklaşması ve sonraki DROP/TRUNCATE TABLE deyimlerin yavaş yürütülmesine neden olması mümkündür.

Risk Azaltıcı Etkenler

Önceden bırakılan veya kesilmiş tabloların hemen temizlenmesini zorlamak için bir bakım penceresi belirleyin, tüm iş yüklerini durdurun ve DBCC SHRINKDATABASE'i çalıştırın.


İyi Durumda Olmayan URI'ler (genel olarak)

Kötü kümelenmiş columnstore dizini (CCI) sistem durumu fazladan meta veriler gerektirir ve bu da sorgu iyileştiricinin en uygun planı belirlemesi için daha fazla zaman almasına neden olabilir. Bu durumdan kaçınmak için tüm CCI'lerinizin iyi durumda olduğundan emin olun.

Risk Azaltıcı Etkenler

Ayrılmış bir SQL havuzunda kümelenmiş columnstore dizin durumunu değerlendirin ve düzeltin.


Otomatik oluşturma istatistiklerini geciktirme

Otomatik istatistik oluşturma seçeneği, AUTO_CREATE_STATISTICS sorgu iyileştiricinin iyi dağıtılmış plan kararları almasını sağlamaya yardımcı olmak için varsayılan olarak kullanılır ON . Ancak, otomatik oluşturma işleminin kendisi ilk sorgunun sonraki yürütmelerinden daha uzun sürmesini sağlayabilir.

Risk Azaltıcı Etkenler

Sorgunun ilk yürütülmesi tutarlı bir şekilde istatistiklerin oluşturulmasını gerektiriyorsa, sorgunun yürütülmesinden önce el ile istatistik oluşturmanız gerekir.


İstatistikleri otomatik oluşturma zaman aşımları

Otomatik istatistik oluşturma seçeneği, AUTO_CREATE_STATISTICS sorgu iyileştiricinin iyi dağıtılmış plan kararları almasını sağlamaya yardımcı olmak için varsayılan olarak kullanılır ON . İstatistiklerin otomatik olarak oluşturulması bir SELECT deyimine yanıt olarak gerçekleşir ve tamamlanması için 5 dakikalık bir eşik vardır. Verilerin boyutu ve/veya oluşturulacak istatistik sayısı 5 dakikalık eşikten daha uzun bir süre gerektiriyorsa, sorgunun yürütülmeye devam edebilmesi için istatistiklerin otomatik olarak oluşturulmasından vazgeçilir. İstatistiklerin oluşturulamaması, sorgu iyileştiricinin verimli bir dağıtılmış yürütme planı oluşturma becerisini olumsuz yönde etkileyerek sorgu performansının düşmesine neden olabilir.

Risk Azaltıcı Etkenler

Tanımlanan tablolar/sütunlar için otomatik oluşturma özelliğine güvenmek yerine istatistikleri el ile oluşturun.

Yürütme aşaması sorunları

  • 2. Adımda sonuç kümesini analiz etmek için aşağıdaki tabloyu kullanın. Senaryonuzu belirleyin ve ayrıntılı bilgi ve olası risk azaltma adımları için yaygın nedeni denetleyin.

    Senaryo Yaygın Neden
    EstimatedRowCount / ActualRowCount < 25% Yanlış tahminler
    Description Değeri belirtir ve sorgu çoğaltılmış bir tabloya başvururBroadcastMoveOperation. Kazınmamış çoğaltılmış tablolar
    1. @ShowActiveOnly = 0
    2. Yüksek veya beklenmeyen sayıda adım (step_index) gözlemlenir.
    3. Birleştirici sütunlarının veri türleri tablolar arasında aynı değildir.    		 Eşleşmeyen veri türü/boyutu
    1. Değer Description , HadoopRoundRobinOperation veya HadoopShuffleOperationdeğerini gösterirHadoopBroadcastOperation.
    2. Verilen total_elapsed_timestep_index bir değeri yürütmeler arasında tutarsız.    		 Geçici dış tablo sorguları

  • total_elapsed_time 3. Adımda elde edilen değeri denetleyin. Belirli bir adımda birkaç dağıtımda önemli ölçüde daha yüksekse şu adımları izleyin:

    1. Her birinde aşağıdaki komutu çalıştırarak, alanında başvuruda bulunarak TSQL ilişkili step_id olan her tablonun veri dağıtımını denetleyin:

      DBCC PDW_SHOWSPACEUSED(<table>);

    2. En düşük satır değeri>/<en yüksek satır değeri>> 0,1 ise <Veri dengesizliği (depolanmış) bölümüne gidin.

    3. Aksi takdirde, Uçuş içi veri dengesizliği'ne gidin.

Yanlış tahminler

Sorgu iyileştiricisinin en uygun planı oluşturduğundan emin olmak için istatistiklerinizin güncel olmasını sağlayın. Tahmini satır sayısı gerçek sayılardan önemli ölçüde daha az olduğunda, istatistiklerin korunması gerekir.

Risk Azaltıcı Etkenler

İlk olarak, ayrılmış bir SQL havuzundaki istatistiklerin doğruluğunu denetleyin. Gerekirse istatistikleri oluşturun veya güncelleştirin.


Kazınmamış çoğaltılmış tablolar

Çoğaltılmış tablolar oluşturduysanız ve çoğaltılan tablo önbelleğini düzgün bir şekilde ısıtamazsanız, ek veri hareketlerinden veya en iyi duruma uygun olmayan dağıtılmış planın oluşturulmasından kaynaklanan beklenmeyen düşük performansa neden olur.

Risk Azaltıcı Etkenler

Eşleşmeyen veri türü/boyutu

Tabloları birleştirirken, birleştirme sütunlarının veri türünün ve boyutunun eşleştiğinden emin olun. Aksi takdirde, iş yükünün geri kalanında CPU, GÇ ve ağ trafiğinin kullanılabilirliğini azaltacak gereksiz veri taşımalarına neden olur.

Risk Azaltıcı Etkenler

Aynı veri türüne ve boyutuna sahip olmayan ilişkili tablo sütunlarını düzeltmek için tabloları yeniden oluşturun.


Geçici dış tablo sorguları

Dış tablolara yönelik sorgular, verileri ayrılmış SQL havuzuna toplu yükleme amacıyla tasarlanmıştır. Dış tablolara yönelik geçici sorgular, eşzamanlı depolama kapsayıcısı etkinlikleri gibi dış faktörlerden dolayı değişken sürelerle karşılanabilir.

Risk Azaltıcı Etkenler

Önce ayrılmış SQL havuzuna veri yükleyin ve ardından yüklenen verileri sorgulayın.


Veri dengesizliği (depolanmış)

Veri dengesizliği, verilerin dağıtımlar arasında eşit olarak dağıtılamadığından kaynaklanmıştır. Dağıtılmış planın her adımı, sonraki adıma geçmeden önce tüm dağıtımların tamamlanmasını gerektirir. Verileriniz dengesiz olduğunda CPU ve GÇ gibi işlem kaynaklarının tüm potansiyeline ulaşılamaz ve bu da yürütme sürelerinin yavaşlamasını sağlar.

Risk Azaltıcı Etkenler

Daha uygun bir dağıtım sütunu seçiminize yardımcı olmak için dağıtılmış tablolar için kılavuzumuzu gözden geçirin.


Uçuş içi veri dengesizliği

Uçuş içi veri dengesizliği, veri dengesizliği (depolanmış) sorununun bir çeşididir. Ancak, çarpık olan disk üzerindeki verilerin dağılımı değildir. Belirli filtreler veya gruplandırılmış veriler için dağıtılmış planın yapısı bir ShuffleMoveOperation tür işlemine neden olur. Bu işlem aşağı akış için kullanılacak çarpık bir çıkış üretir.

Risk Azaltıcı Etkenler

  • İstatistiklerin oluşturulduğu ve güncel olduğundan emin olun. Ayrılmış bir SQL havuzundaki istatistiklerin doğruluğunu denetleme bölümünde açıklanan adımları izleyerek bunların doğruluğunu doğrulayabilirsiniz.
  • Sütunlarınızın GROUP BY sırasını değiştirerek daha yüksek kardinaliteli bir sütuna sahip olun.
  • Birleştirmeler birden çok sütunu kapsıyorsa çok sütunlu istatistikler oluşturun.
  • Sorgunuza sorgu ipucu OPTION(FORCE_ORDER) ekleyin.
  • Sorguyu yeniden düzenleme.

Bekleme türü sorunları

Yukarıdaki yaygın sorunlardan hiçbiri sorgunuz için geçerli değilse, 3 . Adım verileri hangi bekleme türlerinin ( wait_type ve wait_time) en uzun süre çalışan adım için sorgu işlemeyi engellediğini belirleme fırsatı sağlar. Çok sayıda bekleme türü vardır ve benzer azaltmalar nedeniyle bunlar ilgili kategoriler halinde gruplandırılır. Sorgu adımınızın bekleme kategorisini bulmak için şu adımları izleyin:

  1. wait_type 3. Adımda en çok zaman alan öğesini belirleyin.
  2. Bekleme kategorileri eşleme tablosundaki bekleme türünü bulun ve içerdiği bekleme kategorisini belirleyin.
  3. Önerilen azaltmalar için aşağıdaki listeden bekleme kategorisiyle ilgili bölümü genişletin.
Derleme

Derleme kategorisinin bekleme türü sorunlarını azaltmak için şu adımları izleyin:

  1. Sorunlu sorguda yer alan tüm nesneler için dizinleri yeniden oluşturun.
  2. Sorunlu sorguda yer alan tüm nesnelerle ilgili istatistikleri güncelleştirin.
  3. Sorunun devam edip etmediğini doğrulamak için sorunlu sorguyu yeniden test edin.

Sorun devam ederse:

  1. şu .sql dosyası oluşturun:

    SET QUERY_DIAGNOSTICS ON; <Your_SQL>; SET QUERY_DIAGNOSTICS OFF;

  2. Bir Komut İstemi penceresi açın ve aşağıdaki komutu çalıştırın:

    sqlcmd −S <servername>.database.windows.net −d <databasename> −U <username> −G −I −i .\<sql_file_name>.sql −y0 −o .\<output_file_name>.txt

  3. metin düzenleyicisinde output_file_name>.txt açın<. 2. Adımda tanımlanan en uzun süre çalışan adımdaki dağıtım düzeyi yürütme planlarını (ile <ShowPlanXML>başlayan satırlar) bulup kopyalayarak .sqlplan uzantısına sahip ayrı metin dosyalarına yapıştırın.

    Not: Dağıtılmış planın her adımı genellikle 60 dağıtım düzeyi yürütme planı kaydetmiş olur. Aynı dağıtılmış plan adımından yürütme planlarını hazırlayıp karşılaştırdığınızdan emin olun.

  4. 3. Adım sorgusu sık sık diğerlerinden çok daha uzun süre alan birkaç dağıtım gösterir. SQL Server Management Studio'da, uzun süre çalışan bir dağıtımın dağıtım düzeyi yürütme planlarını (oluşturulan .sqlplan dosyalarından) hızlı çalışan bir dağıtımla karşılaştırarak farkların olası nedenlerini analiz edin.

Kilit, Çalışan İş Parçacığı
  • CCI yerine satır deposu dizinini kullanmak için sık ve küçük değişikliklerden geçen tabloları değiştirmeyi göz önünde bulundurun.
  • Değişikliklerinizi toplu işleyin ve hedefi daha az sıklıkta daha fazla satırla güncelleştirin.
Arabellek GÇ, Diğer Disk GÇ, Tran Günlük GÇ

İyi Durumda Olmayan CCI'ler

İyi durumda olmayan CCI'ler artan GÇ, CPU ve bellek ayırmaya katkıda bulunur ve bu da sorgu performansını olumsuz yönde etkiler. Bu sorunu azaltmak için aşağıdaki yöntemlerden birini deneyin:

Eski istatistikler

Güncel olmayan istatistikler, en iyi duruma getirilmemiş dağıtılmış planın oluşturulmasına neden olabilir ve bu da gerektiğinden daha fazla veri hareketi içerir. Gereksiz veri taşıma, iş yükünü yalnızca bekleyen verilerinizde değil, üzerinde de tempdbartırır. GÇ tüm sorgular genelinde paylaşılan bir kaynak olduğundan performanstaki değişimler tüm iş yükünü etkileyebilir.

İyileştirici, sorgu tarafından döndürülecek satır sayısını tahmin etmek için istatistiklere dayanır. İstatistikler, birleştirme koşulu sırasında verileri hizalamak için sorgu iyileştiricinin en verimli planı seçmesine veya en iyi taşıma işlemini (örneğin, Karıştırma Taşıma İşlemi veya Geniş Tür Taşıma İşlemi) gerçekleştirmesine olanak tanır. En iyi birleştirme koşulu tablo dağıtım türüne bağlıdır.

Örneğin, belirli bir tablo için gerçek satır sayısı 60 milyon ve tahmini satır sayısı 1.000 ise (denetim düğümü düzeyinde), iyileştirici bir Yayın taşıma işlemi seçebilir. Bu davranışın nedeni, iyileştiricinin tablonun yalnızca 1.000 satır içerdiği varsayımı dikkate alındığında maliyetin Karıştırma Hareketi ile karşılaştırıldığında daha düşük olarak algılanmasıdır. Ancak gerçek yürütme başladıktan sonra altyapı, yayın taşımayı kullanarak yürütmenin bir parçası olarak 60 milyon satırı taşır. Bu, hem veri boyutunu hem de satır sayısını dikkate alarak pahalı bir işlem olabilir. Sonuç olarak, veri boyutu önemliyse sorgunun kendisi ve diğer sorgular için performans sorunlarına yol açarak yüksek CPU kullanımına neden olabilir.

Bu durumu düzeltmek için tüm istatistiklerin güncel olduğundan ve kullanıcı iş yükleri için güncelleştirilmeleri için bir bakım planının hazır olduğundan emin olun. Ayrılmış sql havuzundaki istatistiklerin doğruluğunu denetleme bölümünde açıklanan adımları izleyerek istatistiklerin doğruluğunu doğrulayabilirsiniz.

Ağır GÇ iş yükleri

Genel iş yükünüz büyük miktarda veri okuyor olabilir. Synapse ayrılmış SQL havuzları, kaynaklarınızı DWU'ya uygun şekilde ölçeklendirir. Daha iyi performans elde etmek için şunlardan birini veya her ikisini de göz önünde bulundurun:

CPU, Paralellik
Senaryo Risk azaltma
Kötü CCI Sistem Durumu Ayrılmış SQL havuzunda kümelenmiş columnstore dizininin durumunu değerlendirme ve düzeltme
Kullanıcı sorguları dönüşümler içeriyor Biçimlendirilmiş sürümlerin depolanabilmesi için tüm biçimlendirmeyi ve diğer dönüştürme mantığını ETL işlemlerine taşıyın
İş yükünün önceliği yanlış belirlendi İş yükü yalıtımı uygulama
İş yükü için yetersiz DWU İşlem kaynaklarını artırmayı göz önünde bulundurun

Ağ GÇ

Sorun 2. Adımda bir RETURN işlem sırasında oluşuyorsa,

  • Eşzamanlı paralel işlemlerin sayısını azaltın.
  • En çok etkilenen işlemin ölçeğini başka bir istemciye genişletme.

Diğer tüm veri taşıma işlemleri için ağ sorunlarının ayrılmış SQL havuzunun içinde gibi görünmesi olasıdır. Bu sorunu hızla azaltmaya çalışmak için şu adımları izleyin:

  1. Ayrılmış SQL havuzunuzu DW100c'ye ölçeklendirin
  2. İstediğiniz DWU düzeyine geri ölçeklendirin
SQL CLR

Verileri dönüştürmenin FORMAT() alternatif bir yolunu uygulayarak (örneğin, CONVERT() stille) işlevin sık kullanılmasından kaçının.