ORDER BY clause introduces dramatic performance difference

Hi All,
Oracle 11G on Windows 2008 R2.
I have a basic SELECT * from TableA ORDER BY col1, col2, col3 statement that gives very different runtimes.
With the ORDER BY it takes 9 mins.
Without the ORDER BY it takes 8 seconds.
I know that ORDER BY, in general, is an expensive operation, and if possible, move that operation to the application layer but in this case it's not possible. I've read that i can adjust 1 or 2 parameters to affect how sort operations are handled by the optmizer - sort_area_size and pga_aggregate_target. The latter one being the one i'm 'supposed' to change for a better effect.
We use automatic memory management and have given Oracle db 6GB out of 16GB on the dedicated database server.
Question:
1) Any thoughts as to what i can change pga_aggregate_target to?
2) Or should i just change the AMM to get more memory and let Oracle handle the memory allocation itself, hoping that more memory will mean faster sort results?
Thx in advance.

Thank you for the tip, here are the explain plans
WITHOUT ORDER BY:
"PLAN_TABLE_OUTPUT"
"Plan hash value: 2332686131"
"| Id  | Operation                         | Name                | Rows  | Bytes | Cost (%CPU)| Time     |"
"|   0 | SELECT STATEMENT                  |                     |     1 |   242 |  3234   (1)| 00:00:39 |"
"|   1 |  NESTED LOOPS                     |                     |       |       |            |          |"
"|   2 |   NESTED LOOPS                    |                     |     2 |    52 |     6   (0)| 00:00:01 |"
"|*  3 |    INDEX RANGE SCAN               | ISD_TRAFFIC_BOOST_I |     4 |    76 |     3   (0)| 00:00:01 |"
"|*  4 |    INDEX UNIQUE SCAN              | RMS_PK              |     1 |       |     0   (0)| 00:00:01 |"
"|*  5 |   TABLE ACCESS BY INDEX ROWID     | M_RM_SCHEDULES      |     1 |     7 |     1   (0)| 00:00:01 |"
"|   6 |  NESTED LOOPS                     |                     |       |       |            |          |"
"|   7 |   NESTED LOOPS                    |                     |     2 |    44 |     6   (0)| 00:00:01 |"
"|*  8 |    INDEX RANGE SCAN               | ISD_TRAFFIC_BOOST_I |     4 |    60 |     3   (0)| 00:00:01 |"
"|*  9 |    INDEX UNIQUE SCAN              | RMS_PK              |     1 |       |     0   (0)| 00:00:01 |"
"|* 10 |   TABLE ACCESS BY INDEX ROWID     | M_RM_SCHEDULES      |     1 |     7 |     1   (0)| 00:00:01 |"
"|  11 |  NESTED LOOPS                     |                     |       |       |            |          |"
"|  12 |   NESTED LOOPS                    |                     |     1 |   242 |  3234   (1)| 00:00:39 |"
"|  13 |    NESTED LOOPS                   |                     |     1 |   233 |  3233   (1)| 00:00:39 |"
"|  14 |     NESTED LOOPS                  |                     |     1 |   222 |  3231   (1)| 00:00:39 |"
"|  15 |      NESTED LOOPS                 |                     |     1 |   214 |  3230   (1)| 00:00:39 |"
"|  16 |       NESTED LOOPS                |                     |     1 |   205 |  3229   (1)| 00:00:39 |"
"|* 17 |        HASH JOIN                  |                     |     7 |  1267 |  3222   (1)| 00:00:39 |"
"|* 18 |         TABLE ACCESS FULL         | M_REQ_TO_POS        |  3424 | 71904 |   584   (1)| 00:00:08 |"
"|* 19 |         HASH JOIN                 |                     |  3232 |   505K|  2638   (1)| 00:00:32 |"
"|  20 |          SORT UNIQUE              |                     |  4577 | 45770 |     7   (0)| 00:00:01 |"
"|  21 |           INDEX FAST FULL SCAN    | PTBP_UK             |  4577 | 45770 |     7   (0)| 00:00:01 |"
"|* 22 |          HASH JOIN                |                     |  2376 |   348K|  2630   (1)| 00:00:32 |"
"|* 23 |           HASH JOIN               |                     |  2298 |   302K|  2353   (1)| 00:00:29 |"
"|* 24 |            HASH JOIN RIGHT OUTER  |                     |  2298 |   271K|  2277   (1)| 00:00:28 |"
"|  25 |             VIEW                  | index$_join$_009    |    14 |   126 |     3  (34)| 00:00:01 |"
"|* 26 |              HASH JOIN            |                     |       |       |            |          |"
"|  27 |               INDEX FAST FULL SCAN| FRT_PK              |    14 |   126 |     1   (0)| 00:00:01 |"
"|  28 |               INDEX FAST FULL SCAN| FRT_UK              |    14 |   126 |     1   (0)| 00:00:01 |"
"|* 29 |             TABLE ACCESS FULL     | M_ITEM_SHIPS        |  2298 |   251K|  2274   (1)| 00:00:28 |"
"|* 30 |            INDEX RANGE SCAN       | APOLI_UK            | 18650 |   254K|    75   (0)| 00:00:01 |"
"|  31 |           TABLE ACCESS FULL       | M_REQ_LI_TO_POLIS   |   105K|  1541K|   276   (1)| 00:00:04 |"
"|  32 |        TABLE ACCESS BY INDEX ROWID| M_PO_LINE_ITEMS     |     1 |    24 |     1   (0)| 00:00:01 |"
"|* 33 |         INDEX UNIQUE SCAN         | POLI_PK             |     1 |       |     0   (0)| 00:00:01 |"
"|  34 |       TABLE ACCESS BY INDEX ROWID | M_UNITS             |     1 |     9 |     1   (0)| 00:00:01 |"
"|* 35 |        INDEX UNIQUE SCAN          | UNIT_PK             |     1 |       |     0   (0)| 00:00:01 |"
"|* 36 |      TABLE ACCESS BY INDEX ROWID  | M_REQS              |     1 |     8 |     1   (0)| 00:00:01 |"
"|* 37 |       INDEX UNIQUE SCAN           | R_PK                |     1 |       |     0   (0)| 00:00:01 |"
"|  38 |     TABLE ACCESS BY INDEX ROWID   | M_IDENTS            |     1 |    11 |     2   (0)| 00:00:01 |"
"|* 39 |      INDEX UNIQUE SCAN            | I_PK                |     1 |       |     1   (0)| 00:00:01 |"
"|* 40 |    INDEX UNIQUE SCAN              | CC_PK               |     1 |       |     0   (0)| 00:00:01 |"
"|  41 |   TABLE ACCESS BY INDEX ROWID     | M_COMMODITY_CODES   |     1 |     9 |     1   (0)| 00:00:01 |"
"Predicate Information (identified by operation id):"
"   3 - access(""MISD"".""ITEM_SHIP_ID""=:B1)"
"   4 - access(""MRS"".""RMS_ID""=""MISD"".""RMS_ID"")"
"   5 - filter(""MRS"".""DELV_DATE_IND""='Y')"
"   8 - access(""MISD"".""ITEM_SHIP_ID""=:B1)"
"   9 - access(""MRS"".""RMS_ID""=""MISD"".""RMS_ID"")"
"  10 - filter(""MRS"".""DELV_DATE_IND""='Y')"
"  17 - access(""RLTP"".""R_ID""=""RP"".""R_ID"" AND ""PTBP"".""RP_ID""=""RP"".""RP_ID"")"
"  18 - filter(""RP"".""RLI_ID"" IS NULL)"
"  19 - access(""PTBP"".""POH_ID""=""RLTP"".""POH_ID"")"
"  22 - access(""APOLI"".""POLI_ID""=""RLTP"".""POLI_ID"")"
"  23 - access(""ISH"".""PROJ_ID""=""APOLI"".""PROJ_ID"" AND ""ISH"".""POLI_ID""=""APOLI"".""POLI_ID"")"
"  24 - access(""ISH"".""FRT_ID""=""FRT"".""FRT_ID""(+))"
"  26 - access(ROWID=ROWID)"
"  29 - filter(""ISH"".""PROJ_ID""='H333966' AND UPPER(NVL(""ISH"".""OWL"",'NON')) NOT LIKE 'EXCLUDE%' "
"              AND ""ISH"".""ITEM_SHIP_QTY"">0)"
"  30 - access(""APOLI"".""PROJ_ID""='H333966')"
"  33 - access(""POLI"".""POLI_ID""=""APOLI"".""POLI_ID"")"
"       filter(""POLI"".""POLI_ID""=""ISH"".""POLI_ID"")"
"  35 - access(""QTY_UNIT"".""UNIT_ID""=""ISH"".""QTY_UNIT_ID"")"
"  36 - filter(""R"".""R_SUPP""=""M_PCK_EXPED_WORKLOAD"".""GET_MAX_ISH_R_SUPPL""(""POLI"".""POLI_ID""))"
"  37 - access(""R"".""R_ID""=""RP"".""R_ID"")"
"  39 - access(""MI"".""IDENT""=""POLI"".""IDENT"")"
"  40 - access(""MI"".""COMMODITY_ID""=""MCC"".""COMMODITY_ID"")"WITH THE ORDER BY:
"PLAN_TABLE_OUTPUT"
"Plan hash value: 3346887832"
"| Id  | Operation                          | Name                | Rows  | Bytes | Cost (%CPU)| Time     |"
"|   0 | SELECT STATEMENT                   |                     |     1 |   242 |  3235   (1)| 00:00:39 |"
"|   1 |  NESTED LOOPS                      |                     |       |       |            |          |"
"|   2 |   NESTED LOOPS                     |                     |     2 |    52 |     6   (0)| 00:00:01 |"
"|*  3 |    INDEX RANGE SCAN                | ISD_TRAFFIC_BOOST_I |     4 |    76 |     3   (0)| 00:00:01 |"
"|*  4 |    INDEX UNIQUE SCAN               | RMS_PK              |     1 |       |     0   (0)| 00:00:01 |"
"|*  5 |   TABLE ACCESS BY INDEX ROWID      | M_RM_SCHEDULES      |     1 |     7 |     1   (0)| 00:00:01 |"
"|   6 |  NESTED LOOPS                      |                     |       |       |            |          |"
"|   7 |   NESTED LOOPS                     |                     |     2 |    44 |     6   (0)| 00:00:01 |"
"|*  8 |    INDEX RANGE SCAN                | ISD_TRAFFIC_BOOST_I |     4 |    60 |     3   (0)| 00:00:01 |"
"|*  9 |    INDEX UNIQUE SCAN               | RMS_PK              |     1 |       |     0   (0)| 00:00:01 |"
"|* 10 |   TABLE ACCESS BY INDEX ROWID      | M_RM_SCHEDULES      |     1 |     7 |     1   (0)| 00:00:01 |"
"|  11 |  SORT ORDER BY                     |                     |     1 |   242 |  3235   (1)| 00:00:39 |"
"|  12 |   NESTED LOOPS                     |                     |       |       |            |          |"
"|  13 |    NESTED LOOPS                    |                     |     1 |   242 |  3234   (1)| 00:00:39 |"
"|  14 |     NESTED LOOPS                   |                     |     1 |   233 |  3233   (1)| 00:00:39 |"
"|  15 |      NESTED LOOPS                  |                     |     1 |   222 |  3231   (1)| 00:00:39 |"
"|  16 |       NESTED LOOPS                 |                     |     1 |   214 |  3230   (1)| 00:00:39 |"
"|  17 |        NESTED LOOPS                |                     |     1 |   205 |  3229   (1)| 00:00:39 |"
"|* 18 |         HASH JOIN                  |                     |     7 |  1267 |  3222   (1)| 00:00:39 |"
"|* 19 |          TABLE ACCESS FULL         | M_REQ_TO_POS        |  3424 | 71904 |   584   (1)| 00:00:08 |"
"|* 20 |          HASH JOIN                 |                     |  3232 |   505K|  2638   (1)| 00:00:32 |"
"|  21 |           SORT UNIQUE              |                     |  4577 | 45770 |     7   (0)| 00:00:01 |"
"|  22 |            INDEX FAST FULL SCAN    | PTBP_UK             |  4577 | 45770 |     7   (0)| 00:00:01 |"
"|* 23 |           HASH JOIN                |                     |  2376 |   348K|  2630   (1)| 00:00:32 |"
"|* 24 |            HASH JOIN               |                     |  2298 |   302K|  2353   (1)| 00:00:29 |"
"|* 25 |             HASH JOIN RIGHT OUTER  |                     |  2298 |   271K|  2277   (1)| 00:00:28 |"
"|  26 |              VIEW                  | index$_join$_009    |    14 |   126 |     3  (34)| 00:00:01 |"
"|* 27 |               HASH JOIN            |                     |       |       |            |          |"
"|  28 |                INDEX FAST FULL SCAN| FRT_PK              |    14 |   126 |     1   (0)| 00:00:01 |"
"|  29 |                INDEX FAST FULL SCAN| FRT_UK              |    14 |   126 |     1   (0)| 00:00:01 |"
"|* 30 |              TABLE ACCESS FULL     | M_ITEM_SHIPS        |  2298 |   251K|  2274   (1)| 00:00:28 |"
"|* 31 |             INDEX RANGE SCAN       | APOLI_UK            | 18650 |   254K|    75   (0)| 00:00:01 |"
"|  32 |            TABLE ACCESS FULL       | M_REQ_LI_TO_POLIS   |   105K|  1541K|   276   (1)| 00:00:04 |"
"|  33 |         TABLE ACCESS BY INDEX ROWID| M_PO_LINE_ITEMS     |     1 |    24 |     1   (0)| 00:00:01 |"
"|* 34 |          INDEX UNIQUE SCAN         | POLI_PK             |     1 |       |     0   (0)| 00:00:01 |"
"|  35 |        TABLE ACCESS BY INDEX ROWID | M_UNITS             |     1 |     9 |     1   (0)| 00:00:01 |"
"|* 36 |         INDEX UNIQUE SCAN          | UNIT_PK             |     1 |       |     0   (0)| 00:00:01 |"
"|* 37 |       TABLE ACCESS BY INDEX ROWID  | M_REQS              |     1 |     8 |     1   (0)| 00:00:01 |"
"|* 38 |        INDEX UNIQUE SCAN           | R_PK                |     1 |       |     0   (0)| 00:00:01 |"
"|  39 |      TABLE ACCESS BY INDEX ROWID   | M_IDENTS            |     1 |    11 |     2   (0)| 00:00:01 |"
"|* 40 |       INDEX UNIQUE SCAN            | I_PK                |     1 |       |     1   (0)| 00:00:01 |"
"|* 41 |     INDEX UNIQUE SCAN              | CC_PK               |     1 |       |     0   (0)| 00:00:01 |"
"|  42 |    TABLE ACCESS BY INDEX ROWID     | M_COMMODITY_CODES   |     1 |     9 |     1   (0)| 00:00:01 |"
"Predicate Information (identified by operation id):"
"   3 - access(""MISD"".""ITEM_SHIP_ID""=:B1)"
"   4 - access(""MRS"".""RMS_ID""=""MISD"".""RMS_ID"")"
"   5 - filter(""MRS"".""DELV_DATE_IND""='Y')"
"   8 - access(""MISD"".""ITEM_SHIP_ID""=:B1)"
"   9 - access(""MRS"".""RMS_ID""=""MISD"".""RMS_ID"")"
"  10 - filter(""MRS"".""DELV_DATE_IND""='Y')"
"  18 - access(""RLTP"".""R_ID""=""RP"".""R_ID"" AND ""PTBP"".""RP_ID""=""RP"".""RP_ID"")"
"  19 - filter(""RP"".""RLI_ID"" IS NULL)"
"  20 - access(""PTBP"".""POH_ID""=""RLTP"".""POH_ID"")"
"  23 - access(""APOLI"".""POLI_ID""=""RLTP"".""POLI_ID"")"
"  24 - access(""ISH"".""PROJ_ID""=""APOLI"".""PROJ_ID"" AND ""ISH"".""POLI_ID""=""APOLI"".""POLI_ID"")"
"  25 - access(""ISH"".""FRT_ID""=""FRT"".""FRT_ID""(+))"
"  27 - access(ROWID=ROWID)"
"  30 - filter(""ISH"".""PROJ_ID""='H333966' AND UPPER(NVL(""ISH"".""OWL"",'NON')) NOT LIKE 'EXCLUDE%' AND "
"              ""ISH"".""ITEM_SHIP_QTY"">0)"
"  31 - access(""APOLI"".""PROJ_ID""='H333966')"
"  34 - access(""POLI"".""POLI_ID""=""APOLI"".""POLI_ID"")"
"       filter(""POLI"".""POLI_ID""=""ISH"".""POLI_ID"")"
"  36 - access(""QTY_UNIT"".""UNIT_ID""=""ISH"".""QTY_UNIT_ID"")"
"  37 - filter(""R"".""R_SUPP""=""M_PCK_EXPED_WORKLOAD"".""GET_MAX_ISH_R_SUPPL""(""POLI"".""POLI_ID""))"
"  38 - access(""R"".""R_ID""=""RP"".""R_ID"")"
"  40 - access(""MI"".""IDENT""=""POLI"".""IDENT"")"
"  41 - access(""MI"".""COMMODITY_ID""=""MCC"".""COMMODITY_ID"")"

Similar Messages

  • Is there any performance difference in the order of columns referencing index?

    I wish to find out if there is any performance difference or efficiency in specifying those columns referencing index(es) first in the WHERE clause of SQL statements. That is, whether the order of columns referencing the index is important???.
    E.g. id is the column that is indexed
    SELECT * FROM a where a.id='1' and a.name='John';
    SELECT * FROM a where a.name='John' and a.id='1';
    Is there any differences in terms of efficiency of the 2 statements??
    Please advise. Thanks.

    There is no difference between the two statements under either the RBO or the CBO.
    sql>create table a as select * from all_objects;
    Table created.
    sql>create index a_index on a(object_id);
    Index created.
    sql>analyze table a compute statistics;
    Table analyzed.
    sql>select count(*)
      2    from a
      3   where object_id = 1
      4     and object_name = 'x';
    COUNT(*)
            0
    1 row selected.
    Execution Plan
       0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=29)
       1    0   SORT (AGGREGATE)
       2    1     TABLE ACCESS (BY INDEX ROWID) OF 'A' (Cost=1 Card=1 Bytes=29)
       3    2       INDEX (RANGE SCAN) OF 'A_INDEX' (NON-UNIQUE) (Cost=1 Card=1)
    sql>select count(*)
      2    from a
      3   where object_name = 'x'   
      4     and object_id = 1;
    COUNT(*)
            0
    1 row selected.
    Execution Plan
       0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=29)
       1    0   SORT (AGGREGATE)
       2    1     TABLE ACCESS (BY INDEX ROWID) OF 'A' (Cost=1 Card=1 Bytes=29)
       3    2       INDEX (RANGE SCAN) OF 'A_INDEX' (NON-UNIQUE) (Cost=1 Card=1)

  • Order By Clause - Slows performance

    On 10.2 when adding an order by clause to a query affects performance that returns 6 rows of data.
    Before:
    select distinct col1
    from table1
    Cost: 3,000
    Execution Time: less than a second
    Chooses: Bitmap Index Fast Full Scan Index (BitMap)
    After:
    select distinct col1
    from table1
    order by col1
    Cost: 14,000
    Execution time: 90 seconds
    Chooses: Full TableScan
    Any ideas as to why the order by causes the slow down ?
    Thanks,

    Venzi wrote:
    Now you add the order by clause to it and Oracle has now to do a sort on it. It can't sort on the BITMAP index in that case so it has to go to the table. It is possible for Oracle to do the order by through the bitmap index - the reason it doesn't is probably down to arithmetic. (The situation is made a little messier by the fact that the table and index have been parallel enabled). Here's a plan from 10.2.0.3 showing the "order by" query running through the bitmap index:
    | Id  | Operation                          | Name     | Rows  | Bytes | Cost  |    TQ  |IN-OUT| PQ Distrib |
    |   0 | SELECT STATEMENT                   |          |     6 |    18 |   356 |        |      |            |
    |   1 |  PX COORDINATOR                    |          |       |       |       |        |      |            |
    |   2 |   PX SEND QC (ORDER)               | :TQ10001 |     6 |    18 |   356 |  Q1,01 | P->S | QC (ORDER) |
    |   3 |    SORT GROUP BY                   |          |     6 |    18 |   356 |  Q1,01 | PCWP |            |
    |   4 |     PX RECEIVE                     |          |  2000K|  5859K|    63 |  Q1,01 | PCWP |            |
    |   5 |      PX SEND RANGE                 | :TQ10000 |  2000K|  5859K|    63 |  Q1,00 | P->P | RANGE      |
    |   6 |       PX BLOCK ITERATOR            |          |  2000K|  5859K|    63 |  Q1,00 | PCWC |            |
    |   7 |        BITMAP CONVERSION TO ROWIDS |          |  2000K|  5859K|    63 |  Q1,00 | PCWP |            |
    |   8 |         BITMAP INDEX FAST FULL SCAN| T1_B1    |       |       |       |  Q1,00 | PCWP |            |
    ------------------------------------------------------------------------------------------------------------Note how the optimizer can recognise that the "group by" operation will allow it to avoid an explicit "order by" operation, and uses the "(ORDER)" distribution to pass the data to the Query Coordinator to enforce correct ordering.
    Running up a test case with a couple of million rows, it looks like the underlying problem the OP has is that the CBO bypasses a few of the execution options in this particular case when parallel execution is possible. (I had to hint this plan - the default plan was a serial full scan of the index that allowed the optimizer to bypass the "sort order" because of a "sort unique", but the cost was much higher than this parallel plan - see below).
    | Id  | Operation               | Name  | Rows  | Bytes | Cost  |
    |   0 | SELECT STATEMENT        |       |     6 |    18 |  2269 |
    |   1 |  SORT UNIQUE NOSORT     |       |     6 |    18 |  2269 |
    |   2 |   BITMAP INDEX FULL SCAN| T1_B1 |  2000K|  5859K|   278 |
    -----------------------------------------------------------------Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
    There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
    +"I believe in evidence. I believe in observation, measurement, and reasoning, confirmed by independent observers. I'll believe anything, no matter how wild and ridiculous, if there is evidence for it. The wilder and more ridiculous something is, however, the firmer and more solid the evidence will have to be."+
    Isaac Asimov                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • SQL: order of WHERE clauses important for performance?

    I wonder if the order of the WHERE clauses does affect performance or if the database optimize each query so that the order is irrelevant? Example: is
    SELECT *
    FROM Table1
    WHERE (fast condition check)
    AND (slow condition check)
    faster than
    SELECT *
    FROM Table1
    WHERE (slow condition check)
    AND (fast condition check)
    because the first condition check might be false and therefore the second is not executed? (Some kind of Java if (fast && slow) is faster than if (slow && fast) ?)

    It depends on how sophisticated the database optimizer is. IBM's DB2/UDB will completely rewrite the syntax of SQL as part of optimization and does not care what the order of the where clause is. Oracle actually has two optimizers RULE and COST. The RULE based optimizer is affected by the order of the where clause, COST is not (RULE is no longer available in the newest version of Oracle, Oracle 10g).

  • Performance issue-order by clause

    hi all,
    i hava a Query it will take time to exec 6 sec....
    i want to reduce it less 1 sec
    i found the problem,that Query it will take more time to Order BY clause...
    how to improve the performance ?

    Try it with an index. Or give us more information about the query.
    How did you find out that it takes more time with the order? Usually ordering does takes time but not so much. be aware that when you add an order by clause then any tool can start showing you the records only after the query is finished. If you have no order by, you can see some results already even if the query is not finished yet.
    Make sure you compare the total running time of the query, not only how fast you see the first records.

  • Performance with order by clause

    Dear all,
    please find the below query .if i executed without order by it is going to execute with in 2 sec.if i add order by clause
    it is taking more than 2 min.as per the business we need order by clause .plaese suggest me.it's very urgent.
    SELECT "FACILITY_ID","VESSEL_NAME","CLASS_NUM","SURVEY_REPORT_NO","IMO_NUMBER","VESSEL_TYPE","VESSEL_TYPE_ID","PRIMARY_BUILDER","BUILDER_ID","REGISTER_OWNER","ABS_SURVEY_STATUS_ID","ABS_SURVEY_STATUS_DATE","NOT_ASSIGNED_SINCE","NO_OF_FINDINGS","CASE","SPM_ITM_CAT_NAME","LEAST_CONFIDENCE" FROM (SELECT
    V. FACILITY_ID,
    v.vessel_name,
    v.class_num,
    ASR.SURVEY_REPORT_NO,
    V.IMO_NUMBER,
    V.VESSEL_TYPE,
    v.vessel_type_id,
    V.PRIMARY_BUILDER,
    V.BUILDER_ID,
    V.REGISTER_OWNER,
    ASR.ABS_SURVEY_STATUS_ID,
    ASR.abs_survey_status_date,
    ROUND(SYSDATE - ASR.abs_survey_status_date) AS NOT_ASSIGNED_SINCE,
    (SELECT COUNT(1) FROM ABS_FINDINGS WHERE survey_report_no = asr.survey_report_no AND FIN_TAG_STAT_ID IN( 'TG')) AS no_of_findings,
    CASE WHEN ( SELECT rnum FROM (SELECT survey_report_no,COUNT(rnum) rnum FROM (SELECT a.survey_report_no,COUNT(*) rnum FROM ABS_FINDINGS A,ABS_SURVEY_REPORTS b
         WHERE a.survey_report_no=b.survey_report_no
         GROUP BY a.survey_report_no,spm_item_category) GROUP BY survey_report_no ) WHERE survey_report_no=asr.survey_report_no )=1 THEN
    ( SELECT spm_item_cat_id FROM ABS_FINDINGS WHERE survey_report_no = asr.survey_report_no AND ROWNUM<2)
    ELSE
    5
    END CASE,
    (SELECT SPM_ITM_CAT_NAME FROM SPM_ITEM_CATEGORIES WHERE SPM_ITEM_CAT_ID =
    (CASE WHEN ( SELECT rnum FROM (SELECT survey_report_no,COUNT(rnum) rnum FROM (SELECT a.survey_report_no,COUNT(*) rnum FROM ABS_FINDINGS A,ABS_SURVEY_REPORTS b
         WHERE a.survey_report_no=b.survey_report_no
         GROUP BY a.survey_report_no,spm_item_category) GROUP BY survey_report_no ) WHERE survey_report_no=asr.survey_report_no )=1 THEN
    ( SELECT spm_item_cat_id FROM ABS_FINDINGS WHERE survey_report_no = asr.survey_report_no AND ROWNUM<2)
    ELSE
    5
    END )) AS SPM_ITM_CAT_NAME,
    (SELECT MIN(tag_weight) FROM TAGGED_FINDINGS
              WHERE finding_id IN (SELECT finding_id FROM ABS_FINDINGS WHERE survey_report_no IN (ASR.SURVEY_REPORT_NO))) AS least_confidence
    FROM
    ABS_SURVEY_REPORTS ASR,
    ABS_VESSELS V
    WHERE
    ASR.FACILITY_ID = V.FACILITY_ID
    AND abs_survey_Status_id = 1 ) WHERE no_of_findings>0
    ORDER BY ABS_SURVEY_STATUS_DATE
    Thanks
    venkat

    Please start reading these informative links first:
    HOW TO: Post a SQL statement tuning request - template posting
    When your query takes too long ...
    and then rephrase your question by posting
    - database version
    - execution plans
    - etc. (see the links above)
    Put the tag before and after your examples, so it'll stay formatted.
    See: http://forums.oracle.com/forums/help.jspa                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • Error : The ORDER BY clause is invalid in views, inline functions, derived

    Hi All,
    I am on 11g 6.2, Windows Server 2008, my db SQL server 2008, I am facing the error for the reports in which I am trying to edit one the column formula and do something like 'abc/sum(abc)*100'.
    10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query Failed: [nQSError: 16001] ODBC error state: 37000 code: 8180 message: [Microsoft][ODBC SQL Server Driver][SQL Server]Statement(s) could not be prepared.. [nQSError: 16001] ODBC error state: 37000 code: 1033 message: [Microsoft][ODBC SQL Server Driver][SQL Server]The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries, and common table expressions, unless TOP or FOR XML is also specified.. [nQSError: 16002] Cannot obtain number of columns for the query result. (HY000)
    One of the solutions to this which I have found is to edit the EXPRESSION_IN_ORDERBY_SUPPORTED feature in the db properties.
    I want to know what does EXPRESSION_IN_ORDERBY_SUPPORTED means?
    When I create a calculations in 11g like abc/sum(abc) in the column formula for a column then i get this error.
    What does this error mean? Does OBIEE 11g doesn't support using these expressions in the report and the fact that it applies the order by clause to the reports, the report fail?
    Could anybody please explain the issue. There is very limited information on this over the web.
    Thanks in advance.
    Ronny

    Thanks svee for the quick response, actually i had resolved the issue by unchecking the EXPRESSION_IN_ORDERBY_SUPPORTED option in the database. I want to understand how does that makes the difference?
    What does EXPRESSION_IN_ORDERBY_SUPPORTED mean? Does it mean that if I give any expression in my answers report and since obiee uses a order by for all the queries, the expression won't be supported?
    Please explain.

  • Order by clause in Sub query

    Hi,
    Can we use order by clause in Sub query?
    While using the order by clause, I am getting the "missing expression error" . If I remove order by clause query executing fine.
    Here is my query:
    select *
    from emp_mstr
    where emp_no in(select
    emp_no
    from emp_mstr
    order by branch_no);
    Thanks & Regards,
    Mahi

    May be you miss some required spaces also, other than wrong use of ORDER BY
    select *
    from emp_mstr
    where emp_no in
         ( select e2.emp_no
           from emp_mstr e2
    --       order by e2.branch_no
         );Why do you want to ORDER BY in the subquery, which you use with IN clause? That will not make any difference in the result..Means the result you get with ORDER BY will be same as without that.. And in this case, ORDER by is a unncessary overhead.. And Ordering is very costly..
    And why do you want to have the IN clause at all in your query? You are referring the same tables in the main query and sub query..
    The below will give the same result
    select *
    from emp_mstr
    where emp_no is not nullIf you want to use another table in the subquery, always use aliasess...
    select *
    from emp_mstr
    where emp_no in
         ( select e2.emp_no
           from emp_mstr2 e2
    --       order by e2.branch_no
         );

  • Sorting character column ( used in order by clause dynamically)

    Hi,
    I need help on sorting character-based numbers. Like say, I want to sort customers based on street numbers(which is a character string being used in the
    order by clause) they live in.
    The criteria are :
    i. Numbers must take precedence.
    This being a character string, 1000001 comes before 2. This shouldn't happen. And you cannot use to_number
    since using it with a string having characters in it would raise an error.
    ii. If only a single alphabet occurs as the last character, then treat the whole string as a number except the last character and then sort it
    as if sorting a number. Something like : if you have 1000A, 200D, 200B, 1000X, the result would be 200B,200D,1000A,1000X.
    iii. if a character occurs elsewhere in the string, then perform the search normally as if performing a character search.
    The output of the following data :
    100
    A101
    B100A
    110C
    C120B
    120
    100020
    120C
    C1100
    100D
    would be like :
    100
    100D
    110C
    120
    120C
    100020
    A101
    B100A
    C120B
    C1100
    Please note that the sort is being done dynamically, so I could have access to the values of the street numbers only during run time.
    Any help is really appreciated.
    Thanks in advance.
    Regards,
    Anil.

    Create a function to test whether the column is numeric :
    create FUNCTION is_numeric(v_number VARCHAR2)
    RETURN INTEGER
    IS
    l_number NUMBER;
    BEGIN
    IF INSTR(UPPER(v_number),'E') > 0 THEN
    RETURN 0;
    END IF;
    l_number := TO_NUMBER(v_number);
    RETURN 1;
    EXCEPTION
    WHEN OTHERS THEN
    RETURN 0;
    END;
    And try this query
    Assume the table name is TEST with column STREET
    select * from TEST
    order by case is_numeric(STREET) when 1 then LPAD(STREET,20, ' ') else STREET end
    Please make sure that 20 mentioned above is the column size for STREET.
    Hope this helps.
    -Nags

  • Problem in sql query because of order by clause

    Hi All,
    I am facing a one problem in my one sql query.I am using Oracle 10gR2.
    Query is given below:
    SELECT t1.ename
            FROM T1, T2
           WHERE T1.EMPNO = 1234
             AND T1.ACCOUNTNO = T2.ACCOUNTNO
             AND T1.SEQ = T2.SEQ
           ORDER BY T2.SEQThe Plan of the query is :
    | Id  | Operation                     | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT              |                      |     2 |   218 | 11716   (1)| 00:00:41 |
    |*  1 |  TABLE ACCESS BY INDEX ROWID  | T1                   |     1 |    89 |     1   (0)| 00:00:01 |
    |   2 |   NESTED LOOPS                |                      |     2 |   218 | 11716   (1)| 00:00:41 |
    |*  3 |    TABLE ACCESS BY INDEX ROWID| T2                   |     2 |    40 | 11715   (1)| 00:00:41 |
    |   4 |     INDEX FULL SCAN           | PK_T2_SEQ            | 58752 |       |   122   (5)| 00:00:01 |
    |*  5 |    INDEX RANGE SCAN           | FK_ACCOUNTNO         |     3 |       |     0   (0)| 00:00:01 |
    ----------------------------------------------------------------------------------------------------Now i want to reduce the time of this query.
    If i am removing Order by clause from query than performance of the query is totally perfect but with order by clause its taking a time.
    I have already set SORT_AREA_SIZE but still nothing is improving.
    Welcome and thanks for your suggestions.
    Thanks,
    Edited by: BluShadow on 23-Jun-2011 07:55
    added {noformat}{noformat} tags and formatted explain plan to make it readable.  Please see {message:id=9360002} for details on how to post code and data                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

    Hi,
    There are a couple of things I do not understand.
    1. Why don't you put {noformat}{noformat} around your code, it makes it so much easier to read, especially your explain plan
    2. You claim that the ORDER BY is problematic compared to no order by. Then why do you choose to post only one plan?
    3. It is hard to understand how your tables relate, and which indexes you have and which you don't.
    - PK_T2_SEQ, does this mean that SEQ alone is primary key of T2?
    - If SEQ is primary key of T2, why do you join on accountno, seq and not just seq?
    - If SEQ is primary key of T2 one of the tables is denormalized.
    4. FK_ACCOUNTNO, is this an index on accountno, alone?
    - Or is this AccountNo, Seq?
    5. Is there no index on T1.EMPNO?
    Above could of course just be a case of my not understanding the names of your indexes.
    So, here are my guesses:
    Above plan is for the ORDER BY query. That means the optimizer, has chosen to full scan PK_T2_SEQ, since data is then read according to the ORDER BY.
    (This could be a bad choice)I
    You could try and order by t1.seq, instead. Result should be the same.
    Regards
    Peter                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • What is the point in having multiple columns in ORDER BY clause?

    DB version:10gR2
    When using ORDER BY clause, the rows are always sorted according to the first column in the ORDER BY clause. So, what is point in having multiple columns in the ORDER BY clause(i always see this in production codes)?
    For the below SQLs' from SCOTT schema, the result sets are always ordered according the first column ename. When i added job asc and job desc, the result set doesn't change.
    SQL> select * from emp order by ename;
         EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM     DEPTNO
          7876 ADAMS      CLERK           7788 23-MAY-87       1100                    20
          7499 ALLEN      SALESMAN        7698 20-FEB-81       1600        300         30
          7698 BLAKE      MANAGER         7839 01-MAY-81       2850                    30
          7782 CLARK      MANAGER         7839 09-JUN-81       2450                    20
          7902 FORD       ANALYST         7566 03-DEC-81       3000                    20
          7900 JAMES      CLERK           7698 03-DEC-81        950                    30
          7566 JONES      MANAGER         7839 02-APR-81       2975                    20
          7839 KING       PRESIDENT            17-NOV-81       5000                    20
          7654 MARTIN     SALESMAN        7698 28-SEP-81       1250       1400         30
          7934 MILLER     CLERK           7782 23-JAN-82       1300                    20
          7788 SCOTT      ANALYST         7566 19-APR-87       3000                    20
          7369 SMITH      CLERK           7902 17-DEC-80        800                    20
          7844 TURNER     SALESMAN        7698 08-SEP-81       1500          0         30
          7521 WARD       SALESMAN        7698 22-FEB-81       1250        500         30
    14 rows selected.
    SQL> select * from emp order by ename, job;
         EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM     DEPTNO
          7876 ADAMS      CLERK           7788 23-MAY-87       1100                    20
          7499 ALLEN      SALESMAN        7698 20-FEB-81       1600        300         30
          7698 BLAKE      MANAGER         7839 01-MAY-81       2850                    30
          7782 CLARK      MANAGER         7839 09-JUN-81       2450                    20
          7902 FORD       ANALYST         7566 03-DEC-81       3000                    20
          7900 JAMES      CLERK           7698 03-DEC-81        950                    30
          7566 JONES      MANAGER         7839 02-APR-81       2975                    20
          7839 KING       PRESIDENT            17-NOV-81       5000                    20
          7654 MARTIN     SALESMAN        7698 28-SEP-81       1250       1400         30
          7934 MILLER     CLERK           7782 23-JAN-82       1300                    20
          7788 SCOTT      ANALYST         7566 19-APR-87       3000                    20
          7369 SMITH      CLERK           7902 17-DEC-80        800                    20
          7844 TURNER     SALESMAN        7698 08-SEP-81       1500          0         30
          7521 WARD       SALESMAN        7698 22-FEB-81       1250        500         30
    14 rows selected.
    SQL>  select * from emp order by ename, job desc;
         EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM     DEPTNO
          7876 ADAMS      CLERK           7788 23-MAY-87       1100                    20
          7499 ALLEN      SALESMAN        7698 20-FEB-81       1600        300         30
          7698 BLAKE      MANAGER         7839 01-MAY-81       2850                    30
          7782 CLARK      MANAGER         7839 09-JUN-81       2450                    20
          7902 FORD       ANALYST         7566 03-DEC-81       3000                    20
          7900 JAMES      CLERK           7698 03-DEC-81        950                    30
          7566 JONES      MANAGER         7839 02-APR-81       2975                    20
          7839 KING       PRESIDENT            17-NOV-81       5000                    20
          7654 MARTIN     SALESMAN        7698 28-SEP-81       1250       1400         30
          7934 MILLER     CLERK           7782 23-JAN-82       1300                    20
          7788 SCOTT      ANALYST         7566 19-APR-87       3000                    20
          7369 SMITH      CLERK           7902 17-DEC-80        800                    20
          7844 TURNER     SALESMAN        7698 08-SEP-81       1500          0         30
          7521 WARD       SALESMAN        7698 22-FEB-81       1250        500         30
    14 rows selected.

    Because there is only one employee with the name SCOTT,FORD ...etc in the emp table and your first column in the order by list is ename
    you spot the difference now
    SQL> select * from emp order by job;
         EMPNO ENAME      JOB              MGR HIREDATE                  SAL       COMM     DEPTNO
          7788 SCOTT      ANALYST         7566 19-APR-87 00:00:00       3000                    20
          7902 FORD       ANALYST         7566 03-DEC-81 00:00:00       3000                    20
          7934 MILLER     CLERK           7782 23-JAN-82 00:00:00       1300                    10
          7900 JAMES      CLERK           7698 03-DEC-81 00:00:00        950                    30
          7369 SMITH      CLERK           7902 17-DEC-80 00:00:00        800                    20
          7876 ADAMS      CLERK           7788 23-MAY-87 00:00:00       1100                    20
          7698 BLAKE      MANAGER         7839 01-MAY-81 00:00:00       2850                    30
          7566 JONES      MANAGER         7839 02-APR-81 00:00:00       2975                    20
          7782 CLARK      MANAGER         7839 09-JUN-81 00:00:00       2450                    10
          7839 KING       PRESIDENT            17-NOV-81 00:00:00       5000                    10
          7844 TURNER     SALESMAN        7698 08-SEP-81 00:00:00       1500          0         30
          7654 MARTIN     SALESMAN        7698 28-SEP-81 00:00:00       1250       1400         30
          7521 WARD       SALESMAN        7698 22-FEB-81 00:00:00       1250        500         30
          7499 ALLEN      SALESMAN        7698 20-FEB-81 00:00:00       1600        300         30
    14 rows selected.
    Elapsed: 00:00:00.00
    SQL> select * from emp order by job, deptno asc;
         EMPNO ENAME      JOB              MGR HIREDATE                  SAL       COMM     DEPTNO
          7902 FORD       ANALYST         7566 03-DEC-81 00:00:00       3000                    20
          7788 SCOTT      ANALYST         7566 19-APR-87 00:00:00       3000                    20
          7934 MILLER     CLERK           7782 23-JAN-82 00:00:00       1300                    10
          7369 SMITH      CLERK           7902 17-DEC-80 00:00:00        800                    20
          7876 ADAMS      CLERK           7788 23-MAY-87 00:00:00       1100                    20
          7900 JAMES      CLERK           7698 03-DEC-81 00:00:00        950                    30
          7782 CLARK      MANAGER         7839 09-JUN-81 00:00:00       2450                    10
          7566 JONES      MANAGER         7839 02-APR-81 00:00:00       2975                    20
          7698 BLAKE      MANAGER         7839 01-MAY-81 00:00:00       2850                    30
          7839 KING       PRESIDENT            17-NOV-81 00:00:00       5000                    10
          7654 MARTIN     SALESMAN        7698 28-SEP-81 00:00:00       1250       1400         30
          7844 TURNER     SALESMAN        7698 08-SEP-81 00:00:00       1500          0         30
          7521 WARD       SALESMAN        7698 22-FEB-81 00:00:00       1250        500         30
          7499 ALLEN      SALESMAN        7698 20-FEB-81 00:00:00       1600        300         30
    14 rows selected.
    Elapsed: 00:00:00.01
    SQL> select * from emp order by job,deptno desc;
         EMPNO ENAME      JOB              MGR HIREDATE                  SAL       COMM     DEPTNO
          7902 FORD       ANALYST         7566 03-DEC-81 00:00:00       3000                    20
          7788 SCOTT      ANALYST         7566 19-APR-87 00:00:00       3000                    20
          7900 JAMES      CLERK           7698 03-DEC-81 00:00:00        950                    30
          7369 SMITH      CLERK           7902 17-DEC-80 00:00:00        800                    20
          7876 ADAMS      CLERK           7788 23-MAY-87 00:00:00       1100                    20
          7934 MILLER     CLERK           7782 23-JAN-82 00:00:00       1300                    10
          7698 BLAKE      MANAGER         7839 01-MAY-81 00:00:00       2850                    30
          7566 JONES      MANAGER         7839 02-APR-81 00:00:00       2975                    20
          7782 CLARK      MANAGER         7839 09-JUN-81 00:00:00       2450                    10
          7839 KING       PRESIDENT            17-NOV-81 00:00:00       5000                    10
          7844 TURNER     SALESMAN        7698 08-SEP-81 00:00:00       1500          0         30
          7654 MARTIN     SALESMAN        7698 28-SEP-81 00:00:00       1250       1400         30
          7521 WARD       SALESMAN        7698 22-FEB-81 00:00:00       1250        500         30
          7499 ALLEN      SALESMAN        7698 20-FEB-81 00:00:00       1600        300         30
    14 rows selected.
    Elapsed: 00:00:00.01
    SQL>

  • Order by clause require dynamic value

    Hi
    I want to bind parameters to orderby clause. In where clause with bind parameter works fine. But in orderby clause ive done similar steps to have a dynamic sort which will be passed from the previous page in a session variable. Although it didnt show any error at the backend where i can see data getting binded, but no sorting is taking place.
    Can u help me to solve this.
    regards
    Jayashri

    Jayashri,
    I have tested this and you are right. And there does occur an error at the backend, only you wont see it unless you run with BC4J debug mode turned on. You can do this by providing -Djbo.debugoutput=console to the JVM. When running inside JDeveloper, you can accomplish this by going to Project Properties => PRofiles => Development => "Runner", and fill this in at the "Java Options" field.
    Doing that will show the reason of the problem. When a view object is queried, BC4J actually performs 2 queries. One to obtain the 'estimated row count', and then one to obtain the action rows.
    Now suppose your query looks like this:
    SELECT <somefields> FROM <table>
    WHERE <field> = :1 ORDER BY :2
    Bc4j will construct the following query to obtain the estimated rowcount:
    SELECT count(1) FROM (SELECT <somefields> FROM <table> WHERE <field> = :1)
    As you can see, it does NOT include the ORDER BY of the original query in this statement, probably for performance reasons (why order the set if you are only interested in the count). Unfortunately, it WILL try to bind both :1 AND :2 to this query, but because there is only one bind variable in this query, this throws an java.sql.SQLException which is unfortunately trapped somewhere in BC4J code, and not shown in the regular log file.
    I am pretty confident that this is actually a BC4J bug (or known restriction). You could post this problem at the JDeveloper Forum to determine this (without mentioning JHeadstart, because this would also happen if you wrote your own code for binding these parameters).
    As for a workaround, you could try the following:
    1.) Remove the (bind parameter from) the order by clause on the ViewObject
    2.) Remove that same bind parameter from the "Query Bind Parameters" property.
    You should now have gone back to a scenario where there are only bind parameters on the where clause. You would need to set the OrderBy clause programatically now. To do this, extend the JhsDataAction for this page, and override the method 'applyIterBindParams()'. Before calling super, try something like:
    ViewObject vo = ib.getRowSetIterator().getRowSet().getViewObject();
    vo.setOrderByClause(<your dynamic orderby>);
    Kind regards,
    Peter Ebell
    JHeadstart Team

  • Doubt regarding multiple criteria in order by clause

    Hi, I don't understand the effect of multiple elements inside the order by clause. I have the following example table:
    factor_x | factor_y | price
    =====================
    1 | 5 | 1000
    2 | 4 | 6970
    3 | 3 | 3688
    4 | 2 | 9087
    5 | 1 | 10000
    =====================
    So I tried: select price from pricetable order by factor_x; results as follows:
    1000
    6970
    3688
    9087
    10000
    Then: select price from pricetable order by factor_y; results as follows:
    10000
    9087
    3688
    6970
    1000
    Then: select price from pricetable order by factor_x, factor_y; results as follows:
    1000
    6970
    3688
    9087
    10000
    which is same as using order by factor_x. Can anyone tells me what is the effect of adding a 2nd, 3rd..... criterion in the order by clause? Because in this example I cannot see the difference. Many thanks.

    Hi,
    I did a little change in your data. Hope it will help you to understand.
    SQL> WITH T AS (SELECT 1 X , 1 Y , 1000 PRICE FROM DUAL UNION A
      2  SELECT 2 , 4 , 6970 FROM DUAL UNION ALL
      3  SELECT 4 , 3 , 3688 FROM DUAL UNION ALL
      4  SELECT 4 , 2 , 9087 FROM DUAL UNION ALL
      5  SELECT 4 , 5 , 10000 FROM DUAL)
      6  SELECT PRICE,X,Y FROM T ORDER BY X;
         PRICE          X          Y
          1000          1          1
          6970          2          4
          9087          4          2
         10000          4          5
          3688          4          3
    SQL> WITH T AS (SELECT 1 X , 1 Y , 1000 PRICE FROM DUAL UNION A
      2  SELECT 2 , 4 , 6970 FROM DUAL UNION ALL
      3  SELECT 4 , 3 , 3688 FROM DUAL UNION ALL
      4  SELECT 4 , 2 , 9087 FROM DUAL UNION ALL
      5  SELECT 4 , 5 , 10000 FROM DUAL)
      6  SELECT PRICE,X,Y FROM T ORDER BY X,Y;
         PRICE          X          Y
          1000          1          1
          6970          2          4
    9087 4 2
    3688 4 3
    10000 4 5
    SQL>Regards
    Avinash

  • Condition in Order by clause?

    hi,
    my db version is,
         Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
        Im having a query like this,
        select a,b,c,d,sum(e) from f group by a,b,c,d order by a,b,c,d
        Now if the value of the a is 1 i want to have the result of following query
        select a,b,c,d,sum(e) from f group by a,b,c,d order by b,a,c,d
        The only change between the above two queries are order by clause.
    How to achieve this?
    Good help will be appreciated.
    Regards
    Sankar MN
    Edited by: SankarMCA on Oct 5, 2010 4:51 AM

    SankarMCA wrote:
    Im having a query like this,
    select a,b,c,d,sum(e) from f group by a,b,c,d order by a,b,c,dNow if the value of the a is 1 i want to have the result of following query
    select a,b,c,d,sum(e) from f group by a,b,c,d order by b,a,c,d
    What do you mean by "if the value of a is 1"?
    Is it then 1 for the whole result set?
    Or only with a 'group' that has a=1?
    If the latter, then since b,c,d are mentioned in the same order in both order-by clauses, there should be no difference.
    Maybe, you could post two sample outputs (one for both order-by) of this query, so we can see what you mean?

  • SQL Query rewrite, remove ORDER BY clause

    Hello,
    we've just installed a proprietary application which uses an Oracle 11.2.0.2 RAC database. We've seen that one of the auto-generated application's queries
    has poor performance (3-5 minutes for results), the query does a SELECT and at the end it uses an ORDER BY clause. If we remove the ORDER BY clause
    the query returns the results in less than 5 seconds. Unfortunately, we can't re-write the query in the application since we don't have any access to it and
    i was wondering if there is a way to rewrite the specific query from the database.
    We've already seen the SQL Patch but we can change only the hints of the query so we can't remove the ORDER BY clause from it. From what we've seen
    outlines also change only the hints and not the actual sql statement.
    Is there a way to rewrite the specific query from the database ?
    thanks in advance,
    Giannis

    Maybe DBMS_ADVANCED_REWRITE can help but this a SQL question than has very likely nothing to do with RAC.
    See http://www.oracle-base.com/articles/10g/dbms_advanced_rewrite.php.

Maybe you are looking for

  • Request for help in tuning the server which is running opmn process.

    Hi Folks, I request for an help in tuning the server which is running oracle app server opmn process , It is chewing arround 40% of the CPU resource,and our sysadmin is back of me to resolve this issues. any feedback on this is highly appriciated...

  • Print out of time stamp ( time recording) in DBM ( using cats)

    Hello, in DBM we use standard time recording, everytime we post time stamp the system prints output of the time stamp we want to stop it...however is probobly control in HR . Any hints where? we use cac1 profile thanks!!!

  • Total Vendor Balance in Z-form of F.18

    Hi, We use F.18 for vendor balance print. But according to client's requirement we have copied form F130_CONFIRM_01 to ZF130_CONFIRM_01 and made changes as per requirements. But client requires that total balance would be come first at the beginning

  • Problems with Playback in CS5, CS4 (gotoAndPlay command)

    I've encountered a really frustrating issue a couple times now throughout the past year, both in CS5 and CS4.  I get to a certain point in a project where it just seems Flash does not want to cooperate anymore.  It's difficult to even explain what th

  • Virtual 3DS on ESXi

    We're trying to get a new Sourcefire solution up and running.  We're using the virtual servers rather than physical installed onto an ESXi 5.1 host. We're running the 3DS in passive mode so we have 3 network adapters configured, 1 for management, 1 f