Ошибка СУБД Postgres

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

1. user1274184 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 80 05.02.24 15:03 Сейчас в теме

(1)

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

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

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

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

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

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

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

(3)

Где?

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

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

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

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

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

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

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

(4)

спросить

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

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

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

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

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

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

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

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

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

20. nomad_irk 80 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 80 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 80 06.02.24 08:51 Сейчас в теме

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

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

(9)

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

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

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

(32)

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

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

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

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

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

34. user1274184 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 80 06.02.24 10:19 Сейчас в теме

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

36. user1274184 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 80 06.02.24 10:42 Сейчас в теме

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

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

38. user1274184 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. user1274184 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. user1274184 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. user1274184 06.02.24 23:13 Сейчас в теме

(43)
Спасибо.

46. nomad_irk 80 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 80 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 80 06.02.24 07:58 Сейчас в теме

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

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

(22)

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

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

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

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

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

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

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

31. nomad_irk 80 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. user1274184 07.02.24 12:12 Сейчас в теме

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

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

(47)

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

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

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

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

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

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

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

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

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

50. nomad_irk 80 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)
иногда или часто лучше обходить стороной
доказывать очевидные вещи
человеку, которые этого не замечает.

Оставьте свое сообщение

E-mail: