Veelgestelde vragen over het gebruik van Azure Database Migration Service

Azure Database Migration Service is een volledig beheerde service die is ontworpen om naadloze migraties van meerdere databasebronnen naar Azure Data-platforms mogelijk te maken met minimale downtime. De service is momenteel algemeen beschikbaar, met voortdurende ontwikkelingsinspanningen gericht op:

• Betrouwbaarheid en prestaties.
• Iteratieve toevoeging van bron-doelparen.
• Voortdurende investeringen in frictievrije migraties.

De service ondersteunt momenteel verschillende bron-/doelparen of migratiescenario's. Zie het artikel Status van migratiescenario's die worden ondersteund door de Azure Database Migration Service voor een volledige lijst van de status van elk beschikbaar migratiescenario.

Wanneer u migreert van SQL Server, zijn ondersteunde bronnen voor Azure Database Migration Service SQL Server 2008 en latere versies. Als u Azure Data Studio met sql Migration-extensie gebruikt, zijn ondersteunde bronnen SQL Server 2008 tot en met SQL Server 2022.

U kunt Azure Database Migration Service gebruiken om offline- en onlinemigraties uit te voeren. Bij een offlinemigratie wordt downtime van toepassingen gestart wanneer de migratie wordt gestart. Bij een onlinemigratie is downtime beperkt tot de tijd die aan het einde van de migratie moet worden overschreden. We raden u aan eerst een offlinemigratie te testen om te bepalen of de downtime aanvaardbaar is. Zo niet, voer dan een onlinemigratie uit.

Azure Database Migration Service is de voorkeursmethode voor databasemigratie naar Microsoft Azure op schaal. Voor meer informatie over hoe Azure Database Migration Service zich verhoudt tot andere microsoft-hulpprogramma's voor databasemigratie en voor aanbevelingen over het gebruik van de service voor verschillende scenario's, raadpleegt u Differentiërende hulpprogramma's en services voor databasemigratie van Microsoft.

Azure Migrate helpt bij de migratie van on-premises virtuele machines naar Azure IaaS. De service beoordeelt de geschiktheid voor migratie en de grootte op basis van prestaties en biedt kostenramingen voor het uitvoeren van uw on-premises virtuele machines in Azure. Azure Migrate is handig voor lift-and-shift-migraties van on-premises VM-workloads naar Azure IaaS-VM's. In tegenstelling tot Azure Database Migration Service is Azure Migrate echter geen gespecialiseerde aanbieding voor databasemigratieservices voor relationele Azure PaaS-databaseplatforms, zoals Azure SQL Database of Azure SQL Managed Instance.

Nee Database Migration Service slaat geen klantgegevens op.

Voor Azure SQL VM- en Azure SQL MI-doelen maakt DMS gebruik van fysieke migratie, d.w.v. back-up en herstel. Zoals hieronder beschreven, bepaalt de gekozen migratiemodus hoe de gegevens consistent worden gehouden tussen de bron en het doel.

• Offlinemigratie: tijdens offlinemigratie naar Azure SQL VM- en Azure SQL MI-doelen wordt downtime van toepassingen gestart wanneer de migratie wordt gestart. DMS herstelt alle back-upbestanden naar het doel, zolang de meest recente back-upbestanden van de bron zijn overgedragen naar SMB-netwerkopslag of naar Azure Blob-container (volgens de migratieconfiguratie). Als de back-up wordt gemaakt met de optie CHECKSUM, voert dmS-herstelbewerking automatisch de validatie uit. Als er geen controlesom is, wordt de integriteit van de back-up expliciet gecontroleerd voordat de back-up wordt hersteld. Dit zorgt ervoor dat het herstelbestand identiek is aan het back-upbestand en dus dezelfde gegevens heeft. U kunt alle back-upbestanden, inclusief de naam van het laatste back-upbestand van de bron, controleren met het back-upbestand toegepast/herstellen op het doel dat wordt weergegeven op de dmS-migratiebewakingspagina en de respectieve controlesom valideren.

• Onlinemigratie: Tijdens onlinemigratie naar Azure SQL VM- en Azure SQL MI-doelen wordt downtime gestart zodra u de migratie-cutover start en de toepassing stopt. DMS herstelt alle back-upbestanden naar het doel, zolang de meest recente back-upbestanden van de bron zijn overgedragen naar SMB-netwerkopslag of naar Azure Blob-container (volgens de migratieconfiguratie). Nadat u op de cutover-knop hebt drukt, toont DMS het aantal voor in behandeling zijnde back-upbestanden (indien aanwezig) die aanwezig zijn in de SMB-netwerkopslag of Azure Blob-container en nog moet worden toegepast/hersteld op het doel. Als de back-up wordt gemaakt met de optie CHECKSUM, voert dmS-herstelbewerking automatisch de validatie uit. Als er geen controlesom is, wordt de integriteit van de back-up expliciet gecontroleerd voordat de back-up wordt hersteld. Dit zorgt ervoor dat het herstelbestand identiek is aan het back-upbestand en dus dezelfde gegevens heeft. U kunt alle back-upbestanden, inclusief de naam van het laatste back-upbestand van de bron, controleren met het back-upbestand toegepast/herstellen op het doel dat wordt weergegeven op de dmS-migratiebewakingspagina en de respectieve controlesom valideren.

Voor Azure SQL DB-doelen voert DMS logische migratie uit in het geval van Azure SQL DB, d.w.z. het kopieert de gegevens uit de tabellen van de SQL-brondatabase en schrijft deze naar de tabellen van de Doel-Azure SQL DB. Omdat DMS alleen offlinemigratie naar Azure SQL DB ondersteunt, wordt de downtime van toepassingen gestart wanneer de migratie wordt gestart. U kunt het aantal gelezen rijen (uit de brondatabasetabel) en gekopieerd (geschreven naar de Azure SQL DB-doeltabel) controleren en valideren vanaf de pagina migratiebewaking. Als extra bevestiging kunt u de onderstaande TSQL uitvoeren om zowel in bron- als doeldatabases controlesom op te halen en de bron- en herstelgegevens te valideren die identiek zijn.

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

Opmerking: Op voorwaarde dat er geen toepassing/s is/worden geschreven naar de bron- of doeldatabase. U kunt ook gebruikmaken van hulpprogramma's zoals het hulpprogramma databasevergelijking voor gegevensvergelijking.

De volgende lijst bevat de Azure-resources die achter de schermen kunnen worden gemaakt om een gegevensmigratie uit te voeren. De gebruikte services kunnen per migratiescenario verschillen.

• Azure Monitor
• Azure VM
• Azure Storage
• Azure Service Bus
• Azure Data Factory

Intern onderhoudt DMS een metagegevensarchief met informatie over netwerklocaties, referenties, back-upbestanden en voltooide taken. Referenties en geselecteerde velden, zoals accountsleutels, worden versleuteld. Gegevens, zoals tabelnamen die kunnen worden opgenomen in telemetrie, worden gehasht. Gebruikersnamen kunnen worden weergegeven in tekst zonder opmaak in servicelogboeken, maar wachtwoorden zullen dat nooit doen. Telemetrie wordt gesiloerd per regio, beheerd door bewaarbeleid en is alleen beschikbaar voor geautoriseerd personeel binnen Microsoft voor geldige probleemoplossingsdoeleinden. Azure-resourcenamen, zoals server- en databasenamen, volgen de regels voor Azure-resources.

DMS (klassiek) maakt gebruik van Azure Service Bus-onderwerpen om de communicatie tussen rekenlagen te vergemakkelijken. De Azure Service Bus-onderwerpen zijn uniek voor elk DMS-exemplaar en alle persoonlijke gegevens worden versleuteld.

Azure SQL Managed Instance en SQL Server op virtuele Azure-machines

Schema en gegevens worden gemigreerd met back-up en herstel. Klanten hebben de keuze om te herstellen vanuit een netwerkshare of rechtstreeks vanuit een opslagcontainer. Een bestand met Windows-prestatiegegevens kan worden gebruikt om optionele (maar sterk aanbevolen) aanbevelingen voor de grootte van workloads te bieden.

Azure SQL-database

Migraties naar Azure SQL Database worden in twee stappen uitgevoerd. De eerste stap is een schemamigratie. DMS (klassiek) maakt gebruik van de SQL Management Objects (SMO) voor schemamigratie. De tweede stap is de werkelijke gegevensmigratie. SqlBulkCopy wordt gebruikt om gegevensmigratie uit te voeren. DMS biedt geen ondersteuning voor schemamigratie. Gegevens worden gemigreerd met behulp van Azure Data Factory. Optioneel, maar ten zeerste aanbevolen, kan een bestand met Windows-prestatiegegevens worden gebruikt om aanbevelingen voor de grootte van de werkbelasting te bieden.

Azure Database for PostgreSQL

In dit scenario extraheert de eindgebruiker de metagegevens, in dit geval het schema, met behulp van de pg_dump en pg_restore opdrachtregelprogramma's. Bij het configureren van wijzigingsgegevensopname voor PostgreSQL gebruikt DMS intern pg_dump gebruik en pg_restore voert dmS de eerste seeding uit voor CDC. De gegevens worden opgeslagen in een versleutelde tijdelijke opslag die alleen toegankelijk is voor uw DMS-exemplaar. Een bestand met Windows-prestatiegegevens kan worden gebruikt om optionele (maar sterk aanbevolen) aanbevelingen voor de grootte van workloads te bieden.

Azure Database for MySQL

In dit scenario worden schema-extractie en -migratie uitgevoerd door DMS (klassiek) met behulp van mysql-net /MySqlConnector. Waar mogelijk wordt de replicatie van binlog in MySQL gebruikt om zowel gegevens- als schemawijzigingen te repliceren. Aangepaste code wordt gebruikt om wijzigingen te synchroniseren waarbij binlog-replicatie niet kan worden gebruikt.

MongoDB naar Azure Cosmos DB

DMS extraheert en voegt gegevens uit een MongoDB in Cosmos DB in. Het biedt ook de mogelijkheid om de gegevens uit een BSON- of JSON-dump te extraheren.

Voor BSON-dumps gebruikt DMS de gegevens in bsondump indeling binnen dezelfde map binnen een blobcontainer. DMS zoekt alleen naar metagegevensbestanden met behulp van de indeling collection.metadata.json.

Voor JSON-dumps leest DMS de bestanden in de blobcontainermappen die zijn genoemd naar de bijbehorende databases. In elke databasemap gebruikt DMS alleen gegevensbestanden die in de data submap zijn geplaatst. DMS kijkt alleen naar bestanden die zijn geplaatst in de metadata submap en met de naam met behulp van de indeling collection.json voor metagegevens.

Oracle naar Azure SQL Database

In dit scenario wordt het AWR-rapport of een Windows-bestand perfmon gebruikt om optionele (maar ten zeerste aanbevolen) aanbevelingen voor de grootte van werkbelastingen te bieden. De gebruiker die de migratie uitvoert, gebruikt de Conversietoolkit voor databaseschema om een schemamigratie uit te voeren om de doeldatabase voor te bereiden.

Oracle naar Azure Database for PostgreSQL

Net als Oracle naar Azure SQL Database, wordt in dit scenario het AWR-rapport of een Windows-bestand perfmon gebruikt om optionele (maar sterk aanbevolen) aanbevelingen voor workloadgrootten te bieden. De ora2pg bibliotheek wordt gebruikt om het schema te extraheren en de gegevens handmatig te migreren door de gebruiker die de migratie uitvoert.

DMS (klassiek) is afhankelijk van de netwerkconfiguratie van de klant. Als de migratiebron privé-eindpunten gebruikt, gebruiken we privé-eindpunten. Dit is de voorkeursconfiguratie. We gebruiken openbare eindpunten als ze de enige optie zijn.

DMS maakt achter de schermen intensief gebruik van ADF voor het plannen en coördineren van gegevensverplaatsing. Daarnaast is de zelf-hostende Integration Runtime niet anders dan die u waarschijnlijk al gebruikt voor uw eigen ADF-pijplijnen. Zie Een zelf-hostende Integration Runtime maken en configureren voor meer informatie over problemen met firewalls en proxyservers.

Alle klantgegevens worden in rust versleuteld. Sommige metagegevens, waaronder maar niet beperkt tot namen van logische servers en databasenamen, evenals de migratiestatus en de voortgang van de migratie, worden weergegeven in servicelogboeken die niet zijn versleuteld.

Alle gegevens die onderweg zijn, worden standaard beveiligd met TLS 1.2-versleuteling. Oudere clients waarvoor oudere versies van TLS zijn vereist, moeten de vereiste versies zijn ingeschakeld op de DMS-portalpagina (klassiek). Voor DMS kan de computer waarop de zelf-hostende Integration Runtime is geïnstalleerd, worden geconfigureerd om vereiste TLS-instellingen toe te staan voor verouderde clients. Zie KB3135244 - TLS 1.2-ondersteuning voor Microsoft SQL Server voor meer informatie over TLS-configuratie voor SQL Server.

Waar mogelijk worden privé-eindpunten gebruikt. Als privé-eindpunten geen optie zijn, worden openbare eindpunten gebruikt voor communicatie tussen servicelagen. Ongeacht het eindpunttype zijn alle resources toegewezen/toegewezen aan het specifieke exemplaar van DMS en beveiligd met unieke referenties.

We bieden geen ondersteuning voor door de klant beheerde sleutels voor versleuteling van gegevens in ons gegevensvlak of besturingsvlak. Alle klantgegevens worden echter in rust versleuteld met behulp van sleutels die worden beheerd door de service. Sommige metagegevens, waaronder maar niet beperkt tot namen van logische servers en databasenamen, evenals de migratiestatus en voortgang worden weergegeven in servicelogboeken in niet-versleutelde vorm.

Alle gegevens die onderweg zijn, worden standaard versleuteld met TLS 1.2-versleuteling. Op de DMS-portalpagina (klassiek) kunnen oudere versies van TLS worden gebruikt voor verouderde clients. Voor DMS kan de computer waarop de zelf-hostende Integration Runtime is geïnstalleerd, worden geconfigureerd om het beheer van TLS-instellingen toe te staan voor verouderde clients. Zie KB3135244 - TLS 1.2-ondersteuning voor Microsoft SQL Server voor meer informatie over TLS-configuratie voor SQL Server.

De mogelijkheid voor het versleutelen van gegevens op ons besturings- of gegevensvlak met door de klant beheerde sleutels wordt niet weergegeven. Alle klantgegevens worden verwijderd zodra het DMS-exemplaar wordt verwijderd, behalve servicelogboeken. DMS-servicelogboeken worden slechts 30 dagen bewaard.

TDE

DMS ondersteunt de migratie van door de klant beheerde sleutels (CMK) naar Azure SQL voor TDE (Transparent Database Encryption). Zie zelfstudie: TDE-databases (preview) migreren naar Azure SQL in Azure Data Studio voor stapsgewijze instructies voor het migreren van uw TDE-sleutels.

Celversleuteling

Versleuteling op celniveau wordt verwerkt op schemaniveau. De hulpprogramma's voor schemamigratie migreren alle schemaobjecten, inclusief de functies en opgeslagen procedures die nodig zijn om versleuteling op celniveau te implementeren.

Altijd versleuteld

DMS biedt momenteel geen ondersteuning voor migratie van Always Encrypted via scenario's waarin afzonderlijke gegevensrijen worden gemigreerd tussen de bron en het doel. Kolommen die zijn versleuteld via Always Encrypted, worden gemigreerd zoals verwacht in scenario's waarin back-up/herstel wordt gebruikt, zoals overstappen naar Azure SQL VM of Azure SQL Managed Instance vanuit een bestaand SQL Server-exemplaar.

We implementeren geen locatiebewust toegangsbeheer buiten wat al beschikbaar is in Azure. Alle gegevens die zijn gekoppeld aan een DMS-exemplaar bevinden zich in dezelfde regio als de DMS-resource.

Onze diensten worden gebruikt in verschillende omgevingen met verschillende interne controles en bedrijfsprocessen. DMS verplaatst gegevens van en naar elke locatie waartoe het account toegang heeft. Het is de verantwoordelijkheid van de gebruiker om inzicht te krijgen in de machtigingen en interne controles van de omgeving waarin ze werken. Het is vooral belangrijk om ervoor te zorgen dat het account dat DMS gebruikt om verbinding te maken met de bron toegang heeft om alle gegevens te zien die zijn bedoeld om te worden gemigreerd van de bron.

VNET-injectie is de actie van het toevoegen van een Azure-resource die zich in de Microsoft-tenant bevindt, aan een subnet in een VNet onder de tenant van de klant. Deze benadering is gebruikt met DMS, zodat we de rekenkracht namens de klant kunnen beheren, terwijl de toegang tot klantresources nog steeds behouden blijft. Omdat het netwerk zich in het klantabonnement bevindt, kan Microsoft de VIRTUELE machine niet meer beheren dan het verlenen van opdrachten starten, stoppen, verwijderen of implementeren. Alle andere beheeracties die toegang nodig hebben tot de virtuele machine, vereisen een door de klant geïnitieerde ondersteuningsaanvraag en goedkeuring.

Er zijn verschillende vereisten vereist om ervoor te zorgen dat Azure Database Migration Service probleemloos wordt uitgevoerd bij het uitvoeren van databasemigraties. Sommige van de vereisten zijn van toepassing op alle scenario's (bron-doelparen) die door de service worden ondersteund, terwijl andere vereisten uniek zijn voor een specifiek scenario.

Vereisten voor Azure Database Migration Service die gebruikelijk zijn in alle ondersteunde migratiescenario's, omvatten de noodzaak om:

• Maak een Microsoft Azure Virtual Network voor Azure Database Migration Service met behulp van het Azure Resource Manager-implementatiemodel. Dit geeft site-naar-site-verbinding met uw on-premises bronservers met behulp van ExpressRoute of VPN.
• Zorg ervoor dat de regels voor uw virtuele netwerkbeveiligingsgroep de poort 443 voor ServiceTags van ServiceBus, Storage en AzureMonitor niet blokkeren. Zie het artikel Netwerkverkeer filteren met netwerkbeveiligingsgroepen voor meer informatie over verkeer filteren van verkeer via de netwerkbeveiligingsgroep voor virtuele netwerken.
• Wanneer u een firewallapparaat gebruikt voor de brondatabase(s), moet u mogelijk firewallregels toevoegen om voor Azure Database Migration Service toegang tot de brondatabase(s) voor de migratie toe te staan.

Zie de gerelateerde zelfstudies in de documentatie van Azure Database Migration Service voor een lijst met alle vereiste vereisten voor het concurreren met specifieke migratiescenario's met behulp van Azure Database Migration Service.

Mogelijk moet u firewallregels toevoegen waarmee Azure Database Migration Service toegang heeft tot uw brondatabase voor migratie. Het IP-adres voor de service is dynamisch, maar als u ExpressRoute gebruikt, wordt dit adres privé toegewezen door uw bedrijfsnetwerk. De eenvoudigste manier om het juiste IP-adres te identificeren, is door in dezelfde resourcegroep te zoeken als uw ingerichte Azure Database Migration Service-resource om de bijbehorende netwerkinterface te vinden. Meestal begint de naam van de netwerkinterface-resource met het voorvoegsel NIC en gevolgd door een uniek teken en een nummerreeks, bijvoorbeeld 'NIC-jj6tnztnmarpsskr82rbndyp'. Als u deze netwerkinterfaceresource selecteert, ziet u het IP-adres dat moet worden opgenomen in de acceptatielijst op de azure-portalpagina van het resourceoverzicht.

Mogelijk moet u ook de poortbron opnemen die SQL Server luistert op de acceptatielijst. Standaard is dit poort 1433, maar de bron-SQL Server kan ook worden geconfigureerd om te luisteren op andere poorten. In dit geval moet u deze poorten ook opnemen in de acceptatielijst. U kunt bepalen op welke poort SQL Server luistert met behulp van een dynamische beheerweergavequery:

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

U kunt ook bepalen welke poort SQL Server luistert door een query uit te voeren op het SQL Server-foutenlogboek:

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

Hoewel meerdere Microsoft-zelfstudies die u kunnen begeleiden bij het instellen van een virtueel netwerk, wordt de officiële documentatie weergegeven in het artikel Azure Virtual Network.

Tijdens een typische, eenvoudige databasemigratie gaat u als volgt te werk:

1. Maak een doeldatabase(s).
2. Beoordeel uw brondatabase(s).
   • Voor homogene migraties beoordeelt u uw bestaande database(s) met behulp van DMA.
   • Voor heterogene migraties (van concurrerende bronnen) beoordeelt u uw bestaande database(s) met SSMA. U gebruikt SSMA ook om databaseobjecten te converteren en het schema naar uw doelplatform te migreren.
3. Maak een exemplaar van de Azure Database Migration Service.
4. Maak een migratieproject dat de brondatabase(s), doeldatabase(s) en de tabellen opgeeft die moeten worden gemigreerd.
5. Start de volledige belasting.
6. Kies de volgende validatie.
7. Voer een handmatige overschakeling van uw productieomgeving uit naar de nieuwe clouddatabase.

Als u problemen ondervindt bij het maken van verbinding met uw brondatabasesysteem tijdens de migratie, maakt u een virtuele machine in hetzelfde subnet van het virtuele netwerk waarmee u uw DMS-exemplaar hebt ingesteld. In de virtuele machine moet u een verbindingstest kunnen uitvoeren, zoals het gebruik van een UDL-bestand om een verbinding met SQL Server te testen of Robo 3T te downloaden om MongoDB-verbindingen te testen. Als de verbindingstest slaagt, hebt u geen probleem met het maken van verbinding met uw brondatabase. Als de verbindingstest niet slaagt, neemt u contact op met de netwerkbeheerder.

Als de gebruiker Azure Database Migration Service (DMS) expliciet stopt of als de service 24 uur inactief is, heeft de service de status Gestopt of Automatisch onderbroken. In elk geval is de service niet beschikbaar en heeft de status Gestopt. Start de service opnieuw om actieve migraties te hervatten.

U kunt enkele dingen doen om uw databasemigratie te versnellen met behulp van de service:

Voor DMS(klassiek)-

• Gebruik de prijscategorie Algemeen voor meerdere CPU's wanneer u uw service-exemplaar maakt, zodat de service kan profiteren van meerdere vCPU's voor parallelle uitvoering en snellere gegevensoverdracht.
• Schaal uw Azure SQL Database-doelexemplaren tijdelijk omhoog naar de SKU van de Premium-laag tijdens de gegevensmigratiebewerking om de beperking van Azure SQL Database te minimaliseren die van invloed kunnen zijn op gegevensoverdrachtactiviteiten bij gebruik van SKU's op een lager niveau.

Voor DMS-

• Als u back-ups kopieert van lokale bestandsshare naar Azure Blob Storage OF tijdens het uitvoeren van een migratie naar Azure SQL DB, gebruikt DMS het SHIR-knooppunt als rekenproces. Zorg er dus voor dat u het resourcegebruik van dat SHIR-knooppunt bewaakt.
• Schaal uw Azure SQL Database-doelexemplaren tijdelijk omhoog naar de Premium-laag-SKU tijdens de gegevensmigratiebewerking om de beperking van Azure SQL Database-schijven te minimaliseren die van invloed kunnen zijn op gegevensoverdrachtactiviteiten bij gebruik van SKU's op een lager niveau.
• Raadpleeg de blog voor meer informatie.

Volgende stappen

• Wat is de Azure Database Migration Service.