Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] recuperación de datos borrados accidentalmente

El día 20 de diciembre de 2010 12:33, Cesar A
<cesar(dot)carbonara(at)gmail(dot)com> escribió:
>
>
> El 21 de diciembre de 2010 10:51, Silvio Quadri <silvioq(at)gmail(dot)com>
> escribió:
>>
>> El día 20 de diciembre de 2010 10:59, Cesar A
>> <cesar(dot)carbonara(at)gmail(dot)com> escribió:
>> >
>> >
>> > El 21 de diciembre de 2010 08:52, Alvaro Herrera
>> > <alvherre(at)commandprompt(dot)com> escribió:
>> >>
>> >> Excerpts from Cesar A's message of lun dic 20 09:06:50 -0300 2010:
>> >> > Saludos.
>> >> >
>> >> > Por error ejecuté:
>> >> > psql -h xxx.xxx.xxx.xxx -U mi_usuario -d mi_bd < dumpsql 2> errores
>> >> >
>> >> > Cuyo dump.sql contiene sólo la estructura de la BD. Sólo tiene
>> >> > estructuras
>> >> > de CREATE ( no había el OR REPLACE)
>> >> >
>> >> > Resulta que en esa IP, la BD era de producción. Y ahora aparece todas
>> >> > las
>> >> > tablas vacías...
>> >>
>> >> La única forma en que eso podría haber pasado es que el script
>> >> contuviera además DROP TABLE xxx para cada tabla.
>> >
>> > Conciente de eso, es lo que más me extraña! ni DROP ni REPLACE.
>> >
>> > El código ejecutado: http://pastebin.com/HQCCqKAd
>> >
>> >>
>> >> ¿O quizás el script
>> >> creó otro schema en el cual tienes una copia adicional de cada tabla, y
>> >> las tablas con los datos están ocultas por ese nuevo schema?  Fíjate si
>> >> puedes encontrar copias duplicadas con \d *.una_tabla
>> >
>> >
>> > Este es el resultado:
>> > \d *.ficha
>> >                                     Tabla «public.ficha»
>> >    Columna    |          Tipo          |
>> > Modificadores
>> >
>> > --------------+------------------------+----------------------------------------------------
>> >  id           | integer                | not null default
>> > nextval('ficha_id_seq'::regclass)
>> >  anno         | character varying(4)   |
>> >  titulo       | character varying(150) |
>> >  descripcion  | character varying(150) |
>> >  autor        | character varying(50)  |
>> >  localizacion | character varying(100) |
>> >  numero       | character varying(7)   |
>> >  codubi       | character varying(7)   |
>> >  codest       | character varying(2)   |
>> >  codpre       | character varying(2)   |
>> >  coddoc       | character varying(2)   |
>> >  observacion  | character varying(200) |
>> >  escala       | character varying(12)  |
>> >  indice       | character varying(5)   |
>> >  idmalo       | integer                |
>> > Índices:
>> >     «ficha_pkey» PRIMARY KEY, btree (id) CLUSTER
>> >
>> > que es la estructura normal de esa tabla...
>> >
>> >>
>> >> > ¿existe alguna forma de recuperar los datos? justo estoy trabajando
>> >> > en
>> >> > lo
>> >> > concerniente en replicación y respaldos, así que de esa BD no tengo
>> >> > nada
>> >> > en
>> >> > físico :-(
>> >>
>> >> Mi más sentido pésame.
>> >
>> > Dato extra: Postresql 8.3.12 bajo Debian Linux
>> >
>> >>
>> >> --
>> >> Álvaro Herrera <alvherre(at)commandprompt(dot)com>
>> >> The PostgreSQL Company - Command Prompt, Inc.
>> >> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>> >
>> >
>> >
>>
>> Es evidente que las tablas estaban vacías al momento que ejecutaste ese
>> comando.
>>
>> Si no tenés nada en el archivo "errores", no sólo no estaban vacías,
>> sino que tampoco existían.
>
>
> Lo siento, pero era un sistema en funcionamiento, no estaba vacío.
>

¿y cuál fue la salida por consola?

--
Silvio Quadri