jueves, 1 de noviembre de 2012

EXPLICACION INDICES


Resumen índices

Un índice es una estructura opcional, asociado con una mesa o tabla de clúster, que a veces puede acelerar el acceso de datos. Mediante la creación de un índice en una o varias columnas de una tabla, se obtiene la capacidad en algunos casos, para recuperar un pequeño conjunto de filas distribuidas al azar de la tabla. Los índices son una de las muchas formas de reducir el disco I / O.

Si una tabla de montón organizado no tiene índices, entonces la base de datos debe realizar un escaneo completo de tabla para encontrar un valor. Por ejemplo, sin un índice, una consulta de ubicación 2700 en la tabla hr.departments requiere la base de datos para buscar todas las filas de cada bloque de la tabla para este valor. Este enfoque no escala bien como datos de aumento de volúmenes.

Por analogía, supongamos que un gerente de Recursos Humanos tiene un estante de cajas de cartón. Las carpetas que contienen información de los empleados se insertan aleatoriamente en las cajas. La carpeta de empleado Whalen (ID 200) es de 10 carpetas desde el fondo de la caja 1, mientras que la carpeta para el rey (ID 100) se encuentra en la parte inferior del cuadro 3. Para localizar una carpeta, el gestor busca en cada carpeta en la casilla 1 de abajo hacia arriba, y luego se mueve de una casilla a otra hasta que se encuentra la carpeta. Para acelerar el acceso, el administrador puede crear un índice que enumera de forma secuencial todos los ID de empleado con su ubicación de la carpeta:


 
ID 100: Box 3, position 1 (bottom)

ID 101: Box 7, position 8

ID 200: Box 1, position 10

.

.

.

Del mismo modo, el administrador podría crear índices separados para los últimos nombres de los empleados, los ID de departamento, y así sucesivamente.
En general, considerar la creación de un índice en una columna en cualquiera de las siguientes situaciones:

• Las columnas indizadas se consultan con frecuencia y devuelven un pequeño porcentaje del número total de filas en la tabla.

• Existe una restricción de integridad referencial en la columna o columnas indexadas. El índice es un medio para evitar un bloqueo de tabla completa que de otro modo se requeriría si se actualiza la clave principal de la tabla principal, se funden en la tabla principal, o eliminar de la tabla primaria.

• Una restricción de clave única se coloca sobre la mesa y desea especificar manualmente el índice de todas las opciones sobre índices y.


Características de indexación


Los índices son objetos de esquema que son lógica y físicamente independiente de los datos de los objetos con los que están asociados. Por lo tanto, un índice se puede quitar o creado sin afectar físicamente a la tabla para el índice.

Nota:
Si se le cae un índice, las aplicaciones siguen funcionando. Sin embargo, el acceso de los datos previamente indexado puede ser más lento.

La ausencia o presencia de un índice no requiere un cambio en el texto de cualquier sentencia SQL. Un índice es una ruta de acceso rápido a una sola fila de datos. Sólo afecta a la velocidad de ejecución. Dado un valor de datos que se ha indexado, el índice apunta directamente a la ubicación de las filas que contienen ese valor.
La base de datos mantiene automáticamente y utiliza los índices después de su creación. La base de datos también refleja automáticamente los cambios en los datos, como agregar, actualizar y eliminar filas, en todos los índices pertinentes sin acciones adicionales requeridas por los usuarios. Rendimiento de recuperación de datos indexados permanece casi constante, incluso cuando se insertan filas. Sin embargo, la presencia de muchos índices en una tabla degrada el rendimiento DML porque la base de datos también debe actualizar los índices.

Índices tienen las siguientes propiedades:

• Facilidad de uso

Los índices son utilizables (por defecto) o inutilizable. Un índice inutilizables no se mantiene por las operaciones DML y es ignorado por el optimizador. Un índice inutilizable puede mejorar el rendimiento de las cargas a granel. En lugar de dejar un índice y luego volverlo a crear, puede hacer que el índice inservible y luego reconstruirlo. Índices inutilizables y las particiones de índice no consumen espacio. Cuando usted hace un índice utilizable no utilizable, la base de datos cae su segmento de índice.

• Visibilidad

Los índices son visibles (por defecto) o invisible. Un índice invisible se mantiene por las operaciones DML y no se utiliza de forma predeterminada por el optimizador. Cómo hacer una invisible índice es una alternativa a lo que es inutilizable o se caiga. Índices invisibles son especialmente útiles para probar la eliminación de un índice antes de dejarlo caer o mediante índices temporalmente sin afectar a la aplicación general.


Guía del administrador de aprender a manejar los índices

• Base de datos Oracle Performance Tuning Guide para aprender cómo ajustar los índices

Teclas y Columnas


Una clave es un conjunto de columnas o expresiones en las que se puede construir un índice. Aunque los términos se usan indistintamente, los índices y las claves son diferentes. Los índices son estructuras almacenados en la base de datos que los usuarios a administrar el uso de sentencias de SQL. Las claves son estrictamente un concepto lógico.
La siguiente sentencia crea un índice en la columna customer_id de la muestra oe.orders tabla:

 
CREATE INDEX ord_customer_ix ON orders (customer_id);

 

En la declaración anterior, la columna customer_id es la clave de índice. El índice en sí se llama ord_customer_ix.

Índices Compuestos

Un índice compuesto, también llamado índice concatenado, es un índice de varias columnas de una tabla. Las columnas de un índice compuesto que deben aparecer en el orden que tenga más sentido para las consultas que recuperar datos y no necesita ser adyacente en la tabla.
Los índices compuestos pueden acelerar la recuperación de datos para las instrucciones SELECT en la que el DONDE referencias cláusula totalidad o la parte principal de las columnas en el índice compuesto. Por lo tanto, el orden de las columnas utilizadas en la definición es importante. En general, las columnas de acceso más común van primero.

Por ejemplo, supongamos que una aplicación realiza consultas frecuentes al apellidos, job_id, y columnas de salario en la tabla empleados. También asumir que last_name tiene alta cardinalidad, lo que significa que el número de valores distintos que es grande en comparación con el número de filas de la tabla. Se crea un índice con el siguiente orden de las columnas:

CREATE INDEX employees_ix

   ON employees (last_name, job_id, salary);

Las consultas que acceden a las tres columnas, sólo la columna last_name, o sólo el last_name y columnas job_id utilizan este índice. En este ejemplo, las consultas que no tienen acceso a la columna last_name no utilizan el índice.

Nota:

En algunos casos, tales como cuando la columna principal tiene muy baja cardinalidad, la base de datos puede utilizar una búsqueda selectiva de este índice

Múltiples índices pueden existir para la misma mesa, siempre y cuando la permutación de columnas difiere para cada índice. Puede crear varios índices que utilizan las mismas columnas si se especifica claramente diferentes permutaciones de las columnas. Por ejemplo, las siguientes sentencias SQL especifican permutaciones válidas:

 
CREATE INDEX employee_idx1 ON employees (last_name, job_id);

CREATE INDEX employee_idx2 ON employees (job_id, last_name);

Índices únicos y no único

Los índices pueden ser único o no único. Índices únicos garantizar que no hay dos filas de una tabla tienen valores duplicados en la columna de clave o columna. Por ejemplo, dos empleados no pueden tener el mismo ID de empleado. Por lo tanto, en un índice único, existe una ROWID para cada valor de datos. Los datos de los bloques de hojas se ordenan sólo por clave.

Índices no únicas permiten valores duplicados en la columna o columnas indexadas. Por ejemplo, la columna 'nombre de la tabla de empleados puede contener varios valores Mike. Para un índice no único, el ROWID se incluye en la clave de forma ordenada, por lo que los índices no únicos se ordenan por la clave de índice y ROWID (ascendente).

Oracle Database no filas de la tabla de índice en el que todas las columnas clave son nulas, a excepción de los índices de mapa de bits o cuando el valor de la columna clave de clúster es nulo.

Tipos de índices

Base de Datos Oracle ofrece varias combinaciones de indexación, que proporcionan una funcionalidad complementaria sobre el rendimiento. Los índices se pueden clasificar de la siguiente manera:

• Los índices de árbol B

Estos índices son el tipo de índice estándar. Son excelentes para la clave principal y los índices altamente selectivos. Utilizado como índices concatenados, B-tree índices pueden recuperar los datos ordenados por las columnas de índice. Índices B-tree tienen los siguientes subtipos:

Índice de tablas organizadas o


Una tabla de índice-organizada difiere de un montón-organizado porque los datos es en sí mismo el índice.

En este tipo de índice, los bytes de la clave de índice se invierten, por ejemplo, 103 se almacena como 301. La inversión de bytes extiende inserta en el índice durante muchos bloques. Consulte "Indicadores clave inversa".

Ö Descendente índices

Este tipo de índice almacena los datos en una columna o columnas de concreto en orden descendente. Consulte "Ascendiendo y descendiendo los índices".

o índices B-tree de racimo


Este tipo de índice se utiliza para indexar una clave de clúster tabla. En lugar de apuntar a una fila, los puntos clave para el bloque que contiene filas relacionadas con la clave de clúster. Consulte "Descripción general de Clusters indexadas".

• Mapa de bits y los índices bitmap join

En un índice de mapa de bits, una entrada de índice utiliza un mapa de bits para que apunte a varias filas. En cambio, los puntos de entrada de un índice B-tree en una sola fila. Un índice de combinación de mapa de bits es un índice de mapa de bits para la unión de dos o más tablas. Consulte "Indicadores de mapa de bits".

• Los índices basados ​​en funciones

Este tipo de índice incluye columnas que, o bien se transforman por una función, tales como la función UPPER, o incluidos en una expresión. Índices B-tree o mapa de bits puede ser basado en las funciones.

Consulte "Indicadores basados ​​en funciones".

• Índices de dominio de aplicación

Este tipo de índice se crea por un usuario para los datos en un dominio específico de la aplicación. El índice física no tiene que utilizar una estructura de índice tradicional y se puede almacenar ya sea en la base de datos Oracle como tablas o externamente como un archivo. Consulte "Indicadores de dominio de aplicación".
Vea también:

Oracle Database Performance Tuning Guide para aprender sobre los diferentes tipos de índices

Índices B-Tree

Árboles B, abreviatura de árboles balanceados, son el tipo más común de índice de base de datos. Un índice B-tree es una lista ordenada de valores dividida en rangos. Mediante la asociación de una tecla con una fila o rango de filas, los árboles B proporcionan un excelente rendimiento de la recuperación para una amplia gama de consultas, incluyendo coincidencia exacta y búsquedas por rango.
La figura 3-1 ilustra la estructura de un índice B-tree. El ejemplo muestra un índice en la columna department_id, que es una columna de clave externa en la tabla empleados.

 Figure 3-1 Internal Structure of a B-tree Index

Bloqueos de rama y Bloques Leaf

Un índice B-tree tiene dos tipos de bloques: bloques de sucursales para la búsqueda y la hoja de bloques que almacenan valores. Los bloqueos de rama de nivel superior de un índice B-tree contienen datos de índice que apunta a bloques de índices de nivel inferior. En la Figura 3-1, el bloqueo de la rama raíz tiene una entrada de 0-40, lo que apunta al bloque de izquierda en el siguiente nivel de sucursales. Este bloqueo de la rama contiene entradas como 0-10 y 11-19. Cada uno de estos puntos de entradas a un bloque de la hoja que contiene los valores de clave que caen en la gama.

Un índice de árbol B está equilibrado porque todos los bloques hoja mantenerse de forma automática a la misma profundidad. Por lo tanto, la recuperación de cualquier documento desde cualquier lugar del índice toma aproximadamente la misma cantidad de tiempo. La altura del índice es el número de bloque requerido para pasar de el bloque de raíz a un bloque de la hoja. El nivel de las sucursales es la altura menos 1. En la Figura 3-1, el índice tiene una altura de 3 y un nivel de rama de la 2.
Bloqueos de rama almacenar el prefijo de clave mínimo necesario para tomar una decisión de ramificación entre dos teclas. Esta técnica permite que la base de datos para adaptarse a la mayor cantidad de información posible sobre cada bloque de rama. Los bloqueos de rama contienen un puntero al bloque de niño que contiene la clave. El número de teclas y punteros está limitado por el tamaño del bloque.

Los bloques de hojas contienen todos los valores de datos indexada y un ROWID correspondiente se utiliza para localizar la fila actual. Cada entrada está ordenada por (clave, ROWID). Dentro de un bloque de la hoja, una llave y ROWID está vinculada a sus hermanos entradas izquierda y derecha. Los propios bloques hoja también están doblemente enlazadas. En la Figura 3-1 el bloque de hoja más a la izquierda (0-10) está ligada a la segunda hoja bloque (11-19).

Nota:
Los índices en columnas con datos de tipo carácter se basan en los valores binarios de los personajes en el juego de caracteres de base de datos.

Scans Índice

En un recorrido de índice, la base de datos recupera una fila al recorrer el índice, utilizando los valores de columna indexados especificados por la norma. Si la base de datos analiza el índice de un valor, entonces se encontrará este valor en n E / S donde n es la altura del índice B-tree. Este es el principio básico detrás de los índices de base de datos Oracle.

Si una instrucción SQL sólo tiene acceso a columnas indexadas, a continuación, lee los valores de la base de datos directamente desde el índice en lugar de a partir de la tabla. Si la declaración accede columnas, además de las columnas indizadas, a continuación, la base de datos utiliza ROWIDs para encontrar las filas de la tabla. Típicamente, la base de datos recupera los datos de la tabla por alternativamente la lectura de un bloque de índice y luego un bloque de tabla.

Vea también:

Oracle Database Performance Tuning Guide para obtener información detallada sobre las exploraciones de índices

Índice Análisis Completo

En un recorrido de índice completo, la base de datos lee el índice completo en orden. Una exploración de índice completo está disponible si una columna en el índice, y en algunas circunstancias, cuando no se especifica un predicado de un predicado (cláusula WHERE) en las referencias de sentencia de SQL. Un análisis completo puede eliminar la clasificación ya que los datos aparecen ordenados por clave de índice.

Supongamos que una aplicación se ejecuta la siguiente consulta:

 

SELECT department_id, last_name, salary

FROM   employees

WHERE  salary > 5000

ORDER BY department_id, last_name;

 

También asumen que department_id, apellidos y salario son una clave compuesta en un índice. Oracle Database realiza un escaneo completo del índice, la lectura de forma ordenada (ordenado por ID de departamento y apellido) y filtrado en el atributo salario. De esta manera, la base de datos escanea un conjunto de datos más pequeñas que la tabla empleados, que contiene más columnas que las que se incluyen en la consulta, y evita la clasificación de los datos.


Por ejemplo, el análisis completo puede leer las entradas de índice de la siguiente manera:

 

50,Atkinson,2800,rowid

60,Austin,4800,rowid

70,Baer,10000,rowid

80,Abel,11000,rowid

80,Ande,6400,rowid

110,Austin,7200,rowid

.

.

.

Español

Inglés

Portugués



Fast Índice Análisis Completo

Un análisis rápido índice completo es un análisis completo índice en el que la base de datos lee los bloques de índice en ningún orden en particular. La base de datos accede a los datos en el índice de sí mismo, sin acceso a la tabla.

Exploraciones de índices completos rápidos son una alternativa a un escaneo completo de tabla cuando el índice contiene todas las columnas que son necesarios para la consulta, y al menos una columna en la clave de índice tiene la restricción NOT NULL.

Por ejemplo, una aplicación emite la siguiente consulta, que no incluye una cláusula ORDER BY:

 

SELECT last_name, salary

FROM   employees;

 

Si el apellido y el salario son una clave compuesta en un índice, a continuación, un análisis rápido índice completo puede leer las entradas de índice para obtener la información solicitada ::

 

Baida,2900,rowid

Zlotkey,10500,rowid

Austin,7200,rowid

Baer,10000,rowid

Atkinson,2800,rowid

Austin,4800,rowid

.

.

.

Índice de escaneado

Una exploración rango de índices es una exploración ordenada de un índice que tiene las siguientes características:

• Una o más columnas principales de un índice que se especifican en las condiciones. Una condición especifica una combinación de una o más expresiones y operadores lógicos (Boolean) y devuelve un valor de TRUE, FALSE o UNKNOWN.

0, 1, o más valores son posibles para una clave de índice.
La base de datos utiliza habitualmente un análisis rango de índices para acceder a datos selectivos. La selectividad es el porcentaje de filas en la tabla que la consulta selecciona. Una consulta que selecciona un pequeño porcentaje de filas tiene una buena selectividad, mientras que una consulta que selecciona un gran porcentaje de filas tiene pobre selectividad. La selectividad se ató a un predicado de consulta, por ejemplo, cuando apellidos LIKE 'A%', o una combinación de predicados.

Por ejemplo, un usuario consulta los empleados cuyos apellidos comienzan con A. Supongamos que la columna last_name está indexado, con las entradas de la siguiente manera:

Abel,rowid

Ande,rowid

Atkinson,rowid

Austin,rowid

Austin,rowid

Baer,rowid

.

.

.

La base de datos podría usar una exploración de distancia debido a la columna de la apellidos se especifica en el predicado y múltiplos ROWIDs son posibles para cada clave de índice. Por ejemplo, dos empleados son nombrados Austin, por lo que dos ROWIDs se asocian con la tecla Austin.

Una exploración intervalo de índice puede estar delimitado en ambos lados, como en una consulta para los departamentos con los ID de entre 10 y 40, o limitada en un solo lado, como en una consulta de los ID de más de 40. Para analizar el índice, la base de datos se mueve hacia atrás o hacia adelante a través de los bloques de la hoja. Por ejemplo, una exploración para los ID de entre 10 y 40 localiza el primer bloque de hoja de índice que contiene el valor de clave más bajo que es de 10 o mayor. La exploración continúa entonces horizontalmente a través de la lista enlazada de nodos de hoja hasta que se localiza un valor mayor que 40.

Index Scan Unique

En contraste con un índice de exploración de distancia, un único índice de exploración debe tener ya sea 0 o 1 rowID asociado con una clave de índice. La base de datos realiza una exploración única cuando un predicado todas las referencias de las columnas de una clave de índice UNIQUE usar un operador de igualdad. Una exploración único índice deja de procesar tan pronto como se encuentra el primer registro, ya que hay un segundo disco es posible.
A modo de ejemplo, supongamos que un usuario ejecute la consulta siguiente:

 

SELECT *

FROM   employees

WHERE  employee_id = 5;

 

Suponga que la columna employee_id es la clave principal y está indexado con las entradas de la siguiente manera:

 

1,rowid

2,rowid

4,rowid

5,rowid

6,rowid

.

.

.

En este caso, la base de datos puede utilizar un único índice de exploración para localizar el ROWID para el empleado cuyo identificador es 5.

 

Índice Skip Scan

Un índice skip análisis utiliza subíndices lógicas de un índice compuesto. La base de datos "salta" a través de un único índice como si se estuviera buscando índices separados. Escaneo Omitir es beneficioso si hay pocos valores distintos de la columna principal de un índice compuesto y muchos valores distintos en la clave nonleading del índice.

La base de datos puede elegir un índice Exploración con salto cuando la columna de dirección del índice compuesto no se ha especificado en un predicado de la consulta. Por ejemplo, suponga que ejecuta la consulta siguiente para un cliente en la tabla sh.customers:
:

 

SELECT * FROM sh.customers WHERE cust_email = 'Abbey@company.com';

 

La tabla clientes tiene un cust_gender columna cuyos valores son M o F. Supongamos que existe un índice compuesto en las columnas (cust_gender, cust_email). Ejemplo 3-1 se muestra una parte de las entradas de índice.

Ejemplo 3-1 Entradas de Índice Compuesto

F,Wolf@company.com,rowid

F,Wolsey@company.com,rowid

F,Wood@company.com,rowid

F,Woodman@company.com,rowid

F,Yang@company.com,rowid

F,Zimmerman@company.com,rowid

M,Abbassi@company.com,rowid

M,Abbey@company.com,rowid

 

La base de datos puede utilizar una búsqueda selectiva de este índice cust_gender a pesar de que no se especifica en la cláusula WHERE.

En una exploración de salto, el número de subíndices lógicas se determina por el número de valores distintos en la columna principal. En el Ejemplo 3-1, la columna principal tiene dos valores posibles. La base de datos se divide lógicamente el índice en un subíndice con la tecla F y un segundo subíndice con la tecla M.

Cuando se busca el registro para el cliente cuyo correo electrónico es Abbey@company.com, la base de datos busca en el subíndice con el valor F y luego busca en el subíndice con el valor M. Conceptualmente, la base de datos procesa la consulta de la siguiente manera:

 

SELECT * FROM sh.customers WHERE cust_gender = 'F'

  AND cust_email = 'Abbey@company.com'

UNION ALL

SELECT * FROM sh.customers WHERE cust_gender = 'M'

  AND cust_email = 'Abbey@company.com';
 

Invierta índices de clave

Un índice de clave inversa es un tipo de índice B-tree que invierte físicamente los bytes de cada clave de índice, manteniendo el orden de las columnas. Por ejemplo, si la clave de índice es 20, y si los dos bytes almacenados para esta clave en hexadecimal son C1, 15 en un índice de árbol B estándar, a continuación, un índice de clave inversa almacena los bytes como 15, C1.

La inversión de la llave soluciona el problema de la contención de los bloques de la hoja en el lado derecho de un índice B-tree. Este problema puede ser especialmente grave en un Oracle Real Application Clusters (Oracle RAC) de base de datos en la que varias instancias modificar varias veces el mismo bloque. Por ejemplo, en un ordena tablas las claves principales para las órdenes son secuenciales. Una instancia del clúster agrega fin 20, mientras que otro 21 añade, con cada instancia de escribir su clave para el mismo bloque de la hoja en el lado derecho del índice.
En un índice de clave inversa, la revocación de la orden de bytes distribuye inserta a través de todas las claves de la hoja en el índice.

Por ejemplo, las llaves, como 20 y 21, que habría sido enunciada en un índice de clave estándar están almacenados lejos en bloques separados. Por lo tanto, E / S para las inserciones de claves secuenciales se distribuye más uniformemente.

