This is an old revision of the document!
Omnidex benefits greatly from caching by the filesystem, managed by the operating system. Omnidex purposefully maintains small index files, and purposefully uses standard file system calls, in order to insure the best caching by the operating system. This allows index files and temporary files to be as accessible as possible.
To support this caching, it is important to maintain adequate physical memory on the server. Consult the System Requirements documentation for specific memory recommendations. In addition to adequate memory, it is important to avoid running processes on the Omnidex server that would flood the filesystem cache by doing excessive I/O.
The applications most likely to flood the filesystem cache with excessive I/O are standard relational database, such as Oracle, SQL Server and MySQL. These databases use retrieval strategies that are much more dependent on direct access to the data, usually with multiple threads or processes. This will quickly flood the filesystem cache, and it will have a significant negative impact on Omnidex performance.
When possible, it is preferable to run Omnidex on a server independent from the relational database. Typically, the database is then accessed through SQL*Net or ODBC. The database access is slower using this approach, but in the long run, this insures the best Omnidex performance. Additionally, since many Omnidex queries are processed solely in the indexes without accessing the database, this strengthens the recommendation to place Omnidex and the relational database on separate servers.
See also: