Professional Documents
Culture Documents
DE JUJUY
FACULTAD DE INGENIERIA
Profesor Adjunto:
Ayudante de 1:
PARTE VI
SISTEMA OPERATIVO Y CONCURRENCIA
16.
Vistas Materializadas
17.
18.
19.
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)
Pg. 192
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.
Pg. 193
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
Pg. 194
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
Pg. 195
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
Figura 16.4
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica
Pg. 196
Figura 16.5
Figura 16.6
Pg. 197
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
Pg. 198
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica
Pg. 199
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.
Pg. 200
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.
Pg. 201
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
Pg. 202
Figura 17.2
Pg. 203
Figura 17.3
Figura 14.4
Pg. 204
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
Figura 14.7
Figura 14.8
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica
Pg. 206
Figura 14.9
Figura 14.10
Pg. 207
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
Pg. 208
Figura 14.12
Pg. 209
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.
Pg. 210
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.
Pg. 211
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
Figura 18.2
Pg. 212
Pg. 213
Figura 18.3
Figura 18.4
Pg. 214
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
Figura 18.6
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica
Pg. 215
Figura 18.7
Pg. 216
Figura 18.8
Pg. 217
Figura 18.9
Figura 18.10
Figura 18.11
Pg. 218
Figura 18.12
Pg. 219
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
Pg. 220
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
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.
Pg. 221
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.
Pg. 222
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).
Pg. 223
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
Pg. 224
Figura 19.3
Pg. 225
Figura 19.4
Figura 19.5
Pg. 226
Figura 19.6
Figura 19.7
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica
Pg. 227
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
Profesor Adjunto: Ms. Ing. Hctor Pedro Liberatori
Ayudante de 1: Lic. Claudia Panica
Pg. 228
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.
Pg. 229