Masalah umum dengan Azure SQL Managed Instance
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
Daftar cadangan jangka panjang di portal Azure memperlihatkan file cadangan untuk database aktif dan dihapus dengan nama yang sama
Pencadangan jangka panjang dapat dicantumkan dan dikelola di halaman portal 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.
Target event_file sesi peristiwa system_health tidak dapat diakses
Ketika Anda mencoba membaca konten event_file target system_health sesi peristiwa, Anda mendapatkan kesalahan 40538, "URL valid yang dimulai dengan 'https://' diperlukan sebagai nilai untuk setiap jalur file yang ditentukan." Ini terjadi di SQL Server Management Studio, atau saat membaca data sesi menggunakan fungsi sys.fn_xe_file_target_read_file .
Perubahan perilaku ini adalah konsekuensi yang tidak diinginkan dari perbaikan keamanan yang diperlukan baru-baru ini. Kami sedang menyelidiki kelayakan perubahan tambahan yang akan memungkinkan pelanggan untuk terus menggunakan system_health sesi di Azure SQL Managed Instance dengan aman. Sementara itu, pelanggan dapat mengatasi masalah ini dengan membuat sesi mereka sendiri yang setara system_health dengan event_file target di penyimpanan blob Azure. Untuk informasi selengkapnya, termasuk skrip T-SQL untuk membuat system_health sesi yang dapat dimodifikasi untuk membuat yang setara dengan system_healthAnda sendiri, lihat Menggunakan sesi system_health.
Prosedur sp_send_dbmail mungkin gagal ketika @query parameter
Prosedur sp_send_dbmail mungkin gagal ketika @query parameter 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 identitas.
Solusi sementara: Pastikan Anda memanggil sp_send_dbmail di bawah akun kustom yang sesuai yang telah 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
EXEC 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.
EXEC 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
EXEC msdb.dbo.sysmail_add_principalprofile_sp @principal_name=N'user_name', @profile_name=N'profile_name', @is_default=0
GO
Panduan sementara tentang pembaruan zona waktu 2022 untuk Chili
Pada 8 Agustus 2022, pemerintah Chili membuat pengumuman resmi tentang perubahan zona waktu Daylight-Saving Time (DST). Mulai pukul 12.00 Sabtu, 10 September 2022, hingga pukul 12.00 Sabtu, 1 April 2023, waktu resmi akan maju 60 menit. Perubahan ini memengaruhi tiga zona waktu berikut: Waktu Standar SA Pasifik, Waktu Standar Pulau Paskah, dan Waktu Standar Magallanes. Azure SQL Managed Instances menggunakan zona waktu yang terpengaruh tidak mencerminkan perubahan hingga Microsoft merilis pembaruan OS untuk mendukung ini, dan layanan Azure SQL Managed Instance menyerap pembaruan pada tingkat OS.
Solusi sementara: Jika Anda perlu mengubah zona waktu yang terpengaruh untuk instans terkelola Anda, ketahui batasan dan ikuti panduan dari dokumentasi.
Mengubah jenis koneksi tidak memengaruhi koneksi melalui titik akhir grup failover
Jika instans berpartisipasi dalam grup failover, mengubah jenis koneksi instans tidak berlaku untuk koneksi yang dibuat melalui titik akhir pendengar grup failover.
Penanganan masalah: Hilangkan dan buat ulang grup failover setelah mengubah jenis koneksi.
Prosedur sp_send_dbmail mungkin gagal sementara saat @query parameter digunakan
Prosedur sp_send_dbmail mungkin gagal sementara ketika @query parameter digunakan. Ketika masalah ini terjadi, setiap detik eksekusi prosedur sp_send_dbmail gagal dengan kesalahan Msg 22050, Level 16, State 1 dan pesan Failed to initialize sqlcmd library with error number -2147467259. Agar dapat melihat kesalahan ini dengan benar, prosedur harus dipanggil dengan nilai default 0 untuk parameter @exclude_query_output, jika tidak, kesalahan tidak disebarluaskan.
Masalah ini tidak disebabkan oleh bug yang diketahui terkait dengan seberapa sp_send_dbmail menggunakan peniruan dan kumpulan koneksi.
Untuk mengatasi masalah ini, gabungkan kode untuk mengirim email ke logika retry yang bergantung pada parameter output @mailitem_id. Jika eksekusi gagal, maka nilai parameter adalah NULL, menunjukkan sp_send_dbmail harus dipanggil sekali lagi agar berhasil mengirim email. Berikut adalah contoh logika coba lagi ini:
CREATE PROCEDURE send_dbmail_with_retry AS
BEGIN
DECLARE @miid INT
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
@mailitem_id = @miid OUTPUT
-- If sp_send_dbmail returned NULL @mailidem_id then retry sending email.
--
IF (@miid is NULL)
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
END
Transaksi terdistribusi dapat dieksekusi setelah menghapus instans terkelola 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 dari Grup Kepercayaan Server atau menghapus grup, Anda mungkin masih dapat mengeksekusi transaksi terdistribusi. Ada solusi yang dapat Anda terapkan untuk memastikan bahwa transaksi terdistribusi dinonaktifkan dan itu adalah failover manual yang dimulai pengguna pada instans terkelola.
Transaksi terdistribusi tidak dapat dijalankan setelah operasi penskalakan instans terkelola
Operasi penskalaan SQL Managed Instance yang mencakup perubahan tingkat layanan atau jumlah vCore akan mengatur ulang pengaturan Grup Kepercayaan Server di backend dan menonaktifkan transaksi terdistribusi yang berjalan. Sebagai solusi sementara, hapus dan buat Server Trust Group baru di portal Azure.
Tidak dapat membuat SQL Managed Instance dengan nama yang sama dengan server logis yang sebelumnya dihapus
Data DNS <name>.database.windows.com dibuat saat Anda membuat server logis di Azure untuk Azure SQL Database, dan saat membuat SQL Managed Instance. Data DNS harus unik. Dengan demikian, jika Anda membuat server logis untuk SQL Database lalu menghapusnya, ada periode ambang tujuh hari sebelum nama dirilis dari rekaman. Dalam periode tersebut, SQL Managed Instance tidak dapat dibuat 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, mungkin 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. Ini mungkin dialami 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 pelanggan pada Azure SQL Managed Instance baru mungkin 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 telah mengalami masalah ini setelah perintah pembaruan, buka halaman Gambaran Umum instans terkelola SQL Anda di portal Azure. Di bawah Pengaturan, pilih ID Microsoft Entra untuk mengakses halaman admin ID Microsoft Entra SQL Managed Instance. Verifikasi apakah Anda dapat melihat pesan kesalahan "Instans Terkelola memerlukan Perwakilan Layanan untuk mengakses ID Microsoft Entra. Klik di sini untuk membuat Service Principal". Jika Anda mengalami pesan kesalahan ini, pilih pesan kesalahan, dan ikuti instruksi langkah demi langkah yang disediakan hingga kesalahan ini diselesaikan.
Batasan failover manual melalui portal untuk grup failover
Jika grup failover mencakup seluruh instans di langganan Azure atau grup sumber daya yang berbeda, failover manual tidak dapat dimulai dari instans utama dalam grup failover.
Penanganan masalah: Memulai failover melalui portal dari instans geo-sekunder.
Peran Agen SQL memerlukan izin EXECUTE eksplisit untuk login non-sysadmin
Jika login non-sysadmin ditambahkan ke peran database tetap Agen SQL, ada masalah di mana izin EXECUTE eksplisit perlu diberikan ke tiga prosedur tersimpan dalam master database agar login ini berfungsi. Jika masalah ini ditemui, pesan The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) kesalahan akan ditampilkan.
Solusi sementara: Setelah Anda menambahkan login ke peran database tetap Agen SQL (SQLAgentUserRole, SQLAgentReaderRole, atau SQLAgentOperatorRole), untuk setiap login yang ditambahkan ke peran ini, jalankan skrip T-SQL berikut untuk secara eksplisit memberikan izin EXECUTE ke prosedur tersimpan yang tercantum.
USE [master];
GO
CREATE USER [login_name] FOR LOGIN [login_name];
GO
GRANT EXECUTE ON master.dbo.xp_sqlagent_enum_jobs TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_is_starting TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_notify TO [login_name];
Batas memori OLTP dalam memori tidak diterapkan
Tingkat layanan Business Critical tidak menerapkan batas memori maks dengan benar untuk objek yang dioptimalkan memori dalam beberapa kasus. SQL Managed Instance mungkin memungkinkan beban kerja menggunakan lebih banyak memori untuk operasi OLTP dalam memori, yang dapat memengaruhi ketersediaan dan stabilitas instans. Kueri OLTP in-memory yang mencapai batas mungkin tidak segera gagal. Kueri yang menggunakan lebih banyak memori OLTP dalam memori gagal lebih cepat jika mencapai batas.
Solusi sementara: Pantau penggunaan penyimpanan OLTP dalam memori menggunakan SQL Server Management Studio untuk memastikan bahwa beban kerja tidak menggunakan lebih dari memori yang tersedia. Tingkatkan batas memori yang bergantung pada jumlah vCores, atau optimalkan beban kerja Anda untuk menggunakan lebih sedikit memori.
Kesalahan salah ditampilkan saat 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 menggunakan ALTER DATABASE REMOVE FILE pernyataan, kesalahan Msg 5042 – The file '<file_name>' cannot be removed because it is not empty tidak segera dikembalikan. SQL Managed Instance akan terus mencoba menghapus file, dan operasi akan gagal setelah 30 menit dengan Internal server error.
Mengubah tingkat layanan dan membuat operasi instans diblokir oleh pemulihan database yang sedang berlangsung
Pernyataan yang sedang RESTORE berlangsung, proses migrasi Layanan Migrasi Data, dan pemulihan titik waktu bawaan, akan memblokir pembaruan tingkat layanan atau mengubah ukuran instans yang ada dan membuat instans baru hingga proses pemulihan selesai.
Proses pemulihan memblokir operasi ini pada instans terkelola dan kumpulan instans di subnet yang sama tempat proses pemulihan berjalan. Instans dalam kumpulan instans tidak terpengaruh. Membuat atau mengubah operasi tingkat layanan tidak gagal atau waktu habis. Mereka melanjutkan 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 tingkat layanan Business Critical mungkin perlu dikonfigurasi 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 dimulai pengguna (misalnya, perubahan max vCore atau ukuran penyimpanan instans maks).
Penanganan masalah: Jalankan ALTER RESOURCE GOVERNOR RECONFIGURE secara berkala atau sebagai bagian dari pekerjaan Agen SQL yang menjalankan tugas SQL saat instans dimulai jika Anda menggunakan Resource Governor.
Dialog Service Broker lintas database harus diinisialisasi ulang setelah pemutakhiran tingkat layanan
Dialog Broker Layanan lintas database akan 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 diubah untuk semua database. Apa pun DIALOG yang dibuat menggunakan pernyataan BEGIN DIALOG yang mereferensikan Service Broker di database lain berhenti mengirimkan pesan ke layanan target.
Penanganan masalah: Hentikan aktivitas apa pun yang menggunakan percakapan dialog Broker Layanan lintas database sebelum memperbarui tingkat layanan, dan menginvestasikannya kembali sesudahnya. Jika ada pesan yang tersisa yang tidak terkirim setelah perubahan tingkat layanan, baca pesan dari antrean sumber dan mengirimnya kembali ke antrean target.
Melebihi ruang penyimpanan dengan file database kecil
CREATE DATABASE, ALTER DATABASE ADD FILE, dan RESTORE DATABASE pernyataan mungkin gagal karena instans dapat mencapai batas Penyimpanan Azure.
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. Ruang yang tidak digunakan pada disk tidak dikenakan biaya, tetapi jumlah total ukuran Disk Azure Premium tidak boleh melebihi 35 TB. Dalam beberapa kasus, instans terkelola 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 keadaan tertentu, karena distribusi file tertentu, instans SQL Managed Instance mungkin mencapai batas 35 TB yang dicadangkan untuk Disk Premium Azure terlampir, ketika Anda mungkin tidak mengharapkannya.
Dalam contoh ini, database yang ada terus berfungsi dan dapat tumbuh tanpa masalah selama file baru tidak ditambahkan. Database baru tidak dapat dibuat atau dipulihkan karena ruang tidak cukup untuk drive disk baru, bahkan jika ukuran total semua database tidak mencapai batas ukuran instans. Kesalahan yang dikembalikan dalam kasus itu 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 menyelesaikan 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.
Cakupan transaksi pada dua database dalam instans yang sama tidak didukung
(Terselesaikan pada Maret 2020) Kelas TransactionScope di .NET tidak berfungsi jika dua kueri dikirim ke dua database dalam instans yang sama di bawah lingkup transaksi yang sama:
using (var scope = new TransactionScope())
{
using (var conn1 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=mypassword;Encrypt=true"))
{
conn1.Open();
SqlCommand cmd1 = conn1.CreateCommand();
cmd1.CommandText = string.Format("insert into T1 values(1)");
cmd1.ExecuteNonQuery();
}
using (var conn2 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=mypassword;Encrypt=true"))
{
conn2.Open();
var cmd2 = conn2.CreateCommand();
cmd2.CommandText = string.Format("insert into b.dbo.T2 values(2)"); cmd2.ExecuteNonQuery();
}
scope.Complete();
}
Penanganan masalah (tidak diperlukan sejak Maret 2020): Gunakan SqlConnection.ChangeDatabase(String) untuk menggunakan database lain dalam konteks koneksi alih-alih menggunakan dua koneksi.
Tidak ada resolusi
Cadangan diferensial tidak diambil saat instans ditautkan ke SQL Server
Saat Anda mengonfigurasi tautan antara SQL Server dan Azure SQL Managed Instance, pencadangan log transaksi dan penuh otomatis diambil pada instans terkelola, baik dalam peran utama maupun tidak. Namun, cadangan diferensial saat ini tidak diambil, kapan dapat menyebabkan waktu pemulihan yang 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. Login ini dapat ditemukan di SSMS (di Object explorer, di bawah Keamanan, Masuk) atau dalam tampilan sys.sysloginssistem . Format nama masuk terlihat seperti 'DBxCy\WF-abcde01234QWERT', dan login memiliki peran server publik. Dalam kondisi tertentu, login ini dibuat ulang, dan karena kesalahan dalam sistem login sebelumnya tidak dihapus. Hal ini dapat menyebabkan peningkatan jumlah login. Login ini tidak mewakili ancaman keamanan. Mereka dapat diabaikan dengan aman. Login ini tidak boleh dihapus karena setidaknya salah satunya digunakan untuk replikasi transaksional.
Masuk dan 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 identitas menggunakan EXECUTE AS USER atau EXECUTE AS LOGIN perwakilan Microsoft Entra berikut ini tidak didukung:
- Pengguna Microsoft Entra alias. Kesalahan berikut dikembalikan dalam kasus ini:
15517. - Masuk dan pengguna Microsoft Entra berdasarkan aplikasi Microsoft Entra atau perwakilan layanan. Kesalahan berikut dikembalikan dalam kasus ini:
15517dan15406.
Replikasi transaksional harus dikonfigurasi ulang setelah geo-failover
Jika replikasi transaksional diaktifkan 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.
tempdb struktur dan konten dibuat ulang
Database tempdb selalu dibagi menjadi 12 file data, dan struktur file tidak dapat diubah. Ukuran maksimum per file tidak dapat diubah, dan file baru tidak dapat ditambahkan ke tempdb. Database tempdb selalu dibuat ulang sebagai database kosong saat instans dimulai atau gagal, dan perubahan apa pun yang dilakukan tempdb tidak dipertahankan.
Log kesalahan tidak dipertahankan
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. Mungkin ada celah dalam riwayat log kesalahan karena SQL Managed Instance dipindahkan beberapa kali pada beberapa mesin virtual.
Tidak dapat diakses instans sementara menggunakan pendengar grup failover selama operasi penskalaan
Menskalakan instans terkelola terkadang memerlukan pemindahan instans ke kluster virtual yang berbeda, bersama dengan catatan DNS terkait yang dikelola layanan. Jika instans terkelola berpartisipasi dalam grup failover, rekaman DNS yang sesuai dengan pendengar grup failover terkait (listener baca-tulis, jika instans adalah pendengar baca-saja geo-primer saat ini, jika instans 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 instans terkelola itu sendiri sepenuhnya dimigrasikan ke kluster virtual baru, yang dalam beberapa situasi dapat menyebabkan waktu yang lama di mana alamat IP instans tidak dapat diselesaikan menggunakan pendengar. Selama waktu ini, klien SQL yang mencoba mengakses instans yang diskalakan menggunakan titik akhir pendengar dapat mengharapkan kegagalan masuk dengan pesan kesalahan berikut: "Kesalahan 40532: Tidak dapat membuka server "xxx.xxx.xxx.xxx" yang diminta oleh login. Gagal masuk. (Microsoft SQL Server, Kesalahan: 40532)".
Masalah ini akan diatasi melalui desain ulang operasi penskalakan.
Diselesaikan
Tabel untuk pencadangan manual di msdb tidak mempertahankan nama pengguna
(Diselesaikan pada Agustus 2023) Kami baru-baru ini memperkenalkan dukungan untuk pencadangan otomatis di msdb, tetapi tabel saat ini tidak berisi informasi nama pengguna.
Kueri pada tabel eksternal gagal dengan pesan kesalahan yang tidak didukung
Mengkueri tabel eksternal mungkin gagal dengan pesan kesalahan umum "Kueri atas tabel eksternal tidak didukung dengan tingkat layanan saat ini atau tingkat performa database ini. Pertimbangkan untuk meningkatkan tingkat layanan atau tingkat performa database". Satu-satunya jenis tabel eksternal yang didukung di Azure SQL Managed Instance adalah tabel eksternal PolyBase (dalam pratinjau). Untuk mengizinkan kueri pada tabel eksternal PolyBase, Anda perlu mengaktifkan PolyBase pada instans terkelola dengan menjalankan sp_configure perintah.
Tabel eksternal yang terkait dengan fitur Kueri Elastis Azure SQL Database tidak didukung di SQL Managed Instance, tetapi membuat dan mengkuerinya tidak diblokir secara eksplisit. Dengan dukungan untuk tabel eksternal PolyBase, pemeriksaan baru telah diperkenalkan, memblokir kueri dari semua jenis tabel eksternal dalam instans terkelola kecuali PolyBase diaktifkan.
Jika Anda menggunakan tabel eksternal Kueri Elastis yang tidak didukung untuk kueri data dalam Azure SQL Database atau Azure Synapse dari instans terkelola, Anda harus menggunakan fitur Linked Server sebagai gantinya. Untuk membuat koneksi Server Tertaut dari SQL Managed Instance ke SQL Database, ikuti instruksi dari artikel ini. Untuk membuat koneksi Linked Server dari SQL Managed Instance ke SQL Synapse, periksa petunjuk langkah demi langkah. Karena mengonfigurasi dan menguji koneksi Linked Server membutuhkan waktu, Anda dapat menggunakan penanganan masalah sebagai solusi sementara untuk mengaktifkan kueri tabel eksternal yang terkait dengan fitur Kueri Elastic:
Solusi sementara: Jalankan perintah berikut (sekali per instans) yang mengaktifkan kueri pada tabel eksternal:
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
Saat 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.
Pulihkan pencadangan manual tanpa CHECKSUM mungkin gagal
(Diselesaikan pada Juni 2020) Dalam keadaan tertentu pencadangan manual database yang dibuat pada instans terkelola tanpa CHECKSUM mungkin gagal dipulihkan. Dalam kasus seperti itu, coba sekali lagi memulihkan backup sampai Anda berhasil.
Penanganan masalah: Ambil backup dari database pada instans terkelola dengan CHECKSUM diaktifkan.
Agen menjadi tidak responsif saat memodifikasi, menonaktifkan, atau mengaktifkan pekerjaan yang ada
Dalam keadaan tertentu, memodifikasi, menonaktifkan, atau mengaktifkan pekerjaan yang ada dapat menyebabkan agen menjadi tidak responsif. Masalah ini secara otomatis dimitigasi setelah deteksi, menghasilkan restart proses agen.
Izin pada grup sumber daya yang tidak diterapkan ke SQL Managed Instance
Saat peran SQL Managed Instance Contributor Azure diterapkan ke grup sumber daya (RG), peran tersebut tidak diterapkan ke SQL Managed Instance dan tidak berpengaruh.
Penanganan masalah: Menyiapkan peran Kontributor SQL Managed Instance untuk pengguna di tingkat langganan.
Pekerjaan Agen SQL dapat terganggu oleh restart proses Agen
(Terselesaikan pada Maret 2020) Agen SQL membuat sesi baru setiap kali pekerjaan dimulai, secara bertahap meningkatkan konsumsi memori. Untuk menghindari mencapai batas memori internal, yang akan memblokir eksekusi pekerjaan terjadwal, proses Agen dimulai ulang setelah konsumsi memorinya mencapai ambang batas. Ini dapat mengakibatkan terganggunya eksekusi pekerjaan yang berjalan pada saat mulai ulang.
Parameter @query tidak didukung dalam sp_send_db_mail
Parameter @query dalam sp_send_db_mail tidak berfungsi.
Pesan kesalahan yang menyesatkan di portal Microsoft Azure yang menyarankan pembuatan ulang Service Principal
Halaman admin Direktori Aktif portal Azure untuk Azure SQL Managed Instance mungkin menampilkan pesan kesalahan berikut, meskipun Perwakilan Layanan sudah ada:
"Instans Terkelola memerlukan Perwakilan Layanan untuk mengakses ID Microsoft Entra (sebelumnya Azure Active Directory). Klik di sini untuk membuat Service Principal"
Anda dapat mengabaikan pesan kesalahan ini jika Perwakilan Layanan untuk instans terkelola sudah ada, dan/atau autentikasi Microsoft Entra pada instans terkelola berfungsi.
Untuk memeriksa apakah Perwakilan Layanan ada, navigasikan ke halaman Aplikasi perusahaan di portal Azure, pilih Identitas Terkelola dari daftar dropdown Jenis aplikasi, pilih Terapkan, dan ketik nama instans terkelola 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 tautan dari pesan kesalahan, Perwakilan Layanan instans terkelola 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. Hal ini dapat dilakukan melalui Azure PowerShell dengan mengikuti petunjuk berikut.
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.