4 OPERACIN Y MANTENIBILIDAD Trata acerca de como se hacen las bitacoras.

Que funcion tienen y porque son tan importantes, ademas es necesario conocer porque son importante a la hora de realizar cambios o conocer un poco mas del sistema de base de datos que se esta manejando. 4.1 Bitcoras de trabajo del DBMS En muchos DBMS la bitcora incluye todo tipo de consulta incluyendo aquellas que no modifican los datos. La operacin ROLLBACK est basada en el uso de una bitcora. El DBMS (Sistema Manejador de Bases de Datos) mantiene una bitcora o diario en cinta o en disco, comnmente, en el cual se registran los detalles de todas las operaciones de actualizacin, en particular, los valores iniciales y final del objeto modificado. Por tanto, si resulta necesario anular alguna modificacin especfica, el sistema puede utilizar la entrada correspondiente de la bitcora para restaurar el valor original del objeto restaurado. 4.1.1. Funciones especifica de las bitcoras La estructura ms ampliamente usada para grabar las modificaciones de la base de datos es la Bitcora. Cada registro de la bitcora escribe una nica escritura de base de datos y tiene lo siguiente:

Nombre de la Transaccin Valor antiguo Valor Nuevo

Es fundamental que siempre se cree un registro en la bitcora cuando se realice una escritura antes de que se modifique la base de datos. Tambin tenemos la posibilidad de deshacer una modificacin que ya se ha escrito en la base de datos, esto se realizar usando el campo del valor antiguo de los registros de la bitcora. Los registros de la bitcora deben residir en memoria estable como resultado el volumen de datos en la bitcora puede ser exageradamente grande. Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de sincronizacin lo cual representa el lmite entre dos transacciones consecutivas, o el final de una unidad lgica de trabajo, y por tanto al punto en el cual la base de datos esta (o debera estar) en un estado de consistencia. Las nicas operaciones que establecen un punto de sincronizacin son COMMIT, ROLLBACK y el inicio de un programa. Cuando se establece un punto de sincronizacin: Se comprometen o anulan todas las modificaciones realizadas por el programa desde el punto de sincronizacin anterior. Se pierde todo posible posicionamiento en la base de datos. Se liberan todos los registros bloqueados. Es importante advertir que COMMIT y ROLLBACK terminan las transaccin, no el programa.

4.1 Bitcoras de trabajo del DBMS. 4.1.1. Funciones especfica de las bitcoras. Qu es el Redo Log? La estructura ms importante para las operaciones de recuperacin es el registro de rehacer, que consiste en dos o ms archivos preasignados que almacenan todos los cambios realizados en la base de datos a medida que ocurren. Cada instancia de una base de datos Oracle tiene un registro de rehacer asociado para proteger la base de datos en caso de fallo de instancia. Rehacer Realizar registro Rehacer los archivos de registro se llena de registros de rehacer. Un registro de rehacer, tambin llamado una entrada de rehacer, se compone de un grupo de vectores de cambio, cada uno de los cuales es una descripcin de un cambio realizado en un solo bloque en la base de datos. Por ejemplo, si cambia un valor salarial en una tabla de empleados, se genera un registro de rehacer contienen vectores de cambio que describen cambios en el segmento de bloque de datos de la tabla, el bloque de datos de deshacer segmento, y la mesa de operaciones de los segmentos de deshacer. Vuelva a realizar entradas de datos de registro que puede utilizar para reconstruir todos los cambios realizados en la base de datos, incluyendo los segmentos de deshacer. Por lo tanto, el registro de rehacer tambin protege los datos de rollback. Al recuperar la base de datos utilizando datos redo, la base de datos lee los vectores de cambio en los registros de rehacer y aplica los cambios a los bloques correspondientes. Registros Redo se almacenan en forma circular en el bfer del registro de rehacer de la SGA (ver "Cmo Oracle Database escribe a los Redo Log") y se escriben en uno de los archivos de registro de rehacer por el escritor Log (LGWR) proceso en segundo plano base de datos. Cuando se confirma una transaccin, LGWR escribe los registros de rehacer las transacciones desde el buffer de redo log del SGA en un archivo de registro de rehacer, y asigna un nmero de cambio de sistema (SCN) para identificar los registros de rehacer para cada transaccin confirmada. Slo cuando todos los registros de rehacer asociados a una transaccin determinada son con seguridad en el disco en los registros en lnea es el proceso de usuario notificado de que la transaccin haya sido cometido. Registros Redo tambin se pueden escribir en un archivo de registro de rehacer antes de que se confirme la transaccin correspondiente. Si el buffer de redo log se llena, u otra transaccin se confirma, sofocos LGWR todas las entradas de registro de rehacer en el buffer de redo log en un archivo de registro de rehacer, a pesar de que algunos registros de rehacer no podrn ser comprometidos. Si es necesario, la base de datos se puede revertir estos cambios. Cmo Oracle Database escribe a los Redo Log El registro de rehacer de una base de datos consiste en dos o ms archivos de registro de rehacer. La base de datos requiere un mnimo de dos archivos de garantizar que uno est siempre disponible para la escritura, mientras que el otro est siendo archivados (si la base de datos est en modo ARCHIVELOG). Consulte "Administracin de registros de rehacer archivados" para obtener ms informacin. LGWR escribe a rehacer los archivos de registro de forma circular. Cuando el archivo de registro de rehacer actual llena, LGWR comienza a escribir al siguiente archivo de registro de rehacer disponible. Cuando el ltimo archivo de registro de rehacer disponible est llena, LGWR vuelve al primer archivo de registro de rehacer y escribe en l, comenzando el ciclo otra vez. La figura 12-1

ilustra la escritura circular del archivo de registro de rehacer. Los nmeros al lado de cada lnea indican el orden en que LGWR escribe a cada archivo de registro de rehacer. Los archivos de registro de rehacer rellenos estn disponibles para LGWR para su reutilizacin en funcin de si el archivo est activada. Si el archivo est desactivado (la base de datos est en modo NOARCHIVELOG), un archivo de registro de rehacer lleno est disponible despus de los cambios registrados en l se han escrito en los archivos de datos. Si est habilitado el archivado (la base de datos est en modo ARCHIVELOG), un archivo de registro de rehacer lleno est disponible para LGWR despus de los cambios registrados en l se han escrito en los archivos de datos y el archivo se ha archivado. Figura 12-1 Reutilizacin de los archivos de registro de rehacer por LGWR

Descripcin del "Figura 12-1 Reutilizacin de los archivos de registro de rehacer por LGWR" Archivos Redo Log activo (actual) e inactiva Base de datos Oracle utiliza slo uno los archivos de registro de rehacer a la vez para almacenar los registros de rehacer escritos del bfer del registro de rehacer. El archivo de registro de rehacer LGWR que est escribiendo activamente se llama el archivo de registro de rehacer actual. Rehacer los archivos de registro que se requieren para la recuperacin de la instancia se denominan archivos de registro de rehacer activos. Rehacer los archivos de registro que ya no son necesarios para la recuperacin de la instancia se denominan archivos de registro de rehacer inactivos.

Si ha habilitado el archivado (la base de datos est en modo ARCHIVELOG), entonces la base de datos no se puede reutilizar o sobrescribir un archivo de registro en lnea activa hasta que uno de los procesos en segundo plano archivador (ARCn) ha archivado su contenido. Si el archivo est desactivado (la base de datos est en modo NOARCHIVELOG), a continuacin, cuando el ltimo archivo de registro de rehacer est llena, LGWR sigue sobrescribiendo el archivo de registro siguiente en la secuencia cuando est inactivo. Interruptores y Nmeros de secuencia de registro Entrar Un cambio de registro es el punto en el que la base de datos deja de escribir en un archivo de registro de rehacer y comienza a escribir a otro. Normalmente, un cambio de registro se produce cuando el archivo de registro de rehacer actual est completamente lleno y la escritura debe seguir el siguiente archivo de registro de rehacer. Sin embargo, puede configurar switches de registro que se produzca a intervalos regulares, con independencia de que el archivo de registro de rehacer actual est completamente lleno. Tambin puede forzar interruptores de registro de forma manual. Oracle Database asigna a cada registro de rehacer presentar un nuevo nmero de secuencia de registro cada vez que se produce un cambio de registro y LGWR comienza a escribir a la misma. Cuando los archivos de base de datos rehacer los archivos de registro, el registro de archivado retiene su nmero de secuencia de registro. Un archivo de registro de rehacer que se encenda de nuevo para su uso se le da el siguiente nmero de secuencia de registro disponibles. Cada archivo de registro de rehacer en lnea o archivados se identifica por su nmero de secuencia de registro. Durante el accidente, instancia o la recuperacin de medios, la base de datos se aplica correctamente los archivos de registro de rehacer en orden ascendente utilizando el nmero de secuencia de registro de los archivos de registro archivados y rehacer necesarias. Planificacin de la Redo Log Esta seccin proporciona pautas que debe tener en cuenta al configurar una instancia de base de datos de registro de rehacer y contiene los siguientes temas: Archivos de registro Redo Multiplexacin La colocacin de Ingreso de Miembros Rehacer en diferentes discos Planificar el tamao de los archivos de registro de rehacer Planificar el tamao del bloque de los archivos de registro de rehacer Seleccin del nmero de archivos de registro Redo Control Lag Archivo Archivos Redo Log Multiplexacin Para proteger contra un fallo que implica la redo log en s, Oracle Database permite un registro de rehacer multiplexados, lo que significa que dos o ms copias idnticas de la redo log se pueden mantener de forma automtica en lugares separados. Para obtener el mayor beneficio, estos lugares deben estar en discos separados. Incluso si todas las copias del registro de rehacer estn en el mismo disco, sin embargo, la redundancia puede ayudar a proteger contra errores de E / S, corrupcin de archivos, etc. Cuando los archivos de registro de rehacer son multiplexadas, LGWR escribe simultneamente la misma informacin de registro de rehacer en varios archivos de registro de rehacer idnticas, lo que elimina un punto nico de fallo de registro de rehacer. Multiplexacin se realiza mediante la creacin de grupos de archivos de registro de rehacer. Un

grupo consta de un archivo de registro de rehacer y sus copias multiplexadas. Cada copia idntica se dice que es un miembro del grupo. Cada grupo de registro de rehacer se define por un nmero, tal como el grupo 1, grupo 2, y as sucesivamente. Figura 12-2 multiplexado rehacer los archivos de registro

En la Figura 12-2, A_LOG1 y B_LOG1 son miembros del Grupo 1, A_LOG2 y B_LOG2 son miembros del Grupo 2, y as sucesivamente. Cada miembro de un grupo debe ser del mismo tamao. Cada miembro de un grupo de archivos de registro es simultneamente activo, es decir, al mismo tiempo escrita por LGWR-como lo indican los registros idnticos nmeros de secuencia asignados por LGWR. En la Figura 12-2, primero LGWR escribe simultneamente tanto A_LOG1 y B_LOG1. A continuacin, se escribe al mismo tiempo para tanto A_LOG2 y B_LOG2, y as sucesivamente. LGWR nunca escribe al mismo tiempo a los miembros de los diferentes grupos (por ejemplo, para A_LOG1 y B_LOG2). Nota: Oracle recomienda multiplex sus archivos de registro de rehacer. La prdida de los datos del archivo de registro puede ser catastrfico si se requiere la recuperacin. Tenga en cuenta que cuando se multiplex el registro de rehacer, la base de datos debe aumentar la cantidad de E / S que se realiza. Dependiendo de su configuracin, esto puede afectar al rendimiento de base de datos global. En respuesta a rehacer fracaso Log Siempre LGWR no puede escribir en un miembro de un grupo, la base de datos marca ese miembro como no vlido y escribe un mensaje de error en el archivo de rastreo LGWR y para el registro de alertas de bases de datos para indicar el problema con los archivos inaccesibles. La reaccin especfica de LGWR cuando un miembro del registro de rehacer no est disponible depende de la razn de la falta de disponibilidad, tal como se resume en la tabla que sigue.

Condition

LGWR Action

LGWR puede escribir con xito en al menos Escritura procede como normal. LGWR escribe a los un miembro de un grupo miembros disponibles de un grupo e ignora a los miembros de carcter. LGWR no puede acceder el siguiente grupo Operacin de base de datos se detiene en la conmutacin de registro ya que el temporalmente hasta que el grupo est disponible o grupo debe archivarse hasta que el grupo se archiva. Todos los miembros del grupo siguiente son inaccesibles para el LGWR en una conmutacin de registro debido a fallas en los medios Base de datos Oracle devuelve un error, y cierra la instancia de base de datos. En este caso, puede que necesite realizar la recuperacin de los medios de comunicacin sobre la base de datos de la prdida de un archivo de registro de rehacer. Si el puesto de control de la base de datos ha ido ms all del log de redo perdidas, recuperacin de los medios de comunicacin no es necesario, porque la base de datos ha salvado los datos registrados en el registro de rehacer a los archivos de datos. Slo necesita soltar el grupo de registro de rehacer inaccesibles. Si la base de datos no archiva el registro mal, usar sin alterar la base de datos claro LOFGILE archivar para desactivar el archivo antes de que el registro se puede caer.

Todos los miembros de un grupo de Base de datos Oracle devuelve un error y la instancia repente sean inaccesibles para el LGWR de base de datos se apaga inmediatamente. En este mientras est escribiendo en ellos caso, puede que necesite para llevar a cabo la recuperacin de los medios de comunicacin. Si los medios de comunicacin que contiene el registro no est realmente perdido--por ejemplo, si inadvertidamente se apag la unidad para el registro - recuperacin de los medios de comunicacin no necesite. En este caso, usted slo necesita vuelva a encender la unidad y deje que la base de datos a realizar la recuperacin automtica de la instancia.

Configuraciones legales e ilegales En la mayora de los casos, un registro de rehacer multiplexados debe ser simtrica: todos los grupos de registro de rehacer deben tener el mismo nmero de miembros. Sin embargo, la base de datos no requiere que un registro de rehacer multiplexados ser simtrica. Por ejemplo, un grupo puede tener slo un miembro, y otros grupos puede tener dos miembros. Esta configuracin protege contra fallos de disco que afecten temporalmente a algunos miembros de registro de rehacer, pero dejan intactos los dems.

El nico requisito para un registro de rehacer ejemplo es que tenga al menos dos grupos. La figura 12-3 muestra las configuraciones de registro de rehacer multiplexados legales e ilegales. La segunda configuracin es ilegal, ya que tiene un solo grupo. Figura 12-3 Configuracin del registro de rehacer multiplexados legales e ilegales

Description of "Figure 12-3 Legal and Illegal Multiplexed Redo Log Configuration"

La colocacin de Ingreso de Miembros Rehacer en diferentes discos Cuando la creacin de un registro de rehacer multiplexados, lugar miembros de un grupo en diferentes discos fsicos. Si un disco falla, entonces slo uno de los miembros de un grupo se convierte en no disponible para LGWR y otros miembros siguen siendo accesibles a LGWR, por lo que el ejemplo puede seguir funcionando. Si el archivo del registro de rehacer, se extendi rehacer miembros de registro a travs de los discos para eliminar la discordia entre los procesos de fondo y ARCN LGWR. Por ejemplo, si tiene dos grupos de miembros del registro de rehacer multiplexados (un registro de rehacer doble cara), coloque cada miembro en un disco diferente y establecer su destino de archivado con un quinto disco. Si lo hace, evitar la contencin entre LGWR (escrito a los miembros) y ARCn (lectura de los miembros). Archivos de datos tambin deben ser colocados en diferentes discos a partir de archivos de registro de rehacer para reducir la contencin en escribir bloques de datos y rehacer los registros. Planificacin del tamao de los archivos de registro de rehacer Al ajustar el tamao de los archivos de registro de rehacer, considere si se le archivando el registro de rehacer. Rehacer los archivos de registro deben ser de un tamao que un grupo de llenado puede ser archivado en una sola unidad de medios de almacenamiento fuera de lnea (tal como una cinta o disco), con la menor cantidad de espacio en el medio no se lo usa. Por ejemplo, supongamos que slo un grupo de redo log lleno puede caber en una cinta y un 49% de la capacidad de almacenamiento en cinta sigue sin ser utilizado. En este caso, es mejor para reducir el tamao de los archivos de registro de rehacer ligeramente, de modo que dos grupos de registro podran ser archivados en cada cinta. Todos los miembros de un mismo grupo de registro de rehacer multiplexados deben ser del mismo tamao. Los miembros de los diferentes grupos pueden tener diferentes tamaos. Sin embargo, no hay ninguna ventaja en mayor o menor tamao de archivo entre los grupos. Si los controles no estn ajustados a producirse entre los switches de registro, hacer que todos los grupos del mismo tamao para garantizar que los puestos de control se producen a intervalos regulares. El tamao mnimo permitido para un archivo de registro de rehacer es de 4 MB. Vea tambin: Su sistema operativo especfico de documentacin de Oracle. El tamao por defecto de los archivos de registro de rehacer es el sistema operativo dependiente. Planificacin del tamao de bloque de los archivos de registro de rehacer A diferencia del tamao de bloque de base de datos, que puede ser entre 2 K y 32 K, rehacer los archivos de registro siempre predeterminada a un tamao de bloque que es igual al tamao de sector fsico del disco. Histricamente, esto ha sido tpicamente 512 bytes (512B). Algunas unidades de disco nuevas de alta capacidad ofrecen 4K bytes (4K) tamaos de sector, tanto para aumentar la capacidad ECC y la mejora de la eficiencia de formato. La mayora de las plataformas de base de datos Oracle son capaces de detectar este tamao de sector ms grande. La base de datos se crea automticamente los archivos de registro de rehacer con un tamao de bloque de 4K en esos discos.

Sin embargo, con un tamao de bloque de 4K, hay una mayor desperdicio redo. De hecho, la cantidad de desperdicio de rehacer en bloques de 4K frente a bloques 512B es significativa. Se puede determinar la cantidad de desperdicio redo viendo las estadsticas almacenadas en el V $ SESSTAT y V $ SYSSTAT vistas. SQL> SELECT name, value FROM v$sysstat WHERE name = 'redo wastage'; NAME VALUE -------------------------------- ---------redo wastage 17941684 Para evitar el desperdicio redo adicional, si est utilizando el modo de emulacin de unidades de disco del tamao del sector disks-4K que emulan un tamao de sector 512B en la Interfaz del disco-puede invalidar el tamao de bloque de 4K predeterminado para registros de rehacer especificando un tamao de bloque 512B o , para algunas plataformas, un tamao de bloque de 1K. Sin embargo, se le cobrar una degradacin significativa del rendimiento cuando un registro de escritura redo no est alineada con los principios del sector fsico de 4K. Debido a siete de las ocho ranuras 512B en un sector fsico de 4K no estn alineados, la degradacin del rendimiento que normalmente ocurre. Por lo tanto, se debe evaluar el equilibrio entre el rendimiento y el desperdicio de disco en la planificacin del tamao de bloque de redo log en los discos en modo de emulacin de tamao de sector de 4 KB. A partir de Oracle Database 11g versin 2, puede especificar el tamao del bloque de archivos de registro de rehacer en lnea con la palabra clave BLOCKSIZE en el CREATE DATABASE, ALTER DATABASE, y CREATE CONTROLFILE. Los tamaos de los bloques permitidos son 512, 1024 y 4096. La siguiente declaracin se suma un grupo de archivos de registro de rehacer con un tamao de bloque de 512B. La clusula BLOCKSIZE 512 es vlido pero no es necesario para los discos de tamao de sector 512B. Para los discos de modo de emulacin de tamao de sector de 4 KB, la clusula BLOCKSIZE 512 anula el tamao de 4K defecto. ALTER DATABASE orcl ADD LOGFILE GROUP 4 ('/u01/logs/orcl/redo04a.log','/u01/logs/orcl/redo04b.log') SIZE 100M BLOCKSIZE 512 REUSE; Para determinar el tamao de bloque del archivo de registro de rehacer, ejecute la siguiente consulta: SQL> SELECT BLOCKSIZE FROM V$LOG; BLOCKSIZE --------512 Seleccin del nmero de archivos de registro Redo La mejor manera de determinar el nmero apropiado de archivos de registro de rehacer de una instancia de base de datos es para probar diferentes configuraciones. La configuracin ptima con los grupos de menor nmero posible sin obstaculizar LGWR de escribir la informacin de registro de rehacer.

En algunos casos, un ejemplo de base de datos puede requerir slo dos grupos. En otras situaciones, una instancia de base de datos puede requerir grupos adicionales para garantizar que un grupo reciclado est siempre disponible para LGWR. Durante la prueba, la forma ms fcil para determinar si la configuracin del registro de rehacer actual es satisfactoria es examinar el contenido del archivo de rastreo LGWR y el registro de alertas de bases de datos. Si los mensajes de indicar que LGWR tiene con frecuencia que esperar a que un grupo debido a un puesto de control no se ha completado o un grupo no ha sido archivada, agregar grupos. Tenga en cuenta los parmetros que pueden limitar el nmero de archivos de registro de rehacer antes de crear o modificar la configuracin de un registro de rehacer instancia. Los siguientes parmetros limitan el nmero de archivos de registro de rehacer que se pueden agregar a una base de datos: El parmetro MAXLOGFILES utilizado en la instruccin CREATE DATABASE determina el nmero mximo de grupos de archivos de registro de rehacer para cada base de datos. Los valores del grupo pueden variar de 1 a MAXLOGFILES. Cuando el nivel de compatibilidad se establezca antes de 10.2.0, la nica manera de cambiar este lmite superior es volver a crear la base de datos o el archivo de control. Por lo tanto, es importante tener en cuenta este lmite antes de crear una base de datos. Cuando la compatibilidad se establece en 10.2.0 o posterior, puede superar el lmite MAXLOGFILES, y los archivos de control de ampliar segn sea necesario. Si MAXLOGFILES no se especifica la instruccin CREATE DATABASE, la base de datos utiliza un sistema de valores por defecto especficos de funcionamiento. El parmetro MAXLOGMEMBERS utilizado en la instruccin CREATE DATABASE determina el nmero mximo de miembros de cada grupo. Al igual que con MAXLOGFILES, la nica manera de cambiar este lmite superior es volver a crear el archivo de base de datos o de control. Por lo tanto, es importante tener en cuenta este lmite antes de crear una base de datos. Si no se especifica ningn parmetro MAXLOGMEMBERS para la instruccin CREATE DATABASE, la base de datos utiliza el valor por defecto del sistema operativo. Control Lag Archivo Puede forzar temas de registro de rehacer habilitados para cambiar sus registros actuales a intervalos de tiempo regulares. En una configuracin primario / en espera de base de datos, los cambios se ponen a disposicin de la base de datos standby archivando registros de rehacer en el sitio primario y luego enviarlos a la base de datos standby. Los cambios que se estn aplicando en la base de datos standby puede quedarse atrs de los cambios que se estn produciendo en la base de datos principal, debido a que la base de datos standby debe esperar a que los cambios en el registro de rehacer la base de datos primaria a archivar (en el registro de rehacer archivados) y luego enviado a la misma. Para limitar este retraso, puede establecer el parmetro de inicializacin ARCHIVE_LAG_TARGET. Al establecer este parmetro permite especificar en segundos el tiempo que el retraso puede ser. Ajuste de la inicializacin de parmetros ARCHIVE_LAG_TARGET Cuando se establece el parmetro de inicializacin ARCHIVE_LAG_TARGET, que causa la base de datos para examinar el registro de rehacer actual de la instancia peridicamente. Si se cumplen las siguientes condiciones, el ejemplo cambia el registro:

 El registro actual se cre antes de n segundos atrs, y el tiempo estimado para el archivo de registro actual es m segundo (proporcional al nmero de bloques de rehacer utilizados en el registro actual), donde n + m excede el valor de la inicializacin ARCHIVE_LAG_TARGET parmetro. El registro actual contiene registros de rehacer. En un entorno Real Application Clusters de Oracle, la instancia tambin causa otros temas para cambiar y archivar sus registros si se estn quedando atrs. Esto puede ser particularmente til cuando una instancia del clster es ms ocioso que los otros casos (como cuando se est ejecutando una configuracin primario / secundario de 2 nodos de Oracle Real Application Clusters). El parmetro de inicializacin ARCHIVE_LAG_TARGET proporciona un lmite superior para el tiempo (en segundos) que el registro actual de la base de datos puede abarcar. Debido a que tambin se considera el tiempo estimado de archivo, este no es el momento exacto interruptor de registro. La siguiente configuracin de parmetros de inicializacin establece el intervalo de cambio de registro de 30 minutos (un valor tpico). ARCHIVE_LAG_TARGET = 1,800 Un valor de 0 desactiva esta funcionalidad de conmutacin de registro basado en el tiempo. Esta es la configuracin por defecto. Puede establecer el parmetro de inicializacin ARCHIVE_LAG_TARGET incluso si no hay ninguna base de datos standby. Por ejemplo, el parmetro ARCHIVE_LAG_TARGET se puede configurar especficamente para forzar registros para ser conmutados y archivados. ARCHIVE_LAG_TARGET es un parmetro dinmico y se puede configurar con el comando SET ALTER SISTEMA. Precaucin: El parmetro ARCHIVE_LAG_TARGET debe establecerse en el mismo valor en todas las instancias de un entorno Real Application Clusters de Oracle. En caso contrario, los resultados por lo que un comportamiento impredecible. Factores que influyen en la configuracin de ARCHIVE_LAG_TARGET Tenga en cuenta los siguientes factores al determinar si desea establecer el parmetro ARCHIVE_LAG_TARGET y para determinar el valor de este parmetro. Registros Overhead de conmutacin (as como el archivo) Con qu frecuencia ocurren los interruptores de registro normales como resultado de las condiciones de registro completo Prdida de redo Cunto se tolera en la base de datos standby Configuracin ARCHIVE_LAG_TARGET no puede ser muy til si cambia de registro naturales ya se producen con ms frecuencia que el intervalo especificado. Sin embargo, en el caso de las irregularidades de la velocidad de generacin de redo, el intervalo proporciona un lmite superior del intervalo de tiempo cada registro actual cubre. Si el parmetro de inicializacin ARCHIVE_LAG_TARGET se establece en un valor muy bajo, no puede haber un impacto negativo en el rendimiento. Esto puede obligar a interruptores de

registro frecuentes. Ajuste el parmetro a un valor razonable a fin de no degradar el rendimiento de la base de datos primaria. 4.1.2 Recuperacin (rollback) Visin general de la recuperacin Instancia Recuperacin Instancia es el proceso de aplicacin de los registros en el registro de rehacer en lnea a archivos de datos para reconstruir los cambios realizados despus de la comprobacin ms reciente. Recuperacin Instancia se produce de forma automtica cuando un administrador intenta abrir una base de datos que se haya parado de manera inconsistente. Propsito de la recuperacin Instancia Recuperacin Instancia asegura que la base de datos est en un estado coherente despus de un fallo de ejemplo. Los archivos de una base de datos se puede dejar en un estado incoherente debido a cmo Oracle Database gestiona los cambios de base de datos. Un hilo redo es un registro de todos los cambios generados por una instancia. Una base de datos de instancia nica tiene un hilo de redo, mientras que una base de datos Oracle RAC tiene mltiples hilos de rehacer, uno para cada instancia de base de datos. Cuando se confirma una transaccin, inicie sesin escritor (LGWR) escribe tanto las entradas de redo que quedan en la memoria y el SCN transaccin en el registro de rehacer en lnea. Sin embargo, el proceso de la escritora de base de datos (DBWn) escribe bloques de datos modificados de los archivos de datos siempre que sea ms eficiente. Por esta razn, los cambios no pueden existir temporalmente en los archivos de datos, mientras que los cambios confirmados todava no existen en los archivos de datos. Si una instancia de una base de datos abierta falla, ya sea por una declaracin ABORTAR PARADA o terminacin anormal, a continuacin, las siguientes situaciones pueden dar lugar a: Los bloques de datos cometidos por una transaccin no se escriben en los archivos de datos y slo aparecen en el registro de rehacer en lnea. Estos cambios se deben volver a aplicar a la base de datos. Los archivos de datos contiene cambios que no se haban cometido cuando la instancia fall. Estos cambios deben ser deshacen de garantizar la coherencia transaccional. Recuperacin Instancia slo utiliza archivos de registro de rehacer en lnea y archivos de datos en lnea actuales para sincronizar los archivos de datos y asegurarse de que sean compatibles. Cuando se realiza la recuperacin de base de datos Oracle Instancia Si se requiere la recuperacin de la instancia depende del estado de los hilos de rehacer. Un hilo redo est marcada abierta en el archivo de control cuando una instancia de base de datos se abre en modo lectura / escritura modo, y est marcado cerrado cuando la instancia se cierra constantemente. Si las roscas estn marcados rehacer abierta en el archivo de control, pero no hay casos vivos mantienen el hilo encola correspondiente a estos temas, entonces la base de datos requiere la recuperacin de instancias.

Oracle Database realiza la recuperacin instancia automticamente en las siguientes situaciones: La base de datos se abre por primera vez tras el fracaso de una base de datos de una sola vez o todas las instancias de una base de datos Oracle RAC. Esta forma de recuperacin de la instancia tambin se conoce como recuperacin de fallos. Oracle Database recupera los temas de rehacer en lnea de los casos terminados juntos. Algunos, pero no todos los casos de una base de datos Oracle RAC no. Recuperacin Instancia se lleva a cabo automticamente por una instancia de sobrevivir en la configuracin. El proceso en segundo plano SMON realiza la recuperacin de ejemplo, la aplicacin de rehacer en lnea de forma automtica. No se requiere la intervencin del usuario. Importancia de los puntos de control para la recuperacin Instancia Recuperacin Instancia utiliza puntos de control para determinar qu cambios deben aplicarse a los archivos de datos. Las garantas de los puestos de control de posicin que cada cambio comprometido con una SCN menor que el SCN puesto de control se guarda en los archivos de datos. La figura 13-5 muestra el hilo redo en el registro de rehacer en lnea. Figura 13-5 Checkpoint Posicin en Redo Log Online

Durante la recuperacin de ejemplo, la base de datos debe aplicar los cambios que se producen entre la posicin del punto de control y el final de la rosca redo. Como se muestra en la Figura 135, algunos cambios pueden haber sido escrito a los archivos de datos. Sin embargo, nicamente los cambios en SCN inferiores a la posicin de punto de control se garantiza que sea el disco. Vea tambin: Oracle Database Performance Tuning Guide para aprender a limitar el tiempo de recuperacin de la instancia Fases de Recuperacin de instancia La primera fase de recuperacin de la instancia se llama recuperacin de cach o rodar hacia delante, y consiste en volver a aplicar todos los cambios registrados en el registro de rehacer en

lnea de los archivos de datos. Dado que los datos de reversin se registra en el registro de rehacer en lnea, rodando hacia adelante tambin regenera los correspondientes segmentos de deshacer. Rodando procede hacia adelante a travs de todos los archivos de registro de rehacer en lnea que sean necesarias para llevar a la base de datos en el tiempo. Despus de rodar hacia adelante, los bloques de datos contienen todos los cambios confirmados registrados en los archivos de registro de rehacer en lnea. Estos archivos tambin pueden contener cambios no confirmados que o se guardan en los archivos de datos antes de la falla, o se registran en el registro de rehacer en lnea y se introdujeron durante la recuperacin de la memoria cach. Despus de la puesta al da, todos los cambios que no fueron cometidos deben ser deshechos. Oracle Database utiliza la posicin del punto de control, lo que garantiza que todos los cambios comprometidos con una SCN menor que el SCN puesto de control se guarda en el disco. Oracle Database aplica deshacer bloques para deshacer los cambios no comprometidos en los bloques de datos que se escribieron antes del fallo o introducidos durante la recuperacin de la memoria cach. Esta fase se llama de nuevo o recuperacin de transacciones rodar. La figura 13-6 ilustra rodar hacia adelante y retroceder, los dos pasos necesarios para recuperarse de un error de instancia de base. Figura 13-6 bsicos Pasos de recuperacin de instancias: rodando hacia delante y Rolling Back

Oracle Database puede deshacer varias operaciones al mismo tiempo como sea necesario. Todas las transacciones que estaban activas en el momento del fallo se marcan como terminadas. En lugar de esperar a que el proceso SMON retrotraer transacciones terminadas, las nuevas

transacciones se pueden hacer retroceder los propios bloques individuales para obtener los datos necesarios. 4.1.3 Permanencia (commit) En el contexto de la Ciencia de la computacin y la gestin de datos, commit (accin de comprometer) se refiere a la idea de consignar un conjunto de cambios "tentativos, o no permanentes". Un uso popular es al final de una transaccin de base de datos. Una sentencia COMMIT en SQL finaliza una transaccin de base de datos dentro de un sistema gestor de base de datos relacional (RDBMS) y pone visibles todos los cambios a otros usuarios. El formato general es emitir una sentencia BEGIN WORK, una o ms sentencias SQL, y entonces la sentencia COMMIT. Alternativamente, una sentencia ROLLBACK se puede emitir, la cual deshace todo el trabajo realizado desde que se emiti BEGIN WORK. Una sentencia COMMIT publicar cualquiera de los savepoints (puntos de recuperacin) existentes que puedan estar en uso. El DBWn es un proceso flojo, ya que no es un proceso que cada n segundos este escribiendo los datos del Buffer Cache a los datafiles, si no que es activado por otro proceso (Como CKPT por ejemplo). Suponer que incremento mi salario de 1 USD a 5 USD en la tabla employees, e inmediatamente despues hago un commit. Pregunta, si se hace un commit, encontrara el valor de 5 USD en los datafiles? Antes de responder esta pregunta, vamos a poner otra situacin con el mismo ejemplo, en lugar de cometer mis datos despus del incremento salarial espere el fin de semana para reflexionar en este cambio, solamente dejo la sesin abierta sin cometer los datos. El lunes que regreso, y verifico los datos directamente en los datafiles, que valor encontrara, 1 o 5 USD? La lgica me llevara a decir que, 1 USD, ya que nunca comet mis datos? Si con este escenario, acurdate que no hemos cometido los datos, si se checaran los datos en el Online Redo Log, que valorse encontrara, 1 o 5 USD? Si tu respuesta fue 1 USD, seria la mas lgica, ya que no se han cometido los datos y no son necesarios para el proceso de recuperacin en caso de que mi base de datos se cayera, si respondiste 5 USD, entonces como explicaras el proceso de recuperacin en caso de que se haya cado la instancia, si cuando se hace una recuperacin los procesos leen del Online Redo Log, y el valor que se encuentra es el de 5 USD? Antes de empezar las respuestas son 1,5 y 5 USD Vamos a tratar de explicarlo aqu abajo Crea un tablespace pequeo, en este caso de 1M, y crea en el usuario hr, una tabla llamada prueba_salario, y en esta tabla inserta el dato de salario TESTDB >create tablespace prueba datafile '/mount/u01/oracle/TESTDB/data/pruebas01.dbf' size 1m;

Tablespace created. TESTDB >create table hr.prueba_salario (salario varchar2(200)) tablespace prueba; Table created. TESTDB >insert into hr.prueba_salario values ('1_USD'); 1 row created. TESTDB >commit; Commit complete. Una vez que completes esto, recicla la base de datos, ya que no queremos que nada se encuentre en memoria, y si te fijas, el dato de 1_USD lo puedes ver en el datafile oracle@localhost [TESTDB] /mount/u01/oracle/TESTDB/data root $ strings /mount/u01/oracle/TESTDB/data/pruebas01.dbf z{|} 5wXTESTDB PRUEBA 1_USD Y ahora haz un update a la tabla hr.prueba_salario y realiza un commit, inmediatamente despus verifica de nuevo el datafile, y te vas a dar cuenta que este dato que acabas de actualizar no se encuentra en el datafile, que sigues viendo el valor de 1_USD TESTDB >update hr.prueba_salario set salario = '5_USD'; 1 row updated. TESTDB >commit; Commit complete. oracle@localhost [TESTDB] /mount/u01/oracle/TESTDB/data root $ strings /mount/u01/oracle/TESTDB/data/pruebas01.dbf z{|} 5wXTESTDB PRUEBA 1_USD En el momento que mandamos llamar al proceso de CKPT, es cuando los buffers "sucios" se escriben a disco, despues de que hagas un checkpoint, verifica de nuevo el datafile, y te vas a dar cuenta que el datafile esta actualizado con el nuevo valor de 5_USD.

TESTDB >alter system checkpoint; System altered. oracle@localhost [TESTDB] /mount/u01/oracle/TESTDB/data root $ strings /mount/u01/oracle/TESTDB/data/pruebas01.dbf z{|} 5wXTESTDB PRUEBA 5_USD Ahora vamos a hacer otra prueba, tira la tabla prueba_salario, vuelvela a crear, vuelve a insertar el dato de 1_USD y una vez que finalices esto, recicla la base de datos para asegurarnos que no se encuentre nada en memoria. Ahora vamos a hacer un update a la tabla de prueba salario, y no vamos a hacer un commit, solamente vamos a llamar al proceso de CKPT. TESTDB >update hr.prueba_salario set salario = '5_USD'; 1 row updated. TESTDB >alter system checkpoint; System altered. Si te fijas abajo, el dato de 5_USD es el que se encuentra en el datafile y no el de 1_USD, aunque no hemos hecho un commit de los datos. oracle@localhost [TESTDB] /mount/u01/oracle/TESTDB/data root $ strings /mount/u01/oracle/TESTDB/data/pruebas01.dbf z{|} 5wXTESTDB PRUEBA 5_USD Abre una nueva sesin y haz un query a la tabla y te fijaras que el dato de 1_USD es el que te arroja, que es el correcto ya que no hemos cometido los datos TESTDB >select * from hr.prueba_salario; SALARIO -----------------------1_USD Una de las preguntas que te has de estar haciendo en este momento, es como Oracle sabe que informacin arrojar, si en el datafile se encuentra el valor de 5_USD. Oracle logra esto a travs de un flujo que se llama Consistencia de Lectura (Read Consistency [RC]). Antes de continuar hay que conocer que es el SCN (System Change Number), este es el punto lgico en el tiempo en el que los cambios se hacen a la base de datos. El flujo de RC funciona con el SCN para garantizar el orden de las transacciones, cuando lanzaste el query en la sesin nueva, la base de datos determina el SCN registrado en el momento que el

query se empez a ejecutar. Este select requiere una versin de los bloques de datos que sean consistentes con los cambios que nicamente se encuentran cometidos. Oracle copia los bloques que se encuentran en los bloques actuales a un buffer de datos nuevo y le aplica datos de undo para reconstruir las versiones anteriores de los bloques de datos. A estas copias se le conocen como clones de consistencia de lectura(Consistency Read Clones). Para saber si la transaccion esta cometida o no, Oracle utiliza una tabla de transacciones llamada lista de transacciones de interes (Interested Transaction List [ITL]), esta lista se encuentra en la cabecera del bloque. Para terminar y regresar al punto, si sabemos que el DBWn es un proceso flojo, y que aunque haga un commit de mis datos, estos pueden que no se encuentren en los datafiles. De dnde toma Oracle la informacin para esto si se me llegara a caer la base de datos antes de que el CKPT mandara a llamar al DBWn? La respuesta esta en el Online Redo Log y cuando encuentra el marcador de commit, es crtico para la consistencia de nuestros datos. 4.2 Definicin de los modos de operacin de un DBMS. (alta, baja, recovery) Propsito de Backup y Recuperacin Como administrador de copia de seguridad, la tarea principal es disear, implementar y gestionar una estrategia de backup y recuperacin. En general, el propsito de una estrategia de recuperacin de copia de seguridad y es para proteger la base de datos contra la prdida de datos y reconstruir la base de datos despus de la prdida de datos. Normalmente, las tareas de administracin de seguridad son las siguientes: Planificacin y probar las respuestas a diferentes tipos de fallas Configuracin del entorno de base de datos de copia de seguridad y recuperacin La creacin de un programa de copia de seguridad Seguimiento de la copia de seguridad y entorno de recuperacin Solucin de problemas de copia de seguridad Para recuperarse de la prdida de datos en caso de necesidad. Como administrador de copia de seguridad, es posible que se le pida que realice otros deberes que se relacionan con copia de seguridad y recuperacin: La preservacin de datos, lo que implica la creacin de una copia de base de datos para el almacenamiento a largo plazo La transferencia de datos, lo que implica el movimiento de datos de una base de datos o un host a otro. El propsito de este manual es explicar cmo realizar las tareas anteriores.

De Proteccin de Datos Como administrador de copia de seguridad, su trabajo principal es hacer copias de seguridad y vigilancia para la proteccin de datos. Una copia de seguridad es una copia de los datos de una base de datos que se puede utilizar para reconstruir los datos. Una copia de seguridad puede ser una copia de seguridad fsica o una copia de seguridad lgica. Copias de seguridad fsicas son copias de los archivos fsicos utilizados en el almacenamiento y la recuperacin de una base de datos. Estos archivos incluyen archivos de datos, archivos de control y los registros de rehacer archivados. En ltima instancia, cada copia de seguridad fsica es una copia de los archivos que almacenan informacin de base de datos a otra ubicacin, ya sea en un disco o en medios de almacenamiento fuera de lnea, tales como cinta. Copias de seguridad lgicas contienen datos lgicos, como tablas y procedimientos almacenados. Puede utilizar Oracle Data Pump para exportar los datos a archivos lgicos binarios, que posteriormente puede importar a la base de datos. Clientes de lnea de comandos La bomba datos expdp y impdp utilizan el DBMS_DATAPUMP y DBMS_METADATA PL / SQL paquetes. Copias de seguridad fsicas son la base de cualquier estrategia de recuperacin de copia de seguridad slida y. Copias de seguridad lgicas son un complemento til de las copias de seguridad fsicas en muchas circunstancias, pero no son suficiente proteccin contra la prdida de datos y sin respaldos fsicos A menos que se especifique lo contrario, la copia de seguridad trmino tal como se utiliza en la copia de seguridad y la documentacin de recuperacin se refiere a una copia de seguridad fsica. Copia de seguridad de una base de datos es el acto de hacer una copia de seguridad fsica. El enfoque en la copia de seguridad y recuperacin de documentacin est casi exclusivamente en copias de seguridad fsicas. Mientras que varios problemas pueden detener el funcionamiento normal de una base de datos Oracle o afectar a las operaciones de base de datos de E / S, solamente la siguiente normalmente requiere la intervencin del DBA y de recuperacin de datos: un error de medios, errores de usuario, y los errores de aplicacin. Otros fallos pueden requerir intervencin DBA sin causar la prdida de datos o que requieren la recuperacin de copia de seguridad. Por ejemplo, es posible que tenga que reiniciar la base de datos tras un fallo de instancia o asignar ms espacio de disco despus de un fallo debido a la declaracin de un archivo de datos completo. Las fallas de medios. La falta de medios es un problema fsico con un disco que provoca un fallo de una leer o escribir en un archivo de disco que se requiere para ejecutar la base de datos. Cualquier archivo de base de datos puede ser vulnerable a un fallo de comunicacin. La tcnica de recuperacin adecuada despus de un fallo de los medios de comunicacin depende de los archivos afectados y el tipo de copias de seguridad disponibles. Un aspecto particularmente importante de la copia de seguridad y recuperacin se est desarrollando una estrategia de recuperacin ante desastres para proteger contra la prdida de

datos catastrfica, por ejemplo, la prdida de toda una serie de bases de datos. Errores de los usuarios Los errores del usuario cuando se producen, ya sea debido a un error en la lgica de la aplicacin o un error manual, los datos en una base de datos se modifican o eliminan incorrectamente. Errores de usuario se estima que la mayor causa de inactividad de base de datos. La prdida de datos debido a un error del usuario puede ser localizada o generalizada. Un ejemplo de dao localizado est eliminando a la persona equivocada en la tabla empleados. Este tipo de lesiones requiere la deteccin y la reparacin quirrgica. Un ejemplo de un dao generalizado es un trabajo por lotes que borra las rdenes de la empresa para el mes en curso. En este caso, se requiere una accin drstica para evitar una extensa base de datos de tiempo de inactividad. Mientras que la formacin de usuarios y el manejo cuidadoso de los privilegios pueden prevenir la mayora de los errores de usuario, su estrategia de copia de seguridad determina la gracia de recuperar los datos perdidos cuando un error del usuario que hace perder los datos. Errores de aplicacin A veces, un mal funcionamiento de software puede daar los bloques de datos. En una corrupcin fsica, que tambin se conoce como la corrupcin los medios de comunicacin, la base de datos no reconoce el bloque en absoluto: la suma de comprobacin no es vlida, el bloque contiene todos los ceros, o el encabezado y el pie de pgina del bloque no coinciden. Si el dao no es muy amplio, puede a menudo repara fcilmente con bloque de recuperacin de medios. Preservacin de Datos Conservacin de datos se relaciona con la proteccin de datos, pero tiene un propsito diferente. Por ejemplo, puede que tenga que conservar una copia de una base de datos tal como exista al final de la cuarta parte del negocio. Esta copia de seguridad no es parte de la estrategia de recuperacin de desastres. Los medios a los que estas copias de seguridad se escriben a menudo disponible despus de la copia de seguridad. Usted puede enviar la cinta en almacenamiento incendio o enviar un disco duro porttil a un centro de pruebas. RMAN proporciona una manera conveniente para crear una copia de seguridad y eximirla de su poltica de retencin de copia de seguridad. Este tipo de copia de seguridad se conoce como una copia de seguridad de archivo. Transferencia de datos En algunas situaciones, es posible que tenga que tomar una copia de seguridad de una base de datos o base de datos de componentes y moverlo a otra ubicacin. Por ejemplo, puede utilizar el Administrador de recuperacin (RMAN) para crear una copia de base de datos, cree una copia de tabla que se puede importar en otra base de datos, o mover una base de datos completa de una plataforma a otra. Estas tareas no son, estrictamente hablando, parte de una estrategia de backup y recuperacin, pero requieren el uso de copias de seguridad de bases de datos, por lo que pueden incluirse en las tareas de un administrador de copia de seguridad.

Oracle Backup y recuperacin Soluciones Al implementar una estrategia de backup y recuperacin, dispone de las siguientes soluciones disponibles: Administrador de recuperacin (RMAN) Recovery Manager est completamente integrado con la base de datos Oracle para llevar a cabo una serie de actividades de copia de seguridad y recuperacin, incluyendo el mantenimiento de un repositorio de RMAN de datos histricos acerca de las copias de seguridad. Se puede acceder a RMAN travs de la lnea de comandos oa travs de Oracle Enterprise Manager. Copia de seguridad y recuperacin gestionadas por el usuario En esta solucin, realizar copias de seguridad y recuperacin con una mezcla de comandos del sistema operativo host y SQL * Plus recuperacin commands.You son responsables de determinar todos los aspectos de cundo y cmo las copias de seguridad y la recuperacin se hacen. Estas soluciones estn respaldadas por Oracle y se documentan, pero RMAN es la mejor solucin para copia de seguridad y recuperacin de bases de datos. RMAN proporciona una interfaz comn para las tareas de copia de seguridad a travs de diferentes sistemas operativos host, y ofrece varias tcnicas de copia de seguridad que no estn disponibles a travs de mtodos administrados por usuarios. La mayor parte de este manual se centra en la copia de seguridad y recuperacin de RMAN basado. Tcnicas de copia de seguridad y recuperacin gestionadas por el usuario se tratan en Realizacin de usuario-Managed Backup and Recovery. Las ms destacables son los siguientes: Copias de seguridad incrementales Una copia de seguridad incremental almacena slo los bloques modificados desde la ltima copia de seguridad. Por lo tanto, proporcionan copias de seguridad ms compacto y una recuperacin ms rpida, lo que reduce la necesidad de aplicar de rehacer en archivo de datos de recuperacin de los medios de comunicacin. Si se habilita el seguimiento de cambios de bloque, entonces usted puede mejorar el rendimiento al evitar escaneos completos de todos los archivos de datos de entrada. Utilice el comando Copia de seguridad incremental para realizar copias de seguridad incrementales. Bloquear los medios de recuperacin Usted puede reparar un archivo de datos con slo un pequeo nmero de bloques de datos corruptos sin tomarlo fuera de lnea o la restauracin desde copia de seguridad. Utilice el comando BLOQUE RECOVER para realizar la recuperacin del bloque de comunicacin. Compresin binaria Un mecanismo de compresin binaria integrado en base de datos Oracle reduce el tamao de las copias de seguridad. Copias de seguridad encriptadas

