Client's Laserfiche Directory Server Database is about 35GB. They are licensed for 5k users. They are wondering why the Directory Server database will be this large.
Any ideas?
Client's Laserfiche Directory Server Database is about 35GB. They are licensed for 5k users. They are wondering why the Directory Server database will be this large.
Any ideas?
What exactly is using the space? Is it the LFDS database's transaction log? Or is it the mdf file itself?
If the transaction log is the culprit, then check to see what recovery model is configured for the LFDS database (simple vs full) and work with the customer to determine what is most appropriate for their needs.
If it's the actual mdf itself, then in SSMS, you can get the "disk usage by table" report to see which specific tables are using the most space. I would presume it's the audit related tables in the database that's used to store data for reporting purposes. Most likely, the audit settings aren't configured to trim the data frequently enough. Keep in mind that this data in the database is only for reporting and is separate from the raw audit data that's still written to logs on disk.
Lastly, if you encounter an SQL timeout issue with it trying to trim the audit reporting data from the database, then you can open a support case and we can provide additional information about dropping and recreating the audit tables in the LFDS database, allowing the customer to start with a clean slate and to also reconfigure the audit settings more appropriately.
The mdf is 35GB and ldf is 338MB.
Below are the configurations:
Disk Usage by Table
You can see that the "audit" related tables in the LFDS database do seem to be the culprit. If the customer does need to keep 30 days of audit reporting data in the database, and they can spare the disk space, then it may be better to just leave things as they are.
However, if the database size keeps growing in an unconstrained fashion, or disk space is a concern, or the customer just wants to clear out the audit reporting data from the database, then open a support case and let us know the exact version of LFDS used. We can provide scripts to drop and recreate the affected tables.