Ошибка субд xx001 error could not read block - Ремонт и установка крупной бытовой техники

I have a service running and inserting data (a lot of data). Sometime, and this is only about few weeks, I receive this error:

ERROR: XX001: could not read block 2354 of relation 1663/17633/17925: read only 0 of 8192 bytes.

This error is from the Npgsql connector of PostGresql:

Exception trace:    at Npgsql.NpgsqlConnector.CheckErrors()
at Npgsql.NpgsqlConnector.CheckErrorsAndNotifications()
at Npgsql.NpgsqlCommand.ExecuteCommand()
at Npgsql.NpgsqlCommand.ExecuteNonQuery()

If I do the query that create that error inside PGAdmin, I have this error too. Anyone have an idea of why this Insert query that has nothing special has this error? This table has a primary key but not Foreign Key and I have verified manually, this table doesn’t contain the primary key.

How can I solve that error?

Источник

Ошибка СУБД:

Продолжение сообщения может быть различным:

1. DATABASE не пригоден для использования

2. ERROR: type «tt7» already exists

3. ERROR: could not read block

DATABASE не пригоден для использования

Пример полного текста ошибки:

Ошибка при выполнении операции с информационно базой по причине: Ошибка СУБД: DATABASE не пригоден для использования

Описание ошибки:

База не запускается после установки и создания.

Решения:

Установим версию предназначенную для работы с 1С:Предприятием. Скачать такую можно с сайта 1С (при наличии купленного ИТС и открытого доступа), или приобрести у PostgresPro.

Либо проверим все ли зависимости были установлены. И установим недостающие.

ERROR: type «tt7» already exists

Пример полного текста ошибки:

Ошибка СУБД:

ERROR: type «tt7» already exists

HINT: A relation has an associated type of the same name, so you must use a name that doesn‘t conflict.

Описание:

Данная ошибка является «плавающей» и может возникать в различных местах

Решение:

Выгрузим и загрузим базу данных средствами 1С:Предприятия(через файл *.dt).

ERROR: could not read block

Ошибка при выполнении операции с информационно базой по причине: Ошибка СУБД: ERROR: could not read block ... in file «» Input/output error

Описание ошибки:

База не запускается. Разрушились диски.

Решения:

Переносим базу на другую дисковую систему.

Разворачиваем из резервной копии.

Не удалось запустить сервер PostgreSQL

Пример полного текста ошибки:

Не удалось привязаться к адресу. Адрес уже используется. Возможно порт 5432 занят другим процессом postmaster? Система БД выключена.Не удалось запустить сервер.

Описание:

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

В этой ситуации при попытке запуска видно ошибку – сервер не запускается.

А при проверке состояния видно, что сервер работает.

netstat –tlnp | grep 5432

Если проверим запущенные процессы пользователя postgres, то можно увидеть, что порт 5432 занят кластером PostgreSQL, только запущенным из каталога по умолчанию.

Решение:

Остановим работающий кластер сервера СУБД.

/opt/pgpro/ent—10/bin/pg_ctl —locale=ru_RU.UTF—8 —D /var/lib/pgpro/ent—10/data stop

Инициализируем кластер из нового каталога(если он не инициализирован).

/opt/pgpro/ent—10/bin/initdb —locale=ru_RU.UTF—8 —D /pgpro/pgdata

Запустим из нового каталога.

/opt/pgpro/ent—10/bin/pg_ctl —locale=ru_RU.UTF—8 —D /pgpro/pgdata start

Длительный запуск 1С:Предприятия при работе с СУБД PostgreSQL

Описание:

Длительный запуск, длительный захват объектов в хранилище, длительное сохранение конфигурации 1С:Предприятия.

Решение:

Такая проблема может быть связано с настройками СУБД PostgreSQL.

Рассчитаем настройки СУБД.

Описание настроек приведено на ИТС.

Выполним настройки, для этого перейдем в терминал psql:

Через psql установим параметры командой ALTER SYSTEM SET(параметры необходимо указать для вашей СУБД):

Пример настроек:

ALTER SYSTEM SET shared_buffers = ’96GB’;

ALTER SYSTEM SET effective_cache_size = ‘288GB’;

ALTER SYSTEM SET maintenance_work_mem = ’20GB’;

ALTER SYSTEM SET wal_buffers = ’16MB’;

ALTER SYSTEM SET default_statistics_target = 100;

ALTER SYSTEM SET random_page_cost = 1.1;

ALTER SYSTEM SET effective_io_concurrency = 200;

ALTER SYSTEM SET work_mem = ’10GB’;

ALTER SYSTEM SET max_worker_processes = 44;

ALTER SYSTEM SET max_parallel_workers_per_gather = 22;

ALTER SYSTEM SET temp_buffers = ‘265MB’;

ALTER SYSTEM SET wal_level = ‘replica’;

ALTER SYSTEM SET max_replication_slots = ‘8’;

ALTER SYSTEM SET max_wal_senders = ’32’;

ALTER SYSTEM SET autovaccuum = ‘on’;

ALTER SYSTEM SET autovaccuum_max_workers = 16;

ALTER SYSTEM SET autovacuum_naptime = ’20s’;

ALTER SYSTEM SET bgwriter_delay = ’20ms’;

ALTER SYSTEM SET bgwriter_lru_multiplier = 4.0;

ALTER SYSTEM SET bgwriter_lru_maxpages = 400;

ALTER SYSTEM SET synchronous_commit = ‘off’;

ALTER SYSTEM SET checkpoint_segments = 256;

ALTER SYSTEM SET checkpoint_completion_target = 0.9;

ALTER SYSTEM SET min_wal_size = ‘4GB’;

ALTER SYSTEM SET max_wal_size = ‘8GB’;

ALTER SYSTEM SET ssl = ‘off’;

ALTER SYSTEM SET max_files_per_process = 1000;

ALTER SYSTEM SET standard_conforming_strings = ‘off’;

ALTER SYSTEM SET escape_string_warning = ‘off’;

ALTER SYSTEM SET max_locks_per_transaction = 256;

ALTER SYSTEM SET max_connections = 15000;

**Из файла *xlsx загружаются в 1С иероглифы/ в файл выгружаются иероглифы.**

Описание ошибки:

При загрузке данных из файла *.xlsx в 1С отображаются иероглифы. Используемая СУБД PostgreSQL/PostgresPro.

Также возможна проблема с кодировкой в выгружаемом файле из 1С:

Решение:

На сервере СУБД проверим и выполним настройку локали.

1. Проверим наличие локали:

2. Проверим переменную:

Корректное значение результатов выполнения команд 2, 3:

3. Если результат не соответствует, выполним:

export LANG=«ru_RU.UTF-8»

4. Выполним:

localectl set—locale LANG=ru_RU.utf8

5. Выполним перезапуск серверов СУБД

Источник

ExRq

22.03.12 — 06:39

Добрый день.

Случилась беда с базой

Конф: v8 УТ 10.3.6.8

база на PostgreSQL 8.4.3-3.1C

При тестировании и исправлении вылетает ошибка

Ошибка СУБД

Error: Could not read block 26637 of relation base/50468/3305609: invalid argument

В конфигураторе останавливается на надписи:

Проверка логической целостности. Регистры накопления. Продажи. — 15%

Дамп базы не делается ни средствами 1с ни PostgreSQL.

База работает. Сбоев нет.

Кто сталкивался? Что делать?

DMLangepas

1 — 22.03.12 — 06:44

прогони копию базы, её же штатной проверкой, в папке 1cv82/../bin/chdbfl.exe

как вариант попробуй

ExRq

2 — 22.03.12 — 06:50

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

DMLangepas

3 — 22.03.12 — 07:09

(2) а новую копию создать нельзя??

ExRq

4 — 22.03.12 — 07:15

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

zva

5 — 22.03.12 — 07:16

Ну пробуй через XML в чистую базу выгрузить, возможно частями

ExRq

6 — 22.03.12 — 07:21

Хотелось бы конечно выгрузить базу штатными средствами и потом уже сменить PostgreSQL или дело не в нем ведь?

DMLangepas

7 — 22.03.12 — 07:34

(6) я просто не знаю, в SQL вообще не скопировать базу как в файловых??? там ведь есть путь к базе?

ЧеловекДуши

8 — 22.03.12 — 07:34

Поди БД файловая

vde69

9 — 22.03.12 — 07:36

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

судя по ошибке у тебя сама посгрей посыпалась

ExRq

10 — 22.03.12 — 07:37

Я ведь написал БД на PostgreSQL, Резервная копия не делается ни средствами 1с ни средствами Postgre

Мыш

11 — 22.03.12 — 07:37

(8) Написано же, «база на PostgreSQL 8.4.3-3.1C «

ExRq

12 — 22.03.12 — 07:40

(9) Отчеты строятся по любым периодам, ошибок не бывает..или это не связано?

Мыш

13 — 22.03.12 — 07:40

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

ExRq

14 — 22.03.12 — 07:43

(13) Опасно конечно заниматься этим без резервной копии..может есть ещё варианты?

vde69

15 — 22.03.12 — 07:48

