我编写了一个简单的存储过程(作为作业运行),用于检查用户订阅关键字警报。当文章 如果订阅的关键字与文章标题匹配,则发布的存储过程会向这些用户发送电子邮件。
我的存储过程的一部分是:
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。
答案 0 :(得分:1)
我没有答案,但你问了所有问题吗?
所有查询的执行时间是否总是会发生? (是 - >腐败?磁盘问题?)
或仅适用于一个@String
? (是 - >关于这个术语的任何异常?字符串中是否有“隐藏”字符,而这些字符在编辑器中没有显示?)
对于其他记录集合@String
它是否可以正常工作,可能是从一周前开始的? (是 - >数据行中的任何异常字符串?)
你可以随意复制吗? (根据你的问题,似乎问题已经消失,你无法重现它。)它是否只适用于一个人一次?
希望这有点帮助!
答案 1 :(得分:0)
CONTAINSTABLE(Question,(Text),@String)
是否在即席查询窗口中有效?如果不是,则可能是您的全文搜索索引已损坏且需要重建
同时检查Article
表上的任何正常索引,它们可能只需要重建统计目的或者也可能已损坏
答案 2 :(得分:0)
我会同意Glen Little的思路。
如果用户已经注册了一个订阅的关键字,其巧合地(或故意地)包含一些CONTAINSTABLE搜索谓词,例如然后,查询可能需要比平时更长的时间。也许“分钟变成天”的时间可能更长,但更长。
检查包含*,“,NEAR和&等的订阅关键字。
CONTAINSTABLE功能允许一组非常复杂的标准。考虑具有较轻匹配算法的FREETEXTTABLE函数。
答案 3 :(得分:0)
1)你怎么知道它会发出无关的结果?
如果是因为用户报告了问题:你确定她没有在邮件和报告之间更改她的关键字吗?
您是否可以在程序结束时添加一些自动检查以检查是否收集了错误的结果?也许那时你可以在发生问题时捕获案例
2)“这项工作每5分钟运行一次,检查最后50篇文章。” 你确定它与时间无关吗?如果一次工作超过5分钟,会发生什么?第二份工作正在开始......
您没有显示光标声明,是否是本地的,或者如果多个进程同时运行会产生某种干扰?也许尝试添加某种锁定机制。
答案 4 :(得分:0)
由于游标是嵌套的,因此您需要尝试以下操作。我的理解是,当光标嵌套时,测试零会让你陷入麻烦。我们最近将所有游标改为类似的东西。
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