Trasmettere dati in streaming dai database Oracle

Datastream ti consente di trasmettere dati storici e modifiche in corso da un database Oracle di origine alla destinazione per l'analisi in tempo reale e la sincronizzazione del database.

Prima di configurare un'origine Oracle, esamina il comportamento di replica, le versioni e i tipi di database supportati, la configurazione del database, le best practice e le limitazioni note in Datastream.

Comportamento

Datastream supporta due metodi di estrazione delle modifiche ai dati dai file di redo log online: il lettore di log binari Oracle (anteprima) e Oracle LogMiner.

Con il metodo di lettura dei log binari (anteprima), viene osservato il seguente comportamento:

  • Se si verifica un ritardo di lettura durante l'estrazione delle modifiche dai file di log online, Datastream estrae le modifiche dai file di log archiviati.

  • Datastream replica solo le modifiche di cui è stato eseguito il commit nella destinazione. Le transazioni di cui non è stato eseguito il commit o il rollback non vengono replicate.

  • Il lettore binario supporta la replica di colonne Oracle VARCHAR2 di lunghezza superiore a 4000 caratteri.

Datastream supporta anche la funzionalità Oracle LogMiner per esporre le modifiche ai dati. Il metodo ha il seguente comportamento:

  • È possibile selezionare tutti gli schemi o schemi specifici di un determinato database, nonché tutte le tabelle degli schemi o tabelle specifiche.
  • Tutti i dati storici vengono replicati.
  • Vengono replicate tutte le modifiche del data manipulation language (DML), come inserimenti, aggiornamenti ed eliminazioni dai database e dalle tabelle specificati.
  • Datastream replica nella destinazione sia le modifiche di cui è stato eseguito il commit sia, in alcuni casi, quelle di cui non è stato eseguito il commit. Datastream legge le modifiche di cui non è stato eseguito il commit. In caso di rollback, i record di output di Datastream includono anche l'operazione opposta. Ad esempio, se è presente un'operazione INSERT di cui è stato eseguito il rollback, i record di output conterranno anche un'operazione DELETE corrispondente. In questo caso, l'evento verrà visualizzato come evento DELETE solo con ROWID.

Backfill basato su ROWID

In Oracle, ROWID è una pseudocolonna che memorizza identificatori univoci per le righe di una tabella. Datastream utilizza i valori ROWID per le operazioni di backfill. Per questo motivo, ti consigliamo di non eseguire azioni che potrebbero modificare i valori ROWID nel database Oracle di origine fino al completamento dell'operazione di backfill.

Le azioni che possono modificare i valori ROWID includono:

  • Spostamento fisico delle righe:

    • Operazioni di esportazione e importazione: quando esporti una tabella e poi la importi di nuovo, la posizione fisica delle righe potrebbe cambiare, generando nuovi valori ROWID.
    • Comando ALTER TABLE (...) MOVE: lo spostamento di una tabella in uno spazio delle tabelle diverso può modificare l'archiviazione fisica e comportare modifiche a ROWID.
    • Comando ALTER TABLE (...) SHRINK SPACE: questo comando comprime la tabella, spostando potenzialmente le righe e influendo sui relativi valori ROWID.
    • Operazioni di partizionamento: la suddivisione, l'unione o lo spostamento delle partizioni possono modificare la posizione fisica delle righe e i relativi valori ROWID.

  • Operazioni di flashback:

    • FLASHBACK TABLE: il ripristino di una tabella a uno stato precedente comporta l'eliminazione e il reinserimento di righe, creando così nuovi valori ROWID.
    • FLASHBACK_TRANSACTION_QUERY: simile a FLASHBACK TABLE. Il rollback di una transazione può causare ROWID modifiche se le righe sono state eliminate o aggiornate all'interno della transazione.

Risolvi i problemi di backfill della tabella di partizione Oracle 11.2.0.4

Se il backfill non va a buon fine per una tabella partizionata su Oracle 11.2.0.4 con un errore di recupero imprevisto (indice fuori dai limiti), ciò è dovuto a un bug dei metadati di Oracle per cui le query a ALL_OBJECTS non restituiscono le sottopartizioni.

  • Soluzione alternativa: revoca temporaneamente il privilegio SELECT ON DBA_EXTENTS all'utente Datastream (ad esempio REVOKE SELECT ON sys.dba_extents FROM USER_NAME;). In questo modo, Datastream è costretto a utilizzare il backfill basato su indice, ignorando il problema dei metadati.

