Hola Nicolás!
Te cuento un poquito…nosotros ya tenemos nuestra base de datos en producción trabajando sobre un motor postgres en un sistema operativo windows 2000, estamos con la versión 5.6.2 de pampa postgres. En este servidor tenemos nuestra base de datos en producción y una base de datos “copiasiu” para que algunos usuarios específicos consulten la última liquidación (la actualizamos una vez al mes después de la liquidación y antes de cerrado el mes).
El problema es el siguiente, los usuarios cuando trabajaban con pervasive podían acceder a las liquidaciones de todos los meses anteriores, incluso de años anteriores, además ellos copiaban algún backup anterior de la base en su máquina local y hacían pruebas localmente. Ellos además de consultar liquidaciones anteriores, también consultan datos personales, datos familiares, estudios, idiomas, etc (básicamente todos los datos que se encuentran en la solapa de legajo electrónico de Gestión).- Además por ejemplo, necesitan emitir reportes de conceptos liquidados (Informes-Conceptos Liquidados) y para eso deben estar parados en el mes recién liquidado.
Debido a todo esto estamos levantando una base de datos una vez por mes, con el estado de la base con la liquidación ok, y agregando el acceso a cada una de esas bases en las máquinas clientes. ¿Hasta cuántas bases de datos podemos levantar en el motor? No se nos saturará el servidor en algún momento?
¿Alguna otra facultad ha tenido este problema? Y de ser así…¿cómo lo resolvieron?
Saludos,
Hola Andrea, te cuento que van a poder seguir accediendo a las liquidaciones de meses anteriores por medio del sistema (en postgres se guardan las liquidaciones históricas en dh21h). Con respecto a la copia de backups en sus máquinas locales, si bien no es aconsejable (diseminación de datos sensibles), es totalmente factible. Solo se deben instalar un motor de base de datos en sus equipos locales y restaurar una base.
Mi consejo seria tener una base rrhh_anterior (al estilo copiasiu) que contenga el mes anterior cerrado y todos los meses restaurar la base central en dicha base. Al no cambiar el nombre, en los clientes no se debe configurar nada extra.
De todas formas, el limite de bases por motor esta dado por la capacidad del servidor (DISCO, memoria, procesamiento, etc…)
En la UNICEN lo estan llevando a cabo de la forma que te mencione (rrhh, rrhh_anterior, rrhh_prueba, rrhh_reajuste, y alguna otra base extra mas) sin inconvenientes.
Si, el tema de los históricos lo tengo resuelto a partir del dh21h como bien me decís. Lo que plantean nuestros usuarios es querer seguir viendo datos personales, datos familiares, estudios, idiomas, etc etc etc de todos los momentos desde que se implemento el pampa…es decir de todos los meses. Además, como te decía antes, necesitan emitir reportes de conceptos liquidados (Informes-Conceptos Liquidados) de un mes y año particular y para eso deben estar parados en dicho mes (no necesariamente es el mes anterior).
Nosotros pasamos a postgres en septiembre del año pasado…por lo que desde entonces he venido levantando una base de datos por mes (sep08, oct08, dic08, ene09, feb09, mar09….) y los usuarios acceden a cada una de ellas para ver los datos en ese momento (es decir todos los meses tengo que configurar el acceso a esa nueva base de datos en las máquinas clientes). No les sirve ver solo la base del mes anterior sino que necesitan ver de todos los meses anteriores, y es por este motivo que vengo levantando una base de datos por mes desde que estamos con postgres. Por lo que entiendo vamos a tener que seguir trabajando de esta manera mientras dé la capacidad del servidor…lo que quería es que me dieras tu opinión respecto a la forma en que lo venimos manejando, o si realmente estamos trabajando mal.
Me preocupa como vamos a manejar esto cuando pasemos a usar Mapuche.
Bueno, muchas gracias por todo
Saludos,
Si realmente es lo que necesitan resolver no les puedo decir que esten trabajando mal. Solo resulta extraño que todos los meses necesiten acceder o sacar reportes de periodos (muy) anteriores. Depende de la frecuencia de estos últimos, podes armar bases con nombres genericos del estilo periodo1, periodo2, periodo3… y vas pisando las bases con el periodo correspondiente. Si la base que buscan es anterior a 6 (8, 12 o los periodos que decidan mantener en linea ej: sep, oct, dic…) se debera recurrir a un backup para restaurar dicha base en una base creada para tal fin. Con esta estrategia no tenes el trabajo de configuración mensual de todos los clientes. Si esta estrategia no cubre tus necesidades, podes optar por enviarles a cada cliente el archivo postgre.ini configurado con los datos de la base creada con lo cual el trabajo para los clientes significara el remplazo de un archivo. Con respecto a Mapuche, podes utilizar una estrategia similar. Varias instancias de Mapuche parados en distintos periodos y a los cleintes solo le tenes que informar a que URL se deben conectar para acceder a cada periodo.
Mi conclusión es que con un servidor con un disco respetable (500gb o mas) vas a poder mantener unas cuantas bases. Como optimización, podes probar de usar las bases de periodos anteriores sin datos en la tabla dh21h. Esto reducirá notablemente el espacio en disco y la velocidad del proceso de restauración del periodo.