Question:
Hello SAP Fans
It might seem fun but it is not.
After deleting planning requests from the cube, we found that one layout in on planning folder (sales planniing) still shows "old data"!!!
We confirmed that there is no request for planning data, we checked with a Bex query and we checked the selections in the layout...
No luck...we can't understand what is going on....Maybe it is a DB problem (would not be the first...).
Well, I appreciate any help,
Thanks
_________________
SemWave
FI/CO/SEM Consultant
Answer:
Hi,
I can suggest a couple of things to try.
1. See if you can view the data in LISTCUBE. This will determine whether BPS is reading data that physically doesn't exist.
2. If you can see the data in LISTCUBE, the "old data" may be tied to a request that is still open. The request may not show up, e.g. in RSA1 in that case. Run RSAPO_CLOSE_TRANS_REQUEST to close all outstanding requests and try again.
If the data does not show up in LISTCUBE...
3. BW 3.X only reads from the cache if the data is there. The cache might have got out of sync with the DB somehow. Try to force your BW query to read from the DB vs the cache and see if you get different results. You can control that from RSRT.
4. I've see Oracle returning wrong results due to bit map index problems before. Try dropping and recreating indexes for the cube.
CF
Answer:
Hi,
I can suggest a couple of things to try.
1. See if you can view the data in LISTCUBE. This will determine whether BPS is reading data that physically doesn't exist.
2. If you can see the data in LISTCUBE, the "old data" may be tied to a request that is still open. The request may not show up, e.g. in RSA1 in that case. Run RSAPO_CLOSE_TRANS_REQUEST to close all outstanding requests and try again.
If the data does not show up in LISTCUBE...
3. BW 3.X only reads from the cache if the data is there. The cache might have got out of sync with the DB somehow. Try to force your BW query to read from the DB vs the cache and see if you get different results. You can control that from RSRT.
4. I've see Oracle returning wrong results due to bit map index problems before. Try dropping and recreating indexes for the cube.
CF
Thanks CF,
Data was not in the cube (2x check with query and listcube.)
So, how can we sync the cache with DB? Is this something that should be prevented/controled someway?
About Oracle: how is it done? Should be done periodically?
We will issue a message for SAP anyway - I think they must solve this Oracle/SAP bugs as soon as possible - or our users can loose their trust in BPS reliability. This data is too much important - it crosses all functions in the company, from marketing, sales, to manufacturing...
There is no room for this kind of errors...
Thanks,
_________________
SemWave
FI/CO/SEM Consultant
Answer:
Hi,
I think you are right to get SAP involved on this.
Anyway, in transaction RSRT, you can enter the query name, then click on Execute + Debug. There you will be able to execute the query in variously ways by turning the use of cache, DB optimizer, aggregate etc. on and off. If you can get the query to retrieve the phantom data by tweaking these parameters then it might give you a clue as to what caused the problem in SEM. Also within RSRT, there is a cache monitor button. I think you can delete the cache from there.
In transaction RSA1, go to InfoProvider and select Manage. You should see options to delete and re-create indexes under the Performance tab.