Comments on: Analysing Statspack 12

By: Jonathan Lewis

Jonathan Lewis — Sun, 09 Jun 2013 11:55:34 +0000

Peter,

It’s not my comment, it’s Timur’s. He is, however, one of the Oracle specialists I would tend to put in the category of “probably correct until shown otherwise”.

It certainly makes sense to me that a null pl/sql block could be faster than a query; and it makes sense to me that you won’t find any other reference to this as a strategy – after all, someone has to be the first to suggest a new method, and end-users often come up with clever ideas while the Oracle manuals (and the authors that copy them) are very slow to change their suggestions.

By: Peter

Peter — Sat, 27 Apr 2013 14:31:44 +0000

Jonathan,
I’m interested in your comment about ‘select 1 from dual’ in jdbc applications. We have such an app using Tomcat connection pooling, and AWR reports show ‘select 1 from dual’ being executed millions of times per hour. This is what is used as the jdbc validation query. Although an inexpensive query, when executed many millions times it does consume cpu and is responsible for significant soft parsing. Are you suggesting that we can improve the situation by replacing ‘select 1 from dual’ with ‘begin null; end;’? From some basic (non-java) tests i can see that running millions of ‘select 1 from dual’ in a loop is significantly slower then millions of ‘begin null; end;’ Am I missing something here? Your suggestion seems like a huge improvement, yet I can find no other reference to using this as a validation query.
I’m interested to hear what you have to say.
Thanks,
Peter

By: Jonathan Lewis

Jonathan Lewis — Sat, 17 Apr 2010 10:58:59 +0000

Timur,

Thanks for adding all these details.

By: Timur Akhmadeev

Timur Akhmadeev — Thu, 15 Apr 2010 08:13:16 +0000

Jonathan, to be clear: objects in "Segments by global cache buffer busy" and JAVA_XA package are not related. Mentioned tables/indexes are used by the application - and no matter what kind of connectivity to Oracle it uses, the objects and it's usage pattern suggests that the application will not work well in RAC without taking additional steps. JMS_MESSAGES and JMS_TRANSACTIONS are JBoss MQ service tables (for ACID-ing JMS transactions). SQL queries from the link match SQLs in AWR (and there are DDLs for tables). JMS_TRANSACTION has no indexes (by default) - possibly developers were thinking it will be small enough and/or they were saving some space. Chances are high that it requires an index (maybe globally hash-partitioned) with increased PCTFREE on table, or table should be single-table hash cluster, or hash-partitioned, etc - there are options to decrease 'gc buffer busy'. JMS_MESSAGES has a PK constraint with (I guess) increasing values which most likely the cause of cluster wait time for SQLs accessing the table. JAVA_XA is an internal Oracle package used by JDBC drivers version less then 10g when XA is needed. 10g JDBC Thin driver can do this natively, and as a result faster (this is Oracle claim; I don't have numbers to compare performance). So, the calls to JAVA_XA are coming implicitly from the driver to demarcate transaction boundaries in a distributed environment (DBMS_XA in 11g has similar documented functionality). It is implemented using Oracle JVM - i.e. procedures are simple wrappers for Java methods inside the DB. This can be seen in AWR as 'Java execution elapsed time' - ~13%. Another bad habit of JDBC applications is a query which usually looks like 'select 1 from dual' (SELECT 'x' FROM DUAL in AWR), executed many times. This is a checking query to validate connection - is it alive or not. The fact is 'select 1 from dual' is not the cheapest query for such task (as probably expected by someone), but 'begin null; end;' is. Usually it is a configuration option somewhere in the application configuration for the data source and can be easily modified.