Unix primary server steps to entirely drop the BMR database and then reinitialize from scratch

Problem

BMRDB files will grow over time as entries are added to it.  However, it may not automatically shrink as entries are deleted. Under some circumstances, entries in the BMRDB can become corrupted, which can cause problems when BMR operations are being performed. Lastly, dropping an oversized BMRD and then reinitializing from scratch can help increase access performance on a running server. Doing so will not delete any of the backup images. This is a recommended action to take ahead of an upgrade that goes to a new major release. 

What are the implications of dropping BMRDB and then re-initialize from scratch?
Not much, BMRDB rebuilds within a day or two, as and when backups run, all your clients will get relisted.
However for those clients that were decommissioned earlier, you can get them back by manually importing the bundle of that client (needs a single command to be run on the primary server).

You will also lose SRTs and Boot servers that were registered earlier. This isn't much of a consequence as older SRTs serve little purpose and newer ones can be created in 20 minutes. Thus, in summary, it will not cause any disruption to your ability to perform a BMR for any client (DR of any client).

Cause

Normal database insertions can cause the database files to grow over time.  Deletions, however may not decrease the physical size of the files.

Solution

Reinitializing BMRDB will reinitialize all BMR database files to their starting sizes and values. All existing entries are removed.

All actions are done on the Master Server via command line.
The example command invocations below are in Unix/Linux format for file names. 
The example invocations are identical on Windows Servers, using Windows install file paths.
 
From the Administration console, under Bare Metal Restore Management node "Tasks", cleanup any and all active tasks for BMR. THIS IS VERY IMPORTANT !

Ensure a FULL catalog backup exists.
Take a downtime of 1 hour (procedure needs only 30 minutes)

Unix primary server steps to drop BMR database and then reinitialize from scratch.

1. We do not want any new jobs to trigger during this procedure
   # <install_path>/bin/admincmd/nbpemreq -suspend_scheduling
   Wait till running jobs are completed and then close the Java console or the WebUI

2. Take an online backup of BMRDB.
   # <install_path>/db/bin/nbdb_backup -dbn BMRDB -online /#SAVE_DIR/BMRDB_backup_ddmmyy

3. There are two methods, listed below, to reinitialize BMRDB from scratch, you may use any.

Method A:  DO NOT USE THIS METHOD for NBU version 10.2 and later

Stop all services
# /usr/openv/netbackup/bin/goodies/netbackup stop
or
# /usr/openv/netbackup/bin/bp.kill_all

Check using bpps command. Kill lingering processes.

Delete the 4 BMRDB files listed below

BMRDB.db
BMRDB.log
BMR_DATA.db
BMR_INDEX.db

Remove the VXDBMS_BMR_DATABASE line from within the /usr/openv/db/data/vxdbms.conf file (do not delete the other line VXDBMS_BMR_INCREMENTAL = BMRDB.log.1)

Remove the initialization line for BMRDB within /usr/openv/var/global/databases.conf file

Start all services
# /usr/openv/netbackup/bin/goodies/netbackup start

Recreate BMR database using below command
# /usr/openv/netbackup/bin/bmrsetupmaster

Method B: This method is suitable for Netbackup v10.2 and above
Stop all services
# /usr/openv/netbackup/bin/goodies/netbackup stop
or
# /usr/openv/netbackup/bin/bp.kill_all

Start just the database server service
# /usr/openv/netbackup/bin/nbdbms_start_stop start

Check, BMRDB should be alive
# /usr/openv/db/bin/nbdb_ping -dbn BMRDB

Below command will entirely remove BMRDB
#/usr/openv/netbackup/bin/bmrsetupmaster -undo -f

Stop the database server service
/usr/openv/netbackup/bin/nbdbms_start_stop stop

Check if remnants of BMR exist in config files and paths (vxdbms.conf and the 4 BMRDB files)
If all good, start all Netbackup services
# /usr/openv/netbackup/bin/goodies/netbackup start

Below command will recreate BMRDB from scratch
#  /usr/openv/netbackup/bin/bmrsetupmaster -redo -force

Check the state of the new BMRDB
# /usr/openv/db/bin/nbdb_ping -dbn BMRDB

Verify that the new BMRDB was rebuilt to the latest SCHEMA.
# /usr/openv/netbackup/bin/bmrs -o query -res database -table CurrentVersion
 

CAUTION: If Method B doesn't work,  then please engage NBU support. DO NOT rename the /usr/openv/db/data/bmrdb folder as this will cause a misconfiguration between what actually exists on the disk Vs what is registered in the database and, further, it will break the BMRDB completely.