This topic contains the following topics:
If errors occur while you are running the Upgrade Assistant, use the following steps to troubleshoot the problem:
If you get any errors during Examination phase, and no components or schemas have been upgraded yet, run the following command to perform a thorough readiness check. The types of checks performed by the readiness check are more thorough than Examination phase of upgrade. Examination phase is read-only and you can rerun it.
On Unix operating machine: ./ua -readiness
On Windows operating machine: ua.bat -readiness
Errors that occur during the Upgrade phase, however, require you to restore your environment from your backup copies, correct the errors and then restart the upgrade process from the beginning.
Your corrective course of action will depend on the phase in which the error occurred.
-logLevel from the command line. The default value is -logLevel NOTIFICATION. You can alter the location of your log files using the -logDir parameter. You can obtain a more detailed logging information by running the Upgrade Assistant with -logLevel TRACE parameter. However, in some situations, this can cause the log file to become very large.
Note:
TRACE messages are not included in the Upgrade Assistant Log File Viewer. To view TRACE messages you must use another tool of your choiceTip:
To expedite the review process, search for the word "ERROR".For more information on understanding error messages in your log files, see Resolving Common Upgrade Assistant Errors.
Log files are stored in the following default directory:
On UNIX operating systems:
ORACLE_HOME/oracle_common/upgrade/logs/ua<timestamp>.log
On Windows operating systems:
ORACLE_HOME\oracle_common\upgrade\logs\ua<timestamp>.log
Some components will create a second log file called ua<timestamp>.out, also in the same location.
Where, timestamp states the actual date and time when the Upgrade Assistant was run.
For database schema upgrades of certain components, there can also be an output (.out) file that will contain the screen output of commands that were run in a shell process or as PL/SQL scripts. You can locate these output files in the same default directory.
In the event that there are questions or issues about an upgrade failure that cannot be resolved with the information in this guide, it will be important to retain the log files. If you must raise a service request, you must upload the entire Upgrade Assistant .log file and the .out files (if available) along with the service request.
To complete the upgrade, resolve the issues and then launch the Upgrade Assistant again, or, if possible, click Back to return to a previous screen and make the necessary changes.
Note:
The readiness check feature performs checks to a far greater level of detail than the Examination phase. If examine fails you should run the Upgrade Assistant with the-readiness parameter and make sure the report does not show any test failures.Issues detected during the Examination phase can be resolved without restoring from backup. However, if you attempt to resolve an examination error in a way that changes the state of the system, you should take an another-point-in-time backup and retain all such backups. Also, you need to restore the entire system to that point-in-time before anything was changed or any upgrade operations were attempted. Issues detected during the Upgrade phase, however, cannot be resolved. The pre-upgrade environment must be restored from backup to a point-in-time before any of the upgrade operations was attempted. If a partially upgrade system encounters upgrade errors later, the entire system must still be restored.
To determine the cause of an upgrade failure:
To complete the upgrade, restore the entire environment using your pre-upgrade backup, to a point in time before any upgrade operations were attempted, resolve the issues and then launch the Upgrade Assistant again. You will have to start the upgrade process from the beginning to ensure a successful (complete) upgrade.
Note:
You should be backing up all databases with RMAN and be able to do a point-in-time recovery from those backups. If the Fusion Middleware repository for your domains spans multiple Oracle Database server, you must restore from each of those backups.If errors occur while you are running the Upgrade Assistant, you must correct the conditions that caused them before you try the upgrade again. The following sections provide some common errors that can occur.
This section provides descriptions of the most common upgrade errors. For a complete list of Fusion Middleware errors, see the Error Messages guide.
If an upgrade fails due to the database server running out of disk space, you must restore the database server environment from backups, add sufficient disk space or remove unwanted files (such as temp or trace files) from the database server, and then retry the upgrade.
NOTE: Once a database schema upgrade has failed due to this class of error, you cannot simply add more disk space and retry the upgrade. The schemas have been left in an inconsistent state and may have been marked "INVALID". You cannot recover from this error without restoring the original database state from backups.
The following examples show some insufficient disk space errors you may encounter:
ORA-01658: unable to create INITIAL extent for segment in tablespace
Cause: The existing schema tablespace does not have sufficient space to complete the upgrade.
Action: Make sure that the tablespace has sufficient room (space) for a successful upgrade. Oracle recommends that you add more data files to the existing database tablespaces, otherwise the upgrade will fail.
ORA-01114: IO error writing block to file <block number>
Cause: The device on which the file resides is probably offline. If the file is a temporary file, then it is also possible that the device has run out of space. This could happen because disk space of temporary files is not necessarily allocated at file creation time.
Action: Restore access to the device or remove unnecessary files to free up space.
ORA-09945: Unable to initialize the audit trail file
Cause: The system is unable to write header information to the file being used as the audit trail. The audit_trail_dest or audit trail destination is full for generation of audit file.
Action: Free up space and retry the operation.
If you have trouble connecting to a database when using the Upgrade Assistant to upgrade a component schema, try connecting to the database using another tool, such as SQL*Plus. This will help you troubleshoot the problem by verifying that the database is up and running and available on the network.
When running Upgrade Assistant in GUI mode, you must set the DISPLAY variable properly or you may receive errors such as:
Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified
Cause: These errors indicate that the DISPLAY variable is not set up properly to allow a GUI to be displayed to the screen.
Action: Set the DISPLAY environment variable to the system name or IP address of your local workstation, and re-run Upgrade Assistant.
If you continue to receive these errors after setting the DISPLAY variable, try launching another GUI tool, such as vncconfig. If you see the same errors, your DISPLAY environment variable may not be set correctly.
If you receive an error stating that the specified domain cannot be upgraded, you must first upgrade the domain to a supported version. Do not attempt to upgrade schemas or domain configurations in an unsupported domain.
If the Upgrade Assistant fails during the upgrade phase or only partially upgrades your components, try to resolve the and then follow these steps:
If you continue to experience upgrade failures, consider setting the -logLevel to TRACE so that more information will be logged. This will be useful when troubleshooting a failed upgrade, but be sure to reset the -logLevel to NOTIFICATION after the issue has been resolved to avoid performance issues.