RMAN utiliza las capacidades de cifrado de copia de seguridad integrados en bases de datos Oracle para almacenar conjuntos de copia de seguridad en un formato codificado. Para crear copias de seguridad cifradas en el disco, la base de datos debe utilizar la opcin de seguridad avanzada. Para crear copias de seguridad encriptadas directamente en cinta, RMAN debe utilizar la copia de seguridad de Oracle Secure interfaz SBT, pero no requiere la opcin de seguridad avanzada. Duplicacin de la base de datos automatizada Crea fcilmente una copia de su base de datos, el apoyo a diversas configuraciones de almacenamiento, incluida la duplicacin directa entre las bases de datos de ASM. Conversin de datos entre plataformas Ya sea que utilice RMAN o mtodos administrados por usuarios, puede complementar las copias de seguridad fsicas con copias de seguridad lgicas de objetos de esquema realizados con la utilidad Export Data Pump. Ms tarde, puede utilizar Data Pump Import para volver a crear los datos despus de la restauracin y la recuperacin. Copias de seguridad lgicas son en su mayora ms all del alcance de la copia de seguridad y de recuperacin de documentacin. 4.3 Comandos de activacion de los modos de operacin 4.4. Manejo de ndices Resumen ndices Un ndice es una estructura opcional, asociado con una mesa o tabla de clster, que a veces puede acelerar el acceso de datos. Mediante la creacin de un ndice en una o varias columnas de una tabla, se obtiene la capacidad en algunos casos, para recuperar un pequeo 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 montn 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 ubicacin 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 volmenes. Por analoga, supongamos que un gerente de Recursos Humanos tiene un estante de cajas de cartn. Las carpetas que contienen informacin 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 ubicacin 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 podra crear ndices separados para los ltimos nombres de los empleados, los ID de departamento, y as sucesivamente. En general, considerar la creacin de un ndice en una columna en cualquiera de las siguientes situaciones: Las columnas indizadas se consultan con frecuencia y devuelven un pequeo porcentaje del nmero total de filas en la tabla. Existe una restriccin 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 requerira si se actualiza la clave principal de la tabla principal, se funden en la tabla principal, o eliminar de la tabla primaria. Una restriccin de clave nica se coloca sobre la mesa y desea especificar manualmente el ndice de todas las opciones sobre ndices y. Caractersticas de indexacin Los ndices son objetos de esquema que son lgica y fsicamente independiente de los datos de los objetos con los que estn asociados. Por lo tanto, un ndice se puede quitar o creado sin afectar fsicamente 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 ms 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 rpido a una sola fila de datos. Slo afecta a la velocidad de ejecucin. Dado un valor de datos que se ha indexado, el ndice apunta directamente a la ubicacin de las filas que contienen ese valor. La base de datos mantiene automticamente y utiliza los ndices despus de su creacin. La base de datos tambin refleja automticamente 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 recuperacin 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 tambin 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. Cmo hacer una invisible ndice es una alternativa a lo que es inutilizable o se caiga. ndices invisibles son especialmente tiles para probar la eliminacin de un ndice antes de dejarlo caer o mediante ndices temporalmente sin afectar a la aplicacin general. Gua del administrador de aprender a manejar los ndices Base de datos Oracle Performance Tuning Guide para aprender cmo 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 trminos 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 lgico. 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 declaracin anterior, la columna customer_id es la clave de ndice. El ndice en s se llama ord_customer_ix. ndices Compuestos Un ndice compuesto, tambin 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 ms sentido para las consultas que recuperar datos y no necesita ser adyacente en la tabla. Los ndices compuestos pueden acelerar la recuperacin de datos para las instrucciones SELECT en la que el DONDE referencias clusula totalidad o la parte principal de las columnas en el ndice compuesto. Por lo tanto, el orden de las columnas utilizadas en la definicin es importante. En general, las columnas de acceso ms comn van primero. Por ejemplo, supongamos que una aplicacin realiza consultas frecuentes al apellidos, job_id, y columnas de salario en la tabla empleados. Tambin asumir que last_name tiene alta cardinalidad, lo que significa que el nmero de valores distintos que es grande en comparacin con el nmero 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, slo la columna last_name, o slo 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 bsqueda selectiva de este ndice Mltiples ndices pueden existir para la misma mesa, siempre y cuando la permutacin 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 vlidas: 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 slo 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 excepcin de los ndices de mapa de bits o cuando el valor de la columna clave de clster es nulo. Tipos de ndices Base de Datos Oracle ofrece varias combinaciones de indexacin, 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 estndar. 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 montn-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 inversin 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 clster tabla. En lugar de apuntar a una fila, los puntos clave para el bloque que contiene filas relacionadas con la clave de clster. Consulte "Descripcin 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 combinacin de mapa de bits es un ndice de mapa de bits para la unin de dos o ms 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 funcin, tales como la funcin UPPER, o incluidos en una expresin. ndices B-tree o mapa de bits puede ser basado en las funciones. Consulte "Indicadores basados en funciones". ndices de dominio de aplicacin Este tipo de ndice se crea por un usuario para los datos en un dominio especfico de la aplicacin. El ndice fsica 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 aplicacin". Vea tambin: 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 ms comn de ndice de base de datos. Un ndice B-tree es una lista ordenada de valores dividida en rangos. Mediante la asociacin de una tecla con una fila o rango de filas, los rboles B proporcionan un excelente rendimiento de la recuperacin para una amplia gama de consultas, incluyendo coincidencia exacta y bsquedas 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 bsqueda 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 raz 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 automtica a la misma profundidad. Por lo tanto, la recuperacin de cualquier documento desde cualquier lugar del ndice toma aproximadamente la misma cantidad de tiempo. La altura del ndice es el nmero de bloque requerido para pasar de el bloque de raz 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 mnimo necesario para tomar una decisin de ramificacin entre dos teclas. Esta tcnica permite que la base de datos para adaptarse a la mayor cantidad de informacin posible sobre cada bloque de rama. Los bloqueos de rama contienen un puntero al bloque de nio que contiene la clave. El nmero de teclas y punteros est limitado por el tamao 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 tambin estn doblemente enlazadas. En la Figura 3-1 el bloque de hoja ms a la izquierda (0-10) est ligada a la segunda hoja bloque (11-19). Nota: Los ndices en columnas con datos de tipo carcter 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 bsico detrs de los ndices de base de datos Oracle. Si una instruccin SQL slo tiene acceso a columnas indexadas, a continuacin, lee los valores de la base de datos directamente desde el ndice en lugar de a partir de la tabla. Si la declaracin accede columnas, adems de las columnas indizadas, a continuacin, la base de datos utiliza ROWIDs para encontrar las filas de la tabla. Tpicamente, 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 tambin: Oracle Database Performance Tuning Guide para obtener informacin detallada sobre las exploraciones de ndices ndice Anlisis Completo En un recorrido de ndice completo, la base de datos lee el ndice completo en orden. Una exploracin de ndice completo est disponible si una columna en el ndice, y en algunas circunstancias, cuando no se especifica un predicado de un predicado (clusula WHERE) en las referencias de sentencia de SQL. Un anlisis completo puede eliminar la clasificacin ya que los datos aparecen ordenados por clave de ndice.

Supongamos que una aplicacin se ejecuta la siguiente consulta: SELECT department_id, last_name, salary FROM employees WHERE salary > 5000 ORDER BY department_id, last_name; Tambin 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 ms pequeas que la tabla empleados, que contiene ms columnas que las que se incluyen en la consulta, y evita la clasificacin de los datos. Por ejemplo, el anlisis 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 . . . Espaol Ingls Portugus Fast ndice Anlisis Completo Un anlisis rpido ndice completo es un anlisis completo ndice en el que la base de datos lee los bloques de ndice en ningn 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 rpidos 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 restriccin NOT NULL. Por ejemplo, una aplicacin emite la siguiente consulta, que no incluye una clusula ORDER BY: SELECT last_name, salary FROM employees; Si el apellido y el salario son una clave compuesta en un ndice, a continuacin, un anlisis rpido ndice completo puede leer las entradas de ndice para obtener la informacin solicitada :: Baida,2900,rowid Zlotkey,10500,rowid Austin,7200,rowid Baer,10000,rowid Atkinson,2800,rowid

Austin,4800,rowid . . . ndice de escaneado Una exploracin rango de ndices es una exploracin ordenada de un ndice que tiene las siguientes caractersticas: Una o ms columnas principales de un ndice que se especifican en las condiciones. Una condicin especifica una combinacin de una o ms expresiones y operadores lgicos (Boolean) y devuelve un valor de TRUE, FALSE o UNKNOWN. 0, 1, o ms valores son posibles para una clave de ndice. La base de datos utiliza habitualmente un anlisis 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 pequeo 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 combinacin 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 podra usar una exploracin de distancia debido a la columna de la apellidos se especifica en el predicado y mltiplos 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 exploracin 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 ms de 40. Para analizar el ndice, la base de datos se mueve hacia atrs o hacia adelante a travs de los bloques de la hoja. Por ejemplo, una exploracin para los ID de entre 10 y 40 localiza el primer bloque de hoja de ndice que contiene el valor de clave ms bajo que es de 10 o mayor. La exploracin contina entonces horizontalmente a travs 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 exploracin de distancia, un nico ndice de exploracin debe tener ya sea 0 o 1 rowID asociado con una clave de ndice. La base de datos realiza una exploracin nica cuando un predicado todas las referencias de las columnas de una clave de ndice UNIQUE usar un operador de igualdad. Una exploracin 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 exploracin para localizar el ROWID para el empleado cuyo identificador es 5. ndice Skip Scan Un ndice skip anlisis utiliza subndices lgicas de un ndice compuesto. La base de datos "salta" a travs 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 Exploracin con salto cuando la columna de direccin 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 bsqueda selectiva de este ndice cust_gender a pesar de que no se especifica en la clusula WHERE. En una exploracin de salto, el nmero de subndices lgicas se determina por el nmero 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 lgicamente el ndice en un subndice con la tecla F y un segundo subndice con la tecla M. Cuando se busca el registro para el cliente cuyo correo electrnico es Abbey@company.com, la base de datos busca en el subndice con el valor F y luego busca en el subndice 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 fsicamente 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 estndar, a continuacin, un ndice de clave inversa almacena los bytes como 15, C1. La inversin de la llave soluciona el problema de la contencin 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 clster agrega fin 20, mientras que otro 21 aade, 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 revocacin de la orden de bytes distribuye inserta a travs de todas las claves de la hoja en el ndice. Por ejemplo, las llaves, como 20 y 21, que habra sido enunciada en un ndice de clave estndar estn almacenados lejos en bloques separados. Por lo tanto, E / S para las inserciones de claves secuenciales se distribuye ms uniformemente. Debido a que los datos en el ndice no est ordenado por clave columna cuando se almacena, la disposicin de las teclas inversa elimina la capacidad de ejecutar una serie de consulta de exploracin de ndice en algunos casos. Por ejemplo, si un usuario emite una consulta para los ID

