PrincipalObjectAccess–Performance Recommendations
One of the topics of discussion that can come up during the planning phase for a customers CRM implementation is Business Unit structure and sharing which leads to the PrincipalObjectAccess (POA) table. As the POA table grows in size due to the sharing of records, which can be frequent in environments with a complex Business Unit structure, CRM performance can suffer. Below are some general recommendations that we provide to customers that are anticipating their deployment will have a complex Business Unit structure and/or frequent sharing of records.
- Share only what is needed
- By limiting the amount of sharing that takes place we will reduce the total number of records in the POA table
- For more on sharing and the POA table see Jon’s post
- Minimize the number of Business Units where possible
- Help reduce the need for sharing records
- Ensure users are placed in the appropriate Business Unit
- Can a user be moved further up the Business Unit hierarchy to give them the necessary access to records in another Business Unit
- Modify Security to allow users to see information outside of their Business Unit
- This will also reduce the need for sharing
- Once a record does not need to be shared any longer stop sharing it
- Enable the EnableRetrieveMultipleOptimization registry key
- http://support.microsoft.com/kb/2535245
- Enabling this will cause the queries to make use of temp tables
- Evaluate splitting TempDB out to its own physically separate RAID array
- Ensure frequent queries that involve the POA table have appropriate indexes in place
Not all of these will be applicable to all deployments but the goal of most of these is to provide customers items to consider while they are planning out their Business Unit structure.
No comments:
Post a Comment