This discussion is archived
13 Replies Latest reply: Apr 18, 2013 7:03 PM by Hemant K Chitale RSS

ORDER BY clause introduces dramatic performance difference

MSandico Newbie
Currently Being Moderated
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.
  • 1. Re: ORDER BY clause introduces dramatic performance difference
    Marcus Rangel Journeyer
    Currently Being Moderated
    How big is the table ? Maybe it seems that the order by clause is slowing things down only because the unordered query begins to return records immediately and the ordered one needs to get everything before it can return the first record.
  • 2. Re: ORDER BY clause introduces dramatic performance difference
    Marcus Rangel Journeyer
    Currently Being Moderated
    Can you compare the running time for these two ?
    select count(*) from (SELECT * from TableA ORDER BY col1, col2, col3);
    select count(*) from (SELECT * from TableA);
  • 3. Re: ORDER BY clause introduces dramatic performance difference
    Mohamed ELAzab Pro
    Currently Being Moderated
    Hello,

    Increasing memory is not a perfect solution in all cases.To tune this query i will ask you some questions:
    1-Have you checked if the statistics were updated on that table?.
    2-You can generate the execution plan for both queries and then you can compare the difference in the acess path for each query and then determine where the big cost in the query that takes a long time goes.

    I want also to know your database version and OS and the value set for pga_aggregrate_target .
    Please post both execution plans for both queries.

    Kind Regards
    Mohamed ELAzab
  • 4. Re: ORDER BY clause introduces dramatic performance difference
    MSandico Newbie
    Currently Being Moderated
    My settings:

    NAME TYPE VALUE
    -------------------------------------------------- ----------- ----------------------------------------------------------------------------------------------------
    archive_lag_target integer 0
    db_flashback_retention_target integer 1440
    fast_start_io_target integer 0
    fast_start_mttr_target integer 0
    memory_max_target big integer 8000M
    memory_target big integer 4000M
    parallel_servers_target integer 128
    pga_aggregate_target big integer 0
    sga_target big integer 0


    I am also in the process of running those queries and getting runtimes....not sure why the pga_aggregate_target is set to 0? (because of AMM?)
  • 5. Re: ORDER BY clause introduces dramatic performance difference
    EdStevens Guru
    Currently Being Moderated
    MSandico wrote:
    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,
    Well, yes, sorting the result set is going to be more expensive than not sorting it, but ..
    and if possible, move that operation to the application layer
    really???? Do you really think your app code can sort it faster than the database engine?


    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.
  • 6. Re: ORDER BY clause introduces dramatic performance difference
    jgarry Guru
    Currently Being Moderated
    1. Show us runtime plans for both situations.
    2. There is an advisor for setting pga_aggregate_target. You can deal with it in tables, or see pretty pictures with EM.
    3. The pretty pictures clearly show the differences between 1 pass and multi-pass operations. This can be an obvious indicator of whether you can benefit overall from general pga changes.
    4. Performance problems are usually code.
    5. Specific code may benefit from not using the general pga aggregate. In other words, if you have a few queries that are just way outliers, it may benefit you to set their sessions to use manual pga and sort settings.
    6. There are situations where the app code can sort better, but generally the database engine is the better place. It Depends. If you are essentially doing an ETL, sometimes that is a situation.
  • 7. Re: ORDER BY clause introduces dramatic performance difference
    Hemant K Chitale Oracle ACE
    Currently Being Moderated
    How did you time the "9 minutes" and "8 seconds" ? _Did you wait for all the rows to be retrieved_ ? How many rows are being retrieved ? What is the row-length ? What are the datatypes and column-lengths of the three columns "col1", "col2", "col3" ?


    Hemant K Chitale
  • 8. Re: ORDER BY clause introduces dramatic performance difference
    Mohamed Houri Pro
    Currently Being Moderated
    Could you please post the execution plan of both queries (with and without order by). And it will be nice to have the optimizer parameters your are using
    SQL> show parameter '%optimizer%'
    
    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- ------------
    ----
    optimizer_dynamic_sampling           integer     2
    optimizer_features_enable            string      10.2.0.4
    optimizer_index_caching              integer     0
    optimizer_index_cost_adj             integer     100
    optimizer_mode                       string      ALL_ROWS
    optimizer_secure_view_merging        boolean     TRUE
    Best regards
    Mohamed Houri
    www.hourim.wordpress.com
  • 9. Re: ORDER BY clause introduces dramatic performance difference
    MSandico Newbie
    Currently Being Moderated
    Thanks for all the responses so far, one big mistake i should have mentioned was that the it SELECTS from a view and there is a lot of underlying logic..which of course can contribute to the performance but the presence (or not) of the ORDER BY statement still looks like a huge impact b/c of sorting.

    I have the explain plans but saved in HTML... im using SQL Developer 3.2

    What's the best way to copy and paste the explain plan from there into this forum post so it's easily read by all?
  • 10. Re: ORDER BY clause introduces dramatic performance difference
    Mohamed Houri Pro
    Currently Being Moderated
    I have the explain plans but saved in HTML... im using SQL Developer 3.2
    1. execute your query
    2. select * from table(dbms_xplan.display_cursor);
    Do this for both queries and post the execution plan together with the predicate part. Don't forget to use the code tag in order to have your execution nicely formatted (use the tab Preview before posting your message)


    Best regards
    Mohamed Houri
    www.hourim.wordpress.com
  • 11. Re: ORDER BY clause introduces dramatic performance difference
    MSandico Newbie
    Currently Being Moderated
    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"")"
  • 12. Re: ORDER BY clause introduces dramatic performance difference
    Hemant K Chitale Oracle ACE
    Currently Being Moderated
    The XPLAN_DISPLAY shows that the Optimizer expects only 1 row to be retrieved in the result-set.


    Did you wait for all the rows to be retrieved ? How many rows are actually being retrieved and sorted ? What is the row-length ? What are the datatypes and column-lengths of the three columns "col1", "col2", "col3" -- which are the ORDER BY columns ?


    Hemant K Chitale
  • 13. Re: ORDER BY clause introduces dramatic performance difference
    Hemant K Chitale Oracle ACE
    Currently Being Moderated
    The XPLAN_DISPLAY shows that the Optimizer expects only 1 row to be retrieved in the result-set.


    Did you wait for all the rows to be retrieved ? How many rows are actually being retrieved and sorted ? What is the row-length ? What are the datatypes and column-lengths of the three columns "col1", "col2", "col3" -- which are the ORDER BY columns ?


    Hemant K Chitale

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points