Get statistics of query Plan

Hello

I sent a simple application on the server by default (on localhost) OEP in Eclipse. I can see the results in the console when the generator to send messages to the port 9200. Also, I can see that the application is RUNNING when I check the processing of the event viewer (http://localhost:9002 / wlevs /)

However, on the page of query plan, the result of stat is always 0 for all operators... I take a look at all the documentation, but I could not solve the problem.

See you soon,.

Alireza

For the review of the performance, query plan statistics news are disabled by default. To activate it, please add following in the server's config.xml file before starting the server.

true

Kind regards

XiYing

Tags: Fusion Middleware

Similar Questions

Error getting query plans for queries involving logical operators
I'm trying to gather information to improve the performance of queries for an application I am running using Oracle Berkeley XML database version 2.4.16 with all available patches installed and have encountered problems in the documentation of my XQuery query plans. I hope that these problems also partly explain query performance problems I'm having.

Specifically, I use dbxml to start
```
qplan collection('browser')/*[@parentIndex='none']



<XQuery>

  <QueryPlanToAST>

    <LevelFilterQP>

      <StepQP axis="parent-of-attribute" uri="*" name="*" nodeType="element">

        <ValueQP container="browser" index="node-attribute-equality-string" operation="eq" child="parentIndex" value="none"/>

      </StepQP>

    </LevelFilterQP>

  </QueryPlanToAST>

</XQuery>
```
I have this make more complex as follows:
```
qplan collection('browser')/*[@parentIndex='none' and @uri='http://example.com/']
```
NB: the above should have been: collection qplan ("browser") / * open_square_bracket @parentIndex = "none" and @uri = "http://example.com/" close_square_bracket

and the dbxml command-line utility responds with:
```
queryPlan failed, Wrong number of arguments.
```
This happens about any variation on this request where there are two conditions related (or gold) set term [].

An overview of what motivates the error would be very useful.

Thank you

Geoff Shuetrim

Published by: Geoff Shuetrim on February 6, 2009 14:26
Hi Geoff,

Please apply "" or "" to your expression of qplan. "
Like this:
```
qplan "collection('browser')/open_square_bracket[@a='b']"
```
or
```
qplan 'collection("browser")/open_square_bracket[@a="b"]'
```
Note: as stated above, use ' ' inside the phrase while using "" outside of expression and use ' ' inside the phrase while using "'outside the expression.

Published by: rucong.zhao on February 5, 2009 19:37

Confused with SQL query plan numbers

Hi all
I'm on Oracle 11.2 "Standard Edition" under Windows.
Here is a simple query plan and the predicate shown after the plan. I'm a little confused by the numbers indicated on the plan and not able to understand why the index is not used. The query is generated from Cognos front end, I captured using dbms_xplan.display_cursor (when the query was actually being run).
SQL > select * from table (dbms_xplan.display_cursor ('& sqlid', 0));
Enter the value of sqlid: 8yd0uu78jzqpg
old 1: select * from table (dbms_xplan.display_cursor ('& sqlid', 0))
new 1: select * from table (dbms_xplan.display_cursor('8yd0uu78jzqpg',0))
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------
SQL_ID, 8yd0uu78jzqpg, number of children 0
-------------------------------------
Select distinct CASE WHEN (CASE WHEN ("MY_TRANSACTION_TABLE3". "NEW_OFFCR_CD" IS "
NULL NULL) THEN ELSE ("MY_TRANSACTION_TABLE3". "NEW_OFFCR_CD" | " -") END IS NULL)"
OR ("MY_TRANSACTION_TABLE3". ("' EMP_NM ' IS NULL) THEN NO OTHER (CASE
WHEN ("MY_TRANSACTION_TABLE3". "NEW_OFFCR_CD" IS NULL), THEN ANOTHER NULL "
("MY_TRANSACTION_TABLE3". "NEW_OFFCR_CD" | " -")
END | "" MY_TRANSACTION_TABLE3 ". ("" EMP_NM END ")"Officer_Name. "
'MY_TRANSACTION_TABLE3 '. ' ' NEW_OFFCR_CD ' 'Officer_Code' of
'FDS_LDN_APLOWNER '. ' ' MY_TRANSACTION_TABLE ' 'MY_TRANSACTION_TABLE3' where
'MY_TRANSACTION_TABLE3 '. » M » (« A », « E », « U », « F ») et
'MY_TRANSACTION_TABLE3 '. ' BASE_DT ' =: PQ1 and.
'MY_TRANSACTION_TABLE3 '. "" NEW_OFFCR_CD "as 'LO %' order by
'Officer_Code' asc nulls last
Hash value of plan: 1213358407
--------------------------------------------------------------------------------------------
| ID | Operation | Name                  | Lines | Bytes | Cost (% CPU). Time |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                       |       |       | 42146 (100) |          |
|   1. UNIQUE FATE |                       |   230. 5750 | 42145 (1) | 00:08:26 |
|* 2 |   TABLE ACCESS FULL | MY_TRANSACTION_TABLE | 4283.   104K | 42144 (1) | 00:08:26 |
--------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
2 filter (("MY_TRANSACTION_TABLE3". "NEW_OFFCR_CD" AS "% LO %' AND
'MY_TRANSACTION_TABLE3 '. ' BASE_DT ' =: PQ1 AND.
INTERNAL_FUNCTION ("MY_TRANSACTION_TABLE3". "M") AND "
'MY_TRANSACTION_TABLE3 '. (("' NEW_OFFCR_CD ' IS NOT NULL))
MY_TRANSACTION_TABLE has 1.3 million records. There is an index made up of 4 columns, first column is BASE_DT and none of the other columns is used here in the predicate.
Questions-
(1) the number the ROWS column in the plan, I guess it's number of selected records in the query (and not the records read by the query). Fix?
(2) there is an index on this table from BASE_DT (but other 3 columns in the index are not used). Each base_dt will select approximately 1.3 M. 80000 records why the index is not used?
(3) the column of time in the plan. Step 1 made by 08:26 minutes and not 2A crossed 08:26 minutes? or steps 1 and 2 together have 08:26 mins?
Thanks in advance

1 LINES - shows the no. of rows estimated by the optimizer for this operation. This estimate is made using the table and column statistics (+ a few formulas can be)

2. with the help of the index is decided by the optimizer based on profit he would get him. Internally, the database comes up with a lot of plan and selects a plan and at low cost. She stated that in light of current statistics rather than index, scanning, beneficial full table scan - so index have not been used.

3. it is worth cumulative - CBO estimated a total 08:26 minutes - similar to the cost. But this chronology may not be necessarily the actual execution time.

Read this link: http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-explain-the-explain-plan-052011-393674.pdf it has almost all the information about the execution plan.

Alarm of inefficient query Plans

SQL Server 5.6 cartridge DBSS - view Instance rule would give alarms for inefficient query Plans. Is it possible to get the same kind of alarms for Query Plans by using the SQL Server and SQL Performance Investigator 5.7 cartridge?

The 'Notice of Performance' function is currently being re-worked in SQL Performance researcher and is therefore not available in version 5.7.

The feature had become a bit bland in the analysis of the performance and I know that the development team has an exciting idea on how to return in a later version. If you have something that you particularly liked, or an idea of how opinions can be improved, we will appreciate the feedback.

explain query plan uses no unique index with where condition

Hi all
I use in the 10.2.0.5 oracle database Enterprise edition 64-bit on 64-bit windows server 2008.
I'm following this tutorial on my own table
Guide to understanding Oracle QUERY PLAN - 10 minutes
my questions are below
```
Analyze table LIB_CLASSIFICATIONS compute statistics;
explain plan for  SELECT class_id  FROM lib_classifications WHERE class_no = '538' ;
select * from table(dbms_xplan.display);
```
the result is less than

Hash value of plan: 3022072076

-----------------------------------------------------------------------------------------

| ID | Operation | Name                | Lines | Bytes | Cost (% CPU). Time |

-----------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT |                     |     1.    10.     5 (0) | 00:00:01 |

|* 1 | TABLE ACCESS FULL | LIB_CLASSIFICATIONS |     1.    10.     5 (0) | 00:00:01 |

-----------------------------------------------------------------------------------------

Information of predicates (identified by the operation identity card):

---------------------------------------------------

1 - filter ("CLASS_NO" = '538')

DESC LIB_CLASSIFICATIONS

Name of Type Null

----------------- -------- -------------

CLASS_ID NOT NULL NUMBER (10)

CLASS_DESC VARCHAR2 (50)

REMARKS VARCHAR2 (250)

CLASS_NO VARCHAR2 (20)

CLASS_TYPE VARCHAR2 (10)

CREATE_USER VARCHAR2 (10)

MODIFY_USER VARCHAR2 (10)

CREATE_DATE DATE

MODIFY_DATE DATE

CLASS_CATEGORY_ID VARCHAR2 (10)

class_id has a primary key.
now when I remove the condition where the query, the result is lower;
```
Analyze table LIB_CLASSIFICATIONS compute statistics;
explain plan for  SELECT class_id  FROM lib_classifications ;
select * from table(dbms_xplan.display);
```
the result is less than

Hash value of plan: 262704430

------------------------------------------------------------------------------------

| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1558. 6232. 2 (0) | 00:00:01 |

| 1. FULL RESTRICTED INDEX SCAN FAST | SYS_C005653 | 1558. 6232. 2 (0) | 00:00:01 |

------------------------------------------------------------------------------------

now it's using indexes with INDEX FAST FULL SCAN.
I need the index using the WHERE condition as well.
How to do this?
Thank you.

you have indexes on the column class_id not on class_no column how u would expect index to use when there is no index on the column class_no

Need help to get the actual execution plan

I need to get the actual execution plan of a query and its actual cost.
If I understand correctly explaining the plan gives only the estimated according to my plan. Can someone help me please?

I'm doing this:

SQL> select OBJECT_NAME,DATA_OBJECT_ID,STATUS from dba_objects where owner='SANTU';

OBJECT_NAME
                                                 DATA_OBJECT_ID STATUS
--------------------------------------------------------------------------------
------------------------------------------------ -------------- -------
TST_REDEF
                                                          73444 VALID
REDEF_PK
                                                          73447 VALID

SQL> select sql_id,sql_text from v$sqlarea where sql_text like '%DATA_OBJECT_ID,STATUS from dba_objects%';

SQL_ID
-------------
SQL_TEXT
--------------------------------------------------------------------------------
gbvnfhs59t98f
select sql_id,sql_text from v$sqlarea where sql_text like '%DATA_OBJECT_ID,STATUS from dba_objects%'

bxdyf6ph2g3ay
select OBJECT_NAME,DATA_OBJECT_ID,STATUS from dba_objects where owner='SANTU'

SQL> select * from table(dbms_xplan.display_cursor('bxdyf6ph2g3ay'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
SQL_ID  bxdyf6ph2g3ay, child number 0
-------------------------------------
select OBJECT_NAME,DATA_OBJECT_ID,STATUS from dba_objects where
owner='SANTU'

Plan hash value: 2160718650

------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |             |       |       |    47 (100)|          |
|   1 |  VIEW                            | DBA_OBJECTS |  1638 |   161K|    47 (3)| 00:00:01 |
|   2 |   UNION-ALL                      |             |       |       |    |          |
|*  3 |    FILTER                        |             |       |       |    |          |
|*  4 |     HASH JOIN                    |             |  1830 |   209K|    46 (3)| 00:00:01 |
|   5 |      INDEX FULL SCAN             | I_USER2     |    88 |  1936 |     1 (0)| 00:00:01 |
|   6 |      NESTED LOOPS                |             |  1830 |   169K|    45 (3)| 00:00:01 |
|   7 |       TABLE ACCESS BY INDEX ROWID| USER$       |     1 |    18 |     1 (0)| 00:00:01 |
|*  8 |        INDEX UNIQUE SCAN         | I_USER1     |     1 |       |     0 (0)|          |
|*  9 |       TABLE ACCESS FULL          | OBJ$        |  1830 |   137K|    44 (3)| 00:00:01 |
|* 10 |     TABLE ACCESS BY INDEX ROWID  | IND$        |     1 |     8 |     2 (0)| 00:00:01 |
|* 11 |      INDEX UNIQUE SCAN           | I_IND1      |     1 |       |     1 (0)| 00:00:01 |
|  12 |     NESTED LOOPS                 |             |     1 |    29 |     2 (0)| 00:00:01 |
|* 13 |      INDEX FULL SCAN             | I_USER2     |     1 |    20 |     1 (0)| 00:00:01 |
|* 14 |      INDEX RANGE SCAN            | I_OBJ4      |     1 |     9 |     1 (0)| 00:00:01 |
|  15 |    NESTED LOOPS                  |             |     1 |    97 |     1 (0)| 00:00:01 |
|  16 |     TABLE ACCESS BY INDEX ROWID  | USER$       |     1 |    18 |     1 (0)| 00:00:01 |
|* 17 |      INDEX UNIQUE SCAN           | I_USER1     |     1 |       |     0 (0)|          |
|* 18 |     INDEX RANGE SCAN             | I_LINK1     |     1 |    79 |     0 (0)|          |
------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter(((("O"."TYPE#"<>1 AND "O"."TYPE#"<>10) OR ("O"."TYPE#"=1 AND =1))
AND
              (("O"."TYPE#"<>4 AND "O"."TYPE#"<>5 AND "O"."TYPE#"<>7 AND "O"."TYPE#"<>8 AND
              "O"."TYPE#"<>9 AND "O"."TYPE#"<>10 AND "O"."TYPE#"<>11 AND "O"."TYPE#"<>12 AND
              "O"."TYPE#"<>13 AND "O"."TYPE#"<>14 AND "O"."TYPE#"<>22 AND "O"."TYPE#"<>87 AND
              "O"."TYPE#"<>88) OR BITAND("U"."SPARE1",16)=0 OR (INTERNAL_FUNCTION("O"."TYPE#") AND
              ((SYS_CONTEXT('userenv','current_edition_name')='ORA$BASE' AND "U"."TYPE#"<>2) OR
              ("U"."TYPE#"=2 AND "U"."SPARE2"=TO_NUMBER(SYS_CONTEXT('userenv','current_edition_id')))
              OR  IS NOT NULL)))))
   4 - access("O"."OWNER#"="U"."USER#")
   8 - access("U"."NAME"='SANTU')
   9 - filter(("O"."NAME"<>'_NEXT_OBJECT' AND "O"."NAME"<>'_default_auditing_opt
ions_'
              AND "O"."LINKNAME" IS NULL AND BITAND("O"."FLAGS",128)=0 AND "O"."
SPARE3"="U"."USER#"))
  10 - filter(("I"."TYPE#"=1 OR "I"."TYPE#"=2 OR "I"."TYPE#"=3 OR "I"."TYPE#"=4
OR
              "I"."TYPE#"=6 OR "I"."TYPE#"=7 OR "I"."TYPE#"=9))
  11 - access("I"."OBJ#"=:B1)
  13 - access("U2"."TYPE#"=2 AND "U2"."SPARE2"=TO_NUMBER(SYS_CONTEXT('userenv','
current_
              edition_id')))
       filter(("U2"."TYPE#"=2 AND "U2"."SPARE2"=TO_NUMBER(SYS_CONTEXT('userenv',
'current
              _edition_id'))))
  14 - access("O2"."DATAOBJ#"=:B1 AND "O2"."TYPE#"=88 AND "O2"."OWNER#"="U2"."US
ER#")
  17 - access("U"."NAME"='SANTU')
  18 - access("L"."OWNER#"="U"."USER#")

57 rows selected.

SQL>

Execution plans

Kind regards
S.K.

Query Plan changes when a static value is assigned to an update
I have a table
```
SQL> create table test
  2  as
  3  select '001' col
  4    from dual
  5  connect by level <= 15000
  6  /

Table created.

SQL> exec dbms_stats.gather_table_stats('SYSADM','TEST',CASCADE=>TRUE)

PL/SQL procedure successfully completed.
```
Now, I want to update the table so that each 5000 lines to be incremented as the value pass
001.002... and so on.

I did it.
```
SQL> set autotrace traceonly explain
SQL> set timing on
SQL> update test t
  2     set col = (select to_char(trunc(rno/5000)+1,'fm009')
  3             from (select row_number() over(order by rowid) rno,
  4                               rowid
  5                     from test) t1
  6             where t.rowid = t1.rowid)
  7  /

15000 rows updated.

Elapsed: 00:03:49.06

Execution Plan
----------------------------------------------------------
   0      UPDATE STATEMENT Optimizer=ALL_ROWS (Cost=8 Card=15000 Bytes=60000)
   1    0   UPDATE OF 'TEST'
   2    1     TABLE ACCESS (FULL) OF 'TEST' (TABLE) (Cost=8 Card=15000 Bytes=60000)
   3    1     VIEW (Cost=55 Card=15000 Bytes=375000)
   4    3       WINDOW (SORT) (Cost=55 Card=15000 Bytes=60000)
   5    4         TABLE ACCESS (FULL) OF 'TEST' (TABLE) (Cost=8 Card=15000 Bytes=60000)

SQL> rollback
  2  /

Rollback complete.

Elapsed: 00:00:01.00
```
It works very well. But what I discovered is. When I change the update above. And replace the
TO_CHAR (trunc(RNO/5000) + 1, 'fm009') with a static value as '1' the query plan changes and
It runs very quickly.
```
SQL> update test t
  2     set col = (select '1'--to_char(trunc(rno/5000)+1,'fm009')
  3             from (select row_number() over(order by rowid) rno,
  4                               rowid
  5                     from test) t1
  6             where t.rowid = t1.rowid)
  7  /

15000 rows updated.

Elapsed: 00:00:00.01


Execution Plan
----------------------------------------------------------
   0      UPDATE STATEMENT Optimizer=ALL_ROWS (Cost=8 Card=15000 Bytes =60000)
   1    0   UPDATE OF 'TEST'
   2    1     TABLE ACCESS (FULL) OF 'TEST' (TABLE) (Cost=8 Card=15000 Bytes=60000)
   3    1     TABLE ACCESS (BY USER ROWID) OF 'TEST' (TABLE) (Cost=1 Card=1 Bytes=4)

SQL> rollback
  2  /

Rollback complete.

Elapsed: 00:00:01.00
```
Why is it so. Can someone explain?
Karthick_Arp wrote:
SQL > update of test t
2 set col = (select to_char (trunc(rno/5000) + 1, 'fm009'))
3 from (select row_number() over (order by rowid) rno,
4 rowid
5 test) t1
6 where t.rowid = t1.rowid)
7.

15000 lines to date.

Execution plan
----------------------------------------------------------
STATEMENT UPDATE 0 = ALL_ROWS optimizer (cost = card 8 = 15000 bytes = 60000)
1 0 UPDATE OF 'TEST '.
2 1 TABLE ACCESS (FULL) 'TEST' (TABLE) (cost = card 8 = 15000 bytes = 60000)
3 1 VIEW (cost = map 55 = 15000 bytes = 375000)
4 WINDOW 3 (TRI) (cost = map 55 = 15000 bytes = 60000)
5 4 TABLE ACCESS (FULL) 'TEST' (TABLE) (cost = card 8 = 15000 bytes = 60000)

SQL > update of test t
2 set col = (select '1' - to_char (trunc(rno/5000) + 1, 'fm009'))
3 from (select row_number() over (order by rowid) rno,
4 rowid
5 test) t1
6 where t.rowid = t1.rowid)
7.

15000 lines to date.

Execution plan
----------------------------------------------------------
STATEMENT UPDATE 0 = ALL_ROWS optimizer (cost = card 8 = 15000 bytes = 60000)
1 0 UPDATE OF 'TEST '.
2 1 TABLE ACCESS (FULL) 'TEST' (TABLE) (cost = card 8 = 15000 bytes = 60000)
3 1 ACCESS TABLE (BY USER ROWID) OF 'TEST' (TABLE) (cost = 1 card = 1 bytes = 4)

Why is it so. Can someone explain?

In addition to what Rob has already said, the answer to your question is: given that the optimizer is smart and recognizes that your WINDOW TYPE in your second query (aka NWR) is never accessible and therefore simply ignores this part of the application. It turns it to a simple statement like this:
```
update test t
   set col = (select '1'
           from (select rowid
                   from test) t1
           where t.rowid = t1.rowid);
```
who can simply access the TEST table for each row of rowid, while your first query should do recursively for each TEST line full table scan. Using a statistics AUTOTRACE, you should see a large difference in e/s logic for both statements.

Using DBMS_XPLAN. DISPLAY could reveal more details what happens, if you're already on 9i or later version (seems to be 9iR2).

Kind regards
Randolf

Oracle related blog stuff:
http://Oracle-Randolf.blogspot.com/

SQLTools ++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676 /.
http://sourceforge.NET/projects/SQLT-pp/

Java: Making query plans persistent
Sorry if this is a repost from the other thread, but that is the ultimate question.

I have around 200-300 unique queries (this is a worst case scenario, but against what I run upward at the moment) that must be performed on the DBXML. The queries themselves last about 300-400 ms. If I first prepare these queries and then use the returned XmlQueryExpression, queries return 0ms and less then average. It seems that the majority of treatment is actually being with the back-end query optimization and forming part of the execution. Unfortunately, the record of the 200-300 XmlQueryExpression in memory is not a valid option because this increases memory usage a lot. The problem is that there are inherent with the underlying DBXML instability and sometimes the database switches and must be restarted, which means that the XmlQueryExpression must be replaced later...

An example would be for a unique look, several objects should be returned from the database - each of these objects, if they took 300-400ms would add 3-4 seconds per unique rendering and if this situation worsened with a single rendered rendered several renders, then return to 15-16 seconds is likely. These compounds as more and more users access the system and must therefore be reduced as much as humanly possible.

The question is multi fold:
(1) is there a way so that the XmlQueryExpressions can be serialized and reused later-(l'idée serait de stocker éventuellement dans une cache de type structure/filesystem/base de données/etc...)?
(2) is it possible to create a XmlQueryExpression with an existing query Plan for failing to make the entire expression on each go-around (same number 1 but to approach different idea)?
(3) (another issue) being the transactional database - what I need to do something with the explicit transactions and undertakes on these objects of XmlQueryExpression despite the requests themselves are only, read-only? In other words I have to commit after. prepare(), but not on. execute()? Everything works fine without the use of transactions on the ready then I guess not.
(4) is there another way I can optimize it? With hundreds of access/renders/objects read at some point, the system latency must be reduced as much as possible - by creating the XmlQueryExpression I compensate for the latency for the first time that the query is running, however over time that there is this pretty red and green baloon memory and I need a way of popping it.
Hello Stephen,

What version of XML DB are you using? If you use XML DB 2.4.13, there will soon be a new version of patch that significantly reduced the memory used by the previously analyzed queries.

It is rare to find someone who needs to execute queries different as - is possible that you could be better off by combining some of the queries?

(1) is there a way so that the XmlQueryExpressions can be serialized and reused later-(l'idée serait de stocker éventuellement dans une cache de type structure/filesystem/base de données/etc...)?
(2) is it possible to create a XmlQueryExpression with an existing query Plan for failing to make the entire expression on each go-around (same number 1 but to approach different idea)?

There is no way to do at the moment.

(3) (another issue) being the transactional database - what I need to do something with the explicit transactions and undertakes on these objects of XmlQueryExpression despite the requests themselves are only, read-only? In other words I have to commit after. prepare(), but not on. execute()? Everything works fine without the use of transactions on the ready then I guess not.

Prepares a query should probably be in an explicit transaction for transactional applications, but this transaction can safely be validated after the preparation of the query without for as much invalidating the XmlQueryExpression object.

(4) is there another way I can optimize it? With hundreds of access/renders/objects read at some point, the system latency must be reduced as much as possible - by creating the XmlQueryExpression I compensate for the latency for the first time that the query is running, however over time that there is this pretty red and green baloon memory and I need a way of popping it.

Why not maintain that sort less recently used (LRU) cache prepared queries? My guess is that you will have a small number of queries that get used a lot, and others who do not get used much at all.

John

How to get the SQL query running of af: search?

I use JDeveloper 11.1.2.3.0. I have a page where I've set up an af:query and an array of result. The problem is that I can't get the exact query that is used during the execution of this component in a managed bean method. Is it possible to get the query string that is run within the af: query?
Thank you

Hello

Method of the ViewObject getQuery() returns what you need;

You can replace the executeQueryForCollection(), and prior to calling super, you can print the result of getQuery() method:

public void executeQueryForCollection (rowset Object,

Object [] params,

{int noUserParams)

System.out.println ("SQL =" + getQuery());

call the super method here...

}

I have CC on my laptop now have bought a new desktop computer and downloaded top CC, but failed to get a second organized plan

I have CC on my laptop now have bought a new desktop computer and downloaded top CC, but failed to get a second organized plan?

disconnect and then again on your desktop computer 2nd cc, sign, sign | Creative desktop application Cloud

If this does not resolve the problem, attach a screenshot showing the problem.

What is the best query plan
Hi all

Please help me choose the query plan. You can tell me which is the best plan for the No. 1 query plan or no plan No 2
Map 1:

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 442504905

-----------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 1. 325. 13222 (1) | 00:02:39 |
| 1. SORT ORDER BY | 1. 325. 13222 (1) | 00:02:39 |
| 2. UNIQUE HASH | 1. 325. 13221 (1) | 00:02:39 |
| 3. NESTED LOOPS |
| 4. NESTED LOOPS | 1. 325. 13220 (1) | 00:02:39 |
| 5. NESTED LOOPS | 1. 224. 13217 (1) | 00:02:39 |

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 6. NESTED LOOPS | 1. 199. 13216 (1) | 00:02:39 |
| 7. NESTED LOOPS | 1. 144. 13215 (1) | 00:02:39 |
|* 8 | HASH JOIN | 1. 93. 13212 (1) | 00:02:39 |
|* 9 | TABLE ACCESS FULL | REC_EPS | 787. 25184 | 742 (2) | 00:00:09 |
| * 10 | TABLE ACCESS FULL | RECEIPTDETAIL | 1059K | 61 M | 12462 (1) | 00:02:30 |
| * 11 | TABLE ACCESS BY INDEX ROWID | LOTXLOCXID | 1. 51. 3 (0) | 00:00:01 |
| * 12 | INDEX RANGE SCAN | IDX_LLI_ISQ | 1 | | 2 (0) | 00:00:01 |
| 13. TABLE ACCESS BY INDEX ROWID | CODELKUP | 1. 55. 1 (0) | 00:00:01 |
| * 14 | INDEX UNIQUE SCAN | PK_SYS_C004623 | 1 | | 0 (0) | 00:00:01 |
| 15. TABLE ACCESS BY INDEX ROWID | RECEPTION | 1. 25. 1 (0) | 00:00:01 |
| * 16. INDEX UNIQUE SCAN | PK_SYS_C004755 | 1 | | 0 (0) | 00:00:01 |

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| * 17. INDEX RANGE SCAN | PK_SYS_C004767 | 1 | | 2 (0) | 00:00:01 |
| 18. TABLE ACCESS BY INDEX ROWID | SKU | 1. 101 | 3 (0) | 00:00:01 |
-----------------------------------------------------------------------------------------------------

Information of predicates (identified by the operation identity card):
---------------------------------------------------

8 - access("RECEIPTDETAIL".") RECEIPTKEY «= SYS_OP_C2C ("REC_EPS".» ASNKEY') AND
'RECEIPTDETAIL '. "' SKU ' = SYS_OP_C2C ("REC_EPS". » « « « SKU »))
9 filter (SYS_OP_C2C ("REC_EPS". "ASNKEY") > = U '0' AND "
SYS_OP_C2C ("REC_EPS". ("ASNKEY") < = U'ZZZZZ ")

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
10 - filter("RECEIPTDETAIL".") RECEIPTKEY' > = U "0" AND "RECEIPTDETAIL". "" RECEIPTKEY "< = U'ZZZZZ") "
11 - filter("LOTXLOCXID".") LOC "= U 'STAGE')
12 - access("RECEIPTDETAIL".") TOLD "=" LOTXLOCXID. " "" IDENTITY CARD "AND
'RECEIPTDETAIL '. ' ' SKU '=' LOTXLOCXID. ' "' SKU ' AND 'LOTXLOCXID '. ("' QTY ' > 0)
14 - access ("LISTNAME"= U 'RECSTATUS' AND "CODELKUP"." "RECEIPTDETAIL"="CODE". ("' STATUS ')
16 - access("RECEIPTDETAIL".") RECEIPTKEY "=" RECEPTION ". ("' RECEIPTKEY")
filter ("RECEPTION". "RECEIPTKEY" > = U '0' AND 'RÉCEPTION' "." " RECEIPTKEY"< = U'ZZZZZ") "
17 - access("RECEIPTDETAIL".") SKU "=" SKU ". ("' SKU ')

41 selected lines.
=================================================================

Plan No. 2:

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 1174712643

----------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 1. 325. 18382 (1) | 00:03:41 |
| 1. SORT ORDER BY | 1. 325. 18382 (1) | 00:03:41 |
| 2. UNIQUE HASH | 1. 325. 18381 (1) | 00:03:41 |
|* 3 | HASH JOIN | 1. 325. 18380 (1) | 00:03:41 |
| 4. NESTED LOOPS |
| 5. NESTED LOOPS | 1. 293. 17637 (1) | 00:03:32 |

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 6. NESTED LOOPS | 1. 192. 17634 (1) | 00:03:32 |
| 7. NESTED LOOPS | 1. 167. 17633 (1) | 00:03:32 |
| 8. NESTED LOOPS | 2. 224. 17631 (1) | 00:03:32 |
|* 9 | TABLE ACCESS BY INDEX ROWID | LOTXLOCXID | 2. 102. 3 (0) | 00:00:01 |
| * 10 | INDEX RANGE SCAN | IDX_LOTXLOCXID_LOC | 2 | | 1 (0) | 00:00:01 |
| * 11 | TABLE ACCESS BY INDEX ROWID | RECEIPTDETAIL | 1. 61. 8814 (1) | 00:01:46 |
| * 12 | INDEX SCAN FULL | IDX_RD_QCREQ | 1 | | 8813 (1) | 00:01:46 |
| 13. TABLE ACCESS BY INDEX ROWID | CODELKUP | 1. 55. 1 (0) | 00:00:01 |
| * 14 | INDEX UNIQUE SCAN | PK_SYS_C004623 | 1 | | 0 (0) | 00:00:01 |
| 15. TABLE ACCESS BY INDEX ROWID | RECEPTION | 1. 25. 1 (0) | 00:00:01 |
| * 16. INDEX UNIQUE SCAN | PK_SYS_C004755 | 1 | | 0 (0) | 00:00:01 |

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| * 17. INDEX RANGE SCAN | PK_SYS_C004767 | 1 | | 2 (0) | 00:00:01 |
| 18. TABLE ACCESS BY INDEX ROWID | SKU | 1. 101 | 3 (0) | 00:00:01 |
| * 19. TABLE ACCESS FULL | REC_EPS | 787. 25184 | 742 (2) | 00:00:09 |
----------------------------------------------------------------------------------------------------------

Information of predicates (identified by the operation identity card):
---------------------------------------------------

3 - access("RECEIPTDETAIL".") RECEIPTKEY «= SYS_OP_C2C ("REC_EPS".» ASNKEY') AND
'RECEIPTDETAIL '. "' SKU ' = SYS_OP_C2C ("REC_EPS". » « « « SKU »))
9 - filter("LOTXLOCXID".") QTY' > 0)

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
10 - access("LOTXLOCXID".") LOC "= U 'STAGE')
11 - filter("RECEIPTDETAIL".") RECEIPTKEY' > = U "0" AND "RECEIPTDETAIL". "" RECEIPTKEY "< = U'ZZZZZ") "
12 - access("RECEIPTDETAIL".") SKU "=" LOTXLOCXID. " "' SKU ' AND
'RECEIPTDETAIL '. "" TOLD "=" LOTXLOCXID. " (' ' ID ')
filter ("RECEIPTDETAIL". "TOLD"="LOTXLOCXID" "." " IDENTITY CARD"AND
'RECEIPTDETAIL '. ' ' SKU '=' LOTXLOCXID. ' ("' SKU ')
14 - access ("LISTNAME"= U 'RECSTATUS' AND "CODELKUP"." "RECEIPTDETAIL"="CODE". ("' STATUS ')
16 - access("RECEIPTDETAIL".") RECEIPTKEY "=" RECEPTION ". ("' RECEIPTKEY")
filter ("RECEPTION". "RECEIPTKEY" > = U '0' AND 'RÉCEPTION' "." " RECEIPTKEY"< = U'ZZZZZ") "
17 - access("RECEIPTDETAIL".") SKU "=" SKU ". ("' SKU ')
19 - filter (SYS_OP_C2C ("REC_EPS". "ASNKEY") > = U '0' AND SYS_OP_C2C ("REC_EPS". " ASNKEY") < = U'ZZZZZ") "

44 selected lines.
Did you test them? You do not have us given information on why you want to use one over the other... For example, do you need to recover as soon as possible all lines or do you want the first rows as quickly as possible? Given that you did not formatting on your plans and we do not request or background, we can say nothing. Even for an experienced DBA/developer - it is not always possible to read a plan and determine which is the 'best' - test and then you can tell us.

To the topic to explain the query Plan
Hello

I have a question about the explain plan command. While gather us statistics and optimize, then choose the best possible plan out the plans explain command available. If we collect statistics on a table for a long time while the system choose:

Whether it will continue to use the same plan, since it uses at startup when statistics have been collected, or will change the plan as soon as dml activities and statistics grow old.

Thank you
GK
Gulshan says:
Hello

I have a question about the explain plan command. While gather us statistics and optimize, then choose the best possible plan out the plans explain command available. If we collect statistics on a table for a long time while the system choose:

The same plan he chose to start with previous statistics. The plan will not change automatically as long as you update the statistics.

Whether it will continue to use the same plan, since it uses at startup when statistics have been collected, or will change the plan as soon as dml activities and statistics grow old.

The DML will not be able to change the statistics stored in the data dictionary views themselves. There must be a statistic explicit collection that has come to reflect the change in the data dictionary. 10 g from, there is automatically a task (a special 11 g automatic) is there who can detect the change in the ongoing dml on the table and can trigger the table for update statistics.

Aman...

How we can get statistics current preferences for the t value specified
We use DBMS_STATS. Procedure SET_TABLE_PREF to set preferences to statistics on the table specified in the specified schema.
How we can get statistics current value of preferences for the specified table?
Of course, you can use the DBMS_STATS. Function GET_PREFS to check the attributes of statistics.
For example, to collect statistics of large properly partitioned tables, you can change the INCREMENT value:

For each, check that the current value of the table:
```
SQL> select dbms_stats.get_prefs('INCREMENTAL','SH','COSTS') from dual;

DBMS_STATS.GET_PREFS('INCREMENTAL','SH','COSTS')
--------------------------------------------------------------------------------
FALSE
```
Change the value for the table in question:
```
SQL> exec dbms_stats.set_table_prefs('SH','COSTS','INCREMENTAL' ,'TRUE') ;
PL/SQL procedure successfully completed.

SQL> select dbms_stats.get_prefs('INCREMENTAL','SH','COSTS') from dual;
DBMS_STATS.GET_PREFS('INCREMENTAL','SH','COSTS')
--------------------------------------------------------------------------------
TRUE
```

Query does not get scanned with Explain plan index
Hello
I have a table with Index XXQP_SAMPLE_N1 in PROCESS_FLAG column. When I run the query below and see the plan to explain it, this table is to get access full table (with red color in Toad). It's not scan with the index. I also analyzed the table with command below. can anyone tell why he does not get scanned with index?

exec DBMS_STATS.gather_table_stats ('XXQP', 'XXQP_SAMPLE', estimate_percent = > 30, cascade = > true);

SELECT
*
Of
XXQP_SAMPLE
WHERE
process_flag = 1;

Thank you
the number of records in the table to satisfy the condition process_flag = 1

I wrote a little note on this topic. Reade case 1. It may be of your interest.

http://karthickarp.blogspot.com/2008/12/it-is-often-asked-why-SQL-is-going-for.html

Published by: Karthick_Arp on April 15, 2009 01:41

connection pool and inefficient query plan

There is a single query that covers almost 90% of cpu DB.
Select * from employee e, Department d where e.departement_id = d.department_id
Us will gather statistics for this table in two, and the issues is resolved.
This occurs every 2 weeks. That said, the query runs fine for 2 weeks and then we have questions... we will bring together the statistics of these two tables... and things are good for another 2 weeks.
This query is a proc to store oracle pl - sql, which is called by the JDBC code. I introduced 2 months behind connection pooling, and today, we are facing this problem.
The query has been accounting for 5 years with no problems.
Before that I presented the connection pool, the jdbc code created a new connection before calling the store proc.
Do you think that my connection to the connection pool has introduced this problem.
The DBA tell me that the query runs a bad plan. Oracle recovers not the more effective plan (and that leads to this high CPU utilization).
I guess that after 2 weeks Oracle begins to pick up plans that are effective in.
Do you think all that this question never has nothing to do with my connection pooling code.
I use Oracle 10 G.

Hi Mike and ground beach thanks for your response.

It was just a doubt... that you guys allowed.

Thank you

m

Get statistics of query Plan

Similar Questions

Maybe you are looking for