需求描述
在我们的生产环境中，大部分情况下需要有自己的运维体制，包括自己健康状态的检测等。如果发生异常，需要提前预警的，通知形式一般为发邮件告知。
邮件作为一种非常便利的预警实现方式，在及时性和易用性方面也有着不可替代的优点。
所以，在本篇中将详细的分析下在SQL Server中的邮件通知功能及使用方式等。
本篇实现
1、通过SQL Server自带的邮件功能实现运维的预警及检测
2、利用数据库邮件组件代替传统的C#发送邮件的弊端
3、实现Job任务运行状态的检测
4、利用PowerShell实现Job任务计划的检测
<1>基础配置
首先，我们来配置下SQL Server中的邮件组件的基础服务项。SQL Server自从05版本起，邮件功能就不需要开启外配配置管理器了，它有着自己的组件，实现邮件发送的功能。
如果，没使用过，可以按照以下步骤进行配置，步骤很简单。
右键，配置数据库邮件
然后直接下一步就行，然后新建一个账户
然后，下一步完成就可以，步骤很简单，这里面有几个概念需要理清楚，对于SQL Server的邮件账户是由权限控制的，目的是实现不同的人使用不同的邮件账户，比如大型数据库的管理一般有好几个DBA负责运维，分职责之后的运行，发送预警邮件也就产生了区分，总不能模块中出现了任何问题都发送给一个人。
跟你一毛钱关系都没有的异常，天天给你发邮件，是不是很不爽？？....这种管理方式是灰常暴力的！
为了解决上述问题，SQL Server对邮件的账户进行了分类：
分为公共账户和专用账户。
一般如果管理人员少，就配置一个公共账户就可以，有问题都发送到该邮箱就可以。
至此，你已经完成了数据库邮件模块的配置，步骤很简单。这里可以发送一封测试邮件，来测试下邮件的连通性。
提示：SQL Server邮件组件的运行需呀SQL Server Age运行执行，所以需要确保此服务正在运行。
在“数据库邮件”上右键，发送测试电子邮件，输入目标邮箱的地址，然后单击发送就可以。
至此，你的SQL Server已经完成邮件组件的基础配置，然后剩下的工作就是如何利用该组件进行部分工作的完成了。
<2>c#调用数据库邮件组件进行邮件的发送
还记得当年刚毕业的时候，对于发送邮件这块功能当时是异常的痴迷，各种的研究和各种的调试。
后来的终归在废了九牛二虎之力之后，终于在一个午夜梦回之时看到了我梦寐以求的测试邮件发送通知，想想一个字描述：草！
大体我记得需要引用以下几个命名空间：
using System.Net; using System.Net.Mail;
然后利用C#提供的SmtpClient类进行组装成邮件实体，而后一个Send()方法，这其中的痛苦点在于各种编码规范等。
我相信现在也有很多程序猿依然再采用着这种方式。
今天提供另外一种灵活的实现方式，利用SQL Server数据库的邮件组件进行邮件的发送。
关于上面第一个步骤提供的邮件组件的调用，其实在SQL Server中是提供系统自带的存储过程进行实现的。方法如下：
该存储过程提供了发送邮件的的各种参数，完全满足发送邮件的各种需求，比如：主题、内容、附件、CC、秘密CC....等等吧
调用该存储过程的方法如下：
--存储过程调用发邮件 EXEC msdb.dbo.sp_send_dbmail @profile_name = 'testMail', @recipients = '787449667@qq.com', @body = '这是测试邮件', @subject = '我发的', @file_attachments='C:\temp\3-26-2015-16-20-21.png'
上面一个简单的方法执行既可以实现，邮件的发送。
然后，你需要的就是c#调用该存储过程了。
关于写C#代码通过Ado.net调用存储过程的过程这里就不赘述了，我相信这是入门级别的小白也能搞定的事情了。
而后，这里捎带分析一下邮件组件的原理和性能问题。我相信这是很多人关心的，其实SQL Server的邮件发送时通过一个底层的JOB轮询执行的，所以根本不用担心其执行顺序和性能问题。
并且SQL Server为此还提供了几个系统的视图来查看历史运行状态和当前邮件的队列状态：
--邮件内容
SELECT * FROM msdb.dbo.sysmail_allitems
--邮件发送日志
SELECT * FROM msdb.dbo.sysmail_event_log
并且SQL Server提供了邮件重新发送的功能以及其它默认参数，具体设置参照此画面：
至此，已经完成了利用C#进行发送邮件的功能。
我相信基本上用C#就会搭配微软自己的SQL Server数据库，而使用它之后就可以少量的代码实现邮件发送的功能。
<3>实现Job任务运行状态的检测
在我们使用SQL Server的时候，很多情况下都需要自定义Job进行部分功能的实现，而大部分时间是采取凌晨或者非业务期进行工作。
而此Job的运行结果的检测便形成了一个需要跟踪的问题，比如有时候N个Job的运行，只有几个出现问题，并且不确定的此Job发生在那个机器上，所以自动化运维的重要性就不言而喻了。
对于上面问题的解决，SQL Server提供了很简单的配置就可以实现。
（1）首先，需要定义几个操作员，说到底就是几个人值班运维此数据库的
上面，我就定义了一个人，其实可以定义多个人，几个运维人员几个...
（2）其次，需要定义警报，说到底就是将产生的预警发送给上面的几个运维人员。
这里面的严重性选项其实是一个很重要的功能，一些简单的问题警告有时候是不需要及时关注的，或者说不需要暂时处理的。
但是有些问题则需要里面去解决，比如服务器宕机....
然后，我们来将此预警关联之操作员
到此，我们已经完成了预警的检测配置，然后需要的就是关联下Job代理的任务属性值。
经过上面的配置，任何我们自定义的Job工作状态都可以进行自动化检测了。
比如：某个Job跑批成功了，某个Job跑批失败了。我们来新建一个自定义的Job来测试下：
然后设置警告
然后，在运行此Job出现异常的时候，就可以自动的报告到相应的运维人员了。
这里我们就设置了一个运维人员，所以这里只发送给一个人。
我们来手动运行下，来测试一下效果
嘿嘿，果然，发出了警报，看起来很贴心的样子
至此，此功能已经配置完成，自己可以灵活的实现。
结语
本来打算将利用Power Shell脚本检测的功能实现方式也加上的，但文章已经稍有点篇幅了，后续再完成吧。此篇的关于SQL Server的邮件功能算作抛砖引玉了，自己另有需求可以自己灵活实现。
其实，在本篇所介绍的Job任务的检测在几台服务器上存在还问题不大，但是如果多台服务器，如果每台服务器上都有几个Job异常的话，每天早上打开邮件多的估计会令你头皮发麻，并且在自带的异常报警中，没有给出详细的错误信息，其实这是一个很不爽弊端。
所以，为了优雅的进行自动化运维的工作，我们将会每次将我们所有检测的服务器Job运行状态进行扫描，而后将其汇总至一封邮件，然后按照重要性发送至固定的运维人员。
听起来是不是还有点小激动的样子，下一篇我们来实现此功能。有兴趣的童鞋，可以提前关注。
关于SQL Server自动化运维和检测的内容很广泛，其中很多都是从日常的经验中出发，一步步的从手动到自动的过程。
如果您看了本篇博客,觉得对您有所收获，请不要吝啬您的“推荐”。
