Migracja Oracle do chmury – Przemysław Rosłon

1. Wprowadzenie

Migracja serwera Oracle Database do chmury to złożony proces, który wymaga starannego planowania, analizy technicznej i biznesowej oraz wyboru odpowiedniej strategii. Niniejszy dokument opisuje wszystkie dostępne ścieżki migracji, narzędzia, scenariusze oraz najlepsze praktyki.

1.1 Dlaczego migrować Oracle do chmury?

Czynnik	Opis
Redukcja kosztów	Eliminacja kosztów utrzymania fizycznej infrastruktury (CAPEX → OPEX)
Skalowalność	Elastyczne skalowanie zasobów w górę i w dół w zależności od obciążenia
Wysoka dostępność	Wbudowane mechanizmy HA, DR i geo-replikacji
Modernizacja	Możliwość stopniowej modernizacji aplikacji i baz danych
Zgodność	Certyfikacje bezpieczeństwa (ISO, SOC, HIPAA, GDPR)
Automatyzacja	Automatyczne patching, backup, monitoring
Szybkość wdrożeń	Prowizjonowanie środowisk w minutach zamiast tygodni

1.2 Strategie migracji (6R)

Strategia	Opis	Zastosowanie dla Oracle
Rehost (Lift & Shift)	Przeniesienie bazy bez zmian na IaaS	Oracle na VM w Azure/AWS/GCP
Replatform (Lift & Reshape)	Przeniesienie z drobnymi optymalizacjami	Oracle na RDS, Exadata Cloud
Repurchase	Zmiana na inny produkt SaaS	Przejście na Oracle SaaS (Fusion)
Refactor	Przepisanie/modyfikacja aplikacji	Migracja do PostgreSQL/Azure SQL
Retire	Wycofanie systemu	Wyłączenie nieużywanych baz
Retain	Pozostawienie on-premises	Bazy z ograniczeniami licencyjnymi

2. Analiza przedmigracyjna

2.1 Inwentaryzacja środowiska Oracle

Przed rozpoczęciem migracji należy przeprowadzić dokładną inwentaryzację:

2.1.1 Informacje o instancji

<a href="#cb1-1"></a>-- Wersja Oracle
<a href="#cb1-2"></a>SELECT * FROM V$VERSION;
<a href="#cb1-3"></a>
<a href="#cb1-4"></a>-- Informacje o instancji
<a href="#cb1-5"></a>SELECT INSTANCE_NAME, HOST_NAME, VERSION, STATUS, DATABASE_STATUS 
<a href="#cb1-6"></a>FROM V$INSTANCE;
<a href="#cb1-7"></a>
<a href="#cb1-8"></a>-- Rozmiar bazy danych
<a href="#cb1-9"></a>SELECT ROUND(SUM(bytes)/1024/1024/1024, 2) AS "Rozmiar_GB" 
<a href="#cb1-10"></a>FROM DBA_DATA_FILES;
<a href="#cb1-11"></a>
<a href="#cb1-12"></a>-- Rozmiar poszczególnych schematów
<a href="#cb1-13"></a>SELECT OWNER, ROUND(SUM(BYTES)/1024/1024, 2) AS "Rozmiar_MB"
<a href="#cb1-14"></a>FROM DBA_SEGMENTS
<a href="#cb1-15"></a>GROUP BY OWNER
<a href="#cb1-16"></a>ORDER BY 2 DESC;
<a href="#cb1-17"></a>
<a href="#cb1-18"></a>-- Liczba obiektów według typu
<a href="#cb1-19"></a>SELECT OBJECT_TYPE, COUNT(*) 
<a href="#cb1-20"></a>FROM DBA_OBJECTS 
<a href="#cb1-21"></a>WHERE OWNER NOT IN ('SYS','SYSTEM','DBSNMP','OUTLN')
<a href="#cb1-22"></a>GROUP BY OBJECT_TYPE
<a href="#cb1-23"></a>ORDER BY 2 DESC;

2.1.2 Analiza obciążenia

<a href="#cb2-1"></a>-- Top SQL pod względem CPU
<a href="#cb2-2"></a>SELECT SQL_ID, ELAPSED_TIME, CPU_TIME, EXECUTIONS, 
<a href="#cb2-3"></a>       ROUND(ELAPSED_TIME/EXECUTIONS/1000, 2) AS AVG_MS
<a href="#cb2-4"></a>FROM V$SQL
<a href="#cb2-5"></a>WHERE EXECUTIONS > 0
<a href="#cb2-6"></a>ORDER BY CPU_TIME DESC
<a href="#cb2-7"></a>FETCH FIRST 20 ROWS ONLY;
<a href="#cb2-8"></a>
<a href="#cb2-9"></a>-- Statystyki I/O
<a href="#cb2-10"></a>SELECT * FROM V$SYSSTAT WHERE NAME LIKE '%physical read%';
<a href="#cb2-11"></a>
<a href="#cb2-12"></a>-- Sesje i połączenia
<a href="#cb2-13"></a>SELECT COUNT(*) AS ACTIVE_SESSIONS FROM V$SESSION WHERE STATUS = 'ACTIVE';
<a href="#cb2-14"></a>SELECT VALUE AS MAX_SESSIONS FROM V$PARAMETER WHERE NAME = 'sessions';
<a href="#cb2-15"></a>
<a href="#cb2-16"></a>-- AWR Report (za ostatnie 24h)
<a href="#cb2-17"></a>@$ORACLE_HOME/rdbms/admin/awrrpt.sql

2.1.3 Identyfikacja funkcji specyficznych dla Oracle

Należy zidentyfikować użycie następujących funkcji:

Funkcja Oracle	Wpływ na migrację	Alternatywa w chmurze
RAC (Real Application Clusters)	Wysoki	Oracle RAC na OCI/Exadata, Azure HA
Data Guard	Średni	Natywne replikacje cloud
ASM (Automatic Storage Management)	Średni	Managed Disks, Block Storage
Partitioning	Niski-Średni	Partycjonowanie natywne w PostgreSQL/SQL
Advanced Compression	Niski	Kompresja w docelowej bazie
Advanced Security (TDE)	Średni	Natywne szyfrowanie cloud
Spatial and Graph	Wysoki	PostGIS, Azure SQL Spatial
OLAP	Wysoki	Synapse Analytics, BigQuery
PL/SQL	Bardzo wysoki	pgPL/SQL, T-SQL (wymaga konwersji)
Oracle Text	Średni	Full-text search w PostgreSQL/SQL
Materialized Views	Średni	Materialized Views w PostgreSQL
Database Links	Średni	Linked Servers, Foreign Data Wrappers
Flashback	Niski	Point-in-time recovery
Streams/GoldenGate	Wysoki	CDC narzędzia cloud-native
Java w bazie	Wysoki	Wymaga refaktoryzacji
Oracle Scheduler	Niski	Cloud scheduler, cron, Azure Automation

2.1.4 Mapowanie zależności aplikacyjnych

┌─────────────────────────────────────────────────────┐
│                    APLIKACJE                         │
├──────────┬──────────┬───────────┬───────────────────┤
│ App Web  │ App ERP  │ Reporting │ ETL/Integration   │
│ (JDBC)   │ (OCI)    │ (ODBC)    │ (SQL*Loader)      │
└────┬─────┴────┬─────┴─────┬─────┴─────────┬─────────┘
     │          │           │               │
     └──────────┴───────────┴───────────────┘
                        │
              ┌─────────┴─────────┐
              │  Oracle Database  │
              │  (on-premises)    │
              ├───────────────────┤
              │ Schemat APP       │
              │ Schemat REPORT    │
              │ Schemat ETL       │
              │ Schemat ARCHIVE   │
              └───────────────────┘

2.2 Ocena gotowości do migracji (Migration Assessment)

Checklist przedmigracyjny:

Kompletna inwentaryzacja instancji Oracle (wersja, edycja, patche)
Rozmiar bazy danych i tempo wzrostu
RPO (Recovery Point Objective) i RTO (Recovery Time Objective)
Wymagania SLA (dostępność, wydajność)
Analiza obciążenia (IOPS, CPU, pamięć, sieć)
Identyfikacja funkcji Oracle Enterprise Edition
Mapowanie zależności aplikacyjnych
Analiza połączeń sieciowych (latency, bandwidth)
Przegląd licencji Oracle (BYOL vs nowe licencje)
Wymagania regulacyjne i compliance
Budżet migracji i docelowy TCO
Okno migracyjne (dopuszczalny downtime)
Zasoby zespołu (kompetencje, dostępność)

3. Modele migracji — przegląd

┌────────────────────────────────────────────────────────────────────┐
│                    MIGRACJA ORACLE DO CHMURY                       │
├────────────────────────┬───────────────────────────────────────────┤
│   ZACHOWANIE ORACLE    │       ZMIANA SILNIKA BAZY DANYCH          │
│   (Homogeniczna)       │       (Heterogeniczna)                    │
├────────────────────────┼───────────────────────────────────────────┤
│                        │                                           │
│  ┌──────────────────┐  │  ┌─────────────────────────────────────┐  │
│  │ Azure VM (IaaS)  │  │  │ Azure SQL Database                  │  │
│  ├──────────────────┤  │  ├─────────────────────────────────────┤  │
│  │ Oracle DB@Azure  │  │  │ Azure SQL Managed Instance          │  │
│  ├──────────────────┤  │  ├─────────────────────────────────────┤  │
│  │ OCI (natywne)    │  │  │ Azure Database for PostgreSQL       │  │
│  ├──────────────────┤  │  ├─────────────────────────────────────┤  │
│  │ OCI-Azure Link   │  │  │ Amazon Aurora PostgreSQL             │  │
│  ├──────────────────┤  │  ├─────────────────────────────────────┤  │
│  │ AWS EC2 (IaaS)   │  │  │ Amazon RDS for PostgreSQL           │  │
│  ├──────────────────┤  │  ├─────────────────────────────────────┤  │
│  │ Amazon RDS Oracle │  │  │ Google Cloud SQL for PostgreSQL     │  │
│  ├──────────────────┤  │  ├─────────────────────────────────────┤  │
│  │ GCP Compute      │  │  │ Azure Database for MySQL            │  │
│  ├──────────────────┤  │  ├─────────────────────────────────────┤  │
│  │ OCI Autonomous   │  │  │ Google AlloyDB                      │  │
│  └──────────────────┘  │  └─────────────────────────────────────┘  │
│                        │                                           │
└────────────────────────┴───────────────────────────────────────────┘

3.1 Macierz decyzyjna

Kryterium	Rehost (VM)	Oracle DB@Azure	OCI	Re-platform (PaaS)	Refactor (PostgreSQL/SQL)
Czas migracji	Krótki	Średni	Średni	Średni	Długi
Ryzyko	Niskie	Niskie	Niskie	Średnie	Wysokie
Koszt migracji	Niski	Średni	Średni	Średni	Wysoki
Koszt operacyjny	Wysoki	Średni-Wysoki	Średni	Niski-Średni	Niski
Zmiana aplikacji	Brak	Brak	Minimalna	Minimalna-Średnia	Znaczna
Zarządzanie	Pełne (klient)	Częściowe	Częściowe	Minimalne	Minimalne
Vendor lock-in Oracle	Tak	Tak	Tak	Nie	Nie
Skalowalność	Ręczna	Automatyczna	Automatyczna	Automatyczna	Automatyczna

4. Opcja 1: Oracle na Azure Virtual Machines (IaaS)

4.1 Opis

Przeniesienie Oracle Database na maszyny wirtualne Azure w modelu IaaS (Infrastructure as a Service). Jest to podejście Lift & Shift — baza danych jest przenoszona bez zmian w architekturze.

4.2 Obsługiwane wersje i edycje

Wersja Oracle	Edycja	Status na Azure
Oracle 19c	Enterprise Edition	✅ W pełni wspierane
Oracle 19c	Standard Edition 2	✅ W pełni wspierane
Oracle 21c	Enterprise Edition	✅ W pełni wspierane
Oracle 23ai	Enterprise Edition	✅ W pełni wspierane
Oracle 12c	Enterprise Edition	⚠️ End of Support (tylko Extended)

4.3 Rekomendowane typy maszyn wirtualnych Azure

Seria VM	vCPU	RAM (GB)	Storage	Zastosowanie
E-series (Edsv5)	2-104	16-672	Premium SSD	OLTP, ogólne obciążenia
M-series (Msv2)	32-416	256-11,400	Ultra Disk	Duże bazy, in-memory
Mv2-series	208-416	5,700-11,400	Ultra Disk	Największe bazy (>4TB RAM)
L-series (Lsv3)	8-80	64-640	NVMe SSD lokalne	Wysoki throughput I/O
D-series (Ddsv5)	2-96	8-384	Premium SSD	Środowiska dev/test

4.4 Konfiguracja storage

┌─────────────────────────────────────────────────┐
│              Azure VM Oracle                     │
├─────────────────────────────────────────────────┤
│                                                  │
│  OS Disk (P30)          128 GB   Premium SSD     │
│  Oracle Binaries (P20)   64 GB   Premium SSD     │
│                                                  │
│  ┌─── DATA ────────────────────────────────┐     │
│  │ Stripe Set (ASM / LVM)                  │     │
│  │ P40 x 4 = 4 TB  Premium SSD            │     │
│  │ lub Ultra Disk (konfigurowalny IOPS)    │     │
│  └─────────────────────────────────────────┘     │
│                                                  │
│  ┌─── REDO LOGS ───────────────────────────┐     │
│  │ P30 x 2 = 2 TB  Premium SSD            │     │
│  │ lub Ultra Disk (niska latencja)         │     │
│  └─────────────────────────────────────────┘     │
│                                                  │
│  ┌─── ARCHIVE LOGS ───────────────────────┐      │
│  │ E40 x 2  Standard SSD                  │      │
│  └─────────────────────────────────────────┘     │
│                                                  │
│  ┌─── BACKUP ─────────────────────────────┐      │
│  │ Azure Blob Storage (Hot/Cool tier)     │      │
│  └─────────────────────────────────────────┘     │
│                                                  │
└─────────────────────────────────────────────────┘

4.5 Wysoka dostępność na Azure VM

Opcja A: Oracle Data Guard na Azure

                    ┌──────────────────┐
                    │   Azure Traffic   │
                    │     Manager       │
                    └────────┬─────────┘
                             │
              ┌──────────────┴──────────────┐
              │                             │
   ┌──────────┴──────────┐     ┌───────────┴──────────┐
   │  Region: West Europe│     │  Region: North Europe │
   │                     │     │                       │
   │  ┌───────────────┐  │     │  ┌─────────────────┐  │
   │  │ Oracle Primary│  │────▶│  │ Oracle Standby  │  │
   │  │   Database    │  │ DG  │  │   Database      │  │
   │  └───────────────┘  │     │  └─────────────────┘  │
   │                     │     │                       │
   │  Availability Zone 1│     │  Availability Zone 1  │
   └─────────────────────┘     └───────────────────────┘

Opcja B: Oracle RAC na Azure (z Shared Storage)

Uwaga: Oracle RAC na Azure wymaga rozwiązania shared storage (np. Azure Shared Disks, FlashGrid, lub Oracle ASM z iSCSI).

   ┌─────────────────────────────────────────┐
   │         Azure Load Balancer              │
   └────────────────┬────────────────────────┘
                    │
         ┌──────────┴──────────┐
         │                     │
   ┌─────┴──────┐       ┌─────┴──────┐
   │  RAC Node 1│       │  RAC Node 2│
   │  (VM AZ-1) │       │  (VM AZ-2) │
   └─────┬──────┘       └─────┬──────┘
         │                     │
         └──────────┬──────────┘
                    │
         ┌──────────┴──────────┐
         │  Azure Shared Disk  │
         │  (Ultra / Premium)  │
         │  lub FlashGrid      │
         └─────────────────────┘

4.6 Kroki migracji Lift & Shift na Azure VM

Przygotowanie środowiska Azure
- Utworzenie Resource Group, VNet, Subnets
- Konfiguracja NSG (porty 1521, 22, 5500)
- Provisioning VM z odpowiednim rozmiarem
- Konfiguracja Managed Disks
Instalacja Oracle na Azure VM
- Instalacja Oracle Linux / RHEL na VM
- Instalacja Oracle Database Software
- Konfiguracja ASM lub filesystem storage
Migracja danych (wybrać jedną z metod)
- RMAN Backup/Restore przez Azure Blob Storage
- Data Pump Export/Import (expdp/impdp)
- Oracle Data Guard (zero downtime)
- Oracle GoldenGate (zero downtime z CDC)
Konfiguracja post-migracyjna
- Konfiguracja networking (TNS, Listener)
- Konfiguracja backup (RMAN → Azure Blob)
- Konfiguracja monitoringu (OEM, Azure Monitor)
- Testy wydajnościowe i funkcjonalne
Cutover
- Przełączenie aplikacji na nowy endpoint
- Weryfikacja łączności i funkcjonalności
- Monitoring przez 24-72h po migracji

5. Opcja 2: Oracle Database@Azure (Exadata w Azure)

5.1 Opis

Oracle Database@Azure to usługa umożliwiająca uruchamianie Oracle Exadata Database Service bezpośrednio w centrach danych Microsoft Azure. Oracle infrastruktura Exadata jest fizycznie zlokalizowana w regionach Azure i podłączona do sieci Azure z ultra-niskim opóźnieniem.

5.2 Kluczowe cechy

Cecha	Opis
Infrastruktura	Oracle Exadata X9M/X10M w Azure datacenter
Sieć	Bezpośrednie połączenie z Azure VNet (<2ms latency)
Zarządzanie	Zarządzane przez Oracle (OCI console + Azure portal)
Billing	Zintegrowane z Azure billing
SLA	99.995% dostępności
RAC	Pełne wsparcie Oracle RAC
Data Guard	Natywne Data Guard cross-region
Autonomous DB	Opcja Oracle Autonomous Database

5.3 Dostępne konfiguracje

Konfiguracja	Compute	Storage	IOPS	Zastosowanie
Quarter Rack	2 DB servers, 3 storage servers	76.8 TB Flash	1.5M	Średnie obciążenia
Half Rack	4 DB servers, 6 storage servers	153.6 TB Flash	3M	Duże obciążenia
Full Rack	8 DB servers, 12 storage servers	307.2 TB Flash	6M	Enterprise critical
Multi-Rack	Skalowalne	Skalowalne	Skalowalne	Największe wdrożenia

5.4 Architektura Oracle Database@Azure

┌──────────────────────────────────────────────────────────────┐
│                      Azure Region                             │
│                                                               │
│  ┌──────────────────────┐    ┌─────────────────────────────┐  │
│  │   Azure Services     │    │  Oracle Database@Azure       │  │
│  │                      │    │                              │  │
│  │  ┌────────────────┐  │    │  ┌─────────────────────┐    │  │
│  │  │ Azure App      │  │    │  │  Oracle Exadata      │    │  │
│  │  │ Service        │──┼────┼─▶│  Database Service    │    │  │
│  │  └────────────────┘  │    │  │                      │    │  │
│  │  ┌────────────────┐  │    │  │  ┌───────┐ ┌──────┐ │    │  │
│  │  │ Azure Kubernetes│ │    │  │  │ RAC   │ │ ASM  │ │    │  │
│  │  │ Service        │──┼────┼─▶│  │ Node1 │ │      │ │    │  │
│  │  └────────────────┘  │    │  │  │ Node2 │ │      │ │    │  │
│  │  ┌────────────────┐  │    │  │  └───────┘ └──────┘ │    │  │
│  │  │ Azure Virtual  │  │    │  │                      │    │  │
│  │  │ Network (VNet) │──┼────┼─▶│  Exadata Storage     │    │  │
│  │  └────────────────┘  │    │  │  (Smart Flash Cache)  │    │  │
│  │                      │    │  └─────────────────────┘    │  │
│  └──────────────────────┘    └─────────────────────────────┘  │
│             │                              │                   │
│             └──────── <2ms latency ────────┘                   │
└──────────────────────────────────────────────────────────────┘

5.5 Kroki migracji do Oracle Database@Azure

Rejestracja usługi — Aktywacja Oracle Database@Azure w subskrypcji Azure
Provisioning Exadata Infrastructure — Przez Azure Portal lub OCI Console
Konfiguracja sieci — Delegacja subnetu Azure VNet do Exadata
Utworzenie VM Cluster — Konfiguracja compute nodes
Utworzenie bazy danych — CDB/PDB provisioning
Migracja danych:
- Oracle Data Guard (preferowane dla zero-downtime)
- RMAN Backup/Restore przez Object Storage
- Oracle Zero Downtime Migration (ZDM)
Rekonfiguracja aplikacji — Zmiana connection string
Walidacja i cutover

6. Opcja 3: Oracle Cloud Infrastructure (OCI)

6.1 Opis

Migracja do natywnego Oracle Cloud Infrastructure (OCI) zapewnia pełną kompatybilność z Oracle Database i dostęp do wszystkich usług Oracle w chmurze.

6.2 Usługi bazodanowe w OCI

Usługa	Typ	Zarządzanie	Zastosowanie
Oracle Base Database	PaaS (VM)	Częściowe	Standardowe obciążenia
Oracle Exadata Cloud Service	PaaS (Exadata)	Częściowe	Enterprise, RAC
Oracle Autonomous Database	PaaS (Serverless)	W pełni zarządzane	Samooptymalizujące się
Oracle Autonomous Data Warehouse	PaaS	W pełni zarządzane	Analityka, BI
Oracle Autonomous Transaction Processing	PaaS	W pełni zarządzane	OLTP
Oracle Autonomous JSON Database	PaaS	W pełni zarządzane	Dokument/JSON
MySQL HeatWave	PaaS	W pełni zarządzane	MySQL + analityka

6.3 Oracle Autonomous Database — szczegóły

Oracle Autonomous Database to w pełni zarządzana usługa oferująca:

Auto-tuning — automatyczna optymalizacja zapytań i indeksów
Auto-scaling — automatyczne skalowanie CPU (1-128 OCPU)
Auto-patching — automatyczne aktualizacje bez przestojów
Auto-backup — automatyczne kopie zapasowe (60 dni retencji)
Auto-security — automatyczne szyfrowanie i patching bezpieczeństwa
Auto-repair — automatyczne wykrywanie i naprawa problemów

6.4 Kroki migracji na OCI

Wariant A: Migracja do Exadata Cloud Service

On-Premises Oracle ──▶ OCI Object Storage ──▶ OCI Exadata Cloud
       │                      │                       │
   RMAN Backup          Upload via         RMAN Restore
   lub Data Pump      OCI CLI/FastConnect   lub Data Pump Import

Wariant B: Migracja do Autonomous Database

On-Premises Oracle ──▶ OCI Object Storage ──▶ Autonomous Database
       │                      │                       │
   Data Pump Export    Upload via          DBMS_CLOUD.COPY_DATA
   (schemas/tables)  OCI CLI/FastConnect   lub Data Pump Import

Wariant C: Oracle Zero Downtime Migration (ZDM)

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Source DB   │     │  ZDM Host    │     │  Target DB   │
│  (On-Prem)   │────▶│  (Orchestr.) │────▶│  (OCI)       │
│              │     │              │     │              │
│  Data Guard  │◀───▶│  Automated   │◀───▶│  Standby     │
│  Primary     │     │  Switchover  │     │  → Primary   │
└──────────────┘     └──────────────┘     └──────────────┘

7. Opcja 4: OCI-Azure Interconnect (Multi-Cloud)

7.1 Opis

Oracle i Microsoft oferują Oracle Interconnect for Microsoft Azure — bezpośrednie, prywatne połączenie sieciowe między OCI a Azure z ultra-niskim opóźnieniem. Pozwala to na architekturę, w której baza danych Oracle działa na OCI, a warstwa aplikacyjna na Azure.

7.2 Dostępne regiony i pary

Region Azure	Region OCI	Latency
East US (Ashburn)	US East (Ashburn)	<2ms
UK South (London)	UK South (London)	<2ms
West Europe (Amsterdam)	Netherlands Northwest	<2ms
Germany West Central (Frankfurt)	Germany Central (Frankfurt)	<2ms
Canada Central (Toronto)	Canada Southeast (Toronto)	<2ms
Southeast Asia (Singapore)	Singapore	<2ms
Japan East (Tokyo)	Japan East (Tokyo)	<2ms

7.3 Architektura Multi-Cloud

┌─────────────────────────────┐       ┌─────────────────────────────┐
│        Microsoft Azure       │       │     Oracle Cloud (OCI)       │
│                              │       │                              │
│  ┌────────────────────────┐  │       │  ┌────────────────────────┐  │
│  │  Application Tier      │  │       │  │  Database Tier         │  │
│  │                        │  │       │  │                        │  │
│  │  ├─ Azure AKS          │  │       │  │  ├─ Exadata Cloud      │  │
│  │  ├─ Azure App Service  │  │       │  │  ├─ Autonomous DB      │  │
│  │  ├─ Azure Functions    │  │       │  │  ├─ Base Database       │  │
│  │  └─ Azure VM           │  │       │  │  └─ RAC Database       │  │
│  └────────────────────────┘  │       │  └────────────────────────┘  │
│                              │       │                              │
│  ┌─────────┐                 │       │                ┌──────────┐  │
│  │ Express │                 │       │                │ FastConn │  │
│  │ Route   │─────────────────┼───────┼────────────────│ ect      │  │
│  │ Circuit │  Interconnect   │       │  Interconnect  │ Circuit  │  │
│  └─────────┘  (<2ms latency) │       │                └──────────┘  │
│                              │       │                              │
│  Azure AD ◀───── Federacja ──┼───────┼──▶ OCI IAM                  │
│                              │       │                              │
└─────────────────────────────┘       └─────────────────────────────┘

