Databridge Enterprise Server Administrator's Guide > Mirroring DMSII Audit Files > Introduction to Mirroring

Introduction to Mirroring

NOTE:Mirroring is available as an additional Enterprise Server component and requires special licensing. Contact your sales representative for details.

After you have loaded a dump of a DMSII database to a secondary MCP host computer, you can propagate or "mirror" Audit Files An audit file is created by DMSII and contains the raw format of changes made to the DMSII database by update programs. Audit file records contain the deletes, adds, and modifies that were made to the various structures. It can contain, for example, hours', days', or weeks' worth of information. An audit file is created by the DMSII Accessroutines and contains the raw format of changes made to the DMSII database by update programs. Audit file records contain the deletes, creates, and modifies that were made to the various structures. Depending on the frequency of changes made to a database, the information in an audit file can span a few hours or several weeks. If you set the DBEngine Read Active Audit option, Databridge can access the current audit file. If you do not set Read Active Audit = true in the DBEngine parameter file, Databridge can access audit information up to and including the current audit file minus one. The audit file contains the update level at the time the audit file was created. The update level in the audit file and the update level in the DESCRIPTION file used by Databridge must match before Databridge will update a replicated database. When an audit file is closed, DMSII creates the next one in the series. Audit files are closed for several reasons, including the following:

  • An operator closes the audit file with the mixnumber SM AUDIT CLOSE command.

  • The audit file reaches the file size set in its DASDL.

  • There is an I/O error on the audit file.

  • There is not enough disk space for this audit file.

  • The database update level changes due to database definition changes

  • A Databridge accessory closed the file in preparation for the fixup phase after extracting records from a DMSII database.

  • The current audit file could not be found.

  • A file reorganization was executed to modify the DMSII structure.

from the primary computer through Enterprise Server to the secondary computer using audit file mirroring. After an audit file has been mirrored, you can use the standard DMSII recovery techniques to recover through the audit file and apply the changes to the secondary database. Because the audit files are first mirrored to the Enterprise Server environment, they are available even if the primary system is unusable. Mirroring in near real-time ensures that very few updates are lost in the case of a primary system failure.

There are two ways to mirror audit files for a configured source: from the Databridge Enterprise graphical interface and from the command line. This procedure uses the graphical interface. The command line lets you specify a range of audit file numbers to be mirrored. For more information about mirroring audit files using the command line, see Command-Line Options.

To mirror audit files

  1. In the right pane of the Databridge Enterprise window, right-click a base source and click Properties.

  2. In the Base Source Properties dialog box, click [Audit Mirror].

  3. In the Audit Mirroring Properties Dialog Box, select the appropriate settings, and then click [OK] twice to close the Audit Mirroring Properties and the Base Source Properties dialog boxes.

  4. Click [Save] to record your new configuration.

  5. To mirror audit files for a configured source, right-click the Enterprise Server source, and select Start mirroring audit files.

  6. To configure the secondary Databridge host, load the sample CONTROL file The DMSII CONTROL file is the runtime analog of the DESCRIPTION file. The DESCRIPTION file is updated only when you compile a modified DASDL. The CONTROL file controls database interlock. It stores audit control information and verifies that all database data files are compatible by checking the database timestamp, version timestamp, and update level. The CONTROL file is updated each time anyone opens the database for updates. The CONTROL file contains timestamps for each data set (when the data set was defined, when the data set was updated). It contains parameters such as how much memory the Accessroutines can use and titles of software such as the DMSUPPORT library (DMSUPPORT/databasename). Databridge uses the CONTROL file for the following information:

    Timestamps

    • INDEPENDENTRANS option

    • AFN for the current audit file and ABSN for the current audit block

    • Data set pack names

    • Audit file pack name

    • Database user code

    (DATA/AUDITMIRROR/SAMPLE/CONTROL) and save a copy as DATA/AUDITMIRROR/databasename/CONTROL.

  7. In the sample control file, modify the parameters described in the following table to reflect your installation. (See the sample configuration file in this section.)

    Parameter

    Description

    SOURCE

    SOURCE name in Enterprise Server

    AT

    Hostname or IP address of the Enterprise Server computer

    PORT

    Port number where the DBDirector service listens (for example, 5100)

    AUDIT " targetPath" on "pack"

    For targetPath and pack, type the directory path and pack on the secondary system where DBAuditMirror will write audit files it receives from Enterprise Server. The mirrored audit file will be created under the usercode that runs DBAuditMirror.

    RETRY num SECONDS

    Number of seconds to pause between retry attempts.

    MAXWAIT maxwait

    Maximum wait for additional audit updates before quitting. If maxwait is set to FOREVER, the host will retry indefinitely.

    The mirrored audit file will be created under the usercode running DBAuditMirror.

  8. On the secondary system, start DBAuditMirror

    START WFL/DATABRIDGE/AUDITMIRROR("
     databasename" [, ["
     logicaldbname"] [, startAFN[, endAFN]]])

    where databasename is the name of the secondary database The replicated database. The replicated database is the database that usually resides on the client machine and contains records cloned from the DMSII database. The replicated database is updated periodically with changes made to the primary (original) DMSII database. The periodic update (or tracking process) is explained later in this section. Compare this to the primary database. . Optionally, you can include a logical database name as a second parameter, and can specify a starting and ending audit file number range as third and fourth parameters. If you want to specify a starting AFN but not a logical database name, include the comma where the logical database name would go and immediately follow it with another comma before the startAFN. For example: 

    START WFL/DATABRIDGE/AUDITMIRROR ("(MIRROR)BANKDB", , 21, 25)

    For additional details, view WFL/DATABRIDGE/AUDITMIRROR.