SEO

Hi,

Is there a way to find out what indexes are used(useful)/unused(useless)
while the last few days/weeks?
If possible so tell me a way via data dictionary without using any
external tools.

Andreas Mosmann

--
wenn email, dann AndreasMosmann <bei> web <punkt> de

On Apr 17, 4:38*am, Andreas Mosmann <mosm...@expires-30-04-2008.news-
group.org> wrote:
> Hi,
>
> Is there a way to find out what indexes are used(useful)/unused(useless)
> while the last few days/weeks?
> If possible so tell me a way via data dictionary without using any
> external tools.
>
> Andreas Mosmann
>
> --
> wenn email, dann AndreasMosmann <bei> web <punkt> de

Let Oracle do that for you:

SQL> create index emp_eno_idx
2 on emp(empno);

Index created.

SQL>
SQL> alter index emp_eno_idx monitoring usage;

Index altered.

SQL>
SQL> select * from emp;

EMPNO ENAME JOB MGR HIREDATE SAL
COMM DEPTNO
---------- ---------- --------- ---------- --------- ----------
---------- ----------
7369 SMITH CLERK 7902 17-DEC-80
800 20
7499 ALLEN SALESMAN 7698 20-FEB-81 1600
300 30
7521 WARD SALESMAN 7698 22-FEB-81 1250
500 30
7566 JONES MANAGER 7839 02-APR-81
2975 20
7654 MARTIN SALESMAN 7698 28-SEP-81 1250
1400 30
7698 BLAKE MANAGER 7839 01-MAY-81
2850 30
7782 CLARK MANAGER 7839 09-JUN-81
2450 10
7788 SCOTT ANALYST 7566 09-DEC-82
3000 20
7839 KING PRESIDENT 17-NOV-81
5000 10
7844 TURNER SALESMAN 7698 08-SEP-81
1500 0 30
7876 ADAMS CLERK 7788 12-JAN-83
1100 20

EMPNO ENAME JOB MGR HIREDATE SAL
COMM DEPTNO
---------- ---------- --------- ---------- --------- ----------
---------- ----------
7900 JAMES CLERK 7698 03-DEC-81
950 30
7902 FORD ANALYST 7566 03-DEC-81
3000 20
7934 MILLER CLERK 7782 23-JAN-82
1300 10

14 rows selected.

SQL>
SQL> select index_name, table_name, used from v$object_usage;

INDEX_NAME TABLE_NAME USE
------------------------------ ------------------------------ ---
EMP_ENO_IDX EMP NO

SQL>
SQL> select * from emp where deptno = 30;

EMPNO ENAME JOB MGR HIREDATE SAL
COMM DEPTNO
---------- ---------- --------- ---------- --------- ----------
---------- ----------
7499 ALLEN SALESMAN 7698 20-FEB-81 1600
300 30
7521 WARD SALESMAN 7698 22-FEB-81 1250
500 30
7654 MARTIN SALESMAN 7698 28-SEP-81 1250
1400 30
7698 BLAKE MANAGER 7839 01-MAY-81
2850 30
7844 TURNER SALESMAN 7698 08-SEP-81
1500 0 30
7900 JAMES CLERK 7698 03-DEC-81
950 30

6 rows selected.

SQL>
SQL> select index_name, table_name, used from v$object_usage;

INDEX_NAME TABLE_NAME USE
------------------------------ ------------------------------ ---
EMP_ENO_IDX EMP NO

SQL>
SQL> select * from emp where empno < 7400;

EMPNO ENAME JOB MGR HIREDATE SAL
COMM DEPTNO
---------- ---------- --------- ---------- --------- ----------
---------- ----------
7369 SMITH CLERK 7902 17-DEC-80
800 20

SQL>
SQL> select index_name, table_name, used from v$object_usage;

INDEX_NAME TABLE_NAME USE
------------------------------ ------------------------------ ---
EMP_ENO_IDX EMP YES

SQL>

