Как запросить свойства почтового профиля включения системы оповещения

Защита будущего - очень мудрая идея :). Как вы заметили, и xp_regread, и xp_instance_regread также недокументированы. И http://social.msdn.microsoft.com/Forums/sqlserver/en-US/b83dd2c1-afde-4342-835f-c1debd73d9ba/xpregread объясняет вашу озабоченность (плюс, он предлагает вам альтернативу).

Ваша трассировка и запуск sp_helptext 'sp_get_sqlagent_properties' — хорошее начало. Следующее, что нужно сделать, это запустить sp_helptext 'sp_helptext' и отметить его ссылку на sys.syscomments. Тема BOL sys.syscomments перенаправляет вас на sys.sql_modules, что указывает на следующий шаг. К сожалению, для ваших нужд только одна строка (для 'sp_get_sqlagent_properties') будет возвращена при запуске USE msdb; ВЫБЕРИТЕ object_name (object_id) FROM sys.sql_modules WHERE определение LIKE '%sp_get_sqlagent_properties%'. Таким образом, я предполагаю, что вам не повезло - альтернативного общедоступного модуля (sproc) не существует. Мое предположение может быть ошибочным :).

Я делаю вывод, что вызовы xp_reg% существуют для нужд клиента (SMO, SSMS и т. д.), таких как установка/получение свойств агента. Что еще более важно (для ваших нужд), ваш запуск sp_helptext также показывает, что SSMS (клиент) использует хранилище реестра (т. е. не хранилище SQL). К сожалению, я должен сделать вывод (на основании отсутствия доказательств поиска в библиотеке), что эти ключи (и их значения) также не задокументированы...

Вышеупомянутое, кажется, ставит вас в рассол. Вы можете решить: «Если мы собираемся полагаться на недокументированные ключи реестра, мы могли бы также полагаться на недокументированные вызовы для их чтения», но я не буду этого рекомендовать :). Вы также можете подать запрос на функцию по адресу https://connect.microsoft.com/ (ваша потребность очевидна). , но поскольку ваша потребность касается запроса функции на стороне клиента, я не рекомендую задерживать дыхание в ожидании исправления :).

Возможно, пришло время сделать шаг назад и взглянуть на картину шире:

• Как часто можно менять этот ключ и как часто этот процесс будет опрашивать это изменение?

• Электронная почта использует примитив почты. Отправитель: «Уважаемый получатель, вы получили мое письмо?» Получатель: «Уважаемый отправитель, вы отправили мне письмо?» Отключение профиля электронной почты — не единственная причина сбоя электронной почты.

Будет ли другой подход более полезным по сравнению с периодической проверкой ключа?

Одним из подходов может быть периодическая отправка электронной почты «KeepAlive». Если электронное письмо «KeepAlive» не приходит периодически, возможно, этот ключ был изменен, возможно, почтовое отделение находится в отпуске, или, возможно, произошло что-то еще (не менее плохое). Кроме того, этот подход должен полностью поддерживаться, документироваться и быть перспективным. Кто знает, как и какие ключи будут использоваться в следующей версии агента SQL Server?

Первая пуля не решена (также она не будет решена путем периодической проверки ключа), и, возможно, у вас есть дополнительные потребности (стоит упомянуть в MS Connect).

Наконец-то я нашел способ сделать это с помощью PowerShell и Microsoft.SqlServer.Management.Smo.Agent.JobServer.

Вот сценарий PowerShell, который я написал, чтобы проверить, включены ли почтовые оповещения агента SQL, и убедиться, что агент SQL настроен на автоматический запуск при перезагрузке сервера. Это работает с локальными или удаленными экземплярами SQL.

# usage examples
Check-SQLAgentConfiguration -InstanceName 'localhost\sql2014'
Check-SQLAgentConfiguration -InstanceName 'RemoteServerName'


function Check-SQLAgentConfiguration{
    param([string]$InstanceName='localhost')

    [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.SMO') | out-null;

    $smosrv = new-object Microsoft.SqlServer.Management.Smo.Server($InstanceName);
    $smosrv.ConnectionContext.ConnectTimeout = 5; #5 seconds timeout.
    $smosrv.ConnectionContext.ApplicationName = 'PowerShell Check-SQLAgentConfiguration';
    "Server: {0}, Instance: {1}, Version: {2}, Product Level: {3}" -f $smosrv.Name, $smosrv.InstanceName, $smosrv.Version, $smosrv.ProductLevel;

    # NOTE: this does not seem to ever fail even if SQL Server is offline.
    if(!$smosrv){"SQL Server Connection failed";  return $null;}   

    $agent = $smosrv.JobServer;

    if(!$agent -or $agent -eq $null){
        throw "Agent Connection failed";  
        return -2;
    }

    $agentConfigErrMsg = "";

    if($agent.AgentMailType -ne "DatabaseMail"){ $agentConfigErrMsg += " AgentMailType: " + $agent.AgentMailType + "; "; }
    if(!$agent.DatabaseMailProfile){$agentConfigErrMsg += " DatabaseMailProfile: " + $agent.DatabaseMailProfile + "; ";}
    if($agent.SqlAgentAutoStart -ne "True"){$agentConfigErrMsg += " SqlAgentAutoStart: " + $agent.SqlAgentAutoStart + " ServiceStartMode: " + $agent.ServiceStartMode + "; "; }

    if($agentConfigErrMsg.length -gt 0){
       $agentConfigErrMsg = "Invalid SQL Agent config! " + $agentConfigErrMsg; 
       throw $agentConfigErrMsg;
       return -1;
    }

    <##
    #for debugging:
    "Valid: "
    "AgentMailType:" + $agent.AgentMailType;
    "DatabaseMailProfile: " + $agent.DatabaseMailProfile;
    "ServiceStartMode: " + $agent.ServiceStartMode;
    "SqlAgentAutoStart: " + $agent.SqlAgentAutoStart;
    #"SqlAgentMailProfile: " + $agent.SqlAgentMailProfile;
    #>

    return 0; 
}

SQL 2008R2 использует службы-брокеры, такие как очереди для обработки почты (http://technet.microsoft.com/en-us/library/ms175887%28v=sql.105%29.aspx). В наших средах я проверяю, что соответствующая очередь существует и активна.

SELECT * FROM msdb.sys.service_queues
WHERE name = N'ExternalMailQueue' 
AND is_receive_enabled = 1;

Эта таблица размещена в Интернете (http://technet.microsoft.com/en-us/library/ms187795%28v=sql.105%29.aspx).

Тестирование показывает, что это делает необходимый переход, когда мы переходили от нового экземпляра -> включенная почта -> отключенная почта и обратно.