C Using OracleAS Portal Installation and Configuration Scripts

C.1 Managing the Invalidation Message Processing Job Using cachjsub.sql

OracleAS Portal uses caching to improve its performance. One type of caching it uses is the invalidation-based caching. In invalidation-based caching, OracleAS Portal caches various objects (pages, portlets, and so on) for a set amount of time. When these objects are requested, they are retrieved from the cache, if available; otherwise they are regenerated from the Oracle Application Server Metadata Repository. The cache for these objects will expire when the maxcache time has been reached, or when the objects are explicitly invalidated (expired) by invalidation messages.

OracleAS Portal uses invalidation messages when it needs to expire objects in the cache. Invalidation messages are categorized as hard and soft invalidations. Hard invalidations take effect immediately, that is, the objects that they intend to invalidate expire from cache immediately. Soft invalidations take effect when they are processed by the invalidation processing job. The frequency by which the invalidation job executes is configurable. This is done using the cachjsub.sql script.

To change the execution frequency of the invalidation processing job:

1. Locate the following directory:

   ORACLE_HOME/portal/admin/plsql/wwc

2. On the database where the portal schema is installed, log on to SQL*Plus with the appropriate user name and password for that schema.

   For example:

   sqlplus portal/portal
   
   

3. Enter the following command to update the execution frequency of the invalidation job:

   SQL> @cachjsub.sql <start_time> <start_time_fmt> <interval_mins>
   
   

   cachjsub.sql takes three parameters:

   • start_time is either when the first job should be run or START.

   • start_time_fmt is the Oracle date format model to be applied to the value of start_time. Refer to the database documentation library for more information about the Oracle date format model.

   • interval_mins is how many minutes each run is scheduled apart.

     
     

     Note: If START is provided for the first parameter, the second parameter is ignored, and it will default the start time to the current time.

     
     

   Example 1:

   SQL> @cachjsub.sql START null 120
   
   

   Example 2:

   SQL> @cachjsub.sql '02-22-2005 7:30' 'MM-DD-YYYY HH:MI' 1440
   
   

   Example 3:

   SQL> @cachjsub.sql '06-14-2005 15:30' 'MM-DD-YYYY HH24:MI' 60
   
   

   Note: Example 3 shows time in the 24-hour format.

C.2 Disabling the IP Check of Cookie Validation

As part of the process of validating the session cookie of a user's request (even if that user is PUBLIC), OracleAS Portal performs a comparison between the IP address stored in the cookie with the IP address of the current client. Only if the two values are the same will OracleAS Portal consider the request legitimate.

When a proxy exists between the user's client and the portal, the IP address stored in the session cookie is that of the proxy, and not that of the client.

Some proxy systems make use of multiple servers, each with different IP addresses. In these circumstances, it is conceivable that the original request from a user's client (the request that causes the session cookie to be created) is routed through one proxy server and that a subsequent request is routed through another, separate, proxy server. In these cases, the IP addresses compared by OracleAS Portal will differ. The request will raise a security violation during the IP checking step. And access to the page will be denied.

Depending on the network configuration into which the Oracle Application Server is installed, it may be necessary to disable IP checking in cookie validation.

To change the state of IP checking in cookie validation, you must use SQL*Plus to update data in both the portal schema and the SSO schema as detailed in Table C-1.

C.3 Using the secupoid.sql Script

By default, OracleAS Portal connects to Oracle Internet Directory using LDAP without SSL. If the Oracle Internet Directory server is configured for an SSL port, though, OracleAS Portal can be configured to use LDAP over SSL, also known as LDAPS.

To configure OracleAS Portal to use SSL to connect to Oracle Internet Directory, you must run the secupoid.sql script. This script enables you to change the following OracleAS Portal configuration parameters related to Oracle Internet Directory:

• Oracle Internet Directory host name

• Oracle Internet Directory port

• application Oracle Internet Directory password

• SSL setting

When you install OracleAS Portal, it is automatically configured to use an Oracle Internet Directory server. However, you may want to change some settings, such as whether to use SSL, after installation. To change to an SSL connection for Oracle Internet Directory, simply run the ORACLE_HOME/portal/admin/plsql/wwc/secupoid.sql script in the PORTAL schema to specify the LDAPS port instead of the LDAP port, and indicate that you want to use SSL.

Running the secupoid.sql Script

This section shows a sample execution of secupoid.sql from SQL*Plus.

In the example, Oracle Internet Directory was initially configured to run LDAP on port 389. Later, an LDAPS port was activated on 636. Because the server name does not change, we retain the old value, update the port, and indicate that we want to use SSL by setting the Use SSL? value to Y. When you run the script, it displays the current configuration and lets you replace any of the configurable settings. The script also enables you to update OracleAS Portal's Oracle Internet Directory cache after running it. Because activating SSL does not change any of the Oracle Internet Directory information cached by OracleAS Portal, it is not usually necessary to refresh the cache in this case.

SQL> @secupoid 
Current Configuration 
-------------------- 
OID Host: oid.domain.com 
OID Port: 389 
Application DN: 
orclApplicationCommonName=PORTAL.040820.123756.096286000,cn=Portal,cn=Products,cn=OracleContext 
Application Password: 3E8C2D1B87CB61011757239C5AA9B390 
Use SSL? N 

PL/SQL procedure successfully completed. 

Updating OID Configuration Entries 
Press [Enter] to retain the current value for each parameter 
For SSL Connection to LDAP, specify "Y"es or "N"o 
------------------------------------------------ 
Enter value for oid_host: 
Enter value for oid_port: 636 
Enter value for app_password: 
Enter value for use_ssl_to_connect_to_ldap: Y 
Enter value for refresh_with_new_settings: N 

PL/SQL procedure successfully completed. 

No errors.

After executing the script, OracleAS Portal is configured for LDAPS access of Oracle Internet Directory.

When secupoid.sql is run, it can change the port number of Oracle Internet Directory stored in the portal schema of the OracleAS Metadata Repository. Running secupoid, however, does not change the values stored in iasconfig.xml. You must manually update the LDAPPort and PortSSLEnabled attributes in the OIDComponent element in iasconfig.xml so that subsequent runs of ptlconfig will not reverse the new settings. Refer to Section A.2, "Portal Dependency Settings File" for more information on the Portal Dependency Settings File.

C.4 Using the secjsdom.sql Script

If you have your Oracle Internet Directory and OracleAS Portal servers residing in different domains, you must explicitly set the JavaScript domain for OracleAS Portal such that it can resolve user and group lists of values. To do this, you must use the secjsdom.sql script located in the directory ORACLE_HOME/portal/admin/plsql/wwc.

Suppose your installation has OracleAS Portal configured to use an Oracle HTTP Server other than Oracle Delegated Administration Services. In this situation, you must have a common domain, so that the values can be transferred from the list of values displayed by Oracle Delegated Administration Services to the page displayed by OracleAS Portal.

To create a common domain for this scenario, follow the steps in Example C-1:

If, in Example C-1, the Oracle Delegated Administration Services servlet is running on a computer infra.abc.com and OracleAS Portal is running on a computer portal.abc.com, then the secjsdom.sql script should be invoked like this:

@ SQL> @secjsdom.sql abc.com

Performing this procedure enables you to run Oracle Internet Directory lists of values from OracleAS Portal in either Netscape, or Internet Explorer. When using lists of values, a transit window is displayed in addition to the list of values itself. The transit window is required to pass values to OracleAS Portal without forcing pages to reset their domain.

To reset a common domain that was defined, run the secjsdom.sql script as shown in Example C-2:

C.5 Configuring the Portal Session Cookie

OracleAS Portal uses a session cookie to maintain session state for portal applications. For portal to work correctly, the client browser must be configured to accept cookies from the server. Upon installation, the portal session cookie has a default name, scope, and security that are set appropriately for most installations. This section describes these defaults, and how they can be changed if needed.

SQL> @ctxckupd
OracleAS Portal
Current Settings for Portal Session Cookie:
Cookie Domain : Only send cookie back to originating host:port
Set Cookie as Secure: Y
Enter the domain for the session cookie...
Leave blank to scope to originating host:
Should cookie be flagged as secure for HTTPS sessions? (Y/N): N
Settings changed to
Cookie Domain : Only send cookie back to originating host:port
Do not set cookie as secure. (N)
SQL>

C.6 Managing the Session Cleanup Job

OracleAS Portal and OracleAS Single Sign-On perform session management similar to other Web-based applications. Sessions are tracked with cookies. Session information is stored in a table in the OracleAS Portal and OracleAS Single Sign-On schema. When a user logs out, the session information is marked inactive. A DBMS job subsequently cleans up the inactive rows.

The session table accumulates a number of rows that are flagged as active. When a user shuts down the browser instead of logging out, the row is "active", even though it is not actually in use. The cleanup job cleans up the active rows that are older than a specified duration.

When OracleAS Portal is installed, a DBMS job is installed to perform session cleanup of the session table, WWCTX_SSO_SESSION$. The cleanup job is set to run every 24 hours. The first scheduled cleanup occurs 24 hours after the installation of the job.

When the job runs, it deletes all inactive sessions and all sessions marked active (WWCTX_SSO_SESSION$.ACTIVE = 1), that are older than 7 days (WWCTX_SSO_SESSION$.SESSION_START_TIME < sysdate - 7).

These default settings can be modified by running some job management scripts in the OracleAS Portal schema to manage portal sessions, or in the OracleAS Single Sign-On schema to manage OracleAS Single Sign-On sessions. They utilize the same session management infrastructure.

Follow these steps to obtain the current cleanup job information:

1. Locate the following directory:

   ORACLE_HOME/portal/admin/plsql/wwc
   
   

2. On the database where the OracleAS Portal or OracleAS Single Sign-On schema is installed, log in to SQL*Plus with the appropriate user name and password for that schema.

   For example:

   sqlplus portal/portal
   
   

3. Enter the following command to get the current job information:

   SQL> @ctxjget
   
   

   The command results in the display of the currently installed job information, as returned by the DBMS_JOB package:

   The session cleanup job is job ID 7381
   dbms_job.isubmit(job=>7381,what=>'begin execute immediate''begin
   wwctx_sso.cleanup_sessions(p_hours_old => 168); end;''; exception when
   others then null; end;',next_date=>to_date('2001-04-17:14:07:20',
   'YYYY-MM-DD:HH24:MI:SS'),interval=>'SYSDATE + 24/24',no_parse=>TRUE);
   
   PL/SQL procedure successfully completed.
   
   

The results indicate which procedure is executed, what parameters are passed to it, and when the next invocation is to occur. This particular example indicates that the job is to clean up active sessions that are a week old (168 hours). It also indicates that the next scheduled job execution is on 4/17/2001 at 5:14 pm, and the job should run every 24 hours thereafter.

If the job execution must be modified, either to adjust the age of sessions that should be deleted, or to increase or decrease the frequency of cleanup, you can run the ctxjsub.sql script to submit modified execution parameters.

Follow these steps to submit modified job execution parameters:

1. Locate the following directory:

   ORACLE_HOME/portal/admin/plsql/wwc
   
   

2. On the database where the OracleAS Portal or OracleAS Single Sign-On schema is installed, log on to SQL*Plus with the appropriate user name and password for that schema. For example:

   sqlplus portal/portal
   
   

3. Enter the following command to submit new cleanup job information:

   @ctxjsub <hours_old> <start_time> <time_format> <interval_hours>
   
   

Table C-2 lists the ctxjsub parameters.

For example:

SQL> @ctxjsub 200 '04/17/2001 10:00' 'MM/DD/YYYY HH24:MI' 12

The job information is displayed, similar to:

Created path for job id.
DBMS_JOB id = 7381
Cleanup job updated. Job ID = 7381

PL/SQL procedure successfully completed.

The cleanup job submission script can be run any number of times to modify the execution parameters. Each invocation updates the job information associated with the job ID for the cleanup job. This job ID is maintained in the preference store so that the job information is updated instead of submitting multiple jobs.

You can also specify a start_time of START, in which case, the time_format parameter is ignored, but you still need to pass it a value (such as NOW). The result is to run the job <interval_hours> hours from now:

SQL> @ctxjsub 168 START NOW 24

This submits the job as it does in the installation.

If you want the cleanup job to execute immediately, then obtain the job ID by calling ctxjget.sql. Once you know the job ID, you can execute the job by issuing the following command in the product schema:

SQL> exec dbms_job.run(7381);

In the preceding example, 7381 is the job ID returned by the call to ctxjget.sql. When you execute a job in this manner, the next automated invocation of the job occurs at interval_hours after this manual invocation. To run the job on the original schedule, resubmit the start_time desired using ctxjsub.sql.

C.7 Timing and Caching Statistics

All OracleAS Portal pages can be run in a special mode in which timing and caching information is displayed. If you want to see this debug information on every page you can set the Parallel Page Engine Parameter showPageDebug to true in the web.xml file.

If you want to see the debug information for just a few select pages and portlets, you can control the logging level by the _debug URL parameter. For example, to see the timing statistics for the following OracleAS Portal page:

http://abc.com/servlet/page?_pageid=21

You can manually insert &_debug=3

To make:

http://abc.com/servlet/page?_pageid=21&_debug=3

Possible values for _debug are 0, 1, 2, 3, 4, and 5.

Values greater than 1 will potentially raise the logmode value for the duration of the request, and trigger all request log messages to be echoed into the page response.

Table C-3 shows the results of _debug values:

urlDebugMode and urlDebugUsers are additional parameters that can be used to restrict the use of _debug on a URL. See Appendix D, "Configuring the Parallel Page Engine" for more information.

The following statistics are available when the portal page is run in debug mode:

• Portlet Statistics

• Page Statistics

• Additional Summary Statistics

Figure C-1 shows a page that is running in the _debug=0 mode:

Figure C-1 Portal Page Running in Debug Mode

Description of "Figure C-1 Portal Page Running in Debug Mode"

C.8 Using the cfgiasw Script to Configure Mobile Settings

If you want to change portal's references to OracleAS Portal or OracleAS Wireless' portal service URLs, you need to use the script cfgiasw.pl to manually update the references. The script file is located here:

ORACLE_HOME/assistants/opca/

Running the script without parameters will print its usage to the screen, which is shown next:

Usage:

perl cfgiasw.pl -s portal_schema 
     -w ias wireless url 
     -h portal home page url 
     -c connect_string

For non-hosted Portals, the OracleAS Wireless' Portal service URL reference can be set in the Mobile tab of the Global Settings page, except the URL of the OracleAS Portal home page, which can only be set using the cfgiasw script.

This script is used to set references to both the OracleAS Wireless Portal Service URL and the OracleAS Portal home page URL, in OracleAS Portal. It can be used in a hosted environment to set the URL references, and will affect all subscribers, because this information is not configured separately for each subscriber. For example:

perl cfgiasw.pl -s portal -c portal_db -w "http://<iaswhost>:<port>/ptg/rm?PAoid=$wireless_service_id"

In the preceding example, if a mobile device makes a request to the OracleAS Portal directly without being mediated by an Oracle Application Server Wireless server, OracleAS Portal redirects the client to the URL specified here. This URL should be the OracleAS Portal's service URL on the Oracle Application Server Wireless server, in the form:

http://<host>:<port>/ptg/rm?PAoid=<service_id>

If this setting is blank, then mobile client requests made directly to OracleAS Portal receive an HTTP status indicating that their request is not supported.

See Section 4.6, "Configuring Mobile Support in OracleAS Portal" for configuring other mobile settings in OracleAS Portal.

C.9 Using the ptlinvsw.sql Script to Invalidate Portal Container Pages

If a user navigates to a subpage within a page portlet and edits it, the changes are not visible immediately unless the page containing the portlet is invalidated by other means.

Session store lookup helps solve this issue. When a page is edited, the session store is first looked up to determine all the pages that have a portlet which is currently displaying the edited page, and then those pages are invalidated.

Because the session store lookup affects performance, this feature is not enabled by default.

To enable portal container page invalidation:

1. On the database where the OracleAS Portal schema is installed, navigate to the ORACLE_HOME/portal/admin/plsql/wws directory.

2. Log on to SQL*Plus with the appropriate user name and password for the portal schema.

   For example:

   sqlplus portal/portal
   
   

3. Enter the following command:

   SQL> @ptlinvsw.sql TRUE
   
   

   To disable this invalidation option, enter the following command:

   SQL> @ptlinvsw.sql FALSE
   
   

C.10 Using the Category and Perspective Scripts

To ensure that all new category and perspective pages are created without errors and that all existing category and perspective pages display their associated items and pages as expected, you should run the category and perspective scripts.

The scripts required are:

ORACLE_HOME/portal/admin/plsql/wws/pstdefin.sql
ORACLE_HOME/portal/admin/plsql/wws/pstpgshw.sql
ORACLE_HOME/portal/admin/plsql/wws/pstundef.sql
ORACLE_HOME/portal/admin/plsql/wws/pstpgcre.sql
ORACLE_HOME/portal/admin/plsql/wws/pstprcpg.sql

To run these scripts:

1. Delete the current category or perspective templates.

2. Connect to OracleAS Portal using SQL*Plus as the portal schema user.

3. Configure the pstdefin.sql file with:

   • Page group information. You can re-create the pages in a single page group, several page groups or all page groups.

   • Page information. You can re-create category pages only, perspective pages only, or both.

   Descriptions for these settings are in the pstdefin.sql file.

   • If necessary, use the script pstpgshw.sql to retrieve information from OracleAS Portal to configure the pstdefin.sql file.

   • Run the script pstpgcre.sql to apply the changes. For example:

   • SQL> @pstpgcre.sql
     
     

When the new pages are created, if the template exists in the page group, new category and perspective pages will be created based on the template. If the user deletes the template in the page group before running the scripts, or if the template is missing, then a new template will be created in the page group and the new pages will be based on this template.

C.11 Using the ptlwsrp_data.sql Script to Create the WSRP Portlet Preference Store

The Web Services for Remote Portlets (WSRP) producer is deployed out-of-the-box, but the portlet preference store for this is not created by default. To enable users to register the producer with OracleAS Portal, you must first create the portlet preference store and make entries in the data-sources.xml file.

To create a portlet preference store and make entries in the data-source.xml, perform the following steps:

1. Stop the OC4J instance in which the portlet container is deployed.

2. Connect to the database as a user with SYSDBA privileges using the following command:

   sqlplus "sys/<sys_password>@<service_name> AS SYSDBA"
   
   

3. To create the preference store, run the ptlwsrp_data.sql script using the following command:

   @ptlwsrp_data portlet_prefs portal
   
   

   The portlet_prefs parameter is the name of the user account that stores the data and portal is the name of the default table space to use for that account. By default the password for the user account is the same as the name of the user account.

4. Edit the data-source.xml file in the <ORACLE_HOME>/j2ee/home/config directory. Add a new entry to map the connection details for the preference store schema by setting the ejb-location to jdbc/portletPrefs, as shown in the following example:

   <data-source 
     class="com.evermind.sql.DriverManagerDataSource" 
     name="OracleDS" location="jdbc/emulatedPortletPrefs"
     xa-location="jdbc/xa/portletPrefs" ejb-location="jdbc/portletPrefs"
     connection-driver="oracle.jdbc.driver.OracleDriver" 
     username="portlet_prefs" password="portlet_prefs" 
     url="jdbc:oracle:thin:@xyz.oracle.com:1521:orcl"
   />
   
   

   Insert valid database details for the url attribute.

5. Run the dcmctl utility with the following options to make sure that the file is synchronized with the Distributed Configuration Management (DCM) repository:

   <oracle_home>/dcm/bin/dcmctl updateConfig -co home -v
   
   

6. Restart OC4J.

C.12 Using the Preference Store Migration and Upgrade Utility

A preference store is a mechanism for storing information like user preference data, portlet and provider settings, or even portlet data, while using OracleAS Portal. Currently, PDK-Java has two PreferenceStore implementations, DBPreferenceStore and FilePreferenceStore. DBPreferenceStore persists data using a JDBC compatible relational database and FilePreferenceStore persists data using the file system.

If you have already installed OracleAS PDK, you can manage the information stored in the preference store by using the Preference Store Migration and Upgrade Utility, which is included in the pdkjava.jar file. For a complete description of the syntax of the utility, use the following command:

java -classpath ORACLE_HOME/portal/jlib/pdkjava.jar oracle.portal.provider.v2.preference.MigrationTool

You can run the Preference Store Migration and Upgrade Utility in either of the following modes based on the -mode you select while running the command:

• Upgrade mode

• Migration mode

Upgrade Mode

Use an upgrade mode to upgrade data in place, and to modify existing locale-specific preferences in the preference store so that the naming format used is compatible with the current version of OracleAS Portal and a given localePersonalizationLevel setting.

Table C-5 describes the upgrade modes in which you can run the utility.

An upgrade mode can be used in the following scenarios:

• You have upgraded from OracleAS PDK 9.0.4.0.0 or earlier and want to use existing portlets with the default localePersonalizationLevel setting of language (In earlier releases, the default setting was locale).

• You have upgraded from OracleAS Portal 9.0.2.0.0 or earlier and want to use existing portlets with a localePersonalizationLevel setting of locale (OracleAS Portal now uses different names for some locales and therefore some existing data must be remapped).

• You want to change the localePersonalizationLevel for an existing portlet from locale to language or vice-versa.

When using an upgrade mode, you must use the -remap option to specify the localePersonalizationLevel (language or locale) that you are upgrading to. You can also use the -countries option to specify a prioritized list of ISO country codes, indicating your order of preference in case of a collision between remapped preferences for different countries. For example, if you specify -remap language -countries GB,US in the command, it means that if the utility comes across both US English and British English preferences (en_US and en_GB) in a given preference store, it will remap the British English preference to become the English-wide preference (en).

Migration Mode

Use a migration mode to copy data from a source preference store to a target preference store. When the utility is run in this mode, the preference stores for all the portlet definitions are updated.

Table C-6 describes the migration modes in which you can run the utility.

When using a migration mode, you can use the -remap and -countries options to specify that the data should be upgraded in the course of being migrated, that is, locale-specific preferences should be remapped appropriately.

The other options accepted by the utility are used to specify the properties of the preference stores involved in the upgrade or migration process. These options must correspond to the tags you specify in provider.xml to describe the preference stores. For more information about the properties you can set on a preference store, refer to the PDK-Java XML Provider Definition Tag Reference document on Portal Studio:

http://portalstudio.oracle.com/pls/ops/docs/folder/community/pdk/jpdk/v2/xml_tag_reference_v2.html

Properties beginning with the prefix -pref1 correspond to properties of the source preference store (in an upgrade mode this is the only preference store). For example, specifying -pref1UseHashing true -pref1RootDirectory j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sample would set the useHashing and rootDirectory properties of a source FilePreferenceStore.

When one of the migration basic modes is selected, properties beginning with the prefix -pref2 correspond to properties of the target preference store. For example, specifying -pref2User portlet_prefs -pref2Password portlet_prefs -pref2URL jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid would set the database connection details on a target DBPreferenceStore.

Following are some examples to illustrate the usage of the utility:

java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar
 oracle.portal.provider.v2.preference.MigrationTool -mode file -remap language
 -countries GB,US -pref1UseHashing true -pref1RootDirectory
 j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sample

java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar
 oracle.portal.provider.v2.preference.MigrationTool -mode filetodb -remap locale
 -countries AR,MX -pref1UseHashing true -pref1RootDirectory
 j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sample -pref2User portlet_
prefs -pref2Password portlet_prefs -pref2URL
 jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid

C.13 Using the Schema Validation Utility

The Schema Validation Utility (SVU) is used to clean up and report any data inconsistencies in the Portal schema. The SVU performs validations on Page Group objects and DB Provider objects.

Some of the benefits of using the SVU are:

• It prevents OracleAS Portal import from failing due to data inconsistencies between the source and target Portal instances.

• It prevents OracleAS Portal patching from failing. For example, when applying the 9.0.4.1 patch to a 9.0.4.0 version of Portal.

You can run the Schema Validation Utility in the following scenarios:

• Before a Portal Export on the source Portal instance. You can choose to run the SVU in this case.

• Before a Portal Import on the target Portal instance You cannot choose to run the SVU in this case. It is run by default.

• After a Portal Import on the target Portal instance.

• When errors such as ORA-1403, ORA-1422, and ORA-4088 are seen when using the OracleAS Portal user interface.

For a more detailed explanation of how the validation is performed, and to download the SVU script, svu_rept.sql, log on to Oracle Metalink at http://metalink.oracle.com and read the article Schema Validation Utility. The Doc ID for this article is 286619.1.

There are two ways of running the Schema Validation Utility, which are:

• Using the Schema Validation Utility with OracleAS Portal Export and Import

• Using the Standalone Schema Validation Utility

SQL> @svu_rept.sql