BASES DE DATOS

PRESENTADO POR

Manuela García Monsalve

ID: 593892

PRESENTADO A

Santiago Salazar Fajardo

NRC: 6672

CORPORACIÓN UNIVERSITARIA MINUTO DE DIOS

BOGOTA D.C

8 DE MAYO 2019
 1. Describa las unidades lógicas de almacenamiento utilizadas por Oracle. Dé un
ejemplo de cómo Oracle almacenaría una tabla que usted desea crear y cómo puede
optimizar el acceso a la información de dicha tabla usando parámetros de
almacenamiento. TABLESPACE, DATAFILE, EXTENDS, SEGMENTOS,
BLOQUES…

Una base de datos Oracle es una colección de datos tratada como una unidad. El propósito
general es almacenar y recuperar información relacionada.

Una instancia Oracle consta de una estructura de memoria, llamada Área Global del Sistema
(SGA), y de unos procesos background utilizados por el servidor Oracle para manejar una
base de datos. Cada instancia Oracle puede abrir y utilizar sólo una base datos en cualquier
punto y momento.

Figura 1

Estructura lógica
​ Esquemas y objetos del esquema:
Un esquema es una colección de objetos de la base de datos. Los objetos del esquema son
estructuras lógicas que hacen referencia directa a datos de la base de datos (tablas, vistas,
secuencias, procedimientos almacenados, sinónimos, índices, clusters y enlaces con otras
bases de datos).
b. ​ Data Base:
Es un conjunto de datos que tienen un representan una información captada del mundo real,
con ellos se puede realizar diversos procesos.

TABLESPACE
Un tablespace es un almacén lógico de los ficheros de la base de datos. Cada tablespace posee
uno o varios ficheros (datafiles) donde almacena toda la información; estos ficheros deben
tener una estructura lógica.
Cuando se crea una base de datos, hay que crear al menos un tablespace, que por defecto es
SYSTEM. Igualmente, cuando se crea un tablespace, se debe indicar al menos un datafile que
formará parte de este datafile (posteriormente se pueden añadir más datafiles del tablespace).
El datafile es un fichero físico al que tendremos que asignar un directorio, un nombre y un
tamaño inicial que posteriormente se podrá ampliar según las necesidades (y de las
limitaciones) de la instalación. Este tablespace es el que contendrá la información de los
usuarios SYS y SYSTEM que son los usuarios que tienen la información necesaria para que
funcione la base de datos.
Por tanto, el tablespace SYSTEM es una pieza clave para el buen funcionamiento de nuestra
base de datos, por lo que es una buena práctica crear el menos otro tablespace donde
almacenar el resto de usuarios que vayamos creando en nuestra base de datos. Podría
ahorrarnos:
– Un bloqueo completo de la base de datos si ocurre algo grave al tablespace SYSTEM.
– Llenar el tablespace SYSTEM pudiendo provocar la parálisis de toda la base de datos.

El uso de múltiples espacios de tablas le permite una mayor flexibilidad para realizar
operaciones de base de datos. Cuando una base de datos tiene múltiples espacios de tabla,
puede:
- Separe los datos de usuario de los datos del diccionario de datos para reducir la
contención de E / S.
- Separe los datos de una aplicación de los datos de otra para evitar que varias
aplicaciones se vean afectadas si se debe desconectar un espacio de tablas.
- Almacene diferentes archivos de datos de diferentes espacios de tabla en diferentes
unidades de disco para reducir la contención de E / S.
- Desconecte los espacios de tablas individuales mientras otros permanecen en línea, lo
que proporciona una mejor disponibilidad general.
- Optimice el uso del espacio de tablas reservando un espacio de tablas para un tipo
particular de uso de base de datos, como actividad de alta actualización, actividad de
solo lectura o almacenamiento temporal de segmentos.
- Copia de seguridad de espacios de tabla individuales.

Manipulando tablespaces (como usuario system):

– Crear un tablespace TEST, de 100MB, en el directorio /users/oradata/orcl:
create tablespace TEST datafile '/users/oradata/orcl/test01.dbf' size 100M;

– Aumentar de tamaño un tablespace modificando su tamaño:

alter datafile '/users/oradata/orcl/test01.dbf' resize 150M;

– Aumentar de tamaño un tablespace añadiendo más datafiles:

alter tablespace TEST add datafile '/users/oradata/orcl/test02.dbf' size 50M;

– Borrar un tablespace:
drop tablespace TEST;
* Otros usos de tablespace:

– Estado de un tablespace:
Un tablespace puede estar online u offline, esto indica si se puede operar con él o no. Para
conocer el estado de un tablespace se puede consultar con la siguiente sentencia:
select tablespace_name, status from dba_tablespaces;

