Tecnología de Bases
de Datos
Práctica 1
El SGBD Oracle
Introducción al servidor Oracle y
sus herramientas
Profesores: Juan Carlos Casamayor, Laura Mota y Mª José Vicent
1
Práctica 1.
Objetivos:
 Conocer la estructura del servidor Oracle.
 Conocer las dos componentes de un servidor Oracle: la
instancia y el almacenamiento secundario.
 Conocer el concepto de conexión con el servidor Oracle y los
modos de conexión.
 Utilizar las herramientas Oracle: SQL*Plus y SQL Developer.
 Conocer la forma de arrancar y apagar el servidor Oracle.
2
2
Práctica 1.
Descripción del servidor Oracle
Servidor Oracle
SGA: Reserva de memoria
principal para uso del
servidor (temporal)
Ordenador con
software Oracle
Instancia
SGA
Procesos de fondo
Base de Datos
Oracle
Almacenamiento secundario
del servidor (permanente)
El identificador del servidor Oracle que se va a utilizar en las prácticas es prueba
3
En un ordenador que va a desempeñar las funciones de servidor de bases de datos y en el que se
encuentra instalado el software de Oracle, se podrá poner en funcionamiento este servidor. Una
vez hecha esta puesta en funcionamiento en el ordenador se encontrarán dos componentes
asociadas al servidor Oracle, la instancia y la base de datos Oracle que explicaré más adelante.
En un ordenador que va a hacer de servidor Oracle es posible poner en marcha más de un
servidor, sin embargo, esto no es común. Habitualmente en un ordenador que va a realizar la
función de servidor de bases de datos, se pone en marcha un servidor Oracle con los recursos
suficientes para poder dar servicio al conjunto de usuarios que así lo requieran.
3
Práctica 1.
Instancia Oracle
Instancia
SGA
Área compartida
Buffers datos
Buffer diario
Procesos de fondo
DBWR
LGWR
CKPT
SMON
PMON
ARC
Instancia Oracle: SGA (System Global Area) + Procesos de fondo
 Es el medio para acceder al almacenamiento secundario (Base de Datos
Oracle) del servidor.
 System Global Area (SGA): reserva en memoria principal, contiene bloques
de disco (transferidos) e información de control para uso del servidor.
 Procesos de fondo: realizan tareas del servidor.
4
La primera de las componentes de un servidor Oracle es la instancia que está compuesta por:
• SGA (Systema Global Area): área de memoria principal de uso exclusivo para el servidor
Oracle, y en la que se pueden distinguir tres componentes (Cache de buffers de base de
datos, buffer de diario y área compartida) con diferentes usos que después veremos. La SGA
es muy grande, centenares de megas o incluso gigas y es la componente que permite acceder
a la información almacenada en disco.
• Procesos de fondo: estos procesos realizan tareas comunes del servidor sin dar un servicio
específico a las solicitudes de los usuarios.
4
Práctica 1.
SGA: System Global Area
SGA
Área compartida
Buffers datos
Buffer diario
System Global Area (SGA): reservada en memoria principal, contiene datos e
información de control para uso del servidor. Consta de tres partes:
 Cache de Buffers de Base de Datos.
 Buffer de Diario.
 Área Compartida.
5
5
Práctica 1.
SGA: Área compartida
SGA
Área compartida
Buffers datos
Área
compartida
Buffer diario
Cache de
biblioteca
Cache de
diccionario
de datos
Área compartida:
 Cache de biblioteca: contiene el texto de las últimas instrucciones SQL, el
código del análisis, y un plan para su ejecución.
 Cache del diccionario de datos: contiene la definición de las tablas
recientemente accedidas y los privilegios de los usuarios conectados.
6
El área compartida permite optimizar el funcionamiento del servidor.
6
Práctica 1.
SGA: Cache de buffers de base de datos
SGA
Área compartida
Buffers datos
Buffer diario
Buffer de datos:
 Almacena los bloques de datos y de índices que han sido accedidos más
recientemente para agilizar el acceso.
 Sirve para minimizar los accesos a la memoria secundaria.
 Puede ser muy grande.
7
7
Práctica 1.
SGA: Buffer de diario
SGA
Área compartida
Buffers datos
Buffer diario
Buffer de diario:
 Almacena los cambios realizados por las transacciones sobre la BD con
fines de recuperación.
 Se utiliza secuencialmente.
 Buffer circular (se reescribe).
 Pequeño.
8
Mucho más pequeño que la zona de buffers de datos, varias decenas de megas.
8
Práctica 1.
Procesos de fondo
Instancia
SGA
Procesos de fondo
DBWR
LGWR
CKPT
SMON
PMON
ARC
Procesos de fondo: realizan las tareas generales del servidor, no están
dedicados a ninguna conexión de usuario.
 DBWR: escritor de base de datos
 LGWR escritor de diario
 CKPT: proceso de puntos de control
 SMON: monitor del sistema
 PMON: monitor de procesos
 ARC: archivador
 …
9
DBWR: transfiere los buffers de base de datos que han sido modificados y los reescribe en el
disco.
LGWR: transfiere las entradas del diario y las escribe en el fichero de diario en disco.
CKPT: realiza las tareas asociadas a la ejecución de un punto de control.
SMON: supervisor del sistema que se encarga de todas las recuperaciones que sean necesarias
durante el arranque.
PMON: monitor de procesos que libera los recursos de una transacción cuando ésta falla
ARC: relacionado con guardar el diario en disco.
9
Práctica 1.
Almacenamiento secundario de Oracle
Ficheros de
control
Fichero de
parámetros
Fichero de
palabra de
paso
Ficheros de
diario
archivados
Ficheros de
datos
Ficheros de
diario
Base de datos Oracle
10
El almacenamiento secundario de Oracle está compuesto por una serie de ficheros que caen
bajo la denominación de base de datos Oracle. Además, hay otro conjunto de ficheros de un uso
menos relevante como son el fichero de parámetros, el fichero de palabra de paso y los ficheros
diarios archivados.
Hay que destacar que Oracle usa una terminología propia, no hay que confundir el término base
de datos de Oracle con el que comúnmente se usa en campo de las bases de datos.
10
Práctica 1.
Almacenamiento secundario de Oracle
Datos sobre el estado del
servidor y estructura física
del almacenamiento
secundario
Ficheros de
control
Fichero de
parámetros
Fichero de
palabra de
paso
Ficheros de
diario
archivados
Ficheros de
datos
Ficheros de
diario
Base de datos Oracle
Objetos de base de datos (tablas, índices,
disparadores, …) de todos los usuarios
de la BD Oracle
Información sobre las
transacciones ejecutadas para
tareas de recuperación
11
Los ficheros que componen la base de datos Oracle son:
• Ficheros de control: si hay varios (es lo recomendado) son todos réplicas. En ellos están
registrados datos sobre el estado del servidor y sobre la estructura física del almacenamiento
secundario.
• Ficheros de datos: constituyen el espacio donde se almacenan todos los datos de los objetos
de los usuarios (tablas, índices, etc.). Existen algunos ficheros de datos especiales que el
servidor usa para la realización de sus tareas, como el espacio de deshacer (control de
concurrencia y recuperación) y el espacio temporal (realización de paginado virtual para
ordenaciones).
• Ficheros de diario: son los ficheros donde se registra toda la información de las operaciones
de actualización en las transacciones de usuarios, para realizar la recuperación, si fuese
necesario.
11
Práctica 1.
Almacenamiento secundario de Oracle
Definición de la
Instancia
Ficheros de
control
Fichero de
parámetros
Fichero de
palabra de
paso
Ficheros de
diario
archivados
Ficheros de
datos
Ficheros de
diario
Base de datos Oracle
Ficheros de diario
históricos
Usuarios con autorización
para arrancar el servidor
12
Fuera de la base de datos Oracle hay otros ficheros de interés:
• Fichero de parámetros: en este fichero se les da valor a los parámetros que configuran el
servidor Oracle. Hay parámetros para todas las componentes del servidor y para definir el
funcionamiento de multitud aspectos (existen más de 1000 parámetros, todos ellos con un
valor por defecto de forma que sólo es necesario establecer los que se deseen).
• Fichero de palabra de paso: en este fichero se registra la acreditación de aquellos usuarios
que necesiten realizar una administración remota con privilegio de conexión SYSDBA.
• Ficheros de diario archivados: corresponden a los ficheros de diario que un proceso de
fondo, el archivador, va guardando en una ubicación diferente para salvaguardarlos.
Fichero de parámetros en:
/opt/oracle/admin/prueba/scripts/initpruebaTemp.ora
12
Práctica 1.
Base de datos e instancia Oracle
Servidor Oracle
BD
Parar el servidor
Oracle
Arrancar el servidor
Oracle
Servidor Oracle
Instancia
Ordenador con
software Oracle
El servidor no se
puede utilizar
El servidor ya se
puede utilizar
BD
13
En un ordenador que realiza las tareas de servidor Oracle, hasta que no se haya arrancado la
instancia, y por tanto realizado la reserva de memoria correspondiente a la SGA y puesto en
marcha los procesos de fondo, el servidor de base de datos no es operativo y, por tanto, la
información almacenada en las estructuras físicas de la base de datos Oracle no es accesibles.
La única forma de acceder a la información almacenada en la base de datos Oracle es
arrancando la instancia asociada a esa base de datos.
13
Práctica 1.
Conexión con el servidor Oracle
Instancia
Servidor Oracle
BD
Usuarios predefinidos en el servidor Oracle:
sys (oracle)
system (oracle)
…
Conexión
cliente‐servidor
SQL*Plus
SQL Developer
Herramientas
Oracle
Usuario Linux:
oracle (TBD.2021)
Acceso a la máquina virtual: portal‐ng.dsic.cloud
Usuario: <usuario_DSIC> (<contraseña_DSIC>)
Máquina virtual (Linux): Escritorio remoto: TBD‐xxx‐v2
TBD‐xxx‐v2
Vídeo: 1.- Acceso y arranque de la máquina virtual
Vídeo: 2.- Conexión a la máquina virtual
14
14
Práctica 1.
Proceso Listener
El proceso listener es un proceso de Oracle que se ejecuta en el
ordenador donde está instalado el servidor Oracle, y tiene como
función atender las peticiones de conexión al servidor por la red.
1. Poner en marcha el proceso listener (desde una terminal Linux):
$ lsnrctl start
2. Parar el proceso listener (desde una terminal Linux):
$ lsnrctl stop
/home/oracle/app/oracle/product/12.1.0/dbhome_1/network/admin
15
El proceso listener es un proceso de Oracle, tipo demonio, que se ejecuta en el ordenador donde
está instalado el servidor Oracle, y tiene como función atender las peticiones de conexión al
servidor por la red.
La configuración de este proceso se encuentra en el fichero listener.ora que se encuentra en un
directorio de instalación del servidor.
Listener es un proceso servidor que provee la conectividad de red con la base de datos Oracle. El
listener está configurado para escuchar la conexión en un puerto específico en el servidor de
base de datos. Cuando se pide una conexión a la base de datos, el listener devuelve la
información relativa a la conexión. La información de una conexión para una instancia de una
base de datos provee el nombre de usuario, la contraseña y el SID de la base de datos. Si estos
datos no son correctos se devolverá un mensaje de error.
Sin este proceso no se puede establecer la conexión al servidor.
15
Práctica 1.
Conexión a un servidor Oracle: sesión
Servidor
Cliente
Proceso
Servidor
3
2
SQL* Plus
Proceso
Usuario
1
listener
Servidor
Oracle
connect hr/pp_hr@prueba
tnsnames.ora
listener.ora
Servicio prueba: parámetros de conexión al servidor Oracle.
(fichero de servicios en el ordenador cliente: tnsnames.ora)
16
Las fases para establecer una conexión entre un programa cliente y un servidor Oracle son las
siguientes una vez el listener está arrancado:
(1) Petición de conexión: desde un ordenador cliente se realiza una petición de conexión usando
alguna herramienta cliente. En la transparencia esta herramienta cliente es el SQL*Plus. En la
petición el usuario proporciona una cadena de conexión en la que se incluye el nombre de un
servicio (prueba). Este servicio está definido localmente en un fichero de servicios
(tnsnames.ora) que le permite saber al proceso usuario los datos de la conexión: ordenador
servidor, puerto de escucha en el ordenador servidor del listener de Oracle y el SID del servidor
al que nos queremos conectar. En la cadena aparece además el nombre del usuario de la
conexión y su contraseña.
Resolución de la petición de conexión: el proceso usuario del ordenador cliente se pone en
contacto por la red con el proceso listener del ordenador servidor, proporcionándole los datos
de la conexión. El listener comprueba la petición de conexión y la acreditación del usuario.
(2) Puesta en marcha de un proceso servidor: si todo es correcto, el listener pone en marcha un
proceso servidor en el ordenador servidor y le deriva la conexión del proceso usuario.
(3) Mantenimiento de la conexión: a partir de ese momento el proceso usuario y el proceso
servidor mantienen la conexión.
16
Práctica 1.
Proceso usuario – Proceso servidor
 Proceso usuario:
 Se ejecuta en el ordenador cliente.
 Se lanza cuando una herramienta o una aplicación se ejecuta en el
ordenador cliente.
 Genera llamadas al servidor Oracle.
 Proceso servidor:
 Se ejecuta en el ordenador servidor.
 Sirve a un único proceso usuario.
 Utiliza un área exclusiva de memoria (PGA) para funciones de:
ordenación, información de la sesión, …
 Procesa las llamadas generadas por el proceso usuario.
 Devuelve los resultados al proceso usuario.
17
17
Práctica 1.
Conexión con el servidor Oracle: modos
Conexión en modo NORMAL:
 Para realizar tareas de usuario final o tareas administrativas que no
afectan al servidor.
Conexión en modo SYSDBA:
 Para realizar tareas administrativas que afectan al servidor:
• Arrancar.
• Parar.
• Realizar copias de seguridad completas.
• Realizar restauraciones de la base de datos completas.
18
Se haga desde donde se haga la conexión, existen dos modos de conexión con el servidor Oracle:
• En modo normal: es una conexión para realizar tareas de usuario final (manejar la
información de sus objetos o manipular sus objetos) o tareas administrativas que no afectan
de forma sustancial al servidor como un todo (crear o alterar usuarios, modificar el
almacenamiento secundario, alterar la configuración de algún recurso del servidor, etc.).
• En modo SYSDBA: es una conexión para realizar tareas administrativas que afectan de forma
sustancial al servidor (arrancar, parar, realizar copias de seguridad completas de la base de
datos, restaurar completamente la base de datos, etc.).
18
Práctica 1.
Conexión con el servidor Oracle: usuarios
Usuarios predefinidos:
 Administradores:
• sys:
 Administrador con privilegio de conexión en modo SYSDBA.
 Puede realizar todas las tareas administrativas.
• system:
 Administrador sin privilegio de conexión en modo SYSDBA.
 Puede realizar tareas administrativas que no exijan el modo
SYSDBA.
 Otros usuarios.
Contraseña para sys y system: oracle
19
Cuando se instala el software del servidor Oracle y se crea una base de datos Oracle, siempre se
crean un conjunto de usuarios predefinidos. Entre ellos cabe distinguir:
• Usuario sys: es el administrador con más privilegios (puede hacer cualquier operación sobre
el servidor). Siempre se debe conectar en modo SYSDBA.
• Usuario system: puede tareas administrativas que no exijan el modo de conexión SYSDBA, ya
que no tiene este privilegio de modo de conexión. Estas tareas son casi todas excepto algunas
que tienen un impacto global sobre el servidor (apagar o arrancar el servidor, realizar una
copia de seguridad completa de la base de datos o una restauración completa de la base de
datos, etc.).
Además de estos dos usuarios, pueden crearse otros muchos dependiendo del software que se
instale en el ordenador que va a realizar las tareas de servidor.
19
Práctica 1.
Herramientas Oracle
 SQL*Plus:
 Herramienta de línea de comandos para la administración y uso de un
servidor Oracle.
 Exige el conocimiento del lenguaje.
 Muy básica.
 Incomoda.
 Siempre funciona.
 SQL Developer:
 Herramienta gráfica para la administración y uso de un servidor Oracle.
 Muy cómoda.
 Muchas funcionalidades y modos de uso.
 Necesita el entorno gráfico.
20
Las herramientas Oracle que utilizaremos son:
• SQL*Plus:
• Herramienta en modo línea de comando con la que se pueden realizar tareas
administrativas o acciones de usuario final contra un servidor Oracle.
• Es muy básica y un podo rudimentaria. Exige un conocimiento preciso del lenguaje.
• La ventaja es que funciona en cualquier contexto, usando cualquier soporte de
conexión y no necesita soporte gráfico.
• SQL Developer:
• Es una herramienta gráfica con la que se pueden realizar tanto tareas administrativas
como trabajos de usuario final.
• Es muy cómoda y moderna. Tiene muchas funcionalidades y es muy versátil.
• Necesita que el entorno gráfico del ordenador en el que se ejecute este activado y es
un poco pesada (está desarrollada en Java)
• Es de instalación autónoma y sirve tanto para realizar conexiones locales como
remotas.
20
Práctica 1.
Herramienta SQL*Plus
 Ejecutar la herramienta (desde terminal LINUX):
$ sqlplus /nolog
(sin conexión)
 Conectarse al servidor Oracle
SQL> connect usuario/contraseña [@servicio]
[AS {NORMAL|SYSDBA}]
 Ejecutar la herramienta + Conectarse al servidor Oracle
$ sqlplus usuario/contraseña [@servicio]
[AS {NORMAL|SYSDBA}]
Ejemplos:
SQL> connect system/oracle
SQL> connect sys/oracle as sysdba
Parámetros de conexión: definidos en el servicio o valores por defecto
(variables del sistema)
21
Para poner en marcha el SQL*Plus tenemos que ejecutar en una terminal de Linux el comando:
sqlplus usuario/contraseña[@servicio] [as {normal|sysdba}]
Toda la cadena detrás del comando sqlplus es la “cadena de conexión”. La parte del servicio está
relacionado con las conexiones remotas que no veremos en esta asignatura. Ejemplos de
cadenas de conexión:
• system/oracle: al ponerse en marcha el SQL*Plus se intentará establecer una conexión con el
usuario Oracle system y le estamos indicando que la contraseña de este usuario es oracle,
para que el servidor haga la verificación.
• /nolog: es una cadena de conexión especial que le indica a la herramienta SQL*Plus que no
realice el intento de establecer conexión en su puesta en marcha. Más adelante, una vez
lanzada la herramienta, tendremos que conectarnos al servidor, mediante la ejecución de la
instrucción correspondiente.
• sys/oracle as sysdba: lo mismo que en el primer ejemplo, sólo que ahora al poner en marcha
el SQL*Plus se intentará establecer una conexión con el usuario sys. Como este usuario
siempre se ha de conectar en modo SYSDBA, se usa ese modo de conexión.
21
Práctica 1.
Arrancar el servidor Oracle en SQL*Plus
1. Poner en marcha el proceso listener:
$ lsnrctl start
2. Ejecutar la herramienta SQL*Plus
$ sqlplus /nolog
3. Arrancar el servidor Oracle:

