Release 2.0
A54628_01
 Library |
 Product |
 Contents |
 Index |
| Oracle ConText Cartridge Administrator's Guide Release 2.0 A54628_01 |
|
This chapter describes the concepts necessary for understanding system administration for ConText.
The following concepts are discussed in this chapter:
Administrative responsibilities for ConText can be divided into two functional areas:
The system administrator's main responsibility is managing ConText servers. This includes:
The DBA's main responsibilities include:
Three database roles provided with ConText:
Each ConText user should be assigned one of the ConText roles. The role assigned to a ConText users depends on the tasks performed by the user.
| See Also:
For more information about assigning ConText roles to users, see "Managing Users" in Chapter 3, "Administering ConText". For more information about database roles, see Oracle8 Server SQL Reference. |
The ConText tasks are grouped into the following areas:
The CTXADMIN role provides users with the ability to perform all of the ConText tasks.
CTXADMIN should be assigned to all users who perform system and database administration for ConText.
The CTXAPP role users with the ability to perform the following tasks/actions:
CTXAPP should be assigned to all users who develop text applications.
The CTXUSER role provides users with the ability to perform ConText queries (text and theme). It should be assigned to all users of a text application.
ConText provides two Oracle users which are created during installation:
CTXSYS is used primarily to perform administration tasks, such as starting ConText servers and administering the ConText queues.
CTXSYS has the following functions and privileges:
| Note:
Only the CTXSYS user can start ConText servers. |
CTXDEMO is used primarily to run the sample applications provided with ConText.
CTXDEMO has the following functions and privileges:
The sample applications, provided to help application developers develop applications using ConText, include:
| See Also:
For more information about setting up and using the sample applications, see Oracle8 ConText Cartridge Application Developer's Guide. |
ConText servers are shared servers that handle text operations in SQL requests. ConText server processes mirror their shared Oracle server counterparts, but process only text-related operations.
ConText servers can only be started from the command-line of the server machine where ConText is installed. In addition, only the CTXSYS user can start ConText servers.
If the server machine can support multiple ConText servers, multiple ConText servers can run at the same time to help balance the processing load. In addition, ConText servers can work with databases installed on either the server machine or on remote machines.
ConText servers can process five types of text operations:
The type of text operations processed by each ConText server is determined by the personality mask assigned to the server.
| See Also:
For more information about each of the text operations that can be processed by ConText servers, see "Text Operations" in Chapter 4, "Text Concepts". For more information about personality masks, see "Personality Masks" in this chapter. |
Requests for text operations are stored in the Text Request Queue. Available ConText servers monitor the queue for text requests. As text operations are submitted, available ConText servers with the appropriate personalities pick up the operations and process them.
| See Also:
For more information about the queues and database pipes that comprise the Text Request Queue, see "Text Request Queue" in this chapter. |
ConText provides a timestamped report for each action performed by a ConText server. These reports are written to the standard output on which the server was started; however, the reports can be directed to a log file if one is specified when the ConText server is started.
| See Also:
For more information about starting ConText servers, see "Starting ConText Servers" in Chapter 3, "Administering ConText". |
A ConText server performs the following tasks before shutting down:
The personality mask for a ConText server indicates the text operations that the server can process. When a ConText server is started, it is assigned a personality mask. A personality mask consists of one or more of the following five personalities (corresponding to the five text operations supported by ConText):
In addition to the user-specified personalities, all ConText servers automatically take on a DBA Personality.
The DBA personality does not appear as part of the personality mask because it is automatically assigned to all ConText servers.
| Note:
For ConText to process text and/or theme queries, at least one ConText server with the Query personality must be running. |
| See Also:
For more information about the text operations supported by ConText, see "Text Operations" in Chapter 4, "Text Concepts". |
The Loader personality enables a ConText server to scan directories at regular intervals for files to be loaded into columns in the database. When the ConText server detects a new file in a specified directory, it uses the ctxload utility to load the contents of the file into a specified column.
The directories scanned by ConText servers running with the Loader personality, as well as the scanning intervals and the columns to which the text is loaded, are specified by a ConText object, called a source, which can be attached to a column.
| See Also:
For more information about automated text loading, see "Text Loading" in Chapter 4, "Text Concepts". For more information about setting up ConText servers to load text, see "Using ConText Servers for Automated Text Loading" in Chapter 6, "Setting Up and Managing Text". |
The DDL personality enables a ConText server to process requests for creating, optimizing, and dropping text indexes. The text index on a column is what allows users to query the text stored in the column.
The DDL personality also enables a ConText server to process DML requests when DML operations are processed in batch mode.
| See Also:
For more information about batch DML processing, see "DML" in Chapter 4, "Text Concepts". |
The DML personality enables a ConText server to automatically update the text index for a table when changes to the table are made that require the text index to be update. Such changes include inserting new documents, updating existing documents, and deleting existing documents.
| Suggestion:
When systems have a high volume of text inserts, updates, and deletes, assign the DML personality to multiple servers to better distribute the system load. |
The Query personality enables a ConText server to process queries for text stored either internally or externally in a text column in a database table. If no running ConText servers have the Query personality, queries submitted to ConText will fail.
The Linguistic personality allows a ConText server to process requests for the Linguistic Services and generate linguistic output. Linguistic output includes:
| Note:
The Linguistic personality is only required to process requests for Linguistic Services. Once the requests have been processed, Linguistic servers can be shut down or the Linguistic personality can be removed from the personality mask of a running ConText server. For more information about the Linguistic Services, see Oracle8 ConText Cartridge Application Developer's Guide. |
The DBA personality allows a ConText server to detect and correct client/server failures and perform system cleanup (recovery).
The DBA personality is automatically assigned to each ConText server during start up, which prevents a single point of failure in a multi-server configuration.
When a working ConText server detects a failed ConText server, it performs the following DBA actions:
When a table has a text column with an existing ConText index and the table is dropped without first dropping the index and policy for the column, the index tables and policy for the column remain in the system until recovery is performed.
System recover is performed automatically by ConText servers approximately every fifteen minutes.
System cleanup can also be performed manually using the RECOVER stored procedure in the CTX_ADM PL/SQL package.
The Text Request Queue is the logical mechanism ConText servers use to process all text operations, except for text loading.
When a client submits a request for a text operation, such as a query, the request is stored in the Text Request Queue. All available ConText servers scan the Text Request Queue regularly, retrieve pending requests if they have the appropriate personality mask, and perform the requested operations.This diagram illustrates how ConText servers with different personality masks access the Text Request Queue.
ConText servers process text requests in the Text Request Queue in the following order:
When a ConText server finishes processing a request of any type, it always checks the pipes and queues for the next pending request according to the precedence order.
The Text Request Queue is made up of the following database pipes and tables:
| See Also:
For more information about the queues used to process DML and Linguistic Services requests, see "DML Queue" and "Services Queue" in this chapter. |
Each ConText server has a dedicated administration pipe for administrative tasks that control its operation (e.g. server shutdown).
When a SQL statement or PL/SQL block includes a text query, the system dispatches the query to the query pipe.
The ConText servers notify the calling client when the operation is finished.
ConText dispatches all requests for DDL operations (e.g. CREATE_INDEX, DROP_INDEX, and OPTIMIZE_INDEX) to the DDL pipe.
The ConText servers notify the calling client when the operation is finished.
If a ConText server encounters a problem with a request in the DDL pipe, the error does not affect the pipe or the server processing the pipe. The errored request is recorded as a row in the Services Queue and the server continues processing the remaining requests in the pipe.
The CTX_INDEX_ERRORS view can be used to display errored DDL requests.
The ConText DML Queue notifies ConText servers of changes made to a table containing a text column with an existing index.
When a DML operation is performed (i.e. data in a text table is modified, deleted, or added), a request for an index update is automatically recorded in the DML Queue.
Requests are placed in the DML Queue by database triggers that are created automatically the first time a ConText index is generated by a ConText server for the text column.
If DML processing is running in immediate mode, the next available ConText server with the DML (M) personality picks up the requests and updates the index as soon as resources and system load allow.
If DML processing is running in batch mode, the requests are stored in the queue until a user explicitly requests DML processing. Then, available ConText servers with the DDL (D) personality pick up all the pending requests and process the requests as one or more batches.
The DML Queue is persistent. If the database goes down, the contents of the queue remains intact.
The DML Queue consists of two internal tables:
| Note:
DRQ_PENDING and DRQ_INPROG are internal tables and should not be accessed directly. To view the queue, use the System Administration tool or the DML Queue views provided with ConText. To administer the queue, use the CTX_DML package. For more information about the DML queue views, see "ConText Queue Views" in Appendix A, "ConText Server and Queue Views". For more information about the CTX_DML package, see "CTX_DML: ConText Index Update and Management" in Chapter 11, "PL/SQL Packages". |
This table contains one row for each DML operation (request for index update) that has not yet been picked up by a ConText server. The row indicates the specific cell that has changed in the text table.
| Note:
Requests are visible in the pending table only after the insert, update, or delete has been committed. |
When a request has been picked up by a ConText server with the DML or DDL personality, the row is deleted from the pending table and the server begins the index update. In addition, a row is written to the in-progress table to indicate that the request is being processed.
This table contains one row for each DML request being processed by a ConText server.
Once the ConText server finishes processing the request, the row is deleted from the in-progress table, indicating that the appropriate index has been updated to reflect the document modification that generated the request.
Requests in the DML Queue are processed in the order they are received, based on a time-stamp. Rows are inserted into the pending table without a timestamp. At a specified time interval, all unmarked rows within the pending table are marked with a time-stamp. The timestamp is based on the time each change was committed.
If a ConText server encounters a problem with a request in the DML Queue, the error does not affect the queue or the server processing the queue. The errored request is recorded as a row in the Services Queue and the server continues processing the remaining requests in the queue.
The CTX_INDEX_ERRORS view of the Services Queue can be used to display errored DML requests.
The DML Queue can be enabled/disabled manually to control processing of DML requests. When the DML Queue is disabled, the queue continues to accept requests; however, new requests and any pending requests in the disabled DML Queue are not picked up by ConText servers until the queue is enabled manually.
The Services Queue is used for processing requests for all ConText services. The Services Queue is designed to be extensible. As additional services are provided by ConText, the Services Queue is the mechanism by which the services will be managed. Currently, the Services Queue supports the following services:
When a request is submitted for Linguistic Services, the request is stored in the Services Queue. A request is picked up by the first available ConText server with the Linguistic personality and the server generates linguistic output for the specified request.
ConText servers with the Linguistic personality pick requests out of the queue based on the request priority and creation time-stamp. Clients may queue a request and continue to work while the request is being processed.
The Services Queue is asynchronous. Clients that place a request in the queue do not automatically block their subsequent requests while waiting for a reply. However, clients can choose to block their subsequent requests for a specified time when they submit requests.
The Services Queue is persistent. If the database crashes after a request has been placed in the queue, the request is still in the queue when the database is recovered.
The Services Queue consists of the CTX_SVCQ internal table. This table stores a row for each request for a ConText Linguistic Service, as well as the request status.
| Note:
CTX_SVQ is an internal table and should not be accessed directly. To view the queue, use the queue views or System Administration tool provided with ConText. To administer the Services Queue (e.g. cleaning up entries), use the CTX_SVC package or the System Administration tool. For more information about the CTX_SVC package, see "CTX_SVC: Services Queue Administration" in Chapter 11, "PL/SQL Packages". |
If a ConText server encounters a problem with a request in the Services Queue, the error does not affect the queue or the server processing the queue. The errored request is recorded as a row in the Services Queue and the server continues processing the remaining requests in the queue.
The CTX_LING_ERRORS view of the Services Queue can be used to display errored requests for Linguistic Services.
The Services Queue can be enabled/disabled manually to control processing of Linguistic Services requests. When the Services Queue is disabled, requests are still accepted into the queue; however, new requests and any pending requests in the disabled Services Queue are not picked up by ConText servers until the queue is enabled manually.
