Vanliga frågor och svar om att använda Azure Database Migration Service

Azure Database Migration Service är en fullständigt hanterad tjänst som har utformats för att möjliggöra sömlösa migreringar från flera databaskällor till Azure Data-plattformar med minimal stilleståndstid. Tjänsten är för närvarande i allmän tillgänglighet, med pågående utvecklingsarbete som fokuserar på:

• Tillförlitlighet och prestanda.
• Iterativt tillägg av källmålpar.
• Fortsatta investeringar i friktionsfria migreringar.

Tjänsten stöder för närvarande olika käll-/målpar eller migreringsscenarier. En fullständig lista över status för varje tillgängligt migreringsscenario finns i artikeln Status för migreringsscenarier som stöds av Azure Database Migration Service.

När du migrerar från SQL Server är källor som stöds för Azure Database Migration Service SQL Server 2008 och senare versioner. Om du använder Azure Data Studio med SQL Migration-tillägget är källor som stöds SQL Server 2008 via SQL Server 2022.

Du kan använda Azure Database Migration Service för att utföra offline- och onlinemigreringar. Med en offlinemigrering startar programavbrott när migreringen startar. Med en onlinemigrering är stilleståndstiden begränsad till den tid som ska minskas i slutet av migreringen. Vi rekommenderar att du testar en offlinemigrering för att avgöra om det frånkopplade tillståndet är godtagbart. Om det inte är det kan du utföra en onlinemigrering.

Azure Database Migration Service är den bästa metoden för databasmigrering till Microsoft Azure i stor skala. Mer information om hur Azure Database Migration Service jämförs med andra Migreringsverktyg för Microsoft-databaser och rekommendationer om hur du använder tjänsten för olika scenarier finns i Differentiering av Microsofts verktyg och tjänster för databasmigrering.

Azure Migrate hjälper till med migrering av lokala virtuella datorer till Azure IaaS. Tjänsten utvärderar migrerings lämplighet och prestandabaserad storleksändring och ger kostnadsuppskattningar för att köra dina lokala virtuella datorer i Azure. Azure Migrate är användbart för lift-and-shift-migreringar av lokala VM-baserade arbetsbelastningar till virtuella Azure IaaS-datorer. Till skillnad från Azure Database Migration Service är Azure Migrate dock inte ett specialiserat databasmigreringstjänsterbjudande för relationsdatabasplattformar i Azure PaaS, till exempel Azure SQL Database eller Azure SQL Managed Instance.

Nej. Database Migration Service lagrar inte kunddata.

För virtuella Azure SQL-datorer och Azure SQL MI-mål använder DMS fysisk migrering, dvs. med hjälp av säkerhetskopiering och återställning. Enligt beskrivningen nedan avgör det valda migreringsläget hur data hålls konsekventa mellan källa och mål.

• Offlinemigrering: Under offlinemigrering till virtuella Azure SQL-datorer och Azure SQL MI-mål startar programavbrott när migreringen startar. DMS återställer alla säkerhetskopierade filer till målet, så länge den senaste säkerhetskopieringsfilen/-filerna från källan har överförts till SMB-nätverkslagring eller till Azure Blob-containern (enligt migreringskonfigurationen). Om säkerhetskopieringen görs med alternativet CHECKSUM utför DMS-återställningsåtgärden automatiskt verifieringen. I avsaknad av kontrollsumma kontrolleras säkerhetskopians integritet explicit innan den återställs. Detta säkerställer att återställningsfilen är identisk med säkerhetskopian och därför har samma data. Du kan verifiera alla säkerhetskopierade filer, inklusive namnet på den senaste säkerhetskopieringsfilen från källan med säkerhetskopieringsfilen tillämpad/återställ på målet som visas på övervakningssidan för DMS-migrering och verifiera deras respektive kontrollsumma.

• Onlinemigrering: Under onlinemigreringen till virtuella Azure SQL-datorer och Azure SQL MI-mål startar stilleståndstiden när du initierar migreringen tillsammans med att stoppa programmet. DMS återställer alla säkerhetskopierade filer till målet, så länge den senaste säkerhetskopieringsfilen/-filerna från källan har överförts till SMB-nätverkslagring eller till Azure Blob-containern (enligt migreringskonfigurationen). När du har tryckt på snabbknappen visar DMS antalet väntande säkerhetskopieringsfiler (om några) som finns i SMB-nätverkslagringen eller Azure Blob-containern och som ännu inte har tillämpats/återställts på målet. Om säkerhetskopieringen görs med alternativet CHECKSUM utför DMS-återställningsåtgärden automatiskt verifieringen. I avsaknad av kontrollsumma kontrolleras säkerhetskopians integritet explicit innan den återställs. Detta säkerställer att återställningsfilen är identisk med säkerhetskopian och därför har samma data. Du kan verifiera alla säkerhetskopierade filer, inklusive namnet på den senaste säkerhetskopieringsfilen från källan med säkerhetskopieringsfilen tillämpad/återställ på målet som visas på övervakningssidan för DMS-migrering och verifiera deras respektive kontrollsumma.

För Azure SQL DB-mål utför DMS logisk migrering när det gäller Azure SQL DB, d.v.s. kopierar data från SQL-källdatabasens tabeller och skriver dem till Azure SQL DB-måltabellerna. Eftersom DMS endast stöder offlinemigrering till Azure SQL DB startar programavbrott när migreringen startar. Du kan övervaka och verifiera antalet rader som lästs (från källdatabastabellen) och kopierats (skrivs till azure SQL DB-måltabellen) från sidan för migreringsövervakning. Som ytterligare bekräftelse kan du köra TSQL:t nedan för att hämta kontrollsumma både vid käll- och måldatabaser och verifiera att käll- och återställningsdata är identiska.

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

Obs! Förutsatt att inga program/s skrivs till källan eller måldatabasen. Du kan också använda verktyg som databasjämförelseverktyg för datajämförelse.

Följande lista innehåller De Azure-resurser som kan skapas i bakgrunden för att utföra en datamigrering. De tjänster som används kan variera beroende på migreringsscenario.

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

Internt underhåller DMS ett metadatalager som innehåller information om nätverksplatser, autentiseringsuppgifter, säkerhetskopieringsfiler och slutförda uppgifter. Autentiseringsuppgifter och markerade fält, till exempel kontonycklar, krypteras. Data, till exempel tabellnamn som kan ingå i telemetri, hashas. Användarnamn kan visas i oformaterad text i tjänstloggar, men lösenord kommer aldrig att göra det. Telemetri siloeras efter region, styrs av kvarhållningsprinciper och är endast tillgängligt för auktoriserad personal inom Microsoft för giltiga felsökningsändamål. Azure-resursnamn, till exempel server- och databasnamn, följer reglerna för Azure-resurser.

DMS (klassisk) använder Azure Service Bus-ämnen för att underlätta kommunikationen mellan beräkningsskikten. Azure Service Bus-ämnena är unika för varje DMS-instans och alla personuppgifter krypteras.

Azure SQL Managed Instance och SQL Server på virtuella Azure-datorer

Schema och data migreras med hjälp av säkerhetskopiering och återställning. Kunder kan välja att återställa från en nätverksresurs eller direkt från en lagringscontainer. En fil som innehåller Windows-prestandadata kan användas för att ge valfria (men starkt rekommenderade) rekommendationer för storleksändring av arbetsbelastningar.

Azure SQL Database

Migreringar till Azure SQL Database utförs i två steg. Det första steget är en schemamigrering. DMS (klassisk) använder SQL Management Objects (SMO) för schemamigrering. Det andra steget är den faktiska datamigreringen. SqlBulkCopy används för att utföra datamigrering. DMS stöder inte schemamigrering. Data migreras med Azure Data Factory. Om du vill men rekommenderas starkt kan en fil som innehåller Windows-prestandadata användas för att ge arbetsbelastningens storleksrekommendationer.

Azure Database for PostgreSQL

I det här scenariot extraherar slutanvändaren metadata, i det här fallet schemat, med hjälp av kommandoradsverktygen pg_dump och pg_restore . När du konfigurerar insamling av ändringsdata för PostgreSQL använder pg_dump DMS internt och pg_restore för att utföra den första seedingen för CDC. Data lagras i en krypterad tillfällig lagring som endast är tillgänglig för din DMS-instans. En fil som innehåller Windows-prestandadata kan användas för att ge valfria (men starkt rekommenderade) rekommendationer för storleksändring av arbetsbelastningar.

Azure Database for MySQL

I det här scenariot utförs schemaextrahering och migrering av DMS (klassisk) med hjälp av mysql-net/MySql Anslut or. När det är möjligt används Replikering av MySQL-binlog för att replikera både data och schemaändringar. Anpassad kod används för att synkronisera ändringar där binlogreplikering inte kan användas.

MongoDB till Azure Cosmos DB

DMS extraherar och infogar data från en MongoDB till Cosmos DB. Det erbjuder också alternativet att extrahera data från en BSON- eller JSON-dump.

För BSON-dumpar använder DMS data i format i bsondump samma mapp i en blobcontainer. DMS söker bara efter metadatafiler med formatet collection.metadata.json.

För JSON-dumpar läser DMS filerna i blobcontainerns mappar med namnet efter de innehållande databaserna. I varje databasmapp använder DMS endast datafiler som placeras i undermappen data . DMS tittar bara på filer som placeras i undermappen metadata och namnges med hjälp av formatet collection.json för metadata.

Oracle till Azure SQL Database

I det här scenariot används AWR-rapporten eller en Windows-fil perfmon för att ge valfria (men starkt rekommenderade) arbetsbelastningsstorleksrekommendationer. Användaren som utför migreringen använder verktyget för databasschemakonvertering för att utföra en schemamigrering för att förbereda måldatabasen.

Oracle till Azure Database for PostgreSQL

Precis som Oracle till Azure SQL Database används AWR-rapporten eller en Windows-fil perfmon i det här scenariot för att tillhandahålla valfria (men starkt rekommenderade) arbetsbelastningsstorleksrekommendationer. Biblioteket ora2pg används för att extrahera schemat och migrera data manuellt av användaren som utför migreringen.

DMS (klassisk) förlitar sig på kundens nätverkskonfiguration. Om migreringskällan använder privata slutpunkter använder vi privata slutpunkter, vilket är den föredragna konfigurationen. Vi använder offentliga slutpunkter om de är det enda alternativet.

DMS använder ADF i bakgrunden för schemaläggning och samordning av dataflytt. Dessutom skiljer sig inte den lokalt installerade integrationskörningen från den som du förmodligen redan använder för dina egna ADF-pipelines. Mer information om problem med brandväggs- och proxyserver finns i Skapa och konfigurera en lokalt installerad integrationskörning.

Alla kunddata krypteras i vila. Vissa metadata, inklusive men inte begränsat till logiska servernamn och databasnamn, samt migreringsstatus och migreringsförlopp visas i tjänstloggar som inte är krypterade.

Alla data under överföring skyddas med TLS 1.2-kryptering som standard. Äldre klienter som kräver äldre versioner av TLS behöver de nödvändiga versionerna aktiverade på sidan för DMS-portalen (klassisk). För DMS kan datorn där den lokalt installerade integrationskörningen är installerad konfigureras för att tillåta nödvändiga TLS-inställningar för äldre klienter. Mer information om TLS-konfiguration för SQL Server finns i KB3135244 – TLS 1.2-stöd för Microsoft SQL Server.

När det är möjligt används privata slutpunkter. Om privata slutpunkter inte är ett alternativ används offentliga slutpunkter för kommunikation mellan tjänstskikt. Oavsett slutpunktstyp är alla resurser dedikerade/begränsade till den specifika instansen av DMS och skyddas med unika autentiseringsuppgifter.

Vi stöder inte kundhanterade nycklar för kryptering av data i vårt dataplan eller kontrollplan. Alla kunddata krypteras dock i vila med hjälp av nycklar som hanteras av tjänsten. Vissa metadata, inklusive men inte begränsat till logiska servernamn och databasnamn, samt migreringsstatus och förlopp visas i tjänstloggar i okrypterat format.

