Siebel Deployment Planning Guide > Siebel Infrastructure Planning >

Defining High Availability Policies

This topic is a step in Process of Infrastructure Planning.

This infrastructure planning step defines business policies regarding availability of servers.

For more information about high availability, see High Availability Deployment Planning.

Siebel Servers

For each business location, assess the impact of losing each server component. Consider the possibility of the component failing, rather than the hosting platform itself. Individual server components that are important to normal application function must be identified in your planning and review phases. Work closely with your implementation team to identify all components that could represent single points of failure.

After you complete this analysis, define high-availability policies for all applications and services. Decide how long your business can tolerate not having access to key applications. Also, decide how long your business can tolerate degraded performance.

For example, a company decides that Siebel Call Center will run 24 hours a day, seven days a week, and the maximum acceptable downtime is 30 minutes. The company also decides the maximum time it can accept degraded performance is one hour.

Finally, at each business location, list all the server components to which each policy applies. This analysis forms the basis for implementing a high-availability strategy as part of hardware planning.

Database Platform and Data Integrity

The server platform that hosts the Siebel Database is crucial to Siebel deployment operations. For this reason, it is important to define high-availability and data integrity policies specifically for the database server. The following policies are recommended:

  • Cluster database servers to protect against platform hardware failures.
  • Use redundant disk arrays (RAIDs) for disk storage. RAID 1+0 is recommended because it provides maximum performance, and there is no data loss if a disk fails. Do not implement RAID 0 arrays. RAID 0 offers good performance but does not protect data adequately in the event of a disk failure.
  • Enable transaction logging.
  • Observe the following best-practice guidelines for storing database files:
    • Store data and indexes on separate disk subsystems.
    • Store active log files and archived log files on separate disk subsystems.
    • Store the database and database control files on separate disk subsystems.
  • To allow for good OLTP performance, set up four rollback segments (if you choose to use them) for each 20 to 40 users. The size of rollback extents should be 100 KB for Initial extents and 100 KB for Next extents. If you are using Siebel EIM, also create several additional, large rollback segments to support EIM loads.

Siebel Gateway Name Server

The Siebel Gateway Name Server maintains the configuration information for all Siebel Servers in all the Siebel Enterprise Servers it manages. Loss of the Gateway Name Server due to a disk failure could bring your Siebel deployment to a halt while the system is restored.

It is strongly recommended that you install a RAID or some other type of redundant disk configuration on your Gateway Name Server.

Mobile Users

A Siebel Server temporarily stores transaction files that move to and from Siebel Remote mobile users. The loss of these files will result in the need to re-extract the database for all affected mobile users. (Siebel Remote supports synchronization of data between Siebel Mobile Web Clients and the Siebel Database through a dial-up connection.)

It is strongly recommended that you install a RAID or some other type of redundant disk configuration on Siebel Servers that run Siebel Remote.

Siebel Deployment Planning Guide Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices.