We are also thinking of the same.. but the database is of very less size and complete backup of the database itself is not taking 15 min.
Do you know what these transactions are? why would it cause delay in startup?
Appreciate your help on understanding this step.
Do you know what these transactions are?
From the link I provided - "Performance Management Architect creates transactions in the Performance Management Architect database. This database is automatically created during installation and configuration. Since Performance Management Architect does not delete these artifacts, the database size can increase over time. The Performance Management Architect Transaction History Purge Utility enables you to remove transactions from the database to reduce database size."
Whether this helps your situation I can't say but it is worth investigating.
You also say that EPMA is installed on a VM, have you checked with the team that manages the VM infrastructure to see whether there is any resource connection that be causing severe performance degradation.
we ran purge utility but issue is still exist
What exact change have you made in the BPMA_Server_Config file?
Have you made any recent changes in the application like added huge dimensions etc.?
If it is VM, you can still restore the environment from the date when this worked fine for you and then test the issue again.
we changed this parameter, only then we are able to start the service but is still taking around 30 minutes.
only EPMA server is in VM so we cant actually restore in this case..
How many EPMA applications do you have on this environment? Do see any issues in working with the existing applications at this point in time?
There are 7 applications which is same in lower environments as well.. there are no issues related to performance or slowness once the epma server starts.
Can you try bouncing DB and EPMA VM. Some time this resolve such issues.