General Guidelines for Tuning a Repository Database

This section describes some general guidelines for tuning a repository database:

• DBAs must frequently run statistics to monitor what is happening with the repository database.

• If you are using a data source, set the connectionPoolDisable attribute to true in the RepositoryConfiguration object to disable automatic internal connection pooling in the Identity Manager repository.

  For example, setting <RepositoryConfiguration connectionPoolDisable=’true’> allows you to avoid having two connection pools (one for Identity Manager and one for your application server).

• You can edit the RepostioryConfiguration object to enhance the performance of searches against specific, single-valued attributes. For example, you might edit this object to add an extended attribute, such as employeeID, that is used to search for Users or as a correlation key.

  The default RepositoryConfiguration object looks like the following example:

  <RepositoryConfiguration ... > <TypeDataStore Type="User" ... attr1="MemberObjectGroups", attr2="lastname" attr3="firstname" attr4="" attr5=""> </TypeDataStore> </RepositoryConfiguration>

  ---

  Note –

  The ellipses represent XML attributes that are not relevant here.

  ---

  Each of the attr1, attr2, attr3, attr4, and attr5 XML attributes specifies a single-valued attribute to be copied into the waveset.userobj table. The waveset.userobj table can contain up to five inline attributes. The attribute value named by attr1 in RepositoryConfiguration will be copied into the “attr1” database column in this table.

  Inline attributes are stored in the base object table for a Type (rather than as rows in the child attribute table).

  Using inline attributes improves the performance of repository queries against those attributes. (Because inline attributes reside in the main “object” table, queries against inline attributes are faster than those against non-inline attributes, which are stored in the child “attribute” table. A query condition against a non-inline attribute requires a “join” to the attribute table.)

  By default, Identity Manager uses the MemberObjectGroups, lastname, and firstname inline attributes.

  • You can add two more attributes to enable faster searching, as long as those attributes are queryable.

    For example, if your deployment contains an employeeID extended attribute, adding that attribute inline will improve the performance of repository searches against that attribute.

  • If you do not need lastname or firstname, you can remove them or replace them with other attributes.

  • Do not remove MemberObjectGroups. Identity Manager uses this attribute internally to speed up authorization checks.

For more information about which object types are stored in each set of tables, see Data Classes.