cancel
Showing results for 
Search instead for 
Did you mean: 

Dump when starting DB02 DYNPRO_FIELD_CONVERSION

Former Member
0 Kudos

Hello together,

when I started the TCODE:  DB02  in our SOLMAN  I got the following DUMP:

Environment:

Anyone an idea, how to fix this Problem?

I've found the SAPNOTE 1320615   but this is not for our Release 7.02.

Best regards,

Mathias

Accepted Solutions (0)

Answers (2)

Answers (2)

Reagan
Product and Topic Expert
Product and Topic Expert
0 Kudos

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.

kaus19d
Active Contributor
0 Kudos

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.

Note:-1703434

Thanks,

Kaushik

Former Member
0 Kudos

There is enough free space

kaus19d
Active Contributor
0 Kudos

for database check using t-code DBACOCKPIT. What about the other, that I mentioned in the last reply? Is this happening in a new installation?

Former Member
0 Kudos

I've checked the other postings but didn't found a solution.  When I press the Tab SPACE-->SPACE Overview  then the dump occurs, too.

.Last Weekend, we've increased the following buffer Parameters:

rsdb/ntab/entrycount

rsdb/otr/max_objects

zcsa/db_max_buftab

rtbb/max_tables

kaus19d
Active Contributor
0 Kudos

the new & current values please(can be checked via RZ10) & hardware config please post

Former Member
0 Kudos

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????

kaus19d
Active Contributor
0 Kudos

Hi ,

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

Former Member
0 Kudos

The Dumps occured again after executing the DB02

I don't know what to do??

BR

MAthias

kaus19d
Active Contributor
0 Kudos

Hi ,

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,

  • run report through SE38 " SAP_DROP_TMP_TABLES "
  • clear some logs like running a archive_log job through db13
  • plan for the other dependency parameters change that I mentioned in the earlier post, might involve a restart.
  • Check ST02
  • Check in SM50 & terminate & change unwanted jobs timing-schedule.

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