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
!!! ( perdoname la ignorancia )