Azure SQL 受控執行個體的已知問題

適用于:Azure SQL 受控執行個體

本文列出 Azure SQL 受控執行個體目前的已知問題,以及其解決日期或可能的因應措施。 若要深入了解 Azure SQL 受控執行個體,請參閱概觀新增功能

已知問題

問題 探索日期 狀態 解決日期
2022 年時區更新的過渡期指引 2022 年 8 月 有因應措施
查詢外部資料表失敗,出現不支援的錯誤訊息 2022 年 1 月 有因應措施
使用 SQL Server 驗證時,不支援使用「@」的使用者名稱 2021 年 10 月 已解決 2022 年 2 月
Azure 入口網站上的誤導錯誤訊息,建議您重新建立服務主體 2021 年 9 月 2021 年 10 月
變更連線類型並不會影響透過容錯移轉群組端點的連線 2021 年 1 月 有因應措施
Procedure sp_send_dbmail may transiently fail when @query parameter is used 2021 年 1 月 有因應措施
從伺服器信任群組移除受控執行個體後,可執行分散式交易 2020 年 10 月 有因應措施
受控執行個體進行調整作業後,無法執行分散式交易 2020 年 10 月 已解決 2021 年 5 月
無法使用與先前刪除的邏輯伺服器相同名稱,建立 SQL 受控執行個體 2020 年 8 月 有因應措施
服務主體無法存取 Azure AD 和 AKV 2020 年 8 月 有因應措施
在未啟用 CHECKSUM 的情況下還原手動備份可能會失敗 2020 年 5 月 已解決 2020 年 6 月
代理程式在修改、停用或啟用現有作業後無回應 2020 年 5 月 已解決 2020 年 6 月
資源群組的權限未套用至 SQL 受控執行個體 2020 年 2 月 已解決 2020 年 11 月
透過入口網站針對容錯移轉群組進行手動容錯移轉的限制 2020 年 1 月 有因應措施
SQL Agent 角色需要非系統管理員 (sysadmin) 登入的明確 EXECUTE 許可權 2019 年 12 月 有因應措施
代理程式程序重新啟動可能會中斷 SQL Agent 作業 2019 年 12 月 已解決 2020 年 5 月
SSDT 中不支援 Azure AD 登入和使用者 2019 年 11 月 無因應措施
記憶體內部 OLTP 記憶體限制不適用 2019 年 10 月 有因應措施
嘗試移除不是空的檔案時傳回錯誤的錯誤 2019 年 10 月 有因應措施
進行中的資料庫還原會封鎖變更服務層級和建立執行個體作業 2019 年 9 月 有因應措施
容錯移轉之後,可能需要重新設定業務關鍵服務層級的 Resource Governor 2019 年 9 月 有因應措施
服務層級升級之後,必須重新初始化跨資料庫 Service Broker 對話 2019 年 8 月 有因應措施
不支援 Azure AD 登入類型的模擬 2019 年 7 月 無因應措施
sp_send_db_mail 中不支援 @ 查詢參數 2019 年 4 月 已解決 2021 年 1 月
異地容錯移轉之後必須重新設定異動複寫 2019 年 3 月 無因應措施
RESTORE 作業期間會使用暫存資料庫 有因應措施
已重新建立 TEMPDB 結構和內容 無因應措施
小型資料庫檔案造成儲存空間超出限制 有因應措施
顯示 GUID 值,而不是資料庫名稱 有因應措施
錯誤記錄檔不會保存 無因應措施
不支援相同執行個體內兩個資料庫上的異動範圍 有因應措施 2020 年 5 月
CLR 模組與連結的伺服器有時候無法參考本機 IP 位址 有因應措施
從 Azure Blob 儲存體還原資料庫之後,未使用 DBCC CHECKDB 確認資料庫一致性。 已解決 2019 年 11 月
如果來源資料庫包含記憶體內部 OLTP 物件,則從業務關鍵服務層級到一般用途服務層級的時間點資料庫還原將不會成功。 已解決 2019 年 10 月
具備使用安全連線之外部 (非 Azure) 郵件伺服器的 Database Mail 功能 已解決 2019 年 10 月
SQL 受控執行個體中不支援自主資料庫 已解決 2019 年 8 月

有因應措施

2022 年時區更新的過渡期指引

在 2022 年 8 月 8 日,英國政府針對Daylight-Saving時間 (DST) 時區變更提出官方公告。 從上午 12:00 開始,2022 年 9 月 10 日下午 12:00,直到上午 12:00,2023 年 4 月 1 日,官方時間將會前進 60 分鐘。 此變更會影響下列三個時區: Pacific SA Standard TimeEaster Island Standard TimeMagallanes Standard Time。 Azure SQL受影響時區的受控實例將不會反映變更,直到 Microsoft 發行作業系統更新以支援此更新,且Azure SQL 受控執行個體服務會吸收作業系統層級上的更新。

