Fazendo backup e restaurando tarefas agendadas do SQL Server

2

Recentemente, tivemos um servidor falhando; Neste servidor, nós tínhamos vários trabalhos programados para serem executados todas as noites. Nós fizemos backup do banco de dados do SQL Server (2005) antes do servidor morrer e restaurá-lo, no entanto, não vejo nenhum dos trabalhos no SQL Server Agent. Fazer backup do banco de dados não faz backup dos trabalhos? Eu não estou ciente dos trabalhos sendo salvos em qualquer lugar ... estou ferrado?

    
por Wayne Molina 29.05.2009 / 14:51

5 respostas

9

Os trabalhos são armazenados no banco de dados do sistema MSDB. Você apoiou isso? Você precisa restaurá-lo para recuperar seus trabalhos.

    
por 29.05.2009 / 14:59
3

Você tem duas opções. Se você está planejando basicamente restaurar um servidor intacto, como o 20th Century Boy indicou, as informações do trabalho são armazenadas no banco de dados msdb. Além dos bancos de dados do usuário, você deve fazer o backup de master e msdb, que são bancos de dados do sistema.

Se você quiser apenas extrair os trabalhos para exibir um outro servidor existente, como uma opção de recuperação, poderá fazer o script dos trabalhos do SQL Server Agent.

  1. Abra o SQL Server Management Studio
  2. Conecte-se ao SQL Server em questão usando o Pesquisador de Objetos.
  3. Expandir o SQL Server Agent
  4. Expanda a pasta Trabalhos
  5. Clique com o botão direito do mouse no trabalho para criar um script e verá o trabalho de script como um par de camadas de opções.
por 29.05.2009 / 15:11
0

Isso não é estritamente uma resposta direta à pergunta, mas acho que é relevante. Praticamente qualquer trabalho agendado que você normalmente criaria no SQL Server pode ser feito como um arquivo em lotes usando osql ou sqlcmd. Você pode executar o arquivo em lotes do Agendador de Tarefas do Windows.

Qual abordagem é melhor é uma questão de gosto. Eu gosto de usar arquivos em lote do Windows porque eu posso executar outras coisas a partir do arquivo em lotes, e o arquivo em lotes é fácil de replicar em novas instalações sem se preocupar com a restauração do msdb.

JR

    
por 29.05.2009 / 16:02
0

O script é bom porque você pode carregar os scripts em um sistema de controle de código-fonte e manter um registro de alterações.

Mas você também deve fazer o backup do MSDB. Cintos e suspensórios.

    
por 29.05.2009 / 20:14
0

Para a situação em que você está, conforme indicado, se você não tiver um backup do MSDB ou um script salvo dos trabalhos e o MSDB não estiver disponível, você terá que recriar os trabalhos a partir da memória ou de outras fontes. ("Estou ferrado" = Sim)

Ao reintegrar os trabalhos, certifique-se de procurar não apenas os trabalhos que você executou , mas os trabalhos que você deve ter em funcionamento.

Agora que são algumas semanas mais tarde e você recuperou (espero) a maioria de seus trabalhos importantes, você deve rever o que você tem em mente e pensar:

  • Seu modelo de recuperação é o que deve ser para o propósito do banco de dados
  • Suas tarefas de backup são otimizadas para seu modelo de recuperação e necessidades de recuperação pontual?
  • Você está mantendo índices como deveria?
  • Você está mantendo estatísticas como deveria?

Pode ser difícil recuperar em uma situação como essa, mas é muito melhor se você garantir que os trabalhos sejam recuperados em uma situação em que você não terá problemas de desempenho na estrada que traga problemas na recuperação novamente!

(É claro que essas são coisas que devem ser verificadas em todos os servidores de banco de dados, mas o acompanhamento de uma falha é um ótimo momento para reexaminar as práticas recomendadas e ver o que pode estar faltando.)

    
por 20.06.2009 / 08:10

Tags