Sanal çekirdek satın alma modeline genel bakış - Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği

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

Bu makalede hem Azure SQL Veritabanı hem de Azure SQL Yönetilen Örneği tarafından kullanılan sanal çekirdek satın alma modeline kısa bir genel bakış sunulmaktadır. Her ürünün sanal çekirdek modeli hakkında daha fazla bilgi edinmek için veritabanı veAzure SQL Yönetilen Örneği Azure SQL gözden geçirin.

Genel Bakış

Sanal çekirdek (sanal çekirdek) mantıksal cpuyu temsil eder ve donanımın fiziksel özelliklerini (örneğin çekirdek sayısı, bellek ve depolama boyutu) seçme seçeneği sunar. Sanal çekirdek tabanlı satın alma modeli, tek tek kaynak tüketiminde esneklik, denetim, saydamlık ve şirket içi iş yükü gereksinimlerini buluta çevirmenin kolay bir yolunu sunar. Bu model fiyatı iyileştirir ve iş yükü gereksinimlerinize göre işlem, bellek ve depolama kaynaklarını seçmenize olanak tanır.

Sanal çekirdek tabanlı satın alma modelinde, maliyetleriniz aşağıdakilerin seçimine ve kullanımına bağlıdır:

  • Hizmet katmanı
  • Donanım yapılandırması
  • İşlem kaynakları (sanal çekirdek sayısı ve bellek miktarı)
  • Ayrılmış veritabanı depolama alanı
  • Gerçek yedekleme depolama alanı

Önemli

Azure SQL Veritabanı'nda işlem kaynakları (CPU ve bellek), G/Ç ve veri ve günlük depolama, veritabanı veya elastik havuz başına ücretlendirilir. Yedekleme depolama alanı her veritabanı için ücretlendirilir.

Sanal çekirdek satın alma modeli, Azure Hibrit Avantajı (AHB) ve Ayrılmış Örnek (RI) ile veritabanı CPU'sunda, bellekte ve depolama kaynak ayırmasında, donanım yapılandırmasında, daha yüksek ölçeklendirme ayrıntı düzeyinde ve fiyatlandırma indirimlerinde saydamlık sağlar.

Azure SQL Veritabanı söz konusu olduğunda sanal çekirdek satın alma modeli DTU modeline göre daha yüksek işlem, bellek, G/Ç ve depolama sınırları sağlar.

Hizmet katmanları

hem Azure SQL Veritabanı'nda hem de Azure SQL Yönetilen Örneği iki sanal çekirdek hizmet katmanı kullanılabilir:

  • Genel amaçlı , ortak performans ve kullanılabilirlik gereksinimlerine sahip çoğu iş yükü için tasarlanmış, bütçe dostu bir katmandır.
  • İş Açısından Kritik katmanı, katı kullanılabilirlik gereksinimleri olan performansa duyarlı iş yükleri için tasarlanmıştır.

Hiper Ölçek hizmet katmanı, Azure SQL Veritabanındaki tek veritabanları için de kullanılabilir. Bu hizmet katmanı çoğu iş yükü için tasarlanmıştır ve yüksek oranda ölçeklenebilir depolama, okuma ölçeği genişletme, hızlı ölçeklendirme ve hızlı veritabanı geri yükleme özellikleri sağlar.

Kaynak sınırları

Kaynak sınırları hakkında daha fazla bilgi için bkz:

İşlem maliyeti

Sanal çekirdek tabanlı satın alma modeli hem Azure SQL Veritabanı hem de Azure SQL Yönetilen Örneği için sağlanan bir işlem katmanına ve Azure SQL Veritabanı için sunucusuz işlem katmanına sahiptir.

Sağlanan işlem katmanında işlem maliyeti, iş yükü etkinliğinden bağımsız olarak uygulama için sürekli olarak sağlanan toplam işlem kapasitesini yansıtır. Sanal çekirdek ve bellek gereksinimlerine göre iş gereksinimlerinize en uygun kaynak ayırmayı seçin, ardından iş yükünüzün gerektirdiği şekilde kaynakların ölçeğini artırın ve azaltın.

Azure SQL veritabanı için sunucusuz işlem katmanında işlem kaynakları iş yükü kapasitesine göre otomatik olarak ölçeklendirilir ve saniye başına kullanılan işlem miktarı için faturalandırılır.

İş Açısından Kritik hizmet katmanında üç ek çoğaltma otomatik olarak ayrıldığından, fiyat Genel Amaçlı hizmet katmanındakinden yaklaşık 2,7 kat daha yüksektir. Benzer şekilde, İş Açısından Kritik hizmet katmanındaki GB başına yüksek depolama fiyatı, yerel SSD depolamanın daha yüksek GÇ sınırlarını ve daha düşük gecikme süresini yansıtır.

