É útil ter o diretório raiz da instância do SQL Server em uma unidade separada?

Sei que é possível alterar muitos dos caminhos padrão ao instalar o SQL Server e, geralmente, quando faço uma instalação, altero as pastas de dados e de log para unidades separadas (normalmente D e E), mas recentemente recebi um máquina pré-instalada que está executando um nome de instância diferente do padrão e configurou o diretório raiz da instância para estar na unidade D junto com os arquivos mdf. Isso significa que, no que normalmente seria uma unidade relativamente limpa, com apenas pastas e arquivos de banco de dados, agora também tenho uma instalação completa dos binários do SQL Server.

agora eu tenho o seguinte:

C:\Program Files\Microsoft SQL Server\ --Base Install
D:\Microsoft SQL Server\MSSQL10_50.MyInstance --Instance Binaries
D:\Microsoft SQL Server\MSSQL10_50.MyInstance\MSSQL\DATA --Data Files
E:\Microsoft SQL Server\MSSQL10_50.MyInstance\MSSQL\LOGS --Log Files

Onde normalmente eu correria com algo como:

C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\ --Base Install & Default Instance Binaries
D:\MSSQL\DATA --Data Files
E:\MSSQL\LOGS --Log Files

Entendo por que é necessário ter uma pasta binária de instância separada, mas não vejo por que seria útil colocar todos esses binários em uma unidade separada.

Alguém pode me dizer por que isso pode ser uma coisa razoável de se fazer? Ou talvez não faça nenhuma diferença? Para mim, isso parece terrivelmente desarrumado ...

Com relação à divisão da raiz da instância, existem alguns argumentos a favor de fazê-lo.

1. Algumas pessoas são a favor de manter sua unidade "C" dedicada apenas aos binários do SO e do SO. Isso pode fornecer algumas opções diferentes de recuperação no caso de uma falha na unidade C, além de ajudar a impedir que o sistema operacional cause ou receba problemas relacionados ao espaço, compartilhando com outros aplicativos.
2. Você está isolando os binários do SQL Server de outros programas e assegurando a disponibilidade de algumas das pastas críticas, como a pasta Logs, onde os logs de erro vão - essa pasta precisa estar acessível para a inicialização dos SQL Servers. Você está se protegendo dos outros, basicamente.

Você pode colocar os arquivos de instância / binários do SQL Server no mesmo local em que costuma colocar os outros arquivos de programa. Mas se você fizer isso - pelo menos, certifique-se de levar os arquivos do banco de dados do sistema e, potencialmente, o local de backup padrão e movê-lo para outro lugar.

Aqui está o que eu costumo fazer quando recebo um número ilimitado de letras de unidade para brincar (no mínimo .. As letras não são importantes aqui):

• C - OS e arquivos no nível do sistema. Somente
• D - arquivos de programa para todos os aplicativos (incluindo SQL Server)
• S - Arquivos de nível de instância / bancos de dados do sistema SQL Server e arquivos de log normalmente (exceto TempDB) (observação .. Se eu tiver várias instâncias, não farei 4 delas. Eu colocaria todos os binários SQL em todas as instâncias em S na maioria das situações, com as pastas fornecendo a separação)

( ED- Outra observação - muitas vezes não tenho uma unidade "S" disponível. No final do dia, os arquivos de banco de dados do sistema para Master, Model, MSDB e Resource db moram na mesma unidade que alguns de seus usuários. arquivos de banco de dados, mas em uma pasta separada para separação lógica para manter as coisas menos confusas não é o fim do mundo.)

• F - Arquivos de dados para bancos de dados do usuário
• L - Unidade de arquivo de log para bancos de dados do usuário
• T - TempDB
• X - Unidade de backup (embora em muitos casos eu opte por transmitir um backup para uma unidade de rede, não pague por uma cópia após o backup e estou imediatamente fazendo backup para armazenamento em outro lugar).

Muitas vezes terei mais unidades de dados e log e, às vezes, outra unidade TempDB. Adicione várias instâncias e você pode ficar sem letras de unidade rapidamente. Certamente você pode colocar seus arquivos no nível da instância em C :. E faço muitas verificações de integridade para clientes que foram configurados dessa maneira - e nunca digo "oh uau ... precisamos corrigir isso agora" - agora, se os arquivos TempDB também estiverem lá, normalmente tê-los mudar isso. Às vezes, mova seus bancos de dados mestre e MSDB também.

Mas o mundo não vai acabar se você não dividir essas coisas. Eu acho que o benefício é realmente apenas manter seus arquivos separados. Como DBA, você deve ter uma paranóia saudável em relação a outras funções em sua empresa, outros aplicativos, outras instalações etc. e quanto mais você puder se isolar do potencial de conflitos, melhor será. E oferece mais algumas opções para reinstalação e recuperação. Então, sim, separe seus binários de C .. Mas meu conselho não seria enlouquecer em uma unidade separada para cada instância ..

Bem, existem apenas 26 letras de unidade possíveis no Windows. 1
Mas você tem a possibilidade de usar pontos de montagem. 2

Portanto, se você precisar instalar 25 servidores diferentes (SQL, Web, ...) em uma máquina, pode fazer sentido ter uma letra de unidade para um dos servidores.
Mas se você tiver apenas um servidor, faria mais sentido ter letras de unidade diferentes para os arquivos de log, o banco de dados e os arquivos de programa.
Você também pode dividir os arquivos de log / banco de dados / programa se estiverem em pastas diferentes.

1. pare o servidor SQL
2. adicionar uma partição
3. copie todos os arquivos de banco de dados para a partição
4. altere o ponto de montagem para a pasta onde estão os arquivos de banco de dados (por exemplo: d: \ database)
5. acabado