Home » RDBMS Server » Performance Tuning » Measuring the impact of indexes?
Measuring the impact of indexes? [message #172239] Mon, 15 May 2006 12:12 Go to next message
robhulse
Messages: 35
Registered: November 2005
Member
Hi Everyone,
I have recently been asked the question;
How would you measure the impact of indexes?
Could anyone please explain this to me or point me to an online document that I may not have seen.
Any help would be much appreciated
Thanks
Re: Measuring the impact of indexes? [message #172242 is a reply to message #172239] Mon, 15 May 2006 12:16 Go to previous messageGo to next message
Frank Naude
Messages: 4579
Registered: April 1998
Senior Member
This might help - http://www.orafaq.com/faq/virtual_indexes
Re: Measuring the impact of indexes? [message #172524 is a reply to message #172239] Wed, 17 May 2006 01:35 Go to previous messageGo to next message
raji_kb02
Messages: 19
Registered: March 2006
Junior Member
But virtual index in undocumented and unsupported feature. Searched for NOSEGMENT in create index documentation. I didn't find anything related to NOSEGMENT. It is available with tuning pack.
Re: Measuring the impact of indexes? [message #172570 is a reply to message #172239] Wed, 17 May 2006 04:21 Go to previous message
Mahesh Rajendran
Messages: 10707
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
It is undocumented but supported and widely known feature available only in tuning pack.
>>How would you measure the impact of indexes
The OP needs to provide more information here.
By impact i assume only performance on queries are taken into context here.
Impact on performance depends on available statistics,volume/distribution of data and the application code.
One can first monitor the index usage. See whether it is been used.
Other method is to simulate something by tweaking statistics/hints ( may or may not
be effective always.Because still the CBO is what that decides).

-- table EMP has 458752 records.
-- Just a regular primary key on EMPNO.
-- As expected, we get a unique scan, with just 4 logical i/o
-- 
scott@9i > select * from emp where empno=10000;

Elapsed: 00:00:00.37

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=79)
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'EMP' (Cost=3 Card=1 Byte
          s=79)

   2    1     INDEX (UNIQUE SCAN) OF 'PK_EMPNO' (UNIQUE) (Cost=2 Card=
          458752)

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          4  consistent gets
          0  physical reads
          0  redo size
        948  bytes sent via SQL*Net to client
        655  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
--
-- Now let us ask CBO not to use the index
-- Elapsed time increases
-- INdex is not used. 2000 more LIO
--
scott@9i >  select /*+ NO_INDEX(emp pk_empno) */ * from emp where empno=10000;

Elapsed: 00:00:00.96

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=261 Card=1 Bytes=79)
   1    0   TABLE ACCESS (FULL) OF 'EMP' (Cost=261 Card=1 Bytes=79)

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


--
-- Drop this unique index and create a non-unique
--
scott@9i > alter table emp drop constraint pk_empno;

Table altered.

Elapsed: 00:00:00.76
scott@9i > create index EMP_EMPNO on emp(empno);

Index created.

Elapsed: 00:00:06.14
scott@9i > @gather_table_stats;
Enter value for table_name: EMP

PL/SQL procedure successfully completed.

Elapsed: 00:00:30.04


--
-- Very minimal increase in LIO.
-- But may produce a different plan using a range scan.
--
scott@9i >  select * from emp where empno=10000;

Elapsed: 00:00:00.38

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1 Bytes=79)
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'EMP' (Cost=4 Card=1 Byte
          s=79)

   2    1     INDEX (RANGE SCAN) OF 'EMP_EMPNO' (NON-UNIQUE) (Cost=3 C
          ard=1)
Statistics
----------------------------------------------------------
          7  recursive calls
          0  db block gets
          7  consistent gets
          0  physical reads
          0  redo size
        948  bytes sent via SQL*Net to client
        655  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

--
-- Let us trick the CBO now.
-- Now CBO thinks there is only 10 distinct rows in table
-- and decides not to use the index.
--

scott@9i > exec dbms_stats.set_column_stats('SCOTT','EMP','EMPNO',distcnt=>10);

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.28
scott@9i >  select * from emp where empno=10000;

Elapsed: 00:00:00.93

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=261 Card=45875 Bytes
          =3624125)

   1    0   TABLE ACCESS (FULL) OF 'EMP' (Cost=261 Card=45875 Bytes=36
          24125)

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

Previous Topic: Tuning without the knowledge of what it is
Next Topic: RAM Tuning
Goto Forum:
  


Current Time: Fri Apr 26 13:02:20 CDT 2024