使用記錄轉送服務從 SQL Server 移轉資料庫 - Azure SQL 受控執行個體

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

本文說明如何使用記錄轉送服務 (LRS),將資料庫移轉至 Azure SQL 受控執行個體。 LRS 是以 SQL Server 記錄傳送技術為基礎的免費雲端服務,適用於 Azure SQL 受控執行個體。

支援的來源如下:

  • 虛擬機器上的 SQL Server
  • Amazon EC2 (Elastic Compute Cloud)
  • Amazon RDS (關聯式資料庫服務) for SQL Server
  • Google Compute Engine
  • 適用於 SQL Server 的 Cloud SQL - GCP (Google Cloud Platform)

必要條件

開始之前,請考慮 SQL Server 執行個體和 Azure 的下列需求。

SQL Server

請確定您符合下列 SQL Server 需求:

  • SQL Server 2008 版至 2022 版。
  • 您的 SQL Server 資料庫使用完整復原模式 (強制)。
  • 資料庫的完整備份 (一或多個檔案)。
  • 差異備份 (一或多個檔案)。
  • 記錄備份 (未分割的交易記錄檔)。
  • 針對 SQL Server 2008 到 2016 版,請在本機建立備份並手動上傳至您的 Azure Blob 儲存體帳戶。
  • 針對 SQL Server 2016 和更新版本,您可以在 Azure Blob 儲存體帳戶中直接建立備份

雖然備份時不需要啟用 CHECKSUM,但強烈建議您啟用它,以便加速還原作業的執行。

Azure

請確定您符合下列 Azure 需求:

  • PowerShell Az.SQL 模組 4.0.0 版或更新版本 (已安裝或透過 Azure Cloud Shell 存取)。
  • 已安裝 Azure CLI 2.42.0 版或更新版本。
  • 已佈建的 Azure Blob 儲存體容器。
  • 針對 Blob 儲存體容器產生具有讀取和列出權限的共用存取簽章 (SAS),或可存取容器的受控識別。
  • 使用一般檔案結構,將個別資料庫的備份檔案放置在儲存體帳戶的個別資料夾中 (強制)。 不支援資料庫資料夾中的巢狀資料夾。

Azure RBAC 權限

透過提供的用戶端執行 LRS 需要下列其中一個 Azure 角色型存取控制 (RBAC) 角色:

最佳作法

當您使用 LRS 時,請考慮下列最佳做法:

  • 執行 Data Migration Assistant,以驗證資料庫是否已準備好遷移至 SQL 受控執行個體。
  • 將完整和差異備份分割成多個檔案,而不是使用單一檔案。
  • 啟用備份壓縮以加快網路傳輸速度。
  • 使用 Cloud Shell 來執行 PowerShell 或 CLI 指令碼,因為它會一直更新為使用最新發行的 Cmdlet。
  • 設定維護期間,以允許在特定日期和時間排程系統更新。 此設定有助於更精準的預測資料庫移轉時間,因為系統升級可能會中斷進行中的移轉。
  • 規劃在最多 30 天內完成單一 LRS 移轉作業。 在此時間範圍內到期時,系統會自動取消 LRS 作業。
  • 若要加速資料庫還原作業,請在建立備份時啟用 CHECKSUM。 若未啟用 CHECKSUM,SQL 受控執行個體會對備份執行完整性檢查,造成花費更多還原時間。

SQL 受控執行個體的系統更新優先順序高於正在進行中的資料庫移轉。 在執行個體的系統更新期間,系統會暫停所有擱置的 LRS 移轉,且只有在套用更新之後才會繼續。 此系統行為可能會延長移轉時間,特別是在大型資料庫的情況下。

若要實現可預測資料庫移轉時間,請考慮設定維護期間來排程特定日期和時間的系統更新,並在指定的維護期間時間範圍之外執行和完成移轉作業。

重要

  • 直到移轉流程完成,您才能使用透過 LRS 還原的資料庫。
  • 在移轉期間,LRS 不支援唯讀存取資料庫。
  • 移轉完成後,移轉流程就完成,無法繼續處理其他差異備份。

移轉多個資料庫

如果使用相同的 Azure Blob 儲存體容器來移轉多個資料庫,您必須將不同資料庫的備份檔案放在容器的個別資料夾中。 單一資料庫的所有備份檔案都必須以一般檔案結構放在資料庫資料夾內,而資料夾不可以是巢狀結構。 不支援資料庫資料夾中的巢狀資料夾。

以下是使用 LRS 移轉多個資料庫時,Azure Blob 儲存體容器內的資料夾結構範例,這是移轉作業需要的結構。

-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>

-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>

-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure. 
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>

建立儲存體帳戶

您可以使用 Azure Blob 儲存體帳戶作為 SQL Server 執行個體與 SQL 受控執行個體部署之間備份檔案的中繼儲存體。 建立新的儲存體帳戶並在該儲存體帳戶中建立 Blob 容器:

  1. 建立儲存體帳戶
  2. 在儲存體帳戶中建立 Blob 容器

在防火牆後方設定 Azure 儲存體

系統支援使用在防火牆後方保護的 Azure Blob 儲存體,但需要額外的設定。 若要在開啟 Azure 防火牆的情況下啟用 Azure 儲存體的讀取/寫入權限,您必須使用 MI 子網路委派和儲存體服務端點,將 SQL 受控執行個體的子網路新增至儲存體帳戶的 vNet 防火牆規則。 儲存體帳戶和受控執行個體必須位於相同的區域,或兩個配對的區域。

如果您的 Azure 儲存體位於防火牆後方,您可能會在 SQL 受控執行個體錯誤記錄檔中看到下列訊息:

Audit: Storage access denied user fault. Creating an email notification:

這會產生電子郵件,通知您 SQL 受控執行個體的稽核程序無法將稽核記錄寫入儲存體帳戶。 如果您看到此錯誤或收到此電子郵件,請遵循本節中的步驟來設定防火牆。

若要設定防火牆,請遵循下列步驟:

  1. 移至 Azure 入口網站中的受控執行個體,然後選取子網路以開啟 [子網路] 頁面。

    Screenshot of the SQL managed instance Overview page of the Azure portal, with the subnet selected.

  2. 在 [子網路] 頁面上,選取子網路名稱以開啟子網路設定頁面。

    Screenshot of the SQL managed instance Subnet page of the Azure portal, with the subnet selected.

  3. 在 [子網路委派] 下方,從 [為服務委派子網路] 下拉式功能表中選擇 Microsoft.Sql/managedInstances。 等候約一小時讓權限傳播出去,然後在 [服務端點] 下方,從 [服務] 下拉式清單中選擇 Microsoft.Storage

    Screenshot of the SQL managed instance Subnet configuration page of the Azure portal.

  4. 接下來,在 Azure 入口網站中移至您的儲存體帳戶,在 [安全性 + 網路] 下方選取 [網路],然後選擇 [防火牆和虛擬網路] 索引標籤。

  5. 在儲存體帳戶的 [防火牆和虛擬網路] 索引標籤上,選擇 [+新增現有的虛擬網路] 以開啟 [新增網路] 頁面。

    Screenshot of the Storage Account Networking page of the Azure portal, with Add existing virtual network selected.

  6. 從下拉式功能表選取適當的訂用帳戶、虛擬網路和受控執行個體子網路,然後選取 [新增],將 SQL 受控執行個體的虛擬網路新增至儲存體帳戶。

驗證 Blob 儲存體帳戶

使用 SAS 權杖或受控識別來存取 Azure Blob 儲存體帳戶。

警告

您不能在相同的儲存體帳戶中同時使用 SAS 權杖和受控識別。 您可以使用 SAS 權杖受控識別其中一項,但不能同時使用兩者。

為 LRS 產生 Blob 儲存體 SAS 驗證權杖

使用 SAS 權杖存取 Azure Blob 儲存體帳戶。

您可以使用 Azure Blob 儲存體帳戶作為 SQL Server 執行個體與 SQL 受控執行個體部署之間備份檔案的中繼儲存體。 為 LRS 產生只具有讀取和列出權限的 SAS 驗證權杖。 此權杖可讓 LRS 存取 Blob 儲存體帳戶,以及使用備份檔案還原到受控執行個體。

請遵循下列步驟來產生權杖:

  1. 在 Azure 入口網站中,開啟 [儲存體總管]。

  2. 展開 [Blob 容器]。

  3. 以滑鼠右鍵按一下 Blob 容器,然後選取 [取得共用存取簽章]。

    Screenshot that shows selections for generating a SAS authentication token.

  4. 選取權杖到期的時間範圍。 確定權杖在移轉期間有效。

  5. 選取權杖的時區:UTC 或本地時間。

    重要

    權杖和受控執行個體的時區可能不相符。 將時區納入考量,確定 SAS 權杖有適當的時效性。 若要考慮時區差異,請設定移轉時間範圍開始之前的有效 FROM 值,以及預期移轉完成後的 TO 值。

  6. 只選取 [讀取] 和 [列出] 權限。

    重要

    請勿選取其他任何權限。 否則 LRS 不會啟動。 此為刻意的安全性需求。

  7. 選取 [建立]。

    Screenshot that shows selections for SAS token expiration, time zone, and permissions, along with the Create button.

