Automatizando tarefas via script


Na época em que o MSDE estava em alta, muitos amigos vinham pedir dicas de como criar uma rotina automática de backups e etc, o maior impasse era sempre a falta de uma interface gráfica.

Ao contrário das novas versões do SQL Server Express, o MSDE possuía o serviço SQL Agent que permite agendar rotinas, backups, etc, e isso era ótimo, mas a barreira era saber como utilizar essa funcionalidade sem uma ferramenta.

Mas enfim, o foco desse texto não é o MSDE, até porque, com o tempo foram disponibilizadas algumas ferramentas para suprir algumas necessidades. A idéia principal é verificarmos como criar uma nova tarefa (job) e automatiza-la utilizando scripts no SQL Server.

Analisando um pouco veremos que precisamos apenas de 4 procedures para criação de um job: sp_add_job, sp_add_jobstep, sp_add_jobserver e sp_add_jobschedule. No nosso texto vamos utilizar como exemplo um cenário onde precisamos automatizar o backup da base de dados Master. Vamos analisar agora cada uma das procedures:

  • sp_add_job

Esta procedure adiciona um novo registro à tabela sysjobs, em linhas gerais, este registro é o nosso job, porém um job sem qualquer funcionalidade e sem agendamento. Inicialmente um job nessas condições não tem qualquer utilidade. Abaixo podemos verificar a criação de um job vazio com o título Backup MASTER:

execute sp_add_job @job_name = 'Backup MASTER'
  • sp_add_jobstep

Para darmos “vida” ao job criado anteriormente, precisamos adicionar funcionalidades a ele, por exemplo: um passo onde será executado o script de backup.  Para adicionar funcionalidades ao job Backup MASTER precisamos conhecer seu código gravado na sysjobs, para isso podemos executar o seguinte comando:

select  job_id
from  sysjobs
where name = 'Backup MASTER'

O resultado será um big código! Isso porque o código gerado é do tipo UNIQUEIDENTIFIER, popularmente conhecido como Identificador Universal.  O resultado da minha consulta é: 7EC785F2-36D7-4BEB-B2E4-BFC38E7F4D31 (é mais prático trabalhar com conteúdos deste tipo armazenando-o numa variável, porém, neste texto iremos aborda-lo explicitamente em cada passo dos exemplos).

Ok. Agora vamos utilizar este big-código junto com a sp_add_jobstep para adicionarmos funcionalidade ao nosso JOB:

-- Adiciona função ao Job
execute sp_add_jobstep @job_id = '7EC785F2-36D7-4BEB-B2E4-BFC38E7F4D31',
     @step_name = 'Script Backup Master',
     @command = 'backup master to disk = ''c:\master.bak'''

Observe que utilizamos três parâmetros junto à sp_add_jobstep: o código do job (@job_id), o nome da funcionalidade (@step_name) e finalmente o script de backup no parâmetro @command.

É interessante esclarecer que um job pode ter inúmeros passos/tarefas, logo você poderá utilizar esta procedure quantas vezes forem necessárias para adicionar novos passos a um mesmo job.

  • sp_add_jobserver

Agora vem o passo mais “abstrato” desse processo. Após criarmos o job e definir suas funções precisamos definir em qual servidor ele irá operar. Pressupõe-se que se o job foi criado no servidor <strong>X</strong> que ele deverá ser executado no contexto deste servidor, porém, aqui nós temos que explicitar isto, logo, precisaremos executar a procedure sp_add_jobserver e configurar o job para rodar no contexto do servidor local:

execute sp_add_jobserver
     @job_id = '7EC785F2-36D7-4BEB-B2E4-BFC38E7F4D31',
     @server_name = N'(local)'

Pronto!

Neste momento nosso job já tem uma forma e já pode ser executado.

Se quisermos testar a execução manualmente, podemos executar o seguinte comando:

 sp_start_job 'Backup MASTER'

Resultado:

Job ‘Backup MASTER’ started successfully.

Vejam que nosso job foi executado com sucesso e que o arquivo foi criado:

  • sp_add_jobschedule

Considerando que a principal funcionalidade do SQL Server Agent e seus jobs é automatizar tarefas, não há muito sentindo em executar jobs manualmente, logo, precisamos criar um agendamento para nosso job e assim partimos para a última etapa deste processo onde recorremos à procedure sp_add_jobschedule:

execute sp_add_jobschedule
     @job_id = '7EC785F2-36D7-4BEB-B2E4-BFC38E7F4D31',
     @name = N'Agenda Backup',
     @freq_type = 4,
     @active_start_time = 120000,
     @freq_interval = 1

O comando pode parecer complexo, mas analisando com calma veremos que é bem tranquilo. Vamos analisar cada um dos parâmetros separadamente:

No @job_id definimos para qual job estamos criando o agendamento utilizando o “big-código”.

Em @name atribuímos um nome para o nosso agendamento.

Em @freq_type temos as seguintes possibilidades:

@freq_type Frequência de Execução
1 somente uma vez
4 Diariamente
8 Semanalmente
16 Mensalmente

No nosso script @freq_type = 4, logo, o comando indica que o job será executado diariamente.

Em @active_start_time definimos o horário da execução, no nosso exemplo 12:00:00, sem os sinais de separação entre horas, minutos e segundos. Se o conteúdo desse parâmetro fosse 215600, o job seria executado às 09:56 da noite.

Por fim temos o parâmetro @freq_interval que está diretamente atrelado ao parâmetro @freq_type e foi definido como 1 porque nosso backup será executado todos os dias.

(Pode ser complexo definir valor para o parâmetro @freq_interval, mas não iremos nos aprofundar nele neste momento. Para entender sua composição consulte: http://msdn.microsoft.com/pt-br/library/ms366342.aspx)

Para verificar todos os parâmetros das procedures listadas acima, digite por exemplo:

 sp_help sp_add_jobschedule 
  • CONCLUSÃO

Neste texto podemos notar que automatizar tarefas via script não é uma tarefa tão árdua, mas sem dúvidas, na maioria
dos cenários, a utilização de uma ferramenta gráfica proporcionará maior produtividade; porém se um dia você se deparar com um MSDE ou situação semelhante, irá lembrar que com basicamente 4 passos é possível automatizar suas rotinas.

Colocando um script em espera

Uma dica rápida antes do feriadão:

Como agendar um script ou executá-lo de forma recorrente sem utilizar o SQL Agent?

O SQL possui um comando de controle de fluxo que pode nos auxiliar nessas tarefas: WAITFOR.

Como utilizá-lo?

Digamos que você queira monitorar o crescimento dos logs a cada 5 minutos. Nesse caso podemos utilizar o WAITFOR DELAY junto com uma estrutura de repetição como o while. Veja o exemplo:

declare @i int

set @i = 1

while @i < 12

begin

– coleta informação sobre espaço utilizado pelo log

dbcc sqlperf(logspace)

– aguarda 05 minutos para continuar

waitfor delay ’00:05:00′

set @i = @i + 1

end

Agora imagine um cenário onde você precise “agendar” a execução de um script para as 22h. Veja o exemplo:

– espera até às 22h

waitfor time ’22:00:00′

GO

dbcc sqlperf(logspace)

GO

select getdate() horaExecucao

É importante salientar que este comando não substitui o SQL Agent! Ele normalmente é utilizado em situações pontuais. Por exemplo, para o DBA às vezes é interessante monitorar durante alguns minutos a situação dos locks e para isso não é necessário criar um job e agendá-lo no SQL Agent, é mais simples utilizar o WAITFOR DELAY. Além disso você pode acompanhar o resultado das execuções diretamente no Management Studio, Query Analyser, sqlcmd, etc.

O comando é interessante, mas não veja nele uma forma de implementar uma nova política de backup, ok?

Bom feriadão!