User profiles
In a Db2® Mirror environment, all user profile objects are replicated.
- The profile being disabled because of too many invalid signon attempts.
- The EIM Association (EIMASSOC) parameter on Create User Profile (CRTUSRPRF) and Change User Profile (CHGUSRPRF).
- The previous sign on date and last used date for the user profile.
Analyze Profile Activity (ANZPRFACT)
The Analyze Profile Activity (ANZPRFACT) command can be used to disable user profiles that have not been active on a node. In the Db2 Mirror environment, users may only be active on one of the nodes. To ensure profiles are not disabled if ANZPRFACT is executed on a node where the users are not active, the command is multi-node aware and will disable profiles only if there is no activity on either Db2 Mirror node.
Create User Profile (CRTUSRPRF) and Change User Profile (CHGUSRPRF) considerations
A user profile has associated objects such as initial program, initial menu, job description, and output queue. Not all of these object types are eligible for replication. You must ensure that the objects associated with a user profile exist on both nodes so that the user profile is usable on both nodes.
Note: Changes made to system-supplied user profiles using the Reset Profile Attributes (QSYRESPA) API are made on the source node only and will not be changed on the target node. The API must be called on both nodes.
Delete User Profile (DLTUSRPRF) considerations
The DLTUSRPRF command will fail if SYSBAS is in BLOCKED state. The DLTUSRPRF command will also fail if a database IASP on the source node is either varied off or its replication state is BLOCKED, and the IASP on the target node has a replication state of TRACKING. For the command to successfully process all objects for which the user is the owner or primary group, the IASP must be varied on and performing active replication. It is recommended that DLTUSPRF should only be run when the replication state is ACTIVE for SYSBAS and all IASPs, whenever possible.
If OWNOBJOPT(*DLT) is specified on DLTUSRPRF, the owned objects will be deleted on both the source and target nodes. Before deleting a user profile, you should verify on both nodes that all the replicated and non-replicated objects that are owned by the profile should be deleted.
Restore User Profile (RSTUSRPRF) considerations
A RSTUSRPRF of all user profiles requires the node to be in restricted state. That means the replication state during the restore will be either TRACKING or BLOCKED. The RSTUSRPRF action is always processed as if the replication state is TRACKING, even if the command is run on the BLOCKED node (see Behavior of specific object types when replication state is BLOCKED). During the restore, the user profile is either created (if it does not already exist) or changed (if it exists). It will not be replicated immediately. Instead, a CRTUSRPRF or CHGUSRPRF action will be added to the Object Tracking List (OTL).
While in restricted state, in order to do a RSTUSRPRF USRPRF(*ALL) followed by a Restore Authority (RSTAUT), the RSTUSRPRF and RSTAUT must be done on the primary node where the replication state is TRACKING. This is because the RSTAUT does a Grant Object Authority (GRTOBJAUT) which is not allowed for most objects when the replication state is BLOCKED.