V$sqlarea : 34769 rows

Hi expert,
I don't know if this is a problem. But how is possible that the v$sqlarea has 34179 records?
SQL> set timing on
SQL> select count(0) from v$sqlarea;
COUNT(0)
34769
Elapsed: 00:01:20.61i'm finding on oracle documentation and
"V$SQLAREA lists statistics on shared SQL area and contains one row per SQL string. It provides statistics on SQL statements that are in memory, parsed, and ready for execution."
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2129.htm
then there are 34000 sql statment in memory?
where I can find some documentation on this view?
many thanks, as usual.
Cheers,
Lain

Depending on the nature of your application, the size of your SGA, and how well you or your developers use bind variables, the number of statements is perfectly fine or really horrible. Like so many things in Oracle, it depends.
One of our databases has several hundred concurrent users, but they are all using a single application that uses bind variables everywhere and has a fairly limited range of funtionality. It has about 10,000 rows in v$sqlarea. Another database supports a dozen or so concurrent users using many related but different applications most of which have never heard of a bind variable. It has about 60,000 rows, most of them being multiple copies of various sql statements differing only by the literal strings used as predicates.
John

Similar Messages

Bind variable vs. variable....

Hi ,
In the Oracle Master Glossary ... there is the following explanation about bind variable:
A variable in a SQL statement that must be replaced
with a valid value, or the address of a value, in order
for the statement to successfully execute
According to the above .. which is the difference between bind variable and variable....????
Tom Kyte in one , at least, of his book... points out to use the bind variables...not simple variables.
He also proves this using the following example:
tkyte@TKYTE816> set timing on
tkyte@TKYTE816> declare
2 type rc is ref cursor;
3 l_rc rc;
4 l_dummy all_objects.object_name%type;
5 l_start number default dbms_utility.get_time;
6 begin
7 for i in 1 .. 1000
8 loop
9 open l_rc for
10 ʹselect object_name
11 from all_objects
12 where object_id = ʹ || i;
13 fetch l_rc into l_dummy;
14 close l_rc;
15 end loop;
16 dbms_output.put_line
17 ( round( (dbms_utility.get_time‐l_start)/100, 2 ) ||
18 ʹ seconds...ʹ );
19 end;
20 /
14.86 seconds...[[/b]pre]
And using bind variables
tkyte@TKYTE816> declare
2 type rc is ref cursor;
3 l_rc rc;
4 l_dummy all_objects.object_name%type;
5 l_start number default dbms_utility.get_time;
6 begin
7 for i in 1 .. 1000
8 loop
9 open l_rc for
10 ʹselect object_name
11 from all_objects
12 where object_id = :xʹ
13 using i;
14 fetch l_rc into l_dummy;
15 close l_rc;
16 end loop;
17 dbms_output.put_line
18 ( round( (dbms_utility.get_time‐l_start)/100, 2 ) ||
19 ʹ seconds...ʹ );
20 end;
21 /
1.27 seconds...I'm confused as in my PL/SQL programs i do not use of course literal values but 'simple variables' not 'bind variables'....
Should i replace all uses and occurences of 'simple variables' with bind variables...?????
Thanks....a lot
Sim

No need for something as complex as SQL tracing. Simply look in the shared pool. E.g.
SQL> create or replace procedure foo2 is
2 n number := 1;
3 c number;
4 begin
5 select
6 count(*) into c
7 from dept
8 where deptno = n;
9 end;
10 /
Procedure created.
SQL> -- we flush the shared pool and remove cached cursors
SQL> alter system flush shared_pool;
System altered.
SQL> -- is there a cursor in the shared pool using DEPT as our stored proc is using?
SQL> select
2 sql_text
3 from v$sqlarea
4 where sql_text like UPPER('%dept%')
5 and sql_text not like '%v$sqlarea%';
no rows selected
SQL> -- we execute our stored proc which will cause our SQL in that stored proc to be cached
SQL> exec Foo2
PL/SQL procedure successfully completed.
SQL> -- do we see our stored proc's SQL in the shared pool using a bind variable?
SQL> select
2 sql_text
3 from v$sqlarea
4 where sql_text like UPPER('%dept%')
5 and sql_text not like '%v$sqlarea%';
SQL_TEXT
SELECT COUNT(*) FROM DEPT WHERE DEPTNO = :B1
SQL>

Oracle 8i: full sql text in v$sqlarea

I work with oracle 8i.
is there a v$... that shows the execution plan for a query.
in thev$sqlarea there isn't the full_sqltext column, and I need to know what oracle is doing now.
Message was edited by:
user596611

v$sqltext_with_newlines will produce multiple rows per statement.
You'll need an inline view
select t.hash_value, t.sorts, t.executions, t.buffer_gets, t.disk_reads, tn.sql_text
from v$sqlarea t,
(select hash_value,sql_text
from v$sqltext_with_newlines
order by hash_value, piece) tn
where sn.hash_value = t.hash_value
Sybrand Bakker
Senior Oracle DBA

Statements in v$SQLAREA

I see some sqls in v$sqlarea. But when I query v$session from the hash_Value of v$sqlarea, nothing comes up. Any particular reason why that would be so?
Thank you.
R

Okay :) here you go
[1]SELECT * from v$version
BANNER
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
PL/SQL Release 9.2.0.6.0 - Production
CORE 9.2.0.6.0 Production
TNS for HPUX: Version 9.2.0.6.0 - Production
NLSRTL Version 9.2.0.6.0 - Production
[2] Here is from v$SQLarea
SELECT *
FROM (SELECT Substr(a.sql_text,1,20) sql_text,
Trunc(a.disk_reads/Decode(a.executions,0,1,a.executions)) reads_per_execution,
a.buffer_gets,
a.disk_reads,
a.executions,
a.sorts,
a.address,hash_value,is_obsolete
FROM v$sqlarea a where a.sql_text like 'SELECT%'
order BY 2 DESC)
WHERE rownum <= 10
Results
SQL_TEXT READS_PER_EXECUTION SORTS ADDRESS HASH_VALUE
SELECT /*+ ORDERED U 174265 11 C00000022FFEE2E8 2024820696
SELECT /*+ 168019 3 C00000021BE3E7B0 3675638738
SELECT /*+ 166238 2 C0000002224D1628 4130578616
SELECT /*+ ORDERED U 165886 C000000245E5ADA0 1735771920
[3] Now query v$session with one of the value from #2
Select * from v$session where hash_value = 2024820696
No rows returned
Hope this helps
Thanks,
R

Gather_Plan_Statistics + DBMS_XPLAN A-rows for parallel queries

Looks like gather_plan_statistics + dbms_xplan displays incorrect A-rows for parallel queries. Is there any way to get the correct A-rows for a parallel query?
Version details:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi on HPUX
Create test tables:
-- Account table
create table test_tacprof
parallel (degree 2) as
select object_id ac_nr,
       object_name ac_na
from all_objects;
alter table test_tacprof add constraint test_tacprof_pk primary key (ac_nr);
-- Account revenue table
create table test_taccrev
parallel (degree 2) as
select apf.ac_nr         ac_nr,
       fiv.r             tm_prd,
       apf.ac_nr * fiv.r ac_rev
from   (select rownum r from all_objects where rownum <= 5) fiv,
       test_tacprof apf;
alter table test_taccrev add constraint test_taccrev_pk primary key (ac_nr, tm_prd);
-- Table to hold query results
create table test_4accrev as
select apf.ac_nr, apf.ac_na, rev.tm_prd, rev.ac_rev
from test_taccrev rev,
     test_tacprof apf
where 1=2;
Run query with parallel dml/query disabled:
ALTER SESSION DISABLE PARALLEL QUERY;
ALTER SESSION DISABLE PARALLEL DML;
INSERT INTO test_4accrev
   SELECT /*+ gather_plan_statistics */
          apf.ac_nr,
          apf.ac_na,
          rev.tm_prd,
          rev.ac_rev
     FROM test_taccrev rev, test_tacprof apf
    WHERE apf.ac_nr = rev.ac_nr AND tm_prd = 4;
SELECT *
FROM TABLE (DBMS_XPLAN.display_cursor (NULL, NULL, 'ALLSTATS LAST'));
| Id | Operation          | Name         | Starts | E-Rows | A-Rows |   A-Time   | Buffers | OMem | 1Mem | Use
|* 1 | HASH JOIN         |              |      1 | 30442 | 23412 |00:00:00.27 |     772 | 1810K| 1380K| 2949K (0)|
|   2 |   TABLE ACCESS FULL| TEST_TACPROF |      1 | 26050 | 23412 |00:00:00.01 |     258 |       |       |
|* 3 |   TABLE ACCESS FULL| TEST_TACCREV |      1 | 30441 | 23412 |00:00:00.03 |     514 |       |       |
ROLLBACK ;
A-rows are correctly reported with no parallel.
Run query with parallel dml/query enabled:
ALTER SESSION enable PARALLEL QUERY;
alter session enable parallel dml;
insert into test_4accrev
select /*+ gather_plan_statistics */ apf.ac_nr, apf.ac_na, rev.tm_prd, rev.ac_rev
from test_taccrev rev,
     test_tacprof apf
where apf.ac_nr = rev.ac_nr
and   tm_prd = 4;
select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
| Id | Operation                | Name         | Starts | E-Rows | A-Rows |   A-Time   | Buffers | OMem | 1Mem | Used-M
|   1 | PX COORDINATOR          |              |      1 |        | 23412 |00:00:00.79 |       6 |       |       |          |
|   2 |   PX SEND QC (RANDOM)    | :TQ10001     |      0 | 30442 |      0 |00:00:00.01 |       0 |       |       |          |
|* 3 |    HASH JOIN             |              |      0 | 30442 |      0 |00:00:00.01 |       0 | 2825K| 1131K|          |
|   4 |     PX BLOCK ITERATOR    |              |      0 | 30441 |     0 |00:00:00.01 |       0 |       |       |          |
|* 5 |      TABLE ACCESS FULL   | TEST_TACCREV |      0 | 30441 |      0 |00:00:00.01 |       0 |       |       |
|   6 |     BUFFER SORT          |              |      0 |        |      0 |00:00:00.01 |       0 | 73728 | 73728 |          |
|   7 |      PX RECEIVE          |              |      0 | 26050 |      0 |00:00:00.01 |       0 |       |       |          |
|   8 |       PX SEND BROADCAST | :TQ10000     |      0 | 26050 |      0 |00:00:00.01 |       0 |       |       |          |
|   9 |        PX BLOCK ITERATOR |              |      0 | 26050 |      0 |00:00:00.01 |       0 |       |       |          |
|* 10 |         TABLE ACCESS FULL| TEST_TACPROF |      0 | 26050 |      0 |00:00:00.01 |       0 |       |       |          |
rollback;
A-rows are zero execpt for final step.

I'm sorry for posting following long test case.
But it's the most convenient way to explain something. :-)
Here is my test case, which is quite similar to yours.
Note on the difference between "parallel select" and "parallel dml(insert here)".
(I know that Oracle implemented psc(parallel single cursor) model in 10g, but the details of the implementation is quite in mystery as Jonathan said... )
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE     10.2.0.1.0     Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
SQL>
SQL> alter system flush shared_pool;
System altered.
SQL>
SQL> alter table t parallel 4;
Table altered.
SQL>
SQL> select /*+ gather_plan_statistics */ count(*) from t t1, t t2
2 where t1.c1 = t2.c1 and rownum <= 1000
3 order by t1.c2;
COUNT(*)
      1000
SQL>
SQL> select sql_id from v$sqlarea
where sql_text like 'select /*+ gather_plan_statistics */ count(*) from t t1, t t2%';
SQL_ID
bx61bkyh9ffb6
SQL>
SQL> select * from table(dbms_xplan.display_cursor('&sql_id',null,'allstats last'));
Enter value for sql_id: bx61bkyh9ffb6
PLAN_TABLE_OUTPUT
SQL_ID bx61bkyh9ffb6, child number 0          <-- Cooridnator and slaves shared the cursor
select /*+ gather_plan_statistics */ count(*) from t t1, t t2 where t1.c1 = t2.c
1 and rownum <= 1000 order by t1.c2
Plan hash value: 3015647771
PLAN_TABLE_OUTPUT
| Id | Operation                  | Name     | Starts | E-Rows | A-Rows |   A-Time   | Buffers | OMem | 1Mem | Used-Mem |
|   1 | SORT AGGREGATE            |          |      1 |      1 |      1 |00:00:00.62 |       6 |       |       |          |
|* 2 |   COUNT STOPKEY            |          |      1 |        |   1000 |00:00:00.62 |       6 |       |       |          |
|   3 |    PX COORDINATOR          |          |      1 |        |   1000 |00:00:00.50 |       6 |       |       |          |
|   4 |     PX SEND QC (RANDOM)    | :TQ10002 |      0 |     16M|      0 |00:00:00.01 |       0 |       |       |          |
|* 5 |      COUNT STOPKEY         |          |      0 |        |      0 |00:00:00.01 |       0 |       |       |          |
|* 6 |       HASH JOIN BUFFERED   |          |      0 |     16M|      0 |00:00:00.01 |       0 | 1285K| 1285K| 717K (0)|
|   7 |        PX RECEIVE          |          |      0 | 10000 |      0 |00:00:00.01 |       0 |       |       |          |
|   8 |         PX SEND HASH       | :TQ10000 |      0 | 10000 |      0 |00:00:00.01 |       0 |       |       |          |
|   9 |          PX BLOCK ITERATOR |          |      0 | 10000 |      0 |00:00:00.01 |       0 |       |       |          |
|* 10 |           TABLE ACCESS FULL| T        |      0 | 10000 |      0 |00:00:00.01 |       0 |       |       |          |
| 11 |        PX RECEIVE          |          |      0 | 10000 |      0 |00:00:00.01 |       0 |       |       |          |
| 12 |         PX SEND HASH       | :TQ10001 |      0 | 10000 |      0 |00:00:00.01 |       0 |       |       |          |
| 13 |          PX BLOCK ITERATOR |          |      0 | 10000 |      0 |00:00:00.01 |       0 |       |       |          |
|* 14 |           TABLE ACCESS FULL| T        |      0 | 10000 |      0 |00:00:00.01 |       0 |       |       |          |
38 rows selected.
SQL>
SQL> select sql_id, child_number, executions, px_servers_executions
2 from v$sql where sql_id = '&sql_id';
SQL_ID                                  CHILD_NUMBER EXECUTIONS
PX_SERVERS_EXECUTIONS
bx61bkyh9ffb6                                      0          1
                    8
SQL>
SQL> insert /*+ gather_plan_statistics */ into t select * from t;
10000 rows created.
SQL>
SQL> select sql_id from v$sqlarea
where sql_text like 'insert /*+ gather_plan_statistics */ into t select * from t%';
SQL_ID
9dkmu9bdhg5h0
SQL>
SQL> select * from table(dbms_xplan.display_cursor('&sql_id', null, 'allstats last'));
Enter value for sql_id: 9dkmu9bdhg5h0
PLAN_TABLE_OUTPUT
SQL_ID 9dkmu9bdhg5h0, child number 0       <-- Coordinator Cursor
insert /*+ gather_plan_statistics */ into t select * from t
Plan hash value: 3050126167
| Id | Operation            | Name     | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
|   1 | PX COORDINATOR      |          |      1 |        | 10000 |00:00:00.20 |       3 |
|   2 |   PX SEND QC (RANDOM)| :TQ10000 |      0 | 10000 |      0 |00:00:00.01 |       0 |
|   3 |    PX BLOCK ITERATOR |          |      0 | 10000 |      0 |00:00:00.01 |       0 |
|* 4 |     TABLE ACCESS FULL| T        |      0 | 10000 |      0 |00:00:00.01 |       0 |
SQL_ID 9dkmu9bdhg5h0, child number 1        <-- Slave(s)
insert /*+ gather_plan_statistics */ into t select * from t
PLAN_TABLE_OUTPUT
Plan hash value: 3050126167
| Id | Operation            | Name     | Starts | E-Rows | A-Rows |   A-Time | Buffers |
|   1 | PX COORDINATOR      |          |      0 |        |      0 |00:00:00.01 |       0 |
|   2 |   PX SEND QC (RANDOM)| :TQ10000 |      0 | 10000 |      0 |00:00:00.01 |       0 |
|   3 |    PX BLOCK ITERATOR |          |      1 | 10000 |   2628 |00:00:00.20 |      16 |
|* 4 |     TABLE ACCESS FULL| T        |      4 | 10000 |   2628 |00:00:00.02 |      16 |
SQL>
SQL> select sql_id, child_number, executions, px_servers_executions
2 from v$sql where sql_id = '&sql_id'; <-- 2 child cursors here
SQL_ID                                  CHILD_NUMBER EXECUTIONS
PX_SERVERS_EXECUTIONS
9dkmu9bdhg5h0                                      0          1
                    0
9dkmu9bdhg5h0                                      1          0
                    4
SQL>
SQL> set serveroutput on
-- check mismatch
SQL> exec print_table('select * from v$sql_shared_cursor where sql_id = ''&sql_id''');
Enter value for sql_id: 9dkmu9bdhg5h0
SQL_ID                        : 9dkmu9bdhg5h0
ADDRESS                       : 6AD85A70
CHILD_ADDRESS                 : 6BA596A8
CHILD_NUMBER                  : 0
UNBOUND_CURSOR                : N
SQL_TYPE_MISMATCH             : N
OPTIMIZER_MISMATCH            : N
OUTLINE_MISMATCH              : N
STATS_ROW_MISMATCH            : N
LITERAL_MISMATCH              : N
SEC_DEPTH_MISMATCH            : N
EXPLAIN_PLAN_CURSOR           : N
BUFFERED_DML_MISMATCH         : N
PDML_ENV_MISMATCH             : N
INST_DRTLD_MISMATCH           : N
SLAVE_QC_MISMATCH             : N
TYPECHECK_MISMATCH            : N
AUTH_CHECK_MISMATCH           : N
BIND_MISMATCH                 : N
DESCRIBE_MISMATCH             : N
LANGUAGE_MISMATCH             : N
TRANSLATION_MISMATCH          : N
ROW_LEVEL_SEC_MISMATCH        : N
INSUFF_PRIVS                  : N
INSUFF_PRIVS_REM              : N
REMOTE_TRANS_MISMATCH         : N
LOGMINER_SESSION_MISMATCH     : N
INCOMP_LTRL_MISMATCH          : N
OVERLAP_TIME_MISMATCH         : N
SQL_REDIRECT_MISMATCH         : N
MV_QUERY_GEN_MISMATCH         : N
USER_BIND_PEEK_MISMATCH       : N
TYPCHK_DEP_MISMATCH           : N
NO_TRIGGER_MISMATCH           : N
FLASHBACK_CURSOR              : N
ANYDATA_TRANSFORMATION        : N
INCOMPLETE_CURSOR             : N
TOP_LEVEL_RPI_CURSOR          : N
DIFFERENT_LONG_LENGTH         : N
LOGICAL_STANDBY_APPLY         : N
DIFF_CALL_DURN                : N
BIND_UACS_DIFF                : N
PLSQL_CMP_SWITCHS_DIFF        : N
CURSOR_PARTS_MISMATCH         : N
STB_OBJECT_MISMATCH           : N
ROW_SHIP_MISMATCH             : N
PQ_SLAVE_MISMATCH             : N
TOP_LEVEL_DDL_MISMATCH        : N
MULTI_PX_MISMATCH             : N
BIND_PEEKED_PQ_MISMATCH       : N
MV_REWRITE_MISMATCH           : N
ROLL_INVALID_MISMATCH         : N
OPTIMIZER_MODE_MISMATCH       : N
PX_MISMATCH                   : N
MV_STALEOBJ_MISMATCH          : N
FLASHBACK_TABLE_MISMATCH      : N
LITREP_COMP_MISMATCH          : N
SQL_ID                        : 9dkmu9bdhg5h0
ADDRESS                       : 6AD85A70
CHILD_ADDRESS                 : 6B10AA00
CHILD_NUMBER                  : 1
UNBOUND_CURSOR                : N
SQL_TYPE_MISMATCH             : N
OPTIMIZER_MISMATCH            : N
OUTLINE_MISMATCH              : N
STATS_ROW_MISMATCH            : N
LITERAL_MISMATCH              : N
SEC_DEPTH_MISMATCH            : N
EXPLAIN_PLAN_CURSOR           : N
BUFFERED_DML_MISMATCH         : N
PDML_ENV_MISMATCH             : N
INST_DRTLD_MISMATCH           : N
SLAVE_QC_MISMATCH             : N
TYPECHECK_MISMATCH            : N
AUTH_CHECK_MISMATCH           : N
BIND_MISMATCH                 : N
DESCRIBE_MISMATCH             : N
LANGUAGE_MISMATCH             : N
TRANSLATION_MISMATCH          : N
ROW_LEVEL_SEC_MISMATCH        : N
INSUFF_PRIVS                  : N
INSUFF_PRIVS_REM              : N
REMOTE_TRANS_MISMATCH         : N
LOGMINER_SESSION_MISMATCH     : N
INCOMP_LTRL_MISMATCH          : N
OVERLAP_TIME_MISMATCH         : N
SQL_REDIRECT_MISMATCH         : N
MV_QUERY_GEN_MISMATCH         : N
USER_BIND_PEEK_MISMATCH       : N
TYPCHK_DEP_MISMATCH           : N
NO_TRIGGER_MISMATCH           : N
FLASHBACK_CURSOR              : N
ANYDATA_TRANSFORMATION        : N
INCOMPLETE_CURSOR             : N
TOP_LEVEL_RPI_CURSOR          : N
DIFFERENT_LONG_LENGTH         : N
LOGICAL_STANDBY_APPLY         : N
DIFF_CALL_DURN                : Y      <-- Mismatch here. diff_call_durn
BIND_UACS_DIFF                : N
PLSQL_CMP_SWITCHS_DIFF        : N
CURSOR_PARTS_MISMATCH         : N
STB_OBJECT_MISMATCH           : N
ROW_SHIP_MISMATCH             : N
PQ_SLAVE_MISMATCH             : N
TOP_LEVEL_DDL_MISMATCH        : N
MULTI_PX_MISMATCH             : N
BIND_PEEKED_PQ_MISMATCH       : N
MV_REWRITE_MISMATCH           : N
ROLL_INVALID_MISMATCH         : N
OPTIMIZER_MODE_MISMATCH       : N
PX_MISMATCH                   : N
MV_STALEOBJ_MISMATCH          : N
FLASHBACK_TABLE_MISMATCH      : N
LITREP_COMP_MISMATCH          : N
PL/SQL procedure successfully completed.

Performance problem on a table with zero rows

I queried the v$sqlarea table to find which SQL statement was doing the most disk reads and it turned out to be a query that read 278 Gigabytes from a table which usually has zero rows. This query runs every minute and reads any rows that are in the table. It does not do any joins. The process then processes the rows and deletes them from the table. Over the course of a day, a few thousand rows may be processed this way with a row length of about 80 bytes. This amounts to a few kilobytes, not 278 Gig over a couple of days. Buffer gets were even higher at 295 Gig. Note that only the query that reads the table is doing these disk reads, not the rest of the process.
There are no indexes on the table, so a full table scan is done. The query reads all the rows, but usually there are zero. I checked the size of the table in dba_segments, and it was 80 Meg. At one point months ago, during a load, the table had 80 Meg of data in it, but this was deleted after being processed. The size of the table was never reduced.
I can only assume that Oracle is doing a full table scan on all 80 Meg of this table every minute. Even when there are zero rows. Dividing the buffer gets in bytes by the number of executions yields 72 Meg which is close to the table size. Oracle is reading the entire table size from disk even when the table has zero rows.
The solution was to truncate the table. This helped immediately and reduced the disk reads to zero most of the time. The buffer gets were also reduced to 3 per execution when the table was empty. The automatic segment manager reduced the size of the table to 64k overnight.
Our buffer cache hit ratio was a dismal 72%. It should go up now that this problem has been resolved.
Table statistics are gathered every week. We are running Oracle 9.2 on Solaris.
Note that this problem is already resolved. I post it because it is an interesting case.
Kevin Tyson, OCP
DaimlerChrysler Tech Center, Auburn Hills, MI

Kevin,
The solution was to truncate the tableThis is not a scoop... isn't it ?
Table statistics are gathered every weekIs there any reason for that ?
If stats ran when no rows, perf can be very bad after loading data, and if stats ran when thousand rows, perf can be very bad after deleting. Perhaps can you find a more restrictive stat running ?
Nicolas.
Message was edited by:
N. Gasparotto

How to find sql causing "enq: TX - row lock contention"

Hi,
In one of our database we keep finding "enq: TX - row lock contention" for 2-3 days. But, then it stopped. The time it happened it blocked other sessions for some long time and it got resolved automatically. Now from ADDM report we got sql queries which waited for this but, we can not find which query from which module was causing the issue. What I should look for that past information. Please help.
Database is 10gR2 on AIX.
Regards,
Gourab

moreajays wrote:
Try executing below query real time
alter session set nls_date_format='dd-mon-yyyy hh24:mi:ss';
SELECT vp.spid,c.inst_id,b.session_id sid,c.serial#,a.object_name,
a.owner object_owner,
Decode(b.locked_mode, 0, 'None',
1, 'Null (NULL)',
2, 'Row-S (SS)',
3, 'Row-X (SX)',
4, 'Share (S)',
5, 'S/Row-X (SSX)',
6, 'Exclusive (X)',
b.locked_mode) locked_mode,
b.oracle_username,
c.program,
d.event,
c.status,
c.last_call_et,
c.sql_address,
e.sql_text, c.logon_time
FROM all_objects a,
gv$locked_object b,
gv$session c,
gv$session_wait d,
gv$sqlarea e,
gv$process vp
WHERE a.object_id = b.object_id
and b.session_id=c.sid
and c.sid=d.sid and c.paddr=vp.addr
and e.address=c.sql_address and lower(d.event) like '%enq%'
ORDER BY 1;
The OP asked for a way of find a historic blocker, not a current blocker.
This query - apart from being one that no-one should want to run on a production system - doesn't say anything about the past, and doesn't identify a blocker.
It reports the sessions that are being blocked, and EVERY table that is currently locked by each session whether or not the table is involved in the current statement.
You're using the gv$ (RAC) views but haven't put in any suitable join predicates on the instance (inst_id) columns; the OP is on 10g so you don't need to join to v$session_wait to pick up the wait information; and the join to v$sqlarea forces a "full tablescan" of the library cache (child cursor derived view) because you're joining on address rather than sql_id.
Regards
Jonathan Lewis

V$sqlarea encoding

I have plsql code looking something like that:
if v_state_flag = 'S' and v_next_query = 'Y' then
      PKG_COMMON.DEBUG ('GET_ADDRESS_LEVEL_LIST.30, fill o_state_list');
      -- kui #postal_flag = 'Y' ja #postalcode on antud, siis lisada klausel
      if v_postalcode_flag = 'S' and i_postal_code is not null then
         open o_state_list for
            select reg.CODE, reg.NAME from V_REGION_LANG reg
            where reg.LANGUAGE = PKG_SESSION.LANGUAGE_CODE
               and reg.COUNTRY = i_country
               and reg.REGION_LEVEL = 'STATE'
               and reg.CLOSED_TIME is null
               -- kui #postal_flag = 'Y' ja #postalcode on antud, siis lisada klausel
               and reg.CODE in (
               select r.REGION_CODE1 from REGION r, POSTALCODE p
               where r.COUNTRY = p.COUNTRY
               and r.CODE = p.REGION_CODE
               and p.POSTALCODE = i_postal_code
               and p.CLOSED_TIME is null
               );       View "v$sqlarea" shows this query as:
select * from v$sqlarea where
last_active_time > sysdate - 2
and sql_text like '%REG.CODE, REG.NAME%'
SELECT REG.CODE, REG.NAME FROM V_REGION_LANG REG
WHERE REG.LANGUAGE = PKG_SESSION.LANGUAGE_CODE
AND REG.COUNTRY = :B1 AND REG.REGION_LEVEL = 'STATE' AND REG.CLOSED_TIME IS NULL
;We have " :B1" in query, it stands for plsql parameter "i_country". But we have call to package function "PKG_SESSION.LANGUAGE_CODE" in v$sqlarea query- why wasn't this function replaced with ":B15" for example?
Why plsql parameters are replaced with ":B5" but package functions not?
Does the "PKG_SESSION.LANGUAGE_CODE" in query makes the query slower?

PL/SQL variables by default act as Bind Variables when you use them in SQL. But PACKAGE functions or standalone functions are not bind variables.
If you dont want the package name to appear in the SQL area then you need to change the SQL to use a bind variable.
Something like this
if v_state_flag = 'S' and v_next_query = 'Y' then
      PKG_COMMON.DEBUG ('GET_ADDRESS_LEVEL_LIST.30, fill o_state_list');
      my_value := PKG_SESSION.LANGUAGE_CODE;
      -- kui #postal_flag = 'Y' ja #postalcode on antud, siis lisada klausel
      if v_postalcode_flag = 'S' and i_postal_code is not null then
         open o_state_list for
            select reg.CODE, reg.NAME from V_REGION_LANG reg
            where reg.LANGUAGE = my_value
               and reg.COUNTRY = i_country
               and reg.REGION_LEVEL = 'STATE'
               and reg.CLOSED_TIME is null
               -- kui #postal_flag = 'Y' ja #postalcode on antud, siis lisada klausel
               and reg.CODE in (
               select r.REGION_CODE1 from REGION r, POSTALCODE p
               where r.COUNTRY = p.COUNTRY
               and r.CODE = p.REGION_CODE
               and p.POSTALCODE = i_postal_code
               and p.CLOSED_TIME is null
               );By doing this you execute the package function only once. But when you use it in a SQL directly you execute it for every row.

Suprising output in v$sqlarea

{\code\}
SQL> show parameter cursor
NAME TYPE VALUE
cursor_sharing string SIMILAR
cursor_space_for_time boolean FALSE
open_cursors integer 300
session_cached_cursors integer 20
SQL> show parameter optimizer_dynamic_sampling
NAME TYPE VALUE
optimizer_dynamic_sampling integer 2
SQL> alter session set nls_language=american;
Session altered.
SQL> alter system flush shared_pool;
System altered.
SQL> select hash_value,sql_text,version_count from v$sqlarea
2 where sql_text like 'select count(*) from k%';
no rows selected
SQL> select count(*) from k where id=1;
COUNT(*)
1
SQL> select count(*) from k where id=2;
COUNT(*)
51806
SQL> select hash_value,sql_text,version_count from v$sqlarea
2 where sql_text like 'select count(*) from k%';
HASH_VALUE
SQL_TEXT
VERSION_COUNT
2570880302
select count(*) from k where id=:"SYS_B_0"
2
2570880302
select count(*) from k where id=:"SYS_B_0"
2
HASH_VALUE
SQL_TEXT
VERSION_COUNT
SQL> select count(*) from k where id=3;
COUNT(*)
0
SQL> select hash_value,sql_text,version_count from v$sqlarea
2 where sql_text like 'select count(*) from k%';
HASH_VALUE
SQL_TEXT
VERSION_COUNT
2570880302
select count(*) from k where id=:"SYS_B_0"
3
2570880302
select count(*) from k where id=:"SYS_B_0"
3
HASH_VALUE
SQL_TEXT
VERSION_COUNT
{\code\}
why has two lines in v$sqlarea ????
Edited by: jinyu on Oct 6, 2008 1:41 AM
Edited by: jinyu on Oct 6, 2008 1:43 AM

I guess you have't understood Heman't reply. Similar is an intelligent parameter. It won't just go and pick the cached cursor. Rather than it would check that with a different bind value, do you need to reuse the same cursor or Oracle should create a new one? In your case,though the values are different, 1 & 2 but Oracle is not deeming them for being safe to be shared so its creating multiple cursors.
That's the basic difference of Force and Similar. Force goes for sort of,one-plan-fits-all where as Similar goes for , share-when-safe.
HTH
Aman....

Confusion in v$sqlarea

Hello Experts ;
I am testing few things on pl-sql supplies packages (DBMS_SHARED_POOL.PURGE )
but i have few doubts please clear my doubt.
<< On Terminal 1 >>
SQL>desc tab1;
Name                                      Null?                         Type
NO                                                                              NUMBER
NAME                                                                       VARCHAR2(15)
EMAIL                                                                       VARCHAR2(15)
CITY                                                                           VARCHAR2(15)
SQL>select count(*) from tab1;
COUNT(*)
    300000
SQL>select * from t ab1;
In Process
<< On Terminal 2 >>
SQL. conn /as sysdba
Connected.
SQL>select sql_text,address, hash_value, executions, loads, version_count, invalidations, parse_calls from v$sqlarea
where sql_text ='SELECT * FROM TAB1';
no rows selected
Why i did n't get values in terminal 2 , when query running on terminal 1;
MY DB VRSION IS : 10.2.0.1.0
Thanks in dvance ..

@BCV
i got 268 lines ..then i have created spool file . i am pasting output for following query..
SYS>select * From v$sqlarea
2 order by FIRST_LOAD_TIME desc;
SQL_TEXT
--------------------------------------------------------------------------------SQL_FULLTEXT
--------------------------------------------------------------------------------SQL_ID        SHARABLE_MEM PERSISTENT_MEM RUNTIME_MEM      SORTS VERSION_COUNT
LOADED_VERSIONS OPEN_VERSIONS USERS_OPENING    FETCHES EXECUTIONS
PX_SERVERS_EXECUTIONS END_OF_FETCH_COUNT USERS_EXECUTING      LOADS
FIRST_LOAD_TIME     INVALIDATIONS PARSE_CALLS DISK_READS DIRECT_WRITES
BUFFER_GETS APPLICATION_WAIT_TIME CONCURRENCY_WAIT_TIME CLUSTER_WAIT_TIME
USER_IO_WAIT_TIME PLSQL_EXEC_TIME JAVA_EXEC_TIME ROWS_PROCESSED COMMAND_TYPE
OPTIMIZER_ OPTIMIZER_COST
OPTIMIZER_ENV
--------------------------------------------------------------------------------OPTIMIZER_ENV_HASH_VALUE PARSING_USER_ID PARSING_SCHEMA_ID
PARSING_SCHEMA_NAME            KEPT_VERSIONS ADDRESS HASH_VALUE OLD_HASH_VALUE
PLAN_HASH_VALUE MODULE
--------------- ----------------------------------------------------------------MODULE_HASH ACTION
ACTION_HASH SERIALIZABLE_ABORTS
OUTLINE_CATEGORY                                                   CPU_TIME
ELAPSED_TIME OUTLINE_SID                              LAST_ACT R
OBJECT_STATUS       LITERAL_HASH_VALUE LAST_LOAD I CHILD_LATCH
SQL_PROFILE                                                      PROGRAM_ID
PROGRAM_LINE# EXACT_MATCHING_SIGNATURE FORCE_MATCHING_SIGNATURE LAST_ACTI
BIND_DATA
select * From v$sqlarea order by FIRST_LOAD_TIME desc

High invalidations in v$sqlarea for 1 query tag with "SQL Analyze"

Hi All,
Hopefully post to the right forum, if not please do let me know. Thanks
I have one pre-production issue still don't have any clue how to move forward.
This is 2 RAC nodes in linux platform with Oracle 11.2.0.2
In the begininng this environment having a lot of performance issue, as huge "cursor: pin S wait on X", "latch: shared pool"
and "library cache:Mutex X" causing very bad performance in this environment. After oracle support suggest to disable few hidden paramter
and adjust some parameter, then it help to stablized the environment (according to oracle, the initial issue was caused by high version count).
But we still can find minimal "latch:shared pool" and "library cache:Mutex X" on top 5 wait event list on hourly AWR report.
This time oracle was saying it might caused by high reload and high invalidatiosn in sqlarea (not sure how true it is), luckily the event
did not caused the performance issue at this moment, but we're asking support how can we get rid of the "mutex/latch" event.
They give me one query to check the invalidations in v$sqlarea, and they suspect the high validation is causing by application.
select *
from v$sqlarea
order by invalidations DESC;
Weird thing is, there have one SQL tag with "SQL Analyze" always causing high invalidations. But we're not able to get more detail (base on SQL_ID)
in v$sql or v$session table. This SQL insert into v$sqlarea and remove within 1 or 2 seconds, hard to get more information.
And the statement is exactly the same, but don't know why SQL Analyze always checking on it.
This SQL is triggering by SYS user, and it is inserting into MLOG$ table (one of the application materialized log file)
insert into "test"."MLOG$_test1" select * from "test"."MLOG$_test1"
The v$sqlarea information as below, sometime the invalidations can hit more than 10,000
SQL_ID              SQL_TEXT                                                                                        LOADS INVALIDATIONS
0m6dhq90rg82x /* SQL Analyze(632,0) */ insert into "test"."MLOG$_test" select * from "test"."MLOG$_test 7981    7981
{code}
Anyone have any idea how can i move forward for this issue? As Oracle is asking me to use SQLTXPLAIN get the detail?
Please share with me if you have any idea. Thanks in advance.
Regards,
Klng

Hi Dom,
We have checked there have no SQL Tuning enable for this SQL_ID. Below is the optimizer parameter in this environment, the hidden parameter was changed which suggest by oracle support.
NAME                                 TYPE        VALUE
_optimizer_adaptive_cursor_sharing   boolean     FALSE
_optimizer_extended_cursor_sharing_r string      NONE
el
object_cache_optimal_size            integer     102400
optimizer_capture_sql_plan_baselines boolean     FALSE
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      11.2.0.2
optimizer_index_caching              integer     90
optimizer_index_cost_adj             integer     10
optimizer_mode                       string      ALL_ROWS
optimizer_secure_view_merging        boolean     TRUE
optimizer_use_invisible_indexes      boolean     FALSE
optimizer_use_pending_statistics     boolean     FALSE
optimizer_use_sql_plan_baselines     boolean     TRUE
plsql_optimize_level                 integer     2
SQL> select * from dba_sql_plan_baselines;
no rows selected
SQL>yeah we did run the ash, but the high invalidation did not caputre in the report. Actually this SQL tag with sql analyze it gone from v$sqlarea very fast (only 1 or 2 seconds only).
Thanks.
Regards,
Klng

Which user/schema executed query in V$SQLAREA

I am looking on one row/query in view "V$SQLAREA" and want to which user/schema was used to log in to the database when that one query was executed. How i can get that schema name?
Should i look this column maybe:
V$SQLAREA
PARSING_SCHEMA_NAME             VARCHAR2(30)      Schema name that was used to parse this child cursor( http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2129.htm )
I have Java software that uses different database schemas/users to make connections to my database. And i want to know for one query which schema/user was used to connect to database before running the query.
I think i need to join "V$SQLAREA" to view V$SESSION and there the column "USERNAME" tells me the connection user name for the executed query.
V$SESSION
USERNAME      VARCHAR2(30)      Oracle username
( http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2088.htm )Seems like i fail to join "V$SQLAREA" to view V$SESSION:
select q.SQL_TEXT, q.sql_id, q.PARSING_SCHEMA_NAME, q.ADDRESS, q.last_active_time, s.USERNAME, s.SCHEMANAME from v$sqlarea q, v$session s
where q.last_active_time > sysdate - 1
and q.sql_text like 'DELETE FROM casino.lgngameoperationlog WHERE sessionCode%'
and s.sql_address=q.address
order by last_active_time desc
no rows found
select q.SQL_TEXT, q.sql_id, q.PARSING_SCHEMA_NAME, q.ADDRESS, q.last_active_time from v$sqlarea q
where q.last_active_time > sysdate - 1
and q.sql_text like 'DELETE FROM casino.lgngameoperationlog WHERE sessionCode%'
order by last_active_time desc
'DELETE FROM casino.lgngameoperationlog WHERE sessionCode = :1 and sessionType = :2';     51thfgbubkkg6;     JAVA;     0000000392523658;     28.10.2010 18:09:14;
*/

I have Java software that uses different database schemas/users to make connections to my database. And i want to know for one query which schema/user was used to connect to database before running the query.If the SQL-text sits inside your Java code, that is the text does not sit inside some stored pl/sql program unit, then you can use parsing_schema_id, yes.
If the SQL-text sits inside a stored procedure, then depending on how that procedure is defined (invoker rights or definer rights), you could use parsing_schema_id too (in the first case (invoker rights)).

Question on SQL_TEXT from v$sqlarea

Windows 2003
Oracle 9.2.0.6.0
I have a number of DML statements I want to run dynamically. I have a PLSQL proc which generates the statements and populates a tracking table with them. It then selects from the tracking table and executes each statement dynamically with a status field against each statement. a pretty simple cursor loop.
All the statements are deletes with a bitmap index hint to delete where delete_flag = Y.
delete /*+ INDEX(<bitmap index name on delete_flag>) */ table_name WHERE delete_flag = 'Y'
several hundred of these. before it runs for each statement I update the tracker table with "running" for that statement so I know which table its running against. 1 of the tables seems to be hung for a long time. hours. I would have expected the delete of this particular table to run in minutes tops. Theres maybe 1 mill rows in the table with 300k rows to be deleted.
explain plan for that statement is good, uses the index as expected with a low costing.
So I started to dig around.
Looking at the waits for this session every few seconds, it seems to be progressing through the blocks so no waits in partiuclar to worry about.
I then happen to check the SQL for that session (nothing else running on the DB while this procuedre is running)
select sesion.sid,
       sesion.username,
       optimizer_mode,
       hash_value,
       address,
       cpu_time,
       elapsed_time,
       sql_text
from v$sqlarea sqlarea, v$session sesion
where sesion.sql_hash_value = sqlarea.hash_value
   and sesion.sql_address    = sqlarea.address
   and sesion.username is not null And the SQL_TEXT returned is not the SQL that was submitted dynamically. the table is correct but its using the primary key to delete.
DELETE FROM hung_table_name WHERE PK_FIELD = :B1
Can anyone explain why Im seeing that delete statement and not the one submitted dynamically?

I can understand guys saying I cant be absolutely sure nothing else is running based on the SQL, but I am sure.
its a small shop, no apps coming in, 1 other dba, 2 developers, no scheduled jobs in the database, no scheduled job on the OS, no other users on.
The tracker table that Im populating has a few hundred statements in it, dynamically generated from a cursor theyre all
step, command, status
1, delete /index hint/ from table1 where delete_flag=Y, Pre
2, commit, Pre
3, delete /index hint/ from table2 where delete_flag=Y, Pre
4, commit, Pre
5, delete /index hint/ from table3 where delete_flag=Y, Pre
and so forth....
Theres no room for anything else to get in, let alone a well constructed command to delete by the primary key.
In the PLSQL, the cursor is select command from tracker_Table order by step
for i in cur
update tracker_table set status ='running' where command = i.command
execute immediate 'i.command';
update tracker_table set status ='complete' where command = i.command
As the entire job takes 2 days (yes, Im trying to come up with a better way and I didnt write this one), this method works for tracking where the job is. At the time this particualr table is getting stuck, the status is set to 'running' for the same table that I see the 2 statements for the in sql_text.
1 which is the statement with the index hint and a non matching hash value in v$session. And 1 statement which Ive shown deletes by the PK where the hash value matches the hash value of the session thats running the delete statement.
Ive never seen that before in a view (sql area)I would have queried many times over the years.
So, unless I can see otherwise, Im going with my earlier instinct that the query is being rewritten to delete by PK based on what sybrand said about the 9i explain. Still doesnt explain for me the other SQL with the non matching hash value though.
Or better turn on sql trace in 1-st session as it was already advised and then look into trace file.see earlier post, its taking hours and not returning so cant get a good trace.

V$sqlarea and ROWS_PROCESSED

Hii all
when I looking v$sqlare for a statement that is I suspect to create so much redo, the Statement is updating a table row (there is not index on table)but ROWS PROCESSED' value is almost 138 million but table has only 15.000 row also executions value is 13000 How it could be possible ? Pls explain what is the exact mean is ROW PROCESSED and EXECUTIONS colums in the v$sqlarea ? if there is index on table when updating a table, row_processed could be higher than actual updated rows ?
10.2.0.4 On AIX
Best Regards

These values are totals across all executions of the statement whilst it has been in the SQL area:
executions:- Total number of executions, totalled over all the child cursors
rows_processed:- Total number of rows processed on behalf of this SQL statement
You could try looking in the AWR data (dba_hist_sqlstat - 10G and above) to view more granular information about this SQL_ID after each snapshot (it records the values for the snapshot period i.e. delta's), if it really is executed so often it will more than likely have been captured by AWR.
Thanks
Paul

Is there way to get lock holder by row id?

My problem is that sometimes some rows get locked for long time and I don't know who holds lock.
Ideally I want query which takes table_name and primary key value and outputs lock holder information. (e.g sql text, how long query is being running, etc)
I've found in documentation that there is no central place where row locks are stored and that this is row level metadata.
My question is: Can I get this row level metadata somehow for concrete row? (I believe this should be possible)
My usecase would be as follows:
1. try to get lock for row for id=#N (select for update semantics, actually hibernate is used for that but it shouldn't make difference here)
2. get error (now i'm getting ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired)
3. This step is what I want to add. Get information about lock holder for row with id=#N and write it into log file.
Here is query I was playing with which outputs general information about transactions having locks but it's not what I need in terms of row level locking:
select a.sql_text, l.ctime, s.STATUS, s.SQL_EXEC_START, s.PROGRAM from
v$lock l join v$session s on (l.sid = s.sid)
join v$sqlarea a on (a.hash_value = s.sql_hash_value)
where l.type='TX' and l.lmode>0;

Welcome to the forum!
Whenever you post provide your 4 digit Oracle version.
>
My problem is that sometimes some rows get locked for long time and I don't know who holds lock.
>
See this Oracle Magazine article.
http://www.oracle.com/technetwork/issue-archive/2012/12-jul/o42dba-1566567.html
>
You can find the specific row that is locked by first finding the table containing that row. To find that table, use the same V$SESSION view; in this case, the information is in the ROW_WAIT_OBJ# column, which shows the object number of the table whose row is being locked. You can then get the name of the table from the DBA_OBJECTS view, using this object number, as shown in Listing 3.
>
For 'who holds the lock' see this thread
How to check Locking sessions in oracle 10g
There are many other similar results on the net.

V$sqlarea : 34769 rows

Similar Messages

Maybe you are looking for