Using the 'alter index <indexname> monitoring usage;' directive
Oracle will keep track of whether or not an index is actually used and
will do so until you issue an 'alter index <indexname> nomonitoring
usage;' command. A simple query of V$OBJECT_USAGE will reveal which
indexes are and are not used. After an 'alter index <indexname>
nomonitoring usage;' directive is issued the collected data remains in
the V$OBJECT_USAGE view; it isn't removed for the objects in question
until another 'alter index ... monitoring usage;' command is called:

SQL> alter index emp_eno_idx nomonitoring usage;

Index altered.

SQL> select index_name, table_name,used from v$object_usage;

INDEX_NAME TABLE_NAME USE
------------------------------ ------------------------------ ---
EMP_ENO_IDX EMP YES

SQL>


David Fitzjarrell

fitzjarrell@cox.net wrote:
> On Apr 17, 4:38 am, Andreas Mosmann <mosm...@expires-30-04-2008.news-
> group.org> wrote:
>> Hi,
>>
>> Is there a way to find out what indexes are used(useful)/unused(useless)
>> while the last few days/weeks?
>> If possible so tell me a way via data dictionary without using any
>> external tools.
>>
>> Andreas Mosmann
>>
>> --
>> wenn email, dann AndreasMosmann <bei> web <punkt> de
>
> Let Oracle do that for you:
>
> SQL> create index emp_eno_idx
> 2 on emp(empno);
>
> Index created.
>
> SQL>
> SQL> alter index emp_eno_idx monitoring usage;
>
> Index altered.
>
> SQL>
> SQL> select * from emp;
>
> EMPNO ENAME JOB MGR HIREDATE SAL
> COMM DEPTNO
> ---------- ---------- --------- ---------- --------- ----------
> ---------- ----------
> 7369 SMITH CLERK 7902 17-DEC-80
> 800 20
> 7499 ALLEN SALESMAN 7698 20-FEB-81 1600
> 300 30
> 7521 WARD SALESMAN 7698 22-FEB-81 1250
> 500 30
> 7566 JONES MANAGER 7839 02-APR-81
> 2975 20
> 7654 MARTIN SALESMAN 7698 28-SEP-81 1250
> 1400 30
> 7698 BLAKE MANAGER 7839 01-MAY-81
> 2850 30
> 7782 CLARK MANAGER 7839 09-JUN-81
> 2450 10
> 7788 SCOTT ANALYST 7566 09-DEC-82
> 3000 20
> 7839 KING PRESIDENT 17-NOV-81
> 5000 10
> 7844 TURNER SALESMAN 7698 08-SEP-81
> 1500 0 30
> 7876 ADAMS CLERK 7788 12-JAN-83
> 1100 20
>
> EMPNO ENAME JOB MGR HIREDATE SAL
> COMM DEPTNO
> ---------- ---------- --------- ---------- --------- ----------
> ---------- ----------
> 7900 JAMES CLERK 7698 03-DEC-81
> 950 30
> 7902 FORD ANALYST 7566 03-DEC-81
> 3000 20
> 7934 MILLER CLERK 7782 23-JAN-82
> 1300 10
>
> 14 rows selected.
>
> SQL>
> SQL> select index_name, table_name, used from v$object_usage;
>
> INDEX_NAME TABLE_NAME USE
> ------------------------------ ------------------------------ ---
> EMP_ENO_IDX EMP NO
>
> SQL>
> SQL> select * from emp where deptno = 30;
>
> EMPNO ENAME JOB MGR HIREDATE SAL
> COMM DEPTNO
> ---------- ---------- --------- ---------- --------- ----------
> ---------- ----------
> 7499 ALLEN SALESMAN 7698 20-FEB-81 1600
> 300 30
> 7521 WARD SALESMAN 7698 22-FEB-81 1250
> 500 30
> 7654 MARTIN SALESMAN 7698 28-SEP-81 1250
> 1400 30
> 7698 BLAKE MANAGER 7839 01-MAY-81
> 2850 30
> 7844 TURNER SALESMAN 7698 08-SEP-81
> 1500 0 30
> 7900 JAMES CLERK 7698 03-DEC-81
> 950 30
>
> 6 rows selected.
>
> SQL>
> SQL> select index_name, table_name, used from v$object_usage;
>
> INDEX_NAME TABLE_NAME USE
> ------------------------------ ------------------------------ ---
> EMP_ENO_IDX EMP NO
>
> SQL>
> SQL> select * from emp where empno < 7400;
>
> EMPNO ENAME JOB MGR HIREDATE SAL
> COMM DEPTNO
> ---------- ---------- --------- ---------- --------- ----------
> ---------- ----------
> 7369 SMITH CLERK 7902 17-DEC-80
> 800 20
>
> SQL>
> SQL> select index_name, table_name, used from v$object_usage;
>
> INDEX_NAME TABLE_NAME USE
> ------------------------------ ------------------------------ ---
> EMP_ENO_IDX EMP YES
>
> SQL>
>
> Using the 'alter index <indexname> monitoring usage;' directive
> Oracle will keep track of whether or not an index is actually used and
> will do so until you issue an 'alter index <indexname> nomonitoring
> usage;' command. A simple query of V$OBJECT_USAGE will reveal which
> indexes are and are not used. After an 'alter index <indexname>
> nomonitoring usage;' directive is issued the collected data remains in
> the V$OBJECT_USAGE view; it isn't removed for the objects in question
> until another 'alter index ... monitoring usage;' command is called:
>
> SQL> alter index emp_eno_idx nomonitoring usage;
>
> Index altered.
>
> SQL> select index_name, table_name,used from v$object_usage;
>
> INDEX_NAME TABLE_NAME USE
> ------------------------------ ------------------------------ ---
> EMP_ENO_IDX EMP YES
>
> SQL>
>
>
> David Fitzjarrell

One small addendum to David's excellent response.

Sometimes Oracle uses the statistics collected for an index but does
not use the index itself.

Thus it is possible to drop an unused index and have performance
affected. If you see this happen then rebuild the index and note
what is happening for future reference.
--
Daniel A. Morgan
Oracle Ace Director & Instructor
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

Thank both of you,

I will try it out.
Is there also a way to determine what index is still needed/useful for a
special query?

Andreas Mosmann

--
wenn email, dann AndreasMosmann <bei> web <punkt> de

On Apr 18, 2:29*am, Andreas Mosmann <mosm...@expires-30-04-2008.news-
group.org> wrote:
> Thank both of you,
>
> I will try it out.
> Is there also a way to determine what index is still needed/useful for a
> special query?
>
> Andreas Mosmann
>
> --
> wenn email, dann AndreasMosmann <bei> web <punkt> de

I do believe that is the downside of deleting indices based on usage.
It only shows what's been used during the observation. That implies a
bad assumption that the usage is completely stable. To me, this seems
worse than just dropping an index and seeing who screams, since when
there is a problem in the future, you have to go through an entire
performance tuning workup because the linkage to the act of dropping
the index is obscured. Maybe I'm missing the concept. What about an
index that would be used when you pass some tipping point or boundary
condition or upgrade or change a session parameter?

I just don't get it. This looks like a feature capriciously useful
for poorly implemented systems.

jg
--
@home.com is bogus.
22 innings of baseball. Yikes!

joel garry (joel-garry@home.com) wrote:
: On Apr 18, 2:29=A0am, Andreas Mosmann <mosm...@expires-30-04-2008.news-
: group.org> wrote:
: > Thank both of you,
: >
: > I will try it out.
: > Is there also a way to determine what index is still needed/useful for a
: > special query?
: >
: > Andreas Mosmann
: >
: > --
: > wenn email, dann AndreasMosmann <bei> web <punkt> de

