1

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.

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 hardware’s 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

2

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-the-clock 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.

o < 2 GB => SWAP = RAM;

o > 2 GB => SWAP = RAM x 0.75

o 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.

3

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 VALUE ------------------------------ ---------------------------------------- NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_CURRENCY $ NLS_ISO_CURRENCY AMERICA NLS_NUMERIC_CHARACTERS ., NLS_CHARACTERSET 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.

4

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.

5

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 table MQCP001; truncate table MQCP002; truncate table MQCP003; truncate table MQCP004; truncate table MQCP005; truncate table MQPWP; truncate table MQSRV; truncate table MQLS; truncate table MQMEM; truncate table MQDWP; truncate table MQWP; commit;

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);

6

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

7

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.

8

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, block-level 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.

9

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

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

Figure 1 – Oracle Real Application Cluster (RAC)

© Oracle

10

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.

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.

© Oracle

11

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.

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.

© Oracle

© Oracle

12

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.

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.

Figure 5: Data Guard Availability vs. Performance