Guía de Tareas Practico Final PDF

PRACTICO FINAL. AR-UTNME-DBA2.
11g-183-LNCISCO
GUÍA DE TAREAS
A. Creación de una Base de Datos
1) Práctica de Creación de la Base de Datos
A. Para la creación manual (sin usar DBCA) a través de la sentencia créate data base
B. Si desea crear una base de datos utilizando otras herramientas de línea de comandos, puede usar el script
BUILD_DB.SQL ubicado en ORACLE_HOME/admin
C. Priperos pasos
D. Baje la instancia SID, elimine todo vestigio de la base de datos SID creada. Usando el DBCA, recree la base de
datos sirio usando el template que existe para ella.
2) Cálculo de Volúmenes de una Base de Datos
B. Mantenimiento de la Base de Datos
1) Crear Tablas
2) Crear Un Tablespace
3) Compactar Un Tablespace
4) Eliminar Un Tablespace
5) Adición De Un DataFile
6) Ampliar El Tamaño De Un DataFile
7) Mover Un Tablespace
8) Mover Un DataFile
9) Activar el Modo Seguro de Transacción (ARCHIVE)
10) Creación de Índices
11) Modificación de Índices
12) Monitoreo de Índices
13) Borrado de Índices
14) Crear un grupo de Redo Log Files
15) Eliminar un grupo de Redo Log Files
16) Adicionar un elemento a un grupo de Redo Log Files
17) Eliminar un elemento de un grupo de Redo Log Files
18) Trasladar un elemento a un subgrupo de Redo Log Files
19) Crear ENLACES de base de datos
20) Crear SECUENCIAS
USO DE LA PÁGINA MANAGE OPTIMIZER STATISTICS
RECOPILACIÓN MANUAL DE ESTADÍSTICAS DEL OPTIMIZADOR
REPOSITORIO DE CARGA DE TRABAJO AUTOMÁTICA (AWR)
MARCO DE ASESORAMIENTO
C. Seguridad de la Base de Datos
1) Seguridad de Accesos
2) Creación y autenticación de Usuarios
A. Crear usuarios
B. Crear usuarios por medio del EM (Enterprise Manager)
C. Modificar un Perfil
D. Eliminar Usuario
E. Modificar Usuario
F. Dar privilegios a un Usuario
G. Quitar privilegios a un Usuario
H. Crear un Rol
I. Modificar un Rol
J. Eliminar un Rol
K. Asignar un Rol a un Usuario o Rol
3) Autenticación de Usuarios
A. Autenticación por medio del SO Linux XE
B. Autenticación por medio del SO Windows
C. Funciones de verificación de contraseñas.
CESARI M. PROYDESA – DBA2 pág. 1

PRACTICO FINAL. AR-UTNME-DBA2.11g-183-LNCISCO
D. Respaldo de la Base de Datos

1) Activar o desactivar el MODO ARCHIVELOG de base de datos Oracle
2) Backups en frio:
3) Backups en caliente:
4) Respaldo de archivos de control mediante archivos de rastreo
5) Respaldos empleando el administrador de recuperación de Oracle
6) Backups lógicos (Desde línea de Comandos):
7) Backups desde Enterprise Manager EM
E. Recuperación de la Base de Datos
1) Recuperación de la BD
2) Recuperación de un Tablespace
3) Recuperación de un Datafile
4) Recuperacion de backups lógicos:
5) Importar un export incremental:
6) Recuperación de una Tabla
7) Recuperación de una Bitácora
8) Recuperación de un Archivo de Control
RECUPERACIÓN DESDE ENTERPRISE MANAGER:
GESTOR DE RECUPERACIÓN DE ORACLE RMAN
F. Gestión de Transacciones
1) Definición de transacciones en SQL:
2) Comprobación de la integridad en SQL:
G. Gestión de los componentes de la Memoria
1) Activación de la Gestión Automática de Memoria (AMM)
2) Activación de la Gestión Automática de Memoria Compartida (ASMM)
3) Asesor de Gestión Automática de Memoria Compartida
H. Análisis de rendimiento en Oracle STATSPACK
1) ¿Cómo se instala?
2) ¿Cómo se recopilan las estadísticas?
3) ¿Cómo se genera un reporte?
4) Tomar nuestra primera snapshot.
5) Listar todas las snapshots de nuestra base de datos.
6) Borrar snapshots.
7) Ajustar el nivel de detalle de las snapshots.
8) Programar la toma de snapshots.
9) Creación de informes.
INCIDENCIAS MÁS FRECUENTES QUE AFECTAN AL RENDIMIENTO DE LA INSTANCIA.
ANÁLISIS DEL INFORME GENERADO POR STATSPACK
PÁGINA RENDIMIENTO DE ENTERPRISE MANAGER
HERRAMIENTAS MÁS INTERESANTES EN ORACLE ENTERPRISE MANAGER
I. Gestión de Estadísticas de Rendimiento Dinámicas
1) Visualización de Estadísticas del Sistema
2) Vistas de Solución de Problemas y de Ajustes
3) Objetos No Válidos o No Utilizables

A. Creación de una Base de Datos

Para la creación de una base de datos se deben tomar en cuenta tres aspectos para lograr los mejores
resultados a la hora de su implementación, estos aspectos son los siguientes:
 Se debe seleccionar el mejor modelo que se adapte a las neceades de la empresa.
 Se debe buscar que el rendimiento de la base de datos sea el más óptimo.
 Se debe realizar un adecuado cálculo de los volúmenes que manejara la base de datos.
1. Seleccionar el modelo de la base de datos: Escoger un modelo para la base de datos acorde con la
estructura de la organización proporcionara una estabilidad para obtener los dos restantes aspectos.
2. Optimizar el rendimiento de la base de datos: Para implementar un buen rendimiento tanto a nivel
lógico como físico, es necesario hacer un estudio de la estructura interna y de las operaciones propias
de la empresa. Además, se deben utilizar los siguientes criterios de eficiencia para lograr el mejor
rendimiento posible: . Evitar la contención: para que los recursos puedan ser usados por los usuarios,
en el menor tiempo posible.
 Reducir la fragmentación: para disminuir el número y el tiempo de las lecturas cuando se busca
información de manera constante.
 Optimizar los procesos: para mantener el rendimiento en un nivel adecuado.
 Separación de Segmentos: realizar este procedimiento permite: hacer respaldos y recuperaciones de
forma apropiada, facilitar la obtención de los datos, mejorar la seguridad de los datos y optimizar el espacio
de almacenamiento.
3. Cálculo de volúmenes: Separar apropiadamente el espacio físico de la memoria y visualizar la
cantidad de recursos que se van a utilizar, ayudara a tener un acceso rápido a los datos. Calcular el
espacio más indicado para cada segmento de memoria o de almacenamiento en la base de datos,
requiere conocer las políticas propias de cada organización. De esta manera se podrán definir
adecuadamente el tamaño inicial y el crecimiento de todos los segmentos (tablespace, índices, logs,
controles, etc) que se van a utilizar constantemente para las operaciones normales de toda empresa.
1) Práctica de Creación de la Base de Datos

Para crear una base de datos Oracle se debe tener la siguiente información:
1. Ubicación del archivo INIT.ORA
2. Nombre y tamaños de los tablespaces a crear
3. Estructura del servidor creada (discos duros, conexiones FTP, etc)
Si queremos iniciar una base de datos creada por nosotros, es necesario contar con la ubicación del
INIT.ORA, una vez tengamos la ruta ejecutamos la siguiente instrucción: SQL> STARTUP PFILE=@ruta
Podemos usar las siguientes herramientas para crear una base de datos: Oracle Database Assistant DBCA,
línea de comando con Sqlplus y BUILD_DB.SQL script
A. Para la creación manual (sin usar DBCA) a través de la sentencia créate data base
a. Defina nombre de la variable de entorno de instancia ORACLE
b. Preparación de archivo de parametros init.ora, cambiando los parámetros de acuerdo al modelo
seleccionado para la base de datos.
*.audit_trail=’db’ # se guardará auditoria en la base de datos, tabla AUD$
*.compatible=’11.2.0.0.4′ # parámetro que define compatibilidad con versiones previas de oracle
*.control_files=’/u01/app/oracle/oradata/SID/control01.ctl’, ‘/u02/oradata/SID/control02.ctl’
# nombre y ubicaciones de archivos de control
*.db_block_size=8192 # tamaño bloque de la BD que se creará. No se puede modificar una vez creada la BD
*.db_domain=’usrSID.cl’ # dominio para el nombre global de la base de datos
*.db_name=’SID’ #nombre de la base de datos
*.db_recovery_file_dest=” #directorio de la flash recovery area
*.db_recovery_file_dest_size=4039114752
*.diagnostic_dest=’/u01/app/oracle’
# directorio de los archivos de diagnóstico, entre ellos el archivo de alerta alert_SID.log, (nuevo release 11g)

*.dispatchers='(PROTOCOL=TCP) (SERVICE=SIDXDB)’
*.job_queue_processes=1000
*.log_archive_format=’SID_%t_%s_%r.dbf’
*.memory_target=422576128 #define tamaño de la SGA y PGA, parametro nuevo release 11g
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile=’EXCLUSIVE’
*.undo_tablespace=’UNDO_SID_TBS’
c. En el directorio home de oracle crear archivo “crea_SID_db.sql”
CREATE DATABASE nombre_base_nueva
USER SYS IDENTIFIED BY usuario_Administrador
USER SYSTEM IDENTIFIED BY usuario_Administrador
LOGFILE GROUP 1 (‘/u01/app/oracle/oradata//redo01a.log’, ‘/u02/oradata/SID/redo01b.log’) SIZE

100M,
GROUP 2 (‘/u01/app/oracle/oradata/SID/redo02a.log’, ‘/u02/oradata/SID/redo02b.log’) SIZE 100M,
GROUP 3 (‘/u01/app/oracle/oradata/SID/redo03a.log’, ‘/u02/oradata/SID/redo03b.log’) SIZE 100M
— 3 grupos con dos miembros cada grupo
MAXLOGFILES 5 — la base de datos puede tener hasta 5 grupos de redolog
MAXLOGMEMBERS 5 — cada grupo puede tener hasta 5 miembros
MAXLOGHISTORY 1000 — To view how often log switches occur in your database, you can query the
dynamic performance view V$LOG_HISTORY
MAXDATAFILES 100 — cantidad maxima de datafiles en la BD
CHARACTER SET WE8ISO8859P1 — set de caracteres para español
NATIONAL CHARACTER SET AL16UTF16 — set de caracteres para columnas NCHAR, NLOG, (japones,
coreano, chino, etc)
EXTENT MANAGEMENT LOCAL — tablespace SYSTEM tiene administracion de extents local
DATAFILE ‘/u01/app/oracle/oradata/SID/system01.dbf’ SIZE 100M REUSE AUTOEXTEND ON NEXT
16M MAXSIZE UNLIMITED –datafile de tablespace system
SYSAUX DATAFILE ‘/u01/app/oracle/oradata/SID/sysaux01.dbf’ SIZE 325M REUSE –datafile de
tablespace sysaux
DEFAULT TABLESPACE users –tablespace default de la base de datos, en este caso USERS
DATAFILE ‘/u01/app/oracle/oradata/SID/users01.dbf’– datafile asociado al tablespace USERS
SIZE 20M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
DEFAULT TEMPORARY TABLESPACE tempts1 — temporary tablespace de la base de datos
TEMPFILE ‘/u01/app/oracle/oradata/SID/temp01.dbf’ –tempfile del tablespace temporal default
SIZE 100M REUSE
UNDO TABLESPACE undo_SID_tbs –tablespace de UNDO, para guardar las imagenes que permiten
realizar ROLLBACK
DATAFILE ‘/u01/app/oracle/oradata/SID/undo_SID_tbs01.dbf’
SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
d. Asegúrese que TODOS los directorios referenciados en los archivos init.ora y crea_SID_db.sql
existan
e. Inicie la base de datos en estado NOMOUNT
f. Ejecute el archivo de comandos @crea_SID_db.sql
g. Consulte las vistas v$datafile, v$controlfile, DICTIONARY, V$tablespace y DBA_TABLESPACES,
v$fixed_tables, v$log, v$logfile
h. Ahora desde la consola de administración con la base de datos abierta procederá a crear el
catalogo (diccionario) y la opción procedural (PL/SQL) @/admin/catalog.sql
i. Ejecutar el archivo @/admin/catproc.sql
j. Consulte las vistas DBA_USERS, DBA_REGISTRY, DBA_TABLESPACES
B. Si desea crear una base de datos utilizando otras herramientas de línea de comandos, puede
usar el script BUILD_DB.SQL ubicado en ORACLE_HOME/admin
a. Defina nombre de la variable de instancia ORACLE_SID
b. Preparación de archivo de parametros init.ora, cambiando los parámetros de acuerdo al modelo
seleccionado para la base de datos.
c. Modificar el archivo build_db.sql, ajustando los parámetros a las necesidades de la empresa.

d. Deshabilitar cualquier instancia que se esté usando

e. Inicie la base de datos en estado NOMOUNT
f. Ejecute el archivo de comandos build_db.sql
g. Ejecutar el archivo catalog.sql,
h. Ejecutar el archivo catproc.sql
C. Priperos pasos
a. Crear 2 tablespaces usrSID_DATA y usrSID_INDEX con administración de extents local
sql> create tablespace usrSID_data
datafile ‘/u02/oradata/SID/usrSID_data01.dbf’ size 100m
autoextend on next 5m maxsize 200m extent management local ;
sql> create tablespace usrSID_index
datafile ‘/u02/oradata/SID/usrSID_index01.dbf’ size 100m
autoextend on next 5m maxsize 200m extent management local ;
b. Crear dos usuarios llamados usrsid1 Y usrsid2 con password “usrsid”, con default tablespace
usrsid_data
sql> create user usrSID1 identified by usrSID default tablespace usrSID_data;
sql> create user usrSID2 identified by usrSID default tablespace usrSID_data;
c. Busque y analice el archivo de alerta. Qué eventos fueron registrados en él
d. ¿Cómo verificaría que la base de datos está formateada en bloques de 8K?
e. Resuelva el problema de privilegios. Desde una consola de administración
sql> grant connect, resource to usrSID1, usrSID2
El rol CONNECT se les entrega a los usuarios finales, en este rol existe el privilegio de crear
sesiones. El rol RESOURCE se le entrega a los desarrolladores, para puedan crear tablas, vistas,
secuencias, etc. en su esquema.
f. En el usuario usrSID1 crear la tabla SID que a continuación se indica
sql> create table test (id number (38) not null, text varchar2 (40),
constraint test_pk primary key ( id ) using index
tablespace usrSID_index pctfree 10
storage ( initial 65536 next 65536 pctincrease 0 minextents 2))
tablespace usrSID_data
pctfree 10
initrans 1
maxtrans 255
storage (initial 65536 next 65536 pctincrease 10 minextents 1 maxextents 2147483645)
g. ¿Cuantos segmentos se crearon con la sentencia anterior, y de qué tipos? Consulte la vista
USER_SEGMENTS
h. ¿En qué tablespace se creó el índice? ¿ En qué tablespace se creó la tabla?. Anote esta información
para comparar más adelante.
i. ¿ Cuantos extents tiene cada segmento ? De qué tamaño se creó cada extent tanto en el índice como
en la tabla. Consulte la vista USER_EXTENTS
j. Borre la tabla test
sql> drop table test purge;
k. En el usuario usrSID1 crear la tabla test que a continuación se indica
sql> create table test (id number (38)not null, text varchar2 (40), constraint
test_pk primary key ( id ) )
l. ¿Cuantos segmentos se crearon con la sentencia anterior, y de qué tipos? Consulte la vista
USER_SEGMENTS
m. ¿En qué tablespace se creó el índice? ¿ En qué tablespace se creó la tabla?. Explique la comparación
con el caso anterior.
n. ¿Cuantos extents tiene la tabla TEST? Consulte la vista USER_EXTENTS
sql> select extent_id, bytes , blocks from user_extents where segment_name=’test’
o. Llenar el registro correspondiente de la creación de la base de datos.
¿Cuantos grupos de redolog tiene la base de datos?
¿Cuantos archivos de redolog tiene la base de datos?
¿Cuantos miembros tiene cada grupo?

¿Cuantos tablespaces tiene su base de datos?
¿Qué usuarios existen en su base de datos?
¿Qué tamaño tiene el tablespace system (originalmente se creó con tamaño inicial de 100M)?
TableSpace Fecha de Creación Tamaño Inicial Crecimiento Tamaño Máximo Observaciones
Control Files Fecha de Creación Tamaño Inicial Crecimiento Tamaño Máximo
Log Files Fecha de Creación Tamaño Inicial Crecimiento Tamaño Máximo
D. Baje la instancia SID, elimine todo vestigio de la base de datos SID creada. Usando el DBCA,
recree la base de datos sirio usando el template que existe para ella.
2) Cálculo de Volúmenes de una Base de Datos

a. Contar el número de tablas que posee el modelo de la base de datos a crear.
b. Contar el número de registros que posee cada una de las tablas.
c. Calcular el tamaño de cada una de las tablas del modelo de la base de datos.
d. Calcular el tamaño de cada uno de los registros de las tablas.
e. Sumar al tamaño de cada tabla, el tamaño de las llaves primarias y foráneas.
f. Calcular el tamaño de cada una de las relaciones de los procesos sustantivos.
g. Calcular el tamaño de cada una de las relaciones de los procesos de apoyo.
h. Sumar todos y cada uno de los valores anteriores, para obtener el tamaño total de la base de datos
en KB.
i. Dividir el la cantidad obtenida en el paso anterior entre 1 048 576, para obtener el tamaño total
de la base de datos en MB.
j. Asignar el tamaño inicial a la base de datos, dependiendo de su tamaño total.
k. Indicar el nivel de crecimiento anual de la base de datos, en múltiplos que un lapso aproximado de
5 años alcance el tamaño total de la misma.
l. Llenar el registro correspondiente del cálculo de los volúmenes de la base de datos.
Porcentaje Tamaño
Nombre de Cantidad de Tamaño de Tamaño de
Crecimiento Total de la Observaciones
la Tabla Registros Registros (KB) Tabla (KB)
Anual (%) Tabla (MB)

B. Mantenimiento de la Base de Datos

Las bases de datos realizan una serie de procesos para garantizar la integridad de los datos y la
consistencia de los archivos del sistema operativo. Es por ello que la simple acción de arrancar una base
de datos se convierta fácilmente en N pasos intermedios de los cuales debemos conocer a profundidad
para detectar errores cuando se nos presenten.
Antes de iniciar una base de datos, debemos estar conectados al SGBD mediante un usuario con rol de
super administrador. Solamente este usuario es capaz de arrancar y apagar la base de datos. El nombre
de usuario super administrador en Oracle se denomina sys.
El primer paso para iniciar una base de datos, es autentificarnos como super administrador. Para ello
ejecutamos la siguiente instrucción en la consola de Oracle: SQL> CONNECT sys/root as SYSDBA
Una vez nos salga el mensaje de Conectado exitosamente, debemos escribir la siguiente instrucción:
SQL> STARTUP OPEN;
Oracle primeramente lee el archivo init.ora, localiza los ficheros de control, crea e inicia al SGA y arranca
todos los procesos. En este punto la base de datos esta arrancada.
Estos datos significan que el SGA fue instanciado correctamente en el servidor. Sin embargo la base de
datos ha pasado por tres estados previos antes de estar lista para recibir consultas. La instrucción
STARTUP OPEN realmente realiza tres instrucciones (nomount, mount y open) antes de estar disponible
para el DBA. Desde luego el DBA también puede instanciar una base de datos en un estado intermedio con
las siguientes instrucciones:
 NOMOUNT. La instrucción de nomount se utiliza cuando se crea una base de datos o cuando, debido
a una falla física se ha pedido un archivo de control. Para iniciar una base de datos en modo
NOMOUNT se debe ejecutar la siguiente instrucción: SQL> STARTUP NOMOUNT;
 MOUNT. El estado de MOUNT abre los ficheros de control para localizar los ficheros de datos y los
redo log, pero no se realiza ninguna comprobación de ellos en este momento. Luego bloquea la
instancia para evitar intervenciones de otras instancias. Se utiliza la siguiente instrucción para
montar la base en modo Mount: SQL> STARTUP MOUNT;
Para pasar de una base de datos en estado NOMOUNT a un estado MOUNT basta ejecutar la siguiente
instrucción: SQL> ALTER DATABASE MOUNT;
Existen muchas razones por las que los DBA necesitan montar la base en modo mount, entre las
principales están las modificaciones a la base de datos como:
1. Efectuar recuperaciones
2. Poner Offline/online un tablespace
3. Recolocar los ficheros de datos y redo log.
4. Crear/borras/modificar un nuevo grupo o miembro de redo log.
 OPEN. El estado de OPEN, bloquea los ficheros de datos y abre todos los ficheros redo log. Si la
instancia abre una Base de datos que se cerró de forma anormal, entonces el proceso OPEN recupera
de los redo log el estado de consistencia mas reciente y pone en línea la base de datos.
Para iniciar una base de datos en modo OPEN se debe ejecutar:
SQL> ALTER DATABASE OPEN;
SQL> STARTUP OPEN;
Detener una base de datos, va depender el estado en la que se encuentre. Existen tres formas diferentes
de apagar una base de datos. La sintaxis es la siguiente:
SQL> SHUTDOWN [normal | immediate | abort];
 Shutdown Normal. La operación de pagado normal, realiza las siguientes acciones en orden: se
impide el acceso a la base de datos (se bloquea), espera a que todos los usuarios completen todas sus
peticiones y se desconecten del servidor. Purga todos los buffers de datos y cachés de redo log,
actualizando los ficheros de datos y de redo log, se eliminan los bloqueos de ficheros, se completan
las transacciones en marcha, se actualizan las cabeceras de ficheros, elimina los threads, libera los
bloqueos de la BD por parte de la instancia, y sincroniza los ficheros de control y de datos.

 Shutdown Immediate. El proceso de detención de la base de datos mediante el immediate, termina

todos los procesos de la base de datos en curso, para ello realiza un rollback a todas las transacciones
no confirmadas. Luego la BD es detenida. Una desventaja de este mecanismo de apagado es que los
usuarios son expulsados, la ventaja es que la BD queda en un estado consistente y si errores.
 Shutdown abort. Es el último recurso a utilizar, debe ser usado solamente cuando los demás
mecanismos fallas. Por ejemplo ante la caída de un proceso que impida el apago normal. Este modo
de apagado tiene la característica que aborta todas las transacciones incluyendo las que se están
realizando en un momento dado. No se realizan rollback a las transacciones abortadas, es por ello
que la BD queda en un estado de inconsistencia, que debe ser reparado con los redo log la próxima
vez que la BD inicie.
Para el MANTENIMIENTO DE LOS COMPONENTES DE LA BASE DE DATOS es recomendable realizar un estudio
previo de la empresa, para así verificar el funcionamiento de estos componentes y para determinar si
existe sobresaturación de la información, esto con el fin de tener una idea más clara de lo que puede
hacerse sobre la base de datos para que esta esté optimizada.
Es muy importante que antes de realizar cualquier cambio en la base de datos esta se debe respaldar,
para así evitar cualquier inconveniente.
Dentro de los procesos de mantenimiento de una base de datos se encuentran:
1. Mantenimiento de Tablespaces
 Inspeccionar periódicamente el tamaño usado por los tablespaces (debe existir un límite).
 Se deberán tener parámetros para medir el nivel de saturación. Algunos de estos parámetros son:
- VME: volumen máximo esperado de transacciones que recibe la organización.
- HWM (High Water Mark): porcentaje que marca el límite de ocupación del tablespace (indispensable).
- PR (Periodicidad de Revisiones del consumo de un tablespace): deben hacerse reportes semanales.
Los procesos de mantenimiento para los tablespaces son los siguientes:
 Creación de tablespace: se crea por las siguientes razones: Los datos se ubican en un solo objeto.
Se reserva espacio para llenarlo posteriormente.
Para llevar a cabo la creación:
 Compactación de Tablespace: se debe realizar un monitoreo de los tablespace, dependiendo
de los resultados dados por los parámetros anteriormente mencionados, la Compactación se
realizara.
 Eliminación de Tablespace: En caso de que el tablespace ya no sea necesario se elimina.
 Mover Tablespace: los segmentos construidos sobre el un tablespace, difícilmente consiguen
liberar el espacio contiguo al final de los ficheros, por lo que se debe mover el tablespace.
 Adición de Datafile: se realiza por las siguientes razones: Para almacenar la información. Para
evitar la fragmentación de la información. Para aumentar el tamaño del tablespace.
Para realizar la adición
 Ampliación de Datafile: si se desea aumentar el tamaño de un DataFile
 Mover Datafile: para realizar el movimiento de un DataFile hacia otro directorio.
Taxonomía de un procedimiento almacenado

Todo procedimiento almacenado en Oracle es precompilado y almacenado en la pool del SGA para
su pronta y rápida ejecución.

Sin por ejemplo, queremos realizar un procedimiento para que inserte en la tabla t1 es necesario
ejecutar el siguiente código en la consola de sqlplus:
REATE TABLE T1 (A int ) tablespace users;
CREATE OR REPLACE PROCEDURE PRC001(Xa IN INT) IS
BEGIN
INSERT INTO t1 VALUES(Xa);
COMMIT;
END PRC001;
Sin queremos ejecutar un procedimiento ya creado previamente debemos encerrarlo entre un
bloque begin… end, como se expresa en el siguiente código:
BEGIN
PRC001(5);
END;
Supongamos que se nos ha contratado para crear un procedimiento almacenado capaz de desactivar
un tablespace
CREATE OR REPLACE PROCEDURE PRC003 (Xnombre IN varchar2)
IS
sql_dinamico varchar2(1000);
BEGIN
sql_dinamico := 'ALTER TABLESPACE :nombre offline';
EXECUTE IMMEDIATE sql_dinamico USING Xnombre;
END PRC003;
2. Modo Seguro de Transacciones. El modo seguro de Transacciones permite que la base de datos
realice respaldos automáticos de todas sus bitácoras sin necead de deshabilitarla. Cada vez que una
bitácora alcanza su capacidad máxima de almacenamiento se produce un cambio de bitácora, es
decir, los datos pasan a otra bitácora con más capacidad en la cual se almacenaran. Esto permite que
la base de datos trabaje 24x7, o sea, que no se tenga que deshabilitar para realizar respaldos en las
bitácoras. Se recomienda establecer el modo seguro de transacción desde el inicio de la instalación
de la base de datos, ya que, así asegurará los respaldos de la misma.
3. Índices. Un índice es una estructura diseñada para obtener un acceso más rápido a los datos
contenidos dentro de una tabla. Es independiente de los datos almacenados en la tabla y cuando se
encuentra bien definido reduce significativamente la búsqueda, aumentando el rendimiento, oracle
utiliza árboles tipo B+ para balancear el tiempo de acceso a cualquier fila. Inmediatamente luego de
crear el índice, este comienza a mantenerse al tanto de las inserciones, actualizaciones y
eliminaciones de registros de la tabla en la cual se ha implementado.
Los índices se utilizan para mejorar el rendimiento de consultas en un table. El uso indiscriminado de
índices tienen seria desventajas tanto es espacio físico como en operaciones de insert y update. Los
índices son utilizados para acelerar el acceso en búsquedas. Es recomendado la separación física de
los índices del tablespace de las tablas, esto para que el proceso de búsqueda se realice en un HD
mientras que la carga de los datos se realice en otro HD.
También es recomendado la separación de tablespace TMP que se utiliza para realizar
ordenamientos en las consultas, en resumen una arquitectura óptima requiere como mínimo 4 discos
duros: uno de datos, otro de índices, otro de TEMP y el diccionario de datos separados (SYSTEM).
Existen tres tipos de índices cuya naturaleza depende de la forma en que haya o creado. Estos tipos
son:
 Índice Primario: Es aquel que tiene la restricción adicional de que el grupo de columnas indexadas
define una única fila o llave primaria.
 Índice Foráneo: Se realizan consultas por campos distintos a los de la clave primaria, por ello hay
que crear un índice por los campos por los que se accede.
 Índice Adicional: Se realizan cuando existen varias instrucciones que requieren ordenamiento, por
ejemplo cuando se utiliza el order by. Sin embargo, las consultas no deben ser alteradas cuando se
coloca un índice.
Es importante revisar con frecuencia los índices para que no se fragmenten, a su vez hay que
desfragmentarlos dependiendo del porcentaje de fragmentación que estos presentan.

Un índice sólo es efectivo cuando es utilizado. Es por eso que debe asegurarse que la frecuencia de
uso sea muy alta y que su implementación vaya a mejorar el rendimiento de las consultas efectuadas
a la tabla donde ree el índice. Sin embargo, no es muy conveniente el uso de varios índices dentro de
una misma tabla porque con cada operación de inserción, actualización o eliminación que se lleva a
cabo sobre una tabla, sus índices se deben recrear. La creación, organización, borrado y análisis de
índices deberán llevar un registro de documentación.
Los procesos de mantenimiento de índices son los siguientes:
 Creación de Indices
 Modificación de Indices
 Monitoreo de Indices
 Borrado de Indices
4. Bitacoras. Oracle cuenta con herramientas de recuperación de la información ante caídas de
suministro eléctrico, errores de disco duros y demás fallos. Estos mecanismos se llaman logs o
bitácoras, las mismas son capaces de almacenar todos los datos de las transacciones las cuales se les
han aplicado commit.
El sentido real la función de los logs, es poder trazar las transacciones (insert, update, delete) de las
bases de datos, esto permite reparar fallos. Existe un concepto denominado miltiplexación de los
redo logs files, el cual permite guardar la misma información en todos los redo logs files (miembros)
que componen un grupo. Este diseño fue realizado de esta forma para garantizar que la base de datos
siga operando sin importar la caída de un redo log file.
El proceso de escritura en logs (LGWR) escribe los registros de redo del buffer de redo log a todos los
miembros del grupo actual de redo logs, hasta que el archivo se llena o se solicita una operación de
cambio de archivo de log. Entonces, cambia el grupo activo y comienza a escribir en los archivos del
siguiente grupo. Los grupos de redo log son usados de una forma circular (como una cola circular). Es
recomendado tener los redo logs files separados en grupos (para garantizar la miltiplexación) en
discos duros independientes.
Oracle y Postgres son los únicos SGBDs que cuenta con bitácoras cíclicas, el funcionamiento es una
cola circular, cuando un log se llena se pasa al siguiente. Desde luego esto significa que con el tiempo
suficiente un log puede llegar a ser sobrescrito, en cuyo caso se recomienda habilitar otro tipo de
Log, llamado Log en Frio mediante el modo Archive.
Para un buen mantenimiento de las bitácoras de una base de datos es necesario tener presente la
organización de la empresa; es decir que tantas transacciones se reportan diariamente, y que
tambien respaldado se quieren tener esas transacciones (en la mayoría de las empresas estas
bitácoras son primordiales en caso de una posible caída de la base de datos). A la hora de crear una
base de datos se debe hacer un estudio previo del manejo de la empresa y la cantidad de recursos
disponibles para la construcción de la base, con estos datos ya cuantificados es posible determinar el
número de bitácoras, así como el tamaño necesario para cada una de ellas.
En caso de que la base ya haya o creada y lo que se necesite sea darle mantenimiento a las bitácoras,
es muy importante también el estudio preciso del número promedio de transacciones diarias de la
empresa, para así asegurar que el tamaño y el numero de bitácoras a adicionar sea el más preciso, y
brinde el mejor funcionamiento de la base de datos.
Los procesos de mantenimiento de bitácoras son los siguientes:
 Adicionar elemento a un Redo Log
 Eliminar un elemento a un Redo Log
 Trasladar un elemento a un Redo Log
 Crear un grupo de Redo Log

El MANTENIMIENTO PROACTIVO1 de la base de datos es sencillo por la infraestructura sofisticada de Oracle

Database, que incluye los siguientes elementos principales:
• El Repositorio de Carga de Trabajo Automática (AWR) es un repositorio incorporado en cada
Oracle Database. En intervalos regulares, el servidor de Oracle Database realiza una instantánea de
todas las estadísticas fundamentales y la información de carga de trabajo y almacena esa información
en AWR. Los datos capturados los puede analizar el usuario, la propia base de datos o ambos.
• Mediante las tareas automáticas, la base de datos realiza operaciones de mantenimiento rutinarias,
como realizar copias de seguridad regulares, refrescar las estadísticas del optimizador o comprobar el
estado de la base de datos. El mantenimiento reactivo de la base de datos incluye condiciones y
errores críticos que descubren los comprobadores de estado de la base de datos:
• El servidor de Oracle Database proporciona alertas generadas por el servidor para los problemas
que no se pueden resolver de manera automática y que se necesitan notificar a los administradores
(como, por ejemplo, la falta de espacio). Por defecto, el servidor de Oracle Database se supervisa a sí
mismo y envía alertas para notificar los problemas. Las alertas notifican los problemas y, a menudo,
también ofrecen recomendaciones de cómo solucionar el problema notificado.
• Las recomendaciones se generan desde los diferentes asesores, cada uno de los cuales es
responsable de un subsistema. Por ejemplo, existen asesores de memoria, de segmentos y de SQL
VISUALIZACIÓN DEL HISTORIAL DE ALERTAS

En la página Historial de Alertas Alert History se muestra un gráfico con el historial de alertas de la base
de datos actual en los segmentos de tiempo que designe.
Una alerta indica un problema potencial: puede ser un umbral de advertencia o crítico de una métrica
supervisada, o puede ser una indicación de que un destino ya no está disponible.
Haga clic en el nombre de la métrica que se muestra en la página Alert History para obtener estadísticas
detalladas, gráficos y registros de hora reales de cada alerta.
También hay una ubicación en la que se pueden introducir comentarios relacionados con la alerta como,
por ejemplo, la información de resolución
1 Cualquier acción proactiva se refiere a la medida preventiva.Reactiva activa se refiere la aplicación de una solución al problema se
presenta

El Repositorio de Carga de Trabajo Automática (AWR) proporciona servicios a los componentes de

servidor de Oracle internos para recopilar, procesar, mantener y utilizar las estadísticas de rendimiento
para detectar posibles problemas y aplicar los ajustes necesarios automáticamente. El historial de
sesiones activas (ASH) es el historial de la actividad de sesión más reciente almacenado en AWR.
Las estadísticas son recopilaciones de datos que proporcionan más detalles sobre la base de datos y los
objetos de la misma. El optimizador de consulta utiliza las estadísticas del optimizador para elegir el
mejor plan de ejecución para cada sentencia SQL. Las estadísticas de la base de datos proporcionan
información para la supervisión del rendimiento.
Las instantáneas de AWR incluyen estadísticas y métricas de la base de datos, estadísticas de las
aplicaciones (volúmenes de transacciones, tiempo de respuesta), estadísticas del sistema operativo y
otras medidas. Una línea base de AWR es un juego de instantáneas de AWR recopiladas en un período de
tiempo. La línea base se utiliza para realizar comparaciones de rendimiento, ya sea del rendimiento actual
con la línea base o de una línea base con otra.
La línea base de ventana móvil del sistema se recopila por defecto en Oracle Database 11g. La línea base
de ventana móvil del sistema es un juego cambiante de instantáneas que incluye los ocho últimos días de
instantáneas por defecto. Esta línea base es válida después de que se hayan recopilado datos suficientes y
se produzca el cálculo de estadísticas. El cálculo de estadísticas está programado para cada sábado a
media noche por defecto.
OPTIMIZADOR DE ORACLE: VISIÓN GENERAL
El rendimiento de las sentencias SQL depende en gran medida de las estadísticas que el optimizador
tenga. Estas son usadas para la generación de apropiados planes de ejecución.
La recolección de estadísticas puede ser manual o automática.
El monitoreo del rendimiento puede ser pro-activo o re-activo
En 11g el uso de los diagnostic advisors libera al DBA de mucho trabajo manual
El optimizador es la parte de Oracle Database que crea el plan de ejecución para una sentencia SQL.
La determinación del plan de ejecución es un paso importante en el procesamiento de todas las
sentencias SQL y puede afectar en gran medida al tiempo de ejecución.
El plan de ejecución se arma dinámicamente por el optimizador, el cual confía totalmente en las
estadísticas. Las estadísticas más importantes son las de los objetos. Las estadísticas solo mejoran el
rendimiento de los SQL no de los PL/SQL.

El plan de ejecución conforma una serie de operaciones que se realizan en secuencia para ejecutar la
sentencia. El optimizador tiene en cuenta muchos factores relacionados con los objetos a los que se hace
referencia y con las condiciones especificadas en la consulta. La información necesaria para el
optimizador incluye:
- Estadísticas recopiladas para el sistema (E/S, CPU, etc.) al igual que objetos de esquema (número de
filas, índice, etc.)
- Información de diccionario
- Cualificadores de cláusula WHERE
- Indicaciones que proporciona el desarrollador
Si se utilizan herramientas de diagnóstico como Enterprise Manager, EXPLAIN PLAN y SQL*Plus
AUTOTRACE, se puede ver el plan de ejecución que elige el optimizador.
Nota: el optimizador de Oracle tiene dos nombres según su funcionalidad: optimizador de consulta y
optimizador automático de ajustes.
ESTADÍSTICAS DEL OPTIMIZADOR

En las estadísticas del optimizador se incluyen estadísticas de tabla, columna, índice y sistema. Las
estadísticas para tablas e índices se almacenan en el diccionario de datos. Estas estadísticas no están
destinadas a proporcionar datos en tiempo real. Proporcionan al optimizador una instantánea
estadísticamente correcta del almacenamiento y la distribución de datos que el optimizador utiliza para
tomar decisiones sobre cómo acceder a los datos.
En las estadísticas recopiladas se incluyen:
- Tamaño de la tabla o índice en los bloques de base de datos
- Número de filas
- Recuento de cadenas y tamaño medio de fila (sólo tablas)
- Altura y número de filas de hoja suprimidas (sólo índices)
A medida que se insertan, suprimen y modifican datos, estos hechos cambian. Puesto que el impacto en el
rendimiento del mantenimiento de estadísticas de distribución de datos en tiempo real es
extremadamente alto, estas estadísticas se actualizan recopilando periódicamente estadísticas en tablas e
índices.
Las estadísticas del optimizador las recopila automáticamente un trabajo de mantenimiento automático
que se ejecuta una vez al día por defecto durante las ventanas de mantenimiento predefinidas. Las
estadísticas del sistema son características del sistema operativo que utiliza el optimizador. Estas
estadísticas no se recopilan automáticamente. Para obtener información sobre la recopilación de
estadísticas del sistema, consulte Oracle Database Performance Tuning Guide (Guía de Ajuste de
Rendimiento de Oracle Database).
Las estadísticas del optimizador no son las mismas que las estadísticas de rendimiento de la base de datos
que se recopilan en la instantánea de AWR

Las estadísticas se ven en la vista DBA_TABLES, incluyen:

- El numero de registros en la tabla,
- El número de bloques (usados y no usados) asignados a la tabla, la cantidad de espacio libre en los
bloques que están siendo usados,
- la longitud promedio del registro, el numero de registros encadenados.
- Los registros encadenados se dan por que el registro es muy largo o porque los parámetros del
almacenamiento son muy bajos.
Además de estadísticas a nivel de tabla, existen estadísticas a nivel de columna (DBA_TAB_COLUMNS),
incluyen:
- El numero de valores distintos
- El mayor y menor valor
- El numero de Nulos
- La longitud promedio del registro
Cuando una tabla es analizada, también los índices son examinados, las estadísticas de los índices se ven
en DBA_INDEXES, incluyen:
- La profundidad del árbol del índice
- El número de valores distintos
- El Clustering factor – Que tan cerca esta el orden natural de los registros respecto al orden de los
registros en el Indice
Estas estadísticas son vitales para que Oracle sepa como ejecutar las sentencias. Si no son exactas, el
rendimiento se vera deteriorado dramáticamente.
También es posible obtener estadísticas explícitamente sobre los índices, estas estadísticas se podrán ver
en INDEX_STATS, incluyen:
- El numero de entradas en el índice referentes a los registros de la tabla
- El número de entradas en el índice referentes a registros borrados
Cuando un registro se borra, se conserva la clave de dicho registro en los índices, después de un tiempo, si
tenemos muchas entradas de índice correspondientes a registros borrados el performance se deteriorara.
1) Crear Tablas
Desde EM, para crear tablas nos dirigimos a "Esquema", sección "Objetos de Base de Datos", "Tablas".
Se pueden crear las tablas como en línea de comandos pero de forma gráfica. Al entrar en este
apartado, tendremos que pulsar en "Crear".
Podemos seleccionar la organización de las tablas, si la queremos estándar o por índices. Elegimos
estándar y pasamos a la pantalla siguiente.
Veremos esta pantalla:
Aquí podemos elegir el nombre de la nueva tabla, el esquema donde va a estar y el tablespace por defecto
donde se va a guardar.
En el apartado Columnas podremos modificar la forma que tendrá la tabla, o sea, añadir las columnas
que tendrá.
En las pestañas de la parte superior podemos elegir las restricciones, el tamaño que va a tener la tabla
entre otras opciones.
Por ejemplo en Restricciones podemos elegir el tipo de restricción en la lista "Restricciones" y pulsando
en el botón "Agregar" para configurar las restricciones que queramos ponerle:
Tenemos la posibilidad de activar o desactivar las restricciones simplemente configurando el "checkbox"

asociado.
En la pestaña Alamcenamiento podemos encontrar los valores de tamaño que tomará la tabla por
defecto. Podemos indicar el tamaño inicial que tendrá entre otras opciones. Podemos ver la sentencia
con la que se creará la tabla pulsando el botón "Mostrar SQL".
Si tenemos las tablas con datos, podemos ver los datos que contienen seleccionando la tabla en la
pantalla principal de las tablas y seleccionando Ver. Aquí veremos las columnas y el tipo de datos de
ellas. Para ver el contenido de la tabla seleccionamos en Acciones "Ver datos".
2) Crear Un Tablespace
Los tablespaces son espacios de memoria donde se van a almacenar las tablas. La memoria que se utiliza
para los tablespaces puede ser de disco o de la memoria principal.
Ejecutamos la siguiente consulta, debe tener en cuenta que el directorio debe existir previamente.
sql> create tablespace <nombre> datafile '<nombredatafile.dbf>' size
<tamaño_inicial>m autoextend on next <tamaño_incremento>m maxsize
<tamaño_maximo>m;
Por ejemplo, podemos ejecutar la siguiente creación de tablespace para Ventas, con un tamaño inicial de
2Mb, un crecimiento de 1Mb hasta 1Gb
create tablespace ventas datafile 'c:\bd\ventas.dbf ' size 2m
autoextend on next 1m maxsize 1g;

a. Verifique que no existe ninguna otra base de datos en ejecución en el sistema, en caso contrario
ejecute shutdown
b. Se prosigue a montar la Base de Datos, ejecute la siguiente instrucción:
startup open pfile =<Ruta>/initdatabase.ora;
c. Para crear el nuevo tablespace se deberá efectuar lo siguiente:
CREATE TABLESPACE <nombre> DATAFILE <nombredatafile.dbf>
SIZE 10M AUTOEXTEND ON NEXT 10M MAXSIZE 100M;
d. Como último paso se debe llenar el registro según corresponda:
Tablespace Fecha creación Ubicación Tamaño Observaciones
Desde la pestaña Servidor, sección Almacenamiento, "Tablespaces" podemos crear o configurar los
tablespaces:
En la pantalla principal de los tablespaces veremos los tablespaces que existen en el sistema y sus
características como el nombre, tamaño asignado, espacio usado, etc.
Al pulsar en el ya conocido botón Crear, podemos crear y configurar un tablespace nuevo. Debemos
introducir el nombre del nuevo tablespace y asignarle un fichero. Para asignar el fichero Pulsamos sobre
el botón Agregar que se encuentra en "Archivos de Datos".
Aquí podemos escribir el nombre del fichero, y a continuación el directorio de archivos, que por defecto
se encuentra donde está instalada la instancia. Le podemos dar un tamaño, que por defecto aparece como
100MB o reutilizar un fichero de tablespace que ya existe.
Otra de las opciones es que se puede indicar que el tablespace se amplíe automáticamente cunado llega al
límite de espacio, que si lo dejáramos como está, ese espacio sería los 100MB que estaban por defecto. Si
queremos que se amplíe automáticamente, lo activamos e indicamos el tamaño que se ampliará cuando se
produzca el exceso de tamaño. Para que no crezca indefinidamente, también podemos limitar el tamaño
máximo del archivo indicando el límite de tamaño.
De vuelta a la pantalla de los tablespaces, podremos observar que se ha añadido un archivo de datos.
Podemos agregar mas archivos si queremos, incluso archivos que se encuentren en otra partición o disco
duro simplemente indicando la ruta del archivo.
Podemos hacer que el tablespace sea permanente o temporal, y si queremos que sea de escritura/lectura,
solo lectura, o incluso offline que consiste en que el tablespace no se activa y por lo tanto no se podrá
usar.
En la pestaña Almacenamiento podemos encontrar otras opciones referidas a la gestión del tamaño del
tablespace. Para crear definitivamente el tablespace, pulsamos en Aceptar.
Podemos ver el nuevo tablespace que hemos creado en la pantalla principal de los tablespaces:
Ahora podemos usar ese tablespace y añadirle tablas.

Si queremos borra el tablespace y además sus ficheros para que no deje rastro, tenemos que
seleccionarlo, pulsar sobre Suprimir y activar el "checkbox" referido al borrado de los ficheros de datos.

3) Compactar Un Tablespace
Ejecutamos la compactación cuando tenemos saturado el tablespace y queremos reducir el tamaño en
disco duro. Para ello el comando realiza una desfragmentación de los datos dejando extensiones de datos
de forma consecutiva ahorrando memoria.
sql> alter tablespace <nombre> coalesce;
Por ejemplo, vamos a compactar la tabla creada en el ejercicio anterior.
sql> alter tablespace ventas coalesce;
a. Verifique que no existe ninguna otra base de datos en ejecución en el sistema, en caso contrario
ejecute shutdown
startup open pfile =<ruta>/initdatabase.ora;
c. Para efectuar una defragmentación de un tablespace, utilice la siguiente instrucción:
alter tablespace <nombre> coalesce;
d. Como último paso se debe llenar el registro según corresponda
Tablespace Fecha compactación Ubicación Tamaño Observaciones
4) Eliminar Un Tablespace
En algún momento es necesario eliminar un tablespace, para ello el mismo debe estar vacío, esto quiere
decir que no tengan objetos tales como tablas, índices o procedimientos almacenados.
sql> alter tablespace <nombre> offline normal;
sql> drop tablespace <nombre> [including contents] ;
Por ejemplo, vamos a eliminar el tablespace de ventas. sql> drop tablespace ventas;
Podría surgir el caso que necesitemos borrar un tablespace junto con todos los objetos que contiene, para
ello utilizamos la siguiente sintaxis: sql> drop tablespace ventas including contents;
a. Se prosigue a montar la Base de Datos, ejecute la siguiente instrucción:
startup open pfile =<ruta>/initdatabase.ora;
b. Ejecute la siguiente instrucción para deshabilitar el Tablespace que desea eliminar:
alter tablespace <nombre> offline;
c. Ahora para eliminar el tablespace usted debe de ejecutar la instrucción siguiente:
drop tablespace <nombre>;
d. Como último paso se debe llenar el registro según corresponda
Tablespace Fecha de Eliminación Ubicación Tamaño Observaciones
5) Adición De Un DataFile
a. Verifique que no existe ninguna otra base de datos en ejecución en el sistema, en caso contrario,
ejecute el siguiente código: shutdown;
c. Para adición de un nuevo datafile, efectué lo siguiente:
ALTER TABLESPACE <nombre> ADD
DATAFILE <ruta_nombredatafile.dbf>
SIZE 100M
AUTOEXTEND ON NEXT 50K MAXSIZE 1000M;
d. Como último paso, se debe llenar el registro correspondiente
DataFile Fecha de creación Ubicación Tamaño Observaciones

6) Ampliar El Tamaño De Un DataFile

En algún momento es necesario eliminar un tablespace, para ello el mismo debe estar vacío, esto quiere
decir que no tengan objetos tales como tablas, índices o procedimientos almacenados.
sql> alter database datafile <ruta.dbf> resize <tamaño nuevo>m;
Por ejemplo, vamos a eliminar el tablespace de ventas.
sql> alter database datafile 'c:\bd\ventas.dbf' resize 5m;
c. Para modificar el tamaño de un datafile ejecute lo siguiente:
ALTER DATABASE DATAFILE <ruta/nombredatafile.dbf> resize <tamaño nuevo>M;
d. Como último paso, se debe llenar el registro correspondiente
DataFile Fecha de modificación Ubicación Tamaño Motivo
7) Mover Un Tablespace
a. Se debe poner offline el tablespace que se desea mover con la siguiente instrucción:
alter tablespace <nombre> offline;
b. Luego mueva el tablespace a nivel sistema operativo. Efectuando cut and paste desde el
explorador para ubicarlo en la nueva dirección.
c. Ahora mueva el o los DataFiles que componen el tablespace de la siguiente manera:
alter tablespace <nombre>
rename datafile <ruta_nombredatafile.dbf>
to < ruta_nombredatafile.dbf>;
d. Como un último paso, se debe poner online el tablespace, con la siguiente instrucción:
alter tablespace "ventas" online;
e. Llene el registro correspondiente:
Tablespace Fecha de reubicación Ubicación nueva Tamaño Motivo Observaciones
8) Mover Un DataFile
c. Para mover el DataFile ejecute la siguiente instrucción:
ALTER DATABASE RENAME FILE <ruta/nombredatafile.dbf> TO <ruta/nombredatafile.dbf >;
d. Como ultimo paso, se debe llenar el registro correspondiente
Datafile Fecha de reubicación Ubicación nueva Tamaño Motivo Observaciones
9) Activar el Modo Seguro de Transacción (ARCHIVE)

Siga los siguientes pasos para poder archivera el modo de transacción segura.
1. Apague la base de datos
2. Inicie conexión con el perfil de SYSDBA
3. Montamos la base de datos en modo MOUNT
4. Ejecutamos: AlTER DATABASE ARCHIVELOG;

5. Abrimos la base de datos: ALTER DATABASE OPEN;

6. Ejecutamos: ALTER SYSTEM ARCHIVE LOG START;
7. Verificamos mediante la consulta: ARCHIVE LOG LIST;
Pasos
a. Montar la Base de Datos en modo open, utilizando el siguiente comando:
startup open pfile = <ruta>\initbase.ora;
b. Verifique que no existe ninguna otra base de datos en ejecución en el sistema, en caso contrario,
c. Se deberá buscar el archivo Init de su base de datos, para que se le active* el siguiente código:
# log_archive_start=true
# log_archive_dest=%Oracle_home%/database/%Oracle_sid%/Archive
# log_archive_format=´´%sample%T%TS%S.ARC´´
*Nota: Le llamamos activar, a el procedimiento de quitar los comentarios al código (#) y luego
salvar el archivo.
d. Se prosigue a montar la Base de Datos en modo mount que se desea poner en modo ARCHIVE:
startup mount;
e. Una vez que se ejecutaron las instrucciones anteriores, se ejecuta lo siguiente:
ALTER DATABASE ARCHIVELOG;
f. Una vez montada la Base de Datos, se procederá a abrirla mediante la siguiente instrucción:
Alter Database Open;
g. Se ejecuta la siguiente instrucción para poner la base de datos en modo ARCHIVE:
Alter system archive log start;
h. Para finalizar, se debe registrar correctamente.
Bitácora Fecha/Hora Ruta Secuencia Observaciones
10) Creación de Índices

Existen diferentes tipos de índices en Oracle, cada uno de ellos es más útil para ciertas aplicaciones.
Índice tipo Árbol B+. Un árbol B+ es un árbol equilibrado, esto significa que la altura del índice es el
mismo para todos los valores asegurando así que la recuperación de los datos para cualquier valor toma
en promedio el mismo tiempo.
Este tipo de índice se utiliza mejor cuando cada valor tiene una cardinalidad alta (bajo número de
ocurrencias), por ejemplo, índices de clave primaria o índices únicos. Un punto importante a tener en
cuenta es que los valores NULL no se indexan
Para crear un índice de este tipo se utiliza la siguiente consulta:
sql> create index <nombre_indice> on <tabla>(<columnas>) ;
Por ejemplo, la tabla t2 tiene como columna a: sql> create index t2_unique on t2(a);
Índice Hash Cluster. En este caso, el índice es una función hash que apunta directamente la llave a la fila
en la tabla. El índice no está separado, por lo que la función está dentro de la tabla. Este índice es
especialmente útil cuando se realizan consultas como X = Y.
CREATE CLUSTER hashDemo (cedula int) size 50 hash is cedula hashkeys 5000;
CREATE TABLE persona( cedula int, nombre varchar(50), edad int)
cluster hashDemo(cedula);
Bitmap Indexes. Se utilizan comúnmente en aplicaciones de datawarehouse para las tablas que no tienen
actualizaciones y cuyas columnas tienen una cardinalidad baja (es decir, hay pocos valores distintos). En
este tipo de índice de Oracle almacena un mapa de bits para cada valor distinto en el índice con un bit por
cada fila de la tabla. Estos mapas de bits son caros de mantener y, por tanto, no es adecuado para
aplicaciones que hacen escrituras a los datos.
Veremos los índices que están en la BD en la pestaña "Esquema", sección "Objetos de Base de Datos",
"Índices".
Los índices son necesarios para aumentar el rendimiento de las consultas a las tablas, sobre todo cuando
esas consultas se producen muy a menudo en una columna concreta. Entonces se crea un índice de esa
columna o columnas. Dentro de "Índices" observamos que se pueden buscar los índices que existen en un
determinado esquema. Podremos buscarlos por nombre de tabla, que mostrará las tablas con índice, o
por nombre de índice. Como siempre, podemos ver el contenido del índice pulsando sobre el, así como
editarlo, eliminarlo o crear uno nuevo. Al verlo, veremos multitud de parámetros, incluido estadísticas. En
"Acciones", al seleccionar "Generar DLL" veremos la sentencia con la que se creó el índice. La creación de
objetos en la BD a través de la interfaz web viene a tener la mísma dinámica siempre, esto es lo que lo
hace muy intuitivo y fácil.
Si queremos crear un índice nuevo pulsamos en "Crear". Introducimos el nombre del índice, el esquema
de usuario y el tablespace donde se va a crear. Lo podemos hacer sobre una tabla o en un cluster.
Suponga que el registro civil de Costa Rica quiere realizar un estudio de minería de datos, para ello quiere
segmentar a la población en las provincias del país. De esta forma cada persona va está en una categoría
de provincia. Es justamente esta segmentación lo que hace al bitmap la elección ideal para hacer
consultas por categorías.
CREATE BITMAP INDEX <nombre_indice> ON <nombre_tabla>(<datos>) REVERSE;
a. Deshabilitar la instancia de Oracle, de la siguiente manera: shutdown
b. Iniciar la Base de Datos en modo: "open", utilizando el siguiente comando:
Startup open pfile='\init.ora';
c. Crear un indice con el siguiente comando:
create index nombreindice on table (columnas )
d. Para finalizar, se debe registrar correctamente.
Nombre
Fecha de creación Ubicación Observaciones
del Indice
11) Modificación de Índices

Se utilizan comúnmente cuando el índice está fragmentado, esto se debe a que la estructura de los arboles
B+ realizan un borrado lógico de los nodos y no así de forma física. Por lo que con el tiempo estos índices
reducen su eficiencia.
La instrucción para reconstruir los índices es: sql> alter index <nombre> rebuild
c. Modificar un índice con el siguiente comando:
alter index index allocate extent deallocate unused rebuild
Nombre
Fecha de modificación Ubicación Observaciones
del Indice
12) Monitoreo de Índices

Podemos registrar un índice en específico para que Oracle nos provea estadísticas relacionadas con un
índice.
sql> analyze index <nombre> validate structure
Si queremos ver las estadísticas generadas, debemos consultar la vista:
sql> select * from index_stats;

c. Para monitorear el índice:

ANALYZE INDEX index VALIDATE STRUCTURE
donde: Validate structure: valida la estructura del índice y genera estadísticas por la vista INDEX_STATS.
Nombre
Fecha de monitoreo Ubicación Observaciones
del Indice
13) Borrado de Índices

La consulta para borrar índices es: sql> drop index <nombre>;
c. Eliminar un índice:
DROP INDEX index
Nombre
Fecha de eliminación Ubicación Observaciones
del Indice
14) Crear un grupo de Redo Log Files

Podemos crear un grupo de Redo Log Files mediante la siguiente instrucción:
ALTER DATABASE ADD LOGFILE ('/oracle/dbs/log1c.rdo',
'/oracle/dbs/log2c.rdo') SIZE 500K;
No olvide que se deben establecer rutas entre los miembros del grupo, que están en discos duros
independientes.
Forzando cambio de Log File, Ejecutamos la siguiente instrucción:
ALTER SYSTEM SWITCH LOGFILE;
Mediante la siguiente instrucción podemos cambiar el tiempo en el que los redo log files cambian al
próximo currem.
ALTER SYSTEM SET archive_lag_target = 1800;
En este caso el cambio se realiza cada 30 minutos, la unidad anterior está dada en segundos pues
1800/60 = 30 minutos.
c. Utilizar la siguiente instrucción para crear el grupo de Redo Log Files:
ALTER DATABASE
ADD LOGFILE ('RUTA/nombreRedoLog1.rdo',
'RUTA2lnombreRedoLog2.rdo') SIZE 500K;
Nombre grupo Redo Log File Fecha creación Ruta Tamaño
15) Eliminar un grupo de Redo Log Files

Antes de eliminar algún grupo de dato, debemos estar seguros que no este siendo utilizado.
Para ello ejecutamos la siguiente cosulta:
SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;

Verificamos que efectivamente el grupo que queremos eliminar no este siendo utilizado, procedemos la
eliminación mediante la siguiente instrucción:
ALTER DATABASE DROP LOGFILE GROUP 3;
16) Adicionar un elemento a un grupo de Redo Log Files
Algunas consultas importantes para tener en cuenta son:
Vista: V$LOG Muestra la información del redo log file
Vista: V$LOGFILE Muestra la ruta de los redo logs files
Vista: V$LOG_HISTORY Muestra el historial del redo log files
Para crear miembros de grupos de redo log files, ejecutamos la siguiente instrucción:
ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2b.rdo'
TO GROUP 2;
startup open pfile='\init.ora';
c. Utilizar la siguiente instrucción para crear el grupo de redo log files, especificando la ruta y el
nombre del Redo Log File donde se desea guardar, así como el tamaño máximo de los mismos,
además la inclusión de nuevos elementos a crear van separados por coma:
alter database add logfile 'Ruta/nombreArchivo.log' size 10m;
Nombre archivo/grupo
Fecha adición Ubicación Tamaño
Redo Log File
17) Eliminar un elemento de un grupo de Redo Log Files

Ejecutamos la siguiente instrucción:
ALTER DATABASE DROP LOGFILE MEMBER
'/oracle/dbs/log3c.rdo';
c. Verificar que el archivo Redo Log File que se desea eliminar este inactivo en la base de datos, con
la siguiente instrucción:
svrmgrl> select NombreGrupoRedo, archived, status from v$log;
d. Utilizar la siguiente instrucción para eliminar el elemento al grupo de redo log files
alter database drop logfile NombrearchivoGrupoRedo;
e. Para finalizar, se debe registrar correctamente.
Nombre archivo/grupo Fecha
Ubicación Motivo
Redo Log File eliminación
18) Trasladar un elemento a un subgrupo de Redo Log Files

Para mover los archivos de redo log files se deben seguir los siguientes pasos:
1. Apagar la base de datos
2. Mover o renombrar mediante OS los archivos redo log files
3. Levantamos la base de datos en modo MOUNT
4. Ejecutamos la siguiente instrucción:
ALTER DATABASE RENAME FILE '/diska/logs/log1a.rdo',
'/diska/logs/log2a.rdo' TO '/diskc/logs/log1c.rdo',
'/diskc/logs/log2c.rdo';
5. Abrimos la base de datos (ALTER DATABASE OPEN)
Pasos
c. Utilizar la siguiente instrucción para mover el elemento seleccionado al subgrupo
correspondiente:
ALTER DATABASE RENAME FILE
'/ruta_original/nombre_archivo', '/ruta_original/nombre_archivo' TO
'/ruta_nueva/nombre_archivo', '/ruta_nueva/nombre_archivo';
Nombre archivo/grupo Fecha
Origen Destino
Redo Log File traslado
19) Crear ENLACES de base de datos

Se pueden crear enlaces de bases de datos, que quiere decir, que se pueden hacer consultas desde una
instancia a otra diferente mediante enlaces.
En Oracle Enterprise Manager para crear un enlace tenemos que ir a la pestaña Esquema, sección Objetos
de Base de Datos, Enlaces de Base de Datos.
Al entrar aquí, veremos una lista de los enlaces que se han creado. Por defecto no existe ninguna.
Pero antes de crear el enlace, tenemos que modificar el fichero tnsnames.ora desde la consola web.
Para eso nos dirigimos a la pestaña Inicio y pulsamos en el enlace Host, que indica el nombre del equipo.
Ahora nos dirigimos a la sección Enlaces relacionados y pulsamos en el enlace
Administración sw Servicios de Red. En ek campo "Administrar" elegimos Nomenclatura local
Antes de configurar, tenemos que introducir un usuario y contraseña con permisos de administrador ya
que vamos a modificar el archivo tnsnames.ora. Es necesario que el usuario tenga contraseña, si no la
tiene, creamos un usuario nuevo y lo añadimos al grupo de administradores. Este usuario debe tener
contraseña.
Una vez introducidos los datos de autenticación, pasaremos a una pantalla como esta:
Veremos el contenido del archivo tnsnames.ora. Para crear un nuevo servicio pulsamos en Crear.
Aquí seleccionamos el protocolo de red, que será TCP/IP, el puerto, que será 1521 o el que elijamos en la
instancia remota y el host, que será el nombre de dominio o la IP de la máquina a la que se va a conectar.
Aceptamos.
Escribimos también el nombre se dervicio de red que será el que usemos para crear el enlace
También tenemos que indicar el nombre del servicio o el SID remoto. Para terminar, aceptamos.
Si abrimos el archivo tnsnames.ora veremos que se ha introducido un nuevo servicio de red que en la
prueba se ha usado orcl2:

Y también aparece en la pantalla de Nomenclatura local en Administración de Servicios de Red:
Ahora podremos crear el enlace.

Volvemos al punto anterior, a la pestaña Esquema, sección Objetos de la Base de Datos, Enlaces de Base
de Datos. Pulsamos en Crear.
Ponemos el nombre del enlace y el nombre del servicio de red, que es el que creamos antes, orcl2.
También podemos configurar con qué usuario nos conectaremos. Si elegimos Usuario fijo, tenemos que
introducir sus credenciales. Y si queremos que el enlace lo use cualquier usuario de la BD activamos el
checkbox Público.
Si pulsamos en mostrar SQL, nos enseñará la sentencia SQL para crear el enlace con los datos que le
hemos pasado:
Para crear un enlace pulsamos en "Crear". El enlace se creará en el esquema "PUBLIC"
20) Crear SECUENCIAS

Para crearlos, nos dirigimos a la pestaña Esquema, sección Objetos de Base de Datos, Secuencias.
Pulsamos en Crear y configuramos las opciones, como el nombre de la secuencia, el esquema donde se va
a guardar y los valores de la secuencia

USO DE LA PÁGINA MANAGE OPTIMIZER STATISTICS

Para gestionar estadísticas del optimizador en Enterprise Manager, haga clic en el separador Server y, a
continuación, haga clic en Manage Optimizer Statistics en la sección Query Optimizer. Desde esta página
puede realizar las siguientes tareas en las estadísticas:
 Recopilar estadísticas del optimizador manualmente.
 Restaurar las estadísticas del optimizador en un punto en el pasado. El punto en el tiempo
seleccionado se debe situar dentro del período de retención de las estadísticas del optimizador, que
es de 30 días por defecto.
 Bloquear las estadísticas del optimizador para garantizar que las estadísticas de determinados
objetos nunca se sobrescriban. Esta opción resulta útil si se han calculado las estadísticas de una
determinada tabla en un momento en el que estaban presentes los datos más representativos y si
desea mantener siempre esas estadísticas. Ninguna fluctuación de la tabla afectará a las estadísticas si
están bloqueadas.
 Desbloquear las estadísticas del optimizador para deshacer un bloqueo realizado previamente.
 Suprimir las estadísticas del optimizador para suprimir estadísticas.
Práctica Recomendada: Utilice las tareas automáticas de mantenimiento para recopilar las estadísticas
del optimizador. Para activar la tarea de recopilación de estadísticas del optimizador, se debe asegurar de
que el parámetro de inicialización STATISTICS_LEVEL está definido en TYPICAL o ALL.
RECOPILACIÓN MANUAL DE ESTADÍSTICAS DEL OPTIMIZADOR

Puede que deba recopilar estadísticas manualmente en ciertas ocasiones como, por ejemplo, cuando el
contenido de una tabla haya cambiado tanto entre los trabajos de recopilación automáticos que las
estadísticas ya no representen la tabla de forma precisa. Esto es habitual en el caso de las tablas grandes
que experimentan más de un 10% de cambio en el tamaño en un período de 24 horas.
Práctica recomendada: recopile estadísticas con la periodicidad suficiente para que la tabla nunca cambie
más de un 10% entre períodos de recopilación. Para ello, se puede necesitar la recopilación manual de
estadísticas o ventanas de mantenimiento adicionales.
Las estadísticas se pueden recopilar manualmente con Enterprise Manager o con el paquete
DBMS_STATS. Las estadísticas del sistema sólo se pueden recopilar con el paquete DBMS_STATS.

Las estadísticas del sistema describen las características del hardware del sistema, como el rendimiento y
el uso de E/S y de CPU, al optimizador de consulta.
Al seleccionar el menú Gather Optimizer Statistics, se inicia un asistente que permite seleccionar el
ámbito, los objetos, las opciones y la programación del trabajo que recopilará las estadísticas del
optimizador. El asistente ejecuta un trabajo DBMS_STATS.GATHER_*_STATS en el ámbito especificado:
tabla, esquema o base de datos. En este asistente, defina las preferencias para los valores por defecto que
utiliza el paquete DBMS_STATS y programe la ejecución del trabajo para el momento que determine.
No se recomienda recopilar estadísticas manualmente para la recopilación rutinaria de estadísticas

porque las estadísticas se recopilan con más eficiencia y menos impacto sobre los usuarios durante las
ventanas de mantenimiento. También se puede ejecutar un trabajo manual si el trabajo automático ha
fallado o se ha desactivado.
También puede recopilar estadísticas del optimizador directamente con el paquete DBMS_STATS:
SQL> EXEC dbms_stats.gather_table_stats('HR','EMPLOYEES');
SQL> SELECT num_rows FROM dba_tables
2 WHERE owner='HR' AND table_name = 'EMPLOYEES';
NUM_ROWS
----------
214
Observe que ahora el número de filas refleja correctamente lo que había en la tabla en el momento en que
se recopilaron las estadísticas. DBMS_STATS también permite la recopilación manual de estadísticas para
un esquema completo o incluso para toda la base de datos.
Las estadísticas del sistema no cambian a menos que la carga de trabajo cambie de manera significativa.
Como resultado, las estadísticas del sistema no necesitan ajustes frecuentes. El procedimiento
DBMS_STATS.GATHER_SYSTEM_STATS recopilará estadísticas del sistema en el período especificado,
aunque también puede iniciar la recopilación de estadísticas del sistema y realizar otra llamada para
parar la recopilación.
Práctica recomendada: utilice el siguiente comando cuando cree una base de datos:
SQL> EXEC dbms_stats.gather_system_stats('NOWORKLOAD');
La opción NOWORKLOAD tarda unos minutos (dependiendo del tamaño de la base de datos) y captura
estimaciones de características de E/S, como el tiempo medio de búsqueda de lecturas y el ratio de
transferencia de E/S
Preferencias de recopilación de estadísticas

Se puede llamar a los procedimientos DBMS_STATS.GATHER_*_STATS a diversos niveles pararecopilar
estadísticas de toda la base de datos o de objetos individuales como tablas. Cuando se llama a los
procedimientos GATHER_*_STATS, se suele permitir el uso de los valores por defecto de varios de los
parámetros. Los valores por defecto proporcionados funcionan bien con la mayoría de los objetos de la
base de datos pero, para algunos objetos o esquemas, es preciso cambiarlos. En lugar de ejecutar trabajos
manuales para cada uno de estos objetos, Oracle Database 11g permite definir valores (denominados
preferencias) para objetos, esquemas o bases de datos individuales o cambiar los valores por defecto con
el comando de nivel global.
Las preferencias especifican los parámetros que se proporcionan a los procedimientos de recopilación.
Los procedimientos SET_*_PREFS crean valores de preferencias para cualquier objeto que no sea
propiedad de SYS ni SYSTEM. El uso esperado es que el DBA defina las preferencias globales para todos
los parámetros que afectan a toda la base de datos. Se aplicarán a todos los parámetros que pueden
utilizar el valor por defecto.
El procedimiento SET_DATATBASE_PREFS itera en todas las tablas y todos los esquemas de la base de
datos definiendo la preferencia especificada. SET_SCHEMA_PREFS itera en las tablas del esquema
especificado. SET_TABLE_PREFS define el valor de preferencia de una sola tabla.
Todas las preferencias de objeto, estén definidas a nivel de base de datos, de esquema o de tabla, se
mantienen en una misma tabla. Si se cambian las preferencias a nivel de esquema, se sobrescriben las
preferencias definidas con anterioridad a nivel de tabla
Cuando se ejecutan los diversos procedimientos de recopilación, recuperan las preferencias a nivel de
objeto definidas para cada objeto. Puede visualizar las preferencias a nivel de objeto en la vista
DBA_TAB_STAT_PREFS. Las preferencias que no estén definidas a nivel de objeto se definirán como
preferencias a nivel global. Puede visualizar las preferencias globales llamando al procedimiento
DBMS_STATS.GET_PREFS para cada preferencia.
Puede definir, obtener, suprimir, exportar e importar esas preferencias a nivel de tabla, esquema, base de
datos y global. Se espera que los valores de preferencias estén definidos desde el nivel global hasta el
nivel de tabla y que se apliquen las preferencias al grupo más pequeño en último lugar.
Preferencias en Oracle Database 11g:
- CASCADE determina si se recopilan las estadísticas de los índices como parte de la recopilación de las
estadísticas de las tablas.
- DEGREE define el grado de paralelismo que se utiliza para recopilar estadísticas.
- PUBLISH se utiliza para decidir si se publican las estadísticas en el diccionario o si se almacenan en un área
privada. Esto permite al DBA validar las estadísticas antes de publicarlas en el diccionario de datos con el
procedimiento PUBLISH_PENDING_STATS.
- STALE_PERCENT se utiliza para determinar el nivel de umbral en el que se considera que un objeto tiene
estadísticas anticuadas. El valor es un porcentaje de filas modificadas desde la última recopilación de
estadísticas. En el ejemplo se cambia el valor de porcentaje por defecto de 10 al porcentaje 13 sólo para
SH.SALES.
- INCREMENTAL se utiliza para recopilar estadísticas globales en tablas particionadas de una forma incremental.
- METHOD_OPT determina las columnas y los parámetros de histogramas que se utilizan para recopilar
estadísticas de columnas.
- GRANULARITY determina la granularidad de las estadísticas que se deben recopilar (sólo es pertinente si la
tabla está particionada).
- NO_INVALIDATE se utiliza para determinar si se deben invalidar los cursores.
- ESTIMATE_PERCENT se utiliza para determinar el número de filas que se debe incluir en la muestra para
obtener unas estadísticas aceptables. Es un porcentaje del número de filas de la tabla.
Nota: para obtener más información sobre estas preferencias, consulte la documentación sobre
DBMS_STATS en Oracle Database PL/SQL Packages and Types Reference (Referencia de Tipos y Paquetes
PL/SQL de Oracle Database).
Las preferencias se pueden suprimir con los procedimientos DBMS_STATS.DELETE_*_PREFS a nivel de
tabla, esquema y base de datos. Puede restablecer los valores recomendados de las preferencias globales
con el procedimiento DBMS_STATS.RESET_PARAM_DEFAULTS.

REPOSITORIO DE CARGA DE TRABAJO AUTOMÁTICA (AWR)

AWR es la infraestructura que proporciona a los componentes de Oracle Database 11g los servicios
necesarios para recopilar, mantener y utilizar estadísticas para detectar problemas y aplicar ajustes
automáticos. Puede considerarlo como almacén de datos para las estadísticas de base de datos, métricas,
etc.
Cada 60 minutos (por defecto), la base de datos captura automáticamente información estadística de SGA
y la almacena en AWR con el formato de instantáneas. Estas instantáneas se almacenan en el disco
mediante un proceso en segundo plano denominado supervisión de gestión (MMON). Por defecto, las
instantáneas se retienen durante ocho días. Puede modificar tanto el intervalo de instantánea como los
intervalos de retención.
AWR contiene cientos de tablas, todas pertenecientes al esquema SYSMAN y almacenadas en el
tablespace SYSAUX. Oracle recomienda que sólo se acceda al repositorio mediante Enterprise Manager o
el paquete DBMS_WORKLOAD_REPOSITORY para su funcionamiento con AWR. No está soportado el
direccionamiento de DML en las tablas del repositorio
Líneas Base de AWR
Una línea base de AWR es un juego de instantáneas de AWR. Suele ser un juego de datos de instantáneas
de un período importante que etiqueta y retiene en AWR. Una línea base se define en un par de
instantáneas; las instantáneas se identifican por sus números de secuencia de instantánea (snap_id) o por
una hora de inicio y de finalización. Cada juego de instantáneas tiene una instantánea inicial y una
instantánea final e incluye todas las instantáneas intermedias. Los juegos de instantáneas se utilizan para
retener datos de instantáneas. Por lo tanto, por defecto, las instantáneas pertenecientes a los juegos de
instantáneas se retendrán hasta que se borren dichos juegos. Se puede definir como valor de caducidad el
número de días que se retendrá la instantánea.
Una línea base se identifica por el nombre proporcionado por el usuario. Ejecute el procedimiento
CREATE_BASELINE para crear una línea base a partir de un juego de instantáneas y especifique un
nombre y un par de identificadores de instantánea. Se asignará un identificador de línea base única para
toda la vida de una base de datos a la línea base recién creada. Normalmente, las líneas base se configuran
a partir de períodos representativos del pasado, con objeto de comparar el comportamiento del sistema
en ese momento con el comportamiento actual. También se pueden definir alertas basadas en umbrales
mediante líneas base desde Database Control. Puede definir el tiempo de caducidad en el número de días
con el parámetro de caducidad de este procedimiento.
El valor por defecto es NULL, es decir, “no caduca nunca”.
Puede obtener los valores de snap_id directamente desde DBA_HIST_SNAPSHOT o Database
Control.
Nota: para obtener más información sobre el paquete DBMS_WORKLOAD_REPOSITORY, consulte la guía
Oracle Database PL/SQL Packages and Types Reference (Referencia de Tipos y Paquetes PL/SQL de
Oracle Database).
Enterprise Manager y AWR

Haga clic en el separador Server y, a continuación, haga clic en Automatic Workload Repository en la
sección Statistics Management. En la página Automatic Workload Repository, haga clic en Edit para
cambiar la configuración.
Desde la página Automatic Workload Repository podrá:
• Editar la configuración del repositorio de carga de trabajo.
• Consultar información detallada acerca de las instantáneas creadas y crear manualmente
instantáneas nuevas.
• Crear líneas base de AWR.
• Generar un informe de AWR

Gestión de AWR
La configuración de AWR incluye el período de retención, el intervalo de recopilación y el nivel de
recopilación. Recuerde que la disminución de cualquier valor de esta configuración afecta a la
funcionalidad de los componentes que dependen de AWR, incluso a los asesores.
El aumento de los valores de la configuración puede ofrecer mejores recomendaciones de los asesores,
pero a costa del espacio necesario para almacenar las instantáneas y el rendimiento utilizado para
recopilar la información de instantáneas.
Plantéese la opción de definir el nivel de recopilación en ALL cuando ajuste una aplicación nueva. El valor
ALL recopila los planes de ejecución SQL y las estadísticas de temporización que mejoran las
recomendaciones de los asesores SQL. Una vez terminado el ajuste, esta configuración debe volver al
valor TYPICAL

Niveles de Estadísticas
El parámetro de inicialización STATISTICS_LEVEL controla la captura de diversas estadísticas y diversos
asesores, incluidas las tareas de mantenimiento automáticas. Las tareas automáticas de mantenimiento
incluyen la recopilación de las estadísticas del optimizador. El parámetro STATISTICS_LEVEL se puede
definir en los siguientes niveles:
• BASIC: desactiva el cálculo de estadísticas y métricas de AWR. La tarea automática de estadísticas
del optimizador está desactivada, igual que todos los asesores y todas las alertas generadas por el
servidor.
• TYPICAL: se recopilan las estadísticas principales necesarias para la autogestión de la base de
datos. Representan lo que normalmente se necesita para supervisar el comportamiento de Oracle
Database. Esto incluye la recopilación automática de estadísticas para reducir la posibilidad de
sentencias SQL de rendimiento bajo, debido a estadísticas anticuadas o no válidas.
• ALL: se capturan todas las estadísticas posibles. Este nivel de captura agrega estadísticas de
tiempo del sistema operativo y estadísticas de ejecución de planes. Estas estadísticas no son
necesarias en la mayoría de los casos, por lo que no se deben activar para conseguir un
rendimiento óptimo; en ocasiones, se necesitan para pruebas de diagnóstico concretas.
Oracle recomienda que se defina el valor por defecto TYPICAL para el parámetro de inicialización
STATISTICS_LEVEL. Al definir el valor en BASIC, se desactiva la recopilación automática de estadísticas
del optimizador
Supervisión de Diagnóstico de Base de Datos Automático (ADDM)

A diferencia de otros asesores, ADDM se ejecuta automáticamente después de cada instantánea de AWR.
Cada vez que se toma una instantánea, ADDM realiza un análisis del período correspondiente a las dos
últimas instantáneas. ADDM supervisa de forma proactiva la instancia y detecta la mayoría de los cuellos
de botella antes de que se conviertan en un problema importante.
En muchos casos, ADDM recomienda soluciones para los problemas detectados e incluso cuantifica las
ventajas de las recomendaciones.
Algunos problemas comunes que detecta ADDM:
- Cuellos de botella en CPU
- Gestión deficiente de la conexión de Red de Oracle
- Contención de bloqueo
- Capacidad de entrada/salida (E/S)
- Reducción excesiva del tamaño de las estructuras de memoria de la instancia de base de datos
- Sentencias SQL de carga alta
- Tiempos de PL/SQL y de Java altos
- Carga alta de punto de control y causa (por ejemplo, archivos log pequeños)
Los resultados de los análisis de ADDM se almacenan en AWR y también se puede acceder a ellos a través
de Enterprise Manager.
En la página Automatic Database Diagnostic Monitor (ADDM), aparecen los resultados detallados del
último análisis de ADDM ejecutado. Database Time representa la suma del tiempo de actividad en las
sesiones de la base de datos durante el período de análisis. Se proporciona un porcentaje de impacto
concreto para cada resultado. El impacto representa el tiempo usado por el problema correspondiente,
comparado con el tiempo de la base de datos durante el período de análisis.
En la diapositiva, tenga en cuenta lo siguiente:
1. El gráfico muestra que el número medio de usuarios activos aumentó drásticamente en este punto.
Además, el problema más importante fue un problema de espera (Wait).
2. El icono muestra que la salida de ADDM que aparece en la parte inferior de la página corresponde a
este punto en el tiempo. Puede ir a un momento anterior (para ver análisis previos) haciendo clic en
los otros iconos.

3. Los resultados le proporcionan un corto resumen de lo que descubrió ADDM como áreas ajustables.
Al hacer clic en un problema concreto, pasará a la página Performance Finding Details.
Si hace clic en el botón View Report, podrá acceder a información detallada sobre el análisis
derendimiento en forma de informe de texto
La página Performance Finding Details le proporciona recomendaciones para solucionar los problemas
encontrados. Las recomendaciones se agrupan en categorías, entre ellas categorías de esquema, de ajuste
SQL y de configuración de la base de datos. La columna Benefit(%) muestra la reducción máxima de
tiempo transcurrido en la base de datos al implantar la recomendación.
ADDM considera la posibilidad de aplicar varios cambios a un sistema. Entre sus recomendaciones se
incluyen:
- Cambios de hardware: agregar CPU o cambiar la configuración del subsistema de E/S.
- Configuración de la base de datos: cambiar la configuración de parámetros de inicialización.
- Cambios de esquema: crear particiones hash de tablas o índices, o bien utilizar la Gestión
- Automática de Espacio de Segmento (ASSM).
- Cambios de aplicación: utilizar la opción de caché para secuencias o usar variables de enlace.
- Utilizar otros asesores: ejecutar el Asesor de Ajustes SQL en SQL con mucha carga o ejecutar el
Asesor de Segmentos en objetos activos.
MARCO DE ASESORAMIENTO
Los asesores proporcionan información de gran utilidad acerca de la utilización y el rendimiento de los
recursos para sus respectivos componentes de servidor. Por ejemplo, el Asesor de Memoria proporciona
un valor recomendado para el parámetro de inicialización MEMORY_TARGET, que controla la cantidad
total de memoria que utiliza la instancia de Oracle Database.
Al contar con los datos capturados por AWR, ADDM permite a Oracle Database diagnosticar su propio
rendimiento y determinar cómo se pueden resolver los problemas identificados. ADDM se ejecuta
automáticamente después de cada una de las capturas de estadísticas AWR. Puede llamar a otros
asesores.
Las principales ventajas que proporciona la infraestructura de asesores son las siguientes:
• Todos los asesores utilizan una interfaz uniforme.
• Todos los asesores disponen de un origen de datos común y un almacén de resultados al utilizar el
repositorio de carga de trabajo.

No se muestran todos los asesores en la diapositiva (por ejemplo, no figuran el Asesor de

Recuperación de Datos ni el Asesor de Reparación SQL).
Supervisión de Diagnóstico de Base de Datos Automático (ADDM)
ADDM es un experto basado en servidor que revisa el rendimiento de la base de datos cada
60 minutos. Su objetivo es detectar pronto los posibles cuellos de botella del sistema y recomendar
correcciones antes de que el rendimiento del sistema se reduzca sensiblemente
Enterprise Manager y Asesores

La página Advisor Central es la página principal de todos los asesores. Para llegar a esta página, haga clic
en el enlace Advisor Central en la lista Related Links de la página inicial de Database Control.
Este no es, sin embargo, el único punto de acceso a los asesores en Database Control. También se puede
acceder a los asesores desde otros contextos.
En el separador Advisors de la página Advisor Central, puede ver una lista de todas las tareas de asesor
registradas en el repositorio de carga de trabajo. También puede filtrar esta lista por tipo de asesor y por
períodos de tiempo predefinidos. El separador Checkers de la página Advisor Central permite programar
diversas comprobaciones de integridad de la base de datos. Puede ver una lista de todas las ejecuciones
de comprobación por nombre, tipo o período.
Algunos de los asesores se describen con mayor detalle en las lecciones tituladas “Gestión de Datos de
Deshacer”, “Gestión de Rendimiento” y “Conceptos de Copia de Seguridad y Recuperación”.
Nota: utilice la página Change Default Parameters para cambiar el tiempo de caducidad por defecto (en
días) para todas las tareas futuras. También puede utilizar esta página para cambiar los parámetros de
algunos asesores importantes.
Paquete DBMS_ADVISOR
El paquete DBMS_ADVISOR contiene todas las declaraciones de procedimiento y constantes para todos
los módulos de asesor. Puede utilizar este paquete para ejecutar tareas desde la línea de comandos.
Para poder ejecutar los procedimientos de asesor, es necesario disponer del privilegio ADVISOR. El
privilegio ADVISOR permite acceder plenamente a las vistas y los procedimientos del asesor.

Nota: para obtener más información sobre todos los procedimientos del paquete DBMS_ADVISOR,
consulte Oracle Database PL/SQL Packages and Types Reference (Referencia de Tipos y Paquetes PL/SQL
de Oracle Database).
1. Automated Maintenance Tasks / Tareas de Mantenimiento Automáticas
Mediante el análisis de la información almacenada en AWR, la base de datos puede identificar la
necesidad de realizar tareas de mantenimiento rutinarias como, por ejemplo, refrescar las estadísticas del
optimizador. La infraestructura de las tareas de mantenimiento automáticas permite a la base de datos
Oracle realizar de manera automática tales operaciones. Utiliza el programador para ejecutar las tareas
en ventanas de mantenimiento predefinidas.
Por defecto, las ventanas de mantenimiento de los días laborables empiezan a las 10:00 p.m. y duran 4
horas. Los sábados y los domingos, la ventana de mantenimiento empieza a las 6:00 a.m. y dura 20 horas.
Todos los atributos de las ventanas de mantenimiento se pueden personalizar, entre los que se incluyen
la hora de inicio y finalización, la frecuencia, los días de la semana, etc. Asimismo, para poder limitar el
impacto de las tareas de mantenimiento automáticas en operaciones habituales de la base de datos, se
tiene que asociar un plan de recursos del Gestor de Recursos de la Base de Datos a una ventana de
mantenimiento.
Ejemplos de mantenimiento:
- Las estadísticas del optimizador se refrescan automáticamente mediante el uso de la infraestructura
de tareas de mantenimiento automáticas.
- El Asesor de Segmentos Automático tiene trabajos por defecto, que se ejecutan en la ventana de
mantenimiento.
- Al crear una base de datos con DBCA, puede iniciar la realización de copias de seguridad periódicas de
bases de datos.
Haga clic en Automated Maintenance Tasks, en la cabecera Scheduler de la página Server, para acceder a
la página Automated Maintenance Tasks, en la que se visualizan el programa de las tareas de
mantenimiento automáticas, así como el historial reciente. Desde aquí, puede aumentar los detalles de
algunas tareas. Haga clic en Configure para ir a la página Automated Maintenance Tasks Configuration.

Una tarea se ejecuta en una ventana. El gráfico muestra la última ventana en la que se ha ejecutado una
tarea y la siguiente ventana en la que está programada su ejecución.
Nota: en el ejemplo se muestran las ventanas por defecto para las tareas. Cuando se cierra la ventana de
mantenimiento, el programador termina el trabajo de recopilación de estadísticas del optimizador por
defecto. Los objetos restantes se procesan en la próxima ventana de mantenimiento.
En la página Automated Maintenance Tasks Configuration se pueden activar y desactivar las tareas de
mantenimiento automáticas todas a la vez, de manera individual o según ventanas concretas.
También se pueden configurar los valores utilizados para la recopilación de estadísticas del optimizador y
los parámetros de control de los trabajos del Asesor de Ajustes SQL automático.
Seleccione el nombre de la ventana para visualizar o editar su programa.
Haga clic en Edit Window Group para agregar y eliminar ventanas del grupo de ventanas

2. Alertas Generadas por el Servidor

Las alertas sirven para notificar cuándo una base de datos está en un estado no deseado y necesita
atención. Por defecto, la base de datos Oracle proporciona alertas a través de Enterprise Manager
Database Control. Opcionalmente, Enterprise Manager se puede configurar para enviar un mensaje de
correo electrónico al administrador acerca de las condiciones del problema, así como para mostrar la
información de alerta en la consola.
También puede definir los umbrales en varias de las métricas pertinentes para el sistema. Oracle
Database 11g notificará de forma proactiva si la base de datos se desvía de las lecturas normales lo
suficiente como para alcanzar dichos umbrales. Una notificación anticipada de posibles problemas
permite responder rápidamente y, en muchos casos, resolver problemas antes incluso de que los usuarios
los adviertan.
Se supervisan unas 60 métricas por defecto, entre otras, las siguientes:
- Broken Job Count
- Database Time Spent Waiting (%)
- Dump Area Used (%)
- SQL Response Time (%) (compared to baseline)
- Tablespace Used (%)
- Generic Incident
Algunas otras métricas clave pueden proporcionar una notificación anticipada del problema:
- Average File Read Time (centiseconds)
- Response Time (per transaction)
- Wait Time (%)
3. Definición de Umbrales
Para definir o editar un umbral para toda la base de datos, haga clic en “Metric and Policy Settings” en la
región Related Links de la página inicial de la base de datos. Introduzca los valores deseados para los
umbrales crítico y de advertencia. Aparecerán las alertas adecuadas cuando la base de datos alcance los
valores especificados.
Los umbrales que ya están definidos aparecen en la lista “Metrics with thresholds”. Por defecto, alrededor
de 60 métricas tienen umbrales predefinidos; puede cambiarlos según sea necesario. La lista “All metrics”
muestra las métricas que no tienen umbrales definidos.
Haga clic en uno de los iconos Edit para acceder a una página en la que puede especificar acciones
correctivas adicionales para los umbrales críticos o de advertencia.
Haga clic en un enlace Collection Schedule para cambiar el intervalo de recopilación programado.
Tenga en cuenta que cada programa afecta a un grupo de métricas.

4. Creación y Prueba de una Alerta

También se pueden definir umbrales para un objeto concreto.
Ejemplo: El usuario decide que necesita recibir una alerta crítica si el espacio utilizado en el tablespace
INVENTORY supera el 75%. (Este tablespace no permite que los archivos de datos se amplíen
automáticamente.) Para crear y probar la alerta, realice los siguientes pasos:
1. En Enterprise Manager, acceda a la página “Metrics and Policy Settings” y, a continuación, haga clic en
el icono Edit correspondiente al umbral Tablespace Used (%). Defina el umbral deseado para el
tablespace.
2. En el separador Schema de la página Tables, cree una tabla para probar la alerta. Utilice la acción
“Define using SQL” para duplicar una tabla ya existente. Con la configuración inicial de 8 MB de la
cláusula STORAGE, la tabla asigna el 80% del tablespace INVENTORY de 10 MB inmediatamente.
3. Después de haber recibido un error informándole de que la tabla no se puede ampliar, compruebe la
página inicial de la base de datos para ver alertas relacionadas. Tablespace Space Used (%) se recopila
cada 10 minutos por defecto.
La mayoría de las alertas contiene el nombre de un asesor asociado al que se puede llamar para obtener
consejo detallado. Database Control ofrece un enlace para llamar al asesor correspondiente a cada
mensaje de alerta.
5. Notificación de Alertas
El mecanismo de notificación utiliza la interfaz de usuario de Enterprise Manager. Se basa en el concepto
de una regla de notificación que establece el mecanismo de notificación adecuado para un juego de
próximas alertas.
Database Control permite editar las reglas de notificación. En la página inicial, haga clic en el enlace
Preferences para mostrar la página General, en la que especifica la dirección de correo electrónico en la
que desea recibir las notificaciones.
En la página General, haga clic en el enlace Rules de la región Notification. Seleccione la regla “Database
Availability and Critical States” y haga clic en el botón Edit. Aparecerá la página “Edit Notification Rule
Database Availability and Critical States”, donde podrá hacer clic en el separador Metrics y editar las
métricas para las que desee recibir notificación

Como opción, puede especificar si desea que Enterprise Manager le proporcione una notificación directa
cuando se produzcan determinadas alertas. Por ejemplo, si especifica que desea una notificación por
correo electrónico de las alertas críticas y tiene definido un umbral crítico para el tiempo de respuesta del
sistema de cada métrica de llamada, puede enviar un mensaje de correo electrónico que contenga un
mensaje similar al siguiente:
Host Name=mydb.us.mycompany.com
Metric=Response Time per Call
Timestamp=08-NOV-2005 10:10:01 (GMT -7:00)
Severity=Critical
Message=Response time per call has exceeded the threshold. See
the latest ADDM analysis.
Rule Name= Rule
Owner=SYSMAN
El correo electrónico contiene un enlace al nombre del host y el último análisis de ADDM.
Por defecto, está configurada la notificación de alertas en estado crítico (como en el caso de que la base de
datos esté inactiva, estado de error del log de alertas genéricas y tablespace usado). Sin embargo, para
recibir estas notificaciones, debe configurar la información de correo electrónico realizando los siguientes
pasos:
1. En cualquier página de Database Control, haga clic en el enlace Setup de la cabecera o del pie de
página.
2. En la página Setup, seleccione Notification Methods.
3. Introduzca la información necesaria en la región Mail Server de la página Notifications Methods.
Existen otros métodos de notificación, entre los que se incluyen scripts e interrupciones SNMP
(Simplified Network Management Protocol). Este último se puede utilizar para comunicarse con
aplicaciones de terceros.
Para recibir notificaciones:
1. En cualquier página de Database Control, haga clic en el enlace Preferences de la cabecera o del pie de
página.
2. En la página Preferences, seleccione General. Introduzca la dirección de correo electrónico en la
región E-mail Addresses.
3. De manera opcional, puede editar las reglas de notificación (por ejemplo, para cambiar el estado de
gravedad necesario para recibir una notificación). Para ello, haga clic en Notification Rules. Aparece la
página Notification Rules.

Nota: para obtener más información sobre la configuración de las reglas de notificación, consulte la
documentación Oracle Enterprise Manager Advanced Configuration (Configuración Avanzada de Oracle
Enterprise Manager)
6. Reacción ante Alertas
Al recibir una alerta, siga las recomendaciones que se le proporcionan. También se puede plantear
ejecutar ADDM (o cualquier otro asesor adecuado) para obtener un diagnóstico más detallado del
comportamiento del sistema o del objeto.
Se generan alertas e incidentes para los errores críticos. Los errores críticos suelen generan incidentes
que se recopilan en problemas. Utilice Support Workbench para investigar y, posiblemente, informar del
problema a los Servicios de Soporte Oracle.
La mayoría de las alertas (como, por ejemplo, “Out of Space”) se borra automáticamente cuando
desaparece la causa del problema. Sin embargo, con otras alertas (como, por ejemplo, el error del log de
alertas genéricas), se envía al usuario una notificación y el usuario deberá confirmarla. Después de tomar
las medidas correctivas necesarias, confirme una alerta borrándola o depurándola. Al borrar una alerta,
ésta se envía al historial de alertas, que se puede visualizar desde la página inicial en Related Links. Al
depurarla, se elimina del historial de alertas.
Para borrar una alerta como, por ejemplo, el error del log de alertas genéricas, haga clic en el enlace Alert
Log de la página inicial bajo Diagnostic Summary. Aparece la página Alert Log Errors.
Seleccione la alerta que desea borrar y, a continuación, haga clic en Clear. Para depurar una alerta,
selecciónela y haga clic en Purge. También puede hacer clic en los botones Clear Every Open Alert o Purge
Every Alert.

C. Seguridad de la Base de Datos

La seguridad de las bases de datos es importante para evitar la fuga de información de la empresa,
además, de lograr una razonable estabilidad de la información y prevenir futuros accesos no autorizados
que interrumpan el flujo normal de la empresa.
Este tema abarca los siguientes puntos:
1. Seguridad de Accesos
La seguridad de accesos se refiere al nivel de seguridad de los datos almacenados en la Base de Datos
para evitar alguna alteración de la información. La política de toda empresa con respecto a la seguridad
de accesos deberá contemplar los siguientes ítems:
 Lo información almacenada en la Base de Dato deberá recibir un apropiado nivel de protección.
 La información se deberá categorizar para así obtener su frecuencia de uso y grado de protección
que deberá tener.
 Se deberá crear un sistema para clasificar la información para así definir apropiadamente su nivel
de protección. La siguiente tabla se muestra algunos criterios para esta clasificación:
Criterios
Criterio Código Descripción
Datos personales DP Existencia de datos que son personales y que no deben divulgarse
Variabilidad VP Existirán datos que cambien poco o existe, relativamente, un gran lapso
de tiempo antes de que se lleguen a modificar, y a estos habrá que darles
un tratamiento especial
Confidencialidad CD Existencia de datos que deben permanecer secretos en la organización
Datos DF Son datos sobre estados financieros que no deben ser divulgados
Financieros
 Los niveles de protección deberán de contemplar las necesidades de la empresa
 Los informes extraídos de la Base de Datos como por ejemplo reportes deberán ser clasificadas
según su valor y grado de accesibilidad.
 Por último se deberán crear usuarios y roles para que accedan a la información clasificada, esto
se detallará en el capítulo siguiente.
2. Seguridad de Usuarios
La seguridad de usuarios es usada para darles privilegios a los distintos usuarios de una base de datos.
Estos privilegios serán para ejecutar sentencias SQL, alterar el funcionamiento de la Base de Datos o para
alterar la forma de la Base de Datos. Deberá de existir una política definida para la seguridad de usuarios
y accesos de estos a la Base de Datos.
Se deberá crear horarios de acceso para los diferentes usuarios y así registrar todo acceso no autorizado
o fuera de horario que los usuarios tengan a la Base de Datos.
Se deberán de crear roles para los distintos usuarios de la Base de Datos, clasificarlos y catalogarlos, para
su correcta asignación a los usuarios. Se deberá realizar las siguientes actividades o procesos:
 Crear un usuario: Toda administración de bases de datos requerirá la creación de usuarios para
tener acceso a la información.
 Eliminar o inactivar un usuario: Cuando un usuario deja de ser necesario, este deberá ser
inactivado o eliminado, para evitar el acceso a la información dentro de la Base de Datos.
 Modificar un perfil: Para modificar o actualizar la información del perfil seguridad de un usuario
 Dar privilegios a un usuario: para que un usuario pueda trabajar sobre diversas tablas, vistas,
procedimientos y demás elementos de la Base de Datos, este deberá de poseer privilegios para
poder tener acceso a estos elementos.
 Quitar privilegios a un usuario: Con el transcurrir del tiempo, un usuario puede perder
privilegios sobre elementos dentro de la base de datos, y estos deberán ser eliminados de
inmediato.

 Crear Roles: Al manejar varios usuarios, e incontable número de privilegios que este puede llegar
a tener, es útil manejar roles; así, podremos dar los mismos privilegios a distintos usuarios que
cumplen con el mismo rol.
 Modificar Roles: Un rol también puede ganar o perder privilegios a lo largo de su vida útil.
 Eliminar Roles o inactivarse: Cuando un rol deja de ser útil, este debe de eliminarse.
 Asignar roles a un Usuario o a un role: Una vez creado algún rol, este no será útil hasta que se le
asigne a algún usuario.
3. Autenticación en Oracle
Cuando los usuarios desean conectarse a la base de datos Oracle para realizar sus funciones, esta se
asegura de que están autorizados a acceder, por medio del proceso de autenticación. La autenticación
puede ser realizada de varias maneras, podemos definir el usuario en la base de datos y autenticarlo, o
definirlo en otro lugar, como por el ejemplo el sistema operativo o un servidor LDAP como Oracle
Internet Directory, y pasarle los credenciales como validos a la base de datos.
Hay dos maneras por las cuales las base de datos autentica usuarios: Por contraseña; Por autenticación
por parte del sistema operativo (OS authentication).
Veamos las diferencias entre estos dos tipos de autenticación.
– Autenticación por medio de contraseña:
create user Scott identified by tiger;
Con esta instrucción creamos el usuarios “scott” autenticado el nuestra base de datos por medio de la
contraseña “tiger”. Esto nos crea la entrada de este usuario en el diccionario de datos en la tabla USERS$
propiedad del usuario SYS. Cuando el usuario se conecta por medio de alguna aplicación cliente este
comprobara en el diccionario de datos si los datos introducidos son correctos.
– Autenticación por medio del Sistema Operativo:
La autenticación por medio de sistema operativo son realizadas por las que en Oracle se denominan
cuentas de usuarios OPS$.
Create user ops$jesus Identified externally;
Con esta instrucción creamos en Oracle el usuario “jesus” y le indicamos a la base de datos de que este
usuario se autenticará por parte del sistema operativo. Este usuario se conectara a la base de datos
usando la siguiente sentencia: connect /
Ahora Oracle comprobará si el usuario “jesus” se encuentra autenticado en el sistema operativo y por lo
tanto podrá conectarse al a base de datos sin necesidad de que se le pida la contraseña.
4. Almacenamiento de las Passwords en Oracle:

Las contraseñas en Oracle son almacenadas por defecto en el tablespace SYSTEM de nuestra base de
datos. Estas contraseñas se almacenan encriptadas con un algoritmo SHA-1 (Contraseña ||Semilla).
Lo más lógico es pensar que haciendo un SELECT password FROM dba_users podríamos ver la versión
encriptada de las contraseñas, pero esto dejo de ser posible en la versión 11g.
Oracle 11g ofrece la posibilidad de usar password de hasta 50 caracteres distinguiendo mayúsculas de
minúsculas. En Oracle 11g los passwords son encriptados con DES en la (columna password) y usando
SHA-1 (columna spare4).
En la versión 11g el hash de la contraseña no es accesible vía dba_users ahora hay que hacerlo mediante el
usuario SYS con la siguiente SELECT:
SYS.USER$ : SELECT name,spare4 FROM SYS.USER$ WHERE password is not null;
Donde spare4 es el hash de la contraseña.
La encriptación SHA-1 y DES a día de hoy no se ha roto aunque ya se aconseja usar cifrado TRIPLE-DES,
por lo que se considera bastante segura aunque no evitamos así ataques de diccionario o mediante fuerza
bruta.

5. Vulnerabilidad de contraseñas en ORACLE.

Oracle pese a ser un sistema con amplias opciones de seguridad presenta algunas vulnerabilidades que
podemos corregir.
Como vimos anteriormente el cifrado de las contraseñas de Oracle es SHA-1 con semilla, este algoritmo es
bastante seguro a día de hoy ya que no se ha roto, pero esto no impide a los atacantes realizar ataques de
fuerza bruta o de diccionario. Hay numerosas herramientas que encriptan el usuario y el password y lo
comparan con el hash. Si el hash es idéntico al almacenado en la base de datos ya sabremos cual es el
password. Desde simples herramientas basadas en SQL ( menos de 500 password por segundo) a
programas especiales realizados en C como chepwd. La herramienta más rápida calcula 1.100.000 de
passwords por segundo. En un Pentium 4 con 3GHz toma el siguiente tiempo:
• 10 segundos para calcular todas las combinaciones de 5 caracteres ascii.
• 5 minutos para calcular todas las combinaciones de 6 caracteres ascii.
• 2 horas para calcular todas las combinaciones de 7 caracteres ascii.
• 2,1 días para calcular todas las combinaciones de 8 caracteres ascii.
• 57 días para calcular todas las combinaciones de 9 caracteres ascii.
• 4 años para calcular todas las combinaciones de 10 caracteres ascii.
Como podemos ver nuestra base de datos está expuesta a estos tipos de ataques y debemos intentar
mitigar sus efectos con algunas de las siguientes medidas.
 Crear una función de verificación de contraseñas lo suficientemente estricta. Esta función deberá
verificar que la longitud sea lo suficientemente amplia y que contenta caracteres especiales, así como
que no la contraseña no sea demasiado simple o palabras que se encuentren en algún diccionario y
otras muchas opciones que podemos programar con PL/SQL.
 Configurar en los perfiles las siguientes opciones de PASSWORD:
PASSWORD_LIFE_TIME → Tiempo de Vida del Password
PASSWORD_GRACE_TIME → Número de días disponibles para cambiar el password antes de que se
bloque la cuenta.
PASSWORD_REUSE_TIME → Número de días hasta volver poder utilizar el mismo password.
PASSWORD_REUSE_MAX → Número de veces que se puede reusar el mismo password.
Las dos siguientes declaraciones son muy importantes para evitar los ataques con fuerza bruta o de
diccionario:
FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 10
Estableciendo un número determinado de veces que el login del usuario puede fallar limitamos
al atacante a que tenga que esperar que la cuenta se desbloquee después de realizar 3 intentos de
ataques con diccionario o fuerza bruta, lo que provoca que no pueda realizar mas ataques a dicho
usuario mientras su cuenta este bloqueada.
 Baneo de direcciones Ip que intenten excesivas conexiones fallidas con la BD. En la red
disponemos de varias herramientas para el crackeo y hacking de bases de datos Oracle. Podemos ver
una lista de estas herramientas y sus ventajas e inconvenientes en el siguiente sitio web:
http://www.red-database-security.com/whitepaper/oracle_password_cracker.html
La autentificación contra bases de datos Oracle también posee de otras vulnerabilidades que el
administrador debe controlar después de la instalación de una base de datos Oracle:
 Autenticación como SYSDBA sin contraseña. Algunos administradores después de instalar una base
de datos Oracle en sistemas Windows se olvidan de que en la instalación se crea el grupo ora_dba y
se añade automáticamente el usuario que creo la base de datos. Esto provoca que el usuario del
sistema operativo que creo la base de datos pueda tener acceso a todos los datos entrando como
SYSDBA y sin necesidad de introducir contraseña alguna. Para evitar esto debemos sacar del grupo
ora_dba al usuario correspondiente.

 Usuarios y contraseñas por defecto. Oracle trae por defecto numerosos usuarios por defecto con
contraseñas ya establecidas que se pueden encontrar por toda la red. Para ver los usuarios con
password por defecto podemos usar la vista del diccionario de datos siguiente:
SELECT * FROM dba_users_with_defpwd;
Debemos desactivar aquellas cuentas que no usemos y que se encuentren habilitadas y cambiar el
password de aquellas que aparecen en la vista.
 Si hay acceso físico estas vendido. Si el atacante tiene acceso directo físico a nuestro servidor de
base de datos o logro entrar remotamente puede atacarnos de diferente manera usando la aplicación
cliente de nuestros usuarios. Un atacante podría modificar el fichero
%ORACLE_HOME%\sqlplus\admin\glogin.sql o %ORACLE_HOME%\sqlplus\admin\login.sql y
insertar código SQL o comandos de la consola de SQL * Plus que le permita obtener datos y copiarlos
a una base de datos remota o como veremos a continuación crearse un usuario automáticamente.
Si el atacante accede y nos modifica el fichero glogin.sql de la siguiente manera:
CREATE USER hacker identified by hackchack1;
grant connect to hacker;
grant dba to hacker;
CLEAR SCREEN
Esto provocará la creación de un usuario para el atacante en el momento en el que algún usuario con
los privilegios correspondientes se loguee en Sql*plus sin que se de cuenta aparentemente.
 Contraseñas en claro por los clientes y servicios. Una vulnerabilidad no propia de Oracle pero
igualmente importante es que las contraseñas de nuestros usuarios se manden en claro o
permanezcan en claro en ficheros de configuración o ficheros de código fuente de sus aplicaciones.
Por ejemplo para realizar una conexión desde una aplicación PHP a Oracle la contraseña y el usuario
debe estar indicado en el código PHP de la aplicación. Por lo tanto debemos proteger y adecuar los
permisos correspondientes a ficheros que contengan datos de identificación contra la base de datos.
Otros métodos para proteger nuestra base de datos seria cifrar todo el contenido de la BD, el uso de
identificación biométrica vía reconocimiento facial, dactilar, vocal y otros métodos.
Si tenemos en cuenta todas estas vulnerabilidades y seguimos todos los pasos necesarios para corregirlas
e impedir al atacante el acceso del sistema tendremos nuestros datos más seguros.
1) Seguridad de Accesos
a. Obtener el diagrama de la Base de Datos, en caso de que no exista proceda a crearlo.
b. Aplicar los criterios de seguridad establecidos por la empresa a cada campo de las tablas de la
Base de Datos.
c. Clasificar los resultados obtenidos para determinar así el nivel de acceso de la información
d. Proceda a llenar el registro
Clasificación de la información:
Nivel Color Significado
2) Creación y autenticación de Usuarios

A. Crear usuarios
a. Conectarse a la base de datos como un administrador de base de datos del sistema.
b. Ejecutar la sentencia sql para crear usuarios:
create user username identified by password;
Donde: username #Es el nombre del usuario a crear.
password #Es la contraseña de este usuario.
c. Llenar el registro correspondiente
Motivo de la creación de usuario: Referencia a la solicitud:
Fecha y hora de creación: Fecha y hora de petición:
Nombre de usuario: Observaciones generales:
B. Crear usuarios por medio del EM (Enterprise Manager)

Desde Oracle Enterprise Manager, para crearlos, nos dirigimos a la pestaña "Servidor". En la categoría
"Seguridad" elegimos "Usuarios". Una vez dentro podremos ver todos los usuarios que se encuentran
en la base de datos:
Como podemos observar, en esta pantalla aparecen las cuentas de usuario de la BD y otras
características como el tablespace por defecto, el perfil, la fecha de creación, etc.
Para añadir un usuario nuevo basta con pulsar sobre el botón "Crear".
Nos enviará a otra pantalla donde introduciremos los credenciales.
En la pestaña "General" introducimos nombre y contraseña del nuevo usuario, además de añadirlo a
un tablespace por defecto y temporal. Se puede también seleccionar el perfil que tendrá el usuario.
En la pestaña "Roles" podemos seleccionar el rol que tendrá el usuario simplemente añadiendolos a
la lista. Los añadimos pulsando en el botón "Editar lista", y elegimos los roles de los que dispone la
BD.
De la misma forma añadimos los privilegios de objetos y del sistema, esta vez pulsando sobre el botón
"Agregar" y pasando los permisos desde la ventana izquierda, que son los disponibles en la BD, a la
derecha que son los que se les dará al usuario.
En la pestaña "Quotas" observaremos los tablespaces que existen en el sistema. Para que el usuario
pueda escribir en ellos seleccionamos una quota en el menú desplegable, donde podemos elegir entre
ninguna, que no tendrá quota, ilimitada, que no tendrá límite de escritura, y valor, que será el valos
que le asignemos en la siguiente columna.
Para crear el usuario definitivamente con la opciones configuradas pulsamos el botón "Aceptar"
Una vez creado tenemos distintas opciones, como por ejemplo bloquearlo, borrarlo, editarlo, etc.
Editar al usuario es la misma función que tiene "ALTER USER".
Cabe destacar que al atribuirle los privilegios al usuario, sean de sistema o sobre objetos, existe la
opción de pasar a otros usuarios ese mismo permiso. En el caso de que sea provilegios de sistema,
activamos "Opción Admin" para que este pueda pasar esos mismos permisos. Es equivalente a "WITH
ADMIN OPTION", usado cuando se añaden permisos al usuario desde la línea de comandos, al usar
"GRANT". En el caso de los permisos sobre objetos, de la misma forma, podemos activar la opción
"Opción Otorgar", que permite al usuario pasar esos permisos de objetos a otros usuarios.
Equivalente a "WITH GRANT OPTION", en línea de comandos al usar "GRANT".
Para eliminar privilegios de un usuario, accedemos a la configuración del usuario y lo editamos. Al
pasar a las pestañas de privilegios, sean de sistema o de objetos, podremos editar la lista de
privilegios y eliminarlos de ella.

C. Modificar un Perfil
Los perfiles tienen la función de limitar los recursos o configurar la forma de logearse en el sistema
mediante la contraseña. Se usan para aplicarselos a numerosos usuarios, ya que aplicar los límites
usuario por usuario es una tarea engorrosa. Crear perfiles y otorgarlos a usuarios en el interfaz web
es muy intuitivo y no precisa dificultad.
Para ver los perfiles disponibles en la BD accedemos a la pestaña "Servidor", sección "Seguridad",
"Perfiles". Aquí vemos los perfiles disponibles.
Si queremos ver que usuario tiene que perfil, seleccionamos cualquier perfil con la columna
"Seleccionar" y en "Acciones" elegimos "Mostrar dependencias". A continuación pulsamos en "Ir".
Se nos mostrará dos pestañas que serán "Dependencias" y "Dependientes". En la primera se
mostrarán los objetos de los que depende el perfil, y el segundo son los objetos a los que se le han
concedido el perfil. En el caso del perfil "Default" en la pestaña "Dependientes" veremos los usuarios
que tienen dicho perfil.
En la lista de los perfiles, si seleccionamos en "Acciones" la opción "Generar DDL", veremos la
sentencia con la que se creó el perfil:
Podemos ver las limitaciones que contiene el perfil "Default", que es el que se asigna por defecto al
crear un usuario. Pero si queremos ver esos límites de forma mas clara solo basta con seleccionar el
perfil y pulsar sobre el botón "Ver". Aquí veremos de forma ordenada las limitaciones. Para modificar
el perfil está el botón "Editar" y para eliminarlo el botón "Suprimir". Si queremos crear un nuevo
perfil, pulsamos sobre "Crear". Aquí escribimos el nombre del nuevo perfil y ponemos las
limitaciones. También tenemos la ayuda del icono de la derecha de cada bloque para buscar los
límites disponibles en la BD, que son ejemplos. En caso de que queramos ver la sentencia SQL
resultante antes de crear el perfil solo tenemos que pulsar en "Mostrar SQL". Veremos la sentencia
con la que se va a crear el perfil que estamos creando en la interfaz web.
En la pestaña "Contraseña" podemos configurar los límites referidos a las contraseñas, así como el
tiempo en días de bloqueo al intentar acceder erroneamente, la complejidad de la contraseña, etc.
Para asignar los perfiles a los usuarios, tenemos que editar los usuarios y seleccionar el perfil elegido.

D. Eliminar Usuario
b. Ejecutar la sentencia sql para eliminar usuarios:
drop user username [cascade];
Donde: username #Es el nombre del usuario a eliminar.
CASCADE # Elimina todos los objetos creados por el usuario (opcional).
Motivo de la eliminación de usuario: Referencia a la solicitud:
Fecha y hora de eliminación: Fecha y hora de petición:
E. Modificar Usuario
b. Ejecutar la sentencia sql para modificar usuarios:
alter user username options;
Donde: username #Es el nombre del usuario a modificar.
options # Son las diferentes opciones que puede llegar a modificar como:
IDENTIFIED BY password[REPLACE old_password] Cambiar la contraseña
IDENTIFIED EXTERNALLY La cuenta es externa y tiene que ser validada con el sistema operativo.
IDENTIFIED GLOBALLY AS external_name La cuenta se autentica globalmente
DEFAULT TABLESPACE tablespace Tablespace por defecto
TEMPORARY TABLESPACE tablespace tablespace temporal
QUOTA int {K | M} ON tablespace Asigna un espacio en megabites o kilobites en el tablespace por defecto
QUOTA UNLIMITED ON tablespace Asigna un espacio ilimitado en el tablespace por defecto
PROFILE profile_name Asignacion de un perfil
DEFAULT ROLE role [,role,...] Hace que el usuario tenga algun rol por defecto
DEFAULT ROLE ALL [EXCEPT role,...] Hace que el usuario tenga todos los privilegios
DEFAULT ROLE NONE Hace que el usuario no tenga rol por defecto
Establece que el password del usuario expirará en forma automática y, por
PASSWORD EXPIRE
lo tanto, deberá cambiarlo al iniciar su próxima sesión.
ACCOUNT {LOCK|UNLOCK} Permite establecer si la cuenta debe permanecer bloqueada o no.
Motivo de la modificación de usuario: Referencia a la solicitud:
Fecha y hora de odificación: Fecha y hora de petición:
F. Dar privilegios a un Usuario
b. Ejecutar la sentencia sql para dar privilegios usuarios:
grant privileges on object to username;
Donde:
username # Es el nombre del usuario al cuál le daremos un privilegio
privileges # Distintos privilegios posibles
object # Objeto sobre el cual actúan los privilegios.
Motivo de la asignación de privilegios: Responsable de la asignación de privilegios:
Fecha y hora de asignación: Fecha y hora de petición:
Privilegios asignados:
G. Quitar privilegios a un Usuario
b. Ejecutar la sentencia sql para quitar privilegios usuarios:
revoke privileges on object to username;
Donde: username # Es el nombre del usuario al cuál le quitaremos un privilegio
privileges # Distintos privilegios posibles, en Oracle existen 81 diferentes privilegios.
object # Objeto sobre el cual actúan los privilegios.


Motivo de la eliminación de privilegios: Fecha y hora de eliminación:
Fecha y hora de petición: Privilegios eliminados:
H. Crear un Rol
Los roles son conjuntos de privilegios que podemos otorgarselos a los usuarios y de esta forma
ahorrarnos tiempo si queremos añadir los mismos privilegios a muchos usuarios.
Desde la línea de comandos creamos los roles con "CREATE ROLE nombrerol" y después le asignamos los
permisos como si se trataran de usuarios, para después, otorgar esos roles a los propios usuarios
b. Digitar la instrucción para la creación del role, con la siguiente estructura:
create role role_name [NOT IDENTIFIED] | [IDENTIFIED [BY password]
[EXTERNALLY] | [GLOBALLY]]
c. Llenar el registro correspondiente Creación de roles
Nombre creador: Nombre solicitante:
Fecha de solicitud:
Lista de roles nuevos creados:
Tipo
Nombre Rol Clave Externally (Si o No) Globally (Si o No)
(Not Identified o Identified)
Desde Oracle Enterprise Manager, los roles se crean accediendo a la pestaña "Servidor" y a
continuación, en la sección "Seguridad", a "Roles". Una vez dentro, veremos los roles que se encuentran
en la base de datos del sistema, viendo algunos conocidos como el rol DBA, RESOURCE o CONNECT
Aquí podemos configurar cada rol simplemente seleccionandolo en la colúmna "Seleccionar" y después
pulsando sobre "Editar".
Si pulsamos sobre el rol RESOURCE, veremos los privilegios que contiene.

En la imagen aparecen los privilegios que posee el rol, en este caso tiene los necesarios para los
programadores. No se le ha asignado ningún rol y ninguno de los permisos tiene la opción para pasarlo a
otros usuarios. No tiene privilegios de objetos y no tiene asignado ningún grupo de consumidores. Si
queremos crear uno desde cero, solo basta con pulsar el botón "Crear" en la pantalla "Roles". Aquí, le
damos un nombre y le asignamos los privilegios y roles de la misma forma que si fuera un usuario. Ahora,
el nuevo rol que creamos podemos asignarselo a cualquier usuario de la BD.
I. Modificar un Rol
b. Ejecute la siguiente sentencia con el nombre del role que va a modificar:
alter role nombre_role
[NOT IDENTIFIED] | [IDENTIFIED [BY password_role]
[EXTERNALLY] | [GLOBALLY]
Nombre creador:
Nombre solicitante: Fecha de solicitud:
Lista de roles modificados:
Tipo
Nombre Rol Clave Externally (Si o No) Globally (Si o No)
(Not Identified o Identified)
J. Eliminar un Rol
b. Si se desea eliminar por completo un role digite la siguiente instrucción:
drop role role_nombre
c. Si se desea desactivar un role digite la siguiente instrucción:
set role role_nombre

d. Llenar el registro correspondiente

Nombre creador:
Nombre solicitante: Fecha de solicitud:
Lista de roles borrados o desactivados:
Cascade
Nombre Rol Borrado o desactivación
(Si o No)
K. Asignar un Rol a un Usuario o Rol

b. Digitar la instrucción para la creación del role, con la siguiente estructura:
grant role_nombre to nombre_usuario_o_role
Nombre creador: Nombre solicitante:
Fecha de solicitud:
Lista de roles borrados o desactivados:
Nombre Rol Nombre del usuario o role
3) Autenticación de Usuarios
A. Autenticación por medio del SO Linux XE
a. Creamos el usuario en el sistema operativo
# useradd lucas
# passwd lucas
Changing password for lucas.
b. Configuramos los parámetros siguientes:
La autenticación por sistema operativo no esta activada por defecto en Oracle XE. Para permitir el
uso de usuarios del sistema operativo, llamados por Oracle OPS$ users, abrimos SQL Plus o algún
cliente SQL y ejecutamos el siguiente comando:
alter system set os_authent_prefix=OPS$ scope=spfile;
Nos modifica el fichero binario:
cat /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/dbs/spfileXE.ora
Este contiene parámetros de configuración de la instancia que se esta ejecutando.
Reiniciamos la DB:
shutdown immediate
Startup
Creamos el usuario en nuestra base de datos:
CREATE USER OPS$lucas IDENTIFIED EXTERNALLY DEFAULT;
Le aplicamos los roles y privilegios como cualquier otro usuario:
GRANT CONNECT, RESOURCE TO lucas;
c. Reiniciamos la base de datos:
/etc/init.d/oracle-xe restart
d. A continuación, tratamos de conectarnos a Oracle como un usuario del sistema operativo
autenticado. Esperamos que falle! Quizás sea necesario configurar algunas variable de entorno
para que SQL * PLUS funcione correctamente.
Vemos la configuración actual de SQL * PLUS
#cat
/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/config/scripts/sqlplus.sh
# su - tim_hall
$ export ORACLE_HOME=”Dato Obtenido del cat enterior”
$ export PATH=”Dato Obtenido del cat enterior”
$ export ORACLE_SID=”Dato Obtenido del cat enterior” , XE
$ sqlplus /

En el ejemplo:
$export:ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
$export PATH=$PATH:$ORACLE_HOME/bin:$PATH
$export ORACLE_SID=XE
$sqlplus /
Para que se coloquen automáticamente al iniciar sesion un usuario, editar el archivo
/home/lucas/.bashrc y añadir las lineas 1, 2 y 3. y para que esta configuración la tengan usuario
que creemos en el sistema las añadimos al fichero /etc/skel/.bashrc .
B. Autenticación por medio del SO Windows
a. Creamos un usuario en el sistema operativo.
b. Configuramos los parámetros siguientes:
alter system set os_authent_prefix =OPS$ scope=spfile;
Nota: El valor por defecto es “OPS$”
Si el usuario del sistema operativo es miembro de un grupo de dominio entonces también
configuramos el siguiente parámetro:
alter system set remote_os_authent=TRUE scope=spfile;
Nota: El valor por defecto del parámetro es FALSE,
c. Editamos el fichero sqlnet.ora y cambiamos el valor de la siguiente linea a NTS:
Sqlnet.authentication_services=(NTS)
d. Reiniciamos la base de datos:
shutdown immediate
startup
Vemos que los parámetros se hayan modificado correctamente usando :
SQL> show parameter authen
NAME TYPE VALUE
----------------------- ----------- -------------
os_authent_prefix string OPS$
remote_os_authent boolean TRUE
e. Creamos un usuario Oracle para autenticación mediante OS
Primero comprobamos el nombre del usuario del sistema operativo.
SQL> select UPPER(sys_context('userenv','os_user')) from dual;
-------------------------------------------------------------------
NOMBREDELAMAQUINA\LUCAS
Ahora creamos el usuario con el mismo nombre que vimos con la sentencia anterior, incluido el
nombre de la máquina, añadiendo la clausula identified by EXTERNALLY.
create user OPS$NOMBREDELAMAQUINA\LUCAS identified EXTERNALLY;
Nota: El nombre del usuario de Oracle debe tener obligatoriamente el mismo nombre que el usuario y el
nombre de máquina del sistema operativo y al crearlo debe comenzar con “OPS$”.
Damos privilegios como a cualquier otro usuario :
SQL> grant dba to "OPS$MACHINENAME\TOM";
f. Testeamos la conexión a través del usuario del sistema operativo.
Sqlplus /
SQL> show user;
USER is "OPS$NOMBREDELAMAQUINA\LUCAS"
C. Funciones de verificación de contraseñas.
Una de las medidas de seguridad que podemos tomar en para proteger nuestra base de datos Oracle
es asignarle una función de verificación a las contraseñas de nuestros usuario para requerirles una
contraseña lo suficientemente segura; como por ejemplo de una longitud determinada, que contenga
caracteres especiales, números, que no sea igual que el nombre de usuario, etc.
En Oracle 11g podemos definir una función de verificación de contraseñas a los perfiles para ello
primero debemos crear una función de verificación de contraseñas, aunque Oracle trae esta
funcionalidad en el archivo $ORACLE_HOME/rbms/admin/utlpwdmg.sql.

Debemos ejecutar dicho script SQL con SQLplus como sysdba, esto nos creara la función
verify_function_11G y nos alterara el perfil por defecto de la siguiente manera:
ALTER PROFILE DEFAULT LIMIT
PASSWORD_LIFE_TIME 180
PASSWORD_GRACE_TIME 7
PASSWORD_REUSE_TIME UNLIMITED
PASSWORD_REUSE_MAX UNLIMITED
PASSWORD_VERIFY_FUNCTION verify_function_11G;
La función verify_function_11G comprobará que el password cumpla los siguientes requisitos:
- Comprueba que el password no es igual que el nombre de usuario
- Comprueba que el password tenga una longitud mínima de 4 caracteres.
- Comprueba que el password no sea una palabra simple de las dadas en una lista de palabras.
- Comprueba que el password contenga al menos una letra, un dígito y un signo de puntuación.
- Comprueba que el nuevo password se diferencie del anterior al menos en tres caracteres.
Esta función proporcionada por Oracle ya nos proporciona que nuestros passwords sean lo
suficientemente seguros, aunque también podemos crear nuestra propia función de verificación.
A continuación crearemos una función de verificación personalizada verifica_contra para que los
passwords cumplan las siguientes condiciones:
– Password diferente al nombre de usuario.
– Password de al menos 8 caracteres.
– Password fuera de la lista de passwords simples.
Script SQL:
create or replace
FUNCTION verifica_contra
(nombreusuario varchar2,
passwordnuevo varchar2,
passwordviejo varchar2)
RETURN BOOLEAN IS
BEGIN
/*Comprueba que el password no sea igual que el nombre de usuario
La función NLS_LOWER pasa a minúsculas la variable dada
raise_application_error lanza una excepción personalizado*/
IF NLS_LOWER(passwordnuevo) = NLS_LOWER(nombreusuario)
THEN raise_application_error(-20001, 'Password Igual que el usuario');
END IF;
/*Comprueba que la longitud mínima sea 8 caracteres */
IF length(passwordnuevo) < 8 THEN
raise_application_error(-20002, 'Password menor de 8 caracteres');
END IF;
/*Comprobación para que el password no este en la lista de passwords
simples*/
IF NLS_LOWER(passwordnuevo) IN ('welcome', 'database', 'account', 'user',
'password', 'oracle', 'computer', 'abcd', 'admin', '1234', '123456', 'tiger',
'administrador', 'asdasd', 'abc123abc' ,'contraseña')
THEN raise_application_error(-20003, 'Password demasiado simple');
END IF;
/*Si no ha habido errores devuelve TRUE*/
RETURN(TRUE);
END;
/
/*Creamos un perfil personalizado */
CREATE OR REPLACE PROFILE contra_dura LIMIT
PASSWORD_LIFE_TIME 30
PASSWORD_GRACE_TIME 7
PASSWORD_VERIFY_FUNCTION verifica_contra;

Con este script ejecutado como SYS crearemos la función y el perfil correspondiente que podremos
asignar a los usuarios de la base de datos.
Las ventajas de limitar los password a ciertas condiciones supondrá para los atacantes un mayor
esfuerzo para poder encontrar el HASH que corresponde con el password mediante ataque de
diccionario, a su vez aplicando FAILED_LOGIN_ATTEMPTS 4 evitamos los ataques de fuerza bruta
sobre nuestros usuarios aunque se les bloquerá la cuenta si se intentan realizar dicho ataque, pero
eso no supondrá un problema ya que nosotros como DBA podremos desbloquear la cuenta.
D. Respaldo de la Base de Datos

1. POLÍTICAS PARA EL MANEJO DE RESPALDOS.
Planear una buena política de copias de seguridad es la mejor forma de conservar la información ante un
error físico del sistema. Esta tarea es imprescindible para conservar la integridad de la base de datos ante
una “catástrofe”
1.1 Creación de respaldos. La política de respaldos se definirá con base en la solución de las siguientes
interrogantes:
¿Qué datos son importantes para la institución y cuál es su periodicidad de respaldo?
Los datos a respaldar y su periodicidad de respaldos serán las siguientes:
- Bitácoras de transacciones: los archivos producto del modo seguro de transacción será respaldados
una vez al día al cierre de operaciones ó al momento de menor cantidad de transacciones.
- Archivo de control: será respaldado una vez al día, creándose dos copias del mismo en caso de que una
de ellas llegue a fallar.
- Archivo de inicialización: se respaldará cada vez que sufra alguna modificación en su contenido.
- Archivos de datos: se respaldarán aquellos archivos de datos críticos para la organización una vez a la
semana.
¿En qué medios de almacenamiento vamos a guardarlos?
Los medios de almacenamiento a utilizar serán cintas magnéticas, CD’s, entre otros.
- Bitácoras y archivos de datos: la organización basará sus respaldos en la teoría de las tres cintas (hija,
madre y abuela). Estas cintas sufrirán un proceso de rotación conforme su uso.
- Archivo de control y archivo de inicialización: la institución almacenará estos respaldos en CD’s.
¿Dónde debe estar situada la copia de seguridad?
- Los respaldos serán trasladados a un sitio seguro que cumpla con las normas internacionales tanto de
confidencialidad de la ubicación del sitio como de calidad del ambiente.
- La divulgación de la ubicación del sitio, así como, la mala administración de las condiciones de
operación serán castigadas según las normativas internas de la organización e inclusive vía penal
dependiendo del tipo de daño causado.
1.2 Codificación de respaldos. La codificación de los respaldos se basará en los siguientes aspectos:
- Se codificarán los respaldos haciendo uso de un algoritmo de encriptación que brinde la mayor
seguridad a los datos.
- La clave para desencriptar la codificación de los respaldos será guardada bajo estrictas normas de
seguridad para evitar el plagio.
- La codificación seguirá un estándar preestablecido que facilite la búsqueda de respaldos en caso de
que se llegasen a necesitar.
- La empresa designará al personal correspondiente para que lleve a cabo la codificación de los
respaldos y los capacitará para que cumplan sus funciones de manera adecuada.
- Una vez que se hayan codificado los datos se procederá a llenar el correspondiente registro que haya
establecido la empresa.

1.3 Almacenamiento de respaldos. Se definen los siguientes criterios a evaluar:

Transporte del respaldo. Deberá realizarse en la fecha y hora establecida por la compañía llenándose el
registro que haga constar cuando y a que hora fue entregado el respaldo, además de quién lo entregó y
quién lo recibió. El transporte deberá contar con un clima óptimo para conservar el buen estado de los
respaldos.
Hospedaje de la información. El sitio donde se hospeden los respaldos deberá cumplir con los siguientes
aspectos:
- Altal seguridad y cerrado a personal no autorizado.
- Clima idóneo en el cual los datos se mantengan seguros tomando en cuenta la temperatura y
humedad.
- Instrumentos para constatar las condiciones del cuarto de almacenamiento.
- ALMACENAMIENTO por los años que indique la regulación interna del país.
- Se le permitirá a la organización realizar visitas periódicas para monitorear que se cumpla con las
normas establecidas.
2. TIPOS DE RESPALDOS A REALIZAR.
Las copias de seguridad o backups pueden ser físicas y lógicas:
Las FÍSICAS se realizan cuando se copian los ficheros que soportan la BD. Entre estos se encuentran los
backups del SO, los backups en frío y los backups en caliente.
 Backups del SO. Este tipo de backup implica parar la BD en modo normal y esto la hace inaccesible
el sistema mientras se lleva a cabo.
 Backups de la BD en Frio. Los backups en frio implican parar la BD en modo normal y copiar todos
los ficheros sobre los que se asienta. Antes de parar la BD hay que parar también todas las
aplicaciones que estén trabajando con la BD. Una vez realizada la copia de los ficheros, la BD se
puede volver a arrancar.
 Backups de la BD en Caliente. El backup en caliente se realiza mientras la BD está abierta y
funcionando en modo ARCHIVELOG. Habrá que tener cuidado de realizarlo cuando la carga de la BD
sea pequeña. Este tipo de backup consiste en copiar todos los ficheros correspondientes a un
tablespace determinado, los ficheros redo log archivados y los ficheros de control.
Las LÓGICAS sólo extraen información de las tablas utilizando comandos SQL y utilizando las
herramientas export e import.
 Backups Lógicos con Export/Import. Estas utilidades permiten al DBA hacer copias de
determinados objetos de la BD, así como restaurarlos o moverlos de una BD a otra. Estas
herramientas utilizan comandos del SQL para obtener el contenido de los objetos.
NOTA: Una vez que se ha planeado una estrategia de backup y se ha probado, conviene automatizarla
para facilitar así su cumplimiento
Según el tipo de archivo y el tipo de empresa se deben realizar diferentes tipos de respaldos .
 Respaldo Parcial.
o Para los archivos de control se debe generar un archivo de rastreo. Dicho archivo debe ser
modificado para su futuro uso.
o realizar un respaldo parcial.
o generar un archivo de rastreo.
 Respaldo Completo.
o Se utilizará un software especializado para respaldos..
El MODO ARCHIVELOG de una base de datos Oracle protege contra la pérdida de datos cuando se
produce un fallo en el medio físico.
1. Se puede realizar una copia de seguridad mientras la base de datos está on-line.
2. Con este modo de base de datos se puede restaurar una copia de seguridad de los archivos
dañados utilizando estos archivos para actualizar los archivos mientras están online.
3. Se puede recuperar la base de datos en un número de cambio del sistema específico.
4. Se puede restaurar la base de datos en un punto específico en el tiempo.

Alguna de las consecuencias que tiene desactivarlo son las siguientes:

 Las copias de seguridad ya no se pueden hacer on-line (habría que aplicar otro tipo de copias de
seguridad).
 No se podrá recuperar la base de datos en un tiempo concreto.
3. MÉTODO DE EXPORTACIÓN DE UNA BASE DE DATOS O DE UN OBJETO DE LA MISMA.
Constituye una utilidad adicional del sistema gestor de base de datos, utilizado para realizar traslados
de objetos o la base de datos completa de un lugar a otro. Así mismo llega a desfragmentar la base de
datos de manera completa. No se recomienda como método para realizar respaldos..
4. ELECCIÓN DEL MÉTODO DE BACKUP
Métodos disponibles:
METODO DE BACKUP TIPO VERSIÓN DISPONIBLE REQUERIMIENTOS
Recovery Manager (RMAN) Físico Oracle 8 ó mayor Almacenamiento en disco ó cinta
Herramienta de copia de archivos
Backup Manual (S.O.) Físico Todas las versiones
del sistema operativo
Export Lógico Todas las versiones N/A
Enterprise Backup Utility (EBU) Físico Oracle 7 Almacenamiento externo
Tipos de backup disponibles:
TIPO DE BACKUP RMAN BACKUP MANUAL EXPORT
Backup en frio (Cold Soportado - Requiere que la Soportado NO soportado
Backup – Closed Backup) instancia esté montada
Backup en caliente (Hot Soportado en forma automática Requiere los Requiere Undo para
Backup – Open Backup) comandos Begin/End mantener consuistencia
Backup
Backup Incremental Soportado NO soportado NO soportado
Detección de bloques Soportado. Se visualiza con las NO soportado Soportado. Se visualiza
corruptos vistas V$BACKUP_CORRUPTI ON en el Log
Catálogo de backups Soportado NO soportado NO soportado
Resguardo de archivos de Soportado Soportado NO soportado
inicio
Comandos Soportado NO soportado Soportado
independientes S.O
Elección del formato de Backup
- Juegos de Copias (Backup Sets)
- Copias Imágen
- Backups con comandos del sistema operativo
- Backups Lógicos
Desarrollar la estrategia de backup
- Decidir si ejecutar la instancia en modo ARCHIVELOG ó NOARCHIVELOG
- Multiplicar el Archivo de Control, Online Redo Logs, y Archived Redo Logs
- Determinación de la frecuencia de los backups
- Realización de backups cuando se realizan cambios estructurales
- Backups frecuentes de los tablespaces más utilizados
- Realización de backups despues de actividades irrecuperables (nolog)
- Almacenamiento de backups históricos
- Exportación de datos de la base de datos para obtener protección adicional y flexibilidad
NOTA: Nunca hacer backups de los archivos Redo Log a menos que sea un backup en frio.

1) Activar o desactivar el MODO ARCHIVELOG de base de datos Oracle

a. ¿En que modo trabaja nuestra BD?:
El comando archive log list nos muestra si la base de datos está en modo archivelog o
noarchivelog y si el archivado automático está funcionando. SQL> archive log list;
b. Activando el modo Archivelog:
Para que el modo archivelog esté activado, el init.ora debe de estar arrancado con los siguientes
parámetros.
Este archivo en windows deberia encontrarse en: <ORACLE_HOME>\database\INIT<sid>.ORA
 Editar INIT.ORA
log_archive_start=true
log_archive_dest_1='location=E:\backups_oracle\arch_log\' REOPEN=5
log_archive_format = arch_%t_%s.arc
*log_archive_dest_1= es el destino donde vas a archivar los .arc
En mi instalación de Oracle 11g este fichero no está generado, para generarlo:
SQL>CREATE PFILE FROM SPFILE;
Tambien podriamos hacer las modificaciones en el SPFILE<SID>.ORA pero este fichero es muy
delicado y sus modificaciones se realizan mediante comandos como:
SQL> ALTER SYSTEM parametro = valor SCOPE=[spfile, memory, both]
*La clausula scope especifica donde quiere que se recoja el cambio; spfile(graba los nuevos valores en
spfile.ora), memory(aplica el cambio solo en la memoria) o both(graba las modificaciones en spfile.ora y lo
aplica en memoria).
*Para log_archive_start necesitamos scope=spfile ya que es un parametro estático y necesita reiniciar la BD
para que el cambio surja efecto. Al contrario log_archive_dest es dinámico y para su modificacion no
necesitamos reiniciar la BD.
 Modificando SPFILE<SID>.ORA
SQL> ALTER SYSTEM set log_archive_start=true scope=spfile
SQL> ALTER SYSTEM set
log_archive_dest_1='location=E:\backups_oracle\arch_log\' scope=both;
 Si la base de datos está funcionando y esos parámetros están en el init.ora paramos la base de
datos con un: SQL> shutdown immediate
NOTA: Previamente habría que haberse conectado, con privilegios adecuados, a la base de
datos sobre la que se quiere realizar el cambio
 A continuación montamos la base de datos: SQL> startup mount
 Después de haber montado la base de datos ejecutamos el siguiente comando para
comunicarle a la base de datos que arrancamos en modo archive log, pero si el init.ora tiene el
paramentro log_archive_start=true, este modo arrancara automaticamente:
SQL> alter database archivelog;
 Y después abrimos la base de datos: SQL> alter database open;
 Para finalizar, activamos el archivado automático, Al hacer el paso 3 realiza este
automaticamente: SQL> alter system archive log start;
Con esto ya tendríamos configurado el modo archivelog de una base de datos Oracle
c. Desactivando el modo Archivelog: Para desactivar el modo archive log de una base de datos
(teniendo en cuenta las consecuencias que esto conlleva) seguimos los siguientes pasos:
 Nos conectamos a la base de datos en la cual queremos parar el modo de archivado y la
paramos mediante el comando: SQL> shutdown immediate
 Montamos la base de datos mediante el comando: SQL> startup mount
 Desactivamos el modo archivelog: SQL> alter database noarchivelog
 Abrimos la base de datos: SQL> alter database open
 Desactivamos el archivado automático. Al hacer el paso 3 realiza este automaticamente:
SQL> alter system archive log stop
Con esto ya tendriamos desactivado el modo archive log de una base de datos Oracle

2) Backups en frio:
El primer paso es parar la BD con el comando shutdown normal. Si la BD se tiene que parar con
inmediate o abort debe rearrancarse con el modo RESTRICT y vuelta a parar en modo normal.
Después se copian los ficheros de datos, los de redo log y los de control, además de los redo log
archivados y aún no copiados.
Una buena idea es automatizar todo este proceso con los scripts correspondientes, de modo que no
nos olvidemos de copiar ningún fichero. Pero ahora nos centraremos en realizar la copia
manualmente para analizar cada procedimiento. Como este tipo de backup es una copia de los
ficheros de la BD, si estos contienen algún tipo de corrupción, la traspasaremos a la copia de
seguridad sin detectarla. Por esto es importante comprobar las copias de seguridad.
Los pasos que hay que seguir para realizar un backup en frió serían:
a. Conocer y listar la ubicación de los datafiles, controlfiles, redo log y redo log archivados:.
Esto se puede hacer ejecutando:
select file_name from dba_data_files;
select name from v$controlfile;
select member from v$logfile;
select name from v$archived_log;
b. Tirar la base de datos mediante shutdown normal o shutdown inmediate.
c. Copiar los archivos datafiles, controlfiles y logfiles a un medio de backup preferido como
cinta, disco duro, otra máquina, etc.
Además, si nos interesa podemos hacer una copia de init.ora.
$>COPY E:\oracle\app\Administrador\product\11.1.0\db_1\database\INITorcl.ORA
E:\backups_oracle\binit.ora
Mediante símbolo de sistema podemos exportar la variable ORACLE_FICHEROS para no tener que
trabajar con rutas tan largas ya que en este caso los ficheros de los que necesitamos hacer copia
estan en la misma ruta.
$>SET ORACLE_FICHEROS=E:\ORACLE\APP\ADMINISTRADOR\ORADATA\ORCL\
DATAFILES:
$>COPY %ORACLE_FICHEROS%\USERS01.DBF E:\backups_oracle\bUSERS01.DBF
$>COPY %ORACLE_FICHEROS%\UNDOTBS01.DBF E:\backups_oracle\bUNDOTBS01.DBF
$>COPY%ORACLE_FICHEROS%\SYSAUX01.DBF E:\backups_oracle\bSYSAUX01.DBF
$>COPY%ORACLE_FICHEROS%\SYSTEM01.DBF E:\backups_oracle\bSYSTEM01.DBF
$>COPY%ORACLE_FICHEROS%\EXAMPLE01.DBF E:\backups_oracle\bEXAMPLE01.DBF
CONTROLFILE:
$>COPY %ORACLE_FICHEROS%\CONTROL01.CTL E:\backups_oracle\bCONTROL01.CTL
LOGFILE:
$>COPY %ORACLE_FICHEROS%\REDO01.LOG E:\backups_oracle\bREDO01.LOG
LOG ARCHIVED FILE:
A este tipo de log se le puede especificar varios destinos por lo que no hace falta estar copiandolos
de un sitio a otro, solo definirle el destino deseado al activar el modo archive log.
3) Backups en caliente:
Este método es prácticamente igual que el anterior, a diferencia de que; no necesita parar la base de
datos, tan solo deberemos desactivar los tablespaces de los que se estén haciendo copia en ese
momento, y tener activado el modo Archive Log
a. Respaldo de los datafiles.
Ver que datafiles tenemos en nuestra base de datos, para ellos podemos realizar la siguiente
consulta a la tabla dba_data_files.
select tablespace_name,file_name from dba_data_files order by tablespace_name;

Para cada uno de los datafiles asociados a un tablespace hacemos lo siguiente:

SQL>Alter tablespace <nonbre_tablespace> begin backup;
Copiamos a otro sitio todos los datafiles, con la utilidad COPY del SO, tal como vimos en las copias
en frio. Ejem:
$>COPY %ORACLE_FICHEROS%\USERS01.DBF E:\backups_oracle\bUSERS01.DBF
...
SQL>Alter tablespace end backup;
SQL>Alter system switch logfile;
Como observamos bloqueamos el tablespace, copiamos todos los datafiles al lugar donde
queramos realizar el backup y por último desbloqueamos el tablespace y forzamos los redo.
b. Respaldo de los control files.
Es recomendable tener una copia de los ficheros de control de la base de datos. Este backup se
puede realizar de la siguiente forma:
1. Para respaldar el controlfile ejecute la siguiente consulta:
ALTER DATABASE BACKUP CONTROLFILE TO ‹dirección y nombre del archivo›;
2. Para respaldar el controlfile en un archivo de traza ejecute la siguiente consulta:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
Si queremos tener un backup legible de estos ficheros para crear uno nuevo en caso de
pérdida,
c. Respaldo del archivo init.ora.
Es recomendable tener una copia del init.ora en algún sitio (con realizar esta copia cada vez que
cambie este archivo sería suficiente).
Mediante los comandos copiar-pegar del sistema operativo se procederá a respaldar dicho
archivo, este se copiará a una dirección previamente establecida. Como vimos con los backups en
frio, copiamos el init.ora de la siguiente forma:
$>COPY E:\oracle\app\Administrador\product\11.1.0\db_1\dbs\init.ora
E:\backups_oracle\binit.ora
d. Respaldo de los redo log files.
1 Ejecute la siguiente instrucción para poder respaldar el log sobre el cual se está escribiendo:
ALTER SYSTEM SWITCH LOGFILE;
2 Deshabilite el modo ARCHIVE mediante el siguiente comando:
ALTER SYSTEM ARCHIVE LOG STOP;
3 Ubicar los redo log files mediante la siguiente consulta:
SHOW PARAMETER LOG_ARCHIVE_DEST;
4 Respaldar los redo log files: Mediante sistema operativo copiamos y pegamos los redo log files a
la ubicación previamente definida.
5 Habilitar el modo ARCHIVE mediante el siguiente comando:
ALTER SYSTEM ARCHIVE LOG START;
Una vez que se ha realizado el respaldo ( backup ) de estos ficheros pueden ser borrados de la
ubicación original en caso de que queramos librerar un poco de espacio, ya que contienen las
ultimas transacciones y si en algún caso queremos realizar una recuperación en el tiempo
tenemos todos estos archivos guardados para cuando la recuperación los pida.
Si trabajamos con el destino predeterminado que en Oracle 11g es:
E:\oracle\app\Administrador\flash_recovery_area\ORCL\ARCHIVELOG>
E:\oracle\app\Administrador\flash_recovery_area\ORCL>XCOPY ARCHIVELOG
E:\backups_oracle /E
Con este ultimo comando copiamos la carpeta contenedora de todos los archivos de log
recursivamente(/E), llevando estas al destino elegido. En este documento al activar el modo
archive log hemos definido una ruta donde se irán generando los archivos de log, con el formato
predeterminado en los parametros de spfile.ora.

e. Respaldo de los tablespace.

1 Para verificar los tablespaces existentes ejecute la siguiente consulta:
SELECT * FROM V$TABLESPACES;
2 Para respaldar los tablespace ejecute la siguiente consulta:
ALTER TABLESPACE ‹NOMBRE DEL TABLESPACE› BEGIN BACKUP;
3 Para verificar los datafiles a respaldar utilice la siguiente consulta:
SELECT FILE_NAME FROM DBA_DATA_FILES
WHERE TABLESPACE_NAME = ‹NOMBRE DEL TABLESPACE›;
4 Copiar los datafiles, mediante el siguiente commando:
HOST COPY ‹DIRECCION DEL DATAFILE› ‹UBACIÓN DEL RESPALDO›;
5 Finalizar el proceso de backup mediante el siguiente comando:
ALTER TABLESPACE ‹NOMBRE DEL TABLESPACE› END BACKUP;
f. Llenar el registro correspondiente
Fecha de respaldo:
Objeto Respaldado ¿Exitoso? Observaciones
4) Respaldo de archivos de control mediante archivos de rastreo

a. Conéctese con el servidor de la base de datos usando la sentencia:
connect internal/oracle.
b. Inicie la base de datos a exportar en modo de apertura con la sentencia:
Startup open pfile=[ubicación del archivo de iniciación de la base de datos].
c. Ingrese la sentencia para crear el rastreo del archivo de control:
alter database backup controlfile to trace noresetlogs.
d. Verifique que el archivo de rastreo haya sido creado de forma exitosa mediante una búsqueda de
archivos de tipo TRC en el sistema operativo o verificando el parámetro de destino de archivos de
este tipo mediante la sentencia:
show parameter user_dump_dest.
e. Edite el contenido del archivo creado eliminando los comentarios del archivo así como los detalles
de versión, de manera que solo contenga el código pertinente para restablecer la base de datos.
f. Edite además la línea para la conexión con la base de datos colocando la siguiente sentencia en su
lugar:
STARTUP NOMOUNT PFILE=[UBICACION DEL ARCHIVO DE INICIACION DE LA BASE DE DATOS] .
g. Llenar el registro correspondiente
Fecha de respaldo:
Objeto Respaldado ¿Exitoso? Observaciones
5) Respaldos empleando el administrador de recuperación de Oracle

a. Etiquete y rotule el dispositivo de almacenamiento.
b. Cree el tablespace para el catalogo de respaldos usando el procedimiento de creación de
tablespaces de este manual.
c. Cree un usuario para realizar los respaldos mediante el administrador de recuperaciones de
Oracle empleando la sentencia:
CREATE USER [nombre de usuario] IDENTIFIED BY [contraseña]
TEMPORARY TABLESPACE temp
DEFAULT TABLESPACE [tablespace para el catalogo de recuperacion]
QUOTA UNLIMITED ON [tablespace para el catalogo de recuperacion];

d. Asigne los privilegios necesarios al usuario creado para realizar los respaldos mediante la
siguiente sentencia:
GRANT connect, resource, recovery_catalog_owner
TO [nombre de usuario para respaldar la base de datos];
e. Ejecute a través de la línea de comandos de su sistema operativo la sentencia para iniciar el
administrador de recuperación. La sentencia para Windows es la siguiente:
rman catalog [nombre de usuario para respaldos]
/[contraseña]@[base de datos del tablespace de catalogo]
target internal/oracle@[nombre de la base de datos a respaldar]
f. Digite la sentencia para efectuar el respaldo:
‘run { ‘allocate channel ch1 type disk;’
‘backup format [Ubicacion del respaldo de la base de datos] (database)’;
‘release channel ch1’; ‘}’
g. Verifique que el respaldo de la base de datos fue realizado de forma exitosa.
h. Llenar el registro correspondiente
Fecha de respaldo: ¿Exitoso? Observaciones
6) Backups lógicos (Desde línea de Comandos):

Este tipo de backups copian el contenido de la BD pero sin almacenar la posición física de los datos. Se
realizan con la herramienta export que copia los datos y la definición de la BD en un fichero en un
formato interno de Oracle. Para realizar un export la BD debe estár abierta. Export asegura la
consistencia en la tabla, aunque no entre tablas. Si se requiere consistencia entre todas las tablas de la
BD entonces no se debe realizar ninguna transacción durante el proceso de export. Esto se puede
conseguir si se abre la BD en modo RESTRICT.
Entre las ventajas de efectuar un export están las siguientes:
- Se puede detectar la corrupción en los bloques de datos, ya que el proceso de export fallará.
- Protege de fallos de usuario, por ejemplo si se borra una fila o toda una tabla por error es fácil
recuperarla por medio de un import.
- Se puede determinar los datos a exportar con gran flexibilidad.
- Se pueden realizar exports completos, incrementales y acumulativos.
- Los backups relizados con export son portables y sirven como formato de intercambio de datos
entre BDs y entre máquinas.
Una de las desventajas de realizar backups lógicos con export es que son mucho más lentos que los
backups físicos.
PARÁMETROS PARÁMETRO
DESCRIPCIÓN
DE EXPORT DEFECTO
USERID indefinido el username/password del usuario que efectua el export.
BUFFER dependiente del SO El tamaño en bytes del buffer utilizado.
FILE expdat.dmp el nombre del fichero destino.
GRANTS Yes indica si se exportan también los derechos.
INDEXES Yes indica si se exportan también los índices.
indica si se exportan también las filas de las tablas, o sólo
ROWS Yes
las definiciones de las tablas.
CONSTRAINTS Yes indica si se exportan también las restricciones.
COMPRESS Yes indica si se exporta en modo comprimido.
FULL No indica si se exporta la BD entera.
OWNER usuario actual una lista de usuarios cuyos objetos se quieren exportar.
TABLES indefinido la lista de tablas a exportar.
RECORDLENGTH dependiente del SO la longitud en bytes del registro del fichero.
INCTYPE indefinido el tipo de export incremental.
indica si se anota el export incremental en las tablas
RECORD Yes
SYS.INCVID y en SYS.INCEXP.
PARFILE indefinido el fichero de parámetros.

 Modos de Export. Existen tres modos de realizar una exportación de datos:

 Modo Tabla. Exporta las definiciones de tabla, los datos, los derechos del propietario, los índices del
propietario, las restricciones de la tabla y los disparadores asociados a la tabla.
 Modo Usuario. Exporta todo lo del modo de Tabla más los clusters, enlaces de BD, vistas, sinónimos
privados, secuencias, procedimientos, etc. del usuario.
 Modo BD Entera. Además de todo lo del modo Usuario, exporta los roles, todos los sinónimos, los
privilegios del sistema, las definiciones de los tablespaces, las cuotas en los tablespaces, las
definiciones de los segmentos de rollback, las opciones de auditoría del sistema, todos los
disparadores y los perfiles.
El modo BD entera puede ser dividido en tres casos: Completo, Acumulativo e Incremental. Estos dos
últimos se toman menos tiempo que el completo, y permiten exportar sólo los cámbios en los datos y en
las definiciones.
 Completo. Exporta todas las tablas de la BD e inicializa la información sobre la exportación
incremental de cada tabla. Después de una exportación completa, no se necesitan los ficheros de
exportaciones acumulativas e incrementales de la BD anteriores.
$ exp userid=system/manager full=y inctype=complete constraints=Y
file=full_export_filename
 Acumulativo. Exporta solo las tablas que han sido modificadas o creadas desde la última exportación
Acumulativa o Completa, y registra los detalles de exportación para cada tabla exportada. Después de
una exportación acumulativa, no se necesitan los ficheros de exportaciones incrementales de la BD
anteriores.
$expuserid=system/manager full=y inctype=cumulative constraints=Y
file=cumulative_export_filename
 Incremental. Exporta todas las tablas modificadas o creadas desde la última exportación Incremental,
Acumulativa o Completa, y registra los detalles de exportación para cada tabla exportada. Son
interesantes en entornos en los que muchas tablas permanecen estáticas por periodos largos de
tiempo, mientras que otras varían y necesitan ser copiadas. Este tipo de exportación es útil cuando
hay que recuperar rápidamente una tabla borrada por accidente.
$ exp userid=system/manager full=y inctype=incremental constraints=Y
file=incremental_export_filename
Exportación de la Base de Datos

a. Carga de la base de datos.
1. Invocar al Server Manager y conectarse así a la base de datos como sysdba.
SVRMGR› CONNECT INTERNAL
Password: ORACLE
2. Levantar la Base de Datos sobre la cual vamos a trabajar, ejecutando el siguiente comando.
STARTUP OPEN ‹nombre de la base de datos›
PFILE=‹dirección del archivo init.ora de nuestra base de datos›
b. Seleccionar el tipo de EXPORT a realizar.
1 Export User Mode. Ejecute la siguiente instrucción:
!EXP ‹nombre de usuario›/‹password›
FILE=‹Dirección donde se almacenará el archivo del export›
‹Resto de instrucciones (Objetos a exportar)›;
2 Export Full Database Mode. Ejecute la siguiente instrucción:
!EXP ‹nombre de usuario ›/‹password› FULL=Y
FILE=‹Dirección donde se almacenará el archivo del export› log=‹Dirección donde se
almacenará la bitácora producto del export›;
3 Export Table Mode. Ejecute la siguiente instrucción:
!EXP ‹nombre de usuario ›/‹password›
FILE=‹Dirección donde se almacenará el archivo del export›
TABLES=‹(tabla 1, tabla 2,.)› GRANTS=Y INDEXES=Y;


Fecha de exportación:
Objeto Exportado ¿Exitoso? Observaciones
7) Backups desde Enterprise Manager EM

Una vez logueados en EM, iremos al apartado “Disponibilidad” y apuntaremos a “Planificar Copia de
Seguridad”.
Como vemos nos da 2 opciones a elegir. En este documento analizaremos la opción personalizada con
toda la la base de datos. Dedeberemos conectarnos con los credenciales de host para realizar esta tarea.

Como es la primera copia que realizamos deberiamos elegir “Copia de Seguridad Completa”
Para el modo de copia elegiremos si deseamos hacer la copia con la base de datos abierta o cerrada.
En las opciones avanzadas tan solo añadiremos que realize copia tambien de los archive logs.
En este paso elegiremos el destino de la copia. Como no dispongo de dispositivo de cintas paso a
continuar explicando la opción “Disco”. (La ubicación que ha tomado para la opción “Disco” esta asignada
desde RMAN).
Introducimos nombre si lo deseamos y la descripción, y lo planificamos para que se realize una vez y de
forma inmmediata.
Revisamos que todo esté correcto y ejecutamos el trabajo. Si todo ha ido bien debería aparecer esto:

E. Recuperación de la Base de Datos

Políticas para la administración del proceso de recuperación.
Las normas a seguir para el proceso de recuperación se enumeran a continuación:
Políticas para la ejecución de pruebas en los respaldos.
 Se realizaran pruebas constantes de los respaldos basándose en un calendario de pruebas
predefinido con sus respectivos responsables.
 Se deberá capacitar al personal que se encargará de realizar las pruebas a los respaldos. En la
selección de este personal se omitirán aquellos involucrados en el proceso de respaldos.
 Se deberá de seguir el correspondiente instructivo que posea la organización, además una vez
concluidas se procederá a llenar el correspondiente registro.
Políticas para la recuperación de la información.
 Cada uno de los posibles escenarios de recuperación tendrá su correspondiente prueba en la fecha
que establezca el calendario de pruebas.
 En caso de fallos de los respaldos se procederá a documentar el fallo y a notificar al encargado
inmediato para que se tomen las medidas correctivas que la organización previamente ha
determinado.
A continuación se detallan los posibles escenarios de recuperación y sus correspondientes procesos para
solucionar la falla:
Tipo de Fallo Ejemplos Procedimiento de recuperación
Pérdida de tablespace Recuperación de un Tablespace
Fallo de medio físico Pérdida de un archivo de datos Recuperación de un Datafile
Pérdida de una tabla Recuperación de una Tabla
Pérdida de una bitácora en línea Recuperación de una Bitácora
Fallo de Sistema
Pérdida de un archivo de control Recuperación de un Archivo de Control
Desarrollar una estrategia de recuperación.
- Verificación de las estrategias de recuperación
- Manejo de los fallos no provenientes del medio físico
- Fallos de sentencia
- Fallos del Proceso de Usuarios
- Errores de usuario
- Fallos de instancia
- Recuperación de un fallo en el medio físico
- Fallo de un disco que contiene al menos un archive de la base de datos
- Un archivo de datos, archived log ó archivo de control que se elimina accidentalmente o se
sobrescribe o se corrompe
Metodo de recuperación:
- Determinar qué archivos requieren restauración.
- Determinar el tipo de recuperación requerido: Completo ó Incompleto, con la base de datos
Abierta ó Cerrada
- Restaurar los archivos necesarios de las copias del backup o de una copia imagen
- Aplicar los registros redo (y/o backups incrementales cuando corresponda) para recuperar los
archivos de datos.
- Re-abrir la base de datos. Si se realizó una recuperación incomplete, iniciar la instancia con la
opción RESETLOGS.

1) Recuperación de la BD
Para recuperar la base de datos a un estado anterior esta tiene que estar puesta en modo archivelog y
tener los archivelog correspondientes a las transacciones que queramos recuperar para poder volver al
punto en el tiempo indicado.
Teniendo en cuenta que nuestra base de datos está levantada los pasos a seguir son los siguientes:
a. Nos conectamos a la base de datos
b. Bajamos la instancia de base de datos SQL > shutdown immediate
c. Levantamos la instancia en modo mount SQL > startup mount
d. Recuperamos la base de datos hasta la fecha indicada (punto en el tiempo al cual queremos
retroceder)
SQL > recover database until time '2009-02-10:22:59:04'
Con esto hemos conseguido recuperar la instancia en el momento indicado en la fecha ('2007-01-
10:22:59:04' à 10 de enero de 2007 a las 22 horas 59 minutos y 4 segundos) Con relación a la fecha
el formato por defecto es el siguiente: 'YYYY-MMDD: HH24:MI:SS'
La sintaxis de este comando:
RECOVER [AUTOMATIC] [FROM 'localizacion'] [BD]
[UNTIL CANCEL]
[UNTIL TIME fecha]
[UNTIL CHANGE entero]
[USING BACKUP CONTROLFILE]
Las opciones entre corchetes son opcionales:
AUTOMATIC hace que la recuperación se haga automáticamente sin preguntar al DBA por el
nombre de los ficheros redo log. También se puede utilizar para este cometido el comando set
autorecovery on/off. Los ficheros redo log deben estar en la localización fijada en
LOG_ARCHIVE_DEST y el formato del nombre de los ficheros debe ser el fijado en
LOG_ARCHIVE_FORMAT.
FROM se utiliza para determinar el lugar donde están los ficheros redo log, si es distinto del fijado
en LOG_ARCHIVE_DEST.
UNTIL sirve para indicar que se desea realizar una recuperación incompleta, lo que implica perder
datos. Solo se dará cuando se han perdido redo log archivados o el fichero de control. Cuando se
ha realizado una recuperación incompleta la BD debe ser abierta con el comando alter database
open resetlogs, lo que produce que los redo log no aplicados no se apliquen nunca y se inicialice la
secuencia de redo log en el fichero de control. Existen tres opciones para parar la recuperación:
- UNTIL CANCEL permite recuperar un redo log cada vez, parando cuando se teclea CANCEL.
- UNTIL TIME permite recuperar hasta un instante dado dentro de un fichero de redo log
- UNTIL CHANGE permite recuperar hasta un SCN dado.
- USING BACKUP CONTROLFILE utiliza una copia de seguridad del fichero de control para
gobernar la recuperación.
2) Recuperación de un Tablespace
La BD debe estar abierta, pero con el tablespace a recuperar offline.
a. Carga de la base de datos
Invocar al Server Manager y conectarse así a la base de datos como sysdba.
CONNECT INTERNAL
Password: ORACLE
Levantar la Base de Datos sobre la cual vamos a trabajar, ejecutando el siguiente comando.
STARTUP MOUNT <nombre de la base de datos> PFILE=<dirección del archivo init<SID>.ora de
nuestra base de datos> EXCLUSIVE RESTRICT
b. Identificación de los datafiles que produjeron el error.
Ejecute la siguiente consulta: SELECT * FROM V$RECOVER_FILE;

c. Ubicación de los datafiles en la unidad de disco.

Ejecute la siguiente consulta: SELECT FILE#, NAME FROM V$DATAFILE;
d. Recuperación del tablespace (cuando se cuenta con todos los ARCHIVE).
1 Se cuenta con respaldos de los datafiles que fallaron. Utilice el instructivo para recuperación de
datafile [CODIGO DE LA REC DE DATAFILE].
2 No se cuenta con respaldos de los datafiles que fallaron. Recreación de los datafiles.
Ejecute la siguiente instrucción para cada uno de los datafiles que fallaron:
ALTER DATABASE
CREATE DATAFILE <’DIRECCIÓN DEL DATAFILE QUE PRODUJO EL ERROR‘>
AS <’DIRECCIÓN DONDE UBICAREMOS AL DATAFILE RECREADO‘>;
Comenzar la recuperación del tablespace. Para comenzar con la recuperación del tablespace
ejecute la siguiente instrucción:
RECOVER [AUTOMATIC] FROM ‘Dirección de los ARCHIVE’
TABLESPACE <nombre del tablespace>
e. Apertura de la base de datos.
Ejecute la siguiente instrucción:
ALTER DATABASE OPEN;
f. Llenar el registro correspondiente
Fecha de recuperación: Objeto Recuperado ¿Exitoso? Observaciones
3) Recuperación de un Datafile
La BD debe estar abierta o cerrada, dependiendo del fichero a recuperar. Si el fichero a recuperar es de un
tablespace de usuario la BD puede estar abierta, pero con el fichero a recuperar offline. Si el fichero es del
tablespace SYSTEM la BD debe estar cerrada, ya que no puede estar abierta con los ficheros del SYSTEM
offline.
a. Apertura de la base de datos en modo exclusivo.
STARTUP MOUNT <nombre de la base de datos> PFILE=<dirección del archivo
init<SID>.ora de nuestra base de datos>
b. Identificación del datafile que produce el error.
Ejecute la siguiente consulta: SELECT * FROM V$RECOVER_FILE;
c. Ubicación del datafile en la unidad de disco.
Ejecute la siguiente consulta: SELECT FILE#, NAME FROM V$DATAFILE;
d. Restauración del datafile.
1. Restauración del datafile que produjo el error a partir del backup más reciente.
HOST COPY <’DIRECCIÓN DONDE SE ENCUENTRA EL BACKUP’>
<’DIRECCIÓN DEL DATAFILE QUE PRODUJO EL ERROR‘>;
Recuperación del datafile a partir del respaldo. Ejecute la siguiente instrucción:
RECOVER DATAFILE <’DIRECCIÓN DEL DATAFILE QUE ACABAMOS DE RESTAURAR‘>;
Recuperación del datafile a partir de los ARCHIVE.
Si la base de datos aún no se ha podido recuperar se nos pedirán los ARCHIVE, si estos se
encuentran en la dirección predefinida ejecutamos la siguiente instrucción: AUTO
Si no se encuentran en dicha dirección ejecutamos las siguientes instrucciones:
ALTER SYSTEM SET LOG_ARCHIVE_DEST = <’UBICACIÓN DE LOS ARCHIVE’>;
Repetimos el paso 5 y damos AUTO.

2. Restauración del datafile que produjo el error a partir de los ARCHIVE.

Recreación del datafile. Ejecute la siguiente instrucción:
ALTER DATABASE CREATE DATAFILE <’DIRECCIÓN DEL DATAFILE QUE PRODUJO EL ERROR‘> AS
<’DIRECCIÓN DONDE UBICAREMOS AL DATAFILE RECREADO‘>;
Recuperación del datafile a partir de los ARCHIVE. Ejecute la siguiente instrucción:
RECOVER [AUTOMATIC]FROM 'UBICACIÓN DE LOS ARCHIVE’
DATAFILE 'DIRECCIÓN DONDE UBICAREMOS AL DATAFILE RECREADO';
e. Apertura de la base de datos.
Ejecute la siguiente instrucción: ALTER DATABASE OPEN;
f. Llenar el registro correspondiente Fecha de recuperación: Objeto de respaldo utilizado:
Objeto Recuperado ¿Exitoso? Observaciones
4) Recuperacion de backups lógicos:

Oracle dispone de la herramienta import para restaurar los datos de una BD a partir de los ficheros
resultados de un export. Import lee los datos de los ficheros de exportación y ejecuta las sentencias que
almacenan creando las tablas y llenándolas de datos.
Parámetros del
Parámetro Defecto Descripción
Import
USERID indefinido el username/password del usuario que efectua el import.
BUFFER dependiente del SO El tamaño en bytes del buffer utilizado.
FILE expdat.dmp el nombre del fichero de exportación a importar.
indica si se muestran los contenidos del fichero de exportación,
SHOW No
sin importar ningún dato.
indica si ignorar los errores producidos al importar un objeto que
IGNORE Yes
ya existe en la BD.
GRANTS Yes indica si se importan también los derechos.
INDEXES Yes indica si se importan también los índices.
ROWS Yes indica si se importan también las filas de las tablas.
FULL No indica si se importan el fichero entero.
FROMUSER Indefinido una lista de los usuarios cuyos objetos se han exportado.
TOUSER Indefinido una lista de los usuarios a cuyo nombre se importan los objetos.
TABLES indefinido la lista de tablas a importar.
RECORDLENGTH dependiente del SO la longitud en bytes del registro del fichero.
INCTYPE indefinido el tipo de import incremental (SYSTEM o RESTORE).
indica si se efectua un commit después de importar cada fila. Por
COMMIT No
defecto, import efectua un commit después de cargar cada tabla.
PARFILE indefinido el fichero de parámetros.
5) Importar un export incremental:

a. Utilizar la copia más reciente del import para restaurar las definiciones del sistema:
$ imp userid=sys/passwd inctype=system full=Y file=export_filename
b. Poner los segmentos de rollback online.
c. Importar el fichero de exportación completa más reciente:
$ imp userid=sys/passwd inctype=restore full=Y file=filename
d. Importar los ficheros de exportación en modo acumulación desde la exportación completa más
reciente, en orden cronológico:
e. Importar los ficheros de exportación en modo incremental desde la exportación completa o
acumulativa más reciente, en orden cronológico:

6) Recuperación de una Tabla

a. Ejecute el programa Service Manager (svrmgrl.exe) de Oracle, ubicado en la ruta:
“C:\Oracle\Ora81\Bin\svrmgrl.exe”.
Conectese con un nombre de usuario y password digitando “connect internal” como nombre de
usuario y “oracle” como password.
b. Deshabilite la instancia de Oracle, por medio del comando: shutdown.
c. Inicie la base de datos en modo “open”, utilizando la instrucción:
startup open pfile = <ruta>\init<sid>.ora
d. Identifique el error y la tabla dañada para iniciar el proceso de recuperación.
e. Localice el archivo de respaldo realizado con el comando export, para recuperar los datos de las
tablas dañadas.
f. Utilice la siguiente instrucción para recuperar la(s) tabla(s) seleccionada(s):
$imp [usuario]/[password] file=[nombre_archivo.dmp] fromuser=[usuario]
touser=[usuario] tables=[nombre de tabla]
Nota: Para nuestro caso la instrucción se usaría de la siguiente forma:
$imp internal/oracle file=nombre_archivo.dmp fromuser=internal touser=internal
tables=nombre_tabla
g. Llenar el registro correspondiente Fecha de recuperación: Objeto de respaldo utilizado:
7) Recuperación de una Bitácora

a. Asegúrese que el dispositivo en donde se encuentra el respaldo esté debidamente conectado.
b. Conéctese con el servidor de la base de datos usando la sentencia: connect internal/oracle.
c. Inicie la base de datos a exportar en modo mount, utilice la sentencia:
Startup mount pfile=[ubicación del archivo de iniciación de la base de datos]
d. Ingrese la sentencia para recuperar toda la base de datos hasta el último redo log archivado:
recover database until cancel;
e. Una vez restaurada la base, ingrese la siguiente sentencia para resetear los archivos de
bitácoras en línea o crearlos en caso de que no existan: Alter database open resetlogs;
f. Llenar el registro correspondiente Fecha de recuperación: Objeto de respaldo utilizado:
8) Recuperación de un Archivo de Control

a. Asegúrese que el dispositivo en donde se encuentra el respaldo esté debidamente conectado.
b. Verifique que exista un archivo de rastreo de archivos de control creado antes de proceder con la
recuperación del archivo de control.
c. Conéctese con el servidor de la base de datos usando la sentencia: connect internal/oracle.
d. Ejecute el archivo de rastreo para archivos de control mas reciente mediante la sentencia:
@[dirección del archivo de rastreo ,incluya extensión].
e. Verifique que los archivos de control se hayan restablecido correctamente en el directorio
correspondiente.
f. Llenar el registro correspondiente: Fecha de recuperación: Objeto de respaldo utilizado:

RECUPERACIÓN DESDE ENTERPRISE MANAGER:

Para realizar una recuperación desde EM, iremos a “Disponibilidad” y seleccionamos Realizar
Recuperción.
En ambitos de recuperación podemos seleccionar toda o parte de la base de datos para recuperar.
Para el ejemplo hemos borrado el datafile USERS01.DBF(OFFLINE) despues de realizar el backup y
ahora vamos a intentar recuperarlo. Para ello usaremos la copia que acabamos de realizar.
Iniciamos oracle en modo mount y arrancamos EM.
Al no poder iniciar nos encontramos con esto una vez logueados.
Pinchamos en Realizar Recuperación.

Introducimos los credenciales de host.Continuar
Nos conectamos como sysdba

En el ambito de recuperación elegimos Archivos de Datos y en el tipo de operación restaurar hasta hora
actual. Pinchamos en recuperar.
Vemos como EM localiza la ruta en conflicto y te la presenta para seleccionarla. Siguiente
También podemos definir el destino de la restauración. Para el ejemplo nos interesa que se ubiquen en el
mismo directorio.

