CREATE STOGROUP statement
The CREATE STOGROUP statement creates a storage group at the current server. Storage from the identified volumes can later be allocated for table spaces and index spaces.
Invocation for CREATE STOGROUP
This statement can be embedded in an application program or issued interactively. It is an executable statement that can be dynamically prepared only if DYNAMICRULES RUN behavior is in effect. For more information, see Authorization IDs and dynamic SQL.
Authorization for CREATE STOGROUP
The privilege set that is defined below must include at least one of the following:
- The CREATESG privilege
- SYSADM or SYSCTRL authority
Installation SYSOPR authority (when the current SQLID of the process is set to SYSINSTL)
Privilege set: If the statement is embedded in an application program, the privilege set is the privileges that are held by the of the owner of the plan or package. If the application is bound in a trusted context with the ROLE AS OBJECT OWNER clause specified, a role is the owner. Otherwise, an authorization ID is the owner.
If the statement is dynamically prepared, the privilege set is the privileges that are held by the SQL authorization ID of the process unless the process is within a trusted context and the ROLE AS OBJECT OWNER clause is specified. In that case, the privileges set is the privileges that are held by the role that is associated with the primary authorization ID of the process.
Syntax for CREATE STOGROUP
Description for CREATE STOGROUP
- stogroup-name
- Names the storage group. The name must not identify a storage group that exists at the current server.
- VOLUMES(volume-id,...) or VOLUMES('*',...)
- Defines
the volumes of the storage group. Each volume-id is
a volume serial number of a storage volume. The volume serial number
can have a maximum of six characters and is specified as an identifier
or a string constant.
If the data set that is associated with the storage group is not managed by Storage Management Subsystem (SMS), VOLUMES must be specified. Asterisks are recognized only by SMS. SMS usage is recommended, rather than using Db2 to allocate data to specific volumes. Having Db2 select the volume requires non-SMS usage or assigning an SMS Storage Class with guaranteed space. However, because guaranteed space reduces the benefits of SMS allocation, it is not recommended. If one or more of the DATACLAS, MGMTCLAS, or STORCLAS clauses are specified, VOLUMES can be omitted. If the VOLUMES clause is omitted, the volume selection is controlled by SMS.
If you do choose to use specific volume assignments, additional manual space management must be performed. Free space must be managed for each individual volume to prevent failures during the initial allocation and extension. This process generally requires more time for space management and results in more space shortages. Guaranteed space should be used only where the space needs are relatively small and do not change.
- VCAT catalog-name
- Identifies the
integrated catalog facility catalog for the storage group. The designated catalog is the one in
which entries are placed for the data sets created by Db2 with the aid of the storage group, for
associated table or index spaces or for their partitions. For each such space or partition,
association is made through a USING clause in a CREATE TABLESPACE, CREATE INDEX, ALTER TABLESPACE,
or ALTER INDEX statement. For more on the association, see the descriptions of those statements.
The data sets are VSAM linear data sets cataloged in the integrated catalog facility catalog that catalog-name identifies. For more information about catalog-name values, see Naming conventions in SQL.
More than one Db2 subsystem can share the integrated catalog facility catalogs with the current server. To avoid the chance of those subsystems attempting to assign the same name to different data sets, specify a catalog-name value that is not used by the other Db2 subsystems.
- DATACLAS dc-name
- Identifies the name of the SMS data class to associate with the Db2 storage group. The SMS data class name must be from 1-8 characters in length. The SMS storage administrator defines the data class that can be used. DATACLAS must not be specified more than one time.
- MGMTCLAS mc-name
- Identifies the name of the SMS management class to associate with the Db2 storage group. The SMS management class name must be from 1-8 characters in length. The SMS storage administrator defines the management class that can be used. MGMTCLAS must not be specified more than one time.
- STORCLAS sc-name
- Identifies the name of the SMS storage class to associate with the Db2 storage group. The SMS storage class name must be from 1-8 characters in length. The SMS storage administrator defines the storage class that can be used. STORCLAS must not be specified more than one time.
FL 502 KEY LABEL key-label-name or NO KEY LABEL
Specifies whether a key label is specified at the storage group level for encryption.
- KEY LABEL key-label-name
- Specifies the key label that is used to encrypt any data set allocated for the table spaces and index spaces using the storage group.
The key label must be defined in ICSF. The Db2 address space RACF user ID or group must be permitted access to the key label in RACF.
The key label can be overridden when the data set is allocated. For details about the order of precedence, see Notes.
- NO KEY LABEL
- Indicates that there is no key label specified at the storage group level for encryption.
Notes for CREATE STOGROUP
- Device types
- When the storage group is used at run time, an error can occur if the volumes in the storage
group are of different device types, or if a volume is not available to z/OS® for dynamic allocation of data sets.
When a storage group is used to extend a data set, all volumes in the storage group must be of the same device type as the volumes used when the data set was defined. Otherwise, an extend failure occurs if an attempt is made to extend the data set.
- Number of volumes
- There is no specific limit on the number of volumes that can be defined for a storage group.
However, the maximum number of volumes that can be managed for a storage group is 133.
z/OS imposes a limit on the number of volumes that can be allocated per data set (currently, 59 volumes). For the latest information on that restriction, see z/OS DFSMS Access Method Services for Catalogs.
- Storage group owner
- If the statement is embedded in an application program, the owner of the plan or package is the owner of the storage group. If the statement is dynamically prepared, the SQL authorization ID of the process is the owner of the storage group. The owner has the privilege of altering and dropping the storage group.
- Specifying volume IDs
- A new storage group must have either specific volume IDs or non-specific volume IDs. You cannot create a storage group that contains a mixture of specific and non-specific volume IDs.
- Verifying the existence of volumes and classes
-
When processing the VOLUMES, DATACLAS, MGMTCLAS, or STORCLAS clauses, Db2 does not check the existence of the volumes or classes or determine the types of devices that are identified or if SMS is active. Later, when the storage group allocates data sets, the list of volumes is passed to Data Facilities (DFSMSdfp) in the physical order of the rows in the SYSIBM.SYSVOLUMES catalog table. For more information, see Implementing Db2 storage groups.
- Key label requirement
- To use a key label for encryption, the VSAM data sets for the page sets need to be associated with an SMS Data Class that has extended format capability (EF enabled).
Determining a key label for base table space and associated objects
When a key label is specified at the table level, Db2 provides the key label to DFSMS to encrypt all the table spaces and index spaces associated with the table. This includes base table space, auxiliary table spaces, XML table spaces, index spaces, and clone table space, regardless of whether the base table space or associated objects are explicitly or implicitly created. Db2 does not enforce any key label relationship between the base table and an associated history or archive table. The key label for the archive and the history tables has to be set independent of the base table. If there is no key label specified at the table level, Db2 will provide the key label to DFSMS specified for the storage group.
When Db2 calls DFSMS to allocate the dataset for table space or index space, DFSMS uses its order of precedence to determine the key label and can override the key label specified by Db2.
DFSMS order of precedence:- RACF® data set profile
- JCL, dynamic allocation, TSO ALLOCATE
- SMS data class construct
If the security administrator has specified a key label for the RACF data set profile, that key label takes precedence over the Db2 provided key label. The REPORT utility can be run to determine the key label used for encryption.
Examples for CREATE STOGROUP
- Example 1
- Create storage group, DSN8G120, of volumes
ABC005 and DEF008. DSNCAT is the integrated catalog facility catalog name.
CREATE STOGROUP DSN8G120 VOLUMES (ABC005,DEF008) VCAT DSNCAT;
Example 2
Create storage group DSNCG100 with key label, STG01KLABEL.
CREATE STOGROUP DSNCG100 VOLUMES (ABC001,DEF003) VCAT DSNCAT KEY LABEL STG01KLABEL;