Hoy vamos a seguir con peque\u00f1as notas sobre la nueva version 12c, en este caso veremos mejoras en la gestion de estadisticas y planes<\/p>\n
La nueva funcionalidad de los planes de ejecicion flexibles (tambi\u00e9n llamado optimizaci\u00f3n de querys flexibles) permite que el optimizador sea capaz de ajustar los planes en tiempo de ejecuci\u00f3n y obtener informaci\u00f3n adicional que le permita obtener mejores planes de ejecuci\u00f3n.
\nEn ved de usar planes de ejecuci\u00f3n fijos esta funcionalidad permite al optimizador el posponer el plan hasta el momento de la ejecuci\u00f3n.
\nEsta funcionalidad se basa en dos m\u00e9todos:<\/p>\n
Muchas veces el optimizador falla en la cardinalidad de las consultas generando un plan deficiente ( default plan), la funcionalidad de adaptative plans ajusta el plan a las estad\u00edsticas actuales, que son mas exactas que las estad\u00edsticas iniciales que fueron obtenidas en una ejecuci\u00f3n anterior. Cuando selecciona el plan el optimizador usar\u00e1 este plan en las siguientes ejecuciones (del child cursor)
\nEsta funcionalidad depende de los dos siguientes par\u00e1metros<\/p>\n
optimizer_features_enable string 12.1.0.2\r\noptimizer_adaptive_reporting_only boolean FALSE\r\n<\/pre>\nSi ponemos el par\u00e1metro OPTIMIZER_ADAPTIVE_REPORTING_ONLY=TRUE el optimizador si que obtiene las estad\u00edsticas, pero no las usar\u00e1 (usar\u00e1 el default plan)
\nLo que hace el optimizador con esta funcionalidad es que obtiene multiples subplanes para porciones del plan para determinar en tiempo de ejecuci\u00f3n que m\u00e9todo usar. Una vez el optimizador decide un plan dejar\u00e1 de recopliar estad\u00edsticas y usar\u00e1 este plan para las siguientes ejecuciones del child cursor
\nPodemos saber cuales de las SQL han usado esta funcionalidad mediante la nueva columna de la vista v$SQL IS_RESOLVED_ADAPTIVE_PLAN que tendr\u00eda un Y
\nCuando una consulta usa el Adptative Query Optimization el plan mostrado en el EXPLAIN PLAN no tiene por que ser el que ha usado, para ver el que ha usado deber\u00edamos de usar la funci\u00f3n XDBS_XPLAN.DISPLAY_CURSOR
\nEste m\u00e9todo tambi\u00e9n es \u201cmuy \u00fatil\u201d con las ejecuciones paralelas , aqu\u00ed se usa una t\u00e9cnica llamada hybrid data distribution<\/p>\nAdaptative statistics<\/h2>\n
Las Adaptative statistics son usadas por el optimizador para lidiar con los predicados complejos. En la versi\u00f3n 12 el dynamic sampling ha sido renombrado como dynamic statistics y puede obtener estad\u00edsticas no solamente de una tabla sino tambi\u00e9n de joins y predicados del tipo group-by
\nEsto se gestiona mediante el par\u00e1metro OPTIMIZER_DYNAMIC_SAMPLING (modificable a nivel sesi\u00f3n),que puede tener valores entre 0 y 11<\/p>\n
| <\/p>\n LEVEL<\/span><\/b> WHEN SAMPLE 0 Switches N\/A 1 At least one non-partitioned 32 2(default) One or This 64 3 Any 64 4 Any statement that meets level 3 criteria and any 64 5 Any 128 6 Any statement that meets level 4 criteria 256 7 Any 512 8 Any statement that meets level 4 criteria 1024 9 Any 4086 10 All statements All Blocks 11 The Automatically Muchas veces los Apdaptative plans no son posibles(queryes con joins ineficientes ..), en esos casos el optimizador opta por esta funcionalidad que es el automatic reoptimization, donde el optimizador cambia el plan para las siguientes ejecuciones. Tambi\u00e9n llamado cardinality feedback , lo que hace el planificador en este caso es mejorar los planes en los que encuentra cardinalediades err\u00f3neas , cuando se usa eeste m\u00e9todo el optimizador compara las estad\u00edsticas que tiene con las cardinalidades observadas durante la ejecuci\u00f3n, en caso de que difieran significativamente el optimizador hace dos cosas: SI NO Creados en shared pool y bajados a sysaux Creados para SQL con cardinalidad incorrecta La versi\u00f3n 12c nos aporta mejoras substanciales en lo que a la obtenci\u00f3n de estad\u00edsticas se refiere <\/p>\n La version 12c introduce una mejora im<\/p>\n La version 12c introduce una mejora importante en la obtenci\u00f3n de estad\u00edsticas en los procesos de carga BULK-LOAD, ahora el optimizador regoje estad\u00edsticas d manera autom\u00e1tica en procesos de carga de este tipo, esto incluye los procesos deCTAS (create table as), INSERT INTO \u2026 <\/p>\n La base de datos obtendr\u00e1 las estad\u00edsticas del objeto, es decir, si se hace sobre una tabla particionada obtendr\u00e1 estad\u00edsticas a nuivel de tabla, pero no de paticion, si se hace sobre una partici\u00f3n si que obtiene estad\u00edsticas a nivel de partici\u00f3n , pero no a nivel global de la tabla. Antes de la 12c cuando hab\u00eda cambios en las filas de una de lsparticiones de la tabla cambiaban todaslas estad\u00edsticas de la tabla quedaban como STALE. En la 12c tenemos u nuevo par\u00e1metro llamado INCREMENTAL_STALENESS que nos permite determinar cuando las estad\u00edsticas de las particiones deben de ser consideradas como STALE. Ahora es posible obtener estad\u00edsticas de la tabla y de los \u00edndices de manera concurrente,se puede configurar incluso que tablas particionadas quieres que usen est\u00e9 m\u00e9todo y cual no. Esta funcionalidad usa la propiedad CONCURRENT del paquete DBMS_STATS en las prefrencias globales. Este puede tener 3 valoers El valor por defecto es OFF <\/p>\n La idea de esta funcionalidad es la de obtener estad\u00edsticas en casos en que los predicados son complejos. Ahora se pueden hacer dos tipos mas de estad\u00edsticas: El proceso para obtener este tipo de estadistiacas es: El SPM es el mecanismo que tiene oracle dede la 11c para evitar que los planes de ejecuci\u00f3n se degraden, el SPM captura los SQLplans, verifica su rendimiento y en caso de ser mejorables los evoluciona.<\/p>\n El optimizador solamente utiliza los \u201cknow plans\u201d, si fijamos a TRUE el par\u00e1metro OPTIMIZER_CAPTURE_SQLPLAN_BASELINES, entonces capturar\u00e1 los planes, pero seguir\u00e1 usando solo los conocidos. El trabajo nocturno DBMS_SPM.EVOLVE_SQL_PLAN_BASELINES\t comprueba los planes con carga mas alta y mira a ver si hay un plan mejor, para que , de manera manual el DBA lo evolucione y se use ese plan. En la 12c Oracle ofrece el SPM Evolve Advisor que evoluciona los planes recientemente a\u00f1adidos sn necesidad de que el DBA <\/p>\n Normalmente los pasos son: Hoy vamos a seguir con peque\u00f1as notas sobre la nueva version 12c, en este caso veremos mejoras en la gestion de estadisticas y planes Uso de Adaptative Execution Plans\/adaptative query optimization La nueva funcionalidad de los planes de ejecicion flexibles … Sigue leyendo |