El día 20 de diciembre de 2010 12:33, Cesar A <cesar.carbon...@gmail.com> escribió: > > > El 21 de diciembre de 2010 10:51, Silvio Quadri <silv...@gmail.com> > escribió: >> >> El día 20 de diciembre de 2010 10:59, Cesar A >> <cesar.carbon...@gmail.com> escribió: >> > >> > >> > El 21 de diciembre de 2010 08:52, Alvaro Herrera >> > <alvhe...@commandprompt.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 <alvhe...@commandprompt.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 - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
