|
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 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. The Database Extract server component (alias DbXtract) does the following work:
- Identifies visible instances for all members of a list of nodes.
- Identifies the commonly visible instances and extracts the records only one time for all these nodes.
- 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. CAUTION: If the Siebel Gateway uses LDAP authentication, then, when you run a job for Database Extract, you must explicitly specify valid database credentials to connect to the Siebel database. Otherwise, the component task fails, with this message: Unable to connect to Database. For example, you might run the job by entering a command like this on the srvrmgr command line:
start task for comp dbxtract with username=user_name, password=pwd
Related Topics
How Siebel Remote Extracts Local Databases
Controlling the Data That Siebel Remote Routes to Clients
Options for Extracting the Server Database
Parameters of the Database Extract Server Component
Related Books
Siebel Performance Tuning Guide
To extract the server database
- Make sure you complete all required work.
CAUTION: Do all required work before you extract the server database.
For more information, see Requirements for Extracting the Server Database.
- Log in to the Siebel Server with administrator privileges.
For more information, see Logging in to the Siebel Server as an Administrator.
- If the local database contains unsynchronized transactions, then you must attempt to synchronize those transactions before you proceed.
- Navigate to the Administration - Server Management screen, and then the Jobs view.
- In the Jobs list, click New.
- In the Component/Job field, choose Database Extract from the picklist.
- 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.
- Locate the Job Parameters list that resides below the Jobs list and the Job Detail form.
- Click New in the Job Parameters list that you located in Step 8, and then add a parameter using values from the following table.
|
|
Client Name |
Enter the remote client name. |
For more information, see Extracting a Database for Multiple Users.
- Optional. To use DAT format for the server database extract file, click New, and then add a parameter using values from the following table.
- 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.
|
|
Client DBA Password |
Use the same value that you use with Generate New Database. |
- 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
- If performance degrades during the extract, then take corrective action.
For more information, see Monitoring Performance of a Server Database Extract.
Requirements for Extracting the Server Database
Perform or review all of 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 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
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
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.
|
