Prepara tabelle per elaborazione

Per preparare le tabelle per l'uso in un ambiente Oracle GoldenGate per Db2 LUW, è necessario eseguire i task riportati di seguito.

Disabilitazione dei trigger e dei vincoli in cascata

Disabilitare i trigger, i vincoli di eliminazione a catena e i vincoli di aggiornamento a catena nelle tabelle LUW Db2 di destinazione. Oracle GoldenGate replica DML risultante da un trigger o da un vincolo a catena. Se lo stesso trigger o vincolo viene attivato nella tabella di destinazione, diventa ridondante a causa della versione replicata e il database restituisce un errore. Si consideri l'esempio seguente, dove le tabelle di origine sono emp_src e salary_src e le tabelle di destinazione sono emp_targ e salary_targ.

Viene emessa un'eliminazione per emp_src.
Viene applicata un'eliminazione a salary_src.
Oracle GoldenGate invia entrambe le eliminazioni alla destinazione.
L'eliminazione padre arriva per prima e viene applicata a emp_targ.
L'eliminazione padre applica un'eliminazione a catena a salary_targ.
L'eliminazione a catena da salary_src viene applicata a salary_targ.
Impossibile individuare la riga perché è già stata eliminata nel passo 5.

Garantire l'univocità delle righe per le tabelle

Oracle GoldenGate richiede una forma di identificativo di riga univoco nelle tabelle di origine e di destinazione per individuare le righe di destinazione corrette per gli aggiornamenti e le eliminazioni replicati.

A meno che non venga utilizzata una clausola KEYCOLS nell'istruzione TABLE o MAP, Oracle GoldenGate seleziona un identificativo di riga da utilizzare nel seguente ordine di priorità:

Chiave primaria
Prima chiave univoca in modo alfanumerico che non contiene un indicatore orario o una colonna calcolata non materializzata.
Se non esiste alcun tipo di chiave precedente (anche se nella tabella potrebbero essere definiti altri tipi di chiavi), Oracle GoldenGate costruisce una pseudo chiave di tutte le colonne che il database consente di essere utilizzato in una chiave univoca, esclusi quelli non supportati da Oracle GoldenGate in una chiave o quelli esclusi dalla configurazione di Oracle GoldenGate.

Nota: se sono presenti altre chiavi non utilizzabili in una tabella o se non sono presenti chiavi nella tabella, Oracle GoldenGate registra un messaggio appropriato nel file di report. La creazione di una chiave da tutte le colonne impedisce le prestazioni di Oracle GoldenGate nel sistema di origine. Nella destinazione, questa chiave fa sì che Replicat utilizzi una clausola WHERE più grande e meno efficiente.
Se una tabella non dispone di una chiave appropriata o se si preferisce che non vengano utilizzate le chiavi esistenti, è possibile definire una chiave sostitutiva se la tabella contiene colonne che contengono sempre valori univoci. Per definire questa chiave sostitutiva, includere una clausola KEYCOLS nel parametro Extract TABLE e nel parametro Replicat MAP. La chiave specificata sostituirà qualsiasi chiave primaria o univoca esistente trovata da Oracle GoldenGate. Consulta TABLE \| MAP in Riferimento su parametri e funzioni per Oracle GoldenGate.

Utilizzo di KEYCOLS per specificare una chiave personalizzata

Se una tabella non dispone di uno dei tipi precedenti di identificativi di riga o se si preferisce non utilizzare tali identificativi, è possibile definire una chiave sostitutiva se la tabella contiene colonne che contengono sempre valori univoci. Per definire questa chiave sostitutiva, includere una clausola KEYCOLS nel parametro Extract TABLE e nel parametro Replicat MAP. La chiave specificata sostituirà qualsiasi chiave primaria o univoca esistente trovata da Oracle GoldenGate.

Prevenzione delle modifiche chiave

Non aggiungere colonne a una chiave dopo che Oracle GoldenGate ha avviato l'estrazione dei dati dalla tabella. Questa regola si applica a una chiave primaria, una chiave univoca, una chiave KEYCOLS o una chiave a tutte le colonne. Db2 LUW non fornisce un'immagine precedente per le colonne aggiunte a una tabella. Se una colonna qualsiasi di una chiave viene aggiornata nell'origine, Oracle GoldenGate richiede un'immagine precedente da confrontare con i valori correnti nella tabella di destinazione quando replica l'aggiornamento.

