Microsoft sql native client ошибка связи hresult 80004005

Я думаю каждый хоть раз, но сталкивался с ошибкой 1С Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 10.0: Неопознанная ошибка HRESULT=80004005

Вот некоторые способы, которые помогут решить данную проблему:

1. Проверить конфигурацию на наличие некорректной информации (мусора). Для этого следует выполнить команду “Проверка конфигурации” с установленным флажком “Проверка логической целостности конфигурации”. При выявлении проблем будет выдано сообщение. Некорректная информация при этом будет удалена автоматически, однако следует обеспечить доступность для изменения корневого объекта конфигурации (напимер, при работе с хранилищем его следует захватить).

2. Если Ваша конфигурация находится на поддержке, следует подобным образом проверить конфигурацию поставщика. Для этого в настройке поддержки следует сохранить конфигурацию поставщика в cf файл, загрузить его в новую базу и выполнить описанную в пункте 1 процедуру. В случае, если было получено сообщение об исправлении, значит конфигурация поставщика содержит некорректную информацию. В этом случае следует снять Вашу конфигурацию с поддержки и заново поставить путем объединения со свежим релизом конфигурации поставщика. В настоящее время все релизы выпускаемые 1С проходят проверку и выпускаются без данной проблемы.

3. Также с этой ситуацией пересекается следующая ситуация:
10007066 Запись данных, содержащих колонки типа ХранилищеЗначения
Проблема:
При использовании СУБД MS SQL SERVER при записи объекта базы данных, содержащего несколько колонок типа ХранилищеЗначения, данные для которых получены из файлов, может происходить ошибка
Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT=80004005и аварийное завершение работы программы.

Включив технологический журнал на время загрузки, можно определить таблицу, в которой содержатся такие хранилища. Найдите средствами MS SQL Server Query Analizer в этой таблице колонки типа image. Для каждой колонки типа image выполните запрос вида:

S_elect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc

Нюансы: обратите внимание, что ”Стандартные проверки” платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.

Суть проблемы: важно, что под это сообщение об ошибке могут подпадать разные причины, но у них есть общая часть для 1С – это не достаточно оперативной памяти. А еще точнее неэффектиное использование ресурсов памяти. Отсюда косвенные способы победить проблему: путем рестарта сервера (на некотрое время становиться больше доступной памяти) или перейти на 64-разрядный сервер приложений.

1С:Предприятие 8.2. Лицензия на сервер (x86-64)

По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.

Обобщенные рекомендации, если рекомендации от 1С не помогли (проделать следующие действия в указанном порядке):

1. Выключить все фоновый задачи у всех баз
В 8.1.11 появился переключатель “запрет на фоновые задания” в
момент создания базы.

Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском – вещь в себе – и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять – возможно проблема “уйдет”.

2. Перезапустить сервер
Второй шаг является частным случаем для вашего случая и после него тоже
есть смысл проверять работоспособность. Однако поскольку существуют утечки памяти http://www.gilev.ru/1c/memleak, то через некоторое время после рестарта пролема может вернуться.

3) делаем бэкап средствами sql
Делать резервное копирование рекомендую при любых действиях, когда может потребоваться “возврат” к предыдущему состоянию данных

4) снимаем базу с поддержки, выгружаем cf
убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение) убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение)

вот пример работоспособности этого приема
http://partners.v8.1c.ru/forum/thread.jsp?id=543293

или

1. Открыть конфигратор;
2. Снял конфигурацию с поддержки, ПРИ ЭТОМ КОНФИГУРАЦИЮ НЕ СОХРАНЯЛ!
3. Далее Сохранить конфигурацию в файл (не сохраняя измененной конфигурации);
4. В SQL для требуемой базы выполнил следующую команду:
DELETE FROM dbo.Config WHERE DataSize > 125829120
5. Загрузить сохраненную конфигурацию обратно.

Взято с http://www.forum.mista.ru/topic.php?id=465608

можно попробовать и более радикальный шаг здесь:
удаляем (в менеджмент консоли) в базе данных таблицу “config”
D_rop TABLE [dbo].[Config]

5) делаем “загрузить конфигурацию” (не объединение) из cf
после этого проверяем, проблема уходит.

6) Ошибка :»Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005″

Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)

Решение в моем случае:
Виндовс по-умолчанию 2Гб берет себе, а 2 отдает нам. SQL почти всю остальную память поедал (в настройках стоит 2Gb) и оставлял для всех остальных только 128Мб физ. памяти(как и положено SQL- он не должен забирать ВСЁ, должен 128 оставить). Ошибка 1С начала проявляться после перехода на релиз 1.2.21.1. Да, действительно, в релизе 1.2.19.1 в файле dbo.Config не было записей больше 120Мб. А вот после обновления на 1.2.21.1 такая запись (примерно 135мб )появляется. При снятии с поддержки запись исчезает сама, и ничего удалять не приходится. При постановке на поддержку -снова появляется… Я так понял, что это и есть конфигурация поставщика.
Если SQL оставляет всего 128, а надо целых 135, то вывод- надо дать рабочим процессам живую физическую память. Moжно урезать SQL. А можно винды. Установив в boot.ini ключ /3GB я тем самым отдал виндам 1Gb, а всему остальному 3Gb, а не 2/2 как по умолчанию. После перезагрузки — все ОК.

У Вас есть свое решение!? оставьте его в комментариях)

	Я
Bogshich 10.01.17 — 17:17	Ситуация: при попытке обновить или выгрузить типовую Бухгалтерию появляется ошибка: Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 10.0: Ошибка связи HRESULT=80004005, Прошу заметить, что ОШИБКА СВЯЗИ, а не Неопознанная ошибка. Сервер 8.3.8, обновляемая конфа 3.0.46.16. Сервер 64, 16Гигов, SQL2008R2 Сделал бэкап sql , развернул на другом сервере 1с 8.3.9 Результат тот же. Снимал с поддержки,  записей более 120 мб нет… пытался обновить до разных релизов.  Есть вторая база, но с тем же релизом обновилась без проблем… Сама база в пользовательском режиме работает без проблем, есть бэкапы за месяц, попробовал достать бэкап 10 дневной давности – проблема та же. 15 дневной давности проблемы нет. В этот период ничего не обновлялось, конфа на поддержке. Может, есть мысли? Чего — то я уже и не знаю чего делать…
Ёпрст 1 — 10.01.17 — 17:42	Так делал ? 1.Выгрузить конфу в cf 2.Удаляем (в менежмент консоли) в базе данных таблицу «config» DROP TABLE [dbo].[Config] 3. «загрузить конфигурацию» (не объединение) из cf
shuhard 2 — 10.01.17 — 17:43	(0) мысли очевидные — выгрузить/загрузить через XML,
Ёпрст 3 — 10.01.17 — 17:44	ну и всякие статьи почитать, типа этой https://helpf.pro/faq/view/1503.html
shuhard 4 — 10.01.17 — 17:47	(3) первоисточник, который ТС явно уже читал http://www.gilev.ru/err80004005/
Ёпрст 5 — 10.01.17 — 17:51	(4) читатьто, мот и читал, но не делал
shuhard 6 — 10.01.17 — 17:53	(5)[Снимал с поддержки,  записей более 120 мб нет] Гилев сделан
Ёпрст 7 — 10.01.17 — 17:55	(6) ну, можно было бы и дропнуть целиком конфиг
Bogshich 8 — 10.01.17 — 19:08	(1) Вот тут у меня не получилось… Снимаю с поддержки, выгружаю сф, выполняю DROP TABLE [dbo].[Config] , тут же делаю загрузить сф из файла, выдает ошибку:  Ошибка СУБД недопустимое имя config…

TurboConf — расширение возможностей Конфигуратора 1С

Проблемы

Предположим, что вы используете SQL Server 2017 и у вас есть много пакетов SQL Server Integration Services (SSIS). Вы можете заметить, что отчеты служб SSIS или Power BI нерегулярно завершались сбоем со следующими ошибками времени ожидания подключения:

«_Main_XXXXX:Error: код ошибки служб SSIS DTS_E_OLEDBERROR. Произошла ошибка OLE DB. Код ошибки: 0x80004005».

Доступна запись OLE DB. Источник: «Microsoft SQL Server Native Client 11.0» Hresult: 0x80004005 Description: «Истекло время ожидания входа».

Доступна запись OLE DB. Источник: «Microsoft SQL Server Native Client 11.0» Hresult: 0x80004005 Description: «Unable to complete login process due to delay in login response».

Доступна запись OLE DB. Источник: «Microsoft SQL Server Native Client 11.0» Hresult: 0x80004005 Description: «TCP Provider: Timeout error [258]. «.»

В противном случае проблема не ограничивается службами SSIS или Power BI отчетов. Любое приложение может привести к ошибкам производительности и времени ожидания при подключении к SQL Server. 

Это исправление содержит два новых столбца : error_code и op_history в sys.dm_os_buffer_descriptors динамического административного представления . Error_code столбец представляет сведения об ошибке во время последней попытки заполнить указанный буфер. Op_history представляет операционный журнал буфера в битовом формате (4 бита на операцию, всего 16 операций, последние 4 бита представляют последнюю операцию и сдвиг влево по мере хода выполнения). 

Примечание. Это исправление не устраняет конкретные ошибки, которые вы видите при заполнении страниц буфера. Он предоставляет сведения только о кодах ошибок и операциях с буферами, чтобы можно было выполнять дополнительные действия по устранению неполадок с новыми сведениями. 

Причину

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

Статус

Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе «Применяется к».

Решение

Эта проблема устранена в следующем накопительном обновлении для SQL Server:

• Накопительный пакет обновления 15 для SQL Server 2017 г.

Сведения о накопительных обновлениях для SQL Server:

Каждое новое накопительное обновление для SQL Server содержит все исправления и все исправления безопасности, которые были включены в предыдущее накопительное обновление. Ознакомьтесь с последними накопительными обновлениями для SQL Server:

• Последнее накопительное обновление для SQL Server 2017 г.

Ссылки

Сведения о терминологии, используемой корпорацией Майкрософт для описания обновлений программного обеспечения.

На ИТС часто даются описания кодов ошибок, но они не всегда исчерпывающие. В этой статье мы будем пытаться продолжать «исчерпывать» 🙂

При эсклуатации баз данных 1С вы можете сталкнуться с такой ситуацией:

Сеанс работы завершен администратором.
по причине:
Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005

Признаки проблемы: нельзя выгрузить в dt

Внимание! Ошибок с кодом 80004005 уйма, более подробно классофикацию я описал здесь http://www.gilev.ru/1c/mssql/errsql.htm . Здесь же мы говорим именно о «неопознанной ошибке» 🙂

Сотрудники 1С рекомендуют решать проблему так:

1. Проверить конфигурацию на наличие некорректной информации (мусора). Для этого следует выполнить команду «Проверка конфигурации» с установленным флажком «Проверка логической целостности конфигурации». При выявлении проблем будет выдано сообщение. Некорректная информация при этом будет удалена автоматически, однако следует обеспечить доступность для изменения корневого объекта конфигурации (напимер, при работе с хранилищем его следует захватить).

2. Если Ваша конфигурация находится на поддержке, следует подобным образом проверить конфигурацию поставщика. Для этого в настройке поддержки следует сохранить конфигурацию поставщика в cf файл, загрузить его в новую базу и выполнить описанную в пункте 1 процедуру. В случае, если было получено сообщение об исправлении, значит конфигурация поставщика содержит некорректную информацию. В этом случае следует снять Вашу конфигурацию с поддержки и заново поставить путем объединения со свежим релизом конфигурации поставщика. В настоящее время все релизы выпускаемые 1С проходят проверку и выпускаются без данной проблемы.

3. Также с этой ситуацией пересекается следующая ситуация:

10007066 Запись данных, содержащих колонки типа ХранилищеЗначения
Проблема:
При использовании СУБД MS SQL SERVER при записи объекта базы данных, содержащего несколько колонок типа ХранилищеЗначения, данные для которых получены из файлов, может происходить ошибка
Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT=80004005и аварийное завершение работы программы.
Дата публикации: 2008-11-13

Включив технологический журнал на время загрузки, можно определить таблицу, в которой содержатся такие хранилища. Найдите средствами MS SQL Server Query Analizer в этой таблице колонки типа image. Для каждой колонки типа image выполните запрос вида:

select top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc

 
Нюансы: обратите внимание, что «Стандартные проверки» платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.

Суть проблемы: важно, что под это сообщение об ошибке могут подпадать разные причины, но у них есть общая часть для 1С — это не достаточно оперативной памяти. А еще точнее неэффектиное использование ресурсов памяти. Отсюда косвенные способы победить проблему: путем рестарта сервера (на некотрое время становиться больше доступной памяти) или перейти на 64-разрядный сервер приложений.

1С:Предприятие 8.2. Лицензия на сервер (x86-64)

По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.

Обобщенные рекомендации, если рекомендации от 1С не помогли (проделать следующие действия в указанном порядке):
1. Выключить все фоновый задачи у всех баз

В 8.1.11 появился переключатель «запрет на фоновые задания» в
момент создания базы.

Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском — вещь в себе — и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять — возможно проблема «уйдет».
2. Перезапустить сервер

Второй шаг является частным случаем для вашего случая и после него тоже
есть смысл проверять работоспособность. Однако поскольку существуют утечки памяти http://www.gilev.ru/1c/memleak, то через некоторое время после рестарта пролема может вернуться.
3) делаем бэкап средствами sql

Делать резервное копирование рекомендую при любых действиях, когда может потребоваться «возврат» к предыдущему состоянию данных

4) снимаем базу с поддержки, выгружаем cf

убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем «загрузить конфигурацию» (не объединение) убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем «загрузить конфигурацию» (не объединение)

вот пример работоспособности этого приема

http://partners.v8.1c.ru/forum/thread.jsp?id=543293

или

1. Открыть конфигратор;
2. Снял конфигурацию с поддержки, ПРИ ЭТОМ КОНФИГУРАЦИЮ НЕ СОХРАНЯЛ!
3. Далее Сохранить конфигурацию в файл (не сохраняя измененной конфигурации);
4. В SQL для требуемой базы выполнил следующую команду:
DELETE FROM dbo.Config WHERE DataSize > 125829120
5. Загрузить сохраненную конфигурацию обратно.

Взято с http://www.forum.mista.ru/topic.php?id=465608

можно попробывать и более радикальный шаг здесь:
удаляем (в менежмент консоли) в базе данных таблицу «config»

DROP TABLE [dbo].[Config]
5) делаем «загрузить конфигурацию» (не объединение) из cf

после этого проверяем, проблема уходит.