# Data Pruning Not Deleting Older Data as Expected **URL:** \ **Category:** Ignition\ **Tags:** database, ignition79\ **Created:** [December 5, 2024, 10:07am UTC](https://forum.inductiveautomation.com/t/data-pruning-not-deleting-older-data-as-expected/99467 "2024-12-05T10:07:24Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Cedrik\_Wyns](https://avatars.discourse-cdn.com/v4/letter/c/f07891/32.png) [@Cedrik\_Wyns](https://forum.inductiveautomation.com/u/Cedrik_Wyns)\ **Post date:** [December 5, 2024, 10:07am UTC](https://forum.inductiveautomation.com/t/data-pruning-not-deleting-older-data-as-expected/99467/1 "2024-12-05T10:07:24Z")
Hello, I recently enabled data pruning in Ignition to manage database size. I've set a pruning age, expecting data older than this age to be deleted automatically. However, I've noticed that the older data is still present in the database. Here are some details about my setup: - Version Ignition: 7.9 - Database type: MySQL - Specific tables or data types I expected to be pruned: tag history - Pruning settings: - Enabled pruning - 1 day partitioning Length - enabled Preprocessed partitions (60s) I'm wondering: 1. Are there logs or indicators I can check to confirm if pruning is running and encountering issues? 2. Is there something additional I need to configure at the database level for pruning to work? ---
**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\ **Post date:** [December 5, 2024, 10:16am UTC](https://forum.inductiveautomation.com/t/data-pruning-not-deleting-older-data-as-expected/99467/2 "2024-12-05T10:16:01Z")
How long did you wait? I think the pruning schedule starts with the time of the change and for a 1 day pruning schedule you might have to wait 24 hours before it deletes anything. ---
**Author:** ![Cedrik\_Wyns](https://avatars.discourse-cdn.com/v4/letter/c/f07891/32.png) [@Cedrik\_Wyns](https://forum.inductiveautomation.com/u/Cedrik_Wyns)\ **Post date:** [December 5, 2024, 2:22pm UTC](https://forum.inductiveautomation.com/t/data-pruning-not-deleting-older-data-as-expected/99467/3 "2024-12-05T14:22:30Z")
Sorry, some context was missing: - Data pruning age is selected for 2 years -\> the database is keeping data from 2021. ---
**Author:** ![Felipe\_CRM](https://avatars.discourse-cdn.com/v4/letter/f/dfb087/32.png) [@Felipe\_CRM](https://forum.inductiveautomation.com/u/Felipe_CRM)\ **Post date:** [December 5, 2024, 2:30pm UTC](https://forum.inductiveautomation.com/t/data-pruning-not-deleting-older-data-as-expected/99467/4 "2024-12-05T14:30:03Z")
Recommend checking logs, as in the following related thread: > [@Historian Data Pruning](https://forum.inductiveautomation.com/t/historian-data-pruning/41587/2): > > The tags.history.query.PartitionManager logger on DEBUG/TRACE may have some information; the prune task is supposed to execute every 10 minutes. If it's been longer than 10 minutes, the logs might let you know what's wrong. In the linked thread the gateway name had changed but the pruning routine only checks historian tables under the current name's `drvid` record (presumably to prevent pruning other gateways' data on the same DB). ---
**Author:** ![Cedrik\_Wyns](https://avatars.discourse-cdn.com/v4/letter/c/f07891/32.png) [@Cedrik\_Wyns](https://forum.inductiveautomation.com/u/Cedrik_Wyns)\ **Post date:** [December 5, 2024, 5:25pm UTC](https://forum.inductiveautomation.com/t/data-pruning-not-deleting-older-data-as-expected/99467/5 "2024-12-05T17:25:24Z")
Thanks for the tip. I've reinitiated the Pruning settings and like you said, after 10 minutes, it worked. Since the servers' hard drive was full, I deleted the logs manually as a quick fix. The gateway seems to still want to delete these non existing logs and gives me a bunch of errors. How can erase these? ![Captura de pantalla 2024-12-05 182428](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/b/1b4566fd38340e28f5945c9d7e72dd8fcefdcc89.png) ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [December 5, 2024, 5:30pm UTC](https://forum.inductiveautomation.com/t/data-pruning-not-deleting-older-data-as-expected/99467/6 "2024-12-05T17:30:26Z")
Might need to verify that the Ignition User has permission to drop tables. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [December 5, 2024, 5:43pm UTC](https://forum.inductiveautomation.com/t/data-pruning-not-deleting-older-data-as-expected/99467/7 "2024-12-05T17:43:09Z")
> [@Cedrik\_Wyns](#): > > Since the servers' hard drive was full, I deleted the logs manually as a quick fix. The gateway seems to still want to delete these non existing logs and gives me a bunch of errors. > How can erase these? You need to delete the corresponding entries in the `sqlth_drv` table; that's what the historian uses as the 'source of truth' for what data tables exist. ---
**Author:** ![Jai\_Kumaran\_Muniyand](https://avatars.discourse-cdn.com/v4/letter/j/258eb7/32.png) [@Jai\_Kumaran\_Muniyand](https://forum.inductiveautomation.com/u/Jai_Kumaran_Muniyand)\ **Post date:** [March 23, 2025, 12:44am UTC](https://forum.inductiveautomation.com/t/data-pruning-not-deleting-older-data-as-expected/99467/8 "2025-03-23T00:44:22Z")
Hi @Felipe_CRM, is this documented in ignitions manual? ---
**Author:** ![Felipe\_CRM](https://avatars.discourse-cdn.com/v4/letter/f/dfb087/32.png) [@Felipe\_CRM](https://forum.inductiveautomation.com/u/Felipe_CRM)\ **Post date:** [March 24, 2025, 12:38pm UTC](https://forum.inductiveautomation.com/t/data-pruning-not-deleting-older-data-as-expected/99467/9 "2025-03-24T12:38:18Z")
Not that I know of, but that wouldn't be a bad idea. Someone would have to contact [docs@inductiveautomation.com](mailto:docs@inductiveautomation.com) ---
**Author:** ![james.vosler](https://avatars.discourse-cdn.com/v4/letter/j/8797f3/32.png) [@james.vosler](https://forum.inductiveautomation.com/u/james.vosler)\ **Post date:** [October 27, 2025, 2:19pm UTC](https://forum.inductiveautomation.com/t/data-pruning-not-deleting-older-data-as-expected/99467/10 "2025-10-27T14:19:17Z")
> [@paul-griffith](#): > > You need to delete the corresponding entries in the `sqlth_drv` table; Deleting entries from this table does not appear to drop the corresponding sqlt\_data\_\* partitions, so I think I missed something else. Do we need to manually remove all the tables or is there a way to get the partitioning mechanism to clean it up? ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [October 27, 2025, 3:30pm UTC](https://forum.inductiveautomation.com/t/data-pruning-not-deleting-older-data-as-expected/99467/11 "2025-10-27T15:30:23Z")
I'm not going to give you a step by step guide on how to maintain your historian database, because my advice to you that you might understand fully might end up consumed by someone a year from now with no idea what they're doing and lead to a fully broken historical database. Contact support if you want direct advice/step by step. EDIT: Let me amend a little bit, now that I've had some coffee and re-read your post. `sqlth_drv` and `sqlth_partitions` are how the system knows what historical tables exist, at all. Once you start doing _any_ manipulation by hand you're putting the system into an uncertain state. If you've delete from `drv` but not `partitions`, I have no idea what pruning will do, because you're in unsupported territory, but it would not surprise me at all that nothing will clean up "orphaned" tables, even if they are identified in the `partitions` table. It's a clear design goal of the historian that automatic maintenance only applies when the historian is **absolutely certain** it's touching its own tables. Multiple gateways could be talking to the same SQL database and be interacting with any number of tables, so if our default behavior in any kind of uncertainty was to start dropping tables people _would_ lose data. Rephrased: If you choose to take on the process of manually bookkeeping your tables, it is up to **you** to keep any removed rows from `partitions` or `drv` in sync with reality in your actual `data` tables.