7.4 Zalety Multi-Cloud

Baza Oracle na natywnym OCI (najlepsza wydajność i kompatybilność)
Aplikacje korzystające z bogactwa usług Azure (AI/ML, DevOps, Kubernetes)
Federacja tożsamości Azure AD ↔︎ OCI IAM
Ultra-niskie opóźnienie między warstwami (<2ms)
Rozdzielenie billing — Azure i OCI osobno

7.5 Kroki wdrożenia

Konfiguracja OCI Tenancy — Utworzenie compartment, VCN
Konfiguracja Azure — VNet, ExpressRoute Circuit
Ustanowienie Interconnect — Peering ExpressRoute ↔︎ FastConnect
Provisioning bazy Oracle na OCI — Exadata/Autonomous/Base DB
Migracja danych — Data Guard, ZDM, lub Data Pump
Konfiguracja federacji IAM — Azure AD ↔︎ OCI Identity Federation
Konfiguracja aplikacji na Azure — Connection string do OCI DB
Testy end-to-end — Weryfikacja latency, throughput, failover

8. Opcja 5: Oracle na AWS EC2 (IaaS)

8.1 Opis

Przeniesienie Oracle Database na instancje Amazon EC2 w modelu Lift & Shift. AWS oficjalnie wspiera Oracle Database na EC2.

8.2 Rekomendowane typy instancji

Typ instancji	vCPU	RAM (GB)	Storage	Zastosowanie
r6i.xlarge → r6i.32xlarge	4-128	32-1,024	EBS	OLTP, ogólne
r6i.metal	128	1,024	EBS	Duże bazy RAC
x2idn.xlarge → x2idn.metal	4-128	32-2,048	NVMe+EBS	In-memory, duże bazy
i3.xlarge → i3.16xlarge	4-64	30.5-488	NVMe lokalne	Wysoki I/O throughput
m6i.xlarge → m6i.32xlarge	4-128	16-512	EBS	Balanced workloads

8.3 Konfiguracja storage na AWS

Typ storage	IOPS	Throughput	Zastosowanie
gp3	do 16,000	1,000 MB/s	Ogólne, redo logs
io2 Block Express	do 256,000	4,000 MB/s	Krytyczne dane
io1	do 64,000	1,000 MB/s	Dane transakcyjne
st1	500	500 MB/s	Archive logs
S3	N/A	N/A	Backup, staging

8.4 Wysoka dostępność na AWS

Multi-AZ Data Guard — Primary w AZ-1, Standby w AZ-2
Cross-Region Data Guard — DR w innym regionie AWS
Oracle RAC na EC2 — Z wykorzystaniem shared storage (EBS Multi-Attach lub FlashGrid)

8.5 Kroki migracji na AWS EC2

Setup AWS — VPC, Subnets, Security Groups, IAM roles
Provisioning EC2 — Launch instancji, attach EBS volumes
Instalacja Oracle — Oracle Linux, Oracle Database software
Transfer danych:
- AWS Direct Connect + RMAN Backup/Restore
- S3 + Data Pump
- Oracle Data Guard (online)
- AWS Database Migration Service (DMS) — ograniczone wsparcie
Konfiguracja — TNS, Listener, Backup, Monitoring
Cutover — Przełączenie ruchu

9. Opcja 6: Amazon RDS for Oracle

9.1 Opis

Amazon RDS for Oracle to w pełni zarządzana usługa bazy danych Oracle na AWS. Amazon zarządza patchowaniem, backup, i infrastrukturą.

9.2 Obsługiwane edycje i wersje

Wersja	Standard Edition 2	Enterprise Edition
Oracle 19c	✅	✅
Oracle 21c	✅	✅

9.3 Klasy instancji RDS

Klasa	vCPU	RAM (GB)	Zastosowanie
db.m6i.large → db.m6i.24xlarge	2-96	8-384	Ogólne
db.r6i.large → db.r6i.24xlarge	2-96	16-768	Memory-optimized
db.x2idn.xlarge → db.x2idn.24xlarge	4-96	32-1,536	Memory-intensive

9.4 Ograniczenia RDS for Oracle

Funkcja	Dostępność
Oracle RAC	❌ Niedostępne
Oracle Data Guard	⚠️ Tylko RDS Multi-AZ (automatyczny failover)
Oracle GoldenGate	✅ Jako źródło/cel
PL/SQL	✅ W pełni wspierane
Oracle Spatial	✅ (EE)
TDE	✅
Advanced Compression	✅ (EE)
Partitioning	✅ (EE)
DBA Access	⚠️ Ograniczony (brak SYS, częściowy SYSDBA)
OS Access	❌ Brak dostępu do OS
Custom patches	❌ Niedostępne

9.5 Kroki migracji do RDS for Oracle

Ocena kompatybilności — Sprawdzenie ograniczeń RDS
Provisioning RDS — Przez AWS Console/CLI/CloudFormation
Migracja danych:
- AWS DMS (Database Migration Service) — online
- Data Pump przez S3 integration: <a href="#cb13-1"></a>-- Na RDS <a href="#cb13-2"></a>SELECT rdsadmin.rdsadmin_s3_tasks.upload_to_s3( <a href="#cb13-3"></a> p_bucket_name => 'my-bucket', <a href="#cb13-4"></a> p_prefix => 'dump/', <a href="#cb13-5"></a> p_s3_prefix => '', <a href="#cb13-6"></a> p_directory_name => 'DATA_PUMP_DIR' <a href="#cb13-7"></a>) AS TASK_ID FROM DUAL;
- Oracle GoldenGate → RDS
Walidacja — Testy integralności i wydajności
Cutover — Zmiana DNS/endpoint

10. Opcja 7: Oracle na Google Cloud Platform

10.1 Opis

Google Cloud Platform oferuje kilka opcji uruchamiania Oracle Database:

10.2 Dostępne opcje

Opcja	Typ	Zarządzanie
Oracle na Compute Engine	IaaS	Klient zarządza
Google Cloud Bare Metal	Bare Metal	Klient zarządza, Google utrzymuje hardware
Oracle Database@Google Cloud	PaaS (Exadata)	Oracle zarządza (analogicznie do DB@Azure)

10.3 Oracle na Google Compute Engine

Rekomendowane typy maszyn:

Typ maszyny	vCPU	RAM (GB)	Zastosowanie
n2-highmem-8 → n2-highmem-128	8-128	64-864	Ogólne OLTP
m2-ultramem-208 → m2-megamem-416	208-416	5,888-8,832	In-memory, SAP
c3-highmem-8 → c3-highmem-176	8-176	64-1,408	Compute-intensive

10.4 Google Cloud Bare Metal Solution

Dedykowane serwery fizyczne w GCP datacenter
Pełne wsparcie Oracle RAC, Data Guard, ASM
Połączenie do GCP VPC z niskim opóźnieniem
Idealne dla Oracle workloads wymagających certyfikacji

10.5 Oracle Database@Google Cloud (2024+)

Analogicznie do Oracle Database@Azure — Oracle Exadata Infrastructure fizycznie w GCP datacenter z bezpośrednim połączeniem do GCP networking.

11. Opcja 8: Migracja do Azure SQL Database / SQL Managed Instance

11.1 Opis

Migracja heterogeniczna z Oracle do Microsoft SQL Server w chmurze Azure. Wymaga konwersji schematu, kodu PL/SQL (na T-SQL) i danych.

11.2 Porównanie docelowych usług Azure SQL

Cecha	Azure SQL Database	Azure SQL Managed Instance	SQL Server na VM
Kompatybilność z SQL Server	~95%	~99%	100%
Zarządzanie	W pełni zarządzane	W pełni zarządzane	Klient
Maks. rozmiar DB	128 TB	16 TB	Nieograniczony
Linked Servers	❌	✅	✅
SQL Agent Jobs	❌ (Elastic Jobs)	✅	✅
CLR	Ograniczone	✅	✅
Cross-DB queries	❌ (Elastic Query)	✅	✅

11.3 Mapowanie typów danych Oracle → SQL Server

Oracle	SQL Server	Uwagi
NUMBER(p,s)	DECIMAL(p,s) lub INT/BIGINT	Zależne od precyzji
VARCHAR2(n)	NVARCHAR(n)	Unicode w SQL Server
CLOB	NVARCHAR(MAX)	Do 2 GB
BLOB	VARBINARY(MAX)	Do 2 GB
DATE	DATETIME2	Oracle DATE zawiera czas
TIMESTAMP	DATETIME2(7)
RAW(n)	VARBINARY(n)
LONG	NVARCHAR(MAX)	Przestarzałe w Oracle
XMLTYPE	XML
INTERVAL	Brak natywnego	Wymaga obejścia
ROWID	Brak	Użyć klucza głównego
BOOLEAN (PL/SQL)	BIT
SEQUENCE	SEQUENCE lub IDENTITY
SYS_REFCURSOR	Cursor

11.4 Konwersja PL/SQL → T-SQL — kluczowe różnice

Konstrukcja	PL/SQL (Oracle)	T-SQL (SQL Server)
Zmienna	`v_name VARCHAR2(100);`	`DECLARE @name NVARCHAR(100);`
Przypisanie	`v_name := 'test';`	`SET @name = 'test';`
IF-THEN	`IF ... THEN ... END IF;`	`IF ... BEGIN ... END`
Pętla FOR	`FOR i IN 1..10 LOOP ... END LOOP;`	`WHILE @i <= 10 BEGIN ... SET @i += 1; END`
Exception	`EXCEPTION WHEN ... THEN`	`BEGIN TRY ... END TRY BEGIN CATCH ... END CATCH`
Pakiety	`CREATE PACKAGE ...`	Brak — użyć schematów + procedur
Sekwencja	`seq.NEXTVAL`	`NEXT VALUE FOR seq`
NVL	`NVL(x, default)`	`ISNULL(x, default)` lub `COALESCE`
DECODE	`DECODE(x, a, b, c)`	`CASE x WHEN a THEN b ELSE c END`
SYSDATE	`SYSDATE`	`GETDATE()` lub `SYSDATETIME()`
DUAL	`SELECT x FROM DUAL`	`SELECT x` (bez FROM)
ROWNUM	`WHERE ROWNUM <= n`	`TOP n` lub `OFFSET...FETCH`
CONNECT BY	`CONNECT BY PRIOR`	`WITH CTE AS (... UNION ALL ...)`
MERGE	`MERGE INTO ...`	`MERGE INTO ...` (składnia zbliżona)
Autonomous Transaction	`PRAGMA AUTONOMOUS_TRANSACTION`	Brak natywnego — obejście z loopback linked server

11.5 Narzędzie: SQL Server Migration Assistant (SSMA) for Oracle

SSMA automatyzuje konwersję schematów i danych z Oracle do SQL Server/Azure SQL.

Możliwości SSMA: – Automatyczna konwersja schematów (tabele, widoki, indeksy) – Konwersja PL/SQL → T-SQL (pakiety, procedury, funkcje, triggery) – Migracja danych z Oracle do SQL Server – Raporty kompatybilności i oceny migracji – Obsługa Oracle 10g, 11g, 12c, 18c, 19c, 21c

Proces z SSMA:

┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  1. Connect  │───▶│  2. Assess   │───▶│  3. Convert  │───▶│  4. Migrate  │
│  to Oracle   │    │  Schema      │    │  Schema &    │    │  Data        │
│  Source      │    │  (Report)    │    │  Code        │    │              │
└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘

11.6 Kroki migracji Oracle → Azure SQL

Assessment — SSMA Assessment Report, identyfikacja problemów
Konwersja schematu — SSMA automatic + ręczna korekta
Konwersja kodu PL/SQL — SSMA + ręczna konwersja złożonego kodu
Migracja danych — SSMA Data Migration lub Azure DMS
Modyfikacja aplikacji — Zmiana connection string, driver (JDBC→JDBC, OCI→ODBC)
Testy regresyjne — Pełne testy funkcjonalne i wydajnościowe
Cutover — Przełączenie produkcji

12. Opcja 9: Migracja do PostgreSQL (Azure/AWS/GCP)

12.1 Opis

Migracja z Oracle do PostgreSQL eliminuje koszty licencji Oracle i daje dostęp do open-source’owej bazy danych z bogatym ekosystemem. PostgreSQL jest często uważany za najbliższy open-source’owy odpowiednik Oracle.

12.2 Docelowe usługi PostgreSQL w chmurze

Usługa	Provider	Zarządzanie	Maks. storage	HA
Azure Database for PostgreSQL Flexible Server	Azure	W pełni zarządzane	64 TB	Zone-redundant
Amazon RDS for PostgreSQL	AWS	W pełni zarządzane	128 TB	Multi-AZ
Amazon Aurora PostgreSQL	AWS	W pełni zarządzane	128 TB	Multi-AZ + read replicas
Cloud SQL for PostgreSQL	GCP	W pełni zarządzane	64 TB	Regional HA
Google AlloyDB	GCP	W pełni zarządzane	64 TB	Regional HA + columnar
Crunchy Bridge	Multi-cloud	W pełni zarządzane	Zmienny	Multi-cloud HA

12.3 Mapowanie typów danych Oracle → PostgreSQL

Oracle	PostgreSQL	Uwagi
NUMBER(p,s)	NUMERIC(p,s)	Dokładne odwzorowanie
NUMBER (bez precyzji)	NUMERIC lub DOUBLE PRECISION	Zależne od użycia
VARCHAR2(n)	VARCHAR(n) lub TEXT	TEXT nie ma limitu
CHAR(n)	CHAR(n)
CLOB	TEXT	Do 1 GB
BLOB	BYTEA	Do 1 GB
NCLOB	TEXT	PostgreSQL natywnie UTF-8
DATE	TIMESTAMP	Oracle DATE zawiera czas!
TIMESTAMP	TIMESTAMP
TIMESTAMP WITH TIME ZONE	TIMESTAMPTZ
INTERVAL YEAR TO MONTH	INTERVAL
RAW(n)	BYTEA
LONG	TEXT
XMLTYPE	XML
SDO_GEOMETRY	GEOMETRY (PostGIS)	Wymaga rozszerzenia PostGIS
BINARY_FLOAT	REAL
BINARY_DOUBLE	DOUBLE PRECISION
BOOLEAN (PL/SQL)	BOOLEAN	Natywny w PostgreSQL
SYS_REFCURSOR	REFCURSOR

12.4 Konwersja PL/SQL → PL/pgSQL

Konstrukcja	PL/SQL (Oracle)	PL/pgSQL (PostgreSQL)
Blok procedury	`CREATE PROCEDURE p AS BEGIN ... END;`	`CREATE FUNCTION p() RETURNS void AS $$ BEGIN ... END; $$ LANGUAGE plpgsql;`
Funkcja	`CREATE FUNCTION f RETURN NUMBER AS`	`CREATE FUNCTION f() RETURNS NUMERIC AS $$`
Pakiety	`CREATE PACKAGE pkg AS ...`	Brak — użyć schematów + funkcji
Wyjątki	`EXCEPTION WHEN NO_DATA_FOUND THEN`	`EXCEPTION WHEN NO_DATA_FOUND THEN` (zbliżone)
Kursory	`CURSOR c IS SELECT ...;`	`DECLARE c CURSOR FOR SELECT ...;`
EXECUTE IMMEDIATE	`EXECUTE IMMEDIATE 'SQL';`	`EXECUTE 'SQL';`
DBMS_OUTPUT	`DBMS_OUTPUT.PUT_LINE('msg');`	`RAISE NOTICE 'msg';`
SYSDATE	`SYSDATE`	`CURRENT_TIMESTAMP` lub `NOW()`
NVL	`NVL(x, default)`	`COALESCE(x, default)`
DECODE	`DECODE(x, a, b, c)`	`CASE x WHEN a THEN b ELSE c END`
ROWNUM	`WHERE ROWNUM <= n`	`LIMIT n`
CONNECT BY	`CONNECT BY PRIOR id = parent_id`	`WITH RECURSIVE cte AS (...)`
SEQUENCES	`seq.NEXTVAL`	`NEXTVAL('seq')`
SYNONYM	`CREATE SYNONYM ...`	Brak — użyć search_path
MATERIALIZED VIEW	`CREATE MATERIALIZED VIEW ...`	`CREATE MATERIALIZED VIEW ...` (wspierane)
Autonomous Transaction	`PRAGMA AUTONOMOUS_TRANSACTION`	`dblink` do samego siebie
BULK COLLECT	`BULK COLLECT INTO`	Array operations
MERGE	`MERGE INTO ...`	`INSERT ... ON CONFLICT DO UPDATE`

12.5 Narzędzia do migracji Oracle → PostgreSQL

12.5.1 Ora2Pg

Najpopularniejsze narzędzie open-source do migracji Oracle → PostgreSQL.

Funkcje: – Automatyczna konwersja schematów – Konwersja PL/SQL → PL/pgSQL – Migracja danych (wielowątkowa) – Raport oceny migracji z punktacją – Konwersja typów danych, sekwencji, synonimów – Obsługa partycjonowania, materialized views

Instalacja:

<a href="#cb15-1"></a># Debian/Ubuntu
<a href="#cb15-2"></a>sudo apt-get install ora2pg
<a href="#cb15-3"></a>
<a href="#cb15-4"></a># Z CPAN
<a href="#cb15-5"></a>cpan install Ora2Pg
<a href="#cb15-6"></a>
<a href="#cb15-7"></a># Docker
<a href="#cb15-8"></a>docker pull georgmoser/ora2pg

Przykład konfiguracji ora2pg.conf:

<a href="#cb16-1"></a>ORACLE_HOME    /usr/lib/oracle/19.3/client64
<a href="#cb16-2"></a>ORACLE_DSN     dbi:Oracle:host=oracle-server;port=1521;sid=ORCL
<a href="#cb16-3"></a>ORACLE_USER    migration_user
<a href="#cb16-4"></a>ORACLE_PWD     secure_password
<a href="#cb16-5"></a>
<a href="#cb16-6"></a>SCHEMA         APP_SCHEMA
<a href="#cb16-7"></a>
<a href="#cb16-8"></a>PG_DSN         dbi:Pg:dbname=target_db;host=pg-server;port=5432
<a href="#cb16-9"></a>PG_USER        postgres
<a href="#cb16-10"></a>PG_PWD         pg_password
<a href="#cb16-11"></a>
<a href="#cb16-12"></a>TYPE           TABLE,VIEW,SEQUENCE,TRIGGER,FUNCTION,PROCEDURE,PACKAGE,TYPE
<a href="#cb16-13"></a>EXPORT_SCHEMA  1
<a href="#cb16-14"></a>FILE_PER_TABLE 1
<a href="#cb16-15"></a>JOBS           8
<a href="#cb16-16"></a>DATA_LIMIT     10000
<a href="#cb16-17"></a>
<a href="#cb16-18"></a># Konwersje
<a href="#cb16-19"></a>REPLACE_AS_BOOLEAN  status:active,is_deleted,enabled
<a href="#cb16-20"></a>REPLACE_ZERO_DATE   2000-01-01
<a href="#cb16-21"></a>
<a href="#cb16-22"></a>OUTPUT         /output/migration/

Uruchomienie oceny migracji:

<a href="#cb17-1"></a># Raport oceny (Migration Assessment)
<a href="#cb17-2"></a>ora2pg -c ora2pg.conf -t SHOW_REPORT --estimate_cost
<a href="#cb17-3"></a>
<a href="#cb17-4"></a># Wynik: Migration level: B-4 (na skali A-1 do C-5)
<a href="#cb17-5"></a># A-1: Prosta migracja (kilka dni)
<a href="#cb17-6"></a># C-5: Bardzo złożona migracja (miesiące)

12.5.2 AWS Schema Conversion Tool (SCT)

GUI narzędzie od AWS do konwersji schematów Oracle → PostgreSQL
Automatyczna konwersja z raportami problemów
Integracja z AWS DMS do migracji danych

12.5.3 pgLoader

Narzędzie do ładowania danych z Oracle do PostgreSQL
Szybkie, wielowątkowe ładowanie
Obsługa konwersji typów

12.6 Rozszerzenia PostgreSQL przydatne po migracji z Oracle

Rozszerzenie	Opis
orafce	Emulacja funkcji Oracle w PostgreSQL (NVL, DECODE, itp.)
pgTAP	Framework testowy dla PostgreSQL
PostGIS	Odpowiednik Oracle Spatial
pg_partman	Zaawansowane partycjonowanie
pg_cron	Scheduler (odpowiednik Oracle Scheduler/DBMS_SCHEDULER)
pgAudit	Auditing (odpowiednik Oracle Audit)
pg_stat_statements	Monitoring zapytań (odpowiednik AWR/ASH)
dblink	Database links (odpowiednik Oracle DB links)
postgres_fdw	Foreign Data Wrappers
pg_hint_plan	Hinty optymalizatora (odpowiednik Oracle hints)

12.7 Kroki migracji Oracle → PostgreSQL

Assessment — Ora2Pg SHOW_REPORT, AWS SCT Assessment
Provision PostgreSQL — Azure/AWS/GCP managed PostgreSQL
Konwersja schematu — Ora2Pg lub AWS SCT
Konwersja kodu PL/SQL — Automatyczna + ręczna (pakiety!)
Migracja danych — Ora2Pg, pgLoader, lub AWS DMS
Instalacja rozszerzeń — orafce, PostGIS, pg_cron itd.
Modyfikacja aplikacji — Driver, connection string, ORM config
Testy regresyjne — Porównanie wyników zapytań Oracle vs PostgreSQL
Testy wydajnościowe — Benchmark, tuning (work_mem, shared_buffers)
Cutover — Przełączenie produkcji

13. Opcja 10: Migracja do MySQL / MariaDB

13.1 Opis

Migracja do MySQL/MariaDB jest opcją dla prostszych baz danych Oracle, które nie wykorzystują zaawansowanych funkcji PL/SQL.

13.2 Docelowe usługi

Usługa	Provider
Azure Database for MySQL Flexible Server	Azure
Amazon RDS for MySQL / Aurora MySQL	AWS
Cloud SQL for MySQL	GCP
OCI MySQL HeatWave	Oracle Cloud

13.3 Ograniczenia

Brak odpowiednika pakietów PL/SQL
Ograniczone wsparcie dla sekwencji (MySQL 8.0+ nie ma natywnych)
Brak materialized views
Ograniczone partycjonowanie w porównaniu z Oracle
Prostsze procedury składowane

13.4 Narzędzia

MySQL Workbench Migration Wizard — Automatyczna konwersja schematów
AWS DMS — Migracja danych online
AWS SCT — Konwersja schematów

14. Narzędzia migracyjne — szczegółowy przegląd

14.1 Oracle Data Pump (expdp/impdp)

Typ: Offline migration
Zastosowanie: Eksport/import schematów, tabel, całych baz
Downtime: Wymagany (czas proporcjonalny do rozmiaru danych)

<a href="#cb18-1"></a># Eksport pełnej bazy
<a href="#cb18-2"></a>expdp system/password@source \
<a href="#cb18-3"></a>  DIRECTORY=DATA_PUMP_DIR \
<a href="#cb18-4"></a>  DUMPFILE=full_export_%U.dmp \
<a href="#cb18-5"></a>  FILESIZE=10G \
<a href="#cb18-6"></a>  PARALLEL=8 \
<a href="#cb18-7"></a>  FULL=Y \
<a href="#cb18-8"></a>  COMPRESSION=ALL \
<a href="#cb18-9"></a>  LOGFILE=export.log
<a href="#cb18-10"></a>
<a href="#cb18-11"></a># Eksport wybranych schematów
<a href="#cb18-12"></a>expdp system/password@source \
<a href="#cb18-13"></a>  DIRECTORY=DATA_PUMP_DIR \
<a href="#cb18-14"></a>  DUMPFILE=schema_export_%U.dmp \
<a href="#cb18-15"></a>  SCHEMAS=APP,REPORT,ETL \
<a href="#cb18-16"></a>  PARALLEL=4 \
<a href="#cb18-17"></a>  COMPRESSION=ALL
<a href="#cb18-18"></a>
<a href="#cb18-19"></a># Import na docelowej bazie
<a href="#cb18-20"></a>impdp system/password@target \
<a href="#cb18-21"></a>  DIRECTORY=DATA_PUMP_DIR \
<a href="#cb18-22"></a>  DUMPFILE=full_export_%U.dmp \
<a href="#cb18-23"></a>  PARALLEL=8 \
<a href="#cb18-24"></a>  TRANSFORM=SEGMENT_ATTRIBUTES:N \
<a href="#cb18-25"></a>  LOGFILE=import.log

Optymalizacja: – Użyj PARALLEL dla wielu wątków – COMPRESSION=ALL redukuje rozmiar dump – FILESIZE dzieli dump na wiele plików – CLUSTER=N może przyspieszyć eksport partycjonowanych tabel – EXCLUDE=STATISTICS — Import statystyk osobno (DBMS_STATS)

14.2 Oracle RMAN (Recovery Manager)

Typ: Offline/Online backup-restore
Zastosowanie: Migracja pełnych baz danych z zachowaniem spójności
Downtime: Minimalny (z incremental backup)

