Wdrażanie przekonwertowanych schematów przy użyciu kreatora konfiguracji

Środowisko instalacji konwersji schematu automatycznie generuje instrukcje i skrypty po zakończeniu przepływu pracy konwersji. Użyj tych plików, aby wdrożyć przekonwertowane schematy do usługi Azure Database for PostgreSQL. Generowanie plików nie powoduje wdrożenia schematów w miejscu docelowym. Przejrzyj je i uruchomisz wygenerowany skrypt programu PowerShell lub powłoki Bash w środowisku wdrażania.

Aby uzyskać instrukcje dotyczące otwierania plików instalacyjnych z ukończonej konwersji, zobacz Przygotowywanie wdrożenia za pomocą środowiska instalacji w samouczku.

Przejrzyj wygenerowane pliki

Katalog instalacyjny zależy od liczby schematów Oracle wybranych do konwersji. Użyj odpowiedniej ścieżki względem katalogu głównego obszaru roboczego:

Zastąp ciąg <migration-project> nazwą folderu projektu migracji, taką jak Mig001. W przypadku wybrania jednego schematu zastąp <schema-name> nazwą wybranego folderu schematu Oracle, taką jak HR. Jeśli wybierzesz wiele schematów, _migration jest rzeczywistą nazwą folderu, a nie symbolem zastępczym.

Lokalizacja odzwierciedla wybrane schematy Oracle, a nie liczbę schematów PostgreSQL zawartych w pakiecie. Przejrzyj setup_instructions.md zakres wdrożenia pakietu.

Zachowaj katalog instalacyjny wewnątrz kompletnego projektu migracji. Moduły uruchamiające odwołują się do sesji konwersji deploy.sql w katalogu równorzędnym convert ; kopiowanie tylko katalogu instalacyjnego nie jest wystarczające.

Zapoznaj się z wygenerowanymi instrukcjami i wdrożeniem sql przed ich uruchomieniem. Upewnij się, że program SQL zawiera poprawki dotyczące obiektów, które zamierzasz wdrożyć. Jeśli projekt zostanie przeniesiony do innego środowiska, zachowaj jego strukturę katalogów i postępuj zgodnie z wymaganiami dotyczącymi obsługi danych w organizacji. Usuń poświadczenia i inne wpisy tajne z udostępnionych plików.

Przygotuj miejsce docelowe

Użyj wymagań w wygenerowanych setup_instructions.mdelementach zamiast kopiowania wymagań z innej konwersji:

• Wersje serwera i klienta. Przygotuj serwer elastyczny Azure Database for PostgreSQL z wymaganą wersją bazy danych PostgreSQL. Główny numer wersji klienta psql musi być zgodny z głównym numerem wersji serwera konwersji zapisanym w wygenerowanym pakiecie instalacyjnym. Zainstaluj tego klienta na komputerze, na którym jest uruchomiona instalacja, i udostępnij go na PATH. Instalator może utworzyć bazę danych na serwerze, ale nie aprowizować serwera Azure.
• Dostęp do powłoki i plików. Użyj programu PowerShell 5.1 lub nowszego w Windows lub powłoki Bash w systemie Linux lub macOS. Proces uruchamiający potrzebuje uprawnień do zapisu do swoich katalogów logs i reports.
• Dostęp do sieci. Zezwól komputerowi instalacyjnemu na nawiązanie połączenia z serwerem docelowym Azure Database for PostgreSQL i portem PostgreSQL.
• Rozszerzenia. Przed wdrożeniem sprawdź wymagane rozszerzenia i dodaj obsługiwane rozszerzenia do listy dozwolonych na serwerze docelowym Azure Database for PostgreSQL. Zobacz Zezwalanie na rozszerzenia w Azure Database for PostgreSQL.
• Uprawnienia. Użyj konta z uprawnieniami bazy danych, schematu, tworzenia obiektów i instalacji rozszerzeń określonych w wygenerowanych instrukcjach. Tryb nowej bazy danych wymaga również uprawnień do tworzenia bazy danych.
• Authentication. Użyj ukrytego monitu o hasło skryptu, pliku hasła PostgreSQL lub zatwierdzonego procesu zarządzania wpisami tajnymi w organizacji. Nie osadzaj haseł w skryptach wdrażania.

Upewnij się, że klient jest dostępny:

psql --version

Wygenerowane instrukcje odzwierciedlają środowisko konwersji, w tym wymagania dotyczące wersji i rozszerzenia PostgreSQL. Przed wdrożeniem zapoznaj się z wszelkimi różnicami miejsc docelowych.

Wybierz tryb bazy danych

Oba moduły uruchamiacze obsługują następujące tryby:

W przypadku interakcyjnego przebiegu skrypt monituje o brakujące wartości hosta, użytkownika i bazy danych. Przed potwierdzeniem przejrzyj wyświetlane miejsce docelowe, tryb bazy danych, schematy i operację.

Sprawdzanie gotowości bez wdrażania

Otwórz terminal w wygenerowanym katalogu instalacyjnym. Wybierz polecenie dla systemu operacyjnego i zamierzonego trybu bazy danych:

Tryb tylko walidacji łączy się z serwerem i zapisuje lokalne raporty i dzienniki. Nie tworzy docelowej bazy danych, nie instaluje rozszerzeń ani nie wdraża przekonwertowanych obiektów.

Sprawdzanie gotowości obejmuje łączność, wersję bazy danych PostgreSQL, kodowanie bazy danych i ustawienia regionalne, uprawnienia, zajętość schematu docelowego i dostępność rozszerzenia. Przejrzyj ostrzeżenia, a także błędy blokujące.

W trybie nowej bazy danych walidacja używa bazy danych obsługowej, ponieważ docelowa baza danych jeszcze nie istnieje. Sprawdza, czy docelowa baza danych jest oznaczona jako pominięta. Pomyślne uruchomienie tylko do weryfikacji nie jest potwierdzeniem, że te pominięte testy zostały zakończone pomyślnie.

Po pomyślnym zakończeniu walidacji sprawdź reports w katalogu validation_report_<timestamp>.md. Rozwiąż zgłoszone problemy przed wdrożeniem. Jeśli walidacja zostanie wcześniej zatrzymana, najpierw sprawdź dane wyjściowe konsoli, a następnie dziennik lub raport, który został utworzony.

Wdróż przekonwertowane schematy

Użyj tego samego miejsca docelowego i trybu bazy danych, które zostały sprawdzone. W katalogu instalacyjnym uruchom odpowiednie polecenie bez -ValidateOnly (PowerShell) lub --validate-only (Bash):

Moduł uruchamiający przygotowuje bazę danych, sprawdza gotowość, instaluje wymagane obsługiwane rozszerzenia, wykonuje przekonwertowane wdrożenie SQL i weryfikuje wynikowe obiekty i rozszerzenia.

Przed zatwierdzeniem niepustego miejsca docelowego należy przejrzeć wdrożenie SQL, ponieważ może zmienić istniejące obiekty.

Służy setup_instructions.md do opcjonalnych parametrów portów, tls, ustawień regionalnych i automatyzacji. W przypadku nieinterakcyjnego przebiegu podaj z wyprzedzeniem szczegóły hosta, użytkownika, bazy danych i uwierzytelniania. Niepusty istniejący obiekt docelowy wymaga również jawnego potwierdzenia za pośrednictwem Windows -AllowNonEmptyExisting lub --allow-nonempty-existing w systemie Linux lub macOS.

Przeglądanie wyników wdrożenia

Przed przejściem do sprawdzania poprawności danych lub aplikacji zapoznaj się z wynikami wdrożenia. Sam stan konwersji nie potwierdza wdrożenia w tym miejscu docelowym.

Uruchomienia tylko do walidacji generują raport walidacji zamiast raportu wdrożenia. Wczesna awaria, taka jak problem z dostępem do plików lub wersją powłoki, może pozostawić tylko dane wyjściowe konsoli.

Użyj kodu zakończenia runnera razem z następującymi danymi wyjściowymi:

Kontynuuj automatyzację tylko dla kodu zakończenia 0. W przypadku dowolnego innego kodu przejrzyj dostępne dane wyjściowe i rozwiąż zgłoszone problemy przed kontynuowaniem.

Weryfikowanie wdrożonego schematu

Pomyślna konfiguracja nie ustanawia równoważności behawioralnej z Oracle ani gotowości produkcyjnej. Niezależnie przetestuj obsługę danych, zależności, logikę biznesową i zachowanie aplikacji w środowisku docelowym.

Przejrzyj wszystkie obiekty lub rozszerzenia, które nie zostały wdrożone, i dokończ ich naprawę. Zastosuj oddzielnie zarządzaną konfigurację zabezpieczeń i cofnij tymczasowe uprawnienia do konfiguracji, gdy nie są już wymagane.

Treści powiązane

• Tutorial: konwertowanie schematów Oracle na Azure Database for PostgreSQL
• Przejrzyj przekonwertowane obiekty w Conversion Eksplorator obiektów
• Wyświetl raport HTML dotyczący konwersji schematu Oracle
• Najlepsze praktyki dotyczące konwersji schematu z Oracle do Azure Database for PostgreSQL