ALTER STOGROUP statement
The ALTER STOGROUP statement changes the description of a storage group at the current server.
Invocation for ALTER 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 ALTER STOGROUP
The privilege set that is defined below must include one of the following:
- Ownership of the storage group
- 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 owner of the package. If the statement is dynamically prepared, the privilege set is the union of the privilege sets that are held by each authorization ID and role of the process.
Syntax for ALTER STOGROUP
Description for ALTER STOGROUP
- stogroup-name
- Identifies the storage group to be altered. The name must identify a storage group that exists at the current server.
- ADD VOLUMES(volume-id,...) or ADD VOLUMES('*',...)
- Adds
volumes to the storage group. Each volume-id is
the volume serial number of a storage volume to be added. It can have
a maximum of six characters and is specified as an identifier or a
string constant.
A volume-id must not be specified if any volume of the storage group is designated by an asterisk (*). An asterisk must not be specified if any volume of the storage group is designated by a volume-id.
You cannot add a volume that is already in the storage group unless you first remove it with REMOVE VOLUMES.
Asterisks are recognized only by Storage Management Subsystem (SMS). If the data set that is associated with the storage group is non SMS managed, either ADD VOLUMES or REMOVE VOLUMES must be specified. Neither ADD VOLUMES or REMOVE VOLUMES is required if DATACLAS, MGMTCLAS, or STORCLAS is specified. 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 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.
- REMOVE VOLUMES(volume-id,...) or REMOVE VOLUMES('*',...)
- Removes
volumes from the storage group. Each volume-id is
the volume serial number of a storage volume to be removed. Each volume-id must
identify a volume that is in the storage group.
The REMOVE VOLUMES clause is applied to the current list of volumes before the ADD VOLUMES clause is applied. Removing a volume from a storage group does not affect existing data, but a volume that has been removed is not used again when the storage group is used to allocate storage for table spaces or index spaces.
Asterisks are recognized only by Storage Management Subsystem (SMS). If the data set that is associated with the storage group is non SMS managed, either ADD VOLUMES or REMOVE VOLUMES must be specified. Neither ADD VOLUMES or REMOVE VOLUMES is required if DATACLAS, MGMTCLAS, or STORCLAS is specified.
- 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. For the
changed KEY LABEL value to take effect, a subsequent REORG of the table spaces or indexes that use
the storage group is required.
- KEY LABEL key-label-name
- Specifies the default key label that is used to encrypt any data set allocated for the table spaces and index spaces using the storage group.
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 for ALTER STOGROUP.
- NO KEY LABEL
- Indicates that there is no key label specified at the storage group level for encryption.
Notes for ALTER STOGROUP
- Work file databases:
- If the storage group altered contains data sets in a work file database, the database must be
stopped and restarted for the effects of the ALTER to be recognized. To stop and restart a database,
issue the following commands:
-STOP DATABASE(database-name) -START DATABASE(database-name)
- 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.
If the VOLUMES clause is specified, the maximum number of volumes is 59.
- 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 in the specified order to Data Facilities (DFSMSdfp).
- SMS data set management:
- You can have Storage Management Subsystem (SMS) manage the storage needed for the objects that the storage group supports. To do so, specify ADD VOLUMES('*') and REMOVE VOLUMES(current-vols) in the ALTER statement, where current-vols is the list of the volumes currently assigned to the storage group. SMS manages every data set created later for the storage group. SMS does not manage data sets created before the execution of the statement.
You can also specify ADD VOLUMES(volume-id) and REMOVE VOLUMES('*') to make the opposite change.
For considerations for using SMS to manage data sets, 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 ALTER STOGROUP
ALTER STOGROUP DSN8G120
ADD VOLUMES (DSNV04,DSNV05);
ALTER STOGROUP DSN8G120
REMOVE VOLUMES (DSNV04,DSNV05);
ALTER STOGROUP DSNCG120
NO KEY LABEL;