Before you install solidDB® server, ensure that the system you choose meets the following software and disk and memory requirements.
▪About 48 MB of disk space, including the space for separately installed documentation – the number varies considerably, depending on the platform
▪At least 40 MB of RAM in the default configuration
▪Adequate disk space for your database – an empty database typically requires about 16 MB of disk space
▪If you use in-memory tables, additional memory to store those tables
▪If you use IBM Infosphere CDC technology (or, the solidDB® log reader is enabled), enough disk space to accommodate transaction log files preserved for replication recovery (catchup) – by default, the required log retention space is 10 GB
▪Java Runtime Environment (JRE) or Java Development Kit (JDK), version 1.4.2 or newer, is required for
– solidDB® installation program. (On Linux, the installation program does not support GNU Compiler for Java GCJ.)
– Shared memory access (SMA) and linked library access (LLA) with Java
User process resource limits (ulimits) considerations in Linux and UNIX environments
In Linux and UNIX environments, you might need to modify the settings for the user process resource limits (ulimits) of your system. For details, see OS user limit requirements (Linux and UNIX).
Security-enhanced Linux considerations
On Red Hat Enterprise Linux (RHEL) operating systems, if Security-enhanced Linux (SELinux) is enabled and in enforcing mode, the installer might fail because of SELinux restrictions.
To determine whether SELinux is installed and in enforcing mode, complete one of the following actions:
▪Check the /etc/sysconfig/selinux file.
▪Run the sestatus command.
▪Check the /var/log/messages file for SELinux notices.
To disable SELinux, complete one of the following actions:
▪Set SELinux in permissive mode and run the setenforce 0 command as a superuser.
▪Modify /etc/sysconfig/selinux and restart the computer.
If the solidDB® server installs successfully on an RHEL system, all solidDB® processes will run in the unconfined domain. To assign the processes to their own domains, so that also confined users can run them, you must modify the policy modules.