Azure SQL Veritabanı Hiper Ölçek hakkında SSS

Hiper Ölçek veritabanı, hiper ölçek ölçeği genişletme depolama teknolojisi tarafından yedeklenen SQL Veritabanı bir veritabanıdır. Hiper Ölçek veritabanı 128 TB'a kadar veriyi destekler ve yüksek aktarım hızı ve performansın yanı sıra iş yükü gereksinimlerine uyum sağlamak için hızlı ölçeklendirme sağlar. Bağlantı, sorgu işleme, veritabanı altyapısı özellikleri vb. Azure SQL Veritabanı'daki diğer veritabanları gibi çalışır.

Hiper Ölçek hizmet katmanı yalnızca Azure SQL Veritabanı’nda sanal çekirdek tabanlı satın alma modelini kullanan tek veritabanlarında kullanılabilir. DTU tabanlı satın alma modelinde kullanılamaz.

Sanal çekirdek tabanlı hizmet katmanları, kaynak sınırı karşılaştırmasında açıklandığı gibi veritabanı kullanılabilirliğine ve depolama türüne, performansa ve maksimum depolama boyutuna göre ayırt edilir.

Hiper Ölçek hizmet katmanı, daha yüksek performans ve kullanılabilirlik, hızlı yedekleme ve geri yükleme, hızlı depolama ve işlem ölçeklenebilirliği arayan tüm müşterilere yöneliktir. Buna küçük ve büyüyen müşteriler, görev açısından kritik büyük veritabanları çalıştıran müşteriler, uygulamalarını modernleştirmek için buluta geçenler ve Azure SQL Veritabanı'da zaten başka hizmet katmanları kullanan müşteriler dahildir. Hiper Ölçek ile şunları elde edersiniz:

• 10 GB'tan 128 TB'a kadar büyüyebilen veritabanı boyutu.
• 2 sanal çekirdekten 128 sanal çekirdek'e kadar sanal çekirdek kaynaklarını hesaplama
• Veritabanı boyutundan bağımsız olarak hızlı veritabanı yedeklemeleri (yedeklemeler depolama anlık görüntülerini temel alır).
• Veritabanı boyutundan bağımsız olarak hızlı veritabanı geri yüklemeleri (geri yüklemeler depolama anlık görüntülerinden alınır).
• Veritabanı boyutundan ve sanal çekirdek sayısından bağımsız olarak daha yüksek günlük aktarım hızı.
• Salt okunur iş yüklerini boşaltmak veya etkin bekleme veritabanları olarak kullanılan bir veya daha fazla salt okunur çoğaltma kullanarak ölçeği genişletmeyi okuyun.
• Ağır iş yükünü kaldırabilecek daha fazla güç elde etmek için sabit sürede hızla işlemin ölçeğini artırma ve ardından sabit sürede ölçeği azaltma. Ölçeklendirme işlemleri, sağlanan işlem için tek basamaklı dakika ve veritabanı boyutu ne olursa olsun sunucusuz işlem için bir saniyeden kısa sürer.
• İşlemin kullanıma göre faturalandırıldığı sunucusuz işlemle kullandığınız kadar ödeme seçeneği.

Hiper Ölçek hizmet katmanı, Azure SQL Veritabanı kullanılabilir olduğu tüm bölgelerde kullanılabilir.

Evet. Sunucu başına veritabanı sayısı hakkında daha fazla bilgi ve sınır için bkz. SQL Veritabanı sunucudaki tek ve havuza alınan veritabanları için kaynak sınırları.

Hiper Ölçek mimarisi, büyük veritabanı boyutlarını desteklerken yüksek performans ve aktarım hızı sağlar.

Hiper Ölçek, iş yükü talebinize göre hızlı ölçeklenebilirlik sağlar.

• Ölçeği Artırma/Azaltma

  Hiper Ölçek ile, CPU ve bellek gibi kaynaklar açısından birincil işlem boyutunun ölçeğini artırabilir ve ardından sabit süre içinde ölçeği azaltabilirsiniz. Depolama alanı uzak olduğundan ölçeği artırma ve azaltma, veri işleminin boyutu değildir.

  Sunucusuz işlem desteği otomatik ölçeklendirme ve ölçeği azaltma sağlar ve işlem kullanım temelinde faturalandırılır.

• Ölçeği Daraltma/Genişletme

  Hiper Ölçek ile ölçeği genişletme, yüksek kullanılabilirlik ve coğrafi çoğaltma gereksinimlerini okumak için üç tür ikincil çoğaltma kullanabilirsiniz. Buna aşağıdakiler dahildir:

  • Birincil ile aynı işlem boyutuna sahip en fazla dört yüksek kullanılabilirlik çoğaltması . Bunlar, birincilden hızlı bir şekilde yük devretmek için etkin bekleme çoğaltmaları görevi görür. Bunları, okuma iş yüklerini birincil iş yüklerinden boşaltmak için de kullanabilirsiniz.
  • Çeşitli okuma ölçeği genişletme senaryolarını karşılamak için birincilden aynı veya farklı işlem boyutuna sahip 30'a kadar adlandırılmış çoğaltma.
  • Bölgesel kesintilere karşı koruma sağlamak ve coğrafi okuma ölçeğini genişletmeyi sağlamak için farklı bir Azure bölgesindeki coğrafi çoğaltma.

