Ошибка субд xx001 error could not read block

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)

Источник

Ошибка СУБД:

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

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. Выполним перезапуск серверов СУБД

Источник

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

4451 gold badge8 silver badges18 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é

28.9k3 gold badges64 silver badges75 bronze badges

Источник

We are using EnterpriseDB PostGresql 8.3. I can’t simply take a good backup
because weeks have pass since the first error occurs.

I will try to Vacumm Full first, if nothing is fixed, I will try to pg_dump
like you suggest.

On Wed, Apr 1, 2009 at 11:49 AM, Emanuel Calvo Franco <
postgres(dot)arg(at)gmail(dot)com> wrote:

> 2009/3/31 Patrick Desjardins <mrdesjardins(at)gmail(dot)com>:
> > Hi,
> >
> > I have the error ERROR: XX001: could not read block 2354 of relation
> > 1663/17633/17925: read only 0 of 8192 bytes, but only sometime, when
> trying
> > to Insert data into a table. I would say that 99% of Insert works and
> 100%
> > of read works. This is only happenning since few weeks. I have done
> Vaccum
> > Analyze without any success (the vaccum take 65 minutes but nothing is
> > fixed, still have the ERROR XXX001). I have this error in the backend
> > application and when I do some Insert Query in the PgAdmin tool.
> >
>
> This kind of error occurs generally on 7.x versions or if you are using
> fsync =off and you have a surprised system down.
>
> Try to do a pg_dump of the database or clean (no delete) del wal files
> (this is not
> recommendable for new users).
>
> > What can I do to fix that problem?
> >
> > Thank you,
> >
>
>
>
> —
> Emanuel Calvo Franco
> Sumate al ARPUG !
> (www.postgres-arg.org —
> www.arpug.com.ar)
> ArPUG / AOSUG Member
> Postgresql Support & Admin
>

Источник

Ошибка СУБД при удалении

Автор Ginayat, 26 окт 2017, 14:30

0 Пользователей и 1 гость просматривают эту тему.

Добрый день!
Имеется база Бухгалтерия гос предприятие здраво 1.0.27.1 крутится на postgresql сервере
Изначально проблема была с выгрузкой не выгружалась база выдавал ошибку через постгрес тоже
Через предприятие нашли проблемный документ который не дает выгрузить базу вот хотели удалить этот документ через интерактивное удаление тоже не помогло выдает ошибку
на скриншоте (скриншот прилагается)
С 2016 года никто не обновлял и соответственно не выгружал базу
Прошу Помочь буду признателен!

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

Тестирование и исправление пробовали делать?

Цитата: MuI_I_Ika от 26 окт 2017, 14:57
Бедный российский госсектор денег им на номральные субд не выделяют вот и приходится мучиться со всякими коварными багами, которые никто раньше в глаза не видел.

Тестирование и исправление пробовали делать?

Да делали не помогает

А что за ошибка то, что не так с документом?

Цитата: MuI_I_Ika от 26 окт 2017, 15:13
А что за ошибка то, что не так с документом?

Не выгружается база , нашли причину из за чего не выгружается база в документе Отражение Зарплаты
Ошибка СУБД:
ERROR:could not read block 23962 in file «base/16402/340816»:Invalid argument
Это при удаление документе

А если его перезаписывать ошибка возникает?
А если распровести?
Очистить табличную часть?

А если поискать данный документ в базе и попробовать удалить непосредственно на таблице.

Естественно такие операции лучше сначала проделать на копии.

Цитата: Ginayat от 27 окт 2017, 08:59ERROR:could not read block 23962 in file «base/16402/340816»:Invalid argument

зделайте ТИИ средствами СУБД. MS SQL? Тогда

DBCC CHECKDB
[ ( database_name | database_id | 0
[ , NOINDEX
| , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
) ]
[ WITH
{
[ ALL_ERRORMSGS ]
[ , EXTENDED_LOGICAL_CHECKS ]
[ , NO_INFOMSGS ]
[ , TABLOCK ]
[ , ESTIMATEONLY ]
[ , { PHYSICAL_ONLY | DATA_PURITY } ]
[ , MAXDOP = number_of_processors ]
}
]
]

Спасибо за Сказать спасибо

Источник

01-17-2010, 04:45 AM

#1

Junior Member

XX001 error message. Database and reports not working.

Hey there.

While opening my cash game reports page, I got the following error message.

«ERROR: XX001: could not read block 2 of relation 1663/16403/16662: read only 0 of 8192 bytes»

The first time I tried it said I only had one hand recorded, then the second time it seems the reports page froze and the cursor is stuck on the ‘loading’ circle.

The HUD works fine and still shows previous stats. I have updated to the latest beta version.

Cheers in advance.

Last edited by Teahupoo; 01-17-2010 at 04:52 AM.
01-17-2010, 07:43 AM

#2

HM Support

Your database is corrupt and your harddisk can be damaged too.

You should first try to fix it with a reindex via pgadmin -> maintenance.

Run chkdsk on your harddisk too.

And i would recommend to do backups and save the original handhistories and export all hands as backup too.
01-17-2010, 08:30 AM

#3

Junior Member

Thanks for the quick reply. I have done both and nothing much has changed unfortunately, except for the fact that it is recording new hands into my reports. When I click on ‘this year’ it has started recording hands since I did the re-index, but I still get the error message when I click on ‘all hands’ and my reports are empty. These were the last few lines after the re-index. Any recommendations for further lines of action?

reindexedNOTICE: table «playerhandsflop» was reindexedNOTICE: table «playerhandsturn» was reindexedNOTICE: table «playerhandsriver» was reindexedNOTICE: table «players» was reindexedNOTICE: table «playervsplayer» was reindexedNOTICE: table «pokerhands» was reindexedNOTICE: table «compiledplayerresults» was reindexedNOTICE: table «compiledplayerresultspositionaction» was reindexedNOTICE: table «postflopactions» was reindexedNOTICE: table «compiledresults» was reindexed
ERROR: invalid page header in block 0 of relation «compiledplayerresults_month»

ERROR: invalid page header in block 0 of relation «compiledplayerresults_month»

Last edited by Teahupoo; 01-17-2010 at 08:54 AM.
01-17-2010, 02:12 PM

#4

*** HM3! ***

Try a new DB.

*Try creating a new UTF DB — http://www.holdemmanager.net/faq/afm…aspx?faqid=146
*Now import a small portion of your HMArchive so you can see if the problem exists in the new DB — http://www.holdemmanager.net/faq/afm…aspx?faqid=173
*If the new DB seems to work properly, you will want to import the rest of your archives to the new DB, export/import the hands from the old DB to the new DB, and export/import any player notes and tourney summaries — and then delete the old DB. — http://www.holdemmanager.net/faq/afmviewfa
q.aspx?faqid=21

Make sure you export/backup everything before deleting the old DB — http://www.holdemmanager.net/forum/s…ad.php?t=20754

If that doesn’t work, you will probably have to try reinstalling postgresql.

Please reinstall PostgreSQL using these steps — http://forums.holdemmanager.com/showthread.php?t=20755