Migracja Oracle do Oracle Database@Azure

Oracle Database@Azure to usługa powstała w wyniku strategicznego partnerstwa Oracle i Microsoft, która umożliwia uruchamianie infrastruktury Oracle Exadata fizycznie wewnątrz centrów danych Azure. Nie jest to zwykła maszyna wirtualna z Oracle — to dedykowany sprzęt Exadata zainstalowany bezpośrednio w Azure datacenter, podłączony do sieci Azure z ultra-niskim opóźnieniem.

1. Kluczowa koncepcja

Poniżej w tabeli przedstawiona jest kluczowa koncepcja migracji

Aspekt	Opis
Fizyczna lokalizacja	Serwery Oracle Exadata stoją w tym samym datacenter co Twoje zasoby Azure
Sieć	Bezpośrednie połączenie L2 z Azure VNet — latency <2ms (typowo <1ms)
Zarządzanie sprzętem	Oracle zarządza sprzętem Exadata (patching firmware, wymiana dysków)
Zarządzanie bazą	Ty zarządzasz bazą danych (lub Oracle w przypadku Autonomous DB)
Billing	Jedna faktura Azure — koszty Oracle Database@Azure pojawiają się na Azure billing
Support	Wspólny model wsparcia Oracle + Microsoft — jeden ticket trafia do obu

---

2. Architektura techniczna

2.1 Warstwy architektury

┌─────────────────────────────────────────────────────────────────────┐
│ WARSTWA ZARZĄDZANIA                                                 │
│ ┌──────────────────────┐  ┌─────────────────────────┐               │
│ │   Azure Portal       │  │   OCI Console           │               │
│ │   (provisioning,     │  │   (DB management,       │               │
│ │    networking,       │  │    patching,            │               │
│ │    billing)          │  │    backup,              │               │
│ │                      │  │    monitoring)          │               │
│ │   Azure CLI / ARM    │  │    OCI CLI / Terraform  │               │
│ └──────────┬───────────┘  └───────────┬─────────────┘               │
│            │       Control Plane      │                             │
├────────────┴──────────────────────────┴─────────────────────────────┤
│ WARSTWA COMPUTE (Exadata VM Cluster)                                │
│                                                                     │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐ │
│  │ DB Server 1 │  │ DB Server 2 │  │ DB Server 3 │  │ DB Server N │ │
│  │             │  │             │  │             │  │             │ │
│  │ Oracle RAC  │  │ Oracle RAC  │  │ Oracle RAC  │  │ Oracle RAC  │ │
│  │ Instance    │  │ Instance    │  │ Instance    │  │ Instance    │ │
│  │             │  │             │  │             │  │             │ │
│  │ OCPUs: 2-64 │  │ OCPUs: 2-64 │  │ OCPUs: 2-64 │  │ OCPUs: 2-64 │ │
│  │ RAM: prop.  │  │ RAM: prop.  │  │ RAM: prop.  │  │ RAM: prop.  │ │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘ │
│         │                │                │                │        │
│         └────────────────┴────────────────┴────────────────┘        │
│                          │ InfiniBand Fabric                        │
│                          │ (RDMA, 100 Gbps)                         │
├──────────────────────────┴──────────────────────────────────────────┤
│ WARSTWA STORAGE (Exadata Storage Servers)                           │
│                                                                     │
│  ┌───────────────┐  ┌───────────────┐  ┌───────────────┐            │
│  │ Storage Srv 1 │  │ Storage Srv 2 │  │ Storage Srv 3 │            │
│  │               │  │               │  │               │            │
│  │ Smart Flash   │  │ Smart Flash   │  │ Smart Flash   │            │
│  │ Cache         │  │ Cache         │  │ Cache         │            │
│  │               │  │               │  │               │            │
│  │ NVMe + HDD    │  │ NVMe + HDD    │  │ NVMe + HDD    │            │
│  │ Smart Scan    │  │ Smart Scan    │  │ Smart Scan    │            │
│  │ HCC           │  │ HCC           │  │ HCC           │            │
│  └───────────────┘  └───────────────┘  └───────────────┘            │
│                                                                     │
│  Łączna pojemność: 76.8 TB (Quarter) → 307.2+ TB (Full Rack)        │
└─────────────────────────────────────────────────────────────────────┘

2.2 Sieciowa integracja z Azure

┌─────────────────────────────────────────────────────────────────────┐
│                        Azure VNet (10.0.0.0/16)                     │
│                                                                     │
│  ┌────────────────────────────────────────────────────────────────┐ │
│  │  Subnet: Application (10.0.1.0/24)                             │ │
│  │  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌───────────────────┐  │ │
│  │  │ AKS      │ │ App Svc  │ │ VM       │ │ Azure Functions   │  │ │
│  │  └────┬─────┘ └────┬─────┘ └────┬─────┘ └────────┬──────────┘  │ │
│  └───────┼────────────┼────────────┼────────────────┼─────────────┘ │
│          │            │            │                │               │
│          └────────────┴────────────┴────────────────┘               │
│                              │                                      │
│                    ┌─────────┴─────────┐                            │
│                    │   VNet Routing     │                           │
│                    │   (<1ms latency)   │                           │
│                    └─────────┬─────────┘                            │
│                              │                                      │
│  ┌───────────────────────────┴─────────────────────────────────────┐│
│  │  Delegated Subnet: Oracle (10.0.10.0/24)                        ││
│  │  *** Ten subnet jest "delegowany" do Oracle Database@Azure ***  ││
│  │                                                                 ││
│  │  ┌─────────────────────────────────────────────────────────┐    ││
│  │  │              Oracle Exadata Infrastructure              │    ││
│  │  │                                                         │    ││
│  │  │  Client Network: 10.0.10.10-20  (dostęp z aplikacji)    │    ││
│  │  │  Backup Network: 10.0.10.100-110 (backup do OCI OS)     │    ││
│  │  │                                                         │    ││
│  │  │  SCAN Listener: 10.0.10.15:1521                         │    ││
│  │  │  VIP Node 1:    10.0.10.11:1521                         │    ││
│  │  │  VIP Node 2:    10.0.10.12:1521                         │    ││
│  │  └─────────────────────────────────────────────────────────┘    ││
│  └─────────────────────────────────────────────────────────────────┘│
│                                                                     │
│  ┌────────────────────────────────────────────────────────────────┐ │
│  │  Azure Services dostępne przez VNet:                           │ │
│  │  • Azure Key Vault (Private Endpoint) — klucze szyfrowania     │ │
│  │  • Azure Monitor — metryki i logi                              │ │
│  │  • Azure AD (Entra ID) — tożsamość                             │ │
│  │  • Azure Storage — dodatkowy backup/staging                    │ │
│  └────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘

---

3. Dostępne usługi w ramach Oracle Database@Azure

W ramach Oracle Database@Azure dostępne są następujące usługi Oracle:

3.1 Oracle Exadata Database Service

To podstawowa usługa — Oracle Database na infrastrukturze Exadata, zarządzana przez klienta w zakresie bazy danych.

Parametr	Opis
Typ	PaaS (Platform as a Service) — oracle zarządza HW, klient zarządza DB
Compute	Skalowalne DB Servers (2-64+ OCPUs per node)
Storage	Exadata Smart Storage (NVMe + HDD, Smart Scan, HCC)
RAC	✅ W pełni wspierane Oracle RAC
Data Guard	✅ W pełni wspierane (local i cross-region)
Multitenant	✅ CDB/PDB architektura
Wersje Oracle	19c, 21c, 23ai
Zarządzanie	OCI Console, OCI CLI, Terraform OCI Provider

3.2 Oracle Autonomous Database on Exadata

W pełni zarządzana (serverless) baza Oracle na infrastrukturze Exadata w Azure.

Parametr	Opis
Typ	PaaS (w pełni zarządzane — auto-tuning, auto-scaling, auto-patching)
Warianty	ATP (Transaction Processing), ADW (Data Warehouse), AJD (JSON), APEX
Compute	Auto-scaling 1-128 ECPUs
Storage	Auto-scaling 1 TB – 384 TB
RAC	Zarządzane automatycznie (ukryte przed użytkownikiem)
Data Guard	✅ Autonomous Data Guard
Wersje Oracle	19c, 23ai
Zarządzanie	Minimalne — Oracle zarządza prawie wszystkim

3.3 Oracle Exadata Database Service on Dedicated Infrastructure

Dedykowana infrastruktura Exadata — pełna izolacja sprzętowa.

Parametr	Opis
Izolacja	Fizycznie dedykowane serwery (nie shared)
Kontrola	Większa kontrola nad patchowaniem i maintenance windows
Zastosowanie	Najbardziej wymagające workloads, compliance

3.4 Porównanie wariantów

Cecha	Exadata DB Service	Autonomous DB	Exadata Dedicated
Zarządzanie DB przez klienta	✅ Pełne	❌ Minimalne	✅ Pełne
Zarządzanie HW	Oracle	Oracle	Oracle
Auto-tuning	❌	✅	❌
Auto-scaling	❌ (ręczne)	✅	❌ (ręczne)
Auto-patching DB	❌ (klient)	✅	❌ (klient)
Oracle RAC management	Klient	Automatyczne	Klient
Dostęp SSH do DB servers	✅	❌	✅
Custom Oracle patches	✅	❌	✅
PDB management	✅	❌ (1 PDB = 1 ADB)	✅
Izolacja fizyczna	Shared infra	Shared	Dedicated
Cena	Średnia	Niska-Średnia	Wysoka
Idealne dla	DBA z pełną kontrolą	Minimal DBA overhead	Compliance, max izolacja

---

4. Czy mogę w pełni zmigrować istniejące środowisko?

4.1 Krótka odpowiedź

TAK — Oracle Database@Azure zapewnia niemal 100% kompatybilności z on-premises Oracle Database, ponieważ bazuje na identycznym oprogramowaniu Oracle Database działającym na identycznym sprzęcie Oracle Exadata. To nie jest emulacja ani alternatywny silnik — to ten sam Oracle Database, który znasz z on-premises.

4.2 Szczegółowa odpowiedź — co można zmigrować

Komponent środowiska	Pełna migracja?	Szczegóły
Schemat bazy danych (tabele, widoki, indeksy, constraints)	✅ 100%	Identyczny silnik — zero zmian
PL/SQL (pakiety, procedury, funkcje, triggery)	✅ 100%	Ten sam PL/SQL engine
Oracle RAC	✅ 100%	Natywne RAC na Exadata
Oracle Data Guard	✅ 100%	Pełne wsparcie — local i cross-region
Oracle ASM	✅ 100%	Natywne ASM na Exadata Storage
Partitioning	✅ 100%	Wszystkie typy partycjonowania
Advanced Compression	✅ 100%	+ Exadata HCC (Hybrid Columnar Compression)
Transparent Data Encryption (TDE)	✅ 100%	Wymagane (domyślnie włączone) + Oracle Key Vault / OCI Vault
Oracle Advanced Security	✅ 100%	TDE + Network Encryption + Data Redaction
Oracle Spatial and Graph	✅ 100%	Pełne wsparcie
Oracle Text	✅ 100%	Pełne wsparcie
Oracle OLAP	✅ 100%	Pełne wsparcie
Oracle Multimedia	✅ 100%	Pełne wsparcie
Oracle Label Security	✅ 100%	Pełne wsparcie
Oracle Database Vault	✅ 100%	Pełne wsparcie
Oracle Audit Vault	✅ 100%	Pełne wsparcie / Unified Auditing
Oracle Real Application Testing (RAT)	✅ 100%	Capture & Replay wspierane
Oracle Flashback	✅ 100%	Flashback Query, Table, Database
Oracle Streams / Advanced Queuing	✅ 100%	AQ działa natywnie
Oracle Scheduler (DBMS_SCHEDULER)	✅ 100%	Pełne wsparcie
Oracle XML DB	✅ 100%	Pełne wsparcie
Oracle JSON	✅ 100%	JSON Relational Duality w 23ai
Database Links	✅ 100%	Lokalne i zdalne DB links
Materialized Views	✅ 100%	Pełne wsparcie + fast refresh
Sequences	✅ 100%	Without any changes
Synonyms	✅ 100%	Public i private synonyms
Oracle Enterprise Manager (OEM)	✅ 100%	Można podłączyć OEM Cloud Control
GoldenGate	✅ 100%	Jako source i target (on-prem ↔︎ DB@Azure)
Java w bazie (OJVM)	✅ 100%	Oracle JVM wspierane na Exadata
Oracle Application Express (APEX)	✅ 100%	Zainstalowane domyślnie
Oracle REST Data Services (ORDS)	✅ 100%	Pełne wsparcie
Multitenant (CDB/PDB)	✅ 100%	Natywne wsparcie, wiele PDB na CDB
In-Memory Column Store	✅ 100%	Pełne wsparcie
Sharding	✅ 100%	Oracle Sharding wspierane
Oracle Autonomous Health Framework	✅ 100%	TFA, ORAchk
Oracle Active Data Guard	✅ 100%	Read-only standby with queries
Connection string / TNS	⚠️ Zmiana	Nowy connection string (SCAN, Easy Connect)
OS-level cron jobs	⚠️ Adaptacja	Przenieść do DBMS_SCHEDULER lub Azure Automation
Custom OS scripts	⚠️ Adaptacja	SSH dostęp jest, ale skrypty mogą wymagać zmian
Oracle Net (Listener)	✅ 100%	Konfiguracja przez OCI Console
Exadata-specific features	✅ 100%	Smart Scan, Storage Indexes, HCC — natywne

4.3 Co NIE wymaga zmian przy migracji

Jeśli Twoje obecne środowisko to Oracle Database (dowolna wersja 11.2.0.4+) na dowolnej infrastrukturze, to następujące elementy działają identycznie bez żadnych zmian:

✅ Cały kod PL/SQL (pakiety, procedury, funkcje, triggery)
✅ Wszystkie zapytania SQL
✅ Schemat bazy (DDL)
✅ Dane (DML)
✅ Indeksy (B-tree, Bitmap, Function-based, Partitioned)
✅ Constrainty (PK, FK, CHECK, UNIQUE, NOT NULL)
✅ Widoki (proste i złożone)
✅ Materialized Views
✅ Sekwencje
✅ Synonimy
✅ Database Links (po zmianie TNS)
✅ Oracle Net connfiguracja (po zmianie adresów)
✅ JDBC / OCI / ODBC aplikacje (po zmianie connection string)
✅ Oracle konfiguracja initialization parameters (pfile/spfile)
✅ Grants i role bezpieczeństwa
✅ Policies (VPD, RLS)
✅ Profiles
✅ Directories (mogą wymagać nowych ścieżek)
✅ Tablespace konfiguracja (ASM zarządzane)

4.4 Co wymaga adaptacji (ale nie blokuje migracji)

Element	Zmiana wymagana	Nakład pracy
Connection string	Nowy endpoint (SCAN address w Azure)	30 minut
TNS konfiguracja	Aktualizacja tnsnames.ora w aplikacjach	1-2 godziny
OS-level cron jobs	Przeniesienie do DBMS_SCHEDULER lub Azure Automation	1-2 dni
Custom OS scripts (backup, monitoring)	Adaptacja do OCI-managed backup lub zachowanie z SSH	1-3 dni
Firewall rules	NSG reguły w Azure VNet zamiast on-prem firewall	1 dzień
DNS resolution	Aktualizacja DNS wpisów dla bazy	1 godzina
Oracle Wallet (TDE)	Rekonfiguracja wallet/klucza w OCI Vault	1-2 godziny
Oracle Enterprise Manager	Konfiguracja OEM Cloud Control targets	1 dzień
Data Guard konfiguracja	Nowa konfiguracja DG w DB@Azure	1-2 dni
Monitoring skrypty	Adaptacja do Azure Monitor + OCI metryki	2-3 dni
Disaster Recovery plan	Aktualizacja DR procedur i dokumentacji	2-3 dni

---

5. Macierz kompatybilności funkcji Oracle

5.1 Oracle Database Features — pełna macierz

Funkcja Oracle	On-Premises	DB@Azure Exadata	DB@Azure Autonomous	Uwagi
CORE DATABASE
SQL	✅	✅	✅	Identyczny silnik
PL/SQL	✅	✅	✅	Pełna kompatybilność
JDBC / OCI / ODBC	✅	✅	✅	Zmiana conn. string
JSON Support	✅	✅	✅
XML DB	✅	✅	✅
HIGH AVAILABILITY
Oracle RAC	✅	✅	✅ (auto-managed)	Identyczny RAC
Data Guard (Physical Standby)	✅	✅	✅ (auto-managed)	Cross-region
Active Data Guard	✅	✅	✅	Read-only standby
Data Guard Far Sync	✅	✅	❌	Nie w Autonomous
GoldenGate	✅	✅	✅ (limited)
Flashback Database	✅	✅	✅
Flashback Table/Query	✅	✅	✅
Application Continuity	✅	✅	✅
Transaction Guard	✅	✅	✅
PERFORMANCE
Exadata Smart Scan	N/A*	✅	✅	*Jeśli on-prem nie jest Exadata
Exadata Smart Flash Cache	N/A*	✅	✅
Exadata HCC (Compression)	N/A*	✅	✅	Ogromne oszczędności storage
Exadata Storage Indexes	N/A*	✅	✅
In-Memory Column Store	✅	✅	✅
In-Memory Aggregation	✅	✅	✅
Partitioning (Range, List, Hash, Composite)	✅	✅	✅
Advanced Index Compression	✅	✅	✅
Result Cache	✅	✅	✅
Parallel Query / DML	✅	✅	✅
Resource Manager	✅	✅	✅ (auto)
SQL Plan Management	✅	✅	✅ (auto w ADB)
SQL Tuning Advisor	✅	✅	✅ (auto w ADB)
SECURITY
Transparent Data Encryption (TDE)	✅	✅ (wymagane)	✅ (wymagane)	Domyślnie ON
Data Redaction	✅	✅	✅
Database Vault	✅	✅	✅
Label Security	✅	✅	✅
Virtual Private Database (VPD)	✅	✅	✅
Audit Vault / Unified Auditing	✅	✅	✅
Network Encryption (Native/SSL)	✅	✅	✅ (wymuszone)
Oracle Key Vault	✅	✅	❌ (OCI Vault)
Privilege Analysis	✅	✅	✅
DEVELOPMENT
APEX	✅	✅	✅	Preinstalowany
ORDS (REST)	✅	✅	✅
Oracle Text (Full-Text Search)	✅	✅	✅
Oracle Spatial and Graph	✅	✅	✅
Oracle Machine Learning (OML)	✅	✅	✅
Oracle OLAP	✅	✅	❌	Deprecated
Java w bazie (OJVM)	✅	✅	❌	Nie w Autonomous
MANAGEMENT
Enterprise Manager (OEM)	✅	✅	⚠️ Limited	OCI Console zamiast OEM
AWR / ASH	✅	✅	✅
ADDM	✅	✅	✅ (auto w ADB)
SQL Monitor	✅	✅	✅
DBMS_SCHEDULER	✅	✅	✅
Data Pump (expdp/impdp)	✅	✅	✅
RMAN	✅	✅	❌ (auto backup)	ADB ma auto backup
SQL*Loader	✅	✅	✅ (via DBMS_CLOUD)
REPLICATION & INTEGRATION
GoldenGate (source)	✅	✅	✅
GoldenGate (target)	✅	✅	✅
Streams / AQ	✅	✅	✅
Database Links	✅	✅	✅
Foreign Data Wrappers	N/A	N/A	N/A	Nie dotyczy Oracle
Heterogeneous Services	✅	✅	❌
MULTITENANT
CDB/PDB Architecture	✅	✅	✅ (1 PDB per ADB)
Multiple PDBs per CDB	✅	✅	❌
PDB Cloning	✅	✅	✅ (clone ADB)
PDB Relocate	✅	✅	❌
23ai NEW FEATURES
JSON Relational Duality	✅	✅	✅
AI Vector Search	✅	✅	✅
Property Graph	✅	✅	✅
True Cache	✅	✅	❌
Globally Distributed DB	✅	✅	❌

5.2 Podsumowanie kompatybilności

Oracle Database@Azure (Exadata DB Service):
─────────────────────────────────────────
Kompatybilność z on-premises:  ~99.5%

Elementy 100% kompatybilne:    Silnik SQL/PL/SQL, RAC, Data Guard,
                                ASM, Partitioning, Compression, TDE,
                                Security, Spatial, Text, OLAP, OEM,
                                GoldenGate, Multitenant, In-Memory

Elementy z drobnymi różnicami:  OS access (jest, ale managed),
                                Storage layout (Exadata ASM),
                                Network configuration (Azure VNet),
                                Backup (OCI managed + RMAN)

Oracle Database@Azure (Autonomous DB):
─────────────────────────────────────────
Kompatybilność z on-premises:  ~95%

Brakujące funkcje:              OJVM (Java w bazie), Oracle OLAP,
                                Multiple PDBs, RMAN management,
                                OS SSH access, custom patching,
                                Heterogeneous Services,
                                Data Guard Far Sync,
                                pełne zarządzanie RAC

---

6. Obsługiwane wersje i edycje Oracle

6.1 Wersje Oracle na DB@Azure

Wersja Oracle	Exadata DB Service	Autonomous DB	End of Support
Oracle 19c (19.x)	✅	✅	Premier: Apr 2024 → Extended: Apr 2027
Oracle 21c (21.x)	✅	❌	Premier: Apr 2024 → Extended: Apr 2026
Oracle 23ai	✅	✅	Premier: Apr 2029 → Extended: Apr 2032

6.2 Edycje

Edycja	Exadata DB Service	Autonomous DB
Enterprise Edition (EE)	✅	✅ (wbudowane)
Standard Edition 2 (SE2)	❌	❌
Express Edition (XE)	❌	❌

Ważne: Oracle Database@Azure działa wyłącznie na Enterprise Edition. Jeśli masz Standard Edition 2 (SE2), potrzebujesz upgrade do EE lub rozważ inną ścieżkę migracji (Oracle na Azure VM z SE2).

6.3 Ścieżki upgrade wersji przy migracji

Obecna wersja on-premises          →  Docelowa wersja na DB@Azure
═════════════════════════════════      ═══════════════════════════

Oracle 11.2.0.4 (11g R2)           →  Oracle 19c  (upgrade + migracja)
Oracle 12.1.0.2 (12c R1)           →  Oracle 19c  (upgrade + migracja)
Oracle 12.2.0.1 (12c R2)           →  Oracle 19c  (upgrade + migracja)
Oracle 18c (18.x)                  →  Oracle 19c  (upgrade + migracja)
Oracle 19c (19.x)                  →  Oracle 19c  (bezpośrednia migracja)
Oracle 19c (19.x)                  →  Oracle 23ai (upgrade + migracja)
Oracle 21c (21.x)                  →  Oracle 21c  (bezpośrednia migracja)
Oracle 21c (21.x)                  →  Oracle 23ai (upgrade + migracja)

6.4 Migracja z non-CDB do CDB/PDB

Oracle Database@Azure wymaga architektury Multitenant (Container Database). Jeśli Twoja baza jest non-CDB:

Przed migracją:                    Po migracji na DB@Azure:
┌──────────────────┐               ┌──────────────────┐
│  Non-CDB         │               │  CDB (Container) │
│  Oracle Database  │  ─────────▶  │  ┌──────────────┐│
│  (np. 12c bez CDB)│              │  │ PDB: APPDB   ││
│                   │               │  │ (Twoje dane) ││
│  SCHEMA1          │               │  │              ││
│  SCHEMA2          │               │  │ SCHEMA1      ││
│  SCHEMA3          │               │  │ SCHEMA2      ││
│                   │               │  │ SCHEMA3      ││
└──────────────────┘               │  └──────────────┘│
                                    │  PDB$SEED        │
                                    └──────────────────┘

Narzędzie konwersji:
  Oracle 19c+: DBMS_PDB.DESCRIBE (non-CDB to PDB plugin)
  Lub: Data Pump export z non-CDB → import do PDB

---

7. Infrastruktura Exadata w Azure — specyfikacja

7.1 Konfiguracje Exadata Infrastructure

Konfiguracja	DB Servers	Storage Servers	OCPU (total)	RAM (total)	Flash Storage	Disk Storage	IOPS	Bandwidth
Quarter Rack (X9M)	2	3	100	1,440 GB	76.8 TB	128.8 TB	1.5M	48 GB/s
Half Rack (X9M)	4	6	200	2,880 GB	153.6 TB	257.6 TB	3M	96 GB/s
Full Rack (X9M)	8	12	400	5,760 GB	307.2 TB	515.2 TB	6M	192 GB/s
Quarter Rack (X10M)	2	3	126	2,016 GB	102.4 TB	128.8 TB	2M+	64 GB/s
Multi-Rack	Skalowalne	Skalowalne	Skalowalne	Skalowalne	Skalowalne	Skalowalne	Skalowalne	Skalowalne

7.2 Elastyczne skalowanie compute (OCPU)

W ramach zakupionej infrastruktury możesz elastycznie przydzielać OCPUs do VM Cluster:

Exadata Infrastructure: Quarter Rack X9M (100 OCPU total)
═══════════════════════════════════════════════════════════

Scenariusz 1: Jeden duży cluster
  VM Cluster 1:  [████████████████████████████████████] 100 OCPU
                  CDB z wieloma PDB

Scenariusz 2: Dwa klastry (prod + dev)
  VM Cluster 1 (PROD):  [██████████████████████████] 76 OCPU
  VM Cluster 2 (DEV):   [████████]                   24 OCPU

Scenariusz 3: Trzy klastry (prod + staging + dev)
  VM Cluster 1 (PROD):     [████████████████████] 60 OCPU
  VM Cluster 2 (STAGING):  [██████████]           25 OCPU
  VM Cluster 3 (DEV):      [██████]               15 OCPU

Skalowanie: Online, bez downtime!
  VM Cluster 1:  60 OCPU → 80 OCPU  (dodanie compute w minutach)
  VM Cluster 2:  25 OCPU → 15 OCPU  (redukcja)

7.3 Storage — jak działa Exadata Smart Storage

┌───────────────────────────────────────────────────────────────┐
│                   Exadata Smart Storage                        │
│                                                                │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │  WARSTWA 1: Smart Flash Cache (NVMe)                     │  │
│  │  • Automatyczne cache'owanie gorących danych              │  │
│  │  • Latency: <0.1ms                                        │  │
│  │  • Pojemność: 76.8 - 307.2 TB (zależnie od rack)         │  │
│  └─────────────────────────────────────────────────────────┘  │
│                          │ (cache miss)                        │
│                          ▼                                     │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │  WARSTWA 2: High Capacity Disk (HDD)                     │  │
│  │  • Dane historyczne i rzadko używane                      │  │
│  │  • Pojemność: 128.8 - 515.2 TB (zależnie od rack)       │  │
│  └─────────────────────────────────────────────────────────┘  │
│                                                                │
│  FUNKCJE SMART STORAGE:                                        │
│  ┌─────────────────┐  ┌─────────────────┐  ┌───────────────┐  │
│  │ Smart Scan      │  │ Storage Index   │  │ HCC           │  │
│  │                 │  │                 │  │ (Compression)  │  │
│  │ Offload SQL     │  │ Automatyczne    │  │ 10-50x        │  │
│  │ predicates to   │  │ eliminowanie    │  │ kompresja      │  │
│  │ storage server  │  │ niepotrzebnych  │  │ kolumnowa      │  │
│  │ → mniej danych  │  │ I/O operations  │  │               │  │
│  │ do DB server    │  │                 │  │               │  │
│  └─────────────────┘  └─────────────────┘  └───────────────┘  │
└───────────────────────────────────────────────────────────────┘

7.4 Wydajność — porównanie z on-premises (non-Exadata)

Metryka	Typowy on-premises (nie-Exadata)	DB@Azure (Exadata)	Poprawa
Random Read IOPS	20,000-100,000	1,500,000+	15-75x
Sequential Read throughput	2-8 GB/s	48-192 GB/s	10-25x
Smart Scan offload	N/A	Tak	Ogromne dla full scan
HCC kompresja	N/A	10-50x	Znaczne oszczędności storage
Flash cache latency	1-3ms (SSD)	<0.1ms (NVMe Flash)	10-30x
InfiniBand fabric	N/A (Ethernet)	100 Gbps RDMA	5-10x

Wniosek: Jeśli Twoje obecne środowisko NIE jest Exadata, to migracja do DB@Azure może przynieść znaczącą poprawę wydajności — nie tylko zachowanie status quo!

---

8. Networking i integracja z Azure

8.1 Model sieciowy

Oracle Database@Azure wykorzystuje delegowany subnet w Azure VNet. Oznacza to, że:

1. Tworzysz Azure VNet jak zwykle
2. Wydzielasz subnet i “delegujesz” go do Oracle Database@Azure
3. Oracle Exadata otrzymuje IP adresy z tego subnetu
4. Ruch sieciowy między aplikacjami Azure a bazą Oracle odbywa się w ramach VNet (bez wychodzenia do internetu)

8.2 Typy adresów IP w Exadata

Delegated Subnet: 10.0.10.0/24
═══════════════════════════════

Client Network (dostęp aplikacji):
  SCAN IP 1:    10.0.10.15    ← Aplikacje łączą się tutaj
  SCAN IP 2:    10.0.10.16    ← (load balancing Oracle Net)
  SCAN IP 3:    10.0.10.17

  VIP Node 1:   10.0.10.11    ← Virtual IP serwera DB 1
  VIP Node 2:   10.0.10.12    ← Virtual IP serwera DB 2

Backup Network (backup do OCI Object Storage):
  Backup IP 1:  10.0.10.100
  Backup IP 2:  10.0.10.101

DNS: 
  Automatyczne DNS resolution w Azure Private DNS Zone
  Lub: custom DNS z Azure DNS Private Resolver

8.3 Connection string — jak łączyć się z aplikacji

# Easy Connect Plus (zalecane):
jdbc:oracle:thin:@//scan-hostname.oraclevcn.com:1521/APPDB_PDB1.oraclevcn.com

# TNS-style (tradycyjny):
APPDB = (DESCRIPTION =
  (ADDRESS_LIST =
    (ADDRESS = (PROTOCOL = TCP)(HOST = scan-hostname)(PORT = 1521))
  )
  (CONNECT_DATA =
    (SERVER = DEDICATED)
    (SERVICE_NAME = APPDB_PDB1.oraclevcn.com)
  )
)

# mTLS (wzajemne TLS — Autonomous Database):
jdbc:oracle:thin:@appdb_tp?TNS_ADMIN=/path/to/wallet

8.4 Łączność z innymi zasobami

┌──────────────────────────────────────────────────────────────────┐
│                    Azure VNet                                     │
│                                                                   │
│  Oracle DB@Azure ◀──────▶ Azure AKS          (w ramach VNet)    │
│  Oracle DB@Azure ◀──────▶ Azure App Service   (VNet Integration) │
│  Oracle DB@Azure ◀──────▶ Azure VM            (w ramach VNet)    │
│  Oracle DB@Azure ◀──────▶ Azure Functions     (VNet Integration) │
│                                                                   │
│  Oracle DB@Azure ◀──VNet Peering──▶ Inne VNety w Azure           │
│  Oracle DB@Azure ◀──ExpressRoute──▶ On-premises                  │
│  Oracle DB@Azure ◀──VPN Gateway──▶ On-premises                    │
│  Oracle DB@Azure ◀──Azure Private Link──▶ Inne Azure Services    │
│                                                                   │
│  Oracle DB@Azure ✖ Brak publicznego IP (private only)            │
└──────────────────────────────────────────────────────────────────┘

8.5 Rekomendowane subnety

Subnet	CIDR	Przeznaczenie	Min. rozmiar
Application	/24	Serwery aplikacyjne	/24
Oracle Delegated	/26 min.	Oracle Exadata client + backup	/26 (zalecane /24)
Management	/27	Bastion, monitoring	/27
Gateway	/27	ExpressRoute/VPN Gateway	/27

---

9. Tożsamość i zarządzanie dostępem

9.1 Model zarządzania — dual control plane

Oracle Database@Azure ma dwa control plane’y, które współpracują:

┌────────────────────────────────────┐  ┌────────────────────────────────┐
│         Azure Control Plane        │  │       OCI Control Plane        │
│                                    │  │                                │
│  ✅ Provisioning infrastruktury    │  │  ✅ Zarządzanie bazą danych   │
│  ✅ Networking (VNet, Subnets)     │  │  ✅ Patching Oracle software  │
│  ✅ Billing i kosztorysowanie      │  │  ✅ Backup management         │
│  ✅ Azure Monitor integracja       │  │  ✅ Data Guard konfiguracja   │
│  ✅ IAM (Entra ID → OCI mapping)   │  │  ✅ VM Cluster management     │
│  ✅ Azure Policy compliance        │  │  ✅ Database monitoring (OCI) │
│  ✅ Resource tags                  │  │  ✅ PDB management            │
│                                    │  │  ✅ Performance Hub / AWR     │
│  Narzędzia:                        │  │                                │
│  • Azure Portal                    │  │  Narzędzia:                    │
│  • Azure CLI                       │  │  • OCI Console                 │
│  • ARM Templates                   │  │  • OCI CLI                     │
│  • Terraform azurerm provider      │  │  • Terraform oci provider      │
│                                    │  │  • SQL*Plus / SQLcl            │
└────────────────────────────────────┘  └────────────────────────────────┘
                 │                                      │
                 └───────────── Federacja ──────────────┘
                          Azure AD ↔ OCI IAM

9.2 Federacja tożsamości Azure AD (Entra ID) ↔︎ OCI

Konfiguracja automatyczna przy pierwszym wdrożeniu:

1. Azure AD (Entra ID) jest źródłem tożsamości (Identity Provider)
2. OCI IAM jest skonfigurowane z Azure AD jako federated IdP
3. Użytkownicy logują się Azure AD credentials do OCI Console

Mapowanie:
  Azure AD Group: "Oracle-DBAs"     →  OCI Group: "ExadataAdmins"
  Azure AD Group: "Oracle-Viewers"  →  OCI Group: "ExadataViewers"
  Azure AD Group: "Oracle-Network"  →  OCI Group: "NetworkAdmins"

9.3 RBAC — wymagane role Azure

Rola Azure	Opis	Kto potrzebuje
Oracle.Database/cloudExadataInfrastructures/*	Zarządzanie Exadata Infrastructure	Cloud Admin
Oracle.Database/cloudVmClusters/*	Zarządzanie VM Clusters	DBA
Oracle.Database/autonomousDatabases/*	Zarządzanie Autonomous DB	DBA
Microsoft.Network/virtualNetworks/subnets/join/action	Delegacja subnetu	Network Admin
Oracle.Database/*/read	Odczyt zasobów Oracle	Viewer

9.4 Zarządzanie użytkownikami bazy danych

<a href="#cb15-1"></a>-- Standardowe zarządzanie użytkownikami Oracle — bez zmian!
<a href="#cb15-2"></a>
<a href="#cb15-3"></a>-- Tworzenie użytkownika (identycznie jak on-premises)
<a href="#cb15-4"></a>CREATE USER app_user IDENTIFIED BY "SecureP@ss123"
<a href="#cb15-5"></a>  DEFAULT TABLESPACE app_data
<a href="#cb15-6"></a>  TEMPORARY TABLESPACE temp
<a href="#cb15-7"></a>  QUOTA UNLIMITED ON app_data;
<a href="#cb15-8"></a>
<a href="#cb15-9"></a>GRANT CONNECT, RESOURCE TO app_user;
<a href="#cb15-10"></a>GRANT SELECT ON schema1.table1 TO app_user;
<a href="#cb15-11"></a>
<a href="#cb15-12"></a>-- Użytkownicy z Azure AD authentication (opcjonalnie):
<a href="#cb15-13"></a>-- Oracle 23ai wspiera bezpośrednią autentykację przez Azure AD / Entra ID
<a href="#cb15-14"></a>CREATE USER "azure_user@company.com" IDENTIFIED GLOBALLY;
<a href="#cb15-15"></a>GRANT CONNECT TO "azure_user@company.com";

---

10. Storage i wydajność

10.1 ASM (Automatic Storage Management)

Oracle Database@Azure używa Oracle ASM do zarządzania storage. ASM jest prekonfigurowany na Exadata Storage Servers.

ASM Disk Groups (typowa konfiguracja):
═══════════════════════════════════════

+DATA       Normal Redundancy (2-way mirror)
            → Dane bazy, tablespace'y
            → Automatic rebalancing

+RECO       Normal Redundancy (2-way mirror)  
            → Redo logs
            → Archive logs
            → Fast Recovery Area
            → RMAN backupy lokalne

+SPARSE     (opcjonalnie)
            → Snapshot copy storage
            → Test/dev klony

10.2 Dostępna pojemność storage

Konfiguracja	Usable DATA (po mirror)	Usable RECO (po mirror)	Total Raw
Quarter Rack X9M	~38 TB Flash usable	~20 TB	205.6 TB raw
Half Rack X9M	~76 TB Flash usable	~40 TB	411.2 TB raw
Full Rack X9M	~152 TB Flash usable	~80 TB	822.4 TB raw

10.3 Skalowanie storage

Można dokupić dodatkowe storage servery (Exadata Storage Expansion):

Quarter Rack + 3 dodatkowe storage servers = "Quarter Rack Extended"
  Flash: 76.8 TB + 76.8 TB = 153.6 TB
  Disk:  128.8 TB + 128.8 TB = 257.6 TB

10.4 Tuning wydajności

Kluczowe parametry do optymalizacji na Exadata:

<a href="#cb18-1"></a>-- Parametry specyficzne dla Exadata (ustawiane per PDB lub CDB)
<a href="#cb18-2"></a>
<a href="#cb18-3"></a>-- Smart Scan offloading (domyślnie ON)
<a href="#cb18-4"></a>ALTER SYSTEM SET cell_offload_processing = TRUE;
<a href="#cb18-5"></a>
<a href="#cb18-6"></a>-- Smart Flash Cache
<a href="#cb18-7"></a>ALTER SYSTEM SET cell_flash_cache_max_size = 'AUTO';
<a href="#cb18-8"></a>
<a href="#cb18-9"></a>-- Parallel Query (Exadata optymalizowane)
<a href="#cb18-10"></a>ALTER SYSTEM SET parallel_degree_policy = 'AUTO';
<a href="#cb18-11"></a>
<a href="#cb18-12"></a>-- In-Memory na Exadata
<a href="#cb18-13"></a>ALTER SYSTEM SET inmemory_size = 32G; -- dostosuj do RAM
<a href="#cb18-14"></a>
<a href="#cb18-15"></a>-- Compression
<a href="#cb18-16"></a>-- Exadata HCC dostępne tylko na Exadata!
<a href="#cb18-17"></a>ALTER TABLE large_table MOVE COMPRESS FOR QUERY HIGH;
<a href="#cb18-18"></a>-- lub
<a href="#cb18-19"></a>ALTER TABLE archive_table MOVE COMPRESS FOR ARCHIVE HIGH;

---

11. Wysoka dostępność i Disaster Recovery

11.1 Architektura HA na DB@Azure

WARSTWA 1: Oracle RAC (Local HA)
═════════════════════════════════
  - Ochrona przed: awarią pojedynczego DB servera
  - Failover: automatyczny, <30 sekund
  - Brak utraty danych

  ┌─────────────┐    ┌─────────────┐
  │ RAC Node 1  │◀──▶│ RAC Node 2  │
  │ (DB Server) │    │ (DB Server) │
  │ AZ: auto    │    │ AZ: auto    │
  └──────┬──────┘    └──────┬──────┘
         └──────┬───────────┘
                │
         Exadata Storage
         (ASM mirroring)


WARSTWA 2: Data Guard (Cross-AZ / Cross-Region DR)
════════════════════════════════════════════════════
  - Ochrona przed: awarią całej infrastruktury Exadata / regionu
  - Failover: automatyczny (Fast-Start Failover) lub ręczny
  - RPO: 0 (sync) lub near-zero (async)

  Azure Region 1 (West Europe)      Azure Region 2 (North Europe)
  ┌──────────────────────────┐      ┌──────────────────────────┐
  │ Exadata DB@Azure         │      │ Exadata DB@Azure         │
  │ ┌──────────────────────┐ │      │ ┌──────────────────────┐ │
  │ │ PRIMARY              │ │ DG   │ │ STANDBY              │ │
  │ │ RAC (2-node)         │─┼──────┼▶│ RAC (2-node)        │ │
  │ │                      │ │Sync  │ │                      │ │
  │ │ Read-Write           │ │ or   │ │ Read-Only (Active DG)│ │
  │ └──────────────────────┘ │ Async│ └──────────────────────┘ │
  └──────────────────────────┘      └──────────────────────────┘

  RPO / RTO:
  ┌────────────────────────────────────────────────────┐
  │ Synchronous Mode:  RPO = 0,     RTO = <30 sec      │
  │ Async Mode:        RPO = <1 sec, RTO = <60 sec     │
  │ Far Sync:          RPO = 0,     RTO = <60 sec      │
  │                    (long distance)                 │
  └────────────────────────────────────────────────────┘


WARSTWA 3: Backup (Point-in-Time Recovery)
══════════════════════════════════════════
  - Ochrona przed: logical corruption, human error
  - Recovery Point: do 60 dni wstecz (konfigurowalnie)
  - RMAN + OCI Object Storage (automatyczne)

11.2 SLA

Konfiguracja	SLA Uptime
Exadata DB Service (single VM Cluster, no RAC)	99.9%
Exadata DB Service (RAC, 2+ nodes)	99.99%
Exadata DB Service (RAC + Data Guard cross-region)	99.995%
Autonomous Database	99.995%

11.3 Data Guard — konfiguracja krok po kroku na DB@Azure

Krok 1: Provisioning Primary (już istnieje)
  - Exadata Infra w Region 1
  - VM Cluster + CDB + PDB

Krok 2: Provisioning Standby Infrastructure
  - Exadata Infra w Region 2 (lub ten sam region, inna AZ)
  - VM Cluster (bez bazy — Data Guard ją utworzy)

Krok 3: Enable Data Guard (OCI Console)
  - Wybierz Primary Database
  - Kliknij "Enable Data Guard"
  - Wybierz target region / infra
  - Skonfiguruj protection mode:
    • Maximum Protection (sync, zero data loss)
    • Maximum Availability (sync + async fallback)
    • Maximum Performance (async, near-zero data loss)

Krok 4: Automatyczna konfiguracja
  - OCI automatycznie tworzy standby bazę
  - Konfiguruje redo transport
  - Uruchamia apply process
  - Konfiguruje Fast-Start Failover (opcjonalnie)

Krok 5: Monitorowanie
  - OCI Console → Data Guard status
  - Transport lag, Apply lag
  - Alerts na lag > threshold

11.4 Porównanie HA z on-premises

Aspekt	On-Premises	DB@Azure
RAC setup	Ręczna konfiguracja (tygodnie)	Automatyczny provisioning (godziny)
Data Guard setup	Ręczna konfiguracja (dni)	Kliknięcie “Enable Data Guard” (godziny)
Failover	Ręczny lub FSFO (wymaga Observer)	Automatyczny FSFO (managed Observer)
Switchover	Ręczny (dgmgrl)	Z OCI Console (+ dgmgrl dostępne)
Storage redundancy	Zależy od hardware	ASM Normal/High Redundancy
Monitoring DG	OEM, custom scripts	OCI Console + alerts + OEM

---

12. Backup i odtwarzanie

12.1 Automatyczne backupy

Oracle Database@Azure zapewnia automatyczne backupy do OCI Object Storage:

Konfiguracja domyślna:
═════════════════════

Typ backupu           Częstotliwość          Retencja
─────────────        ─────────────          ────────
Full backup          Co tydzień (niedziela)  30 dni (konfigurowalny 1-60)
Incremental          Codziennie              30 dni
Archive log backup   Co 30-60 minut          30 dni

Lokalizacja:  OCI Object Storage (automatycznie, szyfrowane)
Koszt:        Wliczony w cenę (storage backup jest dodatkowy)

Customizacja:
  - Retencja: 1 do 60 dni
  - Okno backup: konfigurowalny czas startu
  - Auto-backup control file: TAK (automatyczny)

12.2 Własne backupy (RMAN)

Możesz również tworzyć własne backupy RMAN — masz pełny dostęp do RMAN na DB serverach:

<a href="#cb22-1"></a># SSH do DB Server
<a href="#cb22-2"></a>ssh opc@db-server-1
<a href="#cb22-3"></a>
<a href="#cb22-4"></a># RMAN manual backup
<a href="#cb22-5"></a>rman target /
<a href="#cb22-6"></a>
<a href="#cb22-7"></a>RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE
<a href="#cb22-8"></a>      PLUS ARCHIVELOG;
<a href="#cb22-9"></a>
<a href="#cb22-10"></a>RMAN> BACKUP AS COMPRESSED BACKUPSET 
<a href="#cb22-11"></a>      TABLESPACE app_data;
<a href="#cb22-12"></a>
<a href="#cb22-13"></a># Backup do OCI Object Storage (pre-konfigurowane)
<a href="#cb22-14"></a>RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt
<a href="#cb22-15"></a>      PARMS 'SBT_LIBRARY=/path/to/libopc.so';

12.3 Odtwarzanie (Recovery)

Scenariusze odtwarzania:
════════════════════════

1. Point-in-Time Recovery (PITR)
   OCI Console → Database → Restore → Select timestamp
   Lub: RMAN> RECOVER DATABASE UNTIL TIME '2026-03-10:14:30:00';

2. Restore pełnej bazy z backup
   OCI Console → Database → Restore → Select backup

3. Flashback Database (szybsze niż PITR)
   SQL> FLASHBACK DATABASE TO TIMESTAMP (SYSTIMESTAMP - INTERVAL '2' HOUR);

4. Flashback Table
   SQL> FLASHBACK TABLE app.orders TO TIMESTAMP 
        (SYSTIMESTAMP - INTERVAL '30' MINUTE);

5. Clone z backup (do testów)
   OCI Console → Database → Create Database from Backup
   → Nowa baza z wybranego punktu w czasie

---

13. Bezpieczeństwo i szyfrowanie

13.1 Szyfrowanie — warstwy

┌─────────────────────────────────────────────────────────────────┐
│                     MODEL BEZPIECZEŃSTWA                        │
│                                                                 │
│  WARSTWA 1: Szyfrowanie danych w spoczynku (Data at Rest)       │
│  ═════════════════════════════════════════════════════════      │
│  • TDE (Transparent Data Encryption) — WYMAGANE, domyślnie ON   │
│  • Szyfruje: tablespace'y, redo logs, backup                    │
│  • Algorytm: AES-256                                            │
│  • Klucze zarządzane przez:                                     │
│    ├─ OCI Vault (domyślnie)                                     │
│    ├─ Oracle Key Vault                                          │
│    └─ Customer-managed keys (BYOK)                              │
│                                                                 │
│  WARSTWA 2: Szyfrowanie w tranzycie (Data in Transit)           │
│  ═════════════════════════════════════════════════════          │
│  • Oracle Native Network Encryption (domyślnie ON)              │
│  • TLS 1.2/1.3 dla połączeń klienckich                          │
│  • mTLS (mutual TLS) dla Autonomous Database                    │
│  • InfiniBand fabric (wewnętrzny Exadata) — izolowany           │
│                                                                 │
│  WARSTWA 3: Sieciowa izolacja                                   │
│  ═══════════════════════════                                    │
│  • Delegated Subnet — izolacja na poziomie L2                   │
│  • NSG (Network Security Groups) — firewall rules               │
│  • Brak publicznego IP — dostęp tylko przez VNet                │
│  • Azure Private Link dla dodatkowych usług                     │
│                                                                 │
│  WARSTWA 4: Kontrola dostępu do bazy                            │
│  ═══════════════════════════════════                            │
│  • Oracle Database Vault — separation of duties                 │
│  • Virtual Private Database (VPD) — row-level security          │
│  • Label Security — classification-based access                 │
│  • Data Redaction — maskowanie danych w runtime                 │
│  • Privilege Analysis — identyfikacja nadmiarowych uprawnień    │
│                                                                 │
│  WARSTWA 5: Auditing                                            │
│  ═══════════════════                                            │
│  • Oracle Unified Auditing                                      │
│  • Fine-Grained Auditing (FGA)                                  │
│  • Azure Activity Log (operacje na infrastructure)              │
│  • OCI Audit Log (operacje na bazie)                            │
│                                                                 │
│  WARSTWA 6: Compliance                                          │
│  ══════════════════                                             │
│  • GDPR, ISO 27001, SOC 1/2/3, PCI DSS, HIPAA                   │
│  • Oracle Database Security Assessment Tool                     │
│  • Azure Policy integration                                     │
└─────────────────────────────────────────────────────────────────┘

13.2 Porównanie bezpieczeństwa z on-premises

Aspekt	On-Premises	DB@Azure	Komentarz
TDE	Opcjonalne	Wymagane	DB@Azure wymusza szyfrowanie — lepiej
Network encryption	Konfigurowane ręcznie	Domyślnie ON	Bezpieczniej out-of-the-box
Publiczny dostęp	Zależy od firewalla	Niemożliwy (private only)	Bezpieczniej
Patching security	Ręczne (opóźnienia)	Zarządzane przez Oracle	Szybsze security patches
Fizyczne bezpieczeństwo	Zależy od datacenter	Azure + Oracle datacenter security	Enterprise-grade
Backup encryption	Konfigurowane ręcznie	Automatyczne	Bezpieczniej

---

14. Monitorowanie i zarządzanie

14.1 Dostępne narzędzia monitorowania

┌─────────────────────────────────────────────────────────────────┐
│                    MONITORING STACK                             │
│                                                                 │
│  ┌───────────────────┐                                          │
│  │   Azure Monitor   │  ← Metryki infrastruktury Azure          │
│  │   + Log Analytics │  ← Logi operacyjne                       │
│  │   + Alerts        │  ← Alerty na metryki                     │
│  └────────┬──────────┘                                          │
│           │                                                     │
│  ┌────────┴──────────┐                                          │
│  │   OCI Monitoring  │  ← Metryki Exadata (CPU, IOPS, latency)  │
│  │   + Performance   │  ← Performance Hub (AWR, ASH, SQL Mon.)  │
│  │     Hub           │  ← Database management                   │
│  │   + Events        │  ← OCI Events & Notifications            │
│  └────────┬──────────┘                                          │
│           │                                                     │
│  ┌────────┴──────────┐                                          │
│  │   Oracle OEM      │  ← Opcjonalny Oracle Enterprise Manager  │
│  │   Cloud Control   │  ← Pełne zarządzanie DB (tradycyjne)     │
│  │   (self-managed)  │  ← Agent na DB serverach                 │
│  └────────┬──────────┘                                          │
│           │                                                     │
│  ┌────────┴──────────┐                                          │
│  │   Third-party     │  ← Datadog, Grafana, Dynatrace           │
│  │   monitoring      │  ← Przez Oracle metrics/AWR exports      │
│  └───────────────────┘                                          │
└─────────────────────────────────────────────────────────────────┘

14.2 Kluczowe metryki do monitorowania

Metryka	Źródło	Alert threshold (przykład)
CPU Utilization (%)	OCI Monitoring	> 85% przez 5 min
Storage Utilization (%)	OCI Monitoring	> 80%
IOPS	OCI Monitoring	> 90% max capacity
Memory Utilization (%)	OCI Monitoring / VSYSMETRIC| > 90|DataGuardLag(sec)|OCIConsole/VDATAGUARD_STATS	> 5 sec
Active Sessions	AWR / VSESSION| > 80|TablespaceUsage(|RedoLogSwitchFrequency|VLOG_HISTORY	> 10/hour
Wait Events	ASH / V$ACTIVE_SESSION_HISTORY	Top waits > threshold
Backup Status	OCI Console	Failed backup

14.3 Zarządzanie patchowaniem

Model patchowania na DB@Azure:
══════════════════════════════

1. INFRASTRUKTURA (Exadata firmware, OS, hypervisor)
   Kto: Oracle (automatycznie w maintenance window)
   Kiedy: Kwartalnie lub po critical security patch
   Downtime: Rolling update — zero downtime z RAC

2. ORACLE DATABASE SOFTWARE (quarterly patches — PSU/RU)
   Kto: KLIENT (inicjuje z OCI Console)
   Kiedy: Klient decyduje (zalecane kwartalnie)
   Proces:
     a) Oracle publikuje nowy patch (np. 19.25 RU)
     b) Klient testuje na non-prod
     c) Klient aplikuje na prod z OCI Console
     d) Rolling patch — zero downtime z RAC (w większości przypadków)

   OCI Console → VM Cluster → Patch → Select version → Apply

3. ONE-OFF PATCHES (hotfixy)
   Kto: KLIENT (SSH + opatch)
   Kiedy: Gdy wymagany konkretny hotfix
   Proces:
     a) SSH do DB server
     b) opatch apply <patch_number>
     c) Restart instancji (rolling z RAC)

---

15. Licencjonowanie

15.1 Modele licencyjne

Model	Opis	Kiedy wybrać
BYOL (Bring Your Own License)	Używasz istniejących licencji Oracle	Masz aktywne licencje Oracle EE z Support
License Included (LI)	Licencja wliczona w cenę usługi	Nie masz licencji Oracle lub chcesz uproszczenie

15.2 BYOL — szczegóły

Przelicznik licencji na DB@Azure:
═════════════════════════════════

1 Oracle Processor License = 2 OCPU na Exadata

Przykład:
  VM Cluster z 32 OCPU → potrzebujesz 16 Oracle Processor Licenses
  VM Cluster z 64 OCPU → potrzebujesz 32 Oracle Processor Licenses

Wymagane licencje:
  ✅ Oracle Database Enterprise Edition (base)

  Plus (jeśli używane):
  ✅ Oracle RAC (wliczone w EE — nie potrzeba oddzielnej licencji!)
  ✅ Partitioning Option
  ✅ Advanced Compression
  ✅ Advanced Security (TDE — wymagane na DB@Azure)
  ✅ Database Vault
  ✅ In-Memory
  ✅ Spatial and Graph
  ✅ OLAP
  ✅ Real Application Testing
  ✅ Active Data Guard
  ✅ GoldenGate
  ✅ inne Oracle Options

15.3 License Included — co jest wliczone

W modelu License Included (LI) na DB@Azure, cena zawiera:

Wliczone w LI:
  ✅ Oracle Database Enterprise Edition
  ✅ Oracle RAC
  ✅ Partitioning
  ✅ Advanced Compression
  ✅ Advanced Security (TDE)
  ✅ Database Vault
  ✅ Label Security
  ✅ OLAP
  ✅ Spatial and Graph
  ✅ Oracle Machine Learning

  ❌ NIE wliczone (oddzielna licencja):
  ❌ Oracle GoldenGate
  ❌ Active Data Guard (standby wymaga osobnej licencji LI lub BYOL)
  ❌ In-Memory (osobna opcja)
  ❌ Real Application Testing
  ❌ Advanced Analytics
  ❌ Oracle Multitenant (>3 PDB wymaga Enterprise + Multitenant option)

15.4 Porównanie kosztów BYOL vs LI

Model	Koszt OCPU/miesiąc (approx.)	Dla 32 OCPU/mies.	Uwagi
BYOL	~$0.30/OCPU/godz. = ~$220/OCPU/mies.	~$7,040	+ istniejąca licencja + Support
License Included	~$0.70/OCPU/godz. = ~$510/OCPU/mies.	~$16,320	Wszystko wliczone

15.5 Rekomendacja

Mam istniejące licencje Oracle EE z aktywnym Support?
  ├─ TAK → Użyj BYOL (znaczne oszczędności)
  │        Oszczędność: ~57% na compute vs License Included
  │
  └─ NIE → 
      ├─ Potrzebuję Oracle (bez alternatywy)?
      │   └─ TAK → License Included (prostsze, all-in-one)
      │
      └─ Mogę rozważyć alternatywy?
          └─ TAK → Rozważ PostgreSQL/Azure SQL (brak licencji Oracle)

---

16. Ograniczenia i różnice vs on-premises

16.1 Ograniczenia DB@Azure

Ograniczenie	Szczegóły	Obejście
Tylko Enterprise Edition	SE2/XE niedostępne	Oracle na Azure VM (SE2), lub PostgreSQL
Wymagane TDE	Szyfrowanie musi być włączone	Nie jest to problem — lepsze bezpieczeństwo
Minimalna konfiguracja: Quarter Rack	Nie można zamówić “jednego serwera”	Ale OCPU skalowane od 2 OCPU/node
Dostępność regionalna	Nie wszystkie Azure regiony	Sprawdź aktualne regiony (sekcja 19)
Dual management console	Azure Portal + OCI Console	Terraform do ujednolicenia
Provisioning time	Exadata Infrastructure: 2-5 godzin	Zaplanuj z wyprzedzeniem
Limited Standard VM flexibility	Nie wybierasz typu VM jak w IaaS	Exadata to specjalizowany hardware
OS patching schedule	Oracle zarządza infrastrukturą OS/firmware	Masz input na maintenance window
Student/dev tier	Brak darmowego tier jak w OCI	OCI Free Tier dla dev, DB@Azure od Quarter Rack
Network egress	Ruch do internetu przez Azure (opłaty Azure)	Standardowe opłaty Azure egress

16.2 Różnice operacyjne vs on-premises

Aspekt	On-Premises	DB@Azure	Lepiej w…
Czas provisioning nowej bazy	Tygodnie (HW + instalacja)	Godziny	DB@Azure
Patching OS/firmware	Klient (ryzyko, czas)	Oracle (automatyczne, rolling)	DB@Azure
Wymiana dysków	Klient + vendor (SLA)	Oracle (automatyczne)	DB@Azure
Skalowanie compute	Zamówienie nowego HW (tygodnie)	Online w minutach (OCPU)	DB@Azure
Dostęp SSH do OS	Pełny root	opc user (sudo, ale managed OS)	On-Premises
Custom OS packages	Pełna swoboda	Ograniczone (managed OS)	On-Premises
Network konfiguracja	Pełna kontrola	Azure VNet + delegacja	On-Premises
Backup offsite	Wymaga konfiguracji	Automatyczny do OCI Object Storage	DB@Azure
Security patching	Klient (opóźnienia)	Oracle (szybko po wydaniu)	DB@Azure
Audyt fizycznego dostępu	Klient datacenter	Azure + Oracle datacenter (certified)	DB@Azure

16.3 Co jest LEPSZE na DB@Azure niż on-premises

Migracja do DB@Azure może przynieść ulepszenia w stosunku do obecnego środowiska:

1. Exadata performance — Jeśli on-premises nie jest Exadata, zyskujesz Smart Scan, HCC, Flash Cache
2. Automatyczne backupy — Nie musisz zarządzać tape library / NFS backupami
3. Szybsze provisioning nowych środowisk — Dev/Test w godzinach zamiast tygodni
4. Elastyczne skalowanie — Dodanie/usunięcie OCPUs bez downtime
5. Bezpieczeństwo out-of-the-box — TDE wymagane, network encryption domyślnie
6. Integracja z Azure — Natywna łączność z AKS, App Service, Azure AD
7. Unified billing — Jedno rozliczenie Azure
8. Joint support — Jeden ticket do Oracle + Microsoft
9. Szybsze security patching — Oracle aplikuje patche na infrastrukturę
10. Cross-region DR — Łatwiejsze Data Guard niż budowa drugiego datacenter

---

17. Scenariusze migracji krok po kroku

17.1 Scenariusz 1: Migracja z on-premises Oracle (non-Exadata) do DB@Azure

Typowy przypadek: Oracle 19c na VMware/fizycznym serwerze → DB@Azure Exadata

FAZA 1: PRZYGOTOWANIE (Tydzień 1-3)
═══════════════════════════════════

Dzień 1-5: Azure/OCI Setup
  ├─ Aktywacja Oracle Database@Azure w subskrypcji Azure
  │  (Azure Portal → Marketplace → Oracle Database@Azure → Enable)
  ├─ Utworzenie OCI Tenancy (automatyczne przy aktywacji)
  ├─ Konfiguracja Entra ID ↔ OCI IAM federacji
  └─ Mapowanie grup Azure AD do ról OCI

Dzień 5-10: Networking
  ├─ Azure VNet: 10.0.0.0/16
  ├─ Subnet Application: 10.0.1.0/24
  ├─ Subnet Oracle (delegated): 10.0.10.0/24
  ├─ Subnet Management: 10.0.3.0/24
  ├─ ExpressRoute/VPN do on-premises (jeśli nie istnieje)
  └─ NSG rules: Allow 1521 from app subnet to oracle subnet

Dzień 10-15: Exadata Provisioning
  ├─ Azure Portal → Create Exadata Infrastructure
  │  ├─ Subscription: <twoja>
  │  ├─ Resource Group: rg-oracle-prod
  │  ├─ Region: West Europe
  │  ├─ Shape: Exadata.Quarter3.100 (X9M Quarter Rack)
  │  └─ Maintenance Window: Sunday 02:00-06:00
  │
  ├─ [Czekaj 2-5h na provisioning infrastruktury]
  │
  ├─ Create VM Cluster
  │  ├─ Exadata Infrastructure: <powyższa>
  │  ├─ VNet/Subnet: 10.0.10.0/24 (delegated)
  │  ├─ SSH Public Key: <twój klucz>
  │  ├─ Oracle Grid Infrastructure version: 19c
  │  ├─ DB Servers: 2 (RAC 2-node)
  │  ├─ OCPU per node: 16 (możesz later skalować)
  │  ├─ Memory per node: 256 GB (prop. do OCPU)
  │  └─ License Model: BYOL lub License Included
  │
  └─ Create Database
     ├─ VM Cluster: <powyższy>
     ├─ DB Name: APPDB
     ├─ PDB Name: APPDB_PDB1
     ├─ DB Version: 19c (19.22 lub najnowszy RU)
     ├─ DB Workload Type: OLTP
     ├─ Admin Password: <strong password>
     ├─ TDE: Enabled (wymagane)
     ├─ Automatic Backup: Enabled
     └─ Backup Retention: 30 days


FAZA 2: MIGRACJA DANYCH (Tydzień 3-6)
═════════════════════════════════════

Opcja A: Oracle Data Guard (REKOMENDOWANE — zero downtime)
──────────────────────────────────────────────────────────
  Wymagania: Oracle 19c source, Enterprise Edition, Archivelog ON

  Krok 1: Na źródle (on-premises) — włącz Force Logging
    SQL> ALTER DATABASE FORCE LOGGING;
    SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=dbazure_stby
         ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
         DB_UNIQUE_NAME=dbazure';
    SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
    SQL> ALTER SYSTEM SET FAL_SERVER='dbazure_stby';

  Krok 2: Na DB@Azure — przygotowanie jako standby
    # SSH do DB server
    ssh opc@db-server-1

    # Duplicate z RMAN (przez sieć)
    rman target sys/password@source_primary \
         auxiliary sys/password@dbazure_stby

    RMAN> DUPLICATE TARGET DATABASE FOR STANDBY
          FROM ACTIVE DATABASE
          DORECOVER
          NOFILENAMECHECK;

  Krok 3: Weryfikacja synchronizacji
    SQL> SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST 
         WHERE DEST_ID = 2;

    SQL> SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG 
         WHERE APPLIED = 'YES' ORDER BY SEQUENCE# DESC FETCH FIRST 5 ROWS ONLY;

  Krok 4: Monitorowanie (dni/tygodnie — zależy od planu cutover)
    SQL> SELECT NAME, VALUE, UNIT FROM V$DATAGUARD_STATS;
    -- transport lag: 0 seconds
    -- apply lag: 0 seconds


Opcja B: Oracle Zero Downtime Migration (ZDM)
──────────────────────────────────────────────
  # Na ZDM host (osobna VM):
  zdmcli migrate database \
    -sourcesid APPDB \
    -sourcenode on-prem-host \
    -srcauth zdmauth \
    -srcarg1 user:oracle \
    -srcarg2 identity_file:/home/zdm/.ssh/id_rsa \
    -targetnode db-server-1.oraclevcn.com \
    -tgtauth zdmauth \
    -tgtarg1 user:opc \
    -tgtarg2 identity_file:/home/zdm/.ssh/id_rsa \
    -rsp /path/to/response_file.rsp \
    -eval  # Najpierw ewaluacja!

  # Po udanej ewaluacji:
  zdmcli migrate database ... (bez -eval)


