When processes use the shared tables performance is likely to be degraded by contention on the table. The %TruncateTable() PeopleCode macro generates a DELETE by process instance on the shared table instead of a TRUNCATE command.
The problem is that unless you look in the message log, you will not know that this is happening. However, it easy to write a query that will look at the message log table and report whenever this has occurred.
select p.message_parm recname, r.prcsname , count(*) occurances , max(l.dttm_stamp_sec) last_occurance , max(p.process_instance) process_instance from ps_message_log l , ps_message_logparm p left outer join psprcsrqst r on r.prcsinstance = p.process_instance where l.message_set_nbr = 108 and l.message_nbr = 544 and p.process_instance = l.process_instance and p.message_seq = l.message_seq and l.dttm_stamp_sec >= sysdate - 7 group by p.message_parm, r.prcsname order by 1,2 /
This report tells you which programs failed to allocated instances of which record, how many times that has happened within the last 7 days.
Processes Unable to Allocate Non-Shared Temporary Record Last Record Process Last Process Name Name Occurrences Occurrence Instance --------------- ------------ ----------- ------------------- ---------- TL_ABS_WRK TL_TIMEADMIN 4 08:24:39 01/01/2009 12345 TL_ATTND_HST1 TL_TIMEADMIN 10 08:23:40 01/01/2009 12345 TL_COMP_BAL TL_TIMEADMIN 11 08:23:40 01/01/2009 12345 ...
NB: Just because an Application Engine could not allocate a non-shared table, does not automatically imply that you need more instances of that record. It could be that other processes had failed, but the temporary tables are still allocated to the process until the process is either restarted and completes successfully, or the process is deleted or cancelled.
You might choose to create some spare instances of records to allow for failed processes, but if you do not clear failed processes you will eventually run out of instances.