Model pembelian vCore - Azure SQL Database

Berlaku untuk: Azure SQL Database

• Azure SQL Database
• Azure SQL Managed Instance

Artikel ini meninjau model pembelian vCore untuk Azure SQL Database.

Ikhtisar

Inti virtual (vCore) mewakili CPU logis dan menawarkan opsi untuk memilih karakteristik fisik perangkat keras (misalnya, jumlah inti, memori, dan ukuran penyimpanan). Model pembelian berbasis vCore memberi Anda fleksibilitas, kontrol, transparansi konsumsi sumber daya individual, dan cara mudah untuk menerjemahkan persyaratan beban kerja lokal ke cloud. Model ini mengoptimalkan harga, dan memungkinkan Anda memilih sumber daya komputasi, memori, dan penyimpanan berdasarkan kebutuhan beban kerja Anda.

Dalam model pembelian berbasis vCore, biaya Anda bergantung pada pilihan dan penggunaan:

• Tingkat layanan
• Konfigurasi perangkat keras
• Sumber daya komputasi (jumlah vCore dan jumlah memori)
• Penyimpanan basis data yang dialokasikan
• Penyimpanan cadangan aktual

Penting

Sumber daya komputasi, I/O, dan penyimpanan data dan log dikenakan biaya per database atau kumpulan elastis. Penyimpanan cadangan dikenakan biaya per setiap database. Untuk detail harga, lihat halaman harga Azure SQL Database .

Membandingkan model pembelian vCore dan DTU

Model pembelian vCore yang digunakan oleh Azure SQL Database memberikan beberapa manfaat atas model pembelian berbasis DTU :

• Batas komputasi, memori, I/O, dan penyimpanan yang lebih tinggi.
• Pilihan konfigurasi perangkat keras agar lebih sesuai dengan persyaratan komputasi dan memori beban kerja.
• Diskon harga dengan Azure Hybrid Benefit (AHB).
• Transparansi yang lebih besar dalam detail perangkat keras yang mengoperasikan komputasi, memfasilitasi perencanaan untuk migrasi dari penerapan di lokasi.
• Harga instans cadangan hanya tersedia untuk model pembelian vCore.
• Granularitas penskalaan yang lebih tinggi dengan beberapa ukuran komputasi yang tersedia.

Untuk bantuan dalam memilih antara model pembelian vCore dan DTU, lihat perbedaan antara model pembelian berbasis vCore dan DTU.

Komputasi

Model pembelian berbasis vCore memiliki tingkat komputasi yang disediakan dan tingkat komputasi tanpa server. Dalam tingkat komputasi yang disediakan, biaya komputasi mencerminkan total kapasitas komputasi yang terus disediakan untuk aplikasi yang independen dari aktivitas beban kerja. Pilih alokasi sumber daya yang paling sesuai dengan kebutuhan bisnis Anda berdasarkan persyaratan vCore dan memori, lalu tingkatkan dan turunkan sumber daya sesuai kebutuhan beban kerja Anda. Di tingkat komputasi tanpa server untuk Azure SQL Database, sumber daya komputasi diskalakan otomatis berdasarkan kapasitas beban kerja dan ditagih untuk jumlah komputasi yang digunakan, per detik.

Untuk meringkas:

• Meskipun tingkat komputasi yang disediakan menyediakan sejumlah sumber daya komputasi tertentu yang terus disediakan independen dari aktivitas beban kerja, tingkat komputasi tanpa server menskalakan sumber daya komputasi secara otomatis berdasarkan aktivitas beban kerja.
• Meskipun tingkat komputasi yang disediakan menagih untuk jumlah komputasi yang disediakan dengan harga tetap per jam, tingkat komputasi tanpa server menagih untuk jumlah komputasi yang digunakan, per detik.

Terlepas dari tingkat komputasi, tiga replika sekunder ketersediaan tinggi tambahan secara otomatis dialokasikan di tingkat layanan Business Critical untuk memberikan ketahanan tinggi terhadap kegagalan dan failover cepat. Replika tambahan ini membuat biaya sekitar 2,7 kali lebih tinggi dibandingkan di lapisan layanan General Purpose. Demikian juga, biaya penyimpanan yang lebih tinggi per GB di tingkat layanan Business Critical mencerminkan batas IO yang lebih tinggi dan latensi penyimpanan SSD lokal yang lebih rendah.

Di Hyperscale, pelanggan mengontrol jumlah replika ketersediaan tinggi tambahan dari 0 hingga 4 untuk mendapatkan tingkat ketahanan yang diperlukan oleh aplikasi mereka sambil mengontrol biaya.

Untuk informasi selengkapnya tentang komputasi di Azure SQL Database, lihat Sumber daya komputasi (CPU dan memori).

Batas sumber daya

Untuk batas sumber daya vCore, tinjau konfigurasi Perangkat Keras yang tersedia, lalu tinjau batas sumber daya untuk:

• server logika
• database tunggal
• beberapa basis data di dalam kumpulan elastis

Penyimpanan data dan log

Faktor-faktor berikut memengaruhi jumlah penyimpanan yang digunakan untuk data dan file log, dan berlaku untuk tingkat Tujuan Umum dan Bisnis Penting.

• Setiap ukuran komputasi mendukung ukuran data maksimum yang dapat dikonfigurasi, dengan default 32 GB.
• Saat Anda mengonfigurasi ukuran data maksimum, tambahan 30 persen penyimpanan yang dapat ditagih secara otomatis ditambahkan untuk file log.
• Di tingkat layanan Tujuan Umum, tempdb menggunakan penyimpanan SSD lokal, dan biaya penyimpanan ini termasuk dalam harga vCore.
• Di tingkat layanan Business Critical, tempdb berbagi penyimpanan SSD lokal dengan file data dan log, dan biaya penyimpanan tempdb disertakan dalam harga vCore.
• Di lapisan Tujuan Umum dan Bisnis Kritis, Anda dikenakan biaya untuk ukuran penyimpanan maksimum yang dikonfigurasi untuk database atau kumpulan elastis.
• Untuk SQL Database, Anda dapat memilih ukuran data maksimum antara 1 GB dan ukuran penyimpanan maksimum yang didukung, dengan kenaikan setiap 1 GB.

Pertimbangan penyimpanan berikut berlaku untuk Hyperscale:

• Ukuran penyimpanan data maksimum diatur ke 128 TB dan tidak dapat dikonfigurasi.
• Anda hanya dikenakan biaya untuk penyimpanan data yang dialokasikan, bukan untuk penyimpanan data maksimum.
• Anda tidak dikenakan biaya untuk penyimpanan log.
• tempdb menggunakan penyimpanan SSD lokal, dan biayanya termasuk dalam harga vCore. Untuk memantau ukuran penyimpanan data yang dialokasikan dan digunakan saat ini di SQL Database, gunakan metrik allocated_data_storage dan penyimpanan Azure Monitor masing-masing.

Untuk memantau ukuran penyimpanan data individual dan file log yang dialokasikan dan digunakan saat ini dalam database dengan menggunakan T-SQL, gunakan tampilan sys.database_files dan FILEPROPERTY(... , 'SpaceUsed') fungsi.

Petunjuk / Saran

Dalam beberapa keadaan, Anda mungkin perlu menyusutkan database untuk mengklaim kembali ruang yang tidak digunakan. Untuk informasi selengkapnya, lihat Mengelola ruang file di Azure SQL Database.

Penyimpanan cadangan

Penyimpanan untuk pencadangan database dialokasikan untuk mendukung pemulihan point-in-time (PITR) dan kapabilitas retensi jangka panjang (LTR) SQL Database. Penyimpanan ini terpisah dari penyimpanan file data dan log, dan ditagih secara terpisah.

• PITR: Di tingkat Tujuan Umum dan Bisnis Penting, cadangan database individual disalin ke penyimpanan Azure secara otomatis. Ukuran penyimpanan meningkat secara dinamis saat cadangan baru dibuat. Penyimpanan digunakan oleh pencadangan penuh, diferensial, dan log transaksi. Konsumsi penyimpanan tergantung pada tingkat perubahan database dan periode retensi yang dikonfigurasi untuk cadangan. Anda dapat mengonfigurasi periode retensi terpisah untuk setiap database antara 1 dan 35 hari untuk SQL Database. Jumlah penyimpanan cadangan yang sama dengan ukuran data maksimum yang dikonfigurasi disediakan tanpa biaya tambahan.
• LTR: Anda juga dapat mengonfigurasi retensi jangka panjang pencadangan penuh hingga 10 tahun. Jika Anda menyiapkan kebijakan LTR, cadangan ini disimpan di penyimpanan Azure Blob secara otomatis, tetapi Anda dapat mengontrol seberapa sering cadangan disalin. Untuk memenuhi persyaratan kepatuhan yang berbeda, Anda dapat memilih periode retensi yang berbeda untuk pencadangan mingguan, bulanan, dan/atau tahunan. Konfigurasi yang Anda pilih menentukan berapa banyak penyimpanan yang digunakan oleh cadangan LTR. Untuk informasi lebih lanjut, lihat penyimpanan cadangan jangka panjang.

