適用於：
Azure SQL 受控執行個體
本文提供 Log Replay Service (LRS) 概觀，您可用來將資料庫從 SQL Server 移轉至 Azure SQL 受控執行個體。 LRS 是適用於 Azure SQL 受控執行個體的免費雲端服務，而且以 SQL Server 記錄傳遞技術為基礎。
注意
您現在可以直接透過 Azure 入口網站將 Azure Arc 啟用的 SQL Server 執行個體移轉至 Azure SQL 受控執行個體。 如需詳細資訊，請參閱 移轉至 Azure SQL 受控執行個體。
由於 LRS 會還原標準 SQL Server 備份檔案，因此您可以使用它從 裝載於任何地方 的 SQL Server （內部部署或任何雲端） 移轉至 Azure SQL 受控執行個體。
若要使用 LRS 開始移轉，請檢閱使用記錄重播服務從 SQL Server 移轉資料庫。
重要
將資料庫移轉至 業務關鍵 服務層級之前，請考慮這些限制，不適用於一般用途服務層級。
使用日誌重播服務的時機
Azure 資料庫移轉服務、適用於 Azure Data Studio 的 Azure SQL 移轉延伸模組，以及 LRS 全都使用相同的基礎移轉技術和 API。 LRS 會進一步啟用內部部署 SQL Server 執行個體與 SQL 受控執行個體部署之間複雜的自訂移轉和混合式架構。
無法使用 Azure 資料庫移轉服務或 Azure SQL 延伸模組來移轉時，您可以直接使用 LRS 搭配 PowerShell、Azure CLI Cmdlet 或 API，手動建立和協調至 SQL 受控執行個體的資料庫移轉作業。
請考慮在下列情況下使用 LRS：
- 您需要更充分掌控資料庫移轉專案。
- 在遷移過程中的切換階段，對於停機時間幾乎沒有容忍度。
- 您無法將 Database Migration Service 可執行檔安裝到您的環境。
- 資料庫移轉服務可執行檔無法存取資料庫備份的檔案。
- 您無法將 Azure SQL 移轉延伸模組安裝至您的環境，或無法存取您的資料庫備份。
- 您無法存取主機作業系統或管理員權限。
- 您無法開啟從環境至 Azure 的網路連接埠。
- 您的環境中存在網路節流或 Proxy 封鎖問題。
- 備份透過
TO URL選項直接儲存進 Azure Blob 儲存體帳戶。 - 您需要使用差異備份。
由於 LRS 的運作方式是還原標準 SQL Server 備份檔案，因此它支援從任何來源移轉。 已測試以下來源：
- SQL Server 內部部署
- 虛擬機器上的 SQL Server
- Amazon EC2 （彈性計算雲端）
- Amazon RDS (關聯式資料庫服務) for SQL Server
- Google Compute Engine
- 適用於 SQL Server 的 Cloud SQL - GCP (Google Cloud Platform)
- Alibaba 雲端 RDS for SQL Server
如果您遇到從未被列出的來源移轉的非預期問題，請開啟支援請求以獲得協助。
注意
- LRS 是在 SQL 受控執行個體上還原差異備份的唯一方法。 無法在受控執行個體上手動還原差異備份，或使用 T-SQL 手動設定
NORECOVERY模式。
LRS 的運作方式
若要使用 LRS 建立自訂解決方案將資料庫移轉至雲端，需要數個協調流程步驟，如本節稍後的圖解和表格所示。
移轉包括在 SQL Server 上取得資料庫備份，以及將備份檔案複製到 Azure Blob 儲存體帳戶。 LRS 支援完整備份、記錄備份和差異備份。 您接著會使用 LRS 雲端服務將備份檔案從 Azure Blob 儲存體帳戶還原至 SQL 受控執行個體。 Blob 儲存體帳戶在 SQL Server 和 SQL 受控執行個體之間作為備份檔案的中繼儲存體。
LRS 會監控您的 Blob 儲存體帳戶，檢查在完整備份還原後新增的任何差異或日誌備份。 然後 LRS 會自動還原這些新的檔案。 您可以使用該服務監視正在還原至 SQL 受控執行個體的備份檔案的進度，並在必要時停止該程序。
LRS 不要求備份檔案使用特定的命名慣例。 此服務會掃描放在 Azure Blob 儲存體帳戶上的所有檔案，且只讀取檔案標頭來建立備份鏈。 資料庫在移轉過程中處於還原中狀態。 LRS 會在 NORECOVERY 模式中還原資料庫，因此在移轉程序完成之前，它們無法用於讀取或寫入工作負載。
如果您遷移數個資料庫，則需要：
- 將每個資料庫的備份檔案以一般檔案結構，放在 Blob 儲存體帳戶上的單獨資料夾中。 例如，使用不同的資料庫檔案夾：blobcontainer/database1/files、blobcontainer/database2/files 等等。
- 請勿在資料庫資料夾內使用巢狀資料夾，因為不支援巢狀資料夾結構。 例如，請勿使用 blobcontainer/database1/subfolder/files 等子資料夾。
- 針對每個資料庫分別啟動 LRS。
- 指定不同的 URI 路徑來區隔 Blob 儲存體帳戶上的資料庫資料夾。
雖然不需要啟用 CHECKSUM 進行備份，但強烈建議這麼做。 如果還原資料庫時未使用 CHECKSUM，則需要較長的時間，因為 SQL 受控執行個體會對未啟用 CHECKSUM 的備份執行完整性檢查。
如需詳細資訊，請參閱 使用記錄重播服務從 SQL Server 移轉資料庫。
警告
在啟用 CHECKSUM 的 SQL Server 上進行備份是強烈建議的，因為沒有它，將損毀的資料庫還原至 Azure 會有風險。
自動完成與連續模式移轉
您可以用「自動完成」或「連續」模式啟動 LRS。
當您預先產生整個備份鏈，以及您不打算在移轉開始後再新增檔案時，請使用 自動完成 模式。 針對不需要資料追補的被動工作負載，建議使用此移轉模式。 將所有備份檔案上傳至 Blob 儲存體帳戶，然後啟動自動完成模式移轉。 當還原最後指定的備份檔案時，移轉會自動完成。 移轉的資料庫可用於 SQL 受控執行個體上的讀取/寫入存取權。
如果您打算在移轉進行時持續新增備份檔案，請使用連續模式。 我們建議您對需要資料追趕的活躍工作負載使用此模式。 將目前可用的備份鏈結上傳至 Blob 儲存體帳戶、以連續模式啟動移轉，並視需要從工作負載中新增備份檔案。 系統會定期掃描 Azure Blob 儲存體資料夾，並還原它找到的任何新記錄或差異備份檔案。
當您準備好進行完全移轉時，請停止 SQL Server 執行個體上的工作負載、產生最後一個備份檔案，然後上傳它。 確保最後一個備份檔案已還原，方法是確認在 SQL 受控執行個體上顯示最終的日誌尾部備份已還原。 然後，啟動手動切換。 最終轉換步驟會讓資料庫上線，且在 SQL 受控執行個體上可供讀取/寫入存取。
停止 LRS 之後，無論是透過自動完成，還是透過交接過程手動停止，您就無法繼續您在 SQL 受控執行個體上已上線資料庫的還原程序。 例如，在移轉完成後，您就無法再為線上資料庫還原更多差異備份。 在移轉結束後，若要還原更多備份檔案，您需要刪除受控執行個體的資料庫，然後從頭重新開始移轉。
移轉工作流程
本節中的影像顯示典型的移轉工作流程，而表格則概述步驟。
只有在所有備份鏈檔案都預先可用時，才使用自動完成模式。 我們建議將此模式用於不需要資料追趕的被動工作負載。
當您事先沒有完整備份鏈時，以及當您計劃在移轉進行中新增備份檔案後，請使用連續模式移轉。 我們建議您對需要資料追趕的活躍工作負載使用此模式。
| 作業 | 詳細資料 |
|---|---|
| 1. 將資料庫備份從 SQL Server 執行個體複製到 Blob 儲存體帳戶。 | 使用 AzCopy 或 Azure 儲存體總管，將完整備份、差異備份和記錄備份從 SQL Server 執行個體複製到 Blob 儲存體容器。 使用任何檔案名稱。 LRS 不需要特定的檔案命名慣例。 當您移轉數個資料庫時，請為每個資料庫使用單獨的資料夾。 |
| 2. 在雲端啟動 LRS。 | 使用 PowerShell （start-azsqlinstancedatabaselogreplay） 或 Azure CLI （az_sql_midb_log_replay_start Cmdlet） 啟動服務。 選擇自動完成或連續移轉模式。 在 Blob 儲存體帳戶上針對指向備份資料夾的每個資料庫，分別啟動 LRS。 服務啟動後會從 Blob 儲存體容器取得備份，並開始還原到 SQL 受控執行個體上。 當您以自動完成模式啟動 LRS 時，它會透過指定的最後一個備份檔案還原所有備份。 您必須事先上傳所有備份檔案，而且在移轉過程中無法新增任何新的備份檔案。 建議將此模式用於不需要資料追趕的被動工作負載。 當您以連續模式啟動 LRS 時，它會還原您最初上傳的所有備份，然後監看您上傳至資料夾的任何新檔案。 服務會根據記錄序號鏈 (LSN) 持續套用記錄，直到手動停止。 我們建議您對需要資料追趕的活躍工作負載使用此模式。 |
| 2.1. 監視作業的進度. | 使用 PowerShell （get-azsqlinstancedatabaselogreplay） 或 Azure CLI （az_sql_midb_log_replay_show Cmdlet） 監視進行中還原作業的進度。 若要追蹤失敗要求的其他詳細資料，請使用PowerShell命令 Get-AzSqlInstanceOperation 或使用 Azure CLI 命令 az sql mi op show。 |
| 2.2. 視需要停止作業 (選擇性). | 如果您需要停止移轉流程，請使用 PowerShell (stop-azsqlinstancedatabaselogreplay) 或 Azure CLI (az_sql_midb_log_replay_stop)。 停止作業會刪除您要還原到 SQL 受控執行個體上的資料庫。 停止作業後，您將無法為資料庫恢復使用 LRS。 您需要從頭重新開始移轉流程。 |
| 3. 準備好時切換移至雲端。 | 如果您在自動完成模式中啟動 LRS，則在還原指定的最後一個備份檔案之後，移轉會自動完成。 如果您在連續模式下啟動 LRS，請停止應用程式和工作負載。 從最後的 log-tail 備份中取得資料，然後上傳至 Azure Blob 儲存服務。 請確定在 SQL 受控執行個體上還原最後一個日誌尾部備份。 完成轉換，請使用 PowerShell complete 操作（complete-azsqlinstancedatabaselogreplay）或 Azure CLI az_sql_midb_log_replay_complete 來起始 LRS 作業。 此作業會停止 LRS，並讓資料庫上線以執行 SQL 受控執行個體的讀取/寫入工作負載。將應用程式連接字串從 SQL Server 執行個體重新指向 SQL 受控執行個體。 您需要在應用程式中透過手動變更連接字串，以自行協調此步驟，或自動協調此步驟 (例如，如果應用程式可以從屬性或資料庫讀取連接字串)。 |
重要
一旦移轉後，具有 業務關鍵 服務層級的 SQL 受管理執行個體可能需要比 一般用途 更長的時間才能使用，因為需要植入可用性群組的三個次要複本。 此作業的持續時間取決於資料的大小。 如需詳細資訊，請參閱管理作業持續時間。
移轉大型資料庫
如果您要移轉大小為數 TB 的大型資料庫，請考慮下列幾點：
- 單一 LRS 作業最多可以執行 30 天。 經過這一段期間後將自動取消工作。
- 對於長時間執行的工作，系統更新可能會中斷和延長移轉工作。 強烈建議您使用維護時段來排程計劃性系統更新。 請根據預定的維護時段規劃遷移。
- 系統更新中斷的移轉作業，對於一般用途 SQL 受控執行個體會自動暫停並繼續，而對於商務關鍵 SQL 受控執行個體則會重新啟動。 這些更新會影響移轉的時間範圍。
- 若要增加 SQL Server 備份檔案至 Blob 儲存體帳戶的上傳速度，如果您的基礎結構有足夠的網路頻寬，請考慮使用平行處理搭配多個執行緒。
開始移轉
啟動 LRS 以開始移轉。 您可以選擇自動完成或連續模式來啟動此服務。 如需特定詳細資訊，請檢閱使用記錄重播服務從 SQL Server 移轉資料庫。
自動完成模式。 當您使用自動完成模式時，移轉會在還原最後一個指定的備份檔案時自動完成。 此選項：
- 需要事先提供整個備份鏈結，並上傳至 Azure Blob 儲存體帳戶。
- 移轉進行期間，不允許新增備份檔案。
- 需要 start 命令指定最後一個備份檔案的檔案名稱。
建議針對不需要資料追補的被動工作負載使用自動完成模式。
連續模式。 當您使用連續模式時，服務會持續掃描 Azure Blob 儲存體資料夾，並還原移轉進行中時新增的任何新備份檔案。
只有在您請求手動切換之後，移轉才會完成。
當您事先沒有完整備份鏈時，以及當您計劃在移轉進行中新增備份檔案後，請使用連續模式移轉。
針對需要資料追補的作用中工作負載，我們建議使用連續模式。
規劃在最多 30 天內完成單一 LRS 移轉作業。 當這段期間屆滿時，LRS 工作將被自動取消。
注意
當您移轉多個資料庫時，每個資料庫都必須位於自己的資料夾中。 針對每個資料庫個別啟動 LRS，指向 Azure Blob 儲存體容器和個別資料庫資料夾的完整 URI 路徑。 不支援資料庫資料夾內的巢狀資料夾。
LRS 的限制
如需詳細資訊，請檢閱 使用 LRS 時的限制 。