Bueno , Ya es oficial 🙂
Uno mas!
Responder
Archivo de la categoría: 12c
Checklist de SQLtuning en la version 12c
Hoy vamos a seguir con pequeñas 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 (también llamado optimización de querys flexibles) permite que el optimizador sea capaz de ajustar los planes en tiempo de ejecución y obtener información adicional que le permita obtener mejores planes de ejecución.
En ved de usar planes de ejecución fijos esta funcionalidad permite al optimizador el posponer el plan hasta el momento de la ejecución.
Esta funcionalidad se basa en dos métodos:
- Adaptative plans: Se centra en mejorar el plan del optimizador en runtime
- Adaptative statistics: Se centra en obtener estadísticas adicionales para mejorar las siguientes ejecuciones de una consulta
Adaptative plans
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ísticas actuales, que son mas exactas que las estadísticas iniciales que fueron obtenidas en una ejecución anterior. Cuando selecciona el plan el optimizador usará este plan en las siguientes ejecuciones (del child cursor)
Esta funcionalidad depende de los dos siguientes parámetros
optimizer_features_enable string 12.1.0.2 optimizer_adaptive_reporting_only boolean FALSE
Si ponemos el parámetro OPTIMIZER_ADAPTIVE_REPORTING_ONLY=TRUE el optimizador si que obtiene las estadísticas, pero no las usará (usará el default plan)
Lo que hace el optimizador con esta funcionalidad es que obtiene multiples subplanes para porciones del plan para determinar en tiempo de ejecución que método usar. Una vez el optimizador decide un plan dejará de recopliar estadísticas y usará este plan para las siguientes ejecuciones del child cursor
Podemos saber cuales de las SQL han usado esta funcionalidad mediante la nueva columna de la vista v$SQL IS_RESOLVED_ADAPTIVE_PLAN que tendría un Y
Cuando 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íamos de usar la función XDBS_XPLAN.DISPLAY_CURSOR
Este método también es “muy útil” con las ejecuciones paralelas , aquí se usa una técnica llamada hybrid data distribution
Adaptative statistics
Las Adaptative statistics son usadas por el optimizador para lidiar con los predicados complejos. En la versión 12 el dynamic sampling ha sido renombrado como dynamic statistics y puede obtener estadísticas no solamente de una tabla sino también de joins y predicados del tipo group-by
Esto se gestiona mediante el parámetro OPTIMIZER_DYNAMIC_SAMPLING (modificable a nivel sesión),que puede tener valores entre 0 y 11
|
LEVEL |
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 |
AUTOMATIC REOPTIMIZATION
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.
El optimizador usa estos dos métodos
Statistics feedback
También llamado cardinality feedback , lo que hace el planificador en este caso es mejorar los planes en los que encuentra cardinalediades erróneas , cuando se usa eeste método el optimizador compara las estadísticas que tiene con las cardinalidades observadas durante la ejecución, en caso de que difieran significativamente el optimizador hace dos cosas:
1- Guarda la cardinalidad nueva en las estadísticas
2- Crea un SQLplan mejor para las siguientes ejecuciones de esta consilta
Performance feedback
Esta funcionalidad neceita tener el parámetro PARALLEL_DEGREE_POLICY=ADAPTATIVE
Está mas enfocado a el grado de paralelismo, tras la ejecución compara el grado de paralelismo elegido por el optimizador con el grado de paralelismo,si los dos varían significativamente, el optimizador lo marcará para reoptimizacion y guardará las estadísticas para un mejor plan en la siguientes execuciones
SQL Plan directives
|
SI |
NO |
|
Creados en shared pool y bajados a sysaux Creados para SQL con cardinalidad incorrecta |
NO Gestionados NO para |
Uso avanzado de obtencion de estadisticas
La versión 12c nos aporta mejoras substanciales en lo que a la obtención de estadísticas se refiere
- Estadisticas online para bulk-load
- incremental statisticas
- concurrent statistics
- Extended statistics (gloumn group)
La version 12c introduce una mejora im
Online Statistics gathering for bulk-load
La version 12c introduce una mejora importante en la obtención de estadísticas en los procesos de carga BULK-LOAD, ahora el optimizador regoje estadísticas d manera automática en procesos de carga de este tipo, esto incluye los procesos deCTAS (create table as), INSERT INTO …
La base de datos obtendrá las estadísticas del objeto, es decir, si se hace sobre una tabla particionada obtendrá estadísticas a nuivel de tabla, pero no de paticion, si se hace sobre una partición si que obtiene estadísticas a nivel de partición , pero no a nivel global de la tabla.
La base de datos no obtendrá estadísticas en los casos de
• Esquema SYS
• Es una nested table
• Es un IOT (index organized table)
Incremental statistics
Antes de la 12c cuando había cambios en las filas de una de lsparticiones de la tabla cambiaban todaslas estadísticas de la tabla quedaban como STALE. En la 12c tenemos u nuevo parámetro llamado INCREMENTAL_STALENESS que nos permite determinar cuando las estadísticas de las particiones deben de ser consideradas como STALE.
El valor por defecto de este parámetro es NULL (lo que hace que se comporte como en la 11g)
Puede tomar los valores:
• USE_STALE_PERCENT: Las estadísticas de la partición no serán consideradas STALE hasta que el número de filas que se cambien no sea mayor del porcentaje que se indique ( 10% por defecto)
• USE_LOCKED_STATS: Si las estadísticas de la partición están bloqueadas se usarán para generar las estadísticas globales indepeneientemente de las filas que hayan sido modificadas
Otra mejora en las estadísticas incrementales está relaccionada con el EXCHANGE PARTITION, el Exchange partition permite meter los datos de una tabla como una partición de otra.
Concurrent statistics
Ahora es posible obtener estadísticas de la tabla y de los índices de manera concurrente,se puede configurar incluso que tablas particionadas quieres que usen esté método y cual no.
Para poder usar esta funcionalidad es necesario
• JOB_QUEUE_PROCESSES debe de ser mayor de 4
• Tener el resource manager habilitado
Esta funcionalidad usa la propiedad CONCURRENT del paquete DBMS_STATS en las prefrencias globales. Este puede tener 3 valoers
• MANUAL.concurrencia habilitada solo para las ejecuciones manuales
• AUTOMATIC: Concurrencia habilitado solo apra las automáticas
• ALL: habilitado para todas
El valor por defecto es OFF
SELECT DBMS_STATS.GET_PREFS('CONCURRENT') FROM DUAL;
OFF
Extended statistics/column group
La idea de esta funcionalidad es la de obtener estadísticas en casos en que los predicados son complejos. Ahora se pueden hacer dos tipos mas de estadísticas:
• Column group statistics: Estadistias sobre grupos de columnas
• Expression statistics: Estadisticas sobre columnas que son parte de un Where
El proceso para obtener este tipo de estadistiacas es:
1-Habilitar la monitorización de la carga, para esto se usa el paquete SEED_COL_USAGE del DBMS_STATS
exec DBMS_STATS.SEED_COL_USAGE(null,null,600)
2-Ejecutas la carga de trabajo
3-Revisas el uso de las columnas con DBMS_STATS.REPORT_COL_USAGE
Select DBMS_STATS.REPORT_COL_USAGE(‘ESQUEMA’,’TABLA’) from dual
4-creas las estadisticas grupales que consideres con DBMS_STATS.CREATE_EXTENDED_STATS
Select DBMS_STATS.CREATE_EXTENDED_STATS(‘ESQUEMA’,’TABLA’) from dual
Uso de Adaptive SQL Plan Management (SPM)
El SPM es el mecanismo que tiene oracle dede la 11c para evitar que los planes de ejecución se degraden, el SPM captura los SQLplans, verifica su rendimiento y en caso de ser mejorables los evoluciona.
El optimizador solamente utiliza los “know plans”, si fijamos a TRUE el parámetro OPTIMIZER_CAPTURE_SQLPLAN_BASELINES, entonces capturará los planes, pero seguirá usando solo los conocidos. El trabajo nocturno DBMS_SPM.EVOLVE_SQL_PLAN_BASELINES 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.
Este conjunto de planes conocidos es lo que llamamos una BASELINE
Esto forma parte del TUNNING PACK
SPM consiste en tres componentes
1-SQLPLAN baseline capture
2-SQLPLAN baseline selection
3-SQLPLAN baseline evolution
En la 12c Oracle ofrece el SPM Evolve Advisor que evoluciona los planes recientemente añadidos sn necesidad de que el DBA
Normalmente los pasos son:
• Create an evolve task
• (optionally) set evolve tas parameters
• Execute the evolve task
• Implement the recoomendatios in the task
• Report the task outcome
Checklist de informacion sobre usuarios en 12c con CDB/PDB
En esta entrada seguiremos con las cheklist de cosas a tener en cuenta en la nueva version 12c, en este caso trataremos la informacion sobre usuarios
Tenemos dos tipos de usuario.
- Commonuser: Tendrá la misma identidad en el root y en los PDB donde se le den permisos
- Local user: Solamente exisistirá en el PDB donde se declare.
Common users
Grant privileges a common users o common roles
Usuarios locales
Privilegios globales y locales
Roles locales y globales
Problemas con optachauto y resolucion de nombres (error code 238)
Hoy vamos a ver una entrada rápida
Recientemente me he encontrado con el error code 238 intentando llevar a cabo la aplicación de un parche con el optachauto.
Al intentar llevar a cabo el parcheado me devolvía el siguiente error:
root:$GRID_HOME/OPatch/opatchauto apply $PARCHES/26610308 OPatchauto session is initiated at Sun Nov 18 15:56:14 2017 Patch version not found OPatchauto session completed atSun Nov 18 15:56:20 2017 Time taken to complete the session 0 minute, 7 seconds opatchauto bootstrapping failed with error code 238.
La primera conclusion que debemos de sacar de esto. siempre hay que hacer el analize antes de la aplicacion, ya que de esa manera habríamos comprobado el error .
Tras mucho buscar en la web de soporte y abrir un caso con Oracle, encontramos el problema.
El fichero /etc/hosts de mi servidor tenia mas de dos entradas, supongamos que fuese algo similar a:
10.0.0.1 SERVER server server.dominio server-vip.dominio
Si desde el sistema operativo preguntábamos por cualquiera de las 4 entradas, el servidor funcionaba correctamente.
Sin embargo, al cambiar esa linea por
10.0.0.1 server server.dominio 10.0.0.1 SERVER SERVER.dominio 10.0.0.1 serve-vip server-vip.dominio
Todo volvió a funcionar a la perfeccion.
Un expediente X que nos sirve para recordar que no todo vale a la hora de solcitar las instalaciones a los equipos responsables de los sistemas operativos, las nuevas herramientas de gestion de los componentes de oracle (opatchauto,datapatch …) son muy potentes, pero no dejan de ser componentes externos a la base de datos que requieren de configuraciones correctas que, desgraciadamente no suelen estar tan documentadas como los prerrequisitos del GRID, RAC o Base de datos, por lo que siempre deberemos de velar por que los sistemas operativos donde se encuentran nuestros motores esten prefectametne configurados
Checklist de informacion sobre tablespaces en 12c con CDB/PDB
Vamos a ver una serie de entradas rápidas a modo de resumen sobre la version 12c
Administrar tablespaces en CDB/PDB
En general los tablespaces se gestionan de la misma manera que en las non-cdb-database, sin embargo hay algunas consideraciones para los tablespaces en los CBD
- Un tablespace permanente solamente puede estar asociado a un contenedor (PDB)
- Los tablespaces en un PDB se crean solo desde ese pdb
- Cada PDB deberá de tener su propio default tablespace
- Si un tablespace es creado en un contenedor (PDB), el tablespace se asocia directamente a este contenedor
- Un CDB (o cada instancia de un CDB en RAC ) solamente puede tener activo un Undotablespace
- Solamente hay un tablespace temporal (o un grupo temporal) para un CDB, el root usa este temporal, los PDB pueden usar este o crearse su propio temporarytablespace. Cuando un PDB se desconecta del CDB sus temporales también se desconectan con el .
- Cuando un usuario entre a un PDB y su tablespace por defecto no esté asociado a este PDB automáticamente se le asociará al usuario el tablespace por defecto del PDB
- El UNDO tablespace es común, al contrario que ocurre con el temporal un PDB no puede tener un tablespace UNDO especifico para el.
- Todos los PDB tienen su propio tablespace SYSTEM y SYSAUX, pero este tablespaceactua como un subconjunto del del ROOT$CDB,en estos tablespaces solamente se guardará información relativa a estos solo guardan los metadatos de usuario, los metadatos de Oracle están guardados en el el CDB.
Tablespace por defecto
- Cada PDB debe de tener un tablespace por defecto.
- Si ejecutas un ALTER DATABASE DEFAULT TABLESPACE XX; en el CDB$ROOT lo que estás cambiando es el del CDB$ROOT, para cambiar el default tablespace en uno de los PDBs has d ejecutar
ALTER PLUGGABLE DATABASE DEFAULT TABLESPACE XX;
Administrar tablespaces temporales
Como indicábamos arriba,solamente hay un tablespace temporal (o un grupo temporal) para un CDB, el root usa este temporal, los PDB pueden usar este o crearse su propio temporarytablespace. Cuando un PDB se desconecta del CDB sus temporales también se desconectan con el.