Migrasi database di Azure SQL Database dari model DTU ke model vCore
Berlaku untuk: 
Azure SQL Database
Artikel ini menjelaskan cara migrasi database Anda di Azure SQL Database dari model pembelian berbasis DTU ke model pembelian berbasis vCore.
Migrasi database
Migrasi database dari model pembelian berbasis DTU ke model pembelian berbasis vCore mirip dengan penskalaan antara tujuan layanan di tingkat layanan Dasar, Standar, dan Premium, dengan durasi yang sama dan waktu henti minimal di akhir proses migrasi. Database yang dimigrasikan ke model pembelian berbasis vCore dapat dimigrasikan kembali ke model pembelian berbasis DTU kapan saja menggunakan langkah yang sama, kecuali untuk database yang dimigrasikan ke tingkat layanan Hyperscale .
Anda dapat memigrasikan database Anda ke model pembelian yang berbeda dengan menggunakan portal Azure, PowerShell, Azure CLI, dan Transact-SQL.
Untuk memigrasikan database Anda ke model pembelian yang berbeda dengan menggunakan portal Azure, ikuti langkah-langkah berikut:
Buka database SQL Anda di portal Azure.
Pilih Komputasi + penyimpanan di bawah Pengaturan.
Gunakan daftar dropdown di bawah Tingkat layanan untuk memilih model pembelian dan tingkat layanan baru:
Pilih tingkat layanan vCore dan tujuan layanan
Untuk sebagian besar skenario migrasi DTU ke vCore, database, dan kumpulan elastis di tingkat layanan Dasar dan Standar dipetakan ke tingkat layanan Tujuan Umum. Database dan kumpulan elastis di peta tingkat layanan Premium ke tingkat layanan Business Critical . Bergantung pada skenario dan persyaratan aplikasi, tingkat layanan Hyperscale sering dapat digunakan sebagai target migrasi untuk database dan kumpulan elastis di semua tingkat layanan DTU.
Untuk memilih tujuan layanan, atau ukuran komputasi, untuk database yang dimigrasikan dalam model vCore, Anda dapat menggunakan aturan praktis dasar tetapi perkiraan: setiap 100 DTU di tingkat Dasar atau Standar memerlukan setidaknya 1 vCore, dan setiap 125 DTU di tingkat Premium memerlukan setidaknya 1 vCore.
Tip
Aturan ini perkiraan karena tidak mempertimbangkan jenis perangkat keras tertentu yang digunakan untuk database DTU atau kumpulan elastis.
Dalam model DTU, sistem dapat memilih konfigurasi perangkat keras yang tersedia untuk database atau kumpulan elastis Anda. Selanjutnya, dalam model DTU, Anda hanya memiliki kontrol tidak langsung atas jumlah vCore (CPU logis), dengan memilih nilai DTU atau eDTU yang lebih tinggi atau lebih rendah.
Pada model vCore, pelanggan harus membuat pilihan eksplisit pada konfigurasi perangkat keras dan jumlah vCore (CPU logis). Meskipun model DTU tidak menawarkan pilihan ini, jenis perangkat keras, dan jumlah CPU logis yang digunakan untuk setiap database dan kumpulan elastis diekspos melalui tampilan manajemen dinamis. Ini memungkinkan untuk menentukan tujuan layanan vCore yang cocok dengan lebih tepat.
Pendekatan berikut menggunakan informasi ini untuk menentukan tujuan layanan vCore dengan alokasi sumber daya yang sama, untuk mendapatkan tingkat performa yang sama setelah migrasi ke model vCore.
Pemetaan DTU ke vCore
Kueri Transact-SQL berikut, ketika dijalankan dalam konteks database DTU yang akan dimigrasikan, mengembalikan jumlah vCore yang cocok (mungkin pecahan) di setiap konfigurasi perangkat keras dalam model vCore. Anda dapat membulatkan angka ini ke jumlah vCore terdekat yang tersedia untuk database dan kumpulan elastis di setiap konfigurasi perangkat keras dalam model vCore, pelanggan dapat memilih tujuan layanan vCore yang paling cocok untuk database DTU atau kumpulan elastis mereka.
Sampel skenario migrasi menggunakan pendekatan ini dijelaskan di bagian Contoh.
Jalankan kueri ini dalam konteks database yang akan dimigrasikan, bukan dalam database master. Saat Anda memigrasikan kumpulan elastis, jalankan kueri dalam konteks database apa pun di kumpulan.
;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;
Faktor tambahan
Selain jumlah vCore (CPU logis) dan jenis perangkat keras, beberapa faktor lain mungkin memengaruhi pilihan tujuan layanan vCore:
Pemetaan kueri Transact-SQL cocok dengan tujuan layanan DTU dan vCore dalam hal kapasitas CPU mereka, oleh karena itu hasilnya lebih akurat untuk beban kerja yang terikat CPU.
Untuk jenis perangkat keras yang sama dan jumlah vCore, IOPS, dan batas sumber daya throughput log transaksi yang sama untuk database vCore sering lebih tinggi daripada database DTU. Untuk beban kerja terikat IO, mungkin untuk menurunkan jumlah vCore dalam model vCore untuk mencapai tingkat performa yang sama. Batas sumber daya aktual untuk DTU dan database vCore ditampilkan di tampilan sys.dm_user_db_resource_governance. Membandingkan nilai-nilai ini antara database atau kumpulan DTU yang akan dimigrasikan, dan database atau kumpulan vCore dengan tujuan layanan yang kurang lebih cocok dapat membantu Anda memilih tujuan layanan vCore dengan lebih tepat.
Kueri pemetaan juga mengembalikan jumlah memori per inti untuk database DTU atau kumpulan elastis yang akan dimigrasikan, dan untuk setiap konfigurasi perangkat keras dalam model vCore. Memastikan memori total yang sama atau lebih tinggi setelah migrasi ke vCore penting untuk beban kerja yang memerlukan cache data memori besar untuk mencapai performa yang memadai, atau beban kerja yang memerlukan peruntukan memori besar untuk pemrosesan kueri. Untuk beban kerja tersebut, tergantung pada performa aktual, mungkin perlu untuk meningkatkan jumlah vCore untuk mendapatkan memori total yang memadai.
Pemanfaatan sumber daya historis database DTU harus dipertimbangkan ketika memilih tujuan layanan vCore. Database DTU dengan sumber daya CPU yang kurang digunakan secara konsisten mungkin memerlukan lebih sedikit vCore daripada angka yang dikembalikan oleh kueri pemetaan. Sebaliknya, database DTU di mana pemanfaatan CPU yang tinggi secara konsisten menyebabkan performa beban kerja yang tidak memadai mungkin memerlukan lebih banyak vCore daripada yang dikembalikan oleh kueri.
Jika memigrasikan database dengan pola penggunaan terputus-terputus atau tidak dapat diprediksi, pertimbangkan penggunaan tingkat komputasi Tanpa Server untuk tingkat komputasi Azure SQL Database . Jumlah maksimum pekerja bersamaan dalam tanpa server adalah 75% dari batas dalam komputasi yang disediakan untuk jumlah vCore maks yang sama yang dikonfigurasi. Selain itu, memori maks yang tersedia tanpa server adalah 3 GB kali jumlah maksimum vCores dikonfigurasi, yang kurang dari memori per-core untuk komputasi yang disediakan. Misalnya, pada memori maks Gen5 adalah 120 GB ketika 40 maks vCore dikonfigurasi dalam tanpa server, vs. 204 GB untuk 40 komputasi tersedia vCore.
Dalam model vCore, ukuran database maksimum yang didukung mungkin berbeda tergantung pada perangkat keras. Untuk database besar, periksa ukuran maks yang didukung dalam model vCore untuk database tunggal dan kumpulan elastis.
Untuk kumpulan elastis, batas Sumber Daya untuk kumpulan elastis menggunakan model pembelian DTU dan model vCore memiliki perbedaan dalam jumlah maksimum database yang didukung per kumpulan. Ini harus dipertimbangkan ketika Anda memigrasikan kumpulan elastis dengan banyak database.
Beberapa konfigurasi perangkat keras mungkin tidak tersedia di setiap wilayah. Periksa ketersediaan di Konfigurasi perangkat keras untuk SQL Database.
Panduan ukuran DTU ke vCore yang disediakan di bagian ini membantu dalam estimasi awal tujuan layanan database target.
Konfigurasi optimal database target tergantung pada beban kerja. Dengan demikian, untuk mencapai rasio harga/performa optimal setelah migrasi, Anda mungkin perlu menggunakan fleksibilitas model vCore untuk menyesuaikan jumlah vCore, konfigurasi perangkat keras, dan tingkat layanan dan komputasi. Anda mungkin juga perlu menyesuaikan parameter konfigurasi database, seperti tingkat paralelisme maksimum, dan/atau mengubah tingkat kompatibilitas database untuk mengaktifkan peningkatan terbaru di mesin database.
Contoh migrasi DTU ke vCore
Catatan
Nilai dalam contoh berikut hanya untuk tujuan ilustrasi. Nilai aktual yang dikembalikan dalam skenario yang dijelaskan mungkin berbeda.
Migrasi database S9 Standar
Kueri pemetaan mengembalikan hasil berikut (beberapa kolom tidak diperlihatkan untuk keringkasan):
| dtu_logical_cpus | dtu_memory_per_core_gb | standard_series_vcores | standard_series_memory_per_core_gb |
|---|---|---|---|
| 24.00 | 5,40 | 24.000 | 5,05 |
Kami melihat bahwa database standar DTU memiliki 24 CPU logis (vCore), dengan memori 5,4 GB per vCore. Kecocokan langsung dengan yang merupakan database General Purpose 2 vCore pada perangkat keras seri standar (Gen5), tujuan layanan GP_Gen5_24 vCore.
Migrasi database S0 Standar
Kueri pemetaan mengembalikan hasil berikut (beberapa kolom tidak diperlihatkan untuk keringkasan):
| dtu_logical_cpus | dtu_memory_per_core_gb | standard_series_vcores | standard_series_memory_per_core_gb |
|---|---|---|---|
| 0.25 | 1.3 | 0.500 | 5,05 |
Kita melihat bahwa database DTU memiliki CPU logis (vCore) 0,25 yang setara, dengan memori 1,3 GB per vCore. Tujuan layanan vCore terkecil dalam konfigurasi perangkat keras seri standar (Gen5), GP_Gen5_2, menyediakan lebih banyak sumber daya komputasi daripada database S0 Standar, sehingga kecocokan langsung tidak dimungkinkan. Opsi GP_Gen5_2 lebih disukai. Selain itu, jika beban kerja sangat cocok untuk tingkat komputasi Tanpa Server, maka GP_S_Gen5_1 akan menjadi yang paling cocok.
Migrasi database P15 Premium
Kueri pemetaan mengembalikan hasil berikut (beberapa kolom tidak diperlihatkan untuk keringkasan):
| dtu_logical_cpus | dtu_memory_per_core_gb | standard_series_vcores | standard_series_memory_per_core_gb |
|---|---|---|---|
| 42.00 | 4,86 | 42.000 | 5,05 |
Kita melihat bahwa database DTU memiliki 42 CPU logis (vCore), dengan memori 4,86 GB per vCore. Meskipun tidak ada tujuan layanan vCore dengan 42 core, tujuan layanan BC_Gen5_40 hampir setara dalam hal kapasitas CPU dan memori, dan merupakan kecocokan yang baik.
Migrasi kumpulan elastis 200 eDTU Dasar
Kueri pemetaan mengembalikan hasil berikut (beberapa kolom tidak diperlihatkan untuk keringkasan):
| dtu_logical_cpus | dtu_memory_per_core_gb | standard_series_vcores | standard_series_memory_per_core_gb |
|---|---|---|---|
| 4.00 | 5,40 | 4.000 | 5,05 |
Kita melihat bahwa kumpulan elastis DTU memiliki 4 CPU logis (vCore), dengan memori 5,4 GB per vCore. Namun, panggilan perangkat keras seri standar untuk 4 vCore, tujuan layanan ini mendukung maksimum 200 database per kumpulan, sementara kumpulan elastis eDTU Dasar 200 mendukung hingga 500 database. Jika kumpulan elastis yang akan dimigrasikan memiliki lebih dari 200 database, tujuan layanan vCore yang cocok harus GP_Gen5_6, yang mendukung hingga 500 database.
Migrasi database yang direplikasi geografis
Migrasi dari model berbasis DTU ke model pembelian berbasis vCore mirip dengan meningkatkan atau menurunkan hubungan replikasi geografis antara database di tingkat layanan Standar dan Premium. Selama migrasi, Anda tidak perlu menghentikan replikasi geografis untuk tingkat General Purpose dan Business Critical Service, tetapi Anda harus mengikuti aturan pengurutan ini:
- Saat meningkatkan, sebaiknya Anda meningkatkan database sekunder terlebih dahulu, lalu meningkatkan database utama.
- Saat menurunkan tingkat, balik urutannya: turunkan database utama terlebih dahulu, lalu turunkan database sekunder.
Untuk bermigrasi ke tingkat layanan Hyperscale, replikasi geografis harus dihapus sementara. Untuk informasi selengkapnya, lihat Memigrasikan database yang sudah ada ke Hyperscale.
Saat Anda menggunakan replikasi geografis antara dua kumpulan elastis, kami sarankan Anda menunjuk satu kumpulan sebagai kumpulan utama dan yang lainnya sebagai sekunder. Dalam hal ini, ketika Anda memigrasikan kumpulan elastis, Anda harus menggunakan panduan pengurutan yang sama. Namun, jika Anda memiliki kumpulan elastis yang berisi database primer dan sekunder, perlakukan kumpulan dengan pemanfaatan yang lebih tinggi sebagai yang utama dan ikuti aturan pengurutan yang sesuai.
Tabel berikut ini menyediakan panduan untuk skenario migrasi tertentu:
| Tingkat layanan saat ini | Tingkat layanan target | Tipe migrasi | Tindakan pengguna |
|---|---|---|---|
| Standard | Tujuan Umum | Lateral | Dapat bermigrasi dalam urutan apa pun, tetapi perlu memastikan ukuran vCore yang sesuai seperti yang dijelaskan sebelumnya |
| Premium | Kritis Bisnis | Lateral | Dapat bermigrasi dalam urutan apa pun, tetapi perlu memastikan ukuran vCore yang sesuai seperti yang dijelaskan sebelumnya |
| Standard | Kritis Bisnis | Mutakhirkan | Harus migrasikan sekunder terlebih dahulu |
| Kritis Bisnis | Standard | Menurunkan | Harus migrasikan primer terlebih dahulu |
| Premium | Tujuan Umum | Menurunkan | Harus migrasikan primer terlebih dahulu |
| Tujuan Umum | Premium | Mutakhirkan | Harus migrasikan sekunder terlebih dahulu |
| Kritis Bisnis | Tujuan Umum | Menurunkan | Harus migrasikan primer terlebih dahulu |
| Tujuan Umum | Bisnis Kritis | Mutakhirkan | Harus migrasikan sekunder terlebih dahulu |
| Standard | Hyperscale | Lateral | Replikasi geografis yang akan dinonaktifkan sebelum migrasi ke Hyperscale |
| Premium | Hyperscale | Lateral | Replikasi geografis yang akan dinonaktifkan sebelum migrasi ke Hyperscale |
Migrasi grup failover
Migrasi grup failover dengan beberapa database memerlukan migrasi individu database utama dan sekunder. Selama proses itu, pertimbangan dan aturan pengurutan yang sama berlaku. Setelah database dikonversi ke model pembelian berbasis vCore, grup failover akan tetap berlaku dengan pengaturan kebijakan yang sama.
Buat database sekunder geo-replikasi
Anda dapat membuat database sekunder geo-replikasi (geo-sekunder) hanya dengan menggunakan tingkat layanan yang sama seperti yang Anda gunakan untuk database utama. Untuk database dengan tingkat pembuatan log tinggi, sebaiknya buat geo-sekunder dengan ukuran komputasi yang sama dengan yang utama.
Jika Anda membuat geo-sekunder di kumpulan elastis untuk database utama tunggal, pastikan maxVCore pengaturan untuk kumpulan cocok dengan ukuran komputasi database utama. Jika Anda membuat geo-sekunder untuk primer di kumpulan elastis lain, sebaiknya kumpulan memiliki pengaturan yang sama maxVCore .
Menggunakan salinan database untuk migrasi dari DTU ke vCore
Salinan database membuat rekam jepret data yang konsisten secara transaksional pada titik waktu setelah operasi penyalinan dimulai. Ini tidak menyinkronkan data antara sumber dan target setelah titik waktu itu.
Anda dapat menyalin database apa pun dengan ukuran komputasi berbasis DTU ke database dengan ukuran komputasi berbasis vCore dengan menggunakan PowerShell, Azure CLI, atau Transact-SQL tanpa batasan atau pengurutan khusus, selama ukuran komputasi target mendukung ukuran database maksimum database sumber. Menyalin database ke tingkat layanan lain tidak didukung di portal Azure.