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 Managed Instance
Artikel ini mencantumkan masalah yang saat ini diketahui dengan Azure SQL Managed Instance, dan tanggal resolusi atau kemungkinan solusinya. Untuk mempelajari selengkapnya tentang Azure SQL Managed Instance, lihat Apa itu Azure SQL Managed Instance?, dan Apa yang baru di Azure SQL Managed Instance?
Catatan
ID Microsoft Entra sebelumnya dikenal sebagai Azure Active Directory (Azure AD).
Masalah umum
Memiliki solusi
Memulihkan kegagalan operasi setelah bermigrasi ke SQL Managed Instance
Jika Anda memigrasikan database ke Azure SQL Managed Instance dari SQL Server 2019 dan versi yang lebih baru dengan pemulihan database yang dipercepat diaktifkan, tetapi dikonfigurasi dengan penyimpanan versi persisten (PVS) yang diatur ke sesuatu selain PRIMARY grup file, Anda dapat mengalami kegagalan operasi pemulihan pada instans terkelola SQL target.
Untuk mengatasi masalah ini, pastikan Anda mengatur penyimpanan versi persisten (PVS) ke PRIMARY pada database SQL Server sumber sebelum Anda memigrasikannya ke SQL Managed Instance. Jika Anda sudah memigrasikan database tanpa mengatur PVS ke PRIMARY, Anda dapat mengaturnya pada database SQL Server sumber, lalu memigrasikan ulang database ke SQL Managed Instance.
Tidak dapat menggunakan pemulihan database yang dipercepat setelah bermigrasi ke SQL Managed Instance
Dimulai dengan SQL Server 2019, jika Anda memigrasikan database ke Azure SQL Managed Instance, dan pemulihan database yang dipercepat dinonaktifkan pada database sumber, Anda tidak dapat menggunakan pemulihan database yang dipercepat pada instans terkelola SQL target.
Untuk mengatasi masalah ini, pastikan Anda mengaktifkan pemulihan database yang dipercepat pada database SQL Server sumber sebelum Anda memigrasikannya ke SQL Managed Instance. Jika Anda sudah memigrasikan database tanpa mengaktifkan pemulihan database yang dipercepat, Anda dapat mengaktifkannya pada database SQL Server sumber, lalu memigrasikan ulang database ke instans terkelola SQL.
SQL Server 2017 dan versi yang lebih lama tidak mendukung pemulihan database yang dipercepat, sehingga masalah ini tidak berlaku untuk database yang dimigrasikan dari versi SQL Server tersebut.
Tidak dapat menggunakan Service Broker setelah bermigrasi ke SQL Managed Instance
Jika Anda memigrasikan database ke Azure SQL Managed Instance, dan Service Broker dinonaktifkan pada database sumber, Anda tidak dapat menggunakan Service Broker pada instans terkelola SQL target.
Untuk mengatasi masalah ini, pastikan Anda mengaktifkan Service Broker pada database SQL Server sumber sebelum Anda memigrasikannya ke SQL Managed Instance. Jika Anda sudah memigrasikan database tanpa mengaktifkan Service Broker, Anda dapat mengaktifkannya di database SQL Server sumber, lalu memigrasikan ulang database ke SQL Managed Instance.
Memodifikasi periode retensi cadangan untuk penawaran gratis
Anda hanya dapat mengubah kebijakan penyimpanan cadangan database Anda di instans terkelola SQL gratis dengan menggunakan perintah REST API, PowerShell, dan Azure CLI . Anda tidak dapat mengubah kebijakan penyimpanan cadangan melalui portal Microsoft Azure.
Login ke read-secondary gagal karena adanya penundaan lama di "HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING"
Anda mungkin melihat kesalahan ini sebagai pengecualian untuk Driver Microsoft OLE DB 19 untuk SQL Server saat Anda mencoba menyambungkan ke replika sekunder yang bersifat read-only dari grup failover, atau database yang direplikasi melalui tautan Instans Terkelola.
Kesalahan ini terjadi ketika replika sekunder tidak tersedia untuk masuk karena versi baris hilang untuk transaksi yang sedang dalam penerbangan ketika replika sekunder dimulai ulang atau didaur ulang, baik untuk pemeliharaan atau karena failover. Saat instans dimulai ulang atau gagal, data penerapan versi yang disimpan di tempdb akan dihapus. Kueri baca sekunder dibatalkan jika ada transaksi berjalan lama yang dimulai sebelum failover atau restart.
Untuk mengatasi masalah ini, gulung balik atau lakukan transaksi aktif pada replika utama. Untuk menghindari kesalahan ini, minimalkan transaksi tulis yang berjalan lama pada replika utama.
Kesalahan 8992 saat menjalankan DBCC CHECKDB pada database SQL Server yang berasal dari SQL Managed Instance
Anda mungkin melihat kesalahan berikut saat menjalankan DBCC CHECKDB perintah pada database SQL Server 2022 setelah Anda menghapus indeks, atau tabel dengan indeks, dan database yang berasal dari Azure SQL Managed Instance, seperti setelah memulihkan file cadangan, atau dari fitur tautan SQL Managed Instance:
Msg 8992, Level 16, State 1, Line <Line_Number>
Check Catalog Msg 3853, State 1: Attribute (%ls) of row (%ls) in sys.sysrowsetrefs does not have a matching row (%ls) in sys.indexes.
Untuk mengatasi masalah ini, pertama-tama hilangkan indeks, atau tabel dengan indeks, dari database sumber di Azure SQL Managed Instance, lalu pulihkan, atau tautkan, database ke SQL Server 2022 lagi. Jika membuat ulang database dari Azure SQL Managed Instance sumber tidak dimungkinkan, hubungi dukungan Microsoft untuk membantu mengatasi masalah ini.
Perhatian
Jika Anda membuat indeks yang dipartisi pada tabel setelah menghilangkan indeks seperti yang dijelaskan dalam skenario ini, tabel menjadi tidak dapat diakses.
Daftar cadangan jangka panjang di portal Azure memperlihatkan file cadangan untuk database aktif dan dihapus dengan nama yang sama
Cadangan jangka panjang dapat dicantumkan dan dikelola di halaman portal Microsoft Azure untuk Azure SQL Managed Instance pada tab Cadangan . Halaman ini mencantumkan database aktif atau dihapus, informasi dasar tentang cadangan jangka panjang mereka, dan tautan untuk mengelola cadangan. Saat Anda memilih tautan Kelola , panel sisi baru terbuka dengan daftar cadangan. Karena masalah dengan logika pemfilteran, daftar memperlihatkan cadangan untuk database aktif dan database yang dihapus dengan nama yang sama. Ini memerlukan perhatian khusus saat memilih cadangan untuk dihapus, untuk menghindari penghapusan cadangan untuk database yang salah.
Solusi sementara: Gunakan informasi Waktu pencadangan (UTC) yang ditampilkan dalam daftar untuk membedakan cadangan milik database dengan nama yang sama yang ada pada instans pada periode yang berbeda. Atau, gunakan perintah PowerShell Get-AzSqlInstanceDatabaseLongTermRetentionBackup dan Remove-AzSqlInstanceDatabaseLongTermRetentionBackup, atau perintah CLI az sql midb ltr-backup list dan az sql midb ltr-backup delete untuk mengelola cadangan jangka panjang menggunakan parameter DatabaseState dan nilai pengembalian DatabaseDeletionTime untuk memfilter cadangan untuk database.
Prosedur sp_send_dbmail mungkin gagal saat parameter @query digunakan
Prosedur sp_send_dbmail yang tersimpan mungkin gagal ketika parameter @query digunakan. Kegagalan terjadi ketika prosedur tersimpan dijalankan di bawah akun sysadmin .
Masalah ini disebabkan oleh bug yang diketahui terkait dengan cara sp_send_dbmail menggunakan peniruan.
Solusi sementara: Pastikan Anda memanggil sp_send_dbmail di bawah akun kustom yang sesuai yang Anda buat, dan bukan di bawah akun sysadmin .
Berikut adalah contoh bagaimana Anda dapat membuat akun khusus dan memodifikasi objek yang ada yang mengirim email melalui sp_send_dbmail.
USE [msdb];
GO
-- Step 1: Create a user mapped to a login to specify as a runtime user.
CREATE USER [user_name] FOR LOGIN [login_name];
GO
EXECUTE msdb.dbo.sp_update_jobstep
@job_name = N'db_mail_sending_job',
@step_id = db_mail_sending_job_id,
@database_user_name = N'user_name';
GO
-- Step 2: Grant DB Mail permissions to the user who created it.
ALTER ROLE [DatabaseMailUserRole] ADD MEMBER [user_name];
GO
-- Step 3: If the database of the job step is not msdb, the permission error cannot be avoided even if it is a member of the role, so set it to msdb.
EXECUTE msdb.dbo.sp_update_jobstep
@job_name = N'db_mail_sending_job',
@step_id = db_mail_sending_job_id,
@database_name = N'msdb';
GO
-- Step 4: Set a principal in the email profile
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
@principal_name = N'user_name',
@profile_name = N'profile_name',
@is_default = 0;
GO
Transaksi terdistribusi dapat dijalankan setelah menghapus instans terkelola SQL dari Grup Kepercayaan Server
Grup Kepercayaan Server digunakan untuk membangun kepercayaan antara instans terkelola yang merupakan prasyarat untuk mengeksekusi transaksi terdistribusi. Setelah menghapus instans terkelola SQL dari Grup Kepercayaan Server atau menghapus grup, Anda mungkin masih dapat menjalankan transaksi terdistribusi. Untuk memastikan bahwa transaksi terdistribusi dinonaktifkan, lakukan failover manual yang dimulai pengguna pada instans terkelola SQL.
Tidak dapat membuat SQL Managed Instance dengan nama yang sama dengan server logis yang sebelumnya dihapus
Saat Anda membuat server logis di Azure untuk Azure SQL Database atau SQL Managed Instance, sistem membuat catatan DNS untuk <name>.database.windows.com. Catatan DNS ini harus unik. Jika Anda membuat server logis untuk SQL Database lalu menghapusnya, namanya akan tetap disimpan selama tujuh hari. Selama periode ini, Anda tidak dapat membuat SQL Managed Instance dengan nama yang sama dengan server logis yang dihapus. Sebagai solusinya, gunakan nama yang berbeda untuk SQL Managed Instance, atau membuat tiket dukungan untuk merilis nama server logis.
Perwakilan Layanan tidak dapat mengakses ID Microsoft Entra dan AKV
Dalam beberapa keadaan, ada masalah dengan Perwakilan Layanan yang digunakan untuk mengakses layanan MICROSOFT Entra ID (sebelumnya Azure Active Directory) dan Azure Key Vault (AKV). Akibatnya, masalah ini berdampak pada penggunaan autentikasi Microsoft Entra dan enkripsi data transparan (TDE) dengan SQL Managed Instance. Anda mungkin mengalami masalah ini sebagai masalah konektivitas yang terputus-putus, atau tidak dapat menjalankan pernyataan seperti CREATE LOGIN/USER FROM EXTERNAL PROVIDER, atau EXECUTE AS LOGIN/USER. Menyiapkan TDE dengan kunci yang dikelola oleh pelanggan pada instance SQL Azure baru dapat juga tidak berfungsi dalam beberapa keadaan.
Solusi sementara: Untuk mencegah masalah ini terjadi pada SQL Managed Instance Anda, sebelum menjalankan perintah pembaruan apa pun, atau jika Anda sudah mengalami masalah ini setelah perintah pembaruan, buka halaman Gambaran Umum instans terkelola SQL Anda di portal Microsoft Azure. Di bawah Pengaturan, pilih Microsoft Entra ID untuk mengakses halaman admin Microsoft Entra ID SQL Managed Instance. Cari pesan kesalahan berikut:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Jika Anda menemukan pesan kesalahan ini, pilih pesan tersebut, dan ikuti instruksi langkah demi langkah yang disediakan hingga kesalahan ini diselesaikan.
Kesalahan yang salah dikembalikan ketika mencoba menghapus file yang tidak kosong
SQL Server dan SQL Managed Instance tidak mengizinkan pengguna untuk menjatuhkan file yang tidak kosong. Jika Anda mencoba menghapus file data yang tidak kosong dengan menggunakan ALTER DATABASE REMOVE FILE pernyataan, kesalahan:
Msg 5042 - The file '<file_name>' cannot be removed because it is not empty` isn't immediately returned. SQL Managed Instance keeps trying to drop the file, and the operation fails after 30 minutes with `Internal server error.
Mengubah tingkat layanan dan membuat operasi instans diblokir oleh pemulihan database yang sedang berlangsung
Pernyataan yang sedang berlangsung RESTORE, proses migrasi dari Layanan Migrasi Data, dan pemulihan titik waktu bawaan dapat memblokir pembaruan ke tingkat layanan, atau mengubah ukuran instans yang ada dan membuat instans baru, sampai proses pemulihan selesai.
Proses pemulihan memblokir operasi ini pada instans terkelola dan kumpulan instans di subnet yang sama tempat proses pemulihan berjalan. Instans yang ada dalam kumpulan instans tidak terpengaruh. Pembuatan atau perubahan operasi tingkat layanan tidak mengalami kegagalan atau waktu habis. Operasi ini dilanjutkan setelah proses pemulihan selesai atau dibatalkan.
Penanganan masalah: Tunggu hingga proses pemulihan selesai, atau batalkan proses pemulihan jika operasi pembuatan atau update-service-tier memiliki prioritas yang lebih tinggi.
Resource Governor pada replika sekunder yang dapat dibaca memerlukan konfigurasi ulang setelah failover
Fitur Resource governor yang memungkinkan Anda membatasi sumber daya yang ditetapkan ke beban kerja pengguna mungkin salah mengklasifikasikan beberapa beban kerja pengguna setelah failover atau perubahan tingkat layanan yang diinisiasi pengguna (misalnya, perubahan vCore maksimum atau ukuran penyimpanan instance maksimum).
Solusi sementara: Jalankan ALTER RESOURCE GOVERNOR RECONFIGURE secara berkala atau sebagai bagian dari pekerjaan SQL Agent yang menjalankan tugas SQL saat replika sekunder yang dapat dibaca dimulai jika Anda menggunakan Resource governor.
Ruang penyimpanan terlampaui oleh file database yang kecil
CREATE DATABASE, ALTER DATABASE ADD FILE, dan RESTORE DATABASE pernyataan dapat gagal karena instans mencapai batas Azure Storage pada tier layanan General Purpose, tetapi bukan pada tier upgrade layanan Next-gen General Purpose atau tier layanan Business Critical.
Setiap instans Tujuan Umum SQL Managed Instance memiliki penyimpanan hingga 35 TB yang disediakan untuk ruang Disk Premium Azure. Setiap file database ditempatkan pada disk fisik terpisah. Ukuran disk bisa sebesar 128 GB, 256 GB, 512 GB, 1 TB, atau 4 TB. Anda tidak dikenakan biaya untuk ruang yang tidak digunakan pada disk, tetapi jumlah total ukuran Disk Premium Azure tidak boleh melebihi 35 TB. Dalam beberapa kasus, instans terkelola SQL yang tidak memerlukan total 8 TB mungkin melebihi batas Azure 35 TB pada ukuran penyimpanan karena fragmentasi internal.
Misalnya, instans Tujuan Umum SQL Managed Instance mungkin memiliki satu file besar berukuran 1,2 TB yang ditempatkan pada disk 4-TB. Ini juga mungkin memiliki 248 file yang masing-masing berukuran 1 GB dan yang ditempatkan pada disk 128-GB terpisah. Dalam contoh ini:
- Total ukuran penyimpanan disk yang dialokasikan adalah 1 x 4 TB + 248 x 128 GB = 35 TB.
- Total ruang yang dipesan untuk database pada instans adalah 1 x 1,2 TB + 248 x 1 GB = 1,4 TB.
Contoh ini menggambarkan bahwa dalam kondisi tertentu, karena distribusi file yang spesifik, instans SQL Managed Instance mungkin mencapai batas 35 TB yang dicadangkan untuk Disk Premium Azure yang terlampir, bahkan ketika Anda tidak menduganya.
Dalam contoh ini, database yang ada terus berfungsi dan dapat tumbuh tanpa masalah selama file baru tidak ditambahkan. Anda tidak dapat membuat atau memulihkan database baru karena tidak ada cukup ruang untuk drive disk baru, bahkan jika ukuran total semua database tidak mencapai batas ukuran instans. Kesalahan yang dikembalikan tidak jelas.
Anda dapat mengidentifikasi jumlah file yang tersisa dengan menggunakan tampilan sistem. Jika Anda mencapai batas ini, cobalah untuk mengosongkan dan menghapus beberapa file yang lebih kecil dengan menggunakan pernyataan DBCC SHRINKFILE atau beralih ke tingkat Business Critical, yang tidak memiliki batas ini.
Nilai GUID akan ditampilkan, bukan nama database
Beberapa tampilan sistem, penghitung kinerja, pesan kesalahan, XEvents, dan entri log kesalahan menampilkan pengidentifikasi database GUID alih-alih nama database aktual. Jangan mengandalkan pengidentifikasi GUID ini karena mungkin diganti dengan nama database aktual di masa mendatang.
Solusi Sementara: Gunakan tampilan sys.databases untuk menemukan nama database aktual dari nama database fisik, yang ditentukan dalam bentuk pengidentifikasi database GUID.
SELECT name AS ActualDatabaseName,
physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;
Modul CLR dan server yang ditautkan terkadang tidak dapat mereferensikan alamat IP lokal
Modul CLR di SQL Managed Instance dan server tertaut atau kueri terdistribusi yang mereferensikan instans saat ini terkadang tidak dapat menyelesaikan IP instans lokal. Kesalahan ini adalah masalah sementara.
Tidak ada resolusi
Pesan kesalahan yang menyesatkan saat menyambungkan ke read replica menggunakan kredensial yang tidak valid
Saat Anda mencoba menyambungkan ke replika baca-sekunder instans tingkat Kritis Bisnis dengan menggunakan ApplicationIntent=ReadOnly dan kredensial yang tidak valid, instans melaporkan kesalahan yang menunjukkan bahwa master database bersifat baca-saja. Instans tidak melaporkan dengan benar bahwa kredensial tidak valid.
Cadangan diferensial tidak diambil saat instans ditautkan ke SQL Server
Saat Anda mengonfigurasi tautan antara SQL Server dan Azure SQL Managed Instance, pencadangan otomatis lengkap dan log transaksi dilakukan pada Azure SQL Managed Instance, terlepas dari apakah berfungsi sebagai peran utama atau tidak. Namun, cadangan diferensial saat ini tidak dilakukan, yang dapat menyebabkan waktu pemulihan lebih lama dari yang diharapkan.
Peningkatan jumlah login sistem yang digunakan untuk replikasi transaksional
Layanan Azure SQL Managed Instance membuat login sistem untuk tujuan replikasi transaksional. Anda dapat menemukan login ini di SSMS (diLogin>>) atau dalam sys.syslogins tampilan sistem. Format nama login terlihat seperti DBxCy\WF-abcde01234QWERT, dan login memiliki peran server publik . Dalam kondisi tertentu, login ini dibuat ulang, dan karena masalah internal, login sebelumnya tidak dihapus. Kesalahan ini dapat menyebabkan peningkatan jumlah login. Login ini tidak mewakili ancaman keamanan, dan Anda dapat mengabaikannya dengan aman. Jangan hapus login ini, karena setidaknya salah satunya digunakan untuk replikasi transaksional.
Login serta pengguna Microsoft Entra tidak didukung di SSDT
SQL Server Data Tools tidak sepenuhnya mendukung login dan pengguna Microsoft Entra.
Peniruan jenis login Microsoft Entra tidak didukung
Peniruan menggunakan EXECUTE AS USER atau EXECUTE AS LOGIN tidak didukung untuk entitas Microsoft Entra berikut:
- Pengguna Microsoft Entra yang memiliki alias. Dalam hal ini, operasi mengembalikan kesalahan
15517. - Login dan pengguna Microsoft Entra berdasarkan aplikasi Microsoft Entra atau principal layanan. Dalam hal ini, operasi mengembalikan kesalahan
15517dan15406.
Replikasi transaksional harus dikonfigurasi ulang setelah kegagalan geografis (geo-failover)
Jika Anda mengaktifkan replikasi transaksional pada database dalam grup failover, administrator SQL Managed Instance harus membersihkan semua publikasi pada primer lama dan mengonfigurasi ulang pada primer baru setelah failover ke wilayah lain terjadi. Untuk informasi selengkapnya, lihat Replikasi.
Log kesalahan tidak disimpan
Log kesalahan yang tersedia di SQL Managed Instance tidak bertahan, dan ukurannya tidak termasuk dalam batas penyimpanan maksimum. Log kesalahan mungkin akan dihapus secara otomatis jika terjadi failover. Celah mungkin ada dalam riwayat log kesalahan karena SQL Managed Instance dipindahkan beberapa kali pada beberapa komputer virtual.
Diselesaikan
Panduan sementara tentang pembaruan zona waktu 2024 untuk Paraguay
(Diselesaikan pada Februari 2026)
Pada 14 Oktober 2024, pemerintah Paraguay mengumumkan perubahan permanen pada kebijakan zona waktu. Paraguay sekarang tetap pada daylight saving time (DST) sepanjang tahun, secara efektif mengadopsi UTC-3 sebagai waktu standarnya. Akibatnya, jam tidak maju pada 60 menit pada pukul 12:00 pada 23 Maret 2025, seperti yang dijadwalkan sebelumnya. Perubahan ini memengaruhi zona waktu Standar Paraguay. Microsoft telah merilis pembaruan Windows terkait pada bulan Februari dan Maret 2025. Instans terkelola SQL yang menggunakan zona waktu yang terpengaruh akan mencerminkan perubahan ini dan mengikuti offset UTC-3 baru.
Mengubah jenis koneksi tidak memengaruhi koneksi melalui titik akhir grup failover
(Diselesaikan pada November 2025)
Jika sebuah instans berpartisipasi dalam grup failover, perubahan jenis koneksi instans tidak berpengaruh pada koneksi yang dibuat melalui titik akhir listener grup failover.
Ketidakmampuan mengakses instans sementara karena penggunaan pendengar grup failover saat operasi penskalaan.
(Diselesaikan pada April 2025)
Penskalaan instans terkelola SQL kadang memerlukan memindahkan instans ke kluster virtual lain, bersama dengan rekaman DNS terkait yang dikelola oleh layanan. Jika instance yang dikelola SQL berpartisipasi dalam grup failover, catatan DNS yang sesuai dengan pendengar grup failover terkait (pendengar baca-tulis jika instance adalah geo-primer saat ini, atau pendengar baca-saja jika instance adalah geo-sekunder saat ini) dipindahkan ke kluster virtual baru.
Dalam desain operasi penskalaan saat ini, rekaman DNS pendengar dihapus dari kluster virtual asal sebelum sepenuhnya memigrasikan instans terkelola SQL ke kluster virtual baru. Dalam beberapa situasi, desain ini menyebabkan waktu yang lama di mana alamat IP instans tidak dapat diselesaikan dengan menggunakan pendengar. Selama waktu ini, klien SQL yang mencoba mengakses instans yang sedang diskalakan dengan menggunakan endpoint pendengar dapat mengharapkan kegagalan masuk dengan pesan kesalahan berikut:
Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).
Masalah ini akan diatasi melalui desain ulang operasi penskalakan.
Tabel untuk pencadangan manual di msdb tidak mempertahankan nama pengguna
(Diselesaikan pada Agustus 2023) Dukungan yang baru-baru ini diperkenalkan untuk pencadangan otomatis di msdb saat ini tidak menyertakan informasi nama pengguna.
Saat Anda menggunakan autentikasi SQL Server, nama pengguna dengan '@' tidak didukung
Nama pengguna yang berisi @ simbol di tengah (misalnya, abc@xy) tidak dapat masuk menggunakan autentikasi SQL Server.
Memulihkan cadangan manual tanpa CHECKSUM mungkin gagal
(Diselesaikan pada Juni 2020) Dalam keadaan tertentu, memulihkan cadangan manual database yang Anda buat pada instans terkelola SQL tanpa CHECKSUM mungkin gagal. Dalam kasus seperti itu, coba sekali lagi memulihkan backup sampai Anda berhasil.
Solusi sementara: Lakukan pencadangan manual database pada instans terkelola SQL dengan CHECKSUM diaktifkan.
Izin pada grup sumber daya yang tidak diterapkan ke SQL Managed Instance
Saat Anda menerapkan peran Azure Kontributor SQL Managed Instance pada suatu grup sumber daya (RG), peran tersebut tidak berlaku untuk SQL Managed Instance dan tidak memberikan efek apa pun.
Penanganan masalah: Menyiapkan peran Kontributor SQL Managed Instance untuk pengguna di tingkat langganan.
Pesan kesalahan yang menyesatkan di portal Microsoft Azure yang menyarankan pembuatan ulang Service Principal
Halaman admin Direktori Aktif untuk Azure SQL Managed Instance di portal Azure mungkin menampilkan pesan kesalahan berikut, meskipun Prinsipal Layanan sudah ada.
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Anda dapat mengabaikan pesan kesalahan ini jika Perwakilan Layanan untuk instans terkelola SQL sudah ada, dan/atau autentikasi Microsoft Entra pada instans terkelola SQL berfungsi.
Untuk memeriksa apakah Perwakilan Layanan ada, navigasikan ke halaman Aplikasi perusahaan di portal Microsoft Azure, pilih Identitas Terkelola dari daftar dropdown Jenis aplikasi , pilih Terapkan, dan ketik nama instans terkelola SQL di kotak pencarian. Jika nama instans muncul dalam daftar hasil, Service Principal sudah ada dan tidak diperlukan tindakan lebih lanjut.
Jika Anda sudah mengikuti instruksi dari pesan kesalahan dan memilih tautannya, Prinsipal Layanan dari instans terkelola SQL telah dibuat ulang. Dalam hal ini, tetapkan izin baca ID Microsoft Entra ke Perwakilan Layanan yang baru dibuat agar autentikasi Microsoft Entra berfungsi dengan baik. Anda juga dapat menjalankan langkah ini dengan Azure PowerShell dengan mengikuti instruksi.
Target file acara dari sesi peristiwa system_health tidak dapat diakses.
(Diselesaikan sebagian pada Mei 2025) Ketika Anda mencoba membaca konten event_file target system_health sesi acara, Anda mendapatkan kesalahan 40538, "URL valid yang dimulai dengan https:// diperlukan sebagai nilai untuk jalur file apa pun yang ditentukan."
Awalnya, masalah ini terjadi di SQL Server Management Studio (SSMS), atau saat membaca data sesi menggunakan fungsi sys.fn_xe_file_target_read_file .
Pada Bulan Mei 2025, masalah ini diselesaikan untuk membaca data sesi dari SSMS. Masalah ini tidak terpecahkan saat membaca data peristiwa dengan menggunakan fungsi sys.fn_xe_file_target_read_file.
Perubahan perilaku ini adalah konsekuensi yang tidak diinginkan dari perbaikan keamanan yang diperlukan. Anda dapat mengatasi masalah ini dengan membuat sesi Anda sendiri yang setara dengan sesi system_health yang memiliki target event_file di Azure Blob Storage. Untuk informasi selengkapnya, termasuk skrip T-SQL untuk membuat sesi system_health yang dapat dimodifikasi untuk membuat yang setara dengan milik Anda sendiri system_health, lihat system_health session.
Dialog Service Broker lintas database memerlukan reinisialisasi setelah peningkatan tingkat layanan
(Diselesaikan pada Januari 2020) Dialog Service Broker lintas database berhenti mengirimkan pesan ke layanan di database lain setelah mengubah operasi tingkat layanan. Pesan tidak hilang, dan dapat ditemukan di antrean pengirim. Setiap perubahan vCore atau ukuran penyimpanan instans service_broke_guid di SQL Managed Instance menyebabkan nilai dalam tampilan sys.databases berubah untuk semua database. Setiap DIALOG yang dibuat menggunakan pernyataan BEGIN DIALOG yang mengacu pada Service Broker di database lain menghentikan pengiriman pesan ke layanan target.
Penanganan masalah: Hentikan aktivitas apa pun yang menggunakan percakapan dialog Broker Layanan lintas database sebelum memperbarui tingkat layanan, dan inisialisasi ulang setelahnya. Jika pesan yang tidak terdeliver tetap ada setelah perubahan tingkat layanan, baca pesan dari antrean sumber dan kirim ulang ke antrean target.
Berkontribusi pada konten
Untuk berkontribusi pada dokumentasi Azure SQL, lihat panduan kontributor Dokumen.
Konten terkait
Untuk mengetahui daftar pembaruan dan penyempurnaan SQL Managed Instance, lihat pembaruan layanan SQL Managed Instance.
Untuk pembaruan dan penyempurnaan pada layanan Azure lainnya, lihat Pembaruan layanan.