Is Query of Queries faster than multiple WHERE criteria?

If I need a recordset based on two table column fields (let's say firstName and lastName), is it better to run one query with a WHERE firstName = x AND lastName = y, or is it better to query of queries and find all records with a specified firstName, and then query that query to filter only records with a specified last name?  Which is the better/faster method?
<cfquery name="somequery" datasource="someds">
SELECT *
FROM sometable
WHERE firstName = 'John' AND lastName = 'Smith'
</cfquery>
or....
<cfquery name="somequery" datasource="someds">
SELECT *
FROM sometable
WHERE firstName = 'John'
</cfquery>
<cfquery name="somequery2" dbtype="query">
SELECT *
FROM somequery
WHERE lastName = 'Smith'
</cfquery>

As a rule of thumb, make the database server do all the work... i.e. locally.  If what you are interested is "first name = x and last name = y," then those are the only records that you want to be "sent over the little wire" to you.  "The little wire" is always the bottleneck.

Similar Messages

  • Straight SQL query results are considerably faster than a FUNCTION...

    Hey all,
    First time new poster, long time reader.
    I have a function that calls a specific query with 2 variables. When I execute the query and hardcode the values, it executes <strong>much </strong>quicker than when the function is called, and the values are passed. I'll give some examples below... here's the full function:
    FUNCTION get_golf_gameplay_completed (
    p_cabinet_id_in NUMBER,
    p_days_back_in NUMBER
    RETURN ref_cursor
    IS
    cu_ref_cur ref_cursor;
    BEGIN
    OPEN cu_ref_cur FOR
    SELECT golf_game_data.cabinet_id, golf_game_data.player_num,
    TO_CHAR
    (global_utility_pkg.cnvrt_gmt_to_local_time_by_cab
    (golf_game_data.cabinet_id,
    golf_game_data.server_start_time,
    golf_game_data.server_start_time
    'MM/DD/YYYY HH:MI:SS AM'
    ) cab_local_event_timestamp,
    TO_CHAR
    (global_utility_pkg.cnvrt_gmt_to_local_time_by_cab
    (golf_game_data.cabinet_id,
    golf_game_data_end_time.server_end_time,
    golf_game_data_end_time.server_end_time
    'MM/DD/YYYY HH:MI:SS AM'
    ) cab_local_session_end,
    TO_CHAR
    (global_utility_pkg.cnvrt_gmt_to_local_time_by_cab
    (golf_game_data.cabinet_id,
    golf_game_data_end_time.server_end_time,
    golf_game_data_end_time.server_end_time
    'HH:MI:SS AM'
    ) cab_local_session_end_time,
    TO_CHAR
    (global_utility_pkg.cnvrt_gmt_to_local_time_by_cab
    (golf_game_data.cabinet_id,
    golf_game_data_end_time.server_end_time,
    golf_game_data_end_time.server_end_time
    'MM/DD/YYYY'
    ) cab_local_server_end_date
    FROM golf_game_data INNER JOIN golf_game_data_end_time
    ON golf_game_data.cabinet_id =
    golf_game_data_end_time.cabinet_id
    AND golf_game_data.player_num =
    golf_game_data_end_time.player_num
    AND golf_game_data.session_id =
    golf_game_data_end_time.session_id
    WHERE golf_game_data.cabinet_id = {color:#ff0000}<strong>p_cabinet_id_in</strong>{color}
    AND golf_game_data_end_time.cabinet_id = {color:#ff0000}<strong>p_cabinet_id_in</strong>{color}
    AND golf_game_data_end_time.server_end_time IS NOT NULL
    AND golf_game_data.server_start_time &gt;= SYSDATE - {color:#ff0000}<strong>p_days_back_in</strong>{color}
    ORDER BY golf_game_data_end_time.server_end_time;
    RETURN cu_ref_cur;
    END get_golf_gameplay_completed;
    I've highlighted the variables for readability.
    This is how I've been executing the function from the SQL*Plus command line:
    select tech_report_package.get_golf_gameplay_completed(122477,10) from dual;
    The speed differences between running the raw query versus the function as a whole have been driving me nuts. For the cabinet IDs (the first variable inserted - in the case above, it would be 122477) that have a high amount of activity on the GOLF_GAME_DATA table, the query itself returns results within a few seconds (usually under 10 seconds even for the most bloated data). However, the function, when called with the same IDs, takes minutes - as long as 3 or 4 minutes in some cases.
    I've run various tests in a cloned production environment, and we've isolated any possible issues with networking, data contention, and partitioning (the GOLF_GAME_DATA table is not partitioned) - the issue is simply the query speed versus function speed, with no external influences.
    What baffles me is the fact that the function is very basic - all it does it executes the query and returns the results, just like the query... the only difference being the cursor that's opened.
    So, getting back to square one; my question was: <u>why would any query run much quicker than a function that does nothing but call the same query?</u>
    Any thoughts?
    Thanks
    -Bob

    No change after using that parameter in the session.
    Any other ideas? I was playing with results with one of my coworkers and my manager, and we were unable to produce any results that were, well, reproducable. Even after <strong>shutting the database down</strong>, and starting it back up, it seems that the results from some of the example queries that we were running were being cached on the SAN which hosts the database's files, or cached and restored after the instance was started up.
    FYI - we test on an instance that mimics production. It's a clone that's produced once a day against the production database, and has no user contention. We bring it up, and are able to test things like we would in production with no other users on the instance at the same time. We are still seeing slow results.

  • First execution of query is always best than all the following

    I have a static query that I execute in sql*plus in the same machine as the database and all the time, the first execution is faster than the following executions and it driving me crazy! Any help is appreciated...
    The database is Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
    The query has a comment in the there so I can change the query to be "different" form the previous ones.
    I ran it in sql*plus with set autotrace traceonly and timing on and the results are:
    First execution:
    SQL> @route
    35 rows selected.
    Elapsed: 00:00:45.49
    Execution Plan
    Plan hash value: 1336726102
    Statistics
    442 recursive calls
    0 db block gets
    6244491 consistent gets
    0 physical reads
    176 redo size
    3333 bytes sent via SQL*Net to client
    9006 bytes received via SQL*Net from client
    4 SQL*Net roundtrips to/from client
    46 sorts (memory)
    0 sorts (disk)
    35 rows processed
    Second Execution:
    SQL> @route
    35 rows selected.
    Elapsed: 00:05:04.85
    Execution Plan
    Plan hash value: 1336726102
    Statistics
    386 recursive calls
    0 db block gets
    1282647 consistent gets
    0 physical reads
    840 redo size
    3333 bytes sent via SQL*Net to client
    9006 bytes received via SQL*Net from client
    4 SQL*Net roundtrips to/from client
    47 sorts (memory)
    0 sorts (disk)
    35 rows processed

    Second run:
    SQL> select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));
    PLAN_TABLE_OUTPUT
    SQL_ID  f2xgmq6bsd6g1, child number 1
    SELECT /* + opt_param('_optimizer_use_feedback' 'false') zzzzz5 */
    route,  MIN(load_start) load_start,  store,  lc_id,  loading_seq,
    pick_zone_name,  MAX(user_name) user_name,  SUM(colli) colli,
    SUM(colli_picked) colli_picked,  round((1 - ((SUM(colli) -
    SUM(colli_picked)) / (SUM(colli)))) * 100, 2) || '%' colli_ready   FROM
    (SELECT route,                load_start,                store,
           lc_id,                loading_seq,                CASE
           WHEN (nbr_pick_zones > 1) THEN                   'MULTIPLE'
                ELSE                   pick_zone_name                END
    pick_zone_name,                (SELECT u.user_name
    FROM dms_user u                  WHERE u.user_id = tab4.user_id
               AND u.facility_id = 'E1') user_name,                colli,
                 (colli - colli_not_picked) colli_picked           FROM
    (SELECT tab3.route,                        tab3.load_start,
               tab3.store,
    Plan hash value: 2089643899
    | Id  | Operation                                         | Name                      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
    |   0 | SELECT STATEMENT                                  |                           |      1 |        |     35 |00:01:51.10 |    1286K|       |       |          |
    |   1 |  TABLE ACCESS BY INDEX ROWID                      | DMS_USER                  |     18 |      1 |     18 |00:00:00.01 |      37 |       |       |          |
    |*  2 |   INDEX UNIQUE SCAN                               | DMS_USER1                 |     18 |      1 |     18 |00:00:00.01 |      17 |       |       |          |
    |   3 |  SORT GROUP BY                                    |                           |      1 |      2 |     35 |00:01:51.10 |    1286K|  9216 |  9216 | 8192  (0)|
    |   4 |   VIEW                                            |                           |      1 |      2 |     43 |00:01:51.09 |    1286K|       |       |          |
    |   5 |    WINDOW BUFFER                                  |                           |      1 |      2 |     43 |00:01:51.09 |    1286K|  6144 |  6144 | 6144  (0)|
    |   6 |     SORT GROUP BY                                 |                           |      1 |      2 |     43 |00:01:51.09 |    1286K| 11264 | 11264 |10240  (0)|
    |   7 |      NESTED LOOPS OUTER                           |                           |      1 |      2 |     43 |00:01:51.09 |    1286K|       |       |          |
    |   8 |       VIEW                                        |                           |      1 |      2 |     43 |00:01:51.09 |    1286K|       |       |          |
    |   9 |        UNION-ALL                                  |                           |      1 |        |     43 |00:01:51.09 |    1286K|       |       |          |
    |  10 |         HASH GROUP BY                             |                           |      1 |      1 |      0 |00:00:01.04 |   33948 |   752K|   752K|          |
    |  11 |          VIEW                                     | VM_NWVW_1                 |      1 |      1 |      0 |00:00:01.04 |   33948 |       |       |          |
    |* 12 |           FILTER                                  |                           |      1 |        |      0 |00:00:01.04 |   33948 |       |       |          |
    |  13 |            HASH GROUP BY                          |                           |      1 |      1 |      0 |00:00:01.04 |   33948 |   694K|   694K|          |
    |  14 |             NESTED LOOPS                          |                           |      1 |        |      0 |00:00:01.04 |   33948 |       |       |          |
    |  15 |              NESTED LOOPS                         |                           |      1 |      1 |      0 |00:00:01.04 |   33948 |       |       |          |
    |  16 |               NESTED LOOPS                        |                           |      1 |      1 |      0 |00:00:01.04 |   33948 |       |       |          |
    |  17 |                NESTED LOOPS                       |                           |      1 |      1 |      0 |00:00:01.04 |   33948 |       |       |          |
    |  18 |                 NESTED LOOPS                      |                           |      1 |      1 |      0 |00:00:01.04 |   33948 |       |       |          |
    |  19 |                  NESTED LOOPS                     |                           |      1 |      1 |      0 |00:00:01.04 |   33948 |       |       |          |
    |  20 |                   NESTED LOOPS                    |                           |      1 |      1 |      0 |00:00:01.04 |   33948 |       |       |          |
    |  21 |                    NESTED LOOPS                   |                           |      1 |      1 |      0 |00:00:01.04 |   33948 |       |       |          |
    |  22 |                     NESTED LOOPS                  |                           |      1 |      1 |      0 |00:00:01.04 |   33948 |       |       |          |
    |  23 |                      NESTED LOOPS                 |                           |      1 |      1 |      0 |00:00:01.04 |   33948 |       |       |          |
    |  24 |                       NESTED LOOPS                |                           |      1 |      1 |      0 |00:00:01.04 |   33948 |       |       |          |
    |* 25 |                        TABLE ACCESS BY INDEX ROWID| CONTAINER                 |      1 |     13 |     36 |00:00:00.01 |      21 |       |       |          |
    |* 26 |                         INDEX SKIP SCAN           | CONTAINER_CARR_SERV_ROUTE |      1 |     28 |     36 |00:00:00.01 |      12 |       |       |          |
    |* 27 |                        TABLE ACCESS BY INDEX ROWID| PICK_DIRECTIVE            |     36 |      1 |      0 |00:00:01.04 |   33927 |       |       |          |
    |* 28 |                         INDEX RANGE SCAN          | PICK_DIRECTIVE_I1         |     36 |      1 |    569K|00:00:00.47 |   12936 |       |       |          |
    |  29 |                       TABLE ACCESS BY INDEX ROWID | PICK_FROM_LOC             |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |* 30 |                        INDEX RANGE SCAN           | PICK_FROM_LOC_ITEM        |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |  31 |                      TABLE ACCESS BY INDEX ROWID  | LOCATION                  |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |* 32 |                       INDEX RANGE SCAN            | LOCATION_ZONE             |      0 |   1053 |      0 |00:00:00.01 |       0 |       |       |          |
    |* 33 |                     TABLE ACCESS BY INDEX ROWID   | STOCK_ALLOCATION          |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    PLAN_TABLE_OUTPUT
    |* 34 |                      INDEX UNIQUE SCAN            | STOCK_ALLOCATION1         |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |* 35 |                    TABLE ACCESS BY INDEX ROWID    | NB_TMS_INBOUND            |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |* 36 |                     INDEX RANGE SCAN              | NB_TMS_INBOUND_PK         |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |  37 |                   TABLE ACCESS BY INDEX ROWID     | ROUTE_DEST                |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |* 38 |                    INDEX RANGE SCAN               | ROUTE_DEST1               |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |* 39 |                  TABLE ACCESS BY INDEX ROWID      | NB_LANE_SELECTION         |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |* 40 |                   INDEX UNIQUE SCAN               | NB_LANE_SELECTION_PK      |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |  41 |                 TABLE ACCESS BY INDEX ROWID       | ZONE                      |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |* 42 |                  INDEX UNIQUE SCAN                | ZONE1                     |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |* 43 |                TABLE ACCESS BY INDEX ROWID        | LOC_TYPE                  |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |* 44 |                 INDEX UNIQUE SCAN                 | LOC_TYPE1                 |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |* 45 |               INDEX UNIQUE SCAN                   | ITEM_MASTER1              |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |  46 |              TABLE ACCESS BY INDEX ROWID          | ITEM_MASTER               |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
    |  47 |         HASH GROUP BY                             |                           |      1 |      1 |     43 |00:01:51.09 |    1252K|   759K|   759K| 1336K (0)|
    |  48 |          NESTED LOOPS                             |                           |      1 |        |   1963 |00:13:34.35 |    1252K|       |       |          |
    |  49 |           NESTED LOOPS                            |                           |      1 |      1 |   1963 |00:13:34.33 |    1250K|       |       |          |
    |  50 |            NESTED LOOPS                           |                           |      1 |      1 |   1963 |00:13:34.31 |    1250K|       |       |          |
    |  51 |             NESTED LOOPS                          |                           |      1 |      1 |     37M|00:02:03.09 |     822K|       |       |          |
    |  52 |              MERGE JOIN CARTESIAN                 |                           |      1 |      1 |  41685 |00:00:00.20 |    9793 |       |       |          |
    |  53 |               NESTED LOOPS                        |                           |      1 |        |   1985 |00:00:00.13 |    9790 |       |       |          |
    |  54 |                NESTED LOOPS                       |                           |      1 |      1 |   1985 |00:00:00.10 |    7060 |       |       |          |
    |  55 |                 NESTED LOOPS                      |                           |      1 |     14 |   1985 |00:00:00.08 |    5047 |       |       |          |
    |  56 |                  NESTED LOOPS                     |                           |      1 |     14 |   1985 |00:00:00.03 |    1152 |       |       |          |
    |* 57 |                   HASH JOIN                       |                           |      1 |      1 |     36 |00:00:00.01 |      81 |   774K|   774K|  760K (0)|
    |* 58 |                    HASH JOIN                      |                           |      1 |      7 |     36 |00:00:00.01 |      67 |   779K|   779K|  391K (0)|
    |* 59 |                     HASH JOIN                     |                           |      1 |     36 |     36 |00:00:00.01 |      51 |   835K|   835K|  654K (0)|
    |* 60 |                      TABLE ACCESS BY INDEX ROWID  | CONTAINER                 |      1 |     36 |     36 |00:00:00.01 |      21 |       |       |          |
    |* 61 |                       INDEX SKIP SCAN             | CONTAINER_CARR_SERV_ROUTE |      1 |     28 |     36 |00:00:00.01 |      12 |       |       |          |
    |* 62 |                      TABLE ACCESS FULL            | NB_TMS_INBOUND            |      1 |    144 |    144 |00:00:00.01 |      30 |       |       |          |
    |* 63 |                     TABLE ACCESS FULL             | NB_LANE_SELECTION         |      1 |     64 |     64 |00:00:00.01 |      16 |       |       |          |
    |* 64 |                    TABLE ACCESS FULL              | ROUTE_DEST                |      1 |   2003 |   2149 |00:00:00.01 |      14 |       |       |          |
    |  65 |                   TABLE ACCESS BY INDEX ROWID     | CONTAINER_ITEM            |     36 |     38 |   1985 |00:00:00.02 |    1071 |       |       |          |
    |* 66 |                    INDEX RANGE SCAN               | CONTAINER_ITEM1           |     36 |     38 |   1985 |00:00:00.01 |      94 |       |       |          |
    |  67 |                  TABLE ACCESS BY INDEX ROWID      | ITEM_MASTER               |   1985 |      1 |   1985 |00:00:00.04 |    3895 |       |       |          |
    |* 68 |                   INDEX UNIQUE SCAN               | ITEM_MASTER1              |   1985 |      1 |   1985 |00:00:00.02 |    1910 |       |       |          |
    |* 69 |                 INDEX UNIQUE SCAN                 | STOCK_ALLOCATION1         |   1985 |      1 |   1985 |00:00:00.02 |    2013 |       |       |          |
    |* 70 |                TABLE ACCESS BY INDEX ROWID        | STOCK_ALLOCATION          |   1985 |      1 |   1985 |00:00:00.02 |    2730 |       |       |          |
    |  71 |               BUFFER SORT                         |                           |   1985 |     21 |  41685 |00:00:00.04 |       3 |  2048 |  2048 | 2048  (0)|
    |  72 |                TABLE ACCESS BY INDEX ROWID        | ZONE                      |      1 |     21 |     21 |00:00:00.01 |       3 |       |       |          |
    |* 73 |                 INDEX RANGE SCAN                  | ZONE_ZG_IDX               |      1 |     21 |     21 |00:00:00.01 |       1 |       |       |          |
    |  74 |              TABLE ACCESS BY INDEX ROWID          | LOCATION                  |  41685 |    382 |     37M|00:01:40.75 |     812K|       |       |          |
    |* 75 |               INDEX RANGE SCAN                    | LOCATION_ZONE             |  41685 |   1053 |     37M|00:00:30.18 |     256K|       |       |          |
    |* 76 |             VIEW PUSHED PREDICATE                 |                           |     37M|      1 |   1963 |00:10:49.31 |     428K|       |       |          |
    |* 77 |              FILTER                               |                           |     37M|        |     37M|00:09:39.35 |     428K|       |       |          |
    |  78 |               SORT AGGREGATE                      |                           |     37M|      1 |     37M|00:08:18.42 |     428K|       |       |          |
    |* 79 |                FILTER                             |                           |     37M|        |     37M|00:05:23.60 |     428K|       |       |          |
    |  80 |                 TABLE ACCESS BY INDEX ROWID       | PICK_FROM_LOC             |     37M|      1 |     37M|00:03:59.31 |     428K|       |       |          |
    |* 81 |                  INDEX RANGE SCAN                 | PICK_FROM_LOC_ITEM        |     37M|      1 |     37M|00:02:16.12 |     272K|       |       |          |
    |* 82 |            INDEX UNIQUE SCAN                      | LOC_TYPE1                 |   1963 |      1 |   1963 |00:00:00.01 |       4 |       |       |          |
    |* 83 |           TABLE ACCESS BY INDEX ROWID             | LOC_TYPE                  |   1963 |      1 |   1963 |00:00:00.01 |    1963 |       |       |          |
    |* 84 |       VIEW PUSHED PREDICATE                       |                           |     43 |      1 |     43 |00:00:00.01 |     236 |       |       |          |
    |* 85 |        WINDOW SORT PUSHED RANK                    |                           |     43 |      1 |     86 |00:00:00.01 |     236 |  2048 |  2048 | 2048  (0)|
    |* 86 |         TABLE ACCESS BY INDEX ROWID               | CONTAINER_HISTORY         |     43 |      1 |    160 |00:00:00.01 |     236 |       |       |          |
    |* 87 |          INDEX RANGE SCAN                         | CHST_IDX                  |     43 |      2 |    246 |00:00:00.01 |      90 |       |       |          |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       2 - access("U"."FACILITY_ID"='E1' AND "U"."USER_ID"=:B1)
      12 - filter(("L"."LOCATION_ID"=MAX("PL"."LOCATION_ID") AND "PD"."PICK_FROM_CONTAINER_ID"=MAX("PL"."LOCATION_ID")))
      25 - filter((INTERNAL_FUNCTION("C"."CONTAINER_STATUS") AND "C"."DEST_ID" IS NOT NULL))
      26 - access("C"."FACILITY_ID"='E1' AND "C"."ROUTE"='556')
           filter("C"."ROUTE"='556')
      27 - filter("C"."CONTAINER_ID"="PD"."PICK_TO_CONTAINER_ID")
      28 - access("PD"."FACILITY_ID"='E1')
      30 - access("PL"."FACILITY_ID"='E1' AND "PL"."ITEM_ID"="PD"."ITEM_ID")
      32 - access("L"."FACILITY_ID"='E1' AND "PD"."ZONE"="L"."ZONE")
      33 - filter(("SA"."ORDER_DETAIL_UDA1"='2012-10-26' AND "SA"."SA_ROUTE" IS NOT NULL))
      34 - access("SA"."FACILITY_ID"='E1' AND "SA"."DISTRO_NBR"="PD"."DISTRO_NBR" AND "SA"."DEST_ID"="C"."DEST_ID" AND "SA"."ITEM_ID"="PD"."ITEM_ID")
      35 - filter(("C"."ROUTE"="A"."ROUTE" AND "SA"."SA_ROUTE"="A"."ROUTE"))
      36 - access("A"."FACILITY_ID"='E1' AND "C"."DEST_ID"="A"."DEST_ID")
           filter((TO_CHAR(INTERNAL_FUNCTION("A"."BUSINESS_DATE"),'YYYY-MM-DD')='2012-10-26' AND
                  "SA"."ORDER_DETAIL_UDA1"=TO_CHAR(INTERNAL_FUNCTION("A"."BUSINESS_DATE"),'YYYY-MM-DD')))
      38 - access("RD"."FACILITY_ID"='E1' AND "C"."ROUTE"="RD"."ROUTE" AND "C"."DEST_ID"="RD"."DEST_ID")
      39 - filter("RD"."SHIP_DATE"=TRUNC(INTERNAL_FUNCTION("LS"."LOAD_START")))
      40 - access("LS"."FACILITY_ID"='E1' AND "LS"."BUSINESS_DATE"="A"."BUSINESS_DATE" AND "LS"."ROUTE"="A"."ROUTE")
      42 - access("Z"."FACILITY_ID"='E1' AND "L"."ZONE"="Z"."ZONE")
      43 - filter(("C"."LOCATION_ID" IS NULL OR "LT"."DOOR_LOCATION_FLAG"='N'))
      44 - access("LT"."FACILITY_ID"='E1' AND "L"."LOCATION_TYPE"="LT"."LOCATION_TYPE")
      45 - access("I"."FACILITY_ID"='E1' AND "PL"."ITEM_ID"="I"."ITEM_ID")
      57 - access("C"."FACILITY_ID"="RD"."FACILITY_ID" AND "C"."ROUTE"="RD"."ROUTE" AND "C"."DEST_ID"="RD"."DEST_ID" AND
                  "RD"."SHIP_DATE"=TRUNC(INTERNAL_FUNCTION("LS"."LOAD_START")))
      58 - access("LS"."FACILITY_ID"="A"."FACILITY_ID" AND "LS"."ROUTE"="A"."ROUTE" AND "LS"."BUSINESS_DATE"="A"."BUSINESS_DATE")
      59 - access("C"."DEST_ID"="A"."DEST_ID" AND "C"."ROUTE"="A"."ROUTE")
      60 - filter(("C"."USER_ID" IS NOT NULL AND INTERNAL_FUNCTION("C"."CONTAINER_STATUS") AND "C"."DEST_ID" IS NOT NULL))
      61 - access("C"."FACILITY_ID"='E1' AND "C"."ROUTE"='556')
           filter("C"."ROUTE"='556')
      62 - filter(("A"."BUSINESS_DATE"=TO_DATE(' 2012-10-26 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "A"."FACILITY_ID"='E1'))
      63 - filter(("LS"."BUSINESS_DATE"=TO_DATE(' 2012-10-26 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "LS"."FACILITY_ID"='E1'))
      64 - filter("RD"."FACILITY_ID"='E1')
      66 - access("CI"."FACILITY_ID"='E1' AND "CI"."CONTAINER_ID"="C"."CONTAINER_ID")
      68 - access("I"."FACILITY_ID"='E1' AND "CI"."ITEM_ID"="I"."ITEM_ID")
      69 - access("SA"."FACILITY_ID"='E1' AND "SA"."DISTRO_NBR"="CI"."DISTRO_NBR" AND "SA"."DEST_ID"="A"."DEST_ID" AND "SA"."ITEM_ID"="CI"."ITEM_ID")
      70 - filter(("SA"."ORDER_DETAIL_UDA1"='2012-10-26' AND "SA"."SA_ROUTE" IS NOT NULL AND "SA"."SA_ROUTE"="A"."ROUTE"))
      73 - access("Z"."FACILITY_ID"='E1')
      75 - access("L"."FACILITY_ID"='E1' AND "L"."ZONE"="Z"."ZONE")
      76 - filter(("L"."LOCATION_ID"="P"."LOCATION_ID" AND "C"."PICK_TYPE"=DECODE(TO_CHAR(NVL("P"."CASEPACK",0)),'0','U','CF')))
      77 - filter(COUNT(*)>0)
      79 - filter(('E1'="CI"."FACILITY_ID" AND 'E1'="L"."FACILITY_ID"))
      81 - access("PL"."FACILITY_ID"='E1' AND "PL"."ITEM_ID"="CI"."ITEM_ID")
      82 - access("LT"."FACILITY_ID"='E1' AND "L"."LOCATION_TYPE"="LT"."LOCATION_TYPE")
      83 - filter(("C"."LOCATION_ID" IS NULL OR "LT"."DOOR_LOCATION_FLAG"='N'))
      84 - filter("LAST_USER"=1)
      85 - filter(ROW_NUMBER() OVER ( PARTITION BY "CH"."FACILITY_ID","CH"."CONTAINER_ID" ORDER BY INTERNAL_FUNCTION("CH"."ACTION_TS") DESC )<=1)
      86 - filter((INTERNAL_FUNCTION("CH"."CONTAINER_STATUS") AND "CH"."USER_ID"<>'WMS_OWNER'))
      87 - access("CH"."FACILITY_ID"="TAB1"."FACILITY_ID" AND "CH"."CONTAINER_ID"="TAB1"."LC_ID" AND "CH"."TABLE_NAME"='C' AND "CH"."ACTION_TYPE"='M')
    Note
       - cardinality feedback used for this statement
    169 rows selected.

  • SSRS 2008 R2 is extremely slow. The query runs in less than a second in the dataset designer but if you try to view the report it takes over 10 minutes. I have read this is a bug in SSRS 2008 R2. We installed the most recent patches and service packs.

    SSRS 2008 R2 is extremely slow.  The query runs in less than a second in the dataset designer but if you try to view the report it takes over 10 minutes.  I have read this is a bug in SSRS 2008 R2.  We installed the most recent patches and
    service packs.  Nothing we've done so far has fixed it and I see that I'm not the only person with this problem.  However I don't see any answers either.

    Hi Kim Sharp,
    According to your description that when you view the report it is extremely slow in SSRS 2008 R2 but it is very fast when execute the query in dataset designer, right?
    I have tested on my local environment and can‘t reproduce the issue. Obviously, it is the performance issue, rendering performance can be affected by a combination of factors that include hardware, number of concurrent users accessing reports, the amount
    of data in a report, design of the report, and output format. If you have parameters in your report which contains many values in the list, the bad performance as you mentioned is an known issue on 2008 R2 and already have the hotfix:
    http://support.microsoft.com/kb/2276203
    Any issue after applying the update, I recommend you that submit a feedback at https://connect.microsoft.com/SQLServer/ 
    If you don’t have, you can do some action to improve the performance when designing the report. Because how you create and update reports affects how fast the report renders.
    Actually, the Report Server ExecutionLog2  view contains reports performance data. You could make use of below query to see where the report processing time is being spent:
    After you determine whether the delay time is in data retrieval, report processing, or report rendering:
    use ReportServer
    SELECT TOP 10 ReportPath,parameters,
    TimeDataRetrieval + TimeProcessing + TimeRendering as [total time],
    TimeDataRetrieval, TimeProcessing, TimeRendering,
    ByteCount, [RowCount],Source, AdditionalInfo
    FROM ExecutionLog2
    ORDER BY Timestart DESC
    Use below methods to help troubleshoot issues according to the above query result :
    Troubleshooting Reports: Report Performance
    Besides this, you could also follow these articles for more information about this issue:
    Report Server Catalog Best Practices
    Performance, Snapshots, Caching (Reporting Services)
    Similar thread for your reference:
    SSRS slow
    Any problem, please feel free to ask
    Regards
    Vicky Liu

  • Can't find answer to Query Of Queries runtime error

    Not only I browsed this forum but also googled this problem but unfortunnately I have no luck in finding the answer.
    All I did was writing this simple query:
    <cfquery name="test" dbtype="query">
    select SSN,BirthDate from myquery where SSN <> '' OR BirthDate <> ''
    </cfquery>
    and I got this error:
    Query Of Queries runtime error.
    Comparison exception while executing <>.
    Unsupported Type Comparison Exception: The <> operator does not support comparison between the following types:
    Left hand side expression type = "DOUBLE".
    Right hand side expression type = "STRING".
    I tried the following and did not work either, still got the same error.
    <cfquery name="test" dbtype="query"> 
    select SSN,BirthDate from myquery
    where SSN <> <cfqueryparam cfsqltype="CF_SQL_VARCHAR" value=""/>  
    OR BirthDate <> <cfqueryparam cfsqltype="CF_SQL_VARCHAR" value=""/></cfquery>
    Has someone ever encountered the same problem and know how to solve it?

    HELP ! ! !  Going into testing soon. I need this to work to get correct report results ! ! ! !
    My issue seems similar to the one under discussion and the reply from lawhite01 caught my eye. Can you roll my issue into this discussion?
    This is a 2 parter. The second part is the QoQ part, but the 1st part has a line in the query that is similar to the QoQ one and it uses the same data. Part 1 also throws an error.
    PART # 1.
    I'm trying to use a query table created through QueryNew and then query it.
    I need multiple columns in the query table I create:
    <cfscript>
            tot_AllCurrentDraftListing = QueryNew("AnnounceNum, JP_PDLoc, JP_JS_Title, JP_JS, JP_KW_1, JP_JobTitle, JP_Open, JP_Close, JP_CloseType, JP_CloseName, JP_PosNeed, JP_DirectHire, JP_Desc, JP_Draft, JP_Archived, JP_State, JP_AreaName, JP_AreaID, JP_AreaAlias, JP_Fac_SU, JP_Fac_Facility, JP_FAC_ID, JP_Grade1, JP_sal_low1, JP_sal_high1, JP_Grade2, JP_sal_low2, JP_sal_high2, JP_Grade3, JP_sal_low3, JP_sal_high3, JP_Grade4, JP_sal_low4, JP_sal_high4, JP_Grade5, JP_sal_low5, JP_sal_high5, JP_Posted, JP_TypeHire, JP_HRemail");
        </cfscript>
    Then I populate all the cells of the query table.
    Then I set up to use the created query table.
    I do this first:
        <cfquery name="qAltPostID" datasource="#at_datasource#">
             SELECT AltPoster, fk_Job_AnnounceNum
             from JOB_JPContacts
             Where AltJPContactType = 'AltPosterID'
             and AltPoster = '#session.IHSUID#'
             </cfquery>
    Then, in my first query using the created query, I expect to need to choose from multiple values, so I'm using this line in the query (this is NOT a QoQ query):
                and AnnounceNum IN (<cfqueryparam cfsqltype="CF_SQL_varchar" value="#ValueList(qAltPostID.fk_Job_AnnounceNum)#">)
    I've also tried:
                   and AnnounceNum IN (#ValueList(qAltPostID.fk_Job_AnnounceNum)#)   
    and:
                   and JOB_AnnounceNum IN
                    SELECT fk_Job_AnnounceNum
                    from JOB_JPContacts
                    Where AltJPContactType = 'AltPosterID'
                    and AltPoster = '#session.IHSUID#'
    ERROR is: one record should return. I get 0.
    PART # 2: Here's the QoQ part.
    I get the error:
    Query Of Queries runtime error.
    Comparison exception while executing IN.
    Unsupported Type Comparison Exception: The IN operator does not support comparison between the following types:
    Left hand side expression type = "LONG".
    Right hand side expression type = "STRING".
    A tutorial I found gave an example using only one column for this part of the fix:
         tot_AllCurrentDraftListing = QueryNew("AnnounceNum", "CF_SQL_VARCHAR")
    How would I set up the query with the datatype when I'm using multiple columns:
    <cfscript>
            tot_AllCurrentDraftListing = QueryNew("AnnounceNum, JP_PDLoc, JP_JS_Title, JP_JS, JP_KW_1, JP_JobTitle, JP_Open, JP_Close, JP_CloseType, JP_CloseName, JP_PosNeed, JP_DirectHire, JP_Desc, JP_Draft, JP_Archived, JP_State, JP_AreaName, JP_AreaID, JP_AreaAlias, JP_Fac_SU, JP_Fac_Facility, JP_FAC_ID, JP_Grade1, JP_sal_low1, JP_sal_high1, JP_Grade2, JP_sal_low2, JP_sal_high2, JP_Grade3, JP_sal_low3, JP_sal_high3, JP_Grade4, JP_sal_low4, JP_sal_high4, JP_Grade5, JP_sal_low5, JP_sal_high5, JP_Posted, JP_TypeHire, JP_HRemail");
        </cfscript>
    I used this code after all the cells contained values and before running my QoQ query:
            <cfloop index="intID" from="1" to="#tot_AllCurrentDraftListing.recordcount#" step="1">
                <cfset tot_AllCurrentDraftListing["AnnounceNum"] [intID] = JavaCast("string", intID) />
            </cfloop>
              Is that correct?
    Thanks.
    Whoever can help me with this should be awarded extra points ! ! ! !

  • Query of Queries problem

    Over the past several weeks we've been experiencing periodic
    hangs of the ColdFusion service. We finally invested in SeeFusion
    and found the problem, but aren't sure how to fix it
    The code that hangs is a query of queries block. Basically we
    are getting a result set from verity (~1000 rows), then getting a
    result set from SQL server (~3000 rows), and joining the two with
    the query of query statement. Everything will run fine for a few
    hours, then that block of code will bog down. When I dumped the
    threads during the error, everything gets hung like so:
    "jrpp-255" runnable
    at
    coldfusion.sql.imq.rttExpr.guesstimateJavaType(rttExpr.java:439)
    at
    coldfusion.sql.imq.rttExpr.guesstimateJavaType(rttExpr.java:371)
    at
    coldfusion.sql.imq.imqTable.guessColumnType(imqTable.java:443)
    at
    coldfusion.sql.QueryTableMetaData.InferMetaDataTypes(QueryTableMetaData.java:350)
    at coldfusion.sql.imq.TableList.validate(TableList.java:166)
    at
    coldfusion.sql.imq.rttSelectExprSpec.validate(rttSelectExprSpec.java:498)
    at
    coldfusion.sql.imq.rttSelectStmt.validate(rttSelectStmt.java:84)
    at
    coldfusion.sql.imq.jdbcStatement.fetchResult(jdbcStatement.java:538)
    at
    coldfusion.sql.imq.jdbcStatement.execute(jdbcStatement.java:131)
    at coldfusion.sql.Executive.executeQuery(Executive.java:775)
    at coldfusion.sql.SqlImpl.execute(SqlImpl.java:240)
    at
    coldfusion.tagext.sql.QueryTag.doEndTag(QueryTag.java:500)
    at
    cfauctionManagement2ecfc978963305$funcJOINAUCTIONSTOVERITY.runFunction(D:\inetpub\wwwroot \CustomTags\mysite\component\auctionManagement.cfc:137)
    at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:344)
    at
    coldfusion.filter.SilentFilter.invoke(SilentFilter.java:47)
    at
    coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:290)
    at
    coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:254)
    at
    coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:56)
    at
    coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:207)
    at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:366)
    at
    coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:198)
    at
    coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:157)
    at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:1594)
    at
    coldfusion.tagext.lang.InvokeTag.doEndTag(InvokeTag.java:341)
    at
    cfact_search_auctions2ecfm1040202400._factor47(D:\inetpub\wwwroot\CustomTags\mysite\actio n\act_search_auctions.cfm:849)
    at
    cfact_search_auctions2ecfm1040202400.runPage(D:\inetpub\wwwroot\CustomTags\mysite\action\ act_search_auctions.cfm:1)
    at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:152)
    at
    coldfusion.filter.CFVariablesScopeFilter.invoke(CFVariablesScopeFilter.java:63)
    at
    coldfusion.tagext.lang.ModuleTag.doStartTag(ModuleTag.java:255)
    at
    coldfusion.runtime.CfJspPage._emptyTcfTag(CfJspPage.java:1925)
    at
    cfindex2ecfm1952396859.runPage(D:\inetpub\wwwroot\mysite\cfml\auctions\index.cfm:18)
    at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:152)
    at
    coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:349)
    at
    coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:1915)
    at
    cflas2dvegas2dtimeshares2ecfm1477369516.runPage(D:\inetpub\wwwroot\mysite\cfml\las-vegas- timeshares.cfm:1)
    at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:152)
    at
    coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:349)
    at
    coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65)
    ...etc
    I believe this means CF is trying to "guesstimate" the java
    type of each column in the result set. We tried to work around that
    by CASTing each column as a varchar, but we still have the same
    issue.
    If anyone has an idea what the problem could be, we'd really
    appreciate any help. Also, if anyone can suggest a way to merge the
    two result sets without using SQL, that would be great too. I've
    already tried nested loops to manually build the final result set,
    but that was taking up to 5 seconds to run.
    Environment:
    CFMX 7.0.2
    Win2K
    SQL Server 2K

    > We need more information than that to display a record,
    so we select
    > everything out of the database (which is fairly quick),
    then JOIN that to the
    > verity results (WHERE auctionID = KEY).
    Right. And what do you need THOUSANDS of matches for, in one
    hit, here?
    And what do you need ALL those columns for, when dealing with
    all these
    thousands of rows. You've not really answered my question as
    to "what's
    the end result here?" What are you trying to achieve? I don't
    mean what
    you're doing to aggregate the data, but simply *why*? What is
    the
    requirement you have here to be engaging in this enterprise
    in the first
    place? Search screen? Stock control report? What?
    Is there any way of optimising how much processing you're
    doing?
    If - say - you're doing a search results screen, you probably
    don't need
    1000s of results: you probably need 20. So just ask the DB
    for 20: WHERE
    id IN (#list of 20 IDs from Verity search results#)
    If the user goes "NEXT >>", then grab the next 20
    (cache the Verity query
    somehow, rather than re-query it).
    Obviously there's some heavy-lifting processing that might
    need to process
    the whole lot. Can this not be done in a sliding window of
    results? Or
    could you not pass the list of IDs from the Verity resultset
    into the DB
    somehow, and do the filtering on the DB engine, rather than
    with CF (which
    is not very good at bulk data processing, as you're seeing.
    It's not what
    it's designed for).
    I find QoQ to be very flaky for all ut the most basic
    operations. For
    basic stuff it's fine. It does not surprise me that it seems
    to leak
    memory (or whatever it's doing) and eventually give up the
    ghost. This
    does not help you, I realise, but as a suggested practice:
    don't expect too
    much out of QoQ. Try some other method instead.
    Adam

  • Query of queries disallows SQL right() function

    We're attempting to do a query of queries using the SQL
    right() function like this:
    select *
    from getresults
    where right([key],charindex('\',reverse([key]),1)-1) not in
    (#quotedvaluelist(getexcluded.file_name)#)
    We've even replaced that where clause with a much more simple
    where right([key])='m'
    just to make sure that it wasn't the nesting functions that
    were causing the problem.
    In either case, we get the error:
    Query of Queries syntax error.
    Encountered "right" at line 0, column 0. Incorrect
    conditional expression,
    Expected one of [like|null|between|in|comparison] condition,
    What SQL functions are disallowed from query of queries?
    Thanks,
    Kris

    Nasty stuff huh. Just happened to discover myself today that
    Left doesn't work. I'd suspect that Aggregate functions are the
    ONLY ones that will work. It would have been nice if they'd at
    least allowed CF vs DB functions in their own "database" language.
    BTW, also discovered that Count() returns Null rather than 0
    when there aren't any per your WHERE clause.

  • Multiple where conditions in one parameter

    Hi,
    Is it possible to have more than one where condition in one parameter?
    For example, my WHERE_CLAUSE parameter holds the value "where id='12345' and name='john smith'"
    when i run the report, I get a [052008_033528064][][EXCEPTION] java.lang.NullPointerException at oracle.apps.xdo.dataengine.DataTemplateParser.getObjectVlaue(Unknown
    Source) Thus the sql statement did not execute.
    But if I change the WHERE_CLAUSE to "where id='12345'" or "where name='john smith'" it works fine.
    My observation is that if there are two where conditions, BI publisher wont allow it. Am I correct?
    But the report has to be open to the possibility of having more than one where clause condition. Is there a work around for this?
    Thanks,
    Shanak

    nope your mistaken. bip will handle multiple joins.
    1. make sure the where_clause parameter is defined in your package.
    2. make sure use & syntax
    3. make sure your sql is not malformed. This is probably the issue.
    4. also, read my article on bind variables. the practice of coding the actual value in a where clause should be avoided at all costs. Causes the query execution plan to be reparsed each time that particular query is executed.
    http://bipublisher.blogspot.com/2007/10/bi-publisher-what-lexical-understanding.html
    Ike Wiggins
    http://bipublisher.blogspot.com/

  • Query execution is faster - as SYS user vs. application user in 11.1.07

    In +11.1.0.7+ database, we have noticed execution of an application process as SYS user is faster than the application user. To quantify this execution time was 2 hours as application user and same process when executed as SYS user completed in 1 hour.
    We ran tracing for this process and tkprof output showed follwoing:
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS:
    _call          count      cpu       elapsed disk query current rows_
    Execute 3705586 2440.49 *4294.54* 293602 21835223 23300886 3801288 <<< ==== SYS
    Execute 3703285 6356.69 *8576.50* 303175 21785419 23378086 3801291 <<< ==== Application user
    We have SR open with Oracle, but thought if some one knows about this issue would be great.
    Edited by: dhyani on Aug 17, 2010 3:16 PM

    What about the "Predicate Information" section of the execution plans - were those exactly the same? Did you use AUTOTRACE, EXPLAIN PLAN FOR, or the method that I showed to retrieve the execution plans? Where the SQL_ID and CHILD_NUMBERS displayed exactly the same? Is the STATISTIC_LEVEL set to TYPICAL for both sessions? You can check the setting in SQL*Plus like this:
    SQL> SHOW PARAMETER STATISTICS_LEVEL
    NAME                                 TYPE        VALUE
    statistics_level                     string      typicalAs a demonstration, I will change the value at the session level and then change the setting back:
    SQL> ALTER SESSION SET STATISTICS_LEVEL='ALL';
    SQL> SHOW PARAMETER STATISTICS_LEVEL
    NAME                                 TYPE        VALUE
    statistics_level                     string      ALL
    SQL> ALTER SESSION SET STATISTICS_LEVEL='TYPICAL';If the above does not show a difference, you will need to capture a 10046 trace at either level 8 or level 12 for both sessions and compare the wait events and the STAT lines in the 10046 trace to see where the additional time is being spent. Reference these two blog articles for the 10046 trace:
    http://hoopercharles.wordpress.com/2009/12/01/10046-extended-sql-trace-interpretation/
    http://hoopercharles.wordpress.com/2010/01/26/10046-extended-sql-trace-interpretation-2/
    Keep in mind that the goal is to not change anything until we understand the problem better. Maybe, just maybe, someone created a table (or view) or two in the SYS schema (or used a table/view name that matched a SYS owned object), in a normal user's schema, or there are synonyms pointing to different tables. So, it probably would be a good idea to verify that the results are exactly the same when the SYS user executes the SQL statement and a normal user executes the SQL statement.
    Charles Hooper
    Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
    http://hoopercharles.wordpress.com/
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Why would oracle 9i drivers faster than oracle 10g drivers against a 10g?

    I'm skeptical of the claim but we have a system at work and tests have been done that apparently is showing that the older oracle 9i thin jdbc driver is performing a fetch faster than the 10g driver. This for a query that is currently doing a full table scan.
    Is there a default setting in 10g vs 9i that can explain why the perceived query performance is faster with the older thin driver?

    steffi2 wrote:
    What was observed was that when they started using the old Oracle 8.1.7 8i client jar against this 10g data the actual execution plan changed dramatically to use indexes where was previously it was not doing so and it was doing a full tablescan.
    Why would the introduction of the old 8i jar have this affect?Maybe the test is flawed. For example one test was run with the network was loaded while the other wasn't. Or different connection parameters.
    That said I believe somewhere the claim has been made that Oracle drivers changed from one API to another somewhat recently. Thus that could be the source.
    Or maybe something to do with hints.

  • CTAS is over x10 faster than it's select statement, why?

    Hi gurus -
    Oracle 11gR2
    Exadata
    CREATE TABLE AS SELECT .......................... FROM................. runs over 10 times faster than just the SELECT stmt from the CTAS.
    Why and how CTAS is faster than it's SELECT stmt?
    Thanks,
    Prakash

    No it's not guessing game. Here is my query with elapsed time,
    SELECT CURRENT_CONTRACT,
    JOB_TITLE,
    EXPENDITURE_ITEM_DATE_WEEK_END,
    HIRING_MANAGER,
    RATE_TYPE,
    OT_PAY_RATE,
    DT_PAY_RATE,
    SUM (CONT_OT_SPEND_AMOUNT_ADJ) AS CONT_OT_SPEND_AMOUNT_ADJ,
    SUM (CONT_DT_SPEND_AMOUNT_ADJ) AS CONT_DT_SPEND_AMOUNT_ADJ,
    SUM (CONT_DT_HOURS_SPEND) AS CONT_DT_HOURS_SPEND,
    SUM (CONT_OT_HOURS_SPEND) AS CONT_OT_HOURS_SPEND
    FROM CONTRACTOR_TIME V -- Contractor view
    WHERE ORG IN (23245,33456)
    GROUP BY
    CURRENT_CONTRACT,
    JOB_TITLE,
    EXPENDITURE_ITEM_DATE_WEEK_END,
    HIRING_MANAGER,
    RATE_TYPE,
    OT_PAY_RATE,
    DT_PAY_RATE;
    --Elapsed : 30 minutes
    CREATE TABLE rslt AS
    SELECT CURRENT_CONTRACT,
    JOB_TITLE,
    EXPENDITURE_ITEM_DATE_WEEK_END,
    HIRING_MANAGER,
    RATE_TYPE,
    OT_PAY_RATE,
    DT_PAY_RATE,
    SUM (CONT_OT_SPEND_AMOUNT_ADJ) AS CONT_OT_SPEND_AMOUNT_ADJ,
    SUM (CONT_DT_SPEND_AMOUNT_ADJ) AS CONT_DT_SPEND_AMOUNT_ADJ,
    SUM (CONT_DT_HOURS_SPEND) AS CONT_DT_HOURS_SPEND,
    SUM (CONT_OT_HOURS_SPEND) AS CONT_OT_HOURS_SPEND
    FROM CONTRACTOR_TIME V -- Contractor view
    WHERE ORG IN (23245,33456)
    GROUP BY
    CURRENT_CONTRACT,
    JOB_TITLE,
    EXPENDITURE_ITEM_DATE_WEEK_END,
    HIRING_MANAGER,
    RATE_TYPE,
    OT_PAY_RATE,
    DT_PAY_RATE;
    --Elapsed: 3 mins                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • Which query will run faster

    Hi,
    I have following two tables:
    SQL> desc customers
    Name Null? Type
    ID NOT NULL NUMBER
    NAME VARCHAR2(20)
    SQL> desc orders
    Name Null? Type
    CUST_ID NUMBER
    ARTICLE_NR VARCHAR2(20)
    PRICE NUMBER(5,2)
    I want to find each customer's order with the highest price along with its respective article number and the customer's name.
    Please let me know, which of the following query will work fast and why:
    SELECT c.NAME, o.article_nr, o.price
    FROM customers c,
    (SELECT cust_id, article_nr, price,
    ROW_NUMBER () OVER (PARTITION BY cust_id ORDER BY price DESC)
    r
    FROM orders) o
    WHERE o.r = 1 AND c.ID = o.cust_id
    SELECT NAME, article_nr, price
    FROM orders o, customers c
    WHERE c.ID = o.cust_id
    AND (o.cust_id, price) IN (SELECT cust_id, MAX (price)
    FROM orders
    GROUP BY cust_id);
    Thanks.

    Your second version is selecting twice from the same table (orders). The first version needs only one read over this table. So there is a good chance that the first version is faster than the second.
    However there is always a possibility depending on indexes etc. that it is otherwise.

  • Query slow down when added a where clause

    I have a procedure that has performance issue, so I copy some of the query and run in the sql plus and try to spot which join cause the problem, but I get a result which I can figuer out why. I have a query which like below:
    Select Count(a.ID) From TableA a
    -- INNER JOIN other tables
    WHERE a.TypeID = 2;
    TableA has 140000 records, when the where clause is not added, the count return quite quick, but if I add the where clause, then the query slow down and seems never return so I have to kill my SQL Plus session. TableA has index on TypeID and TypeID is a number type. When TablA has 3000 records, the procedure return very quick, but it slow down and hang there when the TableA contains 140000 records. Any idea why this will slow down the query?
    Also, the TypeID is a foreign key to another table (TableAType), so the query above can written as :
    Select Count(a.ID) From TableA a
    -- INNER JOIN other tables
    INNER JOIN TableAType atype ON a.TypeID = atype.ID
    WHERE atype.Name = 'typename';
    TableAType table is a small table only contains less than 100 records, in this case, would the second query be more efficient to the first query?
    Any suggestions are welcome, thanks in advance...
    Message was edited by:
    user500168

    TableA now has 230000 records and 28000 of them has the TypeID 2.
    I haven't use the hint yet but thank you for your reply which let me to to run a query to check how many records in TableA has TypeID 2. When I doing this, it seems pretty fast. So I begin with the select count for TableA only and gradually add table to join and seems the query is pretty fast as long as TableA is the fist table to select from.
    Before in my query TableA is the second table to join from, there is another table (which is large as well but not as large as TableA) before TableA. So I think this is why it runs slow before. I am not at work yesterday so the query given in my post is based on my roughly memory and I forget to mention another table is joined before TableA, really sorry about that.
    I think I learn a lesson here, the largest table need to be in the begining of the select statement...
    Thank you very much everyone.

  • Join and Multiple where clauses: which is better??

    There was an argument between a colleague and I. He prefers building his views joining many tables with many where clause while I am cute with my join which is simpler and more understandable for me. So, it started an argument on which is a superior way of joining tables.
    I will actually like to know we is faster and better: using JOINs or using multiple where clauses to retrieve values from multiple tables.?

    Dave:
    "Are we talking about the difference between Oracle Joins and ANSI Joins?
    e.g.
    Select d.dept_name, e.emp_name
    from dept d, emp e
    where d.dept_id = e.dept_id"
    That is not really an "Oracle Join". That syntax works on just about every SQL database I have ever worked with. The (+) syntax for an outer join is Oracle specific, but some other databases use a similar style for outer joins (something like a.c += b.c or a.c *= b.c).
    OP:
    There are things you can do with the ANSI style syntax that either cannot be done, or cannot be done as easily, with Oracle's syntax. Most notably, outer joining one table to more than one other tables, and FULL OUTER joins.
    Having said that, in my experience, both are rather rare occurrences, so I tend to stick to doing the jopins in the WHERE clause because that is what I am used to.
    John

  • Oracle SQL Select query takes long time than expected.

    Hi,
    I am facing a problem in SQL select query statement. There is a long time taken in select query from the Database.
    The query is as follows.
    select /*+rule */ f1.id,f1.fdn,p1.attr_name,p1.attr_value from fdnmappingtable f1,parametertable p1 where p1.id = f1.id and ((f1.object_type ='ne_sub_type.780' )) and ( (f1.id in(select id from fdnmappingtable where fdn like '0=#1#/14=#S0058-3#/17=#S0058-3#/18=#1#/780=#5#%')))order by f1.id asc
    This query is taking more than 4 seconds to get the results in a system where the DB is running for more than 1 month.
    The same query is taking very few milliseconds (50-100ms) in a system where the DB is freshly installed and the data in the tables are same in both the systems.
    Kindly advice what is going wrong??
    Regards,
    Purushotham

    SQL> @/alcatel/omc1/data/query.sql
    2 ;
    9 rows selected.
    Execution Plan
    Plan hash value: 3745571015
    | Id | Operation | Name |
    | 0 | SELECT STATEMENT | |
    | 1 | SORT ORDER BY | |
    | 2 | NESTED LOOPS | |
    | 3 | NESTED LOOPS | |
    | 4 | TABLE ACCESS FULL | PARAMETERTABLE |
    |* 5 | TABLE ACCESS BY INDEX ROWID| FDNMAPPINGTABLE |
    |* 6 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE |
    |* 7 | TABLE ACCESS BY INDEX ROWID | FDNMAPPINGTABLE |
    |* 8 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE |
    Predicate Information (identified by operation id):
    5 - filter("F1"."OBJECT_TYPE"='ne_sub_type.780')
    6 - access("P1"."ID"="F1"."ID")
    7 - filter("FDN" LIKE '0=#1#/14=#S0058-3#/17=#S0058-3#/18=#1#/780=#5#
    8 - access("F1"."ID"="ID")
    Note
    - rule based optimizer used (consider using cbo)
    Statistics
    0 recursive calls
    0 db block gets
    0 consistent gets
    0 physical reads
    0 redo size
    0 bytes sent via SQL*Net to client
    0 bytes received via SQL*Net from client
    0 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    9 rows processed
    SQL>

Maybe you are looking for

  • How can I use my external hard drive on my mac and a windows computer?

    Hello, Can anyone help...I have recently purchased a new external hard drive for my macbook pro, it is a 1TB hard drive. I use it for time machine back ups which only takes up about 250gb of space so obviously I have a lot more to use. I'm at Univers

  • How to report the Bug report system doesn't work?

    After eagerly downloading and trying Flash CS6, one glaring bug hit me. I'd tried to report it, in some detail, but I get a replay from a [email protected] that informs me my feedback cannot, and will not be delivered. Can someone look at that? The "

  • Pages are ordered wrong. How do I fix this?

    I am using Adobe Reader at my community college and one of my philosophy .pdf's that my teacher has assigned us to read has 5 pages that are numbered wrong. The order of the pages specified by the .pdf, pg.10-pg.14, are as follows: 62, 65, 63, 64, 66

  • Dba_policies

    Hi, I 've imported a dump with a procedure with the code: Select object_name from dba_policies; And if i want to compile this procedure i get the error message that table or view not found. But if i make a select of the table the table is there. I've

  • Diff between Integer and Number in Oracle

    Hi, What's the differet between integer and number in Oracle?