MOVEit Automation - Manually Trim Statistics Databases to Prevent Upgrade Failures

The SQL commands in this article apply to both MySQL and Azure SQL. The only difference is how you connect to the database. Azure SQL users should connect via SQL Server Management Studio (SSMS) or Azure Data Studio rather than the MySQL command prompt.

Aug 21, 2026
Knowledge

Title

URL Name

moveit-automation-manually-trim-statistics-database

Article Number

000158415

Environment

Product: MOVEit Automation Version: All Supported Versions OS: Windows Database: MySQL or Azure SQL / SQL Server

Question/Problem Description

Symptoms — Is This Article for You?

Database / maintenance symptoms:

The Trim Stats database maintenance task has not run in weeks or months (due to errors or being disabled)
The stats, taskruns, or audit tables have millions of rows and continue to grow
Disk usage on the MOVEit Automation server is unusually high

Upgrade / performance symptoms:

A version upgrade times out (e.g., after 1 hour) during a database schema migration step
An attempted DELETE on the stats table is estimated to take 24+ hours
MOVEit Automation becomes slow or unresponsive during or after a large DELETE attempt

Error messages:

ERROR 1054 (42S22): Unknown column 'logtime' in 'where clause' — appears when using the wrong column name on the stats or taskruns tables (see the column name callout in Step 5 below)

Before pursuing this option to maintain the database, please review the Trim Stats DB script parameters and options. If the Automation system has a large proportion of No Transfer runs, please see the DaysToKeepNoXfer parameter and consider settings this appropriate for your needs.

Note: This option to delete records from the database should be the last option to pursue after trying other methods to improve performance and handle database maintenance. Please take a snapshot of the server as a backup before performing any manual MySQL Database changes. This way there is an easy rollback option in the event of an error or that the outcome of the manual trim is different than you intend.

Steps to Reproduce

Clarifying Information

Important — Before You Begin

Prerequisite checklist:

Take a full server snapshot/backup (e.g., VM snapshot) before making any database changes — not just a backup of the stats table. There is no easy rollback once MOVEit has continued running tasks after a deletion; if needed, revert the snapshot and contact MOVEit Support.
Try the Trim Stats task first. Manual database editing should be a last resort. Review the Trim Stats DB script parameters and options before proceeding. If your system has a high proportion of No Transfer runs, adjust the DaysToKeepNoXfer parameter as needed.
Know your date format. Use YYYY-MM-DD (e.g., 2024-09-15). Omitting the time portion HH:MI:SS defaults to 00:00:00. The format YYYYMMDD (no hyphens) has also been confirmed to work.
Know which column name applies to each table. The stats and taskruns tables use logstamp; the audit table uses logtime. Using the wrong name causes ERROR 1054.
Consider downstream data dependencies. If any scripts or processes query the stats table (e.g., for duplicate file checking using the Message column), trimming or truncating this table will reset that data pool. Assess the impact before proceeding.

Common misunderstandings:

"This article only applies to MySQL." — The SQL commands are identical on Azure SQL / SQL Server. Only the connection method differs (use SSMS or Azure Data Studio instead of the MySQL command prompt).
"Truncating the table will void my database support." — Truncating is an accepted maintenance operation and does not void support status, provided you hold a full server backup beforehand. You accept the loss of historical report data.
"I should use a single DELETE statement even on a very large table." — On tables with tens of millions of rows, a single DELETE can run for 24+ hours and lock MOVEit Automation. Use the batched delete technique in Method 1 for tables over approximately 5 million rows.

Error Message

Error Messages Addressed by This Article ERROR 1054 (42S22): Unknown column 'logtime' in 'where clause' appears in MySQL / Azure SQL and is returned when 'logtime' is used as the WHERE column on the 'stats' or 'taskruns' table. Those tables use 'logstamp'. This does not indicate data corruption; retry with the correct column name. Note: MOVEit Automation itself does not generate error messages for this maintenance scenario. The symptoms (upgrade timeout, slow system) are caused by table size, not an application error.

Defect Number

Enhancement Number

Cause

The Trim Stats database maintenance task was not running — due to errors, misconfiguration, or being disabled — allowing the stats, taskruns, and/or audit tables to grow unchecked. Tables with tens of millions of rows cause upgrade schema migrations to time out and cause DELETE operations to run for hours, locking MOVEit Automation during the process.

Resolution

Choose Your Method

Method	Best For	Trade-offs
Method 1 — Selective DELETE (with optional batching)	Removing records older than a specific date while retaining recent data; any table size	Slower on very large tables without batching; requires choosing the right date and column name
Method 2 — TRUNCATE	Removing ALL historical data immediately; fastest way to unblock an upgrade or free space	Permanently deletes all records — no partial retention; cannot be undone without restoring from backup

8. Resolution Steps

Method 1 — Selective DELETE

Take a full server backup (e.g., VM snapshot) before making any changes.
Connect to the database.
- MySQL: See MOVEit - Connect to MySQL Using Command Prompt.
- Azure SQL / SQL Server: Connect via SSMS or Azure Data Studio using your database credentials.
Select the MOVEit Automation statistics database. The default name is typically micstats, but this may vary per environment:

