Está en la página 1de 60

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

2.-Ventana de Bienvenida del Asistente

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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

13.-Crear Base de Datos


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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

15.-Creando Base de Datos


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de 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.
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

Doble click para definir parámetros


de almacenamiento.

19.-Crear tablespace:nombre

20.-Crear tablespace: tamaño inicial


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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’

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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.


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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.
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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)
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

) 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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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;


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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;


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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;
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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;


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

38.-Empleados de almacén y revoke y posterior grant to public

Usuarios del departamento de producción

Recordemos requisitos especificados:

• 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.
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

• El director, p_emp1, debe poder asignar el permiso de consultar,


modificar e insertar en la tabla de departamento prodccdata a
los posibles futuros trabajadores.

SQL> CREATE USER p_emp1IDENTIFIED BY p_emp1

DEFAULT TABLESPACE produccion

QUOTA UNLIMITED ON produccion;

SQL> CREATE USER p_emp2 IDENTIFIED BY p_emp2

DEFAULT TABLESPACE produccion

QUOTA UNLIMITED ON produccion;

SQL>CREATE USER p_emp3 IDENTIFIED BY p_emp3

DEFAULT TABLESPACE produccion

QUOTA UNLIMITED ON produccion;

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;


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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

Recordemos requisitos especificados:

• 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.
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

• El director, v_emp1, debe poder asignar el permiso de consultar,


modificar e insertar en la tabla de departamento ventasdata a
los posibles futuros trabajadores.

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”.
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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:


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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.
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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.
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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.
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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.
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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;


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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;

SQL> ALTER USER i_emp2 PROFILE empinform;

SQL> ALTER USER i_emp3 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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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’

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

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;


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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.
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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;


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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.


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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.
Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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.


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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;

SQL> DROP USER p_emp2 CASCADE;

SQL> DROP USER p_emp3 CASCADE;

90.-Borrando usuarios de producción


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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;


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

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;


Francisco Manuel Alcaide Perpiñán, ASIR 3 Nocturno. Administración de Base de Datos

94.-Tablespace produccion borrado.

Y tampoco aparece el fichero prodccn01.ora:

95.-Fichero prodccn01.ora ya no existe.