on 09-20-2016 8:39 AM
If possible supply the full dump information from Tx ST22
In the mean while check SAP note 1262315 - DBACockpit: Space Overview Screen Errors and if applicable implement the note and see if the dump occurs again.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Is the physical drive empty space ok/free? Also do check the below,
DYNPRO_FIELD_CONVERSION error in short dump | SCN
DYNPRO_FIELD_CONVERSION when executing tcode DB02 | SCN
Database check error on DB02-->Alert | SCN
Is there any other dumps in ST22? Check for the SAP_BASIS Patch level, might require upgrade.
Thanks,
Kaushik
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I've changed the follwing buffer Parameters:
zcsa/db_max_buftab
old value: 250000
new value: 30000
rsdb/otr/max_objects
old value: 2500
new value: 4000
rsdb/ntab/entrycount
old value: 60000
new value: 65000
Today I started the TCODE: DB02 and no DUMP occurs ... I don't know what happened over night????
Ok, till further the parameters value looks fine to me. Need to check other dependent parameters too, like,
rsdb/otr/buffersize_kb
abap/buffersize
abap/heap_area_dia
abap/heaplimit
abap/swap_reserve
rsdb/obj/buffersize
In addition, I can also give some light here about what would have happened here today & in-between yesterday matter. The thing is the system is adopting to the new parameter changes but it requires the dependent parameters also coupe up at the same time. I also think that had happened due to space allocation to temp memory got a bit freed up if you are running db13 or the default programs which we generally trigger just after install & that jobs delete old job reports/logs such as deleting old/unused spool requests. Lets Say, for example, you have installed & configured your SOLMAN 1st time & you run "SAP_LMDB_LDB_0000000001" job (program name: AI_LMDB_R_SYNC_RUNNER), after running at 1st time as it would start having the required data the very 1st time, so it would take some time to finish up & also would keep some temp memory consumed for the time until its executed completely for the 1st time. If I were you, I would have also get a check on the heap memory. I think when the dump was occuring the SM50 work processes are also occupied & now that you have provided some time, so some of the jobs got cancelled, some finished successfully. Now the cancelled jobs are in generally, the standard jobs we will schedule as periodic, so that cancelled ones, on the next run became successful run to get the desired reports. Sometimes it also happens in some customers case, that due to the Dialogue Work-Processes are captured, the Java part of the SOLMAN not working properly also, like for example, running the MOPZ page very slow. So here What would be the next step of yours is so that this problem does not occurs next time is that you just need to do some SAP-System Performance Tuning Jobs on this System.
Hope it helps. Now that your issue is closed, you may close the thread if felt ok. Also you can try creating a new thread if faced again or some other issues & we would love to provide the required assistance as soon as your issue pops-up to us.
Thanks,
Kaushik
I knew that & that is why I suggested you to concentrate on the performance tuning. I am sorry, What was you system RAM size & hardware configuration, again? It occurs whenever it finds less memory in the temporary/heap to execute jobs.
The To-Do list for now, immediate-basis,
Another important tool here is SAPPFPAR. Also can run via command calling as SAPPFPAR pf=<path of the Instance Profile> to see memory related these kind of issues & recent profile parameters changes.
Thanks,
Kaushik
User | Count |
---|---|
79 | |
9 | |
9 | |
7 | |
7 | |
6 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.