Yoğun elastik havuzlardaki kaynak yönetimi

  • Makale

Şunlar için geçerlidir:Azure SQL Veritabanı

Azure SQL Veritabanı elastik havuzlar, farklı kaynak kullanımına sahip birçok veritabanını yönetmek için uygun maliyetli bir çözümdür. Bir elastik havuzdaki tüm veritabanları, belirli bir anda yalnızca havuzdaki veritabanlarının bir alt kümesinin işlem kaynaklarını kullanacağı varsayımı üzerine CPU, bellek, çalışan iş parçacıkları, tempdbdepolama alanı gibi kaynakların aynı ayırmasını paylaşır. Bu varsayım, elastik havuzların uygun maliyetli olmasını sağlar. Müşteriler, her veritabanının ihtiyaç duyabileceği tüm kaynaklar için ödeme yerine havuzdaki tüm veritabanları arasında paylaşılan çok daha küçük bir kaynak kümesi için ödeme yapıyor.

Kaynak idaresi

Kaynak paylaşımı, yüksek kaynak tüketimine sahip bir veritabanının aynı elastik havuzdaki 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. Azure SQL Veritabanı kaynak idaresini uygulayarak bu hedeflere ulaşır. 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ğlaması gerekir.

Elastik havuzların birincil tasarım hedefi uygun maliyetli olmaktır. Bu nedenle sistem, müşterilerin kasıtlı olarak yoğun havuzlar oluşturmasına izin verir. Bu havuzlar, veritabanı sayısına yaklaşan veya izin verilen en yüksek düzeyde olan ancak işlem kaynaklarının orta düzeyde ayrılmasına sahip olan havuzlardır. Aynı nedenle sistem, iç işlemleri için gerekli olabilecek tüm kaynakları ayırmaz, ancak iç işlemler ile 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 kullanmasına olanak tanır. Ancak yoğun bir havuzdaki birçok veritabanına yönelik iş yükü yeterince yoğunsa kaynak çekişmesi önemli hale gelir. Kaynak çekişmesi 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, havuzdaki veritabanı sayısını DTU ve sanal çekirdek elastik havuzları için belgelenen maksimum değerlere kadar artırmak mümkün olmayabilir.

Kaynak çekişmesi ve performans sorunlarına neden olmadan yoğun havuzlara yerleştirilebilen veritabanlarının sayısı, eşzamanlı olarak etkin olan veritabanlarının sayısına ve her veritabanındaki kullanıcı iş yüklerinin kaynak tüketimine bağlıdır. Kullanıcı iş yükleri değiştikçe bu sayı zaman içinde değişebilir.

Ayrıca, veritabanı başına en az sanal çekirdek veya veritabanı başına en az DTU ayarı 0'dan büyük bir değere ayarlanırsa, havuzdaki en fazla veritabanı sayısı örtük olarak sınırlanır. 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 paketlenmiş bir havuzda kaynak çekişmesi 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 kaynak tüketimini zaman içinde birden çok veritabanına yaymak için sorgu iş yükünü ayarlayın.
  • Bazı veritabanlarını başka bir havuza taşıyarak veya bunları tek başına veritabanları yaparak havuz yoğunluğunun azaltılması.
  • Daha fazla kaynak almak için havuzun ölçeğini artırın.

Son iki eylemi uygulama hakkında öneriler için bu makalenin devamında yer alan operasyonel öneriler bölümüne bakın. Kaynak çekişmesini azaltmak hem kullanıcı iş yüklerine hem de iç işlemlere avantaj sağlar ve sistemin beklenen hizmet düzeyini güvenilir bir şekilde korumasını sağlar.

Kaynak tüketimini izleme

Kaynak çekişmesi nedeniyle performans düşüşünü önlemek için yoğun elastik havuz kullanan müşteriler kaynak tüketimini proaktif olarak izlemeli ve artan kaynak çekişmesi iş yüklerini etkilemeye başlarsa zamanında eyleme geçmelidir. Kullanıcı iş yükündeki değişiklikler, veri hacimlerindeki ve dağıtımdaki değişiklikler, havuz yoğunluğundaki değişiklikler ve Azure SQL Veritabanı hizmetindeki değişiklikler nedeniyle havuzdaki kaynak kullanımı zaman içinde değiştiğinden sürekli izleme önemlidir.

Azure SQL Veritabanı bu tür izleme için uygun çeşitli ölçümler sağlar. Her ölçüm için önerilen ortalama değerin aşılması havuzdaki kaynak çekişmesi olduğunu gösterir ve daha önce bahsedilen eylemlerden biri kullanılarak ele alınmalıdır.

Havuz kaynağı kullanımı (CPU, veri GÇ, günlük GÇ, çalışanlar vb.) eşiği aştığında uyarı göndermek için Azure portalı veya Add-AzMetricAlertRulev2 PowerShell cmdlet'i aracılığıyla uyarı oluşturmayı göz önünde bulundurun. Elastik havuzları izlerken, senaryonuzda gerekirse havuzdaki tek tek veritabanları için uyarılar oluşturmayı da göz önünde bulundurun. Elastik havuzları izlemeyle ilgili örnek bir senaryo için bkz. Çok kiracılı SaaS uygulamasında Azure SQL Veritabanı performansını izleme ve yönetme.

Ölçüm adı Açıklama Önerilen ortalama değer
avg_instance_cpu_percent Temel işletim sistemi tarafından ölçülen bir elastik havuzla ilişkili SQL işleminin CPU kullanımı. Her veritabanındaki sys.dm_db_resource_stats görünümünde ve veritabanındaki sys.elastic_pool_resource_stats görünümünde master kullanılabilir. Bu ölçüm, Azure İzleyici'ye de gönderilir; burada bu ölçüm adlandırılırsql_instance_cpu_percent ve Azure portalında görüntülenebilir. Bu değer, aynı elastik havuzdaki her veritabanı için aynıdır. %70'in altında. %90'a varan kısa ani artışlar kabul edilebilir olabilir.
max_worker_percent Çalışan iş parçacığı kullanımı. Havuzdaki her veritabanı ve havuzun kendisi için sağlanır. Veritabanı düzeyinde ve havuz düzeyinde çalışan iş parçacığı sayısı için farklı sınırlar vardır, bu nedenle bu ölçümün her iki düzeyde de izlenmesi önerilir. Her veritabanındaki sys.dm_db_resource_stats görünümünde ve veritabanındaki sys.elastic_pool_resource_stats görünümünde master kullanılabilir. Bu ölçüm, Azure İzleyici'ye de gönderilir; burada bu ölçüm adlandırılırworkers_percent ve Azure portalında görüntülenebilir. %80'in altında. %100'e varan ani artışlar bağlantı girişimlerinin ve sorguların başarısız olmasına neden olur.
avg_data_io_percent Fiziksel GÇ okuma ve yazma için IOPS kullanımı. Havuzdaki her veritabanı ve havuzun kendisi için sağlanır. Veritabanı düzeyinde ve havuz düzeyinde IOPS sayısı için farklı sınırlar vardır, bu nedenle bu ölçümün her iki düzeyde de izlenmesi önerilir. Her veritabanındaki sys.dm_db_resource_stats görünümünde ve veritabanındaki sys.elastic_pool_resource_stats görünümünde master kullanılabilir. Bu ölçüm, Azure İzleyici'ye de gönderilir; burada bu ölçüm adlandırılırphysical_data_read_percent ve Azure portalında görüntülenebilir. %80'in altında. %100'e varan kısa ani artışlar kabul edilebilir.
avg_log_write_percent İşlem günlüğü yazma GÇ için aktarım hızı kullanımları. Havuzdaki her veritabanı ve havuzun kendisi için sağlanır. Veritabanı düzeyinde günlük aktarım hızı üzerinde farklı sınırlar vardır ve bu nedenle havuz düzeyinde bu ölçümün her iki düzeyde de izlenmesi önerilir. Her veritabanındaki sys.dm_db_resource_stats görünümünde ve veritabanındaki sys.elastic_pool_resource_stats görünümünde master kullanılabilir. Bu ölçüm, Azure İzleyici'ye de gönderilir; burada bu ölçüm adlandırılırlog_write_percent ve Azure portalında görüntülenebilir. Bu ölçüm %100'e yaklaştığında tüm veritabanı değişiklikleri (INSERT, UPDATE, DELETE, MERGE deyimleri, SELECT ... INTO, TOPLU INSERT vb.) daha yavaş olacaktır. %90'ın altında. %100'e varan kısa ani artışlar kabul edilebilir.
oom_per_second Elastik havuzdaki bellek yetersiz (OOM) hatalarının oranıdır ve bu da bellek baskısının göstergesidir. sys.dm_resource_governor_resource_pools_history_ex görünümünde kullanılabilir. Bu ölçümü hesaplamak için bkz . Örnek sorgu örnekleri . Daha fazla bilgi için bkz. DTU kullanan elastik havuzlar için kaynak sınırları veya sanal çekirdek kullanan elastik havuzlar ve Azure SQL Veritabanı bellek yetersiz hatalarını giderme. Yetersiz bellek hatalarıyla karşılaşırsanız sys.dm_os_out_of_memory_events içeriğini gözden geçirin. 0
avg_storage_percent Elastik havuz içindeki tüm veritabanlarındaki veriler tarafından kullanılan toplam depolama alanı. Veritabanı dosyalarında boş alan içermez. Veritabanındaki sys.elastic_pool_resource_stats görünümünde master kullanılabilir. Bu ölçüm, Azure İzleyici'ye de gönderilir; burada bu ölçüm adlandırılırstorage_percent ve Azure portalında görüntülenebilir. %80'in altında. Veri büyümesi olmayan havuzlar için %100'e yaklaşabilir.
avg_allocated_storage_percent Elastik havuz içindeki tüm veritabanlarındaki depolama alanında veritabanı dosyaları tarafından kullanılan toplam depolama alanı. Veritabanı dosyalarında boş alan içerir. Veritabanındaki sys.elastic_pool_resource_stats görünümünde master kullanılabilir. Bu ölçüm, Azure İzleyici'ye de gönderilir; burada bu ölçüm adlandırılırallocated_data_storage_percent ve Azure portalında görüntülenebilir. %90'ın altında. Veri büyümesi olmayan havuzlar için %100'e yaklaşabilir.
tempdb_log_used_percent Veritabanında işlem günlüğü alanı kullanımı tempdb . Bir veritabanında oluşturulan geçici nesneler aynı elastik havuzdaki diğer veritabanlarında görünmese de, tempdb aynı havuzdaki tüm veritabanları için paylaşılan bir kaynaktır. Havuzdaki tempdb bir veritabanından başlatılan uzun süre çalışan veya yalnız bırakılmış bir işlem, işlem günlüğünün büyük bir bölümünü tüketebilir ve aynı havuzdaki diğer veritabanlarındaki sorgularda hatalara neden olabilir. sys.dm_db_log_space_usage ve sys.database_files görünümlerinden türetilir. Bu ölçüm Azure İzleyici'ye de gönderilir ve Azure portalında görüntülenebilir. Bu ölçümün geçerli değerini döndürmek için örnek sorgu örneklerine bakın. %50'nin altında. %80'e varan ani artışlar kabul edilebilir.

bu ölçümlere ek olarak, Azure SQL Veritabanı gerçek kaynak idare sınırlarını döndüren bir görünümün yanı sıra 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ı Açıklama
sys.dm_user_db_resource_governance Geçerli veritabanında veya elastik havuzda 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 birikmeli kaynak havuzu istatistikleri hakkındaki bilgileri döndürür.
sys.dm_resource_governor_workload_groups Toplu 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 bilgilerini almak için sütundaki pool_id sys.dm_resource_governor_resource_pools ile birleştirilebilir.
sys.dm_resource_governor_resource_pools_history_ex Kullanılabilir anlık görüntü sayısına göre yakın geçmiş için kaynak havuzu kullanım istatistiklerini döndürür. Her satır bir zaman aralığını temsil eder. Aralığın süresi sütunda duration_ms sağlanır. Sütunlar, delta_ aralık boyunca her istatistikteki değişikliği döndürür.
sys.dm_resource_governor_workload_groups_history_ex Kullanılabilir anlık görüntü sayısına göre son geçmiş için iş yükü grubu kullanım istatistiklerini döndürür. Her satır bir zaman aralığını temsil eder. Aralığın süresi sütunda duration_ms sağlanır. Sütunlar, delta_ aralık boyunca 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 sorumlu kullanarak sorgulamak için bu sorumluyu sunucu rolüne ##MS_ServerStateReader##ekleyin.

Bu görünümler, kaynak kullanımını izlemek ve kaynak çekişmesi sorunlarını neredeyse gerçek zamanlı olarak gidermek için kullanılabilir. Coğrafi çoğaltmalar da dahil olmak üzere birincil ve okunabilir ikincil çoğaltmalardaki kullanıcı iş yükü kaynak havuzuna ve iş yükü grubuna SloSharedPool1 sınıflandırılır; UserPrimaryGroup.DBId[N] burada N veritabanı kimliği değeri anlamına gelir.

Yoğun havuz kullanan müşteriler, geçerli kaynak kullanımını izlemeye ek olarak geçmiş kaynak kullanım verilerini ayrı bir veri deposunda tutabiliyor. Bu veriler, geçmiş ve mevsimsel eğilimlere göre kaynak kullanımını proaktif olarak yönetmek için tahmine dayalı analizde kullanılabilir.

operasyonel öneriler

Yeterli kaynak odası bırakın. Kaynak çekişmesi ve performans düşüşü oluşursa, azaltma işlemi daha önce belirtildiği gibi bazı veritabanlarını etkilenen elastik havuzdan dışarı taşımayı veya havuzun ölçeğini artırmayı içerebilir. Ancak bu eylemlerin tamamlanması için ek işlem kaynakları gerekir. Özellikle Premium ve İş Açısından Kritik havuzları için bu eylemler, taşınan veritabanları için tüm verilerin aktarılmasını veya havuzun ölçeği artırıldıysa elastik havuzdaki tüm veritabanlarının aktarılmasını gerektirir. Veri aktarımı uzun süre çalışan ve yoğun kaynak kullanan bir işlemdir. Havuz zaten yüksek kaynak baskısı altındaysa, azaltma işleminin kendisi performansı daha da düşürecektir. Aşırı durumlarda, gerekli kaynaklar kullanılamadığından veritabanı taşıma veya havuz ölçeği artırma yoluyla kaynak çekişmelerini çözmek mümkün olmayabilir. Bu durumda, etkilenen elastik havuzdaki sorgu iş yükünü geçici olarak azaltmak tek çözüm olabilir.

Yoğun havuz kullanan müşteriler daha önce açıklandığı gibi kaynak kullanım eğilimlerini yakından izlemeli ve ölçümler önerilen aralıklar içinde kalırken ve elastik havuzda hala yeterli kaynak varken azaltma eylemi gerçekleştirmelidir.

Kaynak kullanımı, her veritabanı ve her elastik havuz için zaman içinde değişen birden çok faktöre bağlıdır. Yoğun havuzlarda en uygun fiyat/performans oranını elde etmek için sürekli izleme ve yeniden dengeleme gerekir; bu da veritabanlarını daha fazla kullanılan havuzlardan daha az kullanılan havuzlara taşımayı ve artan iş yükünü karşılamak için gereken yeni havuzları oluşturmayı gerektirir.

Not

DTU elastik havuzları için havuz düzeyindeki eDTU ölçümü bir MAX veya tek tek veritabanı kullanımının TOPLAM değeri değildir. Çeşitli havuz düzeyi ölçümlerinin kullanımından türetilir. Havuz düzeyi kaynak sınırları, tek tek veritabanı düzeyi sınırlarından daha yüksek olabileceğinden, havuz için eDTU raporlaması sınıra ulaşılmadığını gösterse bile tek bir veritabanının belirli bir kaynak sınırına (CPU, veri GÇ, günlük GÇ vb.) ulaşması mümkündür.

"Sık erişimli" veritabanlarını taşımayın. Havuz düzeyinde kaynak çekişmesi öncelikli olarak az sayıda yüksek oranda kullanılan veritabanından kaynaklanıyorsa, bu veritabanlarını daha az kullanılan bir havuza taşımak veya bunları tek başına veritabanları yapmak cazip olabilir. Ancak, taşıma işlemi hem taşınmakta olan veritabanı hem de havuzun tamamı için performansı daha da düşüreceği için, veritabanı yüksek oranda kullanılırken bunu yapmanız önerilmez. Bunun yerine, yüksek kullanım düzeyi azlana kadar bekleyin veya havuz düzeyinde kaynak baskısını azaltmak için daha az kullanılan veritabanlarını taşıyın. Ancak çok düşük kullanımlı veritabanlarının taşınması bu durumda herhangi bir avantaj sağlamaz çünkü havuz düzeyinde kaynak kullanımını önemli ölçüde azaltmaz.

"Karantina" havuzunda yeni veritabanları oluşturun. Kiracı başına veritabanı modelini kullanan uygulamalar gibi yeni veritabanlarının sık oluşturulduğu senaryolarda, var olan bir elastik havuza yerleştirilen yeni bir veritabanının beklenmedik şekilde önemli kaynakları tüketmesi ve havuzdaki diğer veritabanlarını ve iç işlemleri etkilemesi riski vardır. Bu riski azaltmak için, kaynakların bol miktarda ayrılmasıyla ayrı bir "karantina" havuzu oluşturun. Henüz bilinmeyen kaynak tüketimi desenlerine sahip yeni veritabanları için bu havuzu kullanın. Veritabanı bir hafta veya ay gibi bir iş döngüsü için bu havuzda kaldıktan ve kaynak tüketimi bilindikten sonra, bu ek kaynak kullanımını karşılamak için yeterli kapasiteye sahip bir havuza taşınabilir.

Hem kullanılan hem de ayrılan alanı izleyin. Ayrılan havuz alanı (bir havuzdaki tüm veritabanları için depolamadaki tüm veritabanı dosyalarının toplam boyutu) havuz boyutu üst sınırına ulaştığında, yetersiz alan hataları oluşabilir. Ayrılmış alan eğilimleri yüksekse ve havuz boyutu üst sınırına ulaşma yolundaysa, azaltma seçenekleri şunlardır:

  • Ayrılan toplam alanı azaltmak için bazı veritabanlarını havuz dışına taşıma
  • Dosyalarda boş ayrılan alanı azaltmak için veritabanı dosyalarını küçültme
  • En büyük havuz boyutu daha büyük olan bir hizmet hedefi için havuzun ölçeğini artırma

Kullanılan havuz alanı (dosyalardaki boş alan dahil değil, havuzdaki tüm veritabanlarındaki verilerin toplam boyutu) eğilimleri yüksekse ve havuz boyutu üst sınırına ulaşma yolundaysa, azaltma seçenekleri şunlardır:

  • Toplam kullanılan alanı azaltmak için bazı veritabanlarını havuz dışına taşıma
  • Verileri veritabanının dışına taşıma (arşivle) veya artık gerekli olmayan verileri silme
  • Veri sıkıştırma uygulama
  • En büyük havuz boyutu daha büyük olan bir hizmet hedefi için havuzun ölçeğini artırma

