Why Replacing an OJDBC Driver in Oracle Cloud Control Installation is a Bad Idea?

In a previous blog post, I wrote about alert log being flooded with the “TNS-12599: TNS:cryptographic checksum mismatch” error messages. As it turned out, this problem has being caused by older OJDBC drivers (below the version 8) because they don’t handle encryption correctly under some circumstances. In particular, the connections were coming from Oracle Cloud Control Agent 13.4, which still uses OJDBC 7.

In the comments section, it was reported that simply replacing the OJDBC 7 with the version 8 resolved this issue.

But I realized that this would create a much bigger problem.

OJDBC is a jar file, which is, basically, an archive of compiled Java classes. A Cloud Control patch doesn’t need to replace the whole OJDBC file, it can update just a subset of classes instead.

Here’s an example of such a patch:

/export/home/oracle/27350958/files/
find . -name "*.class"
./jdbc/lib/ojdbc8.jar/oracle/net/ns/NIOAcceptPacket.class
./jdbc/lib/ojdbc8_g.jar/oracle/net/ns/NIOAcceptPacket.class
./jdbc/lib/ojdbc8dms.jar/oracle/net/ns/NIOAcceptPacket.class
./jdbc/lib/ojdbc8dms_g.jar/oracle/net/ns/NIOAcceptPacket.class
./oracle.javavm.jrf/12.2.0.1.0/rdbms.jrf.common.symbol/modules/oracle.jdbc/ojdbc8dms_g.jar/oracle/net/ns/NIOAcceptPacket.class
./oracle.javavm.jrf/12.2.0.1.0/rdbms.jrf.common.symbol/modules/oracle.jdbc/ojdbc8.jar/oracle/net/ns/NIOAcceptPacket.class
./oracle.javavm.jrf/12.2.0.1.0/rdbms.jrf.common.symbol/modules/oracle.jdbc/ojdbc8_g.jar/oracle/net/ns/NIOAcceptPacket.class
./oracle.javavm.jrf/12.2.0.1.0/rdbms.jrf.common.symbol/modules/oracle.jdbc/ojdbc8dms.jar/oracle/net/ns/NIOAcceptPacket.class

This patch updates the Java class NIOAcceptPacket in whatever ojdbc8*.jar is in the destination path.

So if you replaced the original OJDBC with something else prior to patching, you would end up with your own unique Frankenstein driver that nobody has ever tested. Consequently, no one would be able to help you in the case of odd issues, which would almost inevitably arise.

In conclusion, don’t be tempted to replace OJDBC drivers in your Cloud Control installation, even when this resolves the primary problem.