Siebel Remote and Replication Manager Administration Guide > Troubleshooting Siebel Remote > Recovering from a Failure >

Recovering from Failed Media That Resides on the Siebel Server

A head failure or other media failure that involves the Siebel Server might result in an unusable Siebel database. For more information, see Protecting Against a Media Failure.

To recover from failed media that resides on the Siebel Server

1. Stop the following server components on the Siebel Server:
   • Transaction Router
   • Transaction Merger
   • Transaction Processor
2. Use the Server Manager to disable the Synchronization Manager.
3. Wait for the Siebel database administrator to return the Siebel Server to an operational state.
4. If the Transaction Router server component sent data to any remote clients after the most recent backup of the Siebel database was performed, then you must reinitialize the local database for each remote client who received data after the last backup:
   1. To determine if a remote client is not processed because of a corrupted file, you can examine the log file of the Transaction Router server component.

      If the log indicates that the dobjinst.dbf visibility database is corrupt, then you must reextract the Siebel database for the user that the log identifies. It might be necessary to delete the local database. For more information, see Example Where You Must Delete the Local Database and Naming Conventions for Log Files.

   2. Notify users to reinitialize their local databases.
   3. Run Database Extract for the affected clients.

      For more information, see Extracting the Server Database.

   4. Notify each user that Siebel Remote will reinitialize the local database the next time the user synchronizes.

      This is a potentially time-consuming step. The user might be required to reinitialize at different times. For example, to reduce download time, users who are located close to a field office might be required to use a LAN connection. Other users might be required to reinitialize during the evening or night when telephone rates are lower. For more information, see Initializing the Local Database.

Example Where You Must Delete the Local Database

A database extract might not be sufficient to restore a local database. For example, assume the following sequence of events occur:

1. On Monday a backup starts for user A and user B.
2. On Tuesday user A synchronizes.
3. On Wednesday the local database for user A becomes corrupt.
4. To restore the local database for user A, Siebel Remote uses the Monday backup.
5. Siebel Remote starts a database extract for users A and B.
6. User B synchronizes without error.
7. User A receives a mismatch error because the routed values between the remote client and the Siebel Server are different.
8. User A must delete the local database before this user acquires a new local database.

Protecting Against a Media Failure

It is strongly recommended that you run your Siebel Server with a redundant disk configuration. If a device fails that contains inbox and outbox folders for remote clients, then a redundant configuration can minimize data loss.

To protect against a media failure, it is strongly recommended that your database administrator take preventive measures. For example:

• Use disk mirroring
• Use online backups
• Use RAID (Redundant Array of Independent Disks)

If restoring the Siebel database results in a permanent loss of transactions from the Siebel Server, then the Transaction Router server component might have routed some of those lost transactions to remote clients before the failure occurred. To complete a full recovery, it might be necessary for you to resynchronize the Siebel database with the local database.