Préparation des journaux de transactions z/OS Db2 pour Oracle GoldenGate

Découvrez comment configurer la journalisation des transactions Db2 pour prendre en charge la capture de données par l'extraction Oracle GoldenGate.

Oracle GoldenGate peut capturer les données de transaction Db2 à partir des fichiers de journalisation actifs et archivés. Suivez ces instructions pour configurer les journaux afin que le processus Extract puisse capturer des données.

Afin d'activer la capture des modifications pour Oracle GoldenGate pour Db2 z/OS, reportez-vous à Activation de TRANDATA pour les bases de données non-Oracle

Activer l'accès aux enregistrements de journal

Activez la classe de trace 1 de surveillance Db2 ("TRACE(MONITOR) CLASS(1)") afin que Db2 autorise le processus Extract à lire le journal actif. La destination par défaut de OPX est suffisante car Oracle GoldenGate n'utilise pas de destination.

Démarrage manuel de la trace

Connectez-vous à Db2 en tant qu'utilisateur Db2 disposant du privilège TRACE ou au moins de l'autorité SYSOPR.
Lancez la commande suivante :

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

Démarrage automatique de la trace lors du démarrage de Db2

Effectuez l'une des opérations suivantes :

Définissez MONITOR TRACE sur "YES" dans le panneau de trace de l'installation DSNTIPN.
Définissez 'DSN6SYSP MON=YES' dans le travail d'installation DSNTIJUZ, comme décrit dans le Guide d'installation UDB Db2.

Remarque : l'ID d'autorisation principal ou l'un des ID d'autorisation secondaires de l'exécuteur de plan ODBC doit également disposer du privilège MONITOR2.

Taille et conservation des journaux

Plus de données sont consignées lorsque les tables sont définies avec DATA CAPTURE CHANGES que lorsqu'elles sont définies avec DATA CAPTURE NONE. Si l'une des conditions suivantes est remplie, vous devrez peut-être augmenter le nombre et la taille des journaux actifs et archivés.

Vos applications génèrent de grandes quantités de données Db2.
Vos applications ont des validations peu fréquentes.
Vous prévoyez d'arrêter l'extraction pendant de longues périodes.
Votre réseau est peu fiable ou lent.

Utilisez le paramètre système DSN6LOGP MAXARCH dans le travail d'installation DSNTIJUZ pour contrôler la conservation des journaux.

Conservez suffisamment de données de journal pour que le processus Extract puisse recommencer à partir de ses points de reprise après l'avoir arrêté ou après une interruption non planifiée. Le processus Extract doit avoir accès au journal qui contient le début de la plus ancienne unité de travail non validée et à tous les journaux qui suivent.

Si les données dont l'extraction a besoin pendant le traitement n'ont pas été conservées, que ce soit dans les journaux en ligne ou archivés, l'une des actions correctives suivantes peut être requise :

Modifiez le processus Extract pour effectuer une capture à partir d'un point ultérieur pour lequel des données de journal sont disponibles (et acceptez d'éventuelles pertes de données sur la cible).
Resynchronisez les tables source et cible, puis redémarrez l'environnement Oracle GoldenGate. Remarque : la documentation IBM formule des recommandations pour améliorer les performances des lectures de journal. En particulier, vous pouvez utiliser des tampons de sortie de journal volumineux, des journaux actifs volumineux et créer des archives sur le disque.

Utiliser les journaux d'archivage sur bande

Oracle GoldenGate peut lire les fichiers de journalisation archivés Db2 sur bande, ce qui dégrade les performances. Par exemple, Db2 réserve les archives enregistrées pour une seule tâche de récupération, ce qui empêche le processus Extract de lire une bande d'archive utilisée pour récupérer une table tant que la récupération n'est pas terminée. Vous pouvez utiliser DFHSM ou un outil équivalent pour déplacer les fichiers de journalisation archivés de manière transparente entre le stockage DASD en ligne et la bande, mais le processus Extract devra attendre la fin du transfert. Les retards dans le traitement Extract augmentent la latence entre les données source et cible.

Si l'extraction Oracle GoldenGate peut ou va lire à partir d'une bande, d'une bande physique ou d'une bande virtuelle, il est fortement recommandé de s'assurer que les éléments ZPARMs suivants sont pris en compte :

AFFECTÉ

Le paramètre de sous-système DEALLCT détermine la durée pendant laquelle une unité de bande de lecture d'archive doit être autorisée à rester inutilisée avant d'être libérée.

Mise à jour : option 43 sur le panneau DSNTIPB

DSNZPxxx: DSN6LOGP DEALLCT

Oracle recommande de définir DEALLCT sur 0, 1 (1 seconde de délai de libération). La valeur par défaut est de désallouer immédiatement. Cela empêche Db2 de réallouer immédiatement une bande entre les lectures de l'extraction.

MAXRTU

Le paramètre de sous-système MAXRTU spécifie le nombre maximal d'unités de bande dédiées pouvant être allouées à des volumes de bande de journal d'archivage lus simultanément.

Mise à jour : option 43 sur le panneau DSNTIPB

DSNZPxxx: DSN6LOGP MAXRTU

La valeur par défaut est 2 unités de bande, mais elle doit être définie sur le nombre de processus attendus pouvant être lus simultanément à partir de tape+1. Par exemple, si 4 extractions et 2 autres applications peuvent lire à partir de bandes, MAXRTU doit être au moins égal à 7 (4 + 2 + 1).

Pour des performances optimales et des retards minimes lors de la lecture à partir d'une bande, le processus Extract Oracle GoldenGate doit utiliser :

TRANLOGOPTIONS BUFSIZE 33554432

Cela indiquera au processus Extract de lire jusqu'à 32 Mo à la fois à partir du journal des transactions, au lieu de la valeur par défaut de 1 Mo par lecture. Ce paramètre n'augmentera pas les allocations de mémoire qu'Oracle GoldenGate utilise sur z/OS, qu'il s'agisse d'ECSA (64 octets) ou de mémoire partagée 64 bits (1 Mo). Les allocations de mémoire non persistantes Db2 peuvent augmenter pendant que le processus Extract lit les tampons volumineux.

En outre, dans le fichier de paramètres d'extraction, avant le paramètre DBLOGIN, les éléments suivants peuvent également être utilisés pour fournir la possibilité de régler davantage la mise en mémoire tampon de communication TCP du pilote Db2. Exemple :

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

Le pilote Db2 est alors informé de l'utilisation de 512 ko pour les tampons d'envoi et de réception. D'autres valeurs peuvent être utilisées et peuvent être réglées pour chaque installation.

Vidages du journal de contrôle

Lors de la lecture du journal des transactions, l'extraction ne traite pas une transaction tant qu'elle n'a pas capturé l'enregistrement de validation. Si l'enregistrement de validation se trouve sur un bloc de données qui n'est pas plein, il ne peut pas être capturé tant qu'une activité de journal supplémentaire n'est pas générée pour terminer le bloc. L'API utilisée par Extract pour lire les journaux extrait uniquement les blocs de données physiques complets.

Un retard dans la réception de blocs contenant des validations peut entraîner une latence entre les données source et cible. Si les applications ne génèrent pas suffisamment d'enregistrements de journal pour remplir un bloc, le processus Extract génère des enregistrements de journal en émettant des instructions SAVEPOINT et COMMIT jusqu'à ce que le bloc se remplisse d'une manière ou d'une autre et soit libéré.

Dans un groupe de partage de données, chaque appel d'API entraîne le vidage des blocs de données de tous les membres actifs par Db2, éliminant ainsi la nécessité pour le processus Extract d'effectuer des vidages.

Pour empêcher l'extraction d'effectuer des vidages, utilisez le paramètre d'extraction TRANLOGOPTIONS avec l'option NOFLUSH.