Just wanted to answer this question here as a pointer for later reference. But before I continue, I want to mention that this is from the perspective of SCOM. You’ll need to read documentation of your specific application before collocating your other database with the SCOM db’s.
The biggest concern will be one of performance. There are many contributing factors to deciding whether this will provide acceptable performance – hardware, configuration of disks, configuration of SQL instance(s), what is the transaction volume of the other databases sharing the host, how many agents will be deployed, is the SQL host virtualized, which management packs will you import?
If you plan to install more than 100 agents, this alone might put you into a situation that will create a poor experience in the console and cause a bottleneck on the SQL instance. I’ve seen implementations where nothing but the IIS, Windows and Exchange 2010 MP’s were installed, under 100 Exchange 2010 agent-managed computers, and it was evident there were bottlenecks on the SQL Server – and this was only shared between the SCOM databases. Keep in mind that the SCOM databases are a type of OLTP database – read characteristics of OLTP as SQLCAT explains it.
There are no hard and fast rules against sharing a SQL host for the operational and data warehouse databases – it all comes down to performance. Good news is, you’re never tied to a SQL instance for the SCOM databases, since it’s a relatively easy move procedure.
Move the operational database:
Move the data warehouse database: