none
Configuração do Tempdb RRS feed

  • Pergunta

  • Bom dia

    Temos um servidor 2008 e estou querendo habilitar a opção READ_COMMITTED_SNAPSHOT. Como o servidor utiliza uma storage, gostaria de saber a opinião de voces sobre criar uma LUN para o tempdb ou se acham desnecessário pois o controle da storage sobre o acesso aos discos tornaria a diferença imperceptível.

    Grato.

    quarta-feira, 30 de março de 2011 11:31

Respostas

  • Bom Dia,

    Se pegarmos qualquer documentação oficial, boas práticas ou livros de SQL Server, possivelmente você verá a recomendação de separar o TempDB em um disco a parte que favoreça a gravação (RAID 1 ou RAID10). Isso é muito válido, mas são posições meramente técnicas e nem sempre representam a melhor opção.

    Se o seu storage dá a vazão necessária a sua aplicação, não vejo porque alocar uma LUN específica para o TempDB. Isso só irá incorrer em mais administração e eventualmente mais custos caso seja necessário mais investimento para possibilitar essa configuração. Faço o seguinte paralelo: Para que você chegue ao trabalho no horário combinado você precisa percorrer uma estrada a uma velocidade constante de 60 Km/h. Você possui hoje um GOL e ele é capaz de fazer isso. Você pode claro investir mais dinheiro e comprar uma Mercedes para conseguir aumentar a velocidade para até 200 Km/h, mas se os 60 Km/h já eram suficientes qual é o valor agregado nisso ? O Gol já era capaz de manter velocidade superior a 60 Km/h e possuia custos muitos inferiores. A Mercedes aumentou a velocidade, mas isso não mudou em nada sua realidade, pois, você continuará chegando no horário combinado.

    Se formos seguir todas as recomendações (discos para índices nonclustered, discos para dados, disco para log, discos para SO, disco para TempDB, disco para separar os FILEGROUPs das tabelas mais acessadas, das tabelas histórico, etc), você pode acabar com um servidor com mais de 50 LUNs para hospedar alguns poucos bancos de dados. É performático ? Com certeza sim, mas talvez você conseguisse a mesma performance sem todo esse esforço. Até porque falar em discos dedicados hoje nem sempre é verdade. Se você estiver falando de implementações DAS então os discos são dedicados, mas se estivermos falando de iSCSI ou uma SAN é bem possível que o discos seja compartilhado por várias LUNs.

    Não estou desincentivando o uso de uma Lun separada (RAID 10 é ótimo pra escrita), mas sugiro verificar se você realmente tem gargalos de escrita em potencial antes de alocar a LUN. Ou opcionalmente aloque a LUN e veja a vazão do IO (considerando as necessidades atuais e futuras). Caso a LUN seja desnecessária remova-a e deixe o TEMPDB junto. Agora se o recurso realmente estiver sobrando... Então vale a pena o critério técnico e siga as recomendações.

    Uma observação sobre o nível de RAID. O RAID 0 é excelente para escrita, mas ele não possui tolerância a falhas. Se você tiver uma LUN em RAID 0 e um dos discos pifar, a LUN ficará comprometida e bem sabemos que se o TempDB pará, o SQL Server não vai operar corretamente. RAID 0 dificilmente é usado em conjunto com banco de dados. Acredito que deva ter havido uma confusão e a recomendação deveria ser RAID 1

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com

     


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Jose Marcelo quarta-feira, 30 de março de 2011 17:17
    quarta-feira, 30 de março de 2011 14:42

Todas as Respostas

  • Jose,

     

    É muito bom, alias, é recomendação manter a tempdb em raid 0, fara muita diferença em sua performance, e deixe-a em um disco isolado de preferencia...


    ------------------------------------------------------------- Oracle OCA11g
    quarta-feira, 30 de março de 2011 11:37
    Moderador
  • Não consigo montar um raid separado para o tempdb pois todos os discos fazem parte de um array apenas (raid10). Mesmo assim é interessante ter uma LUN apenas para o tempdb?
    quarta-feira, 30 de março de 2011 12:38
  • Bom Dia,

    Se pegarmos qualquer documentação oficial, boas práticas ou livros de SQL Server, possivelmente você verá a recomendação de separar o TempDB em um disco a parte que favoreça a gravação (RAID 1 ou RAID10). Isso é muito válido, mas são posições meramente técnicas e nem sempre representam a melhor opção.

    Se o seu storage dá a vazão necessária a sua aplicação, não vejo porque alocar uma LUN específica para o TempDB. Isso só irá incorrer em mais administração e eventualmente mais custos caso seja necessário mais investimento para possibilitar essa configuração. Faço o seguinte paralelo: Para que você chegue ao trabalho no horário combinado você precisa percorrer uma estrada a uma velocidade constante de 60 Km/h. Você possui hoje um GOL e ele é capaz de fazer isso. Você pode claro investir mais dinheiro e comprar uma Mercedes para conseguir aumentar a velocidade para até 200 Km/h, mas se os 60 Km/h já eram suficientes qual é o valor agregado nisso ? O Gol já era capaz de manter velocidade superior a 60 Km/h e possuia custos muitos inferiores. A Mercedes aumentou a velocidade, mas isso não mudou em nada sua realidade, pois, você continuará chegando no horário combinado.

    Se formos seguir todas as recomendações (discos para índices nonclustered, discos para dados, disco para log, discos para SO, disco para TempDB, disco para separar os FILEGROUPs das tabelas mais acessadas, das tabelas histórico, etc), você pode acabar com um servidor com mais de 50 LUNs para hospedar alguns poucos bancos de dados. É performático ? Com certeza sim, mas talvez você conseguisse a mesma performance sem todo esse esforço. Até porque falar em discos dedicados hoje nem sempre é verdade. Se você estiver falando de implementações DAS então os discos são dedicados, mas se estivermos falando de iSCSI ou uma SAN é bem possível que o discos seja compartilhado por várias LUNs.

    Não estou desincentivando o uso de uma Lun separada (RAID 10 é ótimo pra escrita), mas sugiro verificar se você realmente tem gargalos de escrita em potencial antes de alocar a LUN. Ou opcionalmente aloque a LUN e veja a vazão do IO (considerando as necessidades atuais e futuras). Caso a LUN seja desnecessária remova-a e deixe o TEMPDB junto. Agora se o recurso realmente estiver sobrando... Então vale a pena o critério técnico e siga as recomendações.

    Uma observação sobre o nível de RAID. O RAID 0 é excelente para escrita, mas ele não possui tolerância a falhas. Se você tiver uma LUN em RAID 0 e um dos discos pifar, a LUN ficará comprometida e bem sabemos que se o TempDB pará, o SQL Server não vai operar corretamente. RAID 0 dificilmente é usado em conjunto com banco de dados. Acredito que deva ter havido uma confusão e a recomendação deveria ser RAID 1

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com

     


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Jose Marcelo quarta-feira, 30 de março de 2011 17:17
    quarta-feira, 30 de março de 2011 14:42
  • Boa tarde Gustavo

     

    Vou optar então por criar uma LUN pois o produto da empresa centraliza bancos de clientes em nosso servidor e a tendência é aumentar o número de databases. Acho melhor ter a mercedes e correr quando precisar do que estar com GOL e não passar do 100 Km/h.

     

    Obrigado.

    quarta-feira, 30 de março de 2011 17:17