|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.2) Part No. B14037-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.2) Part No. B14037-01 |
|
|
Previous |
Next |
This appendix describes common problems that you might encounter when using OracleAS 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 Show Up
You cannot access your portal instance. For example, pages are not displayed, or you get an "HTTP 503 Service Unavailable" error when you try to access OracleAS Portal.
OracleAS Portal requires Oracle Application Server components, such as Oracle HTTP Server, OracleAS Web Cache, mod_plsql, OracleAS Metadata Repository, and OC4J_Portal to be up and running. One or more of these components may be down.
Problem 1
Oracle HTTP Server is down.
Solution 1
Display the portal's target page in the Application Server Control Console. See Section 7.2, "Using the Application Server Control Console".
Check if Oracle HTTP Server is up. The Oracle HTTP Server status is displayed in the portal's Component Status table.
If 'Up', continue to next step
If 'Down', 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 the HTTP Server link in the:
Portal's Component Status table, or
Application Server's Component table.
If Oracle HTTP Server starts successfully, see if your portal is now accessible.
If Oracle HTTP Server fails to start, investigate the Oracle HTTP Server error log files and try to determine the problem. See Section K.2.3, "Using Application Server Control Console Log Viewer". If you are not using Log Viewer, 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 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 Oracle Application Server page's Component Status table.
If 'Up', continue to next step.
If 'Down', 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 the Web Cache link in the Application Server's Component table.
If OracleAS Web Cache starts successfully, see if your portal is now accessible.
If OracleAS Web Cache fails to start, investigate the OracleAS Web Cache error log files and try to determine the problem. See Section K.2.3, "Using Application Server Control Console Log Viewer". If you are not using Log Viewer, check the relevant error log files in ORACLE_HOME/opmn/logs and ORACLE_HOME/webcache/logs.
Problem 3
The mod_plsql service is not running.
Solution 3
Display the portal's target page in the Application Server Control Console. See Section 7.2, "Using the Application Server Control Console".
Check the status and configuration of the portal DAD using the DADs table, displayed on the mod_plsql Services page. Click the mod_plsql Services link in the portal's Component Status table to access this page. See also Section 4.5.3, "Configuring a Portal DAD".
If 'Up', continue to next step.
If 'Down', click the name of the DAD in the DADs table and verify that all properties are set correctly. Save any changes and restart Oracle HTTP Server for any change to take effect.
|
Note: The connection details can be verified by using SQL*Plus in theORACLE_HOME associated with the Oracle Application Server target you navigated to, from the mod_plsql DAD wizard. The DAD wizard displays the password in an encrypted form, forcing you to re-enter the password, thereby ensuring this is not the problem.
|
Check if your portal is now accessible.
Problem 4
OracleAS Metadata Repository is down.
Solution 4
Display the portal's target page in the Application Server Control Console. See Section 7.2, "Using the Application Server Control Console".
Look under the section 'OracleAS Metadata Repository Used By Portal'.
If 'Up', continue to next step
If 'Down', start the database
If the database starts successfully, see if your portal is now accessible.
Problem 5
The OC4J_Portal service is down.
Solution 5
Display the portal's target page in the Application Server Control Console. See Section 7.2, "Using the Application Server Control Console".
The OC4J_Portal status is displayed in the portal's Component Status table.
If 'Up', continue to next step.
If 'Down', start OC4J_Portal using the Application Server Control Console.
To access OC4J_Portal monitoring and administration pages in the Application Server Control Console, click the OC4J_Portal link in the:
Parallel Page Engine Services page (available from the portal's Component Status table), or
Application Server's Component table.
If OC4J_Portal starts successfully, see if your portal is now accessible.
If OC4J_Portal fails to start, investigate OC4J_Portal error log files and try to determine the problem. See Section K.2.3, "Using Application Server Control Console Log Viewer".
For additional analysis, you can also review metric information for OC4J in the Oracle Enterprise Manager 10g Grid Control Console, by clicking the All Metrics link in the OracleAS Single Sign-On target page.
Problem 6
SQL* Net Listener is down, or misconfigured.
Solution 6
Check that the SQL*NET TNS listener, on the host where the Metadata repository is installed, is up and running. Log in to the machine containing the Database, change to ORACLE_HOME/bin, if currently not in the $PATH, and execute the following to determine the status of the TNS listener:
lsnrctl status
If the service is not running, start it using:
lsnrctl start
If the service is already up and running, 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.
You are able to access the public home page, but unable to log in. Common symptoms of this problem are:
The login page does not appear after you click the login button.
You get an error after entering your credentials on the OracleAS Single Sign-On login page.
You get errors on OracleAS Portal pages after you have been successfully authenticated.
Problem
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 process of logging in to OracleAS Portal can be logically broken down into three distinct parts:
Communication between OracleAS Portal and OracleAS Single Sign-On
Communication between OracleAS Portal and Oracle Internet Directory
Assignment of the Home Page
Solution
To help diagnose the cause of this problem, we will look at solution areas centred around each part of the login process.
OracleAS Portal to OracleAS Single Sign-On and Back
To understand the first part of the process of logging in to OracleAS Portal, let us assume that OracleAS Portal is accessed at the URL http://www.company.com/pls/portal/. If you click Login on the public home page, you get redirected to the OracleAS Single Sign-On page. The URL will change to, for example, http://login.company.com:4443/pls/orasso. If you enter the username and password, provided by your administrator, and click Login, OracleAS Single Sign-On sends the user information back to OracleAS Portal.
To help diagnose the cause of the problem, encountered in the first part of the login process, follow these steps:
Display the OracleAS Single Sign-On's target page in the Oracle Enterprise Manager 10g Application Server Control Console. The OracleAS Single Sign-On target is displayed in the target page for the Infrastructure Home's instance.
See 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 the HTTP Server link, displayed in the Related Links section.
If 'Up', continue to next step.
If 'Down', start Oracle HTTP Server using the Application Server Control Console, or the command line.
To access Oracle HTTP Server monitoring and administration pages in the Application Server Control Console, click the HTTP Server link in the:
OracleAS Single Sign-On target page, or
Application Server's Component table.
If Oracle HTTP Server starts successfully, see if you can now log in.
If Oracle HTTP Server fails to start, investigate the Oracle HTTP Server error log files and try to determine the problem. See Section K.2.3, "Using Application Server Control Console Log Viewer". If you are not using Log Viewer, 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.
Check the DAD status by performing the following steps:
Navigate to the Application Server Control Console.
Typically, http://<host>.<domain.com>:1812. For more information, see Section 7.2, "Using the Application Server Control Console".
Navigate to the Application Server instance where you would like to check the DAD status and properties.
Select HTTP Server from the System Components table.
Click Administration.
Click PL/SQL Properties.
If 'Up', continue to next step.
If 'Down', click the name of the DAD in the DADs table and verify that all properties are set correctly. Save any changes and restart Oracle HTTP Server for any change to take effect.
Check if you can now log in.
Check if the database containing the OracleAS Single Sign-On schema is running.
Database information is displayed on the OracleAS Single Sign-On's target page in the Oracle Enterprise Manager 10g Application Server Control Console. Drill down for further information.
If 'Up', continue to next step
If 'Down', start the database
If the database starts successfully, see if your OracleAS Single Sign-On is now accessible.
Check the status and configuration of the SQL* Net Listener.
Check that the SQL*NET TNS listener, on the host where the Identity Management repository is installed, is up and running. Log in to the machine containing the Database, change to ORACLE_HOME/bin, if currently not in the $PATH, and execute the following to determine the status of the TNS listener:
lsnrctl status
If the service is not running, start it using:
lsnrctl start
If the service is already up and running, refer to the Oracle Database Net Services Administrator's Guide in the Oracle Database 10g documentation library, for the specific error number returned, and take suitable action.
Check if the OC4J_Security service is up.
The OC4J_Security status is displayed in the Application Server Control Console.
If 'Up', continue to next step.
If 'Down', start OC4J_Security using the Application Server Control Console, or the command line.
To access OC4J_Security monitoring and administration pages in the Application Server Control Console, click the OC4J_Security link in the Application Server's Component table.
If OC4J_Security starts successfully, see if your OracleAS Single Sign-On is now accessible.
If OC4J_Security fails to start, investigate OC4J_Security error log files and try to determine the problem. See Section K.2.3, "Using Application Server Control Console Log Viewer".
Check the OracleAS Portal and OracleAS Single Sign-On connection configuration
Check the connection configuration of OracleAS Portal and OracleAS Single Sign-On. There can be a problem with the connection configuration, if you see any of the error messages listed subsequently:
"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, fix the Host in the IASInstance element and ListenPort in the WebCacheComponent element in iasconfig.xml and run the ptlconfig tool as follows:
ptlconfig -dad <dad name> -site
For additional analysis, you can also review metric information for OracleAS Single Sign-On in the Oracle Enterprise Manager 10g Grid Control Console, by clicking the All Metrics link in the OracleAS Single Sign-On target page.
OracleAS Portal to Oracle Internet Directory and Back
After the steps listed in the section "OracleAS Portal to OracleAS Single Sign-On and Back", in the second part of the process of logging in to OracleAS Portal, 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 cause of problems encountered in the second part of the login process, you need to check if Oracle Internet Directory service is up. Oracle Internet Directory status is displayed in Application Server's page.
If 'Up', continue to next step.
If 'Down', start Oracle Internet Directory using the Application Server Control Console, or the command line.
To access Oracle Internet Directory monitoring and administration pages in the Application Server Control Console, click the OID link in the Application Server's Component table.
If Oracle Internet Directory starts successfully, see if you can now log in.
If Oracle Internet Directory fails to start, investigate the Oracle Internet Directory error log files and try to determine the problem. See Section K.2.3, "Using Application Server Control Console Log Viewer". 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 iasconfig.xml and run the ptlconfig tool as follows:
ptlconfig -dad <dad> -oid
Assignment of the Home Page
After the steps listed in the section "OracleAS Portal to Oracle Internet Directory and Back", in the third part of the process of logging in to OracleAS Portal, the user is redirected to the appropriate home page based on their group membership. The home page preference can be set at the System, Group or User level. If a home page has been specified for an user, that home page is rendered when the user logs in. If no home page has been specified for the user, but the user has a default group, and a home page has been specified for the user's default group then that page is rendered. If no home page has been specified at the user level and the user either does not have a default group or no home page has been specified for the default group, then the system level default home page is rendered.
To help diagnose the cause of the problem, check if you have VIEW privileges for the home page, at the User or Group or System level.
When a home page is being rendered, the user must have privilege to view the page. The privilege can be granted to one of the following:
the user
a group that the user is a member of
public
If the user does not have privilege to view the page through one of the options in the preceding list, they will receive error "WWC-44131: You do not have permission to perform this operation."
At the Group or System level, verify with an administrator that the group you are part of has appropriate privileges to view the page.
A Portal administrator should use the following steps to determine what the user's home page is:
Edit the user's profile to find out the default home page and the default group for the user.
If a default home page has been specified for the user then stop here. Otherwise, edit the group profile for the default group and check if a default home page has been 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 for the user has been established, the next step is to find out what privileges have been granted on the page. Edit the page and click the access link. Check whether or not the page can be viewed by public. Also, 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, make sure that the name of the user appears in the list of members.
Oracle Enterprise Manager, authentication, caching, or URLs are not working correctly with OracleAS Portal.
Problem
OracleAS Portal is not configured correctly to connect to the other Oracle Application Server components. The iasconfig.xml file does not have the correct information for connecting to other Oracle Application Server components.
Solution
For details on verifying the contents of the Portal Dependency Settings file, iasconfig.xml, see Section K.2.5, "Verifying the Portal Dependency Settings File".
When you create category/perspective pages, you see any one of these 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/perspective templates, you may see one of the preceding messages when you create a new category/perspective:
Solution
If either of these errors is displayed, you must first delete the current category/perspective template and then run scripts to:
Replace the current category/perspective template with the original version.
Re-create category/perspective pages that are based on current template. You can do this either across all page groups, or for specific page groups.
This ensures that all new category/perspective pages are created without errors and that all existing category/perspective pages display their associated items and pages as expected.
For more information on where to look for these scripts, and how to run them, see Section C.10, "Using the Category and Perspective 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 bounce back rule is not set up correctly on the LBR when configuring multiple middle-tiers, the response to loopback requests will be dropped causing OracleAS Portal pages to time out.
Solution
NAT bounce back is set up differently on individual LBRs. Consult your LBR's configuration guide on how to set this up. For a detailed description on why the LBR needs additional configuration to make loopback communication successful, refer to Section 5.3, "Configuring Multiple Middle-Tiers with a Load Balancing Router".
User and Group information in OracleAS Portal appears to be out of sync 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
Follow these 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 directory synchronization should be enabled. Enable directory Synchronization should be checked, and by default Send event notifications every n seconds will be set to 300.
If the Directory Synchronization section is not visible or the check box against Enable directory Synchronization is not checked, then the provisioning profile is not enabled. Enable the provisioning profile by checking the check box Enable Directory Synchronization and then clicking on OK or Apply.
If you encounter an error, you must re-create the provisioning profile. The solution is to run ptlconfig as follows:
ptlconfig -dad <dad> -dipreg
Check if Oracle Directory Integration Platform is up and running.
Perform the following steps to check if Oracle Directory Integration Platform is up and running:
Display the portal's target page in 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 associated with your portal.
Oracle Internet Directory status is displayed in Application Server's page.
If 'Up', continue to next step
If 'Down', start Oracle Internet Directory using the Application Server Control Console.
To access the Oracle Internet Directory monitoring and administration pages in the Application Server Control Console, click the OID link in the Application Server's Component table.
If Oracle Internet Directory starts successfully, continue to next step.
If Oracle Internet Directory fails to start, investigate Oracle Internet Directory error log files and try to determine the problem. See Section K.2.3, "Using Application Server Control Console Log Viewer".
Check if the Oracle Directory Integration Platform is up.
Click the OID link in the Application Server's Component table. On the page that follows, click the Directory Integration link, displayed in the Status section
If 'Up', continue to next step.
If 'Down', start the Oracle Directory Integration Platform Server using the 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 the trace and audit log files:
Log in to the machine that has the Oracle Directory Integration Platform Server running.
Typically, the machine that has Oracle Internet Directory installed has the Oracle Directory Integration Platform Server.
Check for the Trace and Audit Log Files.
Navigate to ORACLE_HOME/ldap/odi/log/directory
For each provisioning profile, there are two associated files in the log directory: *.trc (trace) and *.aud (audit) files.
By default, the trace file will have entries that are generated every 300 seconds, because the default value for Send event notifications every n seconds is 300. It contains the log of recent information logged by the Oracle Directory Integration Platform and also contains any errors that may have been encountered. The trace file gets recycled after some time.
The audit file contains a history of all the changes that have been propagated to the provisioning profile.
Here is an example of a message found in the audit 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=company,dc=com ,GUID (CE0D473B93B521FAE0340003BA109AC2) - Response : 1=============Event ID : 2320 - (GROUP_MODIFY)=============Source : orclapplicationcommonname= ASDB.COMPANY.COM,cn=database instances,cn=ultrasearch,cn=portal,cn=products,cn=oraclecontextTime : 20031209170036zObject Name: super_usersObject GUID: CE0D473B93B521FAE0340003BA109AC2Object DN : cn=super_users,cn= ASDB.COMPANY.COM,cn=Database Instances,cn=UltraSearch,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=company,dc=comAttrName - OpType - Value-------------------------------------------uniquemember - ADD - cn=portal,cn=users,dc=us,dc=company,dc=comEVENT_NTFY Response : 12320 : Success : 2 : cn=super_users,cn= ASDB.COMPANY.COM,cn=Database Instances,cn=UltraSearch,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=company,dc=com-----------------------------------------------------
The propagation information gets written to the trace files, and is periodically added to the audit files. If changes are propagated properly, the timestamp in the trace file will have been updated:
If changes are propagated properly, but are not reflected in OracleAS Portal, continue to the section "Are Changes Propagated Properly?"
If you do not find the trace and audit log files, 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 enables you to indicate whether directory synchronization is enabled. Enable directory Synchronization should be checked, and Send event notifications every 300 seconds set by default.
If these values are not set, you must create a provisioning profile, as detailed in the following section.
In the event that you do not find the trace and audit log files in the ORACLE_HOME/ldap/odi/log/ directory, chances are that the provisioning profile has been deleted. To re-create a provisioning profile, run ptlconfig as follows:
ptlconfig -dad <dad> -dipreg
Are Changes Propagated Properly?
Follow these steps to help diagnose whether changes are propagated properly:
Create, delete, and re-create a user through Portal (in Oracle Internet Directory). To do this, perform the following steps:
Click the Administer tab.
Click the Create New Users link, under User
Edit the User's profile
Delete the User.
Re-create the User using 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 <300 seconds. After this login as the newly created user. If you receive 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, which must be resolved before you can log on with this name. Please inform your administrator.", while logging in, propagation is not working. If nothing has been propagated, OracleAS Portal will throw this error because it has the same username, with a different GUID, stored.
If changes are not propagated properly, then it is likely that there is a problem in either Oracle Directory Integration Platform or OracleAS Portal configuration with Oracle Directory Integration Platform. If it is an OracleAS Portal configuration problem, run ptlconfig as follows:
ptlconfig -dad <dad> -dipreg
Sometimes, you will experience performance issues with OracleAS Portal. Typically, pages will 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.
Ensure that the PlsqlCacheDirectory parameter is not misconfigured in the ORACLE_HOME/Apache/modplsql/conf/cache.conf file.
Ensure that the MID_TIER_ORACLE_HOME/lib/libwwjcache.so file is not missing.
Problem 2
Oracle Application Server Containers for J2EE unable to handle load.
Solution 2
If you are getting repeated error messages like the example shown next, it is possible that the load being experienced by OC4J_Portal is exceeding 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 content-fetcher12 shut down. at orac content-fetcher12 shut down. at oracle.webdb.page.ContentFetcher.run(Unknown Source)
Upgrade your hardware suitably, to handle load by doing any or all of the following:
Additional hardware or LBR: For details, refer to the white paper titled "How To Effectively Size Hardware for Your Portal Implementation" located on Oracle Technology Network, http://www.oracle.com/technology/products/ias/portal/administration.html.
Removing -xingc: this was 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 occur when –mx (maximum heap size) is reached, and does not necessarily require -xingc. By removing -xingc , you will not see regular CPU spikes that occurs 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, garbage collection will occur at the time that –mx is reached.
Increasing –ms & -mx: these are initial (ms) and maximum (mx) heap sizes specified for each instance of OC4J_Portal, usually specified in Mb.
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. This can be set in Oracle Enterprise Manager by viewing the advanced properties for the instance, and setting it to a number greater than 1. Prior to Oracle9iAS Portal (9.0.4), this could also be set by editing the application configuration file where the default instances of the numProcs setting is stored.
The numprocs setting provides an element of scalability and redundancy. The Parallel Page Engine (PPE) has a concept of fetcher threads internally, 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. In a high load situation when no threads are available, the incoming requests will be queued. This can be alleviated by increasing the fetcher threads number in the PPE configuration file. While this will provide you with an increased number of available threads, there will be no redundancy.
By setting numProcs to 2 you will have two instances of OC4J_Portal and therefore 2*25 fetcher threads. If one of the instances should fail for any reason, you will still have 25 threads, while OPMN restarts the instance that has died.
Problem 3
Low or no reuse of connection pool.
Solution 3
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 so will disable connection pooling.
Problem 4
Processes start up or shut down frequently.
Solution 4
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: It is important to note that tuning of both theMaxSpareServers and MinSpareServers parameters should only be necessary on very busy sites. Setting this parameter to a large number is almost always a bad idea. For more information refer to the Oracle HTTP Server Administrator's Guide
|
Problem 5
Disk I/O not distributed.
Solution 5
Many components access disks all the time, such as:
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 I/O bottlenecks, ensure that you have a good distribution across physical disks.
Problem 6
Too many network hops. Typical problems can be:
PPE loopbacks are not configured on clustered Oracle HTTP Server environments.
Servlet engine (Oracle Application Server Containers for J2EE) are running on a machine other than Oracle HTTP Server/mod_oc4j.
Infrastructure components are running across wide networks with multiple routers.
Solution 6
Try to reduce the number of network hops by avoiding or working around the listed problems.
Problem 7
Use of 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 7
Avoid the unnecessary use of HTTPS. HTTP will work well in most cases. If you really need an HTTPS environment, use reverse proxy hardware that will manage HTTPS and SSL. For more information, see Section 6.3.2.1, "Configuring SSL for OracleAS Portal" and Section 5.6, "Configuring Reverse Proxy Servers".
Problem 8
After performing all the tasks in the solutions provided, OracleAS Portal is still slow.
Solution 8
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, the next step is to review metric information in the Oracle Enterprise Manager 10g Grid Control Console. Reviewing this information can help you identify the problem.
Click the All Metrics link in the portal's target page to review metric information. Repeat this on target pages for other relevant components (OracleAS Web Cache, Oracle HTTP Server, OC4J, mod_plsql, and so on).
Run the OracleAS Portal Diagnostic Assistant.
You can diagnose portal-related issues by reviewing the report generated from the OracleAS Portal Diagnostic Assistant. See also Section K.2.4, "Using the OracleAS Portal Diagnostics Assistant".
|
See Also:
|
When you try to create Web folders in OracleAS Portal, you get an ORA-20504 error, in the Web server's error log file.
Problem
The tables wwdav$path and wwdav$asl 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 will no longer appear in DAV until they are accepted or rejected.
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, request the administrator to grant you the appropriate privileges. However, if you can successfully perform these operations from the Self-Service Console, then it is most likely related to the subsequent 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 the Oracle Internet Directory is not up and running, follow these steps to help diagnose the cause of this problem:
Display the portal's target page in the Oracle Enterprise Manager 10g Application Server Control Console. See Section 7.2, "Using the Application Server Control Console". Navigate to the Application Server Control Console of the Infrastructure home associated with your portal.
Check if Oracle Internet Directory is up.
Oracle Internet Directory status is displayed in the application Server's page.
If 'Up', continue to next step.
If 'Down', start Oracle Internet Directory using the Application Server Control Console, or the command line.
To access Oracle Internet Directory monitoring and administration pages in the Application Server Control Console, click the Oracle Internet Directory link in the Application Server's Component table.
If Oracle Internet Directory starts successfully, see if the Create New Users and Create New Groups portlets are displayed.
If Oracle Internet Directory fails to start, investigate Oracle Internet Directory error log files and try to determine the problem. See Section K.2.3, "Using Application Server Control Console Log Viewer".
Problem 3
OracleAS Portal and Oracle Internet Directory connection configuration is incorrect.
Solution 3
Fix the values in the OIDComponent element in iasconfig.xml and use ptlconfig 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 the preceding seeded entries, 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 these errors in the error_log file, located in the directory, MID_TIER_ORACLE_HOME/Apache/Apache/logs: ORA-20000, ORA-20001, ORA-20005, ORA-20006.
|
Note: It is important to understand that some of these errors are expected. Report the problem to Oracle support, only if an unusual number of exceptions are encountered. See Section K.3, "Need More Help?"for more information. |
ORA-20000: The ORA-20000 "An attempt was made to access the session context without a valid session" error denotes that the OracleAS Portal session associated with that particular browser session is missing, or that the session cookie itself is missing.
ORA-20001: The ORA-20001 "The session cookie is corrupt - unable to obtain session information. Please close your browser and reconnect." error indicates that a corrupt or otherwise invalid session cookie.
ORA-20005: The ORA-20005 "The session context could not be restored because the session is marked as inactive" 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 ORA-20006 "The session context could not be restored because the cookie value does not match the value stored in the session repository" error indicates that there is a mismatch between the cookie sent by the browser and the cookie stored in the session.
The following is a discussion about each of the errors listed in the preceding text:
ORA-20000 "An attempt was made to access the session context without a valid session"
The ORA-20000 error can be caused by any of the following problems:
Session Row is Missing
Each session cookie has a corresponding session stored in the OracleAS Portal repository that contains information about the session cookie's corresponding session. The data stored in the session includes the session ID, username, session start time, 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 OracleAS Portal repository.
Session Has Been Cleaned Up
A background job runs frequently to cleanup old sessions from the OracleAS Portal repository. By default, this job is configured to cleanup sessions that are older than 7 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 more details.
Session Cookie is Missing
If there is more than one DAD configured for use with an OracleAS Portal repository, and the cookie name specified in those DADs is not the same, 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:
The Cookie Has Been Truncated
If the user clicks the Stop button on the browser during the transmission of the request, the cookie may be truncated. The next time the user accesses the browser, the server is unable to properly decrypt the cookie. This may also happen if an older version of modplsql is in use. Older versions of mod_plsql did not handle a large enough buffer size for receiving the request.
Cookie from Another Server is Received
If the user has recently accessed another OracleAS Portal, configured with a domain-wide cookie scope, then an ORA-20001 error may be raised. If the cookie name of that Portal is the same as your Portal's cookie name, then OracleAS Portal will try to use that cookie. However, since each Portal's cookies are encrypted using Portal-specific keys, it will not be able to decrypt the cookie, and will raise an ORA-20001 assuming that the cookie is corrupted.
To avoid this namespace collision issue, you will need to determine from where you are obtaining the 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 from where the cookies are obtained.
Cookie Encryption Key Was Changed
The cookies are encrypted using DES3 encryption. The encryption key is stored in the OracleAS Portal repository. Its value is typically set during OracleAS Portal installation and does not change thereafter. If this value is changed after installation, it will not be 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 the user made a logout request, but another request (for example, the 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 a user logs out, it is possible that the session stored in the OracleAS Portal repository gets updated to an inactive state. However, if you click the browser's Stop button, the cookie does not get cleared from the user's browser. If this happens, the browser will send the old cookie, causing OracleAS Portal to try to locate the inactive session. When this happens, an ORA-20000 will be 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, but 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.
Timestamp Does Not Match
The cookie may be decrypted properly, but if the timestamp in the cookie does not match the timestamp in the associated session row, it is considered to be corrupt. This mismatch in timestamp may occur if the user invokes the login twice, if there are network configuration issues, or bugs in the session creation logic, or by a malicious session attack.
A remote Web provider that is located on a different machine from OracleAS Portal's Application Server middle-tier, works when the OC4J_Portal service is first started, but stops working after some time. After a long timeout, the message Error: the portlet could not be contacted is shown in the place of each portlet from the same provider. Portlet timeout errors are also found in the OC4J_Portal application.log. 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's domain name resolves to, changes over time. Java's default caching policy caches IP addresses forever, once it has resolved them, which means it keeps using an outdated IP address of the Web provider if the IP address of the Web provider has changed because it is using 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, the sun.net.inetaddr.ttl system property can be used to specify the "time to live" (TTL) in seconds for cached IP addresses.
|
Note: It is important that this system property is passed as a command line option to Oracle Application Server Containers for J2EE (OC4J). Setting the property inoc4j.properties will 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 ORACLE_HOME/opmn/conf/opmn.xml.
|
Usage Example
Edit opmn.xml as follows:
<java-option value="-server -Xincgc -Xnoclassgc -Xms256m -Xmx512m -Dsun.net.inetaddr.ttl=120"/>
Shut down opmn and all its sub-processes 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 MB. This can cause problems if you are performing memory intense operations such as:
Export/Import
Creating Portal Forms/Reports
Solution
To facilitate memory intense operations, you must increase the value of the shared_pool_size parameter.
To change the value of the shared_pool_size parameter:
Edit the shared_pool_size parameter in the init.ora file for the database instance. The init.ora file can be found in your database's ORACLE_HOME.
|
Note: This can be done only after the Infrastructure database is installed. |
Increase the value depending on your configuration.
Restart the database for the changes to reflect.
|
Note: As an optional step, it is suggested that you run the OracleAS Portal Diagnostic Assistant to view a report of the existing and recommended values of the database. See "Running the OracleAS Portal Diagnostic Assistant" for more details. |
You are facing issues with the installation of Oracle Text.
Problem
Experiencing Oracle Text-related problems.
Solution
Use the TEXTTEST utility to check that Oracle Text functionality is installed and setup correctly. See Appendix H, "Using TEXTTEST to Check Oracle Text Installation".
When trying to create Oracle Text indexes, you see any of the following errors:
Cannot grant CTXAPP Role to portal
ERROR: Creating datastore procedures in CTXSYS
ERROR: Setting up Oracle Text data stores
An unexpected error has occurred (WWS-32100)
Problem
Experiencing problems when trying to create Oracle Text indexes.
Solution
Oracle Text must be installed in the same Oracle home as the OracleAS Portal Repository database. See Section 8.3.2, "Oracle Text Prerequisites", for more details.
Choose one of the following options to resolve this issue:
Access the database server and log in as the OracleAS Portal schema owner. Start SQL*Plus and execute the inctxgrn.sql script. This script is located in ORACLE_HOME\portal\admin\plsql\wws. Running this script creates the Oracle Text datastore procedures and also grants the CTXAPP role to the OracleAS Portal schema.
If you have access to the database server, but you do not have a copy of the sbrimtlx.sql script, connect to the database, using SQL*Plus 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.
For more information, refer to Appendix H, "Using TEXTTEST to Check Oracle Text Installation".
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 behavior.
When choosing an image for a search form (Custom Search Portlet: Edit Defaults: Search Form tab), you see the error "Item %1 from page group %2 is not a valid image. (WWS-30071)".
Problem
The image you selected belongs to a page group with an underscore in its name. For example, 'my_pagegroup'.
Solution
Move the required image into a page group which does not have an underscore in its name.
When you enclose a search term or phrase with double quotes, such as "find my search term", no search results are returned.
Problem
You should not use double quotes (") when entering search terms, or searching for phrases.
Solution
To search for multiple words, separate each word with a space, for example: weights aerobics.
To search for a phrase, enclose the phrase in single quotes, for example: 'weight lifting'.
When editing stylesheets, you see stale stylesheet data when previewing or viewing the stylesheet in the context of a Portal page.
Problem
Changes to stylesheets 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 for the time zone. If the time zone of the origin 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 the preceding steps, then verify that the date, time, and time zone have been set to the current values on the Web Cache host(s) 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 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.
OracleAS Portal consists of middle and database tiers each of which consist of numerous components. Not only can components be distributed across many machines, but they may also handle a large number of requests simultaneously.
You can also use diagnostic tools on OracleAS Portal to analyze and resolve issues with the working of OracleAS Portal.
This section contains the following topics:
To facilitate diagnosis, components can record information relating to the requests they receive, in log files. This section details how to configure and use various log files to diagnose problems. We will also see how an individual request can be traced from start to finish, 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, as information relating to these requests is intermingled.
OracleAS Portal makes use of an ECID, a unique number that is assigned to a request and attached to 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. We 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 present in OracleAS Web Cache, Oracle HTTP Server and the Parallel Page Engine (PPE). An ECID is only generated if not already present.
Oracle Application Server Containers for J2EE (OC4J) can include the ECID with each log entry it writes and this can be useful for debugging purposes. 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.
The various OracleAS Portal components can have their diagnostic output configured. The following are the components:
The Java Portal Developers Kit (JPDK) provides a framework for the construction of Java-based portlets and portlet providers. A Java-based provider or Web provider is one that is written as a Web application. The JPDK includes a logging mechanism that is controlled based on each Provider Adapter.
The acceptable logging level values range from 1 to 7 and build incrementally. For example, at logging level 3, the output for logging levels 1 and 2 are also recorded.
Table K-1 Logging Levels
| Logging Level | Description |
|---|---|
| 1 | Configuration |
| 2 | Severe Errors |
| 3 | Warnings |
| 4 | Exceptions |
| 5 | Performance |
| 6 | Information |
| 7 | Debug |
JPDK Log File Contents
A Provider Adapter's diagnostic information 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
Its content is as follows:
03/12/31 02:58:59 - Date and time
jpdk: - Web application
id=1024597399815ApplicationServerThread-12,4: - ECID, sequence number
instance=1926_EXPIRESSAMPLE_886361: - Portlet instance identifier
Beginning rendering of portlet: 1926_EXPIRESSAMPLE_886361: - Message
The portlet instance identifier, identifies a specific portlet instance on a specific page and can be broken down as follows:
1926: - Internal sequence number
EXPIRESSAMPLE: - Portlet name
886361: - Provider identifier
Additional details relating to some of these values are shown in Table K-2.
Table K-2 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 | Some messages carry null ECID and portlet instance identifier values. These are typically SOAP messages from the repository. The portlet instance identifier is null in this case, because the message does not relate to a particular portlet instance. |
mod_plsql is an Oracle HTTP Server module that enables a user to invoke PL/SQL applications over HTTP. Because mod_plsql is an Oracle HTTP Server module, its logging is performed through the Oracle HTTP Server.
Logging is controlled by the LogLevel parameter found in the configuration file httpd.conf, usually located at:
ORACLE_HOME/Apache/Apache/conf
The values for LogLevel are:
emerg
alert
crit
error
warn
notice
info
debug
The values build incrementally. For example, if LogLevel is set to notice, then notice, warn, error, crit, alert and emerg messages are recorded.
If the value of LogLevel is altered, the Oracle HTTP Server must be restarted for this change to take effect.
mod_plsql Log File Contents
The location of mod_plsql's diagnostic information is dictated by the Oracle HTTP Server parameter ErrorLog found in the file httpd.conf. While this parameter is called ErrorLog, the file it describes can contain more than just error messages. A typical value for the Oracle HTTP Server parameter ErrorLog is:
ORACLE_HOME/Apache/Apache/logs/error_log
Two types of mod_plsql messages appear in the Oracle HTTP Server error log:
Standard mod_plsql Messages
Performance mod_plsql Messages
Standard mod_plsql Messages
Here is an example of a standard mod_plsql message found in the Oracle HTTP Server error log:
[Thu Aug 22 08:34:20 2002] [warn] mod_plsql: 'PlsqlCacheCleanupSize' is deprecated.
The content is as follows:
Thu Aug 22 08:34:20 2002: - Date and time
warn: - Message level
mod_plsql: - Indicates this message comes from mod_plsql
'PlsqlCacheCleanupSize' is deprecated.: - Message text
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:
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's 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:
<init-param>
<param-name>logmode</param-name>
<param-value>perf</param-value>
</init-param>
This 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, 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:
&_debug=3
To make:
http://myserver.myplace.com:3000/portal/page?_pageid=111&_dad=myDAD&_schema=mySchema&_debug=3
The values for _debug are shown in Table K-3.
Table K-3 PPE Request Log Levels
| Value | Detail |
|---|---|
| 0 | Activates page-debugging information. |
| 1 | Activates page-debugging information. |
| 2 | Log to page and set the request logmode to debug. |
| 3 | Log to page and set the request logmode to request. |
| 4 | Log to page and set the request logmode to content. |
| 5 | Log to page and set the request logmode to parsing. |
Page Logging
With _debug set to 2, 3, 4, or 5, page logging is activated. This means that messages logged for the request are recorded in the PPE's log file as well as in the page returned.
Page logging is a simple means by which to 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.
urlDebugMode can be found alongside logmode in the portal's web.xml file:
<init-param>
<param-name>urlDebugMode</param-name>
<param-value>4</param-value>
</init-param>
Both urlDebugMode and logmode 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>
The values for urlDebugMode are shown in Table K-4.
Table K-4 PPE urlDebugMode Levels
| Value | Detail |
|---|---|
| None | Ignore the _debug URL parameter. |
| 0 | Only allow _debug to be 0. |
| 1 | Only allow _debug to be 0 or 1. |
| 2 | Only allow _debug to be 0, 1, or 2. |
| 3 | Only allow _debug to be 0, 1, 2, or 3. |
| 4 | Only allow _debug to be 0, 1, 2, 3, or 4. |
| 5 | Only allow _debug to be 0, 1, 2, 3, 4, or 5. |
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
Here 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 is as follows:
03/12/31 11:54:35: - Date and time
portal: - Web application
DEBUG: - logmode flag
active=53: - Active count
id=22020914339, 0: - ECID
ContentFetcher Unexpected Exception Request Failed: - Message
Additional details relating to some of these values are shown in Table K-5.
Table K-5 PPE Standard Message Attributes
| Value | Detail |
|---|---|
| logmode flag | Indicates that logmode is debug or higher. If logmode is set to perf and is therefore lower than debug, the logmode flag is not included in the message. |
| Active count | The number of threads in the PPE's thread group. If logmode is set to perf and is therefore lower than debug, the active count is not included in the message. |
| ECID | The ECID value can be null. A message with such a value relates to a PPE background task (such as clearing pooled objects). Background tasks do not relate to a request and therefore do not have an ECID specified. |
The 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 encompasses the 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 can be found at:
http://<host>:<port>/pls/<dad>/<schema>.wwpro_log.render
For example:
http://myserver.myplace.com:3000/pls/portal/PORTAL.wwpro_log.render
From this page you can apply the following logging levels:
Table K-6 PDK Log Levels
| Level | Detail |
|---|---|
| No debugging | No logging. |
| PROHTTPJ | Provider framework logging only. |
| PROGRP | Provider logging only. |
| ADAPTER | Federated portal adapter logging only. |
| CACHE | Cache logging only. |
| FORCE | Internal to Oracle. |
| INVAL | Invalidation logging only. |
| PROREG | Provider registration logging only. |
| PROLOGIN | Page metadata generation, login and session initialization logging only. |
| PROPROV | Provider communication logging only. |
| PROPMR | Portlet repository metadata logging only. |
| PROHTTP | Web provider framework logging only. |
| All | Every logging level is 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.
The 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 diagnostic output that can be correlated with diagnostics output generated from the other components of OracleAS Portal.
Since the log file is output from the OracleAS Metadata Repository, the database running OracleAS Portal needs to 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 permissions for Oracle Database processes
Privileges granted for the directory are created independently of the permissions 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 permission defined for the Oracle Database processes.
To create a directory object use the following syntax:
CREATE [OR REPLACE] DIRECTORY AS 'path_name';
Table K-7 describes the parameters used in the preceding syntax.
Table K-7 CREATE DIRECTORY Parameters
| Semantics | Description |
|---|---|
OR REPLACE
|
Specify OR REPLACE to re-create the directory database object if it already exists. You can use this clause to change the definition of an existing directory without dropping, re-creating, and regranting database object privileges previously granted on the directory.
Users who had previously been granted privileges on a redefined directory can still access the directory without being granted the privileges again. |
directory
|
Specify the name of the directory object to be created. The maximum length of directory is 30 bytes. You cannot qualify a directory object with a schema name.
Oracle Database does not verify that the directory you specify actually exists. Therefore, take care that you specify a valid directory in your operating system. In addition, if your operating system uses case-sensitive path names, be sure to specify the directory in the correct format. You need not include a trailing slash at the end of the path name. |
path_name
|
Specify the full path name of the operating system directory of the server where the files are located. The single quotes 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 directory database object bfile_dir 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 versions, older than 9.2, for the PL/SQL code to generate diagnostics output, update the database's init.ora file, adding the following line:
UTL_FILE_DIR=<directory where you want to write the log file>
There can be many UTL_FILE_DIR entries, so if the directory you wish to write to is already defined, there is no need to modify this file.
|
Notes:
|
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 script logcfg.sql 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, the current value is maintained.
Table K-8 details logcfg.sql parameters.
Table K-8 Repository Logging Package Parameters
| Parameter | Detail |
|---|---|
| log_level | Describes the level of messages recorded. The values are:
The values build incrementally. The default value is |
| log_state_level | Describes the level of messages for which state information will automatically be logged. The values are:
The values build incrementally. |
| log_format | Describes the format that automatically recorded context information, which is different from state information. The values are:
|
| log_file | The name of the log file to write to. An attempt is made to create this file if it does not already exist. |
| log_directory | The directory in which the log_file exists. This directory must be defined in the init.ora database file under the UTL_FILE_DIR property. For example:
utl_file_dir=/export/home/oracle/iAS904/dblogs If the |
For example, you can run the script logcfg.sql from SQL*Plus as follows:
@logcfg.sql 3 3 1 portal.log /export/home/oracle/iAS904/logs
On 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 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/iAS904/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's diagnostic information is dictated by the Repository diagnostic package parameters log_file and log_directory.
Here is an example of a message found in the OracleAS Metadata Repository's 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-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-ERROR-STACK] ORA-30625: method dispatch on NULL SELF [END-ERROR-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]
Its content is as follows:
ORA-30625: method dispatch on NULL SELF: - The message itself.
Along with its context and state information.
Context Information
Context information is produced in one of two formats, detailed or simple, as specified by log_format. In the given 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
Additional details relating to some of these values are included in Table K-9.
Table K-9 Repository Context Attributes
| Value | Detail |
|---|---|
| Client IP address | Typically, this is the IP address of the client browser or HTTP proxy in use. Since the OracleAS Portal page assembly process makes use of loop back calls, the IP address can also represent the middle-tier itself. |
| Subscriber identifier | Identifies which subscriber has been accessed. |
| User agent | A description of the browser in use. |
State Information
State information consists of the 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]
Error stack:
[START-ERROR-STACK] ORA-30625: method dispatch on NULL SELF [END-ERROR-STACK]
And 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. For more information, see Section K.2.3, "Using Application Server Control Console Log Viewer".
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 filename of the log file.
<INSTANCE> - The name of the OracleAS Portal target in Oracle Enterprise Manager 10g, if one is defined. If there is no corresponding OracleAS Portal target in Oracle Enterprise Manager 10g, 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.
Once 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.
Since the OracleAS Metadata Repository can be accessed through many middle-tiers, you need to:
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.
Ensure that the log file is accessible over a network file system, if the OracleAS Portal database is on a machine other than the OracleAS Portal middle-tier.
To perform log correlation in a multi 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: On changing the Infrastructure services that are used. 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 can help you 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 the Oracle Enterprise Manager 10g Application Server Control Console to view and query entries from the following Oracle Application Server log files to diagnose issues relating to OracleAS Portal. The relevant Oracle Application Server component log files include:
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/access log files named error_log and access_log. This log file contains all relevant mod_plsql logging information.
OC4J_Portal - displays multiple application log files named application.log. This log file contains all relevant PPE logging information.
JPDK - For the JPDK sample providers in a standalone OC4J, the location is j2ee/home/application-deployments/jpdk/application.log. In an Oracle Application Server middle-tier, the location is similar with the addition of a directory for the default island.
Web Cache - displays an error and access log files name event_log and access_log.
Before you can use the OracleAS Metadata Repository log file with the Application Server Control Console Log Viewer, you must complete a registration process. For instructions, see the section "Repository Diagnostics Log File Registration".
If your JPDK OC4J instance is not located in the OracleAS Portal middle-tier Oracle home, then its log file may only be viewed through the local Application Server Control Console instance. If you want to perform diagnostic correlation (see subsequently), you will need to 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 the Application Server Control Console Log Viewer, you can also perform advanced diagnostics by correlating entries across log files using the ECID value discussed in Section K.2.1, "Enabling ECID Logging". This drill-down correlation is automatically provided by the Application Server Control Console Log Viewer.
To view log file entries, click the Logs link in the Application Server Control Console. This link 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 the OracleAS Portal Diagnostic 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 the OracleAS Portal Diagnostic Assistant. Alternatively, you can upload the results to Oracle Support so they can assist in troubleshooting the problem for you.
The generated report includes the following:
OracleAS Portal Repository database information
OracleAS Single Sign-On database information
Oracle Internet Directory diagnostics report
Oracle Text diagnostic report
Apache error log file analysis
In addition, all OracleAS Portal-related configuration files and log files are collected and zipped for your convenience. For a detailed description of all the information collected, refer to the readme file located in the directory ORACLE_HOME/portal/admin/utils/tshoot.
Each time you run the OracleAS Portal Diagnostic Assistant a new directory is created for the generated files, under the directory ORACLE_HOME/portal/admin/utils/tshoot. The directory names have a timestamp format, for example, 040623132344 which means:
year - 04
month - 06
day - 23
hour - 13
minutes -23
seconds - 44
After running the OracleAS Portal Diagnostic Assistant, locate the appropriate directory and open the HTML report named pda.htm in a Browser window. You can use the links provided to navigate through the report and review the diagnostic information.
If you want Oracle Support to assist you in troubleshooting the problem, upload the generated ZIP file named PDA<directory_name>.zip, for example, PDA040623132344.zip.
Refer to readme.htm in the ORACLE_HOME/portal/admin/utils/tshoot directory for detailed information on using the OracleAS Portal Diagnostic Assistant.
Running the OracleAS Portal Diagnostic Assistant
To generate diagnostics information using the OracleAS Portal Diagnostic Assistant, follow these steps:
Check the Support/Upgrade section on Oracle Technology Network, http://www.oracle.com/technology/ for the latest update/patch information for the OracleAS Portal Diagnostic Assistant.
Download the latest OracleAS Portal Diagnostic Assistant script. The Support/Upgrade link 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 the OracleAS Portal Diagnostic Assistant from a database ORACLE_HOME it fails and no diagnostics information is collected.
Go to the directory ORACLE_HOME/portal/admin/utils/tshoot and run the Perl script ptshoot.pl as follows:
ORACLE_HOME/perl/bin/perl ptshoot.pl
Run ptlshoot.pl without any arguments to get help information.
The following is an example of a Unix C-shell script that could be used to run OracleAS Portal Diagnostic Assistant:
#!/bin/csh -f
#
# Set the environment
#
setenv ORACLE_HOME /oracle/productsAS
setenv PATH ${PATH}:$ORACLE_HOME/bin
setenv CLASSPATH $ORACLE_HOME/rdbms/jlib/xsu12.jar:$ORACLE_HOME/jdbc/lib/classes12.zip:$ORACLE_HOME/lib/xmlparserv2.jar
setenv PERL5LIB $ORACLE_HOME/perl/lib/site_perl/5.6.1/sun4-solaris:$ORACLE_HOME/perl/lib:$ORACLE_HOME/perl/lib/5.6.1
#
# Run PDA
#
$ORACLE_HOME/perl/bin/perl ptshoot.pl \
-schema portal \
-password <portal_password> \
-connect abc.oracle.com:1521:orcl1 \
-ssoSchema orasso \
-ssoPassword <orasso_password> \
-ssoConnect defg.oracle.com:1521:orcl2
To run the OracleAS Portal Diagnostic Assistant on Windows, follow these steps:
On the Windows desktop, right-click the My Computer icon and select Properties.
Click the Advanced tab.
Click Environment Variables. Under System Variables, look for, or create, the variable: PERL5LIB
PERL5LIB=c:\oracle\midtier\perl\5.6.1;c:\oracle\midtier\perl\5.6.1\bin;c:\oracle\midtier\perl\5.6.1\lib;c:\oracle\midtier\perl\5.6.1\bin\MSWin32-x86
Click OK, and ensure that this is updated in the System Variables.
Start up a command prompt, and set the environment:
SET ORACLE_HOME=c:\oracle\midtier SET PATH=%PATH%;ORACLE_HOME/bin;ORACLE_HOME/jdk/bin;c:\oracle\midtier\perl\5.6.1\bin\MSWin32-x86 SET CLASSPATH=CLASSPATH%;ORACLE_HOME/rdbms/jlib/xsu12.jar;ORACLE_HOME/jdbc/lib/classes12.zip;ORACLE_HOME/lib/xmlparserv2.jar
Navigate to the location where you downloaded and unzipped the OracleAS Portal Diagnostic Assistant.
From the command prompt window, execute the following: perl ptshoot.pl
Open the latest HTML report (pda.htm) in a Browser window and use the information to help diagnose what is wrong with OracleAS Portal.
When troubleshooting OracleAS Portal, one of the first things to do is to review the contents of the Portal Dependency Settings file iasconfig.xml. This file stores configuration data from all the dependent components in a central place and the content of the file is 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, you must update the file and run the Portal Dependency Settings tool ptlconfig to update the Oracle Application Server 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.
You can find more solutions on Oracle MetaLink, http://metalink.oracle.com. If you do not find a solution for your problem, log a service request.
To help Oracle Support troubleshoot the problem, perform the following steps:
Run the OracleAS Portal Diagnostic Assistant.
You can diagnose portal-related issues by reviewing the report generated from the OracleAS Portal Diagnostic Assistant. See also Section K.2.4, "Using the OracleAS Portal Diagnostics Assistant".
Contact Oracle Support.
If you are unable to establish why your portal is not accessible, contact Oracle Support. To help Oracle Support troubleshoot the problem, provide the following information:
ZIP file generated by the OracleAS Portal Diagnostic Assistant.
Details of any command line scripts you have run (for example, ptlconfig) including the full parameters used.
A rough network diagram, showing how your Oracle Application Server components are configured.
|
See Also:
|
