Home » RDBMS Server » Performance Tuning » Unable to avoid Indexes (2 Merged) (Oracle 10g, Windows 2000)
Unable to avoid Indexes (2 Merged) [message #508361] Fri, 20 May 2011 10:47 Go to next message
oraranjangmailcom
Messages: 67
Registered: April 2010
Member
Hi

Below query is getting delayed becasue of BitMap Indexes on the table. I am trying to avoid indexes by using Hints in the query but unable to do so, please let me know how to achive the expected. Details are as follows.

explain plan for 
SELECT cbu_cid, cbu_cid_customer_en_nm,
         COUNT (billg_acct_no) AS billg_acct_no,
         SUM (subscriber_cnt) AS subscriber_cnt
    FROM daily_view
   WHERE (billg_system_id = 'TM' AND mktg_sub_segment_a_nm = 'TM')
     AND (cbu_cid NOT IN ('0001988048', '0001379962', '0001350469'))
GROUP BY cbu_cid, cbu_cid_customer_en_nm
  HAVING SUM (subscriber_cnt) > 10
ORDER BY subscriber_cnt DESC;

PLAN_TABLE_OUTPUT

Plan hash value: 2905810395
 
-----------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                        |     1 |    73 |  1651   (1)| 00:00:20 |
|   1 |  SORT ORDER BY                   |                        |     1 |    73 |  1651   (1)| 00:00:20 |
|*  2 |   FILTER                         |                        |       |       |            |          |
|   3 |    HASH GROUP BY                 |                        |     1 |    73 |  1651   (1)| 00:00:20 |
|*  4 |     HASH JOIN RIGHT OUTER        |                        |  4449 |   317K|  1648   (1)| 00:00:20 |
|   5 |      TABLE ACCESS FULL           | SALES_VIEW_TARGET      |     1 |    13 |     2   (0)| 00:00:01 |
|*  6 |      TABLE ACCESS BY INDEX ROWID | LEGAL_VIEW_TARGET      |  4449 |   260K|  1646   (1)| 00:00:20 |
|   7 |       BITMAP CONVERSION TO ROWIDS|                        |       |       |            |          |
|   8 |        BITMAP AND                |                        |       |       |            |          |
|*  9 |         BITMAP INDEX SINGLE VALUE| LEGAL_VIEW_TARGET_IX11 |       |       |            |          |
|* 10 |         BITMAP INDEX SINGLE VALUE| LEGAL_VIEW_TARGET_IX10 |       |       |            |          |
-----------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - filter(SUM("LEGAL"."SUBSCRIBER_CNT")>10)
   4 - access("SLS"."BILLING_ACCOUNT_ID"(+)="LEGAL"."BILLING_ACCOUNT_ID")
   6 - filter("LEGAL"."CBU_CID"<>'0001988048' AND "LEGAL"."CBU_CID"<>'0001379962' AND 
              "LEGAL"."CBU_CID"<>'0001350469')
   9 - access("LEGAL"."MKTG_SUB_SEGMENT_A_NM"='TM')
  10 - access("LEGAL"."BILLG_SYSTEM_ID"='TM')


The execution plan is same as above, when I tried with below hints.

Note: There are only two indexes on the table and they are on the fields billg_system_id(index- LEGAL_VIEW_TARGET_IX11
) & mktg_sub_segment_a_nm(index- LEGAL_VIEW_TARGET_IX10)

-- FULL(table)
explain plan for 
SELECT /*+ FULL(daily_view) */ 
  cbu_cid, cbu_cid_customer_en_nm,
         COUNT (billg_acct_no) AS billg_acct_no,
         SUM (subscriber_cnt) AS subscriber_cnt
    FROM daily_view
   WHERE (billg_system_id = 'TM' AND mktg_sub_segment_a_nm = 'TM')
     AND (cbu_cid NOT IN ('0001988048', '0001379962', '0001350469'))
GROUP BY cbu_cid, cbu_cid_customer_en_nm
  HAVING SUM (subscriber_cnt) > 10
ORDER BY subscriber_cnt DESC;


- No_Index(table index)
Query 1:-
explain plan for 
SELECT /*+ NO_INDEX(daily_view LEGAL_VIEW_TARGET_IX10 LEGAL_VIEW_TARGET_IX11) */ 
  cbu_cid, cbu_cid_customer_en_nm,
         COUNT (billg_acct_no) AS billg_acct_no,
         SUM (subscriber_cnt) AS subscriber_cnt
    FROM daily_view
   WHERE (billg_system_id = 'TM' AND mktg_sub_segment_a_nm = 'TM')
     AND (cbu_cid NOT IN ('0001988048', '0001379962', '0001350469'))
GROUP BY cbu_cid, cbu_cid_customer_en_nm
  HAVING SUM (subscriber_cnt) > 10
ORDER BY subscriber_cnt DESC;

Query 2:-
explain plan for 
SELECT /*+ NO_INDEX(daily_view LEGAL_VIEW_TARGET_IX10, LEGAL_VIEW_TARGET_IX11) */ 
  cbu_cid, cbu_cid_customer_en_nm,
         COUNT (billg_acct_no) AS billg_acct_no,
         SUM (subscriber_cnt) AS subscriber_cnt
    FROM daily_view
   WHERE (billg_system_id = 'TM' AND mktg_sub_segment_a_nm = 'TM')
     AND (cbu_cid NOT IN ('0001988048', '0001379962', '0001350469'))
GROUP BY cbu_cid, cbu_cid_customer_en_nm
  HAVING SUM (subscriber_cnt) > 10
ORDER BY subscriber_cnt DESC;


- NO_INDEX_FFS
Query 1:-
explain plan for 
SELECT /*+ NO_INDEX_FFS(daily_view LEGAL_VIEW_TARGET_IX10) NO_INDEX_FFS(daily_view LEGAL_VIEW_TARGET_IX11) */ 
  cbu_cid, cbu_cid_customer_en_nm,
         COUNT (billg_acct_no) AS billg_acct_no,
         SUM (subscriber_cnt) AS subscriber_cnt
    FROM daily_view
   WHERE (billg_system_id = 'TM' AND mktg_sub_segment_a_nm = 'TM')
     AND (cbu_cid NOT IN ('0001988048', '0001379962', '0001350469'))
GROUP BY cbu_cid, cbu_cid_customer_en_nm
  HAVING SUM (subscriber_cnt) > 10
ORDER BY subscriber_cnt DESC;

Query 2:-
explain plan for 
SELECT /*+ NO_INDEX_RS(daily_view LEGAL_VIEW_TARGET_IX10) NO_INDEX_RS(daily_view LEGAL_VIEW_TARGET_IX11) */ 
  cbu_cid, cbu_cid_customer_en_nm,
         COUNT (billg_acct_no) AS billg_acct_no,
         SUM (subscriber_cnt) AS subscriber_cnt
    FROM daily_view
   WHERE (billg_system_id = 'TM' AND mktg_sub_segment_a_nm = 'TM')
     AND (cbu_cid NOT IN ('0001988048', '0001379962', '0001350469'))
GROUP BY cbu_cid, cbu_cid_customer_en_nm
  HAVING SUM (subscriber_cnt) > 10
ORDER BY subscriber_cnt DESC;

Query 3:-
explain plan for 
SELECT /*+ NO_INDEX_SS(daily_view LEGAL_VIEW_TARGET_IX10) NO_INDEX_SS(daily_view LEGAL_VIEW_TARGET_IX11) */ 
  cbu_cid, cbu_cid_customer_en_nm,
         COUNT (billg_acct_no) AS billg_acct_no,
         SUM (subscriber_cnt) AS subscriber_cnt
    FROM daily_view
   WHERE (billg_system_id = 'TM' AND mktg_sub_segment_a_nm = 'TM')
     AND (cbu_cid NOT IN ('0001988048', '0001379962', '0001350469'))
GROUP BY cbu_cid, cbu_cid_customer_en_nm
  HAVING SUM (subscriber_cnt) > 10
ORDER BY subscriber_cnt DESC;


Note: Same Execution plan even after the execution of the query
i.e., BITMAP INDEX SINGLE VALUE| LEGAL_VIEW_TARGET_IX11
BITMAP INDEX SINGLE VALUE| LEGAL_VIEW_TARGET_IX10

Apart from above hints, I have tried with ALL_ROWS & PARALLEL.
Please let me know, how to avoid above two indexes in a query.

Thanks in Advance.
Re: Unable to avoid Indexes (2 Merged) [message #508366 is a reply to message #508361] Fri, 20 May 2011 11:12 Go to previous messageGo to next message
Michel Cadot
Messages: 68641
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
Why don't you want indexes?

Regards
Michel
Re: Unable to avoid Indexes (2 Merged) [message #508367 is a reply to message #508366] Fri, 20 May 2011 11:15 Go to previous messageGo to next message
oraranjangmailcom
Messages: 67
Registered: April 2010
Member
In this scenario Indexes are degrading the performance.

With Index Query Execution time is 5min & without is 1min.
Re: Unable to avoid Indexes (2 Merged) [message #508370 is a reply to message #508367] Fri, 20 May 2011 11:29 Go to previous messageGo to next message
Michel Cadot
Messages: 68641
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
So you should trace why Oracle chooses a wrong plan.
First are you sure your statistics are up to date?
Did calculate histograms on columns indexed with bitmap?

Regards
Michel
Re: Unable to avoid Indexes (2 Merged) [message #508371 is a reply to message #508370] Fri, 20 May 2011 11:38 Go to previous messageGo to next message
BlackSwan
Messages: 26766
Registered: January 2009
Location: SoCal
Senior Member
>FROM daily_view
>SALES_VIEW_TARGET
>LEGAL_VIEW_TARGET
color me CONFUSED!

How is it FROM clause says "daily_view" while EXPLAIN PLAN does not refer to "daily_view"
but instead mentions SALES_VIEW_TARGET & LEGAL_VIEW_TARGET???
Re: Unable to avoid Indexes (2 Merged) [message #508372 is a reply to message #508371] Fri, 20 May 2011 11:44 Go to previous messageGo to next message
BlackSwan
Messages: 26766
Registered: January 2009
Location: SoCal
Senior Member
>With Index Query Execution time is 5min & without is 1min.
I wish you stop posting contradictory information
EXPLAIN PLAN show time of only 20 seconds!

What is real & what is not?
Re: Unable to avoid Indexes (2 Merged) [message #508373 is a reply to message #508371] Fri, 20 May 2011 12:03 Go to previous messageGo to next message
oraranjangmailcom
Messages: 67
Registered: April 2010
Member
Daily_view is a view with join on two tables SALES_VIEW_TARGET & LEGAL_VIEW_TARGET. Sales_view_target doesn't have any data(hence used outer join).
All the data & indexes are on Legal_View_Target.
Re: Unable to avoid Indexes (2 Merged) [message #508386 is a reply to message #508373] Fri, 20 May 2011 15:19 Go to previous messageGo to next message
cookiemonster
Messages: 13920
Registered: September 2008
Location: Rainy Manchester
Senior Member
If daily_view is a view then why are you referring to it in the hints as though it's a table? The hints should almost certainly refer to LEGAL_VIEW_TARGET.
Re: Unable to avoid Indexes (2 Merged) [message #508445 is a reply to message #508386] Sat, 21 May 2011 04:43 Go to previous messageGo to next message
oraranjangmailcom
Messages: 67
Registered: April 2010
Member
As suggested, I tried below approach but execution plan did not change. i.e., no_index on the table "legal_view_target"

explain plan for 
SELECT /*+ NO_INDEX(legal_view_target LEGAL_VIEW_TARGET_IX10 LEGAL_VIEW_TARGET_IX11) */ 
  cbu_cid, cbu_cid_customer_en_nm,
         COUNT (billg_acct_no) AS billg_acct_no,
         SUM (subscriber_cnt) AS subscriber_cnt
    FROM daily_view
   WHERE (billg_system_id = 'TM' AND mktg_sub_segment_a_nm = 'TM')
     AND (cbu_cid NOT IN ('0001988048', '0001379962', '0001350469'))
GROUP BY cbu_cid, cbu_cid_customer_en_nm
  HAVING SUM (subscriber_cnt) > 10
ORDER BY subscriber_cnt DESC;


Re: Unable to avoid Indexes (2 Merged) [message #508461 is a reply to message #508445] Sat, 21 May 2011 09:18 Go to previous messageGo to next message
Michel Cadot
Messages: 68641
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
You search the wrong way.
Hints are to be used ONLY when you have to finally say "I failed".

Regards
Michel

[Updated on: Sat, 21 May 2011 09:18]

Report message to a moderator

Re: Unable to avoid Indexes (2 Merged) [message #508470 is a reply to message #508445] Sat, 21 May 2011 15:27 Go to previous messageGo to next message
John Watson
Messages: 8929
Registered: January 2010
Location: Global Village
Senior Member
To pass hint to a view, you have to use an extended hint syntax, it uses a kind-of recursive dot notation:
create view cv as select * from customers c where cust_city like 'S%';

select /*+ index(v.c cust_credit_limit_idx) */
v.cust_last_name, v.cust_credit_limit from cv v where cust_credit_limit > 5000;

Re: Unable to avoid Indexes (2 Merged) [message #508497 is a reply to message #508470] Sun, 22 May 2011 03:45 Go to previous messageGo to next message
desertman909y
Messages: 9
Registered: May 2011
Location: dubai
Junior Member
in my information Mr Michel Cadot is rite but u can ask other Senior members to what they advice... this is also important


Re: Unable to avoid Indexes (2 Merged) [message #508558 is a reply to message #508361] Mon, 23 May 2011 03:02 Go to previous messageGo to next message
Yasir Hashmi
Messages: 304
Registered: April 2006
Senior Member
If you really waqnt to avoid bitmap indexes,you might run the query with this hint:

opt_param('_b_tree_bitmap_plans','false')

[Updated on: Mon, 23 May 2011 03:03]

Report message to a moderator

Re: Unable to avoid Indexes (2 Merged) [message #508566 is a reply to message #508558] Mon, 23 May 2011 03:50 Go to previous messageGo to next message
Michel Cadot
Messages: 68641
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
It is not wise to use hint, it is even less wise to provide not documented hint.
The first thing is to understand what happens BEFORE searching any workaround.
I think as really stupid to go the other way.

Regards
Michel
Re: Unable to avoid Indexes (2 Merged) [message #508570 is a reply to message #508566] Mon, 23 May 2011 04:17 Go to previous messageGo to next message
Yasir Hashmi
Messages: 304
Registered: April 2006
Senior Member
Yes its always good to analyze the issue and hints on a long way might hamper the performance further as data changes.
But the OP I believe needs a quick fix.
Re: Unable to avoid Indexes (2 Merged) [message #508571 is a reply to message #508558] Mon, 23 May 2011 04:21 Go to previous messageGo to next message
Yasir Hashmi
Messages: 304
Registered: April 2006
Senior Member
@OP
As it is an undocumented hint use it at your own risk.
and if you have support,its better to ask them regrading the issue.

[Updated on: Mon, 23 May 2011 04:22]

Report message to a moderator

Re: Unable to avoid Indexes (2 Merged) [message #508573 is a reply to message #508570] Mon, 23 May 2011 04:35 Go to previous messageGo to next message
Michel Cadot
Messages: 68641
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
Quote:
hints on a long way might hamper the performance further as data changes

And in a short term at the next patchset.
Remember, queries with hints are not stable, optimizer behaviour changes at each patchset, so you have to test ALL your queries with hints at each patchset and even PSU.

Regards
Michel
Re: Unable to avoid Indexes (2 Merged) [message #508588 is a reply to message #508470] Mon, 23 May 2011 05:13 Go to previous messageGo to next message
oraranjangmailcom
Messages: 67
Registered: April 2010
Member
There is nochange in the query execution plan. Details are as below.

> explain plan for 
SELECT /*+ NO_INDEX(dv.LEGAL LEGAL_VIEW_TARGET_IX10) NO_INDEX(dv.LEGAL LEGAL_VIEW_TARGET_IX11)*/
         dv.cbu_cid, dv.cbu_cid_customer_en_nm,
         COUNT (dv.billg_acct_no) AS billg_acct_no,
         SUM (dv.subscriber_cnt) AS subscriber_cnt
    FROM daily_view dv
   WHERE (dv.billg_system_id = 'TM' AND dv.mktg_sub_segment_a_nm = 'TM')
     AND (dv.cbu_cid NOT IN ('0001988048', '0001379962', '0001350469'))
GROUP BY dv.cbu_cid, dv.cbu_cid_customer_en_nm
  HAVING SUM (dv.subscriber_cnt) > 10
ORDER BY subscriber_cnt DESC;

> SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());


PLAN_TABLE_OUTPUT

Plan hash value: 2905810395
 
-----------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                        |     1 |   209 |  1614   (1)| 00:00:20 |
|   1 |  SORT ORDER BY                   |                        |     1 |   209 |  1614   (1)| 00:00:20 |
|*  2 |   FILTER                         |                        |       |       |            |          |
|   3 |    HASH GROUP BY                 |                        |     1 |   209 |  1614   (1)| 00:00:20 |
|*  4 |     HASH JOIN RIGHT OUTER        |                        |  4366 |   891K|  1612   (1)| 00:00:20 |
|   5 |      TABLE ACCESS FULL           | SALES_VIEW_TARGET      |     1 |    13 |     2   (0)| 00:00:01 |
|*  6 |      TABLE ACCESS BY INDEX ROWID | LEGAL_VIEW_TARGET      |  4366 |   835K|  1609   (1)| 00:00:20 |
|   7 |       BITMAP CONVERSION TO ROWIDS|                        |       |       |            |          |
|   8 |        BITMAP AND                |                        |       |       |            |          |
|*  9 |         BITMAP INDEX SINGLE VALUE| LEGAL_VIEW_TARGET_IX11 |       |       |            |          |
|* 10 |         BITMAP INDEX SINGLE VALUE| LEGAL_VIEW_TARGET_IX10 |       |       |            |          |
-----------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - filter(SUM("LEGAL"."SUBSCRIBER_CNT")>10)
   4 - access("SLS"."BILLING_ACCOUNT_ID"(+)="LEGAL"."BILLING_ACCOUNT_ID")
   6 - filter("LEGAL"."CBU_CID"<>'0001988048' AND "LEGAL"."CBU_CID"<>'0001379962' AND 
              "LEGAL"."CBU_CID"<>'0001350469')
   9 - access("LEGAL"."MKTG_SUB_SEGMENT_A_NM"='TM')
  10 - access("LEGAL"."BILLG_SYSTEM_ID"='TM')
Re: Unable to avoid Indexes (2 Merged) [message #508589 is a reply to message #508558] Mon, 23 May 2011 05:27 Go to previous messageGo to next message
oraranjangmailcom
Messages: 67
Registered: April 2010
Member
I have updated the query with "opt_param('_b_tree_bitmap_plans','false')" but there is no change in query execution plan.
Re: Unable to avoid Indexes (2 Merged) [message #508591 is a reply to message #508470] Mon, 23 May 2011 05:34 Go to previous messageGo to next message
oraranjangmailcom
Messages: 67
Registered: April 2010
Member
I was able to replicate the issue in local Database and by using above extended hint syntax (it uses a kind-of recursive dot notation) I was able to avoide the Bitmap indexes, but in my client Database same approach is not helping me. Details are as follows.
SQL> create table t_1 (a number);

Table created.

SQL> create table t_2 (b number);

Table created.

SQL> insert into t_1 (a) values (1);

1 row created.

SQL> insert into t_1 (a) values (2);

1 row created.

SQL> insert into t_1 (a) values (3);

1 row created.

SQL>  insert into t_1 (a) values (4);

1 row created.

SQL> commit;

Commit complete.

SQL> insert into t_2 (b) values (1);

1 row created.

SQL> insert into t_2 (b) values (2);

1 row created.

SQL> insert into t_2 (b) values (3);

1 row created.

SQL> insert into t_2 (b) values (
  2  4);

1 row created.

SQL> commit;

Commit complete.

SQL> select * from t_1;

         A
----------
         1
         2
         3
         4

SQL> select * from t_2;

         B
----------
         1
         2
         3
         4

SQL> create bitmap index x1 on t_1(a);

Index created.

SQL> create bitmap index x2 on t_2(b);

Index created.

SQL> create or replace view view_12 as select * from t_1, t_2 where a = b;

View created.

SQL> select * from view_12;

         A          B
---------- ----------
         1          1
         2          2
         3          3
         4          4
SQL> BEGIN
  2      dbms_stats.gather_table_stats(
  3      ownname => SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA'),
  4      tabname => 'T_1',
  5      method_opt => 'FOR ALL INDEXED COLUMNS SIZE 4',
  6      cascade => TRUE
  7      );
  8    END;
  9  /

PL/SQL procedure successfully completed.

SQL> ED
Wrote file afiedt.buf

  1  BEGIN
  2      dbms_stats.gather_table_stats(
  3      ownname => SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA'),
  4      tabname => 'T_2',
  5      method_opt => 'FOR ALL INDEXED COLUMNS SIZE 4',
  6      cascade => TRUE
  7      );
  8*   END;
SQL> /

PL/SQL procedure successfully completed.

SQL> SET AUTOTRACE TRACEONLY;
SQL> SELECT A, B FROM VIEW_12;


Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=4 Bytes=24)
   1    0   NESTED LOOPS (Cost=1 Card=4 Bytes=24)
   2    1     BITMAP CONVERSION (TO ROWIDS)
   3    2       BITMAP INDEX (FAST FULL SCAN) OF 'X1'
   4    1     BITMAP CONVERSION (TO ROWIDS)
   5    4       BITMAP INDEX (SINGLE VALUE) OF 'X2'




Statistics
----------------------------------------------------------
          7  recursive calls
          2  db block gets
          7  consistent gets
          0  physical reads
          0  redo size
        570  bytes sent via SQL*Net to client
        503  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          4  rows processed

SQL> SELECT /*+ NO_INDEX(V.T_1 X1) NO_INDEX(V.T_2 X2) */ V.A, V.B FROM VIEW_12 V;


Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=4 Bytes=24)
   1    0   HASH JOIN (Cost=3 Card=4 Bytes=24)
   2    1     TABLE ACCESS (FULL) OF 'T_1' (Cost=1 Card=4 Bytes=12)
   3    1     TABLE ACCESS (FULL) OF 'T_2' (Cost=1 Card=4 Bytes=12)




Statistics
----------------------------------------------------------
          7  recursive calls
          4  db block gets
          5  consistent gets
          0  physical reads
          0  redo size
        570  bytes sent via SQL*Net to client
        503  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          4  rows processed
Re: Unable to avoid Indexes (2 Merged) [message #508593 is a reply to message #508591] Mon, 23 May 2011 05:43 Go to previous messageGo to next message
Michel Cadot
Messages: 68641
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
And the cost is higher without the hint, so your test case is not representative to your actual problem.
Too bad you don't want to correctly work and stay stuck to hints.
When you will not be able to make it work with hints maybe you will start to properly work.

Regards
Michel
Re: Unable to avoid Indexes (2 Merged) [message #508595 is a reply to message #508367] Mon, 23 May 2011 05:50 Go to previous messageGo to next message
Roachcoach
Messages: 1576
Registered: May 2010
Location: UK
Senior Member
oraranjangmailcom wrote on Fri, 20 May 2011 17:15
In this scenario Indexes are degrading the performance.

With Index Query Execution time is 5min & without is 1min.



I confess top reading the thread pretty quickly and may have missed it BUT...


If you can prevent the use of the indexes in order to make the above assertion, why can you not use that method to solve the problem?
Re: Unable to avoid Indexes (2 Merged) [message #508619 is a reply to message #508588] Mon, 23 May 2011 08:15 Go to previous messageGo to next message
Yasir Hashmi
Messages: 304
Registered: April 2006
Senior Member
Why don't you try to create a concatenated bitmap index for these two columns?

Quote:
dv.billg_system_id ,dv.mktg_sub_segment_a_nm

Re: Unable to avoid Indexes (2 Merged) [message #508696 is a reply to message #508593] Tue, 24 May 2011 02:11 Go to previous messageGo to next message
oraranjangmailcom
Messages: 67
Registered: April 2010
Member
I have ran the query with the index & without the index on Daily_View (i.e., table:- legal_view_target). Observation is as below.

With the Index :- 4 to 5minutes
WithOut the Index(full table scan):- 1minutes: 30seconds.

Based on the above timelines, I am trying to avoid indexes.

Note: In this scenarios Full Table Scan is Suggested(as per the discussion with seniors in the respective application). Please let me know if I need to observe any thing else.
Re: Unable to avoid Indexes (2 Merged) [message #508698 is a reply to message #508696] Tue, 24 May 2011 02:18 Go to previous messageGo to next message
Roachcoach
Messages: 1576
Registered: May 2010
Location: UK
Senior Member
Did you drop the indexes then?

Also have you eliminated SGA block caching as a possibility for the difference?
Re: Unable to avoid Indexes (2 Merged) [message #508745 is a reply to message #508698] Tue, 24 May 2011 06:44 Go to previous messageGo to next message
jitendra.prakash
Messages: 8
Registered: October 2009
Junior Member
I believe quering a view with a Oracle Hint not going to makr difference because the hint is not going to propagate into view query.Better to try some other way.
Re: Unable to avoid Indexes (2 Merged) [message #508752 is a reply to message #508745] Tue, 24 May 2011 06:53 Go to previous messageGo to next message
cookiemonster
Messages: 13920
Registered: September 2008
Location: Rainy Manchester
Senior Member
John Watson has already shown how to make hints propogate through views.
Re: Unable to avoid Indexes (2 Merged) [message #508753 is a reply to message #508745] Tue, 24 May 2011 06:53 Go to previous messageGo to next message
Michel Cadot
Messages: 68641
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
Maybe you should read what has already been posted before posting your answer.
The opposite of what you say has been proved a couple of posts above.

Regards
Michel
Re: Unable to avoid Indexes (2 Merged) [message #509207 is a reply to message #508753] Thu, 26 May 2011 08:36 Go to previous message
oraranjangmailcom
Messages: 67
Registered: April 2010
Member
Thanks ...
Previous Topic: How to Optimize the Query Without Using IN opertator
Next Topic: Statistics gathering approach
Goto Forum:
  


Current Time: Sat Apr 20 01:46:10 CDT 2024