NHibernate的 - “GenericADOException:无法执行查询”

问题描述:

我们的生产环境中使用的NHibernate v3.1.0.4000 突然开始给与全文检索搜索时,此错误:NHibernate的 - “GenericADOException:无法执行查询”

[SQLEXCEPTION(0x80131904) :超时过期。在操作完成之前已经超时或服务器没有响应。] System.Data.SqlClient.SqlConnection.OnError(SqlException异常,Boolean breakConnection)+404 System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()+ 412 System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior,SqlCommand的cmdHandler,SqlDataReader的数据流,BulkCopySimpleResultSet bulkCopyHandler,TdsParserStateObject stateObj)1363 System.Data.SqlClient.SqlDataReader.ConsumeMetaData()59 System.Data.SqlClient的。 SqlDataReader.get_MetaData()+118 System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds,RunBehavior runBehavior,String resetOptionsString)+6388257 System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBeh System.Data.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior,RunBehavior runBehavior,Boolean returnStream,String方法,DbAsyncResult结果)+538 System.Data.SqlClient.SqlCommand。 RunExecuteReader(CommandBehavior cmdBehavior,RunBehavior runBehavior,布尔returnStream,String方法)+28 System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior行为,字符串方法)+256 System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior行为)+ 19 System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader()+23 NHibernate.AdoNet.AbstractBatcher.ExecuteReader(IDbCommand cmd)+845 NHibernate.Loader.Loader.GetResultSet(IDbCommand st,Boolean autoDiscoverTypes,布尔可调用,RowSelection选择,ISessionImplementor会话)580 NHibernate.Loader.Loader.DoQuery(ISessionImplementor会话,QueryParameters queryParameters,布尔returnProxies)275个 NHibernate.Loader.Loader.DoQueryAndInitializeNonLazyCollections(ISessionImplementor会话,QueryParameters queryParameters,布尔returnProxies )205 NHibernate.Loader.Loader.DoList(ISessionImplementor会话,queryParameters queryParameters)195

[GenericADOException:无法执行查询 [SELECT COUNT(DISTINCT this_.IdDocument)作为y0_ FROM Document.Document THIS_内连接Document.DocumentCopy documentc1_ on this_.IdDocument = documentc1_.IdDocument WHERE((@ p0 = @ p1并包含(this_.Title,@ p2))和this_.IsDe (document)(@ p4 = @ p5和documentc1_.CreationDate> = @ p6)和documentc1_.CreationDate < = @ p7)和(documentc1_.IdOwnedByGroup = @ p8或documentc1_.IdCreatedByGroup = @ p9))] 位置参数:#0> 0#1> 0#2>“#3>假#4> 0#5> 0#6> 12/5/2015 12:00:00ÿÿ#7> 12/5/20 11:59:00ýÿýÿ#8> 1#9> 1 [SQL:SELECT count(distinct this_.IdDocument)as y0_ FROM Document.Document this_ inner join Document.DocumentCopy documentc1_ on this_.IdDocument = documentc1_.IdDocument WHERE((@ p0 = @ p1并包含(this_.Title,@ p2))和this_.IsDeleted = @ p3)和(((@ p4 = @ p5和documentc1_.CreationDate> = @ p6)和documentc1_.CreationDate < = @ p7)和(documentc1_.IdOwnedByGroup = @ p8或documentc1_.IdCreatedByGroup = @ p9))]] NHibernate.Loader.Loader.DoList(ISessionImplementor session,QueryParameters queryParame TER值)637 NHibernate.Loader.Loader.ListIgnoreQueryCache(ISessionImplementor会话,QueryParameters queryParameters)23 NHibernate.Loader.Criteria.CriteriaLoader.List(ISessionImplementor会话)60 NHibernate.Impl.SessionImpl.List(CriteriaImpl标准,IList的结果)+1025 NHibernate.Impl.CriteriaImpl。列表(IList的结果)63 NHibernate.Impl.CriteriaImpl.UniqueResult()57 Domain.Repositories.DocumentRepository.Domain.Abstract.IDocumentRepository.GetAll(标准1 criteria, Int32& count, Dictionary 2 openFieldCriteria)272个 ServicesImplementation.DocumentService.GetDocuments(标准1 criteria, Int32& count, String metadataSearchTerm) +510 Docman.Models.List.ListModel.GetDocuments(Int32& count) +102 ASP._Page_Views_List_Index_cshtml.Execute() in d:\wwwroot\inetpub\docman\Views\List\Index.cshtml:27 System.Web.WebPages.WebPageBase.ExecutePageHierarchy() +280 System.Web.Mvc.WebViewPage.ExecutePageHierarchy() +104 System.Web.WebPages.StartPage.ExecutePageHierarchy() +143 System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage) +157 System.Web.Mvc.ViewResultBase.ExecuteResult(ControllerContext context) +384 System.Web.Mvc.<>c__DisplayClass1c.<InvokeActionResultWithFilters>b__19() +33 System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter(IResultFilter filter, ResultExecutingContext preContext, Func 1续)826372个 System.Web.Mvc.ControllerActionInvoker.InvokeActionResultWithFilters(controllerContext controllerContext,IList`1过滤器,的ActionResult的ActionResult)265 System.Web.Mvc.ControllerActionInvoker.InvokeAction(controllerContext controllerContext,字符串actionName)827248 系统.Web.Mvc.Controller.ExecuteCore()+159 System.Web.Mvc.ControllerBase.Execute(RequestContext requestContext)+335 System.Web.M VC。 <> c__DisplayClassb.b__5()+62 System.Web.Mvc.Async。 <> c__DisplayClass1.b__0()+20 System.Web.Mvc。 <> c__DisplayClasse.b__d()54 System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()469 System.Web.HttpApplication.ExecuteStep(IExecutionStep步骤,布尔& completedSynchronously)375

