-ROLLBACK initiates the central JOURNAL operation for a replicated database. MUPIP JOURNAL commands may specify -ROLLBACK with other action qualifiers but not with -RECOVER. If you do not use -FETCHRESYNC, the database rolls back to the last consistent state. Only asterisk (*) qualifier is allowed for the journal file selection, that is, -ROLLBACK selects journal files by itself. MUPIP JOURNAL -ROLLBACK requires exclusive access to database files before recovery can occur. It keeps an exclusive access to the database files, that is, these database files are inaccessible during the -ROLLBACK.
-ROLLBACK -BACKWARD exits with an error message for following conditions:
Any database region corresponding to a journal file processed has replication state turned OFF. Note that, a configuration where there are replicated regions and at least one non-replicated-but-journaled region is not permitted by the replication source server. The source server errors out at startup on such a configuration without having set up the journal pool. Since all GT.M updates to replicated regions need the source server to have set up a journal pool, no updates are possible until the configuration is changed to have only replicated regions or non-replicated-and-non-journaled regions.
Any database region corresponding to a journal file identified by the command argument has journaling state DISABLE'd or ENABLE'd and OFF.
Any database region corresponding to a journal file has journal state ENABLE'd and ON, but the journal file name specified in the database file header is different than one identified by the command argument.
If a transaction is found with incomplete fence, it is considered broken. For the duration of the rollback, replication is turned OFF on all regions and turned back ON at the end of the rollback.
During the forward phase of rollback, if a complete transaction (fenced or unfenced) is found after a broken transaction, it is considered as a lost transaction. During forward phase of rollback, MUPIP journals the logical updates to the database. All broken and lost transactions are made available as a result of the rollback. These are written as journal extract format in two different text files.
When a database file is rolled back by -ROLLBACK, the corresponding journal file is also rolled back so that the two are synchronized. -ROLLBACK then creates a new journal file. If no forward play of journal records is necessary, the newly created journal file is empty and the database points to the new journal file. The journal allocation/extension/autoswitchlimit values in the new journal file is set in the way as described for -RECOVER -BACKWARD in the previous section under -RECOVER.
A prefix rolled_bak_ is added to the journal file, whose entire contents are eliminated by a -ROLLBACK. These files are not used by GT.M after the MUPIP JOURNAL -RECOVER, and can be moved/deleted as needed.
For -ROLLBACK the target database file should be the same as when GT.M wrote the last complete transaction to the journal.
If the -FETCHRESYNC or -RESYNC qualifiers are not specified, MUPIP does an optimal rollback (that is, check whether the database is in a wholesome state and attempt to automatically recover a database if there is a crash).