Buscar

Juan Andres Mercado Oracle Blog

Troubleshooting daily on Oracle Systems, Linux & more !

Categoría

Tunning

Analyzing SQL with SQL Tuning Advisor on Cloud Control 12c

Buenas Tardes Amigos, esta semana estuvimos realizando tareas de peformance en algunos customers puntuales.

Me sentí alegre, al poder recordar varias buenas practicas de Oracle con las cuales ya venimos operando con los consultores que están en mi equipo.

Problemática

  • Nos encontramos con aplicaciones que esta semana introdujeron un ciclo de cambios en producción mediante diferentes deploys.
  • Algunos querys pasaron de tiempos medidos en , mili segundos, segundos a minutos.
  • algunas aplicaciones dejaron de responder a tareas puntuales por medio time out.

Plan de acción

Como plan de acción (que ampliare en varios artículos de esta semana) decidimos hacer unas serie de tareas de monitoreo y con ello, proponer mejoras.

En el articulo de hoy, utilizaremos la herramienta Cloud Control, pero también comenzaremos a realizar las tareas por linea de comandos con el uso de los scripts sqltrpt.sql que nos servirá en caso de estar en un Customer , en donde no tengamos acceso a dicha herramienta o no esta instalado.

Cloud Control

En Cloud control , con el nombre de nuestra instancia de base de datos que fue seleccionada para ser analizada, usamos el siguiente proceso:

Performance >> Top Activity

En el browser podemos observar un escenario parecido a este:

Seguir leyendo “Analyzing SQL with SQL Tuning Advisor on Cloud Control 12c”

ORA-38171: Insufficient privileges for SQL management object operation

Cuando trabajamos en tareas de performance, es util poder ejecutar desde la linea de comandos (Con analisis previo) las recomendaciones propuestas por:

  • SQLPrt (linea de comandos, recomendaciones propuestas.)
  • SQL TUNNING SET.

Dichas recomendaciones pueden mostrarnos:

  • Cambio de Plan de Ejeuccion.
  • Reescritura de querys.
  • Creacion de Indices.
  • Creacion de Profiles.

Descripcion del problema

Con respecto a la creacion de PROFILES, el siguiente error aparecera  si no contamos con los privilegios necesarios para aplicar las recomendaciones obtenidas.

Ante el intento de setear un profile por comandos

El resultado que nos aparece es el siguiente:

SQL> execute sys.dbms_sqltune.accept_sql_profile(task_name => 'HEAVYQUERY',replace => TRUE);
BEGIN sys.dbms_sqltune.accept_sql_profile(task_name => 'HEAVYQUERY',replace => TRUE); 
*
ERROR at line 1:
ORA-24265: Insufficient privileges for SQL profile operation
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 79
ORA-06512: at "SYS.DBMS_SQLTUNE", line 5659
ORA-06512: at "SYS.DBMS_SQLTUNE", line 5535
ORA-06512: at "SYS.DBMS_SQLTUNE", line 5564
ORA-06512: at line 1

ORA-24265: Insufficient privileges for SQL profile operatio

Ante el intento de aplicar el PROFILE desde Cloud Control. Seguir leyendo “ORA-38171: Insufficient privileges for SQL management object operation”

Reclamable Space on Oracle Tables script

Cuando tenemos actividades en la base de datos, con tipo de transacciones que involucran  DML’s del tipo UPDATE, DELETE, derivara con el tiempo realizar tareas de mantenimiento y  reorganización de datos.

De esta manera la TABLA se ira degradando.

La acción requerida, sera compactarla, reorganizarla.

Parte de nuestra tarea consiste en averiguar las TABLAS candidatas a ser reorganizadas, con el método SHRINK.

Por ello, es necesario revisar y contar con un listado.

Ejecutar el siguiente query

*Agradecemos a Lucas Juarez por compartirlo.

set line 200
set pages 200
col OWNER format a10
    select 
	owner,
	table_name,
	mb_total,
	mb_usado,
	mb_total-mb_usado mb_reclamable,
	round((mb_total-mb_usado)/mb_total*100,2) "%_RECLAMABLE"
		from (select owner,table_name,round((blocks*8)/1024,2) mb_total, round((num_rows*avg_row_len/1024)/1024,2) mb_usado
					from dba_tables
						where owner not in ('ANONYMOUS','APEX_PUBLIC_USER','APEX_030200','APPQOSSYS','BI','CTXSYS',
                       'DBSNMP','DIP','DMSYS','EXFSYS','HR','IX','PUBLIC','MDSYS','ORACLE_OCM',
                       'LBACSYS','MDDATA','MDSYS','MGMT_VIEW','ODM','ODM_MTR','OE','OLAPSYS','ORDDATA',
					   'ORDPLUGINS','ORDSYS','OUTLN','PM','PERFSTAT','TSMSYS','SCOTT','SH','SI_INFORMTN_SCHEMA',
					   'SPATIAL_CSW_ADMIN_USR','OWF_MGR','SPATIAL_WFS_ADMIN_USR','SYS','SYSMAN','SYSTEM','TRACESRV',
					   'MTSSYS','OWBSYS_AUDIT','WEBSYS','WMSYS','XDB')
		and blocks <> 0 )
			where ( (mb_total > 10   and mb_total < 50 and round((mb_total-mb_usado)/mb_total*100,2) > 50 ) 
			or (mb_total > 50   and mb_total < 200 and round((mb_total-mb_usado)/mb_total*100,2) > 40 )
			or (mb_total > 200 and mb_total < 500 and round((mb_total-mb_usado)/mb_total*100,2) > 30 )
			or (mb_total > 500 and round((mb_total-mb_usado)/mb_total*100,2)  > 15 ) )
		order by mb_total desc;

Como resultado podemos obtener una salida como la siguiente: Seguir leyendo “Reclamable Space on Oracle Tables script”

Kill Session MetaQuery

Para hacer sencillo nuestro mundo, nada mejor que un metaquery que nos ayude a realizar una tarea que involucraría tiempo que no existe cuando surge una tarea delicada como la de matar cierto tipo de sessiones.

En el día de hoy compartimos el query de la semana, en un caso particular, donde se tuvo que matar sessiones de un aplicativo que conforma como parte de un ecosistema de aplicaciones , con el mismo repositorio y que afectaba la operatoria completa del negocio.

select 
'ALTER SYSTEM KILL SESSION '''||SID||','||SERIAL#||',@'||INST_ID||''' IMMEDIATE;' 
 query,
 inst_id, 
 sid,
 serial#,
 username,
 status,
 schemaname,
 osuser,
 module,
 machine,
 program,
 sql_id,
 logon_time,
 last_call_et,
 blocking_session,
 event,
 state 
        from gv$session 
           where machine like 'srvlappsp%' 
               and status = 'ACTIVE' order by last_call_et desc;

Saludos a LATAM, INDIA & German People y a Lucas Juarez por su aporte diario como DBA en nuestro equipo de trabajo !

Event Monitor (EMON) Slave Process Constantly Consuming CPU

Hoy tuve un problema en produccion en un Exadata X5, con 18 cores CPUS en cada nodo miembro del RAC.

Pude visualizar que estos eventos ocurrian por que estaban siendo generados por los procesos  ora_e000,  ora_e001 , ora_e0002,  ora_e0003 y  ora_e0004.

La base de datos en cuestion es una oracle database 11.2.0.4

Asi mismo revise que el mismo evento ocurria para las dos otras instancias que tenia en la maquina de computo.

[oracle@exaxxxxxx.com.ar] /home/oracle  > ps -ef | grep -i e00
oracle    24719  14021  0 13:28 pts/0    00:00:00 grep -i e00
oracle    42114      1  0 Feb16 ?        00:00:31 ora_e000_ARDOP2
oracle    42118      1  0 Feb16 ?        00:00:33 ora_e001_ARDOP2
oracle    42120      1  0 Feb16 ?        00:00:33 ora_e002_ARDOP2
oracle    42122      1  0 Feb16 ?        00:00:33 ora_e003_ARDOP2
oracle    42124      1  0 Feb16 ?        00:04:37 ora_e004_ARDOP2
oracle   118746      1  0 Mar29 ?        00:00:00 ora_e000_ARTOP2
oracle   118748      1  0 Mar29 ?        00:00:00 ora_e001_ARTOP2
oracle   118750      1  0 Mar29 ?        00:00:00 ora_e002_ARTOP2
oracle   118752      1  0 Mar29 ?        00:00:00 ora_e003_ARTOP2
oracle   118754      1  0 Mar29 ?        00:00:07 ora_e004_ARTOP2
oracle   172631      1  0 Feb23 ?        00:00:27 ora_e000_NTTOP2
oracle   172633      1  0 Feb23 ?        00:00:27 ora_e001_NTTOP2
oracle   172635      1  0 Feb23 ?        00:00:27 ora_e002_NTTOP2
oracle   172637      1  0 Feb23 ?        00:00:28 ora_e003_NTTOP2
oracle   172639      1  0 Feb23 ?        00:03:59 ora_e004_NTTOP2

Busco evidencia por medio de Cloud Control en la seccion de Performance Home

Vemos el consumo de CPU de los procesos en un nodo sin transacciones: Seguir leyendo “Event Monitor (EMON) Slave Process Constantly Consuming CPU”

Exadata Performance : Recommended Redo Log File Size >= 4GB

En el día de hoy estuve revisando un Exadata X5, en el cual pudimos verificar que no estaba cumpliendo con las políticas recomendadas para el tamaño de REDO, para las maquinas de computo
Oracle Exadata Machine.

Oracle, en su documentación oficial, recomienda que el tamaño de los REDOLOG file deben ser >= 4GB y < 32GB.

Como detalle, es importante saber que no es ideal superar la marca de los 32GB , salvo que se lo requiera el soporte de Oracle.

Esta recomendacion surge,  por que la máquina Exadata puede soportar una tasa extrema de I/O.

Con la última versión de Exadata X-6, se pueden realizar operaciones de I/O de lectura de base de datos de 5 KB hasta 8 GB, o operaciones de escritura de flash de 8 MB de 5 MB por segundo por rack completo.

Revisamos la base de datos en el Exadata:

SQL> SELECT a.group#,
                   b.STATUS,
                   a.MEMBER,
                   b.BYTES/1024/1024 "Size (Mb)"
     FROM gv$logfile a,
                 gv$log b
   WHERE a.group# = b.group# ;

    GROUP# STATUS           MEMBER                                                                            Size (Mb)
---------- ---------------- -------------------------------------------------------------------------------- ----------
         1 INACTIVE         +RECO_EXA/AMX/onlinelog/AMX_redolog_t1g1m2.log                                  512
         1 INACTIVE         +DATA_EXA/AMX/onlinelog/AMX_redolog_t1g1m1.log                                  512
         1 INACTIVE         +RECO_EXA/AMX/onlinelog/AMX_redolog_t1g1m2.log                                  512
         1 INACTIVE         +DATA_EXA/AMX/onlinelog/AMX_redolog_t1g1m1.log                                  512
...
...
         6 INACTIVE         +DATA_EXA/AMX/onlinelog/AMX_redolog_t2g6m1.log                                  512
         6 INACTIVE         +RECO_EXA/AMX/onlinelog/AMX_redolog_t2g6m2.log                                  512
         6 INACTIVE         +DATA_EXA/AMX/onlinelog/AMX_redolog_t2g6m1.log                                  512
         6 INACTIVE         +RECO_EXA/AMX/onlinelog/AMX_redolog_t2g6m2.log                                  512

48 rows selected.

SQL>

 

Algunas consideraciones:

  • Si la aplicación está generando una gran cantidad de LOG SWITCH, 4 GB puede que no sea suficiente y debemos considerar aumentarlo.
  • Los registros de REDO de tamaño inferior a 4GB, pueden llevar a interrupciones de registro innecesarios,  ya que en su mecanismo de control causan cuellos de botella en el rendimiento.
  • Se puede comenzar con el tamaño recomendado de 4 GB y observar los cambios de comportamiento antes de que decidamos aumentar o disminuir el tamaño del REDO.

Idealmente, los archivos de registro de REDO on line deben tener el mismo tamaño y estar configurados para cambiar aproximadamente una vez por hora durante la actividad normal.

Seguir leyendo “Exadata Performance : Recommended Redo Log File Size >= 4GB”

Exadata Performance: Verify the database server InfiniBand network

Verify the database server InfiniBand network is in “connected” mode.

Es semana tuve una visita en un cliente que debia resolver ciertos problemas de performance relacionados al tiempo de acceso al disco.

Sabiendo que nos podiamos encontrar con diferentes tipos de storage, fui preparado.

Mi sorpresa fue al conoce la noticia que esto ocurria en un Exadata. La experiencia me llevo por el camino de hacer un check general del equipo.

Entre el set list para comenzar con un analisis de performance del Exadata, revise cada uno de los siguientes puntos:

  • Verify the database server InfiniBand network is in “connected” mode.
  • Verify database server InfiniBand network MTU size
  • Optimize Scan Rates
  • Ensure Database Extent Sizes are at Least 4MB
  • Confirm correct latency for Small IOs
  • Recommended Memory Configuration
  • Capture Performance Baselines
  • AWR
  • ExaWatcher
  • OSWatcher

Iremos viendo el resto de los puntos en los siguientes posteos de Exadata. Seguir leyendo “Exadata Performance: Verify the database server InfiniBand network”

Crea un sitio web o blog en WordPress.com

Subir ↑

A %d blogueros les gusta esto: