1c postgresql mchar control не найден
Оптимизация производительности PostgreSQL для работы с 1С:Предприятие
PostgreSQL приобретает все большую популярность как СУБД для использования в связке с 1С:Предприятие. При этом одним из самых частых нареканий является низкая производительность этого решения. Во многом это связано с тем, что настройки PostgreSQL по умолчанию не являются оптимальными, а обеспечивают запуск и работу СУБД на минимальной конфигурации. Поэтому имеет смысл потратить некоторое количество времени на оптимизацию производительности сервера, тем более что это не очень сложно.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Существуют разные рекомендации по оптимизации PostgreSQL для совместной работы с 1С, мы будем опираться на официальные рекомендации, изложенные на ИТС, также можно использовать онлайн-калькулятор для быстрого расчета некоторых параметров. Если данные калькулятора и рекомендации 1С будут расходиться - то предпочтение будет отдано рекомендациям 1С.
Для тестирования мы использовали систему:
- CPU - Core i5-4670 - 3.4/3.8 ГГц
- RAM - 32 ГБ DDR3
- Системный диск - SSD WD Green 120 ГБ
- Диск для данных - 2 х SSD Samsung 860 EVO 250 ГБ - RAID1
- СУБД - PostgresPro 11.6
- Платформа - 8.3.16.1148
- ОС - Debian 10 x64
Прежде всего выполним тестирование с параметрами по умолчанию:
Полученный результат - 22,32 по Гилеву высоким не назовешь, для субъективного контроля мы использовали конфигурацию Розница 2.2 с базой реального торгового предприятия объемом в 8 ГБ, в целом работу можно было признать удовлетворительной, но местами наблюдалась некоторая "задумчивость", особенно при открытии динамических списков.
Перейдем к оптимизации. Все изменения следует вносить в файл postgesql.conf, который располагается в Linuх для сборки от 1С по пути /etc/postgres/1x/main, а для сборки от PostgresPro в /var/lib/pgpro/1c-1x/data. В Windows данный файл располагается в каталоге данных, по умолчанию это C:\Program Files\PostgreSQL 1C\1х\data. Все параметры указаны в порядке их следования в конфигурационном файла.
Одним из основных параметров, используемых при расчетах, является объем оперативной памяти. При этом следует использовать то значение, которое вы готовы выделить серверу СУБД, за вычетом ОЗУ используемой ОС и другими службами, скажем, сервером 1С. В нашем случае будет использоваться значение в 24 ГБ.
Затем рассчитаем значения отдельных параметров с помощью калькулятора, для чего укажем ОС и версию Postgres, тип накопителя, количество доступной памяти и количество ядер процессора. В поле DB Type указываем Data Warehouses, количество соединений можем проигнорировать, так как вычисляемый результат будет значительно расходиться с рекомендациями 1С.
Теперь можно приступать к редактированию файла конфигурации. Многие значения в нем закомментированы и содержат значения по умолчанию, при изменении таких параметров данные строки следует раскомментировать.
Максимальное число соединений, 1С рекомендует указанные выше значения, мы установили 1000.
Объем памяти для совместного кеша страниц, разделяется между всеми процессами Postgres, рекомендуемое значение - четверть доступного объема памяти, в нашем случае 6 ГБ.
Верхний лимит для временных таблиц в каждой сессии, рекомендуется фиксированное значение.
Указывает объем памяти, который может быть использован для запроса прежде, чем будут задействованы временные файлы на диске. Применяется для каждого соединения и каждой операции, поэтому итоговый объем используемой памяти может существенно превосходить указанное значение. Это один из тех параметров, вычисляемое значение которого калькулятором существенно отличается от рекомендаций 1С. Для объема памяти в 24 ГБ рекомендуемыми значениями будут 375 - 750 МБ, мы выбрали 512 МБ.
Объем памяти для обслуживающих задач (автовакуум, реиндексация и т.д.), указываем рекомендованный калькулятором объем, в нашем случае 2 ГБ.
Максимальное количество открытых файлов на один процесс, в сборке от PostgresPro для Linux это значение по умолчанию.
Параметры процесса фоновой записи, который отвечает за синхронизацию страниц в shared_buffers с диском.
Допустимое число одновременных операций ввода/вывода. Для жестких дисков указывается по количеству шпинделей, для массивов RAID5/6 следует исключить диски четности. Для SATA SSD это значение рекомендуется указывать равным 200, а для быстрых NVMe дисков его можно увеличить до 500-1000. При этом следует понимать, что высокие значения в сочетании с медленными дисками сделают обратный эффект, поэтому подходите к этой настройке грамотно.
Важно! Параметр effective_io_concurrency настраивается только в среде Linux, в Windows системах его значение должно быть равно нулю.
Настройки фоновых рабочих процессов, выбираются исходя из количества процессорных ядер, берем значения из калькулятора. Выше указаны настройки для четырехъядерного СРU.
Заставляет сервер добиваться физической записи изменений на диск. Выключение данной опции хотя и позволяет повысить производительность, но значительно увеличивает риск неисправимой порчи данных при внезапном выключении питания.
Альтернатива отключению fsync, позволяет серверу не ждать сохранения данных на диске, прежде чем сообщить клиенту об успешном завершении операции. Позволяет достаточно безопасно повысить производительность работы. В случае внезапного выключения питания могут быть потеряны несколько последних транзакций, но сама база останется в рабочем состоянии, также, как и при штатной отмене потерянных транзакций.
Задает размер буферов журнала предзаписи (WAL, он же журнал транзакций), если оставить эту настройку без изменений, то сервер будет автоматически устанавливать это значение в 1/32 от shared_buffers, но не менее 64 КБ и не более размера одного сегмента WAL в 16 МБ.
Указывает задержку в мс перед записью транзакций на диск при числе открытых транзакций, указанных во второй опции. Имеет смысл при количестве транзакций более 1000 в секунду, на меньших значениях эффекта не имеет.
Минимальный и максимальный размер файлов журнала предзаписи. Указываем значения из калькулятора, в нашем случае это 4 ГБ и 16 ГБ.
Скорость записи изменений на диск, рассчитывается как время между точками сохранения транзакций (чекпойнты) умноженное на данный показатель, позволяет растянуть процесс записи по времени и тем самым снизить одномоментную нагрузку на диски. В нашем случае использовано рекомендованное калькулятором максимальное значение 0,9.
Стоимость последовательного чтения с диска, является относительным числом, вокруг которого определяются все остальные переменные стоимости, данное значение является значением по умолчанию.
Стоимость случайного чтения с диска, чем ниже это число, тем более вероятно использование сканирования по индексу, нежели полное считывание таблицы, однако не следует указывать слишком низких, не соответствующих реальной производительности дисковой подсистемы, значений, иначе вы можете получить обратный эффект, когда производительность упрется в медленный случайный доступ.
Так как это относительные значения, но не имеет смысла устанавливать random_page_cost ниже seq_page_cost, однако при применении производительных SSD имеет смысл понизить стоимость обоих значений, чтобы повысить приоритет дисковых операций по отношению к процессорным.
Для производительных SSD можно использовать значения:
Но еще раз напомним, данные значения не являются панацеей и должны устанавливаться осмысленно, с реальным пониманием производительности дисковой подсистемы сервера, бездумное копирование настроек способно привести к обратному эффекту.
Определяет эффективный размер кеша, который может использоваться при одном запросе. Этот параметр не влияет на размер выделяемой памяти, не резервирует ее, а служит для ориентировочной оценки доступного размера кеша планировщиком запросов. Чем он выше, тем большая вероятность использования сканирования по индексу, а не последовательного сканирования. При расчете следует использовать выделенный серверу объем RAM, а не полный объем ОЗУ. В нашем случае это 18 ГБ.
Включение автовакуума, это очень важный для производительности базы параметр. Не отключайте его!
Количество рабочих процессов автовакуума, рассчитывается по числу процессорных ядер, не менее 4, в нашем случае 4.
Время сна процессов автовакуума, большое значение будет приводить к неэффективно работе, слишком малое только повысит нагрузку без видимого эффекта.
Отключает политику защиты на уровне строк, данная опция не используется платформой и ее отключение дает некоторое повышение производительности.
Максимальное количество блокировок в одной транзакции, рекомендация от 1С.
Данные опции специфичны для 1С и регулируют использование символа \ для экранирования.
Сохраним файл конфигурации и перезапустим PostgreSQL, в Linux это можно выполнить командами:
В Windows штатными средствами операционной системы, либо скриптами из поставки сборки PostgreSQL:
После чего снова выполним тестирование производительности, на этот раз мы получили следующий результат:
Как видим, достаточно несложные действия по оптимизации добавили серверу около 30% производительности, субъективные ощущения от работы с конфигурацией Розница также повысились, исчезло ощущение "задумчивости", повысилась отзывчивость системы.
Указанные выше настройки и параметры являются базовым набором для оптимизации PostgreSQL при совместной работе с 1С:Предприятие и доступны даже начинающим администраторам. Для выполнения этих действий не требуется глубокого понимания работы СУБД, достаточно просто правильно рассчитать ряд значений. Данные рекомендации основаны на официальных и рекомендуются в качестве базовой настройки сервера СУБД сразу после инсталляции.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Делал бекап с работающей базы 1С с помощью pgadmin4, при восстановлении на другом сервере возникли ошибки:
(версии 1С(8.3.15.1565,x64) и PostgresSQL(PostgresPro_1C_9.6.8_64bit_1C) на серверах одинаковые)
Пытаюсь войти туда из 1С, выдает ошибку:
Error: operator does not exist: mvarchar = unknown
Если создаю чистую базу из 1С и пытаться восстановить pgadmin-ом бекап в эту базу, то появляются такие ошибки:
Решил проблему, хорошо что была точно такая же, рабочая, пустая база.
Я преобразовал бекап в sql код, сравнил два бекапа, пустой и проблемный, заменил где-то 150 раз слово FUNCTION
на слово PROCEDURE в проблемном дампе и все заработало.
Вот лог сравнения, если интересно:
Так вроде бы данные залились в систему, проблемы возникли только с индексами и приведенными типами.
Не совсем понятно, что Вы имеете ввиду под "Пытаюсь войти туда из 1С, выдает ошибку". Вы добавили базу в консоли?
Лично я бы создал новую базу из 1С (пустую) и загрузил бы туда бэкап тем же методом, которым выгрузил его. Главное, чтобы все данные попали в бэкап. Я для небольших баз приводил скрипты сохранения и развертывания здесь .
>>Не совсем понятно, что Вы имеете ввиду под "Пытаюсь войти туда из 1С, выдает ошибку". Вы добавили базу в консоли?
Запускаю ярлык 1С Предприятие, добавляю базу через кнопку Добавить, после жму или кнопку 1С Предприятие или Конфигуратор и после этого появляется ошибка, т е в базу зайти и работать нельзя.
>>Лично я бы создал новую базу из 1С (пустую) и загрузил бы туда бэкап тем же методом, которым выгрузил его. Главное, чтобы все данные попали в бэкап. Я для небольших баз приводил скрипты сохранения и развертывания здесь.
Первый раз я просто залил бекап через pgadmin в только что созданную мной пустую базу, а второй раз я создал пустую базу из 1С и залил в нее бекап через pgadmin,
но зайти допустим в Конфигуратор нельзя ни в первом случае ни во втором.
(1)
Ели ошибки при восстановлении на другом сервере, то попробуйте восстановить на том, где выгружали
>> Ели ошибки при восстановлении на другом сервере, то попробуйте восстановить на том, где выгружали
К сожалению не могу, это был арендованный сервер, мы от него отказались(
(5)
Может перед тем как отказываться, надо было проверить работоспособность копии? Есть полная уверенность в отсутствии защиты базы от переноса? Если нет, то арендуйте его еще на сутки, но только проверьте в этот раз
>> Может перед тем как отказываться, надо было проверить работоспособность копии?
Работоспособность основной копии проверил, а этой нет.
>> Есть полная уверенность в отсутствии защиты базы от переноса?
Да, эту базу мне дал 1С программист, там нет защиты.
>> Если нет, то арендуйте его еще на сутки, но только проверьте в этот раз
Перед тем как отдавать сервер я удалил все данные спец программой, без возможности восстановления.
(7)
"Работоспособность основной копии проверил, а этой нет.", ну как же ж так
"Да, эту базу мне дал 1С программист, там нет защиты." не вижу связи в этих двух выражениях, то что ее дал 1с ник этого не означает
"Перед тем как отдавать сервер я удалил все данные спец программой, без возможности восстановления", а вот это до разворачивания и проверки нового было совсем зря
>> "Да, эту базу мне дал 1С программист, там нет защиты." не вижу связи в этих двух выражениях, то что ее дал 1с ник этого не означает
1С-ник предупредил бы если бы база была с защитой
(9)
Я не утверждаю, что защита есть, но если ее нельзя отвергать, то надо было этот факт проверить до отключения от старого сервера
>> Я не утверждаю, что защита есть, но если ее нельзя отвергать, то надо было этот факт проверить до отключения от старого сервера
Спросил, говорит что защиты нет.
(12)
Значит ищем причину дальше, версии поста и 1с абсолютно те же, что и на старом? Битность серверов та же?
>> Значит ищем причину дальше, версии поста и 1с абсолютно те же, что и на старом? Битность серверов та же?
вот лог 1С при заходе в Конфигуратор, во вторую базу
насколько я понимаю, в приведенных логах 1С нет информации, которая могла бы что-то прояснить.
Хороший вопрос и сильный ответ. В слова "версия" здесь может входить уйма разных нюансов сборки PSql.
Думаю, в этой ситуации наложилось то, что на арендуемом серваке (либо у ТС) неудачная сборка PSql, на явно некорректную, с неправильными настройками выгрузку дампа. Как уже говорилось, ни в коем случае нельзя было удалять источник до успешной загрузки в приемник.
Арендуйте сервак еще раз. Убедитесь, что это все тот же сервак с тем же самым ПО. Создайте пустую базу средствами 1С. Включите максимальную детализацию ошибок в СУБД. Попытайтесь залить базу средствами СУБД. Неизбежно повалятся ошибки при создании объектов типа "уже существует". Аккуратно удаляйте из дампа строки, создающие объекты, которые уже есть в созданной силами 1С базе. Вдумчиво разбирайтесь, как обойти ошибки другого типа. В итоге нужно добиться, чтобы база загрузилась в СУБД. Затем включите технологический журнал в 1С и попробуйте зайти в конфигуратор. Дальше по ситуации.
Как изначально заливали свою базу в СУБД на арендуемом серваке? Без проблем? После выполнения предыдущих пунктов можно развернуть рядом базу в состоянии на тот момент и сравнивать структуру для понимания, какие таблицы "полетели".
>> Хороший вопрос и сильный ответ. В слова "версия" здесь может входить уйма разных нюансов сборки PSql.
весь софт одинаковых версий
>> Арендуйте сервак еще раз
к сожалению арендовать сервер уже не получится т к он уже был отформатирован и используется под другие задачи
и даже если он не был отформатирован, то я перед тем как его сдать удалил все данные спец программой безвозвратно
скорей всего проблема в том что я делал дамп pgadmin4(в нем встроен PostgreSQL 12 без патчей версии PostgresPro 1C),
нужно было делать дамп из консоли средствами PostgresPro 1C 9.6.8 и проблем бы не было бы, вчера проверил
Кто сможет помочь переконвертировать дамп с формата PostgreSQL 12 в формат PostgresPro 1C, если не очень дорого,
могу заплатить?
Решил проблему, хорошо что была точно такая же, рабочая, пустая база.
Я преобразовал бекап в sql код, сравнил два бекапа, пустой и проблемный, заменил где-то 150 раз слово FUNCTION
на слово PROCEDURE в проблемном дампе и все заработало.
Вот лог сравнения, если интересно:
создание базы средствами 1с и средствами постгреса чистой базы при восстановлении все также приводило к ошибке
пока не наткнулся на выдержку из документации:
The text files created by pg_dump are intended to be read in by the psql program. The general command form to restore a dump is
psql dbname < infile
where infile is what you used as outfile for the pg_dump command. The database dbname will not be created by this command, you must create it yourself from template0 before executing psql (e.g., with createdb -T template0 dbname). psql supports options similar to pg_dump for controlling the database server location and the user name. See psql's reference page for more information.
.
Important: The dumps produced by pg_dump are relative to template0. This means that any languages, procedures, etc. added to template1 will also be dumped by pg_dump. As a result, when restoring, if you are using a customized template1, you must create the empty database from template0, as in the example above.
создал базу средствами постгреса на основании схемы template0 и копия восстановилась без ошибок.
Это называется воровством.
Откуда и какой версии СУБД? 1С вроде не выкладывала 11.*.
Можно тут выбрать правда только тестовая 11 а 9 рекомендованая.
Так вот я и тестирую. Работает стабильно, прирос про производительности ощутимый. Но вот с бэкапами пока бяда.
А просто попробывать востановить. И проверить работает бекап или это просто дамп который не пригоден для восстановления и последующей работы. Дампы бывают разные.
Если просто, то работает. Но смущают ошибки которые идут. Пробовал выгрузить с этими ошибками и при загрузке есть вот такие ошибки:
Но в целом работает. Выгрузил в бэкап с сервера 1, загрузил на PG на сервер 2. 1с запустился, через конфигуратор выгрузил в DT с сервера 2.
Выгружается с ошибками, загружается с ошибками, но при этом все работает. Что то это напрягает.
У меня все крутится в lxc контейнере я его полностью бекаплю. Так что проблем пока не видел. Но вот 11PG пока тоже в тесте стоит бекапы не делал это тестовый, проверю после НГ 2019, ну а пока с наступающим.
В общем, работает стабильно и шустрее чем в 9-ой версии. Но вот с бэкапами пока бяда, будем ждать новых релизов. Пока как вариант бэкапов, это выгрузка в db средствами самой 1с. В Этом случае 100% восстанавливается все без ошибок. :) Переходим временно с .sh на .bat
Всех с наступающим
PS. Но все же если кто что сможет написать по теме милости просим в тему:)
Я думаю тебе стоит задать вопрос на форуме 1сников. Глядишь после праздников дельные советы появятся.
Хотя вангую, что тебе предложат не выпендриваться и взять пропатченную 9 версию постгреса.
Вы правы. Они скажут юзай проверенное. Но мы же админы, нам нельзя топтаться на месте. Да и они требую от нас производительности, но что то новое принимать боятся.
За всех не говорю, только за своих и как обычно это сугубо мое мнение.
Не пробовал переключить локаль на английскую и погуглить ошибки ?
Пробовал, ничего не дало
В пустую БД загружаешь ? попробуй сдампить с удалением сущ ключей
Загружаю в пустую базу которую создаю консольно.
Какой параметр для удаления существующих ключей? Не слышал об этой функции.
но он у тебя похоже уже есть
Да пробовал, выхлоп тот же самый:
Опять котята и кошки (кто понял тот поймет). Ну, а по теме есть выход в 1c-Linux могу баг кинуть но пока сам не проверю.
bdfy про к. я думаю понял.
В общем, ковырял, ковырял и понял что данная ошибка при выгрузке базы не на всех базах. Хотя как не странно, она впадает на типовой конфигурации, а на самописных таки ошибок нет.
Есть мысль что проблемы могут быть в самих базах. Завтра попробую перегрузить эти базы в DT, создать новые и переписать все.
Если это поможет то перейдем ко второму этапу. Загрузка бэкапов в базу.
в гуголе есть похожие ошибки с 9 постгре +1с.
Yesss перезаписанная база из dt выгружается без ошибок. Значит косяк был еще на 9-ом PG. Или на 9-ой версии эти ошибки были не критичны, а вот на 11-ой уже начали создавать проблемы. В общем вариант решения проблемы найден.
Завтра буду тестить загрузку из бэкапа. (Если смогу)
я ничего не понял,если что.
Дамп это не средство бекапа postgresql. Юзайте pg_basebackup или аналоги.
Данная утилита делает бэкап всего кластера. А не конкретных баз. Этот вариант не очень хорошо, так как на сервере много кпий баз, которые ненужно бэкпить. Они делаются по просьбе бухгалтеров, менеджеров, что бы не ставили эксперименты на рабочих базах. Так что вариант хороший, но не очень востребованный.
Да это он про наши аватары.
Ладно. С одной проблемой разобрались, сегодня буду пробовать восстановить бэкап. Посмотрим какие там ошибки будут, будем думать откеля у них ноги растут и как их пофиксить.
Что касаемо восстановления, при восстановлении он выдает ряд ошибок. Они всегда одинаковы и их всегда 30
iliaxxx ★ ( 02.01.19 14:50:19 )
Последнее исправление: iliaxxx 02.01.19 14:50:53 (всего исправлений: 1)
Вообще ничего не понял из этих статей. В большей части материалов вообще было принято решение оставить все как есть.
а зачем? по -Fc ведь уже жатые данные идут в бэкап
Разница между сжатым и несжатым и в правду, на 1 Gb всего 10 мегабайт. Это ничтожная разница. Но по сути проблемы это никак не не влияет на те ошибки что приведены выше.
Тут уже вопрос стоит так, стоит ли замарачиваться на эти ошибки или не стоит, 1с все равно стартует и с этими ошибками. Я просто не знаю как это может повлиять на работу базы, на ее стабильность или производительность.
Ну вот и я созрел проверить.
1. База типовая ошибок нет.
2. Не типовая ошибок нет.
что имеем на борту LXC CentOS 6x64
psql (PostgreSQL) 11.1
1c server 8.3.13-1513.i386
бекап
Значит эта ошибка только на Debian 9. У меня 2 тестовых сервера в разных датацентрах и на всех их стоят Debian 9 и идут эти ошибки при восстановлении.
у ТСа с -Fc дамп, может в этом дело.
Centos 7 х64 postgresql-1C-10.5.24 УТ 11 похожие ошибки при бэкапе
Такая же ситуация с centos7 + 1c 8.3.13 + postgresql 10.5 с сайта 1с. Разворачивается дамп без ошибок. Не нашли решения проблемы?
Присоединяюсь к вопросу.
в общем есть 3 базы 1С:
- Предприятие
- Бухгалтерия
- Кадры.
после обновления месяц назад(около 01.07.2019) все 3 базы стали сыпать при выгрузке pg_dump ошибки вида:
] INDEX _reference11705_2 (ID 92925 OID 4401470) pg_dump: [sorter] POST-DATA BOUNDARY (ID 99653) pg_dump: [sorter] TABLE DATA _yearoffset (ID 93130 OID 1099350) pg_dump: [sorter] PRE-DATA BOUNDARY (ID 99652)
E _reference11705_2 (ID 74830 OID 4401472) pg_dump: [sorter TABLE DATA _yearoffset (ID 93130 OID 1099350) pg_dump: [sorter] PRE-DATA BOUNDARY (ID 99652) pg_dump: [sorter] WARNING: could not resolve dependency loop among these items: pg_dump: [sorter] DUMMY TYPE __reference38372_8 (ID 72841 OID 4399893) pg_dump: [sorter] DUMMY TYPE _reference38372_8 (ID 74581 OID 4399894) pg_dump: [sorter] INDEX _reference38372_8 (ID 92726 OID 4399892) pg_dump: [sorter] POST-DATA BOUNDARY (ID 99653) pg_dump: [sorter] TABLE DATA _yearoffset (ID 93130 OID 1099350) pg_dump: [sorter] PRE-DATA BOUNDARY (ID 99652)
При этом консистентность бекапов НЕ была нарушена. Базы корректно бэкапились и корректно работали при восстановлении в пустую бд.
Тестирование и исправление ничего не давало.
Вопрос решил простой выгрузкой баз средствами 1С .dt и загрузкой оных обратно.
После обновления 25.07.2019 вновь появилась запись в логе бэкапа, но уже только базы «Бухгалтерия»:
pg_dump: [sorter] DUMMY TYPE __reference30_3 (ID 55961 OID 6584518) pg_dump: [sorter] DUMMY TYPE _reference30_3 (ID 74185 OID 6584519) pg_dump: [sorter] INDEX _reference30_3 (ID 93035 OID 6584517) pg_dump: [sorter] POST-DATA BOUNDARY (ID 99721) pg_dump: [sorter] TABLE DATA _yearoffset (ID 93193 OID 1099350) pg_dump: [sorter] PRE-DATA BOUNDARY (ID 99720) pg_dump : pg_dump: [sorter] WARNING: could not resolve dependency loop among th ese items:
Есть подозрение, что и в данном случае поможет этот же метод, если не забуду - отпишу как проверю.
Установлен сервер 1С 8.2 + postgresql 8.4.3-3.1C(во время установки выбирал кодировку UTF-8) на Win7x64.
Настроил резервное копирование базы через pg_dump ежедневно. Попробовав восстановить базу из этих дампов столкнулся с проблемой - база восстановилась но с кучей ошибок и не запустилась.
Открыв сам дамп через блокнот увидел что часть текста в нем в виде "кракозябр". Понятно, что пока с кодировкой не разобраться, восстанавливать из бэкапов я не смогу.
Как правильно бэкапить базу в этом случае?
Можно ли спасти уже существующие бэкапы?
- Вопрос задан более трёх лет назад
- 7633 просмотра
Дам делался командой:
pg_dump.exe -i -h localhost -p 5432 -U postgres -w -F c -f "E:\BackUp.back" test1
Пробовал восстанавливать так:
pg_restore -Upostgres -d "test1" -w -F c -v "E:\BackUp.back"
Восстановилась, при полной проверке средствами 1С база вылетает. Выгружаю в dt файл - он весит в 3 раза меньше оригинальной базы.
Восстановление через
psql -Upostgres -W -d test1 -f "E:\BackUp.back"
дало аналогичные результаты. Во время восстановления были ошибки "..invalid command.." и "кракозябра".
Мне кажется у Вас проблема с шаблонами. Посмотрите конфиг шаблона на боевом сервере. Добейтесь такого же на тестовом БД. Создайте те бд через createdb dbname, после через рестор попробуйте туда восстановить.
Истина где-то рядом.
Вот мои заметки по Postgresql:
-------- createdb: database creation failed: ERROR: new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)
HINT: Use the same encoding as in the template database, or use template0 as template.
Когда мы создаем новую базу данных, PostgreSQL фактически просто создает копию имеющегося шаблона базы данных.
Изначально существует два шаблона: template0 и template1. Шаблон template1 используется по-умолчанию при создании новых баз данных. Чтобы изменить кодировку вновь создаваемой базы данных одним из путей является изменение шаблона template1. Чтобы сделать это, подключитесь к командной оболочке PostgresSQL (psql) и выполните следующие действия:
Ошибка СУБД
ERROR: type "mvarchar" does not exist at character 31
или через средство запуска 1С.
Сервер баз данных не обнаружен
FATAL: database "NAME" does not exist
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Сервер баз данных не обнаружен
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-сервере.
Ошибка СУБД:
ERROR: could not load library "/usr/lib/x86_64-linux-gnu/postgresql/fasttrun.so"
Сервер баз данных не обнаружен
ВАЖНО: пользователь "postgres" не прошёл проверку подлинности (Ident)
Данная ошибка возникает при разнесении серверов по разным ПК из-за неправильно настроеной проверки подлинности в локальной сети. Для устранения откройте /var/lib/pgsql/data/pg_hba.conf, найдите строку:
и приведите ее к виду:
где 192.168.31.0/24 - диапазон вашей локальной сети. Если такой строки нет, ее следует создать в секции IPv4 local connections.
Ошибка при выполнении операции с информационной базой
server_addr=NAME descr=11001(0x00002AF9): Этот хост неизвестен.
где указываете адрес и имя вашего сервера 1С:Предприятия. В случае использования локального DNS следует добавить A-запись для сервера 1С.
Общая информация
Перед тем, как начинать искать ошибки установки и, вообще, приступать к внедрению серверной версии 1С:Предприятия было бы неплохо освежить представление как это работает:
В небольших внедрениях сервер 1С и сервер СУБД обычно совмещают на одном физическом сервере, что немного сужает круг возможных ошибок. В нашем случае будет рассматриваться ситуация, когда сервера разнесены по разным машинам. В нашей тестовой лаборатории мы развернули следующую схему:
Типовые ошибки установки сервера 1С:Предприятие и PostgreSQL на платформе Linux.
Связка сервера 1С:Предприятие и PostgreSQL вторая по популярности среди установок 1С и самое используемое решение на платформе Linux. В отличии внедрений на базе Windows и MSSQL, где трудно сделать так, чтобы не заработало, внедрения на базе Linux таят множество подводных камней для неопытного администратора. Часто бывает так, что вроде бы все сделано правильно, но ошибка следует за ошибкой. Сегодня мы рассмотрим самые типовые из них.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Сервер баз данных не обнаружен
ВАЖНО: пользователь "postgres" не прошёл проверку подлинности (по паролю)
Ошибка СУБД: DATABASE не пригоден для использования
Если вы имеете достаточный опыт администрирования Linux систем, то можете попробовать доустановить необходимые библиотеки и заново инициализировать кластер СУБД. В противном случае PostgreSQL лучше переустановить, не забыв удалить содержимое папки /var/lib/pgsql.
Также данная ошибка может возникать при использовании сборок 9.1.x и 9.2.x Postgre@Etersoft, подробности смотрите ниже.
Читайте также: