Project and Portfolio Management Practitioners Forum

Transaction Tables

Super Contributor.

Transaction Tables


We use loops with timeouts in out workflows, and as a result the volume of data in the Transaction tables has tremendously increased(to a 7 digit value), we extended the Index Tablespace, but was hoping if it would be safe to delete the rows in

Would there be an issue in performance if the tables 'KWFL_STEP_TRANSACTIONS' and 'KWFL_TRANSITION_TRANSACTIONS' have huge amounts of data?

Does anyone use looping with timeouts too?

Any Help is appreciated.

Darshan Bavisi
Outstanding Contributor.

Re: Transaction Tables

Hello Lizabeth,

Can you elaborate if possible the exact business requirement for the loops with timeouts in the workflows? That may help understand if alternate ways may be possible or not in your scenerio.

In case if you must keep it as is, then you may keep archiving these tables, at a regular frequency, out of the schema for primarily two reasons:

1. It will help maintain your audit history as and when required anytime by accessing the archived tables.

2. It will help maintain the application and database performance good all the time by reducing the amount of data in these tables.

So after you archive these tables, you can then safely delete the data from these tables, say all data prior to a month old. You can first also test the retrieval of archived data by writing a SQL (and may be database links) before deleting the data from these tables.
Shashank Mane

Re: Transaction Tables

Low timeouts will keep inserting multiple records in workflow transaction tables. These tables are accessed while rendering the request in the browser. The "Status" & "Transaction Details"section of the request will display information from these tables. There is a way to get rid of some of the unnecessary data from the system but the care must be taken to ensure that the data is really not needed in future. e.g. any compliance norms that require this data to be available on demand.

If these tables have grown really big, truncating data from some of these tables will also show you some performance gain. We have developed a custom solution to address this problem. If you need any details on the solution, let me know.(

As Darshan suggested, you can also relook at the workflow design to see if you can handle these cases differently.

Super Contributor.

Re: Transaction Tables

Thanks for your reply Darshan,Shashank,

We have a Parent Child Scenario, and the Parent proceeds to the next step in the workflow only if the Child Request is at a particular step, thus keeps looping.

The only disadvantage of Purging data is that the Transaction History/Graphical views will not be generated for this data.

We are thinking of increasing the timeout to a larger value, which might help a little

Thanks again