【IT168 技术】为了保持SQL Server运行正常且平稳，就需要不间断的进行日常维护和监测工作。如果没有时刻保持警惕性，SQL Server的性能和稳定性将遭受损害。更严重的是数据库可能无法恢复，甚至彻底崩溃。本文将讨论DBA需要完成的日常工作，此外还将提供一部分脚本和建议，帮助大家缩短日常工作的时间。但是每个不同的环境，日常工作也会有所区别，本文提到的工作即使不能适用于所有的SQL Server设备，但对绝大多数情况都可以适用。
验证服务的可用性
需要确保起关键作用的SQL Server服务器的可用性。首先每天早晨上班时需要确定是否所有的SQL Server服务器都正常运转，这一项工作最好是积极主动并且反应迅速的。如果被用户打电话投诉某个服务器存在故障，后果将非常严重。
理想的情况是使用监控工具，可以在服务器不在正常运转时自动发送Email报告故障，这种方式可以使服务器在发生故障时立即做出反应并开始进行补救措施。该监控工具可以自己开发，也可以购买现成的。如果没有配置自动化的监控工具，也可以使用SQL Server Management Studio 里的Registered Servers工具向服务器发送单独的T-SQL语句。确保每个SQL Server实例能够正常运行，并且可以对简单的T-SQL语句进行响应，这样就可以轻松的了解每个实例预期的响应结果。通过监测实例，可以避免大部分询问特定服务器是否正常运行的尴尬问题。
系统补丁或者服务升级包安装后检验服务器的工作状况尤为重要，有时候服务器没有正确的在线恢复是由于系统的维护工作没做好。不要过度依赖业务人员对服务器的检验，通常情况下，他们申请关键补丁更新时，会有成百上千个服务器补丁。正因为这样，他们经常会忽略某个故障或者问题，因此最好在安装系统补丁或者服务器升级包后对服务器进行详细检查。
监控SQL代理作业
SQL代理作业在DBA所管理的每个SQL Server实例上运行了至少一整夜，因此需要每天检查这些作业，以确保它们能够正常运行。当然也可以在SQL Server作业中加入通知，当作业发生错误时自动发送邮件。但是通知邮件有时会跟其他大量邮件堆在一起，很有可能被忽视。因此，每天早上的第一件事就是对SQL代理作业进行快速扫描，以确保其每晚都已成功运行。
快速审查SQL Server代理作业有很多方法，其中Reporting Services报告提供了所有报错的SQL Server代理作业清单，还有访问管理所有实例的作业步骤。只要订阅这个报告就能够在每天早晨收到一封Email，得知前一天晚上的作业是否出错。有了这个包含所有实例的单独报告，DBA可以快速确定SQL Server代理作业的报错信息。如果发现一个报错信息，需要在其他人没有发现前修复这个错误，并且重新运行。下面是Reporting Services报告的代码：
DECLARE @c INT
-- Table of failed jobs
DECLARE @failed_jobs TABLE (
job_id uniqueidentifier,
step_id int,
step_name sysname,
sql_message_id int,
sql_severity int,
message nvarchar(1024),
run_status int,
FailureDate datetime,
server nvarchar(30)
)
INSERT @failed_jobs( job_id, step_id, step_name, sql_message_id, sql_severity,
message, run_status, FailureDate, server )
SELECT job_id, step_id, step_name, sql_message_id, sql_severity,
message, run_status, FailureDate, server
FROM ( SELECT job_id, step_id, step_name, sql_message_id, sql_severity,
message, run_status,
( DATEADD(ss, CAST(SUBSTRING(CAST( jh.run_duration
+ 1000000 AS char(7)), 6, 2) AS int),
DATEADD(mi, CAST(SUBSTRING(CAST( jh.run_duration
+ 1000000 AS char(7)), 4, 2) AS int),
DATEADD(hh, CAST(SUBSTRING(CAST( jh.run_duration
+ 1000000 AS char(7)), 2, 2) AS int),
DATEADD(ss, CAST(SUBSTRING(CAST( jh.run_time
+ 1000000 AS char(7)), 6, 2) AS int),
DATEADD(mi, CAST(SUBSTRING(CAST( jh.run_time
+ 1000000 AS char(7)), 4, 2) AS int),
DATEADD(hh, CAST(SUBSTRING(CAST( jh.run_time
+ 1000000 AS char(7)), 2, 2) AS int),
CONVERT(datetime, CAST(jh.run_date AS char(8))) )))))) )
AS FailureDate,
server
FROM msdb.dbo.sysjobhistory AS jh ) AS jh
WHERE (GETDATE() > jh.FailureDate)
AND (jh.run_status = 0)
-- Identify how many days to go back and look for failures
AND (DATEADD(dd, -1 , GETDATE()) < jh.FailureDate)
SELECT @c=count(*)
FROM @failed_jobs
IF @c > 0
BEGIN
SELECT SUBSTRING(j.name, 1, 50) AS JobName,
SUBSTRING(jh.step_name, 1, 50) AS StepName, message,
jh.FailureDate AS FailureDate
FROM @failed_jobs jh INNER JOIN
msdb.dbo.sysjobs j ON jh.job_id = j.job_id
END
ELSE
SELECT 'No Failed Jobs For Reporting Period' JobName, ' ' StepName, ' ' FailureDate
▲最近24小时报错的作业列表
当DBA监控SQL Server代理作业时，同样应该审核作业历史记录，因为偶尔会出现一些状况导致作业运行时间延长。如果能够了解SQL Server代理作业的平均运行时间，就能根据运行时间的延长或缩短分析SQL Server存在的问题。
有时会看到SQL Server代理作业被挂起。当这种情况发生时，如果这个作业被挂起且持续运行，那么下个步骤将不会进行。为了避免错过作业的下一个运行周期，需要确保被挂起的作业已经停止运行，另外需要明确导致作业被挂起的原因，并在下个步骤开始运行之前解决该问题。因此就需要监测长时间运行的作业是否已经被挂起，有很多方法可以进行这项监控。如果在网上搜索“长时间运行的SQL代理作业(long running SQL Agent jobs)”能够找到一些辨别长时间运行的作业是否被挂起的解决方法。
