I recently noticed that the disk space of the server on which Openfire(Spark) is installed is almost full disk space. I noticed that the database is only 345MB in size, but your OpenFire log file present in SQL Server is 154GB in size. Are Spark chat messages stored in the bank file or log file? If the answer is in the bank file, why is this log file so big? I had never come across such a large log file, I appreciate everyone’s help and attention.
Spark can only store messages locally on the system at C:\Users\username\AppData\Roaming\Spark\user\username@servername\transcripts
I am not that familiar with SQL Server, but it says this is a transactions log. Maybe you have some very verbose logging enabled on your SQL Server. Not sure if you can take a look inside this log to see what is going on. You can also check Openfire’s own logs at Openfire/logs and maybe you will see something that explains this (some very frequently repeating events). Also, your database is still rather big. I wonder if you have Monitoring Service plugin installed. It would save users messages in the database independently from Spark (as they traverse the server). You can probably check which table has more entries.
Maybe there is a way to purge transaction log in SQL Server, so you can free up the space. Or just delete it?
As wroot said, check your logging setting in your SQL server. Sounds like you are logging every transaction or have debugging enabled. Also, if you have the Monitoring Service plugin for Openfire installed, you might try setting the Max Message Age to something other than 0. On our server, I archive messages for 180 days, and messages older than that are deleted.
This setting can be found at:
Server → Archiving → Archiving Settings
As far as the SQL debugging or Logging settings goes, I couldn’t tell you. I do know that with MySQL it would be as simple as editing the my.ini file to turn off debugging or adjust what is logged and then restarting the service. But each SQL server daemon is different.
This is a sql server issue. There are many ways to address this. You can truncate the log, set up a maintenance plan, change the logging type from full to simple. If your backup software supports sql, this should be truncated automatically on a full backup.