Evet, sürdürebilirsiniz.

Hayır, uygulama programlama modeliniz diğer TÜM MSSQL veritabanlarıyla aynı kalır. bağlantı dizesi her zamanki gibi ve Hiper Ölçek veritabanınızla etkileşim kurmanın diğer normal yollarını kullanırsınız. Uygulamanız Hiper Ölçek veritabanını kullandıktan sonra, uygulamanız ikincil çoğaltmalar gibi özelliklerden yararlanabilir.

Birincil çoğaltmada, varsayılan işlem yalıtım düzeyi RCSI'dir (Kaydedilmiş Anlık Görüntü Yalıtımını Okuma). Okuma Ölçeği genişletme ikincil çoğaltmalarında varsayılan yalıtım düzeyi Anlık Görüntü'dür. Bu, diğer Tüm Azure SQL veritabanlarında olduğu gibi aynıdır.

15 Aralık 2023'ten bu yana geçerli olan yeni, basitleştirilmiş fiyatlandırma ile yeni oluşturulan Hiper Ölçek veritabanları, sunucusuz hiper ölçek veritabanları ve tüm Hiper Ölçek elastik havuzları için işlem fiyatı düşürüldü. Yeni, basitleştirilmiş fiyatlandırma ile eşdeğer tasarruf elde etmek için Azure Hibrit Avantajı (AHB) uygulamaya gerek yoktur. Azure Hibrit Avantajı (AHB) yalnızca sağlanan işlem içeren eski (15 Aralık 2023'tan önce oluşturulmuş) hiper ölçek tek veritabanlarına uygulanabilir. Bu eski veritabanları için, AHB yalnızca Aralık 2026'ya kadar geçerlidir ve bundan sonra bu veritabanları da yeni, basitleştirilmiş fiyatlandırmaya göre faturalandırılır. Daha fazla bilgi için bkz. Hiper Ölçek fiyatlandırma blogu ve Azure SQL Veritabanı Hiper Ölçek – daha düşük, basitleştirilmiş fiyatlandırma!.

Hiper ölçek OLTP, Karma (HTAP) ve Analitik (veri martı) iş yükleri dahil olmak üzere tüm iş yükü türleri için iyi çalışır.

Şu anda SQL Server'ı veri ambarı olarak kullanarak etkileşimli analiz sorguları çalıştırıyorsanız, küçük ve orta ölçekli veri ambarlarını (128 TB'a kadar olan birkaç TB gibi) daha düşük bir maliyetle barındırabileceğiniz ve SQL Server veri ambarı iş yüklerinizi en az T-SQL kod değişikliğiyle Hiper Ölçek'e geçirebileceğiniz için Hiper Ölçek harika bir seçenektir.

Karmaşık sorgular ve sürekli alım hızları 100 MB/sn'den yüksek olan büyük ölçekte veri analizi çalıştırıyorsanız veya Paralel Veri Ambarı (PDW), Teradata veya Azure Synapse Analytics gibi diğer Yüksek Düzeyde Paralel İşleme (MPP) veri ambarlarını kullanıyorsanız Microsoft Fabric en iyi seçenek olabilir.

150 MB/sn veri alımı veya günlük oluşturma hızı, bir kabul önizleme özelliği olarak kullanılabilir. Daha fazla bilgi edinmek ve 150 MB/sn'yi kabul etmek için bkz . Blog: Kasım 2024 Hiper Ölçek geliştirmeleri.

Şu anda hayır. Bununla birlikte, işlem ve çoğaltma sayısının ölçeğini azaltarak kalıcı olmayan zamanlarda maliyeti düşürebilir veya kullanımı temel alarak işlemi otomatik olarak ölçeklendirmek için sunucusuz kullanabilirsiniz.

Okuma iş yükleri için, birincilden daha yüksek işlem boyutuna (daha fazla çekirdek ve bellek) sahip adlandırılmış bir çoğaltma oluşturabilirsiniz. Kullanılabilir işlem boyutları hakkında daha fazla bilgi için bkz . Hiper Ölçek depolama ve işlem boyutları.

Okuma iş yükleri için bu, adlandırılmış çoğaltmalar kullanılarak elde edilebilir.

Azure portalını veya REST API'yi kullanarak HA ikincil çoğaltmalarının sayısını 0 ile 4 arasında ölçeklendikleyebilirsiniz. Ayrıca, birçok okuma ölçeği genişletme senaryosu için en fazla 30 adlandırılmış çoğaltma oluşturabilirsiniz.

Hiper Ölçek veritabanlarında, depolama düzeyinde veri dayanıklılığı sağlanır. Dayanıklılık sağlamak için yalnızca bir çoğaltmaya (birincil) ihtiyacınız vardır. İşlem çoğaltması kapalı olduğunda, veri kaybı olmadan otomatik olarak yeni bir çoğaltma oluşturulur.

Ancak, yalnızca birincil çoğaltma varsa, yük devretmeden sonra yeni bir çoğaltma oluşturmak bir veya iki dakika sürebilir ve ha ikincil çoğaltması kullanılabilir durumda saniyeler arasında olabilir. Yeni çoğaltma başlangıçta soğuk önbelleklere sahip olur ve bu da yük devretmeden hemen sonra daha yüksek depolama gecikmesine ve sorgu performansının düşmesine neden olabilir.

En düşük yük devretme etkisiyle yüksek kullanılabilirlik gerektiren görev açısından kritik uygulamalar için, etkin bekleyen çoğaltmanın yük devretme hedefi olarak kullanılabildiğinden emin olmak için en az bir HA ikincil çoğaltması sağlamanız gerekir.

Tek bir Hiper Ölçek veritabanının en büyük boyutu şu anda 128 TB'tır. Hiper Ölçek elastik havuzundaki bir veritabanının boyutu üst sınırı şu anda 100 TB'tır.

Hiper Ölçek'te işlem günlüğü neredeyse sonsuzdur ve günlüğün etkin bölümünün 1 TB'ı aşamayamayacağına ilişkin bir kısıtlama vardır. Günlüğün etkin bölümü, uzun süre çalışan işlemler veya Değişiklik Verileri Yakalama işleminin veri değişikliği hızına ayak uydurmaması nedeniyle büyüyebilir. Bu sınırın altında kalmak için gereksiz yere uzun ve büyük işlemlerden kaçının. Bu kısıtlama dışında, yüksek günlük aktarım hızına sahip bir sistemde günlük alanının biteceğinden endişelenmeniz gerekmez. Ancak, günlük oluşturma hızı sürekli agresif yazma iş yükleri için kısıtlanabilir. En yüksek sürekli günlük oluşturma hızı 100 MB/sn'dir.

150 MB/sn günlük oluşturma hızı, bir kabul önizleme özelliği olarak kullanılabilir. Daha fazla bilgi edinmek ve 150 MB/sn'yi kabul etmek için bkz . Blog: Kasım 2024 Hiper Ölçek geliştirmeleri.

Veritabanınız yerel SSD depolama alanında bulunur ve sağladığınız tempdb işlem boyutuyla (çekirdek sayısı) orantılı olarak boyutlandırılır. boyutu tempdb yapılandırılamaz ve sizin için yönetilir. Veritabanınızın en büyük tempdb boyutunu belirlemek için bkz . Hiper Ölçek depolama ve işlem boyutları.

Daha fazla veri eklediğinizde/aldıkça veritabanınızın boyutu otomatik olarak büyür.

10 GB. Başlangıç boyutu 10 GB olan bir Hiper Ölçek veritabanı oluşturulur ve 10 GB öbeklerde gerektiğinde büyür.

Her veri dosyası 10 GB büyür. Birden çok veri dosyası aynı anda büyüyebilir.

Hiper Ölçek'te veri dosyaları Azure standart depolama alanında depolanır. Veriler, işlem çoğaltmalarına uzak sayfa sunucularında yerel SSD depolamada tamamen önbelleğe alınır. Buna ek olarak, uzak sayfa sunucularından veri getirme sıklığını azaltmak için işlem çoğaltmalarının yerel SSD'de ve bellekte veri önbellekleri vardır.

Hayır Veri dosyaları dosya grubuna PRIMARY otomatik olarak eklenir. Ek dosya grupları oluşturmanın yaygın nedenleri Hiper Ölçek depolama mimarisinde veya Azure SQL Veritabanı daha geniş kapsamlı olarak geçerli değildir.

Hayır

Evet, veritabanı ve dosya küçültme işlemleri şu anda önizleme aşamasındadır. Önizleme hakkında daha fazla bilgi için bkz. Azure SQL Veritabanı Hiper Ölçek için küçültme.

Evet, diğer Tüm Azure SQL DB veritabanlarında olduğu gibi. Buna satır, sayfa ve columnstore sıkıştırması dahildir.

Evet. Belirli bir tabloyla ilişkili veri sayfaları, tümü aynı dosya grubunun parçası olan birden çok veri dosyasında bulunabilir. MSSQL veritabanı altyapısı, verileri veri dosyalarına dağıtmak için orantılı doldurma stratejisi kullanır.

Evet. Azure SQL Veritabanı'deki mevcut veritabanlarınızı Hiper Ölçek'e taşıyabilirsiniz. Kavram kanıtı (POC) için veritabanınızın bir kopyasını oluşturmanızı ve kopyayı Hiper Ölçek'e geçirmenizi öneririz.

Mevcut veritabanını Hiper Ölçek'e taşımak için gereken süre, verileri kopyalama süresinden ve verileri kopyalarken kaynak veritabanında yapılan değişiklikleri yeniden yürütme süresinden oluşur. Veri kopyalama süresi, veri boyutuyla orantılıdır. Taşıma işlemi düşük yazma etkinliği sırasında yapılırsa değişiklikleri yeniden yürütme süresi daha kısa olur.

Mevcut Azure SQL Veritabanı Hiper Ölçek'e geçirmek için azure portalda, Azure CLI'de, PowerShell'de ve Transact-SQL'de mevcut veritabanını Hiper Ölçek'e geçirmek için örnek kod alın.

Genel Amaçlı hizmet katmanına ters geçiş, hiper ölçek gereksinimlerini karşılamaması halinde, Azure SQL Veritabanı'daki mevcut bir veritabanını Hiper Ölçek hizmet katmanına geçirmiş olan müşterilerin geri dönmesine olanak tanır. Tersine geçiş bir hizmet katmanı değişikliğiyle başlatılmış olsa da, temelde farklı mimariler arasındaki veri boyutu işlemidir. Hiper Ölçek'e geçişe benzer şekilde, yazma etkinliğinin düşük olduğu bir dönemde yapılırsa tersine geçiş daha hızlı olur. Ters geçişle ilgili sınırlamaları öğrenin.

Daha önce var olan bir Azure SQL Veritabanı Hiper Ölçek hizmet katmanına geçirdiyseniz, özgün Hiper Ölçek'e geçişi izleyen 45 gün içinde bunu Genel Amaçlı hizmet katmanına ters geçirebilirsiniz. Veritabanını İş Açısından Kritik gibi başka bir hizmet katmanına geçirmek istiyorsanız, önce Genel Amaçlı hizmet katmanına ters geçiş yapın, ardından hizmet katmanını değiştirin. Tersine geçiş, veri işleminin boyutudur.

Hiper Ölçek hizmet katmanında oluşturulan veritabanları diğer hizmet katmanlarına taşınamaz.

Ters geçiş sınırlamaları ve etkilenen yedekleme ilkeleri de dahil olmak üzere Hiper Ölçek'ten geçişi tersine çevirmeyi öğrenin.

Evet. Bazı Azure SQL Veritabanı özellikleri henüz Hiper Ölçek'te desteklenmiyor. Bu özelliklerden bazıları veritabanınız için etkinleştirildiyse Hiper Ölçek'e geçiş engellenebilir veya geçişten sonra bu özellikler çalışmayı durdurur. Bu sınırlamaların geçici olmasını bekliyoruz. Ayrıntılar için bkz . Bilinen sınırlamalar.

Evet. İşlem çoğaltması ve diğer veri taşıma teknolojileri (Toplu Kopyalama, Azure Data Factory, Azure Databricks, SSIS) dahil olmak üzere Hiper Ölçek'e geçiş yapmak için birçok mevcut geçiş teknolojisini kullanabilirsiniz. Ayrıca birçok geçiş senaryolarını destekleyen Azure Veritabanı Geçiş Hizmeti de bakın.

Hiper Ölçek'e geçiş için kapalı kalma süresi, veritabanlarınızı diğer Azure SQL Veritabanı hizmet katmanlarına geçirirken kapalı kalma süresiyle aynıdır. Boyutu birkaç TB'a kadar olan veritabanları için kapalı kalma süresini en aza indirmek için işlem çoğaltmasını kullanabilirsiniz. Çok büyük veritabanları (10+ TB) için ADF, Spark veya diğer toplu veri taşıma teknolojilerini kullanarak geçiş işlemini uygulamayı düşünebilirsiniz.

Hiper Ölçek 100 MB/sn yeni/değiştirilmiş veri tüketebilen bir özelliktir, ancak Azure SQL Veritabanı'daki veritabanlarına veri taşımak için gereken süre kullanılabilir ağ aktarım hızı, kaynak okuma hızı ve hedef veritabanı hizmet düzeyi hedeflerinden de etkilenir. 150 MB/sn günlük oluşturma hızı, bir kabul önizleme özelliği olarak kullanılabilir. Daha fazla bilgi edinmek ve 150 MB/sn'yi kabul etmek için bkz . Blog: Kasım 2024 Hiper Ölçek geliştirmeleri.

İstemci uygulamasının Azure Depolama'dan veri okumasını ve hiper ölçek veritabanına veri yüklemesine sahip olabilirsiniz (Azure SQL Veritabanı'deki diğer veritabanlarında olduğu gibi). Polybase şu anda Azure SQL Veritabanı'de desteklenmiyor. Hızlı yük sağlamaya alternatif olarak, Azure Data Factory'yi kullanabilir veya SQL için Spark bağlayıcısı ile Azure Databricks'te bir Spark işi kullanabilirsiniz. SQL'e Spark bağlayıcısı toplu eklemeyi destekler.

BULK INSERT veya OPENROWSET kullanarak Azure Blob deposundaki verileri toplu olarak okumak da mümkündür: Azure Blob Depolama'da Verilere Toplu Erişim Örnekleri.

Hiper Ölçek'te basit kurtarma veya toplu günlük kaydı modeli desteklenmez. Yüksek kullanılabilirlik ve belirli bir noktaya kurtarma sağlamak için tam kurtarma modeli gereklidir. Ancak Hiper Ölçek günlük mimarisi, diğer Azure SQL Veritabanı hizmet katmanlarına kıyasla daha iyi veri alma hızı sağlar.

Hayır Hiper ölçek, simetrik bir çoklu işleme (SMP) mimarisidir ve yüksek düzeyde paralel işleme (MPP) veya çok ana mimari değildir. Salt okunur iş yüklerinin ölçeğini genişletmek için yalnızca birden çok çoğaltma oluşturabilirsiniz.

Evet. Azure Veritabanı Geçiş Hizmeti birçok geçiş senaryolarını destekler.

Azure SQL Veritabanı için bkz. SLA. Kritik iş yükleri için HA ikincil çoğaltmaları eklemenizi öneririz. Bu, daha hızlı yük devretme sağlar ve yük devretmeden hemen sonra olası performans etkisini azaltır.

Evet.

Evet, Hiper Ölçek alanlar arası yedekli yapılandırmayı destekler. Hiper Ölçek için alanlar arası yedekli yapılandırmayı etkinleştirmek için en az bir HA ikincil çoğaltması ve alanlar arası yedekli veya coğrafi alanlar arası yedekli depolama kullanılması gerekir.

Evet. Daha fazla bilgi için bkz . Hiper Ölçek elastik havuzları ve Blog: Hiper Ölçek Elastik Havuzları genel kullanıma sunuldu.

Hiper ölçek veritabanları için geleneksel tam, değişiklik temelli ve işlem günlüğü yedeklemeleri yoktur. Bunun yerine, her dosya için ayrı bir anlık görüntü temposuyla veri dosyalarının normal depolama anlık görüntüleri vardır. Oluşturulan işlem günlüğü, yapılandırılan saklama süresi boyunca olduğu gibi korunur. Geri yükleme zamanında, geri yüklenen depolama anlık görüntülerine ilgili işlem günlüğü kayıtları uygulanır. Anlık görüntü temposunun ne olursa olsun, bu işlem açısından tutarlı bir veritabanının bekletme süresi içinde belirtilen zaman noktasından itibaren herhangi bir veri kaybına neden olur. Hiper Ölçek'te veritabanı yedeklemesi süreklidir.

Evet.

Belirli bir noktaya geri yükleme için RPO 0 dakikadır. Belirli bir noktaya geri yükleme işlemlerinin çoğu veritabanı boyutundan bağımsız olarak 60 dakika içinde tamamlar. Daha büyük veritabanları için geri yükleme süresi daha uzun olabilir ve veritabanı, geri yükleme noktasından önce ve geri yükleme noktasına kadar önemli bir yazma etkinliği yaşadıysa. Geri yükleme yapılırken depolama yedekliliğini değiştirmek, geri yükleme veri boyutu olduğundan ve bu süre veritabanı boyutuyla orantılı olduğundan geri yükleme sürelerinin daha uzun olmasına neden olabilir.

Hayır Yedeklemeler depolama alt sistemi tarafından yönetilir ve depolama anlık görüntülerini kullanır. Bunlar kullanıcı iş yüklerini etkilemez.

Evet. Coğrafi olarak yedekli depolama kullanılıyorsa coğrafi geri yükleme tam olarak desteklenir. Bu, yeni veritabanları için varsayılandır. Belirli bir noktaya geri yüklemenin aksine coğrafi geri yükleme için veri boyutu işlemi gerekir. Veri dosyaları paralel olarak kopyalandığından, bu işlemin süresi veritabanı boyutunun toplam boyutu yerine veritabanındaki en büyük dosyanın boyutuna bağlıdır. Veritabanı kaynak veritabanının bölgesiyle eşleştirilen Azure bölgesinde geri yüklenirse coğrafi geri yükleme süresi önemli ölçüde kısalacaktır.

Evet. Hiper Ölçek veritabanları için coğrafi çoğaltma ayarlanabilir.

Hayır Hiper Ölçek veritabanlarının depolama biçimi, SQL Server'ın yayımlanan sürümlerinden farklıdır ve yedeklemeleri denetlemez veya bunlara erişiminiz yoktur. Verilerinizi Bir Hiper Ölçek veritabanından çıkarmak için, herhangi bir veri taşıma teknolojisini kullanarak verileri ayıklayabilirsiniz; diğer bir ifadeyle Azure Data Factory, Azure Databricks, SSIS vb.

Evet. 4 Mayıs 2022'de geçerli olan tüm yeni veritabanları için yedeklemeler, kullanılan yedekleme depolama alanına ve seçilen depolama yedekliliğine göre Azure SQL Veritabanı fiyatlandırma sayfasında yakalanan ücretlere göre ücretlendirilir. 4 Mayıs 2022'den önce oluşturulan Hiper Ölçek veritabanları için yedeklemeler yalnızca yedekleme saklama yedi günden uzun olacak şekilde ayarlandıysa ücretlendirilir. Daha fazla bilgi edinmek için bkz . Hiper Ölçek yedeklemeleri ve depolama yedekliliği.

Yedekleme depolama boyutunu ölçmeye ilişkin ayrıntılar Otomatik Yedeklemeler'de yakalanır.

Yedekleme depolama faturanızı belirlemek için, yedekleme depolama boyutu düzenli aralıklarla hesaplanır ve yedekleme depolama hızıyla ve son hesaplamadan bu yana geçen saat sayısıyla çarpılır. Bir süre için yedekleme faturanızı tahmin etmek için, dönemin her saati için faturalanabilir yedekleme depolama boyutunu yedekleme depolama hızıyla çarpın ve tüm saatlik tutarları ekleyin. Program aracılığıyla birden çok saatlik aralık için ilgili Azure İzleyici ölçümlerini sorgulamak için Azure İzleyici REST API'sini kullanın. Sunucusuz işlem katmanındaki yedekleme faturalaması, sağlanan işlem katmanındakiyle aynıdır.

Veritabanındaki büyük hacimli verileri ekleyen, değiştiren veya silebilen iş yükleri için yedekleme maliyetleri daha yüksek olacaktır. Buna karşılık, çoğunlukla salt okunur olan iş yüklerinin yedekleme maliyetleri daha düşük olabilir.

Yedekleme depolama maliyetlerinin nasıl en aza indirilmesine ilişkin ayrıntılar Otomatik Yedeklemeler'de yakalanır.

