We recently found quite a large .ldf file (137 GB!!!) on the server that hosts DocStar for us. Looking into it, we use a Full Recovery Model and it seems like we’d like to stick with that, but surely there is a way to trim that file down, right? Recently found out about the Audit log and purged data from a few of the beginning months we had DocStar (before I even started training at all). Also went in and unchecked some of the unnecessary entries that were getting logged to the Audit table.
I was curious though if anyone else uses the scheduled purging options provided by DocStar, or even manually purges the Audit table every so often? Part of me assumes that since I didn’t know about this table until now, the data can’t be that important? But then the extremely cautious side of me questions if I might need it one day. Storage hasn’t been a terrible problem yet, but a .ldf file of this size seems a little unnecessary.
.ldf is a DB Log file they only get trimmed when you do proper backups. You may need to look at your DR plan to ensure you are getting what you need incase of any issues.
So you’re saying that purging the Audit table won’t really affect the .ldf? Our Eclipse database gets a backup file created every night it seems per the Eclipse Server Configurator. Would those not be considered a proper backup?
You should be able to find some posts about DB Maintenance here. I am not a DBA, if you have DR type questions you should consult a DBA or SysAdmin who should get you moving in the right direction. Lots of nuance with backup strategy for SQL servers.
Correct. The LDF is the SQL Database Log file. It contains no tables/data that you can access. Only the MDF file contains that data.
The Full backup model in SQL causes the log file to contain all the previous changes between ‘checkpoints’. You need to also do a periodic Transaction Log backup, as well as a subsequent full back up on a regular basis. Then you need to clean up after yourself. SQL Server agent tasks/maintenance plans are available to do all this.
This really comes down to what your recovery point objective is - how much can you lose between backups.
Low transaction volume databases usually use the Simple backup model. take a full backup every evening, or even twice a day. (this is what we do for ECM).
High volume databases need to have a backup every night, and a transaction log backup every two hours at a minimum. (this is what we do for Kinetic)
There is a huge amount of documentation, as well as highly opinionated discussions available on the internet for this.
Once you get the settings set correctly, SQL will shrink the LDF file.
It sounds like your audit settings are configured to log everything in DocStar. I recommend reviewing those settings to determine what is truly necessary for audit purposes. Streamlining the logs to only capture essential information could help reduce unnecessary data growth.
A proper maintenance routine needs to be setup and scheduled. We just did a server migration, and were so focused on so many other things, hadn’t given that a second thought, until I went to refresh our Test environment, and the restore failed due to a lack of disk space for the log file…
I immediately set production to Simple, performed a shrink on the log file, and then set it back to full (and did the same to Test after restoring the backup).
If the log file maxes out your available disk space, Epicor will crash on you.
I already have a planned session with Professional Services to set up a proper maintenance routine. No, performing a backup of the database does not reduce the log file. There are other steps needed to do that.
AND ~ when you restore your backup to one of your other environments, it carries over that exact same log file from your production backup… and thus you can quickly double or triple the amount of disk space being used by log files just from doing backup and restore to Pilot & Test.
So do monitor until you have the proper maintenance plan in place.
It takes approximately 3-4 weeks for our log file to reach about 80% the size of the actual database.
