Precisely Enterworks

Hi all,

Wondering if anyone has any insight into what seems to be an abnormally large number of tables (most empty) in the EPIM database. I'm seeing 86k tables with a PLT or PLT...TMP name. These start from the date of our implementation (2019) to currrent. Maybe they are of no concern, but at a minimum, they do cause it to take longer to open the list of tables.

We are currently on v10.5.3

Thanks!

Mark,

Those tables are associated with previous import jobs and can be removed if they are more than a day old. 

-Brian

Hi all,

Wondering if anyone has any insight into what seems to be an abnormally large number of tables (most empty) in the EPIM database. I'm seeing 86k tables with a PLT or PLT...TMP name. These start from the date of our implementation (2019) to currrent. Maybe they are of no concern, but at a minimum, they do cause it to take longer to open the list of tables.

We are currently on v10.5.3

Thanks!

Thanks, Brian!

Would that imply that there is something amiss with a cleanup routine? Or is this by design?

On some further research, I did discover that the number of SQL tables doesn't really hinder performance, so maybe something that just wasn't seen as necessary? It does waste disk space, and poses more of an administrative/maintenance hassle.

Mark,

Those tables are associated with previous import jobs and can be removed if they are more than a day old. 

-Brian

Hi all,

Wondering if anyone has any insight into what seems to be an abnormally large number of tables (most empty) in the EPIM database. I'm seeing 86k tables with a PLT or PLT...TMP name. These start from the date of our implementation (2019) to currrent. Maybe they are of no concern, but at a minimum, they do cause it to take longer to open the list of tables.

We are currently on v10.5.3

Thanks!

Mark,

The PLT and PLT TMP tables are supposed to be deleted after processing has completed for the associated imports.  However, if there are any errors or if the services are stopped during processing, the tables will not be removed.  I recommend you manually clean these tables up and then monitor moving forward.  If you find that the new tables continue to grow at a significant rate, it may be necessary to examine the Job Monitor and worker log files to determine why they are not being deleted.  To do this, it would be best to open a new support case and provide the details.

-Brian

Thanks, Brian!

Would that imply that there is something amiss with a cleanup routine? Or is this by design?

On some further research, I did discover that the number of SQL tables doesn't really hinder performance, so maybe something that just wasn't seen as necessary? It does waste disk space, and poses more of an administrative/maintenance hassle.

Mark,

Those tables are associated with previous import jobs and can be removed if they are more than a day old. 

-Brian

Hi all,

Wondering if anyone has any insight into what seems to be an abnormally large number of tables (most empty) in the EPIM database. I'm seeing 86k tables with a PLT or PLT...TMP name. These start from the date of our implementation (2019) to currrent. Maybe they are of no concern, but at a minimum, they do cause it to take longer to open the list of tables.

We are currently on v10.5.3

Thanks!