Database in standby

Quando utilizzi un database standby Oracle Active Data Guard come origine, Datastream legge i redo log archiviati. Per assicurarti che Datastream elabori solo i redo log che sono stati applicati correttamente al database in standby, devi filtrare le visualizzazioni Oracle standard, come V$ARCHIVED_LOG e GV$ARCHIVED_LOG, in modo da includere solo i record con il filtro APPLIED = 'YES'.

Puoi farlo creando visualizzazioni personalizzate. Assicurati di concedere l'accesso appropriato a queste visualizzazioni per l'utente Datastream. Ad esempio:

CREATE OR REPLACE VIEW USER_NAME.local_v$archived_log AS 
SELECT * FROM sys.v_$ARCHIVED_LOG
WHERE RESETLOGS_CHANGE# = (SELECT resetlogs_change# FROM v$database)
  AND APPLIED = 'YES';

CREATE OR REPLACE VIEW USER_NAME.local_gv$archived_log AS 
SELECT * FROM sys.gv_$ARCHIVED_LOG
WHERE RESETLOGS_CHANGE# = (SELECT resetlogs_change# FROM v$database)
  AND APPLIED = 'YES';

CREATE SYNONYM USER_NAME.v$archived_log FOR USER_NAME.local_v$archived_log;
CREATE SYNONYM USER_NAME.gv$archived_log FOR USER_NAME.local_gv$archived_log;

L'utilizzo del filtro APPLIED = 'YES' ha un'implicazione sull'aggiornamento dei dati. Datastream attende che il processo di recupero gestito (MRP) del database in standby applichi i log e aggiorni la colonna APPLIED a YES prima di estrarre le modifiche. Se il processo MRP viene ritardato o messo in pausa, ad esempio se sospendi il processo di applicazione in standby, l'aggiornamento dei dati replicati ne risente direttamente. Datastream entra in un loop di nuovi tentativi e ritarda l'elaborazione finché i log archiviati appena applicati non diventano disponibili.

Questa configurazione è molto importante quando si replicano tabelle che includono colonne di oggetti di grandi dimensioni (LOB). Per le operazioni UPDATE, i valori dettagliati delle colonne LOB non sono presenti nei redo log; pertanto, Datastream deve eseguire una query sul database per recuperare la riga associata. Se Datastream elabora un redo log non applicato e tenta di recuperare il valore LOB dal database in standby, potrebbe recuperare un valore errato e obsoleto. Filtrando i log per assicurarsi che vengano applicati completamente, Datastream recupera i dati corretti.

Versioni

Datastream supporta le seguenti versioni del database Oracle:

  • Oracle 11g, versione 11.2.0.4 (supportata solo con il metodo CDC LogMiner)
  • Oracle 12c, versione 12.1.0.2
  • Oracle 12c, versione 12.2.0.1
  • Oracle 18c
  • Oracle 19c
  • Oracle 21c

Datastream supporta i seguenti tipi di database Oracle:

  • In hosting autonomo on-premise o su qualsiasi provider cloud
  • Amazon RDS per Oracle
  • Cloud Oracle
  • Oracle Exadata
  • Oracle RAC
  • Database di standby Oracle Active Data Guard

Configurazione

Per configurare un database Oracle di origine in modo che i dati possano essere trasmessi in streaming a una destinazione, devi configurare il database per concedere l'accesso, configurare il logging e definire una policy di conservazione.

Consulta Configura un database Oracle di origine per scoprire come configurare questo database in modo che Datastream possa estrarre i dati da questo database in una destinazione.

Best practice

Questa sezione descrive le best practice consigliate per configurare l'origine Oracle da utilizzare con Datastream.

Sensibilità alle maiuscole per il lettore binario

Quando configuri un'origine Oracle con il metodo CDC del lettore binario e specifichi i nomi delle directory per i log di ripristino e di archiviazione, tieni presente che i nomi sono sensibili alle maiuscole. Assicurati che i nomi delle directory forniti nel profilo di connessione di Datastream corrispondano esattamente alle maiuscole e minuscole dei nomi delle directory nel tuo database Oracle.

Concorrenza CDC

