La sauvegarde DB2 échoue avec SQL2071N « /usr/lib/libnsrdb2.so ». Code du motif : "2"

Les sauvegardes DB2 échouent avec l’erreur suivante après la mise à niveau de la base de données de V10.5 vers V11.5

Error:

DB2 backup fails with SQL2071N "/usr/lib/libnsrdb2.so". Reason code: "2"

DB2DIAG journaux présentent l’erreur suivante.

2025-01-13-20.16.25.864739+060 E79273449E571         LEVEL: Error (OS)
PID     : 29019                TID : 139807381163456 PROC : db2vend (db2logmgr.meth1 - 267 (
INSTANCE: db2prd               NODE : 000
HOSTNAME: labhostPRD-00
FUNCTION: DB2 UDB, oper system services, sqloLoadModule, probe:191
CALLED  : OS, -, dlopen
DATA #1 : Library name or path, 21 bytes
/usr/lib/libnsrdb2.so
DATA #2 : shared library load flags, PD_TYPE_LOAD_FLAGS, 4 bytes
0
DATA #3 : String, 92 bytes
/usr/lib/nsr/apps/lib64/libssl.so.1.1: undefined symbol: EVP_idea_cbc, version OPENSSL_1_1_0
 
2025-01-13-20.16.25.864904+060 I79274021E462         LEVEL: Error
PID     : 29019                TID : 139807381163456 PROC : db2vend (db2logmgr.meth1 - 267 (
INSTANCE: db2prd               NODE : 000
HOSTNAME: labhostPRD-00
FUNCTION: DB2 UDB, database utilities, sqluFencedVendorProcessCB::loadLibrary, probe:104
MESSAGE : ZRC=0x870F009B=-2029059941=SQLO_MOD_LOAD_FAILED
          "Dynamic library load failed."
DATA #1 : String, 21 bytes
/usr/lib/libnsrdb2.so

Si OpenSSL version 3 est installé sur le système.
Le processus db2vend s’appuie uniquement sur la version 3 d’OpenSSL, mais le processus libnsrdb2 charge la version 1 d’OpenSSL présente dans NMDA

Chemin d’accès OpenSSL du système d’exploitation : /usr/lib64/
Chemin d’accès OpenSSL NMDA : /usr/lib/nsr/apps/lib64/

Vous trouverez ci-dessous l’extrait d’un hôte qui ne fonctionne pas.

Deux processus db2vend

labhostPRD-00:(/root)(root)#ps -ef | grep db2vend | grep -v grep
db2prd   23876 23452  0 Feb05 ?        00:00:00 db2vend (PD Vendor Process - 1) 0
db2prd   24856 23452  0 Feb11 ?        00:00:04 db2vend (db2logmgr.meth1 - 27 (PRD)) 0

Le premier db2vend avec PID 23876 charge OpenSSL V3 à partir du chemin OpenSSL du système d’exploitation

labhostPRD-00:(/root)(root)#lsof -p 23876 | grep -E "lib(ssl|crypto)"
db2vend 23876 db2prd DEL    REG    8,4           51527190 /usr/lib64/libcrypto.so.3.1.4
db2vend 23876 db2prd DEL    REG    8,4           51527189 /usr/lib64/libcrypto.so.1.1
db2vend 23876 db2prd DEL    REG    8,4           51784225 /usr/lib64/libssl.so.3.1.4

Le deuxième db2vend avec PID 24856 charge OpenSSL V1 à partir du chemin OpenSSL NMDA (/usr/lib/nsr/apps/lib64/libssl.so.1.1) et du chemin OpenSSL du système d’exploitation

labhostPRD-00:(/root)(root)#lsof -p 24856 | grep -E "lib(ssl|crypto)"
db2vend 24856 db2prd mem    REG    8,4    721456 50354171 /usr/lib/nsr/apps/lib64/libssl.so.1.1
db2vend 24856 db2prd mem    REG    8,4   5715664 50354411 /usr/lib64/libcrypto.so.3.1.4
db2vend 24856 db2prd mem    REG    8,4   3924472 50360290 /usr/lib64/libcrypto.so.1.1
db2vend 24856 db2prd mem    REG    8,4    743784 50354413 /usr/lib64/libssl.so.3.1.4

La confusion ci-dessus de la version d’OpenSSL est la cause de l’erreur.
NMDA OpenSSL version 1 is compiled with "IDEA encryption algorithm for EVP" but OS OpenSSL Version 1 are not.

1. Ce problème est résolu dans NMDA 19.12, NMDA livré avec OpenSSL V3.
2. La désinstallation d’OpenSSL version 3 serait très probablement utile, car db2vend serait alors forcé de charger les bibliothèques de systèmes d’exploitation libssl.so.1.1 et libcrypto.so.1.1, et par conséquent, l’initialisation de l’interface du fournisseur n’aurait pas besoin de charger les bibliothèques distribuées avec le NMDA
3. Solution de contournement : La variable d’environnement DB2 utilisée comme solution de contournement pour forcer le /usr/lib/nsr/apps/lib64/ à l’aide du document IBM suivant.  DB2LIBPATH [ibm.com]