Error while taking backup in Postgresql (Could not read Block X of relation base/Y/Z) - postgresql

while taking a backup from my PostgrSQL Database
it showing that
pg_dump: Dumping the contents of table "gtab17" failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR: invalid page header in block 9576 of relation base/17779/758869
pg_dump: The command was: COPY public.gtab17 (jrdetid, jrmid, acid, dr, cr, narr, ageamt) TO stdout;
i think my table gtab17 is corrupt
tried
Vaccum Full error on this table
INFO: vacuuming "public.gtab17" ; ERROR: row is too big: size 3256104, maximum size 8160
Analyze error
INFO: analyzing "public.gtab17" ;
ERROR: invalid page header in block 9576 of relation base/17779/758869
Database : PostgreSQL 9.2
OS : Windows XP SP3 ; FILESYSTEM : NTFS
i have googled but dint get any solution to solve this

It means, so your data file is corrupted - a solution is relative difficult - the best way is recovery from some older backup. You can try to fix it with replacing broken data page by zeroes - but you lost some data, and without some deeper knowledgeable you can destroy more than now it is.
REFER

Related

ERROR: attempted to read an unexpected stripe while reading columnar table daily_p2022_10_11, stripe with id=281134 is not flushed

I am getting this error in postgres alert log:
ERROR: attempted to read an unexpected stripe while reading columnar table daily_p2022_10_11, stripe with id=281134 is not flushed.
While trying vacuum, getting below :
ccap_proddb=> vacuum verbose daily_p2022_10_11;
ERROR: invalid columnar chunk entry
DETAIL: Chunk number out of range: 0
Not able to execute - Select count(*) from daily_p2022_10_11;
We have postgres 14.2 and citus 11.0-1

data corrupted in postgres - right sibling's left-link doesn't match: block 9550 links to 12028 instead of expected 12027 in index "log_attach_id_idx"

I am new to Postgres and we are using it for tests reports, we had an issue with our environment that entered duplicate keys to one of the table and since then we are getting this message when trying to run migration scripts:
error: migration failed: right sibling's left-link doesn't match: block 9550 links to 12028 instead of expected 12027 in index "log_attach_id_idx" in line 0: UPDATE log SET project_id = (SELECT project_id FROM item_project WHERE item_project.item_id=log.item_id LIMIT 1); (details: pq: right sibling's left-link doesn't match: block 9550 links to 12028 instead of expected 12027 in index "log_attach_id_idx")
I tried to run pg_dump and got this error:
pg_dump: error: query was: SELECT pg_catalog.pg_get_viewdef('457544'::pg_catalog.oid) AS viewdef
pg_dumpall: error: pg_dump failed on database "reportportal", exiting
Can anyone help here?
Restore your backup, and research what parameters you changed and what you did to end up with data corruption in the first place.

How to backup/recover database after a "missing chunk number 0" message?

PostgreSQL. When I try to backup the database via pgAdmin, I get error
pg_dump: error: Dumping the contents of table "filearchives" failed: PQgetResult() failed.
pg_dump: error: Error message from server: ������: missing chunk number 0 for toast value 1508672 in pg_toast_1245716
pg_dump: error: The command was: COPY public.filearchives (id, usedtime, docid, options, filesize, filename, stream) TO stdout;"
I followed these instructions: https://gist.github.com/supix/80f9a6111dc954cf38ee99b9dedf187a
There were similar errors for REINDEX and VACUUM on the main table (filearchives), but nothing for pg_toast and I was able to select all rows in the main table (filearchives), while there was supposed to be "Corrupted chunk read!".
When I do it via psql, there is no error message, but the backup is incomplete.
The database itself is working fine at the moment.
How to recover the database without removing records? Is there a way to create a backup?

Can not create backup of Firebird database because of the errors

At the time of backup firebird database (gbak -g -ig) I have the following error:
gbak: writing data for table ORDERS
gbak: ERROR:message length error (encountered 532, expected 528)
gbak: ERROR:gds_$receive failed
gbak:Exiting before completion due to errors
When I'm using gfix with different parameters (-v -full, -mend, -ignore), I have the message:
Summary of validation errors
Number of index page errors : 540
In firebird.log file I see the lines:
PC (Server) Thu Sep 20 08:37:01 2018
Database: E:\...GDB
Index 2 is corrupt on page 134706 level 1. File: ..\..\..\src\jrd\validation.cpp, line: 1699
in table COMPONENTS (197)
However, the database works OK without problems.
Please help me to fix the error and make a backup.
(I need the backup to migrate to on 64bit server).

Powercenter SQL1224N error connecting DB2

Im running a workflow in powercenter that is constatnly getting an SQL1224N error.
This process execute a query against one table (POLIZA) with 800k rows, it retrieves the first 10k rows and then it start to execute to another table with 75M rows, at ths moment in DB2 an idle thread error appear but the PWC process still running retrieving the 75M rows, when it is completed (after 20 minutes) the errros comes up related with the first table:
[IBM][CLI Driver] SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command. SQLSTATE=55032
sqlstate = 40003
[IBM][CLI Driver] SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command. SQLSTATE=55032
sqlstate = 40003
Database driver error...
Function Name : Fetch
SQL Stmt : SELECT POLIZA.BSPOL_BSCODCIA, POLIZA.BSPOL_BSRAMOCO
FROM POLIZA
WHERE
EXA01.POLIZA.BSPOL_IDEMPR='0015' for read only with ur
Native error code = -1224
DB2 Fatal Error].
I have a similar process runing against the same 2 tables and it is woking fine where the only difference I can see is that the DB2 user is different.
Any idea how can i fix this?
Regards
The common causes for -1224 are:
Your instance or database has crashed, or
Something/somebody is forcing off your application (FORCE APPLICATION or equivalent)
As for the crash, I think you would know by know. This typically requires a database or instance restart. At any rate, can you please have a look into your DIAGPATH to check for any FODC* directories whose timestamp would match the timestamp of the -1224 errors?
As for the FORCE case, you should find some evidence of the -1224 in db2diag.log. Try searching for the decimal -1224, but also for its hex representation (0xFFFFFB38).