Postgresql 1с ошибка субд
Типовые ошибки установки сервера 1С:Предприятие и PostgreSQL на платформе Linux.
Связка сервера 1С:Предприятие и PostgreSQL вторая по популярности среди установок 1С и самое используемое решение на платформе Linux. В отличии внедрений на базе Windows и MSSQL, где трудно сделать так, чтобы не заработало, внедрения на базе Linux таят множество подводных камней для неопытного администратора. Часто бывает так, что вроде бы все сделано правильно, но ошибка следует за ошибкой. Сегодня мы рассмотрим самые типовые из них.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Общая информация
Перед тем, как начинать искать ошибки установки и, вообще, приступать к внедрению серверной версии 1С:Предприятия было бы неплохо освежить представление как это работает:
В небольших внедрениях сервер 1С и сервер СУБД обычно совмещают на одном физическом сервере, что немного сужает круг возможных ошибок. В нашем случае будет рассматриваться ситуация, когда сервера разнесены по разным машинам. В нашей тестовой лаборатории мы развернули следующую схему:
Сервер баз данных не обнаружен
ВАЖНО: пользователь "postgres" не прошёл проверку подлинности (Ident)
Данная ошибка возникает при разнесении серверов по разным ПК из-за неправильно настроеной проверки подлинности в локальной сети. Для устранения откройте /var/lib/pgsql/data/pg_hba.conf, найдите строку:
и приведите ее к виду:
где 192.168.31.0/24 - диапазон вашей локальной сети. Если такой строки нет, ее следует создать в секции IPv4 local connections.
Сервер баз данных не обнаружен
could not translate host name "NAME" to address: Temporary failure in name resolution
А теперь вспоминаем, о чем было сказано несколько раньше. Клиентом сервера СУБД является сервер 1С, но никак не клиентский ПК, следовательно запись нужно добавлять на сервере 1С:Предприятие в файл /etc/hosts на платформе Linux или в C:\Windows\System32\drivers\etc\hosts на платформе Windows.
Аналогичная ошибка будет возникать, если вы забыли добавить запись типа A для сервера СУБД на локальном DNS-сервере.
Ошибка при выполнении операции с информационной базой
server_addr=NAME descr=11001(0x00002AF9): Этот хост неизвестен.
где указываете адрес и имя вашего сервера 1С:Предприятия. В случае использования локального DNS следует добавить A-запись для сервера 1С.
Ошибка СУБД: DATABASE не пригоден для использования
Если вы имеете достаточный опыт администрирования 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"
Ошибка СУБД
ERROR: type "mvarchar" does not exist at character 31
или через средство запуска 1С.
Сервер баз данных не обнаружен
ВАЖНО: пользователь "postgres" не прошёл проверку подлинности (по паролю)
Сервер баз данных не обнаружен
FATAL: database "NAME" does not exist
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
При нарушении целостности файловой системы сервера баз данных PostgreSQL, последний выдает “Ошибка СУБД” 1С, и часто сопровождается текстом, типа “ERROR: invalid page header in block ХХХХХ of relation base/ХХХХХ/ХХХХХ”.
Причиной подобных исключений может служить разрушенная файловая система и нарушение логической целостности всей базы данных, произошедшие в результате некорректного завершения работы ОС.
Выводимую 1С “Ошибка СУБД” на самом деле надо начинать исправлять не в 1С, а с проверки файловой системы. Полный алгоритм восстановления будет приблизительно следующий:
- Исправление ошибок файловой системы;
- Выявление неисправных таблиц СУБД и их ремонт;
- Проверка и исправление ошибок на уровне 1С в конфигураторе.
Если “Ошибка СУБД” в 1С произошла после некорректного завершения работы ОС, начинаем с команд Chkdsk в Windows и fsck в Linux. Это позволит устранить ошибки на уровне файловой системы.
Затем надо выяснить в каких таблицах БД PostgreSQL возникает ошибка “ERROR: invalid page header in block…”. Для этого обращаемся к логам или пытаемся снять дамп базы данных, например подключившись к СУБД утилитой pgAdmin. Если возникает ошибка “Ошибка СУБД” в 1С, наверняка найдется хотя бы 1 испорченная таблица. В моем случае ошибка возникла при дампе public._enum332.
Для того, чтобы восстановить сломанную таблицу, выполним 3 запроса:
Далее снова пытаемся снять дамп базы данных, пока база не выгрузится без ошибок.
Следующим этапом исправления ошибки СУБД в 1С будет Тестирование и исправление базы в конфигураторе 1С. Для этого запускаем испорченную БД в конфигураторе. Через пункт Администрирование – Тестирование и исправление ИБ пробуем восстановить логическую целостность нашей базы. Обратите внимание, на галочки, выбранные на изображении.
При большом количестве ошибок СУБД, 1С потребуется помощь программиста или грамотного пользователя 1С помимо системного администратора, поэтому будьте готовы к привлечению подобных специалистов.
На этом процедуру исправления ошибки PostgreSQL “ERROR: invalid page header in block…” при работе с 1С можно считать законченной, однако стоит отметить несколько пунктов, которые позволят не допустить возникновение ошибки СУБД в 1С:
Переводим БД с postgree на MS SQL.
При попытке выгрузить БД получаю ошибку Ошибка СУБД out of memory for query result.
Кто сталкивался подскажите варианты выгрузки.
Какой объем бд, железо, версии ПО?
PS Если просите помощи, прикладывайте как можно больше информации о проблеме. А то получается почти как "Ваша программа нам неправильно считает".
Тестирование и исправление базы пробовали делать?
А платформу 1С обновить не пробовали?
У нас на одной из версий платформы 8.2 такая же ошибка была с постгри
Как правильно обновить платформу?
Установил 8.2, сервер 8.2. - прописываю путь к бд - пишет БД не найдена.
Тии попробую.
(7)комп перегрузили после установки 8.2? В 8.2 новые базы создавать получается?
(9) опять же, комп перегрузили?
(10)у него не выгружается база из конфигуратора. Как он в файловую версию выгрузит то?
(11) alexbur,
Комп перезагрузил, новые бд создаются а эту не видит зараза.
Может у кого есть conf файл норм настроенный - поделитесь. все таки мне кажется проблема в нем.
Еще одну вещь заметил БД выгружается, но как только начинается операция сохранения в файл вываливается ошибка.
(13)Какой именно текст ошибки выдает при попытке выгрузки базы из postgre? на какую-нибудь таблицу ссылается?
У нас не выгружается типовая база УПП, ругается на таблицу public.config. Проблема решается отвязкой конфы от поддержки, но нас это решение не устраивает.
(14) alexbur,
через постгри выгружается без ошибок.
Но вот если потом загрузить в пустую базу(восстановить) - то база выдает разные ошибки и ни конфигуратор, ни клиент не грузятся..
(15) на всякий случай тормозните postgre и сохраните каталог в котором база храниться. Сделайте техобслуживание базы в pgadmin (analyze, vacuum, reindex) может выдаст какие-нибудь ошибки
Может быть уже имеет смысл думать о том, чтобы вытащить инфу другим путем? К примеру, создать пустую базу с такой же конфой и перетащить в неё данные с помощью обработки "Универсальный обмен данными черех XML". Не самый плохой путь, на мой взгляд.
(17) alexbur,
Это крайний вариант так как на этой бд у нас РИБ + обмены с сайтами(2 штуки)
Это все полетит в данном случае.
конф файл был стандартный - ошибка и на нем была, сейчас я уже влез в него прилично, но успехов пока нет. Все таки надеюсь что получится стандартными средствами выгрузку сделать.
А если я подниму эту же версию постгри на сервере и скопирую туда папку постгри - он увидит БД. Может на болле мощной машине получится выгрузить.
(22) kliman, не факт что слетит. Универсальный обмен данными в формате xml при загрузке формирует объекты БД с теми же уникальными идентификаторами что и в исходной БД. При повторной выгрузке/загрузке информация не дублируется, а "ложится" на нужные объекты.
РИБ использует тот же самый механизм при обмене. Скорее всего при первом обмене придётся перегрузить весь объём инфы, но, во всяком случае, я бы повел эксперимент.
(14) alexbur, дак снимай с поддержки - загрузи в СКУЛь - потом "загрузить конф. из файла", правда какие-нибудь аналитики могут пропасть.
(20) Мне это незачем, т.к. dt файл из конфигурации прекрасно выгружается. А если снять с поддержки и потом загрузить конфу из файла, то проблема выгрузки из postgre возвращается.
Так что пока обхожусь бэкапами из конфигуратора и подумываю о переходе на x64 postgre.
(19)дык я об это же говорил в (17). Кстати, а какого плана горе может возникнуть при проведении?
(13) Конф файл настраивается индивидуально под каждую конфигурацию - та ещё пляска с бубном.
Возможно имеет смысл наоборот попробовать выгрузить со стандартным конф файлом. Или он у вас изначально стандартный был?
в интернете нашел что у кого-то помогло установка значений
work_mem = 64MB
maintenance_work_mem = 256MB
проставил галочки в конф файле, перезапустил.
Если захожу в конф файл там в значение верное знач, а в текущем значение другие цифры.
Что за колонка текущее значение?
есть вариант с выгрузкой данных в идентичную конфигурацию(на ИТСе есть обработки), если получится в СКУЛе в чистой базе развернуть .cf, то переноси данные через обработки, только галочку "выгружать движения" поставь, иначе при проведении горя хапнешь.
Когда-то давно задавал вопрос на партнерском форуме 1С, а сейчас решил выложить в общий доступ.
Исходные данные:
Платформа: 1С:Предприятие 8.1 (8.1.15.14)
Кофигурация: БП 1.6.24.7 (Конфигурация типовая, на поддержке). Ситуация может воспроизвестись на любой конфигурации.
Сервер СУБД: Postgres 8.3.8 (сборка 1с)
ОС: Debian Lenny 5.0 (Linux 2.6.26-2-686-bigmem i686 GNU/Linux)
Физ: на сервере 8Гб памяти, параметры остального оборудования думаю не критичны.
Воспроизводимость 100%
При закрытии месяца вылетает с ошибкой: Ошибка СУБД. ERROR: Out of memory. DETAIL: Failed on request size 8388608
enable_mergejoin=off (в .conf файле или через SET в консоли/PgAdmin)
Проблема в оптимизаторе, который выбирает неудачный план(merge join), требующий большого объема памяти и большого времени для выполнения запроса.
«If the default plan chosen by the optimizer for a particular query is not optimal, a temporary solution can be found by using one of these configuration parameters to force the optimizer to choose a different plan. Turning one of these settings off permanently is seldom a good idea, however. «
Что такое mergejoin? Алгоритм соединения слиянием сортированных списков (merge join, sort merge join, sort-merge join) — разновидность алгоритма соединения. Алгоритм получает на вход 2 таблицы и условие соединения. Результатом его работы является таблица с результатами соединения. Главным недостатком алгоритма является необходимость в предварительной сортировке списков. Накладные расходы на сортировку могут быть неприемлемо высокими.
(26) Да, решить удалось на этих выходных. Перенес Постгри полностью на новый сервер(64 и и хороший по производительности) и на нем удалось произвести выгрузку в dt. Все таки дело в ресурсах. С постгри больше не работаю)
(28) перенес dump, каталоги не получилось перенести. Загрузить дамп получилось(архив не меняли) раза с 5, до этого сыпались какие-то ошибки. причем каждый раз разные.
Спешу поделиться решением проблемы. Недавно перевел 1с из файлового варианта в SQL, при этом решил использовать PostgreSQL. По началу, при попытки выгрузить базу в .dt файл, вылетала ошибка "Соединение разорвано и чего-то там еще. ". Платформа 1с была 8.2.19.68, в тех. поддержке посоветовали поставить более старую версию (установил 8.2.18.61), ошибка исчезла, но появилась другая "Ошибка СУБД out of memory for query result". Перекопал весь интернет, пробовал различные советы, но ничего не помогало. Исходя из текста ошибки, я понял что программе не хватает памяти, но вот только какой?! На сервере стоит Win2008srv c 8Гб оперативной памяти (вроде должно хватать), но вот в настройках Windows виртуальная память выбирается автоматом, при этом если у вас два раздела (C и D), то на диске D файл подкачки отключен по умолчанию. А так как у меня все базы находятся на диске D, и размер базы 1с составляет порядка 1,5 Гб, то для того чтобы её выгрузить в файл .dt необходимо было включить использование файла подкачки с параметром "по выбору системы" и будет вам счастье.
Спешу поделиться решением проблемы. Недавно перевел 1с из файлового варианта в SQL, при этом решил использовать PostgreSQL. По началу, при попытки выгрузить базу в .dt файл, вылетала ошибка "Соединение разорвано и чего-то там еще. ". Платформа 1с была 8.2.19.68, в тех. поддержке посоветовали поставить более старую версию (установил 8.2.18.61), ошибка исчезла, но появилась другая "Ошибка СУБД out of memory for query result". Перекопал весь интернет, пробовал различные советы, но ничего не помогало. Исходя из текста ошибки, я понял что программе не хватает памяти, но вот только какой?! На сервере стоит Win2008srv c 8Гб оперативной памяти (вроде должно хватать), но вот в настройках Windows виртуальная память выбирается автоматом, при этом если у вас два раздела (C и D), то на диске D файл подкачки отключен по умолчанию. А так как у меня все базы находятся на диске D, и размер базы 1с составляет порядка 1,5 Гб, то для того чтобы её выгрузить в файл .dt необходимо было включить использование файла подкачки с параметром "по выбору системы" и будет вам счастье.
(31)Спасибо совет помог. Но есть еще одна проблемка на другой машине. При выгрузке dt ошибка субд server closed connection unexpectedly
This problems means the server terminated abnormally before or while processing the request.
Такая же ерунда. Ничего не помогло :( Сделал дамп из PG. На локальной машине с Виндой развернул 1с сервер и PG, дамп закинул туда и через конфигуратор выгрузил ИБ.
(34) Ну вот не факт что поможет.
На текущий момент имею тестовую виртуалку под CentOS 7 + PostgresPRO 9.6 + 1C sever x32 - 8.3.10.2580
База УТ 10.3, вес в слоне 22Gb. В виртуалке 8Gb памяти, 2cpu по 6core.
При попытке выгрузить в dt выпадает с ошибкой Out of memory. Хотя память в виртуалке отъедалась максимум в районе половины.
Благо это все эксперименты и можно поиграться. Все что выше советовалось - не помогает. Пока играюсь и смотрю.
Плюс заметил глюк этой версии платформы под CentOS:
Грузил dt этой базы (9,3Гб). Толстым клиентом подсоединялся к 1С серверу на этой виртуалке. И начинаю загрузку. По поведению системы вижу, что dt туда перекачался, и пошла закачка базы в postgres. После заливки примерно 1,3Gb конфигуратор выдает ошибку, что (кратко): "Не все данные загружены. Ошибка формата потока."
Тесты, настройки, чпоки, эксперименты с настройками Postgres и 1С сервер на этой машине ничего не дали.
Делаю следующее: У себя на виндовой машине поднимаю туже версию 1С сервера (и тоже х32), создаю тестовую базу и в качестве СУБД указываю тот же Postgres в той тестовой виртуалке. Заливаю dt и вулая! База залилась без ошибок!
Т.е. есть какой-то глюк в платформе.
Вот в качестве эксперимента по той же схеме запустил выгрузку dt. В итоге в CentOS занято чуть меньше 1,7Гб. По активности сети вижу, что база интенсивно льется на мой компьютер через 1С сервер на моем компьютере. Ошибки пока не выпадало. Будем посмотреть.
UPD: Тоже упало с ошибкой out of memory. Хотя памяти при этом на сервер до опы свободной.
Ну собственно, потыкавшись и помыкавшись, посмотрев за памятью, пришел к выводу, что PostgreSQL тут как бы не причем.
rphost давится. 32-битный процесс доходит до своего предела в 3,5 гига озу и все. после этого резкое высвобождение памяти и в последующем нелюбимая ошибка Out of memory.
Установа х64 1C сервера и последующая повторная выгрузка прошли без проблем.
В процессе наблюдения за поведением x64 rphost, было видно, что потребление памяти процессом доходило до 4,5 Гигабайт. Причем несколько раз.
Интересно, почему та же база, на х32 1C сервере в сочетании с MSSQL не дает такого эффекта?
А вот c PostgreSQL такое наблюдаю постоянно?
Тоже была такая проблема. Мне помог перезапуск службы сервера 1С. Но на огромных базах такое решение скорее всего не поможет, но почему бы не попробовать?
В настройках 1С сервера 32х Свойства рабочего сервера - количество ИБ на процесс. Было 8, сделал 1. Помогло без перезапуска 1С сервера и постгри.
Была точно такая проблема, ничего не помогло из того что тут написано.
Но помогло вот что: в postgresql.conf параметр shared_buffers снизил в разы.
привет коллеги
после обновления с 8.3.16 до 8.3.18.1128 c базами на postgrespro 12.1 получил "Ошибка СУБД: DATABASE не пригоден для использования.", в логах постгреса пусто.
проверил работу 8.3.18 с базами на postgres9.6 все работает.
Откатился до 8.3.16 и с postgrespro 12.1 все заработало.
пока собираем стенд для поиска решения, если кто знает как решить, буду очень признателен
PostgreSQL 12.5
PostgreSQL 12.4
PostgreSQL 12.3
PostgreSQL 11.10
PostgreSQL 11.9
PostgreSQL 11.8
PostgreSQL 11.7
PostgreSQL 11.5
Если при попытки создать баз данных 1С на PostgreSQL
появляется ошибка: DATABASE не пригоден для использования
В файле настроек сервера (в windows он находится********\postgresql.conf)
разкомментируем и отредактируем следующие строки:
backslash_quote = on
escape_string_warning = off
standart_conforming_strings = off
Перезапускаем конфигурацию, должно работать.
(3)
а вы чистую базу создавали ?
1.средствами 1с
2.постгресом
в общем решение найдено и если кратно, то установка 12.4.1 поверх 12.1 решила проблему и проверено 8.3.16 и 8.3.18 работают с 12.4.1
интересно что
- 8.3.16 + 12.1 работает
- 8.3.18 + 12.1 НЕ работает
- 8.3.18 + 12.4.1 после обновлением работает
- 8.3.18 + с той же базой после обновления с откатом субд до 12.1 РАБОТАЕТ!, но при этом вновь создаваемые базы не работают.
вероятно изменения касаются самой структуры таблиц база данных
еще немного потестируем и будем планировать обновление рабочего сервера
(6)Это не решение, а удачное стечение обстоятельств.
Данная ошибка может возникать, если поставили постргес на нестандартном порту.
Для подключения к базе или при создании новой базы надо писать в имени сервера конструкцию типа такой:
localhost port=5433
(7) хммм не соглашусь, проблема повторилась еще несколько раз, и каждый раз этот подходи привел к ее решению, а значит это вполне себе решение )
darkultro37: Не совсем по теме, но решение использовать 8.3.18 принципиально? Первый релиз в новой ветке всегда был сыроватым.
При обновлении базы данных произошел сбой. Не создались таблицы в POstgresql под вновь созданные объекты. В результате при любом обращении к этим объектам вываливалась ошибка типа: "Ошибка СУБД:
ERROR: relation "_infor22964_bydims_rrr" does not exist". Поиски в инете практически ни к чему не привели.
Итак, начнем. Это был ничем не приметный день, кроме того что это был понедельник. По плану было дотянуть до конца рабочего дня и поставить обновление на УПП, в котором должны появиться новый бизнесс процес, константа, и 3 дополнительных регистра сведений. Установку решил проводить "из дома" по удаленномму соединению, т.к. продажники работают до-поздна.
При установке обновления решил не терять времени, поставить обновление конфигурации до того, как все выйдут из базы данных, потом выгнать всех и обновить конфигурацию базы данных. После того, как выгнал пользователей - сделал самый большой прокол в этом дне, последствия которого пришлось разгребать в течении 5-ти часов - не сделал бэкап базы данных.
После обновления базы данных решив заполнить вновь созданные регистры зашел в режим отладки. При открытии формы списка регистра вывалилась ошибка типа "Ошибка СУБД: ERROR: relation "_infor22964_bydims_rrr" does not exist". и предложения: завершить работу и перезапустить.
Первым делом я конечно решил вернуть конфигурацию к первоначальному состоянию. НО в момент обновления конфигурации базы данных вываливалась та же ошибка "типа не найдена таблица и отвали".
Вторым этапом было связаться с администратором сервака и попросить его сделать откат на часик - другой. Одмина пришлось ждать и нервничать ок 2 часов - ибо он ужинал. После окончания ужина узнал, что у него средствами Postgresql делается один архив в сутки, и менно тогда жеж когда у меня делается архив средствами 1С.
Я был практически в отчаинии. Догадывался что работатьна базе можно, но будут проблемы с дальнейшим написанием и обновлением. и с этим надо что-то делать.
Итак в качестве третьего этапа рассматривались следующие варианты: восстановление утреннего архива и перенос документов с помощью типовой обработки "ВыгрузкаЗагрузкаXML", что идет в составе "Конвертации данных" и тестирование и исправление. К тому жеж я задумался над созданием позднего архива. Сразу скажу, что архив не создался, вывалив ту же ошибку.
Вариант с переносом данных решил отложить, ибо "это может быть потраченное впустую время", и ХЗ какой период документов сегодня правила наша "родная" бухгалтерия. И я решил обратиться к просторам инета. Самой полезной инфой было: http://www.forum.mista.ru/topic.php?id=393749&page=1 где мне пришлась по душе идея "исправления таблиц базы данных средствами SQL".
Третий этап, он жеж конечный: "исправления таблиц базы данных средствами SQL".
Теперь расскажу, что мне потребовалось: мне потребовалось сделать восстановление аврхива в базу данных SQL, и установить на компе утилиту "PGAdmin III".
Архивную базу данных я обновил до последнего состояния рабочей базы. Оказалость, что количество таблиц при "нормальном обновлении" на восстановленном архиве на 5 шт. превышало количество таблиц на рабочей базе. из чего я сделал вывод что при обновлении рабочей базы не создалось 5 таблиц. Оставалось найти их и создать вручную. Не смотря на то что на указаном выше форуме прочитал, что при восстановлении базы данных могут создаться таблицы с другими именами, моя практика показала полное совпадение имен рабочей базы и восстановленной. Проблема была в том, что необходимо было найти эти таблицы из 3500 шт. не зная языка SQL.
В итоге, я нашел и создал 5 таблиц недостающих. У меня конфигурация "вернулась в исходное состояние". После этого я сделал архив БД средствами 1С, и повторно выполнил обновление, которое прошло успешно.
Вот так я вышел из сложившегося положения, больше НИКОГДА не буду забывать/забивать делать архив перед обновлением.
Читайте также: