Menskalakan sumber daya database tunggal di Azure SQL Database
Berlaku untuk: 
Azure SQL Database
Artikel ini menjelaskan cara menskalakan sumber daya komputasi dan penyimpanan yang tersedia untuk Azure SQL Database di tingkat komputasi yang disediakan. Sebagai alternatif, tingkat komputasi tanpa server menyediakan penskalaan otomatis komputasi dan tagihan per detik untuk komputasi yang digunakan.
Setelah pada awalnya memilih jumlah vCore atau DTU, Anda dapat menskalakan database tunggal ke atas atau ke bawah secara dinamis berdasarkan pengalaman aktual menggunakan:
Penting
Dalam beberapa keadaan, Anda mungkin perlu menyusutkan database untuk mengklaim kembali ruang yang tidak digunakan. Untuk informasi selengkapnya, lihat Mengelola ruang file untuk database di Azure SQL Database.
Catatan
ID Microsoft Entra sebelumnya dikenal sebagai Azure Active Directory (Azure AD).
Dampak
Mengubah tingkat layanan atau ukuran komputasi utamanya melibatkan layanan yang melakukan langkah-langkah berikut:
Buat instans komputasi baru untuk database.
Sebuah instans komputasi baru dibuat dengan tingkat layanan dan ukuran komputasi yang diminta. Untuk beberapa kombinasi tingkat layanan dan perubahan ukuran komputasi, replika setiap database harus dibuat di instans komputasi baru, yang melibatkan salinan data dan dapat dengan kuat mempengaruhi latensi secara keseluruhan. Terlepas dari itu, database akan tetap online selama langkah ini, dan koneksi berlanjut untuk diarahkan ke database dalam instans komputasi asli.
Alihkan perutean koneksi ke instans komputasi baru.
Koneksi yang sudah ada ke database dalam instans komputasi asli akan dihilangkan. Setiap koneksi baru dibuat ke database dalam instans komputasi baru. Untuk beberapa kombinasi tingkat layanan dan perubahan ukuran komputasi, file database dicopot dan dipasang kembali selama pengalihan. Terlepas dari itu, pengalihan dapat menyebabkan gangguan layanan singkat ketika database tidak tersedia secara umum selama kurang dari 30 detik dan sering juga hanya selama beberapa detik. Jika ada transaksi jangka panjang yang berjalan ketika koneksi terputus, durasi langkah ini dapat memakan waktu lebih lama untuk memulihkan transaksi yang dibatalkan. Pemulihan Database yang Dipercepat di Azure SQL dapat mengurangi dampak dari membatalkan transaksi yang berjalan lama.
Penting
Tidak ada data yang hilang selama proses langkah apa pun dalam alur kerja. Pastikan Anda telah menerapkan beberapa logika coba lagi dalam aplikasi dan komponen yang menggunakan Azure SQL Database ketika tingkat layanan diubah.
Latensi
Estimasi latensi untuk mengubah tingkat layanan, menskalakan ukuran komputasi database tunggal atau kumpulan elastis, memindahkan database ke/dari kumpulan database elastis, atau memindahkan database di antara kumpulan elastis diberi parameter sebagai berikut:
| Latensi penskalaan database | Ke Database tunggal Dasar, database tunggal Standar (S0-S1) |
Ke Database tunggal Standar (S2-S12), database tunggal Tujuan Umum, Database kumpulan elastis dasar, database kumpulan elastis Standar, database kumpulan Tujuan Umum |
Ke Database tunggal Premium atau database terkumpul, database tunggal Business Critical atau database terkumpul |
Ke database tunggal Hyperscale atau database terkumpul |
|---|---|---|---|---|
| Dari database tunggal Dasar, database tunggal Standar (S0-S1) |
• Latensi waktu konstan independen dari ruang yang digunakan. • Biasanya, kurang dari 5 menit. |
• Latensi proporsional dengan ruang database yang digunakan karena penyalinan data. • Biasanya, kurang dari 1 menit per GB ruang yang digunakan. |
• Latensi proporsional dengan ruang database yang digunakan karena penyalinan data. • Biasanya, kurang dari 1 menit per GB ruang yang digunakan. |
• Latensi proporsional dengan ruang database yang digunakan karena penyalinan data. • Biasanya, kurang dari 1 menit per GB ruang yang digunakan. |
| Dari database kumpulan Dasar, database tunggal Standar (S2-S12), Database terkumpul standar, database tunggal Tujuan Umum atau database terkumpul |
• Latensi proporsional dengan ruang database yang digunakan karena penyalinan data. • Biasanya, kurang dari 1 menit per GB ruang yang digunakan. |
• Untuk database tunggal, latensi waktu konstan independen dari ruang yang digunakan. • Biasanya, kurang dari 5 menit untuk database tunggal. • Untuk kumpulan elastis, sebanding dengan jumlah database. |
• Latensi proporsional dengan ruang database yang digunakan karena penyalinan data. • Biasanya, kurang dari 1 menit per GB ruang yang digunakan. |
• Latensi proporsional dengan ruang database yang digunakan karena penyalinan data. • Biasanya, kurang dari 1 menit per GB ruang yang digunakan. |
| Dari database tunggal Premium atau database terkumpul, database tunggal Business Critical atau database terkumpul |
• Latensi proporsional dengan ruang database yang digunakan karena penyalinan data. • Biasanya, kurang dari 1 menit per GB ruang yang digunakan. |
• Latensi proporsional dengan ruang database yang digunakan karena penyalinan data. • Biasanya, kurang dari 1 menit per GB ruang yang digunakan. |
• Latensi proporsional dengan ruang database yang digunakan karena penyalinan data. • Biasanya, kurang dari 1 menit per GB ruang yang digunakan. |
• Latensi proporsional dengan ruang database yang digunakan karena penyalinan data. • Biasanya, kurang dari 1 menit per GB ruang yang digunakan. |
| Dari database tunggal Hyperscale atau database terkumpul | T/A | Lihat Migrasi terbalik dari Hyperscale untuk skenario dan batasan yang didukung. | T/A | • Latensi waktu konstan independen dari ruang yang digunakan. • Biasanya, kurang dari 2 menit. |
Catatan
- Selain itu, untuk database Standard (S2-S12) dan Tujuan Umum, latensi untuk memindahkan database ke/dari kumpulan elastis atau di antara kumpulan elastis akan sebanding dengan ukuran database jika database menggunakan penyimpanan Premium File Share (PFS).
- Dalam hal memindahkan database ke/dari kumpulan elastis, hanya ruang yang digunakan database memberi dampak latensi, bukan ruang yang digunakan kumpulan elastis.
- Untuk menentukan apakah database menggunakan penyimpanan PFS, jalankan kueri berikut dalam konteks database. Jika nilai kolom AccountType adalah
PremiumFileStorageatauPremiumFileStorage-ZRS, kumpulan menggunakan penyimpanan PFS.
SELECT s.file_id,
s.type_desc,
s.name,
FILEPROPERTYEX(s.name, 'AccountType') AS AccountType
FROM sys.database_files AS s
WHERE s.type_desc IN ('ROWS', 'LOG');
Catatan
- Properti zona redundan akan tetap sama secara default saat menskalakan database tunggal dari tingkat Business Critical ke Tujuan Umum.
- Latensi untuk operasi penskalaan ketika redundansi zona diubah untuk database tunggal Tujuan Umum sebanding dengan ukuran database.
Tip
Untuk memantau operasi yang sedang berlangsung, lihat: Mengelola operasi menggunakan SQL REST API, Mengelola operasi menggunakan CLI, Memantau operasi menggunakan T-SQL dan dua perintah PowerShell ini: Get-AzSqlDatabaseActivity dan Stop-AzSqlDatabaseActivity.
Memantau atau membatalkan perubahan penskalakan
Operasi perubahan tingkat layanan atau penskalaan ulang komputasi dapat dipantau dan dibatalkan.
Di halaman Gambaran Umum database SQL, cari banner yang menunjukkan operasi penskalaan sedang berlangsung, dan pilih tautan Lihat selengkapnya untuk penyebaran yang sedang berlangsung.
Pada halaman Operasi yang sedang berlangsung, pilih Batalkan operasi ini.
Izin
Untuk menskalakan database melalui Transact-SQL: ALTER DATABASE digunakan. Untuk menskalakan database, data masuk harus berupa login admin server (dibuat saat server logis Azure SQL Database disediakan), admin Microsoft Entra server, anggota peran database dbmanager di master, anggota peran database db_owner dalam database saat ini, atau dbo database. Untuk mengetahui informasi selengkapnya, lihat ALTER DATABASE.
Untuk menskalakan database melalui peran portal Azure, PowerShell, Azure CLI, atau REST API: Azure RBAC diperlukan, khususnya peran Kontributor, Kontributor SQL DB, atau Kontributor SQL Server Azure RBAC. Untuk informasi selengkapnya, lihat Peran bawaan Azure RBAC.
Pertimbangan tambahan
- Jika Anda meningkatkan ke tingkat layanan atau ukuran komputasi yang lebih tinggi, ukuran maksimum database tidak bertambah kecuali Anda secara eksplisit menentukan ukuran yang lebih besar (ukuran maksimum).
- Untuk menurunkan tingkat database, ruang yang digunakan database harus lebih kecil dari ukuran maksimum yang diperbolehkan dari tingkat layanan target dan ukuran komputasi.
- Saat menurunkan tingkat dari Premium ke tingkat Standar, biaya penyimpanan tambahan berlaku jika (1) ukuran maksimum database didukung dalam ukuran komputasi target, dan (2) ukuran maksimum melebihi jumlah penyimpanan yang disertakan dari ukuran komputasi target. Misalnya, jika database P1 dengan ukuran maksimum 500 GB dirampingkan ke S3, maka biaya penyimpanan tambahan berlaku karena S3 mendukung ukuran maksimum 1 TB dan jumlah penyimpanan yang disertakan hanya 250 GB. Jadi, jumlah penyimpanan tambahan 500 GB – 250 GB = 250 GB. Untuk harga penyimpanan tambahan, lihat biaya Azure SQL Database. Jika jumlah aktual ruang yang digunakan kurang dari jumlah penyimpanan yang ada di dalam, maka biaya tambahan ini dapat dihindari dengan mengurangi ukuran maksimum database menjadi jumlah yang ada di dalamnya.
- Saat meningkatkan database dengan replikasi geo diaktifkan, tingkatkan database sekundernya ke tingkat layanan yang diinginkan dan ukuran komputasi sebelum meningkatkan database utama (panduan umum untuk performa terbaik). Saat meningkatkan ke edisi yang berbeda, persyaratannya adalah database sekunder harus ditingkatkan terlebih dahulu.
- Saat menurunkan tingkat database dengan replikasi geo diaktifkan, turunkan tingkat database utamanya ke tingkat layanan yang diinginkan dan ukuran komputasi sebelum menurunkan database sekunder (panduan umum untuk performa terbaik). Saat menurunkan tingkat ke edisi yang berbeda, persyaratannya adalah database utama harus diturunkan terlebih dahulu.
- Penawaran layanan pemulihan berbeda untuk berbagai tingkat layanan. Jika Anda menurunkan ke tingkat Dasar, ada periode retensi cadangan yang lebih rendah. Lihat Pencadangan otomatis di Azure SQL Database.
- Properti baru untuk database tidak diterapkan hingga perubahan selesai.
- Saat penyalinan data diperlukan untuk menskalakan database (lihat Latensi) saat mengubah tingkat layanan, pemanfaatan sumber daya tinggi bersamaan dengan operasi penskalaan dapat menyebabkan waktu penskalaan yang lebih lama. Dengan Accelerated Database Recovery (ADR), pemutaran kembali transaksi jangka panjang bukanlah sumber penundaan yang signifikan, tetapi penggunaan sumber daya bersamaan yang tinggi mungkin meninggalkan lebih sedikit sumber daya komputasi, penyimpanan, dan bandwidth jaringan untuk penskalaan, terutama untuk ukuran komputasi yang lebih kecil.
Billing
Anda menerima tagihan untuk setiap jam database yang ada yang menggunakan tingkat layanan tertinggi + aturan komputasi yang berlaku selama jam itu, terlepas penggunaan apakah database aktif selama kurang dari sejam. Contohnya, jika Anda membuat database tunggal dan menghapusnya lima menit kemudian tagihan Anda menunjukkan tagihan untuk satu jam database.
Mengubah ukuran penyimpanan
Model pembelian berbasis vCore
Penyimpanan dapat disediakan hingga batas ukuran maksimum penyimpanan data menggunakan kenaikan 1-GB. Penyimpanan data minimum yang dapat dikonfigurasi adalah 1 GB. Untuk batas ukuran maksimum penyimpanan data di setiap tujuan layanan, lihat halaman dokumentasi batas sumber daya untuk batas Sumber Daya untuk database tunggal menggunakan model pembelian vCore dan batas Sumber Daya untuk database tunggal menggunakan model pembelian DTU.
Penyimpanan data untuk satu database dapat diprovisikan dengan meningkatkan atau mengurangi ukuran maksimalnya menggunakan portal Microsoft Azure, T-SQL, PowerShell, Azure CLI, atau REST API. Jika nilai ukuran maks ditentukan dalam byte, nilai tersebut harus kelipatan 1 GB (1073741824 byte).
Jumlah data yang dapat disimpan dalam file data database dibatasi oleh ukuran maksimal penyimpanan data yang dikonfigurasi. Selain penyimpanan tersebut, Azure SQL Database secara otomatis menambahkan 30% lebih banyak penyimpanan yang akan digunakan untuk log transaksi. Harga penyimpanan untuk satu database atau kumpulan elastis adalah jumlah penyimpanan data dan jumlah penyimpanan log transaksi dikalikan dengan harga satuan penyimpanan tingkat layanan. Misalnya, jika penyimpanan data diatur ke 10 GB, penyimpanan log transaksi tambahan adalah 10 GB * 30% = 3 GB, dan jumlah total penyimpanan yang dapat ditagih adalah 10 GB + 3 GB = 13 GB.
Catatan
Ukuran maksimum file log transaksi dikelola secara otomatis, dan dalam beberapa kasus bisa lebih besar dari 30% dari ukuran maksimum penyimpanan data. Ini tidak meningkatkan harga penyimpanan untuk database.
Azure SQL Database secara otomatis mengalokasikan 32 GB per vCore untuk database
tempdb.tempdbterletak di penyimpanan SSD lokal di semua tingkat layanan. Biayatempdbtermasuk dalam harga database tunggal atau kumpulan elastis.Untuk detail tentang harga penyimpanan, lihat Harga Azure SQL Database.
Penting
Dalam beberapa keadaan, Anda mungkin perlu menyusutkan database untuk mengklaim kembali ruang yang tidak digunakan. Untuk informasi selengkapnya, lihat Mengelola ruang file untuk database di Azure SQL Database.
Model pembelian berbasis DTU
- Harga DTU untuk satu database mencakup sejumlah penyimpanan tanpa biaya tambahan. Penyimpanan tambahan di atas termasuk jumlah yang dapat disediakan dengan biaya tambahan ke batas ukuran maksimum dalam tambahan 250 GB hingga 1 TB dan kemudian dalam tambahan 256 GB di atas 1 TB. Untuk jumlah penyimpanan yang disertakan dan batas ukuran maksimum, lihat Database tunggal: Ukuran penyimpanan dan ukuran komputasi.
- Penyimpanan data untuk satu database dapat disediakan dengan meningkatkan atau mengurangi ukuran maksimalnya menggunakan portal Microsoft Azure T-SQL, PowerShell, Azure CLI, atau REST API.
- Harga penyimpanan ekstra untuk satu database adalah jumlah penyimpanan ekstra dikalikan dengan harga satuan penyimpanan ekstra dari tingkat layanan. Untuk detail harga penyimpanan tambahan, lihat Harga Azure SQL Database.
Penting
Dalam beberapa keadaan, Anda mungkin perlu menyusutkan database untuk mengklaim kembali ruang yang tidak digunakan. Untuk informasi selengkapnya, lihat Mengelola ruang file untuk database di Azure SQL Database.
Database yang direplikasi geografis
Untuk mengubah ukuran database sekunder yang direplikasi, ubah ukuran database utama. Perubahan ini kemudian akan direplikasi dan diimplementasikan pada database sekunder juga.
Batasan P11 dan P15 saat ukuran maks lebih besar dari 1 TB
Lebih dari 1 TB penyimpanan di tingkat Premium saat ini tersedia di semua wilayah kecuali: Tiongkok Timur, Tiongkok Utara, Jerman Tengah, dan Jerman Timur Laut. Di wilayah ini, maksimal penyimpanan di tingkat Premium dibatasi sebesar 1 TB. Pertimbangan dan batasan berikut berlaku untuk database P11 dan P15 dengan ukuran maksimum lebih besar dari 1 TB:
- Jika ukuran maksimum untuk database P11 atau P15 pernah diatur ke nilai yang lebih besar dari 1 TB, maka ia hanya dapat dipulihkan atau disalin ke database P11 atau P15. Selanjutnya, database dapat diskalakan ulang ke ukuran komputasi yang berbeda asalkan jumlah ruang yang dialokasikan pada saat operasi penghitungan ulang tidak melebihi batas ukuran maksimum dari ukuran komputasi baru.
- Untuk skenario replikasi geografis aktif:
- Menyiapkan hubungan replikasi geografis: Jika database utama adalah P11 atau P15, sekunder juga harus P11 atau P15. Ukuran komputasi yang lebih rendah ditolak sebagai sekunder karena tidak mampu mendukung lebih dari 1 TB.
- Meningkatkan database utama dalam hubungan replikasi geografis: Mengubah ukuran maksimum menjadi lebih dari 1 TB pada database utama memicu perubahan yang sama pada database sekunder. Kedua peningkatan harus berhasil agar perubahan pada primer berlaku. Batasan wilayah untuk opsi lebih dari 1-TB berlaku. Jika database sekunder berada di wilayah yang tidak mendukung lebih dari 1 TB, database utama tidak ditingkatkan.
- Penggunaan layanan Impor/Ekspor untuk memuat database P11/P15 dengan lebih dari 1 TB tidak didukung. Gunakan SqlPackage untuk mengimpor dan mengekspor data.