Release 2.0
A54628_01
 Library |
 Product |
 Contents |
 Index |
| Oracle ConText Cartridge Administrator's Guide Release 2.0 A54628_01 |
|
This chapter contains configuration information for ConText.
The topics covered in this chapter are:
| See Also:
For general information about configuring Oracle8 and ConText installations, see Oracle8 Server Tuning. |
In general, there are several things to consider when configuring the Oracle database. The Oracle8 Server Tuning manual covers these in greater detail. However, there are some specific things to keep in mind which will result in performance gains when using ConText.
The machine on which the ConText server is running should be configured with the appropriate amount of virtual memory. As an example, for a Solaris machine, you would want between two and three times the amount of swap space as you have for real memory.
Indexing is network bound. If you want to create text/theme indexes and your ConText server is on a different machine than your Oracle server, you should have a fast network.
Indexing is also bound by memory. If you have large volumes of text to index, you should allocate as much memory as possible for indexing on the server machine from which indexing is being performed.
For machines with multiple CPUs, it is advantageous to run multiple servers to take advantage of the CPUs. Parallelization may also be obtained by spreading ConText servers across different machines.
For parallel indexing and index optimization, you should have one CPU for each ConText server running in parallel. In this configuration, ConText servers should either run on a multiple-CPU machine with enough CPUs to support each ConText server or each ConText server should run on a separate, single-CPU machine.
Linguistic Services are both CPU and memory bound. If you want to generate linguistic output, you should run the ConText servers (Linguistic personality) on a machine with multiple-CPUs and large amounts of memory.
| See Also:
For more information about the Linguistic Services, see Oracle8 ConText Cartridge Application Developer's Guide. |
Clients requirements are usually very light because clients do very little processing; however, network speed can be important depending on the amount of data being passed to and from the clients (i.e. complex text queries, large hitlists).
A ConText system consists of the following components:
The client(s) send requests to the Oracle server. The Oracle server processes the requests and returns the results to the client. If a request from the client includes text, the Oracle server sends the text portion of the request to the Text Request Queue where the next available ConText server picks up the request and processes it. The results generated by the ConText server are returned to the Oracle server.
When setting up your ConText system, you need to determine the best configuration for the various components, based on the number of machines available and the resources of each machine.
This section describes three different configurations that can be used for ConText:
In a consolidated configuration, all the server processes are on a single machine and the client is on a separate machine, connected via SQL*Net.
This configuration requires a server machine with multiple-CPUs, large amounts of memory, and a significant amount of database space.
The advantage of this configuration is that all of the processing is performed on a single machine. Network speed is not an issue between the ConText servers and Oracle server because they are on the same machine. Speed may be an issue for client connections, depending on the sizes of the hitlists returned to the client.
In a distributed configuration, the server processes are divided between multiple machines, connected via SQL*Net. The client is also on a separate machine, connected via SQL*Net. ConText supports starting ConText servers (ctxsrv and ctxsrvx) across a network.
Because the ConText server and Oracle processing is distributed, this configuration requires smaller server machines (either single-CPU or multiple-CPUs) than the consolidated processing configuration. However, the database space needs on the machine for the Oracle server remain the same.
Network speed is an issue between the ConText servers and Oracle server because they are distributed across several machines. Speed may be an issue for client connections, depending on the sizes of the hitlists returned to the client.
| See Also:
For more information about ctxsrv and ctxsrvx, see "ctxsrv/ctxsrvx Executables" in Chapter 9, "Executables and Utilities". |
Because the processing performed by the Linguistic Services is CPU and memory-intensive, you may want to consider placing the ConText server process for Linguistic Services on a separate, dedicated machine, with the rest of the ConText server processes running on the same machine as the Oracle server process.
This configuration requires a very large server machine with multiple-CPUs, large amounts of memory, and a significant amount of database space for the ConText servers and the Oracle server. The machine for the ConText server with the Linguistic personality should also have a large amount of available memory. The machine for the Linguistic ConText server can have single- or multiple-CPUs, but should be very fast.
The advantage of this configuration is that network speed is not an issue for the ConText servers and Oracle server on the same machine. It is also not an issue for the Linguistic server because linguistics processing does not require large amounts of data to be transferred across the network.
As always, network speed may be an issue for client connections, depending on the sizes of the hitlists returned to the client.
When you perform queries, you are actually querying a ConText index table which has an Oracle index on the words queried. By putting the datafiles containing your index tables on a different disk from the datafiles containing the Oracle indexes on these tables, you reduce disk input/output contention in accessing data from the indexes and from the index tables. This is also true when you are performing DML on the index.
| Note:
For DDL operations, I/O contention is not as significant an issue because the Oracle index on the index table (I1T) is not created until the indexing is complete. |
In other words, during Query operations, disk contention may take place between:
During DML operations (index updating), disk contention may take place between:
The least amount of I/O disk contention will occur if you can store text tables, ConText index tables, and Oracle indexes for the tables each on separate disks.
However, if you do not have enough disks to store them separately, the optimal configuration is to store text tables and index tables together and store the Oracle indexes for the tables separately.
When creating your database and logfiles, it is generally a good idea to use raw partitions on the disk for data storage. Raw partitions can be accessed much faster for data reads and writes. This is advantageous during:
| See Also:
For more information about using raw partitions and tuning input/output, see Oracle8 Server Tuning. |
