PreparedStatement vs Statement & OCI vs thin

http://www.oreilly.com/catalog/jorajdbc/chapter/ch19.html
came accross this sample chapter from a book which compares Statement vs PreparedStatement vs CallableStatement (and all of the aforementioned using both the thin and OCI drivers for Oracle)
Just wondering if anyone had read the book. It was published in Dec 2001 so the results should be current. If anyone has read it, let me know what you think.
I haven't found many reliable benchmarks for database access, but this one compares only Oracle implementations so I have to assume that it is unbiased. (not the usual "my drivers are better than my competitions - benchmarks to prove it"... then you check out the competition and it says "my drivers are the fastest - benchmarks to prove it!")
Jamie

I haven't read this book, but from other sources and my own experience the basic rules are as follows:
- PreparedStatement is faster then Statement if the SQL statemtn is rather complex and used frequently
- OCI is generally faster than Thin, but requires more setup on the client
as always, these rules have exceptions, and the only way to find out is to try with your program.

Similar Messages

What's the difference between "PreparedStatement" and "Statement"?

What's the difference between "PreparedStatement" and "Statement"?
Which is better??????

Read the docs for the two classes. The differences are apparent there.
Which one is better depends on your needs. I think that constructing and executing a PreparedStatement can be a bit less performant than just a Statement, if you're only executing the query one time. But I don't think that difference will normally be noticable in the context of a given application.
Additionally, if you have to pass any dates or strings to the query, you'll want PreparedStatement's parameters, rather than trying to format and escape things in the query string.

JDBC OCI和JDBC Thin有什么区别?

JDBC OCI和JDBC Thin有什么区别？
效果有什么区别？（都是通过weblogic连db的）

一般来说
OCI效率应该高一些
不过使用的时候一般使用jdbc直接连接
因为OCI不是纯java实现

PreparedStatement vs Statement - When executing only once

Are there any performance implications in using PreparedStatement vs
Statement when you are executing the SQL only once? I am talking about all
kinds of SQL (Select, Update, Insert and Delete). If PrepatedStatement is
used, I would expect some overhead in setting values for different columns
separately and precompliling. Is that overhead significant enough to
degrade performance? If we execute statement only once, I do not expect to
any gain on performance.
I would appreciate any comments.
Sarat

It also depends on the database/driver combination,several database can be
configured to maintain a prepared statement cache at the DB level (I have
never done it myself, but I know people who has done this. Lately I use
mostly Oracle, for which I should not be configured an expert :)).
Also the weblogic's prepared statement cache only caches first so many
statements. If you have used them all up at the startup you are out of luck.
I know you already knew that, but may be helpful to the original poster.
.raja
"Cameron Purdy" <[email protected]> wrote in message
news:[email protected]..
BTW - there is a case where prepped stmts are faster -- when they arecached
by Weblogic's jdbc wrappers. So my previous answer can be wrong.
Peace,
Cameron Purdy
Tangosol Inc.
<< Tangosol Server: How Weblogic applications are customized >>
<< Download now from http://www.tangosol.com/download.jsp >>
"sarat" <[email protected]> wrote in message
news:3b715901$[email protected]..
Are there any performance implications in using PreparedStatement vs
Statement when you are executing the SQL only once? I am talking aboutall
kinds of SQL (Select, Update, Insert and Delete). If PrepatedStatement
is
used, I would expect some overhead in setting values for differentcolumns
separately and precompliling. Is that overhead significant enough to
degrade performance? If we execute statement only once, I do not expectto
any gain on performance.
I would appreciate any comments.
Sarat

PreparedStatement & regular Statement - different results for same select

I was wondering if someone could either
i) try this out for me to confirm my results or
ii) let me know what I am doing wrong
I'm one of the developers on a product and am currently investigating localization for the Thai language...just checking to see that Java and Swing have no problems with it. The only bewildering thing which has happened is noticing that some values which are fetched from the database display in Thai perfectly and other values display as a garble. Sometimes the exact same column is displayed correctly in one part of the program but is not OK in another part. I think I've figured out what it going on and suspect a bug in Oracle's JDBC:
Some selects were configured as PreparedStatements and those return the Thai properly. The more common case however was for programmers to use a simple Statement object for their select and it is in those that the multi-byte strings don't get returned properly.
The following code shows the problem that I am experiencing. I am basically executing the exact same select in 2 different ways and they are both giving different results as long as the column being queried contains a Thai character. If someone could grab and check it out and let me know if they see the same thing, I'd appreciate it. Just change the column/table name and the username/password/databaseIP to get it to run.
<code>
import java.sql.*;
public class SelectTest {
public static void main(String[] args) {
try {
DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
Connection conn = DriverManager.getConnection( "jdbc:oracle:thin:@10.4.31.168:1524:ora8",
"dms_girouard",
"girouard");
String sqlCommand = "select C0620_Title from T0620_SwSheet";
Statement statement = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
ResultSet resultSet1 = statement.executeQuery(sqlCommand);
while (resultSet1.next()) {
if (resultSet1.getString("C0620_Title") != null) {
System.out.println("resultSet1 Title = " + resultSet1.getString("C0620_Title"));
PreparedStatement preparedStatement = conn.prepareStatement(sqlCommand);
ResultSet resultSet2 = preparedStatement.executeQuery();
while (resultSet2.next()) {
if (resultSet2.getString("C0620_Title") != null) {
System.out.println("resultSet2 Title = " + resultSet2.getString("C0620_Title"));
catch (Exception e) {
System.out.println(e.getMessage());
</code>

Hi Peter,
Are you using NCHAR column for Thai , or is your database character set set for Thai.
If you are using a NCHAR column for holding Thai data, then you have to use the
OraclePreparedStatement.setFormOfUse(...) before executing the select.
Regards
Elango. Hi Elangovan,
Thank you for answering.
The datatype on the column is VARCHAR2.
I did my initial tests without doing anything special to make sure the database is localized for Thai, and I was happy to find that almost everything still worked fine - I was able to save and retrieve Thai strings to the database almost perfectly.
The only problem I discovered was the difference between Statement and PreparedStatement selects on a column containing Thai. Colleagues of mine have said they see the same thing when testing on a Oracle database which has been configured specifically for the Thai customer.
I read somewhere that the current JDBC drivers are using an older version of the Unicode standard than the most current version of the Java SDK and that it was causing some problems with Korean. I'm wondering if maybe it's the same problem with Thai.

PreparedStatement and Statement

Hi Joe,
We are using the Driver provided by Weblogic (jdriver) and not the one from
Informix.Do you suggest any settings for this
thanks
Nirmala.

Nirmala,
Which version of Weblogic do you use?
Regards,
Slava Imeshev
"Nirmala" <[email protected]> wrote in message
news:3bcc9ff7$[email protected]..
>
Hi
public void ejbLoad () throws RemoteException, NoSuchEntityException {
Connection connection = null;//JDBC Connection from the pool
PreparedStatement ps = null; // SQL query statement
Statement statement = null;
ResultSet rs = null; // JDBC result set
try {
// Obtain a connection from the connection pool.
ID = (String) context.getPrimaryKey ();
connection = DatabaseHelper.getConnection ();
// Our SQL query.
// Make sure to upshift the user id.
String sqlQuery =
"SELECT * from customer WHERE id= ?";
long startTime = System.currentTimeMillis();
ps = connection.prepareStatement(sqlQuery);
ps.setString(1,ID.toUpperCase());
// Read the customer data from the database.
rs = ps.executeQuery ();
long endTime = System.currentTimeMillis();
long total = endTime -startTime;
System.out.println("total time taken1 " +CISSLogger.getTimeInSeconds(total));
>
>
// rs = ps.getResultSet();
Above is the snippet of the code we are using in ejbLoad,
Appreciate your suggestion
thanks
Nirmala.
"Slava Imeshev" <[email protected]> wrote:
Hi Nirmala,
Could you give us a fragment of your code that uses PreparedStatement?
Regards,
Slava Imeshev
"Nirmala" <[email protected]> wrote in message
news:3bcc8772$[email protected]..
Hi Joe,
We are using the Driver provided by Weblogic (jdriver) and not theone
from
Informix.Do you suggest any settings for this
thanks
Nirmala.

Session Timezone differences between JDBC OCI and Thin drivers

Hi,
I was having a problem with a default on a DATE column of CURRENT_DATE with my Websphere/Oracle web application, when I discovered that the Thin JDBC driver behaves differently from the OCI JDBC driver in regards to the session timezone.
The Thin driver defaults the sesssion timezone to GMT (+0.00), but the OCI driver defaults to whatever the local OS timezone is (in my case GMT+12.00).
Can anyone tell me how why this difference is there how to correct the behaviour of the Thin driver?
I'm using the standard JDBC Connection class, not the OracleConnection object, and therefore cannot use the setSessionTimeZone method.
The only solution I can currently think of is to move the application over to the OCI driver, however, I'm wondering what else is different (ie we'll have to regression test the whole web app again!).
Any ideas?
Cheers,
Dunc

Well, regarding the time zone thing, it appears the following code will solve a lot of headaches...
((OracleConnection)conn).setSessionTimeZone
(TimeZone.getDefault().getID());
Still unknown why the OCI driver appears to do this automatically, while the thin driver does not.
If anyone knows the status of the memory leaks in the Linux OCI, please let me know.
Thanks,
m@

OCI vs THIN

For production environment it has been recommended that we use OCI driver.
Based on the oracle JDBC guide, with 10g there is not much difference in the two drivers in terms of capability.
We would like to know is there any documentation/links/whitepapers on the above? Is there any data proving that OCI performs better than THIN driver?
What are you using for your production JDBC driver? Have you had a chance to compare the two before making the decision?
Thanks,
Rumpa Giri

I agree with Joe Weinstein. I have seen this book several times in the bookstore and I have elected not to purchase it, as it is much too outdated. It would be great if O’Reilly would publish a new edition of this book that is updated for Java Programming with Oracle JDBC for the Oracle 11g database. A lot has changed with Oracle and with java since that 2001. Did Object Relational Mapping (read hibernate) even exist in 2001?
Also, I really wish that when writing a book such as this, the author would make clear which version of the jdbc driver is being used, e.g. ojdbc14.jar version 10.2.0.1 . This can make a big difference!
Interestingly enough, I did see a presentation recently at the Oracle headquarters where one of Oracle's employees alluded to the idea that BEA would be moving to doing more with the JDBC OCI driver.
Doesn't the Oracle thin driver have the same exposure to occasional bugs? Maybe the bug would not be in the native OCI libraries, but I would be curious to know how much exposure there is to potential Oracle bugs in the JDBC OCI interface vs. the jdbc thin driver.

OCI vs. thin driver

I have a need to make a connection with Oracle's OCI driver instead of the thin driver. My current code reads as follows:
String serverURL = "jdbc:oracle:thin:@myServer:1521:myDb"
DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
Connection con = DriverManager.getConnection(serverURL, "myName", "myPassword");
Can someone tell me what it should look like to use the OCI driver?
Any help would be great?
Thanks

Thanks so much for the reply.
That's actually what I had tried, but when it didn't work and with me not being overly experienced with connections, I assumed I had it wrong. So the problem I am experiencing exists somewhere else.
Again, thanks

Statement vs PreparedStatements which is better in which situation

Hi i read in a few forums and a few articles that PreparedStatement object performs better than the Statement object in situations where a high number of the same sqls are used because it precompiles the sql statement. such as inserting a 1000 employees into a table.
i did the following test and found that the gain for using PreparedStatements is sometimes not a gain but a loss.
What the test basically does is that it inserts an item into the table a 2000 times using both PreparedStatements and Statement objects. And it switches between which object it uses to insert item into the table. So in the end 1000 items would have been inserted using PreparedStatements and 1000 using Statement objects.
Am i doing somthing wrong with my test or is the so called gain by using PreparedStatements a fluke. Please advise.
import java.sql.*;
public class TEST {
    static int Prepcount = 1;
    static long PreptotalTime = 0;
    static long PrepstartTime = 0;
    static long PrependTime = 0;
    static long Prepavarage = 0;
    static int Stmtcount = 1;
    static long StmttotalTime = 0;
    static long StmtstartTime = 0;
    static long StmtendTime = 0;
    static long Stmtavarage = 0;
    static PreparedStatement pst;
    static Statement stmt;
    static ResultSet rs;
    static Connection conn;
    public static void usePrep() {
        try {
            pst = conn.prepareStatement("insert into Dhanu values (?,?)");
            PrepstartTime = System.currentTimeMillis();
            pst.setInt(1, Prepcount);
            pst.setInt(2, Prepcount);
            pst.executeQuery();
            PrependTime = System.currentTimeMillis();
            PreptotalTime = PreptotalTime + (PrependTime - PrepstartTime);
            Prepavarage = PreptotalTime / Prepcount;
            Prepcount++;
            pst.close();
        } catch (Exception e) {
            e.printStackTrace();
    public static void useStatement() {
        try {
            StmtstartTime = System.currentTimeMillis();
            stmt = conn.createStatement();
            rs = stmt.executeQuery("insert into Dhanu values ("+Stmtcount+","+Stmtcount+")");
            StmtendTime = System.currentTimeMillis();
            StmttotalTime = StmttotalTime + (StmtendTime - StmtstartTime);
            Stmtavarage = StmttotalTime / Stmtcount;
            Stmtcount++;
            rs.close();
            stmt.close();
        } catch (Exception e) {
            e.printStackTrace();
    public static void main(String[] args) {
        try {
            Class.forName("oracle.jdbc.driver.OracleDriver").newInstance();
            conn = DriverManager.getConnection("jdbc:oracle:thin:@XXX.XXX.XXX.XXX:1521:XXX", "XXX", "XXX");
            System.out.println("Connected to DB");
            conn.setAutoCommit(true);
            for(int x=1;x<=2000;x++){
                if(x%100==0){
                   System.out.println("Count is "+x);
                if(x%2==0){
                    usePrep();
                }else
                    useStatement();
            System.out.println("Prepcount " + Prepcount + " Prepavarage " + Prepavarage + " CurrentExecution " +(PrependTime - PrepstartTime)+ " Totaltime "+PreptotalTime);
            System.out.println("Stmtcount " + Stmtcount + " Stmtavarage " + Stmtavarage+ " CurrentExecution " +(StmtendTime - StmtstartTime)+ " Totaltime "+StmttotalTime);
            System.err.println("Statement time - Prep Time " + (StmttotalTime - PreptotalTime ));
        } catch (Exception ex) {
            ex.printStackTrace();
            System.exit(0);
}

sjasja wrote:
There can still be a performance advantage to PS's even when not used in a loop. Oracle in particular has a textual statement cache. When you execute
insert into foo values(1);
insert into foo values(2);
insert into foo values(3);
the three statements are textually different, so they get re-parsed and the query optimizer runs thrice. But when you prepare
insert into foo values(?);
the parsed and optimized statement remains in the statement cache for some time, and each execution with a different value for "?" can use the pre-parsed statement. The more complex the statement, the bigger the advantage.Yes they do, and so do many others. But it is only that, a cache. It will "usually" be available, not necessarily always. But, in any case, it is still best practice to prepare it, use it multiple times, and close it.
>
I have heard rumors of databases (MSSQL???) where a PS is indeed costlier, as the protocol between the JDBC driver and the DB server requires a separate compilation step. One could argue that in this world, where Java is so important in the server side, and the other advantages of PreparedStatement favor its use, any serious database has had much reason in the last decade to implement a protocol where a separate compilation step is not needed, and any other speed penalties for PSs are decidedly not a marketing advantage.One could argue that, and many have, but PreparedStatements did not spring into being with JDBC, they have existed previously. They are easier to use, however, in Java, and some sort or precompilation is required (even if it is only done the first time the statement is actually run) because at some point in time the DB must determine the paths to take when actually executing the statement, and that was the purpose behind precompiled statements in the first place, so that that determination is done once, and used multiple times. Otherwise it is done as the statement is executed, each time a statement is executed (unless, at least in Oracle, the same statement is still in the statement cache, then it is also reused, rather than redetermined).

Difference Between Thin and OCI drivers

Hi,
Can anyone tell me what the difference is between the OCI and thin JDBC drivers. Or point me to some documentation.
Why would you use the thin driver over using the OCI driver??
Thanks for any help.
Steve

- The thin driver is easier to deploy, since you don't need any Oracle software installed on the client.
- The OCI driver will have slightly more functionality than the thin driver because it's able to leverage the Oracle client.
- If you're doing a lot of data retrieval (lots of bits over the wire), the OCI driver will tend to be faster.
- If you're not retrieving a lot of data, the thin driver may be faster, since the OCI driver incurs a context switch when it goes to make OCI calls via JNI.
Justin

Statement vs PreparedStatement

Can anyone offer guidelines ( or point me to documentation) which describes when/why use a
Statement as opposed to a PreparedStatement.
I realize that a PreparedStatement can be defined with Bind variables for later substitution and thus the statement gets compiled only once thereby being more efficient.
But is that the only difference ? does it make sense to use a PreparedStatement even if there are no Bind variables ?

Whenever you want to re-use a statement you should use Statement and not PreparedStatement.
Statements can effectively only be used once, since you provide the SQL text to the execute method: this means that when issuing execute (or executeQuery) the statement is always fully reparsed by the database.
If you have a PreparedStatement object, you can re-execute it, and the database will reuse the parsed statement.

OCI & thin drivers

I am using Oracle8i and I find two drivers are available for usage in JDBC applications: OCI8 and thin
What is the distinction between OCI and thin dirvers?
To which type of dirver does these two belong to?
When should I use which dirver?
A detailed explation would be appreciated.
Thanks in Advance.
RP

The OCI driver requires an Oracle client install on the same machine while the thin driver does not. If you cannot install additional files on the client computer (such as using an applet) you have to use the thin diver.
The OCI driver is slightly faster since a portion of it is written in C. It also supports things such as Oracle object types and PL/SQL tables while the thin driver does not.

XMLType inputstream on OCI client

Hi all, I have a problem using XMLType.createXML in java to create a XMLType to use as parameter in a stored procedure using OCI client (it works with thin client).
my environment (sorry if I missed something!):
Oracle db 11.1 on server, Java 1.6 and OCI client 11.1 on Windows on client.
In my Eclipse project I included the following jars:
\jdbc\lib\ojdbc6.jar
\jlib\orai18n.jar
\RDBMS\jlib\xdb.jar
\LIB\xmlparserv2.jar
the java code snippet for calling the stored procedure using the input stream:
public String putgetXMLInputStream(File testFile) throws SQLException, FileNotFoundException, UnsupportedEncodingException
     // create the input stream from the file containing XML
     InputStream br = new BufferedInputStream(new FileInputStream(testFile));
// this statement was tested with no value for "kind" parameter and with these two value too
     // "oracle.xml.parser.XMLDocument.THICK"
     // "oracle.xml.parser.XMLDocument.THIN"
     XMLType xmlDoc = XMLType.createXML(connection, br);
     // set the statement
     CallableStatement cs;
     cs = connection.prepareCall("{?=call MYPACKAGE.TESTUPLOAD(?)}");
cs.registerOutParameter(1, OracleTypes.VARCHAR);
     cs.setObject(2, xmlDoc);
// execute the statement
     cs.execute();
     // return the string
     return cs.getString(1);
same code with string:
public String putgetXMLString(File testFile) throws SQLException, FileNotFoundException, UnsupportedEncodingException, IOException
     StringBuilder contents = new StringBuilder();
     try {
     //use buffering, reading one line at a time
     //FileReader always assumes default encoding is OK!
     BufferedReader input = new BufferedReader(new FileReader(aFile));
     try {
          String line = null; //not declared within while loop
          * readLine is a bit quirky :
          * it returns the content of a line MINUS the newline.
          * it returns null only for the END of the stream.
          * it returns an empty String if two newlines appear in a row.
          while (( line = input.readLine()) != null){
          contents.append(line);
          contents.append(System.getProperty("line.separator"));
     } finally {
     input.close();
     XMLType xmlDoc = XMLType.createXML(connection, contents.toString());
     // set the statement
     CallableStatement cs;
     cs = connection.prepareCall("{?=call MYPACKAGE.TESTUPLOAD(?)}");
cs.registerOutParameter(1, OracleTypes.VARCHAR);
     cs.setObject(2, xmlDoc);
// execute the statement
     cs.execute();
     // return the string
     return cs.getString(1);
the java code snippet for establish the database connection (I know that with java 1.6 the registerDriver is not
required, I both tested with and without driver registering and it works in the same way):
// connection string: comment as required
// connection string for thin client
// String connectionString = "jdbc:oracle:thin:@mydbserver:1521:mydb";
// connection string for oci
String connectionString = "jdbc:oracle:oci8:@mydbserver:1521:mydb";
DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
Connection conn =DriverManager.getConnection( connectionString, "john", "tiger");
DatabaseMetaData meta = conn.getMetaData();
System.out.println("Driver JDBC: " + meta.getDriverVersion());
The PL/SQL called by java:
FUNCTION TESTUPLOAD (pDoc IN XMLTYPE) RETURN VARCHAR2 IS
msgout VARCHAR2(24000);
doc DBMS_XMLDOM.DOMDocument;
rootnode DBMS_XMLDOM.DOMNode;
fchild DBMS_XMLDOM.DOMNode;
attr1 VARCHAR2(20);
ns VARCHAR2(200);
BEGIN
ns := 'xmlns="http://www.myweb.it/static/xml/def/0.6/ns1.html" xmlns:si="http://www.myweb.it/static/xml/def/0.6/si.html"';
doc := DBMS_XMLDOM.newDOMDocument(pDoc);
rootnode := dbms_xmldom.makeNode(doc);
fchild := DBMS_XMLDOM.GETFIRSTCHILD(rootnode);
-- dom text
DBMS_XMLDOM.WRITETOBUFFER(rootnode, msgout);
-- attribute value
dbms_xslprocessor.valueOf(rootnode,'/DOC/@TYPENO',attr1, ns );
-- node name of rootnode first child
return '(' || attr2 || ' - ' || DBMS_XMLDOM.GETNODENAME(fchild) || ') ' || msgout;
END TESTUPLOAD;
Thus, the expected result is a returned varchar2 containing the value of the attribute as per XPath, the name of first child node
and the whole text of dom.
This work as expected connecting via OCI and Thin client if I create the XML starting from a string, and only with Thin client if
I adopt the input stream approach. If I use the input stream with OCI client, no error message is displayed, and no value are provided
for attribute or fchild name, but the dom text is returned.
I made test with different charset encoding for the original file (UTF-8, ISO-8859-1, with endofline in windows and linux style).
What I noticed is that in case of string and input stream with Thin client some kind of parsing occours: the returned text show some
special characters (i.e. double quote) replaced by html entity and the charset encoding in <?xml tag replaced with ISO-8859-1, more over
the returned xml is well indented.
I'm sure that I'm missing something :-)
Any hints?
TIA
GB
Edited by: user12844059 on 7-mag-2010 6.54

visit the javasoft.com (sun site) for tutorials and training on all of the technologies you mentioned.
after understanding them, then review the oracle java roadmap found on technet.oracle.com --> technologies --> java to get an oracle perspective.
then ask the oracle technology specific questions you have.

Ouput sql from prepared statement

I'm using prepared statements and I want to output the sql that is being run in the statement to the console. For example:
Class.forName("oracle.jdbc.driver.OracleDriver");
conn = DriverManager.getConnection("jdbc:oracle:thin:@xx.xx.x.xx:xxxx:xxxx", "xxxx", "xxxx");
stmt = conn.prepareStatement("update table set a = ? where b = ? and c = ?");
stmt.setString(1, "a");
stmt.setString(2, "b");
stmt.setString(3, "c");
System.out.println(?????????);So the statement would be something like: "update table set a = 'a' where b = 'b' and c = 'c'"
How can I get the sql from the statement? I would have thought this would be easy but there doesn't seem to be any obvious method.

I also came across the article about overpowering the PreparedStatement, neat stuff.
But as I downloaded the classes and compiled them, I got some errors due to the fact that some methods from the PreparedStatement- and Statement-interfaces were not implemented by the DebuggableStatement-class.
I suspect this has something to do with the JDK-version being used.
I myself am using version 1.4.1_01-b01.
Anyone came across this same problem?
As I do want to compile under the version mentioned, I just insert the method(-stubs) myself. Or is this a bad idea?

PreparedStatement vs Statement & OCI vs thin

Similar Messages

Maybe you are looking for