Still, it would be great if this specific requirement could be added to the Db2 upgrade procedure in the Knowledge Centre, as one does not (and cannot very easily) scan the IBM technotes when planning for a Db2 upgrade, so it can be easily missed (as it was in my case).
Original Message:
Sent: Tue February 10, 2026 11:07 AM
From: Matthew Emmerton
Subject: Db2 using S3 storage for REMOTE STORAGE
This is the right process, and it's even documented by a technote:
https://www.ibm.com/support/pages/db2start-fails-after-linux-os-upgrade
------------------------------
Matthew Emmerton
Db2 Development
Original Message:
Sent: Tue February 10, 2026 10:59 AM
From: Damir Wilder
Subject: Db2 using S3 storage for REMOTE STORAGE
Hi Ian,
You are absolutely right in your assesment, the libaws* libraries are indeed still linked to the wrong (old) version of the OS (RHEL8.1, just as you've shown above, except that I'm missing the "kinesis" library... probably don't need it then...), which is (most likely) why they don't want to work on RHEL9.
The way you described the fix to the issue is pretty much identical to that in the IBM Support case which I had already posted in this thread (https://www.ibm.com/support/pages/node/7180669), so I'm now doubly certain that this would work in my case as well!
The problem, however, is that I still haven't received a word from the IBM Support (having an open case on the subject), giving me an official confirmation that this would be the right way to fix the issue (probably need to talk to them a bit more so that they understand my situation better...).
Finally, it would be really-really nice if IBM could add this as an extra requirement (or prerequisite, or post-installation check, take your pick) into the Db2 upgrade procedure in the Db2 docs formerly known as the Db2 Knowledge Centre, which we all love and always consult as a single source of truth when we want to do things to our Db2 environments!
Regards, Damir
------------------------------
Damir Wilder
Senior Consultant
Triton Consulting
London
Original Message:
Sent: Tue February 10, 2026 10:04 AM
From: Ian Bjorhovde
Subject: Db2 using S3 storage for REMOTE STORAGE
Damir,
When Db2 is installed, the Db2 installer creates soft links in <INSTALLPATH>/lib64 that point to the correct versions of the various libaws* files.
Take a look at INSTALLPATH/lib64/libaws* on your system - you should see something like this:
$ ls -al /opt/ibm/db2/V11.5/lib64/libaws-cpp-sdk-*
lrwxrwxrwx 1 root root 38 Sep 12 22:42 /opt/ibm/db2/V11.5/lib64/libaws-cpp-sdk-core.so -> awssdk/RHEL/8.1/libaws-cpp-sdk-core.so
lrwxrwxrwx 1 root root 41 Sep 12 22:42 /opt/ibm/db2/V11.5/lib64/libaws-cpp-sdk-kinesis.so -> awssdk/RHEL/8.1/libaws-cpp-sdk-kinesis.so
lrwxrwxrwx 1 root root 36 Sep 12 22:42 /opt/ibm/db2/V11.5/lib64/libaws-cpp-sdk-s3.so -> awssdk/RHEL/8.1/libaws-cpp-sdk-s3.so
lrwxrwxrwx 1 root root 42 Sep 12 22:42 /opt/ibm/db2/V11.5/lib64/libaws-cpp-sdk-transfer.so -> awssdk/RHEL/8.1/libaws-cpp-sdk-transfer.so
If you look in to the directory INSTALLPATH/lib64/awssdk, you'll see that there are multiple versions of the libraries for different versions of RHEL, SLES, and Ubuntu.
When you upgrade the server (from RHEL8 to RHEL9, for example), you'll find that these links are pointed at the wrong version of the libraries.
To resolve, you have to manually (as root) remove the links and then re-create the links manually. This can not be done by db2iupdt.
For example, if I were to upgrade my OS from RHEL8 to RHEL9, I would have to run the following commands (again, as root):
cd /opt/ibm/db2/V11.5/lib64
rm -f libaws*
ln -s awssdk/RHEL/9.2/libaws*
Hope this helps.
------------------------------
Ian Bjorhovde
XTIVIA
Original Message:
Sent: Mon February 09, 2026 02:15 PM
From: Damir Wilder
Subject: Db2 using S3 storage for REMOTE STORAGE
Hi Malek,
Thanks for your response.
It seems like the version of the OS might be the issue here (I'm investigating this further), I have just stumbled upon this IBM Support article that describes a very similar situation to mine:
https://www.ibm.com/support/pages/node/7180669
Please find below the output of the commands, as you requested (note, the 1st command did not work, the file libdb2CosApiS3_RHEL9.so does not exist on this server):
ldd ~/sqllib/lib/libdb2CosApiS3_RHEL9.so
ldd: /home/db2inst1/sqllib/lib/libdb2CosApiS3_RHEL9.so: No such file or directory
ls -al ~/sqllib/lib/libdb2CosApiS3*
lrwxrwxrwx. 1 root root 19 Nov 22 2021 /home/db2inst1/sqllib/lib/libdb2CosApiS3.so -> libdb2CosApiS3.so.1
-r-xr-xr-x. 1 bin bin 252400 Nov 15 2024 /home/db2inst1/sqllib/lib/libdb2CosApiS3.so.1
ldd /opt/ibm/db2/V12.1/lib64/awssdk/RHEL/9.2/libaws-cpp-sdk-core.so
linux-vdso.so.1 (0x00007fff1ed78000)
libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f982c360000)
libz.so.1 => /lib64/libz.so.1 (0x00007f982c346000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f982b800000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f982b400000)
libm.so.6 => /lib64/libm.so.6 (0x00007f982c26b000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f982c251000)
libc.so.6 => /lib64/libc.so.6 (0x00007f982b000000)
/lib64/ld-linux-x86-64.so.2 (0x00007f982c40a000)
libnghttp2.so.14 => /lib64/libnghttp2.so.14 (0x00007f982c225000)
libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f982bddf000)
libssh.so.4 => /lib64/libssh.so.4 (0x00007f982bd6a000)
libpsl.so.5 => /lib64/libpsl.so.5 (0x00007f982bd56000)
libssl.so.3 => /lib64/libssl.so.3 (0x00007f982b71a000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f982b6c4000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f982b326000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f982bd3d000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f982c21c000)
libldap.so.2 => /lib64/libldap.so.2 (0x00007f982b65e000)
liblber.so.2 => /lib64/liblber.so.2 (0x00007f982bd2c000)
libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f982bd1c000)
libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f982ae7b000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f982b64d000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f982b646000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f982b632000)
libevent-2.1.so.7 => /lib64/libevent-2.1.so.7 (0x00007f982b2cd000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f982b2ad000)
libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f982b28a000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f982b25d000)
libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f982b223000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f982addf000)
Kind regards, Damir
------------------------------
Damir Wilder
Senior Consultant
Triton Consulting
London
Original Message:
Sent: Sun February 08, 2026 05:16 PM
From: malek shabou
Subject: Db2 using S3 storage for REMOTE STORAGE
Hi Damir,
can you post the output (run with instance used) of:
ldd ~/sqllib/lib/libdb2CosApiS3_RHEL9.so
and (change the path to DBB2 binary)
ldd /opt/ibm/db2/V12.1/lib64/awssdk/RHEL/9.2/libaws-cpp-sdk-core.so
Malek,
------------------------------
malek shabou
Original Message:
Sent: Sun February 08, 2026 04:35 AM
From: Damir Wilder
Subject: Db2 using S3 storage for REMOTE STORAGE
Hi All,
Just wondering if anyone out there is also using the Db2 COS feature (Cloud Object Storage) to enable direct log archiving (via LOGARCHMETH) to a remote (Cloud) storage such as the AWS S3?
And, if you have been using this feature, have you attempted any Db2 upgrades along the way, which also required the upgrade of the operating system as a prerequisite?
How did this work out for you?
I have just attempted the above - upgrade Db2 from v11.5.7 to v12.1.3, which required the OS upgrade from RHEL8.1 to RHEL9.6, and this resulted in the broken COS client (by the looks of it), with the following error messages in the db2diag.log:
FUNCTION: DB2 UDB, oper system services, sqloRemStgList, probe:1139
MESSAGE : ZRC=0x870F00B7=-2029059913=SQLO_UNSUPPORTED
"Operation is unsupported."
...
DATA #3 : String, 26 bytes
COS Client is unavailable
Not much else (in terms of useful info) is present in the db2diag.log, so I'm wondering if my problem is somehow related to the OS upgrade and if there are any extra steps to be taken to remedy the problem (there is nothing in the DB2 Knowledge Centre that would suggest any such actions, that I can see)?
Needless to say, but here it is anyway: the REMOTE STORAGE worked flawlessly for several years prior to this DB2/OS upgrade.
Has anyone had any experience with something like this - and if yes, how did you get out of it?
Kind regards, Damir
------------------------------
Damir Wilder
Senior Consultant
Triton Consulting
London
------------------------------