Hello Tobias,
What you can try to do experimentally, since you mentioned this is a test environment:
- Take a snapshot/backup of your environment. At minimum, your MDB database should be subject to backup.
- Stop SDM Services entirely to prevent any further writes to the MDB database on the event log
- Perform a SQL Server manual deletion of the table's contents.
One thing I'd be curious about is how much activity is being written to the log and the overall origin of the log itself. At any point, I'd take a row count of the table and after an hour, take a second row count, to see how many entries are being written on average. I'd also try and determine where did the table originate from, if it was a copy from production, did any new changes get introduced, basically some way to explain why the table is so big in the first place.
My biggest concern is if the same table in a production install may be experiencing a similar size issue, especially if the production instance has some sort of relation to the test instance (it was the original source of the test install's DB, it has custom changes first deployed in test environment)