This chapter contains the following topics:
After the database is installed, all user schema accounts are locked. To log on as user
WKPROXY) by running the following statement as the
SYS database user:
ALTER USER WKSYS ACCOUNT UNLOCK IDENTIFIED BY password;
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.
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
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. 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:
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. For this, you must log on as the
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 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
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:
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, then create the tablespace on raw devices.
Create a new large tablespace for each Oracle Ultra Search instance user.
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.
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.
See Also:"Users Page"
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
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.
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
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.
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
sql, which is run during installation).
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.
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.
Modify the default stoplist before creating the instance.
To remove the stopword "web" from the default stoplist, log on as user
WKSYS in SQL*Plus, and run the following statement:
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 the
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 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
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/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"