Aaron Weiker's questions

I have a scenario where an external application is monitoring a queue and then taking an action when something is put into the queue. I just wrapped this to happen inside of a transaction to try to prevent things from getting out of the queue if the action has failed. What is happening is that under certain conditions the queue will get disabled if I have a failure in my application that causes the transaction to rollback.

What I'm looking for is a way to enable the queue without opening up SQL Server Management Studio.

It's common practice to separate out the data from the log files on SQL server. Does this still hold true as best practice when working with SharePoint databases.

For example using the above example I could have my log drive have the following files:

• L:\WSS_Content_CentralAdmin.ldf
• L:\WSS_Content_MainSite.ldf
• L:\SharePoint_Config.ldf
• L:\WSS_Search.ldf

And then on my data drive have the following:

• G:\WSS_Content_CentralAdmin.mdf
• G:\WSS_Content_MainSite.mdf
• G:\SharePoint_Config.mdf
• G:\WSS_Search.mdf

Alternatively would it be more practical place each database (data and log) on it's own drive like so:

• G:\WSS_Content_CentralAdmin.mdf
• G:\WSS_Content_CentralAdmin.ldf
• H:\WSS_Content_MainSite.mdf
• H:\WSS_Content_MainSite.ldf
• I:\SharePoint_Config.mdf
• I:\SharePoint_Config.ldf
• J:\WSS_Search.mdf
• J:\WSS_Search.ldf

The other thing I want to better understand is how this advice is affected when the WSS_Content_MainSite database gets larger and we decide to add another database to the web application. Should this new database go on the same place as the other database files or in isolation?

When configuring the storage for your SharePoint databases what RAID level do you use?

The scenario I'm looking for is for a medium to large farm. What I'm interested in is how the different workloads that you can do affect the choices that you make.