-- MySQL or Azure SQL:

USE micstats;

Show more lines
Record a pre-trim row count on all three tables so you can confirm results after trimming:

SELECT COUNT(*) FROM audit;

SELECT COUNT(*) FROM stats;

SELECT COUNT(*) FROM taskruns;

Show more lines
Delete records older than your target date.

⚠️ Column name reminder: Use logstamp for stats and taskruns; use logtime for audit. Using the wrong name returns ERROR 1054 (42S22): Unknown column 'logtime' in 'where clause'.

Standard DELETE (suitable for smaller tables):

DELETE FROM audit WHERE logtime < '2024-01-01';

DELETE FROM stats WHERE logstamp < '2024-01-01';

DELETE FROM taskruns WHERE logstamp < '2024-01-01';

Show more lines

Batched DELETE (recommended for tables with millions of rows — prevents long-running locks):

-- MySQL — repeat until 0 rows affected:

DELETE FROM stats WHERE logstamp < '2024-01-01' LIMIT 10000;

-- Azure SQL — repeat until 0 rows affected:

DELETE TOP (10000) FROM stats WHERE logstamp < '2024-01-01';

Show more lines

ℹ️ Deleting in batches of 10,000–50,000 rows reduces lock time and keeps MOVEit Automation operational during cleanup. The logstamp column is indexed in most versions of Automation, making this filter efficient. Continue running the batch command until the affected row count returns 0.
Verify the results. Re-run the row count queries from Step 4 and confirm the numbers match your intent.

⚠️ If more records were deleted than intended, stop MOVEit services immediately and revert to your server snapshot. Once tasks have continued running, rollback becomes unreliable. Contact MOVEit Support.
Reclaim disk space. Run OPTIMIZE after trimming to free space no longer referenced by deleted rows:

OPTIMIZE TABLE audit;

OPTIMIZE TABLE stats;

OPTIMIZE TABLE taskruns;

Show more lines

For more information, see MySQL - Optimize Database.

Method 2 — TRUNCATE (Remove All Data)

⚠️ Warning: TRUNCATE permanently removes all records from the selected table. This action cannot be undone without restoring from a backup. Use this method only when you are prepared to lose all historical report and audit data, or when you need to immediately unblock an upgrade.

Take a full server backup (VM snapshot) before proceeding.
Connect to the database (see Step 2 in Method 1).
Select the statistics database (see Step 3 in Method 1).
Record a pre-truncate row count (see Step 4 in Method 1).
Truncate all three tables:

TRUNCATE TABLE audit;

TRUNCATE TABLE stats;

TRUNCATE TABLE taskruns;
Verify results. Re-run the row count queries — all three tables should return 0.
Reclaim disk space — Run OPTIMIZE (see Step 7 in Method 1).

Workaround

Notes

Troubleshooting — Common Issues After Trimming

Problem	Cause & Fix
`ERROR 1054 (42S22): Unknown column 'logtime' in 'where clause'`	Wrong column name used on `stats` or `taskruns`. Those tables use `logstamp`, not `logtime`. Retry with the correct column name.
DELETE statement runs for hours / system becomes unresponsive	Table has too many rows for a single DELETE. Switch to batched deletes (Method 1, Step 5) in chunks of 10,000–50,000 rows until 0 rows are affected.
Upgrade still times out after deleting old rows	The table may still have too many rows. Re-run the COUNT query. If still in the millions, delete further back in time or use Method 2 (TRUNCATE).
Disk space has not decreased after DELETE	MySQL and SQL Server do not automatically release space after DELETE. Run `OPTIMIZE TABLE` on all three tables to reclaim it.
More records were deleted than intended	Stop MOVEit services and revert immediately to the server snapshot. Continuing to run tasks makes rollback unreliable. Contact MOVEit Support.
A script that queries the stats table (e.g., for duplicate file checking) is no longer working as expected	Trimming or truncating the stats table removes data the script depends on (e.g., the `Message` column). The pool of tracked records has been reduced. Plan retention windows with downstream script dependencies in mind before trimming.
Concerned that truncating will put the environment out of support	Truncating is an accepted maintenance operation and does not void support status, as long as a full server backup exists.

Progress Articles:
Task 'Trim old stats from database' Errors in Script at "line 982 char 3: Data provider or other service returned an E_FAIL status"
MOVEit - Connect to MySQL Using Command Prompt
MySQL - Optimize Database

References to Other Documentation:

Trim Stats DB script parameters

Keyword Phrase

stats table too large; upgrade timeout database; upgrade timed out schema migration; database maintenance job not running; trim stats task not running; stats table 35 million rows; manual trim MySQL statistics; manually delete stats records; logstamp logtime delete; azure sql stats trim; truncate stats table; MOVEit database slow; dbo.stats too large; ERROR 1054 42S22 unknown column logtime where clause; batched delete MOVEit Automation; DaysToKeepNoXfer; audit taskruns stats delete old records; reclaim disk space MOVEit database; MICStats database cleanup; MOVEit upgrade fails database timeout

Last Modified Date

8/21/2026 8:47 PM