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