Azure SQL 受控執行個體的已知問題
適用於：
Azure SQL 受控執行個體
本文列出目前 Azure SQL 受控執行個體 的已知問題，以及其解決日期或可能的因應措施。 若要深入瞭解 Azure SQL 受控執行個體，請參閱什麼是 Azure SQL 受控執行個體？，以及 Azure SQL 受控執行個體 的新功能？
注意
Microsoft Entra 標識符 先前稱為 Azure Active Directory （Azure AD）。
已知問題
有因應措施
無法存取system_health事件會話event_file目標
當您嘗試讀取事件會話目標system_health的內容event_file時，您會收到錯誤 40538：「開頭為 'https://' 的有效 URL 必須做為指定之任何 filepath 的值。」這發生在 SQL Server Management Studio 中，或使用 sys.fn_xe_file_target_read_file 函式讀取會話數據時。
這種行為變更是最近必要安全性修正的意外後果。 我們正在調查其他變更的可行性，讓客戶能夠安全地使用 system_health Azure SQL 受控執行個體 會話。 同時，客戶可以藉由在 Azure Blob 記憶體中建立自己的對等會話event_file，system_health以解決此問題。 如需詳細資訊，包括 T-SQL 腳本來建立可修改以建立 system_health 您自己的對等 system_health會話，請參閱 使用 system_health 會話。
在已啟用 112FW 的受控實例上使用 參數時 @query ，程式sp_send_dbmail可能會失敗
使用 參數時@query，程式sp_send_dbmail可能會失敗，這會影響已啟用 2022 年 11 月功能波的實例。 在 sysadmin 帳戶下執行預存程式時，就會發生失敗。
此問題是由使用模擬方式的相關 sp_send_dbmail 已知 Bug 所造成。
因應措施：請確定您已建立的適當自定義帳戶下呼叫 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 標準時間」、「復活節島標準時間」和「麥哲倫標準時間」。 使用受影響時區的 Azure SQL 受控執行個體 不會反映變更，直到 Microsoft 發行作業系統更新以支援此功能，且 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 資料庫 建立邏輯伺服器，然後加以刪除，則在從記錄中釋放名稱前七天會有臨界值期間。 在該期間，無法以與已刪除邏輯伺服器相同的名稱建立 SQL 受管理執行個體。 因應措施是針對 SQL 受控執行個體使用不同的名稱，或建立支援票證以釋放此邏輯伺服器名稱。
服務主體無法存取 Microsoft Entra ID 和 AKV
在某些情況下，使用服務主體存取 Microsoft Entra ID（先前稱為 Azure Active Directory）和 Azure 金鑰保存庫 （AKV） 服務時，可能會發生問題。 因此，此問題會影響使用 Microsoft Entra 驗證和透明數據加密 （TDE） 與 SQL 受管理執行個體。 這可能由於間歇性的連線問題，或是無法執行或如 CREATE LOGIN/USER FROM EXTERNAL PROVIDER 或 EXECUTE AS LOGIN/USER 等陳述式。 在新的 Azure SQL 受控執行個體上使用客戶管理的金鑰來設定 TDE，在某些情況下可能也無法運作。
因應措施：如果要避免在執行任何更新命令前，您的 SQL 受控執行個體發生此問題，或在執行更新命令之後遇到此問題，請移至 Azure 入口網站，存取 SQL 受控執行個體 Active Directory 系統管理頁面。 確認您是否可以看到錯誤訊息「受控執行個體 需要服務主體才能存取 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 固定資料庫角色（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 受管理執行個體 中虛擬核心或實例記憶體大小的任何變更，都會service_broke_guid對所有資料庫變更 sys.databases 檢視中的值。 任何 DIALOG 使用 BEGIN DIALOG 語句所建立，參考其他資料庫中的 Service Brokers 會停止將訊息傳遞至目標服務。
因應措施：在更新服務層級之前，請停止任何使用跨資料庫 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=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();
}
因應措施 (自 2020 年 3 月起不再需要)：使用 SqlConnection.ChangeDatabase(String) 在連線內容中使用其他資料庫，而非使用兩個連線。
沒有解決方法
事務複製所使用的系統登入數目增加
Azure SQL 受控執行個體 服務會針對事務複製目的建立系統登入。 您可以在 SSMS 中找到此登入（在 [物件總管]、[安全性]、[登入] 底下，或在系統檢視sys.syslogins中找到。 登入名稱格式看起來像 'DBxCy\WF-abcde01234QWERT'，而登入具有公用伺服器角色。 在某些情況下，此登入會重新建立，而由於系統中的錯誤，先前的登入未被刪除。 這可能會導致登入數目增加。 這些登入不代表安全性威脅。 您可以安心略過。 不應該刪除這些登入，因為至少有一個登入用於事務複製。
msdb 中手動備份的數據表不會保留用戶名稱
我們最近在 中 msdb引進了自動備份的支援，但數據表目前不包含使用者名稱資訊。
SSDT 不支援 Microsoft Entra 登入和使用者
SQL Server Data Tools 不支援 Microsoft Entra 登入和使用者。
不支持模擬 Microsoft Entra 登入類型
不支援使用 EXECUTE AS USER 或 EXECUTE AS LOGIN 下列 Microsoft Entra 主體進行模擬：
- 別名的 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）“。
此問題將會透過調整作業重新設計來解決。
已解決
外部資料表的查詢失敗，並出現不支援的錯誤訊息
查詢外部數據表可能會失敗，並出現一般錯誤訊息：「此資料庫的目前服務層級或效能層級不支援外部數據表的查詢。 請考慮升級該資料庫的服務層級或效能等級。 Azure SQL 受控執行個體中唯一支援的外部資料表類型是 PolyBase 外部資料表 (處於預覽)。 若要允許 PolyBase 外部資料表上的查詢，您必須執行 sp_configure 命令，在受控實例上啟用 PolyBase。
SQL 受管理執行個體 不支援與 Azure SQL 資料庫 彈性查詢功能相關的外部數據表，但不會明確封鎖建立和查詢它們。 利用對 PolyBase 外部資料表的支援，已推出新的檢查，除非已啟用 PolyBase，否則會封鎖查詢受控執行個體中任何類型的外部資料表。
如果您要使用不支援的彈性查詢外部資料表，從受控執行個體查詢 Azure SQL Database 或 Azure Synapse 中的資料，您應改用連結的伺服器功能。 若要建立從 SQL 受管理執行個體 到 SQL 資料庫 的鏈接伺服器連線，請遵循本文的指示。 若要建立從 SQL 受控執行個體至 SQL Synapse 的連結伺服器連線，請參閱此處的逐步指示。 由於設定和測試連結伺服器連線需要一些時間，您可以使用因應措施作為暫時的解決方案，來啟用查詢外部資料表時與彈性查詢相關的功能：
因應措施：執行下列命令（每個實例一次），以在外部數據表上啟用查詢：
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
使用 SQL Server 驗證時，不支援具有 『@』 的用戶名稱
中間包含 '@' 符號的使用者名稱 （例如， 'abc@xy'） 無法使用 SQL Server 驗證登入。
在未啟用 CHECKSUM 的情況下還原手動備份可能會失敗
在某些情況下，在未啟用 CHECKSUM 的受控執行個體上進行的資料庫手動備份可能無法還原。 在這種情況下，請重試還原備份直到成功為止。
因應措施：在啟用 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 服務的更新與改進功能，請參閱服務更新。
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應