CursoDBA10g2 Parte1

Administración de Oracle 10g (Parte 2)
Este documento electrónico puede ser descargado libre y Francisco Fernández Martínez (pacof@um.es)
gratuitamente desde Internet para su ejecución e
impresión, sólo para fines educativos y/o personales, Juan Luis Serradilla Amarilla (juanlu@um.es)
respetando su integridad y manteniendo los créditos de
los autores en el pie de página.
Queda por tanto prohibida su venta.
Universidad de Murcia
Administración de Oracle 10g (Parte 2)
© Juan Luis Serradilla Amarilla y Francisco Fernández Martínez 2004 – 2007
TEMARIO
• Instalación de Oracle10g.
• Diseño y creación de una base de datos.
• Estructuras de almacenamiento (bloque, fila, segmento).
• Nuevas funcionalidades de monitorización y ajuste de Oracle 10g.
• Monitorización y ajuste tradicional de Oracle en versiones anteriores.
• Oracle Net.
• MTS.
• Configuración del archivado.
• Backup.
• Recovery.
Administración de Oracle 10g (Parte 2) 2
© Juan Luis Serradilla Amarilla y Francisco Fernández Martínez 2004 2007
OBJETIVOS
• Saber instalar Oracle10g (servidor y BD) sobre Linux.
• Diseñar (memoria, CPU y disco) y crear una base de datos.
• Conocer el formato del bloque oracle, estructura de la fila, tipos de segmentos
y tipos de índices (Btree vs IOT).
• Conocer la nueva infraestructura, así como las nuevas herramientas de
monitorización y ajuste de Oracle 10g.
• Conocer la infraestructura tradicional de Oracle para el ajuste y la
monitorización: vistas dinámicas de rendimiento, ajuste de sharedpool, buffer
cache, redo log, rollback, temporal (sort), checkpoints, sql, cpu.
• Configurar el software de red (Oracle Net) en el servidor y en el cliente.
• Saber activar y configurar MTS.
• Configurar el archivado de una BD Oracle10g.
• Conocer las cuestiones avanzadas del backup de una BD.
• Conocer las cuestiones avanzadas del recovery de una BD.
TEMA 1
INSTALACIÓN DE ORACLE10g
TEMA 1.
INSTALACIÓN DE ORACLE10g
• Esquema del proceso de instalación.
• Tipos de Bases de Datos.
• Asistentes de Configuración.
• Requerimientos HW y SW.
• Parámetros del Kernel LINUX. Ejemplo con FC3.
• Paquetes necesarios. Ejemplo con FC3.
• Preinstalación.
• Instalación.
• Postinstalación.
• Revisión de seguridad y comprobación final.
ESQUEMA DEL PROCESO DE
INSTALACIÓN
• Descargar SW de Oracle:
http://www.oracle.com/technology/software/products/database/oracle10g/index.html
• Manual de instalación (primero ver “Release Notes”):
http://www.oracle.com/pls/db102/homepage
• Método de instalación
– Básico. Para instalación rápida: SW y permite crear BD de propósito general
(en base a una “precreada”). Método de instalación por defecto.
– Avanzado: para una instalacion personalizada del sw y/o de la BD.
• Tipo de instalación
– Enterprise Edition
– Standard Edition
– Personalizada
• Directorio raíz (ORACLE_HOME)
• Lista de productos a instalar
• Comprobación automática de los requisitos del SO
• Grupos del SO con privilegios (dba y/o oper)
• Creación de la BD: crear BD (ver DBCA) o Configurar ASM o Instalar sólo SW
• Asistentes de configuración (red con netca, BD con dbca, etc)
• Scripts a ejecutar como root
Administración de Oracle 10g (Parte 2) INSTALACIÓN DE ORACLE10g 6
TIPO DE BASE DE DATOS
• Uso General: transacciones cortas (OLTP) y también largas (procesos batch).
La BD creada incluye:
– Parámetros de inicialización usando spfile y gestión automática de UNDO.
– Oracle Options e interMedia
– Advanced Replication
– Servidores Dedicados (no usa MTS)
– NOARCHIVELOG
• Procesamiento de Transacciones (OLTP: Online Transaction
Processing): muchas transacciones cortas concurrentes, consistentes en
consultas sencillas sobre pocos datos (también actualizaciones).
• Almacén de Datos (Data Warehouse): consultas complejas sobre muchos
datos (OnLine Analytical Processing).
• Personalizada.
• Sólo Software: no crea BD ni configura sqlnet.
ASISTENTES DE CONFIGURACIÓN
• Database Configuration Assistant (dbca).
– Permite copiar una BD preconfigurada o crear una personalizada.
– Arranca automáticamente una vez que se ha instalado el sw Oracle.
• Oracle Net Configuration Assistant (netca): configura la red C/S de Oracle en
$ORACLE_HOME/network/admin.
– Opciones Enterprise y Standard: configura listener.ora, sqlnet.ora y
tnsnames.ora.
– Personalizada: permite configurar un servicio de directorio (LDAP), crear listeners
para conectar a la BD y seleccionar el método de resolución de nombres.
Configura, además de los anteriores, el fichero ldap.ora.
– Cliente: permite configurar tnsnames.ora, sqlnet.ora y ldap.ora.
• Database Upgrade Assistant (dbua): para actualizar una BD >=
8.1.7.4/9.0.1.4/9.2.0.4/10.1.0.2, después de instalar el sw de Oracle10g.
• Oracle Enterprise Manager Configuration Assistant: configura OMS y crea (o
actualiza) su repositorio (necesita BD).
• Oracle Internet Directory Configuration Assistant: configura OID, arrancando
OID Server (necesita BD).
REQUERIMIENTOS HW Y SW
(Linux)
• HW:
– RAM 1G (256M para el cliente): “grep Mem /proc/meminfo”
– HD entre 1.5 y 3.5Gb para el sw, 1.2Gb para la bd y al menos 400Mb de
/tmp: “df”
– Swap 1.5 RAM (si <=2G), e igual a la RAM (si >2G): ”/sbin/swapon s”.
• En Linux, si tenemos mucha RAM, podemos configurar poco swap; ej:
RAM=4Gb y Swap=1Gb.
• SW:
– Certificación:
http://www.oracle.com/technology/support/metalink/content.html
• Ejemplo (Linux x86 + Database Server + Enterprise + 10gR2)
– Suse 9 y 10
– Red Hat Enterprise AS/ES 3 y 4 (CentOS es clónico)
– Enterprise Linux 4
– Asianux 2
– Entorno gráfico (Xwin): “xclock”
– Acceso a los ejecutables: make, ar, ld, nm.
– Parámetros del kernel (/etc/sysctl.conf)
PARÁMETROS DEL KERNEL
Valores mínimos (Linux)
• SEMMNI = 100 (# máximo de conjuntos de semáforos).
• SEMMNS = 256 (# máximo de semáforos, sólo para la instalación inicial).
– SEMMNS = sum(processes) + max(processes) + 10*count(BBDD)
processes es el parámetro del init de cada BD.
• SEMOPM = 100 (# máximo de operaciones por “semop call”).
• SEMMSL = 100 (valor mínimo recomendado, sólo para la instalación inicial).
• SHMMAX = 2147483648 (tamaño máximo del segmento de memoria compartida y por tanto
de la SGA).
– 2 GB para kernel SMP. Se recomienda la mitad de la RAM.
– Si queremos tener una SGA de más de 2Gb tendremos q subir este valor.
• SHMMIN = 1 (tamaño mínimo de un segmento de memoria compartida).
• SHMMNI = 4096 (# máximo de segmentos de memoria compartida).
• SHMSEG = 4096 (# máximo de segmentos de memoria por proceso).
• SHMVMX = 32767 (valor máximo de un semáforo).
PARÁMETROS DEL KERNEL
Ejemplo con Linux FC3
(http://www.oraclebase.com/articles/10g/OracleDB10gR2InstallationOnFedora3.php)
Añadir las siguientes líneas al fichero /etc/sysctl.conf:
kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
# semaphores: semmsl, semmns, semopm, semmni
kernel.sem = 250 32000 100 128
fs.filemax = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default=262144
net.core.rmem_max=262144
net.core.wmem_default=262144
net.core.wmem_max=262144
Actualizar los parámetros en memoria con
# /sbin/sysctl p
Paquetes necesarios
FEDORA CORE 3 Linux
# De Fedora Core 3 Disk 1
cd /media/cdrom/Fedora/RPMS
rpm Uvh setarch1*
rpm Uvh tcl8*
rpm Uvh compatlibstdc++8*
rpm Uvh xorgx11deprecatedlibs6*
rpm Uvh openmotif2*
rpm Uvh compatdb4*
rpm Uvh compatlibstdc++devel8*
rpm Uvh compatgcc8*
rpm Uvh compatgccc++8*
rpm Uvh libaio0*
PREINSTALACIÓN (Linux)
• Crear puntos de montaje: uno para el sw y hasta seis para las bases de datos:
– /u01 (sw)
– /u02 (datos), /u03 (índices), /u04 (redo), /u05 (system), /u06 (temp) y /u07 (rollback)
• Crear grupo dba: “groupadd dba”.
• Crear grupo oinstall: “groupadd oinstall”.
• Crear usuario oracle con grupo primario dba y secundario oinstall: “useradd g
dba G oinstall oracle”.
• Crear directorio /u01/app/oracle (ORACLE_BASE) y /u02/oradata, /u03/oradata,
etc.
• Variables de entorno del usuario oracle justo antes de instalar:
– DISPLAY=workstation_name:0.0 (servidor Xwin)
– ORACLE_BASE=/u01/app/oracle (el resto es opcional)
– PATH debe incluir $ORACLE_HOME/bin, /usr/bin, /bin,
/usr/bin/X11/ y /usr/local/bin
– ORACLE_HOME=$ORACLE_BASE/product/10.2.0.1
– ORACLE_SID
INSTALACIÓN
• Artículo de OTN sobre instalación de Oracle 10g sobre Linux:
http://www.oracle.com/technology/pub/articles/smiley_10gdb_install.html
• Montar CD desde el root:
– # mount /mnt/cdrom
• Como usuario oracle, lanzar script de instalación desde fuera del punto
de montaje del CD (por ejemplo, desde el HOME del usuario oracle).
– Comprobar variables DISPLAY y ORACLE_BASE.
– $ /mnt/cdrom/runInstaller
Nota. Se podría ejecutar en modo “no interactivo” con:
$ /mnt/cdrom/runInstaller responsefile mirespfile silent
– Cambiar CD: “eject” o “umount /mnt/cdrom” y luego “mount
/mnt/cdrom”.
Nota: el punto de montaje del CDROM no tiene por qué ser “/mnt/cdrom”, puede
ser otro (“/media/cdrom”, etc).
POSTINSTALACIÓN
• Incluir variables en .bash_profile del usuario oracle:
– export ORACLE_BASE=/u01/app/oracle
– export ORACLE_HOME=$ORACLE_BASE/product/10.2.0.1
– export LD_LIBRARY_PATH=$ORACLE_HOME/lib
– export PATH=$ORACLE_HOME/bin:$PATH
– export ORACLE_SID=mibd
• Activar E/S asíncrona. Ejecutar el siguiente comando de
$ORACLE_HOME/rdbms/lib:
– make f ins_rdbms.mk asynch_on
• Comprobar seguridad de la BD:
http://www.oracle.com/technology/deploy/security/pdf/twp_security_checklist_db_database.pdf
• Comprobar parches de seguridad:
– http://www.oracle.com/technology/deploy/security/index.html
REVISION DE SEGURIDAD
• Instalar sólo aquellas opciones que sean necesarias (Java, Intermedia, etc).
• Bloquear cuentas de usuarios creados por defecto que no vayamos a utilizar.
DBCA bloquea todas menos SYS, SYSTEM, SCOTT y DBSNMP, por ejemplo:
outln, mdsys, wksys, ctxsys, ordsys, etc.
• Cambiar claves de usuarios creados por defecto: SYS, SYSTEM, etc.
• Proteger el DD con O7_DICTIONARY_ACCESSIBILITY = FALSE, impidiendo
acceso al DD a través de privilegios ANY. Así, por ejemplo, usuarios con
DROP ANY no podrán borrar el DD
• Practicar el principio de “los privilegios justos”. Por ejemplo, para conectar a la
BD dar CREATE SESSION y no CONNECT.
• Restringir los usuarios unix con acceso al servidor Oracle.
• Restringir el acceso al servidor Oracle a través de y desde la red.
• Aplicar todos los parches de seguridad que vayan saliendo.
– http://otn.oracle.com/deploy/security/alerts.html
COMPROBACIÓN FINAL
• En el directorio $ORACLE_BASE/oraInventory/logs podemos revisar lo
ocurrido durante la instalación.
• Comprobar que el SW y la BD (si hemos instalado una) funcionan.
– Conectar a la BD usando Sql*Plus
$ sqlplus /nolog
SQL*Plus: Release 10.2.0.2.0 Production on Tue Jan 2 12:59:46 2007
Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
SQL> connect / as sysdba
Connected.
– Comprobar el Listener Sql*Net
$ lsnrctl status
LSNRCTL for Linux: Version 10.2.0.2.0 Production on 02JAN2007 13:00:42
Copyright (c) 1991, 2005, Oracle. All rights reserved.
...
Instance "MNCS", status READY, has 1 handler(s) for this service...
...
The command completed successfully
– Oracle Enterprise Manger:
• Arrancar el servidor web de OEM:
$ emctl start dbconsole
• Acceder a “http://host:1158/em”
PRACTICAS TEMA 1
• 1.1. Comprobar los requerimientos HW y SW para la instalación de
Oracle10g sobre Linux.
• 1.2. Comprobar las tareas de preinstalación.
• 1.3. Comprobar cuánto ocupa el sw de Oracle10g.
• 1.4. Buscar el fichero de log de la instalación y echarle un vistazo.
• 1.5. Comprobar tareas de post instalación relacionadas con la seguridad
de la BD.
• 1.6. Consulta el “Simulador de Instalación de Oracle10g”.
• 1.7. Revisar alertas de seguridad en OTN.
• 1.8. Revisar el manual de instalación de Oracle10g para Linux.
TEMA 2
DISEÑO Y CREACIÓN DE UNA BASE DE
DATOS
TEMA 2.
DISEÑO Y CREACIÓN DE UNA BD
• Contiendas de E/S
– Diccionario de Datos (tablespace SYSTEM).
– Utilidades Oracle (tablespace SYSAUX en 10g, y antes TOOLS).
– Procesos (DBWR, LGWR, ARCH).
– Tipos de segmentos (tablas, índices, temp, rollback).
– Datos estáticos y dinámicos.
• Dimensionar memoria: SGA (Shared Pool, Buffer Cache, Redo Log).
• Dimensionar CPU.
• Dimensionar ficheros de la BD (Redo Log, System, Sysaux, Temp,
Rollback).
• Creación de la BD con CREATE DATABASE y OMF.
• DataBase Configuration Assistant (DBCA).
DISEÑO DE LA BASE DE DATOS
Contiendas en la E/S
• Es muy importante tener en cuenta las posibles contiendas en la E/S:
– Contienda entre el DD y los datos en sí. En el tablespace SYSTEM sólo
debe residir el DD y el segmento de rollback SYSTEM.
– Entre las utilidades del tablespace SYSAUX (>=10g) y las aplicaciones, o
con el DD. Puede ser necesario un disco para el SYSAUX.
– Contienda entre procesos: DBWR, LGWR y ARCH. Discos diferentes para
redolog online y archivado; y el resto de la BD.
– Contienda entre tipos de segmentos: datos, índices, rollback, temp. Separar
segmentos de datos, índices, rollback y temp.
– Contienda entre datos estáticos y dinámicos. Identificar los datos estáticos
(tablas pequeñas: países, provincias, tipos de vía, letras del nif, sexos, etc).
Se accederán con mucha frecuencia y sólo en lectura. Si no se detectan a
priori, se pueden identificar usando la auditoría (p.e. las que no tengan
insert/update/delete durante un día representativo, o varios días).
• Un tablespace para cada área funcional o cada aplicación (gestión económica,
gestión de personal, gestión académica, gestión de investigación, etc).
Administración de Oracle 10g (Parte 2) DISEÑO Y CREACIÓN DE UNA BD 21
DISEÑO DE LA BASE DE DATOS
Organización de los tablespaces
• Utilizar tablespaces locales (>=8i) con gestión automática de segmentos (>=9i).
• Separar los índices de los datos: se puede mover un índice con "alter index
rebuild tablespace tsp_indices;".
• Separar el UNDO (segmentos de rollback si <9i). Desde 9i, mejor la gestión
automática de UNDO. Podemos tener un tablespace de UNDO aparte, más
grande, para las transacciones largas de procesos nocturnos. Si se opta por la
manual, crear tablespace especial de rollback para las transacciones grandes.
• Separar los segmentos temporales en un tablespace temporal. Además, crear
tablespaces temporales adicionales para cada usuario que genere muchos
segmentos temporales. Si las aplicaciones usan tablas temporales globales,
también deben residir en un tablespace temporal independiente. Desde 10g, se
puede definir un grupo de tablespaces para el tablespace temporal por defecto
de la BD.
• Separar las vistas materializadas en un tablespace independiente.
• Separar las tablas temporales de trabajo, como pueden ser las usadas para
cargar información desde ficheros (no hacerlo directamente en las tablas a las
que va dirigida finalmente la información).
• En las tablas particionadas, separar las particiones en diferentes tablespaces, al
menos los datos vigentes de los históricos.
DIMENSIONAR MEMORIA EN 10G
• La RAM debe albergar no sólo la SGA de nuestra BD, sino todos los procesos de
la misma (PGAs), más aquellos procesos necesarios en nuestro sistema (que no
son de la BD). Así como el núcleo de Oracle.
• La SGA la dimensionamos con SGA_TARGET (nuevo en 10g, activa ASMM si
statistics_level vale ALL o TYPICAL), fijando el máximo con SGA_MAX_SIZE.
http://cursos.atica.um.es/oradoc102/server.102/b14231/create.htm#sthref383
• Desde 9i podemos usar un pool compartido para las PGAs, dimensionándolo con
PGA_AGGREGATE_TARGET (mínimo 10M).
• Memoria Oracle 10g = Núcleo Oracle + PGA_AGGREGATE_TARGET +
SGA_MAX_SIZE.
• Memoria máxima para Oracle: 80% de la RAM (RAM * 0.8):
– Mínimo de 40M para el núcleo:
$ size $ORACLE_HOME/bin/oracle
text data bss dec hex filename
74097968 288308 121304 74507580 470e53c /u01/app/oracle/product/10.2.0.1/bin/oracle
– 20% para PGA_AGGREGATE_TARGET: (RAM * 0.8 – núcleo) * 0.2
– 80% para SGA_MAX_SIZE: (RAM * 0.8 – núcleo) * 0.8
• Ejemplo: supongamos RAM=1024M y núcleo=70M
– PGA_AGGREGATE_TARGET = (1024 * 0.8 – 70) * 0.2 = 149M
– SGA_MAX_SIZE = (1024 * 0.8 – 70) * 0.8 = 599M
• En v$pga_target_advice, buscar 1ª fila con ESTD_OVERALLOC_COUNT=0.
VER MEMORIA EN LINUX
• La memoria libre (y la usada) la podemos ver con “free m”.
$ free m
total used free shared buffers cached
Mem: 4041 3992 49 0 152 2487
/+ buffers/cache: 1353
1353 2688
Swap: 2047 373 1673
• Los segmentos de memoria compartida (SGAs) se ven con “ipcs m”.
$ ipcs m
Segmentos memoria compartida
key shmid propietario perms bytes nattch estado
0x6abd8a34 5537793 oracle 660 102760448 13
...
• La memoria necesaria para el ejecutable de oracle, la podemos ver con el
comando unix “size”.
$ size $ORACLE_HOME/bin/oracle
text data bss dec hex filename
74097968 288308 121304 74507580 470e53c /u01/app/oracle/product/10.2.0.1/bin/oracle
• La memoria asociada a cada servidor dedicado (uno por sesión):
– “ps v pid_proceso” o “ps u usuario v”
• RSS > Tamaño de la parte residente del proceso en memoria real (en Kb).
• %MEM > Porcentaje de la memoria real (RAM) que ocupa la parte residente.
$ ps u oracle v|grep i local
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
14560 ? Ss 0:00 0 72361 116542 13492 0.3 oracleCURSO70 (DESCRIPTION=(LOCAL=YES)
DIMENSIONAR LA SGA
SharedPool y BufferCaché
• El tamaño aproximado de la SGA (SGA_TARGET si >=10g) es el siguiente:
DB_CACHE_SIZE + [DB_KEEP_CACHE_SIZE + DB_RECYCLE_CACHE_SIZE + DB_nk_CACHE_SIZE]
+ SHARED_POOL_SIZE + [LARGE_POOL_SIZE + JAVA_POOL_SIZE + STREAMS_POOL_SIZE] +
LOG_BUFFERS + 1MB
Nota: streams_pool_size sólo >=10g. Puede haber hasta cuatro DB_nk_CACHE_SIZE, con n = 2, 4, 8,
16, 32k (uno de los tamaños de bloque es el que usa DB_CACHE_SIZE. )
• En 10g se simplifica mucho: SGA_MAX_SIZE y SGA_TARGET. Si dejamos los
demás a cero (db_cache_size, shared_pool_size, large_pool_size, java_pool_size
y streams_pool_size), Oracle reparte sga_target automáticamente entre ellos.
• Si queremos fijar manualmente shared_pool_size y/o db_cache_size (ó <=9i):
– Memoria recomendada para todas las SGAs de un servidor:
• Para servidores con RAM <= 1Gb: RAM * 0.55
• Para servidores con RAM > 1Gb: RAM * (0.60 a 0.75)
– Memoria recomendada por instancia: (RAM * 0.55) / nºinstancias.
– Shared pool = mem por instancia * 0.45
– Buffer cache = mem por instancia *0.45
• Se puede ver el overhead necesario en shared pool para el arranque en
V$SGAINFO (>=10g). En 10g el overhead resta de shared_pool_size (en 9i no).
• Recomendaciones de espacio para shared pool y buffer caché (>=9i):
– V$SHARED_POOL_ADVICE
– V$DB_CACHE_ADVICE (parámetro db_cache_advice=ON)
Nota: STATISTICS_LEVEL debe valer ALL o TYPICAL
DIMENSIONAR LA SGA
Shared Pool y Log Buffer
• V$SHARED_POOL_ADVICE. Ver si interesa redimensionar SharedPool.
SELECT shared_pool_size_for_estimate "Size of Shared Pool in MB",
shared_pool_size_factor "Size Factor", estd_lc_time_saved "Time Saved in
sec" FROM v$shared_pool_advice;
Size of Shared Pool in MB Size Factor Time Saved in sec

24 .5 525
48 1 525
72 1.5 525
96 2 526
• V$SGA_DYNAMIC_COMPONENTS y V$SGA_RESIZE_OPS. Ver gestión dinámica.
– select component, current_size, min_size, user_specified_size from
v$sga_dynamic_components;
RPAD(COMPONENT,30) CURRENT_SIZE MIN_SIZE USER_SPECIFIED_SIZE

shared pool 50331648 25165824 0
large pool 4194304 0 0
– select rpad(component,28), oper_type, initial_size/1024/1024 "INITIAL",
FINAL_SIZE/1024/1024 "FINAL", status from v$sga_resize_ops;
RPAD(COMPONENT,28) OPER_TYPE INITIAL FINAL STATUS

DEFAULT buffer cache STATIC 44 40 COMPLETE
shared pool GROW 40 44 COMPLETE
• El parámetro del init LOCK_SGA=true evita que se haga swapping de la SGA.
• LOG_BUFFER no necesita más de pocos cientos de Kb, incluso en un sistema
con mucha carga, 1MB posiblemente sea suficiente. Asignar más de 3Mb es
inútil ya que el LGWR escribe cuando el buffer se llena 1/3 o 1Mb.
DIMENSIONAR LA CPU
• Si partimos de una sola CPU, podemos detectar que llega a su límite de uso si:
– Porcentaje máximo de ocupación de CPU = 90%.
– Porcentaje máximo de procesamiento OS/usuario = 40/60%.
Nota: podemos usar los comandos Linux “top” y “sar”.
$ sar
18:20:00 CPU %user %nice %system %iowait %idle
18:30:00 all 0,20 0,00 0,06 0,20 99,54
18:40:00 all 0,16 0,00 0,17 0,12 99,54
Media: all 0,08 0,00 0,05 0,33 99,54
• Si hay varias CPUs, la carga debe estar balanceada. Para una BD mediana con
una carga razonable, lo ideal sería disponer al menos de 2 CPUs.
• Para una instancia con “servidores dedicados” (sin MTS), tendremos un proceso
servidor por cada sesión, además de los procesos background. Por ejemplo, para
100 usuarios simultáneos tendremos un mínimo de 100 procesos nuevos en
nuestro sistema. Probar con MTS si se degrada el uso de CPU por muchas
sesiones concurrentes (MTS es mejor si hay muchas conexiones a la BD).
• Parámetros que limitan el número de procesos y de sesiones:
– PROCESSES. Número máximo de procesos en la instancia.
– SESSIONS. Por defecto 1.1*PROCESSES; sin embargo si usamos MTS habrá que
subirlo (con MTS se puede usar shared_server_sessions para limitar esas sesiones).
DIMENSIONAR FICHEROS
Redo Log
• Redo = 50 a 100M (cada fichero).
– El tamaño óptimo se puede sacar de la columna OPTIMAL_LOGFILE_SIZE
de la vista V$INSTANCE_RECOVERY.
• Al menos tres grupos y, si disponemos de discos, los multiplexaremos en dos
discos (dos miembros por grupo).
• Empezaremos con ficheros de 50100M, intentando que los “log switch” sucedan
cada 2030 minutos.
• Si queremos que los checkpoints coincidan con los “log switch” (y como máximo
cada 30 minutos), asignaremos los parámetros:
– log_checkpoint_interval=0
– log_checkpoint_timeout=1800 (30 minutos, pondremos 0 si queremos que coincidan
con el “log switch”, independientemente del tiempo transcurrido).
– FAST_START_MTTR_TARGET=0 (desactiva “fast recovery instance”).
Nota: log_checkpoint_to_alert=true muestra checkpoints en fichero alert.log.
• FAST_START_MTTR_TARGET es nuevo desde 9i, y permite indicar el nº de segundos
que esperamos que (como mucho) tarde la “recuperación de la instancia” (después de una
“caída”). El valor máximo son 3600 segundos (1h).
DIMENSIONAR FICHEROS
System, Sysaux, Temp y Rollback
• SYSTEM >= 260M. Activaremos el “autoextend” con next=10M.
• SYSAUX. Estimar tamaño con $ORACLE_HOME/rdbms/admin/utlsyxsz.sql, o:
– 500M, BD pequeña (2 cpu, 10 sesiones activas, 500 objetos (tablas/índices).
– 2G para BD mediana (8 cpu, 20 sesiones, 5000 objetos).
– 5G para BD grande (32 cpu, 100 sesiones, 50000 objetos).
• TEMP >= 100M. Tablespaces locales con “uniform size 1M” (si muchas sesiones
simultáneas, 256K). Con pga_aggregate_target se ignora *_area_size.
– Los segmentos temporales ocupan espacio igual que una tabla: para ordenar
una tabla de 100M, por todas sus columnas, necesitaré 100M.
– Operaciones que necesitan segmentos temporales: SELECT ORDER BY,
GROUP BY, DISTINCT, UNION, INTERSECT or MINUS, nonindexed joins,
CREATE INDEX, CREATE/ENABLE PRIMARY/UNIQUE KEY
CONSTRAINT, temporary tables, Temporary LOBs, Statistics collection.
• RBS >= 100M. Usar modo “auto” (no permite “set transaction”). Si usamos modo
“manual”, crear un RS por cada 4 sesiones, y 20 extensiones iniciales cada uno.
“Optimal” debe ser suficiente para 90% de transacciones.
– V$UNDOSTAT. Estadísticas de UNDO cada 10 minutos, incluyendo bloques
de undo y la consulta más larga (en segundos).
SELECT TO_CHAR(BEGIN_TIME,'DD/MM/YYYY HH24:MI') "TIME", UNDOTSN, UNDOBLKS,
TXNCOUNT,MAXQUERYLEN FROM V$UNDOSTAT;
TIME UNDOTSN UNDOBLKS TXNCOUNT MAXQUERYLEN

18/01/2007 10:40 368 16 338516 6
FICHERO DE PARÁMETROS
• Para arrancar la instancia, el servidor Oracle tiene que leer el fichero de
parámetros de inicialización (spfile o init), cuya ubicación predeterminada es
$ORACLE_HOME/dbs.
• El fichero de parámetros de inicialización puede ser de dos tipos:
– Init: se trata de un fichero de texto, editable, cuyo nombre sigue el patrón
init$ORACLE_SID.ora.
– Spfile: es un fichero binario, no editable pero visualizable, cuyo nombre
sigue el patrón spfile$ORACLE_SID.ora.
• Se crea, a partir de un init, con:
CREATE SPFILE [='nombre'] FROM PFILE [='nombre'];
Nota1. Si se omiten los nombres, toma los valores por defecto.
Nota2. La BD no podrá abrir el nuevo spfile hasta el siguiente arranque.
Nota2. Se puede crear un init a partir de un spfile, invirtiendo la sintaxis.
• Los parámetros del spfile se modifican con:
ALTER SYSTEM SET parámetro = valor [SCOPE = MEMORY |
SPFILE | BOTH]
Nota. Si queremos modificar el parámetro sólo en el spfile, indicaremos SPFILE.
EJEMPLO DE INIT.ORA
Suponemos RAM=1Gb, un máximo de 50 sesiones simultáneas, checkpoints cada 30min, gestión
automática de PGAs (RAM*0.80*0.20, resto SGA):
db_name=CURSOxy # Nombre de la BD.
compatible = 10.2.0
background_dump_dest = /u01/app/oracle/admin/CURSOxy/bdump
core_dump_dest = /u01/app/oracle/admin/CURSOxy/cdump
user_dump_dest = /u01/app/oracle/admin/CURSOxy/udump
max_dump_file_size = 10240 # tamaño máximo fichero traza de 5M
control_files = (/u02/oradata/CURSOxy/control1.ctl,
/u03/oradata/CURSOxy/control2.ctl)
undo_management = auto # Gestión automática de Rollback
undo_tablespace = undo_rbs # Tablespace de “undo”
pga_aggregate_target=160M # Espacio máx todas las PGAs (fuera de SGA)
sga_max_size = 640M # Tamaño máximo de la SGA (RAM*0.8*0.8)
sga_target = 512M # Gestión automática del reparto del espacio de SGA
db_cache_size = 0 # Oracle asignará el tamaño automáticamente
shared_pool_size = 0 # Oracle asignará el tamaño automáticamente
large_pool_size = 0
java_pool_size = 0
log_buffer = 3145728 # Tamaño, en bytes, de la caché de redo (3Mb)
log_checkpoint_interval = 0 # desactiva “checkpoint interval”
log_checkpoint_timeout = 1800 # checkpoint como mucho cada 30minutos.
processes = 50 # Nº máx. de procesos (background + sesiones)
remote_login_passwordfile=EXCLUSIVE
nls_territory=spain
nls_language=spanish
CREAR LA BASE DE DATOS
• Para crear una BD necesitamos:
– Conectarnos al servidor Oracle como “SYS AS SYSDBA”, autenticándonos contra
el S.O. o usando un fichero de claves.
– Suficiente memoria para arrancar la instancia y espacio en disco para crear la BD.
• Para ubicar los ficheros que componen la BD:
– Guardaremos, al menos, dos copias del fichero de control, en discos separados.
– Multiplexaremos los redolog en discos diferentes.
– Separaremos los ficheros de datos que provoquen contención en disco; por
ejemplo: datos, índices, temp y rollback.
• La BD la podemos crear con el asistente gráfico (en Linux “dbca”) o con el
comando CREATE DATABASE:
– Crearemos un fichero init.ora, y si queremos, un spfile.ora.
– Arrancaremos las instancia con STARTUP NOMOUNT.
– Crearemos la BD con el comando CREATE DATABASE.
– Ejecutaremos los scripts catalog.sql, catproc.sql y catexp.sql que están en
$ORACLE_HOME/rdbms/admin.
• Desde 10g se puede borrar con “DROP DATABASE;” (sólo montada).
EJEMPLO CON “CREATE
DATABASE”
connect / as sysdba
startup nomount
CREATE DATABASE "CURSOxy"
maxdatafiles 254
maxinstances 1
maxlogfiles 32
character set WE8ISO8859P15
DATAFILE '/u02/oradata/CURSOxy/system01.dbf' SIZE 260M
AUTOEXTEND ON NEXT 10M
EXTENT MANAGEMENT LOCAL
SYSAUX DATAFILE '/u02/oaradata/CURSOxy/sysaux01.dbf' size 100M
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
UNDO TABLESPACE UNDO_RBS
DATAFILE '/u03/oradata/CURSOxy/rbs01.dbf' SIZE 10M
DEFAULT TABLESPACE USERS
DATAFILE '/u02/oradata/CURSOxy/users01.dbf' SIZE 10M
DEFAULT TEMPORARY TABLESPACE TEMP
TEMPFILE '/u03/oradata/CURSOxy/temp01.dbf' SIZE 10M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K
logfile '/u04/oradata/CURSOxy/redo01.log' SIZE 10M,
'/u04/oradata/CURSOxy/redo02.log' SIZE 10M,
'/u04/oradata/CURSOxy/redo03.log' SIZE 10M;
rem *** CREACION DE LAS VISTAS DEL DD ***
@$ORACLE_HOME/rdbms/admin/catalog.sql
@$ORACLE_HOME/rdbms/admin/catproc.sql
ORACLE MANAGED FILES (OMF)
• OMF permite que Oracle se encargue de la creación de los ficheros que
componen la BD, simplificando la administración de la misma.
• OMF se activa mediante dos parámetros de inicialización:
– DB_CREATE_FILE_DEST. Define el directorio donde se ubicarán los ficheros.
– DB_CREATE_ONLINE_LOG_DEST_N. Establece los directorios donde se
guardarán (multiplexados) los ficheros redolog; donde N puede valer de 1 a 5.
Nota. Se pueden activar ambos parámetros o sólo uno ellos.
• Ejemplo para crear una BD, usando OMF, separando los ficheros redolog y de
control del resto:
– Parámetros de inicialización (indicando dos copias de redolog y control):
• DB_CREATE_FILE_DEST='/u02/oradata/CURSOxy'
• DB_CREATE_ONLINE_LOG_DEST_1='/u03/oradata/CURSOxy'
• DB_CREATE_ONLINE_LOG_DEST_2='/u04/oradata/CURSOxy'
– Creación de la BD:
CREATE DATABASE DEFAULT TABLESPACE USERS
DEFAULT TEMPORARY TABLESPACE TEMP
UNDO TABLESPACE UNDO_RBS;
DBCA (DataBase Configuration
Assistant)
• En Unix/Linux se ejecuta con “dbca”. Se trata de un asistente gráfico que
permite:
– Crear una BD. A partir de plantillas predefinidas, que contienen:
• Sólo la estructura. Se pueden cambiar todos los parámetros del init.
• También con ficheros: no se puede cambiar nada.
– Añadir opciones a una BD existente (Java, Intermedia, Spatial, OLAP, etc).
– Borrar una BD.
– Gestionar plantillas de BD: crear una plantilla a partir de otra, o a partir de
sólo la estructura de una BD, o también incluyendo los datos de la misma.
VISTAS DEL DD
• V$DATABASE (Base de datos).
• V$INSTANCE (Instancia).
• V$SGAINFO (SGA). Nuevo en 10g es V$SGAINFO.
• V$SGA_DYNAMIC_COMPONENTS (Zonas dinámicas de la SGA).
• V$SGASTAT (SGA detallada).
• V$SHARED_POOL_ADVICE (Estimaciones de tamaño de la SharedPool)
• V$BUFFER_POOL (Buffers en la caché de datos)
• V$DB_CACHE_ADVICE (Estimaciones db_cache_size)
• V$PGA_TARGET_ADVICE (Estimaciones pga_aggregate_target)
• V$SQLAREA (Sentencias SQL).
• V$PROCESS (Procesos).
• V$BGPROCESS (Procesos background).
• V$DATAFILE (Ficheros de datos de la BD).
• V$CONTROLFILE (Ficheros de control de la BD).
• V$LOGFILE (Ficheros redo log de la BD).
PRACTICAS TEMA 2
• 2.1. Diseñar una BD teniendo en cuenta las contiendas de E/S y la organización
de los tablespaces básicos. Suponer 4 discos: /u01 (SW) y /u02, /u03, /u04 (BD).
• 2.2. Crear un init.ora, diseñando requerimientos de memoria, suponiendo 4Gb
de RAM y 21 instancias con 10 usuarios cada una. Se puede usar un máximo
del 64% de la RAM para las SGAs de todas las bases de datos. Los checkpoints
sucederán cuando se llene el fichero redolog y, como máximo, cada 30 minutos.
La gestión de rollback será automática. Tendremos dos copias del fichero de
control en /u02 y /u03.
• 2.3. Crear la BD que hemos diseñado anteriormente, y para la que también
hemos creado un init.ora. Hacerlo manualmente con CREATE DATABASE. El
nombre de la BD será ALUxy. Antes de lanzar el comando de creación, ponte de
acuerdo con un compañero para que no lo hagais a la vez.
• 2.4. Crear la misma BD usando OMF, y cambiando el nombre por OMFxy.
• 2.5. Consultar el “Simulador de DBCA”.
TEMA 3
ESTRUCTURAS DE ALMACENAMIENTO
TEMA 3.
ESTRUCTURAS DE
ALMACENAMIENTO
• Bloques, extensiones y segmentos.
• Varios tamaños de bloque en la misma BD.
• Formato del bloque.
• Generación del espacio libre en un bloque.
• Estructura de la fila.
• Extensiones y su asignación.
• Segmentos.
• Gestión automática del espacio de los segmentos.
• Comprimir los datos de un segmento.
• Métodos de acceso a datos: índices Btree y Bitmap.
• RECYCLEBIN y drop table.
• Envío de correo con UTL_MAIL.
• Encolar y/o suspender la BD.
BLOQUES, EXTENSIONES Y
SEGMENTOS
• La unidad mínima de asignación de espacio es el
bloque de datos (múltiplo del bloque del S.O.: 2,
4, 8, 16 y 32Kb); de modo que un conjunto
contiguo de bloques forman una extensión. Y las
extensiones forman segmentos de una
determinada estructura de datos (tablas, índices,
rollback, temporal, etc).
• Oracle asigna espacio a un segmento en
unidades de una extensión. Todas las
extensiones de un mismo segmento residen en el
mismo tablespace.
• Oracle pide espacio en múltiplos del bloque de
datos, cuyo tamaño se indica con el parámetro
db_block_size.
Administración de Oracle 10g (Parte 2) ESTRUCTURAS DE ALMACENAMIENTO 40
DIFERENTES TAMAÑOS DE
BLOQUE EN LA MISMA BD
• Aunque el parámetro db_block_size define el tamaño del bloque “estandar” de la BD, se
pueden usar otros tamaños (>=9i) indicándolo a nivel de tablespace, y definiendo la
correspondiente caché de datos con el nuevo tamaño de bloque.
• La Database Buffer Cache consta de tres cachés independientes:
– DB_CACHE_SIZE. Dimensiona la caché por defecto, que siempre existe y cuyo
tamaño no puede valer cero.
– DB_KEEP_CACHE_SIZE. Dimensiona la caché donde se guardarán los bloques de
tablas que se usan con mucha frecuencia.
– DB_RECYCLE_CACHE_SIZE. Dimensiona la caché que almacena los bloques de
las tablas que se usan muy poco.
– El uso de una u otra caché lo indicaremos con el parámetro BUFFER_POOL, de la
clausula STORAGE de la tabla: keep, recycle o default.
• DB_nK_CACHE_SIZE (>=9i). Dimensiona hasta 4 cachés con tamaño de bloque “no
estandar”, con n=2,4,8,16,32.
• Al crear un tablespace, con la clausula BLOCKSIZE, se puede especificar una tamaño de
bloque “no estandar”. Para ello debe estar definido el parámetro DB_CACHE_SIZE y, al
menos, un DB_nK_CACHE_SIZE; de forma que n coincida con el valor que acompaña a
BLOCKSIZE. No se pueden indicar tamaño de bloque no estandar para tablespaces
temporales.
FORMATO DEL BLOQUE
• Cabecera: información general del

bloque (dirección del bloque, tipo de
segmento, etc). 4 bytes.
• Directorio de tabla: información sobre la
tabla. 4 bytes.
• Directorio de filas: información sobre las
filas que actualmente contiene el bloque
(direcciones, etc). 2 bytes por fila.
• Overhead (es el conjunto de los tres
anteriores). Como media, su tamaño
oscila entre 84 y 107 bytes.
• Datos
– Espacio libre: se usa para inserts y updates, y también para registrar las
transacciones (“transaction entries”, unos 23 bytes por cada una).
GENERACION DE ESPACIO LIBRE
EN UN BLOQUE
• Oracle recomienda el uso de la gestión automática del espacio libre (>=9i).
– Se hace al crear un tablespace con “SEGMENT SPACE MANAGEMENT AUTO”.
• Sentencias que generan espacio libre en un bloque: delete y update. Dicho
espacio quedará disponible para los inserts posteriores si:
– El insert sucede en la misma transacción que libera espacio.
– Sucede en otra transacción después del commit de la primera.
• El espacio libre no tiene por qué estar contiguo. Sólo se compactará si al hacer
un insert/update hay suficiente espacio libre, pero no está contiguo.
• Row Chaining (y Migration). Si una nueva fila no cabe en un bloque, será
almacenada en una “cadena de bloques” (dos o más). Si se trata de una fila
que aumenta de tamaño por un update, y no cabe en el bloque, su contenido
será “migrado” a otro bloque, manteniendo un puntero en el bloque original.
• Se reservará, al menos, el espacio libre indicado por PCTFREE (%) para
actualizaciones. Cuando el espacio libre baje a pctfree, no se permitirán más
inserciones (hasta que el espacio ocupado no baje de PCUSED).
– Nota: los tablespaces con gestión automática de segmentos (>=9i) no
necesitan PCTUSED.
ESTRUCTURA DE LA FILA
• Estructura de la fila:
– Cabecera: 3 bytes (de ellos un byte para nºcolumnas).
– Rowid: 6 bytes (1 para el fichero, 4 para el bloque y 1 para fila dentro del
bloque).
– Cabecera de columna: 1byte (o 3bytes si columna>250bytes).
– Columna: datos (si null, no ocupa espacio).
– Cabecera de columna.
– Columna ...
• Longitud de las columnas:
– char(n): n bytes.
– varchar2(n): hasta n bytes.
– Date: 8 bytes desde 9i (antes 7 bytes)
– number(n,m): n/2(entero mayor), más 1 byte. Por ejemplo: number(9,2),
9/2=4.5, 5+1=6.
EXTENSIONES Y SU ASIGNACIÓN
• Una extensión es una unidad lógica de almacenamiento compuesta por un
conjunto de bloques contiguos. Una o más extensiones componen un segmento.
• Oracle recomienda usar tablespaces “manejados localmente” (>=8i), con
extensiones de tamaño uniforme (uniform size) o variable (autoallocate), donde
ya no sirven los parámetros initial, next, pctincrease, minextents, maxextents del
“default storage”:
– Uniform Size. Puedes indicar el tamaño de la extensión (al menos 5 bloques) o usar el
valor por defecto (1M). Los tablespaces temporales “locales” sólo pueden usar este
tipo de asignación de extensiones.
– Autoallocate. Puedes definir la extensión inicial y Oracle determina el tamaño óptimo
para las siguientes (tamaño mínimo 64Kb). Es el defecto para tablespaces
permanentes.
• Si el tablespace se crea con gestión automática de segmentos y
db_block_size>=16K, el tamaño mínimo de la extensión será 1M.
• Para asignar una extensión a un segmento, en un tablespace local, Oracle busca
en el bitmap del fichero el número requerido de bloques libres contiguos.
• Las extensiones vacías no se devuelven al tablespace hasta que se borra el
objeto (drop table/cluster), a no ser que hagamos “TRUNCATE ... DROP
STORAGE;” o “ALTER TABLE ... DEALLOCATE UNUSED;”.
SEGMENTOS
• Un segmento es un conjunto de extensiones que contienen todos los datos de
una estructura lógica de almacenamiento específica, dentro de un tablespace
(segmentos de datos, segmentos de índice, segmentos temporales, etc).
• El primer bloque de un segmento (Header) contiene un directorio de las
extensiones que lo integran.
• Segmento de datos: es una tabla normal, o una partición de una particionada, o
un cluster de tablas.
• Segmento de índices: índice no particionado, o partición de uno particionado. No
tienen que estar en el mismo tablespace que las tablas correspondientes.
• Segmentos temporales: Oracle los usa para hacer ordenaciones, que no caben
en memoria: create index, select ... order by, select distinct, select ... group by,
select ... union, select ... intersect, select ... minus. También se usan para crear
tablas temporales y sus índices (son tablas que contienen datos sólo durante una
transacción o una sesión). Se puede mejorar su rendimiento ajustando el
parámetro sort_area_size. Sin MTS, usar pga_aggregate_target para todas las
áreas de sort de todas las sesiones (todas las PGAs).
GESTION AUTOMATICA DEL
ESPACIO DE LOS SEGMENTOS
• Desde la versión 9i se incluye la posibilidad de gestionar el espacio de los
segmentos automáticamente, siendo más fácil, con mejor utilización del espacio,
y también mejor rendimiento en las operaciones concurrentes de inserción.
• Cada segmento contiene un bitmap que describe el estado de ocupación de cada
bloque, y que se guarda en un conjunto independiente de bloques.
• Se puede activar sólo para los tablespaces permanentes manejados localmente,
excepto el SYSTEM:
CREATE TABLESPACE TSP_CURSO
DATAFILE '/u02/oradata/CURSO/tsp_curso01.dbf' SIZE 10M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K
SEGMENT SPACE MANAGEMENT AUTO;
Se ignoran las clausulas PCTUSED, FREELISTS y FREELISTS GROUPS.
• Una vez creado un tablespace local con gestión automática del espacio de los
segmentos, no tiene vuelta atrás.
• Oracle recomienda la gestión automática porque obtiene mayor rendimiento y es
mucho más fácil de mantener.
• Ya no hace falta PCTUSED.
COMPRESION DE LOS
SEGMENTOS DE DATOS
• Podemos indicar la clausula COMPRESS al crear una tabla (por defecto será
NOCOMPRESS), para que Oracle intente comprimir los datos (excepto para tipos
LOB y tablas IOT). Esto es muy útil en entornos con muy pocas actualizaciones
(insert/update), como datawarehouse.
• Se reduce el uso de disco y memoria (caché de datos) y se recomienda para las
operaciones de sólo lectura.
• Los datos se comprimen, en cada bloque, eliminando los valores repetidos de una
misma columna, que se guardan en una tabla. El factor de compresión será mayor
en bloques con valores repetidos. Se pueden reorganizar las filas agrupando
valores repetidos de una columna en el mismo bloque: “create table as select
order by”, ordenando por columnas con baja cardinalidad.
• Al crear un tablespace, podemos indicar COMPRESS en la clausula DEFAULT;
para que por defecto, se compriman los datos en las tablas que contenga.
METODOS DE ACCESO A DATOS
INDICES BTREE Y BITMAP
• Usaremos índices Btree, en general, cuando vayamos a hacer consultas que
acceden frecuentemente a no más del 1015% de las filas de la tabla.
• Comprobar si un índice se usa (>=9i):
– ALTER INDEX nombre MONITORING USAGE; (activa seguimiento)
– SELECT * FROM V$OBJECT_USAGE; (comprueba uso)
– ALTER INDEX nombre MONITORING USAGE; (desactiva seguimiento)
• Vistas donde ver estadísticas de índices:
– dba_indexes: dbms_stats.gather_index_stats('owner','indice');
– index_stats: analyze index i_nombre validate structure;
– v$segment_statistics (statistics_level=typical u all)
• Falsos mitos sobre degradación de índices:
– Con el tiempo el arbol btree puede perder el “balanceo”. NUNCA.
– Con los borrados se va perdiendo espacio. NO, el espacio se reutiliza.
– Si los niveles del árbol llegan a 'x', el índice se vuelve ineficiente. NO.
• En general no será necesario, pero podemos reconstruir un índice:
alter index i_nombre rebuild;
• Indices Bitmap; muy útiles para accesos en sólo lectura sobre columnas de baja
cardinalidad, en tablas muy grandes (aplicaciones DSS). Muy eficientes para
predicados OR. No usarlos si se hacen updates con frecuencia (aplicaciones
OLTP). Bloqueos a nivel de segmento de bitmap (no de fila).
create bitmap index i_b_nombre on t_tabla (cols) tablespace tsp_nombre;
• Las IOT son tablas almacenadas en un índice Btree. Son útiles para tablas
estaticas que se acceden con frecuencia por la clave primaria (casi todas sus
columnas forma parte de la PK), y que no van a tener ningún otro índice.
RECYCLE BIN Y DROP TABLE
• RECYCLE BIN (>=10g). Contenedor donde Oracle guarda las tablas
borradas (a no ser q se borre con la opción PURGE).
• DBA_RECYCLEBIN. Ver todas las tablas borradas. En
USER_RECYCLEBIN o RECYCLEBIN, sólo las mías. Tb con SHOW
RECYCLEBIN (desde sql*plus).
• Se puede desactivar con parámetro del init “recyclebin = off” (por defecto
“on”). Tb con “ALTER SYSTEM | SESSION ...”.
• Recuperar tabla borrada:
– FLASHBACK TABLE tablaBorrada TO BEFORE DROP;
• Borrar definitivamente:
– PURGE TABLE tabla; (tb PURGE INDEX)
Sólo van a RECYCLEBIN los índices de las tablas borradas (no con DROP
INDEX)
– PURGE RECYCLEBIN | DBA_RECYCLEBIN;
– PURGE TABLESPACE nomtsp [USER usuario];
• Borrar directamente sin pasar por RECYCLEBIN:
– DROP TABLE tabla PURGE;
ENVIAR CORREO DESDE ORACLE
Paquete UTL_MAIL
• El paquete UTL_MAIL (>=10g) no se instala por defecto por razones de
seguridad.
• Instalar UTL_MAIL desde el SYS:
SQL> @$ORACLE_HOME/rdbms/admin/utlmail.sql
SQL> @$ORACLE_HOME/rdbms/admin/prvtmail.plb
• Para poder usar UTL_MAIL hay que definir el parámetro SMTP_OUT_SERVER,
en el init:
smtp_out_server='miServidorDeCorreo.miDominio'
• Una vez arrancada la BD con el nuevo parámetro, podremos enviar un mensaje
con utl_mail.send:
SQL> exec
utl_mail.send('remitente@dominio','destinatario@um.es',nu
ll,null,'Prueba desde Oracle 10g','La fecha actual es '||
to_char(sysdate,'dd/mm/yyyy hh24:mi:ss'))
PL/SQL procedure successfully completed.
ENCOLAR Y SUSPENDER LA BD
Quiesce y Suspend
• “Encolar” la BD (>=9i). Util si el DBA necesita que no haya transacciones ni
consultas concurrentes a la suya. Espera a que terminen transacciones/consultas
(se pueden ver en V$BLOCKING_QUIESCE) e impide nuevas (excepto de
SYS/SYSTEM). Sólo desde SYS/SYSTEM. V$INSTANCE.ACTIVE_STATE:
– ALTER SYSTEM QUIESCE RESTRICTED;
– ALTER SYSTEM UNQUIESCE;
• “Suspender” la BD (>=9i). Util para copias de seguridad en caliente. Suspende
E/S a ficheros de datos y control (los tablespaces deben estar en modo “hot
backup” con ALTER TABLESPACE BEGIN BACKUP). Sólo SYS/SYSTEM.
V$INSTANCE.DATABASE_STATUS. ¡¡¡ Ojo !!!, no cerrar la sesión que hace el
SUSPEND pues es la única que puede hacer RESUME:
ALTER TABLESPACE nomtsp BEGIN BACKUP;
...
ALTER SYSTEM SUSPEND;
// Copiamos ficheros de la BD (necesitará “recuperar la
instancia”, pues no se hace checkpoint).
ALTER SYSTEM RESUME;
ALTER TABLESPACE nomtsp END BACKUP;
...
VISTAS DEL DD
• DBA_TABLESPACES (Tablespaces de la BD).
• DBA_SEGMENTS (Segmentos que hay en los tablespaces).
• DBA_EXTENTS (Extensiones que componen los segmentos).
• DBA_FREE_SPACE (Extensiones libres en cada tablespace).
• DBA_INDEXES (Indices creados sobre tablas de la BD, con estadísticas).
• INDEX_STATS (estadísticas de índices)
• V$SEGMENT_STISTICS (estadísticas de segmentos)
• DBA_RECYCLEBIN (objetos borrados con DROP, sin indicar PURGE)
• V$INSTANCE (Datos de la instancia, incluyendo si está encolada y/o
suspendida)
• SELECT DBMS_METADATA.GET_DDL('TABLE','T1') FROM DUAL; (muestra la
sentencia DDL para crear la tabla T1).
• SELECT DBMS_METADATA.GET_GRANTED_DDL('OBJECT_GRANT',
USUARIO'); (muestra las sentencias GRANT q otorgan al usuario los privilegios
que tiene. Además de OBJECT_GRANT, se puede indicar SYSTEM_GRANT y
ROLE_GRANT).
PRACTICAS TEMA 3
• 3.1. Comprobar el tamaño del bloque de la BD. ¿Cuántas cachés de datos
hay definidas?. Definir la caché keep con 1M. Definir también una caché
para bloques de 4Kb, con 1M.
• 3.2. Crear un tablespace SEGAUTO con gestión automática de
segmentos.
• 3.3. Crear una tabla TABLA01 en el tablespace anterior, con una columna
VARCHAR2(1000). Insertar tres filas de forma que ocupe varias
extensiones. Borrar todas las filas con “delete” y comprobar las
extensiones de la tabla. Hacer “truncate table” y comprobar de nuevo el
espacio ocupado por la tabla.
• 3.4. Crear una tabla TABLA02 con una sola columna varchar2(100); y otra
llamada TABLA02COMPRI igual que la anterior, pero con compresión de
datos. Insertar 1000 filas en TABLA02 y, luego, esas mismas 1000 en
TABLA02COMPRI. ¿Cuántos bloques necesita cada tabla para almacenar
las mismas filas?
PRACTICAS TEMA 3
• 3.5. Crear tablespace TSP4K con tamaño de bloque de 4Kb. Crear una
tabla TABLA03, igual que TABLA01, y comprobar cuantos bloques ocupan
las dos y comparar los datos.
• 3.6. Comprobar los parámetros pga_aggregate_target,
workarea_size_policy y sort_area_size. ¿Se puede poner
pga_aggregate_target=0? ¿cómo desactivar pga_aggregate_target?
• 3.7. Crear una TABLA04 en el tablespace SEGAUTO, con cuatro
columnas: c1 char(2), c2 varchar2(10), c3 date y c4 number(10,2). Estimar
el tamaño medio de la fila, y el número medio de filas por bloque. insertar
100 filas en la tabla , calcular las estadísticas y comprobar los datos
calculados (número de filas, número de bloques y longitud media de la
fila).
• 3.8. Instalar el paquete UTL_MAIL y configurar el parámetro del init
smtp_out_server. Hacer una prueba de envío de correo con utl_mail.send.
TEMA 4
NUEVAS FUNCIONALIDADES DE
MONITORIZACIÓN Y AJUSTE
TEMA 4.
NUEVAS FUNCIONALIDADES DE
MONITORIZACIÓN Y AJUSTE.
• Nueva infraestructura.
• AWR (Automatic Workload Repository).
• Vistas AWR.
• ADDM (Automatic Database Diagnostic Monitor).
• DBMS_ADVISOR.
• DBMS_SQLTUNE.
• SEGMENT SHRINK.
• SEGMENT ADVISOR.
• UNDO ADVISOR.
NUEVA INFRAESTRUCTURA
• Nueva infraestructura = AWR + Time Model + ASH (El parámetro
STATISTICS_LEVEL debe valer TYPICAL u ALL).
• Automatic Workload Repository (AWR). Vistas v$ + volcado a disco, por defecto
cada 60min y máx 7 días (procesos MMON, MMNL). Mejor q STATSPACK.
– EXECUTE dbms_workload_repository.create_snapshot();
• Active Session History (ASH). Recopila muestras cada segundo de las sesiones
activas de V$SESSION: V$ACTIVE_SESSION_HISTORY,
DBA_HIST_ACTIVE_SESS_HISTORY.
• Nuevo “Time Model”: estadísticas y métricas relativas al tiempo consumido por
las sesiones.
– Time Model (“DB time”, “DB CPU”, etc): V$SYS_TIME_MODEL,
V$SESS_TIME_MODEL.
– Wait Classes: V$SYSTEM_WAIT_CLASS, V$SESSION_WAIT_CLASS.
– Metrics (cada 60seg): V$SYSMETRIC, V$SESSMETRIC, V$FILEMETRIC,
V$EVENTMETRIC, V$WAITCLASSMETRIC, V$METRICNAME.
– OS statistics. V$OSSTAT.
• Automatic Database Diagnostic Monitor (ADDM). En base a los datos recopilados
por AWR y ASH, identifica problemas y sus posibles causas, proporcionando
recomendaciones e indicando los beneficios q se obtendrán.
– $ORACLE_HOME/rdbms/admin/addmrpt.sql
Administración de Oracle 10g (Parte 2) NUEVAS FUNCIONALIDADES DE 58
AJUSTE Y MONITORIZACION
AUTOMATIC WORKLOAD
REPOSITORY (AWR)
• Snapshots. Config en DBA_HIST_WR_CONTROL. Ej de cambio a intervalo de 30días cada
30min (expresado en minutos y si intervalo=0 no se calculan más snapshots):
– DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(43200,30);
– DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range (22, 32); Borra rango
• Baselines. Pareja de snapshots (q ya no se borrarán).
– DBMS_WORKLOAD_REPOSITORY.create_baseline (210, 220, 'batch baseline');
Snapshots inicial y final, y nombre para el baseline
– DBMS_WORKLOAD_REPOSITORY.drop_baseline ( 'batch baseline', 'FALSE); Si
TRUE, borra los snaphosts asociados
• Informes AWR en $ORACLE_HOME/rdbms/admin (con salida en HTML o TEXTO):
– awrrpt.sql, pedirá formato salida (text o html), los snapshots inicial y final, y el nombre
del fichero del informe. Existe awrrpti.sql q permite seleccionar una instancia.
– awrsqrpt.sql, muestra estadísticas de una sentencia SQL para un rango de snapshots.
– awrddrpt.sql, compara atributos detallados de rendimiento y valores de configuración
entre dos períodos de tiempo.
• Informe ASH (V$ACTIVE_SESSION_HISTORY):
$ORACLE_HOME/rdbms/admin/ashrpt.sql.
• OEM. Incluye las tareas del administración del AWR. Acceso desde enlace
"Administración", seguido de "Repositorio de Carga de Trabajo Automática" bajo "Gestión
de Estadísticas". Permitiendo modificar la configuración de AWR y gestionar los snapshots.
VISTAS AWR
• Se puede forzar la creación de un snapshot, manualmente:
EXECUTE DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();
• Vistas AWR:
– V$ACTIVE_SESSION_HISTORY. Muestras de sesiones activas recopiladas cada
segundo (ASH).
– V$METRIC. Métricas recopiladas.
– V$METRICNAME. Tipos de métricas y agrupaciones de las mismas.
– V$METRIC_HISTORY. Histórico de métricas recopiladas.
– V$METRICGROUP. Grupos de métricas.
– DBA_HIST_ACTIVE_SESS_HISTORY. Histórico de ASH.
– DBA_HIST_BASELINE. Baselines.
– DBA_HIST_DATABASE_INSTANCE. Arranques de la BD.
– DBA_HIST_SNAPSHOT. Snapshots recopiladas.
– DBA_HIST_SQL_PLAN. Planes de ejecución de sentencias SQL.
– DBA_HIST_WR_CONTROL. Configuración del AWR.
Más información sobre AWR:
http://cursos.atica.um.es/oradoc102/server.102/b14211/autostat.htm#i27008
AUTOMATIC DATABASE
DIAGNOSTIC MONITOR (ADDM)
• Se activa por defecto (statistics_level = TYPICAL u ALL; se desactiva con BASIC).
• Informes. Entre dos snapshots del AWR. Su objetivo, al dar recomendaciones, es reducir la
estadística “DB time” (tiempo acumulado invertido por la BD para atender las peticiones de
usuarios, ver V$SYS_TIME_MODEL).
– $ORACLE_HOME/rdbms/admin/addmrpt.sql. Tb usando el paquete
DBMS_ADVISOR.
• Análisis de resultados. El informe estructura los problemas de rendimiento encontrados en
“FINDINGS”, indicando el porcentaje de impacto; y para cada uno nos da recomendaciones,
indicando qué hacer (“ACTION”) y el por qué (“RATIONALE”).
• Para el análisis de E/S, por defecto, se toma un valor de 10000 microsegundos para la lectura
de un bloque de la BD. Si calculamos el valor real para nuestra BD, podemos cambiarlo con:
EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER(
'ADDM', 'DBIO_EXPECTED', 8000);
• Vistas del DD:
– DBA_ADVISOR_TASKS: ejecuciones de ADDM (tareas) con su identificación.
– DBA_ADVISOR_LOG: log de tareas ADDM (parece estar incluido en el anterior).
– DBA_ADVISOR_RECOMMENDATIONS. Recomendaciones resultantes del análisis.
Ordenar por RANK (importancia) y ver BENEFIT.
– DBA_ADVISOR_FINDINGS. Problemas encontrados en el análisis.
• Más información sobre ADDM:
– “http://cursos.atica.um.es/oradoc102/server.102/b14211/diagnsis.htm#sthref433”
EJECUTAR ADDM CON
DBMS_ADVISOR
CREATE OR REPLACE FUNCTION run_addm(start_time IN DATE, end_time IN DATE )
RETURN VARCHAR2
IS
begin_snap NUMBER;
end_snap NUMBER;
tid NUMBER; Task ID
tname VARCHAR2(30); Task Name
tdesc VARCHAR2(256); Task Description
BEGIN
Busca los ids de los snapshots correspondientes al rango de fechas.
SELECT max(snap_id) INTO begin_snap FROM DBA_HIST_SNAPSHOT
WHERE trunc(end_interval_time, 'MI') <= start_time;
SELECT min(snap_id) INTO end_snap FROM DBA_HIST_SNAPSHOT
WHERE end_interval_time >= end_time;
Nombre de tarea = NULL y genera descripcion unica para la tarea.
tname := '';
tdesc := 'run_addm( ' || begin_snap || ', ' || end_snap || ' )';
Crea la tarea y la ejecuta.
DBMS_ADVISOR.CREATE_TASK('ADDM', tid, tname, tdesc );
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'START_SNAPSHOT', begin_snap );
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'END_SNAPSHOT' , end_snap );
DBMS_ADVISOR.EXECUTE_TASK(tname);
RETURN tname;
END;
OBTENER INFORME ADDM CON
DBMS_ADVISOR
Configura variables y columnas SQL*Plus necesarias para el informe.
SET PAGESIZE 0 LONG 1000000 LONGCHUNKSIZE 1000;
COLUMN get_clob FORMAT a80;
Ejecuta run_addm() con parámetros 7pm y 9pm del dia 20 de Octubre.
VARIABLE task_name VARCHAR2(30);
BEGIN
:task_name := run_addm( TO_DATE('19:00:00 20/10', 'HH24:MI:SS DD/MM'),
TO_DATE('21:00:00 20/10', 'HH24:MI:SS DD/MM'));
END;
/
Ejecuta GET_TASK_REPORT para obtener el texto del informe.
SELECT DBMS_ADVISOR.GET_TASK_REPORT(:task_name)
FROM DBA_ADVISOR_TASKS t
WHERE t.task_name = :task_name
AND t.owner = SYS_CONTEXT( 'userenv', 'session_user' );
Nota: la variable LONG de SQL*Plus debe asignarse a un valor suficiente
para mostrar el informe completo de ADDM, ya que la función
DBMS_ADVISOR.GET_TASK_REPORT devuelve un CLOB.
SQL TUNNING ADVISOR
• Asesor de Ajustes SQL
http://cursos.atica.um.es/oradoc102/server.102/b14211/sql_tune.htm
– Verifica la validez de las estadísticas y si es necesario genera estadísticas
auxiliares.
– Determina si es necesario crear estructuras de acceso: índices y/o vistas
materializadas.
• OEM: “Enlaces Relacionados” (abajo) > “Central de Asesores” > “Asesor de
Ajustes SQL” (bajo Asesores).
• Paquete DBMS_SQLTUNE (“
http://cursos.atica.um.es/oradoc102/appdev.102/b14258/d_sqltun.htm#i1010615”).
– Crear tarea de ajuste de SQL (DBMS_SQLTUNE.CREATE_TUNING_TASK)
– Ejecutar tarea de ajuste de SQL (DBSM_SQLTUNE.EXECUTE_TUNING_TASK)
– Generar informe correspondiente a la tarea
(DBMS_SQLTUNE.REPORT_TUNING_TASK).
– Generar script con las recomendaciones del informe
(DBMS_SQLTUNE.SCRIPT_TUNING_TASK).
– Vistas relacionadas:
• DBA_SQLTUNE_STATISTICS, DBA_SQLTUNE_BINDS, DBA_SQLTUNE_PLANS.
• V$SQL, V$SQLAREA, V$SQLSTATS, V$SQL_BINDS.
SQL TUNNING ADVISOR
DBMS_SQLTUNE
Seleccionar sentencias SQL q ya se han ejecutado:
Sentencias sql con más de 500 buffer gets.
SELECT sql_id, sql_text
FROM table(DBMS_SQLTUNE.SELECT_CURSOR_CACHE('buffer_gets > 500'))
ORDER BY sql_id;
Sentencias sql de miUsuario con más de 500 buffer gets.
FROM table(DBMS_SQLTUNE.SELECT_CURSOR_CACHE('buffer_gets > 500 and
parsing_schema_name = ''miUsuario''')) ORDER BY sql_id;
Sentencias sql que tardaron más de 5 segundos
FROM table(DBMS_SQLTUNE.SELECT_CURSOR_CACHE('elapsed_time > 5000000'))
ORDER BY sql_id;
Datos de una sentencia concreta.
SELECT *
FROM table(DBMS_SQLTUNE.SELECT_CURSOR_CACHE('sql_id =
''4rm4183czbs7j'''));
SQL TUNNING ADVISOR
DBMS_SQLTUNE
Diferentes formas de crear tareas de ajuste SQL.
variable stmt_task VARCHAR2(64);
Con el texto de la sentencia.
EXEC :stmt_task := DBMS_SQLTUNE.CREATE_TUNING_TASK(
sql_text => 'select quantity_sold from sales s, times t where
s.time_id = t.time_id and s.time_id = TO_DATE(''29/01/07'')');
Con el identificador (Sql_id en cursor cache)
EXEC :stmt_task := DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_id =>
'ay1m3ssvtrh24');
Limitando el tiempo de ajuste a 10 minutos
EXEC :stmt_task := DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_id =>
'ay1m3ssvtrh24', time_limit => 600);
Indicando un intervalo de snapshots del AWR
EXEC :stmt_task := DBMS_SQLTUNE.CREATE_TUNING_TASK(begin_snap => 1,
end_snap => 2, sql_id => 'ay1m3ssvtrh24');
SQL TUNNING ADVISOR
DBMS_SQLTUNE
Ejecuto la tarea de ajuste.
EXEC DBMS_SQLTUNE.EXECUTE_TUNING_TASK(:stmt_task);
Compruebo si la tarea ha terminado.
SELECT status FROM USER_ADVISOR_TASKS WHERE task_name = :stmt_task;
Genero el informe.
SET LONG 1000000 LONGCHUNKSIZE 100000 LINESIZE 100 PAGESIZE 10000
SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK(:stmt_task) FROM DUAL;
Genero el script para aplicar las correcciones sugeridas por el
informe anterior.
SELECT DBMS_SQLTUNE.SCRIPT_TUNING_TASK(:stmt_task) FROM DUAL;
Nota: Desde sqlplus es necesario hacer “set long 1000000” (puede q con
menos sea suficiente) para poder ver el clob completo devuelto por
dbms_sqltune.report_tuning_task y dbms_sqltune.script_tuning_task.
SEGMENT ADVISOR
Segment SHRINK
Esta operación compacta el contenido de un segmento y devuelve extensiones libres.
Para poder reorganizar las filas de una tabla hay q permitir q
puedan cambiar los rowids
ALTER TABLE mitabla ENABLE ROW MOVEMENT;
Reorganiza las filas de una tabla y todos sus segmentos (p.e. LOBS)
ALTER TABLE mitabla SHRINK SPACE CASCADE;
Reorganiza sólo un LOB
ALTER TABLE mitabla MODIFY LOB (milob) (SHRINK SPACE);
Reorganiza una sola partición de una tabla particionada
ALTER TABLE mitablapart MODIFY PARTITION mipart1 SHRINK SPACE;
Reorganiza un IOT y el segmento de overflow
ALTER TABLE mitablaiot SHRINK SPACE CASCADE;
Reorganiza sólo el segmento de overflow de un IOT
ALTER TABLE mitablaiot OVERFLOW SHRINK SPACE;
Libera las extensiones que estén vacías
ALTER TABLE mitabla DEALLOCATE UNUSED KEEP integer;
ALTER INDEX miindice DEALLOCATE UNUSED KEEP integer;
ALTER CLUSTER micluster DEALLOCATE UNUSED KEEP integer;
SEGMENT ADVISOR
Ejecución manual
Para ejecutarlo hacen falta los privilegios ADVISOR y CREATE JOB o CREATE ANY
JOB. Desde OEM: “Enlaces relacionados” (abajo) > “Central de Asesores” >
“Asesor de segmentos” (bajo “Asesores”). Manualmente:
variable id number;
declare
name varchar2(100);
descr varchar2(500);
obj_id number;
begin
name:='miTablaSegAdv';
descr:='Ejemplo con Segment Advisor';
dbms_advisor.create_task (advisor_name => 'Segment Advisor', task_id
=> :id, task_name => name, task_desc => descr);
dbms_advisor.create_object (task_name => name, object_type =>
'TABLE', attr1 => 'miUsuario', attr2 => 'miTabla', attr3 => NULL,
attr4 => NULL, attr5 => NULL, object_id => obj_id);
dbms_advisor.set_task_parameter(name, 'recommend_all', 'TRUE');
dbms_advisor.set_task_parameter(name, 'verbose', 'TRUE');
dbms_advisor.execute_task(name);
end;
/
SELECT STATUS FROM DBA_ADVISOR_TASKS WHERE TASK_ID=:id;
SEGMENT ADVISOR
Ver resultados
select af.task_name, ao.attr2 segname, ao.attr3 partition, ao.type,
af.message, af.more_info
from dba_advisor_findings af, dba_advisor_objects ao
where ao.task_id = af.task_id and ao.object_id = af.object_id and
af.task_id=:id;
(Genera la siguiente salida)
...
The free space in the object is less than 10MB.
Allocated Space:3145728: Used Space:3000902: Reclaimable Space :144826:
AUTOMATIC SEGMENT ADVISOR (ASA). Identifica segmentos candidatos a
“shrink”. No analiza todos los objetos de la BD. Examina las estadísticas de la BD
y muestras de segmentos, para seleccionar: tablespaces que se acercan a los
niveles críticos o de alerta, segmentos con más activiidad y segmentos que han
crecido más.
• Intervalo de ejecución de ASA: MAINTENANCE_WINDOW_GROUP (LV una vez
a partir de las 22h y hasta 6h; y S una vez a partir de las 0h hasta 0h del L)
• Vistas del ASA:
•DBA_AUTO_SEGADV_SUMMARY: ejecuciones de ASA.
•DBA_AUTO_SEGADV_CTL: objetos seleccionados para ser analizados.
• Más info: http://cursos.atica.um.es/oradoc102/server.102/b14231/schema.htm#CHDHBHAB
UNDO ADVISOR
DBMS_UNDO_ADV
Algunas funciones del paquete DBMS_UNDO_ADV:
FUNCTION BEST_POSSIBLE_RETENTION RETURNS NUMBER Con undo size actual
FUNCTION LONGEST_QUERY RETURNS NUMBER Query q mas ha tardado, en s.
FUNCTION REQUIRED_RETENTION RETURNS NUMBER Para query q mas tardó
FUNCTION REQUIRED_UNDO_SIZE RETURNS NUMBER Para actual undo_retention
Argument Name Type In/Out Default?

RETENTION NUMBER IN
FUNCTION UNDO_HEALTH RETURNS NUMBER
PROBLEM VARCHAR2 OUT
RECOMMENDATION VARCHAR2 OUT
RATIONALE VARCHAR2 OUT
RETENTION NUMBER OUT
UTBSIZE NUMBER OUT
FUNCTION UNDO_INFO RETURNS BOOLEAN
TABLE_SPACE_NAME VARCHAR2 OUT
TABLE_SPACE_SIZE NUMBER OUT
AUTO_EXTEND BOOLEAN OUT
UNDO_RETENTION NUMBER OUT
RETENTION_GUARANTEE BOOLEAN OUT
Nota: la info obtenida se calcula con datos desde último arranque.
Muchas funciones tienen versiones con parámetros fecha ini y fin.
PRACTICAS TEMA 4
• 4.1. Consultar las principales vistas dinámicas de la 10g relacionadas con el
AWR: V$OSSTAT, V$SYS_TIME_MODEL, V$SES_TIME_MODEL,
V$SYSMETRIC, V$SESSMETRIC, V$FILEMETRIC, V$EVENTMETRIC,
V$SYSTEM_WAIT_CLASS, V$SESSION_WAIT_CLASS,
V$WAITCLASSMETRIC.
• 4.2. Probar AWR.
• 4.3. Probar ASH.
• 4.4. Probar ADDM.
• 4.5. Probar SQL TUNING
• 4.6. Probar SEGMENT ADVISOR.
• 4.7. Probar UNDO_ADVISOR.
TEMA 5
MONITORIZACIÓN Y AJUSTE TRADICIONAL
TEMA 5.
MONITORIZACIÓN Y AJUSTE TRADICIONAL.
• Eventos de espera.
• Vistas dinámicas: información del sistema y de las sesiones.
• Ajuste de la SharedPool.
• Ajuste de la buffer cache.
• Ajuste de los buffers redo log.
• Ajuste del rollback.
• Ajuste del tablespace temporal.
• Ajuste de los checkpoints.
• Ajuste de las sentencias SQL.
• Ajuste de la CPU.
• Utilidad STATSPACK.
EVENTOS DE ESPERA
• V$EVENT_NAME. Lista de posibles esperas.
• V$SYSTEM_EVENT. Esperas totales por evento desde arranque de BD.
• V$SESSION_EVENT. La misma información anterior, por sesión.
• V$SESSION_WAIT. Sesiones que están esperando actualmente.
– Para recibir valores en WAIT_TIME poner TIMED_STATISTICS=TRUE.
• Eventos más comunes:
– free buffer waits: DBWR escribe poco a menudo (subir nº de checkpoints).
– latch free: contención en latches (verificar V$LATCH).
– buffer busy waits: hay contención E/S (ajustar E/S o distribuir datos).
– db file sequential read: hay contención E/S (ajustar E/S o distribuir datos)
– db file scattered read: igual anterior, pero multibloque (ajustar E/S o distribuir datos).
– db file parallel write: checkpoints muy espaciados (subir su número).
– undo segment tx slot: faltan segmentos de rollback (añadir más).
– undo segment extension: demasiadas extensiones dinámicas (ampliaciones y
reducciones) de los segmentos de rollback (ajustar tamaño).
Nota: la lista completa de eventos está en el manual “Oracle10g Database Reference”.
http://cursos.atica.um.es/oradoc102/server.102/b14237/waitevents.htm#i968375
Administración de Oracle 10g (Parte 2) AJUSTE Y MONITORIZACIÓN DE LA 75
INSTANCIA
VISTAS DINAMICAS
INFORMACION DEL SISTEMA
• AWR (>=10g). Ver diapositivas anteriores, de este mismo tema.
• Base de datos
– V$SYSTEM_EVENT: esperas totales por evento.
– V$SYSSTAT: estadísticas básicas de la instancia.
– V$SGASTAT: estado de uso de la SGA. Ver tb V$SGAINFO (>=10g).
– V$WAITSTAT: estadísticas de contención.
– V$PROCESS: procesos oracle.
– V$SESSION: sesiones en curso.
– V$SORT_SEGMENT: estado de uso de los segmentos temporales.
– V$PGASTAT: estadísticas de uso de la PGA.
• Memoria
– V$BUFFER_POOL_STATISTICS: estadísticas de la caché de datos.
– V$LIBRARYCACHE: Rendimiento de la Library Caché.
– V$DB_OBJECT_CACHE: Objetos que hay en la Library Caché.
– V$SQLAREA: Sentencias SQL y estadísticas asociadas.
– V$ROWCACHE: Rendimiento de la Dictionary Caché.
INSTANCIA
VISTAS DINAMICAS
INFORMACION DEL SISTEMA
• E/S
– V$FILESTAT: Estadísticas de E/S de los ficheros de datos.
– V$TEMPSTAT: Estadísticas de E/S de los ficheros temporales.
• Contención
– V$LATCH: Estadísticas de latches.
– V$WAITSTAT: Estadísticas de contención.
– V$ROLLSTAT: Estadísticas de los segmentos de rollback.
– V$UNDOSTAT: Estadísticas de undo.
INSTANCIA
VISTAS DINAMICAS
INFORMACION DE SESIONES
• Sesión (datos de las sesiones actualmente en curso)
– V$SESSION: sesiones.
– V$SESSTAT: estadísticas de cada sesión.
– V$SESSION_EVENT: eventos de cada sesión.
– V$SESSION_WAIT: esperas de cada sesión.
– V$LOCK: bloqueos actuales y peticiones de bloqueo.
– V$ACCESS: objetos bloqueados y las sesiones que los están usando.
– V$TRANSACTION: transacciones en curso.
– V$OPEN_CURSOR: cursores abiertos y compilados.
– V$SORT_USAGE: segmentos temporales en uso
– V$SESS_IO: estadísticas de E/S de cada sesión.
Nota: la lista completa de vistas dinámicas está en el manual “Oracle10g Database Reference”.
http://cursos.atica.um.es/oradoc102/server.102/b14237/toc.htm
INSTANCIA
AJUSTE DE LA SHAREDPOOL
INTRODUCCION
• Oracle guarda las sentencias SQL y los paquetes en la Sharedpool, una caché
que presenta los siguientes problemas:
– La unidad de reserva de espacio no es constante, variando desde unos cuantos bytes
hasta muchos Kb.
– No toda la memoria puede ser liberada cuando el usuario termina con ella; ya que se
trata de una caché que pretende maximizar la compartición.
– No dispone de una zona en disco para paginar.
• Posibles síntomas de problemas de ajuste de la Shared Pool:
– Contención en los latches “%library cache%” (V$LATCH).
– Contención en el latch “%shared pool%” (V$LATCH).
– Altos tiempos de CPU para compilar, “parse time cpu” (V$SYSSTAT).
– Muchas recargas (reloads) en V$LIBRARYCACHE.
– Muchas llamadas de compilación, “parse count%” (V$SYSSTAT).
– Frecuentes errores ORA04031, debidos a la fragmentación.
Nota: los latches son microbloqueos necesarios para proteger las operaciones en la SGA
(SharedPool, LibraryCache, RedoBuffer, etc). Son puntos potenciales de contención.
INSTANCIA
SENTENCIAS SQL
• La ejecución de una sentencia SQL tiene varias fases: análisis sintáctico y
semántico (compilación), y cálculo del plan de ejecución:
– En la “library cache” se guardan las sentecias SQL ya compiladas.
– En la “sql area” se guardan los planes de ejecución de cada una de ellas.
• Al compilar una sentencia SQL, hay que distinguir entre “hard” y “soft” parse:
– Hard Parse: la sentencia SQL no existe en la SharedPool (Library Cache). Es
costoso en términos de CPU y latches.
– Soft Parse: la sentencia SQL ya existe en la SharedPool y puede usar una
versión de la misma.
• Dos sentencias SQL son iguales si tienen el mismo texto (incluyendo espacios en
blanco y mayúsculas/minúsculas); y además:
– Los nombres de objetos deben apuntar a los mismo objetos reales.
– El modo del optimizador (optimizer goal) debe ser el mismo.
– Los nombres, tipos y longitudes de las variables bind deben ser los mismos.
– El entorno NLS (idioma y país) debe ser el mismo.
INSTANCIA
GENERALIDADES
• Que siempre haya espacio libre en la SharedPool, puede significar que sobra; y
que haya poco o nada no supone un problema si el rendimiento es bueno:
SELECT * FROM V$SGASTAT WHERE NAME = 'free memory' AND POOL = 'shared pool';
POOL NAME BYTES

shared pool free memory 693036
• En la library cache, el pinhitratio >= 95% (V$LIBRARYCACHE) y lo más cercano
a 1 (100%). Reloads debe ser casi 0.
• En la row cache (V$ROWCACHE) el ratio getmisses/gets <=15%.
• Las aplicaciones OLTP deben usar “bind variables” (no para DSS).
Nota: en DSS es mejor darle mucha información al CBO q compartir el código.
• Usar DBMS_SHARED_POOL.KEEP (dbmspool.sql) para fijar paquetes muy
usados en la SharedPool (como SYS.STANDARD).
• Haciendo “flush” se puede eliminar la fragmentación (ora4031):
alter system flush shared_pool;
Nota: puede bajar rendimiento hasta que objetos vuelven a la caché. No usar cuando BD tiene
mucha carga. No descarga paquetes “fijados”, ni sentencias ya compiladas de sesiones en curso.
INSTANCIA
LIBRARY CACHE
• V$LIBRARYCACHE. Estadísticas de la Library Caché.
– GETS (peticiones) – Cada petición de ejecutar una sentencia SQL (¿está el
SQL en memoria?).
– PINS (ejecuciones) – Cada petición de metadatos de un SQL (¿está el SQL
ya compilado?, si lo está se ejecuta). PINHITRATIO debe ser casi 1.
– RELOADS (recompilaciones) – Cada petición de metadatos (PIN) que no los
encuentra en memoria pq los ha sacado el algoritmo LRU (ejecuciones que
requieren recompilar sentencia). Debe ser casi 0.
• Los NAMESPACE que se corresponden con sentencias SQL y PL/SQL son: SQL
AREA, TABLE/PROCEDURE, BODY y TRIGGER.
• Para hacer que RELOADS sea casi 0, podemos subir shared_pool_size, pero
además, para aprovechar dicho incremento, subiremos también open_cursors.
• Si RELOADS es casi 0 y siempre tenemos una cantidad significativa de la
SharedPool libre, bajaremos shared_pool_size.
INSTANCIA
ROW CACHE
• V$ROWCACHE. Estadísticas de la Row Caché (Diccionario de Datos).
– PARAMETER: tipo de petición.
– GETS: peticiones a la caché, del tipo en cuestión.
– GETMISSES: peticiones fallidas que generan E/S.
– MODIFICATIONS: actualizaciones de la caché.
SELECT parameter, sum(gets), sum(getmisses)
, 100*sum(gets getmisses) / sum(gets) pct_succ_gets
, sum(modifications) updates
FROM V$ROWCACHE WHERE gets > 0 GROUP BY parameter;
PARAMETER SUM(GETS) SUM(GETMISSES) PCT_SUCC_GETS UPDATES

dc_object_ids 16942 537 96.8303624 173
dc_objects 7534 966 87.1781258 414
...
• Debemos procurar que ratios >= 85%.
• Podemos ver el ratio general con:
SELECT (SUM(GETS GETMISSES FIXED)) / SUM(GETS) "ROWCACHE" FROM V$ROWCACHE;
ROWCACHE

.982133497
INSTANCIA
RESTO DE VISTAS DINAMICAS
• En V$SHARED_POOL_ADVICE podemos ver si nos interesa redimensionar la
SharedPool (el parámetro STATISTICS_LEVEL debe valer ALL o TYPICAL, no BASIC).
select SHARED_POOL_SIZE_FOR_ESTIMATE SIZE_ESTIMATE,
SHARED_POOL_SIZE_FACTOR SIZE_FACTOR,
ESTD_LC_TIME_SAVED_FACTOR PARSE_SAVED_FACTOR
from v$shared_pool_advice;
SIZE_ESTIMATE SIZE_FACTOR PARSE_SAVED_FACTOR

4 .5 .9806
8 1 1
16 2 1.0194
• V$SGASTAT. Detalle de cada una de las partes de la SharedPool.
• V$SQLAREA. Estadísticas sobre todos los cursores compartidos, incluyendo el
texto inicial (1000 caracteres) de cada sentencia. El uso de esta vista consume
muchos latches (V$SQL no).
• V$SQLTEXT. Texto completo de las sentencias, en varias líneas (filas).
• V$DB_OBJECT_CACHE. Objetos en caché, incluyendo paquetes, funciones,
procedimientos, tablas, índices, sinónimos, secuencias, vistas, triggers, etc.
INSTANCIA
COMPARTIR CODIGO SQL
• Nos fijaremos el objetivo “compilar una vez y ejecutar muchas”.
• Detectar sentencias similares que usan literales (V$SQLAREA):
SELECT substr(sql_text,1,40) "SQL", count(*), sum(executions) "TotExecs"
FROM v$sqlarea
WHERE executions < 5
GROUP BY substr(sql_text,1,40) HAVING count(*) > 30 ORDER BY 2;
Nota: los valores 5, 40 y 30 son ejemplo para detectar sentencias que se ejecutan poco
(<5), cuyos 40 primeros caracteres son iguales en muchos casos (>30). Luego veríamos si
es posible convertirlas en una o en unas pocas.
• Desde 9i, con CURSOR_SHARING=SIMILAR (antes sólo FORCE), Oracle
determina qué literales puede sustituir por variables bind sin afectar el plan de
ejecución. Si afectase al plan de ejecución no se hace el cambio (si se usa
FORCE sí).
• Caché privada sesión (SharedPool): al compilar una sentencia primero se busca
en ella. Empezar con SESSION_CACHED_CURSORS=50 (valor alto puede
provocar ora4031, comprobar % de uso). Util con Oracle Forms cuando los
forms se abren y cierran con frecuencia.
INSTANCIA
AJUSTE DE LA SHARED POOL
LATCHES DE LA LIBRARY CACHE
Si alguno de los latches está provocando la mayoría de “sleeps”, entonces hay un
problema. Hay que tener en cuenta que estos datos se acumulan desde el arranque
de la BD, y por tanto no muestran problemas “intermitentes”.
select name,gets,misses,sleeps from v$latch
where name like 'library%';
NAME GETS MISSES SLEEPS

library cache 97155739 42902 12272
library cache load lock 11705 0 0
“misses” son fallos al intentar coger un “latch”, y “sleeps” son aquellos fallos que provocan que la sesión
correspondiente se ponga a “dormir” (lo cual implica una espera).
Para detectar el proceso en cuestión (sólo saldrá algo si lo pillamos en el momento):
select a.name,pid from v$latch a , V$latchholder b
where a.addr=b.laddr and a.name = 'library cache%';
INSTANCIA
AJUSTE DE LA SHARED POOL
ESPERAS POR LATCHES
Consultando V$SESSION_WAIT durante un periodo de “lentitud”, se puede

determinar si hay un problema con “latches” y, en tal caso, con qué “latch” concreto.
Si hay más de 3 ó 4 procesos esperando , puede haber un problema.
select count(*) number_of_waiters
from v$session_wait w, v$latch l
where w.wait_time = 0 and w.event = 'latch free' and
w.p2 = l.latch# and l.name like 'library%';
También es interesante mirar sólo en v$session_wait para ver si hay alguna otra
causa de “lentitud”.
select * from v$session_wait
where event != 'rdbms ipc message' and
event not like '%Net%' and sid > 5;
INSTANCIA
AJUSTE DE LA BUFFER CACHE
GENERALIDADES
• Oracle guarda copias de los bloques de datos en la “buffer caché” (caché de

datos). Puede haber copias de diferentes puntos del tiempo y también bloques
“dirty” (modificados pero que no se han llevado a disco).
• Cuando la caché se llena, Oracle moverá parte de sus bloques a disco (usa
algoritmo LRU sobre la lista, o listas, de bloques no “dirty”), de modo que si
posteriormente son accedidos tendrán que volver a recuperarse del disco.
• El latch “cache buffers lru chain” serializa operaciones sobre la(s) lista(s) LRU.
• El proceso DBWR es el responsable de llevar los bloques “dirty” a disco.
Cualquier sesión puede leer los bloques de la caché.
• Podemos calcular el ratio de eficiencia (hit ratio) de la caché de datos
consultando V$SYSSTAT. Se recomienda que sea >80% para aplicaciones
OLTP; pero esto no asegura un buen rendimiento (tb es muy importante el uso
de índices selectivos).
• En aplicaciones DSS (datawarehouse) se pueden tener ratios mucho menores.
INSTANCIA
HIT RATIO
• Consultando V$SYSSTAT:
select 100*(1 (f1 f2 f3)/(r1 + r2 f2 f3)) HitRatio
from (select value f1 from v$sysstat where name='physical reads'),
(select value f2 from v$sysstat where name='physical reads direct'),
(select value f3 from v$sysstat where name='physical reads direct (lob)'),
(select value r1 from v$sysstat where name='consistent gets'),
(select value r2 from v$sysstat where name='db block gets');
• Si usamos varias cachés (keep, recycle, etc), a partir de
V$BUFFER_POOL_STATISTICS:
SELECT name,
100*(1(physical_reads / (consistent_gets + db_block_gets))) HIT_RATIO
FROM V$BUFFER_POOL_STATISTICS
WHERE ( consistent_gets + db_block_gets ) !=0;
• Si activamos DB_CACHE_ADVICE, podremos consultar en
V$DB_CACHE_ADVICE posibles estimaciones para la “buffer caché”.
select name,size_for_estimate,size_factor,ESTD_PHYSICAL_READ_FACTOR
from v$db_cache_advice;
NAME SIZE_FOR_ESTIMATE SIZE_FACTOR ESTD_PHYSICAL_READ_FACTOR

DEFAULT 4 1 1
DEFAULT 8 2 .3228
INSTANCIA
OBJETIVOS
• Hay que evitar lo siguiente:
– Básicamente las lecturas innecesarias, pues llevan bloques a la caché y, por tanto,
provocan la salida de otros (que luego tendrán q volver a leerse de disco). Cuidado con
los índices poco o nada selectivos y los “full scan” de tablas.
– Contención en el latch 'cache buffers lru chain' (V$LATCH).
– Mucho tiempo empleado en la espera "write complete waits"
(V$BUFFER_POOL_STATISTICS).
– Mucho tiempo empleado en la espera "free buffer waits"
(V$BUFFER_POOL_STATISTICS).
• Factores que puede mejorar el rendimiento del DBWR:
– Atributos de los discos físicos (stripe size, velocidad, etc).
– Raw devices vs File Systems.
– Distribuir las escrituras sobre más discos/ficheros.
– Usar E/S asíncrona cuando esté disponible. Además, si es necesario
arrancar varios procesos DBWR con DB_WRITER_PROCESSES (al menos
uno para cada 8 cpus o grupo de cpus).
– Si no hay E/S asíncrona, paralelizar E/S del DBWR con DBWR_IO_SLAVES.
– Usar las diferentes cachés (keep, recycle, etc).
INSTANCIA
AJUSTE DEL REDO LOG BUFFER
GENERALIDADES
• La Caché de Redo (Redo Log Buffer) es un buffer circular en la SGA, que guarda
información (redo entries) sobre todos los cambios hechos en la BD, que se
utilizará sólo para recuperar la BD, si es necesario. Las “redo entries” van
ocupando espacio contiguo, de forma secuencial, en la Caché de Redo.
• El LGWR es el encargado de escribir las “redo entries” de la cache de redo, en el
fichero (o grupo) redo log activo. Una vez hecho ésto, el proceso de usuario
puede reutilizar dichas entradas.
• Hay determinadas operaciones en las que resulta interesante “desactivar” el
redo, ya que se pueden reconstruir fácilmente; como son crear un índice o crear
una tabla “as select”. La opción a usar en estos casos es NOLOGGIN.
• Dimensionar la Caché de Redo (log_buffer) por encima de 3M, no sirve de nada;
ya que el LGWR vuelca la caché a disco cuando ésta se llena 1/3 ó máximo 1M.
• El tamaño óptimo se puede sacar de la columna OPTIMAL_LOGFILE_SIZE de la
vista V$INSTANCE_RECOVERY.
INSTANCIA
AJUSTE DEL REDO LOG BUFFER
DETECTAR PROBLEMAS
• Contención en latches (V$LATCH) de redo. Si el ratio de MISSES/GETS o el de
IMMEDIATE_MISSES/(IMMEDIATE_GETS+IMMEDIATE_MISSES) > 1% es
porque hay contención:
SELECT name, gets, misses, immediate_gets, immediate_misses
FROM v$latch
WHERE name in ('redo allocation', 'redo copy');
Si hay contención en “redo allocation”, reduciremos uso de redo (NOLOGIN) o subiremos
el tamaño de la Caché de Redo (log_buffer). Si CPUs>16 se puede subir
LOG_PARALLELISM (de 2 a 8).
Si es en “redo copy”, y CPUs > 1, se puede subir _log_simultaneous_copies (oculto).
• Contención en peticiones de espacio de redo en disco. Se refiere a la estadística
“redo log space requests" de la vista V$SYSSTAT, que refleja el nº de esperas al
escribir el redo a disco, pq se ha llenado el fichero redolog. Ese valor debe ser
(casi) cero. Si, por el contrario, dicho nº va incrementándose continuamente,
habrá que comprobar checkpoints y log_switchs. Se debe hacer q los
checkpoints coincidan con los log switchs (cada 1530 minutos aprox.).
INSTANCIA
AJUSTE DEL ROLLBACK
GENERALIDADES
• Si usamos undo automático (>=9i), podemos consultar V$UNDOSTAT: una fila
cada 10 minutos. La columna SSOLDERRCNT muestra los errores ORA1555.
• En los segmentos de rollback (RS) se guardan las imágenes de los datos,
anteriores a las actualizaciones, por si es necesario deshacer las transacciones
(TR) en cuestión; y para mantener la consistencia en lectura. Oracle va
asignando los RS mediante “round robin”.
• Cada TR sólo puede usar un RS para almacenar sus registros de undo.
• Varias TR pueden escribir en la misma extensión.
• Un RS se organiza en forma de anillo, de forma que la “cabeza” del RS nunca
machacará una extensión ocupada por la “cola” del mismo.
• Las extensiones de un RS se usarán en orden. Si no puede usar la siguiente,
reservará una nueva y la insertará en el anillo (reduce el rendimiento).
• Son importantes tanto el tamaño como la duración de una TR. Una TR q sólo
modifica 1 byte durante largo tiempo, puede provocar q un RS se extienda si
dicha extensión se necesita más adelante.
• Para cada RS, debemos asegurarnos de q la cabeza no alcance a la cola muy rápido, pues
hará q el RS se extienda.
INSTANCIA
AJUSTE DEL ROLLBACK
OPTIMIZACION
• El tamaño de los RS depende directamente de la actividad de las TR. Nos
debemos fijar en la actividad “normal” de la BD para ajustar.
• Calcular un segmento de rollback por cada 4 transacciones concurrentes, con
extensiones del mismo tamaño (un mínimo de 20 por RS).
• Fijar “optimal” de modo q el 90% de las transacciones quepan en un RS sin
extenderse. Una vez fijado “optimal”, dejar espacio libre en el tablespace para
que, además, se pueda atender a la transacción más grande.
• Para prevenir “ORA1555 Snapshot too old” (lo provocan las grandes consultas),
cuantos más RS mejor (y no sólo más grandes) y del mismo tamaño, y que las
transacciones sean lo más cortas posibles. Si no hay updates a la vez que
“grandes selects”, no hay ora1555.
• Comprobar la contención en RS consultando V$WAITSTAT.
SELECT CLASS, COUNT FROM V$WAITSTAT
WHERE CLASS like '%undo%';
Si hay en “undo header”, es q no hay bastantes RS (crear más).
INSTANCIA
AJUSTE DE SEGMENTOS DE SORT
GENERALIDADES
• Cuando ocurre una ordenación, Oracle reserva tantas extensiones como

necesite. Finalizada la ordenación, las extensiones se marcan como libres, pero
no se liberan.
• Un mismo segmento de sort puede ser compartido por varias ordenaciones.
• La primera ordenación crea el segmento (si no existía) y las demás añadirán
extensiones si lo necesitan.
• Se utiliza una zona de la SGA, fuera de la Shared Pool, llamada Sort Extent Pool;
sincronizada usando el latch “sort extent pool” (V$LATCH). Si tiene contención,
subir el tamaño de la extensión por defecto del tablespace.
INSTANCIA
AJUSTE DE SEGMENTOS DE SORT
OPTIMIZACION
• Si hay contención en el latch “sort extent pool” (V$LATCH), subiremos el tamaño
de la extensión por defecto del tablespace.
• Si además, también se producen esperas pq hay muchas ordenaciones
concurrentes, se debe incrementar el parámetro SORT_AREA_SIZE, de forma
que una mayor cantidad de ordenaciones se hagan en memoria.
• El tamaño de la extensión debe ser igual a SORT_AREA_SIZE (o múltiplo).
• Desde Oracle9i, usando el parámetro PGA_AGGREGATE_TARGET, me olvido
de sort_area_size (sesiones con servidores dedicados).
PGA_AGGREGATE_TARGET indica el tamaño máximo que sumarán las PGAs
(mínimo 10M).
• Podemos monitorizar los segmentos de sort con:
– V$SORT_SEGMENT muestra los segmentos temporales. Si las columnas
ADDED_EXTENTS y FREED_EXTENTS muestran mucha actividad, añadiremos más
espacio al tablespace. Si MAX_SORT_SIZE indica ordenaciones de gran tamaño, es
posible q necesitemos un tablespace dedicado para ellas (sólo para las grandes).
– V$SORT_USAGE muestra el uso actual de los segmentos temporales.
INSTANCIA
AJUSTE DE LOS CHECKPOINTS
• Un checkpoint es el evento que sincroniza los bloques de datos en memoria con
los ficheros de datos en disco (los escribe el DBWR).
• Indicaciones de ajuste:
– El proceso CKPT puede mejorar significativamente el rendimiento.
– Asignando el parámetro LOG_CHECKPOINTS_TO_ALERT a TRUE
podremos ver en el fichero alert.log los tiempos de comienzo y fin de los
checkpoints.
– Si el valor de LOG_CHECKPOINT_INTERVAL es mayor que el tamaño del
fichero redolog, los checkpoints ocurrirán cuando Oracle haga un “log switch”.
– Lo ideal es que los checkpoints sólo sucedan cuando se hace “log switch”:
• log_checkpoint_interval=0
• log_checkpoint_timeout=0.
• FAST_START_MTTR_TARGET=0 (desactiva “fast recovery instance”).
INSTANCIA
AJUSTE DE LAS CONSULTAS SQL
• Si observamos que nuestras consultas SQL van “lentas”, debemos comprobar:
– El valor de OPTIMIZER_MODE. Ej: si CHOOSE, probar RULE.
ALTER SYSTEM SET OPTIMIZER_MODE=RULE | FIRST_ROWS | ALL_ROWS | CHOOSE;
– ¿Están los índices de las tablas afectadas en estado “valid”?
SELECT * FROM DBA_OBJECTS WHERE OBJECT_TYPE='INDEX' AND STATUS!='VALID';
– ¿Hay alguna otra consulta SQL “pesada” en ejecución?
• Si, además, estamos usando el optimizador por costes (CBO):
– ¿Están calculadas las estadísticas para las tablas y los índices en cuestión?
ANALYZE TABLE | INDEX nombre COMPUTE | ESTIMATE STATISTICS;
Para tablas grandes “Estimate 30%” suele ser casi igual a “compute”.
– Si hay estadísticas, ¿se generaron con “compute” o con “estimate”?
• Para el ajuste de sentencias SQL utilizaremos las siguientes herramientas:
– AUTOTRACE de Sql*Plus:
SQL> SET AUTOT[RACE] {OFF | ON | TRACE[ONLY]} [EXP[LAIN]] [STAT[ISTICS]]
– TKPROF sobre un fichero de traza:
SQL> alter session set sql_trace=true;
SQL> Select ... ;
SQL> alter session set sql_trace=false;
$ tkprof tracefile outputfile [explain=usu/pw] [sys=no]
INSTANCIA
AJUSTE DE LA CPU
• Porcentaje máximo de ocupación de CPU = 90%.
• Porcentaje máximo de procesamiento OS/usuario = 40/60%.
• Si hay varias CPUs, la carga debe estar balanceada.
• Probar con MTS si se degrada el uso de CPU por muchas sesiones concurrentes
(MTS es mejor si hay muchas conexiones a la BD).
• Parámetros que limitan el número de procesos y de sesiones:
– PROCESSES. Número máximo de procesos en la instancia.
– SESSIONS. Por defecto 1.1*PROCESSES; sin embargo si usamos MTS habrá que
subirlo.
INSTANCIA
UTILIDAD “STATSPACK”
• Desde 10g, con la introducción del AWR no es necesario usar STATSPACK.
• STATSPACK es una utilidad para recoger estadísticas que permiten detectar
problemas de rendimiento. Además, mejora la utilidad que había anteriormente,
UTLBSTAT/UTLESTAT.
• Se trata de un conjunto de scripts SQL y PL/SQL. El script de instalación de la
herramienta crea un usuario, PERFSTAT. Los datos recopilados por statspack se
guardarán en tablas.
• La documentación de la herramienta están en
$ORACLE_HOME/rdbms/admin/spdoc.txt.
• STATSPACK trabaja con el concepto “snapshot” para identificar una colección de
datos recopilados en un momento del tiempo, a los que asocia un identificador
único, snap_id. Es necesario recopilar datos en forma de snapshots antes de
poder obtener un informe de rendimiento.

INSTANCIA
INSTALAR “STATSPACK”
• Necesita un tablespace con al menos 100Mb, a ser posible “manejado
localmente”.
• La instalación crea un usuario PERFSTAT que será el propietario de todos los
objetos y el código pl/sql que se cree. Debemos asegurarnos que el tablespace
por defecto de este usuario es el que hemos creado, y tener cuidado con su
tablespace temporal por defecto (no sería mala idea asignarle uno especial).
• Para la instalación debemos conectarnos a la BD como SYSDBA, y lanzar el
script $ORACLE_HOME/rdbms/admin/spcreate.sql, que nos pedirá la clave para
el nuevo usuario, así como el tablespace por defecto y el tablespace temporal.
Este script, de forma automática, llama a otros tres: spcusr.sql, spctab.sql,
spcpkg.sql. Debemos comprobar si se producen errores en los ficheros
spcusr.lis, spctab.lis, spcpkg.lis.
• Si hay errores y tenemos que repetir la instalación, primero desinstalaremos con
el script spdrop.sql.

INSTANCIA
RECOGIENDO DATOS CON
“STATSPACK”
• La forma más sencilla de crear un snapshot es conectando como usuario
PERFSTAT y ejecutando el procedimiento STATSPACK.SNAP. Previamente es
conveniente activar el parámetro time_statistics (TRUE). Este primer snapshot
nos servirá de base comparativa para los próximos snapshots que tomemos.
• Al crear un snapshot, con STATSPACK.SNAP, se pueden indicar parámetros
para, por ejemplo, indicar el nivel de detalle de las estadísticas (i_snap_level), e
incluso una sesión sobre la que recabar estadísticas adicionales (i_session_id).
Para establecer un snapshot inicial (baseline) se recomienda i_snap_level=10.
• Podemos borrar un rango de snapshots con sppurge.sql. Si queremos borrar
todos los snapshots, podemos hacerlo con sptrunc.sql (¡ojo!, que lo borrará todo,
puede ser interesante hacer un export previo del usuario PERFSTAT).

INSTANCIA
OBTENIENDO INFORMES CON
“STATSPACK”
• Podemos obtener un informe sobre el rendimiento general de la instancia con
spreport.sql (desde el usuario PERFSTAT). Nos pedirá el intervalo de snapshots
(inicial y final) y el nombre del fichero de salida.
• Si localizamos una sentencia SQL por su “hash_value”
(V$SQLAREA.HASH_VALUE), podemos generar un informe sobre ella con el
script sprepsql.sql; que nos pedirá el intervalo de snapshots y el hash_value de la
sentencia.

INSTANCIA
RESUMEN DE SCRIPTS
“STATSPACK”
Instalación (como usuario SYSDBA):
spcreate.sql > Instala STATSPACK ejecutando a su vez los scripts:
spcusr.sql > Crea el usuario PERFSTAT
spctab.sql > Crea las tablas
spcpkg.sql > Crea el paquete statspack
spdrop.sql > Desinstala STATSPACK ejecutando a su vez los scripts:
spdtab.sql > Borra las tablas
spdusr.sql > Borra el usuario PERFSTAT
Informes (como usuario PERFSTAT):
spreport.sql > Genera un informe general del rendimiento de la instancia
sprepins.sql > Genera un informe para la BD y la instancia indicados
sprepsql.sql > Genera un informe para la sentencia SQL cuyo Hash Value se indique
spauto.sql > Permite automatizar la recolección de estadísticas (usando dbms_job)
Mantenimiento (como usuario PERFSTAT):
sppurge.sql > Permite borrar un rango de snapshots
sptrunc.sql > Vacía (con truncate) todas las tablas, borrando todos los snapshots
spuexp.par > Es un fichero de parámetros para exportar el usuario PERFSTAT

INSTANCIA
VISTAS DEL DD
• V$SYSSTAT: estadísticas generales del sistema.
• V$SGASTAT: estado de uso de las diferentes partes de la SGA.
• V$SYSTEM_EVENT: estadísticas de eventos de espera a nivel de sistema.
• V$SESSION_WAIT: sesiones que están en espera actualmente.
• V$SESSION_EVENT: estadísticas de eventos de espera por sesión.
• V$SESSTAT: estadísticas generales por sesión.
• V$LIBRARYCACHE: ratios de la Library Caché (Sentencias SQL y PL/SQL).
• V$ROWCACHE: ratios de la Row Caché (Diccionario de Datos).
• V$PGASTAT: estado de la PGA.
• V$BUFFER_POOL_STATISTICS: estadísticas de la caché de datos.
• V$DB_OBJECT_CACHE: objetos que hay en la Library Caché.
• V$LATCH: latches.
• V$ROLLSTAT: estadísticas de uso de los segmentos de rollback.
• V$UNDOSTAT: estadísticas de uso de los segmentos de rollback.
• V$FILESTAT: estadísticas de E/S a nivel de fichero.
• V$SESS_IO: estadísticas de E/S a nivel de sesión.
• V$SORT_SEGMENT: estadísticas de uso de los segmentos temporales.
• V$SORT_USAGE: áreas de sort actualmente en uso.
• Obtener IP: Select SYS_CONTEXT('USERENV','IP_ADDRESS') FROM DUAL;

INSTANCIA
PRACTICAS TEMA 5
• 5.1. Revisar eventos del sistema y comprobar los más significativos. Comprobar
evento “latch free” por sesiones. Comprobar sesiones esperando por el evento
“db file sequential read”. Comprueba el parámetro TIMED_STATISTICS.
• 5.2. Revisa las estadísticas del sistema más significativas. Comprueba el
tamaño medio de la PGA de cada sesión. Revisa las lecturas lógicas y físicas y
calcula el ratio de E/S. Comparar el uso de CPU para “SQL del sistema” (acceso
al DD) sobre el total.
• 5.3. Ver el eatado de ocupación de las partes más significativas de la Shared
Pool.
• 5.4. Comprobar la contención en latches de la Shared Pool y Library Cache.
• 5.5. Comprobar el pinhitratio de la Library Caché, asi como los reloads. Verificar
el espacio libre de la Shared Pool, y el valor de open_cursors.
• 5.6. Ver el ratio de la Row Cache.
• 5.7. Comprobar si el sistema recomienda ampliar la SharedPool.

INSTANCIA
PRACTICAS TEMA 5
• 5.8. Detectar sentencias similares que usan literales. Verificar el parámetros
cursor_sharing y session_cached_cursors. Asignar cursor_sharing=similar.
• 5.9. Instalar el paquete DBMS_SHARED_POOL. Comprobar paquetes que se
pueden “fijar” en la SharedPool y hacerlo.
• 5.10. Comprobar sentencias que ocupan mucha memoria (>=10% de
SharedPool).
• 5.11. Calcular el ratio de eficiencia de la Caché de Datos. Comprobar el
parámetro db_cache_advice. Consultar si Oracle recomienda incrementar la
Caché de Datos. Comprobar si hay contención en el latch “cache buffers lru
chain”. Ver si hay esperas del tipo “write complete waits” o “free buffer waits”.

INSTANCIA
PRACTICAS TEMA 5
• 5.12. Comprobar el tamaño de la Cache de Redo. Ver si hay contención en los
latches de redo. Verificar la estadística “redo log space requests”.
• 5.13. Comprobar los segmentos de rollback ONLINE. Verificar las extensiones
que tiene cada uno, así como el espacio total y libre del tablespace que los
contiene. Ver si hay contención en segmentos de rollback.
• 5.14. Instalar la utilidad STATSPACK. Crear snapshots y generar informe.

INSTANCIA
APENDICE A.
Recursos Oracle en Internet.
• www.orafaq.org (Underground Oracle FAQs)
– Sitio no oficial sobre Oracle (FAQs, foros, artículos, scripts, etc).
• otn.oracle.com (Oracle Tecnology Network)
– Descargas de sw, documentación, foros, artículos, scripts, etc. Registro gratuito.
• otn.oracle.com/oramag (Oracle Magazine)
– Revista Oracle Magazine.
• www.oracle.com (Web de Oracle)
– Portal oficial de Oracle.
• metalink.oracle.com (Soporte Técnico Oracle)
– Soporte técnico para usuarios con contrato de mantenimiento.
• asktom.oracle.com (Gurú de Oracle)
– Artículos y preguntas a uno de los gurús de Oracle
• www.oraclebase.com (Web de Tim Hall)
– Artículos muy interesantes sobre Oracle 10g (incluida instalación)
• www.puschitz.com (Web de Werner Puschitz)
– Artículos muy buenos sobre instalación de Oracle sobre Linux
• www.dbazine.com (Revista electrónica)
– Revista electrónica mensual especializada en Oracle
• www.ixora.com.au (Otro gurú)
– Para mejorar el rendimiento de Oracle sobre Unix
APENDICE B.
Arquitectura Oracle
Servidor Oracle
– Instancia
• Procesos Background
– DBWR
– LGWR
– SMON
– PMON
– CKPT – Base de datos
– Opcionales: RECO, ARCH, Dispatchers, • Ficheros de datos
Servers, etc.
• Ficheros redo log
– Nuevos 10g: MMAN, MMON, MMNL,
PSP0. • Ficheros de control
• System Global Area (SGA)
– Shared Pool
» Library Cache
» Dictionary Cache
– Database Buffer Cache
– Redo Log Buffer
– Java Pool y Large Pool.
APENDICE B.
Arquitectura Oracle
APENDICE C.
Estructura Física/Lógica de la BD
• Estructura lógica de la BD • Estructura física de la BD
– Tablespaces – Ficheros de datos
• Segmentos • Bloques del SO
– Extensiones
» Bloques Oracle
APENDICE C.
Estructura Física/Lógica de la BD
APENDICE D.
Conexión a la BD y consulta
1. El proceso de usuario envía la
sentencia SQL al proceso servidor.
2. El proceso servidor busca la
sentencia SQL en la Shared Pool. Si 3
no la encuentra, la compila y la 1
guarda en la Shared Pool. 2
3. El proceso servidor accede a los 4
datos en la Database Buffer Cache. 4
Si no los encuentra, accede
directamente a los ficheros de datos,
llevando los datos a la Database
Buffer Cache.
4. El proceso servidor devuelve los 1
datos al proceso de usuario q inició
la conexión.
3
APENDICE E.
Actualización de datos
En primer lugar se repiten las fases 1 (envío de
la sentencia), 2 (compilación) y 3 (acceso a
los datos) vistas en el proceso de consulta. 4
4. Se guarda una copia del dato (antes del 5
cambio) en un segmento de Rollback (por si 3 6
se deshace la transacción).
5. Se modifican los bloques de datos en la 1 2
Database Buffer Caché. El DBWR (de
forma asíncrona) los llevara a los ficheros
de datos cuando suceda un checkpoint. 7 7
6. Se guardan en la caché de Redo las "redo
entries" (vector de cambios de cada bloque
modificado) necesarias para registrar el
cambio q se va a hacer (el LGWR vuelca el
buffer al fichero redo log activo, cuando se
hace commit o cada 3 segundos).
6
7. El proceso servidor devuelve el número de 1 5
filas actualizadas al proceso de usuario.
APENDICE F.
Novedades Oracle 9i
• undo tablespace y gestión automática de undo
• database default temporary tablespace
• drop tablespace INCLUDING CONTENTS AND DATAFILES;
• SGA dinámica: sga_max_size, db_cache_size
• db_nk_cache_size (cachés con tamaño de bloque no estándard)
• desaparece “connect internal”, ahora es “connect / as sysdba”
• spfile (fichero de parámetros binario, mantenido con “alter system
set ...”)
• OMF
• tablespaces con gestión automática de segmentos (create
tablespace ... segment space management auto;)
• compresión de los segmentos de datos (create table ... compress;)
APENDICE G.
Novedades Oracle 10g
• Tablespace SYSAUX (permite dejar en el SYSTEM sólo el DD)
• alter tablespace nombre1 RENAME TO nombre2;
• create BIGFILE tablespace tsbig1 ... size 50G; (hasta 8Eb)
• SGA_TARGET (ASMM: gestión automática del tamaño de las partes de la SGA)
• alter table t1 SHRINK SPACE CASCADE; (antes “alter table t1 enable row movement;”)
• "create temporary tablespace ts1 ... TABLESPACE GROUP g1;" y "alter tablespace t2
TABLESPACE GROUP g1;.
• Data Pump (exp/imp todavía existen): expdp/impdp muy eficiente para grandes cantidades
de datos
• Flashback Database (db_recovery_file_dest, db_recovery_file_dest_size,
db_flashback_retention_size). Muy útil para auditoría: ALTER DATABASE FLASHBACK on;
ALTER TABLESPACE nombre FLASHBACK ON; FLASHBACK TABLE nombre TO SCN
numero; FLASHBACK TABLE nombre TO TIMESTAMP '20060303 12:05:00';;
• DROP DATABASE; (sólo montada)
• ALTER DATABASE DEFAULT TABLESPACE nombre;
• ALTER SYSTEM FLUSH BUFFER_CACHE;
• Automatic Storage Management (ASM).
• ALTER SYSTEM QUIESCE RESTRICTED | UNQUIESCE (tb SUSPEND y RESUME).
• DROP TABLE nombre PURGE; (DBA_RECYCLEBIN, recyclebin=on, SHOW RECYCLEBIN,
FLASHBACK TABLE nombreTablaBorrada TO BEFORE DROP; PURGE TABLE
NombreTabla;)
• ADDM. DBA_OUTSTANDING_ALERTS, DBA_ALERT_HISTORY, V$ALERT_TYPES.
Script $ORACLE_HOME/rdbms/admin/addmrpt.sql.
APENDICE H.
SOPORTE DE GLOBALIZACIÓN
• Conjunto de caracteres para la base de datos.
• Lenguaje y territorio. Variable de entorno NLS_LANG.
• Parámetros NLS. NLS_SESSION_PARAMETERS.
– NLS_TERRITORY
– NLS_LANGUAGE
– NLS_DATE_LANGUAGE
• El conjunto de caracteres para la BD a utilizar en España, es el
WE8ISO8859P15 (que incluye el símbolo del euro).
• La variable de entorno NLS_LANG, permite indicar (desde la aplicación
cliente que accede a Oracle) tanto el juego de caracteres a utilizar,
como el país y el idioma:
– export NLS_LANG=SPANISH_SPAIN.WE8ISO8859P15
APENDICE H.
NLS_SESSION_PARAMETERS
Para consultar las variables NLS asociadas a una sesión:
SQL> select * from nls_session_parameters;
PARAMETER VALUE

NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS P .,
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DDMONRR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DDMONRR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZH:TZM
NLS_TIMESTAMP_TZ_FORMAT DDMONRR HH.MI.SSXFF AM TZH:TZM
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
Se pueden cambiar con “ALTER SESSION SET variable=valor;”
APENDICE H.
NLS_TERRITORY Y NLS_LANGUAGE
El país (NLS_TERRITORY) lleva asociado un formato de fecha, y el lenguaje
(NLS_LANGUAGE) se refiere al idioma en que nos responde Oracle.
SQL> SELECT SYSDATE FROM DUAL;
SYSDATE

30MAR05
SQL> ALTER SESSION SET NLS_TERRITORY=SPAIN;
Session altered.
SQL> SELECT SYSDATE FROM DUAL;
SYSDATE

30/03/05
SQL> ALTER SESSION SET NLS_LANGUAGE=SPANISH;
Sesion modificada.
APENDICE H.
NLS_DATE_LANGUAGE
Podemos modificar el idioma de la fecha con NLS_DATE_LANGUAGE:
SQL> SELECT TO_CHAR(SYSDATE,
'DD/MON/YYYY','NLS_DATE_LANGUAGE=SPANISH') FROM DUAL;
TO_CHAR(SYS

20/DIC/2004
SQL> SELECT
TO_CHAR(SYSDATE,'DD/MON/YYYY','NLS_DATE_LANGUAGE=AMERICAN') FROM
DUAL;
TO_CHAR(SYS

20/DEC/2004

CursoDBA10g2 Parte1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CursoDBA10g2 Parte1

Uploaded by

Copyright:

Available Formats

Administración de Oracle 10g (Parte 2)

• Cabecera: información general del

Consultando V$SESSION_WAIT durante un periodo de “lentitud”, se puede

• Oracle guarda copias de los bloques de datos en la “buffer caché” (caché de

• Cuando ocurre una ordenación, Oracle reserva tantas extensiones como

Administración de Oracle 10g (Parte 2) AJUSTE Y MONITORIZACIÓN DE LA 100

Administración de Oracle 10g (Parte 2) AJUSTE Y MONITORIZACIÓN DE LA 101

Administración de Oracle 10g (Parte 2) AJUSTE Y MONITORIZACIÓN DE LA 102

Administración de Oracle 10g (Parte 2) AJUSTE Y MONITORIZACIÓN DE LA 103

Administración de Oracle 10g (Parte 2) AJUSTE Y MONITORIZACIÓN DE LA 104

Administración de Oracle 10g (Parte 2) AJUSTE Y MONITORIZACIÓN DE LA 105

Administración de Oracle 10g (Parte 2) AJUSTE Y MONITORIZACIÓN DE LA 106

Administración de Oracle 10g (Parte 2) AJUSTE Y MONITORIZACIÓN DE LA 107

Administración de Oracle 10g (Parte 2) AJUSTE Y MONITORIZACIÓN DE LA 108

You might also like