2016-05-12 2 views
0

нашей производственной среды, которая использует NHibernate v3.1.0.4000 вдруг начал давать эту ошибку при поиске с полнотекстовым поиском:NHibernate - «GenericADOException: не удалось выполнить запрос»

[SqlException (0x80131904) : Время ожидания истекло. Период ожидания истекает до завершения операции или сервер не отвечает.] System.Data.SqlClient.SqlConnection.OnError (исключение SqlException, логическое разломы) +404 System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning() + 412 System.Data.SqlClient.TdsParser.Run (runBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader DATASTREAM, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) +1363 System.Data.SqlClient.SqlDataReader.ConsumeMetaData() +59 System.Data.SqlClient. SqlDataReader.get_MetaData() +118 System.Data.SqlClient.SqlCommand.FinishExecuteReader (SqlDataReader Д.С., runBehavior runBehavior, String resetOptionsString) +6388257 System.Data.SqlClient.SqlCommand.RunExecuteReaderTds (CommandBehavior cmdBeh Avior, RunBehavior runBehavior, булева returnStream, булева асинхронный) +6389826 System.Data.SqlClient.SqlCommand.RunExecuteReader (CommandBehavior cmdBehavior, RunBehavior runBehavior, булева returnStream, метод String, DbAsyncResult результат) +538 System.Data.SqlClient.SqlCommand. RunExecuteReader (CommandBehavior cmdBehavior, runBehavior runBehavior, булева returnStream, метод String) +28 System.Data.SqlClient.SqlCommand.ExecuteReader (поведение CommandBehavior, метод String) +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 ул, булева 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_ ОТ Document.Document this_ внутреннее соединение Document.DocumentCopy documentc1_ on this_.IdDocument = documentc1_.IdDocument WHERE ((@ p0 = @ p1 и содержит (this_.Title, @ p2)) и this_.IsDe leted = @ p3) и (((@ p4 = @ p5 и documentc1_.CreationDate> = @ p6) и documentc1_.CreationDate < = @ p7) и (documentc1_.IdOwnedByGroup = @ p8 или documentc1_.IdCreatedByGroup = @ p9))] Позиционные параметры: # 0> 0 # 1> 0 # 2> "ýÿýÿýÿýÿýÿýÿýÿýÿ *" # 3> False # 4> 0 # 5> 0 # 6> 12/5/2015 12:00:00 ýÿýÿ # 7> 12/5/2016 11:59:00 ýÿýÿ # 8> 1 # 9> 1 [SQL: SELECT count (отличается this_.IdDocument) как y0_ FROM Document.Document this_ internal 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, QueryParameters queryParame Ослабляет) +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, String ActionName) +827248 системы .Web.Mvc.Controller.ExecuteCore() +159 System.Web.Mvc.ControllerBase.Execute (RequestContext requestContext) +335 System.Web.M ВУ. <> 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 сообщает о другой ошибке. Таким образом, я предполагаю, что это тайм-аут после того, как все ...

UPDATE 2:

После некоторых дополнительных исследований, по-видимому, это связано с этим вопросом, и запрос действительно таймаут, просто не от SSMS:

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

+0

В Datails говорит, Timeout вопрос. – Najera

+0

Сколько данных вы возвращаете? как выглядит код, который делает это? вы используете прогнозы? – Fran

+0

@Najera Если вы посмотрите ниже этого первого исключения, есть еще одно исключение, которое кажется внутренним исключением. – user2173353

ответ

-1

это оказался тайм-аут, который не может быть воспроизведен из SSMS, потому что он использует другое значение для ARITHABORT (между моим приложением сессии и сессии SSMS).

После того, как я установил значение по умолчанию для него, чтобы ON/1 для БД, все было исправлено:

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% фрагментировано в БД (это происходит, когда вы запускаете систему без администратора базы данных ...). Тот же запрос, без полнотекстового поиска, работал быстро, поэтому я думаю, что F.T.S. это то, что сделало разницу. Наши индексы без полнотекстового поиска МОГУТ нуждаться в корректировках, но я не думаю, что они были причиной здесь. :) – user2173353

+0

Иметь «на» не плохо, дано, но полагая, что это на самом деле полностью решает проблемы, с которыми вы столкнулись, вероятно, будет плохо. См. [Здесь] (/ a/10175455/1178314). Во всех случаях, с которыми я столкнулся, фактическая проблема всегда была проблемой индекса, а не только этой установкой «АРИСТАБОРТ». –

Смежные вопросы