ESSENTIA
Point to the directory where the different file configuration for the servers are located. All the users working in the same node must have the same value defined for this variable.
DATADIR
Points to the directory where some data files used by Essentia's executables are kept, like the error messages. The usual value for this variable is: $IDEAFIX/data.
SERVERS
Is the list of the names of the servers the users can access separated by ";". Each of these servers must have a configuration file in the directory $ESSENTIA/servers, with the server's name followed by the ".sv" or ".rsv" extension.
PATH
This UNIX variable indicates the list of directories in which the OS searchs for executables. It must include the directories $IDEAFIX/rbin and $IDEAFIX/bin, in that order.
The default directory in an Essentia Installation is the same as IDEAFIX, i.e., /usr/ideafix, so a view of the directory structure of the installation would be:
For the data placement, several criteria may be used, mainly depending in the host machine file system distribution. As an example we will use a standard file system distribution.
The distribution used is simple and easy to implement. To do this, we ch oose one file system (e.g., /usr2) and here we create a directory dbess were to compile the different schemas of our application.. Inside it, it is necessary to create one directory structure per server. This last structure goes as follows:
journal: stores the transactions log
start : stores the startup and shutdown logs.
A local server is the one that resides in the same network node as the client; a remote server runs in other node. For a network node to recognize a certain server, a file with the server's name and .sv extension must exist in the directory $ESSENTIA/servers. If the server is remote, the extension must be .rsv.
In no case a server's configuration file must be modified while it is running.
A remote server's configuration file (a .rsv file) has the following structure:
Schemas <schemas list>
Schemas: schema's list handled by the server, with their respective directories. The format is the following:
schema:schema_id,schema:schrema_id,...
Each local server configuration file (a .sv file) has the following structure:
Schemas < schemas list >
NextSchemaId < next identifier >
CacheSize < size >
CkPointFreq < frequency >
CkPointLowBound < number of seconds >
CkPointUpBound < number of seconds >
CorruptionTolerant < flag >
Dbase < directoryvalue:..:directory[value] >
HandleVersions < flag >
HKeepingMsgBound < frequency >
Locks < number >
LocksPerClient < number >
LockUnifyBound < number >
LockWait < time >
PendLockNotifTime < time >
Mirroring < flag >
Backup < flag >
Notifies < number >
RunLogFile < file >
StateFile < file >
JournalBuffer < size >
MatureTime < time >
MaxAttachsPerClient < number of relationships >
JournalDir < directory >
JournalFlushFreq < frequency >
TransTimeOut < time >
ObjectRepository < directory >
DiskConfiguration < file >
ServerId
Server ID number. Its must be unique for each network node. Once set, it must not be modified,
because it also identifies the server's data.
Warning: Repeating this ID number in different active servers will produce runtime and data
problems in the applications.
The list of schemas handled by the server, with its corresponding directories. The format is the
following:
schema:schema_id,schema:schrema_id,...
This line is automatically updated with each checkpoint after the dgen, so it must not be
updated manually. If dgen's -k option is used, the checkpoint is automatic and the schema
will be ready sooner.
The next ID number the server will assign to the schemas as it generates them. This line
may not exist when the server starts for the first time, and is automatically updated.
Size of the table and index cache, in Kbytes. It is used by the server to optimize performance
in data and index readings. The default value is 256, but we strongly recommend to se
t this number as high as possible. As a rule of thumb, when the clients are running locally,
you must add each client's memory requirements and assign the cache the 25% of this result.
When the clients are remote, the server only runs Essentia's kernel, and more memory space
can be assigned to the cache.
Warning: Assigning too much memory to the cache relative to the total amount of physical
memory may force Essentia to swap to disk, with the consecuent performance penalty.
Number of seconds that will pass between checkpoints. The default is 3600, i.e., one hour.
Max. number of seconds a checkpoint can be called before the normal cal
l time attempting to exploit the equipment's idle state. The default value is 30
0, i.e., 5 min.
Max. number of seconds Essentia will wait to retry a checkpoint. Its default
value is 15.
When this flag is set to 0, when a client is aborted and the journal is off,
the server state is labeled as ``corrupted'' and no more checkpoints are accept
ed. (except when using the -f option).
If this flag is 1, this situation is ignored. The default value is 1.
Directories where the schemas created in this server will be stored. Each value (preceeded by
a space) indicates the maximum number of blocks that will be stored in each directory.
When one of the directories reaches its assigned space, if a value is specified for the last
directory of the list, no more storing will be allowed once that directory is full. If the last
directory has no associated value, then the rest of the blocks will be stored in that directory.
When this flag is set to 1, it allows the server to generate new versions of the database.
If it's 0, no requests of this type will be accepted.
Warning: The maximum number of possible versions for a given database is 123.
Frequency (measured in number of messages) at which the server will perform administrative
tasks and server clean-up (e.g., verifying the state of the transactions). The default value
is 100.
Max. number of locks admitted by the server. The default is 1024.
Max. number of locks available to a single user. The default is 256.
Max. number of locks available for a user after which the system will try to lock the entire
table. The default value is 200.
Time (in seconds) a query will wait for a lock to be released if the transaction involves more
than one server, and the client has locks in more than one also. If the deadlock appears when
the clients aren't locking records in other servers, Essentia will detect the situation and
abort one of the clients. In the other case, the server states a maximum time to wait for
each lock, and, once time's up, it assumes the problem is a deadlock. Its default value is 120.
Amount of time (in seconds) the server will wait to notify a client that the lock it requested
is waiting because of other client. The default value is 0, meaning that the server will never
notify the clients.
Maximum number of available notifying locks. This facility is currently not available in
IDEAFIX. The default value is 1024.
When this flag is 1, the server enables the database mirroring facility. If its value is 0,
it disables it. Because the mirroring process is independent from the server, it uses the
journal file to update the database image. If the mirroring is disabled the journal files will
not be erased from disk, so in this case it is recommended to set this flag to 0. (Its default
value).
This flag is set to 1 when Essentia's backup facility is used. This flag works in a way similar to
the previous one, allowing to keep the journal files once they have been used. Its default value
is 1.
File where Essentia keeps the information of the server's state for debugging. To turn this
on, the server must be started with the -w option. To use it once the information is
generated, the server must be started with the -r option, in which case the server will
reproduce each of the previous operations. In this way, a server problem may be easily
reproduced. Its default value is /tmp/rise.log.
File where the server keeps information on its state (versions, checkpoints, etc.). This file
is used to restore a server to its original state after a downfall. Thus, It must not be located
in the /tmp directory, because this directory's contents are usually erased at boot-time.
The name of the file must be unique for each network node and cannot be changed once
created.
Warning: this file is as important as the server's data.
Directory where the server's transaction journal is kept. The name of the files of a
journal start with ``rlog''. If the line is not added, this capacity is disabled, implying that if
a client aborts by any abnormal condition, the database will stay corrupted at
transaction-level because the journal is not enabled to perform a rollback. The journal files
are deleted at checkpoint-time automatically if the options of mirroring and backup are
not used.
Warning : The administrator must be sure that the file system where these files will be
kept has enough free space to store the journal files, because they may turn into really big files,
depending the checkpoint frequency and the mirroring and backup options. In case the file
system is full, the server stays idle until the administrator gives it more free space.
Size in Kbytes of the journal's memory buffer. When this buffer is filled, its contents are
stored in the active journal's files. The default value (which is also the minimum) is 32).
This parameter indicates the time (in seconds) that must pass between the last modification
to a table or index for its header to be saved to disk, an action which diminishes the time the
next checkpoint will last.
The value of this parameter depends on the usage of a table. E.g., if because of the
requirements of certain system the data is entered in "bursts" (as in the case
of stock that is constantly updated) each day, it would be adecuate to leave the
deafult value (600 sec = 10 minutes), because it would be highly probable that,
when the system has not received any new data for ten minutes, the daily updating will be
finished and the system will not receive new data for the rest of the day.
This parameter indicates the maximum number of objects (schemas, tables and cursors) which
will be allowed each client to attach to. This parameter can be used as
a control for programs with errors which may generate a big number of cursors and therefore
consume all the available memory.
A good way to define the number that will be used is to run the most demanding applications
(i.e., those that use a big number of objects) and, using the dbps -f command, verify the number
of objects they relate to. Then increase this number in 20-30%, and use it. If a program tries
to relae to a number of objects greater than the allowed, it will abort with a message.
The default value of this variable is zero (0), meaning that there are no limits to the number
of objects a client can relate to.
Frequency (in seconds) at which the journal's buffer is flushed to disk. This parameter
works in relationship with the previous one, because the buffer is flushed to the logfile
depending on the condition which is satisfied first: the buffer overflow or this variable timeout.
Its default value is 10.
Warning : It is not advisable to use a value lower than the default because the server's
performance may be affected.
Number of seconds that the server waits for a client with an active transaction and that
doesn't send messages, after which Essentia will assume that the client is inactive
and will abort the transaction. The default value is 0, which implies that, once a client starts
a transaction, it stays open until the client finishes it, without the server's intervention.
This configuration parameter defines the directory where essentia will store massive binary
and text data.
It is important that those servers that don't use this feature don't define this variable, to avoid
unnecessary performance penalties.
This file stores the configuration that will be used for the different tables (i.e., packed,
ranged or round-robin). For more information on this, see ``Table Fragmentation''.
The shadow is a process that handles the communications from and to other servers. The use of the shadow allows the clients to be independent from the communications through the network. Thus it is necessary to include this program so it can take control in the moment a request comes from a server placed in a remote host of the network.
The installation of this process in done in the following way:
sha-man 6100/tcp #Essentia shadow (comment)
sha-man stream tcp nowait root /usr/idea/bin/shadow shadow
The shadow process uses a configuration file, from where it reads each of the variables that comprise its environment. Thus, when a remote client starts a connection, the shadow will use this file, specified with the command option -e envfile, where envfile is replaced with the complete file path that is desired as configuration file. If this option is not stated in the line added to inetd.conf, Essentia will take as default /etc/ess.env. An example of the contents of this file would be:
DATADIR=/usr/ideafix/datacpp
LANGUAGE=english
There exists another option for the shadow process, -f debugfile, that makes the shadow to write debugging information into debugfile.
Then, a complete line for inetd.conf would be in the following way:
export TZ
Also, each UNIX system must run the timed daemon, that allows to sincronize the hours. The network has to have defined a master hosts and slave hosts. In the master hosts, the command to be executed is timed -M, and in the slaves the command is timed.
To perform this task with greater precision, it is possible to use the NTP (network time protocol) available in various operating systems, that uses the xntpd daemon. For its configuration, refer to the TCP/IP manual.
The sample shell script included with Essentia for automatic startup and shutdown is placed under the $IDEAFIX/bin directory with the name rcshell. Its contents are the following:
-
--------------------- cut here -------------------------- ########## # # If not invoked with at least one argument, assume we are # running on a Linux 2.0.0 machine. We'll check our name to # see what we do. Otherwise, the first argument tells what # to do. ########## MoveLog() {
if [ -r /etc/rc.d/S99ess ]; then
fi
if [ -r /etc/rc.d/K01ess ]; then
fi
It's important to execute this script before all the others.
Like other UNIX process, Essentia uses the OS error log, whose daemon is known as syslogd. This daemon writes in ASCII the different errors that occurr. Depending on how it is configured, it generally sends its output to the console or to a file. This fact depends in a line that has to be inserted in the /etc/syslogd.conf file: