Siebel Remote and Replication Manager Administration Guide > Extracting and Initializing a Remote Database > Process of Extracting the Server Database >

Extracting the Server Database

This process is a step in Process of Extracting the Server Database.

Database extraction uses the server database template that the Siebel Server creates when you run the Generate New Database Template server component. This template provides an up to date database schema to a new or existing remote client. It is strongly recommended that you distribute all database schema changes to all remote clients. For more information, see Controlling the Data That Siebel Remote Routes to Clients.

Beginning with Siebel CRM version 7.5, the Database Extraction server component does the following work:

1. Identifies visible instances for all members of a list of nodes.
2. Identifies the commonly visible instances and extracts the records only one time for all these nodes.
3. Extracts instances outside the common set for each node.

This configuration helps to reduce the time that Siebel Remote requires to extract a large number of users. The Optimal Mode parameter enables this process. If the Optimal Mode parameter is TRUE, then other parameters can affect the time that Siebel Remote requires to complete the extraction. Example parameters include Nodes Per Group and Extract All Repository Files. For more information, see Parameters of the Database Extract Server Component.

For more information, see Local Database Extraction and Options for Extracting the Server Database.

To extract the server database

1. Make sure you complete all required work.

   CAUTION:  If possible, perform all required work before you extract the server database.

   For more information, see Caution About Extracting the Server Database.

2. Log in to the Siebel Server with administrator privileges.

   For more information, see Logging In to the Siebel Server as an Administrator.

3. If the local database contains unsynchronized transactions, then you must attempt to synchronize those transactions before you proceed.
4. Navigate to the Administration - Server Management screen, and then the Jobs view.
5. In the Jobs list, click New.
6. In the Component/Job field, choose Database Extract from the picklist.
7. In the Requested Server field, enter the name of the Siebel Server on which the Database Extract job runs.

   After the job finishes, the read-only Execution Server field displays the name of the Siebel Server that ran the job. For a Database Extract job, this is the same as the Requested Server.

8. In the Job Parameters list, which is located below the Jobs list and the Job Detail form, click New, and then add a parameter using values from the following table.

   Parameter Name	Description
   Client Name	Enter the name of the remote client.

   For more information, see Extracting a Database for Multiple Users.

9. (Optional). To use strong encryption for the local database, click New one time for each parameter that is described in the following table.

   Parameter Name	Description
   Client Database encryption method	Enter AES for strong encryption. AES is Advanced Encryption Standard.
   Client Database encryption key	To extract for a single user who requires an encrypted local database, enter a value of your own choosing for the key. For example, enter a key value, such as bbb1aa2bbb3yy2. Alternatively, to automatically create the key, you can leave the key field empty. To extract for multiple users who each require an encrypted local database, enter the following command: @//server/keyfile.txt where: server/keyfile.txt is the path to a text file that contains pairs of user IDs and their encryption keys. To separate each pair, you can use a space, comma, semicolon, new line, or a tab.

   If you use strong encryption for the local database, then Siebel Remote sends and stores the encryption key in encrypted format.

10. (Optional). To extract a database that is not encrypted, you do the following steps:
    1. Click New, and then enter the parameter that is described in the following table.

       Parameter Name	Value
       Client Database encryption method	none You must manually type in the following text: none

    2. Set the following parameter to False:

       Encrypt client Db password

       For more information see Parameters of the Database Extract Server Component.

11. (Optional). To use DAT format for the server database extract file, click New, and then add a parameter using values from the following table.

    Parameter Name	Value
    Data File Type	DAT

    Beginning with Siebel CRM version 8.0, the default Data File Type is BCP (Bulk Copy). A database extraction that uses BCP might complete more quickly than an extract that uses DAT. If the server database contains an encrypted field, then you might prefer to use the compressed binary DAT format instead of BCP, which displays all field values in clear text.

12. (Optional). To specify a password for the database administrator on the remote client, click New, and then add a parameter using values from the following table.

    Parameter Name	Value
    Client DBA Password	Use the same value that you use with Generate New Database.

13. With the Database Extract record still chosen, click Start in the Jobs list.

    Siebel Remote extracts the server database for the remote client. This step might require a few minutes to finish.

    If you receive an error that is similar to the following, then see Rerunning a Database Extract to Avoid a Concurrency Error:

    Target node is currently in use by another server process

14. If you observe performance degradation during the extract, then take corrective action.

    For more information, see Monitoring Performance of a Server Database Extract.

