DB2-Backup schlägt mit SQL2071N "/usr/lib/libnsrdb2.so" fehl. Ursachencode: "2"

DB2-Backups schlagen nach dem Upgrade der Datenbank von Version 10.5 auf Version 11.5 mit dem folgenden Fehler fehl:

Error:

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

DB2DIAG Protokolle weisen den folgenden Fehler auf.

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

Wenn OpenSSL Version 3 auf dem System installiert ist.
Der db2vend-Prozess basiert nur auf OpenSSL Version 3, der libnsrdb2-Prozess lädt jedoch die OpenSSL-Version 1, die in NMDA vorhanden ist

OpenSSL-Pfad des Betriebssystems: /usr/lib64/
NMDA OpenSSL-Pfad: /usr/lib/nsr/apps/lib64/

Unten sehen Sie den Codeausschnitt eines nicht funktionierenden Hosts.

Zwei db2vend-Prozesse

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

Erstes db2vend mit PID 23876 lädt OpenSSL V3 vom OpenSSL-Pfad des Betriebssystems

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

Das zweite db2vend mit PID 24856 lädt OpenSSL v1 vom NMDA OpenSSL-Pfad (/usr/lib/nsr/apps/lib64/libssl.so.1.1) und dem OpenSSL-Pfad des Betriebssystems

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

Die obige Verwechslung der OpenSSL-Version ist die Ursache für den Fehler.
NMDA OpenSSL version 1 is compiled with "IDEA encryption algorithm for EVP" but OS OpenSSL Version 1 are not.

1. Dieses Problem wurde in NMDA 19.12 behoben, NMDA wird mit OpenSSL V3 ausgeliefert.
2. Die Deinstallation von OpenSSL Version 3 würde höchstwahrscheinlich helfen, da db2vend dann gezwungen wäre, die Betriebssystembibliotheken libssl.so.1.1 und libcrypto.so.1.1 zu laden, so dass die Initialisierung der Anbieterschnittstelle keine Bibliotheken laden müsste, die mit der NMDA verteilt wurden
3. Problemumgehung: Die DB2-Umgebungsvariable, die als Workaround verwendet wird, um das /usr/lib/nsr/apps/lib64/ unter Verwendung des folgenden IBM-Dokuments.  DB2LIBPATH [ibm.com]