This chapter describes the tasks for administering Oracle Communications Messaging Server database snapshots. See "Message Store Automatic Recovery On Startup" for conceptual information on database snapshots.
The primary message store database is critical to smooth operation of the message store. You must always ensure that a snapshot (or backup) of the database is available. If the active database becomes damaged, restarting services allows the message store stored process to swap in the best snapshot and enable services to come back on demand.
Before doing these tasks, see "Message Store Database Snapshot Interval and Location". Also, descriptions of the configutil options described in this page are in Messaging Server Reference.
A database snapshot is a hot backup (dynamic backup) of the message store database. The system makes this copy without any locking, and requires that both the database files and transaction logs so the snapshot can be "recovered" into a valid copy of the database.
By default, snapshots are scheduled with the imdbverify -s command to run at specific times.
local.schedule.snapshot.enable = "1"local.schedule.snapshot = "0 2 * * * bin/imdbverify -s -m"
By default, the imdbverify -s command takes a database snapshot at 2 a.m. (This command uses UNIX crontab format: minute hour day-of-month month-of-year day-of-week command arguments.) The -m option is used to verify the snapshot. The -m option is not required. See "Message Store Database Snapshot Recovery and Verification" for more information.
Database snapshots are located in the following base directory:
local.store.snapshotpath = "dbdata/snapshots"
Change this directory to a different disk than the disk used by the primary database, for both performance and recovery reasons.
You configure the number of snapshots retained over time with the following option:
local.store.snapshotdirs = "3"
Each snapshot requires as much disk space as the entire database and transaction logs at any given time.
Take enough snapshots such that you both have a recent copy, and copies that go back a day or two, to be sure you can find a database not affected by any odd system problems that are not immediately discovered.
The message store has been enhanced to continuously recover archived log files into an up-to-date backup copy of the message store database. If the actual database becomes unusable, then the message store automatically uses this backup database. Having an up-to-date database backup provides the next level of recovery and stability for the message store.
The system automatically runs imdbverify -m as specified for rolling backups, and imdbverify -s -m as specified under snapshots.
If the verification process detects any errors, the errors are written to the default log. Errors in the default log mean not only that the snapshot failed, but they could also be pointing to a problem with the active database. (However, at this time, not all verification errors indicate a live database problem.)
The message store rolling backup operates as a specially designated snapshot, where each transaction log is added to the snapshot and recovered every few minutes to provide a more up-to-date backup. For this reason, always enable snapshots, and rolling backup will be enabled by default.
Rolling backup requires the following three configuration settings, which are enabled by default:
local.store.rollingdbbackup = "yes"
local.schedule.snapshotverify.enable = 1
local.schedule.snapshotverify = "1,3,5,7,9,11,13,15,17,19,
21,23,25,27,29,31,33,35,37,
39,41,43,45,47,49,51,53,55,
57,59 * * * * bin/imdbverify -m"
In this configuration:
local.store.rollingdbbackup enables rolling backup. This means the log archive function running under the stored daemon copies the database transaction logs to the rolling snapshot instead of removing them every minute.
local.schedule.snapshotverify verifies addition, which is required to continually roll the log files into the snapshot.
Note:
Should a rolling backup fail any of its verifies, each side of the process declares the rolling backup invalid and cleans up the logs. Rolling backup then restarts after the next snapshot is put in place. Rolling backup relies on an initial snapshot taken by the normal snapshot process.When the message store services are started, the message store process stored decides if the current database is damaged, and if so, replaces it with the best snapshot. The best snapshot is printed in the logs and any recovery actions are also printed in the default log.