0x01 / SCENARIO
Wybrane dane. W innym miejscu.
Replikacja wskazanych tabel do bazy Oracle, PostgreSQL albo Db2. Bez przenoszenia całego świata, jeśli potrzebujesz jego części.
ORA-600 / CHARON / 0x600
Charon. Przeprawa dla danych.
Logiczna replikacja zmian z Oracle. Internale po naszej stronie. Dane tam, gdzie ich potrzebujesz.
ORA-600 ENGINEERING / LOGICAL REPLICATION
To nie magia.
Znamy drogę przez redo.
Charon przenosi logiczne zmiany z Oracle do Oracle, PostgreSQL i IBM Db2. Harvester przechwytuje. Weaver aplikuje. A pomiędzy nimi jest coś ważniejszego niż efektowna strzałka: granica transakcji.
Uruchom przeprawę ↓
ORACLE INTERNALS. REAL ENGINEERING.
Prześledź jedną transakcję.
Kliknij etap albo uruchom animację. Tempo jest umowne — to mechanizm, nie benchmark.
CAPTURE / ORACLE LOGMINER
Dekoduje Oracle. My przejmujemy wynik.
Fizyczne redo i change vectory interpretuje silnik Oracle LogMiner. Charon odbiera SQL_REDO, składa fragmenty i przekazuje logiczne zmiany do wspólnej ścieżki.
- REDODBMS_LOGMNR
Oracle uruchamia mining redo.
- ORACLE MININGV$LOGMNR_CONTENTS
Oracle zwraca SQL_REDO i metadane.
- CHARON / COLLECTORSQL_REDO → XID
Charon składa fragmenty i wiąże transakcje.
- COMMON PIPELINEminedRecord
Dalej: mapowanie, .dml i bramka COMMIT.
CAPTURE / CHRNATIVE / NO ORACLE LOGMINER
Bierzemy redo na warsztat. Wektor po wektorze.
Tu mining robimy własnym kodem. Charon czyta fizyczne redo, rozpoznaje change vectory i sam rekonstruuje logiczne operacje. Bez DBMS_LOGMNR i bez pobierania SQL_REDO z V$LOGMNR_CONTENTS. „Ręcznie” znaczy: nasz dekoder, nie człowiek przepisujący logi.
- PHYSICAL READCURRENT / ARCHIVE
Odczyt bajtów z plików redo.
- CHANGE VECTORSBYTES → VECTORS
Własne rozpoznawanie i dekodowanie wektorów zmian.
- CHARON / DECODERStreamDecoder / XID
Składanie kompletnych operacji logicznych w kontekście transakcji.
- LOGICAL DMLEvent → minedRecord
Wspólny format. Ten sam mapping, .dml i COMMIT.
Powyżej: wnętrze Harvestera. Poniżej: cały przepływ. Zmienia się sposób odczytu i dekodowania, nie zasada „apply dopiero po COMMIT”.
SOURCE / ORACLE
Tu zaczyna się zmiana.
Oracle zapisuje zmiany w redo. Charon przechwytuje je przez wybrany mechanizm: Oracle LogMiner albo Native Redo.
HARVESTER / LOGMINER
Oracle dekoduje. Charon odbiera.
DBMS_LOGMNR uruchamia mining. Oracle interpretuje change vectory i udostępnia SQL_REDO w V$LOGMNR_CONTENTS. Collector Charona odbiera wynik, składa fragmenty i rozpoznaje XID.
MAPPING / .DML
Transakcja jeszcze czeka.
Mapowanie wiąże tabele źródłowe z docelowymi. Operacje są gromadzone w pliku .dml. Otwarta transakcja nie jest jeszcze aplikowana na celu.
COMMIT GATE
Bez COMMIT nie przepływasz.
Dopiero COMMIT po stronie źródła udostępnia transakcję Weaverowi. ROLLBACK nie jest poleceniem aplikowania zmian.
WEAVER / APPLY
Teraz druga strona.
Weaver odczytuje zatwierdzone transakcje i wykonuje operacje na wybranej bazie docelowej. Capture i apply mogą pracować niezależnie.
TARGET
Dane tam, gdzie mają być.
Oracle, PostgreSQL lub IBM Db2. Obsługę wersji, typów danych, konfigurację i wymagany wariant kompilacji potwierdzamy dla konkretnego wdrożenia.
ROLLBACK
Ta transakcja nie przepływa.
Wycofane zmiany nie są aplikowane w bazie docelowej. Przykład dotyczy otwartej transakcji źródłowej — nie cofania zmian już zatwierdzonych na celu.
PROVIDEROracle LogMiner
TX0x0600 / DEMO
SOURCEREDO
TARGETPostgreSQL
APPLYWAIT
Gotowe. Wybierz etap lub rozpocznij.
Native Redo: obecnie tryb continuous, jedna redo thread i jeden PDB na replikację. Db2 wymaga odpowiedniego wariantu kompilacji.
// USE THE CURRENT
Jeden silnik.
Kilka kierunków.
0x02 / SCENARIO
Raportowanie na drugim brzegu.
Przechwytywanie zmian jako element zasilania oddzielnej bazy raportowej lub integracyjnej. Architektura pod zastosowanie, nie odwrotnie.
0x03 / SCENARIO
Najpierw stan. Potem zmiany.
Ładowanie początkowe i późniejsze przechwytywanie zmian mogą wspierać przygotowanie danych do migracji. Plan przełączenia i testy ustalamy osobno.
[ ENGINEERING > HYPE ]
Nie obiecujemy cudów. Ustalamy warunki.
CLI i REST do sterowania. Mapowanie tabel. Oddzielne capture i apply. Zanim wdrożymy: sprawdzamy wersje, typy danych, topologię i zachowanie po awarii. Nie sprzedajemy hasła „exactly-once” — ścieżka odtwarzania może ponowić transakcję po awarii. Dlatego testujemy również wznowienie i obsługę duplikatów.
Pogadajmy o Twojej przeprawie ↗