Ошибка субд xx001 error invalid page in block

При нарушении целостности файловой системы сервера баз данных PostgreSQL, последний выдает “Ошибка СУБД” 1С, и часто сопровождается текстом, типа “ERROR: invalid page header in block ХХХХХ of relation base/ХХХХХ/ХХХХХ”.

Для начала надо выяснить в каких таблицах БД PostgreSQL возникает ошибка “ERROR: invalid page header in block…”. Для этого обращаемся к логам или пытаемся снять дамп базы данных, например подключившись к СУБД утилитой pgAdmin. Если возникает ошибка “Ошибка СУБД” в 1С, наверняка найдется хотя бы 1 испорченная таблица. В моем случае ошибка возникла при дампе public._inforg60691.

Для того, чтобы восстановить сломанную таблицу, выполним 3 запроса:
SET zero_damaged_pages = on;
VACUUM FULL public._inforg60691 ;
REINDEX TABLE public._inforg60691 ;

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

Следующим этапом исправления ошибки СУБД в 1С будет Тестирование и исправление базы в конфигураторе 1С. Для этого запускаем испорченную БД в конфигураторе. Через пункт Администрирование – Тестирование и исправление ИБ пробуем восстановить логическую целостность нашей базы. Обратите внимание, на галочки, выбранные на изображении.

We have setup database postgresql 11 on a system. There are about 8 tables. From few days, we are facing this problem

ERROR: invalid page in block 9698 of relation base/16385/16560 SQL state: XX001

According to my research, we should set set zero_damaged_pages=on; to fix this issue. We have set and executed few select queries that works fine. Then we decided to take backup of this database via pg_dump. This job was not completed successfully but copied all records.

Now, on new system, we imported backup, we have come to know that database schema is not properly copied here due to which data duplication occured. We repeated this with another database that was fine. All things works fine including restore.

Finally, I conclude that due to error in a block of page, database was not properly backed up. Is there any such option like set zero_damaged_pages=on; in pg_dump to ignore error page but complete the back or any other solution.

   John83

25.11.22 — 17:57

   John83

1 — 25.11.22 — 18:06

win 64

   ДедМорроз

2 — 25.11.22 — 18:09

У вас есть побмтая база данных в postgres.

Что-то пытаться нужно делать с ней,а также понять,что произошло.

Вылетел сеанс — это не причина,а следствие.

   Trimax

3 — 25.11.22 — 18:22

(0) Была аналогичная ситуёвина.

Выгрузил в дт. Развернул на файловой. Заработала. Выгрузил в дт из файловой. Снес базу в постгрес. Создал заново. Загрузил файловый дт-шник. Все заработало.

ПыСы. Вычистил все кэши изначально.

   Trimax

4 — 25.11.22 — 18:27

+ (3) Наперед смотри проблемы с файловой системой и далее на проблемы с железом (жесткие диски)

   Hmster

5 — 25.11.22 — 20:10

(1) говорят таблицу с конфигом можно из бэкапа взять — если только модули менялись

   ДедМорроз

6 — 25.11.22 — 20:25

А диск,случаем,не ssd ?

   John83

7 — 25.11.22 — 22:21

(6) М.2 ssd самсунг

то ли 960 или 860

   Guk

8 — 25.11.22 — 22:23

никогда не понимал, а что движет людьми, которые разворачивают рабочую базу на постриг?…

   Тындр

9 — 25.11.22 — 23:16

(8) Я когда-то так сделал. Клиент не хотел лицензий мелко-мягких. Но косяки возникли практически сразу же, и пришлось ставить тот же MS SQL Express, благо все было в рамках ограничений

   vovastar

10 — 25.11.22 — 23:20

   Тындр

11 — 25.11.22 — 23:31

(10) Это прекрасно. Но в отличии от ВК, в 1С наиболее проработали и протестировали (освоили короче) вариант с MS SQL. А простые 1С-ники, в отличии от программистов ВК, могут только попытаться зарегистрировать ошибку в 1С.

ВК делает для себя, 1С — для всех.

Для 1с важно, чтобы было к кому обратиться (кроме себя) в случае возникновения ошибок с СУБД (так было, как минимум, до 2022 — сейчас я не уверен).

В общем, неоднозначно все. Я постгри лет пять уже даже не пытался использовать.

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

   МимохожийОднако

12 — 26.11.22 — 00:55

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

   John83

13 — 26.11.22 — 12:56

(12) архив в dt

перед самим обновлением, не делался

   lubitelxml

14 — 26.11.22 — 15:05

(13) Люди делятся на два вида: те, кто не делает бэкапы, и те, кто уже делает. (С) не мое

   lubitelxml

15 — 26.11.22 — 15:05

ИМХО постгря зло

   John83

16 — 26.11.22 — 15:24

(14) т.е. ты даже перед каждым обновлением (пусть даже модуль поменял), делаешь архив?

   GANR

17 — 26.11.22 — 15:37

   GANR

18 — 26.11.22 — 15:38

(8) постгрес бесплатный, на лицензиях экономия

   Krendel

19 — 26.11.22 — 17:10

(8) а с этим когда то были проблемы? Такая же работа как с мсом или ораклом

   Garykom

20 — 26.11.22 — 17:11

(19) Надо признать что PostgreSQL под Windows это легкий изврат в т.ч. с 1С

Вот под Linux оно супер

   Guk

21 — 26.11.22 — 18:38

(19) на виндовых серверах, судя по веткам на мисте, это всегда проблема…

   dmpl

22 — 28.11.22 — 07:14

(16) Именно. При этом надо периодически проверять разворачиваемость бэкапов

   Bigbro

23 — 28.11.22 — 07:18

(14) и тех кто проверяет работоспособность бэкапов ))))

   Seriy_Volk

24 — 28.11.22 — 07:38

(0) настроить технологический журнал и глянуть, на запросе к какой таблице падает платформа. Далее в зависимости, что за таблица является проблемной — починить запросом/заменить корректной из бэкапа и т.п.

   John83

25 — 05.12.22 — 23:08

(17) полезная ссылочка, спасибо!

при вакууме ругается на такую таблицу _inforg20355_2, но ее в структуре БД не вижу, есть только _inforg20355 (регистр сведений).

Это как?

   timurhv

26 — 05.12.22 — 23:09

(25) Это индексы

(26) реиндексировать?

Буквально вчера один наш клиент пожаловался, что у него делаются бэкапы в базе 1С живущая на PostgreSQL. В связи с тем что мы предоставляем им только VPS и не более того, мы не ведали что у них там творится внутри собственно. А как оказалось уже достаточно давно бэкапы не пишутся ибо у них своего админа тоже нет и никто за этим не следит.

Отправили нам обращение, посмотрели что у них там происходит и видим следующее при попытке снять резервную копию:

ERROR: invalid page in block 2196 of relation base/349583/364737

Потратив целых 15 минут выяснилось что так просто взять и нажать кнопочку «Хорошо» уже не получится и какого то штатного решения нет от слова «Совсем». Готовых скриптов тоже нет. В итоге решив что надо бы опубликовать найденное решение для тех кто использует PostgreSQL на Windows.

1. Запускаем pgAdmin.
2. Запускаем Query Tool и:
   1. Путь к базе думаю ни у кого не будет вызывать сомнения с какой базой возникла проблема, по этому опустим метод поиска имени базы зная только base/349583
   2. Далее что бы надо вставить текст:
      SELECT pg_filenode_relation(0, 364737); — в результате получаем имя таблицы. У нас это была таблица «_document143_vt2652»
   3. Теперь нам надо запустить её восстановление:
      SET zero_damaged_pages = on;
      VACUUM FULL _document144;
3. По окончании выполнения надо выполнить переиндексацию всей базы!

Надо учесть, что часть данных может быть утеряно из таблицы!

Media failure is one of the crucial things that the database administrator should be aware of. Media failure is nothing but a physical problem reading or writing to files on the storage medium.

A typical example of media failure is a disk head crash, which causes the loss of all files on a disk drive. All files associated with a database are vulnerable to a disk crash, including datafiles, wal files, and control files.

This is the comprehensive post which focuses on disk failure in PostgreSQL and the ways you can retrieve the data from PostgreSQL Database after failure(other than restoring the backup).

In this post, we are going to do archaeology on the below error and will understand how to solve the error.

WARNING: page verification failed, calculated checksum 21135 but expected 3252
ERROR: invalid page in block 0 of relation base/13455/16395

During the process, you are going to learn a whole new bunch of stuff in PostgreSQL.

PostgreSQL Checksum: The definitive guide

• Chapter 1: What is a checksum?
• Chapter 2: PostgreSQL checksum: Practical implementation
• Chapter 3: How to resolve the PostgreSQL corrupted page issue?

With v9.3, PostgreSQL introduced a feature known as data checksums and it has undergone many changes since then. Now we have a well-sophisticated view in PostgreSQL v12 to find the checksums called pg_checksums.

But what is a PostgreSQL checksum?

When the checksum is enabled, a small integer checksum is written to each “page” of data that Postgres stores on your hard drive. Upon reading that block, the checksum value is recomputed and compared to the stored one.

This detects data corruption, which (without checksums) could be silently lurking in your database for a long time.

Good, checksum, when enabled, detects data corruption.

How does PostgreSQL checksum work?

PostgreSQL maintains page validity primarily on the way in and out of its buffer cache.

Also read: A comprehensive guide – PostgreSQL Caching

From here we understood that the PostgreSQL page has to pass through OS Cache before it leaves or enters into shared buffers. So page validity happens before leaving the shared buffers and before entering the shared buffers.

when PostgreSQL tries to copy the page into its buffer cache then it will (if possible) detect that something is wrong, and it will not allow page to enter into shared buffers with this invalid 8k page, and error out any queries that require this page for processing with the ERROR message

ERROR: invalid page in block 0 of relation base/13455/16395

If you already have a block with invalid data at disk-level and its page version at buffer level, during the next checkpoint, while page out, it will update invalid checksum details but which is rarely possible in real-time environments.

confused, bear with me.

And finally,

If the invalid byte is part of the PostgreSQL database buffer cache, then PostgreSQL will quite happily assume nothing is wrong and attempt to process the data on the page. Results are unpredictable; Some times you will get an error and sometimes you may end up with wrong data.

How PostgreSQL Checks Page Validity?

In a typical page, if data checksums are enabled, information is stored in a 2-byte field containing flag bits after the page header.

Also Read: A comprehensive guide on PostgreSQL: page header 

This is followed by three 2-byte integer fields (pd_lower, pd_upper, and pd_special). These contain byte offsets from the page start to the start of unallocated space, to the end of unallocated space, and to the start of the special space.

The checksum value typically begins with zero and every time reading that block, the checksum value is recomputed and compared to the stored one. This detects data corruption.

Checksums are not maintained for blocks while they are in the shared buffers – so if you look at a buffer in the PostgreSQL page cache with pageinspect and you see a checksum value, note that when you do page inspect on a page which is already in the buffer, you may not get the actual checksum. The checksum is calculated and stamped onto the page when the page is written out of the buffer cache into the operating system page cache.

Also read: A comprehensive guide – PostgreSQL Caching

Let’s work on the practical understanding of whatever we learned so far.

I have a table check_corruption wherein I am going to do all the garbage work.

•  my table size is 8 kB.
•  has 5 records.
•  the version I am using is PostgreSQL v12.

First, check whether the checksum is enabled or not?

[postgres@stagdb ~]$ pg_controldata -D /u01/pgsql/data | grep checksum
Data page checksum version: 0
[postgres@stagdb ~]$

It is disabled.

Let me enable the page checksum in PostgreSQL v12.

Syntax: pg_checksums -D /u01/pgsql/data –enable –progress –verbose

Again, check the status of checksums in PostgreSQL

[postgres@stagdb ~]$
[postgres@stagdb ~]$ pg_controldata -D /u01/pgsql/data | grep checksum
Data page checksum version: 1
[postgres@stagdb ~]$

we can disable the checksums with –disable option

Let’s first check the current data directory for errors, then play with data.

To check the PostgreSQL page errors, we use the following command.

pg_checksums -D /u01/pgsql/data –check

[postgres@stagdb ~]$ pg_checksums -D /u01/pgsql/data –check
Checksum operation completed
Files scanned: 969
Blocks scanned: 3006
Bad checksums: 0
Data checksum version: 1
[postgres@stagdb ~]$

Warning!! Do not perform the below case study in your production machine.

As the table check_corruption data file is 16490, I am going to corrupt the file with the Operating system’s dd command.

dd bs=8192 count=1 seek=1 of=16490 if=16490

[postgres@stagdb 13455]$ dd bs=8192 count=1 seek=1 of=16490 if=16490

Now, log in and get the result

I got the result, but why?

I got the result from shared buffers. Let me restart the cluster and fetch the same.

/usr/local/pgsql/bin/pg_ctl restart -D /u01/pgsql/data

But again why?

As we discussed earlier, during restart my PostgreSQL has replaced error checksum with the value of shared buffer.

How can we trigger a checksum warning?

We need to get that row out of shared buffers. The quickest way to do so in this test scenario is to restart the database, then make sure we do not even look at (e.g. SELECT) the table before we make our on-disk modification. Once that is done, the checksum will fail and we will, as expected, receive a checksum error:

i.e., stop the server, corrupt the disk and start it.

• /usr/local/pgsql/bin/pg_ctl stop -D /u01/pgsql/data
• dd bs=8192 count=1 seek=1 of=16490 if=16490
• /usr/local/pgsql/bin/pg_ctl start -D /u01/pgsql/data

During the next fetch, I got below error

postgres=# select * from check_corruption;
2020-02-06 19:06:17.433 IST [25218] WARNING: page verification failed, calculated checksum 39428 but expected 39427
WARNING: page verification failed, calculated checksum 39428 but expected 39427
2020-02-06 19:06:17.434 IST [25218] ERROR: invalid page in block 1 of relation base/13455/16490
2020-02-06 19:06:17.434 IST [25218] STATEMENT: select * from check_corruption;
ERROR: invalid page in block 1 of relation base/13455/16490

Let us dig deeper into the issue and confirm that the block is corrupted

There are a couple of ways you can find the issue which includes Linux commands like

• dd
• od
• hexdump

Usind dd command : dd if=16490 bs=8192 count=1 skip=1 | od -A d -t x1z -w16 | head -1

[postgres@stagdb 13455]$ dd if=16490 bs=8192 count=1 skip=1 | od -A d -t x1z -w16 | head -2
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 4.5e-05 seconds, 182 MB/s
0000000 00 00 00 00 a0 fc 7e 01 03 9a 00 00 2c 00 80 1d >……~…..,…<

here,

00 00 00 00 a0 fc 7e 01 the first 8 bytes indicate pd_lsn and the next two bytes

03 9a indicates checksums.

Using hexdump : hexdump -C 16490 | head -1

[postgres@stagdb 13455]$ hexdump -C 16490 | head -1
00000000 00 00 00 00 a0 fc 7e 01 03 9a 00 00 2c 00 80 1d |……~…..,…|
[postgres@stagdb 13455]$

Both hexdump and dd returned same result.

Let’s understand what our PostgreSQL very own pg_checksums has to say?

command: pg_checksums -D /u01/pgsql/data –check

[postgres@stagdb 13455]$ pg_checksums -D /u01/pgsql/data –check
pg_checksums: error: checksum verification failed in file “/u01/pgsql/data/base/13455/16490”, block 1: calculated checksum 9A04 but block contains 9A03
Checksum operation completed
Files scanned: 968
Blocks scanned: 3013
Bad checksums: 1
Data checksum version: 1
[postgres@stagdb 13455]$

here, according to pg_checksums checksum 9A03 is matching with that of hexdump’s checksum 9A03.

Converting Hex 9A03 to decimals, I got 39427

which is matching the error

2020-02-06 19:06:17.433 IST [25218] WARNING: page verification failed, calculated checksum 39428 but expected 39427

How to resolve the PostgreSQL corrupted page issue?

use the below function to find the exact location where the page is corrupted.

Now, using the function find_bad_row(), you can find the ctid of the corrupted location.

you need hstore extension to use the function

postgres=# CREATE EXTENSION hstore;
CREATE EXTENSION
postgres=#

postgres=# select find_bad_row(‘check_corruption’);
2020-02-06 19:44:24.227 IST [25929] WARNING: page verification failed, calculated checksum 39428 but expected 39427
2020-02-06 19:44:24.227 IST [25929] CONTEXT: PL/pgSQL function find_bad_row(text) line 21 at FETCH
WARNING: page verification failed, calculated checksum 39428 but expected 39427
NOTICE: LAST CTID: (0,5)
NOTICE: XX001: invalid page in block 1 of relation base/13455/16490
find_bad_row
————–
(0,5)
(1 row)

Deleting that particular CTID will resolve the issue

postgres=# delete from check_corruption where ctid='(0,6)’;
DELETE 1
postgres=#

If deleting ctid has not worked for you, you have an alternative solution which is setting zero_damaged_pages parameter.

Example.,

postgres=# select * from master;
WARNING: page verification failed, calculated checksum 8770 but expected 8769
ERROR: invalid page in block 1 of relation base/13455/16770
postgres=#

I can’t access the data from table master as block is corrupted.

Solution:

postgres=# SET zero_damaged_pages = on;
SET

postgres=# vacuum full master;

here, it cleared the damaged page and gave the rest of the result.

What your document has to say?

zero_damaged_pages (boolean): Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current transaction. Setting zero_damaged_pages to on causes the system to instead report a warning, zero out the damaged page in memory, and continue processing. This behavior will destroy data, namely all the rows on the damaged page. However, it does allow you to get past the error and retrieve rows from any undamaged pages that might be present in the table. It is useful for recovering data if corruption has occurred due to a hardware or software error. You should generally not set this on until you have given up hope of recovering data from the damaged pages of a table. Zeroed-out pages are not forced to disk so it is recommended to recreate the table or the index before turning this parameter off again. The default setting is off, and it can only be changed by a superuser.

There are a couple of things to be aware when using this feature though. First, using checksums has a cost in performance as it introduces extra calculations for each data page (8kB by default), so be aware of the tradeoff between data security and performance when using it.

There are many factors that influence how much slower things are when checksums are enabled, including:

1. How likely things are to be read from shared_buffers, which depends on how large shared_buffers is set, and how much of your active database fits inside of it
2. How fast your server is in general, and how well it (and your compiler) are able to optimize the checksum calculation
3. How many data pages you have (which can be influenced by your data types)
4. How often you are writing new pages (via COPY, INSERT, or UPDATE)
5. How often you are reading values (via SELECT)

The more that shared buffers are used (and using them efficiently is a good general goal), the less checksumming is done, and the less the impact of checksums on database performance will be. On an average if you enable checksum the performance cost would be more than 2% and for inserts, the average difference was 6%. For selects, that jumps to 19%. Complete computation benchmark test can be found here 

Bonus

You can dump the content of the file with pg_filedump before and after the test and can use diff command to analyze data corruption

1. pg_filedump -if 16770 > before_corrupt.txt
2. corrupt the disk block
3. pg_filedump -if 16770 > before_corrupt.txt
4. diff or beyond compare both the files.

Thank you for giving your valuable time to read the above information. I hope the content served your purpose in reaching out to the blog.
Suggestions for improvement of the blog are highly appreciable. Please contact us for any information/suggestions/feedback.

If you want to be updated with all our articles

please follow us on Facebook | Twitter
Please subscribe to our newsletter.