Don’t forget when you’re working in your environment to validate the request log is being purged correctly. Failing to do so can certainly impact performance of the FIM environment as a whole.
As an example, I have a complex environment where certain requests will trigger other requests that are completed by the Function Evaluator as part of an action workflow. Each activity in the workflow is another request. Therefore, for example, if you have one request that changes the state of an object such that it triggers an action workflow setting five other attributes, you end up with six requests in your database.
Now on its face, that really doesn’t seem to bad. You want the requests there for obvious auditability over the short term (FIM sets the default for expired requests being purged to 30 days) but not so long that your database grows uncontrollably.
Now imagine that I have 5,000 requests against the database most of them trigger the six subsequent actions based on my workflow I noted above. That means I have 25,000 requests in my log. The default SQL server job for removing the expired objects only runs once per day and removes 20,000 expired objects. Doing the simple math, that is 5,000 less than what I’ve actually generated during that day! Over the course of a month, that is 150,000 more, 6 months would be 900,000 more, etc. My request log never gets purged of all the expired requests, it simply continues to grow.
So long story short, when you’re doing your tuning and planning for initial load and ongoing operations get a good focus on the average number of total requests per day versus the total number of changes made by a user. Then tune the SQL agent job to run often enough to clear them out and keep your requests down to a manageable number.
I have heard of clients running this hourly to ensure that it keeps up to the load of data change in large organizations without any ill effects. Some suggestions from colleagues suggest that running it every 30 minutes during off-peak hours can be of great benefit as well. Look at the results of the scheduled jobs as I have noticed that although they are scheduled to run every 30 minutes, there will be variance in how many times they will run as more complex requests that have expired take longer to purge. I have had jobs that take up to four hours for a single run to remove 20,000 requests and others that have taken a 30 minutes.
If you want to take a look at the “residual” objects that are left in your environment that should have otherwise been purged, do an advanced search from the “Search Requests” navigation bar item. The parameters of the search are pretty simple:
Select request that meet all of the following:
- Expiration Time prior to 30 days ago