Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Berlaku untuk:
Azure SQL Database
Serverless adalah lapisan komputasi untuk database tunggal di Azure SQL Database yang secara otomatis menyesuaikan kapasitas komputasi berdasarkan permintaan beban kerja dan menagih untuk jumlah komputasi yang digunakan per detik. Tingkat komputasi tanpa server juga akan otomatis menjeda basis data selama periode tidak aktif, di mana hanya penyimpanan yang dikenakan biaya, dan otomatis mengaktifkan kembali basis data saat ada aktivitas. Tingkat komputasi tanpa server tersedia di tingkat layanan General Purpose dan tingkat layanan Hyperscale.
Catatan
Jeda otomatis dan lanjutkan otomatis saat ini hanya didukung di tingkat layanan Tujuan Umum.
Gambaran Umum
Rentang penskalaan otomatis komputasi dan penundaan jeda otomatis adalah parameter penting untuk tingkat komputasi tanpa server. Konfigurasi parameter ini membentuk pengalaman performa database dan biaya komputasi.
Konfigurasi performa
- vCore minimum dan vCore maksimum adalah parameter yang dapat dikonfigurasi yang menentukan rentang kapasitas komputasi yang tersedia untuk database. Batas memori dan IO sebanding dengan rentang vCore yang ditentukan.
- Penundaan jeda otomatis adalah parameter yang dapat dikonfigurasi yang menentukan periode waktu database harus tidak aktif sebelum dijeda secara otomatis. Database akan dilanjutkan secara otomatis ketika pengguna masuk atau melakukan aktivitas lain berikutnya. Atau, jeda otomatis dapat dinonaktifkan.
Biaya
Biaya untuk database tanpa server adalah penjumlahan biaya komputasi dan biaya penyimpanan. Biaya penyimpanan ditentukan dengan cara yang sama seperti dalam tingkat komputasi yang disediakan.
- Ketika penggunaan komputasi antara batas minimum dan maksimum yang dikonfigurasi, biaya komputasi didasarkan pada vCore dan memori yang digunakan.
- Ketika penggunaan komputasi di bawah batas minimum yang dikonfigurasi, biaya komputasi didasarkan pada vCore minimum dan memori minimum yang dikonfigurasi.
- Ketika database dijeda, biaya komputasi adalah nol dan hanya biaya penyimpanan yang dikeluarkan.
Untuk detail biaya selengkapnya, lihat Penagihan.
Skenario
Serverless dioptimalkan untuk harga dan performa bagi database tunggal dengan pola penggunaan yang tidak teratur yang dapat menunda proses pemanasan komputasi setelah periode tidak aktif. Sebaliknya, tingkat komputasi yang disediakan dioptimalkan dari segi keseimbangan harga dan performa untuk database tunggal atau beberapa database dalam kelompok elastis dengan penggunaan rata-rata yang lebih tinggi, di mana penundaan dalam memulai komputasi tidak dapat ditoleransi.
Skenario yang cocok untuk komputasi tanpa server
- Database tunggal dengan pola penggunaan terputus-terputus dan tidak dapat diprediksi yang diselingi dengan periode tidak aktif, dan pemanfaatan komputasi rata-rata yang lebih rendah dari waktu ke waktu.
- Database tunggal dalam tingkatan komputasi yang telah ditetapkan yang sering disesuaikan skalanya dan pelanggan yang lebih suka mendelegasikan penyesuaian skala komputasi ke layanan.
- Database tunggal baru tanpa riwayat penggunaan di mana ukuran komputasi sulit atau tidak mungkin diperkirakan sebelum penyebaran di Azure SQL Database.
Skenario yang cocok untuk komputasi terprovisi
- Database tunggal dengan pola penggunaan yang lebih teratur dan dapat diprediksi dan pemanfaatan komputasi rata-rata yang lebih tinggi dari waktu ke waktu.
- Database yang tidak dapat mentolerir trade-off performa yang dihasilkan dari pemangkasan memori yang lebih sering atau keterlambatan dalam melanjutkan dari keadaan dijeda.
- Beberapa database dengan pola penggunaan terputus-terputus dan tidak dapat diprediksi yang dapat dikonsolidasikan ke dalam kumpulan elastis untuk optimasi performa harga yang lebih baik.
Membandingkan tingkat komputasi
Tabel berikut ini meringkas perbedaan antara tingkat komputasi tanpa server dan tingkat komputasi yang disediakan:
| Komputasi tanpa server | Komputasi yang tersedia | |
|---|---|---|
| Pola penggunaan database | Penggunaan intermiten dan tak terduga dengan pemanfaatan komputasi rata-rata yang lebih rendah dari waktu ke waktu. | Pola penggunaan yang lebih teratur dengan pemanfaatan komputasi rata-rata yang lebih tinggi dari waktu ke waktu, atau beberapa database menggunakan pool elastis. |
| Upaya manajemen performa | Turunkan | Lebih tinggi |
| Penskalaan komputasi | Otomatis | Panduan |
| Komputasi responsif | Lebih rendah setelah periode tidak aktif | Segera |
| Granularitas penagihan | Per detik | Per jam |
Model pembelian dan tingkat layanan
Tabel berikut menjelaskan dukungan tanpa server berdasarkan model pembelian, tingkat layanan, dan perangkat keras:
| Kategori | Didukung | Tidak didukung |
|---|---|---|
| Model pembelian | vCore | DTU |
| Tingkat layanan |
Tujuan Umum Hyperscale |
Kritis Bisnis |
| Perangkat Keras | Seri Standar (Gen5) | Semua perangkat keras lainnya |
Penskalaan otomatis
Meningkatkan responsivitas
Database tanpa server dijalankan pada komputer dengan kapasitas yang memadai untuk memenuhi permintaan sumber daya tanpa gangguan untuk sejumlah komputasi yang diminta, dalam batas yang ditetapkan oleh nilai vCore maksimum. Kadang-kadang, penyeimbangan beban secara otomatis terjadi jika mesin tidak dapat memenuhi permintaan sumber daya dalam beberapa menit. Misalnya, jika permintaan sumber daya sebesar 4 vCores, tetapi hanya 2 vCores yang tersedia, maka dibutuhkan waktu hingga beberapa menit untuk menyeimbangkan beban sebelum 4 vCores disediakan. Database tetap online selama penyeimbangan beban kecuali untuk periode singkat di akhir operasi ketika koneksi dijatuhkan.
Manajemen memori
Dalam tingkat layanan Tujuan Umum dan Hyperscale, memori untuk database tanpa server direklamasi lebih sering daripada untuk database komputasi yang disediakan. Perilaku ini penting untuk mengontrol biaya tanpa server dan dapat memengaruhi performa.
Pemulihan Cache
Tidak seperti database komputasi yang dikonfigurasi, memori dari cache SQL diambil kembali dari database tanpa peladen ketika penggunaan CPU atau cache aktif rendah.
- Pemanfaatan cache aktif dianggap rendah ketika ukuran total entri cache yang terakhir digunakan berada di bawah ambang batas, untuk jangka waktu tertentu.
- Ketika reklamasi cache dipicu, ukuran cache target dikurangi secara bertahap menjadi sebagian kecil dari ukuran sebelumnya dan reklamasi hanya berlanjut jika penggunaan tetap rendah.
- Ketika reklamasi cache terjadi, kebijakan untuk memilih entri cache untuk digusur adalah kebijakan pemilihan yang sama seperti untuk database komputasi yang disediakan ketika tekanan memori tinggi.
- Ukuran cache tidak pernah dikurangi di bawah batas memori minimum seperti yang didefinisikan oleh vCore minimum.
Dalam database komputasi tanpa server dan yang disediakan, entri cache dapat dikeluarkan jika semua memori yang tersedia digunakan.
Ketika utilisasi CPU rendah, pemanfaatan cache aktif dapat tetap tinggi tergantung pada pola penggunaan dan mencegah reklamasi memori. Juga, mungkin ada penundaan lain setelah aktivitas pengguna berhenti sebelum reklamasi memori terjadi karena proses latar belakang berkala merespons aktivitas pengguna sebelumnya. Misalnya, operasi penghapusan dan tugas pembersihan Penyimpanan Kueri menghasilkan catatan hantu yang ditandai untuk penghapusan, tetapi tidak dihapus secara langsung sampai proses pembersihan hantu berjalan. Pembersihan hantu mungkin melibatkan membaca halaman data ke dalam cache.
Hidrasi cache
Cache memori SQL tumbuh saat data diambil dari disk dengan cara yang sama dan dengan kecepatan yang sama seperti untuk database yang disediakan. Ketika database sibuk, cache diizinkan untuk tumbuh tidak dibatasi saat ada memori yang tersedia.
Manajemen cache disk
Di tingkat layanan Hyperscale untuk tingkat komputasi tanpa server dan tersedia, setiap replika komputasi menggunakan cache Resilient Buffer Pool Extension (RBPEX), yang menyimpan halaman data di SSD lokal untuk meningkatkan performa IO. Namun, di tingkat komputasi tanpa server untuk Hyperscale, cache RBPEX untuk setiap replika komputasi secara otomatis tumbuh dan menyusut sebagai respons terhadap peningkatan dan penurunan permintaan beban kerja. Ukuran maksimum cache RBPEX dapat bertambah adalah tiga kali memori maksimum yang dikonfigurasi untuk database. Untuk informasi lebih lanjut tentang memori maksimum dan batas penskalaan otomatis RBPEX dalam skema tanpa server, lihat batas sumber daya Hyperscale untuk tanpa server.
Jeda otomatis dan lanjutkan otomatis
Saat ini, jeda otomatis tanpa server dan pelanjutan otomatis hanya didukung di tingkat Tujuan Umum.
Jeda otomatis
Jeda otomatis dipicu jika semua kondisi berikut ini benar selama penundaan jeda otomatis:
- Jumlah sesi = 0
- CPU = 0 untuk beban kerja pengguna yang berjalan di kumpulan sumber daya pengguna
Opsi disediakan untuk menonaktifkan jeda otomatis jika diinginkan.
Fitur berikut ini tidak mendukung jeda otomatis, tetapi mendukung penskalaan otomatis. Jika salah satu fitur berikut digunakan, jeda otomatis harus dinonaktifkan dan database tetap online terlepas dari durasi tidak aktifnya database:
- Geo-replikasi (replikasi geografis aktif dan grup failover).
- Retensi cadangan jangka panjang (LTR).
- Database sinkronisasi yang digunakan dalam Sinkronisasi Data SQL. Tidak seperti database sinkronisasi, database anggota dan hub mendukung jeda otomatis.
- Alias DNS dibuat untuk server logis yang berisi database tanpa server.
- Pekerjaan Elastis, Database tanpa server yang diaktifkan jeda otomatis tidak didukung sebagai Database Pekerjaan. Database tanpa server yang ditargetkan oleh tugas elastis mendukung jeda otomatis. Koneksi pekerjaan melanjutkan database.
Jeda otomatis untuk sementara dihentikan selama penyebaran beberapa pembaruan layanan, yang mengharuskan database tetap aktif. Dalam kasus seperti itu, jeda otomatis menjadi diperbolehkan lagi setelah pembaruan layanan selesai.
Pemecahan masalah jeda otomatis
Jika jeda otomatis diaktifkan dan fitur yang memblokirnya tidak digunakan, tetapi database tidak memasuki jeda otomatis setelah periode penundaan, maka mungkin sesi aplikasi atau pengguna yang mencegah terjadinya jeda tersebut.
Untuk melihat apakah ada sesi aplikasi atau pengguna yang saat ini terhubung ke database, hubungkan ke database menggunakan alat klien apa pun, dan jalankan kueri berikut:
SELECT session_id,
host_name,
program_name,
client_interface_name,
login_name,
status,
login_time,
last_request_start_time,
last_request_end_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_resource_governor_workload_groups AS wg
ON s.group_id = wg.group_id
WHERE s.session_id <> @@SPID
AND
(
(
wg.name like 'UserPrimaryGroup.DB%'
AND
TRY_CAST(RIGHT(wg.name, LEN(wg.name) - LEN('UserPrimaryGroup.DB') - 2) AS int) = DB_ID()
)
OR
wg.name = 'DACGroup'
);
Tip
Setelah menjalankan kueri, pastikan untuk memutuskan sambungan dari database. Selain itu, sesi terbuka yang digunakan oleh kueri mencegah jeda otomatis.
- Jika kumpulan hasil tidak kosong, itu menunjukkan bahwa ada sesi yang saat ini mencegah jeda otomatis.
- Jika kumpulan hasil kosong, masih ada kemungkinan sesi telah dibuka, mungkin untuk waktu yang singkat, pada beberapa titik sebelumnya selama masa jeda otomatis. Untuk memeriksa aktivitas selama periode penundaan, Anda dapat menggunakan audit untuk Azure SQL Database dan Azure Synapse Analytics dan memeriksa data audit untuk periode yang relevan.
Penting
Kehadiran sesi terbuka, dengan atau tanpa pemanfaatan CPU bersamaan di kumpulan sumber daya pengguna, adalah alasan paling umum bagi database tanpa server untuk tidak dijeda secara otomatis seperti yang diharapkan.
Lanjutkan otomatis
Melanjutkan otomatis dipicu jika salah satu kondisi berikut ini benar kapan saja:
| Fitur | Pemicu resume otomatis |
|---|---|
| Autentikasi dan otorisasi | Masuk |
| Deteksi ancaman | Mengaktifkan/menonaktifkan pengaturan deteksi ancaman pada tingkat database atau server. Memodifikasi pengaturan deteksi ancaman pada tingkat database atau server. |
| Penemuan dan klasifikasi data | Menambahkan, memodifikasi, menghapus, atau menampilkan label sensitivitas |
| Melakukan audit | Melihat rekaman audit. Memperbarui atau melihat kebijakan audit. |
| Pengaburan Data | Menambahkan, memodifikasi, menghapus, atau menampilkan aturan masking data |
| Enkripsi data transparan | Menampilkan status atau status enkripsi data transparan |
| Penilaian kerentanan | Pemindaian yang dimulai secara manual dan pemindaian berkala jika diaktifkan |
| Penyimpanan data kueri (performa) | Mengubah atau menampilkan pengaturan Penyimpanan Kueri |
| Rekomendasi Performa | Menampilkan atau menerapkan rekomendasi performa |
| Penyetelan otomatis | Aplikasi dan verifikasi rekomendasi penyetelan otomatis seperti pengindeksan otomatis |
| Penyalinan database | Membuat database sebagai salinan. Ekspor ke file BACPAC. |
| Sinkronisasi data SQL | Sinkronisasi antara hub dan database anggota yang berjalan pada jadwal yang dapat dikonfigurasi atau dilakukan secara manual |
| Memodifikasi metadata database tertentu | Menambahkan tag database baru. Mengubah vCore maksimum, vCore minimum, atau penundaan jeda otomatis. |
| SQL Server Management Studio (SSMS) | Saat menggunakan versi SQL Server Management Studio yang lebih lama dari 18.1 dan membuka jendela kueri baru untuk database apa pun di server, database apa pun yang dijeda otomatis di server yang sama dilanjutkan. Perilaku ini tidak terjadi jika menggunakan SQL Server Management Studio versi 18.1 atau yang lebih baru. |
Pemantauan, manajemen, atau solusi lain yang melakukan salah satu operasi ini memicu pengulangan otomatis. Melanjutkan secara otomatis juga dipicu selama penyebaran beberapa pembaruan layanan yang mengharuskan database tetap daring.
Konektivitas
Jika database tanpa server dijeda, upaya koneksi pertama melanjutkan database dan mengembalikan kesalahan yang menyatakan bahwa database tidak tersedia dengan kode kesalahan 40613. Setelah database dilanjutkan, coba kembali masuk untuk membuat konektivitas. Klien-klien basis data yang mengikuti rekomendasi logika ulang coba sambungan tidak seharusnya membutuhkan modifikasi. Untuk opsi dan rekomendasi logika coba lagi koneksi, lihat:
- Logika coba ulang koneksi di SqlClient
- Logika coba lagi koneksi di SQL Database menggunakan Entity Framework Core
- Logika coba lagi koneksi di SQL Database menggunakan Entity Framework 6
- Logika coba lagi koneksi di SQL Database menggunakan ADO.NET
Latensi
Latensi untuk melanjutkan secara otomatis dan menjeda secara otomatis pada database tanpa server umumnya sekitar 1 menit untuk melanjutkan dan 1-10 menit setelah periode penundaan berakhir untuk jeda otomatis.
Enkripsi data transparan yang dikelola pelanggan (BYOK)
Penghapusan atau pencabutan kunci
Jika menggunakan enkripsi data transparan yang dikelola pelanggan (BYOK) dan database tanpa server dijeda secara otomatis ketika penghapusan atau pencabutan kunci terjadi, maka database tetap dalam status jeda otomatis. Dalam hal ini, setelah database dilanjutkan berikutnya, database menjadi tidak dapat diakses dalam waktu sekitar 10 menit. Setelah database menjadi tidak dapat diakses, proses pemulihan sama dengan database komputasi yang disediakan. Jika database tanpa server online ketika penghapusan atau pencabutan kunci terjadi, maka database juga menjadi tidak dapat diakses dalam waktu sekitar 10 menit dengan cara yang sama seperti database komputasi yang disediakan.
Rotasi kunci
Jika menggunakan enkripsi data transparan yang dikendalikan oleh pelanggan (BYOK), dan penghentian otomatis tanpa server diaktifkan, database diaktifkan kembali secara otomatis setiap kali kunci dirotasi. Database kemudian akan dijeda secara otomatis saat kondisi jeda otomatis terpenuhi.
Membuat database tanpa server baru
Membuat database baru atau memindahkan database yang sudah ada ke tingkat komputasi tanpa server mengikuti pola yang sama seperti membuat database baru di tingkat komputasi yang disediakan dan melibatkan dua langkah berikut:
Tentukan tujuan layanan. Tujuan layanan menentukan tingkat layanan, konfigurasi perangkat keras, dan jumlah maksimum vCore. Untuk opsi tujuan layanan, lihat batas sumber daya tanpa server
Secara opsional, tentukan vCore minimum dan penundaan jeda otomatis untuk mengubah nilai defaultnya. Tabel berikut ini memperlihatkan nilai yang tersedia untuk parameter ini.
Parameter Pilihan nilai Nilai bawaan Minimum vCore Bergantung pada vCore maksimum yang dikonfigurasi - lihat batas sumber daya. 0,5 vCores Penundaan jeda otomatis Minimum: 15 menit
Maksimum: 10.080 menit (tujuh hari)
Kenaikan: 1 menit
Nonaktifkan jeda otomatis: -160 menit
Contoh berikut membuat database baru di tingkat komputasi tanpa server.
Menggunakan portal Microsoft Azure
Lihat Quickstart: Membuat database tunggal di Azure SQL Database menggunakan portal Azure.
Menggunakan PowerShell
- Tujuan Umum
- Hyperscale
Buat database Tujuan Umum tanpa server baru dengan contoh PowerShell berikut:
New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
-Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
-MinVcore 0.5 -MaxVcore 2 -AutoPauseDelayInMinutes 720
Gunakan Azure CLI
- Tujuan Umum
- Hyperscale
Buat database Tujuan Umum tanpa server baru dengan contoh Azure CLI berikut:
az sql db create -g $resourceGroupName -s $serverName -n $databaseName `
-e GeneralPurpose --compute-model Serverless -f Gen5 `
--min-capacity 0.5 -c 2 --auto-pause-delay 720
Menggunakan Transact-SQL (T-SQL)
Saat menggunakan T-SQL untuk membuat database tanpa server baru, nilai default diterapkan untuk vCore minimum dan penundaan jeda otomatis. Nilainya nanti dapat diubah dari portal Microsoft Azure atau melalui API termasuk PowerShell, Azure CLI, dan REST.
Untuk detailnya, lihat CREATE DATABASE.
- Tujuan Umum
- Hyperscale
Buat database tanpa server Tujuan Umum baru dengan contoh T-SQL berikut:
CREATE DATABASE testdb
( EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_S_Gen5_1' ) ;
Memindahkan database antara tingkat komputasi atau tingkat layanan
Database dapat dipindahkan antara tingkat komputasi yang disediakan dan tingkat komputasi tanpa server.
Database tanpa server juga dapat dipindahkan dari tingkat layanan Tujuan Umum ke tingkat layanan Hyperscale. Untuk informasi selengkapnya, lihat Mengonversi database yang sudah ada ke Hyperscale.
Saat memindahkan database di antara tingkat komputasi, tentukan parameter model komputasi sebagai Serverless atau Provisioned saat menggunakan PowerShell atau Azure CLI, atau SERVICE_OBJECTIVE saat menggunakan T-SQL. Tinjau batasan sumber daya untuk mengidentifikasi sasaran layanan yang sesuai.
Contoh berikut memindahkan database yang sudah ada dari komputasi yang disediakan ke tanpa server.
Menggunakan PowerShell
- Tujuan Umum
- Hyperscale
Pindahkan database Tujuan Umum komputasi yang disediakan ke tingkat komputasi tanpa server dengan contoh PowerShell berikut:
Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
-Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
-MinVcore 1 -MaxVcore 4 -AutoPauseDelayInMinutes 1440
Gunakan Azure CLI
- Tujuan Umum
- Hyperscale
Pindahkan database Tujuan Umum komputasi yang disediakan ke tingkat komputasi tanpa server dengan contoh Azure CLI berikut:
az sql db update -g $resourceGroupName -s $serverName -n $databaseName `
--edition GeneralPurpose --compute-model Serverless --family Gen5 `
--min-capacity 1 --capacity 4 --auto-pause-delay 1440
Menggunakan Transact-SQL (T-SQL)
Saat menggunakan T-SQL untuk memindahkan database antar tingkat komputasi, nilai default diterapkan untuk vCore minimum dan penundaan jeda otomatis. Nilainya kemudian dapat diubah dari portal Azure atau melalui API termasuk PowerShell, Azure CLI, dan REST. Untuk informasi lebih lanjut, lihat ALTER DATABASE.
- Tujuan Umum
- Hyperscale
Pindahkan database Tujuan Umum komputasi yang disediakan ke tingkat komputasi tanpa server dengan contoh T-SQL berikut:
ALTER DATABASE testdb
MODIFY ( SERVICE_OBJECTIVE = 'GP_S_Gen5_1') ;
Mengubah konfigurasi tanpa server
Menggunakan PowerShell
Gunakan Set-AzSqlDatabase untuk memodifikasi vCore maksimum atau minimum, dan penundaan jeda otomatis. MaxVcoreGunakan argumen , MinVcore, dan AutoPauseDelayInMinutes . Jeda otomatis tanpa server saat ini tidak didukung di tingkat Hyperscale, sehingga argumen penundaan jeda otomatis hanya berlaku untuk tingkat Tujuan Umum.
Gunakan Azure CLI
Gunakan az sql db update untuk memodifikasi maksimum atau minimum vCore, dan penundaan jeda otomatis. Gunakan argumen capacity, min-capacity, dan auto-pause-delay. Jeda otomatis tanpa server saat ini tidak didukung di tingkat Hyperscale, sehingga argumen penundaan jeda otomatis hanya berlaku untuk tingkat Tujuan Umum.
Layar
Sumber daya yang digunakan dan ditagih
Sumber daya database tanpa server mencakup paket aplikasi, instans SQL, dan entitas kumpulan sumber daya pengguna.
Paket aplikasi
Paket aplikasi adalah batas manajemen sumber daya ter luar untuk database, terlepas dari apakah database berada dalam tingkat komputasi tanpa server atau yang disediakan. Paket aplikasi berisi instans SQL Server dan layanan eksternal seperti Pencarian Teks lengkap yang semuanya menyatukan semua sumber daya pengguna dan sistem yang digunakan oleh database di SQL Database. Instans SQL Server umumnya mendominasi pemanfaatan sumber daya secara keseluruhan di seluruh paket aplikasi.
Kumpulan sumber daya pengguna
Kumpulan sumber daya pengguna adalah batas manajemen sumber daya dalam untuk database, terlepas dari apakah database berada dalam tingkat komputasi tanpa server atau yang diprovisikan. Kumpulan sumber daya pengguna mencakup CPU dan IO untuk beban kerja pengguna yang dihasilkan oleh kueri DDL (CREATE and ALTER) dan DML (INSERT, UPDATE, DELETE, dan MERGE, dan SELECT). Kueri ini umumnya mewakili proporsi pemanfaatan yang paling substansial dalam paket aplikasi.
Metrik
Tabel berikut ini mencakup metrik untuk memantau penggunaan sumber daya paket aplikasi dan kumpulan sumber daya pengguna dari database tanpa server, termasuk replika geografis apa pun:
| Entitas | Metrik | Deskripsi | Unit |
|---|---|---|---|
| Paket aplikasi | persentase_cpu_aplikasi | Persentase vCore yang digunakan oleh aplikasi relatif terhadap vCore maksimum yang diizinkan untuk aplikasi. Untuk Hyperscale serverless, metrik ini tersedia untuk semua replika utama, replika yang diberi nama, dan replika geografis. | Persentase |
| Paket aplikasi | app_cpu_ditagihkan | Jumlah komputasi yang ditagihkan untuk aplikasi selama periode pelaporan. Jumlah yang dibayarkan selama periode ini adalah produk dari metrik ini dan harga satuan vCore. Nilai metrik ini ditentukan dengan menggabungkan maksimum CPU yang digunakan dan memori yang digunakan setiap detik. Jika jumlah yang digunakan kurang dari jumlah minimum yang disediakan sebagaimana ditetapkan oleh vCore minimum dan memori minimum, maka jumlah minimum yang disediakan akan ditagih. Untuk membandingkan CPU dengan memori untuk tujuan tagihan, memori dinormalisasi menjadi unit vCore dengan menghitung ulang jumlah memori dalam GB sebesar 3 GB per vCore. Untuk Hyperscale tanpa server, metrik ini diekspos untuk replika utama dan replika bernama apa pun. |
detik vCore |
| Paket aplikasi | aplikasi_cpu_ditagihkan_HA_replika | Hanya berlaku untuk Hyperscale tanpa server. Jumlah penghitungan yang dibebankan pada semua aplikasi untuk replika HA selama periode pelaporan. Jumlah ini tercakup baik ke replika HA yang dimiliki oleh replika utama maupun replika HA yang dimiliki oleh replika bernama tertentu. Sebelum menghitung jumlah ini di seluruh replika HA, jumlah komputasi yang ditagih untuk replika HA individu ditentukan dengan cara yang sama seperti untuk replika utama atau replika bernama. Untuk Hyperscale tanpa server (serverless), metrik ini ditampilkan untuk semua jenis replika: replika utama, replika bernama, dan replika geografis. Jumlah yang dibayarkan selama periode pelaporan adalah produk dari metrik ini dan harga unit vCore. | detik vCore |
| Paket aplikasi | persentase_memori_aplikasi | Persentase memori yang digunakan oleh aplikasi relatif terhadap memori maksimum yang diizinkan untuk aplikasi. Untuk Hyperscale tanpa server, metrik ini diekspos untuk semua replika utama, replika bernama, dan replika geografis. | Persentase |
| Kumpulan sumber daya pengguna | persentase_cpu | Persentase vCore yang digunakan oleh beban kerja pengguna relatif terhadap vCore maksimum yang diizinkan untuk beban kerja pengguna. | Persentase |
| Kumpulan sumber daya pengguna | data_IO_percent | Persentase IOPS data yang digunakan oleh beban kerja pengguna relatif terhadap IOPS data maksimum yang diizinkan untuk beban kerja pengguna. | Persentase |
| Kumpulan sumber daya pengguna | log_IO_percent | Persentase MB/dtk log yang digunakan oleh beban kerja pengguna dibandingkan dengan MB/dtk log maksimum yang diizinkan untuk beban kerja pengguna. | Persentase |
| Kumpulan sumber daya pengguna | persentase_pekerja | Persentase pekerja yang digunakan oleh beban kerja pengguna relatif terhadap pekerja maksimum yang diizinkan untuk beban kerja pengguna. | Persentase |
| Kumpulan sumber daya pengguna | persentase sesi | Persentase sesi yang digunakan oleh beban kerja pengguna relatif terhadap sesi maksimum yang diizinkan untuk beban kerja pengguna. | Persentase |
Jeda dan lanjutkan status
Dalam kasus database tanpa server dengan fitur jeda otomatis diaktifkan, status yang dilaporkannya akan menyertakan nilai berikut:
| Keadaan | Deskripsi |
|---|---|
| Online | Database sedang online. |
| Menjeda | Database beralih dari online ke dijeda. |
| Dijeda | Database sedang dijeda. |
| Melanjutkan | Database beralih dari dijeda ke online. |
Menggunakan portal Microsoft Azure
Di portal Azure, status database ditampilkan di halaman gambaran umum database dan di halaman gambaran umum servernya. Di portal Azure juga, riwayat peristiwa jeda dan lanjutnya dari basis data tanpa server dapat dilihat di Activity log.
Menggunakan PowerShell
Tampilkan status database saat ini menggunakan contoh PowerShell berikut ini:
Get-AzSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename `
| Select -ExpandProperty "Status"
Gunakan Azure CLI
Lihat status database saat ini menggunakan contoh Azure CLI berikut:
az sql db show --name $databasename --resource-group $resourcegroupname --server $servername --query 'status' -o json
Batas Sumber Daya
Untuk batas sumber daya, lihat lapisan komputasi tanpa server.
Billing
Jumlah komputasi yang ditagih untuk database tanpa server adalah maksimum CPU yang digunakan dan memori yang digunakan setiap detik. Jika jumlah CPU dan memori yang digunakan kurang dari jumlah minimum yang disediakan untuk setiap sumber daya, jumlah yang disediakan akan ditagih. Untuk membandingkan CPU dengan memori untuk tujuan penagihan, memori dinormalisasi menjadi unit vCore dengan menskalakan ulang jumlah GB sebesar 3 GB per vCore.
- Sumber daya ditagih: CPU dan memori
- Jumlah yang ditagih: harga satuan vCore * maksimum (vCore minimum, vCore yang digunakan, memori minimum GB * 1/3, GB memori yang digunakan * 1/3)
- Frekuensi penagihan: Per detik
Harga unit vCore adalah biaya per vCore untuk setiap detik.
Lihat halaman harga Azure SQL Database untuk harga satuan spesifik di suatu wilayah.
Jumlah komputasi yang ditagih dalam database Tujuan Umum tanpa server, atau replika utama atau bernama Hyperscale diekspos oleh metrik berikut:
- Metrik: app_cpu_billed (detik vCore)
- Definisi: maksimum (vCore minimum, vCore yang digunakan, memori minimum GB * 1/3, memori yang digunakan GB * 1/3)
- Frekuensi pelaporan: Per menit berdasarkan pengukuran per detik yang dikumpulkan selama 1 menit.
Jumlah komputasi yang ditagih tanpa server untuk replika Hyperscale HA milik replika utama atau replika bernama apa pun diekspos oleh metrik berikut:
- Metrik: app_cpu_billed_HA_replicas (detik vCore)
- Definisi: Jumlah maksimum dari (vCore minimum, vCore yang digunakan, memori GB minimum * 1/3, memori GB yang digunakan * 1/3) untuk setiap replika HA yang merupakan bagian dari sumber daya induknya.
- Sumber daya induk dan titik akhir metrik: Replika utama dan setiap replika bernama masing-masing mengekspos metrik ini secara terpisah, yang mengukur pemrosesan komputasi yang ditagih untuk replika KETERSEDIAAN TINGGI terkait.
- Frekuensi pelaporan: Per menit berdasarkan pengukuran per detik yang dikumpulkan selama 1 menit.
Tagihan komputasi minimum
Jika database tanpa server dijeda, maka tagihan komputasi adalah nol. Jika database tanpa server tidak dijeda, maka tagihan komputasi minimum tidak kurang dari jumlah vCore berdasarkan maksimum (vCore minimum, memori minimum GB * 1/3).
Contoh:
- Misalkan database tanpa server di tingkat Tujuan Umum tidak dijeda dan dikonfigurasi dengan 8 vCore maksimum dan 1 vCore minimum yang sesuai dengan memori minimum 3,0 GB. Kemudian tagihan komputasi minimum didasarkan pada maksimum (1 vCore, 3,0 GB * 1 vCore / 3 GB) = 1 vCore.
- Misalkan sebuah database serverless di tingkat General Purpose tidak dijeda dan dikonfigurasi dengan maksimum 4 vCore dan minimum 0,5 vCore, yang sesuai dengan memori minimum 2,1 GB. Kemudian tagihan komputasi minimum didasarkan pada maksimum (0,5 vCore, 2,1 GB * 1 vCore / 3 GB) = 0,7 vCore.
- Misalkan database tanpa server di tingkat Hyperscale memiliki replika utama dengan satu replika HA dan satu replika yang diberi nama tanpa replika HA. Misalkan setiap replika dikonfigurasi dengan 8 vCore maksimum dan 1 vCore minimum yang sesuai dengan memori minimum 3 GB. Kemudian tagihan komputasi minimum untuk replika utama, replika HA, dan replika bernama masing-masing didasarkan pada maksimum (1 vCore, 3 GB * 1 vCore / 3 GB) = 1 vCore.
Kalkulator harga Azure SQL Database tanpa server dapat digunakan untuk menentukan memori minimum yang bisa dikonfigurasi berdasarkan jumlah vCore maksimum dan minimum yang dikonfigurasi. Sebagai aturan, jika vCore minimum yang dikonfigurasi lebih besar dari 0,5 vCore, maka tagihan komputasi minimum tidak bergantung pada memori minimum yang dikonfigurasi dan hanya berdasarkan jumlah vCore minimum yang dikonfigurasi.
Contoh skenario
- Tujuan Umum
- Hyperscale
Pertimbangkan database tanpa server di tingkat Tujuan Umum yang dikonfigurasi dengan 1 vCore minimum dan 4 vCore maksimum. Konfigurasi ini sesuai dengan memori minimum sekitar 3 GB dan memori maksimum 12 GB. Misalkan jeda otomatis diatur menjadi 6 jam, dan beban kerja database aktif selama 2 jam pertama dalam periode 24 jam, kemudian tidak aktif.
Dalam kasus ini, biaya komputasi dan penyimpanan untuk database dikenakan selama 8 jam pertama. Meskipun database tidak aktif mulai setelah jam kedua, database masih ditagih untuk komputasi dalam 6 jam berikutnya berdasarkan komputasi minimum yang disediakan saat database online. Biaya hanya dikenakan untuk penyimpanan selama sisa periode 24 jam saat database dijeda.
Lebih tepatnya, tagihan komputasi dalam contoh ini dihitung sebagai berikut:
| Interval Waktu | vCore digunakan setiap detik | GB digunakan setiap detik | Dimensi komputasi ditagih | Waktu detik vCore ditagihkan selama interval waktu |
|---|---|---|---|---|
| 0:00-1:00 | 4 | 9 | vCores digunakan | 4 vCore * 3.600 detik = 14.400 vCore detik |
| 1:00-2:00 | 1 | 12 | Memori yang digunakan | 12 GB * 1/3 * 3.600 detik = 14.400 vCore detik |
| 2.00-8.00 | 0 | 0 | Memori minimum yang disediakan | 3 GB * 1/3 * 21.600 detik = 21.600 detik vCore |
| 8.00-24.00 | 0 | 0 | Tidak ada biaya komputasi saat dijeda | 0 vCore detik |
| Total detik vCore yang ditagih selama 24 jam | 50.400 vCore detik |
Misalkan harga satuan komputasi adalah $0,000145/vCore/detik. Kemudian komputasi yang ditagihkan untuk periode 24 jam ini adalah hasil kali dari harga satuan komputasi dan detik vCore yang ditagihkan: $0,000145/vCore/detik * 50.400 detik vCore ~ $7,31.
Azure Hybrid Benefit dan pemesanan
Diskon Azure Hybrid Benefit (AHB) dan Azure Reservations tidak berlaku untuk tingkat komputasi tanpa server.
Wilayah yang telah tersedia
Untuk ketersediaan regional, lihat Ketersediaan tanpa server menurut wilayah untuk Azure SQL Database.
Konten terkait
- Panduan Cepat: Membuat database tunggal - Azure SQL Database.
- Untuk pilihan tingkat layanan tanpa server, lihat Tujuan Umum dan Hyperscale.