AWS SCT: nieskonwertowane obiekty przy migracji Oracle do PostgreSQL

Ten runbook opisuje rozwiązywanie błędów konwersji schematu w AWS SCT przy migracji heterogenicznej Oracle do PostgreSQL. Pełny przewodnik po migracji znajdziesz w artykule Migracja Oracle do PostgreSQL na AWS. Gdy schemat jest już gotowy, dane przenosisz taskiem DMS - zobacz przewodnik po AWS DMS oraz runbook walidacja danych DMS po przełączeniu. W kwestii planowania migracji umów konsultację.

Objaw

W AWS SCT raport oceny (Assessment Report) i drzewo konwersji pokazują obiekty, których nie udało się przełożyć automatycznie. Typowe sygnały:

# Assessment Report / Action Items w SCT:
#   "Packages: 42 objects - 18 can be converted automatically, 24 require manual work"
#   "PL/SQL package APP_PKG.CALC_TOTALS cannot be converted automatically"
#   "Sequence NEXTVAL used in SELECT - no direct PostgreSQL equivalent"
#   "Trigger uses :OLD/:NEW referencing - manual conversion required"
#   "Data type NUMBER without precision mapped to double precision (review)"
#   "Function requires AWS SCT extension pack (aws_oracle_ext) - not installed on target"

# Kategorie zlozonosci pozycji do konwersji (SCT nadaje kazdej ocene w godzinach):
#   Simple / Medium / Complex / Significant

Drzewo obiektów pokazuje pozycje oznaczone na czerwono (nieskonwertowane) lub żółto (skonwertowane z uwagami). Assessment Report wylicza szacowaną pracochłonność ręcznej konwersji.

Przyczyna

Błędy konwersji SCT przy Oracle → PostgreSQL mają zwykle jedną z czterech przyczyn:

• Pakiety i procedury PL/SQL bez bezpośredniego odpowiednika: PostgreSQL nie ma pakietów w rozumieniu Oracle. Logika PACKAGE/PACKAGE BODY, zmienne pakietowe, %ROWTYPE, kursory referencyjne czy AUTONOMOUS_TRANSACTION wymagają ręcznego przełożenia na funkcje/schematy PL/pgSQL. To najczęstsze i najbardziej pracochłonne pozycje do ręcznej konwersji.
• Konstrukcje specyficzne dla Oracle w SQL: sequence.NEXTVAL w SELECT, CONNECT BY, ROWNUM, DECODE, (+) w złączeniach, SYSDATE, hierarchiczne zapytania. Część SCT przepisuje automatycznie, część zostawia do ręcznej korekty.
• Brak extension pack (aws_oracle_ext) na celu: SCT emuluje wiele funkcji Oracle przez schemat rozszerzeń instalowany na docelowej bazie. Jeśli extension pack nie został wgrany, skonwertowane obiekty odwołują się do nieistniejących funkcji aws_oracle_ext.* i nie kompilują się na PostgreSQL.
• Typy danych bez jednoznacznego mapowania: NUMBER bez precyzji, DATE z częścią czasową, RAW, LONG, CLOB/BLOB, TIMESTAMP WITH LOCAL TIME ZONE. SCT proponuje mapowanie, ale wymaga przeglądu - zły wybór typu przenosi problem na etap walidacji danych w DMS.

Rozwiązanie

A) Uporządkuj pozycje do konwersji wg kategorii i pracochłonności:

# W SCT: View -> Assessment Report View. Posortuj pozycje do konwersji wg:
#   - kategorii obiektu (Packages, Procedures, Triggers, Sequences, Views)
#   - oceny zlozonosci (Simple -> Significant)
# Zacznij od masowych, powtarzalnych wzorcow (np. NEXTVAL, SYSDATE, DECODE),
# ktore da sie rozwiazac jedna regula, a nie obiekt po obiekcie.
# Eksport listy: Assessment Report -> Save to CSV/PDF (do sledzenia postepu).

B) Zainstaluj extension pack (aws_oracle_ext) na docelowej bazie:

-- W SCT: prawy klik na docelowej bazie -> Apply Extension Pack.
-- Tworzy schemat aws_oracle_ext z emulacja funkcji Oracle na PostgreSQL.

-- Weryfikacja na celu (PostgreSQL/Aurora), ze schemat i funkcje istnieja:
SELECT n.nspname AS schema, count(*) AS funcs
FROM pg_proc p JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE n.nspname = 'aws_oracle_ext'
GROUP BY n.nspname;
-- Oczekiwane: schema aws_oracle_ext z niezerowa liczba funkcji.
-- Bez tego skonwertowane obiekty odwolujace sie do aws_oracle_ext.* nie skompiluja sie.

C) Skonwertowane pakiety/procedury PL/SQL - przełóż i zastosuj na cel:

-- Wzorzec konwersji pakietu Oracle na PostgreSQL:
--   PACKAGE + PACKAGE BODY  ->  osobny schemat + funkcje PL/pgSQL
--   zmienne pakietowe        ->  tabela/temp lub GUC (set_config/current_setting)
--   funkcje pakietowe        ->  funkcje w schemacie o nazwie pakietu

-- Przyklad: APP_PKG.CALC_TOTALS -> schema app_pkg, funkcja calc_totals
CREATE SCHEMA IF NOT EXISTS app_pkg;
CREATE OR REPLACE FUNCTION app_pkg.calc_totals(p_order_id bigint)
RETURNS numeric LANGUAGE plpgsql AS $$
DECLARE v_total numeric;
BEGIN
  SELECT COALESCE(SUM(qty * unit_price), 0) INTO v_total
  FROM app_schema.order_lines WHERE order_id = p_order_id;
  RETURN v_total;
END $$;
-- Obiekty proste (widoki, sekwencje) SCT zastosuje automatycznie: Apply to Database.
-- Zlozone przenies recznie i wersjonuj DDL w repo migracji.

D) Konstrukcje Oracle w SQL - zamień na odpowedniki PostgreSQL:

-- Najczestsze zamiany (do zastosowania regula/skryptem tam, gdzie SCT zostawil pozycje do konwersji):
--   seq.NEXTVAL           -> nextval('seq')
--   SYSDATE               -> now()  (lub clock_timestamp())
--   DECODE(a, x, y, z)     -> CASE WHEN a = x THEN y ELSE z END
--   NVL(a, b)             -> COALESCE(a, b)
--   a (+) = b (outer join) -> LEFT JOIN ... ON a = b
--   CONNECT BY            -> WITH RECURSIVE ...
--   ROWNUM <= n           -> LIMIT n

-- Po zamianie sprawdz, ze obiekt kompiluje sie na celu (brak odwolan do brakujacych funkcji).

Prewencja: uruchom Assessment Report na samym początku projektu - to on daje realną wycenę migracji i listę ryzyk, zanim ruszy przenoszenie danych. Rozwiązuj powtarzalne wzorce regułą, a nie obiekt po obiekcie. Wersjonuj docelowy DDL i ręczne konwersje w repozytorium, żeby dało się je odtworzyć na środowisku testowym i produkcyjnym. Domknij konwersję schematu przed uruchomieniem taska DMS - inaczej DMS ładuje dane do niekompletnych struktur, a problem wraca jako rozbieżność w walidacji.

Walidacja

-- 1. Extension pack zainstalowany i widoczny na celu
SELECT count(*) AS ext_funcs FROM pg_proc p
JOIN pg_namespace n ON n.oid = p.pronamespace WHERE n.nspname = 'aws_oracle_ext';
-- Oczekiwane: > 0

-- 2. Wszystkie funkcje/procedury kompiluja sie (brak obiektow z bledem)
--    Szybki sposob: sproboj zaladowac DDL na czyste srodowisko testowe i sprawdz bledy.
--    Kontrola liczby obiektow zrodlo vs cel wg typu:
SELECT 'functions' AS obj, count(*) FROM information_schema.routines
WHERE specific_schema IN ('app_schema','app_pkg');
-- Oczekiwane: liczby zgodne z planem konwersji (uwzgledniajac pakiety -> funkcje)

# 3. W SCT: ponowny Assessment Report nie pokazuje nierozwiazanych pozycji
#    (lub tylko swiadomie zaakceptowane, udokumentowane wyjatki).
# 4. Testowe wywolanie skonwertowanej logiki na celu zwraca te same wyniki co Oracle
#    dla reprezentatywnego zestawu danych (porownanie wynikow, nie tylko "kompiluje sie").

Jeśli extension pack jest zainstalowany, wszystkie obiekty kompilują się na bazie docelowej, Assessment Report nie zgłasza nierozwiązanych pozycji, a testowe wywołania skonwertowanej logiki zwracają wyniki zgodne z Oracle - schemat docelowy jest gotowy do uruchomienia migracji danych taskiem DMS.

SCT zgłasza dziesiątki pozycji do konwersji?

Umów bezpłatną 30-minutową rozmowę. Przejrzymy raport oceny, ustalimy strategię konwersji pakietów PL/SQL i domkniemy schemat przed migracją danych.

Umów rozmowę Wyślij wiadomość