我已经尝试了上面列出的SSMS上的查询,它似乎运行良好和快速。

这里提到了一个类似的错误:Nhibernate FieldNameLookup throws IndexOutOfRangeException,虽然我的错误信息中没有包含任何IndexOutOfRangeException

有谁能告诉我这是什么原因?

UPDATE:

更多信息:

我们正在使用的预测。

根据错误日志,错误来自某个只返回一个计数的查询,而不是很多包含许多字段的行。

正如我之前所说的,同样的查询(在错误日志中列出)运行速度快,而且从SSMS运行时没有问题。然而,执行此SQL查询的应用程序所做的所有查询似乎都会因上述错误而失败。

由于我们使用NH的自定义包装,因此代码可能并不清晰。

我认为我在异常顺序上是错误的,首先发生超时,然后ADO.net报告另一个错误。 所以,我想这是一个超时毕竟...

更新2:

一些额外的研究之后,似乎这是关系到这个问题,并查询确实超时,只是不从SSMS:

Query times out when executed from web, but super-fast when executed from SSMS

+0

的datails说是超时问题。 – Najera

+0

你要带回多少数据?这样做的代码是什么样的?你在使用预测吗? – Fran

+0

@Najera如果你看下面的第一个异常,有另一个异常,似乎是内部的例外。 – user2173353

这竟然是这不能因为它是使用针对ARITHABORT不同的值(我的应用程序会话和SSMS会话之间)从SSMS转载超时。

有一次,我为它的默认值设置为ON/1为DB,一切都被固定:

USE [master]; 
GO 
ALTER DATABASE [{database_name}] SET ARITHABORT ON WITH NO_WAIT; 
GO 

在这里看到:https://dba.stackexchange.com/a/95090/71232

+0

错误,非常错误。您刚刚从您使用过的查询计划缓存中逐出了一个错误的查询计划。麻烦会在一段时间后再次回来并再次咬你。你找到[这个答案](/ a/2248566/1178314)这个事实很有希望,但看起来你已经读得太快了。您的实际问题很可能是索引问题,导致SQL Server有时会生成并放入一个错误的查询计划。 –

+0

@Frédéric然而,MS建议将此设置设为ON(https://msdn.microsoft.com/en-us/library/ms190306.aspx)。所以,我认为做我所做的事并不是一件坏事。此外,查询中还包含全文搜索查询,并且大部分全文索引在数据库中都占用了70%以上的碎片(这就是运行没有DBA的系统时发生的情况......)。同样的查询,没有全文搜索部分,运行速度很快,所以我猜F.T.S.是什么造成了差异。我们的非全文搜索索引可能需要调整,但我不认为它们是这里的原因。 :) – user2173353

+0

把它放在'on'上并不是一件坏事,但是相信它实际上完全解决了你遇到的麻烦可能是一件坏事。见[这里](/ a/10175455/1178314)。在我遇到的所有情况中,实际的麻烦始终是索引问题,而不仅仅是“ARITHABORT”设置。 –