Azure SQL Veritabanı DTU tabanlı modelden sanal çekirdek tabanlı modele geçirme

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

Bu makalede, Azure SQL Veritabanı veritabanınızı DTU tabanlı satın alma modelinden sanal çekirdek tabanlı satın alma modelinegeçirme açıklanmaktadır.

Veritabanı taşıma

Veritabanını DTU tabanlı satın alma modelinden sanal çekirdek tabanlı satın alma modeline geçirmek, Temel , Standart ve Premium hizmet katmanlarında hizmet hedefleri arasında benzer süre ve geçiş işleminin sonunda minimum kapalı kalma süresiyle ölçeklendirmeye benzer. Sanal çekirdek tabanlı satın alma modeline geçirilen bir veritabanı, Hiper Ölçek hizmet katmanına geçirilen veritabanları dışında, aynı adımlar kullanılarak herhangi bir zamanda DTU tabanlı satın alma modeline geri geçirilebilir.

Azure portalı, PowerShell, Azure CLI ve Transact-SQL kullanarak veritabanınızı farklı bir satın alma modeline geçirebilirsiniz.

$parameters = @{
     ResourceGroupName = "<resource group name>"
     DatabaseName = "<database name>"
     ServerName = "<server name>"
     Edition = "<service tier, such as Hyperscale>"
     RequestedServiceObjectiveName = "<hardware such as HS_Gen5_2>"
}

Set-AzSqlDatabase @parameters

az sql db update --resource-group "<resource group name>" --server "<server name>" --name "<database name>" --edition <service tier, such as Hyperscale> --capacity 4 --family Gen5

ALTER DATABASE <database name> MODIFY (EDITION = '<service tier, such as Hyperscale>');

Sanal çekirdek hizmet katmanını ve hizmet hedefini seçin

Çoğu DTU'dan sanal çekirdeğe geçiş senaryosu için, Temel ve Standart hizmet katmanlarındaki veritabanları ve elastik havuzlar Genel Amaçlı hizmet katmanıyla eşleşir. Premium hizmet katmanındaki veritabanları ve elastik havuzlar, İş Açısından Kritik hizmet katmanıyla eşlenir. Uygulama senaryosuna ve gereksinimlerine bağlı olarak Hiper Ölçek hizmet katmanı genellikle tüm DTU hizmet katmanlarında veritabanları ve elastik havuzlar için geçiş hedefi olarak kullanılabilir.

Sanal çekirdek modelinde geçirilen veritabanı için hizmet hedefini veya işlem boyutunu seçmek için temel ama yaklaşık bir temel kural kullanabilirsiniz: Temel veya Standart katmanlardaki her 100 DTU en az 1 sanal çekirdek gerektirir ve Premium katmanındaki her 125 DTU en az 1 sanal çekirdek gerektirir.

DTU modelinde sistem veritabanınız veya elastik havuzunuz için kullanılabilir donanım yapılandırmasını seçebilir. Ayrıca, DTU modelinde daha yüksek veya daha düşük DTU veya eDTU değerleri seçerek sanal çekirdek sayısı (mantıksal CPU) üzerinde yalnızca dolaylı denetime sahip olursunuz.

Sanal çekirdek modelinde müşterilerin hem donanım yapılandırması hem de sanal çekirdek sayısı (mantıksal CPU) için açık bir seçim yapmaları gerekir. DTU modeli bu seçenekleri sunmasa da, donanım türü ve her veritabanı ve elastik havuz için kullanılan mantıksal CPU sayısı dinamik yönetim görünümleri aracılığıyla kullanıma sunulur. Bu, eşleşen sanal çekirdek hizmeti hedefini daha hassas bir şekilde belirlemeyi mümkün kılar.

Aşağıdaki yaklaşım, sanal çekirdek modeline geçiş sonrasında benzer bir performans düzeyi elde etmek üzere benzer kaynak ayırmaya sahip bir sanal çekirdek hizmet hedefini belirlemek için bu bilgileri kullanır.

DTU'dan Sanal Çekirdeğe Eşleme

Aşağıdaki Transact-SQL sorgusu, taşınacak DTU veritabanı bağlamında yürütüldüğünde, sanal çekirdek modelindeki her donanım yapılandırmasında eşleşen (belki kesirli) sanal çekirdek sayısını döndürür. Bu sayıyı sanal çekirdek modelindeki her donanım yapılandırmasında veritabanları ve elastik havuzlar için kullanılabilen en yakın sanal çekirdek sayısına yuvarlayabilirsiniz. Müşteriler, DTU veritabanı veya elastik havuzu için en yakın eşleşen sanal çekirdek hizmet hedefini seçebilir.

Bu yaklaşımı kullanan örnek geçiş senaryoları Örnekler bölümünde açıklanmıştır.

Bu sorguyu, master veritabanında değil, taşınacak veritabanı bağlamında yürütün. Bir elastik havuzu taşırken, sorguyu havuzdaki herhangi bir veritabanı bağlamında yürütün.

;WITH dtu_vcore_map
AS (
    SELECT rg.slo_name,
        CAST(DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS NVARCHAR(40)) COLLATE DATABASE_DEFAULT AS dtu_service_tier,
        CASE 
            WHEN slo.slo_name LIKE '%SQLG4%' THEN 'Gen4' --Gen4 is retired.
            WHEN slo.slo_name LIKE '%SQLGZ%' THEN 'Gen4' --Gen4 is retired.
            WHEN slo.slo_name LIKE '%SQLG5%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG6%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG7%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%GPGEN8%' THEN 'standard_series'
            END COLLATE DATABASE_DEFAULT AS dtu_hardware_gen,
        s.scheduler_count * CAST(rg.instance_cap_cpu / 100. AS DECIMAL(3, 2)) AS dtu_logical_cpus,
        CAST((jo.process_memory_limit_mb / s.scheduler_count) / 1024. AS DECIMAL(4, 2)) AS dtu_memory_per_core_gb
    FROM sys.dm_user_db_resource_governance AS rg
    CROSS JOIN (
        SELECT COUNT(1) AS scheduler_count
        FROM sys.dm_os_schedulers
        WHERE status COLLATE DATABASE_DEFAULT = 'VISIBLE ONLINE'
        ) AS s
    CROSS JOIN sys.dm_os_job_object AS jo
    CROSS APPLY (SELECT UPPER(rg.slo_name) COLLATE DATABASE_DEFAULT AS slo_name) slo
    WHERE rg.dtu_limit > 0
        AND DB_NAME() COLLATE DATABASE_DEFAULT <> 'master'
        AND rg.database_id = DB_ID()
)
SELECT dtu_logical_cpus,
    dtu_memory_per_core_gb,
    dtu_service_tier,
    CASE 
        WHEN dtu_service_tier = 'Basic' THEN 'General Purpose'
        WHEN dtu_service_tier = 'Standard' THEN 'General Purpose or Hyperscale'
        WHEN dtu_service_tier = 'Premium' THEN 'Business Critical or Hyperscale'
        END AS vcore_service_tier,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.7
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus
        END AS standard_series_vcores,
    5.05 AS standard_series_memory_per_core_gb,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.8
        END AS Fsv2_vcores,
    1.89 AS Fsv2_memory_per_core_gb,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.4
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.9
        END AS M_vcores,
    29.4 AS M_memory_per_core_gb
FROM dtu_vcore_map;

Ek faktörler

