Prepara i log delle transazioni Db2 z/OS per Oracle GoldenGate

Informazioni sulla configurazione del log delle transazioni Db2 per supportare l'acquisizione dei dati da parte di Oracle GoldenGate Extract.

Oracle GoldenGate può acquisire i dati delle transazioni Db2 dai log attivi e archiviati. Seguire queste linee guida per configurare i log in modo che Extract possa acquisire i dati.

Per abilitare l'acquisizione delle modifiche per Oracle GoldenGate per Db2 z/OS, vedere Abilita TRANDATA per i database non Oracle

Abilita accesso a record di log

Attivare Db2 Monitor Trace Classe 1 ("TRACE(MONITOR) CLASS(1)") in modo che Db2 consenta a Extract di leggere il log attivo. La destinazione predefinita di OPX è sufficiente perché Oracle GoldenGate non utilizza una destinazione.

Per avviare manualmente il trace

Accedere a Db2 come utente Db2 con il privilegio TRACE o almeno l'autorità SYSOPR.
Eseguire il comando seguente:

start trace(monitor) class(1) scope(group)

Per avviare automaticamente la traccia all'avvio di Db2

Effettuare una delle operazioni riportate di seguito.

Impostare MONITOR TRACE su "YES" nel pannello di trace dell'installazione DSNTIPN.
Impostare 'DSN6SYSP MON=YES' nel job di installazione DSNTIJUZ, come descritto nel manuale Db2 UDB Installation Guide.

Nota: anche l'ID autorizzazione principale, o uno degli ID autorizzazione secondari, dell'esecutore piano ODBC deve disporre del privilegio MONITOR2.

Dimensioni e conserva log

Vengono registrati più dati quando le tabelle sono definite con DATA CAPTURE CHANGES rispetto a quando sono definite con DATA CAPTURE NONE. Se una delle condizioni riportate di seguito è vera, potrebbe essere necessario aumentare il numero e la dimensione dei log attivi e archiviati.

Le applicazioni generano grandi quantità di dati Db2.
Le applicazioni dispongono di commit non frequenti.
Si prevede di interrompere l'estrazione per lunghi periodi.
La tua rete è inaffidabile o lenta.

Utilizzare il parametro di sistema DSN6LOGP MAXARCH nel job di installazione DSNTIJUZ per controllare la conservazione dei log.

Conserva un numero sufficiente di dati di log 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 senza commit e tutti i log successivi.

Se i dati necessari per Extract durante l'elaborazione non vengono conservati, nei log online o archiviati, potrebbe essere necessaria una delle azioni correttive seguenti:

Modifica Extract per l'acquisizione da un point-in-time successivo per il quale sono disponibili i dati di log (e accetta la possibile perdita di dati sulla destinazione).
Risincronizzare le tabelle di origine e di destinazione, quindi riavviare l'ambiente Oracle GoldenGate. Nota: la documentazione IBM fornisce suggerimenti per migliorare le prestazioni delle letture dei log. In particolare, è possibile utilizzare buffer di output di log di grandi dimensioni, log attivi di grandi dimensioni e creare archivi su disco.

Utilizzare i log di archivio su nastro

Oracle GoldenGate è in grado di leggere i log degli archivi Db2 su nastro, che riducono le prestazioni. Ad esempio, Db2 riserva gli archivi registrati per un singolo task di recupero, il che significa che Extract non è in grado di leggere un nastro di archivio utilizzato per recuperare una tabella fino al completamento del recupero. È possibile utilizzare DFHSM o uno strumento equivalente per spostare senza problemi i log di archivio tra lo storage DASD online e il nastro, ma Extract dovrà attendere il completamento del trasferimento. I ritardi nell'elaborazione Extract aumentano la latenza tra i dati di origine e di destinazione.

Se Oracle GoldenGate Extract può o verrà letto dal nastro, dal nastro fisico o dal nastro virtuale, si consiglia di assicurarsi che vengano considerati i seguenti elementi ZPARMs:

NON DISPONIBILE

Il parametro del sottosistema DEALLCT determina il periodo di tempo durante il quale un'unità nastro di lettura dell'archivio deve rimanere inutilizzata prima di essere deallocata.

Aggiornamento: opzione 43 sul pannello DSNTIPB

DSNZPxxx: DSN6LOGP DEALLCT

Oracle consiglia di impostare DEALLCT su 0, 1 (1 secondo di ritardo di disallocazione). L'impostazione predefinita prevede la disallocazione immediata. Ciò impedirà a Db2 di riallocare immediatamente un nastro tra le letture di Extract.

MASSIMO

Il parametro del sottosistema MAXRTU specifica il numero massimo di unità nastro dedicate che possono essere allocate ai volumi del nastro di log di archivio letti contemporaneamente.

Aggiornamento: opzione 43 sul pannello DSNTIPB

DSNZPxxx: DSN6LOGP MAXRTU

Il valore predefinito è 2 unità nastro, ma deve essere impostato sul numero di processi previsti che possono essere letti contemporaneamente da tape+1. Ad esempio, se esistono 4 estrazioni e altre 2 applicazioni che possono essere lette da nastri, MAXRTU deve essere almeno 7 (4 + 2 + 1).

Per ottimizzare le prestazioni e ridurre i ritardi durante la lettura da nastro, Oracle GoldenGate Extract deve utilizzare:

TRANLOGOPTIONS BUFSIZE 33554432

Questa sarà un'indicazione per estrarre per leggere fino a 32 MB alla volta dal log delle transazioni, invece del valore predefinito di 1 MB per lettura. Questa impostazione non aumenterà le allocazioni di memoria utilizzate da Oracle GoldenGate su z/OS, ECSA (64 byte) o memoria condivisa a 64 bit (1 MB). Le allocazioni di memoria transitorie Db2 possono aumentare mentre Extract legge i buffer di grandi dimensioni.

Inoltre, nel file dei parametri Extract, prima del parametro DBLOGIN, è possibile utilizzare anche quanto segue per fornire la possibilità di ottimizzare ulteriormente il buffering di comunicazione TCP del driver Db2. Ad esempio:

SETENV(DB2SOSNDBUF='524288')
SETENV(DB2SORCVBUF='524288')

In questo modo si informa il driver Db2 di utilizzare 512KB per i buffer di invio e ricezione. Altri valori potrebbero essere utilizzati e sarebbero configurabili per ogni installazione.

Cancellazioni log di controllo

Quando si legge il log delle transazioni, Extract non elabora una transazione finché non acquisisce il record di commit. Se il record di commit si trova in un blocco di dati non completo, non sarà possibile acquisirlo finché non verrà generata un'attività di log maggiore per completare il blocco. L'API utilizzata da Extract per leggere i log recupera solo blocchi di dati fisici completi.

Un ritardo nella ricezione di blocchi contenenti commit può causare latenza tra i dati di origine e di destinazione. Se le applicazioni non generano un numero sufficiente di record di log per riempire un blocco, Extract genera record di log emettendo istruzioni SAVEPOINT e COMMIT fino a quando il blocco non si riempie in un modo o nell'altro e viene rilasciato.

In un gruppo di condivisione dati, ogni chiamata API fa sì che Db2 svuoti i blocchi di dati di tutti i membri attivi, eliminando la necessità che Extract esegua svuotamenti.

Per evitare che Extract esegua svuotamenti, utilizzare il parametro Extract TRANLOGOPTIONS con l'opzione NOFLUSH.