Często zadawane pytania dotyczące korzystania z usługi Azure Database Migration Service

Azure Database Migration Service to w pełni zarządzana usługa, która umożliwia bezproblemowe migracje z wielu źródeł baz danych do platform danych Azure z minimalnym przestojem. Usługa jest obecnie ogólnie dostępna, a ciągłe prace programistyczne koncentrują się na następujących kwestiach:

• Niezawodność i wydajność.
• Iteracyjne dodawanie par źródłowych docelowych.
• Ciągłe inwestycje w migracje bez problemów.

Usługa obsługuje obecnie różne pary źródłowe/docelowe lub scenariusze migracji. Aby uzyskać pełną listę stanu każdego dostępnego scenariusza migracji, zobacz artykuł Stan scenariuszy migracji obsługiwanych przez usługę Azure Database Migration Service.

Podczas migracji z programu SQL Server obsługiwane źródła dla usługi Azure Database Migration Service to SQL Server 2008 i nowsze wersje. Jeśli używasz programu Azure Data Studio z rozszerzeniem SQL Migration, obsługiwane źródła to SQL Server 2008 do programu SQL Server 2022.

Usługi Azure Database Migration Service można używać do przeprowadzania migracji w trybie offline i online. W przypadku migracji w trybie offline przestój aplikacji rozpoczyna się po rozpoczęciu migracji. W przypadku migracji online przestój jest ograniczony do czasu, który zostanie skrócony po zakończeniu migracji. Zalecamy przetestowanie migracji offline w celu ustalenia, czy przestój jest dopuszczalny. Jeśli nie jest on dopuszczalny, przeprowadź migrację online.

Usługa Azure Database Migration Service jest preferowaną metodą migracji bazy danych na platformę Microsoft Azure na dużą skalę. Aby uzyskać więcej informacji na temat porównywania usługi Azure Database Migration Service z innymi narzędziami do migracji baz danych firmy Microsoft oraz zaleceń dotyczących korzystania z usługi w różnych scenariuszach, zobacz Różne narzędzia i usługi migracji baz danych firmy Microsoft.

Usługa Azure Migrate pomaga w migracji lokalnych maszyn wirtualnych do usługi Azure IaaS. Usługa ocenia odpowiedniość migracji i ustalanie rozmiaru na podstawie wydajności oraz zapewnia szacowane koszty uruchamiania lokalnych maszyn wirtualnych na platformie Azure. Usługa Azure Migrate jest przydatna w przypadku migracji metodą "lift-and-shift" obciążeń lokalnych maszyn wirtualnych do maszyn wirtualnych IaaS platformy Azure. Jednak w przeciwieństwie do usługi Azure Database Migration Service usługa Azure Migrate nie jest wyspecjalizowaną usługą migracji baz danych dla platform relacyjnych baz danych PaaS, takich jak Azure SQL Database lub Azure SQL Managed Instance.

L.p. Usługa Database Migration Service nie przechowuje danych klientów.

W przypadku maszyn wirtualnych usługi Azure SQL i docelowych wystąpień mi usługi Azure SQL usługa DMS używa migracji fizycznej, tj. przy użyciu kopii zapasowej i przywracania. Jak opisano poniżej, wybrany tryb migracji określa sposób, w jaki dane są spójne między źródłem a obiektem docelowym.

• Migracja w trybie offline: podczas migracji w trybie offline do maszyny wirtualnej azure SQL i obiektów docelowych usługi Azure SQL MI przestój aplikacji rozpoczyna się po rozpoczęciu migracji. Usługa DMS przywróci wszystkie pliki kopii zapasowej do obiektu docelowego, o ile najnowsze pliki kopii zapasowej/s ze źródła zostały przeniesione do magazynu sieciowego SMB lub do kontenera obiektów blob platformy Azure (zgodnie z konfiguracją migracji). Jeśli kopia zapasowa jest wykonywana z opcją CHECKSUM, operacja przywracania DMS automatycznie przeprowadza walidację. W przypadku braku sumy kontrolnej integralność kopii zapasowej jest jawnie sprawdzana przed przywróceniem. Gwarantuje to, że plik przywracania jest identyczny z plikiem kopii zapasowej i dlatego mają te same dane. Możesz sprawdzić wszystkie pliki kopii zapasowej, w tym nazwę ostatniego pliku kopii zapasowej ze źródła, z plikiem kopii zapasowej zastosowanym/przywracaniem w lokalizacji docelowej wyświetlanej na stronie monitorowania migracji usługi DMS i sprawdzić poprawność ich odpowiedniej sumy kontrolnej.

• Migracja online: podczas migracji online na maszynę wirtualną Azure SQL i cele mi usługi Azure SQL przestój rozpoczyna się po zainicjowaniu migracji jednorazowej wraz z zatrzymaniem aplikacji. Usługa DMS przywróci wszystkie pliki kopii zapasowej do obiektu docelowego, o ile najnowsze pliki kopii zapasowej/s ze źródła zostały przeniesione do magazynu sieciowego SMB lub do kontenera obiektów blob platformy Azure (zgodnie z konfiguracją migracji). Po naciśnięciu przycisku migracji jednorazowej usługa DMS wyświetla liczbę oczekujących plików kopii zapasowych (jeśli istnieją) znajdujących się w magazynie sieci SMB lub kontenerze obiektów blob platformy Azure, a jeszcze do zastosowania/przywracania w miejscu docelowym. Jeśli kopia zapasowa jest wykonywana z opcją CHECKSUM, operacja przywracania DMS automatycznie przeprowadza walidację. W przypadku braku sumy kontrolnej integralność kopii zapasowej jest jawnie sprawdzana przed przywróceniem. Gwarantuje to, że plik przywracania jest identyczny z plikiem kopii zapasowej i dlatego mają te same dane. Możesz sprawdzić wszystkie pliki kopii zapasowej, w tym nazwę ostatniego pliku kopii zapasowej ze źródła, z plikiem kopii zapasowej zastosowanym/przywracaniem w lokalizacji docelowej wyświetlanej na stronie monitorowania migracji usługi DMS i sprawdzić poprawność ich odpowiedniej sumy kontrolnej.

W przypadku obiektów docelowych usługi Azure SQL DB usługa DMS wykonuje migrację logiczną w przypadku usługi Azure SQL DB, tj. kopiuje dane z tabel źródłowej bazy danych SQL Database i zapisuje je w tabelach docelowej bazy danych Azure SQL DB. Ponieważ usługa DMS obsługuje tylko migrację w trybie offline do usługi Azure SQL DB, czas przestoju aplikacji rozpoczyna się po rozpoczęciu migracji. Możesz monitorować i weryfikować liczbę odczytanych wierszy (z tabeli źródłowej bazy danych) i skopiowanych (zapisanych w docelowej tabeli usługi Azure SQL DB) ze strony monitorowania migracji. Jako dodatkowe potwierdzenie możesz uruchomić poniższy TSQL, aby pobrać sumę kontrolną zarówno w źródłowych, jak i docelowych bazach danych oraz sprawdzić, czy źródło i przywracanie danych są identyczne.

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

Uwaga: pod warunkiem, że aplikacja/s nie jest zapisywana w źródle lub docelowej bazie danych. Możesz również użyć narzędzi, takich jak narzędzie do porównywania baz danych na potrzeby porównywania danych.

Poniższa lista zawiera zasoby platformy Azure, które mogą zostać utworzone w tle w celu przeprowadzenia migracji danych. Używane usługi mogą się różnić w zależności od scenariusza migracji.

• Azure Monitor
• Maszyna wirtualna platformy Azure
• Azure Storage
• Azure Service Bus
• Azure Data Factory

Wewnętrznie usługa DMS utrzymuje magazyn metadanych, który zawiera informacje o lokalizacjach sieciowych, poświadczeniach, plikach kopii zapasowych i ukończonych zadaniach. Poświadczenia i wybrane pola, takie jak klucze konta, są szyfrowane. Dane, takie jak nazwy tabel, które mogą być uwzględnione w telemetrii, są skrótami. Nazwy użytkowników mogą być wyświetlane w postaci zwykłego tekstu w dziennikach usługi, ale hasła nigdy nie będą. Dane telemetryczne są silosowane według regionów, zarządzane przez zasady przechowywania i dostępne tylko dla autoryzowanych pracowników w firmie Microsoft w celu prawidłowego rozwiązywania problemów. Nazwy zasobów platformy Azure, takie jak nazwy serwerów i baz danych, są zgodne z regułami dotyczącymi zasobów platformy Azure.

Usługa DMS (wersja klasyczna) korzysta z tematów usługi Azure Service Bus w celu ułatwienia komunikacji między warstwami obliczeniowymi. Tematy usługi Azure Service Bus są unikatowe dla każdego wystąpienia usługi DMS, a wszystkie dane osobowe są szyfrowane.

Usługa Azure SQL Managed Instance i program SQL Server na maszynach wirtualnych platformy Azure

Schemat i dane są migrowane przy użyciu kopii zapasowej i przywracania. Klienci mają możliwość przywrócenia z udziału sieciowego lub bezpośrednio z kontenera magazynu. Plik zawierający dane wydajności systemu Windows może być używany w celu udostępnienia opcjonalnych (ale zdecydowanie zalecanych) zaleceń dotyczących rozmiarów obciążeń.

Azure SQL Database

Migracje do usługi Azure SQL Database są wykonywane w dwóch krokach. Pierwszym krokiem jest migracja schematu. Usługa DMS (wersja klasyczna) używa obiektów zarządzania SQL (SMO) do migracji schematu. Drugim krokiem jest rzeczywista migracja danych. Narzędzie SqlBulkCopy służy do przeprowadzania migracji danych. Usługa DMS nie obsługuje migracji schematu. Dane są migrowane przy użyciu usługi Azure Data Factory. Opcjonalnie, ale zdecydowanie zalecane, plik zawierający dane wydajności systemu Windows może być używany w celu udostępnienia zaleceń dotyczących rozmiaru obciążenia.

Azure Database for PostgreSQL

W tym scenariuszu użytkownik końcowy wyodrębnia metadane, w tym przypadku schemat przy użyciu pg_dump narzędzi wiersza polecenia i pg_restore . Podczas konfigurowania przechwytywania zmian danych dla bazy danych PostgreSQL usługa DMS wewnętrznie używa pg_dump funkcji i pg_restore do wykonywania początkowego rozmieszczania dla usługi CDC. Dane są przechowywane w zaszyfrowanym magazynie tymczasowym, który jest dostępny tylko dla wystąpienia usługi DMS. Plik zawierający dane wydajności systemu Windows może być używany w celu udostępnienia opcjonalnych (ale zdecydowanie zalecanych) zaleceń dotyczących rozmiarów obciążeń.

Azure Database for MySQL

W tym scenariuszu wyodrębnianie schematu i migracja są wykonywane przez usługę DMS (klasyczną ) przy użyciu programu mysql-net/MySqlConnector. Jeśli to możliwe, replikacja dziennika binlogu mySQL służy do replikowania zmian danych i schematu. Kod niestandardowy służy do synchronizowania zmian, w których nie można używać replikacji binlog.

Baza danych MongoDB do usługi Azure Cosmos DB

Usługa DMS wyodrębnia i wstawia dane z bazy danych MongoDB do usługi Cosmos DB. Oferuje również opcję wyodrębniania danych z zrzutu BSON lub JSON.

W przypadku zrzutów BSON usługa DMS używa danych w bsondump formacie w tym samym folderze w kontenerze obiektów blob. Usługa DMS wyszukuje tylko pliki metadanych w formacie collection.metadata.json.

W przypadku zrzutów w formacie JSON usługa DMS odczytuje pliki w folderach kontenerów obiektów blob o nazwie od zawierającej bazy danych. W każdym folderze bazy danych usługa DMS używa tylko plików danych umieszczonych w data podfolderze. Usługa DMS analizuje tylko pliki umieszczone w metadata podfolderze i nazwane przy użyciu formatu collection.json metadanych.

Oracle do usługi Azure SQL Database

W tym scenariuszu raport AWR lub plik systemu Windows perfmon jest używany w celu udostępnienia opcjonalnych (ale zdecydowanie zalecanych) zaleceń dotyczących rozmiarów obciążeń. Użytkownik wykonujący migrację używa Zestaw narzędzi do konwersji schematu bazy danych do przeprowadzenia migracji schematu w celu przygotowania docelowej bazy danych.

Oracle to Azure Database for PostgreSQL

Podobnie jak oracle w usłudze Azure SQL Database, w tym scenariuszu raport AWR lub plik systemu Windows perfmon jest używany w celu udostępnienia opcjonalnych (ale zdecydowanie zalecanych) zaleceń dotyczących rozmiarów obciążeń. Biblioteka ora2pg służy do wyodrębniania schematu i ręcznego migrowania danych przez użytkownika wykonującego migrację.

Usługa DMS (wersja klasyczna) opiera się na konfiguracji sieci klienta. Jeśli źródło migracji używa prywatnych punktów końcowych, używamy prywatnych punktów końcowych, co jest preferowaną konfiguracją. Używamy publicznych punktów końcowych, jeśli są one jedyną opcją.

Usługa DMS intensywnie używa usługi ADF w tle do planowania i koordynacji przenoszenia danych. Ponadto własne środowisko Integration Runtime nie różni się od tego, którego prawdopodobnie używasz już do własnych potoków usługi ADF. Aby uzyskać więcej informacji na temat problemów z zaporą i serwerem proxy, zobacz Tworzenie i konfigurowanie własnego środowiska Integration Runtime.

Wszystkie dane klienta są szyfrowane w spoczynku. Niektóre metadane, w tym nazwy serwerów logicznych i nazwy baz danych, a także stan migracji i postęp migracji są wyświetlane w dziennikach usługi, które nie są szyfrowane.

Wszystkie dane przesyłane są domyślnie chronione za pomocą szyfrowania TLS 1.2. Starsi klienci, którzy wymagają starszych wersji protokołu TLS, potrzebują wymaganych wersji włączonych na stronie portalu DMS (wersja klasyczna). W przypadku usługi DMS maszyny, na której zainstalowano własne środowisko Integration Runtime, można skonfigurować tak, aby zezwalać na wymagane ustawienia protokołu TLS w celu uwzględnienia starszych klientów. Aby uzyskać więcej informacji na temat konfiguracji protokołu TLS dla programu SQL Server, zobacz KB3135244 — obsługa protokołu TLS 1.2 dla programu Microsoft SQL Server.

Wszędzie tam, gdzie to możliwe, są używane prywatne punkty końcowe. Jeśli prywatne punkty końcowe nie są opcją, publiczne punkty końcowe są używane do komunikacji między warstwami usług. Niezależnie od typu punktu końcowego wszystkie zasoby są dedykowane/ograniczone do określonego wystąpienia usługi DMS i zabezpieczone przy użyciu unikatowych poświadczeń.

Nie obsługujemy kluczy zarządzanych przez klienta na potrzeby szyfrowania danych w naszej płaszczyźnie danych ani płaszczyźnie sterowania. Jednak wszystkie dane klienta są szyfrowane w spoczynku przy użyciu kluczy zarządzanych przez usługę. Niektóre metadane, w tym nazwy serwerów logicznych i nazwy baz danych, a także stan migracji i postęp są wyświetlane w dziennikach usługi w postaci niezaszyfrowanej.

Wszystkie dane przesyłane są domyślnie szyfrowane przy użyciu szyfrowania TLS 1.2. Strona portalu DMS (wersja klasyczna) umożliwia korzystanie ze starszych wersji protokołu TLS dla starszych klientów. W przypadku usługi DMS maszyny, na której zainstalowano własne środowisko Integration Runtime, można skonfigurować tak, aby umożliwić zarządzanie ustawieniami protokołu TLS w celu uwzględnienia starszych klientów. Aby uzyskać więcej informacji na temat konfiguracji protokołu TLS dla programu SQL Server, zobacz KB3135244 — obsługa protokołu TLS 1.2 dla programu Microsoft SQL Server.

Nie ujawniamy możliwości szyfrowania danych na naszej płaszczyźnie kontroli lub danych przy użyciu kluczy zarządzanych przez klienta. Wszystkie dane klienta są usuwane w momencie usunięcia wystąpienia usługi DMS z wyjątkiem dzienników usług. Dzienniki usługi DMS są przechowywane tylko przez 30 dni.

Transparent Data Encryption

Usługa DMS obsługuje migrację kluczy zarządzanych przez klienta (CMK) do usługi Azure SQL dla funkcji Transparent Database Encryption (TDE). Aby uzyskać instrukcje krok po kroku dotyczące migracji kluczy TDE, zobacz Samouczek: migrowanie baz danych z obsługą funkcji TDE (wersja zapoznawcza) do usługi Azure SQL w narzędziu Azure Data Studio.

Szyfrowanie komórek

Szyfrowanie na poziomie komórki jest obsługiwane na poziomie schematu. Narzędzia migracji schematu migrują wszystkie obiekty schematu, w tym funkcje i procedury składowane niezbędne do zaimplementowania szyfrowania na poziomie komórki.

Zawsze szyfrowane

Usługa DMS nie obsługuje obecnie migracji funkcji Always Encrypted za pośrednictwem scenariuszy, w których poszczególne wiersze danych są migrowane między źródłem a obiektem docelowym. Kolumny szyfrowane za pośrednictwem funkcji Always Encrypted są migrowane zgodnie z oczekiwaniami w scenariuszach korzystających z kopii zapasowych/przywracania, takich jak przenoszenie do maszyny wirtualnej Azure SQL lub wystąpienia zarządzanego usługi Azure SQL z istniejącego wystąpienia programu SQL Server.

Nie implementujemy żadnej kontroli dostępu obsługującej lokalizację poza tym, co jest już dostępne na platformie Azure. Wszystkie dane skojarzone z wystąpieniem usługi DMS znajdują się w tym samym regionie co zasób usługi DMS.

Nasze usługi są używane w różnych środowiskach z różnymi wewnętrznymi mechanizmami kontroli i procesami biznesowymi. Usługa DMS przenosi dane z i do dowolnego miejsca, do którego używa konta, ma dostęp. To użytkownik jest odpowiedzialny za zrozumienie uprawnień i wewnętrznych mechanizmów kontroli środowiska, w których pracują. Szczególnie ważne jest, aby upewnić się, że konto używane przez usługę DMS do nawiązywania połączenia ze źródłem ma dostęp, aby wyświetlić wszystkie dane, które mają zostać zmigrowane ze źródła.

Iniekcja sieci wirtualnej to akcja dodawania zasobu platformy Azure znajdującego się w dzierżawie firmy Microsoft do podsieci w sieci wirtualnej w ramach dzierżawy klienta. Takie podejście zostało podjęte za pomocą usługi DMS, aby umożliwić nam zarządzanie obliczeniami w imieniu klienta, zachowując jednocześnie dostęp do zasobów klientów. Ponieważ sieć znajduje się w subskrypcji klienta, firma Microsoft nie może zarządzać maszyną wirtualną poza wydawaniem poleceń uruchamiania, zatrzymywania, usuwania lub wdrażania. Wszystkie inne akcje zarządzania wymagające dostępu do maszyny wirtualnej wymagają żądania i zatwierdzenia zainicjowanego przez klienta.

Istnieje kilka wymagań wstępnych wymaganych do zapewnienia bezproblemowego działania usługi Azure Database Migration Service podczas przeprowadzania migracji bazy danych. Niektóre wymagania wstępne mają zastosowanie we wszystkich scenariuszach (pary źródło-cel) obsługiwanych przez usługę, podczas gdy inne wymagania wstępne są unikatowe dla konkretnego scenariusza.

Wymagania wstępne usługi Azure Database Migration Service, które są wspólne we wszystkich obsługiwanych scenariuszach migracji, obejmują następujące kwestie:

• Utworzenie usługi Microsoft Azure Virtual Network dla usługi Azure Database Migration Service przy użyciu modelu wdrożenia usługi Azure Resource Manager, która zapewnia łączność między lokacjami dla lokalnych serwerów źródłowych, z użyciem usługi ExpressRoute lub sieci VPN.
• Upewnij się, że reguły sieciowej grupy zabezpieczeń sieci wirtualnej nie blokują portu 443 dla elementów ServiceTags usług ServiceBus, Storage i AzureMonitor. Aby uzyskać więcej informacji na temat filtrowania ruchu sieciowej grupy zabezpieczeń sieci wirtualnej, zapoznaj się z artykułem Filtrowanie ruchu sieciowego przy użyciu sieciowych grup zabezpieczeń.
• W przypadku korzystania z urządzenia zapory przed źródłowymi bazami danych konieczne może być dodanie reguł zapory, aby zezwolić usłudze Azure Database Migration Service na dostęp do źródłowej bazy danych podczas migracji.

Aby uzyskać listę wszystkich wymagań wstępnych wymaganych do konkurowania określonych scenariuszy migracji przy użyciu usługi Azure Database Migration Service, zobacz powiązane samouczki w dokumentacji usługi Azure Database Migration Service.

Może być konieczne dodanie reguł zapory umożliwiających usłudze Azure Database Migration Service dostęp do źródłowej bazy danych na potrzeby migracji. Adres IP usługi jest dynamiczny, ale jeśli używasz usługi ExpressRoute, ten adres jest przypisywany prywatnie przez sieć firmową. Najprostszym sposobem zidentyfikowania odpowiedniego adresu IP jest wyszukanie tej samej grupy zasobów co zasób aprowizowania usługi Azure Database Migration Service w celu znalezienia skojarzonego interfejsu sieciowego. Zazwyczaj nazwa zasobu interfejsu sieciowego rozpoczyna się od prefiksu karty sieciowej, a następnie unikatowego znaku i sekwencji liczb, na przykład "NIC-jj6tnztnmarpsskr82rbndyp". Wybierając ten zasób interfejsu sieciowego, możesz zobaczyć adres IP, który musi zostać uwzględniony na liście dozwolonych na stronie przeglądu zasobu w witrynie Azure Portal.

Może być również konieczne uwzględnienie źródła portów, na którym nasłuchuje program SQL Server na liście dozwolonych. Domyślnie jest to port 1433, ale źródłowy program SQL Server może być również skonfigurowany do nasłuchiwania na innych portach. W takim przypadku należy również uwzględnić te porty na liście dozwolonych. Port, na którym nasłuchuje program SQL Server, można określić przy użyciu zapytania dynamicznego widoku zarządzania:

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

Możesz również określić port, na którym nasłuchuje program SQL Server, wysyłając zapytanie do dziennika błędów programu SQL Server:

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

Podczas gdy wiele samouczków firmy Microsoft, które mogą zapoznać się z procesem konfigurowania sieci wirtualnej, oficjalna dokumentacja zostanie wyświetlona w artykule Azure Virtual Network.

Podczas typowej, prostej migracji bazy danych:

1. Utwórz docelowe bazy danych.
2. Oceń źródłowe bazy danych.
   • W przypadku homogenicznych migracji oceń istniejące bazy danych przy użyciu narzędzia DMA.
   • W przypadku migracji heterogenicznych (ze źródeł konkurencyjnych) oceń istniejące bazy danych za pomocą programu SSMA. Program SSMA umożliwia również konwertowanie obiektów bazy danych i migrowanie schematu na platformę docelową.
3. Utwórz wystąpienie usługi Azure Database Migration Service.
4. Utwórz projekt migracji określający źródłowe bazy danych, docelowe bazy danych i tabele do migracji.
5. Uruchom pełne ładowanie.
6. Wybierz kolejną walidację.
7. Wykonaj ręczne przełączanie środowiska produkcyjnego do nowej bazy danych opartej na chmurze.

Jeśli masz problemy z nawiązaniem połączenia z źródłowym systemem bazy danych podczas pracy nad migracją, utwórz maszynę wirtualną w tej samej podsieci sieci wirtualnej, za pomocą której skonfigurowaliśmy wystąpienie usługi DMS. Na maszynie wirtualnej powinno być możliwe uruchomienie testu połączenia, takiego jak użycie pliku UDL do przetestowania połączenia z programem SQL Server lub pobranie programu Robo 3T w celu przetestowania połączeń bazy danych MongoDB. Jeśli test połączenia zakończy się pomyślnie, nie powinno być problemu z nawiązywaniem połączenia ze źródłową bazą danych. Jeśli test połączenia nie powiedzie się, skontaktuj się z administratorem sieci.

Jeśli użytkownik jawnie zatrzymuje usługę Azure Database Migration Service (DMS) lub jeśli usługa jest nieaktywna przez 24 godziny, usługa jest w stanie zatrzymania lub automatycznego wstrzymania. W każdym przypadku usługa jest niedostępna i w stanie zatrzymania. Aby wznowić aktywne migracje, uruchom ponownie usługę.

Możesz wykonać kilka czynności, aby przyspieszyć migrację bazy danych przy użyciu usługi:

W przypadku usługi DMS (wersja klasyczna)-

• Użyj wieloprocesorowej warstwy cenowej ogólnego przeznaczenia podczas tworzenia wystąpienia usługi, aby umożliwić usłudze korzystanie z wielu procesorów wirtualnych na potrzeby przetwarzania równoległego i szybszego transferu danych.
• Tymczasowe skalowanie wystąpienia docelowego usługi Azure SQL Database do jednostki SKU warstwy Premium podczas operacji migracji danych w celu zminimalizowania ograniczania usługi Azure SQL Database, które mogą mieć wpływ na działania transferu danych podczas korzystania z jednostek SKU niższego poziomu.

W przypadku usługi DMS—

• Jeśli kopiujesz kopie zapasowe z lokalnego udziału plików do usługi Azure Blob Storage LUB podczas przeprowadzania migracji do docelowej bazy danych Azure SQL DB, usługa DMS używa węzła SHIR jako jego obliczeń. Dlatego należy monitorować użycie zasobów tego węzła SHIR.
• Tymczasowe skalowanie w górę wystąpienia docelowego usługi Azure SQL Database do jednostki SKU warstwy Premium podczas operacji migracji danych w celu zminimalizowania ograniczania dysku usługi Azure SQL Database, które może mieć wpływ na działania transferu danych podczas korzystania z jednostek SKU niższego poziomu.
• Aby uzyskać bardziej szczegółowe informacje, zobacz blog.

Następne kroki

• Co to jest usługa Azure Database Migration Service.