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