Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!postnews.google.com!c28g2000cwb.googlegroups.com!not-for-mail From: "Mark D Powell" Newsgroups: comp.databases.oracle.server Subject: Re: Connection between library cache latches and statistics? Date: 10 Oct 2006 07:41:27 -0700 Organization: http://groups.google.com Lines: 49 Message-ID: <1160491287.719432.319560@c28g2000cwb.googlegroups.com> References: <1160485686.081819.59340@k70g2000cwa.googlegroups.com> NNTP-Posting-Host: 192.85.50.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1160491293 13821 127.0.0.1 (10 Oct 2006 14:41:33 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 10 Oct 2006 14:41:33 +0000 (UTC) In-Reply-To: <1160485686.081819.59340@k70g2000cwa.googlegroups.com> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322),gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: c28g2000cwb.googlegroups.com; posting-host=192.85.50.2; posting-account=J7QqBQwAAABTieek3RP_669Gs2iATWzr Xref: dp-news.maxwell.syr.edu comp.databases.oracle.server:276927 On Oct 10, 9:08 am, "Dusan Bolek" wrote: > I'm encountering a strange problem. We're suffering from terrible > library cache latches (30-50% of waits in statspack reports) when > table's stats being older than two business days. I do not understand > why, because the affected tables are only slowly changing and I can't > imagine any possible connection between stats too old and library latch > waits. > > Any ideas? > > Database: 9.2.0.7 EE 64bit Itanium > -- > Dusan Bolek Dusan, are the library waits only happening in relation to a small set of tables? If so, do many of the queries on these tables query against values that are on the leading edge of the value creation pattern. That is, are the queries looking for values that did not exist two days ago but which currently exist possibly in significant quantities. I have seen posts about problem plans where there were values outside the range that existed when the statistics were generated. It wouldn't take but one or two heavily concurrently used queries that were subject to a plan shift perhaps from indexed to full scan access (maybe as part of hash or sort/merge join) to potentially result in library cache contention. If the latch contention is resulting in a performance problem then if you do not have any real clues to the problem source I would just take a look for the heavy logical IO SQL's and I would check the parse statistics to make sure no one added an application that is issuing a lot of non-bind SQL. I trace a SQL Server based connection to our DB once where the task read 100,000 parts from our part master table then issued 100,000 selects against the part master using a constant obtained in the first query for the part number. Every nearly identical statement is hard parsed since no bind variable is used. What is worse is that the queries get only the part description which could have been retrieved on the first query. But the vendor told me the application could not be changed. So another thing to look for is nearly identical SQL but with constants where a bind variable should be. Unfortunately I have no experience with 9.2.0.7 so I do not know if there are any .7 related issues that might be in play. Good luck -- Mark D Powell --