Re: SQL causing 100% CPU utilization
Date: Fri, 6 May 2011 10:56:08 -0700 (PDT)
Message-ID: <7a2ab206-b8eb-4ff6-984b-ae00e1fb793e_at_34g2000pru.googlegroups.com>
On May 5, 11:38 am, "Gerard H. Pille" <g..._at_skynet.be> wrote:
> joel garry wrote:
> > As David said, post the sql and plan. I smell full table scans
> > thrashing through the sga, hogging the cpu.
>
> Don't trust your nose, Gary, full table scans don't get into the SGA.
May have nothing to do with the OP, but http://jonathanlewis.wordpress.com/2011/03/24/small-tables/ and related links is the kind of thing I had in mind.
Taking a quick gander at one of my systems, I see an index fast full scan, only getting rowid for 5 rows out of 200K, cpu cost 44670240, I/ O cost 427, briefly pounding the hell out of a cpu. Before I changed the code, it did a full table scan, pounding the cpu harder for a shorter time, IIRC. It's the type of query that has a nullable column in the middle of a five column key that is not part of the query and the last column is a date and I'm getting > an arbitrary date and the rest of the key is specified. I'm wondering if it would make a difference if I specified it as a primary key. (Other priorities is why I haven't simply tried it yet, load testing is problematic).
jg
-- _at_home.com is bogus. If you thought breaking up by text message was bad... http://www.signonsandiego.com/news/2011/may/06/motorola-mobility-keep-headquarters-illinois/Received on Fri May 06 2011 - 12:56:08 CDT