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 menu drop-down 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 akan dipetakan ke tingkat layanan Tujuan Umum. Database dan kumpulan elastis di tingkat layanan Premium akan di petakan 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 yang sederhana namun mendekati: setiap 100 DTUs dalam tingkat Dasar atau Standar memerlukan setidaknya 1 vCore, dan setiap 125 DTUs di tingkat Premium memerlukan setidaknya 1 vCore.
Tip
Aturan ini adalah perkiraan karena tidak mempertimbangkan jenis perangkat keras tertentu yang digunakan untuk database atau kumpulan elastis DTU.
Dalam model DTU, sistem mungkin memilih konfigurasi perangkat keras apa pun 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 T-SQL di bawah ini, ketika dijalankan dalam konteks database DTU yang akan dimigrasikan, mengembalikan jumlah vCore yang cocok (mungkin dalam 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 melakukan migrasi kumpulan elastis, jalankan kueri dalam konteks database apa pun dalam 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 dapat memengaruhi pilihan tujuan layanan vCore:
- Kueri T-SQL pemetaan cocok dengan tujuan layanan DTU dan vCore dalam hal kapasitas CPU mereka, oleh karena itu hasilnya akan 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 yang terikat IO, dimungkinkan untuk menurunkan jumlah vCore dalam model vCore untuk mencapai tingkat kinerja 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 akan 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 cukup.
- 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-putus atau tidak dapat diprediksi, pertimbangkan penggunaan tingkat komputasi Tanpa Server. Perhatikan bahwa jumlah maksimal pekerja serentak di tanpa server adalah 75% dari batas dalam komputasi yang diprovisikan untuk jumlah vCore maksimal 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, model DTU dan vCore memiliki perbedaan dalam jumlah database maks yang didukung per kumpulan. Ini harus dipertimbangkan ketika 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.
Penting
Pedoman ukuran DTU ke vCore di atas disediakan untuk membantu 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 memanfaatkan fleksibilitas model vCore untuk menyesuaikan jumlah vCore, konfigurasi perangkat keras, dan tingkat layanan serta komputasi. Anda mungkin juga perlu menyesuaikan parameter konfigurasi database, seperti tingkat maksimum paralelisme, dan/atau mengubah tingkat kompatibilitas database untuk mengaktifkan penyempurnaan baru dalam mesin database.
Contoh migrasi DTU ke vCore
Catatan
Nilai dalam contoh di bawah ini 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 geo-replikasi, tetapi Anda harus mengikuti aturan urutan 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.
Saat Anda menggunakan geo-replikasi di antara dua kumpulan elastis, kami sarankan Anda menunjuk satu kumpulan sebagai yang utama dan yang lainnya sebagai yang 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 di atas |
| Premium | Kritis Bisnis | Lateral | Dapat bermigrasi dalam urutan apa pun, tetapi perlu memastikan ukuran vCore yang sesuai seperti yang dijelaskan di atas |
| 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 |
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 satu database utama, pastikan pengaturan maxVCore untuk kumpulan cocok dengan ukuran komputasi database utama. Jika Anda membuat geo-sekunder untuk utama di kumpulan elastis lainnya, kami menyarankan agar kumpulan memiliki pengaturan maxVCore yang sama.
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.
Langkah berikutnya
- Untuk ukuran komputasi dan pilihan ukuran penyimpanan tertentu yang tersedia untuk database tunggal, lihat Batas sumber daya berbasis Azure SQL Database vCore untuk database tunggal.
- Untuk ukuran komputasi tertentu dan pilihan ukuran penyimpanan yang tersedia untuk kumpulan elastis, lihat Batas sumber daya berbasis Azure SQL Database vCore untuk kumpulan elastis.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk