In general, you do not need to map tablespaces for development or demonstration systems manually. You can use the default configuration.

For information about managing tablespaces, see "Managing Tablespaces" in Database Administrator’s Guide in the Oracle database documentation.

Create the actual tablespaces before running the pin_setup configuration script since they require existing tablespaces. Only the two default tablespaces must be created if you have not edited the pin_tables.values file to assign tables to nondefault tablespaces.

Table 2-1 provides guidelines for some database and operating system configuration options specific to BRM. For information on other parameters, see the Oracle database documentation.

For information about memory configuration, see "Tuning Database Memory " in Database Performance Tuning Guide and "Managing Memory" in Database Administrator’s Guide in the Oracle database documentation.

- dm stmt_cache_entries -1080

To determine the storage device type to select, and for other storage considerations, see "I/O Configuration and Design" in Database Performance Tuning Guide in the Oracle database documentation.

For information about the redo log buffer, see "Configuring the Redo Log Buffer" in Database Performance Tuning Guide in the Oracle database documentation.

Oracle strongly recommends that you run your database in automatic undo management mode instead of using rollback segments. For more information, see "Managing Undo" in Database Administrator’s Guide in the Oracle database documentation.

Temporary storage should be three to four times the size of the largest table (usually EVENT_T).

The objects that require the most storage space in a default BRM installation are accounts, bills, and events. The tables that correspond to these objects are also the ones with the most activity:

• ACCOUNT_T
• BAL_GRP_T
• BAL_GRP_BALS_T
• BAL_GRP_SUB_BALS_T
• PURCHASED_DISCOUNT_T
• PURCHASED_PRODUCT_T
• BILL_T
• BILLINFO_T
• ITEM_T
• INVOICE_FORMATS_T
• SERVICE_T

For most customers, the following event tables will be very large:

• EVENT_BAL_IMPACTS_T
• EVENT_BILLING_PRODUCT_T
• EVENT_ESSENTIALS_T
• EVENT_T

For Telco service customers, the following tables will be very large:

• EVENT_DLAY_SESS_TLCS_T
• EVENT_DLYD_SESSION_TLCO_GPRS_T
• EVENT_DLYD_SESSION_TLCO_GSM_T

Your customizations might create additional large tables. For example, if you store a lot of account profile data, the following tables will also be large:

• PROFILE_T
• PROFILE_SERV_EXTRATING_DA_T
• PROFILE_SERV_EXTRATING_T

Other tables may be large depending on your implementation. Your estimate should not include space gained by archiving.

English databases store VARCHARs as one byte per character. Localized versions of BRM can store these strings in AL32UTF8 or UTF8 format. BRM uses the AL32UTF8 character set. Character strings such as names, addresses, descriptions, and notes that can be manipulated by BRM GUI tools can vary in size. To size the database, you must determine roughly what percentage of the database consists of strings that can vary in size.

Choose a storage model based on the total size of your database, which you can determine by summing your data, index, rollback, and temporary tablespaces.

• Use Test or Small for test or demonstration databases.

• Use Large for production databases.

You can set the storage option during installation. See "Installing BRM".

You can set the values used to create the tables using the pin_tables.values file. To set these values:

1. Open the BRM_home/setup/scripts/pin_tables.values file in a text editor.

2. To find the block to update, locate the first instance of the following string:

   PIN_CONF_STORAGE_TEST

3. Determine the block to update. Table 2-2 contains the mapping between the parameter names and the storage option selected in the installer:

   Table 2-2 Mapping of Table Configurations to Installation Values

   pin_tables.values Variables	Storage Model Type
   @PIN_CONF_STORAGE_TEST	Test
   @PIN_CONF_STORAGE_MINI	Small
   @PIN_CONF_STORAGE_MIDSIZE	Medium
   @PIN_CONF_STORAGE_HUGE	Large

   For example, if you intend to select a Large configuration in the installer, update the following block:

     @PIN_CONF_STORAGE_HUGE = (
           # storage small
           "storage (initial 1m next 1m maxextents unlimited pctincrease 0 )",
           # storage medium
           "initrans 4 storage (initial 1m next 20m maxextents unlimited pctincrease 0 )",
           # storage large
           "initrans 4 storage (initial 1m next 100m maxextents unlimited pctincrease 0 )",
           # storage huge
           "initrans 32 storage (initial 1m next 100m maxextents unlimited pctincrease 0 freelists 40 )",
           # storage small
           "initrans 8 storage (initial 1m next 1m maxextents unlimited pctincrease 0 freelists 8 )",
           # storage medium
           "initrans 32 storage (initial 1m next 20m maxextents unlimited pctincrease 0 freelists 16 )",
           # storage large
           "initrans 64 storage (initial 1m next 100m maxextents unlimited pctincrease 0 freelists 32 )",
           # storage huge
           "initrans 80 storage (initial 1m next 400m maxextents unlimited pctincrease 0 freelists 40 )"
     );

   The first four storage clauses are for table storage, and the second four are for index storage.

4. Update the storage clauses with the your required values.

During installation, BRM tables are created using one of the storage models. Therefore, the default storage clause is not used at installation. (The default storage clause specifies the storage parameters to use if no storage clause is provided). However, if you create custom tables, you must specify a storage clause, or else the default storage clause is used.

For information about managing tablespaces, see "Managing Tablespaces" in Database Administrator’s Guide in the Oracle database documentation.

In our benchmark implementations, we use locally managed tablespaces with the bigfile option and Oracle Automatic Storage Management (Oracle ASM). This is much easier than managing them manually. If you use the bigfile option, make sure that you monitor the file space usage so that disks don't become full. Following are some sample commands to create data files for a large production environment.

If you are using Oracle ASM, you can find where tablespaces will be created by logging in to SQL*Plus as a user with sysdba permissions and running the following command:

show parameters DB_CREATE_FILE_DEST;

For the first schema, create three bigfile tablespaces:

create bigfile tablespace PIN_TABLE DATAFILE SIZE 524288M AUTOEXTEND ON NEXT 8192M MAXSIZE UNLIMITED;
create bigfile tablespace PIN_INDEX DATAFILE SIZE 262144M AUTOEXTEND ON NEXT 8192M MAXSIZE UNLIMITED;
create bigfile temporary tablespace PIN_TEMP TEMPFILE SIZE 65636M  AUTOEXTEND ON NEXT 4096M MAXSIZE UNLIMITED;

Create three additional bigfile tablespaces for each additional schema, changing the tablespace name to be in line with the schema number. For example, commands for the second schema could be:

create bigfile tablespace PIN_2TABLE DATAFILE SIZE 524288M AUTOEXTEND ON NEXT 8192M MAXSIZE UNLIMITED;
create bigfile tablespace PIN_2INDEX DATAFILE SIZE 262144M AUTOEXTEND ON NEXT 8192M MAXSIZE UNLIMITED;
create bigfile temporary tablespace PIN_2TEMP TEMPFILE SIZE 65636M  AUTOEXTEND ON NEXT 4096M MAXSIZE UNLIMITED;

Adjust the values for SIZE and NEXT to meet your needs. For a multischema environment, create the same tablespaces for each schema.

For more information about locally managed tablespaces, see "Locally Managed Tablespaces" in Database Administrator’s Guide in the Oracle database documentation.

For more information about Oracle ASM, see "Introducing Oracle Automatic Storage Management" in Administrator's Guide in the Oracle database documentation.

If you are using Oracle RAC, for more information about managing storage, see "Storage Considerations for Oracle Grid Infrastructure and Oracle RAC" in Grid Infrastructure Installation and Upgrade Guide for Linux in the Oracle database documentation.

If you use Automatic Storage Management, you generally do not need to map tables to tablespaces.

The size of the database, in turn, determines the minimum number of disks required for the database. Remember to consider disk space required for other purposes, for example, the operating system, BRM, log files, temporary storage, and swap files.

You should have enough disks to avoid performance bottlenecks. In addition, you can increase performance by spreading the most-used tables over multiple disks.

After determining the number of disks available for the database, divide the tablespaces among those disks.

Half the remaining space will be used for mirroring. Put mirrors on different disks than their corresponding tables and indexes. The number of mirror logical devices will be equal, in number and size, to their corresponding table and index logical devices.

After allocating disk space for mirrors, divide the remaining disk space using the ratio of 2:1 between tables and indexes. That is, two-thirds of the space will be used for table logical devices and one-third of the space will be used for index logical devices.

Create the logical devices over the remaining physical disks using the above guidelines.

Create the actual tablespaces before running the pin_setup configuration script since they require existing tablespaces. Only the two default tablespaces must be created if you have not edited the pin_tables.values file to assign tables to nondefault tablespaces.

See "BRM Preinstallation Tasks" for information about creating the BRM database.

Table 2-3 provides guidelines for some database and operating system configuration options specific to BRM. For information on other parameters, see the Oracle database documentation.

For information about memory configuration, see "Tuning Database Memory" in Database Performance Tuning Guide and "Managing Memory" in Database Administrator’s Guide in the Oracle database documentation.

For information about database performance tuning, see "Oracle Database Configuration Best Practices" in High Availability Overview and Best Practices in the Oracle database documentation.

- dm stmt_cache_entries -1080

open_cursors = 4192 (minimum value: statement cache size + number of dm_backends)

For information about using the optimizer, see "Influencing the Optimizer " and "Optimizer Statistics Concepts" in SQL Tuning Guide in the Oracle database documentation.

In our benchmark implementations, we use the ALL_ROWS optimizer mode. For performance reasons, it is important to gather good optimizer statistics.