In this example we will apply patch 17284368 on JDBC thin driver 11g.
1. Download p17284368_112040_Generic.zip from My Oracle Support.
2. Extract downloaded patch into /u01/swtmp directory.
3. Make a backup copy of the existing “ojdbc5.jar” file.
4. Copy the file “ojdbc5.jar” used by your application to the directory /u01/swtmp/17284368/files/jdbc/lib/ojdbc5.jar/.
5. Patch ojdbc5.jar
$ cd /u01/swtmp/17284368/files/jdbc/lib/ojdbc5.jar/ $ jar uvf ojdbc5.jar *
6. Copy the patched “ojdbc5.jar” file to your test environment.
Please note that, Opatch is the recommended path to apply JDBC patches on production environments. Using this manual method is for testing purposes only.
JDBC 11g thin clients are not able to connect to the database over SCAN and NAT. JDBC OCI and SQLPLUS connections work fine. JDBC connections to local listener work fine, only connections to SCAN listener fail.
For visibility, I will use sql developer with 11g JDBC thin driver. Actually, the problem happens on all applications using that version of JDBC.
Cause:
SQL*Plus and OCI clients use a redirect count to inform the SCAN listener about a redirected connection, but JDBC 11g and below use a lower version of NS , which does not keep a redirect count and connections are rejected.
Solution:
There are several solutions:
1. Upgrade to JDBC 12C 2. Apply Patch 17284368 to the JDBC Thin Driver
The first option may not be acceptable for you, because it requires some changes on application side. Let’s describe how to apply patch to the JDBC thin driver:
1. Download and unzip patch file on database node(s):
$ unzip p17284368_112040_Generic.zip
2. Apply patch on db node(s):
$ cd 17284368/ $ $ORACLE_HOME/OPatch/opatch apply
Oracle Interim Patch Installer version 11.2.0.3.20 Copyright (c) 2019, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/11.2.0/dbhome_1 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/11.2.0/dbhome_1/oraInst.loc OPatch version : 11.2.0.3.20 OUI version : 11.2.0.4.0 Log file location : /u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/opatch2019-02-22_20-26-57PM_1.log Verifying environment and performing prerequisite checks… OPatch continues with these patches: 17284368 Do you want to proceed? [y|n] y User Responded with: Y All checks passed. Problem with accessing response file of "/u01/app/oracle/product/11.2.0/dbhome_1/ccr/bin/setupCCR". Backing up files… Applying interim patch '17284368' to OH '/u01/app/oracle/product/11.2.0/dbhome_1' Patching component oracle.dbjava.ic, 11.2.0.4.0… Patching component oracle.dbjava.jdbc, 11.2.0.4.0… Patch 17284368 successfully applied. Log file location: /u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/opatch2019-02-22_20-26-57PM_1.log OPatch succeeded.
3. Copy patched $ORACLE_HOME/jdbc/lib/ojdbc5.jar to client side.
4. Restart the application:
Instead of patching database side and then copying patched ojdbc to client side, you can manually patch ojdbc thin driver without touching database.
Please consider that, manual method is for testing purposes only and is explained in the next post.
“If you’re confused as to why Oracle skipped 6 releases, it may be simpler to regard Oracle Database 18c as Oracle Database 12c Release 2 12.2.0.2, where Oracle simply changed the naming to reflect the year in which the product is released.
Oracle Database 18c is the first version of the product to follow a yearly release pattern. “
OPatchauto session is initiated at Wed Feb 6 00:44:30 2019 System initialization log file is /u01/app/18.3.0/grid/cfgtoollogs/opatchautodb/systemconfig2019-02-06_12-44-32AM.log.
Session log file is /u01/app/18.3.0/grid/cfgtoollogs/opatchauto/opatchauto2019-02-06_12-49-13AM.log
The id for this session is WRHH OPATCHAUTO-72043: Patch collection failed. OPATCHAUTO-72043: Failed to create bundle patch object. OPATCHAUTO-72043: Please verify the patch supplied. OPatchAuto failed.
Solution:
Ensure unzip of the patch as grid home owner before running opatchauto from root user.
As a workaround, execute the below command as the <grid home owner> to fix the file permissions on unzipped patch location and re-run opatchauto from root user.
I wanted to check if our customer had an issue with network access. I asked him to run telnet command, but because of their security reasons, telnet rpm was not installed at all.
Solution:
One of the solution would be to run nc 🙂 but of course nc was not installed. 🙂
The following command helped me in that situation:
cat < /dev/tcp/192.168.3.4/3260
The port is open if there is no output, but if you receive the following, then the port is closed:
