ronald.vargas.quesada@gmail.com / Blog de Tecnologías Oracle desde 2009, San José, Costa Rica, 23 de Febrero 17 Aniversario -"No vivas para que tu presencia se note, sino para que tu ausencia se sienta" Bob Marley. Peter Drucker "No hay nada más inútil que hacer con gran eficiencia aquello que nunca debió hacerse."
Hace unos días empecé a ver Ted Lasso. Curiosamente, después de una copa de vino, la serie me llevó a pensar en algo que he visto repetirse durante más de treinta años trabajando en tecnología.
No hablo de servidores, bases de datos o proyectos.
Hablo de personas.
Con el tiempo uno descubre que no todas las contrataciones persiguen el mismo objetivo.
Hay empresas que contratan para construir.
Otras contratan para transformar.
Pero también existen aquellas que contratan para encontrar a quién cargarle el peso de un fracaso que comenzó mucho antes de que esa persona llegara.
Es una realidad incómoda.
Muchas veces creemos que nos buscan porque somos la mejor opción para resolver un problema complejo. Nos ilusiona pensar que podremos aportar nuestra experiencia, ordenar el caos y dejar una organización mejor de como la encontramos.
Sin embargo, en algunas ocasiones el desenlace ya estaba decidido.
El presupuesto ya estaba agotado.
La confianza ya estaba rota.
La dirección ya había perdido el rumbo.
Las decisiones importantes ya habían sido tomadas.
Y la contratación no era el comienzo de un rescate, sino el último acto antes del cierre del telón.
No eres el capitán del barco.
Eres el nombre que aparecerá en el informe final.
Durante mi carrera he visto excelentes profesionales fracasar en lugares donde, simplemente, nadie podía tener éxito.
Personas inteligentes, responsables y comprometidas que terminaron cuestionando su capacidad, cuando en realidad habían sido colocadas en un escenario donde el resultado estaba condicionado desde el primer día.
En informática esto ocurre con frecuencia.
Llega un nuevo gerente de TI cuando la empresa lleva años sin invertir.
Contratan un DBA cuando las políticas de respaldo nunca existieron.
Incorporan un arquitecto cuando el sistema acumula veinte años de deuda técnica.
Nombran un líder cuando el equipo perdió la confianza hace mucho tiempo.
Después, cuando nada cambia en unos cuantos meses, la conclusión parece sencilla:
"El nuevo tampoco funcionó."
Pero la pregunta correcta casi nunca es esa.
La pregunta debería ser:
¿Realmente alguien quería que funcionara?
Con los años también entendí que este fenómeno no pertenece únicamente al mundo laboral. Sucede en las relaciones personales.
Hay personas que llegan intentando reconstruir vínculos que llevan años deteriorándose. Intentan comunicarse. Intentan comprender. Intentan cambiar.
Mientras la otra parte ya tomó la decisión de irse hace mucho tiempo.
No buscan reconstruir. Buscan confirmar que ya no había nada por hacer.
Y entonces aparece alguien dispuesto a luchar una batalla que ya había terminado antes de comenzar.
La experiencia, sin embargo, también enseña algo esperanzador.
No todos los desafíos imposibles son una trampa. Algunas de las mejores historias profesionales nacen precisamente de proyectos que parecían condenados. La diferencia suele estar en algo que pocas veces aparece en una descripción de puesto.
La voluntad real de cambiar. Cuando existe esa voluntad, incluso con pocos recursos, los equipos encuentran caminos.
Cuando no existe, ni el mejor profesional del mundo puede fabricar compromiso donde nadie quiere asumirlo.
Si pudiera dar un consejo a quienes apenas comienzan su carrera, no sería "acepten todos los retos".
Sería algo distinto. Aprendan primero a identificar la naturaleza del desafío. Antes de aceptar un puesto, hagan preguntas difíciles:
¿Por qué se fue la persona anterior?
¿Cuántas personas han ocupado ese cargo en los últimos años?
¿Qué decisiones puede tomar realmente quien ocupe el puesto?
¿Existe presupuesto para cambiar las cosas?
¿La dirección está dispuesta a modificar aquello que provocó el problema?
Las respuestas a esas preguntas suelen revelar mucho más que una entrevista de una hora.
El talento es importante.
Pero también lo es elegir las batallas correctas.
Y para quienes ya acumulamos algunas décadas de experiencia, el aprendizaje quizá sea diferente.
No debemos confundir resiliencia con sacrificio infinito.
No tenemos que demostrar constantemente que podemos salvar cualquier proyecto.
Hay momentos en que la mayor muestra de madurez profesional consiste en reconocer que una organización no busca soluciones.
Busca un responsable.
Y son dos cosas completamente distintas.
Decir "no" también forma parte de la experiencia.
Renunciar antes de convertirnos en el chivo expiatorio de decisiones ajenas también es una forma de proteger nuestra integridad profesional.
No porque tengamos miedo de fracasar.
Sino porque entendimos que no todo fracaso nos pertenece.
Después de tantos años sigo creyendo que las personas pueden cambiar organizaciones.
He visto equipos extraordinarios lograr cosas que parecían imposibles.
Pero también aprendí que ninguna persona, por brillante que sea, puede reemplazar la voluntad colectiva de hacer que las cosas no funcionen.
Hay barcos que todavía pueden repararse. Y hay barcos que solo buscan un nuevo capitán para explicar por qué terminaron hundiéndose.
La experiencia consiste, precisamente, en aprender a distinguir unos de otros.
Porque, al final, el verdadero éxito profesional no siempre consiste en salvar todos los barcos.
A veces consiste en reconocer cuáles todavía quieren navegar.
No me hagan mucho caso, yo ya estoy un poco viejo y creo que la entrada en años me empieza a pasar factura.
Solo tengan presente una cosa, la vida es corta, mucho más de lo que crees cuando tienes 20, 30 o 40 años. Despues de los 50's, sólo piensas en una cosa: Como tener paz y como vivir bien.
Algunos dirán que con 58 años, aún me queda mucho por hacer. Y si, tienen mucha razón, pero mis prioridades actuales, son muy distintas a las de hace 20 años atrás.
En ocasiones, desearía correr detrás de un balón, saltar y golpearlo como lo hacía cuando tenía 20. Pero la realidad es otra. Mi cuerpo me lo recuerda cada mañana al levantarme y cada día al final. Ya no soy lo mismo y nunca más lo volveré a hacer. Esa es la realidad.
Lo único que nunca deberíamos permitirnos es cargar con la culpa de un fracaso cuya causa nunca estuvo en nuestras manos.
El Independent Automaton de Fleet Patching and Provisioning, también descrito por Oracle internamente en el contexto de FPP Local Mode, es una herramienta diseñada para realizar out-of-place patching entre dos ORACLE_HOME instalados en el mismo servidor, incluso cuando:
no existe Oracle Grid Infrastructure;
no existe Oracle Restart;
no existe un servidor FPP central;
los Oracle Homes no son working copies;
los Homes fueron instalados mediante runInstaller u otro método convencional.
Oracle permite a través de esta opción que 2 ORACLE_HOME instalados y no administrados por un servidor FPP, pueden ser migrados o actualizados.
La versión disponible del FPP en modo local solo dispone de un comando:
commands: move
objects: database
No contiene las funciones completas de un servidor o cliente FPP, como:
rhpctl add image
rhpctl add workingcopy
rhpctl query job
rhpctl deploy home
rhpctl move gihome
rhpctl upgrade database
rhpctl -version
y esto no esta mal, ya que es el comportamiento esperado en la versión autónoma.
La herramienta identifica las bases asociadas al Home origen y las cambia al Home destino.
Mi escenario para este laboratorio es el siguiente:
FPP integra la ejecución de datapatch como parte del movimiento, salvo que se le indique explícitamente no hacerlo.
Un punto importante mientras no se elimine ni modifique el Home de origen, puede realizarse el movimiento inverso.
No obstante, debe distinguir entre:
retornar los binarios al Home anterior;
revertir los cambios SQL aplicados por datapatch.
Después de que el RU nuevo haya modificado el diccionario, el retorno no debe tratarse simplemente como un cambio de variables. El procedimiento debe considerar el rollback SQL del RU, la compatibilidad y las opciones que soporte rhpctl. Por ello, el Home anterior debe conservarse hasta completar todas las validaciones funcionales.
A continuación podrás ver el procedimiento completo para realizar el cambio o actualización que describí previamente.
[oracle@oracle-server-26ai bin]$ ./rhpctl move database -h
Moves a database from source Oracle home to the patched Oracle home.
Usage: rhpctl move database -sid -sourcehome
-desthome
[-eval]
[-ignorewcpatches]
[-stopoption ]
[-drain_timeout
En mis charlas sobre "Ethical Hacking", me encanta hablar sobre “Neutralidad en Seguridad”. Me gusta ampliar el principio clásico de mínimo privilegio desde una perspectiva puramente técnica, hacia una dimensión de gobernanza, responsabilidad y protección del propio usuario.
El principio tradicional de mínimo privilegio (Principle of Least Privilege, PoLP) establece:
Una identidad (usuario, aplicación, proceso o servicio) debe recibir únicamente los privilegios estrictamente necesarios para ejecutar sus funciones autorizadas, durante el tiempo necesario y bajo las condiciones necesarias.
Sin embargo mi concepto agrega una capa adicional: un exceso de privilegios no solo incrementa el riesgo para la organización, sino que rompe la neutralidad del usuario frente a un incidente.
Para mi: Neutralidad en seguridad: es el principio mediante el cual los privilegios asignados a una identidad digital deben mantenerse alineados estrictamente con sus responsabilidades reales, evitando que permisos innecesarios conviertan a dicha identidad en un punto injustificado de exposición, sospecha o atribución dentro de un incidente de seguridad.
El punto central desde mi perspectiva, es que la neutralidad ocurre cuando, los Permisos concedidos = Responsabilidad funcional. Ni menos, ni más.
Desde el punto de vista de seguridad, un exceso de privilegios genera varios problemas:
1. Incrementa la superficie de ataque
Ejemplo en base de datos:
Un analista requiere:
SELECT sobre tablas de reportes,
pero recibe: SELECT ANY TABLE o peor aún "DBA".
El atacante hereda todo lo que la cuenta puede hacer, no solamente lo que el usuario normalmente hace.
2. Rompe la presunción operacional de inocencia.
Supongamos:
Usuario A: necesita consultar clientes, tiene acceso solo lectura
Usuario B: necesita consultar clientes, pero además tiene: borrar registros, exportar información, crear usuarios, modificar privilegios.
Si ocurre una fuga, desde un análisis forense el Usuario A:
¿Tenía capacidad técnica?
Respuesta: NO, menor probabilidad como origen.
En el caso del Usuario B:
¿Tenía capacidad técnica?
Respuesta: SÍ, debe investigarse. Aunque Usuario B sea inocente, los privilegios excesivos lo colocaron dentro del perímetro de sospecha.
3. La asignación excesiva de permisos crea responsabilidad compartida
Una frase que resume bien el concepto:
"Todo privilegio innecesario es una responsabilidad innecesaria transferida al usuario."
Dar privilegios no es solamente dar capacidad, también es asignar:
Tenemos un script para validar el crecimiento de objetos dentro de la base de datos en los últimos 6 días y cuando ejecutamos la consulta nos devuelve la siguiente salida.
El script en cuestión es el siguiente, asociado a una vista para poderlo ejecutar más fácil:
create view v_tablas_mas_crecimiento as
WITH snaps AS (
SELECT
MIN(snap_id) AS begin_snap,
MAX(snap_id) AS end_snap
FROM dba_hist_snapshot
WHERE begin_interval_time >= SYSDATE - 6
),
seg_begin AS (
SELECT
obj.owner,
obj.object_name AS segment_name,
obj.object_type AS segment_type,
ss.space_used_delta
FROM dba_hist_seg_stat ss
JOIN dba_hist_seg_stat_obj obj
ON obj.dbid = ss.dbid
AND obj.obj# = ss.obj#
AND obj.dataobj# = ss.dataobj#
JOIN snaps sn
ON ss.snap_id = sn.begin_snap
),
seg_growth AS (
SELECT
obj.owner,
obj.object_name AS segment_name,
obj.object_type AS segment_type,
SUM(ss.space_used_delta) AS growth_bytes
FROM dba_hist_seg_stat ss
JOIN dba_hist_seg_stat_obj obj
ON obj.dbid = ss.dbid
AND obj.obj# = ss.obj#
AND obj.dataobj# = ss.dataobj#
WHERE ss.snap_id BETWEEN (SELECT begin_snap FROM snaps)
AND (SELECT end_snap FROM snaps)
GROUP BY obj.owner, obj.object_name, obj.object_type
)
SELECT *
FROM (
SELECT
owner,
segment_name,
segment_type,
ROUND(growth_bytes/1024/1024,2) AS growth_mb
FROM seg_growth
WHERE growth_bytes > 0
ORDER BY growth_bytes DESC
)
WHERE ROWNUM <= 20;
select * from "V_TABLAS_MAS_CRECIMIENTO";
Qué son estos datos en el nombre del objeto ** MISSING: 6591054/6591054 ?
Vamos a explicarlo.
En Oracle, cuando estás consultando crecimiento histórico (normalmente desde AWR usando DBA_HIST_SEG_STAT y DBA_HIST_SEG_STAT_OBJ) y en lugar del nombre del objeto aparece algo como:
** MISSING: 6624752/6624752
significa que AWR tiene estadísticas históricas de un segmento, pero ya no puede resolver el objeto asociado en el diccionario histórico de objetos.
Hola gente comparto con ustedes esta información con la participación de uno de nuestros aliados en el#LAOUCTOUR2026Legadmi
📢 Webinar Exclusivo | Compliance y confianza: convierta los reportes SOC en una ventaja competitiva
¿Su empresa maneja información sensible o trabaja con proveedores que lo hacen?
Le invitamos a un webinar donde descubrirá cómo los reportes SOC 1 y SOC 2 pueden ayudarle a reducir riesgos, fortalecer la confianza de sus clientes y diferenciarse en el mercado.
📅 Fecha: 8 de julio 2026 ⏰ Hora: 9:00 a.m. – 10:00 a.m. 💻 Modalidad: Zoom Aprenda cómo:
✅ Evaluar y gestionar riesgos de proveedores críticos. ✅ Demostrar cumplimiento con estándares internacionales. ✅ Agilizar cierres
comerciales mediante mayor confianza y transparencia. 🎙️ Expositores: * José Manuel Ascanio – Director, Legadmi • Nelson Camargo – IT Risk Consultant Partner, Next Audit
👥 Dirigido a profesionales de Compliance, Auditoría, Riesgos, Seguridad de la Información, Compras, Finanzas, Tecnología y Operaciones.