Preparazione tabelle per l'elaborazione

Gli attributi della tabella riportati di seguito devono essere risolti in un ambiente Oracle GoldenGate.

Disabilitazione dei trigger e dei vincoli in cascata

Disabilitare i trigger, applicare vincoli di eliminazione a catena e applicare vincoli di aggiornamento a catena alle tabelle Sybase di destinazione oppure modificarli per ignorare le modifiche apportate dall'utente del database Oracle GoldenGate. 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.

  1. Viene emessa un'eliminazione per emp_src.

  2. Viene applicata un'eliminazione a salary_src.

  3. Oracle GoldenGate invia entrambe le eliminazioni alla destinazione.

  4. L'eliminazione padre arriva per prima e viene applicata a emp_targ.

  5. L'eliminazione padre applica un'eliminazione a catena a salary_targ.

  6. L'eliminazione a catena da salary_src viene applicata a salary_targ.

  7. Impossibile individuare la riga perché è già stata eliminata nel passo 5.

Per configurare Replicat per disabilitare i trigger di destinazione all'inizio della sessione del database, effettuare le operazioni riportate di seguito.

  1. Assegnare all'utente Replicat il ruolo di replica.

  2. Aggiungere la seguente istruzione di parametro al livello radice del file dei parametri Replicat.

SQLEXEC "set triggers off"

Assegnazione di identificativi riga

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.

Limitazione delle modifiche alle righe nelle tabelle che non dispongono di una chiave

Se una tabella di destinazione non dispone di chiave primaria o univoca, possono esistere righe duplicate. È possibile che Oracle GoldenGate aggiorni o elimini troppe righe nella tabella di destinazione, facendo uscire dalla sincronizzazione i dati di origine e destinazione senza messaggi di errore per avvisare l'utente. Per limitare il numero di righe aggiornate, utilizzare il parametro DBOPTIONS con l'opzione LIMITROWS nel file dei parametri Replicat. LIMITROWS può aumentare le prestazioni di Oracle GoldenGate nel sistema di destinazione perché viene elaborata una sola riga.

Replica dei dati cifrati

Oracle GoldenGate supporta le colonne cifrate con una password cifrata dal sistema, ma non le colonne cifrate con una password definita dall'utente. Controllare le tabelle da cui si desidera acquisire i dati rispetto alle limitazioni di Oracle GoldenGate riportate di seguito.

Le colonne cifrate vengono cifrate nei file di dati e nel log, pertanto Extract deve essere configurato per recuperare i valori di testo in chiaro dal database. Per attivare questo recupero, utilizzare le opzioni FETCHCOLS e FETCHMODCOLS[EXCEPT] del parametro Extract TABLE. FETCHCOLS forza un recupero di valori non presenti nel log e FETCHMODCOLS o FETCHMODCOLS[EXCEPT] forza un recupero di valori presenti nei log. Utilizzati insieme, questi parametri garantiscono che le colonne cifrate vengano sempre recuperate dal database.

Di seguito è riportato un esempio di configurazione di Extract per supportare la cifratura. In questo esempio, la colonna cifrata è cardnum.

TABLE ab.payments, FETCHCOLS (cardnum), FETCHMODCOLS (cardnum);

Preparazione dei log delle transazioni

Per acquisire le operazioni DML, Oracle GoldenGate legge i log in linea. Per garantire la continuità e l'integrità dell'elaborazione Oracle GoldenGate, i log devono essere configurati come indicato nelle sezioni riportate di seguito.

Inizializzazione del punto di troncamento secondario

Stabilire un punto di troncamento del log secondario nel sistema di origine prima di eseguire il processo Extract di Oracle GoldenGate. Extract utilizza il punto di troncamento secondario per identificare i dati che devono essere elaborati.

Per inizializzare il punto di troncamento secondario, eseguire il login al database come utente con privilegi sa_role, quindi eseguire il comando seguente:

dbcc settrunc( 'ltm', valid )

Per impostazione predefinita, Extract gestirà il punto di troncamento secondario una volta stabilito. Non permettere l'arresto di Extract più a lungo del necessario; altrimenti il log potrebbe eventualmente riempirsi e il database si fermerà. L'unico modo per risolvere questo problema è disabilitare il punto di troncamento secondario e gestirlo al di fuori di Oracle GoldenGate, quindi rimuovere il log delle transazioni. I dati non ancora elaborati da Extract andranno persi e sarà necessario risincronizzare i dati di origine e di destinazione.

Per controllare la modalità di gestione del punto di troncamento secondario, utilizzare il parametro TRANLOGOPTIONS. Per ulteriori informazioni, vedere Riferimento per Oracle GoldenGate per Windows e UNIX.

Dimensionamento e conservazione dei log

Conserva un numero sufficiente di dati di log nel sistema di origine in modo che Extract possa iniziare di nuovo dai suoi checkpoint dopo averlo arrestato o dopo un'indisponibilità non pianificata. Extract deve avere accesso al log che contiene l'inizio dell'unità di lavoro meno recente non impegnata e tutti i log successivi. Per determinare dove si trovano i checkpoint Extract, utilizzare il comando INFO EXTRACT. Per ulteriori informazioni su INFO EXTRACT, vedere Riferimento per Oracle GoldenGate per Windows e UNIX.

Se i dati di cui Extract ha bisogno durante l'elaborazione non vengono conservati, nei log online o di backup, potrebbe essere necessaria una delle azioni correttive seguenti:

Accertarsi di non utilizzare le opzioni di backup o archivio che facciano sì che i vecchi file di archivio vengano sovrascritti dai nuovi backup nel sistema di origine. I nuovi backup devono essere file separati con nomi diversi da quelli precedenti. Ciò garantisce che se Extract cerca un determinato log, esso continuerà ad esistere e garantisce anche che i dati siano disponibili nel caso in cui siano necessari per un caso di supporto.

Abilitazione della funzione di logging delle transazioni

Utilizzare il comando ADD TRANDATA per contrassegnare ogni tabella di origine per la replica. Questo comando utilizza le procedure di sistema Sybase sp_setreptable e sp_setrepcol. ADD TRANDATA è il modo consigliato per contrassegnare le tabelle, invece di utilizzare tali procedure tramite l'interfaccia del database, ma il proprietario o l'amministratore di sistema possono utilizzarle se necessario. Per ulteriori informazioni, consultare la documentazione di Sybase.

Per contrassegnare le tabelle per la replica con ADD TRANDATA:

Eseguire il comando ADD TRANDATA per ogni tabella da contrassegnare. La sintassi del comando ADD TRANDATA è la seguente:

ADD TRANDATA SCHEMA.TABLE LOBSNEVER | LOBSALWAYS | LOBSALWAYSNOINDEX | LOBSIFCHANGED

LOBSNEVER | LOBSALWAYS | LOBSALWAYSNOINDEX | LOBSIFCHANGED controlla se i dati LOB non vengono mai propagati, solo se modificati (impostazione predefinita) o sempre propagati. LOBSIFCHANGED è il valore predefinito se non viene specificata alcuna opzione LOB. Il comando ADD TRANDATA sovrascriverà l'impostazione di replica LOB attualmente impostata per la tabella.

Nota: alcune opzioni ADD TRANDATA abilitano l'opzione ALWAYS_REPLICATE di sp_setrepcol. Se una colonna LOB contiene un valore NULL e un'altra colonna della tabella viene aggiornata (ma non LOB), tale valore LOB non verrà acquisito anche se ALWAYS_REPLICATE è abilitato.