Setting up database environment

By default the solidDB^® database files, log, message, and trace files are created in the solidDB^® working directory. For production environments, you might want to set up an environment where, for example, database files, backup files, and log files are located on different disks.

File	Factory value location	How to modify
license file (solid.lic or solideval.lic)	working directory	Define path in SOLIDDIR environmental variable.
solid.ini configuration file	working directory	Define path in SOLIDDIR environmental variable.
database files (solid.db)	working directory	Define with IndexFile.FileSpec parameter
transaction log files (sol#####.log)	working directory	Define location with Logging.LogDir parameter or Define location and file name with Logging.FileNameTemplate parameter. Note If you specify a directory for the log files, the directory must exist before you start solidDB^®: solidDB^® cannot create directories.
message file (solmsg.out)	working directory	Location and name cannot be changed; the solmsg.out file is always output in the working directory.
error file (solerror.out)	working directory	Location and name cannot be changed; the solerror.out file is always output in the working directory.
trace file (soltrace.out)	working directory	Define with Com.TraceFile parameter.

▪If you do not want to run the installer on your production environment node, install solidDB^® on a separate node and copy the executable programs, libraries, and drivers manually to your production node, as applicable for your setup.

▪To prevent loss of data in a disk failure, store the database files and transaction log files on different physical drives. Using different physical drives also provides best performance, especially during database checkpoints when both database files and transaction log files are written at the same time.

Using local disks is especially important with a solidDB^® HotStandby setup. The HotStandby configurations are targeted for environments with shared nothing architecture. Such architecture is best achieved by having the primary and secondary databases in separate nodes, each using local disks. Network disks have a risk of being a logical/physical single point of failure in the system.