: I do believe that is the downside of deleting indices based on usage.
: It only shows what's been used during the observation. That implies a
: bad assumption that the usage is completely stable. To me, this seems
: worse than just dropping an index and seeing who screams, since when
: there is a problem in the future, you have to go through an entire
: performance tuning workup because the linkage to the act of dropping
: the index is obscured. Maybe I'm missing the concept. What about an
: index that would be used when you pass some tipping point or boundary
: condition or upgrade or change a session parameter?

You can disable an index. That way the definition exists but the index is
never used or maintained (i.e. no overhead). If you decide it is needed
you simply enable it.

"when you pass some tipping point"

If an index is enabled then presumably it will only be used when the CBO
decides it is useful for a query.

"Malcolm Dew-Jones" <yf110@vtn1.victoria.tc.ca> schreef in bericht
news:48091a22$1@news.victoria.tc.ca...
> joel garry (joel-garry@home.com) wrote:
> : On Apr 18, 2:29=A0am, Andreas Mosmann <mosm...@expires-30-04-2008.news-
> : group.org> wrote:
> : > Thank both of you,
> : >
> : > I will try it out.
> : > Is there also a way to determine what index is still needed/useful for
> a
> : > special query?
> : >
> : > Andreas Mosmann
> : >
> : > --
> : > wenn email, dann AndreasMosmann <bei> web <punkt> de
>
> : I do believe that is the downside of deleting indices based on usage.
> : It only shows what's been used during the observation. That implies a
> : bad assumption that the usage is completely stable. To me, this seems
> : worse than just dropping an index and seeing who screams, since when
> : there is a problem in the future, you have to go through an entire
> : performance tuning workup because the linkage to the act of dropping
> : the index is obscured. Maybe I'm missing the concept. What about an
> : index that would be used when you pass some tipping point or boundary
> : condition or upgrade or change a session parameter?
>
> You can disable an index. That way the definition exists but the index is
> never used or maintained (i.e. no overhead). If you decide it is needed
> you simply enable it.
>
> "when you pass some tipping point"
>
> If an index is enabled then presumably it will only be used when the CBO
> decides it is useful for a query.
>

But an index may become useful over time, true?

Shakespeare

joel garry wrote:

> I just don't get it. This looks like a feature capriciously useful
> for poorly implemented systems.
>
> jg

In many cases you are correct. But that does not decrease the value
of the tool. It is just that the tool, like all tools, requires some
application of a synapse or two.
--
Daniel A. Morgan
Oracle Ace Director & Instructor
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

Shakespeare wrote:

> But an index may become useful over time, true?
>
> Shakespeare

On that basis alone one could justify putting an index on every
column of every table so I will respectfully disagree unless you
write a very broad definition of "may."

You need to understand your data and how it is being accessed.
The extra overhead of an unused index is not value added.

My recommendation would be to use the DBMS_STATS.SET.... procedures
to see how queries will react to the expected future growth of both
tables and indexes.
--
Daniel A. Morgan
Oracle Ace Director & Instructor
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

"DA Morgan" <damorgan@psoug.org> schreef in bericht
news:1208624947.696580@bubbleator.drizzle.com...
> Shakespeare wrote:
>
>> But an index may become useful over time, true?
>>
>> Shakespeare
>
> On that basis alone one could justify putting an index on every
> column of every table so I will respectfully disagree unless you
> write a very broad definition of "may."
>
> You need to understand your data and how it is being accessed.
> The extra overhead of an unused index is not value added.
>
> My recommendation would be to use the DBMS_STATS.SET.... procedures
> to see how queries will react to the expected future growth of both
> tables and indexes.
> --
> Daniel A. Morgan
> Oracle Ace Director & Instructor
> University of Washington
> damorgan@x.washington.edu (replace x with u to respond)
> Puget Sound Oracle Users Group
> www.psoug.org

I was aiming at data with for example a 'year' column. This column could be
indexed by design, but in the first year (all records same value) this index
is not useful and won't be used. But on the first entry in the second year
it is useful to find entries of that year and so on. A script to remove or
disable unused indexes would remove/disable this index in the first year.

Shakespeare