Rendimiento en el motor Oracle | Road to OCA & OCP

1 de 5

https://oraclehelper.wordpress.com/2010/03/19/rendimiento-en-el-mot...

Rendimiento en el motor Oracle

El uso de la memoria es un factor fundamental para el rendimiento de la instancia, no debe ser muy
pequea pero tampoco muy grande.
Igualmente, es crtico para el rendimiento de la instancia el estado de los objetos (Segmentos y
PL/SQL).
AUTOMATIC MEMORY MANAGEMENT
Existen dos sabores de memoria Oracle, la PGA que es privada para la sesin y la SGA que es
compartida para todos los procesos.
En 9i fue posible implementar un manejo automtico de la PGA
En 10g fue posible implementar el manejo automtico de la SGA.
En 11g podemos dar manejo automtico a las dos areas de memoria
Toda la memoria que Oracle utiliza es memoria virtual, Oracle no podr saber si la memoria que esta
utilizando es RAM o es SWAP (Paginada), la paginacin debe ser evitada puesto que degrada
considerablemente el rendimiento.
Cuando un server process se instancia, hace uso de la PGA, para almacenar informacin como:
Tablas temporales
Ordenamientos de registros
Merging Bitmaps
Variables
Call Stack
Alguna informacin de la PGA indiscutiblemte deber hacerse en memoria, pero para otras
estructuras, tales como las tablas temporales, Oracle podr hacer uso del almacenamiento en disco,
sin embargo, esto degradara el rendimiento de nuestros procesos.
Cada sentencia SQL que se ejecute dentro del motor, necesitara SGA (Shared Pool) y una minima
cantidad de PGA. Sin estas, oracle no podr ejecutar la sentencia.
Tipicamente, existen tres etapas para la asignacin de memoria:
Optimal: Es aquella donde Oracle puede ejecutar todo el proceso en memoria sin tener que acudir
a segmentos temporales en el disco. (Input data & Auxiliary Data en memoria)
One-pass: Es cuando la memoria es insuciente para la ejecucin optima en memoria.
Multipass: Es el evento menos eciente, es cuando tiene la menor cantidad de memoria. Y tiene
29/08/2015 11:37
que hacer uso intensivo de los segmentos temporales en disco.

Rendimiento en el motor Oracle | Road to OCA & OCP

https://oraclehelper.wordpress.com/2010/03/19/rendimiento-en-el-mot...

One-pass: Es cuando la memoria es insuciente para la ejecucin optima en memoria.

Multipass: Es el evento menos eciente, es cuando tiene la menor cantidad de memoria. Y tiene
que hacer uso intensivo de los segmentos temporales en disco.
Comentar Ejemplo, Ultimo prrafo pagina 3.
Conceptos: Shared SQL Area (SGA-Shared Pool), Private SQL Area(PGA)
El escenario ideal es que todas las sentencias encajen dentro de la categora OPTIMAL, sin embargo,
esto es casi imposible, en DWH, debido al tamao de las tablas, se requerira de Gigabytes de
memoria. Por lo tanto, en muchos ambientes llegar al escenario de one-pass ser lo mejor que se
pueda conseguir.
Multipass deber ser prevenido si es posible.
Oracle recomienda utilizar la administracin automtica de la PGA, la denicin ja para esta area,
esta disponible solo por backward compatibility.
Con la administracin automtica de la PGA, Oracle reparte memoria por demanda, oracle espera
que en solo una sesin requiera memoria no negociable al mismo tiempo (Sorts..etc). Cada sesin
requerir una cantidad mnima para almacenar lo el estado de la sesin, el resto ser pasada a las
otras sesiones, de tal forma que cada sesin obtenga la memoria que necesite. Al menos esa es la
esperanza.
One-pass: No es bueno, pero es inevitable.
Multipass: Terrible, desatroso, apague y vmonos, toca llorar por hardware ante el administrador del
sistema, o obligar a los desarrolladores a otimizar (alivianar) los SQL.
WORKAREA_SIZE_POLICY, por default estara setiado en AUTO, lo cual implica que oracle
repartira memoria por demanda a las sesiones, la cantidad de memoria con la que oracle cuenta para
repartir, es la especicada en el parametro PGA_AGGREGATE_TARGET.
Este ultimo parmetro, por lo general deber ser mayor a 10MB y se recomienda este en un tamao
correspondiente al 20% del tamao del SGA. Lo cual no es camisa de fuerza, igual hay que
monitorear y ajustar.
SGA MEMORY MANAGEMENT
La SGA contiene muchas estructuras de memoria, las cuales pueden ser dimensionadas
independientemente, estas son:
Shared Pool
Database Buer Cache
Large pool
Streams Pool
Java Pool
Log Buer
Como regla general, la asignacin del tamao de las estructuras de memoria correspondientes al
large pool, java pool y streams pool no estan sujetas a negociacin, bien sea que ma memoria es
necesitada o no. Si estas estructuras estan muy pequeas entonces habr error. Si estan sobre
dimensinada, pues estaremos desperdiciando memoria, ya que no tendremos benecio de
rendimiento.
El tamao del shared pool, database buer cache y log buer si es negociable, si el tamao es menor
el
2 de 5 al necesitado, no habr error, pero si se degradara el rendimiento del sistema. Sin embargo, con
29/08/2015
11:37

Rendimiento en el motor Oracle | Road to OCA & OCP

https://oraclehelper.wordpress.com/2010/03/19/rendimiento-en-el-mot...

El tamao del shared pool, database buer cache y log buer si es negociable, si el tamao es menor
al necesitado, no habr error, pero si se degradara el rendimiento del sistema. Sin embargo, con el
shared pool especcamente, si esta sub-dimensionado podemos tener errores.
No se deben asignar tamaos gigantescos a estas estructuras de memoria, ya que podra estar
implicndonos hacer swaping. Lo cual daara el rendimiento de la base de datos.
El log Buer no es auto ajustable, es decir, su tamao no esta sujeto a negociacin. El tamao del log
buer es determinado de manera ja al iniciar la instancia y no es auto administrable.
Los parmetros para implementar una administracin manual de las estructuras de memoria son:
SHARED_POOL_SIZE
DB_CACHE_SIZE
LARGE_POOL_SIZE
STREAMS_POOL_SIZE
JAVA_POOL_SIZE
Para habilitar la administracin automtica de la memoria, se deben dejar estasvalores en el defecto,
o en Cero (0) y denir el parmetro SGA_TARGET. Dentro de el valor de esta parmetro debe estar
el tamao que se asignara el LOG_BUFFER, el cual ser jo y no autoadministrable.
AUTOMATIC MEMORY MANAGEMENT
La administracin automtica de la memoria le permite administrar la memoria como un todo, esto
se logra deniendo el parmetro MEMORY_TARGET. Este toma la administracin automtica de la
PGA habilitada por el parametro PAG_AGGREGATE_TARGET y tambin la administracin
automtica de la SGA habilitada por el parmetro SGA_TARGET.
AMM no es solo una herramienta para administrar, realmente entrega grandes benecios de
rendimiento a los motores. Esto debido las conguraciones estticas no se adaptan de la manera
eciente a las demandas de procesamiento que se presentan en los diferentes momentos de lo
operacin del negocio.
Tipicamente la transaccionalidad no necesitara mucha PGA, pero si Database Buer Cache, en
cambio, el procesamiento de consultas SQL si requerir de bastante PGA pero no tanto buer cache.
Por supuesto toda esta administracin de memoria se hace dentro de las restricciones de tamaos
denidas por los parmetros mencionados anteriormente.
Es importante tener en cuenta que el tamao correspondiente al LOG_BUFFER es estatico. No puede
ser auto administrado, y su tamaa ser restado del parmetro que me dene el total del SGA.
El parmetro MEMORY_TARGET es dinamico, y puede ser ajustado sin bajar la instancia, pero
siempre el valor de este parmetro deber estar dentro del limite impuesto por otro parmetro, este
es: MEMORY_MAX_TARGET. Este ltimo, si es esttico.
Hacer el ejercicio de la pgina 7 con mucha atencin
USE MEMORY ADVISORS
Recordar el proceso de MMON y el AWR. Los advisors son herramientas que calculan y proyectan el
efecto de cambiar los tamaos de las estructuras de memoria (SGA y PGA). El uso de AMM facilita el
travs 11:37
3 de 5 uso de los Advisor para tomar decisiones sobre las asignaciones de memoria. Se pueden ver a 29/08/2015

Rendimiento en el motor Oracle | Road to OCA & OCP

https://oraclehelper.wordpress.com/2010/03/19/rendimiento-en-el-mot...

Recordar el proceso de MMON y el AWR. Los advisors son herramientas que calculan y proyectan el
efecto de cambiar los tamaos de las estructuras de memoria (SGA y PGA). El uso de AMM facilita el
uso de los Advisor para tomar decisiones sobre las asignaciones de memoria. Se pueden ver a travs
del EM.
Pagina 9, se muestran querys, revisar los textos que hacen las descripciones en el documento de
Oracle.
Los Advisors no estarn habilitados si las estadsticas no estn habilitadas en modo TYPICAL o ALL.
Solucionando problemas con los objetos Invlidos
Idealmente, en una base de datos todos los objetos deben estar en estado valido, dependiendo de la
cusa del estado invalido, este puede pasar a estado valido la prxima vez que se utilice.
Los ndices invlidos se pasan a validos reconstruyndolos, esto no es un proceso automatico.
Los objetos que pueden estar invlidos son: Procedimientos, funciones, triggers, paquetes, objetos y
vistas.
Cuando se compilan, se verican las dependencias del objeto con otros, incluso bajando al nivel de
columna.
La instruccin para compilarlos es alter object_type objet_name compile;
Existe una vista en la cual podemos observar las dependencias de un objeto. Esta vista es
DBA_DEPENDENCIES.
Oracle nos provee un utilirario para la recompilacion de los objetos de manera masiva, dicho
utilitario se encuentra en $ORACLE_HOME/rdbms/admin/utlrp, este script debe ser ejecutado como
sysdba.
Indices Inutilizables
A diferencia de los otros objetos que se invalidan y que oracle auto recompila cada vez que se
acceden, lo ndices que se hace inutilizables deben ser reparados explcitamente por el DBA.
Una de las razones mas comunes para que le pase esto a un ndice, es cuando se mueve una tabla.
Esto ya que los rowids quedan sirviendo para nada.
Antes de 10g, la forma de detectar un ndice inutilizable era a travs del error que nos arrojaba la
ejecucin de la sentencia sql. Despues de Oracle 10g, cuando esto sucede, es decir cuando se intenta
acceder una tabla que tiene un ndice inutilizable, el optimizador genera un nuevo plan de ejecucin
el cual no utiliza ndices, de tal forma, que las consultas sern siempre satisfactorias.
El parmetro que determina este comportamiento es SKIP_UNUSABLE_INDEX, el cual por defecto
esta denido en TRUE.
ATENCION: La excepcin para este comportamiento es cuando el ndice es necesario para forzar un
constraint, por ej, uno primary key. En este caso, la tabla ser bloqueda para DMLs.
Si se quiere operar como en versiones anteriores a Oracle 10g, se debe congurar el parmetro
SKIP_UNUSABLE_INDEXES=FALSE.
Nota: Cuando un ndice se esta reconstruyendo, se requiere espacio de almacenamiento adicional.
La instruccin REBUILD permite ser usada con NOLOGGING, TABLESPACE, NOLOGGING, por
defecto el ndice ser reconstruido en el tablespace actual, pero se puede mover a travs del uso
de la
4 de 5
29/08/2015 11:37

Rendimiento en el motor Oracle | Road to OCA & OCP

5 de 5

https://oraclehelper.wordpress.com/2010/03/19/rendimiento-en-el-mot...

La instruccin REBUILD permite ser usada con NOLOGGING, TABLESPACE, NOLOGGING, por
defecto el ndice ser reconstruido en el tablespace actual, pero se puede mover a travs del uso de la
instruccin TABLESPACE.
IMPORTANTE: Durante la reconstruccin del ndice, la tabla ser bloqueada para las DMLs.
Con NOLOGGING se indica que la creacin del ndice no genere REDO LOG, pero con esto, se debe
respaldar el tablespace inmediatamente, de tal forma que el tablespace pueda ser restaurado a travs
de RMAN, de lo contrario el tablespace no quedara respaldado. Sin embargo, el no usar
NOLOGGING, hara que la reconstruccin del ndice sea ms rpida.
Los ndices siempre tienden a volverse lentos, principalmente si se hace muchos deletes y updates
sobre las columnas indexadas

Posted in Administracion

Categories
Administracion
Arquitectura
Backup y recuperacion
Desempeo
PL/SQL
Seguridad

29/08/2015 11:37