Debido a que los datos en el índice no está ordenado por clave columna cuando se almacena, la disposición de las teclas inversa elimina la capacidad de ejecutar una serie de consulta de exploración de índice en algunos casos. Por ejemplo, si un usuario emite una consulta para los ID de orden superior a 20, a continuación, la base de datos no puede comenzar con el bloque que contiene este ID y proceder horizontalmente a través de los bloques hoja.

Ascendiendo y descendiendo índices

En un índice ascendente, Oracle Database almacena los datos en orden ascendente. De forma predeterminada, los datos de caracteres se ordenan por los valores binarios contenidos en cada byte del valor, los datos numéricos de menor a mayor número, y fecha de la primera a la última de valor.

Para un ejemplo de un índice ascendente, considere la siguiente sentencia SQL:

 

CREATE INDEX emp_deptid_ix ON hr.employees(department_id);

 
Oracle tipo de base de datos de la tabla hr.employees en la columna department_id. Se carga el índice ascendente de los valores ROWID department_id y correspondientes en orden ascendente, empezando por 0. Cuando se utiliza el índice, base de datos Oracle busca en los valores department_id ordenados y utiliza los ROWIDs asociadas para localizar filas que tienen el valor department_id solicitada.

Al especificar la palabra clave DESC en la sentencia CREATE INDEX, puede crear un índice descendente. En este caso, el índice almacena los datos en una columna o columnas especificado en orden descendente. Si el índice en la figura 3-1 en la columna employees.department_id se desciende, a continuación, la hoja de bloqueo que contenía 250 sería en el lado izquierdo del árbol y el bloque con 0 a la derecha. La búsqueda por defecto a través de un índice descendente es de mayor a menor valor.

Descendente índices son útiles cuando una consulta de tipo algunas columnas que suben y otros descendente. Por ejemplo, supongamos que se crea un índice compuesto sobre el last_name y columnas department_id de la siguiente manera:

CREATE INDEX emp_name_dpt_ix ON hr.employees(last_name ASC, department_id DESC);

 

Si consultas un usuario hr.employees de apellidos en orden ascendente (A a Z) y los identificadores de departamento en orden (de mayor a menor) descendente, entonces la base de datos pueden utilizar este índice para recuperar los datos y evitar el paso adicional de clasificarlos.


compresión clave

Oracle Database puede utilizar la compresión llave para comprimir partes de los principales valores de columna de clave en un índice B-tree o una tabla organizada por índices. Clave de compresión puede reducir en gran medida el espacio consumido por el índice.
En general, las claves de índice tienen dos piezas, una pieza agrupación y una pieza única. Clave de compresión rompe la clave de índice en una entrada de prefijo, que es la pieza agrupación, y una entrada de sufijo, que es la pieza única o casi única. La base de datos alcanza la compresión mediante el intercambio de las entradas de prefijo entre las entradas de sufijos en un bloque de índice.

Nota:
Si no se define una clave para tener una pieza única, entonces la base de datos proporciona una añadiendo un ROWID a la pieza de agrupación.
De forma predeterminada, el prefijo de un índice único se compone de todas las columnas de clave excluyendo el último, mientras que el prefijo de un índice no único se compone de todas las columnas de clave. Por ejemplo, supongamos que crea un índice compuesto sobre la mesa oe.orders la siguiente manera:

CREATE INDEX orders_mod_stat_ix ON orders ( order_mode, order_status );

 

Muchos valores repetidos se producen en las columnas order_mode y ORDER_STATUS. Un bloque de índice puede tener entradas como se muestra en el Ejemplo 3-2.

Example 3-2 Index Entries in Orders Table

online,0,AAAPvCAAFAAAAFaAAa

online,0,AAAPvCAAFAAAAFaAAg

online,0,AAAPvCAAFAAAAFaAAl

online,2,AAAPvCAAFAAAAFaAAm

online,3,AAAPvCAAFAAAAFaAAq

online,3,AAAPvCAAFAAAAFaAAt

 

En el Ejemplo 3-2, el prefijo clave consistiría en una concatenación de los valores order_mode y ORDER_STATUS. Si este índice se creó con la compresión de claves predeterminado y luego duplicar prefijos clave como la línea, 0 y en línea, 2 podría ser comprimido. Conceptualmente, la base de datos alcanza la compresión como se muestra en el ejemplo siguiente:online,0

 

AAAPvCAAFAAAAFaAAa

AAAPvCAAFAAAAFaAAg

AAAPvCAAFAAAAFaAAl

online,2

AAAPvCAAFAAAAFaAAm

online,3

AAAPvCAAFAAAAFaAAq

AAAPvCAAFAAAAFaAAt

Entradas de sufijos forman la versión comprimida de filas de índice. Cada asiento se refiere a un sufijo entrada de prefijo, que se almacena en el mismo bloque de índice como la entrada sufijo.

Como alternativa, puede especificar una longitud de prefijo al crear un índice comprimido. Por ejemplo, si se especifica la longitud de prefijo 1, el prefijo sería order_mode y el sufijo sería ORDER_STATUS, ROWID. Para los valores del Ejemplo 3-2, el índice podría factorizar apariciones duplicadas de línea de la siguiente manera:

 

online

0,AAAPvCAAFAAAAFaAAa

0,AAAPvCAAFAAAAFaAAg

0,AAAPvCAAFAAAAFaAAl

2,AAAPvCAAFAAAAFaAAm

3,AAAPvCAAFAAAAFaAAq

3,AAAPvCAAFAAAAFaAAt

 

Índices de mapa de bits

En un índice de mapa de bits, la base de datos almacena un mapa de bits para cada clave de índice. En un índice B-tree convencional, una entrada de índice apunta a una sola fila. En un índice de mapa de bits, cada clave de índice almacena punteros a varias filas.

Índices de mapa de bits están diseñados principalmente para el almacenamiento de datos o entornos en los que las consultas de referencia muchas columnas en una manera ad hoc. Las situaciones que pueden requerir un índice de mapa de bits son:

Las columnas indexadas tienen baja cardinalidad, es decir, el número de valores distintos que es pequeño en comparación con el número de filas de la tabla.

• La tabla de indexado es ya sea de sólo lectura o no sujetos a modificación significativa de las sentencias DML.

Para ver un ejemplo de almacenamiento de datos, la tabla tiene una columna sh.customer cust_gender con sólo dos valores posibles: M y F. Supongamos que las consultas para el número de clientes de un género en particular, son comunes. En este caso, la columna de la customer.cust_gender sería un candidato para un índice de mapa de bits.

Cada bit del mapa de bits corresponde a una posible ROWID. Si el bit está activado, entonces la fila con el ROWID correspondiente contiene el valor clave. Una función de mapeo convierte la posición de bit a un ROWID real, por lo que el índice de mapa de bits proporciona la misma funcionalidad que un índice de árbol B pesar de que utiliza una representación interna diferente.

Si la columna indexada en una sola fila se actualiza, a continuación, la base de datos bloquea la entrada de clave de índice (por ejemplo, M o F) y no el bit individual asignada a la fila actualizada. Debido a los puntos clave a muchas filas, DML en los datos indexados normalmente bloquea todas estas filas. Por esta razón, los índices de mapa de bits no son apropiados para muchas aplicaciones OLTP.


Índices de mapa de bits en una sola tabla


Ejemplo 3-3 muestra una consulta de la tabla sh.customers. Algunas columnas de esta tabla son candidatos para un índice de mapa de bits.
Ejemplo 3-3 Consulta de la tabla clients

 

 

SQL> SELECT cust_id, cust_last_name, cust_marital_status, cust_gender

  2  FROM   sh.customers

  3  WHERE  ROWNUM < 8 ORDER BY cust_id;

 

   CUST_ID CUST_LAST_ CUST_MAR C

---------- ---------- -------- -

         1 Kessel              M

         2 Koch                F

         3 Emmerson            M

         4 Hardy               M

         5 Gowen               M

         6 Charles    single   F

         7 Ingram     single   F

 

7 rows selected.

 

El cust_marital_status y columnas cust_gender tienen baja cardinalidad, mientras cust_id y cust_last_name no. Por lo tanto, los índices de mapa de bits pueden ser apropiados en cust_marital_status y cust_gender. Un índice de mapa de bits no es probablemente útil para las otras columnas. En cambio, un índice B-tree único en estas columnas probablemente proporcionar la representación más eficiente y recuperación.

Tabla 3-1 ilustra el índice de mapa de bits de la salida de la columna cust_gender muestra en el Ejemplo 3-3. Se compone de dos mapas de bits separados, uno para cada género.

 

Table 3-1 Ejemplo de Bitmap

Value
Row 1
Row 2
Row 3
Row 4
Row 5
Row 6
Row 7
M
1
0
1
1
1
0
0
F
0
1
0
0
0
1
1

 

Una función de mapeo convierte cada bit del mapa de bits a un identificador de fila de la tabla de clientes. Cada valor de bit depende de los valores de la fila correspondiente en la tabla. Por ejemplo, el mapa de bits para el valor de M contiene un 1 como primer poco porque el sexo es M en la primera fila de la tabla de clientes. El mapa de bits cust_gender = 'M' tiene un 0 para los bits en sus filas 2, 6, y 7 debido a que estas filas no contienen M como su valor.

Nota:
Índices de mapa de bits pueden incluir claves que consisten enteramente en valores nulos, a diferencia de índices B-tree. Nulos de indexación puede ser útil para algunas sentencias SQL, como las consultas con el número de función de agregado.

Un analista de la investigación de las tendencias demográficas de los clientes puede preguntar, "¿Cuántos de nuestros clientes son mujeres solteras o divorciadas?" Esta pregunta se corresponde con la siguiente consulta SQL

 

SELECT COUNT(*)

FROM   customers 

WHERE  cust_gender = 'F'

AND    cust_marital_status IN ('single', 'divorced');

Índices de mapa de bits pueden procesar esta consulta de manera eficiente mediante el recuento del número de valores de 1 en el mapa de bits resultante, como se ilustra en la Tabla 3-2. Para identificar a los clientes que cumplan los criterios, Oracle Database puede utilizar el mapa de bits resultante para acceder a la tabla.

Tabla 3-2 Mapa de bits ejemplo

Value
Row 1
Row 2
Row 3
Row 4
Row 5
Row 6
Row 7
M
1
0
1
1
1
0
0
F
0
1
0
0
0
1
1
single
0
0
0
0
0
1
1
divorced
0
0
0
0
0
0
0
single or divorced, and F
0
0
0
0
0
1
1

 

Indexación Bitmap combina eficientemente los índices que corresponden a una serie de condiciones en una cláusula WHERE. Las filas que satisfacer algunas, pero no todas, las condiciones se filtran antes de la propia tabla se accede. Esta técnica mejora el tiempo de respuesta, a menudo de forma espectacular.

Bitmap Únete índices

Un índice de combinación de mapa de bits es un índice de mapa de bits para la unión de dos o más tablas. Para cada valor de una columna de la tabla, el índice almacena el identificador de fila de la fila correspondiente en la tabla indexada. Por el contrario, se crea un índice de mapa de bits estándar en una sola tabla.
Un índice de unirse a mapa de bits es un medio eficaz de reducir el volumen de datos que se deben unir mediante la realización de las restricciones de antemano. Para un ejemplo de cuando un bitmap unirse índice sería útil, suponen que los usuarios a menudo consultan el número de
empleados con un tipo de trabajo en particular. Una consulta típica podría ser como sigue:

 

 

SELECT COUNT(*)

FROM   employees, jobs

WHERE  employees.job_id = jobs.job_id

AND    jobs.job_title = 'Accountant';

El consulta anterior sería típicamente utilice un índice en jobs.job_title para recuperar las filas para Accountant y entonces el Identificación del Aviso del, y un índice sobre employees.job_id para encontrar los filas que coincidan con. Para recuperar los datos desde el índice en sí en lugar de a partir de una scan de las mesas, usted podría crear un mapa de bits unirse a índice de de la siguiente manera:

 

 

CREATE BITMAP INDEX employees_bm_idx

ON     employees (jobs.job_title)

FROM   employees, jobs

WHERE  employees.job_id = jobs.job_id;

 

Figure 3-2 Bitmap Join Index

Description of Figure 3-2 follows


Conceptualmente, employees_bm_idx es un índice de la columna jobs.title en la consulta SQL se muestra en el Ejemplo 3-4 (salida de muestra incluido). La clave job_title en los puntos de índice de filas en la tabla empleados. Una consulta del número de contadores puede usar el índice para evitar el acceso de los empleados y las tablas de puestos de trabajo debido a que el índice en sí contiene la información solicitada.

Ejemplo 3-4 Ingreso de los asalariados y los empleos Tablas

 

SELECT jobs.job_title AS "jobs.job_title", employees.rowid AS "employees.rowid"

FROM   employees, jobs

WHERE  employees.job_id = jobs.job_id

ORDER BY job_title;

 

jobs.job_title                      employees.rowid

----------------------------------- ------------------

Accountant                          AAAQNKAAFAAAABSAAL

Accountant                          AAAQNKAAFAAAABSAAN

Accountant                          AAAQNKAAFAAAABSAAM

Accountant                          AAAQNKAAFAAAABSAAJ

Accountant                          AAAQNKAAFAAAABSAAK

Accounting Manager                  AAAQNKAAFAAAABTAAH

Administration Assistant            AAAQNKAAFAAAABTAAC

Administration Vice President       AAAQNKAAFAAAABSAAC

Administration Vice President       AAAQNKAAFAAAABSAAB

.

.

.

En un almacén de datos, la condición de unión es una unión igualitaria (que utiliza el operador de igualdad) entre las columnas de clave principal de las tablas de dimensiones y las columnas de clave externa de la tabla de hechos. Unirse a los índices de mapa de bits son a veces mucho más eficiente en el almacenamiento de materializada unen puntos de vista, una alternativa para materializar une con antelación.

Vea también:

Oracle Database Data Warehousing Guide para obtener más información acerca de unirse a los índices de mapa de bits

Estructura de almacenamiento Bitmap

Oracle Database utiliza una estructura de índice B-tree para almacenar mapas de bits para cada clave indexada. Por ejemplo, si jobs.job_title es la columna de clave de un índice de mapa de bits, entonces los datos de índice se almacena en un B-árbol. Los mapas de bits individuales se almacenan en los bloques hoja.
Supongamos que la columna tiene valores jobs.job_title único vendedor de envío, Stock Clerk, y varios otros. Una entrada de índice de mapa de bits para este índice tiene los siguientes componentes:

El título del trabajo como la clave del índice
Un ROWID ROWID bajo y alto para una variedad de ROWIDs
Un mapa de bits para ROWIDs específicos en el rango

Conceptualmente, un bloque de la hoja de índice en este índice podría contener las entradas de la siguiente manera:

 

Shipping Clerk,AAAPzRAAFAAAABSABQ,AAAPzRAAFAAAABSABZ,0010000100

