毛毛的小窩 — 關注技術交流、讓我們一起成長

Oracle Text supports the creation of three types of indexes depending on your application and text source. You use the CREATE INDEX statement to create all Oracle Text index types.

The following table describes these indexes and the type of applications you can build with them. The third column shows which query operator to use with the index.

Index Type	ApplicationType	Query Operator
CONTEXT	Use this index to build a text retrieval application when your text consists of large coherent documents. You can index documents of different formats such as MSWord, HTML, XML, or plain text. With a context index, you can customize your index in a variety of ways.	CONTAINS
CTXCAT	Use this index type to improve mixed query performance. Suitable for querying small text fragments with structured criteria like dates, item names, and prices that are stored across columns.	CATSEARCH
CTXRULE	Use a CTXRULE index to build a document classification application. The CTXRULE index is an index created on a table of queries, where each query has a classification. Single documents (plain text, HTML, or XML) can be classified using the MATCHES operator.	MATCHES

With Oracle Text, you can create a CONTEXT index with columns of type VARCHAR2, CLOB, BLOB, CHAR, BFILE and XMLType.

NOTE The column types NCLOB, DATE and NUMBER cannot be indexed using a CONTEXT index.

1. Create a user to used for the following examples:

       CREATE USER            ctx_demo
       IDENTIFIED BY        ctx_demo
       DEFAULT TABLESPACE   ctx_demod
       TEMPORARY TABLESPACE temp;
       GRANT connect, resource, ctxapp, dba TO ctx_demo;

2. Set the instance pramater 'text_enable = FALSE'. This parameter had to be set to 'TRUE' in ConText (Pre interMedia Text 8.1.5). Ensure that the parameter now is set to FALSE.

    

3. Include $ORACLE_HOME/ctx/bin in your PATH variable.

    

4. On unix, the environment variable LD_LIBRARY_PATH or the SHLIB_PATH (depending on platform) must be set in the environment of the user using Oracle Text.

   SHLIB_PATH must be set instead of LD_LIBRARY_PATH when working with the HP platform.

   In versions below 8.1.7 it must also be set in the environment of the user who is starting and stopping the listener. Make sure that you set environment settings before starting extproc (lsnrctl start) because extproc looks up those values at startup time and modifications to these variables are thus not visible to the process resulting in indexing errors.

   Set the environment variable to: <ORACLE_HOME>/lib:<ORACLE_HOME>/ctx/lib where <ORACLE_HOME> is the explicit full path for ORACLE HOME. DO NOT use the $ORACLE_HOME environment variable.

   The variable can also be set in the ENVS section of the listener.ora file:

     SID_LIST_listener=
       (SID_LIST=
       (SID_DESC =
       (SID_NAME = PLSExtProc)
       (ORACLE_HOME = /u01/app/oracle/product/8.1.7)
       (ENVS=LD_LIBRARY_PATH = /u01/app/oracle/product/8.1.7/ctx/lib:/u01/app/oracle/product/8.1.7/lib)
       (PROGRAM = extproc)
       )
       (SID_DESC=
       (SID_NAME=OEM1DB)
       (ORACLE_HOME=/u01/app/oracle/product/8.1.7)
       )
       )

There are times when an index creation operations fail. Whenever the system encounters an error indexing a row, it logs the error into an Oracle Text view.

Ensure you are connected to the database as the user who created the index and query the view CTX_USER_INDEX_ERRORS. You may also view errors on ALL indexes in the database by connecting as CTXSYS and quering the view CTX_INDEX_ERRORS.

  SELECT err_timestamp, err_text
FROM ctx_user_index_errors
ORDER BY err_timestamp DESC;

DML operations to the base table refer to when documents are inserted, updated or deleted from the base table. This section describes how you can monitor, synchronize, and optimize the Oracle Text CONTEXT index when DML operations occur.

Note: CTXCAT indexes are transactional and thus updated immediately when there is an update to the base table. Manual synchronization as described in this section is not necessary for a CTXCAT index.

Viewing Pending DML

When documents in the base table are inserted, updated, or deleted, their ROWIDs are held in a DML queue until you synchronize the index. You can view this queue with the CTX_USER_PENDING view.

For example, to view pending DML on all your indexes, issue the following statement:

  SELECT pnd_index_name, pnd_rowid , TO_CHAR(pnd_timestamp, 'dd-mon-yyyyhh24:mi:ss') timestamp
FROM ctx_user_pending;

This statement gives output in the form:

  PND_INDEX_NAME PND_ROWID          TIMESTAMP
-------------- ------------------ --------------------
MYINDEX        AAADXnAABAAAS3SAAC 06-oct-1999 15:56:50

Synchronizing the Index

Synchronizing the index involves processing all pending updates, inserts, and deletes to the base table. You can do this in PL/SQL with the CTX_DDL.SYNC_INDEX procedure.

The following example synchronizes the index with 2 megabytes of memory:

  BEGIN
ctx_ddl.sync_index('myindex', '2M');
END;

Setting Background DML

You can set CTX_DDL.SYNC_INDEX to run automatically at regular intervals using the DBMS_JOB.SUBMIT procedure. Oracle Text includes a SQL script you can use to do this. The location of this script is:

  $ORACLE_HOME/ctx/sample/script/drjobdml.sql

To use this script, you must be the index owner and you must have execute privileges on the CTX_DDL package. You must also set the job_queue_ processes parameter in your Oracle initialization file.

For example, to set the index synchronization to run every 360 minutes on myindex, you can issue the following in SQL*Plus:

  SQL> @drjobdml myindex 360

Index Optimization

Frequent index synchronization can fragment your CONTEXT index. Index fragmentation can adversely affect query response time. You can optimize your CONTEXT index to reduce fragmentation and index size and so improve query performance.

To understand index optimization, you must understand the structure of the index and what happens when it is synchronized.

CONTEXT Index Structure

The CONTEXT index is an inverted index where each word contains the list of documents that contain that word. For example, after a single initial indexing operation, the word DOG might have an entry as follows:

  DOG DOC1 DOC3 DOC5

Index Fragmentation

When new documents are added to the base table, the index is synchronized by adding new rows. Thus if you add a new document (DOC 7) with the word dog to the base table and synchronize the index, you now have:

  DOG DOC1 DOC3 DOC5
DOG DOC7

Subsequent DML will also create new rows:

  DOG DOC1 DOC3 DOC5
DOG DOC7
DOG DOC9
DOG DOC11

Adding new documents and synchronizing the index causes index fragmentation. In particular, background DML which synchronizes the index frequently generally produces more fragmentation than synchronizing in batch.

Less frequent batch processing results in longer document lists, reducing the number of rows in the index and hence reducing fragmentation.

You can reduce index fragmentation by optimizing the index in either FULL or FAST mode with CTX_DDL.OPTIMIZE_INDEX.

Document Invalidation and Garbage Collection

When documents are removed from the base table, Oracle Text marks the document as removed but does not immediately alter the index.

Because the old information takes up space and can cause extra overhead at query time, you must remove the old information from the index by optimizing it in FULL mode. This is called garbage collection.

Optimizing in FULL mode for garbage collection is necessary when you have frequent updates or deletes to the base table.

Single Token Optimization

In addition to optimizing the entire index, you can optimize single tokens. You can use token mode to optimize index tokens that are frequently searched, without spending time on optimizing tokens that are rarely referenced.

For example, you can specify that only the token DOG be optimized in the index, if you know that this token is updated and queried frequently.

An optimized token can improve query response time for the token.