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

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

Bu makalede, bu SSS'nin geri kalanında yalnızca Hiper Ölçek olarak adlandırılan Azure SQL Veritabanı Hiper Ölçek hizmet katmanındaki bir veritabanını göz önünde bulunduran müşteriler için sık sorulan soruların yanıtları verilmektedir. Bu makalede Hiper Ölçek'in desteklediği senaryolar ve Hiper Ölçek ile uyumlu özellikler açıklanmaktadır.

  • Bu SSS, Hiper Ölçek hizmet katmanını kısa bir şekilde anlayan ve belirli sorularını ve endişelerini yanıtlayan okuyuculara yöneliktir.
  • Bu SSS, bir kılavuz defteri veya Hiper Ölçek veritabanının nasıl kullanılacağıyla ilgili soruları yanıtlamak için tasarlanmamıştır. Hiper Ölçek'e giriş için Azure SQL Veritabanı Hiper Ölçek belgelerine başvurmanızı öneririz.

Genel sorular

Hiper Ölçek veritabanı nedir?

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

Hangi kaynak türleri ve satın alma modelleri Hiper Ölçek'i destekler?

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

Hiper Ölçek hizmet katmanının Genel Amaçlı ve İş Açısından Kritik hizmet katmanlarından farkı nedir?

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ını kimler kullanmalıdır?

Hiper Ölçek hizmet katmanı daha yüksek performans ve kullanılabilirliğe, hızlı yedekleme ve geri yüklemeye ve/veya hızlı depolama ve işlem ölçeklenebilirliğine ihtiyacı olan tüm müşterilere yöneliktir. Uygulamalarını modernleştirmek için buluta geçen müşterilerle Azure SQL Veritabanı’nda diğer hizmet katmanlarını zaten kullanmakta olan müşteriler de buna dahildir. Hiper Ölçek ile şunları elde edersiniz:

  • 100 TB'a kadar veritabanı boyutu
  • Veritabanı boyutundan bağımsız olarak hızlı veritabanı yedeklemeleri (yedeklemeler depolama anlık görüntülerine dayanır)
  • Veritabanı boyutundan bağımsız olarak hızlı veritabanı geri yüklemeleri (geri yüklemeler depolama anlık görüntülerine dayanır)
  • Veritabanı boyutu ile sanal çekirdek sayısından bağımsız olarak daha yüksek günlük aktarım hızı
  • Okuma yükünü boşaltmak için ve etkin beklemeler olarak kullanılan bir veya birden fazla salt okunur çoğaltmanın kullanıldığı Okuma Amaçlı Ölçeği Genişletme.
  • 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. Bu, örneğin 4 çekirdekli ve 32 çekirdekli veritabanı arasında ölçeği artırmaya ve azaltmaya benzer, ancak bu bir veri işlemi boyutu olmadığından çok daha hızlıdır.

Hiper Ölçek şu anda hangi bölgeler tarafından desteklenmeli?

Hiper Ölçek hizmet katmanı, Azure SQL Veritabanı'nın kullanılabildiği tüm bölgelerde kullanılabilir.

Sunucu başına birden çok Hiper Ölçek veritabanı oluşturabilir miyim?

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

Hiper Ölçek veritabanının performans özellikleri nelerdir?

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

Hiper Ölçek veritabanının ölçeklenebilirliği nedir?

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 ölçeği sabit bir süre içinde azaltabilirsiniz. Depolama alanı uzak olduğundan ölçeği artırma ve azaltma, veri işleminin boyutu değildir.

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

    Hiper Ölçek ile okuma ölçeği genişletme, yüksek kullanılabilirlik ve coğrafi çoğaltma gereksinimlerini karşılamak 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 görevi görür. Bunları, okuma iş yüklerini birincil iş yükünden 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 etkinleştirmek için farklı bir Azure bölgesinde coğrafi çoğaltma .

Ayrıntılı sorular

Hiper Ölçek ile tek veritabanlarını tek bir sunucuda karıştırabilir miyim?

Evet, yazabilirsiniz.

Hiper Ölçek için uygulama programlama modelimin değiştirilmesi gerekiyor mu?

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

Hiper Ölçek veritabanında varsayılan işlem yalıtım düzeyi nedir?

Birincil çoğaltmada varsayılan işlem yalıtım düzeyi RCSI'dir (Kaydedilen 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 Azure SQL DB veritabanlarındakiyle aynıdır.

Şirket içi veya IaaS SQL Server lisansımı Hiper Ölçek'e getirebilir miyim?

Evet, Azure Hibrit Avantajı Hiper Ölçek için kullanılabilir. Her SQL Server Standard çekirdeği 1 Hiper Ölçek sanal çekirdeğine eşlenebilir. Her SQL Server Enterprise çekirdeği 4 Hiper Ölçek sanal çekirdeğine eşlenebilir. İkincil çoğaltmalar için SQL lisansına ihtiyacınız yoktur. Azure Hibrit Avantajı fiyatı, Okuma Ölçeği Genişletme (ikincil) çoğaltmalarına otomatik olarak uygulanır.

Hiper Ölçek ne tür iş yükleri için tasarlanmıştır?

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

Azure Synapse Analytics ile Azure SQL Veritabanı Hiper Ölçeği arasında nasıl seçim yapabilirim?

Şu anda veri ambarı olarak SQL Server kullanarak etkileşimli analiz sorguları çalıştırıyorsanız, küçük ve orta ölçekli veri ambarlarını (örneğin, 100 TB'a kadar birkaç TB) daha düşük bir maliyetle barındırabileceğiniz ve SQL Server veri ambarı iş yüklerinizi en düşük T-SQL kod değişiklikleriyle 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 Data Warehouse (PDW), Teradata veya diğer Yüksek Düzeyde Paralel İşleme (MPP) veri ambarlarını kullanıyorsanız Azure Synapse Analytics en iyi seçenek olabilir.

Hiper ölçek işlem soruları

İşlemimi herhangi bir zamanda duraklatabilir miyim?

Ancak şu anda değil, ancak yoğun olmayan zamanlarda maliyeti azaltmak için işleminizi ve çoğaltma sayısını azaltabilirsiniz.

Yoğun bellek kullanan iş yüküm için fazladan RAM içeren bir işlem çoğaltması sağlayabilir miyim?

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ı.

Farklı boyutlarda birden çok işlem çoğaltması sağlayabilir miyim?

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

Kaç Tane Okuma Ölçeği Genişletme çoğaltması desteklenir?

Azure portal veya REST API 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.

Yüksek kullanılabilirlik için ek işlem çoğaltmaları sağlamam gerekiyor mu?

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ının kullanılabilir olması durumunda saniyeler 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 az yük devretme etkisiyle yüksek kullanılabilirlik gerektiren görev açısından kritik uygulamalar için en az bir HA ikincil çoğaltması sağlamalısınız. Bu şekilde, yük devretme hedefi olarak hizmet veren bir etkin bekleme çoğaltması vardır.

Veri boyutu ve depolama soruları

Hiper Ölçek ile desteklenen veritabanı boyutu üst sınırı nedir?

100 TB.

Hiper Ölçek ile işlem günlüğünün boyutu nedir?

Hiper Ölçek'teki işlem günlüğü neredeyse sonsuzdur ve tek bir işlemin 1 TB'tan fazla günlük oluşturamaması kısıtlaması vardır. Ayrıca, Değişiklik Verileri Yakalama kullanılıyorsa, en eski etkin işlemin başlangıcından bu yana en fazla 1 TB günlük oluşturulabilir. Bu sınırın altında kalmak için gereksiz büyük işlemlerden kaçınmanızı öneririz. Belirtilen kısıtlamalar dışında, yüksek günlük aktarım hızına sahip bir sistemde günlük alanının bitmesi konusunda endişelenmenize gerek yoktur. 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.

'tempdb' veritabanım büyüdükçe ölçeklendiriliyor mu?

Veritabanınız tempdb yerel SSD depolama alanında bulunur ve sağladığınız işlem boyutuyla (çekirdek sayısı) orantılı olarak boyutlandırılır. tempdb boyutu 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ı.

Veritabanımın boyutu otomatik olarak büyüyor mu yoksa veri dosyalarının boyutunu yönetmem mi gerekiyor?

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

Hiper Ölçek'in desteklediği en küçük veritabanı boyutu nedir?

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

Veritabanımın boyutu hangi artışlarla büyüyor?

Her veri dosyası 10 GB büyür. Aynı anda birden çok veri dosyası büyüyebilir.

Depolama Hiper Ölçek'te yerel mi yoksa uzak mı?

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. Ayrıca, 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.

Hiper Ölçek ile dosyaları veya dosya gruplarını yönetebilir veya tanımlayabilir miyim?

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ı'nda daha geniş bir şekilde geçerli değildir.

Veritabanım için veri büyümesi konusunda kesin bir sınır sağlayabilir miyim?

Hayır.

Veritabanı küçültmesi destekleniyor mu?

Şu anda değil.

Veri sıkıştırma destekleniyor mu?

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

Çok büyük bir tablom varsa tablo verileri birden çok veri dosyası arasında yayılır mı?

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

Veri geçişi soruları

Azure SQL Veritabanındaki mevcut veritabanlarımı Hiper Ölçek hizmet katmanına taşıyabilir miyim?

Evet. Azure SQL Veritabanındaki 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 kısalır.

Var olan Azure SQL Veritabanlarını Azure portal, Azure CLI, PowerShell ve Transact-SQL'de Hiper Ölçek'e geçirmek için 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ı'ndaki mevcut bir veritabanını Hiper Ölçek hizmet katmanına yakın zamanda geçiren müşterilerin geri taşınmasını sağlar. Tersine geçiş bir hizmet katmanı değişikliğiyle başlatılmış olsa da, temelde farklı mimariler arasında veri boyutu işlemidir. Hiper Ölçek'e geçişe benzer şekilde, yazma etkinliğinin düşük olduğu bir dönemde ters geçiş daha hızlı olur. Ters geçişle ilgili sınırlamaları öğrenin.

Hiper Ölçek veritabanlarımı diğer hizmet katmanlarına taşıyabilir miyim?

Daha önce mevcut bir Azure SQL Veritabanını 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 tersine 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.

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

Hiper Ölçek hizmet katmanına geçiş sonrasında herhangi bir işlevi veya özelliği kaybeder miyim?

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ş sonrasında 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.

Şirket içi SQL Server veritabanımı veya bulut sanal makinesindeki SQL Server veritabanımı Hiper Ölçek'e taşıyabilir miyim?

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 bakın.

Şirket içi veya sanal makine ortamından Hiper Ölçek'e geçiş sırasında kapalı kalma süresi nedir ve bunu nasıl en aza indirebilirim?

Hiper Ölçek'e geçiş için kapalı kalma süresi, veritabanlarınızı diğer Azure SQL Veritabanı hizmet katmanlarına geçirdiğinizdeki kapalı kalma süresiyle aynıdır. Birkaç TB boyutuna 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'e X miktarda veri getirmek ne kadar zaman alır?

Hiper Ölçek 100 MB/sn yeni/değiştirilmiş veri kullanabilir, ancak Azure SQL Veritabanındaki 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.

Blob depolamadan veri okuyabilir ve hızlı yükleme yapabilir miyim (Azure Synapse Analytics'te Polybase gibi)?

İstemci uygulamasının Azure Depolama'dan veri okumasını ve hiper ölçek veritabanına veri yüklemesine (Azure SQL Veritabanı'ndaki diğer veritabanlarında olduğu gibi) sahip olabilirsiniz. Polybase şu anda Azure SQL Veritabanında desteklenmiyor. Hızlı yük sağlamaya alternatif olarak Azure Data Factory kullanabilir veya SQL için Spark bağlayıcısı ile Azure Databricks'te spark işi kullanabilirsiniz. SQL'e Spark bağlayıcısı toplu ekleme işlemini 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 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 oranı sağlar.

Hiper Ölçek, büyük miktarlarda verilerin paralel olarak alımı için birden çok düğüm sağlanmasına izin verir mi?

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

Hiper Ölçek Amazon Aurora, MySQL, PostgreSQL, Oracle, DB2 ve diğer veritabanı platformları gibi diğer veri kaynaklarından geçişi destekliyor mu?

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

İş sürekliliği ve olağanüstü durum kurtarma soruları

Hiper Ölçek veritabanı için hangi SLA'lar sağlanır?

Bkz. Azure SQL Veritabanı için 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.

Veritabanı yedeklemeleri benim için Azure SQL Veritabanı tarafından mı yönetiliyor?

Evet.

Hiper Ölçek Kullanılabilirlik Alanları destekliyor mu?

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 1 HA ikincil çoğaltması ve alanlar arası yedekli veya coğrafi alanlar arası yedekli depolama kullanılması gerekir.

Veritabanı yedeklemeleri ne sıklıkta alınır?

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ü temposu ile 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 için 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, bekletme süresi içinde belirtilen noktadan itibaren herhangi bir veri kaybı olmadan işlem açısından tutarlı bir veritabanı elde edilmesine neden olur. Aslında Hiper Ölçek'te veritabanı yedeklemesi süreklidir.

Hiper Ölçek belirli bir noktaya geri yüklemeyi destekliyor mu?

Evet.

Hiper Ölçek'te veritabanı geri yükleme için Kurtarma Noktası Hedefi (RPO)/Kurtarma Süresi Hedefi (RTO) nedir?

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 bu noktaya kadar önemli bir yazma etkinliğiyle karşılaşmış olabilir.

Veritabanı yedeklemesi birincil veya ikincil çoğaltmalarımdaki işlem performansını etkiler mi?

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

Hiper Ölçek veritabanıyla coğrafi geri yükleme gerçekleştirebilir miyim?

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

Hiper Ölçek veritabanıyla coğrafi çoğaltma ayarlayabilir miyim?

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

Hiper Ölçek veritabanı yedeğini alıp şirket içi sunucuma veya vm'deki SQL Server geri yükleyebilir miyim?

Hayır. Hiper Ölçek veritabanlarının depolama biçimi, SQL Server'nin yayımlanan sürümlerinden farklıdır ve yedeklemeleri denetlemez veya bunlara erişiminiz yoktur. Verilerinizi hiper ölçek veritabanından çıkarmak için Azure Data Factory, Azure Databricks, SSIS gibi veri taşıma teknolojilerini kullanarak verileri ayıklayabilirsiniz.

Hiper Ölçek'teki yedekleme depolama maliyetleri için ücretlendirilecek miyim?

Evet. 4 Mayıs 2022'de geçerli olacak şekilde, 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 süresi 7 günden uzun olacak şekilde ayarlandıysa ücretlendirilir. Daha fazla bilgi edinmek için bkz. Hiper Ölçek yedeklemeleri ve depolama yedekliliği.

Hiper Ölçek veritabanımda yedekleme depolama boyutunu nasıl ölçebilirim?

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

Yedekleme faturamın ne olacağını Nasıl yaparım? biliyor musunuz?

Yedekleme depolama faturanızı belirlemek için, yedekleme depolama alanı 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 alanı 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.

İş yüküm yedekleme depolama maliyetlerimi nasıl etkileyecek?

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 maliyetlerini nasıl en aza indirebilirim?

Yedekleme depolama maliyetlerinin en aza indirilmesiyle ilgili ayrıntılar Otomatik Yedeklemeler'de yakalanır.

Performans soruları

Hiper Ölçek veritabanında ne kadar yazma aktarım hızı gönderebilirim?

İş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ızın elde edilebilmesi, iş yükü türü, istemci yapılandırması ve performansı ve bu hızda günlük 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.

En büyük işlemde kaç IOPS alabilirim?

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

Aktarım hızım yedeklemelerden etkileniyor mu?

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

Ek işlem çoğaltmaları sağladığımda aktarım hızım etkileniyor mu?

Depolama 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 eklendiğinden doğrudan etkilenmez. Ancak, günlüğün ikincil çoğaltmalara ve sayfa sunucularına uygulanmasına izin vermek için birincilde sürekli agresif yazma iş yüklerini kısıtlarız. Bu, ikincil çoğaltmalarda düşük okuma performansını ve HA ikincil çoğaltmasına yük devretmeden sonra uzun kurtarmayı önler.

Hiper Ölçek yoğun kaynak kullanan, uzun süre çalışan sorgular ve işlemler için uygun mu?

Evet. Ancak, diğer Azure SQL DB veritabanlarında olduğu gibi, bağlantılar ç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 bir nedeni, 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 bir süre içinde tamamlanmaktadır. Veritabanınıza bağlanan uygulamalar, yeniden deneme mantığı uygulanarak bu seyrek geçici hataları beklenecek ve tolere edilecek şekilde oluşturulmalıdır. 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.

Hiper Ölçek veritabanındaki performans sorunlarını tanılamak ve gidermek Nasıl yaparım??

Performans sorunlarının çoğu için, özellikle de depolama performansında kökü olmayanlar 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ı.

Ölçeklenebilirlik ile ilgili sorular

İşlem çoğaltması ölçeğini artırmak ve küçültmek ne kadar sürer?

İşlemin ölçeğini artırma veya azaltma genellikle veri boyutundan bağımsız olarak 2 dakikaya kadar sürer.

Ölçeği artırma/azaltma işlemi devam ederken veritabanım çevrimdışı mı?

Hayır. Ölçeği artırma ve azaltma çevrimiçi olacaktır.

Ölçeklendirme işlemleri devam ederken bağlantının düşmesini beklemeli miyim?

Mevcut işlemin ölçeğini artırmak veya küçültmek, ölçeklendirme işleminin sonunda yük devretme gerçekleştiğinde bağlantıların bırakılmasına neden olur. İkincil çoğaltmaların eklenmesi veya kaldırılması, birincil çoğaltmada bağlantı kesilmesine neden olmaz.

İşlem çoğaltmalarının ölçeğini artırma ve azaltma işlemi otomatik mi yoksa son kullanıcı tarafından tetiklenen işlem mi?

Son kullanıcı. Otomatik değil.

İşlem ölçeklendirildikçe 'tempdb' veritabanımın ve RBPEX önbelleğimin boyutu da büyüyor mu?

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

Birden çok birincil işlem kafasının daha yüksek düzeyde eşzamanlılık sağlayabildiği çoklu ana bilgisayar sistemi gibi birden çok birincil işlem çoğaltması sağlayabilir miyim?

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.

Ölçeği genişletme sorularını okuma

Hiper Ölçek'te hangi tür ikincil (okuma ölçeğini genişletme) çoğaltmalar kullanılabilir?

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ı .

Kaç HA ikincil çoğaltması sağlayabilirim?

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

HA ikincil çoğaltmasına bağlanmak Nasıl yaparım??

Bağlantı dizenizdeki özelliğini olarak ayarlayarak ApplicationIntent bu ek salt okunur işlem çoğaltmalarına ReadOnlybağlanabilirsiniz. ile ReadOnly işaretlenen tüm bağlantılar, veritabanınız için eklenmişse otomatik olarak HA ikincil çoğaltmalarından birine yönlendirilir. Ayrıntılar için bkz. Salt okunur sorgu iş yüklerinin yükünü boşaltmak için salt okunur çoğaltmaları kullanma.

Nasıl yaparım? SQL Server Management Studio (SSMS) veya diğer istemci araçlarını kullanarak ikincil işlem çoğaltmasına başarıyla bağlanılıp bağlanmadığım doğrulansın mı?

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

HA ikincil çoğaltması için ayrılmış uç nokta oluşturabilir miyim?

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.

Sistem, HA ikincil çoğaltmalarında okuma iş yükünün akıllı yük dengelemesini yapıyor mu?

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

HA ikincil çoğaltmalarının ölçeğini birincil çoğaltmadan bağımsız olarak artırabilir/azaltabilir miyim?

Hayır. HA ikincil çoğaltmaları yüksek kullanılabilirlik yük devretme hedefleri olarak kullanılır, bu nedenle yük devretme sonrasında beklenen performansı sağlamak için birincil ile aynı yapılandırmaya sahip olmaları gerekir. Adlandırılmış çoğaltmalar, her çoğaltmayı bağımsız olarak ölçeklendirme olanağı sağlar.

Birincil işlemim ve HA ikincil çoğaltmalarım için farklı 'tempdb' boyutlandırması alabilir miyim?

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ı boyuttadır. 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.

İkincil işlem çoğaltmalarıma dizinler ve görünümler ekleyebilir miyim?

Hayır. Hiper ölçek veritabanlarının paylaşılan depolama alanı vardır; diğer bir deyişle tüm işlem çoğaltmaları aynı tabloları, dizinleri ve diğer veritabanı nesnelerini görür. İkincilde 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 ## ön ekli tablo adları) oluşturabilirsiniz. Geçici tablolar okuma-yazmadır.

Birincil ve ikincil işlem çoğaltmaları arasında ne kadar gecikme olacak?

Bir işlemin birincilde işlendiği zamandan ikincilde okunabilir duruma kadar olan veri gecikme süresi, 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 milisaniye cinsindendir, ancak veri gecikme süresinde üst sınır yoktur. Belirli bir ikincil çoğaltmadaki veriler her zaman işlem açısından 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.

Adlandırılmış çoğaltma yük devretme hedefi olarak kullanılabilir mi?

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.

Adlandırılmış çoğaltmalarımda salt okunur bir iş yükünü nasıl dağıtabilirim?

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ıldığından, 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; tüm 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şturmaya örnek olarak olTP ölçeği genişletme örneği verilebilir.

Adlandırılmış çoğaltma, birincil çoğaltmanın bölgesinden farklı bir bölgede olabilir mi?

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 veya performansını etkileyebilir mi?

Adlandırılmış çoğaltma, birincil çoğaltmanın kullanılabilirliğini etkileyemez. Adlandırılmış çoğaltmaların normal koşullarda birincil çoğaltmanın 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üğünü yeterince hızlı kullanamıyorsa, birincil çoğaltmadan günlük oluşturma işlemini yavaşlatıp azaltmasını istemeye başlar, böylece bunu yakalayabilir. Bu davranış birincilin kullanılabilirliğini etkilemese de, yazma iş yüklerinin birincil üzerindeki performansını etkileyebilir. Bu durumdan kaçınmak için adlandırılmış çoğaltmalarınızın işlem günlüğünü gecikmeden işlemek için yeterli kaynak alanı (özellikle CPU) olduğundan emin olun. Örneğin, birincil çok sayıda veri değişikliği işliyorsa, çoğaltmalarda CPU'nun doymasını önlemek ve dolayısıyla birincili yavaşlatmaya zorlamak için birincil ile en az aynı Hizmet Düzeyi Hedefine sahip adlandırılmış çoğaltmaların olması önerilir.

Birincil çoğaltma kullanılamıyorsa, örneğin planlı bakım nedeniyle adlandırılmış çoğaltmalara ne olur?

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

Adlandırılmış çoğaltmaların kullanılabilirliğini nasıl geliştirebilirim?

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 yüksek kullanılabilirlik ve HA çoğaltmaları tarafından sağlanan daha kısa yük devretmelerden de yararlanabilir. Adlandırılmış çoğaltma için HA çoğaltmaları eklemek için AZ CLI ile parametresiniha-replicas, PowerShell ile parametresini HighAvailabilityReplicaCount veya highAvailabilityReplicaCountREST 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 herhangi bir zamanda 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.

Sonraki adımlar

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