Oracle® Application Server Upgrade and Compatibility Guide 10g (10.1.4.0.1) for UNIX Part Number B28188-01 |
|
|
View PDF |
Often, you can troubleshoot common problems by reviewing the log files generated by Oracle Universal Installer and by the Metadata Repository Upgrade Assistant. Refer to the following sections for more information:
When you use Oracle Universal Installer to upgrade your upgrade OracleAS Identity Management or the OracleAS Metadata Repository database, you can troubleshoot certain upgrade issues by reviewing the log files generated by Oracle Universal Installer.
Two sets of Oracle Universal Installer log files are saved on disk:
The installer generates the following log files:
oraInventory_location/logs/installActionstimestamp.log oraInventory_location/logs/oraInstalltimestamp.err oraInventory_location/logs/oraInstalltimestamp.out DESTINATION_ORACLE_HOME/install/make.log
The configuration assistants generates log files in the DESTINATION_ORACLE_HOME/cfgtoollogs
directory.
Note that if you want to access the log files created by the configuration assistants, you need to exit the installer first. The log files are inaccessible if the installer is still in use.
The location of the Oracle inventory directory (oraInventory_location in the previous example) is saved in the following file:
On Solaris systems:
/var/opt/oracle/oraInst.loc
On Linux systems:
/etc/oraInst.loc
When you run MRUA, the utility generates a set of log files that you can use to troubleshoot, verify, or analyze the OracleAS Metadata Repository upgrade process. For more information, see the following sections:
If the MRUA output indicates that one or more of the component upgrades failed, review the MRUA log files, or any component log files referenced from the MRUA log files.
If the OracleAS Portal upgrade fails, then see Section D.3, "Reviewing the OracleAS Portal Repository Upgrade Log Files" for information on how to proceed.
If, by reviewing the log files, you are able to identify a solution to the upgrade failure, then you can implement your solution and re-run MRUA. When you re-run MRUA, any components that were upgraded successfully during the previous run will not be affected. However, MRUA will attempt to upgrade any components that were not upgraded successfully during a previous run of the utility.
Contact Oracle Support for any errors that are not documented or that cannot be resolved by following documented actions. Note that some errors that occur will require the repository to be restored from backup, the problem to be resolved, and another upgrade to be run.
The log files are located in the following directory in the Oracle home of the OracleAS Metadata Repository you are upgrading:
METADATA_REPOSITORY_ORACLE_HOME/upgrade/logs
MRUA generates three log files that are of particular interest when you are troubleshooting upgrade issues. The name of the log file includes the exact time the MRUA session was run. This makes it easy to identify a log file for a particular MRUA session.
For example, the three log files generated when you run MRUA at 12:36 PM on September 16, 2004 would appear as follows in the logs directory:
mrua2004-09-16_12-36-36PM.log mrua2004-09-16_12-36-36PM.err mrua2004-09-16_12-36-36PM.out
Table D-1 shows the three log file types and the content you can expect to find in each one.
Table D-1 Summary of the Log Files Generated by MRUA
MRUA Log File | Description |
---|---|
mrua<timestamp>.log |
The log file is a good place to start if you are troubleshooting a particular problem with the OracleAS Metadata Repository upgrade. This file contains a high-level summary of all the actions performed by MRUA; as a result, it can help you isolate a specific component that was not upgraded successfully. |
mrua<timestamp>.err |
The error file contains any errors or stack traces generated during the upgrade process. These errors should contain information that help you diagnose and address specific upgrade errors. |
mrua<timestamp>.out |
The output file is the largest of the three MRUA log files and it contains the most comprehensive data about the MRUA session. Use this log file to determine exactly when a particular problem occurred to and see the output generated by the MRUA subcomponents. |
This section provides information about the OracleAS Portal upgrade log files. If the OracleAS Portal upgrade fails, carefully review this section in its entirety before attempting to troubleshoot the upgrade failure.
Note that if the OracleAS Portal components were upgraded to 10g Release 2 (10.1.2) successfully, then there is no need to examine the log files.
When upgrading OracleAS Portal by running MRUA, the log files are generated into a single directory:
ORACLE_HOME/upgrade/temp/portal
Note that any already existing log files in the relevant directory will be renamed to include a time stamp, so that they are not overwritten.
Table D-2 Summary of the Repository Upgrade Log Files Generated by OracleAS Portal
Log File | Description |
---|---|
The log file generated by the 10g (9.0.4) to 10g Release 2 (10.1.2) OracleAS Portal upgrade. This file will always be generated if the starting version is 10g (9.0.4), as long as the checks performed at the beginning of the upgrade succeed. |
|
The log file generated for the checks performed before the 10g (9.0.4) to 10g Release 2 (10.1.2) upgrade. This file is generated before the script begins making modifications to the repository, or when a manual upgrade from 10g (9.0.4) is run in -precheck mode. If there are errors in |
At the end of each one of these log files, there is either a success message or a summary of all the errors that occur earlier in the file. These summary messages include references to line numbers. You can go to those lines earlier in the log file to see the errors in their context.
Caution: Any portals running after an upgrade that was not clean are not supported by Oracle. |
Look up any errors found in the precheck or upgrade log files using Section E.3, "Portal Repository Upgrade Messages" as a reference. Resolve any errors and warnings that have documented actions. Any errors that occur after the precheck phase require the repository to be restored from backup, the problem resolved and another upgrade run. Contact Oracle Support for any errors that are not documented or that cannot be resolved by following documented actions. When undocumented errors are found, do not attempt to run the upgrade again, run any further steps, alter any files, modify the OracleAS Portal schema, or access the OracleAS Portal instance in your browser.
The following is an example of the end of the log file after a successful upgrade (note the "Upgrade completed successfully" message and the lack of error messages):
>>> Running upg/common/popinv.pl ### Upgrade completed successfully >>> Running tmp/popinv.sql Portal SQL script started at Thu Apr 22 20:56:23 2004 Connected. Updating patch inventory. Upgrade Ended at Thu Apr 22 20:56:24 2004