Any grants or revokes for the ACID used to run the Catalog Synchronization Utility is rejected by DB2. This is because DB2 does not allow users to grant privileges to, or revoke privileges from, themselves. We therefore suggest that you create a special ACID used only for running the Catalog Synchronization Utility and add an EXCLUDE USER synchronization control statement in TSDB2SY2 for that ACID. We recommend that you assign these privileges to the ACID:
A synchronization of all users and all resources might take a lengthy amount of time to execute and use a significant amount of system resources. To improve the performance of your synchronization, consider including only DB2 users instead of all users. You can use the INCLUDE and EXCLUDE synchronization control statements to accomplish this. If DB2 authorizations are only PERMITted to profiles, then use the PROFILE control statement as the means for selecting users for synchronization.
When running a larger synchronization, consider dividing it into smaller synchronizations. This reduces the amount of system resources required for the synchronization, makes it easier to schedule, and easier to restart in case of a system outage.
The following section provides a few suggestions on how to divide a large synchronization.
PUBLIC is a special authorization ID in DB2 which lets you grant a resource privilege to all users. The Catalog Synchronization Utility provides you with two methods of identifying and granting privileges to the PUBLIC authorization ID.
The first method indicates that resources which are PERMITted to the ALL record will produce GRANT TO PUBLIC SQL statements when that resource and user PUBLIC are explicitly included for synchronization (USER(PUBLIC) or USER(*)).
For example, in CA Top Secret you make the following authorization:
TSS PER(ALL) DB2TABLE(SYSIBM.) ACC(SELECT)
Next, you create synchronization control statements:
INCLUDE USER(PUBLIC) INCLUDE TBL(SYSIBM.*)
As a result, the following GRANT statements are generated:
GRANT SELECT ON TABLE SYSIBM.SYSDBASE TO PUBLIC;
GRANT SELECT ON TABLE SYSIBM.SYSTABLES TO PUBLIC;
GRANT SELECT ON TABLE SYSIBM.SYSPLAN TO PUBLIC;
.
.
.
User PUBLIC is always included for synchronization. It is included explicitly by you, or implicitly by the system. The difference between them is whether the authorizations in the ALL record are used. To avoid REVOKEs being generated for PUBLIC for an included resource, it is suggested that you explicitly indicate:
INCLUDE USER(PUBLIC)
The second method indicates that a PUBLIC file containing GRANT TO PUBLIC statements can be used to identify which resource privileges you want GRANTed to PUBLIC. This method can be used in addition to or in place of the first method described. If it is used in place of the first method, PUBLIC is reported as being included by the system and any privileges permitted to the ALL Record is ignored. This method is useful when you PERMIT general resource privileges to the profiles of all DB2 users instead of the ALL Record. For example, in CA Top Secret you have a profile called DB2DEVL for the DB2 DSND development test system. All DB2 users who can access this subsystem are given the DBADM privilege for the DBTEST database. Your TSS PERMIT command would be:
TSS PER(DB2DEVL) DB2DBASE(DBTEST) ACC(DBADM)
To keep the Catalog Synchronization Utility from generating a GRANT statement for this resource privilege for each user, create the following GRANT TO PUBLIC control statement:
DBS(DBTEST) PRIV(DBADM)
As a result, the following GRANT statement would be generated:
GRANT DBADM ON DATABASE DBTEST TO PUBLIC;
If the owner of a resource is included for synchronization and the resource is included in the GRANT TO PUBLIC file, a GRANT for that resource to the owner is still generated.
Once you use the GRANT TO PUBLIC file, always include that same, or updated, file for subsequent synchronizations. Failure to do this might result in revokes being generated for PUBLIC for the included resources.
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|