Bagikan melalui


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

Masalah Tanggal ditemukan Status Tanggal diselesaikan
Cadangan diferensial tidak diambil saat instans ditautkan ke SQL Server September 2024 Hasilnya
Daftar cadangan jangka panjang di portal Azure memperlihatkan file cadangan untuk database aktif dan dihapus dengan nama yang sama Rabu 2024 Solusi Sementara
Tidak dapat diakses instans sementara menggunakan pendengar grup failover selama operasi penskalaan Jan 2024 Tidak ada resolusi
Target event_file sesi peristiwa system_health tidak dapat diakses Des 2023 Solusi Sementara
Procedure sp_send_dbmail might fail when @query parameter is used on Nov22FW enabled managed instances Des 2023 Solusi Sementara
Peningkatan jumlah login sistem yang digunakan untuk replikasi transaksional Des 2022 Tidak ada resolusi
tabel msdb untuk cadangan manual tidak mempertahankan nama pengguna Nov 2022 Diselesaikan Agustus 2023
Panduan sementara tentang pembaruan zona waktu 2022 untuk Chili Ags 2022 Solusi Sementara
Kueri tabel eksternal gagal dengan pesan kesalahan 'tidak didukung' Jan 2022 Diselesaikan Sep 2022
Saat menggunakan autentikasi SQL Server, nama pengguna dengan '@' tidak didukung Okt 2021 Diselesaikan Feb 2022
Pesan kesalahan yang menyesatkan di portal Microsoft Azure yang menyarankan pembuatan ulang Service Principal Sep 2021 Okt 2021
Mengubah jenis koneksi tidak memengaruhi koneksi melalui titik akhir grup failover Jan 2021 Solusi Sementara
Procedure sp_send_dbmail might transiently fail when @query parameter is used Jan 2021 Diselesaikan Maret 2022
Transaksi terdistribusi dapat dieksekusi setelah menghapus instans terkelola dari Grup Kepercayaan Server 2020 Okt Solusi Sementara
Transaksi terdistribusi tidak dapat dijalankan setelah operasi penskalakan instans terkelola 2020 Okt Diselesaikan Mei 2021
Tidak dapat membuat SQL Managed Instance dengan nama yang sama dengan server logis yang sebelumnya dihapus Agu 2020 Solusi Sementara
Perwakilan Layanan tidak dapat mengakses ID Microsoft Entra dan AKV Agu 2020 Solusi Sementara
Memulihkan backup manual tanpa CHECKSUM bisa gagal 2020 Mei Diselesaikan 2020 Juni
Agen menjadi tidak responsif saat memodifikasi, menonaktifkan, atau mengaktifkan pekerjaan yang ada 2020 Mei Diselesaikan 2020 Juni
Izin pada grup sumber daya yang tidak diterapkan ke SQL Managed Instance 2020 Feb Diselesaikan 2020 Nov
Batasan failover manual melalui portal untuk grup failover 2020 Jan Solusi Sementara
Peran Agen SQL memerlukan izin EXECUTE eksplisit untuk login nonsysadmin 2019 Des Diselesaikan Sep 2022
Pekerjaan Agen SQL dapat terganggu oleh restart proses Agen 2019 Des Diselesaikan 2020 Mar
Masuk dan pengguna Microsoft Entra tidak didukung di SSDT 2019 Nov Tidak ada Solusi Sementara
Batas memori OLTP dalam memori tidak diterapkan 2019 Okt Solusi Sementara
Kesalahan salah ditampilkan saat mencoba menghapus file yang tidak kosong 2019 Okt Diselesaikan Agustus 2020
Mengubah tingkat layanan dan membuat operasi instans diblokir oleh pemulihan database yang sedang berlangsung 2019 Sep Solusi Sementara
Resource Governor pada tingkat layanan Kritis Bisnis mungkin perlu dikonfigurasi ulang setelah failover 2019 Sep Solusi Sementara
Dialog Service Broker lintas database harus diinisialisasi ulang setelah pemutakhiran tingkat layanan 2019 Agu Solusi Sementara
Peniruan jenis login Microsoft Entra tidak didukung 2019 Jul Tidak ada Solusi Sementara
Parameter @query tidak didukung dalam sp_send_db_mail 2019 Apr Diselesaikan Jan 2021
Replikasi transaksional harus dikonfigurasi ulang setelah geo-failover 2019 Mar Tidak ada Solusi Sementara
struktur dan konten tempdb dibuat ulang Tidak ada Solusi Sementara
Melebihi ruang penyimpanan dengan file database kecil Solusi Sementara
Nilai GUID akan ditampilkan, bukan nama database Solusi Sementara
Log kesalahan tidak dipertahankan Tidak ada Solusi Sementara
Cakupan transaksi pada dua database dalam instans yang sama tidak didukung Solusi Sementara 2020 Mar
Modul CLR dan server yang ditautkan terkadang tidak dapat mereferensikan alamat IP lokal Solusi Sementara
Konsistensi database tidak diverifikasi menggunakan DBCC CHECKDB setelah memulihkan database dari Azure Blob Storage. Diselesaikan 2019 Nov
Pemulihan database pada waktu tertentu dari tingkat Kritis Bisnis ke tingkat Tujuan Umum tidak akan berhasil jika database sumber berisi objek OLTP dalam memori. Diselesaikan 2019 Okt
Fitur email database dengan server email eksternal (non-Azure) menggunakan koneksi aman Diselesaikan 2019 Okt
Database terkandung yang tidak didukung dalam SQL Managed Instance Diselesaikan 2019 Agu

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=<password>;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=<password>;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: 15517 dan 15406.

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.