Installation Instructions for the

UC4 Oracle Databases

This document describes the fundamental hardware and
configuration requirements for the installation and
operational use of Oracle databases with the UC4 platform.
The information is aimed particularly at customers who
operate/plan medium to large-sized UC4 systems. For this
reason, it focuses on the various high-availability scenarios
of Oracle databases, such as the different configurations of
Real Application Cluster (RAC) and Data Guard.
The hardware and software configurations described here
include recommendations for the production operation of
the UC4 platform on a proprietary database server.
Because the hardwares resource requirements depend on
the respective implementation and the valid installation
requirements of the database manufacturer, we
recommend contacting UC4 Support or a UC4 expert in
certain cases.
Supported versions................................................2
Scenarios .............................................................2
General installation requirements ..........................2
Scenario 1 (stand-alone database) ........................4
Scenario 2 (hardware cluster)...............................8
Scenario 3 (RAC) ................................................8
Scenario 4 (Data Guard) .................................... 10
Summary ........................................................... 12

Copyright 2008 UC4 Software GmbH (UC4), All rights

reserved. The materials in this publication are protected by
copyright and/or other intellectual property laws. Any
unauthorized use of the materials in this publication may lead to
a breach of these laws. Unless explicitly authorized, the
reproduction of the information or documents in this publication
in any form without prior written consent by UC4 is prohibited.

Supported versions
Oracle 10.2 Enterprise Edition
Due to the limits as regards online reorganization, the Oracle Standard Edition is not suitable for a round-theclock operation of a UC4 system and should therefore only be used for smaller UC4 systems.

Scenarios
Both the general settings for operating an Oracle database and the particularities of the database configurations
that are supported by the UC4 platform are described below.
General installation requirements
Hardware/infrastructure

We recommend using an external disk subsystem with a connection via Fibre Channel for the data files.
Under no circumstances should local disks with software RAID be used, as this could negatively affect
the performance of the database and thereby that of the entire UC4 system.

Latency periods are not too long when the UC4 platform Server accesses the database (ping response
with 8 K packet size < 1 ms). The same requirement applies when using RAC or Data Guard for the
communication between database nodes.

The speed of light is the physical limit for the distance between UC4 server and database that is
theoretically possible, because a signal can cover only a maximum of 200 km/ms under optimal
conditions (fibre optic cable without attenuation). This means that for a ping to a remote system with a
response time of 1 ms the distance may only be between 10 and 20 km. Whether such a distance can be
bridged in practice without inserting active components (repeaters) depends on the cable attenuation,
among other things. If the attenuation is too high, additional components must be inserted that may
further increase the signal propagation delay. The signal time may increase further if the electrical signals
have to be converted into light waves.

The database server must have sufficient RAM and a suitable swap area on the local disk.

< 2 GB => SWAP = RAM;

> 2 GB => SWAP = RAM x 0.75

No swap-in (SI) may take place.

The database system(s) must be equipped with CPUs appropriate to the load. The run queue length of
the available processors under high load can serve as a guideline in this respect. If the run queue is
frequently longer than 1, you may need to employ more CPUs.
o

RUN QUEUE LENGTH <= COUNT of CORES

The number of active components, such as routers, switches or firewalls on the path between the UC4
server and database should be minimized so as not to slow down access and to avoid single points of
failure.

Internal UC4 parameters

We recommend reconfiguring the following UC4 parameters for use with Oracle databases:

Adjustment to UC_HOSTCHAR_DEFAULT/ customer-specific UC_HOSTCHAR_xxxx

Parameter REPORT_BLKSIZE=8000

Reconfiguration UC_SYSTEM_SETTINGS
Parameter REPORT_BLKSIZE=8000
Parameter LAST_USE=0

The LAST_USE parameter in the UC4 UC_SYSTEM_SETTINGS variables affects performance in the RAC/Data
Guard environment in particular, but it can also lead to improvements in performance for stand-alone databases.

Database

The database block size should be set to 8192 bytes during installation. This setting should be the default
for Oracle 10g.

The following NLS character sets are available for UC4 operation. The character set must be set during
installation of the database.
1. GERMAN_GERMANY.WE8ISO8859P15
2. GERMAN_GERMANY.WE8ISO8859P1
3. AMERICAN_AMERICA.WE8ISO8859P15
4. AMERICAN_AMERICA.WE8ISO8859P1
After installation, the setting can be checked using the SQL statement
select * from sys.nls_database_parameters;

Sample output:
PARAMETER
-----------------------------NLS_LANGUAGE
NLS_TERRITORY
NLS_CURRENCY
NLS_ISO_CURRENCY
NLS_NUMERIC_CHARACTERS
NLS_CHARACTERSET
...

VALUE
---------------------------------------AMERICAN
AMERICA
$
AMERICA
.,
WE8ISO8859P1

The version of the database client installed should be the same as that of the server.

SQLNET.ORA
TCP_NODELAY = YES (Validation: Database server and client)
Setting the parameter means that an acknowledgement is not required for every packet simultaneously,
so performance improves.

SQLNET.EXPIRE_TIME <= 5 minutes (Validation: Database server) -> recommended 1

This parameter is relevant for Dead Connection Detection. During this interval,
the database server checks whether existing client sessions are still reacting.
Sessions that do not respond are closed by the server.

TNSNAMES.ORA
ENABLE=BROKEN (Validation: Database client)
This parameter must be entered at the beginning of the tnsnames entry, as shown
in the following example.

Example:
UC4P =
(DESCRIPTION =
(ENABLE=BROKEN)
(ADDRESS = (PROTOCOL = TCP)(HOST = dbhost)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = UC4P)
)
)

Operational system parameter

tcp_keepalive <= 5 minutes (Validation: Database client)

This parameter is necessary to ensure that a connection termination on the side of the database client is
detected if the database server is no longer in the position to end a database session, either in a
controlled way or using Dead Connection Detection. Existing TCP connections are checked in the preset
interval and if the remote station does not respond, the connection is automatically terminated. Thus, the
associated database session is ended and the Oracle client can send an error report to UC4 so that a new
connection can be established.

Scenario 1 (stand-alone database)

Hardware/infrastructure

CPU:

min. 4 (number of cores)

RAM:

min. 16 GB

Gigabit network connection between the UC4 servers and the database with the least possible active
components on the path.

If the data files of the database are stored externally, the speed of the external disk subsystem as well as
its high-performance connection (e.g. Fibre Channel) must be considered.

Database

Tablespaces for UC4 should be created with ASSM (Automatic Segment Space Management).
In addition to several performance advantages when inserting data, ASSM also allows tables to be
transparently reorganized.

Use of local disks

If the database is not installed on an external disk subsystem, the data files of both the index and data
tablespaces (UC4_INDEX, UC4_DATA) should be kept on physically separate disks in order to achieve
maximum I/O throughput.
In order to further improve the I/O, the tables E*, A*, R* and MELD, as well as the temporary UC4 tables
(UC_TEMP*, MQ*) should be placed in their own tablespaces or data files on physically separate disks.
For this, further data tablespaces must be created (e.g. UC4_DATA_E, UC4_DATA_A, UC4_DATA_R,
UC4_DATA_M, UC4_DATA_T).
However, the final distribution of data files always depends on the requirements and the available
infrastructure.

Reorganization with database resources

You should use Oracle SEGMENT ADVISOR here. This generates a list of all tables/indexes that require
reorganization. You can also do this manually following extensive changes in the UC4 database.

Sample for online reorganization of indexes:

sqlplus> alter index <index_name> rebuild online;

Statistics
The access statistics of the database tables should be regularly updated. To do so, a daily update job
(GATHER_STATS_JOB) is scheduled during database installation, as long as this option is not explicitly
deselected. The time of the daily update can be freely selected and should take place in the UC4 system
during times of high load, in order to calculate representative values. Should an automatic update
controlled by Oracle not take place, an update can be scheduled in UC4 with the following statement.

SQL statement to update the statistics of the UC4 database (1 row):

