DBMT in a nutshell
Recompiling info about DBMT in a small document.
DBMT
The Database Maintenance Tool (DBMT) is a core component introduced in Domino 9 and remains essential in Domino 12.0.2 for automated database administration. It functions as a "Swiss Army knife" for server maintenance tasks, specifically designed to eliminate the necessity of running the separate Updall task.
Here is a review of the DBMT's functionality, scope, and required configuration for a Domino 12.0.2 environment, drawing upon the provided documentation:
I. Purpose and Scope of DBMT
The DBMT tool is designed to perform multiple daily and weekly administrative tasks on user mail database files and other databases.
It is crucial to understand that DBMT is intended to replace Updall; administrators should not run both tasks simultaneously.
The specific tasks performed by the DBMT tool include:
- Running copy-style compact operations (compact -C).
- Purging deletion stubs.
- Expiring soft deleted entries.
- Updating views.
- Reorganizing folders.
- Merging full-text indexes.
- Updating unread lists.
- Ensuring that critical views are created for failover.
Compaction Limitations
By default, the DBMT tool executes copy-style compaction (compact -C). It does not support the equivalent of in-place compaction options, such as load compact -S 10 (which is compaction based on a percentage of unused space).
(Note: Although newer versions like Domino R14 include options like -s <n>K, -s <n>M, or -s <n> for compaction based on unused space estimates, these options are not standard features in the core DBMT functionality reviewed in the context of older versions, which rely strictly on copy-style compact.)
II. Configuration via Program Document
To utilize DBMT effectively, especially with scheduled time parameters like -range, configuration is required in both the server's notes.ini file and a Program document.
Notes.ini Requirements
- Remove Updall: The task nUpdall must be removed from the ServerTasksAt2 parameter.
- Prevent Router Interruption: Set MailFileDisableCompactAbort=1. This prevents the router from interrupting compact operations by delivering mail; delivery resumes once the compact operations are complete. This is considered a best practice in clustered environments.
- Specify System Databases: By default, DBMT skips a specific list of system databases (e.g., names.nsf, log.nsf, admin4.nsf). If your organization has additional system databases, you must specify them using the DBMT_FILTER notes.ini variable. Entries are case-insensitive and relative to the data directory (e.g., DBMT_FILTER=log.nsf).
Program Document Execution
To use the -range option, the Program document must be configured to run once at server startup ("At Server Startup Only"). If the administrator chooses to start DBMT daily (e.g., using a time schedule), they should use options like -stoptime or -timeLimit instead of -range.
A standard set of command-line options includes:
dbmt -compactThreads n -updallThreads n -range starttime stoptime -compactNdays n -force d
For example: -compactThreads 8 -updallThreads 8 -range 2:00AM 7:00AM -compactNdays 5 -force 1. Times must be specified in the 12-hour format with AM/PM (e.g., 7:00AM).
III. Key Command Line Options
The following options allow administrators fine-grained control over DBMT operations:
Option | Abbreviated Syntax | Description |
-compactThreads | -ct | Configures the number of threads for compact operations. Default is 1. Specifying 0 prevents compact operations. The value should be based on the number of disks backing the data directory. |
-updallThreads | -ut | Configures the number of threads for updall operations. Default is 1; 0 is not allowed. |
-range starttime stoptime | -r | Assumes the Program document runs at startup. DBMT sleeps until starttime and runs compact operations until stoptime. |
-timeLimit tl | -tl | Restricts the compact time to tl minutes. Assumes DBMT is started daily. This option does not apply to updall. |
-stoptime st | -st | Specifies the time (st) when compacts should complete. Assumes DBMT is started daily. |
-compactNdays n | -cnd | Attempts to compact all non-system databases every n days. |
-force d | -f | Selects the day of the week (d: 1=Sunday, 0=any day) for fixup. Fixup runs only if 5 or more consecutive compact operations fail (and the failure is not due to the database being in use). |
-nocompactlimit | -ncl | If a time limit (-range or -timeLimit) is reached, allows the compacting operation underway to finish, but no new compacts will be started. |
-ods | N/A | Performs copy-style compacting to upgrade databases to the server's ODS level if they are below that level. This command never downgrades ODS. |
-blacklist .ind | -bl | Prevents compaction of databases listed in the specified indirect (.ind) file. |
IV. Non-Discardable Views
DBMT plays a crucial role in managing non-discardable views, which is particularly useful in clustered environments.
A non-discardable view is built by DBMT during updall (if not already built) and will not be discarded due to inactivity. This capability provides performance gains, especially during user failover between cluster members, as it ensures that mail file view indexes (like the inbox) are already built on the failover server, preventing delays for users.
DBMT ensures these views are built for databases using standard mail templates (e.g., StdR7Mail, StdR8Mail, StdR9Mail). Standard non-discardable views include:
- $Inbox
- $Drafts
- $All
- ($Calendar)
- ($iNotes)
- ($ThreadsEmbed)
Administrators can specify additional non-discardable views for standard templates using the dbmt_<template name> notes.ini setting, or add custom mail templates to the list using the DBMT_MailTemplate setting.
