performance tuning

Upload: diego-castro

Post on 12-Oct-2015

131 views

Category:

Documents


3 download

TRANSCRIPT

  • 1. Top-Down

    Oracle, a la hora de optimizar el rendimiento de nuestra base de datos recomienda un

    orden concreto de los aspectos a optimizar. Por ejemplo ponen el diseo de la base de

    datos por encima de la optimizacin del sistema o la instancia. Esta metodologa la

    denominan "Top-Down".

    Prioridad del rea a realizar tuning:

    * Tuning the Data Design

    * Tuning the Aplication Design

    * Tuning Memory Allocation

    * Tuning I/O and Physical Structure

    * Tuning Resource Contention

    * Tuning the underlying Platform(s)

    2. Alert log

    Los Alert logs son registros que contienen la informacin de mensajes de errores obtenidos por la variedad de actividades que se realizan en la base de datos. Estas

    actividades y registros estn almacenados cronolgicamente del mas antiguo al ms

    reciente. Este registro se encuentra en el directorio que hayamos fijado en nuestro

    init.ora bajo el parmetro BACKGROUND_DUMP_DEST. En una arquitectura OFA

    se recomienda que el directorio donde se encuentren estos archivos sea el siguiente:

    $ORACLE_BASE/adin/SID/bdump en sistemas UNIX. En sistemas tales como

    Windows 2000 segn este estndar podra encontrarse en

    %ORACLE_BASE%\admin\SID\bdump El nombre de este alert log ser alert_

    seguido de la instancia de la base de datos.

    Una de las cosas que podemos hacer para tener un seguimiento del alert log es

    mantener en un archivo las ltimas 1000 lneas de este registro. Para hacer esto

    podemos echar mano del comando tail

    Ejemplo:

    cd $ORACLE_BASE/admin/ALUMNOS/bdump

    tail 1000 alert_alumnos.log > alert_alumnos.log.ultimas

    mv alert_alumnos.log.ultimas alert_alumnos.log

    3. Trace files

    Oracle trace files son archivos de texto que contienen informacin de la sesin para el

    proceso que han creado. Trace files pueden ser generados por procesos background . Muchos de estos trace files contienen informacin sobre el tuning que se le debe hacer a una base de datos.

    - Background Trace Files: Los trace files ( ficheros de traza ) generados por los procesos background pueden ser

  • encontrados en el directorio especificado en el init.ora bajo el parmetro de

    BACKGROUND_DUMP_DEST . En sistemas que sigan el modelo OFA,

    $ORACLE_BASE/adin/SID/bdump en sistemas UNIX. En sistemas tales como

    Windows 2000 segn este estndar podra encontrarse en

    %ORACLE_BASE%\admin\SID\bdump

    Ejemplo de trace files para los procesos background:

    Nombre del proceso Sistemas UNIX Sistema Windows

    PMON Pmon_xxxx.trc sidPMON.trc

    SMON Smon_xxxx.trc sidSMON.trc

    DBW0 Dbw0_xxxx.trc sidDBW0.trc

    LGWR Lgwr_xxxx.trc sidLGWR.trc

    CPT Cpt_xxxx.trc sidCPT.trc

    ARC0 Arc_xxxx.trc sidARC0.trc

    - User trace files Los ficheros user trace files se encuentran tambin en el directorio especificado en el init.ora mediante el parmetro BACKGROUND_DUMP_DEST. Este fichero tambin

    incorpora en nombre de la instancia en los sistemas UNIX

    Ejemplo: Siendo alumnos el nombre de la instancia de nuestra base de datos

    ora_alumnos_4327.trc (sistemas UNIX) ora04327.trc (Windows 2000) , para identificar

    a qu usuario corresponde este trace file debemos de recurrir a dos vistas: V$PROCESS

    y v$SESSION.

    Con la siguiente consulta podramos obtener el usuario cuyo proceso corresponde al

    4327 :

    SQL > SELECT s.username,p.spid FROM v$session s, v$process p

    WHERE s.paddr = p.addr AND p.background is null;

    USERNAME SPID

    ----- ----

    USER1 4282

    USER2 5436

    USER3 4327

    USER4 4678

  • Activando las trazas de usuario:

    Cuando ocurre un error, el archivo de traza se genera automticamente, no obstante si el

    administrador de base de datos quiere que este archivo no solo se genere cuando haya

    un error entonces deber realizar lo siguiente:

    Instance-Level Tracing: Si ponemos en init.ora el parmetro SQL_TRACE=TRUE,

    todos los procesos generarn sus archivos de traza. El parmetro por defecto para

    SQL_TRACE es FALSE.

    User Level Self-Tracing Un usuario puede activar o desactivar en su propia sesin su

    trace file utilizando los siguientes comandos de SQL :

    SQL > ALTER SESSION SET SQL_TRACE=TRUE

    SQL > ALTER SESSION SET SQL_TRACE=FALSE

    User Level DBA Tracing Tambin podemos iniciar el user trace file mediante PL/SQL

    haciendo una llamada al paquete DBMS_SYSTEM. Este paquete de PL/SQL contiene

    un procedimiento que nos permite activar el user trace file de algn usuario

    simplemente sabiendo el sid y el serial ( serial# )

    Identificamos el sid y el serial# de un usuario llamado DAVID:

    SQL> SELECT username, sid, serial#

    FROM v$session

    WHERE username = DAVID';

    USERNAME SID SERIAL

    ----- -- ----

    DAVID 10 2642

    Activamos el trace file para la sesin de DAVID usando el paquete DBMS_SYSTEM

    PL/SQL y los valores para el sid y el serial que hemos obtenido en el punto 1.

    Utilizamos el procedimiento set_sql_trace_in_session del paquete dbms_system

    SQL > exec sys.dbms_system.set_sql_trace_in_session(10,2642,TRUE);

    La sesin de DAVID generar un trace file que estar especificado en el parmetro

    USER_DUMP_DEST de nuestro init.ora . En caso de que queramos para el trace file

    para el usuario DAVID ejecutaremos lo siguiente:

    SQL > exec sys.dbms_system.set_sql_trace_in_session(10,2642,FALSE);

    4. Cmo interpretar User trace file

    Una vez que estos trace file se han generado hay que aprender a interpretarlos. Se puede

    interpretar el contenido de un user_trace_file usando la utilidad TKPROF.

    Gestionando trace files:

    Podemos gestionar el tamao de estos archivos mediante una serie de parmetros en el

  • INIT.ora

    Parmetro especificado Tamao mximo para User Trace

    MAX_DUMP_FILE_SIZE=10000 10000 OS bloques

    MAX_DUMP_FILE_SIZE=500K 500000 bytes

    MAX_DUMP_FILE_SIZE=10M 10 megabytes

    MAX_DUMP_FILE_SIZE=unlimited No limits on file size

    Performance Tuning Views Hay dos tipos de vistas de ORACLE que nos dan informacin:

    Las v$ dynamic performance views Las DBA Data dictionary views

    Los nombres de las vistas v$ son generalmente singulares de las DBA views que

    utilizamos con nombres en plural. Un ejemplo para esto es V$datafile vs

    DBA_DATA_FILES.

    Muchas de las vistas estn disponibles cuando la base de datos est en estado nomount

    mount. Las DBA views slo estn disponibles cuando la base de datos est abierta

    (open)

    Hay aproximadamente unas 225 V$, estas vistas estn basadas en tablas dinmicas

    conocidas colectivamente como X$ tablas. Estas tablas existen en memoria con

    nombres encriptados como X$KSMPS.

    Ejemplo de v$dynamic performance views.

    Nombre de la vista Descripcin de la vista

    ------------------ --------------------------

    V$SGASTAT Tamao de todas las estructuras de memoria

    V$STATNAME Estadsticas del V$SESSTAT

    V$SYSSTAT Estadsticas del uso de cpu para todas las sesiones

    activas

    V$SESSTAT Estadsticas de las sesiones activas

    V$SESSION Sesiones activas.

    V$WAITSTAT Refleja la contencin en trminos del nmero de

    esperas en cuatro tipos de bloques de rollback

    Ejemplo de DBA Views

    Nombre de la vista Descripcin de la vista :

    ------------------ -------------------------

    DBA_TABLES Tablas, lneas e informacin de bloques

    DBA_INDEXES ndices, lneas e informacin de bloques

    DBA_DATA_FILES Ubicacin de los datafiles, nombre e informacin

    del tamao.

    DBA_SEGMENTS Informacin sobre el espacio consumido en los

    segmentos de base de datos

  • Ejemplo de consultas (query) para este tipo de vistas V$:

    SQL > Select s.username,n.name,t.value from v$session, v$statname

    n,v$sesstat t where s.sid=t.sid and t.statistic#=n.statistic# and

    s.username ='DAVID';

    DBA VIEW:

    SQL > Select table_name, chain_cnt

    from dba_tables

    where owner = DAVID'

    and chain_cnt !=0;

    Performance Tuning

    Resolver los problemas de rendimiento de la sesin en Oracle Database.

    Es la mitad de la noche, y usted tiene una llamada desesperada de alguien quejndose de que

    la base de datos es lenta. La persona que llama exige saber por qu, y qu vas a hacer al

    respecto. Suena familiar? Si es as, usted no est solo. El alto rendimiento es una expectativa

    comn de los usuarios del sistema de base de datos: se ponen muy infeliz cuando no lo

    entienden, y por lo general no son tmidos a la hora que le permite saber. Qu debe hacer a

    continuacin? En este artculo, usted aprender algunas tcnicas para Oracle problemas de

    rendimiento de base de datos de solucin de problemas.

    Para utilizar los scripts de este artculo, es necesario crear algunas tablas en un esquema de

    prueba y acceso a algunas vistas de rendimiento dinmico. El usuario de la base SYS tiene

    todos los privilegios para acceder a los puntos de vista, por lo que necesita la contrasea para

    el usuario SYS. La secuencia de comandos para la creacin de las tablas de ejemplo est

    disponible en la barra lateral.

  • Estado de la sesin

    disposicin

    Para configurar los casos de prueba para este artculo, ejecutar el SQL en esta seccin

    "Configuracin". El SQL se supone que tiene acceso para el usuario SYS, se puede crear un

    usuario llamado ARUP (lo que significa que usted no tiene un usuario con el mismo nombre), y

    tiene un espacio de tablas denominado USUARIOS con al menos 64 KB de espacio libre .

    Connect as SYS, and execute the following:

    connect sys/ as sysdba

    create user arup identified by arup

    default tablespace users

    /

    alter user arup quota unlimited on users

    /

    -- now connect as arup

    connect arup/arup

    create table t1

    (

    col1 number,

    col2 varchar2(1)

    )

    /

    insert into t1 values

    (1,z)

    /

  • commit

    /

    select tablespace_name, owner , segment_name objeto, file_id, block_id,

    CEIL(blocks*4/1024) Mbytes from dba_extents where owner='CARDO'

    select tableSPACE_name from dba_segments where tablespace_name='SYSTEM' and

    segment_type='TABLE';

    Antes de empezar a averiguar por qu una base de datos es lento, hay que entender primero

    que la base de datos en s mismo nunca es lenta o rpida tiene una velocidad constante. Las

    sesiones conectadas a la base de datos, sin embargo, reducir la velocidad cuando se topan con

    un bache en el camino. Para resolver un problema de rendimiento de la sesin, es necesario

    identificar el bulto y retrela. Afortunadamente, es muy fcil de hacer esto en la mayora de los

    casos.

    El primer paso para resolver un problema de rendimiento de la sesin es conocer lo que la

    sesin de base de datos est haciendo ahora. Una sesin de base de datos Oracle est siempre

    en uno de tres estados:

    Idle. No hacer nada-a la espera de ser dado algo de trabajo.

    Procesamiento. Hacer algo til-que se ejecuta en la CPU.

    Esperando. A la espera de algo, como un bloque que venir de un disco o una cerradura que

    se lanzar.

    Si una sesin est esperando a ser dada de trabajo (ralent), no es realmente lento en

    absoluto, simplemente no tiene nada que ver. Si una sesin est esperando que algn recurso,

    como un bloque o un bloqueo, se ha detenido el proceso. Hasta que llegue ese recurso, la

    sesin continuar esperando. Cuando se llega a ese recurso, lo hace algo de procesamiento y

    luego pasa al siguiente recurso que necesita, espera a que est disponible, y se inicia el

    proceso. . . y el ciclo contina hasta que la sesin no tiene nada ms que hacer. Si se espera a

    que los recursos muchas veces, la sesin aparecer lento. Pero no es muy lento: es slo

    siguiendo un patrn de marcha, parada, ir de nuevo, dejar de nuevo, y as sucesivamente. Tu

    misin es encontrar y eliminar los problemas de "parada" en el perodo de sesiones.

    Cun difcil es para obtener informacin sobre lo que est causando la sesin para dejar? En

    realidad es muy fcil: Base de datos Oracle se instrumenta a hablar de lo que las sesiones de

    base de datos estn haciendo. Todo lo que necesitas hacer es escuchar con atencin o, ms

    precisamente, buscar esa informacin en el lugar correcto, y ese lugar es una vista llamada V $

  • SESSION. Todo lo que necesita para su anlisis es en esta vista.

    Para explicar cmo se utiliza la vista V $ SESSION, voy a utilizar un escenario fila muy comn de

    bloqueo-como un ejemplo. Para seguir adelante, configurar primero las tablas mencionadas

    anteriormente, como se describe en la versin online de este artculo. A continuacin, conecte

    como usuario ARUP de dos sesiones diferentes. Desde la primera sesin, ejecute la siguiente

    instruccin SQL:

    update t1

    set col2 = 'x' where col1 = 1;

    La salida se mostrar "1 fila actualizada," lo que indica que la fila se ha actualizado. No emitir

    COMMIT despus de la declaracin. Al no haber cometido, se le fuerce la sesin para obtener

    y mantener un bloqueo en la primera fila de la tabla T1. Ahora ve a la segunda sesin y emitir

    la siguiente sentencia SQL:

    update t1

    set col2 = 'y'

    where col1 = 1;

    Esta declaracin se colgar. Por qu? La respuesta es simple: la primera sesin mantiene un bloqueo en la fila, lo que hace que el segundo perodo de sesiones para colgar y el usuario para quejarse de que la sesin es lento. Para saber lo que la segunda sesin est haciendo, lo primero que hay que comprobar es la columna STATE de V $ SESSION: select sid, state

    from v$session

    where username = 'ARUP';

    SID STATE

    3346 WAITING

    2832 WAITED KNOWN TIME

    Estudiar la salida con cuidado. Sesin 3346 (en la columna SID) indica que est esperando algo, y por lo tanto no funciona. Esa debe ser su primera pista de que la sesin est experimentando uno de esos golpes de rendimiento en la carretera. Pero antes de poder determinar que la sesin est esperando, vamos a estudiar el estado de la sesin de 2832 en la salida, lo que demuestra que esper a que una cierta cantidad de tiempo conocido antes. El punto importante es que la sesin de 2832 no est esperando nada en este momento, lo que significa que est funcionando de manera productiva. A continuacin, vamos a ver lo que el segundo perodo de sesiones (3346) est esperando. Esa informacin est disponible en la columna del evento en el mismo punto de vista V $ SESSION. La columna de evento no slo muestra un evento de una sesin est esperando que en la actualidad, sino que tambin muestra un evento de una sesin ha esperado antes. La consulta en V $ SESSION en el Listado 1 muestra la informacin de la columna de acontecimientos para las dos sesiones. Listado de Cdigo 1: La consulta para la visualizacin de las sesiones, el estado de sesin y eventos

  • select sid, state, event

    from v$session

    where username = 'ARUP';

    SID STATE EVENT

    2832 WAITED KNOWN TIME SQL*Net message from client

    3346 WAITING enq: TX - row lock contention

    La salida en el Listado 1 muestra que la sesin 3346 est esperando en estos momentos para un evento: "enq: TX - fila contencin de bloqueo"-abreviatura de "poner en cola para el bloqueo a nivel de transaccin en el corredor" o, en la llanura Ingls, un bloqueo a nivel de fila . La sesin est esperando porque quiere bloquear una o ms filas, pero otra sesin ya ha colocado bloqueos en la fila o filas. A menos que otra sesin se confirme o retrotraiga la transaccin, la sesin 3346 no conseguir la cerradura que necesita y no tendr ms remedio que esperar. Por otro lado, el estado de sesin de 2832, "Esperamos tiempo conocido," significa que est trabajando, no esperando-en estos momentos. Fue, sin embargo, a la espera antes de un evento llamado "* mensaje Net SQL desde el cliente" (voy a hablar de este evento especfico ms adelante). Hay una leccin muy importante en estos resultados: no se puede mirar en la columna Evento solo para averiguar lo que la sesin est esperando. Usted debe mirar en la columna STATE primero para determinar si la sesin est esperando o de trabajo y luego inspeccionar la columna EVENTO. Despus de determinar que una sesin est esperando algo, la siguiente cosa que usted necesita saber es el tiempo que la sesin ha estado esperando. Una larga espera por lo general indica una especie de cuello de botella. Dnde puede encontrar informacin sobre la duracin del perodo de espera? La respuesta est ah mismo en la vista V $ SESSION, en la columna SECONDS_IN_WAIT. Obtener la cantidad de tiempo que una sesin ha estado esperando tiene sentido para las sesiones que estn esperando este momento, pero qu pasa con las sesiones que estn trabajando ahora? Recordemos que la columna de la prueba para mostrar no slo el evento de una sesin est experimentando ahora, sino tambin el ltimo evento de espera de la sesin se ha experimentado. Otra columna-tiempo_espera-en la misma vista V $ SESSION muestra cunto tiempo dur esa espera. (Tenga en cuenta que tiempo_espera se muestra en centisegundos [centsimas de segundo].) Ahora que ya sabe cmo obtener informacin sobre las sesiones de espera y de trabajo, vamos a poner toda la informacin junta en una sola consulta, que se muestra en el Listado 2 Muestra claramente el estado de las sesiones: si estn trabajando o esperando;. si estn trabajando, lo que estaban esperando ms temprano y por cunto tiempo; y si ellos estn a la espera, para qu y por cunto tiempo. Listado de Cdigo 2: La consulta para la visualizacin de las sesiones, el estado de sesin, y esperar detalles col "Description" format a50

    select sid,

    decode(state, 'WAITING','Waiting',

    'Working') state,

    decode(state,

    'WAITING',

  • 'So far '||seconds_in_wait,

    'Last waited '||

    wait_time/100)||

    ' secs for '||event

    "Description"

    from v$session

    where username = 'CARDO';

    Output:

    SID STATE Description

    2832 Working Last waited 2029 secs for SQL*Net message from

    client

    3346 Waiting So far 743 secs for enq: TX - row lock contention

    4208 Waiting So far 5498 secs for SQL*Net message from client

    Evento inactivo Tenga en cuenta los detalles de la sesin de 4208 en la Lista 2; que actualmente est esperando 5.498 segundos para un evento de "SQL * Net mensaje desde el cliente". Recuerde que en la seccin anterior que una sesin de base de datos Oracle puede estar en uno de los tres estados: de trabajo, a la espera de un recurso, o en espera de trabajo. Pero, cmo puede una sesin de determinar si est en reposo? Se espera ser dado trabajo por los clientes a travs de SQL * Net, pero no hay manera para que sepa con anticipacin si la obra proviene de los clientes. Todo lo que puede hacer es esperar a alguna instruccin que viene a travs de SQL * Net. Hasta entonces, no tendr nada ms que hacer sino con nimo pronto mirar el * Interfaz de red SQL, y esta condicin se reporta como "SQL * mensaje netos por cliente" en la columna de eventos El V $ de vista de sesin, que es prcticamente lo mismo que estar inactivo. Puede pasar por alto otro valor de columna CASO, "RDBMS mensaje ipc," porque es un estado del evento para las sesiones que estn inactivos. Tenga en cuenta que una sesin inactiva no muestra IDLE como el valor de la columna ESTADO; todava muestra "Waiting". Usted tiene que comprobar la columna de eventos para determinar si la sesin es realmente ocioso. Usted puede tener la tentacin de modificar la consulta en el Listado 2 para sesiones de filtro que incluyen el "mensaje de SQL * Net del cliente" y "RDBMS mensaje ipc" eventos de inactividad. Aunque se puede hacer eso, yo altamente desalentar hacer eso, por mltiples razones. En primer lugar, no todas las instancias del evento "SQL * Net mensaje desde el cliente" indican que la sesin est inactiva. Considere la posibilidad de que la red podra ser realmente lento, en cuyo caso la sesin tambin se espera para estos eventos. Recuerde, la sesin no tiene la capacidad de determinar si el cliente es verdaderamente libre o est enviando instrucciones que son lentos o atrapados en la red. Lo nico que podemos hacer es esperar, y esperar con el evento "SQL * Net mensaje desde el cliente". En segundo lugar, los eventos de inactividad pueden dar algunas pistas sobre el soporte de Oracle sobre qu ms est sucediendo dentro de una sesin. As que te recomiendo que muestra estos valores evento "ociosas".

  • Diagnstico de bloqueo La salida del Listado 2 proporciona suficiente informacin para que pueda hacer un diagnstico sobre el funcionamiento de estas tres sesiones. Sesin 4208 est inactivo, por lo que cualquier queja que la sesin 4208 es lento pero no estn relacionados con la base de datos. Cualquier problema de rendimiento relacionado con esta sesin podra estar relacionado con un error en el cdigo que est pasando a travs de un bucle infinito o alto consumo de CPU en el servidor de aplicaciones. Puede redirigir el enfoque de solucin de problemas de rendimiento hacia el cliente de la aplicacin. La historia de la sesin de 3346 es diferente. Esta sesin es un verdadero cuello de botella para la aplicacin. Ahora que usted sabe por qu aparece esta sesin lento que est esperando un bloqueo de la siguiente pregunta lgica fila es la que sostiene que la sesin de cierre. La respuesta se encuentra tambin en-Espero que lo has adivinado-la vista $ SESIN V, en, ms especficamente, la columna de la BLOCKING_SESSION. (Tenga en cuenta que en un entorno Oracle Real Application Clusters [Oracle RAC], la sesin de bloqueo puede existir en una instancia diferente. En tal caso, se muestra el ejemplo de bloqueo en la columna de la V $ BLOCKING_INSTANCE de vista de sesin.) Usted puede averiguar la sesin de bloqueo y la instancia emitiendo la siguiente sentencia SQL: select

    blocking_session B_SID,

    blocking_instance B_Inst

    from v$session

    where sid = 3346;

    B_SID B_INST

    2832 1

    El resultado muestra claramente que la SID 2832 mantiene el bloqueo de ese SID 3346 est esperando. Ahora se puede seguir una relacin de causa / efecto entre la sesin en la que una actualizacin de una fila est bloqueada y la sesin que mantiene el bloqueo en esa fila. Usted puede encontrar la fila especfica que est bloqueado por encontrar primero la tabla que contiene esa fila. Para encontrar esa tabla, utilice el mismo V $ view perodo de sesiones; en este caso, la informacin se encuentra en la columna de la # ROW_WAIT_OBJ, que muestra el nmero de objeto de la tabla cuyas filas est siendo bloqueado. A continuacin, puede obtener el nombre de la tabla de la vista DBA_OBJECTS, el uso de este nmero de objeto, como se muestra en el Listado 3. Listado de Cdigo 3: Obtencin de informacin de bloqueo de fila select row_wait_obj#,

    row_wait_file#,

    row_wait_block#,

    row_wait_row#

    from v$session

    where sid = 3346;

    ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW#

    241876 1024 2307623 0

  • To get the object information:

    select owner, object_type, object_name, data_object_id

    from dba_objects

    where object_id = 241876;

    OWNER OBJECT_TYPE OBJECT_NAME DATA_OBJECT_ID

    ARUP TABLE T1 241877

    El resultado muestra que algunos fila de la tabla T1 es el punto de la contencin de

    bloqueos de fila. Pero qu fila especfica est bloqueado? Esos datos se encuentra

    disponible en tres V $ SESSION vista columnas ROW_WAIT_FILE #,

    ROW_WAIT_BLOCK # y ROW_WAIT_ROW #-que muestran la ID de archivo

    relativo, el identificador del bloqueo en ese archivo, y el nmero de ranura de la fila

    dentro de ese bloque, respectivamente, para que el concreto fila. Con esta informacin,

    se puede identificar el ROWID de la fila. El ROWID, la direccin fsica de cada fila de

    una instancia de base de datos Oracle, se puede utilizar para identificar de forma nica

    una fila.

    El Listado 4 muestra una secuencia de comandos SQL que permite seleccionar la fila

    bloqueo especfico de la tabla con la informacin recopilada hasta el momento. Guardar

    este script en un archivo llamado rowinfo.sql. El script espera que la entrada en el

    siguiente orden: propietario, nombre de la tabla, objeto #, # archivo, bloque #, y la fila

    #. Usted puede llamar a este script y pasar todos los parmetros requeridos copiando y

    pegando la salida correspondiente del Listado 3.

    Code Listing 4: Finding the row information

    REM Filename: rowinfo.sql

    REM This shows the row from the table when the

    REM components of ROWID are passed. Pass the

    REM following in this exact order

    REM 1. owner

    REM 2. table name

    REM 3. data_object_id

    REM 4. relative file ID

    REM 5. block ID

    REM 6. row Number

    REM

    select *

    from &1..&2

    where rowid =

    dbms_rowid.rowid_create (

    rowid_type => 1,

    object_number => &3,

    relative_fno => &4,

    block_number => &5,

    row_number => &6

    )

    /

  • SQL> @rowinfo ARUP T1 241877 1024 2307623 0

    COL1 C

    1 x

    La salida en el Listado 4 muestra la fila especfica en la que se solicita un bloqueo, pero que est bloqueado por otra sesin. Hasta ahora usted ha identificado no slo la sesin de origen de la cerradura, pero la fila especfica que se est bloqueado tambin. Es posible que el perodo de sesiones que tiene el bloqueo (SID 2832) es de alguna manera desconectado del cliente? Eso puede ocurrir en grupos de conexin o cuando los usuarios acceden a la base de datos con las herramientas de cliente complejo como Oracle SQL Developer. Despus de identificar la sesin que tiene el bloqueo, es posible que quiera esperar hasta que se confirme o retrotraiga la transaccin. Cualquier accin libera el bloqueo. En el caso de una desconexin, se puede decidir como alternativa para matar a la sesin, lo que obligar a una operacin de deshacer la liberacin de los bloqueos mantenidos por la sesin de bloqueo y permitir que las sesiones de espera para continuar. En ocasiones, el problema puede ser bastante simple: por ejemplo, alguien emiti una sentencia UPDATE de una herramienta de cliente pesado, pero se olvid de cometer y por lo tanto caus cada sesin que esperar a que esas filas actualizadas. La identificacin de que el bloqueo de sesin le permite enviar un recordatorio para rectificar esa situacin de inmediato. Ms sobre la Sesin En muchas situaciones de solucin de problemas, el hecho de saber el SID de cada sesin no es suficiente. Es posible que necesite saber otros detalles, como la mquina cliente que la sesin se conecta desde el usuario (tanto de la base de datos y el sistema operativo), y el nombre del servicio. Toda esta informacin tambin est disponible en el mismo V $ view SESIN usted ha estado utilizando. Vamos a examinar brevemente las columnas que proporcionan esa informacin, mediante la ejecucin de la secuencia de comandos se muestra en el Listado 5. Listado de Cdigo 5: Sesiones de un usuario especfico select SID, osuser, machine, terminal, service_name,

    logon_time, last_call_et

    from v$session

    where username = 'ARUP';

    SID OSUSER MACHINE TERMINAL SERVICE_NAME LOGON_TIME

    LAST_CALL_ET

    3346 oradb prodb1 pts/5 SYS$USERS 05-FEB-12

    6848

    2832 oradb prodb1 pts/6 SERV1 05-FEB-12

    7616

    4408 ANANDA ANLAP ANLAP ADHOC 05-FEB-12

    0

  • OSUSER. The operating system user as which the client is connected. The output

    indicates that session 4408 is connected from the ANLAP machine, where a Windows

    user, ANANDA, has logged in.

    MACHINE. The name of the machine where the client is running. This could be the

    database server itself. For two of the sessions, the machine name shows up as prodb1. Session 4408 runs on a different machineANLAPpresumably a laptop.

    TERMINAL. If the session is connected from a UNIX server, this is the terminal

    where it runs.

    LOGON_TIME. This shows when the session was first connected to the Oracle

    Database instance.

    Uso de las columnas que se muestran en el Listado 5, se puede obtener informacin muy detallada sobre las sesiones de un usuario. Supongamos que usted recibe una queja de que las aplicaciones que se ejecutan en el servidor de aplicaciones denominado appsvr1 estn experimentando problemas de rendimiento. Listado 6 muestra una consulta en la V $ SESSION vista-incluidas las columnas que ha utilizado en las consultas anteriores de este artculo, para las sesiones conectadas de esa mquina y la salida. Listado de Cdigo 6: espera de sesin para una mquina especfica col username format a5

    col program format a10

    col state format a10

    col last_call_et head 'Called|secs ago' format 999999

    col seconds_in_wait head 'Waiting|for secs' format 999999

    col event format a50

    select sid, username, program,

    decode(state, 'WAITING', 'Waiting',

    'Working') state,

    last_call_et, seconds_in_wait, event

    from v$session

    where machine = 'appsvr1'

    /

    Called Waiting

    SID USERNAME PROGRAM STATE secs ago for secs EVENT

    2832 ARUP sqlplus.exe Waiting 152 151 SQL*Net

    message

    from

    client

    3089 ARUP sqlplus.exe Waiting 146 146 enq: TX

    - row lock

    contention

    3346 ARUP sqlplus.exe Working 18 49 SQL*Net

    message

    from

    client

  • Desde la salida, se puede ver fcilmente que tres sesiones se conectan desde el servidor de aplicaciones appsvr1. Todos ellos se estn ejecutando SQL * Plus (como se muestra en la columna de la PROGRAM). SID 3346 es el nico que est trabajando (indicado por "trabajo" en la columna STATE). Debido a que est trabajando, la columna de la prueba para mostrar la ltima vez que la sesin esper. El tiempo de espera en este caso, no tiene sentido, porque la sesin no est esperando, pero en realidad funciona. La "Hace segundos llamado" la columna (que representan la columna "last_call_et" en V $ SESSION) muestra 18, lo que significa que la sesin hizo una llamada SQL hace 18 segundos. Las otras sesiones estn esperando. SID 3089 se espera un bloqueo de fila. Desde la salida, se puede ver que la sesin ha estado esperando durante 146 segundos y que tambin hizo su ltima llamada SQL hace 146 segundos. Esto indica que la sesin ha estado esperando a que el bloqueo en particular desde que hizo esa llamada SQL. Finalmente, la sesin 2832 tambin est a la espera; en este caso, se est a la espera de un evento "SQL * Net mensaje desde el cliente", lo que significa que est inactivo, en espera de ser dado algo de trabajo. La sesin dio a conocer su sentencia SQL hace 152 segundos y ha estado inactivo durante 151 segundos. Armado con esta informacin, se puede diagnosticar problemas de rendimiento con mucha precisin. Se puede decir que el usuario se queja de que una de las tres sesiones conectadas desde el servidor de aplicaciones appsvr1, una sesin est inactiva, se est trabajando, y uno est a la espera de una cerradura. El usuario se refiere probablemente a la lentitud de este ltimo perodo de sesiones. Ahora usted sabe la razn y cmo se puede rectificar. Conseguir el SQL Otra pieza clave de la informacin de ajuste de rendimiento es la sentencia SQL se est ejecutando una sesin, lo que proporcionar ms conocimientos sobre el funcionamiento de la sesin. El mismo punto de vista V $ SESIN tambin muestra la informacin de los estados de SQL. La columna SQL_ID en la vista V $ SESSION muestra el identificador de la ltima sentencia SQL ejecutada. Usted puede obtener el texto de la declaracin SQL de la vista V $ SQL, utilizando el valor SQL_ID. He aqu un ejemplo de cmo he identificado la sentencia SQL ejecutada por la sesin que aparece lenta para el usuario select sql_id

    from v$session

    where sid = 3089;

    SQL_ID

    g0uubmuvk4uax

    set long 99999

    select sql_fulltext

    from v$sql

    where sql_id = 'g0uubmuvk4uax';

    SQL_FULLTEXT

    update t1 set col2 = 'y' where col1 = 1

    Datos cuestiones relativas al acceso

  • He utilizado el bloqueo de filas como la causa de una desaceleracin en este artculo.

    Aunque la contencin de bloqueo relacionada-es una causa muy comn, no es la nica

    causa de los problemas de rendimiento. Otra de las principales causas de la discordia es

    el disco I / O. Cuando una sesin recupera los datos de los archivos de datos de base de

    datos en el disco para la cach del bfer, tiene que esperar hasta que el disco enva los

    datos. Esta espera se presenta para esa sesin como "db lectura secuencial" (para

    exploraciones de ndices) o "archivo db lectura dispersa" (para las exploraciones de

    tabla completa) en la columna CASO, como se muestra a continuacin:

    select event

    from v$session

    where sid = 3011;

    EVENT

    db file sequential read

    Cuando vea este evento, ya sabes que la sesin est a la espera para E / S del disco para completar. Para que la sesin sea ms rpido, usted tiene que reducir ese perodo de espera. Hay varias maneras de reducir la espera: Reducir el nmero de bloques recuperados por la sentencia SQL. Revise la sentencia de SQL para ver si se est haciendo un completo recorrido de tabla cuando se debe utilizar un ndice, si est utilizando un ndice incorrecto, o si puede ser reescrito para reducir la cantidad de datos que recupera. Coloque las tablas utilizadas en la instruccin SQL en la parte ms rpida del disco. Considere aumentar el cach del bfer para ver si el tamao ampliado acomodar los bloques adicionales, por lo tanto, la reduccin de la E / S y la espera. Sintonice el subsistema de E / S para devolver los datos ms rpido. Pasos siguientes Leer ms sobre la optimizacin del rendimiento Base de datos Oracle Day 2 + Performance Tuning Guide 11g Release 2 (11.2) Oracle Database Performance Sintona Gua 11g Release 2 (11.2) Hay otras opciones tambin, pero las anteriores son las tcnicas de remediacin ms comunes. La actividad exacta que empresas depende de su situacin especfica, pero la primera tcnica de reducir el nmero de bloques recuperados por una declaracin SQL-casi siempre funciona. Cuando usted piensa acerca de la optimizacin para reducir el nmero de bloques, se puede leer la declaracin de SQL para ver qu tabla est siendo seleccionado. Pero lo que si usted ve a dos o ms tablas en la declaracin? Cmo se determina qu tabla es la causa de la espera? Para encontrar la mesa causando una cola, se le volver a utilizar la vista $ SESIN V. P1 y P2 columnas de la vista proporcionan informacin sobre el segmento de la sesin est esperando. Listado 7 muestra una consulta de P1 y P2, y la salida. Listado de Cdigo 7: Comprobacin de espera de acceso a datos select SID, state, event, p1, p2

  • from v$session

    where username = 'ARUP';

    SID STATE EVENT P1 P2

    2201 WAITING db file sequential read 5 3011

    La columna P1 muestra el ID de archivo, y la columna P2 muestra la ID de bloque. A partir de esa informacin en el resultado en el Listado 7, puede obtener el nombre del segmento de la informacin medida en dba_extents, como se muestra a continuacin: select owner, segment_name

    from dba_extents

    where file_id = 5

    and 3011 between block_id

    and block_id + blocks;

    OWNER SEGMENT_NAME

    ARUP T1

    Esto muestra que la tabla T1, propiedad de ARUP, se selecciona de entre por el disco

    en la sesin. Usted debe dirigir su atencin a esta mesa para la sintonizacin. Puede

    mover la mesa para un disco de alta velocidad para el ms rpido de E / S, o,

    alternativamente, usted puede centrarse en la fabricacin de E / S de esta tabla ms

    rpido al hacer cambios que afectan a esta tabla, como la creacin de nuevos ndices,

    crear vistas materializadas , o la construccin de una memoria cach de resultados.

    conclusin

    En resumen, este artculo presenta los siguientes pasos para iniciar una sesin de ajuste

    del rendimiento exitoso:

    Compruebe si la sesin est trabajando o esperando. En este ltimo caso, determinar

    lo que est esperando y el tiempo que ha estado esperando.

    Compare el perodo de espera de la sesin con el tiempo transcurrido desde que hizo

    un llamado SQL.

    Si la causa de la espera es una contencin de bloqueo, encontrar la sesin que tiene

    el bloqueo y obtener los detalles de la sesin. (Si la sesin tiene el bloqueo es una sesin

    hurfana, es posible que quiera matarlo para liberar el bloqueo.)

    Encuentra la sentencia SQL de la sesin se est ejecutando.

    Si la sesin est a la espera para E / S, averiguo qu segmento (tablas, vistas, ndices

    se materializ, y as sucesivamente) el I / O est esperando.

    Las tcnicas presentadas en este artculo le ayudarn a resolver el 20 por ciento de los

    problemas de rendimiento que te encuentres como DBA. Base de datos de Oracle se

    instrumenta para proporcionar informacin sobre su funcionamiento interno para que

    pueda concentrarse en la causa exacta de un problema, todo lo que tienes que hacer es

    escuchar.

    Espero sinceramente que este artculo le haya ayudado a darse cuenta de lo fcil que es

    para diagnosticar algunos problemas de rendimiento comunes pero aparentemente

  • espinosos en la Base de datos Oracle mediante la identificacin de las fuentes de

    informacin adecuadas. Tuning feliz!

    ---------------------------------------------..

    Ajuste de la CPU de SPARC para optimizar el rendimiento de la carga de

    trabajo en sistemas SPARC T4

    Puede utilizar controles de subprocesos de CPU dinmicos para optimizar el

    rendimiento de la carga de trabajo en sistemas SPARC T4.

    Estos controles de subprocesos permiten especificar el nmero de subprocesos de

    hardware que se activarn por ncleo. Las aplicaciones existentes pueden aprovechar las

    ventajas del rendimiento de subprocesos dinmicos para las CPU de SPARC sin tener

    que volver a escribirlas o compilarlas.

    En esta seccin, se describe cmo utilizar los controles de subprocesos de CPU para

    optimizar el rendimiento de la CPU en sistemas SPARC T4. El rendimiento de la CPU

    se puede optimizar a fin de obtener un rendimiento mximo mediante el ajuste de los

    ncleos de la CPU para que utilicen un nmero mximo de subprocesos de la CPU. De

    forma predeterminada, la CPU se ajusta para obtener un rendimiento mximo. El

    rendimiento de la CPU tambin se puede optimizar para las cargas de trabajo enlazadas

    a la CPU mediante el ajuste de los ncleos de la CPU para que maximicen el nmero de

    instrucciones por ciclo (IPC).

    Cargas de trabajo y modos de subprocesos de la CPU

    En sistemas SPARC T4, puede optimizar el rendimiento de la CPU mediante la

    especificacin del modo de subprocesos de la CPU. El modo de subprocesos puede

    configurarse de forma dinmica y por separado para cada dominio en el sistema. No es

    necesario reiniciar el sistema para cambiar el modo de subprocesos, y el modo

    establecido se mantiene tras los reinicios del dominio y los ciclos de energa de la

    plataforma.

  • Mediante la seleccin del modo de subprocesos de la CPU adecuado, puede mejorar el

    rendimiento de las aplicaciones y las cargas de trabajo que se estn ejecutando en un

    dominio. Puede seleccionar un modo de subprocesos que maximice el rendimiento o

    que maximice el nmero de instrucciones por ciclo de la siguiente forma:

    Maximizacin de rendimiento (max-throughput). Las cargas de trabajo que

    se benefician ms del alto rendimiento ejecutan muchos programas y realizan

    una gran cantidad de operaciones de E/S. Cuando optimiza para obtener un

    rendimiento mximo, permite que los ncleos de la CPU ejecuten

    simultneamente un nmero mximo de subprocesos de hardware. Este modo es

    mejor para ejecutar cargas de trabajo de aplicaciones combinadas y cargas de

    trabajo que tienen muchos subprocesos, como las realizadas por servidores web,

    servidores de bases de datos y servidores de archivos. Este modo se utiliza de

    forma predeterminada y tambin se utiliza en las plataformas SPARC T ms

    antiguas, como las plataformas SPARC T3.

    Maximizacin de IPC (max-ipc). Las cargas de trabajo que se benefician ms

    de los altos IPC normalmente son aplicaciones de un solo subproceso que estn

    enlazadas a la CPU, como los sistemas que ejecutan clculos aritmticos

    intensivos. Cuando optimiza para obtener un IPC mximo, permite que un

    subproceso de la CPU ejecute ms instrucciones por ciclo de CPU. Esta

    optimizacin se consigue gracias a la reduccin del nmero de subprocesos de la

    CPU que estn activos simultneamente en el mismo ncleo de la CPU.

    Seleccin del modo de subprocesos de la CPU

    Seleccione el modo de subprocesos de la CPU para un dominio mediante el comando

    ldm add-domain o ldm set-domain para definir la propiedad threading.

    ldm add-domain [threading=max-throughput|max-ipc] ldom

    ldm set-domain [threading=max-throughput|max-ipc] ldom

    La propiedad threading se utiliza para cambiar dinmicamente el modo de

    subprocesos especificando uno de los siguientes valores:

    max-throughput. Utilice este valor para seleccionar el modo de subprocesos

    que maximiza el rendimiento. Este modo activa todos los subprocesos que estn

    asignados al dominio. Este modo se utiliza de forma predeterminada y tambin

    se selecciona si no se especifica ningn modo (threading=).

    max-ipc. Utilice este valor para seleccionar el modo de subprocesos que

    maximice el nmero de instrucciones por ciclo (IPC). Cuando se utiliza este

    modo en la plataforma SPARC T4, slo un subproceso est activo para cada

    ncleo de la CPU asignado al dominio. La seleccin de este modo requiere que

    el dominio est configurado con la restriccin de ncleo completo.

    Utilice el comando ldm add-core o ldm set-core) para configurar la

    restriccin de ncleo completo. Consulte la pgina de comando man ldm(1M).

  • Tenga en cuenta que el cambio del modo de subprocesos activa o desactiva de forma

    dinmica los subprocesos de la CPU. Por lo tanto, el nmero de CPU virtuales que estn

    disponibles en el dominio tambin cambia dinmicamente.

    El modo de subprocesos max-ipc utiliza la restriccin de ncleo completo, por lo que

    debe cumplir con los requisitos y las limitaciones de la restriccin de ncleo completo

    para hacer lo siguiente:

    Cambie el nmero de ncleos que se asignan a un dominio.

    Active o desactive la restriccin de ncleo completo.

    Por lo tanto, para cambiar de forma dinmica el modo de subprocesos de un dominio en

    ejecucin al modo max-ipc, debe configurar el dominio con la restriccin de ncleo

    completo.

    Para obtener informacin sobre las restricciones, consulte Limitaciones de control de

    subprocesos. Para obtener ms informacin sobre los subcomandos add-domain y set-

    domain, consulte la pgina del comando man ldm(1M).

    Visualizacin del valor de la propiedad threading

    Puede utilizar los siguientes comandos para ver el valor de la propiedad threading:

    El comando ldm list -o resmgmt muestra las restricciones. La siguiente

    salida de ejemplo muestra que la propiedad threading est establecida en max-

    ipc: # ldm list -o resmgmt ldg1

    NAME

    ldg1

    CONSTRAINT

    whole-core

    max-cores=3 threading=max-ipc

    El comando ldm list -o cpu muestra las CPU virtuales desactivadas

    especificando un valor de 0 en la columna UTIL. El texto en negrita en el

    siguiente ejemplo de max-ipc muestra que slo un subproceso est activado por

    CPU: # ldm list -o cpu ldg1

    NAME

    ldg1

    VCPU

    VID PID CID UTIL STRAND

    0 8 1 0.3% 100%

    1 9 1 0 100%

    2 10 1 0 100%

    3 11 1 0 100%

    4 12 1 0 100%

    5 13 1 0 100%

    6 14 1 0 100%

    7 15 1 0 100%

  • 8 24 2 0.4% 100% ...

    El comando ldm list -l incluye toda la informacin sobre el dominio

    especificado. El texto en negrita en el siguiente ejemplo muestra que la

    propiedad threading est establecida en max-ipc: # ldm list -l ldg1

    ...

    VID PID CID UTIL STRAND

    0 8 1 0.6% 100%

    1 9 1 0 100%

    2 10 1 0 100%

    3 11 1 0 100%

    4 12 1 0 100%

    5 13 1 0 100%

    6 14 1 0 100%

    ...

    CONSTRAINT

    whole-core

    max-cores=3

    threading=max-ipc ...

    Limitaciones de control de subprocesos

    La funcin de controles de subprocesos tiene las siguientes limitaciones:

    Se aplican las limitaciones de la restriccin de ncleo completo. Consulte

    Asignacin de CPU.

    El valor de la propiedad threading no se mantiene despus de una migracin de

    dominio.

    La propiedad threading no se puede establecer en max-ipc mientras la

    administracin de energa est activada.

    Cuando se ejecuta la administracin de energa, todos los dominios deben tener la

    propiedad threading establecida en max-throughput.