Skip Headers
Oracle® Ultra Search Administrator's Guide
11g Release 1 (11.1)

Part Number B28330-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

5 Oracle Ultra Search Postinstallation Information

This chapter contains the following topics:

Changing Oracle Ultra Search Schema Passwords

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

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:


From Oracle AS and Oracle Collaboration Suite, you can use the Enterprise Manager to change the password for WKSYS (or WKPROXY) of the metadata repository database.


To change WKSYS (or WKPROXY) password in OracleAS Metadata Repository, you must change their passwords using the Application Server Control Console so the password is updated in both the database and Oracle Internet Directory. See the Oracle Application Server Administrator's Guide and the component guides in the Oracle Application Server Documentation Library for details on how to alter the passwords for the components you have installed.

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.

  1. Locate redo log files and determine their sizes:

    SELECT v$logfile.member, v$, v$log.status, v$log.bytes
    FROM v$log, v$logfile
    WHERE v$ = v$;
  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. It is recommended to 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.

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. For this, you must log on as the SYSTEM or SYS user. Assign the temporary tablespace to the CTXSYS user with the following statement:


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 to resume Oracle Ultra Search 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;

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. Ensure that the STORAGE clause in your CREATE TABLESPACE statement specifies a value that can be allocated by the system.

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:

                (initial extent size 5M, next extent size 50M, PCTINCEASE 1)
                (initial extent size 5M, next extent size 50M, PCTINCEASE 1)

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

Create a new large tablespace for each Oracle Ultra Search instance user.

See Also:

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) which want to host multiple disjoint search indexes within one installation of Oracle.


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 
              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


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.


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

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. Truststore is a list of public SSL certificates identifying entities with which a peer can communicate over SSL. A truststore needs to be maintained. You need to update expired certificates with new issues, or add new certificates to the truststore. By adding new entities to the list you can communicate with them over SSL.For example, if you want to service a secure Oracle Portal installation using Oracle Ultra Search and if your Oracle Portal installation does not have a certificate issued by one of the well known certificate authorities, then 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 the keytool to add, update, remove, and import certificates from and to Sun's truststore. Keytool also enables you to create your own self-signed certificates.

There might be more then one truststore that needs updating. The Oracle Ultra Search crawler and the middle tier 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 needs 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

All 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 during installation). The stoplist is created only in English.

Modifying Instance Stoplists

You can modify the default stoplist by adding or removing stopwords. However, 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 the 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'); 
            ... (add more stopwords by repeated the previous 
            line with new stopwords) ... 

    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

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 enables multiple instances using different schema users, the query application is not configured 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"