Hi Purav, you may want to ensure that you don't have too many versions of the same SQL in the Library Cache. So-called version count issues are the most common issue when shared pool grows. A count of entries in v$sql and group by sql_id, is the most simple check. More insight allows v$sql_shared_cursor Best regards Martin Purav Chovatia schrieb: > Hi, > We have a 10205 database on Solaris SPARC with ASMM enabled and sga_target > & sga_max_size = 4G. What we observe is that shared_pool has grown from > 700MB to 1.6GB in last 3 months whereas buffer cache has shrunk from 3.3G > to 2.5G. This inspite of the database having to do physical reads i.e some > of the hot objects not fitting in the buffer cache. > What could be the reason? > How do I find what is the breakup of the so big shared pool? (There are no > bind variable issues) > > Thanks. > > > -- > //www.freelists.org/webpage/oracle-l > > > -- Usn's IT Blog for Linux, Oracle, Asterisk http://www.usn-it.de -- //www.freelists.org/webpage/oracle-l