Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği performans için uygulamaları ve veritabanlarını ayarlama

Şunlar için geçerlidir: Azure SQL Veritabanı Azure SQL Yönetilen Örneği

Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği ile karşılaştığınız bir performans sorunu belirledikten sonra, bu makale size yardımcı olmak için tasarlanmıştır:

  • Uygulamanızı ayarlayın ve performansı geliştirebilecek en iyi yöntemleri uygulayın.
  • Verilerle daha verimli çalışmak için dizinleri ve sorguları değiştirerek veritabanını ayarlayın.

Bu makalede, Azure SQL Veritabanı veritabanı danışmanı önerilerini ve Azure SQL Veritabanı otomatik ayarlama önerilerini (varsa) önceden incelediğiniz varsayılır. Ayrıca , izleme ve ayarlamaya genel bakışı ve performans sorunlarını gidermeyle ilgili ilgili makalelerini gözden geçirdiğiniz varsayılır. Ayrıca bu makalede, veritabanınıza daha fazla kaynak sağlamak için işlem boyutu veya hizmet katmanı artırılarak çözülebilen çalışan performans sorunu olan bir CPU kaynağınız olmadığı varsayılır.

Uygulamanızı ayarlama

Geleneksel şirket içi SQL Server, ilk kapasite planlama süreci genellikle bir uygulamayı üretimde çalıştırma işleminden ayrılır. Önce donanım ve ürün lisansları satın alınıyor ve daha sonra performans ayarlaması yapılıyor. Azure SQL kullandığınızda, bir uygulamayı çalıştırma ve ayarlama işlemini birbirine ayırmanız iyi bir fikirdir. İsteğe bağlı kapasite için ödeme yapma modeliyle, genellikle yanlış olan bir uygulama için gelecekteki büyüme planlarının tahminlerine göre donanıma aşırı sağlama yapmak yerine, uygulamanızı şu anda gereken en düşük kaynakları kullanacak şekilde ayarlayabilirsiniz. Bazı müşteriler bir uygulamayı ayarlamamayı tercih edebilir ve bunun yerine donanım kaynaklarını fazla sağlamayı seçebilir. Yoğun bir dönemde önemli bir uygulamayı değiştirmek istemiyorsanız bu yaklaşım iyi bir fikir olabilir. Ancak bir uygulamanın ayarlanması, Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği hizmet katmanlarını kullandığınızda kaynak gereksinimlerini en aza indirip aylık faturaları düşürebilir.

Uygulama özellikleri

Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği hizmet katmanları bir uygulama için performans kararlılığını ve öngörülebilirliği geliştirmek üzere tasarlanmış olsa da, bazı en iyi yöntemler uygulamanızı işlem boyutundaki kaynaklardan daha iyi yararlanacak şekilde ayarlamanıza yardımcı olabilir. Birçok uygulama yalnızca daha yüksek bir işlem boyutuna veya hizmet katmanına geçerek önemli performans kazanımlarına sahip olsa da, bazı uygulamaların daha yüksek bir hizmet düzeyinden yararlanmak için ek ayarlamaya ihtiyacı vardır. Daha yüksek performans için, bu özelliklere sahip uygulamalar için ek uygulama ayarlamayı göz önünde bulundurun:

  • "Geveleme" davranışı nedeniyle düşük performansa sahip uygulamalar

    Gevevelemeli uygulamalar, ağ gecikme süresine duyarlı aşırı veri erişimi işlemleri yapar. Veritabanına yönelik veri erişim işlemlerinin sayısını azaltmak için bu tür uygulamaları değiştirmeniz gerekebilir. Örneğin, geçici sorguları toplu hale getirmek veya sorguları saklı yordamlara taşımak gibi teknikleri kullanarak uygulama performansını geliştirebilirsiniz. Daha fazla bilgi için bkz . Batch sorguları.

  • Tek bir makinenin tamamı tarafından desteklenmeyebilen yoğun iş yüküne sahip veritabanları

    En yüksek Premium işlem boyutundaki kaynakları aşan veritabanları, iş yükünün ölçeğini genişletmenin avantajlarından yararlanabilir. Daha fazla bilgi için bkz. Veritabanları arası parçalama ve İşlevsel bölümleme.

  • En iyi olmayan sorguları olan uygulamalar

    Özellikle veri erişim katmanındaki zayıf ayarlanmış sorgulara sahip uygulamalar daha yüksek işlem boyutundan yararlanamayabilir. Bu, WHERE yan tümcesi olmayan, eksik dizinleri olan veya eski istatistikleri olan sorguları içerir. Bu uygulamalar standart sorgu performansı ayarlama tekniklerinden yararlanıyor. Daha fazla bilgi için bkz . Eksik dizinler ve Sorgu ayarlama ve ipuçları.

  • En iyi olmayan veri erişimi tasarımına sahip uygulamalar

    Veri erişim eşzamanlılığı sorunları olan uygulamalar (örneğin kilitlenme) daha yüksek bir işlem boyutundan yararlanamayabilir. Azure Önbellek hizmeti veya başka bir önbelleğe alma teknolojisiyle verileri istemci tarafında önbelleğe alarak veritabanına yönelik gidiş dönüşleri azaltmayı göz önünde bulundurun. Bkz. Uygulama katmanı önbelleğe alma.

    Azure SQL Veritabanında kilitlenmelerin yeniden oluşmasını önlemek için bkz. Azure SQL Veritabanında kilitlenmeleri çözümleme ve önleme. Azure SQL Yönetilen Örneği için İşlem kilitleme ve satır sürüm oluşturma kılavuzununKilitlenmeleri bölümüne bakın.

Veritabanınızı ayarlama

Bu bölümde, uygulamanız için en iyi performansı elde etmek ve mümkün olan en düşük işlem boyutunda çalıştırmak üzere veritabanını ayarlamak için kullanabileceğiniz bazı tekniklere göz atacağız. Bu tekniklerden bazıları geleneksel SQL Server ayarlama en iyi yöntemleriyle eşleşir, ancak diğerleri Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği özgülerdir. Bazı durumlarda, Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği çalışmak üzere geleneksel SQL Server tekniklerini daha fazla ayarlayıp genişletmeye yönelik alanlar bulmak için veritabanı için kullanılan kaynakları inceleyebilirsiniz.

Eksik dizinleri tanımlama ve ekleme

OLTP veritabanı performansındaki yaygın bir sorun, fiziksel veritabanı tasarımıyla ilgilidir. Genellikle veritabanı şemaları büyük ölçekte test edilmeden (yük veya veri hacminde) tasarlanır ve gönderilir. Ne yazık ki sorgu planının performansı küçük ölçekte kabul edilebilir ancak üretim düzeyindeki veri hacimleri altında önemli ölçüde düşebilir. Bu sorunun en yaygın kaynağı, bir sorgudaki filtreleri veya diğer kısıtlamaları karşılamak için uygun dizinlerin olmamasıdır. Genellikle eksik dizinler, bir dizin araması yeterli olduğunda tablo taraması olarak bildirimde bulunur.

Bu örnekte, seçilen sorgu planı bir arama yeterli olduğunda tarama kullanır:

DROP TABLE dbo.missingindex;
CREATE TABLE dbo.missingindex (col1 INT IDENTITY PRIMARY KEY, col2 INT);
DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
    WHILE @a < 20000
    BEGIN
        INSERT INTO dbo.missingindex(col2) VALUES (@a);
        SET @a += 1;
    END
    COMMIT TRANSACTION;
    GO
SELECT m1.col1
    FROM dbo.missingindex m1 INNER JOIN dbo.missingindex m2 ON(m1.col1=m2.col1)
    WHERE m1.col2 = 4;

Eksik dizinleri olan bir sorgu planı

veritabanı ve Azure SQL Yönetilen Örneği Azure SQL, sık karşılaşılan eksik dizin koşullarını bulmanıza ve düzeltmenize yardımcı olabilir. Azure SQL Veritabanı'nda yerleşik olarak bulunan DMV'ler Azure SQL Yönetilen Örneği bir dizinin sorgu çalıştırma tahmini maliyetini önemli ölçüde azaltacağı sorgu derlemelerine bakar. Sorgu yürütme sırasında veritabanı altyapısı her sorgu planının ne sıklıkta yürütüldüğünü izler ve yürütülen sorgu planı ile dizinin bulunduğu hayal edilen plan arasındaki tahmini boşluğu izler. Bu DMV'leri kullanarak fiziksel veritabanı tasarımınızda yapılan değişikliklerin bir veritabanı ve gerçek iş yükü için genel iş yükü maliyetini artırabileceğini hızlıca tahmin edebilirsiniz.

Olası eksik dizinleri değerlendirmek için bu sorguyu kullanabilirsiniz:

SELECT
   CONVERT (varchar, getdate(), 126) AS runtime
   , mig.index_group_handle
   , mid.index_handle
   , CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact *
        (migs.user_seeks + migs.user_scans)) AS improvement_measure
   , 'CREATE INDEX missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' +
        CONVERT (varchar, mid.index_handle) + ' ON ' + mid.statement + '
        (' + ISNULL (mid.equality_columns,'')
        + CASE WHEN mid.equality_columns IS NOT NULL
        AND mid.inequality_columns IS NOT NULL
        THEN ',' ELSE '' END + ISNULL (mid.inequality_columns, '') + ')'
        + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement
   , migs.*
   , mid.database_id
   , mid.[object_id]
FROM sys.dm_db_missing_index_groups AS mig
   INNER JOIN sys.dm_db_missing_index_group_stats AS migs
      ON migs.group_handle = mig.index_group_handle
   INNER JOIN sys.dm_db_missing_index_details AS mid
      ON mig.index_handle = mid.index_handle
 ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

Bu örnekte sorgu şu öneriyle sonuçlandı:

CREATE INDEX missing_index_5006_5005 ON [dbo].[missingindex] ([col2])  

Oluşturulduktan sonra, aynı SELECT deyimi tarama yerine arama kullanan farklı bir plan seçer ve ardından planı daha verimli bir şekilde yürütür:

Düzeltilmiş dizinlere sahip bir sorgu planı

Önemli içgörü, paylaşılan bir ticari sistemin GÇ kapasitesinin ayrılmış bir sunucu makinesinden daha sınırlı olmasıdır. Hizmet katmanlarının her işlem boyutundaki kaynaklarda sistemden en üst düzeyde yararlanmak için gereksiz GÇ'yi en aza indirmeye yönelik bir premium vardır. Uygun fiziksel veritabanı tasarım seçimleri tek tek sorgular için gecikme süresini önemli ölçüde artırabilir, ölçek birimi başına işlenen eşzamanlı isteklerin aktarım hızını artırabilir ve sorguyu karşılamak için gereken maliyetleri en aza indirir.

Eksik dizin isteklerini kullanarak dizinleri ayarlama hakkında daha fazla bilgi için bkz . Eksik dizin önerileriyle kümelenmemiş dizinleri ayarlama.

Sorgu ayarlama ve ipuçları

Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği'daki sorgu iyileştiricisi, geleneksel SQL Server sorgu iyileştiricisine benzer. Sorguları ayarlamaya ve sorgu iyileştiricisinin neden modeli sınırlamalarını anlamaya yönelik en iyi yöntemlerin çoğu Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği için de geçerlidir. Azure SQL Veritabanı'nda ve Azure SQL Yönetilen Örneği sorguları ayarlarsanız, toplam kaynak taleplerini azaltmanın ek avantajını elde edebilirsiniz. Uygulamanız daha düşük bir işlem boyutunda çalışabildiğinden ayarlanmamış eşdeğerden daha düşük bir maliyetle çalışabilir.

SQL Server'de yaygın olan ve Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği için de geçerli olan bir örnek, sorgu iyileştiricisinin parametreleri nasıl "kokladığıdır." Derleme sırasında sorgu iyileştiricisi bir parametrenin geçerli değerini değerlendirerek daha uygun bir sorgu planı oluşturup oluşturamayacağını belirler. Bu strateji genellikle bilinen parametre değerleri olmadan derlenen bir plandan önemli ölçüde daha hızlı bir sorgu planına yol açsa da, şu anda hem SQL Server hem de Azure SQL Veritabanında ve Azure SQL Yönetilen Örneği'de kusursuz bir şekilde çalışır. Bazen parametre koklanmaz ve bazen parametre koklanır, ancak oluşturulan plan bir iş yükündeki parametre değerlerinin tamamı için en iyi durumda değildir. Microsoft, amacı daha bilinçli olarak belirtebilmeniz ve parametre algılamanın varsayılan davranışını geçersiz kılabilmeniz için sorgu ipuçları (yönergeler) içerir. İpuçları kullanıyorsanız genellikle varsayılan SQL Server, veritabanı Azure SQL ve Azure SQL Yönetilen Örneği davranışının belirli bir müşteri iş yükü için kusurlu olduğu durumları düzeltebilirsiniz.

Sonraki örnekte, sorgu işlemcisinin hem performans hem de kaynak gereksinimleri için en iyi olmayan bir planı nasıl oluşturabileceği gösterilmektedir. Bu örnekte, sorgu ipucu kullanırsanız veritabanınız için sorgu çalışma süresini ve kaynak gereksinimlerini azaltabileceğiniz de gösterilir:

DROP TABLE psptest1;
CREATE TABLE psptest1(col1 int primary key identity, col2 int, col3 binary(200));
DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
   WHILE @a < 20000
   BEGIN
     INSERT INTO psptest1(col2) values (1);
     INSERT INTO psptest1(col2) values (@a);
     SET @a += 1;
   END
   COMMIT TRANSACTION
   CREATE INDEX i1 on psptest1(col2);
GO

CREATE PROCEDURE psp1 (@param1 int)
   AS
   BEGIN
      INSERT INTO t1 SELECT * FROM psptest1
      WHERE col2 = @param1
      ORDER BY col2;
    END
    GO

CREATE PROCEDURE psp2 (@param2 int)
   AS
   BEGIN
      INSERT INTO t1 SELECT * FROM psptest1 WHERE col2 = @param2
      ORDER BY col2
      OPTION (OPTIMIZE FOR (@param2 UNKNOWN))
   END
   GO

CREATE TABLE t1 (col1 int primary key, col2 int, col3 binary(200));
GO

Kurulum kodu, veri dağıtımı dengesiz olan bir tablo oluşturur. En uygun sorgu planı, seçilen parametreye göre farklılık gösterir. Ne yazık ki plan önbelleğe alma davranışı her zaman sorguyu en yaygın parametre değerine göre yeniden derlemez. Bu nedenle, farklı bir plan ortalama olarak daha iyi bir plan seçeneği olsa bile, en iyi olmayan bir planın önbelleğe alınması ve birçok değer için kullanılması mümkündür. Ardından sorgu planı, özel bir sorgu ipucuna sahip olması dışında, aynı olan iki saklı yordam oluşturur.

-- Prime Procedure Cache with scan plan
EXEC psp1 @param1=1;
TRUNCATE TABLE t1;

-- Iterate multiple times to show the performance difference
DECLARE @i int = 0;
WHILE @i < 1000
   BEGIN
      EXEC psp1 @param1=2;
      TRUNCATE TABLE t1;
      SET @i += 1;
    END

Elde edilen telemetri verilerinde sonuçların ayrı olması için, örneğin 2. bölümüne başlamadan önce en az 10 dakika beklemenizi öneririz.

EXEC psp2 @param2=1;
TRUNCATE TABLE t1;

DECLARE @i int = 0;
    WHILE @i < 1000
    BEGIN
        EXEC psp2 @param2=2;
        TRUNCATE TABLE t1;
        SET @i += 1;
    END

Bu örneğin her bölümü, parametreli insert deyimini 1.000 kez çalıştırmayı dener (test veri kümesi olarak kullanmak için yeterli yük oluşturmak için). Saklı yordamları yürütürken, sorgu işlemcisi ilk derlemesi sırasında yordama geçirilen parametre değerini ("koklama" parametresi) inceler. İşlemci, sonuçta elde edilen planı önbelleğe alır ve parametre değeri farklı olsa bile daha sonraki çağrılar için kullanır. En uygun plan her durumda kullanılamayabilir. Bazen iyileştiriciye, sorgunun ilk derlendiği zamandaki büyük/küçük harf yerine ortalama büyük/küçük harf için daha iyi bir plan seçmesi için yol göstermeniz gerekir. Bu örnekte, ilk plan parametresiyle eşleşen her değeri bulmak için tüm satırları okuyan bir "tarama" planı oluşturur:

Tarama planı kullanarak sorgu ayarlama

Yordamı 1 değerini kullanarak yürüttüğünden, sonuçta elde edilen plan 1 değeri için en uygun olandı, ancak tablodaki diğer tüm değerler için en iyi durumdaydı. Plan daha yavaş çalıştığından ve daha fazla kaynak kullandığından, her planı rastgele seçmek istediğiniz sonuç büyük olasılıkla bu değildir.

testi SET STATISTICS IO olarak ayarlanmış olarak ONçalıştırırsanız, bu örnekteki mantıksal tarama işi arka planda yapılır. Plan tarafından 1.148 okuma yapıldığını görebilirsiniz (ortalama bir satır döndürülecekse verimsizdir):

Mantıksal tarama kullanarak sorgu ayarlama

Örneğin ikinci bölümü, iyileştiriciye derleme işlemi sırasında belirli bir değeri kullanmasını bildirmek için bir sorgu ipucu kullanır. Bu durumda, sorgu işlemcisini parametresi olarak geçirilen değeri yoksaymaya ve bunun yerine varsaymaya UNKNOWNzorlar. Bu, tabloda ortalama sıklığı olan bir değere başvurur (dengesizliği yoksayma). Sonuçta elde edilen plan, bu örneğin 1. bölümündeki plandan daha hızlı olan ve ortalama olarak daha az kaynak kullanan arama tabanlı bir plandır:

Sorgu ipucu kullanarak sorgu ayarlama

etkisini sys.resource_stats tablosunda görebilirsiniz (testi yürütmeniz ve verilerin tabloyu doldurması arasında bir gecikme vardır). Bu örnekte, bölüm 1 22:25:00 zaman penceresi sırasında yürütülür ve 2. bölüm 22:35:00'da yürütülür. Önceki zaman penceresinde, bu zaman penceresinde daha sonrakine göre daha fazla kaynak kullanıldı (plan verimliliği geliştirmeleri nedeniyle).

SELECT TOP 1000 *
FROM sys.resource_stats
WHERE database_name = 'resource1'
ORDER BY start_time DESC

Sorgu ayarlama örneği sonuçları

Not

Bu örnekteki birim kasıtlı olarak küçük olsa da, özellikle büyük veritabanlarında yetersiz parametrelerin etkisi önemli olabilir. Aşırı durumlarda fark, hızlı vakalar için saniyeler ve yavaş vakalar için saatler arasında olabilir.

Sys.resource_stats inceleyerek testin kaynağının başka bir testten daha fazla veya daha az kaynak kullanıp kullanmadığını belirleyebilirsiniz. Verileri karşılaştırdığınızda, testlerin zamanlamasını sys.resource_stats görünümünde aynı 5 dakikalık pencerede olmayacak şekilde ayırın. Alıştırmanın amacı, kullanılan toplam kaynak miktarını en aza indirmek ve en yoğun kaynakları en aza indirmemektir. Genellikle, bir kod parçasını gecikme süresi için en iyi duruma getirmek kaynak tüketimini de azaltır. Uygulamada yaptığınız değişikliklerin gerekli olduğundan ve değişikliklerin uygulamada sorgu ipuçlarını kullanıyor olabilecek birinin müşteri deneyimini olumsuz etkilemediğinden emin olun.

Bir iş yükünde yinelenen sorgular kümesi varsa, veritabanını barındırmak için gereken en düşük kaynak boyutu birimini yönlendirdiğinden genellikle plan seçimlerinizin en uygun düzeyini yakalayıp doğrulamak mantıklıdır. Doğruladıktan sonra, zaman zaman planların düzeyi düşürülmediğinden emin olmanıza yardımcı olacak planları yeniden gözden geçirebilirsiniz. Sorgu ipuçları (Transact-SQL) hakkında daha fazla bilgi edinebilirsiniz.

Çok büyük veritabanı mimarileri

Azure SQL Veritabanı'ndaki tek veritabanları için Hiper Ölçek hizmet katmanı yayımlanmadan önce müşteriler, tek tek veritabanları için kapasite sınırlarına isabet etmek için kullanılırlardı. Bu kapasite sınırları, Azure SQL Veritabanı elastik havuzlarındaki havuza alınan veritabanları ve Azure SQL Yönetilen Örnekler'deki örnek veritabanları için hala mevcuttur. Aşağıdaki iki bölümde, Azure SQL Veritabanı'ndaki çok büyük veritabanlarıyla ilgili sorunları çözmek için iki seçenek ve Hiper Ölçek hizmet katmanını kullanamadığınızda Azure SQL Yönetilen Örneği açıklanmıştır.

Veritabanları arası parçalama

Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği ticari donanım üzerinde çalıştığından, tek bir veritabanının kapasite sınırları geleneksel şirket içi SQL Server yüklemesinden daha düşüktür. Bazı müşteriler, işlemler Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği tek bir veritabanının sınırlarına uymadığında veritabanı işlemlerini birden çok veritabanına yaymak için parçalama tekniklerini kullanır. Azure SQL Veritabanı'nda parçalama tekniklerini kullanan ve Azure SQL Yönetilen Örneği verilerini tek bir boyutta birden çok veritabanına bölen müşterilerin çoğu. Bu yaklaşım için OLTP uygulamalarının genellikle şemadaki yalnızca bir satıra veya küçük bir satır grubuna uygulanan işlemler gerçekleştirdiğini anlamanız gerekir.

Not

Azure SQL Veritabanı artık parçalama konusunda yardımcı olacak bir kitaplık sağlar. Daha fazla bilgi için bkz . Elastik Veritabanı istemci kitaplığına genel bakış.

Örneğin, bir veritabanında müşteri adı, sipariş ve sipariş ayrıntıları varsa (SQL Server ile birlikte gelen geleneksel örnek Northwind veritabanı gibi), bir müşteriyi ilgili sipariş ve sipariş ayrıntı bilgileriyle gruplandırarak bu verileri birden çok veritabanına bölebilirsiniz. Müşterinin verilerinin tek bir veritabanında kalmasını garanti edebilirsiniz. Uygulama farklı müşterileri veritabanları arasında bölerek yükü birden çok veritabanına etkili bir şekilde yayacaktır. Parçalama sayesinde müşteriler veritabanı boyutu üst sınırının önüne geçmekle kalmaz, veritabanı ve Azure SQL Yönetilen Örneği Azure SQL her veritabanı kendi hizmet katmanı sınırlarına uyduğu sürece farklı işlem boyutlarının sınırlarından önemli ölçüde daha büyük iş yüklerini de işleyebilir.

Veritabanı parçalama, bir çözümün toplam kaynak kapasitesini azaltmasa da, birden çok veritabanına yayılan çok büyük çözümleri destekleme konusunda son derece etkilidir. Her veritabanı, yüksek kaynak gereksinimleri olan çok büyük ve "etkili" veritabanlarını desteklemek için farklı bir işlem boyutunda çalışabilir.

İşlevsel bölümleme

Kullanıcılar genellikle tek bir veritabanında birçok işlevi birleştirir. Örneğin, bir uygulamanın bir deponun envanterini yönetme mantığı varsa, bu veritabanının stok, satın alma siparişlerini izleme, saklı yordamlar ve ay sonu raporlamasını yöneten dizinlenmiş veya gerçekleştirilmiş görünümlerle ilişkili mantığı olabilir. Bu teknik, veritabanını yedekleme gibi işlemler için yönetmeyi kolaylaştırır, ancak bir uygulamanın tüm işlevlerinde en yüksek yükü işlemek için donanımı boyutlandırmanızı da gerektirir.

Azure SQL Veritabanı'nda ve Azure SQL Yönetilen Örneği ölçeği genişletme mimarisi kullanıyorsanız, bir uygulamanın farklı işlevlerini farklı veritabanlarına bölmek iyi bir fikirdir. Bu tekniği kullanarak her uygulama bağımsız olarak ölçeklendirilir. Bir uygulama daha yoğun hale geldikçe (ve veritabanındaki yük arttıkça), yönetici uygulamadaki her işlev için bağımsız işlem boyutlarını seçebilir. Bu mimari sayesinde yük birden çok makineye yayıldığı için bir uygulama tek bir ticari makinenin işleyebileceğinden daha büyük olabilir.

Batch sorguları

Yüksek hacimli, sık ve geçici sorgulama kullanarak verilere erişen uygulamalar için, uygulama katmanı ile veritabanı katmanı arasındaki ağ iletişimi için önemli miktarda yanıt süresi harcanıyor. Hem uygulama hem de veritabanı aynı veri merkezinde olsa bile, ikisi arasındaki ağ gecikme süresi çok sayıda veri erişim işlemiyle büyütülebilir. Veri erişim işlemleri için ağ gidiş dönüşlerini azaltmak için geçici sorguları toplu işleme veya bunları saklı yordamlar olarak derleme seçeneğini kullanmayı göz önünde bulundurun. Geçici sorguları toplu olarak oluşturursanız, veritabanına tek bir yolculukta birden çok sorguyu tek bir büyük toplu iş olarak gönderebilirsiniz. Saklı bir yordamda geçici sorgular derlerseniz, bunları toplu işlediğiniz gibi aynı sonucu elde edebilirsiniz. Saklı yordam kullanmak, saklı yordamı yeniden kullanabilmeniz için sorgu planlarını veritabanında önbelleğe alma olasılığını artırma avantajını da sağlar.

Bazı uygulamalar yoğun yazma gerektirir. Bazen toplu yazma işlemlerini birlikte kullanmayı göz önünde bulundurarak veritabanındaki toplam GÇ yükünü azaltabilirsiniz. Bu genellikle saklı yordamlarda ve geçici toplu işlemlerde otomatik işleme işlemleri yerine açık işlemleri kullanmak kadar basittir. Kullanabileceğiniz farklı tekniklerin değerlendirilmesi için bkz. Azure'da veritabanı uygulamaları için toplu işlem teknikleri. Toplu işlem için doğru modeli bulmak için kendi iş yükünüzü deneyin. Modelin biraz farklı işlem tutarlılığı garantilerine sahip olabileceğini anladığınızdan emin olun. Kaynak kullanımını en aza indiren doğru iş yükünü bulmak için tutarlılık ve performans dengelerinin doğru bileşimini bulmak gerekir.

Uygulama katmanı önbelleğe alma

Bazı veritabanı uygulamalarının yoğun okuma içeren iş yükleri vardır. Önbelleğe alma katmanları veritabanındaki yükü azaltabilir ve büyük olasılıkla Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği kullanarak veritabanını desteklemek için gereken işlem boyutunu azaltabilir. Redis için Azure Cache ile yoğun okuma içeren bir iş yükünüz varsa, verileri bir kez (veya nasıl yapılandırıldığına bağlı olarak uygulama katmanı makine başına bir kez) okuyabilir ve ardından bu verileri veritabanınızın dışında depolayabilirsiniz. Bu, veritabanı yükünü (CPU ve okuma GÇ) azaltmanın bir yoludur, ancak önbellekten okunan veriler veritabanındaki verilerle eşitlenmemiş olabileceğinden işlem tutarlılığı üzerinde bir etki vardır. Birçok uygulamada bazı tutarsızlık düzeyleri kabul edilebilir olsa da, bu tüm iş yükleri için geçerli değildir. Uygulama katmanı önbelleğe alma stratejisi uygulamadan önce tüm uygulama gereksinimlerini tam olarak anlamanız gerekir.

Yapılandırma ve tasarım ipuçlarını alma

Azure SQL Veritabanı kullanıyorsanız, Azure SQL DB'de veritabanı yapılandırmasını ve tasarımını geliştirmek için bir açık kaynak T-SQL betiği yürütebilirsiniz. Betik, veritabanınızı isteğe bağlı olarak analiz eder ve veritabanı performansını ve sistem durumunu geliştirmeye yönelik ipuçları sağlar. Bazı ipuçları en iyi yöntemlere göre yapılandırma ve işlem değişiklikleri önerirken, diğer ipuçları gelişmiş veritabanı altyapısı özelliklerini etkinleştirme gibi iş yükünüz için uygun tasarım değişiklikleri önerir.

Betik hakkında daha fazla bilgi edinmek ve kullanmaya başlamak için Azure SQL İpuçları wiki sayfasını ziyaret edin.

Sonraki adımlar