Siebel EIM Architecture Planning Requirements

You must consider the size and complexity of the implementation before executing any single item with the Siebel application. Aspects that have a direct impact on how the production application will perform might not be your highest priority when you begin your Siebel implementation. However, the decisions made during the initial phases of an implementation have a far reaching impact, not only on performance and scalability but also on the overall maintenance of the Siebel application.

It is strongly recommended to have a Siebel certified principal consultant or architecture specialist from Oracle Advanced Customer Services involved in designing the most effective logical and physical architecture for your organization. This includes capacity planning and system sizing, physical database layout, and other key architecture items. Contact your Oracle sales representative to request assistance from Oracle Advanced Customer Services.

For more information, see the following:

• "Database Sizing Guidelines"

• "Database Layout Guidelines (Logical and Physical)"

Database Sizing Guidelines

This topic is part of "Siebel EIM Architecture Planning Requirements".

One of the most important factors to determine about the database is its overall size. During the planning phase, you need to allocate space for system storage, rollback segments and containers, temporary storage space, log files, and other system files required by the relational database management system (RDBMS), as well as space for the Siebel application data and indexes. If you allocate too little space for the system, then performance will be affected and, in extreme cases, the system itself can be halted.

The space needed by the database depends on the total number and types of supported users. It is recommended that you consult your vendor RDBMS technical documentation for more information about these requirements.

The space required for Siebel data and indexes depends on the functionality being implemented and the amount and nature of data supporting this functionality.

The process for making accurate database size calculations is a complex one involving many variables. Use the following guidelines:

• Determine the total number, and types, of users of Siebel Business Applications (for example, 500 sales representatives and 75 sales managers).

• Determine the functionality that you will implement and the entities required to support them. Typically, the largest entities are as follows:

  • Accounts

  • Activities

  • Contacts

  • Forecasts

  • Opportunities

  • Service Requests

• Estimate the average number of entities per user (for example, 100 accounts per sales representative) and calculate an estimated total number of records per entity for the total user base.

• Using standard sizing procedures for the specific database, and Siebel Data Model Reference on My Oracle Support (Article ID 2285310.1), calculate the average record size per entity and multiply by the total number of records. Typically, these entities span multiple physical tables, all of which must be included in the row size calculation. This determines the estimated data sizes for the largest entities.

• You must add additional space for the storage of other Siebel application data. A rough guideline for this additional amount would be one-half the storage required for these key entities.

• Indexes typically require approximately the same amount of space as data.

• Be sure to allow for a margin of error in the total size calculation.

• Be sure to factor growth rates into the total size calculation.

Database Layout Guidelines (Logical and Physical)

This topic is part of "Siebel EIM Architecture Planning Requirements".

The overall performance of Siebel Business Applications largely depends on the input/output (I/O) performance of the database server. To achieve optimal I/O performance, it is critical that the tables and indexes in the database be arranged across available disk devices in a manner that evenly distributes the I/O load.

The mechanism for distributing database objects varies by RDBMS, depending on the manner in which storage space is allocated. Most databases have the ability to assign a given object to be created on a specific disk. These objects, and guidelines for some of them, are provided in the following list.

A redundant array of independent disks, or RAID, can provide large amounts of I/O throughput and capacity, while appearing to the operating system and RDBMS as a single large disk (or multiple disks, as desired, for manageability). The use of RAID can greatly simplify the database layout process by providing an abstraction layer above the physical disks while ensuring high performance.

Regardless of the implemented RDBMS and the chosen disk arrangement, be sure that you properly distribute the following types of database objects:

• Database log or archive files.

• Temporary workspace used by the database.

• Tables and Indexes: In most implementations, the tables and corresponding indexes in the following list tend to be some of the more heavily used and must be separated across devices. In general, the indexes listed in Table 10-1 must be placed on different physical devices from the tables on which they are created.

Table 10-1 Indexes Recommended to Be Placed on Different Physical Devices

Table Name	Table Name
S_ACCNT_POSTN	S_PARTY_REL
S_OPTY	S_PARTY
S_ADDR_ORG	S_SRV_REQ
S_OPTY_POSTN	S_EVT_ACT
S_CONTACT	S_OPTY
S_POSTN_CON	S_ORG_EXT
S_DOCK_TXN_LOG

Note: If you plan on making extensive use of Siebel EIM, then put the key EIM tables (based on the unique business requirements) and their corresponding indexes on different devices from the Siebel base tables and indexes, because all of them are accessed simultaneously during Siebel EIM operations.