Поставщик общей памяти с обоих концов канала отсутствуют процессы 1с
Соединение с сервером было успешно установлено, но при входе в систему произошла ошибка. (поставщик: поставщик общей памяти, ошибка: 0 - на другом конце канала нет процесса.) Описание: необработанное исключение произошло во время выполнения текущего веб-запроса. Просмотрите трассировку стека для получения дополнительных сведений об ошибке и ее происхождении в коде.
Сведения об исключении: System.Data.SqlClient.SqlException: соединение с сервером было успешно установлено, но затем в процессе входа в систему произошла ошибка. (поставщик: поставщик общей памяти, ошибка: 0 - на другом конце канала нет процесса.)
Ошибка источника:
Во время выполнения текущего веб-запроса возникло необработанное исключение. Информацию о происхождении и местонахождении исключения можно определить с помощью трассировки стека исключений ниже.
Трассировки стека:
[SqlException (0x80131904): соединение было успешно установлено. с сервером, но затем во время входа в систему произошла ошибка. (поставщик: поставщик общей памяти, ошибка: 0 - на другой конец трубы.)]
System.Data.ProviderBase.DbConnectionPool.GetConnection (DbConnection owningObject) +1019
System.Data.ProviderBase.DbConnectionFactory.GetConnection (DbConnection owningConnection) +108
System.Data.ProviderBase.DbConnectionClosed.OpenConnection (DbConnection externalConnection, DbConnectionFactory connectionFactory) +126
System.Data.SqlClient.SqlConnection.Open () +125
NHibernate.Connection.DriverConnectionProvider.GetConnection () +104
NHibernate.Tool.hbm2ddl.SuppliedConnectionProviderConnectionHelper.Prepare () +15 NHibernate.Tool.hbm2ddl.SchemaMetadataUpdater.GetReservedWords (диалект диалект, IConnectionHelper connectionHelper) +89
NHibernate.Tool.hbm2ddl.SchemaMetadataUpdater.Update (ISessionFactory sessionFactory) +80
NHibernate.Impl.SessionFactoryImpl..ctor (Конфигурация cfg, IMapping отображение, настройки параметров, слушатели EventListeners) +599
NHibernate.Cfg.Configuration.BuildSessionFactory () +104
MyProject.API.Data.SessionManager..cctor () в C: \ Dev \ Code \ API \ Data \ SessionManager.cs: 27
22 ответа
Обычно для устранения этой проблемы вы переходите в диспетчер конфигурации SQL Server (SSCM) и:
- убедитесь, что протокол общей памяти включен
- убедитесь, что протокол именованных каналов включен
- убедитесь, что TCP / IP включен и опережает именованные каналы в настройках
Примечание. Если это новый экземпляр SQL Server, убедитесь, что SQL Server и проверка подлинности Windows включены.
- Щелкните правой кнопкой мыши сервер в SSMS и откройте свойства сервера.
- Перейдите в раздел «Безопасность» -> выберите «Режим проверки подлинности SQL Server и Windows».
- Перезагрузите сервер и войдите с учетными данными
У меня такая же проблема. Я попробовал все предложенные ответы на этой странице, но безрезультатно! Наконец, я попробовал следующие шаги, и у меня это сработало:
В обозревателе объектов SQL Server Management Studio щелкните сервер правой кнопкой мыши и выберите команду Свойства.
- На странице «Безопасность» в разделе «Проверка подлинности сервера» выберите новый режим проверки подлинности сервера и нажмите кнопку «ОК».
- В диалоговом окне SQL Server Management Studio нажмите OK, чтобы подтвердить требование перезапуска SQL Server.
- В обозревателе объектов щелкните сервер правой кнопкой мыши и выберите "Перезагрузить". Если агент SQL Server запущен, его также необходимо перезапустить.
Затем попробуйте это в консоли диспетчера пакетов:
Я столкнулся с этим в приложении с первым кодом, которое ожидало, что база данных будет там:
Убедитесь, что база данных создана / имя в строке подключения правильное.
Добавление этого в мою строку подключения сработало для меня:
Я знаю, что я, вероятно, единственный, у кого возникнет эта проблема. но если вы удалили файлы mdf в каталоге C: / /, вы также получите эту ошибку. восстанови это и ты золотой
Это старый, но у меня была проблема в диалоговом окне подключения, что по умолчанию все еще использовалась удаленная мной база данных. И после выполнения этих команд база данных по умолчанию в командной строке не изменилась. Я где-то читал, что сейчас не могу найти, что если вы откроете диалоговое окно «Подключиться к серверу», а затем выберите «Параметры» и выберите вкладку «Свойства подключения», набрав базу данных по умолчанию ( нет , выбрав из раскрывающегося списка) база данных останется на этом новом введенном значении. Для меня это звучит как недостаток, но если кому-то это интересно, это должно решить проблему, по крайней мере, на SQL Server 2012.
Убедитесь, что имя сервера, на который вы входите с помощью SQL Management Studio, соответствует строке подключения.
Сегодня я получал эту ошибку. Оказалось, что я не осознавал, что на машине с установленным SQL Server работает несколько серверов. Фактически я разместил свою базу данных на совершенно другом сервере, нежели тот, который я думал, что использую. (Итак, моя строка подключения указывала на сервер без базы данных)
Я открыл правильный сервер в SQL Management Studio, добавил свою базу данных, и все работало нормально. (Если нужный сервер недоступен в раскрывающемся списке, попробуйте найти его.)
Все хорошие и действительные курсы расследования, особенно журналы для получения дополнительной информации.
Для тех, кто ударил это, это может быть простая ошибка, когда при создании пользователя БД вы, возможно, применили политику паролей и оставили пользователю изменять пароль при первом входе в систему (т.е. оставили флажки вокруг поля пароля с их значениями по умолчанию) .
Это очень легко сделать в SQL Management Studio и, конечно, может сразу вызвать проблемы с аутентификацией, которые замаскированы, если вы не заглянете в журналы.
Привет. Просто включите оба параметра для аутентификации сервера, как показано на скриншоте ниже.
Включите смешанный режим аутентификации при установке сервера MSSQL. Также укажите пароль для пользователя sa.
В моем случае это была орфографическая ошибка в имени базы данных в строке подключения.
Я забыл добавить «Пароль = xxx;» в строке подключения в моем случае.
Сегодня я получал эту ошибку. В моем случае просмотр файла ERRORLOG на SQL-сервере дал мне эту ошибку:
Не удалось войти в систему для пользователя ''. Причина: не удалось открыть базу данных, указанную в свойствах входа.
Это произошло потому, что несколько дней назад я удалил «Базу данных по умолчанию» этого пользователя. Установка базы данных по умолчанию для моей новой базы данных устранила проблему.
Надеюсь, это поможет кому-то другому.
Заглянув в файл журнала SQL SERVER в "C: \ Program Files \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ Log \ ERRORLOG", он говорит «Не удалось войти в систему для пользователя« XXXXX ». Причина: попытка входа с использованием проверки подлинности SQL не удалась. Сервер настроен только для проверки подлинности Windows. [КЛИЕНТ:]»
Найдите полную строку подключения:
"Настоящая" ошибка была в журнале ошибок SQL:
C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\log\ERRORLOG
Путь будет зависеть от вашей версии SQL Server
Перейдите к серверу SQL, используя учетные данные Windows -> Логины -> Выберите логин -> в свойствах -> Проверьте, включен / отключен ли вход. Если Disabled, включите его, это решение сработало для меня.
Вы должны включить режим проверки подлинности сервера в смешанный режим следующим образом: В SQL Studio выберите YourServer -> Property -> Security -> Select SqlServer and Window Authentication mode.
Проверьте, добавлено ли в вашу строку подключения "Trusted_Connection=true" .
У меня была такая же ошибка в SQL Server Management Studio.
Я обнаружил, что, чтобы увидеть более конкретную ошибку, просмотрите файл журнала, созданный SQL Server. Когда я открыл файл журнала, я обнаружил эту ошибку
Не удалось подключиться, поскольку уже достигнуто максимальное количество пользовательских подключений '2'. Системный администратор может использовать процедуру sp_configure для увеличения максимального значения. Соединение было закрыто
Я потратил довольно много времени на то, чтобы понять это. Наконец, запуск следующего кода устранил мою проблему.
Подробнее на здесь и здесь
Редактировать
Чтобы просмотреть журналы, выполните поиск по запросу «журналы» при нажатии кнопки запуска Windows, нажмите «просмотреть журналы событий» . Оттуда перейдите в Приложения в разделе «Журналы Windows». Вы также можете выбрать «Системные» журналы, чтобы увидеть системные ошибки. Вы можете использовать фильтр для текущих журналов, щелкнув «Фильтровать текущие журналы» справа, а затем установить флажок «Ошибка».
Всем привет, базу загрузкил из бэкапа с сервера себе локально на комп, в SQL Express, все ок, добавил базу в сервер 1С - все ок. Но при входе в базу ругается - " Сеанс работы завершен администратором. по причине: Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 11.0: Поставщик общей памяти: С обоих концов канала отсутствуют процессы. В экспрессе не могу найти настройку по общей памяти, только в регистрации нового сервера смог по умолчанию на вкладке "свойства соединения" установить не по умолчанию а ТСП/ИП
Старая знатная проблема. Лечится так, только я не в курсе есть ли в экспрессе такая настройка: network packet size Выкручивай ее до максимума, насколько сам експресс позволяет (если позволяет). В обычной версии это значение 32767.
Если в конфигуратор можешь зайти - удаляй из метаданных все, что много весит - как правило это всякие бинари в макете. Еще можешь попробовать (если в конфигуратор опять же зашел), объединиться с живым cf на x64 ОС. Но лучше и проще, отбекапиться не на экспрессе, и тогда этой проблемы не буедт.
пакет увеличил до 32797, не помогло в конфигуратор не могу попасть, ошибка та же Бэкап был сделан на норм SQL 2008 R2, но эта проблема уже была там. Делали ALTER DATABASE <Имя БД>SET EMERGENCY ALTER DATABASE <Имя БД>SET SINGLE_USER DBCC CHECKDB (<Имя БД>, REPAIR_ALLOW_DATA_LOSS) ALTER DATABASE <Имя БД>SET MULTI_USER не помогло так же.Имя>
=) Так выгрузи в dt, затем подними ее конфигуратором. Скорее всего уже ошибка уйдет. Если нет - ТИИ. Если нет - выгрузи в cd и прогони утилитой - скорее всего ошибка уйдет.
бэкап в sql сделал и пробовал на других серверах ее поднять - тоже самое. Причем на том сервере есть другие базы и они нормально работают. т.е. скорее всего дело не в настройках сервера sql
На изначальном сервере ругается так: Сеанс работы завершен администратором. по причине: Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 11.0: Поставщик TCP: Удаленный хост принудительно разорвал существующее подключение.
Есть какие-то еще инструменты для анализа базы и если надо ее восстановления? не понятно вообще она жива или нет.
Все что смог чектейблом прошел. теперь интересная ошибка - "Файл запрос и ответа на лицензирование конфигурации были удалены из конфигурации" Понять бы где это хранилось, я бы из рабочей базы восстановил.
на нимфостарте утверждают что это лечится сравнениемобъекдинением с типовой этой же версии (или с конфой поставщика).
вот тема про "Файл запрос и ответа на лицензирование конфигурации были удалены из конфигурации" но там в конфигуратор был доступен. видимо пострадали данные о лицензии, где они хранятся -не знаю. поэтому создайте новую бд с с близкой конфой .пройдите валидацию лицензирования через инет. через ТЖ или profile подглядите, каких данных нет. добавьте их из новой бд.
В итоге не исправляемые таблицы пришлось дропать, в конфигуратор попал, сделал дт и выгрузил в файловую. Там уже обработкой собирал данные где есть и пихал где они удалились. вроде пока получается восстановить. Всем спасибо!
При эсклуатации баз данных 1С вы можете сталкнуться с такой ситуацией:
Сеанс работы завершен администратором.
по причине:
Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005
Признаки проблемы: нельзя выгрузить в dt
Внимание! Ошибок с кодом 80004005 уйма, более подробно классофикацию я описал здесь http://www.gilev.ru/1c/mssql/errsql.htm . Здесь же мы говорим именно о "неопознанной ошибке" :)
Сотрудники 1С рекомендуют решать проблему так:
Нюансы: обратите внимание, что "Стандартные проверки" платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.
Также с этой ситуацией пересекается следующая ситуация:
Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском - вещь в себе - и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять - возможно проблема "уйдет".
2. Перезапустить сервер
3) делаем бэкап средствами sql
Делать резервное копирование рекомендую при любых действиях, когда может потребоваться "возврат" к предыдущему состоянию данных
4) снимаем базу с поддержки, выгружаем cf
убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем "загрузить конфигурацию" (не объединение) убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем "загрузить конфигурацию" (не объединение)
вот пример работоспособности этого приема
DROP TABLE [dbo].[Config]
5) делаем "загрузить конфигурацию" (не объединение) из cf
после этого проверяем, проблема уходит.
P.S. Если у Вас есть возможность поделиться своим опытом, то давайте расширим данный материал.
Специальные предложения
Недавно возникла эта проблема
симтомы
1. Любое действие записи вызывает данную ошибку.
2. Не грузятся обмены
3. Невозможно запустить проверку БД и выгрузку
4. Невозможно открыть конфигуратор из-за блокировки информационной базы
Собственно никаких блокировок БД не было, проверялось и в консоли сервера приложений 1с и в консоли SQL сервера
Лечение.
1. делаем бэкап (на всякий пожарный, можно и не делать у кого смешанная модель бэкапа позволяющая восстановить базу на состояние часа назад к примеру )
2. сносим базу с сервера приложений(не трогая БД на SQL сервере)
и заводим её заново (можно наверно и перезагрузить сервер приложений 8.1,
но у меня на нем крутится более 20 баз, которые работали вполне адекватно)
итого починка занимает не более 5 минут(без бэкапа)
хотя вполне возможно у меня был частный случай. но есть у меня подозрение что гребет именно сервер приложений и сама БД тут совершенно ни причем
спасибо, интересный пример
но если не запускалась проверка, то неплохобы было увидеть текст ошибки (собрать можно технологическим), тогда причина станет очевидней
(3) ПОТРЯСАЮЩЕ! А статью вы пробывали читать или ваша рекомендация отличается от приведенных рекомендаций в статье? :) ИЛИ ВЫ ПОТВЕРЖДАЕТЕ ПРАВИЛЬНОСТЬ МЕТОДА? :)
подтверждаю :) опытным путем было получено, что ошибочка вылетает
при некорректном закрытии программы пользователем (во время заполнения книги продаж в типовой бухне, например ) "Ну надоело ждать".
тока все таки лучшее перегрузить, чем сносить, если есть возможность. Был еще такой глюк с такой же ошибкой в итоге, один из пользователей ставил отбор по одному из сотрудников и вылетали все. пытались повторить на других машинах и другими пользователями, хрена. дальше все продолжают успешно работать, кроме как Невозможно запустить проверку БД и выгрузку. перегружаемси, индекируемси - те же грабли.
У нас не выгружались ни cf ни dt. Оказалось, что после некорректного заверешения сервера предприятия остался висеть процесс rphost. Выяснилось это только через неделю (когда увидели что их больше чем надо :)))). Судя по всему старый процесс блокировал запись в таблице config
У меня всегда лечится перезапуском Сервера 1С. Интересно в новой платформе 8.1.13.37 не решили эту проблему?!
Включив технологический журнал на время загрузки, можно определить таблицу, в которой содержатся такие хранилища. Найдите средствами MS SQL Server Query Analizer в этой таблице колонки типа image. Для каждой колонки типа image выполните запрос вида:
sel ect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc
Он позволит узнать максимальные длины хранимых в них данных. Не рекомендуется хранить данные длиннее 100 - 200Mb.
Ошибка :"Соединение с сервером баз данных разорвано администратором
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 как по умолчанию. После перезагрузки - все ОК.
Буду рад, если эти рекомендации помогут кому-нибудь еще :-)
(14) да, в отношении Config, пункты 1 и 2 как раз и позволяют бороться с размером в 1.2.21.1. Спасибо что подтвердили верность инструкции.
описанная проблема полностью описывает траблы с сифилисом который сейчас твориться у меня с базой (бекапы собственные не создаются) попробую данные здесь рекомендации.
Вопрос - а если отключить поддержку, то как ее вернуть? =) как не странно помогло (проверил на демо базе =)))
Возникла ошибка "Сеанс работы завершен администратором". Установив в boot.ini ключ /3GB ошибка устранилась. Огромное спасибо за полезную информацию.
(21) artur.antipin, аналогичная проблема. Я думаю вряд ли поможет, если 32 Gb на сервере, SQL использует 30, 1Gb погоды не сделает
Недавно у клиентов была такая проблема, просто отпала база с указанной ошибкой. MS SQL 2000 показывал базу не в состоянии Suspend, а в состоянии Offline. Понятно что наивный расчет на Online базы не оправдался и я устроил допрос.
В ходе следствия выяснилось что ничего страшного никто не делал (на самом деле) просто у части юзеров полезли избыточные блокировки, и сервер(физический) было решено перезагрузить.
После перезагрузки никто не смог войти, т.к. был Offline режим файлы базы скопировать тоже не удавалось, без меня делать детач боялись. Но так как мне ничего не оставалось я нажал детач. Сервер не много подумал и отключил базу но в списке баз отключенная база осталась не отобража имени, просто пустая строка, перезапуск сервера открылся с(!) подключенной живой базой. Но была проблема, беглый осмотр основных мест показал, что полностью упали итоги регистра Заказы покупателей( изб блокировки были связаны скорее всего с этим) в итоге пришлось их пересчитывать 2,5 часа не долго, но обычно за месяц итоги считались минут 15, значит точно упали.
КонецИстории )
з.ы. причин установить не удалось
Целый день бьюсь с этой проблемой. Пришлось потанцевать с бубном. УПП 1.2.27 Платформа 15. sql 2005. Ошибка решилась соблюдением следующей последовательности действий.
1) удаляю записи больше 120 мб в sql.
2) Снимаю базу с поддержки
3)Объединяю с типовой cf 1.2.27 без галок (одновременно ставлю на поддержку) 1.2.27 предварительно протестирована и исправлена (не знаю важно ли это, но было именно так)
Возникла аналогичная проблема "Соединение с сервером баз данных разорвано администратором Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005" при выгрузке конфигурации из БП 1.6.24.7 на 1С 8.2, сервер SQL 2000. Вопрос решился добавлением рабочего процесса в консоли «Серверы 1С:Предприятия 8.2». Попробуйте. :)
Тоже возникла проблема с основной конфигурацией в файловом варианте. Как посоветуете drop-нуть ConfigSave?
Ошибка: Сеанс работы завершен администратором.
по причине:
Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: [DBNETLIB][ConnectionRead (recv()).]General network error. Check your network documentation.
HRESULT=80004005, SQLSrvr: Error state=1, Severity=10, native=11, line=0
1C 8.1.14 + MS SQl 2005 + Терминальник (на 3х серверах)
Ошибка возникает при любых действиях пользователя - хаотично ((( причин установить не удалось
(27) как ваша ошибка коррелирует с указанной в статье "Неопознанная ошибка"?
У вас же проблема с большей вероятностью в включенном файрволе.
(28) файрволов/антивирусов нет на сервере + Ошибка возникла без каких либо изменений в системе через год после експлуатации.
(27) Vet_ne, Не подскажете как проблема решилась, у меня тоже HRESULT=80004005, SQLSrvr: Error state=1, Severity=10, native=11, line=0
бодаюсь пока безрезультатно.
вот выдержка из этой статьи (хоть и для 2000, но принцип тотже):
Устранение неполадок с установкой подключений
Большинство подобных неполадок в SQL Server 2000 возникает из-за проблем с протоколом TCP/IP или проверкой подлинности Windows либо сочетанием проблем обоих типов.
Внимание! Перед тем как приниматься за устранение неполадок с установкой подключений в SQL Server 2000, убедитесь, что на компьютере с SQL Server запущена служба MSSQLServer.
Запишите возвращенный IP-адрес.
4. Из командной строки выполните следующую команду (где IP address — это IP-адрес, выписанный при выполнении действия 3):
Убедитесь, что команда возвращает правильное имя сервера. Если же одна из указанных выше команд завершается сбоем, возвращает неправильное значение или истекает время ожидания для ее выполнения, значит, неправильно работает просмотр DNS или существует иная проблема, связанная с функционированием сети или маршрутизацией. Чтобы просмотреть текущие параметры DNS, запустите из командной строки следующую команду:
Чтобы устранить эту проблему, добавьте запись для сервера в файл %systemroot%\system32\drivers\etc\hosts на клиентском компьютере. Кроме того, обойти проблему можно путем установки подключения к серверу с помощью сетевой библиотеки именованных каналов.
Примечание. Необходимо включить хотя бы протокол TCP/IP и именованные каналы.
3. Откройте вкладку Псевдоним и проверьте псевдонимы, настроенные для экземпляра SQL Server.
4. Убедитесь, что в свойствах псевдонимов правильно настроены имя сервера (IP-адрес) и протокол.
Можно создать новый псевдоним для тестирования подключения по имени сервера, IP-адресу или другому протоколу.
Примечание. В более ранних версиях компонентов доступа к данным Майкрософт (MDAC) интерфейс программы сетевого клиента отличается. Таким образом, если вы не видите описанных в этой статье элементов интерфейса, установите на клиентском компьютере более новую версию компонентов MDAC.
ОЗУ сервера: 16Gb Место на диске: пердостаточно windows server 2008 R2 Enterprise х64 размер файлов базы : 3.5Gb mdf, 9.2 Gb - log (после деаттача - 1 Mb) ошибка: При выгрузке в *.dt пишет "Ошибка разделенного доступа к информационной базе" Что испробовано: - на этом же сервере другая база выгружается (без галочки блокировок регЗаданий, без выключения консоли) правда размер базы меньше. 1Gb mdf и 200 Mb log - Перезагрузка сервера - перезагрузка sqlserver и агент сервера 1с - развертка второй базы из бэкапа - очищение LOG.ldf - детач - аттач (чобы лог файл обнулился) - SELECT FROM dbo.Config WHERE DataSize > 125829120 в результате (пусто) - снятие с поддержки конфигурации - полное ТиИ, пересчет итогов Остановился на Технологическом Журнале. В логах ТЖ следующее: Descr='Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 10.0: Ошибка связи HRESULT=80004005 и ниже 27:52.5739-0,EXCP,3,process=rphost,p:processName=wano1,t:clientID=112,t:applicationName=Designer,t:computerName=DELEIL,t:connectID=55,SessionID=5,Usr=Администратор,Exception=dd149677-3d47-4e05-a55f-4e75b13a441f,Descr='SrcRemoteInterfaceImpl.cpp(1629): dd149677-3d47-4e05-a55f-4e75b13a441f: Сеанс работы завершен администратором. dc31263e-ecbf-41bd-9b3a-7b55897d5fd6: Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 10.0: Поставщик общей памяти: С обоих концов канала отсутствуют процессы. Помогите с решением.
GO EXEC sp_configure 'show advanced options', 1; GO GO EXEC sp_configure 'network packet size', 32000 ; GO RECONFIGURE; GO так? это значит выгнать всех надо с сервера?
нет размер пакета кратен килобайту 32000 я указал примерно. "это значит выгнать всех надо с сервера?" нет "Параметр вступает в силу немедленно, без перезапуска сервера."
как посмотреть зависшие фоновые? сервер перезагружался, службы тоже. Фоновые отключены в конфигураторе. где и как отключить shared memory?
"Microsoft SQL Server Native Client 10.0: Поставщик общей памяти: С обоих концов канала отсутствуют процессы. " возможно проблема в протоколе.
такая казуистика только в кино про докторхауса бывает. Тут либо есть реально какой-то коннект, либо есть огромные таблицы, либо надо обновить наконец платформу - 2015й год на дворе
"размер файлов базы : 3.5Gb mdf, 9.2 Gb - log (после деаттача - 1 Mb) - детач - аттач (чобы лог файл обнулился)" Вы так базу не убили часом? Или это новый способ обрезания лога транзакций?
вот тут какие-то сказки еще рассказывают, что снятие с поддержки помогает починить ситуацию, но я лично в это верю не больше, чем в shared memory
это рабочий способ шринкануть лог. Варварский, но рабочий. Базу так не потеряешь, если после детача ее руками не грохнуть шифтделитом.
скорее новый способ. Ну что вычитал, то вычитал. Я же не проверяю на других форумах Ваши рекомендации. Вот и пробовал что советовали. снятие с поддержки тоже пробовал. в описано.
те сказки читал еще вчера ночью. и другие читал. не помогло как видите. аж до 8.3.5? хм. а она заведется в режиме обычного приложения? нам управляемый не нужен.
посмотрите с помощью ms sql profiler, последние действия 1с с mssql. Возможно это наведет на источник проблемы.
если сервер 1С 64Х и на сиквеле стоят SP, то путь один - выгрузить cf, поднять на любом другом не MS сиквеле базу, залить через выгрузкузагрузкавидентичную данные и из этой базы получить dt при этом можно попробовать и в файловый залить
то есть из x64 скуля в dt оно в принципе вообще не выгружается по техническим причинам непобедимого характера?
конфигурация: Бухгалтерия для Казахстана. (2,0,18,11) с небольшими дописками. просто документов Реализация и СФ мнооооого.
я не понял из обрывков ни уя, думаю, что автор - тоже. При каких условия "x64" и где выгружаться не будет?
на сервере IPv6 отключено. Но в реестре не трогали. как описано в статье, надо IPv6 вырубать еще и в реестре. попробую ночью. когда можно будет серв перезагружать.
shuhard, я не пойму, ты на куски развалишься, если сформулируешь свою мысль полностью от начала до конца в одно предложение?
у меня похожая аналитика была при отсутствии на MS 2008 сервиспака, правда не при выгрузке dt, а при обновлении конфы итого - SP стоит ?
простите? сама сервак? или что то другое? винда 64 бита. sql фиг иво. как посмотреть то? можно пару слов хотя бы, как профайлером смотреть?
на одной машине. подключаюсь удаленно RMS-ом, под администратором. да и другими вариантами пробовал. фаерволы не смотрел. но другая база же выгружается. всего на сервере 3 базы.
сервер приложений 1С. Который "Агент сервера и блаблабла", который rphost'ы запускает. Вот он - -какой?
брандмауер выключен. C:Program Files (x86)1cv828.2.19.106in agent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:Program Files (x86)1cv82srvinfo" означает ли это что он 64?
[на одной машине]+[ОЗУ сервера: 16Gb] тогда диагноз прост, 90% памяти отдано сиквелу, rhost либо 32Х, либо 64Х и памяти у него меньше 8Гбайт ошибка, как ни странно - мало памяти лечить - переходом на 64Х + выделением ему достаточной памяти + крайний SP на сиквел
угу нужен ключ на 64Х и отобрать побольше памяти у сиквела или разнести сервер 1С и сиквел строка запуска выглядит так C:Program Files1cv828.2.19.90in agent.exe" -srvc -agent -debug -regport 2541 -port 2540 -range 2560:2591 -d "C:Program Files1cv82srvinfo" имя службы 1C:Enterprise 8.2 Server Agent (x86-64)
ПКМ в Менеджмент студии по корню - свойства - память но ограничение памяти сиквела обоюдоострый вариант, начнет расти темп и могут отвалиться часть отчетов
отдай людям sql-дамп. Даже, если ты выжмешь каким-то образом dt, они с другой стороны столкнутся с такими же проблемами при загрузке. Сэкономь свое и чужое время
на горячку можно менять параметр? когда в других базах люди? там стоит сейчас 2147483647 причем в Mb написано хочу поставить 6144 (Mb) сойдет?
память поставил 6 Гб сделал как в статье. перезагрузил сервак. результата нету. остался этот вариант. не знаю реализуем ли он. Можно ли на серв доставить 64х чтобы не навредить 32х. и потом на него базы перевести (хотя бы ту, из которой надо выгрузку сделать)?
[не знаю реализуем ли он] легко ставишь на 25-ие порты 8.3.ХХ.ХХ 64 к нему эмуль и в параллель живут 8.2 32 и 8.3 64 но есть же лобовое решение: - выгрузить cf - выгрузитьзагрузитьчерезXML если файловая рабочая. то не придётся париться
я тут наковырял в ТЖ еще ошибку на файл SELECT TOP 8 [FileName] ,[Creation] ,[Modified] FROM [wano1].[dbo].[Files] работает , а вот если добавить столбец binarydata то на 7 строках пашет а если на 8 строках то ошибка Поставщик общей памяти, error: 0 - С обоих концов канала отсутствуют процессы.) SELECT TOP 8 [FileName] ,[Creation] ,[Modified] ,[Attributes]
а в ТЖ было 52:45.2574-0,EXCP,1,process=1cv8,Usr=Администратор,Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3,Descr="srcInfoBaseImpl.cpp(9749): 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Неправильный путь к файлу 'c01b78f6-1525-41b1-9cc1-69e3da58d2ac.pfl'"
Кстати, в 9 строке в столбце FileName и есть c01b78f6-1525-41b1-9cc1-69e3da58d2ac.pfl то что он не может найти. значит мне надо удалить 9 строку.
ошибка та же. на c01b78f6-1525-41b1-9cc1-69e3da58d2ac.pfl НО. в таблице FILES данной строки уже нет. и где ее искать теперь? как по sql базе можно найти ссылку?
выгрузилась после удаления 2 строк в таблице Files. Строки удалял те, которые не выводились запросом в со столбцом BinaryData. после чего сделал DBCC CHECKTABLE('wano1.dbo.Files', repair_allow_data_loss), он там чего то восстановил. о результате сообщу.
Есть инструкция как воспользоваться этим дампом? Мне иногда надо потренироваться на другом сервере с базой клиента.
В общем развернулась база. все нормально. весит чуть меньше sql. данные в порядке. кратко о решении: в получается что не в сервере и не в ПО дело. хотя все вышеописанные рекомендации тоже делал. спасибо за помощь.
Я использую Microsoft SQL Server 2012, и у пользователя есть все разрешения.
Сервер был настроен на проверку подлинности Windows только по умолчанию. Нет никаких уведомлений о том, что причина ошибки именно в этом, поэтому понять это сложно. Студия SQL Management не предупреждает, даже если вы создаете пользователя только с аутентификацией SQL.
Итак, ответ: Переключитесь с Windows на аутентификацию SQL :
- Щелкните правой кнопкой мыши имя сервера и выберите properties ;
- Выберите вкладку security ;
- Включите SQL Server and Windows Authentication mode ;
- Перезапустите службу SQL Server.
Теперь вы можете подключиться со своим логином / паролем.
В моем случае вход в систему работает удаленно, через VPN. Но подключение с сервера, на котором был установлен sql-сервер, не удалось.
Оказывается, имя экземпляра не по умолчанию, например. SQLEXPRESS. Следовательно, это необходимо явно указать при подключении.
В моем случае: назначить пользователю роль системного администратора.
В моем случае база данных была восстановлена, и пользователь уже использовался для подключения. Мне пришлось удалить пользователя в базе данных и воссоздать сопоставление пользователей для входа в систему.
Это может потерпеть неудачу, если у пользователя есть какие-либо схемы. Они должны быть назначены dbo перед удалением пользователя. Получите схемы, принадлежащие пользователю, используя первый запрос ниже, а затем измените владельца этих схем, используя второй запрос (HangFire - это схема, полученная из предыдущего запроса).
Следуйте другому ответу, и, если он по-прежнему не работает, перезагрузите компьютер, чтобы эффективно перезапустить службу SQL Server в Windows.
Убедитесь, что вы указали пользователя в Security-> Logins, если нет - добавьте его и попробуйте еще раз.
Всегда пытайтесь войти в систему, используя эти учетные данные с помощью SQL Management Studio. Это может раскрыть некоторые дополнительные детали, которые вы не получите во время выполнения в своем коде. Я проверил аутентификацию SQL + Windows, перезапустил сервер, но все равно не повезло. После попытки войти в систему с помощью SQL Management я получил следующее приглашение:
Каким-то образом срок действия пароля истек, хотя логин был создан всего за несколько минут до этого. В любом случае, новый пароль установлен, строка подключения обновлена и все в порядке.
У меня та же проблема: «Соединение с сервером было успешно установлено, но затем произошла ошибка во время процесса входа в систему. (Поставщик: поставщик общей памяти, ошибка: 0 - на другом конце канала нет процесса.)»
Сервер = POS06 \ SQLEXPRESS; AttachDbFilename = C: . \ Datas.mdf; Начальный каталог = Datas; ID пользователя = sa; Pwd = 12345; Время ожидания подключения = 10;
Но мой SQL - это POS06 \ MSQL2014
Измените строку подключения на
Сервер = POS06 \ MSQL2014; AttachDbFilename = C: . \ Datas.mdf; Начальный каталог = Datas; ID пользователя = sa; Pwd = 12345; Время ожидания подключения = 10;
Была и эта ошибка, причина была простой, но не очевидной: неверный пароль. Не уверен, почему я не получил просто «Ошибка входа» от только что установленного сервера SQL 2016.
Ага, эта ошибка могла также быть «что-то не удалось, удачи в разоблачении» - в моем случае это было неправильное имя пользователя. SQL Server 2019 RC1.
Для меня истек срок действия пароля для моего пользователя, входящего в систему, и я получил то же исключение. Затем я вхожу в систему в режиме проверки подлинности Windows и меняю пароль для связанного пользователя, и это решило мою проблему.
Я сталкиваюсь с этой проблемой во второй раз, и все предыдущие ответы не удались, к счастью, следующий запрос выполняет свою работу:
Если вы пытаетесь войти в систему с учетными данными SQL, вы также можете попробовать изменить LoginMode для SQL Server в реестре, чтобы разрешить как проверку подлинности SQL Server, так и проверку подлинности Windows.
- Открыть регедит
- Перейдите к ключу экземпляра SQL (может отличаться в зависимости от имени вашего экземпляра): Computer \ HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SQL Server \ MSSQL14.SQLEXPRESS \ MSSQLServer \
- Установите LoginMode на 2
- Перезапустите службу SQL и SQL Server Management Studio и повторите попытку.
Пожалуйста, проверьте это также Также проверьте конфигурацию TCP / IP, включите Names PipeLine и общую память.
Другой причиной этой ошибки может быть неправильное или несуществующее имя базы данных.
Принудительное установление TCP / IP-соединения (путем предоставления 127.0.0.1 вместо localhost или . ) может выявить настоящую причину ошибки. В моем случае имя базы данных, указанное в строке подключения, было неверным.
Итак, вот чек-лист:
- Убедитесь, что Named Pipe включен в диспетчере конфигурации (не забудьте перезапустить сервер).
- Убедитесь, что база данных, к которой вы подключаетесь, существует.
- Убедитесь, что проверка подлинности SQL Server (или смешанный режим) включена.
Просто и я чувствую себя немного глупо, но это был ответ для меня.
Также вы можете попробовать перейти к службам и перезапустить экземпляр сервера Sql.
Чтобы решить эту проблему, подключитесь к SQL Management Studio с помощью проверки подлинности Windows, затем щелкните правой кнопкой мыши узел сервера «Свойства» -> «Безопасность» и включите режим проверки подлинности SQL Server и Windows. Если вы используете sa, убедитесь, что учетная запись включена. Для этого откройте «sa» в разделе «Логины» и просмотрите статус.
Если это не сработало, вам может потребоваться переустановить SQL Server.
Читайте также: