Iñigo GonzálezIT Operations · Infra

GuíasGuides · Sector 3Sector 3

Oracle: cambiar el hardware y el sistema operativo del servidor de base de datos sin parar el hospitalOracle: replacing the database server's hardware and operating system without stopping the hospital

La matriz de certificación, el aviso sobre licencias por núcleo, el plan con el DBA, los prerrequisitos del nuevo servidor, el paso con Data Guard o con RMAN, la vuelta atrás, la validación con el responsable de la aplicación y qué mirar cuando tras el cambio todo va lento.The certification matrix, the warning about per-core licensing, the plan with the DBA, the new server's prerequisites, the move with Data Guard or RMAN, the rollback, validation with the application owner and what to check when everything is slow after the change.

Sector 3Sector 3 · Oracle - Actualizar hardware y SO de servidores de base de datosOracle - Upgrading hardware and OS on database servers · 6 min6 min read · ActualizadoUpdated 28 oct 202628 Oct 2026

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

PuntoQué se acuerda
MétodoSwitchover de Data Guard o restauración con RMAN
VentanaDía y hora con dirección asistencial y supervisión de guardia, fuera de pases de planta y de la carga de pruebas del laboratorio
Corte realMinutos que la aplicación estará sin base de datos
ConexiónAlias DNS que usa la aplicación (por ejemplo db-his.contoso.local) y cuándo se cambia
Vuelta atrásCriterio para volver y hasta qué momento es posible
ValidaciónQuién prueba, con qué casos y quién da el visto bueno

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.

Bash · srv-ora02 (Oracle Linux 9)
sudo dnf install -y oracle-database-preinstall-19cComplete!rpm -q oracle-database-preinstall-19coracle-database-preinstall-19c-1.0-1.el9.x86_64cat /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 · conectado como SYSDG
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.

What you'll get

Moving the Oracle database under the electronic health record, the laboratory or the pharmacy from a seven-year-old server running Oracle Linux 8 (or RHEL 8) to a new one running version 9, with an outage of minutes rather than a whole night, and with a tested way back. In a hospital, A&E, ICU and the wards don't stop: the change is designed so the cut is short, announced in advance and reversible.

Before you start

  • The DBA (in-house or the vendor's) as the change's technical owner. Systems IT prepares the server, network, storage and monitoring; the DBA decides how the database moves.
  • The clinical application vendor: they must certify the new operating system and Oracle version combination for their product, not just Oracle.
  • The application owner on the clinical side (a nursing lead or someone from a clinical department) who will validate with real cases at the end.
  • Recent backups and a restore tested in the last few months (Backup and DR/BCP guide).
  • The hospital's downtime procedure for working without the system during the outage: paper forms, lists of admitted patients and who tells each unit.

1. The certification matrix and licensing

Before ordering hardware, the DBA checks in My Oracle Support › Certifications that the database version is certified on the target system. For example, Oracle Database 19c on Oracle Linux 9 or RHEL 9 requires a minimum Release Update (19.19 or later): if production is on an earlier one, you first patch the source or install the new Oracle Home with a valid RU.

Oracle Database processor licences are counted by physical cores with a factor depending on the processor. A new server with twice the cores may need more licences, and the Data Guard server is licensed too. Disabling cores, virtualising or using packs such as Diagnostics Pack (AWR) have their own rules. Talk to whoever manages licensing before buying, not after.

2. The plan with the DBA

ItemWhat is agreed
MethodData Guard switchover or RMAN restore
WindowDay and time with clinical management and the duty nurse manager, away from ward rounds and the laboratory's test load
Real outageMinutes the application will be without its database
ConnectionDNS alias the application uses (for example db-his.contoso.local) and when it changes
RollbackCriteria for going back and until when it is possible
ValidationWho tests, with which cases and who signs off

The application must not point at the physical server's name but at an alias or a service name. If today it points at srv-ora01, changing that is part of the project, ideally before the migration.

3. The new server: prerequisites

The preinstall package creates the oracle user, the groups, kernel parameters and limits. On Oracle Linux it is in the repository; on RHEL you download it from Oracle and install it with dnf, which resolves the dependencies.

Bash · srv-ora02 (Oracle Linux 9)
sudo dnf install -y oracle-database-preinstall-19cComplete!rpm -q oracle-database-preinstall-19coracle-database-preinstall-19c-1.0-1.el9.x86_64cat /sys/kernel/mm/transparent_hugepage/enabledalways madvise [never]grep -E 'HugePages_Total|Hugepagesize' /proc/meminfoHugePages_Total:   24576Hugepagesize:       2048 kB
  • HugePages sized so the whole SGA fits (vm.nr_hugepages in /etc/sysctl.d/) and Transparent HugePages disabled, as Oracle recommends.
  • Storage with the same layout as the source (ASM or file systems) and its performance measured before any data goes on it.
  • Oracle Home installed with the same RU production will have on the day of the change.
  • The monitoring and backup agents, installed before the day of the cut.

4. How the database moves

Option A, Data Guard (minimal outage). The new server is built as a physical standby of the current one and receives changes for days. On the day, the DBA runs a switchover: the roles swap and the old server becomes the standby, which is also your way back.

DGMGRL · connected as SYSDG
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"

Option B, RMAN. A backup is restored on the new server, incrementals are applied to bring it close and, in the window, the application is stopped, the last incremental and archive logs are applied and the database is opened. Simpler to license, but the outage is longer.

After the change, the DBA checks the state with srvctl status database -db cdbhis (if there is Oracle Restart or Grid Infrastructure) and lsnrctl status to see the listener is serving the application's service. Then the DNS alias moves.

5. Rollback and validation

  • With Data Guard, going back is another switchover to the old server, possible while the configuration stays in sync. With RMAN, the old server is left stopped and untouched until sign-off.
  • The rollback criterion is set beforehand: for example, if validation hasn't finished cleanly after 45 minutes, you go back.
  • The application owner tests with a test patient: search, open the record, enter a vital sign, order a blood test and check it reaches the laboratory, print a label.
  • Until sign-off, nobody switches off the old server or disconnects it from the network.

6. The ticket: "since the change, the application is slow"

Monday, 8:30. Outpatients say opening a record takes three times as long as on Friday.

  1. Slow everywhere or slow to connect? If the first access is slow and then it is fine, look at the network and DNS: a slow tnsping, a reverse lookup that doesn't answer or a client still trying the old server before reaching the new one.
  2. Memory: the startup alert log says whether the SGA is in large pages. If there weren't enough HugePages, Oracle starts without them (or doesn't start, with USE_LARGE_PAGES=ONLY) and the server pages.
  3. Statistics: on a new platform the DBA gathers dictionary and fixed object statistics (DBMS_STATS.GATHER_DICTIONARY_STATS and GATHER_FIXED_OBJECTS_STATS) and checks whether any key query has changed plan.
  4. Storage: higher redo log write latency than on the source, for example because of a badly presented disk.

Before the change, record the times of three or four typical operations measured on the old server. Without that reference, "it's slow" is an opinion.

Next steps

  • The Red Hat Enterprise Linux guide covers operating system administration.
  • The Grafana guide helps you keep the server's load and latency in view before and after the change.
  • The Backup and DR/BCP guide places Data Guard within the continuity plan.
  • The PostgreSQL/MySQL/SQL Server guide covers the engines that live alongside Oracle in the hospital.

Is something missing, or different in your environment? Get in touch and I'll fix it.

Tech Career Lab · newsletter

¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.

Apúntate y llévate las 33 ideasSign up and get the 33 ideas →