You are on page 1of 40

UNIVERSIDAD NACIONAL

DE JUJUY
FACULTAD DE INGENIERIA

HERRAMIENTAS INFORMATICAS AVANZADAS


PARTE 6 SISTEMA OPERATIVO Y CONCURENCIA

Profesor Adjunto:
Ayudante de 1:

Ms. Ing. Hctor Pedro Liberatori


Lic. Claudia Panica
AO 2014

PARTE VI
SISTEMA OPERATIVO Y CONCURRENCIA

16.

Vistas Materializadas

17.

Monitoreo y Deteccin de Contencin

18.

Utilizacin del Gestor de Recursos

19.

Tuning del Sistema Operativo

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

VI VISTAS MATERIALIZADAS

Por lo general, cualquier accin ejecutada sobre la base de datos, resultar en alguna actividad de acceso de E/S.
Este tipo de acceso puede ser lgico (en memoria) fsico (a disco). Es muy importante formarse una perspectiva
de rendimiento al momento de querer mejorar estos tipos de accesos.
En captulos anteriores se han examinado las formas de identificar potenciales cuellos de botella de rendimiento,
tanto en los componentes lgicos como en los fsicos, de la arquitectura Oracle.
Tambin se ha visto los pasos que se deben seguir para mejorar el rendimiento en cada uno de estos componentes.
De todas formas, cada base de datos Oracle reside dentro de un servidor sobre alguno de los sistemas operativos
que soporta y sus correspondientes recursos de hardware. Debido a esto, muchos componentes y factores NO
Oracle relacionados al servidor, deberan ser considerados cuando se est realizando un acercamiento de la mejora
del rendimiento de la base de datos.
En esta seccin analizaremos el impacto que tienen estos componentes y factores NOOracle sobre la base de datos
y cmo es posible mejorar el rendimiento utilizando las caractersticas del Administrador de Recursos de Oracle
(Oracle Resource Management)

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 192

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIDAD 16
VISTAS MATERIALIZADAS

16.1. OBJETIVOS
Uno de los objetivos para con esta unidad, consiste en que al incorporar todos los conceptos contenidos en el
mismo, el alumno sea capaz de crear vistas materializadas; saber refrescar las dichas vistas y finalmente, poder
crear vistas materializadas anidadas.
Adems se pretende que el sepa manejar el uso del operador UNION ALL.
Finalmente se espera que se llegue a conocer el uso de la reescritura de consultas, y sepa activar y controlar las
reescrituras de las mismas.

16.2. CUESTIONARIO DE INICIACION

16.3. VISTAS MATERIALIZADAS


Los Bosquejos Almacenados (Stored Outlines) ayudan a hacer las consultas ms veloces al avisarle al optimizador
cmo armar el plan de ejecucin en funcin del plan que tenga almacenado previamente para esa consulta.
Las Vistas Materializadas tambin estn designadas para mejorar la velocidad de respuesta de las consultas, pero
en lugar de hacerlo almacenando el mejor plan de ejecucin, lo hace almacenando los datos de consultas con las
uniones funciones ya resueltas. A diferencia de las vistas tradicionales, las cuales solamente almacenan en el
diccionario de datos la sentencia SELECT que se debe ejecutar cuando se invoca esta vista, una Vista Materializada
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica

Pg. 193

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

almacena adicionalmente a la sentencia SELECT los resultados fsicos de la vista en su segmento propio e
independiente de la las tablas a la/s que la vista hace referencia. Este segmento al igual que cualquier segmento
puede ser almacenado en su propio tablespace y puede ser indexado particionado.
Las Vistas Materializadas tienen como objetivo ser utilizadas en sistemas de almacenamiento histrico
(DataWareHouse) de toma de decisiones (Decision Support Systems), donde los volmenes de informacin son
muy grandes y se suelen realizar consultas con varias uniones y funciones agrupadas. Al igual que el bosquejo
almacenado, el optimizador reconoce cundo utilizar una vista materializada y ajusta dinmicamente la consulta
para utilizar esta vista.
De la misma manera, a diferencia de los Bosquejos almacenados, una consulta no tiene que coincidir exactamente
en cuanto a la escritura de la sentencia SQL con la sentencia utilizada para crear la vista materializada. En lugar de
esto, el optimizador puede reescribir dinmicamente la consulta de la vista materializada para que sea igual a la
consulta SQL que se est ejecutando, con el fin de que se pueda utilizar este objeto. Esta funcionalidad de
reescritura de la consulta de definicin de la vista materializada ocurre en forma automtica y es transparente
para el usuario que est ejecutando la consulta SQL.

Figura 16.1

16.4. USO DE LAS VISTAS MATERIALIZADAS


Antes de poder utilizar las vistas materializadas, hay que tener en cuenta que se debe realizar una parametrizacin
previa. Esta tarea se realiza:
1) Determinando las sentencias SQL para las cuales se desea crear una vista materializada. Estas sentencias suelen
ser aquellas que envuelven tablas largas, uniones con otras tablas que tienen funciones de grupo, etc.
Oracle provee una utilidad que hace de Asesor de Totales (Summary Advisor) que puede ser utilizada para
identificar las sentencias SQL que podran ser buenas candidatas para ser incorporadas a vistas materializadas.
Esta utilidad tambin ayuda a identificar a aquellas vistas materializadas que no estn siendo utilizadas y se
podran eliminar.
2) Decidir cundo no se debera tener los datos sincronizados en la vista materializada con los datos de la las
tablas a las que hace referencia. Si no se desea tener los datos sincronizados, se podra especificar la opcin
NEVER durante la creacin de las vistas materializadas. De lo contrario, si se desea tener los datos
sincronizados, se podra especificar la opcin COMPLETE, FAST FORCE REFRESH al momento de la creacin.
Estas opciones afectarn el comportamiento de sincronizacin de la vista:
COMPLETE REFRESH: durante el refresco de los datos, la vista materializada es truncada y luego vuelta a
llenar con los datos originales, completamente en funcin de la consulta de definicin de la vista materializada.
FAST REFRESH: al momento de refrescar los datos, la vista materializada solamente se completar con
aquellos datos que han cambiado en la tabla base desde la ltima sincronizacin. Este refresco se puede hacer
utilizando un LOG de la vista el ROWID de los registros.

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 194

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

FORCE: Oracle intenta refrescar los datos de la vista materializada utilizando el mtodo FAST REFRESH en
primer lugar. Si este mtodo no se encuentra disponible, entonces se utiliza el mtodo COMPLETE REFRESH.
Force Refresh es el mtodo de sincronizacin por defecto.
3) Determinar la frecuencia de actualizacin para el mtodo de sincronizacin elegido. Esta frecuencia se puede
definir de tres formas:
ON COMMIT: los datos de la vista materializada son actualizados en cada confirmacin (COMMIT) de las
transacciones sobre la las tablas base.
Por Tiempo: utilizando las opciones START WITH y NEXT durante la creacin de la vista materializada, los
datos de esta vista pueden ser actualizados en un momento determinado y con una frecuencia definidos por
estos parmetros. De esta manera, para cumplir con esta tarea, se crea un Trabajo de Oracle (Oracle Job) en la
cola de trabajos de Oracle.
ON DEMAND: el DBA puede especificar la actualizacin manual de los contenidos de la vista materializada.
4) Definir los parmetros de inicializacin relacionados con las vistas materializadas. Estos parmetros son
comentados en la tabla de la Figura 16.2. Cabe destacar que los parmetros QUERY_REWRITE_ENABLED y
QUERY_REWRITE_INTEGRITY pueden ser definidos tambin a nivel de sesin con el comando ALTER SESSION.
Para poder hacer esta tarea, el usuario que se encuentra conectado a esa sesin debe tener privilegios de
GLOBAL QUERY REWRITE QUERY REWRITE. Adicionalmente, el usuario tiene la posibilidad de utilizar las
sugerencias (HINTS) REWRITE NOREWRITE a nivel de la escritura de la sentencia SQL, para habilitar
deshabilitar a nivel de sentencia la reescritura de la vista materializada. Continuando con el tema de los
privilegios, cuando un usuario accede a una vista materializada, este usuario debe tener privilegios sobre las
tablas base, en lugar de la vista en s.

Figura 16.2

16.5. CREACION DE VISTAS MATERIALIZADAS


Una vez que se han identificado las sentencias SQL candidatas para pertenecer a una vista materializada, se puede
proceder al proceso de creacin de las mismas. La Figura 16.3 muestra un ejemplo de creacin de una vista
materializada. En este ejemplo se crear una vista materializada llamada EMP_BY_DISTRICT y en cuanto a la
actualizacin de los datos de la vista, se actualizarn los datos desde la ltima actualizacin. EL optimizador de
Oracle utilizar la funcionalidad de la reescritura de la consulta para mejorar la sentencia SQL de la vista y esta
vista se crear con la opcin BUILD IMMEDIATE; las opciones posibles que tiene son:
BUILD IMMEDIATE causa que Oracle construya la vista materializada y la llene con los datos de la consulta,
inmediatamente despus de ejecutado el comando.
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica

Pg. 195

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

BUILD DEFERRED causar que Oracle construya la estructura de la vista materializada, pero sin insertarle
ningn dato hasta que ocurra el refresco.
ON PREBUILT TABLE causa que Oracle utilice una tabla existente que actualmente contenga los mismos datos
que la definicin de la vista materializada y en lugar de volver a crear una nueva estructura utilice la misma de
la tabla, junto a sus datos.

Figura 16.3

16.6. DESHABILITAR VISTAS MATERIALIZADAS


Las vistas materializadas pueden ser deshabilitadas a nivele de instancia, de sesin de sentencia, utilizando
alguno de los siguientes mtodos:
Definiendo el parmetro de inicio QUERY_REWRITE_ENABLED=FALSE y reiniciando la instancia, si se utiliza
un archivo de parmetros dinmico, se puede utilizar el comando ALTER SYSTEM para modificar este
parmetro en forma dinmica.
Cambiando este valor en forma dinmica a nivel de sesin con el comando ALTER SESSION.
Para trabajar este parmetro a nivel de sentencia, se debe poner la sugerencia (HINT) NOREWRITE.
Para poder realizar esta tarea, el usuario debe tener el privilegio de QUERY REWRITE GLOBAL QUERY REWRITE
para poder deshabilitar la reescritura de vistas materializadas de su esquema de cualquier esquema
respectivamente.
Finalmente, para poder eliminar una vista materializada, se debe ejecutar el comando DROP MATERIALIZED VIEW.
Este comando no afecta a ningn dato de las tablas base a las que la vista materializada haca referencia.

Figura 16.4
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica


Pg. 196

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

16.7. REFRESCO MANUAL


Las vistas materializadas pueden definirse para que se actualicen en forma manual en forma automtica. Las
actualizaciones manuales son realizadas con la utilizacin del paquete DBMS_MVIEW y las actualizaciones
automticas son definidas al momento de creacin de la vista materializada, al especificar la opcin COMMIT, con
una frecuencia agendada.
Entonces, para las actualizaciones manuales, el paquete DBMS_MVIEW posee tres procedimientos: REFRESH,
REFRESH_DEPENDENT y REFRESH_ALL_MVIEWS.
REFRESH actualiza una vista materializada en particular.
REFRESH_DEPENDENT actualiza todas las vistas materializadas que hacen referencia a una tabla base pasada al
procedimiento como argumento.
REFRESH_ALL_MVIEWS actualizar todas las vistas materializadas en el esquema que no se han actualizado desde
la ltima sincronizacin.
La Figura 16.5 muestra un ejemplo de la utilizacin de este paquete para las distintas alternativas de actualizacin
propuestas.
La actualizacin de los datos de la vista materializada puede definirse con la opcin REFRESH FAST ON COMMIT
REFRESH FAST COMPLETE ON COMMIT, lo que har que se actualicen los datos en cada confirmacin de
transacciones sobre las tablas base. De lo contrario, se podra haber creado la vista con la opcin REFRESH FAST
ON DEMAND REFRESH COMPLETE ON DEMAND, con lo que se debera utilizar el paquete PL/SQL DBMS_MVIEW
y el paquete DBMS_JOB, como se ve en la Figura 16.6.

Figura 16.5

Figura 16.6

16.8. USO DE EXPLAIN_MV O EXPLAIN_REWRITE


El paquete DBMS_MVIEW permite al DBA comprender y administrar ciertas capacidades sobre las vistas
materializadas, incluyendo la flexibilidad de la reescritura de sentencias de definicin de la vista. Tambin permite
la actualizacin de este tipo de vistas que no forman parte de algn grupo de actualizacin automatizado.
Para esto, analizaremos dos procedimientos de este paquete:
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica

Pg. 197

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

EXPLAIN_MVIEW: este procedimiento habilita al DBA a conocer qu vistas materializadas existen y las
opciones de actualizacin que se pueden ejecutar sobre sta.
La utilizacin de este procedimiento es muy beneficiosa. Simplemente el DBA debe llamar a este procedimiento
pasando como argumento el nombre del esquema y el nombre de la vista materializada que se quiere analizar.
Alternativamente se puede pasar como parmetro una sentencia SELECT para que sea analizada para ver si
vale la pena que forme parte de una vista materializada.
De esta manera, la vista materializada (o la vista potencial) es analizada par este proceso y los resultados son
escritos en unta tabla llamada MV_CAPABILITIES por defecto se puede especificar su escritura en un array
llamado MSG_ARRAY. Para contar con la tabla MV_CAPABILITIES se debe ejecutar su script de creacin llamado
UTLXMV.SQL
EXPLAIN_REWRITE: este procedimiento permite conocer por qu fall una reescritura de la sentencia de
creacin de la vista materializada, en caso de que s se pudo hacer la reescritura, permite ver qu vistas
materializadas afectar. De esta forma se pueden utilizar los resultados de este procedimiento para tomar las
acciones correctivas necesarias para corregir el problema. Para obtener los resultados en una tabla, se debe
ejecutar el script UTLXRW.SQL. Esto crear una tabla llamada REWRITE_TABLE en el esquema ejecutado.
El procedimiento REFRESH refresca consistentemente una o ms vistas materializadas que no son miembros del
mismo grupo de refrescamiento.
El procedimiento REFRESH_ALL_MVIEWS refresca todas las vistas materializadas que no refrescan los cambios en
su tabla maestra o en su vista materializada maestra.

Figura 16.7

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 198

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

16.9. EJERCICIO DE REPASO: REESCRITURA DE LA VISTA


Identificar los pasos que Oracle Server realiza al momento de analizar un plan de ejecucin junto a una vista
materializada.

16.10. EJERCICIO INTEGRADOR: VISTAS MATERIALIZADAS


Con el siguiente ejercicio el alumno comprobar sus conocimientos acerca de la totalidad de los temas tratados en
esta unidad.


Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica

Pg. 199

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

16.11. SINTESIS
En ambientes de datos histricos (DataWareHouse) se suelen utilizar vistas materializadas para mejorar el
rendimiento de la velocidad de consultas complejas a la base de datos.
Estas grandes consultas suelen involucrar uniones entre tablas y funciones de agregacin. Estas operaciones son
costosas en trminos de uso de recursos de la base de datos. Dependiendo de cmo se crean las vistas
materializadas en la base de datos, el optimizador actualizar y utilizar estas vistas.
Las vistas materializadas pueden ser utilizadas de varias formas, por ejemplo, una vista materializada puede
utilizarse para replicar informacin.
Las vistas materializadas mejoran notablemente el rendimiento de algunas consultas al precalcular uniones de
tablas costosas antes de su ejecucin normal. El optimizador de la base de datos reconocer en forma automtica,
cundo una vista materializada puede ser utilizada para resolver una consulta.
Esta operacin es transparente para el usuario y se puede valer de la caracterstica de reescritura de la definicin
de la vista.

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 200

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIDAD 17
MONITOREO Y DETECCION DE LA CONTENCION

17.1. OBJETIVOS
Esta unidad tiene por objetivo que el alumno pueda definir los niveles de bloqueo y sepa evitar problemas en los
mismos.
Adems, deber poder identificar las causas de contencin y resolver los problemas que dicha contencin genera.

17.2. CUESTIONARIO DE INICIACION

17.3. MECANISMO DE BLOQUEO


Como se ha visto en temas anteriores, Oracle provee mecanismos de proteccin para proteger el acceso a las
estructuras de memoria. Estos mecanismos se mantienen por un perodo de tiempo muy corto, con lo que las
contenciones por acceder a las estructuras de memoria son muy pequeas.
El Mecanismo de Bloqueo de Oracle es similar a los mecanismos de proteccin de memoria, con la diferencia que
los bloques son utilizados para proteger el acceso a los datos y no de las estructuras de memoria. Los bloqueos
suelen ser menos restrictivos que las protecciones de memoria.
Las solicitudes de bloqueo son encoladas en el orden en que se fueron produciendo y luego se aplicarn en el
mismo orden, este proceso es conocido como FIFO (First Input, First Output). Este encolado se realiza llevando un
registro de los usuarios que estn esperando un bloqueo.
La contencin del bloqueo puede ocurrir en momentos donde dos usuarios tratan de bloquear el mismo recurso al
mismo tiempo y aumentando su probabilidad de ocurrencia cuando mayor es la actividad DML y mayor es la
concurrencia de usuarios.
En definitiva, los bloqueos son utilizados para preservar la consistencia de los datos. Esto significa que los datos
que un usuario est cambiando se mantienen consistentes durante su sesin, por ms que otros usuarios tambin
estn realizando cambios. Oracle activa el mecanismo de bloqueo en forma automtica tratando de bloquear los
datos al menor nivel posible para no tener restricciones innecesarias sobre los datos de la aplicacin. En
consecuencia, si varios usuarios pueden modificar datos al mismo tiempo, la aplicacin comienza a tener la
capacidad de contar con concurrencia de datos.

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 201

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

Entonces, una vez que se ha producido un bloqueo en forma automtica, ste es mantenido por Oracle hasta que el
usuario que inici la transaccin la confirme (COMMIT) la rechace (ROLLBACK). A causa de esto, los bloqueos
pueden llegar a ser muy largos, dependiendo de la actividad de cada usuario y en consecuencia se puede perder
rendimiento en el acceso a los datos para otros usuarios de la base de datos que necesitan acceder a la misma
informacin.
En la mayora de los casos, el bloqueo que se produce suele ser a nivel de registro. Utilizando este tipo de bloqueo
que es por defecto, en Oracle mltiples usuarios podran:
Cambiar distintos registros de la misma tabla al mismo tiempo, sin problemas de bloqueo.
Actualizar el mismo registro de la misma tabla experimentando un encolamiento que determina quin realiza la
actualizacin (el primero que solicit la actualizacin) y quin debe esperar.
Por defecto, la cantidad mxima de usuarios encolados a la espera de un desbloqueo de un registro est
determinada por el parmetro de inicio SESSIONS. Este valor suele ser adecuado para la mayora de los casos en
ambientes transaccionales, pero si se desea modificar este valor manualmente, se debe definir el parmetro
ENQUEUE_RESOURCES.

Figura 17.1

17.4. TIPOS DE BLOQUEO


La Figura 14.2 muestra las dos situaciones de bloqueo que se pueden presentar (dos usuarios que quieren
actualizar registros diferentes y el mismo registro) sobre la tabla DEPT.
Como se puede observar, cuando el usuario JOE ejecuta una sentencia UPDATE, est bloqueando a nivel de
registro, el departamento de cdigo 20. Cuando el usuario MATT realiza un UPDATE, l bloquea el registro
correspondiente al departamento SALES. Como JOE y MATT estn haciendo bloqueos a diferentes registros,
ninguno de ellos es afectado por estos bloqueos. De la misma manera, si JOE realiza un SELECT de la tabla DEPT,
buscando por los datos del departamento SALES, el bloqueo de MATT no afectar a la consulta de JOE y en lugar de
esto (y teniendo en cuenta que MATT no ha finalizado la transaccin) JOE obtendr una imagen consistente de los
datos antes de su modificacin por MATT, ubicado en el segmento de Rollback de MATT. Finalmente, cuando MATT
trata de cambiar el nombre del departamento que tiene el cdigo 20, MATT experimentar una espera debido a
que ese registro se encuentra bloqueado por JOE, a nivel de registro. Esta espera continuar hasta tanto JOE no
libere el registro (con un COMMIT un ROLLBACK).

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 202

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

Figura 17.2

17.5. BLOQUEOS DML


Oracle utiliza dos tipos de bloqueo para realizar las operaciones de bloqueo. Un bloqueo DML de datos y un
bloqueo DDL de diccionario de datos. Cuando un usuario realiza alguno de estos dos tipos de bloqueo, Oracle, a
su vez, utiliza dos tipos distintos de modo de bloqueo para asegurar la concurrencia de los datos y su consistencia.
El bloqueo DML (o de datos), tambin llamado Exclusivo, bloquea un recurso hasta que la transaccin que realiz
el bloqueo finaliza. De esta manera, ningn otro usuario puede modificar este recurso mientras se encuentra
bloqueado de manera exclusiva.
El bloqueo DDL (o de diccionario de datos), tambin llamado bloqueo Compartido Shared, es el menos
restrictivo, ya que si bien bloquea un recurso, permite a otros usuarios tener el mismo bloqueo en el mismo
recurso.
Los bloqueos DML bloqueos de datos se denotan por la sigla TM (Table Modifications) y son utilizados para
bloquear la tabla cuando los usuarios estn realizando operaciones DML (INSERT, UPDATE, DELETE). De esta
manera, los bloques de datos pueden ser a nivel de registro a nivel de tabla. Cada usuario que realice DML sobre
una tabla, obtiene dos bloqueos en la taba:
Un bloqueo compartido a nivel de tabla
Un bloqueo exclusivo a nivel de registro.
Estos dos bloqueos son implcitos, esto significa que Oracle realiza las acciones de bloqueo por el usuario. Los
bloqueos explcitos pueden ser tomados cuando se realizan operaciones DML. Un bloqueo explcito requiere que el
usuario realice el bloqueo en forma manual, definiendo el tipo de bloqueo. La tabla de la Figura 1 hace una
comparacin de los modos de bloqueo utilizados por las operaciones DML.
Por defecto, la cantidad de bloqueos DML se deriva del valor del parmetro de inicio TRANSACTIONS. El valor que
toma por defecto suele ser ptimo, pero puede ser modificado manualmente definiendo el parmetro DML_LOCKS.

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 203

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA


Figura 17.3

17.6. BLOQUEOS DDL


Los bloqueos DDL bloqueos del diccionario de datos son bloqueos denotados por la sigla TX y son utilizados para
bloquear tablas cuando los usuarios las estn creando, modificando eliminando. Este tipo de bloqueo es siempre
a nivel de tabla y est designado para prevenir a los usuarios de modificar una tabla que est siendo eliminada
modificar su estructura simultneamente, por ejemplo. La tabla de la Figura 14.4 muestra una comparacin de los
diferentes modos de bloqueo para los bloqueos DDL.

Figura 14.4

17.7. HERRAMIENTAS DE DIAGNOSTICO PARA LOS BLOQUES (Parte 1)


Teniendo en cuenta la forma en que Oracle maneja los bloqueos por defecto, por lo general suele ser un mecanismo
muy efectivo que no presenta inconvenientes en el rendimiento. Pero cuando esto ocurre, la contencin de bloqueo
puede ser identificada utilizando varias vistas del diccionario de datos, como ser V$LOCK, V$LOCKED_OBJECT,
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica

Pg. 204

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

DBA_WAITERS y DBA_BLOCKERS. Tambin se puede contar con la utilizacin de la interface grfica Performance
Manager.
Las dos ltimas vistas mencionadas deben ser creadas ejecutando un script llamado CATBLOCK.SQL.
La vista dinmica de rendimiento V$LOCK contiene datos sobre los bloqueos que se estn produciendo en la base
de datos al momento de ejecutar una consulta sobre esta vista. Como se muestra en la Figura 14.5, esta vista
puede ser unida con la vista DBA_OBJECTS y V$SESSION para saber quin est manteniendo el bloqueo y sobre qu
objetos. En este ejemplo se ve que los usuarios SCOTT y JOE estn bloqueando la tabla EMP, la cual JOE es dueo. Si
JOE ha llamado a la mesa de ayuda diciendo que su aplicacin no responde, entonces el DBA puede ver de esta
forma si est ocurriendo algn bloqueo que no le permite continuar. De todas formas, se puede observar que esta
consulta no muestra informacin sobre quin est bloqueando y quin est esperando a que termine el bloqueo.
La vista V$LOCKED_OBJECT tambin lista todos los bloqueos que estn ocurriendo en la base de datos, pero
tambin incluye informacin de bloqueo mostrando qu usuario est realizando una transaccin sobre el objeto
que deriv en ese bloqueo. La consulta de la Figura 14.6 puede ser utilizada para determinar quin est
bloqueando el registro y quines estn esperando a la espera del desbloqueo.
El resultado de esta consulta muestra que el usuario SCOTT, JOE y BRENDA estn todos bloqueando registros en la
tabla EMP de JOE, mientras que ROBIN y REGI lo hacen en la tabla PAYROLL. Adems de esta informacin, se puede
observar con el campo NOM USUARIO qu usuario es quien tiene bloqueado el registro que previene a los otros
usuarios la continuacin de su trabajo. En el primer ejemplo, el usuario SCOTT tiene una transaccin que origin el
bloqueo sobre la tabla EMP, causando que los usuarios BRENDA y JOE experimenten una espera. Asimismo, la
transaccin de ROBIN sobre la tabla PAYROLL est bloqueando al usuario REGI para que termine su transaccin
sobre esa tabla.

Figura 14.5

Figura 14.6
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica


Pg. 205

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

17.8. HERRAMIENTAS DE DIAGNOSTICO PARA LOS BLOQUES (Parte 2)


La vista del diccionario de datos DBA_WAITERS contiene informacin sobre las sesiones de los usuarios que estn
experimentando esperas debido a bloqueos por otras transacciones de otros usuarios. La tabla de la Figura 14.7
muestra el contenido de esta vista.
La Figura 14.8 muestra cmo se consulta la vista de diccionario de datos DBA_WAITERS junto a la vista dinmica
de rendimiento V$SESSION, para obtener datos del usuario. En esta consulta se ve que el usuario MATT est
esperando un bloqueo de JOE para realizar un bloqueo en forma exclusiva a la tabla de JOE.
Frecuentemente el DBA no tiene decisin sobre qu tipo de bloqueo deben utilizar los desarrolladores, pero s
tienen como responsabilidad determinar qu usuario est causando una contencin de bloqueo. Para esto puede
utilizar la vista del diccionario de datos DBA_BLOCKERS que contienen slo una columna llamada
HOLDING_SESSION que muestra el ID de aquellos usuarios que estn bloqueando el acceso de otros usuarios a
recursos. La Figura 14.9 muestra un ejemplo de la utilizacin de esta vista, unida con la vista V$SESSION para
obtener informacin de la sesin. Esta vista muestra que el usuario JOE actualmente est bloqueando al menos
otro usuario tratando de obtener un bloqueo.
Como alternativa a la construccin de scripts propios para las vistas DBA_BLOCKERS y DBA_WAITERS, el DBA
puede utilizar un script que viene incluido, llamado UTLLOCKT.SQL, para mostrar informacin de bloqueo.

Figura 14.7

Figura 14.8
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica


Pg. 206

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

Figura 14.9

17.9. PERFOMANCE MANAGER


El componente Performance Manager del paquete de herramientas de diagnstico Oracle Enterprise Manager
incluye varias representaciones grficas de la actividad de bloqueo. La Figura 14.10 muestra un ejemplo de la
utilizacin de la pantalla del Administrador de Bloqueos del Performance Manager.
En este ejemplo se puede observar que el usuario de aplicacin HR tiene muchos bloqueos en la tabla
JOB_HISTORY.

Figura 14.10

17.10. PREVENCION DEL BLOQUEO


Los problemas de contencin de bloqueo, relacionados con el cdigo SQL, suelen tener dos orgenes: Los
desarrolladores de aplicaciones que realizan transacciones muy largas y aquellos desarrolladores que realizan
bloqueos explcitos muy restrictivos.
Para el caso de las grandes transacciones, si los desarrolladores codifican este tipo de transaccionalidad sin
confirmaciones intermedias y que a su vez tienen alta concurrencia de usuarios, es altamente probable que se
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica

Pg. 207

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

experimenten contencin de bloqueos. Para reducir esto, el cdigo de la aplicacin y su diseo, deberan incluir
puntos de confirmacin de transacciones intermedios para reducir los bloqueos de registros innecesarios.
Si los desarrolladores han codificado una aplicacin que contiene bloqueos explcitos y que son ms restrictivos
que los bloqueos por defecto de Oracle, entonces seguramente se experimentarn bloqueos en altos volmenes.
Estos casos suelen ocurrir cuando los desarrolladores utilizan con frecuencia el comando LOCK TABLE IN
EXCLUSIVE MODE dentro de la aplicacin. A menos que esto sea realmente necesario, los desarrolladores deberan
permitir que el mecanismo por defecto de Oracle acte normalmente para minimizar la contencin.
Muchas aplicaciones comerciales estn diseadas de manera que el cliente pueda utilizar estos productos con la
base de datos que deseen. Es por esto que este tipo de aplicaciones no sacan ventaja de las caractersticas
particulares que potencia cada fabricante de bases de datos. Debido a que no todos los motores de bases de datos
son propensos al bajo nivel de bloqueo, los desarrolladores que escriben este tipo de paquetes comerciales se ven
obligados a realizar este tipo de bloqueos explcitos y que son de una restriccin mucho mayor a la que puede
brindar Oracle, transformando esta aplicacin en un foco de grandes contenciones de bloqueo innecesarias.

Figura 14.11

17.11. SOLUCION A LOS BLOQUEOS


Si un usuario que est realizando un bloqueo no puede ser contactado para que finalice la transaccin, entonces el
DBA es el encargado de cerrar esa sesin que est causando contencin de bloqueo innecesaria, demorando el
resto de las transacciones. Esta tarea la realiza con el comando ALTER SYSTEM KILL SESSION para matar
cerrar forzosamente al usuario que est produciendo el bloqueo.
Este comando desconecta la sesin del usuario y realiza RollBack de todas las transacciones que no tengan
confirmado ese usuario. Antes de poder realizar esto, se debe saber el cdigo de la sesin que se quiere matar
(SID) y el nmero de serie (SERIAL#) de la vista V$SESSION, como se ve en la Figura 14.12.
Si todos los usuarios conectados a la aplicacin utilizan el mismo usuario de Oracle, puede agregar a esta consulta
las columnas OSUSER, MACHINE PROGRAM para poder determinar cul es la sesin que se debe matar.
Una vez que se ha identificado el SID y el SERIAL# de la sesin a eliminar, se puede ejecutar el comando KILL
SESSION:
SQL> ALTER SYSTEM KILL SESSION 12.8881;
Otra tcnica para reducir los bloqueos es utilizando el comando de Oracle 9i ALTER SYSTEM QUIESCE
RESTRICTED. Si el Resource Manager est habilitado, al ejecutar este comando causar que todos los usuarios
inactivos liberen los recursos, incluyendo aquellos que tienen bloqueados.

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 208

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

Figura 14.12

17.12. EJERCICIO DE REPASO: BLOQUEOS


Indicar el tipo de sentencia utilizado en cada caso para provocar el comportamiento siguiente:

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 209

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

17.17. MONITOREO Y DETECCION DE LA CONTENCION


Este ejercicio pondr a prueba los conocimientos adquiridos por el alumno acerca de la totalidad de los temas
tratados en esta unidad.

17.18. SINTESIS
Los temas relacionados al bloqueo pueden ser una fuente de problemas de rendimiento. Si bien el mecanismo de
bloqueo por defecto de Oracle es a nivel de registro, an pueden ocurrir problemas de rendimiento cuando el
cdigo de aplicacin utiliza niveles de bloqueo muy exigentes, se utilizan transacciones muy largas, el usuario
deja estas transacciones sin confirmar por un perodo de tiempo muy grande.
Oracle Server resuelve los deadlocks automticamente cuando ocurren en la base de datos. El DBA puede utilizar
las vistas dinmicas de rendimiento V$LOCK y V$LOCKED_OBJECT y las vistas del diccionario de datos
DBA_WAITERS y DBA_BLOCKERS para monitorear la contencin de bloqueo de la base de datos.
El DBA puede resolver tambin la excesiva contencin de bloqueos modificando el cdigo de aplicacin,
notificando a los usuarios que estn generando el bloqueo para que lo resuelvan, matando la sesin del usuario
que est generando el bloqueo.

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 210

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIDAD 18
UTILIZACION DEL GESTOR DE RECURSOS

18.1. OBJETIVOS
En la presente unidad se tiene por objetivo que el alumno pueda definir el Gestor de Recursos de la base de datos, y
sepa asignarle usuarios a sus diferentes grupos. Tambin se pretende que el alumno aprenda a crear planes de
recursos dentro de dichos grupos.

18.2. CUESTIONARIO DE INICIACION

18.3. REPASO DE LA UTILIDAD RESOURCE MANAGER


Como se ha visto en temas anteriores, Oracle utiliza muchos recursos de hardware mientras los usuarios de
aplicaciones acceden a la base de datos a travs de la Instancia. En aquellos casos en que estos recursos escasean,
el DBA debe asignarlos de manera que sean utilizados lo ms efectivamente posible.
Para versiones anteriores de Oracle 8i, esta tarea solamente poda llevarse a cabo limitando los recursos con la
utilizacin de perfiles. Pero estos perfiles no podan ofrecer la granularidad para ofrecer una solucin flexible a la
asignacin de recursos de hardware.
A partir de Oracle 8i se introduce una nueva caracterstica llamada el Administrador de Recursos Resource
Manager, el cual est designado para mejorar la asignacin de recursos y su posterior gestin. Utilizando esta
herramienta, el DBA puede crear grupos de recursos y asignarles lmites especficos de recursos. Estos grupos de
recursos pueden ser asignados a usuarios de la base de datos, los cuales heredan los lmites de estos grupos.
De esta manera, se ha creado un nuevo juego de tablas base en el diccionario de datos, disponibles para el
monitoreo de recursos y para la gestin de los usuarios asignados a estos grupos. En Oracle 9i es posible controlar
numerosos aspectos del procesamiento de una aplicacin utilizando el Administrador de Recursos. Entonces,
utilizando esta herramienta para controlar los recursos utilizados, se le permite al DBA asegurarse que los
miembros de recursos que necesitan una alta prioridad obtendrn la cantidad suficiente de procesamiento de CPU,
memoria, segmentos de deshacer y recursos de sesin, an cuando hayan muchos usuarios operando
concurrentemente.
Esta utilidad tambin permite al DBA cambiar dinmicamente la asignacin de recursos cambiando el plan de
recursos activo de la instancia. Esta funcionalidad le da al DBA la habilidad de tener ms de un plan de recursos y
activar el que ms necesite en ese momento, por ejemplo, cuando se est en horas de trabajo operativo se puede
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica

Pg. 211

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

activar el plan que de ms recursos a los operadores y cuando se est en horario nocturno se puede cambiar el
plan para darle ms recursos a los usuarios que realizan tareas de mantenimiento tareas de backup.
Cabe destacar que Oracle Resource Manager est disponible solamente en la versin Enterprise de Oracle.

Figura 18.1

18.4. METODOS DE ALMACENAMIENTO


El Administrador de Recursos (Resource Manager) utiliza tres componentes para llevar a cabo la tarea en forma
efectiva de asignacin de recursos. Estos componentes son: Los Grupos de Consumidores, Los Planes de Recursos y
los Planes de Directivas.
Grupo de Consumidores de Recursos: es un grupo de usuarios que tienen necesidades similares de acceso a
recursos de la base de datos y que estn gobernados por las mismas reglas de asignacin de recursos. Un usuario
puede ser miembro de varios grupos de recursos, pero slo un grupo puede estar activo a la vez.
Plan de Recursos: es una coleccin de directivas de utilizacin de los recursos que son utilizadas para determinar
como se asignarn los mismos.
Directivas del Plan de Recursos: especifican cmo se asignan los recursos para cada Plan de Recursos.
Los recursos que pueden ser controlados a travs del Administrador de Recursos son:
1) La cantidad de asignacin de CPU a cada usuario que sea miembro del grupo de consumidores.
2) La profundidad de paralelismo permitido para Consultas en Paralelo (Parallel Queries) realizadas por los
usuarios pertenecientes al grupo de consumidores.
3) Cantidad de espacio del segmento de deshacer que un usuario (miembro del grupo de consumidores) tiene
permitido utilizar cuando realiza una transaccin.
4) La cantidad total de sesiones que un usuario miembro de un grupo de consumidores puede tener activa al
mismo tiempo.
5) La cantidad mxima de tiempo que se puede estar con conexin a la base de datos del usuario perteneciente a
un grupo de consumidores.

Figura 18.2

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 212

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

18.5. USO DEL RESOURCE MANAGER


Los recursos de CPU son asignados utilizando un mtodo de nfasis. Los recursos asociados con consultas
paralelas son asignados utilizando el mtodo Absoluto. Ambos mtodos utilizan una escala relativa, considerando
los valores de 1 a 8 para determinar qu prioridad debera asignarse a un usuario en particular que solicit el
recurso. Al utilizar esta escala relativa, el nmero 1 representa la mayor prioridad y 8 la menor. Esta prioridad es
otorgada a cada usuario, en base al grupo de consumicin (junto a su plan de recursos) al que pertenece.
Mtodo de nfasis: utiliza porcentajes que representan la cantidad de recursos de CPU para cada una de las 8
prioridades. Estos porcentajes son asignados a un grupo de consumidores.
Si un nivel de prioridad tiene asignado un porcentaje de CPU, pero slo utiliza una parte de este porcentaje, el
remanente pasar a estar disponible para ser utilizado por el nivel inmediatamente superior. Por ejemplo, si al
nivel 1 se le asigna un uso del 50% del procesador, pero slo utiliza el 20%, entonces el 30% restante pasa a estar
disponible para el nivel 2 y as sucesivamente.
Mtodo Circular: los recursos que se pasan entre grupos de recursos no utilizan el mtodo de nfasis para asignar
recursos de CPU. En lugar de ello, Oracle utiliza un comportamiento Circular. En otras palabras, los recursos de
CPU que son ofrecidos al primer grupo de consumidores, luego al prximo, luego al prximo y as sucesivamente
hasta que se le vuelve a ofrecer al primer grupo. La Figura 18.3 muestra un ejemplo de la utilizacin de la
asignacin de recursos de CPU, donde se crea un grupo de consumidores llamado POWER_USERS y contiene dos
planes de recursos: FUNCTIONAL y TECHNICAL. Estos dos Planes de Recursos pueden asignar prioridad de uso de
CPU para cada uno de los 8 niveles de granularidad. Ntese que el Plan de Recursos TECHNICAL tiene asignado el
100% de CPU en el primer nivel, 50% para el segundo y el tercer nivel, 25% para el cuarto nivel y cero para los
niveles restantes. Esto significa que los usuarios en el Plan de Recursos TECHNICAL podrn utilizar el 100% de
CPU. Si estos usuarios no utilizan todos los recursos de CPU, entonces los usuarios asignados a este grupo de
consumidores utilizarn el CPU remanente de esta manera:
En nivel 2 usa el 50% del CPU remanente del nivel 1
En nivel 3 usa el 50% del CPU remanente del nivel 2
En nivel 4 usa el 25% del CPU remanente del nivel 3
Los niveles 5 a 8 usan el remanente del nivel superior
Las consultas en paralelo (Parallel Queries PQ) son controladas por el Administrador de Recursos a nivel de
Profundidad de Paralelismo. Esto hace referencia a la cantidad de procesos esclavos que una sesin individual
puede iniciar cuando est procesando este tipo de consultas. A medida que se utilicen ms procesos esclavos, ms
rpida ser la consulta, pero este objetivo se cumple a costa de una utilizacin mayor de recursos de CPU y acceso a
disco.
Mtodo Absoluto: Oracle utiliza el este mtodo para controlar los recursos de consultas paralelas. Por ejemplo, si
se decide limitar los recursos de PQ para usuarios que se encuentran en el grupo de consumidores creado en el
ejemplo anterior (POWER_USERS), al igual que con los recursos de CPU, los dos Planes de Recursos, TECHNICAL y
FUNCIONAL, pueden tener prioridad en los 8 niveles de cada plan. La Figura 18.4 muestra conceptualmente cmo
se realiza la asignacin de recursos de PQ. El Plan de Recursos FUNCTIONAL puede utilizar hasta 5 procesos de
paralelizacin cuando realiza tareas de este tipo, si se utilizan menos procesos, entonces los no utilizados se
podrn utilizar en el siguiente nivel, quedando distribuidos:
Se pueden iniciar hasta 5 procesos en el nivel 2 si se utilizan todos los procesos en el nivel 1.
Se pueden iniciar hasta 2 procesos en el nivel 3 si se utilizan todos los procesos en el nivel 2.
Se puede iniciar hasta 1 proceso en los niveles 4 a 8 si se utilizan todos los procesos en el nivel 3.

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 213

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

Figura 18.3

Figura 18.4

18.6. QUOTA DEL TABLESPACE UNDO


Oracle 9i introduce un nuevo Plan de Directivas llamado UNDO_PLAN. Utilizando este Plan de directivas, el DBA
puede controlar la cantidad de espacio del segmento de deshacer (UNDO) que un usuario tiene permitido consumir
cuando ejecuta grandes operaciones DML. Los lmites definidos en el uso del segmento de deshacer se
implementan en forma de cuota de uso. Si la utilizacin de la cuota es excedida, el usuario que se encuentra
realizando la operacin DML que caus este exceso, se encontrar con que esa operacin fue terminada por Oracle.
Adicionalmente, este usuario u otro usuario del grupo no podr realizar otras operaciones DML hasta que alguno
de los miembros del grupo libere recursos.
A travs de un mecanismo llamado Conjunto de Sesiones Activas (Active Session Pool ASP), Oracle 9i permite al
DBA limitar la cantidad de sesiones concurrentes de un grupo particular de recursos. De esta manera, una vez que
los miembros del grupo de recursos alcanzan la cantidad permitida de sesiones concurrentes, cualquier solicitud
de conexin subsiguiente ser encolada por el Administrador de Recursos, en lugar de ser procesada de inmediato.
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica

Pg. 214

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

As, el Conjunto de Sesiones Activas permite garantizar una mnima cantidad de recursos para cada grupo de
recursos, evitando la monopolizacin de los mismos, por un grupo en particular.
Entonces, una sesin encolada por el Administrador de Recursos se ejecutar una vez que una ms de una sesin
existente finalice se vuelva inactiva. Existe slo una cola de solicitudes de conexin por grupo de consumidores
de recursos. El sistema de funcionamiento de las sesiones encoladas se comporta como el Primero que Entra,
Primero que Sale First In, First Out (FIFO).
Si se consulta la vista dinmica de rendimiento V$SESSION y se encuentra un valor distinto de cero en la columna
CURRENT_QUEUE_DURATION, significa que esa sesin se encuentra actualmente encolada por el Administrador de
Recursos. La columna QUEUE_LENGTH de la vista dinmica de rendimiento V$RSRC_CONSUMER_GROUP tambin
contiene informacin til de monitoreo de la cantidad total de sesiones encoladas para un grupo de consumidores
en particular.
Tanto la cantidad mxima de sesiones permitidas u de sesiones encoladas pueden especificarse cuando se crea el
grupo de consumidores. El valor mximo de sesiones es definido utilizando el parmetro ACTIVE_SESS_POOL_P1
del Administrador de Recursos. La cantidad mxima de tiempo (en segundos) que una sesin permanecer
encolada antes que sea cancelada si no tiene respuesta, se define con el parmetro QUEUEING_P1 del
Administrador de Recursos. El valor por defecto para estos dos parmetros es de 1 milln.
Cabe recordar que una sesin es considerada ACTIVA si en ese momento est efectuando alguna transaccin DML,
realizando alguna consulta alguna operacin en paralelo.

Figura 18.5

18.7. TIPOS DE EJECUCION


Utilizando la nueva caracterstica de Oracle 9i para el Plan de Directivas MAX_ESTIMATED_EXEC_TIME, el DBA
puede especificar el tamao mximo de tiempo que una operacin sobre la base de datos puede tardar en
completarse. Una vez definido este parmetro, el Administrador de Recursos utilizar las estadsticas del CBO para
estimar el tiempo de ejecucin para cada una de estas operaciones. Esta estimacin es entonces comparada con la
cantidad mxima de tiempo permitida. Si en la operacin que se desea ejecutar, resulta ms largo el tiempo
estimado de ejecucin que el definido, entonces la operacin no se iniciar.

Figura 18.6
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica


Pg. 215

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

18.8. GRUPOS DE CLIENTES


Para poder utilizar las caractersticas del Administrador de Recursos de Oracle 9i, el DBA debe realizar algunas
tareas de configuracin. Estas operaciones incluyen la otorgacin de privilegios de administracin de recursos a
los usuarios, la creacin de los objetos de administracin de recursos y la asignacin de usuarios a estos objetos de
consumicin.
Los usuarios que van a tener permitido la administracin de los Grupos de Recursos, los Planes y las Directivas,
deben tener el privilegio de ADMINISTER_RESOURCE_MANAGER.
A diferencia de los privilegios tradicionales, los cuales se podan otorgar con la clusula GRANT TO , este
privilegio debe ser otorgado utilizando un paquete PL/SQL provisto por Oracle, llamado
DBMS_RESOURCE_MANAGER_PRIVS. Este paquete requiere tres argumentos: GRANTEE_NAME, PRIVILEGE_NAME
y ADMIN_OPTION. La Figura 1 muestra un ejemplo de ejecucin de este paquete donde se le otorga el privilegio
ADMINISTER_RESOURCE_MANAGER al usuario REGI, con la opcin de que pueda otorgar, a su vez, este privilegio a
otros usuarios. De la misma manera, si se necesita quitar este privilegio a un usuario, se debe utilizar el
procedimiento REVOKE_SYSTEM_PRIVILEGE.
Entonces, una vez que un usuario ha recibido el privilegio ADMINISTER_RESOURCE_MANAGER, podr utilizar el
Administrador de Recursos, y por consiguiente, podr crear objetos del Administrador de Recursos.
Es posible utilizar la vista del diccionario de datos DBA_RSRC_MANAGER_SYSTEM_PRIVS para ver qu usuarios de
la base de datos tienen el privilegio ADMINISTER_RESOURCE_MANAGER.

Figura 18.7

18.9. OBJETOS DEL RESOURCE MANAGER


Para continuar con el proceso de configuracin del Administrador de Recursos, el DBA debe construir los objetos
en la base de datos para el Administrador de Recursos. Este paso incluye:
Creacin de un rea de Pendientes.
Creacin de uno ms Grupos de Consumidores de Recursos.
Creacin de uno ms Planes de Recursos.
Creacin de una ms Directivas del Plan de Recursos.
Validacin de los Grupos de Consumidores de Recursos, Planes y Directivas.
Guardado de los objetos en la base de datos.
Cuando se crea un grupo de consumidores, un plan una directiva, se realiza almacenado temporalmente en el
rea de Pendientes hasta que sea validado y escrito permanentemente en la base de datos.
El propsito del rea de Pendientes es el de darle al DBA una oportunidad de confirmar que la definicin de cada
uno de estos objetos es correcta antes de implementarla en produccin. Esta rea de Pendientes se crea utilizando
el procedimiento CREATE_PENDING_AREA del paquete PL/SQL DBMS_RESOURCE_MANAGER, como se ve en la
Figura 18.8. Cabe destacar que la base de datos slo puede tener un rea de Pendientes.

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 216

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

Figura 18.8

18.10. GESTION DE GRUPOS DE CLIENTES


Un Grupo de Consumidores de Recursos (Resource Consumer Group RCG) es utilizado para definir un grupo de
usuarios de la base de datos que tienen requerimientos de recursos similares. Los Grupos de Consumidores son
similares a los Roles de Oracle, con la diferencia que los Grupos de Consumidores son utilizados para administrar
recursos y los roles son usados para administrar los privilegios de acceso a objetos y recursos del sistema.
Por defecto, cada usuario de la base de datos pertenece al menos a un Grupo de Consumidores, llamado
DEFAULT_CONSUMER_GROUP. Este grupo, junto a otros grupos de consumidores es creado al momento de
creacin de la base de datos. Estos grupos creados por defecto son:
SYS_GROUP. Este grupo tiene la mayor prioridad de acceso a recursos. El usuario SYS y SYSTEM pertenecen a este
Grupo de Consumidores.
LOW_GROUP. Este grupo recibe la menor prioridad para el acceso a los recursos de la base de datos.
DEFULT_CONSUMER_GROUP. Cualquier usuario que no est asignado en forma explcita a algn grupo, se asignar
automticamente a este grupo.
OTHER_GROUPS. Es el grupo en donde todos los usuarios que pertenezcan no sern miembros de un Plan de
Recursos que se encuentra activo en ese momento, en esa instancia.
Si se desea crear un Grupo de Consumidores personalizado, el DBA deber utilizar el procedimiento
CREATE_CONSUMER_GROUP del paquete PL/SQL DBMS_RESOURCE_MANAGER, como se ve en la Figura 18.9
donde se crea el Grupo de Consumidores POWER_USERS junto a un comentario identificatorio. En este momento,
este grupo se crea en el rea de Pendientes creada previamente.
Los Planes de Recursos son utilizados para organizar las Directivas de los Planes. Entonces, un grupo de Directivas
pueden ser asignadas a un Plan de Recursos, el cual puede ser asignado a su vez, a uno ms Grupos de
Consumidores de Recursos. Slo un Plan de Recursos puede estar activo en una instancia.
La Figura 18.10 muestra la creacin de dos Planes de Recursos para el Grupo de Consumidores POWER_USERS.
Uno llamado FUNCTIONAL y otro llamado TECHNICAL. Estos Planes de Recursos tambin se crearn en el rea de
Pendientes hasta que se verifique su creacin y se almacene en forma permanente en la base de datos.
Al igual que los grupos de consumidores, tambin se crean Planes de Recursos en forma automtica al momento de
creacin de la base de datos, llamados SYSTEM_PLAN, INTERNAL_PLAN e INTERNAL_QUIESCE.
Finalmente, una Directiva de Plan es utilizada para vincular un grupo de consumidores de recursos a un Plan de
Recursos. La Directiva de Plan en donde se asignan los recursos gestionados por el Administrador de Recursos. La
Figura 18.11 muestra la creacin de una Directiva de Plan, donde el argumento CPU_P1 es utilizado para
especificar qu porcentaje del total de la disponibilidad de CPU tiene la mayor prioridad del grupo de
consumidores de recursos. Como se ha comentado antes, se pueden definir hasta 8 niveles de prioridades, al igual
que el nivel de paralelismo, con el parmetro PARALLEL_DEGREE_LIMIT_P2. Por ejemplo, CPU_P1 es para el nivel
1 del porcentaje de CPU, CPU_P2 es para el segundo nivel y as sucesivamente hasta CPU_P8. Cada Directiva de Plan
debe incluir una referencia a un grupo de consumidores por defecto (OTHER_GROUPS), como se ve en la
Figura 18.12.

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 217

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

Figura 18.9

Figura 18.10

Figura 18.11

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 218

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

Figura 18.12

18.11. ADMINISTRACION DEL RESOURCE MANAGER


Una vez que se ha creado un Grupo de Consumidores de Recursos, se define un Plan de Recursos y una Directiva
para ese Plan, ese paquete completo debe ser validado antes que sea escrito permanentemente a la base de datos.
La Verificacin de los componentes del Administrador de Recursos se realiza utilizando el procedimiento
VALIDATE_PENDING_AREA del paquete DBMS_RESOURCE_MANAGER:
SQL> EXECUTE dbms_resource_manager.validate_pending_area ();
Si se omite la inclusin de una directiva que apunte al Grupo de Consumidores de Recursos OTHER_GROUPS al
momento de definir las Directivas de los Planes, Oracle dar un error al realizar esta ejecucin, como se ve en la
Figura 18.13. Al momento de la validacin pueden surgir otros errores y se pueden deber a:
Darle a un Grupo de Consumidores de Recursos y a un Plan nombres idnticos.
Tratar de crear ms de 32 Grupos de Consumidores de Recursos sin Plan de Recursos asignado.
Tener una asignacin de CPU que supera el 100% en la sumatoria de cada nivel.
Tratar de eliminar un plan que es el ms activo de la instancia.
Una vez finalizada la validacin de los objetos del Administrador de Recursos que se encuentran en el rea de
Pendientes, queda la confirmacin de los cambios para que se escriban permanentemente en la base de datos y
para que puedan ser utilizados por los usuarios. Esta tarea se realiza con el procedimiento
SUBMIT_PENDING_AREA del paquete DBMS_RESOURCE_MANAGER:
SQL> EXECUTE dbms_resource_manager.submit_pending_area ();
Es posible asignar Grupos de Consumo de Recursos a usuarios de la base de datos al otorgar el propio grupo a un
usuario directamente otorgando este grupo a un rol. Para eso, se debe ejecutar el procedimiento
GRANT_SWITCH_CUSTOMER_GROUP del paquete DBMS_RESOURCE_MANAGER_PRIVS, como se ve en el ejemplo
de la Figura 18.14, se otorgar el grupo de consumo POWER_USERS al usuario BETTY sin el Grant Option.
Como un usuario puede ser miembro de varios grupos de consumidores al mismo tiempo, suele ser una buena
recomendacin especificar un grupo de consumidores por defecto que se encuentre activo para los usuarios que se
conectan a la base de datos. El grupo de consumidores por defecto se asigna con el procedimiento
SET_INITIAL_CONSUMER_GROUP, como se ve en la Figura 18.15. En el paso anterior, el usuario BETTY debera
estar asignado al grupo por defecto POWER_USERS. Si un usuario no es asignado a ningn grupo por defecto, su
grupo de consumidores inicial ser el grupo DEFAULT_CONSUMER_GROUP.
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica

Pg. 219

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

De esta manera, el grupo de consumidores por defecto de un usuario puede ser cambiado dinmicamente
utilizando el procedimiento SWITCH_CURRENT_CONDUMER_GROUP del paquete DBMS_SESSION. Esta es una
caracterstica til que permite a una aplicacin activar y desactivar varios grupos de consumidores de usuarios que
utilizan varios niveles de utilizacin de recursos.

Figura 18.13

Figura 18.14

Figura 18.15

18.12 CAMBIO AUTOMATICO DE GRUPOS


Si un usuario est activo por un perodo de tiempo especificado, el Administrador de Recursos puede ser
configurado para que cambie en forma automtica la sesin de ese usuario a un grupo de consumidores de
recursos secundarios. Esta caracterstica se gestiona especificando tres parmetros de las directivas de plan:
SWITCH_TIME
SWITCH_GROUP
SWITCH_ESTIMATE
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica

Pg. 220

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

El parmetro SWITCH_TIME es utilizado para definir la duracin, en segundos, que una sesin debe estar activa
antes que el Administrador de Recursos cambie esa sesin a un grupo definido por el parmetro SWITCH_GROUP
(El valor por defecto de este ltimo parmetro es NULL). Si el parmetro SWITCH_ESTIMATE, para el cual el valor
por defecto es FALSE, es definido en TRUE, entonces el Administrador de Recursos utilizar el tiempo estimado
para decidir cundo asignar esa sesin al SWITCH_GROUP.
Recursos de la Instancia.
Cualquiera de los planes pueden ser activados para una instancia pero slo uno de estos planes puede estar activo
por vez. Este plan activo puede definirse con el parmetro de inicio RESOURCE_MANAGER_PLAN. Si este
parmetro no es definido, entonces el Administrador de Recursos estar deshabilitado.

Figura 18.16

18.13

EJERCICIO DE REPASO: GRUPOS DE CONSUMIDORES

El DBA est configurando el Administrador de Recursos y cre un grupo de consumidores NOCTURNO. Identificar
el comando para asignar, al usuario SCOTT este grupo de consumidores, sabiendo que adems SCOTT debe poder
otorgar a su vez este privilegio a otros usuarios.

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 221

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

18.14 EJERCICIO INTEGRADOR: UTILIZACION DEL ADMINISTRADOR DE RECURSOS


El ejercicio siguiente permitir comprobar los conocimientos adquiridos en la presente unidad:

18.15. SINTESIS
Tanto la instancia como la base de datos Oracle residen en servidores. Estos servidores tienen una cantidad
limitada de CPU, memoria y recursos de disco. Los DBAs deberan estar familiarizados con las utilidades
disponibles para el monitoreo de estos recursos. Cualquier esfuerzo de ajuste de la base de datos incluye examinar
los recursos del sistema operativo.
El Administrador de Recursos de Oracle es utilizado para asignar recursos de CPU y consultas paralelas a usuarios
de la base de datos.
Las directivas del plan de recursos son utilizadas cuando se utiliza asignaciones de CPU y nivel de paralelismo a
travs del paquete PL/SQL DBMS_RESOURCE_MANAGER.
Una vez que las directivas son definidas, stas son asignadas a planes de recursos, los cuales son asignados a su vez
a grupos de consumidores que son otorgados a usuarios u otros roles de la base de datos.
El Plan de recursos para la instancia puede ser definido por el parmetro de inicio RESOURCE_MANAGER_PLAN
utilizando el comando ALTER SYSTEM para modificar este valor en forma dinmica.

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 222

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIDAD 19
TUNING DEL SISTEMA OPERATIVO

19.1. OBJETIVOS
En esta unidad el objetivo es que el alumno pueda describir las diferentes arquitecturas de un sistema operativo, y
que sepa ejecutar el proceso de ajuste del mismo.
Tambin es objetivo que el alumno sea capaz de identificar similitudes entre el ajuste para distintos SO.
Por ltimo el alumno deber comprender los conceptos de memoria virtual y de paginacin; y diferenciar entre un
proceso y un hilo (thread).

19.2. CUESTIONARIO DE INICIACION

19.3. ARQUITECTURA DEL SISTEMA


Existen tres recursos principales de servidor que impactan al rendimiento de la base de datos Oracle:
Memoria
Acceso a Disco
CPU
Por lo general, este es el orden en el cual los recursos del sistema operativo servidor deberan ser ajustados. En
este captulo veremos en las consideraciones de ajuste relacionadas a la memoria y CPU.

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 223

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

Figura 19.1

19.4. MEMORIA
Cuando se inicia una instancia, la SGA y todos los procesos en segundo plano son creados en la memoria principal
del servidor. Esta rea de memoria es utilizada no slo para la SGA y los procesos en segundo plano, sino que
tambin es usada por el sistema operativo y cualquier otro proceso que pudiese estar corriendo en el servidor.
Estos son algunos procesos que no son Oracle y consumen recursos del servidor:
Cdigo Kernel de Unix Windows: cada sistema operativo carga sus ejecutables esenciales en memoria al inicio
booteo. Estos ejecutables llamados Kernel, son utilizados para administrar las funciones de acceso a memoria y
dispositivos del propio sistema operativo. En sistemas UNIX, los componentes del Kernel son ajustables por los
administradores del sistemas al igual que se podra hacer con Oracle, esto es, utilizando parmetros de inicio. La
tabla de la Figura 1 muestra algunos de los parmetros ms importantes de inicio del Kernel UNIX.
Servidores de Aplicacin Web: algunos servidores de base de datos incluyen servicios de aplicacin y/o web
para soportar la capa de la lgica de negocios. Estos procesos tienen su propio consumo de recursos en forma
adicional a la misma base de datos.
Agentes de Software: son procesos similares al Agente Inteligente (Intelligent Agent de la consola OEM). Varias
aplicaciones empresariales, monitoreos de red y sistemas de backup utilizan el protocolo de red SNMP que son
agentes para comunicarse entre algn software remoto que controla y el servidor.
Aplicaciones: algunos servidores ocasionalmente tienen paquetes de aplicaciones instalados sobre el mismo
servidor, como ser un paquete de programas de oficina para ser utilizados va red.

Figura 19.2

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 224

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

19.5. PAGINADO E INTERCAMBIO


Cada servidor tiene dos tipos de memoria para almacenar los componentes del kernel del sistema operativo y las
estructuras de memoria, junto a los procesos en segundo plano. El primero de estos tipos de memoria es la
Memoria Fsica, que es representada por la cantidad de memoria que fsicamente tiene el servidor almacenado en
chips electrnicos. Esta memoria se divide en pequeas piezas llamadas Pginas. Esta estructura se asemeja a las
extensiones de Oracle que se almacenan en los tablespaces. La asignacin de procesos y datos a las pginas de
memoria se gestiona a travs de un mecanismo del sistema operativo llamado Tabla de Pginas. Si las pginas de la
memoria fsica se llenan, el sistema operativo del servidor tiene que eliminar, en forma temporal, pginas
procesos de la memoria principal para poder hacer lugar para otros requerimientos de otros procesos datos. Este
proceso se llama Paginado (paging) intercambio (swapping).
La tabla de la Figura 19.3 muestra una comparacin entre el paginado y el intercambio.
Cuando ocurre un paginado intercambio, se utiliza otro tipo de memoria para almacenar los procesos pginas
en disco. Este tipo de memoria se llama Memoria Virtual. Al igual que el ajuste de Oracle, la principal meta del
ajuste del sistema operativo es maximizar la frecuencia con la que las pginas de memoria solicitadas se almacenan
directamente en memoria (caching) para que no tenga que ser ledo del disco (o sea, ledo de la memoria virtual).

Figura 19.3

19.6. TUNING DE MEMORIA E I/O


Las tcnicas utilizadas para monitorear la paginacin y el intercambio, varan en funcin del sistema operativo que
se est implementando. La tabla de la Figura 1 muestra algunos ejemplos de comandos UNIX que pueden ser
usados para el monitoreo de estas operaciones de memoria del servidor. Para ms informacin sobre la utilizacin
de estos comandos, ver las ayuda del comando man para cada uno de estos comandos
Los sistemas Windows 2000 utilizan solamente la paginacin para la gestin de memoria. Su sistema operativo no
soporta el intercambio swapping.
Debido a que la lectura de la memoria virtual (en disco) es varias veces ms lenta que de la memoria fsica, la
excesiva paginacin intercambio pueden causar problemas de rendimiento hasta para la base de datos. Hay
varias tcnicas disponibles para ajustar la memoria del servidor relacionada con la SGA de Oracle. Estas tcnicas
son:
SGA LOCKING: definiendo el parmetro de inicio LOC_SGA=TRUE causar que el sistemas operativo no pueda
realizar un paginado intercambio de ninguna porcin de la SGA en la memoria fsica. De esta forma se logra que
la totalidad de la SGA se encuentre siempre en esta rea de memoria. Esto hay que hacerlo con cuidado ya que el
servidor debe tener memoria suficiente para poder convivir con el resto de los programas. El valor por defecto de
este parmetro es FALSE. Cabe destacar que la utilizacin de este parmetro no est disponible para Windows
2000.
INTIMATE SHARED MEMORY: los servidores de base de datos que corren sobre sistemas Sun Solaris pueden
hacer uso de la caracterstica Intimate Shared Memory ISM para ayudar al ajuste del sistema operativo de las
actividades de paginacin e intercambio. Al habilitar esta caracterstica, mltiples procesos del sistema operativo
compartirn el acceso a la memoria a travs de la tabla de pginas.

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 225

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

Figura 19.4

19.7. LLAMADAS AL SISTEMA OPERATIVO


El CPU del servidor es el encargado de realizar todo el procesamiento que ocurre en el propio servidor. Si un
servidor tiene varios CPU (procesadores), entonces las tareas de procesamiento se comparten entre todos los
procesadores que lo tengan. La cantidad de procesadores disponibles determina el tipo de arquitectura en que el
sistema est basado. La tabla de la Figura 19.5 describe cinco configuraciones (arquitectura) comunes de
servidores, segn la distribucin de sus procesadores.
Oracle tiene varias versiones del producto de base de datos adaptado para distintas opciones de sistemas de
servidores. Si se agregan nuevas CPU al servidor donde reside la base de datos, Oracle cambiar dinmicamente las
definiciones de los parmetros relacionados con la CPU. Algunos de estos parmetros se muestran en la tabla de la
Figura 19.6.

Figura 19.5

Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 226

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

Figura 19.6

19.8. PROCESOS vs: THREAD (HILOS DE EJECUCION


Muy relacionado con la utilizacin del CPU es el concepto de administracin de Procesos e Hilos de Oracle. Tanto
en los sistemas operativos Unix como Windows, el comportamiento de estos sistemas operativos se diferencia en
cmo son creados estos procesos hilos.
En sistemas Unix, cada proceso relacionado a Oracle (PMON, SMON, DBW0, sqlplus, etc) corren sobre el sistema
operativo en un proceso separado e independiente. Cada uno de estos procesos tiene su propio consumo de
memoria y CPU.
Para los sistemas operativos Windows. Cada proceso relacionado a Oracle corre en un hilo separado perteneciente
a un solo proceso del sistema operativo llamado Oracle.exe. Un hilo thread es una secuencia independiente de
instrucciones que se ejecutan para un solo proceso del sistema operativo. Por lo tanto, un proceso puede tener
mltiples hilos threads.
Una ventaja de los hilos es la velocidad de comunicacin entre el hilo y el proceso. Esta comunicacin es mucho
ms veloz en comparacin a la comunicacin entre dos procesos independientes de Oracle.

Figura 19.7
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica


Pg. 227

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

19.9. PARALELISMO
Mientras que cualquier servidor de base de datos usualmente se beneficiar de la presencia de CPUs adicionales,
las mejoras de rendimiento sern ms dramticas en ejecuciones en paralelo de Oracle. Algunos ejemplos de
ejecuciones en paralelo de Oracle incluyen Consultas en Paralelo, DML Paralelo, ANALYZE Paralelo y Creacin de
ndices en Paralelo.
Consultas Paralelas Parallel Query PQ. Cuando se configura esta caracterstica, Oracle permite que una consulta
SQL se divida entre muchos procesos esclavos. Cada uno de estos procesos trabaja sobre una porcin de la consulta
y luego los resultados individuales son combinados en el resultado final. La cantidad de consultas esclavas en que
puede dividirse la consulta principal est relacionada con la cantidad de procesadores del servidor.
DML en paralelo. Algunas operaciones DML (Insert, Update, Delete) pueden ser ejecutadas en paralelo utilizando la
funcionalidad de Consultas en Paralelo de Oracle (Oracle Parallel DML PDML). Algunos ejemplos de PDML
incluyen el comando CREATE TABLE AS SELECT junto a la utilizacin de la sugerencia (HINT) /*+PARALLEL */.
Comando ANALYZE en Paralelo. Las estadsticas que se tomen de grandes tablas pueden ser colectadas en paralelo
si se utiliza el paquete provisto por Oracle DMBS_STATS.
Creacin del ndice en paralelo. Los ndices que son creados en grandes tablas pueden ser creadas tambin en
paralelo si se especifica la opcin PARALLEL en el comando CREATE INDEX. Al hacer esto, Oracle iniciar procesos
mltiples que trabajarn en conjunto para crear el ndice mucho ms rpido que si se hubiese construido con un
solo proceso.
El ajuste de CPU debera comenzar con el monitoreo de la utilizacin del propio CPU. Se podra utilizar el comando
top de Unix para este tipo de monitoreo el monitor de rendimiento de ambientes Microsoft.

Figura 19.8

19.10 EJERCICIO DE REPASO: MANEJO DE MEMORIA


Identificar si las afirmaciones sobre la paginacin y el intercambio de memoria son verdaderas.


Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica

Pg. 228

UNIVERSIDAD NACIONAL DE JUJUY


FACULTAD DE INGENIERIA

ANALISTA PROGRAMADOR UNIVERSITARIO


Ctedra: Herramientas Informticas Avanzadas

19.11 EJERCICIO INTEGRADOR: TUNIG DEL SISTEMA OPERATIVO


El ejercicio siguiente permitir comprobar los conocimientos adquiridos en la presente unidad:

19.12. SINTESIS
Las bases de datos de Oracle residen en instancias en los servidores. Estos servidores tienen una cantidad limitada
de memoria, CPU y disco. Los DBA debern estar familiarizados con las utilizadas que brinda Oracle para
monitorear el sistema operativo. Cualquier esfuerzo de ajuste de la base de datos debera incluir un examen de la
asignacin de este tipo de recursos junto a los cambios necesarios para su ajuste.
El Administrador de Recursos de Oracle es utilizado para esta asignacin de CPU y recursos en paralelo. Las
directivas de los planes de recursos son aquellas que utilizan la asignacin actual de estos recursos, junto al nivel
de paralelismo. Una vez que se han definido las directivas, stas son asignadas a planes de recursos, los cuales son
asignados a grupos de consumidores que a su vez son asignados a usuarios roles de la base de datos.
El plan de recursos para una instancia puede ser definido a travs del parmetro de inicio
RESOURCE_MANAGER_PLAN con el comando ALTER SYSTEM para hacer esta tarea en forma dinmica.


Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori


Ayudante de 1: Lic. Claudia Panica

Pg. 229

You might also like