Veri ve günlük depolama

Aşağıdaki faktörler veri ve günlük dosyaları için kullanılan depolama miktarını etkiler ve Genel Amaçlı ve İş Açısından Kritik katmanları için geçerlidir.

  • Her işlem boyutu, varsayılan olarak 32 GB olan yapılandırılabilir bir maksimum veri boyutunu destekler.
  • Maksimum veri boyutunu yapılandırdığınızda günlük dosyası için faturalanabilir depolama alanının yüzde 30'u otomatik olarak eklenir.
  • Genel Amaçlı hizmet katmanında tempdb yerel SSD depolama alanı kullanılır ve bu depolama maliyeti sanal çekirdek fiyatına dahildir.
  • İş Açısından Kritik hizmet katmanında yerel tempdb SSD depolama alanını veri ve günlük dosyalarıyla paylaşır ve tempdb depolama maliyeti sanal çekirdek fiyatına dahildir.
  • Genel Amaçlı ve İş Açısından Kritik katmanlarında veritabanı, elastik havuz veya yönetilen örnek için yapılandırılan maksimum depolama boyutu için ücretlendirilirsiniz.
  • SQL Veritabanı için 1 GB ile desteklenen depolama boyutu üst sınırı arasındaki veri boyutu üst sınırını 1 GB artışlarla seçebilirsiniz. SQL Yönetilen Örneği için desteklenen depolama boyutu üst sınırına kadar 32 GB'ın katlarındaki veri boyutlarını seçin.

SQL Veritabanı'de geçerli ayrılan ve kullanılan veri depolama boyutunu izlemek için sırasıyla allocated_data_storage ve depolama Azure İzleyici ölçümlerini kullanın.

Hem SQL Veritabanı hem de SQL Yönetilen örneği için, T-SQL kullanarak veritabanındaki tek tek verilerin ve günlük dosyalarının geçerli ayrılmış ve kullanılan depolama boyutunu izlemek için sys.database_files görünümünü ve FILEPROPERTY(... , 'SpaceUsed') işlevini kullanın.

İpucu

Bazı durumlarda kullanılmayan alanı geri kazanmak için veritabanını küçültmeniz gerekebilir. Daha fazla bilgi için bkz. Azure SQL Veritabanında dosya alanını yönetme.

Yedekleme alanı

Veritabanı yedeklemeleri için depolama alanı, SQL Veritabanı ve SQL Yönetilen Örneği belirli bir noktaya geri yükleme (PITR) ve uzun süreli saklama (LTR) özelliklerini desteklemek için ayrılır. Bu depolama, veri ve günlük dosyası depolama alanından ayrıdır ve ayrı olarak faturalandırılır.

  • PITR: Genel Amaçlı ve İş Açısından Kritik katmanlarında tek tek veritabanı yedekleri otomatik olarak Azure depolama alanına kopyalanır. Yeni yedeklemeler oluşturulduktan sonra depolama boyutu dinamik olarak artar. Depolama tam, farklar ve işlem günlüğü yedeklemeleri tarafından kullanılır. Depolama tüketimi, veritabanının değişim oranına ve yedeklemeler için yapılandırılan saklama süresine bağlıdır. Her veritabanı için SQL Veritabanı için 1 ile 35 gün arasında ve SQL Yönetilen Örneği için 0 ile 35 gün arasında ayrı bir saklama süresi yapılandırabilirsiniz. Yapılandırılan maksimum veri boyutuna eşit bir yedekleme depolama alanı tutarı ek ücret ödemeden sağlanır.
  • LTR: Ayrıca tam yedeklemelerin 10 yıla kadar uzun süreli saklamasını yapılandırma seçeneğiniz de vardır. BIR LTR ilkesi ayarlarsanız, bu yedeklemeler otomatik olarak Azure Blob depolamada depolanır, ancak yedeklemelerin ne sıklıkta kopyalandığını denetleyebilirsiniz. Farklı uyumluluk gereksinimlerini karşılamak için haftalık, aylık ve/veya yıllık yedeklemeler için farklı saklama süreleri seçebilirsiniz. Seçtiğiniz yapılandırma, LTR yedeklemeleri için ne kadar depolama alanı kullanılacağını belirler. Daha fazla bilgi için bkz. Uzun süreli yedekleme saklama.

Sonraki adımlar

Başlamak için bkz.

Genel Amaçlı ve İş Açısından Kritik hizmet katmanlarında kullanılabilen belirli işlem ve depolama boyutları hakkında ayrıntılı bilgi için bkz: