Database corrupted

31 views
Skip to first unread message

pascu....@gmail.com

unread,
Jun 26, 2024, 9:16:26 AMJun 26
to dcm4che
Hi,
I've been running dcm4chee-arc 5.26.0 dcoker container for some time without any problems but a few days ago several studies were sent to archiving at the same time and I think the database got corrupted, now I get this error:

2024-06-26 14:54:22,859 WARN  [org.dcm4chee.arc.store.impl.StoreServiceImpl] (EE-ManagedExecutorService-default-Thread-3038)  (97): Failed to update DB:

2024-06-26 14:54:22,867 INFO  [org.dcm4chee.arc.store.impl.StoreServiceImpl] (EE-ManagedExecutorService-default-Thread-3038) (97): Unexpected Exception: : javax.ejb.EJBTransactionRolledbackException: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.

2024-06-26 14:54:23,307 INFO  [org.dcm4chee.arc.store.impl.StoreServiceImpl] (EE-ManagedExecutorService-default-Thread-3038)   (97): Failed to update DB caused by org.postgresql.util.PSQLException: ERROR: invalid page in block 138 of relation base/16384/17183 - retry

do you have any idea how I can fix the database , I have no experience with postgress especially in container ?

Thanks in advance for your time.

pascu....@gmail.com

unread,
Jun 26, 2024, 10:44:10 AMJun 26
to dcm4che
Hi,
I think I've solved the problem, I'll put you the solution maybe it will be useful for someone in the future.

docker exec -it dcm4chee-db-1 bash

The main problem is to find the corrupted element to repair it. The log gives the file location (for real, there are many files corresponding to the given path and you can find the precise file by considering the block). But the problem is to identify what this file is corresponding to. In my case, that file was a pkey index but until you know it, you can’t repair it.

psql -U user -W pacsdb

SELECT pg_class.relfilenode, pg_namespace.nspname as schema_name, pg_class.relname, pg_class.relkind
from pg_class
JOIN pg_namespace on pg_class.relnamespace = pg_namespace.oid
ORDER BY pg_class.relfilenode ASC;


This is giving you results like the following, where the relfilenode fied is corresponding to the file number in the error message and the schema_name / relname to the corrupted element.


 relfilenode |    schema_name     |                    relname                    | relkind
-------------+--------------------+-----------------------------------------------+---------
       17183 | public             | series_desc_upper_idx                         | i
 
In my case the corrupted element was an index, this is a good situation as an index can be rebuilt without data loss. The following command solved the situation

REINDEX INDEX series_desc_upper_idx;

Have a nice day!

Reply all
Reply to author
Forward
0 new messages