A file size of 140GB is not a "problem" although it might feel like a problem to you, because your disk is also 140GB.
What matters most is "is there enough free space in the DB for a supported operation". In your case - with 75GB used and 140GB DB size, then yes, this is good. First, let me say - we NEVER recommend shrinking the OpsMgr database DB file. This should be left alone. Shrinking this file can cause some performance issues that can only be resolved by creating a new file, and moving data over to the new file, and this process can be a bit painful. In SQL, it is quite easy to shrink a file, but it causes some level of fragmentation that a simple reindex will not fully resolve. So if it can be avoided, we recommend it. Ok, next, moving on to the root question.... with 850 agents, why do I have a 75GB used space in my database? Is that large? The answer is - yes, for most deployments, that is a lot of data. There could be a lot of reasons for this. Perhaps your grooming is broken. Perhaps you are keeping some datatype for a really long time. Perhaps you are massive overcollecting some datatype, like perf, or event data. Perhaps you don't manage your environment at all, and you are flooded with state changes and alert data from untuned management packs. Perhaps you have written terrible rules and monitors and they are flooding SCOM with data. Perhaps you have something very unique, like a LARGE number of URL's, or APM, or network monitoring going on. The next logical step in troubleshooting.... is to tell us "what is in your database"? Which you haven't done. Run the large table query here: http://blogs.technet.com/b/kevinholman/archive/2007/10/18/useful-operations-manager-2007-sql-queries.aspx Tell us what you see - which tables are the biggest, and how big are they. Copy the output (in a readable format please) to this thread. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Narendra Bathula Sent: Wednesday, January 21, 2015 8:08 AM To: [email protected] Subject: RE: [msmom] SV: scom 2007 R2 db size is huge Thank you for replying. I have checked the both the sites mentioned and applied on my DB. But the opsmgrdb is still on high usage. i have also tried to removed orphned entries from the DB. That helped me little. most of the microsoft management pack alerts are disabled. we have approximately 100 custom monitors configured. mdf file size =140 GB and disk size where the mdf file located is also 140 GB. That means the drive is fully occupied. Current Status below: File_size_MB : 140 GB space_used_MB : 75 GB Free_Space_MB : 65 GB my gromming settings are configued to 4 days for all. I am not able to understand why operations databse is this much bigger...Please suggest to resolve the issue. Thank you Thanks & Regards, Narendra ________________________________________ From: [email protected] [[email protected]] on behalf of David Biot [[email protected]] Sent: Wednesday, January 21, 2015 5:18 PM To: [email protected] Subject: Re: [msmom] SV: scom 2007 R2 db size is huge Narendra, do you mean that you only have 4 GB of free space in the OperationsManager database? The database needs at least 40% of free space, preferable 50% for the grooming jobs. More information can be found in the following blog post: http://blogs.technet.com/b/kevinholman/archive/2013/10/03/opsmgr-2012-grooming-deep-dive-in-the-operationsmanager-database.aspx This could explain why your database is so huge. According to the official sizing tool (http://www.microsoft.com/en-us/download/details.aspx?id=23016), your databse should have a size of about 20,44 GB and your datawarehouse 605,56. Besides the localizedtext-issue, there is also another issue that is described in the following blog post: http://blogs.technet.com/b/kevinholman/archive/2009/12/21/tuning-tip-do-you-have-monitors-constantly-flip-flopping.aspx. Best regards, David Biot On Wed, Jan 21, 2015 at 12:23 PM, Henrik Andersen <[email protected]<mailto:[email protected]>> wrote: Which version of SQL Server are you on? For SQL Server 2008 please visit https://msdn.microsoft.com/en-us/library/ms189035.aspx /Henrik -----Oprindelig meddelelse----- Fra: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] På vegne af Narendra Bathula Sendt: 21. januar 2015 12:07 Til: [email protected]<mailto:[email protected]> Emne: [msmom] scom 2007 R2 db size is huge Hi All, I am running with scom 2007 R2 and my operationsmanager database size is 140GB occupied. i am having only 850 server under monitoring. How to reduce this size..? I believe is huge size that scom DB is using. I have tried Kevin holman localised text script and got 4gb size freed which is showing in internal database free space. The free space is not showing in total drive space. it is showing in only internal database free space. How to make some free space in logical drive where database is hosted. Please suggest me how to get some free space on drive. Thank you. Thanks & Regards, Narendra ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ----------------------------------------------------------------------------------------------------------------------------------------------------
