Planos de manutenção do SQL 2000 e 2005 mais inteligentes?

Question

Os planos de manutenção do SQL 2000 e 2005 devem ser resilientes a um banco de dados desanexado ou offline?

Eu desanexei / delinei alguns bancos de dados e agora os planos de manutenção estão falhando em sua totalidade porque o SQL não consegue localizar / conectar-se ao banco de dados. Parece-me uma questão simples para o SQL recalcular o script em tal mudança OU ter um plano de manutenção gerado pelo assistente que (na pior das hipóteses) apenas emite um aviso sobre os bancos de dados indisponíveis e continue com as partes independentes do o script, como os outros bancos de dados.

Como é, parece-me ser necessário entrar em cada bloco de etapas do plano de manutenção "DBs de usuário", alternar a configuração para "Todos os bancos de dados", ok fora do assistente, salvar, voltar em e defina-o de volta para "Todos os bancos de dados, exceto os bancos de dados do sistema", ok fora do assistente e salve. Isso é um monte de cliques! (Isso é 2005, com uma lista similarmente estranha para 2000)

Isso é normal? ou há algo mais errado?

Obrigado!

    

Answer 1

Jason,

Sim, isso é normal, e é por isso que muitas pessoas (inclusive eu) decidiram fazer planos de manutenção "roll-our-own".

Outra peculiaridade dos MPs é que eles tentarão fazer um dump de log trx para um banco de dados no modo de recuperação SIMPLE. Você acha que é uma simples verificação antes de tentar fazer o backup do banco de dados, certo? Bem, é, mas não dentro do MP, seu trabalho simplesmente falha.

Existem muitas pequenas peculiaridades como essa. Se você confiar nos MPs para lidar com os backups de seu banco de dados, deve estar ciente de que qualquer alteração feita no banco de dados pode ter um efeito adverso em seu MP, e você precisará revisar e agir de acordo. Caso contrário, você provavelmente será lembrado quando o trabalho falhar na próxima vez.