Problem:

You notice that while running ADPATCH you encounter an error and you are being prompted if you want to proceed. What are the types of errors and what should you do?

Solution:

There are two types of errors: Fatal in which ADPATCH halts and Non-Fatal errors where users are prompted if they want to proceed.

if the user answers YES, adpatch skips the operation it was trying to complete and notes in the $APPL_TOP/install/log/adpatch.log file that it was completed.



Problem:

You answered "Yes" to proceed with the patch when it encountered a Non-Fatal error. How can you get ADPATCH to execute that operation again?

Solution:

The only way to get back to the same point is to restart the patch from the beginning.



Problem:

What happens if adpatch fails on a PL/SQL script?

Solution:

We can execute PL/SQL scripts on sql prompt after reviewing ADPATCH log file. We can also get syntax and parameter for the scripts from log file.



Problem:

What happens if the patch fails? You are being prompted to restart the patch when you start ADPATCH.

Solution:

We can try to restart the ADPATCH with previous session or new session. By default patch will start from where if failed



Problem:

You have decided to start all over and resubmit ADPATCH from the beginning, but you get the error that FND_INSTALL_PROCESSES already exits. How is FND_INSTALL_PROCESSES related and why does ADPATCH have a problem with it?

Solution:

FND_INSTALL_PROCESSES is a table that is created by AUTOINSTALL, ADPATCH and ADADMIN utilities. Normally the above utilities will remove this table after they complete.




This table might exist if you are running any of the above processes. So, if you are also applying another application patch at the same time, the table might exist for the other patch. AUTOINSTALL and ADPATCH should NEVER be run at the same time.

Dropping the FND_INSTALL_PROCESSES table should only be done if you are NOT in the middle of running AUTOINSTALL, ADADMIN or applying another patch. In the case of AUTOINSTALL this table along with the restart files in the $APPL_TOP contains all of the information needed to restart AUTOINSTALL.

Consider this scenario

You are running the install and you get instructions to obtain a patch (usually this would be an FND patch) and you attempt to use ADPATCH to install the patch. If you were to drop FND_INSTALL_PROCESSES at this point, you would have to start your install over. However, you could backup FND_INSTALL_PROCESSES and the restart files. Then run adpatch to install the patch. Then restore FND_INSTALL_PROCESSES and the restart files, and continue the installation.

Problem:

ADPATCH has failed and it indicated there was an error with a worker. What steps can be taken to investigate this problem?

Solution:

When ADPATCH is using workers, it (ADPATCH) keeps track of what jobs the workers are doing with a table in the database called FND_INSTALL_PROCESSES. Look at the bottom of the log file associated with the worker that failed (i.e. adwork01.log or adwork02.log or adwork03.log)



There is a utility ADCTRL that can be used to update FND_INSTALL_PROCESSES. This utility will allow you to reset a flag in FND_INSTALL_PROCESSES. This will allow ADPATCH to restart the failed step.



ADCTRL has a menu with 7 options.



Choose option one on the ADCTRL menu to review the worker status. Other workers will wait for the failed worker.



Choose option two on the menu to fix the worker. Place in the worker number and hit return.



Check the status of worker again using option one. The status should have changed to "fixed restart."



Try restarting the patch again.



Problem:

ADPATCH continues to fail and you have successfully completed the sql statement from the command line. Is there any way to direct the patch to skip this sql and continue?

Solution:

Insert the following at the very top of the script that failed:



exit ;



Go into ADCTRL and set the worker that failed to fixed/restart (as above). Then restart ADPATCH.



Problem:

What should you do if a patch has errs while trying to relink ar25desb?

Solution:

The ar25desb is very similar to the reports executable r25convm. Try and remake r25runm. If r25runm does not remake it is a UNIX problem and should be transferred.



The syntax is: $ORACLE_HOME/reports25/lib (when doing the below you need to be ORACLE)



make -f ins_reports25w.mk r25runm






Problem:

Your patch is erring with an Undefined Symbol. What does this mean and what can you do to resolve this issue?

Solution: The error generally looks like this:



Can't relink APVOID.ABI



An undefined symbol means ADPATCH cannot find a reference to a symbol in the archive file (ex. $FND_TOP/lib/libfnd.a) which was archived from the .o file contained in the patch library directory. The undefined symbols that it cannot fine are listed following the error message.



You can try the nm command searching the library for something that references that symbol:



nm *.o |grep I afmall



(afmall in this case is the undefined symbol)



The object files are binary. Use the following command to put the libfnd.a file in a text version that you can read:



nm libfnd.a > tmp



Use VI to edit the .tmp file and search for the undefined symbol. When you view the file you will notice that each .o is listed and there are a large number of objects. A symbol will only be listed once in each object file (.o).



The .o file is listed at the top and the columns are listed below.



The name column will contain the names of the symbols. The Shndx column will contain the text UNDEF or it will contain a number. The number is referencing what the symbol means. Use the find command in VI to locate the symbol where a number appears in there Shndx column next to the symbol that is erring. You shouldn't find one that is what is causing the undefined symbol. You will need to find the object file that defines this symbol. If this was working and you were applying a patch start with the patch. Also path problems can cause this type of error.



Problem:

You want to know if you can reapply a patch. Will this cause problem?

Solution:

We can almost always reapply patches without a problem. If a patch cannot be reapplied, there will be a warning in the README file. However, problems may exist if you are trying to reapply a patch where you have already applied a later version of the same patch. One example is applying FND Patchset A, then FND Patchset C, then trying to reapply FND Patchset A.



Problem:

A patch is failing on a column with one of these error messages:

ORA-904

ORA-942

Solution:

Make sure you have completed all the manual steps in the readme file. "bad magic" error



This error is normally caused, by running the wrong platform patch (i.e. An HP-UX patch being run on a SUN platform).



We will need to back-out what has been applied and reapply the correct platform patch.