Basic Size Management of Storage Site Databases

This article provides basic information about RecordPoint content databases and what contributes to their size, such as configuration and audit settings. Applies to RecordPoint on-premise solutions.

About RecordPoint Content Databases

RecordPoint uses a minimum of three content databases. One is used for the RecordPoint top-level Site, while all other databases are used to hold record content within what are called "storage sites." Storage sites and their corresponding databases are separated based on the type of content they hold:

• XML stubs of Records, Files, and Boxes

• Binaries

These storage sites, the content types they hold, and their attached databases can be seen by going into Management > Storage Settings.

Storage Site Databases and Size

Two notable factors that contribute to the size of a storage site database are a) the number of items in its corresponding site, and b) audit settings.

a) Number of Site Items

The maximum size of a storage site collection is determined by the number of items (XML stubs or binaries) that exist within it, not by its corresponding database GB size. Fewer items in the site means less database table entries, which in turn can help keep the database’s overall GB size at manageable level. In the RecordPointConfig* list, you can see the following fields and their values that determine what that maximum number is:

• ItemMaximum: 500 (default)

• FolderMaximum: 2 (default)

• ListMaximum: 1000 (default)

• WebMaximum: 1 (default)

Together, these total to a default limit of one million items per storage site (500 items per folder, 2 folders per list, 1000 lists). Once a site hits this limit, then a timer job will automatically begin the process of creating a new storage site and database where new content will be added. The values above can be reduced as needed to lower the maximum number of items that will be held in a storage site.

b) Audit Settings

The other main contributor to a database’s size is the audit settings for both RecordPoint storage sites and SharePoint site collections. A database’s AuditData table, where audit entries for records are added, can make up a large portion of the overall database size depending on these settings.

• Audit Settings in RecordPoint’s Storage Sites:

By default, all audit events are captured and audit trimming is disabled within the storage sites. Generally, it's recommended to keep the default settings as these events correspond to what occurs on a record stub or binary.

• Audit Settings in SharePoint Site Collections**:

Depending on the audit settings for a given active site, each audit event is first stored in the SharePoint database’s AuditData table. Whenever an item is submitted from the active site into RecordPoint, then the SharePoint audit entries for that item (starting from the date of its last RecordPoint submission) is copied and also placed into the AuditData table of the corresponding RecordPoint storage site database. There are two potential ways to reduce the number of events that get copied into RecordPoint, given your compliance requirements:

1. In the active site(s), reduce what events get logged or enable trimming, as that may help lower the number of entries being copied between submissions

2. In the RecordPointConfig* list, adjust the value of a field called AuditMaximum, which dictates the maximum number of entries that will be copied per submission

If your AuditData table already takes up more space than desired, you can migrate some of the old audit data into a new database - see Migrating Audit Data to a New Database on how to do so.

• To reach the RecordPointConfig list, append “/Lists/RecordPointConfig” to the end of your RecordPoint URL. If editing any values in this list, a cache refresh is required afterwards for the changes to take effect (Management > Cache Settings).

• *For further information on auditing, see the following link: 

http://docs.recordpoint.com/display/R4/Auditing+in+RecordPoint