Ошибка СУБД Postgres

Форум Администрирование Настройка СУБД (DB)

1. P__Slava 05.02.24 14:49 Сейчас в теме

Внезапно стала выскакивать ошибка при проведении документов в старой базе УТ 10.3 на сервере 1с 8.3.22.2283 СУБД Postgres 15.5 "58P01: Ошибка: не удалось получить состояние транзакции 3232159384 Detail: не удалось открыть файл "pg_xact/0C0A": No such file or directory."

Кто-нибудь сталкивался, в чем может быть дело?

Прикрепленные файлы:

По теме из базы знаний

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. nomad_irk 83 05.02.24 15:03 Сейчас в теме

(1)

"pg_xact/0C0A": No such file or directory."

Файл потерялся. Нужно срочно найти.

10. Timur.V 84 05.02.24 17:25 Сейчас в теме

(1)
https://pgconf.ru/media/2018/02/04/Sarafannikov_pgconf.pdf

3. P__Slava 05.02.24 15:05 Сейчас в теме

Где? И почему потерялся?

4. nomad_irk 83 05.02.24 15:16 Сейчас в теме

(3)

Где?

Папка основного каталога, как правило BASE, как правило внутри папки, куда установлен Postgres.
Внутри папки BASE есть папка pg_xact.

И почему потерялся?

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

5. P__Slava 05.02.24 15:18 Сейчас в теме

Если бы я знал конкретную причину, то здесь бы не писал. Но вам спасибо за перевод английского текста!
(4)

Вас надо спросить, по какой причине файлы на дисках теряются.

6. P__Slava 05.02.24 15:48 Сейчас в теме

(4)

спросить

Ошибка такая же появилась второй раз при проведении того же документа, это какая-то системная ошибка. СУБД или платформа. В первый раз выкатили бэкап, сейчас это делать не хочется да и бессмыслено.

7. nomad_irk 83 05.02.24 16:07 Сейчас в теме

(6)по указанному пути находятся системные файлы СУБД(журнал транзакций).
Если не починить, то ошибка будет вываливаться периодически и вы не застрахованы от сбоя, т.е. при сбойном завершении работы Postgre данные во всех БД, обслуживаемых экземпляром СУБД, не возможно будет восстановить.

8. P__Slava 05.02.24 16:36 Сейчас в теме

(7) В том то и дело, что я не понимаю, что чинить. Железо в порядке. Скорее всего, это глюк СУБД, может платформы.

9. nomad_irk 83 05.02.24 16:49 Сейчас в теме

(8)Точно нет.
Нужно разбираться, возможно, журналы транзакций перетащили на другой диск, а в прежнее место сделали символьную ссылку на каталог(так делают для увеличения быстродействия и безопасности).
И теперь этот другой диск отключили/удалили или еще чего приключилось и СУБД не может записывать данные в нужный ей файл.

16. XAKEP 05.02.24 19:38 Сейчас в теме

(9)
без wal субд не запустится

20. nomad_irk 83 06.02.24 07:53 Сейчас в теме

(16)WAL - это Write Ahead Log <> Transaction Log
В WAL пишутся ВООБЩЕ ВСЕ действия внутри кластера Pg, в TL - только состояния транзакций соотвественно

23. XAKEP 06.02.24 08:14 Сейчас в теме

(20)

Transaction Log

postgres 15 ?

26. nomad_irk 83 06.02.24 08:38 Сейчас в теме

(23)
Где и когда жил WAL
Где и когда жил TL
Что есть WAL
расположение всех файлов Pg

27. XAKEP 06.02.24 08:45 Сейчас в теме

(26)
включите переводчик для https://www.postgresql.org/docs/12/storage-file-layout.html
и узнайте разницу между статусом и данными

а также между версиями постгрес 9-10 и 12-15

29. nomad_irk 83 06.02.24 08:51 Сейчас в теме

(27)В плане месторасположения WAL и TL что 9, что 10, что 12, что 15 не отличаются от слова совсем.

32. P__Slava 06.02.24 09:48 Сейчас в теме

(9)

Каталог pg_xact есть, но файла 0C0A там нет. Там всего лишь, 15 файлов 0000 - 000E. И в бэкапах системы такого файла нет...

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

33. nomad_irk 83 06.02.24 09:54 Сейчас в теме

(32)

...но файла 0C0A там нет

Вам именно об этом и сообщает Pg.

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

Каким образом определялось, какие именно данные можно вынести?

Еще хорошо бы посмотреть лог самого PG, там много всего интересного можно найти

34. P__Slava 06.02.24 10:11 Сейчас в теме

(33)

Каким образом определялось, какие именно данные можно вынести?

Выносилось
srvinfo\reg_<номер_порта>\snccntx<GUID>

Вот последний лог.

2024-02-06 10:03:14.659 MSK [1785213] ОПЕРАТОР: SET lc_messages to 'en_US.UTF-8';
2024-02-06 10:03:14.659 MSK [1785213] ПРЕДУПРЕЖДЕНИЕ: нет незавершённой транзакции
2024-02-06 10:03:14.675 MSK [1785214] ОШИБКА: неверное значение для параметра "lc_messages": "en_US.UTF-8"
2024-02-06 10:03:14.675 MSK [1785214] ОПЕРАТОР: SET lc_messages to 'en_US.UTF-8';
2024-02-06 10:03:14.675 MSK [1785214] ПРЕДУПРЕЖДЕНИЕ: нет незавершённой транзакции
2024-02-06 10:03:58.970 MSK [1678820] СООБЩЕНИЕ: контрольная точка завершена: записано буферов: 2855 (0.1%); добавлено файлов WAL 0, удалено: 0, переработано: 2; запись=285.521 сек., синхр.=0.004 сек., всего=285.532 сек.; синхронизировано_файлов=445, самая_долгая_синхр.=0.002 сек., средняя=0.001 сек.; расстояние=28368 kB, ожидалось=114444 kB
2024-02-06 10:04:00.780 MSK [1786106] ОШИБКА: неверное значение для параметра "lc_messages": "en_US.UTF-8"
2024-02-06 10:04:00.780 MSK [1786106] ОПЕРАТОР: SET lc_messages to 'en_US.UTF-8';
2024-02-06 10:04:00.780 MSK [1786106] ПРЕДУПРЕЖДЕНИЕ: нет незавершённой транзакции
2024-02-06 10:04:00.787 MSK [1786107] ОШИБКА: неверное значение для параметра "lc_messages": "en_US.UTF-8"
2024-02-06 10:04:00.787 MSK [1786107] ОПЕРАТОР: SET lc_messages to 'en_US.UTF-8';
2024-02-06 10:04:00.788 MSK [1786107] ПРЕДУПРЕЖДЕНИЕ: нет незавершённой транзакции
2024-02-06 10:04:00.806 MSK [1786108] ОШИБКА: неверное значение для параметра "lc_messages": "en_US.UTF-8"
2024-02-06 10:04:00.806 MSK [1786108] ОПЕРАТОР: SET lc_messages to 'en_US.UTF-8';
2024-02-06 10:04:00.806 MSK [1786108] ПРЕДУПРЕЖДЕНИЕ: нет незавершённой транзакции
2024-02-06 10:04:06.913 MSK [1775068] ОШИБКА: invalid memory alloc request size 2327838736
2024-02-06 10:04:06.913 MSK [1775068] ОПЕРАТОР: INS ERT INTO pg_temp.tt18 (_Q_000_F_000RRef, _Q_000_F_001, _Q_000_F_002) SEL ECT DISTINCT
T1._Fld8539RRef,
T1._Fld8542,
T1._Fld8544
FR OM _InfoRg8537 T1
WHERE (T1._Fld8538RRef = '\\364\\207\\000\\014)\\206\\260\\273\\021\\346\\350JP\\317\\342Z'::bytea) AND (T1._Fld8546 >= '2024-02-06 00:00:00'::timestamp) AND (T1._Period <= '2024-02-06 23:59:59'::timestamp)
2024-02-06 10:04:06.913 MSK [1775068] ПРЕДУПРЕЖДЕНИЕ: нет незавершённой транзакции
2024-02-06 10:04:10.536 MSK [1786365] ОШИБКА: неверное значение для параметра "lc_messages": "en_US.UTF-8"
2024-02-06 10:04:10.536 MSK [1786365] ОПЕРАТОР: SET lc_messages to 'en_US.UTF-8';
2024-02-06 10:04:10.536 MSK [1786365] ПРЕДУПРЕЖДЕНИЕ: нет незавершённой транзакции
2024-02-06 10:04:10.542 MSK [1786369] ОШИБКА: неверное значение для параметра "lc_messages": "en_US.UTF-8"
2024-02-06 10:04:10.542 MSK [1786369] ОПЕРАТОР: SET lc_messages to 'en_US.UTF-8';
2024-02-06 10:04:10.543 MSK [1786369] ПРЕДУПРЕЖДЕНИЕ: нет незавершённой транзакции
2024-02-06 10:04:27.964 MSK [1786713] ОШИБКА: неверное значение для параметра "lc_messages": "en_US.UTF-8"
2024-02-06 10:04:27.964 MSK [1786713] ОПЕРАТОР: SET lc_messages to 'en_US.UTF-8';
2024-02-06 10:04:27.964 MSK [1786713] ПРЕДУПРЕЖДЕНИЕ: нет незавершённой транзакции
2024-02-06 10:04:39.932 MSK [1786990] ОШИБКА: неверное значение для параметра "lc_messages": "en_US.UTF-8"
2024-02-06 10:04:39.932 MSK [1786990] ОПЕРАТОР: SE T lc_messages to 'en_US.UTF-8';