<a href="#cb19-1"></a># Pełny backup do Object Storage (Azure Blob / S3 / OCI)
<a href="#cb19-2"></a>rman target /
<a href="#cb19-3"></a>CONFIGURE CHANNEL DEVICE TYPE sbt
<a href="#cb19-4"></a>  PARMS 'SBT_LIBRARY=/path/to/libosbws.so,
<a href="#cb19-5"></a>  ENV=(OSB_WS_HOST=https://storage.blob.core.windows.net,
<a href="#cb19-6"></a>  OSB_WS_BUCKET=oracle-backup)';
<a href="#cb19-7"></a>
<a href="#cb19-8"></a>RUN {
<a href="#cb19-9"></a>  ALLOCATE CHANNEL ch1 DEVICE TYPE sbt;
<a href="#cb19-10"></a>  ALLOCATE CHANNEL ch2 DEVICE TYPE sbt;
<a href="#cb19-11"></a>  ALLOCATE CHANNEL ch3 DEVICE TYPE sbt;
<a href="#cb19-12"></a>  ALLOCATE CHANNEL ch4 DEVICE TYPE sbt;
<a href="#cb19-13"></a>  BACKUP AS COMPRESSED BACKUPSET DATABASE
<a href="#cb19-14"></a>    PLUS ARCHIVELOG DELETE INPUT;
<a href="#cb19-15"></a>  RELEASE CHANNEL ch1;
<a href="#cb19-16"></a>  RELEASE CHANNEL ch2;
<a href="#cb19-17"></a>  RELEASE CHANNEL ch3;
<a href="#cb19-18"></a>  RELEASE CHANNEL ch4;
<a href="#cb19-19"></a>}
<a href="#cb19-20"></a>
<a href="#cb19-21"></a># Restore na serwerze docelowym
<a href="#cb19-22"></a>rman target /
<a href="#cb19-23"></a>RUN {
<a href="#cb19-24"></a>  RESTORE DATABASE;
<a href="#cb19-25"></a>  RECOVER DATABASE;
<a href="#cb19-26"></a>  ALTER DATABASE OPEN RESETLOGS;
<a href="#cb19-27"></a>}

Podejście z Incremental Backup (minimalny downtime):

Dzień 1: Full RMAN Backup → Transfer → Restore na target
Dzień 2: Incremental Level 1 → Transfer → Apply na target
Dzień 3: Incremental Level 1 → Transfer → Apply na target
Cutover: Final Incremental → Apply → Open with RESETLOGS

14.3 Oracle Data Guard

Typ: Online migration (zero downtime)
Zastosowanie: Migracja z minimalnym przestojem
Downtime: Sekundy (switchover)

<a href="#cb21-1"></a>-- Na serwerze źródłowym (Primary)
<a href="#cb21-2"></a>-- Konfiguracja redo transport
<a href="#cb21-3"></a>ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=cloud_standby
<a href="#cb21-4"></a>  ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 
<a href="#cb21-5"></a>  DB_UNIQUE_NAME=cloud_db';
<a href="#cb21-6"></a>ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
<a href="#cb21-7"></a>
<a href="#cb21-8"></a>-- Na serwerze docelowym (Standby)
<a href="#cb21-9"></a>-- Po skonfigurowaniu i zsynchronizowaniu:
<a href="#cb21-10"></a>-- Switchover (na primary)
<a href="#cb21-11"></a>ALTER DATABASE SWITCHOVER TO cloud_db;
<a href="#cb21-12"></a>
<a href="#cb21-13"></a>-- Nowa primary w chmurze
<a href="#cb21-14"></a>ALTER DATABASE OPEN;

Architektura Data Guard Migration:

┌────────────────┐                    ┌────────────────┐
│  On-Premises   │    Redo Logs       │  Cloud Target  │
│  PRIMARY       │──────────────────▶│  STANDBY       │
│                │  (via VPN/         │                │
│  Oracle DB     │   ExpressRoute/    │  Oracle DB     │
│                │   Direct Connect)  │                │
└────────────────┘                    └────────────────┘
        │                                     │
        │         SWITCHOVER                  │
        │       (sekundy downtime)            │
        ▼                                     ▼
┌────────────────┐                    ┌────────────────┐
│  On-Premises   │                    │  Cloud Target  │
│  STANDBY       │◀──────────────────│  PRIMARY       │
│  (do wyłącz.)  │                   │  (produkcja)   │
└────────────────┘                    └────────────────┘

14.4 Oracle GoldenGate

Typ: Online migration (zero downtime) z Change Data Capture
Zastosowanie: Migracje homogeniczne i heterogeniczne, replikacja w czasie rzeczywistym
Downtime: Zero (logiczny cutover)

Komponenty:

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│   Extract    │───▶│  Trail Files  │───▶│  Replicat    │
│  (Source)    │    │  (kolejka)   │    │  (Target)    │
│              │    │              │    │              │
│ Czyta redo   │    │ Pliki z      │    │ Apllikuje    │
│ logs, capture│    │ zmianami     │    │ zmiany       │
│ DML/DDL      │    │ (local/remote)│   │ na target    │
└──────────────┘    └──────────────┘    └──────────────┘

Konfiguracja przykładowa:

-- Extract (na źródle)
EXTRACT ext_ora
USERID ogg_user, PASSWORD ogg_pass
EXTTRAIL ./dirdat/et
TABLE app_schema.*;

-- Data Pump (transfer trail files)
EXTRACT dpump
USERID ogg_user, PASSWORD ogg_pass
RMTHOST cloud-target, MGRPORT 7809
RMTTRAIL ./dirdat/rt
TABLE app_schema.*;

-- Replicat (na celu)
REPLICAT rep_ora
USERID ogg_user, PASSWORD ogg_pass
MAP app_schema.*, TARGET app_schema.*;

Zastosowania GoldenGate: – Migracja Oracle → Oracle (homogeniczna) – Migracja Oracle → PostgreSQL (heterogeniczna) – Migracja Oracle → MySQL/SQL Server (heterogeniczna) – Bidirekcjonalna replikacja (Active-Active) – Real-time data integration

14.5 Oracle Zero Downtime Migration (ZDM)

Typ: Zautomatyzowane narzędzie migracyjne Oracle
Zastosowanie: Migracja z on-premises do OCI lub cloud z orkiestracją
Downtime: Minimalny do zero

Obsługiwane migracje:

On-Premises Oracle ──▶ OCI Base Database
On-Premises Oracle ──▶ OCI Exadata Cloud Service
On-Premises Oracle ──▶ OCI Autonomous Database
On-Premises Oracle ──▶ Oracle Database@Azure

Metody w ZDM: – Logical Migration — Data Pump z GoldenGate (online) lub standalone – Physical Migration — RMAN z Data Guard (online) lub standalone

<a href="#cb26-1"></a># Inicjalizacja ZDM
<a href="#cb26-2"></a>zdmcli migrate database \
<a href="#cb26-3"></a>  -sourcesid ORCL \
<a href="#cb26-4"></a>  -sourcenode source-host \
<a href="#cb26-5"></a>  -srcauth zdmauth \
<a href="#cb26-6"></a>  -srcarg1 user:opc \
<a href="#cb26-7"></a>  -srcarg2 identity_file:/home/zdm/.ssh/id_rsa \
<a href="#cb26-8"></a>  -targethome /u01/app/oracle/product/19.0 \
<a href="#cb26-9"></a>  -targetnode target-host \
<a href="#cb26-10"></a>  -tgtauth zdmauth \
<a href="#cb26-11"></a>  -tgtarg1 user:opc \
<a href="#cb26-12"></a>  -tgtarg2 identity_file:/home/zdm/.ssh/id_rsa \
<a href="#cb26-13"></a>  -eval  # Najpierw ewaluacja

14.6 AWS Database Migration Service (DMS)

Typ: Online migration (CDC)
Zastosowanie: Migracja danych Oracle → dowolna baza docelowa na AWS

Obsługiwane cele: – Amazon RDS for Oracle – Amazon RDS for PostgreSQL / Aurora PostgreSQL – Amazon RDS for MySQL / Aurora MySQL – Amazon Redshift – Amazon S3

Konfiguracja:

<a href="#cb27-1"></a>{
<a href="#cb27-2"></a>  "SourceEndpoint": {
<a href="#cb27-3"></a>    "EngineName": "oracle",
<a href="#cb27-4"></a>    "ServerName": "oracle-source.example.com",
<a href="#cb27-5"></a>    "Port": 1521,
<a href="#cb27-6"></a>    "DatabaseName": "ORCL",
<a href="#cb27-7"></a>    "Username": "dms_user"
<a href="#cb27-8"></a>  },
<a href="#cb27-9"></a>  "TargetEndpoint": {
<a href="#cb27-10"></a>    "EngineName": "postgres",
<a href="#cb27-11"></a>    "ServerName": "target.rds.amazonaws.com",
<a href="#cb27-12"></a>    "Port": 5432,
<a href="#cb27-13"></a>    "DatabaseName": "target_db",
<a href="#cb27-14"></a>    "Username": "postgres"
<a href="#cb27-15"></a>  },
<a href="#cb27-16"></a>  "ReplicationTask": {
<a href="#cb27-17"></a>    "MigrationType": "full-load-and-cdc",
<a href="#cb27-18"></a>    "TableMappings": {
<a href="#cb27-19"></a>      "rules": [{
<a href="#cb27-20"></a>        "rule-type": "selection",
<a href="#cb27-21"></a>        "rule-id": "1",
<a href="#cb27-22"></a>        "rule-name": "include-all",
<a href="#cb27-23"></a>        "object-locator": {
<a href="#cb27-24"></a>          "schema-name": "APP_SCHEMA",
<a href="#cb27-25"></a>          "table-name": "%"
<a href="#cb27-26"></a>        },
<a href="#cb27-27"></a>        "rule-action": "include"
<a href="#cb27-28"></a>      }]
<a href="#cb27-29"></a>    }
<a href="#cb27-30"></a>  }
<a href="#cb27-31"></a>}

14.7 Azure Database Migration Service

Typ: Online/Offline migration
Zastosowanie: Migracja danych do Azure SQL lub PostgreSQL

Obsługiwane ścieżki migracji z Oracle: – Oracle → Azure SQL Database – Oracle → Azure SQL Managed Instance – Oracle → Azure Database for PostgreSQL

14.8 Porównanie narzędzi migracyjnych

Narzędzie	Typ	Downtime	Heterogeniczne	Koszt	Złożoność
Data Pump	Offline	Długi	❌	Darmowe	Niska
RMAN	Offline/Incr.	Średni	❌	Darmowe	Średnia
Data Guard	Online	Sekundy	❌	Licencja EE	Średnia
GoldenGate	Online/CDC	Zero	✅	Licencja OGG	Wysoka
ZDM	Orkiestracja	Min./Zero	❌	Darmowe	Średnia
AWS DMS	Online/CDC	Min.	✅	Per-use	Średnia
Azure DMS	Online/Offline	Różny	✅	Per-use	Średnia
SSMA	Offline	Długi	✅ (→SQL)	Darmowe	Średnia
Ora2Pg	Offline	Długi	✅ (→PG)	Darmowe (OSS)	Średnia
AWS SCT	Schema only	N/A	✅	Darmowe	Niska

15. Scenariusze migracyjne — szczegółowe opisy

15.1 Scenariusz A: Lift & Shift dużej bazy OLTP do Azure VM

Parametry wejściowe:

Baza źródłowa: Oracle 19c Enterprise Edition, RAC 2-node
Rozmiar: 5 TB danych, 200 GB redo logs/dzień
Obciążenie: 50,000 transakcji/s, 2,000 równoczesnych sesji
RPO: < 1 minuta, RTO: < 15 minut
Dopuszczalny downtime: 4 godziny (okno weekendowe)

Architektura docelowa:

┌─────────────────────────────────────────────────────────────────┐
│                      Azure West Europe                          │
│                                                                  │
│  ┌─────────────────┐    Data Guard    ┌─────────────────┐       │
│  │ VM: E104ids_v5  │◀──────────────▶│ VM: E104ids_v5   │       │
│  │ Primary (AZ-1)  │                 │ Standby (AZ-2)   │       │
│  │ 104 vCPU        │                 │ 104 vCPU         │       │
│  │ 672 GB RAM      │                 │ 672 GB RAM       │       │
│  │                  │                 │                   │       │
│  │ Ultra Disk:      │                 │ Ultra Disk:       │       │
│  │ DATA: 6TB 80K IO│                 │ DATA: 6TB 80K IO │       │
│  │ REDO: 500GB 40K │                 │ REDO: 500GB 40K  │       │
│  │ ARCH: 2TB       │                 │ ARCH: 2TB        │       │
│  └────────┬────────┘                 └────────┬─────────┘       │
│           │                                    │                 │
│           └──────────┬─────────────────────────┘                 │
│                      │                                           │
│              ┌───────┴───────┐                                   │
│              │ Azure ILB     │                                   │
│              │ (port 1521)   │                                   │
│              └───────────────┘                                   │
│                                                                  │
│  Backup: RMAN → Azure Blob Storage (Hot, lifecycle → Cool 30d)  │
│  Monitor: Azure Monitor + OEM Cloud Control                      │
└─────────────────────────────────────────────────────────────────┘

                    Data Guard (async)
                          │
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│                      Azure North Europe (DR)                     │
│                                                                  │
│  ┌─────────────────┐                                             │
│  │ VM: E64ids_v5   │   (Far Sync Standby - Disaster Recovery)    │
│  │ Standby (AZ-1)  │                                             │
│  │ 64 vCPU         │                                             │
│  │ 504 GB RAM      │                                             │
│  └─────────────────┘                                             │
└─────────────────────────────────────────────────────────────────┘

