Objetivo: Migrar la base de SQL Server de SisPro a un nuevo servidor.
Alcance: Este instructivo comprende los puntos a tener en cuenta para poder realizar un pasaje de SisPro hacia otro servidor correctamente, teniendo como consigna que la ventana de tiempo del usuario sin Sispro sea lo mas corta posible.
Requisitos previos:
Tener SQL Server instalado correctamente en el servidor nuevo: En un servidor nuevo debe estar instalado el MOTOR de SQL Server y el Managment. Para instalar el motor lo puede hacer el cliente (si tiene una licencia) o se puede descargar la versión Express desde este link (Descargas de SQL Server | Microsoft )
Haber realizado la emulación de la migración en el nuevo servidor teniendo en cuenta lo siguiente:
a. Carpeta de Sispro con reportes y con acceso desde las terminales y pcs
b. Debe existir la carpeta de Sispro con actualizaciones e instaladores: Conviene tener todos los archivos instaladores en el nuevo servidor. Además de ya tener instalado Sispro Planificador, así es mas rápido el testeo.
c. instalar Sispro con base limpia.
d. instalar planificador con base actual y asociar al planificador de alguna pc de algún usuario.
e. Comunicarse con el proveedor del otro sistema para redireccionar en envío de la información. Si nos escriben en una tabla, indicarle al proveedor la IP del nuevo servidor e indicarle la nueva tabla donde nos deben escribir. Para este punto tenemos una ventana mas grande de tiempo. En el caso de Aramis se configura la ruta en donde está Sispro.
f. En el caso de servidor vinculados, hay que realizar nuevamente el Linked Server, verificar antes de la migración que la vinculación ha sido realizada de forma exitosa.
i. Si tienen tareas programadas hay que generarlas nuevamente en el nuevo servidor.
j. Si tiene tareas programadas para actualizar OP hay que replicarlo.
g. Cuando al emulación dio ok, ahí podemos realizar la migración.
h. Cuando se va a hacer la migración , se apagan las terminales, empieza a correr el tiempo de migración (ventana de tiempo del usuario sin SIspro). En esa ventana, se hace una copia de la base y se pisa la información de la base anterior en el nuevo servidor.
Pasos para la migración:
En el servidor de ORIGEN se encuentra la carpeta de SisPro donde se guardan los archivos necesarios para instalaciones, actualizaciones y backups. Una de esas carpetas es Base, dentro de la cual se alojan los archivos .mdf y .ldf de la base de datos que se utiliza en producción.
Se deben pasar al servidor NUEVO todas las carpetas excepto los archivos .mdf y .ldf de la carpeta Base
Sugerencia: si en esa carpeta hay varios backups anteriores, tampoco es necesario migrar todos.
Esta carpeta \\SERVIDOR\SisPro debe estar compartida para poder verse desde las pc’s de Planificadores y Terminales. Tal cual como sucede en el servidor de origen con la misma carpeta.
2. Revisar en el servidor nuevo que los servicios del SQL SERVER estén corriendo y con el mismo usuario de inicio de sesión que el servidor de origen.
3. Revisar que los protocolos estén habilitados al igual que el servidor de origen y chequear si tiene algún número de puerto colocado.
MPORTANTE: Revisar que los usuarios de inicio de sesión en el servidor nuevo sean los mismos que en el servidor de origen. Y que el usuario SA (o el que se use para SisPro) tenga la misma clave.
4. En el caso que haya puerto configurado en los protocolos de TCP/IP, mi recomendación, es que creen una regla de Entrada y Salida en el firewall.
5. Una vez que tenemos el entorno en el servidor nuevo, entonces frenamos el uso de SisPro en el servidor de origen. Podemos hacerlo desde SisPro / Parámetros / Planificación de Producción (Gantt) para cerrar todos los planificadores y SisPro / Parámetros / Terminales de Producción para cerrar todas las terminales
Sugerencia: También se puede frenar el uso de SisPro a través de un script de SQL
Update Parametros set CerrarTodosSispro=1, CerrarTodosSisProTerminal=1
6. Una vez frenado SisPro, realizamos el backup a ese momento de la base de datos y ese archivo .bak lo pasamos al servidor nuevo.
7. Una vez que el archivo .bak esta en el nuevo servidor, lo restauramos en el SQL Server con el mismo nombre de la base de datos, y ubicando la creación de los archivos .mdf y .ldf en la carpeta Base
8. Una vez que tenemos el backup restaurado debemos crear la conexión ODBC hacia la base y probar el SisPro Planificador del servidor. Esto es para comprobar que la base abra y que no está corrupta.
Recordar de volver a activar el acceso a SisPro, por interfaz o por script de SQL:
Update Parametros set CerrarTodosSispro=0, CerrarTodosSisProTerminal=0
9. Finalmente se puede desconectar el servidor de origen y al nuevo servidor podemos cambiarle el nombre para que tenga el mismo que el anterior.
Recordar que esto solo lo podemos hacer si el anterior ya no está en la misma red que el nuevo.
La idea de ponerle el mismo nombre es para no tener que actualizar el acceso en cada una de las terminales.
10. Para tener en cuenta:
Si se cambia el nombre del servidor nuevo, entonces se deben ajustar todos los accesos de los planificadores y terminales.
Si hay alguna otra carpeta compartida que se utilice, alojada en el servidor de origen, entonces también se debe pasar al nuevo.
Si en el servidor de origen hay algún servidor linkeado, entonces se debe crear esa misma conexión y su respectivo ODBC (si es que existe también).
Si se utiliza alguna macro o DLL para enviar ordenes a SisPro entonces se debe comprobar que funcione correctamente (tener en cuenta el tema del nombre del servidor nuevo).
Si hay tareas programadas de Windows en el servidor de origen, se deben pasar al nuevo. Lo mismo con Jobs de SQL Server, se deben migrar hacia el nuevo servidor.