Controlling the size of a NotesTracker Repository database

Two recent IBM developerWorks articles are a must-read for Notes/Domino developers (and also very important for administrators):

• Lotus Notes/Domino 7 application performance: Part 1: Database properties and document collections
• Lotus Notes/Domino 7 application performance: Part 2: Optimizing database views

In the second article, under the heading View Performance Testing the point is made that:

The biggest "performance killers" in terms of view indexing are categorized columns. Sort columns add a small amount of overhead as do some other features, such as the Generate unique keys option.

There are two accompanying charts that reinforce this statement. The first one displays View index size versus response times and we see that the categorized views (the two rightmost bars) having index sizes considerably larger than those of comparable non-categorized views:

Column sorting uses far less resources than view categorization, as shown by the shorter bars in the chart. (The other chart shows View size versus refresh time and demonstrate that the categorized views also have distinctly longer response times.)

In a NotesTracker Repository database -- assuming that you retain the database design as distributed -- the usage log documents are shown via a dozen or so Database Activity views. These views select all of the usage log documents in the repository, whereas the other views select subsets of usage log documents (in some cases quite small subsets) and should not have all that much impact on the repository's size.

Here's a typical view, the Database Activity by Action / User view (shown with the new navigator coming in NotesTracker Version 5.0):

One user of NotesTracker has reported that it only took around 55,000 usage log documents for their NotesTracker Repository database to reach a size of 1 GB, so you may see a need to somehow minimize the database's size.

In light of the findings about categorized views described in the articles, if you feel that you want to reduce the size of any of your NotesTracker Repositories, one good way way to do so would seem to be by deleting unwanted and/or infrequently-used categorized views from the repository's database design. (You could might gain some advantage by implementing some of the other techniques described in the two articles.)

We would be very interested in recieving your feedback if you try doing any of this.