de orden superior a 20, a continuacin, la base de datos no puede comenzar con el bloque que contiene este ID y proceder horizontalmente a travs 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 numricos de menor a mayor nmero, 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 continuacin, la hoja de bloqueo que contena 250 sera en el lado izquierdo del rbol y el bloque con 0 a la derecha. La bsqueda por defecto a travs 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. Compresin clave Oracle Database puede utilizar la compresin 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 compresin puede reducir en gran medida el espacio consumido por el ndice. En general, las claves de ndice tienen dos piezas, una pieza agrupacin y una pieza nica. Clave de compresin rompe la clave de ndice en una entrada de prefijo, que es la pieza agrupacin, y una entrada de sufijo, que es la pieza nica o casi nica. La base de datos alcanza la compresin 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 aadiendo un ROWID a la pieza de agrupacin 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 consistira en una concatenacin de los valores order_mode y ORDER_STATUS. Si este ndice se cre con la compresin de claves predeterminado y luego duplicar prefijos clave como la lnea, 0 y en lnea, 2 podra ser comprimido. Conceptualmente, la base de datos alcanza la compresin como se muestra en el ejemplo siguiente:online,0 AAAPvCAAFAAAAFaAAa AAAPvCAAFAAAAFaAAg AAAPvCAAFAAAAFaAAl online,2 AAAPvCAAFAAAAFaAAm online,3 AAAPvCAAFAAAAFaAAq AAAPvCAAFAAAAFaAAt Entradas de sufijos forman la versin 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 sera order_mode y el sufijo sera ORDER_STATUS, ROWID. Para los valores del Ejemplo 3-2, el ndice podra factorizar apariciones duplicadas de lnea 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 estn diseados 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 nmero de valores distintos que es pequeo en comparacin con el nmero de filas de la tabla. La tabla de indexado es ya sea de slo lectura o no sujetos a modificacin significativa de las sentencias DML. Para ver un ejemplo de almacenamiento de datos, la tabla tiene una columna sh.customer cust_gender con slo dos valores posibles: M y F. Supongamos que las consultas para el nmero de clientes de un gnero en particular, son comunes. En este caso, la columna de la customer.cust_gender sera 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 funcin de mapeo convierte la posicin 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 representacin interna diferente. Si la columna indexada en una sola fila se actualiza, a continuacin, 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 razn, 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 representacin ms eficiente y recuperacin. 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 gnero. Table 3-1 Ejemplo de Bitmap Value M F Row 1 1 0 Row 2 0 1 Row 3 1 0 Row 4 1 0 Row 5 1 0 Row 6 0 1 Row 7 0 1

Una funcin 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 indexacin puede ser til para algunas sentencias SQL, como las consultas con el nmero de funcin de agregado. Un analista de la investigacin de las tendencias demogrficas de los clientes puede preguntar, "Cuntos 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 nmero 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 Tabla 3-2 Mapa de bits ejemplo Value M F single divorced single or divorced, and F Row 1 1 0 0 0 0

acceder

la

tabla.

Row 2 0 1 0 0 0

Row 3 1 0 0 0 0

Row 4 1 0 0 0 0

Row 5 1 0 0 0 0

Row 6 0 1 1 0 1

Row 7 0 1 1 0 1

Indexacin Bitmap combina eficientemente los ndices que corresponden a una serie de condiciones en una clusula WHERE. Las filas que satisfacer algunas, pero no todas, las condiciones se filtran antes de la propia tabla se accede. Esta tcnica mejora el tiempo de respuesta, a menudo de forma espectacular. Bitmap nete ndices Un ndice de combinacin de mapa de bits es un ndice de mapa de bits para la unin de dos o ms 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 estndar 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 realizacin de las restricciones de antemano. Para un ejemplo de cuando un bitmap unirse ndice sera til, suponen que los usuarios a menudo consultan el nmero de empleados con un tipo de trabajo en particular. Una consulta tpica podra ser como sigue: SELECT COUNT(*) FROM employees, jobs WHERE employees.job_id = jobs.job_id AND jobs.job_title = 'Accountant'; El consulta anterior sera tpicamente utilice un ndice en jobs.job_title para recuperar las filas para Accountant y entonces el Identificacin 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 podra 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

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 nmero 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 informacin 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 almacn de datos, la condicin de unin es una unin 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 ms eficiente en el almacenamiento de materializada unen puntos de vista, una alternativa para materializar une con antelacin. Vea tambin: Oracle Database Data Warehousing Guide para obtener ms informacin 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 envo, Stock Clerk, y varios otros. Una entrada de ndice de mapa de bits para este ndice tiene los siguientes componentes: El ttulo del trabajo como la clave del ndice Un ROWID ROWID bajo y alto para una variedad de ROWIDs Un mapa de bits para ROWIDs especficos en el rango Conceptualmente, un bloque de la hoja de ndice en este ndice podra 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 ttulo del trabajo aparece en varias entradas debido a la gama ROWID difiere. Supongamos que actualiza una sesin de trabajo de la identificacin de un empleado del vendedor de envo de Stock Clerk. En este caso, la sesin requiere acceso exclusivo a la entrada de clave de ndice para el valor antiguo (vendedor de envo) 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 actualizacin 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 ms 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 ms columnas de la tabla est indexada. Un ndice basado en funciones calcula el valor de una funcin o expresin 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 funcin que se utiliza para construir el ndice puede ser una expresin aritmtica o una expresin que contiene una funcin de SQL, la funcin PL / SQL definida por el usuario, la funcin del envase o C reclamo. Por ejemplo, una funcin podra aadir 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 clusulas WHERE. La base de datos slo se utiliza el ndice basado en funciones cuando la funcin est incluida en una consulta. Cuando los procesos de base de datos INSERT y UPDATE, sin embargo, todava debe evaluar la funcin 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 expresin aritmtica 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 bsqueda entre maysculas y minsculas. Por ejemplo, supongamos que la columna 'nombre de empleados contiene caracteres en maysculas y minsculas. 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 tambin es til para indizar slo las filas especficas 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 slo las filas A, podra escribir una funcin 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 ); Optimizacin con ndices basados en funciones El optimizador puede utilizar un rango de exploracin de ndice en un ndice basado en las funciones para las consultas con expresiones en la clusula WHERE. La ruta de acceso de exploracin de distancia es especialmente beneficioso cuando el predicado (clusula WHERE) tiene una baja selectividad. En el Ejemplo 3-5 el optimizador puede utilizar un rango de exploracin de ndice, si el ndice se basa en la expresin 12 * Sueldo * COMMISSION_PCT. Una columna virtual es til para acelerar el acceso a los datos derivados de las expresiones. Por ejemplo, se podra 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 expresin mediante el anlisis de la expresin en una sentencia SQL y luego comparar los rboles de expresin de la declaracin y el ndice basado en funciones. Esta comparacin entre maysculas y minsculas e ignora espacios en blanco. ndices dominio de la aplicacin. Un ndice dominio de aplicacin es un ndice personalizado especfico para una aplicacin. Oracle Database proporciona indizacin extensible para hacer lo siguiente: Acomodar los ndices de medida, los tipos de datos complejos, tales como documentos, datos espaciales, imgenes y clips de vdeo (ver "Datos no estructurados") Hacer uso de las tcnicas de indexacin especializadas. Puede encapsular las rutinas de administracin de ndices especficos de la aplicacin como un objeto de esquema INDEXTYPE y definir un ndice de dominio en columnas de tablas o atributos de un tipo de objeto. Indexacin extensible puede procesar de manera eficiente los operadores especficos de la aplicacin. El software de aplicacin, llamado el cartucho, controla la estructura y el contenido de un ndice de dominio. La base de datos interacta con la aplicacin 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 tamao 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 omisin del propietario o de un espacio de tablas denominado especficamente en la sentencia CREATE INDEX. Para facilitar la administracin 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 slo los ndices, que pueden ser reconstruidas, y as reducir el tiempo y el almacenamiento requerido para copias de seguridad. Visin general de las tablas de ndice organizadas Una tabla de ndice-organizada es una tabla almacenada en una variacin de un ndice de estructura de rbol-B. En una tabla de montn 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 tambin 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 montn organizados, mediante sentencias SQL. Para una analoga de una tabla organizada por ndices, supongamos que un gerente de recursos humanos tiene una estantera con cajas de cartn. Cada cuadro est marcado con un nmero 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 ubicacin 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 nmero de empleado. Empleado Rey tiene ID 100, que es el identificador ms 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 analoga, 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 recuperacin 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 ms rpido a filas de la tabla de clave principal o un prefijo vlido 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. Tambin, porque las filas se almacenan en orden, el acceso principal gama de teclas de la clave principal o prefijo implica bloque mnimo de I / Os. Otro de los beneficios es la evitacin 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 fsicamente en un orden especfico. Este tipo de tabla se utiliza a menudo para la recuperacin de informacin, espacial (consulte el apartado "Visin general de Oracle Spatial"), y las aplicaciones OLAP (vase "OLAP"). Caractersticas de las tablas de ndice organizadas El sistema de base de datos realiza todas las operaciones en las tablas de ndice organizadas por la manipulacin de la estructura del ndice B-tree. La Tabla 3-3 resume las diferencias entre las tablas de ndice organizadas y mesas montn organizados. Tabla 3-3 Comparacin 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 localizacin de la identificacin de 1800. Figura 3-3 Cuadro de ndice Organizada

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 exploracin 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 montn organizada en una tabla organizada por ndices, supongamos que el bloque 1 de un segmento de la tabla departamentos montn 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 montn 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 exploracin 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 nmero de bloque de E / S en este ejemplo es el doble del nmero 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 pequeas, ya que consisten en la llave y ROWID. Si se especifica un rea de desbordamiento de fila, a continuacin, 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 fsico 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 lgicas para las tablas de ndice organizadas. Un ROWID lgico es una representacin codificada en base 64 de la clave primaria de tabla. La longitud ROWID lgico 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 montn organizados hacen (vase "Las filas encadenadas y migradas"). Dado que las filas de las tablas de ndice organizadas no tienen direcciones fsicas permanentes, la base de datos utiliza ROWIDs lgicas 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 poblacin: 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 podra tener entradas de ndice de la siguiente manera, donde el valor despus de la coma es el ROWID lgico: 1700,*BAFAJqoCwR/+ 1700,*BAFAJqoCwQv+ 1800,*BAFAJqoCwRX+ 2400,*BAFAJqoCwSn+ Los ndices secundarios proporcionan acceso rpido 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 podran usar el ndice secundario para acelerar el acceso de datos. ROWIDs conjeturas lgicas y fsicas Los ndices secundarios utilizan las ROWIDs lgicas para localizar filas de la tabla. Un ROWID lgico incluye una conjetura fsica, que es el ROWID fsica de la entrada de ndice cuando se hizo por primera vez. Oracle Database puede utilizar las sugerencias fsicas para investigar directamente en el bloque de la hoja de la tabla organizada por ndices, sin pasar por la bsqueda de la clave principal. Cuando la ubicacin fsica de una fila cambia, el ROWID lgica sigue siendo vlido incluso si contiene una conjetura fsica que es rancio. Para una tabla de montn organizado, el acceso de un ndice secundario consiste en un anlisis 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 vara, dependiendo del uso y la exactitud de conjeturas fsicas: Sin conjeturas fsicas, el acceso implica dos exploraciones de ndices: un anlisis del ndice secundario seguido de un anlisis del ndice de clave primaria. Con conjeturas fsicas, el acceso depende de la precisin: o Con conjeturas fsicas precisas, acceso implica una exploracin de ndice secundario y un adicional de I / O para ir a buscar el bloque de datos que contiene la fila. o Con conjeturas fsicas imprecisas, acceso implica una exploracin de ndice secundario y un I / O para ir a buscar el bloque de datos incorrecto (segn lo indicado por la conjetura), seguida de una exploracin 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 asignacin de almacenamiento dinmico organizado. La tabla de asignacin almacena los ROWIDs lgicas de la tabla organizada por ndices. Cada fila de la tabla de asignacin almacena un ROWID lgico 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 bsqueda. Si la base de datos se encuentra la clave, a continuacin, la entrada de mapa de bits se convierte en un ROWID fsica. Con mesas montn organizados, la base de datos utiliza el ROWID fsica para acceder a la tabla base. Con las tablas de ndice-organizados, la base de datos utiliza el ROWID fsica para acceder a la tabla de asignacin, que a su vez produce un ROWID lgico 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. 4.4.2 Reorganizacion de ndices Un paquete puede usar la tarea Reorganizar ndice para reorganizar los ndices de una base de datos individual o de varias bases de datos. Si la tarea solo reorganiza los ndices de una base de datos individual, puede elegir las vistas o las tablas cuyos ndices reorganiza la tarea. La tarea Reorganizar ndice tambin incluye la opcin de compactar datos de objetos grandes. Los datos de objetos grandes son datos de tipo image, text, ntext, varchar(max), nvarchar(max), varbinary(max) o xml. La tarea Reorganizar ndice encapsula la instruccin ALTER INDEX de Transact-SQL. Si elige compactar datos de objetos grandes, la instruccin utiliza la clusula REORGANIZE WITH (LOB_COMPACTION = ON); en caso contrario, se establece LOB_COMPACTION en OFF Dentro de las tareas habituales de Mantenimiento de las Bases de Datos se encuentran aquellas destinadas al control y respaldo de las mismas como ser: Control de Integridad, Chequeo de Consistencia, Copias de Seguridad o Compactacin de las bases. Pero tambin es necesario ejecutar trabajos de mantenimiento cuyos objetivos sean el de mantener la performance de las bases de datos y evitar su degradacin. Esos trabajos son la Reorganizacin de ndices y la Actualizacin de Estadsticas. Estos trabajos son independientes del estado de la base de datos. Puede ocurrir que a la base le falten estudios de optimizacin pero, al menos, mantendremos la performance actual. Si la base se encuentra optimizada, entonces ms an, son necesarios para evitar la degradacin producto del uso continuo. Cualquiera de estos trabajos deben realizarse fuera de lnea por motivos de: alto consumo de recurso y bloqueo de las tablas en el momento de ejecucin. Las tablas que contienen ndices al ser actualizadas o por insercin de nuevos datos, generan fragmentacin de estos ndices. Estas fragmentaciones conllevan a la prdida de performance al acceder a ellas. La instruccin DBCC DBREINDEX reorganiza el ndice de una tabla o todos los ndices definidos para una tabla. La reorganizacin de realiza dinmicamente sin necesidad de conocer la estructura de la misma o las restricciones que ella tenga. Por lo tanto no es necesario conocer si una tabla tiene clave primaria o si esta clave es nica y adems pertenece a algn ndice, ya que la reorganizacin no necesita eliminar y recrear stas restricciones para realizar su trabajo. La sintaxis de esta instruccin es: DBCC DBREINDEX ( basededatos.dueo.nombre_de_tabla [ , ndice [ , fillfactor ] ] ) [ WITH NO_INFOMSGS ] Fillfactor es el porcentaje de espacio de pgina destinado a ser ocupado. El valor definido reemplaza al que fue generado en el momento de la creacin del ndice. Si se quiere mantener el valor original, entonces se utiliza el valor 0. WITH NO_INFOMSGS se suprimen los mensajes generados en la ejecucin.

No es necesario conocer los nombres de todos los ndices de todas las tablas, ya que si utilizamos la instruccin de la siguiente forma: DBCC RBINDEX (Movimientos, , 0) Se reorganizarn todos los ndices que contengan la tabla Movimientos, conservndose el fillfactor original de cada ndice en particular. Una de las formas de utilizarlo es, escribir un script con una sentencia DBCC RBINDEX por cada tabla que necesitemos reorganizar y agendarlas en forma peridica mediante un trabajo de mantenimiento dentro de algn horario disponible. Por lo tanto, la recomendacin ser: elegir las tablas ms accedidas y/o actualizadas, y reorganizarlas una vez entre semana. Para reorganizar todas las tablas que contengan ndices se utiliza el mismo concepto, pero dentro de un procedimiento que recorra todas la tablas de la base y las reorganice, sin necesidad que escribamos todas la tablas que contiene la base de datos. Estos procedimientos se pueden encontrar en el Forum bajo el nombre de Tips, y la idea es generar un trabajo de mantenimiento que se ejecute, por ejemplo, en el fin de semana 4.4.3 Reconstruccion de indices Es importante peridicamente examinar y determinar qu ndices son susceptibles de ser reconstruidos. Cuando un ndice est descompensado puede ser porque algunas partes de ste han sido accedidas con mayor frecuencia que otras. Como resultado de este suceso podemos obtener problemas de contencin de disco o cuellos de botella en el sistema. Normalmente reconstruimos un ndice con el comando ALTER INDEX. Es importante tener actualizadas las estadsticas de la base de datos. Para saber si las estadsticas se estn lanzando correctamente podemos hacer una consulta sobre la tabla dba_indexes y ver el campo last_analyzed para observar cuando se ejecutaron sobre ese ndice las estadsticas. SELECT index_name, FROM WHERE table_owner=nb_usuario last_analyzed dba_indexed

Nota: Siendo nb_usuario el nombre del esquema del usuario para el que queramos validar las estadsticas. (Lanzar con usuario SYS) Para actualizar las estadsticas utilizamos el paquete DBM_STATS. Podemos actualizar las estadsticas de todos los objetos de un esquema de la siguiente forma: Execute DBMS_STATS.gather_schema_stats(Esquema); Nota: Sustituimos esquema por el nombre de nuestro esquema a actualizar (lanzar con usuario SYS) Una vez actualizadas las estadsticas de los ndices de la base de datos lanzamos la siguiente consulta: SELECT DECODE(blevel,0,'OK index_name, BLEVEL',1,'OK blevel, BLEVEL',2,

'OK BLEVEL',3,'OK BLEVEL',4,'OK BLEVEL','BLEVEL FROM dba_indexes where table_owner='Propietario';

HIGH')

OK

Nota: Sustituimos Propietario por el esquema o propietario que queramos verificar (lanzar con usuario SYS) Con esta sentencia obtendremos el nombre del ndice, el blevel y si es correcto. INDEX_NAME BLEVEL OK INX_CUENTA 1 OK BLEVEL INX_TRABAJO 0 OK BLEVEL INX_DINERO BLEVEL HIGH Los ndices que deberamos de reconstruir son los que en la columna ok aparecen como BLEVEL HIGH. Blevel (branch level) es parte del formato del B-tree del ndice e indica el nmero de veces que ORACLE ha tenido que reducir la bsqueda en ese ndice. Si este valor est por encima de 4 el ndice deber de ser reconstruido. Comando ALTER INDEX Como hemos comentado esta sentencia se utiliza para cambiar o reconstruir un ndice existente en la base de datos. Para poder ejecutar este comando el ndice debe de estar en el propio esquema donde intentes ejecutarlo o deberas de tener el privilegio alter any index. Tambin tenemos que tener en cuenta que para realizar la reconstruccin de un ndice deberamos de tener cuota suficiente sobre el tablespace que lo lanzamos. Para reconstruir un ndice bastara con lazar la siguiente sentencia: ALTER INDEX <index_name> REBUILD; Para reconstruir una particin de un ndice podramos hacer lo siguiente ALTER INDEX <index_name> REBUILD PARTITION <nb_partition> NOLOGGING; Nota: En algunos casos cuando alguno de los ndices tiene algn tipo de corrupcin no es posible reconstruirlo. La solucin en este caso es borrar el ndice y recrearlo. http://www.itescam.edu.mx/principal/webalumnos/sylabus/asignatura.php?clave_asig=SCB1001&carrera=ISIC-2010-224&id_d=136