Siebel Installation Guide for UNIX: Servers, Mobile Web Clients, Tools > Guidelines for Configuring the RDBMS >

Creating Oracle Database Objects

To help you automate database instance creation, Siebel Systems provides sample scripts (CrBlankOracleSiebelDEMO.sql and CrBlankOracleSiebelDEMOPostCrDB.sql), located in the $SIEBEL_ROOT/dbsrvr/Oracle directory. Use these scripts as a reference to create scripts based on your deployment's requirements to create database objects. Before using the scripts, make sure you read the file CrBlankOracleSiebelDEMOReadMe.txt.

Use a small, nonproduction environment for testing purposes.

After you install the Siebel Database Server files on the Siebel Server machine (described in the Oracle sections of Installing the Siebel Database Server), you may modify the database table and index creation scripts to specify the file group names you created for Siebel tables and indexes. For more information, see Overriding Oracle Default Storage Parameters.

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 precaution prevents the archiver process (ARCH) and the log writer process (LGWR) from competing for I/Os on the same device, because 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.