Oracle Database: artículos sobre DBA, rendimiento, tuning

He visto a un DBA apagar una producción con un DROP TABLESPACE lanzado en la ventana equivocada. He visto consultas de cuatro segundos convertirse en cuatro horas tras un upgrade, porque alguien había tocado optimizer_features_enable “si total era igual”. He visto backups que no se restauraban, auditorías desactivadas “temporalmente” desde hace cinco años, e índices creados en producción a mano un viernes por la tarde.

Y he visto exactamente lo contrario: instancias Oracle que llevan veinte años funcionando sin un minuto de downtime no planificado, aguantando cargas enormes y sobreviviendo a tres upgrades mayores sin despeinarse.

La diferencia nunca ha sido la versión. Siempre ha sido quién la gestionaba.

Trabajo con Oracle desde 1996. En casi treinta años he visto pasar Oracle 7, 8i, 9i, 10g, 11g, 12c, 19c, 21c, 23ai — y paradigmas, modas, consultores que vendían la feature del momento como la respuesta a cualquier problema.

El corazón del motor, sin embargo, ha seguido siendo el mismo: sólido, complejo, despiadado con quien no lo conoce a fondo.

Oracle no se aprende con tutoriales. Se aprende:

con los incidentes de producción a las tres de la madrugada, cuando el manual sirve de poco y vale más un colega que ya ha visto ese comportamiento
con las migraciones en las que el plan de ejecución cambia el día después del go-live y nadie entiende por qué
con los planes de ejecución que se vuelven patológicos tras un DBMS_STATS.GATHER_SCHEMA_STATS lanzado con parámetros por defecto
con las v$ que dicen la verdad incluso cuando la aplicación miente
con los tuning packs que sirven de verdad, y con los que pagaste y nunca vas a encender

🔧 Qué miro cuando llego a una instancia nueva #

Cuando un cliente me llama porque “la base de datos va lenta” o “algo no va bien”, hay cinco cosas que miro antes de tocar cualquier parámetro. No es una checklist de curso de certificación — es lo que he aprendido a mirar después de perder demasiado tiempo en los sitios equivocados.

Qué	Dónde lo miro	Por qué
La carga real	AWR, ASH, `v$active_session_history`	Entender quién consume de verdad CPU, I/O y `db time` — a menudo no es lo que sospecha el cliente
Lo que ha tocado quien ha pasado antes	`v$parameter` con `ismodified`, `dba_hist_parameter`	Los parámetros “no estándar” son la primera pista de debug pasado sin documentar
Quién hace qué	`dba_audit_trail`, `unified_audit_trail`, jobs programados	Encontrar los jobs nocturnos, las conexiones aplicativas reales, los accesos DBA sin trazar
Estado de Data Guard	`v$dataguard_stats`, `v$archive_dest_status`	Si hay standby, verificar que esté realmente alineado — no fiarse de los dashboards
Espacio y crecimiento	`dba_tablespaces`, `dba_hist_tbspc_space_usage`	Entender dónde se va a estrellar antes de que suceda, no después

Una vez leídas estas cinco cosas, tengo el 70% del cuadro. Las otras preguntas vienen después — y vienen enfocadas.

📚 De qué hablo aquí #

Historias reales, números concretos y lecciones aprendidas sobre Oracle en producción. Arquitectura, rendimiento, seguridad, migraciones, tuning SQL, PL/SQL, gestión del almacenamiento y decisiones de diseño que separan una instalación que funciona de una que sobrevive.

Nada de teoría de folleto. Solo lo que he visto funcionar — y lo que he visto fracasar — en entornos reales: seguros, telco, administración pública, banca, farmacéutico.

Con Oracle no basta conocer la sintaxis.

Hay que entender cómo razona el motor — y tener la humildad de admitir que, a veces, tiene razón él.