¿Te imaginas una base de datos Oracle optimizándose por sí sola mientras descansas? Con Oracle Database 19c y las técnicas de AutoML (Auto Machine Learning), esto es posible.
En esta guía completa te mostraré paso a paso cómo recolectar datos de rendimiento, entrenar un modelo de ML, y usar sus predicciones para ajustar CPU, memoria (SGA/PGA), I/O y latencia, sin intervención manual constante.
¡Prepárate para transformar el rendimiento de tu base de datos!
Paso 1: Preparar el Entorno y la Tabla de Métricas
Antes de iniciar, necesitas una tabla que registre las métricas de rendimiento. Esta información histórica alimentará el modelo de ML, permitiéndole aprender patrones y anticipar necesidades de ajuste.
CREATE TABLE performance_data (
timestamp TIMESTAMP,
cpu_usage NUMBER, -- Porcentaje de uso CPU
latency NUMBER, -- Latencia promedio (ms)
io_usage NUMBER, -- Operaciones de I/O por segundo
sga_usage NUMBER, -- Porcentaje de SGA en uso
pga_usage NUMBER, -- Porcentaje de PGA en uso
query_complexity NUMBER -- Métrica que indica la complejidad
);
Paso 2: Recopilar Métricas de Rendimiento en performance_data
La frecuencia de captura recomendada sería cada 10-15 minutos (aunque puede ajustarse según el entorno). Además, se necesitarán al menos 2 semanas para identificar patrones, idealmente 1-3 meses para mayor precisión (aprox. 2,000-3,000 puntos de datos).
CREATE OR REPLACE PROCEDURE capture_performance_data
IS
BEGIN
INSERT INTO performance_data (timestamp, cpu_usage, latency, io_usage, sga_usage, pga_usage, query_complexity)
VALUES (
SYSTIMESTAMP,
(SELECT value FROM v$sysmetric WHERE metric_name = 'CPU Usage Per Sec'),
(SELECT AVG(elapsed_time) FROM v$sqlarea WHERE executions > 0),
(SELECT value FROM v$sysmetric WHERE metric_name = 'Physical Reads Per Sec'),
(SELECT (sga_target - sga_free_memory)/sga_target*100 FROM v$sgainfo),
(SELECT (pga_used_mem / pga_aggregate_target)*100 FROM v$pgastat),
(SELECT COUNT(*) FROM v$sql WHERE command_type = 3)
);
COMMIT;
END;
/
Paso 3: Entrenamiento del Modelo de Machine Learning
Una vez que tengas suficientes datos, puedes entrenar modelos para predecir cuándo ajustar parámetros. Cada recurso (CPU, memoria, I/O) tiene patrones propios, por lo que entrenar modelos separados permite un control más fino.
Ejemplo para Latencia (TUNING_LATENCY_MODEL):
BEGIN
DBMS_DATA_MINING.CREATE_MODEL(
model_name => 'TUNING_LATENCY_MODEL',
mining_function => DBMS_DATA_MINING.REGRESSION,
data_table_name => 'performance_data',
target_column_name => 'latency'
);
END;
/
Después, entrenaremos el modelo:
BEGIN
DBMS_DATA_MINING.START_AUTO_MODEL_BUILD(
model_name => 'TUNING_LATENCY_MODEL'
);
Tendrás que repetir el proceso de crear modelos y entrenarlos para cpu_usage, sga_usage, pga_usage, io_usage y query_complexity.
Paso 4: Interpretación y Ajuste de Parámetros
Una vez entrenado, el modelo puede usarse para predecir valores futuros. Con esas predicciones habrá que crear procedimientos PL/SQL para ajustar parámetros automáticamente.
Ajuste de CPU (CPU_COUNT)
Si el modelo TUNING_CPU_MODEL predice >80% de uso de CPU, aumentamos CPU_COUNT dentro del rango permitido (ej. 8 a 16). Si es bajo, lo reducimos.
CREATE OR REPLACE PROCEDURE auto_tune_cpu
IS
v_predicted_cpu NUMBER;
BEGIN
SELECT PREDICT_CPU_USAGE FROM TABLE(SELECT PREDICT(TUNING_CPU_MODEL) FROM performance_data)
INTO v_predicted_cpu;
IF v_predicted_cpu > 80 THEN
EXECUTE IMMEDIATE 'ALTER SYSTEM SET CPU_COUNT=16 SCOPE=BOTH';
ELSE
EXECUTE IMMEDIATE 'ALTER SYSTEM SET CPU_COUNT=8 SCOPE=BOTH';
END IF;
END;
/
Ajuste de Latencia (OPTIMIZER_INDEX_COST_ADJ)
Si la latencia predicha es alta (>100ms), bajar OPTIMIZER_INDEX_COST_ADJ a 50 para favorecer índices. Si es baja, mantenerlo en 100.
CREATE OR REPLACE PROCEDURE auto_tune_latency
IS
v_predicted_latency NUMBER;
BEGIN
SELECT PREDICT_LATENCY FROM TABLE(SELECT PREDICT(TUNING_LATENCY_MODEL) FROM performance_data)
INTO v_predicted_latency;
IF v_predicted_latency > 100 THEN
EXECUTE IMMEDIATE 'ALTER SYSTEM SET OPTIMIZER_INDEX_COST_ADJ=50 SCOPE=BOTH';
ELSE
EXECUTE IMMEDIATE 'ALTER SYSTEM SET OPTIMIZER_INDEX_COST_ADJ=100 SCOPE=BOTH';
END IF;
END;
/
Ajuste de SGA (SGA_TARGET)
Si sga_usage predicha >75%, aumentar SGA_TARGET a 6G; si es baja, 4G es suficiente (por ejemplo).
Ajuste de PGA (PGA_AGGREGATE_TARGET)
Si se prevé un uso >80%, subir a 3G; si no, dejar en 2G (si fueran nuestros parámetros de ajuste).
Ajuste de I/O (DB_FILE_MULTIBLOCK_READ_COUNT)
Si io_usage predice mucha lectura, aumenta el valor para leer más bloques por operación.
Paso 5: Automatizar las Ejecuciones de Ajuste
Por último, sería ideal programar procedimientos que se ejecuten periódicamente (alineado a la frecuencia de captura de datos) para que el sistema se autocalibre en tiempo real.
BEGIN
DBMS_SCHEDULER.CREATE_JOB(
job_name => 'AUTO_TUNE_ALL',
job_type => 'PLSQL_BLOCK',
job_action => 'BEGIN auto_tune_cpu; auto_tune_latency; auto_tune_sga; auto_tune_pga; auto_tune_io; END;',
start_date => SYSTIMESTAMP,
repeat_interval => 'FREQ=MINUTELY;INTERVAL=10',
enabled => TRUE
);
END;
/
Conclusión: Un Futuro sin Tuning Manual Constante con AutoML con Oracle Database 19c
Integrar AutoML con Oracle Database 19c es un paso hacia la autonomía del tuning. Al recolectar datos, entrenar modelos y aplicar ajustes automáticos:
- Ganas Tiempo: Menos ajustes manuales, más tiempo en tareas estratégicas.
- Mejoras Rendimiento: Ajustes precisos en CPU, memoria, I/O y latencia mejoran la experiencia del usuario.
- Te Adaptas al Cambio: La carga varía con el tiempo; tu sistema se adapta dinámicamente sin intervención.
¿Listo para dar el salto al tuning inteligente? Comparte tu experiencia, comenta tus resultados y ¡sigue innovando!
Échale un vistazo a nuestros servicios de soporte y mantenimiento Oracle. No dudes en contactarnos sin compromiso. Somos expertos en bases de datos Oracle.
¿Aún no conoces Query Performance? Descubre cómo puede ayudarte en tu entorno Oracle. Más información en su página de LinkedIn.
Sígue a GPS en LinkedIn