none
Instalação de SQLServer 2000 em HP Proliant RRS feed

  • Discussão Geral

  • Boa tarde amigos, tenho que instalar um banco de dados sql server 2000 aqui na minha empresa.
    estou com uma HP Proliant DL380 G5 com 2 HDs de 150Gb SAS um de 500Gb SATA.
    Estou pensando em particionar o HD SATA em 100Gb / 400Gb e deixar os dois de 150Gb SAS para os dados do SQL (as bases), pois SAS é bem mais rápido que SATA.

    Vocês acham que essa é a maneira certa de eu instalar o banco para ter a melhor performance?

    Abs

    Gubergamo
    quinta-feira, 10 de setembro de 2009 19:57

Todas as Respostas

  • Boa Tarde,

    Em princípio pode parecer uma boa idéia, mas para responder com certeza seria necessário avaliar outras questões:

    - Será que o seu sistema tem fila de disco ?
    - Será que seu banco tem muitas atividades de escrita em relação a leitura ?
    - O que você colocaria nas partições de 100 / 400 GB ?
    - Como os bancos serão distribuídos nos demais HDs ?
    - Quanto de memória está disponível nesse servidor ?
    - Qual o tamanho das bases a serem hospedadas ?

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Unique Constraints – Aplicações, Alternativas e um lapso "justificável" do SQL Server
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!710.entry
    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 10 de setembro de 2009 20:23
  • Gustavo,

    Com certeza é uma alternativa interessante utilizar discos específicos para o SQL Server, ainda mais o SAS por apresentar uma performance superior ao SATA e mais seguro.

    Sugiro se for possível alocar o banco TEMPDB em um disco específico, com isso você poderá ainda ter mais um ganho de performance.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    quinta-feira, 10 de setembro de 2009 20:27
    Moderador
  • Boa Tarde,

    Em princípio pode parecer uma boa idéia, mas para responder com certeza seria necessário avaliar outras questões:

    - Será que o seu sistema tem fila de disco ?
    - Será que seu banco tem muitas atividades de escrita em relação a leitura ?
    - O que você colocaria nas partições de 100 / 400 GB ?
    - Como os bancos serão distribuídos nos demais HDs ?
    - Quanto de memória está disponível nesse servidor ?
    - Qual o tamanho das bases a serem hospedadas ?

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Unique Constraints – Aplicações, Alternativas e um lapso "justificável" do SQL Server
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!710.entry
    Classifique as respostas. O seu feedback é imprescindível
    Respondendo Gustavo:
    - Será que o seu sistema tem fila de disco ? tem uma fila relativamente grande, tenho um sistema ERP (microsiga) que usa MUITO o BD e ultimamente estou tendo muitos erros de deadlock, e tenho outro sistema de relatórios que acessa demais o banco também, este último só uso ele nos finais de ano.
    - Será que seu banco tem muitas atividades de escrita em relação a leitura ? complementando a resposta acima, tenho cerca de 25 a 30 usuários que acessa o banco quase as 8 horas de trabalho inserindo, lendo, e alterando muita coisa no BD
    - O que você colocaria nas partições de 100 / 400 GB ? na de 100Gb seria o SO windows 2005 server e na de 400Gb seria pra Backup e dados em geral
    - Como os bancos serão distribuídos nos demais HDs ? imagino subdividir em diretórios, ou mesmo em um único diretório no HD SAS, e fazendo um RAID 0 
    - Quanto de memória está disponível nesse servidor ? tenho 4Gb RAM
    - Qual o tamanho das bases a serem hospedadas ?
    tenho bases de 1Gb e uma grande de 26Gb.

    Gubergamo
    quinta-feira, 10 de setembro de 2009 22:11
  • Gustavo,

    Com certeza é uma alternativa interessante utilizar discos específicos para o SQL Server, ainda mais o SAS por apresentar uma performance superior ao SATA e mais seguro.

    Sugiro se for possível alocar o banco TEMPDB em um disco específico, com isso você poderá ainda ter mais um ganho de performance.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    Se eu fizer um RAID 0 ou 0+1 eu precisarei alocar o TEMPDB em outro disco também? qual é a vantagem de eu ter o TEMPDB em outro HD?
    Gubergamo
    quinta-feira, 10 de setembro de 2009 22:14
  • Boa Noite,

    Agora de posse dessas respostas podemos começar a pensar no que fazer em relação a esses discos. Ainda assim não dá pra afirmar o que é melhor. Você ainda terá que fazer suas avaliações próprias.

    A primeira escolha envolve optar entre desempenho e tolerância a falhas. Se utilizarmos os discos de forma paralela, caso um disco falhe, dados poderão ser perdidos e as aplicações irão parar. Podemos evitar que isso aconteça combinando os discos em uma solução de RAID de forma que caso um disco seja perdido, você possa substituí-lo sem que isso implique a parada.

    Tolerâncias a falhas é normalmente imprescindível para aplicações críticas, mas com uma quantidade tão pequena de discos e ainda com discos com características físicas diferentes, fica um pouco complicado em falar em RAID (até porque teríamos que optar por um RAID via software que não é muito recomendável). Na minha opinião, dada as suas configurações, essa hipótese deve ser descartada senão houver upgrade de hardware.

    Normalmente as aplicações de ERP tem de fato atividades de escrita intensa e é recomendável que o disco esteja à altura. Como você tem 4GB de RAM, a base de 1GB não teria problemas de escrita em disco, pois, ela caberia integralmente na memória, gravando apenas as páginas alteradas de tempos em tempos (pelo CHECKPOINT). Como há uma base de 26GB e se trata de um ERP, então será mesmo necessário trabalhar o sistema de discos.

    O primeiro ponto que gostaria de esclarescer é que particionar um disco de 500Gb em dois (100 / 400) não melhora o desempenho, pois, embora logicamente sejam duas partições, fisicamente continua sendo o mesmo disco. Ainda assim, esse é um ponto pra pensar depois já que os dados dos bancos não irão residir nesse disco (que é o mais lento).

    Como sobram dois discos temos basicamente duas opções para desempenho:

    Utilizar o RAID0: Nessa situação (mesmo que via software), os dois discos irão compor um único volume que terá o dobro de velocidade de escrita e leitura (desconsiderando os pequenos overheads de gerenciamento de RAID via software). É uma utilização interessante, mas lembre-se que embora a velocidade tenha dobrado, você concentrará nesse único volume, toda a carga de escrita e leitura e não será possível segmentar o tráfego de I/O. Será tudo direcionado para esse volume

    Utilizar a separação: Como você tem dois discos para dados, você pode escolher algumas possibilidades de separação:

    - Colocar cada banco em um disco separado
    Isso segmenta o I/O por disco de forma que as requisições de I/O de um banco de dados não irão influenciar o outro banco de dados. Não recomendo, pois, como um banco é de 1GB ficaria desequilibrado dar um disco para ele e um disco para o de 26GB (considerando que os dois tem escrita intensa)

    - Separar dados de Log
    Atividades de escrita intensa envolvem escrita de Log intensa. Separar os arquivos de dados dos arquivos de Log pode beneficiar o desempenho, visto que a escrita do Log não irá concorrer com a escrita dos dados

    - Separar os índices dos dados
    Em sistemas OLTP, o uso de índices é intenso (tanto na leitura quanto na escrita) para a recuperação de dados. Você pode criar FILEGROUPs para agrupar os índices e colocar os arquivos desses FILEGROUPs em um disco enquanto coloca os dados em outro disco. Isso iria diminuir a concorrência de I/O entre os dados e seus respectivos índices (somente para índices NonClustered)

    - Separar o TempDB dos dados
    Você pode colocar o TempDB em um único disco e as demais bases em outro disco. Isso irá isolar a concorrência por recursos de I/O do TempDB (triggers, versionamento de linha, tabelas temporárias, etc) dos demais bancos de dados. Um ERP certamente utiliza muitos recursos "temporários", mas não sei se a concorrência é tão grande que justifique isolar o TempDB em um disco próprio.

    No melhor dos mundos, você teria um subsistema de disco com redundância para cada um dos grupos (Banco, Dados, Log, Índices e TempDB). Infelizmente você não tem todos os discos necessários e talvez alguns grupos nem gerem um benefício tão grande que justifique um sistema de discos a parte. Inicialmente eu optaria por separar os dados do Log ou separar os índices dos dados. Eu não invistiria em separar os bancos por disco ou isolar o TempDB em um primeiro momento. A resposta certa irá depender dos testes que você irá fazer. Sugiro conversar com o fornecedor para verificar algum BenchMark e (ou) se o seu hardware atende aos requisitos mínimos.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Unique Constraints – Aplicações, Alternativas e um lapso "justificável" do SQL Server
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!710.entry


    Classifique as respostas. O seu feedback é imprescindível
    sexta-feira, 11 de setembro de 2009 00:37
  • Bergamo,

    Com este documentário destacado pelo Gustavo Maia, fico sem qualquer tipo de alternativa para descrever um pouco mais sobre minha visão para este tópico.

    Maia,

    Parabéns.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    sexta-feira, 11 de setembro de 2009 01:27
    Moderador
  • Maia, parabéns.. como sempre vc é preciso e objetivo....

    Att.
    Marcelo Fernandes
    MCP, MCDBA, MCSA, MCTS. Se útil, classifique!!!
    sexta-feira, 11 de setembro de 2009 11:46
    Moderador
  • Perfeita a explicação do Gustavo.

    Muito obrigado por tirar essa dúvida minha. assim que montar posto aqui a configuração e o resultado!

    obrigado! abraços!
    Gubergamo
    sexta-feira, 11 de setembro de 2009 12:26
  • Bom Dia Pessoal,

    Ontem eu me empolguei (rs). Eu estava ministrando uma aula no curso 2780 sobre esse assunto e aí na hora do laboratório me deparei com essa pergunta. Foi ótimo para exercitar a explicação que eu havia dado na aula, até mostrei para que os alunos me ajudassem.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Unique Constraints – Aplicações, Alternativas e um lapso "justificável" do SQL Server
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!710.entry
    Classifique as respostas. O seu feedback é imprescindível
    sexta-feira, 11 de setembro de 2009 12:28