Untuk penyimpanan cadangan di Hyperscale, lihat Pencadangan otomatis untuk database Hyperscale.

Lapisan layanan

Opsi tingkat layanan dalam model pembelian vCore termasuk Tujuan Umum, Kritis Bisnis, dan Hyperscale. Tingkat layanan umumnya menentukan jenis dan performa penyimpanan, ketersediaan tinggi dan opsi pemulihan bencana, dan ketersediaan fitur tertentu seperti In-Memory OLTP.

Kasus Penggunaan	Tujuan Umum	Kritis Bisnis	hyperscale
Pilihan terbaik untuk	Mayoritas beban kerja bisnis. Menawarkan opsi komputasi dan penyimpanan yang berorientasi anggaran, seimbang, dan dapat diskalakan.	Menawarkan aplikasi bisnis ketahanan tertinggi terhadap kegagalan dengan menggunakan beberapa replika sekunder ketersediaan tinggi, dan memberikan performa I/O tertinggi.	Beragam beban kerja terluas, termasuk beban kerja yang memiliki penyimpanan yang sangat skalabel dan kebutuhan skala baca. Menawarkan ketahanan yang lebih tinggi terhadap kegagalan dengan memungkinkan konfigurasi lebih dari satu replika sekunder ketersediaan tinggi.
Hitung ukuran	2 hingga 128 vCore	2 hingga 128 vCore	2 hingga 128 vCore
Jenis penyimpanan	Penyimpanan jarak jauh premium (per instans)	Penyimpanan SSD lokal super cepat (per satuan)	Penyimpanan terdesentralisasi dengan cache SSD lokal (untuk setiap replika komputasi)
Ukuran penyimpanan	1 GB – 4 TB	1 GB – 4 TB	10 GB – 128 TB
IOPS	320 IOPS per vCore dengan 16.000 IOPS maksimum	4.000 IOPS per vCore dengan 327.680 IOPS maksimum	327.680 IOPS dengan SSD lokal maksimum Hyperscale adalah arsitektur bertahap dengan cache pada berbagai tingkat. IOPS yang efektif tergantung pada beban kerja.
Memori/vCore	5,1 GB	5,1 GB	5,1 GB atau 10,2 GB
Pencadangan	Pilihan penyimpanan cadangan dengan geo-redundansi, zona-redundansi, atau redundansi lokal, retensi 1-35 hari (default 7 hari) Retensi jangka panjang tersedia hingga 10 tahun	Pilihan penyimpanan cadangan dengan geo-redundansi, zona-redundansi, atau redundansi lokal, retensi 1-35 hari (default 7 hari) Retensi jangka panjang tersedia hingga 10 tahun	Pilihan penyimpanan redundansi lokal (LRS), zona-redundansi (ZRS), atau redundansi geografis (GRS) Retensi 1-35 hari (7 hari secara default), dengan retensi jangka panjang hingga 10 tahun tersedia
Ketersediaan	Satu replika, tidak ada replika untuk skala pembacaan. ketersediaan tinggi dengan redundansi zona (HA)	Tiga replika, dan satu replika skala baca. ketersediaan tinggi dengan redundansi zona (HA)	ketersediaan tinggi dengan redundansi zona (HA)
Harga/penagihan	vCore, penyimpanan cadangan, dan penyimpanan cadangan dikenakan biaya. IOPS tidak dikenakan biaya.	vCore, penyimpanan cadangan, dan penyimpanan cadangan dikenakan biaya. IOPS tidak dikenakan biaya.	vCore untuk setiap replika dan penyimpanan yang digunakan akan dikenakan biaya. IOPS tidak dikenakan biaya.
Model potongan harga	Reservasi Azure Azure Hybrid Benefit (tidak tersedia pada langganan dev/test) Enterprise dan Dev/Test Pay-As-You-Go penawaran langganan	Reservasi Azure Azure Hybrid Benefit (tidak tersedia pada langganan dev/test) Enterprise dan Dev/Test Pay-As-You-Go penawaran langganan	Azure Hybrid Benefit (tidak tersedia pada langganan dev/test) 1 Enterprise dan Dev/Test Pay-As-You-Go penawaran langganan
tabel OLTP dalam memori	Tidak	Ya	Tidak ada

¹ Harga yang disederhanakan untuk SQL Database Hyperscale segera hadir. Tinjau blog harga Hyperscale untuk mendapatkan detailnya.

Untuk detail yang lebih besar, tinjau batas sumber daya untuk server logis , database tunggal, dan database yang dikumpulkan.

Nota

Untuk informasi selengkapnya tentang Perjanjian Tingkat Layanan (SLA), lihat SLA untuk Azure SQL Database

Tujuan Umum

Model arsitektur untuk tingkat layanan Tujuan Umum didasarkan pada pemisahan komputasi dan penyimpanan. Model arsitektur ini bergantung pada ketersediaan tinggi dan keandalan penyimpanan Azure Blob yang secara transparan mereplikasi file database dan menjamin tidak ada kehilangan data jika kegagalan infrastruktur yang mendasar terjadi.

Gambar berikut menunjukkan empat simpul dalam model arsitektur standar dengan lapisan komputasi dan penyimpanan yang dipisahkan.

Dalam model arsitektur untuk tingkat layanan Tujuan Umum, ada dua lapisan:

• Lapisan komputasi tanpa status yang menjalankan proses sqlservr.exe dan hanya berisi data sementara dan cache (misalnya – cache rencana, kumpulan buffer, kumpulan columnstore). Simpul stateless ini dioperasikan oleh Azure Service Fabric yang menginisialisasi proses, mengontrol kesehatan simpul, dan melakukan failover ke tempat lain jika perlu.
• Lapisan data stateful yang memiliki file database (.mdf/.ldf) dan disimpan di Azure Blob storage. Penyimpanan Azure Blob menjamin bahwa tidak ada kehilangan data dari rekaman apa pun yang ditempatkan dalam file database apa pun. Azure Storage memiliki ketersediaan/redundansi data bawaan yang memastikan bahwa setiap rekaman dalam file log atau halaman dalam file data dipertahankan meskipun prosesnya crash.

Setiap kali mesin database atau sistem operasi ditingkatkan, beberapa bagian dari infrastruktur dasar mengalami kegagalan, atau jika beberapa masalah penting terdeteksi dalam proses sqlservr.exe, Azure Service Fabric memindahkan proses stateless ke simpul komputasi stateless lainnya. Ada sekumpulan simpul cadangan yang menunggu untuk menjalankan layanan komputasi baru jika failover node utama terjadi untuk meminimalkan waktu failover. Data di lapisan penyimpanan Azure tidak terpengaruh, dan file data/log dilampirkan ke proses yang baru diinisialisasi. Proses ini menjamin ketersediaan 99,99% secara default dan ketersediaan% 99,995 saat redundansi zona diaktifkan. Mungkin ada beberapa dampak performa pada beban kerja berat yang sedang dalam penerbangan karena waktu transisi dan fakta bahwa simpul baru dimulai dengan cache dingin.

Kapan memilih tingkat layanan Tujuan Umum

Tingkat layanan Tujuan Umum adalah tingkat layanan default di Azure SQL Database yang dirancang untuk sebagian besar beban kerja generik. Jika Anda memerlukan mesin database yang dikelola sepenuhnya dengan SLA default dan latensi penyimpanan antara 5 ms dan 10 ms, tingkat Tujuan Umum adalah opsi untuk Anda.

Bisnis Kritis

Model tingkat layanan Business Critical didasarkan pada kluster proses mesin database. Model arsitektur ini bergantung pada kuorum simpul mesin database untuk meminimalkan dampak performa pada beban kerja Anda, bahkan selama aktivitas pemeliharaan. Peningkatan dan patch sistem operasi dasar, driver, dan mesin database terjadi secara transparan, dengan waktu henti minimal bagi pengguna akhir.

Dalam model Business Critical, komputasi dan penyimpanan terintegrasi pada setiap simpul. Replikasi data antara proses mesin database pada setiap simpul kluster empat node mencapai ketersediaan tinggi, dengan setiap simpul menggunakan SSD yang terpasang secara lokal sebagai penyimpanan data. Diagram berikut menunjukkan bagaimana tingkat layanan Business Critical mengatur kluster node mesin basis data dalam replika kelompok ketersediaan.

Baik proses mesin database maupun file .mdf/.ldf yang mendasar ditempatkan pada node yang sama dengan penyimpanan SSD yang terpasang secara lokal, memberikan latensi rendah pada beban kerja Anda. Ketersediaan tinggi diimplementasikan menggunakan teknologi yang mirip dengan SQL Server grup ketersediaan AlwaysOn. Setiap database adalah kluster simpul database dengan satu replika utama yang dapat diakses untuk beban kerja pelanggan, dan tiga replika sekunder yang berisi salinan data. Replika utama terus-menerus mendorong perubahan ke replika sekunder untuk memastikan data tersedia pada replika sekunder jika primer gagal karena alasan apa pun. Failover ditangani oleh Service Fabric dan mesin database – satu replika sekunder menjadi replika utama, dan replika sekunder baru dibuat untuk memastikan ada cukup node dalam kluster. Beban kerja secara otomatis dialihkan ke replika utama baru.

Selain itu, kluster Business Critical memiliki kemampuan Read Scale-Out bawaan yang menyediakan replika read-only tanpa biaya yang digunakan untuk menjalankan kueri baca-saja (seperti laporan) dan tidak akan memengaruhi performa beban kerja pada replika utama Anda.

Kapan memilih tingkat layanan Business Critical

Tingkat layanan Business Critical dirancang untuk aplikasi yang memerlukan respons latensi rendah dari penyimpanan SSD yang mendasarinya (rata-rata 1-2 ms), pemulihan yang lebih cepat jika infrastruktur yang mendasarinya gagal, atau perlu melepas beban laporan, analitik, dan kueri baca-saja ke bebas biaya replika sekunder yang dapat dibaca dari database utama.

Alasan utama mengapa Anda harus memilih tingkat layanan Business Critical alih-alih tingkat Tujuan Umum adalah:

• persyaratan latensi I/O Rendah – beban kerja yang membutuhkan respons yang cepat secara konsisten dari lapisan penyimpanan (rata-rata 1-2 milidetik) harus menggunakan tingkat Business Critical.
• Beban Kerja dengan kueri laporan dan analisis di mana satu replika sekunder baca-saja gratis sudah cukup.
• Ketahanan yang lebih tinggi dan pemulihan yang lebih cepat dari kegagalan. Jika ada kegagalan sistem, database pada instans utama dinonaktifkan dan salah satu replika sekunder segera menjadi database utama baca-tulis baru, siap untuk memproses kueri.
• Perlindungan kerusakan data tingkat lanjut. Karena tingkat Business Critical menggunakan replika database di balik layar, layanan ini menggunakan perbaikan halaman otomatis yang tersedia dengan pencerminan dan grup ketersediaan untuk membantu mengurangi kerusakan data. Jika replika tidak dapat membaca halaman karena masalah integritas data, salinan baru halaman diambil dari replika lain, menggantikan halaman yang tidak dapat dibaca tanpa kehilangan data atau waktu henti pelanggan. Fungsionalitas ini tersedia di tingkat Tujuan Umum jika database memiliki replika geo-sekunder.
• ketersediaan yang lebih tinggi - Tingkatan Business Critical dalam konfigurasi multi-zona ketersediaan memberikan ketahanan terhadap kegagalan zona dan SLA ketersediaan yang lebih tinggi.
• pemulihan geografis cepat - Ketika replikasi geografis aktif dikonfigurasi, tier Kritis Bisnis memiliki Tujuan Titik Pemulihan (RPO) terjamin 5 detik dan Tujuan Waktu Pemulihan (RTO) 30 detik selama 100% jam penerapan.

Hiperskala

Tingkat layanan Hyperscale cocok untuk semua jenis beban kerja. Arsitektur asli cloud-nya menyediakan komputasi dan penyimpanan yang dapat diskalakan secara independen untuk mendukung berbagai aplikasi tradisional dan modern yang terluas. Sumber daya komputasi dan penyimpanan di Hyperscale secara substansial melebihi sumber daya yang tersedia di tingkat Tujuan Umum dan Bisnis Kritis.

