Estadísticas Extendidas en Oracle 12c: ¿Cómo, Cuándo y Qué?

En el día a día de la administración de bases de datos, nos enfrentamos a un dilema constante: el equilibrio entre rendimiento y estabilidad. Oracle nos ofrece un conjunto de herramientas muy poderosas para ayudar al optimizador de consultas a tomar mejores decisiones, y entre ellas destacan las estadísticas extendidas.

Son útiles, sí. Pueden ser la diferencia entre una consulta que tarda segundos y otra que se arrastra durante minutos. Pero también tienen un lado menos amable: cuando se usan sin control, pueden generar dependencias ocultas, columnas virtuales invisibles e incluso problemas serios al eliminarlas sin una estrategia.

Las estadísticas extendidas nacen para resolver una limitación del optimizador de Oracle. Normalmente, las estadísticas se generan por columna, y el motor asume que cada columna es independiente de las demás. En la práctica sabemos que eso casi nunca es así: columnas como país y ciudad, o fecha de inicio y fecha de fin, tienen una relación directa que impacta las consultas.

puede confundir al optimizador si no hay estadísticas sobre esa expresión, porque no sabe cuántos registros cumplen esa condición.

Escenarios de Uso de las Estadísticas Extendidas en Oracle 12c

• Estadísticas multicolumna (column groups): ayudan a capturar correlaciones entre columnas.

• Estadísticas sobre expresiones: permiten medir la selectividad real de funciones y transformaciones en filtros.

• Estadísticas multicolumna: entendiendo las correlaciones
  Para entender las correlaciones en las estadisticas multicolumnas, imaginemos un sistema de pedidos (REGISTRO_ENVIOS) donde cada fila tiene un PAIS y una CIUDAD. Si pedimos:
  SELECT * FROM REGISTRO_ENVIOS WHERE PAIS = 'Italia' AND CIUDAD = 'Roma' AND PEDIDO_ELECTRONICO IN ('iPhone 15 Pro', 'MacBook Air M3', 'Nintendo Switch OLED').
  El optimizador, sin estadísticas multicolumna, tratará PAIS y CIUDAD como si fueran atributos totalmente independientes. En el mundo real sabemos que ciudades y países están ligadas: la ciudad Roma probablemente solo existe dentro del país Italia.  El resultado, Oracle puede calcular cardinalidades erróneas y elegir planes ineficientes.
  La solución es sencilla: crear un grupo de columnas como estadística extendida:
  BEGIN
DBMS_STATS.CREATE_EXTENDED_STATS( ownname => 'SYSTEM', tabname => 'REGISTRO_ENVIOS',  extension => '(PAIS, CIUDAD));
 END;
  Con esto, Oracle entiende la relación y ajusta sus estimaciones. Esto no solo mejora el rendimiento de las consultas, sino que también hace que los planes de ejecución sean más consistentes.
  
• Estadísticas sobre expresiones: cuando los filtros no son directos; otro caso común ocurre con expresiones. Pensemos en la típica búsqueda insensible a mayúsculas:
  SELECT * FROM empleados WHERE UPPER(CIUDAD) = 'BOGOTA';
  Aquí el optimizador no sabe si ese filtro devuelve una fila, mil o diez mil. El resultado suele ser un escaneo completo.
  Podemos ayudarlo creando una estadística sobre la expresión:
  BEGIN
DBMS_STATS.CREATE_EXTENDED_STATS(
ownname   => 'SYSTEM',
tabname   => 'REGISTRO_ENVIOS',
extension => '(UPPER("CIUDAD"))');
END;
  De esa forma, Oracle “aprende” qué tan selectivo es aplicar UPPER sobre CIUDAD y elige un plan más ajustado.

• Riesgos y problemáticas
  Hasta aquí todo suena ideal, pero hay que hablar de los riesgos, especialmente en entornos críticos.

• Columnas virtuales ocultas.
  Al crear una estadística extendida, Oracle puede generar columnas internas que no vemos a simple vista. Algunas de ellas incluso pueden estar ligadas a índices. Eliminar estas estadísticas sin cuidado puede dar errores como:
  Es decir no todo lo que aparece en DBA_STAT_EXTENSIONS es eliminable.

• Dependencia de planes de ejecución.
  Si un aplicativo se ha acostumbrado a un plan generado con estadísticas extendidas, eliminarlas puede cambiar radicalmente el comportamiento de las consultas. Lo que antes duraba segundos puede dispararse a minutos.

• Impacto en aplicaciones externas.
  En entornos donde usamos ERP, CRM o aplicaciones de terceros, estas estadísticas pueden haber sido creadas como parte de la configuración inicial. Si desaparecen, los reportes pueden fallar o rendir mal.

• Dificultad de rollback.
  Si borramos sin un respaldo apropiado, no hay manera de “volver atrás”. El sistema tiene que recomputar desde cero y eso abre la puerta a inconsistencias o caídas de rendimiento inesperadas.

• Cómo deshabilitarlas y borrarlas con seguridad
  Deshabilitar la creación automática
  Oracle puede crear estas estadísticas de forma automática si está activado el parámetro AUTO_STAT_EXTENSIONS. Para evitar sorpresas:
  EXEC DBMS_STATS.SET_GLOBAL_PREFS(‘AUTO_STAT_EXTENSIONS’, ‘OFF’);
  De esta forma, solo existirán las que decidamos crear manualmente.
  Respaldar antes de tocar nada
  La mejor práctica es siempre exportar las estadísticas actuales a una tabla de backup:
  BEGIN
DBMS_STATS.CREATE_STAT_TABLE( ownname => 'SYSTEM', stattab => 'STATS_BACKUP' );  DBMS_STATS.EXPORT_DATABASE_STATS( stattab => 'STATS_BACKUP', statown => 'SYSTEM' );
END;
  Esto incluye también las estadísticas extendidas. Si algo sale mal, podemos restaurarlas con:
  BEGIN
  DBMS_STATS.IMPORT_DATABASE_STATS
    stattab => 'STATS_BACKUP',
    statown => 'SYSTEM'
  );
END;

• Eliminar solo lo necesario
  Podemos usar un script que elimine las estadísticas extendidas de todos los esquemas, excluyendo los esquemas del sistema, sin embargo, esto puede generar los errores mencionados anteriormente, por lo cual, la mejor alternativa, es ser selectivo con las estadísticas extendidas a borrar:
      BEGIN
DBMS_STATS.DROP_EXTENDED_STATS(
ownname   => rec.owner,
tabname   => rec.table_name,
extension => rec.extension
);
END

Buenas prácticas de Estadísticas Extendidas en Oracle 12c en entornos empresariales

Cuando hablamos de estadísticas extendidas en una base de datos de produccion, la recomendación principal es la prudencia. Estas son algunas buenas practicas que se pueden aplicar:

• No dependas de la creación automática, controlar qué estadísticas se generan evita sorpresas y asegura coherencia en los planes.
• Siempre respalda antes de borrar, exportar las estadísticas te da una “red de seguridad” para revertir cambios.
• Documenta cada acción, no basta con borrar: hay que dejar evidencia de qué extensión se eliminó, cuándo y por qué.
• Excluye los esquemas del sistema, nunca borres estadísticas de SYS, SYSTEM u otros esquemas internos, Oracle las requiere.
• Prueba en un ambiente de Test, antes de aplicar cambios en producción, simula el impacto en un entorno de pruebas.