Conectarse con el usuario sys en modo SYSDBA
SQL> connect sys/oracle as sysdba

Arrancar el servidor
SQL> startup
Vídeo: 3.- Arrancar y parar el Oracle
22
22
Práctica 1.
Parar el servidor Oracle en SQL*Plus
1. Parar el servidor Oracle:

Conectarse con el usuario sys en modo SYSDBA
SQL> connect sys/oracle as sysdba

Apagar el servidor
SQL> shutdown
2. Cerrar la herramienta SQL*Plus
SQL> exit
3. Parar el proceso listener :
$ lsnrctl stop
Video: 3.- Arrancar y parar el Oracle
23
Modos de parada del servidor:
• Normal: la parada se espera a que no haya sesiones abiertas.
• Transactional: la parada se espera a que no haya transacciones activas.
• Immediate: se fuerza un punto de control, y se cierran todos los ficheros.
• Abort: se apaga el servidor sin miramientos.
23
Práctica 1.
Herramienta SQL Developer
 Ejecutar la herramienta (desde terminal LINUX):
$ sqldeveloper
 Tipos de uso de la herramienta (ventanas):
 Navegación de esquemas de usuario: Ventana de navegación de
esquemas.
 Administración del servidor Oracle: Ventana de administración.
 Ejecución de instrucciones (SQL, SQL*Plus y PL/SQL): Ventana de
Trabajo de SQL.
Vídeo: 4.- Arrancar el SQL Developer. Creación de conexiones
24
La herramienta SQL Developer tiene diferentes tipos de usos, de los que se pueden destacar
tres:
• Navegación de esquemas: esta forma de uso está orientada a un usuario normal. Al
conectarse la herramienta presenta el esquema de objetos del usuario, catalogado por tipo
de objeto, permitiendo la navegación por él.
• Administración del servidor: este uso está orientado a administradores de la base de datos.
Permite operar sobre el servidor, alterar su configuración en sus diversas componentes y
realizar tareas que afectan globalmente sobre el servidor (en esta versión no se puede
arrancar y parar el servidor desde el SQL Developer).
• Ejecución de instrucciones: existe una hoja de trabajo que permite ejecutar instrucciones
SQL, SQL*Plus y bloques de programa PL/SQL. Con esta forma de uso se puede realizar
cualquier operación sobre el servidor, aunque se requiere un conocimiento del lenguaje.
24
Práctica 1.
SQL Developer: conexiones
Para trabajar con el sistema usando el SQL Developer hay que
utilizar conexiones.
 Conexión en SQL Developer: definición de un conjunto de
parámetros de conexión a un servidor Oracle.
Definición de conexiones: local a la herramienta SQL Developer
Video: 4.- Arrancar el SQL Developer. Creación de conexiones
25
Lo primero que se debe hace cuando se empieza a trabajar con el SQL Developer es crear una
conexión. Una conexión del SQL Developer es una denominación a la información que determina
el servidor Oracle con el que se quiere conectar. La forma de crear una conexión de este tipo es
elegir en el menú Ver la opción Conexiones.
Al crear una conexión aparece una ventana en la que hay que especificar los siguientes datos:
• Nombre de conexión: es un identificador para la conexión que se está creando.
• Usuario: si se especifica, esta conexión sólo podrá ser utilizada por ese usuario para
establecer la conexión con el servidor Oracle.
• Contraseña: si se especifica y se guarda, al usar esta conexión del SQL Developer, no se
pedirá el usuario y la contraseña establecida para la acreditación al conectarse con el servidor
Oracle.
• Tipo de conexión: es la forma de establecer la conexión con el servidor. Hay que dejar el
valor Básico.
• Rol: define el modo de conexión, valor por defecto corresponde a un modo de conexión
normal, y SYSDBA a un modo de conexión SYSDBA.
• Nombre del host: es el ordenador que hace de servidor Oracle. Hay que indicar el nombre
completo o la IP de este ordenador.
• Puerto: es el puerto en el ordenador que hace de servidor Oracle donde se encuentra
escuchando el listener.
• SID (System Identification): es el identificador que distingue a la instancia Oracle que se está
ejecutando en el ordenador que hace de servidor Oracle.
25
Práctica 1.
SQL Developer: Navegación de esquemas
26
Al conectarse en modo normal, la navegación de esquemas es la forma de trabajo por defecto.
En esta forma de trabajo, en la ventana Conexiones del menú Ver se despliega la taxonomía de
objetos de la base de datos Oracle (tablas, índices, vistas, disparadores, …) de forma que se
puede ir navegando por todos ellos y seleccionar alguno de algún tipo para realizar operaciones
sobre él. Las acciones que se pueden realizar sobre cada objeto dependen del tipo de objeto que
tenga.
26
Práctica 1.
SQL Developer: Administración
Para administrar el sistema usando el SQL Developer hay que
utilizar conexiones de tipo DBA.
 Conexión DBA: es una conexión de las ya creadas que se
incluye en la lista de conexiones DBA (Opción DBA del
menú Ver) .
Ventana
conexiones
DBA
Permite:
• Crear una nueva conexión e incluirla
en DBA o
• Elegir una existente e incluirla en DBA
27
Al elegir esta opción, se puede crear una conexión para trabajar en modo DBA. Para ello hay que
elegir una de las conexiones SQL Developer ya creadas que permita el modo de conexión
SYSDBA con el servidor Oracle (o crearla en ese momento si no existe ninguna).
Para administrar el servidor desde el SQL Developer, es necesario tener creada al menos una
conexión de este tipo.
Lo que se podrá administrar en este modo dependerá de los privilegios del usuario que se
conecte.
27
Práctica 1.
SQL Developer: Administración
28
Si se está conectado en modo administrativo, el SQL Developer proporciona una visión del
servidor Oracle, permitiendo observar sus componentes agrupadas en varias categorías de las
que vamos a estudiar:
• Almacenamiento: da acceso a todos los elementos que requieren almacenamiento
secundario, ficheros diarios archivados, ficheros de control, ficheros de datos, ficheros de
diario (grupos de Redo Logs), Segmentos de Rollback, Tablespaces y Grupos de Tablespaces
Temporales.
• Configuración de la Base de Datos: en esta sección se pueden consultar y editar los
parámetros de configuración del servidor.
• Seguridad: aquí se pueden administrar todos los aspectos de seguridad del servidor Oracle,
usuarios, roles y perfiles.
28
Práctica 1.
SQL Developer: hoja de trabajo SQL
29
El último tipo de uso posible en el SQL Developer es la ejecución de instrucciones. Este uso se
realiza mediante la herramienta Hoja de Trabajo de SQL, que se encuentra en el menú
Herramientas. Esta herramienta permite ejecutar instrucciones SQL, SQL*Plus y bloques de
programa PL/SQL.
Al elegir esta opción en el menú Herramientas se requerirá que se indique cuál va a ser la
conexión del SQL Developer mediante la cual se solicita la ejecución de las instrucciones editadas
en la hoja de trabajo. Hay que elegir una entre la que haya creadas o se podrá crear una nueva si
es el caso.
En la transparencia se muestran los tres modos de trabajo del SQL Developer:
• Ventana Conexiones: modo de navegación de esquemas.
• Ventana DBA: modo de administración del sistema.
• Ventana Hoja de trabajo de SQL: ejecución de instrucciones.
29
Tecnología de Bases
de Datos
Práctica 2
Procesamiento de transacciones y
mantenimiento de la integridad en
Oracle
Profesores: Laura Mota y Mª José Vicent
Curso: 2020‐2021
Práctica 2.
Objetivos:
 Conocer la sintaxis para la definición de transacciones en
Oracle.
 Comprobar experimentalmente el funcionamiento de las
instrucciones COMMIT y ROLLBACK.
 Comprobar experimentalmente los modos de comprobación
de la integridad en Oracle.
 Tabajar con restricciones diferibles.
2
Práctica 2.
Definición de transacciones en Oracle
Operaciones de usuario:
 INICIO: inicio implícito.
En Oracle una transacción se inicia implícitamente cuando se ejecuta la
primera instrucción SQL (DML) desde que finalizó la última transacción o
desde que se realizó la conexión al servidor.
 FIN (con confirmación): COMMIT [WORK]
(o FIN implícito)
(transacción confirmada parcialmente)
En Oracle una transacción finaliza implícitamente (con confirmación
parcial) cuando el usuario se desconecta del servidor.
 FIN (con anulación): ROLLBACK [WORK]
(transacción anulada)
Nota: la sintaxis para la definición de transacciones en Oracle coincide
con la del SQL estándar excepto para la instrucción SQL de inicio de
una transacción (START TRANSACTION) que no existe en Oracle.
3
Práctica 2.
Definición de transacciones en Oracle
Operaciones de usuario:
 En Oracle se pueden definir puntos de SAVEPOINT para anular
parcialmente una transacción (SQL estándar):
SAVEPOINT nombre_savepoint
ROLLBACK TO nombre_savepoint
4
Práctica 2.
Definición de transacciones en Oracle
Operaciones de usuario:
INICIO IMPLÍCITO
…
…
SAVEPOINT marca1
…
…
SAVEPOINT marca2
…
…
IF … THEN ROLLBACK TO SAVEPOINT marca2
…
…
IF … THEN ROLLBACK TO SAVEPOINT marca1
…
COMMIT
5
Práctica 2.
Comprobación de R.I. en Oracle
Modos de comprobación de la integridad (se define para cada
restricción del esquema):
 Modo inmediato: la restricción se comprueba tras cada
operación SQL que pueda violar la restricción.
 Modo diferido: la restricción se comprueba al final de cada
transacción que contenga una instrucción que pueda violar la
restricción.
El modo de comprobación de una restricción puede ser fijo
(restricción no diferible) o se puede cambiar dinámicamente
durante la ejecución de una transacción (restricción diferible).
6
Práctica 2.
Comprobación de R.I. en Oracle
Acción del SGBD frente a la violación de una RI:
 Modo inmediato: el SGBD rechaza la instrucción SQL que
provoca la violación y la transacción continúa.
 Modo diferido: el SGBD anula la transacción.
7
Práctica 2.
Comprobación de R.I. en Oracle
Propiedad del cambio: diferible/no diferible
[[NOT] DEFERRABLE] [INITIALLY {IMMEDIATE|DEFERRED}]
Inmediato
Diferido
Modo
8
Práctica 2.
Comprobación de R.I. en Oracle
La instrucción SQL que permite cambiar, localmente en una
transacción, el modo de una restricción definida como diferible
(DEFERRABLE), es:
SET CONSTRAINT {RI1, RI2, ... | ALL}
{IMMEDIATE
| DEFERRED}
9
Tecnología de Bases
de Datos
Práctica 3
Recuperación de bases de datos
en Oracle
Profesores: Laura Mota y Mª José Vicent
Curso: 2020‐2021
1
Práctica 3.
Objetivos:
 Estudiar la estrategia de actualización de la base de datos que
se sigue en Oracle.
 Estudiar los elementos que intervienen en la estrategia de
recuperación de la base de datos en Oracle.
 Comprobar experimentalmente la estrategia de recuperación
en Oracle.
2
2
Práctica 3.
Estrategia de actualización en Oracle
 Entorno concurrente.
 Actualización en el lugar.
 Actualización inmediata.
 Actualización no forzar.
Algoritmo
DESHACER/REHACER
3
3
Práctica 3.
Estrategia de recuperación en Oracle
Elementos utilizados en el procesamiento de transacciones y en la
estrategia de recuperación en el SGBD Oracle:
 Buffer de datos.
 Buffer de diario.
 Fichero de diario.
[escribir, T, X, valor_antes, valor_después]
 Espacio de deshacer.
4
Como se ha presentado en el Tema 3, en un diario se registran todas las operaciones que
realizan las transacciones, con fines de recuperación de la BD: deshacer una transacción anulada
o interrumpida, o rehacer una transacción confirmada.
Para poder deshacer o rehacer una actualización de una transacción es necesario guardar en el
diario el valor anterior y el valor posterior a dicha actualización, como se indica en la entrada de
tipo [escribir, T, X, valor_antes, valor_después]
La particularidad de Oracle reside en que estas dos informaciones (valores de X) se almacenan
en dos repositorios distintos:
• En un fichero de datos del servidor (Espacio de Deshacer) y
• En el fichero de diario del servidor.
Como se presentará en la Práctica 5, Oracle utiliza para gestionar el espacio disponible en disco
(los ficheros de datos) una organización particular. El espacio en disco destinado a datos se
organiza en espacios de distinto tamaño (tablespaces en la terminología de Oracle), gestionados
por el servidor. Uno de estos espacios se destina a almacenar las anotaciones con los valores
anteriores de los datos actualizados, para poder deshacer transacciones durante la recuperación
de la BD. Por este motivo se habla de Espacio de Deshacer (Undo Tablespace).
En el fichero de diario se almacenan las anotaciones con el valor posterior de los datos
actualizados para poder rehacer transacciones durante la recuperación de la BD.
En la transparencia se indica el destino final de estos dos valores del dato actualizado
(valor_antes y valor_después). En las transparencias siguientes se presentará con más detalle el
uso de estos dos repositorios.
4
Práctica 3.
Bloques
de datos
Estrategia de recuperación en Oracle
Bloques
de diario
Bloques de
deshacer
Instancia
Ficheros de
control
Área compartida
Buffers datos Buffer diario
Ficheros de
datos
DBWR
LGWR
CKPT
SMON
PMON
Memoria Principal
ARC
Ficheros de
diario
Base de datos Oracle
Memoria Secundaria
5
Como se ha visto en prácticas anteriores, en la SGA de la instancia, de un servidor Oracle, existen
dos tipos de buffers: el buffer de diario y el buffer de datos.
En el buffer de datos se trasfieren temporalmente los bloques de los ficheros de datos que son
accedidos durante el uso del servidor. Estos bloques pueden ser de dos tipos:
• Bloques de datos (bloques de objetos de datos), o
• Bloques del espacio de deshacer.
En el buffer de diario se trasfieren bloques del fichero de diario.
Los bloques transferidos a memoria principal serán devueltos (grabados) al disco en instantes de
tiempo determinados por la estrategia de actualización de la BD y los parámetros de
configuración del servidor.
5
Práctica 3.
6
Estrategia de recuperación en Oracle
Espacio de
deshacer
Fichero
de datos
Buffer de
datos
2
[escribir, T, X, valor_antes, valor_después ]
En la actualización de un elemento de datos (X):
 El valor_después se escribe en el objeto de datos
 El valor_antes se escribe en el espacio de deshacer
 Ambos modificaciones (escrituras) son registradas antes en el
fichero de diario con fines de recuperación.
Buffer de
diario
4
Objeto de
datos
3
1
Fichero
de diario
6
Debido a la forma particular, en Oracle, de almacenar la información relativa a una operación de
actualización, es importante entender el destino de cada información para la recuperación,
teniendo en cuenta que las actualizaciones realizadas en el espacio de deshacer (valor_antes)
reciben el mismo tratamiento, respecto a la política de recuperación, que las actualizaciones de
los objetos de datos, es decir, que el hecho de escribir en el espacio de deshacer implica hacer
una anotación en el fichero de diario. Así:
• El valor del dato antes de la actualización (valor_antes) se escribe en el correspondiente
bloque del espacio de deshacer residente temporalmente en el buffer de datos. Una
anotación con la inserción realizada en el espacio de deshacer (valor_antes) es también
registrada previamente en el buffer de diario. (En el espacio de deshacer sólo se hacen
inserciones).
• El valor del dato después de la actualización (valor_después) se escribe en el correspondiente
bloque del objeto de datos residente temporalmente en el buffer de datos. Una anotación
con el valor actualizado (valor_después) es registrada previamente en el buffer de diario.
Los bloques de datos y de deshacer en los que se han hecho actualizaciones, en el buffer de
datos, serán devueltos a su posición en el disco en algún momento posterior.
El contenido del buffer de diario será grabado en el fichero de diario en disco siguiendo una
política que asegura tener en disco toda la información necesaria para la recuperación de la base
de datos en caso de fallo. (Algoritmo de gestión del fichero de diario).
6
7
Estrategia de recuperación en Oracle
Fichero de
diario
Tabla
(fichero de datos)
actualización del elemento
de datos X
escribir [T, X, valor_antes]
X
Buffer de
datos
escribir[T, X, valor_antes]
Espacio de deshacer
(fichero de datos)
escribir[T, X, valor_después]
Práctica 3.
Buffer de
diario
4
2
1
3
escribir (X)
7
Esta transparencia visualiza más detalladamente lo que ya se ha descrito en la transparencia
anterior.
Es importante destacar:
• Cualquier bloque (datos, deshacer, diario) debe ser transferido al buffer correspondiente
para su actualización, y posteriormente debe ser salvado (grabado) en disco.
• Cualquier actualización que se hace en el espacio de deshacer o en los objetos de datos debe
ser anotada previamente en el fichero de diario.
• En el espacio de deshacer se registran los valores anteriores de los datos con fines de
recuperación (deshacer transacciones), pero estas inserciones en el espacio de deshacer son
anotadas también en el fichero de diario. Si se perdiese el contenido del espacio de deshacer
por algún fallo, éste podría ser reconstruido usando el diario.
El uso de un espacio de deshacer (valor_antes) en Oracle responde únicamente a razones de
rendimiento. Las mismas medidas de seguridad podrían tomarse usando exclusivamente un
fichero de diario clásico.
Con el uso del espacio de deshacer se pretende tener más accesible la información necesaria
para deshacer transacciones, ya que esta tarea se realiza con mucha más frecuencia (usuario,
SGBD) que la tarea de rehacer (fallo del sistema).
7
Práctica 3.
Estrategia de recuperación en Oracle
Buffers de datos (MP)
transacciones
t1
bloques de datos
UPDATE profesor
SET cod_dep=‘DISCA’
WHERE cod_pro=‘JCC’;
<JCC … DSIC>
8
Buffer de diario (MP)
bloques de deshacer
[escribir, T1 , X, <JCC … DSIC>]
bloques de diario
[leer, T1, X]
[escribir, T1 ,X, <JCC … DSIC>]
<JCC … DISCA>
[escribir, T1 , X, <JCC … DISCA>]
t2
commit
t4
confirmación
del SGBD
t5
UPDATE profesor
SET cod_dep=‘DISCA’
WHERE cod_pro=‘MCG’;
[commit, T1]
[leer, T2, Y]
<MCG … DSIC>
Escritura
anticipada
en el diario
t7
Bloques de
deshacer
Bloques de
datos
[escribir, T2 , Y, <MCG … DSIC>]
[escribir, T2 , Y, <MCG … DISCA>]
<MCG … DISCA>
…
fallo del
t10 sistema
[escribir, T2 , Y, <MCG … DSIC>]
BD
t6
Forzar
escritura en
t3 el diario
diario
Profesor
Ficheros
de diario
Espacio
para datos
Ficheros
de datos
Espacio de
deshacer
8
En la transparencia se ilustra con un ejemplo la situación en que puede quedar la base
de datos (en disco) después de un fallo del sistema con pérdida de memoria principal,
en el supuesto de la estrategia de actualización planteada.
8
Práctica 3.
tiempo
Estrategia de recuperación en Oracle
t1
t4 t5
t10
T1 (confirmada)
Rehacer
Reconstruir
(espacio de
deshacer)
T2 (interrumpida)
punto de control
Deshacer
fallo del sistema
Algoritmo DESHACER/REHACER
9
Éste es el proceso de recuperación de la base de datos del ejemplo anterior después del fallo.
Deberán deshacerse las actualizaciones de las transacción T2 y rehacerse las actualizaciones de
la transacción T1 que es la única confirmada después del último punto de control. Para deshacer
T2, primero reconstruirá el espacio de deshacer usando el diario.
9
Práctica 3.
Estrategia de recuperación en Oracle
Fallo del sistema con pérdida de MP: Algoritmo Deshacer/Rehacer
Forzar la escritura
en el diario
a)
En el fichero de diario en disco se encuentran los cambios realizados por
las transacciones confirmadas antes del fallo del sistema (las
transacciones que hicieron estos cambios pueden no haber sido grabados
en la BD en disco).
b) En el fichero de diario en disco se encuentran todos los cambios
realizados sobre bloques del espacio de deshacer correspondientes a
cambios en bloques de datos que ya han sido transferidos a disco (las
transacciones que hicieron estos cambios pueden haber sido
interrumpidas).
Escritura anticipada
en el diario
10
a) Debido al algoritmo de gestión del fichero de diario (forzar la escritura en el diario) antes de
confirmar una transacción, el SGBD transfiere a disco el contenido del buffer de diario, es
decir salva en el fichero de diario los cambios realizados por la transacción (valor_despues),
independientemente de que estos cambios hayan sido grabados o no en el disco. Esto
permite rehacer la transacción confirmada en caso de fallo del sistema.
b) Debido al algoritmo de gestión del fichero de diario (escritura anticipada en el diario), en el
fichero de diario se encuentran los cambios realizados en el espacio de deshacer que son
necesarios para deshacer las actualizaciones (valor_antes) de las transacciones
interrumpidas que ya hayan sido grabadas en disco.
10
Práctica 3.
Estrategia de recuperación en Oracle
Fallo del sistema con pérdida de MP: Algoritmo Deshacer/Rehacer
Estrategia de recuperación:
a) Se aplican sobre la BD los cambios registrados en el fichero de diario en
disco, desde el último punto de control: se rehacen las transacciones
confirmadas y se reconstruye el espacio de deshacer en disco. (REHACER)
b) Utilizando las entradas del espacio de deshacer en disco, se deshacen
todos los cambios producidos por transacciones interrumpidas por el fallo
del sistema.(DESHACER)
11
11
Práctica 3.
Estrategia de recuperación en Oracle
Espacio de
deshacer
Ficheros
de diario
BD
BD que necesita
recuperación
BD
REHACER
BD con cambios de
transacciones
confirmadas e
interrumpidas
Sincronización de la BD y el espacio
de deshacer en disco con el estado
del buffer de datos en el momento
del fallo.
BD
DESHACER
BD con datos de
transacciones
confirmadas
Anulación de cambios de
transacciones
interrumpidas.
12
Al aplicar el procedimiento REHACER:
• Rehacemos, con la información del fichero de diario (valor_después) las transacciones
confirmadas antes del fallo y posteriores al último punto de control. Algunos de los cambios
de estas transacciones podrían haberse quedado en el buffer de datos en el momento del
fallo.
• Rehacemos el espacio de deshacer en disco con la información del fichero de diario. Esto
asegura que en el espacio de deshacer en disco, después de la restauración, están registrados
los cambios (valor_antes) de las transacciones activas en el momento del fallo, realizados
sobre bloques de datos que ya han sido transferidos al disco. Otros cambios de estas
transacciones interrumpidas no registrados todavía en disco no interesan.
Al aplicar el procedimiento DESHACER:
• Deshacemos los cambios de las transacciones interrumpidas.
12
Práctica 3.
Estrategia de recuperación en Oracle
Buffer de datos:
 Almacena los bloques de datos y del espacio de deshacer que han sido
accedidos más recientemente.
 Sirve para minimizar los accesos a disco.
 El SGBD gestiona de la misma forma los bloques de datos y los bloques
del espacio de deshacer.
13
Como ya estudia en la práctica 1, el buffer de datos almacena temporalmente bloques de datos
y bloques del espacio de deshacer.
13
Práctica 3.
Estrategia de recuperación en Oracle
Instancia
Área compartida
Buffers datos
DBWR:
 Hace falta espacio en el
buffer de datos.
Buffer diario
 Antes de ejecutar un punto
de control.
DBWR
LGWR
CKPT
SMON
PMON
ARC
 Periódicamente.
Ficheros de
control
Ficheros de
datos
Ficheros de
diario
Base de datos Oracle
14
Los criterios para que el proceso de fondo DBWR (Database Writer) actúe y transfiera bloques
(datos, deshacer) del buffer de datos al disco, pueden ser varios:
• El servidor necesita espacio en el buffer de datos para atender las peticiones de las
transacciones: transferir nuevos bloques de datos y de deshacer al buffer de datos.
• Antes de marcar un punto de control en el fichero de diario, el servidor transfiere a disco el
contenido del buffer de diario y los bloques del buffer de datos (sucios).
• En la configuración del servidor se puede establecer una periodicidad para transferir bloques
(sucios) del buffer de datos a disco.
14
Práctica 3.
Estrategia de recuperación en Oracle
Buffer de diario:
 Almacena los cambios realizados por las transacciones sobre bloques
de datos y bloques del espacio de deshacer con fines de recuperación.
 Se utiliza secuencialmente.
 Buffer circular (se reescribe)
15
Como ya se estudia en la práctica 1, el buffer de diario almacena temporalmente bloques del
fichero de diario donde se anotan, entre otra información, las actualizaciones (valor_después)
realizadas sobre bloques de datos y bloques de deshacer.
15
Práctica 3.
Estrategia de recuperación en Oracle
Instancia
Área compartida
Buffers datos
LGWR:
 Confirmación de transacción.
Buffer diario
 1/3 del buffer de diario lleno.
 Antes de que escriba el DBWR.
DBWR
LGWR
CKPT
SMON
PMON
ARC
 Cada tres segundos.
Ficheros de
control
Ficheros de
datos
Ficheros de
diario
Base de datos Oracle
16
Los criterios para que el proceso de fondo LGWR (Log Writer) actúe y transfiera el contenido del
buffer de diario al disco, pueden ser varios:
• Antes de que el servidor confirme una transacción: algoritmo de gestión del diario (forzar
escritura en el diario).
• Cuando una porción del buffer de diario previamente establecida está llena (configuración).
• Antes de que el proceso DBWR transfiera bloques del buffer de datos a disco: algoritmo de
gestión del diario (escritura anticipada en el diario).
• Con cierta periodicidad previamente establecida (configuración).
16
Práctica 3.
Organización del diario en Oracle
Grupo 1
Grupo 2
Grupo 3
Miembro
Miembro
Miembro
Disco 1
Miembro
Miembro
Miembro
Disco 2
El servidor Oracle trabaja con varios grupos de ficheros de diario.
Cada grupo de diario es un conjunto de ficheros de diario similares (miembros).
17
Por razones de seguridad el servidor Oracle trabaja con varios grupos de diario.
Cada grupo de diario contiene un conjunto de ficheros de diario similares (miembros).
Por seguridad los miembros de un grupo de diario se suelen almacenar en discos distintos.
17
Práctica 3.
Organización del diario en Oracle
Grupo 1
Actual
Grupo 3
Miembro
Miembro
Miembro
Disco 1
Miembro
Miembro
Miembro
Disco 2
LGWR
•
•
•
Buffer diario
Existe un grupo actual que es el que está siendo utilizado por el servidor.
El servidor actualiza simultáneamente todos los miembros del grupo actual.
Cuando los ficheros del grupo actual están llenos, el servidor pasa al grupo
18
siguiente. (Uso circular del conjunto de grupos de diario).
El fichero de diario tendría todas sus entradas entre los miembros de los distintos grupo (uno
por grupo).
Un grupo puede estar en varios estados:
• Actual: es sobre el que está escribiendo el LGWR.
• Activo: es posible que sus entradas sean necesarias para realizar recuperación ante fallos.
• Inactivo: sus entradas no son necesarias para recuperarse ante un fallo de sistema (por
ejemplo porque se ha hecho un checkpoint).
18
Práctica 3.
Organización del diario en Oracle
Grupo 1
Grupo 2
Actual
Miembro
Miembro
Miembro
Disco 1
Miembro
Miembro
Miembro
Disco 2
ARCH
Ficheros de
diario archivados
Cuando un grupo de diario está completo puede ser archivado por razones de
seguridad. (Parámetro de configuración del servidor).
Los grupos se sobreescriben cuando están llenos. Antes de esto deberían estar en
estado inactivo y archivarse.
19
19
Práctica 3.
Organización del diario en Oracle
En el servidor prueba existen 3 grupos de diario, cada
uno de ellos con un fichero de diario.
El grupo #1 es el grupo de
diario actual en este momento
Gestión de grupos de diario
en SQL Developer
20
En la instalación del laboratorio los tres miembros de cada grupo del diario están en el mismo
disco (incluso en el mismo directorio). Esto no debería ser así para que la instalación fuera
robusta.
20
Tecnología de Bases
de Datos
Práctica 4
Control de la concurrencia en
Oracle
Profesores: Laura Mota y Mª José Vicent
1
Práctica 4.
Objetivos:
 Conocer la estrategia seguida en Oracle para el control de la
ejecución concurrente de transacciones.
 Conocer los niveles de aislamiento estándar que a nivel de
transacción pueden especificarse en Oracle.
 Comprobar experimentalmente la aplicación de esta
estrategia en distintas situaciones.
2
2
Práctica 4.
Niveles de aislamiento en SQL estándar:
SET TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED
 READ COMMITTED
 REPETEABLE READ
 SERIALIZABLE
}
 READ UNCOMMITTED: lectura no confirmada.
 READ COMMITTED: lectura confirmada.
 REPETEABLE READ: lectura repetible
 SERIALIZABLE: lectura serializable.
3
En el Tema 4, se estudia la propuesta que el SQL estándar hace relativa al control de la
concurrencia. El SQL propone que el protocolo, utilizado por el SGBD, permita trabajar con
distintos niveles de control de la concurrencia: niveles de aislamiento.
El nivel de aislamiento lo establece el usuario al inicio de la transacción, con la instrucción SQL:
SET TRANSACTION ISOLATION LEVEL
{READ UNCOMMITTED READ COMMITTED REPETEABLE
READ SERIALIZABLE }
(el alcance es la transacción)
O en la sesión de usuario, con la instrucción SQL:
ALTER SESSION SET ISOLATION LEVEL
{READ UNCOMMITTED READ COMMITTED REPETEABLE
READ SERIALIZABLE }
(el alcance es la sesión)
La elección del nivel de aislamiento debe estar en función del tipo de actividad que se vaya a
realizar.
SQL propone cuatro niveles de aislamiento que significan distintos grados de exigencia en el
control de la concurrencia.
3
Práctica 4.
Niveles de aislamiento en Oracle:
SET TRANSACTION ISOLATION LEVEL { READ COMMITTED
 SERIALIZABLE }
 READ COMMITTED: lectura de datos confirmados al inicio de
la instrucción SQL.
 SERIALIZABLE: lectura de datos confirmados al inicio de la
transacción.
 El valor por defecto cuando no se usa la instrucción es READ
COMMITED.
4
Oracle simplifica la propuesta de SQL, y elimina dos niveles de aislamiento.
El efecto es que en Oracle, el nivel mínimo de aislamiento en el que se puede trabajar es READ
COMMITED, es decir las transacciones siempre leen versiones de los datos ya confirmados en el
instante de la operación de lectura. Por otro lado, desaparece un nivel intermedio, REPETEABLE
READ, que queda incluido en el siguiente nivel, SERIALIZABLE, en el que las transacciones leen
versiones de los datos confirmados al inicio de la transacción.
4
Práctica 4.
Control del procesamiento de transacciones en SQL estándar:
Anomalía
Nivel de aislamiento
Lectura sucia
Lectura no
repetible
Lectura de
Pérdida de
fantasmas actualizaciones
READ UNCOMMITED
SÍ
SÍ
SÍ
SÍ
READ COMMITED
NO
SÍ
SÍ
SÍ
REPETIBLE READ
NO
NO
SÍ
SÍ
SERIALIZABLE
NO
NO
NO
NO
5
5
Práctica 4.
Control del procesamiento de transacciones en Oracle:
Anomalía
Lectura sucia
Lectura no
repetible
READ COMMITED
NO
SÍ
SÍ
SÍ
SERIALIZABLE
NO
NO
NO
NO
Nivel de aislamiento
Lectura de
Pérdida de
fantasmas actualizaciones
6
6
Práctica 4.
Control de la concurrencia en Oracle:
 El control de la concurrencia en Oracle se basa en tres recursos:
 Un protocolo de bloqueo de elementos de datos.
 Las versiones antiguas de los elementos de datos (anteriores
a una actualización), guardadas en el servidor con fines de
recuperación.
 Las marcas de tiempo (número secuencial del sistema): SCN
(System Change Number).
7
Estos tres recursos se explican a continuación.
7
Práctica 4.
Recurso 1 para control concurrencia en Oracle:
Protocolo de bloqueo de Oracle:
El sistema Oracle utiliza un protocolo de bloqueo en el que un
elemento de datos puede estar en dos estados: ‘bloqueado’,
‘desbloqueado’:
 Si bloqueo(X) = ‘bloqueado’, otras transacciones distintas a la
que provocó el bloqueo pueden leer el elemento de datos X, pero
ninguna otra transacción distinta a la que provocó el bloqueo
puede escribir el elemento X. Bloqueo exclusivo en escritura.
 Si bloqueo(X) = ‘desbloqueado’, cualquier transacción puede leer
o escribir el elemento de datos X.
8
En el Tema 4, se estudia la familia de protocolos de bloqueo de elementos de datos.
Se presentaron dos protocolos de bloqueo, el protocolo de bloqueo binario (impide el acceso
concurrente a un elemento de datos), y el protocolo de bloqueo B2F (permite un acceso
concurrente en lectura y un acceso exclusivo en escritura).
Los protocolos de bloqueo de elementos de datos se basan en la idea de restringir el acceso al
mismo elemento de datos por varias transacciones.
Bloqueo: estado de un elemento de datos con respecto a las operaciones que las transacciones
pueden realizar sobre él.
El protocolo de bloqueo propuesto por Oracle no coincide exactamente con ninguno de los
vistos en teoría.
8
Práctica 4.
Recurso 1 para control concurrencia en Oracle:
Protocolo de bloqueo de Oracle:
 Los bloqueos son implícitos(1):
 El estado de bloqueo lo provoca una operación de escritura
SQL.
 El desbloqueo de un elemento de datos se produce cuando
finaliza la transacción que lo tenía bloqueado (con
confirmación o con anulación).
La granularidad (por defecto) del bloqueo es a nivel de fila(2).
(1) El usuario puede definir bloqueos manuales (explícitos).
(2) La granularidad puede ser también a nivel de tabla.
9
En Oracle, como en otros SGBD, el bloqueo y el desbloqueo son implícitos, es decir no existen
operaciones específicas para bloquear y desbloquear elementos de datos. El estado de bloqueo
de un elemento de datos lo provoca una operación de escritura sobre el elemento. El
desbloqueo de los elementos de datos, bloqueados durante una transacción, se produce cuando
la transacción termina.
Existen bloqueos explícitos (SELECT … FOR UPDATE) que permiten bloquear conjuntos de filas,
para realizar ciertas operaciones. Este tipo de bloqueos no serán estudiados en esta práctica.
En Oracle, como en otros SGBD, el bloqueo es a nivel de fila.
En algunas ocasiones el bloqueo se produce a nivel de tabla, esto sucede cuando concurren una
operación de DML (actualización) y una operación de DDL (definición de datos (CREATE)). Este
tipo de bloqueos tampoco serán estudiados en esta práctica.
9
Práctica 4.
Recurso 1 para control concurrencia en Oracle:
Protocolo de bloqueo de Oracle:
 Conclusiones:
 Una operación de lectura siempre se satisface. Los lectores
nunca esperan (aunque esté bloqueado).
 Sólo una transacción activa puede actualizar un elemento de
datos (bloqueo exclusivo en escritura).
10
De acuerdo con la definición del protocolo de bloqueo que se sigue en Oracle, se puede concluir
que las operaciones de lectura de las transacciones siempre se satisfacen, y que sólo una
transacción puede acceder a un elemento de datos para actualizarlo.
Observad que este protocolo no coincide con el protocolo B2F estudiado en el Tema 4, el
protocolo B2F es más estricto.
Observad que no coincide tampoco con el Protocolo Multiversión (Tema 4), ya que, aunque
siempre se permite la lectura de un elemento de datos, no se permite que varias transacciones
actualicen un elemento de datos a la vez.
10
Práctica 4.
Recurso 1 para control concurrencia en Oracle:
Protocolo de bloqueo de Oracle:
 Bloqueo mortal en Oracle: el SGBD detecta la situación de
bloqueo mortal y la resuelve rechazando una de las operaciones
que provocan el problema, informando a la correspondiente
transacción. No anula la transacción.
11
11
Práctica 4.
Recurso 1 para control concurrencia en Oracle:
12
Para ver los bloqueos que hay en un momento determinado se puede utilizar la herramienta de
informes del SQL Developer (Menú: Ver‐Informes) con el usuario sys o system.
12
Práctica 4.
Recurso 2 para control concurrencia en Oracle:
Versiones antiguas de los elementos de datos:
 Las versiones de un elemento de datos que mantiene el sistema
son los valores (confirmados) anteriores a las actualizaciones de
las transacciones, que se almacenan con fines de recuperación
de la base de datos.
 En Oracle la información para la recuperación de la base de
datos se almacena en dos repositorios distintos:
 El fichero de diario (Redo Log) y
 El espacio de deshacer (Undo Tablespace).
13
Anteriormente se ha dicho que Oracle utiliza tres recursos para el control de la concurrencia:
bloqueo de elementos de datos, versiones de los elementos de datos y marcas de tiempo. Esto
significa que ninguno de estos recursos por sí sólo es suficiente para asegurar los niveles de
aislamiento que permite Oracle.
Respecto a las versiones de los elementos de datos, Oracle mantiene versiones antiguas de los
elementos de datos (valores confirmados anteriores a las actualizaciones de las transacciones)
con fines de recuperación de la base de datos. Este uso se vio en la práctica 3, pero como se verá
en las trasparencias siguientes, Oracle va a hacer también uso de las versiones de los elementos
de datos para el control de la concurrencia.
Usualmente (ver Tema 4), los SGBD almacenan los valores de los datos anterior (valor_antes) y
posterior (valor_después) a una actualización en el fichero de diario del sistema. Oracle, por
razones de rendimiento, almacena esta información en dos repositorios distintos, de la forma
que se va a exponer a continuación. Básicamente la idea del uso de un diario, donde se registra
todo lo que sucede en las transacciones, es la misma, pero la implementación que hace Oracle
de esta idea es distinta.
13
Práctica 4.
Recurso 2 para control concurrencia en Oracle:
Versiones antiguas de los elementos de datos:
Bloques
de datos
Bloques
de diario
Bloques de
deshacer
Instancia
Ficheros de
control
Área compartida
Buffers datos Buffer diario
Ficheros de
datos
DBWR
LGWR
CKPT
SMON
PMON
Memoria Principal
ARC
Ficheros de
diario
Base de datos Oracle
Memoria Secundaria
14
Como se ha presenta en el Tema 4, en un fichero de diario se registran todas las operaciones
que realizan las transacciones, con fines de recuperación de la BD: deshacer una transacción
anulada o interrumpida, o rehacer una transacción confirmada.
Para poder deshacer o rehacer una actualización de una transacción es necesario guardar en el
diario el valor anterior y el valor posterior a dicha actualización, como se indica en la entrada de
tipo [escribir, T, X, valor_antes, valor_después]
La particularidad de Oracle reside en que estas dos informaciones (valores de X) se almacenan
en dos repositorios distintos: en un fichero de datos del servidor y en el fichero de diario del
servidor.
Como se presentará en la práctica 6, Oracle utiliza para gestionar el espacio disponible en disco
(los ficheros de datos) una organización particular. El espacio en disco destinado a datos se
organiza en espacios de distinto tamaño (tablespaces en la terminología de Oracle), gestionados
por el servidor. Uno de estos espacios se destina a almacenar las anotaciones con los valores
anteriores de los datos actualizados, para poder deshacer transacciones durante la recuperación
de la BD. Por este motivo se habla de Espacio de Deshacer (Undo Tablespace).
En el fichero de diario se almacenan las anotaciones con el valor posterior de los datos
actualizados para poder rehacer transacciones durante la recuperación de la BD.
En la transparencia se indica el destino final de estos dos valores del dato actualizado
(valor_antes y valor_después). En las transparencias siguientes se presentará con más detalle el
uso de estos dos repositorios.
14
Práctica 4.
Recurso 2 para control concurrencia en Oracle:
Versiones antiguas de los elementos de datos:
Espacio de
deshacer
Fichero
de datos
Buffer de
datos
2
[escribir, T, X, valor_antes, valor_después ]
En la actualización de un elemento de datos (X):
 El valor_después se escribe en el objeto de datos
 El valor_antes se escribe en el espacio de deshacer
 Ambos modificaciones (escrituras) son registradas antes en el
fichero de diario con fines de recuperación.
Buffer de
diario
4
Objeto de
datos
3
1
Fichero
de diario
15
Debido a la forma particular, en Oracle, de almacenar la información relativa a una actualización,
es importante entender el destino de cada información:
• El valor del dato después de la actualización (valor_después) se escribe en el correspondiente
bloque de datos (bloque del objeto de datos) residente temporalmente en el buffer de datos.
Una anotación con ese valor actualizado (valor_después) es registrada previamente en el
buffer de diario.
• El valor del dato antes de la actualización (valor_antes) se escribe en el correspondiente
bloque del espacio de deshacer residente temporalmente en el buffer de datos. Una
anotación con la actualización realizada sobre el espacio de deshacer (valor_antes) es
también registrada previamente en el buffer de diario.
Los bloques de datos y de deshacer en los que se han hecho actualizaciones, en el buffer de
datos, serán devueltos a su posición en el disco en algún momento posterior (Práctica 3).
El contenido del buffer de diario será grabado en el fichero de diario en disco siguiendo una
política que asegura tener en el diario en disco toda la información necesaria para la
recuperación de la base de datos en caso de fallo. (Práctica 3)
Es importante observar que las actualizaciones realizadas en el espacio de deshacer
(valor_antes) reciben el mismo tratamiento, respecto a la política de recuperación, que las
actualizaciones de los objetos de datos (valor_después), es decir son anotadas en el fichero de
diario.
15
Práctica 4.
Recurso 3 para control concurrencia en Oracle:
Marcas de tiempo: System Change Number (SCN)
 SCN: número secuencial asignado por el sistema (representa un
instante de tiempo y permite la ordenación temporal).
 Cada transacción lleva asociado un SCN de inicio y un SCN de
terminación. Si una transacción T tiene un SCN de inicio menor que el SCN
de inicio de otra transacción T’, entonces T es anterior a T’.
 Los bloques de datos tienen, en la cabecera del bloque, ranuras
transaccionales donde el sistema registra, entre otra
información, el SCN de las transacciones confirmadas que han
actualizado filas del bloque.
16
16
Práctica 4.
Recurso 3 para control concurrencia en Oracle:
Marcas de tiempo: System Change Number (SCN)
Cabecera
Espacio Libre
Bloque
•
•
•
Directorio de filas en el bloque.
Directorio de tablas que usan el
bloque.
Slots de transacciones: SCN de
confirmación de las transacciones
que han modificado las filas del
bloque.
Datos
17
17
Práctica 4.
Estudio de las anomalías en Oracle:
 Lectura sucia.
 Lectura no repetible. Lectura de fantasmas.
 Pérdida de actualizaciones.
18
Una vez presentados los tres recursos que utiliza Oracle para el control de la concurrencia, se va
a hacer una revisión de las anomalías tipificadas (lectura sucia, lectura no repetible, y pérdida de
actualizaciones) para analizar cómo Oracle las evita con su estrategia de control de la
concurrencia. Dado que la lectura de fantasmas es un caso específico de lectura no repetible, no
se estudia su caso.
18
Práctica 4.
READ COMMITED
Lectura sucia en Oracle:
T1
T2
t1
t2
t3
inicio
r(X)
w(X)
…
bloqueo (exclusivo
en escritura)
ti
…
Buffers de datos
bloques de datos
X
10
X=10
inicio
r(X)
bloques de deshacer
20
T1 t3 X 10
X=10
lectura permitida
El sistema muestra el último valor confirmado
del elemento de datos que existe en el
momento en que se inicia la instrucción SQL.
19
El sistema necesita mantener información sobre las transacciones confirmadas, y el instante de
inicio y de finalización de las transacciones.
En los slots transaccionales de la cabecera de los bloques, el sistema guarda el SCN de las
transacciones que han actualizado filas del bloque.
Procedimiento:
a) Si la última transacción* que ha actualizado X (cabecera de bloque) es una transacción
confirmada**, entonces, el valor de X en el bloque de datos es un valor confirmado.
b) Si la última transacción que ha actualizado X (cabecera de bloque) no es transacción
confirmada, entonces, el sistema deberá buscar en el espacio de deshacer la primera
actualización de X de esa transacción, y usar el valor_antes.
En Oracle NO hay lectura sucia.
* La última transacción que ha actualizado X será la de mayor SCN (slots transaccionales)
** No se entra en cómo el servidor mantiene información sobre las transacciones: inicio, fin,
confirmación.
19
Práctica 4.
Lectura sucia en Oracle:
 Para cada elemento de datos actualizado por una transacción, el
sistema mantiene la siguiente información en el espacio de
deshacer: el identificador de la transacción, una marca de
tiempo y el valor antes de la actualización.
 Con esta información el SGBD puede proporcionar a cada
transacción que requiere la lectura de un elemento de datos el
último valor confirmado del mismo antes del inicio de la
instrucción.
Se asegura el nivel de aislamiento READ COMMITED: las operaciones de
lectura de las transacciones leen datos ya confirmados en el momento de la
lectura (o bien las actualizaciones realizadas por la propia transacción).
Se evita la anomalía de la lectura sucia.
20
Para asegura el nivel de aislamiento READ COMMITED (valor por defecto) en el que no se
produce la anomalía de la lectura sucia, Oracle utiliza las versiones anteriores de los elementos
de datos y proporciona a las transacciones, en sus operaciones de lectura, el último valor
confirmado del dato, existente al inicio de la operación.
En Oracle NO hay lectura sucia.
20
Práctica 4.
Estudio de las anomalías en Oracle:
 Lectura sucia.
 Lectura no repetible. Lectura de fantasmas.
 Pérdida de actualizaciones.
21
21
Práctica 4.
Lectura no repetible en Oracle:
 El valor mínimo y por defecto de aislamiento de Oracle es
read commited por lo que en este nivel se leerán siempre
datos confirmados antes de la operación de lectura.
Si entre dos lecturas del mismo dato en una transacción otra
transacción modifica el dato y confirma la modificación, cada
lectura devolverá un valor.
22
22
Práctica 4.
READ COMMITED
Lectura no repetible en Oracle:
T1
t1
t2
t3
t4
…
ti
…
inicio
r(X)
T2
bloques de datos
X=10
inicio bloqueo
w(X)
c liberación
r(X)
Buffers de datos
bloques de deshacer
X
10
50
T2 t4 X 10
X=50
lectura permitida
Sí se da la
anomalía
El sistema muestra el último valor confirmado
del elemento de datos que existe en el
momento en que se inicia la instrucción SQL.
23
Como se puede observar, el uso del protocolo de bloqueo de Oracle y la lectura del último valor
confirmado del dato (al inicio de la operación), no son suficientes para evitar la anomalía.
23
Práctica 4.
SERIALIZABLE
Lectura no repetible en Oracle:
T1
t1
t2
t3
t4
…
ti
inicio
r(X)
T2
bloques de datos
X=10
inicio bloqueo
w(X)
c liberación
r(X)
Buffers de datos
bloques de deshacer
X
10
50
T2 t4 X 10
X=10
…
lectura permitida
No se da la
anomalía
El sistema muestra el último valor confirmado
del elemento de datos que existe en el
momento en que se inicia la transacción
24
24
Práctica 4.
SERIALIZABLE
Lectura no repetible en Oracle:
T1
t1
t2
t3
t4
t5
t6
t7
t8
t9
t10
t11
inicio
r(X)
…
…
T2
X=10
inicio
r(X)
w(X)
c
No se da la
anomalía
bloques de deshacer
T0 ti X 4
10
X=10
inicio
r(X)
w(X)
c
r(X)
bloques de datos
X
T3
X=50
50
T2 t4 X 10
80
T3 t9 X 50
X=10
El sistema muestra el último valor confirmado
del elemento de datos que existe en el
momento en que se inicia la transacción
25
En la transparencia se muestra un ejemplo con 3 transacciones.
SERIALIZABLE: Se busca en el espacio de deshacer las entradas de la última transacción, que ha
actualizado X, y que ha sido confirmada, antes del inicio de la transacción que ahora quiere leer.
Procedimiento:
a) Si la última transacción que ha actualizado X (cabecera de bloque) es una transacción
confirmada, antes del inicio de la transacción que ahora quiere leer, entonces se lee el valor
de X en el bloque de datos.
b) Si la última transacción que ha actualizado X (cabecera de bloque) es una transacción
confirmada, después del inicio de la transacción que ahora quiere leer, o no es una
transacción confirmada, entonces, el sistema deberá buscar dos transacciones consecutivas,
Ti, Ti+1 (que han actualizado X), tales que Ti sea la última transacción confirmada antes del
inicio de la transacción que ahora quiere leer, y en el espacio de deshacer se debe leer el
valor_antes de la primera actualización de Ti+1.
25
Práctica 4.
Lectura no repetible en Oracle:
 Para cada elemento de datos actualizado por una transacción, el
sistema mantiene la siguiente información en el espacio de
deshacer: el identificador de la transacción, una marca de
tiempo y el valor antes de la actualización.
 Con esta información el SGBD puede proporcionar a cada
transacción que requiere la lectura de un elemento de datos el
último valor confirmado del mismo antes del inicio de la
transacción.
Se asegura el nivel de aislamiento SERIALIZABLE: las operaciones de lectura
de las transacciones leen datos confirmados antes del inicio de la
transacción (o bien las actualizaciones realizadas por la propia transacción).
Se evita la anomalía de la lectura no repetible.
26
Para asegura el nivel de aislamiento SERIALIZABLE en el que no se produce la anomalía de la
lectura no repetible, Oracle usa las versiones anteriores del elemento de datos, y proporciona a
las transacciones, en sus operaciones de lectura, el último valor confirmado del dato, existente al
inicio de la transacción.
26
Práctica 4.
Estudio de las anomalías en Oracle:
 Lectura sucia.
 Lectura no repetible. Lectura de fantasmas.
 Pérdida de actualizaciones.
27
27
Práctica 4.
READ COMMITED
Pérdida de actualizaciones en Oracle:
Buffers de datos
T1
t1
t2
t3
t4
t5
t4
t6
t7
t8
t9
inicio
r(X)
T2
bloques de datos
X
10
X=10
inicio
r(X)
X=10
XX2
bloqueo
w(X)
c liberación
XX3
w(X) bloqueo
c liberación
8
7
Sí se da la
anomalía
28
Como se puede observar, el uso del protocolo de bloqueo de Oracle y la lectura del último valor
confirmado del dato (al inicio de la transacción), no son suficientes para evitar la anomalía. Por
lo tanto va a ser necesario utilizar otros recursos.
28
Práctica 4.
SERIALIZABLE
Pérdida de actualizaciones en Oracle:
Buffers de datos
T1
t1
t2
t3
t4
t5
t4
t6
t7
t8
t9
inicio
r(X)
T2
bloques de datos
X
10
X=10
inicio
r(X)
XX2
bloqueo
w(X)
c liberación
XX3
w(X)
No se da la
anomalía
X=10
8
ORA 08177, “Cannot serialize access for this
transaction”
Cause: Encountered data changed by an operation that
occurred after the start of this serializable transaction.
29
29
Práctica 4.
Pérdida de actualizaciones en Oracle:
 Oracle utiliza la información de las marcas de tiempo (SCN) en
los slots transaccionales de la cabecera de los bloques para
saber qué transacciones han actualizado alguna fila del bloque.
 En el nivel de aislamiento SERIALIZABLE, una transacción T
puede actualizar una fila sólo si el sistema puede garantizar que
la última actualización de la fila fue hecha por una transacción
que fue confirmada antes del inicio de T.
 Error generado cuando una transacción T (ejecutada en el nivel
SERIALIZABLE) intenta actualizar una fila residente en un bloque
que ha sido actualizada por otra transacción que fue confirmada
después de que la transacción T se iniciase: ORA 08177, “Cannot
serialize access for this transaction”.
Anula la instrucción de escritura
30
Oracle utiliza para el control de la anomalía de la pérdida de actualizaciones, el recurso de las
marcas de tiempo en los slots transaccionales de las cabeceras de bloque.
30
Tecnología de Bases
de Datos
Práctica 5 (Parte 1)
Implementación de bases de datos
en Oracle
 Estudiar la estructura de almacenamiento de Oracle.
