Re: BAMIMA:Bam Buffer

Rau

I've seen exactly the same issues. In addition to upgrading as Norman suggests you could try setting the init.ora parameter CURSOR_SHARING=FORCE. Take a look at issues (in metalink) first though in case you're going to hit one of the few gotchas left in 8.1.7.4 - there are loads of problems with this setting in 8.1.7.0 to .3 so don't use it till you've upgraded unless you're either a) very brave b) very foolish or c) very desperate.

As for why it happens - I think the SQL is aged out but the "holes" left by these statements are scattered throughout the SGA and are of different sizes (due to the usually different length of SQL strings when constructing SQL with literals in the predicates) and so you end up with a highly fragmented SGA where there is lots of free space but it's all in pieces to small to fit the statement you want into. Someone on the list might correct me here if I'm wrong.

Andy

"Ray Teale" <ray_at_BLAHholly.com.au> wrote in message news:DruEb.74$g21.2793_at_nnrp1.ozemail.com.au...
> Version : 8.1.7.0.0
> Sun Solaris 2.8
>
> I'm getting the old BAMIMA:Bam Buffer error regularly on my database.
> I have tried pinning packages to no avail. I have also increased the size
> of the shared pool size and it is now three times the initial size (About
> 300M). All that is happening is that it is taking longer between
failures.
>
> I suspect that the application which is using the database may have a lot
of
> dynamic SQL. I'm wondering if this might be an issue as the dynamic
> statements do not have bind variables.
>
> I'm confused about the error because I thought select statements would be
> aged out rather than the shared pool run out of memory.
>
> Can anybody shed light?
>
> Regards
>
> Rau
>
>
>
Received on Fri Dec 19 2003 - 02:49:15 CST