使用記錄轉送服務從 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)
必要條件
重要
- 將資料庫移轉至 業務關鍵 服務層級之前,請考慮這些限制,不適用於一般用途服務層級。
- 直到移轉流程完成,您才能使用透過 LRS 還原的資料庫。
- 在移轉期間,LRS 不支援唯讀存取資料庫。
- 移轉完成後,移轉流程就完成,無法繼續處理其他差異備份。
開始之前,請考慮本節中 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
Read
記憶體容器所產生的共用存取簽章 (SAS) 安全性令牌List
,或可存取容器的受控識別。 授與超過Read
和List
的許可權會導致 LRS 失敗。 - 使用一般檔案結構,將個別資料庫的備份檔案放置在儲存體帳戶的個別資料夾中 (強制)。 不支援資料庫資料夾中的巢狀資料夾。
Azure RBAC 權限
透過提供的用戶端執行 LRS 需要下列其中一個 Azure 角色型存取控制 (RBAC) 角色:
- SQL 受控執行個體參與者角色
- 具有下列權限的角色:
Microsoft.Sql/managedInstances/databases/*
最佳作法
當您使用 LRS 時,請考慮下列最佳做法:
- 執行 Data Migration Assistant,以驗證資料庫是否已準備好遷移至 SQL 受控執行個體。
- 將完整和差異備份分割成多個檔案,而不是使用單一檔案。
- 啟用備份壓縮以加快網路傳輸速度。
- 使用 Cloud Shell 來執行 PowerShell 或 CLI 指令碼,因為它會一直更新為使用最新發行的 Cmdlet。
- 設定 維護期間 ,讓系統更新排程在特定日期和時間移轉時段之外,以避免延遲或中斷移轉。
- 規劃在最多 30 天內完成單一 LRS 移轉作業。 在此時間範圍內到期時,系統會自動取消 LRS 作業。
- 若要防止意外移轉損毀的資料庫,以及加快資料庫還原的速度,請在進行備份時啟用
CHECKSUM
。 雖然 SQL 受管理執行個體 在沒有 的情況下對備份CHECKSUM
執行基本完整性檢查,但無法保證攔截所有形式的損毀。 使用CHECKSUM
進行備份是確保還原至 SQL 受管理執行個體 備份不會損毀的唯一方法。 備份的基本完整性檢查不會CHECKSUM
增加資料庫的還原時間。 - 移轉至 業務關鍵 服務層級時,在完全移轉之後,考慮資料庫可用性長時間延遲,而資料庫會植入次要複本。 對於停機需求最少的大型資料庫,請考慮先移轉至一般用途服務層級,然後再升級至 業務關鍵 服務層級,或使用 受控執行個體 鏈接來遷移您的數據。
- 上傳數千個資料庫檔案以還原可能會導致過多的移轉時間,甚至失敗。 將資料庫合併成較少的檔案,以加速移轉程式,並確保其成功。
- 若要將切換時間縮短至最低並降低失敗的風險,請確保您的最後備份盡可能小。
設定維護期間
SQL 受控執行個體的系統更新優先順序高於正在進行中的資料庫移轉。
移轉會根據服務層級而受到不同的影響:
- 在一般用途服務層級中,所有擱置的 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 容器:
- 建立儲存體帳戶。
- 在儲存體帳戶中建立 Blob 容器。
在防火牆後方設定 Azure 儲存體
系統支援使用在防火牆後方保護的 Azure Blob 儲存體,但需要額外的設定。 若要啟用已開啟 Azure 防火牆 Azure 儲存體 的讀取/寫入許可權,您必須使用MI子網委派和記憶體服務端點,將 SQL 受控實例的子網新增至記憶體帳戶的虛擬網路防火牆規則。 儲存體帳戶和受控執行個體必須位於相同的區域,或兩個配對的區域。
如果您的 Azure 記憶體位於防火牆後方,您可能會在 SQL 受控實例錯誤記錄檔中看到下列訊息:
Audit: Storage access denied user fault. Creating an email notification:
這會產生電子郵件,通知您 SQL 受控執行個體的稽核程序無法將稽核記錄寫入儲存體帳戶。 如果您看到此錯誤或收到此電子郵件,請遵循本節中的步驟來設定防火牆。
若要設定防火牆,請遵循下列步驟:
移至 Azure 入口網站中的受控執行個體,然後選取子網路以開啟 [子網路] 頁面。
在 [子網路] 頁面上,選取子網路名稱以開啟子網路設定頁面。
在 [子網路委派] 下方,從 [為服務委派子網路] 下拉式功能表中選擇 Microsoft.Sql/managedInstances。 等候約一小時讓權限傳播出去,然後在 [服務端點] 下方,從 [服務] 下拉式清單中選擇 Microsoft.Storage。
接下來,在 Azure 入口網站中移至您的儲存體帳戶,在 [安全性 + 網路] 下方選取 [網路],然後選擇 [防火牆和虛擬網路] 索引標籤。
在儲存體帳戶的 [防火牆和虛擬網路] 索引標籤上,選擇 [+新增現有的虛擬網路] 以開啟 [新增網路] 頁面。
從下拉式功能表選取適當的訂用帳戶、虛擬網路和受控執行個體子網路,然後選取 [新增],將 SQL 受控執行個體的虛擬網路新增至儲存體帳戶。
驗證 Blob 儲存體帳戶
使用 SAS 權杖或受控識別來存取 Azure Blob 儲存體帳戶。
警告
您不能在相同的儲存體帳戶中同時使用 SAS 權杖和受控識別。 您可以使用 SAS 權杖或受控識別其中一項,但不能同時使用兩者。
為 LRS 產生 Blob 儲存體 SAS 驗證權杖
使用 SAS 權杖存取 Azure Blob 儲存體帳戶。
您可以使用 Azure Blob 儲存體帳戶作為 SQL Server 執行個體與 SQL 受控執行個體部署之間備份檔案的中繼儲存體。 為 LRS 產生只具有讀取和列出權限的 SAS 驗證權杖。 此權杖可讓 LRS 存取 Blob 儲存體帳戶,以及使用備份檔案還原到受控執行個體。
請遵循下列步驟來產生權杖:
在 Azure 入口網站中,開啟 [儲存體總管]。
展開 [Blob 容器]。
以滑鼠右鍵按一下 Blob 容器,然後選取 [取得共用存取簽章]。
選取權杖到期的時間範圍。 確定權杖在移轉期間有效。
選取權杖的時區:UTC 或本地時間。
重要
權杖和受控執行個體的時區可能不相符。 將時區納入考量,確定 SAS 權杖有適當的時效性。 若要考慮時區差異,請設定移轉時間範圍開始之前的有效 FROM 值,以及預期移轉完成後的 TO 值。
只選取 [讀取] 和 [列出] 權限。
重要
請勿選取其他任何權限。 否則 LRS 不會啟動。 此為刻意的安全性需求。
選取 [建立]。
將會以您指定的時效性產生 SAS 驗證。 您需要 URI 版本的權杖,如下列螢幕擷取畫面所示:
注意
目前不支援透過定義預存存取原則所設權限建立的 SAS 權杖。 請遵循本程序中的指示,手動指定 SAS 權杖的讀取和列出權限。
從 SAS 權杖複製參數
使用 SAS 權杖或受控識別來存取 Azure Blob 儲存體帳戶。
使用 SAS 權杖來啟動 LRS 之前,您需要了解其結構。 所產生 SAS 權杖的 URI 包含兩個部分,以問號 (?
) 分隔,如下列範例所示:
從 https://
開始到問號 (?
) 的第一個部分,用於提供給 LRS 作為輸入的 StorageContainerURI
參數。 其會提供儲存資料庫備份檔案的資料夾資訊給 LRS。
第二個部分是 ?
參數,從問號 (StorageContainerSasToken
) 之後一直到字串結尾為止。 此部分是實際簽署的驗證權杖,在指定期間內有效。 此部分不一定要如範例所示以 sp=
開頭。 您的案例可能有所不同。
複製參數,如下所示:
複製權杖的第一個部分,從
https://
開始,最多到 (但不包含) 問號 (?
)。 啟動 LRS 時,請在 PowerShell 或 Azure CLI 中使用此部分作為StorageContainerUri
參數。複製權杖的第二個部分,從問號 (
?
) 之後一直到字串結尾為止。 啟動 LRS 時,請在 PowerShell 或 Azure CLI 中使用此部分作為StorageContainerSasToken
參數。
注意
複製權杖的任一部分時,請勿包含問號 (?
)。
驗證受控執行個體儲存體存取權
驗證受控執行個體是否可以存取您的 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 儲存體帳戶:
- 下載並安裝 AzCopy。
- 下載並安裝 Azure 儲存體總管。
- 使用 Azure 入口網站中的儲存體總管。
注意
若要使用相同的 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命令 Get-AzSqlInstanceOperation 或使用 Azure CLI 命令 az sql mi op show。
停止移轉 (選用)
如果需要停止移轉,請使用 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 還原的資料庫。
- 在移轉過程中,無法在 SQL 受控執行個體上唯讀存取正在移轉的資料庫。
- 移轉完成後,移轉流程就完成,無法繼續處理其他差異備份。
- LRS 僅支援資料庫
.bak
、.log
和.diff
檔案。 不支援 Dacpac 和 bacpac 檔案。 - 您必須設定 維護期間 ,以排程特定日期和時間的系統更新。 規劃在排程維護期間外執行和完成移轉。
- 不使用
CHECKSUM
資料庫備份:- 可能會移轉損毀的資料庫。
- 還原所需的時間比已啟用的資料庫備份
CHECKSUM
還要長。
- LRS 使用的共用存取簽章 (SAS) 令牌必須針對整個 Azure Blob 儲存體 容器產生,而且它必須具有
Read
和List
許可權。 例如,如果您授與Read
、List
和Write
許可權,LRS 因為額外的Write
許可權而無法啟動。 - 不支援使用透過定義預存存取原則所設權限建立的 SAS 權杖。 請遵循本文中的指示,手動指定 SAS 權杖的讀取和列出權限。
- 將個別資料庫的備份檔案必須以一般檔案結構,放在 Blob 儲存體帳戶上的單獨資料夾中。 不支援資料庫資料夾中的巢狀資料夾。
- 如果您正在使用自動完成模式,則必須事先在 Blob 儲存體帳戶上使用整個備份鏈結。 您無法在自動完成模式中新增備份檔案。 如果您需要在移轉過程中新增備份檔案,請使用連續模式。
- 針對指向包含個別資料庫檔案夾的完整 URI 路徑,每個資料庫必須個別啟動 LRS。
- 備份 URI 路徑、容器名稱或資料夾名稱不應包含
backup
或backups
,因為這些是保留關鍵詞。 - 當平行啟動多個 Log Replay 還原時,以相同的儲存體容器為目標,請確定會針對每個還原作業提供相同的有效 SAS 權杖。
- LRS 支援每一個受控執行個體最多有 100 個同時還原流程。
- 單一 LRS 作業最多可以執行 30 天,之後會自動取消。
- Azure 儲存體帳戶雖然可以在防火牆後方使用,但需要額外的設定,而且儲存體帳戶和受控執行個體必須位於相同區域或兩個配對的區域。 請檢閱設定防火牆以深入了解。
- 您可以平行還原的資料庫數目上限是每個單一訂用帳戶 200 個。 在某些情況下,可以藉由開啟支援票證來提高此限制。
- 上傳數千個資料庫檔案以還原可能會導致過多的移轉時間,甚至失敗。 將資料庫合併成較少的檔案,以加速移轉程式,並確保其成功。
- 在移轉程序的開始和結束階段,有兩種情況會發生:如果出現故障轉移,則會中止移轉,而必須從頭手動重新啟動移轉作業,因為資料庫已從 SQL 受控實例中移除。
- 如果在第一次啟動移轉作業時,第一次完整資料庫備份正在還原至 SQL 受控實例時發生故障轉移,則必須從頭手動重新啟動移轉作業。
- 如果在起始移轉之後發生移轉作業故障轉移,則必須從頭手動重新啟動移轉作業。 請確保最後一個備份文件盡可能小,以將切換時間降到最低,並降低在切換過程中發生故障轉移的風險。
注意
如果您需要在移轉期間進行唯讀存取資料庫,執行移轉的時間範圍更長,而且停機時間最少,請考慮使用 受控執行個體 連結功能作為建議的移轉解決方案。
移轉至 業務關鍵 服務層級的限制
在移轉至 業務關鍵 服務層級中的 SQL 受管理執行個體 時,請考慮下列限制:
- 移轉大型資料庫時,當資料庫植入至 業務關鍵 服務層級的次要複本時,資料庫在完全移轉之後,可能會有相當多的停機時間。 因應措施會列在較長的 完全移轉 區段中。
- 如果移轉因非計劃性故障轉移、系統更新或安全性修補程式而中斷,則移轉會從頭開始自動重新啟動,因此很難規劃可預測的移轉,而不會意外發生最後一刻。
重要
只有在移轉至 業務關鍵 服務層級,而不是移轉至一般用途服務層級時,才適用這些限制。
業務關鍵 服務層級中較長的完全移轉
如果您要移轉至 業務關鍵 服務層級中的 SQL 受管理執行個體,請在將資料庫植入次要複本時,考慮將資料庫上線到主要複本上的延遲。 對於較大的資料庫來說,這尤其如此。
移轉至 業務關鍵 服務層級中的 SQL 受管理執行個體 所需的時間比一般用途服務層級還要長。 在完全移轉至 Azure 之後,資料庫將無法使用,直到從主要複本植入到三個次要複本為止,這可能需要很長的時間,視資料庫大小而定。 資料庫越大,次要複本的植入時間越長,可能最多需要數小時的時間。
如果資料庫在完全移轉完成後立即可供使用,請考慮下列因應措施:
- 先移轉至一般用途服務層級,然後升級至 業務關鍵 服務層級。 升級您的服務層級是一項在線作業,可將資料庫保持在在線狀態,直到進行短暫的故障轉移,作為升級作業的最後一個步驟。
- 使用在線移轉至 業務關鍵 實例的 受控執行個體 連結,而不需要等候資料庫在完全移轉之後可供使用。
針對 LRS 問題進行疑難排解
啟動 LRS 之後,請使用下列其中一個監視 Cmdlet 來查看作業狀態:
- 若為 PowerShell:
get-azsqlinstancedatabaselogreplay
- 若為 Azure CLI:
az_sql_midb_log_replay_show
若要檢閱失敗作業的詳細資料:
- 針對 PowerShell:Get-AzSqlInstanceOperation
- 針對 Azure CLI:az sql mi op show
如果 LRS 在一段時間後無法啟動,而且發生錯誤,請檢查最常見的問題:
- 受控執行個體上的現有資料庫與您嘗試從 SQL Server 執行個體移轉的資料庫是否同名? 重新命名其中一個資料庫,即可解決此衝突。
- 授與 SAS 權杖的權限是否只有讀取和列出? 授與超過
Read
和List
的許可權會導致 LRS 失敗。 - 您是否在 LRS 的 SAS 權杖中複製問號 (
?
) 後面的部分,內容就像sv=2020-02-10...
? - 對於開始和完成移轉的時間範圍,SAS 權杖有效時間是否合適? 由於 SQL 受控執行個體部署和 SAS 權杖使用的時區不同,可能會出現不相符的情形。 嘗試重新產生 SAS 權杖,並擴大目前日期前後的權杖時效範圍。
- 當平行啟動多個 Log Replay 還原時,以相同的儲存體容器為目標,請確定會針對每個還原作業提供相同的有效 SAS 權杖。
- 資料庫名稱、資源群組名稱和受控執行個體名稱的拼字是否正確?
- 如果您以自動完成模式啟動 LRS,指定給最後一個備份檔案的檔案名稱是否有效?
- 備份 URI 路徑是否包含關鍵字
backup
或backups
? 重新命名使用backup
或backups
作為保留的關鍵字的容器或資料夾。