242 LOBs with DB2 for z/OS: Stronger and Faster
variables. From the point of view of DB2 LOB materialization, application A, application B, and
application C do not materialize the LOB in DB2 virtual storage when they only select a LOB
value. See Figure 8-2.
Figure 8-2 LOB Materialization In user address space in case of data retrieval
Application A uses a locator and might just use the space it needs for the chunks of data
pointed to through the defined locator. Application B might require the complete LOB data.
Therefore, the private user address space might require, based on the size of the LOB, a
huge amount of storage. Application C uses LOB file reference variables, eliminating any
need to allocate any kind of variable for storing chunks of the LOB in its local address space.
If you have applications in a distributed environment selecting LOB values through the
network, they involve the DB2 DDF address space. You can minimize the server’s storage
consumption by utilizing the DRDA flow optimization functionality. See 4.3, “DRDA LOB flow
optimization” on page 81.
If you use stored procedures, the selected LOB data is not materialized within a DBM1
address space. Stored procedures use LOCATORs and move the data in small chunks from
disk through the stored procedure address space.
Assume a scenario where your application A and application B INSERT into your LOB table
space. From the point of view of materialization, the picture is different. Now there are space
allocations in virtual storage involved. The materialization in DB2 virtual storage occurs if you
are using LOCATORs, and it probably does not occur if you use other techniques. However,
not using LOCATORs, like in application B, causes you to require more storage in your private
user address space, and depending on the size of your LOB, this could consume a large
amount of storage. See Figure 8-3 on page 243.
DB2 DBM1 Address
DB2 DBM1 Address