Crónica de una madrugada: Cuando SYS.siebel_stats amanece inválido en producción

Son las 3:00 AM. Estás revisando los reportes de salud de tu clúster RAC en producción y de pronto, una alerta llama tu atención: un objeto en el esquema SYS amaneció inválido. Y no es cualquier objeto, se llama siebel_stats.

El pulso se acelera por un segundo. Todos hemos estado ahí. Las preguntas caen en cascada: ¿Me hackearon? ¿Alguien metió las manos en el motor? ¿Es un proceso interno de Siebel que falló? Y lo más extraño: a los pocos minutos, el objeto vuelve a estar válido por arte de magia.

Como boticarios del dato, no podemos permitirnos cajas negras en nuestra infraestructura. Así que acompáñame a destripar este paquete, entender por qué hace lo que hace, y por qué, en realidad, es uno de los mejores aliados que puedes tener en un entorno Oracle 12c con CRM Siebel.

🔬 El Síntoma: ¿De dónde salió este fantasma?

Primero, bajemos las pulsaciones. Este paquete no es un intruso, pero tampoco viene preinstalado de fábrica ni con el motor de Oracle Database ni con los binarios de Siebel.

Si miramos bajo el capó y leemos la cabecera del código fuente, encontramos esta joya: REM \(Header: coe_gather_statistics.sql 11.4.4.6 2015/09/09 abel.macias carlos.sierra \)

Estamos ante una auténtica receta magistral del Oracle Center of Excellence (COE), firmada por referentes absolutos del rendimiento como Carlos Sierra y Abel Macias. Es un script implementado a medida (probablemente en alguna ventana de afinamiento pasada o por recomendación de Oracle ACS) para domar al Optimizador Basado en Costos (CBO) frente al complejo modelo de datos de Siebel.

¿Y por qué se invalidó y compiló solo? Pura mecánica de Oracle. Si alguna dependencia de este paquete (como la tabla de auditoría siebel_stats_log o alguna vista del diccionario de datos) sufre el más mínimo cambio o mantenimiento, el paquete pasa a estado INVALID. Cuando el Scheduler intenta correr la rutina de madrugada, entra en acción la Recompilación Diferida (Deferred Recompilation): Oracle nota la invalidez, verifica que la estructura sigue siendo coherente y lo recompila al vuelo, ejecutándolo sin que nosotros movamos un dedo.

⚗️ La Fórmula Magistral: Traduciendo el código

Lanzar un DBMS_STATS.GATHER_SCHEMA_STATS tradicional en un entorno Siebel es como intentar navegar por Santiago con un mapa del año 1990: el optimizador va a tomar decisiones desastrosas. Este paquete del COE interviene exactamente ahí.

Analicemos sus ingredientes clave:

• Filtro Quirúrgico: El motor no pierde tiempo. El script ignora la basura y se enfoca solo en tablas estándar de Siebel (S_%) y extensiones customizadas (CX_%), saltándose inteligentemente las tablas de ETL.

• La vacuna contra los Nested Loops: Siebel es especialista en crear cientos de tablas vacías. Si Oracle ve "0 filas" en sus estadísticas, asume un costo bajísimo y arma Nested Loops masivos que terminan asfixiando la CPU. ¿Qué hace nuestra fórmula? Si una tabla tiene menos de 15 registros, borra las estadísticas y bloquea la tabla (DBMS_STATS.LOCK_TABLE_STATS). Esto fuerza al motor a usar Dynamic Sampling, calculando la ruta en tiempo real. Magia pura.

• Evolución a 12c: El código es inteligente. Detecta que estamos en la versión 12.2.0.1 y delega el cálculo del muestreo a DBMS_STATS.AUTO_SAMPLE_SIZE. Este algoritmo de hash moderno es brutalmente rápido y nos entrega estadísticas precisas en una fracción del tiempo que tomaría en un 11g.

• Histogramas a la medida: La regla de oro en Siebel es recolectar estadísticas solo para columnas indexadas. Sin embargo, el script hace excepciones a mano para el corazón de la visibilidad del CRM (S_POSTN_CON, S_ORG_BU, S_ORG_GROUP), forzando el análisis de todas las columnas. Le estamos dando al optimizador una radiografía perfecta de dónde están los cuellos de botella.

💊 Contraindicaciones y Monitoreo

Tener a SYS.siebel_stats operando en las sombras no es un riesgo, es un seguro de vida. Su labor nocturna es la barrera entre un día de operaciones fluido y un colapso generalizado de la aplicación.

Como única recomendación de monitoreo, acostúmbrate a revisar periódicamente la tabla siebel_stats_log. Ahí es donde el procedimiento deja anotado si tropezó con algún ORA-XXXXX mientras tú y yo intentábamos dormir un par de horas.

Ahora les paso el micrófono a ustedes: ¿Les ha tocado lidiar con el optimizador en entornos Siebel pesados? ¿Tienen implementadas otras recetas del COE en sus motores? ¡Los leo en los comentarios para debatir!