İşlem günlüğü aktarım hızı üst sınırı, herhangi bir Hiper Ölçek işlem boyutu için 100 MB/sn olarak ayarlanır. Bu hıza ulaşabilmek, iş yükü türü, istemci yapılandırması ve performansı ve bu hızda günlük kaydı oluşturmak için birincil işlem çoğaltması üzerinde yeterli işlem kapasitesine sahip olmak dahil ancak bunlarla sınırlı olmamak üzere birden çok faktöre bağlıdır. 150 MB/sn günlük oluşturma hızı, bir kabul önizleme özelliği olarak kullanılabilir. Daha fazla bilgi edinmek ve 150 MB/sn'yi kabul etmek için bkz . Blog: Kasım 2024 Hiper Ölçek geliştirmeleri.

IOPS ve GÇ gecikme süresi, iş yükü desenlerine bağlı olarak değişir. Erişilen veriler işlem çoğaltmasında RBPEX'te önbelleğe alınırsa, İş Açısından Kritik veya Premium hizmet katmanlarında olduğu gibi benzer GÇ performansı görürsünüz.

Hayır İşlem, depolama katmanından ayrılır. Bu, yedeklemenin performans etkisini ortadan kaldırır.

Depolama alanı paylaşıldığından ve birincil ve ikincil işlem çoğaltmaları arasında doğrudan fiziksel çoğaltma olmadığından, birincil çoğaltmadaki aktarım hızı ikincil çoğaltmaların eklenmesinden doğrudan etkilenmez. Ancak, günlüklerin ikincil çoğaltmalara ve sayfa sunucularına uygulanmasına izin vermek için birincilde sürekli ve agresif yazma iş yükleri kısıtlanabilir. Bu, ikincil çoğaltmalarda düşük okuma performansını ve HA ikincil çoğaltmasına yük devretmeden sonra uzun kurtarmayı önler.

Evet. Ancak, diğer Azure SQL DB veritabanlarında olduğu gibi bağlantılar da çok seyrek geçici hatalarla sonlandırılabilir ve bu da uzun süre çalışan sorguları durdurup işlemleri geri alabilir. Geçici hataların nedenlerinden biri, sistemin sürekli işlem ve depolama kaynağı kullanılabilirliğini sağlamak veya planlı bakım gerçekleştirmek için veritabanını hızla farklı bir işlem düğümüne kaydırmasıdır. Bu yeniden yapılandırma olaylarının çoğu 10 saniyeden kısa sürede tamamlanmaktadır. Veritabanınıza bağlanan uygulamalar, yeniden deneme mantığı uygulanarak bu seyrek geçici hataları beklenecek ve tolere edilecek şekilde derlenmelidir. Ayrıca, planlı bakım nedeniyle oluşan geçici hataları önlemek için iş yükü zamanlamanızla eşleşen bir bakım penceresi yapılandırmayı göz önünde bulundurun.

Çoğu performans sorunu için, özellikle de depolama performansında köklenmemiş olanlar için yaygın SQL tanılama ve sorun giderme adımları uygulanır. Hiper Ölçek'e özgü depolama tanılamaları için bkz . SQL Hiper Ölçek performansı sorunlarını giderme tanılaması.

Sunucusuz bir veritabanının ölçeğini artırabileceği en fazla bellek miktarı, sağlanan işlemdeki sanal çekirdek sayısının 5 GB/sanal çekirdek sayısının 5 GB/sanal çekirdek sayısından daha fazla olmasıyla karşılaştırıldığında yapılandırılan sanal çekirdek sayısının en fazla 3 GB/sanal çekirdek sayısıdır. Ayrıntılar için sunucusuz Hiper Ölçek kaynak sınırlarını gözden geçirin.

Sağlanan işlem katmanında ölçeği artırma veya azaltma işlemi, veri boyutu ne olursa olsun genellikle 2 dakikaya kadar sürer. İşlemin iş yükü talebine göre otomatik olarak ölçeklendirildiği sunucusuz işlem katmanında ölçeklendirme süresi genellikle altsaniyedir, ancak bazen sağlanan işlem ölçeklendirilirken olduğu kadar uzun sürebilir.

Hayır Ölçeği artırma veya azaltma işlemleri sırasında veritabanı çevrimiçi kalır.

Sağlanan işlemin ölçeğini artırma veya azaltma, ölçeklendirme işleminin sonunda yük devretme gerçekleştiğinde bağlantıların bırakılmasına neden olur. Sunucusuz işlemde otomatik ölçeklendirme genellikle bağlantının düşmesine neden olmaz, ancak zaman zaman gerçekleşebilir. İkincil çoğaltmaların eklenmesi veya kaldırılması, birincil çoğaltmada bağlantının düşmesine neden olmaz.

Sağlanan işlemde ölçeklendirme son kullanıcı tarafından gerçekleştirilir. Sunucusuz işlemde otomatik ölçeklendirme, hizmet tarafından gerçekleştirilir.

Evet. çekirdek tempdb sayısı arttıkça işlem düğümlerindeki veritabanı ve RBPEX önbellek boyutu otomatik olarak artar. Ayrıntılar için bkz . Hiper Ölçek depolama ve işlem boyutları.

Hayır Yalnızca birincil işlem çoğaltması okuma/yazma isteklerini kabul eder. İkincil işlem çoğaltmaları yalnızca salt okunur istekleri kabul eder.

Hiper Ölçek, Yüksek Kullanılabilirlik (HA) çoğaltmalarını, adlandırılmış çoğaltmaları ve coğrafi çoğaltmaları destekler. Ayrıntılar için bkz . Hiper Ölçek ikincil çoğaltmaları .

0 ile 4 arasında. Çoğaltma sayısını ayarlamak istiyorsanız Azure portalını veya REST API'yi kullanarak bunu yapabilirsiniz.

bağlantı dizesi özelliği olarak ayarlayarak ApplicationIntent bu ek salt okunur işlem çoğaltmalarına ReadOnlybağlanabilirsiniz. ile ReadOnly işaretlenen tüm bağlantılar varsa otomatik olarak HA ikincil çoğaltmalarından birine yönlendirilir. Ayrıntılar için bkz . Salt okunur sorgu iş yüklerini boşaltmak için salt okunur çoğaltmaları kullanma.

Aşağıdaki T-SQL sorgusunu yürütebilirsiniz: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Sonuç, READ_ONLY salt okunur ikincil çoğaltmaya bağlı olmanız ve READ_WRITE birincil çoğaltmaya bağlı olmanızdır. Veritabanı bağlamı veritabanınıza değil master veritabanınızın adına ayarlanmalıdır.

Hayır YALNıZCA belirterek ApplicationIntent=ReadOnlyHA ikincil çoğaltmalarına bağlanabilirsiniz. Ancak, adlandırılmış çoğaltmalar için ayrılmış uç noktaları kullanabilirsiniz.

Hayır Salt okunur amaca sahip yeni bir bağlantı, rastgele bir HA ikincil çoğaltmasına yönlendirilir.

Sağlanan işlem katmanında değil. HA ikincil çoğaltmaları yüksek kullanılabilirlik yük devretme hedefleri olarak kullanıldığından, yük devretme sonrasında beklenen performansı sağlamak için birincil ile aynı yapılandırmaya sahip olmaları gerekir. Sunucusuz olarak işlem, tek tek iş yükü talebine göre her HA çoğaltması için otomatik olarak ölçeklendirilir. Her HA ikincil, yük devretme sonrası rolüne uyum sağlamak için yapılandırılan maksimum çekirdeklere otomatik ölçeklendirme yapmaya devam edebilir. Adlandırılmış çoğaltmalar , her çoğaltmayı bağımsız olarak ölçeklendirme olanağı sağlar.

Hayır Veritabanınız tempdb sağlanan işlem boyutuna göre yapılandırılır; HA ikincil çoğaltmalarınız birincil işlemle tempdbaynı boyuta sahiptir. Adlandırılmış çoğaltmalarda, tempdb çoğaltmanın işlem boyutuna göre boyutlandırılır, bu nedenle birincil çoğaltmadan daha küçük veya daha büyük tempdb olabilir.

Hayır Hiper ölçek veritabanı işlem çoğaltmaları depolamayı paylaşır; yani tüm işlem çoğaltmaları aynı tabloları, dizinleri ve diğer veritabanı nesnelerini görür. İkincil okumalar için en iyi duruma getirilmiş ek dizinler istiyorsanız bunları birincil dizine eklemeniz gerekir. Geçici verileri depolamak için her ikincil çoğaltmada geçici tablolar (# veya ## ile ön ekli tablo adları) oluşturabilirsiniz. Geçici tablolar okuma-yazmadır.

Bir işlemin birincil üzerinde işlendiği zamandan ikincilde okunabilen zamana kadar olan veri gecikmesi, geçerli günlük oluşturma hızına, işlem boyutuna, çoğaltma üzerindeki yüke ve diğer faktörlere bağlıdır. Küçük işlemler için tipik veri gecikme süresi onlarca milisaniyedir, ancak veri gecikme süresinde üst sınır yoktur. Belirli bir ikincil çoğaltmadaki veriler her zaman işlemsel olarak tutarlıdır, bu nedenle büyük işlemlerin yayılması daha uzun sürer. Ancak, belirli bir noktada veri gecikme süresi ve veritabanı durumu farklı ikincil çoğaltmalar için farklı olabilir. Kaydedilmiş verileri hemen okuması gereken iş yükleri birincil çoğaltmada çalıştırılmalıdır.

Hayır, adlandırılmış çoğaltmalar birincil çoğaltma için yük devretme hedefleri olarak kullanılamaz. Bu amaçla HA çoğaltmaları ekleyin.

Her adlandırılmış çoğaltmanın farklı bir hizmet düzeyi hedefi olabileceğinden ve bu nedenle farklı kullanım örnekleri için kullanılabildiğinden, birincile gönderilen salt okunur trafiği adlandırılmış çoğaltma kümesine yönlendirmenin yerleşik bir yolu yoktur. Örneğin, sekiz adlandırılmış çoğaltmanız olabilir ve OLTP iş yükünü yalnızca 1 ile 4 arasında adlandırılmış çoğaltmalara yönlendirmek isteyebilirsiniz; Power BI analitik iş yükleri 5 ve 6 adlı çoğaltmaları, veri bilimi iş yükü ise 7 ve 8 çoğaltmalarını kullanır. Kullandığınız araç veya programlama diline bağlı olarak, bu tür iş yükünü dağıtma stratejileri farklılık gösterebilir. REST arka ucun ölçeği genişletmesine izin vermek için iş yükü yönlendirme çözümü oluşturma örneği için OLTP ölçeği genişletme örneğini gözden geçirin.

Hayır, adlandırılmış çoğaltmalar birincil çoğaltmanın aynı sayfa sunucularını kullandığından, aynı bölgede olmaları gerekir.

Adlandırılmış çoğaltma, birincil çoğaltmanın kullanılabilirliğini etkileyemez. Adlandırılmış çoğaltmaların normal koşullarda birincilin performansını etkileme olasılığı düşüktür, ancak yoğun iş yükleri çalışıyorsa bu durum oluşabilir. Bir HA çoğaltması gibi, adlandırılmış çoğaltma da işlem günlüğü hizmeti aracılığıyla birincil çoğaltmayla eşitlenmiş olarak tutulur. Adlandırılmış bir çoğaltma herhangi bir nedenle işlem günlüklerini yeterince hızlı kullanamıyorsa, birincil çoğaltmadan günlük oluşturma işlemini yavaşlatmalarını (azaltmasını) istemeye başlar ve böylece bunu yakalayabilir. Bu davranış birincilin kullanılabilirliğini etkilemese de, yazma iş yüklerinin birincil üzerindeki performansını etkileyebilir. Bu durumu önlemek için, adlandırılmış çoğaltmalarınızın işlem günlüğünü gecikmeden işlemek için yeterli kaynak alanına (özellikle CPU) sahip olduğundan emin olun. Örneğin, birincil çok sayıda veri değişikliği işliyorsa, çoğaltmalarda CPU'nun doygunluğunu önlemek ve dolayısıyla birincili yavaşlama zorlamak için birincil ile en az aynı Hizmet Düzeyi Hedefine sahip adlandırılmış çoğaltmaların olması önerilir.

Adlandırılmış çoğaltmalar her zamanki gibi salt okunur erişim için kullanılabilir olmaya devam eder.

Varsayılan olarak, adlandırılmış çoğaltmaların kendi HA çoğaltmaları yoktur. Adlandırılmış bir çoğaltmanın yük devretmesi için öncelikle yeni bir çoğaltma oluşturulması gerekir ve bu genellikle yaklaşık 1-2 dakika sürer. Ancak, adlandırılmış çoğaltmalar HA çoğaltmaları tarafından sağlanan daha yüksek kullanılabilirlik ve daha kısa yük devretmelerden de yararlanabilir. Adlandırılmış bir çoğaltma için HA çoğaltmaları eklemek için AZ CLI ile parametresiniha-replicas, PowerShell ile parametresini highAvailabilityReplicaCount HighAvailabilityReplicaCount veya REST API ile özelliğini kullanabilirsiniz. Adlandırılmış çoğaltma oluşturulurken HA çoğaltmalarının sayısı ayarlanabilir ve adlandırılmış çoğaltma oluşturulduktan sonra her zaman yalnızca AZ CLI, PowerShell veya REST API aracılığıyla değiştirilebilir. Adlandırılmış çoğaltmalar için HA çoğaltmalarının fiyatlandırması, normal Hiper Ölçek veritabanları için HA çoğaltmalarıyla aynıdır.

Evet. Sütun Ana Anahtarı kullanıcı veritabanında depolanır ve sorgu SELECT * FROM sys.column_master_keysyürütülerek doğrulanabilir. Adlandırılmış çoğaltmalar ve yüksek kullanılabilirlik ikincil çoğaltmaları, birincil Hiper Ölçek veritabanıyla aynı sayfa sunucularından/depolama katmanından verileri okur. Her iki çoğaltma türü de günlük hizmeti aracılığıyla birincil Hiper Ölçek veritabanıyla eşitlenir. Anahtar değişikliği bir işlem olarak kabul edilir ve adlandırılmış çoğaltmaya ve yüksek kullanılabilirliğe sahip ikincil çoğaltmaya otomatik olarak çoğaltılır.

DATABASEPROPERTYEX() İşlev, adlandırılmış bir çoğaltma bağlamında yürütülürken öğesini karşılık gelen adlandırılmış çoğaltmasıyla replica_id eşleyebilir. Ancak, şu anda birincil çoğaltmadan sorgulandığında dinamik yönetim görünümündeki sys.dm_database_replica_states her kayıt için öğesini ilgili adlandırılmış çoğaltmasına bağlamak replica_id mümkün değildir. Aşağıdaki örnek sorgu, adlandırılmış bir çoğaltmanın bağlamında çalıştırılarak çoğaltma adı, çoğaltma kimliği ve eşitleme ayrıntıları tanımlanabilir.

  SELECT replica_id, DB_NAME() AS 'Database/Replica name', 
  synchronization_state_desc, log_send_queue_size/1024.0/1024.0 AS log_send_queue_size_gb,
  last_sent_time, last_received_time, last_commit_time, secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE replica_id = DATABASEPROPERTYEX(DB_NAME(),'REPLICAID');

İlgili içerik

Hiper Ölçek hizmet katmanı hakkında daha fazla bilgi için bkz . Hiper Ölçek hizmet katmanı.