DBINSTAL is a server based console utility that is used to install and build the Omnidex indexes. Indexing options are specified during the DBINSTAL installation process and then built with the DBINSTAL Build command.
It is important to note that the two processes, installing the indexes and building the indexes, are two completely separate processes that do not necessarily have to be performed at the same time. This means that there are times when the indexes must be reinstalled but not necessarily rebuilt, for instance when upgrading a minor version of Omnidex, with the exception of upgrading from 4.0.7 to 4.0.8. See Index File Limits for more information about this upgrade.
There are also times when the indexes must be rebuilt but not necessarily reinstalled, like when deferring indexing to a batch process in an update application. The existing index installation is still valid but the indexes are built and rebuilt during periodic batch processes.
The actual process of the Build command is to serially read the specified table and unload the appropriate columns of data into a special Omnidex unload file. This file is then read and the physical Omnidex indexes are populated with the internal Omnidex index structure from the unload file. Omnidex has options to generate multiple indexes and uses very high-speed processing techniques to minimize the actual indexing time.
For the initial index installation and build, DBINSTAL should be run interactively. Manually define the MDK and ASK indexes for each table and then run the Build command to populate the index files. After this is complete, run OAHELPER to generate an installation batch script. This script allows the indexes to be re-installed and re-built in the future by simply executing the script. This installation script can be easily modified using any text editor.
If DBINSTAL prematurely stops on UNIX systems (for example, results in a core dump), particularly on HP-UX systems, then run DBINSTAL again for each indexing operation, or try reducing the memory allocation through DBINSTAL's BUF=n option. This problem is due to an anomaly in some versions of UNIX. A DISC work-around is in progress.
Use the DBINSTAL Build BUF=n option to allocate an appropriate amount of memory for DBINSTAL indexing operations.
Determining the optimal BUF=n size is best done by trial and error on a subset of the database. Monitor the number of sort segments required (displayed by DBINSTAL). The maximum is 2048 segments. Vary the BUF=n size on the database subset, and use the BUF=n value that provides a sort segment size closest to 1024.
Use 8 Mbytes of BUF=n space for each Distributed Index (;DI) processed. If a Build option of @9 is used, then the BUF=n size should be set to 72 (8 * 9).
A child table can be indexed as a stand-alone table in its own domain, in its parent's domain, as a parent and child, or any combination of these. With all of these options, Omnidex can always ensure the best query performance.
Child tables are defined with foreign key constraints in the Omnidex environment catalog. This causes DBINSTAL to issue a Link Column prompt when defining indexes for a child table.
To index a child table in its own domain, without indexing it in its parent's domain, simply enter a forward slash at the Link Column prompt:
Table name? ORDERS
Link Column 1: /
To index a child only in its parent's domain, enter the column name that links it to its parent or enter P=parentname, at the Link Column prompt:
Table name ? ORDERS
Link Column 1: ACCT
Link Column 1: P=CUSTOMERS
Link Column 2: /
To index a child in both its parent's domain and its own domain, link the child table to the parent table and then enter $DR at the next Link Column prompt:
Link Column 1: P=CUSTOMERS
Link Column 2: $DR
To index a table as both a parent and a child table, enter $PK at the first Link Column prompt, then link the table to its parent at the next Link Column prompt:
Link Column 1: $PK
Link Column 2: P=CUSTOMERS