Metody przetwarzania danych z bazy Oracle

Oracle

Metody zbierania danych z dzienników Redo

Logminer

Podczas konfigurowania Logminera należy być świadomym znaczenia poniższych obiektów :

Źródłowa baza danych

Generuje wszystkie pliki dziennika redo, które mają być analizowane przez LogMiner

Wydobywcza baza danych

Baza danych, z której LogMiner korzysta podczas przeprowadzania analizy.

Słownik Logminer

Pozwala programowi LogMiner na podawanie nazw tabel i kolumn zamiast wewnętrznych identyfikatorów obiektów podczas wyświetlania żądanych danych dziennika redo.

Pliki Redo

zawierają zmiany wprowadzone w bazie danych lub słowniku bazy danych.

*słowniki Logminer - LogMiner używa słownika do tłumaczenia wewnętrznych identyfikatorów obiektów i typów danych na nazwy obiektów i zewnętrzne formaty danych. Bez słownika LogMiner zwraca wewnętrzne identyfikatory obiektów i prezentuje dane jako dane binarne.

INSERT INTO HR.JOBS(JOB_ID, JOB_TITLE, MIN_SALARY, MAX_SALARY)  VALUES('IT_WT','Technical Writer', 4000, 11000);

Bez słownika Logminer zwracałby :

insert into "UNKNOWN"."OBJ# 45522"("COL 1","COL 2","COL 3","COL 4") values
(HEXTORAW('45465f4748'),HEXTORAW('546563686e6963616c20577269746572'),
HEXTORAW('c229'),HEXTORAW('c3020b'));

Przed wygenerowaniem plików dziennika, które zostaną przeanalizowane przez LogMiner, należy włączyć dodatkowe rejestrowanie.

Gdy włączysz dodatkowe rejestrowanie, w strumieniu redo rejestrowane są dodatkowe informacje, które są potrzebne, aby informacje w plikach dziennika redo były dla Ciebie przydatne. Dlatego przynajmniej musisz włączyć minimalne dodatkowe rejestrowanie, jak pokazuje poniższe polecenie SQL:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Aby ustalić, czy dodatkowe rejestrowanie jest włączone, należy wykonać zapytanie do V$DATABASEwidoku, jak pokazano poniżej:

SELECT SUPPLEMENTAL_LOG_DATA_MIN FROM V$DATABASE;

LogMiner wymaga słownika do tłumaczenia identyfikatorów obiektów na nazwy obiektów, gdy zwraca dane redo. LogMiner daje trzy opcje dostarczenia słownika, natmiast w przypadku Goldenore CDC zalecana i wspieran jest opcja

Online Catalog
Oracle zaleca korzystanie z tej opcji, gdy będziesz mieć dostęp do źródłowej bazy danych, z której utworzono pliki dziennika redo i gdy nie przewiduje się żadnych zmian w definicjach kolumn w interesujących tabelach. Jest to najbardziej wydajna i łatwa w użyciu opcja.

Pamiętaj jednak, że katalog online może rekonstruować tylko polecenia SQL wykonywane na najnowszej wersji tabeli. Gdy tylko tabela zostanie zmieniona, katalog online nie będzie już odzwierciedlał poprzedniej wersji tabeli. Oznacza to, że LogMiner nie będzie w stanie rekonstruować żadnych poleceń SQL wykonywanych na poprzedniej wersji tabeli. Zamiast tego LogMiner generuje niewykonywalny kod SQL (w tym formatowanie szesnastkowe do surowych wartości binarnych) w kolumnie SQL_REDOwidoku V$LOGMNR_CONTENT.

Wspierane typy danych i atrybuty przechowywania tabel

Wspierane typy danych i atrybuty przechowywania tabel	Uwagi	Debezium
CHAR		T
NCHAR		T
VARCHAR2 i VARCHAR		T
NVARCHAR2		T
NUMBER		T
DATE		T
TIMESTAMP		T
TIMESTAMP WITH TIME ZONE		T
TIMESTAMP WITH LOCAL TIME ZONE		T
INTERVAL YEAR TO MONTH		T
INTERVAL DAY TO SECOND		T
RAW		T
CLOB		T
NCLOB		T
BLOB		T
LONG		N
LONG RAW		N
BINARY_FLOAT		T
BINARY_DOUBLE		T
Tabele zorganizowane w indeksy (IOT), w tym te z nadmiarowymi danymi lub kolumnami LOB	Wsparcie zależne od wersji
Indeksy oparte na funkcjach
Tabele używające kompresji podstawowej i kompresji OLTP
Dane XMLType przechowywane w formacie CLOB		T
Dane XMLType przechowywane w formacie obiektowo-relacyjnym	Zawartość kolumny SQL_REDO dla operacji związanych z danymi XML nigdy nie jest prawidłowym SQL lub PL/SQL	T
Dane XMLType przechowywane jako XML binarny	Zawartość kolumny SQL_REDO dla operacji związanych z danymi XML nigdy nie jest prawidłowym SQL lub PL/SQL	T
Hybrydowa kompresja kolumnowa	Zależy od systemu przechowywania i kompatybilności ustawionej na 11.2
Wielobajtowe CLOB	Dostępne dla dzienników redo generowanych przez bazę danych z kompatybilnością ustawioną na 10.1 lub wyższą
Typy danych LOB i LONG	Dostępne dla dzienników redo generowanych przez bazę danych z kompatybilnością ustawioną na 9.2.0.0 lub wyższą
Tabele zorganizowane w indeksy bez segmentu nadmiarowego lub bez kolumn LOB	Dostępne dla dzienników redo generowanych przez bazę danych z kompatybilnością ustawioną na 10.0.0.0 lub wyższą
Tabele zorganizowane w indeksy z segmentem nadmiarowym lub z kolumnami LOB	Dostępne dla dzienników redo generowanych przez bazę danych z kompatybilnością ustawioną na 10.2.0.0 lub wyższą
Dane XMLType przechowywane jako XML binarny	Dostępne na Oracle Database 11g Release 2 (11.2.0.3) lub wyższej z ustawieniem kompatybilności redo na 11.2.0.3 lub wyższą	T
Dane XMLType przechowywane w formacie obiektowo-relacyjnym	Dostępne na Oracle Database 11g Release 2 (11.2.0.3) lub wyższej z ustawieniem kompatybilności redo na 11.2.0.3 lub wyższą	T

Uwagi

Debezium

CHAR

NCHAR

VARCHAR2 i VARCHAR

NVARCHAR2

NUMBER

DATE

TIMESTAMP

TIMESTAMP WITH TIME ZONE

TIMESTAMP WITH LOCAL TIME ZONE

INTERVAL YEAR TO MONTH

INTERVAL DAY TO SECOND

RAW

CLOB

NCLOB

BLOB

LONG

LONG RAW

BINARY_FLOAT

BINARY_DOUBLE

Tabele zorganizowane w indeksy (IOT), w tym te z nadmiarowymi danymi lub kolumnami LOB

Wsparcie zależne od wersji

Indeksy oparte na funkcjach

Tabele używające kompresji podstawowej i kompresji OLTP

Dane XMLType przechowywane w formacie CLOB

Dane XMLType przechowywane w formacie obiektowo-relacyjnym

Zawartość kolumny SQL_REDO dla operacji związanych z danymi XML nigdy nie jest prawidłowym SQL lub PL/SQL

Dane XMLType przechowywane jako XML binarny

Zawartość kolumny SQL_REDO dla operacji związanych z danymi XML nigdy nie jest prawidłowym SQL lub PL/SQL

Hybrydowa kompresja kolumnowa

Zależy od systemu przechowywania i kompatybilności ustawionej na 11.2

Wielobajtowe CLOB

Dostępne dla dzienników redo generowanych przez bazę danych z kompatybilnością ustawioną na 10.1 lub wyższą

Typy danych LOB i LONG

Dostępne dla dzienników redo generowanych przez bazę danych z kompatybilnością ustawioną na 9.2.0.0 lub wyższą

