4 Backup and Recovery

Performing backup and recovery for Oracle Database Mobile Server is the same as what you would normally do for Oracle database applications. The following sections help you understand how to use the Oracle database backup and recovery methods for preserving your mobile server and mobile applications:

4.1 How Does Oracle Database Mobile Server Store its Information?

Oracle Database Mobile Server uses the Oracle database to store information, as follows:

  • The mobile server itself is installed and configured as a database application. Thus, the mobile server stores its metadata and client state information within a database schema.

  • For each mobile application, the mobile server installs triggers and stores transaction data in a schema for that application.

4.2 Backing Up Oracle Database Mobile Server

Since all of the data needed for a backup and recovery strategy exists in the database, you should use the Oracle database backup and recovery strategies discussed in the following books:

  • Oracle Backup Installation Guide

  • Oracle Database Recovery Manager Quick Start Guide

  • Oracle Database Backup and Recovery Basics

  • Oracle Backup Administrator's Guide

  • Oracle Database Backup and Recovery Advanced User's Guide

Note:

In the past, we recommended that you use export/import to perform a backup. This is not a recommended option anymore. Use the normal online Oracle database backup procedure.

However, the following sections describe what to keep in mind when coming up with a backup and recovery strategy for your Oracle Database Mobile Server environment: Section 4.3, "Oracle Database Mobile Server Backup Coordination Between Client and Server" and Section 4.4, "Oracle Database Mobile Server Recovery Issues".

4.3 Oracle Database Mobile Server Backup Coordination Between Client and Server

When a client and a server synchronize with each other, the mobile server assigns the same "magic" number to both sides to indicate that the data is in-sync. If this number is different on both sides, the mobile server knows that the data is out of sync and is in an error condition. The following example details how this could effect your attempts for a clean recovery.

When you perform a backup, you may lose client data unless you plan accordingly. Figure 4-1 demonstrates the following scenario:

  1. The client inserts record 1 and synchronizes the data to the server. The mobile server assigns the same magic number to both the client and the server to denote that they are in sync. In this example, the magic number on both the client and the server is 10.

  2. The client inserts record 2. No synchronization is performed.

  3. The backup is performed. Client record 1 is saved to the backup. The latest magic number on both the client and the server is 10.

  4. The client inserts record 3 and synchronizes the data to the server. The mobile server assigns the same magic number to both the client and the server to denote that they are in sync. In this example, the magic number on both the client and the server is 20.

  5. The client inserts record 4. No synchronization is performed.

  6. A failure occurs and the last backup is used to recover the mobile server, the mobile applications and the application data. In this scenario, only record 1 is in the backup, so it will exist in the restored database.

  7. The client synchronizes. Records 2 and 3 can be lost, because they are not in the backup. The msync client does not send them to the server, since they were already sent in step 4. However, the msync client does send record 4 to the server, since it is a new record that has never been synchronized with the database. After the synchronization, record 4 is stored in the error queue, not in the application tables.

Figure 4-1 Lost Data With Backup and Recovery Strategy

Description of Figure 4-1 follows
Description of "Figure 4-1 Lost Data With Backup and Recovery Strategy"

The mobile server checks the magic numbers on both the client and the server. It verifies the state of the data on the client to determine what action to take. When the client performs the next synchronization, if the magic numbers are not the same, then the following occurs:

  1. The client checks if there are any new records—whether newly inserted, modified, or deleted—on the client. If so, then these records are sent to the server, which saves these records in the error queue.

  2. A full refresh of all of the subscribed data is sent to the client.

In our example, if you did nothing, the client would send record 4 to the server, which would end up in the error queue, and records 2 and 3 would be lost. To save records 2 and 3, do the following:.

  1. On the server, retrieve and restore the last backup.

  2. On the mobile client that is out of sync, update any record that has been modified since the last synchronization. In our example, you would do any sort of update that makes the record seem to contain new information in records 2 and 3. For example, you could update the VARCHAR field with the same content.

  3. Initiate a synchronization on the client. The Oracle Database Mobile Server software detects that the client database is out of sync and that some of the records have been modified. Thus, the following occurs:

    1. The modified records are updated in the restored database on the server and saved in the error queue.

    2. The server pushes a full refresh down to the client.

  4. In order for you to reapply the modified records to the applications table, you must first modify the DML operation from Error to Update. The DBA must modify the record in the error queue for the base table, named CEQ$<base_table_name>, changing the DML operation from Error (E) to Update (U) or Insert (I).

  5. Once updated to Update, re-execute the command. Navigate to the Error Queue screen in the Mobile Manager. Click on the modified record. Click Execute.

    Note:

    For more information on the error queue and how to reapply the records, see Section 2.10.1 "Resolving Errors and Conflicts on the Mobile Server Using the Error Queue" in the Oracle Database Mobile Server Developer's Guide.

  6. The next time that the MGP runs, the update is applied to the application table.

Thus, all information contained within records 2 and 3 will be restored from the device.

4.4 Oracle Database Mobile Server Recovery Issues

When you perform a recovery, the state of both the mobile server and the mobile application schemas must be in-sync. If they are out-of-sync, severe problems may occur. Therefore, when you perform a backup and restoration for the mobile server and the mobile application schemas, each must be recovered to the same point in time. Use the Oracle database Point-in-Time Recovery strategy to ensure that both the mobile server schema and mobile application schemas are recovered to the same point in time.

The mobile application schemas usually reside on the same Oracle database as the mobile server. However, if you have used a database link to store the mobile application schemas on a separate Oracle database, then you must use a backup and restore strategy for distributed database systems.