|
Oracle® Application Server 10g Forms and Reports Services Upgrade Guide
10g (9.0.4) for UNIX Part No. B13547-01 |
|
|
|
|
Oracle® Application Server 10g Forms and Reports Services Upgrade Guide
10g (9.0.4) for UNIX Part No. B13547-01 |
|
|
|
|
This chapter contains information you need to know about troubleshooting and resolving errors that may occur during an upgrade.
If errors occur at either stage of the upgrade process, you must correct the conditions that caused them before you try the upgrade again. This section contains the following topics:
Section 2.1.1, "Resolving Common Errors"
Section 2.1.2, "Examining the Log File"
Under certain conditions, the OracleAS Upgrade Assistant cannot perform an upgrade. Among these are that the starting configuration is unsupported, or processes are running in the Oracle homes.
This section identifies each condition and its cause(s), and explains how to resolve it.
If the source Oracle home does not appear as expected in the drop-down list of the Oracle Homes screen when you execute the OracleAS Upgrade Assistant, suspect one of these conditions: wrong installation type, Oracle homes are on different computers, or the Oracle home is not identified in the default inventory. The solution for each of these is detailed below.
The source Oracle home will not appear if the source middle tier instance is not of the same installation type as the destination middle tier instance. If this is the case, you must reinstall the destination middle tier with the same installation type as the source middle tier.
Another case in which the source middle tier will not appear as a selection is that the source middle tier instance is installed on a different computer from the destination middle tier instance. If this is the case, you must install the destination middle tier instance on the same computer as the source instance to be upgraded.
The OracleAS Upgrade Assistant uses the default inventory location to populate the drop-down list in the Oracle Homes screen. If the source Oracle home is not listed in the default Oracle Universal Installer inventory, then you need to provide the inventory file location to the OracleAS Upgrade Assistant. Start the OracleAS Upgrade Assistant with the -invptrloc option, described in Section 1.3.2, "Starting the OracleAS Upgrade Assistant To Use Multiple Oracle Universal Installer Inventory Locations" to specify the inventory location.
If the upgrade fails during the OPMN, OC4J or Oracle HTTP Server upgrade, it is probably because OPMN is still running in one or both instances (source and destination). You must stop OPMN before starting the OracleAS Upgrade Assistant. Follow the instructions in Section 1.2, "Stopping OracleAS Instances".
You can examine the <destination_MT_OH>/upgrade/log/iasua.log file and Table 2–1, "OracleAS Upgrade Assistant Error Messages" to determine the cause of examination and upgrade failures.
|
Note: By default, the OracleAS Upgrade Assistant logging function appends, so you should always look for the last instance of a message in the file. You can setlog.append=FALSE in <destination_MT_OH>/upgrade/iasua.properties to overwrite entries instead of appending them.
|
To determine the cause of an examination failure:
Note the name of the failed component in the OracleAS Upgrade Assistant dialog or command-line output.
Search for the message Starting to examine component_name.
Investigate the messages between the Starting... message and the message Finished examining component_name with status: Failure.
To determine the cause of an upgrade failure:
Note the name of the failed component in the OracleAS Upgrade Assistant dialog or command-line output.
Open <destination_MT_OH>/upgrade/log/iasua.log.
Search for the message Starting to upgrade component_name.
Investigate the messages between the Starting... message and the message Finished upgrading component_name with status: Failure.
Table 2-1 OracleAS Upgrade Assistant Error Messages
| Component | Message | Possible Cause and Solution |
|---|---|---|
| All | Unable to upgrade file filename.
|
The file was not found in the source Oracle home, or you do not have sufficient permissions to copy the file. Determine the permissions for the file in the source Oracle home and the destination Oracle home, and adjust them as necessary. |
| Oracle Application Server Containers for J2EE
|
J2eeDeploymentException
|
An application EAR file is not 100% J2EE compliant.
Use the |
| Oracle Application Server Forms Services
|
Save files operation failed.
|
The copy operation failed. Some files are copied "as is" from <source_MT_OH> (i.e., registry.dat and ftrace.cfg). Verify that all of these files exist and that permissions and disk space are sufficient for a copy operation.
|
| Oracle Application Server Forms Services
|
Invalid section in the <formsweb.cfg> <default.env> file.
|
There is an invalid entry in the named file in <source_MT_OH>. Examine the file, and locate and correct any errors.
|
| Oracle Application Server Forms Services
|
Invalid or missing configuration file.
|
There is an invalid configuration file in <source_MT_OH>. Examine the file, and locate and correct any errors.
|
| Oracle Application Server Forms Services
|
Invalid or missing Forms configuration file <file name>.
|
The Upgrade Assistant is unable to locate the configuration files specified in the formsweb.cfg file (*htm and *env files), or the user-defined FormsServlet configuration file specified in oc4j_bi_forms.properties. Ensure that all files specified in the entries are valid and exist in the specified location.
|
| Oracle Application Server Forms Services
|
Forms is not configured in the Source Oracle Home <version number>, Forms upgrade cannot proceed.
|
If Forms services are not configured in the source OracleAS middle tier installation, then the Upgrade Assistant will not upgrade Oracle Application Server Forms Services. Ignore this message; if Oracle Application Server Forms Services is not configured in the source Oracle home, then upgrade is unnecessary. |
| Oracle Application Server Forms Services
|
Forms is not configured in the Destination Oracle Home <version number>, Forms upgrade cannot proceed.
|
If Forms services are not configured in the destination middle tier installation, then the Upgrade Assistant will not upgrade Oracle Application Server Forms Services. Configure Oracle Application Server Forms Services in the destination Oracle home. |
| Oracle HTTP Server (mod_plsql) | java.io.FileNotFoundException...Apache/modplsql/conf/dads.conf
or
|
The file was not found. Provide a file at the location specified. |
This section discusses reasons for which an Oracle Application Server Containers for J2EE upgrade may fail.
If a configuration does not perform as expected after an upgrade, it might be because configuration changes were made to OC4J application files by means other than the Oracle Enterprise Manager Application Server Control. Only the changes made by the Oracle Enterprise Manager Application Server Control will be included in the OC4J upgrade performed by the OracleAS Upgrade Assistant. Manually edited files may not be in the scope of the managed configuration, and the edits may not be preserved in an upgrade. If you use Distributed Configuration Management’s dcmctl utility to perform configuration changes, see the Distributed Configuration Management Reference Guide for instructions and a complete discussion on the correct usage of the commands.
OC4J deployment enforces J2EE compliance rules, so the OracleAS Upgrade Assistant may not upgrade applications that are not fully J2EE compliant. The OracleAS Upgrade Assistant simply reads the files in the source Oracle home and attempts to deploy them to the destination Oracle home; if deployment fails, it could be because an application is not J2EE compliant. If the OracleAS Upgrade Assistant cannot deploy an application for any reason, it logs the exception in the <destination_MT_OH/upgrade/log/iasua.log. The exception may not be explicitly described as a J2EE compliance issue, but that may be the reason for the failure. Knowledge of the J2EE and EJB specifications, and the EJB features used in applications will be helpful in preventing and troubleshooting deployment failures (10g (9.0.4) supports a higher version of the EJB specification than Release 2 (9.0.2)). While the development of J2EE applications is standardized and portable, the XML configuration files are not. Multiple XML files may need to be configured for an OC4J application to be deployed, and the required configuration varies according to the services the application uses. For example, if the application uses a database, the DataSource object in the data-sources.xml file must be configured.
The dcmctl utility provides a J2EE compliance validation command. It takes one input, the name of an EAR file, and then lists non-compliant characteristics of that file. The syntax is:
<destination_MT_OH>/dcm/bin/dcmctl validateEarFile -f <full path and filename for ear file>
You must provide the full path to the EAR file.
If you connect to the Internet using a proxy server, you must configure proxy settings so that the validation routine can access DTDs (for example, on the Sun Microsystems site). To do this, you define an environment variable called ORACLE_DCM_JVM_ARGS, which specifies a hostname and port for the proxy. For example, using tcsh, the command is:
setenv ORACLE_DCM_JVM_ARGS "-DhttpProxy.host=www-proxy.hostname.com -DhttpProxy.port=9999"
where hostname is the host name and 9999 is the port number. The method of defining this environment variable depends on the platform, so refer to system documentation for instructions on defining this variable.
If there is no firewall to connect to an external network, use the -noproxy flag with the command. For example:
<destination_MT_OH>/dcm/bin/dcmctl validateEarFile -f <full path and filename for ear file> -noproxy
Example 2-1 validateEarFile Command and Output for J2EE-Compliant Application
dcmctl validateEarFile -v -f simple.ear No J2EE XML/DTD validation errors were found
Example 2-2 validateEarFile Command and Output for non-J2EE-Compliant Application
dcmctl validateEarFile -v -f petstore.ear
Warning: J2EE/DTD validation errors were found
ADMN-906001 {0} Base Exception: oracle.ias.sysmgmt.deployment.j2ee.exception.J2eeDeploymentException:Cannot get xml document by parsing /var/tmp/jar50152.tmp: Invalid element 'servlet' in content of 'web-app', expected elements '[servlet-mapping, session-config, mime-mapping, welcome-file-list, error-page, taglib, resource-ref, security-constraint, login-config, security-role, env-entry, ejb-ref]'.
It is a good idea to review all applications for overall J2EE compliance before upgrading them, since there are cases in which an application is deployable, but delivers unpredictable or undesirable server behavior. For example, ensure that each application has a unique context root defined in application.xml.
You can restart the OracleAS Upgrade Assistant after it has partially or completely processed an Oracle home. Follow these steps:
Start the OracleAS Upgrade Assistant GUI version as described in "Performing an Upgrade with the OracleAS Upgrade Assistant (Graphical User Interface (GUI) Version)", or the command-line version as described in "Performing an Upgrade with the OracleAS Upgrade Assistant (Command-line Version) ".
The OracleAS Upgrade Assistant displays one of the following messages, depending on the outcome of the previous upgrade:
If the previous upgrade was unsuccessful, then the message is:
The OracleAS Upgrade Assistant has already processed this destination Oracle home directory, it didn’t complete successfully.
If the previous upgrade was successful, then the message is:
The OracleAS Upgrade Assistant has already successfully processed this destination Oracle home directory.
Close the dialog and continue with the upgrade.
