Oracle® Ultra Search Administrator's Guide
10g Release 2 (10.1.2) Part No. B14041-01 |
|
Previous |
Next |
This chapter contains the following topics:
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;
The operations described in this section are database administration operations. They can be performed using Oracle Enterprise Manager or SQL*Plus.
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:
|
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#;
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.
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';
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:
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 |
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 |
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 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.
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.
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:
|
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 |
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.
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).
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.
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.
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 theWKSYS password
|
If necessary, alter an instance stoplist after initial crawling with one of the following methods:
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');
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.
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"