The question I have is why does Oracle SQL developer does not require Oracle client installed on local?? I searched on the internet and found that it makes use of JDBC thin driver. Can someone please throw some light on this topic?
The Oracle thin driver is a so-called JDBC Type 4 driver, which is implemented purely in Java without native dependencies (.dll/.so), and has a full implementation of the Oracle wire protocol. In other words the thin driver does not require the Oracle client installed, as it doesn't use it.
There are also JDBC Type 2 drivers which do use native dependencies; Oracle has a Type 2 driver as well which is known as the Oracle JDBC OCI driver. This driver uses a JDBC url that is prefixed with jdbc:oracle:oci:.
The Type 1 and Type 3 drivers I ignore because they are hardly relevant these days.
Related
I have a standalone 3rd party application working with Oracle database and I need to troubleshoot its DB queries. And I don't have access to its source code (nor desire to decompile it :-) ).
Its DB connection configuration has several separate parameters:
Driver: oracle.jdbc.OracleDriver
JDBC URL: jdbc:oracle:thin:#localhost:1521:orcl
User name & password
But I can't change driver as application is checking for a list of supported drivers and just refuse to start if I put com.p6spy.engine.spy.P6SpyDriver into the driver parameter.
So can p6spy still be used in this case? If not, is there any other way to trace application DB access from application's end (I'm aware of Oracle tracing, that would be my next step if this won't work)?
Many thanks!
You can use P6Spy in Datasource way
We are migrating applications from Websphere 8.5.5.2 to 8.5.5.11 with JDK 8.
We connecting 3 different databases Oracle,DB2,Sybase and currently using following drivers for the same.
DB2: db2jcc.jar,db2jcc_license_cu.jar,db2jcc_license_cisuz.jar
Oracle: ojdbc14.jar
Sybase:jconn4.jar
Dose this drivers will support JDK 8 or do we need to use different version of jars. We are bale to connect DB with this jars in WAS-8.5.5.11 but does this cause any connection issues when load was high.
To support Java-8 with Db2 jdbc , it is best to use a recent version of the Db2-driver files, at least higher than V10.5-fixpack7 or higher.
To learn which jdbc-driver-version gets supplied with which Db2-client version, check here. You can download latest drivers from that page (IBM registration required).
Looking at various Oracle doc (cited below) it looks like you should plan to move up to a newer version of the Oracle JDBC driver for Java 8.
Regarding ojdbc14.jar which you were using, Oracle documentation states that it is for JDK 1.4 and JDK 1.5
On the Oracle JDBC faq, under the section titled "What are the Oracle JDBC releases versus JDK versions?" it indicates to use ojdbc6, ojdbc7, or ojdbc8 with Java 8 depending on which Oracle database version you have.
What is the combination of driver and jdbc URL to use for CDH5 (I am on CDH5.3)?
I have tried a few including:
jdbc:hive2://myserver:21050/;auth=noSasl
And with the following driver:
org.apache.hive.jdbc.HiveDriver
I have added
/opt/cloudera/parcels/CDH/lib/impala/lib/*:/opt/cloudera/parcels/CDH/lib/hive/lib/*
to the classpath (but still no success)
The result is:
java.sql.SQLException: No suitable driver found for jdbc:hive2://myserver:20150/;auth=noSasl
Firstly, make sure you're using the correct driver. You should use the Impala JDBC driver (rather than the Hive driver).
Then you should be able to use the com.cloudera.impala.jdbc3.Driver driver with a connection string like: jdbc:impala://host:21050
The Impala JDBC driver guide has more details and examples.
Our java applications will access legacy mainframe db2 databases.
I remember in my previous projects, C++ applications required db2 binding before deployment.
In current projects, all mainframe applications, Cobol packages are also required to do db2 binding.
Does a java application that uses jdbc4 driver needs db2 binding too?
If you are using standard JDBC you are creating dynamic SQL (PrepareStatement) that do not requires binding in DB2 side.
However, if you use SQLj, you will need to 'precompile' that code to generate you .java files and another file to bind in the database.
It does not matter if you are connecting to a mainframe (system z or i) or to a DB2 LUW. The concept is the same for all platforms as DB2 is DB2.
SQLj is not very popular, however is very powerful to tune your queries and improve the data access, however, as you used to do in C, the code has to be developped in more phases, and you have to rebind each time the access plan has to be modified (new statisques, security, etc.)
SQLj is very easy to use from Data Studio, and SQLj from DB2 is not exactly the same from Oracle.
The JDBC type IV driver, supplied by IBM, will handle everything you need to do.
The driver maps Java objects into DB2 appropriately.
I don't know what "binding" means in this context. Java is not C++.
If your DB2 version supports Dynamic Statement Caching and enabled (consult your DBA’s), you can use JDBC Type-4 driver to access mainframe DB2 database (use prepare statement) without binding.
DB2 will generate access paths and store it in first request into cache. Otherwise, you need use SQLJ like technologies and bind them.
I am trying to understand the difference between XA vs Non XA JDBC datasource. Also how do I know which type and version of JDBC dtriver is used. I am currently on 10.3 weblogic and trying some tet to kill long running queries using setQueryTimeout, which isnt seem to be reliable with OracleXADataSource as it is only working the first time and not always.
Sorry for this basic question but I am new to Weblogic Datasource configuration
Thanks
XA jdbc drivers are used to implement two-phase commit, meaning the two remote resources are part of the same transaction. Java specifies an implementation of this via JTA. A good reading is e.g. http://www.javaworld.com/javaworld/jw-07-2000/jw-0714-transaction.html; if you google for 'xa jdbc driver' you'll find plenty more info.
You should not use the XA driver if not necessary. I remember reading that there are some problems with them.
To identify JDBC driver your WLS is using, go to the <domain_dir>/config/jdbc and open the data souce file, check the driver-name value in the file.
To identify the Driver version, check from which .jar is the driver being loaded (run the WLS with -verbose:class)- the name of the jar will contain the version number. Also, you can use java -jar my-jdbc-file.jar which will print the driver version. The OJDBC drivers are usually stored in a file named ojdbc6.jar or ojdbc7.jar, etc.