RE: Full Table Scan and TKPROF Output

From: Daemen, Remco <R.Daemen_at_facent.nl>
Date: Fri, 08 Jun 2001 01:53:56 -0700
Message-ID: <F001.00321C6E.20010608012857@fatcity.com>

Hi Ethan,

If selectivity is that low, try using a bitmapped index.

HTH, Remco

-----Oorspronkelijk bericht-----

Van: Post, Ethan [mailto:epost_at_kcc.com]
Verzonden: vrijdag 8 juni 2001 2:26
Aan: Multiple recipients of list ORACLE-L Onderwerp: Full Table Scan and TKPROF Output

My theory...We are running J.D. Edwards OneWorld. OneWorld allows the CNC (code word for OneWorld admin) to configure a number of job queues that check a table (the F986110) for new jobs that need to be processed. Each of these processes and occasionally a few more update, delete and select from this table almost constantly. The SQL being executed against the table uses a "WHERE" clause on 5 columns which are indexed but the selectivity is really bad, only 5 distinct values out of 100+ thousand records, so it does a full table scan. A few months ago I cached the table. At the moment the table is 100 MB and only has 30 MB of data. I will reorg it the next time we get some down time. The trouble is that I experience a lot of buffer busy waits on these processes. Also when I ran SQLTRACE it showed an almost unbelievable number of buffers read in consistent mode, way! way! larger than the size of the table. The CPU associated with these processes runs around 10% each so we are at 50% CPU even when the system is dead. Luckily they seem to take a low priority and the % CPU drops when the job kicks off, this may be because the queue is waiting on the job. My guess why CPU is 10% is that the CPU is reading all the blocks in memory a bazillion times. I can't find anything about this on the J.D. Edwards Knowledge Garden. By the way CPU time is really high also.

This is a huge performance problem for OneWorld. My proposed official "duct tape" solution is to make the table much smaller by moving the records into another table after they are more than N days old. At the moment we clean up after 90 days but I think there would be a terrific gain if we reduce it to 7 days or so, (some of this is for the benefit of folks on the JDELIST, sorry I'm gonna cross-post).

Am I missing anything? Are there any other solutions to this dilemma?

Thanks,
Ethan Post

--

This e-mail is intended for the use of the addressee(s) only and may contain privileged, confidential, or proprietary information that is exempt from disclosure under law. If you have received this message in error, please inform us promptly by reply e-mail, then delete the e-mail and destroy any printed copy. Thank you.

==
--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Post, Ethan
INET: epost_at_kcc.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message

to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Daemen, Remco
INET: R.Daemen_at_facent.nl

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message