Performance Tuning :

Performance Tuning of demantra can be broadly divided into 2 groups listed below.
1. Tuning the Oracle database.
2. Tuning the Demantra applications

1. Tuning the Oracle database

1.1 Database parameters
There are a few database parameters that have a significant impact on the worksheet performance.
These need to set properly to get optimal database performance.
a. DB_BLOCK_SIZE parameter needs to be set to either 16 or 32. If the database is already created
with a different value then the database needs to be rebuilt.
b. DB_FILE_MULTIBLOCK_READ_COUNT parameter will read multiple blocks at the same time
when the database is scanning the tables and indexes. Also it affects the behavior of the CBO. So
it should be set to a value derived by the formula
(Number of Physical disk blocks * SAN read-ahead) / Oracle block size
c. CURSOR_SHARING parameter needs to be set to FORCE. This reduces the amount of work done
to generate an execution plan.
d. SGA_TARGET parameter determines the shared memory size of the database instance and must
be set to a value of 60% of the total memory available
e. PGA_AGGREGATE_TARGET which specifies the private memory available to Oracle users can be
set to 25% of the total memory available.
f. optimizer_index_cost_adj specifies the cost to access indexes should be set to a value between
20 to 50.
g. optimizer_index_caching parameter specifies how much of an index resides in the database
buffer cache and should be set to a value between 50 to 80.
h. parallel_max_servers specifies the maximum number of parallel servers available for parallel
execution. It should be set to a value based on the maximum number of CPUs in the system.
i. parallel_min_servers specifies the minimum number of parallel servers to be started at instance
startup. For e.g. if there are 8 CPUs in the system then this can be set to 2.

1.2 Optimizer Statistics

Optimizer statistics on the demantra schema objects need to gathered at frequent intervals.
These optimizer statistics are managed via a PL/SQL package DBMS_STATS. It provides server

PL/SQL procedures to gather the statistics of a table, schema or entire database. This package
has an estimate percentage which can be used to specify the sampling percentage of the rows
that need to be sampled while gathering the statistics.
exec dbms_stats.gather_table_stats(null, 'TABLEX', estimate_percent => 10);
In the example given the estimate percentage has been specified as 10% which can be changed
as required.

1.3 Row Chaining and Migration

Row chaining and migration significantly impacts the performance of demantra. Row chaining
and row migration happens when a row is too large to fit into an existing database block. This
happens due to inserts of new rows and updates to existing rows in the database. Row
migration is caused specifically by small values of PCTFREE. This impacts large tables in
DEMANTRA like SALES_DATA,MDP_MATRIX etc.
To determining row chaining first we need to analyze the table using the following syntax.
Analyze table <table_name> compute statistics;
Once the statistics are gathered we can determine the extent of row chaining using the
following query.
select table_name, chain_cnt, num_rows, (chain_cnt/num_rows)*100 percent
from user_tables
where chain_cnt >0 and num_rows > 0
order by chain_cnt desc;
If the chaining percentage is more than 5% of the total table rows then the table is a fit
candidate for reorganization.

1.4 Partitioning
Demantra has few tables that can grow very large in size. This significantly impacts the
performance of the worksheets whereby worksheets take a long time to open. This is
accompanied by huge I/O as the data is searched in the entire table rather than a particular
subset of data. To reduce this problem Oracle has come out with partitioning option. SQL
queries and DML statements need not be modified to query data from partitioned tables.
Partitioning can provide tremendous benefits to a wide range of applications by improving the
performance and availability.
Range and list partitioning are the best suited for partitioning large tables like SALES_DATA in
demantra.

1.5 Redo Log Size

Demantra generates a lot of redo logging due to which log switches can happen very frequently,
in turn affecting the performance of the oracle instance. To prevent this problem ensure that
the redo log members are sized properly. A redo log size of greater than 300MB to 1GB in size
is found to be ideal. The exact size can be arrived by looking into the frequency of the log
switches in the alert.log

1.6 System Statistics

System statistics need to be gathered periodically on the system database objects.

1.7 Fragmentation
Fragmentation of major objects is one of the major issues facing the demantra databases. In
order to reduce fragmentation rebuild the data table. While rebuilding the data table reorder
the columns so that the highly populated columns are at the beginning of the table and columns
with no data at the end of the table.

1.8 Parallelism
Run the worksheets utilizing multiple CPUs in parallel. This will effectively use the CPUs and
help in faster response times. Generally indexes of major tables like MDP_MATRIX,SALES_DATA
should be set to a degree of 1 as this will avoid any unexpected CBO behavior. For major tables
like SALES_DATA and MDP_MATRIX set the parallel degree to 8 or more so that similar number
of processes execute the query.

2. Tuning Demantra Applications

2.1 Demantra parameters
There are multiple demantra parameters that need to be set depending on the customer
environment to improve performance. Some of the major parameters are listed below.
a. threadpool.query_run.size sets the maximum size of the query run thread pool . This
parameter needs to be set to a value which is the product of the concurrent users and
threadpool.query_run.per_user . E.g. if threadpool.query_run.per_user is set to 8 and no of
concurrent users are 10 the value for this parameter comes to 80.

b. threadpool.query_run.per_user specifies the amount of threads that a single user can use to
query the data. Can be set to a value between 4 to 12.
c. Import BlockSize which specifies the maximum size of the copy paste thread pool. This
needs to be ideally set to a value between 5000 to 10000
d. MaxDBConnections parameter specifies the maximum number of simultaneous database
connections which can be set from 100 to 200.
e. worksheet.data.comb.block_size controls the blocksize used for worksheet data retrieval
f. worksheet.full.load is set to 1 when using crosstab worksheets.
g. client.worksheet.calcSummaryExpression specifies whether summary line client expressions
are supported. If set to true i.e. 0 then simple expressions are supported.

2.2 Tuning the Application server

The demantra applications uses JVM which needs to be sized adequately so that there is sufficient
memory for the worksheets. There are 2 major JVM parameters that can be used to control the total
amount of memory available to the JVM.
-Xmx : Maximum memory that the JVM will consume from the OS. This needs to be typically set to
1024M to 1536M
-Xms : The total memory allocated to the application when it starts up. This needs to be set from
256M to 512M

These 2 parameters can be set in the $IAS_ORACLE_HOME\opmn\conf\opmn.xml file and services

bounced for the new settings to take effect.

2.3 Worksheet Caching

Enable worksheet caching depending on the volume of the data used in the worksheet. This
substantially reduces the time taken to open the worksheet as the system stores the subset of data
that is part of the worksheet in a separate table and so the retrieval is faster compared to regular
worksheets. There are 2 types of worksheet caching.

Automatic caching is good for small worksheets.

Manual caching is suitable for larger worksheets where the data does not change
frequently