If the content of DBCLOB columns keeps increasing, the requirement for compression for LOB fields becomes more urgent. 5.8 Some points of SAP LOB usage with CCMS With the SAP Computing Center Management System (CCMS), some special considerations have to be made for LOB table spaces. Here, we distinguish between DB2 V8 and DB2 9. With DB2 V8, an online REORG is not available for LOB table spaces; therefore in V8, REORG SHRLEVEL NONE must be defined for LOBs. Jobs for LOB-related REORG should be uploaded to z/OS and only submitted during a maintenance window, when the SAP system is down. Otherwise, this would result in a severe performance impact on the running SAP system. For this reason, suggested periodic REORG jobs of table spaces do not include LOB table spaces. Additionally, a V8 REORG of a LOB table space did not reclaim disk space in the underlying VSAM data set, and as a result, the number of extents remained unchanged. SAP environments have typically a large number of data sets and it is common to use the number of extents as a trigger for the REORG of table spaces. Primarily, this trigger is to minimize the risk of exhausting the maximum number of extents unexpectedly. The availability of sliding secondary extent allocation in DB2 V8 removed most of the potential for problems, and this is the default for implicitly created table spaces in V9. Changes in architecture over a period of time have rendered the performance impact of a growing number of extents to be marginal, or non-existent. A growing number of extents might, however, be an indication of performance