been trying to understand the core interface table MAX - where in the object type for eg: T_SLS has about 90 entries and has segment numbers from 001 to 0090 - cannot understand why there is so much entries for a each object type.
my question for each objects for Eg; T_SLS we have about 91 entries. how does this entires form? Are all of these entries required? I dont see these entries getting bigger when running RIMODAC2 or RIMODINI. Are these really required or only 1 entry per object is required?
CIF_IMAX is a synthesis of the data found in the various CIF_I* tables. If you have any question as to whether the contents of this table are right or wrong, just regenerate it using report RCIFIMAX. Regeneration generally only takes a few minutes at most.
In general, if you perform the standard recommended reorganization activities periodically, you can pretty much ignore the contents of these technical tables.
I am curious why you are questioning the contents of this table. Is it causing some kind of problem?
We are facing performance issues since last few weeks and can see from the SM50 / SM66 that its taking time in CIF_IMAX update, causing delay in delivery creations etc.,
Did you have a similar issue in the past on CIF_IMAX?
I have never known the size of CIF_IMAX to cause any problems. In the end, when you compare table sizes, CIF_IMAX is not what I would call a large table. One wonders just how much a change in the number of records would improve performance issues.
"Delay" is a subjective term. Since this is a queued interface, one cannot expect instantaneous updates. Each business has to decide how much delay is acceptable.
In my experience, the biggest problems with slow updates through the core interface are poorly written customer enhancements. That would be the first place I would look.
If you are using outbound queues, and the traffic is heavy, you can sometimes improve throughput by switching to inbound queues. There can also be some benefits by changing block sizes for certain model types. These are relatively easy things to experiment with and implement.
And finally, you can always raise a message to SAP to have them examine your system.
we have seen stuck in the reservation table RESB and is taking a very long time, also seeing a hige failure in CCR jobs becasuse of System failure error. since reservation is linked to SO, Assets, Production order, sales order etc., do u see any issues here.
"System failure" is meaningless to me; it can have a number of root causes and even more possible solutions, depending upon the exact nature of YOUR system and the contents of the system failure messages.
It is not likely you are going to find the answers to such a problem within an SCN forum. I suggest that if you have exhausted your searches of SCN and OSS, then you open a message with SAP.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.