Sanal çekirdek sayısı (mantıksal CPU' lar) ve donanım türüne ek olarak, sanal çekirdek hizmet hedefinin seçimini etkileyen başka birçok faktör de olabilir:

• Eşleme Transact-SQL sorgusu, CPU kapasitesi açısından DTU ve sanal çekirdek hizmet hedefleriyle eşleşir, bu nedenle sonuçlar CPU'ya bağlı iş yükleri için daha doğru olur.

• Aynı donanım türü ve aynı sayıda sanal çekirdek için, sanal çekirdek veritabanları için IOPS ve işlem günlüğü aktarım hızı kaynak sınırları genellikle DTU veritabanlarına göre daha yüksektir. Girdi/Çıktı'ya bağlı iş yüklerinde, aynı performans düzeyine ulaşmak için vCore modelindeki sanal çekirdek sayısını azaltmak mümkün olabilir. DTU ve sanal çekirdek veritabanları için gerçek kaynak sınırları sys.dm_user_db_resource_governance görünümünde gösterilir. Geçirilecek DTU veritabanı veya havuzu ile yaklaşık eşleşen hizmet hedefine sahip bir sanal çekirdek veritabanı veya havuzu arasındaki bu değerleri karşılaştırmak sanal çekirdek hizmet hedefini daha hassas bir şekilde seçmenize yardımcı olabilir.

• Haritalama sorgusu, geçirilecek DTU veritabanı veya elastik havuz için ve ayrıca vCore modelindeki her bir donanım yapılandırması için çekirdek başına bellek miktarını döndürür. Sanal çekirdek geçişten sonra benzer veya daha yüksek toplam bellek sağlamak, yeterli performans elde etmek için büyük bir bellek veri önbelleği gerektiren iş yükleri veya sorgu işleme için büyük bellek izinleri gerektiren iş yükleri için önemlidir. Bu tür iş yüklerinde, gerçek performansa bağlı olarak, yeterli toplam bellek elde etmek için sanal çekirdek sayısını artırmak gerekebilir.

• Sanal çekirdek hizmet hedefi seçilirken DTU veritabanının geçmiş kaynak kullanımı dikkate alınmalıdır. Sürekli olarak az kullanılan CPU kaynaklarına sahip DTU veritabanları, eşleme sorgusu tarafından döndürülen sayıdan daha az sanal çekirdek gerektirebilir. Buna karşılık, sürekli yüksek CPU kullanımının yetersiz iş yükü performansına neden olduğu DTU veritabanları sorgu tarafından döndürülenden daha fazla sanal çekirdek gerektirebilir.

• Aralıklı veya öngörülemeyen kullanım desenlerine sahip veritabanlarını geçiriyorsanız, Azure SQL Veritabanı işlem katmanı için Sunucusuz işlem katmanı kullanımını göz önünde bulundurun. Sunucusuz durumdaki en fazla eş zamanlı çalışan sayısı, sağlanan işlemde yapılandırılan en fazla sanal çekirdek sayısı için sınırın %75'idir. Ayrıca sunucusuz olarak kullanılabilen maksimum bellek, yapılandırılan sanal çekirdek sayısının en fazla 3 GB katıdır ve sağlanan işlem için çekirdek başına bellekten daha azdır. Örneğin, Gen5'te sunucusuz olarak yapılandırıldığında, 40 maksimum sanal çekirdek için maksimum bellek 120 GB'tır; ancak, sağlanmış 40 sanal çekirdekli işlemde bu değer 204 GB'tır.

• Sanal çekirdek modelinde desteklenen maksimum veritabanı boyutu donanıma bağlı olarak farklılık gösterebilir. Büyük veritabanları için tek veritabanları ve elastik havuzlar için sanal çekirdek modelinde desteklenen maksimum boyutları kontrol edin.

• Elastik havuzlar için, DTU satın alma modelini ve sanal çekirdek modellerini kullanan elastik havuzlar için kaynak sınırları, havuz başına desteklenen veritabanı sayısı üst sınırında farklılık gösterir. Birçok veritabanıyla elastik havuzları geçirirken bu dikkate alınmalıdır.

• Bazı donanım yapılandırmaları her bölgede kullanılamayabilir. SQL Veritabanı için donanım yapılandırması altında kullanılabilirliği denetleyin.

Bu bölümde sağlanan DTU-sanal çekirdek boyutlandırma yönergeleri, hedef veritabanı hizmeti hedefinin ilk tahmininde yardımcı olur.

Hedef veritabanının en iyi yapılandırması iş yüküne bağlıdır. Bu nedenle, geçiş sonrasında en uygun fiyat/performans oranını elde etmek için sanal çekirdek, donanım yapılandırması ve hizmet ve işlem katmanı sayısını ayarlamak için sanal çekirdek modelinin esnekliğini kullanmanız gerekebilir. Ayrıca, maksimum paralellik derecesi gibi veritabanı yapılandırma parametrelerini ayarlamanız ve/veya veritabanı altyapısında son geliştirmeleri etkinleştirmek için veritabanı uyumluluk düzeyini değiştirmeniz gerekebilir.

DTU'dan sanal çekirdeğe geçiş örnekleri

Standart S9 veritabanını taşıma

Eşleme sorgusu aşağıdaki sonucu döndürür (bazı sütunlar kısa için gösterilmez):

DTU standart veritabanında sanal çekirdek başına 5,4 GB belleğe sahip 24 mantıksal CPU (sanal çekirdek) olduğunu görüyoruz. Bunun doğrudan eşleşmesi, GP_Gen5_24 sanal çekirdek hizmeti hedefi olan standart seri (5. Nesil) donanımdaki Genel Amaçlı 2 sanal çekirdek veritabanıdır.

Standart S0 veritabanını taşıma

Eşleme sorgusu aşağıdaki sonucu döndürür (bazı sütunlar kısa için gösterilmez):

DTU veritabanının sanal çekirdek başına 1,3 GB bellek ile 0,25 mantıksal CPU'ya (vÇekirdek) eşdeğer olduğunu görüyoruz. Standart seri (5. Nesil) donanım yapılandırmasındaki en küçük sanal çekirdek hizmet hedefleri olan GP_Gen5_2, Standart S0 veritabanından daha fazla işlem kaynağı sağladığından doğrudan eşleşme mümkün değildir. GP_Gen5_2 seçeneği tercih edilir. Ayrıca, iş yükü Sunucusuz işlem katmanı için uygunsa, GP_S_Gen5_1 daha yakın bir eşleşme olacaktır.

Premium P15 veritabanını taşıma

Eşleme sorgusu aşağıdaki sonucu döndürür (bazı sütunlar kısa için gösterilmez):

DTU veritabanında sanal çekirdek başına 4,86 GB belleğe sahip 42 mantıksal CPU (sanal çekirdek) olduğunu görüyoruz. 42 çekirdekli sanal çekirdek hizmet hedefi olmasa da, BC_Gen5_40 hizmet hedefi CPU ve bellek kapasitesi açısından neredeyse eşdeğerdir ve iyi bir eşleşmedir.

Temel 200 eDTU elastik havuzunu taşıma

Eşleme sorgusu aşağıdaki sonucu döndürür (bazı sütunlar kısa için gösterilmez):

DTU elastik havuzunun sanal çekirdek başına 5,4 GB belleğe sahip 4 mantıksal CPU'ya (sanal çekirdek) sahip olduğunu görüyoruz. Standart seri donanım 4 sanal çekirdek için çağrıda bulunur, ancak bu hizmet hedefi havuz başına en fazla 200 veritabanını desteklerken, Temel 200 eDTU elastik havuzu en fazla 500 veritabanını destekler. Geçirilecek elastik havuzda 200'den fazla veritabanı varsa, eşleşen sanal çekirdek hizmeti hedefinin en fazla 500 veritabanını destekleyen GP_Gen5_6 olması gerekir.

Coğrafi olarak çoğaltılan veritabanlarını taşıma

DTU tabanlı modelden sanal çekirdek tabanlı satın alma modeline geçiş yapmak, Standart ve Premium hizmet katmanlarındaki veritabanları arasındaki coğrafi çoğaltma ilişkilerini yükseltmeye veya düşürmeye benzer. Geçiş sırasında, Genel Amaçlı ve İş Açısından Kritik Hizmet katmanları için coğrafi çoğaltmayı durdurmanız gerekmez, ancak şu sıralama kurallarına uymanız gerekir:

• Yükseltme sırasında önce ikincil veritabanını yükseltmeniz ve ardından birincil veritabanını yükseltmeniz gerekir.
• Sürüm düşürme sırasında sırayı tersine çevirin: Önce birincil veritabanını düşürmeniz ve ardından ikincil veritabanını düşürmeniz gerekir.

Veritabanını Hiper Ölçek hizmet katmanına dönüştürmek için coğrafi çoğaltma geçici olarak kaldırılmalıdır. Daha fazla bilgi için bkz. Var olan veritabanını Hiper Ölçekdönüştürme.

İki elastik havuz arasında coğrafi çoğaltma kullandığınızda, bir havuzu birincil, diğerini ikincil havuz olarak atamanızı öneririz. Bu durumda, esnek havuzları geçirirken aynı sıralama kılavuzunu kullanmanız gerekir. Ancak, hem birincil hem de ikincil veritabanları içeren elastik havuzlarınız varsa, havuzu birincil olarak daha yüksek kullanımla değerlendirin ve buna göre sıralama kurallarına uyun.

Aşağıdaki tabloda belirli geçiş senaryoları için rehberlik sağlanmaktadır:

Yük devretme gruplarını taşıma

Birden çok veritabanı içeren yük devretme gruplarının geçişi, birincil ve ikincil veritabanlarının her birinin ayrı ayrı geçirilmesini gerektirir. Bu işlem sırasında dikkat edilmesi gerekenler ve sıralama kuralları aynı şekilde uygulanır. Veritabanları sanal çekirdek tabanlı satın alma modeline dönüştürüldükten sonra, yük devretme grubu aynı ilke ayarlarıyla etkin kalır.

Coğrafi çoğaltma için bir ikincil veritabanı oluşturma

Bir coğrafi çoğaltma ikincil veritabanı (coğrafi ikincil) oluşturmak için yalnızca birincil veritabanı için kullandığınız hizmet katmanını kullanarak oluşturabilirsiniz. Yüksek günlük oluşturma hızına sahip veritabanları için, birincil ile aynı hesaplama kapasitesine sahip coğrafi ikincil kopya oluşturmanızı öneririz.

Tek bir birincil veritabanı için elastik havuzda coğrafi olarak ikincil bir veritabanı oluşturursanız, havuz ayarının maxVCore birincil veritabanının işlem boyutuyla eşleştiğinden emin olun. Başka bir elastik havuzdaki birincil için coğrafi ikincil oluşturursanız havuzların aynı maxVCore ayarlara sahip olması önerilir.

DTU'dan sanal çekirdek'e geçiş yapmak için veritabanı kopyasını kullanma

Veritabanı kopyası, kopyalama işlemi başlatıldıktan sonra belirli bir noktada verilerin işlem açısından tutarlı bir anlık görüntüsünü oluşturur. Bu noktadan sonra kaynak ve hedef arasındaki verileri eşitlemez.

Hedef işlem boyutu kaynak veritabanının en büyük veritabanı boyutunu desteklediği sürece, kısıtlama veya özel sıralama olmadan PowerShell, Azure CLI veya Transact-SQL kullanarak DTU tabanlı işlem boyutuna sahip herhangi bir veritabanını sanal çekirdek tabanlı işlem boyutuna sahip bir veritabanına kopyalayabilirsiniz. Veritabanını farklı bir hizmet katmanına kopyalamak Azure portalında desteklenmez.

İlgili içerik

• Sanal çekirdek satın alma modeli kullanıldığında tek veritabanları için kaynak sınırları
• Sanal çekirdek satın alma modeli kullanıldığında elastik havuzlar için kaynak sınırları