Unidad Didáctica 4 Gestión del Espacio Físico
UNIDAD DIDÁCTICA 4
Gestión del espacio físico
Índice 1. Estructuras de almacenamiento 1.1. Visión general de las estructuras de almacenamiento 2. Tablespaces 2.1. Tablespaces permanentes 2.2. Tablespaces temporales 2.3. Tipos de tablespaces permanentes 2.4. Tablespace UNDO 2.5. Tablespaces por defecto 2.6. Gestión de extensiones 2.7. Disponibilidad de los Tablespaces 2.8. Tablespace de solo lectura 2.9. Obtener información de los Tablespaces 2.10. Cálculo del tamaño de la base de datos en Oracle 10g 3. Bloques, extensiones y segmentos 3.1. Bloques 3.2. Extensiones 3.3. Segmentos 4. Métodos de acceso a datos 4.1. Indices 4.2. Indices de clave inversa 4.3. Arboles B 4.4. Mapa de bits 4.5. Tablas organizadas como índices 4.6. Cluster 4.7. Hash cluster 4.8. Particiones
Esquema de contenidos:
Introducción Introducción Oracle dispone de un sistema de almacenamiento propio que, aunque se coordina con el SO, se mantiene ajeno a él. Este sistema emplea unidades de almacenamiento propias, cada una diseñada para cumplir una misión concreta. En esta unidad nos centraremos en los siguientes aspectos básicos de Oracle 10g: •
Estructuras Lógicas de Almacenamiento
•
Gestión del Almacenamiento
•
Métodos de Acceso a la información de la BBDD.
Al finalizar cada lección se plantearán una serie de ejercicios prácticos que inciden en los conceptos presentados y refuerzan su aprendizaje, intentar su resolución y trabajarlos es primordial para conseguir los objetivos fijados en esta unidad.
Objetivos Comprender: -
Estructuras lógicas de almacenamiento utilizadas por Oracle 10g.
-
Relaciones existentes entre las diferentes estructuras lógicas.
-
Gestión del almacenamiento de la información en un SGBD Oracle 10g.
-
Herramientas de administración incluidas en Oracle 10g para la gestión del espacio en disco.
-
Métodos de acceso a datos que soporta Oracle 10g para optimizar el acceso a la información.
Lección 1
Estructuras de almacenamiento
Índice 1.1. Visión general de las estructuras de almacenamiento
Introducción En esta lección se introducen las estructuras lógicas de almacenamiento utilizadas por Oracle10 g. En segundo lugar se describen las relaciones existentes entre ellas y con las estructuras físicas a las que se conectan para almacenar la información. Al finalizar se incluyen una serie de ejercicios de auto evaluación para comprobar los conocimientos aprendidos.
Objetivos Comprender: -
Estructuras lógicas de almacenamiento utilizadas por Oracle 10g.
-
Relaciones de las estructuras lógicas y físicas en Oracle 10g.
-
Relaciones existentes entre las diferentes estructuras lógicas.
Apartado 1.1: Visión general de las estructuras de almacenamiento 1. TABLESPACES Oracle dispone de un sistema de almacenamiento propio que, aunque se coordina con el SO, se mantiene ajeno a él. Este sistema emplea unidades de almacenamiento propias, cada una diseñada para cumplir una misión concreta. Al mantener un catálogo lógico de todos los objetos que componen la base de datos, Oracle 10g puede conocer, en todo momento de cuánto espacio dispone, dónde se encuentran los objetos y cuanto espacio necesita para realizar el almacenamiento de los datos. Las estructuras de almacenamiento en Oracle10g son los bloques, las extensiones, los segmentos y los tablespaces. Desde el punto de abstracción de más alto nivel, Oracle 10g almacena los objetos de los esquemas lógicamente en espacios de tablas o tablespaces y físicamente en ficheros de datos, los cuales tienen que ir asociados al tablespace correspondiente. Una BBDD Oracle consiste en 2 o más tablespaces, y cada uno de ellos en uno o más ficheros de datos (estructuras físicas de almacenamiento. Cada uno de estos ficheros sólo puede estar asociado a un tablespace. Cuando se crea un objeto, por ejemplo una tabla o un índice, se puede especificar en que tablespace se almacenará, en caso de no hacerlo se guardará en el tablespace por defecto del usuario propietario del objeto. La distribución de los objetos en un tablespace asociado a una BBDD puede observarse en la siguiente figura.
Figura 1. Distribución de objetos en un tablespace
2. ESQUEMA Un esquema es un conjunto de objetos de la base de datos que pertenecen al mismo propietario. Los objetos del esquema son las estructuras lógicas que se corresponden con los datos de la BBDD. Algunos de los objetos del esquema son tablas, vistas, secuencias, procedimientos almacenados, índices, clusters, etc. Aunque puede resultar conveniente a efectos de administración, un tablespace y un esquema no tienen porque mantener una relación uno a uno. Es decir: un usuario puede crear objetos que residan en distintos tablespaces. Para acceder a los objetos de un esquema se puede anteponer el sufijo con el nombre del esquema antes del objeto. El nombre del esquema es del propietario de los objetos que contiene: nombre_esquema.nombre_objeto, por ejemplo user_aux.tabla1
3. BLOQUES Desde el punto de vista de almacenamiento de los datos, Oracle 10g guarda los datos en bloques de datos, también llamados bloques lógicos, bloques Oracle o páginas (ver Figura 2).
Figura 2. Distribución de estructuras lógicas en Oracle 10g
Los bloques son la unidad mínima de asignación espacio y consisten en número determinado de bytes contiguos en disco. Una vez asignado un objeto, un bloque jamás contendrá filas de otro objeto. El número de filas que contiene
bloque depende de las dimensiones de éste y del tamaño de las filas que contiene.
4. EXTENSIÓN El siguiente nivel lógico de almacenamiento es la extensión. Ésta es una agrupación de bloques de datos contiguos en disco dedicados a un único objeto. Es la unidad de espacio en la que se producen asignaciones de espacio, ya que se hiciera a nivel de bloque resultaría demasiado costoso y produciría demasiada fragmentación. Cada una de estas extensiones solo puede residir en un fichero de datos. Por tanto un segmento que se extiende por varios datafiles, debe estar compuesto por múltiples extensiones, ubicadas en diferentes ficheros.
5. SEGMENTO En un nivel superior a las extensiones se encuentran los segmentos. Un segmento es el conjunto lógico de todas las extensiones asignadas a un único objeto, aunque no se encuentren contiguas en disco. Cuando un segmento se satura (se queda sin espacio libre para nuevos datos), Oracle 10g le asigna una nueva extensión. Por ello, dado que el sistema asigna nuevas extensiones en función de la demanda, éstas pueden no encontrarse contiguas en disco. Estos segmentos están asociados a un único tablespace. Cada tabla se almacena en su propio segmento de datos y cada índice se almacena en su propio segmento de índice, pero si la tabla o índice se divide en particiones, cada una de ellas se almacena en su propio segmento. Finalmente, los segmentos se almacenan en tablespaces. Un tablespace puede almacenar segmentos cuyas extensiones se encuentren en más de un fichero, pero una extensión sólo puede contener datos de un fichero de datos. Gracias a esta propiedad, la base de datos es independiente del medio físico: aunque se agote el espacio físico disponible, se puede agregar ficheros al tablespace aunque ni siquiera residan en el equipo local. La relación de las estructuras lógicas y físicas en Oracle puede observarse en la Figura 3.
Figura 3. Relación entre estructuras lógicas y físicas en Oracle 10g
Conclusión En esta lección, se ha visto de manera global las estructuras lógicas y físicas de Oracle 10g. Además se han descrito las relaciones existentes entre ellas y la manera en la que conectan.
Lección 2
Tablespaces
Índice 2.1. Tablespaces permanentes 2.2. Tablespaces temporales 2.3. Tipos de tablespaces permanentes 2.4. Tablespace UNDO 2.5. Tablespaces por defecto 2.6. Gestión de extensiones 2.7. Disponibilidad de los Tablespaces 2.8. Tablespace de solo lectura 2.9. Obtener información de los Tablespaces 2.10. Cálculo del tamaño de la base de datos en Oracle 10g
Introducción En esta lección se da a conocer las estructuras lógicas de más alto nivel para el almacenamiento de información en Oracle10 g: el espacio de tablas o tablespace. Se incluye además una descripción de las herramientas disponibles en Oracle 10 g para la gestión del espacio en disco. Toda BBDD Oracle 10g se divide en unidades lógicas de almacenamiento, conocidas como espacios de tablas o tablespaces. Estos tablespaces permiten agrupar físicamente esquemas de objetos para simplificar las operaciones de administración. Cada BBDD se divide a nivel lógico en uno o más tablespaces. Los ficheros de datos son asociados de forma explicita a cada tablespace para almacenar los datos de las estructuras lógicas (tablas, índices, etc) en un tablespace. Es conveniente utilizar varios tablespaces, enfocando cada uno a una labor concreta dentro del SGBD. Las ventajas inherentes más comunes son las siguientes: •
Se podrá separar los datos de los usuarios, de los datos del DD.
•
Se podrá separar físicamente distintos tipos de objetos, por ejemplo tablas e índices.
•
Se podrán separar los datos de distintas aplicaciones.
•
Se reduce la contención de E/S del disco si existen varios tablespaces que guardan sus datafiles en distintos discos.
•
Se podrá realizar copias de seguridad de tablespaces individuales.
•
Se podrá activar y desactivar de forma independiente ciertas áreas de la BBDD, limitando así el acceso únicamente a ciertas zonas.
Objetivos -
Descripción y utilización de la estructura lógica de más alto nivel en Oracle 10g, Tablespace.
-
Herramientas de administración incluidas en Oracle 10g para la gestión del espacio en disco.
-
Calculo del tamaño de una BBDD Oracle 10g.
Apartado 2.1: Tablespaces permanentes Estos tablespaces están compuestos por ficheros de datos y pueden contener segmentos de datos y de índices. Son los tablespaces donde se guarda la información con la que trabaja el SGBD y a la que accede el usuario. La sentencia básica de creación de este tipo de tablespace es: CREATE TABLESPACE nombre_tablespace DATAFILE ruta_fichero SIZE tamaño_fichero;
Para asignar un tablespace permanente por defecto a un usuario, se puede indicar en la sentencia de creación del mismo: CREATE USER nombre_user IDENTIFIED BY clave_usuario TEMPORARY TABLESPACE nombre_tablespace.
Apartado 2.2: Tablespaces temporales Este tipo de tablespace se utiliza como espacio de almacenamiento predeterminado para los objetos temporales que Oracle 10g construye a medida que procesa instrucciones SQL. Solo pueden contener segmentos temporales (ver apartado 4) Existe una zona de memoria dentro de la instancia de Oracle destinada a la agrupación y/o ordenación de datos. Si la cantidad de memoria asignada es insuficiente para el procesamiento de ciertas operaciones implícitas o explicitas, Oracle utiliza este tablespace temporal como área secundaria de trabajo. La creación de espacios temporales se realiza mediante la sentencia CREATE TABLESPACE y cláusula TEMPORARY: CREATE TEMPORARY TABLESPACE nombre_tablespace TEMPFILE ruta_fichero SIZE tamaño_fichero; Para especificar el tablespace por defecto de la BBDD se utiliza la cláusula DEFAULT TEMPORARY TABLESPACE de la sentencia CREATE DATABASE. Si un usuario no va a utilizar el tablespace temporal por defecto de la BBDD, es necesario indicarlo en la sentencia de creación del usuario: CREATE USER nombre_user IDENTIFIED BY clave_usuario TEMPORARY TABLESPACE nombre_tablespace.
Apartado 2.3 2.3: Tipos de tablespaces tablespaces permanentes Una nueva funcionalidad en Oracle 10g es el tipo de tablespace BIGFILE. Hasta la versión 9 de Oracle todos los tablespaces eran SMALLFILE invariablemente. Los tablespaces BIGFILE utilizan un único fichero de datos (o temporal), en lugar de varios como los antiguos SMALLFILE, que puede tener hasta 232 bloques de tamaño. Por tanto en función del tamaño de bloque utilizado, un único fichero puede ser como máximo de 128 terabytes (TB). La consecuencia de esto es que Oracle 10g, en conjunción con el parámetro DB_FILES, puede escalar hasta BBDD de 8 exabytes (EX) de tamaño. Además al ser la gestión de estos ficheros dependiente de Oracle, son completamente transparentes para el usuario las operaciones que se realizan sobre este tipo de ficheros tan grandes. Este nuevo tipo de tablespace está orientado para BBDD extremadamente grandes. Cuando un BBDD de este tipo presenta miles de ficheros de datos de lectura/escritura, las operaciones a realizar sobre ellos pueden sufrir ciertos retrasos. Por tanto al reducir el número de ficheros de datos sobre los que trabajar, se mejora el rendimiento al reducir el tiempo de ejecución de estas operaciones. Para crear este tipo de tablespace es necesario incluir la cláusula BIGFILE en la sentencia de creación del espacio de tablas: CREATE BIGFILE TABLESPACE tablespace_name DATAFILE ruta_fichero SIZE tamaño_fichero; Los tipos de tablespace SMALLFILE es la nueva denominación que da Oracle 10g a los antiguos tablespaces. En este tipo de espacios, se pueden tener varios ficheros de datos en un solo tablespace. En función del tamaño de bloque utilizado las BBDD que utilicen este tablespace pueden alcanzar como máximo los 8 petabytes (PB). Para crear este tipo de tablespace no es necesario incluir ninguna cláusula especial, ya que por defecto Oracle 10g crea estos en espacio de tablas:
Los tipos de tablespace SMALLFILE es la nueva denominación que da Oracle 10g a los antiguos tablespaces. En este tipo de espacios, se pueden tener varios ficheros de datos en un solo tablespace. En función del tamaño de bloque utilizado las BBDD que utilicen este tablespace pueden alcanzar como máximo los 8 petabytes (PB). Para crear este tipo de tablespace no es necesario incluir ninguna cláusula especial, ya que por defecto Oracle 10g crea estos en espacio de tablas: CREATE TABLESPACE tablespace_name DATAFILE ruta_fichero SIZE tamaño_fichero; Los tablespaces SYSTEM y SYSAUX se crean con el tipo SMALLFILE.
Apartado 2.4: Tablespace UNDO Este último tipo de tablespace mantiene la información necesaria para anular los cambios realizados sobre la BBDD. Esta información consiste en registros de las acciones realizadas por las transacciones, y se conoce como información de undo o deshacer. Este tipo de tablespace solo puede contener un tipo de segmento, el de UNDO. En Oracle se entiende por deshacer (undo), el proceso de restaurar los datos a un estado previo. A medida que se interactúa con el SGBD los datos contenidos en la BBDD cambian, si se quisiera recuperar alguno a un valor anterior, por haberse producido un error o fallo, Oracle utilizará la información almacenada aquí para conseguir restaurarlo. Este tipo de tablespace es utilizado por el SGBD para múltiples propósitos: •
Rollback
explicito
de
una
transacción
usando
la
sentencia
ROLLBACK. •
Rollback implícito de una transacción (por ejemplo, para recuperar una transacción fallida).
•
Reconstruir una imagen de los datos consistente en lectura
•
Recuperación de corrupciones lógicas.
Aunque la BBDD puede tener definida más de tablespace UNDO, estos sólo se utilizan por el SGBD cuando se ha activado la gestión automática de información de anulación; en cuyo caso solo se puede utilizar un único tablespace UNDO. CREATE UNDO TABLESPACE tablespace_name DATAFILE ruta_fichero SIZE tamaño_fichero;
Apartado 2.5: Tablespaces por defecto Como parte del proceso de creación de toda BBDD en Oracle 10g se crean dos tablespaces por defecto, SYSTEM y SYSAUX. El tablespace SYSTEM se encarga de almacenar el DD, el cual es utilizado por el SGBD para su correcto funcionamiento.
Este DD se compone de un
conjunto de tablas internas que almacenan información sobre la propia BBDD. A medida que Oracle 10g opera, extrae de forma continuada información operativa de este DD. Además del contenido del diccionario, el tablespace SYSTEM contiene el código fuente y compilado de los programas PL/SQL (procedimientos y funciones almacenadas, disparadores, etc.), y los objetos de la BBDD (secuencias, vistas, sinónimos, etc.). Por tanto, este tablespace siempre tiene que existir y estar activo, mientras que la BBDD esté abierta. El tablespace SYSAUX, es utilizado por varias herramientas y módulos en los que se basan las actividades del SGBD para almacenar sus objetos. Este espacio comparte con el de SYSTEM las siguientes características: •
Son obligatorios cuando se crea un nueva BBDD.
•
Son de tipo permanente.
•
No pueden ser eliminado.
•
Siempre tienen que estar activados (online).
•
Tienen que tener el estado Lectura/Escritura
Cuando se actualiza una versión de Oracle a la versión 10g se crea el tablespace SYSAUX para cubrir las nuevas funcionalidades del SGBD. Como estos dos tablespaces, SYSTEM y SYSAUX, son los únicos que se encuentran en el SGBD de forma certera, son los tablespaces por defecto. Sin embargo Oracle recomienda encarecidamente que no sean usados como tablespaces por defecto de los usuarios o aplicaciones.
Para conseguirlo durante la creación de una nueva BBDD, se crean ciertos tablespaces para almacenar datos de las diferentes aplicaciones y usuarios que van a interactuar con el SGBD. Es práctica común en ciertas ocasiones crear varios tablespaces temporales, así como un tablespace UNDO para mejorar el rendimiento del SGBD. Por tanto y como resumen, Oracle 10g utiliza varios espacios de tablas para separar lógica y físicamente el almacenamiento de distintos conjuntos de información de la BBDD.
Apartado 2.6: Gestión de extensiones Como se ha comentado anteriormente los tablespaces se componen de segmentos que a su vez se desglosan en extensiones. La asignación de estas extensiones a un segmento perteneciente a un tablespace puede realizarse siguiendo dos políticas distintas. Cuando un segmento ha agotado el espacio del que dispone (todas sus extensiones están llenas) es necesario asignarle una nueva extensión para almacenar la nueva información. Por tanto la asignación de espacio en Oracle 10g es bajo demanda, cuando un segmento no tiene extensiones libres solicita al SGBD que le asigne más espacio a través de una nueva extensión. Por otro lado las extensiones asignadas a un segmento también pueden ser liberadas para ser utilizadas por otro tablespace. Este proceso de asignación/liberación de extensiones implica que es necesario almacenar en alguna zona del SGBD la información relativa a un segmento y sus extensiones. La forma de gestionar las extensiones de un tablespace puede ser (cuando el segmento no tiene la suya propia): •
Gestión de extensiones mediante el diccionario (única conocida antes de Oracle 8i): Modifica una serie de tablas en el DD en cuanto una extensión es asignada o liberada. Esto implica que el volumen de transacciones que operan sobre el diccionario puede ser muy elevado, lo que en algunas ocasiones podría afectar al rendimiento del SGBD. Para crear un tablespace usando esta política es necesario recurrir a la cláusula EXTENT MANAGEMENT DICTIONARY de la sentencia CREATE TABLESPACE. Además se pueden indicar los parámetros de almacenamiento predeterminados para los segmentos que se almacenan en el tablespace. Para ello se incluirá la cláusula DEFAULT STORAGE de la sentencia CREATE TABLESPACE. Las opciones disponibles son:
o INITIAL: Define las dimensiones de la primera extensión del segmento. o NEXT:
Define
las
dimensiones
del
segundo
y
posteriores
extensiones del segmento. o MINEXTENTS: Número de extensiones asignadas a un segmento cuando se crea por primera vez en el tablespace. o MAXEXTENTS: Determina el número máximo de extensiones que un segmento puede tener. Puede tener como valor UNLIMITED. o PCINCREASE: Define el porcentaje de incremento a partir de la segunda (NEXT). •
Se calcula mediante: NEXT*(1+(PCTINCREASE/100))
o FREELIST: Lista de bloques de datos en la extensión que permiten la inserción, es decir que están libres. Un ejemplo de tablespace usando este método es el siguiente: CREATE TABLESPACE tablespace_name DATAFILE ruta_fichero SIZE tamaño_fichero EXTENT MANAGEMENT DICTIONARY DEFAULT STORAGE (INITIAL 50K NEXT 50K MINEXTENS 2 MAXTEXTENS 50 PCTINCREASE 0); •
Gestión local de extensiones: En este caso se utiliza un mapa de bits (bitmap) que reside en la cabecera del propio tablespace. Es el recomendado por Oracle, ya que se reduce la contención del DD al reducirse las operaciones a realizar sobre el. Para utilizar esta política se debe recurrir a la cláusula EXTENT MANAGEMENT LOCAL de la sentencia CREATE TABLESPACE.
Dentro de esta opción aparecen dos alternativas, ya que el sistema puede reservar el tamaño que considere más adecuado para las extensiones o bien hacer que todas tengan el mismo. En la primera alternativa, el mismo sistema es el encargado de reservar las extensiones del tamaño que considere más oportuno dependiendo de las necesidades puntuales. Para ello se utiliza la cláusula AUTOALLOCATE: CREATE TABLESPACE tablespace_name DATAFILE ruta_fichero SIZE tamaño_fichero EXTENT MANAGEMENT LOCAL AUTOALLOCATE; La otra opción permite que todas las extensiones tengan las mismas dimensiones. Se trata por tanto, de una asignación uniforme de extensiones. En este caso se utiliza la cláusula UNIFORM, con la posibilidad de definir el tamaño que se quiere utilizar en las extensiones (parámetro SIZE). Si no se define por defecto el valor es de 1MB. CREATE TABLESPACE tablespace_name DATAFILE ruta_fichero SIZE tamaño_fichero EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1024K; Si durante la creación del segmento, se ha definido un método de forma explicita se utilizará este para las nuevas asignaciones/liberaciones. En caso contrario se recurrirá a la política de utilización de extensiones fijada en el tablespace donde se aloja dicho segmento. Un manejo ineficiente de las extensiones disponibles hace que se produzcan demoras en la creación y asignación de las mismas. Oracle recomienda utilizar la gestión local de extensiones.
Apartado 2.7: Disponibilidad de los tablespaces Los tablespaces pueden tener los datos a disposición de las aplicaciones y de los usuarios, lo que se conoce como estado online o activo. Sin embargo, es posible que en algunos casos se quiera limitar el acceso a los mismos aunque la BBDD siga disponible; en este caso el tablespace estaría offline o desactivo. Al desactivar un espacio de tablas los objetos almacenados en el quedan inaccesibles para los usuarios de la BBDD. Para cambiar su estado se utiliza la sentencia: ALTER TABLESPACE nombre_tablespace OFFLINE; Al desactivar un tablespace, se desactivan (estado offline) todos los ficheros asociados con el. Para volver a activar un tablespace se utiliza la sentencia: ALTER TABLESPACE nombre_tablespace ONLINE;
Apartado 2.8: Tablespace de solo lectura Es posible cambiar la propiedad de lectura/escritura de un tablespace, dejándolo con el atributo de solo lectura. Con esto se impiden todas las operaciones que puedan modificar los contenidos de los ficheros asociados al tablespace. Sin embargo para poder realizar este cambio es necesario que se cumplan una serie de condiciones para el tablespace en cuestión: •
El tablespace debe estar online.
•
El tablespace no debe estar incluido en ninguna copia de seguridad en caliente.
•
El tablespace no debe tener ningún segmento de undo activo.
Para impedir la escritura se utiliza la sentencia: ALTER TABLESPACE tablespace_name READ ONLY; Para volver a permitir las escrituras, se utiliza la sentencia: ALTER TABLESPACE tablespace_name READ WRITE; En un tablespace read only solo se pueden realizar consultas de los datos, por tanto si en el instante de ejecutar esta sentencia se están realizando cualquier tipo de operación que pueda alterar los datos, el servidor espera hasta que acaben para poner el tablespace en estado read only. Para comprobar el estado del tablespace, se puede realizar una consulta sobre la vista dba_tablespaces, mostrando el tablespace y su estado: SELECT tablespace_name, status FROM dba_tablespaces;
Apartado 2.9: Obtener información de los tablespaces Oracle 10g incluye una serie de utilidades para obtener información detallada de los diferentes tablespaces asociado a una BBDD. En lugar de tener que acceder a esta información a través de consultas al DD desde la línea de comandos de herramientas como el SQL*Plus o iSQL*Plus, se puede acceder a mediante herramientas más interactivas como Oracle Enterprise Manager (EM) Database Control. Gracias a esta herramienta se puede monitorizar y gestionar las diferentes estructuras que componen la BBDD. EM Database Control es una alternativa a las tradicionales herramientas de línea de comandos y utiliza las ventajas que aporta tecnología web. Para poder acceder a esta herramienta se tienen que seguir los siguientes pasos: 1. Abrir un navegador y escribir la URL del Entreprise Manager de la BBDD que se quiere gestionar. 2. Acceder mediante el usuario y contraseña del usuario correspondiente y acceder a la pestaña de administración (ver Figura 4). 3. Para listar los tablespaces asociados a la BBDD, elegir la opción tablespaces ubicada debajo de la cabecera Almacenamiento (ver Figura 5). 4. Seleccionar un tablespace del listado de disponibles y pinchar el botón Editar para poder trabajar con él.
Figura 4. Pestaña de administración en Oracle EM
Figura 5. Pestaña de tablespaces en Oracle EM
Las opciones más importantes al alcanzar este punto son: General y Almacenamiento (ver Figura 6). La primera de ellas muestra las características principales del tablespace: •
Tipo: Permanente, temporal, etc
•
Tamaño: Bigfile, Smallfile.
•
Estado: Lectura/escritura, online, offline, etc.
•
Política de gestión de extensiones utilizada: Diccionario de datos, local.
•
Listado de ficheros asociados al tablespace.
Figura 6. Edición de tablespace en Oracle EM
La segunda pestaña muestra información relativa al almacenamiento del tablespace (gestión de extensiones, segmentos y tamaño de bloque usado) (ver Figura 7).
Figura 7. Gestión del almacenamiento de un tablespace en Oracle EM Se puede utilizar las opciones comentadas en Oracle EM Database Control para manipular y cambiar a través de múltiples opciones los tablespaces. Además esta herramienta cubre prácticamente las mismas funcionalidades que las ofrecidas por las que utilizan la línea de comandos. Por ejemplo para incrementar el tamaño de los ficheros de datos de un tablespace, basta con pinchar el botón Editar de la zona de Archivos de Datos. Oracle EM Database Control mostrará una ventana para la edición de las características de ese fichero (ver Figura 8).
Figura 8. Edición de un fichero de datos asociado a un tablespace en Oracle EM
Apartado 2.10: Cálculo de la base de datos en Oracle 10g Para realizar una estimación del tamaño de la BBDD, es necesario tener presente que Oracle 10g almacena la información de forma organizada, utilizando estructuras de almacenamiento tanto lógicas como físicas. El tamaño de la BBDD se calcula a partir de los tablespaces que la forman. Estos a su vez dependen de las dimensiones de los ficheros de datos asociados a ellos (ver Figura 9). Por tanto el tamaño final de una BBDD se calcula como la suma de las dimensiones de los ficheros de datos asociados a los tablespaces que conforman cada BBDD.
Figura 9. Distribución de tablespaces y ficheros en Oracle 10g Este tamaño se fija al crear los tablespaces y definir los datafiles con su dimensión inicial. Si con el paso del tiempo es necesario aumentar la capacidad de la BBDD, existen tres alternativas:
•
Añadir un fichero de datos a un tablespace. ALTER
TABLESPACE
nombre_tablespace
ADD
DATAFILE
ruta_fichero SIZE tamaño_fichero [opciones]; Esta sentencia no puede ser utilizada si el tablespace es de tipo BIGFILE, ya que solo se permite que tengan asociado un único fichero de datos. •
Agregar un nuevo tablespace a la BBDD. CREATE
TABLESPACE
nombre_tablespace
DATAFILE
ruta_fichero SIZE tamaño_fichero [opciones]; •
Modificar el tamaño de los ficheros de datos asociados a algún tablespace. Para realizar esto existen dos posibilidades, especificar un nuevo tamaño o bien permitir que estos crezcan dinámicamente para satisfacer las nuevas demandas de espacio. ALTER
DATABASE
DATAFILE
ruta_fichero
RESIZE
tamaño_fichero [K|M] ALTER DATABASE DATAFILE ruta_fichero AUTOEXTEND ON; Es importante remarcar, que cuando un tablespace crea un fichero de datos de un tamaño concreto, implica para el SO la reserva y por tanto la ocupación de ese espacio en disco. Es decir, que aunque inicialmente el tablespace esté vacío, y disponga de espacio disponible para guardar información de los objetos de la BBDD, para el SO ese fichero está lleno y tiene el tamaño fijado al crear el tablespace.
Conclusión Con el desarrollo de esta lección, el alumno debe ser capaz de saber crear y gestionar las unidades lógicas de almacenamiento tablespaces en Oracle 10g.
Lección 3
Bloques, extensiones y segmentos
Índice 3.1. Bloques 3.2. Extensiones 3.3. Segmentos
Introducción En esta lección se detallan el resto de estructuras lógicas de alto para almacenamiento de información en Oracle10 g: Bloque, Extensión y Segmento. Por otro lado se describe el proceso de gestión del espacio en disco y almacenamiento de la información en la BBDD. Al finalizar se incluyen una serie de ejercicios de auto evaluación para comprobar los conocimientos aprendidos.
Objetivos -
Descripción y utilización del resto de estructuras lógicas de Oracle 10g: Bloque, Extensión y Segmento.
-
Dependencias entre estas unidades lógicas de almacenamiento.
-
Gestión del almacenamiento de la información de la BBDD.
-
Gestión del espacio en disco para el SGBD Oracle 10g.
Apartado 3.1: Bloques Oracle 10 gestiona el almacenamiento en disco de los ficheros de datos a través de las unidades denominadas bloques de datos, las cuales representan las unidades más pequeñas que usa Oracle para manejar información. Su tamaño para cada BBDD se especifica en el parámetro de inicio DB_BLOCK_SIZE y no puede cambiarse posteriormente. Oracle 10g delega en el SO la comunicación con los elementos de hardware del sistema y, por lo tanto, desde el punto de vista físico, los datos se almacenan y trasladan en bloques del mismo. Cada SO tiene su propio tamaño de bloque, pero Oracle 10g lo ignora para sus operaciones y aplica el suyo propio. Para simplificar las operaciones de E/S, se recomienda que el tamaño del bloque de Oracle sea un múltiplo del tamaño de bloque del sistema operativo.
1
FORMATO DE UN BLOQUE La estructura de un bloque de datos está dividida en diferentes zonas como
se puede observar en la Figura 10.
Figura 10. Estructura de un bloque en Oracle 10g
•
Cabecera (Común y variable): La cabecera contiene información general del bloque, como su dirección y el tipo de segmento al que pertenece (es decir, si se trata de un segmento de datos, de índice o de rollback).
•
Directorio de Tabla: Este componente almacena información sobre la tabla a la que se encuentra asignado este bloque.
•
Directorio de Filas: Esta sección contiene los identificadores de registros pertenecientes al bloque. Un bloque puede estar vacío o almacenar todos los registros posibles. En ambos casos, este espacio está ocupado ya que, aunque los registros se destruyan, sus identificadores siguen apareciendo en el directorio de filas hasta que son reaprovechados por nuevas inserciones. Las tres zonas anteriores con conocidas como sobrecabecera o overhead.
•
Datos de filas: Ésta es la zona del bloque en la que se
encuentran físicamente los datos de la tabla o índice. Si un registro es tan voluminoso que no cabe en un bloque, es necesario dividir el registro y almacenado en varios. Esto se conoce como "encadenamiento de filas" y afecta al rendimiento, ya que cuando se consulte el registro será necesario localizar el bloque principal y, además, el bloque asociado que contiene el resto del registro. •
Espacio libre: El espacio libre es el espacio restante, apto para la inserción de nuevos registros o la actualización de los que ya están en el bloque y necesitan más espacio. Este espacio libre se gestiona con el parámetro PCTFREE.
2
ESPACIO LIBRE El espacio libre se reserva para insertar nuevas filas y para actualizaciones
de filas que requieren espacio adicional. La gestión de los espacio libre puede ser realizada de forma manual o automática. Si se utiliza la opción de manejo automático, este se gestiona a través de los segmentos de la BBDD, depositando esta información en bitmaps. Su uso es opuesto a la gestión manual a través de las listas de bloques libres. En esta segunda opción, caso el espacio libre para los segmentos de datos e índices se gestiona a través de una lista de bloques libres (denominada como “free lists” en la terminología de ORACLE). Estos bloques son aquellos poseen espacio mayor o igual al que determina el parámetro PCTFREE. La utilización de la gestión automática ofrece los siguientes beneficios: •
Facilidad de uso.
•
Se aprovecha el espacio, especialmente para aquellos objetos que tienen filas que varían mucho de tamaño.
•
Mejores ajustes en tiempo real a las variaciones en acceso concurrente.
•
Mejor comportamiento en entornos multi instancia en términos de rendimiento y utilización del espacio disponible.
3
PCTUSED / PCTFREE En los tablespaces gestionados de forma manual, al crear o modificar un
objeto de tipo tabla o cluster, existen dos parámetros que permiten controlar el comportamiento del espacio libre. Estos parámetros son PCTUSED y PCTFREE y controlan el uso del espacio libre para inserciones y actualizaciones, para todos los bloques de un determinado segmento asociado al tablespace. También se puede especificar el parámetro de almacenamiento PCTFREE cuando se crea o modifica un índice (que tiene su propio segmento de indices).
El parámetro PCTFREE establece el porcentaje mínimo del bloque que debe reservarse para permitir la expansión de los datos que ya se encuentran almacenados en dicho bloque. Esta expansión se produce cuando se modifican filas o registros almacenados en la tabla, asignado valores a columnas que previamente contenían nulos, o valores mayores a columnas con tipos de datos variables.
Figura 11. Uso del parámetro PCTFREE Si por ejemplo, se asigna el valor 20 al parámetro PCTFREE, el 20% de cada bloque de este segmento de datos quedará libre y disponible siempre para las posibles actualizaciones de registros que ya existan en ese bloque. El bloque permitirá inserciones hasta que se encuentre lleno al 80% (sumando el espacio de datos de filas y el overhead). A partir de ese momento, el bloque queda inhabilitado para inserciones y únicamente se destinará a la actualización (y borrado) de registros. El parámetro PCTUSED marca el nivel de ocupación por debajo del cual debe encontrarse el bloque para reactivarse. Tras alcanzar el límite de PCTFREE, Oracle inhabilita el bloque para inserciones hasta que su ocupación sea inferior al porcentaje establecido en PCTUSED. De este modo, el sistema se asegura de que el bloque sólo queda disponible cuando hay espacio suficiente para insertar un número significativo de registros.
Si configuramos el parámetro PCTUSED = 4O al crear la tabla, el bloque de datos no se considera disponible para nuevas inserciones hasta que el espacio usado (la suma del espacio para datos de filas y el overhead) decae hasta el 39% o menos. Un ejemplo de este parámetro lo podemos ver en la siguiente figura:
Figura 12. Uso del parámetro PCTUSED
Mediante el uso combinado de PCTFREE y PCTUSED puede controlarse el comportamiento del espacio en los bloques de datos de las extensiones de un segmento. Para los nuevos bloques, el espacio disponible para inserciones es el tamaño del bloque menos la suma del Overhead y el PCTFREE. Las actualizaciones de datos existentes pueden usar cualquier espacio disponible en el bloque. Por lo tanto las actualizaciones también pueden reducir el espacio
disponible por debajo del PCTFREE establecido. Un ejemplo de funcionamiento de estos parámetros puede observarse en la Figura 13.
Figura 13. Uso combinado de PCTFREE y PCTUSED Por cada segmento de datos o de índice, Oracle 10g mantiene una o varias listas libres (free lists). Se trata de listas que bloques de datos, asociados a las extensiones del segmento, que disponen de más espacio libre que el PCTFREE. Estos bloques están disponibles para nuevas inserciones. Cuando se intenta insertar nuevos registros en una tabla, Oracle recorre las free lists en busca de bloques disponibles para nuevas inserciones. Por este motivo se recomienda crear varias free lists por segmento para reducir la contención cuando se produzcan al mismo tiempo varias inserciones.
4
ENCADENAMIENTO Y MIGRACIÓN En Oracle 10g existen dos circunstancias en las cuales los datos de una fila
de una tabla pueden ser demasiado grandes para almacenarlos en un único bloque. En el primer caso, encadenamiento, Oracle almacena los datos de la fila en una cadena de uno o más bloques de datos reservados para ese segmento Esto sucede con filas grandes con columnas del tipo LONG o LONG RAW. Las operaciones que pueden producir este fenómeno son INSERT ó UPDATE. La reorganización es provocada por un valor demasiado bajo de PCTFREE; ya que no hay espacio suficiente en los bloques para las futuras inserciones o modificaciones. El segundo fenómeno, migración, se produce si una sentencia UPDATE incrementa la cantidad de datos en una fila, de modo que la fila no se puede dejar en ese bloque de datos. Oracle intenta encontrar otro bloque con espacio libre suficiente para mantener la fila entera. Si el bloque está disponible, Oracle mueve la fila entera al nuevo bloque y guarda en el bloque original un puntero al nuevo bloque. El identificador de la fila o ROWID de la fila migrada no cambia. Gracias a esto los índices no son modificados, ya que apuntan a la localización original de la fila. Estos fenómenos, encadenamiento y migración tienen un efecto negativo sobre el rendimiento: •
Las sentencias INSERT y UPDATE que causan reorganización y encadenamiento se ejecutan más lentamente, porque realizan un procesamiento adicional.
•
Las consultas que utilizan un índice para seleccionar filas encadenadas o reorganizadas deben realizar I/Os adicionales.
Apartado 3.2: Extensiones Una extensión es una unidad lógica de almacenamiento compuesta de una serie de bloques de datos contiguos. Una o más extensiones crean a su vez un segmento. Cuando todo el espacio de un segmento está usado, Oracle asigna una nueva extensión para el segmento (siempre y cuando sea posible). Cuando se crea un objeto, por ejemplo una tabla, Oracle le asigna al segmento de ese objeto una extensión inicial de un número determinado de bloques de datos. Aunque no se hayan insertado datos todavía, los bloques de datos de Oracle que corresponden con la extensión inicial son reservados para las posibles filas de la tabla. Si los bloques de datos de esa extensión inicial se llenan y se necesita más espacio para almacenar nueva información, Oracle asigna automáticamente una extensión adicional para el segmento. Esa nueva extensión debe tener el mismo tamaño o superior que la anterior en el segmento.
1
NÚMERO DE EXTENSIONES Y TAMAÑO El control de la asignación del espacio libre a través de las extensiones se
define en la cláusula de almacenamiento de cada segmento, sea del tipo que se. Por ejemplo se puede determinar cuanto espacio se reserva inicialmente o el número de extensiones de un segmento, especificando los parámetros de almacenamiento de la cláusula STORAGE en la sentencia CREATE TABLE o CREATE INDEX. Si no se especifican, se utiliza la cláusula predeterminada del tablespace al que pertenece el objeto. Los tablespaces pueden gestionar las extensiones de dos formas: a través del diccionario de datos o localmente. En la primera de ellas, se utilizan los parámetros INITIAL, NEXT y PCTINCREASE de la cláusula STORAGE de la sentencia de creación del objeto, tabla o índice. Siguiendo esta política, la primera extensión del segmento tendrá el
tamaño especificado en el parámetro INITIAL. Si se requiere una segunda, su tamaño lo fija el parámetro NEXT, el resto se calculan en función de los parámetros NEXT y PCTINCREASE. Estos parámetros pueden modificarse después de la creación del objeto correspondiente. La segunda alternativa, gestión local, se configura con la cláusula UNIFORM O AUTOALLOCATE a la hora de crear el tablespace. Si se utiliza esta se renuncia a la posibilidad de configurar los parámetros anteriores, INITIAL, NEXT, etc para el tablespace. Sin embargo si pueden especificarse a nivel de segmento. En este caso los parámetros INITIAL, NEXT, PCTINCREASE y MINEXTENTS son usados de forma conjunta para calcular el tamaño inicial del segmento. Después de esto, una serie de algoritmos internos determinan el tamaño de cada extensión. Las posibilidades que existen en este tipo de gestión para el tamaño de las extensiones son: que todas tengan un tamaño fijo (UNIFORM) o variable calculado por el SGBD (AUTOALLOCATE).
2
ASIGNACIÓN / LIBERACIÓN DE EXTENSIONES Oracle utiliza diferentes algoritmos para asignar extensiones, dependiendo
del tipo de gestión elegida: local o diccionario de datos. Con la gestión local, Oracle busca espacio libre para asignar una nueva extensión. Para ello en primer lugar determina el fichero de datos candidato en el tablespace, y posteriormente busca el mapa de bits (bitmap) del fichero para reservar los bloques libres adyacentes necesarios. Si en este fichero no existiera espacio libre, Oracle buscaría en otro de los asignados al tablespace. De forma general, las extensiones de un segmento no se devuelven al tablespace hasta que se elimina el objeto del esquema (sentencia DROP). Cuando las extensiones se liberan, en el modo local Oracle modifica la cabecera bitmap del fichero, y en modo del diccionario actualiza los datos correspondientes del DD para reflejar que las extensiones vuelven a ser espacio libre. Todos los bloques de las extensiones liberadas pasan a estar inaccesibles.
Apartado 3.3: Segmentos
Un segmento es la estructura de más alto nivel dentro de un tablespace. Se trata de un conjunto de extensiones que contienen todos los datos asociados a un objeto específico dentro del tablespace al que pertenece. Para cada objeto, por ejemplo una tabla o índice, Oracle asigna una o más extensiones para formar su correspondiente segmento de datos o segmento de índice. Por tanto los segmentos son simplemente objetos de la BBDD que consumen espacio de almacenamiento. La liberación de las extensiones de un segmento suele realizarse cuando se borra el objeto que almacena los datos en el segmento. En el caso de los segmentos temporales, se borran al terminar de ejecutar la sentencia SQL que los requería. Existen diferentes tipos de segmentos en función de los objetos que se van a almacenar en cada uno. •
Segmento de Datos.
•
Segmentos de Índices.
•
Segmentos Temporales.
•
Gestión Manual de Undo (Segmentos de Rollback) / Gestión Automática de Undo.
1
SEGMENTOS DE DATOS Conjunto de extensiones asignadas a una tabla, cluster o partición. Al crear
el objeto correspondiente Oracle 10g crea un segmento de este tipo para almacenar todos los datos asociados a el. Por tanto en un segmento de este tipo no pueden aparecer extensiones asignadas a varios objetos. El método de almacenamiento utilizado depende de la cláusula STORAGE incluida en la sentencia de creación CREATE TABLE.
En el caso de no incluirse de forma explícita, la gestión de extensiones se ajusta a la política definida en el tablespace donde reside el objeto. Una vez que asignada una extensión a un segmento, esta se mantiene asociada hasta que se borra el segmento, es decir al borrar el objeto que almacena los datos. Por ejemplo si se borran datos de una tabla con el comando DELETE, esto no influye en el espacio de disco ocupado por ese objeto. Esto es debido a que Oracle realiza la reserva de espacio a priori, es decir al asignar las extensiones (bloques de bytes) a una extensión se está reservando cierta cantidad de sitio en disco. Por tanto para el SO, este espacio de disco aparece como ocupado aunque en realidad no lo esté todavía. El número máximo de extensiones que puede tener un segmento puede estar fijado, por el parámetro MAXEXTENTS de la cláusula de almacenamiento, la cuota disponible por el usuario en el tablespace, o bien, por el espacio libre en el tablespace (si la cláusula AUTOEXTEND no está activada).
2
SEGMENTOS DE ÍNDICES Cada índice tiene asignado un conjunto de extensiones que almacena
todos sus datos. La creación de este tipo de segmento es inherente a la sentencia CREATE INDEX, en la cual también se pueden especificar los parámetros de gestión de extensiones. Al igual que en lo segmentos de datos, la liberación de las extensiones se produce al borrar el segmento al que están asignadas. En este caso además si se borra la tabla o cluster que está indexando, también se borraría el segmento.
3
SEGMENTOS DE ROLLBACK O UNDO Estos segmentos almacenan la información temporal relativa a las
transacciones que se ejecutan en el SGBD. Su uso permite brindar consistencia de lectura, restaurar múltiples transacciones y recuperar la BBDD después de un fallo. Gracias a esto se consigue que en entornos multiusuario con acceso concurrente, la información aparezca siempre en un estado consistente.
Cada segmento de rollback, mantiene cierta información antes de ser cambiada por una o más transacciones de la base de datos. Esta información es útil para brindar a las demás transacciones consistencia de lectura. Cuando acceden las transacciones intentan acceder a la información almacenada en un bloque sucio (que ha sido actualizado pero no confirmado), se les remite a la información del segmento de rollback respectivo. Además de esto, en los casos que una transacción aborte por cualquier motivo, el proceso PMON restaura el valor de los bloques sucios con la información original. Por último, en el caso de una caída de la base de datos, los segmentos de rollback son reconstruidos según la información de los ficheros de redo, a continuación se inicia el proceso de restauración de todas las transacciones no confirmadas. La cantidad de transacciones asociadas un segmento de rollback puede limitarse mediante el parámetro de inicialización: TRANSACTIONS_PER_ROLLBACK_SEGMENT. Como el resto de los segmentos, los segmentos de rollback adquieren nuevas extensiones si las que ya dispone no bastan para almacenar la información que recibe. El contenido de cada transacción debe almacenarse en único segmento de rollback. De este modo la utilización y reutilización de las extensiones es un problema acuciante, especialmente en entornos con gran carga de trabajo. Las extensiones asociadas a un segmento de rollback, son utilizadas de forma cíclica. De esta forma en la Figura 14, en su parte izquierda se muestra que cuando el extensión E3 se llena se pasa a la E4. Cuando la E4 se llena, se verifica si en la extensión E1 puede almacenarse la transacción en curso y no tiene otras transacciones activas actuando sobre. En este caso se continúa almacenando la transacción en la extensión E1 (parte derecha de la figura), en caso contrario se generaría una nueva extensión E5.
Figura 14. Utilización cíclica de los segmentos de Rollback Toda BBDD dispone de al menos un segmento de rollback en el tablespace SYSTEM. Por tanto no es un segmento público, por lo que sólo es utilizado por el SGBD y no por los usuarios finales. Si existen varios segmentos de rollback, Oracle sólo utiliza el ubicado en SYSTEM para operaciones del sistema. En general, se recomienda crear al menos un segmento de rollback adicional.
4
SEGMENTOS TEMPORALES Este tipo de segmentos son creados por el SGBD cuando el análisis sobre
una sentencia SQL necesita un espacio de trabajo suplementario al disponible en la zona SGA. Al terminar ejecución de la sentencia, sea con éxito o error, se liberan y pueden volver a ser utilizadas. Algunas de las operaciones que necesitan utilizar los segmentos temporales son: CREATE INDEX, SELECT DISCTINCT, SELECT…[GROUP BY | ORDER BY | UNION | INTERSECT | MINUS], etc. Estos segmentos se crean automáticamente en el tablespace temporal del usuario que ejecuta la sentencia. Para la asignación de un tablespace temporal a un usuario se recurre a la sentencia TERMPORARY TABLESPACE de las sentencias de creación (CREATE USER) o modificación de usuarios (ALTER USER)..
Los tablespaces temporales asociados a los usuarios no pueden ser del tipo permanente.
5
GESTIÓN DEL UNDO En Oracle 8i y anteriores, los segmentos de Rollback aseguraban la
consistencia en lectura y la capacidad de gestionar la restauración de transacciones. En este casos se considera que la gestión del undo se realiza de forma manual: gestión manual del undo (Manual Undo Management o MUM). Para simplificar la gestión de los segmentos de Rollback, a partir de Oracle 9i se introdujo la Gestión Automática de Undo (Automatic Undo Management o AUM). En este caso el SGBD, gestiona automáticamente la asignación del espacio de undo (rollback) entre las diferentes sesiones activas. En este caso la gestión de los segmentos de undo y el espacio entre las diferentes sesiones activas recae en el SGBD. En lugar de utilizar los segmentos de rollback de sus predecesores, recurre a los tablespaces de undo. Por tanto el espacio se asigna por medio del tablespace undo, evitando la necesidad de tener que reservar múltiples segmentos de rollback de diferentes tamaños. Gracias a esto se consigue reducir la complejidad de la gestión de los segmentos de rollback y permite ejercer mayor control sobre cuanto tiempo está retenido antes de ser sobrescrito. En una BBDD que utiliza AUM, todas las transacciones comparten un único tablespace undo. Cualquier transacción en ejecución puede consumir espacio libre en ese tablespace. El espacio de undo es dinámicamente transferido, desde las transacciones confirmadas a las transacciones en ejecución en caso de escasez de espacio dentro del tablespace undo
En la nueva política diseñada, el SGBD cambia automáticamente el periodo para el cual la información de undo es retenida, para satisfacer así las operaciones que requieran información de este tipo. Este periodo es conocido en Oracle 10g como “undo retention”, e indica la cantidad de tiempo que deber pasar antes de que la información antigua, es decir información de undo para transacciones confirmadas, pueda ser sobrescrita. Este tiempo puede ser especificado a través del parámetro UNDO_RETENTION, el cual es dinámico y puede por tanto ser cambiado en cualquier momento a través de la sentencia ALTER SYSTEM. Esta característica AUM ha sido mejorada en Oracle 10g a través de la funcionalidad Automatic Undo Retention Tuning. Esta característica es utilizada por defecto en el SGBD, y determina automáticamente el tiempo óptimo de “undo retention” dependiendo del tamaño del tablespace de undo. Oracle 10g se ajusta dinámicamente a los cambios de requisitos de undo, en función de la actividad del sistema, no siendo necesaria la intervención del usuario. Esto maximiza el uso del espacio disponible en el tablespace de undo y permite que las sentencias largas se completen sin encontrar problemas relacionados con la gestión de los segmentos de rollback. Oracle recomienda encarecidamente utilizar los tablespaces de undo para manejar las operaciones de deshacer en lugar de los antiguos segmentos de rollback/undo. La gestión del espacio en estos segmentos era excesivamente compleja, y Oracle en la actualidad ha dejado de lado este método de gestión del undo. En resumen en el modo manual (MUM) el espacio de undo se gestiona a través de segmentos rollback/undo; mientras que el automático (AUM) se utilizan los tablespaces de undo. Para utilizar este último, es necesario crear un tablespace undo para cada instancia y fijar el parámetro UNDO_MANAGEMENT del fichero init.ora a AUTO.
Conclusión Al llegar a este punto el alumno habrá cumplido los objetivos de la lección, y por tanto será capaz de:
Utilizar y dimensionar bloques.
Utilizar y dimensionar extensiones.
Utilizar y dimensionar segmentos.
Lección Lección 4
Métodos de acceso a datos
Índice 4.1. Indices 4.2. Indices de clave inversa 4.3. Arboles B 4.4. Mapa de bits 4.5. Tablas organizadas como índices 4.6. Cluster 4.7. Hash cluster 4.8. Particiones
Introducción En esta lección se describen los métodos de acceso disponibles en Oracle 10g para mejorar el acceso a la información almacenada en la BBDD. En segundo lugar se describen otros posibles objetos existentes en Oracle 10g para la gestión de los datos de los usuarios: cluster y tablas particionadas, así como su ámbito y ventajas de utilización. Al finalizar se incluyen una serie de ejercicios de auto evaluación para comprobar los conocimientos aprendidos.
Objetivos En esta lección aprenderás: -
Tipos de métodos de acceso a datos que soporta Oracle 10g para optimizar el acceso a la información.
-
Ámbitos y ventajas de aplicación de cada método de acceso.
-
Descripción y utilización de los clusters y las tablas particionadas en Oracle 10g.
-
Ámbitos y ventajas de aplicación de los clusters y tablas particionadas.
Apartado 4.1: Índices Los índices son estructuras opcionales asociadas con las tablas y clusters. Son estructuras que se almacenan dentro de la BBDD y los usuarios pueden crearlos, modificarlos y borrarlos a través de sentencias SQL. Se pueden crear índices sobre una o más columnas de una tabla para acelerar las sentencias SQL que se ejecuten sobre dicha tabla. Un índice en Oracle 10g permite acceder de forma rápida a los datos de una tabla. Son además el principal causante de la reducción de las operaciones de E/S cuando se usan correctamente. Sus utilidades más importantes dentro del SGBD se pueden resumir en: •
Mejorar el tiempo de búsqueda en función de ciertas condiciones del tipo WHERE condición: •
Igualdad (una o varias filas)
•
Intervalo
•
Prefijo
•
Reducir el tiempo de las operaciones de combinación de tablas.
•
Mejorar las consultas que requieren agrupación u ordenación: •
•
ORDER BY, GROUP BY, DISTINCT, etc.
Facilitar la implementación de restricciones: •
Integridad referencial
•
Unicidad
Se pueden crear varios tipos de índices para una tabla, siempre y cuando la combinación de columnas de cada uno difiera. En el caso de crear índices sobre las mismas columnas deberían cambiarse las combinaciones de las columnas alternando el orden. Por ejemplo: CREATE INDEX nombre_índice ON nombre_tabla (col1, col2); CREATE INDEX nombre_índice ON nombre_tabla (col2, col1); Los índices en Oracle 10g pueden ser únicos (opción unique) o no únicos (opción nonunique), según exijan o no que las columnas del índice admitan o no valores duplicados en distintas filas: CREATE [UNIQUE] INDEX... Si la restricción UNIQUE existe sobre alguna columna de la tabla, el SGBD crea un índice único automáticamente. Por tanto, Oracle no recomienda crear índices únicos explícitamente. Por ejemplo sobre las claves primarias no es necesario definir índices lo que ahorra tiempo al administrador del SGBD. Es recomendable que los índices sean únicos y que, al menos, exista uno por cada clave primaria o ajena de cada tabla, así como por cada columna que contenga valores de búsqueda usuales. Oracle 10g soporta múltiples tipos de indexado que permiten una funcionalidad distinta de cara al rendimiento de la BD: Árboles B sobre las tablas, árboles B sobre los clusters, índices hash sobre clusters, índices de clave inversa e índices de mapas de bits. Los índices son lógica y físicamente Independientes de los datos de las tablas asociadas y son mantenidos dinámica y automáticamente. Por tanto se puede crear o borrar un índice sin ningún efecto lateral sobre los datos de la tabla u otros índices.
Sin embargo a la hora de definir los índices es necesario tener en cuenta el coste en espacio que esto supone, y que además es necesario reorganizarlos al modificarse la información a la que apuntan. Por tanto es conveniente no definir índices si se sabe de antemano que el SGBD no lo va a utilizar y si la clave es muy volátil o muy larga. Cuando se crea un índice se le asigna un segmento de tipo índice para contener sus valores en el tablespace correspondiente. Es preferible que este tablespace no sea el mismo en el que está contenida la tabla asociada y que ambos tablespaces estén almacenados en discos diferentes, para que Oracle pueda leerlos en paralelo. Al crear un índice, Oracle ordena las columnas del índice y almacena el valor de los índices junto con el ROWID de las filas. Los índices pueden crearse en orden ascendente (ASC), descendente (DESC), comprimidos (COMPRESS) o no comprimidos (NOCOMPRESS) En los siguientes apartados se detallan los métodos de acceso a datos más comunes en Oracle 10g.
Apartado 4.2: Índices de clave inversa A veces, puede ocurrir que las inserciones o modificaciones a un índice se concentren en un conjunto pequeño de bloques. Esto puede conllevar una bajada crítica del rendimiento debido a los continuos bloqueos de los mismos bloques del índice. Para solventar esto, Oracle 10g permite generar índices inversos, donde las claves (valores de las columnas) se insertan invirtiendo el orden de sus bytes. Al revertirse los nodos del índice, las inserciones se realizan de forma distribuida a lo largo de todos los nodos hojas. Por ejemplo, si se insertan filas con la clave 101, 102 y 103 en una tabla con un índice regular, las filas se almacenarán probablemente en el mismo nodo hoja. En un índice clave inversa, las claves se convertirían en 101, 201 y 301, y las filas se insertarán de forma dispersa por el segmento del índice. Esta posibilidad es recomendable tan solo para operaciones de acceso a un único valor, ya que las recuperaciones por rango de índice no se beneficiarían de este índice, al no estar ahora las entradas ordenadas alfabéticamente por el valor de la columna. Además son útiles en situaciones en las que el usuario inserta valores ascendentes y borra los valores bajos de la tabla. Para crearlo se añade la cláusula REVERSE al final de la instrucción de creación: CREATE [UNIQUE] INDEX nombre_indice ON nombre_tabla (col1, col2, … coln) REVERSE;
Existe la posibilidad de convertir un índice invertido en uno normal mediante la sentencia: ALTER INDEX nombre_indice REBUILD NOREVERSE. Sin embargo el proceso inverso no puede hacerse, lo que implicaría que sería necesario crearlo de nuevo.
Apartado 4.3: Árboles B Oracle 10g utiliza estructuras basadas en arboles B para almacenar los índices y acelerar el acceso a los datos. Es además el tipo de índice más habitual en Oracle 10g. Si no existieran estos índices, el acceso a los datos sería secuencial y se tendría que recorrer toda la tabla para encontrar el valor buscado. En el mejor de los casos, si existieran n filas, la media de filas leídas sería de n/2. Es por tanto evidente que al aumentar el tamaño de la BBDD el tiempo de acceso a los datos también subiría. Si los valores a los que se quiere acceder estuvieran ordenados, se podrían dividir en bloques de rangos de valores. Estos serían los nodos hojas del árbol B. Cada valor final de un rango, se almacena en un bloque junto con un puntero a otro bloque, construyendo así un árbol de búsqueda en el cual el tiempo medio de acceso a un dato sería de log(n) para n entradas. Este es el principio básico de los índices de Oracle 10g. Los nodos superiores de un árbol B apuntan a los nodos del nivel inferior dentro del árbol. En el nivel más bajo se encuentran los nodos hojas, estos contienen cada uno de los valores de la columna indexada y el rowid de la fila donde se encuentra el resto de datos asociados a ese valor del índice.
Figura 15. Ejemplos de búsquedas en un índice del tipo árbol B
Las ventajas de utilizar la estructura de árbol B son: •
Todos los nodos hoja están a la misma profundidad.
•
La recuperación de cualquier registro lleva aproximadamente el mismo tiempo.
•
Permanecen automáticamente balanceados.
•
Todos los bloques del árbol están llenos de media en ¾.
•
Excelente rendimiento para una amplia variedad de consultas, desde emparejamiento exacto (exact match) a búsquedas por rango de valores (ver Figura 15).
•
Inserts, updates, y deletes son eficientes, manteniéndose el orden de clave.
•
El rendimiento es bueno tanto para tablas grandes y pequeñas, y no se degrada con el aumento del tamaño de las mismas.
La sentencia básica de creación de este tipo de índices es la siguiente: CREATE [UNIQUE] INDEX nombre_indice ON nombre_tabla (col1, col2, ... coln) [ATRIBUTOS]; donde: •
UNIQUE: indica que la combinación que la combinación de valores en las columnas indexadas debe ser único.
•
ATRIBUTOS: NOSORT | SORT,
REVERSE,
NOCOMPRESS, COMPUTE STATISTICS, etc.
COMPRESS,
Apartado Apartado 4.4: Mapa de bits En este tipo de índice, para cada valor de la clave se utiliza un mapa de bits en lugar del rowid. Cada bit de este mapa se corresponde con un posible rowid. Si el bit tiene el valor 1, quiere decir que esa fila con el correspondiente rowid contiene el valor de la clave, en caso contrario aparecería un 0 (ver Figura 16). Una función de mapeo convierte la posición del bit en un rowid, por tanto este índice proporciona la misma funcionalidad que los índices regulares basados en árboles B, pero utilizando una representación interna distinta.
Figura 16. Ejemplo de índice mapa de bits sobre una tabla Si el número de valores que difieren en la clave a indexar es pequeño, los índices de mapa de bits son muy eficientes desde el punto de vista del ahorro del espacio. En general las columnas cuyos valores se repiten más de cien veces, son buenas candidatas para un índice de mapas de bits. Además si el índice a crear se corresponde con varias condiciones dentro de la cláusula WHERE, a través de operadores AND,OR, etc, este tipo de índice es muy eficiente. Las filas que satisfacen algunas, pero no todas, de las condiciones son filtradas antes de acceder a la tabla. Esto mejora el tiempo de acceso, a veces de forma drástica.
Los índices de mapa de bits, pueden indexar filas que contengan valores NULL, al contrario que la mayoría de los otros tipos de índices (basados en árboles B). La indexación de valores nulos puede ser útil para la ejecución de algunas sentencias SQL, como por ejemplo sentencias de agregado del tipo COUNT. La sentencia básica de creación de este tipo de índices es la siguiente: CREATE BITMAP INDEX nombre_indice ON nombre_tabla (col1, col2, ... coln) [ATRIBUTOS]; donde: ATRIBUTOS:
NOSORT
|
SORT,
REVERSE,
NOCOMPRESS, COMPUTE STATISTICS, etc.
COMPRESS,
Apartado 4.5 4.5: Tablas organizadas como índices Es una tabla normal con un índice en una o más de sus columnas. En lugar de mantener dos segmentos separados para la tabla y el índice árbol B, el SGBD mantiene un único índice del tipo árbol B con el contenido de ambas: •
El valor de la clave primaria.
•
Los valores de la otra columna para la fila correspondiente.
Cada fila del índice contiene los valores de la clave y del resto de los atributos no claves: Su utilización suele darte en tablas que se consultan por la clave primaria con pocas columnas. Gracias a esto los datos son recuperados más rápidamente que si hubiesen sido almacenados en tablas normales. Las ventajas de este tipo de índices son: •
Acceso más rápido a las filas de las tablas ya que están en el mismo bloque.
•
Acceso secuencial y por rangos por la clave primaria o un sufijo.
•
Ahorro en espacio: la clave se guarda una sola vez.
Sin embargo es conveniente no utilizar en tablas con filas grandes ya que entonces su rendimiento se ve afectado.
Apartado 4.6: Cluster Un cluster es un grupo de una o más tablas que comparten los mismos bloques de datos, porque comparten columnas comunes y a menudo se utilizan juntas en consultas en operaciones del tipo join (ver Figura 17). En este tipo de tablas la clave sólo se almacena una vez, por lo que se produce un ahorro de espacio dentro de la BBDD. Es obligatorio construir un índice de cluster, para las columnas de la clave. El índice que se construye se basa en el árbol B de búsqueda. Además no puede ejecutarse ninguna sentencia LMD en las tablas del cluster si no existe su índice correspondiente. Este índice será utilizado para localizar una fila dentro del mismo, ya que apunta al bloque asociado con cada valor de clave del cluster.
Figura 17. Ejemplo de almacenamiento en tablas normales o cluster
Su utilización además de mejorar la eficiencia del SGBD en tablas con joins frecuentes, disminuye la E/S de disco y mejora el tiempo de acceso. No se recomienda su uso cuando: •
El valor clave se modifica a menudo.
•
En tablas que se recorren completas con asiduidad.
•
Si las filas que se agrupan juntas varían en número y/o superan el tamaño de uno o dos bloques.
Por último es necesario resaltar, que las búsquedas de tablas completas son generalmente más lentas en tablas cluster que en tablas normales.
Apartado 4.7: Hash cluster En este cluster en lugar del índice tradicional, se utiliza una función de dispersión para calcular la ubicación de una fila. La función hash usa una clave de cluster que puede ser definida por el usuario o generada por el sistema. Cuando una fila es insertada dentro de una de las tablas en un cluster de este tipo, las columnas de la clave hash son utilizadas para calcular un valor también hash. Por último la fila es almacenada basándose en ese valor. Es eficiente para consultas con condiciones de igualdad ya que facilita un único acceso, pero presenta la desventaja de ocupar más espacio.
Apartado 4.8: Particiones
El particionamiento en Oracle 10g permite a los usuarios descomponer, en cualquier momento, tablas e índices en trozos más pequeños y manejables llamados particiones que son almacenados en segmentos separados. La noción de partición permite manejar tablas que almacenan grandes volúmenes de datos de forma óptima, y permiten que un gran número de procesos pueda acceder a las mismas de forma concurrente. Se recomienda el uso de particiones cuando: •
La tabla tiene un tamaño superior a 2 GB.
•
Tablas que mantienen históricos.
Todas las particiones de una tabla o índice deberían contener las mismas columnas y definiciones de restricciones, pero cada partición puede tener sus propios parámetros de almacenamiento y cada partición puede residir en tablespaces separados. Oracle 10g soporta diferentes rangos de particionamiento: •
Particionamiento por Rango: se hace corresponder datos en particiones haciendo uso de los rangos de los valores de la clave de particionamiento.
•
Particionamiento por Lista: permite especificar explícitamente la correspondencia entre las filas y las particiones. Se especifica una lista de valores discretos para la clave de particionamiento. No se soportan claves de particionamiento formadas por varios atributos.
•
Particionamiento por Hash: la correspondencia entre las filas y las particiones se realiza a través de una función de hash. Es una opción útil cuando: o Se desconoce la correspondencia en función de los rangos. o El rango de las particiones difiere sustancialmente o es difícil balancearla manualmente.
Conclusión En esta lección se han presentado los principales métodos de acceso a datos, detallando las ventajas e inconvenientes de cada uno.
Conclusión General Al finalizar esta unidad didáctica has debido
comprender aspectos
fundamentales relativos al almacenamiento de la información dentro de un SGBD Oracle 10g. Los puntos fundamentales tratados han sido: •
Estructuras lógicas de almacenamiento utilizadas por Oracle 10g.
•
Relaciones existentes entre las diferentes estructuras lógicas.
•
Gestión del almacenamiento de la información en un SGBD Oracle 10g.
•
Herramientas de administración incluidas en Oracle 10g para la gestión del espacio en disco.
•
Métodos de acceso a datos que soporta Oracle 10g para optimizar el acceso a la información.
Glosario de términos AUM
Automatic Undo Management:
BBDD
Base de Datos.
DD
Diccionario de Datos.
EM
Enterprise Manager.
EX
ExaBytes.
LMD
Lenguaje de Manipulación de Datos.
MUM
Manual Undo Management
PB
PetaBytes.
PMON
Process Monitor
ROWID
Identificador de Fila (Row Identification).
SQL
Structured Query Language (Lenguaje de Consulta Estructurado)
SGBD
Sistema de Gestión de Base de Datos.
TB
TeraBytes.
URL
Uniform Resource Locator
Bibliografía •
Abramson, I., 2004]. Oracle database 10g : guía de aprendizaje. Capítulo 1.
•
[Arun Kumar R., 2005]. Oracle® Database 10g Insider Solutions. Sams Publishing. Capítulo 1.
•
[Dawes,C. & Bryla, B., 2004] OCA: Oracle 10g Administration I Study Guide. Sybex. Capítulo 1.
•
[Greenwald, R. & Stackowiak, R., 2004]. Oracle Essentials, 3e: Oracle Database 10g. Capítulo 2, 4 & 11.
•
[Kreines, D. C., 2003]. Oracle Data Dictionary, Pocket Reference.
•
[Kyte, T., 2005]. Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions. Apress. Capítulo 2, 3, 4, 5.
•
[Loney, K., 2004]. Oracle Database 10g: The Complete Reference. Capítulo 1.
•
[Oracle, 10g
2006].
Release
2
Oracle® (10.2).
Database Parte
I
&
Administrator's II.
(url:
Guide
http://download-
uk.oracle.com/docs/cd/B19306_01/server.102/b14231/toc.htm) •
[Oracle, 2006]. Oracle® Database Concepts 10g Release 2 (10.2). (url: http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/toc.htm ).
•
[Perez, C., 2005]. Oracle 10g: administración y análisis de bases de datos. Capítulo 14.
