There have been a some issues that jump out when planning the SQL environment that raise some concerns.
- What versions of SQL are supported?
- What are the implications regarding the different databases for the different OCS roles?
- What are the implications regarding collocation with 3rd party application databases?
1. What versions of SQL are supported?
Answer: SQL 2005 with SP2 including both 32-bit and 64-bit, and SQL 2008 including both 32-bit and 64-bit.
Additional Info: You have to be insane to not use a 64-bit version because of the memory support limitations in 32-bit.
2. What are the implications regarding the different databases for the different OCS roles?
Answer: Lots. There is some confusion because of some Microsoft documentation. The documentation tends to lead us all to believe that you must have a separate SQL instance for each of the OCS databases: pool back-end, archiving, Quality of Experience (QoE), Response Group, and Group Chat. This just isn't the case when it comes to support and certainly is not the case when it comes to databases in general. Microsoft will support a single instance hosting the different OCS databases.
Additional Info: Performance should always be a concern when planning the SQL environment for OCS. The different databases might be best implemented on different servers for performance reasons. There is absolutely no reason for each of the databases to be installed in separate instances on the same server. It is a management nightmare to have so many instances involved in supporting OCS. The only real concern is that you can't use the same SQL instance to support multiple pools because each pool's back-end has the same database names. In the case of the other OCS databases, they can be collocated because they do have different database names, however, you need to keep an eye on performance.
3. What are the implications regarding collocation with 3rd party application databases?
Answer: See the answer for question number 2 above.
Additional Info: See above as well. It comes down to performance, database names, and support issues with different applications having different needs for patching and service packing.
Best Practice: Do not collocate OCS databases with other databases for non-OCS applications if it is at all possible. The requirements for service packs and patches may cause issues with other application databases if they are all in the same instance. Host the OCS databases on separate servers as needed for performance reasons.