Bookshelf v7.5: Capacity Planning

Siebel Server Installation Guide for UNIX > Creating the Oracle Database > Creating the Database >

Capacity Planning

One of the most important factors to determine about your database is its overall size. In your planning, you will need to allocate space for system storage, rollback or temporary storage space, log files, and other system files required by Oracle, as well as space for Siebel data and indexes. If you allocate too little space for your system, performance will be affected and, in extreme cases, the system itself may be halted. If you allocate too much, you will waste space.

The space needed by Oracle will vary primarily based on the total number and types of users supported, as well as the transaction mix and rate. Consult the Oracle documentation for more information on these requirements.

The space required for Siebel data and indexes will vary depending on what Siebel eBusiness Applications functionality you will implement and the amount and nature of data supporting that functionality.

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

Be certain to factor growth rates into your total size calculation.

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

Determine the Siebel eBusiness Applications 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 your total user base.

Using standard sizing procedures for your specific database, and Siebel Data Model Reference, 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 will determine the estimated data size for the largest entities.

You must add additional space for the storage of other Siebel 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.

Allow for a margin of error in your total size calculation.

If you require additional help in planning capacity and the number of machines required for your implementations, contact Siebel Technical Support.

Sizing Redo Logs

If redo logs are too small, frequent log switches occur, creating resource-intensive Oracle check-pointing in which all dirty buffers are flushed. Although a range of 10 to 15 minutes or longer for log switching is preferable under a normal OLTP (Online Transaction Processing) load, during periods of heavy DML (Data Manipulation Language) activity (for example, during large EIM loads or upgrades), the logs may switch more frequently than every two minutes. However, when this occurs, overall database performance will suffer as a result.

You can check the frequency of this operation either in the alert log or by querying v$loghist. It is best to use verification when there is the greatest activity and the heaviest load on the database.

If this activity occurs too frequently, drop and recreate individual redo log groups with larger sizes.

To achieve optimum performance, placing subsequent log file groups on alternative devices is critical. This prevents the archiver process (ARCH) and the log writer process (LGWR) from competing for I/Os on the same device, since ARCH reads from the previous group, while LGWR is writing to the current group. This process causes the read-write head of the device to move back and forth, contributing to inefficient I/O. When log file groups are located on separate devices, the speed of both processes improves as they do not contend for the same hardware resource.