Hello there, I am wondering a couple of things about the following thread: http://social.technet.microsoft.com/Forums/en-US/operationsmanagergeneral/thread/eb1158d6-4ae6-46b2-97ac-26ab65c9890a Database sizing: Kevin Holman writes: "You should calculate the database size using the widely available estimation tools, or look at what you use in productiDon. As long as there is no alert storm, change in agent count, or change in management packs - the opsDB size should stay fairly constant. You should set the DB size to allow for 50% free space RIGHT NOW, and bump it up higher to accomodate for any growth that may occur. So if I understand this correctly, when implementing a new SCOM environment, you estimate the required size for the OpsMgr database by using estimation tools. When having an existing environment you should have an OpsMgr database size that is twice the amount of used database space, knowing that at least 40% is required by default. This way you have an extra 10% as a buffer for growth. A good rule of thumb is to set it to 30GB in size for just about any implementation. Set it higher if your OpsDB is larger than 10GB in used space right now. That said - unless you have a huge agent count... most implementations will/should never grow beyond 25GB in used space in the database." Now somehing else is said, it diverts from the previous rule. Do you need 50% (like the previous rule) or 67% (20GB free space/30 OpsMgr database size) of free OpsMgr database free space? Maybe I understand this incorrectly. Can I just use the rule for all databases or does this only count or the OpsMgr database? Autogrowth: Kevin Holman writes: "Autogrow should only be enabled as an insurance policy - nothing more." Does this count for all databases, or just the OpsMgr database? By the way, I can't check this setting for the ReportServer and ReportServerTempDB. When trying to view their properties, I get the following error: "Property owner is not available for database...". What is the issue here? Thanx in advance. Regards, Chris

HiI Chris, thewse are the rules I use for OPsMgr DB sizing: Use available tools for the first cap planning, but isnce every environment is different you need to check what would be "your size" after a few running days. 30/40 GB should be treated as max size for live DB, your experience may vary but growing larger can have an impact on performance, especially on console performance. leave it 50% free, 40% needed for maintenance tasks, 10% for unexpected grow (alert storms and so on). This is true for the live DB. I don't use autogrow, never. After all you have montiors on for your DB so you should be alrted if something is going wrong and you have a chance to jump in and correct the issue before your DB becomes huge You don't need so much free space in the DW, the DW is partitioned in "small" tables and it is not subject to huge reindex operations such as the live DB is. I woul recommend to leave in any case about 20% free space in the DW. Hope this helps Daniele- Daniele, Microsoft MVP OpsMgr This posting is provided "AS IS" with no warranties, and confers no rights. http://nocentdocent.wordpress.com http://www.progel.it

One littel question about database sizing with the SCOM 2007 R2 Sizing Helper Tool. Check the example below. DB Size Number of Days for Data Retention 7 Number of Computers 750 Total Size (MB) 12313.45 Total Size (GB) 12.02 Suggested Space Allocation 18.04 with 50% buffer (GB) What do they mean with "Suggested Spave Allocation (with 50% buffer (GB)"? Is it the space you need in total on the volume you have this database on, so you can extend the database size when needed?

Hi Chris I think in this they mean the 50% free space to cover the 40% required for maintenance tasks and a 10% "leeway". With regard to auto-grow, you might want to talk to your DBAs to see what company policy is. I agree with Daniele and never use autogrow. Monitor the size of the OpsMgr databases and grow manually as necessary. Problems with auto-grow: 1) The default settings are to grow the database in small increments which can lead to fragmentation \ performance issues. 2) If a transaction does cause problems then with autogrow enabled, the database will just grow until the disk is full and then it is more difficult to recover. More info here: http://support.microsoft.com/kb/315512 Cheers Graham View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

I also never recommend autogrow on the operational database. I've seen a few critical database size issues go unattended for month's without the SCOM Admin's knowledge, which could have been prevented if autogrow was NOT enabled. Because autogrow was enabled, and customer had an alert storm one day which caused grooming to fail, the operational database continued to grow every day and grooming continued to fail going forward. Eventually, customer had hundreds of thousands of alerts in the operational database, and the database had grown well over 100-150GB. Customer finally called into Premier Support, complaining about terrible performance issues in the console. The problem was easily spotted, but it took time and reconfiguration of DB files/disks to rectify the issue.HTH, Jonathan Almquist - MSFT

I also never recommend autogrow on the operational database. I've seen a few critical database size issues go unattended for month's without the SCOM Admin's knowledge, which could have been prevented if autogrow was NOT enabled. Because autogrow was enabled, and customer had an alert storm one day which caused grooming to fail, the operational database continued to grow every day and grooming continued to fail going forward. Eventually, customer had hundreds of thousands of alerts in the operational database, and the database had grown well over 100-150GB. Customer finally called into Premier Support, complaining about terrible performance issues in the console. The problem was easily spotted, but it took time and reconfiguration of DB files/disks to rectify the issue.HTH, Jonathan Almquist - MSFT