Join Order

1. What is the importance of JOIN order in where clause? i.e. what is the difference b/w "emp.deptno = dept.deptno" AND "dept.deptno = emp.deptno" in WHERE clause?
2. What is the difference b/w "SELECT", "sElECt", "SElecT" from performance tuning point of view? Is it case sensitive or insensitive? Suppose Oracle has parsed one stmt with SELECT in upper case. If I issue same stmt but select in lower case, will it parse again or pick up from shared pool?

1. What is the importance of JOIN order in where
clause? i.e. what is the difference b/w "emp.deptno =
dept.deptno" AND "dept.deptno = emp.deptno" in WHERE
clause?Should make no difference whatsoever.
2. What is the difference b/w "SELECT", "sElECt",
"SElecT" from performance tuning point of view? Is it
case sensitive or insensitive? Suppose Oracle has
parsed one stmt with SELECT in upper case. If I issue
same stmt but select in lower case, will it parse
again or pick up from shared pool?Shared Pool is case sensitive, so any changes to the query will be seen as a different statement.
But like the others say, why not try it for yourself and find out.

Similar Messages

How to hint hash join order on indexes ?

Hi,
in my 9.2.0.8 DB I've got query like this:
SELECT COUNT (agreementno) cnt
FROM followup
WHERE agreementno = :v001 AND actioncode = :v002 AND resultcode = :v003;
Plan
SELECT STATEMENT CHOOSECost: 11 Bytes: 18 Cardinality: 1
     5 SORT AGGREGATE Bytes: 18 Cardinality: 1
          4 VIEW index$_join$_001 Cost: 11 Bytes: 18 Cardinality: 1
               3 HASH JOIN Bytes: 18 Cardinality: 1
                    1 INDEX RANGE SCAN NON-UNIQUE IDX_FOLLOWUP06 Cost: 13 Bytes: 18 Cardinality: 1
                    2 INDEX RANGE SCAN UNIQUE PK_FOLLOWUP Cost: 13 Bytes: 18 Cardinality: 1 I need to change join order of indexes, so the proble one would be PK_FOLLOWUP .
Of course the best plan is index range scan on pk but during to hight CF Oracle is combining 2 indexes .
Regards.
Greg

Hmm sorry for red-herring.
I guess you could also consider hand-coding the index join, something like:
SELECT /*+ ORDERED USE_HASH (b) */
       COUNT (a.empno)
FROM (SELECT e.empno
       FROM emp e
       WHERE e.empno > 7000) a,
      (SELECT e.empno
       FROM emp e
       WHERE e.ename LIKE 'S%') b
WHERE a.ROWID = b.ROWID;or...
WITH e AS
     (SELECT e.empno, e.ename
        FROM emp e)
SELECT /*+ ORDERED USE_HASH (b) */
       COUNT (a.empno)
FROM   e a, e b
WHERE b.ename LIKE 'S%'
AND    a.empno > 7000
AND    a.ROWID = b.ROWID;

Developing Python-SQLAlchemy Interface, OUTER JOIN/ORDER BY/LIMIT problems

Hi,
We are currently trying to implement a database interface for SQLAlchemy, an object relational mapper (ORM) library for python. (http://www.sqlalchemy.org)
There are some MaxDB-specific issues, we have to sort out for this, so perhaps you can give us some help on the following:
1) Outer joins buggy for MaxDB releases < 7.6.03.07:
When joining more than 2 tables, the database may return incorrect results. Simple modifications of the order in where clauses may give different results (e.g. FROM lhs LEFT OUTER JOIN rhs ON lhs.col=rhs.col vs rhs.col=lhs.col)
For 7.6.03.07, these issues seem to be fixed, however, I could not find any changelog or bugfix-report, which confirm that these bugs are completely fixed.
2) ORDER BY/LIMIT seem not to be supported in subqueries.
3) LIMIT is not supported for derived tables, e.g.:
SELECT * FROM (SELECT * FROM a) LIMIT 2
More detailled information about these issues can be found at:
http://www.sqlalchemy.org/trac/wiki/DatabaseNotes (In section MaxDB/SAP DB)
Can you please tell me if and when these bugs/features will be fixed in future MaxDB releases?
Best Regards,
Hermann Himmelbauer

Perre wrote:I'm used to being able to pick one or a couple of songs and then adding it a specified playlist. Is this impossible in sonata?
It's clearly not impossible, just different than you expect. Create your playlist as you want it to appear in the Current tab (meaning don't dump every single song from your library in there, just the ones you want) and then save the playlist.
Perre wrote:And if I try to play the m3u file created (the one with every song listed) through freevo I get a message that the directory is empty. What am I doing wrong??
Look at save_absolute_paths_in_playlists in your mpd.conf.

Seibel Query help : - Joining Order table with Asset or CX_ACTION table.

Hi Team
I need help joining the Order table with the Asset table
or the Order table with CX_ACTION table to
Can i get reference on this .
select x.x_msisdn,
x.x_product_name,
x.x_action,
x.x_status_outcome,
a.recovered_dt,
x.x_amount,
x.created,
x.x_number_retries,
o.ORDER_NUM "FMW Order No",
DECODE(FULFLMNT_STATUS_CD , 'Failed','Failed', o.STATUS_CD) "Order Status"
from
siebel.cx_action x,
siebel.s_order o,
siebel.s_asset a
where a.row_id = x.x_asset_id
and x.created > to_date('08/01/2013 08:00:00', 'dd/mm/yyyy hh24:mi:ss')
and x.created < to_date('09/04/2013 07:50:00', 'dd/mm/yyyy hh24:mi:ss')
Regards

I'm not familiar with Seibel or any of these tables but right off the bat I'd suggest you're missing a join predicate to your s_order table. This could give you far more rows than you're expecting.
Aside from that you haven't told us what problems you are having. An error? Wrong results? Performance?

Right order of joining tables

Hi everybody,
I have read the SQL Tuning section of Performance Tuning Oracle Book of Oracle 10g. v.2.
In 11.5.4. paragraph titled "Controlling the Access Path and Join Order with Hints" , in the second note there is a small paragraph about the right join of the tables....
In whichever query i try ,i've noticed that altering the joining order of the tables the sql statistics (consistent gets , sorts(memory/disk)) are the same regardless of the join order....
Can you please give me an example or a source in which the modification of the join order of the tables in a sql query produce different results ...in statistics????
Thanks , a lot
Simon

Duplicate post. Don't answer this thread please Right order of joining tables.
Cheers, APC

How to define the order of GROUPBYs, JOINs and FILTERS in an interface?

Hello,
I would like to define an interface which implements the following logic:
Give me a list of all customers with less then 2 orders in status = 'A'.
SELECT C.Name, o.cnt
FROM CUSTOMER C
LEFT OUTER JOIN (SELECT cust_id, count(*) cnt FROM ORDERS WHERE status = 'A' GROUP BY cust_id) O
ON C.cust_id = O.cust_id
WHERE O.cnt < 2 OR O.cust_id IS NULL
In this case, the right order of operations is essential:
First apply filter, then group, then join, then apply the second filter.
How can I define this in an ODI interface?
Thanks in advance for any hints...
Best regards,
Karol

Defining JOINs order :
1 - Go in topology manager and verify that your technologie support the ISO ordered join ( left inner join ...)
NB : by default Oracle data sources are configured with the old syntax ( ie : columns(+)=expr )
- Open technology Oracle: Check SQL ISO
- Go to the SQL tab
- select "FROM" in the filter place
- verify the join syntax
2 - Define the alias order in the source table
3 - Check the ordered join (ISO) and a num-order on the join operator
Defining GROUPBYs and FILTERS orders seems to be impossible
but you can create a mapping as a view and use this mapping as a source in an other one !

Does sql sql efficiency depend on order of join predicate?

hello experts,
I trying to under stand the explain plan , I read the link
http://savvinov.com/2012/06/11/sql-efficiency/
Example 3: The inefficiency is coming from the wrong join order, where the bigger row source is taken as the driving table.
please explain.
thanks
yahs

Hi Nikolay,
What matters is the order in which a join is executed, not the order in which you specify join conditionsHmmm. Not really in all cases.
As jonathan Lewis pointed it out in the following article
http://jonathanlewis.wordpress.com/2010/12/15/join-surprise/#more-5104
With multi-column joins, the order of the join predicates can make a big difference to the way Oracle operates a merge join
Best regards
Mohamed Houri
www.hourim.wordpress.com

Production order report on Daily

Hi gurus,
I tried to create a report for production orders. it contain four selection parameters. Here i am using four tables 1) crhd 2) caufv 3) aufk 4) afru 5) zbreak ( this is a ztable created by me ) . i need the fields like date,work centre, porder,startdate,enddate,order quantity,processed quantity,yield,scrap, (down time ,from time ,reason these all from ztable). i want to make one report on this.
   i did it in two ways. I used a join statement but it is taking more time to execute. i know this is a performance issue. please give me a good idea how to finish this report.
<< Please repect the 2,500 character limit on posts. Post only the relevant portion of your code. And please use code tags.>>
form get_data.
select
     a~arbpl
     b~plnbez
     c~aufnr
     d~rueck
     d~isdd
     d~iedd
     b~gamng
     d~lmnga
     d~xmnga
     d~rmnga
     e~from_time
     e~to_time
     e~total_time
     e~workcentre
     e~reason
     into table itab
*     (itab-arbpl, itab-plnbez, itab-aufnr,
*     itab-rueckb itab-isdd itab-iedd,
*     itab-gamng, itab-lmnga, itab-xmnga,
*     itab-rmnga ,itab-from_time, itab-to_time,
*     itab-total_time, itab-workcenter, itab-reason)
     from ( ( crhd as a
      inner join caufv as b
     on a~werks = b~werks
     inner join aufk as c
     on c~werks = b~werks
      inner join afru as d
     on d~werks = c~WERKS )
     inner join ZBREAK_DOWN_TIME as e
     on e~werks = d~werks )
     WHERE PLNBEZ IN S_MATNR.
     append itab.
endform.
Thank you.
Edited by: Rob Burbank on Jan 3, 2010 2:09 PM

Hi MadhuRao,
My observations in your current SELECT statement are as follows:
1. In your query you are selecting AUFNR from the table AUFK which is already there in the view CAUFV which you have already included. So this is un-necessary.
2. There is no index for WERKS in table CRHD (Work Center Header) table. You should read the work centers separately in a hash table and read to fill your main internal table.
3. You should join Order table (view CAUFV) and Order confirmations (AFRU) based on order number (AUFNR). Currently you are joining based on plant (WERKS) which is also another serious performance issue.
My suggestions are:
1. SELECT all the Work-Centers from CRHD into an internal table.
2. SELECT from CAUFV first for the given list of material numbers (which is the only WHERE clause field in your query). This must be your main internal table itab.
3. Consolidate all the unique Order Numbers (AUFNR) and if possible the counter (APLZL) into a separate internal table.
4. SELECT from the confirmation table (AFRU) for the list of above orders only.
5. Loop through your main internal table itab and update the fields from the Work-Center and Confirmation internal tables.
This would greatly improve the performance, however your code will be huger.
Cheers
Suresh

Query Degradation--Hash Join Degraded

Hi All,
I found one query degradation issue.I am on 10.2.0.3.0 (Sun OS) with optimizer_mode=ALL_ROWS.
This is a dataware house db.
All 3 tables involved are parition tables (with daily partitions).Partitions are created in advance and ELT jobs loads bulk data into daily partitions.
I have checked that CBO is not using local indexes-created on them which i believe,is appropriate because when i used INDEX HINT, elapsed time increses.
I checked giving index hint for all tables one by one but dint get any performance improvement.
Partitions are daily loaded and after loading,partition-level stats are gathered with dbms_stats.
We are collecting stats at partition level(granularity=>'PARTITION').Even after collecting global stats,there is no change in access pattern.Stats gather command is given below.
PROCEDURE gather_table_part_stats(i_owner_name,i_table_name,i_part_name,i_estimate:= DBMS_STATS.AUTO_SAMPLE_SIZE, i_invalidate IN VARCHAR2 := 'Y',i_debug:= 'N')
Only SOT_KEYMAP.IPK_SOT_KEYMAP is GLOBAL.Rest all indexes are LOCAL.
Earlier,we were having BIND PEEKING issue,which i fixed but introducing NO_INVALIDATE=>FALSE in stats gather job.
Here,Partition_name (20090219) is being passed through bind variables.
SELECT a.sotrelstg_sot_ud sotcrct_sot_ud,
b.sotkey_ud sotcrct_orig_sot_ud, a.ROWID stage_rowid
FROM (SELECT sotrelstg_sot_ud, sotrelstg_sys_ud,
sotrelstg_orig_sys_ord_id, sotrelstg_orig_sys_ord_vseq
FROM sot_rel_stage
WHERE sotrelstg_trd_date_ymd_part = '20090219'
AND sotrelstg_crct_proc_stat_cd = 'N'
AND sotrelstg_sot_ud NOT IN(
SELECT sotcrct_sot_ud
FROM sot_correct
WHERE sotcrct_trd_date_ymd_part ='20090219')) a,
(SELECT MAX(sotkey_ud) sotkey_ud, sotkey_sys_ud,
sotkey_sys_ord_id, sotkey_sys_ord_vseq,
sotkey_trd_date_ymd_part
FROM sot_keymap
WHERE sotkey_trd_date_ymd_part = '20090219'
AND sotkey_iud_cd = 'I'
--not to select logical deleted rows
GROUP BY sotkey_trd_date_ymd_part,
sotkey_sys_ud,
sotkey_sys_ord_id,
sotkey_sys_ord_vseq) b
WHERE a.sotrelstg_sys_ud = b.sotkey_sys_ud
AND a.sotrelstg_orig_sys_ord_id = b.sotkey_sys_ord_id
AND NVL(a.sotrelstg_orig_sys_ord_vseq, 1) = NVL(b.sotkey_sys_ord_vseq, 1);
During normal business hr, i found that query takes 5-7 min(which is also not acceptable), but during high load business hr,it is taking 30-50 min.
I found that most of the time it is spending on HASH JOIN (direct path write temp).We have sufficient RAM (64 GB total/41 GB available).
Below is the execution plan i got during normal business hr.
| Id | Operation                 | Name                | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads | Writes | OMem | 1Mem | Used-Mem | Used-Tmp|
|   1 | HASH GROUP BY            |                     |      1 |      1 |   7844K|00:05:28.78 |      16M|    217K| 35969 |       |       |          |         |
|* 2 |   HASH JOIN               |                     |      1 |      1 |   9977K|00:04:34.02 |      16M|    202K| 20779 |   580M|    10M| 563M (1)|     650K|
|   3 |    NESTED LOOPS ANTI      |                     |      1 |      6 |   7855K|00:01:26.41 |      16M|   1149 |      0 |       |       |          |         |
|   4 |     PARTITION RANGE SINGLE|                     |      1 |    258K|   8183K|00:00:16.37 |   25576 |   1149 |      0 |       |       |          |         |
|* 5 |      TABLE ACCESS FULL    | SOT_REL_STAGE       |      1 |    258K|   8183K|00:00:16.37 |   25576 |   1149 |      0 |       |       |          |         |
|   6 |     PARTITION RANGE SINGLE|                     |   8183K|    326K|    327K|00:01:10.53 |      16M|      0 |      0 |       |       |          |         |
|* 7 |      INDEX RANGE SCAN     | IDXL_SOTCRCT_SOT_UD |   8183K|    326K|    327K|00:00:53.37 |      16M|      0 |      0 |       |       |          |         |
|   8 |    PARTITION RANGE SINGLE |                     |      1 |    846K|     14M|00:02:06.36 |     289K|    180K|      0 |       |       |          |         |
|* 9 |     TABLE ACCESS FULL     | SOT_KEYMAP          |      1 |    846K|     14M|00:01:52.32 |     289K|    180K|      0 |       |       |          |         |
I will attached the same for high load business hr once query gives results.It is still executing for last 50 mins.
INDEX STATS (INDEXES ARE LOCAL INDEXES)
TABLE_NAME                          INDEX_NAME                          COLUMN_NAME        COLUMN_POSITION   NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
SOT_REL_STAGE                       IDXL_SOTRELSTG_SOT_UD               SOTRELSTG_SOT_UD                 1   25461560      25461560            184180
SOT_REL_STAGE                                                           SOTRELSTG_TRD_DATE               2   25461560      25461560            184180
                                                                        _YMD_PART
TABLE_NAME                          INDEX_NAME                          COLUMN_NAME        COLUMN_POSITION   NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
SOT_KEYMAP                          IDXL_SOTKEY_ENTORDSYS_UD            SOTKEY_ENTRY_ORD_S               1 1012306940             3          38308680
                                                                        YS_UD
SOT_KEYMAP                          IDXL_SOTKEY_HASH                    SOTKEY_HASH                      1 1049582320    1049582320        1049579520
SOT_KEYMAP                                                              SOTKEY_TRD_DATE_YM               2 1049582320    1049582320        1049579520
                                                                        D_PART
SOT_KEYMAP                          IDXL_SOTKEY_SOM_ORD                 SOTKEY_SOM_UD                    1 1023998560     268949136         559414840
SOT_KEYMAP                                                              SOTKEY_SYS_ORD_ID                2 1023998560     268949136         559414840
SOT_KEYMAP                          IPK_SOT_KEYMAP                      SOTKEY_UD                        1 1030369480    1015378900          24226580
TABLE_NAME                          INDEX_NAME                          COLUMN_NAME        COLUMN_POSITION   NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
SOT_CORRECT                         IDXL_SOTCRCT_SOT_UD                 SOTCRCT_SOT_UD                   1 412484756     412484756         411710982
SOT_CORRECT                                                             SOTCRCT_TRD_DATE_Y               2 412484756     412484756         411710982
                                                                        MD_PART
INDEX partiton stas (from dba_ind_partitions)
INDEX_NAME                     PARTITION_NAME       STATUS       BLEVEL LEAF_BLOCKS DISTINCT_KEYS CLUSTERING_FACTOR   NUM_ROWS SAMPLE_SIZE LAST_ANALYZ GLO
IDXL_SOTCRCT_SOT_UD            P20090219            USABLE            1         372        327879            216663     327879      327879 20-Feb-2009 YES
IDXL_SOTKEY_ENTORDSYS_UD       P20090219            USABLE            2        2910             3             36618     856229      856229 19-Feb-2009 YES
IDXL_SOTKEY_HASH               P20090219            USABLE            2        7783        853956            853914     853956      119705 19-Feb-2009 YES
IDXL_SOTKEY_SOM_ORD            P20090219            USABLE            2        6411        531492            157147     799758      132610 19-Feb-2009 YES
IDXL_SOTRELSTG_SOT_UD          P20090219            USABLE            2       13897       9682052             45867    9682052      794958 20-Feb-2009 YESThanks in advance.
Bhavik Desai

Hi Randolf,
Thanks for the time you spent on this issue.I appreciate it.
Please see my comments below:
1. You've mentioned several times that you're passing the partition name as bind variable, but you're obviously testing the statement with literals rather than bind
variables. So your tests obviously don't reflect what is going to happen in case of the actual execution. The cardinality estimates are potentially quite different when
using bind variables for the partition key.
Yes.I intentionaly used literals in my tests.I found couple of times that plan used by the application and plan generated by AUTOTRACE+EXPLAIN PLAN command...is same and
caused hrly elapsed time.
As i pointed out earlier,last month we solved couple of bind peeking issue by intproducing NO_VALIDATE=>FALSE in stats gather procedure,which we execute just after data
load into such daily partitions and before start of jobs which executes this query.
Execution plans From AWR (with parallelism on at table level DEGREE>1)-->This plan is one which CBO has used when degradation occured.This plan is used most of the times.
ELAPSED_TIME_DELTA BUFFER_GETS_DELTA DISK_READS_DELTA CURSOR(SELECT*FROMTA
        1918506000          46154275              918 CURSOR STATEMENT : 4
CURSOR STATEMENT : 4
PLAN_TABLE_OUTPUT
SQL_ID 39708a3azmks7
SELECT A.SOTRELSTG_SOT_UD SOTCRCT_SOT_UD, B.SOTKEY_UD SOTCRCT_ORIG_SOT_UD, A.ROWID STAGE_ROWID FROM (SELECT SOTRELSTG_SOT_UD,
SOTRELSTG_SYS_UD, SOTRELSTG_ORIG_SYS_ORD_ID, SOTRELSTG_ORIG_SYS_ORD_VSEQ FROM SOT_REL_STAGE WHERE SOTRELSTG_TRD_DATE_YMD_PART = :B1 AND
SOTRELSTG_CRCT_PROC_STAT_CD = 'N' AND SOTRELSTG_SOT_UD NOT IN( SELECT SOTCRCT_SOT_UD FROM SOT_CORRECT WHERE SOTCRCT_TRD_DATE_YMD_PART =
:B1 )) A, (SELECT MAX(SOTKEY_UD) SOTKEY_UD, SOTKEY_SYS_UD, SOTKEY_SYS_ORD_ID, SOTKEY_SYS_ORD_VSEQ, SOTKEY_TRD_DATE_YMD_PART FROM
SOT_KEYMAP WHERE SOTKEY_TRD_DATE_YMD_PART = :B1 AND SOTKEY_IUD_CD = 'I' GROUP BY SOTKEY_TRD_DATE_YMD_PART, SOTKEY_SYS_UD,
SOTKEY_SYS_ORD_ID, SOTKEY_SYS_ORD_VSEQ) B WHERE A.SOTRELSTG_SYS_UD = B.SOTKEY_SYS_UD AND A.SOTRELSTG_ORIG_SYS_ORD_ID =
B.SOTKEY_SYS_ORD_ID AND NVL(A.SOTRELSTG_ORIG_SYS_ORD_VSEQ, 1) = NVL(B.SOTKEY_SYS_ORD_VSEQ, 1)
Plan hash value: 1213870831
| Id | Operation                     | Name                | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT              |                     |       |       | 19655 (100)|          |       |       |        |      |            |
|   1 | PX COORDINATOR               |                     |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (RANDOM)         | :TQ10003            |     1 |   116 | 19655   (1)| 00:05:54 |       |       | Q1,03 | P->S | QC (RAND) |
|   3 |    HASH GROUP BY              |                     |     1 |   116 | 19655   (1)| 00:05:54 |       |       | Q1,03 | PCWP |            |
|   4 |     PX RECEIVE                |                     |     1 |   116 | 19655   (1)| 00:05:54 |       |       | Q1,03 | PCWP |            |
|   5 |      PX SEND HASH             | :TQ10002            |     1 |   116 | 19655   (1)| 00:05:54 |       |       | Q1,02 | P->P | HASH       |
|   6 |       HASH GROUP BY           |                     |     1 |   116 | 19655   (1)| 00:05:54 |       |       | Q1,02 | PCWP |            |
|   7 |        NESTED LOOPS ANTI      |                     |     1 |   116 | 19654   (1)| 00:05:54 |       |       | Q1,02 | PCWP |            |
|   8 |         HASH JOIN             |                     |     1 |   102 | 19654   (1)| 00:05:54 |       |       | Q1,02 | PCWP |            |
|   9 |          PX JOIN FILTER CREATE| :BF0000             |    13M|   664M| 2427   (3)| 00:00:44 |       |       | Q1,02 | PCWP |            |
| 10 |           PX RECEIVE          |                     |    13M|   664M| 2427   (3)| 00:00:44 |       |       | Q1,02 | PCWP |            |
| 11 |            PX SEND HASH       | :TQ10000            |    13M|   664M| 2427   (3)| 00:00:44 |       |       | Q1,00 | P->P | HASH       |
| 12 |             PX BLOCK ITERATOR |                     |    13M|   664M| 2427   (3)| 00:00:44 |   KEY |   KEY | Q1,00 | PCWC |            |
| 13 |              TABLE ACCESS FULL| SOT_REL_STAGE       |    13M|   664M| 2427   (3)| 00:00:44 |   KEY |   KEY | Q1,00 | PCWP |            |
| 14 |          PX RECEIVE           |                     |    27M| 1270M| 17209   (1)| 00:05:10 |       |       | Q1,02 | PCWP |            |
| 15 |           PX SEND HASH        | :TQ10001            |    27M| 1270M| 17209   (1)| 00:05:10 |       |       | Q1,01 | P->P | HASH       |
| 16 |            PX JOIN FILTER USE | :BF0000             |    27M| 1270M| 17209   (1)| 00:05:10 |       |       | Q1,01 | PCWP |            |
| 17 |             PX BLOCK ITERATOR |                     |    27M| 1270M| 17209   (1)| 00:05:10 |   KEY |   KEY | Q1,01 | PCWC |            |
| 18 |              TABLE ACCESS FULL| SOT_KEYMAP          |    27M| 1270M| 17209   (1)| 00:05:10 |   KEY |   KEY | Q1,01 | PCWP |            |
| 19 |         PARTITION RANGE SINGLE|                     | 16185 |   221K|     0   (0)|          |   KEY |   KEY | Q1,02 | PCWP |            |
| 20 |          INDEX RANGE SCAN     | IDXL_SOTCRCT_SOT_UD | 16185 |   221K|     0   (0)|          |   KEY |   KEY | Q1,02 | PCWP |            |
Other Execution plan from AWR
ELAPSED_TIME_DELTA BUFFER_GETS_DELTA DISK_READS_DELTA CURSOR(SELECT*FROMTA
        1053251381                 0             2925 CURSOR STATEMENT : 4
CURSOR STATEMENT : 4
PLAN_TABLE_OUTPUT
SQL_ID 39708a3azmks7
SELECT A.SOTRELSTG_SOT_UD SOTCRCT_SOT_UD, B.SOTKEY_UD SOTCRCT_ORIG_SOT_UD, A.ROWID STAGE_ROWID FROM (SELECT SOTRELSTG_SOT_UD,
SOTRELSTG_SYS_UD, SOTRELSTG_ORIG_SYS_ORD_ID, SOTRELSTG_ORIG_SYS_ORD_VSEQ FROM SOT_REL_STAGE WHERE SOTRELSTG_TRD_DATE_YMD_PART = :B1 AND
SOTRELSTG_CRCT_PROC_STAT_CD = 'N' AND SOTRELSTG_SOT_UD NOT IN( SELECT SOTCRCT_SOT_UD FROM SOT_CORRECT WHERE SOTCRCT_TRD_DATE_YMD_PART =
:B1 )) A, (SELECT MAX(SOTKEY_UD) SOTKEY_UD, SOTKEY_SYS_UD, SOTKEY_SYS_ORD_ID, SOTKEY_SYS_ORD_VSEQ, SOTKEY_TRD_DATE_YMD_PART FROM
SOT_KEYMAP WHERE SOTKEY_TRD_DATE_YMD_PART = :B1 AND SOTKEY_IUD_CD = 'I' GROUP BY SOTKEY_TRD_DATE_YMD_PART, SOTKEY_SYS_UD,
SOTKEY_SYS_ORD_ID, SOTKEY_SYS_ORD_VSEQ) B WHERE A.SOTRELSTG_SYS_UD = B.SOTKEY_SYS_UD AND A.SOTRELSTG_ORIG_SYS_ORD_ID =
B.SOTKEY_SYS_ORD_ID AND NVL(A.SOTRELSTG_ORIG_SYS_ORD_VSEQ, 1) = NVL(B.SOTKEY_SYS_ORD_VSEQ, 1)
Plan hash value: 3434900850
| Id | Operation                     | Name                | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT              |                     |       |       | 1830 (100)|          |       |       |        |      |            |
|   1 | PX COORDINATOR               |                     |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (RANDOM)         | :TQ10003            |     1 |   131 | 1830   (2)| 00:00:33 |       |       | Q1,03 | P->S | QC (RAND) |
|   3 |    HASH GROUP BY              |                     |     1 |   131 | 1830   (2)| 00:00:33 |       |       | Q1,03 | PCWP |            |
|   4 |     PX RECEIVE                |                     |     1 |   131 | 1830   (2)| 00:00:33 |       |       | Q1,03 | PCWP |            |
|   5 |      PX SEND HASH             | :TQ10002            |     1 |   131 | 1830   (2)| 00:00:33 |       |       | Q1,02 | P->P | HASH       |
|   6 |       HASH GROUP BY           |                     |     1 |   131 | 1830   (2)| 00:00:33 |       |       | Q1,02 | PCWP |            |
|   7 |        NESTED LOOPS ANTI      |                     |     1 |   131 | 1829   (2)| 00:00:33 |       |       | Q1,02 | PCWP |            |
|   8 |         HASH JOIN             |                     |     1 |   117 | 1829   (2)| 00:00:33 |       |       | Q1,02 | PCWP |            |
|   9 |          PX JOIN FILTER CREATE| :BF0000             | 1010K|    50M|   694   (1)| 00:00:13 |       |       | Q1,02 | PCWP |            |
| 10 |           PX RECEIVE          |                     | 1010K|    50M|   694   (1)| 00:00:13 |       |       | Q1,02 | PCWP |            |
| 11 |            PX SEND HASH       | :TQ10000            | 1010K|    50M|   694   (1)| 00:00:13 |       |       | Q1,00 | P->P | HASH       |
| 12 |             PX BLOCK ITERATOR |                     | 1010K|    50M|   694   (1)| 00:00:13 |   KEY |   KEY | Q1,00 | PCWC |            |
| 13 |              TABLE ACCESS FULL| SOT_KEYMAP          | 1010K|    50M|   694   (1)| 00:00:13 |   KEY |   KEY | Q1,00 | PCWP |            |
| 14 |          PX RECEIVE           |                     |    11M|   688M| 1129   (3)| 00:00:21 |       |       | Q1,02 | PCWP |            |
| 15 |           PX SEND HASH        | :TQ10001            |    11M|   688M| 1129   (3)| 00:00:21 |       |       | Q1,01 | P->P | HASH       |
| 16 |            PX JOIN FILTER USE | :BF0000             |    11M|   688M| 1129   (3)| 00:00:21 |       |       | Q1,01 | PCWP |            |
| 17 |             PX BLOCK ITERATOR |                     |    11M|   688M| 1129   (3)| 00:00:21 |   KEY |   KEY | Q1,01 | PCWC |            |
| 18 |              TABLE ACCESS FULL| SOT_REL_STAGE       |    11M|   688M| 1129   (3)| 00:00:21 |   KEY |   KEY | Q1,01 | PCWP |            |
| 19 |         PARTITION RANGE SINGLE|                     | 5209 | 72926 |     0   (0)|          |   KEY |   KEY | Q1,02 | PCWP |            |
| 20 |          INDEX RANGE SCAN     | IDXL_SOTCRCT_SOT_UD | 5209 | 72926 |     0   (0)|          |   KEY |   KEY | Q1,02 | PCWP |            |
EXECUTION PLAN AFTER SETTING DEGREE=1 (It was also degraded)
| Id | Operation                 | Name                | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT          |                     |     1 |   129 |       | 42336   (2)| 00:12:43 |       |       |
|   1 | HASH GROUP BY            |                     |     1 |   129 |       | 42336   (2)| 00:12:43 |       |       |
|   2 |   NESTED LOOPS ANTI       |                     |     1 |   129 |       | 42335   (2)| 00:12:43 |       |       |
|* 3 |    HASH JOIN              |                     |     1 |   115 |    51M| 42334   (2)| 00:12:43 |       |       |
|   4 |     PARTITION RANGE SINGLE|                     |   846K|    41M|       | 8241   (1)| 00:02:29 |    81 |    81 |
|* 5 |      TABLE ACCESS FULL    | SOT_KEYMAP          |   846K|    41M|       | 8241   (1)| 00:02:29 |    81 |    81 |
|   6 |     PARTITION RANGE SINGLE|                     | 8161K|   490M|       | 12664   (3)| 00:03:48 |    81 |    81 |
|* 7 |      TABLE ACCESS FULL    | SOT_REL_STAGE       | 8161K|   490M|       | 12664   (3)| 00:03:48 |    81 |    81 |
|   8 |    PARTITION RANGE SINGLE |                     | 6525K|    87M|       |     1   (0)| 00:00:01 |    81 |    81 |
|* 9 |     INDEX RANGE SCAN      | IDXL_SOTCRCT_SOT_UD | 6525K|    87M|       |     1   (0)| 00:00:01 |    81 |    81 |
Predicate Information (identified by operation id):
   3 - access("SOTRELSTG_SYS_UD"="SOTKEY_SYS_UD" AND "SOTRELSTG_ORIG_SYS_ORD_ID"="SOTKEY_SYS_ORD_ID" AND
              NVL("SOTRELSTG_ORIG_SYS_ORD_VSEQ",1)=NVL("SOTKEY_SYS_ORD_VSEQ",1))
   5 - filter("SOTKEY_TRD_DATE_YMD_PART"=20090219 AND "SOTKEY_IUD_CD"='I')
   7 - filter("SOTRELSTG_CRCT_PROC_STAT_CD"='N' AND "SOTRELSTG_TRD_DATE_YMD_PART"=20090219)
   9 - access("SOTRELSTG_SOT_UD"="SOTCRCT_SOT_UD" AND "SOTCRCT_TRD_DATE_YMD_PART"=20090219)2. Why are you passing the partition name as bind variable? A statement executing 5 mins. best, > 2 hours worst obviously doesn't suffer from hard parsing issues and
doesn't need to (shouldn't) share execution plans therefore. So I strongly suggest to use literals instead of bind variables. This also solves any potential issues caused
by bind variable peeking.
This is a custom application which uses bind variables to extract data from daily partitions.So,daily automated data extract from daily paritions after load and ELT process.
Here,Value of bind variable is being passed through a procedure parameter.It would be bit difficult to use literals in such application.
3. All your posted plans suffer from bad cardinality estimates. The NO_MERGE hint suggested by Timur only caused a (significant) damage limitation by obviously reducing
the row source size by the group by operation before joining, but still the optimizer is way off, apart from the obviously wrong join order (larger row set first) in
particular the NESTED LOOP operation is causing the main troubles due to excessive logical I/O, as already pointed out by Timur.
Can i ask for alternatives to NESTED LOOP?
4. Your PLAN_TABLE seems to be old (you should see a corresponding note at the bottom of the DBMS_XPLAN.DISPLAY output), because none of the operations have a
filter/access predicate information attached. Since your main issue are the bad cardinality estimates, I strongly suggest to drop any existing PLAN_TABLEs in any non-Oracle
owned schemas because 10g already provides one in the SYS schema (GTT PLAN_TABLE$) exposed via a public synonym, so that the EXPLAIN PLAN information provides the
"Predicate Information" section below the plan covering the "Filter/Access" predicates.
Please post a revised explain plan output including this crucial information so that we get a clue why the cardinality estimates are way off.
I have dropped the old plan.Got above execution plan(listed above in first point) with PREDICATE information.
"As already mentioned the usage of bind variables for the partition name makes this issue potentially worse."
Is there any workaround without replacing bind variable.I am on 10g so 11g's feature will not help !!!
How are you gathering the statistics daily, can you post the exact command(s) used?
gather_table_part_stats(i_owner_name,i_table_name,i_part_name,i_estimate:= DBMS_STATS.AUTO_SAMPLE_SIZE, i_invalidate IN VARCHAR2 := 'Y',i_debug:= 'N')
Thanks & Regards,
Bhavik Desai

Can we implement the custom sql query in CR for joining the two tables

Hi All,
Is there anyway to implement the custom sql query in CR for joining the two tables?
My requirement here is I need to write sql logics for joining the two tables...
Thanks,
Gana

In the Database Expert, expand the Create New Connection folder and browse the subfolders to locate your data source.
Log on to your data source if necessary.
Under your data source, double-click the Add Command node.
In the Add Command to Report dialog box, enter an appropriate query/command for the data source you have opened.
For example:
SELECT
    Customer.`Customer ID`,
    Customer.`Customer Name`,
    Customer.`Last Year's Sales`,
    Customer.`Region`,
    Customer.`Country`,
    Orders.`Order Amount`,
    Orders.`Customer ID`,
    Orders.`Order Date`
FROM
    Customer Customer INNER JOIN Orders Orders ON
        Customer.`Customer ID` = Orders.`Customer ID`
WHERE
    (Customer.`Country` = 'USA' OR
    Customer.`Country` = 'Canada') AND
    Customer.`Last Year's Sales` < 10000.
ORDER BY
    Customer.`Country` ASC,
    Customer.`Region` ASC
Note: The use of double or single quotes (and other SQL syntax) is determined by the database driver used by your report. You must, however, manually add the quotes and other elements of the syntax as you create the command.
Optionally, you can create a parameter for your command by clicking Create and entering information in the Command Parameter dialog box.
For more information about creating parameters, see To create a parameter for a command object.
Click OK.
You are returned to the Report Designer. In the Field Explorer, under Database Fields, a Command table appears listing the database fields you specified.
Note:
To construct the virtual table from your Command, the command must be executed once. If the command has parameters, you will be prompted to enter values for each one.
By default, your command is called Command. You can change its alias by selecting it and pressing F2.

CBO (10g): unable to estimate the good NL join cardinality

Hi all,
In my 10.2.0.4 database, the CBO does not choose the good execution plan for the following query:
SELECT A.CNACT, A.LCACT, I.CMECH, I.CAECH, I.CSOPT, T.COLAN, I.MTSNA
FROM TPOOIN_TT T, IAVOPE I, NATACF A
WHERE T.POTMP IN ('TABDJO_TT', 'TCLRJO_TT', 'TCORJO_TT','TDLVJO_TT', 'TEXEJO_TT', 'TOPEJO_TT')
AND INSTR(',' || T.LIMAR || ',', ',' || I.COMAR || ',', 1) != 0
AND T.COINT IN (I.COINC,I.COINF)
AND I.DATRA BETWEEN T.DATRA AND T.DAMAX
AND A.ID_CNACT = I.ID_CNACT;
The execution plan chosen by the CBO is the following:
SQL_ID 762utndb7xxsa, child number 0
SELECT     A.CNACT, A.LCACT, I.CMECH, I.CAECH, I.CSOPT, T.COLAN, I.MTSNA   FROM
TPOOIN_TT T, IAVOPE I, NATACF A WHERE T.POTMP IN (:"SYS_B_00", :"SYS_B_01", :"SYS_B_02",
    :"SYS_B_03", :"SYS_B_04", :"SYS_B_05")    AND INSTR(:"SYS_B_06" || T.LIMAR || :"SYS_B_07",
:"SYS_B_08" || I.COMAR || :"SYS_B_09", :"SYS_B_10") != :"SYS_B_11"    AND T.COINT IN (I.COINC,I.COINF)
AND I.DATRA BETWEEN T.DATRA AND T.DAMAX    AND A.ID_CNACT = I.ID_CNACT
Plan hash value: 1994655966
| Id | Operation                      | Name        | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads |
|   1 | NESTED LOOPS                  |             |      1 |      1 |    100 |00:02:16.62 |      20M|    203K|
|   2 |   NESTED LOOPS                 |             |      1 |      1 |   6757K|00:02:35.45 |     585K|    203K|
|   3 |    TABLE ACCESS FULL           | NATACF      |      1 |   2919 |     61 |00:00:00.01 |       6 |      0 |
|   4 |    TABLE ACCESS BY INDEX ROWID | IAVOPE      |     61 |      1 |   6757K|00:02:35.47 |     585K|    203K|
|   5 |     BITMAP CONVERSION TO ROWIDS|             |     61 |        |   6757K|00:00:00.02 |     771 |    589 |
|* 6 |      BITMAP INDEX SINGLE VALUE | IAVOPE9_BMP |     61 |        |   1145 |00:00:01.92 |     771 |    589 |
|* 7 |   TABLE ACCESS FULL            | TPOOIN_TT   |   6757K|      1 |    100 |00:01:51.64 |      20M|      0 |
Predicate Information (identified by operation id):
   6 - access("A"."ID_CNACT"="I"."ID_CNACT")
   7 - filter((INTERNAL_FUNCTION("T"."POTMP") AND INSTR(:SYS_B_06||"T"."LIMAR"||:SYS_B_07,:SYS_B_08||"I".
              "COMAR"||:SYS_B_09,:SYS_B_10)<>:SYS_B_11 AND ("T"."COINT"="I"."COINC" OR "T"."COINT"="I"."COINF") AND
              "I"."DATRA">="T"."DATRA" AND "I"."DATRA"<="T"."DAMAX"))
Note
   - dynamic sampling used for this statement
if I use the hint ORDERED, the query runs instantly.
Apparently, the CBO is mistaken when it estimates the join cardinality for NATACF and IAVOPE tables.
Indeed, it estimates that the NESTED LOOP is going to return only a single row (column E-Rows) instead of 6757K rows (column A-Rows).
By looking at the 10053 trace file we can see that the CBO is unable to estimate the join cardinality:
Join order[4]: NATACF[A]#1 IAVOPE#2 TPOOIN_TT[T]#0
Now joining: IAVOPE[I]#2
NL Join
Outer table: Card: 2919.00 Cost: 26.27 Resp: 26.27 Degree: 1 Bytes: 24
Inner table: IAVOPE Alias: I
Access Path: TableScan
NL Join: Cost: 793981231.57 Resp: 793981231.57 Degree: 1
Cost_io: 775301479.00 Cost_cpu: 553603549165062
Resp_io: 775301479.00 Resp_cpu: 553603549165062
****** trying bitmap/domain indexes ******
Access Path: index (AllEqJoinGuess)
Index: IAVOPE9_BMP
resc_io: 2.00 resc_cpu: 15293
ix_sel: 0.016667 ix_sel_with_filters: 0.016667
NL Join: Cost: 5865.78 Resp: 5865.78 Degree: 1
Cost_io: 5864.00 Cost_cpu: 52626084
Resp_io: 5864.00 Resp_cpu: 52626084
Access path: Bitmap index - accepted
Cost: 5892.05 Cost_io: 5890.00 Cost_cpu: 60612251 Sel: 0.0000e+00
Not believed to be index-only
****** finished trying bitmap/domain indexes ******
Best NL cost: 5892.05
resc: 5892.05 resc_io: 5890.00 resc_cpu: 60612251
resp: 5892.05 resp_io: 5890.00 resp_cpu: 60612251
Join Card: 0.00 = outer (2919.00) * inner (62632660.00) * sel (0.0000e+00)
Join Card - Rounded: 1 Computed: 0.00
The cardinality of the inner and the outer table are well estimated but the CBO is using ZERO as the selectivity.
Does someone know why the CBO is making this estimation?
Is it a bug ?
thanks for your help

I think there is a bug with DBMS_XPLAN beacause there are 2919 rows in NATACF table. This tabe is static.
My post concerns the fact that the CBO estimates 0 rows as the result of the join between IAVOPE and NATACF.
That's what I want to understand.
Join Card: 0.00 = outer (2919.00) * inner (62632660.00) * sel (0.0000e+00)The issue is not located on the temporary table since when I run a query with only NATACF and IAVOPE and I get the wrong estimation
select A.CNACT, A.LCACT, I.CMECH, I.CAECH, I.CSOPT, I.MTSNA from IAVOPE I, NATACF A where
I.DATRA = to_date(:"SYS_B_0",:"SYS_B_1") AND A.ID_CNACT = I.ID_CNACT
Plan hash value: 2748866919
| Id | Operation                     | Name        | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads |
|* 1 | TABLE ACCESS BY INDEX ROWID | IAVOPE      |      1 |      1 |    100 |00:00:00.24 |    9506 |      7 |
|   2 |   NESTED LOOPS                |             |      1 |      1 | 43580 |00:00:00.08 |      14 |      0 |
|   3 |    TABLE ACCESS FULL          | NATACF      |      1 |   2919 |      1 |00:00:00.01 |       4 |      0 |
|   4 |    BITMAP CONVERSION TO ROWIDS|             |      1 |        | 43579 |00:00:00.02 |      10 |      0 |
|* 5 |     BITMAP INDEX SINGLE VALUE | IAVOPE9_BMP |      1 |        |     15 |00:00:00.01 |      10 |      0 |
Predicate Information (identified by operation id):
   1 - filter("I"."DATRA"=TO_DATE(:SYS_B_0,:SYS_B_1))
   5 - access("A"."ID_CNACT"="I"."ID_CNACT")
Join order[1]: NATACF[A]#0 IAVOPE#1
Now joining: IAVOPE[I]#1
NL Join
Outer table: Card: 2919.00 Cost: 26.27 Resp: 26.27 Degree: 1 Bytes: 24
Inner table: IAVOPE Alias: I
Access Path: TableScan
NL Join: Cost: 900314800.50 Resp: 900314800.50 Degree: 1
Cost_io: 875835670.00 Cost_cpu: 725477142751961
Resp_io: 875835670.00 Resp_cpu: 725477142751961
****** trying bitmap/domain indexes ******
Access Path: index (AllEqJoin)
Index: IAVOPE7_BMP
resc_io: 39.00 resc_cpu: 293786
ix_sel: 0.021477 ix_sel_with_filters: 0.021477
NL Join: Cost: 113896.21 Resp: 113896.21 Degree: 1
Cost_io: 113867.00 Cost_cpu: 865547968
Resp_io: 113867.00 Resp_cpu: 865547968
Access Path: index (AllEqJoinGuess)
Index: IAVOPE9_BMP
resc_io: 2.00 resc_cpu: 15293
ix_sel: 0.016129 ix_sel_with_filters: 0.016129
NL Join: Cost: 5865.78 Resp: 5865.78 Degree: 1
Cost_io: 5864.00 Cost_cpu: 52626084
Resp_io: 5864.00 Resp_cpu: 52626084
Access path: Bitmap index - accepted
Cost: 5892.05 Cost_io: 5890.00 Cost_cpu: 60612251 Sel: 0.0000e+00
Not believed to be index-only
****** finished trying bitmap/domain indexes ******
Best NL cost: 5892.05
resc: 5892.05 resc_io: 5890.00 resc_cpu: 60612251
resp: 5892.05 resp_io: 5890.00 resp_cpu: 60612251
Join Card: 0.00 = outer (2919.00) * inner (1408783.43) * sel (0.0000e+00)
Join Card - Rounded: 1 Computed: 0.00

Where clause on right side table of a left join

I was told by someone that a where clause on the right side table of a left join is bad SQL. I have looked around and found a great article for DB2. I am not sure if this is 100% correct for SQL Server so would like to find a good detailed
article on the topic.
Thank you

I was told by someone that a where clause on the right side table of a left join is bad SQL. I have looked around and found a great article for DB2. I am not sure if this is 100% correct for SQL Server so would like to find a good detailed
article on the topic.
Thank you
I'm going to be blunt here so if you get offended easily please stop reading now.
That has got to be some of the dumbest advice I've seen in a while. Such a query serves a specific purpose, there's no good or bad to it. Following is a classic example:
select distinct
CustomerID
from Customer as c
left join Orders as o
on c.CustomerID = o.CustomerID
and o.OrderDate > dateadd(day, -90, getdate())
where o.CustomerID is null
The above hypothetical query, which includes a where clause which targets the right table in a left join, returns all customers which have not placed an order in the past 90 days. It's a perfectly valid query which serves a key business purpose and
I challenge anyone to justify why they claim it is "bad SQL".
Such a query will execute efficiently given appropriate indices. There's simply no justification for such a blanket statement about where clauses and outer joins.

Join hint ignored - very bad query plan results

I'm trying to get a query that's being generated by SSAS to perform acceptably. Because this query is (at least partially) generated by SSAS, I don't have complete control over the query text.
The problem - The query looks roughly like this:
select
-- a bunch of columns
from
T1 -- table with ~40,000,000 rows
inner loop join T2 on T2.t2id = T1.t2id -- table with ~16,000 rows
inner loop join T3 on T3.t3id = T1.t3id -- table with ~200,000 rows inner loop join T4 on T4.t4id = T1.t4id -- table with ~200,000 rows
left loop join T5 on T5.t3id = T1.t3id and T5.t6id = T4.t6id -- table with 0 rows
where
-- some uninteresting conditions
T1 is a Fact (or Measure) table, T2, T3 and T4 are Dimension tables, T5 and T6 are involved in the filtering of the query. Every row of T1 WILL match exactly one row in each of T1, T2 and T3.
You'll note that I've hinted all of the joins - according to the documentation, using join hints forces join order (which is consistent with the plan that's produced). There's no mention that join hints can be transparently ignored by the optimizer,
but that seems to be precisely what's happening.
In the plan that results, the join to T4 is done as a hash join, with T1*T2*T3 (40,000,000 rows) on the "top", so it ends up trying to build a hash table with 40,000,000 rows, resulting in very high tempdb activity and very poor performance (I
don't know how poor - I've never let it finish).
I can see part of the reason why it's making this join choice - the estimate of T1*T2*T3 is only 35,000 rows, even though T1 has 40,000,000 rows and the join will hit on every row.
Questions:
1. What can I do to the query or the database to improve the estimate on the join to T3?
2. What can I do to the query to force the optimizer to use a loop join like I asked?
Version is SQL Server 2008 R2 SP2 Developer Edition X64.
OS is Windows 2008 R2
Machine is dual-quad-hyper-threaded CPU with 96Gb of RAM and several Tb of disk spread over 8 spindles and SSDs.
I've seen this query perform well before - I've been tuning this query for going on 7 years now and I've never seen it perform this badly that I can recall. Not sure if it's something that's changed in SP2, or something about the distribution
of data in this particular database that's changed, but something's sure changed.
-cd Mark the best replies as answers!

That would indicate that there are no foreign-key constraints, or if they, they are not trusted. (Assuming here that there WHERE clause includes no filter on T1.)
That, or the statistics on T1 are giving a completely wrong estimates for the number of NULL values in t2id and t3id.
Erland Sommarskog, SQL Server MVP, [email protected]
Thanks, Erland.
There are foreign key constraints, but they're NOCHECK. I've tried creating and updating statistics on various columns of the tables involved - I'll re-check that I've got up to date statistics on all of the columns involved in these joins.
What about the join-hint being ignored? Is there anything I can do, or has something changed here recently? Interestingly, when I run this query from SSMS, I get loop-joins all around, but when SSAS runs the query, the one join always comes out
a hash join. Before I added the hints, all joins were hash joins - the hints worked on all joins but the one.
-cd Mark the best replies as answers!

Union All slow with order by

I have 2 queries that I do an "union all" and then an order by after the "union all" This seems to be extremely slow. But when I run the queries individually, they are really fast. Could some help me out with this please.
SELECT *
FROM (SELECT a.*, ROWNUM rnum
          FROM (SELECT   COLS......
    FROM (((SELECT from tables with joins)
           UNION ALL
           (SELECT from tables and view with joins))
            order by colname)
      ) a
         WHERE ROWNUM <= 500)
WHERE rnum >= 1
PLAN_TABLE_OUTPUT
Plan hash value: 3988534528
| Id | Operation                                      | Name                          | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT                               |                               |   500 | 1600K|       | 3634M (1)|999:59:59 |       |       |
|* 1 | VIEW                                          |                               |   500 | 1600K|       | 3634M (1)|999:59:59 |       |       |
|* 2 |   COUNT STOPKEY                                |                               |       |       |       |            |          |       |       |
|   3 |    VIEW                                        |                               | 4277K|    13G|       | 3634M (1)|999:59:59 |       |       |
|* 4 |     SORT ORDER BY STOPKEY                      |                               | 4277K|   311M| 1095M| 3634M (1)|999:59:59 |       |       |
|   5 |      UNION-ALL                                 |                               |       |       |       |            |          |       |       |
PLAN_TABLE_OUTPUT
|* 6 |       FILTER                                   |                               |       |       |       |            |          |       |       |
|* 7 |        HASH JOIN                               |                               |   212K|    15M|       |   153K (1)| 00:03:37 |       |       |
|* 8 |         HASH JOIN RIGHT OUTER                  |                               |   507 | 22308 |       |     6 (17)| 00:00:01 |       |       |
|   9 |          TABLE ACCESS FULL                     | DIR                          |   143 | 3861 |       |     2   (0)| 00:00:01 |       |       |
| 10 |          TABLE ACCESS FULL                     | USER                          |   507 | 8619 |       |     3   (0)| 00:00:01 |       |       |
| 11 |         PARTITION RANGE ITERATOR               |                               |   212K| 6645K|       |   153K (1)| 00:03:37 |   KEY |   KEY |
| 12 |          TABLE ACCESS BY LOCAL INDEX ROWID     | FL                                |   212K| 6645K|       |   153K (1)| 00:03:37 |   KEY |   KEY |
|* 13 |           INDEX RANGE SCAN                     | I_FL_ID                      |   382K|       |       | 38943   (2)| 00:00:56 |   KEY |   KEY |
|* 14 |            COUNT STOPKEY                       |                               |       |       |       |            |          |       |       |
|* 15 |             FILTER                             |                               |       |       |       |            |          |       |       |
| 16 |              PARTITION RANGE ITERATOR          |                               |     1 |    22 |       |   856   (1)| 00:00:02 |   KEY |   KEY |
PLAN_TABLE_OUTPUT
|* 17 |               TABLE ACCESS BY LOCAL INDEX ROWID| PAY                           |     1 |    22 |       |   856   (1)| 00:00:02 |   KEY |   KEY |
|* 18 |                INDEX RANGE SCAN                | I_PAY_FLID                       |     1 |       |       |   855   (1)| 00:00:02 |   KEY |   KEY |
|* 19 |       FILTER                                   |                               |       |       |       |            |          |       |       |
|* 20 |        HASH JOIN RIGHT OUTER                   |                               | 25019 | 3029K|       |   138K (1)| 00:03:17 |       |       |
| 21 |         TABLE ACCESS FULL                      | DIR                            |   143 | 3861 |       |     2   (0)| 00:00:01 |       |       |
|* 22 |         HASH JOIN                              |                               | 25019 | 2369K|       |   138K (1)| 00:03:17 |       |       |
| 23 |          TABLE ACCESS FULL                     | USER                          |   507 | 8619 |       |     3   (0)| 00:00:01 |       |       |
|* 24 |          HASH JOIN                             |                               | 25019 | 1954K|       |   138K (1)| 00:03:17 |       |       |
| 25 |           INDEX FULL SCAN                      | PK_HO                         |   278 | 1112 |       |     1   (0)| 00:00:01 |       |       |
|* 26 |           HASH JOIN                            |                               | 25019 | 1856K|       |   138K (1)| 00:03:17 |       |       |
| 27 |            INDEX FULL SCAN                     | PK_HO                         |   278 | 1112 |       |     1   (0)| 00:00:01 |       |       |
PLAN_TABLE_OUTPUT
| 28 |            NESTED LOOPS                        |                               | 25019 | 1759K|       |   138K (1)| 00:03:17 |       |       |
| 29 |             PARTITION RANGE ITERATOR           |                               | 25018 |   830K|       | 63575   (1)| 00:01:30 |   KEY |   KEY |
|* 30 |              TABLE ACCESS BY LOCAL INDEX ROWID | PAY                           | 25018 |   830K|       | 63575   (1)| 00:01:30 |   KEY |   KEY |
|* 31 |               INDEX RANGE SCAN                 | I_PAY_TIME_ID                  | 1493K|       |       | 9052   (2)| 00:00:13 |   KEY |   KEY |
|* 32 |             TABLE ACCESS BY GLOBAL INDEX ROWID | FL                            |     1 |    38 |       |     3   (0)| 00:00:01 | ROWID | ROWID |
|* 33 |              INDEX UNIQUE SCAN                 | PK_FL                         |     1 |       |       |     2   (0)| 00:00:01 |       |       |
SELECT *
FROM (SELECT a.*, ROWNUM rnum
          FROM ( SELECT from tables with joins order by colname) a
         WHERE ROWNUM <= 500)
WHERE rnum >= 1
PLAN_TABLE_OUTPUT
Plan hash value: 3503998222
| Id | Operation                                     | Name                    | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT                              |                         |   500 | 1228K|   222K (1)| 00:05:15 |       |       |
|* 1 | VIEW                                         |                         |   500 | 1228K|   222K (1)| 00:05:15 |       |       |
|* 2 |   COUNT STOPKEY                               |                         |       |       |            |          |       |       |
|   3 |    VIEW                                       |                         |   520 | 1271K|   222K (1)| 00:05:15 |       |       |
|* 4 |     FILTER                                    |                         |       |       |            |          |       |       |
|   5 |      NESTED LOOPS OUTER                       |                         |    26 | 1976 |    54   (0)| 00:00:01 |       |       |
PLAN_TABLE_OUTPUT
|   6 |       NESTED LOOPS                            |                         |    26 | 1274 |    48   (0)| 00:00:01 |       |       |
|   7 |        PARTITION RANGE ITERATOR               |                         |   212K| 6645K|    22   (0)| 00:00:01 |   KEY |   KEY |
|   8 |         TABLE ACCESS BY LOCAL INDEX ROWID     | FL                      |   212K| 6645K|    22   (0)| 00:00:01 |   KEY |   KEY |
|* 9 |          INDEX RANGE SCAN                     | I_FL_START_ID              |    47 |       |     8   (0)| 00:00:01 |   KEY |   KEY |
|* 10 |           COUNT STOPKEY                       |                         |       |       |            |          |       |       |
|* 11 |            FILTER                             |                         |       |       |            |          |       |       |
| 12 |             PARTITION RANGE ITERATOR          |                         |     1 |    22 |   856   (1)| 00:00:02 |   KEY |   KEY |
|* 13 |              TABLE ACCESS BY LOCAL INDEX ROWID| PAY                   |     1 |    22 |   856   (1)| 00:00:02 |   KEY |   KEY |
|* 14 |               INDEX RANGE SCAN                | I_PAY_ID               |     1 |       |   855   (1)| 00:00:02 |   KEY |   KEY |
| 15 |        TABLE ACCESS BY INDEX ROWID            | USER                     |     1 |    17 |     1   (0)| 00:00:01 |       |       |
|* 16 |         INDEX UNIQUE SCAN                     | PK_USER                  |     1 |       |     0   (0)| 00:00:01 |       |       |
PLAN_TABLE_OUTPUT
| 17 |       TABLE ACCESS BY INDEX ROWID             | DIR                    |     1 |    27 |     1   (0)| 00:00:01 |       |       |
|* 18 |        INDEX UNIQUE SCAN                      | PK_DIR                 |     1 |       |     0   (0)| 00:00:01 |       |       |
   SELECT *
FROM (SELECT a.*, ROWNUM rnum
          FROM ( SELECT from tables and view with joins order by colname) a
         WHERE ROWNUM <= 500)
WHERE rnum >= 1
PLAN_TABLE_OUTPUT
Plan hash value: 1786470271
| Id | Operation                                   | Name                          | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT                            |                               |   500 | 1600K| 1696   (1)| 00:00:03 |       |       |
|* 1 | VIEW                                       |                               |   500 | 1600K| 1696   (1)| 00:00:03 |       |       |
|* 2 |   COUNT STOPKEY                             |                               |       |       |            |          |       |       |
|   3 |    VIEW                                     |                               |   501 | 1596K| 1696   (1)| 00:00:03 |       |       |
|* 4 |     FILTER                                  |                               |       |       |            |          |       |       |
|   5 |      NESTED LOOPS                           |                               |   501 | 60120 | 1696   (1)| 00:00:03 |       |       |
PLAN_TABLE_OUTPUT
|   6 |       NESTED LOOPS                          |                               |   501 | 58116 | 1696   (1)| 00:00:03 |       |       |
|   7 |        NESTED LOOPS OUTER                   |                               |   501 | 56112 | 1695   (1)| 00:00:03 |       |       |
|   8 |         NESTED LOOPS                        |                               |   501 | 42585 | 1689   (1)| 00:00:03 |       |       |
|   9 |          NESTED LOOPS                       |                               |   501 | 34068 | 1550   (1)| 00:00:03 |       |       |
| 10 |           PARTITION RANGE ITERATOR          |                               |   829K|    23M|    42   (0)| 00:00:01 |   KEY |   KEY |
| 11 |            TABLE ACCESS BY LOCAL INDEX ROWID| PAY                        |   829K|    23M|    42   (0)| 00:00:01 |   KEY |   KEY |
|* 12 |             INDEX RANGE SCAN                | I_PAY_TIME_ID               |   902 |       |     9   (0)| 00:00:01 |   KEY |   KEY |
|* 13 |           TABLE ACCESS BY GLOBAL INDEX ROWID| FL                               |     1 |    38 |     3   (0)| 00:00:01 | ROWID | ROWID |
|* 14 |            INDEX UNIQUE SCAN                | PK_FL                            |     1 |       |     2   (0)| 00:00:01 |       |       |
| 15 |          TABLE ACCESS BY INDEX ROWID        | USER                              |     1 |    17 |     1   (0)| 00:00:01 |       |       |
|* 16 |           INDEX UNIQUE SCAN                 | PK_USER                           |     1 |       |     0   (0)| 00:00:01 |       |       |
PLAN_TABLE_OUTPUT
| 17 |         TABLE ACCESS BY INDEX ROWID         | DIR                          |     1 |    27 |     1   (0)| 00:00:01 |       |       |
|* 18 |          INDEX UNIQUE SCAN                  | PK_DIR                          |     1 |       |     0   (0)| 00:00:01 |       |       |
|* 19 |        INDEX UNIQUE SCAN                    | PK_HO                         |     1 |     4 |     0   (0)| 00:00:01 |       |       |
|* 20 |       INDEX UNIQUE SCAN                     | PK_HO                         |     1 |     4 |     0   (0)| 00:00:01 |       |       |
---------------------------------------------------------------------------------------------------------------------------------------------

Can you limit the number of rows coming out of each part of the UNION ALL before limiting the number of rows you're trying to return? So that you end up with something like
SELECT *
FROM (<<Get first 500 rows from first query>>
       UNION ALL
       <<Get first 500 rows from second query>>)
WHERE rownum <= 500It appears from the query plan that your problem is that Oracle is sorting the entire result of the UNION ALL before finding the first 500 rows. That's obviously rather time consuming since the two queries return 10's of GB of data. Individually, the two queries are fast because you're limiting each of them to 500 rows, so Oracle can do a quick index scan (presumably on the sort column) that would find those rows.
And depending on what's behind the queries, I'd look to see whether you can put some additional filter conditions in place to look for data with dates in the past day or two in order to at least limit the worst case if Oracle does have to sort everything.
Justin

Rownum and order by as parameter

i want a procedure that will accept the 'from' and 'to' parameter (rownum) for paginaton as well as the order by column also as a parameter( the order by changes based on the parameter) , and my query is using multiple table which doesnt have Unique keys, the pagination is not working poperly at that time..
please have a look in to the procedure..
CREATE OR REPLACE Procedure P_pagination
(cur out sys_refcursor,end1 number,start1 number,ordr number)
as
Var_sql varchar2(4000);
begin
var_sql := ' Select * '||
          ' From '||
          ' (select rownum rwnum,aa.* from ' ||
          ' (select ti.a,t2.a,t3.a,t4.b from t1,t2,t3,t4 where < all the joins> order by '||ordr||' )aa'||
          ' where rownum <='|| end1 ||') ' ||
          ' where rwnum >='|| start1 ;
open cur for var_sql;
end ;
/

If you don't specify explicit ORDER BY clause
Oracle wont guarantee the order of the sort. You specify ORDER BY ID , but
not ORDER BY ID, <<something>> , so you have unrepeatable results. Your order by ID but don't order inside ID. Look:
SQL> select *
2 from
3 (select a.*, rownum rnum
4 from
5 (select id, data
6 from t
7 order by id) a
8 where rownum <= 150
9 )
10 where rnum >= 148
11 /
        ID       DATA       RNUM
         0         34        148
         0         54        149
         0         81        150
SQL> select *
2 from
3 (select a.*, rownum rnum
4 from
5 (select id, data
6 from t
7 order by id) a
8 where rownum <= 151
9 )
10 where rnum >= 148
11 /
        ID       DATA       RNUM
         0         28        148
         0         34        149
         0         54        150
         0         81        151
SQL> select *
2 from
3 (select a.*, rownum rnum
4 from
5 (select id, data
6 from t
7 order by id, rowid) a
8 where rownum <= 150
9 )
10 where rnum >= 148
11 /
        ID       DATA       RNUM
         0         24        148
         0         21        149
         0         35        150
SQL> select *
2 from
3 (select a.*, rownum rnum
4 from
5 (select id, data
6 from t
7 order by id, rowid) a
8 where rownum <= 151
9 )
10 where rnum >= 148;
        ID       DATA       RNUM
         0         24        148
         0         21        149
         0         35        150
         0         68        151Rgds.

Join Order

Similar Messages

Maybe you are looking for