Performance problem on a table with zero rows
I queried the v$sqlarea table to find which SQL statement was doing the most disk reads and it turned out to be a query that read 278 Gigabytes from a table which usually has zero rows. This query runs every minute and reads any rows that are in the table. It does not do any joins. The process then processes the rows and deletes them from the table. Over the course of a day, a few thousand rows may be processed this way with a row length of about 80 bytes. This amounts to a few kilobytes, not 278 Gig over a couple of days. Buffer gets were even higher at 295 Gig. Note that only the query that reads the table is doing these disk reads, not the rest of the process.
There are no indexes on the table, so a full table scan is done. The query reads all the rows, but usually there are zero. I checked the size of the table in dba_segments, and it was 80 Meg. At one point months ago, during a load, the table had 80 Meg of data in it, but this was deleted after being processed. The size of the table was never reduced.
I can only assume that Oracle is doing a full table scan on all 80 Meg of this table every minute. Even when there are zero rows. Dividing the buffer gets in bytes by the number of executions yields 72 Meg which is close to the table size. Oracle is reading the entire table size from disk even when the table has zero rows.
The solution was to truncate the table. This helped immediately and reduced the disk reads to zero most of the time. The buffer gets were also reduced to 3 per execution when the table was empty. The automatic segment manager reduced the size of the table to 64k overnight.
Our buffer cache hit ratio was a dismal 72%. It should go up now that this problem has been resolved.
Table statistics are gathered every week. We are running Oracle 9.2 on Solaris.
Note that this problem is already resolved. I post it because it is an interesting case.
Kevin Tyson, OCP
DaimlerChrysler Tech Center, Auburn Hills, MI