Profesores: Laura Mota y Mª José Vicent
Curso: 2019‐2020
1
Práctica 5. Parte 1.
Reserva en memoria
principal (temporal)
Almacenamiento en Oracle:
Instancia
Servidor Oracle
BD Oracle
Almacenamiento en
disco (permanente)
2
El espacio en disco de un servidor Oracle se compone de un conjunto de ficheros del SO. Estos
ficheros están especializados para distintos usos: ficheros de control, ficheros de diario, y
ficheros de datos.
Los ficheros de datos constituyen el espacio en disco destinado al almacenamiento de datos de
los usuarios y del servidor.
2
Práctica 5. Parte 1.
Jerarquía de almacenamiento:
Base de Datos
Oracle
Tablespace
Lógico
Ficheros del
SO
Físico
Segmento
Extensión
Bloque
Oracle
Gestión del espacio en disco (Oracle)
Bloque SO
Gestión del espacio en disco (SO)
3
Oracle gestiona el espacio en disco destinado a datos, los ficheros de datos, de una forma
propia, superponiendo una organización lógica sobre la organización física del SO.
El espacio en disco para datos se organiza en tablespaces.
• Un tablespace se define sobre uno o varios de los ficheros de datos del servidor, es decir es el
espacio en disco (no necesariamente contiguo) constituido por estos ficheros.
• Un segmento es el espacio en disco ocupado por un objeto de BD (del usuario o del servidor).
Un segmento va ocupando espacio en disco dinámicamente en unidades de tamaño variable
denominadas extensiones.
• Una extensión es espacio en disco contiguo formado por uno o varios bloques Oracle.
• Un bloque Oracle está formados por uno o varios bloques de SO contiguos.
3
Práctica 5. Parte 1.
Estructura del almacenamiento:
Índice1
Tabla2
Índice2
Índice3
Índice6
Índice4
Índice7
Índice5
Tabla3
Disco2
Tabla1
Fichero2
Fichero1
Disco1
Tablespace: espacio en disco definido por uno o más ficheros de SO
Tablespace
Ficheros del SO
(estructuras físicas (SO)
asociadas a un tablespace)
Objetos de BD (tablas, índices)
(almacenados en un tablespace se
pueden distribuir por varios ficheros en
disco)
4
Oracle gestiona el espacio en disco destinado a datos en forma de tablespaces.
Un tablespace se define sobre uno o varios de los ficheros de datos del servidor, es decir es el
espacio en disco (no necesariamente contiguo) constituido por estos ficheros.
El uso de tablespaces hace más flexible la gestión del espacio en disco en el servidor
Cuando se crea un nuevo usuario se le asigna un tablespace para datos en el cual se
almacenarán (por defecto) los objetos creados por el usuario mientras éste no especifique en la
creación del objeto otro tablespace en el que esté autorizado.
4
Práctica 5. Parte 1.
Estructura del almacenamiento:
Segmento: espacio en disco ocupado por un objeto de BD
Disco2
100M
Disco1
F1
32K
Segmento de tabla t1
64K
96K
Segmento de tabla t2
32K
100M
Extensiones
F2
Tablespace T
Un objeto de base de datos (tabla, índice) se almacena en un único tablespace.
5
Un segmento es el espacio en disco ocupado por un objeto de BD (del usuario o del servidor).
Un segmento se almacena en un único tablespace.
Un segmento va ocupando espacio en disco (en el tablespace) dinámicamente a medida que el
correspondiente objeto crece. Las asignaciones de memoria que recibe se denominan
extensiones, y pueden ser de tamaño variable.
Una extensión es espacio en disco contiguo formado por uno o varios bloques Oracle. Una
extensión no puede ocupar bloques de ficheros distintos.
Las extensiones de un segmento aparecen distribuidas en el tablespace (incluso en ficheros
distintos), es decir, no son necesariamente contiguas en disco.
El tamaño de las extensiones se especifica en la definición del tablespace.
5
Práctica 5. Parte 1.
Estructura del almacenamiento:
Segmento asociado a la tabla t1
creada en el tablespace T
Segmento t1
128k
Extensión
32k 4k
4k
Extensión
4k
96k 4k
4k 4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
4k
Bloques Oracle (4K)
Las extensiones que se van
asignando dinámicamente a un
segmento pueden ser de
tamaño variable.
6
6
Práctica 5. Parte 1.
Estructura del almacenamiento:
Tipos de tablespace
Permanente
Temporal
Deshacer
Tamaño de las
extensiones
Gestión del espacio en
un tablespace (gestión
de extensiones)
Local
Gestión del espacio en
un segmento
Automático
Automático
Uniforme
Diccionario (en desuso)
Manual
7
En Oracle existen tres tipos de tablespaces:
• Permanente: para almacenar segmentos de objetos de BD (tablas, índices, …)
• Temporal: para almacenar segmentos temporales, creados por el servidor para tareas de
ordenación de datos.
• Deshacer: para almacenar segmentos de deshacer, con información para las tareas de
recuperación.
La gestión de las extensiones en un tablespace es local: el espacio (bloques ocupados y libres) en
el tablespace se gestiona en un mapa de bits en la cabecera del tablespace. En versiones
anteriores había una gestión por diccionario de datos que ya está en desuso. En la gestión local
el tamaño de las extensiones puede ser establecido automáticamente por el servidor (asignación
automática) que es el valor por defecto, o puede definirse un tamaño uniforme.
La gestión del espacio en un segmento, es decir el espacio (bloques) ocupado y libre en sus
extensiones, se puede gestionar por medio de listas de bloques libres (manual), es el valor por
defecto, o por medio de un mapa de bits en la cabecera del segmento (automático).
7
Práctica 5. Parte 1.
Estructura del almacenamiento: tablespaces
8
Los tablespaces pueden ser gestionados por usuarios con privilegios de administración (sys o
system).
8
Práctica 5. Parte 1.
Estructura del almacenamiento: tablespaces
9
9
Práctica 5. Parte 1.
Estructura del almacenamiento: tablespaces
10
10
Práctica 5. Parte 1.
Estructura del almacenamiento: ficheros de datos
11
11
Práctica 5. Parte 1.
Estructura del almacenamiento: tablespaces
12
12
Práctica 5. Parte 1.
Estructura del almacenamiento: tablespaces
13
13
Práctica 5. Parte 1.
Estructura del almacenamiento: tablespaces
14
14
Práctica 5. Parte 1.
Tipos de segmentos: Datos de usuario
Tabla
Partición
de tabla
Índice
Agrupación
Tabla organizada
como índice
Partición de
índice
15
En Oracle existen distintos tipos de segmentos correspondientes a distintos tipos de objetos de base de datos:
Segmento de tabla: es el tipo de segmento más frecuente, es el espacio en disco ocupado por una estructura
tabla implementada como un fichero desordenado. Las filas de la tabla se almacenan en las extensiones
(bloques) del segmento sin ningún orden. En un principio las filas se almacenan secuencialmente, según el
orden de inserción, y posteriormente, cuando la tabla evoluciona debido a actualizaciones y borrados, se
reutiliza el espacio libre existente en los bloques.
Segmento de partición de tabla: Oracle contempla la partición de una tabla (implementada como un fichero
desordenado) en subconjuntos de filas definidos por algún criterio: valor del campo(s) de partición. Cada
partición es un segmento distinto que se almacena en un tablespace distinto. Oracle gestiona los diferentes
segmentos de la partición de forma trasparente para el usuario. La partición de una tabla (de un tamaño
grande) mejora el rendimiento en el uso concurrente de la tabla.
Segmento de agrupación (cluster): la agrupación es una estructura de datos (fichero mixto) en la que se
almacenan filas de dos tablas distintas relacionadas por algún campo (generalmente una clave ajena). Esta
forma de implementar las tablas favorece la recuperación conjunta de las filas relacionadas de ambas tablas. El
espacio ocupado por esta estructura es un segmento de agrupación. Las tablas incluidas en la agrupación no
tienen segmento propio.
Segmento de tabla organizada como índice: en casos especiales una estructura tabla puede implementarse
como una estructura de índice, de forma que los campos no‐clave de las filas se almacenan junto a la clave de
indexación, en los nodos del índice. El espacio ocupado por una tabla implementada de esta forma es un
segmento de tabla‐índice.
Segmento de índice: un índice es una estructura de datos que permite el acceso directo y ordenado a las filas
de una tabla por el valor de un campo de indexación. El espacio ocupado por un índice es un segmento de
índice.
Segmento de partición de índice: de la misma forma y por las mismas razones que en el caso de una tabla, las
entradas de un índice pueden ser divididas en subgrupos por algún criterio, y almacenadas en segmentos
distintos: segmentos de partición de índice.
15
Práctica 5. Parte 1.
Tipos de segmentos: Datos del servidor
Segmento de
deshacer
Segmento
temporal
16
Segmento de deshacer: es un tipo de segmento para uso del servidor, en el que se almacenan
entradas con información (valor_antes) relativa a las actualizaciones realizadas en tablas e
índices por las operaciones de usuario. Esta información permite deshacer transacciones durante
el proceso de recuperación de la base de datos.
Segmento temporal: es un tipo de segmento para uso del servidor. Los segmentos temporales
son creados dinámicamente por el servidor, en los tablespaces temporales, y sirven para realizar
tareas de ordenación de datos cuando esto sea necesario. Operaciones: CREATE INDEX, SELECT
DISTINCT, SELECT … GROUP BY, SELECT … ORDER BY.
16
Práctica 5. Parte 1.
Asignación y liberación de extensiones:
 Asignación de extensiones a un segmento:
 Se insertan datos por primera vez en el segmento.
 El segmento crece (inserciones, modificaciones).
 Se extiende manualmente el segmento.
 Liberación de extensiones de un segmento:
 Se elimina el segmento.
 Se trunca el segmento.
 Se reorganiza el segmento.
 La asignación y liberación de extensiones (de tamaño variable)
a los segmentos produce la fragmentación del espacio en disco
del tablespace (ficheros). El servidor Oracle en ciertas situaciones, o a
petición del administrador, puede fundir huecos libres y contiguos de
distinto tamaño para disponer de espacios libres de mayor tamaño.
17
El servidor asigna dinámicamente extensiones a un segmento a medida que éste crece.
Las extensiones ocupadas por un segmento se liberan cuando el segmento se borra o se trunca.
El servidor gestiona los espacios (huecos) libres en los tablespaces con el fin de volver a
utilizarlos. Cuando las extensiones liberadas son de distinto tamaño, el espacio en el tablespace
(ficheros) puede quedar muy fragmentado. El servidor Oracle puede fundir porciones de espacio
libre contiguo en los ficheros del tablespace para disponer de áreas de espacio libre de mayor
tamaño, y crear en ellas nuevas extensiones.
17
Práctica 5. Parte 1.
Bloque de datos Oracle:
 Unidad mínima de E/S
 Consiste en uno o más bloques de SO
 Se establece en la creación del servidor
(BD Oracle)
Cabecera
Espacio Libre
(para las actualizaciones de
filas del bloque)
Datos
(filas)
Tamaño del bloque: parámetro de inicialización DB_BLOK_SIZE
18
Oracle usa un tamaño de bloque propio. Este tamaño se define en la creación del servidor Oracle
(parámetro: DB_BLOK_SIZE).
Un bloque Oracle consiste en uno o varios bloques de SO contiguos.
Esto significa que la unidad de transferencia de datos entre memoria secundaria y memoria
principal (buffers del servidor) puede ser mayor.
En un servidor Oracle, el espacio del bloque se divide en tres secciones: cabecera del bloque,
espacio para datos (filas de tabla o entradas de índice), y espacio libre para las posibles
actualizaciones (cambio de longitud) de las filas almacenadas en el bloque.
Es importante destacar que en Oracle, las filas son registros de longitud variable, debido al uso
de tipos de datos de longitud variable (varchar) y a la existencia de valores nulos.
El tamaño de las secciones del bloque se puede establecer en la definición del objeto de datos
(segmento). Si no se hace, Oracle asume unos valores por defecto.
18
Práctica 5. Parte 1.
Bloque de datos Oracle:
Cabecera:
 directorio de filas en el bloque.
 slots de transacciones: transacciones
que han modificado las filas del
bloque
Espacio Libre
(para las actualizaciones de
filas del bloque)
Datos
(filas)
19
En la cabecera del bloque se almacena la siguiente información: un directorio de las filas
almacenadas en el bloque, y los slots o ranuras transaccionales.
Los slots transaccionales guardan información sobre las transacciones que han actualizado filas
del bloque. Son utilizados para el control de la concurrencia en el nivel de aislamiento
SERIALIZABLE.
19
Práctica 5. Parte 1.
Bloque de datos Oracle:
Parámetros de uso del bloque (en
un segmento):
INITRANS
MAXTRANS: fijo a 255
PCTFREE
PCTUSED
20
Los parámetros de uso del bloque se pueden especifican en la creación del objeto (segmento).
Los parámetros INITRANS y MAXTRANS están relacionados con el control de la concurrencia, y
fijan el número mínimo y máximo de slots transaccionales en la cabecera del bloque. Por
ejemplo si INITRANS tiene el valor 3, se asegura que al menos tres transacciones pueden estar
actualizando filas del bloque. Si se necesitan nuevos slots adicionales, se crean hasta el valor
MAXTRANS. El espacio libre en el bloque puede ser utilizado también para aumentar el tamaño
de la cabecera del bloque.
20
Práctica 5. Parte 1.
PCTFREE=20
PCTUSED=40
Bloque de datos Oracle:
Inserciones
80%
1
Inserciones
2
80%
Inserciones
Inserciones
40%
3
4
21
Los parámetros PCTFREE y PCTUSED están relacionados con el uso del espacio para datos en el
bloque y las operaciones de usuario que están permitidas.
PCTFREE establece el porcentaje de espacio libre en el bloque (valor por defecto: 10%).
PCTUSED establece el porcentaje de espacio usado que el servidor intenta mantener en el
bloque. Cuando un bloque tiene un porcentaje de ocupación por debajo de PCTUSED, el bloque
pasa a formar parte de la lista de bloques del segmento disponibles para nuevas inserciones de
filas (valor por defecto: 40%).
En el ejemplo:
Estado 1: se insertan filas en el bloque hasta una ocupación del 80%.
Estado 2: el bloque no admite nuevas inserciones (PCTFREE=20%).
Estado 3: se borran filas o se actualizan filas lo que implica una reducción del espacio ocupado
en el bloque. Mientras el espacio ocupado esté por encima del 40%, el bloque no estará
disponible para nuevas inserciones.
Estado 4: cuando debido a sucesivos borrados y actualizaciones el espacio ocupado cae por
debajo del 40%, el bloque vuelve a admitir nuevas inserciones de filas.
21
Práctica 5. Parte 1.
Estructura de una fila (de una tabla):
Cabecera de fila
Longitud de columna
Valor de columna
Bloque Oracle
22
En Oracle las filas son registros de longitud variable.
Los campos (columnas) se almacenan en la fila en el orden en que aparecen en la definición de la
tabla. Las columnas del final de la fila con valor nulo no se almacenan. Para poder direccionar las
columnas dentro de la fila, ésta tiene la siguiente estructura:
Cabecera de la fila: almacena el número de columnas en la fila, la información de enlace cuando
una fila, debido a su longitud, tiene que ser almacenada en varios bloques, y el estado de
bloqueo de la fila para el control de la concurrencia.
Datos: para cada columna, el servidor almacena la longitud de la columna (1 byte o 3 bytes
según el tipo de datos de la columna) y su valor, en ese orden.
Por ejemplo, sea una tabla con 10 atributos (todos ellos de tipo entero), y la siguiente fila de esa
tabla:
{(a1, 1), (a2, null), (a3, 7), (a4, null), (a5, 5), (a6, 4) (a7, 1), (a8, null), (a9, null) (a10,
null)}:
• En la cabecera de la fila se almacenará que sólo tiene 7 valores (los 3 últimos atributos son
nulos).
• Para cada uno de los 7 primeros atributos se almacenará dos informaciones: longitud (0 si es
nulo) y valor.
No existen caracteres separadores entre filas.
22
Práctica 5. Parte 1.
Migración y encadenamiento de filas:
Antes de
actualizar
Después de
actualizar
23
En la trasparencia se muestra el caso de una fila que, después de una actualización, no
cabe en el bloque que ocupaba inicialmente. En estos casos Oracle traslada la fila
actualizada a otro bloque y mantiene, en el bloque inicial, un puntero a la nueva posición
de la fila: MIGRACIÓN.
El fenómeno del ENCADENAMIENTO sucede cuando una fila tiene una longitud
demasiado larga para caber en un bloque. En estos casos Oracle, trocea la fila en
fragmentos más pequeños que son almacenados en bloques distintos, y mantiene
punteros entre los fragmentos para poder reconstruir la fila completa.
23
Práctica 5. Parte 1.
Consulta diccionario del sistema:
Tabla
Descripción
dba_tables
dba_objects
dba_tab_columns
dba_constraints
Información relativa a los objetos de los
usuarios: tablas, restricciones,
columnas, …
dba_tablespaces
dba_free_space
dba_segments
dba_extents
Información sobre los tablespaces y el
almacenamiento físico de los objetos
(segmentos) del usuario
Para conocer el esquema de una tabla del diccionario se debe usar la instrucción
describe nombre_de_tabla.
Cualquier tabla puede consultarse con la instrucción select.
24
Por ejemplo, para saber qué tablas ha creado Cosmos se podría consultar la tabla daba_tables
del sistema (con un usuario como sys o system). Para saber qué información almacena esa tabla
usaríamos la instrucción describe (donde veríamos que uno de sus atributos es owner):
describe dba_tables;
select *
from dba_tables
where owner = ‘COSMOS’;
24
Tecnología de Bases
de Datos
Práctica 5 (Parte 2)
Implementación de bases de datos
en Oracle
 Estudiar los distintos tipos de índices que ofrece Oracle.
Profesores: Laura Mota y Mª José Vicent
Curso: 2019‐2020
1
Práctica 5. Parte 2.
Identificador interno de fila de una tabla: ROWID
• Identificador único de una fila
• Se usa para localizar una fila
Formato ROWID
OOOOOO
FFF
BBBBBB
RRR
Número objeto
Número fichero
Número bloque
Número fila
2
El ROWID es una columna virtual (no se almacena) de todas las tablas.
El ROWID es el identificador único de las filas en la base de datos.
El ROWID no coincide con la dirección física de la fila, pero sirve para localizarla en la base de
datos, y para hacer referencia a ella desde cualquier sitio.
Los ROWID de las filas se almacenan en los índices de las tablas para direccionar las filas.
Un ROWID tiene una longitud de 10 bytes y es visualizado como 18 caracteres con el siguiente
significado:
• Número de objeto: es el número de objeto (único en la BD) al que pertenece la fila (permite
conocer el tablespace en el que está almacenado).
• Número de fichero relativo: es el número de fichero relativo (dentro del tablespace del
segmento) en el que se almacena la fila.
• Número de bloque relativo: es el número de bloque relativo (dentro del fichero) en el que se
almacena la fila.
• Número de fila relativo: es la entrada (número de orden) en el directorio de filas de la
cabecera del bloque, correspondiente a la fila.
El uso del nro. de entrada en la cabecera de bloque para direccionar la fila permite mover la fila
en el bloque (compactación) sin que cambie su rowid.
2
Práctica 5. Parte 2.
Clasificación de índices:
 Lógica:
Campo de indexación simple o múltiple.
Con restricción de unicidad o no (único o no único).
 Física:
Particionado o no particionado.
Árbol B+ o mapa de bits.
• Normal o invertido (sólo en árbol B+).
3
Los índices son estructuras de datos que permiten el acceso directo y ordenado a las filas de una
tabla por el valor de un campo de indexación (llamado también clave de indexación aunque no
tenga restricción de unicidad).
En Oracle, las entradas de un índice son pares de la forma <valor‐clave, ROWID>
El campo de indexación puede ser simple, formado por una única columna de la tabla, o
múltiple, formado por la concatenación de varias columnas de la tabla.
En el caso de campo de indexación múltiple, el orden de las columnas en el campo de
indexación, no tiene que coincidir con el orden de las columnas en la definición de la tabla.
El campo de indexación puede tener restricción de unicidad (único) o no tenerla (no único). En el
primer caso cada entrada del índice apunta a una única fila de la tabla indexada, en el segundo
caso cada entrada del índice apunta a un conjunto de filas de la tabla.
Por su estructura, los índices se clasifican en índices con estructura en árbol B+, e índices de
mapas de bits (estructura de array).
Por último, un índice, al igual que una tabla, puede particionarse en varios segmentos para
mejorar su rendimiento.
3
Práctica 5. Parte 2.
Índice en árbol B+:
Entrada del índice
(nodo‐hoja)
Nodo‐raíz
Nodo‐interno
Cabecera
Nodo‐hoja
Longitud columna clave
Valor columna clave
ROWID
4
Un índice en árbol B+, es un índice donde las entradas se organizan en una estructura de árbol
B+,
En un árbol B+ se diferencian dos tipos de nodos: los nodos internos y los nodos hoja.
Los nodos internos sirven para organizar (distribuir) los valores de la clave en el árbol. Las
entradas en un nodo‐interno contienen: un valor del campo clave y un puntero a un nodo
(bloque) del nivel inmediatamente inferior.
Los nodos‐hoja contienen entradas que direccionan filas de la tabla indexada. Las entradas en un
nodo‐hoja contienen: una cabecera con el número de columnas de la clave (en la entrada) e
información sobre el estado de bloqueo de la entrada; un valor de la clave (simple o compuesta);
y la dirección (ROWID) de la fila de la tabla con dicho valor de clave.
Los nodos‐hoja (bloques) están doblemente encadenados entre sí para permitir el acceso
secuencial ordenado (ascendente y descendente) a las filas de la tabla por el valor del campo
clave.
Si el índice no es único, entonces puede contener entradas con valor de clave repetido, que
apuntarán a distintas filas de la tabla. (Índice denso).
La inserción de una nueva fila en la tabla implica la inserción de una nueva entrada en el índice
en el nodo‐hoja apropiado, y la reestructuración del árbol si es necesario. El borrado de una fila
implica el borrado lógico (marcado) de una entrada en un nodo‐hoja (no se reutiliza el espacio
de los borrados hasta que el nodo (bloque) está vacío). Una modificación del campo clave
significa el borrado y la inserción de una nueva entrada en el índice.
4
Práctica 5. Parte 2.
Índice mapa de bits:
Fichero 3
Bloque 10
Tabla
Bloque 11
Bloque 12
Índice (árbol B+)
clave
Start
End
ROWID ROWID
bitmap
<azul, 10.0.3, 12.6.3, 1000100100010010100>
<verde, 10.3.3, 12.3.3, 0001010000100100000>
<rojo, 10.1.3, 12.8.3, 0100000011000001001>
<amarillo, 10.2.3, 12.7.3, 0010001000001000010>
5
Los índice de mapa de bits son útiles cuando la tabla indexada tiene una cardinalidad elevada, y
el campo de indexación tiene un número reducido de valores. Son recomendables también
cuando no son muy frecuentes las operaciones de actualización en la tabla, es decir es una tabla
principalmente de lectura.
Un índice de mapa de bits se organiza también como un árbol B+. La diferencia con el índice en
árbol B+ reside en que las entradas en los nodos‐hoja contienen un vector (array) de bits
asociado al valor del campo de indexación. Cada bit en el array se corresponde con una fila de la
tabla indexada.
Las entradas en los nodos‐hoja contienen también los valores StartROWID y EndROWID:
StartROWID es la dirección (relativa) de la primera fila en la tabla que contiene el valor de la
clave, y EndROWID es la dirección (relativa) de la última fila en la tabla que contiene dicho valor
en la clave.
Los bits, en el vector asociado a un valor del campo de indexación, representan todas las filas en
la tabla. Si un bit de este array tiene un valor 1 significa que la correspondiente fila en la tabla
tiene dicho valor en el campo de indexación.
Ejemplo de entrada en un nodo‐hoja del índice:
<azul, 10.0.3, 12.6.3, 1000100100010010100>
La primera fila en la tabla que tiene el valor AZUL en el campo clave es la fila de ROWID 10.0.3
(fichero 3, bloque 10, fila 0), y la última que tiene dicho valor es la fila de ROWID 12.6.3 (fichero
3, bloque 12, fila 6). El array de bits indica qué filas de la tabla tienen o no dicho valor en la clave.
StartROWID y EndROWID simplifican el acceso a bloques para recuperar las filas
El ROWID viene dado <bloque_id, fila_id, fichero_id>
5
Práctica 5. Parte 2.
Índice con clave invertida:
Índice sobre EMP (EMPNO)
KEY
ROWID
EMPNO
----1257
2877
4567
6657
8967
9637
9947
...
...
(BLOCK# ROW# FILE#)
------------------0000000F.0002.0001
0000000F.0006.0001
0000000F.0004.0001
0000000F.0003.0001
0000000F.0005.0001
0000000F.0001.0001
0000000F.0000.0001
...
...
Tabla EMP
EMPNO
----7499
7369
7521
7566
7654
7698
7782
...
...
ENAME JOB
----- -------ALLEN SALESMAN
SMITH CLERK
WARD
SALESMAN
JONES MANAGER
MARTIN SALESMAN
BLAKE MANAGER
CLARK MANAGER
...
...
...
...
...
...
...
...
6
En un índice de clave invertida, los valores (bytes) de las columnas que componen la clave se
invierten.
La inversión de la clave tiene como objetivo dispersar en el índice entradas correspondientes a
inserciones consecutivas con valores de clave secuenciales o muy próximos, y evitar de esta
forma problemas de bloqueo.
6
Práctica 5. Parte 2.
Comparación de índices:
Árbol B+
Bitmap
Adecuado para claves de cardinalidad
elevada.
Adecuado para claves de cardinalidad
baja.
Modificaciones sobre la clave son
relativamente eficientes.
Modificaciones sobre la clave son muy
ineficientes.
Ineficiente para consultas que usen la
conectiva lógica OR.
Eficiente para consultas que usen la
conectiva lógica OR.
Útiles para OLTP.
Útiles para DSS*.
* DSS: Decision Support Systems.
OLTP: On Line Transaction Processing
7
7
Práctica 5. Parte 2.
Creación de índices:
CREATE INDEX nombre_alumno
ON alumno(nombre) REVERSE
PCTFREE 30
TABLESPACE indx01;
CREATE BITMAP INDEX alumno_gén
ON alumno(sexo)
PCTFREE 30
TABLESPACE indx01;
8
8
Práctica 5. Parte 2.
Reconstrucción de índices:
ALTER INDEX alumno_nombre
REBUILD TABLESPACE indx02;
Usar esta instrucción para:
 Mover un índice a otro tablespace.
 Mejorar el aprovechamiento del espacio al eliminar las
entradas borradas.
 Cambiar un índice en árbol B+ normal a invertido y viceversa.
9
9
Práctica 5. Parte 2.
Eliminación de índices:
DROP INDEX alumno_nombre;
Usar esta instrucción para:
 Borrar los índices antes de cargas masivas y recrearlos
posteriormente.
 Borrar los índices que no se usan frecuentemente y crearlos
cuando sean necesarios.
 Borrar y recrear índices que no son válidos.
10
En las cargas masivas de la base de datos, es conveniente borrar los índices y volverlos a crear
después de finalizada la carga. Esto evita la actualización continua del índice durante la carga, lo
que consume tiempo y puede degradar el índice.
Cuando un índice se corrompe por algún motivo, el servidor no lo utiliza para la optimización de
consultas. Es responsabilidad del administrador vigilar estos índices y volverlos a crear.
10
Práctica 5. Parte 2.
Índices en el SQL Developer:
11
11
Práctica 5. Parte 2.
Índices en el SQL Developer:
12
12
Tecnología de Bases
de Datos
Práctica 5 (Parte 3)
Implementación de bases de datos
en Oracle
 Estudiar la implementación de tablas en Oracle.
Profesores: Laura Mota y Mª José Vicent
Curso: 2019‐2020
1
Práctica 5. Parte 3.
Creación de tablas:
CREATE TABLE empleado(
empno NUMBER(4) PRIMARY KEY,
nombre VARCHAR2(30),
depto NUMBER(2) REFERENCES departamento)
PCTFREE 20 PCTUSED 50
TABLESPACE data01;
2
En la transparencia aparece un ejemplo de definición de tabla, en el que se observa la definición
de los parámetros de uso de los bloques.
TABLESPACE: tablespace de almacenamiento del segmento de tabla.
PCTFREE, PCTUSED: parámetros de uso del espacio en el bloque.
2
Práctica 5. Parte 3.
Copia de tablas:
CREATE TABLE nuevo_empleado
TABLESPACE data01
AS
SELECT * FROM empleado;
3
La instrucción CREATE TABLE permite crear una tabla a partir de una subconsulta.
La nueva tabla tiene el mismo esquema y contenido que la tabla definida por la subconsulta.
En la copia no se trasfieren las restricciones de integridad definidas sobre la tabla origen, salvo
las restricciones de valor no nulo.
3
Práctica 5. Parte 3.
Marca de agua superior:
Después de inserciones
Extensión ID
0
1
2
3
Después de borrados
Extensión ID
Bloque usado
0
1
4
Marca de agua superior
2
Bloque sin usar
3
4
Bloque libre después
de borrar
4
La marca de agua de un segmento apunta al bloque con número (relativo) mayor, en el que ha
habido inserciones. (En el ejemplo el bloque 1 de la extensión 4)
A medida que se insertan filas en la tabla, la marca de agua va desplazándose.
Cuando la tabla experimenta borrados la marca de agua no se actualiza, lo que significa que en
las extensiones del segmento pueden existir bloques libres.
4
Práctica 5. Parte 3.
Asignación manual de extensiones a un segmento:
ALTER TABLE empleado
ALLOCATE EXTENT(SIZE 500K
DATAFILE ‘/DISK3/DATA01.DBF’);
5
La instrucción ALTER TABLE permite asignar manualmente extensiones a un segmento de tabla.
5
Práctica 5. Parte 3.
Liberación de espacio:
Antes de liberar
ALTER TABLE empleado
DEALLOCATE UNUSED;
Marca de agua superior
Después de liberar
Bloque usado
Bloque sin usar
Bloque libre después
de borrar
6
La instrucción ALTER TABLE permite liberar el espacio no utilizado (bloques y extensiones) por
encima de la marca de agua.
6
Práctica 5. Parte 3.
Truncamiento de una tabla:
TRUNCATE TABLE empleado;
Extensión ID
Marca de agua
superior
0
1
Bloque sin usar
7
La instrucción TRUNCATE TABLE borra todas las filas de una tabla y libera las extensiones
ocupadas por el segmento.
En el ejemplo se asume que MINEXTENTS es 2, por eso después de truncar la tabla se mantienen
dos extensiones, y la marca de agua se sitúa en el primer bloque de la primera extensión.
7
Práctica 5. Parte 3.
Borrado de una tabla:
DROP TABLE departamento
CASCADE CONSTRAINTS;
8
La instrucción DROP TABLE borra una tabla y libera las extensiones que ocupaba.
La opción CASCADE CONSTRAINTS borra las restricciones de clave ajena que hacen referencia a
la tabla borrada.
8
Práctica 5. Parte 3.
Implementación de una tabla:
Tabla
Agrupación
Tabla organizada
como índice (TOI)
Ordenación de Filas
Desordenadas
Agrupadas
Ordenadas
9
Las tres implementaciones posibles de la estructura tabla implican una distribución distinta de
las filas en las extensiones (bloques) del segmento de tabla.
En la implementación normal de una tabla como un fichero desordenado, inicialmente las filas
se almacenan secuencialmente en las extensiones (bloques) del segmento. Cuando la tabla
evoluciona, debido a actualizaciones y borrados, el orden de almacenamiento de las nuevas filas
deja de ser secuencial, y es imposible influir en la distribución de las filas.
En la implementación por agrupación (cluster), las filas de dos tablas relacionadas entre sí por
algún campo (generalmente una clave ajena) se almacenan en una misma estructura. En este
caso el servidor intenta almacenar todas las filas que tienen el mismo valor en el campo de
agrupación en el mismo bloque.
En la implementación como índice, las filas de la tabla se mantienen ordenadas según el campo
de indexación. La estructura del índice (árbol B+) mantiene esta ordenación.
9
Práctica 5. Parte 3.
Agrupación:
Matrícula
DNI
----101
102
102
102
101
101
...
Asig
-----A41
A20
G78
N95
A56
W08
Alumno-Matrícula
Nota ...
-----10
9
8
6
9
10
Alumno
DNI
-----101
102
...
Fecha
Nombre Sexo
----------- ---05-ENE-17 Rosa
M
07-ENE-17 Ana
M
Ficheros Alumno y Matrícula
Clave de agrupamiento
(DNI)
101 Fecha
Nombre
05-ENE-17 Rosa
Asig
Nota
A41
10
A56
9
W08
10
102
Fecha
Nombre
07-ENE-17 Ana
Asig
Nota
A20
9
G78
8
N95
6
...
Sexo
M
Sexo
M
Fichero Mixto
10
La agrupación es una forma de implementación de tablas, en la que las filas de dos tablas
relacionadas entre sí por algún campo (campo de agrupación), se almacenan en una misma
estructura de datos (segmento).
En el ejemplo aparecen a la izquierda las tablas Alumno y Matrícula, y a la derecha la
implementación de ambas tablas como una agrupación.
Se puede observar cómo las filas de ambas tablas que están relacionadas por el valor del campo
de agrupación (dni) se almacenan juntas (se intentan almacenar en el mismo bloque).
La gestión de las dos tablas implementadas como una agrupación se realiza de forma
trasparente a su implementación.
10
Práctica 5. Parte 3.
Tipos de agrupación:
Campo de
agrupación
Agrupación indexada
Agrupación con dispersión
Función
direccionamiento
11
En Oracle existen dos tipos de agrupación. la agrupación indexada, y la agrupación con
direccionamiento calculado.
La diferencia entre ambos tipos de agrupación reside en el mecanismo de acceso directo a las
filas de la agrupación por el valor del campo de agrupación.
En la agrupación indexada se utiliza un índice, definido sobre el campo de agrupación, para
acceder a las filas.
Una entrada del índice de agrupación contienen un valor del campo de agrupación y un puntero
al bloque del segmento donde se almacenan las filas de ambas tablas que tienen dicho valor en
el campo.
En la agrupación con direccionamiento calculado, una función de direccionamiento calcula la
dirección del bloque a partir del valor del campo de agrupación.
Las filas de las tablas implementadas como una agrupación se almacenan en el mismo segmento.
11
Práctica 5. Parte 3.
Creación agrupación indexada:
1. Crear la agrupación.
CREATE CLUSTER alumno_clu
(dni CHAR(10))
SIZE 200
TABLESPACE DATA01;
2. Crear el índice de agrupación.
CREATE INDEX alumno_clu_idx
ON CLUSTER alumno_clu
TABLESPACE INDX01;
12
En la creación de la agrupación (cluster) el parámetro SIZE especifica el espacio necesario para
almacenar todas las filas con un mismo valor en el campo de agrupación, y en consecuencia el
número de valores distintos del campo de agrupación que podrán almacenarse en un bloque.
Si no se especifica este parámetro, entonces Oracle asume por defecto un espacio de un bloque.
12
Práctica 5. Parte 3.
Creación de agrupación con direccionamiento calculado:
1. Crear la agrupación.
CREATE CLUSTER alumno_clu
(dni CHAR(10))
SIZE 200 HASHKEYS 40000
TABLESPACE DATA01;
13
En la creación de una agrupación con direccionamiento calculado, el parámetro HASHKEYS indica
el número de valores distintos del campo de agrupación.
El parámetro SIZE tiene el mismo significado que en el caso de la agrupación indexada.
Ambos parámetros permiten al servidor determinar el número de extensiones que se deben
asignar en la creación de la agrupación.
La función de dispersión se puede definir con la función HASH IS, pero las funciones
proporcionadas por el Oracle por defecto funcionan muy bien.
13
Práctica 5. Parte 3.
Creación de las tablas en la agrupación:
3. Crear las tablas en la agrupación.
CREATE TABLE alumno
(dni CHAR(10)
CONSTRAINT alumno_pk PRIMARY KEY,
fecha DATE, nombre VARCHAR2(40),sexo CHAR(1))
CLUSTER alumno_clu(dni);
CREATE TABLE matrícula
(dni CHAR(10) REFERENCES alumno,
asig VARCHAR2(5) REFERENCES asignatura,
nota NUMBER(3),
CONSTRAINT matricula_pk PRIMARY KEY(dni,asig))
CLUSTER alumno_clu(dni);
14
14
Práctica 5. Parte 3.
Implementación de una tabla como un fichero disperso:
 La agrupación se puede utilizar para implementar una tabla
como un fichero disperso, con direccionamiento calculado.
 En este caso basta definir la agrupación e incluir en él sólo la
tabla que se desee dispersar.
 La función de direccionamiento aplicada a un valor de la clave
de direccionamiento devuelve el bloque donde se almacena
la fila con ese valor de clave.
15
15
Práctica 5. Parte 3.
Tablas implementadas como índices (TOI):
Acceso indexado a
una tabla
Acceso a una tabla
organizada como índice
ROWID
Columnas no clave
Columna clave
Cabecera de fila
16
Los índices son estructuras de datos que permiten el acceso directo y ordenado a las filas de la
tabla por un campo de indexación.
En una tabla implementada como un índice (árbol B) las filas de la tabla se almacenan en los
nodos‐hoja del índice, junto al campo de indexación (clave primaria de la tabla). Los nodos
internos sirven para organizar y distribuir los valores de la clave en el índice.
16
Práctica 5. Parte 3.
Tablas implementadas como índices (TOI):
CREATE TABLE empleado(
empno NUMBER(4) PRIMARY KEY,
nombreVARCHAR2(30)
depto NUMBER(2) REFERENCES departamento)
ORGANIZATION INDEX TABLESPACE data01
PCTTHRESHOLD 20
OVERFLOW TABLESPACE data02;
 Las filas de la tabla se almacenan como un fichero ordenado.
17
El parámetro PCTTHRESHOLD indica el porcentaje de espacio reservado en un bloque de nodo‐
hoja para almacenar una fila de la tabla.
Si una fila excede el tamaño determinado por PCTTHERESHOLD, entonces la fila es partida en
dos fragmentos, el primer fragmento se almacena en un bloque de un nodo‐hoja, y el segundo
fragmento en un bloque de desborde, ambos fragmentos están ligados por un puntero.
17
Práctica 5. Parte 3.
Desbordamiento de filas en una TOI:
Tablespace de TOI
Tablespace de desbordamiento
Bloque
Filas más grandes que
PCTTHRESHOLD
Filas de tamaño menor o igual que PCTTHRESHOLD
18
18
Práctica 5. Parte 3.
Definición de tablas en el SQL Developer:
19
19
Práctica 5. Parte 3.
Resumen:
Formato de registro
(distribución de los campos en
el registro)
Aspectos
físicos
(de los segmentos)
Formato de bloque
(distribución de los registros en
el bloque)
‒ registros de longitud variable
‒ cabecera de registro: nro. de campos
almacenados
‒ longitud de cada campo almacenada
‒ directorio (posición relativa) de los
registros en la cabecera del bloque
‒ compactación periódica del
espacio ocupado en el bloque
‒ organización extendida
(Oracle)
Directorio de bloques
(distribución de los bloques del
segmento en el tablespace)
‒ diccionario del sistema: dirección
(relativa) y tamaño (bloques) de las
extensiones en el tablespace
20
20
Práctica 5. Parte 3.
Resumen:
Fichero desordenado (segmento de tabla)
(secuencia determinada por el orden de inserción)
Fichero disperso: clúster de una única tabla
Aspectos
lógicos
(tipos de segmentos)
(segmento de agrupación)
(secuencia determinada por una función de direccionamiento)
Fichero mixto: clúster de varias tablas
(segmento de agrupación)
(Diseñador de
la BD)
(secuencia determinada por la relación entre campos de dos tablas)
Fichero ordenado: tabla implementada como índice
(segmento de índice)
(secuencia determinada por el campo de indexación)
21
21
Tecnología de Bases
de Datos
Práctica 6
Optimización de consultas en
Oracle
Profesores: Laura Mota y Mª José Vicent
Curso: 2019‐2020
1
Práctica 6.
Objetivos:
 Conocer la estrategia de optimización de Oracle: basada en
reglas y en costes.
 Conocer las operaciones básicas que intervienen en la
ejecución de una consulta.
 Conocer las estructuras físicas que intervienen en las
decisiones del optimizador.
 Conocer la forma de intervenir en las decisiones del
optimizador (HINT).
 Saber cómo hacer un buen uso de la optimización.
2
2
Práctica 6.
Introducción al optimizador en Oracle:
 A partir de la versión 12c, el optimizador de Oracle es adaptativo:
el plan de ejecución diseñado ante una consulta puede cambiarse
durante la ejecución de la misma usando estadísticas más afinadas
de los datos que se detectan en tiempo de ejecución.
 El optimizador usa este método si el parámetro
OPTIMIZER_ADAPTIVE_FEATURES es TRUE.
 Cambio del valor del parámetro:
 Conectado como sys ejecutar:
ALTER SYSTEM
SET optimizer_adaptive_features=FALSE
scope=BOTH;
 Desde el el SQL Plus Apagar el servidor (shutdown) y levantarlo
de nuevo (startup).
3
Las prácticas de optimización se van a hacer sin tener activada la opción de adaptación de
planes. Esta opción, muy útil por otra parte, complica mucho la comprensión de los conceptos
básicos del optimizador que es el objetivo de la práctica.
3
Práctica 6.
Introducción al optimizador en Oracle:
 El plan de ejecución indica:
 Las tablas a las que se accede y la forma de acceso (camino
de acceso).
 El orden de las operaciones.
 El método de concatenación.
4
4
Práctica 6.
Introducción al optimizador en Oracle:
 Cómo se visualiza el plan de ejecución:
 Con la herramienta SQL Developer:
• En una Hoja de Trabajo SQL se escribe la consulta.
• Con el botón superior "Explicación del Plan".
• El plan aparece en la ventana de salida "Explicación del
Plan".
• En Herramientas>Preferencias‐‐Bases de Datos >
Rastreo Automático/Explicación del Plan se configura la
información que se muestra.
5
El plan propuesto por Oracle también puede visualizarse en una Hoja de Trabajo SQL se escribe
la consulta precedida de EXPLAIN PLAN FOR. Una vez ejecutada la consulta, el plan puede
visualizarse haciendo uso de la función DISPLAY del paquete administrativo DBMS_XPLAN.
5
Práctica 6.
Introducción al optimizador en Oracle:
Configuración de la pantalla
de Explicación del Plan
6
La segunda alternativa para visualizar el plan se muestra en la figura de abajo:
6
Práctica 6.
Introducción al optimizador en Oracle:
 En el plan de ejecución se obtiene la siguiente información:
 Operación: acceso a tabla, acceso a índice,…
 Objeto al que se le aplica la operación.
 Opción elegida.
 Coste estimado: que permite comparar varias opciones (no
es ni tiempo ni bloques).
 Cardinalidad esperada del resultado.
7
7
Práctica 6.
Caminos de acceso a tablas y concatenación de tablas:
 Existen diferentes formas de resolver una consulta
 Distintos caminos de acceso a las tablas.
 Distintas alternativas para ejecutar las concatenaciones de
tablas.
8
Las consultas en SQL se pueden resolver internamente de muchas formas posibles. De todas las
operaciones que pueden aparecer en una consulta analizaremos dos tipos:
• Operaciones que se resuelven accediendo a una única tabla: selección, ordenación,
agrupación, etc. Para resolver estas operaciones existen distintas alternativas, dependiendo
de los caminos de acceso a la tabla disponibles.
• Operaciones que se resuelven accediendo a más de una tabla: estas operaciones requieren la
concatenación de dos o más tablas. Existen diversas alternativas para realizar la
concatenación de tablas.
8
Práctica 6.
Caminos de acceso a una tabla:
 Distintas formas de acceder a las filas de una tabla
 FULL: barrido completo de tabla (acceso a todas las filas de
la tabla en secuencia).
 Acceso por ROWID proporcionado por un índice definido
sobre la tabla:
• BY ROWID: por cada entrada del índice se accede a la
fila de la tabla.
• BY INDEX ROWID BATCHED: se recuperan unos cuantos
ROWID del índice, se ordenan y luego se accede a las
filas con esto se pueden reducer los accesos a los
bloques de las filas de la tabla.
9
En Oracle pueden existen varios caminos de acceso a las filas de una tabla. Algunos de ellos
dependen de la existencia o no de índices definidos sobre la tabla que sean utilizables para la
ejecución de la consulta.
9
Práctica 6.
Barrido completo de una tabla:
 Se usa cuando:
 Por la forma de la consulta la tabla debe ser revisada
completamente (SELECT * FROM tabla).
 La tabla es pequeña (centenares de bloques).
 No hay índices útiles para la consulta.
 Hay índices útiles para la consulta, pero el número
esperado de filas a recuperar es tan alto que el coste de
usar los índices es superior al coste de hacer un barrido
completo de la tabla.
10
El Barrido Completo se usa en distintas circunstancias como se comenta en la transparencia. Es
conveniente aclarar el último caso. Esto significa que, en el índice, muchas entradas cumplirán la
condición de la búsqueda y para cada una de ellas habrá que recuperar la fila asociada. Es decir,
para cada entrada habrá que recuperar, en principio, un bloque diferente de la tabla donde esta
la correspondiente fila. Esto implica que el número total de bloques accedidos será mayor que si
se realizara un barrido completo de la tabla, siendo, por lo tanto, más caro el uso del índice.
10
Práctica 6.
Barrido completo de una tabla:
• Like '%...' no puede usar índices
• La tabla Empleados tiene 107 filas.
• El optimizador estima que van a ser devueltas 2 filas.
11
Existen algunas condiciones en las que no se puede hacer uso de los índices:
• Operador LIKE.
• Condiciones en las que en uno de los operandos aparece una función sobre una
columna.
• Cuando el factor de agrupación es alto y tiende a ser igual que el número de filas de
la tabla
• Cuando es un índice de baja selectividad.
11
Práctica 6.
Recorrido de un índice:
 Hay distintas maneras de buscar las entradas deseadas en un
índice:
 UNIQUE SCAN: acceso a una entrada en un índice único.
 RANGE SCAN: barrido de rango en un índice recuperando
todas las entradas que cumplen la condición.
 SKIP SCAN: recorrido no completo de un índice
multicolumna (compuesto) sin conocer algunos de los
valores de las primeras columnas.
 FULL SCAN: recorrido completo de todas las entradas del
índice.
12
12
Práctica 6.
UNIQUE SCAN: índice único sobre employee_id
13
•
•
Con el índice sobre employee_id se encuentra el ROWID de la fila (como mucho una) con
ese valor en ese atributo.
Se encuentra la fila de Empleado usando ese ROWID.
13
Práctica 6.
RANGE SCAN: índice no único sobre job_id
14
• Con el barrido del índice se encuentra las entradas que cumplen la condición, de igualdad
que, como el índice no es único, pueden ser varias.
• A partir de esas entradas, y con el ROWID de las filas, se realiza una búsqueda por ROWID en
la tabla.
14
Práctica 6.
FULL SCAN: índice no único sobre last_name+first_name
15
En este caso, no hace falta realizar la búsqueda por ROWID en la tabla, ya que las columnas de la
selección están todas en los registros del índice.
En el ejemplo, la clave del índice “NOMBRE_ISDX" está compuesta por "last_name“ y
"first_name” por tanto para resolver la consulta basta realizar un barrido completo sobre este
índice.
Existe otra opción de recorrido completo del índice :
• FAST FULL SCAN: es más rápido que el FULL SCAN por cómo realiza la I/O de los bloques.
15
Práctica 6.
SKIP SCAN: índice no único sobre manager_id+department_id
16
• No se proporciona valor para la primera columna del índice compuesto
(manager_id,department_id) , pero aún así se resuelve la consulta sin recorrer todo el índice.
• Esta opción es mejor que el FULL SCAN ya en principio no recorre todo el índice sino que
ejecuta la consulta para los distintos valores de la primera columna (manager_id) y luego
hace la unión de las resultados obtenidos.
16
Práctica 6.
Concatenación:
 Para realizar la concatenación el optimizador decide:
 Orden de concatenación: a qué tabla se accede primero y a
qué tabla se accede en segundo lugar
 Método de concatenación:
• Bucles anidados (NESTED LOOPS)
• Por fusión (MERGE JOIN)
• Por direccionamiento calculado (HASH JOIN)
17
La concatenación se realiza en diversos tipos de consultas:
• FROM con varias tablas y condición en el WHERE con una comparación que permite realizar la
concatenación.
• JOIN en el FROM.
• Subconsultas que se resuelven con una concatenación entre una de las tablas de la consulta
externa y una de la subconsulta.
Hay que observar que en Oracle no existe el método de bucle único comentado en Tema 9.
17
Práctica 6.
NESTED LOOPS: bucles anidados
 Para cada fila en la tabla del bucle externo:
 Buscar todas las filas de la tabla del bucle interno que
coinciden.
 A veces en vez de una tabla se puede usar un índice para
realizar el recorrido.
18
18
Práctica 6.
NESTED LOOPS: bucles anidados
• En el bucle externo se recorre Clientes.
• En el bucle interno, para cada cliente se recorre Ventas.
19
En este ejemplo se ha usado una pista (HINT) para forzar el uso de de bucles anidados. Estas
pistas se verán más adelante.
19
Práctica 6.
MERGE JOIN: fusión
 Ordenar cada tablas sobre las columnas de la concatenación.
 Recorrer las tablas ordenadas y de una pasada realizar la
concatenación
 Si una de las dos tablas tiene un índice sobre la columna de
concatenación se evita una ordenación y es más probable que
se elija este método.
20
20
Práctica 6.
MERGE JOIN: fusión
• Se ordenan (SORT) las tablas Clientes y Ventas.
• Se funden las tablas ordendas (MERGE JOIN)
21
En este ejemplo se ha usado una pista (HINT) para forzar la concatenación por fusión. Estas
pistas se verán más adelante.
21
Práctica 6.
HASH JOIN: concatenación por direccionamiento calculado
 Con la tabla más pequeña se crea en memoria una tabla hash
basada en la clave de concatenación.
 La tabla más grande se recorre en una barrido completo y para
cada una de sus filas se busca en la tabla hash las filas que
coinciden.
22
22
Práctica 6.
HASH JOIN: concatenación por direccionamiento calculado
• Se crea una tabla hash para Clientes (para ello hace un recorrido completo de
la tabla).
• Se recorre Ventas con un barrido completo.
23
En este ejemplo no se ha usado ninguna pista (HINT) porque es el método elegido por Oracle ya
que es el método que menor coste supone.
23
Práctica 6.
Funcionamiento y configuración del optimizador en Oracle:
 A partir de Oracle 12c, es un AQO (Adaptive Query Opimizer).
 Con el parámetro OPTIMIZER_ADAPTIVE_FEATURES a falso e un
CBO (Cost Based Optimizer) pero también con aspectos
heurísticos.
 Su comportamiento depende de:
 Parámetro inicialización OPTIMIZER_MODE.
 Estadísticas en el diccionario de datos.
 Pistas (HINTS).
24
24
Práctica 6.
Parámetro OPTIMIZER_MODE:
 Los valores más relevantes son:
 ALL_ROWS: valor por defecto
• El optimizador funcionará basado en costes para todas las
instrucciones que se ejecuten.
• Orientado a obtener todas las filas con el menor gasto de recursos
• Adecuado para sistemas no afinados y con procesos en lotes que
manejan grandes volúmenes
 FIRST_ROWS:
• El optimizador usa una mezcla de costes y heurístico para encontrar
el mejor plan para una respuesta rápida de la primeras filas.
• Adecuado para sistemas que procesan muchas transacciones
pequeñas.
25
Otros valores:
• FIRST_ROWS_1, FIRST_ROWS_10, FIRST_ROWS_100, FIRST_ROWS_1000: El
optimizador funcionará basado en costes y optimiza con el objetivo de el mejor
tiempo de respuesta para obtener las filas indicadas.
25
Práctica 6.
Estadísticas:
 El optimizador intenta estimar el coste real de ejecutar las
instrucciones (cpu, memoria, operaciones, i/o, etc.).
 Usa estadísticas almacenadas para los distintos objetos que
intervienen en la ejecución de las operaciones para estimar el
coste.
 Tipos de estadísticas:
 De tabla.
 De columna.
 De índice.
 Histogramas de columna.
26
Las estadísticas de Histograma de columna no se van a ver.
26
Práctica 6.
Estadísticas de tabla:
 Estadísticas de tabla incluyen:
 Número de filas.
 Número de bloques.
 Número de bloques libres.
 Longitud promedio de la fila.
 Número de filas encadenadas.
 …
 Se pueden consultar en la vista USER_TAB_STATISTICS
27
27
Práctica 6.
Estadísticas de columna:
 Estadísticas de columna incluyen:
 Valor mínimo.
 Valor máximo.
 Número de valores distintos.
 Densidad: tiene que ver con la selectividad, se usa en las concatenaciones.
 Número de nulos.
 Número de cubos.
 …
 Se pueden consultar en la vista USER_TAB_COL_STATISTICS
28
28
Práctica 6.
Estadísticas de índice:
 Estadísticas de índice incluyen:
 Nivel del B‐árbol.
 Número de bloques hojas.
 Número de claves distintas.
 Promedio de bloques hoja por valor de clave.
 Promedio de bloques de datos por valor de clave.
 Número de entradas.
 …
 Se pueden consultar en la vista USER_IND_STATISTICS
29
29
Práctica 6.
Recopilación de estadísticas:
30
La recopilación de estadísticas también puede hacerse manual mediante la instrucción
ANALYZE TABLE…
30
Práctica 6.
HINTS: pistas
 Las instrucciones pueden incluir pistas para dirigir al optimizador.
 Se incluyen en las instrucciones de acceso: SELECT, UPDATE,
INSERT, DELETE.
 Las pistas empiezan con /*+ y terminan con */
 Pueden incluirse en subconsultas y en vistas.
 El optimizador ignora las pistas si:
 No tienen sentido en la instrucción.
 Entran en conflicto entre ellas.
 No tienen una sintaxis correcta.
31
31
Práctica 6.
HINTS: pistas
 Pistas sobre el camino de acceso:
 FULL: barrido completo de tabla.
 ROWID: acceso a tabla por el ROWID de una fila.
 HASH: barrido por direccionamiento calculado (sólo para tablas agrupadas).
 INDEX: acceso a tabla usando un índice.
 …
 Pistas sobre la concatenación:
 ORDERED: fuerza a concatenar las tablas en el orden que aparecen en la
cláusula FROM.
 USE_MERGE, USE_NL, USE_HASH: indica la forma de realizar la
concatenación.
32
Otras pistas:
•
Pistas sobre el modo global del optimizador: ALL_ROWS, FIRST_ROWS, FIRST_ROWS_10,
…: el efecto es el mismo que se vio para el parámetro de inicialización OPTIMIZER_MODE,
pero para la instrucción donde se incluir la pista.
•
Pistas de transformación de consultas:
• USE_CONCAT: reescribe una consulta OR en una UNION ALL
• MERGE: fusiona una vista en una consulta
• NO_MERGE: deshabilita barrido de agrupación (sólo para tablas agrupadas)
32
Práctica 6.
Reglas básicas para la optimización:
1. Comprueba el plan de ejecución de la instrucción:
 Actualizar las estadísticas.
 Crear índices.
 Proporcionar pistas al optimizador: sólo si se tiene claro.
2. Comprueba la salida AUTOTRACE.
3. Instrucciones de con un uso intensivo.
4. Resolviendo problemas típicos.
33
33
Práctica 6.
AUTOTRACE: SQL Developer
Conectado como sys
34
34
Práctica 6.
AUTOTRACE: información obtenida
 recursive calls: número de instrucciones adicionales SQL fueron
ejecutadas.
 db block gets: número de bloques que fueron procesados (lectura)
en memoria en acceso actual (current).
 physical reads: número de bloques leídos del disco.
 redo size: cantidad de información de deshacer generada.
 bytes enviados y recibidos vía SQL*NET.
 sorts: ordenaciones en memoria y en disco.
 rows processed: número de filas procesadas para la instrucción.
35
En la transparencia se muestran algunas de las informaciones obtenidas, no todas.
35
Práctica 6.
Reglas básicas de optimización:
 Instrucción SELECT de computación larga:





Gran número de llamadas recursivas (subconsultas complejas).
Gran número de recuperaciones consistentes.
Gran número de lecturas físicas: mucho uso del disco.
Gran número de datos recibidos por la red: mucho uso de la red.
Muchas ordenaciones.
 Solución:
 Gran número de lecturas físicas:
• La cache BD es muy pequeña: ampliarla.
• Muchos rastreos completos en las consultas: crear índices.
 Gran cantidad de datos recibidos por la red:
• Los resultados de las consultas los procesa el cliente: revisar la
configuración de la conexión entre cliente y servidor.
 Muchas ordenaciones:
• Existen ORDER BY, GROUP BY, DISTINCT en una consulta sobre una tabla
sin índices: crear índices sobre los atributos relevantes.
36
36
Práctica 6.
Reglas básicas de optimización:
 Instrucción UPDATE o DELETE de computación larga:
 Gran número de recuperaciones de bloques.
 Gran número de lecturas físicas: mucho uso del disco.
 Generación de mucha información de deshacer.
 Solución:




Dividir la instrucción en varias transacciones.
Ejecutar la instrucción como una instrucción por lotes cuando haya poca
carga.
Considerar la reconstrucción de la aplicación que ejecuta dicha instrucción.
Comprobar si la condición del WHERE es compleja y de ejecución larga.
37
37
Tecnología de Bases
de Datos
Práctica 7
Seguridad en Oracle
Profesores: Laura Mota y Mª José Vicent
Curso: 2019‐2020
1
Práctica 7.
Objetivos:
 Estudiar los recursos para la definición de la seguridad en
Oracle: usuarios, privilegios, roles y perfiles.
 Estudiar la creación de usuarios.
 Estudiar la concesión de privilegios: tipos de privilegios y
concesión con el uso de roles.
 Estudiar la utilidad de los perfiles: control de recursos del
sistema y de palabras de paso.
2
Los contenidos necesarios para la realización de esta práctica se desarrollan en el Tema 5 del
programa de teoría.
2
Práctica 7.
Seguridad en Oracle:
Privilegios
directos
Tablespace
por defecto
Privilegios
por roles
Tablespace
temporal
USUARIOS
Bloqueo de
cuentas
Palabras de
paso
Cuotas en
tablepaces
Límites de
recursos
3
La gestión de la seguridad en un servidor Oracle comprende todos los aspectos relacionados con
la creación de usuarios:
• Gestión de contraseñas (tiempo de expiración, intentos fallidos en el uso de la contraseña,
complejidad de la contraseña, reutilización de contraseñas, …)
• Restricciones en el uso de recursos del sistema por parte del usuario (CPU, sesiones abiertas,
tiempo de conexión, operaciones de lectura, …)
• Concesión de privilegios (permisos) a los usuarios para realizar acciones en el servidor:
privilegios genéricos, o privilegios sobre objetos de usuario.
• Asignación de espacio en disco a los usuarios.
3
Práctica 7.
Usuario: esquema de base de datos
 En Oracle no existe el concepto de esquema de base de datos
relacional.
 Todos los objetos creados por un usuario constituyen su
esquema de base de datos.
usuario  esquema
 Nominación de los objetos de un esquema (usuario):
usuario.objeto
4
Como ya se ha comentado en otras ocasiones, en Oracle no existe el concepto de esquema de
base de datos relacional.
Se entiende por esquema de base de datos (de un usuario), el conjunto de todos los objetos de
los que un usuario es propietario.
4
Práctica 7.
Usuario: tipos de objetos en su esquema
 Tablas:
 Disparadores.
 Restricciones.
 Índices.
 Vistas.
 Secuencias.
 Unidades de programación almacenadas (PL/SQL).
 Tipos de datos definidos por el usuario.
…
5
Oracle es un SGBD relacional, y por lo tanto los tipos de objetos de base de datos que puede
crear un usuario son los comunes en bases de datos relacionales: tablas, vistas, disparadores, …
5
Práctica 7.
Usuario: elementos asociados
 Palabra de paso.
 Tablespace por defecto: tablespace donde se almacenarán los
objetos del usuario cuando éste no especifica explícitamente
otro tablespace en la creación.
 Tablespace temporal: tablepace utilizado por los procesos
servidores de las sesiones del usuario para realizar tareas de
ordenación de datos.
 Cuotas en los tablespace de tablas: limitan el espacio que el
usuario puede utilizar en los tablespace que tiene asignados.
 Privilegios: directos y por roles.
 Perfil: límites en el uso de recursos del sistema.
6
Un usuario puede ser creado por un usuario que tenga el correspondiente privilegio de
sistema (CREATE USER) o por un usuario administrador (con el rol DBA que incluye
todos los privilegios de sistema).
Instrucción SQL:
CREATE USER usuario
IDENTIFIED BY contraseña
[DEFAULT TABLESPACE tablespace]
[TEMPORARY TABLESPACE tablespace]
[QUOTA {entero|UNLIMITED} ON tablespace]…
[PASSWORD EXPIRE] [ACCOUNT {LOCK |UNLOCK}]
[PROFILE {perfil|DEFAULT}]
6
Práctica 7.
Usuario: creación en SQL Developer
7
En el asistente de creación (Crear Nueva) de un usuario en SQL Developer, en la pestaña de
información general (Usuario), se puede especificar:
• Nombre del usuario.
• Contraseña (inicial).
• Vencimiento (opcional) de la contraseña para que el usuario la cambie al conectarse por
primera vez.
• Bloqueo (opcional) de la cuenta de usuario, el administrador deberá desbloquearla para que
el usuario la pueda utilizar.
• Tablespace por defecto.
• Tablespace temporal.
Una vez creado un usuario, estos parámetros se pueden cambiar con la opción Editar, el usuario
se puede borrar con la opción Borrar Usuario. Algunos de los parámetros se pueden cambiar
discrecionalmente.
7
Práctica 7.
Perfil:
 Conjunto de restricciones (límites) de uso de los recursos del
sistema y de la palabra de paso del usuario.
 Se asigna al usuario en su creación o en su modificación.
 Puede ser un perfil por defecto (perfil DEFAULT).
Privilegios Tablespace
directos
por defecto
Privilegios
de roles
Usuarios
Tablespace
temporal
Cuotas en
tablespaces
Bloqueo de
cuentas
Palabras
de paso
Límites
recursos
Perfil
8
La definición de un perfil permite agrupar (y nominar) un conjunto de restricciones (límites) en
el uso de los recursos del sistema por parte del usuario, y unas limitaciones en el uso de la
palabra de paso del usuario.
En la transparencia siguiente se muestran algunos ejemplos de este tipo de restricciones.
Un usuario puede tener asignado un único perfil. Existe el perfil por defecto (DEFAULT). El perfil
se asigna en la creación (o modificación) del usuario.
8
Práctica 7.
Perfil: ejemplos de restricciones
Recursos del sistema
Palabra de paso
(sesión de usuario)
(usuario)
Tiempo de conexión
Tiempo de vida
Tiempo de CPU
Nro. de intentos
Tiempo de inactividad
Función de verificación de contraseñas
Nro. de bloques de datos leídos
Bloqueo de cuentas
…
…
9
9
Práctica 7.
Perfil: SQL Developer
10
10
Práctica 7.
Perfil: asociación a un usuario
 En SQL Developer no se puede asignar un perfil a un usuario a
través de sus herramientas, hay que utilizar la instrucción
ALTER USER nom_perfil PROFILE nom_usuario
desde una hoja de trabajo de un usuario administrativo.
 Al borrar un perfil, todos los usuarios que lo tuvieran asignado
pasarían a tener el perfil DEFAULT.
11
11
Práctica 7.
Privilegios:
 Un privilegio es un permiso concedido al usuario para realizar
un tipo de acción en el servidor.
 Tipos de privilegios:
• Privilegios de sistema: permiten a los usuarios realizar
acciones (genéricas) en el servidor.
• Privilegios de objeto: permiten a los usuarios realizar
operaciones sobre objetos de datos de usuarios.
12
Un privilegio es un permiso concedido a un usuario para realizar un tipo de acción (operación)
en el servidor.
Las acciones pueden ser relativas a la sesión de trabajo, o a objetos de base de datos.
Los privilegios pueden ser genéricos (de sistema), es decir independientes de cualquier objeto
(Ej. El privilegio de crear tablas: CREATE TABLE), o específicos (de objeto) para un objeto
concreto (Ej. El privilegio de hacer inserciones en tabla1 del usuario usuario1: INSERT ON
usuario1.tabla1).
Los privilegios se pueden conceder y revocar a los usuarios dinámicamente.
En SQL las instrucciones para otorgar y revocar privilegios son:
• Instrucción GRANT: permite otorgar un privilegio a un usuario o a un grupo de usuarios:
GRANT privilegio,… TO usuario, …
• Instrucción REVOKE: permite revocar un privilegio otorgado a un usuario o a un grupo de
usuarios: REVOKE privilegio, … FROM usuario, …
12
Práctica 7.
Privilegios de sistema:
 Los privilegios de sistema son genéricos, es decir
independientes del objeto.
 Existen unos 80 privilegios de sistema:
• Acciones relativas a la sesión del usuario (Ej. CREATE
SESSION).
• Acciones relativas a objetos de base de datos (Ej. CREATE
VIEW).
 ANY: esta opción permite realizar la acción en cualquier
esquema de usuario. (Ej. CREATE ANY TABLE).
13
Un usuario puede recibir privilegios de sistema de un usuario administrador (o con
privilegio para la creación de usuarios) durante la creación o la modificación del usuario.
Para que un usuario (no autorizado para crear usuarios) pueda conceder un privilegio
de sistema a otro usuario, debe haber recibido ese mismo privilegio con opción de
trasferencia : WITH ADMIN OPTION en SQL (opción Admin en SQL Developer).
GRANT privilegio, … TO usuario, …
WITH ADMIN OPTION
La revocación de un privilegio de sistema, concedido con opción de trasferencia, no
tiene efecto en cascada, es decir no implica la revocación de dicho privilegio a los
usuarios que lo han recibido transitivamente.
13
Práctica 7.
Privilegios de sistema: Ejemplos
Categoría
Ejemplos de privilegio
Index
CREATE ANY INDEX
ALTER ANY INDEX
DROP ANY INDEX
Table
CREATE TABLE
CREATE ANY TABLE
ALTER ANY TABLE
DROP ANY TABLE
SELECT ANY TABLE
UPDATE ANY TABLE
DELETE ANY TABLE
Session
CREATE SESSION
ALTER SESSION
RESTRICTED SESSION
Tablespace
CREATE TABLESPACE
ALTER TABLESPACE
DROP TABLESPACE
UNLIMITED TABLESPACE
…
…
14
14
Práctica 7.
Privilegios de sistema: SQL Developer
15
En el asistente para la creación (o modificación) de un usuario, en la pestaña Privilegios de
Sistema se pueden asignar al usuario los privilegios que se desee con (opcional) opción de
trasferencia (Admin).
15
Práctica 7.
Privilegios de sistema: SQL Developer
16
En el asistente para la creación (o modificación) de un usuario, en la pestaña Privilegios de
Sistema se pueden asignar al usuario los privilegios que se desee con (opcional) opción de
trasferencia (Admin).
16
Práctica 7.
Privilegios de sistema: SQL Developer
17
En el asistente para la creación (o modificación) de un usuario, en la pestaña Privilegios de
Sistema se pueden asignar al usuario los privilegios que se desee con (opcional) opción de
trasferencia (Admin).
17
Práctica 7.
Privilegios de objeto: Ejemplos
Privilegio
Tabla
ALTER

DELETE

Vista
Secuencia
Procedimiento



EXECUTE
INDEX

INSERT

REFERENCES

SELECT


UPDATE




Los privilegios de objeto permiten a los usuarios realizar operaciones sobre
objetos de base de datos de los usuarios.
18
Los privilegios de objeto permiten realizar operaciones sobre objetos de base de datos de
usuarios.
El propietario del objeto puede otorgar y revocar estos permisos.
Para que un usuario (no propietario del objeto) pueda conceder un privilegio sobre un objeto a
otro usuario, debe haber recibido ese mismo privilegio con opción de trasferencia: WITH GRANT
OPTION en SQL (opción Otorgar en SQL Developer).
GRANT operación, … TO usuario, …
WITH GRANT OPTION
La revocación de un privilegio de objeto, concedido con opción de trasferencia, tiene un efecto
en cascada, es decir implica la revocación del mismo privilegio a todos los usuarios que lo han
recibido transitivamente.
18
Práctica 7.
Privilegios de objeto: SQL Developer
19
En SQL Developer el propietario de un objeto, en la ventana de navegación de esquemas, puede
otorgar (Otorgar) o revocar (Revocar) privilegios (Privilegios) sobre el objeto, a otros usuarios.
Para que un usuario (no propietario del objeto) pueda conceder un privilegio sobre un objeto a
otro usuario, debe haber recibido ese mismo privilegio con opción de trasferencia: WITH GRANT
OPTION en SQL (opción Otorgar en SQL Developer).
GRANT operación, … TO usuario, …
WITH GRANT OPTION
La revocación de un privilegio de objeto, concedido con opción de trasferencia, tiene un efecto
en cascada, es decir implica la revocación del mismo privilegio a todos los usuarios que lo han
recibido transitivamente.
19
Práctica 7.
Privilegios de objeto: SQL Developer
20
20
Práctica 7.
Privilegios de objeto: SQL Developer
21
21
Práctica 7.
Rol:
 Un rol es un conjunto nominado de privilegios (de sistema o de
objeto), y/o roles.
 La definición de un rol simplifica la tarea de concesión y gestión
de privilegios de los usuarios.
 Un rol puede ser creado por un usuario con el correspondiente
privilegio de sistema (CREATE ROLE) o un administrador (rol
DBA).
22
En SQL las instrucciones para otorgar y revocar roles a los usuarios son:
Instrucción GRANT: permite otorgar un rol a un usuario o a un grupo de usuarios
Instrucción REVOKE: permite revocar un rol otorgado a un usuario o a un grupo de usuarios.
GRANT rol,… TO usuario, …
REVOKE rol, … FROM usuario, …
Un rol se puede conceder a un usuario con opción de trasferencia, WITH ADMIN OPTION en
SQL, con el mismo significado que en la concesión de privilegios de sistema.
GRANT rol, … TO usuario, … WITH ADMIN OPTION
Un rol puede ser borrado por su creador o por cualquier usuario que lo haya recibido con opción
ADMIN.
Instrucción SQL: DROP ROL
22
Práctica 7.
Rol: ejemplos
Usuarios
A
Rol_Dirección
Roles
Privilegios
SELECT
ON EMP
CREATE
TABLE
C
B
Rol_Empleado
INSERT
ON EMP
CREATE
SESSION
Rol: conjunto de privilegios (de sistema o de objeto)
UPDATE
ON EMP
23
23
Práctica 7.
Rol: beneficios
 Simplifican la asignación discrecional de privilegios a los
usuarios.
 Permiten una gestión de privilegios dinámica.
 Ofrecen una disponibilidad de privilegios selectiva.
 Revocación no en cascada.
24
La definición de roles en el servidor tiene las siguientes ventajas:
• Simplifican la concesión discrecional de privilegios: usuarios con las mismas características de
uso del servidor, pueden recibir el mismo conjunto de privilegios a través de un rol.
• Gestión de privilegios dinámica: si para un colectivo de usuarios se desea modificar el
conjunto de privilegios concedidos, el uso de un rol permite hacer este cambio de una forma
centralizada.
• Disponibilidad de privilegios selectiva: los privilegios concedidos a un usuario, por medio de
un rol, se pueden revocar temporalmente deshabilitando el rol y volviéndolo a habilitar más
tarde.
• Revocación no en cascada: la revocación de un rol no provoca la revocación en cascada de
los privilegios de objeto incluidos en el rol.
24
Práctica 7.
Rol: SQL Developer
25
En la creación del rol (Crear Nueva) se especifican los privilegios de sistema y (otros) roles que
componen el rol.
En la creación de un rol se puede especificar (opcional) una contraseña para identificarse en la
habilitación y deshabilitación del rol.
25
Práctica 7.
Roles predefinidos en Oracle:
Nombre del rol
Descripación
CONNECT
Permite la conexión al servidor.
RESOURCE
Permite la creación de objetos (tablas,
índices,…).
DBA
Reúne todos los privilegios de sistema.
Estos privilegios los puede transmitir
(tiene WITH ADMIN OPTION).
…
…
26
Los tres roles predefinidos que aparecen en la trasparencia son los más utilizados en Oracle.
Los roles CONNECT y RESOURCE son los roles básicos que debe poseer un usuario para realizar
tareas básicas de base de datos.
Un usuario con el rol DBA tiene todos los privilegios de sistema con opción de trasferencia, es un
usuario administrador.
26
Práctica 7.
Rol: roles por defecto del usuario
27
Los roles asignados a un usuario (en la creación o modificación) con la opción Valor por defecto
(DEFAULT) son habilitados automáticamente cuando el usuario se conecta al servidor.
En la creación del usuario (Crear Nuevo) todos los roles asignados al usuario serán con valor por
defecto. En la modificación del usuario (Editar) esta propiedad se puede cambiar.
27
Práctica 7.
Rol: habililtar y deshabilitar roles
 Habilitar y deshabilitar roles en la sesión de usuario.
 Deshabilitar un rol para revocar temporalmente privilegios.
 Habilitar un rol para obtener temporalmente privilegios.
 Instrucción SQL: SET ROLE
 Los roles por defecto se habilitan en la conexión.
 Si el rol tiene palabra de paso se solicitará en el momento de su
habilitación manual (SET ROLE).
28
Durante la sesión de trabajo, el usuario puede habilitar y deshabilitar los roles que tiene
concedidos, con el efecto de disponer o perder temporalmente algunos privilegios.
Instrucción SQL: SET ROLE rol [IDENTIFIED BY contraseña]
28