Shipping Clerk,AAAPzRAAFAAAABSABa,AAAPzRAAFAAAABSABh,010010

Stock Clerk,AAAPzRAAFAAAABSAAa,AAAPzRAAFAAAABSAAc,1001001100

Stock Clerk,AAAPzRAAFAAAABSAAd,AAAPzRAAFAAAABSAAt,0101001001

Stock Clerk,AAAPzRAAFAAAABSAAu,AAAPzRAAFAAAABSABz,100001

.

.

.

El mismo título del trabajo aparece en varias entradas debido a la gama ROWID difiere.

Supongamos que actualiza una sesión de trabajo de la identificación de un empleado del vendedor de envío de Stock Clerk. En este caso, la sesión requiere acceso exclusivo a la entrada de clave de índice para el valor antiguo (vendedor de envío) y el nuevo valor (Stock Clerk). Base de datos de Oracle bloquea las filas apuntada por estas dos entradas, pero no las filas apuntado por contador o cualquier otra tecla-hasta que la actualización comete.

Los datos para un índice de mapa de bits se almacenan en un segmento. Base de datos Oracle almacena cada mapa de bits en una o más piezas. Cada pieza ocupa parte de un único bloque de datos.

Índices basados ​​en funciones


Puede crear índices sobre las funciones y las expresiones que implican una o más columnas de la tabla está indexada. Un índice basado en funciones calcula el valor de una función o expresión que implique una o varias columnas y se almacena en el índice. Un índice basado en funciones puede ser un árbol B o un índice de mapa de bits.

La función que se utiliza para construir el índice puede ser una expresión aritmética o una expresión que contiene una función de SQL, la función PL / SQL definida por el usuario, la función del envase o C reclamo. Por ejemplo, una función podría añadir los valores en dos columnas.

Usos de los índices basados ​​en funciones

Los índices basados ​​en funciones son eficientes para evaluar las declaraciones que contienen funciones en sus cláusulas WHERE. La base de datos sólo se utiliza el índice basado en funciones cuando la función está incluida en una consulta. Cuando los procesos de base de datos INSERT y UPDATE, sin embargo, todavía debe evaluar la función de procesar el documento.

Por ejemplo, suponga que crea el siguiente índice basado en funciones:

 

 

CREATE INDEX emp_total_sal_idx

  ON employees (12 * salary * commission_pct, salary, commission_pct);

 

La base de datos se puede utilizar el índice anterior al procesar consultas como Ejemplo 3-5 (ejemplo de salida parcial incluido).

 

Ejemplo 3-5 consulta que contiene una expresión aritmética

 

SELECT   employee_id, last_name, first_name,

         12*salary*commission_pct AS "ANNUAL SAL"

FROM     employees

WHERE    (12 * salary * commission_pct) < 30000

ORDER BY "ANNUAL SAL" DESC;

 

EMPLOYEE_ID LAST_NAME                 FIRST_NAME           ANNUAL SAL

----------- ------------------------- -------------------- ----------

        159 Smith                     Lindsey                   28800

        151 Bernstein                 David                     28500

        152 Hall                      Peter                     27000

        160 Doran                     Louise                    27000

        175 Hutton                    Alyssa                    26400

        149 Zlotkey                   Eleni                     25200

        169 Bloom                     Harrison                  24000

 

Los índices basados ​​en funciones definidas en el SQL funciones UPPER (column_name) o LO WER (column_name) facilitar la búsqueda entre mayúsculas y minúsculas. Por ejemplo, supongamos que la columna 'nombre de empleados contiene caracteres en mayúsculas y minúsculas. Se crea el siguiente índice basado en las funciones de la mesa hr.employees:

CREATE INDEX emp_fname_uppercase_idx

ON employees ( UPPER(first_name) );

 

El índice emp_fname_uppercase_idx puede facilitar consultas como la siguiente ::

SELECT *

FROM   employees

WHERE  UPPER(first_name) = 'AUDREY';

 

Un índice basado en funciones también es útil para indizar sólo las filas específicas de una tabla. Por ejemplo, la columna cust_valid en la tabla sh.customers tiene ya sea I o A como un valor. Para indizar sólo las filas A, podría escribir una función que devuelve un valor nulo para las filas distintas de las filas A. Se puede crear el índice de la siguiente manera:

CREATE INDEX cust_valid_idx

ON customers ( CASE cust_valid WHEN 'A' THEN 'A' END );

 

Optimización con índices basados ​​en funciones

El optimizador puede utilizar un rango de exploración de índice en un índice basado en las funciones para las consultas con expresiones en la cláusula WHERE. La ruta de acceso de exploración de distancia es especialmente beneficioso cuando el predicado (cláusula WHERE) tiene una baja selectividad. En el Ejemplo 3-5 el optimizador puede utilizar un rango de exploración de índice, si el índice se basa en la expresión 12 * Sueldo * COMMISSION_PCT.

Una columna virtual es útil para acelerar el acceso a los datos derivados de las expresiones. Por ejemplo, se podría definir annual_sal columna virtual como 12 * Sueldo * COMMISSION_PCT y crear un índice basado en las funciones de annual_sal.

El optimizador realiza la concordancia de expresión mediante el análisis de la expresión en una sentencia SQL y luego comparar los árboles de expresión de la declaración y el índice basado en funciones. Esta comparación entre mayúsculas y minúsculas e ignora espacios en blanco.

Índices dominio de la aplicación.
Un índice dominio de aplicación es un índice personalizado específico para una aplicación. Oracle Database proporciona indización extensible para hacer lo siguiente:

• Acomodar los índices de medida, los tipos de datos complejos, tales como documentos, datos espaciales, imágenes y clips de vídeo (ver "Datos no estructurados")
• Hacer uso de las técnicas de indexación especializadas

Puede encapsular las rutinas de administración de índices específicos de la aplicación como un objeto de esquema INDEXTYPE y definir un índice de dominio en columnas de tablas o atributos de un tipo de objeto.

Indexación extensible puede procesar de manera eficiente los operadores específicos de la aplicación.

El software de aplicación, llamado el cartucho, controla la estructura y el contenido de un índice de dominio. La base de datos interactúa con la aplicación para construir, mantener y buscar en el índice de dominio. La estructura de índice en sí mismo puede ser almacenado en la base de datos como una tabla de índices-organizada o externamente como un archivo.
Índice de almacenamiento

Oracle Database almacena los datos de índice en un segmento de índice. El espacio disponible para los datos de índice de un bloque de datos es el tamaño de bloque de datos menos los gastos de bloque, sobrecarga de entrada, ROWID, y un byte de longitud para cada valor de índice.

El espacio de tablas de un segmento de índice es el espacio de tabla por omisión del propietario o de un espacio de tablas denominado específicamente en la sentencia CREATE INDEX. Para facilitar la administración puede almacenar un índice en una tabla independiente de su tabla. Por ejemplo, usted puede optar por no copia de seguridad de los espacios de tablas que contienen sólo los índices, que pueden ser reconstruidas, y así reducir el tiempo y el almacenamiento requerido para copias de seguridad.

Visión general de las tablas de índice organizadas

Una tabla de índice-organizada es una tabla almacenada en una variación de un índice de estructura de árbol-B. En una tabla de montón organizada, las filas se insertan en las que entran. En una tabla organizada por índices, las filas se almacenan en un índice definido en la clave principal de la tabla.

Cada entrada de índice en el árbol B también almacena los valores de columna no clave. Por lo tanto, el índice es la de datos, y los datos es el índice. Aplicaciones manipular tablas de índice organizadas como tablas montón organizados, mediante sentencias SQL.

Para una analogía de una tabla organizada por índices, supongamos que un gerente de recursos humanos tiene una estantería con cajas de cartón. Cada cuadro está marcado con un número 1, 2, 3, 4, y así sucesivamente, pero las cajas no se sientan en los estantes en orden secuencial. En su lugar, cada caja contiene un puntero a la ubicación de almacenamiento del siguiente cuadro en la secuencia.
Las carpetas que contienen los registros de empleados se almacenan en cada caja. Las carpetas se ordenan por número de empleado. Empleado Rey tiene ID 100, que es el identificador más bajo, por lo que su carpeta está en la parte inferior de la caja 1. La carpeta de empleado 101 está encima de 100, 102 está en la parte superior de 101, y así sucesivamente hasta que se completa el cuadro 1. La carpeta siguiente en la secuencia es en la parte inferior de la caja 2.

En esta analogía, ordenar las carpetas por ID de empleado permite buscar de manera eficiente para las carpetas sin tener que mantener un índice independiente. Supongamos que un usuario solicita los registros de los empleados 107, 120, y 122. En lugar de buscar un índice en un solo paso y la recuperación de las carpetas en una etapa distinta, el administrador puede buscar las carpetas en orden secuencial y recuperar todas las carpetas que se encuentran.

Índice de tablas organizadas proporcionan un acceso más rápido a filas de la tabla de clave principal o un prefijo válido de la tecla. La presencia de columnas sin clave de una fila en el bloque de la hoja evita un bloque de datos adicional I / O. Por ejemplo, el sueldo del empleado 100 se almacena en la fila de índice en sí. También, porque las filas se almacenan en orden, el acceso principal gama de teclas de la clave principal o prefijo implica bloque mínimo de I / Os. Otro de los beneficios es la evitación de la sobrecarga de espacio de un índice de clave principal separada.

Índice de tablas organizadas son útiles cuando las piezas relacionadas de datos deben ser almacenados juntos o los datos deben ser almacenados físicamente en un orden específico. Este tipo de tabla se utiliza a menudo para la recuperación de información, espacial (consulte el apartado "Visión general de Oracle Spatial"), y las aplicaciones OLAP (véase "OLAP").

Características de las tablas de índice organizadas


El sistema de base de datos realiza todas las operaciones en las tablas de índice organizadas por la manipulación de la estructura del índice B-tree. La Tabla 3-3 resume las diferencias entre las tablas de índice organizadas y mesas montón organizados.

Tabla 3-3 Comparación de las tablas Heap-organizada con cuadros organizada por índices


La figura 3-3 ilustra la estructura de una tabla de índice de departamentos-organizada. Los bloques de hojas contienen las filas de la tabla, ordenados de forma secuencial por clave primaria. Por ejemplo, el primer valor de la primera hoja bloque muestra un ID de departamento de 20, el nombre del departamento de Marketing, ID gerente del 201, y la localización de la identificación de 1800.

Una tabla de índice-organizada almacena todos los datos en la misma estructura y no es necesario para almacenar el ROWID. Como se muestra en la Figura 3-3, el bloque de la hoja 1 en una tabla organizada por índices puede contener, como sigue, ordenados por clave principal:

 

20,Marketing,201,1800

30,Purchasing,114,1700

 

Bloque 2 de la hoja en una tabla organizada por índices puede contener las entradas de la siguiente manera:

 

50,Shipping,121,1500

60,IT,103,1400

 

Una exploración de las filas de la tabla organizada por índices, a fin de clave principal lee los bloques en el orden siguiente:
1. Bloque 1
2. Bloque 2
Para acceso a los datos de contraste en una tabla de montón organizada en una tabla organizada por índices, supongamos que el bloque 1 de un segmento de la tabla departamentos montón organizado contiene filas de la siguiente manera:

 

50,Shipping,121,1500

20,Marketing,201,1800

 

Bloque 2 contiene las filas de la misma tabla de la siguiente manera:

 

30,Purchasing,114,1700

60,IT,103,1400

 

Un bloque de hoja de índice B-tree para esta tabla de montón organizado contiene las entradas siguientes, en donde el primer valor es la clave principal y la segunda es el ROWID:

20,AAAPeXAAFAAAAAyAAD

30,AAAPeXAAFAAAAAyAAA

50,AAAPeXAAFAAAAAyAAC

60,AAAPeXAAFAAAAAyAAB

 

Una exploración de las filas de la tabla con el fin de clave principal lee los bloques de segmentos de la tabla en la siguiente secuencia:

1. Bloque 1
2. Bloque 2
3. Bloque 1
4. Bloque 2


Por lo tanto, el número de bloque de E / S en este ejemplo es el doble del número de índice en el ejemplo-organizada.


Tablas de índice organizadas con Row Area Overflow


Cuando se crea una tabla organizada por índices, puede especificar un segmento separado como un área de desbordamiento fila. En las tablas de índice organizadas, las entradas del índice B-tree pueden ser grandes, ya que contienen una fila completa, por lo que un segmento aparte de contener las entradas es útil. Por el contrario, las entradas B-árboles son generalmente pequeñas, ya que consisten en la llave y ROWID.

Si se especifica un área de desbordamiento de fila, a continuación, la base de datos se puede dividir una fila en una tabla organizada por índices de lo siguiente:

• La entrada de índice

Esta parte contiene los valores de columna de todas las columnas de clave principal, una RowId físico que apunta a la parte desbordamiento de la fila y, opcionalmente, algunas de las columnas sin clave. Esta parte se almacena en el segmento de índice.

• La parte de desbordamiento

Esta parte contiene los valores de columna de las columnas sin clave restantes. Esta parte se almacena en el segmento de área de almacenamiento de desbordamiento.


Índices secundarios en las tablas de índice organizadas


Un índice secundario es un índice en una tabla organizada por índices. En cierto sentido, es un índice en un índice. El índice secundario es un objeto de esquema independiente y se almacena por separado de la tabla organizada por índices.

Como se explica en "Tipos de datos ROWID", Oracle Database utiliza identificadores de fila llamados ROWIDs lógicas para las tablas de índice organizadas. Un ROWID lógico es una representación codificada en base 64 de la clave primaria de tabla. La longitud ROWID lógico depende de la longitud de la clave primaria.

Las filas de bloques hoja de índice se pueden mover dentro o entre los bloques debido a inserciones. Las filas de las tablas de índice organizadas no migran como filas montón organizados hacen (véase "Las filas encadenadas y migradas"). Dado que las filas de las tablas de índice organizadas no tienen direcciones físicas permanentes, la base de datos utiliza ROWIDs lógicas basadas en la clave principal.

Por ejemplo, supongamos que la tabla de departamentos es organizada por índices. La columna location_id almacena el ID de cada departamento. La tabla almacena las filas de la siguiente manera, con el último valor que el ID de la población:

 

10,Administration,200,1700

20,Marketing,201,1800

30,Purchasing,114,1700

40,Human Resources,203,2400

 

Un índice secundario en la columna location_id podría tener entradas de índice de la siguiente manera, donde el valor después de la coma es el ROWID lógico:

 

1700,*BAFAJqoCwR/+

1700,*BAFAJqoCwQv+

1800,*BAFAJqoCwRX+

2400,*BAFAJqoCwSn+

 

Los índices secundarios proporcionan acceso rápido y eficiente a las tablas de índice organizadas con columnas que no son ni la clave principal ni un prefijo de la clave primaria. Por ejemplo, una consulta de los nombres de los departamentos cuyo identificador es mayor que 1700 podrían usar el índice secundario para acelerar el acceso de datos.

 

ROWIDs conjeturas lógicas y físicas

Los índices secundarios utilizan las ROWIDs lógicas para localizar filas de la tabla. Un ROWID lógico incluye una conjetura física, que es el ROWID física de la entrada de índice cuando se hizo por primera vez. Oracle Database puede utilizar las sugerencias físicas para investigar directamente en el bloque de la hoja de la tabla organizada por índices, sin pasar por la búsqueda de la clave principal. Cuando la ubicación física de una fila cambia, el ROWID lógica sigue siendo válido incluso si contiene una conjetura física que es rancio.

Para una tabla de montón organizado, el acceso de un índice secundario consiste en un análisis del índice secundario y un adicional de I / O para buscar el bloque de datos que contiene la fila. Para las tablas de índice-organizados, el acceso de un índice secundario varía, dependiendo del uso y la exactitud de conjeturas físicas:

• Sin conjeturas físicas, el acceso implica dos exploraciones de índices: un análisis del índice secundario seguido de un análisis del índice de clave primaria.

• Con conjeturas físicas, el acceso depende de la precisión:

o Con conjeturas físicas precisas, acceso implica una exploración de índice secundario y un adicional de I / O para ir a buscar el bloque de datos que contiene la fila.

o Con conjeturas físicas imprecisas, acceso implica una exploración de índice secundario y un I / O para ir a buscar el bloque de datos incorrecto (según lo indicado por la conjetura), seguida de una exploración de índice único de la tabla de índice organizado por el valor de la clave primaria.

Índices de mapas de bits de las tablas de índice organizadas

Un índice secundario en una tabla organizada por índices puede ser un índice de mapa de bits. Como se explica en "Indicadores de mapa de bits", un índice de mapa de bits almacena un mapa de bits para cada clave de índice.

Cuando existen índices de mapa de bits en una mesa organizada por índices, todos los índices de mapa de bits utilizan una tabla de asignación de almacenamiento dinámico organizado. La tabla de asignación almacena los ROWIDs lógicas de la tabla organizada por índices. Cada fila de la tabla de asignación almacena un ROWID lógico para la fila de tabla organizada por índices correspondientes.

La base de datos tiene acceso a un índice de mapa de bits utilizando una clave de búsqueda. Si la base de datos se encuentra la clave, a continuación, la entrada de mapa de bits se convierte en un ROWID física. Con mesas montón organizados, la base de datos utiliza el ROWID física para acceder a la tabla base. Con las tablas de índice-organizados, la base de datos utiliza el ROWID física para acceder a la tabla de asignación, que a su vez produce un ROWID lógico que la base de datos utiliza para acceder a la tabla de índice-organizada.
Nota:

Movimiento de filas en una tabla organizada por índices no deja los índices bitmap construidas sobre la mesa organizada por índices inutilizable.


Indices BTREE
Muchas veces, usamos los índices de acuerdo a las búsquedas que se están haciendo delimitando la información por la parte Where de una consulta. Sin embargo, no sabemos cómo es que se usa o cómo es que funciona dicho índice por dentro. Aquí una breve, resumida pero nutritiva explicación al respecto. Espero les guste.
Ok, vamos a pensar que tenemos varios números para alimentar una estructura. Los números son:
7 4 12 10 3 1 5

Búsqueda en un arreglo (tabla)

Al meter los números mencionados en un arreglo ordenado, quedarían como sigue:
Ahora, para buscar un número en dicho arreglo, no tenemos otra que compararlo contra cada uno de los elementos del mismo. Para encontrar un elemento de esta forma, se tiene que si el arreglo tiene n elementos, entonces, por promedio demoraremos n/2 comparaciones en encontrar el número que buscamos.
Así, en nuestro arreglo, tardaremos 3.5 comparaciones en promedio en encontrar cualquier número. Es decir, podríamos demorar una comparación si buscamos el 1 y 7 comparaciones si buscamos el 12.
Este arreglo nos simula una búsqueda de tipo FULL TABLE ACCESS en una tabla que NO tiene índices o cuya búsqueda se hace por un campo de una tabla que no está indexado.
Ok, entonces, ¿de qué forma podemos realizar una búsqueda más rápida?
Búsqueda en un árbol binario
¿Qué pasa si como van llegando nuestros números de prueba, los metemos en un árbol binario?
Hay que recordar que conforme lleguen los elementos, se pone el de valor intermedio en el nodo raíz y de ahí, los elementos mayores a ese nodo, se colocan a la derecha y los elementos menores, se colocan a la izquierda. Si es necesario, se balancea el árbol para que quede con las hojas repartidas equitativamente. Así, obtenemos un árbol como el que sigue:
Para realizar una búsqueda en este árbol se realizará mucho más rápido que en nuestro ejemplo anterior. Por ejemplo, para buscar el número 1, tendremos que hacer 3 comparaciones para encontrarlo, primero contra 5, después contra el 3 y finalmente contra el 1.
Después de comparar el número a buscar contra cada nodo, se sabrá para dónde ir: a la izquierda si es menor al nodo o a la derecha si es mayor al nodo.
Si buscamos el número 12, también se realizan 3 comparaciones: primero contra el 5, después contra 10 y al final, contra el mismo 12. Como se puede ver, se agiliza la búsqueda.
Pero, otra vez, ¿qué será más rápido?

Búsqueda en un árbol B-Tree (B* o B+)

Para responder a la última pregunta del punto anterior, tenemos que recurrir a los árboles B-Tree o B+ como se puede encontrar referencia a ellos. Prácticamente todos los índices de los RBDMS más famosos y comunes, entre ellos Oracle; se basan en este tipo de árboles. La tecnología detrás de estos árboles no es parte de este post; pero si, una explicación general
¿Cómo es un árbol de este tipo? En la siguiente imagen, vemos un ejemplo del mismo:
Es muy similar a un árbol binario. Sólo que cada uno de los nodos es un arreglo de n elementos. Y de cada elemento de dicho arreglo, se deriva un nuevo nodo hijo con los mismos n elementos. En RDBMS como Oracle, Informix, DB2; n vale 128.
Nota. Hay que recordar que hablando ya de índices, cada uno de los elementos de cada nodo será un registro.
De este forma en el 1er nivel del árbol podemos guardar:
128 elementos o registros
En el 2o nivel, tendremos 128 x 128 registros, es decir:
16,384 registros
En el 3er nivel, tendremos 128 x 128 x 128, es decir:
2’097,152 registros
En total, en un árbol con 3 niveles, tendremos capacidad para guardar:
2’113,664 elementos o registros
Ahora, ¿cuánto nos tardamos en encontrar un elemento en un árbol de estas dimensiones? Supongamos que nuestro elemento se encuentra en el nivel más bajo de este árbol.
Para encontrar nuestro registro, comparamos contra los elementos en el nodo raíz. Si recordamos nuestra comparación en arreglos, tardaremos n/2 comparaciones en saber cuál es el nodo hijo al que tendremos que ir. Basado en el tamaño de n, sabremos que en promedio, tardaremos 64 comparaciones en cada nodo.
Bajo nuestro supuesto de que el registro que buscamos está hasta el 3er nivel, tendremos en total 64 comparaciones x 3 nodos. Es decir:
¡ 192 comparaciones para encontrar un registro en una tabla de 2’113,664 registros !
¡Imaginen! si agregamos un nivel más de elementos, será un índice de 270’549,120 registros y para encontrar un registro, nos demorará ¡sólo 256 comparaciones!