Migrace databází z SQL Serveru pomocí služby Přehrání protokolu – Azure SQL Managed Instance

Platí pro: Azure SQL Managed Instance

Tento článek vysvětluje, jak migrovat databáze do služby Azure SQL Managed Instance pomocí služby LRS (Log Replay Service). LRS je bezplatná cloudová služba, která je k dispozici pro Azure SQL Managed Instance na základě technologie přesouvání protokolů SQL Serveru.

Jsou podporovány následující zdroje:

• SQL Server na virtuálních počítačích
• Amazon EC2 (Elastic Compute Cloud)
• Amazon RDS (relační databázová služba) pro SQL Server
• Google Compute Engine
• Cloud SQL pro SQL Server – GCP (Google Cloud Platform)

Požadavky

Než začnete, zvažte následující požadavky pro instanci SQL Serveru i Azure. Pečlivě si projděte části omezení a osvědčených postupů , abyste zajistili úspěšnou migraci.

Před migrací databází na úroveň služby Pro důležité obchodní informace zvažte tato omezení, která neplatí pro úroveň služby Pro obecné účely.

SQL Server

Ujistěte se, že splňujete následující požadavky pro SQL Server:

• SQL Server verze 2008 až 2022.
• Vaše databáze SQL Serveru používá úplný model obnovení (povinné).
• Úplná záloha databází (jeden nebo více souborů)
• Rozdílové zálohování (jeden nebo více souborů)
• Zálohování protokolů (není rozděleno pro soubor transakčního protokolu).
• V případě SQL Serveru verze 2008 až 2016 vytvořte zálohu místně a ručně ji nahrajte do účtu služby Azure Blob Storage.
• Pro SQL Server 2016 a novější můžete provést zálohování přímo do účtu služby Azure Blob Storage.
• I když není CHECKSUM potřeba povolit zálohování, důrazně doporučujeme zabránit neúmyslné migraci poškozené databáze a zrychlit operace obnovení.

Azure

Ujistěte se, že splňujete následující požadavky pro Azure:

• PowerShell Az.SQL modul verze 4.0.0 nebo novější (nainstalovaný nebo přístupný přes Azure Cloud Shell).
• Azure CLI verze 2.42.0 nebo novější (nainstalované).
• Zřízený kontejner Azure Blob Storage.
• Token zabezpečení sdíleného přístupového podpisu (SAS) s oprávněními Read List vygenerovanými pro kontejner Blob Storage nebo spravovanou identitu, která má přístup k kontejneru. Udělení více oprávnění než Read a List způsobí selhání LRS.
• Záložní soubory pro jednotlivé databáze umístěte do samostatné složky v účtu úložiště pomocí ploché struktury souborů (povinné). Vnoření složek do databázových složek se nepodporuje.

Oprávnění Azure RBAC

Spuštění LRS prostřednictvím poskytnutých klientů vyžaduje jednu z následujících rolí řízení přístupu na základě role (RBAC) Azure:

• Role přispěvatele spravované instance SQL
• Role s následujícím oprávněním: Microsoft.Sql/managedInstances/databases/*

Osvědčené postupy

Při používání LRS zvažte následující osvědčené postupy:

• Spuštěním Pomocník s migrací dat ověřte, že jsou vaše databáze připravené k migraci do služby SQL Managed Instance.
• Rozdělte úplné a rozdílové zálohy na několik souborů místo použití jednoho souboru.
• Povolte kompresi záloh, což pomůže síťový přenos urychlit.
• Ke spouštění skriptů PowerShellu nebo rozhraní příkazového řádku použijte Cloud Shell, protože se vždy aktualizuje tak, aby používal nejnovější vydané rutiny.
• Nakonfigurujte časové období údržby, aby aktualizace systému byly naplánovány v konkrétní den a čas mimo časové období migrace, aby se zabránilo zpoždění nebo přerušení migrace.
• Naplánujte dokončení jedné úlohy migrace LRS do maximálně 30 dnů. Při vypršení tohoto časového rámce se úloha LRS automaticky zruší.
• Pokud chcete zabránit neúmyslné migraci poškozené databáze a zrychlit obnovení databáze, povolte CHECKSUM při zálohování zálohy. Přestože spravovaná instance SQL provádí základní kontrolu integrity záloh bez CHECKSUM, zachycení všech forem poškození není zaručeno. Vytváření záloh CHECKSUM je jediným způsobem, jak zajistit, aby záloha obnovená do služby SQL Managed Instance nebyla poškozena. Základní kontrola integrity záloh bez CHECKSUM zvýšení doby obnovení databáze.
• Při migraci na úroveň služby Pro důležité obchodní informace přistupujte k delšímu zpoždění dostupnosti databáze po přímé migraci, zatímco databáze se odsadí do sekundárních replik. Pro zvláště velké databáze s minimálními požadavky na prostoje zvažte nejprve migraci na úroveň služby Pro obecné účely a pak upgradujte na úroveň služby Pro důležité obchodní informace nebo pomocí odkazu na spravovanou instanci k migraci dat.
• Nahrání tisíců databázových souborů k obnovení může vést k nadměrným časům migrace a dokonce i selháním. Konsolidovat databáze do menšího počtu souborů, aby se urychlil proces migrace, a zajistit, že je úspěšný.

Konfigurace časového období údržby

Aktualizace systému pro spravovanou instanci SQL mají přednost před probíhajícími migracemi databází.

Migrace se liší podle úrovně služby:

• Na úrovni služby Pro obecné účely se všechny čekající migrace LRS pozastaví a obnoví až po instalaci aktualizace. Toto chování systému může prodloužit dobu migrace, zejména pro velké databáze.
• Na úrovni služby Pro důležité obchodní informace se všechny čekající migrace LRS zruší a po instalaci aktualizace se automaticky restartují. Toto chování systému může prodloužit dobu migrace, zejména pro velké databáze.

Pokud chcete dosáhnout předvídatelného času pro migrace databází, zvažte konfiguraci časového období údržby pro naplánování aktualizací systému pro určitý den a čas a spuštění a dokončení úloh migrace mimo určený časový rámec údržby. Například pro migraci, která začíná v pondělí, nakonfigurujte vlastní časové období údržby v neděli, aby bylo možné migraci dokončit nejvíce času.

Konfigurace časového období údržby se nevyžaduje, ale důrazně se doporučuje pro velké databáze.

Migrace více databází

Pokud migrujete více databází pomocí stejného kontejneru Azure Blob Storage, musíte záložní soubory pro různé databáze umístit do samostatných složek uvnitř kontejneru. Všechny záložní soubory pro jednu databázi musí být umístěny ve struktuře plochých souborů uvnitř složky databáze a složky nelze vnořit. Vnoření složek do databázových složek se nepodporuje.

Tady je příklad struktury složek uvnitř kontejneru Azure Blob Storage, struktury, která se vyžaduje k migraci více databází pomocí LRS.

-- 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>

Vytvoření účtu úložiště

Účet Služby Azure Blob Storage použijete jako zprostředkující úložiště pro záložní soubory mezi vaší instancí SQL Serveru a nasazením služby SQL Managed Instance. Vytvoření nového účtu úložiště a kontejneru objektů blob uvnitř účtu úložiště:

1. Vytvoření účtu úložiště
2. Vytvořte kontejner objektů blob uvnitř účtu úložiště.

Konfigurace úložiště Azure za bránou firewall

Použití úložiště objektů blob v Azure, které je chráněné za bránou firewall, je podporované, ale vyžaduje další konfiguraci. Pokud chcete povolit přístup pro čtení a zápis ke službě Azure Storage se zapnutou službou Azure Firewall, musíte přidat podsíť spravované instance SQL do pravidel brány firewall pro účet úložiště pomocí delegování podsítě MI a koncového bodu služby Úložiště. Účet úložiště a spravovaná instance musí být ve stejné oblasti nebo ve dvou spárovaných oblastech.

Pokud je vaše úložiště Azure za bránou firewall, může se v protokolu chyb spravované instance SQL zobrazit následující zpráva:

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

Tím se vygeneruje e-mail s oznámením, že auditování spravované instance SQL selhává při zápisu protokolů auditu do účtu úložiště. Pokud se zobrazí tato chyba nebo obdržíte tento e-mail, nakonfigurujte bránu firewall podle kroků v této části.

Bránu firewall nakonfigurujete takto:

1. Na webu Azure Portal přejděte ke spravované instanci a výběrem podsítě otevřete stránku Podsítě .

   

2. Na stránce Podsítě vyberte název podsítě a otevřete stránku konfigurace podsítě.

   

3. V části Delegování podsítě zvolte Instance Microsoft.Sql/managedInstances z podsítě Delegát do rozevírací nabídky služby . Počkejte asi hodinu, než se oprávnění rozšíří, a pak v části Koncové body služby v rozevíracím seznamu Služby zvolte Microsoft.Storage.

   

4. Potom na webu Azure Portal přejděte ke svému účtu úložiště, v části Zabezpečení a sítě vyberte Sítě a pak zvolte kartu Brány firewall a virtuální sítě.

5. Na kartě Brány firewall a virtuální sítě pro váš účet úložiště zvolte +Přidat existující virtuální síť a otevřete stránku Přidat sítě.

   

6. V rozevíracích nabídkách vyberte příslušné předplatné, virtuální síť a podsíť spravované instance a pak vyberte Přidat a přidejte do účtu úložiště virtuální síť spravované instance SQL.

Ověření v účtu služby Blob Storage

Pro přístup k účtu služby Azure Blob Storage použijte token SAS nebo spravovanou identitu.

Ověření přístupu k úložišti spravované instance

Ověřte, že vaše spravovaná instance má přístup k vašemu účtu Blob Storage.

Nejprve nahrajte všechny zálohy databáze, jako full_0_0.bakje například , do kontejneru Azure Blob Storage.

Dále se připojte ke spravované instanci a spusťte ukázkový testovací dotaz, abyste zjistili, jestli má vaše spravovaná instance přístup k zálohování v kontejneru.

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' 

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

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'MANAGED IDENTITY' 

Nahrání záloh do účtu služby Blob Storage

Jakmile je kontejner objektů blob připravený a ověřili jste, že vaše spravovaná instance má přístup k kontejneru, můžete začít nahrávat zálohy do účtu Blob Storage. Máte tyto možnosti:

• Zkopírujte zálohy do účtu Blob Storage.
• Proveďte zálohy z SQL Serveru přímo do účtu Blob Storage pomocí příkazu BACKUP TO URL , pokud to vaše prostředí umožňuje (počínaje SQL Serverem verze 2012 SP1 CU2 a SQL Serverem 2014).

Kopírování existujících záloh do účtu služby Blob Storage

Pokud používáte starší verzi SQL Serveru nebo pokud vaše prostředí nepodporuje zálohování přímo na adresu URL, proveďte zálohy na instanci SQL Serveru stejně jako obvykle a zkopírujte je do svého účtu Blob Storage.

Zálohování instance SQL Serveru

Nastavte databáze, které chcete migrovat do úplného modelu obnovení, aby bylo možné zálohovat protokoly.

-- 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

Pokud chcete ručně vytvořit úplné, rozdílové a protokolové zálohy databáze do místního úložiště, použijte následující ukázkové skripty T-SQL. CHECKSUM není vyžadováno, ale doporučuje se zabránit migraci poškozené databáze a zrychlit obnovení.

Následující příklad přebírá úplné zálohování databáze na místní disk:

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

Následující příklad provede rozdílové zálohování na místní disk:

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

Následující příklad přebírá zálohu transakčního protokolu na místní disk:

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

Kopírování záloh do účtu služby Blob Storage

Jakmile jsou zálohy připravené a chcete začít migrovat databáze do spravované instance pomocí LRS, můžete ke kopírování existujících záloh do účtu Blob Storage použít následující přístupy:

• Stáhněte a nainstalujte AzCopy.
• Stáhněte a nainstalujte Průzkumníka služby Azure Storage.
• Použijte Průzkumník služby Storage na webu Azure Portal.

Přímé zálohování do účtu služby Blob Storage

Pokud používáte podporovanou verzi SQL Serveru (počínaje SQL Serverem 2012 SP1 CU2 a SQL Serverem 2014) a vaše podnikové a síťové zásady to umožňují, můžete zálohovat z SQL Serveru přímo do svého účtu Blob Storage pomocí nativní možnosti ZÁLOHOVÁNÍ SQL Serveru na adresu URL . Pokud můžete použít BACKUP TO URL, nemusíte provádět zálohy do místního úložiště a nahrávat je do účtu Blob Storage.

Když provádíte nativní zálohy přímo do účtu Blob Storage, musíte se ověřit v účtu úložiště.

Pomocí následujícího příkazu vytvořte přihlašovací údaje, které importuje token SAS do vaší instance SQL Serveru:

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

Podrobné pokyny pro práci s tokeny SAS najdete v kurzu Použití služby Azure Blob Storage s SQL Serverem.

Po vytvoření přihlašovacích údajů k ověření instance SQL Serveru pomocí služby Blob Storage můžete pomocí příkazu BACKUP TO URL provést zálohy přímo do účtu úložiště. CHECKSUM se doporučuje, ale nevyžaduje se.

Následující příklad přebírá úplné zálohování databáze na adresu 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

Následující příklad přebírá rozdílové zálohování databáze na adresu 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

Následující příklad přebírá zálohu transakčního protokolu na adresu 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

Přihlaste se k Azure a vyberte předplatné.

Pomocí následující rutiny PowerShellu se přihlaste k Azure:

Login-AzAccount

Pomocí následující rutiny PowerShellu vyberte předplatné, ve kterém se nachází vaše spravovaná instance:

Select-AzSubscription -SubscriptionId <subscription ID>

Spuštění migrace

Spusťte migraci spuštěním LRS. Službu můžete spustit buď v automatickém , nebo průběžném režimu.

Když použijete režim automatického dokončování, migrace se dokončí automaticky po obnovení posledního ze zadaných záložních souborů. Tato možnost vyžaduje, aby byl předem k dispozici celý řetěz zálohování a nahrál se do vašeho účtu Blob Storage. Nepovoluje přidávání nových záložních souborů během migrace. Tato možnost vyžaduje, start aby příkaz určil název souboru poslední zálohy. Tento režim doporučujeme pro pasivní úlohy, pro které není vyžadováno zachytávání dat.

Když používáte nepřetržitý režim, služba průběžně prohledá složku Azure Blob Storage a obnoví všechny nové záložní soubory, které se při migraci přidají. Migrace se dokončí až po vyžádání ruční přímé migrace. Migraci průběžného režimu je potřeba použít, pokud nemáte předem celý řetěz záloh a když plánujete přidat nové záložní soubory po dokončení migrace. Tento režim doporučujeme pro aktivní úlohy, pro které se vyžaduje zachytávání dat.

Naplánujte dokončení jedné úlohy migrace LRS do maximálně 30 dnů. Po uplynutí této doby se úloha LRS automaticky zruší.

Spuštění LRS v režimu automatického dokončování

Ujistěte se, že se celý řetěz záloh nahrál do účtu služby Azure Blob Storage. Tato možnost neumožňuje přidání nových záložních souborů během migrace.

Pokud chcete spustit LRS v režimu automatického dokončování, použijte příkazy PowerShellu nebo Azure CLI. Pomocí parametru zadejte název posledního záložního -LastBackupName souboru. Po dokončení obnovení posledního zadaného záložního souboru služba automaticky zahájí přímou migraci.

Obnovte databázi z účtu úložiště pomocí tokenu SAS nebo spravované identity.

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"

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"

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity  `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

Spuštění LRS v průběžném režimu

Ujistěte se, že jste nahráli počáteční řetěz záloh do účtu služby Azure Blob Storage.

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"

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"

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity

Skriptování úlohy migrace

Klienti PowerShellu a Azure CLI, kteří spouštějí LRS v průběžném režimu, jsou synchronní. V tomto režimu PowerShell a Azure CLI čekají na odezvu rozhraní API na zprávu o úspěchu nebo selhání, než spustí úlohu.

Během tohoto čekání se příkaz nevrátí do příkazového řádku. Pokud skriptujete prostředí migrace a potřebujete spouštěcí příkaz LRS k okamžitému vrácení řízení, abyste mohli pokračovat ve zbývající části skriptu, můžete powershell spustit jako úlohu na pozadí s přepínačem -AsJob . Příklad:

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

Když spustíte úlohu na pozadí, objekt úlohy se vrátí okamžitě, i když dokončení úlohy trvá delší dobu. Během spuštění úlohy můžete pokračovat v práci v relaci bez přerušení. Podrobnosti o spuštění PowerShellu jako úlohy na pozadí najdete v dokumentaci ke spouštěcí úloze PowerShellu.

Podobně pokud chcete spustit příkaz Azure CLI v Linuxu jako proces na pozadí, použijte ampersand (&) na konci spouštěcího příkazu LRS:

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

Monitorování průběhu migrace

Az.SQL 4.0.0 a novější poskytuje podrobnou zprávu o průběhu. Projděte si podrobnosti o obnovení spravované databáze – získejte ukázkový výstup.

Pokud chcete monitorovat probíhající průběh migrace přes PowerShell, použijte následující příkaz:

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

Pokud chcete monitorovat probíhající průběh migrace prostřednictvím Azure CLI, použijte následující příkaz:

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

Pokud chcete sledovat další podrobnosti o neúspěšném požadavku, použijte příkaz PowerShellu Get-AzSqlInstanceOperation nebo použijte příkaz Azure CLI az sql mi op show.

Zastavení migrace (volitelné)

Pokud potřebujete migraci zastavit, použijte PowerShell nebo Azure CLI. Zastavením migrace odstraníte obnovující databázi ve spravované instanci, takže obnovení migrace nebude možné.

Pokud chcete proces migrace zastavit prostřednictvím PowerShellu, použijte následující příkaz:

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

Pokud chcete proces migrace zastavit prostřednictvím Azure CLI, použijte následující příkaz:

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

Dokončení migrace (průběžný režim)

Pokud spustíte LRS v nepřetržitém režimu, ujistěte se, že vaše aplikace a úloha SQL Serveru byly zastaveny, aby se zabránilo vygenerování nových záložních souborů. Ujistěte se, že se poslední záloha z vaší instance SQL Serveru nahrála do účtu služby Azure Blob Storage. Sledujte průběh obnovení ve spravované instanci a ujistěte se, že se obnovila poslední záloha protokolu.

Po obnovení poslední zálohy protokolu ve spravované instanci zahajte ruční přímou migraci. Po dokončení přímé migrace bude databáze dostupná pro přístup ke čtení a zápisu ve spravované instanci.

K dokončení procesu migrace v průběžném režimu LRS přes PowerShell použijte následující příkaz:

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

K dokončení procesu migrace v průběžném režimu LRS prostřednictvím Azure CLI použijte následující příkaz:

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

Omezení

Při migraci s LRS zvažte následující omezení:

• Databáze, které se obnovují prostřednictvím LRS, nemůžete použít, dokud se proces migrace nedokončí.
• Během procesu migrace se databáze migrované nedají použít pro přístup jen pro čtení ve službě SQL Managed Instance.
• Po dokončení migrace je proces migrace konečný a nejde pokračovat s dalšími rozdílovými zálohami.
• LRS podporuje pouze databázi .bak.loga .diff soubory. Soubory Dacpac a bacpac nejsou podporované.
• Musíte nakonfigurovat časové období údržby pro naplánování aktualizací systému v konkrétní den a čas. Naplánujte spuštění a dokončení migrací mimo naplánované časové období údržby.
• Zálohy databáze, které jsou pořízeny bez CHECKSUM:
  • může potenciálně migrovat poškozené databáze.
  • obnovení než zálohy databáze s povoleným obnovením CHECKSUM trvá déle.
• Token sdíleného přístupového podpisu (SAS), který používá LRS, se musí vygenerovat pro celý kontejner služby Azure Blob Storage a musí mít Read pouze oprávnění a List oprávnění. Pokud například udělíte Readoprávnění , Lista Write oprávnění, LRS se nespustí kvůli dodatečnému Write oprávnění.
• Použití tokenů SAS vytvořených s oprávněními nastavenými prostřednictvím definování uložených zásad přístupu se nepodporuje. Podle pokynů v tomto článku ručně zadejte oprávnění ke čtení a výpisu tokenu SAS.
• Záložní soubory pro různé databáze musíte umístit do samostatných složek v účtu Blob Storage v ploché struktuře souborů. Vnoření složek do databázových složek se nepodporuje.
• Pokud používáte režim automatického dokončování, musí být celý řetěz záloh dostupný předem v účtu Blob Storage. V režimu automatického dokončování není možné přidávat nové záložní soubory. Pokud během migrace potřebujete přidat nové záložní soubory, použijte nepřetržitý režim.
• LRS musíte spustit zvlášť pro každou databázi, která odkazuje na úplnou cestu URI, která obsahuje jednotlivé složky databáze.
• Cesta k identifikátoru URI zálohování, název kontejneru nebo názvy složek by neměly obsahovat backup nebo backups protože se jedná o vyhrazená klíčová slova.
• Při paralelním spuštění více obnovení přehrání protokolu, které cílí na stejný kontejner úložiště, se ujistěte, že je pro každou operaci obnovení k dispozici stejný platný token SAS.
• LRS může podporovat až 100 souběžných procesů obnovení na jednu spravovanou instanci.
• Jedna úloha LRS může běžet maximálně 30 dní, po které se automaticky zruší.
• I když je možné použít účet služby Azure Storage za bránou firewall, je nutná další konfigurace a účet úložiště a spravovaná instance musí být buď ve stejné oblasti, nebo ve dvou spárovaných oblastech. Další informace najdete v tématu Konfigurace brány firewall .
• Maximální počet databází, které můžete obnovit paralelně, je 200 na jedno předplatné. V některých případech je možné tento limit zvýšit otevřením lístku podpory.
• Nahrání tisíců databázových souborů k obnovení může vést k nadměrným časům migrace a dokonce i selháním. Konsolidovat databáze do menšího počtu souborů, aby se urychlil proces migrace, a zajistit, že je úspěšný.

Omezení při migraci na úroveň služby Pro důležité obchodní informace

Při migraci na spravovanou instanci SQL na úrovni služby Pro důležité obchodní informace zvažte následující omezení:

• Při migraci velkých databází může dojít k značnému výpadku, protože databáze jsou po přímé migraci nedostupné, zatímco databáze se zasadí do sekundárních replik úrovně služby Pro důležité obchodní informace. Alternativní řešení jsou uvedená v delší části přímé migrace .
• Migrace se automaticky restartuje od začátku, pokud se migrace přeruší neplánovaným převzetím služeb při selhání, aktualizací systému nebo opravou zabezpečení, což ztěžuje naplánování předvídatelné migrace bez překvapení za poslední minutu.

Delší přímá migrace na úrovni služby Pro důležité obchodní informace

Pokud migrujete na spravovanou instanci SQL na úrovni služby Pro důležité obchodní informace, přineste databáze do režimu online na primární replice, zatímco se odsadí do sekundárních replik. To platí zejména pro větší databáze.

Migrace na spravovanou instanci SQL na úrovni služby Pro důležité obchodní informace trvá déle, než je úroveň služby Pro obecné účely. Po dokončení přímé migrace do Azure budou databáze nedostupné, dokud se nenasadí z primární repliky na tři sekundární repliky, což může trvat delší dobu v závislosti na velikosti databáze. Čím větší je databáze, tím delší počáteční doba sekundárních replik může trvat až několik hodin.

Pokud je důležité, aby databáze byly dostupné hned po dokončení přímé migrace, zvažte následující alternativní řešení:

• Nejprve migrujte na úroveň služby Pro obecné účely a pak upgradujte na úroveň služby Pro důležité obchodní informace během následného časového období údržby. Upgrade úrovně služby je online operace, která udržuje databáze online až do krátkého převzetí služeb při selhání jako poslední krok operace upgradu.
• Odkaz Na spravovanou instanci použijte pro online migraci do instance Pro důležité obchodní informace, aniž byste museli čekat na dostupnost databází po přímé migraci.

Řešení potíží s LRS

Po spuštění LRS pomocí některé z následujících rutin monitorování zobrazte stav probíhající operace:

• Pro PowerShell: get-azsqlinstancedatabaselogreplay
• Pro Azure CLI: az_sql_midb_log_replay_show

Kontrola podrobností o neúspěšné operaci:

• Pro PowerShell: Get-AzSqlInstanceOperation
• Pro Azure CLI: az sql mi op show

Pokud se po nějaké době nepodaří spustit LRS a zobrazí se chyba, zkontrolujte nejběžnější problémy:

• Má existující databáze ve spravované instanci stejný název jako databáze, kterou se pokoušíte migrovat z instance SQL Serveru? Tento konflikt vyřešíte přejmenováním jedné z databází.
• Jsou oprávnění udělená jen pro čtení a výpis tokenu SAS? Udělení více oprávnění než Read a List způsobí selhání LRS.
• Zkopírovali jste token SAS pro LRS za otazníkem (?) s obsahem, který vypadá takto sv=2020-02-10...?
• Je doba platnosti tokenu SAS vhodná pro časové období spuštění a dokončení migrace? Kvůli různým časovým pásmům používaným pro nasazení služby SQL Managed Instance a tokenu SAS může docházet k neshodám. Zkuste znovu vygenerovat token SAS a prodloužit platnost tokenu časového intervalu před aktuálním datem a po tomto datu.
• Při paralelním spuštění několika obnovení přehrání protokolu, které cílí na stejný kontejner úložiště, se ujistěte, že je pro každou operaci obnovení k dispozici stejný platný token SAS.
• Jsou název databáze, název skupiny prostředků a název spravované instance správně napsané?
• Pokud jste spustili LRS v režimu automatického dokončování, byl platný název souboru pro poslední zadaný záložní soubor?
• Obsahuje cesta URI zálohování klíčová slova backup nebo backups? Přejmenujte kontejner nebo složky, které používají backup , nebo backups jako jsou vyhrazená klíčová slova.

Další kroky

• Přečtěte si další informace o migraci do služby Azure SQL Managed Instance pomocí funkce odkazu.
• Přečtěte si další informace o migraci z SQL Serveru do azure SQL Managed Instance.
• Přečtěte si další informace o rozdílech mezi SQL Serverem a spravovanou instancí SQL.
• Přečtěte si další informace o osvědčených postupech pro úlohy nákladů a velikostí migrovaných do Azure.