Search

Top 60 Oracle Blogs

Recent comments

JDBC

Oracle & Postgres JDBC Fetch Size

TL;DR — By default PostgreSQL ResultSet is not a server cursor but a client buffer. The whole result is fetched before the first next() call.

It is usually a good idea to start with default settings rather than trying to ‘tune’ any possible parameter. Defaults are often suited to the most common cases. However, there’s a big exception to it when using JDBC drivers: the default fetch size is probably not the right setting. Here is an example with the same Java code to show the fetching behavior in Oracle and PostgreSQL.

Java example

Here is my Java code which is exactly the same for Oracle and PostgresSQL

Easy Oracle Cloud wallet location in the JDBC connection string

I wrote about the 19c easy-connect string recently and the possibility to use a wallet with it (and no need for a tnsnames.ora then):

19c EZCONNECT and Wallet (Easy Connect and External Password File)

That was with sqlplus and setting TNS_ADMIN and still requires sqlnet.ora to set the wallet location directory. This post adds two things:

  • TNS_NAMES parameter in the JDBC URL with no need for
    the java -Doracle.net.tns_admin
  • We can add our password to the cloud wallet downloaded from the Autonomous Database (ATP/ADW)

Oracle Cloud user

For this test I’ve created a new user in my Autonomous Transaction Processing cloud service.

The click-path is:

You should set OCSID.CLIENTID

each time you grab an Oracle JDBC connection from the pool

For troubleshooting and monitoring performance, you want to follow what happens from the end-user to the database. It is then mandatory to identify the end-user and application from the database session. With Oracle there are some ‘dbms_application_info’ strings to be set, like MODULE, ACTION and CLIENT_INFO. That’s about the tasks in the application code (like identifying the Java class or method from which the SQL statement is prepared) but that’s not about the end-user.

Adding JDBC driver property in SQL Developer connecting to MySQL

I suppose you get it there because this kind of error was properly indexed by Google:

Status : Failure -Test failed: The server time zone value 'CEST' is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support.

However, this trick works if you want to add any property to the JDBC URL string when connecting with Oracle SQL Developer, which provides no other way to add properties.

The trick is JDBC URL Injection after the port. When connecting to port 5501 I set the following in the ‘port’ field:

5501/?serverTimezone=UTC#

like this:

which finally will expand to:

Referencing LDAP for JDBC thin client connections….

Just a quick note, to mention something that I just recently discovered.  (Yes, this has been available since at least Oracle 10.1, but I wasn’t aware of it!)

When composing a JDBC thin client connect URL, we have been using something of the form:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOSTNAME=myhost.my.domain)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=mydb)))

This is fine, but if you have a mix of Oracle OCI clients and JDBC thin clients, and if the OCI clients are all configured to use an LDAP server for Net Service Name resolution, then, whenever you make any kind of reconfiguration, you need to update the LDAP server, and then still need to update the hardcoded connection information in the JDBC Thin URL.

However, what i recently discovered, is that it’s possible to define your JDBC Thin URL, thus:

Consultancy

I have a permanent job at the NetCracker‘s System Performance group. Recently I was offered to do one day job outside, on-site in another company, which coincidentally has an office close to NetCracker’s Moscow office. It was an opportunity to apply my skills in a completely different situation which I couldn’t miss; plus I’ve never done public presentations before and this was a good occasion to practice that. Here I’d like to write down some notes how the event went.

When column name matters

There’s a thread on the OTN forum with a case of amusing behavior of the 11.2.0.1 JDBC driver: it fails to detect properly all bind variables in an SQL statement referencing column named NORDER. WTF?! PS. 1) Oracle’s SSO is actually Multi Sign-On because I have two accounts (one for OTN forums and one for [...]