Re: v$sql - executions vs loads vs invalidations
- From: Gerry Miller <gerry@xxxxxxxxxxxxxxxxxxx>
- To: k.sriramkumar@xxxxxxxxx
- Date: Wed, 16 May 2012 08:52:43 +1000
Thanks Sriram
A query has gone back to the vendors about this and we are awaiting a reply.
However, you may have something there with the ODBC driver. I will suggest
it if they come back with no answer.
Regards
Gerry
Sriram Kumar wrote: Hi, What is the client access library(ODBC?). Have seen
asimilar issue where 1=0 was fired by the driver to get the structure of the
table (equivalent of describe) and it was firing before every application's
table based resultset queries. This was not happening for all types of
drivers but i think it was the Microsoft Oracle Driver. The solution at that
time was to evaulate the use of Oracle driver and the problem vanished. Have
not seen the cursor invalidation but the tables were accessed either by
quering the table directly with 1=0 as in this case or querying
ALL_TAB_COLUMNS view with the table name Best Regards Sriram Kumar On Wed,
May 2, 2012 at 1:03 PM, Gerry Miller <gerry@xxxxxxxxxxxxxxxxxxx>[1]wrote: Hi
Norman, The 11g explanation would make sense here. The parse count is 1 for
each query. You are right about the application not using bind variables,
although the WHERE clause is always "WHERE 1=0". Thanks Gerry Norman Dunbar
wrote: Hi Gerry, On 01/05/12 10:41, Gerry Miller wrote: LOADS: 2794
INVALIDATIONS: 2793 EXECUTIONS: 0 How I read this is that this statementwas
loaded 2794 times, invalidated 2793 but never executed, but I think this
opinion may stem from my ignorance. This is one of hundreds of such
statements. The 11g reference manual, is a little helpful on the EXECUTIONS,
it states that this is the number of times that the object was executed
sinceit was *brought into the cache*. So, it looks like your statement
hasn'tbeen executed any time in the last 2794 loads. Invalidation occurs,
forexample, when an underlying table is changed. The application (sounds
nasty!) doesn't do anything like creating and dropping tables in a SQL
Server"temporary table" manner does it? I suspect that PARSE_CALLS will be
about 2794 as well. Sounds to me like one of those applications that doesn't
use binds and always parses. Welcome to my world! :-( Cheers, Norm. --
//www.freelists.org/webpage/oracle-l[2] --
//www.freelists.org/webpage/oracle-l[3]
--- Links ---
1 mailto:gerry@xxxxxxxxxxxxxxxxxxx
2 //www.freelists.org/webpage/oracle-l
3 //www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
