Veritabanı depolama alanını iyileştirme

Tamamlandı

Veritabanı depolama alanını iyileştirmek için orantılı dolgu ve tempdb yapılandırmasını göz önünde bulundurmanız gerekir.

G/Ç performansını anlama

G/Ç performansı bir veritabanı uygulamasında çok önemli olabilir. Azure SQL sizi fiziksel dosya yerleşiminden soyutlar, ancak ihtiyacınız olan G/Ç performansını elde ettiğinizden emin olmanız için çeşitli yöntemler vardır.

Saniye başına giriş/çıkış sayısı (IOPS), uygulamanız açısından önemli olabilir. IOPS gereksinimleriniz için doğru hizmet katmanını ve sanal çekirdekleri seçtiğinizden emin olun. Azure'a geçiş yaparsanız şirket içi sorgularınız için IOPS'yi ölçmeyi öğrenin. IOPS ile ilgili kısıtlamalarınız varsa uzun G/Ç bekleme süreleriyle karşılaşabilirsiniz. Sanal çekirdek satın alma modelinde sanal çekirdeklerin ölçeğini artırabilir veya yeterli IOPS'niz yoksa İş Açısından Kritik veya Hiper Ölçek'e geçebilirsiniz. Üretim iş yükleri için DTU kullanırken Premium katmanına geçmenizi öneririz.

G/Ç gecikmesi, G/Ç performansının diğer kilit bileşenlerinden biridir. Azure SQL Veritabanı'nda daha kısa bir G/Ç gecikmesi için İş Açısından Kritik veya Hiper Ölçek katmanını göz önünde bulundurun. SQL Yönetilen Örneği’nde daha kısa G/Ç gecikme süresi için, İş Açısından Kritik katmanına geçin veya veritabanının dosya boyutunu veya dosya sayısını artırın. İşlem günlüğü gecikme süresini iyileştirmek için çok durumlu işlemler kullanmanız gerekebilir.

Dosyalar ve dosya grupları

SQL Server uzmanları fiziksel dosya yerleşimi ile G/Ç performansını artırmak için genellikle dosya ve dosya gruplarını kullanır. Azure SQL, kullanıcıların dosyaları belirli disk sistemlerine yerleştirmesine izin vermez. Ancak Azure SQL'de ücretler, IOPS ve gecikme süreleriyle ilgili G/Ç performansı için kaynak taahhütleri vardır. Bu şekilde, kullanıcıyı fiziksel dosya yerleşiminden soyutlamak bir avantaj olabilir.

Azure SQL Veritabanı’nın tek bir veritabanı dosyası vardır (Hiper Ölçekte genellikle birkaç dosya olur) ve boyut üst sınırı Azure arabiriminden yapılandırılır. Daha fazla dosya oluşturma işlevi yoktur.

Azure SQL Yönetilen Örneği, veritabanı dosyaları eklemeyi ve boyutları yapılandırmayı destekler, ancak dosyaların fiziksel yerleşimini desteklemez. G/Ç performansını geliştirmek için SQL Yönetilen Örneği için dosya sayısını ve dosya boyutlarını kullanabilirsiniz. Buna ek olarak, yönetilebilirlik sağlamak amacıyla SQL Yönetilen Örneği için kullanıcı tanımlı dosya grupları desteklenir.

Orantılı dolguyu açıklama

İki veri dosyası içeren bir SQL Server veritabanına 1 gigabayt veri eklerken, her dosyanın yaklaşık 512 megabayt artmasını bekleyebilirsiniz. Ancak, her zaman böyle değildir. SQL Server, verileri her dosyanın boyutuna göre dağıtır. Örneğin, her iki veri dosyası da 2 gigabaytsa veriler eşit olarak dağıtılır. Ancak bir dosya 10 gigabayt, diğeri 1 gigabayt ise, yaklaşık 900 MB büyük dosyaya ve 100 MB daha küçük bir dosyaya gider. Bu davranış tüm veritabanlarında yaygındır, ancak yoğun yazma gerektiren tempdb'de düzensiz bir yazma düzeni, daha fazla yazma işlemi işlediğinden en büyük dosyada bir performans sorunu oluşturabilir.

SQL Server'da Tempdb'yi yapılandırma

SQL Server, kurulum sırasında kullanılabilir CPU sayısını algılar ve sekize kadar uygun dosya sayısını eşit boyutlandırmayla yapılandırır. Ayrıca, 1117 ve 1118 izleme bayraklarının davranışları veritabanı altyapısıyla tümleştirilir, ancak yalnızca için kullanılır tempdb. Tempdb ağır iş yükleri için tempdb dosyalarının sayısını sekizden fazla artırmak ve makinenizdeki CPU sayısıyla eşleştirmek yararlı olabilir.

Hem SQL Server hem de Azure SQL için aynı şekilde kullanırsınız tempdb . Ancak, dosyaların yerleşimi, dosyaların sayısı ve boyutu tempdb ve yapılandırma seçenekleri dahil olmak üzere yapılandırma tempdb yeteneğinizin farklı olduğunu unutmayın.

SQL Server, yalnızca kullanıcı tanımlı geçici tabloları depolamanın ötesinde çeşitli görevler için tempdb kullanır. Diğer amaçlarla birlikte ara sorgu sonuçlarını, sıralama işlemlerini ve satır sürümü oluşturma için sürüm deposunu depolayan iş tabloları için kullanılır. Bu kapsamlı kullanım nedeniyle tempdb'yi kullanılabilir en düşük gecikme süreli depolama alanına yerleştirmek ve veri dosyalarını düzgün bir şekilde yapılandırmak çok önemlidir.

veritabanı dosyaları tempdb her zaman yerel SSD sürücülerinde otomatik olarak depolanır, bu nedenle G/Ç performansı sorun oluşturmamalıdır.

SQL Server uzmanları genellikle tabloların ayırmalarını bölümlendirmek için tempdb birden fazla veritabanı dosyası kullanır. Azure SQL Veritabanı için dosya sayısı sanal çekirdek sayısıyla (örneğin, iki sanal çekirdek dört dosyaya eşittir) en fazla 16 olacak şekilde ölçeklendirilir. üzerinde T-SQL tempdbaracılığıyla dosya sayısı yapılandırılamaz, ancak dağıtım seçeneğini değiştirerek bunu yapılandırabilirsiniz. Boyut üst sınırı tempdb sanal çekirdek sayısı başına ölçeklendirilir. Sanal çekirdeklerden bağımsız olarak, SQL Yönetilen Örneği ile 12 dosya alırsınız.

Veritabanı seçeneği MIXED_PAGE_ALLOCATION KAPALI olarak ayarlanır ve AUTOGROW_ALL_FILES ON olarak ayarlanır. Bunu yapılandıramazsınız, ancak SQL Server'da olduğu gibi bunlar önerilen varsayılan değerlerdir.

tempdb SQL Server 2019'da kullanıma sunulan ve ağır mandal çekişmelerini azaltabilen meta veri iyileştirme özelliği şu anda Azure SQL Veritabanı veya Azure SQL Yönetilen Örneği'da sağlanmamaktadır.

Veritabanı yapılandırması

Genellikle T-SQL ALTER DATABASE ve ALTER DATABASE SCOPED CONFIGURATION deyimleriyle bir veritabanı yapılandırabilirsiniz. Performansa yönelik birçok yapılandırma seçeneği Azure SQL için kullanılabilir. SQL Server, Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği arasındaki farklar için ALTER DATABASE ve ALTER DATABASE SCOPED CONFIGURATION T-SQL başvurusuna başvurun.

Azure SQL Veritabanı'nda, veritabanınızın Azure hizmet düzeyi sözleşmelerini (SLA) karşılayabilmesini sağlayan varsayılan kurtarma modeli tam kurtarmadır. Bu, toplu işlemler için minimum günlüğe kaydetmenin, minimum günlüğe kaydetmeye izin verilen durumlar dışında tempdbdesteklenmediği anlamına gelir.

MAXDOP yapılandırması

Maksimum paralellik derecesi (MAXDOP), tek tek sorguların performansını etkileyebilir. SQL Server ve Azure SQL aynı şekilde işler MAXDOP . Daha MAXDOP yüksek bir değere ayarlandığında sorgu başına daha fazla paralel iş parçacığı kullanılır ve bu da sorgu yürütmeyi hızlandırıyor olabilir. Ancak bu artan paralellik, bellek baskısına neden olabilecek ve depolama performansını etkileyebilecek ek bellek kaynakları gerektirir. Örneğin, satır gruplarını bir sütun deposuna sıkıştırırken paralellik daha fazla bellek gerektirir ve bu da bellek baskısına ve satır grubu kırpmasına neden olabilir.

Buna karşılık, MAXDOP'un daha düşük bir değere ayarlanması bellek baskısını azaltabilir ve depolama sisteminin daha verimli bir şekilde çalışmasını sağlar. Bu, sınırlı bellek kaynaklarına veya yüksek depolama taleplerine sahip ortamlarda önemlidir. MAXDOP'yi dikkatlice yapılandırarak sorgu performansını ve depolama verimliliğini dengeleyerek hem CPU hem de depolama kaynaklarının en iyi şekilde kullanılmasını sağlayabilirsiniz.

MAXDOP’yi Azure SQL'de tıpkı SQL Server’dakine benzer şekilde aşağıdaki teknikleri kullanarak yapılandırabilirsiniz:

  • ALTER DATABASE SCOPED CONFIGURATION yapılandırmak MAXDOP için Azure SQL desteklenir.
  • "Maksimum paralellik derecesi" saklı yordamı sp_configure SQL Yönetilen Örneği için desteklenir.
  • MAXDOP sorgu ipuçları tam olarak desteklenir.
  • Resource Governor ile yapılandırma MAXDOP , SQL Yönetilen Örneği için desteklenir.