Azure SQL 受控執行個體的已知問題
適用於：
Azure SQL 受控執行個體
本文列出 Azure SQL 受控執行個體目前的已知問題，及其解決日期或可能的因應措施。 如需了解 Azure SQL 受控執行個體的詳細資訊，請參閱什麼是 Azure SQL 受控執行個體，以及 Azure SQL 受控執行個體 的新增功能？
注意
Microsoft Entra ID 先前稱為 Azure Active Directory (Azure AD)。
已知問題
有因應措施
Azure 入口網站 中的長期備份清單會顯示使用中和已刪除資料庫的備份檔具有相同名稱
您可以針對備份索引標籤上的 Azure SQL 受控執行個體，在 Azure 入口網站頁面上列出並管理長期備份。頁面會列出作用中或已刪除的資料庫、其長期備份的基本資訊，以及管理備份的連結。 當您選取 [管理] 連結時，新的側邊窗格隨即開啟，其中包含備份清單。 由於篩選邏輯發生問題，清單會顯示作用中資料庫和已刪除資料庫具有相同名稱的備份。 選取要刪除的備份時，這需要特別注意，以避免刪除錯誤的資料庫備份。
因應措施：使用清單中顯示的備份 tim (UTC) 資訊，區分屬於不同期間執行個體上相同名稱的資料庫備份。 或者，使用 PowerShell 命令 Get-AzSqlInstanceDatabaseLongTermRetentionBackup 和 Remove-AzSqlInstanceDatabaseLongTermRetentionBackup，或 CLI 命令 az sql midb ltr-backup list 和 az sql midb ltr-backup delete，使用 DatabaseState 參數和 DatabaseDeletionTime 傳回值來管理長期備份，以篩選資料庫的備份。
無法存取 system_health 事件工作階段的 event_file 目標
當您嘗試讀取 system_health 事件工作階段的 event_file 目標的內容時，您會收到錯誤 40538：「以 'https://' 為開頭的有效 URL 需要做為指定的任何檔案路徑的值」。這種情況發生在 SQL Server Management Studio 中，或使用 sys.fn_xe_file_target_read_file 函式讀取工作階段資料時。
此行為變更是最近的必要安全性修正的意外後果。 我們正在調查其他變更的可行性，讓客戶能夠繼續安全地使用 Azure SQL 受控執行個體上的 system_health 工作階段。 同時，客戶可藉由在 Azure Blob 儲存體中建立自己的具有 event_file 目標的對等 system_health 工作階段，來解決此問題。 如需詳細資訊，包括用於建立 system_health 工作階段的 T-SQL 指令碼，且可修改該工作階段來建立您自己的對等 system_health 工作階段，請參閱使用 system_health 工作階段。
使用 @query 參數時，程序 sp_send_dbmail 可能會失敗
使用 @query 參數時，程序 sp_send_dbmail 可能會失敗。 在系統管理員帳戶下執行預存程序時，就會發生失敗。
此問題是由於已知錯誤引起，且此錯誤與 sp_send_dbmail 使用模擬有關。
因應措施：確定在您已建立的適當自訂帳戶下呼叫 sp_send_dbmail，而不是在系統管理員帳戶下。
以下範例說明如何建立專用帳戶，並修改透過 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
智利 2022 年時區更新的過渡期指引
智利政府於 2022 年 8 月 8 日正式公告日光節約時間 (DST) 的時區變更。 從 2022 年 9 月 10 日週六上午 12:00 開始，到 2023 年 4 月 1 日週六上午 12:00 為止，官方時間將會提前 60 分鐘。 這項變更會影響下列三個時區：「太平洋 SA 標準時間」、「復活節島標準時間」和「麥哲倫標準時間」。 除非 Microsoft 發行作業系統更新以支援這些變更，而且 Azure SQL 受控執行個體服務在作業系統層級上吸收更新，否則使用受影響時區的 Azure SQL 受控執行個體不會反映這些變更。
因應措施：如果您需要改變受控執行個體的受影響時區，注意限制並遵循文件中的指導。
變更連線類型並不會影響透過容錯移轉群組端點的連線
如果執行個體參與容錯移轉群組，則變更執行個體的連線類型不會影響透過容錯移轉群組接聽程式端點建立的連線。
因應措施：變更連線類型後，卸除並重新建立容錯移轉群組。
使用 @query 參數時，程序 sp_send_dbmail 可能會暫時失敗
使用 @query 參數時，程序 sp_send_dbmail 可能會暫時失敗。 發生此問題時，每秒執行的 sp_send_dbmail 程序會失敗並顯示錯誤 Msg 22050, Level 16, State 1 和訊息 Failed to initialize sqlcmd library with error number -2147467259。 若要能正確查看此錯誤，呼叫程序時，參數 @exclude_query_output 的預設值應為 0，否則此錯誤不會傳播。
此問題是由於已知錯誤引起，此錯誤與 sp_send_dbmail 使用模擬與連線共用有關。
如要解決此問題，請在電子郵件中包含程式碼封裝，並傳送到依賴輸出參數 @mailitem_id 的重試邏輯。 如果執行失敗，則參數值會是 Null，表示應再次呼叫 sp_send_dbmail，以成功傳送電子郵件。 以下是此重試邏輯的範例︰
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
從伺服器信任群組移除受控執行個體後，可執行分散式交易
伺服器信任群組用於在分散式交易必要條件的受控執行個體間建立信任關係。 從伺服器信任群組中移除受控執行個體，或刪除該群組後，您仍可執行分散式交易。 您可以套用以確定停用分散式交易的因應措施是，在受控執行個體上執行使用者起始手動容錯移轉。
受控執行個體進行調整作業後，無法執行分散式交易
SQL 受控執行個體的調整作業 (包含變更服務層級或虛擬核心數量) 將重設後端的服務信任群組設定，並停用執行中的分散式交易。 因應措施為在 Azure 入口網站上刪除並建立新的服務信任群組。
無法使用與先前刪除的邏輯伺服器相同的名稱，建立 SQL 受控執行個體
當您於 Azure 建立 Azure SQL Database 的邏輯伺服器，以及建立 SQL 受控執行個體時，即會建立 <name>.database.windows.com 的 DNS 記錄。 DNS 記錄名稱必須唯一。 如此一來，如果您建立 SQL Database 的邏輯伺服器，然後將其刪除，則需要七天的閾值期間，七天後記錄才會釋放此名稱。 在該段期間，您無法使用與已刪除邏輯伺服器相同的名稱，建立 SQL 受控執行個體。 因應措施是針對 SQL 受控執行個體使用不同的名稱，或建立支援票證以釋放此邏輯伺服器名稱。
服務主體無法存取 Microsoft Entra ID 和 AKV
在某些情況下，用於存取 Microsoft Entra ID (先前稱為 Azure Active Directory) 和 Azure Key Vault (AKV) 服務的服務主體可能存在問題。 因此，此問題會影響透過 SQL 受控執行個體使用 Microsoft Entra 驗證和透明資料加密 (TDE) 的使用情況。 這可能由於間歇性的連線問題，或是無法執行或如 CREATE LOGIN/USER FROM EXTERNAL PROVIDER 或 EXECUTE AS LOGIN/USER 等陳述式。 在新的 Azure SQL 受控執行個體上使用客戶管理的金鑰來設定 TDE，在某些情況下可能也無法運作。
因應措施：若要避免在執行任何更新命令前，您的 SQL 受控執行個體發生此問題，或在執行更新命令之後遇到此問題，請移至 Azure 入口網站中 SQL 受控執行個體的 [概觀] 頁面。 在 [設定] 底下，選取 "Microsoft Entra ID" 來存取 SQL 受控執行個體 [Microsoft Entra ID 管理員] 頁面。 確認您是否可以看到錯誤訊息「受控執行個體需要服務主體才能存取 Microsoft Entra ID。 請按一下此處以建立服務主體」。 如果您遇到此錯誤訊息，請選取該訊息，並依照提供的逐步指示進行，直到解決此錯誤為止。
透過入口網站針對容錯移轉群組進行手動容錯移轉的限制
如果容錯移轉群組跨越不同 Azure 訂用帳戶或資源群組中的執行個體，則無法從容錯移轉群組中的主要執行個體起始手動容錯移轉。
因應措施：透過入口網站，從異地複寫次要執行個體起始容錯移轉。
SQL Agent 角色需要非系統管理員 (sysadmin) 登入的明確 EXECUTE 許可權
如果將非系統管理員的登入新增至任何 SQL Agent 固定資料庫角色，則存在一個問題，即必須將明確的 EXECUTE 權限授與 master 資料庫中的三個預存程序，這些登入才可正常運作。 如果遇到此問題，則會顯示以下錯誤訊息：The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229)。
因應措施：您將登入新增至 SQL Agent 固定資料庫角色後 (SQL SQLAgentUserRole、SQLAgentReaderRole 或 SQLAgentOperatorRole)，針對新增至這些角色的每個登入，會執行下列 T-SQL 指令碼，以明確地將 EXECUTE 權限授與所列的預存程序。
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];
記憶體內部 OLTP 記憶體限制不適用
在某些情況下，業務關鍵服務層級無法針對記憶體最佳化物件正確套用記憶體限制上限。 SQL 受控執行個體可讓工作負載針對記憶體內部 OLTP 作業使用更多記憶體，這可能會影響執行個體的可用性和穩定性。 觸達限制的記憶體內部 OLTP 查詢可能不會立即失敗。 如果使用更多記憶體內部 OLTP 記憶體的查詢觸達限制，則查詢會很快失敗。
因應措施：使用 SQL Server Management Studio 來監視記憶體內部 OLTP 儲存體使用量，以確保工作負載不會使用超過可用記憶體。 增加相依於虛擬核心數目的記憶體限制，或最佳化您的工作負載以使用較少的記憶體。
嘗試移除非空白檔案時傳回錯誤的錯誤
SQL Server 和 SQL 受控執行個體不允許使用者卸除非空白檔案。 如果您嘗試使用 ALTER DATABASE REMOVE FILE 陳述式移除非空白的資料檔案，則不會立即傳回錯誤 Msg 5042 – The file '<file_name>' cannot be removed because it is not empty。 SQL 受控執行個體會繼續嘗試卸除檔案，而且作業將會因為 Internal server error 在 30 分鐘之後失敗。
進行中的資料庫還原會封鎖變更服務層級和建立執行個體作業
進行中的 RESTORE 陳述式、資料移轉服務移轉程序和內建的時間點還原，將會封鎖更新服務層級或重新調整現有執行個體的大小，並建立新的執行個體，直到還原程序完成為止。
還原程序會在還原程序執行所在的相同子網路中，封鎖受控執行個體和執行個體集區上的這些作業。 執行個體集區中的執行個體不受影響。 建立或變更服務層級作業不會失敗或逾時，一旦完成或取消還原程序，就會繼續進行。
因應措施：等到還原程序完成，或如果建立或更新服務層級作業的優先順序較高，則取消還原程序。
容錯移轉之後，可能需要重新設定業務關鍵服務層級的 Resource Governor
Resource Governor 功能 (可讓您限制指派給使用者工作負載的資源) 可能會在容錯移轉或使用者起始的服務層級變更 (例如，變更虛擬核心上限或執行個體儲存體大小上限) 之後，不正確地分類某些使用者工作負載。
因應措施：如果您使用 Resource Governor，請在執行個體啟動時，定期 (或作為執行 SQL 工作的 SQL Agent 作業一部分) 執行 ALTER RESOURCE GOVERNOR RECONFIGURE。
服務層級升級之後，必須重新初始化跨資料庫 Service Broker 對話
跨資料庫 Service Broker 對話會在變更服務層級作業之後，停止將訊息傳遞至其他資料庫中的服務。 訊息不會遺失，且可以在傳送者佇列中找到。 SQL 受控執行個體中的任何虛擬核心或執行個體儲存大小變更，會導致所有資料庫的 sys.databases 檢視中的 service_broke_guid 值變更。 使用 BEGIN DIALOG 陳述式 (參考其他資料庫中的 Service Broker) 所建立的任何 DIALOG 會停止將訊息傳遞至目標服務。
因應措施：在更新服務層級之前，請停止任何使用跨資料庫 Service Broker 對話交談的活動，然後再將其重新初始化。 如果有剩餘的訊息在服務層級變更後無法傳遞，請從來源佇列讀取訊息，然後將其重新傳送至目標佇列。
小型資料庫檔案造成儲存空間超出限制
CREATE DATABASE、ALTER DATABASE ADD FILE 和 RESTORE DATABASE 陳述式可能會失敗，因為執行個體可以觸達 Azure 儲存體的限制。
每個 SQL 受控執行個體的一般用途執行個體最多可保留 35 TB 的儲存體，以供 Azure 進階磁碟空間使用。 每個資料庫檔案都會放在個別的實體磁碟上。 磁碟大小可以是 128 GB、256 GB、512 GB、1 TB 或 4 TB。 針對磁碟上未使用的空間，並不收費，但「Azure 進階磁碟」大小的總和不可超過 35 TB。 在某些情況下，總計不需 8 TB 的受控執行個體可能會因內部分散的緣故而超過 35 TB 的 Azure 儲存體大小限制。
例如，SQL 受控執行個體的一般用途受控執行個體可能將一個大小為 1.2 TB 的大型檔案放在一個 4 TB 的磁碟上。 其也可能有 248 個 1 GB 的檔案放置在單獨的 128 GB 磁碟上。 在此範例中：
- 配置的磁碟儲存體大小總計為 1 x 4 TB + 248 x 128 GB = 35 TB。
- 為執行個體上的資料庫保留的大小總計為 1 x 1.2 TB + 248 x 1 GB = 1.4 TB。
此範例說明了在特定情況下，由於特定的檔案散發方式，SQL 受控執行個體的執行個體可能在您未預期的情形下，達到為所連結「Azure 進階磁碟」保留的 35 TB 限制。
在此範例中，現有資料庫會繼續運作，只要不新增檔案，就可正常成長而不會有任何問題。 因為沒有足夠空間可供新的磁碟機使用，所以無法建立或還原新的資料庫，即使所有資料庫的大小總計未達到執行個體大小限制也是如此。 在該情況下所傳回的錯誤並不清楚。
您可以使用系統檢視來識別剩餘的檔案數目 \(英文\)。 如果您觸達此限制，請嘗試使用 DBCC SHRINKFILE 陳述式清空並刪除部分較小的檔案，或切換至業務關鍵服務層級，此層級無此限制。
顯示 GUID 值，而不是資料庫名稱
數個系統檢視、效能計數器、錯誤訊息、XEvents 與錯誤記錄檔項目都會顯示 GUID 資料庫識別碼，而非實際資料庫名稱。 不要依賴這些 GUID 識別碼，因為其未來可能會被實際資料庫名稱取代。
因應措施：使用 sys.databases 檢視來解析實體資料庫名稱中的實際資料庫名稱 (以 GUID 資料庫識別碼的形式指定)：
SELECT name AS ActualDatabaseName,
physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;
CLR 模組與連結的伺服器有時候無法參考本機 IP 位址
SQL 受控執行個體中的 CLR 模組與參考目前執行個體的連結伺服器或分散式查詢，有時無法解析本機執行個體的 IP。 此錯誤為暫時性問題。
不支援相同執行個體內兩個資料庫上的異動範圍
(2020 年 3 月已解決) 若兩個查詢被傳送到相同異動範圍內相同執行個體內的兩個資料庫，.NET 中的 TransactionScope 類別將無法運作：
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();
}
因應措施 (自 2020 年 3 月起不再需要)：使用 SqlConnection.ChangeDatabase(String) 在連線內容中使用其他資料庫，而非使用兩個連線。
沒有解決方法
當執行個體連結至 SQL Server 時，不會進行差異備份
當您設定 SQL Server 與 Azure SQL 受控執行個體之間的連結時，不論其是否在主要角色中，將在受控執行個體上進行自動完整備份和交易記錄備份。 但是，目前未進行差異備份，否則可能會導致還原時間比預期更長。
用於異動複寫的系統登入數目增加
Azure SQL 受控執行個體服務為異動複寫的目的而建立系統登入。 您可以在 SSMS (在 物件總管 中 安全性 的 登入 區段中) 或系統檢視表 sys.syslogins 中找到此登入 。 登入名稱格式看起來像 'DBxCy\WF-abcde01234QWERT'，而且登入具有 public 伺服器角色。 在某些情況下，此登入會重新建立，而由於系統中的錯誤，先前的登入未被刪除。 這可能會導致登入數目增加。 這些登入不代表安全性威脅。 您可以安心略過。 您不應該刪除這些登入，因為其中至少有一個登入正用於異動複寫。
SSDT 中不支援 Microsoft Entra 登入和使用者
SQL Server Data Tools 無法完整支援 Microsoft Entra 登入和使用者。
不支援模擬 Microsoft Entra 登入類型
不支援使用下列 Microsoft Entra 主體的 EXECUTE AS USER 或 EXECUTE AS LOGIN 進行模擬：
- 別名化的 Microsoft Entra 使用者。 在此情況下，系統會傳回下列錯誤：
15517。 - Microsoft Entra 登入和以 Microsoft Entra 應用程式或服務主體為基礎的使用者。 在此情況下，系統會傳回下列錯誤：
15517和15406。
異地容錯移轉之後必須重新設定異動複寫
如果在容錯移轉群組中的資料庫上啟用異動複寫，則 SQL 受控執行個體系統管理員必須清理舊主要執行個體上的所有發行集，並在容錯移轉至另一個區域之後，在新的主要執行個體上重新加以設定。 如需詳細資訊，請參閱複寫。
重新建立 tempdb 結構和內容
tempdb 資料庫一律會分割成 12 個資料檔案，而且無法變更檔案結構。 無法變更每個檔案大小的上限，而且無法將新檔案新增至 tempdb。 當執行個體啟動或容錯移轉時，一律將 tempdb 資料庫重新建立為空白資料庫，而且不會保留在 tempdb 中進行的任何變更。
錯誤記錄檔不會保存
SQL 受控執行個體中可用的錯誤記錄檔不會保留下來，而且其大小不包括在儲存體大小上限中。 若發生容錯移轉，可能會自動清除錯誤記錄檔。 由於在多個虛擬機器上多次移動 SQL 受控執行個體，因此錯誤記錄檔歷程記錄中可能含有空白。
在調整作業期間，使用容錯移轉群組接聽程式暫時無法存取執行個體
調整受控執行個體有時需要將執行個體移至不同的虛擬叢集，以及相關聯的服務維護 DNS 記錄。 如果受控執行個體參與容錯移轉群組，則對應至其相關聯容錯移轉群組接聽程式的 DNS 記錄 (如果執行個體是目前的異地主要複本，即為讀寫接聽程式；如果執行個體是目前的異地次要執行個體，即為唯讀接聽程式)，則會移至新的虛擬叢集。
在目前的調整作業設計中，接聽程式 DNS 記錄會在受控執行個體本身完全移轉至新的虛擬叢集之前，從原始虛擬叢集中移除，在某些情況下，可能會導致長時間無法使用接聽程式解決執行個體 IP 位址問題。 在此期間，嘗試使用接聽程式端點存取正在調整執行個體的 SQL 用戶端，可能預期會失敗，並出現下列錯誤訊息：「錯誤 40532：無法開啟登入所要求的伺服器 "xxx.xxx.xxx.xxx"。 登入失敗。 (Microsoft SQL Server，錯誤：40532)」。
此問題可透過調整作業重新設計來解決。
已解決
手動備份的 msdb 資料表不會保留使用者名稱
(2023 年 8 月已解決) 我們最近在 msdb 引進了對自動備份的支援，但資料表目前未包含使用者名稱資訊。
查詢外部資料表失敗，出現不支援的錯誤訊息
查詢外部表格可能會失敗，並出現一般錯誤訊息：「此資料庫目前的服務層級或效能等級，不支援外部表格的查詢。 請考慮升級該資料庫的服務層級或效能等級。 Azure SQL 受控執行個體中唯一支援的外部資料表類型是 PolyBase 外部資料表 (處於預覽)。 若要在 PolyBase 外部表格上允許查詢，您必須執行 sp_configure 命令，來在受控執行個體上啟用 PolyBase。
SQL 受控執行個體中不支援與 Azure SQL 資料庫的彈性查詢功能相關的外部表格，但建立和查詢資料表時不會明確遭到封鎖。 利用對 PolyBase 外部資料表的支援，已推出新的檢查，除非已啟用 PolyBase，否則會封鎖查詢受控執行個體中任何類型的外部資料表。
如果您要使用不支援的彈性查詢外部資料表，從受控執行個體查詢 Azure SQL Database 或 Azure Synapse 中的資料，您應改用連結的伺服器功能。 若要建立從 SQL 受控執行個體至 SQL Database 的連結伺服器連線，請遵循本文中的指示。 若要建立從 SQL 受控執行個體至 SQL Synapse 的連結伺服器連線，請參閱此處的逐步指示。 由於設定和測試連結伺服器連線需要一些時間，您可以使用因應措施作為暫時的解決方案，來啟用查詢外部資料表時與彈性查詢相關的功能：
因應措施：執行下列命令 (每個執行個體一次) 以啟用外部表格查詢：
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
使用 SQL Server 驗證時，不支援使用 '@' 的使用者名稱
中間包含 '@' 符號的使用者名稱 (例如 'abc@xy') 無法使用 SQL Server 驗證登入。
在未啟用 CHECKSUM 的情況下還原手動備份可能會失敗
(2020 年 6 月已解決) 某些情況下，在未使用總和檢查碼的受控執行個體進行的資料庫手動備份，可能無法還原。 在這種情況下，請重試還原備份直到成功為止。
因應措施：在啟用 CHECKSUM 的受控執行個體上進行資料庫的手動備份。
代理程式在修改、停用或啟用現有作業後無回應
在某些情況下，修改、停用或啟用現有作業可能會導致代理程式無回應。 偵測到該問題會自動緩和，導致代理程式程序重新啟動。
資源群組的權限未套用至 SQL 受控執行個體
當 SQL 受控執行個體資料參與者 Azure 角色套用至資源群組 (RG) 時，此項目不會套用至 SQL 受控執行個體，且沒有作用。
因應措施：針對訂用帳戶層級的使用者，設定 SQL 受控執行個體參與者角色。
代理程式程序重新啟動可能會中斷 SQL Agent 作業
(2020 年 3 月已解決) SQL Agent 會在每次作業啟動時建立新的工作階段，而逐漸增加記憶體耗用量。 為了避免達到會封鎖執行排程工作的內部記憶體限制，代理程式程序會在其記憶體使用量觸達閾值後重新啟動。 這可能會導致在重新啟動時中斷作業的執行。
sp_send_db_mail 中不支援 @query 參數
sp_send_db_mail 程序中的 @query 參數無法使用。
Azure 入口網站上的誤導錯誤訊息，建議您重新建立服務主體
針對 Azure SQL 受控執行個體 Azure 入口網站的 Active Directory 管理員頁面，即使服務主體已存在，仍可能會顯示下列錯誤訊息：
「受控執行個體需要服務主體才能存取 Microsoft Entra ID (先前稱為 Azure Active Directory)。 請按一下此處以建立服務主體」
如果受控執行個體的服務主體已存在，且/或受控執行個體上的 Microsoft Entra 驗證可執行，您可以忽略此錯誤訊息。
若要檢查服務主體是否存在，請瀏覽至 Azure 入口網站的 [企業應用程式] 頁面，在 [應用程式類型] 下拉式清單中選擇 [受控識別]，再選取 [套用] 並在搜尋框中輸入受控執行個體的名稱。 如果結果清單中顯示執行個體名稱，表示服務主體已存在，無須採取進一步動作。
如果您已遵循錯誤訊息中的指示，並選取錯誤訊息中的連結，則會重新建立受控執行個體的服務主體。 在此情況下，將 Microsoft Entra ID 讀取權限指派給新建立的服務主體，以便 Microsoft Entra 驗證正常運作。 您可以依照下列指示，透過 Azure PowerShell 來完成此動作。
參與內容
若要參與編輯 Azure SQL 文件，請參閱 Docs 參與者指南。
相關內容
如需 SQL 受控執行個體更新和增強功能清單，請參閱 SQL 受控執行個體服務更新。
如需所有 Azure 服務的更新與改進功能，請參閱服務更新。