I have about 30GB size of company DB but DYNAMICS DB is also of same size i.e. 30GB where it could not be true.
Any Idea why that would be or since the initial size is set to Big is the reason?
*This post is locked for comments
I have about 30GB size of company DB but DYNAMICS DB is also of same size i.e. 30GB where it could not be true.
Any Idea why that would be or since the initial size is set to Big is the reason?
*This post is locked for comments
Hi Harry,
I found the culprit. it WSExceptionLog Table in Dynamics which is grown to 27+ GB and now working on it to resolve.
Thank you very much for all your help
It is possible your Log File is not truncating after the TRN backup because no Full backup has been done since the TRN log backups were implemented. There are other potential causes as well. Please refer to the technet article at this link:
Hi,
As Harry mentions, if you have a database admin I would use them as a first port of call.
Otherwise, In SQL Server Management Studio, Right Click on the Dynamics DB then choose Reports - Standard Reports - Disk Usage. Please let us know the details of this report.
If there is a lot of unused space, then I'd recommend running the SQL "DBCC SHRINKDATABASE" command (Bing "DBCC SHRINKDATABASE" and there's lots of information on how to run it and what it does).
Thanks,
Justin
Thanks Harry,
My Recovery Model is "Full" and we do back TL overnight but this DYNAMICS MDF sits at very odd size
Syed,
Typically if a database is unexpectedly large, as is the case with a 30GB Dynamics database, it is because the Recovery Model for the database is set to Full, and the transaction log is not being backed up. This causes the log file to continue to grow, dramatically increasing the size of the database.
If you have a SQL resource, I would recommend consulting them on this matter. There is a ton of information available about this (online and otherwise) and a lot of it conflicts. In my humble opinion, the Full Recover Model is the right model for production environments, as it provides the greatest flexibility when restoring because of a disaster; however, this model must be administered correctly.
To validate this is the problem, go to your Dynamics database in SQL Server Management Studio, right click on the database, select properties, and choose the options tab. The Recovery Model is visible on this tab.
Almas Mahfooz
3
User Group Leader