You must calculate the approximate storage requirement for the extended common service area (ECSA).
Before you begin
Determine the values of the following subsystem parameters for use in the calculations:
Procedure
- To estimate storage that is needed for ECSA (above the 16-MB line) for each local Db2 subsystem, use the following calculations:
- Start with 5 MB of ECSA for the base.
- Add 4 KB for each user. You can use (MAXDBAT-value + CTHREAD-value) × 4 KB.
- Add 5 MB for each IRLM subsystem.
Each IRLM subsystem uses 4 - 5 MB of ECSA when no workload is active and the default trace settings are used. As the workload increases, the ECSA use in IRLM for locking might also increase, depending on the type of requests processed by IRLM.
For example, if a workload processes a large number of queries or notifies through IFI calls, the ECSA increases depending on the number of locks held, number of threads, number of members in the data sharing group, and so forth. When multiple IFI requests run concurrently,the ability of IRLM to reuse and or release the ECSA storage is reduced. In such scenarios, the ECSA usage by IRLM might go up to 10 MB.
- If optional tracing is used for IRLM with the TRACE parameter, add memory for the IRLM optional trace buffers:
- If TRACE=YES is used, add 1.3 MB.
- If TRACE=n is used, where n is the number of optional trace buffers, add 512 × n KB.
- Add at least 8 MB, and as much as 50 MB, for the instrumentation facility interface (IFI), for IFI buffers as requested by monitoring programs and the standard trace classes for accounting (1, 2, 3, 7, and 8) and statistics (1, 3, 4, 5 and 6).
If Db2 encounters a shortage of ECSA storage for IFI processing, Db2 can continue processing threads, but trace records might be lost until the ECSA shortage is resolved.
Traces that are likely to increase the storage requirement above the 8 MB minimum include: IFCID 003 or IFCID 148 with more than 10 active buffer pools (or group buffer pools), IFCID 124 (SQL statement text), IFCID 199 (Buffer pool stats), and others.
- If you use the distributed data functions of Db2 (DDF), you might find that you need more virtual storage. You can estimate how much your storage needs are likely to increase in the ECSA above the 16-MB line by adding the following amounts:
- Add 2.5 MB for the code that relates to distributed processing
- Add 1 KB for each SNA network connection. In z/OS 2.2 or later, TCP/IP connections use zero ECSA storage.
However, if you are uncertain of how many concurrent SNA connections you might have, or if you operate with z/OS 2.1 or earlier, use the CONDBAT subsystem parameter value.
- Add 2 KB for each thread that uses distributed processing. You can use MAXDBAT-value × 2 KB.
- Add 1 KB for each requesting system that is listed as a TCP/IP address or SNA LU name in the communication database of the Db2 subsystem. You do not need to count the number of connections between Db2 and the requesting systems.
What to do next
Specify this sum or a value that is larger than this sum as the second value of the CSA parameter of the IEASYSxx z/OS logical PARMLIB member. The logical PARMLIB is usually referred to as SYS1.PARMLIB. Specifying values that are too high is preferable to specifying values that are too low; making your values too low can result in a need to IPL z/OS. For example, if the ECSA size is too small, z/OS places the Db2 global load modules and control blocks for Db2 in CSA below the 16-MB line instead of above it. This can cause problems with coexisting z/OS subsystems.
Distributed threads are represented by z/OS SSRB control blocks that reside in the extended system queue area (ESQA) when they are paused. The amount of storage that is used might vary depending on the z/OS release that is used. Estimate 4 KB of ESQA for every active distributed thread. You can use MAXDBAT-value × 4 KB.