35. nomad_irk 83 06.02.24 10:19 Сейчас в теме

(34)в приведенном куске лога ничего интересного.
нужно смотреть в окрестностях последней(-его) остановки/запуска сервиса

36. P__Slava 06.02.24 10:26 Сейчас в теме

(35)
Сразу после ошибки. Подсунул левый файл, стал ругаться на другой. Не понимаю, откуда он их берет.
Проблема с временными таблицами?

2024-02-06 10:22:51.248 MSK [1781911] ПОДРОБНОСТИ: Не удалось открыть файл "pg_xact/0BBB": No such file or directory.
2024-02-06 10:22:51.248 MSK [1781911] ОПЕРАТОР: SEL ECT
T1._Q_000_F_000RRef,
T1._Q_000_F_004,
'\\274\\225\\000\\014)\\206\\260\\273\\021\\351\\024\\343\\323\\230\\004\\216'::bytea,
T1._Q_000_F_003,
CASE WHEN (T1._Q_000_F_003 > CAST(0 AS NUMERIC)) THEN CAST(((CAST(CAST((CAST(23.034 AS NUMERIC) * (CAST(100 AS NUMERIC) + T1._Q_000_F_003)) AS NUMERIC(19, 8)) / CAST(100 AS NUMERIC) AS NUMERIC(19, 8))) + CAST(0.49 AS NUMERIC)) AS NUMERIC(15, 0)) ELSE CAST(((CAST(CAST((CAST(10.47 AS NUMERIC) * (CAST(100 AS NUMERIC) + (CAST(120 AS NUMERIC) * (CAST(CAST(((CAST(100 AS NUMERIC) + T1._Q_000_F_003)) AS NUMERIC(17, 8)) / CAST(100 AS NUMERIC) AS NUMERIC(17, 8)))))) AS NUMERIC(25, 10)) / CAST(100 AS NUMERIC) AS NUMERIC(25, 10))) + CAST(0.49 AS NUMERIC)) AS NUMERIC(15, 0)) END
FR OM pg_temp.tt12 T1
WHERE (NOT (('\\274\\225\\000\\014)\\206\\260\\273\\021\\351\\024\\343\\323\\230\\004\\216'::bytea IN
(SELECT
T2._Fld8539RRef AS Q_002_F_000RRef
FR OM _InfoRg8537 T2
WH ERE (date_trunc('day','2024-02-05 00:01:00'::timestamp) >= T2._Period) AND (date_trunc('day','2024-02-05 00:01:00'::timestamp) <= CASE WHEN (T2._Fld8546 = '0001-01-01 00:00:00'::timestamp) THEN (('2024-02-05 00:01:00'::timestamp)::timestamp + ((CAST(1 AS NUMERIC))::int::numeric 'DAY')::interval) ELSE (((((((((((('2000-01-01 00:00:00'::timestamp)::timestamp + ((DATE_PART('YEAR',T2._Fld8546)::int::numeric - 2000)::int::numeric 'YEAR')::interval))::timestamp + ((DATE_PART('MONTH',T2._Fld8546)::int::numeric - 1)::int::numeric 'MONTH')::interval))::timestamp + ((DATE_PART('DAY',T2._Fld8546)::int::numeric - 1)::int::numeric 'DAY')::interval))::timestamp + ((CAST(23 AS NUMERIC))::int::numeric 'HOUR')::interval))::timestamp + ((CAST(59 AS NUMERIC))::int::numeric 'MINUTE')::interval))::timestamp + ((CAST(59 AS NUMERIC))::int::numeric || 'SECOND')::interval) END) AND (T2._Fld8538RRef = '\\\\\\225\\000\\014)\\206\\260\\273\\021\\350\\330\\032\\376iLZ'::bytea) AND (T2._Fld8539RRef IN
(SELECT
T3._REFFIELDRRef AS REFFIELDRRef
FR OM pg_temp.tt5 T3)))))) AND (T1._Q_000_F_002 > CAST(23.034 AS NUMERIC)) AND (T1._Q_000_F_001 <= CAST(23.034 AS NUMERIC)) AND (T1._Q_000_F_003 <> CAST(0 AS NUMERIC)) AND (T1._Q_000_F_003 >= -CAST(100 AS NUMERIC))
ORDER BY (T1._Q_000_F_004) DESC, (T1._Q_000_F_000RRef) DESC LIM IT 1

37. nomad_irk 83 06.02.24 10:42 Сейчас в теме

(36)Проблема может возникать в случае, когда транзакция(-и) зависла(-и) на какое-то длительное время, либо после восстановления БД из бэкапа.

Решается - перезапуском сервиса, либо поиском спящих сеансов с подвисшими транзакциями и их удалением.

38. P__Slava 06.02.24 11:45 Сейчас в теме

(37)

Решается - перезапуском сервиса, либо поиском спящих сеансов с подвисшими транзакциями и их удалением.

Посмотрел несколько сбоев, проблема наблюдается при выборке во временную таблицу из РС ЦеныНоменклатуры. В разных комбинациях запросов. Иногда проходит, иногда сбоит. Запросы разные.
Странные глюки. Не было таких раньше.

После перезагрузки сервера 1с

2024-02-06 11:38:50.373 MSK [2115] ПОДРОБНОСТИ: Не удалось открыть файл "pg_xact/0A38": No such file or directory.
2024-02-06 11:38:50.373 MSK [2115] ОПЕРАТОР: INS ERT IN TO pg_temp.tt14 (_Q_000_F_000RRef, _Q_000_F_001, _Q_000_F_002) SEL ECT DISTINCT
T1._Fld8539RRef,
T1._Fld8542,
T1._Fld8544
FR OM _InfoRg8537 T1
WHERE (T1._Fld8538RRef = 'L\\223\\000\\014)\\024v\\235\\021\\353\\233\\217W&j+'::bytea) AND (T1._Fld8546 >= '2024-02-06 00:00:00'::timestamp) AND (T1._Period <= '2024-02-06 23:59:59'::timestamp)

Может с РС что-то не то?

39. XAKEP 06.02.24 18:14 Сейчас в теме

(35)
PostgreSQL поддерживает только общую для всех баз кластера кодировку, которая должна совпадать с локальной кодировкой (Настройка переменных локализации в Linux), иначе не будут работать строковые функции сортировки, upper/lower и т.п. Локаль общая для всех процессов сервера - соответственно он не может создать две базы в разных кодировках - кодировка всегда одна для всего сервера и всех его БД.

------------
ОШИБКА: неверное значение для параметра "lc_messages": "en_US.UTF-8"

но вам это не интересно
----------------------------------
Т.е. создать базу в другой кодировке можно, но тогда в ней будут неправильно работать функции обработки строк и сортировка строк.

-----------
ОШИБКА: invalid memory alloc request size 2327838736
ну очень не интересно , да ?

40. P__Slava 06.02.24 22:02 Сейчас в теме

(39)

PostgreSQL поддерживает только общую для всех баз кластера кодировку, которая должна совпадать с локальной кодировкой (Настройка переменных локализации в Linux), иначе не будут работать строковые функции сортировки, upper/lower и т.п. Локаль общая для всех процессов сервера - соответственно он не может создать две базы в разных кодировках - кодировка всегда одна для всего сервера и всех его БД.

