I am getting intermittent SQL Server 7886 errors (Severity 20 State 2) in the SQL Server log for the SharePoint_Config database when I run a full farm backup in SharePoint 2013. SharePoint does not report any errors during these backups. In the
SQL Server log each database backup completes successfully. The servers in this farm are running Windows 2012 R2, SharePoint 2013 SP1 and SQL Server 2012 SP1 CU6.
I am also seeing these errors on another farm with running Windows Server 2012, SharePoint 2013 and SQL Server 2012 SP1 CU6. I applied SharePoint 2013 SP1 to the servers and this farm and I still receive the 7886 error.
I have another farm running SharePoint 2010, SQL Server 2008 R2 and Windows 2012 that backs up without any errors.
I followed the action plan from this link without any success:
http://sqlactions.com/2013/05/06/a-read-operation-on-a-large-object-failed-while-sending-data-to-the-client/
The SQL Server log only reports the 7886 error. However, when I run SQL Server profiler while the backup is running, the 7886 error is always preceded by a 601 error (Could not continue scan with NOLOCK due to data movement).
Has anyone else seen this error?
I am getting intermittent SQL Server 7886 errors (Severity 20 State 2) in the SQL Server log for the SharePoint_Config database when I run a full farm backup in SharePoint 2013. SharePoint does not report any errors during these backups. In the
SQL Server log each database backup completes successfully. The servers in this farm are running Windows 2012 R2, SharePoint 2013 SP1 and SQL Server 2012 SP1 CU6.
I am also seeing these errors on another farm with running Windows Server 2012, SharePoint 2013 and SQL Server 2012 SP1 CU6. I applied SharePoint 2013 SP1 to the servers and this farm and I still receive the 7886 error.
I have another farm running SharePoint 2010, SQL Server 2008 R2 and Windows 2012 that backs up without any errors.
I followed the action plan from this link without any success:
http://sqlactions.com/2013/05/06/a-read-operation-on-a-large-object-failed-while-sending-data-to-the-client/
The SQL Server log only reports the 7886 error. However, when I run SQL Server profiler while the backup is running, the 7886 error is always preceded by a 601 error (Could not continue scan with NOLOCK due to data movement).
Has anyone else seen this error?
- Remove From My Forums
-
Question
-
This Error 7886 has happened twice since last Saturday. Here is the full description of it:
«A read operation on a large object failed while sending data to the client. A common cause for this is if the application is running in READ UNCOMMITTED isolation level. This connection will be terminated.»
This is a Win 2008 server and SQL Server 2008 SP3. We do have BLOBs and use READ UNCOMMITTED isolation level but never got this error before.
I was wondering if anyone knows how to identity which call is causing this error.
Answers
-
I would guess that if you run a profiler script logging batch or statement start, exceptions and errors, you can nail it. Of course filter this as best you can, and log it to local disk files on the server to minimize overhead. You probably know
which app or login is creating it, for starters, and can probably filter by table name or field name as well.Whether you can get it from dmv’s after the fact without profiler, I don’t know.
Josh
ps — any chance it leaves any info in the server log?
-
Edited by
Thursday, August 16, 2012 7:51 PM
-
Marked as answer by
amber zhang
Thursday, August 23, 2012 6:40 AM -
Unmarked as answer by
psneto
Wednesday, September 5, 2012 10:41 PM -
Marked as answer by
psneto
Wednesday, September 5, 2012 10:51 PM
-
Edited by
-
-
Marked as answer by
amber zhang
Thursday, August 23, 2012 6:40 AM
-
Marked as answer by
- Remove From My Forums
-
Question
-
when running the SharePoint 2013 farm backup there is an error 7886 severity 20 state 2 in the sql server log (a read operation on a large object failed while sending data to the client. a common cause for this is if the application is running in read
committed isolation level, the connection will be terminated) . Farm consists of one WFE and one SQL only. not sure which database it relates to though. Noticed that after the backup the sharepoint synchronization service does not restart, remains off. next
time when the backup runs the synchronization service starts up and so on , one backup turns it off than second one turns it on. was wondering the terminated connection is the reason for the synchronization stoppage.how should I fix this error 7886?
- Remove From My Forums
-
Question
-
when running the SharePoint 2013 farm backup there is an error 7886 severity 20 state 2 in the sql server log (a read operation on a large object failed while sending data to the client. a common cause for this is if the application is running in read
committed isolation level, the connection will be terminated) . Farm consists of one WFE and one SQL only. not sure which database it relates to though. Noticed that after the backup the sharepoint synchronization service does not restart, remains off. next
time when the backup runs the synchronization service starts up and so on , one backup turns it off than second one turns it on. was wondering the terminated connection is the reason for the synchronization stoppage.how should I fix this error 7886?
January 12, 2009 at 3:04 am
#195856
Hi all,
Last night my SQL box (2005 Std) reported the following error, this occured at just after 18:00
«Message
A read operation on a large object failed while sending data to the client. A common cause for this is if the application is running in READ UNCOMMITTED isolation level. This connection will be terminated.»
Then at 19:00, my hourly transaction logs backups ran (for 7 seconds), then the SQL box became unresponsive and required a restart at around 19:15.
I cant find any indication as to why it became unresponsive (sql logs, event viewer) and judging by the fact that it occured so long after the error message that would indicate that the two are unreleated.
I was wondering if anyone had come across this error before and if so, had it caused any performance issue which could cause the box to become unresponsive.
Thanks,
Jackal
Gail Shaw
SSC Guru
Points: 1004494
January 12, 2009 at 8:48 am
#925322
Anything in the SQL error log?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass
NicHopper
SSCrazy Eights
Points: 9081
January 12, 2009 at 9:17 am
#925346
Hi Gail,
Thanks for the response, the SQL logs show the error occuring at 6.01pm, then transaction log backups at 7.00pm and then the actions involved with restarting SQL. Other than that nothing of any use what so ever.
Thanks,
Jackal
Gail Shaw
SSC Guru
Points: 1004494
January 12, 2009 at 9:26 am
#925353
Jackal (1/12/2009)
Thanks for the response, the SQL logs show the error occuring at 6.01pm
Can you post the full message that was in the log?
Anything in the windows event logs?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass
eng_mgomaa
Right there with Babe
Points: 736
January 13, 2009 at 10:39 pm
#926379
I had the same error, but didn’t know the reason, it appeared three or four times and then disappeared completly, if someone has analysis for this event please confirm us
Johan Bijnens
SSC Guru
Points: 135002
January 14, 2009 at 12:07 am
#926396
If you cannot fine any reasonable / related message in sqlservers errorlog,
I would suggest to at least run DBCC CheckDB (for the db if you know it, if you don’t for all dbs)
NicHopper
SSCrazy Eights
Points: 9081
January 14, 2009 at 2:33 am
#926429
It’s certainly a strange one.
I cant find anything in either the SQL logs or the Windows logs. I’ll shortly be posting the logs up so hopefully someone maybe able to spot something.
Hadrian
Hall of Fame
Points: 3742
January 14, 2009 at 3:00 am
#926436
Hadrian
Hall of Fame
Points: 3742
January 14, 2009 at 3:11 am
#926440
check if you are using large objects,LOB and try to reduce the level of locking checking for indexes,denormalize the table.
NicHopper
SSCrazy Eights
Points: 9081
January 14, 2009 at 3:34 am
#926446
The table that I beleive is causing this issue has a TEXT column in it.
It’s a bit of an open ended question but what exactly is happening when this error is occuring, is it just a case of SQL not being be able to confirm the integrity of the data and then killing the connection for data integrity purposes?
Johan Bijnens
SSC Guru
Points: 135002
January 14, 2009 at 3:39 am
#926448
Could you also post your version number of SQL2005 ?
Select @@version
-- or
Select Serverproperty( 'ProductVersion' ) as ProductVersion
, Serverproperty( 'ProductLevel' ) as ProductLevel
, Serverproperty( 'ResourceLastUpdateDateTime' ) as ResourceLastUpdateDateTime
, Serverproperty( 'ResourceVersion' ) as ResourceVersion
NicHopper
SSCrazy Eights
Points: 9081
January 14, 2009 at 3:42 am
#926451
Sorry, should of done that in the original post.
The version number is 9.00.3042.00 (SP2) — none of the cumlitive updates have been applied to this.
Ignacio A. Salom Rangel
SSC-Insane
Points: 20443
did you find out what was causing the error?
NicHopper
SSCrazy Eights
Points: 9081
Ignacio A. Salom Rangel (10/22/2009)
did you find out what was causing the error?
Hi,
Sorry for not getting back to you sooner. I dont know how much help I can be on this one, basically I tracked it down to be related to a TEXT column on one of the older tables that had several million records.
We dont have the issue any longer and beleive this to be down to 3 things;
1. We moved to SP3 (always a good thing — circumstances permitting)
2. We reduced the amount of data in the table via archiving to ease the load up a bit.
3. We re-evalulated and made changes to our procedures which are using the column, the goal is for us to eventually remove the columnn and replace it with a better solution, but thats a while off.
Hope this helps, if you need anymore help then let me know.
Ignacio A. Salom Rangel
SSC-Insane
Points: 20443
Thank you for answering. I got the error only once. I was not able to find what was causing the error. I check all the databases on that server, but everything was fine. I don’t know what else to do, any tips are welcome.
MSSQL Как исправить ошибку Ошибка MSSQL Сохранение изменений запрещено.
У меня в журнале есть ошибка в течение нескольких недель, я много искал, но не нашел полезного ответа.
Я закрыл порт SQL Server для общедоступного IP-адреса, но у меня пока есть проблема.
Ошибка: 17806, уровень серьезности: 20, состояние: 14. Сбой установления связи SSPI с кодом ошибки 0x8009030c, состояние 14 при установлении соединения со встроенной безопасностью; соединение было закрыто. Причина: сбой AcceptSecurityContext. Код ошибки Windows указывает причину сбоя. Попытка входа не удалась [КЛИЕНТ: 10.10.3.25]
Время поднят: 27 января 2015 г., 14:23
При выключенной системе возникла ошибка.
- вы пробовали это allenkinsel.com/archive/2010/06/… ???
Сценарий — Несколько отдельных идентификаторов Windows начали генерировать эти ошибки при попытке подключения, все остальные входы в Windows работали правильно. Изначально соединения выполнялись через приложения, но также выполнялись через sqlcmd. При локальном входе на сервер с ошибочным идентификатором подключения к SQL будут успешными.
Процесс устранения неполадок — проверьте все обычные проблемы SSPI, я не буду утомлять вас подробностями, поскольку они легко доступны для поиска
Относительно простой способ проверки «простых» проблем с аутентификацией. Если это возможно / целесообразно, это войти в SQL Server локально с ошибочным идентификатором, запустить sqlcmd и подключиться к серверу через sqlcmd –Sservername, port –E (указав порт вы используете TCP / IP вместо LPC, тем самым заставляя сеть участвовать в уравнении). Проверьте, пытается ли логин использовать NTLM или Kerberos (есть много способов сделать это, но самый простой — проверить, есть ли на машине какие-либо другие подключения KERBEROS)
SELECT DISTINCT auth_scheme FROM sys.dm_exec_connections Если используется Kerberos, необходимо проверить еще несколько вещей, связанных с SPN, поскольку на этом сервере использовался только NTLM, который я пропустил. Определение того, были ли учетные записи исключены из подключения к машине через сеть через групповую политику или некоторые другие другие настройки AD
После того, как все это подтвердилось, я начал пытаться выяснить, что означает код ошибки 0x8009030c, оказывается, довольно очевидно, что это за описание: sec_e_logon_denied. Это описание было настолько полезным, что я подумал о том, чтобы превратить этот сервер в якорь для лодки, но, к счастью для моего работодателя, серверная комната находится за много миль отсюда и имеет вооруженную охрану.
Так как я знал, что мы можем войти в систему локально на SQL Server с идентификатором, который SQL отклонял с отклонением входа в систему, что-то еще пыталось сделать мою жизнь несчастной.
У нас не был включен аудит безопасности сбоев входа в систему, поэтому у меня не было возможности получить более подробное описание ошибки, как назло, хотя это поможет найти основную причину. Чтобы получить более точное сообщение об ошибке, я нашел эту удобную статью в базе знаний, в которой подробно описаны шаги, необходимые для перевода сетевого входа в режим отладки.
Передай привет моему новому лучшему другу! — nltest.exe После загрузки nltest и использования его для включения отладки netlogon на SQL Server я получил это немного лучшее сообщение в файле netlogon.log
06/15 14:15:39 [LOGON] SamLogon: Network logon of DOMAINUSER from Laptop Entered 06/15 14:15:39 [CRITICAL] NlPrintRpcDebug: Couldn’t get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc0000064) 06/15 14:15:39 [LOGON] SamLogon: Network logon of DOMAINUSER from Laptop Returns 0xC0000064 The error code 0XC0000064 maps to “NO_SUCH_USER” Since I was currently logged in to the server with the ID that was returning no such user, something else was obviously wrong, and luckily at this point I knew it wasn’t SQL. Running “set log” on the server revealed that a local DC (call it DC1) was servicing the local logon request. After asking our AD guys about DC1 and its synchronization status, as well as whether the user actually existed there, everything still looked OK. After looking around a bit more I discovered this gem of a command for nltest to determine which DC will handle a logon request C:>nltest /whowill:Domain Account [16:32:45] Mail message 0 sent successfully (MAILSLOTNETGETDC579) [16:32:45] Response 0: DC2 D:Domain A:Account (Act found) The command completed successfully Even though this command returned “act found” it was returning from DC2. (I dont exactly understand why the same account would authenticate against 2 different DC’s based on a local desktop login or a SQL login but it apparently can) После того, как ребята из AD спросили о DC2, у них, по-видимому, погасли лампочки, поскольку этот сервер фактически существует за другим набором межсетевых экранов, в совершенно другом месте. Хотя DC2 возвращал пинг, консоль по какой-то причине не позволяла входить в систему. После быстрой перезагрузки DC2 и некоторой волшебной пыли AD pixie (я не администратор AD, если это не было полностью очевидно из моего новообретенного друга nltest), идентификаторы Windows, у которых возникли проблемы, начали аутентификацию на DC3, и наши ошибки SSPI исчезли. прочь.
Интересный лакомый кусочек: во время устранения неполадок я обнаружил, что этот конкретный SQL-сервер аутентифицировал учетные записи по крайней мере в 5 различных DC. Отчасти этого можно было ожидать, поскольку в игре задействованы разные домены, но я не слышал окончательного ответа от ребят из AD о том, должно ли это работать таким образом.
The solution Перезагрузите некорректно функционирующий контроллер домена, конечно, могут быть другие способы исправить это, перенаправив запросы на другой контроллер домена без перезагрузки, но, поскольку он в любом случае плохо себя ведет, и эксперты AD хотели перезагрузить, поэтому мы пошли с этим. Перезагрузка SQL, вероятно, решила бы и эту проблему, но я ненавижу исправления проблем с перезагрузкой, они всегда возвращаются!
Справка
Tweet
Share
Link
Plus
Send
Send
Pin
Длина, указанная в полезных данных сетевого пакета, не соответствует количеству прочитанных байтов; соединение было закрыто. Обратитесь к поставщику клиентской библиотеки. Ошибка: 17836, уровень серьезности: 20, состояние: 14. Я получаю эту ошибку 5 раз одновременно почти и хочу узнать причину ее возникновения.
2 ответа
Лучший ответ
См. Решение здесь:
Поскольку на сервере SQL зарегистрировано событие с кодом 17836, порт SQL открыт. Это больше похоже на проблему аутентификации. На основе этой статьи (Конфигурация для удаленного запроса базы данных SQL — http://www.howtonetworking.com/others/testsqlconnect2.htm), мы можем есть 3 исправления:
- создание идентификатора входа в систему SQL (рекомендуется)
- присоединить компьютер к домену
- разрешить анонимные подключения к SQL Server 2000 или SQL Server 2005 (не рекомендую)
И это Форум MSDN
Выполните nslookup IP-адреса КЛИЕНТА, указанного в сообщении об ошибке, и выясните, какой компьютер подключается. Затем вам нужно проверить эту машину и определить, что конкретно подключается к SQL Server. Вы можете получить больше информации, выполнив трассировку SQL для класса событий ошибок и предупреждений и получив столбец ClientProcessID в данных трассировки. Когда ошибка увеличивается, вы можете получить PID для процесса, который подключается с этого компьютера 10.26.32.96, а затем вы можете найти этот процесс в диспетчере задач на этом компьютере, добавив PID к отображаемым данным (View -> Select Columns ).
2
Rahul Tripathi
15 Апр 2016 в 07:24
В моем случае эти события совпали с тем, что я проводил тесты подключения telnet к нашим SQL-серверам. Мы увидим по одной записи в журнале событий Windows для каждого экземпляра, с которым мы успешно выполнили telnet.
0
Mike
25 Апр 2018 в 04:03