Gestione delle tabelle di query materializzate

Per mantenere la parità tra le tabelle delle query materializzate di origine e di destinazione (MQT), replicare le tabelle di base, ma non gli MQT. Il database di destinazione gestisce gli MQT in base alle modifiche applicate da Replicat alle tabelle di base.

Di seguito sono riportate le regole per la configurazione di queste tabelle.

Includere le tabelle di base nelle istruzioni TABLE e MAP.
Non includere MQT nelle istruzioni TABLE e MAP.
I caratteri jolly possono essere utilizzati nelle istruzioni TABLE e MAP, anche se possono risolvere i nomi MQT insieme ai nomi delle tabelle normali. Oracle GoldenGate esclude automaticamente gli MQT dagli elenchi di tabelle con caratteri jolly. Tuttavia, qualsiasi MQT elencato esplicitamente in un'istruzione Extract TABLE per nome causerà l'interruzione di Extract.

Creazione di una tabella temporale

Una tabella temporale è una tabella che mantiene la cronologia dei dati e il periodo di tempo in cui i dati sono validi. Le tabelle temporali vengono utilizzate in Oracle GoldenGate per tenere traccia di tutte le righe precedenti eliminate o aggiornate nella tabella. Le tabelle temporali vengono utilizzate anche per mantenere la validità aziendale delle relative righe e dati. Ad esempio, Oracle GoldenGate tiene traccia del periodo di tempo durante il quale una riga è valida. Esistono tre tipi di tabelle temporali, system-period, application-period e bitemporal table.

Converti in tabella temporale

È possibile convertire una tabella già esistente in una tabella temporale, che modifica la struttura della tabella. In questa sezione viene descritto come cambia la struttura delle tabelle. La tabella esistente di esempio seguente viene convertita in tutti e tre i tipi di tabelle temporali negli esempi riportati di seguito.

Table policy_info
(
Policy_id char[4] not null primary key,
Coverage int not null
              )
And the tables contains the following initial rows
                   POLICY_ID       COVERAGE
                   -------------        -----------
                     ABC                12000
                     DEF                 13000
                     ERT                 14000

Esempio 1 Conversione di una tabella esistente in una tabella temporale del periodo di sistema

La tabella esistente di esempio viene convertita in una tabella temporale del periodo di sistema aggiungendo le colonne SYSTEM_PERIOD, transaction id e il periodo SYSTEM_TIME come indicato di seguito.

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

Creare quindi una tabella di cronologia per la nuova tabella temporale utilizzando uno dei due metodi riportati di seguito.

    CREATE TABLE hist_policy_info
(
 policy_id     CHAR(4) NOT NULL,

coverage     INT NOT NULL,
sys_start    TIMESTAMP(12) NOT NULL ,

sys_end      TIMESTAMP(12) NOT NULL,

ts_id            TIMESTAMP(12) NOT NULL

           );
 ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;

CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;

La clausola RESTRICT ON DROP non consentirà l'eliminazione della tabella di cronologia durante l'eliminazione della tabella temporale del periodo di sistema. In caso contrario, la tabella della cronologia viene eliminata implicitamente durante l'eliminazione della tabella temporale associata. È possibile creare una tabella di cronologia senza RESTRICT ON DROP. Impossibile eliminare in modo esplicito una tabella di cronologia.

Non utilizzare la clausola GENERATED ALWAYS durante la creazione di una tabella di cronologia. Anche la chiave primaria della tabella temporale del periodo di sistema non si applica qui poiché potrebbero esserci molti aggiornamenti per una particolare riga nella tabella di base, che attiva molti inserimenti nella tabella della cronologia per lo stesso set di chiavi primarie. Oltre a questi, la struttura di una tabella della cronologia dovrebbe essere esattamente la stessa della tabella temporale periodo-sistema associata. La tabella della cronologia deve avere lo stesso numero e lo stesso ordine di colonne della tabella temporale del periodo di sistema. Le colonne della tabella cronologia non possono essere aggiunte, eliminate o modificate in modo esplicito. Associare una tabella temporale del periodo di sistema alla relativa tabella di cronologia alla seguente istruzione:

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

Le colonne GENERATED ALWAYS della tabella sono quelle che vengono sempre popolate da Database Manager, pertanto non si dispone di alcun controllo su queste colonne. Database Manager inserisce queste colonne in base all'ora di sistema.

Le colonne SYSTEM_PERIOD e transaction id aggiunte in eccesso avranno valori predefiniti per le righe già esistenti, come indicato di seguito.

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID

--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

Una volta avviato l'aggiornamento della tabella temporale, la tabella della cronologia associata viene popolata con le immagini precedenti.

Esempio 2 Conversione di una tabella esistente in tabella temporale periodo applicazione

È possibile convertire la tabella esistente di esempio in una tabella temporale del periodo dell'applicazione aggiungendo colonne temporali e un periodo BUSINESS_TIME come indicato di seguito.

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

Durante l'aggiunta di colonne temporali, è necessario assicurarsi che durante l'immissione dei valori di tempo di validità business delle colonne temporali esistenti, la colonna bus_start abbia sempre un valore minore di bus_end poiché queste colonne specificano la validità aziendale delle righe.

La nuova tabella temporale del periodo di applicazione avrà un aspetto simile a:

POLICY_ID   COVERAGE    BUS_START  BUS_END
--------- ----------- ---------- -------------------------------
ERT             14000              10/10/2001  10/10/2002
DEF             13000             10/10/2001   10/10/2002
ABC             12000             10/10/2001   10/10/2002

Esempio 3 Conversione di una tabella esistente in tabella bitemporal

È possibile convertire la tabella di esempio esistente in tabella bitemporale aggiungendo SYSTEM_PERIOD, le colonne temporali insieme al periodo SYSTEM_TIME e BUSINESS_TIME come indicato di seguito.

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

Durante l'aggiunta delle colonne orarie, è necessario assicurarsi che durante l'immissione dei valori del tempo di validità aziendale delle colonne orarie già esistenti, il valore della colonna bus_start sia sempre minore di bus_end poiché queste colonne specificano la validità aziendale delle righe.

Creare quindi una tabella di cronologia per la nuova tabella temporale utilizzando uno dei due metodi riportati di seguito.

    CREATE TABLE hist_policy_info
(
 policy_id     CHAR(4) NOT NULL,

coverage     INT NOT NULL,
sys_start    TIMESTAMP(12) NOT NULL ,

sys_end      TIMESTAMP(12) NOT NULL,

ts_id            TIMESTAMP(12) NOT NULL

           );
 ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;
CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;

La clausola RESTRICT ON DROP non consentirà l'eliminazione della tabella di cronologia durante l'eliminazione della tabella temporale del periodo di sistema. In caso contrario, la tabella della cronologia viene eliminata implicitamente durante l'eliminazione della tabella temporale associata. È possibile creare una tabella di cronologia senza RESTRICT ON DROP. Impossibile eliminare in modo esplicito una tabella di cronologia.

Non utilizzare la clausola GENERATED ALWAYS durante la creazione di una tabella di cronologia. Anche la chiave primaria della tabella temporale del periodo di sistema non si applica qui poiché potrebbero esserci molti aggiornamenti per una particolare riga nella tabella di base, che attiva molti inserimenti nella tabella della cronologia per lo stesso set di chiavi primarie. Oltre a questi, la struttura di una tabella della cronologia dovrebbe essere esattamente la stessa della tabella temporale del periodo di sistema associato. La tabella della cronologia deve avere lo stesso numero e lo stesso ordine di colonne della tabella temporale del periodo di sistema. Le colonne della tabella cronologia non possono essere aggiunte, eliminate o modificate in modo esplicito. Associare una tabella temporale del periodo di sistema alla relativa tabella di cronologia alla seguente istruzione:

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

Le colonne SYSTEM_PERIOD e transaction id aggiunte in eccesso avranno valori predefiniti per le righe già esistenti, come indicato di seguito.

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID

--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

Una volta avviato l'aggiornamento della tabella temporale, la tabella della cronologia associata viene popolata con le immagini precedenti.

Il periodo, l'ID transazione e le colonne ora aggiuntivi SYSTEM_TIME avranno valori predefiniti per le righe già esistenti, come indicato di seguito.

POLICY_ID COVERAGE    SYS_START                        SYS_END                          TS_ID                            BUS_START         BUS_END
--------- ----------- -------------------------------- -------------------------------- -------------------------------- ---------- -------------------------------------
ABC   12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002