Plan migracji krok po kroku:

Faza	Zadanie	Czas	Kto
Tydzień 1-2	Provisioning Azure (VNet, VMs, Disks, NSG)	5 dni	Cloud Engineer
Tydzień 2-3	Instalacja Oracle 19c na Azure VMs	3 dni	DBA
Tydzień 3	Konfiguracja Data Guard (on-prem → Azure)	2 dni	DBA
Tydzień 3-4	Synchronizacja inicjalna Data Guard	3-5 dni	DBA (automatyczne)
Tydzień 4	Konfiguracja backupu RMAN → Blob Storage	1 dzień	DBA
Tydzień 4-5	Konfiguracja monitoringu (OEM + Azure Monitor)	2 dni	DBA + Cloud
Tydzień 5-6	Testy HA (failover/switchover)	3 dni	DBA + App Team
Tydzień 6-7	Testy wydajnościowe (load test)	5 dni	App Team + DBA
Tydzień 7-8	Testy aplikacji (UAT)	5 dni	App Team
Weekend 8	CUTOVER	4h	DBA + App Team
Tydzień 9	Monitoring post-migracyjny	5 dni	Wszyscy
Tydzień 10	Decommission on-premises (po potwierdzeniu)	5 dni	Infra Team

Procedura Cutover (4h okno):

T+00:00  Ogłoszenie maintenance window
T+00:15  Zatrzymanie aplikacji → baza read-only
T+00:30  Weryfikacja synchronizacji Data Guard (zero lag)
T+00:45  Switchover Data Guard (on-prem → Azure)
T+01:00  Weryfikacja nowej primary na Azure
T+01:15  Zmiana DNS/connection string aplikacji
T+01:30  Restart aplikacji, weryfikacja połączeń
T+02:00  Smoke testy aplikacji (kluczowe flow)
T+02:30  Pełne testy regresyjne (automatyczne)
T+03:00  Weryfikacja backupów, monitoringu
T+03:30  Ogłoszenie zakończenia maintenance
T+03:45  Monitoring — zespół w gotowości 24h

15.2 Scenariusz B: Migracja do Oracle Database@Azure (Exadata)

Parametry wejściowe:

Baza źródłowa: Oracle 19c EE, Exadata on-premises (Quarter Rack)
Rozmiar: 20 TB danych
Obciążenie: Oracle RAC 2-node, OLTP + reporting
Wymagania: Zero downtime, Oracle RAC, pełna kompatybilność
Integracja: Aplikacje na Azure AKS, Azure AD authentication

Architektura docelowa:

┌──────────────────────────────────────────────────────────────────┐
│                        Azure Region                               │
│                                                                   │
│  ┌──────────────────────────┐   ┌──────────────────────────────┐  │
│  │     Azure Services       │   │   Oracle Database@Azure      │  │
│  │                          │   │                              │  │
│  │  ┌─────────────────┐    │   │  ┌─────────────────────┐    │  │
│  │  │ AKS Cluster     │    │   │  │ Exadata Quarter Rack │    │  │
│  │  │ (App Tier)      │────┼───┼──│ 2 DB Servers         │    │  │
│  │  └─────────────────┘    │   │  │ 3 Storage Servers    │    │  │
│  │  ┌─────────────────┐    │   │  │ 76.8 TB Flash        │    │  │
│  │  │ Azure Functions │    │   │  │                       │    │  │
│  │  │ (Integration)   │────┼───┼──│ RAC: 2-node          │    │  │
│  │  └─────────────────┘    │   │  │ Data Guard: Enabled   │    │  │
│  │  ┌─────────────────┐    │   │  │ TDE: Enabled          │    │  │
│  │  │ Azure AD        │    │   │  └─────────────────────┘    │  │
│  │  │ (Identity)      │────┼───┼──▶ Entra ID Federation     │  │
│  │  └─────────────────┘    │   │                              │  │
│  │  ┌─────────────────┐    │   │  Billing: Azure unified     │  │
│  │  │ Azure Monitor   │    │   │  Management: OCI + Azure    │  │
│  │  └─────────────────┘    │   │                              │  │
│  └──────────────────────────┘   └──────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────┘

Plan migracji:

Faza	Zadanie	Czas
Tydzień 1	Aktywacja Oracle Database@Azure, konfiguracja OCI Tenancy	3 dni
Tydzień 1-2	Provisioning Exadata Infrastructure w Azure	3-5 dni (Oracle)
Tydzień 2	Konfiguracja sieci (Azure VNet delegation)	2 dni
tydzień 2-3	Utworzenie VM Cluster i CDB/PDB	2 dni
Tydzień 3-4	Konfiguracja Oracle Data Guard (on-prem Exadata → DB@Azure)	3 dni
Tydzień 4-6	Synchronizacja inicjalna (20 TB via ExpressRoute)	5-10 dni
Tydzień 6-7	Konfiguracja RAC, TDE, Data Guard na Azure	3 dni
Tydzień 7-8	Konfiguracja Entra ID Federation	2 dni
Tydzień 8-9	Testy wydajnościowe i HA	5 dni
Tydzień 9-10	UAT	5 dni
Tydzień 10	Cutover (Data Guard Switchover)	2h
Tydzień 11	Post-migration monitoring	5 dni

15.3 Scenariusz C: Migracja Oracle → Azure Database for PostgreSQL

Parametry wejściowe:

Baza źródłowa: Oracle 19c Standard Edition 2
Rozmiar: 500 GB danych, 50 schematów
PL/SQL: ~200 procedur, 30 pakietów, 50 trigerów
Integracja: Aplikacja Java Spring Boot (Hibernate/JPA)
Cel: Eliminacja licencji Oracle, redukcja kosztów o 60%
Dopuszczalny downtime: 8 godzin

Plan migracji:

┌─────────────────────────────────────────────────────────────────┐
│                    FAZA 1: ASSESSMENT (2 tygodnie)               │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  1. Ora2Pg Assessment Report                                     │
│     ora2pg -c ora2pg.conf -t SHOW_REPORT --estimate_cost         │
│                                                                  │
│  2. Identyfikacja niekompatybilności:                            │
│     - Pakiety PL/SQL → rozbicie na funkcje w schematach          │
│     - Oracle-specific SQL (CONNECT BY, DECODE, (+) outer join)   │
│     - Typy danych (DATE → TIMESTAMP, NUMBER → NUMERIC)           │
│     - Sekwencje i synonimy                                       │
│     - Database links → Foreign Data Wrappers                     │
│                                                                  │
│  3. Oszacowanie pracochłonności konwersji kodu                   │
│                                                                  │
│  Wynik: Migration Assessment Score: B-3                          │
│  Szacowany czas konwersji kodu: 4-6 tygodni                     │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│              FAZA 2: KONWERSJA SCHEMATU (3 tygodnie)             │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  1. Ora2Pg schema conversion:                                    │
│     ora2pg -c ora2pg.conf -t TABLE -o tables.sql                 │
│     ora2pg -c ora2pg.conf -t VIEW -o views.sql                   │
│     ora2pg -c ora2pg.conf -t SEQUENCE -o sequences.sql           │
│     ora2pg -c ora2pg.conf -t INDEX -o indexes.sql                │
│     ora2pg -c ora2pg.conf -t TRIGGER -o triggers.sql             │
│                                                                  │
│  2. Ręczna korekta typów danych:                                 │
│     - Oracle DATE → TIMESTAMP (zachowanie komponentu czasu)      │
│     - NUMBER bez precyzji → odpowiedni typ PostgreSQL            │
│     - CLOB/BLOB → TEXT/BYTEA                                     │
│                                                                  │
│  3. Provisioning Azure Database for PostgreSQL:                   │
│     - Tier: General Purpose                                      │
│     - vCores: 16, Memory: 64 GB                                 │
│     - Storage: 1 TB (auto-grow)                                  │
│     - HA: Zone-redundant                                         │
│     - Region: West Europe                                        │
│                                                                  │
│  4. Deploy schematu na PostgreSQL                                │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│              FAZA 3: KONWERSJA KODU (4-6 tygodni)                │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  1. Automatyczna konwersja (Ora2Pg):                             │
│     ora2pg -c ora2pg.conf -t FUNCTION -o functions.sql           │
│     ora2pg -c ora2pg.conf -t PROCEDURE -o procedures.sql         │
│     ora2pg -c ora2pg.conf -t PACKAGE -o packages.sql             │
│                                                                  │
│  2. Ręczna konwersja pakietów PL/SQL:                            │
│     - Każdy pakiet → schemat PostgreSQL                          │
│     - Package variables → tabela konfiguracji lub GUC            │
│     - Package cursors → funkcje zwracające SETOF                 │
│     - Package overloading → różne nazwy funkcji                  │
│                                                                  │
│  3. Konwersja Oracle-specific SQL w aplikacji:                   │
│     - Hibernate dialect: OracleDialect → PostgreSQLDialect       │
│     - Native queries: konwersja ręczna                           │
│     - JDBC driver: ojdbc → postgresql                            │
│     - Connection pool: konfiguracja pod PostgreSQL               │
│                                                                  │
│  4. Instalacja rozszerzenia orafce:                              │
│     CREATE EXTENSION orafce;                                     │
│     -- Zapewnia: NVL, DECODE, LPAD/RPAD, ADD_MONTHS, itp.       │
│                                                                  │
│  5. Instalacja pg_cron:                                          │
│     CREATE EXTENSION pg_cron;                                    │
│     -- Zamiennik Oracle DBMS_SCHEDULER                           │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│              FAZA 4: MIGRACJA DANYCH (1-2 tygodnie)              │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Metoda 1: Ora2Pg (offline, proste)                              │
│  ┌──────────────────────────────────────────────────────────┐    │
│  │ ora2pg -c ora2pg.conf -t COPY -o data.sql -j 8           │    │
│  │ psql -h pg-server -d target -f data.sql                   │    │
│  └──────────────────────────────────────────────────────────┘    │
│                                                                  │
│  Metoda 2: AWS DMS (online, CDC — jeśli na AWS)                 │
│  ┌──────────────────────────────────────────────────────────┐    │
│  │ Full Load + CDC: Oracle → PostgreSQL                      │    │
│  │ Minimalizuje downtime do czasu cutover                    │    │
│  └──────────────────────────────────────────────────────────┘    │
│                                                                  │
│  Metoda 3: Oracle GoldenGate for PostgreSQL (online)             │
│  ┌──────────────────────────────────────────────────────────┐    │
│  │ Extract z Oracle + Replicat do PostgreSQL                 │    │
│  │ Obsługuje CDC i heterogeniczną replikację                 │    │
│  └──────────────────────────────────────────────────────────┘    │
│                                                                  │
│  Walidacja danych:                                               │
│  - Porównanie row count per tabela                               │
│  - Checksum kluczowych tabel                                     │
│  - Porównanie wyników kluczowych zapytań                         │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│              FAZA 5: TESTY (3-4 tygodnie)                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  1. Testy jednostkowe PL/pgSQL (pgTAP)                           │
│  2. Testy integracyjne aplikacji                                 │
│  3. Testy wydajnościowe (porównanie z Oracle baseline)           │
│  4. Testy obciążeniowe (JMeter/Gatling)                          │
│  5. Testy failover/HA                                            │
│  6. UAT (User Acceptance Testing)                                │
│  7. Testy backupu/restore                                        │
│                                                                  │
│  Tuning PostgreSQL:                                              │
│  - shared_buffers = 16GB (25% RAM)                               │
│  - effective_cache_size = 48GB (75% RAM)                         │
│  - work_mem = 256MB                                              │
│  - maintenance_work_mem = 2GB                                    │
│  - wal_buffers = 64MB                                            │
│  - random_page_cost = 1.1 (SSD)                                 │
│  - effective_io_concurrency = 200 (SSD)                          │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│              FAZA 6: CUTOVER (8h okno migracyjne)                │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  T+00:00  Maintenance window start                               │
│  T+00:30  Zatrzymanie aplikacji                                  │
│  T+01:00  Final data sync (delta od ostatniego pełnego load)     │
│  T+03:00  Walidacja danych (row count, checksums)                │
│  T+03:30  Deploy nowej wersji aplikacji (PostgreSQL driver)      │
│  T+04:00  Smoke testy                                            │
│  T+05:00  Pełne testy regresyjne                                │
│  T+06:00  Weryfikacja monitoringu i alertów                      │
│  T+07:00  Go/No-Go decision                                     │
│  T+07:30  Ogłoszenie zakończenia maintenance                     │
│  T+08:00  Monitoring — zespół w gotowości                        │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Szacowane oszczędności:

Pozycja	Oracle (roczny)	PostgreSQL Azure (roczny)	Oszczędność
Licencja Oracle SE2 (2 proc.)	~$34,000	$0	$34,000
Oracle Support (22%)	~$7,500	$0	$7,500
Infrastruktura (serwer)	~$15,000	~$12,000 (PaaS)	$3,000
DBA (czas na patching)	~$10,000	~$2,000 (auto-patching)	$8,000
RAZEM	~$66,500	~$14,000	~$52,500 (79%)

15.4 Scenariusz D: Multi-Cloud OCI + Azure (Interconnect)

Parametry wejściowe:

Baza źródłowa: Oracle 19c EE, 10 TB, RAC, GoldenGate rep.
Aplikacje: .NET na Azure App Service, Azure AKS
Wymaganie: Najlepsza wydajność Oracle + ekosystem Azure
Region: West Europe

Plan migracji:

Faza	Zadanie	Czas
Tydzień 1	Setup OCI Tenancy, VCN, kompartmenty	3 dni
Tydzień 1-2	Konfiguracja Azure ExpressRoute + OCI FastConnect Interconnect	3 dni
Tydzień 2	Walidacja Interconnect (latency test <2ms)	1 dzień
Tydzień 2-3	Provisioning OCI Exadata Cloud Service	5 dni
Tydzień 3	Konfiguracja Oracle RAC na OCI Exadata	3 dni
Tydzień 3-4	Data Guard: on-prem → OCI (via VPN/FastConnect)	5 dni
Tydzień 4-5	Synchronizacja danych (10 TB)	5-7 dni
Tydzień 5	Federacja tożsamości Azure AD ↔︎ OCI IAM	2 dni
Tydzień 5-6	Rekonfiguracja aplikacji Azure (connection do OCI)	3 dni
Tydzień 6-7	Testy end-to-end (latency, throughput, failover)	5 dni
Tydzień 7-8	UAT	5 dni
Tydzień 8	Cutover (Data Guard Switchover)	2h

15.5 Scenariusz E: Migracja Oracle → Amazon Aurora PostgreSQL

Parametry wejściowe:

Baza źródłowa: Oracle 19c EE, 2 TB, 100 proc. w PL/SQL
Cel: Eliminacja Oracle, wysoka wydajność na AWS
Wymaganie: Minimalizacja downtime (max 2h)
Aplikacja: Microservices na ECS/EKS

Podejście: AWS SCT + DMS + ręczna konwersja kodu

┌─────────────┐    ┌──────────┐    ┌──────────────┐    ┌────────────────┐
│ AWS Schema  │───▶│ Ręczna   │───▶│ AWS DMS      │───▶│ Aurora         │
│ Conversion  │    │ konwersja│    │ Full Load    │    │ PostgreSQL     │
│ Tool (SCT)  │    │ PL/SQL   │    │ + CDC        │    │                │
│             │    │          │    │              │    │ Reader: 2      │
│ Schema      │    │ Procedures│   │ Oracle →     │    │ Writer: 1      │
│ assessment  │    │ Packages │    │ Aurora PG    │    │ Auto-scaling   │
│ & convert   │    │ Triggers │    │              │    │                │
└─────────────┘    └──────────┘    └──────────────┘    └────────────────┘

Fazy:

AWS SCT Assessment (1 tydzień) — Raport konwersji schematu
Schema Conversion (2 tygodnie) — SCT automatic + manual fixes
PL/SQL → PL/pgSQL (4-6 tygodni) — Konwersja 100 procedur
AWS DMS Setup (1 tydzień) — Full Load + CDC replication task
Application Migration (2 tygodnie) — Driver, ORM, native queries
Testing (3 tygodnie) — Functional, performance, HA
Cutover (2h) — Stop CDC, switch DNS, validate

15.6 Scenariusz F: Migracja Oracle → Azure SQL Managed Instance

Parametry wejściowe:

Baza źródłowa: Oracle 12c SE, 200 GB, 30 procedur PL/SQL
Aplikacja: .NET Framework, Entity Framework
Cel: Migracja na w pełni zarządzaną bazę Microsoft
Dopuszczalny downtime: Weekend (48h)

Podejście: SSMA + Azure DMS

┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  1. SSMA     │───▶│  2. SSMA     │───▶│  3. Azure    │───▶│  4. Azure SQL│
│  Assessment  │    │  Convert     │    │  DMS         │    │  Managed     │
│              │    │  Schema &    │    │  Data        │    │  Instance    │
│  Report:     │    │  PL/SQL →    │    │  Migration   │    │              │
│  85% auto    │    │  T-SQL       │    │  (online)    │    │  16 vCores   │
│  15% manual  │    │              │    │              │    │  64 GB RAM   │
└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘

Specyficzne konwersje dla tego scenariusza:

<a href="#cb34-1"></a>-- ORACLE: Pakiet
<a href="#cb34-2"></a>CREATE OR REPLACE PACKAGE order_pkg AS
<a href="#cb34-3"></a>  PROCEDURE create_order(p_customer_id NUMBER, p_amount NUMBER);
<a href="#cb34-4"></a>  FUNCTION get_order_total(p_order_id NUMBER) RETURN NUMBER;
<a href="#cb34-5"></a>END order_pkg;
<a href="#cb34-6"></a>
<a href="#cb34-7"></a>-- SQL SERVER: Schemat + procedury
<a href="#cb34-8"></a>CREATE SCHEMA order_pkg;
<a href="#cb34-9"></a>GO
<a href="#cb34-10"></a>
<a href="#cb34-11"></a>CREATE PROCEDURE order_pkg.create_order
<a href="#cb34-12"></a>  @p_customer_id INT,
<a href="#cb34-13"></a>  @p_amount DECIMAL(18,2)
<a href="#cb34-14"></a>AS
<a href="#cb34-15"></a>BEGIN
<a href="#cb34-16"></a>  -- konwertowany kod
<a href="#cb34-17"></a>END;
<a href="#cb34-18"></a>GO
<a href="#cb34-19"></a>
<a href="#cb34-20"></a>CREATE FUNCTION order_pkg.get_order_total(@p_order_id INT)
<a href="#cb34-21"></a>RETURNS DECIMAL(18,2)
<a href="#cb34-22"></a>AS
<a href="#cb34-23"></a>BEGIN
<a href="#cb34-24"></a>  DECLARE @total DECIMAL(18,2);
<a href="#cb34-25"></a>  -- konwertowany kod
<a href="#cb34-26"></a>  RETURN @total;
<a href="#cb34-27"></a>END;
<a href="#cb34-28"></a>GO

15.7 Scenariusz G: Migracja Oracle do OCI Autonomous Database

Parametry wejściowe:

Baza źródłowa: Oracle 19c EE, 3 TB, Oracle RAC
Cel: Najwyższy poziom automatyzacji, minimalny DBA overhead
Wymaganie: Auto-scaling, auto-patching, auto-tuning

Podejście: Oracle Zero Downtime Migration (ZDM)

┌──────────────────────────────────────────────────────────────────┐
│                    ZDM Orchestrated Migration                     │
│                                                                   │
│  Source (On-Prem)         ZDM Host           Target (OCI ADB)     │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────────┐    │
│  │ Oracle 19c   │    │ ZDM Service  │    │ Autonomous DB    │    │
│  │ RAC (EE)     │    │              │    │ Transaction      │    │
│  │              │    │ Orchestrates:│    │ Processing       │    │
│  │ 3 TB data   │───▶│ 1. Data Pump │───▶│                  │    │
│  │              │    │ 2. GoldenGate│    │ Auto-scaling     │    │
│  │              │    │ 3. Switchover│    │ 4-128 OCPU       │    │
│  └──────────────┘    └──────────────┘    └──────────────────┘    │
│                                                                   │
│  Metoda: Logical Online Migration                                 │
│  - Initial Load: Data Pump via Object Storage                     │
│  - CDC: GoldenGate (zintegrowany w ZDM)                          │
│  - Cutover: Automatyczny switchover                               │
│                                                                   │
└──────────────────────────────────────────────────────────────────┘

Uwagi dotyczące Autonomous Database:

Aspekt	Opis
Nieobsługiwane funkcje	Oracle RAC (zarządzane przez ADB), bezpośredni dostęp OS, custom patching
Mapowanie PDB	On-prem CDB/PDB → ADB (każda ADB to efektywnie PDB)
Networking	Private Endpoint w OCI VCN, dostęp przez Service Gateway
Szyfrowanie	TDE wymagane (wbudowane, Oracle-managed keys lub Customer-managed)
Backup	Automatyczny, 60 dni retencji, cross-region opcjonalnie

15.8 Scenariusz H: Migracja krytycznej bazy Oracle z zerowym downtime (GoldenGate)

Parametry wejściowe:

Baza źródłowa: Oracle 19c EE, 8 TB, 24/7 operacja
Wymaganie: Absolutnie zero downtime (system finansowy)
Cel: Oracle na Azure VM z Data Guard
Metoda: Oracle GoldenGate bidirection + logical cutover

Architektura migracji:

FAZA 1: Setup i Initial Load
═══════════════════════════════════════════════════════

On-Premises                           Azure VM
┌──────────────┐                    ┌──────────────┐
│ Oracle 19c   │  GoldenGate       │ Oracle 19c   │
│ PRIMARY      │  Extract ────────▶│ TARGET       │
│              │                    │              │
│ 8 TB data   │  Initial Load     │ Empty DB     │
│ (running)    │  (Data Pump)  ───▶│ → 8 TB       │
│              │                    │              │
│ Users: ✅   │                    │ Users: ❌    │
└──────────────┘                    └──────────────┘


FAZA 2: CDC Replication (dni/tygodnie)
═══════════════════════════════════════════════════════

On-Premises                           Azure VM
┌──────────────┐                    ┌──────────────┐
│ Oracle 19c   │  GoldenGate CDC   │ Oracle 19c   │
│ PRIMARY      │  Extract ────────▶│ TARGET       │
│              │  (real-time)       │              │
│ Zmiany ──────┤                    │──── Applies  │
│              │  Lag: <1 sec       │              │
│ Users: ✅   │                    │ Users: ❌    │
└──────────────┘                    └──────────────┘


FAZA 3: Cutover (logiczny, zero downtime)
═══════════════════════════════════════════════════════

1. Włącz bidirectional replication
2. Przekieruj ruch app → Azure (DNS TTL = 30s)
3. Weryfikacja, że zmiany replikują w obu kierunkach
4. Gdy 100% ruchu na Azure — wyłącz starą replikację

On-Premises                           Azure VM
┌──────────────┐                    ┌──────────────┐
│ Oracle 19c   │  ◀───────────────▶│ Oracle 19c   │
│ (old primary)│  Bidirectional    │ (new primary)│
│              │  GoldenGate       │              │
│ Users: ❌   │                    │ Users: ✅    │
│ (drain)      │                    │ (active)     │
└──────────────┘                    └──────────────┘

16. Porównanie kosztów

16.1 Szacunkowe koszty miesięczne (przykład: 4 TB baza, 16 vCPU, 128 GB RAM)

Opcja	Compute/mies.	Storage/mies.	Licencja Oracle/mies.	Support/mies.	TOTAL/mies.
On-premises	~$1,500 (amortz.)	~$200	~$2,800 (BYOL amortz.)	~$620	~$5,120
Azure VM (BYOL)	~$2,100	~$460	(BYOL — istniejąca)	~$620	~$3,180
Azure VM (nowa lic.)	~$2,100	~$460	~$2,800	~$620	~$5,980
Oracle DB@Azure	~$4,500 (Exadata)	Included	Included	Included	~$4,500
OCI Base DB	~$1,200	~$100	~$2,500 (BYOL)	~$550	~$4,350
OCI Autonomous DB	~$2,400	~$100	Included	Included	~$2,500
AWS EC2 (BYOL)	~$2,000	~$400	(BYOL)	~$620	~$3,020
AWS RDS Oracle	~$5,500 (license incl.)	~$400	Included	Included	~$5,900
Azure PostgreSQL	~$1,200	~$200	$0	$0	~$1,400
Aurora PostgreSQL	~$1,400	~$200	$0	$0	~$1,600
Azure SQL MI	~$2,200	Included	Included	Included	~$2,200

Uwaga: Ceny orientacyjne, zależne od regionu, typu instancji, rezerwacji i rabatów.

16.2 Koszt migracji (jednorazowy)

Scenariusz	Zespół	Czas	Szacowany koszt
Lift & Shift (Azure VM)	2-3 os.	2-3 miesiące	$30,000 – $80,000
Oracle DB@Azure	2-3 os.	2-3 miesiące	$40,000 – $100,000
OCI Migration	2-3 os.	2-3 miesiące	$30,000 – $80,000
Oracle → PostgreSQL	3-5 os.	4-8 miesięcy	$100,000 – $300,000
Oracle → Azure SQL	3-5 os.	3-6 miesięcy	$80,000 – $250,000
Multi-Cloud (OCI+Azure)	3-4 os.	3-4 miesiące	$60,000 – $150,000

17. Zarządzanie licencjami Oracle w chmurze

17.1 BYOL (Bring Your Own License)

Przeniesienie istniejących licencji Oracle do chmury:

Cloud	Reguły licencjonowania
Azure	1 Oracle Processor License = 4 vCPU (hyper-threaded), max 8 vCPU na SE2
AWS	1 Oracle Processor License = 2 vCPU (hyper-threaded) dla EC2, wyjątek dla m/r/x z BYOL
OCI	1 Oracle Processor License = 2 OCPU (natively 1 OCPU = 2 vCPU)
GCP	1 Oracle Processor License = 2 vCPU

17.2 Oracle License Included (LI)

OCI: Licencja wliczona w cenę (Autonomous DB, Exadata Cloud)
AWS RDS: Licencja wliczona w cenę instancji RDS
Oracle DB@Azure: Licencja wliczona w cenę usługi

17.3 Ważne zasady

Oracle License Agreement — Sprawdź ograniczenia w umowie (Limited Use, Named User Plus vs Processor)
Authorized Cloud Environments — Oracle oficjalnie autoryzuje: OCI, AWS, Azure, Google Cloud
Soft Partitioning vs Hard Partitioning — VMware = soft partitioning (licencja na cały host), dedicated hosts = hard partitioning
Oracle Audit — Przygotuj się na audyt Oracle po migracji
Support transfer — Poinformuj Oracle Support o zmianie platformy

17.4 Rekomendacje licencyjne

Scenariusz	Rekomendacja
Mam istniejące licencje EE	BYOL na Azure/AWS/OCI — oszczędność
Chcę uniknąć licencji Oracle	Migracja do PostgreSQL/Azure SQL
Potrzebuję RAC/Exadata	OCI lub Oracle DB@Azure (LI)
Mała baza, SE2	BYOL na VM lub migracja do PostgreSQL
Koniec umowy licencyjnej	OCI Autonomous (LI) lub refactor do open-source

18. Bezpieczeństwo i zgodność

18.1 Szyfrowanie

Warstwa	Oracle on-prem	Chmura (cel)
Data at rest	TDE (Transparent Data Encryption)	TDE + Cloud KMS (Azure Key Vault, AWS KMS, OCI Vault)
Data in transit	Oracle Native Encryption, SSL/TLS	TLS 1.2/1.3 (wymuszane)
Backup encryption	RMAN encryption	Automatyczne szyfrowanie backup (AES-256)
Network	VPN	VPN / ExpressRoute / Direct Connect / FastConnect

18.2 Kontrola dostępu

Azure: Azure AD (Entra ID) + RBAC + NSG + Private Endpoints
AWS: IAM + Security Groups + VPC Endpoints + KMS
OCI: OCI IAM + Network Security Groups + Private Endpoints
PostgreSQL: Row-Level Security (RLS), Column-Level Permissions

18.3 Zgodność regulacyjna

Standard	Azure	AWS	OCI	GCP
GDPR	✅	✅	✅	✅
ISO 27001	✅	✅	✅	✅
SOC 1/2/3	✅	✅	✅	✅
HIPAA	✅	✅	✅	✅
PCI DSS	✅	✅	✅	✅
FedRAMP	✅	✅	✅	✅

18.4 Network Security — architektura referencyjna

┌─────────────────────────────────────────────────────────────────┐
│                      Azure VNet (10.0.0.0/16)                    │
│                                                                  │
│  ┌─────────────────────────────────┐                             │
│  │  Subnet: Application (10.0.1.0/24)                            │
│  │  NSG: Allow 443 inbound, 1521 to DB subnet                   │
│  │  ┌───────────┐  ┌───────────┐                                │
│  │  │ App VM 1  │  │ App VM 2  │                                │
│  │  └───────────┘  └───────────┘                                │
│  └──────────────────────┬──────────────────────────────────────┘ │
│                         │ (NSG: only 1521)                       │
│  ┌──────────────────────┴──────────────────────────────────────┐ │
│  │  Subnet: Database (10.0.2.0/24)                              │ │
│  │  NSG: Allow 1521 from App subnet ONLY                        │ │
│  │  ┌───────────┐  ┌───────────┐                                │ │
│  │  │ Oracle VM │  │ Oracle VM │   Private Endpoint             │ │
│  │  │ (Primary) │  │ (Standby) │   (no public IP)              │ │
│  │  └───────────┘  └───────────┘                                │ │
│  └──────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  ┌──────────────────────────────────────────────────────────────┐ │
│  │  Subnet: Management (10.0.3.0/24)                            │ │
│  │  NSG: Allow SSH from Bastion only                            │ │
│  │  ┌───────────┐                                               │ │
│  │  │ Azure     │                                               │ │
│  │  │ Bastion   │                                               │ │
│  │  └───────────┘                                               │ │
│  └──────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  ExpressRoute / VPN Gateway ◀───▶ On-premises                   │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

19. Testowanie i walidacja

19.1 Plan testów post-migracyjnych

19.1.1 Testy integralności danych

<a href="#cb38-1"></a>-- Porównanie row count
<a href="#cb38-2"></a>-- Na źródle (Oracle)
<a href="#cb38-3"></a>SELECT table_name, num_rows FROM all_tables WHERE owner = 'APP_SCHEMA';
<a href="#cb38-4"></a>
<a href="#cb38-5"></a>-- Na celu (np. PostgreSQL)
<a href="#cb38-6"></a>SELECT schemaname, relname, n_live_tup FROM pg_stat_user_tables;
<a href="#cb38-7"></a>
<a href="#cb38-8"></a>-- Porównanie checksums kluczowych tabel
<a href="#cb38-9"></a>-- Oracle
<a href="#cb38-10"></a>SELECT ORA_HASH(SUM(ORA_HASH(col1||col2||col3))) FROM table1;
<a href="#cb38-11"></a>
<a href="#cb38-12"></a>-- PostgreSQL
<a href="#cb38-13"></a>SELECT md5(string_agg(md5(col1::text||col2::text||col3::text), '')) 
<a href="#cb38-14"></a>FROM table1;

19.1.2 Testy funkcjonalne

Wszystkie procedury składowane wykonują się poprawnie
Triggery działają jak oczekiwano
Widoki zwracają prawidłowe dane
Sekwencje generują prawidłowe wartości
Constraints (PK, FK, CHECK, UNIQUE) są enforce’owane
Indeksy są wykorzystywane przez optymalizator
Job scheduler działa prawidłowo
Backup/restore działa prawidłowo

19.1.3 Testy wydajnościowe

Test	Metryka	Oracle Baseline	Cloud Target	Akceptowalne
OLTP throughput	TPS	50,000	≥ 45,000	≥ 90%
Query response time	P95 (ms)	15	≤ 20	≤ 133%
Batch processing	Czas (min)	120	≤ 150	≤ 125%
Concurrent users	Sesje	2,000	≥ 2,000	≥ 100%
Backup time	Czas (min)	60	≤ 90	≤ 150%
Recovery time	RTO (min)	15	≤ 15	≤ 100%

19.1.4 Testy HA/DR

Failover automatyczny (Data Guard / Zone HA)
Switchover ręczny
Recovery z backup
Cross-region DR test
Network partition test

19.2 Narzędzia do testowania

Narzędzie	Zastosowanie
Oracle Real Application Testing (RAT)	Replay Oracle workload na nowym serwerze
Apache JMeter	Load testing aplikacji i bazy
Gatling	Performance testing
pgTAP	Unit testing PostgreSQL
tSQLt	Unit testing SQL Server
DbUnit	Database testing w Java
Flyway/Liquibase	Schema versioning i validation

20. Plan rollback

20.1 Strategia rollback dla każdego scenariusza

Lift & Shift (Data Guard)

Stan normalny po migracji:
  Cloud = PRIMARY, On-prem = STANDBY

Rollback:
  1. Switchover: Cloud → STANDBY, On-prem → PRIMARY
  2. Zmiana DNS/connection string na on-prem
  3. Walidacja

Czas rollback: ~30 minut

Migracja do PostgreSQL

Stan normalny po migracji:
  PostgreSQL = produkcja, Oracle = wyłączony

Rollback (wymaga przygotowania):
  1. Utrzymaj Oracle w stanie standby przez 2-4 tygodnie po migracji
  2. Jeśli rollback potrzebny:
     a. Zatrzymaj aplikację
     b. Reverse data sync: PostgreSQL → Oracle (GoldenGate lub dump)
     c. Przywróć starą wersję aplikacji (Oracle driver)
     d. Restart aplikacji z Oracle

Czas rollback: 4-8 godzin (zależnie od zmian w danych)

Migracja do Azure SQL

Analogicznie do PostgreSQL — utrzymaj Oracle standby.
Reverse migration za pomocą SSMA reverse lub Data Export/Import.

20.2 Macierz ryzyk i mitygacji

Ryzyko	Prawdopodobieństwo	Wpływ	Mitygacja
Utrata danych	Niskie	Krytyczny	Backup przed cutover, Data Guard w sync
Degradacja wydajności	Średnie	Wysoki	Testy obciążeniowe przed cutover, tuning
Niekompatybilność PL/SQL	Średnie (heterog.)	Wysoki	Pełna konwersja i testy przed cutover
Problemy sieciowe	Niskie	Średni	Redundantne połączenia, ExpressRoute
Przekroczenie okna migracji	Średnie	Średni	Rehearsal migration, buffer w planie
Problemy licencyjne	Niskie	Wysoki	Konsultacja z Oracle LMS przed migracją
Brak kompetencji zespołu	Średnie	Średni	Szkolenia, wsparcie partnera Oracle

21. Podsumowanie i rekomendacje

21.1 Drzewo decyzyjne

                    Czy chcesz zachować Oracle?
                            │
                    ┌───────┴───────┐
                    │               │
                   TAK             NIE
                    │               │
            ┌───────┴────┐    ┌────┴───────────────┐
            │            │    │                    │
      Zero zmian    Optymalizacja   Jaka baza docelowa?
        w kodzie     i zarządzanie       │
            │            │         ┌─────┴─────┐
            │            │         │           │
       Lift&Shift  Oracle PaaS  PostgreSQL  SQL Server
            │            │         │           │
     ┌──────┴──┐    ┌───┴────┐    │       Azure SQL MI
     │         │    │        │    │       (SSMA)
   Azure     AWS   OCI    DB@Azure │
   VM (IaaS) EC2  Autonomous      │
                  /Exadata   Azure DB for
                              PostgreSQL
                            / Aurora PG
                            (Ora2Pg/SCT)

21.2 Rekomendacje według profilu

Profil organizacji	Rekomendowana opcja	Powód
Duży enterprise, mocno zintegrowany z Oracle, minimalne ryzyko	Oracle Database@Azure lub OCI Exadata	Pełna kompatybilność, minimalne zmiany
Enterprise na Azure, potrzeba Oracle wydajności	Oracle Database@Azure	Natywna integracja, Exadata performance
Enterprise, multi-cloud strategy	OCI-Azure Interconnect	Best of both worlds
Średnia firma, chce zredukować koszty Oracle	Migracja do PostgreSQL (Azure/AWS)	Eliminacja licencji, 60-80% oszczędności
Firma .NET/Microsoft stack	Azure SQL Managed Instance (SSMA)	Naturalna integracja z ekosystemem MS
Startup/mała firma z Oracle	PostgreSQL na Azure/AWS	Minimalne koszty, open-source
Szybka migracja, minimalne ryzyko	Lift & Shift na Azure/AWS VM	Najszybsza ścieżka, BYOL
Krytyczny system 24/7	GoldenGate + Azure VM/OCI	Zero downtime, pełna kontrola
Chce pozbyć się zarządzania DB	OCI Autonomous Database	Auto-everything, minimalny DBA

21.3 Kolejne kroki

✅ Przeprowadź inwentaryzację środowiska Oracle
✅ Wykonaj assessment z użyciem odpowiedniego narzędzia (Ora2Pg, SSMA, AWS SCT)
✅ Wybierz docelową platformę na podstawie drzewa decyzyjnego
✅ Przeprowadź Proof of Concept (PoC) na wybranej platformie
✅ Zaplanuj budżet migracji i docelowy TCO
✅ Przeprowadź rehearsal migration na środowisku testowym
✅ Zaplanuj okno migracyjne i procedurę cutover
✅ Wykonaj migrację produkcyjną według wybranego scenariusza
✅ Monitoring post-migracyjny
✅ Decommission starego środowiska (po potwierdzeniu stabilności)

Artykuł ten został przygotowany jako kompletne kompendium wiedzy o migracji Oracle Database do chmury. Każdy scenariusz powinien być dostosowany do specyficznych wymagań organizacji.