Rather than repeating the content of the manual, I'll try here to give some background information.

Why use a secondary server with the Informix Warehouse Accelerator?

For query acceleration:

Within a high-availability (HA) environment of Informix servers, there is a primary server that is best suited for OLTP workload, where data is frequently changed, inserted or deleted. The primary server has direct access to the disks in order to perform all required data changes directly. A secondary server in such a HA environment can also perform changes to data (update, insert, delete), but in order to do so, it always needs to route the change requests to the primary server to get them executed and then replicated to all the secondary servers of the HA environment.

Therefore, a secondary server is more suited to performing queries that change only very little or no data at all. This is exactly the case for typical data warehouse queries comprising an OLAP workload. It is therefore quite desirable to let a secondary server perform such OLAP workloads and still benefit from acceleration by the Informix Warehouse Accelerator. With Release 11.70.FC5 this is now possible.

It could be argued, that also the primary server would not be strained by accelerated queries as they get executed by the accelerator rather than the Informix server. However, an OLAP workload, e.g. for a specific report, can contain queries dealing with temporary tables to be created and used on the fly. Such queries cannot be accelerated, but with according configuration can be executed on a secondary server without burdening the primary server. In such cricumstances, using the secondary server is still beneficial to the overall workload distribution in the HA environment.

For data mart administration:

Furthermore, loading data into a data mart in the accelerator is a demanding task for the database server, as all the data must be read from disk and sent over to the accelerator. Nevertheless, no changes to the user data need to occur in the database server. Only tiny amounts of meta data need to be created when creating a data mart, and even less such meta data needs to be changed after a data mart was loaded successfully, to reflect the new state "Active" for the data mart. Therefore, also data mart administration, including the loading of a data mart with the data, is suited very well for a secondary server.

Necessary configuration

Updates on the secondary server:

In order to be able to perform the required changes of the small amounts of meta data, the secondary server still needs to be an "updateable secondary" server. Hence, the secondary server must be configured accordingly with the parameter UPDATEABLE_SECONDARY in its onconfig file. Strictly speaking this is not necessary for pure query acceleration only. Nevertheless, it is recommended that every secondary server connecting to the accelerator be an "updateable secondary" server, to avoid errors and confusion when trying to do some administrative action for the accelerator, e.g. after an HA-failover has happened.

Virtual Processor for acclereator administration:

For the same reason, the secondary server must be configured with the VPCLASS parameter to run the required virtual process (the "dwavp") handling administrative commands, and have access to the SmartBLOBSpace required as a staging area of user input and output for such administrative commands. If configuration parameters were changed or added, then the secondary server needs to be restarted to make these effective. With that, the secondary server basically is ready.

(For examples and detailed how-to on the configuration tasks please see the manual.)

Connecting the secondary server to the accelerator

The only thing missing now is an actual connection to the accelerator. The necessary connection information is stored as a group entry in the sqlhosts file of the respective Informix server instance, where the accelerator name is represented as the group name.

Here the long string following the option "a=" is the encoded authentication token, that the database server uses when sending any requests to the accelerator.

If all database servers of the HA environment to be connected to the accelerator share the same sqlhosts file (e.g. via shared disk or file system), then it is sufficient to have once established a connection to the accelerator from one of the database servers. All other database servers in the HA environment will then see the automatically created entry in the sqlhosts file and be able to utilize this. Thus even when the primary server previously had already established a connection to the accelerator, this will be sufficient for the secondary servers as they will see the corresponding entry in the shared sqlhosts file.

However, if the sqlhosts file is not shared, then the connection still should be established only once (if not already done) and the resulting sqlhosts entry of that database server should only be copied manually to the sqlhosts files of the other servers in the HA environment.

Two cases are possible that need slightly different handling:

The primary server of the HA environment already has an established connection to the accelerator:

The connection information for this connection should also be used by the secondary server(s) intended to connect to the accelerator. As the sqlhosts file is not shared, the respective group entry needs to be copied manually to all secondary servers to be connected to the accelerator.

None of the servers in the HA environment has yet a connection to the accelerator:

A new connection from one of the chosen servers must be established to the accelerator as described in the manual. Once this is done, the created sqlhosts entry needs to be copied manually to the sqlhosts files of the other servers.

What happens, if a new connection is done even though another server already has an established connection?

If one database server of the HA environment already has an established connection to the accelerator, but still a new connection is established from a different database server (with a different sqlhosts file), then the existing connection of the first database server will be invalidated. This is because upon the new connection request, the accelerator server will generate a new authentication token for the same accelerator name. This will be stored correctly in the sqlhosts file of the database server requesting that new connection. But without sharing the sqlhosts file, the first database server will have no knowledge of the new authentication token. Its sqlhosts file will still have the old authentication token, that has just been invalidated. When attempting to use this old authentication token, the accelerator will reject any request. Therefore, when not sharing the same sqlhosts file among the database servers of a HA envrionment, some extra care may be needed regarding the handling of the accelerator's connection info and distributing it among the database servers involved. The same is true when only renewing just the authentication token, as in some envrionments there will be a requirement to do this regularly.

Once all chosen database servers of the HA environment have access to the accelerator, it is probably good practice to determine one of them as the "master" for all administrative actions regarding data marts in the accelerator, and utilize with other connected database servers only the query acceleration. This will prevent confusion that could easily ensue when data marts are manipulated concurrently from different database servers. E.g. when from one database server a data mart is being loaded while at the same time from a different database server a status change is attempted for the same data mart.

With the general availability - eGA completed 5/24, GA on
6/4 - of the new release 11.70.FC5 of both, the Informix Server and the
Informix Warehouse Accelerator, a set of new functionalities was
implemented for the accelerator:

Partition Refresh:

Refresh data quickly without reloading the whole data mart. By using
the new functions dropPartMart() and loadPartMart(), you
can drop and load a specific partition of fact tables in an existing
data mart. With fact tables in the warehouse database fragmented, this
can save a lot of time when only some fragments of the fact table have
changed data to be propagated into the data mart.

Integration with Informix MACH11:

High-availability secondary servers of an Informix MACH11
environment can now be used to accelerate queries and to administer
data marts, including the loading of data marts. Secondary servers are
perfectly suitable for dealing with the rather static data in data
marts. By connecting secondary servers to the Informix Warehouse
Accelerator, you have greater flexibility in a mixed-workload
environment, leaving primary servers free to exclusively handle OLTP,
thus increasing the availability and the throughput for all the
servers in the high-availability cluster.

Support for more SQL functions implemented:

LEN, LENGTH : length of a character value.

SUBSTR, SUBSTRING : substring of a character value.

TODAY : current system date.

TRIM : remove specified leading or trailing pad characters from a string.

YEAR : four-digit year of a DATE or DATETIME value.

UNITS : specify the time unit of a DATE or DATETIME value.

New options for session environment use_dwa:

The use_dwa session environment now includes new options for
controlling accelerator related aspects of client connections to the
Informix database server. You can now specify settings for a
particular session, control whether queries are run by the Informix
database server if they cannot be accelerated by Informix Warehouse
Accelerator, and specify an output file for debug/trace
messages.

The information provided applies to the Informix Server Version 11.70.xC4
and later.

Thanks to a new IBM Proof of Technology (PoT) it is now possible to
experience the acceleration capabilities of the Informix Warehouse
Accelerator first hand. This IBM PoT was developed recently by Carlton
Doe, well known in the Informix community for his invaluable books on
Informix Administration (e.g. on
Amazon) or his comparison of Informix Version 11 editions on
developerWorks.

For more information on this new IBM PoT for the Informix Warehouse
Accelerator, as well as the general concept of an IBM PoT, please read
the flyer (PDF file). It also
describes, how this PoT could be scheduled as a one day event.

The
information provided applies to the Informix Server Version 11.70.xC4
and later.

With the default configuration of the Informix Warehouse Accelerator
it is possible, that on a single machine the existing CPU resources of
that machine do not get utilized to the maximum when executing queries.
One way to increase CPU utilization is to increase the number of worker
nodes, as described in an early entry of this blog (topic Configuration
Tips (1): CPU Resources).

However, on a single machine this previously described approach has
the drawback, that more worker nodes will also increase the amount of
memory needed for the data marts, because of the duplication of the
dimension table data for every worker node (described in another earlier
blog entry on the topic of Estimating
the Size of a Data Mart). On a cluster system where each accelerator
worker node is running on its own cluster hardware node, this
duplication of dimension tables is unavoidable, because by the
architectural design of clusters the memory cannot be shared among
nodes. But with the accalerator on a single (SMP) machine, this really
hurts, because all worker nodes have their portion of shared memory on
the same machine. That way the memory could not only be shared among the
threads of a single worker node, but also among the different worker
nodes themselves. The duplication of dimension tables in memory for each
worker node is not efficient on a single machine.

Fortunately, there is a way to avoid having multiple worker nodes
with the dimension tables duplicated in memory and still achieve a
higher degree of parallelism and with that better CPU utilization on a
single machine. Each single worker node is already by itself inherently
working in parallel, using threads to execute queries in parallel.
Using more parallel threads for query execution will allow a single
worker node to use more CPU resources and thus execute the query faster.
The same can be achieved also for the work that needs to be done during
the loading of data into a data mart, although here the performance gain
is less, because the load tasks are better distributed among different
worker nodes than a single worker node can distribute the whole work
among its threads.

Two configuration parameters can be used to control the CPU utilization
for each worker node, for query execution as well as data mart load:

CORES_FOR_SCAN_THREADS_PERCENTAGE

Determines the percentage of present CPU resources that should be
used for query execution. (A major task within query execution is the
scanning of table data, hence the "SCAN" in the name of this
parameter.)

CORES_FOR_LOAD_THREADS_PERCENTAGE

Determines the percentage of present CPU resources that should be
used for data mart loading tasks (like building data histograms and
dictionaries, and data compression).

Both parameters are optional and can be specified independently in
the accelerator's configuration file dwainst.conf. With the
parameters absent, both have a default setting of 17 (percent). Once the
parameters and their values have been put into the dwainst.conf
file, they need to be propagated to the individual worker and
coordinator nodes to make them effective. For this the accelerator must
be stopped (using the command "ondwa stop"), the parameters
need to be dispersed (using the command "ondwa setup") and
finally the accelerator needs to be started again (using the command
"ondwa start").

The accelerator uses the settings of these parameters to determine
the number of parallel threads to be started for execution of the
respective task at hand. This is done by an internal calculation based
on empirical values and the given percentage of present CPU cores.
Here, present CPU cores refers to the number of CPU cores, that the
Linux OS has at its disposal, which may differ from two other terms,
number of installed CPU cores as well as number of available CPU cores.
Especially in a virtualized environment, the number of present CPU cores
often does not equal the number of physically installed CPU cores, as
the virtual machine may be entitled to utilize only a portion of
physically existing hardware. (Though it may not be very feasable to run
the accelerator in a virtual machine for serious production
applications.) On the other hand, the number of present CPU cores may
not equal the number of available CPU cores, as some CPU cores may be
quite permanently occupied by other processes (like an Informix Server
with configured processor affinity).

It should be noted, that in general parallel threads for query
execution scale quite well. However, on a big machine (e.g. 64 CPU cores
or even more), it is quite possible to configure the CPU percentage too
high, resulting in too many threads causing a noticable overhead, and as
a result not improving performance. Whereas on a smaller machine, with
say 8 or 16 CPU cores, it is quite safe to configure both parameters
e.g. close to 80 or 90 percent.

All said so far applies to the accelerator installed on a single
(SMP) machine. In a cluster installation the accelerator normally is
running each individual coordinator or worker node exclusively on its
own cluster hardware node. For such an installation it is recommended
to set both parameters to 100 percent.

The
information provided applies to the Informix Server Version 11.70.xC2
and later.

Recent attempts to run the Informix Warehouse Accelerator on some
rather new Linux systems have surfaced a few peculiarities due to
changes of istreams' function tellg() in the standard C/C++
library on these systems. Most obviously the accelerator will not start
on such a system with the complaint about some default value for
configuration parameters not being valid. A message according to this
effect will appear in the individual accelerator nodes' log file,
node{x}.log (x starting with 0), located in the directory
configured for DWADIR:

While these problems could be avoided by specifying this and a few
other parameters in a specific way and with appropriate values in the
nodes' configuration files, more problems are much likely to surface
later during the parsing of the SQL text sent by the Informix Server for
accelerating queries. Due to failures in the parsing, the queries will
not be accelerated. Unfortunately, there is no simple workaround for
this latter kind of problem.

Therefore, to avoid all these problems related to the changed
behaviour of the tellg() function, it is recommended for the time
being to only use GNU Standard C++ Library (libstdc++) versions lower
than 4.6.0, but not version 4.6.0 or higher.
(E.g. SLES 11 SP2 is known to include libstdc++ version 4.6.1)

Updated: 5/8/2012

Update 12/18/2012:

This problem has been fixed in versions 11.70.FC6 and newer of the
Informix Warehouse Accelerator.

In February Lester Knutsen hosted a Webcast to demo the Informix
Warehouse Accelerator that demonstrated his current benchmarks with this
exciting new Informix database technology. He demonstrated ad-hoc
queries on a bookstore database with 250 million customers and over a
billion records in the fact table. In this new Webcast Lester Knutsen will
combine that with the best Open Source Business Intelligence -
Pentaho.

The
information provided applies to the Informix Server Version 11.70.xC4
and later.

In the last blog entry on
Continuous Acceleration during Data Refresh I said that the old data
mart can be dropped "as soon as the last query utilizing it has
completed". This obviously raises the question, how to be sure that
there is no longer a query in need of the old data mart. While with the
current releases it is not possible to directly determine which data
marts really are in use by running queries, this blog entry describes a
method to ensure that an old data mart is no longer in use and can be
dropped after the new data mart has been created.

In general, the Informix Warehouse Accelerator executes queries
serially, one query after another, but using full parallelism for each
single query. Compared to the Informix Server, this corresponds to
strictly obeying a setting of PDQPRIORITY to 100, giving all CPU
resources to the single query currently being executed. With the
accelerator there is a small overlap in that the worker node(s) of the
accelerator can start working on the next query while the coordinator
node is still performing the final stages of the previous query, like
final sorting of the query result and sending the result to the Informix
Server. But the time consuming part of query execution is done in the
worker node(s), and is done one query at a time. If the accelerator
receives new queries before the query currently being executed has
finished, it will queue the newly arrived queries in FIFO fashion and
serve them subsequently.

We can use this behavior described above in connection with the
knowledge about continuous availability described in the previous blog
entry to determine, when an old data mart is no longer needed. Even
though the Informix Server will automatically switch to using only the
new data mart as soon as it has been loaded and became active, there
might still be older queries queued up that need the old data mart once
it is their turn for execution. Dropping the old data mart too early
would cause such queries to fail miserably.

After the load of the new data mart has completed and the new data
mart has become active, as administrator we now can issue a simple test
query using the data mart. As with all other queries, Informix Server
will automatically decide to use the new data mart instead of the old
one for this test query. With the queries in the queue being handled in
FIFO fashion, earlier queries, possibly needing the old data mart, will
be ahead in the queue and will be executed before our test query. Once
our test query has finished and returned the result, we know that no
older query needing the old data mart can still be in the queue of the
accelerator. The old data mart is no longer needed and now can be
dropped safely.

To exclude any doubt about whether our test query really got executed
by the accelerator (and not by the Informix Server due to automatic
fallback in case of an issue), the fallback option can be turned off for
the test query. This is done with a setting of '5' for the session
environment use_dwa. With this setting, queries that cannot be
accelerated for any reason will return an error rather than falling back
to execution by the Informix Server. For more information on setting the
use_dwa session environment see the earlier blog entry
"use_dwa"
Environment Setting. With this setting, if our test query returns
the expected result and not an error, we can be sure that it was
executed by the accelerator.

The
information provided applies to the Informix Server Version 11.70.xC4
and later.

To refresh the data in a data mart of the Informix Warehouse
Accelerator, the data mart must be loaded with a new set of the complete
data. This can be done by dropping the existing data mart, re-creating
it and then loading it with the new data. Alternatively, the data mart
can be disabled and loaded. While this saves the procedure of dropping
and re-creating the data mart, it still means that the data mart is not
available during the loading of the new data. And as normally this
loading phase is the step that takes the longest, renewing the data
always renders the data mart unavailable for considerable time.

Fortunately, with version 11.70.FC4 of the Informix Server, it is now
possible to achieve continuous availability of a data mart even during
the procedure of renewing the data. For this, a second data mart with
the same definition, but a different name, needs to be created and
loaded. While this new data mart is being loaded, the old data mart is
still available for query acceleration. As soon as loading of the new
data mart is complete, the new data mart will become active. From that
moment onwards it will be utilized for the acceleration of newly
arriving queries. This switch over to the new data mart happens
automatically in the optimizer of the Informix Server, where it is
decided, whether a query can be accelerated. As soon as the last query
utilizing the old data mart has completed, the old data mart can be
dropped manually.

With this method, queries can be continuously accelerated even while
new data is being loaded. It should be noted however, that this method
of data refresh requires the double of the memory space needed normally
for the data mart, though only for a short time. Therefore the size of
the shared memory available for the worker nodes may need to be adjusted
accordingly. Parameter WORKER_SHM in the accelerator's configuration
file "dwainst.conf" specifies the relevant memory resource.

Also see the
description
in the manual "IBM Informix Warehouse Accelerator Administration
Guide".

The information provided applies to the Informix Server Version
11.70.xC2 and later.

In a previous blog
entry I have already discussed the possible problems caused by AQTs
that are left over, i.e. for which the corresponding data mart does not
exist anymore in the accelerator. That same blog entry also contains a
script, that can be used to remove such left over AQTs. However, in
order to avoid dropping any AQT accidently, the script requires that the
data mart name is specified. Recently it dawned on me, that this is not
terribly helpful when looking for an AQT of which the name of the
corresponding data mart is not known or has been forgotten - as it no
longer exists.

Below is a modified version of the original script, where the
specification of the data mart is optional. If no data mart is
specified, the script will list all AQTs of the specified database
for all data marts residing in the specified accelerator. In this mode,
the "-y" parameter to pre-confirm the dropping of all AQTs is not
allowed. Instead, each AQT is listed with the name of its corresponding
data mart, and dropping the AQT must be confirmed individually.

Note:

This version of the script still does not check whether a
corresponding data mart possibly still exists. Removing the AQTs of an
existing data mart will render the data mart useless. Therefore it is
important to use this script only to remove old AQTs when the
corresponding data mart does no longer exist, or, with much caution
checking the AQT's creation date, when the data mart has been
re-created. A new AQT could be dropped which means its data mart
again will need to be dropped and redeployed.

#!/bin/sh

# drop_aqts.sh## Script (improved version) to remove left-over AQTs from a database.## Attention: No checking is done to determine if the data mart# still exists.# AQTs found will be dropped anyway. Without AQTs# an existing data mart is rendered useless. It# will need to be dropped and re-created.## Usage: drop_aqts.sh { database } { accelerator } [ mart [ -y ]]# database : name of the database# accelerator : name of the accelerator instance# mart : optional: name of the data mart# -y : optional: don't prompt for confirmation# -y is valid only, when a data mart name is specified## This script is provided as is.# No warranty is given for functioning without error or possible damage.

The
information provided applies to the Informix Server Version 11.70.xC2
and later.

Following up on the last blog entry with the
description of how to configure the syslogd implementation often
used on Red Hat Linux distribution, here is a description for the
syslog-ng implementation ("-ng" for "new generation"), widely
used on SUSE Linux distributions. The examples have been tested on SUSE
Linux Enterprise Server 11 using version 2.0.9 of syslog-ng.

Naturally, the concept of system logging is the same for both
implementations and the Informix Warehouse Accelerator always uses the
system logging facility named 'local6'. From the perspective of the
accelerator and its messages the difference is in the method of
configuring the system logging.

The configuration file for syslog-ng is located in directory
/etc/syslog-ng/ and is named syslog-ng.conf. This file
must be edited as user 'root' to apply the needed changes.
syslog-ng has the notion of defining in the configuration file
not only the destinations, but also the source of log messages, along
with optional filters. These definitions are then tied together to
define individual logging actions, making syslog-ng much more
flexible. However, in the example I will keep things rather simple,
just to achieve the same objective as with the examples for
syslogd in the last blog entry: to redirect all messages of the
accelerator to a separate file named /var/log/iwalog.

First a new filter for the Informix Warehouse Accelerator is defined.
It is named 'f_iwa' and should select all messages going to facility
'local6'. Therefore the filter does not specify a level, but only the
facility. The following line is added to the section containing all the
filter definitions in file syslog-ng.conf:

filter f_iwa { facility(local6); };

Next a new destination for the messages from the accelerator is
defined. The destination is the file /var/log/iwalog and the
name of this new destination is 'd_iwa'. Usually the destinations in
syslog-ng.conf are not grouped together (like the filter
definitions), instead they are placed with the log action definition
where the destination is used. Therefore a new place, convenient for the
admin, is to be chosen for the following line to be added to the
configuration file:

destination d_iwa { file("/var/log/iwalog"); };

Right after the destination definition, the log action is to be
defined, again with a new line to be added to the file. Here, the
previously defined filter 'f_iwa' and the destination 'd_iwa' are used.
The generic source definition named 'src', already existing, is
sufficient. It is not necessary to define a new source for this purpose.
The line defining the log action is:

log { source(src); filter(f_iwa); destination(d_iwa); };

With this the definition for directing all messages from the
acclereator to file /var/log/iwalog is complete. However, the
same messages can be sent to different destinations concurrently, in
effect duplicating the messages to each of these destinations. As
usually there exist already some definitions that cause the
accelerator's messages to be sent to other destinations, it may be
desirable to turn this off in order to have the accelerator's messages
collected only in the one (new) place, the file /var/log/iwalog.
To do this, the other definitions applying to (some of) the
accelerator's messages need to be found in the configuration file and
changed accordingly. Typically these definitions are:

filter f_messages { not facility(news, mail) and not filter(f_iptables); };

filter f_warn { level(warn, err, crit) and not filter(f_iptables); };

These filter definitions apply to (some) messages of the accelerator
and the later use of these filters in the configuration file causes
these messages being sent to three different files:
/var/log/localmessages, /var/log/messages and
/var/log/warn. To stop these messages from being sent to these
three destinations, the above filter definitions need to be changed to
exclude the accelerator's messages. This is best done by using the
filter 'f_iwa' that we have already defined. That way, if later a change
is applied to filer 'f_iwa', it will automatically be effective
throughout the configuration file without having to revisit and adjust
the above three filter definitions. With the suggested changes applied,
the lines will look like the following:

filter f_messages { not facility(news, mail) and not filter(f_iptables) and not filter(f_iwa); };

filter f_warn { level(warn, err, crit) and not filter(f_iptables) and not filter(f_iwa); };

After all necessary changes have been applied to the file
syslog-ng.conf, the remaining task is to make the new
configuration effective. The running syslog-ng daemon needs to
read the changed configuration file. This is accomplished by sending the
syslog-ng process the hang up signal. Sending the signal needs
to be done as user 'root' and the easiest way is to use the kill
system utility. Before using kill, the pocess ID of the running
syslog-ng needs to be determined using the ps system
utility, filtering the output with grep:

Given the extensive flexibility of syslog-ng it may well be
possible to not only send messages to a different host, but also to
insert the messages into a database system running on that host.
However, figuring out how this can be done and what configuration is
needed ... is left to the adventurous reader - for the time being at
least.

The
information provided applies to the Informix Server Version 11.70.xC2
and later.

The processes of a running Informix Warehouse Administrator instance
typically are producing various informational messages that are handled
via the system logging mechanism. On a normally configured Linux system,
these messages are directed to the file /var/log/messages.
Traditionally, this is the place for system messages and therefore it
may be convenient to redirect the messages of the accelerator to a
different location. For one, this probably helps to unclutter the file
/var/log/messages, but it can also avoid running out of disk
space for the file system where this file resides.

Depending on the distribution and version of Linux in use, different
implementations of system logging are available, each with its specific
method of configuration. Therefore, in this blog entry I will describe
the method for the most common and basic system logging implementation,
the syslogd (see also the manpage for syslogd(8) ). The
examples have been tested on Red Hat Enterprise Linux Server release 5.5
(Tikanga) with version 1.4.1 of syslogd. Red Hat Enterprise Linux
Server release 6.0 (Santiago) uses the rsyslogd as preferred
implementation for system logging. The configuration file for
rsyslogd is /etc/rsyslog.conf, which is in its default
structure almost identical to the configuration file of syslogd.
Therefore the description below can also be applied to a standard
configuration of the rsyslogd implementation.

The syslogd implementation of system logging offers several so
called 'facilities'. Examples of such facilities are 'auth', 'cron',
'daemon', 'kern', 'mail', 'local0' through 'local7', to name a few. For
each facility the system logging can be configured by several levels,
e.g. 'debug', 'info', 'warning', 'err', etc. The configuration of the
facilities with their levels includes also the destination for the
messages, usually files like /var/log/messages. The configuration
of syslogd is in file /etc/syslog.conf (see also the
manpage syslog.conf(5) for more information). An application like
the accelerator has to specify the facility and the level for any
messages sent to the system logging.

The following actions normally require root access, so all things
should best be done as user 'root'.

The Informix Warehouse Accelerator uses the facility 'local6' for all
its messages sent to the system logging. In order to change the
destination for all these messages, no matter what is their level, this
'local6' facility needs to be configured in file
/etc/syslog.conf. If there is no configuration for the 'local6'
facility listed in the configuration file, then the default message
destination is /var/log/messages. To change this, two things
need to be done in /etc/syslog.conf:

Entries that apply to all facilities are denoted by an asterisk
wildcard before the dot. An example is the following line:

*.info;mail.none;cron.none /var/log/messages

This tells the system logging to put all messages of level 'info'
coming from all facilities ( *.info ) into /var/log/messages,
but not messages from facilities 'mail' and 'cron'.

In this line, the facility 'local6' now also must be specified to
exclude its messages from going to /var/log/messages. The
changed line will look like this:

*.info;local6.none;mail.none;cron.none /var/log/messages

Assuming that until now there is no configuration for facility
'local6', a new line has to be added to the file for this facility.
Using the asterisk wildcard for the level, we configure for all
messages of facility 'local6' that they be directed to the specified
destination file. The file name has to be specified with the
absolute path, and if it is not owned by user 'root' it must at
least be writable for user 'root'. (This sometimes is not guaranteed
for remote file systems, e.g. mounted via NFS.)

local6.* /var/log/iwalog

The above line will cause all messages for facility 'local6' to be
sent to file /var/log/iwalog instead of the default
/var/log/messages.

With this the simple configuration for facility 'local6' is complete.
In case there are more configuration lines that apply to all facilities,
i.e. with the asterisk wildcard before the dot, then they should also be
changed as above by adding the ;local6.none specifier to
them.

In order to make the new configuration effective, the syslog daemon
has to read the new configuration file. This is achieved by restarting
the syslog daemon process, named syslogd. Normally it is sufficient
to send this syslogd process the hangup signal upon which it will
do the required restart and thus read the new configuration file.

In order to send a signal to the syslogd process, the process
ID of that process needs to be determined, e.g. using the ps
system utility in the following way:

With the above configuration now effective, all future messages from
the Informix Warehouse Accelerator should be redirected to the file
/var/log/iwalog.

In a following blog entry I will briefly describe the necessary steps
when using the syslog-ng implementation ("-ng" for "new generation"),
an implementation widely used on SUSE Linux Enterprise Server.

The first video presentation introduces the Informix Warehouse
Accelerator. The emphasis is on the business need for using the
accelerator and the business value of using it. There is some
explanation of the concepts that make Informix Warehouse Accelerator
perform so well, but without going into technical detail. Results of
proof of concepts at four customers confirm the possible performance
gains.

The second video presentation is more technical and gives an
overview of how the Informix Warehouse Accelerator fits into an
existing environment with Informix Server and client applications. The
emphasis is on the transparency for the client applications that do
not need to know of the accelerator's existence.

The first demo introduces the IBM Smart Analytics Optimizer Studio, the graphical administration interface for IBM Informix Warehouse Accelerator. This is a great demo to watch if you are not familiar with Eclipse-based interfaces.

The second demo shows you how to use the administration interface to create a data mart, including how to add a subset of columns from a table to the data mart. Use this demo to get acquainted with using Informix Warehouse Accelerator.