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

  • Makale

Ş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 defterindeki adımları yürütun. İlk üç adım, bir sorgunun yaşam döngüsünü açıklayan telemetri toplama işleminde size yol gösterir. Makalenin sonundaki başvurular, toplanan verilerde bulunan olası fırsatları çözümlemenize yardımcı olur.

Not

Bu not defterini açmayı denemeden ö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 veCCI'lerin yeniden oluşturulduğundan emin olun.

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 .

-- 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;

-- 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 sorgulara sahip olmak 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 deyiminin bir toplu işte bulunduğunu bildiğinizde değeri resource_allocation_percentage olmayan QID'leri filtrelemeyi göz önünde bulundurun.

    Not: Diğer oturumlar tarafından engellenen bazı sorguları da filtreleyeebileceği için 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ğeri 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 1. request_idAdımda elde edilen değer
@ShowActiveOnly 0 - Sorgu için tüm adımları göster
1 - Yalnızca şu anda etkin olan adımı göster		 
DECLARE @QID VARCHAR(16) = '<request_id>', @ShowActiveOnly BIT = 1; 
-- Retrieve session_id of QID
DECLARE @session_id 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 waiting
   INNER JOIN sys.dm_pdw_waits blocking
      ON waiting.object_type = blocking.object_type
      AND waiting.object_name = blocking.object_name
   INNER JOIN sys.dm_pdw_exec_requests 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 için değeri 0 olarak değiştirin. Dağıtım için performans sorununa neden olabilecek değeri not wait_type alın.

Parametre Açıklama
@QID 1. request_idAdımda elde edilen değer
@StepIndex 2. StepIndexAdım'da tanımlanan değer
@ShowActiveOnly 0 - Verilen StepIndex değer için tüm dağıtımları göster
1 - Verilen StepIndex değer için yalnızca şu anda etkin olan dağıtımları göster		 
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 sayıda sorgunun kısa sürede gönderildiğini ve derlemeye başlamak için kuyruğa alındığını belirtir.

Azaltıcı etken

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şkili 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ü grubu/sınıflandırıcı önemi.

Azaltıcı etken

Karmaşık sorgu veya daha 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 durumlarda 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şimlerini kullanmaz).

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.

Azaltıcı etken

  • 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ıma 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 zaman diliminde çok sayıda DROP/TRUNCATE TABLE deyim gerçekleştiriyorsa, meta verilerin kalabalık hale gelmesi ve sonraki DROP/TRUNCATE TABLE deyimlerin yavaş yürütülmesine neden olması mümkündür.

Azaltıcı etken

Bir bakım penceresi belirleyin, tüm iş yüklerini durdurun ve DBCC SHRINKDATABASE'i çalıştırarak önceden bırakılan veya kesilmiş tabloların hemen temizlenmesini zorlar.


İyi durumda olmayan CCI'ler (genel olarak)

Kümelenmiş columnstore dizini (CCI) sistem durumu için ek meta veriler gerekir ve bu da sorgu iyileştiricisinin 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.

Azaltıcı etken

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


Otomatik oluşturma istatistiklerinin gecikmesi

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ırON. Ancak, otomatik oluşturma işleminin kendisi ilk sorgunun sonraki yürütmelerinden daha uzun sürmesini sağlayabilir.

Azaltıcı etken

Sorgunun ilk yürütülmesi tutarlı bir şekilde istatistiklerin oluşturulmasını gerektiriyorsa, sorguyu yürütmeden önce istatistikleri el ile 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ırON. İ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ı durdurulacaktır. İstatistiklerin oluşturulamaması, sorgu iyileştiricisinin verimli bir dağıtılmış yürütme planı oluşturma becerisini olumsuz etkileyebilir ve bu da sorgu performansının düşmesine neden olabilir.

Azaltıcı etken

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ım'da 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 Ortak Neden
    EstimatedRowCount / ActualRowCount < 25% Yanlış tahminler
    Description değeri gösterir BroadcastMoveOperation ve sorgu çoğaltılmış bir tabloya başvurur. Çıkarılmamış ç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. total_elapsed_time Belirli step_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 bölümü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.

Azaltıcı etken

İstatistikleri oluşturma/güncelleştirme.


Çıkarılmamış ç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 taşımaları veya en iyi durumdaki dağıtılmış bir planın oluşturulması nedeniyle beklenmeyen düşük performans ortaya çıkar.

Azaltıcı etken

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, cpu, GÇ ve ağ trafiğinin kullanılabilirliğini iş yükünün geri kalanına düşürecek gereksiz veri hareketlerine neden olur.

Azaltıcı etken

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


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örler nedeniyle değişken sürelerle karşılaşabilir.

Azaltıcı etken

Ö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ılmıyor olduğu anlamına gelir. Dağıtılmış planın her adımı, sonraki adıma geçmeden önce tüm dağıtımların tamamlanmasını gerektirir. Verileriniz çarpıtıldığında CPU ve GÇ gibi işleme kaynaklarının tam potansiyeli elde edilemez ve bu da yürütme sürelerinin yavaşlamasına neden olur.

Azaltıcı etken

Daha uygun bir dağıtım sütunu seçiminize yardımcı olması 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, dengesiz olan disk üzerindeki verilerin dağılımı değildir. Belirli filtreler veya gruplandırılmış veriler için dağıtılmış planın doğası bir ShuffleMoveOperation tür işlemine neden olur. Bu işlem aşağı akışta kullanılacak çarpık bir çıkış üretir.

Azaltıcı etken

  • İstatistiklerin oluşturulduğu ve güncel olduğundan emin olun.
  • Sütunlarınızın GROUP BY sırasını değiştirerek daha yüksek kardinalite sütununa sahip bir müşteri adayı oluşturun.
  • 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 (ve wait_timeiçindewait_type) en uzun süre çalışan adım için sorgu işlemeyi engellediğini belirleme fırsatına sahip olur. Ç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ımdan 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 bir 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, gerektiğinden daha fazla veri taşımayı içeren iyileştirilmemiş bir dağıtılmış planın oluşturulmasına neden olabilir. Gereksiz veri taşıma, yalnızca bekleyen verilerinizde değil, üzerinde de tempdbiş yükünü artırır. GÇ tüm sorgularda paylaşılan bir kaynak olduğundan performans etkileri iş yükünün tamamı tarafından hissedilebilir.

Bu durumu düzeltmek için tüm istatistiklerin güncel olduğundan ve bunların kullanıcı iş yükleri için güncel kalmasını sağlayacak bir bakım planının uygulandığından emin olun.

Ağır GÇ iş yükleri

Genel iş yükünüz büyük miktarlarda veri okuyor olabilir. Synapse ayrılmış SQL havuzları, kaynakları DWU'ya uygun olarak ö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 Durumu Ayrılmış SQL havuzunda kümelenmiş columnstore dizin durumunu değerlendirme ve düzeltme
Kullanıcı sorguları dönüştürmeleri içerir Biçimlendirilmiş sürümlerin depolanması için tüm biçimlendirmeyi ve diğer dönüştürme mantığını ETL işlemlerine taşıma
İş yükünün öncelikleri 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ımdaki 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 olarak ölçeklendirme
  2. İstediğiniz DWU düzeyine geri ölçeklendirin
SQL CLR

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