Nejčastější dotazy ohledně používání služby Azure Database Migration Service

Azure Database Migration Service je plně spravovaná služba navržená tak, aby umožňovala bezproblémovou migraci z více databázových zdrojů na datové platformy Azure s minimálními výpadky. Služba je v současné době obecně dostupná a průběžné vývojové úsilí zaměřené na:

• Spolehlivost a výkon.
• Iterativní přidání párů zdrojového cíle
• Další investice do migrací bez tření.

Služba aktuálně podporuje různé páry zdroje a cíle nebo scénáře migrace. Úplný seznam stavu jednotlivých dostupných scénářů migrace najdete v článku Stav scénářů migrace podporovaných službou Azure Database Migration Service.

Při migraci z SQL Serveru jsou podporované zdroje pro službu Azure Database Migration Service SQL Server 2008 a novější verze. Pokud používáte Azure Data Studio s rozšířením SQL Migration, podporované zdroje jsou SQL Server 2008 až SQL Server 2022.

Službu Azure Database Migration Service můžete použít k provádění offline a online migrací. Při offline migraci se po spuštění migrace spustí výpadek aplikace. Při online migraci je výpadek omezený na dobu, která se má zkrátit na konci migrace. Doporučujeme otestovat offline migraci a určit, jestli je výpadek přijatelný. Pokud není, proveďte online migraci.

Služba Azure Database Migration Service je upřednostňovanou metodou migrace databází do Microsoft Azure ve velkém měřítku. Další informace o porovnání služby Azure Database Migration Service s jinými nástroji pro migraci databází Microsoftu a doporučení k používání této služby pro různé scénáře najdete v tématu Odlišování nástrojů a služeb pro migraci databází od Microsoftu.

Azure Migrate pomáhá s migrací místních virtuálních počítačů do Azure IaaS. Služba vyhodnocuje vhodnost migrace a velikost na základě výkonu a poskytuje odhad nákladů na provoz místních virtuálních počítačů v Azure. Azure Migrate je užitečná pro migrace místních úloh založených na virtuálních počítačích založených na metodách "lift and shift" do virtuálních počítačů Azure IaaS. Na rozdíl od služby Azure Database Migration Service ale azure Migrate není specializovaná služba pro migraci databází pro platformy relačních databází Azure PaaS, jako je Azure SQL Database nebo Azure SQL Managed Instance.

Ne. Služba Database Migration Service neukládá zákaznická data.

Pro virtuální počítače Azure SQL a cíle Azure SQL MI používá DMS fyzickou migraci, tj. pomocí zálohování a obnovení. Jak je popsáno níže, zvolený režim migrace určuje, jak se data uchovávají konzistentní mezi zdrojem a cílem.

• Offline migrace: Během offline migrace na virtuální počítač Azure SQL a cíle Azure SQL MI se při spuštění migrace spustí výpadek aplikace. DMS obnoví všechny záložní soubory do cíle, pokud se nejnovější záložní soubor/s ze zdroje přenesou do síťového úložiště SMB nebo do kontejneru objektů blob Azure (podle konfigurace migrace). Pokud je záloha provedena s možností CHECKSUM, operace obnovení DMS automaticky provede ověření. Při absenci kontrolního součtu se integrita zálohy před obnovením explicitně kontroluje. Tím zajistíte, že soubor obnovení bude stejný jako záložní soubor, a proto budou mít stejná data. Všechny záložní soubory, včetně názvu posledního záložního souboru ze zdroje, můžete ověřit pomocí použitého záložního souboru nebo obnovení v cíli zobrazeném na stránce monitorování migrace DMS a ověřit odpovídající kontrolní součet.

• Online migrace: Během online migrace na virtuální počítač Azure SQL a cíle Azure SQL MI se výpadek spustí po zahájení přímé migrace spolu se zastavením aplikace. DMS obnoví všechny záložní soubory do cíle, pokud se nejnovější záložní soubor/s ze zdroje přenesou do síťového úložiště SMB nebo do kontejneru objektů blob Azure (podle konfigurace migrace). Po stisknutí tlačítka přímé migrace zobrazí DMS počet nevyřízených záložních souborů/s (pokud existuje), které jsou přítomné v síťovém úložišti SMB nebo kontejneru objektů blob Azure a které se ještě mají použít nebo obnovit v cíli. Pokud je záloha provedena s možností CHECKSUM, operace obnovení DMS automaticky provede ověření. Při absenci kontrolního součtu se integrita zálohy před obnovením explicitně kontroluje. Tím zajistíte, že soubor obnovení bude stejný jako záložní soubor, a proto budou mít stejná data. Všechny záložní soubory, včetně názvu posledního záložního souboru ze zdroje, můžete ověřit pomocí použitého záložního souboru nebo obnovení v cíli zobrazeném na stránce monitorování migrace DMS a ověřit odpovídající kontrolní součet.

V případě cílů Azure SQL DB dmS provede logickou migraci v případě Azure SQL DB, tj. zkopíruje data z tabulek zdrojové databáze SQL a zapíše je do tabulek cílové databáze Azure SQL. Vzhledem k tomu, že DMS podporuje pouze offline migraci do Azure SQL DB, spustí se výpadek aplikace při spuštění migrace. Můžete monitorovat a ověřovat počet řádků přečtených (ze zdrojové tabulky databáze) a zkopírovat (zapsat do cílové tabulky Azure SQL DB) ze stránky pro monitorování migrace. Jako další potvrzení můžete spustit následující TSQL, abyste získali kontrolní součet ve zdrojové i cílové databázi a ověřili, že zdroj a obnovení dat jsou identická.

  "SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>"
  

Poznámka: Nezadá se žádná aplikace nebo aplikace zapisuje do zdrojové nebo cílové databáze. K porovnání dat můžete využít také nástroje, jako je nástroj Porovnání databáze.

Následující seznam obsahuje prostředky Azure, které se můžou vytvořit na pozadí, aby bylo možné provést migraci dat. Používané služby se můžou lišit podle scénáře migrace.

• Azure Monitor
• Virtuální počítač Azure
• Azure Storage
• Azure Service Bus
• Azure Data Factory

DMS interně udržuje úložiště metadat, které obsahuje informace o síťových umístěních, přihlašovacích údajích, záložních souborech a dokončených úlohách. Přihlašovací údaje a vybraná pole, jako jsou klíče účtu, jsou šifrovaná. Data, jako jsou názvy tabulek, které můžou být zahrnuté v telemetrii, jsou hashovaná. Uživatelská jména se můžou v protokolech služeb zobrazovat ve formátu prostého textu, ale hesla nikdy nebudou. Telemetrie se řídí podle oblastí, řídí se zásadami uchovávání informací a je dostupná jenom autorizovaným pracovníkům v Microsoftu pro platné účely řešení potíží. Názvy prostředků Azure, jako jsou názvy serverů a databází, se řídí pravidly pro prostředky Azure.

DMS (Classic) využívá témata služby Azure Service Bus k usnadnění komunikace mezi výpočetními vrstvami. Témata služby Azure Service Bus jsou jedinečná pro každou instanci DMS a šifrují se všechna osobní data.

Spravovaná instance Azure SQL a SQL Server na virtuálních počítačích Azure

Schéma a data se migrují pomocí zálohování a obnovení. Zákazníci si vybrali možnost obnovení ze sdílené síťové složky nebo přímo z kontejneru úložiště. Soubor obsahující údaje o výkonu Systému Windows může být využit, aby poskytoval volitelná doporučení pro (ale důrazně doporučenou) velikost úloh.

Azure SQL Database

Migrace do služby Azure SQL Database se provádějí ve dvou krocích. Prvním krokem je migrace schématu. DMS (Classic) používá k migraci schématu objekty sql Management (SMO). Druhým krokem je skutečná migrace dat. SqlBulkCopy slouží k migraci dat. DMS nepodporuje migraci schématu. Data se migrují pomocí služby Azure Data Factory. Volitelně ale důrazně doporučujeme použít soubor obsahující data o výkonu Windows, aby poskytoval doporučení pro změnu velikosti úloh.

Azure Database for PostgreSQL

V tomto scénáři koncový uživatel extrahuje metadata, v tomto případě schéma pomocí nástrojů příkazového řádku a pg_restore nástrojů příkazového pg_dump řádku. Při konfiguraci zachytávání dat změn pro PostgreSQL se DMS interně používá pg_dump a pg_restore provádí počáteční seeding pro CDC. Data se ukládají do šifrovaného dočasného úložiště, které je přístupné jenom pro vaši instanci DMS. Soubor obsahující údaje o výkonu Systému Windows může být využit, aby poskytoval volitelná doporučení pro (ale důrazně doporučenou) velikost úloh.

Azure Database for MySQL

