Oracle not using correct index

Hi,
I have a fact table (a big table) and a dimension table representing dates.
My query is
select fdat.*, dd.dim_date from fdat_bitmap fdat, dim_dates dd where
fdat.dim_date_id = dd.dim_date_id
and dd.dim_date > TO_DATE('2011-12-20 00:00:00' , 'YYYY-MM-DD HH24:MI:SS');
and the corresponding plan is:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 76M| 9173M| 709K (1)| 02:21:51 |
|* 1 | HASH JOIN | | 76M| 9173M| 709K (1)| 02:21:51 |
|* 2 | INDEX FAST FULL SCAN| UI_DD_DATES_ID | 6951 | 97314 | 8 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL | FDAT_BITMAP | 198M| 20G| 708K (1)| 02:21:39 |
Predicate Information (identified by operation id):
1 - access("FDAT"."DIM_DATE_ID"="DD"."DIM_DATE_ID")
2 - filter("DD"."DIM_DATE">TO_DATE(' 2011-12-20 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'))
17 rows selected
When I change the query to:
select fdat.*, dd.dim_date from fdat_bitmap fdat, dim_dates dd where
fdat.dim_date_id = dd.dim_date_id
and fdat.dim_date_id > 20111220;
Explain plan changes to:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 390K| 46M| 43958 (1)| 00:08:48 |
| 1 | MERGE JOIN | | 390K| 46M| 43958 (1)| 00:08:48 |
| 2 | TABLE ACCESS BY INDEX ROWID | FDAT_BITMAP | 390K| 41M| 43948 (1)| 00:08:48 |
| 3 | BITMAP CONVERSION TO ROWIDS| | | | | |
|* 4 | BITMAP INDEX RANGE SCAN | I_FDATB_DIM_DID | | | | |
|* 5 | SORT JOIN | | 6991 | 97874 | 9 (12)| 00:00:01 |
|* 6 | INDEX FAST FULL SCAN | UI_DD_DATES_ID | 6991 | 97874 | 8 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - access("FDAT"."DIM_DATE_ID">20111220)
filter("FDAT"."DIM_DATE_ID">20111220)
5 - access("FDAT"."DIM_DATE_ID"="DD"."DIM_DATE_ID")
filter("FDAT"."DIM_DATE_ID"="DD"."DIM_DATE_ID")
6 - filter("DD"."DIM_DATE_ID">20111220)
22 rows selected
My question is why the first query not resulting in the plan similar to second one ? How can make it come with plan similar to the second one without changing the query ?
Thanks,
-Rakesh

user12257218 wrote:
My query is
select fdat.*, dd.dim_date from fdat_bitmap fdat, dim_dates dd where
fdat.dim_date_id = dd.dim_date_id
and dd.dim_date > TO_DATE('2011-12-20 00:00:00' , 'YYYY-MM-DD HH24:MI:SS');When I change the query to:
select fdat.*, dd.dim_date from fdat_bitmap fdat, dim_dates dd where
fdat.dim_date_id = dd.dim_date_id
and fdat.dim_date_id > 20111220;My question is why the first query not resulting in the plan similar to second one ? How can make it come with plan similar to the second one without changing the query ?
To a very large extent this is because the two queries are not logically equivalent - unless you have a constraint in place that enforces the rule that:
dd.dim_date_id > 20111220 if, and only if, dd.dim_date > TO_DATE('2011-12-20 00:00:00' , 'YYYY-MM-DD HH24:MI:SS')
A constraint like: (dim_date_id = to_number(to_char(dim_date,'yyyymmdd'))) might help - provided both columns also have NOT NULL declarations (or "is not null" constraints), and provided that that's appropriate for the way your application works.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b>

Similar Messages

  • Why is Oracle not using the index??

    Hi,
    I have a table called 'arc_errors' which has an index on 'member_number' as follows:- Create/Recreate indexes
    create index DWO.DW_ARC_CERRORS_MNO on DWO.DW_ARC_CERRORS (MEMBER_NUMBER);
    But surpisingly, when I execute the following query, it does not use the index.
    SELECT member_number,
    COUNT(*) error_count
    FROM arc_errors a
    WHERE member_number = 68534152 AND
    ( tx_type = 'SDIC' AND
    error_number IN (4, 7, 12, 13, 15, 17, 18, 705) )
    OR
    ( tx_type = 'AUTH' AND
    error_number IN (100, 104, 107, 111, 116) )
    OR
    ( tx_type = 'BHO' AND
    error_number IN (708,710) )
    OR
    ( tx_type = 'XLGN' AND
    ( error_number BETWEEN 102 AND 105 OR
    error_number BETWEEN 107 AND 120 OR
    error_number BETWEEN 300 AND 304 ) )
    OR
    ( tx_type = 'None' AND
    ( error_number IN (20, 112) OR
    error_number BETWEEN 402 AND 421 ) )
    OR
    ( tx_type = 'HYBR' AND
    error_number IN (303, 304) )
    GROUP BY member_number;
    This is what 'explain plan' tell me
    SELECT STATEMENT, GOAL = RULE               237907     502923     15087690     
    SORT GROUP BY               237907     502923     15087690     
    PARTITION RANGE ALL                              
    TABLE ACCESS FULL     DWO     DW_ARC_CERRORS     237209     502923     15087690     
    Can someone tell me why a 'table acess full' is required here?
    Thanks in advance,
    Rajesh

    Sorry, I just found the solution myself. I need to put an extra pair of braces around the set of conditions seperated by OR.

  • Optimizer not using correct execution plan

    Hi ,
    DB  version : 11.2.0.3
    My sql query ran last month 1 hour. But the same sql query today running for four hours. Looks like optimizer is not using correct execution plan. I have used tuning advisor and applied recommended sql profile and query execution is back to normal. I can see statistics are upto date for the tables. Any other factors why the optimizer is not choosing correct execution plan ?
    Thanks.

    What is the correct plan according to you? Multiple factors cause optimizer to chose a different plan. As a rudimentry example - A binary index column having low cardinality than expected, after new data has been inserted. Never ever expect your query to have same execution plan till the entire lifetime, until the underlying data does not change or nobody changes database settings.
    You have to give a lot of information if you are looking for performance tuning. Pls see following thread
    https://forums.oracle.com/message/9362003#9362003

  • SQL Query not using Composite Index

    Hi,
    Please look at the below query:
    SELECT pde.participant_uid
    ,pde.award_code
    ,pde.award_type
    ,SUM(decode(pde.distribution_type
    ,'FORFEITURE'
    ,pde.forfeited_quantity *
    pde.sold_price * cc.rate
    ,pde.distributed_quantity *
    pde.sold_price * cc.rate)) AS gross_Amt_pref_Curr
    FROM part_distribution_exec pde
    ,currency_conversion cc
    ,currency off_curr
    WHERE pde.participant_uid = 4105
    AND off_curr.currency_iso_code =
    pde.offering_currency_iso_code
    AND cc.from_currency_uid = off_curr.currency_uid
    AND cc.to_currency_uid = 1
    AND cc.latest_flag = 'Y'
    GROUP BY pde.participant_uid
    ,pde.award_code
    ,pde.award_type
    In oracle 9i, i"ve executed this above query, it takes 6 seconds and the cost is 616, this is due to non usage of the composite index, Currency_conversion_idx(From_currency_uid, To_currency_uid, Latest_flag). I wonder why this index is not used while executing the above query. So, I've dropped the index and recreated it. Now, the query is using this index. After inserting many rows or say in 1 days time, if the same query is executed, again the query is not using the index. So everyday, the index should be dropped and recreated.
    I don't want this drop and recreation of index daily, I need a permanent solution for this.
    Can anyone tell me, Why this index goes stale after a period of time???? Please take some time and Solve this issue.
    -Sankar

    Hi David,
    This is Sankar here. Thankyou for your reply.
    I've got the plan table output for this problematic query, please go thro' it and help me out why the index CURRENCY_CONVERSION_IDX is used now and why it's not using while executing the query after a day or inserting some records...
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | SELECT STATEMENT | | 26 | 15678 | 147 |
    | 1 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_PAYOUT_SCHEDULE | 1 | 89 | 2 |
    |* 2 | INDEX UNIQUE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 61097 | | 1 |
    | 3 | SORT AGGREGATE | | 1 | 67 | |
    |* 4 | FILTER | | | | |
    |* 5 | INDEX RANGE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 1 | 67 | 2 |
    | 6 | SORT AGGREGATE | | 1 | 94 | |
    |* 7 | FILTER | | | | |
    |* 8 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_PAYOUT_SCHEDULE | 1 | 94 | 3 |
    |* 9 | INDEX RANGE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 1 | | 2 |
    |* 10 | FILTER | | | | |
    |* 11 | HASH JOIN | | 26 | 15678 | 95 |
    |* 12 | HASH JOIN OUTER | | 26 | 11596 | 91 |
    |* 13 | HASH JOIN | | 26 | 10218 | 86 |
    | 14 | VIEW | | 1 | 82 | 4 |
    | 15 | SORT GROUP BY | | 1 | 116 | 4 |
    |* 16 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_LEDGER | 1 | 116 | 2 |
    |* 17 | INDEX RANGE SCAN | PARTICIPANT_UID_IDX | 1 | | 1 |
    |* 18 | HASH JOIN OUTER | | 26 | 8086 | 82 |
    |* 19 | HASH JOIN | | 26 | 6006 | 71 |
    | 20 | NESTED LOOPS | | 36 | 5904 | 66 |
    | 21 | NESTED LOOPS | | 1 | 115 | 65 |
    | 22 | TABLE ACCESS BY INDEX ROWID | CURRENCY_CONVERSION | 18 | 756 | 2 |
    |* 23 | INDEX RANGE SCAN | KLS_IDX_CURRENCY_CONV | 3 | | 1 |
    | 24 | VIEW | | 1 | 73 | 4 |
    | 25 | SORT GROUP BY | | 1 | 71 | 4 |
    | 26 | TABLE ACCESS BY INDEX ROWID| PART_AWARD_VALUE | 1 | 71 | 2 |
    |* 27 | INDEX RANGE SCAN | PAV_PARTICIPANT_UID_IDX | 1 | | 1 |
    | 28 | TABLE ACCESS BY INDEX ROWID | PARTICIPANT_AWARD | 199 | 9751 | 1 |
    |* 29 | INDEX UNIQUE SCAN | PARTICIPANT_AWARD_PK1 | 100 | | |
    |* 30 | INDEX FAST FULL SCAN | PARTICIPANT_AWARD_TYPE_PK1 | 147 | 9849 | 4 |
    | 31 | VIEW | | 1 | 80 | 10 |
    | 32 | SORT GROUP BY | | 1 | 198 | 10 |
    |* 33 | TABLE ACCESS BY INDEX ROWID | CURRENCY_CONVERSION | 1 | 42 | 2 |
    | 34 | NESTED LOOPS | | 1 | 198 | 8 |
    | 35 | NESTED LOOPS | | 2 | 312 | 4 |
    | 36 | TABLE ACCESS BY INDEX ROWID| PART_DISTRIBUTION_EXEC | 2 | 276 | 2 |
    |* 37 | INDEX RANGE SCAN | IND_PARTICIPANT_UID | 1 | | 1 |
    | 38 | TABLE ACCESS BY INDEX ROWID| CURRENCY | 1 | 18 | 1 |
    |* 39 | INDEX UNIQUE SCAN | CURRENCY_AK | 1 | | |
    |* 40 | INDEX RANGE SCAN | CURRENCY_CONVERSION_AK | 2 | | 1 |
    | 41 | VIEW | | 1 | 53 | 4 |
    | 42 | SORT GROUP BY | | 1 | 62 | 4 |
    |* 43 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_VESTING | 1 | 62 | 2 |
    |* 44 | INDEX RANGE SCAN | PAVES_PARTICIPANT_UID_IDX | 1 | | 1 |
    | 45 | TABLE ACCESS FULL | AWARD | 1062 | 162K| 3 |
    | 46 | TABLE ACCESS BY INDEX ROWID | CURRENCY | 1 | 18 | 2 |
    |* 47 | INDEX UNIQUE SCAN | CURRENCY_AK | 102 | | 1 |
    Predicate Information (identified by operation id):
    2 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2
    "PAPS"."INSTALLMENT_NUM"=1)
    4 - filter(4105=:B1)
    5 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2)
    7 - filter(4105=:B1)
    8 - filter("PAPS"."STATUS"='OPEN')
    9 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2)
    10 - filter("CC_A_P_CURR"."FROM_CURRENCY_UID"= (SELECT /*+ */ "CURRENCY"."CURRENCY_UID" FROM
    "EWAPDBO"."CURRENCY" "CURRENCY" WHERE "CURRENCY"."CURRENCY_ISO_CODE"=:B1))
    11 - access("SYS_ALIAS_7"."AWARD_CODE"="A"."AWARD_CODE")
    12 - access("SYS_ALIAS_7"."AWARD_CODE"="PVS"."AWARD_CODE"(+))
    13 - access("SYS_ALIAS_8"."AWARD_CODE"="PALS"."AWARD_CODE" AND
    "SYS_ALIAS_8"."AWARD_TYPE"="PALS"."AWARD_TYPE")
    16 - filter(TRUNC("PAL1"."LEDGER_ENTRY_DATE")<=TRUNC(SYSDATE@!) AND "PAL1"."ALLOC_TYPE"='IPU')
    17 - access("PAL1"."PARTICIPANT_UID"=4105)
    filter("PAL1"."PARTICIPANT_UID"=4105)
    18 - access("SYS_ALIAS_8"."AWARD_CODE"="PDES"."AWARD_CODE"(+) AND
    "SYS_ALIAS_8"."AWARD_TYPE"="PDES"."AWARD_TYPE"(+))
    19 - access("SYS_ALIAS_7"."AWARD_CODE"="SYS_ALIAS_8"."AWARD_CODE")
    23 - access("CC_A_P_CURR"."TO_CURRENCY_UID"=1 AND "CC_A_P_CURR"."LATEST_FLAG"='Y')
    27 - access("PAV"."PARTICIPANT_UID"=4105)
    filter("PAV"."PARTICIPANT_UID"=4105)
    29 - access("SYS_ALIAS_7"."AWARD_CODE"="SYS_ALIAS_9"."AWARD_CODE" AND
    "SYS_ALIAS_7"."PARTICIPANT_UID"=4105)
    30 - filter("SYS_ALIAS_8"."PARTICIPANT_UID"=4105)
    33 - filter("CC"."LATEST_FLAG"='Y')
    37 - access("PDE"."PARTICIPANT_UID"=4105)
    filter("PDE"."PARTICIPANT_UID"=4105)
    39 - access("OFF_CURR"."CURRENCY_ISO_CODE"="PDE"."OFFERING_CURRENCY_ISO_CODE")
    40 - access("CC"."FROM_CURRENCY_UID"="OFF_CURR"."CURRENCY_UID" AND "CC"."TO_CURRENCY_UID"=1)
    43 - filter("PV"."VESTING_DATE"<=SYSDATE@!)
    44 - access("PV"."PARTICIPANT_UID"=4105)
    filter("PV"."PARTICIPANT_UID"=4105)
    47 - access("CURRENCY"."CURRENCY_ISO_CODE"=:B1)
    Note: cpu costing is off
    93 rows selected.
    Please help me out...
    -Sankar

  • Why is my SQL not using an index?

    I have a small SQL query (10g) where I join to basic table together on a customer_id column.
    select *
    from customer c
    inner join work_item sp1 ON sp1.customer_id = c.customer_id
    and I am using TOAD, which tells me (in the Explain Plan area), that I'm doing a "TABLE ACCESS FULL" scan on the customer table.
    But when I look at the details of BOTH tables, I can clearly see that they both have an index on the customer field, and they are both the same data types...
    The interesting thing, is that if I change the query to only select data from the work_item table,
    select sp1.*
    from customer c
    inner join work_item sp1 ON sp1.customer_id = c.customer_id
    I can see that the indexes are being used...
    Why is this? I must be able to select certain columns from the customer table, but why would it not use an index when I do?
    Thanks!

    If I understand correctly, below is a simple test case.
    I created a small table and indexed "object_id" column.
    When I issue "Select * from t" optimizer goes with FULL TABLE SCAN, whereas wehn "select OBJECT_ID from t" is issued, optimizer chooses to read from the index instead of accessing the table. This is because FAST FULL SCAN is far cheaper than a FTS in this case.
    SQL> create table t as select object_id, object_name from all_objects;
    Table created.
    SQL> exec dbms_stats.gather_table_stats(user, 't');
    PL/SQL procedure successfully completed.
    SQL> create index t_idx1 on t(object_id);
    Index created.
    SQL> set autotrace traceonly exp
    SQL> select * from t;
    Execution Plan
    Plan hash value: 1601196873
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      | 37932 |  1074K|    55   (2)| 00:00:01 |
    | 1 | TABLE ACCESS FULL| T | 37932 | 1074K| 55 (2)| 00:00:01 |
    SQL> select object_id from t;
    Execution Plan
    Plan hash value: 3958994525
    | Id  | Operation            | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT     |        | 37932 |   185K|    25   (0)| 00:00:01 |
    | 1 | INDEX FAST FULL SCAN| T_IDX1 | 37932 | 185K| 25 (0)| 00:00:01 |
    SQL>

  • How to prevent Oracle from using an index when joining two tables ...

    How to prevent Oracle from using an index when joining two tables to get an inline view which is used in an update statement?
    O.K. I think I have to explain what I mean:
    When joining two tables which have many entries sometimes it es better not to use an index on the column used as join criteria.
    I have two tables: table A and table B.
    Table A has 4.000.000 entries and table B has 700.000 entries.
    I have a join of both tables with a numeric column as join criteria.
    There is an index on this column in table A.
    So I instead of
      where (A.col = B.col)I want to use
      where (A.col+0 = B.col)in order to prevent Oracle from using the index.
    When I use the join in a select statement it works.
    But when I use the join as inline view in an update statement I get the error ORA-01779.
    When I remove the "+0" the update statement works. (The column col is unique in table B).
    Any ideas why this happens?
    Thank you very much in advance for any help.
    Regards Hartmut

    I think you should post an properly formatted explain plan output using DBMS_XPLAN.DISPLAY including the "Predicate Information" section below the plan to provide more details regarding your query resp. update statement. Please use the \[code\] and \[code\] tags to enhance readability of the output provided:
    In SQL*Plus:
    SET LINESIZE 130
    EXPLAIN PLAN FOR <your statement>;
    SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);Usually if you're using the CBO (cost based optimizer) and have reasonable statistics gathered on the database objects used the optimizer should be able to determine if it is better to use the existing index or not.
    Things look different if you don't have statistics, you have outdated/wrong statistics or deliberately still use the RBO (rule based optimizer). In this case you would have to use other means to prevent the index usage, the most obvious would be the already mentioned NO_INDEX or FULL hint.
    But I strongly recommend to check in first place why the optimizer apparently seems to choose an inappropriate index access path.
    Regards,
    Randolf
    Oracle related stuff:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle:
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

  • Why does it not use the index?

    L.S.,
    We are using a table called IT_RFC_REGISTRATION. It is a relatively big table for our application.
    Its primary key is RFCNR, each new RFCNR getting the next value.
    Now for my intranet report I am interested in the last 40 records. But when I execute:
    SELECT *
    FROM IT_RFC_REGISTRATION
    ORDER BY RFCNR DESC
    the query takes ages to execute.
    When I do this:
    SELECT RFCNR
    FROM IT_RFC_REGISTRATION
    ORDER BY RFCNR DESC
    the result comes instantaneous because this query uses the index on RFCNR.
    Why does the former query not use the index to execute? It should be much faster to fetch ROWIDs from the index end to start and use those to get the records, than to load all the records and then sort them.
    Is there a trick with which I can use a join of the latter query and the former query to speed up the result?
    Greetings,
    Philbert de Zwart,
    Utrecht, The Netherlands.

    The difference you see in query run time is based on the amount data being sorted, then returned. In the first query, a full table scan is faster since if the index was used, Oracle would have to do a lookup in the index, get the rowid's and go look up the data in the table (TWO disk i/o's). It's faster to just scan the entire table.
    Indexes will generally not be used unless you have a where clause. If you only need a few fields from the table, you could include them all in an index. For instance, if you only need RFCNR & DESC create a concatenated index on those two columns and then only a scan of the index is required (very fast).

  • Why is this query not using the index?

    check out this query:-
    SELECT CUST_PO_NUMBER, HEADER_ID, ORDER_TYPE, PO_DATE
    FROM TABLE1
    WHERE STATUS = 'N'
    and here's the explain plan:-
    1     
    2     -------------------------------------------------------------------------------------
    3     | Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
    4     -------------------------------------------------------------------------------------
    5     | 0 | SELECT STATEMENT | | 2735K| 140M| 81036 (2)|
    6     |* 1 | TABLE ACCESS FULL| TABLE1 | 2735K| 140M| 81036 (2)|
    7     -------------------------------------------------------------------------------------
    8     
    9     Predicate Information (identified by operation id):
    10     ---------------------------------------------------
    11     
    12     1 - filter("STATUS"='N')
    There is already an index on this column, as is shown below:-
         INDEX_NAME INDEX_TYPE     UNIQUENESS     TABLE_NAME     COLUMN_NAME     COLUMN_POSITION
    1     TABLE1_IDX2 NORMAL     NONUNIQUE     TABLE1      STATUS     1
    2     TABLE1_IDX NORMAL     NONUNIQUE     TABLE1     HEADER_ID     1
    So why is this query not using the index on the 'STATUS' Column?
    I've already tried using optimizer hints and regathering the stats on the table, but the execution plan still remains the same, i.e. it still uses a FTS.
    I have tried this command also:-
    exec dbms_stats.gather_table_stats('GECS','GEPS_CS_SALES_ORDER_HEADER',method_opt=>'for all indexed columns size auto',cascade=>true,degree=>4);
    inspite of this, the query is still using a full table scan.
    The table has around 55 Lakh records, across 60 columns. And because of the FTS, the query is taking a long time to execute. How do i make it use the index?
    Please help.
    Edited by: user10047779 on Mar 16, 2010 6:55 AM

    If the cardinality is really as skewed as that, you may want to look at putting a histogram on the column (sounds like it would be in order, and that you don't have one).
    create table skewed_a_lot
    as
       select
          case when mod(level, 1000) = 0 then 'N' else 'Y' end as Flag,
          level as col1
       from dual connect by level <= 1000000;
    create index skewed_a_lot_i01 on skewed_a_lot (flag);
    exec dbms_stats.gather_table_stats(user, 'SKEWED_A_LOT', cascade => true, method_opt => 'for all indexed columns size auto');Is an example.

  • Query not using the index

    Query
    SELECT case.case_objid FROM [email protected] case, table_x_cwp_tickect_details_vw t WHERE CASE.case_condition_cd IN ('OPEN', 'OPEN-DISPATCH', 'OPEN-REJECT', 'OPEN-RETURNED') AND case.case_type_cd in ('CUSTOMER FAULT', 'CHRONIC','SCHEDULED ACTIVITY','PROBLEM') AND ROWNUM <= 500 AND case.case_objid = t.ticket_objid AND ( ( case.account_id = '672286' ) ) ORDER BY case.case_id DESC
    From PROD
    Plan
    SELECT STATEMENT HINT: FIRST_ROWS Cost: 2,629 Bytes: 221,500 Cardinality: 500
         37 SORT ORDER BY Cost: 2,629 Bytes: 221,500 Cardinality: 500
              36 COUNT STOPKEY
                   35 NESTED LOOPS OUTER Cost: 2,628 Bytes: 279,533 Cardinality: 631
                        33 HASH JOIN OUTER Cost: 2,627 Bytes: 275,116 Cardinality: 631
                             31 NESTED LOOPS OUTER Cost: 2,249 Bytes: 266,282 Cardinality: 631
                                  28 NESTED LOOPS Cost: 1,766 Bytes: 257,448 Cardinality: 631
                                       26 NESTED LOOPS Cost: 1,765 Bytes: 253,031 Cardinality: 631
                                            24 NESTED LOOPS Cost: 1,764 Bytes: 248,614 Cardinality: 631
                                                 22 NESTED LOOPS Cost: 1,763 Bytes: 244,197 Cardinality: 631
                                                      19 NESTED LOOPS Cost: 1,258 Bytes: 235,363 Cardinality: 631
                                                           17 NESTED LOOPS Cost: 1,257 Bytes: 230,946 Cardinality: 631
                                                                14 NESTED LOOPS OUTER Cost: 752 Bytes: 217,695 Cardinality: 631
                                                                     12 HASH JOIN Cost: 751 Bytes: 213,278 Cardinality: 631
                                                                          1 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                          11 HASH JOIN Cost: 748 Bytes: 208,861 Cardinality: 631
                                                                               2 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                               10 HASH JOIN Cost: 746 Bytes: 204,444 Cardinality: 631
                                                                                    3 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                                    9 HASH JOIN Cost: 743 Bytes: 200,027 Cardinality: 631
                                                                                         4 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                                         8 NESTED LOOPS Cost: 741 Bytes: 195,610 Cardinality: 631
                                                                                              5 REMOTE REMOTE CASE Cost: 235 Bytes: 156,488 Cardinality: 631
                                                                                              7 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_CASE Cost: 1 Bytes: 62 Cardinality: 1
                                                                                                   6 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.TC_C_CASE_OBJINDEX Cost: 1 Cardinality: 1
                                                                     13 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.UN_PTT2CASE Cost: 1 Bytes: 7 Cardinality: 1
                                                                16 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_SITE Cost: 1 Bytes: 21 Cardinality: 1
                                                                     15 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_OBJINDEX Cost: 1 Cardinality: 1
                                                           18 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.BUS_ORG_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                      21 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_ADDRESS Cost: 1 Bytes: 14 Cardinality: 1
                                                           20 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.ADDRESS_OBJINDEX Cost: 1 Cardinality: 1
                                                 23 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.COUNTRY_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                            25 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONTACT_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                       27 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONDITION_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                  30 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE SA.TABLE_SITE_PART Cost: 1 Bytes: 14 Cardinality: 1 Partition #: 34
                                       29 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_PART_OBJINDEX Cost: 1 Cardinality: 1
                             bold 32 TABLE ACCESS FULL TABLE SA.TABLE_MOD_LEVEL Cost: 376 Bytes: 1,442,084 Cardinality: 103,006 bold
                        34 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.PART_NUM_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
    From DEV platform
    Plan
    SELECT STATEMENT HINT: FIRST_ROWS Cost: 591 Bytes: 61,134 Cardinality: 138
         37 SORT ORDER BY Cost: 591 Bytes: 61,134 Cardinality: 138
              36 COUNT STOPKEY
                   35 HASH JOIN Cost: 590 Bytes: 61,134 Cardinality: 138
                        1 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                        34 HASH JOIN Cost: 588 Bytes: 60,168 Cardinality: 138
                             2 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                             33 HASH JOIN Cost: 585 Bytes: 59,202 Cardinality: 138
                                  3 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                                  32 HASH JOIN Cost: 583 Bytes: 58,236 Cardinality: 138
                                       4 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                                       31 NESTED LOOPS OUTER Cost: 580 Bytes: 57,270 Cardinality: 138
                                            29 NESTED LOOPS OUTER Cost: 579 Bytes: 56,304 Cardinality: 138
                                                 27 NESTED LOOPS OUTER Cost: 469 Bytes: 54,372 Cardinality: 138
                                                      24 NESTED LOOPS Cost: 363 Bytes: 52,440 Cardinality: 138
                                                           22 NESTED LOOPS Cost: 362 Bytes: 51,474 Cardinality: 138
                                                                20 NESTED LOOPS Cost: 361 Bytes: 50,508 Cardinality: 138
                                                                     18 NESTED LOOPS Cost: 360 Bytes: 49,542 Cardinality: 138
                                                                          15 NESTED LOOPS Cost: 249 Bytes: 47,610 Cardinality: 138
                                                                               13 NESTED LOOPS Cost: 248 Bytes: 46,644 Cardinality: 138
                                                                                    10 NESTED LOOPS OUTER Cost: 138 Bytes: 43,746 Cardinality: 138
                                                                                         8 NESTED LOOPS Cost: 137 Bytes: 42,780 Cardinality: 138
                                                                                              5 REMOTE REMOTE CASE Cost: 26 Bytes: 34,224 Cardinality: 138
                                                                                              7 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_CASE Cost: 1 Bytes: 62 Cardinality: 1
                                                                                                   6 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.TC_C_CASE_OBJINDEX Cost: 1 Cardinality: 1
                                                                                         9 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.UN_PTT2CASE Cost: 1 Bytes: 7 Cardinality: 1
                                                                                    12 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_SITE Cost: 1 Bytes: 21 Cardinality: 1
                                                                                         11 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_OBJINDEX Cost: 1 Cardinality: 1
                                                                               14 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.BUS_ORG_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                                          17 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_ADDRESS Cost: 1 Bytes: 14 Cardinality: 1
                                                                               16 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.ADDRESS_OBJINDEX Cost: 1 Cardinality: 1
                                                                     19 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.COUNTRY_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                                21 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONTACT_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                           23 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONDITION_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                      26 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE SA.TABLE_SITE_PART Cost: 1 Bytes: 14 Cardinality: 1 Partition #: 34
                                                           25 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_PART_OBJINDEX Cost: 1 Cardinality: 1
                                       bold           28 INDEX RANGE SCAN INDEX SA.IND_PART_INFO2PART_NUM Cost: 1 Bytes: 14 Cardinality: 1 bold
                                            30 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.PART_NUM_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
    Conclusion:
    IND_PART_INFO2PART_NUM is not in use in Production environment
    PROD
    1. SQL> select index_name,NUM_ROWS,CLUSTERING_FACTOR from dba_indexes where index_name='IND_PART_INFO2PART_NUM';
    INDEX_NAME NUM_ROWS CLUSTERING_FACTOR
    IND_PART_INFO2PART_NUM 103023 46488
    DEV environment
    SQL> select index_name,NUM_ROWS,CLUSTERING_FACTOR,table_name from dba_indexes where index_name='IND_PART_INFO2PART_NUM';
    INDEX_NAME NUM_ROWS CLUSTERING_FACTOR TABLE_NAME
    IND_PART_INFO2PART_NUM 101982 45722 TABLE_MOD_LEVEL
    1. Index is rebuild
    2. stats are up to date
    3. Redef on table is done.
    Still no change in the plan .

    Osama-mustafa wrote:
    Aman.... wrote:
    Osama-mustafa wrote:
    alter index <index-name> rebuild ;Why?
    Aman....I faced this issue with query and indexes was need rebuildWhat issue Osama-that query wasn't using index and after rebuild it did start using it? Not just that this reply is wrong , this is OP has mentioned that he has done already. Please note that index rebuild is not the answer when the query is not using the index. There can be many reasons behind it. Have a look at Richard Foote's blog where he explains all of this in a very detailed way and in many posts.
    Aman....

  • Not using my index !!!

    i have 3 tables:
    customer (has over 120,000 rows)
    business
    workplace
    I'm doing a query which is blowing out (time wise) due to the fact that it's not using the index which i have specified on the customer table. The index which is specified on the customer table has 3 columns in it and in my joins i've used two of them and it's doing a full table scan.
    However, the other two tables are not as big as customer but not very small either and the joins that i've used on them are using the indexes that i've specified and is behaving.

    1.In a query change the order of a table ,keep the tables with less data first
    i.e select a.x,b.y,c.z
    from custormer a,business b,workplace c
    2.As far as u r using 2 columns in the same manner in order which index been created
    it doesn't matter
    check on explain plan and see which of the table been fully scan.
    Jitesh

  • Why my query not using any index but doing a FULL TABLE SCAN

    Hi,
    My EXPLAIN PLAN output is
    Plan hash value: 1163866984                                                                                                                                                                                                                                                                                 
    | Id  | Operation               | Name              | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |                                                                                                                                                                                                       
    |   0 | SELECT STATEMENT        |                   |   774 |   159K|       | 40847   (2)| 00:08:11 |                                                                                                                                                                                                       
    |*  1 |  FILTER                 |                   |       |       |       |            |          |                                                                                                                                                                                                       
    |   2 |   SORT GROUP BY         |                   |   774 |   159K|       | 40847   (2)| 00:08:11 |                                                                                                                                                                                                       
    |*  3 |    HASH JOIN            |                   | 77337 |    15M|  9744K| 40843   (2)| 00:08:11 |                                                                                                                                                                                                       
    |*  4 |     HASH JOIN           |                   | 77337 |  8836K|  5896K| 20987   (2)| 00:04:12 |                                                                                                                                                                                                       
    |*  5 |      HASH JOIN          |                   | 77337 |  4984K|       |  9292   (3)| 00:01:52 |                                                                                                                                                                                                       
    |*  6 |       HASH JOIN         |                   | 24991 |   951K|       |  3349   (3)| 00:00:41 |                                                                                                                                                                                                       
    |*  7 |        TABLE ACCESS FULL| IDS_TXNIDNUMBERS  | 24991 |   683K|       |  2328   (3)| 00:00:28 |                                                                                                                                                                                                       
    |   8 |        TABLE ACCESS FULL| IDS_TXNDEMDATAMAP |  2419K|    25M|       |  1006   (3)| 00:00:13 |                                                                                                                                                                                                       
    |   9 |       TABLE ACCESS FULL | IDS_IDNUMBERS     |  7435K|   191M|       |  5903   (2)| 00:01:11 |                                                                                                                                                                                                       
    |  10 |      TABLE ACCESS FULL  | IDS_DEMDATA       |  2583K|   125M|       |  3683   (5)| 00:00:45 |                                                                                                                                                                                                       
    |  11 |     TABLE ACCESS FULL   | IDS_TXN           |  2583K|   231M|       |  6403   (1)| 00:01:17 |                                                                                                                                                                                                       
    -----------------------------------------------------------------------------------------------------  All my 5 tables IDS_TXNIDNUMBERS, IDS_TXNDEMDATAMAP, IDS_IDNUMBERS,IDS_DEMDATA, IDS_TXN has indexes in relevant columns. Is it cause less time so CBO is not using the indexes.
    Thanks
    Amitava.

    amitavachatterjee1975 wrote:
    Please be polite when responding to my queries. If you find these questions not to your standard, stay away from them. This is an open forum and I have got my full rights to ask questions.Unsure, what wrong did you find in SB's reply. I find those links perfectly knowledgeable. The question of having so many unanswered questions probably pricked you a little too much. But that, IMO, is a legitimate question, to be asked to a User who even after being associated with OTN for over an year has 100% record of not getting an answer.
    For your original question, you will have to provide more details to allow people to answer you.
    You must read {message:id=3292438} and post the mentioned details. People do not carry a Crystal Ball to identify the problem merely by reading few lines of Problem description and Explain plans. Do not make people guess, provide appropriate details, to help them Help "You".

  • IP address not used correctly at RT Ping Controllers.vi

    It seems to me that the IP address provided to RT Ping Controller.vi and RT Reboot Controller is not used correctly.
    What I do is: Set the Subnet flag true and give a numerical IP adress to RT Ping Controller.vi
    What I get is the controller information for the controllers on the subnet, even if the IP does NOT match.
    Why do I do this? I want to acquire the MAC of the controller specified by the IP to use it for the reset vi.
    What I do second is: Set the subnet flag true and give an IP address to RT Reboot Controller.vi and provide a MAC address. The IP address does not match to the controller with the MAC given. The controller with the MAC reboots, independent of having a different IP.
    What is going
    on here and how can I get the correct MAC for an IP easily (i.e., without looking it up in MAX and typing it in somewhere)?

    Try setting the Local Subnet value to FALSE and pass in the IP you want to ping. You should get just details back on the target you specified, including it's MAC address. If the IP isn't a valid RT target, you will get an error.
    When Local subnet is set to TRUE, it will attempt to ping all controllers on the local subnet (regardless of the IP address passed in)--requiring you to search the resulting array for the IP you are interested in (and yep.. it might not be there).

  • Why my select is not using the index

    This is my index
    CREATE INDEX CONFIG_STATE_IDX ON IDENTIFIER
    (CONFIGURATION_ID, STATE)
    LOGGING
    TABLESPACE NII_INDEX
    PCTFREE 10
    INITRANS 2
    MAXTRANS 255
    STORAGE (
    INITIAL 64K
    MINEXTENTS 1
    MAXEXTENTS 2147483645
    PCTINCREASE 0
    FREELISTS 1
    FREELIST GROUPS 1
    BUFFER_POOL DEFAULT
    NOPARALLEL;
    This is my select statement:
    SELECT *
    FROM identifier i
    WHERE
         i.configuration_id = '89afead40a0c0b8d00628c59aa405ea4'
         AND i.state = 'QT'
    AND ROWNUM <6
    This is my exmplain plan result
    Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
    SELECT STATEMENT Hint=CHOOSE          5           2128                     
    COUNT STOPKEY                                        
    TABLE ACCESS FULL     IDENTIFIER     133 K     19 M     2128                     
    Why it is not using the index on configuration_id and state.

    Possibility one: you didn't do an analyze statistics on the table and/or the index after index creation.
    Possibility two: The optimizer has determined that it can return the query result set with fewer I/Os if it does a FTS vs using the index (the optimizer is very keen on I/Os).

  • Why Oracle not using the correct indexes after running table stats

    I created an index on the table and ran the a sql statement. I found that via the explain plan that index is being used and is cheaper which I wanted.
    Latter I ran all tables stats and found out again via explain plan that the same sql is now using different index and more costly plan. I don't know what is going on. Why this is happening. Any suggestions.
    Thx

    I just wanted to know the cost using the index.
    To gather histograms use (method_opt is the one that causes the package to collect histograms)
    DBMS_STATS.GATHER_SCHEMA_STATS (
    ownname => 'SCHEMA',
    estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
    block_sample => TRUE,
    method_opt => 'FOR ALL COLUMNS SIZE AUTO',
    degree => 4,
    granularity => 'ALL',
    cascade => TRUE,
    options => 'GATHER'
    );

  • CBO not picking correct indexes or doing Full Scans

    Database version - 10.2.0.4
    OS : Solaris 5.8
    Storage: SAN
    Application : PeopleSoft Financials
    DB size : 450 gb
    DB server : 12 CPU ( 900 Mghz each ), 36 GB RAM
    ASMM - sga_target_size = 5 gb
    Locally managed tablespaces - MANUAL
    - db_file_multiblock_read_count - not set explicitly in spfile ( implicitly defaulted to 128 )
    - other optimizer related parameters are set to default
    - system_statistics - CPUSPEEDNW=456.282722513089, IOSEEKTIM =10, IOTFRSPEED=4096     
    - dictionary object system stats were last gather in Nov 09
    - stats on schema objs are gathered every night using custom script, but I have to say there are some histograms on some tables which were gathered by PS admins
    begin
    dbms_stats.gather_schema_stats(
    ownname=> 'SCHEMANM' ,
    cascade=> DBMS_STATS.AUTO_CASCADE,
    estimate_percent=> DBMS_STATS.AUTO_SAMPLE_SIZE,
    degree=> 10,
    no_invalidate=> DBMS_STATS.AUTO_INVALIDATE,
    granularity=> 'AUTO',
    method_opt=> 'FOR ALL COLUMNS SIZE 1',
    options=> 'GATHER STALE');
    end;
    Details :
    We are experiencing erratic database performance. It was upgraded from 9i to 10g along with PS software upgrade. A job that runs on one day in 12 hrs(that is high in itself) would take more than 24 hrs another day.
    We have Test and Staging envs on other servers which do not have performance issues of production magnitude. The test, staging dbs are clones of prod, created by ftp'ing files from one location to another, not sure if that makes any difference but just pointing out.
    On Prod db some symptoms which baffle me are :
    1) sql executing for over 40 minutes, check the plan and it is using an "incorrect" index, idx1. Hint sql with "correct" index, idx2, and it runs in few seconds. result set <400 rows. Cost with hint with idx2 is HIGHER. This scenario is still understandable as CBO is likely to pick a lower cost.
    - But why is there so much discrepancy in cost and response time?
    - what is influencing the CBO to pick an index which is obviously not the fastest response time?
    2) sql plan shows FTS , execution time , runs forever . But a hint with index in this case shows the cost is LOWER and response time is in seconds, so why is CBO not even evaluating this index path? Because as I understand the CBO, it will always pick the lower cost plan.
    What is influencing the CBO. Is it system stats? or any other database parameter? or the hardware ? the large SGA?? histogram ?? Stats gathering?? is there is any known issue with DBMS_STATS.AUTO_SAMPLE_SIZE and cardinaility?
    Where should I put my focus?
    What am I looking for ?
    I do have Jonathan Lewis's Cost-Based Oracle Fundamentals which I have just started so perhaps I will be enlightened but while I read it, it would be of immense help to get some advice from forum gurus.
    At this time I am not posting any exec plan or code, but I can do so if required.
    Thanks,
    JC

    Picking up just a couple of points - the ones about: why can performance change so much from one day to the next, and how can the optimizer miss a plan which (when hinted) shows a lower cost.
    NOTE: These are only suggestions that may allow you to look at critical code and recognise the pattern of behaviour
    Performance change:
    You are using "gather stale" which means tables won't get new statistics is the volume of change since the last collection is "small". But peoplesoft tables can be big, so some tables may need a lot of data to change (which might take several days or weeks) before they get new stats. The 10g optimizer is able to compare the high-values stored with the predicate values supplied in queries, and decide that since the predicate is higher than the known highest value, it should scale down its estimates of data returned. After a few days when the stats haven't changed, the optimizer suddenly gets to the point where the estimated data size is much too small and the plan changes to something that you can see is bad. The typical example here is a date column that increases with time, and a query on "recent data" - the optimizer basically says: "you want 9th Feb - the high value says 28th Jan, there's virtually no data". Keeping date and sequence-based high-values up to date is important. (See dbms_stats.set_column_stats).
    Lower cost plans available:
    Sometimes this is a bug. Sometimes it's an unlucky side effect. When a query has a large number of tables in a single query block, the optimizer can only examine a limited subset of the possible join orders (for example, a 10-table join has over 3million join orders, and the default limit is 2,000 checked). Because of this limit, Oracle starts working through a few joins orders in a methodical manner, then does a "big jump" to a different set of join orders where it checks a few more join orders, then does another "big jump". It may be that it never gets to your nice plan with the lower cost because it doesn't have time. However, by putting in the hint, you may make some of the orders the optimizer would have examined drop out of the "methodical list" - so it examines a few more in one sequence, or possibly "jumps" to a different sequence that it would not othewise have reached. (I wrote a related blog item some time ago that might make this clearer, even though it's not about exactly the same phenomenon: http://jonathanlewis.wordpress.com/2006/11/03/table-order/ ).
    Your recent comment about dynamic sampling is correct, by the way - by default (which for your version is is level 2 as a system parameter) it will only apply for tables which don't have any statistics. It's only for higher levels, or when explicitly hinted for tables, that it can apply to tables with existing statistics.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    "Science is more than a body of knowledge; it is a way of thinking"
    Carl Sagan
    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.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

Maybe you are looking for

  • Flash installation problem

    i cannot install Flash.  I get so far and then i get a message to close internet explorer.  What am i doing wrong?  How do i close IE and still download?  help.

  • Battery problems with Hp Compaq CQ60

    So I inherited my sisters HP comapaq cq60 307-SA so that i have a laptop to take to university, but it has a lot of issues when it comes to battery. Sometimes the battery works fine, I charge it to 100%, and leave it to discharge, which it seems to d

  • File creation in Linux via FileWriter method

    I have a situation, that I find rather odd. When I run my java application under Linux it creates a file using FileWriter, but when the file is view via an edit like VI, the program states that the file is in dos format [dos mode]!!! How is this poss

  • Gow can I acsess an Object?

    I have an application, which have to build buttons dynamically. I get an Array with button objects as an JMS object Message. Do add the buttons to the GUI I do something like: for ( i = 0; i < array.lenght; i++) { Button button = (button) objectMessa

  • Weird quirk

    In early 2013, I bought a refurbished late-2012 iMac (the latest model) from Apple direct. The iMac naturally ships with Apple's bluetooth-wireless keyboard and "magic mouse". The magic mouse's quirks were a little too much for me. I set it aside and