exec dbms_stats.gather_schema_stats('UC4',options=>'GATHER AUTO',
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt =>
'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
The following statement can also be used, which generates more suitable
statistics in certain cases.
exec dbms_stats.gather_schema_stats('UC4',options=>'GATHER AUTO',
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt =>
'FOR ALL INDEXED COLUMNS SIZE AUTO', cascade => TRUE);
To check if and when the statistics were last updated, use the 'USER_TABLES view.

Example:
sqlplus>select TABLE_NAME,NUM_ROWS,LAST_ANALYZED from USER_TABLES;
Exception:
Because it is not necessary to create access statistics for the UC_TEMP* tables (UC_TEMP, UC_TEMP1,
UC_TEMP2, UC_TEMP3,), any available statistics for these tables must be deleted and the tables then
locked so that new statistics can be created.
SQL statements:
exec dbms_stats.delete_table_stats('uc4','UC_TEMP');
exec dbms_stats.lock_table_stats('uc4','UC_TEMP');
exec dbms_stats.delete_table_stats('uc4','UC_TEMP1');
exec dbms_stats.lock_table_stats('uc4','UC_TEMP1');
exec dbms_stats.delete_table_stats('uc4','UC_TEMP2');
exec dbms_stats.lock_table_stats('uc4','UC_TEMP2');
exec dbms_stats.delete_table_stats('uc4','UC_TEMP3');
exec dbms_stats.lock_table_stats('uc4','UC_TEMP3');
Listing 1: Exceptions for automatic creation of statistics

Fragmentation
If the number of entries in the UC4 message queue (MQ* tables) has greatly increased (several 10000
entries), e.g. due to a malfunction, these tables may be very fragmented. This can hinder the
performance of the UC4 system, since it is precisely these tables that are used most. In order to
overcome the fragmentation, the following DB statements can be used when a UC4 system has stopped
(all CP and WP processes). In this case, it is necessary to cold start the UC4 system (StartMode=COLD in
ucsrv.ini or via the Context Menu in the Service Manager dialog).
truncate
truncate
truncate
truncate
truncate
truncate
truncate
truncate
truncate
truncate
truncate
commit;

table
table
table
table
table
table
table
table
table
table
table

MQCP001;
MQCP002;
MQCP003;
MQCP004;
MQCP005;
MQPWP;
MQSRV;
MQLS;
MQMEM;
MQDWP;
MQWP;

Listing 2: Defragmenting the MQ* tables (offline)

The tables can also be reorganized online (while UC4 is running) using:
alter table MQCP001 ENABLE ROW MOVEMENT;
alter table MQCP001 SHRINK SPACE CASCADE;
exec dbms_stats.gather_table_stats('UC4','MQCP001',estimate_percent=>100,
method_opt=>'FOR ALL INDEXED COLUMNS SIZE AUTO',cascade=>FALSE);

Alternatively, defragmentation can also be carried out online using alter table <TABLE> move. However,
all associated indexes must then be newly constructed and the access statistics recreated, as shown
here:
alter table MQCP001 move;
alter index PK_MQCP001 rebuild online;
alter index NK_MQCP001_BACV rebuild online;
alter index NK_MQCP001_PRIO rebuild online;
exec dbms_stats.gather_table_stats('UC4','MQCP001',estimate_percent=>100,
method_opt=>'FOR ALL INDEXED COLUMNS SIZE AUTO',cascade=>FALSE);
The above statements must be repeated for the tables MQCP002 to MQCPxxx.
alter table MQPWP move;
alter index PK_MQPWP rebuild online;
alter index NK_MQPWP_PRIORITY rebuild online;
exec dbms_stats.gather_table_stats('UC4','MQPWP',estimate_percent=>100,
method_opt=>'FOR ALL INDEXED COLUMNS',cascade=>TRUE);
The above statements must be repeated for the tables MQDWP, MQWP and MQQWP.
alter table MQMEM move;
alter index PK_MQMEM rebuild online;
exec dbms_stats.gather_table_stats('UC4','MQMEM',estimate_percent=>100,
method_opt=>'FOR ALL INDEXED COLUMNS',cascade=>TRUE);
The above statements are to be repeated for the tables MQSRV to MQLS.
Listing 3: Defragmenting the MQ* tables (online)

Tuning the database parameters

Buffer cache hit rate
In general, the buffer cache hit rate should be more than 98%. The following script is an example for
calculating the current value.
-- DB_BLOCK_BUFFERS: 'buffer cache hit rate %' should be > 98%
execute dbms_output.put_line(chr(9));
execute dbms_output.put_line(chr(9));
execute dbms_output.put_line('>>>>>> DB_BLOCK_BUFFERS: "buffer cache hit rate %"
should be > 98%');
execute dbms_output.put_line(chr(9));
declare dbg number;
cg number;
pr number;
begin
select value into dbg
from v$sysstat
where name = 'db block gets';
select value into cg
from v$sysstat
where name = 'consistent gets';
select value into pr
from v$sysstat
where name = 'physical reads';
dbms_output.put_line('db block gets
|'||to_char(dbg,'999G999G999G999'));
dbms_output.put_line('consistent gets
|'||to_char(cg,'999G999G999G999'));
dbms_output.put_line('physical reads
|'||to_char(pr,'999G999G999G999'));
dbms_output.put_line('----------------------------------------');
dbms_output.put_line('buffer cache hit rate in % |'||
to_char (round(100*(1-(pr/(dbg+cg))),2),'999D00'));
end;
/
Listing 4: Calculating the buffer cache hit rate

Memory hit rate

In general, the memory hit rate of the sort area should be greater than 99%. The following script is an
example for calculating the current value.
-- SORT_AREA_SIZE: memory hit rate % should be > 99%
execute dbms_output.put_line(chr(9));
execute dbms_output.put_line(chr(9));
execute dbms_output.put_line('>>>>>> SORT_AREA_SIZE: "memory hit rate %" should be
> 99%');
execute dbms_output.put_line(chr(9));
declare sm number;
sd number;
begin
select value into sm
from v$sysstat
where name = 'sorts (memory)';
select value into sd
from v$sysstat
where name = 'sorts (disk)';
dbms_output.put_line('sorts (memory)

|'||to_char(sm,'999G999G999'));

dbms_output.put_line('sorts (disk)

|'||to_char(sd,'999G999G999'));

dbms_output.put_line('-------------------------------');
dbms_output.put_line('memory hit Rate % |'||
to_char (round(100-(100*sd/sm),2),'999D00'));
end;
/
Listing 5: Determining the memory hit rate

Shared pool size

Out of the total number of all accesses, the percentage of unsuccessful accesses to the library cache
within the shared pool should, in general, be much smaller than 1%. The following script is an example
for calculating the current value.
-- SHARED_POOL_SIZE: 'Misses %' should be << 1%
execute dbms_output.put_line(chr(9));
execute dbms_output.put_line(chr(9));
execute dbms_output.put_line('>>>>>> SHARED_POOL_SIZE: "Misses %" should be <<
1%');
column 'misses %' format a10
select sum(pins) "Executions",
sum(reloads) "Cache Misses while Executing",
to_char(sum(reloads)/(sum(pins)+sum(reloads))*100,'990D0000') "Misses %"
from v$librarycache;
Listing 6: Calculating library cache misses

Memory Advisor
The Memory Advisor can also be used for this purpose and PGA_AGREGATE_TARGET should be used.

Scenario 2 (hardware cluster)

Hardware/infrastructure

Similar to scenario 1; it is also recommended to use identical hardware for all cluster nodes.

If the UC4 server is also running on the same cluster, then the database client must be parameterized in
such a way that a reconnect to the new DB instance can be made after pivoting a cluster.

Database

Similar to scenario 1

Scenario 3 (RAC)
The UC4 platform is not fully RAC-enabled, as it only benefits from the increased availability of one RAC system,
but its performance does not improve by using RAC technology. Instead, by setting the following parameters, you
can ensure that only one node of the RAC system is used for communication, in order to minimize data traffic
through the cluster interconnect and thereby the administration overheads. Furthermore, this reduces the
probability of deadlocks in the database through concurrent accesses of several database nodes.

Note:
In general, Oracle works within an RAC node with row-level locking. However, between the RAC nodes, blocklevel transfer and resource locking are used.
To make sure that UC4 is always only connected to one node, we recommend using Cluster Managed Services.
These must be configured so that the service is only running on one node and, if required, is moved by the
cluster software to the second node.

Example for setting up a cluster service:

srvctl add service d <DB NAME> -s <SERVICE NAME> -r <Node 1> -a <Node 2>
srvctl start service d <DB NAME> -s <SERVICE NAME>

Similarly, in TNSNAMES.ORA under CONNECT_DATA=(SERVICE-NAME=<SERVICENAME<) the service name

created with srvctl must be used.

When using an RAC system with UC4, the following database parameters must also be set.

INIT.ORA
active_instance_count = 1
This parameter is only relevant if an RAC system with exactly two nodes is used and ensures
that all database sessions are always only connected at one node. It is not required if Cluster
Managed Services are
being used.
_lm_dd_interval <= 10
This parameter determines the interval for the recognition/removal of deadlocks in the
database.
Filesystemio_options = SETALL
This parameter ensures that the database instance uses both ASYNC I/O and DIRECTIO.
This enables you to achieve the optimal level of performance at a sensible buffer cache
size.
local_listener
This parameter ensures that the database instance registers with the local listener.
remote_listener nur im RAC
This parameter ensures that the database instance registers with the other listener
in the RAC.

TNSNAMES.ORA
(LOAD_BALANCE=ON) (Validation: Database client)
The CONNECT load is thereby equally distributed across all listeners in the RAC.
(FAILOVER=ON) (Validation: Database client)
This parameter ensures that a failover of the database sessions takes place
in so far as the primary RAC node is no longer available.
Example of a corresponding tnsnames.ora entry:
UC4P =
(DESCRIPTION =
(ENABLE=BROKEN)
(ADDRESS = (PROTOCOL = TCP)(HOST = knoten1-VIP)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = knoten2-VIP)(PORT = 1521))
(LOAD_BALANCE = on)
(FAILOVER = on)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = UC4P) ### Cluster Managed Service Name
)
)
Listing 7: Example of tnsnames.ora for RAC

Oracle
Figure 1 Oracle Real Application Cluster (RAC)

Hardware/infrastructure

Similar to scenario 1; it is also recommended to use identical hardware for all cluster nodes.

A high-performance connection must be selected (at least Gigabit) for the cluster interconnect. According
to information from Oracle, RAC nodes can be operated smoothly only up to a distance of 3 km! Greater
distances make high demands on the infrastructure and the protocol being used.

Database

Similar to scenario 1

Scenario 4 (Data Guard)

Hardware/infrastructure

Similar to scenario 1; it is also recommended to use identical hardware for the Data Guard nodes.

Database

Similar to scenario 1

The characteristics of Oracle Data Guard configuration that are relevant for use with UC4 are described below.
Which specifications are used depends on the available infrastructure and the requirements.
Configuration 1 (Maximum Protection - Guaranteed Protection Mode)
Transactions are only registered as committed on the primary database if the transaction was also committed on
at least one standby database. If the transaction cannot be committed to a standby database, the primary
database is not changed.
In this configuration, if the primary database fails, production can continue after a short manual check has been
carried out to see whether the standby database was running at the time of the failure, and after the standby
database has been activated.

Oracle
Figure 2: Data Guard Maximum Protection Mode

Configuration 2 (Maximum Availability - Instant/Rapid Protection Mode)

This configuration ensures a prompt synchronization of the standby databases. However, confirmation that data
has been committed to the primary database using at least one standby database is not required to allow the
next transaction to be completed on the primary database. Therefore, the primary database does not remain
unchanged if no standby database is available. Changes in the primary database are automatically carried over to
the standby database, as soon as it is available again.
If the primary database has failed, it is essential to check whether the standby database was running at the time
of the failure.

10

 Oracle
Figure 3: Data Guard Maximum Availability Mode

Configuration 3 (Maximum Performance)

In this configuration, changes are only transferred to the standby database if the online redo log is switched.
Therefore, if the primary database fails, it cannot be assumed that the standby database is up-to-date. A manual
check of the UC4 activities since the last log change must be performed in every case.

Oracle
Figure 4: Data Guard Maximum Performance Mode

Comparing the Data Guard configurations

As a general rule, all the configurations require the same quantity of user data to be transferred between primary
and standby databases. The required workload when the primary database fails is always different. The lower the
workload during a failure, the higher the load in the form of longer response times during day-to-day operation.
For the reasons mentioned above, it must be calculated for each case how the demand on availability can be
ideally realized with the infrastructure that is currently available.

11

Data Guard
Mode

Workload during
failover

Demands on
infrastructure

UC4 performance

Max. Availability

Low
Start: NORMAL

Very high

Only suitable for systems with

low throughput

Max. Protection

Medium
Start: Possibly
COLD

High

Max.
Performance

High
Start: COLD

High

Behaves similarly towards UC4

as it would for a single instance.
But makes considerably higher
demands on database hardware
and infrastructure (network).

Table 1: Comparison of the Data Guard configurations

The graphic below demonstrates the connection between performance and availability of the Data Guard
configurations in comparison to a single instance (without hardware cluster). For a single instance, the availability
is always minimal in comparison to a Data Guard solution. However, performance is barely affected. Conversely,
for Data Guard in the maximum availability mode, the availability is very high but the negative influence on the
performance is also at the maximum level. Therefore, it is recommended when planning to install UC4 Data
Guard to focus on the available infrastructure, so that no performance bottlenecks arise.

Figure 5: Data Guard Availability vs. Performance

Summary
Taking the above configuration options and their parameter settings into account, large UC4 systems can be
operated with Oracle databases at a high level of performance and availability.
The best option differs depending on the situation and is greatly determined by the available infrastructure and
the demands involved.

12