Ошибка соединения с сервером баз данных что это значит

Соединение с сервером баз данных разорвано администратором или Неопознанная ошибка 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 как по умолчанию. После перезагрузки — все ОК.

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

Источник

Устраняем типичные ошибки в MySQL

Авторизуйтесь

Устраняем типичные ошибки в MySQL

MySQL — система управления базами данных (СУБД) с открытым исходным кодом от компании Oracle. Она была разработана и оптимизирована специально для работы веб-приложений. MySQL является неотъемлемой частью таких веб-сервисов, как Facebook, Twitter, Wikipedia, YouTube и многих других.

Эта статья расскажет, как определять, с чем связаны частые ошибки на сервере MySQL, и устранять их.

Не удаётся подключиться к локальному серверу

Одной из распространённых ошибок подключения клиента к серверу является «ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)».

Эта ошибка означает, что на хосте не запущен сервер MySQL ( mysqld ) или вы указали неправильное имя файла сокета Unix или порт TCP/IP при попытке подключения.

Убедитесь, что сервер работает. Проверьте процесс с именем mysqld на хосте сервера, используя команды ps или grep, как показано ниже.

Если эти команды не показывают выходных данных, то сервер БД не работает. Поэтому клиент не может подключиться к нему. Чтобы запустить сервер, выполните команду systemctl.

Чтобы проверить состояние службы MySQL, используйте следующую команду:

Если в результате выполнения команды произошла ошибка службы MySQL, вы можете попробовать перезапустить службу и ещё раз проверить её состояние.

Если сервер работает (как показано) и вы по-прежнему видите эту ошибку, вам следует проверить, не заблокирован ли порт TCP/IP брандмауэром или любой другой службой блокировки портов.

New Media , Санкт-Петербург , По итогам собеседования

Для поиска порта, который прослушивается сервером, используйте команду netstat .

Не удаётся подключиться к серверу MySQL

Ещё одна похожая и часто встречающаяся ошибка подключения — «(2003) Can’t connect to MySQL server on ‘server’ (10061)». Это означает, что в сетевом соединении было отказано.

Следует проверить, работает ли в системе сервер MySQL (смотрите выше) и на тот ли порт вы подключаетесь (как найти порт, можно посмотреть выше).

Похожие частые ошибки, с которыми вы можете столкнуться при попытке подключиться к серверу MySQL:

Ошибки запрета доступа в MySQL

В MySQL учётная запись (УЗ) определяется именем пользователя и клиентским хостом, с которого пользователь может подключиться. УЗ может также иметь данные для аутентификации (например, пароль).

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

В MySQL есть возможность создавать учётные записи, позволяющие пользователям клиентских программ подключаться к серверу и получать доступ к данным. Поэтому при ошибке доступа проверьте разрешение УЗ на подключение к серверу через клиентскую программу.

Увидеть разрешённые привилегии учётной записи можно, выполнив в консоли команду SHOW GRANTS
Входим в консоль (пример для Unix, для Windows консоль можно найти в стартовом меню):

В консоли вводим команду:

Дать привилегии конкретному пользователю в БД по IP-адресу можно, используя следующие команды:

Ошибки запрещённого доступа могут также возникнуть из-за проблем с подключением к MySQL (см. выше).

Потеря соединения с сервером MySQL

С этой ошибкой можно столкнуться по одной из следующих причин:

• плохое сетевое соединение;
• истекло время ожидания соединения;
• размер BLOB больше, чем max_allowed_packet .

В первом случае убедитесь, что у вас стабильное сетевое подключение (особенно, если подключаетесь удалённо).

Если проблема с тайм-аутом соединения (особенно при первоначальном соединении MySQL с сервером), увеличьте значение параметра connect_timeout .

В случае с размером BLOB нужно установить более высокое значение для max_allowed_packet в файле конфигурации /etc/my.cnf в разделах [mysqld] или [client] как показано ниже.

Если файл конфигурации недоступен, это значение можно установить с помощью следующей команды.

Слишком много подключений

Эта ошибка означает, что все доступные соединения используются клиентскими программами. Количество соединений (по умолчанию 151) контролируется системной переменной max_connections . Устранить проблему можно, увеличив значение переменной в файле конфигурации /etc/my.cnf .

Недостаточно памяти

Если такая ошибка возникла, это может означать, что в MySQL недостаточно памяти для хранения всего результата запроса.

Сначала нужно убедиться, что запрос правильный. Если это так, то нужно выполнить одно из следующих действий:

• если клиент MySQL используется напрямую, запустите его с ключом —quick switch , чтобы отключить кешированные результаты;
• если вы используете драйвер MyODBC, пользовательский интерфейс (UI) имеет расширенную вкладку с опциями. Отметьте галочкой «Do not cache result» (не кешировать результат).

Также может помочь MySQL Tuner. Это полезный скрипт, который подключается к работающему серверу MySQL и даёт рекомендации по настройке для более высокой производительности.

MySQL продолжает «падать»

Если такая проблема возникает, необходимо выяснить, заключается она в сервере или в клиенте. Обратите внимание, что многие сбои сервера вызваны повреждёнными файлами данных или индексными файлами.

Вы можете проверить состояние сервера, чтобы определить, как долго он работал.

Чтобы узнать время безотказной работы сервера, запустите команду mysqladmin .

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

Заключение

Самое важное при диагностике — понять, что именно вызвало ошибку. Следующие шаги помогут вам в этом:

• Первый и самый важный шаг — просмотреть журналы MySQL, которые хранятся в каталоге /var/log/mysql/ . Вы можете использовать утилиты командной строки вроде tail для чтения файлов журнала.
• Если служба MySQL не запускается, проверьте её состояние с помощью systemctl . Или используйте команду journalctl (с флагом -xe ) в systemd.
• Вы также можете проверить файл системного журнала (например, /var/log/messages ) на предмет обнаружения ошибок.
• Попробуйте использовать такие инструменты, как Mytop, glances, top, ps или htop, чтобы проверить, какая программа использует весь ресурс процессора или блокирует машину. Они также помогут определить нехватку памяти, дискового пространства, файловых дескрипторов или какого-либо другого важного ресурса.
• Если проблема в каком-либо процессе, можно попытаться его принудительно остановить, а затем запустить (при необходимости).
• Если вы уверены, что проблемы именно на стороне сервера, можете выполнить команды: mysqladmin -u root ping или mysqladmin -u root processlist , чтобы получить от него ответ.
• Если при подключении проблема не связана с сервером, проверьте, нормально ли работает клиент. Попробуйте получить какие-либо его выходные данные для устранения неполадок.

Источник

Ошибка установки соединения с базой данных: причина, исправление

Занимаясь разработкой собственного сайта, мы часто сталкиваемся с ошибками установки соединения с базой данных, внутренними неполадками сервера и т.д. Все это пугающе действует на новичка. Даже опытные блогеры с трудом справляются с похожими проблемами. Но не стоит паниковать. Чаще такие проблемы решаются в два счета.

WordPress

Одна из наиболее популярных систем управления «начинкой» ресурса. На платформе WordPress появляются мелкие блоги и крупные проекты. Ошибка установки соединения с базой данных происходит именно с этой CMS.

Написан WP на скриптовом языке общего назначения PHP. Сервером БД (база данных) служит MySQL. Впервые CMS появилась в 2003 году и сейчас имеет версию 4.8.1. Преимуществами WordPress считаются простота в управлении контентом, большое количество дополнительных инструментов — тем и плагинов.

Содержание

Прежде чем понять, как избавиться от ошибки установки соединения с базой данных WordPress, важно рассмотреть строение системы. Любой ресурс на основе этой CMS основан на двух важных элементах. Речь идет о программных файлах и БД.

Первые находятся на хостинге, куда можно попасть по запросу через FTP. Вторые хранятся на хостинге в отдельном секторе. Для перехода необходимо скачать специальный сервис. Популярностью пользуется PhpMyAdmin.

Если программным документам нужна дополнительная информация, они переходят в БД, используя материалы оттуда. Далее отображают страницу ресурса корректно.

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

При обнаружении ошибки установки соединения с базой данных становится понятно, что у программных документов нет возможности попасть в БД и корректно отобразить страницу.

Проверка

Прежде чем решать эту проблему, нужно осуществить пару проверочных действий, которые помогут выявить причину ошибки.

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

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

Используем сервис PhpMyAdmin, вводим логин и пароль. Если вы не можете определить, пустая ли база, посмотрите на её вес и содержимое. Обычно должны быть таблицы и записи, а объем папки может быть от Кб.

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

Почему?

Интересно, что ошибка установки соединения с базой данных появляется и вместе с транспортировкой ресурса. Причем возникает неполадка с вероятностью 99%. Если ресурс уже был установлен на хостинг, а неполадка возникла, то может быть ряд других причин.

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

Частичная проблема

Иногда подобная неприятность возникает частично. В хранилище пропали определенные таблицы или стали недоступны. Чтобы убедиться в точности этой неполадки, достаточно перейти в панель администратора. При повторном возникновении проблемы нужно проверять БД.

Чтобы восстановить её, переходим к файлику wp-config.php. Сюда нужно внести дополнительную команду: define(‘WP_ALLOW_REPAIR’, true);. Теперь нужно перейти в специальное меню site.com/wp-admin/maint/repair.php. На месте site.com указываете ваш ресурс. После появится окно с восстановлением.

В нем желательно выбрать не просто восстановление, но и оптимизацию. Процесс занимает несколько минут. После завершения необходимо будет убрать команду из файла wp-config.php.

Транспортировка

Возможно, со временем вы решили перенести блог с Denwer. Ошибка установки соединения с базой данных появляется при некорректности файла wp-config.php. Здесь нужно указывать конфигурацию, нужную для соединения с БД.

Открыв этот документ, важно внимательно присмотреться к показателям, которые там имеются. Чаще всего имя пользователя и базы данных одинаково. Оно появляется при регистрации на хостинге. Тут же есть и пароль. Все это нужно сохранять при переносе ресурса с разных сервисов, в том числе и Openserver.

Ошибка установки соединения с базой данных исключена, если все личные данные вы сохраните навсегда. Также важно не перепутать пароль БД и «админки». Их вы также устанавливаете отдельно, и желательно, чтобы они были разные.

Если все правильно, а ошибка по-прежнему не исправлена, нужно протестировать работоспособность БД. Для этого создается специальный тестовый файл. Его конфигурация может несколько отличаться, поэтому желательно самостоятельно для себя подобрать команды. Такой test.php поможет запустить нам проверку системы.

После того как вы заполните документ, нужно перейти на site.com/test.php. При успешном подключении становится понятно, что хостинг работает корректно. Точно так же все хорошо с паролем и именем пользователя.

Если тест выдает, что вы используете некорректное имя или шифр, значит придется отправиться в панель и поменять данные. Если же вы и вовсе не смогли «законнектиться», то проблема на сервере. Тут дело проще. Подождите какое-то время либо обратитесь в службу поддержки хостинга.

Выводы

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

Источник