Мне интересно, даже очень. Но что делать?! База работает, но теперь не бэкапится, регистр сведений раздулся??
pg_dump: ошибка: Ошибка выгрузки таблицы "_inforg7066": сбой в PQgetResult().
pg_dump: подробности: Сообщение об ошибке с сервера: ОШИБКА: invalid memory alloc request size 8589934587
pg_dump: подробности: Выполнялась команда: COPY public._inforg7066 (_period, _recordertref, _recorderrref, _lineno, _active, _fld7067, _fld7068rref, _fld7069rref, _fld7070rref, _fld7071rref, _fld7072_type, _fld7072_rtref, _fld7072_rrref, _fld7073_type, _fld7073_rtref, _fld7073_rrref, _fld7074rref, _fld7075rref, _fld7076rref, _fld7077rref, _fld7078rref, _fld7079_type, _fld7079_rtref, _fld7079_rrref, _fld7080_type, _fld7080_rtref, _fld7080_rrref, _fld7081, _fld7082, _fld7083rref, _fld7084rref, _fld7085rref, _fld7086, _fld7087, _fld7088rref, _fld7089, _fld7090, _fld7091, _fld7092, _fld7093rref, _fld7094rref, _fld7095rref, _fld7096rref, _fld7097_type, _fld7097_rtref, _fld7097_rrref, _fld7098, _fld7099, _fld7100, _fld7101rref, _fld7102rref, _fld7103rref, _fld7104rref, _fld7105rref, _fld7106rref, _fld7107, _fld7108, _fld7109rref, _fld7110rref, _fld7111rref, _fld7112, _fld7113, _fld7114, _fld7115, _fld7116, _fld7117rref, _fld7118rref, _fld7119rref, _fld7120, _fld7121rref, _fld7122, _fld7123_type, _fld7123_rtref, _fld7123_rrref, _fld7124rref, _fld7125rref) TO stdout;
pg_dump: ошибка: рабочий процесс неожиданно прервался

41. XAKEP 06.02.24 22:19 Сейчас в теме

(40)
Выложите конфиг файл слона и сообщите сколько оперативки на железе, сколько ядер у проца и сколько физических дисков ссд хдд

42. P__Slava 06.02.24 22:36 Сейчас в теме

(41)

ссд

1 ssd
64 ГБ памяти, 12 ядер

Прикрепленные файлы:

postgresql.conf

43. XAKEP 06.02.24 22:50 Сейчас в теме

(42)
Один диск -не желательно, но что есть

maintenance_work_mem = 256MB - это очень мало на нужные процессы обслуживания
Если позволяют соединения - у вас не более 10клиентов, то work_mem = 512MB увеличить на столько же

Со смартфона пишу, не все могу заметить...
max_connections = 200 - реальное плюс 25-50 %
Там ещё с чекпойнтом и валами но сейчас не готов
В Гугле найдите надстройку для ссд постгрес 1с,точно не помню, потому что использую только хдд под слон.

44. P__Slava 06.02.24 23:13 Сейчас в теме

(43)
Спасибо.

46. nomad_irk 83 07.02.24 09:13 Сейчас в теме

(39)В рамках обсуждаемой проблемы - не интересно вообще какая там кодировка и что в результате этого может быть.
Памяти процессам Pg не хватает - либо Pg не настраивали, либо проблемы с железом/вирусы.

12. redfred 05.02.24 17:58 Сейчас в теме

(8) Проверку файловой системы для начала прогоните

13. XAKEP 05.02.24 18:50 Сейчас в теме

(12)
какую файловую ?
субд - так вы потом не соберете ее....

17. redfred 05.02.24 20:02 Сейчас в теме

(13) Файловую на которой база лежит. Из бэкапа базу восстанавливали и она опять ошибками пошла - явно дисковую подсистему проверять надо. И сильно подозреваю, что базу снова из бэкапов поднимать нужно будет

18. XAKEP 05.02.24 20:43 Сейчас в теме

(17)
а вы знаете , как используется хранилище у автора,
какие диски физические,
где находится база
как долго они используют ее и что с питанием системы в целом

19. redfred 06.02.24 04:40 Сейчас в теме

(18) Нет, не знаю. По большому счёту, какая разница-то что там? Возможных вариантов не так, чтоб сильно много

11. redfred 05.02.24 17:57 Сейчас в теме

(7)

по указанному пути находятся системные файлы СУБД(журнал транзакций).

Ну, не совсем журнал транзакций. Он, всё же, в pg_wal.

21. nomad_irk 83 06.02.24 07:54 Сейчас в теме

(11)см (20)

25. XAKEP 06.02.24 08:18 Сейчас в теме

(21)
см. постгрес 15 :)

15. XAKEP 05.02.24 19:36 Сейчас в теме

(7)

при сбойном завершении работы Postgre

для этого существует archive_command и дальше по мануалу.

22. nomad_irk 83 06.02.24 07:58 Сейчас в теме

(15)все так, только состояний транзакций нет, восстановление данных с последней "точки" не возможны.

24. XAKEP 06.02.24 08:18 Сейчас в теме

(22)

нет, восстановление данных с последней "точки

archive_timeout ,
если прям продакшн и каждые 5минут важны

28. nomad_irk 83 06.02.24 08:48 Сейчас в теме

(24)да хоть унастраивайтесь таймаутами - файлов для хранения лога транзакций нет, либо он "кривой".
восстановить данные в базах будет невозможно с момента последнего полного бэкапа.

30. XAKEP 06.02.24 08:52 Сейчас в теме

(28)
вы слона видели или работали с ним ????
логическая или физическая репликация - была у вас в жизни?

восстановится можно из ........ ( спросите дба админа )

31. nomad_irk 83 06.02.24 08:55 Сейчас в теме

(30)у ТС хворает ровно один экземпляр Pg, вы можете дальше рассказывать о физических/логических репликациях и способах восстановления из них

14. XAKEP 05.02.24 18:54 Сейчас в теме

включите в конфиг файле слона нужные опции для просмотра ошибок
или в логах сейчас смотрите, что пишет.
-----------
Ошибка такая же появилась второй раз при проведении того же документа,
-------------------
так она и будет, если файла нет
ТИИС 1с проверяли ?
хотя перед эти точно бекап нужен

или попробуйте младшую версию слона, если есть возможность

45. ansh15 07.02.24 09:08 Сейчас в теме

По поводу

pg_dump: ошибка: Ошибка выгрузки таблицы "_inforg7066": сбой в PQgetResult().
pg_dump: подробности: Сообщение об ошибке с сервера: ОШИБКА: invalid memory alloc request size 8589934587

- тема известная. Там есть и объяснения и решение.
Обычно это касалось таблицы config в конфигурациях с возможностью редактирования и сохранением поддержки.
Возможно, в _inforg7066 занеслось что-то большое( в какой-нибудь столбец таблицы) или просто испортилось при каком-то не очень очевидном сбое.
Можно попробовать выгрузить без этой таблицы, в статье по ссылке указано как это сделать, хотя если был сбой, таких таблиц может быть не одна..
Если удастся выгрузить, лучше создать новый кластер Pg (pgsql/data), старый куда-нибудь скопировать, на всякий случай. И в новый восстанавливать данные. Потому что в старом может быть битый не только pg_xact...

Если бы был Linux, можно было бы попробовать выгрузить/загрузить при помощи pg_dumpbinary/pg-restorebinary(ищется в Интернете)

47. P__Slava 07.02.24 12:12 Сейчас в теме

(45)
Спасибо за совет с новым кластером. Базе трындец, но надо понять причины ее падения. База не бэкапируется даже с исключением отдельных таблиц, не вакуумируется, не реиндексируется и не исправляется средствами 1С. Железо нормальное.

48. nomad_irk 83 07.02.24 17:17 Сейчас в теме

(47)

База не бэкапируется даже с исключением отдельных таблиц, не вакуумируется, не реиндексируется и не исправляется средствами 1С

Как же замечательно, что мы об этом узнали в 47-ом сообщении..........

52. P__Slava 08.02.24 13:27 Сейчас в теме

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

49. XAKEP 07.02.24 17:45 Сейчас в теме

(47)
# WRITE-AHEAD LOG
основная причина в этом разделе

другая, которая ускорила это - внезапное или внеплановое завершение виндовс
( или просто вырубали питание )

через .dt - получалось выгрузить базу ?

кстати, посмотрите кристал диском ваш ссд.

50. nomad_irk 83 08.02.24 07:55 Сейчас в теме

(49)

WRITE-AHEAD LOG

C WAL все в порядке, о чем говорит лог PG в (34)
проблема с журналом транзакций(данные о статусах транзакций)

в (47) появились новые вводные, что и автовакуум/бэкап/реиндекс средствами СУБД не работает, так же не работает ТиИ средствами 1С

51. XAKEP 08.02.24 13:05 Сейчас в теме

(50)
давайте еще раз - статус - у вас означает данные или ч-т-о ?
статус документа - проведен/удален - это документ или статус ????

чего вы держитесь статуса, как будто вы по нему восстановите данные ...

и про "все в порядке"
вы в курсе, что установлено в этом разделе у автора вопроса
- при том, что он выложил конфиг файл слона ?

покажите пример своей работы,
когда информация из папки статусов (!!!) слона помогли вам в решении проблем с данными

53. XAKEP 08.02.24 13:59 Сейчас в теме

(50)
иногда или часто лучше обходить стороной
доказывать очевидные вещи
человеку, которые этого не замечает.

Для отправки сообщения требуется регистрация/авторизация

Ошибка СУБД Postgres

Журнал

База знаний

Лаборатория

Анализ & Управление

Сопровождение 1С

Корпоративные решения

Обучение

Маркетплейс

Проектный офис

Мероприятия

Видеозаписи

Биржа заказов

Форум

Мерч

О компании