Siebel Remote and Replication Manager Administration Guide > Administering Siebel Remote > Handling Failure and Recovery >

Database Server Media Failure

A head crash or other media failure on the Siebel database server may render the database unusable. Therefore, your database administrator should take preventive measures to protect against such occurrences, such as disk mirroring or online backups and RAID (redundant array of independent disks).

If restoring the database results in a permanent loss of transactions from the server, the Transaction Router may have routed some of those lost transactions to Mobile Web Clients prior to the crash. Full recovery may then require a second step: resynchronizing the server and client databases.

To diagnose and restore database synchronization

1. Stop the Transaction Router, Transaction Merger, and Transaction Processor on the Siebel Remote server, and use Siebel Server Manager to disable the Synchronization Manager.
2. After the database administrator has returned the database server to an operational state, use the Siebel Server to determine if Transaction Router sent data to any clients after the last backup of the database server.

   These are the clients whose databases require reinitialization. To do this:

   1. Look at the route log file txnroute_<taskid>.log to see if there is anything about not processing a client because of a corrupted file.
   2. If the log indicates that dobjinst.dbf (visibility database) is bad, you must reextract the database for the mobile user identified in the log.

      For dbxtract, see Creating Mobile Web Client User Accounts and Privileges.

      NOTE:  A database extract may not be enough to restore a database. For example: On Monday a backup is invoked for two mobile users (A and B). On Tuesday user A synchronizes, yet that database is lost on Wednesday. User A's database is restored from Monday's backup.
      
      Then a dbxtract is invoked for Users A and B. User B synchronizes without any errors. However, user A receives a mismatch error because the routed values are different between the client and the server. User A must delete the local DB before acquiring a new database.

3. Notify these users that their databases must be reinitialized.
4. Run Database Extract for the affected clients.

   For information on running Database Extract, see Creating Mobile Web Client User Accounts and Privileges.

5. Notify the affected users that their client databases will be reinitialized the next time they synchronize.

   For information on initializing a Mobile Web Client database, see Initializing a Mobile Web Client Database. Since this is a potentially lengthy process, users may want to finish this process at different times. For example, users located close to a field office may want to take advantage of a LAN connection to reduce download time. Others may want to reinitialize during the evening or night, when telephone rates are lower.