10g (9.0.4)
Part Number B10356-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle® Application Server Portal Configuration Guide 10g (9.0.4) Part Number B10356-01 |
|
This chapter shows you how to use various tools to diagnose problems, and lists possible causes and solutions to errors that you may encounter while installing or using OracleAS Portal.
You can find the most up-to-date troubleshooting information on Portal Center, http://portalcenter.oracle.com. Click the Search icon in the upper right corner of any Portal Center page.
This chapter contains the following sections:
This section contains some troubleshooting information for common issues that you may experience while running OracleAS Portal. These are:
If you cannot access your OracleAS Portal instance through the internet/intranet, follow these steps to help diagnose the cause of the problem:
The Web Cache status is displayed in the portal's Component Status table.
To access Web Cache monitoring and administration pages in the Application Server Control, click the Web Cache link in the:
- Portal's Component Status table, or
- Application Server's Component table.
If Web Cache starts successfully, check to see if your portal is now accessible.
If Web Cache fails to start, investigate Web Cache error log files and try to determine the problem. See Section 13.6, "Using Application Server Control Log Viewer". If you are not using Log Viewer, check the relevant error log files in ORACLE_HOME/opmn/logs.
The HTTP Server status is displayed in the portal's Component Status table.
To access HTTP Server monitoring and administration pages in the Application Server Control, click the HTTP Server link in the:
- Portal's Component Status table, or
- Application Server's Component table.
If HTTP Server starts successfully, check to see if your portal is now accessible.
If HTTP Server fails to start, investigate HTTP Server error log files and try to determine the problem. See Section 13.6, "Using Application Server Control 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 DAD status 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".
The status is displayed on the portal's target page in the Enterprise Manager Application Server Control. Look under the section 'OracleAS Metadata Repository Used By Portal'.
If the database starts successfully, check to see if your portal is now accessible.
If the database fails to start, investigate further to establish what is wrong with this component.
The OC4J_Portal status is displayed in the portal's Component Status table.
To access OC4J_Portal monitoring and administration pages in the Application Server Control, 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, check to see if your portal is now accessible. If you are not using Log Viewer, check the relevant error log files in ORACLE_HOME/opmn/logs.
If OC4J_Portal fails to start, investigate OC4J_Portal error log files and try to determine the problem. See Section 13.6, "Using Application Server Control Log Viewer".
You can diagnose portal-related issues by reviewing the report generated from the OracleAS Portal Diagnostic Assistant. See also Section 13.5, "Using the OracleAS Portal Diagnostics Assistant".
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:
ptlasst.csh, orasso.cfg, ossoref.jar, and so on) including the full parameters used.
If the OracleAS Single Sign-On (SSO) is not accessible you cannot login to OracleAS Portal. Follow these steps to help diagnose the cause of this problem:
Click the HTTP Server link, displayed in the Related Links section.
To access HTTP Server monitoring and administration pages in the Application Server Control, click the HTTP Server link in the:
- OracleAS Single Sign-On target page, or
- Application Server's Component table.
If HTTP Server starts successfully, check to see if your OracleAS Single Sign-On is now accessible.
If HTTP Server fails to start, investigate HTTP Server error log files and try to determine the problem. See Section 13.6, "Using Application Server Control 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 DAD status 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".
Database information is displayed on the OracleAS Single Sign-On's target page in the Enterprise Manager Application Server Control. Drill down for further information.
If the database starts successfully, check to see if your OracleAS Single Sign-On is now accessible.
If the database fails to start, investigate further to establish what is wrong with this component.
The OC4J_Security status is displayed in Application Server's page. Alternatively, you can establish its status using the following command line:
ORACLE_HOME/dcm/bin/dcmctl getstate
|
See Also:
Oracle Application Server 10g Administrator's Guide for more information on the Distributed Configuration Management (DCM) utility, |
To access OC4J_Security monitoring and administration pages in the Application Server Control, click the OC4J_Security link in the Application Server's Component table.
If OC4J_Security starts successfully, check to 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 13.6, "Using Application Server Control Log Viewer". If you are not using Log Viewer, check the relevant error log files in ORACLE_HOME/opmn/logs.
The Oracle Internet Directory status is displayed in Application Server's page.
To access Oracle Internet Directory monitoring and administration pages in the Application Server Control, click the Oracle Internet Directory link in the Application Server's Component table.
If Oracle Internet Directory starts successfully, check to see if your OracleAS Single Sign-On is now accessible.
If Oracle Internet Directory fails to start, investigate the Oracle Internet Directory error log files and try to determine the problem. See Section 13.6, "Using Application Server Control Log Viewer".
You can diagnose OracleAS Single Sign-On and portal-related issues by reviewing the report generated from the OracleAS Portal Diagnostic Assistant. See also Section 13.5, "Using the OracleAS Portal Diagnostics Assistant".
If you are unable to establish why you cannot login to OracleAS Portal, contact Oracle Support. To help Oracle Support troubleshoot the problem, provide the following information:
ptlasst.csh, orasso.cfg, ossoref.jar, and so on) including the full parameters used.
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 these underlying category/perspective templates, you may see one of these messages when you create a new category/perspective:
32022:catpagecreationerror 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.
32023:persppagecreationerror 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.
If either of these errors is displayed, you must first delete the current category/perspective template and then run scripts to:
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.
The scripts required are available at:
ORACLE_HOME/portal/admin/plsql/wws/pstdefin.sql ORACLE_HOME/portal/admin/plsql/wws/pstpgshw.sql ORACLE_HOME/portal/admin/plsql/wws/pstundef.sql ORACLE_HOME/portal/admin/plsql/wws/pstpgcre.sql ORACLE_HOME/portal/admin/plsql/wws/pstprcpg.sql
To run these scripts:
pstdefin.sql file with:
Descriptions for these settings are in the file pstdefin.sql.
pstpgshw.sql to retrieve information from OracleAS Portal to configure the pstdefin.sql file.
pstpgcre.sql to apply the changes. For example:
SQL> @pstpgcre.sql
In OracleAS Portal, there is multi-language support for the online help. However, only context sensitive Help topics are translated.
This section contains some troubleshooting information for less common issues that you may experience while running OracleAS Portal. These are:
A remote Web provider that is located on a different machine 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, the message Error: the portlet could not be contacted is shown in the place of each portlet from the same provider. You can also find portlet timeout errors in the OC4J_Portal application.log. On restarting OC4J_Portal, the Web provider works again, but only for a limited period of time.
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 of using DDNS.
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.
opmn.xml as follows:
<java-option value="-server -Xincgc -Xnoclassgc -Xms256m -Xmx512m -Dsun.net.inetaddr.ttl=120"/>
To do this, run the following commands:
ORACLE_HOME/opmn/bin/opmnctl stopall ORACLE_HOME/opmn/bin/opmnctl startall
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:
The typical error you will see is "ORA-04031: unable to allocate 30192 bytes of shared memory." 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:
init.ora file for the database instance. The init.ora file can be found in your database's ORACLE_HOME.
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. 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.
If you make configuration changes using the OracleAS Portal Configuration Assistant (OPCA) in MIDTIER mode (using the WEBCACHE, OHS, or OID type), the iasconfig.xml file is not updated to reflect these changes. This can cause your site to be misconfigured, and is therefore not recommended. Instead, the Portal Dependency Settings file and tool should be used to update the configuration, whenever possible. Refer to Appendix A, "Using the Portal Dependency Settings File" for more information about the Portal Dependency Settings file, and examples of the iasconfig.xml file.
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.
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).
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 13-1, where a solid arrow depicts a request with an ECID.
ECID generation is present in Web Cache, Oracle HTTP Server (OHS) 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 10g Administrator's Guide.
If you want to log ECID information in OC4J logs, edit the file opmn.xml as follows:
opmn.xml.
Here is an example:
<process-type id="OC4J_Portal" module-id="OC4J">
<environment>
<variable id="DISPLAY" value="localhost:0"/>
<variable id="LD_LIBRARY_PATH" value="/export/home/ias/pwhome/lib"/>
</environment>
<module-data>
<category id="start-parameters">
<data id="java-options" value="-server
-Djava.security.policy=/export/home/ias/pwhome/j2ee/OC4J_Portal/conf
ig/java2.policy -Djava.awt.headless=true
-Doracle.dms.transtrace.ecidenabled=true -Xmx256m "/>
<data id="oc4j-options" value="-properties"/>
</category>
<category id="stop-parameters">
<data id="java-options"
value="-Djava.security.policy=/export/home/ias/pwhome/j2ee/OC4J_Port
al/config/java2.policy -Djava.awt.headless=true"/>
</category>
</module-data>
<start timeout="900" retry="2"/>
<stop timeout="120"/>
<restart timeout="720" retry="2"/>
<port id="ajp" range="3301-3400"/>
<port id="rmi" range="3201-3300"/>
<port id="jms" range="3701-3800"/>
<process-set id="default_island" numprocs="1"/>
</process-type>
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.
| Logging Level | Description |
|---|---|
|
1 |
Configuration |
|
2 |
Severe Errors |
|
3 |
Warnings |
|
4 |
Exceptions |
|
5 |
Performance |
|
6 |
Information |
|
7 |
Debug |
A Provider Adapter's diagnostic information is recorded in the servlet context log file named application.log.
There are two types of 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:
Additional details relating to some of these values are shown in Table 13-2.
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:
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.
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:
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.
PPE servlet level logging is controlled by the logmode servlet initialization argument. The values for logmode are:
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
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 13-3.
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 13-4.
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:
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 13-5.
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 13-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:
You can view PDK log entries from the same page used to configure PDK logs, as shown in Figure 13-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 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.
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 13-7 details logcfg.sql parameters.
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
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=(null) 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:
Along with its context and state 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 13-8.
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]
Oracle Enterprise Manager 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 13.6, "Using Application Server Control Log Viewer".
To load and view the Repository Diagnostics log file entries, you must first register the log file with Oracle Enterprise Manager. 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, if one is defined. If there is no corresponding OracleAS Portal target in Oracle Enterprise Manager, 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:
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.
Use the OracleAS Portal Diagnostic Assistant to gather information if you are troubleshooting issues after OracleAS Portal installation. Problems can vary from accessing the portal, to users getting errors at different levels within the 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 troubleshoot the problem for you.
The generated report includes the following:
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, 20030623132344 which means:
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 troubleshoot the problem, upload the generated ZIP file named PDA<directory_name>.zip, for example, PDA20030623132344.zip.
Refer to readme.htm in the ORACLE_HOME/portal/admin/utils/tshoot directory for detailed information on using the OracleAS Portal Diagnostic Assistant.
To generate diagnostics information using the OracleAS Portal Diagnostic Assistant, follow these steps:
Download the latest OracleAS Portal Diagnostic Assistant script. The Support/Upgrade link is located in the Product Information section.
If you try to run the OracleAS Portal Diagnostic Assistant from a database ORACLE_HOME it fails and no diagnostics information is collected.
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.
pda.htm) in a Browser window and use the information to help diagnose what is wrong with OracleAS Portal.
You can use the Oracle Enterprise Manager Application Server Control 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:
error_log and access_log. This log file contains all relevant mod_plsql logging information.
application.log. This log file contains all relevant PPE logging information.
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.
event_log and access_log.
Before you can use the OracleAS Metadata Repository log file with the Application Server Control Log Viewer, you must complete a registration process. For instructions, see Section 13.4.1.5.2, "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 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 Log Viewer, you can also perform advanced diagnostics by correlating entries across log files using the ECID value discussed in Section 13.4, "Diagnosing OracleAS Portal Problems". This drill-down correlation is automatically provided by the Application Server Control Log Viewer.
To view log file entries, click the Logs link in the Application Server Control. This link is located at the top and bottom of every Application Server Control component home page.
|
See Also:
For detailed instructions on how to use the Log Viewer, see Oracle Application Server 10g Administrator's Guide, chapter Managing Diagnostic Log Files. This chapter also 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 13-4 shows an example of Oracle Application Server components selected in the View Logs page.
Text description of the illustration cg_monit_sshot_console_logs.gif
For discussions on import and export, visit the Oracle Technology Network Discussion Forums site and look for export/import, accessible from the same URL.
For detailed error message descriptions, cause and actions, refer to the export/import error messages chapter of the Oracle Application Server Portal Error Messages Guide.
This section provides information on the common problems encountered while using the Search functionality in OracleAS Portal, or Oracle Text.
Search functionality can become inconsistent if the search criteria includes a large number of attributes and the user can choose which page groups to search and the list of available page groups is very long. This problem is due to URL size constraints.
Here are examples of issues that can occur:
A workaround is to reduce the number of attributes, or page groups, or both, available for user selection.
If you define search criteria for a PL/SQL attribute, it is ignored and therefore search results are not returned as expected.
If you are experiencing Oracle Text-related problems, 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".
This section lists the issues you may encounter while working with the Federated Portal Adapter, and their workarounds.
Refer to the book Oracle Application Server Portal Error Messages Guide, for more information on error messages. This book contains the following sections:
|
 Copyright © 2002, 2003 Oracle Corporation. All Rights Reserved. |
|