UNR - Liliana - migracion a Postgres

Hola Liliana, todo un manual de procedimiento!

Te cuento que en cuanto a las instancias no ningun problema, podes tener mes_anterior y mes_a_liquidar.

En cuanto a la existencia de una utilidad para el traslado de datos entre bases, lo podes realizar con dump/restore o sino con el contrib “dblink”.
Y si necesitas hacer la base de producción mas ágil, podes hacer lo que mencionas, dejar una base con históricos y la que crezca sea esta.

En cuanto al tamaño de dh21h, te cuento que hemos detectado que gran parte del volumen viene dado por índices. Estos indices surgen en la migracion de datos. Actualmente estamos evaluando la eliminación o remplazo de algunos índices.

Hay tiempos inevitables y lamentablemente no se pueden igualar los tiempos de copiar algo a nivel filesystem contra manejar información dentro de una base de datos.

Aprovecho para decirte que probamos la generación de recibos (y si bien es un proceso que demora excesivamente) y el tiempo no viene dado por la cantidad de recibos sino por la cantidad de unidades académicas. Es decir, generar 100 recibos puede llevar un tiempo muy similar a generar 500 y no 5 veces mas como se estimaría.

Espero que estos comentarios te sean de utilidad.

Saludos,
Nico.

1- Una utilidad que permita trasladar entre bases el contenido de las tablas. ?
2- Una base_histórica donde residan solamente las tablas de acumulación de datos históricos.? la cual se pueda acceder desde las bases de producción.
( dh21h,dh41,dh70 por ej.); de esta forma, la manipulación de bases del mes, sería mas llevadera.

El 26/05/10 13:03, Liliana Pozzobon escribió:

Hola Nicolás !
Te molesto con lo siguiente:
En un mail del mes de Noviembre del año 2006, te presenté el tema de la estructura de nuestro trabajo en el entorno PAMPA_Pervasive
Allí te cuento como es nuestra producción, y si podían, me sugerían ustedes algún método ágil de trabajo bajo el entorno Pampa_PostgreSQL.
Se ha podido pensar en alguna forma de trabajo ?

Para aclararte el panorama te cuento que:
Habrá 2 instancias de producción en el mismo PostgreSQL ( solo hay un hardware disponible y tendrá varios PostgreSQL para producción y desarrollo)
Nosotros no podemos tener una sola base, porque nuestros tiempos de proceso son de varios días, 2 actualmente y por lo que he visto hasta el momento, estimo 3 o 4 días en el futuro PostgreSQL.
Las instancias son:
a- Mes_anterior ( liquidación abierta con permiso de solo consulta) y con todas la liquidaciones históricas ( actualmente en …\rrhh\hist\dh21mmaa.dat ) para el Visualizador Histórico de Liquidaciones.
b- Mes_a_liquidar (disponible para la carga de datos de los liquidadores)

El flujo de trabajo es el siguiente:
En la instancia del Mes a Liquidar; al producir el corte de ingreso de datos, los pasos son:
1- se genera la liquidación
2- se hace un control completo de conciliación de totales entre el libramiento, los depósitos bancarios y los recibos.
3- se procesan los botones que dan orígen a los archivos de imputación, carga en SAC y etc, etc.
4- se resguarda el mes liquidado ( zip del rrhh*.* en Pervasive y por ej. pg_dump de la base completa en PostgreSQL).
5- se hace el traslado del contenido de las tablas de la base del mes_a_liquidar ( ahora liquidado ) a las tablas de la base de la instancia Mes_anterior.
( 15 min. en entorno Pervasive y he probado psql < base.sql con solo un mes y nos demanda 2 horas de carga neta + vacuum por supuesto.
6- Cierre del mes y traslado del contenido de las nuevas tablas históricas a la base Mes_anterior.
( 2 minutos en entorno Pervasive (todas nuestras dh21mmaa.dat insumen 18Gb))
en PostgreSQL quedan en dh21h y teniendo en cuenta que solamente ene/feb/y mar ocupan 192 mb y 380 mb sus índices,
sería muy tedioso su puesta en línea de una base a la otra.

Ahora bien; los puntos 5 y 6 son el cuello de botella;
Nuestro volúmen de datos , tanto mensuales como históricos y su reproducción en otra instancia es bastante grande.
( test_pampa | 3177098860 bytes| 3102635 kb| 3029 mb )
Para poner un ejemplo, una base con solamente 3 meses de dh21mmaa, (sin ninguna dh41aaaa) nos demanda 2 horas de carga neta.
No me alcanza la imaginación, si hay que trasladar 2 o 3 o los 10 años que tenemos de historicas.
Entonces ante este panorama, se podría contar con:
1- Una utilidad que permita trasladar entre bases el contenido de las tablas. ?
2- Una base_histórica donde residan solamente las tablas de acumulación de datos históricos.? la cual se pueda acceder desde las bases de producción.
( dh21h,dh41,dh70 por ej.); de esta forma, la manipulación de bases del mes, sería mas llevadera.

Espero haber explicado con claridad nuestro cuello de botella para producir Pampa en entorno PostgreSQL.
Cualquier pregunta que necesites, estamos a la escucha y esperando tu respuesta.

Un abrazo
Salutti a tutti.

Liliana E. Pozzobón
Jefa Dpto. Operaciones y Equipos
Dirección de Computación y Procesamiento de Datos
Universidad Nacional de Rosario
lpozzobo@sede.unr.edu.ar
Tel. 341-4201200 int. 386 de 9 a 14 h

Nicolas Dominguez Florit
Equipo SIU-Mapuche
Consorcio SIU
skype: nicolas.dominguez.florit
Tel: +54 2293 42-2000 Int. 131
http://www.siu.edu.ar

-------- Mensaje original --------
Asunto: Re: Entorno de trabajo para el futuro inmediato.
Fecha: Fri, 28 May 2010 13:47:38 -0300
De: Liliana Pozzobon lpozzobo@unr.edu.ar
Responder-a:: Liliana Pozzobon lpozzobo@unr.edu.ar
A: ndominguez@siu.edu.ar

Mi estimado Nicolás,
te respondo en cada una tus fraces.

Liliana E. Pozzobón
Jefa Dpto. Operaciones y Equipos
Dirección de Computación y Procesamiento de Datos
Universidad Nacional de Rosario
lpozzobo@sede.unr.edu.ar
Tel. 341-4201248

----- Original Message -----
From: Nicolás Domínguez Florit
To: Liliana Pozzobon
Sent: Thursday, May 27, 2010 2:04 PM
Subject: Re: Entorno de trabajo para el futuro inmediato.

Hola Liliana, todo un manual de procedimiento!
NO no el manual es mucho mas grande !!!

Te cuento que en cuanto a las instancias no ningun problema, podes tener mes_anterior y mes_a_liquidar.
SI, ya lo sé y ya lo tengo, y además la del mapuche y etc. etc. en total por ahora son 4.

En cuanto a la existencia de una utilidad para el traslado de datos entre bases, lo podes realizar con dump/restore o sino con el contrib "dblink".
Todos los utilitarios son demandantes de tiempos de trabajo de cpu neta !!!   Olvídate de operaciones manuales !
 
Y si necesitas hacer la base de producción mas ágil, podes hacer lo que mencionas, dejar una base con históricos y la que crezca sea esta.
Estoy en ese camino, pero el tema es que esa info histórica debe ser accedida por el Pampa y/o Mapuche que esté en la producción del mes, y eso, creo que yo no lo puedo hacer. 

En cuanto al tamaño de dh21h, te cuento que hemos detectado que gran parte del volumen viene dado por índices. Estos indices surgen en la migracion de datos. Actualmente estamos evaluando la eliminación o remplazo de algunos índices.
Si, te mensioné  en el punto 6 cuanto mide cada cosa con solo 3 meses.
 
Hay tiempos inevitables y lamentablemente no se pueden igualar los tiempos de copiar algo a nivel filesystem contra manejar información dentro de una base de datos.
Es por eso que me parece que la solución del sistema pasa por crear una base.histórica que pueda ser accedida por los distintos puntos del / los sistemas.
Imaginate vos a los que recién arrancan que les es todo tan rapidito, dentro de 5 años, cuando los volúmenes de datos acumulado les haga las cosas mas tediosas.
Cual es la solución ?,  aumentar las horas de trabajo ? y el personal para hacer las cosas manualmente ? 
Poner una tabla acá, otra allá, y la consistencia de sistema ?
Y una cuestión de avance técnológico, que se supone que debería hacer el trabajo mas llevadero, se torna un incordio !!!

Aprovecho para decirte que probamos la generación de recibos (y si bien es un proceso que demora excesivamente) y el tiempo no viene dado por la cantidad de recibos sino por la cantidad de unidades académicas. Es decir, generar 100 recibos puede llevar un tiempo muy similar a generar 500 y no 5 veces mas como se estimaría.
Si mi querido Nicolás....    Mi calculo es atendiendo a la cantidad de recibos que tiene cada instituto.
También es cierto que si lo generás alfabético general solo tarda lo que tarda en recorrer la base.
Pero no es la solución que se quiten los institutos !

Espero que estos comentarios te sean de utilidad.
Nicolás....    los comentarios sirven para intuir, percibir, saber o confirmar, que los únicos que manejamos semejantes volúmenes de información parece ser que somos nosotros.
Y si bien en el año 2006 vos ya sabías de estos inconvenientes, parece que no hay soluciones de parte del sistema.
 
Bueno, espero que la ingeniería del sistema, Dios y la Patria nos ayude !!!
Un abrazo.
Liliana.

Hola Liliana, me parecen muy bien los pasos de describís. Solo tengo dudas con respecto a la base mes_anterior. Ya que si le haces un append de los históricos, deben ser de los históricos anteriores (es decir, pasar lo que mes_anterior tenia el mes anterior en dh21 a dh21h).

Para resolver esto, podes utilizar una estrategia como la siguiente antes de sobreescribir la base mes_anterior:
BEGIN;
CREATE TEMP TABLE DH21HTEMP AS (SELECT * from pampa.DH21);
ALTER TABLE DH21HTEMP DROP COLUMN id_liquidacion;
INSERT INTO pampa.DH21H SELECT nextval(‘‘dh21h_id_liquidacion_seq’’),* from DH21HTEMP;
DROP TABLE DH21HTEMP;
END;

Otra alternativa seria actualizar dh21h solo con los registros que le indiques, esto se puede realizar con el contrib dblink. Un ejemplo:
–inserta en base mes_anterior resgistros
INSERT INTO pampa.dh21h
SELECT *
FROM dblink(’
hostaddr=192.168.1.100
port=5432
dbname=base_del_mes
user=postgres
password=xxxpostgresxxx’,
‘SELECT * from pampa.dh21h where id_liquidacion > 100 and id_liquidacion < 200’) AS dh21h_remota (
id_liquidacion integer,
nro_liqui integer,
nro_legaj integer,
nro_cargo integer,
codn_conce integer,
impp_conce double precision,
tipo_conce character(1),
nov1_conce double precision,
nov2_conce double precision,
nro_orimp integer,
tipoescalafon character(1),
nrogrupoesc integer,
codigoescalafon character(4),
codc_regio character(4),
codc_uacad character(4),
codn_area integer,
codn_subar integer,
codn_fuent integer,
codn_progr integer,
codn_subpr integer,
codn_proye integer,
codn_activ integer,
codn_obra integer,
codn_final integer,
codn_funci integer,
ano_retro integer,
mes_retro integer,
detallenovedad character(10)
) ORDER BY id_liquidacion;

Los sql de arriba los podes ejecutar con psql desde linea de comandos.

Con respecto a la pregunta 2 no te termino de entender a lo que te referís con lleve o traiga basura.

Cualquier duda de los scripts o lo que sea, no dudes en consultarnos.

Un abrazo y nos mantenemos en contacto.
Nico.

El 31/05/10 09:58, Liliana Pozzobon escribió:

Nico,
a ver que te parece esto:
a) Base_del_mes
b) Base_mes_anterior

1- Carga de datos durante el mes
2- Liquidación y dump -T
2- otra Liquidación si hay ( por ej. SAC). y dump -T
3- Cierre del mes
acá dump completito y (tar del data + postgres + dir/win y etc etc)
y entonces en la base Mes_anterior:

  1. restor del dump -T de antes del cierre
  2. append de la dh21h del mes recién generada con el cierre.

De esta forma tengo una dh21h completa que no muevo.

Pregunta 1, cual es la forma más adecuada de apendear tablas en postgres ?
Si podés, mandame un ejemplo de .sql que agrege a una tabla grande de 18Gb una mas chica de 100Mb(si tiene el SAC)
( creo que anda por el INSERT INTO )
me gustaría usar algo generado por ustedes, con el debido order by.

Pregunta 2,
cual sería el conjunto de pasos a seguir para estar seguros que el tema del dump/restor no me traiga y/o lleve “basura” ?
Tené en cuenta que pretendo que en la base de producción, no tenga otros permisos que los que se necesitan para ejecutar la aplicación.

Si tengo esto resuelto, el resto es tratar de generar los scripts (algunos ya los tengo), para que corran desde win ( cplink para disparar scripts) en el server y poder programar
los tiempos de trabajo.
Espero tu respuesta.
Un Brazo y muchas gracias por la dedicación.

Liliana E. Pozzobón
Jefa Dpto. Operaciones y Equipos
Dirección de Computación y Procesamiento de Datos
Universidad Nacional de Rosario
lpozzobo@sede.unr.edu.ar
Tel. 341-4201248

Si liliana, no existe comunicación entre distintas bases. La forma de hacerlo es mediante dblink.
Saludos,
Nico.

El 31/05/10 14:11, Liliana Pozzobon escribió:

Nico,

NO no, en la base del mes solo tengo la dh21h del mes.
o sea que sería un append de todo lo que hay en dh21h del mes_actual en la dh21h de mes_anterior
que de esta manera crecerá y no la muevo de ningun lado, solo le appendeo lo nuevo que generó el cierre y que es solo lo del mes.

como ambas bases están en la misma instancia del postgres (mismo puerto), hace falta el dblink en el INSERT INTO ?

Muchas gracias
Un abrazo

Liliana E. Pozzobón
Jefa Dpto. Operaciones y Equipos
Dirección de Computación y Procesamiento de Datos
Universidad Nacional de Rosario
lpozzobo@sede.unr.edu.ar
Tel. 341-4201248

OK. Nico

Me pongo a ver si genero esos scripts y tomar tiempos para un rulo de fin de mes.
Disculpá mi ignorancia de postgres.
En el mainframe el sql hablaba normalmente entre bases.
Chau Chau.

Liliana E. Pozzobón
Jefa Dpto. Operaciones y Equipos
Dirección de Computación y Procesamiento de Datos
Universidad Nacional de Rosario
lpozzobo@sede.unr.edu.ar
Tel. 341-4201248

Hola Liliana, que yo sepa no existe nada en postgres que te de lo que necesitas.
Se me ocurre que lo podrias realizar utilizando el log de postgres (en el caso que estes logueando) o sino mirando la tabla logtan_ del esquema pampa. Aunque esta ultima solo te va a mostrar las cosas que se realizan desde la aplicación.

En Mapuche existe un mecanismo de auditoria mucho mas complejo y robusto que te permite obtener lo que vos necesitas (utiliza triggers y un esquema especial de auditoría). Pero en pampa no existe tal mecanismo.

Saludos,
Nico.

El 08/06/10 12:44, Liliana Pozzobon escribió:

Hola Nicolas !
Estas de vuelta ?
Si es así,
me podrías pasar un query que me diga desde el postgresql cuando se modificó por última vez una tabla del esquema pampa ?
La verdad que estuve viendo el pg_catalog y se me hace difícil.
Espero tu respuesta y muchas gracias.
Un salutti a tutti
Beso.

Liliana E. Pozzobón
Jefa Dpto. Operaciones y Equipos
Dirección de Computación y Procesamiento de Datos
Universidad Nacional de Rosario
lpozzobo@sede.unr.edu.ar
Tel. 341-4201248

Hola Liliana, muy bueno el contrib que me pasaste. No lo conocía.
Para el uso de este contrib hace falta agregar un nuevo campo en cada tabla del sistema.
Además del gran incremento de volumen de datos, tener asociado un trigger para cada modificación sumaria una nueva demora (si bien puede que sea mínima según la actulización que se este realizando).
Al agregar un nuevo campo a cada tabla es muy probable que se rompan muchos cosas, ya que la estructura definida en el lenguaje (diccionario de clarion) va a ser distinta a la que tenga la base de datos. Por lo que yo considero que esta alternativa no es aplicable al Pampa Escritorio Postgres.

En cuanto a dh41aaaa.dat tenes toda la razón del mundo. No se esta migrando. Si para ustedes es factor indispensable tenerlos migrados, les haremos un exportador muy similar al de dh21aamm.dat. Te cuento que en Postgres no se utiliza mas el mecanismo de pasar a historicos los datos de dh41. Por lo que quedan todos en linea en la tabla dh41 de postgres.

Espero respuesta tuya para ver si avanzamos en la migración de los dh41.

Saludos,
Nico.

El 09/06/10 10:11, Liliana Pozzobon escribió:

Hola Nico,
gracias por contestar
que macana…
porque se me ocurría que en vez de restaurar los 30 GB de la base mes_actual a la base histórica mes_anterior,
podía solo refrescarle las diferencias producidas durante el mes.

preguntando en el google apareció esto:
http://www.postgresql.org/docs/current/static/contrib-spi.html

psql -U postgres db_name < ./contrib/moddatetime.sql
(needed yum install postgres-contrib first)

So any table can now have the following trigger added…

CREATE TRIGGER table_update BEFORE UPDATE
ON table_name FOR EACH ROW EXECUTE PROCEDURE
moddatetime(‘updated_at’);
esto implica trabajo de ustedes modificando el sistema ?
o lo puedo hacer yo en mi postgres y no romper nada :slight_smile: !!! ( perdoname la ignorancia )

Otra cosa respecto de la migración:
Nosotros tenemos las dh41aaaa.dat que genera el cierre de mes en los diciembre de cada año desde que arrancamos, o sea 1999 / 2009 hasta ahora.
Como las llevamos al postgres ?

Bueno, muchas gracias por tu tiempo.
Espero respuesta.
Beso.

Liliana E. Pozzobón
Jefa Dpto. Operaciones y Equipos
Dirección de Computación y Procesamiento de Datos
Universidad Nacional de Rosario
lpozzobo@sede.unr.edu.ar
Tel. 341-4201248