CursoDBA10g2_parte1

Administración de Oracle 10g (Parte 2)

© Juan Luis Serradilla Amarilla y Francisco Fernández Martínez 2004 – 2008


Francisco Fernández Martínez ([email protected])Juan Luis Serradilla Amarilla ([email protected])

Universidad de Murcia

Este documento electrónico puede ser descargado libre y gratuitamente desde Internet para su ejecución e

impresión, sólo para fines educativos y/o personales, respetando su integridad y manteniendo los créditos de

los autores en el pie de página.Queda por tanto prohibida su venta.


© Juan Luis Serradilla Amarilla y Francisco Fernández Martínez 2004 2008

2

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.



3

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.



4

TEMA 1

INSTALACIÓN DE ORACLE10g



5

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.



6

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


http://www.oracle.com/technology/software/products/database/oracle10g/index.html

http://www.oracle.com/pls/db102/homepage



7

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.




8

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).




9

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)


http://www.oracle.com/technology/support/metalink/content.html



10

PARÁMETROS DEL KERNELValores 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).




11

PARÁMETROS DEL KERNELEjemplo 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


http://www.oracle-base.com/articles/10g/OracleDB10gR2InstallationOnFedora3.php



12

Paquetes necesariosFEDORA CORE 3 Linux

# De Fedora Core 3 Disk 1cd /media/cdrom/Fedora/RPMSrpm Uvh setarch1*rpm Uvh tcl8*rpm Uvh compatlibstdc++8*

# De Fedora Core 3 Disk 2cd /media/cdrom/Fedora/RPMSrpm Uvh xorgx11deprecatedlibs6*rpm Uvh openmotif2*rpm Uvh compatdb4*

# De Fedora Core 3 Disk 3cd /media/cdrom/Fedora/RPMSrpm Uvh compatlibstdc++devel8*rpm Uvh compatgcc8*rpm Uvh compatgccc++8*rpm Uvh libaio0*




13

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




14

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).


http://www.oracle.com/technology/pub/articles/smiley_10gdb_install.html



15

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:– El sw de Oracle 10g R2 ya la lleva activada. Se puede comprobar con:

# ps fe|grep dbw|grep i curso50oracle 22540 1 0 Jan08 ? 00:00:08 ora_dbw0_CURSO50# lsof p 22540|grep libaiooracle 22540 oracle mem REG 253,0 2628 1966157 /usr/lib/libaio.so.1.0.1

– Para activarla a nivel de una BD, asignar el parámetro del init:filesystemio_options = setall

– Ejecutar, si es necesario, 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.htmlINSTALACIÓN DE ORACLE10g

http://www.oracle.com/technology/deploy/security/pdf/twp_security_checklist_db_database.pdf

http://www.oracle.com/technology/deploy/security/index.html



16

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


http://otn.oracle.com/deploy/security/alerts.html



17

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 /nologSQL*Plus: Release 10.2.0.2.0 Production on Tue Jan 2 12:59:46 2007Copyright (c) 1982, 2005, Oracle. All Rights Reserved.SQL> connect / as sysdbaConnected.

– Comprobar el Listener Sql*Net$ lsnrctl statusLSNRCTL for Linux: Version 10.2.0.2.0 Production on 02JAN2007 13:00:42Copyright (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”




18

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.




19

TEMA 2

DISEÑO Y CREACIÓN DE UNA BASE DE DATOS



20

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).



21

DISEÑO DE LA BASE DE DATOSContiendas 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).

DISEÑO Y CREACIÓN DE UNA BD



22

DISEÑO DE LA BASE DE DATOSOrganizació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.




23

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 filename74097968 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.




24

VER MEMORIA EN LINUX

• La memoria libre (y la usada) la podemos ver con “free m”.$ free m total used free shared buffers cachedMem: 4041 3992 49 0 152 2487/+ buffers/cache: 13531353 2688Swap: 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 estado0x6abd8a34 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 filename74097968 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 COMMAND14560 ? Ss 0:00 0 72361 116542 13492 0.3 oracleCURSO70 (DESCRIPTION=(LOCAL=YES)14594 ? Ss 0:00 0 72361 117034 25832 0.6 oracleCURSO70 (DESCRIPTION=(LOCAL=YES)14626 ? Ss 0:00 1 72361 116510 15168 0.3 oracleCURSO70 (DESCRIPTION=(LOCAL=YES)




25

DIMENSIONAR LA SGASharedPool 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




26

DIMENSIONAR LA SGAShared 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 0large 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 COMPLETEshared 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.




27

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 %idle18:30:00 all 0,20 0,00 0,06 0,20 99,5418:40:00 all 0,16 0,00 0,17 0,12 99,54Media: 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).




28

DIMENSIONAR FICHEROSRedo 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).




29

DIMENSIONAR FICHEROSSystem, 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




30

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.




31

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.0background_dump_dest = /u01/app/oracle/admin/CURSOxy/bdumpcore_dump_dest = /u01/app/oracle/admin/CURSOxy/cdumpuser_dump_dest = /u01/app/oracle/admin/CURSOxy/udumpmax_dump_file_size = 10240 # tamaño máximo fichero traza de 5Mcontrol_files = (/u02/oradata/CURSOxy/control1.ctl,

/u03/oradata/CURSOxy/control2.ctl)undo_management = auto # Gestión automática de Rollbackundo_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 SGAdb_cache_size = 0 # Oracle asignará el tamaño automáticamenteshared_pool_size = 0 # Oracle asignará el tamaño automáticamentelarge_pool_size = 0java_pool_size = 0log_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=EXCLUSIVEnls_territory=spainnls_language=spanish




32

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).




33

connect / as sysdbastartup nomountCREATE DATABASE "CURSOxy" maxdatafiles 254 maxinstances 1 maxlogfiles 32 character set WE8ISO8859P15DATAFILE '/u02/oradata/CURSOxy/system01.dbf' SIZE 260M AUTOEXTEND ON NEXT 10M EXTENT MANAGEMENT LOCALSYSAUX 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 10MDEFAULT TABLESPACE USERS DATAFILE '/u02/oradata/CURSOxy/users01.dbf' SIZE 10MDEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE '/u03/oradata/CURSOxy/temp01.dbf' SIZE 10M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64Klogfile '/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

EJEMPLO CON “CREATE DATABASE”




34

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;




35

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.




36

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).




37

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”.




38

TEMA 3

ESTRUCTURAS DE ALMACENAMIENTO



39

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.



40

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.




41

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 (a nivel de partición no): 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.




42

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).



43

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.




44

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.




45

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;”.




46

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).




47

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.




48

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.




49

METODOS DE ACCESO A DATOSINDICES 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.




50

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;




51

ENVIAR CORREO DESDE ORACLEPaquete 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.sqlSQL> @$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','[email protected]',null,null,'Prueba desde Oracle 10g','La fecha actual es '||to_char(sysdate,'dd/mm/yyyy hh24:mi:ss'))

PL/SQL procedure successfully completed.




52

ENCOLAR Y SUSPENDER LA BDQuiesce 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;...




53

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).




54

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?




55

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.




56

TEMA 4

NUEVAS FUNCIONALIDADES DE MONITORIZACIÓN Y AJUSTE



57

TEMA 4.NUEVAS FUNCIONALIDADES DE MONITORIZACIÓN Y AJUSTE.

• Nueva infraestructura.• AWR (Automatic Workload Repository).• Vistas AWR.• ADDM (Automatic Database Diagnostic Monitor).• DBMS_ADVISOR.• SQL Tuning Advisor.• Segment Shrink.• Segment Advisor.• UNDO Advisor.



58

NUEVA INFRAESTRUCTURA

NUEVAS FUNCIONALIDADES DE AJUSTE Y MONITORIZACION

• 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 activas en llamadas a la BD (consultas/actualizaciones).– 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



59

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.



60

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



61

AUTOMATIC DATABASE DIAGNOSTIC MONITOR (ADDM)


• Se activa por defecto (statistics_level = TYPICAL u ALL; se desactiva con BASIC).• Informes. Entre dos snapshots del AWR. Da recomendaciones para reducir la estadística

“DB time” (V$SYS_TIME_MODEL) o tiempo total acumulado por la BD para atender las consultas/actualizaciones de las sesiones activas (“http://download.oracle.com/docs/cd/B19306_01/server.102/b28051/tdppt_method.htm#CIHCDGCI”).– $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”

http://download.oracle.com/docs/cd/B19306_01/server.102/b28051/tdppt_method.htm#CIHCDGCI



62

EJECUTAR ADDM CON DBMS_ADVISOR


CREATE OR REPLACE FUNCTION run_addm(start_time IN DATE, end_time IN DATE ) RETURN VARCHAR2IS begin_snap NUMBER; end_snap NUMBER; tid NUMBER; Task ID tname VARCHAR2(30); Task Name tdesc VARCHAR2(256); Task DescriptionBEGIN 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;



63

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.



64

SQL TUNING 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.

http://cursos.atica.um.es/oradoc102/server.102/b14211/sql_tune.htm



65

SQL TUNNING ADVISORDBMS_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.SELECT sql_id, sql_text 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 segundosSELECT sql_id, sql_text 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'''));



66



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 minutosEXEC :stmt_task := DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_id =>

'ay1m3ssvtrh24', time_limit => 600);

Indicando un intervalo de snapshots del AWREXEC :stmt_task := DBMS_SQLTUNE.CREATE_TUNING_TASK(begin_snap => 1, end_snap => 2, sql_id => 'ay1m3ssvtrh24');



67



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 10000SELECT 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.



68

SEGMENT ADVISORSegment 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 rowidsALTER 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 LOBALTER TABLE mitabla MODIFY LOB (milob) (SHRINK SPACE); Reorganiza una sola partición de una tabla particionadaALTER TABLE mitablapart MODIFY PARTITION mipart1 SHRINK SPACE; Reorganiza un IOT y el segmento de overflowALTER TABLE mitablaiot SHRINK SPACE CASCADE; Reorganiza sólo el segmento de overflow de un IOTALTER TABLE mitablaiot OVERFLOW SHRINK SPACE;

Libera las extensiones que estén vacíasALTER TABLE mitabla DEALLOCATE UNUSED KEEP integer;ALTER INDEX miindice DEALLOCATE UNUSED KEEP integer;ALTER CLUSTER micluster DEALLOCATE UNUSED KEEP integer;



69

SEGMENT ADVISOREjecució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;



70

SEGMENT ADVISORVer 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

http://cursos.atica.um.es/oradoc102/server.102/b14231/schema.htm#CHDHBHAB



71

UNDO ADVISORDBMS_UNDO_ADV


Algunas funciones del paquete DBMS_UNDO_ADV:FUNCTION BEST_POSSIBLE_RETENTION RETURNS NUMBER Con undo size actualFUNCTION 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 INFUNCTION UNDO_HEALTH RETURNS NUMBER PROBLEM VARCHAR2 OUT RECOMMENDATION VARCHAR2 OUT RATIONALE VARCHAR2 OUT RETENTION NUMBER OUT UTBSIZE NUMBER OUTFUNCTION 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.



72

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.




73

TEMA 5

MONITORIZACIÓN Y AJUSTE TRADICIONAL



74

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.



75

EVENTOS DE ESPERA

AJUSTE Y MONITORIZACIÓN DE LA INSTANCIA

• 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



76

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é.



77

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.



78

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

http://cursos.atica.um.es/oradoc102/server.102/b14237/toc.htm



79

AJUSTE DE LA SHAREDPOOLINTRODUCCION


• 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.



80

AJUSTE DE LA SHAREDPOOLSENTENCIAS 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.



81

AJUSTE DE LA SHAREDPOOLGENERALIDADES


• 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.



82

AJUSTE DE LA SHAREDPOOLLIBRARY 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.



83

AJUSTE DE LA SHAREDPOOLROW 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 173dc_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



84

AJUSTE DE LA SHAREDPOOLRESTO 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.



85

AJUSTE DE LA SHAREDPOOLCOMPARTIR 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.



86

AJUSTE DE LA SHARED POOLLATCHES 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 12272library 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%';



87

AJUSTE DE LA SHARED POOLESPERAS 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;



88

AJUSTE DE LA BUFFER CACHEGENERALIDADES


• 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.



89

AJUSTE DE LA BUFFER CACHEHIT RATIO


• Consultando V$SYSSTAT:select 100*(1 (f1 f2 f3)/(r1 + r2 f2 f3)) HitRatiofrom (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 1DEFAULT 8 2 .3228



90

AJUSTE DE LA BUFFER CACHEOBJETIVOS


• 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).



91

AJUSTE DEL REDO LOG BUFFERGENERALIDADES


• 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.



92

AJUSTE DEL REDO LOG BUFFERDETECTAR 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.).



93

AJUSTE DEL ROLLBACKGENERALIDADES


• 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.



94

AJUSTE DEL ROLLBACKOPTIMIZACION


• 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).



95

AJUSTE DE SEGMENTOS DE SORTGENERALIDADES


• 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.



96

AJUSTE DE SEGMENTOS DE SORTOPTIMIZACION


• 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.



97

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”).



98

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]



99

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.



100

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.



101

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.



102

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).



103

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.



104

RESUMEN DE SCRIPTS “STATSPACK”


Instalación (como usuario SYSDBA):spcreate.sql > Instala STATSPACK ejecutando a su vez los scripts:

spcusr.sql > Crea el usuario PERFSTATspctab.sql > Crea las tablasspcpkg.sql > Crea el paquete statspack

spdrop.sql > Desinstala STATSPACK ejecutando a su vez los scripts:spdtab.sql > Borra las tablasspdusr.sql > Borra el usuario PERFSTAT

Informes (como usuario PERFSTAT):spreport.sql > Genera un informe general del rendimiento de la instanciasprepins.sql > Genera un informe para la BD y la instancia indicadossprepsql.sql > Genera un informe para la sentencia SQL cuyo Hash Value se indiquespauto.sql > Permite automatizar la recolección de estadísticas (usando dbms_job)

Mantenimiento (como usuario PERFSTAT):sppurge.sql > Permite borrar un rango de snapshotssptrunc.sql > Vacía (con truncate) todas las tablas, borrando todos los snapshotsspuexp.par > Es un fichero de parámetros para exportar el usuario PERFSTAT



105

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;




106

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.




107

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”.




108

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.




109

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



110

APENDICE B.Arquitectura Oracle

Servidor Oracle– Instancia

• Procesos Background– DBWR– LGWR– SMON– PMON– CKPT– Opcionales: RECO, ARCH, Dispatchers,

Servers, etc.– Nuevos 10g: MMAN, MMON, MMNL,

PSP0.• System Global Area (SGA)

– Shared Pool» Library Cache» Dictionary Cache

– Database Buffer Cache– Redo Log Buffer– Java Pool y Large Pool.

– Base de datos• Ficheros de datos• Ficheros redo log• Ficheros de control



111

APENDICE B.Arquitectura Oracle



112

APENDICE C.Estructura Física/Lógica de la BD

• Estructura física de la BD– Ficheros de datos

• Bloques del SO

• Estructura lógica de la BD– Tablespaces

• Segmentos– Extensiones

» Bloques Oracle



113

APENDICE C.Estructura Física/Lógica de la BD



114

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 no la encuentra, la compila y la guarda en la Shared Pool.

3. El proceso servidor accede a los datos en la Database Buffer Cache. 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 datos al proceso de usuario q inició la conexión.

2

3

4

1

1

3

4



115

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. Se guarda una copia del dato (antes del cambio) en un segmento de Rollback (por si se deshace la transacción).

5. Se modifican los bloques de datos en la Database Buffer Caché. El DBWR (de forma asíncrona) los llevara a los ficheros de datos cuando suceda un checkpoint.

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).

7. El proceso servidor devuelve el número de filas actualizadas al proceso de usuario.

2

3

7

1

1

3

7

4

5

5 6

6



116

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;)



117

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.



118

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



119

APENDICE H.NLS_SESSION_PARAMETERSPara consultar las variables NLS asociadas a una sesión:

SQL> select * from nls_session_parameters;PARAMETER VALUE NLS_LANGUAGE AMERICANNLS_TERRITORY AMERICANLS_CURRENCY $NLS_ISO_CURRENCY AMERICANLS_NUMERIC_CHARACTERS P .,NLS_CALENDAR GREGORIANNLS_DATE_FORMAT DDMONRRNLS_DATE_LANGUAGE AMERICANNLS_SORT BINARYNLS_TIME_FORMAT HH.MI.SSXFF AMNLS_TIMESTAMP_FORMAT DDMONRR HH.MI.SSXFF AMNLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZH:TZMNLS_TIMESTAMP_TZ_FORMAT DDMONRR HH.MI.SSXFF AM TZH:TZMNLS_DUAL_CURRENCY $NLS_COMP BINARY

Se pueden cambiar con “ALTER SESSION SET variable=valor;”



120

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;SYSDATE30MAR05

SQL> ALTER SESSION SET NLS_TERRITORY=SPAIN;Session altered.

SQL> SELECT SYSDATE FROM DUAL;SYSDATE30/03/05

SQL> ALTER SESSION SET NLS_LANGUAGE=SPANISH;Sesion modificada.



121

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(SYS20/DIC/2004

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

TO_CHAR(SYS20/DEC/2004

CursoDBA10g2_parte1

Documents

Transcript of CursoDBA10g2_parte1