適用於：
Azure SQL 受控執行個體
本文列出 Azure SQL 受控執行個體目前的已知問題，及其解決日期或可能的因應措施。 如需了解 Azure SQL 受控執行個體的詳細資訊，請參閱什麼是 Azure SQL 受控執行個體，以及 Azure SQL 受控執行個體 的新增功能？
注意
Microsoft Entra ID 先前稱為 Azure Active Directory (Azure AD)。
已知問題
有因應措施
修改免費方案的備份保留期限
您只能使用 REST API、 PowerShell 和 Azure CLI 命令，在免費的 SQL 受控實例中修改資料庫的備份保留原則。 您無法透過 Azure 入口網站修改備份保留原則。
登入次要資料庫失敗，因為長時間等候「HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING」
當您嘗試連線到故障轉移群組的只讀次要複本，或透過受控實例連結複寫的資料庫時，您可能會看到此錯誤是 Microsoft OLE DB Driver 19 for SQL Server 驅動程式的例外狀況。
當次要複本因交易期間的資料列版本遺失而無法用於登入時，就會發生此錯誤。這種遺失可能發生在次要複本重新啟動或重新配置，或者因為故障轉移進行維護時。 當實例重新啟動或故障轉移時，儲存於 tempdb 中的版本設定數據會被清除。因此，如果在故障轉移或重新啟動之前已經開始有長時間運行中的作用中交易，則次要讀取查詢會被中止。
若要解決此問題，請復原或認可主要複本上的使用中交易。 若要避免此錯誤，請將主要復本上長時間執行的寫入交易降到最低。
巴拉圭 2024 年時區更新的中期指導方針
2024年10月14日，巴拉圭政府宣佈永久改變該國的時區政策。 巴拉圭全年實行日光節約時間，採用UTC-3作為其標準時間。 因此，時鐘不會在2025年3月23日上午12：00前提前60分鐘，如前所述。 這項變更會影響巴拉圭標準時區。 Microsoft 已在 2025 年 2 月和 3 月發行相關的 Windows 更新。 Azure SQL 受控實例目前不會反映此更新。 使用受影響時區的實例不會反映變更，直到 Azure SQL 受控實例服務吸收 OS 層級上的更新為止。
因應措施：如果您需要改變受控執行個體的受影響時區，注意限制並遵循文件中的指導。
在源自 SQL 受控實例的 SQL Server 資料庫上執行 DBCC CHECKDB 時發生錯誤 8992
在您刪除索引或包含索引的資料表，且資料庫原自 Azure SQL 受控實例（例如還原備份檔案或使用 DBCC CHECKDB）後，可能會在 SQL Server 2022 資料庫上執行 命令時，看到以下錯誤：
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.
若要解決此問題，請先從 Azure SQL 受控實例中的源資料庫卸除索引或具有索引的數據表，然後再次將資料庫還原或連結至 SQL Server 2022。 如果無法從來源 Azure SQL 受控實例重新建立資料庫，請連絡Microsoft支援人員以協助解決此問題。
謹慎
如果您卸除索引後在資料表上建立分割索引，如上述情境所述，資料表會變得無法存取。
Azure 入口網站 中的長期備份清單會顯示使用中和已刪除資料庫的備份檔具有相同名稱
您可以在 [ 備份 ] 索引標籤上的 Azure SQL 受控實例的 Azure 入口網站頁面上列出及管理長期備份。頁面會列出作用中或刪除的資料庫、其長期備份的基本資訊，以及管理備份的連結。 當您選取 [管理] 連結時，新的側邊窗格隨即開啟，其中包含備份清單。 由於篩選邏輯發生問題，清單會顯示作用中資料庫和已刪除資料庫具有相同名稱的備份。 選取要刪除的備份時，這需要特別注意，以避免刪除錯誤的資料庫備份。
因應措施：使用清單中顯示的備份時間 (UTC) 資訊，區分屬於不同期間在執行個體上相同名稱的資料庫備份。 或者，使用 PowerShell 命令 Get-AzSqlInstanceDatabaseLongTermRetentionBackup 和 Remove-AzSqlInstanceDatabaseLongTermRetentionBackup 或 CLI 命令 az sql midb ltr-backup list 和 az sql midb ltr-backupdelete ，使用 DatabaseState 參數和 DatabaseDeletionTime 傳回值來管理長期備份，以篩選資料庫的備份。
使用 @query 參數時，程序 sp_send_dbmail 可能會失敗
使用 sp_send_dbmail 參數時，程序 @query 可能會失敗。 在系統管理員帳戶下執行預存程序時，就會發生失敗。
此問題的原因是與 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
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
更改連線類型不會影響透過容錯移轉群組端點的連線
如果執行個體參與容錯移轉群組，則變更執行個體的連線類型不會影響透過容錯移轉群組接聽程式端點建立的連線。
因應措施：變更連線類型後，卸除並重新建立容錯移轉群組。
從伺服器信任群組移除 SQL 受控執行個體之後，可以執行分散式交易
伺服器信任群組用於在受控執行個體之間建立信任關係，這是執行分散式交易的必要條件。 從伺服器信任群組移除 SQL 受控執行個體或刪除群組之後，您仍然可以執行分散式交易。 您可以套用一個因應措施來確保分散式交易已停用，那就是在 SQL 受控執行個體上使用者起始的手動容錯移轉。
無法使用與先前刪除的邏輯伺服器相同的名稱，建立 SQL 受控執行個體
當您於 Azure 建立 Azure SQL Database 的<name>.database.windows.com，以及建立 SQL 受控執行個體時，即會建立 的 DNS 記錄。 DNS 記錄名稱必須唯一。 如此一來，如果您建立 SQL 資料庫的邏輯伺服器，然後將其刪除，則需要等候七天，七天後此名稱才會從記錄中釋放。 在該段期間，您無法使用與已刪除邏輯伺服器相同的名稱，建立 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 管理員] 頁面。 確認您是否可以看到錯誤訊息：
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal。
如果您遇到此錯誤訊息，請選取該訊息，並依照提供的逐步指示進行，直到解決此錯誤為止。
嘗試刪除非空檔案時回報不正確的錯誤
SQL Server 和 SQL 受控執行個體不允許使用者刪除非空的檔案。 如果您嘗試使用 ALTER DATABASE REMOVE FILE 語句移除非空的資料檔案，則不會立即傳回錯誤 Msg 5042 – The file '<file_name>' cannot be removed because it is not empty。 SQL 受控執行個體會不斷嘗試刪除檔案，而該作業將於 30 分鐘後因 Internal server error 而失敗。
因為正在進行的資料庫還原，變更服務層級和建立執行個體的作業被封鎖。
進行中的 RESTORE 語句、數據遷移服務移轉程式，以及內建的時間點還原功能會封鎖更新服務層級或調整現有實例的大小且無法建立新的實例，直到還原程式完成為止。
還原程序會在還原程序執行所在的相同子網路中，封鎖受控執行個體和執行個體集區上的這些作業。 執行個體集區中的執行個體不受影響。 建立或變更服務層級的作業不會失敗或逾時，它們會在還原程序完成或被取消後繼續進行。
因應措施：等到還原程序完成，或如果建立或更新服務層級作業的優先順序較高，則取消還原程序。
必須在容錯移轉後重新配置可讀次要副本上的資源管理器
可讓您限制指派給使用者工作負載的資源 管理員功能， 可能會在容錯移轉或使用者起始的服務層級變更 （例如，變更最大虛擬核心或最大執行個體儲存體大小） 之後，錯誤地分類某些使用者工作負載。
因應措施：如果您使用ALTER RESOURCE GOVERNOR RECONFIGURE，請定期執行，或作為 SQL 代理程式作業的一部分執行，以在可讀取次要複本啟動時執行 SQL 工作。
服務層級升級之後，必須重新初始化跨資料庫 Service Broker 對話
變更服務層級作業之後，跨資料庫 Service Broker 對話方塊會停止將訊息傳遞至其他資料庫中的服務。 訊息不會遺失，且可以在傳送者佇列中找到。 SQL 受控執行個體中的任何虛擬核心或執行個體儲存大小變更，會導致所有資料庫的 service_broke_guid 檢視中的 值變更。 使用 DIALOG 陳述式並引用其他資料庫中的 Service Broker 所建立的任何 會停止將訊息傳遞至目標服務。
因應措施：在更新服務層級之前，請停止任何使用跨資料庫 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 的 SQL 受控執行個體可能會因為內部片段而超過 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 高級磁碟的 35TB 限制。
在此範例中，現有資料庫會繼續運作，只要不新增檔案，就可正常成長而不會有任何問題。 因為沒有足夠空間可供新的磁碟機使用，所以無法建立或還原新的資料庫，即使所有資料庫的大小總計未達到執行個體大小限制也是如此。 在這種情況下返回的錯誤信息並不明確。
您可以使用系統檢視來識別剩餘的檔案數目 \(英文\)。 如果您觸達此限制，請嘗試使用 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 地址。 此錯誤為暫時性問題。
沒有解決方法
當執行個體連結至 SQL Server 時，不會進行差異備份
當您設定 SQL Server 與 Azure SQL 受控執行個體之間的 連結 時，無論它是否處於主要角色，都會在 SQL 受控執行個體上進行自動完整備份和交易記錄備份。 但是，目前未進行差異備份，否則可能會導致還原時間比預期更長。
用於異動複寫的系統登入數目增加
Azure SQL 受管理執行個體服務為交易複寫的目的正在建立系統登入。 您可以在 SSMS (在 物件總管 中 安全性 的 登入 區段中) 或系統檢視表 sys.syslogins 中找到此登入 。 登入名稱的格式看起來像 'DBxCy\WF-abcde01234QWERT'，而且登入具有公用伺服器角色。 在某些情況下，此登入會重新建立，而由於系統中的錯誤，先前的登入未被刪除。 這可能會導致登入數目增加。 這些登入不代表安全性威脅。 您可以安心略過。 您不應該刪除這些登入，因為其中至少有一個登入正在用於交易複製。
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 受控執行個體系統管理員必須清理舊主要執行個體上的所有發行集，並在新的主要執行個體上重新加以設定。 如需詳細資訊，請參閱複寫。
錯誤記錄檔不會保存
SQL 受控執行個體中可用的錯誤記錄檔不會保留下來，而且其大小不包括在儲存體大小上限中。 如果發生故障轉移，錯誤記錄檔可能會被自動清除。 由於在多個虛擬機器上多次移動 SQL 受控執行個體，因此錯誤記錄檔歷程記錄中可能含有空白。
已解決
在調整規模作業期間，使用容錯移轉群組傾聽器暫時無法存取執行個體
（已於 2025 年 4 月解決）
調整 SQL 受控執行個體有時需要將執行個體移至不同的虛擬叢集，以及相關聯的服務維護的 DNS 記錄。 如果 SQL 受控執行個體參與容錯移轉群組，則對應至其相關聯容錯移轉群組接聽程式的 DNS 記錄 （讀寫接聽程式，如果執行個體是目前的異地主要唯讀接聽程式，如果執行個體是目前的異地次要接聽程式） 會移至新的虛擬叢集。
在目前的擴展操作設計中，SQL 受控執行個體尚未完全移轉至新的虛擬叢集前，會先從原始虛擬叢集中移除接聽程式 DNS 記錄，某些情況下可能會導致無法使用接聽程式解析執行個體的 IP 位址。 在此期間，嘗試使用接聽程式端點存取正在調整之實例的 SQL 用戶端，可能會預期登入失敗，並出現下列錯誤訊息：
Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).
此問題將透過擴充操作的重新設計來解決。
手動備份的 msdb 資料表不會保留使用者名稱
(2023 年 8 月已解決) 我們最近在 msdb 引進了對自動備份的支援，但資料表目前未包含使用者名稱資訊。
使用 SQL Server 驗證時，不支援使用 '@' 的使用者名稱
中間包含 '@' 符號的使用者名稱 (例如 'abc@xy') 無法使用 SQL Server 驗證登入。
在沒有 CHECKSUM 的情況下還原手動備份可能會失敗
（已於 2020 年 6 月解決） 在某些情況下，在沒有 CHECKSUM 的 SQL 受管理執行個體上進行的資料庫手動備份可能無法還原。 在這種情況下，請重試還原備份直到成功為止。
因應措施： 在啟用 CHECKSUM 的 SQL 受控執行個體上手動備份資料庫。
資源群組的權限未套用至 SQL 受控執行個體
當將 SQL 受控執行個體參與者的 Azure 角色套用至資源群組 (RG) 時，其不會對 SQL 受控執行個體產生影響。
因應措施：在訂用帳戶層級為使用者設定 SQL 管理執行個體貢獻者角色。
Azure 入口網站上的誤導錯誤訊息，建議重新建立服務主體
針對 Azure SQL 受控執行個體 Azure 入口網站的 Active Directory 管理員頁面，即使服務主體已存在，仍可能會顯示下列錯誤訊息：
Managed Instance needs a Service Principal to access Microsoft Entra ID ([formerly Azure Active Directory](/entra/fundamentals/new-name)). Click here to create a Service Principal
如果 SQL 受控執行個體的服務主體已存在，和/或 SQL 受控執行個體上的 Microsoft Entra 驗證運作正常，您可以忽略此錯誤訊息。
若要檢查服務主體是否存在，請流覽至 Azure 入口網站上的 [企業應用程式] 頁面，從 [應用程式類型] 下拉式清單中選擇 [受控識別]，選取 [套用]，然後在搜尋方塊中輸入 SQL 受控執行個體的名稱。 如果結果清單中顯示執行個體名稱，表示服務主體已存在，無須採取進一步動作。
如果您已遵循錯誤訊息中的指示，並從錯誤訊息中選取連結，則已重新建立 SQL 受控執行個體的服務主體。 在此情況下，將 Microsoft Entra ID 讀取權限指派給新建立的服務主體，以便 Microsoft Entra 驗證正常運作。 您可以依照下列指示，透過 Azure PowerShell 來完成此動作。
無法存取 system_health 事件工作階段中的 event_file 目標
（2025年5月解決）當您嘗試讀取事件會話目標event_file的內容system_health時，您會收到錯誤 40538：「開頭為 『https://』 的有效 URL 必須做為指定之任何檔案路徑的值」。這發生在 SQL Server Management Studio 中，或使用 sys.fn_xe_file_target_read_file 函式讀取會話數據時。
此行為變更是最近的必要安全性修正的意外後果。 我們正在調查其他變更的可行性，讓客戶能夠繼續安全地使用 Azure SQL 受控執行個體上的 system_health 工作階段。 同時，客戶可藉由在 Azure Blob 儲存體中建立自己的具有 system_health 目標的對等 event_file 工作階段，來解決此問題。 如需詳細資訊，包括用於建立 system_health 工作階段的 T-SQL 指令碼，且可修改該工作階段來建立您自己的對等 system_health 工作階段，請參閱使用 system_health 工作階段。
貢獻內容
若要參與編輯 Azure SQL 文件，請參閱 Docs 參與者指南。
相關內容
如需 SQL 受控執行個體更新和增強功能清單，請參閱 SQL 受控執行個體服務更新。
如需所有 Azure 服務的更新與改進功能，請參閱服務更新。