將會以您指定的時效性產生 SAS 驗證。 您需要 URI 版本的權杖,如下列螢幕擷取畫面所示:

Screenshot that shows an example of the URI version of a SAS token.

注意

目前不支援透過定義預存存取原則所設權限建立的 SAS 權杖。 請遵循本程序中的指示,手動指定 SAS 權杖的讀取列出權限。

從 SAS 權杖複製參數

使用 SAS 權杖或受控識別來存取 Azure Blob 儲存體帳戶。

使用 SAS 權杖來啟動 LRS 之前,您需要了解其結構。 所產生 SAS 權杖的 URI 包含兩個部分,以問號 (?) 分隔,如下列範例所示:

Example URI for a generated SAS token for Log Replay Service.

https:// 開始到問號 (?) 的第一個部分,用於提供給 LRS 作為輸入的 StorageContainerURI 參數。 其會提供儲存資料庫備份檔案的資料夾資訊給 LRS。

第二個部分是 StorageContainerSasToken 參數,從問號 (?) 之後一直到字串結尾為止。 此部分是實際簽署的驗證權杖,在指定期間內有效。 此部分不一定要如範例所示以 sp= 開頭。 您的案例可能有所不同。

複製參數,如下所示:

  1. 複製權杖的第一個部分,從 https:// 開始,最多到 (但不包含) 問號 (?)。 啟動 LRS 時,請在 PowerShell 或 Azure CLI 中使用此部分作為 StorageContainerUri 參數。

    Screenshot that shows where to copy the first part of the token.

  2. 複製權杖的第二個部分,從問號 (?) 之後一直到字串結尾為止。 啟動 LRS 時,請在 PowerShell 或 Azure CLI 中使用此部分作為 StorageContainerSasToken 參數。

    Screenshot that shows where to copy the second part of the token.

注意

複製權杖的任一部分時,請勿包含問號 (?)。

驗證受控執行個體儲存體存取權

驗證受控執行個體是否可以存取您的 Blob 儲存體帳戶。

首先,將任何資料庫備份 (例如 full_0_0.bak) 上傳至 Azure Blob 儲存體容器。

接下來,連線到受控執行個體,然後執行範例測試查詢,以判斷受控執行個體是否可以存取容器中的備份。

如果您使用 SAS 權杖向儲存體帳戶進行驗證,請使用您的 SAS 權杖取代 <sastoken>,並在執行個體上執行下列查詢:

CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE' 
, SECRET = '<sastoken>' 

RESTORE HEADERONLY 
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak' 

將備份上傳至 Blob 儲存體帳戶

當您的 Blob 容器已備妥且您已確認受控執行個體可以存取容器時,就可以開始將備份上傳至 Blob 儲存體帳戶。 您可以:

  • 將備份複製到 Blob 儲存體帳戶。
  • 如果您的環境允許,請使用 BACKUP TO URL 命令,直接從 SQL Server 備份到 Blob 儲存體帳戶 (從 SQL Server 2012 版 SP1 CU2 和 SQL Server 2014 開始)。

將現有備份複製到 Blob 儲存體帳戶

如果您使用的是舊版 SQL Server,或您的環境不支援直接備份至 URL,請像平常一樣,在 SQL Server 執行個體上建立備份,然後將備份複製到 Blob 儲存體帳戶。

在 SQL Server 執行個體上建立備份

將您要遷移的資料庫設定為完整復原模式,以允許記錄備份。

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master
ALTER DATABASE SampleDB
SET RECOVERY FULL
GO

若要在本機儲存體上手動建立資料庫的完整備份、差異備份和記錄備份,請使用下列範例 T-SQL 指令碼。 CHECKSUM 非必要項目,但建議使用。

下列範例會在本機磁碟建立完整資料庫備份:

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

下列範例會在本機磁碟建立差異備份:

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

下列範例會在本機磁碟建立交易記錄備份:

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
TO DISK='C:\BACKUP\SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
GO

將備份複製到 Blob 儲存體帳戶

備份準備就緒之後,您想要使用 LRS 開始將資料庫移轉至受控執行個體,可以使用下列方法將現有的備份複製到 Blob 儲存體帳戶:

注意

若要使用相同的 Azure Blob 儲存體容器來移轉多個資料庫,請將各個資料庫的所有備份檔案放在容器內的個別資料夾中。 每個資料庫資料夾均使用一般檔案結構。 不支援資料庫資料夾中的巢狀資料夾。

直接備份至 Blob 儲存體帳戶

如果您使用的是支援的 SQL Server 版本 (從 SQL Server 2012 SP1 CU2 和 SQL Server 2014 開始),且貴公司和網路原則允許,則可以使用原生 SQL Server BACKUP TO URL 選項,從 SQL Server 直接備份到 Blob 儲存體帳戶。 如果您可以使用 BACKUP TO URL,則不需要備份到本機儲存體,再上傳至 Blob 儲存體帳戶。

當您原生備份直接儲存到 Blob 儲存體帳戶時,您必須向儲存體帳戶進行驗證。

使用下列命令建立認證,將 SAS 權杖匯入 SQL Server 執行個體:

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',  
SECRET = '<SAS_TOKEN>';  

如需使用 SAS 權杖的詳細指示,請檢閱教學課程使用 Azure Blob 儲存體搭配 SQL Server

建立認證以使用 Blob 儲存體驗證 SQL Server 執行個體之後,您可以使用 BACKUP TO URL 命令,直接備份到儲存體帳戶。 建議使用 CHECKSUM,但並非必要。

下列範例會在 URL 建立完整資料庫備份:

-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

下列範例會在 URL 建立差異資料庫備份:

-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'  
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

下列範例會在 URL 建立交易記錄備份:

-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'  
WITH COMPRESSION, CHECKSUM

登入 Azure 並選取訂用帳戶

使用下列 PowerShell Cmdlet 來登入 Azure:

Login-AzAccount

使用下列 PowerShell Cmdlet,選取受控執行個體所在的訂用帳戶:

Select-AzSubscription -SubscriptionId <subscription ID>

開始移轉

啟動 LRS 以開始移轉。 您可以選擇自動完成連續模式來啟動此服務。

使用自動完成模式時,還原最後一個指定的備份檔案後,移轉就會自動結束。 此選項需要事先提供整個備份鏈結,並上傳至 Blob 儲存體帳戶。 移轉進行期間,不允許新增備份檔案。 使用此選項時,start 命令需要指定最後一個備份檔案的檔案名稱。 針對不需要資料追補的被動工作負載,我們建議使用此模式。

當您使用連續模式時,服務會持續掃描 Azure Blob 儲存體資料夾,並還原移轉進行中時新增的任何新備份檔案。 只有在要求手動完全移轉之後,移轉才會完成。 當您事先沒有完整備份鏈結時,以及當您計劃在移轉進行中新增備份檔案後,您需要使用連續模式移轉。 針對需要資料追補的作用中工作負載,我們建議使用此模式。

規劃在最多 30 天內完成單一 LRS 移轉作業。 經過這一段時間後將自動取消 LRS 作業。

注意

在您移轉多個資料庫時,必須針對每個資料庫分別啟動 LRS,並指向 Azure Blob 儲存體容器和個別資料庫資料夾的完整 URI 路徑。

以自動完成模式啟動 LRS

請確定整個備份鏈結已上傳至 Azure Blob 儲存體帳戶。 此選項不允許在移轉進行期間新增新的備份檔案。

若要以自動完成模式啟動 LRS,請使用 PowerShell 或 Azure CLI 命令。 使用 -LastBackupName 參數指定最後一個備份檔案名稱。 最後一個指定的備份檔案還原完成之後,服務會自動起始完全移轉。

使用 SAS 權杖或受控識別,從儲存體帳戶還原資料庫。

重要

  • 在您以自動完成模式開始移轉之前,請確定整個備份鏈結已上傳至 Azure Blob 儲存體帳戶。 此模式不允許在移轉進行期間新增新的備份檔案。
  • 請確定您已正確指定最後一個備份檔案,而且之後未上傳其他檔案。 如果系統偵測到在最後一個指定備份檔案後還有其他備份檔案,移轉將會失敗。

下列 PowerShell 範例會使用 SAS 權杖,以自動完成模式啟動 LRS:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

下列 Azure CLI 範例會使用 SAS 權杖,以自動完成模式啟動 LRS:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

以連續模式啟動 LRS

請確定您已將初始備份鏈結上傳至 Azure Blob 儲存體帳戶。

重要

