Automic schema tables

[Shravya Devadiga]

Hi Community,

 I have observed the huge data in some of below tables, is it suggestable to purge the data in below tables?

Can you Please confirm

 

TABLE	PROCESS_D	RECORD_COUNT
AH	24-Nov-25	885226
AH	25-Nov-25	755672
AH	26-Nov-25	218777
EH	24-Nov-25	23446
EH	25-Nov-25	28582
EH	26-Nov-25	20758
MQSRV	25-Nov-25	154
OH	24-Nov-25	34279
OH	25-Nov-25	31217
OH	26-Nov-25	7356
RH	24-Nov-25	1369529
RH	25-Nov-25	1158267
RH	26-Nov-25	343386
RT	24-Nov-25	26941533
RT	25-Nov-25	23699594
RT	26-Nov-25	7773823

Table Name	Count (ROWS)
EJ	9678725  Rows
EFC	3252356  Rows
EPPF	3251381  Rows
ESTP	10057127  Rows
EOI	5144  Rows
EJPFV	79285  Rows
EJPPC	5679  Rows
EJPOV	24456831  Rows
EJPPF	96421  Rows
EJPPA	24890505  Rows
EJPCV	399085  Rows
EJPPO	28648386  Rows
EJPPV	2846381  Rows
EV	453786349  Rows
ECV	115738581  Rows
EJPP	30291753  Rows
EPUD	611259  Rows
EVP	43  Rows
EY	53259  Rows

 

Thanks & Regards

Shravya 

-------------------------------------------

[Markus Embacher]

Hi Shravya,

do not purge any data from Automic tables unless instructed by our Support team.

The data in the A* tables is the execution history. Data in E* tables is the process monitoring view in AWI.

For cleaning up the A** tables please use the DB.Archive, DB.Reorg and DB.Unload utilities to maintain the data in those tables. It is recommended to automate those tools using an Automic workflow and to run it on a regular basis.
You can find more information in our documentation:
https://docs.automic.com/documentation/webhelp/english/ALL/components/DOCU/24.4.0/Automic%20Automation%20Guides/Content/Utilities/admin_Utilities_Overview.htm?Highlight=utilities

The data in the E** tables is very concerning, because it means, that there are a lot of activities in the Process Monitoring which were not cleaned up (deactivated). To have a performant Automic system it is very important to care about deactivating tasks from the Process Monitoring when they are finished. The normal process is to define an automatic deactivation on workflow level or to deactivate workflows manually. Since the number of records is huge I recommend opening a case with Support and ask for help on cleaning up those activities. 

https://docs.automic.com/documentation/webhelp/english/ALL/components/DOCU/24.4.0/Automic%20Automation%20Guides/Content/AWA/Objects/obj_attributes_defining.htm#TaskDeactivation

I'm assuming that the number of records in the E* tables is already significantly impacting the overall performance of your Automic system. 

Regards, Markus 

-------------------------------------------

[Shravya Devadiga]

Hi Marcus,

Thanks for your valuable response!

We have some issues while clearing the deactivate tasks from process monitoring perspective, we are trying to clear it manually, but it is not clearing. And we are maintaining the ILM partition and dropping it in timely manner.

Kindly suggest if we can take any other action on this issue, as you mentioned we are having some challenges on application.

Regards,

Shravya

-------------------------------------------

[Markus Embacher]

Hi Shravya,

please switch the view in process monitoring from list view to tree view and look for top level workflows. then deactivate those top level workflows. It will also deactivate the tasks within those workflows. Start with oldest workflow tasks first.

When using ILM make sure you still run the Reorg and Unload utility in order to get rid of objects in the recycle bin and to reorganize versioned objects.

ILM partitions cannot be checked and dropped if related activities are not deactivated in process monitoring. 

If it turns out there are too many tasks left for deactivation open a case with Support and ask for help cleaning up the tables.

Regards, Markus

-------------------------------------------

[Shravya Devadiga]

Hi Markus,

No more executions are pending in process monitoring as we are clearing it. ILM is being dropped once a week and AE maintenance is also being performed Still we could see the data is more in EJ**, MELD, AH tables. How can we reduce the size of the tables to avoid the impact?

TABLE	PROCESS_D	RECORD_COUNT
AH	24-Nov-25	885226
AH	25-Nov-25	755672
AH	26-Nov-25	218777
EH	24-Nov-25	23446
EH	25-Nov-25	28582
EH	26-Nov-25	20758
MQSRV	25-Nov-25	154
OH	24-Nov-25	34279
OH	25-Nov-25	31217
OH	26-Nov-25	7356
RH	24-Nov-25	1369529
RH	25-Nov-25	1158267
RH	26-Nov-25	343386
RT	24-Nov-25	26941533
RT	25-Nov-25	23699594
RT	26-Nov-25	7773823

Table Name	Count (ROWS)
EJ	9678725  Rows
EFC	3252356  Rows
EPPF	3251381  Rows
ESTP	10057127  Rows
EOI	5144  Rows
EJPFV	79285  Rows
EJPPC	5679  Rows
EJPOV	24456831  Rows
EJPPF	96421  Rows
EJPPA	24890505  Rows
EJPCV	399085  Rows
EJPPO	28648386  Rows
EJPPV	2846381  Rows
EV	453786349  Rows
ECV	115738581  Rows
EJPP	30291753  Rows
EPUD	611259  Rows
EVP	43  Rows
EY	53259  Rows

Regards,

Shravya Devadiga

-------------------------------------------

[Markus Embacher]

Hi,

based on the information provided I think the data you are seeing reflects the data being generated at normal workload of your Automic instance. But I am not able to verify that based on that data. Your queries are showing EH for a couple of specific dates, but the other E-tables show the total number of records. All other tables are child-tables to EH. How many days/weeks (how many ILM partitions) you keep in you DB?

Regards, Markus 

-------------------------------------------

[Shravya Devadiga]

Hi Markus,

We usually keep 14days of data in DB (3 sets of ILM) and clear remaining. EH table also is not having much data.

Need to know how the EJ** and some other tables having more data, how that can be cleared?

Regards,

Shravya Devadiga

-------------------------------------------

[Markus Embacher]

Hi Shravya,

please provide the following output:

select count(*) from ev where ev_ah_idnr not in (select eh_ah_idnr from eh);

If the count is 0 then it means all the records in the EV table belong to current tasks in the Process Monitoring. If the count is > 0 then there are orphaned records (please open support case and ask for clean-up SQL statements).

Regards, Markus

-------------------------------------------