How long should they take? What has changed in the meantime? Is the server running ok? Changes in the network?
We are not clairvoyant here, although it would definitely help. I would look to run some diagnostics and monitoring on the server as a starting point. Maybe investigate installing ProTop (the free version will do just great).
I get questions like this from time to time, where someone asks a question that implies they have already jumped to a conclusion.
If the application is slow, and in particular slower than it used to be, how do you know that the problem is the database being slow? Do you have evidence that someone changed the database configuration for the worse?
Have you investigated other possible contributing factors, e.g.:
Thank you for your answer.
We are doing execute this menu in batch job and see in log file,
1. MRP 23.2 - 16hrs., last month 4-6 hrs.
2. BOM Roll-Up 13.12.13 - 5hrs., last month 1-2hrs.
3. Routing Roll-up 14.13.13 - 5hrs., last month 1-2hrs.
Now, we found corrupt record in tr_hist and we would like to rebuild index for this weekend.
What is your evidence for having found a "corrupt record"?
Depending on what you have actually found you may, or may not, have a good reason to rebuild one or more indexes.
It is unlikely that a single "corrupt record" is responsible for the sort of performance difference that you describe and rebuilding one or more indexes is not very likely to result in any significant performance improvement.
It is far more likely that there has been a change in your environment. Some of the more common changes that lead to this sort of dramatic performance loss are:
- migration to new hardware
- conversion to a virtualized host
- implementation of a SAN
- increased activity by other applications on shared infrastructure
- accidental changes to Progress startup parameters or configuration options