G Troubleshooting Oracle Portal

This appendix describes common problems that you may encounter when using Oracle Portal and explains how to solve them. It also gives detailed instructions on how to diagnose Oracle Portal problems. It contains the following topics:

G.1 Problems and Solutions

This section describes common problems and solutions. It contains the following topics:

G.1.1 Unable to Access Oracle Portal

For example, pages are not displayed, you get an "HTTP 503 Service Unavailable" error, or an "An error occurred while processing the request. Try refreshing your browser. If the problem persists contact the site administrator" error when you try to access Oracle Portal.

Oracle Portal requires Oracle Fusion Middleware components, such as Oracle HTTP Server, Oracle Web Cache, Portal Services, Oracle Metadata Repository, and WLS_PORTAL to be available (up) and running. One or more of these components may be unavailable (down).

Problem 1

Oracle HTTP Server is down.

Solution 1

Display the Oracle Portal home page in Fusion Middleware Control. See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

Check if the Oracle HTTP Server is up. The Oracle HTTP Server status is displayed in the Fusion Middleware pane on the Oracle Fusion Middleware Control home page.

Figure G-1 HTTP Server Status

Description of Figure G-1 follows
Description of "Figure G-1 HTTP Server Status"

  • If the status is 'Up', then continue to the next step.

  • If the status is 'Down', then start Oracle HTTP Server from Fusion Middleware Control.

To start Oracle HTTP Server using Fusion Middleware Control, do the following:

  1. From the Navigation pane, expand Web Tier, and select the Oracle HTTP Server (by default it is ohs1).

  2. Right-click ohs1, and select Control > Start Up to start the Oracle HTTP Server.

If Oracle HTTP Server starts successfully, check whether your portal is accessible.

If Oracle HTTP Server fails to start, use Log Viewer to check the Oracle HTTP Server error log files and try to determine the problem. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information.

If you are not using Log Viewer, then check the relevant error log files in the ORACLE_INSTANCE\diagnostics\logs\OHS\ohs1\access_log and ORACLE_INSTANCE\diagnostics\logs\OHS\ohs1\console~OHS~1.log directories.

Problem 2

Oracle Web Cache is down.

Solution 2

Navigate to the Fusion Middleware Control, of the Oracle Portal that is running the Oracle Web Cache process. For details, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

Check if Oracle Web Cache is up. The Oracle Web Cache status is displayed in the Fusion Middleware System Components table.

  • If the status is 'Up', then continue to the next step.

  • If the status is 'Down', then start Oracle Web Cache using Fusion Middleware Control.

To access Oracle Web Cache monitoring and administration pages in Fusion Middleware Control, click Web Cache in the Fusion Middleware System Components table.

If Oracle Web Cache starts successfully, check whether your portal is now accessible.

If Oracle Web Cache fails to start, then investigate the Oracle Web Cache error log files and try to determine the problem. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information.

If you are not using Log Viewer, then check the relevant error log files in the ORACLE_INSTANCE\diagnostics\logs\WebCache\wc1\access_log and ORACLE_INSTANCE\diagnostics\logs\WebCache\wc1\event_log directories.

Problem 3

Oracle Portal is down due to incorrect Portal DAD configuration.

Solution 3

Check the status and configuration of the Oracle Portal DAD. Navigate to the Oracle Portal home page in Fusion Middleware Control. From the Oracle Portal home page, click Settings > Database Access Descriptor. Check the DADs table in the Configure Database Access Descriptor page to see if the DAD configured for your portal is up.

  • If the status is 'Up', then continue to the next step.

  • If the status is 'Down', then click the name of the DAD in the DADs table and verify that all properties are set correctly. Save any changes and then restart both WLS_PORTAL and Oracle HTTP Server for any change to take effect. See Section 5.6.4, "Configuring a Portal DAD Using Fusion Middleware Control" for information about configuring the DAD from the portal's home page.


Note:

You can verify the database connection details for a DAD using SQL*Plus - in the Oracle home directory associated with the Oracle Fusion Middleware for your portal. The DAD Settings page displays the password in an encrypted form and forces you to reenter the password, to ensure that password validity is not the problem.

Check if your portal is accessible now.

Problem 4

Oracle Metadata Repository is down.

Solution 4

Display the Oracle Portal home page in Oracle Fusion Middleware Control. See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

Look under the Oracle Metadata Repository Used by Portal section.

  • If the status is 'Up', then continue to the next step.

  • If the status is 'Down', then start the database.

If the database starts successfully, check whether your portal is accessible now.

Problem 5

The WLS_PORTAL service is down.

Solution 5

Display the domain home page (for your Oracle Portal instance), in Oracle Fusion Middleware Control. See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

The WLS_PORTAL status is displayed in the System Components table.

  • If the status is 'Up', then continue to the next step.

  • If the status is 'Down', then start WLS_PORTAL using Oracle Fusion Middleware Control.

To access WLS_PORTAL monitoring and administration pages in Oracle Fusion Middleware Control, click WLS_PORTAL in either of the following:

  • Parallel Page Engine Services page (available from the Component Status table on the Oracle Portal home page)

  • Fusion Middleware System Components table

If WLS_PORTAL starts successfully, check whether your portal is now accessible.

If WLS_PORTAL fails to start, then investigate WLS_PORTAL error log files and try to determine the problem. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information.

Problem 6

SQL* Net listener is down, or misconfigured.

Solution 6

Check that the SQL*Net TNS listener is up and running on the host where the metadata repository is installed. Log in to the computer containing the database, change to the ORACLE_INSTANCE/bin directory if you are currently not in the $PATH directory, and use the following command to determine the status of the TNS listener:

lsnrctl status

If the service is not running, then start it by using the following command:

lsnrctl start

If the service is already up and running, then refer to the Oracle Database Net Services Administrator's Guide in the Oracle Database documentation library, for information on how to troubleshoot Oracle Net Services.

Problem 7

Portal Services is reporting some other error.

Solution 7

Perform the following steps to resolve the problem:

  1. Navigate to ORACLE_HOME/opmn/bin and issue the opmctl status command. Ensure that key services show an alive status. If not, scan the files under ORACLE_HOME/opmn/logs for more details.

  2. Navigate to ORACLE_INSTANCE/webcache/logs. Scan the event_log file for any pointers to the problem.

G.1.2 Unable to Log In to Oracle Portal

You can access the public home page but are unable to log in. Common symptoms of this problem are the following:

  • The login page does not appear after you click Login.

  • You get an error after you enter your credentials on the OracleAS Single Sign-On login page.

  • You get errors on Oracle Portal pages after you have been authenticated.

Problem 1

You may not be able to log in to Oracle Portal due to problems encountered during the process of logging in to Oracle Portal.

The Oracle Portal login process can be logically broken down into three parts:

  • Communication between Oracle Portal and OracleAS Single Sign-On

  • Communication between Oracle Portal and Oracle Internet Directory

  • Assignment of the Home Page

Solution 1

To help diagnose the cause of this problem, look at the solutions focused on each part of the login process.

Verify Communication Between Oracle Portal and OracleAS Single Sign-On

To understand the first part of the login process, assume that Oracle Portal is accessed at:

http://www.company.com/portal/pls/portal/

When you click Login on the public home page you get redirected to the OracleAS Single Sign-On page. For example, the URL changes to:

http://login.company.com:4443/pls/sso

If you enter the user name and password provided by your administrator and click Login, then OracleAS Single Sign-On sends the user information back to Oracle Portal.

To diagnose the cause of a problem encountered in this part of the login process, perform the following steps:

  1. Display the OracleAS Single Sign-On home page in the Oracle Enterprise Manager 11g Fusion Middleware Control.

    The OracleAS Single Sign-On home page is available from the home page for the Infrastructure home directory instance.

    For details, refer to the section on Interpreting and Using the Home Page on the Standalone Console in the Oracle Application Server Single Sign-On Administrator's Guide.

  2. Check if Oracle HTTP Server is Up.

    Click HTTP_Server displayed in the Related Links section.

    • If the status is 'Up', then continue to the next step.

    • If the status is 'Down', then start Oracle HTTP Server using Oracle Fusion Middleware Control.

    To access Oracle HTTP Server monitoring and administration pages in Oracle Fusion Middleware Control, click HTTP_Server in either of the following:

    • OracleAS Single Sign-On home page

    • Fusion Middleware System Components table

    If Oracle HTTP Server starts successfully, check whether you can log in now.

    If Oracle HTTP Server fails to start, then investigate the Oracle HTTP Server error log files and try to determine the problem. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information. If you are not using Log Viewer, then check the relevant error log files in the following directory:

    ORACLE_INSTANCE\diagnostics\logs\OHS\ohs1\access.log
    
  3. Check the status and configuration of the OracleAS Single Sign-On DAD.

    From the OracleAS Single Sign-On home page, perform the following steps:

    1. In the Related Links section of the OracleAS Single Sign-On home page, click HTTP_Server.

    2. Click Administration.

    3. Click PL/SQL Properties and review the DADs section:

    • If the status is 'Up', then continue to the next step.

    • If the status is 'Down', then click the name of the DAD in the DAD table and verify that all properties are set correctly. Save any changes and restart Oracle HTTP Server and WLS_PORTAL for any change to take effect.

    Check if you can log in now.

  4. Check if the database containing the OracleAS Single Sign-On schema is running.

    Database information is displayed on the OracleAS Single Sign-On home page in the Oracle Enterprise Manager 11g Fusion Middleware Control. Drill down for further information.

    • If the status is 'Up', then continue to the next step.

    • If the status is 'Down', then start the database.

    If the database starts successfully, check whether your OracleAS Single Sign-On schema is accessible now.

  5. Check the status and configuration of the SQL* Net Listener.

    Check that the SQL*Net TNS listener is up and running on the host where the Identity Management repository is installed. Log in to the computer containing the database. Change to the ORACLE_INSTANCE/bin directory if you are currently not in the $PATH directory, and use the following to determine the status of the TNS listener:

    lsnrctl status
    

    If the service is not running, then start it by using the following:

    lsnrctl start
    

    If the service is already up and running, then refer to the Oracle Database Net Services Administrator's Guide in the Oracle Database 11g documentation library, for the specific error number returned, and then take suitable action.

Verify Communication Between Oracle Portal and Oracle Internet Directory

In the second part of the Oracle Portal login process, the credentials provided by OracleAS Single Sign-On are used by Oracle Portal to get Group membership information from Oracle Internet Directory.

To help diagnose the causes of problems encountered in this part of the login process, check the Metadata Repository log.

Verify Assignment of the Home Page

In the final part of the Oracle Portal login process, you are redirected to the appropriate Oracle Portal home page based on your Group membership. The home page preference can be specified at the System, Group, or User level.

If a home page has been specified for you, then it is displayed when you log in. If no home page has been specified for you, but you belong a default group, and a home page has been specified for your default group, then that page is displayed. If a home page has not been specified for you and you either do not belong to a default group or a home page has not been specified for the default group, then the System level default home page is displayed.

To help diagnose the cause of the problem, check if you have View privileges for the home page, at the User, Group, or System level.

When a home page is being displayed, you must have privilege to view the page. The privilege can be granted to one of the following:

  • User

  • User Group

  • Public

If you do not have privileges to view the page at any of the levels in the preceding list, then you receive the "WWC-44131: You do not have permission to perform this operation" error.

At the Group or the System level, verify with an administrator that the group you are part of has correct privileges to view the page.

A portal administrator must perform the following steps to identify a user home page:

  • Edit the user profile to find out the default home page and the default group for the user.

  • If a default home page is already specified for the user, then stop here. Otherwise, edit the group profile for the default group, and check if a default home page is specified.

  • If a default home page has been specified for the default group, then stop here. Otherwise check the default home page from the Global Settings page.

Once the home page is established, the next step is to find out about the privileges granted on the page. Edit the page, and click Access. Check whether or not the page can be viewed by public. In addition, look at the list of grantees. Check if the user or any group that the user belongs to has been given View or higher privileges on the page. Grant the appropriate privileges if needed. If the privilege has been granted to a group that the user is a member of, then ensure that the name of the user appears in the list of members.

G.1.3 Problems Creating Category or Perspective Pages

When you create category or perspective pages, you may encounter the following errors:

  • WWS-32022:The category has been created but it was not possible to place the search portlets onto the category page. The category page will not show the items or pages in the category.

  • WWS-32023:The perspective has been created but it was not possible to place the search portlets onto the perspective page. The perspective page will not show the items or pages in the perspective.

Problem

When you create a category in a page group, a category page is created based on the category template. Similarly, when you create a perspective, a perspective page is created based on the perspective template. If changes are made to the underlying category or perspective templates, then you may see one of the preceding messages when you create a new category or perspective.

Solution

If either of these errors is displayed, you must first delete the current category or perspective template, and then run scripts to do the following:

  • Replace the current category or perspective template with the original version.

  • Re-create category or perspective pages that are based on the current template. You can do this either across all page groups, or for specific page groups.

This ensures that all new category or perspective pages are created without errors and that all existing category or perspective pages display their associated items and pages as expected.

See Section B.9, "Using the Category and Perspective Scripts" for more information about where to look for and run these scripts.

G.1.4 Problems with Network Address Translation (NAT) Setup

After following the steps in Section 6.3, "Configuring Multiple Middle Tiers with a Load Balancing Router", you encounter the following error:

Timeout occurred while retrieving page metadata

Problem

If a NAT bounceback rule is not correctly set up on the LBR when configuring multiple middle tiers, then the response to loopback requests is deleted, causing Oracle Portal pages to time out.

Solution

NAT bounceback rule is set up differently on individual LBRs. Consult your LBR configuration guide for detailed information. Refer to Section 6.3, "Configuring Multiple Middle Tiers with a Load Balancing Router" for a detailed description on why the LBR needs additional configuration to make loopback communication successful.

G.1.5 User and Group Information in Oracle Portal and Oracle Internet Directory Does Not Match

User and group information in Oracle Portal is not synchronized with the information in Oracle Internet Directory.

Problem

Changes from Oracle Internet Directory are not propagated to Oracle Portal. Oracle Portal uses a provisioning profile to receive notifications when user or group privilege information changes. This enables Oracle Portal to keep its authorization information synchronized with the information stored in Oracle Internet Directory. By default, this provisioning profile is enabled.

Solution

Perform the following steps to help diagnose the cause of this problem:

  1. Check if provisioning is enabled.

    Perform the following steps to check if provisioning is enabled:

    1. Log in to Oracle Portal. Click the Administer tab. On the Portal Builder page, click Global Settings under Services.

    2. Click the SSO/OID tab, and scroll down to the Directory Synchronization section. This section enables you to specify whether or not directory synchronization should be enabled. Enable Directory Synchronization should be selected, and by default, Send event notifications every n seconds must be set to 300.

    3. If the Directory Synchronization section is not visible or the check box for Enable Directory Synchronization is not checked, then the provisioning profile is not enabled. Enable the provisioning profile by selecting the Enable Directory Synchronization, check box and then clicking OK or Apply.

    If you encounter an error, you must re-create the provisioning profile, using oidprovtool tool as shown in the following example:

    oidprovtool operation=create ldap_host=myhost.mycompany.com ldap_port=389 \
    ldap_user_dn="cn=orcladmin" ldap_user_password=welcome1 application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \
    organization_dn="dc=us,dc=mycompany,dc=com" interface_name=PORTAL.WWSEC_OID_SYNC \
    interface_type=PLSQL interface_connect_info=myhost:1521:iasdb:PORTAL:password \
    schedule=360 event_subscription="USER:dc=us,dc=mycompany,dc=com:DELETE" \
    event_subscription="GROUP:dc=us,dc=mycompany,dc=com:DELETE" \
    event_subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY(orclDefaultProfileGroup,userpassword)" \
    event_subscription="GROUP:dc=us,dc=mycompany,dc=com:MODIFY(uniqueMember)" \
    profile_mode=OUTBOUND 
    
  2. Check if Oracle Directory Integration Platform is up and running.

    Perform the following steps to do this:

    1. Display the Oracle Enterprise Manager 11g Fusion Middleware Control. See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information. Navigate to the Oracle Fusion Middleware Control of the Infrastructure home directory associated with your portal.

    2. Oracle Internet Directory status is displayed on the Fusion Middleware page.

      • If the status is 'Up', then continue to the next step.

      • If the status is 'Down', then start Oracle Internet Directory using Oracle Fusion Middleware Control.

      To access the Oracle Internet Directory monitoring and administration pages in Oracle Fusion Middleware Control, click OID in the Fusion Middleware System Components table.

      If Oracle Internet Directory starts successfully, then continue to the next step.

      If Oracle Internet Directory fails to start, then check the Oracle Internet Directory error log files and try to determine the problem. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information.

    3. Check if Oracle Directory Integration Platform is up.

      Click OID in the Fusion Middleware System Components table. On the page that follows, click Directory Integration in the Status section.

      • If the status is 'Up', then continue to the next step.

      • If the status is 'Down', then start the Oracle Directory Integration Platform server using Oracle Enterprise Manager 11g Fusion Middleware Control.


    See Also:


  3. Check the contents of the trace and audit log files.

    When changes are propagated, results are written to trace and audit files. Checking the contents of these files can give you additional information about propagation failures. Perform the following steps to check the contents of these files:

    1. Log in to the computer that has the Oracle Directory Integration Platform server running.

      Typically, the computer that has Oracle Internet Directory installed has the Oracle Directory Integration Platform server.

    2. Check for the trace and audit Log Files.

      Navigate to the ORACLE_INSTANCE/ldap/odi/log/ directory.

      For each provisioning profile, there are two associated files in the log directory: *.trc (trace) and *.aud (audit) log files.

      By default, the trace log file contains entries that are generated every 300 seconds, because the default value of Send event notifications every n seconds is 300. This file contains the log of recent information logged by Oracle Directory Integration Platform and also contains any errors that may have been encountered. The trace log file gets recycled after some time.

      The audit log file contains a history of all the changes that have been propagated to the provisioning profile. The following is an example of a message found in the audit log file:

      Tue Jun 19 17:07:30 GMT 2004  -  Audit Log Start
      -----------------------------------------------------
      Group Exists Check - DN : cn=super_users,cn=ASDB.COMPANY.US.COM,cn=Database 
      Instances,cn=SES,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=co
      mpany,dc=com ,GUID (CE0D473B93B521FAE0340003BA109AC2) - Response : 
      =============Event ID : 2320 - (GROUP_MODIFY)=============
      Source     : orclapplicationcommonname= ASDB.COMPANY.COM,cn=database
       instances,cn=ses,cn=portal,cn=products,cn=oraclecontext
      Time       : 20031209170036z
      Object Name: super_users
      Object GUID: CE0D473B93B521FAE0340003BA109AC2
      Object DN  : cn=super_users,cn= ASDB.COMPANY.COM,cn=Database 
      Instances,cn=ses,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=co
      mpany,dc=com
      AttrName     -      OpType     -     Value
      -------------------------------------------
      uniquemember    -     ADD    -    
       cn=portal,cn=users,dc=us,dc=company,dc=com
      EVENT_NTFY Response : 1
      2320 : Success : 2 : cn=super_users,cn= ASDB.COMPANY.COM,cn=Database 
      Instances,cn=ses,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=co
      mpany,dc=com
      -----------------------------------------------------
      

    The propagation information gets written to the trace log files, and is periodically added to the audit log files. If changes are propagated properly, then the time stamp in the trace log file will be updated:

    • If changes are propagated properly, but are not reflected in Oracle Portal, then continue to the "Are Changes Propagated Properly?" section.

    • If you do not find the trace and audit log files, then check if a provisioning profile exists by performing the following steps:

    1. Log in to Oracle Portal. Click the Administer tab. On the Portal Builder page, click Global Settings under Services.

    2. Click the SSO/OID tab and scroll down to the Directory Synchronization section. This section lets you indicate whether or not directory synchronization is enabled. Enable Directory Synchronization must be selected, and Send event notifications every [ ] seconds must be set to 300 by default.

    3. If these values are not set, then you must create a provisioning profile as detailed in the following section.

    If you do not find the trace and audit log files in the ORACLE_INSTANCE/ldap/odi/log/ directory, then chances are that the provisioning profile has been deleted. To re-create a provisioning profile, run the oidprovtool tool as shown in the example below:

    ldap_user_dn="cn=orcladmin" ldap_user_password=welcome1 application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \
    organization_dn="dc=us,dc=mycompany,dc=com" interface_name=PORTAL.WWSEC_OID_SYNC \
    interface_type=PLSQL interface_connect_info=myhost:1521:iasdb:PORTAL:password \
    schedule=360 event_subscription="USER:dc=us,dc=mycompany,dc=com:DELETE" \
    event_subscription="GROUP:dc=us,dc=mycompany,dc=com:DELETE" \
    event_subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY(orclDefaultProfileGroup,userpassword)" \
    event_subscription="GROUP:dc=us,dc=mycompany,dc=com:MODIFY(uniqueMember)" \
    profile_mode=OUTBOUND 
    

    Are Changes Propagated Properly?

    To help diagnose whether or not changes are propagated properly, create, delete, and re-create a user through Oracle Portal (in Oracle Internet Directory). To do this, perform the following steps:

    1. Click the Administer tab.

    2. Under User, click Create New Users.

    3. Edit the profile of the user.

    4. Delete the user.

    5. Re-create the user with the same name.

    Wait for the interval period (the time specified for Send event notification of messages). To minimize your wait time, you can reset this value to less than 300 seconds. After this, log in as the newly created user. If you receive the following error while logging in, then information is not propagating from Oracle Internet Directory to Oracle Portal:

    Error "WWC-41742: There is a conflict with your assigned user name. There is a user entry with this name, but with a different globally unique identifier (GUID), which must be resolved before you can log on with this name. Please inform your administrator."

    If no information is propagated, then Oracle Portal throws this error, because it has the same user name stored with a different GUID.

    If changes are not propagated properly, then it is likely that there is a problem in either Oracle Directory Integration Platform or in the configuration of Oracle Portal with Oracle Directory Integration Platform. If this is an Oracle Portal configuration problem, then run the ptlconfig tool as follows:

    ptlconfig -dad <dad> -dipreg
    

G.1.6 Problems with Oracle Portal Performance

You may experience performance issues with Oracle Portal for example, pages may load slowly.

There could be multiple reasons why your portal is slow. Some of these problems are described here.

Problem 1

Caching is disabled.

Solution 1

Problem 2

Page metadata is not cached in Oracle Web Cache. The initial, one-time call from the middle tier to the Oracle Portal schema to determine the Oracle Portal version may have failed.

Solution 2

To resolve this problem, perform the following tasks:

  1. Confirm that page metadata is not cached in Oracle Web Cache. To do this, perform the following step:

    • Append a page URL with &_debug=1, refresh the browser, and verify that the Oracle Web Cache page metadata cache status is MISS, NON-CACHEABLE.

  2. Restart all WLS_PORTAL instances.

  3. Perform Step 1 again to determine if page metadata is now cached in Oracle Web Cache.

Problem 3

Low or no reuse of connection pool.

Solution 3

Set the MaxRequestsPerSession parameter to 1000 Oracle Fusion Middleware Control MBean Browser


Note:

Ensure that the MaxRequestsPerSession attribute is not set to 1. Doing this disables connection pooling. For information about the MaxRequestsPerSession attribute, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.

To change the MaxRequestsPerSession attribute:

  1. Navigate to the Fusion Middleware Control instance for the appropriate farm.

    See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

  2. From the Farm menu, select Administration > System MBean Browser.

  3. Locate the PlsqlMaxRequestsPerSession MBeans attribute using the Search function, or use the Navigation pane and open Mbeans > oracle.mas.config > PortalConfig > pls/portal.

  4. On the Attributes tab, scroll down and click on the PlsqlMaxRequestsPerSession attribute.

  5. Reset the attribute value to 1000 and click OK.

  6. Restart the Oracle HTTP Server and WLS_PORTAL.

    Refer to Section 5.6.3, "Stopping and Starting Portal Components Using Fusion Middleware Control" for information on restarting the Oracle HTTP Server and WLS_PORTAL components.

Problem 4

Site is not responding.

Solution 4

Check the WebCache and OHS logs diagnostic messages to see if there is a need to tune the configuration of these Oracle components.

Oracle Fusion Middleware Control MBean Browser

To change the attribute:

  1. Navigate to the Fusion Middleware Control instance for the appropriate farm.

    See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

  2. From the Farm menu, select Administration > System MBean Browser.

  3. Locate the MBeans attribute using the Search function, or use the Navigation pane and open Mbeans > oracle.mas.config > PortalConfig > Global.

  4. On the Attributes tab, scroll down and click on the attribute.

  5. Reset the attribute value and click OK.

  6. Restart the Oracle HTTP Server and WLS_PORTAL.

    Refer to Section 5.6.3, "Stopping and Starting Portal Components Using Fusion Middleware Control" for information on restarting the Oracle HTTP Server and WLS_PORTAL components.

Problem 6

Disk input or output not distributed.

Solution 6

Many components, such as the following, access disks all the time:

  • Oracle HTTP Server access and error logs

  • Portal cached content

  • Web content service

  • Other local applications

All these components compete for the resources of the file system. To reduce input or output bottlenecks, ensure that you have a good distribution across physical disks.

Problem 7

Too many network hops. Typical problems can be any of the following:

  • PPE loopbacks are not configured on clustered Oracle HTTP Server environments.

  • Servlet engines run on a computer other than Oracle HTTP Server or mod_weblogic.

  • Infrastructure components run across wide networks with multiple routers.

Solution 7

Try to reduce the number of network hops by avoiding or working around the listed problems.

Problem 8

Use of the HTTPS protocol for serving content.

You may have configured your portal to use HTTPS for ordinary content that does not need to be secure.

Solution 8

Avoid the unnecessary use of HTTPS. HTTP works well in most cases. If you really need a secure environment, then use reverse proxy hardware that will manage HTTPS and Secure Socket Layer (SSL). See Section 6.6, "Configuring Oracle Portal to Work with a Reverse Proxy Server" for more information.

Problem 9

After performing all the tasks in the solutions provided, Oracle Portal is still slow.

Solution 9

  • Review metric information for Oracle Portal, its host, and other relevant components.

    If all the components required by Oracle Portal are up and running as expected, then the next step is to review metric information in Oracle Fusion Middleware Control. Reviewing this information can help you identify the problem.

    Click All Metrics in the portal home page to review metric information. Repeat this on home pages for other relevant components (Oracle Web Cache, Oracle HTTP Server, and so on).

  • Run Oracle Portal Diagnostics Assistant.

    You can diagnose portal-related issues by reviewing the report generated by using Oracle Portal Diagnostics Assistant. See Section G.2.5, "Using Oracle Portal Diagnostics Assistant" for more information.

More on OTN

Note:

The Performance Monitoring Scripts zip file is also available as part of the Oracle Fusion Middleware installation.

G.1.7 Error When Creating Web Folders

When you try to create Web folders in Oracle Portal, you get an ORA-20504 error, in the Web server error log file.

Problem

The wwdav$path and wwdav$asl tables are corrupt.

Solution

To repopulate the tables, you have to run the DAV Loader (wwdav_loader) utility. You can run the DAV Loader utility by executing the following procedure from SQL*Plus:

set serveroutput on size 1000000
begin
    wwdav_loader.create_dav_content;
end;

This re-creates all the DAV data. To get more debugging information, you can also use:

set serveroutput on size 1000000
begin
    wwdav_loader.create_dav_content(
        p_debug_mode => true);
end;

Running the DAV Loader removes any temporary documents, and any locks on documents, from the DAV tables. Items submitted for approval no longer appear in the DAV Loader until they are accepted or rejected.

In future, to examine whether there are any data corruptions in the DAV schema, you can run the DAV Report utility. To run this utility, perform the following steps:

  1. Change the directory to ORACLE_HOME//portal/admin/plsql/wwu/, where the davreprt.sql file resides.

  2. Log in to SQL*Plus as the PORTAL schema user.

  3. Run the DAV Report Utility as follows:

    davreprt.sql
    

This will run through a series of tests. If all tests pass, then no known data corruptions can be found in the DAV schema. If any test fails, then the DAV Loader must be run to correct the data corruption.

G.1.8 Create New Users and Create New Groups Portlets Do Not Appear

The Create New Users and Create New Groups portlets are displayed based on user privileges. The portlets may not appear for a variety of reasons.

Problem 1

You do not have sufficient privileges.

Solution 1

Use the Delegated Administration Service Self-Service Console to verify if you can administer users and groups. If you do not have the required privileges, then request the administrator to grant you the required privileges. However, if you can successfully perform these operations from the Self-Service Console, then it is most likely related to the next two problems. Inform the administrator about the issue.

Problem 2

Oracle Internet Directory is down or the group information in Oracle Internet Directory is incorrect.

Solution 2

If the Group membership information in Oracle Internet Directory is incorrect or if Oracle Internet Directory is not up and running, then perform the following steps to help diagnose the cause of this problem:

  1. Display the portal home page in Oracle Enterprise Manager 11g Fusion Middleware Control. See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information. Navigate to Oracle Fusion Middleware Control Console of the Infrastructure home directory associated with your portal.

    Check if Oracle Internet Directory is up. Oracle Internet Directory status is displayed in the Fusion Middleware page.

    • If the status is 'Up', then continue to the next step.

    • If the status is 'Down', then start Oracle Internet Directory using Oracle Fusion Middleware Control Console or the command line.

      To access Oracle Internet Directory monitoring and administration pages in Oracle Fusion Middleware Control Console, click Oracle Internet Directory in the Fusion Middleware System Components table.

      If Oracle Internet Directory starts successfully, then check if the Create New Users and Create New Groups portlets are displayed.

      If Oracle Internet Directory fails to start, then investigate Oracle Internet Directory error log files and try to determine the problem. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information.

Problem 3

Oracle Portal and Oracle Internet Directory connection configuration is incorrect.

Solution 3

Login to Enterprise Manager and ensure that you have entered the correct OID parameters in the Portal Wire Configuration page.

G.1.9 ORA-2000x Errors in the error_log File

When you attempt to log in to Oracle Portal, you see one of the following errors in the diagnostics log file located in the ORACLE_INSTANCE/diagnostics/logs/OHSComponent/ohs1 directory:

  • ORA-20000: "An attempt was made to access the session context without a valid session"

    This error denotes that the Oracle Portal session associated with that particular browser session is broken or lost, or that the session cookie itself is missing.

  • ORA-20001: "The session cookie is corrupt - unable to obtain session information. Please close your browser and reconnect."

    This error indicates a corrupt or otherwise invalid session cookie.

  • ORA-20005: "The session context could not be restored because the session is marked as inactive"

    This error is raised when the session cookie points to an inactive session. The cookie sent by the browser matches the cookie stored in the session, but the session is not active.

  • ORA-20006: "The session context could not be restored because the cookie value does not match the value stored in the session repository"

    This error indicates that there is a mismatch between the cookie sent by the browser and the cookie stored in the session.


Note:

It is important to understand that some of these errors are expected. Report the problem to Oracle Support Services only if an unusual number of exceptions is encountered. See Section G.3, "Need More Help?"for more information.

These errors are discussed in detail in the following subsections.

ORA-20000 "An attempt was made to access the session context without a valid session"

This error can be caused by any of the following problems:

Session Row Is Missing

Each session cookie has a corresponding session stored in the portal schema that contains information about the session cookie corresponding session. The data stored in the session includes the session ID, user name, session start time, information about whether the user is logged on or not, what time the user logged on, whether the session is active or marked for cleanup. The ORA-20000 error is raised if the session ID specified in the cookie does not exist in the sessions stored in the portal schema in the Oracle Metadata Repository.

Session Is Cleaned Up

A background job runs frequently to clean up old sessions from the portal schema in the Oracle Metadata Repository. By default, this job is configured to clean up sessions that are older than seven days. An attempt to access a session that has been cleaned up by the background job will result in an ORA-20000 error. See Section B.5, "Managing the Session Cleanup Job" for details.

Session Cookie Is Missing

If more than one DAD is configured for use with the portal schema in an Oracle Metadata Repository, and the cookie name specified in these DADs is not the same, then it will result in the cookie_name value in the wwctx_cookie_info$ table switching values every time a new session creation request is received through one of the DADs. This will result in an ORA-20000 error.

ORA-20001 "The session cookie is corrupt - unable to obtain session information. Please close your browser and reconnect."

The ORA-20001 error can be caused by any of the following problems:

Cookie Is Truncated

If you click Stop on the browser during the transmission of a request, then the cookie may be truncated. The next time you access the browser, the server is unable to properly decrypt the cookie.

Cookie from Another Server Is Received

If you have recently accessed another Oracle Portal that is configured with a domainwide cookie scope, then an ORA-20001 error may be raised. If the cookie name of that portal is the same as your portal cookie name, then Oracle Portal tries to use that cookie. However, because each portal cookie is encrypted using portal-specific keys, Oracle Portal will not be able to decrypt the cookie, and will raise an ORA-20001 error assuming that the cookie is corrupted.

To avoid this namespace collision issue, you must determine the source of these cookies. Closing the browser will clear all the session cookies. You can debug the problem by starting up the browser with cookie warnings turned on, to see where the cookies are obtained from.

Cookie Encryption Key Is Changed

The cookies are encrypted using DES3 encryption. The encryption key is stored in the portal schema in the Oracle Metadata Repository. Its value is typically set during Oracle Portal installation and does not change thereafter. If this value is changed after installation, then it is not possible to decrypt any of the outstanding session cookies. Also, any other values that have been encrypted with this key cannot be decrypted. Note that this value should not be changed.

ORA-20005 "The session context could not be restored because the session is marked as inactive."

The ORA-20005 error results when the session cookie points to an inactive session. The cookie sent by the browser matches the cookie stored in the session, but the session is not active. It indicates that you made a logout request, but another request (for example, a user makes a request to change the language from the Language portlet) was sent before the cookie was reset in the browser.

Session Is Marked Inactive

When the user logs out, it is possible that the session stored in the portal schema gets updated to an inactive state. However, if you click Stop in the browser, then the cookie does not get cleared from the users browser. If this happens, then the browser sends the old cookie, causing Oracle Portal to try to locate the inactive session. When this happens, an ORA-20000 error is raised.

ORA-20006 "The session context could not be restored because the cookie value does not match the value stored in the session repository."

The ORA-20006 error indicates that there is a mismatch between the cookie sent by the browser and the cookie that is stored in the session. This could happen if the cookie changes based on one request, and the user sends another request before the cookie is actually updated in the browser. For example, the user makes a request to change the language from the Language portlet, but sends another request before the first request is complete. This is similar to the ORA-20005 error, with the difference that the cookie itself contains a mismatch between the client and the server.

Time Stamp Does Not Match

The cookie may be decrypted properly, but if the time stamp in the cookie does not match the time stamp in the associated session row, it is considered to be corrupt. This mismatch in time stamp may occur if the user invokes the login twice, if there are network configuration issues, or bugs in the session creation logic, or because of a malicious session attack.

G.1.10 Remote Web Providers Time Out in a Dynamic DNS Environment

A remote Web provider that is located on a computer different from the Oracle Portal middle tier, works when the WLS_PORTAL service is first started, but stops working after some time. After a long timeout interval, the Error: the portlet could not be contacted message is shown in the place of each portlet from the same provider. Portlet timeout interval errors are also found in the WLS_PORTAL WLS_PORTAL-diagnostic.log file. After restarting WLS_PORTAL, the Web provider works again, but only for a limited period of time.

Problem

The possible cause for this problem can be that the Web provider is using dynamic DNS (DDNS) for its Domain Name to IP Address mapping. This means that the IP address that the Web provider domain name resolves to changes over time. Java default caching policy caches IP addresses forever, once it has resolved them. This means the Java cache stores an outdated IP address of the Web provider if the IP address of the Web provider changes, because of DDNS.

Solution

To resolve this problem, you need to perform additional configuration in WLS_PORTAL to prevent remote Web providers from timing out. You must change the sun.net.inetaddr.ttl system property for WLS_PORTAL. On JDK 1.3 and later, you can use the sun.net.inetaddr.ttl system property to specify the "time to live" (TTL) in seconds for cached IP addresses.

Example

  1. Edit the opmn.xml file as follows:

    <java-option value="-server -Xincgc -Xnoclassgc -Xms256m -Xmx512m -Dsun.net.inetaddr.ttl=120"/>
    
  2. Shut down opmn and all its subprocesses, and restart it for the latest configuration changes to take effect.

    To do this, run the following commands:

    ORACLE_INSTANCE/opmn/bin/opmnctl stopall
    ORACLE_INSTANCE/opmn/bin/opmnctl startall
    

G.1.11 Problems Related to Memory-Intense Operations

You see the error "ORA-04031: unable to allocate 30192 bytes of shared memory."

Problem

By default, the shared_pool_size value in Oracle Fusion Middleware is 32 megabytes. This can cause problems if you are performing memory-intense operations such as the following:

  • Export or Import

  • Creating Portal Forms or Reports

Solution

To facilitate memory-intense operations, you must increase the value of the shared_pool_size parameter.

If you are unfamiliar with the steps involved in updating a database initialization parameter, refer to the section, "Managing Initialization Parameters Using a Server Parameter File", in the Oracle Database Administrator's Guide in the Oracle Database 11g documentation library.


Note:

As an optional step, it is suggested that you run Oracle Portal Diagnostics Assistant to view a report of the existing and recommended values of the database. See "Running Oracle Portal Diagnostics Assistant" for details.

G.1.12 Unable to Create Oracle Text Indexes

When trying to create Oracle Text indexes, you may encounter the following errors:

  • "Cannot grant CTXAPP role to portal"

  • "ERROR: Creating data store procedures in CTXSYS"

  • "ERROR: Setting up Oracle Text data stores"

  • "An unexpected error has occurred (WWS-32100)"

Problem

You face problems when trying to create Oracle Text indexes.

Solution

Oracle Text must be installed in the same Oracle Database home directory as the portal schema. See Section 9.3.2, "Oracle Text Prerequisites" for details.

Choose one of the following options to resolve this issue:

  • Access the database and log in as the Oracle Portal schema owner. Start SQL*Plus and run the inctxgrn.sql script. This script is located in the ORACLE_HOME\portal\admin\plsql\wws directory. Running this script creates the Oracle Text data store procedures and also grants the CTXAPP role to the Oracle Portal schema.

  • If you have access to the database, but you do not have a copy of the inctxgrn.sql script, use SQL*Plus to connect to the database as the schema owner and run the following commands:

    set serveroutput on size 10000
    begin
       wwv_context_util.grantCtxRole(user);
    end;
    @@sbrimtlx
    

    Replace (user) with the Oracle Portal schema owner, for example, portal.

G.1.13 Problems with MultiLanguage Support for Help

Only a subset of the online Help appears to be translated in Oracle Portal.

Problem

In Oracle Portal, there is multi-language support for the online Help. However, only a subset of the context-sensitive Help topics is translated for languages other than Japanese.

Solution

This is expected activity.

G.1.14 Stale Style-Sheet Data Is Displayed on Portal Pages

When editing style sheets, you see stale style-sheet data when previewing or viewing the style sheet in the context of a portal page.

Problem

Changes to style sheets are not reflected on portal pages. This is because the Greenwich Meridian Time (GMT) is appended to the numeric value, which generates the Last-Modified header without correcting the time zone. If the time zone of the original server precedes GMT, then the generated Last-Modified header is actually a future date.

Solution

Perform the diagnostic steps described in the Oracle Application Server Portal Error Messages Guide for the following errors:

WWC-40018: General invalidation message processing exception: %1
WWC-40019: Could not open web cache connection

If the problem is not resolved by these steps, then verify that the date, time, and time zone have been set to the current values on the Oracle Web Cache hosts and the database host. Also, verify that the database time zone has been set to match the database host time zone. The database time zone can be determined by executing the following query:

SQL> SELECT DBTIMEZONE FROM DUAL;

If the database time zone differs from the database host time zone, then set the database time zone to the database host time zone using the ALTER DATABASE SET TIME_ZONE command, and then restart the database.

For example:

SQL> ALTER DATABASE SET TIME_ZONE = '-05:00';

The change will not take effect until the database is restarted.

G.1.15 Stale Content Is Displayed on Portal Pages

The content on your portal pages is not getting refreshed and stale content is displayed.

Problem

Your browser cache settings may be incorrect.

Solution

Ensure that the browser cache setting is not set to Never.

To verify this setting, refer to the "Browser Recommendations" section in the Preface of the Oracle Fusion Middleware User's Guide for Oracle Portal.

G.1.16 Images Are Not Displayed on Portal Pages

When using Oracle Portal, you may face either of the following problems:

  • Images are not displayed.

  • After logging out of portal, you cannot log in unless you close the browser and open it again.

Problem

Your browser image settings may be incorrect.

Solution

Ensure that images are automatically loaded. To verify this setting, refer to the "Browser Recommendations" section in the Preface of the Oracle Fusion Middleware User's Guide for Oracle Portal.


Note:

It is recommended that this setting is always enabled.

G.1.17 Unhandled Exception Errors

When accessing or using Oracle Portal, you may encounter an unhandled exception error. For example, "Error 30526: An Unhandled Exception has occurred."

Problem

Oracle Portal encounters a database error from which it cannot recover.

Solution

In case of unhandled exception errors, the actual cause of the error is not clear. To gather more information about the possible cause of the error, generate a trace file.

After you have turned tracing on, you can find the generated trace files in the directory specified in the database parameter user_dump_dest. To find out the name of the directory, use either of the following commands:

select value from v$parameter where name = 'user_dump_dest';

show parameter user_dump_dest;

Refer to Section G.2.2, "Generating Trace Files" for the procedure to generate trace files. These trace files are not formatted. Use the tkprof utility to format them.

G.1.18 Problems in Configuring the OmniPortlet Provider

When configuring the OmniPortlet provider to build portlets, you may encounter a number of problems. To resolve many of the problems, you may need to view the OmniPortlet provider application log file, WLS_Portal.log. This log file is available at the following location:

MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\logs

Problem

The required SSL library is not in the library path.

If you installed the OracleAS PDK on a Portal instance, you may encounter the following error:

"java.lang.NoClassDefFoundError: at oracle.security.ssl.OracleSSLCipherSuite.isSSLLibDomestic when accessing HTTPS site with certificate"

Solution

Ensure that the SSL library is in the library path. Refer to "Copying the Library for HTTPS Access (PDK Only)" for more information.

G.1.19 Problems in Configuring Oracle Web Cache for the OmniPortlet Provider

Stale portlet content displays on the portal page, and it does not reflect the portlet definition. This problem may occur because of the following errors in Oracle Web Cache configuration:

Problem 1

The port value is not specified properly in the cache.xml file. You may encounter the following error:

CONFIGURATION: Encountered a Cache Invalidation Exception.
oracle.net.http.HttpConfigurationException: Bad "port" value in configuration element "invalidation"

Solution 1

Set the correct port number in the cache.xml file.

A template copy of the cache.xml file can be found in the ORACLE_INSTANCE/portal/conf directory. To specify the port, modify the configuration file as indicated by the italicized entry in the following example:

<?xml version="1.0"?>
<webcache>
    <invalidation
        host="cache.us.oracle.com"
        port="4001"
authorization="0510198d5df8efd5779406342be2528aa0cccb179ea6b77baf49f019f5075a3a11"/>
</webcache>

Problem 2

The authorization value is not encrypted in the cache.xml file. You may encounter the following error:

CONFIGURATION: Encountered a Cache Invalidation Exception.
oracle.net.http.HttpConfigurationException: Bad "authorization" value in configuration element "invalidation." String un-obfuscation error

Solution 2

Information about the Oracle Web Cache instance is maintained in the cache.xml file in the ORACLE_INSTANCE/portal/conf directory. If the Web Cache invalidation settings change, then you must update this file. Refer to Section E.2.1.3, "Configuring Caching (PDK Only)" for more information.

Problem 3

The oracle.http.configfile system property is not defined. This means that the configuration file for Web Cache Invalidation is not defined. You may encounter the following error when you start the WLS_Portal instance:

Error: CONFIGURATION: Provider Test Page: Web Cache Invalidation config file not defined by "oracle.http.configfile"

G.1.20 Problems in Accessing Oracle Portal from a Mobile Device

Mobile devices do not provide good interfaces for displaying detailed error information when compared with standard desktop browsers. Because of this, a lot of error information is logged in the Oracle Application Server Wireless log file. You can access this log file using a Web-based monitoring tool known as the Activity Logger. Refer to the Oracle Application Server Wireless Administrator's Guide for details about using the Activity Logger.

When you access Oracle Portal through OracleAS Wireless, you may encounter either of the following errors:

  • Service Error

  • Temporary Error

Service Error

A service error is generated by the OracleAS Wireless server when the wireless server has a problem accessing the back-end server. A service error is displayed as follows:

Service Error

A service error may be generated for any of the following reasons:

  • A document that is not of text or vnd.oracle.mobilexml type has been returned to the OracleAS Wireless server.

  • A document of text or vnd.oracle.mobilexml type has been returned to the OracleAS Wireless server, but the content is not valid XML.

  • A document of text or vnd.oracle.mobilexml type has been returned to the OracleAS Wireless server, but the content is not valid OracleAS Wireless XML.

  • An error status has been returned to the OracleAS Wireless server, but there is no attached document that can be returned to the user.

Temporary Error

A temporary error is a message generated by Parallel Page Engine (PPE) if there is a problem in rendering error documents for a mobile device. A temporary error is displayed as follows:

A temporary error has prevented Oracle Portal from servicing your request. (id=<nnnnn>)

The value <nnnn> is the log error ID.

When rendering error documents for standard desktop browsers, PPE takes the error document that resulted from the metadata call to the database, and passes it to the user. This cannot be done for mobile devices because the documents rendered for mobile requests must be in OracleAS Wireless XML.

If PPE is servicing a mobile request and the database renders an error document that is not valid OracleAS Wireless XML, then PPE performs the following tasks:

  1. Writes the document into the servlet error log file, MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\logs directory.

  2. Assigns a unique ID to the error.

  3. Passes a standard error template to the user in the following format:

    A temporary error has prevented Oracle Portal from servicing your request. (id=<nnnnn>)
    

    where <nnnn> is the log error ID.

Problems and Workarounds for Service and Temporary Errors

The different problems and workarounds for service errors and temporary errors are discussed in the following subsections.


Note:

After performing a suggested workaround, clear the cache, close the browser, and open it again. This must be done because the error page may be cached and you may encounter the service error again when you try to access the back-end service.

Problem 1

Oracle Application Server is not configured correctly. You encounter a service error.

Solution 1

Verify the Oracle Portal and OracleAS Wireless configurations in Oracle Application Server. For details about verifying these settings, refer to the Oracle Fusion Middleware Administrator's Guide.

Problem 2

You are not authenticated to access Oracle Portal from a mobile device or simulator. This could be because the comparison of IP addresses failed when validating the session cookie during logon. You encounter a service error.

Solution 2

Change the state of IP checking in cookie validation. Refer to Section B.2, "Configuring for IP Check During Session Cookie Validation" for details.

Access Oracle Portal from a mobile device or simulator and check if you still get a service error.

Problem 3

The xml.validation.mode parameter is set to True. If this parameter is set to True, then OracleAS Wireless tries to validate the error message file, which is not in valid XML format. You encounter a service error.

Solution 3

In the OracleAS Wireless instance, ensure that the xml.validation.mode parameter is set to False in the web.xml file located at:

ORACLE_HOME/j2ee/OC4J_Wireless/applications/wdk/wdk-web/WEB-INF

Access Oracle Portal from a mobile device or simulator and check if you still get a service error.

Problem 4

There are changes in OracleAS Wireless actions. You encounter a service error.

Solution 4

Check if any service can be run on the OracleAS Wireless server. For example, check if you can run OracleAS Wireless examples from a mobile device or simulator. For details, refer to the Oracle Application Server Wireless Administrator's Guide.

  • If the example services do not work, then you may have to install and configure OracleAS Wireless again. For details, refer to OracleAS Wireless documentation.

  • If the example services work properly, then check the OracleAS Wireless server log file for troubleshooting information. The log file stores information about the response from the portal service that is causing problems. Using this information, you can check if portal is returning an error status or invalid OracleAS Wireless XML.

Access the OracleAS Wireless server log file by clicking View Log at the bottom of the OracleAS Wireless Activity Logger. The last 500 lines in the log file are displayed. The wireless server log file is available in the ORACLE_INSTANCE/wireless/logs/ directory or the /var/tmp/ directory.

Based on the information in the log file, perform corrective steps or contact Oracle Support Services.


Note:

You can change the number of lines displayed while viewing the log file, but if you are searching for specific information in a large log file, then it is recommended to view the file using an operating system command, for example, vi, emacs, or more.

Problem 5

There is an error in retrieving metadata. You encounter a temporary error.

Solution 5

Access the servlet error log file, WLS_PORTAL-diagnostic.log, from the MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\logs directory to view troubleshooting information. The servlet error log file records the original error document and its headers, and therefore contains as much information as is available to a standard desktop browser when there is a problem. Use the information in the error log file to perform standard Oracle Portal troubleshooting analysis.

Problem 6

When clicking the login link in the mobile browser, you encounter a service error.

Solution 6

Ensure that the AS Wireless patch and Oracle SSO patch have been applied as described in section 5.7.1 and 5.7.2.

G.1.21 Error During Export and Import After Upgrading from Oracle Portal 3.0.9 or 9.0.4

If you run the Oracle Portal Export and Import, after upgrading from Oracle Portal 3.0.9 or 9.0.4, you may encounter unexpected errors.

Problem 1

If your transport set includes categories or perspectives, the error may be due to category and perspective templates with incorrect page type IDs; that is, the page type ID is 1 instead of 11.

Solution 1

Check your transport set. If categories or perspectives are included, you can fix this issue by running the following script before running the Oracle Portal Export and Import utility:

SQL> @pstpgcre.sql

This script is located at ORACLE_INSTANCE/portal/admin/plsql/wws/pstpgcre.sql. This script drops and re-creates the category and perspective templates and their associated pages.

Refer to Section B.9, "Using the Category and Perspective Scripts" for information on how to use the category and perspective scripts.

Problem 2

When you upgrade from Oracle Portal 3.0.9, category and perspective names are appended with pageid and siteid and this impacts export and import between portals. For example, if you upgrade a category named GENERAL from version 3.0.9 to version 9.0.4, and then upgrade to version 11.1.1, the name of the upgraded category may be GENERAL_12345_0, where 12345 is the pageid and 0 is the siteid.

When you export and import between portals, search portlets that are customized to search for categories or perspectives will lose the category and perspective search criteria, if the source and target portals have different names for the same categories and perspectives.

Solution 2

Ensure that category and perspective names in the source and target portals are exactly the same. For example:

  • Change category and perspective names to pre-upgrade names by removing the ID that is appended to the name. For example, change GENERAL_12345_0 back to GENERAL.

  • Alternatively, specify new category and perspective names. If there is an existing category or perspective with the name you specify, then you are prompted for a different name.


Note:

Make the same changes in the both the source and target portals.

G.1.22 Errors Displayed When the Oracle Portal Language is Traditional Chinese

When the portal language is set to Traditional Chinese you may see errors while working with portlets, such as the Custom Search portlet, or when using the Navigator.

Problem

Errors while working with portlets can occur if the SHARED_POOL_SIZE of the Oracle Metadata Repository database is set too low.

Solution

As a workaround, increase the SHARED_POOL_SIZE of the Oracle Metadata Repository database. Although the recommended minimum size is 144Mb,this is too low for the Traditional Chinese language. Try increasing the SHARED_POOL_SIZE to 216MB, or higher.

G.1.23 Uploaded Content Is Not Returned in Search

If you have uploaded portal content, and it is not being returned using Oracle Text search in Oracle Portal, it may be due to content not being properly indexed before being made searchable.

Problem

Content has been uploaded to portal, but is not returned when searched.

Solution

Make sure the uploaded content was indexed correctly therefore making it searchable. For example, if a document is not indexed correctly due to the filter, then the tokens will not be in the index, and the terms inside the document will not be searchable as they will not match any tokens in the index.

To ensure content is indexed correctly and is therefore searchable, add the Mimetype and Character set attributes to the file- and url- item types (or create new file- url- item types and add these attributes) and specify the MIME type and character set when uploading content.

G.2 Diagnosing Oracle Portal Problems

Oracle Portal consists of middle and database tiers, each of which consists of numerous components. Components can be distributed across many computers, and they can also simultaneously handle a large number of requests.

You can also use diagnostic tools on Oracle Portal to analyze and resolve issues about how Oracle Portal works.

This section contains the following topics:

G.2.1 Enabling ECID Logging

To facilitate problem diagnosis, components can record information related to the requests they receive in log files. This section details how to configure and use various log files to diagnose problems, and how an individual request can be traced from start to finish by using the Execution Context Identifier (ECID).

Execution Context Identifier

Because Oracle Portal can satisfy a large number of requests simultaneously, tracing a single request through the various Oracle Portal components can be difficult because the information relating to these requests is intermingled.

Oracle Portal makes use of an ECID, which is a unique number that is assigned to a request and attached to the information recorded for that request. As a request is passed from one component to another, the ECID can be incremented to form a sequence. This means that an individual request can be tracked through any number of components by following this ECID sequence.

An ECID is generated by the first Oracle Fusion Middleware component to receive a request without an ECID. You can observe this generation and propagation in Figure G-2, where a dotted arrow depicts a request with an ECID.

Figure G-2 Request Flow with ECID Generation and Propagation

Description of Figure G-2 follows
Description of "Figure G-2 Request Flow with ECID Generation and Propagation"

ECID generation is available in Oracle Web Cache, Oracle HTTP Server, and the Parallel Page Engine (PPE). An ECID is generated only if it does not already exist. In this release, logging of portal invalidations in Oracle Web Cache now includes the ECID of the original request. This can be used to relate invalidations to original edits or personalizations.


See Also:

For more information about ECIDs and how they can help you to correlate messages from Oracle Fusion Middleware components, refer to the Oracle Fusion Middleware Administrator's Guide.

G.2.2 Generating Trace Files

When an internal error is detected by a process, information about the error can be written to a trace file. This information is useful in analyzing unhandled exception errors. Refer to Section G.1.17, "Unhandled Exception Errors" for more information.

You can generate a trace file for the sessions in a database instance by using any of the following methods:

G.2.2.1 Using PlsqlBeforeProcedure and PlsqlAfterProcedure

You can enable SQL tracing for a particular session in a database instance by creating a new DAD and setting values for the procedures, PlsqlBeforeProcedure and PlsqlAfterProcedure.


Note:

You can set values for PlsqlBeforeProcedure and PlsqlAfterProcedure in the original DAD, but this can affect other users. Therefore, it is recommended to create a new DAD.

To enable tracing, perform the following steps:

  1. Run the utltrace.sql script in the portal schema. The default portal schema name is portal.


    Note:

    The script utltrace.sql is available in the ORACLE_INSTANCE/portal/admin/plsql/wwc directory on the Oracle Fusion Middleware Repository Creation Assistant CD-ROM. This CD-ROM is part of the Oracle Fusion Middleware CD-ROM Pack from which you installed Oracle Portal.

    For Oracle Portal 11.1.1, the source code of utltrace.sql is available on Oracle Metalink at

    http://metalink.oracle.com


  2. Create a new DAD, for example portal_trc. Refer to the Oracle Fusion Middleware User's Guide for mod_plsql.

  3. Click OK to go back to the PL/SQL properties for the HTTP Server.

  4. In the DAD Status section, click the DAD that you created.Click Advanced, and then set the following values:

    • PlsqlBeforeProcedure: portal.wwutl_trace.trace_on

    • PlsqlAfterProcedure: portal.wwutl_trace.trace_off

  5. Stop and start the HTTP Server and WLS_PORTAL.


    Note:

    The cookie for the new DAD must be the same as the portal DAD so that you can replace the DAD in the portal URL. If the cookie name for the new DAD is different from the portal DAD, then update the cookie name of the new DAD with that of the portal DAD.

    Refer to Section 12.2.1, "Checking the PlsqlSessionCookieName Value" for details about checking or updating the cookie name.


  6. Change the DAD in the Oracle Portal URL to the new DAD that you defined in Step 2 and use this URL to access Oracle Portal. For example, change:

    http://<hostname>:<port>/portal/pls/portal/portal.home

    to:

    http://<hostname>:<port>/portal/pls/portal_trc/portal.home

After you set the event, two trace files will be written to the user_dump_dest directory. Open and view this file to check for any information about the unhandled exception error that you encountered.

G.2.2.2 Setting the sql_trace Parameter

You can enable tracing by setting the sql_trace database initialization parameter.

After setting an event, for the event to take effect, you must restart the database instance.

To enable tracing for all sessions in the database instance, set the sql_trace parameter to true in SPFILE using the following SQL syntax:

ALTER SYSTEM SET
sql_trace=true
COMMENT = 'turn tracing ON for all sessions'
SCOPE=SPFILE;

To turn tracing off, use the following syntax:

ALTER SYSTEM SET
sql_trace=false
COMMENT = 'turn tracing OFF for all sessions'
SCOPE=SPFILE;

If you are unfamiliar with the steps involved in updating a database initialization parameter file, refer to the section, "Managing Initialization Parameters Using a Server Parameter File", in the Oracle Database Administrator's Guide in the Oracle Database 11g documentation library.

G.2.2.3 Setting Database Event 10046

You can enable tracing for all sessions in a database instance by setting database event 10046. Event 10046 is the equivalent of setting the value of sql_trace to true in the parameter file. In addition, while setting event 10046, you can also specify the level of tracing.


Note:

Setting events should be done only with the help of Oracle Support Services.

Table G-1 describes different trace levels.

Table G-1 Trace Levels

Level Description

1

Used to enable standard SQL_TRACE functions. This is the default value.

4

Used to enable standard SQL_TRACE functions and to trace bind values.

8

Used to enable standard SQL_TRACE functions and to trace waits.

This is used mainly for identifying latch wait, but it can also be used to identify full table scans and index scans.

12

Used to enable standard SQL_TRACE functionality and to trace bind values and waits.



Note:

When you set a database event, consider the following points:
  • You cannot set an event when a database instance is running.

  • You can set events without having to mount or open the database. You can run the command with the database instance in NOMOUNT state.


To enable tracing by setting database event 10046 in SPFILE, use the following syntax:

ALTER SYSTEM SET
        EVENT = '10325 trace name context forever, level 10:10015 trace name context forever, level 1'
COMMENT = 'Debug tracing of control and rollback'
SCOPE=SPFILE;

If you are unfamiliar with the steps involved in updating a database initialization parameter file, refer to the section, "Managing Initialization Parameters Using a Server Parameter File", in the Oracle Database Administrator's Guide in the Oracle Database 11g documentation library.

G.2.3 Viewing the Diagnostic Output of Components

The various Oracle Portal components can have their diagnostic output configured. The following are the components:

G.2.3.1 JPDK

Java Portal Development Kit (JPDK) provides a framework for the construction of Java-based portlets and portlet providers. A Java-based provider or Web provider is written as a Web application. The JPDK includes a logging mechanism that is controlled based on each Provider Adapter.

Table G-2 lists and describes the available logging levels. The acceptable logging level values range from 1 to 8 and build incrementally. For example, at logging level 3, the output for logging levels 1 and 2 are also recorded.

Table G-2 Logging Levels

Logging Level Description

1

Configuration

2

Severe Errors

3

Warnings

4

Exceptions

5

Performance

6

Detailed Performance Information

7

Information

8

Debug


JPDK Log File Contents

Diagnostic information about a provider adapter is recorded in the servlet context log file named WLS_PORTAL-diagnostic.log.

There are two types of JPDK messages:

  • Standard JPDK Messages

  • Performance JPDK Messages

Standard JPDK Messages

Here is an example of a standard JPDK message that you might find in a Provider Adapter's WLS_PORTAL-diagnostic.log file:

07/12/31 02:58:59 jpdk: [instance=1926_EXPIRESSAMPLE_886361, id=1024597399815ApplicationServerThread-12,4] Beginning rendering of portlet: 1926_EXPIRESSAMPLE_886361

The content of the standard JPDK message is as follows:

  • Date and time: 07/12/31 02:58:59

  • Web application: jpdk

  • ECID, sequence number: id=1024597399815ApplicationServerThread-12,4

  • Portlet instance identifier: instance=1926_EXPIRESSAMPLE_886361

  • Message: Beginning rendering of portlet: 1926_EXPIRESSAMPLE_886361

The portlet instance identifier identifies a specific portlet instance on a specific page, and can be broken down as follows:

  • Internal sequence number: 1926

  • Portlet name: EXPIRESSAMPLE

  • Provider identifier: 886361

Additional details about some of these values are shown in Table G-3.

Table G-3 JPDK Standard Message Attributes

Value Detail

ECID

Some messages carry null ECID and portlet instance identifier values. These are typically SOAP messages from the repository.

Portlet instance identifier

This is the same as ECID except that the portlet instance identifier is null in this case, because the message does not relate to a particular portlet instance.


G.2.3.2 Portal Services

Portal Services performance is logged through Oracle HTTP Server. The default directory for the error_log file is ORACLE_INSTANCE/Apache/Apache/log on UNIX and ORACLE_INSTANCE\Apache\Apache\log on Windows. Logging is controlled by the LogLevel parameter in the configuration file httpd.conf.

G.2.3.3 Parallel Page Engine

The Parallel Page Engine (PPE) is a shared server process servlet that accepts data representing a page layout, and then converts this data into a page containing portlets.

PPE logging can be controlled at the servlet and request level. If a request logging level is not specified, then the servlet level is used for the request. If both servlet and request logging levels are specified, then the higher of the two is used for the request.

Servlet-level Logging

Diagnostic logging setting for Oracle Portal is maintained in the logging.xml file of the WLS_PORTAL instance (MW_HOME\user_projects\domains\<DomainName>\config\fmwconfig\servers\WLS_PORTAL).

By default, the logging level is NOTIFICATION:1, which is set at logger "oracle". The Portal logger oracle.portal is the child of the oracle logger and it inherits the logging level of the parent if it is not specified in logging.xml. If needed, you can set logger oracle.portal to have its own logging level. For example:

<logger name="oracle.portal" level="FINE"/>

Performance logging is set in appConfig.xml (MW_HOME\user_projects\domains\<DomainName>\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\appConfig.xml). By default, it is set to off.

<perfLogMode>off</perfLogMode> 

You can turn it on by specifying either on or perf. Performance logging output will be sent to the same target as diagnostic logging.

Table G-4 describes how setting the level for the oracle.portal logger affects the logging output from the PPE.

Table G-4 Logging Levels and Description

Log Level Description

None

No messages.

Severe

No debug messages, provides information on warnings and errors.

Config

No debug messages, provides information on configuration related messages.

Fine

Provides information on configuration related messages and general debug messages.

Finer

Provide all the information in Fine log level and details of requests made by the PPE.

Finest

Provide all the information in Finer log level and details of the content of requests made by the PPE and metadata parsing.


Request-Level Logging

PPE request-level logging is controlled by the _debug URL parameter. For example, to specify request-level logging for the following URL:

http://myserver.myplace.com:3000/portal/page?_pageid=111&_dad=myDAD&_schema=mySchema

You must manually insert the following:

&_debug=3

The resultant URL is as shown:

http://myserver.myplace.com:3000/portal/page?_pageid=111&_dad=myDAD&_schema=mySchema&_debug=3

Table G-5 lists the values for _debug.

Table G-5 PPE Request Log Levels

Value Detail

0

Activates page-debugging information

1

Activates page-debugging information

2

Logs to page and sets the request log mode to debug

3

Logs to page and sets the request log mode to request

4

Logs to page and sets the request log mode to content

5

Logs to page and sets the request log mode to parsing


Page Logging

With _debug set to 2, 3, 4, or 5, page logging is activated. This means that messages logged for the request are recorded in the PPE log file, and in the page returned.

Page logging is a means by which you can obtain detailed information relating to a request. As a result, it is also a security issue, for which the urlDebugMode servlet initialization argument is provided.

The urlDebugMode argument can be found alongside oracle.portallogger in the Portal appConfig.xml file (MW_HOME\user_projects\domains\<DomainName>\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\appConfig.xml):

<urlDebugMode>4</urlDebugMode>

Table G-6 lists the values for the urlDebugMode argument. The default value is 1.

Table G-6 PPE urlDebugMode Levels

Value Detail

None

Ignore the _debug URL parameter.

0

Allow _debug to be 0.

1

Allow _debug to be 0 or 1.

2

Allow _debug to be 0, 1, or 2.

3

Allow _debug to be 0, 1, 2, or 3.

4

Allow _debug to be 0, 1, 2, 3, or 4.

5

Allow _debug to be 0, 1, 2, 3, 4, or 5.


PPE Log File Contents

PPE diagnostic messages are recorded in the servlet context WLS_PORTAL-diagnostic.log file. This file can be found at:

MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\logs

There are two types of PPE messages:

  • Standard PPE Messages

  • Performance PPE Messages

Standard PPE Messages

The following is an example of a standard PPE message found in its log file:

03/12/31 11:54:35 portal: id=22020914339,0 DEBUG: active=53  ContentFetcher
 Unexpected Exception Request Failed:java.lang.IllegalArgumentException
 name=content-fetcher52 label=dbPortlet url=https://abc.company.com:5001/pls/ptl_
9_0_4_0_87/!PTL_9_0_4_0_87.wwpro_app_provider.execute_portlet/391497559/4
 time=38975ms timeout=15000ms process=ResponseHeaders

The content of this standard PPE message is as follows:

  • Date and time: 03/12/31 11:54:35

  • Web application: portal

  • logmode flag: DEBUG

  • Active count: active=53

  • ECID: id=22020914339, 0

  • Message: ContentFetcher Unexpected Exception Request Failed

Table G-7 provide details relating to some of these values.

Table G-7 PPE Standard Message Attributes

Value Detail

logmode flag

Indicates that log mode is debug or higher. If logmode is set to perf and is therefore lower than debug, then the logmode flag is not included in the message.

Active count

Indicates the number of threads in the PPE thread group. If logmode is set to perf and is therefore lower than debug, then the active count is not included in the message.

ECID

Can be null. A message with such a value relates to a PPE background task (such as clearing pooled objects). Background tasks do not relate to a request, and therefore do not have an ECID specified.


Performance PPE Messages

The following is an example of a performance PPE message found in the log file:

07/06/16 06:06:37 portal: [perf] 140.87.20.124
 https://abc.company.com:8250/portal/ page?_pageid=40,1&_dad=portal&_
schema=PORTAL&_mode=16 id=8198110376563,1 type=page name=40,1 status=200
 user=PORTAL subscriberID=1 reqTime=187ms waitTime=0ms cache=(null) timeout=No
 redirects=0 bytes=33865 authLevel=10 webCacheStatus=(null) webCacheExpires=(null)
 webCacheAge=(null) csConv=No readTime=No,0ms pageTimeout=No procTime=0ms

G.2.3.4 Oracle Fusion Middleware Portal Developer Kit

Oracle Fusion Middleware Portal Developer Kit (PDK) provides a framework for the construction of portlets and portlet providers in a variety of Web languages including Java, Web Services, XML, ASP, Perl, and PL/SQL. The PDK therefore includes JPDK.

The PDK provides a core logging mechanism, which is augmented by logging in specific developers kits. PDK logging is controlled through a Web-based user interface as shown in Figure G-3.

Figure G-3 PDK Logging Page

Description of Figure G-3 follows
Description of "Figure G-3 PDK Logging Page"

This PDK Logging Page can be found at:

http://<host>:<port>/portal/pls/<dad>/<schema>.wwpro_log.render

A sample URL is as follows:

http://myserver.myplace.com:3000/portal/pls/portal/PORTAL.wwpro_log.render

From this page you can apply the logging levels described in Table G-8.

Table G-8 PDK Log Levels

Level Detail

No debugging

No logging

PROHTTPJ

Provider framework logging

PROGRP

Provider logging

ADAPTER

Federated portal adapter logging

CACHE

Cache logging

FORCE

Internal to Oracle

INVAL

Invalidation logging

PROREG

Provider registration logging

PROLOGIN

Page metadata generation, login, and session initialization logging

PROPROV

Provider communication logging

PROPMR

Portlet metadata repository logging

PROHTTP

Web provider framework logging

All

All logging levels activated


PDK Log File Contents

You can view PDK log entries from the same page used to configure PDK logs, as shown in Figure G-4.

Figure G-4 Log Entries in the PDK Logging Page

Description of Figure G-4 follows
Description of "Figure G-4 Log Entries in the PDK Logging Page"

G.2.3.5 Oracle Metadata Repository

Oracle Metadata Repository consists of all the metadata, portal content, and PL/SQL code that reside in the Oracle Portal database schema. The PL/SQL code that executes in the Oracle Portal schema also generates diagnostics output that can be correlated with diagnostics output generated from the other components of Oracle Portal.

Because the log file is produced by Oracle Metadata Repository, the database running Oracle Portal must be configured to allow this. To do this, you must use the CREATE DIRECTORY statement to create a directory object.

A directory object specifies an alias for a directory on the server file system where external files and external table data are located.


Note:

All directories are created in a single namespace and are not owned by an individual schema. You can secure access to the files stored within the directory structure by granting object privileges on the directories to specific users.

To use the CREATE DIRECTORY statement, you must have the CREATE ANY DIRECTORY system privilege. When you create a directory, you are automatically granted the READ and WRITE object privileges on that directory. You, or the database administrator, can in turn grant these privileges to other users and roles.


Note:

WRITE privileges on a directory are useful in connection with external tables. They let the grantee determine whether the external table agent can write a log file or a bad file to the directory.

You must also create a corresponding operating system directory for file storage. Your system or database administrator must ensure that the operating system directory has the correct READ and WRITE privileges for Oracle Database processes

Privileges granted for the directory are created independently from the privileges defined for the operating system directory, and the two may, or may not, correspond exactly. For example, an error occurs if a sample user hr is granted READ privilege on the directory object, but the corresponding operating system directory does not have READ privilege defined for the Oracle Database processes.

To create a directory object, use the following syntax:

CREATE [OR REPLACE] DIRECTORY AS 'path_name';

Table G-9 describes the parameters used in CREATE DIRECTORY syntax.

Table G-9 CREATE DIRECTORY Parameters

Semantics Description

OR REPLACE

Specify OR REPLACE to re-create the directory database object, if it already exists. You can use this clause to change the definition of an existing directory without deleting, re-creating, and regranting database object privileges previously granted on the directory.

Existing users with privileges to access a redefined directory can to access the directory without being granted the privileges again.

directory

Specify the name of the directory object to be created. The maximum length of the directory name is 30 bytes. You cannot qualify a directory object with a schema name.

Oracle Database does not verify that the directory you specify actually exists. Therefore, you must ensure that you specify a valid directory in your operating system. In addition, if your operating system uses case-sensitive path names, then be sure to specify the directory in the correct format. You need not include a trailing slash at the end of the path name.

path_name

Specify the full path name of the operating system directory of the server where the files are located. The single quotation marks are required, with the result that the path name is case-sensitive.


For example, the following statement creates a directory database object that points to a directory on the server:

CREATE DIRECTORY admin AS 'oracle/admin';

The following statement redefines the bfile_dir directory database object to enable access to files stored in the operating system directory /private1/lob/files:

CREATE OR REPLACE DIRECTORY bfile_dir AS '/private1/LOB/files';

In the case of Oracle Database releases earlier than 9.2, for the PL/SQL code to generate diagnostics output, update the database initialization parameter file by adding the following line:

UTL_FILE_DIR=<directory where you want to write the log file>

If you are unfamiliar with the steps involved in updating a database initialization parameter file, refer to the section, "Managing Initialization Parameters Using a Server Parameter File", in the Oracle Database Administrator's Guide in the Oracle Database 11g documentation library.

There can be many UTL_FILE_DIR entries, so if the directory you wish to write to is already defined, then there is no need to modify this file.


Note:

On installing of Oracle Metadata Repository, if the database you are installing into has the UTL_FILE_DIR parameter set, then the Oracle Portal installer configures Oracle Metadata Repository such that it uses the first directory defined by the database parameter as the location for the Oracle Metadata Repository log file. If the UTL_FILE_DIR directory is not configured, then Oracle Metadata Repository logging is not set up on installation.

Oracle Metadata Repository logging is performed through a logging package. This logging package is controlled using the script logcfg.sql which you must run from SQL*Plus.

The logcfg.sql script can be found at:

ORACLE_INSTANCE/portal/admin/plsql/wwc

The logcfg.sql script can take five parameters in the following order: log_level, log_state_level, log_format, log_file, and log_directory. If less than five parameters are supplied, then one or more values are requested. If no value is received in response to this request, then the current value is maintained.

Table G-10 details the logcfg.sql parameters.

Table G-10 Repository Logging Package Parameters

Parameter Detail

log_level

Describes the level of messages recorded. The values are the following:

  • 0: None

  • 1: Error

  • 2: Warning

  • 3: Information

  • 4: Trace

  • 5: Debug

  • 6: Fine Debug

The values build incrementally. The default value is 1.

log_state_level

Describes the level of messages for which state information will automatically be logged. The values are the following:

  • 0: None

  • 1: Error

  • 2: Warning

  • 3: Information

  • 4: Trace

  • 5: Debug

  • 6: Fine Debug

The values build incrementally.

log_format

Describes the format of automatically recorded context information, which is different from state information. The values are the following:

  • 0: Simple

  • 1: Detailed

log_file

Specifies the name of the log file to write to. An attempt is made to create this file if it does not already exist.

log_directory

Specifies the directory in which the log_file parameter exists. This value can be either a physical path or a directory object. If the value is a physical directory, it must be defined in the database parameter file under the UTL_FILE_DIR property. For example:

utl_file_dir=/export/home/oracle/as1014/logs

If the database parameter file is modified, then the database must be restarted for this change to take effect.

If the value is a directory object, then you must specify the directory object name in uppercase. For example, LOGS.


For example, you can run the logcfg.sql script from SQL*Plus as follows:

@logcfg.sql 3 3 1 portal.log /export/home/oracle/as1014/logs

If you point to a directory object instead, then you must specify the directory object name in uppercase. For example, to point to a directory object named logs, you must run the logcfg.sql script from SQL*Plus as follows:

@logcfg.sql 3 3 1 portal.log LOGS

After running logcfg.sql, the usage is displayed:

Configure Portal diagnostics
usage:
logcfg.sql <log_level> <log_state_level> <log_format> <log_file> <log_directory>
If for any of the params a null value is specified the existing value will be maintained.
Log levels:
0 : None (turn diagnostics off)
1 : Error
2 : Warning
3 : Information
4 : Trace
5 : Debug
6 : Fine Debug
Log formats:
0 : Simple
1 : Detailed

The current values are also displayed:

Current settings:
Log level:     3
Log state level:     3
Log format:     1
Log file:     portal.log
Log directory:     /export/home/oracle/as101202/dblogs

To truncate the Oracle Metadata Repository diagnostics log file, run the SQL script logtrunc.sql located at: ORACLE_INSTANCE/portal/admin/plsql/wwc

Repository Log File Contents

The location of the Oracle Metadata Repository diagnostic information is dictated by the repository diagnostics package parameters log_file and log_directory.

The following is an example of an ERROR type message found in the Oracle Metadata Repository log file:

[06-AUG-2007 15:02:15] [ERROR] id=(102733434) ctx=wwsrc_simple_edit.render_simple_edit_prefs user=PORTAL subscriberId=1 language=us userAgent="Mozilla/5.0" ip=192.0.0.1
ORA-30625: method dispatch on NULL SELF
[START-ERROR-STACK]
ORA-30625: method dispatch on NULL SELF
[END-ERROR-STACK]
[START-CALL-STACK]
----- PL/SQL Call Stack -----
object          line          object
handle          number        name
81b35e6c        350           package body PORTAL.WWLOG_API_DIAG
81b35e6c        443           package body PORTAL.WWLOG_API_DIAG
81b35e6c        526           package body PORTAL.WWLOG_API_DIAG
86765ac8        259           package body PORTAL.WWSRC_SIMPLE_EDIT
86765ac8        334           package body PORTAL.WWSRC_SIMPLE_EDIT
84317130        19            package body PORTAL.WWSBR_BASIC_SEARCH
88857980        713           package body PORTAL.WWSBR_SITEBUILDER_PROVIDER
8323ad18        1             anonymous block
87e53d5c        648           package body PORTAL.WWPRO_API_PROVIDER
81ae1e50        2644          package body PORTAL.WWPOB_PAGE
877a0d9c        12            anonymous block
[END-CALL-STACK]
[START-QUERY-STRING]
_providerid=102274117
_portletid=14
_mode=5
_title=Basic%20Search
_referencepath=1875_BASICSEARCH_102274117
_back_url=http%3A%2F%2Fmyserver.myplace.com%3A3000%2Fpls%2Fportal%
_portlet_reference=33_31293_33_1_1
[END-QUERY-STRING]

The message in the log file is as follows:

ORA-30625: method dispatch on NULL SELF: - The message itself.

The log file also has context and state information.

Context Information

Context information is produced in one of two formats, detailed or simple, as specified by log_format parameter. In the following example, the format is detailed:

  • 06-AUG-2007 15:02:15: Date and time

  • ERROR: Message level

  • id=(102733434, 1): ECID

  • ctx=wwsrc_simple_edit.render_simple_edit_prefs: Message context

  • user=PORTAL: Database user

  • subscriberId=1: Subscriber identifier

  • language=us: Globalization Support language

  • userAgent="Mozilla/5.0": User agent

  • ip=192.0.0.1: Client IP address

The simple format is a subset of the detailed format and includes the following information:

  • 06-AUG-2007 15:02:15: Date and time

  • ERROR: Message level

  • ctx=wwsrc_simple_edit.render_simple_edit_prefs: Message context

Table G-11 provides additional details relating to some of these values.

Table G-11 Repository Context Attributes

Value Detail

Client IP address

Typically, this is the IP address of the client browser or HTTP proxy in use. Because the Oracle Portal page assembly process uses loopback calls, the IP address can also represent the middle tier itself.

Subscriber identifier

This identifies which subscriber has accessed the repository.

User agent

This is description of the browser in use.


State Information

State information consists of the error stack, call stack, and a query string. Examples of each of these are as follows:


Note:

The PL/SQL error stack is displayed only if a message of type ERROR is logged.

Error stack:

[START-ERROR-STACK]
ORA-30625: method dispatch on NULL SELF
[END-ERROR-STACK]

Call stack:

[START-CALL-STACK]
----- PL/SQL Call Stack -----
object          line        object
handle          number      name
81b35e6c        350         package body PORTAL.WWLOG_API_DIAG
81b35e6c        443         package body PORTAL.WWLOG_API_DIAG
81b35e6c        526         package body PORTAL.WWLOG_API_DIAG
86765ac8        259         package body PORTAL.WWSRC_SIMPLE_EDIT
86765ac8        334         package body PORTAL.WWSRC_SIMPLE_EDIT
84317130        19          package body PORTAL.WWSBR_BASIC_SEARCH
88857980        713         package body PORTAL.WWSBR_SITEBUILDER_PROVIDER
8323ad18        1           anonymous block
87e53d5c        648         package body PORTAL.WWPRO_API_PROVIDER
81ae1e50        2644        package body PORTAL.WWPOB_PAGE
877a0d9c        12          anonymous block
[END-CALL-STACK]

Query string:

[START-QUERY-STRING]
_providerid=102274117
_portletid=14
_mode=5
_title=Basic%20Search
_referencepath=1875_BASICSEARCH_102274117
_back_url=http%3A%2F%2Fmyserver.myplace.com%3A3000%2Fpls%2Fportal%
_portlet_reference=33_31293_33_1_1
[END-QUERY-STRING]

Repository Diagnostics Log File Registration

Oracle Enterprise Manager 11g provides a Log Reader and Log Viewer. The Log Reader allows administrators to upload log files to a file-based log repository. The Log Viewer allows administrators to view and query log entries loaded into the repository. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information.

To load and view the Repository Diagnostics log file entries, you must first register the log file with Oracle Enterprise Manager 11g. To do this, edit the following file:

ORACLE_INSTANCE/diagnostics/config/registration/PORTAL.xml

In this file, there is a template entry that you can copy and expand to reflect details of your log file. The template is as follows:

<logs xmlns="http://www.oracle.com/iAS/EMComponent/ojdl" helpIDLogs="psm_cs_xml_log_info">

<!-- 
<log path="<PATH>" componentId="PORTAL"> 
<logreader type="SimpleTextLog"> 
    <property name="ComponentId" value="PORTAL"/> 
    <property name="ModuleId" value="Portal:<INSTANCE>"/> 
    <property name="TimestampFormat" value="[dd-MMM-yyyy HH:mm:ss]"/> 
    <property name="TimestampLocale" value="en_US"/> 
</logreader> 
<logviewer ComponentName="ID_VLOGS_PORTAL_REP@ResourceBundle" 
           LogType="ERROR" 
           LogName="Diagnostics for Portal instance <INSTANCE>"/> 
</log> 
--> 

</logs>

Modify the following information in the copied template entry:

  • <PATH>: The absolute path and file name of the log file.

  • <INSTANCE>: The name of the Oracle Portal target in Oracle Enterprise Manager 11g, if it is defined. If there is no corresponding Oracle Portal target in Oracle Enterprise Manager 11g, then use the name of the Oracle Portal instance and database details, for example, <portal schema name>-<db service name>. This value is used to distinguish this log entry in the Log Viewer from other Oracle Portal instance log entries.

After you have saved the new PORTAL.xml entry, the Log Reader starts uploading the log file periodically, and you can use the Log Viewer to view and query this log file.

Because the Oracle Metadata Repository can be accessed through many middle tiers, you need to do the following:

  • Register the Repository Diagnostics log file with one of the Oracle Enterprise Manager 11g Fusion Middleware Control instances that is monitoring an Oracle Portal middle tier.

  • If the Oracle Portal database is on a computer other than the Oracle Portal middle tier, ensure that the log file is accessible over a network file system.

  • To perform log correlation in a multiple middle-tier environment, you need to register the Repository Diagnostics log file with each Oracle Enterprise Manager 11g instance monitoring an Oracle Portal middle tier.


    Note:

    . Using Oracle Enterprise Manager 11g, you have to update the location of the Repository Diagnostics log file in the PORTAL.xml file located at ORACLE_INSTANCE/diagnostics/config/registration/.

G.2.3.6 Oracle Web Cache

Oracle Web Cache events and errors are stored in an event log. The event log helps you to determine which documents or objects have been inserted into the cache. It can also identify listening port conflicts or startup and shutdown issues. By default, the event log has a file name of event_log and is stored in ORACLE_INSTANCE/webcache/logs on UNIX and ORACLE_INSTANCE\webcache\logs on Windows.

G.2.4 Using Fusion Middleware Control Log Viewer

You can use Oracle Enterprise Manager 11g Fusion Middleware Control to view and query entries from the following log files. This helps you to diagnose issues relating to Oracle Portal. The relevant Oracle Fusion Middleware component log files include the following:

  • Portal:<instance>: Displays a single, diagnostic error log file for each portal instance named <customer_specified_log_name>. This log file is generated by the relevant Oracle Metadata Repository.

  • HTTP_Server: Displays multiple error or access log files named error_log and access_log. These log files contain all relevant Portal Service logging information.

  • WLS_PORTAL: Displays multiple application log files named WLS_PORTAL-diagnostic.log. This log file contains all relevant PPE logging information.

  • Web Cache: Displays error and access log file names event_log and access_log.

Before you can use the Oracle Metadata Repository log file with Fusion Middleware Control Log Viewer, you must complete a registration process. Refer to the section "Repository Diagnostics Log File Registration" for instructions.

If your JPDK WLS instance is not located in the Oracle Portal middle tier Oracle home, then you may view its log file only through the local Fusion Middleware Control instance. If you want to perform diagnostic correlation, then you must follow a similar remote registration process to that described for the Oracle Metadata Repository log file when it is remotely located.

In addition to viewing the log file entries with Oracle Fusion Middleware Control Log Viewer, you can also perform advanced diagnostics by correlating entries across log files using the ECID value. See Section G.2.1, "Enabling ECID Logging" for more information. This drill-down correlation is automatically provided by the Oracle Fusion Middleware Control Log Viewer.

To view log file entries, click Logs, which is located at the top and bottom of every Oracle Fusion Middleware Control component home page.


See Also:

For detailed instructions on how to use the Log Viewer, refer to the Oracle Fusion Middleware Administrator's Guide. It describes how to perform advanced queries for diagnostic log file information, search through diagnostic messages (collected from selected Oracle Fusion Middleware components) in the Log Repository, and correlate messages across log files and components.

G.2.5 Using Oracle Portal Diagnostics Assistant

Use Oracle Portal Diagnostics Assistant to gather information if you are troubleshooting issues after Oracle Portal installation. Problems can vary from accessing the Oracle Portal, to users getting errors at different levels within Oracle Portal.

You can diagnose issues by reviewing the results from Oracle Portal Diagnostics Assistant. Alternatively, you can upload the results to Oracle Support Services so that they can assist in troubleshooting the problem for you.

The generated report includes the following sections:

  • Errors and violations summary (available only if violations are detected by Oracle Portal Diagnostics Assistant)

  • Oracle Portal Repository database information

  • OracleAS Single Sign-On database information

  • Oracle Internet Directory diagnostics report

  • Oracle Text diagnostics report

  • Apache error log file analysis

In addition, all Oracle Portal-related configuration files and log files are collected and zipped for your convenience.

To run Oracle Portal Diagnostics Assistant, you need to use the script pda.csh (UNIX) or pda.cmd (Windows). Each time you run the script, a new directory is created for the generated files under the directory where you downloaded the Oracle Portal Diagnostics Assistant zip file. The directory names have a timestamp format, for example, 070623132344 which means:


Year: 07
Month: 06
Day: 23
Hour: 13
Minutes: 23
Seconds: 44

After running Oracle Portal Diagnostics Assistant, locate the appropriate directory and open the HTML report named pda.htm in a browser window. You can navigate through the report and review the diagnostics information.

If you want Oracle Support Services to assist you in troubleshooting the problem, then log on to Oracle Metalink at http://metalink.oracle.com, and upload the generated ZIP file named PDA<directory_name>.zip, for example, PDA040623132344.zip.

For detailed information about using Oracle Portal Diagnostics Assistant and the information collected, refer to the readme file located in the directory in which you downloaded Oracle Portal Diagnostics Assistant.

Running Oracle Portal Diagnostics Assistant

To generate diagnostics information using Oracle Portal Diagnostics Assistant, perform the following steps:

  1. Check the Support and Metalink section on OTN for the latest update/patch information for Oracle Portal Diagnostics Assistant at:

    http://www.oracle.com/technology/

    Download the latest Oracle Portal Diagnostics Assistant script. Support/Upgrade is located in the Product Information section.

  2. Ensure that the ORACLE_INSTANCE environment variable is set to the correct Oracle Portal middle tier Oracle home directory.

    If you try to run Oracle Portal Diagnostics Assistant from a database Oracle home directory, it fails and no diagnostics information is collected.

  3. Navigate to the location where you downloaded and unzipped Oracle Portal Diagnostics Assistant.

  4. Run Oracle Portal Diagnostics Assistant on UNIX as follows:

    pda.csh
    -schema <portal schema name>
    -password <portal schema password>
    -connect <Portal connect string>
    -ssoSchema <SSO schema name>
    -ssoPassword <SSO schema password>
    -ssoConnect <SSO connect string>
    [-apacheLogDir <directory name>]
    [-apacheLogName <file name>]
    [-logFileLimit <number of rows>]
    [-show]
    [-showall]
    

    Run the script without any parameters to get Help information.

    Table G-12 lists and describes the parameters used with the Oracle Portal Diagnostics Assistant script.

    Table G-12 Oracle Portal Diagnostics Assistant Script Parameters

    Parameter Description

    -schema

    Name of the Oracle Portal schema. This parameter is mandatory. Default = Portal.

    -password

    Password for the Oracle Portal schema. This parameter is mandatory. Default = portal_schema.

    -connect

    Connect string for the Oracle Portal schema. Use the format <host>:<port>:<sid>. This parameter is mandatory.

    -ssoSchema

    Name of the OracleAS Single Sign-On schema. This parameter is mandatory.

    -ssoPassword

    Password for the OracleAS Single Sign-On schema. This parameter is mandatory.

    -ssoConnect

    Connect string for the OracleAS Single Sign-On schema. Use the format <host>:<port>:<sid>. This parameter is mandatory.

    -apacheLogDir

    Directory for Oracle HTTP Server error log file. This parameter is optional. Default = ORACLE_INSTANCE/Apache/Apache/logs.

    -apacheLogName

    Error log file name. This parameter is optional. Default = error_log.

    -logFileLimit

    The number of rows in the error log file. This parameter is optional. Default = 10000.

    -show

    Generates diagnostics information with only the necessary set of queries. This is the default mode for generating diagnostics information when no other parameters are selected.

    -showall

    Generates diagnostics information with all the queries. This mode has an additional query that retrieves all the portal objects and their privileges from the relevant security table. Because of this, generating diagnostics information in the -showall mode takes a very long time.


    The following is an example of running Oracle Portal Diagnostics Assistant on a Unix platform:

    # Set the environment
    #
    setenv ORACLE_INSTANCE /oracle/productsAS
    #
    # Run PDA
    #
    pda.csh \
    -schema portal  \
    -password <portal_password>  \
    -connect abc.oracle.com:1521:orcl1 \
    -ssoSchema orasso \
    -ssoPassword <orasso_password> \
    -ssoConnect defg.oracle.com:1521:orcl2
    -show
    

    Run Oracle Portal Diagnostics Assistant on Windows as follows:

    1. Start up a command prompt, and run the following command:

      pda.cmd
      -schema <portal schema name>
      -password <portal schema password>
      -connect <Portal connect string>
      -ssoSchema <SSO schema name>
      -ssoPassword <SSO schema password>
      -ssoConnect <SSO connect string>
      [-apacheLogDir <directory name>]
      [-apacheLogName <file name>]
      [-logFileLimit <number of rows>]
      [-show]
      [-showall]
      

    Run the script without any parameters to get help information.

    Table G-12 lists and describes the parameters used with the Oracle Portal Diagnostics Assistant script.

  5. Open the latest HTML report (pda.htm) in a browser window and use the information to help diagnose any Oracle Portal issues.

G.2.6 Analyzing Mobile-Related Problems in Oracle Portal

Mobile devices do not provide good interfaces for displaying detailed error information when compared with standard desktop browsers. The following information will help you analyze mobile-related problems in Oracle Portal.

Using the _debug parameter

All Oracle Portal pages can be run in a special mode where timing and caching information is displayed. If you append the _debug=1 parameter to a page URL, then extra timing information is added to the response that is displayed.

If you want to see the debug information for a few select pages and portlets, you can control the logging level by using the _debug URL parameter. Valid values for _debug are 0, 1, 2, 3, 4, and 5. For details about timing and caching statistics, refer to Section B.6, "Timing and Caching Statistics".

You may encounter problems in using the _debug URL parameter for mobile browser access because of the following reasons:

  • The URL that the mobile device uses to access Oracle Portal refers to an OracleAS Wireless service and not Oracle Portal. Therefore, you cannot directly append the _debug=1 parameter to the URL in the mobile browser.

  • The method used for rendering information for a mobile device requires the response page to be valid OracleAS Wireless XML. Because the extra information may not be valid OracleAS Wireless XML, it cannot be added inline to a mobile response page.

To resolve this problem and to use the _debug parameter, perform the following tasks:

  1. Create a new service in the OracleAS Wireless server to access a page directly, instead of using the default portal service that is registered with OracleAS Wireless. Specify a URL with a format similar to the following:

    http://<host.domain>:<port>/portal/pls/portal/MyGroup/MyPage?_debug=1
    
  2. Request the new service not the default portal service in the mobile device.

  3. View the servlet log file for the recorded performance information. This information will be in a format similar to the following:

    4/23/02 5:38 AM portal: [perf] Information for Portlet 33,31071.
    Portlet Timing: 234 msecs (wait=0)
    Timing Status: 
    XSLT Timing: null msecs
    Caching information of portlet:
    Portlet Cache status:  <I>Web Cache:-</I> MISS,NON-CACHEABLE [N], <I>File System Cache:-</I> MISS,NEW
    From Cache:  <I>Web Cache:-</I> -,  <I>File System Cache:-</I> None
    From Portlet: Cache Key: NORMAL, Cache Level: USER
     
    4/23/02 5:38 AM portal: [perf] Information for Page 33%2C31060%2C33_31062
    Elapsed Time: 2470 msecs
    Page meta-time 7 msecs (wait = 994)
    Page meta Cache Status:  <I>Web Cache:-</I> MISS,NON-CACHEABLE [N], Cache Expires: null secs, Age in Cache: null secs ,  <I>File System Cache:-</I> MISS,NEW
    Login meta-time 1227 msecs (wait = 1)
    Login meta Cache Status:  <I>Web Cache:-</I> MISS,NON-CACHEABLE [N], Cache Expires: null secs, Age in Cache: null secs
    

Mobile Information Useful for Support

If you are not able to resolve mobile-related problems by using the troubleshooting steps described in Section G.1.20, "Problems in Accessing Oracle Portal from a Mobile Device" then contact Oracle Support Services. It would be helpful if you have answers to the following questions before you contact Oracle Support Services:

  1. What are the symptoms of the error? For example, did you get error messages, was there a lack of response, or was a blank screen displayed?

  2. What is the context of the error?

    • Was the user logged on?

      • Do all authenticated users experience the same problem?

      • Does the public user experience the problem?

    • Does the problem occur during the logon phase?

      • How far did the user get in logging on?

      • Did the user try to log on in the standard manner, or was the user directed to log on?

    • Does the problem occur when viewing a page?

      • Describe the page structure.

      • Do any portlets allow titles to be personalized?

      • Can the page be previewed using a standard desktop browser without having OracleAS Wireless in the communication network?

    • Does the problem occur when viewing an individual portlet?

    • Does the problem occur on all mobile pages, a few pages, or one page?

  3. If possible, run the portal service through the OracleAS Wireless debug tool. This requires specific OracleAS Wireless access. For details, refer to the Oracle Application Server Wireless Administrator's Guide.

  4. Is there a record for the problem in any of the log files listed in Table G–13?

    Table G-13 Error Log Files and Locations

    Log Files Location

    OracleAS Wireless Server log files

    ORACLE_INSTANCE/wireless/logs/sys_panama.log or /var/tmp/sys_panama.log

    Server JVM standard output:

    ORACLE_INSTANCE/opmn/logs/OC4J_Wireless_default_island/application.log

    Provider JVM standard output:

    ORACLE_INSTANCE/j2ee/OC4J_wireless/application-deployments/portal/WLS_OC4J_default_island/application.log

    Oracle HTTP Server log files

    ORACLE_INSTANCE/Apache/Apache/logs/access_log/application.log and ORACLE_INSTANCE/Apache/Apache/logs/error_log

    Parallel Page Engine Server log file

    ORACLE_INSTANCE/j2ee/WLS_PORTAL/application-deployments/portal/WLS_PORTAL_default_island_1/application.log


G.3 Need More Help?

You can find more solutions on Oracle MetaLink at

http://metalink.oracle.com

If you do not find a solution for your problem, then log a service request.

To help Oracle Support Services troubleshoot the problem, perform the following steps:

  1. Run Oracle Portal Diagnostics Assistant.

    You can diagnose portal-related issues by reviewing the report generated by Oracle Portal Diagnostics Assistant. You can also refer to Section G.2.5, "Using Oracle Portal Diagnostics Assistant" for more information.

  2. Contact Oracle Support Services.

    If you cannot establish why your portal is not accessible, then contact Oracle Support Services. To help Oracle Support Services troubleshoot the problem, provide the following information:

    • ZIP file generated by Oracle Portal Diagnostics Assistant.

    • Details of any command-line scripts that you have run (for example, ptlconfig) including all the parameters used.

    • A rough network diagram, showing how your Oracle Fusion Middleware components are configured.


See Also:

Oracle Fusion Middleware Release Notes for Microsoft Windows (32-Bit), available on OTN http://www.oracle.com/technology/documentation/index.html