Chad Scott

Several years ago I got a call about a problem with some relatively unburdened servers that had low Server Availability Indexes (SAI). At the time, there really was no simple documentation on how to set this appropriately to yield the desired SAI, so a common approach was to keep setting the Server_Transinfo_Range notes.ini parameter to successively high values until the problem of low SAI went away. This is not a good approach, however, because setting Server_Transinfo_Range too high will result in a server that never thinks it is busy, even when it should.

Here are the instructions we've had for years for tuning SAI:

1. During a period of heavy usage, monitor the expansion factor on your server. You can use the console command "show stat server.expansionfactor" to do this. You can also monitor performance statistics during these periods. Record enough values for the expansion factor during heavy usage so that you can determine the expansion factor value for a fully loaded server.

2. Determine a value for SERVER_TRANSINFO_RANGE so that 2 raised to the power of that value results in the expansion factor value you chose in step 1.

While accurate, many people find these instructions a bit confusing, so I created a table that you can use to make this very easy. Just track the Server.ExpansionFactor statistic for periods of heavy usage and determine what you want the SAI to read for those periods. Find the closest ExpansionFactor in the table and trace left to your desired SAI. If it is not there, find the two numbers closest to your target. Then trace up to the corresponding value you need to set for Server_Transinfo_Range. Hopefully this will make tuning an appropriate SAI much easier for you.

Changing the system clock is one of the most damaging things you can do in a Notes/Domino environment. In particular, setting the clock forward in time and then back to the current time is a scenario that seems to play out much more than it should. Doing this on a Notes or Domino machine can have many serious ramifications that can have lengthy clean-up procedures.

I understand there may be times where you want to test the correct function of some task or agent at some point in the future, perhaps as part of planning for a specific project or business cycle. If this type of testing must be done, make sure it's in a completely disposable environment. I don't even recommend your normal test environment unless you plan on rebuilding it afterward. This is a perfect scenario for a client/server running in a virtual machine. Make a snapshot, do your testing, and then delete it.

Based on my experience, there seems to be very little consensus in the community about scheduled database maintenance. Here's a good starting point.

I commonly see environments where Compact -B runs nightly, but it's actually a good thing to have a bit of (contiguous) whitespace in the database so the on-disk file doesn't have to grow as soon as a new document is added. You don't want to go crazy with it and have a 50-percent utilized database, but somewhere around 10 percent seems reasonable.

Fixup is another area where you may have received some conflicting information in the past. We reviewed the applicability of Fixup as a general maintenance task with members of the Development team, and the consensus is that this is safe to do. I don't think it's necessary to run it regularly, but once a week can help clear up any inconsistencies that might crop up in the database.

What are you running for scheduled maintenance?

If you have or are thinking about upgrading to Notes/Domino 8.0.1, please be sure you are familiar with the following issues:

1. Policy settings that you have not configured start applying to users. The safe approach here is to assume that this will impact you and update your directory template code according to the instructions in the Technote linked on the right.

2. You see odd replication behavior after upgrading to 8.0.1, usually manifesting as documents appearing both in the Inbox and in folders to which they were moved. We are tracking several issues with the new Streaming Cluster Replication (SCR) feature. As with the above issue, assume that this will impact you and implement the notes.ini parameter documented in the Technote linked on the right. This feature will be off by default in 8.0.2 and will not be re-enabled until we have a better handle on the situation.

3. The Domino server time may creep ahead of the OS time. This issue is being tracked in SPR DBRH7FRQ6R, and a Technote is forthcoming. There is no current workaround short of restarting the server, but debugging efforts are ongoing.

4. Users are not prompted when their certificates are about to expire. This issue has been fixed in 8.0.2, and hot fixes are available for 8.0.1. Please refer to the linked Technote for more information.

My name is Chad Scott, and I'm a member of the Domino support team at IBM. I'd like to use this blog to share some pearls of wisdom I've picked up by supporting diverse environments over the last four years and highlight issues known to cause significant problems. The support teams have not traditionally had a great deal of interaction with the community outside of PMRs, and that's one thing I'd like this blog to help change. Please feel free to contact me at chads@us.ibm.com.