30.09.21 — 02:15
Пробовал перенести: 1. выгрузкой загрузкой 2. через обработку обмена (загрузив конфигурацию), не получается. Постоянно выскакивает ошибка: Ошибка DMBS: Превышен максимально допустимый внутренний размер файла
Есть опыт в решении вопроса?
1 — 30.09.21 — 02:19
Конечно, но тебе они не помогут
2 — 30.09.21 — 05:27
Удалить интересные видео из файловых вложений для начала.
3 — 30.09.21 — 05:45
(0) Это означает что файловую вам не создать.
Какая-то таблица уже перешла пределы размеров для файловой базы.
Надо или свертывать или оставаться или постгри.
4 — 30.09.21 — 07:47
(0) Маловероятно, но уточню. Платформа у вас >= 8.3.8?
5 — 30.09.21 — 08:11
(0)> Ошибка DMBS: Превышен максимально допустимый внутренний размер файла
что именно не понятно в этом сообщении?
достигнут предельный размер внутреннего файла для файлового варианта
если это не глюк, то вариант только один — сворачивать исходную базу, из которой производится выгрузка,
и да, надо было указать конфигурацию, а то может у вас там ERP
6 — 30.09.21 — 08:16
1cd — это по сути контейнер с файлами. Каждый «файл» — это таблица данных или индекс или ещё какая хрень. Так вот, у внутреннего файла есть ограничение в 4Гб. С версии 8.3.8 это ограничение можно «подвинуть» до 6Гб, перейдя на увеличенный размер страницы. Ограничение в данном случае не техническое, а прибито гвоздями, но селяви — это 1с.
7 — 30.09.21 — 08:16
(4) 100% новая база создавалась на платформе выше 8.3.8 со страницами 8К и расширенным лимитом до 6Гб на внутренний файл,
играться утилитой CNVDBFL.EXE с размером страниц смысла не имеет
8 — 30.09.21 — 08:18
(0)
Какова цель переноса в файловую?
9 — 30.09.21 — 08:20
Если цель в том, чтобы легализоваться с пиратки, но при этом не платить за сервер, то путь только один — предварительно найти в sql самую жирную таблицу и принять меры к её уменьшению.
10 — 30.09.21 — 09:04
(7) Ну, чудеса случаются. Кто знает, что за конфигурация и насколько старая.
11 — 30.09.21 — 09:12
(0) попробуй в конфигураторе сделать исправления, типа пересоздание индекса и таблиц, а потом выгрузи в дт
12 — 30.09.21 — 09:29
Лучше уговорите хозяина потратиться на сервер 1с. Всего то полсотни тыр, и проблема решена. А если пользователей до 5, то и мини-сервер пойдет за 14400.
13 — 30.09.21 — 09:42
странно, что при ошибке с сообщением о превышении максимального размера ТС ни словом не обмолвился про фактический размер базы
14 — 30.09.21 — 09:46
ОФФ: ТС закопали…
15 — 30.09.21 — 10:21
Если скуль, стрельни в SSMS скриптом
USE test_base
GO
SELECT
tab.name AS TableName,
part.rows,
CAST(SUM(allocat.total_pages) * 8 / 1024.00 AS numeric(20,2)) AS TotalMB,
CAST(SUM(allocat.used_pages) * 8 / 1024.00 AS numeric(20,2)) AS UsedMB,
CAST(SUM(allocat.total_pages) — SUM(allocat.used_pages) * 8 / 1024.00 AS numeric(20,2)) AS UnusedMB
FROM
sys.tables tab
INNER JOIN
sys.indexes idx ON tab.object_id = idx.object_id
INNER JOIN
sys.partitions part ON idx.object_id = part.object_id AND idx.index_id = part.index_id
INNER JOIN
sys.allocation_units allocat ON part.partition_id = allocat.container_id
GROUP BY
tab.name, part.rows
ORDER BY
TotalMB DESC
GO
16 — 30.09.21 — 10:22
USE test_base
тут нужно поменять
USE <имя_твоей_базы>
17 — 30.09.21 — 10:30
Потом смотри какие у тебя самые большие таблицы, и прикидывать что в них за данные. Может там какой-нибудь мусор типа служебных логов, или вложенные файлы
18 — 30.09.21 — 10:37
Сорри, пару скобочек потерял
USE test_base
GO
SELECT
tab.name AS TableName,
part.rows,
CAST(SUM(allocat.total_pages) * 8 / 1024.00 AS numeric(20,2)) AS TotalMB,
CAST(SUM(allocat.used_pages) * 8 / 1024.00 AS numeric(20,2)) AS UsedMB,
CAST((SUM(allocat.total_pages) — SUM(allocat.used_pages)) * 8 / 1024.00 AS numeric(20,2)) AS UnusedMB
FROM
sys.tables tab
INNER JOIN
sys.indexes idx ON tab.object_id = idx.object_id
INNER JOIN
sys.partitions part ON idx.object_id = part.object_id AND idx.index_id = part.index_id
INNER JOIN
sys.allocation_units allocat ON part.partition_id = allocat.container_id
GROUP BY
tab.name, part.rows
ORDER BY
TotalMB DESC
GO
19 — 30.09.21 — 11:40
Спасибо, понял. (все лицензионное!)
20 — 30.09.21 — 11:47
(19) это прекрасно, но в файловом варианте данная база все равно не взлетит
21 — 30.09.21 — 11:50
(0) Есть оптимальное решение: оставить на SQL.
22 — 30.09.21 — 12:03
(19) селекты крутить через ssms не запрещено лицензией
23 — 30.09.21 — 12:03
(21) как понимаю автору нужно запустить копию базы локально на своем ПК для каких-то доработок
24 — 30.09.21 — 12:08
(23) Поднять SQL-сервер для таких задач.
Winnie Buh
25 — 30.09.21 — 12:10
(24) это слишком простой и очевидный вариант,
автор хочет файловую с танцами и бубнами
Discussing the best practices of 1C:Enterprise implementation, sharing the business-level of 1C:Enterprise implementation experience.
|
||||||
|
||||||
|
||||||
|
||||||
|
||||||
|
||||||
| Subscribe |
Users browsing this topic (guests: 1, registered: 0, hidden: 0)
Связка сервера 1С:Предприятие и PostgreSQL вторая по популярности среди установок 1С и самое используемое решение на платформе Linux. В отличии внедрений на базе Windows и MSSQL, где трудно сделать так, чтобы не заработало, внедрения на базе Linux таят множество подводных камней для неопытного администратора. Часто бывает так, что вроде бы все сделано правильно, но ошибка следует за ошибкой. Сегодня мы рассмотрим самые типовые из них.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Общая информация
Перед тем, как начинать искать ошибки установки и, вообще, приступать к внедрению серверной версии 1С:Предприятия было бы неплохо освежить представление как это работает:
Сервер 1С Предприятия. Часть 1 — Общие вопросы.
В небольших внедрениях сервер 1С и сервер СУБД обычно совмещают на одном физическом сервере, что немного сужает круг возможных ошибок. В нашем случае будет рассматриваться ситуация, когда сервера разнесены по разным машинам. В нашей тестовой лаборатории мы развернули следующую схему:
В нашем распоряжении имеются два сервера под управлением Ubuntu 12.04 x64, на одном из них установлен сервер 1С:Предприятие версии 8.3, на другом PostgreSQL 9.04 от Ethersoft, а также клиент под управлением Windows. Напоминаем, что клиент работает только с сервером 1С, который, в свою очередь, формирует необходимые запросы к серверу СУБД. Никаких запросов от клиента к серверу управления базами данных не происходит.
Сервер баз данных не обнаружен
ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)
Данная ошибка возникает при разнесении серверов по разным ПК из-за неправильно настроеной проверки подлинности в локальной сети. Для устранения откройте /var/lib/pgsql/data/pg_hba.conf, найдите строку:
host all all 192.168.31.0/24 identи приведите ее к виду:
host all all 192.168.31.0/24 md5где 192.168.31.0/24 — диапазон вашей локальной сети. Если такой строки нет, ее следует создать в секции IPv4 local connections.
Сервер баз данных не обнаружен
could not translate host name «NAME» to address: Temporary failure in name resolution
На первый взгляд ошибка понятна: клиент не может разрешить имя сервера СУБД, типичная ошибка для небольших сетей, где отсутствует локальный DNS-сервер. В качестве решения добавляют запись в файл hosts на клиенте, что не дает никакого результата…
А теперь вспоминаем, о чем было сказано несколько раньше. Клиентом сервера СУБД является сервер 1С, но никак не клиентский ПК, следовательно запись нужно добавлять на сервере 1С:Предприятие в файл /etc/hosts на платформе Linux или в C:WindowsSystem32driversetchosts на платформе Windows.
Аналогичная ошибка будет возникать, если вы забыли добавить запись типа A для сервера СУБД на локальном DNS-сервере.
Ошибка при выполнении операции с информационной базой
server_addr=NAME descr=11001(0x00002AF9): Этот хост неизвестен.
Как и прошлая, эта ошибка связана с неправильным разрешением клиентом имени сервера. На этот раз именно клиентским ПК. В качестве решения добавляем в файл /etc/hosts на платформе Linux или в C:WindowsSystem32driversetchosts на платформе Windows запись вида:
192.168.31.83 SRV-1C-1204где указываете адрес и имя вашего сервера 1С:Предприятия. В случае использования локального DNS следует добавить A-запись для сервера 1С.
Ошибка СУБД: DATABASE не пригоден для использования
Гораздо более серьезная ошибка, которая говорит о том, что вы установили несовместимую с 1С:Предприятие версию PostgreSQL или допустили грубые ошибки при установке, например не установили все необходимые зависимости, в частности библиотеку libICU.
Если вы имеете достаточный опыт администрирования Linux систем, то можете попробовать доустановить необходимые библиотеки и заново инициализировать кластер СУБД. В противном случае PostgreSQL лучше переустановить, не забыв удалить содержимое папки /var/lib/pgsql.
Также данная ошибка может возникать при использовании сборок 9.1.x и 9.2.x Postgre@Etersoft, подробности смотрите ниже.
Ошибка СУБД:
ERROR: could not load library «/usr/lib/x86_64-linux-gnu/postgresql/fasttrun.so»
Довольно специфичная ошибка, характерная для сборок 9.1.x и 9.2.x Postgre@Etersoft, также может приводить предыдущей ошибке. Причина кроется в неисправленной ошибке в библиотеке fasttrun.so. Решение — откатиться на сборку 9.0.x Postgre@Etersoft.
Ошибка СУБД
ERROR: type «mvarchar» does not exist at character 31
Возникает если база данных была создана без помощи системы 1С:Предприятия. Помните, для работы с 1С базы данных следует создавать только с использованием инструментов платформы 1С: через консоль Администрирование серверов 1С Предприятия
или через средство запуска 1С.
Сервер баз данных не обнаружен
ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (по паролю)
Очень простая ошибка. Неправильно указан пароль суперпользователя СУБД postgres. Вариантов решения два: вспомнить пароль или изменить его. Во втором случае вам нужно будет изменить пароль в свойствах всех существующих информационных баз через оснастку Администрирование серверов 1С Предприятия.
Сервер баз данных не обнаружен
FATAL: database «NAME» does not exist
Еще одна очень простая ошибка. Смысл ее сводится к тому, что указанная БД не существует. Чаще всего возникает из-за ошибки в указании имени базы. Следует помнить, что информационная база 1С в кластере и база данных СУБД — две разные сущности и могут иметь различные имена. Также следует помнить, что Linux системы чувствительны к регистру и для них unf83 и UNF83 два разных имени.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Здравствуйте!
Есть один сервер. На нем стоит MS SQL, 1С сервер и терминально подключаются пользователи через RDP (до 80 пользователей).
В один прекрасный день при входе в клиент-серверную базу 1С всем пользователям начало выдавать ошибку:
Платформа: 1С:Предприятие 8.3 (8.3.5.1068)
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Произошли ошибки во время выполнения многошаговой операции OLE DB. По возможности, проверьте значения всех состояний OLE DB. Работа не выполнена.
HRESULT=80040E21,
Сервер перезагрузили. После перезагрузки пользователи при попытки зайти в базу видели ошибку:
Платформа: 1С:Предприятие 8.3 (8.3.5.1068)
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Ошибка выделения памяти
HRESULT=80004005,
При запуске Тестирования и исправление на проверку логической целостности к моменту завершения конфигуратор выдал критическую ошибку и завершил работу.
Сервер перезагрузили и после пользователи смогли зайти в 1С и нормально начать работу. Прошло пара дней и при входе в 1С снова вылезла ошибка:
Платформа: 1С:Предприятие 8.3 (8.3.5.1068)
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Ошибка выделения памяти
HRESULT=80004005,
Потом, при выгрузке базы в файл .dt 1С её не выгрузила и выдала ошибку соединения с сервером 1С Предприятие. Подскажите возможные причины этого и как с этим бороться?
__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь
При работе в приложениях, связанных с обменом данных через портал 1С в некоторых ситуациях появляется сообщение: «Соединение с сервером баз данных разорвано администратором». Что в этом случае делать, об этом мы расскажем вам на протяжении этой статьи.
Содержание
- Решение ошибки с соединением с сервером баз данных в 1С
- Как правильно создать БД 1С Предприятия
- Другие решения ошибки в 1С
- Видеоинструкция
Решение ошибки с соединением с сервером баз данных в 1С
ПО 1С Бухгалтерия и предприятие содержит встроенные сервисы для решения некоторых проблем. Если ваша программа отказывается связываться с сервером 1С, то, как вы понимаете, это происходит на программном уровне. 
Они могут быть связаны с большим количеством некорректных файлов. Если выполнить проверку на эти файлы, приложение попытается освободиться от них. И программа снова станет работать в обычном режиме.
- Открываем 1С на компьютере;
- Вверху находится основное меню программы. В нём нужно найти пункт «Конфигурация» и выбрать мышью;
- В выпадающем окне находится пункт «Проверка конфигурации» — нажмите на него;
- Подтвердите проверку.
В настройках этой процедуры по пути также нужно поставить галочку на «Проверка логической целостности». Если ПО обнаружит какие-либо проблемы, пользователь будет об этом уведомлён. Но файлы, которые следует удалить, будут очищены в автоматическом режиме. Используйте эту функцию и в других случаях, когда появляются проблемы с приложением 1С Бухгалтерия. Если конфигурация на поддержке, необходимо провести проверку конфигурации поставщика. В настройках необходимо сохранить её в файл fc.
Затем следует загрузить файл в новую базу и снова провести проверку, которую мы сделали только что в инструкции. Если в ходе этого появятся ошибки, значит конфигурация поставщика содержит какие-либо неверные данные.
Читайте также: значение не является значением объектного типа 1С.
Как правильно создать БД 1С Предприятия
Эта инструкция поможет избавиться от ошибок, которые могли появится на этапе создания конфигурации в программе 1С Предприятия. После её запуска нам предлагают создать новую или выполнить добавление существующей базы.
Выберите подходящий вариант.
- Теперь нужно решить, нужен ли шаблон для создания конфигурации или мы будет создавать базу без него;
- Назовите каталог и укажите его расположение на компьютере;
- Далее обычно в параметрах добавления оставляют значения по умолчанию. Нажмите кнопку «Готово».
База данных создана. Теперь нужно понять, что за файлы она содержит. Это поможет в дальнейшем полноценно работать с цифровыми документами. Чтобы попасть в неё, нужно подсмотреть путь, который был указан в параметрах программы. Откройте эту папку на компьютере. Она будет содержать несколько файлов. Эти файлы отвечают за правильную работу ПО. Если создать новую БД, можно избавиться от ошибки: «Соединение с сервером баз данных разорвано администратором 1С».
При необходимости переноса базы данных пользователю нужно передать жёлтый файл на носитель или другое устройство. Эти данные можно посмотреть. Для этого используйте пользовательский интерфейс 1С Предприятия. Или режим «Конфигуратор».
Это может быть полезным: слишком много фактических параметров в 1С 8.3.
Другие решения ошибки в 1С
Параметры, которые установлены в программе пользователя могут приводить к сбою при работе с ней. Первой рекомендацией, которую нужно выполнить будет – отключение всех задач, которые работают в фоновом режиме в ПО. Параметр можно будет найти в разделе «Отладка» программы 1С Предприятия. А также в момент создания базы данных. В последних версиях программы появилась эта функция. Она может решить данную проблему. В процессе работы с программой в ней накапливаются разные данные, от которых нужно избавиться.
В противном случае накопление больших файлов приводят к выводам программы из строя. Фоновые задачи добавляют эти данные в кэш программы. Пользователь также может попытаться устранить проблему при помощи перезапуска сервера. Такая процедура является не очень эффективной, но в некоторых случаях действительно может помочь. Также хорошей привычкой будет создание резервных копий данных. Данная ошибка не приводит к потере важной информации. Но случается, что приложение зависает и потраченное время на ввод данных будет безвозвратно потеряно.
Попробуйте также выполнить снятие базы с поддержки и выгрузить cf. Затем в менеджменте консоли завершаем в таблице запись более 120 Мб. Далее снова следует загрузить конфигурацию. В операционной системе может не хватать памяти для полноценной работы программы. Попробуйте её увеличить за счёт физической памяти.
Видеоинструкция
Если не удалось исправить ошибку – Соединение с сервером баз данных разорвано администратором 1С, посмотрите это видео.
Ошибка СУБД:
Продолжение сообщения может быть различным:
-
1. DATABASE не пригоден для использования
2. ERROR: type «tt7» already exists
3. ERROR: could not read block
DATABASE не пригоден для использования
Пример полного текста ошибки:
|
Ошибка при выполнении операции с информационно базой по причине: Ошибка СУБД: DATABASE не пригоден для использования |
Описание ошибки:
База не запускается после установки и создания.
Решения:
Установим версию предназначенную для работы с 1С:Предприятием. Скачать такую можно с сайта 1С (при наличии купленного ИТС и открытого доступа), или приобрести у PostgresPro.
Либо проверим все ли зависимости были установлены. И установим недостающие.
ERROR: type «tt7» already exists
Пример полного текста ошибки:
|
Ошибка СУБД: ERROR: type «tt7» already exists HINT: A relation has an associated type of the same name, so you must use a name that doesn‘t conflict. |
Описание:
Данная ошибка является «плавающей» и может возникать в различных местах
Решение:
Выгрузим и загрузим базу данных средствами 1С:Предприятия(через файл *.dt).
ERROR: could not read block
|
Ошибка при выполнении операции с информационно базой по причине: Ошибка СУБД: ERROR: could not read block ... in file «» Input/output error |
Описание ошибки:
База не запускается. Разрушились диски.
Решения:
Переносим базу на другую дисковую систему.
Разворачиваем из резервной копии.
Не удалось запустить сервер PostgreSQL
Пример полного текста ошибки:
|
Не удалось привязаться к адресу. Адрес уже используется. Возможно порт 5432 занят другим процессом postmaster? Система БД выключена.Не удалось запустить сервер. |
Описание:
Такая ситуация часто случается у начинающих администраторов в случае, если они хотят инициализировать сервер в каталог отличный от каталога по умолчанию. При этом сервер уже запустили из каталога по умолчанию.
В этой ситуации при попытке запуска видно ошибку – сервер не запускается.
А при проверке состояния видно, что сервер работает.
|
netstat –tlnp | grep 5432 |
Если проверим запущенные процессы пользователя postgres, то можно увидеть, что порт 5432 занят кластером PostgreSQL, только запущенным из каталога по умолчанию.
Решение:
Остановим работающий кластер сервера СУБД.
|
/opt/pgpro/ent—10/bin/pg_ctl —locale=ru_RU.UTF—8 —D /var/lib/pgpro/ent—10/data stop |
Инициализируем кластер из нового каталога(если он не инициализирован).
|
/opt/pgpro/ent—10/bin/initdb —locale=ru_RU.UTF—8 —D /pgpro/pgdata |
Запустим из нового каталога.
|
/opt/pgpro/ent—10/bin/pg_ctl —locale=ru_RU.UTF—8 —D /pgpro/pgdata start |
Длительный запуск 1С:Предприятия при работе с СУБД PostgreSQL
Описание:
Длительный запуск, длительный захват объектов в хранилище, длительное сохранение конфигурации 1С:Предприятия.
Решение:
Такая проблема может быть связано с настройками СУБД PostgreSQL.
Рассчитаем настройки СУБД.
Описание настроек приведено на ИТС.
Выполним настройки, для этого перейдем в терминал psql:
Через psql установим параметры командой ALTER SYSTEM SET(параметры необходимо указать для вашей СУБД):
Пример настроек:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
ALTER SYSTEM SET shared_buffers = ’96GB’; ALTER SYSTEM SET effective_cache_size = ‘288GB’; ALTER SYSTEM SET maintenance_work_mem = ’20GB’; ALTER SYSTEM SET wal_buffers = ’16MB’; ALTER SYSTEM SET default_statistics_target = 100; ALTER SYSTEM SET random_page_cost = 1.1; ALTER SYSTEM SET effective_io_concurrency = 200; ALTER SYSTEM SET work_mem = ’10GB’; ALTER SYSTEM SET max_worker_processes = 44; ALTER SYSTEM SET max_parallel_workers_per_gather = 22; ALTER SYSTEM SET temp_buffers = ‘265MB’; ALTER SYSTEM SET wal_level = ‘replica’; ALTER SYSTEM SET max_replication_slots = ‘8’; ALTER SYSTEM SET max_wal_senders = ’32’; ALTER SYSTEM SET autovaccuum = ‘on’; ALTER SYSTEM SET autovaccuum_max_workers = 16; ALTER SYSTEM SET autovacuum_naptime = ’20s’; ALTER SYSTEM SET bgwriter_delay = ’20ms’; ALTER SYSTEM SET bgwriter_lru_multiplier = 4.0; ALTER SYSTEM SET bgwriter_lru_maxpages = 400; ALTER SYSTEM SET synchronous_commit = ‘off’; ALTER SYSTEM SET checkpoint_segments = 256; ALTER SYSTEM SET checkpoint_completion_target = 0.9; ALTER SYSTEM SET min_wal_size = ‘4GB’; ALTER SYSTEM SET max_wal_size = ‘8GB’; ALTER SYSTEM SET ssl = ‘off’; ALTER SYSTEM SET max_files_per_process = 1000; ALTER SYSTEM SET standard_conforming_strings = ‘off’; ALTER SYSTEM SET escape_string_warning = ‘off’; ALTER SYSTEM SET max_locks_per_transaction = 256; ALTER SYSTEM SET max_connections = 15000; |
Из файла *xlsx загружаются в 1С иероглифы/ в файл выгружаются иероглифы.
Описание ошибки:
При загрузке данных из файла *.xlsx в 1С отображаются иероглифы. Используемая СУБД PostgreSQL/PostgresPro.
Также возможна проблема с кодировкой в выгружаемом файле из 1С:
Решение:
На сервере СУБД проверим и выполним настройку локали.
1. Проверим наличие локали:
2. Проверим переменную:
Корректное значение результатов выполнения команд 2, 3:
3. Если результат не соответствует, выполним:
|
export LANG=«ru_RU.UTF-8» |
4. Выполним:
|
localectl set—locale LANG=ru_RU.utf8 |
5. Выполним перезапуск серверов СУБД
Я думаю каждый хоть раз, но сталкивался с ошибкой 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 как по умолчанию. После перезагрузки — все ОК.
У Вас есть свое решение!? оставьте его в комментариях)