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/<password> 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.