DanM's questions

No meu trabalho atual, descobri recentemente que nossos servidores de banco de dados MS SQL não tinham dispositivos de backup configurados para eles. Quando perguntei a outros membros de TI sobre isso, a resposta foi que os próprios servidores estavam sendo copiados regularmente, incluindo os arquivos do banco de dados, portanto, fazer backups do servidor SQL seria redundante.

Tenho certeza de que essa é uma pergunta muito elementar, mas me fez pensar: por que o servidor MS SQL, assim como outros sistemas RDBMS, tem seu próprio sistema de backup? A maioria dos outros aplicativos não tem isso. Meu primeiro pensamento é que apenas o RDBMS pode executar verificações de integridade nos arquivos do banco de dados.

Que outras razões existem? Acho que precisamos mudar nossos procedimentos de backup e restauração, mas preciso ter certeza de que tenho um argumento sólido para fazer isso, pois isso exigirá investimentos adicionais.

Estou tentando solucionar alguns picos de CPU intermitentes que estamos testemunhando em um de nossos SQL Servers de produção. Estamos executando o SQL Server 2008 R2 Standard Edition com 28 GB de RAM e 4 núcleos de CPU. Quando isso acontece, notamos um grande número de esperas RESOURCE_SEMAPHORE_QUERY_COMPILER, que duram cerca de um ou dois minutos e depois param, fazendo com que o uso da CPU volte ao normal.

Depois de pesquisar isso, entendo que isso normalmente é causado pela compilação de muitos planos de execução não reutilizáveis, para os quais estamos trabalhando atualmente em alterações em nosso aplicativo.

Esse comportamento também pode ser acionado por remoções de cache do plano devido à pressão de memória? Se sim, como eu verificaria isso? Estou tentando ver se há algum remédio de curto prazo que possamos fazer, como atualizar a RAM do servidor, até implantarmos nossas correções de aplicativos. A única outra opção de curto prazo em que consigo pensar é mover alguns de nossos bancos de dados mais ocupados para um servidor diferente.