Oracle: cambiar el hardware y el sistema operativo del servidor de base de datos sin parar el hospital

Qué vas a conseguir

Pasar la base de datos Oracle que hay debajo de la historia clínica, el laboratorio o la farmacia de un servidor de hace siete años con Oracle Linux 8 (o RHEL 8) a uno nuevo con la versión 9, con una parada de minutos y no de una noche entera, y con un camino de vuelta probado. En un hospital urgencias, UCI y planta no paran: el corte tiene que ser corto, anunciado y reversible.

Antes de empezar

• El DBA (interno o del proveedor) como responsable técnico del cambio. IT de sistemas prepara el servidor, la red, el almacenamiento y la monitorización; el DBA decide cómo se mueve la base de datos.
• El proveedor de la aplicación clínica: tiene que certificar la nueva combinación de sistema operativo y versión de Oracle para su producto, no solo Oracle.
• El responsable de la aplicación del lado asistencial (un referente de enfermería o de un servicio clínico) que validará con casos reales al terminar.
• Copias de seguridad recientes y una restauración probada en los últimos meses (guía de Backup y DR/BCP).
• El procedimiento de contingencia del hospital para trabajar sin el sistema durante la parada: impresos, listados de pacientes ingresados y quién avisa a cada unidad.

1. La matriz de certificación y las licencias

Antes de pedir el hardware, el DBA comprueba en My Oracle Support › Certifications que la versión de la base de datos está certificada en el sistema destino. Por ejemplo, Oracle Database 19c en Oracle Linux 9 o RHEL 9 exige un Release Update mínimo (19.19 o posterior): si producción está en uno anterior, primero toca parchear el origen o instalar el nuevo Oracle Home ya con un RU válido.

Las licencias de Oracle Database por procesador se calculan por núcleos físicos con un factor según el procesador. Un servidor nuevo con el doble de núcleos puede necesitar más licencias, y el servidor de Data Guard también se licencia. Desactivar núcleos, virtualizar o usar paquetes como Diagnostics Pack (AWR) tiene reglas propias. Habla con quien gestiona las licencias antes de comprar, no después.

2. El plan con el DBA

La aplicación no debe apuntar al nombre del servidor físico sino a un alias o un nombre de servicio. Si hoy apunta a srv-ora01, cambiarlo es parte del proyecto, y conviene hacerlo antes de la migración.

3. El servidor nuevo: prerrequisitos

El paquete preinstall crea el usuario oracle, los grupos, los parámetros del kernel y los límites. En Oracle Linux está en el repositorio; en RHEL se descarga de Oracle y se instala con dnf, que resuelve las dependencias.

›sudo dnf install -y oracle-database-preinstall-19cComplete!›rpm -q oracle-database-preinstall-19coracle-database-preinstall-19c-1.0-1.el9.x86_64›cat /sys/kernel/mm/transparent_hugepage/enabledalways madvise [never]›grep -E 'HugePages_Total|Hugepagesize' /proc/meminfoHugePages_Total:   24576Hugepagesize:       2048 kB

• HugePages configuradas para que quepa el SGA entero (vm.nr_hugepages en /etc/sysctl.d/) y Transparent HugePages desactivadas, como recomienda Oracle.
• El almacenamiento con el mismo diseño que el origen (ASM o sistemas de ficheros) y el rendimiento medido antes de poner datos.
• Oracle Home instalado con el mismo RU que tendrá producción en el momento del cambio.
• Los agentes de monitorización y de copias, instalados antes del día del corte.

4. Cómo se mueve la base de datos

Opción A, Data Guard (parada mínima). El servidor nuevo se crea como standby física del actual y recibe los cambios durante días. El día del cambio, el DBA hace un switchover: los papeles se intercambian y el antiguo queda como standby, que es también la vuelta atrás.

›dgmgrl sys@cdbhis_aDGMGRL> show configurationConfiguration - dg_his  Protection Mode: MaxPerformance  Members:  cdbhis_a - Primary database    cdbhis_b - Physical standby databaseConfiguration Status:SUCCESSDGMGRL> validate database cdbhis_b  Ready for Switchover:  YesDGMGRL> switchover to cdbhis_bPerforming switchover NOW, please wait...Switchover succeeded, new primary is "cdbhis_b"

Opción B, RMAN. Se restaura una copia en el servidor nuevo, se aplican incrementales para acercarlo y, en la ventana, se para la aplicación, se aplica el último incremental y los archivelogs y se abre. Más sencillo de licenciar, pero el corte es más largo.

Después del cambio, el DBA comprueba el estado con srvctl status database -db cdbhis (si hay Oracle Restart o Grid Infrastructure) y lsnrctl status para ver que el listener sirve el servicio de la aplicación. Entonces se mueve el alias DNS.

5. La vuelta atrás y la validación

• Con Data Guard, volver es otro switchover hacia el servidor antiguo, posible mientras la configuración siga sincronizada. Con RMAN, el servidor antiguo se deja parado e intacto hasta que se dé el visto bueno.
• El criterio de vuelta se fija antes: por ejemplo, si a los 45 minutos la validación no ha terminado bien, se vuelve.
• El responsable de la aplicación prueba con un paciente de pruebas: buscar, abrir la historia, registrar una constante, pedir una analítica y comprobar que llega al laboratorio, imprimir una etiqueta.
• Hasta el visto bueno, nadie apaga el servidor antiguo ni lo desconecta de la red.

6. El ticket: "desde el cambio, la aplicación va lenta"

Lunes, 8:30. Las consultas externas dicen que abrir una historia tarda el triple que el viernes.

1. ¿Lento todo o lento al conectar? Si el primer acceso tarda y después va bien, mira la red y el DNS: un tnsping lento, una resolución inversa que no responde o un cliente que aún intenta el servidor antiguo antes de llegar al nuevo.
2. La memoria: el alert log de arranque indica si el SGA está en páginas grandes. Si las HugePages no bastaban, Oracle arranca sin ellas (o no arranca, con USE_LARGE_PAGES=ONLY) y el servidor pagina.
3. Las estadísticas: en una plataforma nueva el DBA recoge las del diccionario y las de los objetos fijos (DBMS_STATS.GATHER_DICTIONARY_STATS y GATHER_FIXED_OBJECTS_STATS) y revisa si alguna consulta clave ha cambiado de plan.
4. El almacenamiento: latencias de escritura de los redo logs mayores que en el origen, por ejemplo por un disco mal presentado.

Guarda antes del cambio los tiempos de tres o cuatro operaciones típicas medidos en el servidor antiguo. Sin esa referencia, "va lento" es una opinión.

Siguientes pasos

• La guía de Red Hat Enterprise Linux cubre la administración del sistema operativo.
• La guía de Grafana ayuda a tener a la vista la carga y la latencia del servidor antes y después del cambio.
• La guía de Backup y DR/BCP sitúa Data Guard dentro del plan de continuidad.
• La guía de PostgreSQL/MySQL/SQL Server sirve para los motores que conviven con Oracle en el hospital.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.