cursodba10g_atica_completo4dpp

Administración y Ajuste de Oracle 10g

© Juan Luis Serradilla Amarilla y Francisco Fernández Martínez 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.



2

TEMARIO

• Arquitectura de la Base de Datos

• Arranque y parada

• Fichero de control

• Redo log

• Tablespaces

• Segmentos de rollback

• Usuarios, roles, privilegios y perfiles

• Jobs

• Auditoría

• Copias de seguridad y recuperación



3

OBJETIVOS

• Conocer la Arquitectura Oracle.

• Saber arrancar y parar una base de datos Oracle.

• Gestionar los ficheros Redo log.

• Gestionar el fichero de control.

• Gestionar tablespaces, incluyendo temporales y undo.

• Gestionar segmentos de rollback.

• Gestionar usuarios, roles, privilegios y perfiles.

• Gestionar jobs.

• Gestionar la auditoría del sistema gestor de base de datos.

• Realizar copias de seguridad y recuperación de la base de datos.



4

TEMA 1

ARQUITECTURA DE LA BASE DE DATOS



5

TEMA 1.ARQUITECTURA DE LA BD

• Servidor oracle

• Instancia

• Conexión a la Base de datos

• Memoria: SGA (Automatic Shared Memory Management >=10g) y PGA

• Procesos: procesos de usuario, servidores y background

• Estructura lógica: tablespaces, segmentos, extensiones, bloques

• Arquitectura OFA

• Usuarios administradores de la BD: sys y system

• Fichero de autenticación (orapw)



6

SERVIDOR ORACLE

Servidor Oracle:• Instancia

Oracle • Base de datos

OracleInstancia

Oracle: • System Global

Area (SGA)• Procesos

BackgroundBase de datos

Oracle: • Ficheros de

Datos• Fichero(s) de

Control • Ficheros Redo

Log.



7

INSTANCIA

• La integran los procesos “background” y la SGA• Abre una y sólo una BDO, y permite acceder a ella.

Nota: con Oracle Real Application Cluster (RAC), más de una instancia usarán la misma BD.

• En la máquina donde reside el servidor Oracle, la variable ORACLE_SID identifica a la instancia con la que estamos trabajando.

ARQUITECTURA DE LA BD Administración y Ajuste de Oracle 10g


8

CONEXIÓN A LA BD

• Para poder conectarnos a una BDO, necesitamos una serie devariables en el entorno del usuario del S.O. desde el que realizaremos la conexión. En el caso de unix/linux:

– ORACLE_HOME. Localización del sw Oracle a utilizar.– ORACLE_SID. BD, asociada al ORACLE_HOME, a la que vamos a

conectarnos. Tiene sentido sólo en un SBD.– PATH=$PATH:$ORACLE_HOME/bin. Programas Oracle– LD_LIBRARY_PATH=$ORACLE_HOME/lib. Localización de las librerías

compartidas (Linux/Unix).– NLS_LANG=spanish_spain. Idioma del cliente (opcional).

• Proceso de usuario: la ejecución de la aplicación que permite al usuario iniciar la conexión; por ejemplo, sql*plus.

• Proceso servidor: se crea en el SBD cuando el usuario se conecta a la BD, y es el que realmente interactúa con la BD.

• Una conexión de un proceso de usuario al SBD es una sesión en la BD (puede haber varias del mismo usuario). Se inicia cuando el usuario se valida contra la BD y termina cuando el usuario se desconecta.

• Desconectar una sesión con “ALTER SYSTEM DISCONNECT SESSION 'sid, serial#' [POST_TRANSACTION] [IMMEDIATE];”. Destruye el servidor dedicado (o el circuito virtual si MTS).

ARQUITECTURA DE LA BD



9

CONEXIÓN A LA BD: procesos


Conexión con Servidor Dedicado

Conexión con Servidor Compartido (MTS)



10

SGA (System Global Area)y Automatic Shared Memory Management


• log buffer, buffer cachés keep y recycle, y buffer cachés con tamaño de bloque especial; aunque consumen espacio de SGA_TARGET, se fijan manualmente (LOG_BUFFER, DB_KEEP_CACHE_SIZE, DB_RECYCLE_CACHE_SIZE, DB_nK_CACHE_SIZE). El resto (punto anterior) los dejaremos a cero (tb podemos darles valores, q serán tomados como mínimos).

• V$SGAINFO: tamaño componentes SGA (tb gránulo y libre). V$SGA_DYNAMIC_COMPONENTS.

• V$SGA_TARGET_ADVICE: recomendaciones sobre SGA_TARGET.

• Zona de memoriacompartida, que se reserva al arrancar la instancia. Su tamaño es dinámico (>= 9i) y limitado por el parámetro SGA_MAX_SIZE.

• SGA_TARGET (>=10g) fija el tamaño de la SGA y activa el reparto automático de su espacio entre: sga fija, shared pool, large pool, java pool, buffer caché y streams pool. El resto se ajustan manualmente.

SGA (sga_target, sga_max_size)

SHAREDPOOL

BUFFERCACHE

REDOBUFFER(log_buffer)

STREAMSPOOL

JAVAPOOL

LARGEPOOL



11

SGA (System Global Area)y ASMM• La SGA está formada por gránulos (espacio contiguo de memoria virtual), que

serán de 4M para SGAs <= 1Gb (en 9i <= 128M), y de 16M en caso contrario (ver V$SGAINFO). Los componentes de la SGA (buffer cache, sharedpool, largepool, javapool, etc) variarán su tamaño usando en base a gránulos. Al arrancar, se asignan al menos tres gránulos (uno para la SGA fija que incluye los redo buffers, otro para la buffer cache y uno más de sharedpool); y cada componente seguirá reservando tantos gránulos como necesite.

• La SGA está compuesta, fundamentalmente, por tres estructuras de memoria: shared pool, database buffer cache y redo log buffer. Además, existen tres estructuras de memoria que, opcionalmente, pueden estar presentes en la SGA: large pool, streams pool y java pool. Los parámetros del fichero de inicialización que más afectan al tamaño de la SGA son: DB_CACHE_SIZE (>=9i, antiguo db_block_buffer en <=8i), LOG_BUFFER, SHARED_POOL_SIZE.

• Ejemplo de parámetros de inicialización para usar gestión automática de SGA (SGA_TARGET):

sga_max_size = 80Msga_target = 70Mdb_cache_size = 0shared_pool_size = 0large_pool_size = 0java_pool_size = 0streams_pool_size = 0log_buffer = 1048576



12

SGA: Shared Pool

• Formada por dos estructuras dememoria gestionadas por algoritmos LRU:

– library cache– dictionary cache

• Su tamaño viene determinado por el parámetro shared_pool_size, del init.ora (sin que la SGA supere sga_target (sga_max_size en 9i)). Desde 10g se recomienda usar sga_target, dejando shared_pool_size a cero, o indicando un valor mínimo). Se puede cambiar dinámicamente con:ALTER SYSTEM SET SHARED_POOL_SIZE

= 64M;• Se puede “vaciar” con ALTER

SYSTEM FLUSH SHARED_POOL; (menos lo q está en uso por sesiones o q esté “fijado” con dbms_shared_pool.keep).


SHARED POOL (shared_pool_size)

LIBRARY CACHE

DICTIONARY CACHE

SQL AREA PL/SQLAREA



13

SGA: Shared Pool

• En la library cache se almacena información sobre lassentencias SQL y PL/SQL, usadas recientemente. Está formada por dos estructuras:

– Shared SQL área; se almacenan los planes de ejecución y los árboles sintácticos (parse tree) de las sentencias SQL.

– Shared PL/SQL área; contiene las unidades de programa compiladas y analizadas sintácticamente (parsed): procedures, functions, packages y triggers.

• En la dictionary cache se guardan las definiciones de datos usadas más recientemente: database files, tablas, índices, columnas, usuarios, privilegios, etc. Esta información se genera y utiliza en la fase de análisis sintáctico (parse); y se obtiene de las tablas del diccionario de datos. Es como una caché de datos para el DD.



14

SGA: Database Buffer Cache

• Almacena copias de los bloques de datos, extraídos de los ficheros de datos (data files); y está gestionado por un algoritmo LRU.

• Cuando se procesa una query, el proceso servidor busca los bloques de datos en la Database Buffer Cache; si no los encuentra, los lee de los ficheros de datos y guarda una copia en la Database Buffer Cache.

• Su tamaño depende principalmente del parámetro DB_CACHE_SIZE (desde 10g mejor usar sga_target, dejando db_cache_size a cero o un valor mínimo). Puede modificarse dinámicamente (sin sobrepasar sga_target (sga_max_size en 9i)):

ALTER SYSTEM SET DB_CACHE_SIZE = 96M;• Se pueden definir varias cachés de datos 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 frecuentemente.

– DB_RECYCLE_CACHE_SIZE. Dimensiona la caché que almacena los bloques de las tablas que se usan poco.

El uso de una u otra caché lo indicaremos con el parámetro BUFFER_POOL, de la clausula STORAGE de la tabla: keep, recycle o default: ALTER TABLE mitabla STORAGE (BUFFER POOL KEEP);

• Se pueden definir cachés adicionales para tablas que no usan el tamaño de bloque por defecto de la BD; con los parámetros DB_nK_CACHE_SIZE, por ejemplo, DB_16K_CACHE_SIZE. Después se crea un tablespace que use el nuevo tamaño de bloque (crete tablespace ... BLOCKSIZE 16384;). Util al importar un tablespace de otra BD con otro db_block_size.

• Desde 10g, se puede vaciar con “ALTER SYSTEM FLUSH BUFFER_CACHE; “. Vacía completamente la caché de datos de la SGA. ¡¡¡OJO!!!, no usar en producción. Util si se quiere medir el rendimiento de sentencias sql como si se ejecutasen por primera vez.




15

SGA: Redo Log Buffer Cache

• Es un buffer circular que registra todoslos cambios hechos en los bloques de la caché de datos (incluidos datos en sí, índices y rollback), en lo que llamaremos “redo entries”. Su propósito principal esla recuperación de la instancia (no confundir con el “rollback”).

• El tamaño viene determinado por el parámetro log_buffer (en bytes).

• Las “redo entries” contienen la información necesaria (indices y rollback incluidos) para repetir los cambios hechos mediante insert, update, delete, create, alter o drop.

• Los procesos servidores copian las entradas de redo en la Redo Log Buffer Cache (después de modificar los bloques en la cache de datos) ; y el proceso LGWR es el encargado de volcar dichos buffers al fichero redo log activo (en disco).


DML USERS

LGWR



16

SGA: Large Pool

• Es un área de memoria de la SGA, a configurar sólo si se usa:– un entorno de servidores compartidos (shared server o

MTS)– recovery manager (RMAN)– parallel query

• Con MTS, almacena información sobre las sesiones conectadas a través de servidores compartidos: UGA, I/O y operaciones de backup y recuperación.

• No hace uso de algoritmo LRU para su gestión.• Su tamaño depende del parámetro large_pool_size (en

bytes), del fichero de inicialización, que se puede modificar dinámicamente (sin que el tamaño total de la SGA sobrepase el parámetro sga_target (sga_max_size en 9i)):ALTER SYSTEM SET LARGE_POOL_SIZE = 64M;

• Desde 10g mejor usar sga_target, dejando large_pool_size a cero (o con un valor mínimo).




17

SGA: Java Pool

• Sólo es necesaria si se instala y se usa Java en la BD.Se utiliza para compilar (parsing) el código Java (de forma similar a la Shared Pool para el código PL/SQL).

• Su tamaño depende del parámetro java_pool_size (redondeado por encima a un múltiplo del valor del gránulo), del fichero de inicialización. En Oracle9i, su tamaño por defecto es de 24M (si el tamaño del gránulo es de 4M, y de 32M si es de 16M.

• Desde 10g mejor usar sga_target, dejando java_pool_size a cero (o con un valor mínimo), de modo q sea Oracle el que se encargue de ajustar su tamaño automáticamente.



18

Program Global Area (PGA)

• Es una zona de memoria, fuera de la SGA, reservada paracada proceso de usuario que se conecta a la BD.

• Se crea cada vez que se arranca un nuevo proceso servidor (o un proceso background); y se libera cuando el proceso termina.

• En un entorno de servidores dedicados (dedicated server) contiene: sort area, información de sesión (privilegios de usuario y estadísticas de sesión), estado de los cursores (etapa del procesamiento de cada sentencia SQL que está usando actualmente la sesión), pila (stack space).

• Con servidores compartidos (MTS), parte de estas estructuras se guardan en la SGA. Si se activa la Large Pool se almacenan en ella, si no se quedan en la Shared Pool.

• PGA_AGGREGATE_TARGET (>=9i). Valor mínimo 10M, y default=20%SGA.. Vista V$PGASTAT. Tamaño = en OLTP RAM*0.80*0.20 (en DSS RAM*0.80*0.50). Activar: si es distinto de cero (junto a WORKAREA_SIZE_POLICY=AUTO). Habilita el uso de una zona de memoria compartida para las PGA, evitando la necesidad de asignar parámetros como SORT_AREA_SIZE o HASH_AREA_SIZE.




19

Program Global Area (PGA)


PGA(servidor dedicado)

SGA

PGA (servidor compartido)

SGA

PILA

SESION

LARGE POOL

PILA

SESIONSHARED POOL

SQL SHARED POOL

SQL



20

Estructura de procesos

• Procesos de usuario: se arranca uno cuando un usuario solicitauna conexión a la BD. Establece la conexión con la BD pero no interactúa directamente con ella.

• Procesos servidores: creado cuando se establece la conexión a la BD. Es el proceso que interactúa con la BD, para cada sesión. Un proceso servidor puede ser dedicado o compartido. Uno dedicado sólo gestiona la peticiones de la sesión que lo inicia; sin embargo, uno compartido gestiona las peticiones de varios procesos de usuario.

• Procesos background: disponibles cuando se arranca una instancia Oracle. Son los siguientes: DBWR, PMON, SMON, LGWR y CKPT; y nuevos en 10g: PSP0 (Process Spawner), MMAN (Memory Manager), MMON (Memory Monitor), MMNL (Memory Monitor Light). Opcionalmente podemos tener: ARCH, RECO, Dispatchers (Dnnn), Shared Servers (Snnn), etc. El parámetro BACKGROUND_DUMP_DEST, del fichero de inicialización, define el directorio donde se guardan los ficheros de traza de los procesos background.




21

Procesos background (DBWR)

• DBWR. Escribe los bloques de datos (y rollback) de la SGA (data buffer cache) en los ficheros de datos. Esto lo hace de forma asíncrona, cuando:

– Sucede un checkpoint.– El número de buffers modificados alcanza un umbral.– No quedan buffers libres.– Ocurre un timeout.– Ponemos un tablespace offline.– Dejamos un tablespace en modo readonly.– Borramos o “truncamos” una tabla.– ALTER TABLESPACE nombretsp BEGIN BACKUP.Nota. Un checkpoint sucede cuando:– El fichero redo log se llena al 90%.– Se alcanza log_checkpoint_interval (bloques del SO).– Se llega a log_checkpoint_timeout (en segundos).

• Nombre del proceso: DBW0 a DBW9 y DBWa DBWj (máximo 20).• DB_WRITER_PROCESSES. Nº de procesos arrancados.



22

Procesos background (LGWR, SMON)

• LGWR. Realiza escrituras secuenciales del contenido de la redolog buffer cache en los ficheros redo log. ¿Cuando?

– Se hace commit.– La redo log buffer cache se llena 1/3.– Hay 1Mb de cambios en la redo log buffer cache.– Como mucho, cada 3 segundos.– Siempre antes que escriba el DBWR.

• SMON. Recupera la instancia, si es necesario, cuando ésta arranca: aplica los cambios registrados en los redo log (roll forward), abre la base de datos dejándola accesible a los usuarios, y hace rollback de las transacciones que no terminaron. También se activa periódicamente, agrupando extensiones libres contiguas en extensiones de mayor tamaño (sólo para tablespaces con “default storage” cuyo pctincrease > 0).Además libera el espacio ocupado por segmentos temporales durante el procesamiento de sentencias SQL.




23

Procesos background (PMON, CKPT, ARCH)

• PMON. Se activa periódicamente, recuperando los recursos despuésde que un proceso falle: hace rollback de las transacciones que el usuario tenía en curso, libera bloqueos a nivel de tabla/fila y otros recursos reservados por el usuario, y vuelve a arrancar dispatchers “muertos” (dead dispatchers).

• CKPT. Avisa al DBWR cuando sucede un checkpoint y actualiza las cabeceras de los ficheros de datos y de control (el DBWR volcará los buffers actualizados a los ficheros de datos). Si los checkpoints suceden muy frecuentemente puede haber contención en disco. Si tardan mucho se alargará el proceso de recovery. Como mucho sucederá un checkpoint al llenarse el redolog.

• ARCH. Proceso opcional. Archiva automáticamente los redo log online si se activa el modo ARCHIVELOG; asegurando que se registran todos los cambios hechos en la base de datos. Archiva el redo log que se ha llenado, cuando sucede un “log switch”.

• MMAN (>=10g). Memory Manager. Gestiona Automatic Shared Memory Managment.

• MMON (>=10g). Memory monitor. Genera snapshots del AWR (abre procesos esclavos M000).

• MMNL (>=10g). Memory Monitor Light. Captura frecuentemente “session history” (V$ACTIVE_SESSION_HISTORY) y calcula métricas.

• PSP0 (>=10G). Process spawner. Crea y gestiona otros procesos Oracle.



24

ESTRUCTURA LÓGICA

• La estructura lógica de la base de datos determina el uso que se hace del espacio físico que la sustenta. Existe una jerarquía top-down en esta estructura, consistente en tablespaces, segmentos, extensiones y bloques.

• Una BDO la forman un grupo de tablespaces. Un tablespace puede contener uno o más segmentos. Un segmento lo integran una o más extensiones. Una extensión tendrá al menos un bloque. El bloque es la unidad mínima de almacenamiento.

• El tamaño del bloque será múltiplo del que tenga el SO, y lo determina la variable db_block_size (2K, 4K, 8K, 16K y 32K).

• Cuando un segmento (tabla, índice, rollback o temporal) crece, el espacio que se añade es de una extensión.

• ASM (>=10g). Gestor de volúmenes para bases de datos Oracle. Gestiona directamente los discos. Además distribuye automáticamente los datos entre los discos, manteniendo el reparto uniforme cuando se añaden o quitan discos (incluso en caliente). También se encarga de borrar los ficheros que ya no forman parte de la BD.




25

ESTRUCTURA LÓGICA


Base de Datos, Tablespaces, Segmentos, Extensiones y Bloques



26

ARQUITECTURA OFA

• OFA (Oracle Flexible Architecture) propone una estructura de directorios que permite ubicar fácilmente cualquier fichero del servidor de base de datos; además de agrupar dichos ficheros por componentes.

• Además, facilita el reparto de los ficheros entre diferentes discos, optimizando la E/S. Oracle recomienda separar el software de los datos; y estos últimos repartirlos entre varios discos (por ejemplo, separando datos e índices, incluso también temp y rollback). Estructura de directorios OFA:/u01/app/oracle (ORACLE_BASE)

$ORACLE_BASE/product/10.2.0.1 (ORACLE_HOME)$ORACLE_HOME/bin (Ejecutables)$ORACLE_HOME/dbs (init$ORACLE_SID.ora, orapw$ORACLE_SID)

$ORACLE_BASE/admin/$ORACLE_SID (ADMIN)$ORACLE_BASE/admin/$ORACLE_SID/pfile (PFILE)

init$ORACLE_SID.ora (crear enlace en $ORACLE_HOME/dbs)$ORACLE_BASE/admin/$ORACLE_SID/bdump (BDUMP)

alert$ORACLE_SID.ora y ficheros de traza de procesos background$ORACLE_BASE/admin/$ORACLE_SID/udump (UDUMP)

alert$ORACLE_SID.ora y ficheros de traza de procesos background/u02/oradata/$ORACLE_SID (Ficheros de la BD: *.dbf, *.ctl, *.log)/u03/oradata/$ORACLE_SID (Ficheros de la BD: *.dbf, *.ctl, *.log)/u04/oradata/$ORACLE_SID (Ficheros de la BD: *.dbf, *.ctl, *.log)




27

USUARIOS ADMINISTRADORES DE LA BD

• Cuando creamos una BDO se crean automáticamentelos usuarios SYS y SYSTEM, ambos con el rol DBA.

• El SYS, cuya clave inicial es change_on_install, es el propietario del DD y habitualmente se usa para arrancary parar la base de datos, así como para modificar los componentes de la misma (como instalar nuevas opciones). Para conectar como SYS:CONNECT SYS AS SYSDBACONNECT / AS SYSDBANota: hay que pertenecer al grupo dba (Unix/Linux) o crear un

“fichero de autenticación” en el SBD.• El SYSTEM, con clave inicial manager, es el DBA por

excelencia. Se usara para las tareas administrativas habituales: alta de usuarios, creación de tablespaces, etc.



28

FICHERO DE AUTENTICACIÓN

• Un “fichero de autenticación” nos permite conectar a la BD comoSYS AS SYSDBA, sin pertenecer al grupo dba o desde un puesto remoto al SBD, realizando dicha autenticación contra el mencionado fichero. Lo usaremos cuando no dispongamos de una conexión desde el propio SBD como grupo dba.

• Para usar un fichero de autenticación:– Crearemos el fichero con la utilidad orapwd:

orapwd file=nombre_fichero password=clave entries=máximo_de_usuarios

Nota: el fichero se llamará orapw$ORACLE_SID y estará en $ORACLE_HOME/dbs.– Activaremos el parámetro REMOTE_LOGIN_PASSWORDFILE del init:

• EXCLUSIVE. Permite dar el privilegio SYSDBA a otros usuarios(además del SYS). Sólo una instancia usa el fichero.

• SHARED. El único usuario reconocido por le fichero es el SYS. Elfichero puede ser compartido por varias instancias.

– Incluiremos el usuario en el fichero de claves (para el SYS no hay que hacerlo):GRANT SYSDBA TO usuario;Nota: en V$PWFILE_USERS están los usuarios con SYSDBA y/o SYSOPER.

– Conectaremos a la BD (el usuario Oracle que se conecta siempre es el SYS):CONNECT usuario/clave AS SYSDBA




29

PROCESO DE 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. ARQUITECTURA DE LA BD

ﾺ

2

3

4

1

1

3

4



30

PROCESO DE ACTUALIZACIÓN

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



31

VISTAS DEL DD

• V$DATABASE (Base de datos).• V$INSTANCE (Instancia).• V$SGA (SGA).• V$SGAINFO (Gestión dinámica de la SGA).• V$SGASTAT (SGA detallada).• V$BUFFER_POOL (Buffers en la caché de datos)• 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).• DBA_TABLESPACES (Tablespaces de la BD).• DBA_SEGMENTS (Segmentos que hay en los tablespaces).• DBA_EXTENTS (Extensiones que componen los segmentos).• DBA_USERS (Usuarios de la BD).



32

PRACTICAS TEMA 1

• 1.1. Comprobar la asignación de variables de entorno necesarias para conectarnos a la BD:

– echo $ORACLE_HOME– echo $ORACLE_SID– echo $LD_LIBRARY_PATH – echo $PATH

• 1.2. Identificar los procesos que componen instancia:– ps -ef|grep $ORACLE_SID– select username, program from v$process where background is

not null;– select name,description from v$bgprocess where PADDR!='00';

• 1.3. Ver el tamaño de la SGA de la BD:– select * from v$sgainfo;– select * from v$sgastat;– select * from v$sgastat where name in ('library cache','row

cache','sql area','buffer_cache','log_buffer');• 1.4. Comprobar valores de parámetros del init relacionados

con el tamaño de la SGA:– show parameter sga_target– show parameter sga_max_size– show parameter shared_pool_size– show parameter db_cache_size– show parameter db_block_size– show parameter log_buffer– show parameter large_pool_size– show parameter java_pool_size




33

PRACTICAS TEMA 1.

• 1.5. Comprobar ficheros que componen la BD y ubicarlos en la estructura OFA:

– ls -l /u0?/oradata/$ORACLE_SID– select name from v$datafile;– select name from v$tempfile;– select member from v$logfile;– select name from v$controlfile;

• 1.6. Identificar la estructura lógica de la BD: tablespaces, segmentos, extensiones.

– Select tablespace_name from dba_tablespaces;– select tablespace_name, file_name from dba_data_files order by

tablespace_name, file_name;– select tablespace_name, segment_type, count(*) segmentos from

dba_segments group by tablespace_name,segment_type;– select tablespace_name,segment_type, count(*) extensiones from

dba_extents group by tablespace_name,segment_type;



34

PRACTICAS TEMA 1.

• 1.7. Consultar información sobre la base de datos (v$database) y la instancia (v$instance).

– select name, created, log_mode, checkpoint_change#, open_mode, platform_name, current_scn from v$database;

– select instance_name, host_name,version, startup_time, status, archiver,logins, database_status from v$instance;

• 1.8. Localizar el proceso “servidor” asociado a mi sesión (v$process y v$session). ¿Es un servidor dedicado o compartido?select a.server, a.username dbuser,a.program user_program, b.spid

server_process, b.program server_programfrom v$session a, v$process b where a.username=USER and a.PADDR=b.ADDR;




35

PRACTICAS TEMA 1.

• 1.9. ¿Cuanto ocupa la Dictionary cache y la Library cache en tu BD? (v$sgastat)select SQL_TEXT, PERSISTENT_MEM, EXECUTIONS, LOADS,

DISK_READS, CPU_TIME, ELAPSED_TIME from v$sqlarea order by DISK_READS desc;

• 1.10. Ver la actividad de la Library Cache (v$librarycache).select namespace,gethitratio, gethitratio from v$librarycache;

• 1.11. Ver las sentencias SQL que guarda la Shared-Pool (v$sqlarea).select sql_text from v$sqlarea;

• 1.12. Crear el fichero de autenticación y activarlo (orapwd).orapwd file=$ORACLE_HOME/dbs/orapwCURSOxy password=miclave

entries=5remote_login_passwordfile=EXCLUSIVE"



36

TEMA 2ARRANQUE Y PARADA DE LA BASE DE

DATOS

ARRANQUE Y PARADA DE LA BD



37

TEMA 2.ARRANQUE Y PARADA DE LA BD

• Ficheros de inicialización: init.ora y spfile.ora• Creación de la BD• OMF (Oracle Managed Files)

• Arranque de la base de datos

• Comando startup

• Comando alter database

• Parar la base de datos

• Fichero alertSID.Log

• Trazas de los procesos background

• Trazas de los procesos de usuario

• Diccionario de datos

• Automatic Storage Managment (ASM)

ARRANQUE Y PARADA DE LA BD Administración y Ajuste de Oracle 10g


38

FICHEROS DE PARÁMETROS DE INICIALIZACIÓN – I

• 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.Nota3. Se puede crear un init a partir de un spfile, invirtiendo la sintaxis.

• Los parámetros del spfile se modifican con:ALTER SYSTEM SET parametro = valor [SCOPE = MEMORY | SPFILE | BOTH]

Nota. Si sólo queremos modificar el parámetro en el spfile, indicaremos SPFILE. Para hacer el cambio solo en memoria, especificar MEMORY.




39

FICHEROS DE PARÁMETROS DE INICIALIZACIÓN – II

• Hay dos tipos de parámetros: – Explícitos: los que se indican en el fichero de parámetros.– Implícitos: el resto, que tomarán un valor por defecto.

• La forma de indicar valor a los parámetros es parametro=valor.

• El símbolo # indica el comienzo de un comentario, pudiendo estar al principio o en medio de la línea.

• En el init.ora, el parámetro ifile permite incluir otros ficheros con parámetros.

• Una lista de valores se indicará entre paréntesis, separando los valores por comas.

• Para indicar un valor de tipo cadena de caracteres hay que encerrarlo entre comillas simples.

• Si usamos OFA, la ubicación típica para el init.ora es $ORACLE_BASE/admin/$ORACLE_SID/pfile. Después creamos un enlace en $ORACLE_HOME/dbs (ubicación por defecto).



40

EJEMPLO DE INIT.ORA

db_name=CURSOxydb_block_size=2048compatible = 10.2.0control_files = (/u02/oradata/CURSOxy/control1.ctl,

/u03/oradata/CURSOxy/control2.ctl)undo_management = autoundo_tablespace = undo_rbsbackground_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 = 10240sga_max_size = 120Msga_target = 100Mdb_cache_size = 0shared_pool_size = 0large_pool_size = 0java_pool_size = 0log_buffer = 2886656log_checkpoint_interval = 0log_checkpoint_timeout = 1800pga_aggregate_target = 10Mprocesses = 30remote_login_passwordfile=EXCLUSIVEnls_territory=spainnls_language=spanish

Nota. Es un fichero de texto que hay que mantener manualmente con un editor ASCII (vi, notepad, etc).




41

PARÁMETROS BÁSICOS DE ORACLE 10g

COMPATIBLECONTROL_FILESDB_BLOCK_SIZEDB_CREATE_FILE_DESTDB_CREATE_ONLINE_LOG_DESTDB_DOMAINDB_NAMEDB_RECOVERY_FILE_DESTDB_RECOVERY_FILE_DEST_SIZEINSTANCE_NUMBERJOB_QUEUE_PROCESSESLOG_ARCHIVE_DEST_nLOG_ARCHIVE_DEST_STATE_n


NLS_LANGUAGENLS_TERRITORYOPEN_CURSORSPROCESSESREMOTE_LISTENERREMOTE_LOGIN_PASSWORDFILEROLLBACK_SEGMENTSSESSIONSSHARED_SERVERSSTAR_TRANSFORMATION_ENABLE

DUNDO_MANAGEMENTUNDO_TABLESPACE

Como curiosidad, son aquellos parámetros que seríaobligatorio fijar para una instancia (los demás se podrían dejar por defecto). Realmente ésto no debe hacerse (dejar el resto de parámetros sin asignar para que tomen sus valores por defecto).



42

CREAR LA BASE DE DATOSy borrarla

• 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 (separados del resto de la BD).

– Separaremos los ficheros de datos que provoquen contención en disco; por ejemplo: datos, índices, system (DD), 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 y catproc.sql que están en

$ORACLE_HOME/rdbms/admin.• Desde 10g se puede borrar con “DROP DATABASE;” (sólo montada).




43

EJEMPLO DE CREACION DE BASE DE DATOSconnect / 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_RBS1 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 3M, '/u04/oradata/CURSOxy/redo02.log' SIZE 3M, '/u04/oradata/CURSOxy/redo03.log' SIZE 3M;rem *** CREACION DE LAS VISTAS DEL DD ***@$ORACLE_HOME/rdbms/admin/catalog.sql@$ORACLE_HOME/rdbms/admin/catproc.sql



44

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 los ficheros de control y 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:• 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 “CURSOxy”

character set WE8ISO8859P15UNDO TABLESPACE UNDO_RBSDEFAULT TABLESPACE USERSDEFAULT TEMPORARY TABLESPACE TEMP;




45

ARRANCAR LA BASE DE DATOS

• Cuando arrancamos una BDO, pasa por varios estados hastaque finalmente queda accesible a los usuarios: nomount, mount y open.

• En el primer estado (nomount) se arranca la instancia:lectura del fichero de parámetros, creación de la SGA, arranque de los procesos background y apertura del fichero alert$ORACLE_SID.log.Nota: el fichero de parámetros se busca en $ORACLE_HOME/dbs,

comenzando por spfile$ORACLE_SID.ora. Si no lo encuentra, sigue con spfile.ora, y finalmente init$ORACLE_SID.ora.

• Seguidamente la BD se monta (mount) abriendo el fichero de control y obteniendo de él los nombres de los ficheros que la componen: datafiles y redo log.

• Finalmente se abre la BD (open), procediendo a la apertura de los ficheros de datos (datafiles) y los ficheros redo log. El servidor oracle comprueba la consistencia de la base de datos, y si es necesario el proceso SMON inicia la recuperación de la instancia.



46

COMANDO STARTUP

• Arranca la instancia y abre la BD. Permite parar el proceso de arranque de la BD en cualquiera de sus fases (NOMOUNT, MOUNT).

• STARTUP (abre la base de datos con el fichero de parámetros por defecto).

• STARTUP PFILE=/home/CURSO/cursoXY/miinit.ora

• STARTUP NOMOUNT (para crear la base de datos).

• STARTUP MOUNT (para renombrar datafiles, activar ARCHIVELOG o hacer una recuperación completa de la BD).

• STARTUP RESTRICT (sólo permite la conexión de usuarios con el privilegio RESTRICTED SESION).

• STARTUP FORCE (hace SHUTDOWN ABORT y arranca la BD).




47

COMANDO ALTER DATABASE Y“ENCOLAR Y SUSPENDER” LA BD

• Permite cambiar el estado de la base de datos, p.e. de NOMOUNT aMOUNT, o de MOUNT a OPEN. También se utiliza para dejar la BD en modo READ ONLY.

– ALTER DATABASE {MOUNT | OPEN}– ALTER DATABASE OPEN [READ WRITE | READ ONLY]

• “Encolar” la BD (>=9i). Util si el DBA necesita q no haya transacciones ni consultas concurrentes a la suya. Espera a q 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 cerrarla sesión q hace el SUSPEND pues es la única q puede hacer RESUME:

ALTER TABLESPACE nomtsp BEGIN BACKUP;...ALTER SYSTEM SUSPEND;// Copiamos ficheros de la BD (necesitará “recuperar lainstancia”, pues no se hace checkpoint).ALTER SYSTEM RESUME;ALTER TABLESPACE nomtsp END BACKUP;



48

PARAR LA BASE DE DATOS

• Hay determinadas operaciones que requieren parar la BD; como la actualización de algunos parámetros del init.ora; o hacer una copia física de la BD (copia en frio). La BD se para con el comando SHUTDOWN, impidiendo cualquier conexión posterior.

• SHUTDOWN [NORMAL], espera a que terminen todas las transacciones en curso y todas las sesiones, fuerza un checkpoint, además de cerrar todos los ficheros y destruir (parar) la instancia.

• SHUTDOWN TRANSACTIONAL, sólo espera a que terminen las transacciones en curso, fuerza un checkpoint, cierra los ficheros y destruye (para) la instancia.

• SHUTDOWN IMMEDIATE, hace rollback de todas las transacciones en curso y cierra todas las sesiones; cierra y desmonta la BD, además de forzar un checkpoint, cerrar ficheros y parar la instancia (como los anteriores).

• SHUTDOWN ABORT, cierra la instancia (destruye procesos background y SGA) sin esperar a desmontar ni cerrar la BD (como en una “caida”, ni hace checkpoint ni cierra ficheros)). Requiere recovery de la instancia al arrancar (lo hace automáticamente el proceso SMON).




49

COMANDO SHUTDOWN

• Sintaxis:SHUTDOWN [NORMAL | TRANSACTIONAL | IMMEDIATE | ABORT]

• Tipos de parada. Cada una de las opciones de parada se comporta de forma diferente en cuanto a esperar a que terminen transacciones y sesiones, hacer checkpoint, o desmontar y cerrar la BD:


NORMAL TRANSACTIONAL IMMEDIATE ABORTEsperar Transacciones S S N NEsperar Sesiones S N N NCheckpoint S S S NCerrar BD S S S NDesmontar BD S S S NParar instancia S S S S



50

FICHERO alert.log

• Es el fichero de log de la BD y la primera referencia para elDBA en el “día a día” de la administración de la misma.

• Por defecto está en $ORACLE_HOME/rdbms/log; o en el directorio que indique el parámetro BACKGROUND_DUMP_DEST del init. Si usamos OFA, una ubicación típica es $ORACLE_BASE/admin/$ORACLE_SID/bdump.

• Recoge tanto información de estado como errores:– arranque y parada,– parámetros del init sin valores por defecto,– arranque de los procesos background,– cambio de fichero redolog (log switch), – creación de tablespaces y segmentos de rollback, – comandos alter (alter database, alter tablespace, etc), – errores ORA-600 y los que indican falta de espacio (llenado

de tablas, índices, tablespaces, etc).




51

EJEMPLO DE alert.log

Tue Oct 26 13:11:08 2006Starting ORACLE instance (normal)...Starting up ORACLE RDBMS Version:

10.2.0.2.0.System parameters with non-default values: processes = 30 sga_max_size = 83886080 __shared_pool_size = 50331648 shared_pool_size = 0 __large_pool_size = 4194304 large_pool_size = 0 __java_pool_size = 4194304 java_pool_size = 0... db_cache_size = 0 compatible = 10.2.0 log_buffer = 2886656... db_name = CURSOxy pga_aggregate_target = 10485760PMON started with pid=2, OS id=18002PSP0 started with pid=3, OS id=18004MMAN started with pid=4, OS id=18006DBW0 started with pid=5, OS id=18008LGWR started with pid=6, OS id=18010


CKPT started with pid=7, OS id=18012SMON started with pid=8, OS id=18014RECO started with pid=9, OS id=18016MMON started with pid=10, OS id=18018MMNL started with pid=11, OS id=18020Tue Oct 26 13:11:08 2006ALTER DATABASE MOUNT...SMON: enabling cache recoveryMon Oct 26 13:11:13 2006Successfully onlined Undo Tablespace 1.Mon Oct 26 13:11:13 2006SMON: enabling tx recoveryMon Oct 26 13:11:13 2006Database Characterset is WE8ISO8859P15...Tue Oct 26 13:11:16 2006Completed: ALTER DATABASE OPENWed Oct 26 13:52:06 2006Thread 1 advanced to log sequence 552 Current log# 3 seq# 4 mem# 0:

/home/u04/oradata/CURSOxy/redo03.log

Nota. En el ejemplo de arriba se puede ver el arranque de la instancia, los parámetros asignados, los procesos arrancados, como se monta la BD, y cómo finalmente se abre la BD y se empiezan a usar los fichero redolog.



52

FICHEROS DE TRAZA DE LOS PROCESOS BACKGROUND

• Registran errores producidos en los procesosbackground de la instancia: LGWR, DBWR, SMON, PMON, etc.

• Se generan en el directorio indicado por el parámetro de inicialización BACKGROUND_DUMP_DEST, que pordefecto es $ORACLE_HOME/rdbms/log. Si se utiliza la arquitectura OFA para ubicar los ficheros Oracle, una ubicación típica para estos ficheros de traza es $ORACLE_BASE/admin/$ORACLE_SID/bdump.

• Su nombre sigue el patrón ${ORACLE_SID}_nombreproceso_pid.trc; por ejemplo, cursoXY_smon_16432.trc (los nombres de los ficheros de traza en Unix/Linux están siempre en minúsculas).




53

FICHEROS DE TRAZA DE LOS PROCESOS DE USUARIO• Recogen estadísticas de seguimiento de sentencias SQL o errores en

las sesiones de usuario. • Las trazas de usuario se generan en el directorio que indique el

parámetro USER_DUMP_DEST (por defecto, $ORACLE_HOME/rdbms/log). Si usamos OFA, una ubicación típica es $ORACLE_BASE/admin/$ORACLE_SID/udump.

• Su tamaño está limitado por el parámetro MAX_DUMP_FILE_SIZE. • Sus nombres siguen el patrón ${ORACLE_SID}_ora_pid.trc; por

ejemplo, cursoXY_ora_23654.trc (siempre en minúsculas).• Pueden ser muy útiles para el ajuste de sentencias SQL. En este

caso se pueden generar voluntariamente “activando la traza”:– A nivel de sesión con “ALTER SESSION SET

SQL_TRACE=TRUE;”,– Desde una sesión del DBA con

“dbms_system.set_sql_trace_in_session(sid,true)”, donde SID es el nº de sesion oracle (V$SESSION, V$PROCESS). Se desactiva de igual forma (indicando false en lugar de true).

– A nivel de instancia, con el parámetro “SQL_TRACE=TRUE” del init.

• Utilidad TKPROF. Permite generar un informe “legible”, a partir de un fichero de traza generado explícitamente para una sesión.

– tkprof cursoXY_ora_23654.trc salida_traza.txt explain=scott/tiger sys=no ARRANQUE Y PARADA DE LA BD Administración y Ajuste de Oracle 10g


54

DICCIONARIO DE DATOS (DD)

• El DD está compuesto por un conjunto de tablas y vistas asociadas donde se almacena toda la información sobre los objetos que componen la BD, así como la estructura lógica y física de la misma.

• El DD incluye dos tipos de objetos: tablas base y vistas.– Las tablas base se crean automáticamente cuando creamos la BD

con el comando CREATE DATABASE; y son las que realmente contienen la información del DD.

– Las vistas se crean al lanzar el script catalog.sql; y permiten acceder a la información de las tablas del DD (que está codificada).

• El DD contiene información sobre: la definición de todos los objetos de la BD (tablas, vistas, índices, sinónimos, secuencias, procedimientos, funciones, paquetes, triggers, etc), el espacio ocupado por cada objeto, condiciones de integridad, usuarios, privilegios, roles, así como auditoría del sistema.




55

VISTAS DEL DICCIONARIO DE DATOS

• El DD se modifica cada vez que lanzamos una sentencia DDL.• Las vistas estáticas que forman parte del DD son de tres

tipos: dba, all y user. Cada una de ellas tendrá un prefijo asociado que la ubica en uno de dichos tipos.

– DBA: todos los objetos de la BD.– ALL: todos los objetos accesibles por el usuario actual.– USER: todos los objetos propiedad del usuario actual.

• La vista DICTIONARY contiene una lista de todas las vistas del DD; y en DICT_COLUMNS tenemos el detalle de las columnas de cada una de ellas.

• Ejemplos de vistas del DD:– Objetos de la BD: dba_objects, dba_tables, dba_indexes,

dba_tab_columns, dba_ind_columns, dba_constraints, dba_views.– Espacio ocupado: dba_data_files, dba_segments, dba_extents.– Estructura de la BD: dba_tablespaces, dba_data_files.

• El DD también tiene las llamadas tablas dinámicas, cuyas vistas tienen el prefijo V$ (como V$SESSION). Se crean al arrancar la instancia y residen en memoria. Cuando cerramos la BD (y por tanto la instancia), desaparecen y con ellas su contenido.



56

AUTOMATIC STORAGE MANAGEMENT (ASM) - I• ASM (>=10g). Gestor de volúmenes para bases de datos Oracle. Mejor

rendimiento de E/S y fácil de gestionar. Maneja el espacio en forma de grupos de discos. Divide cada fichero en extensiones (de 128K o 1M) y las reparte entre los discos de un grupo (striping). Tb permite mirror, y lo hace a nivel de fichero (más granular q a nivel de disco), gestionando el mirror a nivel de extensión. Varias opciones de mirror (a nivel de grupos de discos): 2-way mirroring (1 copia por extensión), 3-way (2 copias) y unprotected (sin mirror). Opciones de striping: fine (128Kb) y coarse (1M). Se puede desactivar mirror y/o striping.

• Al añadir nuevo disco a un grupo, rebalancea los datos online. Si esto genera mucha E/S, se puede “frenar” con ASM_POWER_LIMIT (en el init de la propia instancia ASM).

• ASM necesita un tipo especial de instancia: – Tiene init y orapw, pero no DD. Usuarios SYS y SYSTEM con

autenticación SO (no más usuarios).– Instancia: mount o no mount (nunca open). Memoria: de 60M a

120M.– Comandos de gestión propios: “create | alter | drop diskgroup”.– Nuevos procesos background:

• RBAL: coordina la actividad de rebalanceo de los discos en cada grupo.

• ORBn (n=0..9): ejecuta el rebalanceo, moviendo extensiones entre discos.




57

AUTOMATIC STORAGE MANAGEMENT (ASM) - II• Cada BD q usa ASM, tiene dos nuevos procesos background:

• OSMB: comunicación entre BD y la instancia ASM.• RBAL: abre y cierra los discos en los grupos, en la parte de la

BD.• Parámetros del init (para instancia ASM y/o BD q la usa):

– instance_type = ASM (para una BD es RDBMS)– db_unique_name = +ASM (valor por defecto)– asm_power_limit = 1 (máximo 11; velocidad rebalanceo; 1 es el

más lento)– asm_diskstring (limita los dispositivos de disco usables para grupos

de discos; ejemplo: '/dev/hd*').– asm_diskgroups (nombres de grupos de discos q se mostarán

automáticamente; por defecto vale NULL y los monta todos).– large_pool_size (al menos 8M, para ejecutar los paquetes internos

de uso de ASM)• Ejemplo de init de una instancia ASM

instance_type=ASM db_unique_name=+ASM asm_power_limit=1 asm_disk_string=’/dev/vgora01/rdsk/*’, ‘/dev/vgora02/rdsk/*’ asm_disk_groups=diskgrp1, diskgrp2 large_pool_size=16M ARRANQUE Y PARADA DE LA BD Administración y Ajuste de Oracle 10g


58

VISTAS DEL DD

• V$INSTANCE• V$DATABASE• V$SESSION• V$PROCESS• V$PARAMETER• V$PARAMETER2• V$SYSTEM_PARAMETER• V$SYSTEM_PARAMETER2• DICTIONARY• DICT_COLUMNS• V$ASM_DISKGROUP• V$ASM_CLIENT• V$ASM_DISK• V$ASM_FILE• V$ASM_TEMPLATE• V$ASM_OPERATION




59

PRACTICAS TEMA 2.

2.1. Fichero init.ora. Arranque y parada de la BD.• Localizar el fichero init.ora (y spfile si existe) de nuestra BD:

– ls -l $ORACLE_HOME/dbs/init$ORACLE_SID.ora– ls -l $ORACLE_HOME/dbs/spfile$ORACLE_SID.ora

• Anotar el valor de los parámetros: db_block_size, sga_target, sga_max_size, shared_pool_size, db_cache_size, log_buffer, processes.

– more $ORACLE_HOME/dbs/init$ORACLE_SID.ora– grep processes $ORACLE_HOME/dbs/init$ORACLE_SID.ora

• Crear fichero /home/CURSO/cursoxy/init01xy.ora, copia del initCURSOxy.ora, y modificar processes=17.

– cp $ORACLE_HOME/dbs/init$ORACLE_SID.ora init01xy.ora– echo processes=17 >> init01xy.ora– tail init01xy.ora

• Arrancar la BD y comprobar valor de parámetros, ¿por qué no ha tomado el nuevo valor?.

– STARTUP – show parameter processes

• Parar la BD y arrancar con el init01xy.ora. Comprobar parámetro processes. Abrir otra conexión de sqlplus y ver qué ocurre.

– SHUTDOWN immediate– STARTUP pfile=init01xy.ora– show parameter processes

• Parar la BD de forma normal, estando conectado algún usuario y ver qué ocurre. Y qué sucede cuando todos los usuarios se desconectan.

– SHUTDOWN• Repetir la parada de la BD, estando conectado algún usuario, de forma que no

espere:– SHUTDOWN IMMEDIATE



60

PRACTICAS TEMA 2.

2.2. Arranque de la BD (STARTUP). Comprobar las diferentes fases en el arranque de la BD.

• Arrancar sólo la instancia (NOMOUNT) y consultar algún parámetro. Qué ocurre al acceder a V$CONTROLFILE.

– STARTUP NOMOUNT– SHOW PARAMETER processes– SELECT * FROM V$CONTROLFILE;

• Ahora montar la BD y volver a consultar V$CONTROLFILE. Que sucede al leer DBA_USERS.– ALTER DATABASE MOUNT– SELECT * FROM V$CONTROLFILE;– SELECT * FROM DBA_USERS;

• Abrir la BD en modo READ ONLY y crear una tabla. Activar modo READ WRITE y volver a crear la tabla.

– ALTER DATABASE OPEN READ ONLY– CREATE TABLE MITABLA (C1 VARCHAR2(2));– ALTER DATABASE OPEN READ WRITE– CREATE TABLE MITABLA (C1 VARCHAR2(2));

2.3. Fichero alert.log y ficheros de traza. Diccionario de datos.• Buscar y consultar el fichero de alert de la BD.

– ls -l $ORACLE_HOME/rdbms/log/alert_$ORACLE_SID.log– ls -l $ORACLE_BASE/admin/$ORACLE_SID/bdump/alert_$ORACLE_SID.log– cat alert_$ORACLE_SID.log– tail -26f alert_$ORACLE_SID.log

• Buscar si hay ficheros de traza. – ls -l $ORACLE_HOME/rdbms/log/*.trc– ls -l $ORACLE_BASE/admin/$ORACLE_SID/bdump/*.trc– ls -l $ORACLE_BASE/admin/$ORACLE_SID/udump/*.trc

• Sacar la lista de vistas del DD. Consultar las columnas de dichas vistas.– Select * from DICTIONARY;– Select * from DICT_COLUMNS;




61

PRACTICAS TEMA 2.

2.4. Impedir las conexiones de usuarios, de modo que el DBA sí pueda conectarse. Intenta conectarte como scott/tiger. Volver a permitir conexiones de usuarios.

• STARTUP RESTRICT (si la BD está parada)• ALTER SYSTEM ENABLE RESTRICTED SESSION; (sila BD estaba arrancada)• ALTER SYSTEM DISABLE RESTRICTED SESSION;2.5. Forzar un checkpoint y hacer un insert en la tabla

SCOTT.DEPT. Inmediatamente después hacer SHUTDOWN ABORT. Arrancar y comprobar SCOTT.DEPT. Volver a repetir el insert, haciendo commit antes del SHUTDOWN ABORT; y comprueba el contenido de SCOTT.DEPT.

• ALTER SYSTEM CHECKPOINT;• insert into scott.dept values (99,'FORMACION','MURCIA');• SHUTDOWN ABORT• STARTUP• SELECT * FROM SCOTT.DEPT;• insert into scott.dept values (99,'FORMACION','MURCIA');• COMMIT;• SHUTDOWN ABORT• STARTUP• SELECT * FROM SCOTT.DEPT;



62

PRACTICAS TEMA 2.

2.6. Conéctate como SCOTT y haz update sobre DEPT (sin hacer commit). Desde otra sesión, cierra la BD con SHUTDOWN TRANSACTIONAL. ¿Qué pasa al hacer commit en la sesión de SCOTT?• CONNECT SCOTT/TIGER• SHUTDOWN TRANSACTIONAL (sesión del sys)• update dept set deptno=88 where deptno=99; (sesión de scott)• COMMIT; (sesión de scott)2.7. Conéctate como usuario scott/tiger. Activa la traza y haz una query con una join entre EMP y DEPT (select a.ename, b.dname from emp a, dept b where a.deptno=b.deptno;). Desactiva la traza y analiza el fichero que se ha generado con el comando tkprof (es un comando unix, no de SQL).• CONNECT SCOTT/TIGER• ALTER SESSION SET SQL_TRACE=TRUE;• tkprof nombre_fichero_traza.trc salida_traza.txt explain=scott/tiger sys=no (desde

fuera SQL)• cat salida_traza.txt




63

TEMA 3 FICHERO DE CONTROL

FICHERO DE CONTROL Administración y Ajuste de Oracle 10g


64

TEMA 3.FICHERO DE CONTROL

• Fichero de control

• Contenido del fichero de control

• Multiplexar fichero de control

• Backup del fichero de control

FICHERO DE CONTROL



65

FICHERO DE CONTROL

• Se trata de un fichero binario, sin el cual no es posiblearrancar la BD. Por ello es conveniente mantener varias copias del mismo, en diferentes discos.

• Se lee al montar la BD.

• Su tamaño es fijo, y depende de los parámetros indicados al crear la BD con CREATE DATABASE; como por ejemplo MAXLOGFILES y MAXDATAFILES.

• El fichero de control contiene información como: nombre de la BD, fecha de creación de la BD, nombres de los tablespaces, nombre y localización de los ficheros de datos y de redo, número de secuencia del redo log en curso, información de checkpoint, información del archivado de los redo log, información de backup.



66

AÑADIR COPIAS Y BACKUP DEL FICHERO DE CONTROL

• Para añadir una copia del fichero de control:– Se para la BD con SHUTDOWN NORMAL.– Se hace una copia física del fichero de control, a nivel del sistema

operativo. En Unix con el comando cp.– Se incluye la nueva copia del fichero de control en el init.ora (o

spfile); en el parámetro CONTROL_FILES.– Arrancar la BD con STARTUP.

• Se recomienda sacar una copia de seguridad del fichero de control cada vez que cambie la estructura física de la BD:

– ALTER DATABASE BACKUP CONTROLFILE TO TRACE;De esta forma se generan, en un fichero de traza, las sentencias sql necesarias para volver a crear el fichero de control.

– ALTER DATABASE BACKUP CONTROLFILE TO ‘/u02/oradata/CURSOxy/ora_control01.bak’;

Hace una copia binaria y aislada del fichero.• En la vista V$CONTROLFILE tenemos la lista de todos los

ficheros de control de la BD. En V$CONTROLFILE_RECORD_SECTION veremos las diferentes secciones y su estado de uso.

FICHERO DE CONTROL



67

ALTER DATABASE BACKUP CONTROLFILE TO TRACESTARTUP NOMOUNTCREATE CONTROLFILE REUSE DATABASE "CURSOxy" NORESETLOGS NOARCHIVELOG MAXLOGFILES 32 MAXLOGMEMBERS 2 MAXDATAFILES 1000 MAXINSTANCES 1 MAXLOGHISTORY 292LOGFILE GROUP 1 '/u04/oradata/CURSOxy/redo01.log' SIZE 10M, GROUP 2 '/u04/oradata/CURSOxy/redo02.log' SIZE 10M, GROUP 3 '/u04/oradata/CURSOxy/redo03.log' SIZE 10MDATAFILE '/u02/oradata/CURSOxy/system01.dbf', '/u03/oradata/CURSOxy/undo_rbs01.dbf', '/u03/oradata/CURSOxy/sysaux01.dbf', '/u02/oradata/CURSOxy/users01.dbf'CHARACTER SET WE8ISO8859P15;ALTER DATABASE OPEN;Nota: si hubiese que indicar la opción RESETLOGS, se perderá el

contenido de los ficheros redolog.



68

VISTAS DEL DD

• V$CONTROLFILE

• V$CONTROLFILE_RECORD_SECTION

• V$PARAMETER

FICHERO DE CONTROL



69

PRACTICAS TEMA 3

3.1.Localizar el fichero de control desde el SO y desde la BD.

– ls -lt /u0?/oradata/$ORACLE_SID/*.ctl

– ls -l /u0?/oradata/$ORACLE_SID/*control*

– select * from v$controlfile;

3.2.Consultar la información de la BD relativa al contenido del fichero de control. Forzar un checkpoint y volver a consultar. Consultar las secciones que contiene el fichero de control y su estado de uso.

– select * from v$database;

– alter system checkpoint;

– select * from v$controlfile_record_section;



70

PRACTICAS TEMA 3

3.3. Añade una copia al fichero de control de la BD en"/u04/oradata/$ORACLE_SID". Crea un initxy02.ora e incluye el nuevo fichero. Arranca la BD con el nuevo init y comprueba que ha tomado la nueva copia del fichero de control.

– shutdown immediate– cp /u02/oradata/$ORACLE_SID/control1.ctl

/u04/oradata/$ORACLE_SID/control3.ctl– cp $ORACLE_HOME/dbs/init$ORACLE_SID.ora init02xy.ora– vi init02xy.ora– startup pfile=init02xy.ora– select * from v$controlfile;

3.4. Sacar una copia de seguridad del fichero de control, tanto en un fichero de traza, como un nuevo fichero de control.

– alter database backup controlfile to trace;– ls -lt $ORACLE_BASE/admin/$ORACLE_SID/udump|head -2– alter database backup controlfile to

'/u02/oradata/CURSOxy/ora_control1.bak';– ls -lt /u02/oradata/$ORACLE_SID/control_copia1.ctl– select * from v$controlfile;

FICHERO DE CONTROL



71

TEMA 4 GESTION DEL REDO LOG

GESTION DEL REDO LOG Administración y Ajuste de Oracle 10g


72

TEMA 4.GESTION DEL REDO LOG

• Ficheros redo log

• Funcionamiento del redo log

• Añadir/quitar grupos/miembros de redo

• Configuración de los ficheros redo log

• Modo archivelog

GESTION DEL REDO LOG



73

FICHEROS REDO LOG

• Los ficheros redo log guardantodos los cambios hechos en los datos y permiten volver a aplicarlos en caso de caída de la BD.

• Los ficheros redo log se organizan en grupos. Una BD requiere al menos dos grupos. Cada fichero redo log dentro de un grupo se llama miembro.

• La idea es que cada grupo tenga tantos miembros como discos disponemos para matener las copias de los redo. Lo usual es tener 3 grupos de redo con 2 miembros cada uno.



74

FUNCIONAMIENTO DEL REDO LOG

• Los ficheros redo log se usan demanera circular: cuando uno sellena, el LGWR comienza aescribir en el siguiente grupo(“log switch”), hasta volver alprimero. Cuando ocurre un “logswitch”, también sucede un“checkpoint”; y se actualiza elfichero de control. Podemosforzar un log switch o uncheckpoint explícitamente con:

– ALTER SYSTEM SWITCH LOGFILE;

– ALTER SYSTEM CHECKPOINT;• El LGWR escribe al hacer commit,

o cada 3 segundos, o si el bufferredolog se llena 1/3, y antes deque el DBWR vuelque loscambios de los buffers de datos alos ficheros de la BD.




75

AÑADIR GRUPOS Y MIEMBROS DE REDO

• Añadir grupos al Redo Log Online:ALTER DATABASE ADD LOGFILE GROUP 3 (‘/u04/oradata/CURSOxy/redo03a.log’, ‘/u03/oradata/CURSOxy/redo03b.log’) SIZE 1M;

• Añadir miembros Redo Log Online :ALTER DATABASE ADD LOGFILE MEMBER

‘/u03/oradata/CURSOxy/redo01b.log’ TO GROUP 1,‘/u03/oradata/CURSOxy/redo02b.log’ TO GROUP 2;



76

ELIMINAR GRUPOS Y MIEMBROS DE REDO

• Eliminar grupos del Redo Log Online (por ejemplo si hecreado otros más grandes):ALTER DATABASE DROP LOGFILE GROUP 3;

No puede haber menos de 2 grupos; no se puede borrarel grupo activo; al borrar un grupo no se eliminan los ficheros del sistema operativo (a no ser que se use OMF).

• Elminar miembros Redo Log Online:ALTER DATABASE DROP LOGFILE MEMBER

‘/u03/oradata/CURSOxy/redo03b.log’;No se puede borrar el último miembro q quede de un grupo (y dejarlo vacío); tampoco un miembro del grupo en curso; si la BD está en modo ARCHIVELOG no se puede borrar un miembro cuyo grupo no ha sido archivado; cuando borramos un miembro no se elimina el fichero correspondiente del sistema operativo.




77

CONFIGURACIÓN DE LOS FICHEROS REDO LOG• Vaciado (por ejemplo si todos los miembros de un grupo están

corruptos):ALTER DATABASE CLEAR [UNARCHIVED] LOGFILE ‘/u02/oradata/CURSOxy/redo02a.log’;

Es equivalente a añadir y borrar un fichero redolog.• Mover o renombrar (¡ojo! la BD debe estar sólo montada):

!mv /u04/oradata/CURSOxy/redo03a.log /u03/oradata/CURSOxy/redo3a.logALTER DATABASE RENAME FILE ‘/u04/oradata/CURSOxy/redo03a.log’ TO ‘/u03/oradata/CURSOxy/redo3a.log’;

• Configuración del Redo Log Online: – El número de grupos Redo Log Online necesarios, como mínimo

será dos. Es probable que se necesite alguno más debido a que, al llenarse circularmente, los checkpoints no completen. La configuración debe ser simétrica: mismo número de miembros para todos los grupos.

– Cada miembro de un grupo debe estar en un disco diferente. Además hay que separar en diferentes discos los Redo Log Archivados de los Redo Log Online, para reducir la contención entre el LGWR y el ARCH. El Redo Log Online también debería estar en un disco distinto a los ficheros de datos, para reducir la contención entre LGWR y DBWR.

• En las vistas V$LOG, V$LOG_HISTORY y V$LOGFILE están los detalles del redo.



78

MODO ARCHIVELOG

• Por defecto, la BD se crea en modo NOARCHIVELOG (con CREATE DATABASE). Si activamos el modo ARCHIVELOG se irán archivando los ficheros redo log conforme se llenan (cada vez que ocurre un “log switch”).

• LOG_ARCHIVE_START=TRUE, activa archivado automático (en 10g no hace falta). El proceso ARCH irá archivando el grupo redo log lleno, después de cada “log switch”, en el directorio indicado por el parámetro LOG_ARCHIVE_DEST (por defecto $ORACLE_HOME/dbs/arch).Nota. Se puede ver el estado del archivado con el comando “archive log list” del sqlplus.

• Cada vez que se archiva un redo log, en el fichero de control se guarda el nombre del redolog archivado, número de secuencia, y números SCN más alto y más bajo.

• El redolog que se ha llenado no puede reutilizarse hasta que ocurra un checkpoint y haya sido copiado por el proceso ARCH.

• Poner BD en modo ARCHIVELOG: SHUTDOWN, backup (por seguridad), configurar log_archive_dest en el INIT, STARTUP MOUNT, activar archivado (ALTER DATABASE ARCHIVELOG;), abrir BD (ALTER DATABASE OPEN;), parar BD, y hacer backup (pues ha cambiado el fichero de control y la copia anterior ya no nos sirve). Nota. Más información en “http://cursos.atica.um.es/oradoc102/server.102/b14231/archredo.htm#i1006246”




79

VISTAS DEL DD

• V$LOG• V$LOG_HISTORY

• V$LOGFILE

• V$DATABASE



80

PRACTICAS TEMA 4

4.1. Localizar los ficheros redolog de la BD. ¿Cuántos grupos hay y cuántos miembros tiene cada grupo? ¿están correctamente distribuidos?

• ls -lt /u0?/oradata/$ORACLE_SID/*.log• ls -lt /u0?/oradata/$ORACLE_SID/*redo*• select * from v$logfile;

4.2. Comprobar el fichero redo log activo. ¿Qué ocurre al forzar un "log switch"? ¿y al forzar un checkpoint?

• select * from v$log;• alter system switch logfile;• alter system checkpoint;

4.3. Añade un miembro más a cada grupo: /u03/oradata/$ORACLE_SID/redo11.log, /u03/oradata/$ORACLE_SID/redo12.log, /u03/oradata/$ORACLE_SID/redo13.log.alter database add logfile member '/u03/oradata/CURSOxy/redo11.log' to group 1, '/u03/oradata/CURSOxy/redo12.log' to group 2, '/u03/oradata/CURSOxy/redo13.log' to group 3;




81

PRACTICAS TEMA 4

4.4. Añade un grupo más (grupo 4), con dos miembros de 1M: /u03/oradata/$ORACLE_SID/redo04.log y /u04/oradata/$ORACLE_SID/redo14.log. Añade 2 grupos más (grupo 5 y 6), con las mismas características.

• alter database add logfile group 4 ('/u03/oradata/CURSOxy/redo04.log', '/u04/oradata/CURSOxy/redo14.log') size 1M;



4.5. Elimina los miembros del grupo 1, de uno en uno. ¿Qué ocurre al eliminar el último?. Borrar los grupos 1, 2 y 3. ¡¡¡ Ojo y no borrar el redo log activo !!!

• Alter database drop logfile member '/u04/oradata/CURSOxy/redo01.log';

• alter database drop logfile member '/u03/oradata/CURSOxy/redo11.log';

• alter database drop logfile group 1;• alter database drop logfile group 2;• alter database drop logfile group 3;



82

PRACTICAS TEMA 4

4.6. Cambiar el nombre de los miembros de redo de los grupos 4, 5 y 6; a redo1a.log, redo1b.log, redo2a.log, redo2b.log, redo3a.log, redo3b.log.

• shutdown immediate¡¡¡ OJO, la BD debe estar sólo montada!!! • startup mount• mv /u03/oradata/CURSOxy/redo01.log /u03/oradata/CURSOxy/redo1a.log• mv /u04/oradata/CURSOxy/redo11.log /u04/oradata/CURSOxy/redo1b.log• mv /u03/oradata/CURSOxy/redo02.log /u03/oradata/CURSOxy/redo2a.log• mv /u04/oradata/CURSOxy/redo12.log /u04/oradata/CURSOxy/redo2b.log• mv /u03/oradata/CURSOxy/redo03.log /u03/oradata/CURSOxy/redo3a.log• mv /u04/oradata/CURSOxy/redo13.log /u04/oradata/CURSOxy/redo3b.log• alter database rename file '/u03/oradata/CURSOxy/redo01.log' to

'/u03/oradata/CURSOxy/redo1a.log';• alter database rename file '/u04/oradata/CURSOxy/redo11.log' to

'/u04/oradata/CURSOxy/redo1b.log';• alter database rename file '/u03/oradata/CURSOxy/redo02.log' to


'/u04/oradata/CURSOxy/redo2b.log';• alter database rename file '/u03/oradata/CURSOxy/redo03.log' to


'/u04/oradata/CURSOxy/redo3b.log';• alter database open;• select * from v$logfile;




83

TEMA 5TABLESPACES

TABLESPACES Administración y Ajuste de Oracle 10g


84

TEMA 5.TABLESPACES

• Qué es un tablespace• Tablespaces system y sysaux• Create tablespace• Formas de gestionar el espacio de un tablespace• Tablespaces “undo”• Tablespaces temporales• Tablespace temporal por defecto de la BD y tablespace

por defecto de la BD• Tablespace offline y rename• Tablespace read-only y bigfile• Borrar un tablespace y grupos• Redimensionar un tablespace• Mover ficheros

TABLESPACES



85

QUE ES UN TABLESPACE

• Una BD 10g podría tener sólo los tablespaces SYSTEM y SYSAUX (>=10g). Oracle recomienda crear tablespaces adicionales para los datos, índices, rollback y segmentos temporales.

• Según la estructura física, una BD está compuesta por: el fichero de control, ficheros redo log y ficheros de datos. La estructura lógica nos dice que está compuesta de tablespaces, segmentos, extensiones y bloques.

• Cada tablespace consiste en uno o más ficheros del s.o. llamados ficheros de datos (un fichero pertenece a un solo tablespace):

– Un tablespace sólo puede pertenecer a una BD a la vez. – Puede tener cero o más segmentos (un segmento sólo pertenece a un

tablespace). – Exceptuando el tablespace SYSTEM, o aquellos que contengan segmentos de

rollback activos, un tablespace se puede poner offline, estando la BD funcionando.

– Un tablespace se puede poner en modo read-only o read-write, y viceversa.• Tipos de tablespaces: permanent (datos: system, sysaux,

aplicaciones), undo (rollback) y temporary (sort).• Oracle 10g permite crear “bigfile tablespaces”, de hasta 8EB (millones

de terabytes).TABLESPACES Administración y Ajuste de Oracle 10g


86

TABLESPACES

TABLESPACES



87

TABLESPACES SYSTEM Y SYSAUX

• Los tablespaces SYSTEM y SYSAUX son los únicos que, cómo mínimo, se crean con la BD (create database).

• El tablespace SYSTEM (No debe contener datos de aplicaciones):– Contiene el DD, incluidos procedimientos almacenados, funciones,

triggers y paquetes. – También alberga al segmento de rollback system

• El tablespace SYSAUX (>=10g) permite que en el tablespace SYSTEM sólo esté el DD, aglutinando las utilidades del sistema (Repositorio OEM, Intermedia, Spatial, OLAP, RMAN, XML DB, etc).– ¿Qué hay en el tablespace SYSAUX y cuánto ocupa?select occupant_name, space_usage_kbytes from v$sysaux_occupants;– ¿Se puede mover el contenido de SYSAUX a otro tablespace?select occupant_name, move_procedure, move_procedure_desc from v$sysaux_occupants;

• Respecto al resto de tablespaces (no SYSTEM), se recomienda separar los ficheros de redo, luego datos de índices, después rollback y segmentos temporales. También es bueno separar datos estáticos y dinámicos.



88

CREAR UN TABLESPACE

CREATE TABLESPACE DATOS_USUARIOS DATAFILE ‘/u02/oradata/CURSOxy/datos_usuarios01.dbf’ SIZE 16M AUTOEXTEND ON NEXT 1M MAXSIZE 32M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K SEGMENT SPACE MANAGEMENT AUTO;

CREATE TABLESPACE DATOS_USUARIOS DATAFILE ‘/u02/oradata/CURSOxy/datos_usuarios01.dbf’ SIZE 16M AUTOEXTEND ON NEXT 1M MAXSIZE 32M EXTENT MANAGEMENT DICTIONARY DEFAULT STORAGE (INITIAL 16K NEXT 32K MAXEXTENTS 10 PCTINCREASE 50);

TABLESPACES

CREATE [BIGFILE] TABLESPACE nombre [DATAFILE claúsula_fichero] [MINIMUM EXTENT n[K|M]] [BLOCKSIZE n[K]] [LOGGING|NOLOGGING] [claúsula_extensiones] [DEFAULT claúsula_storage] [ONLINE|OFFLINE] [PERMANENT|TEMPORARY];

claúsula_fichero :== nombre_fichero [SIZE n[K|M] [REUSE] | REUSE] [AUTOEXTEND ON|OFF [NEXT n[K|M]] [MAXSIZE n[K|M]]]claúsula_extensiones :== EXTENT MANAGEMENT

[DICTIONARY | LOCAL [AUTOALLOCATE | UNIFORM [SIZE n[K|M]]

[SEGMENT SPACE MANAGEMENT AUTO | MANUAL]]]claúsula_storage :== STORAGE (INITIAL n[K|M] [NEXT n[K|M]] [MINEXTENTS n] [MAXEXTENTS n] [PCTINCREASE n])



89

FORMAS DE GESTIONAR EL ESPACIO DE UN TABLESPACE• Tablespaces manejados localmente (Oracle los recomienda >=8i):

– Las extensiones libres se registran en un bitmap, de forma que cada bit corresponde a un bloque. El valor de cada bit indica si el bloque correspondiente está libre o usado. Existe un bitmap de este tipo en cada fichero del tablespace. Cada vez que una extensión se reserva o se libera, se modifica el bitmap correspondiente.

– Ventajas:• Reducción de la contención en las tablas del DD.• No se genera rollback al reservar/liberar espacio (pues no se

actualiza el DD).• No es necesario hacer “coalesce”.

– No tienen el mismo sentido INITIAL_EXTENT y NEXT_EXTENT y no se usan MIN_EXTENTS, MAXEXTENTS y PCTINCREASE del STORAGE al crear una tabla. Tampoco tiene sentido DEFAULT STORAGE del tablespace.

– El tablespace system se puede “manejar localmente”, desde Oracle9i (en 8i no). Si el SYSTEM es “local”, NO se pueden crear tablespaces “por diccionario”. Desde Oracle9i, por defecto, los tablespaces se crean como “locales” (si el parámetro compatible>=9.0), exepto el SYSTEM.

• Tablespaces gestionados a través del DD (a extinguir):– Es el método por defecto en Oracle8i. Las extensiones libres quedan

registradas en tablas del DD. Cada vez que una extensión se libera o se reserva, las tablas correspondientes del DD deben ser actualizadas.

– Permite definir STORAGE flexible a los segmentos (los “locales” NO).TABLESPACES Administración y Ajuste de Oracle 10g


90

TABLESPACES “UNDO”

• En Oracle 9i se introducen los segmentos de undo automáticos, que permiten sustituir la gestión manual de segmentos de rollback. Con Oracle 10g todavía se puede optar por la gestión manual, pero se avisa de que ya no estará disponible en futuras versiones.

• Los tablespaces “undo” sólo pueden contener segmentos de rollback (ningún otro tipo de objeto). Los llamaremos tablespaces de rollback.

• Son del tipo “manejados localmente” (de forma automática).CREATE UNDO TABLESPACE undo01 DATAFILE ‘/u03/oradata/CURSOxy/undo01.dbf’ SIZE 100M;

• Un tablespace de rollback sólo se usa cuando se activa la gestión automática de rollback en la BD (undo_management=auto y undo_tablespace=nombre_tablespace). Sólo puede haber un tablespace de rollback activo en un momento dado.

TABLESPACES



91

TABLESPACES TEMPORALESY GRUPOS

• Los segmentos temporales (de sort) se crean en tablespacestemporales, automáticamente, para ordenaciones (order by, joins, create index, etc) que no caben en memoria. Existen sólo durante la ejecución de la sentencia SQL.

• Un tablespace temporal no puede contener objetos permanentes.• Es recomendable que sean “locally managed” (no pueden usar

AUTOALLOCATE ni SEGMENT SPACE MANAGEMENT AUTO) y usen ficheros temporales:CREATE TEMPORARY TABLESPACE temp TEMPFILE ‘/u03/oradata/CURSOxy/temp01.dbf’ SIZE 100M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 2M;

• Para optimizar el rendimiento es recomendable que UNIFORM SIZE sea múltiplo de SORT_AREA_SIZE.

• No se puede renombrar un fichero temporal (tempfile). Tampoco se pueden poner en modo read-only. Siempre tienen el modo NOLOGGING (no producen entradas de redo log).

• Desde Oracle10g se pueden agrupar tablespaces temporales, repartiendo las ordenaciones entre ellos (cada ordenación sólo usa un “segmento de sort” en un tablespace).

ALTER TABLESPACE temp1 TABLESPACE GROUP gtemp;ALTER TABLESPACE temp2 TABLESPACE GROUP gtemp;ALTER TABLESPACE temp3 TABLESPACE GROUP gtemp;ALTER TABLESPACE temp3 TABLESPACE GROUP '';ALTER USER nombre_usuario TEMPORARY TABLESPACE gtemp;



92

TABLESPACE TEMPORAL PORDEFECTO DE LA BD Y TABLESPACE POR DEFECTO• Desde Oracle9i, al crear la BD se puede (y se debe) indicar un

tablespace temporal por defecto para aquellos usuarios a los que no se le asigne uno explícitamamente. Si no se hace así, por defecto, se asignará el tablespace SYSTEM (ésto hay que evitarlo a toda costa).

• EL tablespace temporal por defecto de la BD se puede cambiar:ALTER DATABASE DEFAULT TEMPORARY TABLESPACE nombre_tablespace;Nota: nombre_tablespace podría ser un nombre de grupo.

• También se puede crear con la BD (CREATE DATABASE), en cuyo caso, será del tipo “local”.

• Al asignar a la BD un tablespace temporal por defecto, todos los usuarios que no tengan uno asignado explícitamente, pasarán a tenerlo. Y cuando cambiemos el tablespace temporal por defecto de la BD, cambiará para todos los usuarios que no lo tengan asignado de forma explícita.

• No podemos borrarlo hasta que hayamos asignado otro. No podemos ponerlo offline.

• Desde Oracle10, además, se puede definir un tablespace pordefecto para los usuarios a los que no se le asigna uno explícitamente, en el momento de la creación de la BD con la claúsula DEFAULT TABLESPACE nombre. Además se puede cambiar en cualquier momento con (¡¡¡ojo!!!, se cambiará para todos los usuarios, incluso los q tuviesen asignado uno concreto, excepto especiales como SYS, SYSTEM, DBSNMP, OUTLN, etc):ALTER DATABASE DEFAULT TABLESPACE nombre;

TABLESPACES



93

TABLESPACE OFFLINE Y RENAME

• Cuando un tablespace está OFFLINE no se puede acceder a los datos que contiene:ALTER TABLESPACE DBA01USER OFFLINE;

• Para ponerlo de nuevo ONLINE:ALTER TABLESPACE DBA01USER ONLINE;

• Algunos tablespaces no se pueden poner OFFLINE: SYSTEM, tablespaces con segmentos de rollback o temporales activos.

• SintaxisALTER TABLESPACE nombre ONLINE | OFFLINE;

• Los segmentos que contiene pueden ser borrados (por ejemplo “drop table”, porque sólo afectan al DD). En tablespaces “locales”, el segmento borrado pasa a ser del tipo temporal.

• Desde Oracle 10g, se puede renombrar un tablespace (execpto SYSTEM y SYSAUX), incluso estando READ ONLY:ALTER TABLESPACE nombre1 RENAME TO nombre2;



94

TABLESPCE READ-ONLY Y BIGFILE

• Al poner un tablespace en modo READ-ONLY, sólo se permiten operaciones de lectura sobre sus datos; sin embargo los segmentos que contiene pueden ser borrados (por ejemplo “drop table”, porque sólo afecta al DD). En tablespaces “locales”, el segmento borrado pasa a ser del tipo temporal.

• Sintaxis:ALTER TABLESPACE nombre READ [ONLY | WRITE];

• Un tablespace BIGFILE puede tener hasta 8Exabytes (millones de Tb). No pueden serlo ni SYSTEM ni SYSAUX.CREATE BIGFILE TABLESPACE nombre DATAFILE

'/u02/oradata/CURSOxy/nombre01.dbf' size 50G EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

TABLESPACES



95

BORRAR UN TABLESPACE

• Al borrar un tablespace, se elimina del DD. No podemosborrar SYSTEM/SYSAUX. Los ficheros asociados no se borran (hacerlo desde el SO después de eliminar el tablespace), a no ser que usemos INCLUDING CONTENTS AND DATAFILES (>= Oracle9i).

• No podremos borrarlo si contiene objetos, a menos que indiquemos NCLUDING CONTENTS. Tampoco podemos hacerlo si existen “foreign keys” apuntando a sus objetos, a menos que además indiquemos CASCADE CONSTRAINTS (se borrarán las citadas constraints FK).

• Se recomienda poner el tablespace OFFLINE antes de borrarlo, para asegurarnos que nadie está usando su contenido.

DROP TABLESPACE nombre_tablespace [INCLUDING CONTENTS [AND DATAFILES] [CASCADE CONSTRAINTS]];



96

REDIMENSIONAR UN TABLESPACE

• Podemos cambiar el tamaño de un tablespace añadiendo unfichero al mismo, o bien cambiando el tamaño del fichero que lo compone.

– ALTER TABLESPACE users ADD DATAFILE ‘/u02/oradata/CURSOxy/users02.dbf’ size 1M;– ALTER DATABASE DATAFILE ‘/u02/oradata/CURSOxy/users01.dbf’ resize 2M;

Podemos reducir el tamaño de un fichero, pero no podremos hacerlo si hay espacio ocupado al final del mismo.

• Una opción interesante es programar el crecimiento del fichero que compone el tablespace:

ALTER DATABASE DATAFILE ‘/u02/oradata/CURSOxy/users01.dbf’ SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4M;Podemos indicar UNLIMITED como MAXSIZE. Y las unidades también pueden ser K (p.e. 512K) o bytes (p.e. 100000).

• Sólo un tablespace BIGFILE se puede redimensionar con ALTER TABLESPACE, sin indicar DATAFILE (>=10g):ALTER TABLESPACE bigtbs RESIZE 60G;

• Podemos borrar fichero vacío de tablespace, con más de uno (>=10g): ALTER TABLESPACE users DROP DATAFILE

'/u02/oradata/CURSOXY/users02.dbf';TABLESPACES



97

REDIMENSIONAR UN TABLESPACE



98

MOVER FICHEROS

• Existen dos métodos para mover ficheros: con ALTERTABLESPACE y con ALTER DATABASE.

• El primero sólo es aplicable a tablespaces que no son el SYSTEM, y que no contienen segmentos de rollback o temporales activos:

– Poner el tablespace offline– Mover el fichero a nivel del S.O.– ALTER TABLESPACE RENAME DATAFILE ‘/path1/fichero1’ TO

‘/path2/fichero2’;– Poner el tablespace online.

• El segundo requiere que la BD esté sólo montada, y es la única forma de mover el tablespace SYSTEM:

– Parar la BD.– Montar la BD (startup mount).– Mover el fichero desde el S.O.– ALTER DATABASE RENAME FILE ‘/path1/fichero1’ TO

‘/path2/fichero2’;– Abrir la BD.

TABLESPACES



99

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;



100

ADDM (AUTOMATIC DATABASE DIAGNOSTIC MONITOR)

• Se activa por defecto (statistics_level = TYPICAL u ALL; se desactiva conBASIC).

• Informes. Entre dos snapshots del AWR. Su objetivo es reducir la estadística “DB time” (tiempo acumulado invertido por la BD para atender las peticiones de usuarios, ver V$SYS_TIME_MODEL).

– $ORACLE_HOME/rdbms/admin/addmrpt.sql. Tb usando el paquete DBMS_ADVISOR.

• 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.– DBA_ADVISOR_LOG.– DBA_ADVISOR_RECOMMENDATIONS. Ordenar por RANK

(importancia) y ver BENEFIT.– DBA_ADVISOR_FINDINGS.

• Más información sobre ADDM:– “

http://cursos.atica.um.es/oradoc102/server.102/b14211/diagnsis.htm#sthref4”

TABLESPACES



101

AWR (AUTOMATIC WORKLOAD REPOSITORY)• Genera y procesa estadísticas de rendimiento para que el propio servidor Oracle pueda detectar problemas y dar recomendaciones de ajuste (usando ADDM).

• Se activa por defecto (statistics_level = TYPICAL u ALL; se desactiva con BASIC).

• Genera “snapshots” automáticamente. Tb manualmente con paquete DBMS_WORKLOAD_REPOSITORY.

• Informes:– AWR: $ORACLE_HOME/rdbms/admin/awrrpt.sql. Permite generar

HTML.– ASH (V$ACTIVE_SESSION_HISTORY):

$ORACLE_HOME/rdbms/admin/ashrpt.sql.• Vistas del DD:

– V$ACTIVE_SESSION_HISTORY (ASH, añade sesiones activas cada segundo a buffer circular en SGA)

– V$METRIC*: V$METRIC, V$METRICGROUP, V$METRICNAME, V$METRIC_HISTORY.

– DBA_HIST*: DBA_HIST_ACTIVE_SESS_HISTORY, DBA_HIST_BASELINE, DBA_HIST_DATABASE_INSTANCE, DBA_HIST_SNAPSHOT, DBA_HIST_SQL_PLAN, DBA_HIST_WR_CONTROL.

• Más información sobre AWR:– “

http://cursos.atica.um.es/oradoc102/server.102/b14211/autostat.htm#i27008” TABLESPACES Administración y Ajuste de Oracle 10g


102

VISTAS DEL DD

• DBA_TABLESPACES• DBA_DATA_FILES• DBA_TEMP_FILES• V$TABLESPACE• V$DATAFILE• V$TEMPFILE• V$UNDOSTAT• DBA_TABLESPACE_GROUPS

TABLESPACES



103

PRACTICAS TEMA 5

5.1. Consultar los tablespaces que componen la BD. Comprobar los ficheros que tienen cada uno de ellos.– Select * from dba_tablespaces;– select * from v$tablespace– select * from dba_data_files;– select * from v$datafile;– select * from dba_temp_files;– select * from v$tempfile;



104

PRACTICAS TEMA 5

5.2. Crea el tablespace DATACURSOxy, NO manejado localmente, con el fichero /u02/oradata/datacursoxy01.dbf, con un tamaño de 1M. Crea 4 tablas (TABLA01, TABLA02, TABLA03, TABLA04) de 256K sobre dicho tablespace. Borra las tablas TABLA02 y TABLA04, y crea una tabla TABLA05 de 512K. ¿Qué ocurre y por qué?. Borra el tablespace DATACURSOxy y créalo de nuevo, manejado localmente. Vuelve a crear las tablas y repite el borrado de TABLA02 y TABLA04; y la creación de TABLA05 de 512K. ¿Qué ocurre esta vez y por qué?

– Create tablespace DATACURSOxy datafile ‘/u02/oradata/CURSOxy/datacursoxy01.dbf’ size 1M extent management dictionary;

– create table TABLA01 (C1 VARCHAR2(4000)) tablespace DATACURSOxy storage (initial 256K minextents 1);

– drop table TABLA02;– create table TABLA05 (C1 VARCHAR2(4000)) tablespace

DATACURSOxy storage (initial 512K minextents 1);– alter tablespace DATACURSOxy offline;– drop tablespace DATACURSOxy including contents and datafiles;– create tablespace DATACURSOxy datafile

‘/u02/oradata/CURSOxy/datacursoxy01.dbf’ size 1M extent management local uniform size 256K;

TABLESPACES



105

PRACTICAS TEMA 5

5.3. Pon el tablespace DATACURSOxy en modo READ-ONLY. Inserta una fila en alguna de sus tablas, ¿qué ocurre?. Borra la tabla TABLA01, ¿por qué se puede borrar?. Deja el tablespace DATACURSOxy en modo READ-WRITE. Repite el insert sobre TABLA01.

– alter tablespace DATACURSOxy read only;– insert into TABLA01 values (‘PRIMERA FILA’);– drop table TABLA01;– alter tablespace DATACURSOxy read write;– insert into TABLA01 values (‘PRIMERA FILA’);

5.4. Crea una tabla TABLA06 en el tablespace DATACURSOxy, ¿qué ocurre y por qué?. Activa el autoextend de su fichero, ajustando next 256K y maxsize 2M. Vuelve a crear la tabla TABLA06.

– Create table TABLA06 (C1 varchar2(4000)) tablespace DATACURSOxy storage (initial 256K minextents 1);

– alter database datafile ‘/u02/oradata/CURSOxy/datacursoxy01.dbf’ autoextend on next 256K maxsize 2M;

– Create table TABLA06 (C1 varchar2(4000)) tablespace DATACURSOxy storage (initial 256K minextents 1);



106

PRACTICAS TEMA 5

5.5. Crea el tablespace INDCURSOxy de 1M con el fichero /u02/oradata/CURSOxy/indcursoxy01.dbf. Muévelo al directorio /u03/oradata/CURSOxy.

– Create tablespace INDCURSOxy datafile ‘/u02/oradata/CURSOxy/indcursoxy01.dbf’ size 1M;

– alter tablespace CURSOxy offline;– mv /u02/oradata/CURSOxy/indcursoxy01.dbf

/u03/oradata/CURSOxy/indcursoxy01.dbf– alter tablespace rename datafile

‘/u02/oradata/CURSOxy/indcursoxy01.dbf’ to ‘/u03/oradata/CURSOxy/indcursoxy01.dbf’;

– alter tablespace INDCURSOxy online;– select * from dba_data_files;

TABLESPACES



107

TEMA 6.

ESPACIO DE “UNDO”.

ESPACIO DE “UNDO” Administración y Ajuste de Oracle 10g


108

TEMA 6.ESPACIO DE “UNDO”.

• Concepto de Transacción.• Espacio de “UNDO” (DESHACER).

– Caídas del sistema. “Redo log”.– Consistencia en lectura.– Retroceso de transacción. “Flashback”.

• Gestión de Espacio de “UNDO” (DESHACER).– Parámetros obsoletos.

• Modo automático de “undo”.– Parámetros de inicialización.– Cuota de “UNDO”.– Espacio almac. Creación, modificación, borrado e intercambio.– Vistas.– Dimensionado manual y automático.– Periodo de permanencia. “Retention guarantee”.



109

TEMA 6.ESPACIO DE “UNDO”.

• Modo manual de “UNDO” (DESHACER).

– Segmentos y sus tipos: segmentos de “rollback”.– Escritura en un segmento de “rollback”.– Segmento rollback system.– Segmentos de “rollback” públicos y privados.– Creación. Decremento y borrado. Parámetro optimal.– Puesta en/fuera de línea.– Modificación de parámetros.– Asignación explícita a una transacción.– Vistas estáticas.



110

TRANSACCIÓN.

• Unidad lógica de trabajo que contiene una o más sentencias SQL; se trata de una unidad indivisible o atómica. Los efectos de las sentencias de una transacción pueden ser todos validados (aplicados a la base de datos) o retrocedidos.

• Comienza en la primera sentencia SQL ejecutable.

• Termina cuando es validada o retrocedida, de forma explicita, mediante las sentencias COMMIT o ROLLBACK, o implícitamente, en el caso de sentencias DDL.

ESPACIO DE “UNDO”



111

ESPACIO DE “UNDO” (DESHACER).

• Espacio de “undo”: Conjunto de registros que guardaninformación, relativa a acciones realizadas por una transacción, necesaria para:

– Recuperación de la base de datos.

– Proporcionar consistencia en lectura (imagen de los datos).

– Retroceder transacciones (“rollback”).–

– Análisis de datos previos usando Oracle Flashback Query.

–

– Recuperación lógica usando Oracle Flashback.



112

ESPACIO DE “UNDO” Y CAÍDAS DEL SISTEMA.

• En caso de producirse una caída del sistema y quedartransacciones activas (sin validación –commit- ni retroceso – rollback-), Oracle recupera la información del espacio de “undo” y una vez hecho se realiza el “rollback” de dichas transacciones.

• En la recuperación de base de datos y una vez aplicados los cambios guardados en los ficheros de “redo”, el espacio de “undo” sirve para deshacer los efectos de transacciones no validadas.

• Este proceso recibe el nombre de “rolling back” o “transaction recovery”.




113

ESPACIO DE “UNDO” Y CAÍDAS DEL SISTEMA.



114

ESPACIO DE “UNDO” Y “REDO LOG”.

• En el caso del “redo log”, al igual que con “undo”, el sistema recoge datos estadísticos que ayudan a determinar su tamaño óptimo.

• En general los “redo” deben ser lo bastante grandes de como para que los “checkpoint” no ocurran demasiado frecuentemente; si se produce “log switch” con frecuencia superior a 20 minutos, el rendimiento decrece. Por otra parte, los “redo” excesivamente grandes afectan al rendimiento en disco y ocupan espacio.

• La columna OPTIMAL_LOGFILE_SIZE de la vista V$INSTANCE_RECOVERY indica el valor mínimo recomendado para el tamaño de los “redo log”.




115

ESPACIO DE “UNDO” Y CONSISTENCIA EN LECTURA.

• Se usa la información en el espacio de “undo” paracrear un conjunto de datos coherente respecto a un punto en el tiempo.

• Al validar la transacción (“commit”) se libera la información pero no se destruye inmediatamente sino que permanece un tiempo para asegurar la consistencia en lectura de las consultas que comenzaron antes de la validación.

• Los cambios realizados por otras transacciones que suceden durante la ejecución de la consulta no son tenidos en cuenta por esta. Los bloques alterados son reconstruidos a partir del espacio de “undo”, y los datos obtenidos enviados a la consulta.



116





117


• En ciertos casos, no pude devolverse un conjunto coherente de resultados, “snapshot”, para consulta voluminosa. Ocurre porque no puede almacenarse suficiente información en el espacio de “undo”como para reconstruir los datos requeridos.

• Generalmente se produce si existe una gran actividad que fuerza a que se sobrescriban datos necesarios para lograr la consistencia. Se genera el error:

ORA-01555 snapshot too old: rollback segment number “string” with name "string" too small

• La solución es disponer de más espacio de “undo”.



118

ESPACIO DE “UNDO” Y RETROCESO DE TRANSACCION.

• Retroceder una transacción (“rolling back”) es deshacer cualquier cambio realizado a los datos por sentencias SQL de una transacción no validada.

• En el retroceso de una transacción:

– Se aplican todos los cambios almacenados en orden inverso hasta llegar al dato original.

– Se libera cualquier bloqueo de datos efectuado por la transacción.

– Finaliza la transacción.




119

GESTION DE ESPACIO DE “UNDO” (DESHACER).

• Existen dos formas de gestionar el espacio de “undo”:

- Usando espacios de almacenamiento de “undo” (modo automático). Oracle recomienda que se trabaje de esta forma, dado que es menos complejo de implementar y más eficiente en su gestión.

- Usando segmentos de “rollback” (modo manual). A desaparecer.

Ambas formas NO pueden simultanearse.

• La forma de gestión, manual o automática, se determina en el arranque de la base de datos mediante el parámetro de inicialización UNDO_MANAGEMENT.



120

PARAMETROS OBSOLETOS.

• Existen distintos parámetros usados en versiones anteriores, relacionados con “undo” -manual y automático-, que han quedado obsoletos:

– UNDO_SUPPRESS_ERRORS

– MAX_ROLLBACK_SEGMENTS–

– ROW_LOCKING–

– SERIALIZABLE–

– TRANSACTION_AUDITING




121

MODO AUTOMATICO DE “UNDO”



122

MODO AUTOMATICO “UNDO”.PARAMETROS INICIALIZACION.

• El parámetro de inicialización UNDO_MANAGEMENTdebe tener el valor AUTO.

UNDO_MANAGEMENT = AUTO

• Al arrancar se busca un espacio de almacenamiento (“tablespace”) de “undo” (existente desde la creación de la bd o creado posteriormente), el primero disponible.

• Si no existe, se usa el segmento de “rollback” SYSTEM, y se genera un mensaje de error en el fichero de alertas. ¡Error!.




123


• Otros parametros de inicialización relacionados son:

- UNDO_RETENTION. Parámetro dinamico (alter system setundo_retention= <valor>) que indica en segundos -por defecto 900-, cuanto tiempo ha de permanecer, al menos, la informacion de “undo”disponible -importante en largas transacciones, consistencia en lectura, y utilidades Flashback -.

Sólo en ciertas circunstancias es necesario fijar este parámetro:

● Esp. de alm. con la opción AUTOEXTEND.● Fijar el periodo de retención para LOB.● Se desea especificar la “retention guarantee”.

El sistema calcula automáticamente el periodo de permanencia, para satisfacer los requerimientos de las consultas, basándose en el uso y tamaño del esp.alm. de “undo” e ignorando el valor UNDO_RETENTION, si es necesario, a menos que “retention guarantee”esté activa (si se necesita espacio para las transacciones activas y no hay suficiente , se reutiliza el existente y puede provocar el fallo de consultas muy largas).



124


- UNDO_TABLESPACE. Parámetro dinámico (alter system ...) que indicael espacio de almacenamiento de “undo” a usar en el arranque. Si se indica en modo manual, provoca error y falla el arranque.

Si se omite, se elige el primer espacio de almacenamiento de “undo” disponible, si no hay ninguno se arranca sin esp.alm. de “undo”y las transacciones se ejecutan en el segmento de “rollback” SYSTEM ¡Error!.

• Al arrancar en modo automático, cualquier parámetro relativo al modo manual usado en el fichero de parámetros es ignorado.




125

MODO AUTOMATICO “UNDO”.ESPACIO DE ALMACENAMIENTO.

• Para el uso en modo automático es necesario al menosun espacio de almacenamiento (“tablespace”) de “undo”, que está reservado exclusivamente para esta función (no pueden crearse allí objetos de datos).

• A cada instancia se le asigna sólo un esp.alm. de “undo”-puede ser de tipo “bigfile”-. Los datos de “undo” se manejan usando segmentos de “undo” que se crean y mantienen por el sistema.

• Si no hay ningún espacio de “undo” se emplea el segmento de “rollback” SYSTEM. ¡Error!.



126

MODO AUTOMATICO “UNDO”.ESPACIO DE ALMACENAMIENTO.

• Distintas operaciones pueden llevarse a cabo con este espacio de almacenamiento:

- Creación.-

- Modificación.-

- Borrado.-

- Intercambio entre distintos espacios de “undo”.-

- Modificar la clausula de retención.




127

MODO AUTOMATICO “UNDO”.CREACION DE ESPACIO “UNDO”.

• Al crear la base de datos, mediante la clausula UNDO TABLESPACE de la sentencia CREATE DATABASE:

CREATE DATABASE CURSO25 ...

UNDO TABLESPACE undotbs_01 DATAFILE

'/u03/oradata/CURSO25/undo01.dbf';

• Mediante la sentencia CREATE UNDO TABLESPACE (identica a CREATE TABLESPACE):

CREATE UNDO TABLESPACE undotbs1DATAFILE '/u03/oradata/CURSO25/undo01.dbf'SIZE 10M AUTOEXTEND ON RETENTION

GUARANTEE;



128

MODO AUTOMATICO “UNDO”.CREACION DE ESPACIO “UNDO”.

• Restricciones:

En la creacion sólo puede especificarse la clausula DATAFILE (localización del fichero), determinando Oracle el resto de atributos.




129

MODO AUTOMATICO “UNDO”.MODIFICACION ESPACIO “UNDO”.

• Mediante la sentencia ALTER TABLESPACE. Se permite:

- Añadir un fichero de datos.

ALTER TABLESPACE UNDOTBS ADD DATAFILE '/u03/oradata/CURSO25/undo02.dbf' AUTOEXTENDON NEXT 1M MAXSIZE UNLIMITED;

- Redimensionar un fichero de datos.

ALTER DATABASE DATAFILE'/u03/oradata/CURSO25/undo01.dbf' RESIZE 20M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED;



130


ALTER DATABASE DATAFILE

'/u03/oradata/CURSO25/undo01.dbf' RESIZE 100M;

- Renombrar un fichero de datos.

ALTER DATABASE RENAME FILE'/u03/oradata/CURSO25/undo01.dbf' TO'/u03/oradata/CURSO25/tbsp_undo01.dbf';

- Poner en línea o fuera de línea un fichero de datos.

ALTER DATABASE DATAFILE '/u03/oradata/CURSO25/undo01.dbf'

ONLINE/OFFLINE;




131


- Modificar claúsula “RETENTION”.

NO preservar los datos de “undo” que son aun válidos.

ALTER TABLESPACE UNDOTBS RETENTION NOGUARANTEE;

Preservar los datos de “undo” que son aun válidos.

ALTER TABLESPACE UNDOTBS RETENTION GUARANTEE;



132

MODO AUTOMATICO “UNDO”.BORRADO ESPACIO “UNDO”.

• Se emplea la sentencia DROP TABLESPACE:

DROP TABLESPACE <nombre_tbsp>;

• Sólo es posible borrar si el espacio de “undo” no está en uso. Al borrar se elimina todo su contenido.




133

MODO AUTOMATICO “UNDO”.INTERCAMBIO ESPACIO “UNDO”.

• Se usa la sentencia ALTER SYSTEM SET para asignar unnuevo espacio de “undo”, que sustituye al que anteriormente se utilizaba:

ALTER SYSTEM SET UNDO_TABLESPACE=<nombre_tbsp>;

• Se producirá error en caso de que el nuevo espacio de

almacenamiento no exista, no sea de “undo” o se este usando por otra instancia.

• La bd está en línea mientras se realiza la operación; y pueden ejecutarse transacciones, al terminar todas aquellas comenzadas despues de la sentencia se asignan al nuevo espacio de “undo”.



134

MODO AUTOMATICO “UNDO”.INTERCAMBIO ESPACIO “UNDO”.

• Si existen transacciones pendientes de validar, “commit”, en el antiguo espacio de “undo”, este pasa al estado PENDING OFFLINE. Las transacciones siguen su curso pero no se usa para nuevas transacciones.

• En el estado PENDING OFFLINE, un espacio de “undo” no puede borrarse. Una vez finalizadas todas las transacciones pasa al estado OFFLINE.

• Si se indica ALTER SYSTEM SET UNDO_TABLESPACE=''; sedeasigna el espacio de “undo” actual y se pasa al siguiente disponible.




135

MODO AUTOMATICO “UNDO”.VISTAS.

● V$UNDOSTAT. Estadísticas para monitorizar y ajustar el espacio de “undo”.

• V$ROLLSTAT. Informa sobre el comportamiento de los segmentos “undo” en el espacio de “undo”.

• V$TRANSACTION. Transacciones activas en el sistema.

• DBA_TABLESPACES.

• DBA_UNDO_EXTENTS. Extensiones en el espacio de “undo”.

• DBA_HIST_UNDOSTAT. Estadísticas acerca de consumo de espacio de “undo”, concurrencia de transacciones, longitud de las consultas ejecutas en la instancia, ... (contiene vistas de v$UNDOSTAT).



136

MODO AUTOMATICO “UNDO”.DIMENSIONANDO EL ESPACIO “UNDO”.

• Puede dimensionarse de tres formas:

– Empleando esp. de almacenamiento autoextensibles, de forma que incrementa su tamaño conforme es necesario (claúsula AUTOEXTEND).

– Cálculo usando método manual.

– Cálculo usando método automático: Undo Advisor.




137

MODO AUTOMATICO “UNDO”.DIMENSIONADO MANUAL.

• El espacio de “undo” necesario para retener lainformacion un tiempo determinado (UNDO_RETENTION) es:

Espacio = UR * (Tasa_transaccion * tamaño_bloque)

• Donde UR es el valor de UNDO_RETENTION, en segundos, y la tasa de transaccion el número máximo de bloques “undo” por segundo (columna UNDOBLKS de V$UNDOSTAT).

• Es preciso añadir al valor obtenido entre un 10% y un 20% de forma que pueda hacerse frente a situaciones inesperadas.



138

MODO AUTOMATICO “UNDO”.DIMENSIONADO AUTOMATICO.

• Si el espacio NO es autoextensible puede estimarse su valor óptimo usando el “Undo Advisor”, empleando el paquete DBMS_ADVISOR; este depende del repositorio Automatic Workload Repository (AWR) que contiene instantáneas de todas las estadísticas clave y de la carga de trabajo de la bd, a intervalos de 30 minutos (registro histórico de uso de la bd).

• Operaciones a seguir:

a) Determinar el periodo de tiempo a analizar (seleccionando los identificadores de “snap” apropiados). La vista DBA_HIST_SNAPSHOT muestra la información sobre instantáneas en el AWR (número de instantánea y fecha).

SQL >Select snap_id, begin_interval_time, end_interval_timefrom DBA_HIST_SNAPSHOTwhere begin_interval_time > '...' andend_interval_time < '...' order by end_interval_time desc;




139


b) Invocar Undo Advisor mediante el siguiente bloque para determinar el número de tarea.

DECLAREtid NUMBER;tname VARCHAR2(30);oid NUMBER;

BEGINDBMS_ADVISOR.CREATE_TASK('Undo Advisor', tid, tname, 'Undo Advisor Task');DBMS_ADVISOR.CREATE_OBJECT(tname, 'UNDO_TBS', null, null, null, 'null', oid);DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'TARGET_OBJECTS', oid);DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'START_SNAPSHOT',

snap_id_inicial);DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'END_SNAPSHOT', snap_id_final);DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'INSTANCE', 1);DBMS_ADVISOR.execute_task(tname);DBMS_OUTPUT.PUT_LINE ('Identificador de trabajo es: ' || tid ||' '|| tname);

end;/



140


c) Consultar la vista DBA_ADVISOR_FINDINGS para averiguar las recomendaciones.

SQL >Select owner, task_id, task_name, type, message, more_info from dba_advisor_findings where task_id= <numero_tarea -tid->

● Puede generarse un informe de texto o HTML mediante AWR ejecutando

SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql




141

MODO AUTOMATICO “UNDO”.PERIODO DE PERMANENCIA “UNDO”.

• El cálculo del valor óptimo para UNDO_RETENTION se realizaa partir de información estadística de uso y se ajusta para la consulta más larga, la información sobre duración de las consultas se obtiene cada 30 segundos.

• La bd analiza automáticamente el uso de “undo” para determinar el tamaño del esp.alm. de “undo” de forma que pueda soportar la consulta más larga.

• Esta característica está activada por defecto (arquitectura) y NO puede desactivarse. El valor calculado será tal que permita evita el error “snapshot too old”.



142


• En el cálculo, automático, del periodo de permanencia esnecesario considerar:

– El valor por defecto para UNDO_RETENTION son 900 segundos.Si el parámetro se ajusta a cero o no se indica valor, se ajusta

automáticamente empleando el valor 900 como el mínimo.Si UNDO_RETENTION se ajusta a un valor distinto de cero, se

ajusta automáticamente empleando el valor indicado como mínimo.

– Para un esp.alm. de “undo” con AUTOEXTEND. El sistema lo ajusta para ser algo superior que el mayor tiempo correspondiente a la ejecución de una consulta, si hay espacio. Si hay espacio libre, el periodo no es inferior al UNDO_RETENTION asignado.

– Para un esp.alm. de “undo” de tamaño fijo, la bd lo ajusta al máximo posible (hasta que haya espacio). Se ignora el valor de UNDO_RETENTION a menos que “RETENTION GUARANTEE” estéactiva.




143


– El ajuste automático del periodo de permanencia no es soportadopor LOB. Para estos objetos, el valor es el fijado por el parámetro UNDO_RETENTION.

– En operaciones DML de gran carga no se garantiza UNDO_RETENTION. Para asegurar que el espacio de “undo”necesario siempre estará disponible durante el periodo indicado se emplea la claúsula RETENTION GUARANTEE.

• El tiempo que el sistema retiene los datos en “undo” para el esp.alm. actual puede obtenerse consultando la columna TUNED_UNDORETENTION de la vista V$UNDOSTAT.

– La vista presenta estadísticas en periodos de diez minutos, una fila de datos por periodo, para los últimos 4 días (más allá han de consultarse en la vista DBA_HIST_UNDOSTAT).



144


select to_char(begin_time, 'DD-MON-RR HH24:MI') begin_time,to_char(end_time, 'DD-MON-RR HH24:MI') end_time,tuned_undoretentionfrom v$undostat order by end_time;

BEGIN_TIME END_TIME TUNED_UNDORETENTION------------------- ------------------- ------------------------------04-FEB-06 00:01 04-FEB-06 00:11 12100...07-FEB-06 23:21 07-FEB-06 23:31 86700...

El valor de “tuned_undoretention” se muestra en segundos.




145

MODO AUTOMATICO “UNDO”.“RETENTION GUARANTEE”.

• La claúsula “RETENTION GUARANTEE” permite garantizar el éxito de consultas de larga duración u operaciones “Flashback”. Puede usarse al crear el esp.almacenamiento de “undo” (CREATE UNDO TABLESPAE o CREATE DATABASE) o usando la sentencia ALTER TABLESPACE.

• Al activar la claúsula se garantiza el mínimo “undo_retention” especificado, de forma que la bd nunca sobeescribe datos (las transacciones pueden fallar por falta de espacio).

• Para desactivar la garantía de retención debe usarse la claúsula “RETENTION NOGUARANTEE”.

• El valor actual puede consultarse en la vista DBA_TABLESPACES (columna RETENTION, con valoresGUARANTEE, NOGUARANTEE o NOT APLY).



146

MODO MANUAL DE “UNDO”




147

MODO MANUAL “UNDO”.PARAMETROS INICIALIZACION.

• El parámetro de inicialización UNDO_MANAGEMENT debe tener el valor MANUAL, o bien no indicarse (es el valor por defecto).

UNDO_MANAGEMENT = MANUAL



148

MODO MANUAL “UNDO”.PARAMETROS INICIALIZACION.

Parametros de inicialización relacionados son:

- ROLLBACK_SEGMENTS. Asigna segmentos a la instancia.

- TRANSACTIONS. Indica el número máximo de transacciones concurrentes. Valores mayores incrementan el tamaño de la SGA y pueden incrementar el numero de segmentos reservados.

- TRANSACTIONS_PER_ROLLBACK_SEGMENT. Indica el número de transacciones concurrentes que cada segmento se espera que maneje.




149

SEGMENTOS Y SUS TIPOS.

• Segmento: Un conjunto de extensiones que contiene todos los datos para una estructura lógica de almacenamiento especifica en un “tablespace”.

• Tipos de segmentos:

- Segmentos de datos.- Segmentos de índices.- Segmentos temporales.

- Segmentos de “rollback”.



150

SEGMENTOS DE “ROLLBACK”.

• Toda base de datos posee uno o más segmentos de “rollback”.

• Contiene/n los valores antiguos de datos modificados por cada transacción.

• La información se dispone en múltiples entradas de “rollback” que contienen información de bloque y el dato tal como existía antes de la operación involucrada en la transacción.

• Estas entradas modifican los bloques del segmento de “rollback” y Oracle almacena todos los cambios hechos en la bitácora (“redo log”).




151

TRANSACCIONESY SEGMENTOS DE “ROLLBACK”.

• Una transacción es asociada a un segmento:

- Automáticamente, al siguiente segmento libre que exista.

Oracle distribuye las transacciones entre los segmentos activos de forma que todos ellos trabajen con, aproximadamente, el mismo número. Esto no depende del tamaño de los segmentos.

- Por asignación. Al comienzo de la transacción puede indicarse el segmento de “rollback” apropiado a usar (SET TRANSACTION USE ROLLBACK SEGMENT …).



152

ESCRITURA EN UN SEGMENTO DE “ROLLBACK”.

• Durante la transacción se escribe la información de“rollback” en el segmento asignado de forma secuencial. Cada transacción escribe en una única extensión del segmento en un momento dado.

• Por cada segmento existe una tabla de transacciones: Lista de todas las transacciones que lo usan y las entradas en el mismo para cada modificación realizada por dichas transacciones.

• Muchas transacciones activas pueden escribirconcurrentemente en un segmento, pero cada bloque de datos de una extensión de un segmento solo puede contener información de una transacción.




153


• Cada segmento de “rollback” debe tener al menos dos extensiones asignadas.

• Si una transacción agota el espacio libre en la extensión actual y debe proseguir la escritura, se localiza una extensión en el mismo segmento:

- Bien se reutiliza una extensión ya asignada al segmento. Se comprueba la siguiente extensión y si no contiene información de una transacción activa, se convierte en la extensión actual.

- O bien se asigna una nueva extensión al segmento.



154





155




156





157

SEGMENTO ROLLBACK SYSTEM.

• Se crea al mismo tiempo que la base de datos.• Reside en el “tablespace” SYSTEM y usa sus parámetros

de almacenamiento por defecto.• No puede borrarse.• Si existen diversos segmentos de “rollback”, se emplea

para transacciones especiales del sistema, y las transacciones de usuario son distribuidas entre otros segmentos de “rollback”.

• Se recomienda crear segmentos adicionales al SYSTEM tras instalar la base de datos.

• Si hay excesivas transacciones para el resto de segmentos, el segmento SYSTEM también es usado.



158

SEGMENTOS DE “ROLLBACK” PÚBLICOS Y PRIVADOS.

• Un segmento privado se adquiere explícitamente porla instancia si es nombrado en el fichero de inicialización (parámetro ROLLBACK_SEGMENTS). También puede usarse al ponerlo en línea de forma manual.

• Los segmentos públicos forman un conjunto que cualquier instancia puede usar. El número de segmentos públicos adquiridos automáticamente depende de los valores de TRANSACTIONS yTRANSACTIONS_PER_ROLLBACK_SEGMENT.

• La distinción tiene sentido si se usa la opción Real Application Clusters.




159

RECOMENDACIONES.

• Se recomienda crear un espacio de almacenamiento exclusivo que albergue a los segmentos de “rollback”.

• Ventajas:

- Puede ser mantenido en línea de forma permanente.

- No impide que otros espacios de almacenamiento sean puestos fuera de línea.



160

CREACIÓN.

• Debe poseerse el privilegio “create rollback segment”.

• El espacio de almacenamiento destino debe estar en línea.

• Sintaxis:

CREATE <PUBLIC> ROLLBACK SEGMENT <NOMBRE>TABLESPACE <NOMBRE_TBSP>STORAGE (INITIAL <XX>

NEXT <XX> MINEXTENTS <XX> MAXEXTENTS <XX> OPTIMAL <XX> );




161

CREACIÓN. RECOMENDACIONES.

• INITIAL y NEXT deben ser del mismo valor: Se consiguen así extensiones de tamaño uniforme.

• Debe crearse un adecuado número de extensiones iniciales para minimizar la necesidad de extensión.

• No debe fijarse MAXEXTENTS=UNLIMITED. Se evita así que se extienda de forma ilimitada debido a un error de programación.



162

CREACIÓN.PARÁMETRO OPTIMAL.

• Especifica el tamaño optimo del segmento. Oracleintenta mantener este tamaño para el segmento deasignando dinámicamente las extensiones cuando sus datos no son necesarios para otras transacciones activas.

• Cuando una transacción necesita escribir en otra extensión, se compara el tamaño actual del segmento con el optimo; si es mayor, y la extensión siguiente a la que se ha llenado es inactiva, se desalojan extensiones hasta llegar al optimo (siempre las mas antiguas).

• Su valor no puede ser menor que el espacio asignado inicialmente, especificado por los parámetros initial, next y el numero mínimo de extensiones.




163

CREACIÓN.PARÁMETRO OPTIMAL.

• Las estadísticas generadas en la vista V$ROLLSTAT(valores SHRINKS, AVESHRINK, AVEACTIVE y OPTSIZE) dan idea de lo adecuado o no del parámetro OPTIMAL.

– SHRINKS (bajo) y AVESHRINK (bajo): Si AVEACTIVE es cercano a OPTSIZE, OPTIMAL es correcto. En caso contrario, OPTIMAL es demasiado grande.

– SHRINKS (bajo) y AVESHRINK (alto): OPTIMAL correcto.

– SHRINKS (alto) y AVESHRINK (bajo): OPTIMAL demasiado pequeño.

– SHRINKS (alto) y AVESHRINK (alto): Aumentar OPTIMAL hasta que SHRINKS disminuya.



164

TAMAÑO SEGMENTO “ROLLBACK”.

• Aunque los segmentos de “rollback” pueden manejar transacciones de cualquier dimensión:

– Si un sistema ejecuta sólo transacciones cortas es preferible que los segmentos sean pequeños (siempre permanecen en memoria pero se corre el peligro de generar el ORA-01555).

– Si son transacciones de larga duración es mejor usar segmentos de gran tamaño.

• Lo ideal es crear un número de segmentos de tamaño apropiado para cada tipo de transacción y asignar explicitamente las transaccion atípicas a aquellos que corresponda (por ejemplo, transacciones largas).




165

TAMAÑO SEGMENTO “ROLLBACK”.

• Se recomienda que cada segmento típico tenga un 10%del tamaño de la mayor tabla de la bd.



166

PUESTA EN/FUERA DE LÍNEA.

• Cuando se crea un segmento esta fuera de línea y debeser puesto en línea de forma explicita.

• Si se intenta poner fuera de línea un segmento activo y en uso solo se consigue cuando las transacciones que lo usan finalizan. Permanecerá fuera de línea hasta que explícitamente sea puesto en línea o la instancia rearrancada.

• Sintaxis:

ALTER ROLLBACK SEGMENT <NOMBRE> ONLINE;

ALTER ROLLBACK SEGMENT <NOMBRE> OFFLINE;




167

MODIFICACIÓN DE PARÁMETROS.

• Sintaxis:

ALTER ROLLBACK SEGMENT <NOMBRE>STORAGE (INITIAL <XX>

NEXT <XX> MINEXTENTS <XX> MAXEXTENTS <XX> OPTIMAL <XX> );



168

DECREMENTO.

• Manualmente puede reducirse el tamaño de un segmentode”rollback”. El tamaño final depende del espacio libre en el segmento y de cuantas transacciones activas usan el segmento.

• Si no se especifica un tamaño concreto se intenta ajustar al del parámetro de creación OPTIMAL. Si no se ha determinado, al del parámetro MINEXTENTS.

• Sintaxis:

ALTER ROLLBACK SEGMENT <NOMBRE>SHRINK TO <XX> K/M;

ALTER ROLLBACK SEGMENT <NOMBRE> SHRINK;




169

BORRADO.

• Debe poseerse el privilegio “drop rollback segment”.

• El segmento debe estar fuera de línea.

• Sintaxis:

DROP ROLLBACK SEGMENT <NOMBRE>;



170

ASIGNACIÓN EXPLICITA A UNA TRANSACCIÓN.

• El segmento debe estar en línea y usarse como primera sentencia de la transacción:

SET TRANSACTION USE ROLLBACK SEGMENT <NOMBRE>;

• Un ejemplo de uso es asignar transacciones que insertan, actualizan o borran grandes cantidades de información a segmentos lo bastante grandes como para contener la información de “rollback” de la transacción.




171

VISTAS.

• V$ROLLNAME. Nombres de los segmentos de “rollback” en línea.

• V$ROLLSTAT. Estadísticas sobre segmentos de “rollback”.

• V$TRANSACTION. Transacciones activas en el sistema.

• DBA_ROLLBACK_SEGS. Información sobre segmentos de “rollback” de la bd.

• DBA_SEGMENTS, donde tipo de segmento sea ROLLBACK



172

TEMA 7.

GESTIÓN DE USUARIOS Y RECURSOS.

GESTIÓN DE USUARIOS Y RECURSOS



173

TEMA 7.GESTIÓN DE USUARIOS Y RECURSOS.

• Usuarios y su autentificación.

• Creación, modificación y borrado de usuarios.

• Grupos de espacios temporales.

• Espacio de almacenamiento SYSAUX.

• Perfiles. Parámetros. Función de verificación.

• Creación, modificación, asignación y borrado de perfiles.

• Privilegios. Privilegios de sistema y sobre objetos.

• Privilegios de sistema. Otorgar y revocar. Restricciones.




174

TEMA 7.GESTIÓN DE USUARIOS Y RECURSOS.

• Privilegios sobre objetos. Otorgar y revocar privilegios sobre objetos.

• Roles. Beneficios de los roles. Roles predefinidos.

• Creación, modificación, asignación y deasignación de roles a usuarios.

• Parámetro max_enabled_roles.

• Borrado de roles.

• Roles por defecto. Activación y desactivación de roles.

• Vistas.




175

USUARIOS




176

USUARIOS Y SU AUTENTIFICACIÓN.

• Cada base de datos tiene una lista valida de usuarios. Para acceder a la misma un usuario debe ejecutar un aplicación y conectarse a la instancia usando un nombre valido previamente definido. Tras la autentificación, puede autorizarse, o no, el acceso a determinados elementos y la ejecución de ciertas acciones.

• Las formas más comunes de autentificar a un usuario son:

- Por base de datos.

- Por sistema operativo (autentificación externa).




177

USUARIOS Y SU AUTENTIFICACIÓN.

• En la autentificación por base de datos la administraciónde la cuenta de usuario, contraseña, que se guarda encriptada, y la autentificación es realizada por Oracle.

• En la autentificación externa la cuenta es mantenida porOracle pero la administración de la contraseña y la autentificación de usuario es realizada externamente.

El ejemplo más común de la autentificación porsistema operativo es los usuarios ops$ o “identified externally”. El prefijo a usar viene determinado por el parámetro de inicialización, fichero init.ora, OS_AUTHENT_PREFIX (define el prefijo a añadir alcomienzo de toda cuenta de usuario identificado pors.o. y su valor por defecto es OPS$).




178

CREACIÓN DE USUARIOS.

• Necesario el privilegio de sistema CREATE USER. Normalmente sólo lo tiene el usuario administrador.

• No es posible la conexión del usuario creado a menos que posea el privilegio de sistema CREATE SESSION.

• Sintaxis:

CREATE USER <usuario>IDENTIFIED BY <contraseña>/EXTERNALLYDEFAULT TABLESPACE <espacio>TEMPORARY TABLESPACE <espacio>/<grupo_espacios>QUOTA <xx>/UNLIMITED ON <espacio>PROFILE <perfil>PASSWORD EXPIREACCOUNT LOCK/UNLOCK;




179


• Nombre de usuario.

Debe ser único respecto a otros nombres de usuario y roles. Cada usuario tiene asociado un esquema y dentro del mismo cada objeto debe tener un único nombre.

• Identificación.

Un usuario autentificado de forma externa se ha de crearcon la cláusula “IDENTIFIED EXTERNALLY”.




180


• DEFAULT TABLESPACE.

Indica aquel espacio de almacenamiento donde se crearán los objetos del esquema del usuario cuando al hacerlo no se indica ninguno en particular.

Si se omite la clausula, los objetos se crean en el esp. alm. pordefecto de la bd (default user tablespace) que se indica mediante la sentencia: alter database default tablespace ...; si este no se ha especificado el espacio por defecto es SYSTEM (¡Error!).

• TEMPORARY TABLESPACE.

Indica el espacio o grupo de espacios de almacenamiento para los segmentos temporales requeridos por el usuario.

No debe indicarse cuota. Si se omite la clausula, el espacio temporal por defecto es el SYSTEM (¡Error!) a menos que se haya fijado el valor del esp. temporal por defecto (default temporarytablespace): alter database default temporary tablespace ...; .




181


• QUOTA.

Indica la cantidad máxima de espacio que un usuario puede utilizar en un determinado espacio de almacenamiento. Puede indicarse cuota en múltiples espacios al tiempo.

El creador del usuario puede indicar cuota sobre espacios de almacenamiento aunque él no las posea.

Por defecto no se tiene cuota en ningún espacio de almacenamiento. Indicando UNLIMITED, es ilimitado el espacio a usar. Pueden usarse distintas abreviaturas paraindicar el tamaño: kilobytes (K), megabytes (M), gigabytes (G), terabytes (T), petabytes (P), o exabytes (E).

Puede revocarse el acceso a un espacio de almacenamiento asignando cuota cero en el mismo. Los objetos ya creados permanecen pero no pueden crecer ni crearse ninguno más.




182


• PROFILE.

Indica el perfil a asignar al usuario (especifica limitaciones en recursos del sistema y restricciones). Si se omite se asigna el perfil DEFAULT.

• PASSWORD EXPIRE.

Fuerza al usuario a cambiar la clave antes de conectarse a la base de datos.

• ACCOUNT.

“ACCOUNT LOCK”, bloquea la cuenta de usuario y deshabilita el acceso. “ACCOUNT UNLOCK”, desbloquea la cuenta de usuario y permite al acceso.




183

GRUPOS ESPACIOS TEMPORALES.

• Un grupo de espacios de alm. temporales (“temporary tablespace group”) es un sinónimo que engloba a un conjunto de espacios de almacenamiento temporales.

• El grupo se crea cuando se añade el primer espacio temporal al mismo (no puede estar vacio, por lo que, al menos, tiene un miembro). Si se eliminan todos sus componentes, el grupo deja de existir.

• Creación de grupos:

alter tablespace <nombre_temporal> tablespace group <nombre_grupo_temporales>;

create temporary tablespace <nombre_temporal> tempfile '/.../... .dbf' size ... tablespace group <nombre_grupo>;




184

GRUPOS ESPACIOS TEMPORALES.

• Asignar grupos por defecto:

alter database default temporary tablespace <nombre_grupo>;

• Eliminar un temporal de un grupo:

alter tablespace <nombre_temporal> tablespace group '';




185

MODIFICACIÓN DE USUARIOS.

• Los usuarios pueden cambiar sus propias claves, sin embargo para cambiar cualquier otro parámetro es necesario el privilegio “ALTER USER”.

• Sintaxis:

ALTER USER <usuario>IDENTIFIED BY <contraseña>/EXTERNALLYDEFAULT TABLESPACE <espacio>TEMPORARY TABLESPACE <espacio>/<grupo_espacios>QUOTA <xx>/UNLIMITED ON <espacio>DEFAULT ROLE <role>/ALL/ALL EXCEPT <role>/NONEPROFILE <perfil>PASSWORD EXPIREACCOUNT LOCK/UNLOCK;




186

MODIFICACIÓN DE USUARIOS.

• DEFAULT ROLE.

Indica los roles otorgados por defecto al usuario en la conexión. Se refiere a roles otorgados de forma directa al usuario (con la sentencia GRANT).

Oracle activa los roles indicados sin necesidad de especificar sus contraseñas.

Al crear el usuario los roles por defecto son todos los asignados, se limitan posteriormente mediante ALTER USER.




187

BORRADO DE USUARIOS.

• Al borrar un usuario el esquema asociado, con todos susobjeto, desaparecen.

• Una posible solución para que permanezca el usuario y los objetos pero impedir la conexión es revocar el privilegio “CREATE SESSION”.

• No es posible eliminar un usuario que permanezca conectado a la base de datos. Debe esperarse a que concluya o forzar su terminación (ALTER SYSTEM KILL SESSION).

• Es necesario tener el privilegio de sistemas “DROPUSER”.




188

BORRADO DE USUARIOS.

• Oracle no borra esquemas de usuario no vacios a menos que se indique CASCADE, realiza un borrado de objetos previo, o se hayan eliminado con anterioridad los objetos.

Es conveniente estudiar las implicaciones que sobre otros esquemas tiene el borrado del usuario y de su esquema:

– Se invalida vistas o sinónimos para objetos en el esquema borrado.

– Se invalidan procedimientos almacenados, funciones, o paquetes que consulten objetos pertenecientes al esquema eliminado.

– Las vistas materializadas en otros esquemas basados en tablas pertenecientes al esquema borrado no podrán refrescarse.

– Se borran todos los disparadores, “triggers”, del esquema.– No se eliminan roles creados por el usuario.

• Sintaxis:DROP USER <usuario> <CASCADE>;




189

ESPACIO DE ALMACENAMIENTO SYSAUX.

• El espacio de almacenamiento SYSAUX acompaña a SYSTEM,ayudando a incrementar la disponibilidad de la bd al descargardatos de aplicaciones que utilizaban el espacio SYSTEM u otros con anterioridad a esta versión de bd.

Tiene las mismas características de almacenamiento que SYSTEM.

• La vista dinámica V$SYSAUX_OCCUPANTS indica, entre otras cosas, las aplicaciones que usan SYSAUX, el espacio utilizado,el nombre del esquema propietario de la mismas y el nombre del procedimiento que debe emplearse para desplazardeterminado contenido desde SYSAUX hasta otra lozalización:

Select occupant_name, schema_name, space_usage_kbytes, move_procedure from V$SYSAUX_OCCUPANTS;




190

PERFILES




191

PERFILES.

• Está constituido por un conjunto de límites de recursos de la base de datos. Diferentes perfiles pueden ser asignados a diferentes usuarios.

• Habilitar o deshabilitar la limitación de recursos mediante perfiles puede hacerse (no aplicable a los parámetros de contraseña que siempre están habilitados):

- Mediante el parámetro de inicialización RESOURCE_LIMIT (init.ora), asignando valores TRUE o FALSE (por defecto).

- Mediante la sentencia ALTER SYSTEM SET RESOURCE_LIMIT = TRUE/FALSE.




192

CREACIÓN DE PERFILES.

• Es necesario el privilegio de sistema “CREATE PROFILE”.

• Existe un perfil por defecto o DEFAULT. Inicialmente todos los recursos designados en él tienen valor UNLIMITED, por lo que es conveniente modificarlo (sentencia ALTER PROFILE).

• Un usuario al que no se le asigna perfil posee el perfilDEFAULT.

• Aquellos recursos para los que en el perfil asignado no se ha definido un valor, o se ha indicado DEFAULT, toman el valor designado en el perfil por defecto.

• Sintaxis:

CREATE PROFILE <nombre_perfil> LIMIT <parámetros> <valor>/UNLIMITED/DEFAULT;




193

CREACIÓN DE PERFILES. PARÁMETROS DE RECURSOS.

• Parámetros de recursos:

– SESSIONS_PER_USER. Número de sesiones concurrentes.

– CPU_PER_SESSION. Tiempo de UCP por sesión (centésimas de segundo).

– CPU_PER_CALL. Tiempo de UCP para una llamada (parse, execute, o fetch) en centésimas de segundo.

– CONNECT_TIME. Tiempo total para una sesión (minutos).

– IDLE_TIME. Tiempo de inactividad continua en una sesión (minutos).




194

CREACIÓN DE PERFILES. PARÁMETROS DE RECURSOS.

– LOGICAL_READS_PER_SESSION. Numero de bloques de datos leídos en una sesión (memoria o disco).

– LOGICAL_READS_PER_CALL. Numero de bloques de datos para una llamada de una SQL (parse, execute, o fetch).

– PRIVATE_SGA. Cantidad de espacio, en bytes, para uso privado reservado en la “shared pool” de la SGA (se emplea K o M para indicar kilobytes o megabytes). Solo en “Shared Server”.

– COMPOSITE_LIMIT. Coste total en recursos por sesión expresado en unidades de servicio (CPU_PER_SESSION, CONNECT_TIME, LOGICAL_READS_PER_SESSION, y PRIVATE_SGA).




195

CREACIÓN DE PERFILES. PARÁMETROS DE CONTRASEÑA.

• Parámetros de contraseña:

– FAILED_LOGIN_ATTEMPTS. Número de intentos fallidos de conexión antes del bloqueo.

– PASSWORD_LIFE_TIME. Número de días en que la clave es válida para autentificación.

Si se indica un valor para PASSWORD_GRACE_TIME, la clave expira si no se cambia en este periodo. Si no se indica valor para PASSWORD_GRACE_TIME, por defecto UNLIMITED, se genera un aviso pero el usuario puede seguir conectándose.

– PASSWORD_GRACE_TIME. Periodo de gracia donde se permite la conexión pero se notifica la necesidad de cambiarla.

– PASSWORD_REUSE_TIME . Número de días en los cuales la contraseña no puede reutilizarse.




196

CREACIÓN DE PERFILES. PARÁMETROS DE CONTRASEÑA.

– PASSWORD_REUSE_MAX . Número de cambios de clavenecesarios antes de poder reutilizar la clave actual.

NOTA: PASSWORD_REUSE_TIME y PASSWORD_REUSE_MAX deben usarse conjuntamente. Si se indica un entero para ambos parámetros, el usuario no puede reutilizar la contraseña hasta que ha cambiado el número de veces indicado en PRM durante el periodo indicado por PRT. Si alguno de los dos tiene valor UNLIMITED, nunca se podrá reutilizar la contraseña. Si ambos tiene valor UNLIMITED, la bd los ignora.

– PASSWORD_LOCK_TIME. Número de días que la cuenta estará bloqueada después de un cierto número de fallos de conexión indicado.

– PASSWORD_VERIFY_FUNCTION. Permite indicar como argumento un “script” PL/SQL que verifica la complejidad de la clave. Si se indica NULL no se usa función alguna. Oracle proporciona una función por defecto: “verify_function”.




197

CREACIÓN DE PERFILES.

• Valor UNLIMITED. Si es un parámetro de recurso indica que puede usarse una cantidad ilimitada del mismo, en el caso de parámetros de contraseña que no ha sido fijado limite.

• Valor DEFAULT. Si se indica DEFAULT o se omite en el perfil algún parámetro, al ser asignado a un usuario toma para dicho parámetro el valor indicado en el perfil DEFAULT.

• Ejemplo de creación de perfil.

CREATE PROFILE perfil_2 LIMITFAILED_LOGIN_ATTEMPTS 5PASSWORD_LIFE_TIME 60PASSWORD_REUSE_TIME 60PASSWORD_REUSE_MAX 5PASSWORD_VERIFY_FUNCTION verify_functionPASSWORD_LOCK_TIME 1/24PASSWORD_GRACE_TIME 10;




198

FUNCIÓN DE VERIFICACIÓN.

• La función de verificación de contraseña debe pertenecer al usuario SYS. Realiza las comprobaciones:

– La contraseña satisface un mínimo de longitud.

– La contraseña no coincide con el nombre de usuario.

• Puede modificarse, siempre en el esquema SYS y conectando como CONNECT SYS/password AS SYSDBA




199

MODIFICACIÓN DE PERFILES.

• Es necesario poseer el privilegio de sistema “ALTER PROFILE”.

• Los valores modificados no afectan a las sesiones en curso.

• Sintaxis:

ALTER PROFILE <perfil>

LIMIT <parámetros> <valor>/UNLIMITED/DEFAULT;




200

ASIGNACIÓN DE PERFILES.

• Los perfiles no pueden asignarse a roles ni a otros perfiles, solo a usuarios.

• Se puede realizar durante la creación del usuario (CREATE USER) o posteriormente (ALTER USER).

• Un usuario sólo puede tener un perfil asignado a la vez.

• Las asignaciones de perfiles no afectan a las sesiones activas.




201

BORRADO DE PERFILES.

• Debe poseerse el privilegio de sistema DROP PROFILE. El perfil DEFAULT no puede borrarse.

• Para eliminar un perfil asignado a un usuario debe usarse la opción CASCADE. Si se borra un perfil asociado a un usuario, a este se le asigna de forma automática el perfil DEFAULT.

El borrado de un perfil no afecta a las sesiones en curso.

• Sintaxis:

DROP PROFILE <perfil>;

DROP PROFILE <perfil> CASCADE;




202

VISTAS. USUARIOS Y PERFILES.


Estadísticas de sesión (ver también V$STATNAME).V$SESSTAT

Información sobre sesiones.V$SESSION

USER_RESOURCE_LIMITS

Parámetros de contraseña asignados al usuario.USER_PASSWORD_LIMITS

Cuotas de espacio para usuarios.DBA_TS_QUOTASUSER_TS_QUOTAS

Describe el usuario actual.USER_USERS

Usuarios visibles al usuario actual.ALL_USERS

Usuarios de la base de datos.DBA_USERS

Parámetros de recursos asignados al usuario.



203

PRIVILEGIOS




204

PRIVILEGIOS.

• Derecho a ejecutar un tipo determinado de sentencia SQL o a acceder a un objeto de otro usuario. Pueden asignarse a usuarios o, preferiblemente, a roles. Es importante no excederse en la concesión de privilegios.

• Se distinguen dos tipos:

- De sistema: Permite realizar determinadas acciones en la base de datos (Por ejemplo, crear espacios de almacenamiento, crear usuarios, …) o en cualquier esquema.

- Sobre objetos: Permite a un usuario acceder y manipular o ejecutar objetos concretos (tablas, vistas, secuencias, procedimientos, funciones o paquetes).




205

PRIVILEGIOS DE SISTEMA.

• DATABASE.– ALTER DATABASE– ALTER SYSTEM– AUDIT SYSTEM

• DATABASE LINKS– CREATE DATABASE LINK – CREATE PUBLIC DATABASE LINK – DROP PUBLIC DATABASE LINK

• TABLAS – INDICES– CREATE TABLE– CREATE ANY TABLE / CREATE ANY INDEX– ALTER ANY TABLE / ALTER ANY INDEX– DROP ANY TABLE / DROP ANY INDEX– DELETE ANY TABLE / DROP ANY TABLE / INSERT ANY TABLE /

UPDATE ANY TABLES/ SELECT ANY TABLE




206


• PROCEDURE– CREATE PROCEDURE– CREATE ANY PROCEDURE– ALTER ANY PROCEDURE– DROP ANY PROCEDURE– EXECUTE ANY PROCEDURE

• PROFILES– CREATE PROFILE – ALTER PROFILE – DROP PROFILE

• ROLES– CREATE ROLE – ALTER ANY ROLE – DROP ANY ROLE– GRANT ANY ROLE




207


• ROLLBACK SEGMENTS– CREATE ROLLBACK SEGMENT – ALTER ROLLBACK SEGMENT – DROP ROLLBACK SEGMENT

• SESSIONS– CREATE SESSION – ALTER SESSION

• TABLESPACES– CREATE TABLESPACE – ALTER TABLESPACE – DROP TABLESPACE – MANAGE TABLESPACE– UNLIMITED TABLESPACE




208


• USUARIO– CREATE USER– ALTER USER– DROP USER–

• OTROS– ANALYZE ANY– AUDIT ANY– COMMENT ANY TABLE– ...

Nota: Consultar “Oracle Database SQL Reference” para una lista completa de privilegios de sistema.




209


• La cláusula ANY en cualquier privilegio indica que losusuarios a los que se les conceda tienen dicho privilegio en cualquier esquema.

• Notas:

- No existe el privilegio CREATE INDEX.- CREATE TABLE incluye las sentencias CREATE INDEX y

ANALYZE.- Privilegios como CREATE TABLE o CREATE PROCEDURE

incluyen el borrado de dichos objetos.- UNLIMITED TABLESPACE no puede otorgarse a un rol.

Este privilegio permite usar una cantidad ilimitada de espacio en cualquier espacio de almacenamiento de la bd y se antepone a cualquier cuota explícita asignada al usuario (¡Error!).




210

OTORGARPRIVILEGIOS DE SISTEMA.

• Para que un usuario pueda otorgar un priv.de sistema biendebe haberse otorgado con ADMIN OPTION, permite a aquel a quien se le concede el privilegio poder otorgarlo (¡peligro!), ohaber sido concedido el privilegio GRANT ANY PRIVILEGE.

• Sintaxis:

GRANT <privilegio>/ALL PRIVILEGES TO <usuario>/<rol>/PUBLIC;

GRANT <privilegio>/ALL PRIVILEGES TO <usuario>/<rol>/PUBLIC WITH ADMIN OPTION;

• Al especificar ALL PRIVILEGES se otorgan todos los privilegios de sistema (¡Peligro!).

• La cláusula PUBLIC otorga el privilegio a todos los usuarios(¡Peligro!).




211

RESTRICCIONESEN PRIVILEGIOS DE SISTEMA.

• El parámetro de inicialización, fichero init.ora,O7_DICTIONARY_ACCESSIBILITY permite restringir los privilegios de sistema. Impide el acceso al esquema SYS a través de los privilegios que conceden acceso a cualquier esquema (privilegios ANY).

• Por defecto su valor es FALSE, el acceso a objetos en este esquema está entonces restringido a SYS y aquellos usuarios que se conectan como SYSDBA. En este caso, por ejemplo, SELECT ANY TABLE permite acceder a vistas y tablas en otros esquemas pero no seleccionar objetos del esquema SYS (diccionario de datos).

• Si su valor es TRUE, se permite el acceso a los objetos del esquema SYS (¡Error!).




212

REVOCARPRIVILEGIOS DE SISTEMA.

• Sintaxis:

REVOKE <privilegio>/ALL PRIVILEGES FROM<usuario>/<rol>/PUBLIC;

• Cualquier usuario con la opción ADMIN OPTION sobre un privilegio puede revocarlo. Quien lo hace no tiene porque ser el usuario que originalmente lo otorgo.

• Al retirar ciertos privilegios determinados objetos pueden quedarinconsistentes (procedimientos o vistas consultadas merced al privilegio SELECT ANY TABLE).

• En el caso de ADMIN OPTION no hay un efecto en cascada cuando se retira un privilegio referente a operaciones DDL (por ej. CREATE TABLE); si lo hay cuando se revoca un privilegio referente a operaciones DML (por ejemplo SELECT ANY TABLE).

• Si se retira un privilegio de sistema de PUBLIC, pero existen usuarios a los que se ha otorgado aquel directamente o a través de roles, estos siguen pudiendolo usar.




213

PRIVILEGIOS SOBRE OBJETOS.

• TABLAS

– ALTER - DELETE - FLASHBACK– INDEX - INSERT - REFERENCES– SELECT - UPDATE

• VISTAS

– DELETE - FLASHBACK - INSERT– REFERENCES - SELECT - UPDATE

• SECUENCIAS

– ALTER - SELECT

• FUNCIONES, PAQUETES Y PROCEDIMIENTOS

– EXECUTE

Nota: Consultar “Oracle Dat.SQL Reference” para lista completa privilegios sobre objetos.




214

OTORGARPRIVILEGIOS SOBRE OBJETOS.

• Sintaxis:

GRANT <privilegio>/ALL PRIVILEGES <columna>/ON <esquema>.objetoTO <usuario>/<rol>/PUBLIC;

GRANT <privilegio>/ALL PRIVILEGES ON <esquema>.objetoTO <usuario>/<rol>/PUBLIC WITH GRANT OPTION;

• Con ALL PRIVILEGES se otorgan todos los privilegios sobre el objeto(¡Peligro!).

• Con PUBLIC otorga el privilegio a todos los usuarios (¡Peligro!).

• La cláusula GRANT OPTION permite a aquel a quien se le concede elprivilegio poder otorgarlo (¡Peligro!).




215

OTORGARPRIVILEGIOS SOBRE OBJETOS.

• Ejemplos:

GRANT ALL PRIVILEGES ON nomina.retencionesTO gestor WITH GRANT OPTION;

GRANT REFERENCES (dni_empleado), UPDATE (dni_empleado, sueldo_base) ON nomina.empleados TO gestor;




216

REVOCARPRIVILEGIOS SOBRE OBJETOS.

• Sintaxis:

REVOKE <privilegio>/ALL PRIVILEGES ON <esquema>.objeto FROM <usuario>/<rol>/PUBLIC <CASCADE CONSTRAINTS>;

• CASCADE CONSTRAINTS elimina cualquier cláusula de integridad referencial que aquel a quien se retiran los permisos haya definido usando REFERENCES o ALL PRIVILEGES.

• Quien otorgo privilegios solo puede revocarlos a aquellos usuarios a quienes se los ha concedido.

• En el caso de GRANT OPTION hay un efecto en cascada cuando se retira un privilegio.




217

ROLES




218

ROLES.

• Es un grupo de privilegios, de sistema o sobre objetos,a los que se les da un nombre y pueden ser asignados a otros usuarios y roles.

• Características:

- Pueden otorgarse a cualquier usuario o rol, pero no a si mismo y tampoco de forma circular.

- Pueden tener contraseña.

- Su nombre es único en la bd, distinto a cualquier otro nombre de usuario o rol.

- No pertenecen a ningún esquema.




219

ROLES. BENEFICIOS.

• Simplifican el manejo de privilegios. Los permisos pueden asignarse a un rol y este a los diferentes usuarios.

• Manejo de privilegios dinámico. Si se modifican los privilegios asociados al rol, todos los usuarios que lo posean los adquieren de forma inmediata.

• Disponibilidad de privilegios selectiva. Roles asignados a un usuario pueden ser activados o desactivados temporalmente.

• Mejora aplicaciones. Cuando un usuario ejecuta una determinada aplicación puede activarse, o desctivarse, selectivamente roles en función de nuestro interés. Los roles también pueden protegerse con claves y estos activarse sólo si la aplicación suministra la correcta.

• Mejora de la productividad. El uso de roles disminuye el numero de “grants” almacenados en el diccionario de datos.




220

ROLES PREDEFINIDOS.

• Oracle proporciona roles predefinidos como ayuda a la administración de base de datos, entre los que se encuentran:

– CONNECT. Incluye sólo el privilegio CREATE SESSION.

– RESOURCE. Incluye CREATE CLUSTER, CREATE INDEXTYPE, CREATE OPERATOR, CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER y CREATE TYPE.

– DBA. Todo privilegio de sistema WITH ADMIN OPTION.

– EXP_FULL_DATABASE. Privilegios para realizar exportaciones completas e incrementales de la base de datos.

– IMP_FULL_DATABASE. Idem para importaciones completas.




221

ROLES PREDEFINIDOS.

– DELETE_CATALOG_ROLE. Privilegio de borrado en la tabla de auditoría de sistema (AUD$).

– EXECUTE_CATALOG_ROLE. Privilegio de ejecución sobre objetos en el diccionario de datos.

– SELECT_CATALOG_ROLE. Privilegio de consulta sobre objetos del diccionario de datos.

• Los roles CONNECT, RESOURCE y DBA se mantienen por compatibilidad con versiones anteriores de Oracle. No se asegura que sigan existiendo en un futuro.

• Se recomienda crear roles específicos en cada bd y asignarles los permisos necesarios, evitando el uso de roles predefinidos, con lo que no surgirán problemas si estos quedan obsoletos en futuras versiones.




222

CREACIÓN DE ROLES.

• Debe poseerse el privilegio CREATE ROLE.

• El nombre debe ser diferente a cualquier nombre de rol o usuario existente.

• Sintaxis:

CREATE ROLE <rol> IDENTIFIED BY <contraseña>;

CREATE ROLE <rol> NOT IDENTIFIED/<>;

• La cláusula IDENTIFIED BY indica como debe ser autorizado antes de usarse por un usuario al que se la ha otorgado.




223

MODIFICACIÓN DE ROLES.

• Un rol solo puede modificarse para cambiar su método de autentificación.

• Debe poseerse el privilegio de sistema ALTER ANY ROLE o haber sido sido otorgado el rol con la opción ADMIN.

• No se ven afectadas las sesiones en las que el rol está ya activo.

• Sintaxis:

ALTER ROLE <rol> NOT IDENTIFIED/ IDENTIFIED BY <contraseña>;




224

ASIGNAR ROLES A USUARIOS.

• Sintaxis:

GRANT <rol> TO <usuario>/<rol>/PUBLIC;

GRANT <rol> TO <usuario>/<rol>/PUBLIC WITH ADMIN OPTION;

• Para que un usuario pueda otorgar un rol debe habérsele concedido con ADMIN OPTION, poseer el privilegio GRANT ANY ROLE, o haberlo creado.

• El usuario que crea el rol implícitamente lo tiene asignado con ADMIN OPTION.




225

PARÁMETRO MAX_ENABLED_ROLES.

• Este parámetro está obsoleto y sólo se mantiene por compatibilidad. Es preferible NO usarlo.

• Es un parámetro de inicialización que define el numero máximo de roles de base de datos activos concurrentemente, incluyendo aquellos contenidos dentro de otros roles, que un usuario puede poseer.

• Un usuario puede activar como máximo 2+MAX_ENABLED_ROLES puesto que cada usuario tiene dos roles adicionales (PUBLIC y y el propio rol del usuario).




226

ROLES POR DEFECTO.

• Un rol por defecto es aquel que automáticamente se activa al conectarse.

• Con la sentencia ALTER USER se limitan los roles por defecto asignados a un usuario. La claúsula puede sólo indicar roles otorgados directamente al usuario con una sentencia GRANT.

• Sintaxis:

ALTER USER <usuario> DEFAULT ROLE <rol1>,…<roln>/ALL [EXCEPT rol1 [,role2]... ] / NONE;




227

ROLES POR DEFECTO.

• La cláusula DEFAULT ROLE se aplica solo a los roles otorgados de forma directa, y no para roles no asignados al usuario o asignados a través de otros roles.

• ALL hace que todos los roles sean por defecto excepto aquellos indicados en la cláusula EXCEPT.

• EXCEPT indica que los roles que le siguen no serán por defecto.

• NONE hace que ninguno de los roles sea por defecto, y los únicos privilegios al efectuarse la conexión serán aquellos asignados directamente.




228

DEASIGNACIÓN DE ROLES.

• Puede hacerlo cualquier usuario con la opción ADMIN OPTION para un rol, también aquellos usuarios con el privilegio GRANT ANY ROLE (pueden revocar cualquier rol).

• Sintaxis:

REVOKE <rol1>, …<roln>FROM <usuario>|<rol>|PUBLIC [, <usuario>|<rol>} ]...

• Con PUBLIC se deasigna el rol de todos los usuarios.




229

BORRADO DE ROLES.

• Debe poseerse el privilegio DROP ANY ROLE o haber sido concedido el rol con ADMIN OPTION.

• Sintaxis:

DROP ROLE <rol>;

• Al borrar un rol se deasigna de todos los usuarios y roles, y se elimina de la base de datos. Las sesiones en las que el rol está activo no se ven afectadas, pero ninguna otra lo podrá usar.




230

ACTIVACIÓN YDESACTIVACIÓN DE ROLES.

• Durante una sesión, el usuario o una aplicación puede usar lasentencia SET ROLE para modificar los roles activos en lasesión. Previamente los roles deben haber sido asignados al usuario.

Al crear un usuario todos los roles asignados son pordefecto, a menos que se limite con ALTER USER.

• No podrá hacerse uso de los privilegios otorgados a través del rol inactivo a menos que también se hayan otorgado de forma directa o a través de otros roles.

• En la siguiente sesión, los roles activos vuelven a ser los roles por defecto.

• La vista SESSION_ROLES informa de aquellos roles que, para el usuario actual, están activos en un momento determinado.




231

ACTIVACIÓN YDESACTIVACIÓN DE ROLES.

• Sintaxis:

SET ROLE <rol> [ IDENTIFIED BY <contraseña>][, <rol> [ IDENTIFIED BY <contraseña>]]…/ALL [ EXCEPT <rol1> , … ,<roln> ] ...]/NONE

• IDENTIFIED BY indica la contraseña del rol al activarlo.

• ALL activa todos los roles excepto los que aparecen en la cláusula EXCEPT (no puede usarse esta opción para activar roles con contraseña).

• NONE desactiva todos los roles en la sesión (solo son activos los privilegios otorgados directamente).




232

VISTAS.

• DATABASE_PROPERTIES ... Propiedades de la bd.

• DBA_USERS ... Usuarios de la bd.

• DBA_ROLES ... Roles existentes en la bd.

• DBA_ROLE_PRIVS ... Roles concedidos a usuarios y roles.

• DBA_SYS_PRIVS ... Privilegios de sistema a usuarios y roles.

• DBA_TAB_PRIVS ... Permisos sobre objetos en la bd.

• DBA_TABLESPACE_GROUPS ... Grupos de espacios temporales.

• DBA_COL_PRIVS ... Permisos sobre columnas de objetos en bd.

• DBA_TS_QUOTAS ... Cuotas de espacio para usuarios.

• DBA_PROFILES ... Perfiles en la bd.




233

VISTAS.

• ROLE_ROLE_PRIVS ... Roles concedidos a otros roles.

• ROLE_SYS_PRIVS ... Privilegios de sistema concedidos a roles.

• ROLE_TAB_PRIVS ... Privilegios sobre objetos concedidos a roles.

• DBA_CONNECT_ROLE_GRANTEES ... Usuarios con privilegio CONNECT.

• USER_PASSWORD_LIMITS ... Parámetros contraseña usuario.

• USER_RESOURCE_LIMITS ... Límites de recursos por usuario.

• SESSION_PRIVS ... Privilegios disponibles en la sesión.

• SESSION_ROLES ... Roles activos en la sesión.

• V$SESSION ... Información de sesión.

GESTIÓN DE USUARIOS Y RECURSOS Administración y Ajuste de Oracle 10g


234

TEMA 8.

TRABAJOS.

TRABAJOS



235

TEMA 8.TRABAJOS (JOBS).

• DBMS_JOB vs. DBMS_SCHEDULER.

• MIGRACION A DBMS_SCHEDULER.– CREACION DE TRABAJOS.– MODIFICACION DE TRABAJOS.– BORRADO DE TRABAJOS.

• PLANIFICADOR (SCHEDULER).

• ARQUITECTURA DEL PLANIFICADOR.

• NOMENCLATURA OBJETOS.

• PRIVILEGIOS PLANIFICADOR.

TRABAJOS Administración y Ajuste de Oracle 10g


236

TEMA 8.TRABAJOS (JOBS).

• PROCEDIMIENTOS PLANIFICADOR.– “CREATE_JOB”. INTERVALO EJECUCION.– “SET _ATTRIBUTE”.– “SET _ATTRIBUTE_NULL”.– “COPY”.– “ENABLE”.– “DISABLE”.– “RUN_JOB”.– “STOP_JOB”.– “DROP_JOB”.

• VISTAS.

TRABAJOS



237

DBMS_JOB vs. DBMS_SCHEDULER.

• Los trabajos son el resultado de la combinación de unaplanificación y un programa, p.ej. código PL/SQL, junto con los argumentos requeridos por dicho programa. Se lanzan a la cola de trabajos, especificando la periodicidad con que deben ser ejecutados.

• Las funciones de planificación se ofrecen a través del paquete DBMS_SCHEDULER, este reemplaza al paquete DBMS_JOB.

• Para gestionar la cola de trabajos se dispone, por tanto, del paquete DBMS_SCHEDULER. Aunque DBMS_JOB sigue estando disponible, no es probable que lo esté en un futuro.

• Dentro del paquete DBMS_SCHEDULER existen diversosprocedimientos como CREATE_JOB, DROP_JOB, STOP_JOB, ... que permiten planificar los trabajos automatizados.



238

DBMS_JOB vs. DBMS_SCHEDULER.

• DBMS_JOB permite ejecutar sólo programas almacenados obloques PL/SQL. DBMS_SCHEDULER puede ejecutar también ejecutables de S.O.

• En DBMS_JOB sólo hay un componente, el trabajo o “job”. EnDBMS_SCHEDULER hay múltiples componentes que incrementan la capacidad de planificación.

• Usando DBMS_SCHEDULER los intervalos de planificación pueden definirse en lenguaje natural y de forma más compleja que con DBMS_JOB, el cual sólo acepta expresiones tipofecha.

• DBMS_SCHEDULER proporciona mayor detalle en cuanto al estado del trabajo y sus fallos, esta información puede consultarse en el diccionario de datos.

TRABAJOS



239

MIGRACION A DBMS_SCHEDULER (I).CREACION DE TRABAJOS.

• Usando DBMS_JOB:

VARIABLE jobno NUMBER;

BEGIN

DBMS_JOB.SUBMIT(:jobno, 'INSERT INTO employees VALUES (7935, ''SALLY'', ''DOGAN'', ''[email protected]'', NULL, SYSDATE, ''AD_PRES'', NULL,NULL, NULL, NULL);', SYSDATE, 'SYSDATE+1');

COMMIT;

END;

/

• Usando DBMS_SCHEDULER:

BEGIN

DBMS_SCHEDULER.CREATE_JOB(

job_name => 'job1',

job_type => 'PLSQL_BLOCK',

job_action => 'INSERT INTO employees VALUES (7935, ''SALLY'', ''DOGAN'',''[email protected]'', NULL, SYSDATE,''AD_PRES'', NULL, NULL, NULL, NULL);');

start_date => SYSDATE,

repeat_interval => 'FREQ = DAILY; INTERVAL = 1');

END;

/



240

MIGRACION A DBMS_SCHEDULER (II).MODIFICACION DE TRABAJOS.


BEGIN

DBMS_JOB.WHAT(31, 'INSERT INTO employees VALUES (7935, ''TOM'', ''DOGAN'', ''[email protected]'', NULL, SYSDATE,''AD_PRES'', NULL, NULL, NULL, NULL);');

COMMIT;

END;

/


BEGIN

DBMS_SCHEDULER.SET_ATTRIBUTE(

name => 'JOB1',

attribute => 'job_action',

value => 'INSERT INTO employees VALUES (7935, ''TOM'', ''DOGAN'', ''[email protected]'', NULL, SYSDATE, ''AD_PRES'', NULL, NULL, NULL, NULL);');

END;

/

TRABAJOS



241

MIGRACION A DBMS_SCHEDULER (III).BORRADO DE TRABAJOS.


BEGIN

DBMS_JOB.REMOVE(14144);

COMMIT;

END;

/


BEGIN

DBMS_SCHEDULER.DROP_JOB('myjob1');

END;

/



242

PLANIFICADOR (SCHEDULER).

• Mediante el planificador puede controlarse cuándo y dónde se ejecutarán los trabajos automatizados. Permite, por ejemplo:

– Planificar trabajos de mantenimiento de la bd como copias de seguridad u otras tareas a realizar durante horas de menor actividad.

– Planificar la ejecución de trabajos en una fecha determinada o basándose en eventos.

– Agrupar trabajos en clases y priorizar entre las mismas (incluso modificar la priorización en función del tiempo).

– Gestionar y monitorizar trabajos.

TRABAJOS



244

ARQUITECTURA DEL PLANIFICADOR.

• Tabla de trabajos.

Hay una por base de datos y almacena informacion tal como el propietario, nivel de “log” o si el trabajo se elimina al finalizar – opción por defecto – (visible mediante la vistaDBA_SCHEDULER_JOBS o las análogas ALL_... y USER_...).

• Proceso coordinador.

Proceso “background”, cjqNNN, que arranca automáticamente cuando un trabajo debe ejecutarse y sedesactiva tras un periodo de inactividad. Se encarga de:

– Controlar y crear los procesos esclavos.– Consultar la tabla de trabajos.– Coger los trabajos de la tabla y colocarlos en memoria

cache. Darlos a los esclavos para su ejecución.

TRABAJOS



245


– Limpiar el conjunto de esclavos cuando no son necesarios.– Desactivarse cuando no hay trabajos planificados.– Despertar cuando debe ejecutarse un nuevo trabajo o se

ha creado un trabajo.– Recuperar los trabajos en ejecución tras el arranque

posterior a un cierre anormal de la bd (p.ej. caida del sistema o “shutdown abort”).

Existe sólo un proceso coordinador por instancia.

• Procesos esclavos.

Su número es ajustado automáticamente por el planificador. Son despertados por el coordinador cuando hay trabajos por ejecutar. Se encargan de:

– Ejecutar el trabajo y realizar las operaciones asociadas



246


(abrir sesión, comenzar la transacción, comenzar la ejecución, finalizar la transacción y cerrar sesión).

– Actualizar el estado del trabajo en la tabla de trabajos reflejando el estado del trabajo.

– Actualizar la cuenta de ejecuciones o fallos del trabajo.– Buscar nuevos trabajos a ejecutar (o ir a dormir si no hay

ninguno).– ...

TRABAJOS



247

PLANIFICADOR. RAC.

• El planificador usa una tabla de trabajos por cada base de datos y un proceso coordinador para cada instancia. Los coordinadores comunican entre sí para guardar información actualizada.



248

NOMENCLATURA OBJETOS.

• Los objetos del planificador se nombran de la misma forma que cualquier otro objeto de la base de datos: “[esquema_usuario].nombre”. Los objetos deben ser únicos en el espacio de nombres.

• Por defecto, los nombres de objetos se almacenan en mayúsculas a menos que estén encerrados en dobles comillas.

TRABAJOS



249

PRIVILEGIOS PLANIFICADOR.

• Para administrar el planificador debe poseerse el rolSCHEDULER_ADMIN (generalmente sólo administradores).

• Es necesario ser restrictivos con la concesión de estos permisos, siendo aconsejable la concesión de privilegios concretos, por ejemplo:

GRANT CREATE JOB TO scott; -crear trabajos,... en su esquema-

GRANT ALTER myjob1 TO scott;

• Una alternativa para administrar el planificador es el privilegio MANAGE SCHEDULER. Por ejemplo:

GRANT MANAGE SCHEDULER TO <usuario>;

El usuario podrá crear, modificar, o borrar ventanas de ejecucion, clases de trabajo o grupos de ventanas.



250


TRABAJOS



251




252


TRABAJOS



253

PROCEDIMIENTOS PLANIFICADOR.

TRABAJOSTRABAJOS Administración y Ajuste de Oracle 10g


254

DBMS_SCHEDULER.PROCEDIMIENTO “CREATE_JOB”.

• Debe indicarse la acción, planificación y atributos del trabajo.

• El propietario del trabajo es el usuario en cuyo esquema se ha creado, el creador del trabajo es el usuario que ha creado el mismo. Un trabajo puede crearse en otro esquema indicando “esquema.nombre_trabajo”.

• Los trabajos se ejecutan con los privilegios del esquema en el cual se crean. El entorno del trabajo cuando se ejecuta esaquel que existía en el momento de su creación.

• Cualquier trabajo puede consultarse una vez creado usando las vistas *_SCHEDULER_JOBS. Por defecto los trabajos secrean deshabilitados y necesitan activarse para serejecutados.

TRABAJOS



255


• Sintaxis:

DBMS_SCHEDULER.CREATE_JOB (job_name IN VARCHAR2,job_type IN VARCHAR2,job_action IN VARCHAR2,number_of_arguments IN PLS_INTEGER DEFAULT 0,start_date IN TIMESTAMP WITH TIME ZONE DEFAULT NULL,repeat_interval IN VARCHAR2 DEFAULT NULL,end_date IN TIMESTAMP WITH TIME ZONE DEFAULT NULL,job_class IN VARCHAR2 DEFAULT 'DEFAULT_JOB_CLASS',enabled IN BOOLEAN DEFAULT FALSE,auto_drop IN BOOLEAN DEFAULT TRUE,comments IN VARCHAR2 DEFAULT NULL);



256


• job_name

Identificador unívoco del trabajo. Si el trabajo reside en otro esquema debe indicarse el nombre de esquema. Para generar el nombre puede usarse el procedimiento “GENERATE_JOB_NAME”

DBMS_SCHEDULER.GENERATE_JOB_NAME (prefijo IN VARCHAR2 DEFAULT 'JOB$_') RETURN VARCHAR2;

• job_type

Tipo de trabajo creado. Algunos de los tipos soportados son:

a) 'PLSQL_BLOCK'. Bloque PL/SQL. En este caso no pueden indicarse argumentos.

b) 'STORED_PROCEDURE'. Procedimiento almacenado o subprograma C externo (sólo procedimientos, no funciones con valor de retorno, son soportados).

TRABAJOS



257


• job_action

Para un bloque PL/SQL, la acción es es ejecutar un código PL/SQL code. Estos bloques deben acabar con un “;” (“my_proc();” o “BEGIN my_proc(); END;” ...)

Para un procedimiento almacenado la acción es el nombre del mismo.

• number_of_arguments. Número de argumentos para el trabajo (0-255, por defecto 0).

• program_name. Nombre del programa asociado altrabajo.

• start_date. Fecha en que el trabajo arrancará. Si “start_date” y “repeat_interval” son nulos, el trabajo se inicia tan pronto sea habilitado.

• event_condition. Expresión de eventos.



258


• queue_spec. Cola de eventos.

• repeat_interval. Intervalo de ejecución. Si no se indica el trabajo sólo se ejecuta una vez.

• schedule_name. Nombre de la planificación, window, o window group asociada al trabajo.

• end_date. Fecha tras la que el trabajo no se ejecutará más (el STATE del trabajo se asigna a COMPLETED, y se deshabilita). Si no se indica fecha, el trabajo se repetirá indefinidamente a menos que se alcance “max_runs” o “max_failures” en cuyo caso el trabajo para.

• job_priority. Prioridad del trabajo entre los que integran la clase (de 1 -máxima- a 5 -mínima-, por defecto 3).

• comments. Comentarios.

TRABAJOS



259


• enabled. Indica si el trabajo se crea habilitado o no (TRUE o FALSE). Por defecto su valor es FALSE, por tanto el planificador lo ignora y no se envía a ejecución. Para ser ejecutado el argumento debe tener valor TRUE o ser activado con el procedimiento ENABLE.

• auto_drop. Si su valor es TRUE, el trabajo será borrado tras ser deshabilitado o completarse su ejecución (cuando llega a su fecha final, alcanza el número de ejecuciones indicadas por “max_runs” -fijadas con SET_ATTRIBUTE- o sólo debe ejecutarse una vez). Un trabajo se deshabilita cuando falla las veces indicadas por “max_failures times” (fijadas con SET_ATTRIBUTE).

Si el valor es FALSE, el trabajo no se borra hasta hacerlo explícitamente con el procedimiento DROP_JOB.

Por defecto los trabajos se crean con “auto_drop” igual a TRUE.



260


• Ejemplo:

BEGINDBMS_SCHEDULER.CREATE_JOB (job_name => 'my_emp_job1',job_type => 'PLSQL_BLOCK',job_action => 'INSERT INTO sales VALUES( 7987, ''SALLY'',

''ANALYST'', NULL, NULL, NULL, NULL, NULL);',start_date => '28-APR-03 07.00.00 PM Australia/Sydney',repeat_interval => 'FREQ=DAILY;INTERVAL=2',end_date => '20-NOV-04 07.00.00 PM Australia/Sydney',comments => 'My new job');

END;/

TRABAJOS



261

INTERVALO EJECUCION.

• Está definido por el valor del atributo “repeat_interval” o por el dela planificación que referencia el trabajo. Si no se indica valor para “repeat_interval” el trabajo sólo se ejecuta una vez (indicada en “start date”).

• Puede indicarse de dos formas:

– Mediante una expresión acorde a “Scheduler Calendaring Syntax” (véase PL/SQL Packages and Types Reference para una descripción detallada). Por ejemplo:

a) Ejecución todos los viernes (los ejemplos son equivalentes).FREQ=DAILY; BYDAY=FRI;FREQ=WEEKLY; BYDAY=FRI;FREQ=YEARLY; BYDAY=FRI;



262


b) Ultimo día del mes.FREQ=MONTHLY; BYMONTHDAY=-1;

c) Ejecución el 10 de marzo.FREQ=YEARLY; BYMONTH=MAR; BYMONTHDAY=10;FREQ=YEARLY; BYDATE=0310;

d) Cada 10 dias.FREQ=DAILY; INTERVAL=10;

e) Diariamente a las 4, 5 y 6 de la tarde.FREQ=DAILY; BYHOUR=16,17,18;

f) Cada 50 horas.FREQ=HOURLY; INTERVAL=50;

g) Cada hora durante los tres primeros días del mes.FREQ=HOURLY; BYMONTHDAY=1,2,3;

TRABAJOS



263


– Mediante una expresión PL/SQL . Por ejemplo:

BEGINDBMS_SCHEDULER.CREATE_JOB (job_name => 'scott.my_job2',start_date => '15-JUL-04 01.00.00 AM Europe/Warsaw',repeat_interval => 'SYSTIMESTAMP + INTERVAL '30' MINUTE',end_date => '15-SEP-04 01.00.00 AM Europe/Warsaw',comments => 'Comentarios');

END;/

Supone la ejecución por primera vez el 15 de julio y luego cada 30 minutos hasta el 15 de septiembre.



264

DBMS_SCHEDULER.PROCEDIMIENTO “SET _ATTRIBUTE”.

• Sintaxis:

DBMS_SCHEDULER.SET_ATTRIBUTE (name IN VARCHAR2,attribute IN VARCHAR2,value IN [VARCHAR2, TIMESTAMP WITH TIMEZONE,PLS_INTEGER, BOOLEAN, INTERVAL DAY TO SECOND],<value2 IN VARCHAR2 DEFAULT NULL>);

Name ... nombre del objeto.Attribute ... atributo a modificar.Value ... nuevo valor (no puede ser NULL). Para fijar un atributo a

NULL debe usarse el procedimiento SET_ATTRIBUTE_NULL.Value2 ... Usado en atributos que pueden tener dos valores

asociados.

Cualquier parámetro, excepto job_name, puede modificarse.

TRABAJOS



265

• Algunos de los valores que pueden modificarse son:

– logging_level. Indica qué información se guarda: DBMS_SCHEDULER.LOGGING_OFF -ninguna-, DBMS_SCHEDULER.LOGGING_RUNS -información sobre ejecuciones- y DBMS_SCHEDULER.LOGGING_FULL -información sobre creación, habilitación, modificación, ...-.

– restartable. Indica si un trabajo se rearranca en caso de fallo. Por defecto su valor es FALSE.

– max_failures. Número de veces que un trabajo puede fallar consecutivamente antes de ser deshabilitado (en este caso su STATE es puesto a BROKEN). Por defecto NULL, nuevas instancias del trabajo arrancan independientemente del número de fallos previos.

– max_runs. Número máximo de ejecuciones consecutivas. Al alcanzarlas, el trabajo se deshabilita y su estado pasa a ser COMPLETED. Por defecto es NULL, con lo que el trabajo se repite indefinidamente o hasta alcanzar “end_date” o “max_failures”.

TRABAJOS




266

– job_action

– job_type

– repeat_interval

– start_date

– end_date

– comments

– auto_drop. Indica si el trabajo debe ser borrado después de completar su ejecución.

TRABAJOS




267

DBMS_SCHEDULER.PROC. “SET _ATTRIBUTE_NULL”.

• Sintaxis:

DBMS_SCHEDULER.SET_ATTRIBUTE_NULL (name IN VARCHAR2,attribute IN VARCHAR2);

Este procedimiento asigna el valor NULL a un atributo.



268

DBMS_SCHEDULER.PROCEDIMIENTO “COPY”.

• Sintaxis:

DBMS_SCHEDULER.COPY_JOB (old_job IN VARCHAR2,new_job IN VARCHAR2);

• Copia todos los atributos de un trabajo existente a un nuevo trabajo, este es creado deshabilitado -el estado del trabajo original no varía-.

• Esta operación requiere tener privilegios para crear un trabajo en el esquema del nuevo trabajo (CREATE JOB para el propio esquema o CREATE ANY JOB en otro caso). Si el trabajo original no está en el propio esquema de usuario se necesita también privilegio ALTER en el mismo o

• poseer el privilegio CREATE ANY JOB.

TRABAJOS



269

DBMS_SCHEDULER.PROCEDIMIENTO “ENABLE”.

• Sintaxis:

DBMS_SCHEDULER.ENABLE (name IN VARCHAR2);

• Permite activar un trabajo, programa, ... todos los cuales, por defecto, son creados deshabilitados. A partir de la activación el proceso coordinador puede llevarlo a ejecución.

• Se llevan a cabo operaciones de validación previas a la habilitación. Si fallan, no se habilita el objeto y se genera un error.

• Se debe ser el propietario del objeto, tener privilegio ALTER en el mismo o poseer el privilegio CREATE ANY JOB.



270

DBMS_SCHEDULER.PROCEDIMIENTO “DISABLE”.

• Sintaxis:

DBMS_SCHEDULER.DISABLE (name IN VARCHAR2,force IN BOOLEAN DEFAULT FALSE);

• Permite desactivar un trabajo, programa, ... puede indicarse en “name”una lista de nombres separados por comas. Deshabilitar un objeto ya deshabilitado no genera error.

• Se debe ser el propietario del objeto, tener privilegio ALTER en el mismo o poseer el privilegio CREATE ANY JOB.

• Cuando un trabajo se deshabilita su estado se modifica a “disabled”. Si “force” es FALSE y el trabajo está ejecutándose se develve un error; si “force” es TRUE, se deshabilita el trabajo pero se permite finalizar la instancia del mismo que está ejecutándose.

TRABAJOS



271

DBMS_SCHEDULER.PROCEDIMIENTO “RUN_JOB”.

• Sintaxis:

DBMS_SCHEDULER.RUN_JOB (job_name IN VARCHAR2,use_current_session IN BOOLEAN DEFAULT TRUE);

Ejecuta un trabajo de forma inmediata. Usar RUN_JOB requiere bien ser el propietario del trabajo, bien tener privilegio ALTER en dicho trabajo. También pueden ejecutarse trabajos con el privilegio CREATE ANY JOB.

• Si use_current_session es TRUE, el trabajo se ejecuta en la sesion quellama a RUN_JOB. Esta forma de ejecutarse no hace que se modifique loscontadores “failure_count” y “run_count”, el trabajo se reflejará en el “log” del mismo.

• Si use_current_session es FALSE: es preciso chequear el “log” para obtener información sobre la ejecución del trabajo; “run_count”, “last_start_date”, “last_run_duration” y “failure_count” son actualizados yRUN_JOB falla si hay un trabajo planificado ejecutándose.



272

DBMS_SCHEDULER.PROCEDIMIENTO “STOP_JOB”.

• Sintaxis:

DBMS_SCHEDULER.STOP_JOB (job_name IN VARCHAR2force IN BOOLEAN DEFAULT FALSE);

• Permite parar trabajos en ejecución. Tras la parada de un trabajo, el estado de este pasa a ser STOPPED si sólo se ejecutaba una vez; mientras que el de uno programado para repetirse múltiples veces pasa a ser SCHEDULED o COMPLETED (en función de si la siguiente ejecución estabaplanificada).

• Si el argumento “force” de la llamada es FALSE, el planificador intenta parar el trabajo ordenadamente y genera un error si falla en su intento. Si su valor es TRUE, se interrumpe inmediatamente el proceso esclavo(Oracle sólo recomienda esta opción si ha fallado la parada ordenada).

TRABAJOS



273

DBMS_SCHEDULER.PROCEDIMIENTO “DROP_JOB”.

• Sintaxis:

DBMS_SCHEDULER.DROP_JOB (job_name IN VARCHAR2,force IN BOOLEAN DEFAULT FALSE);

• Permite borrar un trabajo (desaparece de cualquier vista, por tanto, y no vuelve a ejecutarse).

• Requiere ser el propietario del trabajo, tener el privilegio ALTER sobre el mismo, o poseer el privilegio de sistema CREATE ANY JOB.

• Si el argumento “force” es FALSE, y una instancia del trabajo está ejecutándose se genera un error. Si su valor es TRUE, el planificador intenta parar la instancia del trabajo y después lo borra.



274

VISTAS.

• DBA_SCHEDULER_JOB_ARGS. Argumentos de trabajos.

• DBA_SCHEDULER_JOB_LOG. Cambios de estado de trabajos.

• DBA_SCHEDULER_JOB_RUN_DETAILS. Detalles sobre la ejecución de trabajos.

• DBA_SCHEDULER_JOBS. Información sobre trabajos en la bd.

• DBA_SCHEDULER_RUNNING_JOBS. Trabajos en ejecución.

• DBA_SCHEDULER_SCHEDULES. Planificación de trabajos.

• SESSION_PRIVS. Privilegios de sistema actuales.

• V$LOCK. Bloqueos mantenidos por el servidor.

• V$SESSION. Información de sesiones actuales.

TRABAJOS



275

TEMA 9.

AUDITORÍA.

AUDITORIA Administración y Ajuste de Oracle 10g


276

TEMA 9.AUDITORÍA.

• Auditoría.

• Tipos de auditoría.

• Registros de auditoría. “Audit trail”.

• Parámetro “audit_trail”.

• Auditoría de usuarios administradores.

• Información “audit trail” de sistema operativo.

• Auditoría de sentencias. opciones.

• Auditoría de privilegios. Privilegios auditables.AUDITORIA



277

TEMA 9.AUDITORÍA.

• Auditoría de esquema. Opciones.

• Auditoría y “flashback”.

• Auditoría de grano fino. Paquete dbms_fga. Procedimientos.

• Desactivación. Sentencia noaudit.

• Desactivación de la auditoría.

• Control y protección del “audit trail”.

• Auditoría. Recomendaciones.

• Vistas.AUDITORIA Administración y Ajuste de Oracle 10g


278

AUDITORÍA.

• Mediante la auditoría se intenta monitorizar y registrar acciones en la base de datos con el fin de :

– Investigar actividades maliciosas (borrado de tablas, ..)

– Detectar privilegios incorrectamente otorgados a usuarios (que permiten realizar acciones inapropiadas, las cuales son detectadas)

– Recoger datos sobre actividades concretas (tablas que se actualizan, usuarios concurrentes, …)

– Detectar problemas con la implementación de políticas de seguridad (puntos débiles que generan registros)

• Puede ser más o menos general, permitiendo auditar:

– Ejecuciones de sentencias exitosas, fallidas o ambas.

– Ejecución de sentencias por sesión o por lanzamiento de sentencia.

– Usuarios concretos o todos los usuarios.

AUDITORIA



279

TIPOS DE AUDITORÍA.

• Existen varios tipos:

- De sentencias. Seleccionando un tipo concreto de las mismas, que afectan a una determinada clase de objetos de base de datos (por ejemplo, AUDIT TABLE que auditacreate table, alter table y drop table).

- De privilegios. Auditoría de privilegios de sistema (por ejemplo, AUDIT CREATE TABLE).

- De esquema. Sentencias específicas sobre objetos de un esquema concreto (p. ej. AUDIT SELECT ON <nombre_tabla>).

- De grano fino (“fine grained”). Acceso a datos concretos y cambios en los mismos a nivel columna.



280

TIPOS DE AUDITORÍA.

• Si se habilitan opciones de auditoría semejantes de sentenciay de privilegio, sólo se genera un registro; por ej. la auditoría de TABLE -sentencia- y CREATE TABLE -privilegio- sólo genera un registro al crear una tabla. La auditoría de privilegios es más restringida que la de sentencias pues audita sentencias específicas.

AUDITORIA



281

REGISTROS DE AUDITORÍA.“AUDIT TRAIL”.

• La información de auditoría se almacena en los registros deauditoría, que incluyen datos como:

– Usuario. Identificador de sesión y terminal– Nombre del esquema accedido– Operación y código de operación– Fecha y hora

• En la auditoría básica (sentencias, privilegios, esquemas) los registros se guardan en la tabla de diccionario de datos SYS.AUD$ (“db audit trail”) o en ficheros de sistema operativo (“operating system audit trail”). Está codificada y no es legible. En el primer caso, existen diferentes vistas que permiten usar la información almacenada como DBA_AUDIT_TRAIL.

• En la auditoría de grano fino, los registros se escriben en DBA_FGA_AUDIT_TRAIL (tabla SYS.FGA_LOG$).



282


• El registro de información puede estar habilitado o deshabilitado.Aquellos usuarios autorizados de la base de datos pueden determinar las opciones de auditoría, pero el decidir si se graba o no información pertenece al administrador.

• Cuando la auditoría está habilitada se genera un registro durante la fase de la ejecución de la sentencia. La generación e inserción de un registro de auditoría es independiente de como acabe la transacción del usuario; si esta es deshecha (“rollback”), el registro de auditoría permanece (“commit”).

• Las opciones de auditoría para sentencias y privilegios en vigor cuando un usuario se conecta permanecen así durante la sesión (auque se modifiquen o establezcan nuevas opciones, que sólo tendrán efecto en una nueva sesión). Por el contrario, cambios en las opciones sobre esquema se aplican inmediatamente para la sesión en curso.

AUDITORIA



283


• La auditoría de grano fino se aplica a objetos individuales y, por tanto,no se ve afectada por la auditoría básica que está habilitada o no para la bd al completo.

• El “audit trail” no almacena información sobre los valores de los datos que pudieran estar involucrados en una determinada sentencia que está siendo auditada. Por ejemplo, los valores actuales y anteriores de una fila modificada no se guardan al auditar la sentencia UPDATE(puede hacerse usando disparadores de base de datos, “triggers”).

CREATE TRIGGER audit_emp_salariesAFTER INSERT OR DELETE OR UPDATE ON employee_salariesfor each row

beginif (:new.salary> :old.salary * 1.10) then insert into emp_salary_audit

values (:employee_no,:old.salary,:new.salary,user,sysdate);endif;

end;



284


• Independientemente de si la auditoría esta habilitada ono, siempre se registran algunos tipos de acciones que son escritos a ficheros de sistema operativo (ficheros en $ORACLE_HOME/rdbms/audit):

– “Startup” de la instancia. Se almacena el usuario desistema operativo que lo hace, el identificador de terminal del usuario, fecha y hora. El “audit trail” de bd no está disponible hasta que se ha arrancado satisfactoriamente esta.

– “Shutdown” de la instancia. Almacena el usuario desistema operativo, el identificador de terminal del usuario y fecha y hora.

– Conexiones a la base de datos con privilegios de administrador.

AUDITORIA



285

AUDITORÍA. PARAMETRO “AUDIT_TRAIL”.

• Para comenzar a auditar debe asignarse al parámetro deinicialización, estático, AUDIT_TRAIL el valor DB (auditoría en base de datos excepto para los valores que siempre se escriben a s.o.). Elvalor NONE, valor por defecto, deshabilita la auditoría.

• El valor OS indica que la auditoría debe llevarse a sistema operativo. El parámetro AUDIT_FILE_DEST señala donde se guardan los ficheros, así como los registros de auditoría para SYS (por defecto$ORACLE_BASE/$DB_UNIQUE_NAME/adump y, en segundo lugar,$ORACLE_HOME/rdbms/audit).

• El valor XML indica que los registros se escriben como ficheros xml enel s.o.. Pueden consultarse mediante la vista V$XML_AUDIT_TRAIL.

• Para auditar una sentencia SQL o privilegio debe poseerse el privilegiode sistema “AUDIT SYSTEM”. Para auditar operaciones sobre unobjeto, debe pertenecer al esquema o tener privilegio “AUDIT ANY”.

• Habilitar la auditoría de grano fino o la del SYS no precisa indicarvalor para AUDIT_TRAIL.



286

AUDITORIA DE USUARIOS ADMINISTRADORES.

• El parámetro de inicialización AUDIT_SYS_OPERATIONS- estático- permite especificar la auditoría de aquellas sesiones de usuarios conectados como SYS (privilegio SYSDBA). Los registros generados son escritos en el “audit trail” de sistema operativo, no depende del valordel parámetro AUDIT_TRAIL.

• Si su valor es TRUE (AUDIT_SYS_OPERATIONS=TRUE), se auditan dichas operaciones.

• Si su valor es FALSE, valor por defecto, no son auditadas (AUDIT_SYS_OPERATIONS=FALSE).

AUDITORIA



287

AUDITORÍA BD vs SO.

• El almacenamiento de la auditoría en base de datos tienediferentes ventajas:

– Pueden usarse ciertas vistas predefinidas, existentes en el diccionario de base de datos, para consultar de forma sencilla el “audit trail” (como dba_audit_trail).

– Pueden usarse herramientas Oracle de generación de informes, como Oracle Reports.

– Evita la ejecución de eventos si el “audit trail” no puede grabar los registros que se generan.

• Por otra parte, la auditoría en sistema operativo podría ayudara examinar la actividad global del sistema con mayor facilidad; al estar todos los registros de auditoría (de Oracle y de otras herramientas) en un mismo lugar. También podría ser más seguro al requerir permisos concretos para acceder a los ficheros.



288

INFORMACION “AUDIT TRAIL” DE SISTEMA OPERATIVO.

• Los registros de auditoría escritos a ficheros de sistemaoperativo contienen información codificada que incluye los campos:

– Código de operación (“action code”). Debe consultarse la tabla AUDIT_ACTIONS, esta muestra la descripción de los códigos de operación.

– Privilegios. Privilegios de sistema usados para realizar la acción. Consultar la tabla SYSTEM_PRIVILEGE_MAP.

– Terminación (“completion code”). Describe el resultado; si hubo éxito se devuelve un valor cero, en caso contrario un código de error.

AUDITORIA



289

AUDITORÍA DE SENTENCIAS.

• Sintaxis:

AUDIT <sentencia1, … sentencian>/ALLBY <usuario1, … usuarion>BY SESSION/ACCESSWHENEVER SUCESSFUL/NOT SUCCESSFUL;

• La cláusula BY <usuario> permite restringir la auditoría sólo a aquellas sentencias ejecutadas por los usuarios indicados.

• La cláusula BY SESSION, clausula por defecto, indica que se desea un sólo registro para todas las sentencias SQL y operaciones del mismo tipo ejecutadas en la misma sesión.



290


• La cláusula BY ACCESS indica que se desea un registro para cada sentencia SQL y operación auditadas. Si se auditan sentencias de definición de datos del lenguaje (DDL) siempre se audita por acceso.

• La cláusula WHENEVER SUCESSFUL, permite auditar sólo sentencias SQL y operaciones que surten efecto.

• La cláusula WHENEVER NOT SUCESSFUL, permite auditar sólo sentencias SQL y operaciones que fallan o generan errores.

• Si se omiten las dos opciones anteriores, se realiza la auditoría independientemente del éxito o fallo de la sentencia.

AUDITORIA



291


• Nota general: Si se configura la auditoría por s.o., la cláusula BY SESSION equivale a BY ACCESS. Se genera un registro cada vez que se realiza un acceso.

• Nota general: Para cualquier tipo de auditoría (sentencia, privilegio o sistema), si se opta por auditar “NOT SUCCESSFUL” se generan registros sólo si el fallo se produce por alguna razón relacionada con la opción auditada. Por ejemplo, no se produce registro si una sentencia falla por no tener cuota estando auditando CREATE TABLE.



292

AUDITORÍA DE SENTENCIAS.OPCIONES.

Create role / alter role / drop role / set roleRole

Create public synonym / Drop public synonym

Public synonym

Create public database link / drop public database link

Public database link

Create function / create package / create package body / create procedure / drop function / drop package / drop procedure

Procedure

Todas las sentencias SQL que fallan por no existir un determinado objeto

Not exists

Create / alter / analyze /drop indexIndex

Create database link / drop database linkDatabase link

Sentencias SQL auditadas.Opcion

AUDITORIA



293


Create table / drop table / truncate tableTable

Create tablespace / drop tablespace / alter tablespace

Tablespace

Grant y revoke privilegios_sistema y rolesSystem grant

Audit sentencias_sql / Noaudit sentencias_sql

System audit

Create synonym / drop synonymSynonym

Conexiones - valor por defecto y único BY SESSION -Session

Create sequence / drop sequenceSequence

Create rollback segment/ alter rollback segment / drop rollback segment

Rollback Statement

Sentencias SQL auditadas.Opción



294


Grant / revoke <privilegio> on <secuencia>Grant sequence

Grant / revoke <privilegio> on <tabla, vista, vista materializada>

Grant table

Grant / revoke <privilegio> on <procedimiento, funcion, paquete>

Grant procedure

Delete from <tabla>, <vista>Delete table

Alter tableAlter table

Create view /drop viewView

Create user / alter user /drop userUser

Create trigger / drop trigger /alter triggerTrigger


AUDITORIA



295


Cualquier sentencia que contenga sequence.CURRVAL o sequence.NEXTVAL

Select sequence

Update <tabla, vista>Update table

Select from <tabla, vista, vista materializada>

Select table

Lock table <tabla, vista>Lock table

Insert into <tabla, vista>Insert table




296

AUDITORÍA DE PRIVILEGIOS.

• Sintaxis:

AUDIT <priv_sistema1, … priv_sisteman>/ALL PRIVILEGES

BY <usuario1, … usuarion>BY SESSION/ACCESSWHENEVER SUCESSFUL/NOT SUCCESSFUL;

• La cláusula ALL PRIVILEGES, indica que debe auditarse todo privilegio de sistema.

• Toda la auditoría de privilegios sobre sentencias DDL se hace por acceso. Por defecto es por sesión.

AUDITORIA



297

PRIVILEGIOS AUDITABLES.

ALTER DATABASE ALTER SYSTEM AUDIT SYSTEM

CREATE DATABASE LINK CREATE PUBLIC DATABASE LINK DROP PUBLIC DATABASE LINK

CREATE PROCEDURECREATE ANY PROCEDUREALTER ANY PROCEDUREDROP ANY PROCEDUREEXECUTE ANY PROCEDURE

CREATE PROFILE ALTER PROFILE DROP PROFILE

CREATE ROLE ALTER ANY ROLE DROP ANY ROLE

CREATE ROLLBACK SEGMENT ALTER ROLLBACK SEGMENT DROP ROLLBACK SEGMENT

CREATE SESSIONALTER SESSION



298

PRIVILEGIOS AUDITABLES.

CREATE ANY TABLE / ANY INDEX ALTER ANY TABLE / ANY INDEX DELETE ANY TABLE DROP ANY TABLE / ANY INDEX INSERT ANY TABLE UPDATE ANY TABLE SELECT ANY TABLE

CREATE USER ALTER USER DROP USER

CREATE VIEW CREATE ANY VIEW DROP ANY VIEW

ANALYZE ANY AUDIT ANY COMMENT ANY TABLE

AUDITORIA



299

AUDITORÍA DE ESQUEMA.

• Sintaxis:

AUDIT <clausula_objeto1, … clausula_objeton>/ALLON <esquema>.objeto_auditado/DEFAULTBY SESSION/ACCESSWHENEVER SUCESSFUL/NOT SUCCESSFUL;

• La cláusula ALL indica todas las opciones posibles sobre un tipo de objeto concreto.

• Mediante la cláusula ON DEFAULT se establece pordefecto las opciones indicadas para todo objeto creado con posterioridad. Al establecerlas permanecen aquellas definidas por defecto para objetos creados previamente (pueden cambiarse indicando explícitamente el objeto).



300

AUDITORÍA DE ESQUEMA.

• Puede auditarse todas las sentencias SELECT y DML permitidas por los privilegios de objetos.

• No pueden auditarse procedimientos incluidos en paquetes, aunque sí procedimientos y funciones individuales y también paquetes.

• Si se habilita afecta a todos los usuarios de la bd.

AUDITORIA



301

AUDITORÍA DE ESQUEMA.OPCIONES.

• Tablas.

– Alter / audit / comment / delete / grant / index / insert / lockrename / select /update / flashback (sólo a consultas flashback)

• Vistas.

– Audit / comment / delete / grant / insert / lock rename / select /update / flashback (sólo a consultas flashback)

• Secuencias.

– Alter / audit / grant / select

• Procedimientos.

– Audit / execute / grant / rename

• Vistas materializadas.

– Alter / audit / comment / delete / index / insert / lock / select /update



302

AUDITORÍA Y “FLASHBACK”.

• Para usar las prestaciones “flashback”, la bd debe estar enmodo automático de “undo”.

• La vista FLASHBACK_TRANSACTION_QUERY muestra información acerca de las transacciones realizadas en la bd. Si se han modificado datos en una tabla, la vista muestra información sobre los mismos y señala la sentencia precisa (campo UNDO_SQL) que permite deshacerlos.

• “Flashback Version Query” hace posible ver todos los cambios producidos en una fila de una tabla en un periodo de tiempo concreto. FVQ permite añadir una cláusula VERSIONS a la sentencia SELECT que indique un rango SCN o temporal en el que se desea consultar las modificaciones. La sentencia también puede devolver información sobre la transacción responsable del cambio (VERSIONS_XID).

AUDITORIA



303


• Para ejecutar “flashback query” es necesario el privilegio SELECT sobre los objetos, además bien el privilegio FLASHBACK sobre los objetos, bien FLASHBACK ANY TABLE(permite ejecutarla sobre cualquier tabla, vista o vista materializada en cualquier esquema).

• Puede recuperarse información a través de distintas pseudocolumnas :

– VERSIONS_STARTTIME. Fecha de la primera versión de las filas devueltas por la consulta.

– VERSIONS_STARTSCN. Idem para SCN.– VERSIONS_ENDTIME. Fecha de la última versión de las filas devueltas por

la consulta.– VERSIONS_ENDSCN. Idem para SCN– VERSIONS_XID. Transacción que generó la versión.– VERSIONS_OPERATION. Operación que dió lugar a la versión (I -insert-, U

-update- o D -delete-).



304


• Clausula FLASHBACK:

• AS OF pemite recuperar la version de las filas a un momento en el tiempo o SCN particular.

• VERSIONS permite recuperar múltiples versiones validades de las filas entre dos SCN o momentos en el tiempo.MINVALUE y MAXVALUE se refieren a los datos más antiguo y más reciente respectivamente.

AUDITORIA



305

AUDITORÍA Y RECUPERACION DE TABLAS.“FLASHBACK TABLE”.

• Es posible restaurar una tabla a un estado anterior a aquel donde tuvieron lugar una serie de cambios mediante la sentencia FLASHBACK TABLE.

Nota: Esta posibilidad será analizada en relacion a los mecanismos de copias de seguridad.



306

AUDITORÍA DE GRANO FINO.

• Para llevarla a cabo NO es preciso habilitar la auditoria básica(“audit trail”).

• Permite monitorizar accesos a datos basándose en su contenido y auditar sentencias SELECT y DML en tablas y vistas mediante la creación de una política de auditoría al efecto.

• Se usa el paquete DBMS_FGA y sus procedimientos asociados, generándose apuntes en el “audit trail” de grano fino (SYS.FGA_LOG$, accesible a través de la vista DBA_FGA_AUDIT_TRAIL).

• Este tipo de auditoría permite indicar columnas singulares, relevantes, que precisan ser auditadas (por ejemplo: dni, ayudas sociales, datos de salud, ...) -caso de no hacerlo se aplica a todas las columnas-; así como establecer acciones a llevar a cabo si se produce el acceso conforme a la política de auditoría implementada.

AUDITORIA



307


• Proporciona las siguientes funcionalidades:

– Usar políticas diferenciadas para INSERT, UPDATE, DELETE, y SELECT; y poder tener varias de ellas asociadas a cada tabla.

– Activar la auditoria sólo cuando es necesaria (por ejemplo, con información crítica como el salario o datos de salud) y sólo si es referenciada una columna concreta.



308


• En el ejemplo se auditan las sentencias INSERT, UPDATE, DELETE, y SELECT en la tabla “hr.emp”, controlando cualquier acceso a la columna “salary” de empleados pertenecientes al departamento “sales”:

DBMS_FGA.ADD_POLICY(object_schema => 'hr',object_name => 'emp',policy_name => 'chk_hr_emp',audit_condition => 'dept = ''SALES'' ',audit_column => 'salary'statement_types => 'insert,update,delete,select');

• Cualquiera de las sentencias siguientes genera un registro:

SELECT count(*) FROM hr.emp WHERE dept = 'SALES' and salary > 10000000;SELECT salary FROM hr.emp WHERE dept = 'SALES';DELETE from hr.emp where salary >1000000;

AUDITORIA



309

PAQUETE DBMS_FGA.PROCEDIMIENTO ADD_POLICY.

• Procedimiento ADD_POLICY.

Permite crear una política de auditoría (hasta un máximo de 256 sobre una tabla o vista).

DBMS_FGA.ADD_POLICY(object_schema VARCHAR2,object_name VARCHAR2,policy_name VARCHAR2,audit_condition VARCHAR2,audit_column VARCHAR2,handler_schema VARCHAR2,handler_module VARCHAR2,enable BOOLEAN,statement_types VARCHAR2,audit_trail BINARY_INTEGER IN DEFAULT,audit_column_opts BINARY_INTEGER IN DEFAULT);



310


AUDITORIA



311


– Ejemplo.

DBMS_FGA.ADD_POLICY(object_schema => 'scott', object_name=>'emp', policy_name => 'mypolicy1', audit_condition => 'sal < 100', audit_column =>'comm, credit_card, expirn_date', handler_schema => NULL, handler_module => NULL, enable => TRUE, statement_types=> 'INSERT, UPDATE', audit_trail => DBMS_FGA.DB+DBMS_FGA.EXTENDED, audit_column_opts => DBMS_FGA.ALL_COLUMNS);



312

PAQUETE DBMS_FGA.PROCEDIMIENTO DISABLE_POLICY.

• Procedimiento DISABLE_POLICY.

Deshabilita una política de auditoría.

DBMS_FGA.DISABLE_POLICY(object_schema VARCHAR2,object_name VARCHAR2,policy_name VARCHAR2 );

AUDITORIA



313

PAQUETE DBMS_FGA.PROCEDIMIENTO ENABLE_POLICY.

• Procedimiento ENABLE_POLICY.

Habilita una política de auditoría.

DBMS_FGA.ENABLE_POLICY(object_schema VARCHAR2,object_name VARCHAR2,policy_name VARCHAR2enable BOOLEAN);



314

PAQUETE DBMS_FGA.PROCEDIMIENTO DROP_POLICY.

• Procedimiento DROP_POLICY.

Borra una política de auditoría.

DBMS_FGA.DROP_POLICY(object_schema VARCHAR2,object_name VARCHAR2,policy_name VARCHAR2);

AUDITORIA



315

DESACTIVACIÓN.SENTENCIA NOAUDIT.

• Para desactivar la auditoría de una sentencia es necesario poseer el privilegio de sistema “AUDIT SYSTEM”.

• Para detener la auditoría sobre un objeto, debe pertenecer al esquema o tener el privilegio “AUDIT ANY”.

• La sintaxis de NOAUDIT es igual a la de AUDIT (para cada sentencia de auditoría es necesaria una sentencia NOAUDIT que la deshabilite).



316

DESACTIVACIÓN.SENTENCIA NOAUDIT.

• Sintaxis:

NOAUDIT <sentencia1, … sentencian>/ALLBY <usuario1, … usuarion>WHENEVER SUCESSFUL/NOT SUCCESSFUL;

NOAUDIT <priv_sistema1, … priv_sisteman>/ALL PRIVILEGES

BY <usuario1, … usuarion>WHENEVER SUCESSFUL/NOT SUCCESSFUL;

NOAUDIT <clausula_objeto1, … clausula_objeton>/ALLON <esquema>.objeto_auditado/DEFAULTWHENEVER SUCESSFUL/NOT SUCCESSFUL;

AUDITORIA



317

DESACTIVACIÓNDE LA AUDITORÍA.

• Mediante la sentencia NOAUDIT sólo se desactivan opciones de auditoría básica. Para deshabilitar la auditoría básica debe modificarse el parámetro de inicialización AUDIT_TRAIL.



318

CONTROL DEL “AUDIT TRAIL”.

• Si el “audit trail” se llena de forma que no pueden insertarse más registros, las sentencias auditadas no pueden ejecutarse correctamente hasta que se vacía, y se generan errores (por ejemplo, si se está auditando CREATE SESSION no se podrán conectar usuarios a la bd).

• El tamaño máximo de SYS.AUD$ depende de los parámetros de almacenamiento, “default storage”, del espacio SYSTEM. Pueden modificarse los parámetros para SYS.AUD$.

AUDITORIA



319


• La gestión del “audit trail”, el único objeto de SYSdirectamente modificable, es similar a la de otra tabla; pueden borrarse registros con la sentencia DELETE:

- DELETE FROM SYS.AUD$;

- DELETE FROM SYS.AUD$ WHERE OBJ$NAME= <nombre_objeto>;

• Sólo el usuario SYS, un usuario al que se haya concedido el privilegio DELETE sobre SYS.AUD$, o un usuario con elprivilegio DELETE ANY TABLE pueden efectuar el borrado.

• La información del “audit trail” puede archivarse copiándola a una tabla (INSERT INTO <tabla> SELECT ... FROM SYS.AUD$) o ser exportada.



320


• Después del borrado de registros, las extensiones adquiridas para esta tabla permanecen. Este espacio puede reducirse:

- Copiar el “audit trail” a otra tabla o exportarlo

- Conectarse como usuario administrador y truncar SYS.AUD$ (sentencia TRUNCATE).

- Cargar los datos anteriormente salvados que interese mantener accesibles.

AUDITORIA



321

PROTECCIÓN DEL “AUDIT TRAIL”.

• Debe protegerse de borrados no autorizados:

- Otorgar el privilegio DELETE ANY TABLE solo a usuarios administradores.

- Auditar cualquier cambio que se realice en el “audit trail” mediante la sentencia

AUDIT SELECT, INSERT, UPDATE, DELETE ON SYS.AUD$ BY ACCESS;



322

AUDITORÍA.RECOMENDACIONES.

• Es necesario seguir una serie de reglas a la hora de auditar la actividad de la base de datos:

- Limitar el numero de acciones auditadas y el tiempo durante el que se hará. Así disminuye el impacto de la auditoría sobre las sentencias supervisadas y se limita el tamaño del “audit trail” (¿qué debo o quiero auditar?).

- Evaluar el propósito y planear una estrategia (¿para qué y por qué audito?, ¿qué actividad maliciosa he detectado?).

- Si se audita debido a la sospecha de alguna acción maliciosa; debe comenzarse por auditar acciones de tipo general para, una vez analizada la información, pasar a auditar acciones mas concretas.

AUDITORIA



323

AUDITORÍA.RECOMENDACIONES.

- Proteger el “audit trail”, de forma que la infomacion de auditoría no pueda ser añadida, modificada o borrada sin ser registrada la operación.

- Controlar de forma estricta quien tiene derecho a auditar.

- En caso de que se desee recoger información histórica sobre determinadas operaciones debe auditarse sólo aquellas acciones que sean pertinentes; y preocuparse de guardar los registros de auditoría de interés y eliminar periódicamente del “audit trail” esta informacion.



324

AUDITORÍA. VISTAS.

• AUDIT_ACTIONS. Descripciones para los códigos de tipos de acción.

• ALL_DEF_AUDIT_OPTS. Opciones por defecto de auditoría de objetos que serán aplicadas al crearlos.

• DBA_AUDIT_EXISTS. Registros producidos por AUDIT NOT EXISTS.

• DBA_AUDIT_OBJECT. Registros para todos los objetos en el sistema.

• DBA_AUDIT_SESSION. Registros relativos a conexiones y desconexiones.

• DBA_AUDIT_STATEMENT. Registros para las sentencias GRANT, REVOKE, AUDIT, NOAUDIT, y ALTER SYSTEM.

• DBA_AUDIT_TRAIL. Registros de “audit trail”.

AUDITORIA



325

AUDITORÍA. VISTAS.

• DBA_OBJ_AUDIT_OPTS. Opciones de auditoría para todos los objetos.

• DBA_COMMON_AUDIT_TRAIL. Incluye registros de auditoría básica y de grano fino, así como el contenido de V$XML_AUDIT_TRAIL

• DBA_FGA_AUDIT_TRAIL. Registros de auditoría grano fino.

• DBA_AUDIT_POLICIES. Políticas de auditoría de grano fino en el sistema.

• DBA_PRIV_AUDIT_OPTS. Privilegios de sistema auditados.

• DBA_STMT_AUDIT_OPTS. Opciones de auditoría por sentencia.

• FLASBACK_TRANSACTION_QUERY. Información sobre transacciones y operaciones realizadas.



326

AUDITORÍA. VISTAS.

• STMT_AUDIT_OPTION_MAP. Información códigos de auditoría.

AUDITORIA



327

TEMA 10.

COPIAS DE SEGURIDAD.

COPIAS DE SEGURIDAD Administración y Ajuste de Oracle 10g


328

TEMA 10.COPIAS DE SEGURIDAD.

• MODOS DE OPERACION DE LA BD.

• COPIAS DE SEGURIDAD.

• COPIA FISICA.

• OPTIMAL FLEXIBLE ARCHITECTURE. O.F.A. Y UNIX.

• COPIA FISICA. SISTEMAS DE FICHEROS.

• COPIA FISICA. TAR (UNIX) Y RECOVERY MANAGER.

• RECUPERACION DE TABLAS. “FLASHBACK TABLE”.

COPIAS DE SEGURIDAD



329


• RECUPERACION DE TABLAS. “RECYCLE BIN”.

• RECUPERACION DE TABLAS. “PURGE”. “FLASHBACK TO BEFORE DROP”.

• COPIA LOGICA. DATA PUMP EXPORT/IMPORT.

• ARQUITECTURA DATA PUMP.

• DATA PUMP. VENTAJAS. EJECUCION. INFORMACION. FICHEROS.

• DATA PUMP EXPORT. PARAMETROS.



330


• DATA PUMP EXPORT. PARAMETROS. MODO INTERACTIVO.

• DATA PUMP IMPORT. PARAMETROS.

• DATA PUMP IMPORT. PARAMETROS. MODO INTERACTIVO.

• DATA PUMP Y PARAMETROS.

• COPIA LOGICA. UTILIDADES EXPORT/IMPORT.

• EXPORT/IMPORT vs. DATA PUMP

• UTILIDAD EXPORT. EXPORT MODO DIRECTO. CASOS PRACTICOS.

COPIAS DE SEGURIDAD



331


• UTILIDAD IMPORT. CASOS PRACTICOS.

• RENOMBRAR ESP. DE ALMACENAMIENTO.

• SQL*LOADER. CARGA DE DATOS. FICHEROS DATOS Y CONTROL.

• SQL*LOADER. EJEMPLOS. EJECUCION.

• VISTAS.

• APENDICE A. RECURSOS ORACLE.



332

MODOS DE OPERACION DE LA BD.

• Existen dos modos de operación de la bd:

• Modo NOARCHIVELOG.

– El archivado de los “redo log” está deshabilitado. Cuando un grupo de “redo” pasa a estar inactivo tras un “log switch”, está disponible para ser nuevamente usado por el LGWR.

– Este modo protege a la bd de fallos en la instancia pero no de fallos en los soportes (“media failure”). Sólo los cambios recientes en la bd, almacenados en el “redo” en línea pueden recuperarse; si ocurre un fallo en disco, la bd sólo puede recuperarse hasta el momento en que se realizó la copia más reciente.

– Para la recuperación sólo pueden emplearse copias completas y coherentes realizadas con la bd cerrada consistentemente.

COPIAS DE SEGURIDAD



333

MODOS DE OPERACION DE LA BD.

• Modo ARCHIVELOG.

– El archivado de los “redo log” está habilitado. Un grupo de “redo” no puede reutilizarse por LGWR hasta ser archivado tras el “log switch”.

– Se garantiza que todas las transacciones validadas pueden recuperarse en caso de fallo en el sistema o disco. Además pueden emplearse copias realizadas con la bd abierta y en uso normal.

Nota: durante este tema se asume que la base de datos está en modo noarchivelog.



334


• Pueden distinguirsen dos tipos de copias:

– Copias de seguridad físicas. Se realiza la copia de los ficheros que constituyen la base de datos. Se distinguen copias de seguridad en línea (“en caliente”) y fuera de línea (“en frio”).

Se pueden hacer manualmente (comando “tar” de s.o.) o mediante la utilidad RMAN (“recovery manager”) de Oracle.

– Copias de seguridad lógicas. Implican la lectura de un conjunto de registros de base de datos y su escritura en un fichero especial.

Se emplean utilidades propias de la base de datos: export/import y data pump export/import.

COPIAS DE SEGURIDAD



335


• Las copias de seguridad lógicas se emplean para:

– Transferir objetos de datos entre bases de datos Oracle (independientemente de la plataformas en que residan).

– Proporcionar copia de seguridad lógica para objetos de la base de datos, un espacio de almacenamiento o la base de datos al completo.

– Migración entre versiones de base de datos (¡Peligro!).

• Una buena estrategia de copias de seguridad incluirá ambos tipos de copias, físicas y lógicas, pues son complementarias.



336

COPIA FISICA

COPIAS DE SEGURIDAD



337

COPIA FISICA.

• Realizar una copia física implica copiar los sistemas de ficheros asociados a la base de datos y aquellos donde se ha instalado la misma.

– La copia de los ficheros de base de datos se realiza de forma diaria.

– La copia del “software” de base de datos se realiza con frecuencia semanal, dado su menor nivel de actualización.

• Dado que se asume que la base de datos está en modo noarchivelog, sólo es posible realizar copias “en frio” de la misma. Por tanto, previamente a la copia física se efectuará una parada de la base de datos, de forma que su contenido sea íntegro y coherente.



338

OPTIMAL FLEXIBLE ARCHITECTURE (O.F.A.).

• Oracle recomienda usar la “Optimal Flexible Architecture” (O.F.A.) en las instalaciones de base de datos.

• O.F.A. tiene los siguientes beneficios:

– Organiza grandes cantidades de “software” y datos en disco evitando cuellos de botella y bajas productividades.

– Facilita las tareas administrativas rutinarias.

– Gestiona de forma adecuada el crecimiento y administración de la base de datos.

COPIAS DE SEGURIDAD



339

O.F.A. EN ENTORNOS UNIX.

Ficheros de servidor y librerías bd requeridas./rdbms

Enlaces a donde residen los ficheros de inicialización./dbs

Ficheros NET. Comunicaciones./network

Binarios./bin

Por defecto/u01/app/oracle/product/<v_bd>

$ORACLE_HOME

Por defecto /u01/app/oracle$ORACLE_BASE



340


Fich.de traza procesos “background”.

bdump

arch

adhoc

Fich. archivados de “redo log”.

“Scripts” SQL Ad hoc.

Nombre base datos./<nombre_BD>

admin


COPIAS DE SEGURIDAD



341


init.orapfile

Fich. Export bd.exp

udump

create

cdump

Fich. traza usuario.

Progr. creación bd.

Ficheros “core dump”.

Nombre base datos./<nombre_BD>

admin




342

COPIA FISICA.SISTEMAS DE FICHEROS.

• Los sistemas de ficheros a copiar diariamente son:

- Sistemas de ficheros de administración de la bd, bajo $ORACLE_BASE/admin. Incluirá la copia del fichero de parámetros de inicialización “init.ora” y del fichero de parámetros “spfile” en su caso.

- Sistemas de ficheros asociados a la base de datos. Aquellos de la forma /uxx/oradata/<nombre_bd>; contendrán los ficheros de datos (.dbf), de control (.ctl) y de “redo log” (.log) de la base de datos.

- Sistemas de ficheros asociados a la exportación de base de datos (en caso de que se haya optado por realizarla). En nuestra bd de la forma /export/<nombre_bd>.

- Sistema de ficheros /etc.

COPIAS DE SEGURIDAD



343

COPIA FISICA.SISTEMAS DE FICHEROS.

• Los sistemas de ficheros a copiar semanalmente son:

- Sistemas de ficheros que integran la estructura O.F.A. Bajo $ORACLE_BASE (/u01/app/oracle).

- Todos los sistemas de ficheros que integran la copia diaria de la base de datos.



344

COPIA FISICA. COMANDO TAR (UNIX).

• La copia se realizará tras:

– Haber hecho la exportación correspondiente de la base de datos.

– Haber cerrado cualquier comunicación con la base de datos (proceso “listener”).

– Cerrar la base de datos (shutdown).

• Se usará la sentencia TAR de sistema operativo: Copia los sistemas de ficheros indicados a un dispositivo físico.

• El proceso debe ser automatizado y el cese de actividad de la base de datos afectar lo menos posible al servicio.

COPIAS DE SEGURIDAD



345

COPIA FISICA. RECOVERY MANAGER.

• Es una utilidad que permite realizar copias y recuperaciones en la bd y automatiza la administración de las mismas. El entorno para RMAN incluye:

– Bd a copiar.

– Cliente RMAN. Permite ejecutar sentencias RMAN.

– “Flash recovery area” (opcional). Localización en disco en que la bd puede almacenar y gestionar ficheros de copia y recuperación.

– “Media management software” (opcional). SW necesario para que RMAN interactúe con dispositivos de copia como unidades de cinta y otros.

– BD “recovery catalog” (opcional). Esquema de bd empleado para registrar la actividad de RMAN en una o más bbdd destino.



346

FLASHBACK

COPIAS DE SEGURIDAD



347

RECUPERACION DE TABLAS.“FLASHBACK TABLE”.

• Es posible restaurar una tabla a un estado anterior a aquel donde tuvieron lugar cambios, usando el espacio de “undo”, mediante la sentencia FLASHBACK TABLE. Se proporciona así una forma rápida de recuperar una tabla modificada o borrada, y se evita recurrir a métodos complejos.

• Características:

– La operación se realiza en línea.– Se mantienen automáticamente todos los atributos de la

tabla (índices, disparadores, “constraints”) necesarios.– Se mantienen las restricciones de integridad.– No se pierden los datos originales, pudiendo volver al

principio (no puede hacerse un “rollback” de la sentencia, pero puede realizarse una nueva recuperación a un momento justo anterior al actual -es conveniente anotar previamente el SCN actual-).



348


– Durante la recuperación se adquiere un bloqueo DML queimpide cualquier operación sobre la tabla. Esta se realiza en una transacción única, independientemente del número de tablas que comprenda la recuperación.

• Requisitos:

– Debe poseerse el privilegio FLASHBACK ANY TABLE o tenerel privilegio FLASHBACK sobre la tabla.

– Deben poseerse los privilegios SELECT, INSERT, DELETE, yALTER en la tabla.

– La información de “undo” debe ser suficiente como para recuperar hasta el punto indicado en la operación.

– Debe habilitarse en la tabla la característica “row movement” mediante la sentencia:

ALTER TABLE <nombre_tabla> ENABLE ROW MOVEMENT;

COPIAS DE SEGURIDAD



349


• Restricciones:

– Esta operación no puede realizarse en tablas que forman parte de un “cluster”, vistas materializadas, tablas Advanced Queuing (AQ), tablas estáticas de diccionario, tablas de sistema, tablas remotas, “object” tablas, tablas anidadas o particiones individuales de tablas.

– Las operaciones DDL que cambian la estructura de una tabla no permiten usar esta utilidad (actualización, “moving” o truncado de la tablas, adición de “constraint”, adición de una tabla a un “cluster”, modificación o borrado de una columna, adición, borrado, coalescencia, división, modificación o truncado de una partición -salvo la adición de una partición “range”-).



350

RECUPERACION DE TABLAS.“FLASHBACK DROP”.

• Al borrar una tabla, la bd no borra inmediatamente el espacio ocupado por la misma. La bd renombra la tabla y la coloca junto con sus objetos asociados (“constraints”, tablas anidadas y semejantes) en lo que denomina “recycle bin”, de forma que si fue borrada por error es posible recuperarla usando la sentencia FLASHBACK TABLE (“flashback drop”).

• El “recycle bin” es una tabla de diccionario con información sobre los objetos borrados y sus asociados, los cuales no se eliminan hasta indicarlo explicitamente o hasta haber necesidades de espacio (se eliminan en orden “first-in first-out” -FIFO-). Cada usuario, a menos que tenga privilegio SYSDBA, sólo puede acceder a sus propios objetos en esta tabla:

SELECT * FROM RECYCLEBIN;

• El espacio libre en un espacio de almacenamiento puede consultarse en la vista DBA_FREE_SPACE.

COPIAS DE SEGURIDAD



351

RECUPERACION DE TABLAS.“RECYCLE BIN”.

• Al borrar un espacio de almacenamiento incluyendo su contenido, los objetos en el mismo no se almacenan en el “recycle bin” y la bd elimina cualquier referencia en el mismo. Igualmente sucede cuando se borra un usuario, “cluster” o “type”.

• Este modo de funcionamiento, habilitado por defecto, puede habilitarse o deshabilitarse mediante el parámetro de inicialización RECYCLEBIN, o, dinámicamente mediante las sentencias:

ALTER SESSION/SYSTEM SET recyclebin = OFF;

ALTER SESSION/SYSTEM SET recyclebin = ON;

Deshabilitar “recycle bin” no afecta a los objetos que ya se hallan en el mismo.



352


• También se obvia en ciertas ocasiones el “recycle bin”:

– En la sentencia DROP TABLE ... PURGE (ej. SQL> drop table emp purge;).

– En la sentencia DROP TABLESPACE ... INCLUDING CONTENTS. Cada espacio de almacenamiento tiene su propio “recycle bin” por lo que borrar el espacio implica eliminar este y cualquier objeto en el mismo.

– AL emplear DROP USER...CASCADE. Se elimina el usuario y todos sus objetos (incluidos aquellos en el “recycle bin”.

COPIAS DE SEGURIDAD



353


• A los objetos almacenados en el “recycle bin” se les asigna un nombre generado por el sistema de la forma BIN$unique_id$version , donde :

– unique_id es un identificador único para el objeto compuesto por 26 caracteres, y

– version es un número de version asignado a la bd.

• Es posible obtener información mediante las vistas:

– USER_RECYCLEBIN. Permite a un usuario ver los objetos de su propiedad que han sido borrados, tiene un sinónimo: RECYCLEBIN.

– DBA_RECYCLEBIN. Da información a los administradores sobre todos los objetos borrados.

O mediante la sentencia SQL*Plus SHOW RECYCLEBIN.



354

RECUPERACION DE TABLAS.“PURGE”. “FLASHBACK TO BEFORE DROP”.

• Mediante la sentencia PURGE puede borrarse explicitamente elcontenido del “recycle bin” y liberar el espacio asociado (son necesarios los mismos privilegios requeridos para borrar el elemento):

PURGE TABLE/INDEX <nombre>;

PURGE TABLESPACE <nombre_tbsp> USER <nombre_usuario>;

Nota: Se eliminan todos los objetos de “nombre_usuario” para elesp.almacenamiento “nombre_tbsp”.

PURGE RECYCLEBIN/DBA_RECYCLEBIN;

• La sentencia FLASHBACK TABLE ... TO BEFORE DROP permite recuperar objetos del “recycle bin”:

FLASHBACK TABLE <nombre_tabla> TO BEFORE DROPRENAME TO <nombre_tabla>;

COPIAS DE SEGURIDAD



355

COPIA LOGICA: DATAPUMP



356

COPIA LÓGICA.DATA PUMP EXPORT/IMPORT.

• Son utilidades integradas en la bd que permiten cargas y descargas de información a gran velocidad. Todo el proceso de exportación/importación se lleva a cabo en el servidor.

• No son compatibles con el export/import originales.

• Consta de los siguientes componentes:

– Clientes expdp e impdp. Usan los procedimientos proporcionados por el paquete DBMS_DATAPUMP.

– Paquete DBMS_DATAPUMP. Conocido como Data Pump API, permite crear y monitorizar los trabajos implicados.

– Paquete DBMS_METADATA. Conocido como Metadata API, proporciona la definición de los objetos de la bd a Data Pump.

COPIAS DE SEGURIDAD



357

ARQUITECTURA DATA PUMP.



358

DATA PUMP. VENTAJAS.

• Algunas de las ventajas de Data Pump son:

– La forma de acceso a los datos se decide automáticamente (habitualmente “direct path”, “external” cuando no es posible).

– La exportación puede realizarse en paralelo y puede escribirse a múltiples ficheros en diferentes discos (opciones PARALLEL y DUMPFILE).

– Puede reiniciarse un trabajo fallido donde se interrumpió.

– Permite filtrar metadatos con múltiples combinaciones (opciones INCLUDE y EXCLUDE).

– Pueden filtrarse filas de datos durante la importación.

– Permite estimar el espacio en disco necesario antes de realizar el trabajo (opción ESTIMATE_ONLY).

– Pueden hacerse exportaciones e importaciones remotas usando “database link”.

COPIAS DE SEGURIDAD



359

DATA PUMP. VENTAJAS.

– Los trabajos pueden asignar recursos dinámicamente según la carga de trabajo.

– Puede indicarse explícitamente la versión de bd, de forma que sólo los objetos soportados se exportan.

– Durante la importación, puede cambiarse los nombres de fichero, esquemas y espacios de almacenamiento destino.



360

DATA PUMP. EJECUCIÓN.

• En cada exportación o importación se crea un proceso maestro quecontrola la misma, incluyendo la comunicación con los clientes, la creación y control del conjunto de procesos de trabajo necesarios y la realización de las operaciones de conexión.

• En la transferencia de datos y metadatos, se emplea un tabla maestro, que se crea en el esquema del usuario que realiza la exportación/importación y tiene el nombre del trabajo -job- que realiza la operación, para realizar el seguimiento del proceso:

– Durante la exportación la tabla registra la localización de los objetos en el conjunto de ficheros de descarga (“dump file set”). Al finalizar, el contenido de la tabla se escribe a fichero.

– Durante la importación la tabla maestro se carga desde el conjunto de ficheros de descarga y se emplea para controlar la secuencia de localización de los ficheros a importar.

COPIAS DE SEGURIDAD



361


• Esta tabla maestro también se emplea para reiniciar un trabajo.

• El destino final de la tabla maestro es diverso:

– Si el trabajo finaliza correctamente, la tabla se borra.

– Si el trabajo se para, usando la sentencia STOP_JOB, se retiene para poder reiniciarlo.

– Si el trabajo se elimina, usando la sentencia KILL_JOB, la tabla se elimina y el trabajo no puede reiniciar.

– Si un trabajo termina inesperadamente, se mantiene la tabla. Puede borrarse si no hay intención de reiniciar el trabajo.

• El progreso de un trabajo y los errores producidos pueden registrarse en un fichero de “log”. El estado del mismo, en tiempo real, puede obtenerse usando la sentencia STATUS en modo interactivo de Data Pump.



362

DATA PUMP. INFORMACIÓN.

• Puede obtenerse información en las siguientes vistas:

– DBA_DATAPUMP_JOBS y USER_DATAPUMP_JOBS. Identifican trabajos Data Pump activos.

– DBA_DATAPUMP_SESSIONS. Identifica sesiones de usuario asociadas a un trabajo.

– V$SESSION_LONGOPS. Información sobre el progreso del trabajo.

COPIAS DE SEGURIDAD



363

DATA PUMP. FICHEROS.

• Existen tres tipos de ficheros gestionados por Data Pump:

– Ficheros de volcado (“dump”). Contienen datos y metadatos.Durante una exportación pueden indicarse al definir el trabajo así

como posteriormente (por ejemplo, pueden añadirse ficheros de volcado con ADD_FILE).

Durante un importación, todos los ficheros de volcado deben especificarse al definir el trabajo.

– Ficheros “log”. Contienen mensajes sobre la operación realizada.

– Ficheros SQL. Registran la salida de una operación SQLFILE (parámetro SQLFILE) consistente en el volcado de todas las sentencias DDL que se hubieran ejecutado durante una importación a un fichero.

Nota: Los ficheros de “log” y SQL pueden sobreescribirse si ya existen. Nunca se sobreescriben ficheros de volcado si ya existen, se genera un error.



364

DATA PUMP.LOCALIZACION DE FICHEROS.

• Es necesario crear objetos tipo directorio (asocia un nombre a un directorio o sistema de ficheros) por un usuario administrador o con el privilegio CREATE ANY DIRECTORY. Al exportar/importar se indica mediante el parámetro DIRECTORY.

SQL> CREATE DIRECTORY DPUMP_VOLCADO AS '/datapump/ficheros';

Por defecto se asigna el valor para DATA_PUMP_DIR:

SQL> CREATE DIRECTORY DATA_PUMP_DIR AS '/datapump/ficheros';

• Tras la creación de un directorio, su creador debe conceder el permiso de lectura (READ) o escritura (WRITE) a otros usuarios.

SQL> GRANT READ, WRITE ON DIRECTORY <directorio> TO <usuario>;

Nota: Implica tener acceso a través de bd pero no el poder acceder a través de s.o.

COPIAS DE SEGURIDAD



365


• El orden de precedencia usado para determinar la localización es:

1.- Objeto directorio formando parte de la especificación de un nombre de fichero (DUMPFILE=<localización>:<fichero>.dmp).

2.- Objeto directorio indicado en el parámetro DIRECTORY.

3.- Valor de la variable de entorno DATA_PUMP_DIR (definida enel entorno del cliente):

SQL> CREATE DIRECTORY DUMP_FICHERO AS '/DATAPUMP/FICHEROS';

# EXPORT DATA_PUMP_DIR=<VARIABLE_FICHERO_VOLCADO>

4.- Si es un usuario privilegiado se emplea el valor por defecto en bd del directorio DATA_PUMP_DIR (que debe estar previamentecreado). No confundir con la variable de entorno.



366

DATA PUMP EXPORT.

• Se emplea la utilidad expdp, indicando las características de la exportación en la línea de comandos o mediante un fichero de parámetros. Los ficheros resultantes de una exportación sólo pueden importarse con D.P. Import.

Cualquier usuario puede exportar objetos de su propiedad o su esquema al completo.

Los usuarios no privilegiados deben tener permiso WRITE en el objeto directorio y deben indicar éste en el parámetro DIRECTORYo junto al nombre de fichero de volcado.

Modo ayuda en línea: expdp HELP=y

Modo interactivo: expdp directory=<localización>

Modo fichero de parámetros: expdp PARFILE=<fichero_parametros>

Nota: Si no se indica ningún otro parámetro se usan los valores por defecto en la exportación: expdat.dmp y export.log -ficheros-, exportación a nivel de esquema, SYS_EXPORT_SCHEMA_01 -trabajo- y se exportan datos y metadatos.

COPIAS DE SEGURIDAD



367

DATA PUMP EXPORT.

• Existen cinco modos de trabajar con “datapump export”:

- “Full export” (parámetro FULL). Se exporta toda la bd. Es necesario el rol EXP_FULL_DATABASE.

- “Esquema de usuario” (parámetro SCHEMAS). Si no se posee rolEXP_FULL_DATABASE sólo es posible exportar el esquema propio.

- “Tabla” (parámetro TABLES). Para exportar tablas no pertenecientes al propio esquema es necesario el rol EXP_FULL_DATABASE.

- “Tablespace” (parámetro TABLESPACES). Debe tenerse el rol EXP_FULL_DATABASE.

- “Transport Tablespace” (parámetro TRANSPORT_TABLESPACES). Permite exportar metadatos para tablas y objetos dependientes pertenecientes a un conjunto de espacios de almacenamiento. Es necesario el rol EXP_FULL_DATABASE.



368

DATA PUMP EXPORT.PARÁMETROS.

• CONTENT =<ALL | DATA_ONLY | METADATA_ONLY>

Indica contenido a exportar: datos, metadatos o ambos.

• DIRECTORY =<DATA_PUMP_DIR>

Localización para los ficheros de volcado y registro.

• DUMPFILE = <directorio_objeto:>nombre_fichero

Fichero de volcado. Por defecto expdat.dmp

• ESTIMATE = <BLOCKS | STATISTICS>

Método de estimación de espacio en disco necesario para cada tabla.

• ESTIMATE_ONLY =<N | Y>

Permite estimar el espacio consumido en una exportación sin realizarla.

COPIAS DE SEGURIDAD



369


• EXCLUDE = tipo_objeto <:cláusula>

Filtrar metadatos exportados indicando objetos y tipos excluidos. Por defecto ninguno. Es excluyente con el parámetro INCLUDE.

• FILESIZE

Tamaño máximo para ficheros de exportación (por defecto ilimitado).

• FULL = <N | Y>

Realizar una exportación de la bd al completo. En una exportacion completa no se incluyen los esquemas SYS, ORDSYS, EXFSYS, MDSYS, DMSYS, CTXSYS, ORDPLUGINS, LBACSYS, XDB, SI_INFORMTN_SCHEMA, DIP, DBSNMP, y WMSYS. Nunca se exportan tampoco los permisos sobre objetos de SYS.



370


• INCLUDE = tipo_objeto <:cláusula>

Filtrar metadatos exportados indicando objetos y tipos incluidos (consultar las vistas DATABASE_EXPORT_OBJECTS, SCHEMA_EXPORT_OBJECTS y TABLE_EXPORT_OBJECTS).

• JOB_NAME

Especificar un nombre para el trabajo, “job”, de exportación; coincide tambien con la tabla maestro usada para controlar la exportación. Por defecto de las forma sys_export_<modo>_xx

• LOGFILE = <directorio_objeto:>nombre_fichero

Fichero de registro, por defecto export.log

• NOLOGFILE = <Y | N>

No crear fichero de registro.

COPIAS DE SEGURIDAD



371


• PARALELL = n

Grado de paralelismo en la ejecución (por defecto 1). Su número debe ser igual al número de ficheros de volcado indicados.

• QUERY =<nombre_esquema.><nombre_tabla> | <cláusula>

Permite seleccionar filas a exportar según condiciones a cumplir. No compatible con CONTENT=METADATA_ONLY, ESTIMATE_ONLY o TRANSPORT_TABLESPACES.

• SCHEMAS =<lista de esquemas>

Permite indicar que se realizará una exportación de esquemas, es el modo por defecto. Por defecto referencia el esquema de usuario.

• STATUS = nn

Frecuencia con que muestra el estado del trabajo junto a una descripción de la operación actual (por defecto es cero y no muestra información hasta acabar la exportación de cada objeto).



372


• TABLES = <nombre_esquema.><nombre_tabla>, ...

Indica exportación en modo tabla (del propio esquema, por defecto).

• TABLESPACES = <nombre_espacioalmac>, ...

Indica tbsp. a exportar en modo “tablespace”.

• TRANSPORT_FULL_CHECK =<N | Y>

Chequear o no las dependencias entre los objetos residentes los espacios de almacenamiento a “transportar” y aquellos situados fuera del conjunto (sólo en modo “transport tablespace”).

• TRANSPORT_TABLESPACES = <nombre_espacioalmac>, ...

Realizar una exportación en modo “transport tablespace” y espacios de almacenamiento a los que se aplica. Este modo tiene un grado de paralelismo igual a 1 y requiere disponer del rol EXP_FULL_DATABASE, sus trabajos no se pueden reiniciar.

COPIAS DE SEGURIDAD



373

DATA PUMP EXPORT.MODO INTERACTIVO.

• Tras iniciar un trabajo, puesto que se ejecuta en el servidor, esposible interrumpir la sesión cliente y asociarse al trabajo posteriormente. También es posible modificar ciertos parámetros de forma interactiva.Para pasar a modo interactivo puede interrumpirse la conexiónactual con Ctrl+C y asociar posteriormente una sesión cliente (ATTACH):

/home/...> expdp attach=<nombre_trabajo>

Los parámetros que pueden usarse en modo interactivo son:

– ADD_FILE = <directorio:><nombre_fichero>, ...

Permite añadir ficheros de volcado.



374

DATA PUMP EXPORT.MODO INTERACTIVO.

– CONTINUE_CLIENT. Salir de modo interactivo y entrar en modo registro.

– EXIT_CLIENT. Salir de sesión cliente. El trabajo continúa ejecutándose en el servidor.

– HELP. Ayuda en línea.

– KILL_JOB. Cancelar trabajo actual y desasociar las sesiones cliente relacionadas.

– PARALLEL. Indicar grado paralelismo o número de trabajos.

– START_JOB. Reiniciar el trabajo asociado.

– STATUS. Mostrar informe del estado del trabajo asociado.

– STOP_JOB [INMEDIATE]. Detener el trabajo asociado, puede reiniciarse más tarde. Con “inmediate” los procesos acaban al instante, las tareas incompletas se volverán a realizar al reiniciarlo.

COPIAS DE SEGURIDAD



375

DATA PUMP IMPORT.

• Se emplea la utilidad impdp, indicando las características de laimportación en la línea de comandos o mediante un fichero de parámetros. Sólo pueden usarse en la importación ficheros creadoscon D.P. Export.

Los usuarios deben tener permiso READ en el objeto directorio dond resida el fichero de volcado y de escritura donde se cree el fichero de registro (log) y los SQL.

Modo ayuda en línea: impdp HELP=y

Modo interactivo: impdp directory=<localización>

Modo fichero de parámetros: impdp PARFILE=<fichero_parametros>

Nota: Si no se indica ningún otro parámetro se usan los valores por defecto en laexportación: expdat.dmp e import.log -ficheros-, importación total del fichero y trabajo SYS_IMPORT_xx_01.



376

DATA PUMP IMPORT.

• Existen cinco modos de trabajar con “datapump import”:

- “Full import” (parámetro FULL). Se importa el fichero de volcado al completo (modo por defecto). Necesario el rol IMP_FULL_DATABASEsi se hizo la exportación con EXP_FULL_DATABASE.

- “Esquema de usuario” (parámetro SCHEMAS). Sólo se cargan objetos propiedad del usuario actual. Si se posee rolIMP_FULL_DATABASE pueden cargarse esquemas diferentes al propio.

- “Tabla” (parámetro TABLES). Para importar tablas no pertenecientesal propio esquema es necesario el rol IMP_FULL_DATABASE.

- “Tablespace” (parámetro TABLESPACES).

- “Transport Tablespace” (parámetro TRANSPORT_TABLESPACES). Permite importar metadatos para un conjunto de espacios de almacenamiento. Es necesario el rol IMP_FULL_DATABASE.

COPIAS DE SEGURIDAD



377

DATA PUMP IMPORT.PARÁMETROS.

• CONTENT =<ALL | DATA_ONLY | METADATA_ONLY>

Indica contenido a importar: datos -filas, no se crean objetos-, metadatos -definiciones- o ambos.

• DIRECTORY =<DATA_PUMP_DIR>

Por defecto DATA_PUMP_DIR para usuarios privilegiados, ninguno para el resto. Localización para los ficheros de volcado y registro.

• DUMPFILE = <directorio_objeto:>nombre_fichero

Fichero de volcado. Por defecto expdat.dmp

• ESTIMATE = <BLOCKS | STATISTICS>

Método de estimación de espacio en disco necesario para cada tabla (sólo válido si se indica también NETWORK_LINK).



378


• EXCLUDE = tipo_objeto <:cláusula>

Filtrar metadatos importados indicando objetos y tipos excluidos. Por defecto ninguno. Es excluyente con el parámetro INCLUDE. No puede usarse junto con CONTENT=DATA_ONLY.

• FULL = <N | Y>

Realizar una exportación de la bd al completo, todo el fichero fuente se importa. Si la operación de exportación que dio lugar al fichero se hizo usando el rol EXP_FULL_DATABASE, es necesario el rol IMP_FULL_DATABASE.

• INCLUDE = tipo_objeto <:cláusula>

Filtrar metadatos importados indicando objetos y tipos incluidos (consultar las vistas DATABASE_EXPORT_OBJECTS, SCHEMA_EXPORT_OBJECTS y TABLE_EXPORT_OBJECTS). No puede usarse junto con CONTENT=DATA_ONLY.

COPIAS DE SEGURIDAD



379


• JOB_NAME

Especificar un nombre para el trabajo, “job”, de importación; coincide tambien con la tabla maestro usada para controlar la importación. Por defecto de las forma sys_import_<modo>_xx

• LOGFILE = <directorio_objeto:>nombre_fichero

Fichero de registro, por defecto import.log.

• NOLOGFILE = <Y | N>

No crear fichero de registro.

• PARALELL = n

Grado de paralelismo en la ejecución (por defecto 1).



380


• QUERY =<nombre_esquema.><nombre_tabla:> <cláusula>

Permite seleccionar filas a importar según condiciones a cumplir. No compatible con CONTENT=METADATA_ONLY, SQLFILE oTRANSPORT_TABLESPACES.

• REMAP_DATAFILE=fichero_fuente : fichero_destino

Cambia el nombre de fichero_fuente por el de fichero_destino en las sentencias SQL donde se referencie la fuente (CREATE TABLESPACE, CREATE LIBRARY y CREATE DIRECTORY). Debe tenerse el rol IMP_FULL_DATABASE.

• REMAP_SCHEMA=esquema_fuente : esquema_destino

Carga objetos del esquema fuente al esquema destino. Debe tenerse el rol IMP_FULL_DATABASE. Si el esquema destino no existe, se crea si el fichero de volcado contiene la información necesaria (CREATEUSER) y se importa con suficientes privilegios (en caso contrario debe crearse previamente).

COPIAS DE SEGURIDAD



381


• REMAP_TABLESPACE=tbsp_fuente : tbsp_destino

Carga todos los objetos, incluso el usuario, del esquema fuente en el esquema destino.

• REUSE_DATAFILES=<Y | N>

Indica si la operación de importación debe reutilizar los ficheros de datos existentes o no en la creación de espacios de almacenamiento.

• SKIP_UNUSABLE_INDEXES=<Y | N>

Permite indicar que no se carguen tablas que tengan índices en estado no disponible.

• SQLFILE=<directorio_objeto:>nombre_fichero

Define un fichero en el que descargar todas las sentencias SQL tipo DDLque se hubieran ejecutado al importar (no son ejecutadas). Si se generan contraseñas en el fichero, aparecen comentadas.



382


• SCHEMAS =<lista de esquemas>

Permite indicar que se realizará una importación de esquemas. Por defecto referencia el esquema de usuario, para otros es necesario el rol IMP_FULL_DATABASE.

• STATUS = nn

Frecuencia con que muestra el estado del trabajo junto a una descripción de la operación actual y el porcentaje que falta para acabar el trabajo (por defecto es cero).

• TABLE_EXISTS_ACTION = <SKIP | APPEND |TRUNCATE |REPLACE>

Indica qué hacer si la tabla a importar ya existe. Si se indica CONTENT=DATA_ONLY la opción por defecto es APPEND):

• SKIP. Deja la tabla tal como está e importa siguiente objeto.• APPEND. Carga filas, el contenido anterior no se modifica.• TRUNCATE. Borra las filas existentes antes de cargar.• REPLACE. Borra la tabla y la carga al completo.

COPIAS DE SEGURIDAD



383


• TABLES = <nombre_esquema.><nombre_tabla><:partición>, ...

Indica exportación en modo tabla (por defecto del propio esquema; para tablas de otro esquema debe tenerse el rol IMP_FULL_DATABASE).

• TABLESPACES = <nombre_espacioalmac>, ...

Indica tbsp. a exportar en modo “tablespace”.

• TRANSFORM=<SEGMENT_ATTRIBUTES|STORAGE>:<N|Y><:TABLE|:INDEX>

Permite modificar parámetros en la sentencia de creación DDL a importar:

– SEGMENT_ATTRIBUTES. Atributos físicos, “storage”, “tablespaces”, “logging”.

– STORAGE. Cláusula “storage”.

Por defecto se aplica a todos los tipos de objetos.



384


• TRANSPORT_DATAFILES

Conjunto de ficheros a importar en el destino en modo “transport tablespace”.

• TRANSPORT_TABLESPACES = <nombre_espacioalmac>, ...

Realizar una importación en modo “transport tablespace” y espacios de almacenamiento a los que se aplica.

COPIAS DE SEGURIDAD



385

DATA PUMP IMPORT.MODO INTERACTIVO.

• Al igual que con “data pump export”, tras iniciar un trabajo, yaque es ejecutado en el servidor, es posible interrumpir la sesión cliente y asociarse al trabajo posteriormente. También es posible modificar ciertos parámetros de forma interactiva.Para pasar a modo interactivo puede interrumpirse la conexiónactual con Ctrl+C y asociar posteriormente una sesión cliente (ATTACH):

/home/...> impdp attach=<nombre_trabajo>

Los parámetros que pueden usarse en modo interactivo son:

– CONTINUE_CLIENT. Salir de modo interactivo y entrar en modoregistro.

– EXIT_CLIENT. Salir de sesión cliente. El trabajo continúaejecutándose en el servidor.



386

DATA PUMP IMPORT.MODO INTERACTIVO.

– HELP. Ayuda en línea.

– KILL_JOB. Cancelar trabajo actual y desasociar las sesiones cliente relacionadas.

– PARALLEL. Indicar grado paralelismo o número de trabajos.

– START_JOB. Reiniciar el trabajo asociado.

– STATUS. Mostrar informe del estado del trabajo asociado.

– STOP_JOB [INMEDIATE]. Detener el trabajo asociado, puede reiniciarse más tarde. Con “inmediate” los procesos acaban al instante, las tareas incompletas se volverán a realizar al reiniciarlo.

COPIAS DE SEGURIDAD



387

DATA PUMP Y PARAMETROS.

• Ciertos parámetros de inicialización pueden afectar al rendimiento de “data pump”. Puede probarse a usar las siguientes asignaciones:

– DISK_ASYNCH_IO = TRUE– DB_BLOCK_CHECKING = FALSE– DB_BLOCK_CHECKSUM = FALSE

• Además los parámetros siguientes deben tener valores lo suficientemente altos como para permitir el máximo grado de paralelismo:

– PROCESSES– SESSIONS– PARALLEL_MAX_SERVERS–



388

COPIA LOGICA: EXPORT/IMPORT

COPIAS DE SEGURIDAD



389

COPIA LÓGICA.UTILIDADES EXPORT/IMPORT.

• Generalmente se recomienda emplear Data Pumpexport/import y no usar las utilidades originales export/import; sin embargo estas son necesarias en los siguientes casos:

– Al importar ficheros creados con la utilidad “export”. Porejemplo, aquellos procedentes de bases de datos con versiones anteriores a la 10g.

– Si se desea exportar ficheros que serán importados con la utilidad “import”. Por ejempo, si se van a transferir datos a bases con una versión anterior a la 10g.



390

EXPORT/IMPORT vs. DATA PUMP

• Data Pump trabaja con un grupo de ficheros de volcado (“dump file set”), no con uno único.

• D.P. basa su funcionamiento en el servidor no en el cliente.• D.P. emplea ejecución paralela.• D.P. almacena los metadatos como documentos XML no como

sentencias DDL.• D.P. se ajusta automáticamente (no son necesarios parámetros

empleados en export/import originales como BUFFER y RECORDLENGTH).

• Usando D.P. no es posible realizar “commit” intermedio durante una importación (sí con import original -parámetro COMMIT-).

• Con D.P. no es posible comprimir extensiones al recrear tablas (sí con import original -parámetro COMPRESS-).

• Al importar con D.P. en una tabla que ya existe, si una fila viola una restricción se interrumpe la operación y no se carga ningún dato. Con import original se registra el error y prosigue la carga.

COPIAS DE SEGURIDAD



391

UTILIDAD EXPORT.

• Para usar la utilidad debe tenerse el privilegio CREATE SESSION.

• Para exportar objetos pertenecientes a otro esquema de usuario debe tenerse asignado el rol EXP_FULL_DATABASE.

• Como resultado se obtiene un fichero .dmp (fichero de exportación) y, opcionalmente, un fichero .log con el informe de incidencias.

• Es conveniente que todos los ficheros generados para usar en la exportación o como resultado de ella estén en un sistema de ficheros independiente (p.ej. /export/<nombre_bd>).



392

UTILIDAD EXPORT.

• Existen cuatro modos de realizar “export”:

- “Tabla”. Cualquier usuario puede exportar tablas indicadas del esquema de usuario.

- “Usuario”. Cualquier usuario puede exportar todos los objetos del esquema.

- “Tablespace”. Permite mover “tablespaces” entre bases de datos. Sólo posible con el rol EXP_FULL_DATABASE.

- “Full database”. Exporta todos los objetos de la BD (no se exportan disparadores pertenecientes al esquema SYS). Sólo posible con el rol EXP_FULL_DATABASE.

COPIAS DE SEGURIDAD



393

UTILIDAD EXPORT.

• Aunque puede ejecutarse la utilidad e ir indicando en el “prompt” diferentes opciones, se recomienda usar un fichero de parámetros.

• Sintaxis:

exp HELP=Y Proporciona ayuda en línea.

exp Modo interactivo (sin modo directo).

exp PARFILE=<fichero_parametros>



394

UTILIDAD EXPORT.

Exportación de la base de datos completa o no.FULL (Y/N)

Nombre del fichero de “export”, por defecto “expdat.dmp”.FILE

Modo directo o no -convencional- de exportación.DIRECT (Y/N)

Exportar o no las restricciones sobre tablas.CONSTRAINTS (Y/N)

Asegura la consistencia de los datos exportados cuando pueden estar siendo actualizados (p.ej. con la bd abierta). Incompatible con copias incrementales.

CONSISTENT (Y/N)

Incluir todos los datos en una extensión (no para LOB).COMPRESS (Y/N)

Tamaño “bufer” de datos (bytes). No tiene efecto al usar “direct path”.BUFFER

DescripciónParámetro

COPIAS DE SEGURIDAD



395

UTILIDAD EXPORT.

Lista de “tablespaces” a exportar.TABLESPACES

Permite exportación de “tablespaces”.TRANSPORT_TABLESPACE(Y/N)

Relación de tablas a exportar (modo tabla).TABLES

Exportar o no los datos de las tablas.ROWS (Y/N)

Indica los usuarios de los que se realizara la copia.OWNER

Indica fichero donde se guardarán los mensajes.LOG

Exportar o no índices.INDEXES (Y/N)

Exportar o no privilegios sobre objetos.GRANTS (Y/N)




396

UTILIDAD EXPORT.

Usuario y contraseña del usuario que realiza la exportación (¡Peligro!).USERID

Exportar o no disparadores.TRIGGERS (Y/N)


COPIAS DE SEGURIDAD



397

EXPORT. MODO DIRECTO.

• Existen dos métodos para realizar la exportación:

– “Conventional path Export”. Utiliza la sentencia SQL SELECT para extraer datos de las tablas. Se leen los datos desde disco a una “buffer cache” y, después de ser evaluados, se transfieren al cliente “export”, que los escribe en el fichero de “export”.

– “Direct path Export”. Extrae los datos de disco a la “buffer cache” y las filas son transferidas directamente al cliente “export”, que las escribe en el fichero de salida. Los datos se hallan en el formato que “export” espera y no hay conversión.

La extracción de datos es mucho más rápida.Se debe especificar “DIRECT=Y” en el fichero de

parámetros.



398


• Mediante el parámetro RECORDLENGTH se especifica en el fichero de parámetros el tamaño del “buffer” que se usa para escribir en el fichero de “export”.

• Se recomienda que RECORDLENGTH sea múltiplo del tamaño de bloque E/S y múltiplo de DB_BLOCK_SIZE, de forma que cada lectura en tabla devuelva un bloque de datos. Si los datos leídos no caben en el “buffer”, se harán múltiples escrituras en el fichero de “export” para cada bloque.

• En modo interactivo no puede usarse el modo directo de exportación.

COPIAS DE SEGURIDAD



399




400

CASOS PRACTICOS.

• La utilidad “export” se aconseja en los siguientes casos:

- Realización de una copia de seguridad de la base de datos.

FILE=<nombre_bd>.dmpFULL=YLOG=<nombre_bd>.log

- Copias de seguridad de esquema de usuario (al borrarlo y necesitar guardar su esquema de forma temporal).

FILE=<nombre_esquema_bd>.dmpOWNER=<propietario del esquema>LOG=<nombre_esquema_bd>.logCOMPRESS=Y

COPIAS DE SEGURIDAD



401

CASOS PRACTICOS.

- Copias de seguridad de tablas antes de realizar operaciones delicadas como borrado masivo de datos, cargas de datos, actualizaciones, …

FILE=<nombre_tabla>.dmpTABLES=(<esquema>.<nombre_tabla>, …)LOG=<nombre_esquema_tabla>.logCOMPRESS=Y



402

UTILIDAD IMPORT.

• La utilidad “import” es complementaria de “export”.

• Los objetos se importan en el orden en que están en el fichero de exportación:

- Definición de tipos.- Definiciones de tablas.- Datos de tablas.- Índices.- Restricciones de integridad, vistas, procedimientos y

disparadores.- Índices bitmap, funcionales y de dominio.

• En tablas que ya existen es aconsejable deshabilitar las restricciones de integridad referenciales temporalmente.

COPIAS DE SEGURIDAD



403

UTILIDAD IMPORT.

• Para usar la utilidad debe tenerse el privilegio CREATE SESSION. Por supuesto, deben tenerse los privilegios necesarios para crear o trabajar con los objetos a importar.

• Un usuario puede importar un fichero de “export” no creado por él. Si el fichero de exportación fue creado con el privilegio EXP_FULL_DATABASE, debe tenerse asignado el rol IMP_FULL_DATABASE.

• Como resultado se obtiene un fichero .log con el informe de incidencias.



404

UTILIDAD IMPORT.

• Existen cuatro modos de realizar “import”:

- “Tabla”. Cualquier usuario puede importar tablas indicadasdel esquema de usuario.

- “Usuario”. Cualquier usuario puede importar todos losobjetos del esquema.

- “Tablespace”. Permite mover “tablespaces” entre bases de datos. Sólo usuarios privilegiados.

- “Full database”. Sólo posible con el privilegioIMP_FULL_DATABASE.

COPIAS DE SEGURIDAD



405

UTILIDAD IMPORT.

• Aunque puede ejecutarse la utilidad e ir indicando en el “prompt” diferentes opciones, se recomienda usar un fichero de parámetros.

• Sintaxis:

imp HELP=Y Proporciona ayuda en línea.

imp Modo interactivo.

imp PARFILE=<fichero_parametros>



406

UTILIDAD IMPORT.

Lista de esquemas a importar (usado normalmente con TOUSER).FROMUSER

Nombre del fichero de “export” a importar, por defecto “expdat.dmp”.FILE

Indica si los ficheros de datos existentes debe ser o no reutilizados.DESTROY (Y/N)

Importar o no las restricciones sobre tablas.CONSTRAINTS (Y/N)

Hacer “commit” o no después de cada inserción. Útil para evitar que los segmentos de “rollback” crezcan demasiado. Si ocurre un error y no hay clave única se producirán filas duplicadas.

COMMIT (Y/N)

Tamaño “bufer” de datos (bytes) usado en la transferencia.BUFFER


COPIAS DE SEGURIDAD



407

UTILIDAD IMPORT.

Fichero de descarga para sentencias de creación de índices, no son creados.INDEXFILE

Indica la forma de tratar los erroresgenerados en la creación de objetos. Si IGNORE=Y se ignoran los errores de creación y se continua, en caso contrario se muestran. En el caso de tablas, si IGNORE=Y se importan los datos en las tablas existentes. Si IGNORE=N se genera un error y no se inserta.

IGNORE (Y/N)

Importar o no el fichero completo.FULL (Y/N)

Importar o no índices.INDEXES (Y/N)

Importar o no privilegios sobre objetos.GRANTS (Y/N)




408

UTILIDAD IMPORT.

Si SHOW=Y, el contenido del fichero de “export” se lista pero no se importa. Solo puede usarse con los parámetros FULL=Y, FROMUSER, TOUSER, o TABLES.

SHOW (Y/N)

Lista de tablas a importar.TABLES

Incluir datos en la importación.ROWS (Y/N)

Lista de esquemas donde importar. Se requiere IMP_FULL_DATABASE.TO_USER

Indica fichero donde se guardaran los mensajes.LOG

Lista de espacios de almacenamiento a importar.TABLESPACES

Importar datos de espacios de almacenamiento.TRANSPORT_TABLESPACE


COPIAS DE SEGURIDAD



409

CASOS PRACTICOS.

• Se hará uso de la utilidad “import” en los casos:

- Recuperación de la base de datos a un punto en el tiempo.

FILE=<nombre_fichero_export>.dmpFULL=YLOG=<nombre_bd>.log

- Recuperación de un esquema de usuario.

FILE=<nombre_fichero_export>.dmpFROMUSER=<propietario del esquema>TOUSER=<esquema_importación>LOG=<nombre_esquema_bd>.log



410

CASOS PRACTICOS.

- Recuperación de tablas tras un borrado accidental (si son muy voluminosas emplear opción COMMIT=Y). Es aconsejable en este caso importar a un esquema diferente a aquel al que pertenece la tabla y posteriormente hacer un “create table … as select * from …;” o un “insert into … select * from …;”.

FILE=<nombre_fichero_export>.dmpFROMUSER=<esquema_origen>TOUSER=<esquema_destino>TABLES=(<nombre_tabla1>, …)LOG=<nombre_esquema_tabla>.log

COPIAS DE SEGURIDAD



411

CASOS PRACTICOS.

- Recuperación de procedimientos, disparadores y paquetes.En este caso no es posible la importación, es necesario crear un fichero con el contenido del fichero de exportación, editarlo, seleccionar el texto buscado para confeccionar el “script” adecuado y ejecutar este ultimo.

FILE=<nombre_fichero_export>.dmpFROMUSER=<esquema_origen>SHOW=YGRANTS=NROWS=NINDEXES=NLOG=<nombre_esquema_tabla>.log

- En el caso de índices se usa el parámetro INDEXFILE.



412

RENOMBRAR ESP. DE ALMACENAMIENTO.

• Util en casos donde se emplea la utilidad para “transportar”esp. de almacenamiento (por ejemplo, recuperación avanzada TSPITR).

ALTER TABLESPACE user RENAME to u1;

– No puede renombrarse ni SYSTEM ni SYSAUX– Los esp. de almacenamiento y todos los ficheros de datos

asociados deben estar en línea.– Pueden rebnombrarse también esp. alm. en sólo lectura (READ

ONLY).

COPIAS DE SEGURIDAD



413

SQL*LOADER



414

SQL*LOADER. CARGA DE DATOS.

• SQL*Loader carga datos que proceden de otro tipo de ficherosdistintos a tablas Oracle.

• Tiene como entrada un fichero de control y uno o más ficheros de datos.

• Su salida es una base de datos donde se cargan los datos, un fichero de “log”, un fichero donde se guardan los registros rechazados (“bad file”) y un fichero donde se almacenan los registros descartados por no cumplir los criterios especificados en el fichero de control (“discard file”).

COPIAS DE SEGURIDAD



415

SQL*LOADER.



416

SQL*LOADER.FICHERO DE CONTROL.

• Es un fichero de texto con instrucciones que indica dondeencontrar los datos a cargar y su formato, la configuración del SQL*Loader al cargar los datos y como analizar e interpretarlos datos.

• Se considera dividido en tres secciones:

- Información de la sesión (opciones y cláusula INFILE que indica donde están los datos).

- Uno o mas bloques "INTO TABLE" con información sobre la tabla en la que cargar los datos (nombre y columnas).

- Datos de entrada, es opcional.

COPIAS DE SEGURIDAD



417

SQL*LOADER.FICHEROS DE DATOS.

• Lee uno o más ficheros de datos indicados en el fichero de control.

• Los datos se consideran organizados en registros.

• Un fichero de datos puede estar en tres formatos:

– “Fixed-record”. Cuando todos los registros tiene la misma longitud.

– “Variable-record”. Se indica la longitud del registro al principio del mismo.

– “Stream-record”. No se indica longitud, la marca un “terminador”.



418

SQL*LOADER.EJEMPLOS.

-- Ejemplo 1 de fichero de control

load datainfile 'example.dat' "fix 10“into table examplefields terminated by ',' optionally enclosed by '"‘(col1, col2)

example.dat:

0001, abcd,0002,fghi,0003,klmn,

COPIAS DE SEGURIDAD



419

SQL*LOADER.EJEMPLOS.

-- Ejemplo 2 de fichero de control (incluye datos en el fichero)

load datainfile *into table deptfields terminated by ',' optionally enclosed by '"‘(deptno, dname, loc)begindata12,research,"saratoga“10,"accounting",cleveland11,"art",salem13,finance,"boston“21,"sales",phila.22,"sales",rochester42,"int'l","san fran"



420

SQL*LOADER.EJECUCION.

• Desde la línea de sentencias debe ejecutarse:

sqlldr userid=<usuario>/<contraseña> control=<nombre_fichero_control> log=<nombre_fichero_log>

COPIAS DE SEGURIDAD



421

VISTAS.

• DBA_DATAPUMP_JOBS. Trabajos Data Pump activos.

• DBA_DATAPUMP_SESSIONS. Sesiones de usuario asociadas a un trabajo.

• DBA_DIRECTORIES. Directorios definidos en bd.

• V$SESSION_LONGOPS. Información sobre desarrollo de trabajos.



Administración y Ajuste Avanzados de Oracle 10g



423

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.



424

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 (B-tree 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.



425

TEMA 1

INSTALACIÓN DE ORACLE10g



426

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.



427

ESQUEMA DEL PROCESO DE INSTALACIÓN

• Descargar SW de Oracle:http://www.oracle.com/technology/software/products/database/oracle10g/index

• 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

INSTALACIÓN DE ORACLE10g Administración y Ajuste de Oracle 10g


428

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.




429

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



430

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)




431

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



432

PARÁMETROS DEL KERNELEjemplo con Linux FC3(http://www.oracle-base.com/articles/10g/OracleDB10gR2InstallationOnFedora3.php)

Añadir las siguientes líneas al fichero /etc/sysctl.conf:

kernel.shmall = 2097152kernel.shmmax = 2147483648kernel.shmmni = 4096# semaphores: semmsl, semmns, semopm, semmnikernel.sem = 250 32000 100 128fs.file-max = 65536net.ipv4.ip_local_port_range = 1024 65000net.core.rmem_default=262144net.core.rmem_max=262144net.core.wmem_default=262144net.core.wmem_max=262144

Actualizar los parámetros en memoria con # /sbin/sysctl -p




433

Paquetes necesariosFEDORA CORE 3 Linux

# De Fedora Core 3 Disk 1cd /media/cdrom/Fedora/RPMSrpm -Uvh setarch-1*rpm -Uvh tcl-8*rpm -Uvh compat-libstdc++-8*

# De Fedora Core 3 Disk 2cd /media/cdrom/Fedora/RPMSrpm -Uvh xorg-x11-deprecated-libs-6*rpm -Uvh openmotif-2*rpm -Uvh compat-db-4*

# De Fedora Core 3 Disk 3cd /media/cdrom/Fedora/RPMSrpm -Uvh compat-libstdc++-devel-8*rpm -Uvh compat-gcc-8*rpm -Uvh compat-gcc-c++-8*rpm -Uvh libaio-0*



434

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




435

INSTALACIÓN

• Artículo de OTN sobre instalación de Oracle 10g sobre Linux:http://www.oracle.com/technology/pub/articles/smiley_10gdb_install

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



436

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



437

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í, porejemplo, 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



438

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 02-JAN-2007 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”




439

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.



440

TEMA 2

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



441

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



442

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



443

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.

DISEÑO Y CREACIÓN DE UNA BD Administración y Ajuste de Oracle 10g


444

DIMENSIONAR MEMORIA EN 10G

• La RAM debe albergar no sólo la SGA de nuestra BD, sino todos losprocesos 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#st

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




445

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)



446

DIMENSIONAR LA SGAShared-Pool y Buffer-Caché• 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 TYPICALDISEÑO Y CREACIÓN DE UNA BD



447

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. DISEÑO Y CREACIÓN DE UNA BD Administración y Ajuste de Oracle 10g


448

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). DISEÑO Y CREACIÓN DE UNA BD



449

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 50-100M, intentando que los “log

switch” sucedan cada 20-30 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).



450

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 ORDERBY, GROUP BY, DISTINCT, UNION, INTERSECT or MINUS, non-indexed 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




451

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.



452

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




453

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

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



454

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”




455

ORACLE MANAGED FILES (OMF)

• OMF permite que Oracle se encargue de la creación de los ficherosque 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;



456

DBCA (DataBase Configuration Assistant)

• En Unix/Linux se ejecuta con “dbca”. Se trata de un asistente gráficoque 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.




457

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



458

PRACTICAS TEMA 2

• 2.1. Diseñar una BD teniendo en cuenta las contiendas de E/S y laorganizació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 porOMFxy.

• 2.5. Consultar el “Simulador de DBCA”.




459

TEMA 3

ESTRUCTURAS DE ALMACENAMIENTO



460

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 B-tree y Bitmap.• RECYCLEBIN y drop table.• Envío de correo con UTL_MAIL.• Encolar y/o suspender la BD.



461

BLOQUES, EXTENSIONES Y SEGMENTOS

• La unidad mínima de asignación de espacioes el bloque de datos (múltiplo del bloquedel S.O.: 2, 4, 8, 16 y 32Kb); de modo queun conjunto contiguo de bloques formanuna extensión. Y las extensiones formansegmentos de una determinada estructurade datos (tablas, índices, rollback,temporal, etc).

• Oracle asigna espacio a un segmento enunidades de una extensión. Todas lasextensiones de un mismo segmento residenen el mismo tablespace.

• Oracle pide espacio en múltiplos del bloquede datos, cuyo tamaño se indica con elparámetro db_block_size.




462

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.




463

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



464

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.




465

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.




466

EXTENSIONES Y SU ASIGNACIÓN

• Una extensión es una unidad lógica de almacenamiento compuesta porun conjunto de bloques contiguos. Una o más extensiones componenun 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 bloqueslibres contiguos.

• Las extensiones vacías no se devuelven al tablespace hasta que seborra el objeto (drop table/cluster), a no ser que hagamos “TRUNCATE... DROP STORAGE;” o “ALTER TABLE ... DEALLOCATE UNUSED;”.




467

SEGMENTOS

• Un segmento es un conjunto de extensiones que contienen todos losdatos de una estructura lógica de almacenamiento específica, dentrode un tablespace (segmentos de datos, segmentos de índice,segmentos temporales, etc).

• El primer bloque de un segmento (Header) contiene un directorio delas extensiones que lo integran.

• Segmento de datos: es una tabla normal, o una partición de unaparticionada, o un cluster de tablas.

• Segmento de índices: índice no particionado, o partición de unoparticionado. No tienen que estar en el mismo tablespace que lastablas correspondientes.

• Segmentos temporales: Oracle los usa para hacer ordenaciones, queno 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ámetrosort_area_size. Sin MTS, usar pga_aggregate_target para todas lasáreas de sort de todas las sesiones (todas las PGAs).




468

GESTION AUTOMATICA DEL ESPACIO DE LOS SEGMENTOS

• Desde la versión 9i se incluye la posibilidad de gestionar el espacio delos segmentos automáticamente, siendo más fácil, con mejorutilización del espacio, y también mejor rendimiento en las operacionesconcurrentes de inserción.

• Cada segmento contiene un bitmap que describe el estado deocupación de cada bloque, y que se guarda en un conjuntoindependiente de bloques.

• Se puede activar sólo para los tablespaces permanentes manejadoslocalmente, 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 espaciode los segmentos, no tiene vuelta atrás.

• Oracle recomienda la gestión automática porque obtiene mayorrendimiento y es mucho más fácil de mantener.

• Ya no hace falta PCTUSED.ESTRUCTURAS DE

ALMACENAMIENTO



469

COMPRESION DE LOS SEGMENTOS DE DATOS

• Podemos indicar la clausula COMPRESS al crear una tabla (por defectoserá 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.




470

METODOS DE ACCESO A DATOSINDICES B-TREE Y BITMAP• Usaremos índices B-tree, en general, cuando vayamos a hacer

consultas que acceden frecuentemente a no más del 10-15% 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 b-tree 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 B-tree. 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. ESTRUCTURAS DE

ALMACENAMIENTO



471

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;




472

ENVIAR CORREO DESDE ORACLEPaquete UTL_MAIL

• El paquete UTL_MAIL (>=10g) no se instala por defecto por razones deseguridad.

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




473

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




474

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




475

PRACTICAS TEMA 3

• 3.1. Comprobar el tamaño del bloque de la BD. ¿Cuántas cachésde datos hay definidas?. Definir la caché keep con 1M. Definirtambié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?




476

PRACTICAS TEMA 3

• 3.5. Crear tablespace TSP4K con tamaño de bloque de 4Kb. Crearuna 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 ponerpga_aggregate_target=0? ¿cómo desactivarpga_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 , calcularlas 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.




477

TEMA 4

NUEVAS FUNCIONALIDADES DE MONITORIZACIÓN Y AJUSTE



478

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.



479

NUEVA INFRAESTRUCTURA

NUEVAS FUNCIONALIDADES DE AJUSTE Y MONITORIZACION

• Nueva infraestructura = AWR + Time Model + ASH (El parámetroSTATISTICS_LEVEL debe valer TYPICAL u ALL).

• Automatic Workload Repository (AWR). Vistas v$ + volcado a disco, por defecto cada 60min y máx 7 días (procesos MMON, MMNL). Mejor q STATSPACK.

– EXECUTE dbms_workload_repository.create_snapshot();• Active Session History (ASH). Recopila muestras cada segundo de las

sesiones activas de V$SESSION: V$ACTIVE_SESSION_HISTORY, DBA_HIST_ACTIVE_SESS_HISTORY.

• Nuevo “Time Model”: estadísticas y métricas relativas al tiempo consumido por las sesiones.

– Time Model (“DB time”, “DB CPU”, etc): V$SYS_TIME_MODEL, V$SESS_TIME_MODEL.

– Wait Classes: V$SYSTEM_WAIT_CLASS, V$SESSION_WAIT_CLASS.– Metrics (cada 60seg): V$SYSMETRIC, V$SESSMETRIC,

V$FILEMETRIC, V$EVENTMETRIC, V$WAITCLASSMETRIC, V$METRICNAME.

– OS statistics. V$OSSTAT.• Automatic Database Diagnostic Monitor (ADDM). En base a los datos

recopilados por AWR y ASH, identifica problemas y sus posibles causas, proporcionando recomendaciones e indicando los beneficios q se obtendrán.

– $ORACLE_HOME/rdbms/admin/addmrpt.sql Administración y Ajuste de Oracle 10g


480

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.



481

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



482

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”



483

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;



484

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.



485

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

– 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.Administración y Ajuste de Oracle 10g


486

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



487



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



488



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



489

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;



490

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;



491

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 (L-V 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 Administración y Ajuste de Oracle 10g


492

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 OUTNota: la info obtenida se calcula con datos desde último arranque. Muchas funciones tienen versiones con parámetros fecha ini y fin.



493

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.




494

TEMA 5

MONITORIZACIÓN Y AJUSTE TRADICIONAL



495

TEMA 5.MONITORIZACIÓN Y AJUSTE TRADICIONAL.

• Eventos de espera.• Vistas dinámicas: información del sistema y de las sesiones.• Ajuste de la Shared-Pool.• 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.



496

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



497

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



498

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.



499

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



500

AJUSTE DE LA SHARED-POOLINTRODUCCION


• Oracle guarda las sentencias SQL y los paquetes en la Shared-pool, 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 ORA-04031, 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.



501

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



502

AJUSTE DE LA SHARED-POOLGENERALIDADES


• Que siempre haya espacio libre en la SharedPool, puede significar quesobra; 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 (ora-4031):

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.



503

AJUSTE DE LA SHARED-POOLLIBRARY 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 sercasi 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/SQLson: 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.



504

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



505

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



506

AJUSTE DE LA SHARED-POOLCOMPARTIR 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 (valoralto puede provocar ora-4031, comprobar % de uso). Util con Oracle Forms cuando los forms se abren y cierran con frecuencia.



507

AJUSTE DE LA SHARED POOLLATCHES DE LA LIBRARY CACHE


Si alguno de los latches está provocando la mayoría de “sleeps”, entonceshay 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%';



508

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;



509

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.



510

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



511

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).Administración y Ajuste de Oracle 10g


512

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.



513

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 comprobarcheckpoints y log_switchs. Se debe hacer q los checkpoints coincidan con los log switchs (cada 15-30 minutos aprox.).



514

AJUSTE DEL ROLLBACKGENERALIDADES


• Si usamos undo automático (>=9i), podemos consultar V$UNDOSTAT:una fila cada 10 minutos. La columna SSOLDERRCNT muestra los errores ORA-1555.

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



515

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 “ORA-1555 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 ora-1555.

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



516

AJUSTE DE SEGMENTOS DE SORTGENERALIDADES


• Cuando ocurre una ordenación, Oracle reserva tantas extensionescomo 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.



517

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.



518

AJUSTE DE LOS CHECKPOINTS


• Un checkpoint es el evento que sincroniza los bloques de datos enmemoria 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”).



519

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]



520

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.



521

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.



522

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.



523

RECOGIENDO DATOS CON “STATSPACK”


• La forma más sencilla de crear un snapshot es conectando comousuario 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 indicarparámetros para, por ejemplo, indicar el nivel de detalle de las estadísticas (i_snap_level), e incluso una sesión sobre la que recabarestadí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).



524

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.



525

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



526

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;




527

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.




528

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




529

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.




530

TEMA 6.

NET.

COMUNICACIONES



531

TEMA 6. NET.

• ORACLE NET SERVICES.• ORACLE NET.

– ORACLE NET. CLIENTE/SERVIDOR.– ORACLE NET. WEB y APP. SERVER.– ORACLE NET. WEB SIN APP. SERVER.– ORACLE NET. CONNECTION POOLING.

• LISTENER.• ORACLE CONNECTION MANAGER.• OTROS COMPONENTES• CONCEPTOS.

– SERVICIO.– INSTANCIA.– REGISTRO DE SERVICIO.– CONECTOR.– MAPEOS.

COMUNICACIONES Administración y Ajuste de Oracle 10g


532

TEMA 6. NET.

• CONFIGURACION. MODELOS. MODELO LOCAL.• TNSNAMES.ORA• LISTENER.ORA

– SECCION PROTOCOLO.– SECCION REGISTRO SERVICIO.– PARAMETROS DE CONTROL.– LISTENER.ORA Y JSERVER.– CONTROL DEL “LISTENER”.

• SQLNET.ORA• CONFIGURACION BASICA NET.• DATABASE LINK.

COMUNICACIONES



533

ORACLE NET SERVICES.

• “Oracle Net Services” proporciona soluciones deconectividad para entornos distribuidos y heterogéneos. Está integrado por:

– Oracle Net.

– Listener.

– Oracle Connection Manager.

– Herramientas de comunicaciones.–

» Oracle Net Configuration Assistant.

» Oracle Net Manager.

» Oracle Enterprise Manager.



534

ORACLE NET.

• Es el sw que permite establecer y mantener una sesiónde red desde una aplicación cliente a un servidor de bd; así como del intercambio de mensajes entre ambos.

Es capaz de hacerlo al estar localizado en cada ordenador de la red.

• Existen distintas tipologías de conexión:

– Conexiones cliente/servidor (C/S).

– Conexiones web cliente.

– Conexiones web cliente sin uso de servidor de aplicaciones (Application Server).

COMUNICACIONES



535

ORACLE NET. CLIENTE/SERVIDOR.

• Oracle Net reside en el cliente y en el servidor. Se sitúa en lacapa más alta de protocolos de red, que indica como las aplicaciones acceden a la red y como los datos se dividen en paquetes para su transmisión. Oracle Net interactúa con el protocolo TCP/IP -con o sin SSL- pero también puede trabajarcon el protocolo SDP (redes “Infiniband”).

• Oracle Net se compone a su vez de “Oracle Net foundation layer” (establece y mantiene la conexión) y “Oracle protocolsupport” (mapea a protocolos estandar desde la tecnología Oracle Net).

• Las aplicaciones cliente Java acceden a la bd Oracle empleando además JDBC (Java Database ConnectivityDriver). Oracle ofrece dos manejadores “JDBC OCI” -clientes con instalación local Oracle- y “JDBC Thin Driver” -clientes sin instalación local Oracle, por ejemplo “applets”-.



536


COMUNICACIONES



537


COMUNICACIONES

• OCI: Oracle Call Interface. SW usado por el cliente para interactuar con el servidor de bd (interfaz entre la aplicación cliente y el lenguaje SQL que comprende el servidor).

• TTC: Two-Task Common.• OPI: Oracle Program Interface.



538


COMUNICACIONES



539


COMUNICACIONES

• El manejador JDBC OCI emplea un esquema de comunicaciones similar al estándar C/S.• JDBC Thin driver emplea una implementación Java del Oracle Net Foundation Layer

llamada JavaNet y una implementación Java de TTC llamada JavaTTC.



540

ORACLE NET. WEB y APP. SERVER.

• La conexión de aplicaciones web cliente (con o sin Web Application Server) a una bd es similar al caso C/S.

COMUNICACIONES



541


• El protocolo HTTP, “Hypertext Transport Protocol” permite comunicar entre los navegadores web y los servidores de aplicaciones, estos gestionan datos, controlan el acceso a los mismos y sirven las peticiones de los navegadores.

• Un servidor de aplicaciones puede soportar aplicaciones Java y “servlets” también.



542


COMUNICACIONES



543

ORACLE NET. WEB SIN APP. SERVER.

• Es posible acceder desde los clientes web directamente a la bd, sin servidor de aplicaciones, como al usar “Java applet”. Además la bd puede aceptar conexiones con protocolos como HTTP, FTP o WebDAV (conexiones a Oracle XML DB).



544

ORACLE NET. CONNECTION POOLING.

• Si se ejecutan múltiples aplicaciones web interactivas, algunasde ellas pueden, en un momento dado, estar inactivas. “Connection pooling” permite a la bd interrumpir a nivel físico una sesión inactiva, la sesión lógica permanece abierta, y restablecer la conexión física cuando haya alguna petición.

COMUNICACIONES



545

LISTENER.

• En la bd recibe la conexión inicial. Está configurado con unadirección de protocolo, aquellos clientes configurados con esta dirección pueden enviar peticiones al “listener”. Una vez establecida la conexión, el cliente y la bd comunican directamente entre ellos.



546

ORACLE CONNECTION MANAGER.

• Permite que múltiples sesiones cliente sean multiplexadas a través de una sola conexión a una bd.

COMUNICACIONES



547

OTROS COMPONENTES

• Oracle Net Configuration Assistant.

– Permite configurar los componentes básicos de red después de realizar la instalación de bd.

– Oracle Universal Installer lanza esta herramienta durante la instalación del sistema gestor de bd.

– En UNIX debe ejecutarse $ORACLE_HOME/bin/netca

• Oracle Net Manager.

– Proporciona un entorno integrado de configuración y gestión de Oracle Net Services.

– En UNIX debe ejecutarse $ORACLE_HOME/bin/netmgr

En Oracle 10g, muchas funcionalidades de Net Manager están integradas en Oracle Enterprise Manager.



548

CONCEPTOS BASICOS

COMUNICACIONES



549

CONCEPTOS. SERVICIO.

• Una bd es un “servicio” desde el punto de vista de los clientes.

• El servicio está identificado por un nombre de servicio que viene determinado por el parámetro de inicialización SERVICE_NAMES. Por defecto es el nombre “global database”, compuesto por el nombre de bd (parámetro DB_NAME) y el nombre de dominio (DB_DOMAIN). Los clientes usan el nombre de servicio para identificar la bd a la que acceden.

• Este parámetro también puede ser modificado dinámicamente mediante ALTER SYSTEM.



550


COMUNICACIONES

• La bd puede tener uno o más servicios asociados; así puede ser identificada de distintas formas por clientes diferentes, y un administrador puede limitar recursos del sistema.



551


• La información necesaria para una conexión se almacena en un repositorio (local o centralizado -LDAP-).



552

CONCEPTOS. INSTANCIA.

• Una base de datos tiene al menos una instancia integradapor un área de memoria llamada System Global Area (SGA)y por procesos Oracle.

• El nombre de la instancia viene indicado por el parámetro de inicialización INSTANCE_NAME. Por defecto se refiere al Oracle System Identifier (SID) de la instancia.

COMUNICACIONES



553

CONCEPTOS. REGISTRO DE SERVICIO.

• “Service registration” es una utilidad por la que el proceso PMON automáticamente proporciona información al “listener”, de forma que listener.ora no precisa ser configurado con información estática tal como:

– Nombres de servicio para cada instancia de la bd.

– Nombres de instancia de la bd.

– Manejadores de servicio (“dispatcher” o servidor dedicado) disponible para cada instancia.

– Dispatcher, instancia e información “node load” que permite al “listener” determinar qué “dispatcher” puede manejar adecuadamente una petición cliente. Si todos los “dispatchers” están bloqueados, el “listener” puede habilitar un servidor dedicado para la conexión.



554


• Para asegurar que el registro de servicio funciona correctamentem el fichero de parámetros de inicialización debería contener los parámetros:

SERVICE_NAMES, para el nombre de servicio de la bd

INSTANCE_NAME, para el nombre de la instancia

• El valor del parámetro SERVICE_NAMES se considera antes que el “global database name” (compuesto por DB_NAME y DB_DOMAIN) y el valor de INSTANCE_NAME se considera antes que el SID indicado durante la instalación o creación de la bd.

COMUNICACIONES



555


• Los eventos relacionados con el registro de servicio sealmacenan en el fichero listener.log:

– service_register. Recepción de información de instancia por el “listener”.

– service_update. Recepción de información actualizada de una instancia por parte del “listener”.

– service_died. El “ listener” ha perdido su conexión con el PMON. Se descarta cualquier información de registro para la instancia, los clientes no podrán conectarse a la istancia hasta un nuevo registro del PMON.



556

CONCEPTOS. CONECTOR.

• Un cliente usa un descriptor de conexión que indica la localización de la bd y el nombre del servicio de bd.

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=<nombre_host/direccionIP>)(PORT=1521))(CONNECT_DATA= (SERVICE_NAME=<nombre_de_servicio>)))

También puede indicarse la conexión a una instancia específica (Real Application Clusters):

(DESCRIPTION= ... (INSTANCE_NAME=<nombre_instancia>)))

• Los manejadores de servicio en el servidor pueden ser un “dispatcher” (modo servidor compartido) o un proceso servidor dedicado.

COMUNICACIONES



557

CONCEPTOS. CONECTOR.

• Puede suceder que un cliente desee usar un manejador de servicio particular, en este caso debe indicarse en el conector:

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=host)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=nombre_servicio)(SERVER=shared/dedicated)))

• Si no se indica el valor para el parámetro SERVER se asume por defecto la configuración “shared server”. Si no hay “dispatchers” disponibles, se usarán servidores dedicados.



558

CONCEPTOS. MAPEOS.

• El establecimiento de la correspondencia entre el nombre de servicio y su conector es posible mediante repositorios de información que permiten dicho mapeo a través de una “naming method”:

– “Local Naming”. Usa el fichero “tnsnames.ora”.

– “Directory Naming”. Emplea un sistema de directorios LDAP.

– “Easy Connect Naming”. No requiere configuración. Permite a los clientes conectar a la bd usando una cadena TCP/IP que incluye el nombre de servidor, un puerto y un nombre de servicio:

CONNECT username/password@host[:port][/service_name]

– “External Naming”. Emplea un sistema no Oracle.

COMUNICACIONES



559

TIPOS DE CONFIGURACION



560

CONFIGURACION. MODELOS.

• Existen dos modelos de configuración de Oracle Net:

– Localizado o no centralizado: la información se almacena en un fichero tnsnames.ora local a cada máquina en la red.

– Centralizado: la información se guarda en un directorio central (LDAP).

• En la exposición se considera un modelo de configuración no centralizado, donde la información sobre direcciones de red se almacena en el fichero tnsnames.ora de cada sistema.

COMUNICACIONES



561

CONFIGURACION. MODELO LOCAL.

• Existen los siguientes ficheros de configuración:

– cman.ora ... Residente en la máquina donde se ejecuta Oracle Connection Manager.

– listener.ora ... En el servidor de bd. Con infomación sobre protocolo , dirección de escucha, servicios para los que se escucha y parámetros de control.

– sqlnet.ora ... En el cliente y en el servidor bd. Puede contener ruta de conexiones, parámetros de control de acceso a bd, parámetros de Oracle Advanced Security, ...

– tnsnames.ora ... En los clientes. Contiene “net service names” -nombre de servicio asociado a un descriptor de conexión-. Usado en los mapeos.



562

CONFIGURACION. MODELO LOCAL.

• Los ficheros de configuración residen generalmente en “$ORACLE_HOME/network/admin”, aunque pueden hacerlo en otros lugares.

• El orden de búsqueda para sqlnet.ora es:

– El directorio indicado por la variable TNS_ADMIN– El directorio $ORACLE_HOME/network/admin

● El orden de búsqueda para cman.ora, listener.ora y tnsnames.ora es:

– El directorio indicado por la variable TNS_ADMIN– En UNIX, el directorio global de configuración (“global

configuration directory”).– El directorio $ORACLE_HOME/network/admin

COMUNICACIONES



563

TNSNAMES.ORA



564

TNSNAMES.ORA

• Contiene nombres de servicio de red, usados al establecer unaconexión, de red mapeados a descriptores de conexión. Dichos descriptores contienen la localización de un “listener” a través de una dirección de protocolo y el nombre de servicio de la bd al que conecta.

• Por defecto, tnsnames.ora reside en

$ORACLE_HOME/network/admin aunque también puede estaren el directorio indicado por la variable de entorno TNS_ADMIN o el “global configuration directory”. Su sintaxis básica es:

nombre_servicio=(DESCRIPTION=

(ADDRESS=(PROTOCOL=tcp)(HOST=host)(PORT=1521))(CONNECT_DATA= (SERVICE_NAME=nombre_servicio)))

COMUNICACIONES



565

TNSNAMES.ORA

nombre_servicio=(DESCRIPTION_LIST=(DESCRIPTION=(ADDRESS=(protocol_address_information))(ADDRESS=(protocol_address_information))(ADDRESS=(protocol_address_information))

(CONNECT_DATA= (SERVICE_NAME=service_name)))(DESCRIPTION=(ADDRESS=(protocol_address_information))(ADDRESS=(protocol_address_information))(ADDRESS=(protocol_address_information))

(CONNECT_DATA= (SERVICE_NAME=service_name))))

donde ADDRESS define la localización de “listener” y CONNECT_DATA define el servicio al cual conectar.



566

LISTENER.ORA

COMUNICACIONES



567

LISTENER.ORA

• El “listener” es un proceso que corre en la bd. Recibepeticiones de conexión de los clientes y gestiona el tráfico de dichas peticiones a la bd. Su configuración se almacena en un fichero llamado listener.ora y sus mensajes se generan en el fichero listener.log

• Dado que todos los parámetros de configuración tienen valores por defecto, es posible arrancar y usar el “listener” sin configurar. El “listener” se llama por defecto LISTENER, no soporta servicios hasta el arranque de la bd, y escucha atendiendo a los siguientes valores:

(ADDRESS=(PROTOCOL=tcp)(HOST=host_name)(PORT=1521))

• El puerto por defecto para conexión al “listener” es el 1521(aunque en futuras versiones puede cambiar al 2483, TCP/IP, y 2484, TCP/IP con SSL). Puertos inferiores a 1024 están reservados para su uso por procesos privilegiados.



568

LISTENER.ORA

COMUNICACIONES

Cada listener está configurado con una o varias direcciones de protocolo, los clientes configurados con una de estas direcciones pueden enviarle peticiones. Una vez recibida la petición, el listener elige un manejador de servicio apropiado para servir la petición y redirige la misma hacia él.



569

LISTENER.ORA

• El listener determina si un servicio de la bd y sus manejadoresde servicio están disponibles mediante el registro del servicio. Durante el mismo, el proceso PMON proporciona al listener información sobre:

– Nombres de los servicios de bd disponibles.

– Nombre de la instancia asociada con los servicios.

– Manejadores de servicio (dispatchers y servidores dedicados) disponibles para la instancia -tipo, dirección de protocolo y carga actual y máxima-.



570

LISTENER.ORA

• Si el listener no se está ejecutando cuando arranca lainstancia, PMON no puede registrar la información de servicio. PMON intenta conectar periódicamente, no obstante, pueden pasar hasta 60 segundos antes de que PMON registre la información tras el arranque del listener. Para iniciar el registro de información inmediatamente tras el arranque del listener debe emplearse la sentencia SQL:

ALTER SYSTEM REGISTER;

• El listener rechaza las peticiones previas al registro. Si la instancia está en modo restringido, PMON ordena al listenerbloquear las conexiones y los clientes reciben un error:

ORA-12526: TNS:listener: all appropriate instances are in restricted modeORA-12527: TNS:listener: all appropriate instances are in restricted mode or

blocking new connectionsORA-12528: TNS:listener: all appropriate instances are blocking new

connections

COMUNICACIONES



571

LISTENER.ORA

• Por defecto, PMON registra información del servicio referenteal puerto TCP/IP número 1521. Para poder usar un puerto distinto debe configurarse el parámetro de inicialización LOCAL_LISTENER

• En un entorno “shared server” puede emplearse el atributo LISTENER del parámetro DISPATCHERS en el fichero deinicialización. Como LOCAL_LISTENER y el atributo LISTENERpermiten a PMON registrar información del “dispatcher” con el listener, no es preciso especificar ambos si los valores del listener son los mismos.

• Por ejemplo, para configurar el listener en el puerto 1421:

LOCAL_LISTENER=listener1

DISPATCHERS="(PROTOCOL=tcp)(LISTENER=listener1)"

En el tnsnames.ora:listener1=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=

host)(PORT=1421)))



572

LISTENER.ORA

• El registro dinámico de servicios no requiere ninguna configuración del fichero listener.ora

• El “listener” emplea la información dinámica adquirida mediante el registro dinámico antes de usar la información configurada estáticamente en el fichero listener.ora.

• Durante la instalación de la bd, Oracle Universal Installerejecuta el Oracle Net Configuration Assistant; este permite configurar el “listener” con un nombre y una dirección concreta.

• También se crea una entrada para escucha del protocolo IPCque se configura de forma automática y sirve a procedimientos externos (escritos en un 3GL que pueden ser llamados desde el código PL/SQL -sólo C-).

COMUNICACIONES



573

LISTENER.ORA

• En la configuración del “listener” se indica:

– Nombre.– Dirección que acepta peticiones.– Servicios para los que escucha (la configuración estática es

necesaria si se usa Oracle Enterprise Manager).– Parámetros de control.

• Pueden configurarse múltiples “listener”, con distintos nombres, en un fichero listener.ora. Sin embargo, se recomienda ejecutar sólo uno por nodo en la mayoría de entornos.

• SID_NAME (valor del parámetro de inicialización INSTANCE_NAME), GLOBAL_DBNAME (servicio de bd, generalmente en versiones 8.x -combinación de DB_NAME y DB_DOMAIN-) y ORACLE_HOME son parámetros estáticos definibles en listener.ora



574

LISTENER.ORA.SECCION PROTOCOLO.

• Define las direcciones de las que el “listener” acepta peticiones.

LISTENER_NOMBRE=(DESCRIPTION=

(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=host)(PORT=1521))(ADDRESS=(PROTOCOL=ipc)(KEY=extproc))))

• El parámetro QUEUESIZE permite indicar el número de peticiones concurrentes que puede aceptar el “listener” via TCP/IP o IPC. Su valor por defecto depende del s.o..

LISTENER_NOMBRE= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=host) (PORT=1521)(QUEUESIZE=20)))

COMUNICACIONES



575

LISTENER.ORA.SECCION PROTOCOLO.

• El parámetro RECV_BUF_SIZE permite indicar, en bytes, el tamaño del “buffer” para recibir operaciones de sesiones (en TCP/IP, TCP/IP with SSL, y SDP). Su valor depende del s.o.

LISTENER_NOMBRE = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=host)(PORT=1521)(RECV_BUF_SIZE=11784))(ADDRESS=(PROTOCOL=ipc)(KEY=extproc)(RECV_BUF_SIZE=11784)))

• Mediante SEND_BUF_SIZE puede indicarse, en bytes, el tamaño del “buffer” para enviar operaciones de sesiones (en TCP/IP, TCP/IP with SSL, y SDP). Su valor depende del s.o.

LISTENER_NOMBRE=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=host)(PORT=1521)(SEND_BUF_SIZE=11280))(ADDRESS=(PROTOCOL=ipc)(KEY=extproc)(SEND_BUF_SIZE=11280))))



576

LISTENER.ORA.SECCION REGISTRO SERVICIO.

• La sección SID_LIST se usa para configurar estáticamente el “listener”. Requerida por compatibilidad con bbdd Oracle8.0, procedimientos externos y ciertas herramientas de gestión (Oracle Enterprise Manager). En versiones 9i u 8i está infomación se registra dinámicamente al arrancar la instancia.

SID_LIST_<nombre_listener>= (SID_LIST= (SID_DESC=

(SDU=2085)(GLOBAL_DBNAME=sales.us.acme.com)

(ORACLE_HOME=/oracle9i) (SID_NAME=sales)) (SID_DESC= (SID_NAME=plsextproc) (ORACLE_HOME=/oracle9i) (PROGRAM=extproc)))

COMUNICACIONES



577

LISTENER.ORASECCION REGISTRO SERVICIO.

• Donde:

– SID_LIST ... lista de descripciones.

– SID_DESC ... información de servicio.

– SDU ... Optimizar la transferencia de datos usando un tamaño indicado de session data unit (SDU).

– GLOBAL_DBNAME ... “Global database name” de la bd (el listener comprueba la igualdad entre el valor de este parámetro y el del parámetro SERVICE_NAME en el descriptor de conexión del cliente). Permite identificar el servicio de bd.

– ORACLE_HOME ... localización del servicio (opcional en UNIX).

– PROGRAM ... Nombre del programa de servicio ejecutable.

– SID_NAME ... SID de la instancia (parámetro INSTANCE_NAME).



578

LISTENER.ORA. PARAMETROS DE CONTROL.

– LOG_DIRECTORY_<nombre_listener> indica el directorio dedestino del fichero de log del “listener”. Por defecto el directorio $ORACLE_HOME/network/log

– LOG_FILE_<nombre_listener> indica el nombre del fichero de log para el “listener”. Por defecto listener.log

– TRACE_DIRECTORY_<nombre_listener> indica el directorio de destino de los ficheros de traza del “listener”. Por defecto $ORACLE_HOME/network/trace

– TRACE_FILE_<nombre_listener> indica el nombre del fichero de traza del “listener”. Por defecto listener.trc

– TRACE_LEVEL_<n_listener>. Nivel de detalle de la traza (0, sin traza, a 16, máximo nivel de traza).

– TRACE_FILELEN_<n_listener>. Tamaño de los ficheros de traza (KB). Al alcanzarlo, traza se escribe en el siguiente fichero.

– TRACE_FILENO_<n_listener>. Número de ficheros de traza.

COMUNICACIONES



579

LISTENER.ORA Y JSERVER.

• Clientes acceden a aplicaciones Enterprise JavaBeans (EJBs) yCommon Object Request Broker Architecture (CORBA), opción Oracle Jserver, en una bd Oracle8i sobre una conexión Inter-Orb Protocol (IIOP). IIOP es una implementación de General Inter-Orb Protocol (GIOP) sobre TCP/IP. Debe configurarse el puerto 2481 para TCP/IP o 2482 para TCP/IP con SSL.

listener= (DESCRIPTION_LIST= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=2481)) (PROTOCOL_STACK= (PRESENTATION=giop) (SESSION=raw))))



580

CONTROL DEL “LISTENER”.

• La utilidad para control del “listener” (Listener Control Utility) permite administrar este componente. La sintaxis es:

S.O.> LSNRCTL <sentencia> [nombre_listener]

• Si no se indica nombre, hace referencia al “listener” de nombre “listener”. Para arrancar el “listener” lsnr:

LSNRCTL START lsnr

• También pueden ejecutarse sentencias en el “prompt” LSNRCTL (se obtiene tecleando lsnrctl sin argumentos).

S.O.> lsnrctlLSNRCTL> START lsnr

COMUNICACIONES



581


• Pueden combinarse distintas órdenes en un fichero de texto y ejecutarlas de la forma:

lsnrctl @file_name

• Para parar el “listener” lsnr: LSNRCTL STOP lsnr

• Para obtener información: LSNRCTL STATUS lsnr

• Para comprobar los valores actuales: LSNRCTL SHOW

• Para activar la traza: lsnrctl trace <nivel> <lsnr>



582


• Mediante la orden SERVICES se obtiene información sobre los servicios e instancias registradas, y los manejadores asociados a cada instancia.

LSNRCTL SERVICES lsnr

COMUNICACIONES



583

SQLNET.ORA



584

SQLNET.ORA

• Los parámetros de configuración para cliente y servidor, perfil, que permiten especificar preferencias de Oracle Net se almacenan en el fichero sqlnet.ora

• Sus mensajes se generan en el fichero sqlnet.log

• Permite realizar acciones como:

– Priorizar modelos de localización (NAMES.DIRECTORY_PATH).

– Permitir o no el acceso a ciertos clientes.• Acceso denegado.

TCP.EXCLUDED_NODES=(<dir_IP>|<servidor>)

• Acceso permitido:TCP.INVITED_NODES=(<dir_IP>|<servidor>)

• Comprobar valores anteriores .TCP.VALIDNODE_CHECKING = yes/no

COMUNICACIONES



585

SQLNET.ORA

– Indicar el intervalo, en segundos, que media para el envio de una confirmación para verificar que la conexión está activa.

SQLNET.EXPIRE_TIME

Un valor mayor que 0 asegura que no permanecen sesiones abiertas indefinidamente. Si la confirmación encuentra una sesión que ha terminado o que no está en uso, devuelve un error y fuerza al proceso servidor a terminar.

– Indicar un dominio por defecto. Este se añade automáticamente a cualquier nombre de servicio dado en la cadena de conexión y comparado con los nombres de servicio de tnsnames.ora

NAMES.DEFAULT_DOMAIN=<nombre_dominio>



586

SQLNET.ORA

– Indicar el intervalo, en segundos, para completar unaoperación de envio a los clientes tras el establecimiento de la conexión (recomendable en entornos donde las conexiones con los clientes suelen verse interrumpidas):

SQLNET.SEND_TIMEOUT

Si el servidor no puede completar el envío en dicho tiempo, se generan en el fichero sqlnet.log los errores:

“ORA-12535: TNS:operation timed out” y“ORA-12608: TNS: Send timeout occurred”

COMUNICACIONES



587

SQLNET.ORA

– Indicar el intervalo, en segundos, para el servidor esperapor datos de un cliente tras el establecimiento de la conexión (recomendable en entornos donde las conexiones con los clientes suelen verse interrumpidas):

SQLNET.RECV_TIMEOUT

Si un cliente no envía datos se generan en el fichero sqlnet.log los errores:

ORA-12535: TNS:operation timed out y ORA-12609: TNS: Receive timeout occurred



588

SQLNET.ORA

– Indicar parámetros de control del “log”:

• LOG_DIRECTORY_CLIENT. Directorio de destino para el fichero de “log” (por defecto el directorio de trabajo actual).

• LOG_FILE_CLIENT. Nombre del fichero de “log” para el cliente (por defecto sqlnet.log).

• LOG_DIRECTORY_SERVER. Directorio destino para ficheros de “log” del servidor (por defecto $ORACLE_HOME/network/log).

• LOG_FILE_SERVER. No aplicable. Hace referencia al fichero de “log” del servidor: sqlnet.log

– Indicar parámetros de traza:

• TRACE_DIRECTORY_CLIENT. Directorio destino para trazas del cliente, por defecto $ORACLE_HOME/network/trace

COMUNICACIONES



589

SQLNET.ORA

• TRACE_DIRECTORY_SERVER. Directorio destino para trazasdel servidor, por defecto $ORACLE_HOME/network/trace

• TRACE_FILE_CLIENT. Nombre del fichero de traza cliente. Por defecto sqlnet.trc

• TRACE_FILE_SERVER. Nombre del fichero de traza servidor. Por defecto svr_pid.trc

• TRACE_FILELEN_CLIENT. Tamaño de los ficheros traza cliente (KB). Al alcanzar el tamaño, la traza se escribe al fichero siguiente. El número de ficheros se indica conTRACE_FILENO_CLIENT

• TRACE_FILELEN_SERVER. Tamaño de los ficheros traza servidor (KB). Al alcanzar el tamaño, la traza se escribe al fichero siguiente. El número de ficheros se indica conTRACE_FILENO_SERVER

• TRACE_LEVEL_CLIENT. Nivel de detalle de la traza (0, sin traza, a 16, nivel máximo de traza).

• TRACE_LEVEL_SERVER. Nivel de detalle de la traza (0, sin traza, a 16, nivel máximo de traza).



590

SQLNET.ORA

• Para configurar un modelo local o no centralizado, el parámetro NAMES.DIRECTORY_PATH del fichero sqlnet.ora -indica el orden de los métodos de configuración que Oracle Net emplea para resolver los identificadores- debe contener en primer lugar el valor tnsnames.

NAMES.DIRECTORY_PATH=(tnsnames)

• “Easy connect naming” se configura automáticamente en la instalación, es neceasrio que venga especificado EZCONNECTen NAMES.DIRECTORY_PATH

NAMES.DIRECTORY_PATH=(ezconnect, tnsnames)

COMUNICACIONES



591

CONFIGURACION BASICA NET



592

CONFIGURACION BASICA NET.

• Se muestra la forma de intercomunicar una aplicación cliente con una bd a través de una red TCP/IP.

• Se asume que:

– Servidor BD y cliente en la misma red.

– Servidor BD: Instalada bd y TCP/IP. Configurado un “listener”.

– Cliente: Instalado “Oracle Client” y TCP/IP.

COMUNICACIONES



593


1.- Confirmar conexión de red.

• Realizar un “loopback test” para comprobar que el servidor de bd puede comunicar con si mismo

ping <nombre_maquina> o ping <direccion_IP>

• Comprobar que existe comunicación entre el cliente y la bd (por ejemplo, con “ping”).



594


2.- Arrancar el”listener” y la bd.

• Desde s.o.:

lsnrctlLSNRCTL> start <nombre_listener>

Nombre_listener debe estar definido en el fichero listener.ora. Debe aparecer un mensaje indicando que el “listener” ha arrancado.

• Arrancar la bd.

sqlplus /nologSQL> CONNECT / as sysdbaSQL> STARTUP

COMUNICACIONES



595


• Comprobar que el “service registration” de la bd ha tenidolugar de forma correcta:

LSNRCTL> SERVICES [nombre_listener]

• La sentencia “SERVICES” muestra los servicios soportados porla bd y los manejadores de servicio disponibles, al menos uno.



596

CONFIGURACION BASICA NET. SERVICIOS.

COMUNICACIONES



597




598


Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=net)))

Services Summary...

Service "sales.us.acme.com" has 1 instance(s).Instance "sales", status READY, has 3 handler(s) for this service...

Handler(s):"DEDICATED" established:0 refused:0 state:ready LOCAL SERVER"D000" established:0 refused:0 current:0 max:10000 state:ready

DISPATCHER <machine: sales-server, pid: 1689>(ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=52414))

...Service "hr.us.acme.com" has 1 instance(s).

Instance "hr", status READY, has 2 handler(s) for this service...

Handler(s):"DEDICATED" established:0 refused:0 state:ready LOCAL SERVER"D000" established:0 refused:0 current:0 max:10000 state:ready

DISPATCHER <machine: sales-server, pid: 11326>(ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=58361))

The command completed successfully

COMUNICACIONES



599


3.- Configurar el cliente para usar un nombre de serviciode red (“net service name”). El nombre de servicio sedefine durante la creación de la bd.

Se trata de un nombre para el servicio asociado a un descriptor de conexión. El cliente, para conectarse, indicará un nombre de usuario, una contraseña y una cadena de conexión o nombre de servicio (reside en el fichero tnsnames.ora-modificable manualmente, con NetManager, o con NetCAssistant-). Por ejemplo:

sales= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com)))



600


• El descriptor de conexión contiene:

– La ruta de red hacia la bd, incluyendo la localización del “listener” a través de un protocolo -sección ADDRESS-.

– Nombre de servicio (“service name”) - a partir de bd versión 8i o 9i-.

Puede indicarse una instancia con INSTANCE_NAME.

sales=(DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com)(INSTANCE_NAME=sales)))

COMUNICACIONES



601


• El método “easy connect naming” hace innecesaria la definición de servicios en tnsnames.ora, al permitir indicar directamente al cliente un puerto y nombre de servicio de conexión (Por defecto, el nombre de servicio usado es ORCL):

CONNECT username/password@[//]host[:port][/service_name]

• Por ejemplo: “CONNECT username/password@sales-server:1521/sales.us.acme.com”

Este cadena se convierte en el descriptor:

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=sales.us.acme.com)))

• Para conexiones URL o JDBC:

CONNECT username/password@[//][host][:port][/service_name]



602


4.- Conectar a bd.

• Desde el cliente:

– Arrancar SQL*Plus: sqlplus

– Conectar a bd:

CONNECT username/password@nombre_servicio_red

COMUNICACIONES



603

DATABASE LINK



604

DATABASE LINK.

• Es una conexión entre dos bbdd que permite acceder a ellas como una única bd; así como acceder de forma remota. Define una vía de comunicación unidireccional, en un solo sentido, cuya definición se almacena en diccionario de datos.

• Pueden ser públicos o privados.

• Generalmente tienen el mismo nombre que el “global database name” de la bd remota que referencia.

COMUNICACIONES



605

TEMA 7.

ARQUITECTURA “SHARED SERVER”.

SHARED SERVER. Administración y Ajuste de Oracle 10g


606

TEMA 7. SHARED SERVER.

• MANEJADORES DE SERVICIO.• SERVIDOR DEDICADO.• SERVIDOR COMPARTIDO. “DISPATCHER”.• VENTAJAS “SHARED SERVER”.• “DISPATCHER”.

– NUMERO DE “DISPATCHER”.– CONFIGURACION DE “DISPATCHER”.– PROCESOS SERVIDOR COMPARTIDOS.– AJUSTE DEL NUMERO “SHARED SERVER”.– OTROS PARAMETROS.– CONNECTION POOLING.– SERVICIOS Y “DISPATCHER”.– AJUSTE DEL NUMERO “DISPATCHERS”.– REDUCIR CONTENCION. “DISPATCHERS”.– “DISPATCHERS”. CLAUSULA INDEX.

SHARED SERVER.



607

TEMA 7. SHARED SERVER.

• VERIFICAR CONFIGURACION.• PARAR “DISPATCHERS”.• FORZAR CONFIGURACION. COMPARTIDA. DEDICADA.• DESHABILITAR MODO SERVIDOR COMPARTIDO.• VISTAS.



608

MANEJADORES DE SERVICIO.

• Para cada instancia existen unos “manejadores de servicio” o puntos de conexión a la bd.

• Estos pueden ser:

– Un servidor dedicado, o

– Un “dispatcher”, caso de servidor compartido.

SHARED SERVER.



609

MANEJADORES DE SERVICIO.

• El tipo de configuración se determinará en el servidor de bd.

• Respecto al cliente puede suceder que este desee usar un manejador de servicio particular, en este caso el tipo a utilizarse indicaría en el conector:

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=host)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=nombre_servicio)(SERVER=shared/dedicated)))

• Si no se indica el valor para el parámetro SERVER se asume por defecto la configuración “shared server”. Si no hay “dispatchers” disponibles, se usarán servidores dedicados.



610

SERVIDOR DEDICADO.

• El “listener” arranca un proceso dedicado exclusivo para cadapetición cliente, que permanece hasta la finalización de la misma.

• Pueden darse dos opciones (seleccionada en función del S.O. y el

protocolo):

– El servidor dedicado hereda la petición de conexión del “listener”.

– El servidor dedicado informa al “listener” sobre su dirección de escucha, esta se pasa al cliente. Se cierra la conexión con el “listener” y el cliente se conecta al servidordedicado directamente.

SHARED SERVER.



611

SERVIDOR DEDICADO.



612

SERVIDOR DEDICADO.

SHARED SERVER.



613

SERVIDOR DEDICADO.

• En ciertas situaciones es preciso conectar obligatoriamente usando servidores dedicados y ha de indicarse de forma explícita:

– Trabajos “batch” (en general aquellos en los que no es posible ningún tiempo de espera).

– Al usar Recovery Manager (RMAN) para hacer copias, restaurar o recuperar una bd.



614

SERVIDOR COMPARTIDO.

• La arquitectura de servidor compartido usa uno o variosprocesos “dispatcher” para redirigir las conexiones cliente a una cola de peticiones común. Un proceso servidor compartido desocupado extrae la petición de esta cola.

• Permite que un pequeño número de procesos servidor atienda un gran número de clientes, reduciendo así los recursos de sistema necesarios respecto a cuando se usan servidores dedicados. La configuración servidor compartido es recomendable cuando existan una gran número de conexiones puesto que reduce las necesidades de memoria.

• El proceso “listener” redirige las peticiones al “dispatcher”. Alllegar una petición, el “listener” la conduce al “dispatcher”, o indica al cliente la dirección de protocolo del “dispatcher” -elcliente termina la sesión con el “listener” y establece una con el “dispatcher”-.

SHARED SERVER.



615

SERVIDOR COMPARTIDO.



616

SERVIDOR COMPARTIDO: “DISPATCHER”.

SHARED SERVER.



617


SHARED SERVER.

• Un dispatcher admite múltiplesconexiones cliente a la vez. Cada una de ellas se asocia a un circuito virtual, una porción de memoria compartida usada por el dispatcher para las peticiones y respuestas a los clientes.



618


SHARED SERVER.

La configuración en servidorcompartido es compatible con otras soluciones aportadas por Oracle Net y conjuntamente permiten reducir la sobrecarga de los servidores de bd (como, por ejemplo, Oracle Connection Manager).



619

VENTAJAS “SHARED SERVER”.

• Permite maximizar el uso de los recursos del sistema y mejorar el rendimiento, incrementando el número de clientes que simultáneamente pueden estar conectados a la bd.

• Reduce el número de procesos que corren sobre la instancia.

• Incrementa el número de posibles usuarios.

• Disminuye el número de procesos servidor ociosos.

• Reduce el uso de memoria y la sobrecarga del sistema.

• La configuración en modo compartido resulta adecuada en sistemas con muchos usuarios OLTP realizando transacciones intermitentes o aquellos sistemas con una alta tasa de conexión a la bd (siempre hay un proceso “dispatcher” listo para gestionar la petición entrante).



620

“DISPATCHER”.

• El número de procesos “dispatcher” arrancados con la instancia se controla con el parámetro de inicialización DISPATCHERS. Este número depende de la bd, del límite impuesto por s.o., del número de conexiones para cada proceso y del número de conexiones requeridas para cada protocolo.

• Los procesos “dispatcher” y servidores compartidos pueden arrancarse además con la sentencia ALTER SYSTEM sin necesidad de rearrancar la instancia.

• Un “dispatcher” se crea automáticamente, para TCP/IP, cuando se elige el modo servidor compartido (SHARED_SERVERS mayor que 0) sin especificar el parámetro “dispatchers”, es equivalente a tener en el fichero de inicializacion:

dispatchers="(PROTOCOL=tcp)"

SHARED SERVER.



621

NUMERO DE “DISPATCHER”.

• Una vez conocido el número de posibles conexiones porproceso de s.o. puede calcularse el número inicial de “dispatchers” a crear en el arranque:

Número de “dispatchers” =CEIL ( nº máx. sesiones concurrentes / conexiones por

dispatcher )

• Es necesario tener en cuenta que tras arrancar la instancia pueden arrancarse más procesos si son necesarios. Configurardemasiados “dispatcher” puede afectar a la productividad de la bd.



622

CONFIGURACION DE “DISPATCHER”.

• Configuración Típica.

DISPATCHERS="(PROTOCOL=TCP) (DISPATCHERS=2)”DISPATCHERS=”(PROTOCOL=IPC) (DISPATCHERS=1)"

• Forzar los puertos usados.

DISPATCHERS="(ADDRESS=(PROTOCOL=TCP)(PORT=5000))"DISPATCHERS="(ADDRESS=(PROTOCOL=TCP)(PORT=5001))"

• Forzar las direcciones IP usadas (las direcciones IP deben ser direcciones válidas para el “host” donde está la instancia).

DISPATCHERS="(ADDRESS=(PROTOCOL=TCP)(HOST=144.25.16.201))(DISPATCHERS=2)"

SHARED SERVER.



623

PROCESOS SERVIDOR COMPARTIDOS.

• La configuración de servidor compartido se habilita asignando al parámetro de inicialización SHARED_SERVERS un valor mayor que cero o asignándole un valor con ALTER SYSTEM. No es necesario ajustar ningún otro parámetro.

• Como esta configuración requiere al menos un “dispatcher”, se crea uno. Por compatibilidad, si se incluye el parámetro DISPATCHERS y se le da un valor, se habilita SHARED_SERVERS -con un valor por defecto de 1-.

• El valor indicado por SHARED_SERVERS es el mínimo a crear cuando arranca la instancia, tras el arranque la gestión de su número es dinámica y la lleva a cabo Oracle

SHARED_SERVERS = <número>



624


• Si la carga del sistema decrece, se mantiene este mínimo por lo que no debe asignarse un valor demasiado alto.

• Tanto el número de DISPATCHERS como de SHARED_SERVERS pueden modificarse dinámicamente. Es necesario el privilegio ALTER SYSTEM.

SHARED SERVER.



625


• El número de “shared servers” en un momento determinadode la operación de la bd no puede fijarse -sólo el máximo y el mínimo son definibles-.

• Los “shared servers” se crean dinámicamente bajo el control automático de la arquitectura “shared server” de la instancia Oracle. Así, no se necesita ni se puede configurar el número de ellos en ningún momento.

• Conforme la carga se incrementa, por ejemplo al aumentar el número de consultas/DDLs/DMLs que los clientes ejecutan, la instancia Oracle incrementa el número de “shared servers”también -hasta el límite fijado por MAX_SHARED_SERVERS-.En el caso de que la carga descienda, los “shared servers” son eliminados automáticamente por la instancia.



626

AJUSTE DEL NUMERO “SHARED SERVER”.

• El incremento de tiempos de espera en las respuestas indica contención para los “shared servers”. La vista V$QUEUEcontiene estadísticas sobre la actividad de la cola de peticiones a los “shared servers” (vista accesible sólo a SYS y usuarios con el privilegio SELECT ANY TABLE como SYSTEM).

• En particular, la columna WAIT muestra el tiempo total de espera, en centésimas de segundo, para las peticiones que han estado en cola y TOTALQ muestra el número total de peticiones que han estado alguna vez en cola.

• Para monitorizar sus valores puede emplearse la sentencia:

SELECT DECODE(TOTALQ, 0, 'No Requests', WAIT/TOTALQ || ' CENTESIMAS SEGUNDO') "TIEMPO MEDIO DE ESPERA POR PETICION" FROM V$QUEUE WHERE TYPE = 'COMMON';

SHARED SERVER.



627

AJUSTE DEL NUMERO “SHARED SERVER”.

• También puede determinarse cuántos “shared servers” están ejecutándose en un instante:

SELECT COUNT(*) "PROCESOS SHARED SERVER” FROM V$SHARED_SERVER WHERE STATUS != 'QUIT';

• Si se detecta contención en los “shared servers”, debe en primer lugar comprobarse que no hay contención en memoria -examinando la “shared pool” y la “large pool”-. En última instancia podrían añadirse más recursos actuando sobre los parámetros:

MAX_DISPATCHERSMAX_SHARED_SERVERSDISPATCHERSSHARED_SERVERS



628

CAMBIAR NUMERO “SHARED SERVER”.

• Tras arrancar la instancia, puede modificarse el númeromínimo de procesos “shared server” mediante la sentencia ALTER SYSTEM. Oracle elimina los servidores desocupados cuando hay más que el límite mínimo especificado.

• Si SHARED_SERVERS es 0, Oracle elimina todos los servidores actuales cuando se desocupan y no arranca ninguno hasta que se incrementa el valor de “SHARED_SERVERS”.

• Por ejemplo, para fijar el mínimo de procesos “shared server”a cuatro:

ALTER SYSTEM SET SHARED_SERVERS = 4;

SHARED SERVER.



629

OTROS PARAMETROS.

• SHARED_SERVER_SESSIONS. Parámetro modificable conALTER SYSTEM que indica el número total de sesiones concurrentes de usuario permitidas en arquitectura “shared server”. Si se indica, su valor debe ser menor que SESSIONS.

• Parámetros que también pueden requerir ajuste son:

– LARGE_POOL_SIZE. Tamaño en bytes de la pila “large pool”, mínimo de 300k. Es modificable con ALTER SYSTEM.

– SESSIONS. Parámetro estático, especifica el número máximo de sesiones que es posible crear en el sistema; dado que cada conexión requiere una sesión, este parámetro determina el número máximo de usuarios concurrentes en la bd.



630

OTROS PARAMETROS.

• CIRCUITS. Parámetro modificable con ALTER SYSTEM que indica número total de circuitos virtuales disponibles para sesiones de red. Está relacionado con los requerimientos de SGA y no es necesario indicarlo a menos que se quiera limitar el número de circuitos.

Un circuito virtual es una porción de memoria compartidausada por el “dispatcher” para las conexiones cliente (peticiones/respuestas). El “dispatcher” coloca un circuito virtual en una cola común cuando llega una petición; un servidor compartido ocioso coge dicho circuito, sirve la petición, y enlaza el circuito antes de intentar recuperar otro.

SHARED SERVER.



631

OTROS PARAMETROS.

• MAX_DISPATCHERS (obsoleto). Parámetro modificable conALTER SYSTEM que indica el máximo número de procesos “dispatcher” permitidos a la vez. Su valor debe ser mayor o igual que el número de “dispachers” indicados por DISPATCHERS y menor que el número de procesos indicadospor PROCESSES. Se mantiene por compatibilidad con versiones anteriores.

• MAX_SHARED_SERVERS. Parámetro modificable con ALTER SYSTEM que indica el número máximo de procesos de servidorcompatido (“shared server”) simultáneos. Si ocurren con demasiada frecuencia “deadlocks”, debe incrementarse. Su valor debe ser mayor o igual que el número de “dispachers”indicados por SHARED_SERVERS y menor que el número deprocesos indicados por PROCESSES.



632

CONNECTION POOLING.

• Esta utilidad permite reducir el número de conexiones físicasde red a un “dispatcher” al compartir un conjunto de conexiones entre los procesos cliente.

• Se configura usando el atributo POOL del parámetro DISPATCHERS y los atributos opcionales CONNECTIONS(CON o CONN), SESSIONS (SES o SESS) y TICKS (TIC o TICK).

– CONNECTIONS ... Máximo número de conexiones de redpermitidas por “dispatcher”. Valor por defecto dependiente del s.o.

– TICKS ... Duración de “network tick” en segundos (por defecto 1). Es un “timeout” del Connection Pool.

– POOL ... Activa “Connection Pooling” (valores YES -activado-, NO -desactivado-, IN -conexiones entrantes- y OUT -conexiones salientes-). Por defecto no está activado.

– SESSIONS ... Número máximo de sesiones de red permitidas por “dispatcher” (valor por defecto dependente del s.o.).

SHARED SERVER.



633

CONNECTION POOLING.

• Suponiendo un sistema que puede soportar hasta 950 conexionespor proceso y que existen 4000 usuarios conectados al tiempo a través de SSL y 2500 sesiones concurrentes a través de TCP/IP con SSL, serían necesarios 5 “dispatchers” para TCP/IP y 3 más para TCP/IP con SSL:

DISPATCHERS="(PROTOCOL=tcp)(DISPATCHERS=5)"DISPATCHERS="(PROTOCOL=tcps)(DISPATCHERS=3)"

• Si los clientes están frecuentemente inactivos y un “dispatcher”puede gestionar 4000 sesiones TCP/IP o 2500 sesiones TCP/IP con SSL, podría optarse por la configuración:

DISPATCHERS="(PROTOCOL=tcp)(DISPATCHERS=1)(POOL=on)(TICK=1) (CONNECTIONS=950)(SESSIONS=4000)"

DISPATCHERS="(PROTOCOL=tcps)(DISPATCHERS=1)(POOL=on)(TICK=1) (CONNECTIONS=950)(SESSIONS=2500)"



634

SERVICIOS Y “DISPATCHER”.

• Dado que una bd puede estar representada por múltiples nombres de servicio, un conjunto de “dispatchers” pueden habilitarse para servir exclusivamente peticiones a un servicio particular (e incluso asignar mayores recursos a las mismas).

SERVICE_NAMES=CURSOxxINSTANCE_NAME=CURSOxxDISPATCHERS="(PROTOCOL=tcp)"DISPATCHERS="(PROTOCOL=tcp)(SERVICE=ADMINCURSO)"

• En el ejemplo anterior hay dos “dispatchers”, el primero sirve peticiones para clientes accediendo al servicio CURSOxx, el otro sólo para clientes accediendo al servicio “ADMINCURSO”.

SHARED SERVER.



635

AJUSTE DEL NUMERO “DISPATCHERS”.

• V$DISPATCHER proporciona información general sobre losprocesos “dispatcher”. V$DISPATCHER_RATE muestra estadísticas y contiene los valores actuales (prefijo CUR_),medios (prefijo AVG_) y máximos (prefijo MAX_).

• Es necesario comparar los valores actuales con los máximos, si aquellos se acercan a los valores medios (AVG_), están alejados de los máximos (MAX_) y el sistema proporciona una respuesta adecuada en tiempo el ajuste es el correcto.

• Si las tasas actuales y medias están alejadas de los máximos, habrá que reducir el número de “dispatchers”. Si aquellas están cerca de los máximos, se podrían añadir “dispatchers”.

• V$DISPATCHER_RATE debería examinarse durante periodos de carga máxima y mínima del sistema para obtenerinformación exhaustiva a partir de la cual realizar el ajuste.



636

REDUCIR CONTENCION. “DISPATCHERS”.

• Si se determina que la carga de los procesos “dispatcher” esbaja, debe reducirse el número de procesos. Si la carga es alta, puede mejorarse la productividad de varias formas:

– Habilitar “Connection Pooling”.

– Habiltar multiplexado (“Connection Manager”).

– Arrancar más procesos “dispatcher”. Para modificar elnúmero de procesos se usa la sentencia ALTER SYSTEM. Esimportante observar que su número NO varía dinámicamente. Cuando se reduce, puede hacerse hasta el número indicado en DISPATCHERS.

ALTER SYSTEMSET DISPATCHERS ='(PROTOCOL=TCP)(DISPATCHERS=5)','(PROTOCOL=TCPS)(DISPATCHERS=2)';

SHARED SERVER.



637

“DISPATCHERS”. CLAUSULA INDEX.

• INDEX. Este parámetro se usa en ALTER SYSTEM SETDISPATCHERS para indicar que “dispatcher” quiere modificarse (se ignora si se indica en el fichero de parámetros). Señala el orden en el que se inicializaron, su rango oscila entre 0 (el primer proceso “dispatcher”) a uno menos al número total de “dispatchers” definidos.

Por ejemplo, si se indican 3 “dispatchers” en el fichero de parametros, para modificar el tercero debe indicarse INDEX=2en la sentencia ALTER SYSTEM (consultar vistas v$dispatcher, observar la columna conf_indx, y v$dispatcher_config).

• Si en el fichero de inicialización se indica:

dispatchers = "(ADDRESS=(PROTOCOL=TCP) (host=host)(port=5100))"dispatchers = "(ADDRESS=(PROTOCOL=TCP) (host=host)(port=2480))"



638


• Ejecutando “lsnrctl services” (lsnrctl services listener_v9205):

Service "v9205" has 2 instance(s).Instance "v9205", status UNKNOWN, has 1 handler(s) for this service...Handler(s):"DEDICATED" established:0 refused:0LOCAL SERVERInstance "v9205", status READY, has 3 handler(s) for this service...Handler(s):"DEDICATED" established:0 refused:0 state:readyLOCAL SERVER"D001" established:0 refused:0 current:0 max:1002 state:readyDISPATCHER <machine: INDL040AD, pid: 840>(ADDRESS=(PROTOCOL=tcp)(HOST=indl040ad.idc.oracle.com)(PORT=2480))"D000" established:0 refused:0 current:0 max:1002 state:readyDISPATCHER <machine: INDL040AD, pid: 2280>(ADDRESS=(PROTOCOL=tcp)(HOST=indl040ad.idc.oracle.com)(PORT=5100))The command completed successfully

SHARED SERVER.



639


• Asignemos ahora el puerto 3500 al “dispatcher” D000's:

SQL> alter system shutdown immediate 'D000';System altered.

SQL> alter system set DISPATCHERS='(ADDRESS= PROTOCOL=TCP)(HOST=indl040ad)(PORT= 3500))(INDEX = 0)';System altered.

SQL> alter system register;System altered.

•Nota: Indicando REGISTER, el PMON registra la instancia con los “listeners” inmediatamente; en caso contrario los clientes pueden no acceder a los servicios temporalmente.•Nota: También podría añadirse un “dispatcher” con ALTER SYSTEM indicando INDEX=3.



640


• Ejecutando “lsnrctl services” de nuevo:

Service "v9205" has 2 instance(s).Instance "v9205", status UNKNOWN, has 1 handler(s) for this service...Handler(s):"DEDICATED" established:0 refused:0LOCAL SERVERInstance "v9205", status READY, has 3 handler(s) for this service...Handler(s):"DEDICATED" established:0 refused:0 state:readyLOCAL SERVER"D001" established:0 refused:0 current:0 max:1002 state:readyDISPATCHER <machine: INDL040AD, pid: 840>(ADDRESS=(PROTOCOL=tcp)(HOST=indl040ad.idc.oracle.com)(PORT=2480))"D000" established:0 refused:0 current:0 max:1002 state:readyDISPATCHER <machine: INDL040AD, pid: 2280>(ADDRESS=(PROTOCOL=tcp)(HOST=indl040ad.idc.oracle.com)(PORT=3500))The command completed successfully

SHARED SERVER.



641

VERIFICAR CONFIGURACION.

• Al usar “shared server”, debe arrancarse en primer lugar el “listener” y después la bd. Puede verificarse el estado del “dispatcher” ejecutando:

lsnrctl services

• Para verificar que las conexiones realizadas están usando servidores compartidos debe consultarse la vista V$CIRCUIT(habrá una entrada por cada conexión de servidor compartido).

Select dispatcher, circuit, server, status from v$circuit;



642

PARAR “DISPATCHERS”.

• Es posible parar procesos específicos al estar identificados por un nombre de la forma Dnnn -los procesos “background” correspondientes se identifican de la forma Dnnn-.

SELECT NAME, NETWORK FROM V$DISPATCHER;

NAME NETWORK-------------------------------------------------------------------------D000 (ADDRESS=(PROTOCOL=tcp)(HOST=host)(PORT=3499))D001 (ADDRESS=(PROTOCOL=tcp)(HOST=host)(PORT=3531))D002 (ADDRESS=(PROTOCOL=tcp)(HOST=host)(PORT=3532))

• Para parar el “dispatcher” D002:

ALTER SYSTEM SHUTDOWN IMMEDIATE 'D002';

SHARED SERVER.



643

PARAR “DISPATCHERS”.

• La claúsula IMMEDIATE permite parar el “dispatcher”, no aceptando nuevas conexiones y terminando inmediatamente las existentes. Posteriormente el proceso acaba.

Si no se indica IMMEDIATE, el proceso “dispatcher” espera hasta que todos sus usuarios se desconecten antes de finalizar.



644

FORZAR CONFIGURACION COMPARTIDA.

• Si está configurado “shared server” y llega una conexióncuando no hay “dispatcher” registrados, las peticiones pueden ser manejadas por un proceso servidor dedicado (configurado en listener.ora). Si se desea que un cierto cliente use siempre un “dispatcher”, debe indicarse (server=shared) en el descriptor de conexión. Si no hay un “dispatcher” disponible, se rechaza la conexión del cliente.

sales= (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=host)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=servicio) (SERVER=shared)))

SHARED SERVER.



645

FORZAR CONFIGURACION DEDICADA.

• En ciertas ocasiones, interesa que un cliente se conecte a una instancia usando un servidor dedicado -como al ejecutar un trabajo “batch”, o al usar Recovery Manager para copiar, recuperar o restaurar una bd-.

Debe hacerse una conexión mediante un servicio de red configurado como servidor dedicado:

– Bien el servicio contiene la clausula SERVER=DEDICATED.

sales= (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=host)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=servicio)(SERVER=dedicated)))



646

FORZAR CONFIGURACION DEDICADA.

– Bien el fichero sqlnet.ora del cliente debe contener la variable USE_DEDICATED_SERVER=on -añade (server=dedicated) a la sección CONNECT_DATA del descriptor que el cliente use, el valor es sobreescrito, incluso si está configurado el modo servidor compartido-.

SHARED SERVER.



647

FORZAR CONFIGURACION.

• La instancia Oracle sólo proporciona la forma de limitar el número total de sesiones que pueden establecerse, como un conjunto, pero no deja limitar de forma específica sesiones dedicadas o sesiones compartidas como tales.

• Para limitar el número total de sesiones que pueden establecerse, puede usarse el parámetro SESSIONS en el fichero de parámetros de inicialización.



648

DESHABILITAR MODO SERVIDOR COMPARTIDO.

• Puede hacerse asignando un valor cero a SHARED_SERVERS.Ningún cliente más se conecta, sin embargo Oracle retiene algunos servidores compartidos hasta que todas las conexiones en este modo se cierran (en cantidad igual al menor de los parámetros SHARED_SERVERS o MAX_SHARED_SERVERS).

• Si SHARED_SERVERS y MAX_SHARED_SERVERS son ambos puestos a cero, todos los servidores compartidos finalizan y las peticiones de clientes serán “encoladas” hasta que el valor de cualquiera de dichos parámetros se eleve de nuevo.

• Una vez todos los clientes hayan desconectado, para eliminar los “dispatchers” debe indicarse:

ALTER SYSTEM SET DISPATCHERS = '';

SHARED SERVER.



649

VISTAS.

• V$CIRCUIT ... Circuitos virtuales -conexiones de usuario a la bd a traves de “dispatchers” y servidores.

• V$DISPATCHER ... Información sobre los procesos “dispatcher” (nombre,estado, estadísticas,...).

• V$DISPATCHER_CONFIG ... Configuración de los procesos “dispatcher”.

• V$DISPATCHER_RATE ... Estadísticas para “dispatcher”.• V$QUEUE ... Información sobre las colas de mensaje de los

servidores compartidos.• V$SHARED_SERVER ... Información de procesos “shared-

server”.• V$SHARED_SERVER_MONITOR ... Información para ajuste

de “shared server”.• V$SGA ... Información sobre “system global area” (SGA).• V$SGASTAT ... Información estadística de la SGA.• V$SHARED_POOL_RESERVED



650

TEMA 8.

ARCHIVADO DE BASE DE DATOS.

ARCHIVADO DE BASE DE DATOS



651

TEMA 8. ARCHIVADO.

• MODOS DE FUNCIONAMIENTO DE LA BD.

• MODOS “NOARCHIVELOG” Y “ARCHIVELOG”.

• “REDO LOG” ARCHIVADO.

• INFORMACION DE ARCHIVADO.

• MODO DE ARCHIVADO INICIAL.

• CAMBIO A MODO “ARCHIVELOG”.

• ARCHIVELOG.

– ARCHIVADO MANUAL.

– DESTINO DE ARCHIVADO. FALLOS EN DESTINO.

– CONTROL DE PROCESOS ARCn.

ARCHIVADO DE BASE DE DATOS Administración y Ajuste de Oracle 10g


652

TEMA 8. ARCHIVADO.

• INFORMACION PROCESO ARCHIVADO.

• FLASH RECOVERY AREA Y ARCHIVELOG.

• CAMBIO A MODO “NOARCHIVELOG”.

• VISTAS.




653

MODOS DE FUNCIONAMIENTO DE BD.

• La bd puede funcionar en dos modos distintos: modo “noarchivelog” y modo “archivelog”.

• Ambos se distinguen por el manejo que se hace de los “redo log” en línea cuando se completa el llenado de un grupo y se produce el “log switch”.

• La elección de uno u otro modo depende de las exigencias en cuanto a disponibilidad y capacidad de recuperación necesarias en nuestra operación diaria de la bd. Si no se puede permitir la pérdida de datos en caso de fallo en disco o fichero y es necesaria una actividad continua de la bd, servicio 24x7, es aconsejable el funcionamiento en modo “archivelog”.



654

MODO “NOARCHIVELOG”.

• En este modo la bd está protegida contra el fallo deinstancia; pero si se produce un fallo en disco o en fichero, sólo puede recuperarse hasta la copia completa, y consistente, más reciente.

• Está desactivado el archivado de los “redo log” en línea. Cuando se completa el llenado de un grupo y se produce el “log switch”, este es reutilizado por el LGWR.

• Deben hacerse periódica y frecuentemente copias completas y coherentes de la bd (con la bd cerrada consistentemente).




655

MODO “ARCHIVELOG”.

• Se archivan los “redo log” en línea. Cuando se completael llenado de un grupo, este NO es reutilizado por el LGWR hasta que se archiva.

• Pueden usarse copias realizadas mientras la base de datos está abierta y en funcionamiento.

• Permite recuperar todas las transacciones validadas (“commit”) en caso de fallo en disco o de sistema operativo -se recupera la bd al momento actual-.

• Es aconsejable en el caso de no poder permitir ningún tipo de pérdida de datos.



656

MODO “ARCHIVELOG”.




657

“REDO LOG” ARCHIVADO.

• Se llama “redo log” archivado al conjunto de ficheros de “redo log” archivados, que son copia de ficheros pertenecientes a un grupo de “redo log” -escritos estos al completo y en línea- de la base de datos. Este conjunto de ficheros archivados se escribe en un destino fuera de línea.

• Al proceso de copia se le denomina proceso de archivado y se ocupa del mismo el proceso “archiver” (ARCn). Este proceso copia los ficheros de “redo log” a un dispositivo determinado tras cada “log switch”.

• El proceso “log writer” (LGWR) no puede reutilizar ni sobreescribir un grupo de “redo log” hasta que ha sido archivado.



658

“REDO LOG” ARCHIVADO.

• Una instancia puede tener hasta diez procesos ARCn (de ARC0a ARC9). EL proceso “log writer” (LGWR) arranca un nuevo proceso ARCn cuando el número de procesos de archivado es insuficiente, este hecho se registra en el fichero de alertas (alert).

• La copia incluye las entradas de “redo” del fichero en línea y mantiene el número de secuencia único de “log” del grupo.

• El proceso descrito sólo tiene lugar si la bd está en modoARCHIVELOG y el modo de archivado automático está activado.




659

INFORMACION DE ARCHIVADO.

• La orden de SQL*Plus ARCHIVE LOG LIST se emplea, entre otras cosas, para mostrar información de archivado para una determinada instancia.

– Modo de operación: ARCHIVELOG o NOARCHIVELOG.– Estado de archivado automático (habilitado o no).– Destino de archivado.– Número de secuencia para el más antiguo “redo log”

en línea lleno.– Idem para el próximo a archivar.– Idem para el actual.



660

MODO DE ARCHIVADO INICIAL.

• Indicado al crear la base de datos mediante la sentenciaCREATE DATABASE. Por defecto es NOARCHIVELOG.

CREATE DATABASE [database]{USER SYS IDENTIFIED BY ...|USER SYSTEM IDENTIFIED BY ...| CONTROLFILE REUSE| LOGFILE [GROUP integer] redo_log_file_spec [, [GROUP integer] redo_log_file_spec]...| MAXLOGFILES integer | MAXLOGMEMBERS integer| MAXLOGHISTORY integer | MAXDATAFILES integer| MAXINSTANCES integer | { ARCHIVELOG | NOARCHIVELOG }| FORCE LOGGING | CHARACTER SET charset| NATIONAL

CHARACTER SET charset| DATAFILE datafile_tempfile_spec [, datafile_tempfile_spec]...| default_temp_tablespace | undo_tablespace_clause| set_time_zone_clause }...;




661

CAMBIO A MODO “ARCHIVELOG”.

• Si no se ha establecido el modo ARCHIVELOG durante lacreación de la bd puede hacerse posteriormenteempleando la sentencia ALTER DATABASE. Es preciso estar conectado a la bd con privilegios de administrador.

• Pueden utilizarse las claúsulas NOARCHIVELOG yARCHIVELOG (es preciso que la bd esté montada pero no abierta y Real Application Clusters -RAC- deshabilitado).

• La claúsula ARCHIVELOG sólo puede usarse tras pararla instancia normalmente o de forma inmediata sin errores (de forma coherente).



662


– Parar la instancia de base de datos:» shutdown

– Realizar una copia de seguridad de la bd.– Modificar el fichero de parámetros de inicialización.– Arrancar una instancia y montar la bd:

» startup mount– Modificar el modo de archivado y abrir la bd:

» alter database archivelog;» alter database open;

– Comprobar el modo (archive log list;), archivar los “redo log” (archive log all;) y parar la instancia:

» shutdown immediate– Realizar una copia de seguridad de la bd en el nuevo

modo.




663


• El cambio de modo actualiza el fichero de control. Tras cambiarlo, debe realizarse una copia todos los ficheros de la base de datos.

• Cualquier copia anterior puede desecharse pues se ha realizado en modo NOARCHIVELOG (a menos que haya algún problema al cambiar a modo ARCHIVELOG y sea necesario volver al modo NOARCHIVELOG inicial).



664

ARCHIVELOG. ARCHIVADO MANUAL.

• Normalmente el archivado de “redo log” se realiza de forma automática, por mayor comodidad y seguridad.

• Si se desea archivar de forma manual, al cambiar a modo “archivelog”, en el paso donde se modifica el modo de archivado y se abre la bd, debe indicarse:

» alter database archivelog manual;» alter database open;.

• Si está activo el archivado manual debemos explícitamente archivar los “redo log” o la bd suspenderá su funcionamiento. No es conveniente trabajar de forma manual.




665

ARCHIVELOG. ARCHIVADO MANUAL.

• Para realizar el archivado manual es necesario estar conectado AS SYSDBA o tener el privilegio ALTER SYSTEM. La sentencia:

» alter system archive log all;

guarda todos los ficheros aún no archivados.

• Mediante alter system archive log current; se fuerza a cambiar de “log” y archivar el que se está usando así como el resto de no archivados (util para copias “online”). Esta sentencia puede usarse aun cuando se esté trabajando en modo automático de archivado.



666

ARCHIVELOG. DESTINO DE ARCHIVADO.

• Puede ser único o múltiple, en este caso se guardan en más de una localización.

• El parámetro de inicialización LOG_ARCHIVE_DEST_n-siendo n un entero entre 1 y 10- permite especificar hasta diez destinos de archivado. El caso más común es el archivado local -en la propia maquina-, lo que se indica:

LOG_ARCHIVE_DEST_1='LOCATION=/u06/oradata/CURSOxx'

• Es incompatible con el parámetro LOG_ARCHIVE_DEST (este parámetro junto con LOG_ARCHIVE_DUPLEX_DEST permite especificar un máximo de dos destinos de archivado).




667


• Para especificar el destino de archivado debe pararse la instancia de base de datos -shutdown- e:

– Indicar en fichero de parámetros destinos de archivado.

LOG_ARCHIVE_DEST_1 = 'LOCATION = /u06/oradata/CURSOxx'

LOG_ARCHIVE_DEST_2 = 'LOCATION = /u07/oradata/CURSOxx' ...

– Indicar el valor del parámetro LOG_ARCHIVE_FORMAT. Permite indicar el formato de nombre que se aplicará a los ficheros de archivado.



668


• El nombre de los archivados se compone de una cadena de caracteres combinada con variables:

– %s ... Número de secuencia de log.– %t ... Número de “thread”.– %a ... Identificación de activación.– %d ... Identificación de bd.– %r ... Identificación de “resetlog” (permite asegurar

nombres únicos para los ficheros de archivado a través de múltiples “encarnaciones” de la bd, estas cambian al abrir la bd con la opción “resetlogs”).

• Si se emplean mayúsculas (por ejemplo, %S o %T) el valor pasa a ser de longitud fija y se completa con ceros a la izquierda. Un ejemplo de nombre puede ser: LOG_ARCHIVE_FORMAT = "LOG%t_%s_%r.ARC"




669


• Los valores de dichos parámetros pueden encontrarse en:

– Número de secuencia de log (%s ): Vista V$ARCHIVED_LOG, columna SEQUENCE#

– Número de “thread” (%t). Vista V$ARCHIVED_LOG, columna THREAD#

– Identificación de activación (%a). Es el número asignado a la instancia de bd. Vista V$DATABASE, columna ACTIVATION#

– Identificación de bd (%d). Vista V$DATABASE, columna DBID

– Identificación de “resetlog” (%r). Vista V$ARCHIVED_LOG, columna RESETLOGS_ID



670


• La ruta completa de localización se forma concatenandoambas variables (LOG_ARCHIVE_DEST_n yLOG_ARCHIVE_FORMAT). Así, según el ejemplo anterior se generan ficheros de la forma:

/u06/oradata/CURSOxx/LOGxxx_yyy_zzz.ARC/u07/oradata/CURSOxx/LOGxxx_yyy_zzz.ARC

• Cada destino tiene una serie de características que determinan su estado (ver vista v$ARCHIVE_DEST):

– Valid/Invalid ... destino especificado y validez– Enabled/Disabled ... estado de disponibilidad y usabilidad

(por defecto un destino tiene valor “enabled”).– Active/Inactive ... si hay problemas accediendo al destino




671


• Mediante el fichero de parámetros de inicialización LOG_ARCHIVE_DEST_STATE_n, parámetro dinámicomodificable con ALTER SESSION o ALTER SYSTEM, es posible controlar el estado de un determinado destino de archivado:

– Enabled (por defecto). Destino válido y que puede usarse.

– Defer. Destino excluido temporalmente hasta que sea habilitado.

– Alternate. No habilitado pero puede llegar a estarlo si el resto de destinos fallan.



672

ARCHIVELOG. FALLOS DESTINO ARCHIVADO.

• Mediante LOG_ARCHIVE_MIN_SUCCEED_DEST=n(modificable dinámicamente con ALTER SESSION oALTER SYSTEM) se determina el mínimo número de destinos de archivado a los que debe poder escribirse satisfactoriamente antes de reutilizar el “redo log” en línea. Su valor por defecto es 1.

• Con LOG_ARCHIVE_DEST_n (modificable dinámicamente) puede indicarse si un destino tiene como atributo OPTIONAL -el archivado no se requiere para poder usar el “redo log”-, por-, valor por defecto, o MANDATORY -el archivado debe tener éxito antes de poder reutilizar el “redo log”-.




673

ARCHIVELOG. FALLOS DESTINO ARCHIVADO.

• Con LOG_ARCHIVE_DEST_n puede especificarse el mínimo número de segundos antes de que el proceso ARCn intente acceder a un destino que ha fallado (opción REOPEN). El valor por defecto es de 300 segundos; con un valor de cero, ARCn no intentará reescribir tras un fallo. Si no se indica REOPEN, ARCn nunca intentará escribir tras un error.

• Si se indica REOPEN con un destino de tipo OPTIONAL, la bd puede sobreescribir los “redo” en línea si hay un error. Si se indica para un destino tipo MANDATORY y no puede archivarse puede verse perjudicado el funcionamiento de la bd (en este caso, deberá archivarse manualmente, cambiar el destino -DEFER, OPTIONAL, ...- o definirlo como OPTIONAL).



674

ARCHIVELOG. CONTROL DE PROCESOS ARCn.

• Los procesos de archivado (ARCn) son creados conforme se necesitan.

• Puede indicarse el número de procesos creados en el arranque de la instancia (ARC0 a ARC9), añadiendo en el fichero de parámetros:

LOG_ARCHIVE_MAX_PROCESSES=<numero>;

• No pudiendose crear más de los indicados. Su valor por defecto es 2.

• Generalmente no es necesario indicar nada pues la bd arranca tantos procesos ARCn como sean necesarios para asegurar un correcto funcionamiento.




675


• Este parámetro puede modificarse dinámicamente conla sentencia (la bd debe estar montada pero no abierta):

ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=<numero>;

• Cada proceso ARCn trabaja sólo con un “log” inactivo cada vez, pero debe escribir a cada unos de los destinos indicados.



676





677

INFORMACION PROCESO ARCHIVADO.

• La información qe se genera y guarda en los ficheros detraza sobre el archivado puede controlarse mediante el parámetro -modificable con ALTER SYSTEM- LOG_ARCHIVE_TRACE. Valores válidos para el nivelde traza son:

– 0: Disable archivelog tracing (valor por defecto) – 1: Track archival of redo log file – 2: Track archival status of each archivelog destination – 4: Track archival operational phase – 8: Track archivelog destination activity – 16: Track detailed archivelog destination activity – 32: Track archivelog destination parameter modifications – 64: Track ARCn process state activity – 128: Track FAL (fetch archived log) server related

activities ARCHIVADO DE BASE DE DATOS Administración y Ajuste de Oracle 10g


678


– 32: Track archivelog destination parameter modifications– 64: Track ARCn process state activity– 128: Track FAL (fetch archived log) server related

activities– 256: Track RFS Logical Client– 512: Track LGWR redo shipping network activity– 1024: Track RFS Physical Client– 2048: Track RFS/ARCn Ping Heartbeat– 4096: Track Real Time Apply– 8192: Track Redo Apply (Media Recovery or Physical

Standby)

• Pueden combinarse distintos niveles indicando un valor resultado de la suma de dos de ellos (por ejemplo, el valor 3 hace referencia a 1 y a 2).

• Al fijar el valor por defecto, cero, Oracle continuará generando entradas en el fichero de “alert” y trazas en respuesta a condiciones de error.




679


• Aun cuando se fije el valor por defecto, cero, Oraclecontinuará generando entradas en el fichero de “alert” y trazas en respuesta a condiciones de error.



680

FLASH RECOVERY AREA.

• Lugar centralizado para ficheros de copia y recuperación(directorio gestionado por Oracle, sistema de ficheros o disco “automatic storage management”) tales como “redo”archivado, RMAN, ...

• La bd sería recuperable usando los ficheros almacenados en el área “flash” (ficheros de control, “redo” en línea, “redo”archivado, “flashback”, copias de ficheros de datos, ...).

• Se define una cantidad de espacio que puede Oracle usar en la “flash recovery area”. Oracle and RMAN escriben en el área hasta alcanzar el límite; al llegar al mismo, Oracle elimina el mínimo conjunto de ficheros existente que sean obsoletos, copias redundantes o volcados a otro dispositivo.




681


• Se recomienda que el área de “flash recovery” sea la suma deltamaño de la bd, del tamaño de las copias incrementales y el tamaño de todos los archivados no copiados a otro dispositivo de seguridad. Su tamaño mínimo debe ser al menos suficiente para contener los archivados no copiados a un dispositivo de seguridad.

• El área de “flash” se define con los parámetros de inicialización:

– DB_RECOVERY_FILE_DEST_SIZE ... Cantidad máximatotal, en bytes, del área (este parámetro debe indicarse antes de DB_RECOVERY_FILE_DEST).

– DB_RECOVERY_FILE_DEST ... Localización (directorio,sistema de ficheros o disco “automatic storage management-ASM-), NO puede ser sistema de ficheros “raw”.



682

FLASH RECOVERY AREA Y ARCHIVELOG.

• Es recomendable usar el área “Flash Recovery” para almacenar los archivados. Pueden darse varios casos, de más a menos recomendable:

– Sólo realizar el archivado en el área de “flash recovery” y usar discos espejo para copiar redundantemente los archivados.

– Realizar el archivado en el área de “flash recovery” y fijar otros destinos de archivado (LOG_ARCHIVE_DEST_n) externos al área.

– No usar el área “flash recovery” para archivar.




683

FLASH RECOVERY AREA Y ARCHIVELOG.

• Si se configura un área de “flash” y no se indican destinos de archivado (LOG_ARCHIVE_DEST_n), entonces LOG_ARCHIVE_DEST_10 implícitamente apunta al área (a menos que se le asigne la cadena vacía).

• Si se asigna alguna localización para LOG_ARCHIVE_DEST_n, los archivados se almacenan sólo en la misma y no en el área de “flash”. Si esta está configurada es necesario indicar explicitamente el área como uno de los destinos

LOG_ARCHIVE_DEST_1 = 'LOCATION=<USE_DB_RECOVERY_FILE_DEST>'

• Los nombres de fichero para los archivados en el área de “flash” no vienen determinados por LOG_ARCHIVE_FORMAT y son Oracle Managed Filenames.



684

CAMBIO A MODO “NOARCHIVELOG”.

– Parar la instancia de base de datos:» shutdown

– Realizar una copia de seguridad de la bd.– Modificar el fichero de parámetros de inicialización.– Arrancar una instancia y montar la bd:

» startup mount– Modificar el modo de archivado:

» alter database noarchivelog;» alter database open;

– Comprobar el modo (archive log list) y parar la instancia:» shutdown immediate

– Realizar una copia de seguridad de la bd.




685

VISTAS.

• V$DATABASE. Consulta del modo de la bd ARCHIVELOGo NOARCHIVELOG.

• V$ARCHIVED_LOG. Información histórica sobre archivado a partir del fichero de control.

• V$ARCHIVE_DEST. Información sobre destino de archivado.

• V$ARCHIVE_PROCESSES. Información sobre el estado de los procesos de archivado.

• V$BACKUP_REDOLOG. Información sobre “backups” de los “logs” archivados.

• V$LOG. Información sobre grupos de “redo” en línea - indica también cual necesita archivarse-.

• V$LOG_HISTORY. Información histórica de “log”.



686

TEMA 9.


COPIAS DE SEGURIDAD



687

TEMA 9. COPIAS DE SEGURIDAD.

• COPIA Y RECUPERACION: METODOS.• COPIAS FISICAS/LOGICAS.• ESTRATEGIAS DE COPIA. CONSIDERACIONES.• FLASH RECOVERY AREA. ARCHIVADO.• COPIAS COMPLETAS/PARCIALES.

• ESTRATEGIA MANUAL DE COPIA.– OBTENCION DE INFORMACION DE COPIA.– COPIA COMPLETA BD. PROCESO.– COPIA TBSP FUERA LINEA. PROCESO.– COPIA TBSP LECTURA/ESCRITURA EN LINEA. PROCESO.– COPIA TBSP LECTURA/ESCRITURA EN LINEA. PROBLEMAS EN LA

COPIA.– COPIA TBSP SOLO LECTURA EN LINEA. PROCESO.– COPIA FICHERO CONTROL.– COPIA “REDO” ARCHIVADO.



688

TEMA 9. COPIAS DE SEGURIDAD.

– COPIA OTROS FICHEROS.– COPIA MODO “SUSPEND”.

• RESTAURACION DE COPIAS.• DBVERIFY. VALIDACION FICHEROS Y SEGMENTOS.

• FLASHBACK DATABASE– PUNTOS RESTAURACION.– ACTIVAR FLASHBACK DATABASE.– VENTANA FLASHBACK DATABASE.– MONITORIZACION FLASHBACK DB

• COPIA LÓGICA. DATA PUMP EXPORT/IMPORT.

• “TABLESPACES” TRANSPORTABLES.– LIMITACIONES.– COMPATIBILIDAD.– PROCESO.

COPIAS DE SEGURIDAD



689

COPIA Y RECUPERACION: METODOS.

• Para realizar la copia y recuperación físicas Oracle proporcionados soluciones:

– Recovery Manager, una herramienta propia de Oracle que puede gestionarse a través de un interfaz línea de comandos o gráfica.

– Copia y recuperación gestionada por usuario, que emplea una mezcla de órdenes de s.o. y SQL*Plus.

• Se recomienda usar Recovery Manager al poderse realizar los mismos tipos de copias y recuperaciones que manualmente, además de proporcionar un interfaz estándar sobre distintos sistemas operativos.



690

COPIA Y RECUPERACION: METODOS.

• No obstante, los métodos manuales también son útiles y diferentes circunstancias pueden justificar el uso de los mismos:

– Migración de bd a una versión actualizada pero conservando aún los “script” de copia actuales.

– Coexistencia de bbdd tipo Oracle7 junto a otras más recientes, y la necesidad de coherencia en el manejo de todas ellas (RMAN sólo soporta bd versión 8.0 o superior). Algo que debería ser inusual actualmente.

– Pérdida de las copias realizadas con RMAN, y necesidad de restaurar copias manuales y recuperar con la orden SQL*Plus RECOVER.

Nota: La exposición estará basada en el empleo de métodos manuales de copia y recuperación.

COPIAS DE SEGURIDAD



691

COPIAS FISICAS/LOGICAS.

• Debe permitir, en caso de pérdida de los datos originales, recuperarlos.

• Pueden clasificarse en:

– Físicas. Copias de los ficheros que integran la bd, ficheros de control y ficheros “archive log” hechas con utilidades del gestor de bd -Recovery Manager, RMAN- o del s.o..

– Lógicas. Exportación a fichero binario mediante las utilidades de exportación (DATA PUMP EXPORT o EXPORT).

La copia física es la base del sistema de copia y recuperación, aunque ambas son complementarias.



692

ESTRATEGIAS DE COPIA. CONSIDERACIONES.

• Frente a errores de usuario.

– Flashback Database. Permite devolver la bd al completo a un estado anterior sin necesidad de restaurar, tomando como referncia un SCN o creando los puntos de restauración, “restore points”, necesarios. Debe estar configurada una “flash recovery area”.

– Recuperación de la bd “Point-in-Time”. Se recupera un tbsp. o la bd al completo a un momento concreto.

– Importación desde copia lógica.

• Frente a fallos de máquina (“media failure”).

– El tipo de fallo (fallo físico, sobreescritura, borrado o corrupción de un fichero de bd, ...) determina la técnica de recuperación a usar.

RECUPERACION



693

ESTRATEGIAS DE COPIA. CONSIDERACIONES.

• Ciertamente, es necesario, además de disponer de un plan decopia y recuperación, anticiparse a posible problemas.

• Un aspecto básico es tener múltiples copias de los ficheros de “redo” en línea así como de los ficheros de control y del “redo”archivado y que estas copias residan cada una en un disco físico diferente.

– Si un fallo daña una de las copias de “redo” en línea, la bd puede continuar sin interrupción. Si no se dispone de copias y se daña el “redo”, ña bd se detiene y pueden perderse datos.

– Si se daña cualquier fichero de control, esté o no multiplexado, la bd se detiene cuando se intenta leer o escribir en dicho fichero.



694

ESTRATEGIAS DE COPIA. CONSIDERACIONES.• Es necesario anotar la configuración “hw” y “sw” del servidor.

– Nombre, fabrica y modelo de la máquina donde reside la bd.– Versión del s.o.– Número de discos y controladoras– Capacidad de disco y espacio libre.– Nombre de todos los ficheros de datos.– Nombre y versión del sw de gestión de almacenamiento.– Nombre de la instancia (SID).– Identificador de la bd (DBID).– Versión y parche del servidor Oracle.– Versión y parche del sw de comunicaciones.– Método y frecuencia de las copias así como de la recuperación

COPIAS DE SEGURIDAD



695

ESTRATEGIAS DE COPIA. CONSIDERACIONES.• Conjunto de Redundancia.

Está integrado por los ficheros necesarios para recuperar la bd: Copia del fichero de control y de todos los ficheros de datos (“datafiles”), “redo log” archivado, duplicado de los “redo log” en línea y del fichero de control actual y ficheros de configuración (fichero de parámetros, tnsnames.ora y listener.ora). El conjunto de redundancia debe estar en discos distintos de aquellos que contienen ficheros de datos, “redo”en línea y ficheros de control. También se aconseja mantenerdistintas copias del conjunto.

• Es aconsejable hacer copias espejo del fichero de control. Es necesario que todas las copias del fichero de control estén accesibles o caería la instancia.



696

ESTRATEGIAS DE COPIA. CONSIDERACIONES.• Hacer copias espejo de los fiheros de datos si es posible para

evitar la realización de “media recovery” debido a un fallo de disco.

• Copia en modo ARCHIVELOG.

– Disponer de múltiples destinos de archivado (entre ellos puede figurar la “flash recovery area”).

– Copiar la bd al completo tras su creación o paso a modo ARCHIVELOG.

– Realizar copias de los tbsp con la bd abierta o cerrada. En particular de aquellos de uso intensivo deben hacerse copias frecuentes (para reducir el tiempo de recuperación).

– Copiar el fichero de control cada vez que se realice un cambio estructural en la bd (“ALTER DATABASE BACKUP CONTROLFILE”).

– Copiar los “redo log” archivados frecuentemente. Es conveniente realizar copias a varios soportes (cinta, disco, ...).

COPIAS DE SEGURIDAD



697

ESTRATEGIAS DE COPIA. CONSIDERACIONES.• Realizar copias de manera frecuente y regular (más frecuencia

a mayor número de operaciones DML).

• Realizar copias antes y después de cambios en la estructura de la bd (creado/borrado de tbsp, adición/renombrado de fichero de datos, adición, renombrado o borrado de “redo log”en línea, ...).

• Realizar copia después de operaciones con la opción NOLOGGING, creación de tablas e índices, puesto que la bd no genera “redo” para dichos objetos y no podrían recuperarse desde las copias existentes.

• Realizar copia completa después de abrir la bd con la opción RESETLOGS.

• Guardar las copias antiguas de la bd.



698

ESTRATEGIAS DE COPIA. CONSIDERACIONES.• Realizar copias lógicas de la bd, como complemento a las

copias físicas, puesto que no son sustitutivos de las mismas.

• Evitar la copia de “redo log” en línea pues accidentalmente pueden ser restaurados y corromper la bd.

– La mejor forma de protegerlos es tener múltiples miembros en cada grupo, y en diferentes discos.

– Si la bd está en modo ARCHIVELOG, el proceso ARC guarda los “redo” que se han llenado. Si la bd está en modo NOARCHIVELOG, el único tipo de copias válido es el realizado con la bd cerrada, consistente y completo; los ficheros en este tipo de copia son todos consistentes y no necesitan recuperación ni, por tanto, los “redo” en línea.

– Pueden restaurarse, por error, copias de los “redo log” en línea y corromper la bd.

COPIAS DE SEGURIDAD



699COPIAS DE SEGURIDAD

FLASH RECOVERY AREA



700


• Se trata de un lugar en disco donde la bd puede crear ygestionar fciheros relacionados con copia y recuperación. Debe determinarse su localización (directorio o grupo de discos ASM -Automatic Storage Management-) y una cuota de espacio, cantidad de espacio máximo a usar, para la misma (para averiguar la cuota de disco y uso de disco del área flash debe consultarse V$RECOVERY_FILE_DEST).

• Este área debe estar separada de aquel lugar donde residan los ficheros de la estructura de la bd (ficheros de datos, de control y “redo” en línea). El área “flash” está relacionada con OMF -Oracle Managed Files- y ASM -Automatic Storage Management-.

• Para habilitar el área “flash” debe darse valor a los parámetros de inicialización DB_RECOVERY_FILE_DEST_SIZE (cuota de disco) yDB_RECOVERY_FILE_DEST (localización).

COPIAS DE SEGURIDAD



701


• Las vistas V$RECOVERY_FILE_DEST yV$FLASH_RECOVERY_AREA_USAGE ayudan a determinarsi se ha reservado suficiente espacio para el área “flash”.

• V$RECOVERY_FILE_DEST permite averiguar la localización, cuota, espacio en uso y espacio recuperable mediante el borrado de ficheros y número de ficheros en el área “flash”.

SQL> SELECT * FROM V$RECOVERY_FILE_DEST;

• V$FLASH_RECOVERY_AREA_USAGE permite averiguar elporcentaje de disco usado por los diferentes tipos de ficheros y espacio recuperable mediante el borrado de ficheros obsoletos, redundantes o ya almacenados en otro soporte.

SQL> SELECT * FROM V$FLASH_RECOVERY_AREA_USAGE;



702

FLASH RECOVERY AREA. ARCHIVADO.

• Por defecto, LOG_ARCHIVE_DEST_10 señala al área “flash”. Los nombres generados para el “log” archivado no siguen la pauta fijada por LOG_ARCHIVE_FORMAT.

• También puede indicarse que cualquier otro destino de archivado señala dicha área:

LOG_ARCHIVE_DEST_1 = 'LOCATION=/...'LOG_ARCHIVE_DEST_2 =

'LOCATION=USE_DB_RECOVERY_FILE_DEST'

COPIAS DE SEGURIDAD




TIPOLOGIA DE COPIAS



704

COPIAS COMPLETAS/PARCIALES.

• Completas. Incluyen ficheros de control y de datos. Es independiente del modo de operación de la bd.

COPIAS DE SEGURIDAD



705


• Una copia completa puede ser:

– Consistente. Puede abrirse con la opción RESETLOGS sinrealizar “media recovery”, o sea, sin aplicar “redo” a los ficheros de datos. Todos los ficheros de datos deben:

• Tener el mismo “system change number” (SCN) en sus cabeceras, a menos que los tbsp correspondientes esten en sólo lectura u “offline normal”.

• No contienen cambios tras el SCN.• Concuerdan con la información de “checkpoint” almacenada en

el fichero de control.

Nota: Un "system change number" (SCN) es una marca de tiempo, "timestamp", interna para una versión validada de la bd. La bd emplea elvalor de reloj SCN para garantizar la consistencia de las transacciones. Porejemplo, cuando un usuario valida una transacción, Oracle graba un SCNpara esta validación en el "redo log" en línea.Oracle también emplea SCNs para coordinar transacciones distribuidas entre distintas bbdd



706


Sólo pueden efectuarse copias consistentes tras un“shutdown” limpio de la bd, esta no debe abrirse hastafinalizar la misma.Una copia completa y consistente es la única opción válidapara bd en modo NOARCHIVELOG.

– Inconsistente. Copia donde algun fichero contiene cambios hechos después del “checkpoint” de los ficheros. Necesita recuperación antes de ser consistente.Normalmente se hacen con la bd abierta mientras se

realiza la copia. Pero también si la copia se hace sobre una bd cerrada justo después de caer una instancia o de cerrarla bd con SHUTDOWN ABORT.

Sólo son válidos si la bd está en modo archivelog.

COPIAS DE SEGURIDAD



707


• Parciales.

– Copias de los ficheros de un “tablespace”. Sólo son válidos si la bd está en modo archivelog (en modo noarchivelog sólo cuando está en modo sólo lectura u “offline normal”).

Pueden hacerse con RMAN o mediante el s.o..– Copia de un fichero de datos. Válido en modo archivelog (en modo noarchivelog cuando está en modo sólo lectura u “offline normal”, o cuando todo fichero de un tbsp. se copia). Pueden hacerse con RMAN o mediante el s.o..– Copia de fichero de control. Mediante RMAN, o la sentencia “alter database backup controlfile” -a binario-.– Copias de “redo log” archivados. Fundamentales para recuperar una copia inconsistente. Deben copiarse todos los producidos durante una copia inconsistente.



708


– Durante las copias realizadas en línea pueden producirseinconsistencias en los datos que se intenta copiar (porejemplo, la lectura de bloques fracturados -con datos antiguos y nuevos al estar modificándose-).

– Para evitarlo, el tbsp. debe ponerse en modo “backup” con la sentencia “alter tablespace begin backup” (no puede indicarse para un tbsp de sólo lectura ni un tbsp temporal gestionado localmente). Mientras dura la copia no puedeponerse fuera de línea, parar la instancia o comenzar otra copia del tbsp.

– Mediante “alter tablespace end backup” se indica que la copia del tbsp. ha acabado. Se recomienda usarla tan pronto como sea posible, pues si sucede un fallo de instancia o “shutdown abort”, Oracle piensa que se necesita “media recovery” en el siguiente arranque (quizá con “redo log” archivado).

COPIAS DE SEGURIDAD




ESTRATEGIA MANUAL DE COPIA



710

ESTRATEGIA MANUAL DE COPIA.

• Se realizan copias periódicas de los ficheros de datos y “redo” archivado usando órdenes de s.o.. Es necesario relacionar las copias realizadas con los originales (por ejemplo, adoptando nombres derivados del original.

cp <nombre_fichero> <nombre_fichero.fecha>Ficheros de datos

ActuaciónObjeto

F.“redo” archivado cp <nombre_fichero> <nombre_fichero.fecha>

F. control alter database backup controlfile to <nombre_fichero>

F. parámetros create pfile= <init.ora.fecha> from spfile;

F. red cp tnsnames.ora tnsnames.ora.fecha

COPIAS DE SEGURIDAD



711

OBTENCION DE INFORMACION DE COPIA.

• Identificar los ficheros a copiar.

– Se consultan las vistas V$DATAFILE -ficheros de datos-, V$TABLESPACES -tbsp-, V$LOGFILE -”redo” en línea- yV$CONTROLFILE -f.control-. Al hacer copia de un fichero de control con “ALTER DATABASE BACKUPCONTROLFILE TO <fichero>;” debe guardarse información sobre los f.datos y f.redo en línea existentes junto con la copia del fichero de control (la estructura de labd en el momento de hacer la copia puede ser distinta a la existente en el momento de recuperar).

• Determinar el estado de copia (vista V$BACKUP).

– Muestra si un f.datos en línea forma parte de una copia actual – el valor ACTIVE de la columna “status” indica en copia- (útil con bd abierta y con f.control no recuperado ni nuevo -en este caso, contendría información desactualizada-).



712

OBTENCION DE INFORMACION DE COPIA.

• La vista V$BACKUP es útil con la bd abierta y también tras un fallo de instancia pues muestra el estado de copia de los ficheros en el instante del fallo y permite determinar si algún tbsp. ha quedado en modo copia.

SQL> SELECT t.name AS "TBSP", d.file# as "DF#", d.name AS "DF_NAME", b.status FROM V$DATAFILE d, V$TABLESPACE t, V$BACKUP b WHERE d.TS#=t.TS# AND b.FILE#=d.FILE# AND b.STATUS='ACTIVE';

COPIAS DE SEGURIDAD



713

COPIA COMPLETA BD.

• Es posible realizarla tras cerrar la bd, “shutdown”, con las opciones: Normal, immediate o transactional.

• Puede realizarse en modo archivelog o noarchivelog.

• Puede restaurarse sin hacer recuperación (en modo “archivelog” puede recuperarse posteriormente para llevar la bd a un momento más actual).

• En modo archivelog se recomienda hacer copia del f.control con:

ALTER DATABASE BACKUP CONTROLFILE TO <fichero>;



714

COPIA COMPLETA BD. PROCESO.

• Cerrar la bd.

SQL> SHUTDOWN NORMAL / IMMEDIATE / TRANSACTIONAL

No debería realizarse copia de la bd si ha sido parada de forma anormal (“shutdown abort” o caída debido a un fallo).

• Copiar los ficheros apropiados (datos, control, inicialización, configuración -buscar todos los ficheros .ora comenzando por el $ORACLE_HOME-, ...).

• Rearrancar la bd.

SQL> STARTUP

COPIAS DE SEGURIDAD



715

COPIA TBSP FUERA LINEA.

• Puede realizarse la copia de todos o parte de los f.datos queintegran un tbsp cuando está fuera de línea (para ponerlo fuera de línea debe tenerse el privilegio DBA o MANAGETABLESPACE).

• No puede ponerse fuera de línea el tbsp SYSTEM o un tbsp con segmentos de “rollback” activos.

• Si el tbsp fuera de línea contiene índices al intentar acceder a estos se generan errores. El problema se pondrá de manifiesto cuando el método de acceso elegido por el optimizadorrequiera usar los índices.



716

COPIA TBSP FUERA LINEA. PROCESO.

● Identificar los ficheros de datos correspondientes a los tbsp acopiar (DBA_DATA_FILES).

SQL> SELECT TABLESPACE_NAME, FILE_NAMEFROM SYS.DBA_DATA_FILESWHERE TABLESPACE_NAME = '...';

● Poner el tbsp fuera de línea con prioridad normal (ALTERTABLESPACE <nombre_tbsp> OFFLINE NORMAL;).

● Realizar copia de los f.datos (cp).

● Poner el tbsp en línea (ALTER TABLESPACE <nombre_tbsp>ONLINE;).

● Forzar el archivado de “redo”, de forma que aquel necesario para recuperar la copia del tbsp esté disponible (ALTERSYSTEM ARCHIVE LOG CURRENT;).

COPIAS DE SEGURIDAD



717

COPIA TBSP LECTURA/ESCRITURA EN LINEA. PROCESO.• Cualquier tbsp a copiar debe ser puesto en modo copia

(“backup mode”) mediante la sentencia ALTER TABLESPACE... BEGIN BACKUP. Tras la copia, debe abandonarse el modo copia con ALTER TABLESPACE ... END BACKUP o ALTER DATABASE END BACKUP. Al recuperar la bd se preguntará por los ficheros de “redo” necesarios para aplicar.

• Identificar los f.datos que pertenecen al tbsp.

SQL> SELECT TABLESPACE_NAME, FILE_NAMEFROM SYS.DBA_DATA_FILESWHERE TABLESPACE_NAME = '...';

• Indicar el comienzo de copia:

SQL> ALTER TABLESPACE <NOMBRE_TBSP> BEGIN BACKUP;



718

COPIA TBSP LECTURA/ESCRITURA EN LINEA. PROCESO.• Realizar la copia (cp).

• Indicar fin de copia:

SQL> ALTER TABLESPACE <NOMBRE_TBSP> END BACKUP;

• Forzar el archivado de “redo”, de forma que aquel necesario para recuperar la copia esté disponible:

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

COPIAS DE SEGURIDAD



719

COPIA TBSP LECTURA/ESCRITURA EN LINEA.

Si el proceso de copia involucra a varios tbsp, pueden copiarse de forma paralela o en serie (en ambos casos se fuerza el archivado al final del proceso, cuando sobre todos los tbsp se haya hecho el “end backup”). Es necesario tener en cuenta que hacerlo de forma paralela puede hacer que se generan grandes cantidades de “redo” si hay gran actividad en los tbsp. involucrados y debería existir “redo” suficiente.

● Paralela.

Se ponen simultáneamente todos los tbsp en modo “begin backup” -implica un gran crecimiento de “redo” en línea al actualizarlos-. Se realiza la copia y se hace “end backup”.

● Serie (Opción recomendada).

Repetir el proceso “begin backup”-copia-”end backup” para cada tbsp. minimiza el tiempo “begin”-“end” para un tbsp.



720

COPIA TBSP LECTURA/ESCRITURA EN LINEA.

En la opción paralela en lugar de realizar un “ALTER TABLESPACE ... BEGIN BACKUP;” para cada tbsp, si se están copiando todos ellos puede indicarse:

SQL> ALTER DATABASE BEGIN BACKUP;

Y en lugar de usar “ALTER TABLESPACE ... END BACKUP;” puede utilizarse:

SQL> ALTER DATABASE END BACKUP;

COPIAS DE SEGURIDAD



721

COPIA TBSP LECTURA/ESCRITURA EN LINEA. PROBLEMAS EN LA COPIA.● Una copia de tbsp puede fallar y no completarse cuando:

– La copia ha terminado pero no se indica su fin (“end backup”).

– Se interrumpe la copia debido a un fallo de instancia o la realización de un “shutdown abort”.

En caso de un “crash recovery” si un fichero está en modo copia y se intenta abrir, Oracle interpreta que es una copia a recuperar y no se abre la bd hasta la recuperación o hasta abandonar el modo copia (se generan los ORA-01113 y ORA-01110).

ORA-01113: file xx needs media recoveryORA-01110: data file xx: '/.../.../....dbf'



722

COPIA TBSP LECTURA/ESCRITURA EN LINEA. PROBLEMAS EN LA COPIA.● Abandonar el modo de copia (sólo si se está seguro de que los

ficheros están en la fecha actual).

– Montar la bd (STARTUP MOUNT).– Consultar en V$BACKUP tbsp en copia (status='ACTIVE').– Ejecutar “ALTER DATABASE END BACKUP;” (sólo si la bd está

montada y no se ha restaurado ningun fichero implicado, en caso de que esté abierta debe emplearse ALTER TABLESPACE ... END BACKUP o ALTER DATABASE DATAFILE ... END BACKUP para cada tbsp o fichero implicado).

– Abrir la bd.

● Recuperación (caso de no estar seguro de haber restaurado copia).

– Montar la bd (STARTUP MOUNT).– Recuperar la bd (RECOVER DATABASE) y comprobar en

V$BACKUP que no hay tbsp en copia (status='ACTIVE').– Abrir la bd.

COPIAS DE SEGURIDAD



723

COPIA TBSP SOLO LECTURA EN LINEA. PROCESO.

• No es necesario poner el tbsp en modo copia pues la bd no permite cambios en el mismo, simplemente copiar los f.datos correspondientes. Si el conjunto de tbsp es autocontenido puede además realizarse la exportación del tbsp con vistas a realizar posteriormente un transporte de tbsp.

– Consultar DBA_TABLESPACES para determinar qué tbsp están en modo sólo lectura (SELECT TABLESPACE_NAME, STATUS FROM DBA_TABLESPACES WHERE STATUS = 'READ ONLY';)

– Identificar los ficheros asociados a los tbsp consultando DBA_DATA_FILES.

– Copiar los ficheros correspondientes.Al restaurar la copia, debe ponerse fuera de línea el tbsp, copiar

los ficheros y ponerlo en línea.La copia es válida incluso si se cambia a lectura/escritura tras la

copia -necesitará recuperación-.



724

COPIA FICHERO CONTROL.

• En una bd en modo archivelog debe copiarse tras realizar uncambio estructural. Se requiere el privilegio ALTER DATABASE.

• Puede copiarse a un fichero binario (preferible al contenerinformación sobre historia de “redo” archivado, tbsp. fuera de línea o sólo lectura, ...) o a un fichero de traza. En ambos casos (copia a fichero binario o de traza) las entradas para los ficheros “TEMP” no son incluidas.

• Fichero binario.

– Realizar el cambio deseado a la bd.

– ALTER DATABASE BACKUP CONTROLFILE TO '/.../copia/fcontrol.bak' REUSE;

La opción REUSE permite sobreescribir un f.control existente

COPIAS DE SEGURIDAD



725

COPIA FICHERO CONTROL.

• Fichero de traza.

– Se generan sentencias SQL de creación del fichero de control en un fichero de traza (arrancan la bd, recrean el f.control, y recuperan y abren la bd).

– Debe montarse o abrirse la bd y ejecutar la sentencia:

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

– Si no se indica RESETLOGS ni NORESETLOGS en la sentencia, el fichero de traza contiene versiones del fichero para ambas opciones. Las entradas de ficheros temporales se incluyen en la salida usando sentencias "ALTER TABLESPACE... ADD TEMPFILE”.



726

COPIA “REDO” ARCHIVADO.

• Los ficheros de “redo” archivado generados pueden copiarse acinta u otro dispositivo y, de esta forma, ahorrar espacio donde este localizada la bd.

• Para realizar la copia, se averiguan los ficheros de “redo”archivado que la bd ha generado:

SQL> SELECT THREAD#,SEQUENCE#,NAME FROM V$ARCHIVED_LOG;

• Se realiza una copia de cada número de secuencia de “log”(en caso de guardar múltiples copias, sólo es necesario una por número de secuencia).

COPIAS DE SEGURIDAD



727

COPIA OTROS FICHEROS.

• Como norma general, cada vez que se modifiquen debencopiarse además el fichero de parámetros de inicialización, los de interconexión y el de contraseñas.

• La forma más sencilla de localizarlos es realizar una búsqueda automática desde $ORACLE_HOME de todos los ficheros acabados en “.ora” (orden find de s.o. UNIX).



728

COPIA MODO “SUSPEND”.

• Existen herramientas que permiten hacer copias “espejo” oduplicados exactos y desvincular la copia del original de forma que puedan usarse independientemente.

• Con la funcionalidad SUSPEND/RESUME puede suspenderse la entrada/salida de la bd, desvincular la copia “espejo” y hacer una copia de la misma. En este estado no puede ejecutarse SHUTDOWN IMMEDIATE, NORMAL oTRANSACTIONAL; ejecutar SHUTDOWN ABORT reactiva la bd. En una configuración RAC no debe arrancarse una nuevainstancia mientras los nodos originales están en suspenso.

• La sentencia ALTER SYSTEM SUSPEND permite “suspender”la bd, todas las operaciones E/S se completan pero cualquiernueva operación se guarda en cola. Se recomienda que se preceda con una sentencia “begin backup” (inicio de copia).

• Tras la copia se ejecuta la sentencia ALTER SYSTEMRESUME.

COPIAS DE SEGURIDAD



729

COPIA MODO “SUSPEND”.

• Poner los tbsp en modo copia:ALTER TABLESPACE <nombre> BEGIN BACKUP; o

ALTER DATABASE BEGIN BACKUP;

• Suspender la bd: ALTER SYSTEM SUSPEND;

• Comprobar el cambio de estado (consultar V$INSTANCE, campo DATABASE_STATUS: SELECT DATABASE_STATUS FROM V$INSTANCE;

• Realizar la copia espejo.

• Finalizar la suspensión de la bd: ALTER SYSTEM RESUME;

• Comprobar que la bd está activa (consultar V$INSTANCE, campo DATABASE_STATUS).

• Poner tbsp modo no copia: ALTER TABLESPACE users END BACKUP;

• Copiar el f.control y archivar los “redo” en línea.




METODOS DE VERIFICACION DE COPIA:

RESTAURACION DE COPIAS

DBVERIFY



731

RESTAURACION DE COPIAS.

• Periódicamente deben verificarse las copias realizadas para asegurar que son útiles para la recuperación.

• La mejor forma de hacerlo es restaurar las copias en otra máquina e intentar abrir la bd, realizando recuperación si es necesario.



732

DBVERIFY:DATABASE VERIFICATION UTILITY.

• Es una utilidad que hace un chequeo de integridad de la estructura de datos física de una base de datos en línea o fuera de línea.

• Puede usarse en ficheros de copia (“backup”) y ficheros en línea (o unidades menores). Generalmente se intenta asegurar así que una copia es válida antes de restaurarla, o como herramienta de diagnóstico cuando se encuentran problemas de corrupción de datos.

• Al ejecutarse sobre una bd fuera de línea, los chequeos son mucho más rápidos. Estos se limitan a bloques de datos -no a ficheros de control ni “redo logs”.

COPIAS DE SEGURIDAD



733

DBVERIFY. VALIDACION FICHEROS.

• Se verifican uno o más bloques de disco pertenecientes a un fichero de datos y se realizan chequeos de página. Si el fichero es del tipo Automatic Storage Management (ASM)debe indicarse un USERID.

dbv USERID = <usuario> | FILE =<nombre_de_fichero> | { START = <dirección_bloque> | END =

<dirección_bloque> } | BLOCKSIZE = integer | LOGFILE = <nombre_de_fichero> | FEEDBACK = integer | HELP = { Y | N } | PARFILE = <nombre_de_fichero>

Por ejemplo, dbv FILE=nomina.dbf FEEDBACK=100



734


• Los parámetros tienen el siguiente significado:

– USERID ... Nombre de usuario y contraseña. Sólo en el caso de ficheros ASM.

– FILE ... Nombre del fichero de bd a verificar.

– START ... Dirección inicial del bloque Oracle a verificar (por defecto, el primero del fichero).

– END ... Dirección del último bloque a verificar (por defecto el último en el fichero).

– BLOCKSIZE ... Necesario si el fichero no tiene un tamaño de bloque de 2 KB. Si es así y no se indica se genera el error DBV-00103.

COPIAS DE SEGURIDAD



735


– LOGFILE ... Fichero donde se guarda información (por defecto elterminal).

– FEEDBACK ... Informe de progreso de la verificación enviado alterminal. Un punto (.) por cada n número de página verificadas. Si n = 0, no hay informe.

– HELP ... Ayuda en línea.

– PARFILE ... Fichero de parámetros.



736


/home/oracle> dbv file=/u02/.../.../users01.dbf feedback=100

...

DBVERIFY - Verification starting : FILE = users01.dbf.....................DBVERIFY - Verification completeTotal Pages Examined : 2048Total Pages Processed (Data) : 0Total Pages Failing (Data) : 0Total Pages Processed (Index): 0Total Pages Failing (Index): 0Total Pages Failing (Seg) : 0Total Pages Empty : 2016Total Pages Marked Corrupt : 0Total Pages Influx : 0

COPIAS DE SEGURIDAD



737


Pages = bloques

Total Pages Examined = número de bloques en el fichero

Total Pages Processed = número de bloques que se verificaron (formatted blocks)

Total Pages Failing (Data) = número de bloques que fallaron la rutina de chequeo de bloque de datos.

Total Pages Failing (Index) = idem para bloque de índices.

Total Pages Marked Corrupt = número de bloques para los que la cabecera de caché no es válida, haciendo que fuera imposible determinar el tipo de bloque para DBVERIFY.

Total Pages Influx = número de bloques que estan siendo leidos y escritos en el mismo tiempo. Si la bd está abierta, se leen los bloques múltiples veces para generar una imagen consistente. Por esta misma razón, pueden haber bloques leidos y escritos a la vez (INFLUX) para los que no se puede obtener una imagen consistente.



738

DBVERIFY. VALIDACION SEGMENTOS.

• Permite indicar un segmento de tabla o índice a verificar.

• Requiere la conexión a la bd con privilegios de SYSDBA, e indicar el segmento concreto a validar.

• Durante la comprobación, el segmento es bloqueado. Si se trata de un segmento de índice, la tabla padre es bloqueada asimismo (algunos índices como los index-organized table -IOT-, donde se mantiene las filas de la tabla en un índice construido en la clave primaria, no tienen tabla padre).

COPIAS DE SEGURIDAD



739


dbv USERID = usuario/contraseña | SEGMENT_ID = tsn.segfile.segblock | LOGFILE = <nombre_fichero> | FEEDBACK = integer | HELP = { Y | N } | PARFILE = <nombre_fichero>

• Los parámetros tienen el siguiente significado:

– SEGMENT_ID ... Segmento a verificar. Compuesto por número de tbsp (tsn), “segment header file number” (segfile) y “segment header block number” (segblock). El número de tbsp puede obtenerse de v$tablespace, campo ts#, y segfile y segblock de dba_segments. También puede consultarse SYS_USER_SEGS (necesario el privilegio SYSDBA).

– LOGFILE ... Fichero donde se guarda información (por defecto el terminal).



740


– FEEDBACK ... Informe de progreso de la verificación enviado alterminal. Un punto (.) por cada n número de página verificadas. Si n = 0, no hay informe.

– HELP ... Ayuda en línea.

– PARFILE ... Fichero de parámetros.

SQL> select a.name tablespace, a.ts# numero_tbsp, b.SEGMENT_NAME segmento, b.HEADER_FILE cabecera, b.HEADER_BLOCK bloque from v$tablespace a, dba_segments b where a.name=b.TABLESPACE_NAME and b.tablespace_name='USERS' and b.owner='SCOTT' order by b.SEGMENT_NAME;

...USERS 0DEPT 1 57341...

COPIAS DE SEGURIDAD



741


/home/oracle> dbv userid=system/systxxxx segment_id=0.1.57341

...

DBVERIFY - Verification starting : SEGMENT_ID = 0.1.57341

DBVERIFY - Verification complete

Total Pages Examined : 2

Total Pages Processed (Data) : 1

Total Pages Failing (Data) : 0

Total Pages Processed (Index): 0

Total Pages Failing (Index): 0

Total Pages Processed (Other): 0

Total Pages Processed (Seg) : 1

Total Pages Failing (Seg) : 0

Total Pages Empty : 0

Total Pages Marked Corrupt : 0

Total Pages Influx : 0




FLASHBACK DATABASE



743

FLASHBACK DATABASE.

• “Flashback Database” permite “retroceder” la bd al completo ydeshacer los efectos de cambios no deseados en la bd. El resultado es muy similar a realizar una recuperación “point-in-time” aunque más rápida pues mo es preciso restaurar ficheros desde un soporte y resquiere aplicar menos cambios desde el “redo” archivado.

• Los puntos de restauración garantizada (“restore points”) permiten seleccionar un SCN y asegurar que “flashback database” podrá usarse en dicho SCN -aunque no necesariamente en los SCN entre el punto de chequeo y el momento actual- (incluso operaciones NOLOGGING u operaciones OPEN RESETLOGS).

• “Restore points” y “Flashback Database” pueden usarse independientemente o combinados. En cualquier caso, la sentencia RMAN FLASHBACK DATABASE o la SQL*Plus FLASHBACKDATABASE se emplean para devolver la bd al SCN indicado:

FLASHBACK DATABASE TO RESTORE POINT “before_upgrade”;FLASHBACK DATABASE TO SCN 202381;



744

FLASHBACK DATABASE.

• “Flashback Database” emplea su propio mecanismo de log, secrean los “flashback logs” que se almacenan en el área “flash”(proceso “flashback writer -RVWR-). Para habilitar esta característica debe crearse un área “flash” e indicar un “flashback retention target” o margen temporal en el que se podrá recuperar hacia el pasado.

• Definido ese punto, la bd copia a intervalos regulares imágenes de cada bloque modificado en cada fichero de datos en los log de “flashback”. Estas copias se reconstruyen los ficheros de datos.

• El rango de SCNs o ventana para los que hay suficientes datos “flashback log” como para realizar un “FLASHBACK DATABASE”depende del espacio en el área “flash”. Operaciones como el borrado de un tbsp. no son reversibles con este método (la ventana empezaría a continuación de los mismos). El uso de puntos de restauración garantizada es la única forma de asegurarel regreso a un SCN concreto o ancho de ventana de “flashback”.

COPIAS DE SEGURIDAD



745

FLASHBACK DATABASE.

• Si se habilita “Flashback Database” y uno o más puntos de restauración garantizada, la bd guarda los log de flashback, lo que puede generar cierta sobrecarga en el funcionamiento de la bd y uso de espacio del área “flash”.

• Se retienen los log necesarios para permitir retroceder al punto de restauración más antiguo y los log no se borran si se necesitan para garantizar este extremo. Es conveniente monitorizar el espacio en el área “flash”.



746

PUNTOS RESTAURACION.

• Para crearlos se usa la sentencia SQL*Plus CREATE RESTORE POINT indicando un nombre para el mismo y si se trata de un punto garantizado o normal (por defecto). La bd puede estar abierta o montada, siempre que en este último caso haya sido parada coherentemente.

SQL> CREATE RESTORE POINT <nombre>;

SQL> CREATE RESTORE POINT <nombre> GUARANTEE FLASHBACK DATABASE;

• Para borrar un punto de restauración se usa la sentencia SQL*Plus DROP RESTORE POINT:

SQL> DROP RESTORE POINT <nombre>;

COPIAS DE SEGURIDAD



747


• Los puntos normales pueden ser descartados aunque no se borren.Así sucede que los 2048 puntos más recientes se guardan en el fichero de control independientemente de su edad y cualquierpunto más reciente que el valor de CONTROL_FILE_RECORD_KEEP_TIME se retieneindependientemente de cuantos puntos haya definidos. Cualquierpunto normal que no cumpla ninguna de las dos condiciones mencionadas puede desaparecer del fichero de control.

• Los puntos de control garantizados siempre permanecen hasta que se borran explícitamente. Al definir este tipo de puntos, debe monitorizarse el espacio usado en el área “flash” (vistas V$RECOVERY_FILE_DEST y V$FLASH_RECOVERY_AREA_USAGE”).



748


• La vista V$RESTORE_POINT permite ver los puntos derestauración definidos:

SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZEFROM V$RESTORE_POINT;

• Para ver aquellos puntos garantizados solamente:

SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZEFROM V$RESTORE_POINTWHERE GUARANTEE_FLASHBACK_DATABASE='YES';

• Para puntos de restauración normales STORAGE_SIZE es cero. Para los garantizados STORAGE_SIZE indica la cantidad de espacio en el área “flash” usada para retener log necesarios para garantizar el regreso a dicho punto con FLASHBACK DATABASE.

COPIAS DE SEGURIDAD



749

ACTIVAR FLASHBACK DATABASE.

• Debe fijarse un valor para el parámetro de inicialización, dinámico,DB_FLASHBACK_RETENTION_TARGET (ventana de recuperación) y ejecutarse ALTER DATABASE FLASHBACK ON. En grandes bd es conveniente fijar el parámetro LOG_BUFFER a un valor de, al menos, 8Mb.

1.- Montar la bd

SQL> SHUTDOWN IMMEDIATE;SQL> STARTUP MOUNT;

2.- Indicar ventana de recuperación (por defecto 1440 minutos -24h-).

SQL> ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320;

3.- Activar Flashback Database para la bd al completo.

SQL> ALTER DATABASE FLASHBACK ON;

Para desactivar “flashback”: SQL> ALTER DATABASE FLASHBACK OFF;



750

ACTIVAR FLASHBACK DATABASE.

• Puede habilitarse/deshabilitarse el “flashback” para tbsp. específicos

SQL> ALTER TABLESPACE <nombre_tbsp> FLASHBACK ON/OFF;

• Si se deshabilita Flashback para un tbsp., deben ponerse fuera de línea sus ficheros de datos antes de ejecutar FLASHBACK DATABASE.

• DB_FLASHBACK_RETENTION_TARGET determina indirectamente cuanto log se retendrá. V$FLASHBACK_DATABASE_LOG ayuda a estimar cuánto espacio es necesario para log de “flashback”.

SQL> SELECT ESTIMATED_FLASHBACK_SIZE FROM V$FLASHBACK_DATABASE_LOG;

Nota: Debe añadirse el espacio indicado en ESTIMATED_FLASHBACK_SIZE al área de “flash”.

COPIAS DE SEGURIDAD



751

VENTANA FLASHBACK DATABASE.

• El SCN más antiguo puede determinarse de la forma siguiente:

SQL> SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME FROM V$FLASHBACK_DATABASE_LOG;

• El SCN más reciente puede obtenerse:

SQL> SELECT CURRENT_SCN FROM V$DATABASE;



752

MONITORIZACION FLASHBACK DB.

• Existen varias formas de monitorización:

– Realización de estadísticas usando Oracle Statspack.

– Consultar la vista V$FLASHBACK_DATABASE_STAT(columnas FLASHBACK_DATA, REDO_DATA y DB_DATA).

– Consultar la vista V$SYSSTAT (columnas “physical write I/O request”, “physical read I/O request”, “redo writes” y “flashback log writes”).

COPIAS DE SEGURIDAD




COPIA LOGICA



754

COPIA LÓGICA.DATA PUMP EXPORT/IMPORT.

• Son utilidades integradas en la bd que permiten cargas y descargas de información a gran velocidad. Todo el proceso de exportación/importación se lleva a cabo en el servidor.

• No son compatibles con el export/import originales.

• Consta de los siguientes componentes:

– Clientes expdp e impdp. Usan los procedimientos proporcionados por el paquete DBMS_DATAPUMP.

– Paquete DBMS_DATAPUMP. Conocido como Data Pump API, permite crear y monitorizar los trabajos implicados.

– Paquete DBMS_METADATA. Conocido como Metadata API, proporciona la definición de los objetos de la bd a Data Pump.

COPIAS DE SEGURIDAD



755


• En cada exportación o importación se crea un proceso maestro quecontrola la misma, incluyendo la comunicación con los clientes, la creación y control del conjunto de procesos de trabajo necesarios y la realización de las operaciones de conexión.

• En la transferencia de datos y metadatos, se emplea un tabla maestro, que se crea en el esquema del usuario que realiza la exportación/importación y tiene el nombre del trabajo -job- que realiza la operación, para realizar el seguimiento del proceso:

– Durante la exportación la tabla registra la localización de los objetos en el conjunto de ficheros de descarga (“dump file set”). Al finalizar, el contenido de la tabla se escribe a fichero.

– Durante la importación la tabla maestro se carga desde el conjunto de ficheros de descarga y se emplea para controlar la secuencia de localización de los ficheros a importar.



756


• Esta tabla maestro también se emplea para reiniciar un trabajo.

• El destino final de la tabla maestro es diverso:

– Si el trabajo finaliza correctamente, la tabla se borra.

– Si el trabajo se para, usando la sentencia STOP_JOB, se retiene para poder reiniciarlo.

– Si el trabajo se elimina, usando la sentencia KILL_JOB, la tabla se elimina y el trabajo no puede reiniciar.

– Si un trabajo termina inesperadamente, se mantiene la tabla. Puede borrarse si no hay intención de reiniciar el trabajo.

• El progreso de un trabajo y los errores producidos pueden registrarse en un fichero de “log”. El estado del mismo, en tiempo real, puede obtenerse usando la sentencia STATUS en modo interactivo de Data Pump.

COPIAS DE SEGURIDAD



757

DATA PUMP. INFORMACIÓN.

• Puede obtenerse información en las siguientes vistas:

– DBA_DATAPUMP_JOBS y USER_DATAPUMP_JOBS. Identifican trabajos Data Pump activos.

– DBA_DATAPUMP_SESSIONS. Identifica sesiones de usuario asociadas a un trabajo.

– V$SESSION_LONGOPS. Información sobre el progreso del trabajo.



758

DATA PUMP. FICHEROS.

• Existen tres tipos de ficheros gestionados por Data Pump:

– Ficheros de volcado (“dump”). Contienen datos y metadatos.Durante una exportación pueden indicarse al definir el trabajo así

como posteriormente (por ejemplo, pueden añadirse ficheros de volcado con ADD_FILE).

Durante un importación, todos los ficheros de volcado deben especificarse al definir el trabajo.

– Ficheros “log”. Contienen mensajes sobre la operación realizada.

– Ficheros SQL. Registran la salida de una operación SQLFILE (parámetro SQLFILE) consistente en el volcado de todas las sentencias DDL que se hubieran ejecutado durante una importación a un fichero.

Nota: Los ficheros de “log” y SQL pueden sobreescribirse si ya existen. Nunca se sobreescriben ficheros de volcado si ya existen, se genera un error.

COPIAS DE SEGURIDAD



759


• Es necesario crear objetos tipo directorio (asocia un nombre a un directorio o sistema de ficheros) por un usuario administrador o con el privilegio CREATE ANY DIRECTORY. Al exportar/importar se indica mediante el parámetro DIRECTORY.

SQL> CREATE DIRECTORY DPUMP_VOLCADO AS '/datapump/ficheros';

Por defecto se asigna el valor para DATA_PUMP_DIR:

SQL> CREATE DIRECTORY DATA_PUMP_DIR AS '/datapump/ficheros';

• Tras la creación de un directorio, su creador debe conceder el permiso de lectura (READ) o escritura (WRITE) a otros usuarios.

SQL> GRANT READ, WRITE ON DIRECTORY <directorio> TO <usuario>;

Nota: Implica tener acceso a través de bd pero no el poder acceder a través de s.o.



760


• El orden de precedencia usado para determinar la localización es:

1.- Objeto directorio formando parte de la especificación de un nombre de fichero (DUMPFILE=<localización>:<fichero>.dmp).

2.- Objeto directorio indicado en el parámetro DIRECTORY.

3.- Valor de la variable de entorno DATA_PUMP_DIR (definida enel entorno del cliente):

SQL> CREATE DIRECTORY DUMP_FICHERO AS '/DATAPUMP/FICHEROS';

# EXPORT DATA_PUMP_DIR=<VARIABLE_FICHERO_VOLCADO>

4.- Si es un usuario privilegiado se emplea el valor por defecto en bd del directorio DATA_PUMP_DIR (que debe estar previamentecreado). No confundir con la variable de entorno.

COPIAS DE SEGURIDAD



761

DATA PUMP EXPORT.

• Se emplea la utilidad expdp, indicando las características de la exportación en la línea de comandos o mediante un fichero de parámetros. Los ficheros resultantes de una exportación sólo pueden importarse con D.P. Import.

Cualquier usuario puede exportar objetos de su propiedad o su esquema al completo.

Los usuarios no privilegiados deben tener permiso WRITE en el objeto directorio y deben indicar éste en el parámetro DIRECTORYo junto al nombre de fichero de volcado.

Modo ayuda en línea: expdp HELP=y

Modo interactivo: expdp directory=<localización>

Modo fichero de parámetros: expdp PARFILE=<fichero_parametros>

Nota: Si no se indica ningún otro parámetro se usan los valores por defecto en la exportación: expdat.dmp y export.log -ficheros-, exportación a nivel de esquema, SYS_EXPORT_SCHEMA_01 -trabajo- y se exportan datos y metadatos.



762

DATA PUMP EXPORT.

• Existen cinco modos de trabajar con “datapump export”:

- “Full export” (parámetro FULL). Se exporta toda la bd. Es necesario el rol EXP_FULL_DATABASE.

- “Esquema de usuario” (parámetro SCHEMAS). Si no se posee rolEXP_FULL_DATABASE sólo es posible exportar el esquema propio.

- “Tabla” (parámetro TABLES). Para exportar tablas no pertenecientes al propio esquema es necesario el rol EXP_FULL_DATABASE.

- “Tablespace” (parámetro TABLESPACES). Debe tenerse el rol EXP_FULL_DATABASE.

- “Transport Tablespace” (parámetro TRANSPORT_TABLESPACES). Permite exportar metadatos para tablas y objetos dependientes pertenecientes a un conjunto de espacios de almacenamiento. Es necesario el rol EXP_FULL_DATABASE.

COPIAS DE SEGURIDAD



763

DATA PUMP IMPORT.

• Se emplea la utilidad impdp, indicando las características de laimportación en la línea de comandos o mediante un fichero de parámetros. Sólo pueden usarse en la importación ficheros creadoscon D.P. Export.

Los usuarios deben tener permiso READ en el objeto directorio dond resida el fichero de volcado y de escritura donde se cree el fichero de registro (log) y los SQL.

Modo ayuda en línea: impdp HELP=y

Modo interactivo: impdp directory=<localización>

Modo fichero de parámetros: impdp PARFILE=<fichero_parametros>

Nota: Si no se indica ningún otro parámetro se usan los valores por defecto en laexportación: expdat.dmp e import.log -ficheros-, importación total del fichero y trabajo SYS_IMPORT_xx_01.



764

DATA PUMP IMPORT.

• Existen cinco modos de trabajar con “datapump import”:

- “Full import” (parámetro FULL). Se importa el fichero de volcado al completo (modo por defecto). Necesario el rol IMP_FULL_DATABASEsi se hizo la exportación con EXP_FULL_DATABASE.

- “Esquema de usuario” (parámetro SCHEMAS). Sólo se cargan objetos propiedad del usuario actual. Si se posee rolIMP_FULL_DATABASE pueden cargarse esquemas diferentes al propio.

- “Tabla” (parámetro TABLES). Para importar tablas no pertenecientesal propio esquema es necesario el rol IMP_FULL_DATABASE.

- “Tablespace” (parámetro TABLESPACES).

- “Transport Tablespace” (parámetro TRANSPORT_TABLESPACES). Permite importar metadatos para un conjunto de espacios de almacenamiento. Es necesario el rol IMP_FULL_DATABASE.

COPIAS DE SEGURIDAD




TBSP TRANSPORTABLES



766

“TABLESPACES” TRANSPORTABLES.

• Permite trasladar un conjunto de espacios de almacenamientodesde una bd a otra (sólo entre bd con el mismo juego de caracteres -character set- y sobre plataformas compatibles).

• Los tbsp transportados pueden ser gestionados localmente o no. No necesitan ser del mismo tamaño de bloque que el tamaño de bloque estándar de la bd destino.Es util, por ejemplo, para:

– Realizar una recuperación a un punto en el tiempo “Tablespace Point-in-Time Recovery” (TSPITR).

– Archivo de datos históricos.– Copia de tbsp. de sólo lectura en múltiples bd.– Migración de bd entre distintas plataformas (SQL> SELECT *

FROM V$TRANSPORTABLE_PLATFORM;).

COPIAS DE SEGURIDAD



767

“TBSP” TRANSPORTABLES. LIMITACIONES.

• Ambas bbdd deben usar el mismo juego de caracteres -character set- y el mismo juego de caracteres nacional -national character set-.

• No puede transportarse un tbsp a una bd destino en el cual exista un tbsp con el mismo nombre (alguno de los dos debe renombrarse).

• Los tbsp transportables no soportan:– Vistas materializadas– Tablas particionadas– Migración del tbsp SYSTEM u objetos de SYS– ...



768

“TBSP” TRANSPORTABLES. COMPATIBILIDAD.

• Al definir un conjunto transportable, Oracle calcula el más bajo nivel de compatibilidad al cual la bd destino debe trabajar. A partir de Oracle 10g, un tbsp. puede transportarse a una bd con el mismo o superior nivel de compatibilidad.

COPIAS DE SEGURIDAD



769

“TBSP” TRANSPORTABLES.PROCESO 1/6.

• Determinar la compatibilidad de las plataformas.

• Sólo es necesario si se trabaja con plataformas origen y destino diferentes. Debe ejecutarse la sentencia:

SQL> SELECT d.PLATFORM_NAME, ENDIAN_FORMATFROM V$TRANSPORTABLE_PLATFORM tp, V$DATABASE dWHERE tp.PLATFORM_NAME = d.PLATFORM_NAME;



770


• Seleccionar un conjunto de tbsp “autocontenidos”.

• No deben haber dependencias entre objetos del conjunto de tbsp transportables y aquellos que no sean del mismo. Se incumple si, por ejemplo, existe:

– Un índice dentro del conjunto está definido para una tabla fuera del mismo (sí puede existir un índice fuera del conjunto definido para una tabla del mismo).

– Una tabla particionada parcialmente contenida en el conjunto.

– Una “constraint” de integridad referencial apuntando a una tabla (al transportar tbsp pueden incluirse restricciones de integridad o no).

– Una tabla con una columna LOB que referencia LOBS fuera del conjunto.

COPIAS DE SEGURIDAD



771

“TBSP” TRANSPORTABLES. DBMS_TTS.

• Para determinar si un conjunto de tbsp es autocontenido se emplea el procedimiento TRANSPORT_SET_CHECK del paquete DBMS_TTS (debe poseerse el rolEXECUTE_CATALOG_ROLE).

DBMS_TTS.TRANSPORT_SET_CHECK ( ts_list IN CLOB, incl_constraints IN BOOLEAN DEFAULT FALSE, full_check IN BOOLEAN DEFAULT FALSE);

ts_list ... Lista de tbsp, separados por coma.incl_constraints ... TRUE para considerar las restricciones de

integridad referencial en el análisis (valor por defecto).full_closure ... Por defecto FALSE. Determinar o no si está

autocontenido estrictamente (dependencias desde-hacia). Para TSPITR debe ser puesto a TRUE.



772

“TBSP” TRANSPORTABLES. DBMS_TTS.

• Para una aplicación estricta, el parámetro FULL_CHECK debetener el valor TRUE (por ejemplo, Tablespace Point-in-Time Recovery -TSPITR-).

• Todas las excepciones producidas pueden verse a través de la vista TRANSPORT_SET_VIOLATIONS. Si la vista está vacía, el conjunto de tbsp es autocontenido.

SQLPLUS> EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK('NOMINA,PAGOS', TRUE);

SQLPLUS> SELECT * FROM TRANSPORT_SET_VIOLATIONS;

COPIAS DE SEGURIDAD



773


• Generar un conjunto de tbsp. transportables.

– Cambiar el estado de los tbsp a sólo lectura.

ALTER TABLESPACE <nombre_tbsp> READ ONLY;

– Realizar la exportación de metadatos de los tbsp a migrar (sólo se exportan metadatos) -conexión con privilegio SYSDBA-. Debe poseerse el rol EXP_FULL_DATABASEpara realizar la exportación.

DUMPFILE = expdat.dmpDIRECTORY = dpump_dirTRANSPORT_TABLESPACES = (NOMINA, PAGOS)



774


Si el autocontenido debe ser estricto:

DUMPFILE = expdat.dmpDIRECTORY = dpump_dirTRANSPORT_TABLESPACES = (NOMINA, PAGOS) TRANSPORT_FULL_CHECK=Y

• TRANSPORT_FULL_CHECK es un parámetro que verifica que un conjunto de tbsp a recuperar no tiene dependencias (hacia/desde).

• Si el conjunto de tbsp no es autocontenido, la exportación falla.

COPIAS DE SEGURIDAD



775


Si la codificación entre las plataformas es distinta, deben convertirse los ficheros de datos empleando la orden CONVERT de RMAN.

$ RMAN TARGET /Recovery Manager: Release 10.1.0.0.0Copyright (c) 1995, 2003, Oracle Corporation. All rights connected to target database: xxxx (DBID=...)

RMAN> CONVERT TABLESPACE sales_1,sales_22> TO PLATFORM 'Microsoft Windows NT'3> FORMAT '/temp/%U';Starting backup at 08-APR-03...Finished backup at 08-APR-03

RMAN> exit



776


• Copiar los ficheros de datos correspondientes a los tbsp a transportar al lugar de destino. Hacer igual con el fichero resultado de la exportación.

• Puede hacerse de distintas formas como, por ejemplo, cualquier utilidad que permita copiar ficheros -ftp, copia de s.o.-, el paquete DBMS_FILE_TRANSFER, ...

COPIAS DE SEGURIDAD



777


• Integrar el conjunto de tbsp transportados.

– Importar la información relativa a los tbsp.

IMPDP system/password DUMPFILE=expdat.dmp DIRECTORY=dpump_dir

TRANSPORT_DATAFILES= /salesdb/sales_101.dbfREMAP_SCHEMA=(dcranney:smith)REMAP_SCHEMA=(jfee:williams)

• TRANSPORT_DATAFILES identifica los ficheros de datos correspondientes a los tbsp a importar

• REMAP_SCHEMA cambia los propietarios de los objetos de bd. Si no se indica se crean en el mismo esquema que el origen y dichos esquemas deben existir en el destino o, en caso contario, generan un error.



778


• Comprobar si se han generado errores en el proceso de importación.

• Si todo ha ido bien, los tbsp se habrán copiado en modo sólo lectura. Cambiar el espacio al estado de lectura/escritura.

ALTER TABLESPACE <nombre_tbsp>READ WRITE;

COPIAS DE SEGURIDAD



779


• Si se migran tbsp de una tamaño de bloque distinto al tamañode bloque estánsar de la bd destino, en esta debe añadirse el parámetro de inicialización DB_nK_CACHE_SIZE.

• DB_nK_CACHE_SIZE (donde n = 2, 4, 8, 16, 32) es unparámetro dinámico (modificable con ALTER SYSTEM) quepermite especificar el tamaño de la caché para nK buffers.

• Por ejemplo, si el tbsp a migrar tiene 8K de tamaño de bloque y la bd destino 4K, debe incluirse DB_8K_CACHE_SIZE como parámetro.



780

“TBSP” TRANSPORTABLES. RESUMEN.

• Proceso.

– Cambiar los espacios de almacenamiento al estado de sólo lectura.

– Trasladar la información almacenada en el diccionario (exportación de metadatos) a la bd destino.

– Copiar los ficheros de datos correspondientes a dichos espacios de almacenamiento en el destino.

– Integrar la información en la bd destino (importación).

– Cambiar el espacio al estado de lectura/escritura.

COPIAS DE SEGURIDAD



781

VISTAS.

• V$DATAFILE

• V$TABLESPACES

• V$LOGFILE

• V$CONTROLFILE

• V$BACKUP

• V$INSTANCE

• V$ARCHIVED_LOG



782

TEMA 10.

RECUPERACION.

RECUPERACION



783

TEMA 10. RECUPERACION.

• RECUPERACION.

• ESTRUCTURAS DE RECUPERACION.

• PRINCIPIOS DE RECUPERACION.

• TIPOS DE RECUPERACION.– COMPLETA.– INCOMPLETA.– FLASHBACK.

• ESTRATEGIAS DE RECUPERACION.

• RESTAURACION DE FICHEROS.– FICHEROS DE COPIA.– “REDO” ARCHIVADO.

• RESTAURAR Y RECREAR F. CONTROL.

RECUPERACION Administración y Ajuste de Oracle 10g


784


• RECUPERAR F. CONTROL.– PERDIDA DE MIEMBRO MULTIPLEXADO.– PERDIDA DE TODOS MIEMBROS.– PERDIDA DE MIEMBROS Y COPIAS.

• RECUPERACION COMPLETA– BD CERRADA.– BD ABIERTA.

• RECUPERACION INCOMPLETA.– “CANCEL BASED”.– “TIME BASED”.– “CHANGE BASED”.

• RECUPERACION PARALELA.

• APERTURA BD TRAS RECUPERACION.



785


• TSPITR (“Tbsp. Point in time recovery”).– PRELIMINARES. – CREACION BD AUXILIAR. – TRANSPORTAR TBSP. OPERACIONES BD AUXILIAR.– TRANSPORTAR TBSP. OPERACIONES BD EN USO.

• VISTAS.



786

RECUPERACION Y ESTRUCTURAS

RECUPERACION



787

RECUPERACION.

• La posibilidad de un fallo de sistema o de máquina siempre existe. Si ocurre y afecta a la bd, esta debe recuperarse. El objetivo es asegurar que los efectos de las transacciones validadas se reflejen en la bd recuperada y la vuelta a una operación normal de la bd lo antes posible.

• Existen distintos tipos de fallos que pueden hacer necesario o no la intervención del administrador de bd y la recuperación:

– Error de usuario. Por ejemplo, el borrado de una tabla (puede recuperarse de una copia lógica previa o mediante el uso de “flashback”). Es necesaria la intervención del administrador y la recuperación.

– Fallo de una sentencia. Se deshace cualquier cambio automáticamente y se devuelve el control al usuario.



788

RECUPERACION.

– Fallo de proceso. P.ej. desconexión anormal. PMON lodetecta, hace “rollback” de transaccion y libera recursos.

– Fallo de instancia. Debido a problemas de máquina, un fallo de s.o. ... Oracle realiza sin intervención del usuario la recuperación de la instancia (“crash recovery”).

– Fallo en disco (“media failure”). Es necesaria la intervención del administrador y la recuperación (“media recovery”). Deben restaurarse ficheros desde copia física usando sentencias de s.o. y realizar recuperación con la sentencia SQL*Plus RECOVER (modo ARCHIVELOG).

“Media recovery” puede ser completa -todo “redo”generado se aplica- o incompleta -no se aplica todo el “redo” generado y se obtiene una versión anterior de la bd- (en ambos casos la recuperación afecta a la bd en su totalidad, al completo). TSPITR, “tablespace point-in-timerecovery”, permite realizar una recuperación incompleta deun tbsp concreto.

RECUPERACION



789

ESTRUCTURAS DE RECUPERACION.

• Ficheros de datos (“datafiles”) y bloques de datos.

La bd se estructura en unidades lógicas llamadas “tablespaces”, las cuales se asocian con uno o más ficheros de datos, “datafiles”. La bd gestiona el espacio en dichos ficheros en unidades llamadas bloques de datos (la mínima unidad dealmacenamiento que puede manejar la bd).

Los datos nuevos o modificados no se escriben a los “datafiles” de forma inmediata sino que se almacenan en memoria y se escriben a intervalos. Si surge un fallo que hace caer la bd habrán cambios guardados en memoria que no han sido aplicados.

La copia física de los “datafiles” es fundamental en cualquierestrategia de copia y recuperación.



790


• Redo Log.

Conjunto de ficheros que registran todos los datos modificados en memoria que aun no han sido escritos a los ficheros de datos. Cada bd necesita al menos dos grupos de “redo” en línea con un miembro de “redo”.

Este “redo” en línea debe guardarse y da lugar al llamado “redo log” archivado (modo archivelog de la bd).

En modo ARCHIVELOG la bd puede recuperarse completamente de fallos de instancia y de disco. También puede hacerse copia mientras está abierta y en uso.

En modo NOARCHIVELOG, la bd puede ser recuperada de un fallo de instancia pero no de disco. La bd sólo puede copiarse si está cerrada de forma consistente.

RECUPERACION



791


• Registros de “undo”.

Almacenados en espacios de almacenamiento de “undo” o en “rollback segments” (inusual en este caso). Contienen las imagenes anteriores de aquellos datos que han sido modificados y se emplean para “deshacer” las transacciones no validadas tras la aplicación de todo el “redo log”.

● Ficheros de control.

Guardan información de las estructuras físicas de la bd y su estado:

– Información sobre la bd (RESETLOGS SCN y time stamp) usada en la recuperación.



792


– Información sobre “redo log” en línea actual.– Registros de log (log sequence numbers, SCN en cada log)– Información sobre bloques de ficheros de datos corruptos.

● Copias de bd (“backups”).

Realizadas mediante Recovery Manager o con utilidades s.o..

RECUPERACION



793

PRINCIPIOS Y TIPOSDE

RECUPERACION



794

PRINCIPIOS DE RECUPERACION.

• Se aborda a lo largo del tema la recuperación asumiendo quela bd se encuentra en modo ARCHIVELOG y usando métodos de recuperación manuales.

• La recuperación básicamente implica dos acciones:

– Restaurar el/los fichero/s dañados desde el dispositivode copia preciso (cinta, disco, ...) y hacerlo accesible al servidor de bd (permisos, ...).

– Recuperación o aplicar los cambios al fichero/s dañado/s empleando el “redo” archivado y en líneahasta que la bd se encuentre en el SCN deseado (generalmente el momento previo al fallo que obligó a la recuperación).

RECUPERACION



795

PRINCIPIOS DE RECUPERACION.



796

TIPOS DE RECUPERACION: COMPLETA.

• Completa.

Se emplean datos de “redo” combinados con una copia de la bd, tbsp., o fichero de datos para actualizarlo al punto más actual posible. Se aplican todos los cambios anotados en el “redo”.

Si se pretende recuperar la bd en su conjunto, debe:

– Montarse la bd.– Asegurarse de que todos los ficheros a recuperar están en

línea.– Restaurar una copia de la bd o ficheros a recuperar.– Aplicar “redo” (en línea, archivado o ambos).

RECUPERACION



797

TIPOS DE RECUPERACION: COMPLETA.

Si se pretende recuperar un tbsp o fichero de datos, debe:

– Si la bd está abierta, poner el tbsp o fichero fuera de línea.– Restaurar una copia de los ficheros a recuperar.– Aplicar “redo” (en línea, archivado o ambos).



798

TIPOS DE RECUPERACION: INCOMPLETA.

• Incompleta.

Se emplea una copia de la bd para generar una versión no actual de la bd. No se aplican todos los cambios posteriores a la última copia.

Se puede realizar sobre la bd en su conjunto: DBPITR -”db point-in-time recovery”-. En los siguientes casos:

– Un fallo en disco destroza algunos o todos los “redo” en línea.

– Se ha producido una pérdida de datos, por ejemplo el borrado de una tabla (¡conveniente tener copia lógica, aunque en este punto también puede usarse “flashback”).

– No puede realizarse una recuperación completa pues se han perdido “redo” archivados.

– Se han perdido los ficheros de control y debe usarse una copia para abrir la bd.

RECUPERACION



799

TIPOS DE RECUPERACION: INCOMPLETA.

• Para realizarla deben recuperarse todos los ficheros de datosprecisos de copias anteriores a aquel momento al que se pretenda restaurar y abrir la bd con la opción RESETLOGS.

Al indicar “alter database open resetlogs;” se reinicia el número de secuencia de “log” actual -número 1- y se desecha cualquier información de “redo” no aplicada durante la recuperación, pone a cero.

Es conveniente realizar una copia completa de la bd si se ha producido cualquier pérdida de archivados.

• Un caso particular es la recuperación de un tbsp “point in time” (TSPITR). Permite recuperar uno o más tbsp. a un momento en el tiempo distinto del resto de la bd.



800

INCONVENIENTES RECUPERACION TRADICIONAL• Existen inconvenientes en la recuperación completa o

incompleta señaladas anteriormente (en general en el “point-in-time recovery”):

– No pueden devolverse objetos concretos a un estado anterior, sólo la bd en su conjunto (en casos concretos puede realizarse un “tablespace point-in-time recovery -TSPITR-”).

– La bd no está disponible durante el proceso de “point-in-time recovery”.

– “Point-in-time recovery” puede ser pesado dado que todos losficheros de datos deben restaurarse y después recuperar la bd.

• Las utilidades “flashback” proporcionadas por Oracle son más eficientes que la recuperación tradicional en la mayoría de los casos.

RECUPERACION



801

TIPOS DE RECUPERACION: FLASHBACK.

• Flashback proporciona un conjunto de características quepermiten evitar la restauración de la bd y la realización de recuperación “point-in-time”.

• La mayoría de estas características se desarrollan a un nivel lógico, como son:

– Oracle Flashback Query. Consultar contenido de bd en un tiempo anterior.

– Oracle Flashback Version Query. Ver estados anteriores de datos.

– Oracle Flashback Transaction Query. Ver transacciones que afectan a un tabla a lo largo del tiempo.

– Oracle Flashback Table. Devolver tablas a un estado previo.

– Oracle Flashback Drop. Deshace el efecto de “drop table”.

• Fl. Table, Fl. Query, Fl. Trans. Query y Fl. Version Query están relacionadas con “undo”. Fl. Drop se basa en el “recycle bin”.



802


• A nivel físico, Oracle Flashback Database permite en elcaso de tener ficheros de datos en los que se desea deshacercambios volver a su estado anterior. Esta forma de trabajo es mucho más rápida pues no necesita de la restauración de ficheros ni de la aplicación de todo el conjunto del “redo”archivado. Es necesario configurar un área de memoria “flashrecovery area” y habilitar el “flashback logging” pues no lo está por defecto.

• El proceso implica:

– Averiguar SCN al que retornar, o determinar el punto de retorno apropiado. Consultar CURRENT_SCN en V$DATABASE y la vistaV$FLASHBACK_DATABASE_LOG:

SQL> SELECT CURRENT_SCN FROM V$DATABASE;SQL> SELECT OLDEST_FLASHBACK_SCN,

OLDEST_FLASHBACK_TIME FROM V$FLASHBACK_DATABASE_LOG;

RECUPERACION



803


– Usar, en su caso, el resto de funcionalidades “flashback” para identificar el SCN en que se produjeron los cambios a deshacer.

– Ejecutar Fl.Database

FLASHBACK DATABASE TO SCN 46963;FLASHBACK DATABASE TO TIMESTAMP (SYSDATE-1/24);FLASHBACK DATABASE TO TIMESTAMP timestamp '2007-19-02

14:00:00';FLASHBACK DATABASE TO TIMESTAMP to_timestamp ('2007-

19-02 19:30:00', 'YYYY-MM-DD HH24:MI:SS');

– Abrir la bd en modo sólo lectura y comprobar el resultado. Si es necesario realizar “flashback” de nuevo a un SCN distinto, debe usarse RECOVER DATABASE para volver al presente y hacer de nuevo “flashback”.

– Si el resultado de “flashback database” es correcto, abrir la bd con la opción RESETLOGS.



804

ESTRATEGIASDE

RECUPERACION

RECUPERACION



805

ESTRATEGIAS DE RECUPERACION.

• Frente a errores de usuario.

– Flashback Database. Permite devolver la bd al completo a un estado anterior sin necesidad de restaurar, tomando como referncia un SCN o creando los puntos de restauración, “restore points”, necesarios. Debe estar configurada una “flash recovery area”.

– Recuperación de la bd “Point-in-Time”. Se recupera un tbsp. o la bd al completo a un momento concreto.

– Importación desde copia lógica.

• Frente a fallos de máquina (“media failure”).

– El tipo de fallo (fallo físico, sobreescritura, borrado o corrupción de un fichero de bd, ...) determina la técnica de recuperación a usar.



806


• Si la bd está en modo NOARCHIVELOG y hay un fallo en disco, “media failure”, se debe restaurar la copia completa y consistente más reciente y abrir la bd (si se quisiera la bd actualizada hasta el momento del fallo, habría que introducir todos los cambios manualmente ¡imposible!).

• Si la bd está en modo ARCHIVELOG y los “redo” están disponibles, puede emplearse una recuperación completa o incompleta para reconstruir la bd.

RECUPERACION



807


• Probar los mecanismos de copia y recuperación en un entorno apropiado.

• Planificar la respuesta a los distintos tipos de incidentes. Se atenderá al siguiente procedimiento general:

– Determinar la información que se necesita recuperar y restaurar.

– Restaurar copia de los ficheros y cualquier fichero de “redo” archivado que sea necesario (a nivel de s.o.).

– Recuperar los ficheros.– Abrir la bd. Si se hace una recuperación incompleta o se

ha restaurado una copia del fichero de control, debe abrirse con la opción RESETLOGS.



808

RESTAURACIONY

RECUPERACION

RECUPERACION



809

RESTAURACION DE FICHEROS.

• Restaurar un fichero es reemplazarlo por una copia previa delmismo. Se trata de una operación previa a la recuperación de cualquier fichero dañado.Es necesario, por tanto, guardar la localización de los ficheros de datos, control, “redo” en línea, “redo” archivado, inicialización, comunicaciones y contraseñas.

• Localización datos, control y “redo” en línea.

SELECT NAME FROM V$DATAFILEUNION ALLSELECT MEMBER FROM V$LOGFILEUNION ALLSELECT NAME FROM V$CONTROLFILE;



810

RESTAURAR FICHEROS DE COPIA.

• Localización “redo” archivado.

SELECT NAME, VALUE FROM V$PARAMETERWHERE NAME LIKE log_archive_dest%AND VALUE IS NOT NULL ;

• Formato de “redo” archivado.

SHOW PARAMETER LOG_ARCHIVE_FORMAT

• Listado de “redo” archivado.

SELECT NAME FROM V$ARCHIVED_LOG;

RECUPERACION



811

FICHEROS A RESTAURAR.

• La vista V$RECOVER_FILE muestra el estado de los ficherosque necesitan recuperación, el motivo, el SCN donde debe comenzar, ...

SELECT * FROM V$RECOVER_FILE;

Nota:La vista no es util si el fichero de control en uso es una copia restaurada o uno nuevo creado tras el fallo en disco (“media failure”), pues, en este caso, no contiene la información necesaria para actualizar v$recover_file.

• De V$DATAFILE y V$TABLESPACE pueden obtenerse nombres de fichero y de “tablespaces” de aquellos ficheros que necesitan recuperación.

SELECT r.FILE#, d.NAME, t.NAME, d.STATUS, r.ERROR, r.CHANGE#, r.TIME FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t WHERE t.TS# = d.TS# AND d.FILE# = r.FILE#



812

RESTAURAR “REDO” ARCHIVADO.

• El “redo” archivado debe ser accesible durante larecuperación en el lugar definido como primer destino de archivado (log_archive_dest_1).

• Si es necesario indicar una localización alternativa puede hacerse e indicarlo mediante el parámetro LOGSOURCE-orden SET de SqlPlus o el parámetro RECOVER ... FROM de la sentencia ALTER DATABASE –de forma previa a la recuperación-. También especificando el nuevo destino: RECOVER AUTOMATIC TABLESPACE <tbsp> FROM“\...\...”;

• Para averiguar que ficheros de “redo” son necesarios, se consultan las vistas:

– V$ARCHIVED_LOG ... Nombres de todos los ficheros de“redo” archivado.

RECUPERACION



813

RESTAURAR “REDO” ARCHIVADO.

– V$RECOVERY_LOG ... “redo” archivado necesario para la recuperación (sólo contiene información en caso de necesitarse recuperación para un fichero de datos, no si se trata de una recuperación planificada por un fallo de usuario).



814

RESTAURAR FICHEROS DE COPIA.

• Determinar los ficheros de datos a recuperar.

• Si la bd está abierta, poner los “tablespaces” a recuperar fuera de línea:

ALTER TABLESPACE users OFFLINE IMMEDIATE;

• Restaurar copias de los ficheros dañados a su misma localización:

cp /copia/tbs_24.bak /u02/.../tbs_24.f

• Recuperar (RECOVER) y poner el tbsp. recuperado en línea:

RECOVER TABLESPACE <tbsp>;ALTER TABLESPACE <tbsp> ONLINE;

RECUPERACION



815

RESTAURAR Y RECREAR F. CONTROL.

• Si un fallo de disco, “media failure”, afecta a los ficheros de control (multiplexados o no), la bd sigue trabajando hasta la primera vez que un proceso “background” necesita acceder a los mismos; en este instante la bd se cierra automaticamente.

• Si el fallo es temporal y la bd todavía no se ha cerrado, puede intentarse corregir el fallo. Si la bd cierra, puede arrancarse tras corregir el problema y restaurar el acceso a los ficheros de control.



816

RECUPERAR F. CONTROL.PERDIDA DE MIEMBRO MULTIPLEXADO.

• En el caso de que un fallo haya dañado uno o más ficheros decontrol y, al menos, exista un f.control no dañado.

• Suponiendo que el disco y el sistema de ficheros donde reside el fichero dañado funcionan correctamente:

– Parar la bd: SHUTDOWN ABORT– Corregir el problema hw.– Copiar un fichero de control intacto sobre el/los ficheros/s

de control dañado/s

cp /u02/.../control01.ctl /u03/.../control02.ctl

– Arrancar la bd: STARTUP

RECUPERACION



817

RECUPERAR F. CONTROL.PERDIDA DE MIEMBRO MULTIPLEXADO.

• Si el disco y el sistema de ficheros donde reside el fichero dañado NO funcionan correctamente:

– Parar la bd: SHUTDOWN ABORT– Copiar el fichero de control intacto a una localización

alternativa: cp /u02/.../control01.ctl /u05/.../control02.ctl– Editar el fichero de parámetros de inicialización y

modificar la variable CONTROL_FILES de forma que contenga SOLO las localizaciones actuales de los ficheros de control válidos (se excluyen el resto).

CONTROL_FILES = '/u02/.../control01.ctl', '/u05/.../control02.ctl'

– Arrancar la bd: STARTUP



818

RECUPERAR F. CONTROL.PERDIDA DE TODOS MIEMBROS.

• No puede montarse ni abrirse la bd hasta tener un fichero decontrol accesible. Si se intenta montar la bd, se produce el error “ORA-00205: error in identifying controlfile, check alertlog for more info”.

• Al restaurar una copia del fichero de control, debe abrirse la bd con la opción RESETLOGS.

• Si se tiene copia del fichero de control.

• Suponiendo que el disco y el sistema de ficheros donde reside el fichero dañado funcionan correctamente:

– Parar la bd: SHUTDOWN ABORT– Corregir el problema hw.

RECUPERACION



819


– Restaurar la copia del fichero de control a todos los destinos indicados en el parámetro de inicialización CONTROL_FILES (orden cp).

– Montar la bd: STARTUP MOUNT – Recuperar, sentencia RECOVER con la claúsula USING

BACKUP CONTROLFILE. Indicar UNTIL CANCEL si se está realizando una recuperación incompleta:

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL

– Aplicar los “log” archivados. Si se recibe un mensaje indicando que alguno no existe, probablemente significa que la información necesaria está en los “redo” en línea -cambios no archivados al suceder el problema-.



820


ORA-00279: change 55636 generated at 06/08/2000 16:59:47 needed for thread 1

ORA-00289: suggestion : /oracle/work/arc_dest/arcr_1_111.arcORA-00280: change 55636 for thread 1 is in sequence #111Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

Puede indicarse el nombre de un “log” en línea y pulsarse retorno de carro:

/oracle/dbs/t1_log1.fLog applied.Media recovery complete.

Si los “redo” en línea no están accesibles, puede cancelarse la recuperación sin aplicarlos. En este caso debe recrearse el fichero de control si los cambios en los “redo” en línea son necesarios.

– Abrir la bd con la opción RESETLOGS: ALTER DATABASE OPEN RESETLOGS;

– Realizar una copia completa de la bd.RECUPERACION



821


• Si no puede restaurarse el fichero de control a su localizaciónoriginal; debe indicarse una nueva localización en el fichero de parámetros, variable CONTROL_FILES.

• La restauración es idéntica al caso en que se restaure a la localización por defecto, salvo que debe modificarse el fichero de parámetros de forma previa a la misma y al montaje de la bd.



822

RECUPERAR F. CONTROL.PERDIDA DE MIEMBROS Y COPIAS.

• Si los ficheros de control se han dañado pero el “redo” en línea permanece, puede recuperarse la bd tras crear un fichero de control. No se requiere abrir la bd, en este caso, con la opción RESETLOGS. Para crear u fichero de control:

– Arrancar la bd , no montar: STARTUP NOMOUNT– Crear el fichero de control, indicando la opción

NORESETLOGS. Por ejemplo:

CREATE CONTROLFILE REUSE DATABASE SALES NORESETLOGS ARCHIVELOG...

Tras crear el fichero de control, Oracle monta la bd.

– Recuperar la bd: RECOVER DATABASE– Abrir la bd: ALTER DATABASE OPEN;– Realizar copia del fichero de control: ALTER DATABASE

BACKUP CONTROLFILE TO '/.../copia_fcontrol' REUSE;

RECUPERACION



823


• Existen distintas opciones para crear el fichero de control:

– En el caso de haber ejecutado un ALTER DATABASEBACKUP CONTROLFILE TO TRACE NORESETLOGS tras el último cambio estructural, o antes de haber realizado este cambio; puede usarse el fichero de traza generado (en caso de no reflejar los últimos cambios, debe editarse y añadirlos).

– Si se ha realizado una copia a fichero binario, ALTERDATABASE BACKUP CONTROLFILE TO fichero;, debe copiarse el fichero, crear una instancia temporal, montarla bd -STARTUP MOUNT- y realizar una copia a traza -ALTER DATABASE BACKUP CONTROLFILE TO TRACENORESETLOGS-. Se edita, si es necesario, y se realizan los cambios oportunos.



824


– Si no existe copia del fichero de control, debe crearse manualmente (sentencia CREATE CONTROLFILE).

RECUPERACION



825

CONDICIONES RECUPERACION.

• Para realizar cualquier tipo de “media recovery” debe tenerseen cuenta que:

– Deben tenerse privilegios de administrador.– Una sesión no puede comenzar una recuperación

completa mientras otra realiza una recuperación tipo incompleta.

– No puede realizarse “media recovery” si se está conectado a la bd a través de un proceso servidor compartido (“shared server”).

• Debe usarse la sentencia SQL*Plus RECOVER, y realizar una recuperación automática; así no se interroga al aplicar cada “log” archivado. Los nombres de estos, se obtienen concatenando LOG_ARCHIVE_FORMAT y LOG_ARCHIVE_DEST_n, siendo n el mayor valor entre los destinos habilitados.



826

CONDICIONES RECUPERACION.

• Hay dos formas de automatizar la aplicación de los “redo” necesarios en la recuperación:

– Ejecutando SET AUTORECOVERY ON antes de RECOVER.

Startup mountSet autorecovery onRecover databasealter database open;

– Indicando la claúsula AUTOMATIC como opción de la sentencia RECOVER.

Startup mountRecover automatic databasealter database open;

RECUPERACION



827

RECUPERACION COMPLETA.

• Se recuperan las copias al SCN actual; bien la bd al completo, o tbsp o ficheros de datos individuales.

• No es necesario abrir la bd con RESETLOGS, de forma que pueden recuperarse ciertos ficheros de datos en un momento y los restantes posteriormente.



828

RECUPERACION COMPLETA.BD CERRADA.

1.- Preliminares.

– Cerrar la bd: SHUTDOWN ABORT.– Intentar corregir el fallo que origina el error (puede que el

fallo sea temporal y los datos no hayan sido dañados).

2.- Restaurar copias de los ficheros dañados o perdidos.

– Determinar los ficheros de datos a recuperar.– Identificar la copia más reciente de los ficheros dañados

(no restaurar ficheros de datos no afectados ni ”redo” en línea).

– Restaurar los ficheros.

RECUPERACION



829


3.- Recuperar la bd.

– Montar la bd: STARTUP MOUNT.– Obtener los nombres de los ficheros de datos y su estado:

SELECT NAME,STATUS FROM V$DATAFILE;– Asegurarse de que todos los f.datos de la bd están en

línea (a menos que forme parte de un tbsp. de sólo lectura o se hubiera puesto fuera de línea normalmente): ALTER DATABASE DATAFILE '/.../tbs.dbf' ONLINE;

– Ejecutar la sentencia paa recuperar la bd -todos los ficheros dañados- , un tbsp. concreto o un fichero de datos (puede indicarse recuperación automática):

RECOVER DATABASE;RECOVER TABLESPACE users;RECOVER DATAFILE '/.../tbs.dbf';



830


En una recuperación automatizada, esta continúa hasta que todo el “redo” archivado y en línea se ha aplicado y aparece el mensaje: “media recovery complete”.

– Abrir la bd: ALTER DATABASE OPEN;

RECUPERACION



831

RECUPERACION COMPLETA.BD ABIERTA.

• Puede ocurrir un fallo con la bd abierta, dejando los ficheros no dañados en línea y en condiciones de uso. Oracle automaticamente pone los ficheros dañados fuera de línea -no sus “tablespaces”- si el DBWR no puede escribir en ellos.

Las consultas que no pueden leer en dichos ficheros generan errores, pero Oracle no los pone fuera de línea por esta razón:

ERROR at line 1:ORA-01116: error in opening database file 11ORA-01110: data file 11: '/oracle/dbs/tbs_32.f'ORA-27041: unable to open fileSVR4 Error: 2: No such file or directoryAdditional information: 3



832


• El proceso no es aplicable si se dañan los ficheros del tbsp.SYSTEM, en este caso se cierra la bd automáticamente.

1.- Preliminares.

– Poner los tbsp que contienen los ficheros dañados fuera de línea: ALTER TABLESPACE users OFFLINE TEMPORARY;

– Intentar corregir, si es posible, el fallo máquina que origina el error.

2.- Restaurar copias de los ficheros dañados o perdidos.

– No deben restaurarse copias de ficheros no dañados, “redo” en línea o ficheros de control. Si se han restaurado a una localización alternativa, deben renombrarse los ficheros de datos: ALTER DATABASE RENAME FILE'/.../tbs1.dbf' TO '/.../tbs1.dbf';

RECUPERACION



833


3.- Recuperar los tbsp. fuera de línea.

– Conectar con privilegios de administrador.

– Recuperar todos los tbsp. afectados (aconsejable automáticamente):

RECOVER TABLESPACE users, sales

La recuperación continúa hasta que todo el “redo” archivado y en línea se ha aplicado.

– Poner los tbsp. en línea:

ALTER TABLESPACE users ONLINE;ALTER TABLESPACE sales ONLINE;



834

RECUPERACION INCOMPLETA.

• Al no recuperar la bd al momento más actual, debe indicarse cuando terminar la recuperación (“point in tine recovery”). Existen diversas opciones:

– Time-based ... Recupera datos hasta un instante concreto.

– Cancel-based ... Recupera hasta el empleo de la sentencia CANCEL.

– Change-based ... Recupera hasta un SCN específico.

Tras una recuperación incompleta siempre debe abrirse la bd con “resetlogs”.

RECUPERACION



835


1.- Preliminares.

– Realizar una copia completa de la bd como medida de precaución ante errores durante la recuperación.

– Cerrar la bd, si está abierta: SHUTDOWN ABORT– Intentar corregir el fallo que origina el error.

2.- Restaurar una copia completa de la bd.

– Si el fichero de control actual no refleja la estructura de la bd en el tiempo al que se quiere recuperar, debe restaurarse una copia del mismo que lo haga.

– Restaurar copias de todos los ficheros de datos de la bd (previas al momento al que se quiere recuperar).

– Abrir una sesión Sqlplus como administrador.



836


– Montar la bd:STARTUP MOUNT

– Si algún fichero fue restaurado a una localización alternativa anteriormente, indicarlo:

ALTER DATABASE RENAME FILE '/.../df2.dbf' TO '/.../df2.dbf';

– Obtener el nombre y estado de todos ficheros de datos: SELECT NAME,STATUS FROM V$DATAFILE;

– Asegurarse de que todos los ficheros de la bd están en línea (a menos que un tbsp se hubiera puesto fuera de línea normalmente -opción NORMAL- o sea de sólo lectura):

ALTER DATABASE DATAFILE '/..../tbs.dbf' ONLINE;

RECUPERACION



837

RECUPERACION INCOMPLETA.“CANCEL BASED”.

• La recuperación finaliza al indicar “CANCEL” en lugar de un nombre de fichero “redo” archivado, o cuando todos estos han sido aplicados. Permite controlar el proceso de recuperación.

• Deben seguirse los siguientes pasos:

– Conectarse a Sqlplus con privilegios de administrador: sqlplus '/ AS SYSDBA'

– Montar la bd: STARTUP MOUNT– Comenzar la recuperación: RECOVER DATABASE UNTIL

CANCELSi se está usando una copia del f.de control debe

indicarse: RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE



838

RECUPERACION INCOMPLETA.“CANCEL BASED”.

– Continuar aplicando “redo” hasta llegar al último ycancelar ejecutando: CANCEL. Si el fichero de control es una copia deberá indicarse también los nombres del “redo” en línea si desean aplicarse.

Oracle devuelve un mensaje indicando si la recuperación fue exitosa. Si se cancela una recuperación antes de que todos los ficheros esten en un SCN consistente y se intenta abrir la bd, se recibe un ORA-1113 en caso de sernecesaria más recuperación. Puede consultarse la vista V$RECOVER_FILE para determinar si es así, o si una copia de algún fichero no fue restaurada antes de comenzar la recuperación.

– Abrir la bd en modo RESETLOGS. Siempre deben reiniciarse los “log” en línea después de una recuperación incompleta o con una copia del fichero de control:

ALTER DATABASE OPEN RESETLOGS;RECUPERACION



839

RECUPERACION INCOMPLETA.“TIME BASED”.

– Ejecutar RECOVER DATABASE UNTIL TIME paracomenzar. El tiempo siempre se indica usando el formato:'YYYY-MM-DD:HH24:MI:SS'. Por ejemplo:

RECOVER DATABASE UNTIL TIME '2004-12-31:12:47:30'

Si se usa una copia del fichero de control, restaurada:RECOVER DATABASE UNTIL TIME '2004-12-31:12:47:30'

USING BACKUP CONTROLFILE

– Aplicar “redo” archivado. Si el fichero de control es una copia, tras aplicar “redo” archivado debe indicarse el “redo” en línea. Finaliza automáticamente la recuperación al alcanzar el tiempo indicado y se devuelve un mensaje indicando si es correcta.

– Abrir bd en modo “RESETLOGS”: ALTER DATABASE OPENRESETLOGS;



840

RECUPERACION INCOMPLETA.“CHANGE BASED”.

– Indicar el SCN de terminación. Por ejemplo:

RECOVER DATABASE UNTIL CHANGE 10000;

– Aplicar “redo” archivado. Si el fichero de control es una copia, tras aplicar “redo” archivado debe indicarse el “redo” en línea. Finaliza automáticamente la recuperación al alcanzar el SCN indicado y se devuelve un mensaje indicando si es correcta.

– Abrir bd en modo “RESETLOGS”: ALTER DATABASE OPEN RESETLOGS;

RECUPERACION



841

RECUPERACION PARALELA.

• Por defecto se emplea recuperación paralela, lo que incrementa la productividad. El grado de paralelismo es igual al número de UCP´s disponibles, relacionado con el parámetro de inicialización CPU_COUNT.

• Si se indica “RECOVER PARALLEL” o “RECOVER PARALLEL 0” se evita este comportamiento.



842

APERTURA BD TRAS RECUPERACION.

• Siempre que se realiza una recuperación incompleta orecuperación con una copia del fichero de control, debe reinicializarse los “logs” al abrir la bd. La nueva versión de bd se llama “incarnation”. Todos los “redo” archivados generados tras el punto de RESETLOGS en la antigua “incarnation” son no válidos en la nueva.

• Al realizar una recuperación completa, no tiene que abrirse la bd con la opción RESETLOGS. Todos las copias y “redo”archivado creados durante la vida de esta “incarnation” de labd son válidos.

RECUPERACION



843




844


• Al abrir la bd con RESETLOGS, todos los f.datos obtienen un nuevo RESETLOGS SCN y fecha, y la secuencia de “log” se reinicia a 1.

El “log” archivado contiene asímismo esos dos valores en la cabecera. Como Oracle no aplica un “log” archivado a un fichero de datos a menos que RESETLOGS SCN y fecha coincidan, esta operación evita que se corrompan con “log” archivados que no son de “encarnaciones” padres directas de a actual.

• Reinicializar los “logs” permite:– Descartar para siempre cualquier información no aplicada

durante la recuperación.– Reinicializar la información en el fichero de control sobre

“redo” en línea y “redo” threads.– Crear los ficheros de “redo” en línea si no existían.– Reinicializar el número de secuencia de “log” a 1.

RECUPERACION



845


– Archiva “redo” en línea, si está accesible, y borra su contenido.

– Actualizar todos los ficheros de datos y “redo” en línea y, por tanto, el “redo” archivado que se produzca con un nuevo RESETLOG SCN y “time stamp”.



846


• Tras un RESETLOGS, es aconsejable:

– Realizar una copia completa de la bd, cerrándola en modo normal (permite recuperar cambios hechos tras la reinicialización).

– Comprobar que en el alert_SID.log no existen entradas que reflejen inconsistencias detectadas entre el dicconario de datos y el fichero de control (p.ej. Fich. datos que no aparecen en el fich. de control).

RECUPERACION



847

TSPITR



848

TSPITR (“Tbsp. Point in time recovery”).

• Junto con la funcionalidad de transporte de tbsp., permiterecuperar uno o más tbsp. (distintos al SYSTEM) a un momento en el tiempo anterior al resto de la bd. Es util para:

– Recuperar tras un borrado de tabla. Idem si está corrupta (¡es conveniente tener copia lógica!).

– Recuperar tras sentencias que han afectado a una parte de la bd (DML).

– Recuperar un esquema (si es independiente y reside en un tbsp aparte) a un punto diferente del resto.

– Recuperar un tbsp en una gran bd (VLDB -very largedatabase-) cuando es más eficiente que recuperar la bd al completo.

RECUPERACION



849

TSPITR.

• El desarrollo básico de un TSPITR consta de varios pasos:

– Operaciones preliminares y puesta fuera de línea de aquellos tbsp. que requieren recuperación.

– Creación de una bd auxiliar (duplicado de la bd en uso restaurada desde copia) y su recuperación hasta el momento necesario en el tiempo.

La bd auxiliar puede residir en la misma máquina que la bd en uso o en otra distinta. Se aconseja esta última opción por su mayor facilidad de manejo y menorprobabilidad de daño.

– Borrado de los tbsp que requieran TSPITR (bd en uso).

– Transporte del conjunto de tbsp. desde la bd auxiliarhasta la bd en uso.



850

TSPITR. PRELIMINARES.

1.- Debe comprobarse que se poseen las copias necesariasprevias al instante al que se desea el TSPITR; así como una copia del fichero de control realizada con ALTER DATABASE BACKUP CONTROLFILE TO '<fichero>';

Igualmente que hay suficiente espacio en disco y memoria para poder recuperar y arrancar la bd auxiliar.

Si el tbsp. a recuperar se ha renombrado debe asegurarse que el SCN para el TSPITR es posterior al momento en que fue renombrado (no puede hacerse en caso contrario, aunque puede realizarse un DBPITR a un SCN previo al renombrado -vuelve a su nombre anterior-).

2.- Obtener información de la bd en uso.

- Ficheros de datos, control y “redo” en línea (SELECT NAMEFROM V$DATAFILE UNION ALL SELECT MEMBER FROM V$LOGFILEUNION ALL SELECT NAME FROM V$CONTROLFILE;).

RECUPERACION



851


- Ficheros de datos del tbsp SYSTEM y del conjunto de recuperación (tbsp a recuperar).

SELECT t.NAME AS "reco_tbs", d.NAME AS "dbf_name" FROM V$DATAFILE d, V$TABLESPACE t WHERE t.TS# = d.TS#AND t.NAME IN ('SYSTEM', 'RECO_TBS_1', 'RECO_TBS_2');

- Ficheros de datos del tbsp de UNDO.

SELECT r.TABLESPACE_NAME AS "rbs_tbs", d.FILE_NAME AS "dbf_name" FROM DBA_ROLLBACK_SEGS r, DBA_DATA_FILES dWHERE r.TABLESPACE_NAME=d.TABLESPACE_NAME;

SELECT u.TABLESPACE_NAME AS "undo_tbs", d.FILE_NAME AS "dbf_name" FROM DBA_UNDO_EXTENTS u, DBA_DATA_FILES dWHERE u.TABLESPACE_NAME=d.TABLESPACE_NAME;



852


3.- Determinar los objetos que se perderán en el TSPITR.Cualquier objeto creado tras el instante al que se desea

recuperar se pierde. Para averiguar cuáles son , debe consultarse la vista TS_PITR_OBJECTS_TO_BE_DROPPED en la bd en uso.Por ejemplo, si se quiere recuperar “ventas1” y “ventas2” al

instante '2000-06-02:07:03:11':

SELECT OWNER, NAME, TABLESPACE_NAME, TO_CHAR(CREATION_TIME, 'YYYY-MM-DD:HH24:MI:SS')

FROM SYS.TS_PITR_OBJECTS_TO_BE_DROPPED WHERE TABLESPACE_NAME IN ('VENTAS1','VENTAS2') AND CREATION_TIME > TO_DATE('00-JUN-02:07:03:11','YY-MON-

DD:HH24:MI:SS')ORDER BY TABLESPACE_NAME, CREATION_TIME;

RECUPERACION



853


4.- Configurar la conexión a la bd auxiliar (Net) y, en su caso, crear el fichero de claves.

5.- Crear un fichero de parámetros de inicialización para la bd auxiliar.

Contendrá parámetros como: DB_NAME, CONTROL_FILES, LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_FORMAT, DB_UNIQUE_NAME, DB_FILE_NAME_CONVERT, LOG_FILE_NAME_CONVERT.

Parámetros de memoria como DB_CACHE_SIZE , SHARED_POOL_SIZE y LARGE_POOL_SIZE deben mantenerse a un valor bajo.



854

TSPITR. CREACION BD AUXILIAR.

• Se asume que se creará en una máquina distinta a aquella enque reside la bd en uso, y se usarán los mismos nombres de ruta (“path names”) para los ficheros.

1.- Restaurar los ficheros de la bd auxiliar (ficheros de control,“undo” y system), junto con el conjunto de recuperación -tbsp a recuperar-.

2.- Arrancar la bd auxiliar -sin montar-. Si es necesario indicarcuál es el fichero de parámetros de inicialización.

STARTUP NOMOUNT PFILE = /.../.

RECUPERACION



855


3.- Montar la bd auxiliar usando la claúsula CLONE (pone todos los ficheros de datos “offline” de forma automática).

ALTER DATABASE MOUNT CLONE DATABASE;

4.- Ejecutar la consulta siguiente para descartar cualquier error en el nombre de los ficheros de datos:

SELECT NAME FROM V$DATAFILE UNION ALLSELECT MEMBER FROM V$LOGFILE UNION ALLSELECT NAME FROM V$CONTROLFILE;

En caso de haber algún error deberán renombrarse (si no se ha usado DB_FILE_NAME_CONVERT y LOG_FILE_NAME_CONVERT).



856


5.- Poner todos los ficheros de datos en línea.

ALTER DATABASE DATAFILE /u02/.../system.dbf ONLINE;ALTER DATABASE DATAFILE /u02/.../ventas1.dbf ONLINE;ALTER DATABASE DATAFILE /u02/.../ventas2.dbf ONLINE;ALTER DATABASE DATAFILE /.../undo.dbf ONLINE;

TSPITR no funcionará si todos los ficheros del cjto. de recuperación no están en línea. En este momento la bd auxiliar está lista para recuperación.

6.- Recuperar la bd a un instante concreto con la opción USING BACKUP CONTROLFILE. Por ejemplo:

RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE

7.- Abrir la bd auxiliar con la opción RESETLOGS.

ALTER DATABASE OPEN RESETLOGS;

RECUPERACION



857

TSPITR. TRANSPORTAR TBSP.OPERACIONES BD AUXILIAR.

1.- Colocar los tbsp en modo sólo lectura.

ALTER TABLESPACE ventas1 READ ONLY;ALTER TABLESPACE ventas2 READ ONLY;

2.- Comprobar que el conjunto es autocontenido.

EXECUTE SYS.DBMS_TTS.TRANSPORT_SET_CHECK('ventas1,ventas2',TRUE,TRUE);

SELECT * FROM SYS.TRANSPORT_SET_VIOLATIONS;

3.- Generar el conjunto transportable (utilidad Data Pump Export).



858

TSPITR. TRANSPORTAR TBSP.OPERACIONES BD EN USO.

1.- Borrar los tbsp. del conjunto de recuperación.

DROP TABLESPACE ventas1 INCLUDING CONTENTS;DROP TABLESPACE ventas2 INCLUDING CONTENTS;

2.- Copiar los ficheros de datos de la bd auxiliar a la bd en uso, igual con el fichero resultado de la exportación (orden cp).

3.- Importar el conjunto transportado (utilidad Data Pump import).

4.- Cambiar modo de los tbsp. transportados a lectura/escritura.

ALTER TABLESPACE ventas1 READ WRITE;ALTER TABLESPACE ventas2 READ WRITE;

RECUPERACION



859

TSPITR. TRANSPORTAR TBSP.OPERACIONES BD EN USO.

5.- Realizar una copia de los tbsp. recuperados.

Debe realizarse copia pues de otra forma podrían perderse. Si, por ejemplo, ocurre un fallo de disco, y se intenta recuperar desde una copia anterior al TSPITR, esta falla.



860

VISTAS.

• V$ARCHIVED_LOG

• V$RECOVER_FILE ... Muestra el estado de los ficheros que precisan “media recovery”.

• V$RECOVERY_LOG

RECUPERACION



861

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.oracle-base.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



862

APENDICE B.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



863

APENDICE B.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 (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 DATABASEFLASHBACK on; ALTER TABLESPACE nombre FLASHBACK ON; FLASHBACKTABLE nombre TO SCN numero; FLASHBACK TABLE nombre TO TIMESTAMP'2006-03-03 12:05:00';;

• DROP DATABASE; (sólo montada)• ALTER DATABASE DEFAULT TABLESPACE nombre; • ALTER SYSTEM FLUSH BUFFER_CACHE;• Automatic Storage Management• 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; PURGETABLE NombreTabla;)

• ADDM. DBA_OUTSTANDING_ALERTS, DBA_ALERT_HISTORY, V$ALERT_TYPES.Script $ORACLE_HOME/rdbms/admin/addmrpt.sql.



864

APENDICE C.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



865

APENDICE C.Arquitectura Oracle



866

APENDICE D.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



867

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



868

ﾺ

APENDICE E.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



869

APENDICE F.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



870

APENDICE G.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



871

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 DD-MON-RRNLS_DATE_LANGUAGE AMERICANNLS_SORT BINARYNLS_TIME_FORMAT HH.MI.SSXFF AMNLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AMNLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZH:TZMNLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZH:TZMNLS_DUAL_CURRENCY $NLS_COMP BINARY

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



872

APENDICE H.NLS_TERRITORY Y NLS_LANGUAGE

El país (NLS_TERRITORY) lleva asociado un formato de fecha, y el lenguaje (NLS_LANGUAGE) se refiere al idioma en que nos responde Oracle.

SQL> SELECT SYSDATE FROM DUAL;SYSDATE---------30-MAR-05

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

SQL> SELECT SYSDATE FROM DUAL;SYSDATE--------30/03/05

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



873

APENDICE H.NLS_DATE_LANGUAGE

Podemos modificar el idioma de la fecha con NLS_DATE_LANGUAGE:

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

TO_CHAR(SYS-----------20/DIC/2004

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

TO_CHAR(SYS-----------20/DEC/2004



874

APENDICE IINTRODUCCION A ORACLE RAC

• Dos (o más) instancias accediendo a la misma BD.

• Cada instancia reside en un servidor independiente,manteniendo una conexión de alta velocidad a los discoscompartidos.

• La BD reside en los discos compartdos, y cada instanciamantiene (en dichos discos) sus propios ficheros de control yredo online.

• Un usuario es conectado a la BD mediante una de las intancias, ysi ésta cae, será reconectado automáticamente mediante otrainstancia del cluster.

• RAC provee alta disponibilidad (si no puedes perder más de 30minutos de caída, seguramente necesitas RAC), y también,escalabilidad.

• Más SO y más tráfico de red.

INTRODUCCIÓN A ORACLE RAC



875

ARQUITECTURA RAC.

INTRODUCCIÓN A ORACLE RAC Administración y Ajuste de Oracle 10g


876

REQUISITOS DE LOS NODOS

• Acceso a los discos compartidos (Oracle recomienda ASM o Automatic Storage Management).

• Dos tarjetas de red. Una IP privada y otra pública (Oracle proporciona VIPCA o Virtual IP Configuration Assistant).

• Soporte para TCP/IP y un sw de interconexión soportado por Oracle (Oracle proporciona Oracle Clusterware).

• Cada instancia tiene su propio init (pueden tener diferentes tamaños de sga, etc), y su propio UNDO y redolog online. Un mismo spfile permite configurar varias intancias:

– alter system set shared_pool_size=400M sid='INST01';• “Cache fusion”: la primera instancia q arranca es “lock master”

(LM), no configurable (es así Oracle6 Parallel Server). LM sabe qué bloques tiene cada instancia en su caché (global cache table). Si LM cae, otra instancia se convertirá en LM.

• Podemos monitorizar una instancia (V$SESSION) o las dos a la vez (GV$SESSION).

• Misma versión de SO, Oracle y arquitectura (32 ó 64 bits).




877

CLUSTER-READY SERVICES (CRS)

• CRS es el sw de cluster (clusterware) de Oracle. Soporta nodos de multitud de SSOO (Sun, HP, Tru64, AIX, Windows, Linux, etc). Todos los nodos deben tener el mismo SO y arquitectura (32 ó 64 bits)

• CRS tiene 3 componentes principales, en forma de “demonios” lanzados desde el “inittab” (Unix) o como servicios (Win): 1 como root y 2 oracle (fatal=si falla reinicia nodo, respawn=si falla reinicia proceso):

– Ocssd (oracle, fatal): cluster synchronization services daemon

– Crsd (root, respawn): mantiene la disponibilidad de los recursos

– Evmd (oracle, respawn): event logger daemon• En /etc/init.d estan: init.crs, init.crsd, init.cssd, init.evmd. CRS

se arranca/para con “/etc/init.d/init.crs start|stop” (desde root).



878

ORACLE CLUSTERWARE.

• Oracle Clusterware, OCW, requiere dos componentes,residentes ambos en un almacenamiento compartido:

– Un disco, “voting disk”, donde se recoge informaciónsobre los nodos miembros. Permite determinar las instancias miembros del “cluster” y debe residir en un disco compartido. Se recomienda disponer de varios discos de este tipo para garantizar una alta disponibilidad (en número impar).

– Oracle Cluster Registry (OCR) para registrarinformación sobre configuración del “cluster”, así como sobre cualquier bd en “cluster” y sobre los procesos que OCW controla. Debe residir en un disco compartido accesible a los nodos. Se recomienda que este multiplexado para garantizar una alta disponibilidad.




879

COMPONENTES CLUSTERWARE. PROCESOS.

• Cluster Synchronizaton Services (CSS) -proceso ocssd-. Controla quienes son miembros del “cluster” y avisa a los nodos cuando alguno de ellos abandona o ingresa en el mismo.

• Cluster Ready Services (CRS) -proceso crsd-. Programa principal para gestionar la alta disponibilidad en un “cluster”. Gestiona los recursos del “cluster” basándose en la información almacenada en el OCR (por ejemplo arranque, parada, monitorizacion y otras operaciones). CRS monitoriza la instancia, el listener... y automáticamente reinicia dichos componentes cuando ocurre un fallo (por defecto lo intenta cinco veces como máximo).

• Event Management (EVM) -proceso evmd-. Proceso “background” que publica los eventos que crea CRS.

• Oracle Notification Service (ONS). Servicio para comunicar eventos FAN (Fast Application Notification).



880


• RACG. Extensión que ejecuta “scripts” cuando ocurren eventosFAN.

• Process Monitor Daemon (OPROCD) -proceso oprocd-. Procesoresidente en memoria para monitorizar el “cluster”, su fallo provoca el rearranque del nodo.




881


• Para asegurar que cada instancia del RAC obtiene el bloquenecesario para satisfacer una petición, las instancias RAC usan los procesos Global Cache Service (GCS) y Global Enqueue Service (GES).

• Estos procesos mantienen registros de los estados de cada fichero de datos y cada bloque usando el Global Resource Directory (GRD), el cual está distribuido a través de todas las instancias activas.

• Después de que una instancia accede a datos, cualquier otra instancia en el “cluster” puede realizar una imagen del bloque desde otras instancia en la bd (Cache Fusion) lo que es más rápido que volver a leer en disco.



882


• A lograr el funcionamiento anteriormente mencionadocontribuyen el Global Resource Directory (GRD) y los procesos específicos de RAC:

– LMS, proceso Global Cache Service– LMD, proceso Global Enqueue Service– LMON, proceso Global Enqueue Service Monitor– LCK0, proceso Instance Enqueue

• VIPs (Virtual IP Addresses). Cada nodo, además de su ip estática, tiene una ip “virtual”, en la q escuchará el listener de cada nodo, y a la q accederán los clientes. Si un nodo falla, su VIP será levantada por otro nodo, no con el objetivo de q se sigan conectando los clientes a través de dicha VIP, sino q larespuesta será q no hay instancia activa en dicha VIP, para q el cliente intente conectarse a otra.




883

CACHE FUSION

• La primera instancia en arrancar se convierte en Lock Master (LM). Si esta cae, otra será la nueva LM (¿cuál?).

– INSTA: hola LM, quiero leer el bloque 625– LM: nadie lo tiene, léelo de disco– LM actualiza su tabla, ya sabe q INSTA tiene el bloque– INSTA lee el bloque– INSTB: hola LM, quiero leer el bloque 625– LM: espera, INSTA lo tiene, ahora le digo q te lo envíe– LM sabe q INSTA e INSTB tienen el bloque– INSTA envía el bloque a INSTB– INSTB: hola LM, quiero modificar el bloque 625– LM informa a INSTA q su versión del bloque 625 queda

invalidada– LM sabe q INSTB tiene el bloque 625 (válido)– LM: haz tu modificación

• Este mecanismo consume CPU y tráfico de red. Por otro lado, es más rápido leer un bloque de la red q del disco.



884

INTALAR RAC

• Puedes montar RAC hasta con 4 nodos con 1 CPU, o hasta 2nodos con 2 CPUs, con la licencia Oracle Database Standard Edition. Si quieres más hay q pasar a la licencia Oracle Database Enterprise Edition.

• Primer paso: usar OUI (Oracle Universal Installer) para instalarCRS (Cluster Ready Services). Lo proporciona Oracle 10g para la gestión del cluster. Con CRS se puede:

– Definir servicios para distribuir la carga entre nodos.– AWR recoge estadísticas sobre estos servicios.

• Segundo paso: instalar el software del servidor de BD Oracle con RAC (usando OUI), en un ORACLE_HOME diferente al de CRS.




885

RECUPERACIÓN DE LA INSTANCIA

• Cada instancia tiene su propio UNDO tablespace y redolog online.

• Si una instancia cae la otra se encarga de recuperarla (leer y aplicar redolog online).

• Si las dos instancias caen, la primera q arranque hará el recovery de todas las transacciones.



886

PARADAS POR MANTENIMIENTO

• Actualizaciones del SO: cero parada (si las aplicaciones soportan RAC, claro). Se procede nodo a nodo, de modo q el cluster no se para.

• Actualizaciones de Oracle:

– Critical Patch Update: cero parada (esto será así para cualquier parche q sólo actualice el sw, y no el DD de la BD).

– Patchsets (10.2.0.2 a 10.2.0.3) y releases (10g R1 a R2). Hay q parar todos los nodos, pues hay q actualizar el DD de la BD. En este caso el tiempo de parada puede ser mayor q sin RAC, puesto q hay q parar igualmente, y actualizar el sw en todos los nodos.

• De nada sirve RAC si no hay redundancia también a nivel del servidor de aplicaciones, así como de la red q lo conecta al RAC.




887

FLASH RECOVERY AREA

• La “flash recovery area” (FRA) será la misma para todas las instancias del RAC. Para ello la situaremos en los discos compartidos, y asignaremos los parámetros DB_RECOVERY_FILE_DEST y DB_RECOVERY_FILE_DEST_SIZE con los mismo valores, en todas las instancias.



888

EJEMPLO DE INSTALACIONORACLE RAC

• 4 nodos Blade HP G2:

– Cpu BL20p (2cpus hiperthreading)– RAM 5Gb– 4 tarjetas de red gigabit, en dos grupos (se usan dos para las

redes pública y privada del cluster, y hay otras dos q les dan alta disponibilidad).

• SAN EVA 5000 de HP– Conexión de fibra al cluster.– 150Gb para la BD y 200Gb para el área de Flash (incluye

backups)• SO Linux Red Hat Advanced Server 3 (van a migrar a RHEL4).

Todos los nodos deben tener el mismo.




889

EJEMPLO DE INSTALACIONORACLE RAC

• Oracle 10g R1 (10.1.0.5) y están migrando a 10g R2 (10.2.0.3)

– sga_target=800M– sga_max_size=3G– pga_aggregate_target (por defecto, para ellos, son 228M)– Spfile en ASM– Processes=600 (han medido un máximo de 1200 en total,

unos 300 por nodo).• ASM (la versión q se corresponde con el Kernel).

“/etc/init.d/oracleasm listdisk”. ASM necesita RMAN para backups. Ver manual “ASM best practices”. Instancias ASM con pfiles (init).

• OCR y Voting Disk en rawdevices (/etc/sysconfig/rawdevices). Copias de seguridad con “dd”.

• OEM Grid Control con una agente en cada nodo.


cursodba10g_atica_completo4dpp

Documents

compatible

automatic

perdida de

funcin de

htmlinstalacin

de grano fino

modificacion

real application