Count is slow

Question

When there is an insert happening in the table will there be an impact in reading the data from the table.
When there is an insert going on i just gave
Select Coun(*) from mytable
it is taking some 10-13 sec to return the count if the table size keep on growing.
is there any faster way to check the count

Answer 1

BluShadow wrote:
Ensure you have an index/primary key, and then a count(*) will often use the index instead which typically takes less I/O as there is usually less data blocks to an index than the base table.
Counter-intuitive, but this could make the count slower if the table is subject to a lot of inserts (unless the PK is based on a monotonic sequence).
A count(*) which is much slower than seems reasonable for the hardware may be spending a lot of its time reconstructing read-consistent copies of rapidly changing blocks.
When you do a tablescan Oracle starts with a read-consistent view of the segment header to identify the highwater marks for the table so that the count(*) can stop at the earliest possible moment and not have to reconstruct blocks (to empty) that were about the HWM when the query started.  (For tables with lots of space being below the HWM that is being used by the inserts this doesn't necessarily help - and there are various reasons why there might be a lot of usable space below the HWM).
When a count(*) uses an index fast full scan, the same applies - but if the key values being inserted are effectively randomly distributed (and not at the high value, as sometimes happens) then every block scanned may have to be cloned and made read-consistent.
Step 1 (for OP):  Check the execution path
Step 2: check if time required is reasonable for number of blocks that would be read if no inserts taking place
Step 3: check statistics during execution, noting particularly details of "undo records applied"
Step 4: check what read waits are occurring - multiblock from the data tablespace, or single block from the undo tablespace
Regards
Jonathan Lewis