Yoğun elastik havuzlardaki kaynak yönetimi
ŞUNUN İÇİN GEÇERLİDİR: 
Azure SQL Database
Azure SQL Veritabanı havuzları, farklı kaynak kullanımına sahip birçok veritabanını yönetmek için uygun maliyetli bir çözümdür. Havuza yalnızca bir veritabanı alt kümesinin herhangi bir zamanda işlem kaynaklarını kullanabileceği varsayımı üzerine, bir elastik havuza sahip tüm veritabanları CPU, bellek, çalışan iş parçacıkları, depolama alanı, tempdb gibi kaynakların aynı ayırmasını paylaşır. Bu varsayım, elastik havuzların uygun maliyetli olması için izin verir. Müşteriler, her bir veritabanına gerekebilecek tüm kaynaklar için ödeme yapmak yerine havuza gelen tüm veritabanları arasında paylaşılan çok daha küçük bir kaynak kümesi için ödeme yapmak zorunda.
Kaynak idaresi
Kaynak paylaşımı, yüksek kaynak tüketimine sahip bir veritabanının aynı elastik havuz üzerindeki diğer veritabanlarını etkilediği "gürültülü komşu" etkisini en aza indirmek için sistemin kaynak kullanımını dikkatle denetlemesini gerektirir. Aynı zamanda, sistemin güvenilir bir şekilde çalışması için yüksek kullanılabilirlik ve olağanüstü durum kurtarma (HADR), yedekleme ve geri yükleme, izleme, Sorgu Deposu, Otomatik ayarlama vb. gibi özellikler için yeterli kaynak sağlamaları gerekir.
Azure SQL Veritabanı süreç düzeyi kaynak idaresi için Windows İş Nesneleri, depolama kota yönetimi için Windows Dosya Sunucusu Resource Manager (FSRM) ve üzerinde değişiklik yapılan ve genişletilmiş bir sürümü de dahil olmak üzere birden çok kaynak idare mekanizması kullanarak bu hedeflere SQL Server Resource Governor kaynak idaresi uygulama SQL Veritabanı.
Elastik havuzların birincil tasarım hedefi uygun maliyetli olmak. Bu nedenle sistem, müşterilerin kasıtlı olarak yoğun havuzlar oluşturmasına izin verir. Bu, veritabanı sayısına yaklaşan veya izin verilen en yüksek düzeyde olan ancak işlem kaynaklarının orta düzeyde ayırması gereken havuzlardır. Aynı nedenle, sistem iç işlemleri için ihtiyaç duyulabilecek tüm kaynakları korumaz, ancak iç işlemler ve kullanıcı iş yükleri arasında kaynak paylaşımına izin verir.
Bu yaklaşım müşterilerin yeterli performans ve önemli maliyet tasarrufları elde etmek için yoğun elastik havuzları kullanmalarına olanak sağlar. Ancak, yoğun bir havuzdaki birçok veritabanına karşı iş yükü yeterince yoğunsa, kaynak iddiası önemli hale gelir. Kaynak iddiası, kullanıcı iş yükü performansını azaltır ve iç işlemleri olumsuz etkileyebilir.
Önemli
Çok sayıda etkin veritabanı olan yoğun havuzlarda, havuza alınan veritabanı sayısını DTU ve sanal çekirdek elastik havuzları için belgelenmiş maksimum değere kadar artırmak uygun olabilir.
Kaynak ayrımlarına ve performans sorunlarına neden olmadan yoğun havuzlara yerleştirilemedik veritabanlarının sayısı, eşzamanlı olarak etkin veritabanlarının sayısına ve her veritabanındaki kullanıcı iş yüklerinin kaynak tüketimine bağlıdır. Bu sayı, kullanıcı iş yükleri değiştiklerinde zaman içinde değişebilir.
Buna ek olarak, veritabanı başına en az sanal çekirdek sayısı veya veritabanı başına en az DTA ayarı 0'dan büyük bir değere ayarlanırsa havuza yönelik en fazla veritabanı sayısı örtülü olarak sınırlanacak. Daha fazla bilgi için bkz. Havuza alınan sanal çekirdek veritabanları için veritabanı özellikleri ve havuza alınan DTU veritabanları için Veritabanı özellikleri.
Yoğun olarak paketlenmiş bir havuzda kaynak iddiası oluştuğunda, müşteriler bunu azaltmak için aşağıdaki eylemlerden birini veya daha fazlasını seçebilir:
- Kaynak tüketimini azaltmak veya zaman içinde kaynak tüketimini birden çok veritabanına yaymak için sorgu iş yükünü ayarlama.
- Bazı veritabanlarını başka bir havuza hareket ettirerek veya tek başına veritabanları yaparak havuz yoğunluğunu azaltabilirsiniz.
- Daha fazla kaynak elde etmek için havuzun ölçeğini ölçeklendirin.
Son iki eylemi uygulama hakkında öneriler için bu makalenin devamlarında yer alan İşlem önerileri makalesine bakın. Hem kullanıcı iş yüklerinin hem de iç işlemlerin kaynakla ilgili avantajlarını azaltmak, sistemin beklenen hizmet düzeyini güvenilir bir şekilde sürdürmesini sağlar.
Kaynak tüketimini izleme
Kaynak ayrımlarından dolayı performans düşüşlerini önlemek için, yoğun elastik havuzları kullanan müşterilerin kaynak tüketimini proaktif olarak izlemesi ve artan kaynak kullanımının iş yüklerini etkilemeye başladığı zaman içinde eyleme geçerek devamması gerekir. Kullanıcı iş yükünde yapılan değişiklikler, veri hacimleri ve dağıtım değişiklikleri, havuz yoğunluğu değişiklikleri ve hizmette yapılan değişiklikler nedeniyle havuzdaki kaynak kullanımı zaman içinde değişti Azure SQL Veritabanı önemlidir.
Azure SQL Veritabanı izleme türüyle ilgili çeşitli ölçümler sağlar. Her ölçüm için önerilen ortalama değerin aşılır olması, havuzda kaynak ayrımı olduğunu gösterir ve daha önce bahsedilen eylemlerden biri kullanılarak ele alınamaz.
| Ölçüm adı | Description | Önerilen ortalama değer |
|---|---|---|
avg_instance_cpu_percent |
Temel işletim sistemi SQL olarak bir elastik havuzla ilişkili işlemde cpu kullanımı. Her veritabanında sys.dm_db_resource_stats görünümde ve veritabanındaki sys.elastic_pool_resource_stats görünümünde master kullanılabilir. Bu ölçüm aynı zamanda Azure İzleyici, burada olarak da ifade edilir ve bu sqlserver_process_core_percent ölçümler Azure portal. Bu değer, aynı elastik havuza sahip her veritabanı için aynıdır. |
%70'in altında. Arada sırada %90'a varan kısa ani artışlar kabul edilebilir. |
max_worker_percent |
Çalışan iş parçacığı kullanımı. Havuza ve havuza göre her veritabanı için sağlanır. Veritabanı düzeyinde çalışan iş parçacığı sayısı için farklı sınırlar vardır ve havuz düzeyinde bu ölçümün her iki düzeyde de izlenmesi önerilir. Her veritabanında sys.dm_db_resource_stats görünümde ve veritabanındaki sys.elastic_pool_resource_stats görünümünde master kullanılabilir. Bu ölçüm aynı zamanda Azure İzleyici, burada olarak da ifade edilir ve bu workers_percent ölçümler Azure portal. |
%80'in altında. %100'e kadar olan ani artışlar bağlantı denemeleri ve sorguların başarısız olmasına neden olur. |
avg_data_io_percent |
Okuma ve yazma fiziksel IO için IOPS kullanımı. Havuza ve havuza göre her veritabanı için sağlanır. Veritabanı düzeyinde IOPS sayısı için farklı sınırlar vardır ve havuz düzeyinde bu ölçümün her iki düzeyde de izlenmesi önerilir. Her veritabanında sys.dm_db_resource_stats görünümde ve veritabanındaki sys.elastic_pool_resource_stats görünümünde master kullanılabilir. Bu ölçüm aynı zamanda Azure İzleyici, burada olarak da ifade edilir ve bu physical_data_read_percent ölçümler Azure portal. |
%80'in altında. Bazen %100'e kadar olan kısa ani artışlar kabul edilebilir. |
avg_log_write_percent |
İşlem günlüğü yazma G/S için aktarım hızı kullanımları. Havuza ve havuza göre her veritabanı için sağlanır. Veritabanı düzeyinde günlük aktarım hızı için farklı sınırlar vardır ve havuz düzeyinde bu ölçümün her iki düzeyde de izlenmesi önerilir. Her veritabanında sys.dm_db_resource_stats görünümde ve veritabanındaki sys.elastic_pool_resource_stats görünümünde master kullanılabilir. Bu ölçüm aynı zamanda Azure İzleyici, burada olarak da ifade edilir ve bu log_write_percent ölçümler Azure portal. Bu ölçüm %100'e yakın olduğunda, tüm veritabanı değişiklikleri (INSERT, UPDATE, DELETE, MERGE deyimleri, SELECT ... INTO, BULK INSERT vb.) daha yavaş olacaktır. |
%90'ın altında. Bazen %100'e kadar olan kısa ani artışlar kabul edilebilir. |
oom_per_second |
Elastik havuzda bellek yetersiz (OOM) hatalarının hızı, bellek baskısı göstergesidir. Sys.dm_resource_governor_resource_pools_history_ex kullanılabilir. Bu ölçümü hesaplamak için örnek sorgu örneklerine bakın. | 0 |
avg_storage_percent |
Elastik havuz içindeki tüm veritabanlarında bulunan veriler tarafından kullanılan toplam depolama alanı. Veritabanı dosyalarına boş alan dahil değildir. Veritabanındaki sys.elastic_pool_resource_stats görünümünde master kullanılabilir. Bu ölçüm aynı zamanda Azure İzleyici, burada olarak da ifade edilir ve bu storage_percent ölçümler Azure portal. |
%80'in altında. Veri büyümesine gerek yoktur ve havuzlar için %100'e yaklaşabilirsiniz. |
avg_allocated_storage_percent |
Elastik havuz içindeki tüm veritabanlarında bulunan depolamadaki veritabanı dosyaları tarafından kullanılan toplam depolama alanı. Veritabanı dosyalarına boş alan içerir. Veritabanındaki sys.elastic_pool_resource_stats görünümünde master kullanılabilir. Bu ölçüm aynı zamanda Azure İzleyici, burada olarak da ifade edilir ve bu allocated_data_storage_percent ölçümler Azure portal. |
%90'ın altında. Veri büyümesine gerek yoktur ve havuzlar için %100'e yaklaşabilirsiniz. |
tempdb_log_used_percent |
Veritabanında işlem günlüğü alanı tempdb kullanımı. Bir veritabanında oluşturulan geçici nesneler aynı elastik havuzdaki diğer veritabanlarında görünmese de, aynı havuzdaki tüm veritabanları tempdb için paylaşılan bir kaynaktır. Havuza bir veritabanından başlayan uzun süre çalışan veya yalnız kalan bir işlem, işlem günlüğünün büyük bir bölümünü kullanabilir ve aynı havuza sahip diğer veritabanlarında sorgular için hatalara tempdb neden olabilir. Veri ve sys.dm_db_log_space_usage sys.database_files türetilen. Bu ölçüm aynı zamanda Azure İzleyici olarak da yalıtarak Azure portal. Bu ölçümün geçerli değerini geri almak için örnek sorgu örneklerine bakın. |
%50'nin altında. %80'e varan ani artışlar kabul edilebilir. |
Azure SQL Veritabanı, bu ölçümlere ek olarak gerçek kaynak idare sınırlarını döndüren bir görünüm ve kaynak havuzu düzeyinde ve iş yükü grubu düzeyinde kaynak kullanım istatistikleri döndüren ek görünümler sağlar.
| Görünüm adı | Description |
|---|---|
| sys.dm_user_db_resource_governance | Geçerli veritabanı veya elastik havuz içinde kaynak idare mekanizmaları tarafından kullanılan gerçek yapılandırma ve kapasite ayarlarını döndürür. |
| sys.dm_resource_governor_resource_pools | Geçerli kaynak havuzu durumu, kaynak havuzlarının geçerli yapılandırması ve kümülatif kaynak havuzu istatistikleri hakkında bilgi döndürür. |
| sys.dm_resource_governor_workload_groups | Birikmeli iş yükü grubu istatistiklerini ve iş yükü grubunun geçerli yapılandırmasını döndürür. Bu görünüm, kaynak havuzu sys.dm_resource_governor_resource_pools için pool_id sütundaki verilerle bir araya kullanılabilir. |
| sys.dm_resource_governor_resource_pools_history_ex | Son 32 dakika boyunca kaynak havuzu kullanım istatistiklerini döndürür. Her satır 20 saniyelik bir aralığı temsil eder. delta_Sütunlar, Aralık sırasında her istatistikteki değişikliği döndürür. |
| sys.dm_resource_governor_workload_groups_history_ex | Son 32 dakika için iş yükü grubu kullanım istatistiklerini döndürür. Her satır 20 saniyelik bir aralığı temsil eder. delta_Sütunlar, Aralık sırasında her istatistikteki değişikliği döndürür. |
İpucu
Bu ve diğer dinamik yönetim görünümlerini Sunucu Yöneticisi dışında bir asıl kullanarak sorgulamak için, bu sorumluyu ##MS_ServerStateReader## sunucu rolüneekleyin.
Bu görünümler, kaynak kullanımını izlemek ve neredeyse gerçek zamanlı kaynak çekişmesini gidermek için kullanılabilir. Coğrafi çoğaltmalar dahil olmak üzere birincil ve okunabilir ikincil çoğaltmalarda Kullanıcı iş yükü, SloSharedPool1 UserPrimaryGroup.DBId[N] N veritabanı kimliği değerini temsil eden kaynak havuzu ve iş yükü grubu olarak sınıflandırılmaktadır.
Güncel kaynak kullanımını izlemenin yanı sıra, yoğun havuzlar kullanan müşteriler geçmiş kaynak kullanımı verilerini ayrı bir veri deposunda koruyabilir. Bu veriler, kaynak kullanımını geçmiş ve dönemsel eğilimler temelinde proaktif olarak yönetmek için tahmine dayalı çözümlemede kullanılabilir.
İşletimsel öneriler
Yeterli kaynak headodsını bırakın. Kaynak Çekişmesi ve performans düşüşü gerçekleşirse, risk azaltma, bazı veritabanlarının etkilenen elastik havuzdan dışına taşınmasını veya daha önce belirtildiği gibi havuzu ölçeklendirmesini gerektirebilir. Ancak, bu eylemler için ek işlem kaynaklarının tamamlanmasını gerekir. özellikle, Premium ve İş Açısından Kritik havuzları için, bu eylemler taşınmakta olan veritabanları için tüm verilerin veya havuzun ölçeği azaltılsa, elastik havuzdaki tüm veritabanları için aktarılmasını gerektirir. Veri aktarımı, uzun süre çalışan ve Kaynak yoğunluklu bir işlemdir. Havuz zaten yüksek kaynak baskısı altındaysa, Azaltýcý işlem performansı daha da düşürebilir. Olağanüstü durumlarda, gerekli kaynaklar kullanılamadığından veritabanı taşıma veya havuz ölçeği aracılığıyla kaynak çekişmesini çözümlemek mümkün olmayabilir. Bu durumda, etkilenen elastik havuzdaki sorgu iş yükünü geçici olarak düşürmek tek çözüm olabilir.
Yoğun havuzlar kullanan müşteriler, daha önce açıklandığı gibi kaynak kullanımı eğilimlerini yakından izlemelidir ve ölçümler önerilen aralıklar dahilinde kaldığı ve elastik havuzda yeterli kaynak olduğundan, bu işlemleri azaltma işlemi gerçekleştirin.
Kaynak kullanımı, her bir veritabanı ve elastik havuz için zaman içinde değişen birden çok etkene bağlıdır. Yoğun havuzlardaki en iyi fiyat/performans oranının sağlanması sürekli izleme ve yeniden dengeleme gerektirir, bu da veritabanlarını daha fazla kullanılan havuzlardan daha az kullanılan havuzlara taşıyor ve artan iş yükünü karşılamak için gereken yeni havuzlar oluşturuyor.
"Sık erişimli" veritabanlarını taşımayın. Havuz düzeyindeki kaynak çekişmesinin birincil olarak az sayıda çok kullanılan veritabanı olması nedeniyle, bu veritabanlarını daha az kullanılan bir havuza taşımak veya tek başına veritabanları yapmak mümkündür. Ancak, bunun yapılması, bir veritabanı yüksek düzeyde kullanılabilir kaldığı sürece bunu yapmanız önerilmez, çünkü taşıma işlemi, hem veritabanı hem de tüm havuz için performansı düşürür. Bunun yerine, yüksek kullanım alt taraflarına kadar bekleyin veya havuz düzeyinde kaynak basıncını sağlamak yerine daha az kullanılan veritabanlarını taşıyın. Ancak, çok düşük kullanımı olan veritabanlarının taşınması, havuz düzeyinde kaynak kullanımını önemli ölçüde azalmadığından, bu durumda herhangi bir avantaj sağlamaz.
"Karantina" havuzunda yeni veritabanları oluşturun. Veritabanı başına kiracı modeli kullanan uygulamalar gibi, sıklıkla yeni veritabanlarının oluşturulduğu senaryolarda, mevcut bir elastik havuza yerleştirilmiş yeni bir veritabanının beklenmedik şekilde önemli kaynakları tüketmesi ve havuzdaki diğer veritabanlarını ve iç süreçlerini etkilemesi gerekir. Bu riski azaltmak için, kaynakların çok fazla ayrılması ile ayrı bir "Karantina" havuzu oluşturun. Henüz bilinmeyen kaynak tüketim desenleriyle bu havuzu yeni veritabanları için kullanın. Bir veritabanı, hafta veya ay gibi bir iş çevrimi için bu havuzda bir kez daha olduğunda ve kaynak tüketimi bilindiğinde, bu ek kaynak kullanımına uyum sağlamak için yeterli kapasiteye sahip bir havuza taşınabilir.
Kullanılan ve ayrılan alanı izleyin. Ayrılmış havuz alanı (bir havuzdaki tüm veritabanları için depolamada bulunan tüm veritabanı dosyalarının toplam boyutu) en yüksek havuz boyutuna ulaşırsa, boş alan hataları oluşabilir. Ayrılan alan eğilimleri yüksekse ve en büyük havuz boyutuna ulaşmak için izse, risk azaltma seçenekleri şunlardır:
- Toplam ayrılan alanı azaltmak için bazı veritabanlarını havuzdan dışarı taşıyın
- Dosyalardaki boş ayrılmış alanı azaltmak için veritabanı dosyalarını küçültün
- Havuzun boyutunu daha büyük olan en büyük havuz boyutuyla bir hizmet hedefine ölçeklendirin
Kullanılan havuz alanı (bir havuzdaki tüm veritabanlarındaki toplam veri boyutu) eğilimleri yüksek ve en büyük havuz boyutuna ulaşmak için izlerse, azaltma seçenekleri şunlardır:
- Toplam kullanılan alanı azaltmak için bazı veritabanlarını havuza taşıyın
- Verileri veritabanının dışına taşı veya artık gerekli olmayan verileri Sil
- Veri sıkıştırmayı Uygula
- Havuzun boyutunu daha büyük olan en büyük havuz boyutuyla bir hizmet hedefine ölçeklendirin
Aşırı yoğun sunuculardan kaçının. Azure SQL Veritabanı sunucu başına en fazla 5000 veritabanını destekler . Binlerce veritabanı içeren elastik havuzlar kullanan müşteriler, tek bir sunucuya birden çok elastik havuz yerleştirmeyi göz önünde bulundurarak desteklenen sınıra kadar toplam veritabanı sayısına sahip olabilir. Ancak, binlerce veritabanına sahip sunucular işlemsel zorluk oluşturur. Bir sunucudaki tüm veritabanlarının (örneğin, portaldaki veritabanlarını görüntüleme) listelenmesi gereken işlemler daha yavaş olacaktır. Sunucu düzeyinde oturum açma işlemleri veya güvenlik duvarı kuralları için yanlış değişiklik gibi işletimsel hatalar, daha fazla sayıda veritabanını etkileyecektir. Sunucu yanlışlıkla silinmesinin, silinen sunucuda veritabanlarını kurtarmak için Microsoft Desteği 'den yardım gerekir ve etkilenen tüm veritabanları için uzun sürmemiş bir kesinti oluşmasına neden olur.
Sunucu başına veritabanı sayısı ' nı desteklenen en yüksek sayıdan daha düşük bir sayıya sınırlamak önerilir. Birçok senaryoda, sunucu başına en fazla 1000-2000 veritabanı kullanılması idealdir. Yanlışlıkla sunucu silme olasılığını azaltmak için sunucuya veya kaynak grubuna bir silme kilidi koyun.
Örnekler
Bellek kullanımını izleme
Bu sorgu oom_per_second , son 32 dakika içinde her kaynak havuzu için ölçüyü hesaplar. Bu sorgu, elastik havuzdaki herhangi bir veritabanında yürütülebilir.
SELECT pool_id,
name AS resource_pool_name,
IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;
tempdbGünlük alanı kullanımını izleme
Bu sorgu tempdb_log_used_percent , tempdb işlem günlüğünün izin verilen en büyük boyutuna göre göreli kullanımını gösteren ölçümün geçerli değerini döndürür. Bu sorgu, elastik havuzdaki herhangi bir veritabanında yürütülebilir.
SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
FROM tempdb.sys.database_files
WHERE type_desc = N'LOG'
) AS df
;
Sonraki adımlar
- elastik havuzlara giriş için bkz. elastik havuzlar, Azure SQL Veritabanı birden çok veritabanını yönetmenize ve ölçeklendirmenize yardımcı olur.
- Kaynak kullanımını azaltmak üzere sorgu iş yüklerini ayarlama hakkında daha fazla bilgi için bkz. izleme ve ayarlama, izleme ve performans ayarlama.