Aşırı yoğun sunuculardan kaçının. Azure SQL Veritabanı sunucu başına en fazla 5000 veritabanını destekler. Binlerce veritabanı olan elastik havuzları kullanan müşteriler, desteklenen sınıra kadar toplam veritabanı sayısıyla birlikte tek bir sunucuya birden çok elastik havuz yerleştirmeyi düşünebilir. Ancak binlerce veritabanına sahip sunucular işletimsel zorluklara neden olabilir. Bir sunucudaki tüm veritabanlarını listelemeyi gerektiren işlemler (örneğin portaldaki veritabanlarını görüntüleme) daha yavaş olacaktır. Sunucu düzeyinde oturum açma işlemlerinin veya güvenlik duvarı kurallarının yanlış değiştirilmesi gibi işlemsel hatalar, daha fazla sayıda veritabanını etkiler. Sunucunun yanlışlıkla silinmesi, silinen sunucudaki veritabanlarını kurtarmak için Microsoft Desteği yardım gerektirir ve etkilenen tüm veritabanları için uzun süreli bir kesintiye neden olur.

Sunucu başına veritabanı sayısını desteklenen en yüksek sayıdan daha düşük bir sayıyla sınırlayın. Birçok senaryoda, sunucu başına en fazla 1000-2000 veritabanı kullanmak idealdir. Yanlışlıkla sunucu silme olasılığını azaltmak için sunucuya veya kaynak grubuna bir silme kilidi yerleştirin.

Örnekler

Tek tek veritabanı kapasitesi ayarlarını görüntüleme

sys.dm_user_db_resource_governance Geçerli veritabanında veya elastik havuzda kaynak idaresi tarafından kullanılan gerçek yapılandırma ve kapasite ayarlarını görüntülemek için dinamik yönetim görünümünü kullanın. Daha fazla bilgi için bkz . sys.dm_user_db_resource_governance.

Bu sorguyu elastik havuzdaki herhangi bir veritabanında çalıştırın. Havuzdaki tüm veritabanları aynı kaynak idare ayarlarına sahiptir.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

Genel elastik havuz kaynak tüketimini izleme

Tüm havuzun sys.elastic_pool_resource_stats kaynak tüketimini izlemek için sistem kataloğu görünümünü kullanın. Daha fazla bilgi için bkz . sys.elastic_pool_resource_stats.

Son 10 dakikayı görüntülemek için bu örnek sorgu, istenen elastik havuzu içeren mantıksal Azure SQL sunucusunun veritabanında çalıştırılmalıdır master .

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Tek tek veritabanı kaynak tüketimini izleme

Tek tek veritabanlarının sys.dm_db_resource_stats kaynak tüketimini izlemek için dinamik yönetim görünümünü kullanın. Daha fazla bilgi için bkz . sys.dm_db_resource_stats. Etkinlik olmasa bile her 15 saniyede bir satır vardır. Geçmiş veriler yaklaşık bir saat boyunca tutulur.

Verilerin son 10 dakikasını görüntülemek için bu örnek sorgu istenen veritabanında çalıştırılmalıdır.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

Daha az sıklıkta daha uzun saklama süresi için üzerinde aşağıdaki sorguyu sys.resource_statsgöz önünde bulundurun. Azure SQL mantıksal sunucusunun veritabanında çalıştırın master . Daha fazla bilgi için bkz. sys.resource_stats (Azure SQL Veritabanı). Beş dakikada bir bir satır bulunur ve geçmiş veriler iki hafta boyunca korunur.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Bellek kullanımını izleme

Bu sorgu, kullanılabilir anlık görüntü sayısına göre her kaynak havuzu için son geçmişe yönelik ölçümü hesaplar oom_per_second . Bu örnek sorgu, havuzdaki başarısız bellek ayırmalarının son ortalama sayısını belirlemeye yardımcı olur. Bu sorgu elastik havuzdaki herhangi bir veritabanında çalıştırılabilir.

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;

Günlük alanı kullanımını izleme tempdb

Bu sorgu ölçümün tempdb_log_used_percent geçerli değerini döndürür ve işlem günlüğünün tempdb izin verilen en büyük boyutuna göre göreli kullanımını gösterir. Bu sorgu elastik havuzdaki herhangi bir veritabanında çalıştırılabilir.

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