Manually Apply a One-Off Patch to the JDBC Thin Driver

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 THIN CONNECTIONS OVER SCAN AND NAT FAIL WITH ORA-12516

Problem:

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.

Oracle Database 18c: why Oracle skipped 6 releases?

“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. “

https://blogs.oracle.com/database/oracle-database-18c-:-now-available-on-the-oracle-cloud-and-oracle-engineered-systems

Oracle DB Support Roadmap 2019

Exadata Performance Diagnostics with AWR

” The contents of this paper apply to all Exadata deployments – whether onpremises, Public Cloud, or Cloud at Customer “

https://www.oracle.com/technetwork/database/exadata/exadata-awr-5100655.pdf

OPATCHAUTO-72043: Failed to create bundle patch object.

Problem:

Applying Patch Set Update (PSU) to Grid Infrastructure Home results in OPATCHAUTO-72043 error.

# /u01/app/18.3.0/grid/OPatch/opatchauto apply /u01/swtmp/28659165/ -nonrolling

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.

chmod -R 775 <unzipped patch location>

Check if a port on a remote system is reachable (without telnet)

Problem:

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:

-bash: connect: Connection refused
-bash: /dev/tcp/192.168.3.4/3261: Connection refused