on 11-11-2013 8:58 PM
Hi,
Can anyone please help me narrow down an issue where a scheduled "Delete PSA Request" that has historically taken no more than 5 minutes to complete (in process chain) is now taking more than 8 hours? What are some of the things that I can look at to determine why this is the case? Thanks in advance!
Hi ,
Normally index creation or deletion takes longer time when your database statistics are not updated properly, so you can check databease stats after your data loading is completed and index generation is done.
If the following chain is running number of times in a day then you need not delete and create the Index again and again .
Then you can remove the delete and create index step from the Original chain and create an separate chain with delete and create index step and run it once when you have less load on the system .
Hope this helps .
Thanks
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Are you facing the same while manually deleting the PSA?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Are you using a SQL Server db by any chance? There's an snote for PSA performance issue with this DB.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Have you checked/analyzed the PSA deletion job log in the process chain-->Display messages?
You can understand easily which step is taking long time and Why?
I feel you must have more BGds available in SM50. You can split your variants in to two branches in the chain and distribute the datasources equally.
You can find PSA tables in RSDSTS, RSTSODSPART tables
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Suman,
I did. I looked at the displaying messages and noted that one of the logs that took the longest was:
"Request REQU_# deleted from PSA;
RSREQICODS entry also deleted"
The above step started at 8:47 AM and it was not until 14:55 that the next step started
And then again, another one of these was logged at 14:58
"Request REQU_# deleted from PSA;
RSREQICODS entry also deleted"
but it was not until 19:24 that it had to be manually cancelled by our team.
I also went on SM37 to see these entries but I do not get much info other than start time and description. How can you easily tell the "why" part of taking too long from these logs? especially with a request that was already deleted from PSA....thank you again!
You can check parallely in SM50 while deletion of PSA job going on. I mean you can see what all SQL statements have been running and where it is spending long time etc..
I suspect there are no proper indexes on RSREQICODS table. That's why your job spends lot of time there, it seems. Try to create indexes on it and run your deletion job again.
Message was edited by: Suman Chakravarthy K
Hi
Have you tried with tx RSRV -> PSA Tables -> Consistency Check for PSA?
Sounds like an inconsitency in your psa table
Hope it helps
Martin
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi ,
Am not sure, try to check table RSPCPROCESSLOG, process type as PSA_DEL(similar term) keep filter and check it out. you will get all psa deletion chains which are have. finding to particular might be hard.
As you said your PC chian takig more time mean you will know the process chain so thru that we can know the psa/data source.
Coming to your issue:
As my guess your data source may be disturbed.so better to try to activate your Data source by using program"RSDS_DATASOURCE_ACTIVATE_ALL" and later check it.
Thanks
User | Count |
---|---|
76 | |
10 | |
9 | |
9 | |
6 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.