É seguro reiniciar o Sql Server Agent?

Question

Eu me encontrei no papel tênue de um desenvolvedor encarregado de gerenciar um servidor SQL. Eu configurei alguns trabalhos para serem executados em uma programação, mas gostaria de receber uma notificação por e-mail após a conclusão.

Configurei o Database Mail e enviei uma mensagem de teste com sucesso, mas recebo uma erro dizendo que foi feita uma tentativa de enviar email quando nenhuma sessão foi estabelecida. Ao pesquisar isso , há muito de ruído que reiniciar o SQL Server Agent irá corrigir o problema.

Mas antes de eu ir muito longe no buraco do coelho, pensei em perguntar se há alguma consequência não intencional de reiniciar o SQL Server Agent? Por exemplo, isso afetará qualquer trabalho atual ou há um alto risco de que ele desligue, mas não reinicie?

Este é o SQL 2005 x64 SP4.

    

Answer 1

O agente só tende a lidar com a execução de tarefas de manutenção (backups, re-indexação, etc.). Verifique se não haverá nada em execução quando antes de reiniciá-lo e você deve estar ok. Eu nunca não tive que reiniciar antes, mas como qualquer outra coisa eu faria isso fora de horas se você estivesse preocupado.

    

Answer 2

Da minha experiência com o SQL, você deve poder reiniciar este serviço sem quaisquer conseqüências não intencionais. Enquanto o SQL Server estiver em execução, não deverá haver nenhum problema com o serviço do Agente que voltará a ser ativado assim que você pará-lo.

O que você viu nos registros de eventos que fazem você pensar que precisa reiniciar?

    

Answer 3

Execute o script para descobrir se há algum trabalho em execução. Se não, então é seguro reiniciá-lo.

List Running Jobs
/*
DESCRIPTION:
List the RUNNING jobs on an instance

CONFIGURATION
None

Compatibility list:
MSSQL2005
MSSQL2008
Does not work
MSSQL2000

Legend
@execution_status=1 Running
@execution_status=4 Idle
*/


IF EXISTS (SELECT * FROM tempdb.dbo.sysobjects WHERE ID = OBJECT_ID(N'tempdb..#JobInfo'))
BEGIN
DROP TABLE #JobInfo
END

SELECT * INTO #JobInfo
FROM OPENROWSET('sqloledb', 'server=(local);trusted_connection=yes'
, 'set fmtonly off exec msdb.dbo.sp_help_job @execution_status=1')

SELECT
-- [job_id]
[originating_server],[name],[enabled]
--,[description]
,[start_step_id]
--,[category]
,[owner]
--,[notify_level_eventlog],[notify_level_email],[notify_level_netsend],[notify_level_page],[notify_email_operator],[notify_netsend_operator],[notify_page_operator],[delete_level],[date_created],[date_modified]
--,[version_number]
,[last_run_date]
,[last_run_time]
,[last_run_outcome]
,[next_run_date]
,[next_run_time]
--,[next_run_schedule_id]
,[current_execution_status]
,[current_execution_step]
,[current_retry_attempt]
--,[has_step],[has_schedule],[has_target]
,[type]
FROM #JobInfo

Quando você recebe um erro, abaixo está a solução

Resolução: Basicamente, "Consultas distribuídas ad hoc" são desabilitadas por padrão no SQL Server devido à configuração de segurança e você não pode usar OPENROWSET ou OPENDATASOURCE e, se não puder executar essas duas funções de conjunto de linhas, não poderá acessar nenhuma fonte de dados remota. Então, como corrigir esse problema? Segue abaixo o script para ativar "Consultas distribuídas ad hoc".

USE master
GO
sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
sp_configure 'Ad Hoc Distributed Queries', 1;
RECONFIGURE;
GO

- OUTPUT

A opção de configuração "show advanced options" é alterada de 0 para 1. Execute a instrução RECONFIGURE para instalar. A opção de configuração "consultas distribuídas ad hoc" mudou de 0 para 1. Execute a instrução RECONFIGURE para instalar.

Como você pode ver acima, a configuração "Consultas distribuídas ad hoc" mudou de 0 para 1. Agora você pode executar facilmente qualquer "Consulta ad hoc"

Observação: por padrão, essa opção é definida como 0 e você precisa alterá-la para 1 para ativar esse recurso.