Job.EnumHistory возвращает неверную информацию о продолжительности задания, используя объекты управления SQL Server - PullRequest
2 голосов
/ 28 января 2011

Я делаю некоторые отчеты о заданиях SQL Server, используя объекты управления SQL Server (SMO).

Это тестовое задание:

enter image description here

Это код:

using Microsoft.SqlServer.Management.Smo;
using Microsoft.SqlServer.Management.Smo.Agent;

...

var server = new Server("TestServer");
var agent = server.JobServer;
var job = agent.Jobs["TestJob Long"];

var jhf = new JobHistoryFilter();
var tbl = job.EnumHistory(jhf);

foreach (DataRow row in tbl.Rows.Cast<DataRow>())
    {
        Console.WriteLine("StepId: {0} | Date: {1} | Duration: {2} | Status:{3}", row["StepId"], row["RunDate"], row["RunDuration"], (JobOutcome)row["RunStatus"]);
    }

Это вывод:

StepId: 0 | Date: 27-01-2011 16:23:14 | Duration: 146 | Status:Succeeded
StepId: 3 | Date: 27-01-2011 16:24:23 | Duration: 37 | Status:Succeeded
StepId: 2 | Date: 27-01-2011 16:23:50 | Duration: 33 | Status:Succeeded
StepId: 1 | Date: 27-01-2011 16:23:14 | Duration: 36 | Status:Succeeded

Строки с stepId = 0 являются «сводкой»шаг, который содержит совокупную информацию (или, по крайней мере, я так думал), но эта информация неверна.37 + 33 + 36 - это не 146 секунд, а только 106. Это соответствует времени, отображаемому в SQL Server Management Studio enter image description here

Это не проблема, ограниченная одним заданием, одним сервером и т. Д. - я получаюэто везде.

Я мог бы сложить шаги, чтобы получить правильное время, но я чувствую, что чего-то здесь не хватает - должно быть объяснение, так как я не думаю, что SMO просто возвращает неверную информацию.

Что мне здесь не хватает?

1 Ответ

3 голосов
/ 28 января 2011

С TechNet :

Столбец набора результатов run_time представляет время выполнения в виде масштабированного длинного целого числа. Целое число строится как сумма часов, масштабированных на 10000, минут, масштабированных на 100, и секунд. Значение использует 24-часовые часы. Например, время 1:03:09 вечера. представляется длинным целым значением 130309.

"Эй, давайте создадим новый тип данных продолжительности, в котором мы испортим целое число ..."

В документации фактически не упоминается, что этот специальный формат применяется к продолжительности, но он соответствует описанию, поэтому ...

...