Per ridurre al minimo il ritardo di replica, assicurati che Datastream possa elaborare i redo log con la stessa velocità con cui l'origine Oracle li crea. Quando utilizzi il metodo CDC del lettore binario, la concorrenza di Datastream è a livello di file di redo log: ogni attività definita da maxConcurrentCdcTasks elabora un file alla volta.

Ti consigliamo di utilizzare la seguente metodologia:

  • Ottimizza la contemporaneità in Datastream: identifica il numero medio di cambi di redo log durante l'orario di apertura di punta e configura il parametro maxConcurrentCdcTasks di conseguenza. Per saperne di più, consulta Numero massimo di attività CDC.
  • Configura il cambio dei log di Oracle: configura Oracle in modo che cambi i log di frequente, ad esempio ogni 10-20 minuti. In questo modo viene creato un flusso costante di unità di lavoro più piccole, consentendo alle attività simultanee di Datastream di funzionare in parallelo in modo efficace.

Ti consigliamo di ottimizzare le impostazioni in modo che in Datastream siano presenti attività simultanee sufficienti per gestire la creazione frequente di redo log più piccoli da Oracle. Per saperne di più, consulta i controlli della concorrenza degli stream.

Limitazioni note

Le limitazioni note per l'utilizzo del database Oracle come origine includono:

  • Gli stream sono limitati a 10.000 tabelle. Se uno stream include più di 10.000 tabelle, potrebbero verificarsi errori.
  • Datastream supporta l'architettura multi-tenant Oracle (CDB/PDB), ma puoi replicare un solo database modulare in uno stream.
  • Oracle Autonomous Database non è supportato.
  • Per le tabelle che non hanno una chiave primaria, Datastream utilizza ROWID della riga per eseguire un'operazione di unione lato consumer. Tieni presente che il ROWID potrebbe non essere univoco. Se elimini e reinserisci una riga con l'utilità di esportazione/importazione di Oracle, ad esempio, il ROWID della riga potrebbe cambiare. Se elimini una riga, Oracle può riassegnare il relativo ROWID a una nuova riga inserita in un secondo momento.
  • Le tabelle organizzate per indice (IOT) non sono supportate.
  • Le tabelle temporanee non sono supportate.
  • I seguenti tipi di dati Oracle non sono supportati e non vengono replicati. Le colonne di questi tipi vengono replicate come valori NULL nella destinazione:
    • ANYDATA, ANYDATASET, ANYTYPE
    • VARRAY (array Oracle)
    • BFILE, BFILENAME
    • INTERVAL DAY TO SECOND, INTERVAL YEAR TO MONTH
    • LONG, LONG RAW
    • UROWID
    • UDT
    • Tipi di dati multimediali e spaziali: ORDAUDIO, ORDDATASOURCE, ORDDICOM, ORDDOC, ORDIMAGE, ORDVIDEO, SDO_GEOMETRY (e tutti gli altri tipi di MDSYS.SDO_*).

  • Per lo streaming delle colonne di tipi di dati di oggetti di grandi dimensioni, come XMLTYPE, oggetti binari di grandi dimensioni (BLOB), oggetti di grandi dimensioni di caratteri (CLOB) e oggetti di grandi dimensioni di caratteri nazionali (NCLOB), devi includere il flag streamLargeObjects nella configurazione dello stream. Se non includi il flag, Datastream non esegue lo streaming di queste colonne e vengono sostituite con valori NULL nella destinazione. Per ulteriori informazioni, vedi Attiva lo streaming di oggetti di grandi dimensioni per le origini Oracle. Durante lo streaming di questi tipi di dati, Datastream deve eseguire query sul database di origine per recuperare i valori LOB mancanti in un determinato momento (in un processo di ricerca attivo chiamato integrazione). Questo accade nei seguenti scenari:

    • Quando i payload LOB invariati vengono eliminati dal redo log durante un UPDATE
    • Durante qualsiasi operazione DML che coinvolge tipi XML binari
    • Durante qualsiasi DML analizzato su una tabella contenente LOB se lo stream utilizza il metodo LogMiner

    Poiché Datastream trasmette queste colonne eseguendo query sul database, le modifiche intermedie potrebbero non essere acquisite in scenari che prevedono aggiornamenti rapidi e consecutivi o un'eliminazione rapida dopo un inserimento. Tieni presente che le operazioni DELETE non attivano l'integrazione. Questa limitazione è particolarmente rilevante quando si utilizza la modalità di scrittura di sola aggiunta, che prevede l'acquisizione di tutte le modifiche intermedie.

  • Per Oracle 11g, le tabelle con colonne di tipi di dati ANYDATA o UDT non sono supportate e l'intera tabella non verrà replicata.

  • Oracle Label Security (OLS) non viene replicato.

  • Datastream recupera periodicamente lo schema più recente dall'origine man mano che gli eventi vengono elaborati. Se uno schema cambia, alcuni eventi del nuovo schema potrebbero essere letti mentre è ancora applicato lo schema precedente. In questo caso, Datastream rileva la modifica dello schema, attiva un recupero dello schema ed elabora nuovamente gli eventi non riusciti.

  • Non tutte le modifiche allo schema di origine possono essere rilevate automaticamente. In questo caso, potrebbe verificarsi un danneggiamento dei dati. Le seguenti modifiche allo schema potrebbero causare il danneggiamento dei dati o l'impossibilità di elaborare gli eventi a valle:

    • Eliminazione di colonne
    • Aggiunta di colonne al centro di una tabella
    • Modificare il tipo di dati di una colonna
    • Riordinare le colonne
    • Eliminare tabelle (pertinente se la stessa tabella viene poi ricreata con l'aggiunta di nuovi dati)
    • Troncamento delle tabelle

  • Datastream non supporta la replica delle viste.

  • Datastream non supporta la replica delle colonne virtuali (GENERATED ALWAYS AS (...) VIRTUAL) perché Oracle non archivia i valori delle colonne virtuali sul disco né li scrive nei redo log. Le colonne virtuali vengono omesse dallo schema di destinazione. Se una colonna virtuale fa parte di una chiave primaria composita, Datastream utilizza solo le colonne non virtuali come chiave primaria nella destinazione, il che può causare sovrascritture di chiavi duplicate se le colonne rimanenti non sono univoche.

  • Datastream supporta le viste materializzate. Tuttavia, le nuove visualizzazioni create durante l'esecuzione dello streaming non vengono compilate automaticamente.

  • Quando utilizzi il metodo Oracle LogMiner, le istruzioni SAVEPOINT non sono supportate e possono causare discrepanze nei dati in caso di rollback.

  • Quando utilizzi il metodo del lettore binario, le tabelle partizionate dinamicamente non sono supportate.

  • Quando utilizzi il metodo Oracle LogMiner, Datastream non supporta la replica di tabelle e colonne i cui nomi superano i 30 caratteri.

  • Datastream supporta le seguenti codifiche dei set di caratteri per i database Oracle:

    • AL16UTF16
    • AL32UTF8
    • IN8ISCII
    • IW8ISO8859P8
    • JA16SJIS
    • JA16SJISTILDE
    • KO16MSWIN949
    • US7ASCII
    • UTF8
    • WE8ISO8859P1
    • WE8ISO8859P9
    • WE8ISO8859P15
    • WE8MSWIN1252
    • ZHT16BIG5

  • Datastream non supporta la replica dei valori con data pari a zero. Queste date vengono sostituite con i valori NULL.

  • Datastream non supporta la connettività diretta ai database utilizzando la funzionalità Single Client Access Name (SCAN) negli ambienti Oracle Real Application Clusters (RAC). Per informazioni sulle potenziali soluzioni, consulta Comportamento e limitazioni dell'origine Oracle.

  • Se l'origine è un database di standby Oracle Active Data Guard, Datastream supporta solo la crittografia a livello di tablespace e non supporta la crittografia a livello di colonna.

Limitazioni aggiuntive quando si utilizza il lettore binario

  • Il metodo di lettura binaria ad alte prestazioni è supportato solo per Oracle 12c e versioni successive. Per Oracle 11g e versioni precedenti, devi utilizzare LogMiner.

  • Il lettore binario non supporta le seguenti funzionalità:

    • Transparent Database Encryption (TDE)
    • Hybrid Columnar Compression
    • File sicuri
    • ASM non è supportato per le origini Amazon RDS.
    • Il metodo CDC del lettore binario non supporta Oracle 11g e versioni precedenti.

Passaggi successivi