從 Azure SQL 資料庫自動重新植入 Fabric 鏡像資料庫

本文說明在 Azure SQL 資料庫中對資料庫進行鏡像時的自動重新設置。

在某些情況下，如果鏡像至 Fabric 有延遲，則可能會增加交易日誌檔案的使用量。在已認可的變更複寫至鏡像資料庫之前，無法截斷交易記錄檔。一旦交易記錄大小達到其定義的上限，寫入資料庫就會失敗。

為了防止關鍵 OLTP 交易的寫入失敗，Azure SQL 資料庫與 Azure SQL 管理實例的鏡像功能會使用自動重種功能，允許截斷交易日誌，並重新初始化資料庫鏡像至 Fabric。

重置會停止從鏡像資料庫到 Microsoft Fabric 的交易流動，並在目前狀態重新初始化鏡像。重新植入涉及產生針對鏡像設定的資料表的新初始快照集，並將該快照集複寫至 Microsoft Fabric。快照之後，增量更新會被同步。

在 Azure SQL 資料庫和 Azure SQL 受控執行個體中，重新植入可以在資料庫層級或資料表層級進行。

資料庫層級重新植入： 資料庫中所有已啟用鏡像的資料表都會停止進行中的資料鏡像、截斷交易記錄檔，並重新發佈已啟用鏡像之所有資料表的初始快照集，以重新初始化資料庫的鏡像。然後，增量變更會恢復並持續複製。
表格層級重新植入： 只有需要重新植入的資料表才會停止資料的持續鏡像。透過重新發佈初始快照，會針對那些受影響的資料表重新初始化鏡像。然後，增量變更會恢復並持續複製。

資料庫級自動重新植入的原因

資料庫層級的重新植入可確保交易記錄不會成長到最大大小，以保護資料庫寫入可用性。交易記錄大小上限是根據 Azure SQL Database 或 Azure SQL 受控執行個體的資料庫服務等級目標而定。啟用 Fabric 鏡像的資料庫，其交易日誌的使用量可能會不斷增加，從而阻礙日誌截斷。一旦交易記錄大小達到定義的最大限制，寫入資料庫就會失敗。

由於鏡像導致防止日誌截斷的原因可能有多種：
- 將資料從來源鏡像到鏡像資料庫時的延遲，會防止那些擱置複寫的交易從交易紀錄檔中被截斷。
- 正在等待複寫的長時間執行複寫交易因無法截斷，繼續佔用交易記錄的空間。
- OneLake 中寫入著陸區時持續錯誤可能會阻止複製。
  - 這種情況可能是因為權限不足所造成的。鏡像至Fabric會使用系統指派的管理身份（SAMI）或使用者指派的管理身份（UAMI）以將資料寫入One Lake的著陸區。如果設定不當，交易複製可能會反覆失敗。
    
    備註
    
    使用者指派管理身份（UAMI）的支援目前處於預覽階段。
如果 Fabric 容量被暫停後再繼續，則鏡像資料庫狀態仍然保持在已暫停。因此，在來源中所做的變更不會複寫至 OneLake。若要繼續鏡像，請移至 Fabric 入口網站中的鏡像資料庫，選取 [繼續複寫]。鏡像從暫停的位置繼續進行。

如果 Fabric 容量長時間保持暫停狀態，鏡映可能不會從其停止點繼續，而會從頭開始重新同步資料。這是因為長時間暫停鏡像可能會導致來源資料庫的交易記錄檔使用量增加，並延遲記錄截斷。當資料庫鏡像恢復時，若交易記錄檔案空間使用接近於滿，將啟動資料庫的重新載入，以釋放被佔用的記錄空間。

表級自動重設的原因

當已啟用鏡映的來源資料表發生結構描述變更時，Fabric 中那些鏡映資料表的結構描述不再符合來源。這可能是因為來源上的下列 ALTER TABLE 資料定義語言（DDL） T-SQL 陳述式：

新增/刪除/更改/重新命名欄
截斷/重新命名表格
新增非叢集主索引鍵

只會針對受影響的資料表進行重置操作。

診斷

若要識別 Fabric 鏡映是否阻止鏡映資料庫的日誌截斷，請檢查 log_reuse_wait_desc 系統型錄視圖中的 sys.databases 直欄，以查看原因是否為 REPLICATION。如需瞭解日誌重用等待類型的詳細資訊，請參閱延遲交易日誌截斷的因素。例如：

SELECT [name], log_reuse_wait_desc 
FROM sys.databases 
WHERE is_data_lake_replication_enabled = 1;

如果查詢顯示 REPLICATION 日誌重複使用等待類型，則由於 Fabric 鏡像，交易日誌無法清空已提交的交易，並且會繼續填滿。如需 Azure SQL 資料庫中記錄使用量的其他疑難排解，請參閱針對 Azure SQL 資料庫的交易記錄錯誤進行疑難排解。

使用下列 T-SQL 腳本來檢查記錄空間總計，以及目前的記錄使用量和可用空間：


USE <Mirrored database name>
GO 
--initialize variables
DECLARE @total_log_size bigint = 0; 
DECLARE @used_log_size bigint = 0;
DECLARE @size int;
DECLARE @max_size int;
DECLARE @growth int;

--retrieve total log space based on number of log files and growth settings for the database
DECLARE sdf CURSOR
FOR
SELECT SIZE*1.0*8192/1024/1024 AS [size in MB],
            max_size*1.0*8192/1024/1024 AS [max size in MB],
            growth
FROM sys.database_files
WHERE TYPE = 1 
OPEN sdf 
FETCH NEXT FROM sdf INTO @size,
                @max_size,
                @growth 
WHILE @@FETCH_STATUS = 0 
BEGIN
SELECT @total_log_size = @total_log_size + 
CASE @growth
        WHEN 0 THEN @size
        ELSE @max_size
END 
FETCH NEXT FROM sdf INTO @size,
              @max_size,
              @growth 
END 
CLOSE sdf;
DEALLOCATE sdf;

--current log space usage
SELECT @used_log_size = used_log_space_in_bytes*1.0/1024/1024
FROM sys.dm_db_log_space_usage;

-- log space used in percent
SELECT @used_log_size AS [used log space in MB],
       @total_log_size AS [total log space in MB],
       @used_log_size/@total_log_size AS [used log space in percentage];

重新播種期間

在重新植入期間，Microsoft Fabric 中的鏡像資料庫專案可供使用，但在重新植入完成之前不會收到累加變更。 reseed_state中的sys.sp_help_change_feed_settings欄指出重新植入狀態。

在 Fabric 鏡像中，會監視來源 SQL 資料庫交易記錄。只有在下列三個條件成立時，才會觸發自動重新植入：

交易日誌超過@autoreseedthreshold百分比已滿，例如70。
日誌重複使用原因為 REPLICATION。
因為記錄重複使用等候可能會因其他功能（例如交易複寫或 CDC）而被提升，只有當 REPLICATION = 1 時 sys.databases.is_data_lake_replication_enabled 才會進行自動重播。此值由 Fabric Mirroring 設定。

檢查是否已觸發資料庫層級重新植入

如果要重新植入整個資料庫，請尋找下列條件。

reseed_state在來源 SQL 資料庫中系統預存程序sys.sp_help_change_feed_settings的欄位指出其目前的重新設置狀態。
- 0 = 一般。
- 1 = 資料庫已開始重新初始化至 Fabric 的程式。過渡狀態。
- 2 = 資料庫正在重新初始化為 Fabric，並等待複寫重新啟動。過渡狀態。建立複寫時，重新植入狀態會移至 0。
如需詳細資訊，請參閱 sys.sp_help_change_feed_settings。
資料庫中啟用鏡像的所有資料表，其7中的state欄位值都會是sys.sp_help_change_feed_table。

如需詳細資訊，請參閱 sys.sp_help_change_feed_table。

檢查是否已觸發資料表層級重置

對於任何要重新設定初始值的表格，請在7中尋找state行sys.sp_help_change_feed_table的值。

如需詳細資訊，請參閱 sys.sp_help_change_feed_table。

針對 Azure SQL 資料庫的 Fabric 鏡像資料庫進行疑難排解

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-11-25