V tomto scénáři se extrakce a migrace schémat provádí dmS (Classic) pomocí mysql-net/MySqlConnector. Pokud je to možné, replikace binlogu MySQL se používá k replikaci dat i změn schématu. Vlastní kód se používá k synchronizaci změn, kdy nejde použít replikaci binlogu.

MongoDB do Služby Azure Cosmos DB

DMS extrahuje a vloží data z MongoDB do Cosmos DB. Nabízí také možnost extrahovat data z výpisu paměti BSON nebo JSON.

V případě výpisů paměti BSON používá DMS data ve bsondump formátu ve stejné složce v kontejneru objektů blob. DMS hledá pouze soubory metadat pomocí formátu collection.metadata.json.

V případě výpisů kódu JSON bude DMS číst soubory ve složkách kontejneru objektů blob pojmenovaných po obsahujících databázích. V každé složce databáze používá DMS pouze datové soubory umístěné v data podsložce. DMS se podívá jenom na soubory umístěné v metadata podsložce a pojmenované pomocí formátu collection.json pro metadata.

Oracle do Azure SQL Database

V tomto scénáři se sestava AWR nebo soubor Windows perfmon spotřebovávají k poskytnutí volitelných (ale vysoce doporučených) doporučení k určení velikosti úloh. Uživatel provádějící migraci použije Sada nástrojů pro převod schématu databáze k provedení migrace schématu k přípravě cílové databáze.

Oracle do Azure Database for PostgreSQL

Podobně jako Oracle do Azure SQL Database se v tomto scénáři využívá sestava AWR nebo soubor Windows perfmon k poskytnutí volitelných (ale vysoce doporučených) doporučení k určení velikosti úloh. Knihovna ora2pg se používá k extrakci schématu a ruční migraci dat uživatelem provádějícím migraci.

DMS (Classic) spoléhá na konfiguraci sítě zákazníka. Pokud zdroj migrace používá privátní koncové body, použijeme privátní koncové body, což je upřednostňovaná konfigurace. Veřejné koncové body používáme, pokud jsou jedinou možností.

DMS využívá ADF na pozadí k plánování a koordinaci přesunu dat. Kromě toho se místní prostředí Integration Runtime neliší od místního prostředí Integration Runtime, které už pravděpodobně používáte pro vlastní kanály ADF. Další informace o problémech s bránou firewall a proxy serverem najdete v tématu Vytvoření a konfigurace místního prostředí Integration Runtime.

Všechna neaktivní uložená data zákazníků se šifrují. Některá metadata, včetně názvů logických serverů a názvů databází, a také stavu migrace a průběhu migrace se zobrazují v protokolech služby, které nejsou šifrované.

Všechna přenášená data jsou ve výchozím nastavení chráněná šifrováním TLS 1.2. Starší klienti, kteří vyžadují starší verze protokolu TLS, potřebují na stránce portálu DMS (Classic) povolené požadované verze. Pro DMS je možné nakonfigurovat počítač, na kterém je nainstalovaný místní prostředí Integration Runtime, aby bylo možné povolit požadovaná nastavení protokolu TLS pro přizpůsobení starším klientům. Další informace o konfiguraci protokolu TLS pro SQL Server najdete v tématu KB3135244 – podpora protokolu TLS 1.2 pro Microsoft SQL Server.

Pokud je to možné, používají se privátní koncové body. Pokud privátní koncové body nejsou možnost, veřejné koncové body se použijí pro komunikaci mezi vrstvami služeb. Bez ohledu na typ koncového bodu jsou všechny prostředky vyhrazené nebo omezené na konkrétní instanci DMS a jsou zabezpečené pomocí jedinečných přihlašovacích údajů.

Nepodporujeme klíče spravované zákazníkem pro šifrování dat v naší rovině dat ani řídicí rovině. Všechna neaktivní uložená data zákazníků se ale šifrují pomocí klíčů spravovaných službou. Některá metadata, včetně názvů logických serverů a názvů databází, a také stavu migrace a průběhu, se zobrazují v protokolech služby v nešifrované podobě.

Všechna přenášená data se ve výchozím nastavení šifrují pomocí šifrování TLS 1.2. Stránka portálu DMS (Classic) umožňuje starší verze protokolu TLS používat pro starší klienty. V případě DMS je možné nakonfigurovat počítač, na kterém je nainstalovaný místní prostředí Integration Runtime, tak, aby umožňoval správu nastavení protokolu TLS tak, aby vyhovovalo starším klientům. Další informace o konfiguraci protokolu TLS pro SQL Server najdete v tématu KB3135244 – podpora protokolu TLS 1.2 pro Microsoft SQL Server.

Nezpřístupňujeme možnost šifrování dat v naší řídicí rovině nebo rovině dat pomocí klíčů spravovaných zákazníkem. Všechna zákaznická data se odstraní v okamžiku, kdy se instance DMS odstraní s výjimkou protokolů služeb. Protokoly služby DMS se uchovávají jenom po dobu 30 dnů.

Transparentní šifrování dat

DMS podporuje migraci klíčů spravovaných zákazníkem (CMK) do Azure SQL pro transparentní šifrování databáze (TDE). Podrobné pokyny k migraci klíčů transparentního šifrování dat najdete v tématu Kurz: Migrace databází s povoleným transparentním šifrováním dat (Preview) do Azure SQL v Nástroji Azure Data Studio.

Šifrování buněk

Šifrování na úrovni buňky se zpracovává na úrovni schématu. Nástroje pro migraci schématu migrují všechny objekty schématu včetně funkcí a uložených procedur nezbytných k implementaci šifrování na úrovni buňky.

Funkce Always Encrypted

DMS v současné době nepodporuje migraci funkce Always Encrypted prostřednictvím scénářů, kdy se mezi zdrojem a cílem migrují jednotlivé řádky dat. Sloupce šifrované pomocí funkce Always Encrypted se migrují podle očekávání ve scénářích, které používají zálohování a obnovení, jako je přechod na virtuální počítač Azure SQL nebo spravovaná instance Azure SQL z existující instance SQL Serveru.

Neimplementujeme žádné řízení přístupu s podporou umístění nad rámec toho, co je již dostupné v Azure. Všechna data přidružená k instanci DMS se nacházejí ve stejné oblasti jako prostředek DMS.

Naše služby se používají v různých prostředích s různými interními ovládacími prvky a obchodními procesy. DMS přesouvá data z a do libovolného místa, ke kterému účet používá, má přístup. Uživatel zodpovídá za pochopení oprávnění a interních ovládacích prvků prostředí, ve které pracuje. Je zvlášť důležité zajistit, aby účet, který DMS používá pro připojení ke zdroji, měl přístup k zobrazení všech dat, která mají být migrována ze zdroje.

Injektáž virtuální sítě je akce přidání prostředku Azure, který se nachází v tenantovi Microsoftu, do podsítě ve virtuální síti v rámci tenanta zákazníka. Tento přístup byl přijat s DMS, abychom umožnili spravovat výpočetní prostředky jménem zákazníka a přitom zachovat přístup k zákaznickým prostředkům. Vzhledem k tomu, že síť je v předplatném zákazníka, nemůže Microsoft spravovat virtuální počítač nad rámec vydávání příkazů Start, Stop, Delete nebo Deploy. Všechny ostatní akce správy, které potřebují přístup k virtuálnímu počítači, vyžadují žádost o podporu iniciovanou zákazníkem a schválení.

K zajištění bezproblémového spuštění služby Azure Database Migration Service při migraci databází je potřeba splnit několik požadavků. Některé z požadavků se vztahují na všechny scénáře (páry zdroj-cíl) podporované touto službou, zatímco ostatní požadavky jsou specifické pro konkrétní scénář.

Požadavky služby Azure Database Migration Service, které jsou společné ve všech podporovaných scénářích migrace, zahrnují:

• Vytvořte pro službu Azure Database Migration Service síť Microsoft Azure Virtual Network s použitím modelu nasazení Azure Resource Manager, který poskytuje možnosti připojení typu Site-to-Site k místním zdrojovým serverům prostřednictvím ExpressRoute nebo sítě VPN.
• Ujistěte se, že pravidla skupiny zabezpečení sítě virtuální sítě neblokují port 443 pro ServiceTags of ServiceBus, Storage a AzureMonitor. Další podrobnosti o filtrování provozu pomocí skupin zabezpečení virtuální sítě najdete v článku Filtrování provozu sítě s použitím skupin zabezpečení sítě.
• Pokud před zdrojovými databázemi používáte zařízení brány firewall, možná bude potřeba přidat pravidla brány firewall, která službě Azure Database Migration Service povolí přístup ke zdrojovým databázím za účelem migrace.

Seznam všech požadavků potřebných k soutěžit konkrétní scénáře migrace pomocí služby Azure Database Migration Service najdete v souvisejících kurzech v dokumentaci ke službě Azure Database Migration Service.

Možná budete muset přidat pravidla brány firewall, která službě Azure Database Migration Service umožní přístup ke zdrojové databázi pro migraci. IP adresa služby je dynamická, ale pokud používáte ExpressRoute, tato adresa je soukromě přiřazená vaší podnikovou sítí. Nejjednodušší způsob, jak identifikovat odpovídající IP adresu, je vyhledat přidruženou síťovou rozhraní ve stejné skupině prostředků jako váš zřízený prostředek služby Azure Database Migration Service. Název prostředku síťového rozhraní obvykle začíná předponou síťové karty a za ním jedinečný znak a posloupnost čísel, například NIC-jj6tnztnmarpsskr82rbndyp. Výběrem tohoto prostředku síťového rozhraní uvidíte IP adresu, kterou je potřeba zahrnout do seznamu povolených na stránce Přehled prostředků na webu Azure Portal.

Možná budete muset zahrnout také zdroj portů, který SQL Server naslouchá na seznamu povolených. Ve výchozím nastavení je to port 1433, ale zdrojový SQL Server může být nakonfigurovaný tak, aby naslouchal i na jiných portech. V takovém případě musíte tyto porty zahrnout také do seznamu povolených. Port, na který SQL Server naslouchá, můžete určit pomocí dotazu dynamického zobrazení správy:

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

Port, na který SQL Server naslouchá, můžete také určit dotazem na protokol chyb SQL Serveru:

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

Zatímco několik kurzů Microsoftu, které vás můžou projít procesem nastavení virtuální sítě, oficiální dokumentace se zobrazí v článku Azure Virtual Network.

Během typické jednoduché migrace databáze:

1. Vytvoření cílových databází
2. Posouzení zdrojových databází
   • U homogenních migrací vyhodnoťte stávající databáze pomocí DMA.
   • V případě heterogenních migrací (z konkurenčních zdrojů) vyhodnoťte stávající databáze pomocí SSMA. Pomocí SSMA můžete také převést databázové objekty a migrovat schéma na cílovou platformu.
3. Vytvořte instanci služby Azure Database Migration Service.
4. Vytvořte projekt migrace určující zdrojové databáze, cílové databáze a tabulky, které se mají migrovat.
5. Spusťte úplné načtení.
6. Vyberte další ověření.
7. Proveďte ruční přechod produkčního prostředí na novou cloudovou databázi.

Pokud máte potíže s připojením ke zdrojovému databázovému systému při migraci, vytvořte virtuální počítač ve stejné podsíti virtuální sítě, pomocí které jste nastavili instanci DMS. Na virtuálním počítači byste měli být schopni spustit test připojení, jako je například použití souboru UDL k otestování připojení k SQL Serveru nebo stažení Robo 3T pro testování připojení MongoDB. Pokud test připojení proběhne úspěšně, nemělo by docházet k potížím s připojením ke zdrojové databázi. Pokud test připojení neproběhne úspěšně, obraťte se na správce sítě.

Pokud uživatel explicitně zastaví službu Azure Database Migration Service (DMS) nebo pokud je služba neaktivní po dobu 24 hodin, služba je zastavená nebo automaticky pozastavená. V každém případě je služba nedostupná a je ve stavu zastavení. Pokud chcete obnovit aktivní migrace, restartujte službu.

Pokud chcete urychlit migraci databáze pomocí této služby, můžete udělat několik věcí:

Pro DMS(Classic)-

• Při vytváření instance služby použijte cenovou úroveň Pro obecné účely s více procesory, aby služba mohla využít více virtuálních procesorů k paralelizaci a ke zrychlení přenosu dat.
• Během operace migrace dat dočasně vertikálně navyšte kapacitu cílové instance Azure SQL Database na skladovou položku úrovně Premium, aby se minimalizovalo omezování služby Azure SQL Database, které může mít vliv na aktivity přenosu dat při použití skladových položek nižší úrovně.

Pro DMS-

• Pokud kopírujete zálohy z místní sdílené složky do úložiště objektů blob v Azure NEBO při migraci do cílové služby Azure SQL DB používá DMS jako výpočetní prostředky uzel SHIR. Proto se ujistěte, že monitoruje využití prostředků daného uzlu SHIR.
• Během operace migrace dat dočasně vertikálně navyšte kapacitu cílové instance Služby Azure SQL Database na skladovou položku úrovně Premium, abyste minimalizovali omezování disku služby Azure SQL Database, které může mít vliv na aktivity přenosu dat při použití skladových položek nižší úrovně.
• Podrobnější informace najdete v blogu.

Další kroky

• Co je služba Azure Database Migration Service.