Ejercicio Tipo Examen 1eval Fran

Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno.
Administración de Base de Datos
EJERCICIOS OPCIONALES DEL PRIMER TRIMESTRE

DE ADMINISTRACIÓN DE BASES DE DATOS
OBJETIVO
La tarea de administración de una base de datos para múltiples usuarios

tiene un grado de dificultad alto. El DBA (Data Base Administrator) o
Administrador de la Base de Datos suele ser un profesional experimentado
para poder manejar los problemas de los demás usuarios y los propios del
funcionamiento del sistema. El Administrador de la Base de Datos suele
enfrentarse a situaciones relacionados con la instalación del propio
software (en nuestro caso Oracle), el diseño y la creación de la base de
datos, el arranque y la parada de la base de datos, la creación y el
control de usuarios, la concesión de privilegios y asignación de roles, la
gestión del espacio de almacenamiento, la realización de copias de
seguridad y la recuperación de la base de datos.
En la realización del presente trabajo se va a adoptar el rol como

Administrador de Base de Datos que se va a enfrentar a algunas de las
tareas arriba mencionadas y vistas en la parte Administración de Oracle
II, a saber:
 Arranque y parada de la base de datos.

 Creación y control de usuarios.
 Concesión de privilegios.
 Asignación de roles.
 Gestión del espacio de almacenamiento de los esquemas.
DESCRIPCIÓN DEL SISTEMA
Vamos a suponer que “Empresa” es una PYME dedicada a la producción

y venta online que cuenta con un Gerente y está organizada según
cuatro departamentos: Almacén, Producción, Ventas e Informática. En
Almacén trabaja a_emp1 y a_emp2, en Producción p_emp1, p_emp2 y
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos
p_emp3, en Ventas v_emp1 y en Informática i_emp1, i_emp2 e i_emp3. El

empleado i_emp1 será el administrador de la Base de Datos.
El Gerente de la empresa le ha asignado al Administrador de la Base de

Datos la creación de una nueva base de datos llamada “Empresa”
donde se almacenará toda la información relevante a su
funcionamiento, ya que no le gusta la idea de utilizar para ello la base de
datos que se creó al instalar el producto por primera vez y donde la
estructura de la empresa todavía no había sido definida a efectos de
almacenamiento de información.
Realizaremos la creación de la Base de Datos con el Asistente de

Configuración de Bases de Datos, instalado con el software de Oracle.
1.-Asistente de configuración de Base de Datos

2.-Ventana de Bienvenida del Asistente
3.-Selección de la operación a realizar

4.-Elegimos plantilla “General Purpose” para la creación de la base de datos. En mostrar detalles
se puede consultar la descripción de dicha plantilla
5.-Nombre de la Base de Datos Global y SID

6.-Modo de funcionamiento de la base de datos: Modo Servidor Dedicado, ya que no se prevé

que el número total de conexiones cliente sea muy grande.
7.-Parámetros de inicialización: memoria

8.-Parámetros de inicialización: Juego de Caracteres
9.-Parámetros de inicialización:Tamaño del área de Ordenación

10.-Parámetros de inicialización: Ubicación de Archivos
11.-Parámetros de inicialización: Decidimos que la base de datos no se ejecute en Modo Archive

Log
12.-Almacenamiento en la Base de Datos. Aceptamos los valores que nos sugiere.
13.-Crear Base de Datos

14.-Resumen de opciones, verificamos que son correctas y pulsamos en Aceptar.
15.-Creando Base de Datos

16.-contraseñas de SYS y SYSTEM
17.-Base de datos empresa aparece en la consola de Oracle Enterprise Manager. Conectado

con usuario sys como sysdba
Para la realización de los ejercicios siguientes, utilizaremos la base de

datos empresa recién creada.
Antes de entrar en el desarrollo de los ejercicios, vamos a definir un

espacio de tablas para cada uno de los departamentos. Los datos de
cada departamento se almacenarán en su espacio de tablas
correspondiente.
Los espacios de tablas tendrán las siguientes características:
Tablespace Nombre de Directorio de archivos Tama Autoe Inc Tamaño

archivo ño xtend máximo
inicial
informatica inform01.ora c:\oracle\oradata\empresa 20 MB Sí 1024KB 35MB
almacen almcn01.ora c:\oracle\oradata\empresa 15 MB Sí 512KB 25MB
produccion prodccn01.ora c:\oracle\oradata\empresa 10MB Sí 512KB unlimited
ventas ventas01.ora c:\oracle\oradata\empresa 5MB Sí 256KB 15MB
Creamos el tablespace “informática” a través de la consola Enterprise

Manager:
18.-Crear nuevo tablespace

Doble click para definir parámetros

de almacenamiento.
19.-Crear tablespace:nombre
20.-Crear tablespace: tamaño inicial

21.-Crear tablespace: Autoextend, valor máximo.
22.-Crear tablespace: crear tras haber introducido los parámetros anteriores.

23.-Crear tablespace: tablespace creado correctamente.
Supongamos que el usuario administrador, se encuentra, en este

momento, sin acceso a la consola Enterprise Manager y decide crear los
restantes tablespaces a través de SQLPlus.
Tablespace almacen
SQL>CREATE TABLESPACE almacen
DATAFILE ‘c:\oracle\oradata\empresa\almacn01.ora’
SIZE 15M AUTOEXTEND ON NEXT 512K MAXSIZE 25M;
Tablespace produccion
SQL>CREATE TABLESPACE produccion
DATAFILE ‘c:\oracle\oradata\empresa\prodccn01.ora’
SIZE 10M AUTOEXTEND ON NEXT 512K MAXSIZE UNLIMITED;
Tablespace ventas
SQL>CREATE TABLESPACE ventas
DATAFILE ‘c:\oracle\oradata\empresa\ventas01.ora’

24.-Tablespaces almacen, produccion y ventas creadas con SQLPlus
Una vez creados los tablespaces anteriores, el usuario administrador crea

los usuarios de cada departamento, asignándoles como tablespace el
propio de cada departamento.
El primer usuario lo crea con Enterprise Manager y el resto con SQLPLus.
25.-Crear usuario: crear.

Le asignamos
el tablespace
informatica
Notar que el sistema le asigna el rol connect

automáticamente
26.-Crear usuario en Enterprise Manager
Como el usuario i_emp1 va a ser administrador de la base de datos, se le

asigna dicho rol:
27.-Rol DBA asignado a i_emp1

28.-Usuario i_emp1 creado correctamente
Aquí se puede plantear una primera cuestión, ¿dispondrá el usuario

i_emp1 de un esquema que pueda ser consultado dentro de Enterprise
Manager?
La respuesta es que no, ya que dicho usuario no ha creado todavía

ningún objeto, por lo que no dispondrá aún de ningún esquema.
29.-Notar cómo usuario i_emp1 aparece en Seguridad-Usuarios, pero no tiene un Esquema

todavía.
A partir de este momento será i_emp1 el que ejerza como DBA y con
dicho usuario realizaremos todo lo relacionado con la administración de
la base de datos.
Inicialmente cada departamento cuenta con una tabla al que deberán

tener acceso de consulta, actualización e introducción de datos los
empleados de dicho departamento. Los directores de departamento
podrán además modificar dicha tabla y les tendrá que ser otorgado el
privilegio de poder dar acceso de consulta a la misma a futuros
empleados cuando fuesen contratados. Adicionalmente, la empresa
dispone de una tabla de información general que podrá ser consultada
por todos los empleados. Esta tabla se almacenará en el tablespace
USERS creado por el sistema al instalarse.
El usuario DBA, i_emp1 crea ahora las tablas (las realizamos

extremadamente sencillas ya que el objetivo de la presente práctica no
es la creación de tablas) indicando que deberán ser almacenadas en los
tablespaces adecuados. Lo realizará desde SQLPlus:
CREATE TABLE infgeneral (
cig VARCHAR2(20)
) TABLESPACE users; // Si no indicásemos esto, lo crearía en el

tablespace informática, que es el tablespace por defecto de i_emp1
CREATE TABLE informdata (
cid NUMBER(6)
) ; //  No ponemos nada porque lo creará en su tablespace por

defecto, que es informática, donde queremos que sea almacenada.
CREATE TABLE almacendata (
cad VARCHAR2(25)
) TABLESPACE almacen;
CREATE TABLE prodccdata (
cpd VARCHAR2(25)
) TABLESPACE produccion;
CREATE TABLE ventasdata (
cvd VARCHAR2(25)
) TABLESPACE ventas;
30.-Tablas creadas en su tablespace correspondiente

Ahora vemos como el usuario i_emp1 dispone de un esquema en

Enterprise Manager, ya que los objetos creados, los ha creado en su
esquema.
31.-Tablas creadas en esquema i_emp1.
Veamos si, en efecto, se han creado en los tablespaces pretendidos:
SQL> SELECT table_name, tablespace_name FROM all_tables
WHERE owner=UPPER(‘i_emp1’);
32.-Tablas creadas en su tablespace correcto

El resto de usuarios se crearán desde SQLPlus. Para la creación del resto

de usuarios, se tendrá en cuenta lo siguiente:
 El usuario Gerente podrá crear, consultar, actualizar e introducir

información en cualquier tabla de cualquier esquema, pero no
podrá modificar su definición. Si tuviese que crear una tabla, por
defecto se almacenaría en el espacio de tablas users. Su cuota
será ilimitada en users pero limitada a 1M en informática, a 3M en
producción y almacén y a 1M en ventas.
 Cada trabajador podrá almacenar información únicamente en el
tablespace correspondiente a su departamento (connect).
 Los empleados del departamento de informática que son
programadores y crean aplicaciones deberán tener asignado el rol
resource y una cuota de 5M en tablespace informatica.
 Los directores de Almacen (a_emp1), Producción (p_emp1) y
Ventas (v_emp1) deberán poder asignar los permisos de consulta,
actualización e introducción de datos a posibles futuros
trabajadores contratados, sin que sea necesario que el
Administrador efectúe esa rutina.
 Solamente los trabajadores de producción tendrán una cuota
ilimitada en su tablespace. Los demás tendrán una cuota de 5M en
su tablespace.
Usuario gerente
Teniendo en cuenta lo arriba especificado:
SQL>CREATE USER gerente IDENTIFIED BY gerente
DEFAULT TABLESPACE users
QUOTA UNLIMITED ON users QUOTA 1M ON informatica
QUOTA 3M ON produccion QUOTA 1M ON ventas;

GRANT CREATE CONNECT, CREATE ANY TABLE, SELECT ANY TABLE,
UPDATE ANY TABLE, INSERT ANY TABLE TO gerente;
33.-Usuario gerente
Evidentemente, al Administrador de le ha olvidado fijar la cuota del

usuario gerente en almacén, así que tendrá que hacer uso de la orden
ALTER:
34.-Gerente no dispone de cuota en almacen.
Así, tendrá que modificar el usuario gerente para concederle la cuota:
SQL>ALTER USER gerente QUOTA 3M ON almacen;
35.-Usuario gerente modificado

Y ahora sí, vemos que las cuotas son las correctas:
36.-Cuotas correctas de usuario gerente
Usuarios del departamento de Informática
Recordemos las exigencias especificadas arriba (resource y cuota de 5M

en tablespace informática). Recordemos que, además, podrán consultar
la tabla de información general de la empresa y podrán consultar,
actualizar e insertar datos en la tabla de su departamento. Asimismo, el
director del departamento, que en este caso es i_emp1, deberá poder
asignar permiso de consulta sobre dicha tabla de departamento a los
usuarios que puedan ser contratados. En este caso el director de
informática es el administrador de la base de datos, por lo que no se
requerirá ninguna acción adicional en este sentido.
SQL>CREATE USER i_emp2 IDENTIFIED BY i_emp2
DEFAULT TABLESPACE informatica
QUOTA 5M ON informatica;
SQL>CREATE USER i_emp3 IDENTIFIED BY i_emp3
DEFAULT TABLESPACE informatica
QUOTA 5M ON informatica;
SQL>GRANT RESOURCE TO i_emp2, i_emp3;

SQL>GRANT SELECT ON infgeneral TO i_emp2, i_emp3;
SQL>GRANT SELECT, UPDATE, INSERT ON informdata TO i_emp2, i_emp3;
37.-Empleados de informática
Usuarios del departamento de Almacén
Recordemos requisitos especificados:
 Almacenar objetos propios en su tablespace (connect).

 Cuota de 5M en su tablespace almacen.
 Pueden consultar la tabla de información general de la empresa,
 Pueden consultar, modificar e insertar valores en su tabla de
departamento almacendata.
 El director, a_emp1, debe poder asignar el permiso de consultar,
modificar e insertar en la tabla de departamento almacendata a
los posibles futuros trabajadores.
SQL>CREATE USER a_emp1 IDENTIFIED BY a_emp1
DEFAULT TABLESPACE almacen
QUOTA 5M ON almacen;
SQL>CREATE USER a_emp2 IDENTIFIED BY a_emp2
DEFAULT TABLESPACE almacen
QUOTA 5M ON almacen;
GRANT CONNECT TO a_emp1, a_emp2;
Llegado a este punto, el administrador considera que no tiene sentido

estar asignando permisos de consulta sobre la table infgeneral a cada
grupo de empleados. Además, cada vez que se contraten trabajadores,
deberá tener que hacerlo de nuevo. Así que decide revocar los permisos
a los usuarios del departamento de informática a quienes le había
asignado los permisos y darlos de nuevo utilizando la opción PUBLIC.
REVOKE SELECT ON infgeneral FROM i_emp2, i_emp3;
GRANT SELECT ON infgeneral TO PUBLIC;
GRANT SELECT, UPDATE, INSERT ON almacendata TO a_emp1
WITH GRANT OPTION;
GRANT SELECT, UPDATE, INSERT ON almacendata TO a_emp2;

38.-Empleados de almacén y revoke y posterior grant to public
Usuarios del departamento de producción
• Almacenar objetos propios en su tablespace (connect).

• Cuota ilimitada en su tablespace produccion.
• Pueden consultar la tabla de información general de la
empresa (no es necesario hacer nada en relación con esto al
haberse otorgado ese permiso a PUBLIC en el paso anterior).
• Pueden consultar, modificar e insertar valores en su tabla de
departamento prodccdata.
• El director, p_emp1, debe poder asignar el permiso de consultar,

modificar e insertar en la tabla de departamento prodccdata a
SQL> CREATE USER p_emp1IDENTIFIED BY p_emp1
DEFAULT TABLESPACE produccion
QUOTA UNLIMITED ON produccion;
SQL> CREATE USER p_emp2 IDENTIFIED BY p_emp2
SQL>CREATE USER p_emp3 IDENTIFIED BY p_emp3
GRANT CONNECT TO p_emp1, p_emp2, p_emp3;
GRANT SELECT, UPDATE, INSERT ON prodccdata TO p_emp1
WITH GRANT OPTION;
GRANT SELECT, UPDATE, INSERT ON prodccdata TO p_emp2, p_emp3;

39.-Empleados de producción (notar error al hacer referencia a la tabla de datos de producción,

se ha vuesto a escribir correctamente seguidamente)
Usuarios del departamento de ventas
• Almacenar objetos propios en su tablespace (connect).

• Cuota de 5M en su tablespace ventas. Aunque actualmente
solamente se encuentra el director de departamento de ventas,
la empresa planea contratar otro trabajador.
• Pueden consultar la tabla de información general de la
empresa (no es necesario hacer nada en relación con esto al
haberse otorgado ese permiso a PUBLIC anteriormente).
• Pueden consultar, modificar e insertar valores en su tabla de
departamento ventasdata.
• El director, v_emp1, debe poder asignar el permiso de consultar,

modificar e insertar en la tabla de departamento ventasdata a
SQL> CREATE USER v_emp1 IDENTIFIED BY v_emp1
DEFAULT TABLESPACE ventas
QUOTA 5M ON ventas;
SQL> GRANT CONNECT TO v_emp1;
SQL> GRANT SELECT, UPDATE, INSERT ON ventasdata TO v_emp1
WITH GRANT OPTION;
40.-Empleados de ventas
Una vez definido un entorno en el que existen tablas, usuarios, roles y

permisos aplicados, vamos a pasar a realizar los ejercicios en sí. Para ello
utilizaremos lo definido en nuestra base de datos “empresa”.
Ejercicio Número 1
En este primer ejercicio, vamos a simular que el usuario Administrador se

encuentra conectado en el servidor y un usuario, por ejemplo, p_emp2
crea una conexión desde un equipo diferente al del servidor. La conexión
la crea desde SQL Developer
41.-Administrador 1_emp1 conectado en propio servidor
42.-Conexión de p_emp2 desde cliente SQL Developer

Es la primera vez que p_emp2 se conecta a la base de datos y desea

consultar la tabla de su departamento “prodccdata”.
Con los permisos asignados anteriormente, ¿obtendrá algún resultado si

ejecuta SELECT * FROM prodccdata; ? ¿Qué ocurre?¿Se te ocurre alguna
solución elegante al problema?
Vemos que si efectuamos esa consulta, el sistema nos muestra un error

ORA-00942: la tabla o vista no existe.
43.-Error ORA-00942:la vista no existe
El mensaje de error es perfectamente lógico, ya que la tabla se

encuentra dentro del esquema del usuario administrador de la base de
datos, que fue quien creó todas las tablas de departamento. Así que si el
usuario ejecuta lo siguiente:
SQL> SELECT * FROM i_emp1.prodccdata;
Debería obtener una respuesta positiva:

44.-Respuesta positiva del sistema (no contiene ningún valor nuestra tabla, pero muestra la
columna correspondiente)
Aunque técnicamente correcto, no es una solución elegante el que

cada usuario tenga que teclear el nombre del usuario administrador
delante de las tablas de su departamento. Así, lo que puede hacer
p_emp2 es crearse un sinónimo a la tabla de su departamento, que se
encuentra dentro del esquema i_emp1 (administrador).
SQL> CREATE SYNONYM prodccdata FOR i_emp1.prodccdata;
45.-Tras definir un sinónimo, se puede referir a la tabla propiedad de i_emp1 mediante el nombre
del sinónimo.
Ejercicio Número 2
En este ejercicio, siguiendo la situación del anterior, el usuario

administrador decide que tiene que parar la base de datos por motivos
de mantenimiento. En primer lugar echa un vistazo a “conexiones” en la
consola Enterprise Manager para ver cuántas sesiones hay en la base de
datos pertenecientes a empleados. Vemos que hay tres sesiones, pero
pertenecientes al usuario p_emp2 utilizando SQL Developer.
46.-Tres sesiones pertenecientes a p_emp2 utilizando una conexión de SQL Developer
El administrador, dadas las pocas sesiones abiertas, decide cerrar la base

de datos, pero se quiere asegurar de que la base de datos se cierre
cuando el usuario p_emp2 concluya su sesión y termine sus tareas, pero
tampoco desea que se acepten más conexiones, ¿cómo podría
hacerlo? ¿Qué mensaje recibe un usuario si desea conectarse tras el
cierre normal de la base de datos?
La respuesta sería haciendo un cierre normal, en el que no se admiten

conexiones nuevas, el servidor Oracle espera a que se desconecten
todos los usuarios antes de completar el cierre, cierra y desmonta la base
de datos y por último cierra la instancia.
SQL> SHUTDOWN NORMAL (AUNQUE NORMAL ES LA OPCIÓN POR

DEFECTO)
Recordemos que existe modo TRANSACCIONAL, IMMEDIATE Y ABORT

también.
47.-Base de Datos esperando a cerrarse cuando terminen sesiones en la misma.
El usuario conectado no nota nada, pero ¿y si intenta estableer conexión

un nuevo usuario?
Vemos que el sistema muestra un mensaje ORA-01090: shutdown in

progress-connection is not permitted
48.-Mensaje que muestra el sistema ante el intento de una nueva conexión por parte de otro
usuario. ORA-01090: shutdown in progress-connection is not permitted.
Como el usuario p_emp2 tarda mucho en desconectarse, el

administrador piensa que puede que no esté en el terminal o que se le
haya olvidado y esté en cualquier otra tarea. Así que decide matar la
sesión del mismo. ¿desde dónde puede hacerlo?¿Qué ocurre cuando le
mata la sesión?
La sesión se puede terminar o matar desde Enterprise Manager o desde

la consola SQLPlus. Lo hacemos esta vez desde la consola, eligiendo la
opción Matar Sesión Inmediato
49.-Terminando o matando sesión de p_emp2 de forma inmediata.
Cuando mata la primera sesión de p_emp2, si p_emp2 realiza alguna

acción desde el cliente, el sistema le muestra el siguiente mensaje:
50.-Mensaje a usuario en cliente cuando realiza alguna acción. ORA-00028: su sesión ha sido
matada.
Sin embargo, la base de datos, sigue sin cerrarse, ¿tendremos que matar
el resto de sesiones que crea SQL Developer?
51.-Matando sesión 2 creada por SQL Developer
52.-Matando sesión número 3 de SQL Developer

53.-Base de datos cerrada, desmontada e instancia Oracle cerrada
Por último, el administrador decide volver a hacer disponible la base de

datos a los empleados. Lo hace en tres etapas, ¿puedes detallarlas?
¿Sería posible haberlo hecho en dos etapas? ¿Cómo? Comprueba si el
administrador y un empleado, por ejemplo p_emp2 se pueden conectar
a la base de datos en las dos primeras etapas.
La respuesta es que si ha planeado poner la base de datos a disposición

de los usuarios en tres etapas deberá ser mediante la secuencia:
1. STARTUP NOMOUNT
El inicio de la instancia incluye: lectura del archivo de parámetros
initsid.ora, asignación de la SGA, inicio de los procesos en segundo
plano y apertura del archivo ALERT y los archivos de rastreo.
54.-Inicio de la instancia
Vamos a intentar conectarnos a la base de datos con el usuario

administrador y con un usuario normal:
Intentamos conectarnos con el usuario sys como sysdba y el
sistema nos muestra un mensaje de Status: Success
55.-Aparentemente la conexión con sys parece posible
Sin embargo, al conectar, SQL Developer nos informa de un

problema al intentar consultar las tablas. ORA-01219: base de datos
no abierta: solo se permiten consultas en tablas/vistas fijas.
56.-Error al intentar consultar tablas

Desde SQLPlus:
Vemos que nos permite conectarnos como sys, pero, evidentemente, no

podemos consultar ningún objeto.
57.-Conexión posible con sys, pero limitada
Y si ahora intentamos conectarnos con un usuario normal, por ejemplo,

p_emp2:
58.-error ORA-01033:Oracle initilization or shutdown in progress

2. ALTER DATABASE MOUNT
Para realizar las operaciones de mantenimiento específicas, se inicia

una instancia y se monta una base de datos, pero no se abre.
59.-Base de datos montada
3. ALTER DATABASE OPEN
La apertura permite que cualquier usuario se conecte a la base de

datos y realice operaciones normales de acceso a datos.
60.-Base de datos abierta. Permite conexión de usuarios y acceso normal a datos.
En cuanto a cómo podría haberse abierto la base de datos en dos

etapas:
STARTUP MOUNT
ALTER DATABASE OPEN

Ejercicio Número 3
En este ejercicio, el administrador, perteneciente al departamento de

informática, i_emp1, ha decidido que los empleados del departamento
de informática, incluído él mismo, dispongan de un número máximo de 2
sesiones por usuario, un tiempo de conexión ilimitado y un número
máximo de intentos de conexión antes de bloquear el usuario de 3.
¿Cómo podría hacer esto sin tener que asignarlos cada vez a cada
empleado? Comprueba que los límites asignados al perfil funcionan
apropiadamente.
Por último, después de comprobar lo anterior, el Administrador decide

que las cuentas podrán tener 2 minutos máximos de inactividad. Modifica
el perfil para ello mediante SQL.
Resp:
Para realizar esta tarea, el Administrador podría crear un perfil, con las
limitaciones impuestas y asignar ese perfil a los empleados del
departamento de informática. Decide crear el perfile a través de la
consola SQLPLus.
IMPORTANTE: Para que el sistema tenga en cuenta los perfiles hay que
fijar el siguiente parámetro a TRUE, bien desde la consola Enterprise
Manager, o bien directamente desde SQLPlus de la siguiente manera:
SQL> ALTER SYSTEM SET RESOURCE_LIMIT=TRUE;

61.-Fijando resource_limit a true. Como está seleecionado Ejecutando arriba, será válido hasta
que la base de datos se reinicie.
SQL> CREATE PROFILE empinform LIMIT
SESSIONS_PER_USER 2
CONNECT_TIME UNLIMITED
FAILED_LOGIN_ATTEMPTS 3;
62.-Perfil empinform creado

Seguidamente el administrador tendrá que modificar su propio usuario y

los usuarios i_emp2, i_emp3 para añadirles este perfil.
SQL> ALTER USER i_emp1 PROFILE empinform;
63.-Asignando perfil empinform a los empleados del Departamento de Informática.
Ahora nos conectamos con el cliente SQL Developer con el usuario

i_emp2, pero el sistema nos devuelve un error indicándonos que el usuario
i_emp2 carece de permisos para crear una sesión:
64.-Falta permiso create sesión

Informado el Administrador, se da cuenta de que cuando creó los

usuarios, otorgó el rol GRANT RESOURCE a los mismos, el cual no contiene
el privilegio CONNECT como vemos en Enterprise Manager:
65.-Privilegios del sistema que tiene otorgados el rol RESOURCE
Lo soluciona otorgándoles el privilegio CREATE SESSION a ambos

empleados de su departamento:
SQL> GRANT CREATE SESSION TO i_emp2, i_emp3;
66.-CREATE SESSION otorgado a empleados del departamento de informática

Ahora sí, podemos conectarnos con el SQL Developer:
67.-conectado con SQL Developer
Consultamos con Enterprise Manager el número de sesiones abiertas por

i_emp2. Vemos que SQL Developer ha abierto dos sesiones i_emp2:
68.-Dos sesiones abiertas con i_emp2

¿Qué ocurre si i_emp2 intenta realizar otra conexión, por ejemplo desde
SQLplus?
69.-SQLplus nolog desde ordenador cliente
70.-Mensaje ORA-02391 indicándonos que se ha superado el límite SESSIONS_PER_USER
Intenta ahora “loguear” con el usuario i_emp3, introduce una contraseña

errónea 4 veces seguidas ¿qué ocurre? ¿Cómo puede solucionarlo el
administrador?
Vemos que al introducir 4 veces la contraseña errónea, se imcumple el

límite establecido en el perfil empinform (FAILED_LOGIN_ATTEMPS 3) y el
sistema bloquea la cuenta
71.-Cuenta bloqueada. Otra limitación del perfil funcionando correctamente.

El Administrador podrá solucionarlo, bien desde Enterprise Manager,

desbloqueando la cuenta:
72.-Pulsando desbloquear cuenta de i_emp3
O bien desde SQLPlus:
SQL> ALTER USER i_emp3 ACCOUNT UNLOCK;
73.-Cuenta desbloqueada
Y por último vemos que si ahora i_emp3 proporciona los credenciales

correctos tras el bloqueo, su conexión es posible.
74.-Conexión realizada tras desbloqueo de cuenta
Finalmente, el Administrador decide, como se dice al principio del

ejercicio, que las cuenta debería poder estar inactivas un período
máximo de dos minutos, así que tendrá que añadir al perfil el parámetro
IDLE_TIME y fijarlo a 2, como sigue:
SQL> ALTER PROFILE empinform LIMIT IDLE_TIME 2;
75.-Perfil empinform modificado. Añadiendo periodo de inactividad máximo de 2 minutos.
Y si intentamos ahora, tras un periodo de inactividad superior a los 2

minutos, realizar alguna operación con nuestro usuario i_emp3:
76.-Tras volver a conectarse el usuario después de la modificación del perfil, y permanecer un

tiempo de inactividad superior al máximo establecido, e intentar una operación en la base de
datos, el sistema muestra el mensaje ORA-2396: ha excedido el tiempo máximo de inactividad,
vuelva a conectarse.
Ejercicio número 4
La Gerencia de la empresa considera que sería una buena idea crear un

usuario llamado “comprador” que pudiera conectarse, crearse sus tablas
y vistas y tuviera permisos de INSERT Y SELECT en la tabla ventasdata.
¿Cómo podría implantarlo el Administrador?Tras haber efectuado lo
anterior, se dan cuenta de que no es una buena idea otorgar el privilegio
de INSERT sobre ventasdata, ¿cómo podría el Administrador solucionarlo?
Resp:
El Administrador podría pensar en crear un tablespace llamado

“compras” donde el usuario comprador almacenase sus objetos. Esto
evitaría mezclar su información con los de la empresa propiamente

dicha.
En el caso de que más adelante tuviese que crear otros usuarios con estos
mismos privilegios, puede decidir crear un rol que tenga los siguientes
privilegios: CREATE SESSION, CREATE TABLE, CREATE VIEW, INSERT y SELECT
en ventasdata.
Y por último, asignarle ese rol al usuario creado.
Veamos cómo hacer todo esto:
Tablespace
SQL>CREATE TABLESPACE compras
DATAFILE ‘c:\oracle\oradata\empresa\compras01.ora’
Usuario
SQL> CREATE USER comprador IDENTIFIED BY comprador
DEFAULT TABLESPACE compras
QUOTA 1M ON compras;
Rol
SQL> CREATE ROL comp;
Conceder privilegios al rol
SQL> GRANT SELECT, INSERT ON ventasdata TO comp;
SQL> GRANT CREATE SESSION, CREATE TABLE, CREATE VIEW TO comp;
Asignar Rol a Usuario
SQL> GRANT comp TO comprador;

Vemos lo mismo en SQLPLus:
77.-Operaciones con usuario comprador
Vamos a comprobar que en efecto, el usuario “comprador” puede

insertar datos en la tabla ventasdata:
SQL> INSERT INTO i_emp1.ventasdata VALUES (‘DECOMPRADOR’);
78.-Información insertada por usuario comprador

Ahora, la dirección decide retirar el privilegio de poder insertar en la tabla

ventasdata. El Administrador retirará el privilegio del Rol asignado al
usuario “comprador”:
SQL> REVOKE INSERT ON ventasdata FROM comp;
79.-Eliminando privilegio de INSERT ON ventasdata al rol comp
Ahora el usuario “comprador” intenta volver a insertar datos en

ventasdata:
80.-ORA-01031: PRIVILEGIOS INSUFICIENTES. Al intentar insertar datos de nuevo en la tabla

ventasdata.
Ejercicio número 5
En este punto se contrata un empleado en el departamento de ventas.

El administrador lo creará e indicará al sistema que guarde sus objetos en
el tablespace ventas. Le asignará una cuota de 3M en el tablespace
ventas. El director de ventas v_emp1 decide que durante el periodo de
prueba, dicho trabajador solamente pueda conectarse a la base de
datos y seleccionar información de la tabla “ventasdata”. ¿Puede
otorgarle dicho permiso el director de ventas? ¿Por qué?
El usuario a_emp2 (empleado de almacen) inserta en la tabla

almacendata una serie de datos. Tras introducir 3 se da cuenta de que
se ha equivocado, ¿qué puede hacer para evitar pedirle al
Administrador que borre los datos insertados?
Por último, la gerencia, dados los altos costes de producción, decide

prescindir de dicho departamento y subcontratar la producción
externamente. Por ello, solicita al Administrador de la Base de datos que
elimine toda la información relativa a dicho departamento, eliminando a
sus usuarios y el tablespace correspondiente. No desea que quede
ningún rastro de dicho tablespace, ni siquiera el fichero físico asociado al
mismo. Detalla los pasos necesarios para que se cumplan las exigencias
del Gerente.
Resp:
Primeramente el Administrador crea el usuario v_emp2:
SQL> CREATE USER v_emp2 IDENTIFIED BY v_emp2
DEFAULT TABLESPACE ventas QUOTA 3M ON ventas;

81.-Nuevo empleado de ventas creado.
Seguidamente, el Administrador concede el privilegio de CREATE

SESSION:
SQL>GRANT CREATE SESSION TO v_emp2;
82.-Privilegio de crear sesión otorgado a nuevo empleado de ventas
¿Podrá ahora el director de departamento v_emp1 otorgarle el privilegio

de consultar la tabla de datos del departamento ventasdata?
La respuesta es que sí, porque cuando el Administrador creó los usuarios

que eran jefes de departamento, les asignó los privilegios de la siguiente
manera, se puede consultar anteriormente (en concreto a v_emp1):
SQL> GRANT SELECT, UPDATE, INSERT ON ventasdata TO v_emp1
WITH GRANT OPTION;
Por tanto, vemos que v_emp1 puede otorgar cualquiera de esos

privilegios (SELECT, UPDATE, INSERT) sobre la tabla i_emp1.ventasdata a
cualquier otro usuario.
Lo verificamos con el Enterprise Manager, donde vemos como, en efecto,
El director de ventas v_emp1 puede otorgar esos privilegios a otro usuario.

83.-comprobando que, en efecto, v_emp1 (Director de Ventas) puede otorgar privilegios a otros
usuarios sobre ventasdata (que recordemos, pertenece al esquema del Administrador i_emp1).
Ahora se conecta v_emp2 e intenta consultar la tabla ventasdata (no

sabe que su director, todavía no le ha otorgado los privilegios):
84.-v_emp2 se conecta a la base de datos e intenta consultar la tabla ventasdata antes de que
su director le haya otorgado los permisos. El sistema le muestra el error ORA-00942: la tabla o vista
no existe
Ahora, el director del departamento le otorga el privilegio de poder

consultar dicha tabla:
85.-El Director de Ventas, v_emp1 otorga el privilegio de consultar la tabla ventasdata a su nuevo
empleado.
Y ahora, tras repetir la consulta v_emp2, obtiene la información requerida
86.-Datos consultados satisfactoriamente
Ahora nos vamos a conectar con el usuario a_emp2 y vamos a insertar

unos datos que, simularemos que son erróneos:
87.-Insertando valores en almacendata. Consulta de los valores introducidos.
Ahora se da cuenta de que dichos valores son erróneos. Lo normal sería

borrar las filas usando la orden DELETE y siguiendo algún criterio con
WHERE, por ejemplo:
DELETE FROM i_emp1.almacendata WHERE cad LIKE ‘_O’;

Pero, como vemos en la imagen siguiente, carece de los privilegios

necesarios:
88.-empleado de almacen a_emp2 carece de los privilegios necesarios para borrar datos de la
tabla almacendata
Podría actualizar los valores introducidos por los correctos, pero podría ser
largo. O simplemente supongamos que tampoco tuviera permisos para
actualizar la tabla. Como al insertar los valores no ha realizado un
COMMIT, si ejecuta ROLLBACK, dejará sin efecto la introducción de esos
valores.
Simple error de
teclear mal
i_emp1
89.-ROLLBACK de a_emp2 para deshacer la entrada de datos errónea en la tabla almacendata.

Por último, el Administrador debe deshacerse de todo rastro del

departamento de producción, eliminando usuarios, tablespace
producción y ficheros asociados.
Eliminando usuarios
En este caso, vamos a hacerlo manualmente. En el caso real de muchos

usuarios, podría crearse un procedimiento PL/SQL que mediante un bucle
“FOR, WHILE, LOOP etc..” leyese los nombres de los usuarios que
guardasen su información en el tablespace de interés y los fuese
borrando uno a uno.
Como ya digo, aquí lo haremos manualmente para no alargar en

demasía el presente trabajo.
Borramos los usuarios utilizando la opción CASCADE que suprimirá todos

los objetos del usuario antes de borrarlo:
SQL> DROP USER p_emp1 CASCADE;
90.-Borrando usuarios de producción

Vemos que físicamente existe un fichero asociado al tablespace

producción:
91.-Fichero asociado a tablespace producción
Para que no quede ni rastro deberemos usar varias opciones que

detallamos a continuación:
Primeramente pondremos OFFLINE el tablespace “producción” para

asegurarnos de que no haya sentencias SQL que estén accediendo a
datos del tablespace, en cuyo caso no sería posible borrarlo:
SQL>ALTER TABLESPACE produccion OFFLINE;

92.-Tablespace produccion modificado a OFFLINE. Notar que nos tenemos que conectar con
usuario SYS como SYSDBA
Seguidamente utilizaríamos el siguiente comando
SQL> DROP TABLESPACE produccion INCLUDING CONTENTS AND

DATAFILES CASCADE CONSTRAINTS
Aquí INCLUDING CONTENTS permite borrar un tablespace que contenga

datos. Sin esta opción solamente se podría borrar un tablespace vacío.
AND DATAFILES borra los archivos de datos asociados.
CASCADE CONSTRAINTS borra las relaciones de integridad referencial

que afecten a las tablas del tablespace suprimido.
93.-Tablespace produccion borrado, Notar opciones utilizadas. Recordad que estamos

conectados como sysdba.
Si consultamos ahora los tablespaces, vemos que no aparece

“producción”:
SQL> SELECT tablespace_name FROM dba_tablespaces;

94.-Tablespace produccion borrado.
Y tampoco aparece el fichero prodccn01.ora:
95.-Fichero prodccn01.ora ya no existe.

Ejercicio Tipo Examen 1eval Fran

Cargado por

Información del documento

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

Ejercicio Tipo Examen 1eval Fran

Cargado por

Copyright:

Formatos disponibles

Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno.

Administración de Base de Datos

EJERCICIOS OPCIONALES DEL PRIMER TRIMESTRE

La tarea de administración de una base de datos para múltiples usuarios

En la realización del presente trabajo se va a adoptar el rol como

 Arranque y parada de la base de datos.

DESCRIPCIÓN DEL SISTEMA

Vamos a suponer que “Empresa” es una PYME dedicada a la producción

p_emp3, en Ventas v_emp1 y en Informática i_emp1, i_emp2 e i_emp3. El

El Gerente de la empresa le ha asignado al Administrador de la Base de

Realizaremos la creación de la Base de Datos con el Asistente de

1.-Asistente de configuración de Base de Datos

2.-Ventana de Bienvenida del Asistente

3.-Selección de la operación a realizar

5.-Nombre de la Base de Datos Global y SID

6.-Modo de funcionamiento de la base de datos: Modo Servidor Dedicado, ya que no se prevé

7.-Parámetros de inicialización: memoria

8.-Parámetros de inicialización: Juego de Caracteres

9.-Parámetros de inicialización:Tamaño del área de Ordenación

10.-Parámetros de inicialización: Ubicación de Archivos

11.-Parámetros de inicialización: Decidimos que la base de datos no se ejecute en Modo Archive

12.-Almacenamiento en la Base de Datos. Aceptamos los valores que nos sugiere.

13.-Crear Base de Datos

14.-Resumen de opciones, verificamos que son correctas y pulsamos en Aceptar.

15.-Creando Base de Datos

16.-contraseñas de SYS y SYSTEM

17.-Base de datos empresa aparece en la consola de Oracle Enterprise Manager. Conectado

Para la realización de los ejercicios siguientes, utilizaremos la base de

Antes de entrar en el desarrollo de los ejercicios, vamos a definir un

Los espacios de tablas tendrán las siguientes características:

Tablespace Nombre de Directorio de archivos Tama Autoe Inc Tamaño

Creamos el tablespace “informática” a través de la consola Enterprise

18.-Crear nuevo tablespace

Doble click para definir parámetros

20.-Crear tablespace: tamaño inicial

21.-Crear tablespace: Autoextend, valor máximo.

22.-Crear tablespace: crear tras haber introducido los parámetros anteriores.

23.-Crear tablespace: tablespace creado correctamente.

Supongamos que el usuario administrador, se encuentra, en este

SQL>CREATE TABLESPACE almacen

SIZE 15M AUTOEXTEND ON NEXT 512K MAXSIZE 25M;

SQL>CREATE TABLESPACE produccion

SIZE 10M AUTOEXTEND ON NEXT 512K MAXSIZE UNLIMITED;

SQL>CREATE TABLESPACE ventas

SIZE 5M AUTOEXTEND ON NEXT 256K MAXSIZE 15M;

24.-Tablespaces almacen, produccion y ventas creadas con SQLPlus

Una vez creados los tablespaces anteriores, el usuario administrador crea

El primer usuario lo crea con Enterprise Manager y el resto con SQLPLus.

25.-Crear usuario: crear.

Notar que el sistema le asigna el rol connect

26.-Crear usuario en Enterprise Manager

Como el usuario i_emp1 va a ser administrador de la base de datos, se le

27.-Rol DBA asignado a i_emp1

28.-Usuario i_emp1 creado correctamente

Aquí se puede plantear una primera cuestión, ¿dispondrá el usuario

La respuesta es que no, ya que dicho usuario no ha creado todavía

29.-Notar cómo usuario i_emp1 aparece en Seguridad-Usuarios, pero no tiene un Esquema

Inicialmente cada departamento cuenta con una tabla al que deberán

El usuario DBA, i_emp1 crea ahora las tablas (las realizamos

CREATE TABLE infgeneral (

) TABLESPACE users; // Si no indicásemos esto, lo crearía en el

CREATE TABLE informdata (

) ; //  No ponemos nada porque lo creará en su tablespace por

CREATE TABLE almacendata (