Ошибка субд xx000 error missing chunk number 0 for toast value 1c
Описание
Ошибка при выполнении операции с информационной базой
Ошибка СУБД:
XX002: ERROR: index "pg_class_relname_nsp_index" contains unexpected zero page at block 7
HINT: Please REINDEX it.
по причине:
Ошибка СУБД:
XX002: ERROR: index "pg_class_relname_nsp_index" contains unexpected zero page at block 7
HINT: Please REINDEX it.
Запрос ,который вернёт ТОП 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
Дальше комбинируйте под свои задачи, сам принцип я думаю понятен
(4) Большое спасибо за участие, знать бы еще как с ними работать, я с постгре и запросами на Вы. Запросы на скринах делал по инфе с инета. Штатного админа нет по постгре
Как вариант - собрать полный технологический журнал и посмотреть сам запрос, на котором ошибка валится.
Технологический журнал — это средство логирования действий платформы происходящих на самом низком уровне. Данные предоставляемые технологическим журналом позволяют выявить причины «тормозов», зависаний, утечек памяти и «падений» рабочих процессов.
Содержание
Общая информация
Включение технологического журнала
Создание файла настроек
Технологический журнал является основным источником информации для всех инструментов анализа производительности платформы.
Ведение технологического журнала возможно как для сервера, так и для клиентских приложений. Так как клиентские логи и дампы, за редким исключением, не представляют практического интереса, вопрос мы будем рассматривать только со стороны сервера. Тем не менее, все сказанное ниже, будет верно и для клиента.
Технологический журнал может продуцировать два вида информации:
Включение технологического журнала
По умолчанию технический журнал включен и работает, дампы хранятся здесь:
%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С, то файл настроек нужно разместить здесь:
Если настроить нужно конкретную версию, то здесь (зависит от версии):
Иногда может потребовать включить тех. журнал для конкретного пользователя, из под которого запущен сервер 1С, в этом случае файл настроек следует разместить тут:
Перезагружать сервер не требуется, настройки считаются и будут применены не более чем через 60 секунд. Выключить тех. журнал еще проще — нужно переместить или переименовать файл настроек.
Создание файла настроек
Теперь перейдем к содержимому файла настроек logcfg.xml.
Этот элемент отвечает за формирование дампов памяти. Атрибуты:
location — каталог в который будут сохраняться дампы, значение этого атрибута должно отличаться от значений такого же атрибута у других элементов ( и ).
create — записывать (1) или не записывать (0) дампы.
type — тип дампа, любая комбинация (сумма) из перечисленных ниже флажков:
0 — минимальный;
1 — дополнительный сегмент данных;
2 — содержимое всей памяти процесса;
4 — данные хэндлов;
8 — оставить в дампе только информацию, необходимую для восстановления стеков вызовов;
16 — если стек содержит ссылки на память модулей, то добавить флажок флаг 64;
32 — включить в дамп память из-под выгруженных модулей;
64 — включить в дамп память, на которую есть ссылки;
128 — добавить в дамп подробную информацию о файлах модулей;
256 — добавить в дамп локальные данные потоков;
512 — включение в дамп памяти из всего доступного виртуального адресного пространства.
Компания «1С» советует использовать значение 3 (1+2), так как в большинстве случаев этого достаточно.
Этот элемент определяет каталог тех. журнала и события которые в него попадают. Таких элементов может быть несколько т.е. сервер 1С может вести сразу несколько тех. журналов с различными настройками. Тем не менее компания «1С» не рекомендует вести более 20 тех. журналов одновременно, так как это может замедлить работу системы. Может содержать внутри себя элементы и . Атрибуты:
location — каталог в который будут записываться логи, этот каталог должен быть пустым, кроме этого он не должен совпадать со значениями аналогичных атрибутов у других элементов.
history — время жизни логов, в часах.
Определяет условия, при выполнении которых событие попадает в журнал. Само условие задается следующими элементами:
eq — равно;
ne — не равно;
gt — больше;
ge — больше или равно;
lt — меньше;
le — меньше или равно;
like — соответствие маске.
Определяет условия попадания в журнал значения свойства события.
Элемент включает записи в журнал всех свойств событий.
Руководство администратора (желтая, не очень толстая книжечка) можно легко найти в электронном виде, да и бумажном оно встречается достаточно часто, так как входит во многие поставки продуктов компании 1С.
When running \d table, we got error msg:ERROR: missing chunk number 0 for toast value 185589 in pg_toast_2619, it seems catalog has been corrupted!
Time: 1.322 ms
pg_statistic got OID 2619.
The text was updated successfully, but these errors were encountered:
Jasonysli commented May 29, 2015
Jasonysli commented May 29, 2015
The two error messages are both about catalog corrupted, so sad.
koichi-szk commented May 29, 2015
Thanks for the report. Does it happen with the master or REL1_2_STABLE? Please test it with REL1_2_STABLE branch, not master because master does not have many fixes of PG itself.
Can you reproduce the error anytime or does it happen occasionally? I found the same error in the past but I was not successful to reproduce it.
If you can, please let me know what branch you used. I will write a patch to collect the info. Please let me know the exact error message, if you have other one than you reported.
I can provide a patch this weekend or Monday for the latest.
Thank you;
—
Koichi
koichi-szk commented May 30, 2015
Please find enclosed a patch to cause PANIC and get a core when the above error occurs. You can take back trace for analysis.
However, I suspect the cause is not here, there could be another module which destroyed some part of the storage.
I suspect there could be a buffer overflow. Backtrace will help to see what catalog is damaged and what code we should investigate. Could you test XC with valgrind? This sometimes helps to find such bad bug. We did it before 1.0 release and was helpful to find such potential bugs.
Sorry for asking so many things. Hope this helps.
Thank you very much;
Thank you very much;
koichi-szk commented May 31, 2015
Because XC depends upon palloc(), you may need to do something extra to check memory leak with valgrind. I think there are some document available on the setup. It might be in a file server of the office.
Let me check. If I'm lucky, I can provide the setup info later on Monday.
Jasonysli commented Jun 1, 2015
Hi koichi-szk, sorry for the delayed reply.I answer the question one by one:
1、OK, we will keep using REL1_2_STABLE code to do the test instead of master, in fact , we are using REL1_2_STABLE.
2、Our system was running with high work load, the issue happens on two of four coordinators. We did no special operation, just normal DDL and DML. I think maybe it was caused by catalog corruption, becasue we got "ERROR: catalog is missing 7 attribute(s) for relid 141685" msg at the same time.
3、In pressure test, we keep the xc running on high workload, no memory leak found after 24 hours running. But we will keep observing memory info when running test.
koichi-szk commented Jun 1, 2015
Thank you very much for the report. Sorry I'm not successful to find a
guide how to use valgrind with XC. Will let you know when found.
What is the relation with relied 141685?
I'm afraid there could be at least one buffer overflow, which runs very
rarely. Will continue to review the code to find it.
Thank you again;
In some cases, it is possible that PostgreSQL tables get corrupted. This can happen in case of hardware failures (e.g. hard disk drives with write-back cache enabled, RAID controllers with faulty/worn out battery backup, etc.), as clearly reported in this wiki page. Furthermore, it can happen in case of incorrect setup, as well.
One of the symptoms of such corruptions is the following message:
ERROR: missing chunk number 0 for toast value 123456 in pg_toast_45678
This almost surely indicates that a corrupted chunk is present within a table file. But there is a good way to get rid of it.
Let's suppose that the corrupted table is called mytable . Many articles on the Internet suggest to fire the following query against the database:
and then to fire the following commands:
But in my case this was not enough. Then, I computed the number of rows in mytable :
To find the corruption, it is possible to fetch data from the table until getting the 'Missing chunk. ' error. So the following group of queries does the job:
. and so on until getting the error. In this example, if you reach the offset of 55000 (55000 + 5000 is 60000 which exceeds the total number of records) without getting the error, then your table is not corrupted. The order by clause is necessary to make your query repeatable, i.e. assure that the query does not randomly return rows, and limit and offset clauses work as expected. If your table does not have an id field, you have to find a good field to order by. For performance reasons, it is preferable to select an indexed field.
In order to go faster and not get your console dirty, the query can be directly triggered from the console, redirecting the output to /dev/null and printing an error message only in case of error found:
The above syntax means: execute the query and redirect the output to /dev/null or, in case of error (||), write an error message.
Let's suppose that the first query giving the error is the following:
Now, you know that the corrupted chunk is in the rows between 10000 and 14999. So, you can narrow the search by halving the query LIMIT clause.
So, the error happens to be in the rows between 10000 and 12499. We halve again the rows limit.
Fetching the rows between 10000 and 12499 does not return any error. So the error must be in the rows between 11250 and 12499. We can confirm this by firing the query:
So, we halve again the limit.
You should continue narrowing until exactly finding the corrupted row:
Note that in this last query the LIMIT 1 clause exactly identifies only one row.
Finally, you have to find the id of the corrupted row and delete it (obviously you have a data loss):
During the search of the corrupted row, consider that, most likely, the corruption is in the last inserted/updated records, even if this is not a general rule. So you can choose a sort key that respects the physical insert/update so to lower the scan time.
If you prefer to fully automate the corrupted row search, consider using the following script (in csh syntax):
This script prints the number of all the corrupted rows. In case of long tables, it can take long time since it performs as many queries as the number of table rows.
Клиент-Серверный вариант на Postgresql. При выгрузке базы в dt, вываливает ошибку: Ошибка СУБД Error (см вложение).
При тестировании удалось определить поврежденную таблицу"Регистр сведений Ресурсы механизмов онлайн сервисов РО"
Через Postgresql, восстановить таблицу не удалось. Какими методом это можно произвести?
(12) Постгрес на винде
Я решил проблему по другому. Так как информационная база была целой, за исключением "Регистра сведений Ресурсы механизмов онлайн сервисов РО" и был архив базы dt на начало февраля, выгрузив данные из базы с битой таблицей загрузил в новую информационную базу.
На файловой базе были такие ошибки. В таких ситуациях, открывал базу утилитой, которая даёт доступ к таблицам, и заменял руками значение, которое требует платформа, в вашем случае, она 0 хочет. 2-3 раза повторял махинацию, и проблема пропадала.
Тем более если база не файловая, то никакие утилиты не нужны.
Ничего не помогло.
REINDEX table pg_toast.pg_toast_2549433; - реиндексация проходит нормально
VACUUM ANALYZE [table] -- вываливается та же ошибка
Не работает pg_dump, та же ошибка, архив базы не создается.
А как/чем этот регистр изменяется? Вручную, документом(-ами)?
В режиме Предприятие пробовали этот регистр открыть, посмотреть что там?
Если он изменяется документами, то не пробовали эти документы перепровести?
Если этот регистр можно изменять вручную, то не пробовали в него добавлять записи?
В клиент-серверном варианте есть режим "Тестирование и исправление ИБ"? (в файловом варианте такой есть в Конфигураторе)
Ошибка СУБД
ERROR: unexpected chunk number 37 (expected 0) for toast value 9333560 in pg_toast_2549433
А в самой Postgresql есть свои средства тестирования и исправления?
(11) Я в клиент-сервере профан, чисто из любознательности интересуюсь, для общего развития ))
В репозитории моей Debian GNU/Linux куча разных пакетов по Постгрес, в том числе полный комплект документации. В принципе, могу хоть сейчас себе установить и начать вместе с вами в эту СУБД погружаться ))
Подозреваю, что без такого погружения вашу проблему не решить.
А как именно вы пытались восстановить таблицу через Постгрес? Что пробовали делать?
Вот что у меня в репозитории пакетов есть по поводу клиентских программулин (фронт-эндов) для Постгрес. Пишут, что удалять таблицы можно, ну значит наверняка и для прямого редактирования этих самых таблиц есть какие-то средства:
Package: postgresql-client-9.6
Description: front-end programs for PostgreSQL 9.6
This package contains client and administrative programs for PostgreSQL: these are the interactive terminal client psql
and programs for creating and removing users and databases.
This is the client package for PostgreSQL 9.6. If you install PostgreSQL 9.6 on a standalone machine, you need the
server package postgresql-9.6, too. On a network, you can install this package on many client machines, while the server
package may be installed on only one machine.
При тестировании столкнулся с проблемой - при формировании расчетного листка за 2 месяца или более долго думает и в итоге выдаёт- На сервере недостаточно памяти для выполнения задания .
За месяц тот же отчет формирует без проблем.
Пробовал формировать прочие отчеты за разные периоды - проблем не возникло.
Физически на сервере 64Гб ОЗУ.
В этих делах не мастер конечно, но пару вариантов могу предложить:
1) Поставьте последнюю платформу 8.3.12. В 8.3.13 и далее, пока не совсем стабильны и ни для одной конфигурации не требуется.
2) Поставьте х64, у х32 есть ограничение по памяти.
(2) Даунгрэйд платформы помог.
на 8.3.12.1790 всё заработало.
Спасибо всем, кто откликнулся.
Дальше продолжаю тестирование.
(5) Насколько я понимаю, сервер приложений. rphost при этом начинает жрать память, разрастается до 2гиг примерно, за тем эта ошибка.
Логи скуля завра погляжу.
больше 3.5 Гб не сможет взять, сколько бы не ставили памяти на сервер, отсюда и надо плясать
И хорошо бы настройки кластера приложить, а то курсы провидцев сегодня закрыты
больше 3.5 Гб не сможет взять, отсюда и надо плясать
И хорошо бы настройки кластера приложить, а то курсы провидцев сегодня закрыты
Под виндой ни разу больше 2х рабочих процессов не запускалось. на 30 человек.
А тут тестовый сервер. один пользователь и один, далеко не самый сложный, отчет.
Неужели всё так плохо до никсами? будем исходить из того, 3.5 гига для этой задачи достаточно.
По настройкам, Сервер приложений 1с всё по дефолту.
Могу завтра выложить postgresql.conf, но как писал выше, с дефолтными настроками постгри тоже самое было.
Какие ещё настройки интересны?
- для начала 0 поменяйте на минус -1
В принципе - можете смотаться в мою публикацию и поставить как там
(13)
Отключение ограничений по ни Максимальному объему памяти рабочих процессов ни по Безопасному расходу памяти за один вызов ничего не дало.
Памяти потребляет, что с "0", что с "-1" совершенно одинаково.
Пик потребления примерно 2 гига на процесс и 2.5гига всего системной памяти. (см скрин), затем резко высвобождается, примерно 1 гиг ОЗУ и вылазит ошибка(второй скрин).
Еще несколько отчетов эту ошибку вызывают. Расчётно платежная ведомость, даже в пределах одного месяца не формируется.
(15)Можно попробовать технологическим журналом понять сколько уходит памяти на сервер 1С, но так конечно х64 надо ставить там не будет ограничений
(18) В 8.3.12. Всё нормально, похоже все же глюк платформы был.
(19) Не решился самый свежий ставить пока.
(1)Поставьте сервер 1с х64. У меня весной подобная проблема была - нехватка памяти. Если раньше работало то не факт, что так будет всегда.
В этих делах не мастер конечно, но пару вариантов могу предложить:
1) Поставьте последнюю платформу 8.3.12. В 8.3.13 и далее, пока не совсем стабильны и ни для одной конфигурации не требуется.
2) Поставьте х64, у х32 есть ограничение по памяти.
(2) Платформа последняя была на момент установки . гляну завтра мож что новее есть.
Не так прочитал. да, как вариант попробую даунгреднуть платформу.
2. Лицензии на платформу 64 нет. Апгрейд не предполагается.
Данная база без проблем крутиться на 32 битном сервере Win2008R2+1C32+MSSQL2008x64. и 30 человек активных пользователей.
Железо там старое. быстродействия не хватает, но нехватки памяти ни разу не было замечено.
Тут, скорее или с настройками что не так или какой-то запрос криво с постгри работает.
(3) Может и настройки. Тут уже было как то у человека проблемы, не хватало памяти для обновления/реструктуризации базы. Хотя место полно было, пока х64 не поставил.
(2) Даунгрэйд платформы помог.
на 8.3.12.1790 всё заработало.
Спасибо всем, кто откликнулся.
Дальше продолжаю тестирование.
(7) не находит: Ошибка на сервере
К сожалению, произошла внутренняя ошибка сервера
код ошибки какой?
(9) Так нормально.
У меня аварийного завершения работы нет. Показывает эту ошибку и всё. Программа продолжает работать.
Если не хотите быть подопытными кроликами, то не стоит ставить платформу больше рекомендуемой по 3 цифре. Так как после предварительных тестов их пускаю в маштабный тест, тестируя на всех пользователях, кто любит ставить по рекомендациям 1С.
P.S. Думаю этот прием многим знаком, когда кажется что в тесте все ок, а в релизе оказывается, что, что то не учли.
(21) Да это понятно. Но сервер то тестовый, вот и поставил самую свежую )
на боевом платформу редко обновляю, в основном когда конфигурация того просит.
Работоспособности добился.
Теперь надо производительность отлаживать - пока что-то совсем не радует.
Субъективно, по ощущениям работает на уровне старого сервера семилетней давности.
Тест Гилева 15 всего выдаёт.
Этот параметр, как рекомендует 1С установил:
lc_messages = 'C'
Пробовал менять на en_US.UTF-8
Тогда постгри совсем не стартует.
В логах системы:
Пробовал менять на ru_RU.UTF-8 , тогда ругается, как в первом случае, только по-русски.
Еще столкнулся с ошибкой в БГУ 1.0
Ошибка выскакивает в настройках обмена с зарлпатой.
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/dlist:
по причине:
Ошибка СУБД:
ERROR: index key does not match expected index column
По (25) Вопрос остаётся открытым.
На данный момент Установлена платформа 8.3.13.1809 и PostgreSQL 10.5-24.1C.
Пробовал вместо линуксового использовать 1С сервер под Виндовс, так же в связке с этой СУБД, результат тот же.
Если смысл попробовать другую сборку PostgreSQL, например от Postgres Professional?
Читайте также: