What are some of the common dump errors that can turn up during transactions and how do I solve them?
Thanks in advance.
Following are a number of errors that you can get along with their corresponding solutions
This usually happens when any transaction has fifty or more nested “CALL SCREEN”. The solution is to redesign your transaction to prevent that many nested calls. Note that there ia a distinction between CALL SCREEN and SET SCREEN. While CALL SCREEN creates a new stack and puts the entry in it, SET SCREEN only navigates between screens.
There is not help text available for the above dump. All we can say is that this either happened because the release of the kernel is not the same as the release of the database, or that the text was deleted for some reason. You can look for further information in the note system.
This typically shows up because of the SAPGUI. It is likely that a RAISE statement came up in the program CL_PO_ITEM_HANDLE_MM=======CP and the condition FAILURE was returned. The process was terminated because no superior program took up the exception.
4.ORA-00060: DEADLOCK DETECTED WHILE WAITING FOR RESOURCE
This happens when you try to execute a statement but you end up with a deadlocked session since there is another session that had the same resource locked. There are two possible options to take care of this error: you can either wait a little while for the other session to close and re execute the statement, or you can execute a ROLLBACK since the last time the session was saved i.e. COMMIT was used.
5.ORA-01089 – IMMEDIATE SHUTDOWN
This means that your DBA has decided to start a SHUTDOWN IMMEDIATE command. Oracle swill shut down completely and any active operations will be terminated. There is no way to stop this command so the best you can do is wait until Oracle has been restarted by the DBA.
This error means that a user context or an internal session has been trying to use more than 2 GB of main memory. Since 32-bit variables are frequently used, the Database puts a cap on the stems at 2 B. Consider a way to run a session that requires lower memory consumption. This includes trying to use unsigned 32-bit variables that allow up to 4 GB of transaction space.
Consider if the way you are using the application is in fact the way in which it was intended to be used, or if you have selected too much data. Moreover, check and see if the consumption of memory in your system and in the application depends on any parameters that you have customised. Finally, the application may not actually be a very memory economical one, especially when there are transactions that run for long times.
A tool named “Memory Inspector” is available for use in these situations that decides and lists ranked lists of large internal tables and also indicates discrepancies between large objects. The use of this tool might be useful.
Sign up for STechies
All the site contents are Copyright © www.stechies.com and the content authors. All rights reserved.
All product names are trademarks of their respective companies. The site www.stechies.com is in no way affiliated with SAP AG.
Every effort is made to ensure the content integrity. Information used on this site is at your own risk.
The content on this site may not be reproduced or redistributed without the express written permission of
www.stechies.com or the content authors.