在連續模式中啟動 LRS 之後,您就可以將新的記錄和差異備份新增至儲存體帳戶,直到手動完全移轉為止。 起始手動完全移轉之後,就無法新增或還原任何其他差異檔案。

下列 PowerShell 範例會使用 SAS 權杖,以連續模式啟動 LRS:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

下列 Azure CLI 範例會以連續模式啟動 LRS:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

編寫移轉作業的指令碼

以連續模式啟動 LRS 的 PowerShell 和 Azure CLI 用戶端會同步執行。 在此模式中,PowerShell 和 Azure CLI 會等待 API 回應並報告成功或失敗,然後才會啟動作業。

在這段等候期間,命令不會將控制權還給命令提示字元。 如果您將移轉體驗編寫成指令碼,而且需要 LRS start 命令立即歸還控制權,以繼續執行指令碼的其餘部分,您可以使用 -AsJob 切換參數以背景作業形式執行 PowerShell。 例如:

$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob

當您啟動背景作業時,即使作業需要很久才完成,也會立即傳回作業物件。 工作執行時,您可以在工作階段中繼續工作,而不需中斷。 如需以背景作業形式執行 PowerShell 的詳細資訊,請參閱 PowerShell Start-Job 文件。

同樣地,若要在 Linux 上以背景程序形式啟動 Azure CLI 命令,請在 LRS start 命令結尾加上 & 符號:

az sql midb log-replay start <required parameters> &

監視移轉進度

Az.SQL 4.0.0 和更新版本提供詳細的進度報告。 如需範例輸出,請檢閱受控資料庫還原詳細資料 - 取得

若要透過 PowerShell 監視移轉過程,請使用下列命令:

Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

若要透過 Azure CLI 監視移轉過程,請使用下列命令:

az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb

停止移轉 (選用)

如果需要停止移轉,請使用 PowerShell 或 Azure CLI。 停止移轉會刪除受控執行個體上正在還原的資料庫,因此無法繼續移轉。

若要透過 PowerShell 停止移轉流程,請使用下列命令:

Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

若要透過 Azure CLI 停止移轉流程,請使用下列命令:

az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb

完成移轉 (連續模式)

如果您以連續模式啟動 LRS,請確定您的應用程式和 SQL Server 工作負載已停止,避免產生任何新的備份檔案。 請確定 SQL Server 執行個體的最後一個備份已上傳至 Azure Blob 儲存體帳戶。 監視受控執行個體上的還原進度,並確定已還原最後一個記錄檔結尾備份。

在受控執行個體上還原最後一個記錄檔結尾備份時,請起始手動完全移轉以完成移轉。 完全移轉完成後,資料庫就可在受控執行個體上供讀取和寫入存取使用。

若要透過 PowerShell 以 LRS 連續模式完成移轉流程,請使用下列命令:

Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"

若要透過 Azure CLI 以 LRS 連續模式完成移轉流程,請使用下列命令:

az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"

針對 LRS 問題進行疑難排解

啟動 LRS 之後,請使用下列其中一個監視 Cmdlet 來查看作業狀態:

  • 若為 PowerShell:get-azsqlinstancedatabaselogreplay
  • 若為 Azure CLI:az_sql_midb_log_replay_show

如果 LRS 在一段時間後無法啟動,而且發生錯誤,請檢查最常見的問題:

  • 受控執行個體上的現有資料庫與您嘗試從 SQL Server 執行個體移轉的資料庫是否同名? 重新命名其中一個資料庫,即可解決此衝突。
  • 授與 SAS 權杖的權限是否有讀取和列出?
  • 您是否在 LRS 的 SAS 權杖中複製問號 (?) 後面的部分,內容就像 sv=2020-02-10...? 
  • 對於開始和完成移轉的時間範圍,SAS 權杖有效時間是否合適? 由於 SQL 受控執行個體部署和 SAS 權杖使用的時區不同,可能會出現不相符的情形。 嘗試重新產生 SAS 權杖,並擴大目前日期前後的權杖時效範圍。
  • 當平行啟動多個 Log Replay 還原時,以相同的儲存體容器為目標,請確定會針對每個還原作業提供相同的有效 SAS 權杖。
  • 資料庫名稱、資源群組名稱和受控執行個體名稱的拼字是否正確?
  • 如果您以自動完成模式啟動 LRS,指定給最後一個備份檔案的檔案名稱是否有效?
  • 備份 URI 路徑是否包含關鍵字 backupbackups? 重新命名使用 backupbackups 作為保留的關鍵字的容器或資料夾。

下一步