(14) а копию сделать кто мешает?

останавливаешь службу и копируешь файлы

Мыш

16 — 22.03.12 — 07:50

(14) Образ винчестера сделай.

ExRq

17 — 22.03.12 — 07:50

(14)А постгри потом стартанет если заменить базу на старую?

ExRq

18 — 22.03.12 — 07:51

(16)

zva

19 — 22.03.12 — 07:56

(17) Без танцев с бубном точно нет, но зато файлы останутся…

«Продажи» — первый поломатый регистр, на котором спотыкается ТиИ. Их может быть 100500…

ExRq

20 — 22.03.12 — 08:01

(19) Плохо дело чувствую

ExRq

21 — 22.03.12 — 08:05

Кстати, идея. Недавно делал РБД с этого узла и она создалась без сбоев. Там конечно обрезанный узел но нужно попробовать на полном плане. А с файловой уже проще.

vde69

22 — 22.03.12 — 08:16

сделай так:

1. создай новую пустую базу с этой конфигурацией

2. экспортом гони таблицы из поломатой в новую

3. составляешь список таблиц которые не удалось копирнуть

4. принимаешь решение чего дальше

способ безопасный, геморный, но понятный

Kraft

23 — 22.03.12 — 08:20

(22) +1 за такой подход

ExRq

24 — 22.03.12 — 08:27

(22) Спасибо попробую.

Один вопрос Экспорт — это ты имеешь ввиду средство 1с или Postgre? Ни разу не сталкивался.

vde69

25 — 22.03.12 — 08:31

(24) средстави СУБД, я с пости не работал, я только со скулем, зато так например востанавливал базу 7.7 примерно 60 гигов после краха винта и скульного рековера, там черти что было

ExRq

26 — 22.03.12 — 08:39

(25) Понял Спасибо. Буду пробовать. Отпишусь.

Jofa

27 — 22.03.12 — 08:42

Беда случилась уже давно когда Выбирали СУБД на учёбу забыли денег выделить ..)

ExRq

28 — 22.03.12 — 08:55

))

ExRq

29 — 23.03.12 — 07:26

Нашел таблицу которая дает ошибку.

accumreg7721

ERROR: could not read block 26637 of relation base/50468/3305609: Invalid argument

Кто знает что за таблица?

vde69

30 — 23.03.12 — 08:03

(29) регист…

теперь тупо в новой базе сделай ТиИс и потом полное перепроведение, и все будет рабочее.

DMLangepas

31 — 23.03.12 — 08:03

(29) ERROR: could not read block 26637 of relation base/50468/3305609: Invalid argument

судя по последним словам, может это по больничным листам?)))))))

vde69

32 — 23.03.12 — 08:08

(30) хотя лучше не перепроведение, а что-то более правильное, на сколько я понял у тебя один регист «продажы» крякнул, подумай как его заполнить без перепроведения

ExRq

33 — 23.03.12 — 08:10

(29) Объясни что такое ТиИс?

И как в новой? — я не могу её залить в новую базу.

(30) Да конечно лучше как то заполнить )

Мыш

34 — 23.03.12 — 08:14

(33) Тестирование и Исправление.

ExRq

35 — 23.03.12 — 08:17

Тоесть перенести все таблицы в новую базу кроме этой и уже например средствами 1с её заполнить..? дошло

ExRq

36 — 23.03.12 — 08:27

А можно как то посмотреть что это за блок такой 26637?

vde69

37 — 23.03.12 — 08:28

(36) никак, это к 1с не имеет отношение, это номер страницы в файле субд

vde69

38 — 23.03.12 — 08:30

а вообще если такая ошибка появилась — это ОЧЕНЬ серьезный звонок админу, вариантов масса, от начала рассыпания дисков, до серьезных проблемм с софтом.

нет никакой гарантии что на этом сервере сабж не повторится но уже в КРУПНЫХ МАСШТАБАХ

ExRq

39 — 23.03.12 — 10:23

Спасибо за помощь vde69

Вяйнемейнен

40 — 23.03.12 — 10:58

В Postgre подобные ошибки случаются с завидным постоянством, и, что самое плохое, — нет штатных утилит по лечению тип DBCC в MSSQL, поэтому главное правило — регулярные архивы.

Схема лечения такой ошибки следующая.

В pgadmin нужно запустить переиндексацию с перебором всех таблиц, например, подобным скриптом:

CREATE OR REPLACE FUNCTION _Reindex_Base(

schema_name in name,

result out bigint

)

LANGUAGE plpgsql as $BODY$

DECLARE table_name name;

BEGIN

FOR table_name IN (

SELECT t.table_name

FROM information_schema.tables t

WHERE t.table_schema = schema_name

AND t.table_type = ‘BASE TABLE’

— AND t.table_name > ‘_reference84’

ORDER BY t.table_name

) LOOP

raise info ‘reindex %s’, table_name;

EXECUTE ‘REINDEX TABLE ‘

||quote_ident(schema_name)||’.’||quote_ident(table_name);

END LOOP;

RETURN;

END;

$BODY$;

SELECT result

FROM _Reindex_Base(‘public’);

Нормальные таблицы будут переиндексироваться, на битых будет спотыкаться.

Битые таблицы потом нужно идентифицировать, каким объектам базы они соответствуют — благо обработок по представлению структуре базы везде валяется немеряно.

Далее битые таблицы придется удалить и пересоздать — проще всего автогенерируемым CREATE скриптом в том же pgadmin.

После этого восстанавливать данные, исходя из важности потерянных таблиц и имеющихся архивов. Служебные данные, типа итогов регистров — переформировать; движения регистров — можно восстанавливать, можно заново получить перепроведением. Справочники, документы, перечисления, независимые регистры сведений — только восстанавливать из бэкапов — либо тянуть в виде таблиц Postgre, либо разворачиать архивные базы полностью и выгружать-загружать средствами 1С.

vde69

41 — 23.03.12 — 11:01

(40) вот по этому я и сижу на скуле а пости извени это пРости какое-то

ExRq

42 — 23.03.12 — 11:48

(40) Спасибо большое, сейчас пробую.

Господин ПЖ

43 — 23.03.12 — 11:52

не гонялся бы ты поп за дешевизной…

ExRq

44 — 23.03.12 — 12:49

Да уже тоже сижу думаю об этом..)

Мыш

45 — 23.03.12 — 13:39

Бесплатность линуксов нивелируется стоимостью поддержки.

ansh15

46 — 23.03.12 — 14:03

Это всего лишь стоимость несделанного вовремя бэкапа(ОС, СУБД и все остальное, практически, не имеет значения). Ключевая фраза в (3) — «Не уследил…»

ansh15

47 — 23.03.12 — 14:05

Извините, в (2)

Источник

When creating a new column on a table, I’m getting the following error:

ERROR: could not read block 167593 in file "pg_tblspc/16384/PG_9.4_201409291/16386/157223695.1": read only 0 of 8192 bytes
SQL state: XX001

Obviously not good, as SQL state XX001 means corrupt data. I’m not too bothered as this is not critical data and can relatively easily be re-loaded from the source.

However, after searching for similar issues, all I can see from other people is this error for ‘of relation base’, not ‘in file’. How is ‘in file’ different, and what does this mean? Is it more likely that I have a hardware issue?

Also, how can I check to see for certain that the data is corrupted?

asked May 4, 2016 at 8:59

MattMatt

4551 gold badge8 silver badges20 bronze badges

However, after searching for similar issues, all I can see from other
people is this error for ‘of relation base’, not ‘in file’. How is ‘in
file’ different, and what does this mean? Is it more likely that I
have a hardware issue?

No, it’s the same issue. The error message used to refer to the relation in older versions of PostgreSQL, but it was changed at some point (version 9.0, probably) to refer to the corresponding file instead.

I think the switch to the new message format happened here:

commit 23dc89d2c385e8e362cb4b8186b4d4ad02242ac0
Author: Heikki Linnakangas
Date: Wed Aug 5 18:01:54 2009 +0000

Improve error messages in md.c. When a filesystem operation like open() or
fsync() fails, say "file" rather than "relation" when printing the filename.

This makes messages that display block numbers a bit confusing. For example,
in message 'could not read block 150000 of file "base/1234/5678.1"', 150000
is the block number from the beginning of the relation, ie. segment 0, not
150000th block within that segment. Per discussion, users aren't usually
interested in the exact location within the file, so we can live with that.

To ease constructing error messages, add FilePathName(File) function to
return the pathname of a virtual fd.

answered May 4, 2016 at 11:04

Daniel VéritéDaniel Vérité

29.9k3 gold badges68 silver badges78 bronze badges

Источник

When creating a new column on a table, I’m getting the following error:

ERROR: could not read block 167593 in file "pg_tblspc/16384/PG_9.4_201409291/16386/157223695.1": read only 0 of 8192 bytes
SQL state: XX001

Obviously not good, as SQL state XX001 means corrupt data. I’m not too bothered as this is not critical data and can relatively easily be re-loaded from the source.

Also, how can I check to see for certain that the data is corrupted?

Источник