Geçiş sonrası doğrulama ve iyileştirme kılavuzu

Şunlar için geçerlidir: SQL Server

Geçiş sonrası SQL Server adımı, veri doğruluğunu ve eksiksizliğini uzlaştırma ve iş yüküyle ilgili performans sorunlarını ortaya çıkarma açısından çok önemlidir.

Yaygın performans senaryoları

SQL Server Platformu'na geçiş sonrasında karşılaşılan yaygın performans senaryolarından bazıları ve bunların nasıl çözümleneceği aşağıdadır. Bunlar SQL Server'dan SQL Server'a geçişe (eski sürümlerden daha yeni sürümlere) ve yabancı platforma (Oracle, DB2, MySQL ve Sybase gibi) SQL Server'a geçişe özgü senaryoları içerir.

Kardinalite tahmin aracı (CE) sürümündeki değişiklik nedeniyle sorgu regresyonları

Şunlar için geçerlidir: SQL Server'ı SQL Server'a geçirme.

SQL Server'ın eski bir sürümünden SQL Server 2014 (12.x) veya sonraki sürümlerine geçiş yaparken ve veritabanı uyumluluk düzeyini kullanılabilir en son sürüme yükseltirken, bir iş yükü performans gerileme riskiyle karşı karşıya kalabilir.

Bunun nedeni, SQL Server 2014 (12.x) ile başlayarak tüm Sorgu İyileştiricisi değişikliklerinin en son veritabanı uyumluluk düzeyine bağlı olmasıdır, bu nedenle planlar yükseltme sırasında değil, kullanıcı veritabanı seçeneğini en son sürüme değiştirdiğinde COMPATIBILITY_LEVEL değiştirilir. Bu özellik, Sorgu Deposu ile birlikte yükseltme işlemindeki sorgu performansı üzerinde büyük bir denetim düzeyi sağlar.

SQL Server 2014'te (12.x) kullanıma sunulan Sorgu İyileştirici değişiklikleri hakkında daha fazla bilgi için bkz. SQL Server 2014 Kardinalite Tahmin Aracı ile Sorgu Planlarınızı İyileştirme.

CE hakkında daha fazla bilgi için bkz . Kardinalite Tahmini (SQL Server).

Çözüm adımları

Veritabanı uyumluluk düzeyini kaynak sürümle değiştirin ve aşağıdaki resimde gösterildiği gibi önerilen yükseltme iş akışını izleyin:

Bu makale hakkında daha fazla bilgi için bkz. Daha yeni SQL Server'a yükseltme sırasında performans kararlılığını koruma.

Parametre algılamaya duyarlılık

Şunlar için geçerlidir: SQL Server geçişi için yabancı platform (Oracle, DB2, MySQL ve Sybase gibi).

Uyarı

SQL Server'ın SQL Server'a geçişlerinde, bu sorun kaynak SQL Server'da mevcutsa, SQL Server as-is'nin daha yeni bir sürümüne geçiş yapmak bu senaryoyu ele almaz.

SQL Server, ilk derlemede giriş parametrelerini koklayarak, bu giriş veri dağıtımı için iyileştirilmiş parametreli ve yeniden kullanılabilir bir plan oluşturarak saklı yordamlarda sorgu planlarını derler. Saklı yordamlar olmasa bile, önemsiz planlar oluşturan çoğu deyim parametreleştirilir. Bir plan ilk önbelleğe alındıktan sonra, gelecekteki tüm yürütmeler önceden önbelleğe alınmış bir plana eşler.

İlk derlemede her zamanki iş yükü için en yaygın parametre kümeleri kullanılmadığında olası bir sorun ortaya çıkar. Farklı parametreler için aynı yürütme planı verimsiz hale gelir. Bu makale hakkında daha fazla bilgi için bkz . Parametre duyarlılığı.

Çözüm adımları

1. İpucunu RECOMPILE kullanın. Her parametre değerine her uyarlandığında bir plan hesaplanır.

2. seçeneğini (OPTIMIZE FOR(<input parameter> = <value>))kullanmak için saklı yordamı yeniden yazın. Parametreli değer için verimli hale gelen bir plan oluşturup bakımını yaparak ilgili iş yükünün çoğuna uyan değerin hangi değeri kullanacağınıza karar verin.

3. Saklı yordamı, yordamın içindeki yerel değişkeni kullanarak yeniden yaz. İyileştirici şimdi tahminler için yoğunluk vektörü kullanır ve parametre değerinden bağımsız olarak aynı plana neden olur.

4. seçeneğini (OPTIMIZE FOR UNKNOWN)kullanmak için saklı yordamı yeniden yazın. Yerel değişken tekniğini kullanmakla aynı etki.

5. ipucunu DISABLE_PARAMETER_SNIFFINGkullanmak için sorguyu yeniden yazın. veya kullanılmadığı sürece OPTION(RECOMPILE)WITH RECOMPILEOPTIMIZE FOR <value> parametre algılamayı tamamen devre dışı bırakarak yerel değişken tekniğini kullanmakla aynı etki.

Tip

Bunun bir sorun olup olmadığını hızla belirlemek için Management Studio Plan Analizi özelliğini kullanın. Daha fazla bilgi için bkz . SSMS'de Yeni: Sorgu Performansı Sorunlarını Giderme kolaylaştırdı.

Eksik dizinler

Şunlar için geçerlidir: Yabancı platform (Oracle, DB2, MySQL ve Sybase gibi) ve SQL Server'ın SQL Server'a geçişi.

Yanlış veya eksik dizinler, ek bellek ve CPU'ların boşa harcanmasına neden olan ek G/Ç'ye neden olur. Bunun nedeni iş yükü profilinin değişmesi olabilir; örneğin, farklı önkoşullar kullanmak, mevcut dizin tasarımını geçersiz hale getirme. Düşük dizin oluşturma stratejisinin veya iş yükü profilindeki değişikliklerin kanıtı şunlardır:

• Yinelenen, yedekli, nadiren kullanılan ve tamamen kullanılmayan dizinleri arayın.
• Kullanılmayan dizinler ve güncelleştirmeler için özel bakım.

Çözüm adımları

1. Eksik Dizin başvuruları için grafik yürütme planını kullanın.

2. Veritabanı Altyapısı Ayarlama Danışmanı tarafından oluşturulan dizin oluşturma önerileri.

3. sys.dm_db_missing_index_details kullanın.

4. Mevcut DMV'leri kullanarak eksik, yinelenen, yedekli, nadiren kullanılan ve tamamen kullanılmayan dizinlere ilişkin içgörüler sağlamak için mevcut DMV'leri kullanabilen, ancak veritabanınızdaki mevcut yordamlara ve işlevlere herhangi bir dizin başvurusu ipucu verilip alınmadığını/sabit kodlandığını gösteren önceden var olan betikleri kullanın.

Tip

Bu tür önceden var olan betiklere örnek olarak Dizin Oluşturma ve Dizin Bilgileri verilebilir.

Verileri filtrelemek için koşul kullanamama

Şunlar için geçerlidir: Yabancı platform (Oracle, DB2, MySQL ve Sybase gibi) ve SQL Server'ın SQL Server'a geçişi.

Uyarı

SQL Server'ın SQL Server'a geçişlerinde, bu sorun kaynak SQL Server'da mevcutsa, SQL Server as-is'nin daha yeni bir sürümüne geçiş yapmak bu senaryoyu ele almaz.

SQL Server Sorgu İyileştiricisi yalnızca derleme zamanında bilinen bilgileri hesaba ekleyebilir. bir iş yükü yalnızca yürütme zamanında bilinebilecek koşullara dayanırsa, kötü bir plan seçimi olasılığı artar. Daha kaliteli bir plan için önkoşulların SARGable olması gerekir.

Uyarı

İlişkisel veritabanlarında SARGable terimi, sorgunun yürütülmesini hızlandırmak için bir dizin kullanabilen bir Search ARGbağımsız değişken koşulunu ifade eder. Daha fazla bilgi için bkz. SQL Server ve Azure SQL dizin mimarisi ve tasarım kılavuzu.

SARGable olmayan bazı koşul örnekleri:

• Varchar'ı nvarchar'a veya int'i varchar'a dönüştürme gibi örtük veri dönüştürmeleri. Fiili Yürütme Planları'nda çalışma zamanı CONVERT_IMPLICIT uyarılarını arayın. Bir türden diğerine dönüştürmek de duyarlık kaybına neden olabilir.

• gibi WHERE UnitPrice + 1 < 3.975karmaşık belirsiz ifadeler, ancak gibi değil WHERE UnitPrice < 320 * 200 * 32.

• veya gibi WHERE ABS(ProductID) = 771 işlevleri kullanan ifadeler WHERE UPPER(LastName) = 'Smith'

• başta joker karakter içeren dizeler, örneğin WHERE LastName LIKE '%Smith', ama değil WHERE LastName LIKE 'Smith%'.

Çözüm adımları

1. Değişkenleri/parametreleri her zaman hedef hedef Veri türleri olarak bildirin.

   Bu, veritabanında depolanan tüm kullanıcı tanımlı kod yapılarını (saklı yordamlar, kullanıcı tanımlı işlevler veya görünümler gibi) temel alınan tablolarda ( sys.columns gibi) kullanılan veri türleriyle ilgili bilgileri tutan sistem tablolarıyla karşılaştırmayı içerebilir.

2. Tüm kodu önceki noktaya geçiremezse, aynı amaçla tablodaki veri türünü değişken/parametre bildirimiyle eşleşecek şekilde değiştirin.

3. Aşağıdaki yapıların kullanışlılığının nedenini belirleyin:

   • Koşul olarak kullanılan işlevler;
   • Joker karakter aramaları;
   • Sütunlu verilere dayalı karmaşık ifadeler - bunun yerine dizine alınabilen kalıcı hesaplanan sütunlar oluşturma gereksinimini değerlendirin;

Uyarı

Bu adımların tümü program aracılığıyla yapılabilir.

Tablo değerli işlevlerin kullanımı (çoklu deyim ve satır içi)

Şunlar için geçerlidir: Yabancı platform (Oracle, DB2, MySQL ve Sybase gibi) ve SQL Server'ın SQL Server'a geçişi.

Uyarı

SQL Server'ın SQL Server'a geçişlerinde, bu sorun kaynak SQL Server'da mevcutsa, SQL Server as-is'nin daha yeni bir sürümüne geçiş yapmak bu senaryoyu ele almaz.

Tablo Değerli İşlevleri, görünümlere alternatif olabilecek bir tablo veri türü döndürür. Görünümler tek SELECT bir deyimle sınırlı olsa da, kullanıcı tanımlı işlevler görünümlerde mümkün olandan daha fazla mantığa izin veren ek deyimler içerebilir.

Çok deyimli tablo değerli işlevinin (MSTVF) çıkış tablosu derleme zamanında oluşturulmadığından, SQL Server Sorgu İyileştiricisi satır tahminlerini belirlemek için gerçek istatistikleri değil buluşsal yöntemleri kullanır.

Dizinler temel tablolara eklense bile, bu yardımcı olmayacaktır.

MSTVF'ler için, SQL Server bir MSTVF tarafından döndürülmesi beklenen satır sayısı için sabit 1 tahmini kullanır (SQL Server 2014(12.x) ile başlayarak sabit tahmin 100 satırdır).

Çözüm adımları

1. MSTVF yalnızca tek deyimliyse, satır içi tablo değerli bir işleve dönüştürün.

   CREATE FUNCTION dbo.tfnGetRecentAddress (@ID INT)
   RETURNS
       @tblAddress TABLE ([Address] VARCHAR (60) NOT NULL)
   AS
   BEGIN
       INSERT INTO @tblAddress ([Address])
       SELECT TOP 1 [AddressLine1]
       FROM [Person].[Address]
       WHERE AddressID = @ID
       ORDER BY [ModifiedDate] DESC;
       RETURN;
   END
   

   Satır içi biçim örneği daha sonra görüntülenir.

   CREATE FUNCTION dbo.tfnGetRecentAddress_inline
   (@ID INT)
   RETURNS TABLE
   AS
   RETURN
       (SELECT TOP 1 [AddressLine1] AS [Address]
        FROM [Person].[Address]
        WHERE AddressID = @ID
        ORDER BY [ModifiedDate] DESC)
   

2. Daha karmaşıksa, Memory-Optimized tablolarda veya geçici tablolarda depolanan ara sonuçları kullanmayı göz önünde bulundurun.

İlgili içerik

• Sorgu Deposu ile iş yüklerini izlemeye yönelik en iyi yöntemler
• In-Memory OLTP için Örnek Veritabanı
• Kullanıcı tanımlı işlevler
• Tablo Değişkenleri ve Satır Tahminleri - Bölüm 1
• Tablo Değişkenleri ve Satır Tahminleri - Bölüm 2
• Yürütme Planı Önbelleğe Alma ve Yeniden Kullanma