unfortunately I can't see on what SAP release you are running. I don't understand what you are meaning with DEV (3 instances). Do you really use 3 instances to the system DEV ? Where is this good for ?
But there are 2 major parts in temp storage: a) the SAP buffers, extended memory ... that you can see on ST02 b) the storage that every WP needs for it's ODPs
to a) The top-part of ST02 (Buffer) has mostly defined about 1-2 GB storage that are allocated just after start of SAP without any user logged on. The bottom part (SAP memory) is now very different. The most interesting figure is the Extended Memory and there "In memory". This is the storage that can be used as maximum for the extended memory. Up to 4.5B this is allocated dynamically. So, you can setup up to the maximum of 8 GB and it only uses the storage it needs. This will increase when more user log on. When you are using 4.6x this is pre-allocated storage. The complete storage that is defined in "in memory" will be already allocated at the start of SAP even when no user logged on. So then it is useful to set this to a useful value. It is recommended to abserve the "Max. use" and set it that way that normally after a few days system-run the "Max. use" is about 80% of the "In memory".
to b) Every WP uses up to 1200 ODPs (open data pathes). Each ODP consumes 30-300 KB. Our experience is that this is mostly 300 KB. As there are only a few ODPs at the startup of SAP and this increases while the system stays up, the storage increases over the time the system is active. The 1200 ODPs is set because of performance reasons. You have to possibilities in order to reduce this part of memory: 1) Cycle your WPs some times (e.g. every 24 hours, without restarting SAP!) as described in note 182207. Then every time the WPs restart themselves they clean the ODPs up to 0 as they die and are getting restarted. 2) Reduce the maximum amount of ODPs with the following instance-parameter: Standard (default): dbs/db4/odp_threshold =1200 dbs/db4/odp_commit_threshold =1210 dbs/db4/odp_open_threshold =1250
Useful reduction: dbs/db4/odp_threshold =800 dbs/db4/odp_commit_threshold =810 dbs/db4/odp_open_threshold =850 (When you reduce this much more, this will really do have an impact on your performance!!!)
You might check option 1. Some customers are doing this and say that there are no performance impacts but big reductions in temp-storage. But as I said: Don't complain about performance afterwards!
> -----Original Message----- > From: Robert Morin [mailto:Robert.MorinZF...] > Sent: Freitag, 5. Januar 2001 00:05 > To: Sap400ZMag. Linz. At (E-mail) > Subject: What is Temporary Storage Explanation > > > Hello people, > > First thing first: > > I hope the new year brings everybody new hope, patience and > happiness in > this wonderful career of IT that we so carefully selected > > Now to the point: > Can someone explain to me the following questions. > We just finish our initial production roll out on of our > production machine. > We roll-out only the CS (customer file) with 4 user's as a > pilot. Now on our > PRODUCTION box, the temporary storage used for our minimum > process at the > time of writing this was > Subsystem: R3_00 Job: *ALL Temporary storage: > 4,156,416 KB. > > So you can imagine that our DEV (3 instance) & QA (2 > instance) environment > which are on the same box with at it's peek 3 programmer and > 3 power user. > Now my temporary storage is > Subsystem: R3_00 Job: *ALL Temporary storage: > 6,397,952 KB. > Subsystem: R3_01 Job: *ALL Temporary storage: > 4,411,392 KB. > > My manager would like to know and so would I. Is there an > explanation or a > formula that will explain theses numbers as we roll-out more > user's and > module what type of increase can we expect? Is there a way to > control the > utilization of the Qtemp in SAP? > > So many questions so little time. > > Robert Morin > >