|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.4) B19305-03 |
|
 Previous |
 Next |
|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.4) B19305-03 |
|
|
Previous |
Next |
This appendix describes common problems that you may encounter when using Oracle Application Server Portal and explains how to solve them. It also gives detailed instructions on how to diagnose OracleAS Portal problems. It contains the following topics:
This section describes common problems and solutions. It contains the following topics:
Problems with Oracle Application Server Integration Configuration
User and Group Information in OracleAS Portal and Oracle Internet Directory Does Not Match
Create New Users and Create New Groups Portlets Do Not Appear
Problems in Configuring OracleAS Web Cache for the OmniPortlet Provider
Error During Export and Import After Upgrading from OracleAS Portal 3.0.9 or 9.0.4
You cannot access your portal instance. 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 OracleAS Portal.
OracleAS Portal requires Oracle Application Server components, such as Oracle HTTP Server, OracleAS Web Cache, Portal Services, OracleAS Metadata Repository, and OC4J_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 OracleAS Portal home page in Application Server Control Console. See Section 7.3, "Using Application Server Control Console to Monitor and Administer OracleAS Portal" for more information.
Check if Oracle HTTP Server is up. The Oracle HTTP Server status is displayed in the Component Status table on the OracleAS Portal home page.
If the status is 'Up', then continue to the next step.
If the status is 'Down', then start Oracle HTTP Server using Application Server Control Console.
To access Oracle HTTP Server monitoring and administration pages in Application Server Control Console, click HTTP_Server in either of the following:
Portal Component Status table
Application Server System Components table
If Oracle HTTP Server starts successfully, check whether your portal is accessible.
If Oracle HTTP Server fails to start, then investigate the Oracle HTTP Server error log files and try to determine the problem. See Section K.2.4, "Using Application Server Control Console Log Viewer" for more information. If you are not using Log Viewer, then check the relevant error log files in the following directories:
ORACLE_HOME/opmn/logs
ORACLE_HOME/Apache/Apache/logs/error_log
Problem 2
OracleAS Web Cache is down.
Solution 2
Navigate to the Oracle Enterprise Manager 10g Application Server Control Console of the Oracle home directory that is running the OracleAS Web Cache process. For details, refer to the section on Starting and Stopping Oracle Application Server Web Cache in Oracle Enterprise Manager Advanced Configuration.
Check if OracleAS Web Cache is up. The OracleAS Web Cache status is displayed in the Application Server System Components table.
If the status is 'Up', then continue to the next step.
If the status is 'Down', then start OracleAS Web Cache using the Application Server Control Console.
To access OracleAS Web Cache monitoring and administration pages in the Application Server Control Console, click Web Cache in the Application Server System Components table.
If OracleAS Web Cache starts successfully, check whether your portal is now accessible.
If OracleAS Web Cache fails to start, then investigate the OracleAS Web Cache error log files and try to determine the problem. See Section K.2.4, "Using Application Server Control Console Log Viewer" for more information.
If you are not using Log Viewer, then check the relevant error log files in the ORACLE_HOME/opmn/logs and ORACLE_HOME/webcache/logs directories.
Problem 3
OracleAS Portal is down due to incorrect Portal DAD configuration.
Solution 3
Check the status and configuration of the OracleAS Portal DAD. Navigate to the Oracle HTTP Server home page in Application Server Control Console. See Section 7.3, "Using Application Server Control Console to Monitor and Administer OracleAS Portal" for more information. Click HTTP_Server in either of the following:
Portal Component Status table
Application Server System Components table
From the Oracle HTTP Server home page, click Administration. and then PL/SQL Properties. Check the DADs table 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 OC4J_Portal and Oracle HTTP Server for any change to take effect. See Section 4.5.3, "Configuring a Portal DAD" for information about configuring the DAD from the portal's home page.
|
Note: You can verify the connection details for a DAD using SQL*Plus - in the Oracle home directory associated with the Oracle Application Server for your portal. TheDAD 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
OracleAS Metadata Repository is down.
Solution 4
Display the OracleAS Portal home page in the Application Server Control Console. See Section 7.3, "Using Application Server Control Console to Monitor and Administer OracleAS Portal" for more information.
Look under the OracleAS 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 OC4J_Portal service is down.
Solution 5
Display the Application Server home page (for your OracleAS Portal instance), in the Application Server Control Console. See Section 7.2, "Using the Application Server Control Console" for more information.
The OC4J_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 OC4J_Portal using the Application Server Control Console.
To access OC4J_Portal monitoring and administration pages in the Application Server Control Console, click OC4J_Portal in either of the following:
Parallel Page Engine Services page (available from the Component Status table on the OracleAS Portal home page)
Application Server System Components table
If OC4J_Portal starts successfully, check whether your portal is now accessible.
If OC4J_Portal fails to start, then investigate OC4J_Portal error log files and try to determine the problem. See Section K.2.4, "Using Application Server Control Console 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_HOME/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 10g documentation library, for information on how to troubleshoot Oracle Net Services.
Problem 7
OPMN or the Portal Services is reporting some other error.
Solution 7
Perform the following steps to resolve the problem:
Navigate to ORACLE_HOME/opmn/bin and issue the opmnctl status command. Ensure that key services show an alive status. If not, scan the files under ORACLE_HOME/opmn/logs for more details.
Navigate to ORACLE_HOME/j2ee/OC4J_Portal/application-deployments/portal/OC4J_Portal_default_island_1 and scan the file application.log for details on how to proceed with resolving the issue.
Navigate to ORACLE_HOME/webcache/logs. Scan the event_log file for any pointers to the problem.
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 OracleAS Portal pages after you have been authenticated.
Problem 1
You may not be able to log in to OracleAS Portal due to problems encountered during the process of logging in to OracleAS Portal.
The OracleAS Portal login process can be logically broken down into three parts:
Communication between OracleAS Portal and OracleAS Single Sign-On
Communication between OracleAS 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 OracleAS Portal and OracleAS Single Sign-On
To understand the first part of the login process, assume that OracleAS 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/orasso
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 OracleAS Portal.
To diagnose the cause of a problem encountered in this part of the login process, perform the following steps:
Display the OracleAS Single Sign-On home page in the Oracle Enterprise Manager 10g Application Server Control Console.
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.
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 the Application Server Control Console.
To access Oracle HTTP Server monitoring and administration pages in the Application Server Control Console, click HTTP_Server in either of the following:
OracleAS Single Sign-On home page
Application Server 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 K.2.4, "Using Application Server Control Console Log Viewer" for more information. If you are not using Log Viewer, then check the relevant error log files in the following directories:
ORACLE_HOME/opmn/logs
ORACLE_HOME/Apache/Apache/logs/error_log
Check the status and configuration of the OracleAS Single Sign-On DAD.
From the OracleAS Single Sign-On home page, perform the following steps:
In the Related Links section of the OracleAS Single Sign-On home page, click HTTP_Server.
Click Administration.
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 OC4J_Portal for any change to take effect.
Check if you can log in now.
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 10g Application Server Control Console. 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.
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_HOME/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 10g documentation library, for the specific error number returned, and then take suitable action.
Check if the OC4J_Security service is up.
The OC4J_Security status is displayed in the Application Server Control Console.
If the status is 'Up', then continue to the next step.
If the status is 'Down', then start OC4J_Security using the Application Server Control Console.
To access OC4J_Security monitoring and administration pages in the Application Server Control Console, click OC4J_Security in the System Components table on the home page for the Infrastructure home directory instance.
If OC4J_Security starts successfully, then check if your OracleAS Single Sign-On schema is accessible.
If OC4J_Security fails to start, then investigate OC4J_Security error log files and try to determine the problem. See Section K.2.4, "Using Application Server Control Console Log Viewer" for more information.
Check the OracleAS Portal and OracleAS Single Sign-On connection configuration.
Check the connection configuration of OracleAS Portal and OracleAS Single Sign-On. There may be a problem with the connection configuration if you see any of the following error messages:
"WWC-41453: The cookie version specified in the authentication message is not supported by this configuration". Please notify your administrator."
"WWC-41454: The decryption of the authentication information was unsuccessful". This may be caused by corruption of the data, an incorrect encryption key in this application's configuration, or an illegal access attempt. Please notify your administrator.
"WWC-41439: You cannot login because there is no configuration information stored in the enabler configuration table."
If you find there is a problem with the OracleAS Portal and OracleAS Single Sign-On connection configuration, then fix the Host parameter in the IASInstance element and the ListenPort parameter in the WebCacheComponent element in the iasconfig.xml file and run the ptlconfig tool as follows:
ptlconfig -dad <dad name> -site
Verify Communication Between OracleAS Portal and Oracle Internet Directory
In the second part of the OracleAS Portal login process, the credentials provided by OracleAS Single Sign-On are used by OracleAS 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, you need to check if the Oracle Internet Directory service is Up. The Oracle Internet Directory status is displayed on the Application Server page.
If the status is 'Up', then continue to the next step.
If the status is 'Down', then start Oracle Internet Directory using the Application Server Control Console.
To access Oracle Internet Directory monitoring and administration pages in the Application Server Control Console, click OID in the System Components table on the home page for the Infrastructure home directory instance.
If Oracle Internet Directory starts successfully, then check if you can log in.
If Oracle Internet Directory fails to start, then investigate the Oracle Internet Directory error log files and try to determine the problem. See Section K.2.4, "Using Application Server Control Console Log Viewer" for more information. It is also likely that this is a problem with OracleAS Portal and Oracle Internet Directory connection configuration. The solution is to fix the values in the OIDComponent element in the iasconfig.xml file and run the ptlconfig tool as follows:
ptlconfig -dad <dad> -oid
Verify Assignment of the Home Page
In the final part of the OracleAS Portal login process, you are redirected to the appropriate OracleAS 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.
Problem 2
OPMN is reporting issues.
Solution 2
Navigate to ORACLE_HOME/opmn/bin and issue the opmnctl status command. Ensure that key services show an alive status. If not, scan the files under ORACLE_HOME/opmn/logs for more details.
Oracle Enterprise Manager, authentication, caching, or URLs do not work with OracleAS Portal.
Problem
OracleAS Portal is not correctly configured to connect to certain other Oracle Application Server components. The iasconfig.xml file does not have the correct information for connecting to other Oracle Application Server components.
Solution
See Section K.2.6, "Verifying the Portal Dependency Settings File" for details on verifying the contents of the Portal Dependency Settings file, iasconfig.xml.
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 C.10, "Using the Category and Perspective Scripts" for more information about where to look for and run these scripts.
After following the steps in Section 5.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 OracleAS 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 5.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.
User and group information in OracleAS Portal is not synchronized with the information in Oracle Internet Directory.
Problem
Changes from Oracle Internet Directory are not propagated to OracleAS Portal. OracleAS Portal uses a provisioning profile to receive notifications when user or group privilege information changes. This enables OracleAS 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:
Check if provisioning is enabled.
Perform the following steps to check if provisioning is enabled:
Log in to OracleAS Portal. Click the Administer tab. On the Portal Builder page, click Global Settings under Services.
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.
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. The solution is to run the ptlconfig tool as follows:
ptlconfig -dad <dad> -dipreg
Check if Oracle Directory Integration Platform is up and running.
Perform the following steps to do this:
Display the Oracle Enterprise Manager 10g Application Server Control Console. See Section 7.2, "Using the Application Server Control Console" for more information. Navigate to the Application Server Control Console of the Infrastructure home directory associated with your portal.
Oracle Internet Directory status is displayed on the Application Server page.
If the status is 'Up', then continue to the next step.
If the status is 'Down', then start Oracle Internet Directory using Application Server Control Console.
To access the Oracle Internet Directory monitoring and administration pages in the Application Server Control Console, click OID in the Application Server 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 K.2.4, "Using Application Server Control Console Log Viewer" for more information.
Check if Oracle Directory Integration Platform is up.
Click OID in the Application Server 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 10g Application Server Control Console.
|
See Also:
|
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:
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.
Check for the trace and audit Log Files.
Navigate to the ORACLE_HOME/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=UltraSearch,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=ultrasearch,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=UltraSearch,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=UltraSearch,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 OracleAS 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:
Log in to OracleAS Portal. Click the Administer tab. On the Portal Builder page, click Global Settings under Services.
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.
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_HOME/ldap/odi/log/ directory, then chances are that the provisioning profile has been deleted. To re-create a provisioning profile, run the ptlconfig tool as follows:
ptlconfig -dad <dad> -dipreg
Are Changes Propagated Properly?
To help diagnose whether or not changes are propagated properly, create, delete, and re-create a user through OracleAS Portal (in Oracle Internet Directory). To do this, perform the following steps:
Click the Administer tab.
Under User, click Create New Users.
Edit the profile of the user.
Delete the user.
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 OracleAS 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 OracleAS 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 OracleAS Portal with Oracle Directory Integration Platform. If this is an OracleAS Portal configuration problem, then run the ptlconfig tool as follows:
ptlconfig -dad <dad> -dipreg
You may experience performance issues with OracleAS 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
Set the PlsqlCacheEnable parameter to On in the ORACLE_HOME/Apache/modplsql/conf/cache.conf file. See Section 4.5.4, "Configuring the Portal Cache" for more information.
Ensure that the PlsqlCacheDirectory parameter is correctly configured in the ORACLE_HOME/Apache/modplsql/conf/cache.conf file. See Table 7-2, "Portal Cache Settings" for more information.
Problem 2
Page metadata is not cached in OracleAS Web Cache. The initial, one-time call from the middle tier to the OracleAS Portal schema to determine the OracleAS Portal version may have failed.
Solution 2
To resolve this problem, perform the following tasks:
Confirm that page metadata is not cached in OracleAS Web Cache. To do this, perform either of the following steps:
Append a page URL with &_debug=1, refresh the browser, and verify that the OracleAS Web Cache page metadata cache status is MISS, NON-CACHEABLE.
Access the Popular Requests screen in OracleAS Web Cache Manager and verify that page metadata is not cached.
Restart all OC4J_Portal instances.
Perform Step 1 again to determine if page metadata is now cached in OracleAS Web Cache.
If the caching problem has not been resolved, then perform the diagnostic steps described in the Oracle Application Server Portal Error Messages Guide for the following error:
WWC-40018: General invalidation message processing exception: %1
Problem 3
Oracle Containers for J2EE (OC4J) is unable to handle the load.
Solution 3
If you get repeated error messages such as the following, then it is possible that the load on by OC4J_Portal exceeds the capacity of either your hardware or configuration settings:
application.log file contains [example] 04/28/04 5:47 PM portal: Fetcher content-fetcher12 shut down. 04/28/04 5:47 PM portal: UncaughtException in thread name=content-fetcher12, java.lang.RuntimeException: Fetcher at oracle.webdb.page.ContentFetcher.run(Unknown Source)
Upgrade your hardware to handle a heavy load by doing any or all of the following:
Adding hardware or an LBR: For details, refer to the white paper titled "How to Effectively Size Hardware for Your Portal Implementation" located on Oracle Technology Network (OTN) at: http://www.oracle.com/technology/products/ias/portal/administration_10g1014.html.
Removing -xingc: This is a default setting in Oracle9iAS Portal (9.0.2), required for the Wireless element of OC4J_Portal. -xingc is the flag that turns on incremental garbage collection for the JVM. Garbage collection in OracleAS Portal occurs when maximum heap size (-mx) is reached, and does not necessarily require -xingc. By removing -xingc , you will not see periodic CPU spikes that occur during the garbage collection process. The CPU spiking for incremental garbage collection can be a problem on a CPU-bound system. If -xingc is removed, then garbage collection will occur only when that -mx is reached.
Increasing –ms and -mx: These are initial (ms) and maximum (mx) heap sizes specified for each instance of OC4J_Portal. These are usually specified in Megabits.
Increasing numProcs: numProcs is the number of default instances of an OC4J that will be instantiated at startup. The default value of numProcs is 1. Refer to subsection "Option 1: Create a New OC4J Instance to Create Another Set of PPE Threads" under Section 9.3, "Setting the Number of PPE Fetchers", for information about increasing the number of OC4J_Portal instances. Before OracleAS Portal (9.0.4), this could also be set by editing the application configuration file where the default values of the numProcs setting are stored.
The numprocs setting provides an element of scalability and redundancy. The Parallel Page Engine (PPE) has an internal concept of fetcher threads, which are used to respond to requests for content. By default, each PPE has 25 fetcher threads available for use. When a thread is busy, the available number is reduced. At a high load when no threads are available, the incoming requests are queued. This can be alleviated by increasing the fetcher threads number in the PPE configuration file. While this provides you with an increased number of available threads, there is no redundancy.
By setting numProcs to 2, you have two instances of OC4J_Portal and therefore twice the number of fetcher threads, that is 50. If any instance should fail for any reason, then you still have 25 threads while OPMN restarts the instance that has died.
Problem 4
Low or no reuse of connection pool.
Solution 4
Set the PlsqlMaxRequestsPerSession parameter to 1000 in the dads.conf file.
On UNIX systems, this file is in the ORACLE_HOME/Apache/modplsql/conf directory.
On Windows systems, this file is in the ORACLE_HOME\Apache\modplsql\conf directory.
Ensure that the PlsqlMaxRequestsPerSession parameter is not set to 1. Doing this disables connection pooling. For information about the PlsqlMaxRequestsPerSession parameter, refer to the Oracle HTTP Server Administrator's Guide.
|
Note: It is recommended that you edit thedads.conf file using Application Server Control Console.
If you manually edit the |
Problem 5
Processes start up or shut down frequently.
Solution 5
Tune the Oracle HTTP Server parameters, MaxSpareServers and MinSpareServers, in the ORACLE_HOME/Apache/Apache/conf/httpd.conf file. The default value for the MaxSpareServers parameter is 10, and the default value for the MinSpareServers parameter is 5.
|
Note: Tuning of both theMaxSpareServers and MinSpareServers parameters should be necessary only on very busy sites. Setting this parameter to a large number is a bad idea. For more information refer to the Oracle HTTP Server Administrator's Guide.
|
Problem 6
Connection pool is cleaned up too frequently.
Solution 6
Tune the PlsqlIdleSessionCleanupInterval parameter in the ORACLE_HOME/Apache/modplsql/conf/plsql.conf file. Increasing the value of this parameter allows pooled database connections to remain available in the pool for the specified time. The default value is 15 (minutes).
Problem 7
Disk input or output not distributed.
Solution 7
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 8
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 (Oracle Containers for J2EE) run on a computer other than Oracle HTTP Server or mod_oc4j.
Infrastructure components run across wide networks with multiple routers.
Solution 8
Try to reduce the number of network hops by avoiding or working around the listed problems.
Problem 9
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 9
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 5.6, "Configuring Reverse Proxy Servers" for more information.
Problem 10
After performing all the tasks in the solutions provided, OracleAS Portal is still slow.
Solution 10
Review metric information for OracleAS Portal, its host, and other relevant components.
If all the components required by OracleAS Portal are up and running as expected, then the next step is to review metric information in Oracle Enterprise Manager 10g Grid Control Console, or Application Server Control Console.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 (OracleAS Web Cache, Oracle HTTP Server, OC4J, and so on).
Run OracleAS Portal Diagnostics Assistant.
You can diagnose portal-related issues by reviewing the report generated by using OracleAS Portal Diagnostics Assistant. See Section K.2.5, "Using OracleAS Portal Diagnostics Assistant" for more information.
|
See Also:
|
|
Note: The Performance Monitoring Scripts zip file is also available as part of the Oracle Application Server installation. |
When you try to create Web folders in OracleAS 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:
Change the directory to ORACLE_HOME/portal/admin/plsql/wws, where the davreprt.sql file is available.
Log in to SQL*Plus as the PORTAL schema user.
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.
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:
Display the portal home page in Oracle Enterprise Manager 10g Application Server Control Console. See Section 7.2, "Using the Application Server Control Console" for more information. Navigate to Application Server 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 application Server page.
If the status is 'Up', then continue to the next step.
If the status is 'Down', then start Oracle Internet Directory using Application Server Control Console or the command line.
To access Oracle Internet Directory monitoring and administration pages in Application Server Control Console, click Oracle Internet Directory in the Application Server 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 K.2.4, "Using Application Server Control Console Log Viewer" for more information.
Problem 3
OracleAS Portal and Oracle Internet Directory connection configuration is incorrect.
Solution 3
Fix the values in the OIDComponent element in the iasconfig.xml file and use the ptlconfig tool to reconfigure your Oracle Internet Directory and OracleAS Portal configuration as follows:
ptlconfig -dad <dad> -oid
|
Note: When you run theptlconfig -dad <dad> -oid command, it configures Oracle Internet Directory with OracleAS Portal with the following types of seeded entries:
If you have previously removed any of these seeded entries, then you must remember that they will be re-created when you reconfigure OracleAS Portal with Oracle Internet Directory. |
When you attempt to log in to OracleAS Portal, you see one of the following errors in the error_log file located in the MID_TIER_ORACLE_HOME/Apache/Apache/logs directory:
ORA-20000: "An attempt was made to access the session context without a valid session"
This error denotes that the OracleAS 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 K.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 OracleAS Metadata Repository.
Session Is Cleaned Up
A background job runs frequently to clean up old sessions from the portal schema in the OracleAS 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 C.6, "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 OracleAS 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 OracleAS 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 OracleAS Portal tries to use that cookie. However, because each portal cookie is encrypted using portal-specific keys, OracleAS 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 OracleAS Metadata Repository. Its value is typically set during OracleAS 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 OracleAS 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.
A remote Web provider that is located on a computer different from the OracleAS Portal middle tier, works when the OC4J_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 OC4J_Portal application.log file. After restarting OC4J_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 OC4J_Portal to prevent remote Web providers from timing out. You must change the sun.net.inetaddr.ttl system property for OC4J_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.
|
Note: This system property is passed as a command-line option to Oracle Containers for J2EE (OC4J). Setting the property in theoc4j.properties file does not help, because the system property is read first before OC4J reads this file. Therefore, it is best to modify the <java-option> line in the OC4J_Portal section of the ORACLE_HOME/opmn/conf/opmn.xml directory.
|
Example
Edit the opmn.xml file as follows:
<java-option value="-server -Xincgc -Xnoclassgc -Xms256m -Xmx512m -Dsun.net.inetaddr.ttl=120"/>
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_HOME/opmn/bin/opmnctl stopall ORACLE_HOME/opmn/bin/opmnctl startall
You see the error "ORA-04031: unable to allocate 30192 bytes of shared memory."
Problem
By default, the shared_pool_size value in Oracle Application Server 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 10g documentation library.
|
Note: As an optional step, it is suggested that you run OracleAS Portal Diagnostics Assistant to view a report of the existing and recommended values of the database. See "Running OracleAS Portal Diagnostics Assistant" for details. |
You are facing issues with the installation of Oracle Text.
Problem
You encounter Oracle Text-related problems.
Solution
Use the TEXTTEST utility to check that Oracle Text is installed and set up correctly. See Appendix H, "Using TEXTTEST to Check Oracle Text Installation" for more information.
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 8.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 OracleAS 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 OracleAS 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 OracleAS Portal schema owner, for example, portal.
Refer to Appendix H, "Using TEXTTEST to Check Oracle Text Installation" for more information.
Only a subset of the online Help appears to be translated in OracleAS Portal.
Problem
In OracleAS 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.
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 OracleAS 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.
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 Application Server Portal User's Guide.
When using OracleAS 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 Application Server Portal User's Guide.
|
Note: It is recommended that this setting is always enabled. |
When accessing or using OracleAS Portal, you may encounter an unhandled exception error. For example, "Error 30526: An Unhandled Exception has occurred."
Problem
OracleAS 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 K.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.
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, application.log. This log file is available at either of the following locations:
OC4J_HOME/j2ee/home/application-deployments/portalTools/ (for PDK Only installations)
ORACLE_HOME/j2ee/OC4J_Portal/application-deployments/portalTools/OC4J_Portal_default_island_1/
Problem
The required SSL library is not in the library path.
If you installed the OracleAS PDK on a standalone OC4J instance, or if you downloaded the preconfigured standalone OC4J with OracleAS PDK, then 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.
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 OracleAS 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_HOME/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 OracleAS Web Cache instance is maintained in the cache.xml file in the ORACLE_HOME/portal/conf directory. If the Web Cache invalidation settings change, then you must update this file. Refer to Section I.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 OC4J instance:
Error: CONFIGURATION: Provider Test Page: Web Cache Invalidation config file not defined by "oracle.http.configfile"
Solution 3
Add the oracle.http.configfile system property as a new line in the ORACLE_HOME/j2ee/OC4J_Portal/config/oc4j.properties file as shown in the following example:
oracle.http.configfile=<fully_qualified_filename>
Problem 4
The configuration file defined by the oracle.http.configfile system property does not exist. You may encounter the following error:
Error: CONFIGURATION: Provider Test Page: Web Cache Invalidation config file defined by "oracle.http.configfile" does not exist.
Solution 4
Ensure that you have specified a valid file name in the oracle.http.configfile system property in the ORACLE_HOME/j2ee/OC4J_Portal/config/oc4j.properties file.
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 OracleAS 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:
Writes the document into the servlet error log file, application.log, located in the ORACLE_HOME/j2ee/OC4J_Portal/application-deployments/portal/OC4J_Portal_default_island_1 directory.
Assigns a unique ID to the error.
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 OracleAS Portal and OracleAS Wireless configurations in Oracle Application Server. For details about verifying these settings, refer to the Oracle Application Server Administrator's Guide.
Problem 2
You are not authenticated to access OracleAS 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 C.2, "Configuring for IP Check During Session Cookie Validation" for details.
Access OracleAS 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 OracleAS 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_HOME/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, application.log, from the ORACLE_HOME/j2ee/OC4J_Portal/application-deployments/portal/OC4J_Portal_default_island_1 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 OracleAS Portal troubleshooting analysis.
If you run the OracleAS Portal Export and Import, after upgrading from OracleAS 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 OracleAS Portal Export and Import utility:
SQL> @pstpgcre.sql
This script is located at ORACLE_HOME/portal/admin/plsql/wws/pstpgcre.sql. This script drops and re-creates the category and perspective templates and their associated pages.
Refer to Section C.10, "Using the Category and Perspective Scripts" for information on how to use the category and perspective scripts.
Problem 2
When you upgrade from OracleAS 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 10.1.2, 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. |
OracleAS 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 OracleAS Portal to analyze and resolve issues about how OracleAS Portal works.
This section contains the following topics:
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 OracleAS Portal can satisfy a large number of requests simultaneously, tracing a single request through the various OracleAS Portal components can be difficult because the information relating to these requests is intermingled.
OracleAS 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 Application Server component to receive a request without an ECID. You can observe this generation and propagation in Figure K-1, where a dotted arrow depicts a request with an ECID.
Figure K-1 Request Flow with ECID Generation and Propagation
ECID generation is available in OracleAS 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 OracleAS Web Cache now includes the ECID of the original request. This can be used to relate invalidations to original edits or personalizations.
Oracle Containers for J2EE (OC4J) can include the ECID with each log entry it writes, which can be useful for debugging purposes.
|
See Also: For more information about ECIDs and how they can help you to correlate messages from application server components, refer to the Oracle Application Server Administrator's Guide. |
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 K.1.19, "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:
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 forPlsqlBeforeProcedure 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:
Run the utltrace.sql script in the portal schema. The default portal schema name is portal.
|
Note: The scriptutltrace.sql is available in the Oracle_Home/portal/admin/plsql/wwc directory on the Oracle Application Server Repository Creation Assistant CD-ROM. This CD-ROM is part of the Oracle Application Server CD-ROM Pack from which you installed OracleAS Portal.
For OracleAS Portal 10.1.2.0.2, the source code of |
Create a new DAD, for example portal_trc. Refer to the Oracle Application Server mod_plsql User's Guide.
Click OK to go back to the PL/SQL properties for the HTTP Server.
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
Stop and start the HTTP Server and OC4J_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 11.2.1, "Checking the PlsqlSessionCookieName Value" for details about checking or updating the cookie name. |
Change the DAD in the OracleAS Portal URL to the new DAD that you defined in Step 2 and use this URL to access OracleAS 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.
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 10g documentation library.
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 K-1 describes different trace levels.
Table K-1 Trace Levels
| Level | Description |
|---|---|
|
|
Used to enable standard |
|
|
Used to enable standard |
|
|
Used to enable standard This is used mainly for identifying latch wait, but it can also be used to identify full table scans and index scans. |
|
|
Used to enable standard |
|
Note: When you set a database event, consider the following points:
|
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 10g documentation library.
The various OracleAS Portal components can have their diagnostic output configured. The following are the components:
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 K-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 K-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 application.log.
There are two types of JPDK messages:
Standard JPDK Messages
Performance JPDK Messages
Here is an example of a standard JPDK message that you might find in a Provider Adapter's application.log file:
03/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: 03/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 K-3.
Table K-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 |
Portal Services performance is logged through Oracle HTTP Server. The default directory for the error_log file is ORACLE_HOME/Apache/Apache/log on UNIX and ORACLE_HOME\Apache\Apache\log on Windows. Logging is controlled by the LogLevel parameter in the configuration file httpd.conf.
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
PPE servlet-level logging is controlled by the logmode servlet initialization argument. The values for logmode are the following:
none
perf
debug
request
content
parsing
all
The values build incrementally. For example, if logmode is set to content, then content, request, debug, and perf messages are also recorded. The default value is none. A value of all allows every logging message to be included.
As the PPE is a servlet, configuration varies with the Servlet container on which it is deployed. Under OracleAS Portal, the servlet container is OC4J and logmode can be found in the portal web.xml file. This XML file contains properties for more than just the PPE, and consequently, logmode can appear more than once. It is important to modify the correct logmode value.
The following can be found inside the page servlet clause:
<servlet>
<servlet-name>page</servlet-name>
<servlet-class>oracle.webdb.page.ParallelServlet</servlet-class>
.
.
.
<init-param>
<param-name>logmode</param-name>
<param-value>perf</param-value>
</init-param>
.
.
.
</servlet>
If the value of logmode is altered, then OC4J must be restarted for this change to take effect. The web.xml file can be found at:
ORACLE_HOME/j2ee/OC4J_Portal/applications/portal/portal/WEB-INF
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 K-4 lists the values for _debug.
Table K-4 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 |
|
3 |
Logs to page and sets the request log mode to |
|
4 |
Logs to page and sets the request log mode to |
|
5 |
Logs to page and sets the request log mode to |
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 logmode in the portal web.xml file:
<init-param>
<param-name>urlDebugMode</param-name>
<param-value>4</param-value>
</init-param>
The urlDebugMode argument can be found inside the page servlet clause:
<servlet>
<servlet-name>page</servlet-name>
<servlet-class>oracle.webdb.page.ParallelServlet</servlet-class>
.
.
.
<init-param>
<param-name>urlDebugMode</param-name>
<param-value>4</param-value>
</init-param>
.
.
.
</servlet>
Table K-5 lists the values for the urlDebugMode argument. The default value is 1.
Table K-5 PPE urlDebugMode Levels
| Value | Detail |
|---|---|
|
|
Ignore the |
|
|
Allow |
|
|
Allow |
|
|
Allow |
|
|
Allow |
|
|
Allow |
|
|
Allow |
PPE Log File Contents
PPE diagnostic messages are recorded in the servlet context application.log file. This file can be found at:
ORACLE_HOME/j2ee/OC4J_Portal/application-deployments/portal/<island>/application.log
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 K-6 provide details relating to some of these values.
Table K-6 PPE Standard Message Attributes
| Value | Detail |
|---|---|
|
|
Indicates that log mode is |
|
Active count |
Indicates the number of threads in the PPE thread group. If |
|
ECID |
Can be |
Performance PPE Messages
The following is an example of a performance PPE message found in the log file:
05/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
Oracle Application Server 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 K-2.
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 K-7.
Table K-7 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 K-3.
Figure K-3 Log Entries in the PDK Logging Page
OracleAS Metadata Repository consists of all the metadata, portal content, and PL/SQL code that reside in the OracleAS Portal database schema. The PL/SQL code that executes in the OracleAS Portal schema also generates diagnostics output that can be correlated with diagnostics output generated from the other components of OracleAS Portal.
Because the log file is produced by OracleAS Metadata Repository, the database running OracleAS 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 K-8 describes the parameters used in CREATE DIRECTORY syntax.
Table K-8 CREATE DIRECTORY Parameters
| Semantics | Description |
|---|---|
|
|
Specify Existing users with privileges to access a redefined directory can to access the directory without being granted the privileges again. |
|
|
Specify the name of the directory object to be created. The maximum length of the 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. |
|
|
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 10g 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 OracleAS Metadata Repository, if the database you are installing into has theUTL_FILE_DIR parameter set, then the OracleAS Portal installer configures OracleAS Metadata Repository such that it uses the first directory defined by the database parameter as the location for the OracleAS Metadata Repository log file. If the UTL_FILE_DIR directory is not configured, then OracleAS Metadata Repository logging is not set up on installation.
|
OracleAS 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_HOME/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 K-9 details the logcfg.sql parameters.
Table K-9 Repository Logging Package Parameters
| Parameter | Detail |
|---|---|
|
|
Describes the level of messages recorded. The values are the following:
The values build incrementally. The default value is |
|
|
Describes the level of messages for which state information will automatically be logged. The values are the following:
The values build incrementally. |
|
|
Describes the format of automatically recorded context information, which is different from state information. The values are the following:
|
|
|
Specifies the name of the log file to write to. An attempt is made to create this file if it does not already exist. |
|
|
Specifies the directory in which the 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, |
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 OracleAS Metadata Repository diagnostics log file, run the SQL script logtrunc.sql located at: ORACLE_HOME/portal/admin/plsql/wwc
Repository Log File Contents
The location of the OracleAS 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 OracleAS Metadata Repository log file:
[06-AUG-2002 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-2002 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-2002 15:02:15: Date and time
ERROR: Message level
ctx=wwsrc_simple_edit.render_simple_edit_prefs: Message context
Table K-10 provides additional details relating to some of these values.
Table K-10 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 OracleAS 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 10g 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 K.2.4, "Using Application Server Control Console 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 10g. To do this, edit the following file:
ORACLE_HOME/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 OracleAS Portal target in Oracle Enterprise Manager 10g, if it is defined. If there is no corresponding OracleAS Portal target in Oracle Enterprise Manager 10g, then use the name of the OracleAS 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 OracleAS 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 OracleAS 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 10g Application Server Control Console instances that is monitoring an OracleAS Portal middle tier.
If the OracleAS Portal database is on a computer other than the OracleAS 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 10g instance monitoring an OracleAS Portal middle tier.
|
Note: . Using Oracle Enterprise Manager 10g, you have to update the location of the Repository Diagnostics log file in thePORTAL.xml file located at ORACLE_HOME/diagnostics/config/registration/.
|
Oracle Application Server 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_HOME/webcache/logs on UNIX and ORACLE_HOME\webcache\logs on Windows.
You can use Oracle Enterprise Manager 10g Application Server Control Console to view and query entries from the following Oracle Application Server log files. This helps you to diagnose issues relating to OracleAS Portal. The relevant Oracle Application Server 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 OracleAS 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.
OC4J_Portal: Displays multiple application log files named application.log. This log file contains all relevant PPE logging information.
JPDK: Displays the location j2ee/home/application-deployments/jpdk/application.log for the JPDK sample providers in a standalone OC4J. In an Oracle Application Server middle tier, the location is similar to the addition of a directory for the default island.
Web Cache: Displays error and access log file names event_log and access_log.
Before you can use the OracleAS Metadata Repository log file with Application Server Control Console Log Viewer, you must complete a registration process. Refer to the section "Repository Diagnostics Log File Registration" for instructions.
If your JPDK OC4J instance is not located in the OracleAS Portal middle tier Oracle home, then you may view its log file only through the local Application Server Control Console instance. If you want to perform diagnostic correlation, then you must follow a similar remote registration process to that described for the OracleAS Metadata Repository log file when it is remotely located.
In addition to viewing the log file entries with Application Server Control Console Log Viewer, you can also perform advanced diagnostics by correlating entries across log files using the ECID value. See Section K.2.1, "Enabling ECID Logging" for more information. This drill-down correlation is automatically provided by the Application Server Control Console Log Viewer.
To view log file entries, click Logs in Application Server Control Console, which is located at the top and bottom of every Application Server Control Console component home page.
|
See Also: For detailed instructions on how to use the Log Viewer, refer to the Oracle Application Server Administrator's Guide. It describes how to perform advanced queries for diagnostic log file information, search through diagnostic messages (collected from selected Oracle Application Server components) in the Log Repository, and correlate messages across log files and components. |
Figure K-4 shows an example of Oracle Application Server components selected in the View Logs page.
Figure K-4 Application Server Control Console View Logs Page
Use OracleAS Portal Diagnostics Assistant to gather information if you are troubleshooting issues after OracleAS Portal installation. Problems can vary from accessing the OracleAS Portal, to users getting errors at different levels within OracleAS Portal.
You can diagnose issues by reviewing the results from OracleAS 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 OracleAS Portal Diagnostics Assistant)
OracleAS 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 OracleAS Portal-related configuration files and log files are collected and zipped for your convenience.
To run OracleAS 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 OracleAS Portal Diagnostics Assistant zip file. The directory names have a timestamp format, for example, 040623132344 which means:
After running OracleAS 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 OracleAS Portal Diagnostics Assistant and the information collected, refer to the readme file located in the directory in which you downloaded OracleAS Portal Diagnostics Assistant.
Running OracleAS Portal Diagnostics Assistant
To generate diagnostics information using OracleAS Portal Diagnostics Assistant, perform the following steps:
Check the Support and Metalink section on OTN for the latest update/patch information for OracleAS Portal Diagnostics Assistant at:
http://www.oracle.com/technology/
Download the latest OracleAS Portal Diagnostics Assistant script. Support/Upgrade is located in the Product Information section.
Ensure that the ORACLE_HOME environment variable is set to the correct OracleAS Portal middle tier Oracle home directory.
If you try to run OracleAS Portal Diagnostics Assistant from a database Oracle home directory, it fails and no diagnostics information is collected.
Navigate to the location where you downloaded and unzipped OracleAS Portal Diagnostics Assistant.
Run OracleAS 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 K-11 lists and describes the parameters used with the OracleAS Portal Diagnostics Assistant script.
Table K-11 OracleAS Portal Diagnostics Assistant Script Parameters
| Parameter | Description |
|---|---|
|
-schema |
Name of the OracleAS Portal schema. This parameter is mandatory. Default = |
|
-password |
Password for the OracleAS Portal schema. This parameter is mandatory. Default = |
|
-connect |
Connect string for the OracleAS Portal schema. Use the format |
|
-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 |
|
-apacheLogDir |
Directory for Oracle HTTP Server error log file. This parameter is optional. Default = |
|
-apacheLogName |
Error log file name. This parameter is optional. Default = |
|
-logFileLimit |
The number of rows in the error log file. This parameter is optional. Default = |
|
-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 |
The following is an example of running OracleAS Portal Diagnostics Assistant on a Unix platform:
# Set the environment # setenv ORACLE_HOME /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 OracleAS Portal Diagnostics Assistant on Windows as follows:
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 K-11 lists and describes the parameters used with the OracleAS Portal Diagnostics Assistant script.
Open the latest HTML report (pda.htm) in a browser window and use the information to help diagnose any OracleAS Portal issues.
When troubleshooting OracleAS Portal, one of the first things to do is to review the contents of the Portal Dependency Settings file called iasconfig.xml. This file stores configuration data from all the dependent components in a central place, and the contents of this file are updated when there are configuration changes. Therefore, the file should reflect the current configuration of OracleAS Portal with OracleAS Web Cache, Oracle Internet Directory, and Oracle Enterprise Manager 10g. If the file does not accurately reflect your configuration settings, then you must update the file and run the Portal Dependency Settings tool ptlconfig to update OracleAS Metadata Repository.
Refer to Appendix A, "Using the Portal Dependency Settings Tool and File" for more information about the Portal Dependency Settings file, and examples of the iasconfig.xml file.
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 OracleAS Portal.
Using the _debug parameter
All OracleAS 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 C.7, "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 OracleAS Portal refers to an OracleAS Wireless service and not OracleAS 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:
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
Request the new service not the default portal service in the mobile device.
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 K.1.22, "Problems in Accessing OracleAS 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:
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?
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?
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.
Is there a record for the problem in any of the log files listed in Table K-12?
Table K-12 Error Log Files and Locations
| Log Files | Location |
|---|---|
|
OracleAS Wireless Server log files |
Server JVM standard output:
Provider JVM standard output:
|
|
Oracle HTTP Server log files |
|
|
Parallel Page Engine Server log file |
|
You can find more solutions on Oracle MetaLink at
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:
Run OracleAS Portal Diagnostics Assistant.
You can diagnose portal-related issues by reviewing the report generated by OracleAS Portal Diagnostics Assistant. You can also refer to Section K.2.5, "Using OracleAS Portal Diagnostics Assistant" for more information.
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 OracleAS 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 Application Server components are configured.
|
See Also:
|
