Jeda otomatis dan lanjut otomatis pada tingkat komputasi tanpa server untuk Azure SQL Database

Berlaku untuk:Azure SQL Database

Artikel ini menjelaskan perilaku auto-pause dan auto-resume untuk tier komputasi serverless di Azure SQL Database, serta bagaimana interaksinya dengan berbagai fitur Azure SQL Database.

Saat ini, lapisan layanan General Purpose adalah satu-satunya lapisan layanan yang mendukung jeda otomatis dan pelanjutan otomatis pada komputasi tanpa server.

Untuk memantau status database tanpa server, lihat Memantau status jeda dan lanjutkan.

Jeda otomatis

Auto-pause akan dimulai jika semua kondisi berikut terpenuhi selama jeda auto-pause:

  • Jumlah sesi = 0
  • CPU = 0 untuk beban kerja pengguna yang berjalan di kumpulan sumber daya pengguna

Secara default, ada jeda otomatis satu jam.

Fitur yang mencegah jeda otomatis

Jika Anda menggunakan salah satu fitur berikut, nonaktifkan jeda otomatis. Database tetap online terlepas dari berapa lama database tidak aktif. Fitur-fitur berikut mencegah auto-pause, tetapi mendukung auto-scaling:

Skenario fitur berikut juga mencegah jeda otomatis:

  • Database sinkronisasi yang digunakan dalam SQL Data Sync. Tidak seperti database sinkronisasi, database hub dan anggota mendukung jeda otomatis.
  • Dalam pekerjaan elastis, database serverless dengan auto-pause diaktifkan tidak didukung sebagai database job. Database serverless yang menjadi target job 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.

Lanjutkan otomatis

Lanjutan otomatis dimulai jika salah satu kondisi berikut benar kapan saja:

Feature Pemicu resume otomatis
Autentikasi dan otorisasi Upaya masuk
Deteksi ancaman Mengaktifkan atau menonaktifkan pengaturan deteksi ancaman di tingkat basis data atau server.
Memodifikasi pengaturan deteksi ancaman pada tingkat database atau server.
Penemuan dan klasifikasi data Menambahkan, memodifikasi, menghapus, atau menampilkan label sensitivitas
Auditing Melihat rekaman audit.
Memperbarui atau melihat kebijakan audit.
Penyamaran data Menambahkan, memodifikasi, menghapus, atau menampilkan aturan masking data
Enkripsi transparan untuk data 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 Query Store
Rekomendasi kinerja Menampilkan atau menerapkan rekomendasi performa
Penyetelan otomatis Penerapan dan verifikasi rekomendasi penalaan 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 atau memodifikasi tag Azure pada database.
Mengubah vCore maksimum, vCore minimum, atau penundaan jeda otomatis.
SQL Server Management Studio (SSMS) Pada versi SSMS sebelum 18.1, saat membuka jendela kueri baru untuk database apa pun pada server, database yang dijeda secara otomatis pada server yang sama akan dilanjutkan kembali. Perilaku ini tidak terjadi jika Anda menggunakan SSMS versi 18.1 atau lebih baru.

Pemantauan, pengelolaan, atau solusi lain yang menjalankan salah satu operasi ini akan memicu pelanjutan otomatis. Pelanjutan otomatis juga dimulai saat proses penerapan beberapa pembaruan layanan yang mengharuskan database berada dalam keadaan online.

Lanjutkan otomatis identifikasi pemicu

Log aktivitas Azure Monitor mengekspos pemicu lanjut otomatis untuk operasi Resume Databases di bawah properti Caller dalam JSON peristiwa Started dan Succeeded. Untuk informasi lebih lanjut, lihat Memantau tingkat komputasi tanpa server.

Latensi

Latensi umumnya berkisar sekitar satu menit untuk melanjutkan otomatis dan 1–10 menit untuk jeda otomatis. Latensi untuk salah satu operasi dapat serendah dalam kisaran satu detik.

Enkripsi data transparan yang dikelola pelanggan

Penghapusan atau pencabutan kunci

Jika Anda menggunakan enkripsi data transparan yang dikelola pelanggan (bawa kunci sendiri atau BYOK) dan database tanpa server akan otomatis dijeda saat penghapusan atau pencabutan kunci, database tetap dalam keadaan auto-paused. 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 serverless sedang online saat kunci dihapus atau dicabut, database tersebut juga akan menjadi tidak dapat diakses dalam waktu sekitar 10 menit, sama seperti pada database dengan komputasi terprovisi.

Rotasi kunci

Jika Anda menggunakan enkripsi data transparan yang dikelola pelanggan (BYOK) dan mengaktifkan jeda otomatis tanpa server, basis data akan otomatis kembali setiap kali kunci diputar. Basis data kemudian berhenti secara otomatis ketika kondisi jeda otomatis terpenuhi.

Pemecahan masalah jeda otomatis

Pemecahan masalah konektivitas auto-resume

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 kembali berjalan, coba sambungkan kembali. Basis data umumnya kembali aktif dalam waktu kurang dari satu menit.

Semua aplikasi yang terhubung ke cloud sebaiknya menggunakan rekomendasi logika percobaan ulang koneksi. Aplikasi memerlukan logika retry untuk berhasil setelah kesalahan konektivitas sementara. Mekanisme percobaan ulang sangat penting untuk database nirserver, yang mana kesalahan konektivitas sementara yang disebabkan oleh auto-resume sudah dapat diperkirakan.

Untuk opsi dan rekomendasi logika coba lagi koneksi, lihat:

Mengatasi masalah jeda otomatis

Jika Anda mengaktifkan auto-pause dan tidak menggunakan fitur yang memblokir auto-pause, tetapi database tidak auto-pause setelah periode penundaan, aplikasi atau sesi pengguna mungkin mencegah auto-pause.

Untuk melihat apakah ada sesi aplikasi atau pengguna yang saat ini terhubung ke database, 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, hal itu menunjukkan bahwa saat ini ada sesi yang mencegah penjedaan otomatis.
  • Jika kumpulan hasil kosong, masih ada kemungkinan bahwa ada sesi yang terbuka, mungkin untuk waktu yang singkat, pada suatu waktu sebelumnya selama periode penundaan jeda otomatis. Untuk memeriksa aktivitas selama periode penundaan, gunakan Auditing for Azure SQL Database dan Azure Synapse Analytics serta periksa data audit untuk periode yang relevan.

Important

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.

Konten terkait

  • Last updated on