Which views do we need to query to find the the current running queries which are using indexes with high costs? Kindly suggest.

Thanks,
Kartik

Nice comment, especially the addition of (sensible).
Thanks for that – and the follow-up.
Interestingly the same strategy fails (in 10.2.0.3) for my bitmap join index example, although it worked for a bitmap join index which was a two-table join rather than three tables
Your example did make me think about the side effects of things like export/import, and dropping indexes, etc.
I hope everyone noticed your comment about danger – here’s a little threat waitng to happen if anyone takes that approach in production:

SQL> select column_name from user_tab_cols where table_name = 'PEOPLE';

COLUMN_NAME
--------------------
ID_TOWN_WORK
ID_TOWN_HOME
PADDING

SQL> create index pe_ho1 on people(id_town_home + 1);

Index created.

SQL> select column_name from user_tab_cols where table_name = 'PEOPLE';

COLUMN_NAME
--------------------
ID_TOWN_WORK
ID_TOWN_HOME
PADDING
SYS_NC00004$

SQL> create index pe_ho2 on people(id_town_home + 2);

Index created.

SQL> select column_name from user_tab_cols where table_name = 'PEOPLE';

COLUMN_NAME
--------------------
ID_TOWN_WORK
ID_TOWN_HOME
PADDING
SYS_NC00004$
SYS_NC00005$

SQL> drop index pe_ho1;

Index dropped.

SQL> select column_name from user_tab_cols where table_name = 'PEOPLE';

COLUMN_NAME
--------------------
ID_TOWN_WORK
ID_TOWN_HOME
PADDING
SYS_NC00004$

Notice how the virtual column for index pe_ho2 starts life as sys_nc00005$, but changes to sys_nc00004$ when you drop the index pe_ho1 ?
That surprised me – I thought I’d have to use an export import pass to switch virtual columes on the indexes

There is no (sensible) alternative.
i.e. could you not use the hidden column name?

SQL> explain plan for
  2  select * 
  3  from t2 
  4  where nvl(col1,1) > 0;

Explained.

SQL> 
SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------
Plan hash value: 1513984157

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      | 10000 | 80000 |     9  (12)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T2   | 10000 | 80000 |     9  (12)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(NVL("COL1",1)>0)

13 rows selected.

SQL> 
SQL> explain plan for
  2  select /*+
  3           index(@"SEL$1" "T2"@"SEL$1" ("T2"."SYS_NC00002$")) 
  4           */ 
  5         * 
  6  from t2 
  7  where nvl(col1,1) > 0;

Explained.

SQL> 
SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------
Plan hash value: 3246639252

------------------------------------------------------------------------------------
| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |      | 10000 | 80000 |    38   (3)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T2   | 10000 | 80000 |    38   (3)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | I_T2 | 10000 |       |    22   (5)| 00:00:01 |
------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access(NVL("COL1",1)>0)

14 rows selected.

SQL> 

I guess because the index type is function-base