Correction des paramètres de Db2 configuration incorrects après une mise à niveau

Pour certaines versions Data Gate antérieures, les paramètres de configuration de la base de Db2 données cible ne sont pas correctement migrés lors de la mise à niveau d'une Data Gate instance. Si tel est le cas, vous devez corriger manuellement les paramètres de la base de données cible.

A propos de cette tâche

Vous avez installé et provisionné une Data Gate instance dans Cloud Pak for Data la version 4.7, 4.8, ou 5.0 et vous avez récemment effectué une mise à niveau vers une version plus Data Gate récente dans Cloud Pak for Data5.0.x ou 5.1.0.

Cependant, les paramètres de configuration de la base de Db2 données cible n'ont pas été correctement migrés lors de la mise à niveau.

Les paramètres Db2 de configuration appliqués lors de la mise à niveau sont différents des paramètres qui étaient utilisés avec l'ancienne Data Gate instance.

De plus, la nouvelle version nécessite davantage de paramètres pour la base de Db2 données cible, et certaines des valeurs supplémentaires ne sont pas définies lors de la mise à niveau et sont donc absentes de la configuration.

Vous pourriez rencontrer une ou plusieurs des situations suivantes après la Data Gate mise à niveau :

DB2_SELECTIVITY n'est pas défini, ce qui entraîne l'échec du chargement des tables. Le message d'erreur suivant s'affiche :

[AQT10050E]
Impossible de charger les tables. Une erreur interne s'est produite sur l'accélérateur « <data-gate-instance-name> » 
Par Db2Data Gate exemple : ODBC l'opération SQLExecDirect a échoué avec le code -1 lors de l'exécution 
instruction : /* IBM_DWA */ CREATE OR REPLACE VIEW... OÙ « DWA_Partition_ID (masqué) » 
<= 0 SÉLECTIVITÉ 1 : <Diagnostics> <SQLSTATE>428E5</SQLSTATE> <SQLCODE>-20046</SQLCODE> 
<Tokens num="1"> <Token>n_ID (masqué)" <= 0 </Token> </Tokens> 
<Message>[ IBM ][Pilote CLI][ DB2/LINUXZ64 ] Clause SQL20046N SELECTIVITY suivant « n_ID (masqué) » 
<= 0 » ne peut être spécifié que pour un prédicat valide défini par l'utilisateur. 
SQLSTATE=428E5</Message> </Diagnostics>

DB2LOCK_TO_RB n'est pas défini sur STATEMENT, ce qui a l'effet suivant : les requêtes effectuées sur la base de Db2 données cible renvoient des résultats différents de ceux renvoyés par la même requête effectuée sur la base de Db2 for z/OS données source.
PAGE_AGE_TRGT_MCR, DB2MAXFSCRSEARCH, DB2_SELECTIVITY, DB2_STATISTICS, ou DB2_APPENDERS_PER_PAGE sont définis sur des valeurs incorrectes. Il en résulte une dégradation des performances en termes de chargement des tables, de vitesse de réplication des modifications de lignes et de vitesse d'exécution des requêtes dans la base de Db2 données cible.
DB2_WAITFORDATA_LIBNAME est défini sur une valeur incorrecte ou vide. Cela provoque l'échec des requêtes sur la base de Db2données cible.

Procédure

À partir de la ligne de commande du Cloud Pak for Data système sur lequel votre Data Gate instance est installée, déterminez l'instance de base de Db2 données cible utilisée par Data Gate l'instance :
```
oc get datagateinstanceservice | awk '{print $1 " " $7}'
```
Cette commande renvoie le nom Data Gate de l'instance et le nom de la base de données cible, par exemple :
```
NAME TARGET_DATABASE
dg1730137307043920 db2oltp-1713769437245949
```
Déterminez le pod de Db2 base de données cible à l'aide de la TARGET_DATABASE valeur renvoyée par la commande précédente :
```
❯ oc get pods | grep db2oltp-1713769437245949
```
Le nom du pod de la base de données cible est renvoyé. Par exemple :
```
c-db2oltp-1713769437245949-db2u-0 1/1 Course à pied 1 38d
c-db2oltp-1713769437245949-etcd-0 1/1 Course à pied 1 38d
```

Ouvrez un shell dans le pod de Db2 base de données cible, par exemple :

oc exec -it c-db2oltp-1713769437245949-db2u-0 bash

Cette commande est confirmée par un message similaire à celui-ci :

Conteneur par défaut « db2u » hors de : db2u, init-labels (init), init-kernel (init)
[db2uadm@c-db2oltp-1713769437245949-db2u-0 /]$

À l'intérieur du conteneur, exécutez les commandes suivantes pour accéder au dossier Data GateDb2 de configuration. Exemple où db2inst1 est le nom de l'instance de base de données cible :
```
su - db2inst1
cd /mnt/blumeta0/home/db2inst1/config_db2u
```
Toujours dans la coque du conteneur, exécutez les scripts appropriés pour votre base de données cible :
- Pour une base de Db2 données cible :
```
./db_cfg_row_store.sh
./db2set_dg.sh
```
- Pour une base de Db2 Warehouse données cible :
```
./dbm_cfg_analytics.sh
./db_cfg_analytics.sh
./db2set_analytics.sh
```
Toujours à l'intérieur de la coque du conteneur, redémarrez votre base de données cible :
```
./restart_db2.sh
```
Pour vérifier les paramètres ajustés, exécutez les commandes suivantes :
```
db2set
db2 get db cfg for bludb
db2 get dbm cfg
```
Comparez les résultats affichés à l'écran avec les valeurs des deux tableaux dans Modifications apportées à la base de données cible et assurez-vous que les valeurs correspondent.
(Mise à niveau Data Gate vers 5.1.3 et base de données cible à partir d'une version antérieure à 11.5.6.0 ) : Si vous effectuez une mise à niveau Data Gate vers la version 5.1.3 et votre base de données cible ( Db2 ou Db2 Warehouse ) à partir d'une version antérieure à 11.5.6.0 vers une version plus récente, vous devez également appliquer le paramètre suivant dans Db2 ou Db2 Warehouse :
```
oc get datagateinstanceservice | awk '{print $1 " " $7}'
```
Cette commande renvoie le nom Data Gate de l'instance et le nom de la base de données cible, par exemple :
```
NOM TARGET_DATABASE
dg1730137307043920 db2oltp-1713769437245949
```
Déterminez le pod de Db2 base de données cible à l'aide de la TARGET_DATABASE valeur renvoyée par la commande précédente :
```
oc get pods | grep db2oltp-1713769437245949
```
Le nom du pod de la base de données cible est renvoyé. Par exemple :
```
c-db2oltp-1713769437245949-db2u-0 1/1 Course à pied 1 38d
c-db2oltp-1713769437245949-etcd-0 1/1 Course à pied 1 38d
```

Ouvrez un shell dans le pod de Db2 base de données cible, par exemple :

oc exec -it c-db2oltp-1713769437245949-db2u-0 bash

Cette commande est confirmée par un message similaire à celui-ci :

Conteneur par défaut « db2u » hors de : db2u, init-labels (init), init-kernel (init)
[db2uadm@c-db2oltp-1713769437245949-db2u-0 /]$

Déterminez le pod de Db2 base de données cible à l'aide de la TARGET_DATABASE valeur renvoyée par la commande précédente :
```
oc get pods | grep db2oltp-1713769437245949
```
Le nom du pod de la base de données cible est renvoyé. Par exemple :
```
c-db2oltp-1713769437245949-db2u-0 1/1 Course à pied 1 38d
c-db2oltp-1713769437245949-etcd-0 1/1 Course à pied 1 38d
```

À l'intérieur du conteneur, exécutez les commandes suivantes pour accéder au dossier Data GateDb2 de configuration. Exemple où db2inst1 est le nom de l'instance de base de données cible :

su - db2inst1
cd /mnt/blumeta0/home/db2inst1/config_db2u
db2set DB2_WAITFORDATA_LIBNAME=/mnt/blumeta0/home/db2inst1/config_db2u/waitfordata/libs/libwaitForDataSharedLib.so
libpath="$(db2set | grep DB2LIBPATH | awk -F'=' '{print $2}')"

Si le libpath est vide, alors :

db2set DB2LIBPATH=/mnt/blumeta0/home/db2inst1/config_db2u/waitfordata/libs

si le chemin d'accès à la bibliothèque n'est pas vide :

db2set DB2LIBPATH="/mnt/blumeta0/home/db2inst1/config_db2u/waitfordata/libs:${libpath}"

Vous pouvez vérifier si ce qui précède a fonctionné en :

db2set -tout

et vérifiez les valeurs de DB2_WAITFORDATA_LIBNAME et DB2LIBPATH.