因應措施:如果您需要改變受控實例的受影響時區,請注意 限制 ,並遵循檔中的指引。

查詢外部資料表失敗,出現不支援的錯誤訊息

查詢外部資料表失敗時顯示一般錯誤訊息「此資料庫目前的服務層或效能等級,不支援外部資料表的查詢。請考慮升級該資料庫的服務層或效能等級。」。 Azure SQL 受控執行個體中唯一支援的外部資料表類型是 PolyBase 外部資料表 (處於預覽)。 若要在 PolyBase 外部資料表上允許查詢,您必須執行 sp_configure 命令,來在受控執行個體上啟用 PolyBase。

SQL 受控執行個體中不支援與 Azure SQL Database 的彈性查詢功能相關的外部資料表,但建立和查詢資料表時不會明確遭到封鎖。 利用對 PolyBase 外部資料表的支援,已推出新的檢查,除非已啟用 PolyBase,否則會封鎖查詢受控執行個體中任何類型的外部資料表。

如果您要使用不支援的彈性查詢外部資料表,從受控執行個體查詢 Azure SQL Database 或 Azure Synapse 中的資料,您應改用連結的伺服器功能。 若要建立從 SQL 受控執行個體至 SQL Database 的連結伺服器連線,請遵循本文中的指示。 若要建立從 SQL 受控執行個體至 SQL Synapse 的連結伺服器連線,請參閱此處的逐步指示。 由於設定和測試連結伺服器連線需要一些時間,您可以使用因應措施作為暫時的解決方案,來啟用查詢外部資料表時與彈性查詢相關的功能:

因應措施:執行下列命令 (每個執行個體一次) 以啟用查詢外部資料表:

sp_configure 'polybase enabled', 1
go
reconfigure
go

變更連線類型並不會影響透過容錯移轉群組端點的連線

如果執行個體參與自動容錯移轉群組,則變更執行個體的連線類型不會影響透過容錯移轉群組接聽程式端點建立的連線。

因應措施:變更連線類型後,卸除並重新建立自動容錯移轉群組。

使用 @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 的邏輯伺服器,然後將其刪除,則需要 7 天的閾值期間,7 天後記錄才會釋放此名稱。 在該段期間,您無法使用已刪除邏輯伺服器相同名稱建立 SQL 受控執行個體。 因應措施是針對 SQL 受控執行個體使用不同的名稱,或建立支援票證以釋放此邏輯伺服器名稱。

服務主體無法存取 Azure AD 和 AKV

在某些情況下,用於存取 Azure AD and Azure Key Vault (AKV) 服務的服務主體可能存在問題。 因此,此問題會影響透過 SQL 受控執行個體使用 Azure AD 驗證和透明資料庫加密 (TDE) 的使用情況。 這可能由於間歇性的連線問題,或是無法執行或如 CREATE LOGIN/USER FROM EXTERNAL PROVIDEREXECUTE AS LOGIN/USER 等陳述式。 在新的 Azure SQL 受控執行個體上使用客戶管理的金鑰來設定 TDE,在某些情況下可能也無法運作。

因應措施:如果要避免在執行任何更新命令前,您的 SQL 受控執行個體發生此問題,或在執行更新命令之後遇到此問題,請移至 Azure 入口網站,存取 SQL 受控執行個體 Active Directory 系統管理頁面。 確認您是否可以看到錯誤訊息「受控執行個體需要服務主體才能存取 Azure Active Directory。 請按一下此處以建立服務主體」。 如果您遇到此錯誤訊息,請按一下該訊息,並依照提供的逐步指示進行,直到解決此錯誤為止。

透過入口網站針對容錯移轉群組進行手動容錯移轉的限制

如果容錯移轉群組跨越不同 Azure 訂用帳戶或資源群組中的執行個體,則無法從容錯移轉群組中的主要執行個體起始手動容錯移轉。

因應措施:透過入口網站,從異地複寫次要執行個體起始容錯移轉。

SQL Agent 角色需要非系統管理員 (sysadmin) 登入的明確 EXECUTE 許可權

如果將非系統管理員 (sysadmin) 登入加入任何 SQL Agent 固定資料庫角色,則會存在一個問題,即必須將明確的 EXECUTE 權限授與三個預存程序,這些登入才可正常進行。 如果遇到此問題,則會顯示錯誤訊息「EXECUTE 權限在物件 <object_name> 上遭到拒絕 (Microsoft SQL Server,錯誤: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 分鐘之後失敗。

因應措施:使用 DBCC SHRINKFILE (N'<file_name>', EMPTYFILE) 命令移除檔案內容。 如果這是檔案群組中唯一的檔案,您必須先從與這個檔案群組相關聯的資料表或分割區中刪除資料,然後再壓縮檔案,並選擇性地將此資料載入另一個資料表/資料分割。

進行中的資料庫還原會封鎖變更服務層級和建立執行個體作業

進行中的 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 對話交談的活動,然後再將其重新初始化。 如果有剩餘的訊息在服務層級變更後無法傳遞,請從來源佇列讀取訊息,然後將其重新傳送至目標佇列。

RESTORE 作業期間會使用暫存資料庫

當資料庫在 SQL 受控執行個體上還原時,還原服務會先建立具有所需名稱的空資料庫,以在執行個體上配置名稱。 經過一段時間之後,就會卸除此資料庫,並開始還原實際資料庫。

處於還原狀態的資料庫,會暫時擁有隨機 GUID 值,而非名稱。 一旦還原程序完成,暫時名稱就會變更為 RESTORE 陳述式中所指定的名稱。

在初始階段中,使用者可以存取空的資料庫,甚至在此資料庫中建立資料表或載入資料。 當還原服務啟動第二個階段時,將會卸除此暫存資料庫。

因應措施:除非您看到還原已完成,否則請不要存取您要還原的資料庫。

小型資料庫檔案造成儲存空間超出限制

CREATE DATABASEALTER DATABASE ADD FILERESTORE 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;

不支援相同執行個體內兩個資料庫上的異動範圍

(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) 在連線內容中使用其他資料庫,而非使用兩個連線。

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) 在連線內容中使用其他資料庫,而非使用兩個連線。

沒有解決方法

SSDT 中不支援 Azure AD 登入和使用者

SQL Server Data Tools 無法完整支援 Azure AD 登入和使用者。

不支援 Azure AD 登入類型的模擬

不支援使用下列 Azure Active Directory (Azure AD) 主體的 EXECUTE AS USEREXECUTE AS LOGIN 進行模擬:

  • 別名化的 Azure AD 使用者。 在此情況下,系統會傳回下列錯誤:15517
  • Azure AD 登入和以 Azure AD 應用程式或服務主體為基礎的使用者。 在此情況下,系統會傳回下列錯誤:1551715406

異地容錯移轉之後必須重新設定異動複寫

如果在自動容錯移轉群組中的資料庫上啟用異動複寫,則 SQL 受控執行個體管理員必須清除舊主要執行個體上的所有發行集,並在容錯移轉至另一個區域之後,在新的主要執行個體上重新加以設定。 如需詳細資訊,請參閱複寫

已重新建立 TEMPDB 結構和內容

tempdb 資料庫一律會分割成 12 個資料檔案,而且無法變更檔案結構。 無法變更每個檔案大小的上限,而且無法將新檔案新增至 tempdbTempdb 當執行個體啟動或容錯移轉時,一律會重新建立為空的資料庫,而且不會保留在 tempdb 中進行的任何變更。

錯誤記錄檔不會保存

SQL 受控執行個體中可用的錯誤記錄檔不會保留下來,而且其大小不包括在儲存體大小上限中。 若發生容錯移轉,可能會自動清除錯誤記錄檔。 由於在多個虛擬機器上多次移動 SQL 受控執行個體,因此錯誤記錄檔歷程記錄中可能含有空白。

已解決

使用 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 管理員刀鋒視窗即使服務主體已存在仍可能會顯示下列錯誤訊息:

「受控執行個體需要服務主體才能存取 Azure Active Directory。 請按一下此處以建立服務主體」

如果受控執行個體的服務主體已存在,且/或受控執行個體上的 Azure Active Directory 驗證可執行,您可以忽略此錯誤訊息。

若要檢查服務主體是否存在,請瀏覽至 Azure 入口網頁的 [企業應用程式] 頁面,在 [應用程式類型] 下拉式清單中選擇 [受控識別],再選取 [套用] 並在搜尋方塊中輸入受控執行個體的名稱。 如果結果清單中顯示執行個體名稱,表示服務主體已存在,無須採取進一步動作。

如果您已遵循錯誤訊息中的指示,並按一下錯誤訊息中的連結,則會重新建立受控執行個體的服務主體。 在此情況下,請將 Azure AD 讀取權限指派給新建立的服務主體,以便 Azure AD 驗證正常運作。 您可以依照下列指示,透過 Azure PowerShell 來完成此動作。

參與內容

若要參與編輯 Azure SQL 文件,請參閱 Docs 參與者指南

後續步驟

如需 SQL 受控執行個體更新和增強功能清單,請參閱 SQL 受控執行個體服務更新

如需所有 Azure 服務的更新與改進功能,請參閱服務更新