Re: Shared Pool: Can it be filled *over* 100% ?

From: omlet <notrolls_at_notrolls.omlet.org.notrolls>
Date: Fri, 13 Aug 2004 08:17:07 -0400
Message-ID: <f5a1d74fd48ef2ea20f9c6aa9f15b062@localhost.talkaboutdatabases.com>

Reminding David Fitzjarrell of an earlier posting probably would be in the right place here:

Cursors kernel code have a lot of overhead: The following are the most interesting ones:

opiosq, opicca, opiexe, opifch or kernel calls kkspsc, kksumc, kkspfx, kkspin.

When you issue a simple SQL statement; the following occurs:

1- aquires shared lock;
2- creation of a kgl object;
3- pinning the name's object heap zero in shared mode

 3.1- might require checking if there is some context area that could be
used by this user, by pinning the child objects, one by one, and seeing if usable.
 3.2 release the pin locks
4- pin the parent heap zero in exclusive mode, create new child marked as not bind-qualified; lock the child kglob in breakable shared mode, release the parent pin lock, parse; release the pin lock and object lock on the child
5- bind all bind variables
6- pin parent heap zero in shared mode; check all matching children by pinning their heap zero to see if any is reusable by this user.

I cannot help help it! I have to be offensive: "do the above till Daniel's cursorit is willing and dripping; lock it in breakable-share mode. On every dip, pin in S mode; do cleanups; if the dick slips signal an error if mid-fetch;"

Now if you get an error mid-fetch your stats were updated wrongly and if the bang is too hard you certainly would get Daniel's past 100% satisfaction!

Wouldn't you!

Lil Received on Fri Aug 13 2004 - 07:17:07 CDT