Como você gerencia os patches do MSSQL 2000/2005?

Question

Estou aprendendo a gerenciar bancos de dados para minha empresa e, embora tenha um bom entendimento do uso de um banco de dados, posso ver que é completamente diferente administrar um banco de dados.

A minha função é que somos uma equipe pequena e anteriormente não tínhamos ninguém gerenciando os servidores de banco de dados, se algo desse errado, corrigiríamos, mas não haveria manutenção proativa.

Estou reunindo algumas documentações de práticas recomendadas que devemos usar, correções para problemas descobertos e métodos para evitar que problemas ocorram. No momento, meus gerentes estão relutantes em consertar os Servidores DB (SO e Software DB), que, acredito, são loucura, mas são mais experientes e "sabem melhor".

Nosso ambiente é o Server 2003, com 5 DB Servers, três MSSQL 2005 e dois MSSQL2000. Os servidores de banco de dados são todos privados e não estão voltados para a Internet. Eles estão por trás do nosso firewall. O fato de não serem públicos é o raciocínio por trás da relutância dos gerentes em consertar os servidores.

O que eu gostaria de saber é:

Como as pessoas gerenciam o patch dos servidores SQL e do sistema operacional? É necessário remendá-los? Item da lista Quando você aplica as correções (imensamente, depois de alguns dias para esperar que os problemas sejam encontrados e documentados, outros)? Lista de itens White papers, documentação técnica, bons blogs, etc, que você pode recomendar. Qualquer ajuda seria muito apreciada, pois acredito que elas devem ser corrigidas pelo menos para o SP mais recente e talvez a segunda atualização cumulativa recente, mas eu não tenho nenhuma forma de práticas recomendadas para basear isso, então seria muito interessante aprender o que as pessoas fazem.

Se você precisar de mais informações, por favor, não hesite em entrar em contato comigo.

Obrigado,

Lima

    

Answer 1

Meu conselho: sim, corrigi-los. Como vimos até hoje, o conteúdo malicioso pode e vai chegar à sua rede interna. Pensamentos contrários a isso são simplesmente ingênuos e irresponsáveis. Slammer foi um abridor de olhos de volta no dia e muito foi feito para bloquear SQL para evitar isso, mas novas ameaças surgem blá blá blá.

No que diz respeito aos servidores db, é praticamente o mesmo que os outros servidores. Montar um plano de instalação, montar um plano de reversão, aplicar os patches em um ambiente de teste, quando for confortável aplicá-los na produção. Eles devem ser avaliados para prioridade junto com todos os outros patches.

Concordo, não corrigir é insano. Se a sua empresa depende desses sistemas e eles não estão corrigindo por causa do desconforto com a administração do SQL Server, peça a alguém para o treinamento administrativo do SQL.

Editar: Para o seu comentário, no seu servidor de teste você duplica seu ambiente de produção da melhor forma possível. Para testar seu processo de correção, você executa todo o processo no servidor de teste. Se falhar, há uma chance decente ou melhor de que também falhe na produção. Não atualize a produção até que os patches em um ambiente de teste estejam estáveis.

Nos servidores de aplicativos, você também quer ter certeza de que seu aplicativo continua funcionando conforme os patches instalados. Assim, você desejará não apenas garantir que o sistema sobreviva ao patch, mas que você execute a funcionalidade de seu aplicativo. .

    

Answer 2

Bancos de dados de correção não devem ser diferentes de corrigir qualquer coisa. Teste e implemente.

Obviamente, isso requer um sistema de teste para corrigir primeiro, mas se esses bancos de dados forem tão importantes quanto as pessoas seniores em sua organização acreditam que sejam, tenho certeza de que eles já implantaram sistemas de teste prontos para testes. ;)

Eu sempre acho interessante quando as pessoas se recusam a consertar os sistemas porque são "apenas internas" e, portanto, seguras. Eu acho que você não tem nenhum computador em sua LAN que acesse a Internet e nenhuma possibilidade de fazer alguma coisa com um software que acione um bug de corrupção de dados do servidor na versão original não corrigida do software.

    

Answer 3

De acordo com o acima, com relação a "sim, você deve corrigir e sim testar primeiro os patches".

No entanto, notarei que, como você mencionou que sua equipe é nova na administração do BD, acho que o MSSQL requer correções com menos frequência do que o Windows. Para mim, configurei o windows update para "baixar apenas" em nossa máquina de testes, e então, certa noite, quando nos sentimos corajosos, pedimos ao Windows que vá em frente e instale, reinicie e execute nossos testes de regressão.

A máquina de produção é configurada da mesma maneira - somente para download, não instale os patches. Então, se nossos testes forem bem na máquina de teste, nós acordaremos às 5 da manhã do dia seguinte e pediremos que a máquina de produção instale os patches também, deixe-a reiniciar e faça alguns testes simples para garantir que o aplicativo ainda esteja funcionando. Nós normalmente fazemos isso não mais do que uma vez por semana, já que não gostamos de acordar às 5 da manhã, mas é claro que se a descrição do patch soar excepcional, vamos apressá-lo.

    

Answer 4

Gosta. Bem, você definitivamente quer remendá-los como SQL Slammer e outros operar ATRÁS do firewall, então ... De qualquer forma, "de volta no dia" eu iria corrigi-los manualmente do SP que saem de tempos em tempos depois de testar em um servidor de backup . Hoje em dia eu apenas deixo o "Microsoft Update" pegar qualquer patch relacionado ao SQL Server. Parece funcionar bem.