Tabele zorganizowane w indeksy bez segmentu nadmiarowego lub bez kolumn LOB

Dostępne dla dzienników redo generowanych przez bazę danych z kompatybilnością ustawioną na 10.0.0.0 lub wyższą

Tabele zorganizowane w indeksy z segmentem nadmiarowym lub z kolumnami LOB

Dostępne dla dzienników redo generowanych przez bazę danych z kompatybilnością ustawioną na 10.2.0.0 lub wyższą

Dane XMLType przechowywane jako XML binarny

Dostępne na Oracle Database 11g Release 2 (11.2.0.3) lub wyższej z ustawieniem kompatybilności redo na 11.2.0.3 lub wyższą

Dane XMLType przechowywane w formacie obiektowo-relacyjnym

Dostępne na Oracle Database 11g Release 2 (11.2.0.3) lub wyższej z ustawieniem kompatybilności redo na 11.2.0.3 lub wyższą

Niewspierane typy danych i atrybuty przechowywania tabel

Uwagi

Debezium

Typ danych BFILE

Proste i zagnieżdżone typy danych abstrakcyjnych (ADT)

Kolekcje (tabele zagnieżdżone i VARRAY)

Odwołania obiektów

SecureFiles

Chyba że kompatybilność bazy danych jest ustawiona na 11.2 lub wyższą

Kolumny SecureFiles LOB z deduplikacją, operacjami fragmentacyjnymi oraz operacjami SecureFiles Database File System (DBFS)

Operacje w pakiecie DBMS_LOB PL/SQL na kolumnach SecureFiles LOB: FRAGMENT_DELETE, FRAGMENT_INSERT, FRAGMENT_MOVE, FRAGMENT_REPLACE, COPY_FROM_DBFS_LINK, MOVE_TO_DBFS_LINK, SET_DBFS_LINK, COPY_DBFS_LINK, SETCONTENTTYPE

LogMiner generuje wiersze z kolumną OPERATION ustawioną na UNSUPPORTED. Nie będzie generowane SQL_REDO ani SQL_UNDO dla tych rekordów redo

Dodatkowe informacje

Wspierane bazy danych i wersje plików dzienników redo: LogMiner działa na bazach danych wersji 8.1 lub nowszych, ale można go używać do analizy plików dzienników redo z baz danych wersji 8.0.
Uwagi dotyczące SecureFiles LOB: Wspierane, gdy kompatybilność bazy danych jest ustawiona na 11.2 lub wyższą. Tylko kolumny SQL_REDO mogą być wypełniane dla kolumn SecureFiles LOB; kolumny SQL_UNDO nie są wypełniane.

Monitorowanie Logminera

Zarządzanie Logminerem przez Debezium

XStream Api

OpenLog Replicator

Punkty przywracania / Oracle

W momencie robienia punktów przywracania - należy ustawić poniższy parametr w celu pobierania tylko najnowszych Archów, w przypadku nie ustawienia należy usunąć stare Archy z pomocą RMAN.

log.mining.archive.log.hours

0

The number of hours in the past from SYSDATE to mine archive logs. When the default setting (0) is used, the connector mines all archive logs.

Konektory Debezium

Obsługa wartości domyslnych

Ustawienia dla konektora źródłowego :

"value.converter.replace.null.with.default" : "true",

"value.converter.enhanced.avro.schema.support":"true",

"value.converter.ignore.default.for.nullables":"true",

Stand

Aby umożliwić Debezium przechwytywanie zdarzeń z logicznej bazy danych Oracle tylko do odczytu, należy dodać następującą właściwość do konfiguracji łącznika, aby wyłączyć tworzenie i zarządzanie tabelą opróżniania:

internal.log.mining.read.only=true

Poprzednie ustawienie zapobiega tworzeniu i aktualizowaniu tabeli przez bazę danych LOG_MINING_FLUSH. Możesz użyć tej internal.log.mining.read.onlywłaściwości z bazą danych Oracle Standalone lub z instalacją Oracle RAC.

PreviousLogMiner testy wydajnościowe NextOpenLogReplicator (OLR)

Last updated 2 months ago