Managing the Data Protector Internal Database

Recovering the IDB

label and media pool.

2.Run the omnidbutil -fixmposcommand to establish consistency between media positions (mpos) and binary files.

3.Import the catalog from the media to recreate the binary files. Refer to “Importing the Catalog from Media” on page 114.

Recovering if DC If some DC binary files are corrupted, you can remove the DC binary Binary Files Are files and recreate them. The only effect of removing the files is that some

Corrupted media positions point to the non-existent binary files, and thus an error message is displayed when browsing the relevant filesystems. Proceed as follows:

1.From the omnidbcheck -dcoutput, identify the Medium ID of the corrupted DC binary file. Run the omnimm -media_info<Medium> command to get other attributes of the medium, such as medium label and media pool.

2.Identify the DC binary file for the affected medium. DC binary files are named: <Medium>_<TimeStamp>.dat (in the <Medium>, and colons ":" are replaced with underscores "_").

3.Remove the corrupted DC binary files.

4.Run the omnidbutil -fixmposcommand to establish consistency between media positions (mpos) and binary files.

5.Import the catalog from the media to recreate the binary files. Refer to “Importing the Catalog from Media” on page 114.

Handling Major Database Corruption in theFilenames Part

If you detect that the corruption is of major severity, which means that a filename tablespace is corrupted, you can remove the detail catalogs (filenames and DC binary files) instead of recovering the whole IDB.

The procedure is fast and results in an IDB without detail catalogs (as though all backups were done with the No log option). The IDB is still fully operational in terms of all backups, restores, and media management operations, except that browsing is not possible (information about backed up data should be read from media).

Since all detail catalogs are lost, this method of recovery is only applicable if:

Chapter 9

423