Podemos revisar los parámetros RMAN para ver y comprender las acciones realizadas por debajo de EM.
Una vez todo revisado procedemos a ejecutar. Esto lo que hará será tomar del backup el fichero y llevarlo
al destino aplicándole los cambios hasta el momento de la perdida permitiendo así el inicio normal de la
BD con tablespace online.
Una vez finalizado podemos pinchar en Abrir Base de Datos y esta se reiniciara y se abría
automáticamente después de ver insertado nuestros credenciales.
GESTOR DE RECUPERACIÓN DE ORACLE RMAN

El gestor de recuperación RMAN2 es una herramienta que nos proporciona una solución completa para la
creación de copias de seguridad y recuperación dentro de entornos Oracle. Permite realizar copias de
seguridad consistente e inconsistente, incremental y completa, de la base de datos completa o de una
parte de la misma.
A continuación se listaran los componentes mínimos para montar una estructura segura para nuestros
respaldos.
 Cliente: El cliente RMAN es la aplicación de Oracle que maneja las operaciones de respaldo y
recuperación. Mediante Oracle Net, este puede conectarse a través de la red permitiendo que ambos
(cliente y base de datos primaria) se encuentren en distintos servidores.
 Base de Datos Primaria: Es la base de datos que contiene los controlfile, datafile y los archived redo
log que RMAN va a respaldar.
 Base de Datos de Catálogo y Esquema Catálogo. Este componente es la base de datos que contiene
el catalogo de recuperación. Este catalogo contiene metadata 3que RMAN emplea para respaldar y
recuperar la base de datos primaria. El uso de este componente no es obligatorio ya que un respaldo
puede hacerse utilizando solamente el controlfile. Pero se considera una buena práctica tenerlo en el
ambiente de respaldos y recuperación.
Comandos de Uso de RMAN.
1) Conectarse a un catálogo RMAN.
Conexión a RMAN
Por defecto la conexión es a catalog, si colocáramos nocatalog RMAN debe obtener la información del
ControlFile de la base de datos target.
2
RMAN: Recovery Manager – Gestor de Recuperación.-
3
Metadata: se los describe como datos que definen otros datos. Se los puede relacionar con el concepto de índice ya que
un metadato se puede utilizar para referenciar un conjunto de datos.
2) Cómo crear un catálogo de recuperación.

a. Configurar el catálogo de recuperación
Nos conectamos a la base de datos para crear un nuevo tablespace con un tamaño de 2M con una
política autoextend que le permita aumentar su tamaño una vez que llegue al total definido.
Creación Tablespace
b. Creamos el Propietario del catalogo de recuperación.
Creamos el usuario rman el cual va a ser el propietario del catalogo creado anteriormente.
Creación de Usuario
A continuación asignamos los privilegios CONNECT y RECOVERY_CATALOG_OWNER al usuario.
CONNECT le permite al usuario conectarse a la base de datos mientras que
RECOVERY_CATALOG_OWNER le permite ejecutar consultas y realizar mantenimientos al catalogo
de recuperación.
Otorgando privilegios.
c. Creando el catalogo de recuperación.
La creación de un catalogo de recuperación se realiza mediante el empleo del comando CREATE
CATALOG. Como nombramos anteriormente un catalogo de recuperación o base de datos de catalogo
es un esquema de base de datos que contiene metadatos de RMAN para un conjunto de base de datos
de destino. Empleamos el comando para crear nuestro catalogo:
Creación catalogo de recuperación.
3) Comandos de sincronización del catalogo de recuperación.

a. Registrar una Base de Datos.
Para ello hacemos uso del comando REGISTER DATABASE el cual nos permite registrar la base de
datos de destino en el catalogo de recuperación para que RMAN pueda mantener sus metadatos.
Registrar Base de Datos

b. Desregistrar una Base de Datos.

Para quitar los metadatos de RMAN de una o más base de datos registradas al catalogo de
recuperación es necesario utilizar el comando UNREGISTERDATABASE.
Quito registro de la base de datos al catálogo.

c. Borrar Catálogo de Recuperación
Por medio del comando DROP CATALOG eliminamos un catalogo de recuperación.
Eliminando catálogo de recuperación.

d. Actualizar versión del catálogo de recuperación.
Para actualizar el catalogo de recuperación de una versión anterior a la versión requerida por el
cliente RMAN es necesario ejecutar el comando UPGRADE CATALOG.
Actualizando catalogo de recuperación.
4) Crear un catalogo virtual privado.

Una de las mejoras de Oracle 11g fue la creación de catálogos virtuales. Esta funcionalidad permite tener
en la misma instancia de catalogo los catálogos de distintos entornos. A continuación veremos cómo es la
creación y uso de este tipo de catálogos.
a. Crear el propietario del catalogo virtual privado.
Creación usuario catalogo virtual.

b. Otorgar privilegios al usuario del catalogo virtual.
Otorgando privilegios usuario catálogo virtual.

Como se puede observar en la Ilustración 11, otorgamos al usuario privilegios
RECOVERY_CATALOG_OWNER para poder ejecutar consultas y realizar mantenimientos al catálogo,
como también privilegios CATALOG para manipular el catalogo de la base de datos dba11g.
c. Crear catálogo virtual.
Dependiendo de la versión del cliente RMAN que tengamos será la forma de creación de un catálogo
virtual.

Si la versión del cliente es anterior a Oracle 11g se deberá ejecutar la siguiente sentencia:
Creación catalogo virtual con cliente anterior a 11g.

Sino, si nuestro cliente es de Oracle 11g o posterior la sentencia a ejecutar es la siguiente:
Creación catálogo virtual cliente 11g o posterior.
d. Utilizar el catálogo virtual privado.

Registramos una base de datos al catálogo.
Registrando base de datos al catalogo.

Visualizamos las bases de datos registradas.
visualizamos las bases de datos registradas.
e. Copias de Seguridad.
A continuación veremos cómo hacer un backup en una base de datos 11g.
Nos conectamos a la base de datos contra el catálogo.
Conexión contra el catálogo.

1. Backup Parcial de la Base de Datos (Whole Backup). Es un backup de todos los datafile, los
controlfile, este tipo no está sincronizado con la base de datos, simplemente es una copia de parte de
la base de datos en un determinado momento. Este tipo de backup se puede hacer con RMAN o con el
sistema operativo, mientras la base de datos este abierta o cerrada.
Backup de la base de datos

2. Backup Full. Un Full backup es una copia completa o parcial de uno o más datafiles. Todos los
bloques del datafile serán copiados.
Ilustración 1: Full Backup.

3. Incremental Backup. Un backup incremental es un backup de solo ciertos bloques de un datafile,

solo los bloques que han cambiado o se han añadido después de un full backup. Este tipo de backup
solo se puede hacer con RMAN. Ocupan poco tamaño y son más rápidos. Pueden ejecutarse con la
base de datos abierta o cerrada estando o no en modo archive.
Ilustración 2: Backup incremental level 1.
Ilustración 3: Backup incremental level 0.

El nivel o level determina si la copia de seguridad es incremental o diferencial.
4. Comprimir Copias de Seguridad. El comando para comprimir una copia de seguridad es
BACKUP AS COMPRESSED BACKUPSET. El cual nos permite darle formato empleando parámetros. A
continuación se listarán algunos de estos parámetros:
Tabla: Parámetros de copia de seguridad.
PARAMETRO DESCRIPCION
%a Especifica el ID de activación de la base d datos
Especifica el número de copia de seguridad dentro de un conjunto de copias de
%c
seguridad dúplex
%d Especifica el nombre de la base de datos
%s Especifica el número de la copia de seguridad
%t Especifica la marca de tiempo de la copia de seguridad
%p Especifica el número de pieza dentro del conjunto de copias de seguridad
Ilustración 4: Comprimir Backup
Ilustración 5: Comprimir copia de seguridad.
5. Borrar Copia de Seguridad. Para eliminar una copia de seguridad ejecutamos el siguiente
comando:
Ilustración 6: Eliminar copia de seguridad.
6. Borrar copias de seguridad obsoletas. Ejecutamos el siguiente comando para eliminar las copias
de seguridad obsoletas.
Ilustración 7: Eliminar copias de seguridad obsoletas.

f. Recuperación con RMAN.

A continuación se ejemplificará el cómo recuperar una base de datos a partir un backup.
Recuperación a partir de un Whole Backup. Colocamos la base de datos en modo nomount de la
siguiente forma:
Ilustración 8: Inicial BD en estado nomount.

Recuperamos la base de datos.
Ilustración 9: Recuperamos la base de datos.

Montamos la base de datos y abrimos con un resetlogs.
Ilustración 10: open en resetlogs.

g. Listar Copias de Seguridad.
Para listar copias de seguridad ejecutamos el comando LIST BACKUP.
Ilustración 11: Listar copias de seguridad.
5) Clonación de la bd con RMAN:

a. Se debe generar un listener, el cual contenga las entradas de la instancia nueva y claro, el origen de
donde sacaremos los datos.
LISTER11G =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = oracle11g.inmotion.cl)
(PORT = 1521))
)
SID_LIST_LISTER11G =
(SID_LIST =
(SID_DESC = (GLOBAL_DBNAME = orcl)
(ORACLE_HOME = /u01/app/oracle/product/11.1.0/db_1)
(SID_NAME = orcl)
)
(SID_DESC =
(GLOBAL_DBNAME = copia)
(ORACLE_HOME = /u01/app/oracle/product/11.1.0/db_1)
(SID_NAME = copia)
)
b. Al momento de levantar el listener, debe estar proporcionando disponibilidad a ambos servicios.
c. Se debe añadir la siguiente entrada al archivo tnsnames.ora
copia = (DESCRIPTION =
( ADDRESS = (PROTOCOL = TCP)(HOST = oracle11g.inmotion.cl)(PORT = 1521) )
( CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = copia) )
)
d. Se debe generar un archivo de password, dado que el DUPLICATE ACTIVE DATABASE se conecta
mediante SYSDBA a la instancia remota. Como observación , la password debe ser exactamente la
misma , entre la instancia de origen y la de destino.
e. Se debe iniciar la instancia auxiliar en estado NOMOUNT , en esta instancia es donde quedarán los
datos de la primaria.

f. Nos conectamos a RMAN , con la instancia primaria , la base de datos debe estar abierta.
g. Nos conectamos a través de RMAN a la instancia auxiliar.
h. Se deben generar todos los directorios nuevos que vamos a utilizar en nuestra nueva instancia
i. Ahora podemos ejecutar nuestro comando DUPLICATE DATABASE mediante RMAN , de la siguiente
forma.
run {
set newname for datafile '/u01/app/oracle/oradata/orcl/users01.dbf' to
'/u01/app/oracle/oradata/copia1/users01.dbf';
set newname for datafile '/u01/app/oracle/oradata/orcl/undotbs01.dbf' to
'/u01/app/oracle/oradata/copia2/undotbs01.dbf';
set newname for datafile '/u01/app/oracle/oradata/orcl/sysaux01.dbf' to
'/u01/app/oracle/oradata/copia3/sysaux01.dbf';
set newname for datafile '/u01/app/oracle/oradata/orcl/system01.dbf' to
'/u01/app/oracle/oradata/copia4/system01.dbf';
duplicate target database to copia from active database
db_file_name_convert '/u01/app/oracle/oradata/orcl' ,
'/u01/app/oracle/oradata/copia'
spfile parameter_value_convert = '/u01/app/oracle/admin/orcl' ,
'/u01/app/oracle/admin/copia'
set log_file_name_convert =
'/u01/app/oracle/oradata/orcl','/u01/app/oracle/oradata/copia'
set audit_file_dest='/u01/app/oracle/admin/copia/adump'
set log_archive_dest_1=''
set memory_target='183001600'
set dispatchers='(PROTOCOL=TCP) (SERVICE=copia)'
set control_files='/u01/app/oracle/oradata/copia1/control01.ctl','/u01/app/oracle/
oradata/copia2/control02.ctl','/u01/app/oracle/oradata/copia3/control03.ctl'
set db_recovery_file_dest_size = '2294967296';
}

F. Gestión de Transacciones
Las operaciones de acceso a una BD se organizan en transacciones.
Una transacción es una Secuencia de operaciones de acceso a la base de datos que constituyen una
unidad lógica de ejecución
Grafo de transiciones de estado de una transacción

Propiedades que deben cumplir las transacciones:
 Atomicidad: una transacción es una unidad atómica de ejecución (o se ejecutan todas sus operaciones o
ninguna).
 Consistencia: la transacción debe conducir la BD de un estado consistente a otro estado consistente (se
cumplen todas las restricciones de integridad).
 Aislamiento: una transacción no debe hacer visibles sus cambios a otras transacciones hasta que es
confirmada.
 Persistencia: cuando una transacción es confirmada sus cambios deben ser grabados en la BD y no deben
perderse debido a fallos de otras transacciones o del sistema
1) Definición de transacciones en SQL:

INICIO: en el uso interactivo una transacción se inicia con la primera instrucción SQL ejecutada desde que
finalizó la última transacción o desde que se inició la sesión. (INICIO implícito).
FIN (con confirmación): COMMIT [WORK ] (transacción confirmada parcialmente)
FIN (con anulación): ROLLBACK [WORK ] (transacción anulada)
FIN (implícito): cierre de la sesión (confirmada parcialmente) o anulación del SGBD (anulada)
Nota: En SQL no se pueden anidar las transacciones
2) Comprobación de la integridad en SQL:

La sintaxis de ORACLE para la definición del punto de comprobación de una restricción coincide con la
sintaxis de SQL, con las siguientes excepciones:
 restricción con modo inmediato (IMMEDIATE): se anula la operación SQL que ha provocado la
violación. (statement rollback)
 restricción con modo diferido (DEFERRED): se anula la transacción que ha provocado la violación.
(transaction rollback)

G. Gestión de los componentes de la Memoria

Oracle Database 11g permite especificar la memoria total asignada a la instancia. La memoria se
reasignará dinámicamente entre el Área Global del Sistema (SGA) y el Área Global de Programa (PGA)
según sea necesario.
Este método se denomina Gestión Automática de Memoria (AMM) y sólo está disponible en las
plataformas que soportan la liberación dinámica de memoria. Con ello, se simplifican las tareas de gestión
de la memoria.
Los asesores de memoria están disponibles para ayudarle a definir los parámetros de inicialización en
diversos niveles. El asesor concreto disponible depende del nivel en el que se especifiquen los parámetros
de memoria. Si activa AMM, sólo está disponible el asesor de tamaño de memoria.
La Gestión Automática de Memoria Compartida (ASMM) permite gestionar SGA como un todo.
SGA está formada por varios componentes. El tamaño de muchos de estos componentes se ajusta de
manera dinámica para conseguir un rendimiento óptimo dentro de los límites de los parámetros de
inicialización. Al activar AMM, ASMM se activa automáticamente. Si se activa ASMM pero no AMM, está
disponible el asesor de tamaño de SGA.
Puede gestionar el tamaño de los componentes individuales de manera manual, mediante la definición del
parámetro de inicialización para cada componente. Si el servidor de Oracle le notifica la existencia de un
problema de rendimiento relacionado con el tamaño del componente SGA o PGA, puede utilizar el Asesor
de Memoria del componente para determinar una configuración nueva y adecuada. El Asesor de Memoria
puede modelar el efecto de los cambios realizados en los parámetros
1) Activación de la Gestión Automática de Memoria (AMM)

Si no ha activado la Gestión Automática de Memoria (AMM) al configurar la base de datos, puede activarla
realizando los siguientes pasos:
1. En la página inicial de la base de datos, haga clic en el separador Server.
2. Haga clic en Memory Advisors en la región Database Configuration.
Aparecerá la página Memory Advisors.
3. Haga clic en Enable, junto a Automatic Memory Management.
Aparece la página Enable Automatic Memory Management.
4. Defina los valores para Total Memory Size y Maximum Memory Size de Automatic
Memory Management.
Nota: si cambia Maximum Memory Size, se debe reiniciar la instancia de base de datos.
5. Haga clic en Aceptar.

Puede aumentar el tamaño con posterioridad aumentando el valor del campo Total Memory Size o el
parámetro de inicialización MEMORY_TARGET. Sin embargo, no puede definirlo en un valor más alto que
el especificado en el campo Maximum Memory Size o el parámetro MEMORY_MAX_TARGET. Para obtener
más información, consulte Oracle Database Administrator’s Guide (Guía del Administrador de Oracle
Database).
Después de activar AMM, está disponible el asesor de tamaño de memoria para ayudarle a ajustar los
tamaños máximo y objetivo de memoria.
Nota: Oracle le recomienda utilizar la Gestión Automática de Memoria para simplificar las tareas de
gestión de la memoria.
2) Activación de la Gestión Automática de Memoria Compartida (ASMM)

La Gestión Automática de Memoria Compartida está activada de manera automática si se ha activado
AMM. Si no se ha activado AMM o no ha activado ASMM al configurar la base de datos, puede activar la
Gestión Automática de Memoria Compartida realizando los siguientes pasos:
1. En la página inicial de la base de datos, haga clic en el separador Server.
2. Haga clic en Memory Advisors en la región Database Configuration.
Aparecerá la página Memory Advisors.
3. Desplácese hasta la sección SGA. Haga clic en Enable, junto a Automatic Shared Memory
Management.
Aparece la página Enable Automatic Shared Memory Management.
4. Especifique el tamaño total del área SGA. Haga clic en OK.
Puede aumentar el tamaño total de SGA con posterioridad aumentando el valor del campo Total SGA Size
o el parámetro de inicialización SGA_TARGET. Sin embargo, no puede definirlo en un valor más alto que el
especificado en el campo Maximum SGA Size o el parámetro SGA_MAX_SIZE. Para obtener más
información, consulte Oracle Database Administrator’s Guide (Guía del Administrador de Oracle
Database).
Si AMM está desactivada, se puede acceder al asesor de PGA. Se recomienda utilizar el asesor de PGA para
definir el valor de memoria de PGA. Haga clic en el separador PGA para acceder a la página de
propiedades de PGA. Haga clic en Advice para llamar al asesor de PGA.
Nota: Oracle le recomienda utilizar la Gestión Automática de Memoria Compartida para simplificar las
tareas de gestión de la memoria.

3) Asesor de Gestión Automática de Memoria Compartida

Si ASMM está activada, no deberá definir los parámetros de inicialización de los componentes específicos de
la memoria compartida que gestiona ASMM. Después de activar ASMM, está disponible el asesor de
tamaño de SGA para ayudarle a seleccionar el mejor valor para el tamaño total de SGA.
Antes de activar ASMM, elimine los parámetros individuales de área de memoria de SPFILE porque, si
están definidos, se pueden imponer restricciones a ASMM. Si, después de ver los efectos de las
asignaciones de ASMM, decide que desea ajustar las asignaciones de determinados componentes, podrá
especificar los valores para esos componentes.
Si los valores que especifica son menores que los valores actuales, esos valores se tratan como tamaños
mínimos de memoria para los respectivos componentes. Si los valores que especifica son mayores que los
valores actuales, el tamaño de los componentes de memoria se aumenta hasta los valores proporcionados
mientras haya memoria libre disponible. De esta forma, se limita la cantidad de memoria disponible para
el ajuste automático, pero la capacidad estará disponible si el entorno necesita un tamaño especial que
ASMM no permita.
Los parámetros de inicialización que hay que tener en cuenta son los siguientes:
• SHARED_POOL_SIZE
• LARGE_POOL_SIZE
• JAVA_POOL_SIZE
• DB_CACHE_SIZE
• STREAMS_POOL_SIZE
Para ajustar estos parámetros con ASMM activada, debe utilizar el comando ALTER SYSTEM.

H. Análisis de rendimiento en Oracle STATSPACK

Para poder optimizar el rendimiento de la instancia, es vital saber cuál es nuestro nivel actual para poder
comparar en un futuro. Sin un nivel base, es difícil averiguar a qué se debe el problema que afecta a
nuestra base de datos.
VISTAS
Las vistas son los resultados de alguna sentencia sobre una tabla, y podemos ver las vistas que existen en
cada esquema de usuario de la BD en la interfaz web. Para hacerlo basta con acceder a la pestaña
"Esquema", sección "Objetos de la Base de Datos" y en "Vistas". Tenemos que realizar una búsqueda
según el esquema del que queremos ver sus vistas. Por supuesto podemos crear vistas de las tablas que
tenga cualquier usuario, simplemente presionando sobre "Crear". Debemos introducir el nombre de la
vista que queramos crear, el esquema de usuario donde se encuentran las tablas, los alias y el texto de la
consulta. Los alias no son necesario ponerlos y en el recuadro de texto que se refiere al texto de la
consulta, debemos introducir toda la sentencia en el, en este caso sería una SELECT.
Proporcionan información en tiempo real acerca de las entrañas de nuestra base de datos. La estructura
de la base de datos, información de rendimiento, parámetros de inicialización son algunos ejemplos de los
datos que podemos obtener de ellas. Las vistas proporcionadas por Oracle tienen siempre el prefijo V_$,
pertenecen a SYS, y por defecto sólo están disponibles a SYS y a usuarios con el privilegio SELECT ANY
TABLE. También encontraremos vistas que comienzan por V$, que son sinónimos que apuntan a las
anteriores.
Las Vistas Dinámicas más importantes que dan información sobre el rendimiento de la instancia son:
 V$SYSTEM_EVENT. Recoge información sobre las esperas totales por evento y el tiempo de estas
esperas.
 V$SYSSTAT. Recoge las estadísticas básicas acumuladas de la instancia, como el uso total de
commits o de rollbacks, o los bloques totales de redo leídos.
 V$SGAINFO. Recoge información sobre el tamaño (en bytes) de todos los elementos componentes
de la SGA (Shared pool, Large pool, etc). Además nos dice cual de estos elementos son
redimensionables. Un ejemplo de redimensionable sería el Shared Pool y un ejemplo de no
redimensionable sería el tamaño máximo de la SGA.
 V$SGASTAT. Recoge la información detallada de los elementos que componen la SGA. Si
V$SGAINFO nos mostraba el tamaño total de cada uno de estos componentes, V$SGASTAT nos
muestra el tamaño de todos los elementos que componen cada uno de los componentes.
 V$BUFFER_POOL_STATISTICS. Recoge información sobre las estadísticas de la caché de datos,
como el número de buffers escritos o el número de buffers escaneados.
 V$LIBRARYCACHE. Proporciona información sobre el rendimiento de la libary cache (caché de
secuencias SQL). Por ejemplo nos da información de cuantas veces se solicitaron las sentencias sql y
cuantas fueron rechazadas
 V$FILESTAT. Contiene información acerca de las estadísticas de los ficheros de datos escritos y
leídos, como el número de veces que es requerido el DBWR en ese fichero.
 V$LATCH. Proporciona información sobre los latches. Los latches son un mecanismo que protege la
estructura de datos de la SGA contra los accesos simultáneos. Limitan la cantidad de tiempo y espacio
en los que un proceso puede mantener un recurso en un instante dado.
 V$WAITSTAT. Muestra estadísticas relacionadas con la contención de bloques de la base de datos .
 V$SQL. Recoge información sobre las sentencias SQL en ejecución, incluyendo el consumo de
memoria.
 V$PROCESS. Recoge información acerca de los procesos que se encuentran activos en ese
momento, como el usuario que lo esta usando, con el programa que se esta utilizando, en que archivo,
o el tamaño de la memoria de pga usado.
 V$BGPROCESS. Recoge información sobre los procesos en segundo plano, como la descripción de
estos y los errores encontrados en ellos.

Podríamos examinar cada una de estas vistas y anotar sus valores para conseguir información sobre
como afectan los cambios de configuración al rendimiento. Por suerte, Oracle proporciona una serie de
scripts agrupados bajo el nombre de Statspack que se encargarán de hacer la mayor parte del trabajo
sucio en nuestro lugar.
Si queremos ver los datos de la vista solo tenemos que buscar la vista en el esquema del usuario y pulsar
sobre el nombre de la vista. A continuación en "Acciones" seleccionamos "Ver datos" y pulsamos en "Ir".
Nos aparecerá los datos de la vista.
STATSPACK
Statspack es un conjunto de scripts para medir la productividad de la base de datos. Es una herramienta
que contiene Oracle, que recopila información de las vistas más importantes del rendimiento. Este
además analiza dichas estadísticas y genera un reporte con el diagnóstico global de rendimiento. Además
muestra la información recopilada en un formato legible para el administrador de la Base de Datos.
El término 'snapshot' describe un conjunto de estadísticas tomadas en un momento concreto,
almacenadas con un identificador único. No confundir con Oracle Snapshot Replication.
¿Cómo es el reporte que genera?
El reporte que genera cuenta con una estructura definida:
1. En primer lugar nos muestra el diagnóstico en sí, en el cual se encuentran los indicadores de
desempeño (medición de las principales variables), y a continuación, los eventos que inciden en el
rendimiento.
2. En segundo lugar el reporte nos presenta todos los eventos de la base de datos.
3. Luego las sentencias SQL más consumidoras de recursos ordenadas de 4 formas:
-SQL ordenadas por llamadas.
-SQL ordenadas por lecturas.
-SQL ordenadas por ejecuciones.
-SQL ordenadas por llamadas analizadas.
4. A continuación, un listado de todas las estadísticas de la base de datos.
5. Continúa con un listado de las tablespaces y los datafiles ordenados por la suma de lecturas y
escrituras.
6. Las siguientes estadísticas son las de uso de :
-Buffer pool
-PGA
-Undo Segments
-Latches
-Shared pool
7. Por último nos enseña parámetros del init.ora

1) ¿Cómo se instala?
El proceso de instalación crea un usuario, de nombre PERFSTAT propietario de todos los objetos
necesarios por este paquete. Después se le conceden únicamente privilegios de consulta sobre las vistas
dinámicas necesarias para recopilar la información.
Una snapshot tiene como identificador único la combinación de su snap_id (generada automáticamente
en el momento de la creación de dicha snapshot), el dbid, y el número de instancia.
Una vez hemos tomados varias snapshots, es posible generar un informe de rendimiento, proporcionando
las id de las dos snapshots que queremos comparar.
Requisitos: Antes de instalar Statspack, es recomendable la creación de un tablespace de un mínimo de
500M, ya que al instalarlo nos pedirá un tablespace que designar para la utilización de Statspack. Para ser
consistentes, Oracle recomienda llamarlo PERFSTAT. Es importante mantener vigilado el tamaño del
tablespace para que no se llene.
SQL> CREATE TABLESPACE perfstat
DATAFILE 'C:\app\Usuario\oradata\orcl\perfstat.dbf' SIZE 1000M REUSE
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 512K
SEGMENT SPACE MANAGEMENT AUTO PERMANENT ONLINE;
Proceso: Para instalar Statspack, tan solo tendremos que ejecutar en sql plus, con cualquier usuario que
funcione como sysdba, el siguiente script: /rdbms/admin/spcreate.sql
1. Nos conectamos como algún usuario con privilegios de SYSDBA
SQL> @?/rdbms/admin/spcreate.sql
SQL>[password para el usuario perfstat]
2. Nombre del tablespace a utilizar:
SQL>PERFSTAT
3. Que tablespace temporal usara el usuario PERFSTAT
SQL>TEMP
4. Revisar los archivos de log spcusr.lis, spctab.lis, spcpkg.lis en busca de “ORA-”, por si ha habido algún
error. En ese caso, hay que corregir el error, desinstalar Statspack y volver a iniciar el proceso de
instalación.
SQL> @?/rdbms/admin/spdrop.sql
SQL> @?/rdbms/admin/spcreate.sql
Este script creará también el usuario perfstat. En la instalación se nos pedirá que elijamos el
password del usuario perfstat, así como el tablespace por defecto, y el tablespace temporal.
2) ¿Cómo se recopilan las estadísticas?
Para tomar una foto en un momento determinado se debe de ejecutar el siguiente comando como usuario
perfstat en sql plus: exec statspack.snap;
Sin embargo es recomendable automatizar la ejecución anterior, de forma que se fija la ejecución del
statspack cada hora exacta (7:00,8:00,9:00,....).
Para ello se debe ejecutar el siguiente script: /rdbms/admin/spauto.sql
3) ¿Cómo se genera un reporte?
Para generar un reporte hay que ejecutar el siguiente script como usuario perfstat:
/rdbms/admin/spreport.sql
Se pedirá que indiques la instantánea inicial y la final de la que quieres hacer el reporte. También la
ubicación del fichero.
4) Tomar nuestra primera snapshot.
Nos conectamos como perfstat y ejecutamos la siguiente consulta: SQL>exec statspack.snap;
Nos conectamos como perfstat y ejecutamos la siguiente consulta: SQL>exec statspack.snap;
5) Listar todas las snapshots de nuestra base de datos.
select name,snap_id,to_char(snap_time,'DD.MM.YYYY:HH24:MI:SS')
"Date/Time" from stats$snapshot,v$database;
6) Borrar snapshots.
@?/rdbms/admin/sppurge;
7) Ajustar el nivel de detalle de las snapshots.
Nivel 0: Este nivel almacena estadísticas generales, incluyendo segmentos de rollback, caché de filas, SGA,
eventos de sistema, procesos de fondo, eventos de sesión, estadísticas de sistema, estadísticas de tiempos
de espera, bloqueos de objetos e información de cerrojos.
Nivel 5: Este nivel almacena datos sobre consultas SQL que consuman muchos recursos, junto con todos
los datos capturados por niveles inferiores.
Nivel 6: Este nivel almacena el plan de ejecución de consultas SQL que consuman muchos recursos, junto
con todos los datos capturados por niveles inferiores.
Nivel 7: Este nivel recoge estadísticas a nivel de segmento, incluyendo lecturas físicas y lógicas, bloqueos
de filas, tiempos de espera de buffers y todos los datos capturados por niveles inferiores.
Nivel 10: Este nivel almacena estadísticas sobre cerrojos hijos, junto con todos los datos capturados por
niveles inferiores.
Para modificar el nivel de detalle de nuestras snapshots futuras usamos el siguiente comando,
cambiando 6 por el nivel deseado.
exec statspack.snap(i_snap_level => 6, i_modify_parameter => 'true');
8) Programar la toma de snapshots.

@?/rdbms/admin/spauto.sql
Este script de ejemplo programará la toma de una snapshot cada hora. Para modificar la programación de
esta tarea o de cualquier otra, podemos utilizar el comando dbms_job.
9) Creación de informes.
Nota: No deben compararse snapshots procedentes de diferentes ejecuciones de instancias. La instancia
no debe haber sido apagada entre la snapshot inicial y la final.
La razón es que los valores recopilados por Statspack proceden de vistas que residen en memoria, por lo
que apagar la instancia resetaría los valores a 0. Dado que Statspack resta los valores iniciales a los
finales, el resultado sería inválido.
SQL*PLUS>@?/rdbms/admin/spreport.sql
RESUMEN DE SCRIPS
 Instalación (como usuario sysdba):
spcreate.sql: Instala Statspack ejecutando a su vez los scripts:
spcusr.sql: Crea el usuario PERFSTAT
spctab.sql: Crea las tablas
spcpkg.sql: Crea el paquete statspack
spdrop.sql: Desinstala STATSPACK ejecutando a su vez los scripts:
spdtab.sql: Borra las tablas
spdusr.sql: Borra el usuario PERFSTAT
 Informes (como usuario perfstat):
spreport.sql: Genera un informe general del rendimiento de la instancia
sprepins.sql: Genera un informe para la BD y la instancia indicados
sprepsql.sql: Genera un informe para la sentencia SQL que se indique.
spauto.sql: Permite automatizar la recolección de estadísticas.
 Mantenimiento (como usuario perfstat):
sppurge.sql -> Permite borrar un rango de snapshots
sptrunc.sql -> Vacía todas las tablas, borrando todos los snapshots
spuexp.par -> Es un fichero de parámetros para exportar el usuario perfstat

INCIDENCIAS MÁS FRECUENTES QUE AFECTAN AL RENDIMIENTO DE LA INSTANCIA.

- Contención en los LATCHES de LIBRARY CACHE
La razón por la que ocurre esta incidencia, es por la acumulación de muchas peticiones a un mismo
contenido de la caché de datos. Muchas de ellas se quedarán en espera. Para analizar si tenemos este
problema podemos mirar la vista dinámica V$LATCH. Existen varias latches que afectan a la library cache
(library cache, library cache pin allocation, library cache lock,....) Existirán problemas de rendimiento si
existen fallos (misses) con esperas(sleeps). Para evitar este problema habría que ampliar el tamaño de la
Shared Pool.
- Contención en los LATCH de SHARED POOL
La razón por la que ocurre esta incidencia, es por la acumulación de muchas peticiones a un mismo
contenido de la shared pool. Muchas de ellas se quedarán en espera. Para analizar si tenemos este
problema podemos mirar la vista dinámica V$LATCH. El latch encargado de la shared pool se llama
'shared pool' Existirán problemas de rendimiento si existen fallos (misses) con esperas(sleeps) en este
latch. Para evitar este problema habría que ampliar el tamaño de la Shared Pool.
- Altos tiempos de CPU para compilar.
Las estadísticas de esta incidencia se miraría en la fila “parse time cpu” de la vista V$SYSSTAT
- Muchas recompilaciones (RELOADS) en la caché de datos
Las recompilaciónes (reloads) son cada petición de metadatos (PIN) que no se encuentran en memoria
por que los ha sacado el algoritmo LRU (ejecuciones que requieren recompilar sentencia). Se miran en la
vista $LIBRARYCACHE y para el correcto funcionamiento de la instancia debe ser prácticamente 0 en los
namespaces sql/area, table/procedure,body y trigger. Si este valor no se acerca a 0 deberemos subir el
tamaño de la shared pool.
- Muchas llamadas de compilación.
Las estadísticas de este incidencia se miraría en la fila “parse count(total)”, “parse count(hard)”, parse
count(failures) de la vista V$SYSSTAT. Si existen muchas sentencias analizadas con fracaso(“parse
count(failures)”) con respecto al total (“parse count(total)”) el rendimiento de la base de datos no está
siendo el correcto.
- Contención en el LATCH 'CACHE BUFFERS LRU CHAIN'.
Como las anteriores contenciones de latches, tiene que ver con la acumulación de peticiones. Se puede
comprobar en la vista V$LATCH. Se dará si existen fallos (misses) con esperas (sleeps). La solución es
evitar las lecturas innecesarias o los índices poco selectivos.
- Mucho tiempo empleado en la espera "WRITE COMPLETE WAITS" y mucho tiempo empleado en la
espera "FREE BUFFER WAITS" .
Podemos ver si hay esperas para estas dos incidencias en V$BUFFER_POOL_STATISTICS.
Pueden evitarse evitando lecturas innecesarias o los índices poco selectivos
- Contención en LATCHES DE REDO.
Los latches de redo en los que tendremos que comprobar que hay contención, es decir, si existen fallos
(misses) con esperas (sleeps), son 'redo copy' y 'redo allocation'. Una posible solución es las subida de la
caché de Redo (log_buffer).
- 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úmero de
esperas al escribir el redo a disco, por que se ha llenado el fichero redolog.
- Contención en los segmentos de ROLLBACK
Habrá contención en los segmentos de rollback, si el count de 'undo header' de la columna class de la vista
V$WAITSTAT, es mayor que 0. Para solucionarlo tendremos que crear un mayor número de segmentos de
rollback.
- Cuellos de botellas
Los cuellos de botellas aparecen cuando hay una demanda excesiva simultánea sobre un recurso
ANÁLISIS DEL INFORME GENERADO POR STATSPACK

Anteriormente ya explique la estrucutura de Statspack, ahora veremos la información más relevante
recogida por este informe.
1. En primer lugar, Statspack nos da la información sobre la eficiencia de la actividad de la instancia.
Dentro de este apartado también aparecen las estadísticas de la Shared Pool.
- BUFFER NOWAIT: % de veces que se acceden a los buffers de datos sin tiempos de espera (Buffer
Nowait).
- BUFFER HIT: % de veces que los bloques de buffer se encontraban en la memoria, sin tener que
ejecutar una operación de lectura.
- LIBRARY HIT: % de ocasiones en el que las sentencias sql se encontraban en la shared pool.
- EXECUTE TO PARSE: % de utilización de sentencias sql ya analizadas.
- PARSE CPU TO PARSE ELAPS: Proporción de CPU dedicado a analizar las sentencias sql.
- REDO NOWAIT: % de tamaño suficiente en los buffers de redo.
- SOFT PARSE: % de sesiones en las que se utilizó sentencias sql que ya estaban en la shared pool.
- LATCH HIT: Frecuencias de uso de latches sin esperas.
- NON-PARSE CPU: % de cantidad de recursos de la CPU destinados a la ejecución de sql.
Las estadísticas de la Sahred Pool, nos indican la memoria usada, y porcentaje de sentencias sql
ejecutadas más de una vez.
2. El informe de Statspack trae la información de los 5 eventos que tienen un mayor peligro de
constituir un posible cuello de botella en la base de datos, ya que son los que tienen un mayor número
de esperas.
3. También podemos ver las estadísticas de memoria usada en la base de datos.
4. En la siguiente estadística también podremos ver en que gasta el tiempo la base de datos.

En este caso vemos que lo que más se hace en la base de datos (en lo que más tiempo emplea) es el
la ejecución de las sentencias sql) .
5. Podemos ver los eventos de procesos, tanto los que están en primer plano, como los que están en
segundo plano, para los que ha habido más esperas.
6. Statspack tambíén nos da información de como ha actuado y operado la instancia durante el periodo
que va entre fotografía y fotografía
7. Estudiamos las sentencias sql en el informe. Podremos ver las sentencias que consumen más cpu.
8. Sentencias que tienen un mayor tiempo de ejecución
9. Sentencias con un mayor número de lecturas lógicas.
10. Sentencias con un mayor número de lecturas de disco físicas
11. Sentencias con un mayor número de ejecuciones.
12. Sentencias que han sido más veces analizadas.
13. Otro de los apartados importante son los de las estadísticas de entrada/salida de las tablespaces y de
los ficheros de datos. Este punto también incluye las estadísticas del buffer pool
14. También reporta información sobre la memoria de los procesos.
15. Por supuesto también nos da información sobre los latches. Recordamos que habrá contención de
latches cuando haya fallos con esperas (Slps/Miss).
16. Tambíén nos ofrece detalles de como está funcionando la caché de datos
17. Con la siguiente tabla, podremos ver si es aconsejable ampliar el tamaño de la Shared Pool, ya que nos
ofrece algunas estadísticas por cada tamaño de la Shared Pool.

18. Proporciona información sobre el tamaño de la memoria de los componentes de la SGA.

19. Por último da a conocer los parámetros de init.ora en el momento en el que se hizo la fotografía
PÁGINA RENDIMIENTO DE ENTERPRISE MANAGER

La página Rendimiento de Enterprise Manager es el portal a un potente juego de herramientas de
supervisión y ajuste del rendimiento. En el primer juego de gráficos de esta página se resumen los
procesos y la actividad de la sesión activa.
En el gráfico Average Active Sessions/ Promedio de sesiones activas se muestra el nivel de uso de CPU y
los recursos que están provocando la mayoría de los eventos de espera.
En la diapositiva, se aprecia que ha habido un aumento reciente en las esperas Concurrency y Other.
Durante cada uno de estos picos, también ha habido un ligero aumento en el uso de E/S del sistema y de
CPU. Haga clic en estas categorías para obtener más información sobre las esperas. Los datos de E/S se
dividen en tipos de E/S (por ejemplo, lectura de archivo log, escritura de archivo de control, etc.).
1) Aumento de Detalle de una Categoría de Espera Concreta

Cuando se aumenta el detalle de una categoría de espera específica, se pueden ver detalles sobre
intervalos concretos de cinco minutos, así como el SQL en funcionamiento principal y las sesiones en
funcionamiento principales (Top Working SQL y Top Working Sessions) asociadas a ese evento de
espera concreto durante ese tiempo.
Esto le permitirá realizar análisis posteriores de las ralentizaciones del sistema y determinar las posibles
causas.

El ejemplo de la diapositiva muestra los resultados del aumento de detalle de la categoría Concurrency
desde el gráfico Active Session de la diapositiva anterior
2) Página Rendimiento: Throughput/ Rendimiento

Puede visualizar gráficos del rendimiento global de la instancia y de la entrada/salida del disco de
instancia haciendo clic en los separadores Rendimiento e I/O de la página principal Rendimiento.
El separador Throughput/ Rendimiento está seleccionado en la diapositiva.
3) Supervisión del Rendimiento: Top Sessions

Haga clic en Top Consumers en la sección Additional Monitoring Links para ir a la página Top
Consumers.
La página Top Consumers: Overview se muestra en formato gráfico:
 Top Services  Top Actions (por servicio y módulo)
 Top Modules (por servicio)  Top Clients

En la página Top Consumers, haga clic en el separador Top Sessions para visualizar las estadísticas
críticas de las sesiones que utilizan más recursos.
 CPU
 Memoria PGA
 Lecturas lógicas
 Lecturas físicas
 Recuento de análisis pesados
 Recuento de ordenación
Haga clic en el nombre de una columna para ordenar los resultados por el valor de dicha columna.
En la tabla de esta página se enumeran las sesiones ordenadas según las lecturas lógicas. Aquí se muestra
que el usuario INVENTORY de la sesión 36 produce el mayor número de lecturas lógicas en este momento
concreto
4) Supervisión del Rendimiento: Top Services
En sistemas de varios niveles en los que hay un servidor de aplicaciones que agrupa en pools las
conexiones a la base de datos, puede que la visualización de sesiones no proporcione la información
necesaria para analizar el rendimiento.
La agrupación de las sesiones en nombres de servicio permite supervisar el rendimiento de forma más
precisa.

En el ejemplo de la diapositiva, hay cuatro servicios: SYS$USERS, SYS$BACKGROUND, SH y SERV1.

Independientemente de la sesión utilizada para una solicitud concreta, si se conectó a través de
uno de estos servicios, los datos de rendimiento de la sesión se capturan con el nombre de
servicio. De los servicios de aplicaciones mostrados (SH y SERV1), en esta lista queda claro que el
servicio SH fue el más activo durante este intervalo de cinco minutos.
HERRAMIENTAS MÁS INTERESANTES EN ORACLE ENTERPRISE MANAGER

Las herramientas más interesantes que presenta Oracle Enterprise Manager con respecto al rendimiento
de la base de datos son:
 ADDM (Monitor de Diagnóstico de la Base de Datos Automático )
El ADDM realiza un análisis del sistema, identifica los posibles problemas y sus causas potenciales, y
por último plantea recomendaciones para solucionarlos.
La información que analiza el ADDM es:
- Cuellos de botella en la CPU
- Gestión ineficiente de conexiones
- Bloqueos
- Operaciones de entrada/salida
- Tamaño de las estructuras de memoria
- Carga de sentencias sql.
- Tiempo de ejecución de procedimientos PL/SQL y Java
Es muy fácil de generar. Tan solo tendremos que seleccionar el botón “ejecutar ADDM ahora” de la
pestaña “Rendimiento”
Al realizar el análisis nos da un resultado

En este caso no ha encontrado ningún problema

 La Central de Asesores
Para acceder a ese apartado tendremos que irnos a la parte inferior de la pestaña rendimiento
Y la pestaña que aparece nos ofrece las siguientes posibilidades:

Asesor de memoria: Analiza el tamaño de la SGA y de la PGA, optimizando el uso de la memoria
global de la instancia. Si tienes activada la opción gestión automática de la memoria, la base de datos
definirá automáticamente la distribución óptima de memoria. El botón consejo nos da una gráfica con
el porcentaje de mejora en función de los distintos tamaños.
Asesores de sql. Se divide en tres partes:
- Asesor de acceso sql : Analiza las consultas realizadas y puede indicar si es conveniente crear
índices o vistas materializadas para mejorar los tiempos de respuesta.
- Asesor de ajustes sql: Analiza las sentencias SQL y ofrece optimizaciones sobre las mismas.
- Resumen de resultados de ajustes SQL automáticos (SQL Tuning Advisory): Permite activar los
ajustes automáticos de SQL. Con esta opción activada la base de datos buscará formas para
mejorar los planes de ejecución de sentencias SQL de mucha carga. Ofrece estadísticas sobre esta
tarea.
Asesor de segmentos: Proporciona información útil para el dimensionado de los segmentos
(tablespaces, tablas,..) y para detectar aquellos que deben ser comprimidos.
Gestión automática de deshacer (undo): Proporciona información sobre el tamaño del tablespace
de UNDO y del tiempo de retención de los datos en él
 El informe ASH
El informe ASH es un informe muy parecido a Statspack, que se genera en Oracle Enterprise. Manager
solamente con seleccionar el botón “ejecutar informe ASH” en la pestaña de rendimiento.
El informe presenta lo mas utilizado, o lo que mas consume en cada una de las partes de la base de datos
(eventos mas frecuentes, secuencias SQL ejecutadas con mayor frecuencia,etc). Es una herramienta
fundamental para intentar detectar posibles casos de cuellos de botella.

I. Gestión de Estadísticas de Rendimiento Dinámicas

Las estadísticas deben estar disponibles para diagnosticar eficazmente los problemas de rendimiento. El
servidor de Oracle genera muchos tipos de estadísticas para distintos niveles de granularidad.
A nivel de sistema, de sesión y de servicio, se calculan tanto los eventos de espera como las estadísticas
acumulativas. En la diapositiva, la fila superior de las vistas muestra las estadísticas acumulativas. La fila
inferior muestra las vistas de eventos de espera.
Cuando se analiza un problema de rendimiento en cualquiera de estos ámbitos, normalmente se observa
el cambio producido en las estadísticas (valor delta) durante el período de tiempo que le interesa.
Todos los eventos de espera posibles están catalogados en la vista V$EVENT_NAME. Todas las
estadísticas están catalogadas en la vista V$STATNAME. Dispone de alrededor de 480 estadísticas en
Oracle Database.
Las vistas dinámicas más importantes que nos dan información sobre el rendimiento de la instancia son:
 V$SYSTEM_EVENT. Recoge información sobre las esperas totales por evento y el tiempo de estas
esperas.
 V$SYSSTAT. Recoge las estadísticas básicas acumuladas de la instancia, como el uso total de commits
o de rollbacks, o los bloques totales de redo leídos.
 V$SGAINFO. Recoge información sobre el tamaño (en bytes) de todos los elementos componentes de
la SGA (Shared pool, Large pool, etc). Además nos dice cuál de estos elementos son redimensionables.
Un ejemplo de redimensionable sería el Shared Pool y un ejemplo de no redimensionable sería el
tamaño máximo de la SGA.
 V$SGASTAT. Recoge la información detallada de los elementos que componen la SGA. Si V$SGAINFO
nos mostraba el tamaño total de cada uno de estos componentes, V$SGASTAT nos muestra el tamaño
de todos los elementos que componen cada uno de los componentes.
 V$BUFFER_POOL_STATISTICS. Recoge información sobre las estadísticas de la caché de datos, como
el número de buffers escritos o el número de buffers escaneados.
 V$LIBRARYCACHE. Proporciona información sobre el rendimiento de la libary cache (caché de
secuencias SQL). Por ejemplo nos da información de cuantas veces se solicitaron las sentencias sql y
cuantas fueron rechazadas.
 V$FILESTAT. Contiene información acerca de las estadísticas de los ficheros de datos escritos y leídos,
como el número de veces que es requerido el DBWR en ese fichero.
 V$LATCH. Proporciona información sobre los latches. Los latches son un mecanismo que protege la
estructura de datos de la SGA contra los accesos simultáneos. Limitan la cantidad de tiempo y espacio
en los que un proceso puede mantener un recurso en un instante dado.
 V$WAITSTAT. Muestra estadísticas relacionadas con la contención de bloques de la base de datos .
 V$SQL. Recoge información sobre las sentencias SQL en ejecución, incluyendo el consumo de
memoria.

 V$PROCESS. Recoge información acerca de los procesos que se encuentran activos en ese momento,
como el usuario que lo está usando, con el programa que se está utilizando, en que archivo, o el
tamaño de la memoria de pga usado.
 V$BGPROCESS. Recoge información sobre los procesos en segundo plano, como la descripción de
estos y los errores encontrados en ellos
4) Visualización de Estadísticas del Sistema

Ejemplo: SQL> SELECT name, class, value FROM v$sysstat;
NAME CLASS VALUE
------------------------------- ------ ----------
...
table scans (short tables) 64 135116
table scans (long tables) 64 250
table scans (rowid ranges) 64 0
table scans (cache partitions) 64 3
table scans (direct read) 64 0
table scan rows gotten 64 14789836
table scan blocks gotten 64 558542
...
Las estadísticas del sistema se clasifican por tema de ajuste y propósito de la depuración. Las clases
incluyen la actividad general de la instancia, la actividad del buffer de redo log, el bloqueo, la actividad de
la caché de buffers de la base de datos, etc.
5) Vistas de Solución de Problemas y de Ajustes

La diapositiva muestra algunas de las vistas que pueden ayudar a determinar la causa de los problemas
de rendimiento o a analizar el estado actual de la base de datos.
Para obtener una descripción completa de estas vistas, consulte Oracle Database Reference (Referencia de
Oracle Database).
6) Objetos No Válidos o No Utilizables

Los objetos PL/SQL no válidos y los índices no utilizables afectan al rendimiento.
Un objeto PL/SQL no válido se debe recompilar antes de poder utilizarse. Esto obliga a agregar el tiempo
de compilación a la primera acción que intente acceder al paquete, el procedimiento o la función PL/SQL.
Si el código PL/SQL no se recompila correctamente, la operación falla y genera un error. El optimizador
ignora los índices no utilizables. Si el adecuado funcionamiento de una sentencia SQL depende de un
índice marcado como no utilizable, el rendimiento no mejora hasta que se vuelve a crear el índice.
Objetos PL/SQL no válidos: el estado actual de determinados objetos PL/SQL se puede ver si se consulta
el diccionario de datos. Localice los objetos PL/SQL no válidos con lo siguiente:
SELECT object_name, object_type FROM DBA_OBJECTS
WHERE status = 'INVALID';

Por defecto, la métrica Owner’s Invalid Object Count se comprueba cada 24 horas. Si el número de objetos
de un propietario individual supera dos, se emite una alerta.
Si encuentra objetos PL/SQL con un estado INVALID, la primera pregunta que debe responder es si “este
objeto ha tenido alguna vez el estado VALID”. A menudo, un desarrollador de aplicaciones no realiza la
limpieza del código que no funciona. Si el objeto PL/SQL no es válido debido a un error de código, poco se
puede hacer hasta que se resuelve el error. Si el procedimiento fue válido en algún momento del pasado y
se ha convertido en no válido recientemente, tiene dos opciones para resolver el problema:
• No haga nada. La mayor parte de los objetos PL/SQL se recompilará automáticamente si es necesario
cuando se les llame. Los usuarios experimentarán un breve retraso mientras se recompilan los
objetos. (En la mayor parte de los casos, apenas se advierte este retraso.)
• Recompile el objeto no válido manualmente.
Los objetos PL/SQL no válidos se pueden recompilar manualmente con Enterprise Manager o a través de
comandos SQL: ALTER PROCEDURE HR.add_job_history COMPILE;
La recompilación manual de paquetes PL/SQL necesita dos pasos:
ALTER PACKAGE HR.maintainemp COMPILE;
ALTER PACKAGE HR.maintainemp COMPILE BODY;
Índices no utilizables: para encontrar los índices no válidos, consulte la vista del diccionario de datos
DBA_INDEXES:
SELECT index_name, table_name FROM DBA_INDEXES
WHERE status = 'UNUSABLE';
En el caso de los índices particionados, el estado se mantiene en la vista DBA_IND_PARTITIONS.
Los índices no utilizables se convierten en válidos reconstruyéndolos para volver a calcular los punteros.
La reconstrucción de un índice no utilizable vuelve a crear el índice en una nueva ubicación y después
borra el índice no utilizable. Este proceso se puede llevar a cabo con Enterprise Manager o a través de
comandos SQL:
ALTER INDEX HR.emp_empid_pk REBUILD;
ALTER INDEX HR.emp_empid_pk REBUILD ONLINE;
ALTER INDEX HR.email REBUILD TABLESPACE USERS;
Si se omite la cláusula TABLESPACE, el índice se vuelve a crear en el mismo tablespace en el que ya
existe. La cláusula REBUILD ONLINE permite a los usuarios seguir actualizando la tabla de índices
mientras tiene lugar la reconstrucción. (Sin la palabra clave ONLINE, los usuarios deben esperar a que
termine la reconstrucción antes de llevar a cabo DML en la tabla afectada. Si el índice no es utilizable, no
se utiliza durante la reconstrucción aunque se utilice la palabra clave ONLINE.)
Enterprise Manager utiliza la acción de reorganización para reparar un índice UNUSABLE.
Nota: la reconstrucción de un índice necesita espacio libre disponible para el proceso. Compruebe que
haya espacio suficiente antes de intentar la reconstrucción. Enterprise Manager comprueba
automáticamente los requisitos de espacio.
En la página SQL Details, aparecen los detalles de la última sentencia SQL ejecutada en esa sesión, que es
la que está en duda. Haga clic en el separador Plan para ver el plan de ejecución de la consulta. Si aparece
una opción para ver el gráfico o la tabla, seleccione el botón de radio Table. La opción Graph no está
soportada en Firefox.

Guía de Tareas Practico Final PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guía de Tareas Practico Final PDF

Cargado por

Copyright:

Formatos disponibles

PRACTICO FINAL. AR-UTNME-DBA2.

CESARI M. PROYDESA – DBA2 pág. 1

D. Respaldo de la Base de Datos

CESARI M. PROYDESA – DBA2 pág. 2

A. Creación de una Base de Datos

1) Práctica de Creación de la Base de Datos

CESARI M. PROYDESA – DBA2 pág. 3

LOGFILE GROUP 1 (‘/u01/app/oracle/oradata//redo01a.log’, ‘/u02/oradata/SID/redo01b.log’) SIZE

CESARI M. PROYDESA – DBA2 pág. 4

d. Deshabilitar cualquier instancia que se esté usando

¿Cuantos miembros tiene cada grupo?

TableSpace Fecha de Creación Tamaño Inicial Crecimiento Tamaño Máximo Observaciones

Control Files Fecha de Creación Tamaño Inicial Crecimiento Tamaño Máximo

Log Files Fecha de Creación Tamaño Inicial Crecimiento Tamaño Máximo

2) Cálculo de Volúmenes de una Base de Datos

CESARI M. PROYDESA – DBA2 pág. 6

B. Mantenimiento de la Base de Datos

CESARI M. PROYDESA – DBA2 pág. 7

 Shutdown Immediate. El proceso de detención de la base de datos mediante el immediate, termina

Taxonomía de un procedimiento almacenado

CESARI M. PROYDESA – DBA2 pág. 8

CESARI M. PROYDESA – DBA2 pág. 9

CESARI M. PROYDESA – DBA2 pág. 10

El MANTENIMIENTO PROACTIVO1 de la base de datos es sencillo por la infraestructura sofisticada de Oracle

VISUALIZACIÓN DEL HISTORIAL DE ALERTAS

CESARI M. PROYDESA – DBA2 pág. 11

El Repositorio de Carga de Trabajo Automática (AWR) proporciona servicios a los componentes de

CESARI M. PROYDESA – DBA2 pág. 12

ESTADÍSTICAS DEL OPTIMIZADOR

CESARI M. PROYDESA – DBA2 pág. 13

Las estadísticas se ven en la vista DBA_TABLES, incluyen:

Tenemos la posibilidad de activar o desactivar las restricciones simplemente configurando el "checkbox"

CESARI M. PROYDESA – DBA2 pág. 15

Ahora podemos usar ese tablespace y añadirle tablas.

CESARI M. PROYDESA – DBA2 pág. 16

CESARI M. PROYDESA – DBA2 pág. 17

6) Ampliar El Tamaño De Un DataFile

9) Activar el Modo Seguro de Transacción (ARCHIVE)

CESARI M. PROYDESA – DBA2 pág. 18

5. Abrimos la base de datos: ALTER DATABASE OPEN;

10) Creación de Índices

11) Modificación de Índices

12) Monitoreo de Índices

CESARI M. PROYDESA – DBA2 pág. 20

c. Para monitorear el índice:

13) Borrado de Índices

14) Crear un grupo de Redo Log Files

15) Eliminar un grupo de Redo Log Files

CESARI M. PROYDESA – DBA2 pág. 21

17) Eliminar un elemento de un grupo de Redo Log Files

18) Trasladar un elemento a un subgrupo de Redo Log Files

19) Crear ENLACES de base de datos

CESARI M. PROYDESA – DBA2 pág. 23

Y también aparece en la pantalla de Nomenclatura local en Administración de Servicios de Red:

Ahora podremos crear el enlace.

Para crear un enlace pulsamos en "Crear". El enlace se creará en el esquema "PUBLIC"

20) Crear SECUENCIAS

CESARI M. PROYDESA – DBA2 pág. 24

USO DE LA PÁGINA MANAGE OPTIMIZER STATISTICS

RECOPILACIÓN MANUAL DE ESTADÍSTICAS DEL OPTIMIZADOR

CESARI M. PROYDESA – DBA2 pág. 25

No se recomienda recopilar estadísticas manualmente para la recopilación rutinaria de estadísticas

Preferencias de recopilación de estadísticas