Caution About Extracting the Server Database

CAUTION:  If possible, perform all the items listed in this topic before you extract the server database. If you do not perform these items before you extract the server database, then it might be necessary for you to reextract the server database for all users, which can be a time consuming and tedious task.

If possible, perform all the following tasks before you extract the server database:

• To maintain integrity across databases, the same conflict resolution rule must be in effect for the local databases and for the server databases. If possible, specify the rule as part of the initial Siebel Remote implementation on your server database before you run a database extract for any client so that Siebel Remote copies the rule consistently to all remote clients.
• If possible, set the Intersection Table Conflict Resolution field before you extract any remote client. If you change the Intersection Table Conflict Resolution field after extraction, then you must reextract all remote clients. If you do not reextract all clients, then server data and client data might diverge.
• If possible, set the Intersection Table Merge Rule field before you extract any remote client. If you change this field after extraction, then you must reextract all clients. If you change this field after extraction, and if you do not reextract all clients, then server data and client data might diverge.
• Before you start time filtering in a production environment, make sure you test it thoroughly. Make sure the cutoff dates you choose for time filtering allows the necessary data to reach the test remote clients. Deployment of an inappropriate cutoff date can prevent stable but necessary data from reaching the remote client. Examples of this data include price lists or rate lists. If you must choose an earlier cutoff date after you deploy Siebel Remote to a production environment, then it might be necessary for you to reextract all remote clients.
• If you change the server database schema after you deploy Siebel Remote to a production environment, then you must run the Generate New Database Template server component and reextract all remote clients, or you must use a Siebel Anywhere kit to distribute the change to all remote clients. It is strongly recommended that you do this even if the schema change only affects a private dock object because individual tables in a private dock object might become visible to a remote client at a later time. Problems can occur if the server database structure does not match the local database structure.
• If possible, define all positions and routing models before you deploy Siebel Remote to a production environment. If you must change the Position for a user or a routing model, then you must reextract the server database to the remote client to delete records that must no longer be visible to the user as determined by the new position for the user. This technique also improves the performance of the Transaction Router because a reorganization of the reporting hierarchy for your company creates many transactions on the Siebel Server, which creates a backlog.
• If possible, set the routing group before you deploy Siebel Remote to a production environment. If you change the routing group from Standard to Full Copy after deployment, then you must reextract all remote clients that are associated with the regional node.
• You must not rename or delete any DX files that exist in the siebsrvr\docking\client\inbox directory. If you rename or delete these files, then you will lose the transactions and you must reextract the remote client.

Rerunning a Database Extract to Avoid a Concurrency Error

If another Siebel Server process uses the target node, then Siebel CRM might display an error message. For example, if another Siebel Server process is accessing the inbox or outbox directory for user sjones, then Siebel CRM might display an error message that is similar to the following:

Target node "sjones" is currently in use by another server process. Try again later.

Rerunning a database extract to avoid a concurrency error

• Wait a few minutes, and then rerun the server database extract.

  If you wait a few minutes, then the file might be available and unlocked.

Monitoring Performance of a Server Database Extract

if you observe performance degradation, then it might be necessary to limit the number of children records for each parent record. The visibility for all children must be examined for each child. Attaching many children to the same parent record can degrade the performance of the router and the server database extract. This is true for objects with limited visibility. If more than 10,000 child records are attached to a parent record, such as with contacts attached to an account, then you must thoroughly test the performance of the server database extract and router.

How Siebel CRM Manages Changes in the S_DOCK_SESSION Table

Beginning with Siebel CRM version 7.5, Siebel Remote stores the synchronization history of the remote client in the S_DOCK_SESSION table. It uses the data in this table for one of the Siebel Remote status reports. Although it does not purge the data in this table, reextracting a remote client automatically cleans up table rows that Siebel Remote associates with that client. For example, if you create a new account and assign it to the remote client, then Siebel Remote adds a new row for this client to the S_DOCK_SESSION table. If you reextract and reinitialize the remote client, then Siebel Remote removes the row that it created in the S_DOCK_SESSION table for the account. To clean up the S_DOCK_SESSION table, it is not necessary to resynchronize the remote client.

The LAST_ATTACH_BYTES column of the S_DOCK_SESSION table contains the last chunk of bytes for the last file attachment that Siebel Remote processes. It uses this column with the LAST_ATTACH_FILE column, which stores the file name of the last attachment file that it processed.