Opcja C: Data Pump (offline — prostsza, ale z downtime)
───────────────────────────────────────────────────────
  # Na źródle:
  expdp system/password@source \
    DIRECTORY=DATA_PUMP_DIR \
    DUMPFILE=full_%U.dmp \
    FILESIZE=10G \
    PARALLEL=8 \
    FULL=Y \
    COMPRESSION=ALL

  # Transfer dump files do DB@Azure (scp / Azure Blob / OCI Object Storage)
  scp full_*.dmp opc@db-server-1:/tmp/dumps/

  # Na DB@Azure:
  impdp system/password@dbazure \
    DIRECTORY=DATA_PUMP_DIR \
    DUMPFILE=full_%U.dmp \
    PARALLEL=8 \
    FULL=Y


FAZA 3: WALIDACJA (Tydzień 6-8)
═══════════════════════════════

  1. Row count validation
     -- Na źródle i celu: porównanie count(*) per tabela

  2. Data checksum validation
     -- Na źródle i celu: ORA_HASH porównanie

  3. Testy aplikacyjne
     -- Zmiana connection string na DB@Azure endpoint
     -- Uruchomienie test suite
     -- Smoke test kluczowych operacji

  4. Performance baseline
     -- AWR report na DB@Azure
     -- Porównanie z on-premises AWR
     -- Exadata Smart Scan powinien pokazać poprawę!

  5. HA testy
     -- RAC node failure test
     -- Data Guard switchover test
     -- Backup/restore test


FAZA 4: CUTOVER (Weekend migracyjny)
════════════════════════════════════

  Opcja A (Data Guard — zalecane):
  ────────────────────────────────
  T+00:00  Announcement: Maintenance window start
  T+00:15  Weryfikacja Data Guard lag = 0
  T+00:20  SWITCHOVER:
           # Na primary (on-prem):
           DGMGRL> SWITCHOVER TO dbazure;
           # Lub z OCI Console: Database → Data Guard → Switchover
  T+00:25  Weryfikacja: DB@Azure = PRIMARY, on-prem = STANDBY
  T+00:30  Zmiana DNS / connection string w aplikacjach
  T+00:45  Restart aplikacji
  T+01:00  Smoke test
  T+01:30  Full regression test
  T+02:00  Go/No-Go decision
  T+02:15  Ogłoszenie zakończenia maintenance
  T+02:30  Monitoring — zespół w gotowości

  Rollback (jeśli potrzebny):
  ──────────────────────────
  # Switchover z powrotem:
  DGMGRL> SWITCHOVER TO onprem_db;
  # Zmiana connection string na on-premises
  # Restart aplikacji
  # Czas rollback: ~15 minut

  Opcja B (Data Pump — offline):
  ──────────────────────────────
  T+00:00  Zatrzymanie aplikacji
  T+00:30  Final incremental export (tabele zmienione od ostatniego dump)
  T+02:00  Import incremental na DB@Azure
  T+04:00  Walidacja
  T+04:30  Zmiana connection string
  T+05:00  Restart aplikacji
  T+05:30  Testy
  T+06:00  Go/No-Go


FAZA 5: POST-MIGRATION (Tydzień 8-12)
════════════════════════════════════

  Tydzień 1: Wzmożone monitorowanie 24/7
  Tydzień 2: Normalne monitorowanie, tuning wydajności
  Tydzień 3: Konfiguracja Data Guard cross-region (DR)
  Tydzień 4: Decommission on-premises (po potwierdzeniu stabilności)
    ├─ Zatrzymanie Data Guard replikacji
    ├─ Shutdown starej bazy
    ├─ Archiwizacja backup on-premises (na wszelki wypadek)
    └─ Zwolnienie hardware

17.2 Scenariusz 2: Migracja z istniejącego Exadata on-premises do DB@Azure

Typowy przypadek: Exadata on-premises → DB@Azure Exadata (najbardziej bezpośrednia ścieżka)

To jest NAJPROSTSZA migracja, ponieważ:
  • Ten sam hardware (Exadata → Exadata)
  • Ten sam software (Oracle DB → Oracle DB)
  • Te same features (Smart Scan, HCC, RAC → identyczne)
  • ASM → ASM (nic się nie zmienia)

Metoda: Data Guard Switchover (zero downtime)

  1. Provisioning DB@Azure (Exadata, taki sam lub większy shape)
  2. Data Guard: On-prem Exadata (primary) → DB@Azure (standby)
  3. Synchronizacja (czas zależny od rozmiaru i bandwidth)
  4. Switchover (sekundy downtime)
  5. Gotowe!

UWAGA: Exadata HCC dane zostaną zachowane — nie trzeba re-kompresować!

17.3 Scenariusz 3: Migracja wielu baz danych (konsolidacja)

Obecne środowisko on-premises:
  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
  │ Server 1     │  │ Server 2     │  │ Server 3     │
  │ Oracle 19c   │  │ Oracle 19c   │  │ Oracle 12c   │
  │ DB: HR       │  │ DB: FINANCE  │  │ DB: ARCHIVE  │
  │ 500 GB       │  │ 2 TB         │  │ 5 TB         │
  └──────────────┘  └──────────────┘  └──────────────┘

Docelowe środowisko DB@Azure (konsolidacja na jednym Exadata):
  ┌────────────────────────────────────────────────────────────┐
  │ Exadata Quarter Rack X9M                                   │
  │ VM Cluster: PROD (64 OCPU, 2 RAC nodes)                    │
  │                                                            │
  │ CDB: CONSDB                                                │
  │ ┌──────────┐  ┌──────────────┐  ┌────────────┐             │
  │ │ PDB: HR  │  │ PDB: FINANCE │  │ PDB: ARCH  │             │
  │ │ 500 GB   │  │ 2 TB         │  │ 5 TB (HCC) │             │
  │ └──────────┘  └──────────────┘  └────────────┘             │
  │                                                            │
  │ Resource Manager:                                          │
  │   HR: 20% CPU guaranteed                                   │
  │   FINANCE: 50% CPU guaranteed                              │
  │   ARCHIVE: 10% CPU guaranteed                              │
  │   Remainder: shared                                        │
  └────────────────────────────────────────────────────────────┘

Kroki:
  1. Provisioning DB@Azure z jednym CDB
  2. Dla każdej bazy źródłowej:
     a) Data Pump export (lub Data Guard per baza)
     b) Import do nowej PDB
     c) Walidacja
  3. Upgrade 12c→19c (jeśli potrzebny, przy Data Pump Import)
  4. Konfiguracja Resource Manager (izolacja CPU/memory per PDB)
  5. Cutover (po kolei per baza lub wszystkie naraz)

Oszczędności konsolidacji:
  Przed: 3 serwery × licencja = 3× koszt
  Po: 1 Exadata (shared) = mniejszy koszt licencyjny (BYOL)
      + Exadata performance
      + Centralne zarządzanie

---

18. Koszty

18.1 Składniki kosztów DB@Azure

Koszt całkowity = Exadata Infrastructure + Compute (OCPU) + Storage + Backup + Network

1. EXADATA INFRASTRUCTURE (stały koszt miesięczny)
   Quarter Rack X9M:  ~$12,000 - $18,000/mies.
   Half Rack X9M:     ~$24,000 - $36,000/mies.
   Full Rack X9M:     ~$48,000 - $72,000/mies.

2. COMPUTE / OCPU (zmienny — płacisz za aktywne OCPUs)
   BYOL:              ~$0.30/OCPU/godz.  (~$220/OCPU/mies.)
   License Included:  ~$0.70/OCPU/godz.  (~$510/OCPU/mies.)

3. STORAGE (Exadata)
   Wliczony w Exadata Infrastructure cost
   Dodatkowy storage expansion: ~$1,200/TB/mies.

4. BACKUP (OCI Object Storage)
   ~$0.0255/GB/mies. (Object Storage Standard)
   Retencja 30 dni, 5 TB baza ≈ ~$130-250/mies.

5. NETWORK (Azure egress)
   Wewnątrz VNet: $0 (darmowe)
   Do internetu: Standardowe Azure egress pricing
   ExpressRoute: Zależy od planu

18.2 Przykładowe scenariusze kosztowe

Scenariusz	Konfiguracja	BYOL/mies.	LI/mies.
Mała baza (2 TB, 16 OCPU)	Quarter Rack, 1 VM Cluster 16 OCPU	~$15,500	~$20,200
Średnia baza (10 TB, 48 OCPU)	Quarter Rack, 1 VM Cluster 48 OCPU	~$22,600	~$36,500
Duża baza (50 TB, 100 OCPU)	Half Rack, 1 VM Cluster 100 OCPU	~$46,000	~$75,000
Enterprise Critical (100 TB, 200 OCPU + DR)	Full Rack × 2 (primary + DR)	~$110,000	~$175,000

18.3 Porównanie z on-premises Exadata

On-Premises Exadata Quarter Rack:
═════════════════════════════════
  CAPEX (zakup hardware):     ~$400,000 - $600,000  (jednorazowo)
  Amortyzacja (5 lat):        ~$6,700 - $10,000/mies.
  Oracle Support:             ~$80,000 - $120,000/rok = $6,700-$10,000/mies.
  Datacenter (power, cooling): ~$2,000 - $4,000/mies.
  DBA/Admin (patching, HW):   ~$5,000 - $10,000/mies.
  ──────────────────────────────────────────────────
  TOTAL (amortyzacja 5 lat):  ~$21,000 - $34,000/mies.

DB@Azure Quarter Rack (BYOL):
═════════════════════════════
  Infrastructure:              ~$15,000/mies.
  Compute (32 OCPU BYOL):     ~$7,000/mies.
  Backup storage:              ~$200/mies.
  ──────────────────────────────────────────────────
  TOTAL:                       ~$22,200/mies.

  Plus: istniejąca licencja Oracle (BYOL — już opłacona)
  Plus: Oracle Support (już płatne): ~$6,700-$10,000/mies.

PORÓWNANIE:
  On-prem total TCO:  ~$21,000 - $34,000/mies.
  DB@Azure BYOL:      ~$22,200 + support = ~$29,000 - $32,200/mies.

  Różnica: Zbliżony koszt, ale DB@Azure oferuje:
  ✅ Brak CAPEX (zero inwestycji początkowej)
  ✅ Elastyczne skalowanie
  ✅ Zarządzany hardware
  ✅ Integracja z Azure
  ✅ Automatyczne backupy
  ✅ Szybszy DR (cross-region Data Guard)

---

19. Regiony i dostępność

19.1 Dostępne regiony Oracle Database@Azure (stan na 2026)

Azure Region	Status	Usługi
East US	✅ GA	Exadata DB Service, Autonomous DB
West US 2	✅ GA	Exadata DB Service, Autonomous DB
Central US	✅ GA	Exadata DB Service
West Europe (Amsterdam)	✅ GA	Exadata DB Service, Autonomous DB
UK South (London)	✅ GA	Exadata DB Service, Autonomous DB
Germany West Central (Frankfurt)	✅ GA	Exadata DB Service, Autonomous DB
France Central (Paris)	✅ GA	Exadata DB Service
Canada Central (Toronto)	✅ GA	Exadata DB Service, Autonomous DB
Southeast Asia (Singapore)	✅ GA	Exadata DB Service
Japan East (Tokyo)	✅ GA	Exadata DB Service
Australia East (Sydney)	✅ GA	Exadata DB Service, Autonomous DB
Brazil South (São Paulo)	✅ GA	Exadata DB Service
South Central US	✅ GA	Exadata DB Service
North Europe (Dublin)	✅ GA	Exadata DB Service
Inne regiony	🔜 Planowane	Sprawdź docs.oracle.com

Uwaga: Lista regionów jest dynamiczna. Oracle i Microsoft ciągle rozszerzają dostępność. Sprawdź aktualne regiony na docs.oracle.com lub w Azure Portal.

19.2 Disaster Recovery — pary regionów

Primary Region	DR Region	Latency
West Europe	North Europe	~15ms
East US	West US 2	~60ms
UK South	UK West (lub West Europe)	~5ms
Germany West Central	France Central	~10ms
Canada Central	Canada East (lub East US)	~20ms

---

20. FAQ — najczęstsze pytania

Q1: Czy moje istniejące połączenia JDBC/OCI będą działać?

Tak. Wystarczy zmienić connection string (host/port/service_name). Sterownik JDBC (ojdbc), OCI, ODBC — wszystkie działają identycznie. Nie ma żadnej zmiany w protokole Oracle Net.

<a href="#cb35-1"></a>// Przed (on-premises):
<a href="#cb35-2"></a>String url = "jdbc:oracle:thin:@//onprem-host:1521/APPDB";
<a href="#cb35-3"></a>
<a href="#cb35-4"></a>// Po (DB@Azure):
<a href="#cb35-5"></a>String url = "jdbc:oracle:thin:@//scan-hostname.oraclevcn.com:1521/APPDB_PDB1";

Q2: Czy mogę użyć Oracle RAC na DB@Azure?

Tak. Oracle RAC jest natywnie wspierany na Exadata. To ten sam RAC co on-premises — z tymi samymi możliwościami (Cache Fusion, Global Cache, Services, etc.).

Q3: Czy moje PL/SQL pakiety będą działać bez zmian?

Tak — 100%. PL/SQL engine jest identyczny. Nie musisz zmieniać ani jednej linijki kodu PL/SQL. Pakiety, procedury, funkcje, triggery, typy — wszystko działa tak samo.

Q4: Czy mogę migrować z Oracle 11g / 12c?

Tak, ale z upgrade’em. DB@Azure wspiera Oracle 19c i 23ai. Musisz upgrade’ować do jednej z tych wersji. Możesz to zrobić: – Przed migracją (upgrade on-premises → potem Data Guard do DB@Azure) – W trakcie migracji (Data Pump export z 12c → import do 19c na DB@Azure) – Przez ZDM (obsługuje upgrade + migrację w jednym procesie)

Q5: Czy muszę mieć Multitenant (CDB/PDB)?

Tak. DB@Azure wymaga architektury CDB/PDB. Jeśli Twoja baza jest non-CDB, musisz ją najpierw skonwertować:

<a href="#cb36-1"></a>-- Oracle 19c: Non-CDB to PDB conversion
<a href="#cb36-2"></a>-- Krok 1: Describe non-CDB as PDB
<a href="#cb36-3"></a>EXEC DBMS_PDB.DESCRIBE('/tmp/ncdb.xml');
<a href="#cb36-4"></a>-- Krok 2: Plugin do CDB
<a href="#cb36-5"></a>CREATE PLUGGABLE DATABASE pdb_from_noncdb USING '/tmp/ncdb.xml' COPY;
<a href="#cb36-6"></a>ALTER PLUGGABLE DATABASE pdb_from_noncdb OPEN;
<a href="#cb36-7"></a>-- Krok 3: Convert
<a href="#cb36-8"></a>@$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql

Q6: Czy mogę mieć dostęp SSH do serwerów bazy danych?

Tak (dla Exadata DB Service). Masz dostęp SSH jako użytkownik opc z sudo. Możesz: – Uruchamiać RMAN, SQL*Plus, adrci, opatch – Przeglądać logi (alert log, trace files, listener log) – Instalować one-off patches – Uruchamiać custom scripts

Nie (dla Autonomous Database) — brak dostępu SSH.

Q7: Czy Oracle Enterprise Manager (OEM) będzie działał?

Tak. Możesz zainstalować OEM Cloud Control na osobnej Azure VM i dodać DB@Azure jako managed targets. Agent OEM instalujesz na DB serverach przez SSH.

Q8: Czy mogę używać Oracle GoldenGate z DB@Azure?

Tak. DB@Azure może być zarówno źródłem jak i celem GoldenGate. Możesz: – Replikować z on-premises do DB@Azure (migracja) – Replikować z DB@Azure do innej bazy (integracja) – Bidirectional replication (active-active)

Q9: Co z Application Express (APEX)?

APEX jest preinstalowany na DB@Azure. Możesz uruchomić swoje aplikacje APEX bez dodatkowej konfiguracji.

Q10: Czy mogę mieć wiele baz danych na jednym Exadata?

Tak! Na jednym Exadata możesz: – Utworzyć wiele VM Clusters (np. PROD, DEV, TEST) – Każdy VM Cluster może mieć wiele CDB – Każda CDB może mieć wiele PDB – Izolacja zasobów przez Resource Manager

Q11: Czy mogę łatwo wrócić do on-premises jeśli coś pójdzie nie tak?

Tak. Jeśli używasz Data Guard do migracji, na on-premises pozostaje standby baza. W każdej chwili możesz wykonać switchover z powrotem. Czas rollback: ~15-30 minut.

Q12: Czy moje backupy RMAN z on-premises mogę przywrócić na DB@Azure?

Tak. Możesz przenieść RMAN backupy do OCI Object Storage i wykonać restore na DB@Azure. To jest jedna z metod migracji danych.

Q13: Czy Standard Edition 2 jest wspierane?

Nie. Oracle Database@Azure jest dostępne wyłącznie dla Enterprise Edition. Jeśli masz SE2, opcje to: – Oracle na Azure VM (SE2 na IaaS) — Lift & Shift – Migracja do PostgreSQL (eliminacja licencji) – Upgrade do Enterprise Edition + DB@Azure

Q14: Jak wygląda patching bazy danych?

Klient kontroluje kiedy patchować bazę Oracle (RU — Release Update): 1. Oracle publikuje nowy RU (np. 19.25) 2. Testujesz na non-prod DB@Azure 3. Aplikujesz na prod z OCI Console 4. Rolling patch z RAC — zero downtime (w większości przypadków)

Q15: Czy dane opuszczają Azure datacenter?

Nie (domyślnie). Dane bazy danych znajdują się fizycznie w Azure datacenter. Backup domyślnie trafia do OCI Object Storage w tym samym regionie (który jest w tym samym lub powiązanym datacenter). Dane nie opuszczają regionu geograficznego, chyba że skonfigurujesz cross-region DR.

---

21. Podsumowanie — czy pełna migracja jest możliwa?

Jednoznaczna odpowiedź

╔══════════════════════════════════════════════════════════════════════╗
║                                                                      ║
║  TAK — pełna migracja istniejącego środowiska Oracle do              ║
║  Oracle Database@Azure jest możliwa w ~99.5% przypadków.             ║
║                                                                      ║
║  Oracle Database@Azure uruchamia IDENTYCZNY silnik Oracle Database   ║
║  na IDENTYCZNYM hardware Exadata. Twój kod PL/SQL, schemat,          ║
║  dane, konfiguracja RAC, Data Guard, ASM — wszystko działa           ║
║  tak samo jak on-premises.                                           ║
║                                                                      ║
╚══════════════════════════════════════════════════════════════════════╝

Warunki pełnej migracji

Warunek	Spełniony?	Co jeśli nie?
Oracle Enterprise Edition	Wymagane	Użyj Oracle na Azure VM (SE2)
Oracle 19c lub 23ai	Wymagane	Upgrade z 11g/12c/18c/21c do 19c (wspierany)
CDB/PDB architektura	Wymagane	Konwersja non-CDB → PDB (prosta procedura)
TDE (szyfrowanie)	Wymagane	Włącz TDE przed lub w trakcie migracji
Dostępność regionu Azure	Wymagane	Sprawdź listę regionów (sekcja 19)
Łączność sieciowa	Wymagane	ExpressRoute / VPN do on-premises
Budżet na Exadata	Wymagane	Min. Quarter Rack (~$15,000-20,000/mies.)

Elementy wymagające pracy

Element	Nakład pracy	Ryzyko
Zmiana connection string w aplikacjach	Niski (godziny)	Niskie
Konfiguracja Azure networking (VNet, NSG)	Niski (dni)	Niskie
Transfer danych (Data Guard / Data Pump)	Średni (dni-tygodnie)	Niskie
Upgrade wersji Oracle (jeśli potrzebny)	Średni (tygodnie)	Średnie
Konwersja non-CDB do CDB (jeśli potrzebne)	Niski (dni)	Niskie
Migracja OS-level jobs do DBMS_SCHEDULER	Niski (dni)	Niskie
Adaptacja monitoringu	Niski-Średni (dni)	Niskie
Aktualizacja dokumentacji DR	Niski (dni)	Niskie

Macierz decyzyjna — podsumowanie

CZY DB@AZURE JEST DLA MNIE?

  Mam Oracle Enterprise Edition?
    ├─ TAK → Czy moja baza to Oracle 19c lub nowsze?
    │         ├─ TAK → ✅ PROSTA MIGRACJA (Data Guard switchover)
    │         │         Czas: 4-8 tygodni | Ryzyko: Niskie
    │         │
    │         └─ NIE (11g/12c/18c/21c) → ⚠️ MIGRACJA Z UPGRADE
    │                   Czas: 6-12 tygodni | Ryzyko: Średnie
    │
    └─ NIE (SE2/XE) → ❌ DB@AZURE NIEDOSTĘPNE
                       Alternatywy:
                       ├─ Oracle na Azure VM (Lift & Shift z SE2)
                       ├─ OCI Base Database (SE2 wspierane)
                       └─ Migracja do PostgreSQL (eliminacja licencji)

Końcowa rekomendacja

Jeśli Twoja organizacja: – ✅ Używa Oracle Enterprise Edition – ✅ Chce zachować pełną kompatybilność Oracle – ✅ Potrzebuje wydajności Exadata – ✅ Korzysta z ekosystemu Azure (AKS, App Service, Azure AD) – ✅ Chce uniknąć zarządzania hardware

→ Oracle Database@Azure jest OPTYMALNYM wyborem dla pełnej migracji istniejącego środowiska Oracle do chmury Azure.

---

Artykuł został przygotowany jako kompletna analiza możliwości migracji do Oracle Database@Azure. Przed podjęciem decyzji zaleca się przeprowadzenie Proof of Concept (PoC) w wybranym regionie Azure.