Re: How to trace what is happening inside the stored procedure

> What, from 32 bytes? In this day and age of multi-Gb memories even in PC=
> 's?

Well, the structure containing session information is a fixed array as far as I know, with fixed data element offsets, so you need to pre-allocate the max amount of memory needed for for all elements, for each session record, so in large number of sessions this might take several(tens) of megabytes.

Yep, I don't argue with you, memorywise it's nothing in todays servers, but trying to understand, why Oracle has gone with such figures - for old-school low-level kernel developers in Oracle this 32 and 48 bytes may have seemed to be more than enough, because historically they have done well with less than 10 byte abbreviated variable and function names in kernel (like ksusegst, ksmsp, kglob, ktuxe etc..).

Another reason why keeping these structures small I can think of is that if your session structures start to span several virtual memory page boundaries, more soft page faults will occur and since these structures are accessed quite often, it might mean more CPU usage due VM engine servicing in systems using small pagesizes such 4kB. I think this is unlikely the reason, since additional CPU usage will be marginal, especially with modern CPUs with more usable TLB cache slots and large pagesizes, but the point is that it's sometimes about more than just memory usage, but also memory usage performance.

Tanel.

--
http://www.freelists.org/webpage/oracle-l