Início / dba / Perguntas / 28559
Accepted
adhocgeek
Asked: 2012-11-13 01:41:48 +0800 CST

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

  • 772

Eu 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 log para unidades separadas (geralmente D e E), no entanto, recentemente recebi um máquina pré-instalada que está executando um nome de instância diferente do padrão e eles configuraram 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.

ou seja, agora 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

Posso entender por que é necessário ter uma pasta binária de instância separada, mas não consigo ver 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 a fazer? Ou talvez simplesmente não faça diferença alguma? Para mim, parece terrivelmente desarrumado...

sql-server sql-server-2008-r2

2 respostas

  1. Best Answer

    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 ao sistema operacional e aos binários do sistema operacional. Isso pode oferecer algumas opções diferentes para recuperação em caso de falha na unidade C, pode ajudar a impedir que o sistema operacional cause ou receba problemas relacionados ao compartilhamento com outros aplicativos.
    2. Você está isolando os binários do SQL Server de outros programas e garantindo a disponibilidade de algumas das pastas críticas, como a pasta Logs, onde os logs de erros vão - essa pasta precisa estar acessível para a inicialização do SQL Server. Você está se protegendo dos outros, basicamente.

    Você pode colocar os binários/arquivos de instância do SQL Server no mesmo lugar em que costuma colocar seus outros arquivos de programa. Mas se você fizer isso - pelo menos, certifique-se de pegar 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 tenho 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 de nível de sistema. Apenas
    • 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 para todas as instâncias em S na maioria das situações, com as pastas fornecendo a separação)

    ( ED- Outra nota - muitas vezes não tenho uma unidade "S" disponível. No final do dia, ter os arquivos de banco de dados do sistema para Master, Model, MSDB e Resource db vivendo 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 de usuários
    • L - Unidade de arquivo de log para bancos de dados de usuários
    • T - TempDB
    • X - Unidade de backup (embora, em muitos casos, eu opte por transmitir um backup para uma unidade de rede, não pagando por uma cópia após o backup e estou fazendo backup imediatamente para armazenamento em outro lugar.)

    Muitas vezes, terei mais unidades de dados e log e, às vezes, outra unidade TempDB. Adicione em várias instâncias e você pode ficar sem letras de unidade rapidamente. Você certamente pode se safar colocando seus arquivos de nível de instância em C:. E eu faço muitas verificações de integridade para clientes que foram configurados assim - e nunca digo "oh uau... temos que corrigir isso agora" - Agora, se os arquivos TempDB também estiverem lá, normalmente que eles mudem 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. Acho que o benefício é apenas manter -seus- arquivos separados. Como um DBA, você deve ter uma paranóia saudável em torno de outras funções em sua empresa, outros aplicativos, outras instalações, etc. e quanto mais você puder se isolar do potencial de conflitos, melhor você 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 ..

    • 25

  2. 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 diferentes letras de unidade 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/programas se estiverem em pastas diferentes.

    1. parar o servidor SQL
    2. adicionar uma partição
    3. copie todos os arquivos de banco de dados para a partição
    4. mude o ponto de montagem para a pasta, onde os arquivos de banco de dados foram (por exemplo: d:\database)
    5. finalizado
    • 3

relate perguntas