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 modifications to all remote clients. For more information, see Controlling the Data That Siebel Remote Routes to Clients.

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

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 that reside outside of 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 How Siebel Remote Extracts Local Databases and Options for Extracting the Server Database.

To extract the server database

1. Make sure you complete all required work.

   CAUTION:  Do 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 where Siebel Remote runs the Database Extract job.

   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 server is the same as the Requested Server.

8. Locate the Job Parameters list that resides below the Jobs list and the Job Detail form.
9. Click New in the Job Parameters list that you located in Step 8, and then add a parameter using values from the following table.

   Parameter Name	Description
   Client Name	Enter the remote client name.

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

10. Optional. To use strong encryption for the local database, click New one time for each parameter that the following table describes.

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

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

11. Optional. Do the following work to extract a database that is not encrypted:
    1. Click New, and then enter the parameter that the following table describes.

       Parameter Name	Value
       Client Database encryption method	You must manually enter 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.

12. 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, Siebel Remote sets the Data File Type to BCP (Bulk Copy), by default. 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. DAT displays all field values in clear text.

13. 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.

14. 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

15. If performance degrades 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:  It is recommended that you do all the items that this topic describes before you extract the server database. If you do not do this, then it might be necessary for you to reextract the server database for all users, which can be a time consuming and tedious task.

Do all the following tasks before you extract the server database:

• Make sure the same conflict resolution rule is in effect for the local databases and for the server databases to maintain integrity across databases. You can 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.
• Set the Intersection Table Conflict Resolution field before you extract any remote client. If you modify this 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.
• Set the Intersection Table Merge Rule field before you extract any remote client. If you modify this field after extraction, then you must reextract all clients. If you modify this field after extraction, and if you do not reextract all clients, then server data and client data might diverge.
• Make sure you test time filtering thoroughly before you use it in a production environment. Make sure the cutoff dates you choose for time filtering allow the necessary data to reach the test remote clients. Deploying an incorrect cutoff date can prevent stable but necessary data from reaching the remote client. Price lists or rate lists are examples of this data. 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 modify 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 this modification to all remote clients. It is strongly recommended that you do this even if this modification 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 might occur if the server database structure does not match the local database structure.
• Define all positions and routing models before you deploy Siebel Remote to a production environment. If you must modify the Position for a user or a routing model, then you must reextract the server database to the remote client so that Siebel Remote deletes the records that it must not display to the user, according to the modified position. This configuration also improves Transaction Router performance because a reporting hierarchy reorganization for your company creates many transactions on the Siebel Server, and these transactions might cause a backlog.
• Set the routing group before you deploy Siebel Remote to a production environment. If you modify 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 folder. 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 folder 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 Modifications 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 remove 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 that stores the file name of the last attachment file that it processed.