Bernd,

a helpful tool for this is Scheduled SQL Jobs for DNN/EVOQ by Iowa Computer Gurus. Have a look at it - but I recommend not using the shrink database option, this could cause performance issues.

Are you compressing your database backups (BACKUP ... WITH COMPRESSION)?

Happy DNNing!
Michael

are you able to access you SQL server database using SQL Server Management Studio (SSMS)?
You first need to identify the file running out of space - is it the database (.mdf or the log (.ldf) file?
in first case, you might need to delete from (or truncate) tables Eventlog, Sitelog or ScheduleHistory and Search index (tables Searchitems, searchItemWords and especially SearchItemWordPositions).
If it is caused by log file, please make sure to use "with truncate log" option on your frequent backups.
You should also use "simple mode" for database logging (in databas options).
After you fixed all these options, right click database node in SSMS and choose shrink > files.
Shrink both mdf and ldf files and make sure, there is enough disk space for them to grow (at least 512 MB or 50% of your DB size).

Thank you, Michael and Sebastian,

these are very helpful hints. Yes, I can use SSMS for maintenance of my SQL Server database. Unfortunately, WITH COMPRESSION is not supported in SQL Express Edition.

WITH COMPRESSION zips the backup file, but does NOT affect the size of the live database files.
Which recovery model are you using - if you are using "full", please make sure, you are backing up "WITH TRUNCATE Log, see https://theitbros.com/tru...12-transaction-logs/
In most cases, Simple recovery model is sufficient for DNN websites.

As I make backups every x hours, my goal is to keep backup files small. Thus, cleaning log tables is a good way for this.

Bernd,

cleaning the log tables does not affect the size of the database file, but that does not matter. It just "creates" some free space inside the database file which will be filled with data again, and that prevents the database from growing fast. It also reduces the size of the compressed backup file. If you want to reduce the file size of your data file, you have to shrink it, but I do not recommend doing this as it could affect performance. If the transaction log file is the problem, you are using the Full recovery model most propably, and never backup the transaction logs (or use the option Sebastian mentioned).

The thing to check is the database's recovery model. As Sebastian says, "Simple" is enough for most websites, but the question is: Which loss of data is acceptable? If you say 1 day or half a day, then I would use the Simple recovery model and make a full backup in this interval. If you say one hour or half an hour, then I would use also the Simple model, make a full backup once a day and an hourly or half-hourly differential backup. But if you run a website with a lot of mission-critical changes, say a web shop with orders every few minutes or seconds, i would use the Full recovery model, make a full backup every 24 hours, every hour a differential backup an a transaction log backup every minute or two minutes.

For automated database backups have a look at Ola Hallengren's SQL Server Backup, Integrity Check, Index and Statistics Maintenance. This also includes maintenance tasks to keep your database clean and performant. For RESTORE scripts, have a look at Brent Ozar's SQL-Server-First-Responder-Kit. Both are the best you cannot buy for money (because they are free!).

And finally: SQL Server has a bad habit, per default it increases file sizes by 10%. That is not much as long as the files are small, but if your database gets bigger, the increase of the file size also gets bigger. Therefore you should change that to a fixed size that makes sense for your environment. If you have lots of new data every day, turn it on to 100 or 200 MB, or even more. If not, 10 MB could be enough as well, but as everything with SQL Server: it depends on the situation.

Happy DNNing!
Michael