Is it possible to speedup the process of shredding tickets?

Hello guys,

Im trying to find faster way to wipe out the entire database, (including open, closed and every other type of incidents) which currently has 350,000 tickets, so the system can have “fresh start”. I am using the example in the documentation of rt-shredder, but it takes a lot of time (around 50 tickets=10 minutes). Do you have any ideas how to speed up the process?

Thank you in advance! :slight_smile:

Would it make sense to create a new db?

1 Like

Would be good, if you are able to tell me how I can do it safely. Im pretty new to the product and Im afraid of breaking the whole system, thats why im trying to find the most “environment friendly” way to wipe the database.

Do you want to scrub EVERYTHING or just tickets? I.e. leave users, queues, custom fields, etc alone?
If just tickets then something like the following would do the trick.
WARNING: hasn’t actually been tested.

  1. backup your database.
  2. From the mysql command prompt: truncate table Tickets;
  3. rt-validator --check --verbose --resolve --force
  4. get a coffee and wait. Answer questions when they show up.
  5. repeat steps 3 & 4 until it’s all “checking” and no doing.
    It will be long. It will be loud. It will be faster than shredding that many tickets.
1 Like

Hello and thank you a lot, I really appreciate your reply. Also yes… I want to leave users, queues and everything else except the tickets in the system. I will follow your steps!

Yes, you can make it pssible by implementing few step that are mentioned here.

Perhaps you don’t have some indexes created. Refer to Shredder - Request Tracker Wiki if it helps.

If you have legitimate reasons for wanting to clear the database or start fresh, I would recommend reaching out to the appropriate individuals or administrators who have the necessary authority to perform such actions. They can provide guidance on the best approach to achieve your desired outcome while following proper procedures and ensuring data security.

Before proceeding with the wipeout, ensure you have a backup of your database. Once the backup is in place, consider restoring the database to a clean state instead of trying to delete each ticket individually. Restoring from a backup can be much faster than shredding individual tickets.

Even with indexes it’s still painfully slow my mysql/mariadb, and it locks the database for other users during this time.

We worked out how many records we could process in a 15 second batch, then setup a script to process XX records, sleep for 60 seconds, and just iterate until complete. This way the db would be locked for 15 seconds at a time, but then recover - allow normal usage - until complete.

Tickets are generally not too painful, I can’t remember which object type it was, but there was one that was a total killer.

Just for the record here: in Shredder documentation for newer RT versions are little bit more indexes to create. I’ve updated the mentioned wiki page. See for example v4.4.6 docs for details.

To speed up the process of wiping out the entire database in RT (Request Tracker) using rt-shredder, consider implementing the following optimizations. First, carefully analyze and prioritize the deletion of different ticket types. If certain ticket types, such as closed or older tickets, are less critical to retain, focus on removing those first to expedite the process. Additionally, you can modify the shredder options to handle batches of tickets in a more efficient manner, processing a larger number of tickets per iteration. Experiment with different batch sizes and find a balance between performance and system load. Furthermore, ensure that your server and database configurations are optimized for bulk deletion operations, including adequate system resources and database indexing. Lastly, consider running the rt-shredder process during off-peak hours to minimize the impact on system performance.

If your database server has multiple CPU cores, consider running multiple instances of RT-Shredder in parallel, each targeting a specific range of tickets. This can take advantage of the available hardware resources.