Хранимые проки ломаются на ночь - PullRequest
Новая
       23

Хранимые проки ломаются на ночь

1 голос
/ 26 апреля 2010

Мы работаем с MS SQL 2005, и в последние несколько дней у нас возникла очень специфическая проблема.

У меня есть два процесса, один из которых создает почасовой отчет с данными. И другой, который вызывает его, помещает его результаты во временную таблицу, выполняет некоторые агрегации и возвращает сводку.

Они отлично работают ... до следующего утра.

На следующее утро, внезапно, отчет о вызовах жалуется на неверное имя столбца.

Исправление - это просто перекомпиляция вызывающего процесса, и все снова работает хорошо.

Как это может произойти? Это случилось три ночи подряд с момента запуска этих проков в производство.

РЕДАКТИРОВАТЬ: Похоже, что это не перекомпиляция, которая требуется для вызывающего (резюме) proc. Я просто смог решить проблему, выполнив процедуру вызова (почасовая). Затем выполнить сводную процедуру. Это имеет меньше смысла, чем раньше.

EDIT2: Часовой процесс довольно большой, и я не буду публиковать его здесь полностью. Но, в конце концов, он выполняет SELECT INTO, затем условно возвращает соответствующий результат (ы) из созданной временной таблицы. 

Select      [large column list]
    into    #tmpResults
    From    #DailySales8
    Where   datepart(hour,RowStartTime) >= @StartHour
    and datepart(hour,RowStartTime) < @EndHour
    and datepart(hour, RowStartTime) <= @LastHour

IF @UntilHour IS NOT NULL 
    AND EXISTS (SELECT * FROM #tmpResults WHERE datepart(hour, RowEndTime) = @UntilHour) BEGIN
        SELECT      * 
            FROM    #tmpResults
            WHERE   datepart(hour, RowEndTime) = @UntilHour
END ELSE IF @JustLastFullHour = 1 BEGIN
        DECLARE @MaxHour INT
        SELECT @MaxHour = max(datepart(hour, RowEndTime)) FROM #tmpResults

        IF @LastHour > 24 SELECT @LastHour = @MaxHour

        SELECT      * 
            FROM    #tmpResults
            WHERE   datepart(hour, RowEndTime) = @LastHour

        IF @@ROWCOUNT = 0 BEGIN
            SELECT      * 
                FROM    #tmpResults
                WHERE   datepart(hour, RowEndTime) = @MaxHour
        END
END ELSE BEGIN
        SELECT * FROM #tmpResults
END

Затем он удаляет все временные таблицы и завершает работу.

Звонящий (Резюме)

Сначала создается временная таблица #tmpTodaySales для хранения результатов, список столбцов СООТВЕТСТВУЕТ определению #tmpResults в другом процессе. Тогда это заканчивает тем, что вызвало почасовую процедуру пару раз 

    INSERT #tmpTodaysSales
        EXEC HourlyProc @LocationCode, @ReportDate, null, 1


    INSERT #tmpTodaysSales
        EXEC HourlyProc @LocationCode, @LastWeekReportDate, @LastHour, 0

Я верю, что эти призывы терпят неудачу. Но перекомпиляция proc или выполнение почасовой процедуры вне этого, а затем вызов сводного proc устраняет проблему.

Ответы [ 2 ]

0 голосов
/ 28 апреля 2010

Два вопроса:

Меняется ли схема # DailySales8 вообще? Имеет ли он прямую / косвенную зависимость от даты исполнения или от любого из параметров, предоставленных HourlyProc?

Какое выполнение INSERT #tmpTodaysSales EXEC HourlyProc ... в сводке завершается неудачей - первое или второе?

0 голосов
/ 26 апреля 2010

Как выглядят планы обслуживания на ночь, и есть ли другие запланированные работы на ночь, которые выполняются между 2230 и 1000 на следующий день? Возможно, что этот шаг в плане обслуживания или другой работе агента вызывает какое-то повреждение, которое нарушает ваш SP.

...