Oracle on Ivan Luminaria

Oracle en Linux: los parámetros del kernel que nadie configura

Tue, 24 Feb 2026 08:03:00 +0100

El cliente era una empresa de logística con Oracle 19c Enterprise Edition sobre Oracle Linux 8. Sesenta usuarios concurrentes, un ERP a medida, unos 400 GB de datos. El servidor era un Dell PowerEdge con 128 GB de RAM y 32 cores.

Las quejas eran vagas pero persistentes: “El sistema va lento.” “Las queries de la mañana tardan el doble que hace dos meses.” “De vez en cuando se congela todo unos segundos.”

AWR, ASH y los 10 minutos que salvaron un go-live

Tue, 10 Feb 2026 08:03:00 +0100

Viernes, 18:40. Ya tenía la chaqueta puesta, listo para salir. El teléfono vibra. Es el project manager.

“Ivan, tenemos un problema. El sistema va lentísimo. Mañana por la mañana es el go-live.”

No es la primera vez que recibo una llamada así. Pero el tono era diferente. No era la queja genérica sobre la lentitud. Era pánico.

Me reconecto por VPN, abro una sesión en la base de datos Oracle 19c del cliente. Lo primero que hago es una comprobación rápida:

Usuarios, roles y privilegios en Oracle: por qué GRANT ALL nunca es la respuesta

Tue, 27 Jan 2026 08:03:00 +0100

Me ha pasado más de una vez: entro en un entorno Oracle y encuentro la misma situación. Todos los usuarios aplicativos conectados como schema owner, con el rol DBA asignado. Desarrolladores, procesos batch, herramientas de reporting — todos con los mismos privilegios que el usuario propietario de las tablas.

Cuando preguntas por qué, la respuesta siempre es alguna variante de: “Así todo funciona sin problemas de permisos.”

Claro. Todo funciona. Hasta el día en que un desarrollador ejecuta un DROP TABLE sobre la tabla equivocada. O un batch de importación hace un TRUNCATE sobre una tabla de producción pensando que está en el entorno de pruebas. O alguien ejecuta un DELETE FROM clientes sin la cláusula WHERE.

Oracle Partitioning: cuando 2 mil millones de filas ya no caben en una query

Tue, 23 Dec 2025 08:03:00 +0100

Dos mil millones de filas. No es un número que se alcance en un día. Se necesitan años de transacciones, movimientos, registros diarios que se acumulan. Y durante todo ese tiempo la base de datos funciona, las consultas responden, los reportes salen. Luego un día alguien abre un ticket: “el reporte mensual tarda cuatro horas.”

Cuatro horas. Para un reporte que seis meses antes tardaba veinte minutos.

No es un bug. No es un problema de red o de almacenamiento lento. Es la física de los datos: cuando una tabla crece más allá de cierto umbral, los enfoques que funcionaban dejan de funcionar. Y si no diseñaste la estructura para manejar ese crecimiento, la base de datos hace lo único que puede: leerlo todo.

De single instance a Data Guard: el día en que el CEO entendió el DR

Tue, 16 Dec 2025 08:03:00 +0100

El cliente era una empresa mediana del sector asegurador. Trescientos empleados, un aplicativo de gestión interno sobre Oracle 19c, un solo servidor físico en la sala de máquinas de la planta baja. Sin réplica. Sin standby. Sin plan de disaster recovery.

Durante cinco años todo había funcionado. Y cuando las cosas funcionan, nadie quiere gastar dinero protegiéndose de problemas que nunca han ocurrido.

El día en que todo se paró #

Un miércoles de noviembre por la mañana, a las 8:47, el disco del grupo de datos principal sufrió un fallo físico. No un error lógico, no una corrupción recuperable. Un fallo hardware. La controladora RAID perdió dos discos simultáneamente — uno llevaba semanas degradado sin que nadie se diera cuenta, el otro cedió de golpe.