As databases grow in size, they require increasing amounts of resources to maintain and use. The document count has a direct impact on the time required to build views, maintain internal document tables, and run maintenance utilities, among other things. In many cases, there exists business justification for such large databases. However, most environments also contain many unnecessarily large databases that consume a disproportionate amount of resources. Database quotas
are a valuable tool for combating size creep in such databases.
A basic quota implementation might look something like this:
- Mail files for general users: 500 MB
- Mail files for power users: 1 GB
- Nonessential applications (team rooms and the like): 1 GB
The goal here is not to optimize quotas to save as much disk space as possible but to provide sensible maximums that limit the number of multi-gigabyte databases residing on the server. Remember that these are just starting points for developing your own quota implementation; different environments may require more generous or restrictive maximums.
In addition to setting the database quota, it is important to consider how Domino calculates the database size when evaluating the quota. There are three ways in which this can be done.
1. Check the space used in the database
2. Check the physical file size when extending the file
3. Check the physical file size when adding a note
The first option is the most lenient because it instructs Domino to discount whitespace when determining a database's size for quota evaluation. If a database that is 100 MB on the file system has a 100 MB quota and contains 20 percent whitespace, then it will be considered 80 MB for quota purposes. In this manner, it is possible for a database to be much larger than the configured quota if whitespace makes up a significant portion of the database. This option is recommended on servers that have transaction logging
enabled, as users will be able to compact their mail files without user intervention to provide temporary quota relief. Frequent scheduled compactions
The second option does not discount whitespace. The same 100 MB database with 20 percent whitespace is considered to be 100 MB during quota evaluation. Because this database has 20 MB whitespace, it may still be possible to add new notes before the quota would be exceeded. This will depend upon the message size and the size of the individual whitespace chunks available in the database. If no single chunk of whitespace can accommodate the new note, the database will have to be extended on
the file system. This operation will fail because it would cause the database to exceed its quota. Note that this option always requires administrative intervention if transaction logging is enabled. As with the prior option, frequent scheduled compactions
The third option calculates the database size in the same manner as the second. The difference here is that whitespace cannot be used for new notes. In our 100 MB database with 20 percent whitespace, even a new 1 KB note will cause the database to exceed its quota. This is the most restrictive enforcement option, and it also requires administrative intervention if transaction logging is enabled.