Estimating database capacity

An understanding of the sizes of elements, versions, and DOs is essential when estimating how many of these objects a VOB database of a given size can hold.

About this task

Keeping a VOB database's working set in memory greatly reduces the time it takes to access VOB metadata, which is why the VOB host configuration guidelines include a recommendation that the VOB server be configured with enough physical memory to hold half of each VOB database it hosts.

The following table provides information about the sizes, in bytes, of the four most significant contributors to VOB database space consumption.
Table 1. Sizes of common VOB data types
Data type VOB database space consumption (in bytes)
Element with one version 3970
Each additional version of an element 642
Unshared DO (excluding config rec) 1924
Shared DO (excluding config rec) 118
Note: Every DO includes a configuration record (config rec). The size of the config rec is determined by an element's contents and how the DO was built (build script and compiler options). For purposes of estimation, you can assume that a config rec adds between 2% and 10% to the size of an unshared DO, and 50% to 100% to the size of a shared DO.

It is more difficult to estimate how many of these objects users will create in a VOB. Estimating the number of elements is usually easy, especially if you are populating the VOB with the contents of another source code control system (see Importing data). Estimating the number of versions is harder. Some elements accumulate many more versions than others. You might be able to use the number of versions of some representative elements in other VOBs as an indicator of how your software development methods contribute to version creation. The number of derived objects you create is a function of the number of build targets and number of elements in each target. If you do not use dynamic views and clearmake or omake, you do not create derived objects.

When you have an estimate of the number of elements a VOB will contain, you can use the information provided in Table 1 to compute a rough approximation of the VOB's database size by using this formula:

S = N (E + (e * (V -1))+ (D * d))

where:
  • S is the database size in bytes.
  • N is the number of elements in the VOB.
  • E is the size of an element with one version.
  • e is the size of each additional version of an element.
  • V is the average number of versions per element
  • D is the number of unshared derived objects per element
  • d is the size of an unshared derived object.

Example

The following example uses this formula to estimate the size of a VOB that contains 500 elements with an average of 20 versions and 5 derived objects per element:

500 * (3970 + (642 * (20 - 1)) + (5 * 1924)) = 12,894,000 bytes

These estimates do not account for the sizes of other VOB metadata such as branch types and instances, attribute types and instances, and so on. These data types are generally small, but they can be numerous in some VOBs, especially when UCM is in use.