Alla data under överföring krypteras med TLS 1.2-kryptering som standard. På dms-portalsidan (klassisk) kan äldre versioner av TLS användas för äldre klienter. För DMS den dator där den lokalt installerade integrationskörningen är installerad kan konfigureras för att tillåta hantering av TLS-inställningar för äldre klienter. Mer information om TLS-konfiguration för SQL Server finns i KB3135244 – TLS 1.2-stöd för Microsoft SQL Server.

Vi exponerar inte möjligheten att kryptera data på vårt kontroll- eller dataplan med kundhanterade nycklar. Alla kunddata tas bort när DMS-instansen tas bort förutom tjänstloggar. DMS-tjänstloggar sparas endast i 30 dagar.

TDE

DMS stöder migrering av kundhanterade nycklar (CMK) till Azure SQL for Transparent Database Encryption (TDE). Stegvisa instruktioner för att migrera dina TDE-nycklar finns i Självstudie: Migrera TDE-aktiverade databaser (förhandsversion) till Azure SQL i Azure Data Studio.

Cellkryptering

Kryptering på cellnivå hanteras på schemanivå. Schemamigreringsverktygen migrerar alla schemaobjekt, inklusive de funktioner och lagrade procedurer som krävs för att implementera kryptering på cellnivå.

Alltid krypterad

DMS stöder för närvarande inte migrering av Always Encrypted via scenarier där enskilda datarader migreras mellan källa och mål. Kolumner som krypteras via Always Encrypted migreras som förväntat i scenarier som använder säkerhetskopiering/återställning, som att flytta till en virtuell Azure SQL-dator eller En hanterad Azure SQL-instans från en befintlig SQL Server-instans.

Vi implementerar ingen platsmedveten åtkomstkontroll utöver vad som redan är tillgängligt i Azure. Alla data som är associerade med en DMS-instans finns i samma region som DMS-resursen.

Våra tjänster används i olika miljöer med olika interna kontroller och affärsprocesser. DMS flyttar data från och till var som helst som kontot det använder har åtkomst till. Det är användarens ansvar att förstå behörigheter och interna kontroller i den miljö de arbetar i. Det är särskilt viktigt att se till att det konto som DMS använder för att ansluta till källan har åtkomst för att se alla data som är avsedda att migreras från källan.

VNET-inmatning är åtgärden att lägga till en Azure-resurs som finns i Microsoft-klientorganisationen i ett undernät i ett virtuellt nätverk under kundens klientorganisation. Den här metoden användes med DMS för att vi skulle kunna hantera beräkningen för kundens räkning, samtidigt som åtkomsten till kundresurserna bibehålls. Eftersom nätverket finns i en kundprenumeration kan Microsoft inte hantera den virtuella datorn utöver att utfärda kommandona Start, Stoppa, Ta bort eller Distribuera. Alla andra hanteringsåtgärder som behöver åtkomst till den virtuella datorn kräver en kundinitierad supportbegäran och godkännande.

Det finns flera krav som krävs för att säkerställa att Azure Database Migration Service fungerar smidigt när du utför databasmigreringar. Vissa av förutsättningarna gäller för alla scenarier (par av källa/mål) som tjänsten har stöd för, medan andra förutsättningar är specifika för ett visst scenario.

Förutsättningar för Azure Database Migration Service som är vanliga i alla migreringsscenarier som stöds är bland annat behovet av att:

• Skapa ett virtuellt Azure-nätverk för Azure Database Migration Service genom att använda Azure Resource Manager-distributionsmodellen, som ger plats-till-plats-anslutning för dina lokala källservrar genom att använda antingen ExpressRoute eller VPN.
• Se till att reglerna för nätverkssäkerhetsgruppen för det virtuella nätverket inte blockerar port 443 för ServiceTags för ServiceBus, Storage och AzureMonitor. Mer information om trafikfiltrering för virtuella nätverk NSG finns i artikeln Filtrera nätverkstrafik med nätverkssäkerhetsgrupper.
• När du använder en brandväggsinstallation framför dina källdatabaser kanske du måste lägga till brandväggsregler för att tillåta Azure Database Migration Service att komma åt källdatabaserna för migrering.

En lista över alla krav som krävs för att konkurrera med specifika migreringsscenarier med Hjälp av Azure Database Migration Service finns i de relaterade självstudierna i dokumentationen för Azure Database Migration Service.

Du kan behöva lägga till brandväggsregler som gör att Azure Database Migration Service kan komma åt källdatabasen för migrering. IP-adressen för tjänsten är dynamisk, men om du använder ExpressRoute tilldelas den här adressen privat av företagets nätverk. Det enklaste sättet att identifiera lämplig IP-adress är att titta i samma resursgrupp som din etablerade Azure Database Migration Service-resurs för att hitta det associerade nätverksgränssnittet. Vanligtvis börjar namnet på nätverksgränssnittsresursen med NIC-prefixet och följs av ett unikt tecken och en nummersekvens, till exempel "NIC-jj6tnztnmarpsskr82rbndyp". Genom att välja den här nätverksgränssnittsresursen kan du se den IP-adress som måste ingå i listan över tillåtna på azure-portalsidan för resursöversikt.

Du kan också behöva inkludera portkällan som SQL Server lyssnar på listan över tillåtna. Som standard är det port 1433, men SQL Server-källan kan också konfigureras för att lyssna på andra portar. I det här fallet måste du även inkludera dessa portar på listan över tillåtna portar. Du kan fastställa den port som SQL Server lyssnar på med hjälp av en fråga för dynamisk hanteringsvy:

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

Du kan också fastställa porten som SQL Server lyssnar på genom att fråga SQL Server-felloggen:

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

Även om flera Microsoft-självstudier som kan vägleder dig genom processen att konfigurera ett virtuellt nätverk visas den officiella dokumentationen i artikeln Azure Virtual Network.

Under en vanlig, enkel databasmigrering gör du följande:

1. Skapa en eller flera måldatabaser.
2. Utvärdera dina källdatabaser.
   • För homogena migreringar utvärderar du dina befintliga databaser med hjälp av DMA.
   • För heterogena migreringar (från konkurrenskällor) utvärderar du dina befintliga databaser med SSMA. Du använder också SSMA för att konvertera databasobjekt och migrera schemat till målplattformen.
3. Skapa en instans av Azure Database Migration Service.
4. Skapa ett migreringsprojekt som anger källdatabaserna, måldatabaserna och tabellerna som ska migreras.
5. Starta den fullständiga belastningen.
6. Välj den efterföljande verifieringen.
7. Utför en manuell övergång av produktionsmiljön till den nya molnbaserade databasen.

Om du har problem med att ansluta till källdatabassystemet när du arbetar med migreringen skapar du en virtuell dator i samma undernät i det virtuella nätverk som du konfigurerade DMS-instansen med. På den virtuella datorn bör du kunna köra ett anslutningstest, till exempel att använda en UDL-fil för att testa en anslutning till SQL Server eller ladda ned Robo 3T för att testa MongoDB-anslutningar. Om anslutningstestet lyckas bör du inte ha problem med att ansluta till källdatabasen. Kontakta nätverksadministratören om anslutningstestet inte lyckas.

Om användaren uttryckligen stoppar Azure Database Migration Service (DMS) eller om tjänsten är inaktiv i 24 timmar är tjänsten i ett stoppat eller automatiskt pausat tillstånd. I varje fall är tjänsten inte tillgänglig och har statusen stoppad. Starta om tjänsten om du vill återuppta aktiva migreringar.

Du kan göra några saker för att påskynda databasmigreringen med hjälp av tjänsten:

• Använd prisnivån för flera processorer med Generell användning när du skapar tjänstinstansen så att tjänsten kan dra nytta av flera virtuella processorer för parallellisering och snabbare dataöverföring.
• Skala tillfälligt upp din Azure SQL Database-målinstans till Premium-nivå-SKU:n under datamigreringsåtgärden för att minimera Azure SQL Database-begränsning som kan påverka dataöverföringsaktiviteter när du använder SKU:er på lägre nivå.

Nästa steg

• Vad är Azure Database Migration Service.