Home » 1C » Ошибка type mvarchar does not exist при создании базы 1С в PostgreSQL

Ошибка type mvarchar does not exist при создании базы 1С в PostgreSQL

Столкнулся с неприятной ошибкой во время работы с сервером администрирования 1С в связке с PostgreSQL. Сразу скажу, что данная связка сулит много нюансов и подводных камней, так что без крайней необходимости не рекомендую с ней связываться, если нет хорошего опыта работы с postgresql. Либо придется учиться по ходу дела.

Суть проблемы вот в чем. Я установил postgresql 10 от postgresqlpro примерно по той же схеме, что описана у меня в статье про установку и настройку postgresql для работы с 1с. После установки выполнил инициализацию кластера простой командой:

# pg-setup initdb

Затем из дампа залил базу и какое-то время все это без проблем работало. Потом стало нужно создать новую базу. Я создал через консоль postgresql базу:

$ create database panda with owner = usr1cv8 ENCODING = 'UTF8' LC_COLLATE = 'ru_RU.UTF-8' LC_CTYPE = 'ru_RU.UTF-8';

И пошел создавать базу через панель администрирования 1с. У меня этого не получилось, вылезла ошибка.

Ошибка при создании информационной базы:
Ошибка операции администрирования
Ошибка СУБД: 
ERROR: type "mvarchar" does not exist 
LINE 1: create table Config (FileName mvarchar(128) not null, Creati...^

ERROR: type "mvarchar" does not exist

Начал искать информацию на эту тему. Понял, что создавать базу из консоли нельзя, необходимо это делать через панель администрирования 1С. ОК, удалил базу через консоль:

$ drop database panda;

Пошел в панель администрирования, но создать базу не получилось. К сожалению, не заскринил ошибку. Но суть в том, что база создавалась не в той кодировке. Сейчас поясню. Смотрим список баз на сервере:

root@sql:/opt/pgpro/1c-10/bin# ./psql -U postgres -l
                                   Список баз данных
    Имя     | Владелец | Кодировка | LC_COLLATE  |  LC_CTYPE   |     Права доступа     
------------+----------+-----------+-------------+-------------+-----------------------
 enterprise | usr1cv8  | UTF8      | ru_RU.utf8  | ru_RU.utf8  | =Tc/usr1cv8          +
            |          |           |             |             | usr1cv8=CTc/usr1cv8
 panda      | usr1cv8  | UTF8      | en_US.UTF-8 | en_US.UTF-8 | 
 postgres   | postgres | UTF8      | en_US.UTF-8 | en_US.UTF-8 | 
 template0  | postgres | UTF8      | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
            |          |           |             |             | postgres=CTc/postgres
 template1  | postgres | UTF8      | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
            |          |           |             |             | postgres=CTc/postgres

База enterprise была залита из дампа и имеет правильную кодировку. Базу panda создает 1С через консоль администрирования, и у нее кодировка LC_COLLATE и LC_CTYPE en_US.UTF-8, а должна быть ru_RU.UTF-8. Это при том, что консоль сервера в момент настройки postgresql была правильная.

# locale
LANG=ru_RU.UTF-8
LANGUAGE=
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=

Я думал, что пропатченой сборки postgresql и нужной консоли достаточно, чтобы все было в порядке с кодировкой. Но ошибся. Раньше не припоминаю, чтобы сталкивался с подобной ошибкой. Получается, я попал в тупик. Я могу руками создать базу данных с нужными кодировками, но она не будет работать, так как 1С должна базу создать сама. Если же я создаю базу через 1С, выбираются дефолтные шаблоны с неподходящей кодировкой и ничего не работает.

Я нашел один вариант решения — проинициализировать заново кластер, явно указав кодировки:

# initdb --locale=ru_RU.UTF-8 --lc-collate=ru_RU.UTF-8 --lc-ctype=ru_RU.UTF-8 --encoding=UTF8

Как я понял, все текущие базы дропнутся. Возможно понял не правильно, но проверять не захотелось, так как текущая база там на 80 гигов и заливать дамп очень долго. Нашел другой способ — замена шаблона. Вот последовательность действий в консоли postgresql для удаления текущего шаблона и создания нового с нужными кодировками.

$ update pg_database set datistemplate = false where datname='template1';
$ drop database template1;
$ create database template1 ENCODING = 'UTF8' LC_COLLATE = 'ru_RU.UTF-8' LC_CTYPE = 'ru_RU.UTF-8' template=template0;
$ update pg_database set datistemplate = true where datname='template1';

После этого получилось через консоль 1С создать базу и начать с ней работать. Список баз стал выглядеть вот так:

root@sql:/opt/pgpro/1c-10/bin# ./psql -U postgres -l
                                   Список баз данных
    Имя     | Владелец | Кодировка | LC_COLLATE  |  LC_CTYPE   |     Права доступа     
------------+----------+-----------+-------------+-------------+-----------------------
 enterprise | usr1cv8  | UTF8      | ru_RU.utf8  | ru_RU.utf8  | =Tc/usr1cv8          +
            |          |           |             |             | usr1cv8=CTc/usr1cv8
 panda      | usr1cv8  | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | 
 postgres   | postgres | UTF8      | en_US.UTF-8 | en_US.UTF-8 | 
 template0  | postgres | UTF8      | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
            |          |           |             |             | postgres=CTc/postgres
 template1  | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | 

Ошибок больше не было.

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

Помогла статья? Есть возможность отблагодарить автора

12 комментариев

  1. Владимир

    Хорошее описание и дебаг, но по сути при установке posgresql под 1С нужно инициализировать базу сразу с русской локалью, достаточно команды — initdb —locale=ru_RU.UTF-8 =)
    хорошая статья на инфостарте, с нее сделал краткую выдержку, по которой развернул уже около 7 серверов.

    По поводу проблем, они всегда появляются если сам не в теме, а статья в интернете написано не ахти =( в цело за 2 года полет нормальный, проблемы бывают, но редко и как правило все исправляются. А переходил спешно буквально за неделю с W2K8 + MSSQL без предварительного изучения темы.

    п.с. ничего не типичного у меня не настроено, по этому для каких то конфигураций естественно будет геморрой, а для каких переход не представляется возможным.
    п.п.с. и у меня норм создаются базы командой «createdb -U user database».
    п.п.п.с. и если какая-то проблема с «консолью кластера», то можно с сервера 1с управлять, для этого есть rac\ras.

    • Я когда 9-ю версию настраивал, специально в консоли инициализацию кластера не делал. Либо просто забыл об этом написать. Я всегда шпаргалки оставляю по тем вещам, которые настраиваю. Думал, это в сборке под 1С уже предусмотрено, и кластер сам инициализируется при запуске с нужными параметрами.

      В целом, у меня тоже работают базы под postgresql. Причем первые тестовые запуски я делал еще лет 6 назад. Оно и тогда работало. Как бонус — кластер 1С на линуксе даже лицензию не просил. Сейчас не знаю как. Но возни с этими базами больше, плюс непредсказуемая производительность. Иногда то, что на mssql работает нормально, на postgres начинает сильно тормозить и работать раз в 10 медленнее. Разобраться в чем проблема стоит немалых усилий. Потом еще программисту надо в код лезть и исправлять.

      • Пока что еще действует пряник от 1С, что под линуксом 1С сервер до 12 подключений не треьует лиценщию на сервер. Но это не значит, что запущенный сервер лицензионный

  2. И как 10 версия? Более стабильная?
    Вы используете сборки только от 1С?
    Стандартные не будут работать?
    Спасибо.

    • Я настраивал от postgrespro сборку. По производительности разницы с 9-й версией не заметили. База была достаточно большая — 80-90 гигов. Несмотря на то, что переехали вместе с 10-й версией на более мощное железо, производительность не изменилась. Не знаю почему, особо не тестировал.

      • Неужели невозможно обосновать руководству приобретение MS SQL? К тому же, есть версия MS SQL заточенная только под 1С, соответственно ценник на нее ниже.

        • Если postgresql отвечает на поставленную задачу, то я сам не понимаю, зачем платить больше. Реально, многим этого достаточно. В основном это небольшие компании, где с 1С работает человек 10. Там затраты на mssql, а с ним и windows server будут существенными.

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

          • Я в курсе. НО, что дешевле время простоя + время специалиста(который мог бы заниматься другими проблемами)? Выведите формулу и посчитайте(просто для себя хотя бы). А на поставленную задачу может отвечать даже IBM DB2.
            PS Это не критика, не претензия.

            • Таким компаниям, чаще всего, простой даже в пол дня — день не критичен. Postgresql вполне имеет право на жизнь и актуальна во многих кейсах. Я тут не категоричен и сам все прикидывал.

  3. А если ли у Вас шпаргалка для наблюдения за PostgreSQL с помощью Zabbix?
    Пытался интегрировать в Zabbix шаблоны по https://github.com/pg-monz/pg_monz,
    но не получилось. Было бы интересно узнать про Ваш опыт.
    Спасибо.

    • Нет, не занимался никогда. Мониторинг БД не тривиальная задача. Я не очень много работал именно с тюнингом и анализом работы БД. А сам по себе мониторинг БД снижает ее производительность. Я мониторю бд по косвенным признакам — общие параметры работы сервера, нагрузка на диски. Вглубь, в запросы не смотрю, так как почти не разбираюсь в sql. Могу только простенькие запросы писать.

  4. Пгстатистика же есть искаробки

Добавить комментарий

Ваш e-mail не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.