Calculating estimated rows in query plan

Hi,
I'm trying to do one calculation over statistics, but I can't achieve the correct value.
The query is the following:
select * from product where
productid between 1387 and 1392
The result for estimated rows is 5,81583.
The histogram:
Considering the Avg_Range_Rows field the result should be 6, so I suppose this field is rounded.
Trying to do the calculation, I notice there are 132 possible key values between the two histogram keys. There are 126 rows (range_rows), so 126/132 = 0.95454545 . Multiply by 6 = 5.72727272, it doesn't achieve the value in query plan.
Trying the opposite way: 5,81583/6 = 0.969305 * 132=127.94826 . I don't understand how SQL Server is calculating this.
Thank you for the help !
Cheers,
Dennes - Se resolveu, classifique a mensagem, por favor - [http://www.bufaloinfo.com.br] NOVO DVD Segurança no ASP.NET : http://www.bufaloinfo.com.br/LearingSeriesSegurancaASPNET2.asp

Dennes
>>>Considering the Avg_Range_Rows field the result should be 6
It is 1
AVG_RANGE_ROWS is the average number of rows per distinct value and it is calculated as RANGE_ROWS / DISTINCT_RANGE_ROWS. In your example, we have a total of 126 records
for 126 DISTINCT_RANGE_ROWS, so that gives, 126/126 = 1 also shown on the histogram for AVR_RANGE_ROWS
http://sqlblog.com/blogs/ben_nevarez/archive/2009/09/04/statistics-used-by-the-query-optimizer-in-sql-server-white-paper.aspx
Best Regards,Uri Dimant SQL Server MVP,
http://sqlblog.com/blogs/uri_dimant/
MS SQL optimization: MS SQL Development and Optimization
MS SQL Consulting:
Large scale of database and data cleansing
Remote DBA Services:
Improves MS SQL Database Performance
SQL Server Integration Services:
Business Intelligence

Similar Messages

Estimated Row Count Query. How to avoid?

Hi,
I use Jdeveloper 9.0.3. Production to evaluate its capability with swing JClient. I found that before the form is shown on the desktop the framework runs the quety like this.
SELECT /*+ ORDERED USE_NL(RtEmployee) USE_NL(RtUnitmeasure) USE_NL(RtGroupcode) */ count(1) FROM (SELECT RtProduct.PRODUCTID, RtProduct.ID_UM, RtUnitmeasure.SHORTNAMERUS, RtProduct.ID_COMMON, RtProduct.NAMERUS, RtProduct.NAMEENG, RtProduct.ID_GROUPCODE, RtGroupcode.GROUPCODE, RtProduct.IS_GRCODEFAULT, RtProduct.VAT, RtProduct.PRICE_U, RtProduct.MINPRICE, RtProduct.MARKUP, RtProduct.IS_DISCOUNT, RtProduct.NOTE, RtEmployee.SURNAME, RtProduct.CREATEDATE, RtProduct.MODIFYDATE, RtProduct.ID_OPERATOR, RtProduct.ID, RtUnitmeasure.ID AS ID1, RtGroupcode.ID AS ID2, RtEmployee.ID AS ID3 FROM RT_PRODUCT RtProduct, RT_EMPLOYEE RtEmployee, RT_UNITMEASURE RtUnitmeasure, RT_GROUPCODE RtGroupcode WHERE ((RtProduct.ID_OPERATOR = RtEmployee.ID)AND (RtProduct.ID_UM = RtUnitmeasure.ID))AND (RtProduct.ID_GROUPCODE = RtGroupcode.ID))
to estimate dataset cardinality.
Attention development team. Plase pay attention that the statement is badly formed as
Hints entered into "Query Hint" field of the VO is placed in outer query but intended to use in sub query and will not be taken into account by optimizer!
My question is how to avoid this query and/or how can I replace a functionality for estimating dataset cardinality by user defined function or so?
Best regards,
Vyacheslav

I tried the suggested solution but could not figure
out how to get the current query string to extract
the WHERE clause to use in my own query or to get the
parameters to build my own WHERE. How about a more
explicit code example?
Joe:
A few different ways to do this. First, note that getQueryHitCount()
method receives the following parameter:
ViewRowSetImpl viewRowSet
To get the entire query statement, you can call
String entireQuery = vo.getQuery();
For each row set (identified by the viewRowSet parameter), you have a
set of where-clause parameters. Some of these are user provided
(through setWhereClauseParam calls) and some of these are system
provided (system provided params are primarily for view links).
To get all where-clause params (both user and system params), you
call:
Object[] paramVals = viewRowSet.getParametersAsStorageTypes();
Again, paramVals include both user and system param vals.
If you do
int noUserParams = viewRowSet.getWhereClauseParams().length;
noUserParams will tell how many of these are user supplied:
paramVals[0] .. paramVals[noUserParams-1] are user supplied and the
rest are system supplied.
If you want to get the Long postings are being truncated to ~1 kB at this time.

Select Query Hangs / No DB Locks / Query Plan is good

I have below query in application which hangs ( Only sometimes ) and there are some session which also try to insert data into this tables also starts getting hanged.
SELECT DISTINCT F2 || ' - ' || F3 || ' - ' || F4
FROM Table1
WHERE F4 = 6160
AND F1|| F2|| F3 NOT IN (
SELECT F2|| F3 || F4
FROM Table2
WHERE F1 = 181)
F2 - varchar(4)
F3- varchar(100)
F4- varchar(20)
F1,F1 are NUMBER
Table1 has one unique index comprising all fields in ORDER F1,F2, X,F3, F4,Y - X,Y are some different field.
Table2 has one unique index comprising all fields in ORDER F1,F3, F4,F2 are some different field.
Below are facts from DBA ----
1- Session Query Plan was excellent -
2 - No tables were locked in DB
3 - Statistics on this table Table1 was calculated on Feb, 2008 and shows 8 millions rows but actual current row count is 13 million. DBA says sometime analyzing statistics again may cause poor query performance.
4- There were 8 session in DB, 1 was for above select statement and other 7 were trying to insert data into above table.
Can you please advise what could else be verified to root cause issue as it has been hanging many times - hence causing other session to hang ?
Many Thanks

Can you clarify exactly what the DBA meant by "No tables were locked in DB"? What was the exact query that was used to determine this? Was it hitting V$LOCK (GV$LOCK in a RAC system)? Or the DBA_BLOCKERS and DBA_WAITERS tables? Or something else? The specific query here is important because there is a world of difference between a row-level lock and a table-level lock. Of course, locks would never prevent a SELECT statement from running, but it could cause problems for the INSERT statements.
I strongly concur with Old DBA's suggestion about refactoring the query to not do the concatenation in the NOT IN clause.
Are the F4 = 6160 and F1 = 181 conditions really using hard-coded numeric literals? Or are these bind variables? Is the data in F1 or F4 skewed-- that is, are there certain values that are more likely than other values?
How many rows would you expect to be in Table1 with an F4 value of 6160? How many rows in Table2 with a F1 value of 181?
Justin

Estimated row count

hello
i used estimatedrowcount on several occasions in my application to hide and show certain parts of the screen (normally in EL expressions)
why is it called ESTIMATED and not EXACT. Of course, there is a reason why i ask,
sometimes and in certain pages in which i add new row, it is not also the case that the value of EstimatedRowcount is always updated when a new row is inserted. Also what if another use is adding rows through the same page but from a different browser (different instance of the same applications).
In other words, when does the framework issues SELECT count() on the page to reflect an updated SELECT count().
In certain situation , i had to create VO in order to make sure that i control that the count() is specifically calculated when i need since i noticed that the default EstimatedRowCount does not always give the expected result and henceforth, could be unwise to depend on it to control the logic
rgds
ammar sajdi
Amman jordan

You are right, the estimated row count does not query the database every time you call the method. It just is designed to give you the estimated row count in the context of the "current query" of the VO. So, you perform a query. After the query is performed, the table binding, for example, calls the getEstimatedRowCount() method to determine how many rows are to be expected (keep in mind that probably not all rows are fetched at once after the query). Nothing wrong with that. The ViewObject is executed, 20 rows are fetched, the estimated row count tells the binding that there are 100 rows in the result. If then another user inserts a new row, then that typically will have no effect on the 100 rows, meaning you won't get 101 rows at a sudden. If you scroll through the result set, you will get the 100 rows. In order to get 101 rows, you will need to re-execute the query. Then the table binding will get the estimated row count and it will be 101.
As soon as the fetch is complete, meaning that all rows are fetched from the database and are in memory, then getEstimatedRowCount() no longer accesses the database (why should it?!) but just returns the count of fetched rows. Of course, taking into account any unposted rows that you may have created.
If you really want the row count from the database, why don't you just call getQueryHitCount()? Why must it be getEstimatedRowCount()?!
Sascha

Query plan and negative value in where

I have a question about this query:
select g.col1,
g.col2
from tab1 g,
tab2 part
where part.col3 <> 0
and g.col4 = 'PRO3'
and g.col2 = part.col5
and g.cod7 = -1
This is the execution plan:
SELECT STATEMENT, GOAL = ALL_ROWS
HASH JOIN
INDEX FAST FULL SCAN     SYS_C00254422     14     22453     516419
TABLE ACCESS FULL     TAB2     920     67458     1079328
If I change the select in this way:
select g.col1,
g.col2
from tab1 g,
tab2 part
where part.col3 <> 0
and g.col4 = 'PRO3'
and g.col2 = part.col5
and -g.cod7 = 1
I have a new query plan:
SELECT STATEMENT, GOAL = ALL_ROWS
NESTED LOOPS
INDEX FAST FULL SCAN     SYS_C00254422
TABLE ACCESS BY INDEX ROWID          TAB2
INDEX UNIQUE SCAN          SYS_C00254336
Oralce use a nested loop and the index of the table TAB1 and doesn't do the hash join.
Why?
I use oracle 10g
Message was edited by:
user613483
Message was edited by:
user613483

SQL> desc TAB1
Name Null? Type
COL1 NOT NULL VARCHAR2(5)
COL4 NOT NULL VARCHAR2(5)
COL2 NOT NULL VARCHAR2(15)
COL7 NOT NULL NUMBER(3)
DTCOL8 NOT NULL DATE
DRcol9 DATE
LEVcol10 NUMBER(3)
COL11 VARCHAR2(30)
COD12 VARCHAR2(15)
LEV13 NUMBER(3)
COD14 VARCHAR2(15)
LEV15 NUMBER(3)
COD16 VARCHAR2(15)
LEVN17 NUMBER(3)
COD18 VARCHAR2(15)
LEV19 NUMBER(3)
CODNOD20 VARCHAR2(15)
LEVNO21 NUMBER(3)
CODNOD22 VARCHAR2(15)
LEVN23 NUMBER(3)
COD24 VARCHAR2(15)
LEV25 NUMBER(3)
CODNOD26 VARCHAR2(15)
L27 NUMBER(3)
CODN28 VARCHAR2(15)
LEV28 NUMBER(3)
D30 DATE
SQL> desc tab2
Name Null? Type
COL5 NOT NULL VARCHAR2(15)
DESY1 VARCHAR2(60)
DESPA VARCHAR2(60)
CODS VARCHAR2(5)
CODNI VARCHAR2(5)
CODZO VARCHAR2(10)
CODC VARCHAR2(5)
CDFIS VARCHAR2(30)
CO VARCHAR2(30)
CODVATI VARCHAR2(30)
COT1 VARCHAR2(15)
COT2 VARCHAR2(15)
DCAT3 VARCHAR2(15)
CAT4 VARCHAR2(15)
COD VARCHAR2(15)
COU VARCHAR2(5)
FLG NOT NULL NUMBER(1)
COT VARCHAR2(20)
FLGCUSTD NOT NULL NUMBER(1)
CODMOE VARCHAR2(5)
FLG NOT NULL NUMBER(1)
FLGC NOT NULL NUMBER(1)
CODMOP VARCHAR2(5)
CODC VARCHAR2(15)
COELIV VARCHAR2(15)
CONC VARCHAR2(15)
COGMT VARCHAR2(10)
COR VARCHAR2(5)
COOUP VARCHAR2(15)
VALDIT NUMBER(14,2)
DTREDIT DATE
DTRE DATE
DTD DATE
DST DATE
DK DATE
COCK VARCHAR2(5)
CMOD VARCHAR2(5)
FNN NOT NULL NUMBER(1)
PGDCL VARCHAR2(60)
PDB VARCHAR2(60)
CXTEL VARCHAR2(15)
ILCK VARCHAR2(15)
DTTART DATE
PVERY NUMBER(9)
FLTUAL NOT NULL NUMBER(1)
DVER DATE
RIFE_INTERNO VARCHAR2(15)
DATADATE
ESENZIONE DATE
NMSENZIONE VARCHAR2(15)
VSED NUMBER(14,2)
EORD NOT NULL NUMBER(1)
EM VARCHAR2(30)
COTER VARCHAR2(15)
COUST VARCHAR2(15)
CORINT VARCHAR2(15)
TURFACE NUMBER(6)
ODSURFACE NUMBER(6)
ALINDEXPOT NUMBER(6)
SSE NUMBER(6)
NUSEATTR NUMBER(6)
NUETTI NUMBER(6)
CORTY VARCHAR2(15)
DESEC VARCHAR2(60)
QTEARI NUMBER(6)
TOFACE NUMBER(6)
COD VARCHAR2(30)
FLGCI NUMBER(1)
FLGC NUMBER(1)
COL3 NUMBER(1)
FLGCOL33 NUMBER(1)
Query plan of the original select:
1     SQL_ID 51kgr2x36h3y4, child number 0
2     -------------------------------------
3     select g.col1, g.col2 from tab1 g, tab2 part
4     where part.col3 <> 0 and g.col4 = 'PRO3' and g.col2 =
5     part.col5 and g.col7 = -1
6
7     Plan hash value: 2145701647
8
9     ---------------------------------------------------------------------------------------
10     | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
11     ---------------------------------------------------------------------------------------
12     | 0 | SELECT STATEMENT | | | | 938 (100)| |
13     |* 1 | HASH JOIN | | 22485 | 856K| 938 (17)| 00:00:05 |
14     |* 2 | INDEX FAST FULL SCAN| SYS_C00254422 | 22453 | 504K| 14 (8)| 00:00:01 |
15     |* 3 | TABLE ACCESS FULL | TAB2 | 67458 | 1054K| 920 (16)| 00:00:05 |
16     ---------------------------------------------------------------------------------------
17
18     Predicate Information (identified by operation id):
19     ---------------------------------------------------
20
21     1 - access("G"."COL2"="PART"."COL5")
22     2 - filter(("G"."COL7"=(-1) AND "G"."COL4"='PRO3'))
23     3 - filter("PART"."COL3"<>0)
24
Sql plan of the second quesry:
1     SQL_ID g1hc2xj88sc7x, child number 0
2     -------------------------------------
3     select g.col1, g.col2 from tab1 g, tab2 part where
4     part.col3 <> 0 and g.col4 = 'PRO3' and g.col2 = part.col5
5     and -g.col7 = 1
6
7     Plan hash value: 601419963
8
9     ----------------------------------------------------------------------------------------------
10     | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
11     ----------------------------------------------------------------------------------------------
12     | 0 | SELECT STATEMENT | | | | 512 (100)| |
13     | 1 | NESTED LOOPS | | 249 | 9711 | 512 (1)| 00:00:03 |
14     |* 2 | INDEX FAST FULL SCAN | SYS_C00254422 | 248 | 5704 | 15 (14)| 00:00:01 |
15     |* 3 | TABLE ACCESS BY INDEX ROWID| TAB2 | 1 | 16 | 2 (0)| 00:00:01 |
16     |* 4 | INDEX UNIQUE SCAN | SYS_C00254336 | 1 | | 1 (0)| 00:00:01 |
17     ----------------------------------------------------------------------------------------------
18
19     Predicate Information (identified by operation id):
20     ---------------------------------------------------
21
22     2 - filter(((-"G"."COL7")=1 AND "G"."COL4"='PRO3'))
23     3 - filter("PART"."COL3"<>0)
24     4 - access("G"."COL2"="PART"."COL5")
25
Index used:
Primary key on tab2 SYS_C00254336:
alter table TAB2
add primary key (COL5)
using index
tablespace name_tablespace;
Primary key on tab1 SYS_C00254422;
alter table TAB1
add primary key (COL1, COL4, COL2, COL7, DTCOL8 )
using index
tablespace name_tablespace;
Message was edited by:
user613483
Message was edited by:
user613483

How to setup a query plan in effective at any time for SP or SQL query?

I have a SP which include a group by SQL statement. It retrieve data from a couple of tables which are over 1G size,
When I run this SP at first time, it take more than 5 minutes to get the result. then I run it again and again, Finally, it become very quick, I can get the result within second.
Not sure why. I guess it is because of query plan.
How to make it running at first time to get result within second? How to force a better best query plan in effective at first time to run the query?
If the engine has better plan in memory, could it be lost at some point? because I have the complain from end user said some times it is fast, sometime it is very slow.
How to resolve this problem?

thanks, kevin. Here is the pesudo query( I modify table name as business rule from my company). you are right, mytab3 is a lookup table.
Select d.stock,i.description,c.categoryname,
Round(IsNull(Sum(d.qty),0),2) AS qty,
From mytab1 d,mytab2 s,invent i,mytab3 c
Where
d.stock != 'param1'
And d.id1 = s.id1    --id1: univarchar(11)
And i.code = c.code   --code:univarchar(2)
And d.stock = i.stock --stock: univarchar(12)
And i.code2 = d.code2 --code2: univarchar(2)
And d.code2 = 'param2'
And s.id2 = 'param3'   --id2: univarchar(6)
Group By c.categoryname,d.stock,i.description
Order By d.stock
here is the query plan when run this query:
The command completed with no results returned
QUERY PLAN FOR STATEMENT 1 (at line 1).
Executed in parallel by coordinating process and 4 worker processes.
    STEP 1
        The type of query is SELECT (into Worktable1).
        GROUP BY
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Executed in parallel by coordinating process and 4 worker processes.
        FROM TABLE
            mytab2
            s
        Nested iteration.
        Index : ind_mytab2 _id2
        Forward scan.
        Positioning by key.
        Keys are:
            id2 ASC
        Executed in parallel with a 4-way hash scan.
        Using I/O Size 16 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        FROM TABLE
            mytab1
            d
        Nested iteration.
        Index : ind_det_inv
        Forward scan.
        Positioning by key.
        Keys are:
            id1 ASC
        Using I/O Size 16 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        FROM TABLE
            invent
            i
        Nested iteration.
        Using Clustered Index.
        Index : invent_pk
        Forward scan.
        Positioning by key.
        Keys are:
            stock ASC
            code2 ASC
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        FROM TABLE
            mytab3
            c
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable1.
        Parallel work table merge.
    STEP 2
        The type of query is INSERT.
        The update mode is direct.
        Executed by coordinating process.
        Worktable2 created, in allpages locking mode, for ORDER BY.
        FROM TABLE
            Worktable1.
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 8 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable2.
    STEP 3
        The type of query is SELECT.
        Executed by coordinating process.
        This step involves sorting.
        FROM TABLE
            Worktable2.
        Using GETSORTED
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 8 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
Total estimated I/O cost for statement 1 (at line 1): 1409882.
The sort for Worktable2 is done in Serial

Can users see the query plan of a SQL query in Oracle?

Hi,
I wonder for a given sql query, after the system optimization, can I see the query plan in oracle? If yes, how to do that? thank you.
Xing

You can use explain plan in SQLPlus
SQL> explain plan for select * from user_tables;
Explained.
Elapsed: 00:00:01.63
SQL> select * from table(dbms_xplan.display());
PLAN_TABLE_OUTPUT
Plan hash value: 806004009
| Id | Operation                       | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |          | 2014 | 1123K|   507   (6)| 00:00:07 |
|* 1 | HASH JOIN RIGHT OUTER          |          | 2014 | 1123K|   507   (6)| 00:00:07 |
|   2 |   TABLE ACCESS FULL             | SEG$     | 4809 |   206K|    34   (3)| 00:00:01 |
|* 3 |   HASH JOIN RIGHT OUTER         |          | 1697 |   873K|   472   (6)| 00:00:06 |
|   4 |    TABLE ACCESS FULL            | USER$    |    74 | 1036 |     3   (0)| 00:00:01 |
|* 5 |    HASH JOIN OUTER              |          | 1697 |   850K|   468   (6)| 00:00:06 |
|   6 |     NESTED LOOPS OUTER          |          | 1697 |   836K|   315   (6)| 00:00:04 |
|* 7 |      HASH JOIN                  |          | 1697 |   787K|   226   (8)| 00:00:03 |
|   8 |       TABLE ACCESS FULL         | TS$      |    13 |   221 |     5   (0)| 00:00:01 |
|   9 |       NESTED LOOPS              |          | 1697 |   759K|   221   (8)| 00:00:03 |
| 10 |        MERGE JOIN CARTESIAN     |          | 1697 |   599K|   162 (10)| 00:00:02 |
|* 11 |         HASH JOIN               |          |     1 |   326 |     1 (100)| 00:00:01 |
|* 12 |          FIXED TABLE FULL       | X$KSPPI |     1 |    55 |     0   (0)| 00:00:01 |
| 13 |          FIXED TABLE FULL       | X$KSPPCV |   100 | 27100 |     0   (0)| 00:00:01 |
| 14 |         BUFFER SORT             |          | 1697 | 61092 |   162 (10)| 00:00:02 |
|* 15 |          TABLE ACCESS FULL      | OBJ$     | 1697 | 61092 |   161 (10)| 00:00:02 |
|* 16 |        TABLE ACCESS CLUSTER     | TAB$     |     1 |    96 |     1   (0)| 00:00:01 |
|* 17 |         INDEX UNIQUE SCAN       | I_OBJ#   |     1 |       |     0   (0)| 00:00:01 |
| 18 |      TABLE ACCESS BY INDEX ROWID| OBJ$     |     1 |    30 |     1   (0)| 00:00:01 |
|* 19 |       INDEX UNIQUE SCAN         | I_OBJ1   |     1 |       |     0   (0)| 00:00:01 |
| 20 |     TABLE ACCESS FULL           | OBJ$     | 52728 |   411K|   151   (4)| 00:00:02 |
Predicate Information (identified by operation id):
   1 - access("T"."FILE#"="S"."FILE#"(+) AND "T"."BLOCK#"="S"."BLOCK#"(+) AND
              "T"."TS#"="S"."TS#"(+))
   3 - access("CX"."OWNER#"="CU"."USER#"(+))
   5 - access("T"."DATAOBJ#"="CX"."OBJ#"(+))
   7 - access("T"."TS#"="TS"."TS#")
11 - access("KSPPI"."INDX"="KSPPCV"."INDX")
12 - filter("KSPPI"."KSPPINM"='_dml_monitoring_enabled')
15 - filter("O"."OWNER#"=USERENV('SCHEMAID') AND BITAND("O"."FLAGS",128)=0)
16 - filter(BITAND("T"."PROPERTY",1)=0)
17 - access("O"."OBJ#"="T"."OBJ#")
19 - access("T"."BOBJ#"="CO"."OBJ#"(+))
42 rows selected.
Elapsed: 00:00:03.61
SQL> If your plan table does not exist, execute the script $ORACLE_HOME/RDBMS/ADMIN/utlxplan.sql to create the table.

Query Plan 'group-by' clause

In evaluating several query plans, I've discovered several sqlstop messages that read:
<groupBy preclustered="true" sqlstop="Cannot generate SQL for the 'group-by' clause because it is not equivalent to the relational GROUP BY clause" stable="true">
I've examined the XQuery code and find no group clause and I can't find a reference to this message in the documentation or by googling the text. I assume that the grouping is being done implicitly by ODSI since it is not in the XQuery source. I have tried restructuring the code to no avail.
My question is -- is this causing me a performance problem since the sql is not generated, and if so, what steps must I take in the xquery structure to avoid this issue.
Many thanks to anyone who can provide some insight into this.
Regards,
PB

is this causing me a performance problem since the sql is not generatedMy question is - why are you asking this question? :) Do you have a performance problem? The "Best Practices" posted as an announcement in this forum might help. Otherwise engage customer support.
To answer your question - your xquery likely generates nested/hierarchical xml - and looks something like below - which can be implemented with a sql left-outer-join ordered by CUSTOMER_ID of the customer-table, and taking the rows returned and ... grouping by CUSTOMER_ID to eliminate the duplicate customer information. So there's your group-by. But you cannot write sql that has a left-outer join, and then a group-by on the left-hand side. So the group by is done in the engine. Since the results are already sorted, the group-by in the engine simply skips over the duplicates (i.e. it's basically free).
for $c in CUSTOMER()
where $c/LAST_NAME = $lastname
return
<CUSTOMER>
... $c/CUSTOMER_ID ... (: in a left-outer-join, the CUSTOMER_ID is duplicated for every ORDER :)
{ for $o in ORDER()
where $o/CUSTOMER_ID eq $c/CUSTOMER_ID
return
</CUSTOMER>

Merge cartesian join in query plan

Hi All
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
W are using many GTT's in our code, the query plan have Merge Cartesain join showing cardinality as '1' which is incorrect, as GTT tables have many rows. Due to this query is taking ages to execute.
I am trying to sue dynamic sampling, but it doesn't seem to work.
please help on this.

user8650395 wrote:
Hi All
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
W are using many GTT's in our code, the query plan have Merge Cartesain join showing cardinality as '1' which is incorrect, as GTT tables have many rows. Due to this query is taking ages to execute.
I am trying to sue dynamic sampling, but it doesn't seem to work.
please help on this.Interesting.
There was a a thread a day or two ago about when dynamic sampling does not work. You can search OTN for it if you like. Also check the docs to make sure that dynamic sampling works with GTTS
One problem with GTTS is getting accurate statistics. Have you considered using DBMS_STATISTICS to set the statistics on the table to adjust the cardinality?
Your cardinality of 1 sounds incorrect. In theory a cartesian join against one row should be painelss; unfortunately your cardinality figure seems to be off! Sometimes in cases like yours the cost-based optimizer will choose a Cartesian join even when the table joins are properly specified.

Sql Query Plan with ROWNUM

Oracle 10g:
I have a table with index, when I run that query on that index it's fine. I get into problem if I add ROWNUM in that query, query slows down from 1 sec to 30 sec. I don't know why. for eg:
select * from (select * from A where b = 1) where ROWNUM < 1000 becomes very slow:
Query Plan for select * from A where b = 1 (Query is just an example):
Rows     Plan
208912     SELECT STATEMENT
208912     SORT ORDER BY
208912     HASH JOIN RIGHT OUTER
408     INDEX FULL SCAN PK_BAD_ACK_TASK
208912     HASH JOIN RIGHT OUTER
16     INDEX FULL SCAN PK_INFORMATIONAL_TASK
208912     HASH JOIN RIGHT OUTER
1     INDEX FULL SCAN PK_SYSTEM_ERROR_TASK
208912     HASH JOIN RIGHT OUTER
1     INDEX FULL SCAN PK_REJECTED_TRANSMISSION
208912     HASH JOIN RIGHT OUTER
1     INDEX FULL SCAN PK_ONHOLD_TASK
208912     HASH JOIN RIGHT OUTER
329465     INDEX FAST FULL SCAN PK_FAILED_MESSAGE
208912     TABLE ACCESS FULL TASK
Query when I add ROWNUM (slow query as mentioned above):
Rows     Plan
999     SELECT STATEMENT
<NULL>     COUNT STOPKEY
208912     VIEW
208912     SORT ORDER BY STOPKEY
208912     HASH JOIN RIGHT OUTER
408     INDEX FULL SCAN PK_BAD_ACK_TASK
208912     NESTED LOOPS OUTER
208912     NESTED LOOPS OUTER
208912     NESTED LOOPS OUTER
208912     HASH JOIN RIGHT OUTER
329465     INDEX FAST FULL SCAN PK_FAILED_MESSAGE
208912     HASH JOIN RIGHT OUTER
16     INDEX FULL SCAN PK_INFORMATIONAL_TASK
208912     TABLE ACCESS FULL TASK
1     INDEX FAST FULL SCAN PK_ONHOLD_TASK
1     INDEX FAST FULL SCAN PK_REJECTED_TRANSMISSION
1     INDEX FAST FULL SCAN PK_SYSTEM_ERROR_TASK

user628400 wrote:
Oracle 10g:
I have a table with index, when I run that query on that index it's fine. I get into problem if I add ROWNUM in that query, query slows down from 1 sec to 30 sec. I don't know why. for eg:Some notes:
* When using ROWNUM the cost based optimizer switches to a FIRST_ROWS_N mode, this might explain the significant difference in the execution plan
* Try to get a more meaningful output using DBMS_XPLAN.DISPLAY
* Since you're already on 10g, try to compare the actual cardinalities to the estimates using DBMS_XPLAN.DISPLAY_CURSOR with the "ALLSTATS LAST" option and the GATHER_PLAN_STATISTICS hint.
See e.g. here for more information how to do it: http://jonathanlewis.wordpress.com/2006/11/09/dbms_xplan-in-10g/
This way you should be able to tell where the optimizer assumptions go wrong so that it thinks that the second one is better than the first one
A simple remedy you might want to try that should get you back to plan 1 is the following:
select * from (
select ROWNUM as rn, a.* from (select * from A where b = 1 ORDER BY<your_order_criteria>) a
where rn < 1000;Regards,
Randolf
Oracle related stuff blog:
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/
Edited by: Randolf Geist on Jan 11, 2009 9:33 PM
Added the obvious sort ORDER BY

Several calculated members in MDX query error

Hi all,
When I try to run this query on TX MDXTEST:
WITH
MEMBER [Measures].[284B70E6-5D9B-48A9-A8,39,F6,8C,24,8F,3D,84]
     AS ' [Measures].[4GPT8EYWQP8HAE0GFNSERQ9ZC]-[Measures].[4GPT8D1S01T3MR5EZ57C98LJC] '
MEMBER [Measures].[97630961-6154-4C5F-8C,72,C,DF,23,48,B1,19] AS
' [Measures].[4GPT8D1S01T3MR5EZ57C98LJC]-[Measures].[4GPT8EYWQP8HAE0GFNSERQ9ZC] '
SELECT
{ [Measures].[284B70E6-5D9B-48A9-A8,39,F6,8C,24,8F,3D,84],
[Measures].[97630961-6154-4C5F-8C,72,C,DF,23,48,B1,19] } ON COLUMNS
, NON EMPTY
     CROSSJOIN(
          CROSSJOIN( { [0CALMONTH].[200912] } , { [0STOR_LOC__ZCHINEYP].[X] } ), [0PLANT].[LEVEL01].MEMBERS )
        DIMENSION PROPERTIES [0CALMONTH].[20CALMONTH], [0STOR_LOC__ZCHINEYP].[20STOR_LOC__ZCHINEYP] ON ROWS
FROM [ZIC_MP01/ZIC_Q01]
I get the following error:
System error in program CL_RSD_MULTIPROV and form GET_IOBJNM_PROVID-03
I run the report CL_RSDRC_MULTIPROV of the note 1090490 explains (Error in class CL_RSD_MULTIPROV) and nothing happened.
When I delete any of the calculated members of the query, the query works
WITH
MEMBER [Measures].[284B70E6-5D9B-48A9-A8,39,F6,8C,24,8F,3D,84]
     AS ' [Measures].[4GPT8EYWQP8HAE0GFNSERQ9ZC]-[Measures].[4GPT8D1S01T3MR5EZ57C98LJC] '
SELECT
{ [Measures].[284B70E6-5D9B-48A9-A8,39,F6,8C,24,8F,3D,84] } ON COLUMNS
, NON EMPTY
     CROSSJOIN(
          CROSSJOIN( { [0CALMONTH].[200912] } , { [0STOR_LOC__ZCHINEYP].[X] } ), [0PLANT].[LEVEL01].MEMBERS )
        DIMENSION PROPERTIES [0CALMONTH].[20CALMONTH], [0STOR_LOC__ZCHINEYP].[20STOR_LOC__ZCHINEYP] ON ROWS
FROM [ZIC_MP01/ZIC_Q01]
Any ideas?
Regards

Hi,
just to make sure. this forum is about the SAP Integration Kit. are those MDX items coming from an OLAP Universe ?
thanks
Ingo

Actual Query Plan not running

I am using SQL Server 2012 (11.0.5058.0) and I am trying to learn Execution Plan Basics. One of the tasks is to run the "Actual Query Plan" by CTRL+M. When I try this nothing happens. I can do the "Display Estimated
Query Plan" and it works. Why can't I do the Actual Query Plan?

Hi,
To display Actual Query Plan, you have to execute the query. CTRL+M merely toggles to display Actual Query Plan or not.
See:
Display an Actual Execution Plan
Hope this helps,
~ J.

Reg: query plan -

Hi Experts,
I was playing/experimenting with query plans but got stuck up with the below. I guess, I'm overlooking something.
ranit@XE11GR2>> create table t
2 as
3 select * from all_objects;
Table created.
ranit@XE11GR2>> exec dbms_stats.gather_table_stats('rb1','t');
PL/SQL procedure successfully completed.
ranit@XE11GR2>> create index t_uidx
2 on
3 t(owner, object_type, object_name);
Index created.
ranit@XE11GR2>> select * from t
2 where owner = 'SYS';
Elapsed: 00:00:00.00
Execution Plan
Plan hash value: 1601196873
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      | 1642 |   144K|    67   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T    | 1642 |   144K|    67   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("OWNER"='SYS')
ranit@XE11GR2>> select count(*) from t
2 where owner = 'SYS';
Elapsed: 00:00:00.00
Execution Plan
Plan hash value: 1979783846
| Id | Operation         | Name   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |        |     1 |     7 |    11   (0)| 00:00:01 |
|   1 | SORT AGGREGATE   |        |     1 |     7 |            |          |
|* 2 |   INDEX RANGE SCAN| T_UIDX | 1642 | 11494 |    11   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("OWNER"='SYS')
Doubt: Why does the first query have a FTS while the second query (with COUNT(*)) does an Index scan?
ranit@XE11GR2>> select owner, object_name, namespace from t
2 where owner = 'SYS';
Elapsed: 00:00:00.05
Execution Plan
Plan hash value: 1601196873
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      | 1642 | 47618 |    67   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T    | 1642 | 47618 |    67   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("OWNER"='SYS')
Also, in the above I'm seeing that if I add a non-indexed column in SELECT clause (like column 'namespace') it goes for a FTS. How does column in SELECT clause affect the use of Indexes?
Any pointers if highly appreciated.
Thanks,
Ranit

The second query doesn't have to visit the table - all the required data is in the index- and Oracle thinks that a range scan will only have to go through a small number of leaf blocks to find all the SYS entries. The first query needs data which can only be found in the table, and Oracle thinks the 1642 rows it need to find will be spread across so many blocks that it's quicker to do the tablescan than jump to each one separately after doing an index range scan.
If you want to see how much work Oracle thinks it would take to use an indexed access path into the table, you could test by adding a hint to the query.
Regards
Jonathan Lewis
Now on twitter: @jloracle

What is meant by estimated costs and estimated rows in SQL explain (ST05)?

Hi
I was just wondering if someone could explain/clarify exactly what is meant by estimated costs and estimated rows in the 'explain' / execution path functionality of ST05.
For example, we could see a SQL statement was very inefficient accessing a table:
Estimated Costs = 6.006.615 , Estimated #Rows = 0
Does this literally mean that for 6 million costs / reads / effort, 0 results were returned??
Is this a ratio of efficiency?
We built an appropriate index and now we have:
Estimated Costs = 2 , Estimated #Rows = 1
A lot better! The job was taking 40+ hours and being cancelled; now it takes 5 minutes. So a 3 million times improvement sounds realistic...
However, we had another instance where the explain showed:
( Estim. Costs = 195.077 , Estim. #Rows = 538.660 )
and we built an index, and now the explain is:
( Estimated Costs = 41.867 , Estimated #Rows = 538.660 )
What exactly does this mean - as the costs has been reduced, but the rows is the same?
Thanks
Ross

Hi Ross,
>I was just wondering if someone could explain/clarify exactly what is meant by estimated costs and estimated rows in the >'explain' / execution path functionality of ST05
Take a look at note 766349, point 20.
>An EXPLAIN displays "Estimated Costs" and "Estimated Rows", which
>are simply the CBO's calculation results (refer to Note 7550631).
>Since these results are based upon a number of assumptions (column
>values are distributed equally, statistics), and depend upon the
>database parameter settings, the calculated costs and rows are
>useful only within a margin for error. High "Estimated Costs" and
>"Estimated Rows" are therefore neither a satisfactory nor a
>necessary indication of an expensive SQL statement. Also, the
>calculated costs have no actual effect upon the performance - the
>deciding costs are always the actual ones, in the form of BUFFER
>GETs, DISK READs, or processed rows.
So the costs and rows are values conjured up by the cost optimizer when calculating the access path that is most likely to be efficient. THEY ARE ESTIMATES!!!
>Does this literally mean that for 6 million costs / reads / effort, 0 results were returned??
As per the above, no. The costs and rows are estimated before the rows are fetched so there are no actual results yet.
>What exactly does this mean - as the costs has been reduced, but the rows is the same?
An efficient database access is exactly that; reads only the blocks that contain the rows it needs and nothing else. If the access is inefficient it will spend time accessing blocks that contain no data that is eventually contained in the result set.
This question would be better placed in the Oracle forum...
Regards,
Peter

Query Plan Question for Outer Join

I have the following join query:
select unique ep.ACT_UID,
ep.SE_REQ_TS,
sr.SERVICE_NM
from
eaisvcs.Service_requests sr,
eaisvcs.SERVICE_EPISODE ep
where
ep.ACT_UID = sr.ACT_UID;
I have an index on the act_uid in both tables, and the statistics are up-to-date. There are about 3.2 million rows in each table. 10% of the act_uid's that are in the ep table that do not have a match in the sr table. Other than that, most id's match up between the tables.
Here is the query plan:
ID PARENT_ID OPERATION OPTIONS
0 SELECT STATEMENT
1 0 SORT UNIQUE
2 1 MERGE JOIN
3 2 SORT JOIN
4 3 TABLE ACCESS FULL
5 2 SORT JOIN
6 5 TABLE ACCESS FULL
I cannot figure out why a table scan is being performed every time on both tables. The Act_UID is the PK in the ep table. There is a composite index (act_uid, sev_seq_no) in the sr table. the act_id is a varchar2 column in both tables. The sev_seq_no column is numeric.
Any ideas or insights about this would be greatly appreciated.
Thanks!

The plan can be good.
Oracle choose a full table scan for these reason too:
- sr.SERVICE_NM is not a part of the index and so a full table scan is less expensive. If you will add this field to your composite index Oracle will probably take this new index.
Bye, Aron

Calculating estimated rows in query plan

Similar Messages

Maybe you are looking for