Ошибка СУБД при входе в базу 1С

REINDEX, VACUUM FULL не пробовали?

Запрос ,который вернёт ТОП 100 самых больших таблиц с учётом индексов

create extension if not exists pgstattuple;

SEL ECT nspname || '.' || relname AS "relation", pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
FR OM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE nspname NOT IN ('pg_catalog', 'information_schema') AND C.relkind <> 'i' AND nspname !~ '^pg_toast' ORDER BY pg_total_relation_size(C.oid) DESC LIM IT 100


Отдельно только индексы более 200МБ:
create extension if not exists pgstattuple;

SELECT relname AS "relation", pg_size_pretty(pg_indexes_size(C.oid)) AS "total_size"
FR OM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE pg_indexes_size(C.oid) >= 209715200 AND nspname NOT IN ('pg_catalog', 'information_schema') AND C.relkind <> 'i' AND nspname !~ '^pg_toast' ORDER BY pg_indexes_size(C.oid) DESC

Отдельно только таблицы более 1ГБ:
create extension if not exists pgstattuple;

SELECT relname AS "relation", pg_size_pretty(pg_table_size(C.oid)) AS "total_size"
FR OM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WH ERE pg_table_size(C.oid) >= 1073741824 AND nspname NOT IN ('pg_catalog', 'information_schema') AND C.relkind <> 'i' AND nspname !~ '^pg_toast' ORDER BY pg_table_size(C.oid) DESC


Дальше комбинируйте под свои задачи, сам принцип я думаю понятен

Как вариант - собрать полный технологический журнал и посмотреть сам запрос, на котором ошибка валится...

Какая ОС? Язык какой?

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

Общая информация
Включение технологического журнала
Создание файла настроек
<dump>
<log>
<event>
<property>

Общая информация

Технологический журнал является основным источником информации для всех инструментов анализа производительности платформы.

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

Технологический журнал может продуцировать два вида информации:

Логи — файлы с расширением *.log, в которых в текстовом виде храниться информация о произошедших событиях;
Дампы — файлы с расширением *.mdmp, в которых хранится содержимое оперативной памяти рабочего процесса на момент его «падения». Самостоятельный анализ дампа невозможен, так как исходный код платформы закрыт. Единственный способ проанализировать дамп — отправить его в тех. поддержку или на партнерский форум.

Включение технологического журнала

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

%LOCALAPPDATA%\1C\1cv8\dumps (пример: C:\Users\USR1CV8\AppData\Local\1C\1cv8\dumps)

а логи здесь:

%LOCALAPPDATA%\1C\1cv8\logs (пример: C:\Users\USR1CV8\AppData\Local\1C\1cv8\logs)

USR1CV8 — имя пользователя под которым работает сервер 1С. Логи хранятся 24 часа, при этом делятся на файлы — каждый час новый файл.

Собираемая таким образом информация минимальна — формируются дампы минимального размера при аварийном завершении работы рабочих процессов, а в логи попадают только события SYSTEM с уровнем Error.

В большинстве случаев этой информации недостаточно, следовательно нам необходимо самостоятельно указать какую информацию мы хотим видеть в логах. Для этого необходимо создать файл настроек тех. журнала (об этом ниже) с названием logcfg.xml и разместить его в одной из подходящих директорий.

Выбор директории зависит от задачи: если нужно настроить тех. журнал для всех версий 1С, то файл настроек нужно разместить здесь:

C:\Program Files\1cv8\conf

Если настроить нужно конкретную версию, то здесь (зависит от версии):

C:\Program Files\1cv8\8.3.13.1513\bin\conf

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

C:\Users\USR1CV8\AppData\Local\1C\1cv8\conf

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

Создание файла настроек

Теперь перейдем к содержимому файла настроек logcfg.xml.

Вначале приведем пример файла настроек:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump location="c:\1c_info\dumps" create="1" type="3"/>
<log location="c:\1c_info\logs" history="48">
<event>
<eq property="name" value="EXCP"/>
</event>
<event>
<eq property="name" value="PROC"/>
</event>
<event>
<eq property="name" value="ADMIN"/>
</event>
<event>
<eq property="name" value="EXCPCNTX"/>
</event>
<property name="all"> </property>
</log>
</config>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18



<dump>

Этот элемент отвечает за формирование дампов памяти. Атрибуты:

location — каталог в который будут сохраняться дампы, значение этого атрибута должно отличаться от значений такого же атрибута у других элементов (<log> и <defaultlog>).

create — записывать (1) или не записывать (0) дампы.

type — тип дампа, любая комбинация (сумма) из перечисленных ниже флажков:

0 — минимальный;
1 — дополнительный сегмент данных;
2 — содержимое всей памяти процесса;
4 — данные хэндлов;
8 — оставить в дампе только информацию, необходимую для восстановления стеков вызовов;
16 — если стек содержит ссылки на память модулей, то добавить флажок флаг 64;
32 — включить в дамп память из-под выгруженных модулей;
64 — включить в дамп память, на которую есть ссылки;
128 — добавить в дамп подробную информацию о файлах модулей;
256 — добавить в дамп локальные данные потоков;
512 — включение в дамп памяти из всего доступного виртуального адресного пространства.

Компания «1С» советует использовать значение 3 (1+2), так как в большинстве случаев этого достаточно.
<log>

Этот элемент определяет каталог тех. журнала и события которые в него попадают. Таких элементов может быть несколько т.е. сервер 1С может вести сразу несколько тех. журналов с различными настройками. Тем не менее компания «1С» не рекомендует вести более 20 тех. журналов одновременно, так как это может замедлить работу системы. Может содержать внутри себя элементы <event> и <property>. Атрибуты:

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

history — время жизни логов, в часах.
<event>

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

eq — равно;
ne — не равно;
gt — больше;
ge — больше или равно;
lt — меньше;
le — меньше или равно;
like — соответствие маске.

<property>

Определяет условия попадания в журнал значения свойства события.

Элемент <property name=»all»> </property> включает записи в журнал всех свойств событий.

упоминаются далеко не все элементы конфигурационного файла, а те, что все-таки упоминаются, рассмотрены поверхностно. Самое полное описание всех элементов конфигурационного файла, с примерами, советами и пояснениями имеется на сайте ИТС (https://its.1c.ru/db/v8314doc#bookmark:adm:TI000000393), а также в руководстве администратора.

Руководство администратора (желтая, не очень толстая книжечка) можно легко найти в электронном виде, да и бумажном оно встречается достаточно часто, так как входит во многие поставки продуктов компании 1С.

размер базы позволяет выгрузить в файловый вариант ?

в конфигуратор входите - в чем проблема выгрузить файл в дт ?

Выгрузка прошла в dt или тоже завершилась с ошибкой?

https://www.sql.ru/forum/1333781/oshibka-pri-vhode-v-bazu

я так понимаю ждут фортуну

---------------------------

вышел из ветки

Кстати, есть бекап от 19.02.2021, но восстановить его не получается, видимо битый сделался, скрин попытки во вложении, в логах пишет:
< 2021-02-25 12:26:47.192 GMT >ERROR: canceling statement due to user request
< 2021-02-25 12:26:47.192 GMT >CONTEXT: COPY _inforg7202, line 152664
< 2021-02-25 12:26:47.192 GMT >STATEMENT: COPY public._inforg7202 (_fld7203_type, _fld7203_rtref, _fld7203_rrref, _fld7204, _fld406) FROM stdin;

< 2021-02-25 12:26:47.215 GMT >LOG: could not send data to client: An existing connection was forcibly closed by the remote host.


< 2021-02-25 12:26:47.215 GMT >FATAL: connection to client lost

Попробуйте переустановить службу, сравните с рабочей службой. Смотрите в журнал приложений и служб ошибки

Попробуйте почистить лог

обязательно к прочтению
https://forum.infostart.ru/redirect.php?url=aHR0cHM6Ly9wb3N0Z3Jlc3Byby5ydS9kb2NzL3Bvc3RncmVzcWwvOS42­L2FwcC1wZ3Jlc2V0eGxvZw==

Решение с чисткой логов помогает C:\Program Files (x86)\PostgreSQL\9.6.1-4.1C\bin>pg_resetxlog.exe -f "D:\PostgreSQL\data", только не с первого раза, нужно запустить службу, если не запустилась, то еще раз чистить и снова пробовать, или сразу выполнить эту команду несколько рази потом все стартует.
При первом вызове была ошибка:
pg_resetxlog: lock file "postmaster.pid" exists
Is a server running? If not, delete the lock file and try again.
Удалили файл "postmaster.pid", потом нормально отработало.

Была подобная ошибка. В итоге все снес и заново с бекапа восстановил

Не стал разбираться искать причины и не страшно что потеряли данные за неделю 100 сотрудников быстро все восстановили. Только я уже там не работаю

У меня такая ошибка случилась. Из симптомов - база открывалась только конфигуратором, DT выгрузить не давала, выдавало ошибку XX002: ERROR. Лично мне при такой ошибке помогло pg_dump / pg_restore из самой проблемной базы, НО восстанавливайте не саму в себя базу с помощью pg_restore, а в другую пустую только созданную базу. При этой процедуре индексы пересоздаются и если дело исключительно в них, то новая база в которую сделали pg_restore запустится. Потом переименовал с помощью ALT ER DATABASE восстановленную из бэкапа базу как рабочую, а проблемную назвал иначе и полет нормальный. Конфигуратор - если он запускается - лучше им ничего не делать типа ТИИС, пытайтесь сначала pg_dump / pg_restore в новую чистую базу.