2012-06-14 34 views
10

tengo varios errores con mi db PostgreSQL, lo que resultó después de una subida de tensión:reparación de base de datos PostgreSQL corrupto

No puedo acceder a la mayoría de las tablas de mi base de datos. Cuando intento por ejemplo select * from ac_cash_collection, me sale el error foolowing:

ERROR: missing chunk number 0 for toast value 118486855 in pg_toast_2619

cuando intento pg_dump me sale el siguiente error:

 
Error message from server: ERROR: relation "public.st_stock_item_newlist" does not exist 
pg_dump: The command was: LOCK TABLE public.st_stock_item_newlist IN ACCESS SHARE MODE 

que siguió adelante y trató de correr reindex de toda la base de datos, De hecho, lo dejé corriendo, me fui a dormir y descubrí que no había hecho nada en la mañana, así que tuve que cancelarlo.

Necesito ayuda para arreglar esto lo antes posible, por favor ayuda.

+0

supongo que el fallo de alimentación dañado el disco duro de alguna manera, lo más probable que necesite para restaurar la copia de seguridad –

+0

¿Ha tratado de [Google que] (https://www.google.com/webhp?q=postgresql%20ERROR% 3A% 20missing% 20chunk% 20number)? – lanzz

+0

El aumento de tensión corrompió las copias de seguridad también ... –

Respuesta

3

Antes de hacer nada otra cosa, http://wiki.postgresql.org/wiki/Corruptiony actuar sobre las instrucciones. De lo contrario, se corre el riesgo de empeorar el problema.


Hay dos parámetros de configuración que figuran en el Fine Manual que puedan ser de uso: ignore_system_indexes y zero_damaged_pages. Nunca los he usado, pero lo haría si estuviera desparato ...

No sé si ayudan contra las tablas de tostadas. En cualquier caso, si su configuración hace que sus bases de datos vuelvan a ser utilizables, yo {backup + drop + restore} para obtener todas las tablas y catálogos en forma recién nacida de nuevo. ¡Éxito!

+2

Se agregó una advertencia acerca de tomar una copia primero; es muy importante. 'zero_damaged_pages' * does * afecta a las tablas TOAST (e índices y todo lo demás). Funciona * borrando datos *, no recuperándolo. Piense muy, muy cuidadosamente antes de usarlo, o 'pg_resetxlog', o cualquiera de las otras herramientas de recuperación de" martillo grande ". –

+0

Excelente consejo, en mi humilde opinión. Al volver a leer el OQ, parece que también hay catálogos dañados involucrados. – wildplasser

+0

Es posible que la copia de seguridad no sea posible aquí. Espere que 'pg_dump' falle con errores como' datos comprimidos están dañados' si sus tablas usan almacenamiento extendido. – kontextify

4

Si tiene copias de seguridad, solo restaure desde ellas.

Si no, acaba de enterarse de por qué necesita copias de seguridad periódicas. No hay nada que PostgreSQL pueda hacer si el hardware se comporta mal.

Además, si alguna vez se encuentra nuevamente en esta situación, primero detenga PostgreSQL y realice una copia de seguridad de todo a nivel de archivos: todos los espacios de tabla, WAL, etc. De este modo, tendrá un punto de partida conocido.

Entonces, si aún desea recuperar algunos datos.

  1. Prueba de volcado de tablas individuales. Consigue lo que puedas de esta manera.
  2. índices de caída si causan problemas
  3. secciones de volcado de tablas (id = 0..9999, 1000..19999 etc.) - de esa manera se puede identificar dónde se pueden dañar algunas filas y volcar secciones cada vez más pequeños para recuperar lo que sigue siendo bueno
  4. Intente volcar solo ciertas columnas: los valores de texto grandes se almacenan fuera de línea (en las tablas de tostados), por lo que evitarlos podría sacar el resto de sus datos.
  5. Si tiene tablas del sistema dañadas, está trabajando mucho.

Eso es mucho trabajo, y luego tendrá que revisar y revisar lo que ha recuperado y tratar de descubrir qué es lo que falta o está incorrecto.

Hay más cosas que puede hacer (crear bloques vacíos en algunos casos puede permitirle volcar datos parciales) pero son más complicados y complicados ya menos que los datos sean particularmente valiosos no valen la pena.

Mensaje clave para llevar de esta - asegúrese de que usted toma regularmente copias de seguridad, y asegurarse de que funcionan.

+1

+1 Hoy estoy feliz de haber aprendido sobre LO IMPORTANTE ES HACER BACKUP y he recuperado con éxito una base de datos. – Claudix

1

Antes de hacer CUALQUIER COSA, tome una copia completa de la base de datos dañada del sistema de archivos.

http://wiki.postgresql.org/wiki/Corruption

De no hacerlo, destruye la evidencia sobre la causa de la corrupción, y significa que si sus esfuerzos de reparación van mal y hacer cosas peores que no se puede deshacer.

Cópielo ahora!

Cuestiones relacionadas