Tip

Indexing text extenders to improve performance

Due to recent accounting scandals in the financial industry, the FCC may implement new regulations that require companies to preserve the content of electronic documents, primarily e-mail, for predetermined time periods. Being able to store and retrieve these documents in a DBMS might be advantageous. This tip written by Susan Lawson from an InformIT article discusses indexing text extenders to improve performance.

Indexing Text Extenders

Scans are just as undesirable in text documents as they are with our DB2 tables. We need to create indexes so that sequential scans of documents are not necessary. By using a text index, you can speed up the searches performed on these documents.

A text index contains important words as well as a list of words known as stop words, such as and and the, which will not be in a text index. This list can be modified, but you would only want to do it once at installation time. When a request is made, the index is searched for the important terms to determine which documents contain those specified terms.

To set up a text index, you first record the text documents that need to be indexed in a log table. This process occurs when a DB2 trigger is fired off during an insert, update, or delete of a column of a text document. Then, when the terms are inserted or updated in the text document, they are added to the index. They are also deleted from the index if they are deleted from the text document.

There are four types of text indexes, and the type must be established before you implement columns that will be using text extenders. Not all search options are available by all index types, so you want to make sure the index will suit your criteria for searching. The four types of indexes are as follows:

  • Linguistic: In this type of index linguistic processing is performed during the analysis for the text when creating an index. Before a word is inserted into the index, it is reduced to its base form. Queries also use linguistic processing when searching against this index. This index requires the least amount of space, but searches may be longer than those done against a precise index.
  • Precise: In this index the search terms are exactly as they are in the text document and are case-sensitive. The same processing is used for the query search terms, so they must match exactly. The search can be broadened by using masks. This index provides a more precise search, and the retrieval and indexing is fast, but more space is required for its storage.
  • Dual: Dual indexes are combinations of linguistic and precise indexes. This allows the user to decide which type of search to use. This index requires the most amount of disk space. It is slower for searching and indexing than the linguistic indexes and is not recommended for a large number of text documents.
  • Ngram: The Ngram index is used primarily for indexing DBCS documents; it analyzes text by parsing sets of characters. This index type also supports fuzzy searches.

When creating tables that will support the ability to search text using extenders, you must consider a few design options. You can create one text index for all text columns in the table, or you can have several different text indexes—one for each text column. Using separate indexes for each text column offers the most flexibility in terms of support for your searches. It also gives you other options, such as how frequently the index is updated and where it is stored. One common index is easier to maintain, but is less flexible. If your indexes are large, consider storing them on separate disks, especially if you expect to have concurrent access to the indexes.

You can also have multiple indexes on a single text column. You may want to do this if you need the ability to allow different types of searches on a text column. And just like other DB2 indexes, these indexes will need to be reorganized too. If you have a text column that is continually updated, you will need to reorganize it. However, when using these indexes, the text extender automatically reorganizes them in the background. Despite this feature, you still may have to reorganize an index manually every so often, depending on its volatility. This is done with the REORGANIZE INDEX command. Issue the GET INDEX STATUS command to see if an index needs reorganization.

Frequency of Index Updates

When text documents are added, deleted. or changed, their content must be synchronized with the index. This information is automatically stored by triggers in a log table, and the documents will be indexed the next time an index update is executed.

The indexes can be immediately updated via the UPDATE INDEX command, but it is easier to have this performed automatically on a periodic basis. This time-based information is kept in an environment variable called DB2TXUPDATEFREQ, which provides default settings that can be changed during the ENABLE TEXT COLUMN or ENABLE TEXT TABLE commands. For an existing index, you can use the CHANGE INDEX SETTINGS command to change the variable settings.

The variable for determining when indexing should occur is based on the minimum number of queued text documents in the log table, and when this minimum is reached, the index is updated. Because updating indexes is a very resource-intensive and time-consuming task, this frequency should be set carefully.

Catalog View for Text Extenders

There is a catalog view created for each subsystem when you run the ENABLE SERVER. This view is DB2TX.TEXTINDEXES. It has information about the tables and the columns that have been enabled for the text extender. The entries are made during table, column, or external file enablement. If they are disabled, the row is removed. You can view the entries in the catalog view via SQL. In this view you can see such information as how often the indexes are scheduled for updates, whether or not you have a multiple-index table, and the type of index.

Read more of this article at InformIT.

For More Information

  • Feedback: E-mail the editor with your thoughts about this tip.
  • More tips: Hundreds of free DB2 tips and scripts.
  • Tip contest: Have a DB2 tip to offer your fellow DBAs and developers? The best tips submitted will receive a cool prize -- submit your tip today!
  • Ask the Experts: Our SQL, database design, Oracle, SQL Server, DB2, metadata, and data warehousing gurus are waiting to answer your toughest questions.
  • Forums: Ask your technical DB2 questions--or help out your peers by answering them--in our active forums.
  • Best Web Links: DB2 tips, tutorials, and scripts from around the Web.

This was first published in June 2003

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.