10g (9.0.4) for Linux x86
Part Number B12261-03
 Home |
 Contents |
| Oracle® Application Server 10g Release Notes 10g (9.0.4) for Linux x86 Part Number B12261-03 |
|
This chapter describes issues associated with Oracle Ultra Search. It includes the following topics:
This section describes general issues and their workarounds for Oracle Ultra Search. It includes the following topics:
Oracle Ultra Search uses a set of codes to indicate the crawling result of the crawled URL. Besides the standard HTTP status codes, it uses its own codes for non-HTTP related issues. Only URLs with a status of 200 will be indexed. Table 11-1 lists the Oracle Ultra Search status codes.
Per the Oracle Application Server 10g Upgrading to 10g (9.0.4) document, you must apply database 9.0.1.5 patchset before you upgrade iAS 9.0.2 to Oracle Application Server 10g.
After you apply the patchset, do not perform the following post install actions as described in the patchset note:
"Execute the following steps only if you have installed Oracle Ultra Search in the database you are attempting to modify."
Instead, perform the following post install steps:
CONNECT / AS SYSDBA
GRANT SELECT ON SYS.DBMS_LOCK_ALLOCATED TO WKSYS;
ALTER USER WKSYS ACCOUNT UNLOCK;
ALTER PACKAGE WKSYS.WK_CRW COMPILE BODY;
ALTER PACKAGE WKSYS.WK_SNAPSHOT COMPILE BODY;
Oracle Ultra Search can only crawl public Oracle AS Portal sources. See the Oracle Application Server Portal Configuration Guide for how to set up public pages.
This section covers Important security considerations when using a single ACL to restrict access to a data source.
An Oracle Ultra Search data source can be protected by a single administrator specified ACL. This ACL specifies which users and groups are allowed to view the documents belonging to that data source.
Oracle Ultra Search uses the Oracle Server's ACL evaluation engine to evaluate permissions when queries are performed by search users. This ACL evaluation engine is a feature of Oracle XML database. If an Oracle Ultra Search query attempts to retrieve a document that is protected by an administrator specified ACL, the ACL is evaluated and subsequently cached.
The duration an ACL is cached is controlled by an XDB configuration parameter. Please consult the chapter titled "Oracle XML DB Resource Security" in the book Oracle XML DB Developer's Guide. The XDB documentation indicates that the /xdbconfig/sysconfig/acl-max-age parameter should be modified. The value is a number in seconds that determines how long ACLs are cached. Please see the chapter on "Installing and Configuring Oracle XML DB" for information on altering this configuration parameter.
Since ACLs are cached, it is important to remember that changes to an administrator specified ACL may not propagate immediately. This only applies to database sessions that existed before the change was made.
Two SQL scripts (wk0prefcheck.sql and wk0idxcheck.sql) under $ORACLE_HOME/ultrasearch/admin/ are used for this reconfiguration.
wk0prefcheck.sql is invoked under wksys to reconfigure default cache character set and index preference.
wk0idxcheck.sql is needed for reconfiguring instance(s) created before database character set change, e.g., the default instance. This script must be invoked by the instance owner and wk0prefcheck.sql must be run first as it depends on reconfigured default settings generated by wk0prefcheck.sql.
wk0idxcheck.sql will also drop and recreate the Oracle Text index used by Oracle Ultra Search. So if there are already data source indexed then user must force re-crawl all of the data sources.
wk0idxcheck.sql must be run once for each instance. So if there are two instances "inst1" and "inst2" owned by "owner1" and "owner2" respectively then wk0idxcheck.sql should be run twice; once by "owner1" and once by "owner2
All data returned to Oracle Ultra Search must be in the UTF-8 character set. However, multibyte character sets such as Chinese or Korean are incompatible with UTF-8. Therefore, Oracle Ultra Search does not correctly handle or recognize the incoming data.
An Oracle Ultra Search crawl of a data source with a multi-byte name will fail. An error of the file not being found occurs if the local environment that starts the Oracle database is not compatible with the locale's target files.
To correct this problem, you must set the correct locale, restart the Oracle database and force Oracle Ultra Search to re-crawl the data source.
For example:
SQL> shutdown immediate
'ja' using the following commands:
> setenv LANG ja > setenv LC_ALL ja
SQL> startup
Oracle Ultra Search does not support database character sets that are not supported by Oracle Text.
For example, the AL32UTF8 character set is not supported.
For Unicode support, use UTF8.
For the complete list of supported database character sets, please consult the Oracle Text Reference for Lexer Types.
An Oracle Ultra Search Administrator can log in as a database administrator or an SSO user who has been granted administrative privileges. In this release, when logging in as a database administrator, then under certain circumstances, the administrator will not be able to create nor edit administrator-specified ACLs for a data source. An "Access Denied" error will be encountered when attempting to create or modify ACLs. An "Access Denied" error is encountered. The workaround is to always log in as an SSO user in order to create/modify ACLs for a data source.
XML DB Dependency--the following two XML database bugs are identified in the 9.2.0.4 database release. They will be fixed in post 9.2.0.4 database patch release.
When using Oracle 9.2.0.4, the Oracle Ultra Search Administrators will not be able to view administrator specified ACLs after creation. As a result, these ACLs cannot be edited or modified. Administrators must therefore assume responsibility for keeping track of permissions specified in these ACLs. Furthermore, since ACLs cannot be viewed, they cannot be edited. As a result, if an ACL has to be changed, customers must drop the existing data source, recreate it, and assign a new ACL with the new permissions.
resource_view with updatexml Causes Core Dump
When using Oracle 9.2.0.4, this bug will prevent ACLs stored in the XDB repository from being updated. Therefore, even if bug 3172282 is fixed (and the administrator can view an administrator specified ACL after creation), the ACL cannot be successfully edited. As a result, if an ACL has to be changed, customers must drop the existing data source, recreate it, and assign a new ACL with the new permissions.
Oracle Ultra Search can be installed on top of an existing Oracle 9i (9.0.1.4) or later database. This can be done in one of two ways:
Oracle Application Server Repository Creation Assistant (OracleAS RepCA) converts a customer database into an OracleAS Metadata Repository. OracleAS RepCA will install all of the Oracle Application Server component schemas and also install the Oracle Ultra Search backend.
OracleAS RepCA is only available in the Oracle Application Server release. OracleAS RepCA is the recommended way of installing Oracle Ultra Search backend onto a customer database. Although there is the overhead of having all the other Oracle Application Server component schemas installed along with Oracle Ultra Search, you will get the benefits of OracleAS Infrastructure 10g (for example, Identity Management Integration, well defined processes for IM re-association, and so forth).
For details on how to use OracleAS RepCA to create an MR, refer to the "Using an Existing Database for the OracleAS Metadata Repository" section of the Oracle Application Server 10g Installation Guide.
IMPORTANT: For Oracle Ultra Search, there is a required post-OracleAS RepCA install configuration step. Oracle Ultra Search crawler is a Java application that requires JDK 1.4.1 or later. Oracle Ultra Search is configured by OracleAS RepCA to use the default JDK installation (for example, $ORACLE_HOME/jdk/bin/java), which in the pre-10g ORACLE_HOME is pre-JDK 1.4.1; thus, unless your $ORACLE_HOME/jdk/bin/java is already JDK 1.4.1 or later, you must perform the following steps:
ultrasearch/admin directory of the OracleAS RepCA CD. Then execute the wkrepca.sql script via SQLPLUS. You will have to connect as the wksys user and pass to the script the path to the JDK 1.4.1 or later Java executable. For example:
sqlplus wksys/wksys password@repca_cd/ultrasearch/admin/wkrepca.sql /usr/local/jdk1.4/bin/java
If you want to install only the Oracle Ultra Search backend into a customer database, you can opt for manual installation of Oracle Ultra Search backend. To illustrate this process here, we use the following values and conventions:
ORACLE_HOME--the Oracle home directory of the target database
SH -- the source directory, the directory on the OracleAS RepCA CD, that contains the Oracle Ultra Search directory (for example OracleAS RepCA)
Following are the steps involved in a manual installation of the Oracle Ultra Search backend:
$ORACLE_HOME/ultrasearch directory. You can do this by renaming this directory to $ORACLE_HOME/ultrasearch.old.
SH /ultrasearch to $ORACLE_HOME/ultrasearch.
$ORACLE_HOME/ultrasearch/admin.
wksys already exists on the target database then de-install it by executing:
sqlplus /nolog @$ORACLE_HOME/ultrasearch/admin/wk0deinstall.sql sysSYSPWCSTR
See below for the meaning of each parameter.
wk0setup.sql.
For example:
sqlplus /nolog @$ORACLE_HOME/ultrasearch/admin/wk0setup.sql $ORACLE_HOME CSTR sys SYSPW 'as sysdba' WKSYSPW TBLSPC TMPTBLSPC portal CFS oui PSEP JDBCDRV JDBCNLS JEXEC CTXHX JDBC_NODE JDBC_ ALL $ORACLE_HOME
where the various parameters are as follows (parameters should be enclosed in single quotes to avoid misinterpretation):
CSTR--TNS alias preceded with `@' (for example, @inst1), this parameter can also be passed in as a single white space (` `)
SYSPW--password for the SYS user/schema
WKSYSPW--password to be used for the Oracle Ultra Search schema wksys
TBLSPC--tablespace for wksys
TMPTBLSPC--temporary tablespace for wksys
CFS--if ORACLE_HOME is on a Cluster File System (CFS) then `true'; else `false'
PSEP--path separator (for example, on UNIX this is `:', on Windows it is `;')
JDBCDRV--path to JDBC drivers, classes12.zip (for example, $ORACLE_HOME/jdbc/lib/classes12.zip)
JDBCNLS--path to nls_charset12.zip or orai18.jar (for example, $ORACLE_HOME/jdbc/lib/nls_charset12.zip)
JEXEC - Java executable path (for example, /packages/jdk1.4.1/bin/java). Note that this has to point to a JDK 1.4.1 or later installation
CTXHX - path to INSOFILTER, ctxhx (for example, $ORACLE_HOME/ctx/bin/ctxhx)
JDBC_NODE - thin JDBC connect string, and only the part after the `@' (for example, HOST:PORT:SID); note that in case of RAC, this connect string must be to the current node
DBC_ALL - same as JDBC_NODE, but in case of RAC with CFS true, this JDBC string should include all the RAC nodes (hint: use TNS syntax)
If the database character set has been changed after Oracle Ultra Search installation, you must reconfigure the Oracle Ultra Search backend so that it can adapt to the new character set.
Two SQL scripts (wk0prefcheck.sql and wk0idxcheck.sql), located in $ORACLE_HOME/ultrasearch/admin/, are used for this reconfiguration:
wk0prefcheck.sql is invoked under wksys to reconfigure default cache character set and index preferences.
Running wk0idxcheck.sql also drops and recreates the Oracle Text index used by Oracle Ultra Search. If there are already data sources indexed, you must force a re-crawl of all of the data sources.
wk0idxcheck.sql must be run once for each instance. For example, if there are two instances, "inst1" and "inst2," owned by "owner1" and "owner2," respectively, then wk0idxcheck.sql should be run twice: once by "owner1" and once by owner2.
wk0idxcheck.sql is needed for reconfiguring instance(s) created before the database character set change (for example, the default instance). This script must be invoked by the instance owner, and wk0prefcheck.sql must be run first, as it depends on reconfigured default settings generated by wk0prefcheck.sql.
This section describes documentation errata for the Oracle Ultra Search User's Guide. It includes the following topics:
References to the "temporary directory" in the tuning and administration chapters should read "cache directory" instead.
Oracle Ultra Search only supports the "Crawl ACLs from the Data Source" mode for user-defined data source types where the crawler agent retrieves the ACL from the data source along with other document attributes. You cannot get ACL from a data source if it is a Web, table, portal, email, or file type.
With agent APIs, there is a new URL property "UrlData.ACL" that allows the agent to set the ACL of the URL submitted. There is also a new AclHelper class in the Agent APIs. This generates the ACL string to make sure that the ACL string format is correct.
Only Distinguished Name (DN) and Global User Id (GUID) can be used as the principal of an ACL.
The following additions and corrections apply to setting up a secure Oracle Ultra Search installation. Before you can set up a secure Oracle Ultra Search installation, you must:
The document currently states that you can use OracleAS RepCA to convert a 9.2.0.4 database to an iAS 9.0.4 metadata repository. It should add that you can do this if you have a 9.2.0.4 database.
You can use OracleAS RepCA to register the database to Oracle Internet Directory. After registration, you need to perform these manual steps:
Also, the reference to the Oracle Database Administrator's Guide for details on configuring the database to use Oracle Identity Management and Oracle Internet Directory should be ignored.
If you checked the "OracleAS Portal" option on the "Configuration Options" Oracle
Installer screen, then the configuration steps in the following section are automatically performed by the Oracle Portal Configuration Assistant (OPCA).
You do not need to perform any additional manual steps as indicated in the section text ("Editing the data-sources.xml File"). Everything is configured automatically.
For application.xml file, under the <orion-application> tag, change the following:
Change:
<library path="$ORACLE_HOME/ultrasearch/lib/ultrasearch_query.jar" /> <library path="$ORACLE_HOME/ultrasearch/webapp/config" /> <library path="$ORACLE_HOME/jlib/uix2.jar" /> <library path="$ORACLE_HOME/jlib/share.jar" /> <library path="$ORACLE_HOME/jlib/regexp.jar" /> <library path="$ORACLE_HOME/lib/mail.jar" /> <library path="$ORACLE_HOME/lib/activation.jar" /> <library path="$ORACLE_HOME/lib/xmlparserv2.jar" /> <library path="$ORACLE_HOME/jdbc/lib/nls_charset12.zip" /> <library path="$ORACLE_HOME/jdbc/lib/classes12.jar" />
to:
<library path="$ORACLE_HOME/ultrasearch/lib/ultrasearch_query.jar" /> <library path="$ORACLE_HOME/ultrasearch/webapp/config" /> <library path="$ORACLE_HOME/jlib/uix2.jar" /> <library path="$ORACLE_HOME/jlib/share.jar" /> <library path="$ORACLE_HOME/jlib/regexp.jar" /> <library path="$ORACLE_HOME/jdbc/lib/nls_charset12.zip" /> <library path="$ORACLE_HOME/jlib/repository.jar"/> <library path="$ORACLE_HOME/jlib/ohw.jar"/> <library path="$ORACLE_HOME/jlib/ldapjclnt9.jar"/> <library path="$ORACLE_HOME/j2ee/home/jazn.jar"/> <library path="$ORACLE_HOME/portal/jlib/ptlshare.jar"/> <library path="$ORACLE_HOME/portal/jlib/pdkjava.jar"/>
For the default-web-site.xml under the <web-site> tag, add the following:
Change:
<web-app application="UltrasearchAdmin" name="admin" root="/ultrasearch/admin" /> <web-app application="UltrasearchQuery" name="query" root="/ultrasearch/query"/> <web-app application="UltrasearchPortlet" name="query" root="/provider/ultrasearch" />
To:
<web-app application="UltrasearchQuery" name="query" root="/ultrasearch/query"/> <web-app application="UltrasearchQuery" name="welcome" root="/ultrasearch" /> <web-app application="UltrasearchAdmin" name="admin" root="/ultrasearch/admin" /> <web-app application="UltrasearchAdmin" name="admin_sso" root="/ultrasearch/admin_sso" /> <web-app application="UltrasearchAdmin" name="ohw" root="/ultrasearch/ohw" />
The content of the ultrasearch.properties file has changed.
Here is an example of the ultrasearch.properties file:
connection.driver=oracle.jdbc.driver.OracleDriver #If set, The JDBC connection URL specified here will override the dynamically #acquired one from OID. #This setting is also used by the 9i query sample (gsearch.jsp) #Example: connection.url=jdbc:oracle:thin:@<host>:<port>:<sid> connection.url=%JDBC_CONN_STR% oracle.net.encryption_client=REQUESTED oracle.net.encryption_types_client=(RC4_56,DES56C,RC4_40,DES40C) oracle.net.crypto_checksum_client=REQUESTED oracle.net.crypto_checksum_types_client=(MD5) oid.app_entity_cn=m16bi.sgtcnsun03.cn.oracle.com domain=us.oracle.com
You no longer need to configure the JDBC connect string in the ultrasearch.properties file. The database connect information is taken from Oracle Internet Directory.
Step 4 should read as follows:
4. Invoke the registration script.
@full_path_of_registration_script
The registration script for RMI-based remote crawling is the following:
$REMOTE_ORACLE_HOME/ultrasearch/tools/remotecrawler/scripts/<platform>/register.sql
The registration script for JDBC-based remote crawling is the following:
$REMOTE_ORACLE_HOME/ultrasearch/tools/remotecrawler/scripts/<platform>/register _jdbc.sql
For example, if the value for $REMOTE_ORACLE_HOME on a UNIX host is /home/oracle9i, then enter the following at the SQL*Plus prompt to register an RMI-based remote crawler:
/home/oracle9i/ultrasearch/tools/remotecrawler/scripts/unix/register.sql
Likewise, if you are running SQL*Plus on Windows, and $REMOTE_ORACLE_HOME is in d:\Oracle\Oracle9i, then enter the following at the SQL*Plus prompt to register a JDBC-based remote crawler:
d:\Oracle\Oracle9i\ultrasearch\tools\remotecrawler\scripts\winnt\register_jdbc.sql
For Oracle Ultra Search to access secure Web sites, you may need to import certificates into the crawler's trust store and the Oracle Containers for J2EE (OC4J) JVM's trust store.
The Oracle Ultra Search administration tool is a Web application that runs within the OC4J JVM. Secure portal instances require clients to authenticate with SSL. To discover page groups in secure portal instances, the Oracle Ultra Search administration tool must make HTTPS network calls.
By default, the OC4J JVM recognizes certificates of well-known certificate authorities. However, if the secure portal instance uses a self-signed certificate or a certificate signed by an unknown certificate authority, then you must import the portal's certificate into the OC4J JVM's truststore. This can be done with the keytool utility provided by Sun Microsystems.
The OC4J JVM default truststore is located at $ORACLE_HOME/jdk/jre/lib/security/cacerts.
At the end of this section the following note should be present:
Note: The remote crawler cache directory must be mounted to the server side crawler cache directory (specified under "Crawler" "Settings" tab), otherwise the documents can not be indexed.
|
 Copyright © 2003 Oracle. All Rights Reserved. |
|