La tabella della cronologia viene popolata con le immagini precedenti una volta che l'utente avvia l'aggiornamento della tabella temporale.

Esempio 4 Replica in ambiente eterogeneo.

Nella configurazione eterogenea in cui non sono presenti tabelle temporali sul lato di applicazione, è possibile replicare le tabelle del periodo di sistema e bitemporali solo se non le tabelle della cronologia associate. Durante l'esecuzione della replica in questa situazione, è necessario occuparsi del valore delle colonne SYSTEM_PERIOD e ID transazione. Queste colonne avranno alcuni valori che il database di destinazione potrebbe non supportare. È innanzitutto necessario utilizzare le funzioni di conversione della mappa per convertire questi valori nel formato supportato dal database di destinazione, quindi mappare le colonne di conseguenza.

Ad esempio, MySQL ha un intervallo DATETIME compreso tra 1000-01-01 00:00:00.000000 e 9999-12-31 23:59:59.999999. Non è possibile replicare il valore dell'indicatore orario 0001-01-01-00.00.00.000000000000 in MySQL. Per replicare tali valori, è necessario convertire questo valore nel valore MySQL DATETIME 1000-01-01 00:00:00.000000, quindi mappare le colonne. Se nella tabella dei periodi di sistema policy_info è presente la riga seguente:

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID
--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

Per replicare la riga in MySQL, utilizzare la funzione colmap():

map *source_schema*.policy_info, target *target_schema*.policy_info colmap
(policy_id=policy_id, coverage=coverage, sys_start= @IF( ( @NUMSTR( @STREXT(sys_
start,1,4))) > 1000, sys_start, '1000-01-01 00.00.00.000000'), sys_end=sys_end,
 ts_id= @IF( ( @NUMSTR( @STREXT(ts_id,1,4))) > 1000, ts_id, '1000-01-01
 00.00.00.000000'));

Replica con tabelle temporali

È possibile scegliere uno dei metodi seguenti per replicare un periodo di sistema o una tabella temporale bitemporale come indicato di seguito.

È possibile replicare una tabella temporale solo in un'altra tabella temporale. Si tratta del comportamento predefinito. Oracle GoldenGate non replicherà il periodo SYSTEM_TIME e le colonne ID transazione perché queste vengono generate automaticamente sul lato di applicazione. Database Manager inserisce le colonne nella tabella temporale di destinazione utilizzando l'ora di clock del sistema e i valori predefiniti. È possibile conservare i valori originali di queste colonne, quindi utilizzare uno dei valori riportati di seguito.
- Aggiungere ulteriori colonne di indicatore orario nella tabella temporale di destinazione e mappare le colonne di conseguenza. Le colonne extra vengono aggiunte automaticamente alla tabella della cronologia associata.
- Utilizzare una tabella non temporanea sul lato di applicazione e mappare le colonne in modo appropriato. In questo scenario non sarà possibile mantenere la tabella della cronologia.
- In una configurazione eterogenea in cui l'origine è Db2 LUW e la destinazione è un database diverso, è possibile ignorare le colonne generate automaticamente o utilizzare una funzione di conversione delle colonne appropriata per convertire il valore delle colonne nel formato supportato dal database di destinazione e mapparle alle colonne di destinazione di conseguenza.
Oppure
È possibile replicare una tabella temporale, con la tabella della cronologia associata, rispettivamente in una tabella temporale e nella tabella della cronologia, quindi è necessario specificare il parametro Replica, DBOPTIONS SUPPRESSTEMPORALUPDATES. È necessario specificare sia la tabella temporale che la tabella cronologia da acquisire nel file dei parametri Extract. Oracle GoldenGate replica il valore delle colonne ID periodo e transazioni SYSTEM_TIME. È necessario assicurarsi che l'istanza di database disponga dell'autorizzazione di esecuzione per eseguire la stored procedure sul lato di applicazione.

Oracle GoldenGate non è in grado di rilevare e risolvere i conflitti durante l'utilizzo della replica predefinita come periodo SYSTEM_TIME e le colonne transactionstart id rimangono generate automaticamente. Queste colonne non possono essere specificate nelle clausole set e where. Se si utilizza il parametro SUPPRESSTEMPORALUPDATES, Oracle GoldenGate supporta CDR.