Administración de Oracle11g
PRACTICA 1
Comprobar la asignación de variables de entorno necesarias para
conectarnos a la BD.
Se trata de las variables $ORACLE_HOME, $ORACLE_SID, $LD_LIBRARY_PATH y $PATH.
ORACLE_HOME define en qué directorio está instalado Oracle.
ORACLE_SID determina con qué instancia queremos trabajar.
LD_LIBRARY_PATH permite que Oracle localice las librerías compartidas que no forman parte
del núcleo.
PATH debe incluir el directorio con los ejecutables de Oracle, para mayor comodidad del
administrador.
Solución:
Echo $ORACLE_HOME
Echo $ORACLE_SID
Echo $LD_LIBRARY_PATH
Identificar los procesos que componen instancia.
Lo podemos hacer consultando la vista dinámica V$PROCESS
Ver el tamaño de la SGA de la BD y las cachés que la componen.
Hay varias vistas dinámicas de la BD que nos dan información sobre el tamaño y la estructura
de la SGA: V$SGAINFO, V$SGA_DYNAMIC_COMPONENTS, V$SGA_TARGET_ADVICE,
V$SGA y V$SGASTAT.
Comprobar valores de parámetros del init relacionados con el tamaño de la
SGA.
Los parámetros de inicialización más importantes que afectan al tamaño de la SGA son:
shared_pool_size, db_cache_size, db_block_size, log_buffer, large_pool_size y java_pool_size.
Con Oracle 11g se introduce sga_target para que, automáticamente, se ajuste el tamaño de las
cachés que componen la SGA, nunca por encima de sga_max_size. Por tanto, con 11g,
1
Administración de Oracle11g
bastaría asignar sga_target, sga_max_size y log_buffer (y los demás a cero, aunque en la
práctica lo mejor es asignarles un valor mínimo).
Comprobar ficheros que componen la BD y ubicarlos en la estructura OFA.
Accederemos a la información de los ficheros de control desde la propia BD, consultando las
vistas dinámicas V$DATAFILE, V$TEMPFILE, V$CONTROLFILE y V$LOGFILE:
Identificar la estructura lógica de la BD: tablespaces, segmentos,
extensiones.
En el Diccionario de Datos (DD) de la BD tenemos vistas para comprobar la estructura lógica
de la BD: DBA_TABLESPACES, DBA_DATA_FILES, DBA_SEGMENTS y DBA_EXTENTS.
Consultar información sobre la base de datos (v$database) y la instancia
(v$instance).
Podemos obtener información de la base de datos y de la instancia, de las vistas
V$DATABASE y V$INSTANCE, respectivamente.
Localizar el proceso “servidor” asociado a mi sesión (v$process y
v$session). ¿Es un servidor dedicado o compartido?
Toda sesión contra la BD tiene dos procesos asociados: cliente y servidor. En el cliente
tenemos el proceso de usuario que inicia la sesión y en el servidor de base de datos tendremos
el proceso que sirve las peticiones de dicha sesión; que puede ser un servidor dedicado o
compartido. En las vistas V$SESSION y V$PROCESS tenemos toda la información relativa a
sesiones y procesos, respectivamente.
¿Cuanto ocupa la Dictionary cache y la Library cache en tu BD? (v$sgastat)
En la vista V$SGASTAT hay información detallada sobre las partes de la SGA.
Ver la actividad de la Library Cache (v$librarycache).
En la vista V$LIBRARYCACHE podemos ver los ratios de eficiencia de la Library Cache, en
“tantos por uno”. El objetivo es q se aproximen los más posible a 1, de lo contrario es posible
que haya que aumentar el tamaño de la Shared Pool.
Ver las sentencias SQL que guarda la Shared-Pool (v$sqlarea).
2
Administración de Oracle11g
En la vista V$SQLAREA podemos ver el contenido del “área SQL” de la sharedpool, así como
información útil para el ajuste de cada una de las sentencias sql (Shared Pool consumida, nº de
veces q se ha ejecutado, nº de veces q se ha salido de la caché, lecturas físicas, tiempo de
CPU, tiempo total incluyendo compilación, etc).
Comprobar el funcionamiento de la caché de redolog, como protectora del contenido de
la caché de datos. Para ello iniciaremos una transacción y provocaremos una caída de la
BD, comprobando que al arrancarla de nuevo, se mantendrá la integridad de la misma.
• Crear la tabla BORRAME del usuario SCOTT.
• Insertar una fila sin hacer commit y forzar la caída de la BD.
• Arrancar de nuevo la BD y comprobar que la fila insertada no está (pues no se hizo commit).
• Repetir la inserción de la fila, esta vez haciendo commit; y forzar la caída de la BD otra vez.
• Arrancar la BD una vez más y comprobar que ahora la fila si está (ya que se validó la
transacción con commit).
Comprobar el funcionamiento de la caché de datos, en lo que se refiere a la mejora del
rendimiento cuando se repite una consulta. ¿Por qué la segunda vez que se lanza la
misma consulta tarda menos?
• Activar la medición de tiempos en sqlplus con SET TIMING ON.
• Lanzar la consulta SELECT COUNT(*) FROM DBA_SOURCE.
• Volver a lanzar la misma consulta.
• Comprobar que la segunda ejecución tarda mucho menos, ya que los datos ya se cargaron
en la caché de datos al lanzarla la primera vez; y por tanto se acceden directamente en
memoria y no en disco.
