may not leave enough volumes with adequate free space; this could cause a REORG to fail due to lack of space. The following methods address this issue.

Use One SMS Storage Group for Each Partition

A one-volume SMS Storage Group can be defined for each partition. The ACS routine assigns to each partition its corresponding Storage Group. This method is similar to creating a DB2 defined partitioned table space, using one STOGROUP for each partition. One SMS Storage Group is defined for each DB2 STOGROUP.

The advantage of this method is strict data set placement. The DB2 administrator will have the same disk distribution as he has without SMS. The disadvantage of this method is that many SMS Storage Groups are required, and the ACS routines become more complex and dependent on DB2 table space names. For an example, see Appendix A, section A.7, “Partitioned Table Spaces Using SMS, User Distribution” on page 181.

Use One SMS Storage Group for One Partitioned Table Space

Another alternative is to have one specific SMS Storage Group for each partitioned table space. Enough volumes are assigned to the Storage Group for all the partitions. SMS distributes the partitions on those volumes. Because this Storage Group is dedicated to the table space, no other data sets are ever allocated on these volumes, practically reserving the space for this table space.

If specific volumes of the SMS Storage Group are desired, guaranteed space must be used to assign the partitions to the specific volumes.

For this situation, we do not recommend guaranteed space unless the space requirements are relatively small and static.

To use guaranteed space with DB2 defined data sets, multiple DB2 STOGROUPs are required. Each of these STOGROUP must refer to a volume of the SMS Storage Group. To avoid possible allocation or extension failures, if guaranteed space storage class is used, the storage administrator should run the DFSMShsm space management function more frequently on the set of volumes assigned to the DB2 STOGROUPs.

If SMS manages the allocation, or if user defined tablespaces are used, only one DB2 STOGROUP is required, defined with (VOLUMES "*"). The example in Figure 100 on page 172 shows a definition of such a STOGROUP. The example described in Appendix A, section A.6, “Partitioned Table Space Using SMS Distribution” on page 178 shows how to allocate a partitioned table space using this method.

6.2 User Databases

This section shows how to assign SMS classes to different types of data. For the purpose of these examples, the data has been divided into the following environments:

•Online Production Databases

•Batch Production Databases

•Data Warehouse Databases

•Development and Test Databases

Managing DB2 Databases with SMS 57

Page 78 Page 80
Page 79
Image 79
IBM 5695-DF1, 5655-DB2 manual User Databases, Use One SMS Storage Group for Each Partition
Page 78 Page 80

5695-DF1, 5655-DB2 specifications

IBM 5655-DB2 and 5695-DF1 are significant components within the IBM software ecosystem, predominantly focusing on data management and integration solutions. These offerings cater primarily to enterprise environments that require robust database management systems and associated frameworks to maintain and manipulate data efficiently.

IBM 5655-DB2 is a well-known relational database management system (RDBMS) that excels in managing large volumes of structured data. Its architecture is designed to support high availability, scalability, and performance, crucial for businesses operating in today’s data-driven world. Some of its main features include advanced indexing capabilities, support for complex queries, and dynamic workload management. Additionally, it provides strong concurrency controls, which enable multiple users to access and manipulate data simultaneously without compromising data integrity.

One of the key characteristics of DB2 is its support for various data types, including JSON and XML, making it versatile for modern applications that generate data in diverse formats. It also features robust security mechanisms to protect sensitive data, aligning with compliance standards across industries. Integration with analytics tools further allows businesses to derive insights from their data, enhancing decision-making processes.

On the other hand, IBM 5695-DF1, also known as the InfoSphere DataStage, is a powerful data integration tool that facilitates the extraction, transformation, and loading (ETL) of data from various sources to target systems. It empowers organizations to streamline their data flows, ensuring that clean, consistent information is available for analysis and operational use. Key features of 5695-DF1 include a user-friendly graphical interface that enhances developer productivity and a rich set of connectors for numerous data sources, enabling seamless data integration.

DataStage also supports real-time data integration, allowing businesses to keep their data synchronized across multiple platforms. Its parallel processing capabilities dedicatedly optimize performance, enabling organizations to handle vast datasets efficiently. It incorporates data quality tools that help in validating and cleansing data before it is used for decision-making processes.

Both IBM 5655-DB2 and 5695-DF1 are part of a broader strategy to accommodate the evolving landscape of data management. Businesses leverage these technologies to enhance their data architectures, fostering agility and competitive advantage in their respective markets. Their integration capabilities, along with a focus on security and scalability, position them as vital assets in modern enterprise environments. Whether managing critical data within a database or ensuring seamless data flow across systems, these IBM offerings provide a comprehensive approach to handling complex data challenges.
Top Page Image Contents