SQL Server 2005 хранимой процедуры непредвиденное поведение

Question

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

Один из разделов моей хранимой процедуры:

OPEN @getInputBuffer

                FETCH NEXT
                FROM @getInputBuffer INTO @String

                WHILE @@FETCH_STATUS = 0

                BEGIN
                --PRINT @String

                INSERT INTO #Temp(ArticleID,UserID)             
                SELECT  A.ID,@UserID
                FROM    CONTAINSTABLE(Question,(Text),@String)  QQ 
                JOIN    Article A WITH (NOLOCK)  ON A.ID = QQ.[Key]
                WHERE   A.ID > @ArticleID


                FETCH NEXT
                FROM @getInputBuffer INTO @String

                END

                CLOSE @getInputBuffer
                DEALLOCATE @getInputBuffer

Это задание выполняется каждые 5 минут и проверяет последние 50 статей.

Последние 3 месяца он работал нормально, но за неделю до неожиданного поведения.

Проблема заключается в том, что она отправляет не относящиеся к делу результаты.

@String содержит ключевое слово предупреждения пользователя и соответствует последним статьям с использованием полнотекстового поиска. Обычное время выполнения 3 минуты, но время его выполнения 3 дня (в проблеме).

Сейчас текущее состояние исправно, но мы не можем найти причину, по которой он отправил несущественные результаты.

Примечание: Я уже удалил шумовые слова из ключевого слова оповещения пользователя. Я использую SQL Server 2005 Enterprise Edition.

Answer 1

У меня нет ответа, но вы задали все вопросы?

Всегда ли длительное время выполнения происходит для всех запросов? (Да -> Повреждение? Проблемы с диском?)

Или это только для одного @String? (Да -> что-нибудь необычное в этом термине? Есть ли в строке «скрытый» символ, который не отображается в вашем редакторе?)

Хорошо ли это работает @String против других наборов записей, может быть, неделю назад? (Да -> какие-нибудь необычные строки в строках данных?)

Можете ли вы воспроизвести его по своему желанию? (Из вашего вопроса кажется, что проблема исчезла, и вы не можете воспроизвести ее.) Это было только для одного человека, в одно время?

Надеюсь, это немного поможет!

Answer 2

Поскольку курсоры вложены, вы можете попробовать следующее. Насколько я понимаю, проверка на ноль может привести к неприятностям, когда курсоры вложены Недавно мы изменили все наши курсоры на что-то вроде этого.

WHILE (@@FETCH_STATUS <> -1) BEGIN
    IF (@@FETCH_STATUS <> -2) BEGIN

        INSERT INTO #Temp(ArticleID,UserID)             
            SELECT  A.ID,@UserID
            FROM    CONTAINSTABLE(Question,(Text),@String)  QQ 
            JOIN    Article A WITH (NOLOCK)  ON A.ID = QQ.[Key]
            WHERE   A.ID > @ArticleID

    END

    FETCH NEXT FROM @getInputBuffer INTO @String
END

Answer 3

1) Откуда вы знаете, что он посылает несущественные результаты?

Если это связано с тем, что пользователь сообщил о проблеме: вы уверены, что она не меняла свои ключевые слова между почтой и отчетом?

Можете ли вы добавить автоматическую проверку в конце процедуры, чтобы убедиться, что она дала плохие результаты? Возможно, тогда вы сможете отследить случаи, когда возникают проблемы

2) «Это задание запускается каждые 5 минут и проверяет последние 50 статей». Вы уверены, что это не связано со временем? Что делать, если работа занимает более 5 минут? Начинается вторая работа ...

Вы не показываете объявление курсора, оно локальное или могут быть какие-то помехи, если несколько процессов выполняются одновременно? Возможно, попробуйте добавить какой-нибудь механизм блокировки.

Answer 4

Я бы согласился с мнением Глена Литтла.

Если пользователь зарегистрировал подписанное ключевое слово, которое по совпадению (или преднамеренно) содержит некоторые предикаты поиска CONTAINSTABLE, например, РЯДОМ, тогда запрос может занять больше времени, чем обычно. Возможно, «минуты становятся днями длиннее, но дольше».

Проверка подписных ключевых слов, содержащих *, ", NEAR и т. Д.

Функция CONTAINSTABLE допускает очень сложный набор критериев. Рассмотрим функцию FREETEXTTABLE с более легким алгоритмом сопоставления.

Answer 5

Работает ли CONTAINSTABLE(Question,(Text),@String) в окне запроса ad hoc? Если нет, возможно, ваши индексы полнотекстового поиска повреждены и требуют перестройки

• Перестройка полнотекстового каталога
• Темы для полнотекстового поиска

Также проверьте все нормальные индексы в таблице Article, они могут просто нуждаться в пересоздании для статистических целей или могут быть повреждены тоже

• ОБНОВЛЕНИЕ СТАТИСТИКИ (Transact-SQL)