Untuk mempelajari lebih lanjut, tinjau tingkat layanan Hyperscale untuk Azure SQL Database.

Kapan memilih tingkat layanan Hyperscale

Tingkat layanan Hyperscale menghapus banyak batas praktis yang secara tradisional terlihat dalam database cloud. Di mana sebagian besar database lain dibatasi oleh sumber daya yang tersedia dalam satu simpul, database di tingkat layanan Hyperscale tidak memiliki batas tersebut. Dengan arsitektur penyimpanan yang fleksibel, database Hyperscale tumbuh sesuai kebutuhan - dan Anda hanya ditagih untuk kapasitas penyimpanan yang Anda gunakan.

Selain kemampuan penskalaannya yang canggih, Hyperscale adalah opsi yang bagus untuk beban kerja apa pun, bukan hanya untuk database besar. Dengan Hyperscale, Anda dapat:

• Mencapai ketahanan tinggi dan pemulihan kegagalan cepat sambil mengontrol biaya, dengan memilih jumlah replika ketersediaan tinggi dari 0 hingga 4.
• Tingkatkan ketersediaan tinggi dengan mengaktifkan redundansi zona untuk komputasi dan penyimpanan.
• Mencapai latensi I/O rendah (rata-rata 1-2 milidetik) untuk bagian yang sering diakses dari database Anda. Untuk database yang lebih kecil, ini mungkin berlaku untuk seluruh database.
• Terapkan berbagai skenario read scale-out dengan replika bernama.
• Manfaatkan penskalaan cepat , tanpa harus menunggu data disalin ke penyimpanan lokal pada simpul baru.
• Nikmati pencadangan database berkelanjutan tanpa dampak dan pemulihan cepat.
• Mendukung persyaratan kelangsungan bisnis dengan menggunakan grup failover dan replikasi lintas wilayah.

Konfigurasi perangkat keras

Konfigurasi perangkat keras umum dalam model vCore mencakup seri standar (Gen5), seri premium, memori seri premium yang dioptimalkan, dan seri DC. Hyperscale juga menyediakan opsi untuk perangkat keras seri premium dan memori seri premium yang dioptimalkan. Konfigurasi perangkat keras mendefinisikan batas komputasi dan memori serta karakteristik lain yang memengaruhi performa beban kerja.

Konfigurasi perangkat keras tertentu seperti seri standar (Gen5) dapat menggunakan lebih dari satu jenis prosesor (CPU), seperti yang dijelaskan dalam sumber daya komputasi (CPU dan memori). Meskipun database atau kumpulan elastis tertentu cenderung tetap berada di perangkat keras dengan jenis CPU yang sama untuk waktu yang lama (umumnya selama beberapa bulan), ada peristiwa tertentu yang dapat menyebabkan database atau kumpulan dipindahkan ke perangkat keras yang menggunakan jenis CPU yang berbeda.

Database atau kumpulan dapat dipindahkan untuk berbagai skenario, termasuk tetapi tidak terbatas pada kapan:

• Tujuan layanan diubah
• Infrastruktur saat ini di pusat data mendekati batas kapasitas
• Perangkat keras yang saat ini digunakan sedang dinonaktifkan karena akhir masa pakainya
• Konfigurasi redundan zona diaktifkan, pindah ke perangkat keras yang berbeda karena ketersediaan kapasitas

Untuk beberapa beban kerja, perpindahan ke jenis CPU yang berbeda dapat mengubah performa. SQL Database mengonfigurasi perangkat keras dengan tujuan untuk memberikan performa beban kerja yang dapat diprediksi meskipun jenis CPU berubah, menjaga perubahan performa dalam pita sempit. Namun, di seluruh spektrum beban kerja pelanggan yang luas di SQL Database, dan saat jenis CPU baru tersedia, terkadang perubahan dalam kinerja dapat lebih terlihat jika sebuah database atau pool berpindah ke jenis CPU yang berbeda.

Terlepas dari jenis CPU yang digunakan, batas sumber daya untuk database atau kumpulan elastis (seperti jumlah inti, memori, IOPS data maks, laju log maks, dan pekerja bersamaan maks) tetap sama selama database tetap pada tujuan layanan yang sama.

Sumber daya komputasi (CPU dan memori)

Tabel berikut membandingkan sumber daya komputasi dalam konfigurasi perangkat keras dan tingkat komputasi yang berbeda:

Konfigurasi perangkat keras	CPU (Unit Pemroses Pusat)	Ingatan
Seri standar (Gen5)	Komputasi yang dialokasikan - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 GHz*, Intel® Xeon® Platinum 8370C (Ice Lake)*, prosesor AMD EPYC 7763v (Milan) - Menyediakan hingga 128 vCore (hyper-threaded) komputasi tanpa server - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 GHz*, Intel® Xeon® Platinum 8370C (Ice Lake)*, prosesor AMD EPYC 7763v (Milan) - Skala otomatis hingga 80 vCore (hyper-threaded) - Rasio memori-ke-vCore secara dinamis beradaptasi dengan memori dan penggunaan CPU berdasarkan permintaan beban kerja dan dapat setinggi 24 GB per vCore. Misalnya, pada titik waktu tertentu beban kerja dapat digunakan dan ditagih untuk memori 240 GB dan hanya 10 vCore.	Komputasi yang dialokasikan - 5,1 GB per vCore - Provisi hingga 625 GB komputasi tanpa server - Skala otomatis hingga 24 GB per vCore - Skala otomatis maksimal hingga 240 GB
Seri Fsv2**	- Prosesor Intel® 8168 (Skylake) - Memiliki kecepatan jam turbo inti seluruh yang terjaga 3,4 GHz dan kecepatan jam turbo inti tunggal maksimum 3,7 GHz. - Penyediaan hingga 72 inti virtual (hyper-threaded)	- 1,9 GB per vCore - Provisi hingga 136 GB
Seri DC	- Prosesor Intel® Xeon® E-2288G - Menampilkan Intel Software Guard Extension (Intel SGX) - Penyediaan hingga 8 vCore (fisik)	4,5 GB per vCore

* Dalam tampilan manajemen dinamis sys.dm_user_db_resource_governance, pembuatan perangkat keras untuk database yang menggunakan prosesor Intel® SP-8160 (Skylake) muncul sebagai Gen6, pembuatan perangkat keras untuk database yang menggunakan Intel® 8272CL (Cascade Lake) muncul sebagai Gen7, dan pembuatan perangkat keras untuk database menggunakan Intel® Xeon® Platinum 8370C (Ice Lake) atau AMD® EPYC® 7763v (Milan) muncul sebagai Gen8. Untuk ukuran komputasi dan konfigurasi perangkat keras tertentu, batas sumber daya sama terlepas dari jenis CPU (Intel Broadwell, Skylake, Ice Lake, Cascade Lake, atau AMD Milan).

** Perangkat keras seri Fsv2 akan dihentikan 1 Oktober 2026.

Untuk informasi selengkapnya, lihat batas sumber daya untuk database tunggal dan kumpulan elastis .

Untuk sumber daya dan spesifikasi komputasi database Hyperscale, lihat sumber daya komputasi Hyperscale.

Seri standar (Gen5)

Perangkat keras seri standar (Gen5) menyediakan sumber daya komputasi dan memori yang seimbang, dan cocok untuk sebagian besar beban kerja database.

Perangkat keras seri standar (Gen5) tersedia di semua wilayah publik di seluruh dunia.

Seri premium Hyperscale

Opsi perangkat keras seri premium menggunakan teknologi CPU dan memori terbaru dari Intel dan AMD. Seri premium memberikan dorongan terhadap performa komputasi relatif terhadap perangkat keras seri standar.

• Opsi seri Premium menawarkan performa CPU yang lebih cepat dibandingkan dengan seri Standar dan jumlah vCore maksimum yang lebih tinggi.
• Opsi memori seri Premium yang dioptimalkan menawarkan jumlah memori dua kali lipat relatif terhadap seri Standar.

Memori seri standar, seri premium, dan seri premium yang dioptimalkan tersedia untuk kumpulan elastis Hyperscale.

Untuk informasi selengkapnya, lihat pengumuman blog seri premium Hyperscale.

Untuk wilayah yang tersedia, lihat ketersediaan seri premium Hyperscale.

Seri DC

• Perangkat keras seri DC menggunakan prosesor Intel dengan teknologi Software Guard Extensions (Intel SGX).
• Seri DC diperlukan untuk Always Encrypted dengan enklave aman beban kerja yang memerlukan perlindungan keamanan enklave perangkat keras yang lebih kuat, dibandingkan dengan enklave Keamanan berbasis Virtualisasi (VBS).
• Seri DC dirancang untuk beban kerja yang memproses data sensitif dan menuntut kemampuan pemrosesan kueri rahasia, yang disediakan oleh Always Encrypted dengan enklave aman.
• Perangkat keras seri DC menyediakan sumber daya komputasi dan memori yang seimbang.

Seri DC hanya didukung untuk komputasi yang dipersiapkan (tanpa dukungan untuk Serverless) dan tidak mendukung redundansi zona. Untuk wilayah tempat seri DC tersedia, lihat ketersediaan seri DC.

Jenis layanan Azure yang didukung oleh seri DC

Untuk membuat database atau kumpulan elastis pada perangkat keras seri DC, langganan harus merupakan jenis penawaran berbayar termasuk Pay-As-You-Go atau Perjanjian Enterprise (EA). Untuk daftar lengkap jenis penawaran Azure yang didukung oleh seri DC, lihat penawaran saat ini tanpa batas pengeluaran.

Pilih konfigurasi perangkat keras

Anda dapat memilih konfigurasi perangkat keras untuk database atau kumpulan elastis di SQL Database pada saat pembuatan. Anda juga dapat mengubah konfigurasi perangkat keras database atau kumpulan elastis yang ada.

Untuk memilih konfigurasi perangkat keras saat membuat SQL Database atau kumpulan

Untuk informasi mendetail, lihat Membuat SQL Database.

Pada tab Dasar, pilih tautan konfigurasi database di bagian Komputasi + penyimpanan, lalu pilih tautan Ubah konfigurasi:

Pilih konfigurasi perangkat keras yang diinginkan:

Untuk mengubah konfigurasi perangkat keras SQL Database atau kumpulan yang ada

Untuk sebuah database, pada halaman Gambaran Umum, pilih tautan tingkat harga:

Untuk kumpulan, pada halaman Gambaran Umum, pilih Konfigurasikan.

Ikuti langkah-langkah untuk mengubah konfigurasi, dan pilih konfigurasi perangkat keras seperti yang dijelaskan di langkah-langkah sebelumnya.

Ketersediaan perangkat keras

Untuk informasi tentang ketersediaan perangkat keras generasi saat ini, lihat Ketersediaan Fitur menurut Wilayah untuk Azure SQL Database.

Perangkat keras generasi sebelumnya

Seri Fsv2

Perangkat keras seri Fsv2 untuk Azure SQL Database akan dihentikan 1 Oktober 2026. Untuk meminimalkan gangguan layanan dan mempertahankan performa harga, transisi ke perangkat keras hyperscale seri premium atau seri Standar (Gen5). Untuk informasi selengkapnya, lihat Pemberitahuan Penghentian: Penawaran seri FSV2 Azure SQL Database. Untuk sebagian besar database dan beban kerja, perangkat keras Hyperscale seri premium atau Seri Standar (Gen5) memberikan performa harga yang serupa atau lebih baik daripada Fsv2. Untuk memastikan, validasi ini dengan database dan beban kerja spesifik Anda.

• Fsv2 menyediakan lebih sedikit memori dan tempdb per vCore daripada perangkat keras lainnya, sehingga beban kerja yang sensitif terhadap batas tersebut mungkin berkinerja lebih baik pada seri standar (Gen5).
• Seri Fsv2 hanya didukung di tingkat Tujuan Umum.

Gen4

Perangkat keras Gen4 telah dipensiunkan dan tidak tersedia untuk penyediaan, peningkatan, atau penurunan. Migrasikan database Anda ke generasi perangkat keras yang didukung untuk berbagai vCore dan skalabilitas penyimpanan yang lebih luas, jaringan terakselerasi, kinerja IO terbaik, dan latensi minimal. Tinjau opsi perangkat keras untuk database tunggal dan opsi perangkat keras untuk kumpulan elastis. Untuk informasi selengkapnya, lihat Dukungan telah berakhir untuk perangkat keras Gen 4 di Azure SQL Database.

Langkah berikutnya

Panduan Cepat : Membuat database tunggal - Azure SQL Database

Konten terkait

• Halaman harga Azure SQL Database
• Batas sumber daya untuk database tunggal menggunakan model pembelian vCore
• Batas sumber daya untuk kumpulan elastis menggunakan model pembelian vCore