Re: Index vs. table scans in statspack reports

The object isn't hot, it's a specific block from the object. If you haven't got the root block bug, then the block could
be from a very small object that is accessed very frequently, or a block which is the leading edge of a table or index which is 'the most current block' of that object. You need to spot the object, and decide why one block from it might be of extreme interest.

Solutions are then business/application dependent, but could include rebuilding a table with a very large pctfree to minimise the rows per block hence spread the accesses across multiple blocks; turn an indexed table into a single table hash cluster to eliminate index lookup contention, and so on.

-- 
Regards

Jonathan Lewis
http://www.jlcomp.demon.co.uk

  The educated person is not the person
  who can answer the questions, but the
  person who can question the answers -- T. Schick Jr


One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html


Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html
____UK___November


The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html


"Rick Denoire" <100.17706_at_germanynet.de> wrote in message
news:btujsvk55tugpetqvk6134jgvae22rpgv1_at_4ax.com...


> "Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote:

>

> >This may give you a clue about the object that is

> >the hot object.  A high touch count (tch) means heavy

> >use.  The OBJ column maps to the data_object_id in

> >dba_objects (or  dataobj#  in sys.obj$ if you want a

> >less expensive check).

>

> What could I do then with the hot object? Difficult to split into

> different disks...

>

> Bye

> Rick Denoire