Skip Headers
Oracle® Ultra Search Administrator's Guide
10g Release 2 (10.1.2)
Part No. B14041-01
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

5 Oracle Ultra Search Postinstallation Information

This chapter contains the following topics:

Changing Oracle Ultra Search Schema Passwords

There are two Oracle Ultra Search system schemas created during installation: WKSYS and WKPROXY. You can update the schema password in the following way:

With the Oracle Database release, after the database is installed, all user schema accounts are locked. To log on as user WKSYS (or WKPROXY), unlock WKSYS (or WKPROXY) by running the following statement as the SYSTEM or SYS database user:

ALTER USER WKSYS ACCOUNT UNLOCK IDENTIFIED BY password;

Configuring the Oracle Server for Oracle Ultra Search

The operations described in this section are database administration operations. They can be performed using Oracle Enterprise Manager or SQL*Plus.

Step 1: Tune the Oracle Database

Increase the Size of the Oracle Redo Logs, if necessary

Every instance of an Oracle database has an associated online redo log, which is a set of two or more online log files that record all committed changes made to the database. Online redo logs protect the database in the event of an instance failure. The size of redo log files determines the frequency of redo log file switches. This, in turn, significantly impacts text indexing speed. To reduce the frequency of log file switches, ensure that the redo log files are each 100MB or more.

The following section lists some tips on how to increase the redo log file sizes, if necessary. Enter the statements in the following section with the appropriate Oracle administrator privileges.


See Also:

  • Oracle Database Performance Tuning Guide

  • Oracle Database Administrator's Guide


  1. Locate redo log files and determine their sizes:

    SELECT v$logfile.member, v$logfile.group#, v$log.status, v$log.bytes
    FROM v$log, v$logfile
    WHERE v$log.group# = v$logfile.group#;
    
    
  2. Add larger redo log files:

    ALTER DATABASE ADD LOGFILE 'redo_log_directory/newredo1.log' size 100m;
    ALTER DATABASE ADD LOGFILE 'redo_log_directory/newredo2.log' size 100m;
    ALTER DATABASE ADD LOGFILE 'redo_log_directory/newredo3.log' size 100m;
    
    

    A production database should have more log members for each log group, and different storage devices should be used to increase performance and reliability.

  3. Drop the old log files. For each old redo log file, enter the ALTER SYSTEM SWITCH LOGFILE statement until that log file's status is INACTIVE. This is necessary to ensure that Oracle is not using that log file when you try to drop it.

    Then, drop the old redo log file with the following statement:

    ALTER DATABASE DROP LOGFILE 'redo_log_directory/redo01.log';
    ALTER DATABASE DROP LOGFILE 'redo_log_directory/redo02.log'; 
    ALTER DATABASE DROP LOGFILE 'redo_log_directory/redo03.log';
    
    
  4. Manually delete the old log files from the file system. For each old redo log file, use the appropriate operating system statement to delete the unwanted log file from the file system.

Increase the Size of the Undo Space

Every Oracle database must have a method of maintaining information that is used to roll back, or undo, changes to the database. Such information consists of records of the transactions, primarily before they are committed. Oracle refers to these records collectively as undo. The undo space created by the Oracle Installer may be too small. Oracle recommends that you use automatic undo management and increase the undo space.


See Also:

Oracle Database Administrator's Guide for details on using automatic undo management

Tune Oracle Initialization Parameters

Set the following values in the initialization file:

  • PROCESSES: Set this to 50 or more.

  • SORT_AREA_SIZE: Set this to 5MB or more.

  • SORT_AREA_RETAINED_SIZE: Set this to 5MB or more.

  • JOB_QUEUE_PROCESSES: Set this to three or higher. (Set it to at least one.) This is needed because the Oracle Ultra Search crawler is launched by scheduling a database job. If this is zero, then no database jobs are run. As a result, any attempts to launch the Oracle Ultra Search crawler fail. Also consider other requirements for job queue processes when you set this value.


See Also:

Oracle Ultra Search Readme for the latest information on initialization parameters relating to Oracle Ultra Search

Step 2: Create and Assign the Temporary Tablespace to the CTXSYS User

The starter database created by the Oracle Installer may create a temporary tablespace that is too small. Oracle Ultra Search uses the Oracle Text engine intensively. Therefore, a large temporary tablespace must be created for the Oracle Text system user CTXSYS. If you want greater read and write performance, create the tablespace on raw devices.

When you have created the temporary tablespace, assign it as the temporary tablespace for the CTXSYS user. To do so, you must log on as the SYSTEM or SYS user. Assign the temporary tablespace to the CTXSYS user with the following statement:

ALTER USER CTXSYS TEMPORARY TABLESPACE new_temporary_tablespace;

See Also:

Oracle Database Administrator's Guide for information on how to create a temporary tablespace

Step 3: Create a Large Tablespace for Each Oracle Ultra Search Instance User

For each Oracle Ultra Search instance, you must create a tablespace large enough to contain all data obtained during the crawling and indexing processes. This amount is subject to the amount of data you intend to crawl and index. However, it is often not possible to know in advance how much data you intend to collect. Try to obtain an estimate of the cumulative size of all data you want to crawl.

If you cannot estimate the size, then try to allocate as much space as possible. If you run out of disk space, then Oracle Ultra Search is able to resume crawling after you add more datafiles to the instance tablespace.

Here is an example of how to create a new tablespace:

CREATE TABLESPACE lmtbsb DATAFILE '/u02/oracle/data/lmtbsb01.dbf' SIZE 150M;

Pay attention to the STORAGE clause in your CREATE TABLESPACE statement. The amount of data to be stored in the tablespace can be very large. This can cause the Oracle server to progressively allocate many new extents when more storage space is needed. If the extent management clause specifies that each new extent is to be larger than the previous extent (that is, the PCTINCREASE setting is nonzero), then you could encounter the situation where the next extent that the Oracle server wants to allocate is larger than what is available. In such a situation, indexing halts until new extents can be added to the tablespace.

To mitigate this problem, certain instance-specific tables have explicit storage parameter settings. The initial extent size, next extent size, and PCTINCREASE setting are defined for these tables. These tables are created when a new instance is created. The tables and their storage clause settings are as follows:

DR$WK$DOC_PATH_IDX$I 
                (initial extent size 5M, next extent size 50M, PCTINCEASE 1)
DR$WK$DOC_PATH_IDX$K 
                (initial extent size 5M, next extent size 50M, PCTINCEASE 1)

If you want greater read and write performance, create the tablespace on raw devices.

Be sure to create a new large tablespace for each Oracle Ultra Search instance user.


See Also:

  • Oracle Database SQL Reference for more information on creating tablespaces and managing storage settings

  • Oracle Database Administrator's Guide for information on how to create a tablespace


Step 4: Create and Configure New Users for Oracle Ultra Search Instances

Oracle Ultra Search uses Oracle's fine grained access control feature to support multiple Oracle Ultra Search instances within one physical database. This is especially useful for large organizations or application service providers (ASPs) that want to host multiple disjoint search indexes within one installation of Oracle.


Note:

Oracle Ultra Search requires that each Oracle Ultra Search virtual instance belong to a unique database user. Therefore, as part of the installation process, you must create one or more new database users to own all data for your Oracle Ultra Search instance.

If you intend to create more than one database instance, you should also create multiple user tablespaces: one for each user.


You must grant the WKUSER role to database users hosting new Oracle Ultra Search instances.


See Also:

"Users Page"

Enter the following statements to create and configure a new user. Run these statements as the WKSYS, SYSTEM, or SYS database user.

CREATE USER username 
              IDENTIFIED BY password DEFAULT TABLESPACE default_tbs 
              TEMPORARY TABLESPACE temporary_tbs QUOTA UNLIMITED 
              ON default_tbs;

where username = name of the Oracle Ultra Search instance owner

and password = password of the Oracle Ultra Search instance owner

and default_tbs = default tablespace for the Oracle Ultra Search instance created in Step 3

and temporary_tbs = temporary tablespace created in Step 2

GRANT WKUSER TO username;

After these steps are completed, WKSYS or an Oracle Ultra Search super-user can create an Oracle Ultra Search instance on this user schema.

If you want this user to have the general administrative privilege or the super-user privilege, then log on as an Oracle Ultra Search super-user or WKSYS and go to the Users page in the administration tool to grant the appropriate privilege.

Step 5: Alter the Index Preferences

This step is optional.

An empty index is created when an Oracle Ultra Search instance is created. The existing index preferences, such as language-specific parameters, are defined in the $ORACLE_HOME/ultrasearch/admin/wk0pref.sql file.

You can modify these preferences so that all new Oracle Ultra Search instances use the modified preferences, or you can alter the index using your own preferences immediately after an instance is created. Alter the index using SQL.


Note:

The crawler transforms all documents into HTML files with binary document filtering before indexing begins.


See Also:

  • Oracle Text Application Developer's Guide

  • Oracle Text Reference


Configuring Oracle Ultra Search for SSL

Starting with Oracle Database 10g, Oracle Ultra Search supports secure socket layer (SSL). This means that in addition to HTTP-based URLs, Oracle Ultra Search can also access HTTPS-based URLs (that is, HTTP over SSL).Ultra Search treats SSL as a service of the JVM; thus, any customization, tuning, or configuration of the SSL should be done on the JRE level. Oracle Ultra Search uses the SSL service provided by Sun Microsystem's JDK. Sun's SSL implementation lets you easily replace the default Trust Manager, Key Manager, and truststore with the ones you choose. Truststore is a list of public SSL certificates identifying entities with which a peer is allowed to communicate over SSL. A truststore needs to be maintained. You may need to update expired certificates with new issues, or you may want to add new certificates to the truststore, effectively adding new entities to the list of ones you are willing to communicate with over SSL.For example, say you want to service a secure Oracle Portal installation using Oracle Ultra Search. And say your Oracle Portal installation does not have a certificate issued by one of the well known certificate authorities like Verisign; rather, it uses a self-signed certificate issued by you. That means that your Oracle Portal's certificate will not be in the truststore(s) used by Oracle Ultra Search. Consequently, you will need to add to the truststore the certificate identifying your Oracle Portal installation.Besides third party tools, Sun provides its own truststore management tool called keytool. You can use keytool to add, update, remove, and import certificates to and from Sun's truststore. Keytool also lets you create your own self-signed certificates.

Keep in mind that there might be more then one truststore that needs updating. The Oracle Ultra Search crawler and the midtier can use different JDK installations (for example, when the two are on separate tiers, as with Oracle Application Server or Oracle Collaboration Suite deployments). Each has its own separate truststore, which would need to be updated.


See Also:

Sun Microsystems documentation, including the JSSE User's Guide, for more information about using Sun's keytool key and certificate management utility, for information on customization of the SSL service, and for information on truststore management

Managing Stoplists

Every Oracle Ultra Search instance has a stoplist associated with it. A stoplist is a list of words that are ignored during the indexing process. These words are known as stopwords. Stopwords are not indexed because they are deemed not useful, or even disruptive, to the performance and accuracy of indexing.

Default Oracle Ultra Search Stoplist

During the installation process, a default stoplist is created for the Oracle Ultra Search product. Subsequently, when an Oracle Ultra Search instance is created, a copy of the default stoplist is created for the Oracle Ultra Search instance.

The default stoplist is created under the WKSYS schema. The default stoplist name is wk_stoplist. (This list is defined in the file $ORACLE_HOME/ultrasearch/admin/wk0pref.sql, which is run at installation).

Modifying Instance Stoplists

Modify the default stoplist by adding or removing stopwords from it. However, remember that these modifications do not affect existing Oracle Ultra Search instances. They only affect Oracle Ultra Search instances that are created after the modifications are made.

Modifying instance stoplists should be done as a last resort. Use one of the following methods:

  • Modify the default stoplist before creating the instance.

  • Replace the instance stoplist immediately after creating the instance.

Replacing the instance stoplist immediately after creating the instance affects only that instance. You must first create a user-defined stoplist.

In both cases, the result is that the Oracle Ultra Search instance stoplist is modified and defined before initial crawling. This means that all documents collected by the Oracle Ultra Search crawler are evaluated against the correct stoplist. It is important to modify the stoplist before initial crawling to avoid having to recrawl all documents.

Modifying Instance Stoplists Before Initial Crawling

  1. Modify the default stoplist before creating the instance.

    For example, to add the stopword "web" to the default stoplist, log on as user WKSYS in SQL*Plus, and run the following statement:

    EXEC ctx_ddl.add_stopword('wk_stoplist','web');
    
    

    To remove the stopword "web" from the default stoplist, log on as user WKSYS in SQL*Plus, and run the following statement:

    EXEC ctx_ddl.remove_stopword('wk_stoplist','web');
    
    

    Subsequently, the stoplists of all new instances reflect the modifications made to the default stoplist.

  2. Replace the instance stoplist immediately after creating the instance:

    You must create a new user-defined stoplist. Log on as the owner of the instance in SQL*Plus, and run the following statements:

    BEGIN   ctx_ddl.create_stoplist('example_stoplist'); 
            ctx_ddl.add_stopword('example_stoplist','example_stopword'); 
            ... (add more stopwords by repeated the previous 
            line with new stopwords) ... 
    END; 
    /
    
    

    To replace an instance stoplist with this new stoplist, log on as the owner of the instance in SQL*Plus, and run the following statement:

    ALTER INDEX wk$doc_path_idx rebuild parameters('replace stoplist example_stoplist');
    

See Also:

"Changing Oracle Ultra Search Schema Passwords" for information about changing the WKSYS password

Modifying Instance Stoplists After Initial Crawling

If necessary, alter an instance stoplist after initial crawling with one of the following methods:

  1. Add stopwords to the instance stoplist:

    Choosing to add stopwords to the instance stoplist does not affect any documents already crawled or indexed. This is not an expensive operation.

    For example, to add the stopword "web" to the instance stoplist, log on as the owner of the instance in SQL*Plus, and run the following statement:

    ALTER INDEX wk$doc_path_idx rebuild parameters('add stopword web');
    
    
  2. Replace the instance stoplist after initial crawling:

    Defining a new stoplist and replacing the instance stoplist with it invalidates the entire index. If you choose this method, you must force the Oracle Ultra Search crawler to recrawl all documents in the index. To do this, click Process All Documents in the Edit Schedule page. This is a very expensive operation. Therefore, this option should be the last resort.

Configuring the Query Application

The Oracle Ultra Search query application is deployed automatically with the Oracle Ultra Search installation. However, because Oracle Ultra Search allows multiple instances using different schema users, the query application is not configured for how to connect to the database automatically. Database connection is configured by creating a data source in OC4J (not to be confused with an Oracle Ultra Search data source). This is done by editing the data-sources.xml file.

Oracle Ultra Search lets multiple instances use different schema users, so multiple query applications can co-exist on the same database. Each query application requires its database connection information to be defined with data-sources.xml. They must be defined to have different location values, such as jdbc/UltraSearchPooledDS1, jdbc/UltraSearchPooledDS2, and so on. Correspondingly, the query application must be deployed multiple times in OC4J.

Each application deployment must be configured to use the correct entry in data-sources.xml. This is done by editing the JSP source for query. For the complete search application, edit common_customize_instance.jsp and edit the following line to use the correct location value:

String m_datasource_name = "jdbc/UltraSearchPooledDS"