​DATA FILE
Los datafiles son los ficheros físicos en los que se almacenan los objetos que forman parte de
un tablespace. Un datafile pertenece solamente a un tablespace y a una instancia de base de
datos. Un tablespace puede estar formado por uno o varios datafiles. Cuando se crea un
datafile, se debe indicar su nombre, su ubicación o directorio, el tamaño que va a tener y el
tablespace al que va a pertenecer. Además, al crearlos, ocupan ya ese espacio aunque se
encuentran totalmente vacíos, es decir, Oracle reserva el espacio para poder ir llenándolo
poco a poco con posterioridad. Por supuesto, si no hay sitio suficiente para crear un fichero
físico del tamaño indicado, se producirá un error y no se creará dicho fichero.

EXTEND
es uno de los métodos de colección de Oracle PL / SQL que se utiliza con tablas anidadas y
VARRAYS para agregar elementos únicos o múltiples a la colección. Tenga en cuenta que
EXTEND no se puede utilizar con matrices asociativas. EXTEND tiene tres formas:
EXTEND, que agrega una sola instancia NULL.
EXTEND ( n ) que agrega múltiples instancias NULL. El número de instancias se especifica
mediante n .
EXTENDER ( n, m ) que adjunta n copias de la instancia m a la colección.
Ejemplo:
DECLARE
TYPE PSOUG_TAB IS TABLE OF NUMBER;
PTAB PSOUG_TAB;
BEGIN
PTAB := PSOUG_TAB();
PTAB.EXTEND;
PTAB(1) := 100;
DBMS_OUTPUT.PUT_LINE('VALUE AT INDEX(1) IS '||PTAB(1));
PTAB.EXTEND(5,1);
DBMS_OUTPUT.PUT_LINE(´VALUE AT INDEX(4) IS '||PTAB(4));
END;
VALUE AT INDEX(1) IS 100
VALUE AT INDEX(4) IS 100

Segment:
Un segmento almacena la información de una estructura lógica de Oracle dentro de un
Tablespace. Está formado por una o más extensiones y, a medida que va creciendo el
segmento se van asignando nuevas extensiones al mismo. Hay cuatro tipos de segmentos: de
datos, de índices, temporales y de rollback.
Tendremos segmentos de datos para tablas o clusters, segmentos de índices para índices,
segmentos de rollback para poder deshacer o rehacer cambios por transacciones y segmentos
temporales.

Un segmento de datos es el lugar donde se almacenan todos los datos de una tabla que no esté
particionada o que no forme parte de un cluster, de una partición de una tabla particionada o,
de un cluster de tablas. Se crea el segmento de datos a la hora de ejecutar la sentencia create
que crea la tabla, cluster o partición. En dicha sentencia se indican también los valores de la
cláusula storage, en el cuál se va a determinar la forma en que dicho segmento va a ir
asignando y designando las extensiones.

El nivel de almacenamiento de base de datos lógica por encima de un punto que se llama un
segmento. Un segmento de es un conjunto de extensiones asignadas a una estructura lógica
determinada. Por ejemplo, los diferentes tipos de segmentos incluyen los siguientes:

· Data Segment
Cada uno no agrupado tabla tiene un segmento de datos. Todos los de la tabla de los datos se
almacenan en las extensiones de su segmento de datos. Cada grupo tiene un segmento de
datos. Los datos de cada tabla en el grupo son almacenados en el segmento de datos del
cluster.
· Index Segment
Cada índice tiene una serie de sesiones de índice que almacena todos sus datos.
· Rollback Segment
Uno o más segmentos rollback son creados por la base de datos administrador de una base de
datos para almacenar temporalmente "deshacer" la información. Esta información se utiliza:
· para generar la información base de datos de lectura consistente
· durante la recuperación de la base de datos comprometido a revertir las transacciones
para los usuarios.
· Temporary Segment
Se crean cuando un Oracle SQL declaración de las necesidades de un área de trabajo
temporal para completar la ejecución.
Cuando la instrucción termine su ejecución, el temporal use extensiones segmento son
devueltos al sistema para su uso futuro.
Oracle asigna dinámicamente el espacio, cuando las extensiones existentes de un segmento se
lleno. Por lo tanto, cuando las extensiones existentes de un segmento están llenas asigna otra
medida de ese segmento, según sea necesario. Debido a que las extensiones están asignadas
como necesarias, las extensiones de un segmento pueden o no ser contiguo en el disco.

SEGMENTOS
Un segmento almacena la información de una estructura lógica de Oracle dentro de un
Tablespace. Está formado por una o más extensiones y, a medida que va creciendo el
segmento se van asignando nuevas extensiones al mismo. Hay cuatro tipos de segmentos: de
datos, de índices, temporales y de rollback.

Segmentos de datos e índices

En un segmento de datos se almacenan todos los datos de una tabla que no esté particionada o
que no forme parte de un cluster, de una partición de una tabla particionada o, de un cluster
de tablas. Se crea el segmento de datos a la hora de ejecutar la sentencia create que crea la
tabla, cluster o partición. En dicha sentencia se indican también los valores de la cláusula
storage, que se han explicado en el capítulo que hace referencia a las extensiones, y va a
determinar la forma en que dicho segmento va a ir asignando y desasignando las extensiones.
Estructuras de Oracle
<< Anterior ParteSiguiente Parte >>

Un segmento almacena la información de una estructura lógica de Oracle dentro de un

Tablespace. Está formado por una o más extensiones y, a medida que va creciendo el
segmento se van asignando nuevas extensiones al mismo. Hay cuatro tipos de segmentos: de
datos, de índices, temporales y de rollback.

. Segmentos de datos e índices

En un segmento de datos se almacenan todos los datos de una tabla que no esté particionada o
que no forme parte de un cluster, de una partición de una tabla particionada o, de un cluster
de tablas. Se crea el segmento de datos a la hora de ejecutar la sentencia create que crea la
tabla, cluster o partición. En dicha sentencia se indican también los valores de la cláusula
storage, que se han explicado en el capítulo que hace referencia a las extensiones, y va a
determinar la forma en que dicho segmento va a ir asignando y desasignando las extensiones.
En el caso de los índices, existe un segmento para cada índice no particionado o para cada
partición de un índice particionado. Al igual que con las tablas, los segmentos de índices se
crean al ejecutar la sentencia de creación de índices en la cual, también se pueden indicar
valores para la cláusula storage y así parametrizar la forma en que se le asignan las
extensiones a medida que vaya creciendo.
​Segmentos temporales
Cuando Oracle procesa las consultas se puede ver en la necesidad de utilizar espacio en disco
para poder llevar a cabo algunas partes del parsing (análisis) y de la ejecución de la misma.
Solamente utilizará este tipo de segmentos cuando no pueda realizar la consulta íntegramente
en memoria o cuando no pueda buscarse un método alternativo para realizarla utilizando los
índices.
Hay varios tipos de sentencias en las que Oracle se ve en la obligación de utilizar los
segmentos temporales:

SELECT ... ORDER BY.

CREATE INDEX.
SELECT ... GROUP BY.
SELECT ... UNION ...
SELECT DISTINCT ...
SELECT INSERSEC ...
SELECT MINUS ...
Se puede dar el caso en el que algunas consultas en las que intervengan joins en los que no
haya índices que faciliten la unión y en las que se den a la vez sentencias del tipo "group by"
y "order by" o incluso "distinct", en las que no solo se requiere de un nuevo segmento
temporal sino que pueden adquirirse dos segmentos para poder realizar dichas consultas.

BLOQUES
Un bloque es la unidad mínima de almacenamiento de información de Oracle. A los bloques
también se les conoce como "bloques de datos", "bloques lógicos" o "bloques oracle". Cada
uno de estos bloques está formado por un número determinado de bloques del sistema
operativo. A la hora de crear una nueva base de datos se debe indicar cuántos bloques de
sistema operativo formarán un bloque de datos o bloque oracle. Es muy importante decidir
bien este valor de antemano ya que una vez creada la base de datos ya no se puede modificar
más que en migraciones a versiones más actuales del producto.

Un bloque de datos es la mínima unidad de Lectura / Escritura en una base de datos Oracle,
es decir, Oracle no lee y escribe en bloques del sistema operativo sino que lo hace en
unidades lógicas que son los bloques de datos y que varían de una base de datos a otra en la
misma máquina ya que es un valor que se debe indicar en la creación de cada base de datos
Oracle.
Oracle recomienda que el tamaño de un bloque de datos o, data block, sea siempre un
múltiplo del bloque de datos del sistema operativo.
PL/SQL es un lenguaje estructurado con bloques. Un bloque PL/SQL es definido por las
palabras clave DECLARE, BEGIN, EXCEPTION, y END, que dividen el bloque en tres
secciones

1. Declarativa: sentencias que declaran variables, constantes y otros elementos de código, que
después pueden ser usados dentro del bloque
2. Ejecutable: sentencias que se ejecutan cuando se ejecuta el bloque
3. Manejo de excepciones: una sección especialmente estructurada para atrapar y manejar
cualquier excepción que se produzca durante la ejecución de la sección ejecutable
Sólo la sección ejecutable es obligatoria. No es necesario que usted declare nada en un
bloque, ni que maneje las excepciones que se puedan lanzar.

Un bloque es en sí mismo una sentencia ejecutable, por lo que se pueden anidar los bloques
unos dentro de otros.

Aquí hay algunos ejemplos:

El clásico “¡Hola Mundo!” es un bloque con una sección ejecutable que llama al
procedimiento DBMS_OUTPUT.PUT_LINE para mostrar texto en pantalla:

BEGIN
DBMS_OUTPUT.put_line('¡Hola Mundo!');
END;

Las funciones y procedimientos —tipos de bloques con un nombre— son discutidos con
mayor detalle más adelante en este artículo, así como los paquetes. En pocas palabras, sin
embargo, un paquete es un contenedor de múltiples funciones y procedimientos. Oracle
extiende PL/SQL con muchos paquetes incorporados en el lenguaje.

El siguiente bloque declara una variable de tipo VARCHAR2 (un string) con un largo
máximo de 100 bytes para contener el string ‘¡Hola Mundo!’. Después, el procedimiento
DBMS_OUTPUT.PUT_LINE acepta la variable, en lugar del literal, para desplegarlo:

DECLARE
l_mensaje VARCHAR2(100) := '¡Hola Mundo!';
BEGIN
DBMS_OUTPUT.put_line(l_mensaje);
END;

Note que he llamado a la variable l_mensaje. Normalmente uso el prefijo l_ para variables
locales —variables definidas dentro del código de un bloque— y el prefijo g_ para variables
globales definidas en un paquete.

El siguiente ejemplo de bloque agrega una sección de manejo de excepciones que atrapa
cualquier exception (WHEN OTHERS) que pueda ser lanzada y muestra el mensaje de error,
que es retornado por la función SQLERRM (provista por Oracle).

DECLARE
l_mensaje VARCHAR2(100) := '¡Hola Mundo!';
BEGIN
DBMS_OUTPUT.put_line(l_mensaje);
EXCEPTION
WHEN OTHERS
THEN
DBMS_OUTPUT.put_line(SQLERRM);
END;

El siguiente ejemplo de bloque demuestra la habilidad de PL/SQL de anidar bloques dentro

de bloques así como el uso del operador de concatenación (||) para unir múltiples strings.

DECLARE
l_mensaje VARCHAR2(100) := '¡Hola';
BEGIN
DECLARE
l_mensaje2 VARCHAR2(100) := l_mensaje || ' Mundo!';
BEGIN
DBMS_OUTPUT.put_line(l_mensaje2);
END;
EXCEPTION
WHEN OTHERS
THEN
DBMS_OUTPUT.put_line(DBMS_UTILITY.format_error_stack);
END;

2. 2. ¿Qué elementos de la memoria principal asociados al funcionamiento de un SMBD

pueden ser configurados? ¿Qué opciones brinda un SMBD para configurar dichos
parámetros?

Sistema Manejador de Bases de Datos

"un sistema manejador de base de datos, es un sistema computacional cuya finalidad general
es almacenar información y permitir a los usuarios recuperar y actualizar esa información con
base en peticiones. La información en cuestión puede ser cualquier cosa que sea de
importancia para la empresa u organización; es decir, todo lo que sea necesario como auxiliar
en el proceso general de su administración." (Date, 2001).

"Se puede definir el Sistema Manejador de Base de Datos (SMBD) como un conjunto
coordinado de programas, procedimientos, lenguajes, etc., que suministra a los distintos tipos
de usuarios los medios necesarios para describir y manipular los datos almacenados en la
base, garantizando su seguridad." (Miguel y Piattini, 1999).
la finalidad de un sistema manejador de bases de datos es establecer las adecuadas interfaces
entre ésta y los diferentes tipos de usuarios (diseñadores, administradores, analistas,
programadores y usuarios finales). También podemos afirmar que las operaciones típicas que
debe realizar un SMBD pueden resumirse en aquellas que afectan a la totalidad de los datos y
las que tienen lugar sobre registros concretos.

Función de definición o descripción

La función de descripción o definición debe permitir al diseñador de la base de datos

especificar los elementos de datos que la integran, su estructura y las relaciones que existen
entre ellos, las reglas de validación, así como las características de tipo físico y las vistas
lógicas de los usuarios. Esta función, realizada por el lenguaje de descripción o definición de
datos (LDD) propio de cada SMBD, debe suministrar los medio para definir las tres
estructuras de datos (externa, lógica e interna), especificando las características de los datos a
cada uno de estos niveles.

Función de manipulación
La función de manipulación nos permite consultar la base de datos, ya sea la totalidad de la
información o por partes. También nos permite realizar actualizaciones (inserción, borrado y
modificación). En general, podemos observar que la función de manipulación permite a los
usuarios de la base, informáticos o no, buscar, añadir, suprimir o modificar los datos de la
misma, siempre de acuerdo con las especificaciones y normas de seguridad dictadas por el
administrador (DBA).

La función de manipulación se llevará a cabo por medio de lenguaje de manipulación de

datos (LMD) que ofrece los instrumentos necesarios para la realización de estas tareas.

Función de control o utilización

La función de control reúne todas las interfaces que necesitan los diferentes usuarios para
comunicarse con la base de datos y proporciona un conjunto de procedimientos para el
administrador. Las exigencias o necesidades de cómo utilizar la base de datos son diferentes,
según los tipos de procesos y según los usuarios. De manera especial, esta función debe
integrar una serie de instrumentos que faciliten las tareas del administrador.

El motor de la base de datos​ acepta peticiones lógicas de los otros subsistemas del SGBD, las
convierte en su equivalente físico y accede a la base de datos y diccionario de datos en el
dispositivo de almacenamiento.
El subsistema de definición de datos​ ayuda a crear y mantener el diccionario de datos y
define la estructura del fichero que soporta la base de datos.
El subsistema de manipulación de datos​ ayuda al usuario a añadir, cambiar y borrar
información de la base de datos y la interroga para extraer información. El subsistema de
manipulación de datos suele ser el interfaz principal del usuario con la base de datos. Permite
al usuario especificar sus requisitos de la información desde un punto de vista lógico.
El subsistema de generación de aplicaciones​ contiene utilidades para ayudar a los usuarios en
el desarrollo de aplicaciones. Usualmente proporciona pantallas de entrada de datos,
lenguajes de programación e interfaces.
El subsistema de administración​ ayuda a gestionar la base de datos ofreciendo
funcionalidades como almacenamiento y recuperación, gestión de la seguridad, optimización
de preguntas, control de concurrencia y gestión de cambios.

3​. Los índices se usan para mejorar el rendimiento de las operaciones sobre una tabla.
En general mejoran el rendimiento las SELECT y empeoran (mínimamente) el rendimiento
de los INSERT y los DELETE.
Una vez creados no es necesario nada más, oracle los usa cuando es posible (ver EXPLAIN
PLAN).
En oracle existen tres tipos de índices:
TABLE INDEX

CREATE [UNIQUE|BITMAP] INDEX [esquema.]index_name

ON [esquema.]table_name [tbl_alias]
(col [ASC | DESC]) index_clause index_attribs

Bitmap Join Index:

CREATE [UNIQUE|BITMAP] INDEX [esquema.]index_name
ON [esquema.]table_name [tbl_alias]
(col_expression [ASC | DESC])
FROM [esquema.]table_name [tbl_alias]
WHERE condition [index_clause] index_attribs
Cluster Index:
CREATE [UNIQUE|BITMAP] INDEX [esquema.]index_name
ON CLUSTER [esquema.]cluster_name index_attribs

Un ejemplo de índices basados en funciones para búsquedas en mayúsculas:

Copiar

CREATE INDEX idx_case_ins ON my_table(UPPER(empname));

SELECT * FROM my_table WHERE UPPER(empname) = 'KARL';

es importante tener en cuenta que para cualquiera de los casos de deben considerar la
cantidad de registros o tuplas que se encuentran en la base de datos así como los recursos de
memoria que se poseen, de tal manera que se pueda tomar una decisión en cuanto el
mejoramiento del rendimiento de las consultas en la base de dato.

en la mayoría de los casos los sistemas gestores de bases de datos generan un índice
automáticamente para los valores de las tablas que se indican como llaves primaria.
de tal manera que si se tiene la siguiente estructura con los siguientes campos para la
siguiente tabla
Usuarios:
Id
Nombre
Fecha_Nacimiento
Teléfono

Normalmente se opta por asignar la clave primaria al Id, de tal manera que este se creará
también como un índice que a su vez también es único.
4. ¿Qué criterios deben analizarse para optar por el uso de un índice?

A. Elección de tablas y columnas a indexar

A continuación se dan una serie de consideraciones recomendables para determinar cuándo se

debe crear un índice sobre una tabla:

• Si al acceder a una tabla la consulta visita un número pequeño de bloques (sobre el total de
bloques que componen la tabla) filtrando por la(s) columna(s) que compongan) el índice. A
este concepto se le denomina selectividad de bloque que debe prevalecer sobre el de
selectividad de columna.
• Para mejorar el rendimiento de las joins sobre varias tablas, indexar las columnas empleadas
en la join. Las FKs han de indexarse siempre salvo que se cumplan TODOS los siguientes
supuestos:

o Que no se realicen nunca borrados en la tabla padre.

o Que nunca se actualice en la tabla padre la(s) columna(s) referenciada(s) en la FK.
o Que nunca se realicen consultas con joins de la tabla padre a la hija.

• Todas las tablas sin excepción (sean pequeñas o grandes) deberían tener una PK y por tanto
al menos un índice. La creencia de que una tabla pequeña no necesita índices para acceder a
ella puede llevar a un volumen desorbitado de lecturas lógicas si dicha tabla es accedida
frecuentemente por la aplicación. Si una columna no selectiva es la más frecuentemente
utilizada n sentencias sobre tablas grandes, posiblemente sería necesario revisar el diseño de
la aplicación o de los datos.

Si una columna muy selectiva no es muy usada en las condiciones de sentencias, sólo es
recomendable crear un índice sobre ella si se trata de una foreign key. Para determinar que
columnas son candidatas (siempre teniendo en cuenta el concepto de selectividad de bloque):

• La columna tiene valores únicos o prácticamente no tiene valores repetidos.

• En las columnas con un rango grande de valores diferentes (siempre y cuando se
empleen en las consultas), normalmente se creará un índice convencional (B*Tree) pero
dependiendo de otros factores se consideraría cualquier otro tipo (bitmap, fbi, etc.).
• Si se van a realizar consultas donde los filtros a aplicar son múltiples combinaciones
sobre varias columnas, puede ser óptimo crear índice bitmap (siempre teniendo en cuenta las
características de estos índices).

• Las columnas que, aunque contengan valores nulos, las consultas solicitan todas las filas
que contienen valores pueden ser indexadas. En el caso de que se observe que el índice no es
utilizado cuando se realizan consultas del tipo WHERE COL_X IS NOT NULL y se esté
absolutamente seguro de que debería ser utilizado, se recomienda emplear la siguiente
sintaxis WHERE COL_X > - 9,99 * POWER (10,25) como solución temporal. No son
candidatas a indexar, en principio, las siguientes columnas:

• La columna contiene nulos y no se realizan siempre consultas que devuelvan

valores (salvo en el caso de que las filas con valores nulos fueran pocas y
resultara necesario conocer precisamente dichos registros, donde un índice del
tipo bitmap o uno basado en función podría indexar los valores nulos).

• Las columnas con tipos LONG y LONG RAW no pueden ser indexadas.

B. Orden de columnas a indexar para optimizar rendimiento

El orden de las columnas al crear un índice puede afectar de forma notable al rendimiento.
Normalmente, se deben especificar las columnas más utilizadas en las consultas. Si por
ejemplo se crea un índice para acelerar las consultas sobre las columnas COL_A, COL_B y
COL_C, las consultas deberían acceder a COL_A, a COL_A y COL_B. Si accede a COL_B,
a COL_C o a COL_B y a COL_C, el índice podría no llegar a utilizarse aunque el camino de
acceso INDEX SKIP SCAN (introducido en 9i) permitiría utilizarlo. Será el CBO el que
determine la idoneidad de su uso.

C. Limitar el número de índices sobre la tabla

A pesar de que una tabla soporta múltiples índices, hay que tener en cuenta que esto llevaría
una sobrecarga adicional, sobre todo en operaciones de INSERT y DELETE, dado que todos
los índices de la tabla deben ser actualizados junto con la tabla (se debe tener en cuenta
también que si se actualiza la tabla, los índices implicados deben ser actualizados también).

Por lo tanto, se debe tener muy en cuenta el tipo de transacciones que se van a lanzar contra
la tabla, la naturaleza de la misma; si una tabla se usa básicamente para consultas o es una
tabla read-only, el tener varios índices puede ser efectivo. Si, por el contrario, la tabla es
modificada de forma frecuente y pesada, será preferible que tenga un número menor de
índices.

En resumen, se deberán crear todos los índices que sean necesarios pero siendo su número tan
limitado como sea posible.

D. Índices concatenados vs. varios índices de una sola columna

La selectividad de una columna, nunca debe ser considerada a la hora de considerar el orden
de las columnas de un índice. Una consulta del tipo:
select * from t where a = :n1 and b = :n2;
será resuelta de la misma forma (aproximadamente) independientemente de que el índice
concatenado haya sido creado como (A, B) o (B, A) e independientemente de la selectividad
de las columnas. La única consideración para determinar el orden de las consultas será
precisamente el tipo de éstas Si la mayoría de las consultas son del tipo:
select * from t where a = :n1 and b = :n2;
select * from t where b = :n2
el índice debería ser creado como (B, A).

Cuando se va a crear un índice concatenado, debe valorarse si la selectividad de este índice va

a ser considerablemente mayor con varias columnas que con una. Por ejemplo, para una tabla
de POBLACIONES, un índice por el campo NOMBRE_POBLACION tendrá la misma
selectividad que otro por los campos NOMBRE_POBLACION y PROVINCIA (habrá muy
pocas poblaciones que se llamen igual en distintas provincias). En este caso, no interesará un
índice concatenado, ya que con una sola columna puede localizarse el registro consultado.
Hay una sola excepción para este caso, y es que en la consulta lo normal sea pedir
únicamente la provincia, pues en ese caso se ahorra el acceso a la tabla, utilizando solamente
el índice para resolverla.

Si se tienen varias columnas muy selectivas, podemos pensar en crear varios índices, cada
uno de ellos con una columna, si las consultas de nuestra aplicación tienen condiciones de
igualdad para esas columnas unidas por AND. Por ejemplo, para sentencias del tipo

SELECT * FROM emp WHERE job = 'ANALISTA' AND deptno = 20;

Podría interesar tener dos índices, uno para cada columna. El plan de ejecución sería el
siguiente:

--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 20 | 2280 | 10 |
| 1 | TABLE ACCESS BY INDEX ROWID | EMP | 20 | 2280 | 10 |
| 2 | BITMAP CONVERSION TO ROWIDS | | | | |
| 3 | BITMAP AND | | | | |
| 4 | BITMAP CONVERSION FROM ROWIDS| | | | |
|* 5 | INDEX RANGE SCAN | IX_DEPTNO | 611 | | 2 |
| 6 | BITMAP CONVERSION FROM ROWIDS| | | | |
|* 7 | INDEX RANGE SCAN | IX_JOB | 611 | | 2 |

Se hace un RANGE SCAN de cada índice y, a continuación, una conversión bitmap de

ROWID (que sustituye al path de acceso obsoleto AND-EQUAL proveniente del RBO), la
operación AND de los bitmaps y su posterior transformación a ROWID para el acceso a la
tabla.

Aquí debe valorarse cómo se harán menos lecturas: si en un INDEX RANGE SCAN del
índice concatenado, seguido del acceso a tabla por ROWID; o con los dos INDEX RANGE
SCAN y la conversión bitmap seguida del acceso a tabla por ROWID, por lo que se
recomienda comprobar y analizar el plan de ejecución siempre que sea posible.

E. Otras recomendaciones para índices

A continuación se dan una serie de pautas y consejos a tener en cuenta a la hora de trabajar
con índices. También se hace una breve referencia a otros tipos de índices existentes en
Oracle.
• Creación de índices tras inserción de datos: Si la carga inicial de datos en una tabla se va a
realizar con SQL*Loader, es recomendable no crear el índice hasta que el proceso de carga
finalice, pues a cada fila que se va insertando, se debe actualizar el índice. Si la aplicación o
las normas lo permiten, se puede usar la carga por el método directo (direct path) de forma
que el índice puede ser creado mientras los datos son cargados.
• Monitorizar los índices: Oracle proporciona un mecanismo bastante sencillo para
comprobar si los índices son utilizados o no a través de una simple consulta al diccionario de
datos. Esto se debe gracias a la implementación de la característica MONITORING USAGE.
• Se debe buscar un equilibrio entre la mejora en los accesos y el empeoramiento en las
acciones de alteración de datos a la hora de definir el número de índices que debe soportar
cada tabla, en general, mas de 5 índice por tabla en Aplicaciones Transaccionales (OLTP)
puede ser un valor máximo.

F. Índices basados en funciones

Los índices basados en funciones se emplean para simplificar el uso de consultas que deben
evaluar valores devueltos por una función o una expresión, dado que el valor ya está
almacenado en el índice.

Para poder crear índices basados en funciones, se deben cumplir los siguientes requisitos:

• Se debe poseer el privilegio de sistema QUERY REWRITE para crear índices en el propio
esquema.

• Si se quieren crear índices de este tipo en cualquier esquema, se debe poseer el privilegio
GLOBAL QUERY REWRITE y CREATE ANY INDEX

• Los siguientes parámetros de inicialización deben incluirse en fichero de

parámetros:

o QUERY_REWRITE_INTEGRITY=TRUSTED
o QUERY_REWRITE_ENABLED=TRUE
o COMPATIBLE=8.1.0.0.0 (o superior)

• Las tablas deben ser analizadas tras la creación de los índices

• La consulta no debe necesitar ningún valor NULL de la expresión indexada pues estos no se
almacenan en el índice.

A continuación, se muestran algunos ejemplos de índices basados en funciones y su utilidad:

Ejemplo1: Índice basado en función para ejecución de búsquedas “case-sensitive”. La

siguiente sentencia crea un índice sobre una tabla basado en una evaluación “uppercase”
sobre una columna:

CREATE INDEX idx ON emp (UPPER(ename));

SELECT * FROM emp WHERE UPPER(ename) LIKE 'JOH%';

Ejemplo 2: Índice basado en una expresión que pre calcula el valor:

CREATE INDEX idx ON t (a + b * (c - 1), a, b);

La SELECT puede usar tanto una index range scan (en la siguiente consulta la expresión de
la sentencia es un prefijo del índice) o un index full scan (preferible cuando el índice
especifica un alto grado de paralelismo)

SELECT a FROM t WHERE a + b * (c - 1) < 100;

G. Índices de clave inversa

Un índice de clave inversa, invierte los bytes de cada columna indexada, excepto para el
ROWID, pero guarda el orden de la columna. Se utiliza para:
• Entorno de Real Application Clusters donde las modificaciones en el árbol de índices se
producen en un conjunto concentrado de entradas de tipo hoja.

• Situaciones en las que el usuario inserta valores ascendentes y borra los valores inferiores
de una tabla.

5. ¿Qué mecanismos o herramientas propone un SMBD para apoyar el proceso de

afinamiento de una base de datos? Describa su funcionamiento y utilícelo para mostrar el
efecto que tiene una decisión de afinamiento

Creación, seguridad y monitoreo

inserción, modificado, borrado y seleccionado.
métodos
usar el optimizer
usando hints
usando histograms
driving tables
partitions
parallel query
además de comandos como analize
estas son algunas de las más usadas pero oracle suministra muchisimas mas herramientas

6. ¿Qué es un hint y cómo puede beneficiar el desempeño de una consulta?

Los hints son parámetros que pasamos a las sentencias SQL para influir en el optimizador de
oracle.
Copiar

SELECT /*+ HINT */ . . .

Toda consulta SELECT se ejecuta dentro del servidor en varios pasos. Para la misma
consulta, pueden existir distintos caminos para conseguir el mismo resultados, por lo que el
servidor es el responsable de decidir qué camino seguir para conseguir el mejor tiempo de
respuesta.
La parte de la base de datos que se encarga de estas decisiones se llama Optimizador. El
camino seguido por el servidor para la ejecución de una consulta se denomina "Plan de
ejecución" (ver EXPLAIN PLAN).
Hay que tener en cuenta que:

1. si no es posible efectuar lo que se indica con el hint, Oracle lo ignorará,

2. los Hints fuerzan el uso del Optimizador por costes (a excepción de rule)
3. no afectan a subconsultas en la misma sentencia SQL.

Optimizador por reglas (RULE)

se basa en ciertas reglas para realizar las consultas. Por ejemplo, si se filtra por un campo
indexado, se utilizará el índice. Si la consulta contiene un ORDER BY, se utilizará un
algoritmo Quick Sort, etc. No tiene en cuenta el estado actual de la base de datos, ni el
número de usuarios conectados, ni la carga de datos de los objetos, etc. Es un sistema de
optimización estático, no varía de un momento a otro.

Optimizador por costes (CHOOSE)

se basa en las reglas básicas, pero teniendo en cuenta el estado actual de la base de
datos. Es decir, tiene en cuenta el número de registros de las tablas, el número de usuarios
accediendo a ellas, etc. Por ejemplo, si se hace una consulta utilizando un campo indexado,
mirará primero el número de registros y si es suficientemente grande entonces merecerá la
pena acceder por el índice, si no, accede directamente a la tabla.

Para averiguar el estado actual de la base de datos se basa en los datos del catálogo público,
por lo que es recomendable que esté lo más actualizado posible (a través de la sentencia
ANALYZE), ya que de no ser así, se pueden tomar decisiones a partir de datos desfasados (la
tabla tenía 10 registros hace un mes pero ahora tiene 10.000).

7. Describa escenarios de la rotonda (proyecto) en donde aplicaría la fragmentación de datos

Considere la posibilidad de fragmentar sus tablas si tiene como objetivo mejorar al menos
uno de los aspectos siguientes:

● Tiempo de respuesta de un solo usuario

● Concurrencia
● Disponibilidad
● Características de copia de seguridad y restauración
● Carga de datos

la fragmentación de datos permite recuperar información que se encuentra en la base de

datos.
en el caso de la rotonda esto se puede implementar con la tabla de los clientes
cada que se ejecute un pedido es importante guardar la información de los clientes para
cuando se requiera nuevamente y más aún si es un cliente frecuente y en general con la
mayoría de las tablas por ejemplo con los restaurantes, si en algún momento dado un
restaurante se retira de la rotonda, es importante tener almacenado dicho registro por si el
restaurante vuelve a ingresar en la rotonda, lo mismo pasaría con los menús y los productos,
un producto puede ser eliminado de un menú, pero este puede existir en otro menú de tal
manera que su registro no tiene porque eliminarse.

REFERENCIAS

Unknows.(2013).Estructura lógica y física de una base de datos en oracle. Recuperado de:

http://infoinges.blogspot.com/2013/05/estructura-logica-y-fisica-de-una-base.html
Oppel, Andrew J. (2009). Databases: a beginner's guide
(http://books.google.com/books?id=GfRMor1kRCoC). McGraw Hill Professional. p. 44.
Recuperado de: Oracle Docs.
https://docs.oracle.com/cd/B19306_01/server.102/b14220/physical.htm
Oracle.(2019)Construyendo con Bloques en PL/SQL. Recuperado de:
https://www.oracle.com/technetwork/es/articles/sql/construyendo-con-bloques-parte-1-15491
35-esa.html
oracle(2019)create index. Recuperado de: http://ora.u440.com/ddl/create%20index.html
IBM(2018)Que es fragmentación. Recuperado de:
https://www.ibm.com/support/knowledgecenter/es/SSGU8G_11.50.0/com.ibm.ddi.doc/ids_d
di_084.htm