unidad4 admon

67
4 OPERACIÓN 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 Bitácoras de trabajo del DBMS En muchos DBMS la bitácora incluye todo tipo de consulta incluyendo aquellas que no modifican los datos. La operación ROLLBACK está basada en el uso de una bitácora. El DBMS (Sistema Manejador de Bases de Datos) mantiene una bitácora o diario en cinta o en disco, comúnmente, en el cual se registran los detalles de todas las operaciones de actualización, en particular, los valores iniciales y final del objeto modificado. Por tanto, si resulta necesario anular alguna modificación específica, el sistema puede utilizar la entrada correspondiente de la bitácora para restaurar el valor original del objeto restaurado. 4.1.1. Funciones especifica de las bitácoras La estructura más ampliamente usada para grabar las modificaciones de la base de datos es la Bitácora. Cada registro de la bitácora escribe una única escritura de base de datos y tiene lo siguiente: Nombre de la Transacción Valor antiguo Valor Nuevo Es fundamental que siempre se cree un registro en la bitácora cuando se realice una escritura antes de que se modifique la base de datos. También tenemos la posibilidad de deshacer una modificación que ya se ha escrito en la base de datos, esto se realizará usando el campo del valor antiguo de los registros de la bitácora. Los registros de la bitácora deben residir en memoria estable como resultado el volumen de datos en la bitácora puede ser exageradamente grande. Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de sincronización lo cual representa el límite entre dos transacciones consecutivas, o el final de una unidad lógica de trabajo, y por tanto al punto en el cual la base de datos esta (o debería estar) en un estado de consistencia. Las únicas operaciones

Upload: kary-jimenez

Post on 08-Feb-2016

429 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: UNIDAD4 ADMON

4 OPERACIÓN Y MANTENIBILIDAD

Trata acerca de como se hacen las bitacoras.Que funcion tienen y porque son tan importantes, ademas es necesario conocer porque son im-portante a la hora de realizar cambios o conocer un poco mas del sistema de base de datos que se esta manejando.

4.1 Bitácoras de trabajo del DBMS

En muchos DBMS la bitácora incluye todo tipo de consulta incluyendo aquellas que no mo-difican los datos.

La operación ROLLBACK está basada en el uso de una bitácora. El DBMS (Sistema Maneja-dor de Bases de Datos) mantiene una bitácora o diario en cinta o en disco, comúnmente, en el cual se registran los detalles de todas las operaciones de actualización, en particular, los valores iniciales y final del objeto modificado. Por tanto, si resulta necesario anular alguna modificación específica, el sistema puede utilizar la entrada correspondiente de la bitácora para restaurar el valor original del objeto restaurado.

4.1.1. Funciones especifica de las bitácorasLa estructura más ampliamente usada para grabar las modificaciones de la base de datos es la Bi-tácora. Cada registro de la bitácora escribe una única escritura de base de datos y tiene lo siguien-te:

Nombre de la Transacción Valor antiguo Valor Nuevo

Es fundamental que siempre se cree un registro en la bitácora cuando se realice una escritura an-tes de que se modifique la base de datos.También tenemos la posibilidad de deshacer una modificación que ya se ha escrito en la base de datos, esto se realizará usando el campo del valor antiguo de los registros de la bitácora.Los registros de la bitácora deben residir en memoria estable como resultado el volumen de da-tos en la bitácora puede ser exageradamente grande.Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de sincroniza-ción lo cual representa el límite entre dos transacciones consecutivas, o el final de una unidad ló-gica de trabajo, y por tanto al punto en el cual la base de datos esta (o debería estar) en un estado de consistencia. Las únicas operaciones que establecen un punto de sincronización son COMMIT, ROLLBACK y el inicio de un programa. Cuando se establece un punto de sincronización:Se comprometen o anulan todas las modificaciones realizadas por el programa desde el punto de sincronización anterior.Se pierde todo posible posicionamiento en la base de datos. Se liberan todos los registros blo-queados. Es importante advertir que COMMIT y ROLLBACK terminan las transacción, no el pro-grama.

Page 2: UNIDAD4 ADMON

4.1 Bitácoras de trabajo del DBMS. 4.1.1. Funciones específica de las bitácoras.

¿Qué es el Redo Log?

La estructura más importante para las operaciones de recuperación es el registro de rehacer, que consiste en dos o más 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, también llamado una entrada de rehacer, se compone de un grupo de vectores de cambio, cada uno de los cuales es una descripción 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 también 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 búfer del registro de rehacer de la SGA (ver "Cómo 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 transacción, 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 número de cambio de sistema (SCN) para identificar los registros de rehacer para cada transacción confirmada. Sólo cuando todos los registros de rehacer asociados a una transacción determinada son con seguridad en el disco en los registros en línea es el proceso de usuario notificado de que la transacción haya sido cometido.

Registros Redo también se pueden escribir en un archivo de registro de rehacer antes de que se confirme la transacción correspondiente. Si el buffer de redo log se llena, u otra transacción 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 podrán ser comprometidos. Si es necesario, la base de datos se puede revertir estos cambios.

Cómo Oracle Database escribe a los Redo Log

El registro de rehacer de una base de datos consiste en dos o más archivos de registro de rehacer. La base de datos requiere un mínimo 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 "Administración de registros de rehacer archivados" para obtener más información.

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

Page 3: UNIDAD4 ADMON

ilustra la escritura circular del archivo de registro de rehacer. Los números al lado de cada línea indican el orden en que LGWR escribe a cada archivo de registro de rehacer.Los archivos de registro de rehacer rellenos están disponibles para LGWR para su reutilización en función 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 después 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 después de los cambios registrados en él se han escrito en los archivos de datos y el archivo se ha archivado.

Figura 12-1 Reutilización de los archivos de registro de rehacer por LGWR

Descripción del "Figura 12-1 Reutilización de los archivos de registro de rehacer por LGWR"

Archivos Redo Log activo (actual) e inactiva

Base de datos Oracle utiliza sólo uno los archivos de registro de rehacer a la vez para almacenar los registros de rehacer escritos del búfer 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 recuperación de la instancia se denominan archivos de registro de rehacer activos. Rehacer los archivos de registro que ya no son necesarios para la recuperación de la instancia se denominan archivos de registro de rehacer inactivos.

Page 4: UNIDAD4 ADMON

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 línea 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 continuación, 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 Números 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. También puede forzar interruptores de registro de forma manual.

Oracle Database asigna a cada registro de rehacer presentar un nuevo número 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 número de secuencia de registro. Un archivo de registro de rehacer que se encendía de nuevo para su uso se le da el siguiente número de secuencia de registro disponibles.Cada archivo de registro de rehacer en línea o archivados se identifica por su número de secuencia de registro. Durante el accidente, instancia o la recuperación de medios, la base de datos se aplica correctamente los archivos de registro de rehacer en orden ascendente utilizando el número de secuencia de registro de los archivos de registro archivados y rehacer necesarias.

Planificación de la Redo Log

Esta sección 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 Multiplexación

• La colocación de Ingreso de Miembros Rehacer en diferentes discos

• Planificar el tamaño de los archivos de registro de rehacer

• Planificar el tamaño del bloque de los archivos de registro de rehacer

• Selección del número de archivos de registro Redo

• Control Lag Archivo

Archivos Redo Log Multiplexación

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 más copias idénticas de la redo log se pueden mantener de forma automática en lugares separados. Para obtener el mayor beneficio, estos lugares deben estar en discos separados. Incluso si todas las copias del registro de rehacer están en el mismo disco, sin embargo, la redundancia puede ayudar a proteger contra errores de E / S, corrupción de archivos, etc. Cuando los archivos de registro de rehacer son multiplexadas, LGWR escribe simultáneamente la misma información de registro de rehacer en varios archivos de registro de rehacer idénticas, lo que elimina un punto único de fallo de registro de rehacer.Multiplexación se realiza mediante la creación de grupos de archivos de registro de rehacer. Un

Page 5: UNIDAD4 ADMON

grupo consta de un archivo de registro de rehacer y sus copias multiplexadas. Cada copia idéntica se dice que es un miembro del grupo. Cada grupo de registro de rehacer se define por un número, 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 tamaño.

Cada miembro de un grupo de archivos de registro es simultáneamente activo, es decir, al mismo tiempo escrita por LGWR-como lo indican los registros idénticos números de secuencia asignados por LGWR. En la Figura 12-2, primero LGWR escribe simultáneamente tanto A_LOG1 y B_LOG1. A continuación, 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 pérdida de los datos del archivo de registro puede ser catastrófico si se requiere la recuperación. 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 configuración, 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 válido 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 reacción específica de LGWR cuando un miembro del registro de rehacer no está disponible depende de la razón de la falta de disponibilidad, tal como se resume en la tabla que sigue.

Page 6: UNIDAD4 ADMON

Condition LGWR Action

LGWR puede escribir con éxito en al menos un miembro de un grupo

Escritura procede como normal. LGWR escribe a los miembros disponibles de un grupo e ignora a los miembros de carácter.

LGWR no puede acceder el siguiente grupo en la conmutación de registro ya que el grupo debe archivarse

Operación de base de datos se detiene temporalmente hasta que el grupo esté disponible o hasta que el grupo se archiva.

Todos los miembros del grupo siguiente son inaccesibles para el LGWR en una conmutación 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 recuperación de los medios de comunicación sobre la base de datos de la pérdida de un archivo de registro de rehacer. Si el puesto de control de la base de datos ha ido más allá del log de redo perdidas, recuperación de los medios de comunicación no es necesario, porque la base de datos ha salvado los datos registrados en el registro de rehacer a los archivos de datos. Sólo 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 repente sean inaccesibles para el LGWR mientras está escribiendo en ellos

Base de datos Oracle devuelve un error y la instancia de base de datos se apaga inmediatamente. En este caso, puede que necesite para llevar a cabo la recuperación de los medios de comunicación. Si los medios de comunicación que contiene el registro no está realmente perdido--por ejemplo, si inadvertidamente se apagó la unidad para el registro - recuperación de los medios de comunicación no necesite. En este caso, usted sólo necesita vuelva a encender la unidad y deje que la base de datos a realizar la recuperación automática de la instancia.

Configuraciones legales e ilegalesEn la mayoría de los casos, un registro de rehacer multiplexados debe ser simétrica: todos los grupos de registro de rehacer deben tener el mismo número de miembros. Sin embargo, la base de datos no requiere que un registro de rehacer multiplexados ser simétrica. Por ejemplo, un gru-po puede tener sólo un miembro, y otros grupos puede tener dos miembros. Esta configuración protege contra fallos de disco que afecten temporalmente a algunos miembros de registro de re -hacer, pero dejan intactos los demás.

Page 7: UNIDAD4 ADMON

El único requisito para un registro de rehacer ejemplo es que tenga al menos dos grupos. La figu-ra 12-3 muestra las configuraciones de registro de rehacer multiplexados legales e ilegales. La se-gunda configuración es ilegal, ya que tiene un solo grupo.Figura 12-3 Configuración del registro de rehacer multiplexados legales e ilegales

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

Page 8: UNIDAD4 ADMON

La colocación de Ingreso de Miembros Rehacer en diferentes discos

Cuando la creación de un registro de rehacer multiplexados, lugar miembros de un grupo en diferentes discos físicos. Si un disco falla, entonces sólo 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 través 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 contención entre LGWR (escrito a los miembros) y ARCn (lectura de los miembros).

Archivos de datos también deben ser colocados en diferentes discos a partir de archivos de registro de rehacer para reducir la contención en escribir bloques de datos y rehacer los registros.

Planificación del tamaño de los archivos de registro de rehacer

Al ajustar el tamaño 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 tamaño que un grupo de llenado puede ser archivado en una sola unidad de medios de almacenamiento fuera de línea (tal como una cinta o disco), con la menor cantidad de espacio en el medio no se lo usa. Por ejemplo, supongamos que sólo 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 tamaño de los archivos de registro de rehacer ligeramente, de modo que dos grupos de registro podrían ser archivados en cada cinta.

Todos los miembros de un mismo grupo de registro de rehacer multiplexados deben ser del mismo tamaño. Los miembros de los diferentes grupos pueden tener diferentes tamaños. Sin embargo, no hay ninguna ventaja en mayor o menor tamaño de archivo entre los grupos. Si los controles no están ajustados a producirse entre los switches de registro, hacer que todos los grupos del mismo tamaño para garantizar que los puestos de control se producen a intervalos regulares.El tamaño mínimo permitido para un archivo de registro de rehacer es de 4 MB.

Vea también:

Su sistema operativo específico de documentación de Oracle. El tamaño por defecto de los archivos de registro de rehacer es el sistema operativo dependiente.

Planificación del tamaño de bloque de los archivos de registro de rehacer

A diferencia del tamaño de bloque de base de datos, que puede ser entre 2 K y 32 K, rehacer los archivos de registro siempre predeterminada a un tamaño de bloque que es igual al tamaño de sector físico del disco. Históricamente, esto ha sido típicamente 512 bytes (512B).Algunas unidades de disco nuevas de alta capacidad ofrecen 4K bytes (4K) tamaños de sector, tanto para aumentar la capacidad ECC y la mejora de la eficiencia de formato. La mayoría de las plataformas de base de datos Oracle son capaces de detectar este tamaño de sector más grande. La base de datos se crea automáticamente los archivos de registro de rehacer con un tamaño de bloque de 4K en esos discos.

Sin embargo, con un tamaño de bloque de 4K, hay una mayor desperdicio redo. De hecho, la

Page 9: UNIDAD4 ADMON

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 estadísticas 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 emulación de unidades de disco del tamaño del sector disks-4K que emulan un tamaño de sector 512B en la Interfaz del disco-puede invalidar el tamaño de bloque de 4K predeterminado para registros de rehacer especificando un tamaño de bloque 512B o , para algunas plataformas, un tamaño de bloque de 1K. Sin embargo, se le cobrará una degradación significativa del rendimiento cuando un registro de escritura redo no está alineada con los principios del sector físico de 4K. Debido a siete de las ocho ranuras 512B en un sector físico de 4K no están alineados, la degradación del rendimiento que normalmente ocurre. Por lo tanto, se debe evaluar el equilibrio entre el rendimiento y el desperdicio de disco en la planificación del tamaño de bloque de redo log en los discos en modo de emulación de tamaño de sector de 4 KB.

A partir de Oracle Database 11g versión 2, puede especificar el tamaño del bloque de archivos de registro de rehacer en línea con la palabra clave BLOCKSIZE en el CREATE DATABASE, ALTER DATABASE, y CREATE CONTROLFILE. Los tamaños de los bloques permitidos son 512, 1024 y 4096.La siguiente declaración se suma un grupo de archivos de registro de rehacer con un tamaño de bloque de 512B. La cláusula BLOCKSIZE 512 es válido pero no es necesario para los discos de tamaño de sector 512B. Para los discos de modo de emulación de tamaño de sector de 4 KB, la cláusula BLOCKSIZE 512 anula el tamaño 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 tamaño de bloque del archivo de registro de rehacer, ejecute la siguiente consulta:

SQL> SELECT BLOCKSIZE FROM V$LOG;

BLOCKSIZE--------- 512

Selección del número de archivos de registro Redo

La mejor manera de determinar el número apropiado de archivos de registro de rehacer de una instancia de base de datos es para probar diferentes configuraciones. La configuración óptima con los grupos de menor número posible sin obstaculizar LGWR de escribir la información de registro de rehacer.

En algunos casos, un ejemplo de base de datos puede requerir sólo dos grupos. En otras

Page 10: UNIDAD4 ADMON

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 más fácil para determinar si la configuración 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 parámetros que pueden limitar el número de archivos de registro de rehacer antes de crear o modificar la configuración de un registro de rehacer instancia. Los siguientes parámetros limitan el número de archivos de registro de rehacer que se pueden agregar a una base de datos:

• • El parámetro MAXLOGFILES utilizado en la instrucción CREATE DATABASE determina el número máximo 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 límite superior es volver a crear la base de datos o el archivo de control. Por lo tanto, es importante tener en cuenta este límite antes de crear una base de datos. Cuando la compatibilidad se establece en 10.2.0 o posterior, puede superar el límite MAXLOGFILES, y los archivos de control de ampliar según sea necesario. Si MAXLOGFILES no se especifica la instrucción CREATE DATABASE, la base de datos utiliza un sistema de valores por defecto específicos de funcionamiento.• El parámetro MAXLOGMEMBERS utilizado en la instrucción CREATE DATABASE determina el número máximo de miembros de cada grupo. Al igual que con MAXLOGFILES, la única manera de cambiar este límite superior es volver a crear el archivo de base de datos o de control. Por lo tanto, es importante tener en cuenta este límite antes de crear una base de datos. Si no se especifica ningún parámetro MAXLOGMEMBERS para la instrucción 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 configuración primario / en espera de base de datos, los cambios se ponen a disposición 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 están aplicando en la base de datos standby puede quedarse atrás de los cambios que se están 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 parámetro de inicialización ARCHIVE_LAG_TARGET. Al establecer este parámetro permite especificar en segundos el tiempo que el retraso puede ser.

Ajuste de la inicialización de parámetros ARCHIVE_LAG_TARGET

Cuando se establece el parámetro de inicialización ARCHIVE_LAG_TARGET, que causa la base de datos para examinar el registro de rehacer actual de la instancia periódicamente. Si se cumplen las siguientes condiciones, el ejemplo cambia el registro:

• El registro actual se creó antes de n segundos atrás, y el tiempo estimado para el archivo de

Page 11: UNIDAD4 ADMON

registro actual es m segundo (proporcional al número de bloques de rehacer utilizados en el registro actual), donde n + m excede el valor de la inicialización ARCHIVE_LAG_TARGET parámetro.• El registro actual contiene registros de rehacer.

En un entorno Real Application Clusters de Oracle, la instancia también causa otros temas para cambiar y archivar sus registros si se están quedando atrás. Esto puede ser particularmente útil cuando una instancia del clúster es más ocioso que los otros casos (como cuando se está ejecutando una configuración primario / secundario de 2 nodos de Oracle Real Application Clusters).El parámetro de inicialización ARCHIVE_LAG_TARGET proporciona un límite superior para el tiempo (en segundos) que el registro actual de la base de datos puede abarcar. Debido a que también se considera el tiempo estimado de archivo, este no es el momento exacto interruptor de registro.La siguiente configuración de parámetros de inicialización establece el intervalo de cambio de registro de 30 minutos (un valor típico).

ARCHIVE_LAG_TARGET = 1,800

Un valor de 0 desactiva esta funcionalidad de conmutación de registro basado en el tiempo. Esta es la configuración por defecto.Puede establecer el parámetro de inicialización ARCHIVE_LAG_TARGET incluso si no hay ninguna base de datos standby. Por ejemplo, el parámetro ARCHIVE_LAG_TARGET se puede configurar específicamente para forzar registros para ser conmutados y archivados.ARCHIVE_LAG_TARGET es un parámetro dinámico y se puede configurar con el comando SET ALTER SISTEMA.Precaución:El parámetro 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 configuración de ARCHIVE_LAG_TARGET

Tenga en cuenta los siguientes factores al determinar si desea establecer el parámetro ARCHIVE_LAG_TARGET y para determinar el valor de este parámetro.

Registros • Overhead de conmutación (así como el archivo)• ¿Con qué frecuencia ocurren los interruptores de registro normales como resultado de las condiciones de registro completo• Pérdida de redo ¿Cuánto se tolera en la base de datos standby

Configuración ARCHIVE_LAG_TARGET no puede ser muy útil si cambia de registro naturales ya se producen con más frecuencia que el intervalo especificado. Sin embargo, en el caso de las irregularidades de la velocidad de generación de redo, el intervalo proporciona un límite superior del intervalo de tiempo cada registro actual cubre.Si el parámetro de inicialización 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 parámetro a un valor razonable a fin de no degradar el rendimiento

Page 12: UNIDAD4 ADMON

de la base de datos primaria.

4.1.2 Recuperación (rollback)

Visión general de la recuperación Instancia

Recuperación Instancia es el proceso de aplicación de los registros en el registro de rehacer en línea a archivos de datos para reconstruir los cambios realizados después de la comprobación más reciente. Recuperación Instancia se produce de forma automática cuando un administrador intenta abrir una base de datos que se haya parado de manera inconsistente.

Propósito de la recuperación Instancia

Recuperación Instancia asegura que la base de datos está en un estado coherente después de un fallo de ejemplo. Los archivos de una base de datos se puede dejar en un estado incoherente debido a cómo 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 múltiples hilos de rehacer, uno para cada instancia de base de datos.Cuando se confirma una transacción, inicie sesión escritor (LGWR) escribe tanto las entradas de redo que quedan en la memoria y el SCN transacción en el registro de rehacer en línea. 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 más eficiente. Por esta razón, los cambios no pueden existir temporalmente en los archivos de datos, mientras que los cambios confirmados todavía no existen en los archivos de datos.

Si una instancia de una base de datos abierta falla, ya sea por una declaración ABORTAR PARADA o terminación anormal, a continuación, las siguientes situaciones pueden dar lugar a:• Los bloques de datos cometidos por una transacción no se escriben en los archivos de datos y sólo aparecen en el registro de rehacer en línea. Estos cambios se deben volver a aplicar a la base de datos.• Los archivos de datos contiene cambios que no se habían cometido cuando la instancia falló. Estos cambios deben ser deshacen de garantizar la coherencia transaccional.

Recuperación Instancia sólo utiliza archivos de registro de rehacer en línea y archivos de datos en línea actuales para sincronizar los archivos de datos y asegurarse de que sean compatibles.

Cuando se realiza la recuperación de base de datos Oracle Instancia

Si se requiere la recuperación 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 están 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 recuperación de instancias.

Oracle Database realiza la recuperación instancia automáticamente en las siguientes situaciones:

Page 13: UNIDAD4 ADMON

• 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 recuperación de la instancia también se conoce como recuperación de fallos. Oracle Database recupera los temas de rehacer en línea de los casos terminados juntos.

• Algunos, pero no todos los casos de una base de datos Oracle RAC no. Recuperación Instancia se lleva a cabo automáticamente por una instancia de sobrevivir en la configuración.El proceso en segundo plano SMON realiza la recuperación de ejemplo, la aplicación de rehacer en línea de forma automática. No se requiere la intervención del usuario.

Importancia de los puntos de control para la recuperación Instancia

Recuperación Instancia utiliza puntos de control para determinar qué cambios deben aplicarse a los archivos de datos. Las garantías de los puestos de control de posición 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 línea.

Figura 13-5 Checkpoint Posición en Redo Log Online

Durante la recuperación de ejemplo, la base de datos debe aplicar los cambios que se producen entre la posición del punto de control y el final de la rosca redo. Como se muestra en la Figura 13-5, algunos cambios pueden haber sido escrito a los archivos de datos. Sin embargo, únicamente los cambios en SCN inferiores a la posición de punto de control se garantiza que sea el disco.Vea también:Oracle Database Performance Tuning Guide para aprender a limitar el tiempo de recuperación de la instancia

Fases de Recuperación de instancia

La primera fase de recuperación de la instancia se llama recuperación de caché o rodar hacia delante, y consiste en volver a aplicar todos los cambios registrados en el registro de rehacer en línea de los archivos de datos. Dado que los datos de reversión se registra en el registro de

Page 14: UNIDAD4 ADMON

rehacer en línea, rodando hacia adelante también regenera los correspondientes segmentos de deshacer.Rodando procede hacia adelante a través de todos los archivos de registro de rehacer en línea que sean necesarias para llevar a la base de datos en el tiempo. Después de rodar hacia adelante, los bloques de datos contienen todos los cambios confirmados registrados en los archivos de registro de rehacer en línea. Estos archivos también 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 línea y se introdujeron durante la recuperación de la memoria caché.

Después de la puesta al día, todos los cambios que no fueron cometidos deben ser deshechos. Oracle Database utiliza la posición 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 recuperación de la memoria caché. Esta fase se llama de nuevo o recuperación 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 básicos Pasos de recuperación 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

Page 15: UNIDAD4 ADMON

necesarios.

4.1.3 Permanencia (commit)

En el contexto de la Ciencia de la computación y la gestión de datos, commit (acción 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 transacción de base de datos.

Una sentencia COMMIT en SQL finaliza una transacción 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 más 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 recuperación) 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, encontraría el valor de 5 USD en los datafiles?

Antes de responder esta pregunta, vamos a poner otra situación con el mismo ejemplo, en lugar de cometer mis datos después del incremento salarial espere el fin de semana para reflexionar en este cambio, solamente dejo la sesión abierta sin cometer los datos.El lunes que regreso, y verifico los datos directamente en los datafiles, que valor encontraría, 1 o 5 USD? La lógica me llevaría a decir que, 1 USD, ya que nunca cometí mis datos?

Si con este escenario, acuérdate que no hemos cometido los datos, si se checaran los datos en el Online Redo Log, que valorse encontraría, 1 o 5 USD?

Si tu respuesta fue 1 USD, seria la mas lógica, ya que no se han cometido los datos y no son necesarios para el proceso de recuperación en caso de que mi base de datos se cayera, si respondiste 5 USD, entonces como explicarías el proceso de recuperación en caso de que se haya caído la instancia, si cuando se hace una recuperación 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í abajoCrea un tablespace pequeño, 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.

Page 16: UNIDAD4 ADMON

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 veren el datafileoracle@localhost [TESTDB] /mount/u01/oracle/TESTDB/dataroot $ 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 después verifica de nuevo el datafile, y te vas a dar cuentaque este dato que acabas de actualizar no se encuentra en el datafile, que sigues viendo el valor de 1_USDTESTDB >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.

Page 17: UNIDAD4 ADMON

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/dataroot $ strings /mount/u01/oracle/TESTDB/data/pruebas01.dbf

z{|}

5wXTESTDB

PRUEBA

5_USD

Abre una nueva sesión 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 datosTESTDB >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 información arrojar, si en el datafile se encuentra el valor de 5_USD. Oracle logra esto a través 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 lógico 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 sesión nueva, la base de datos determina el SCN registrado en el momento que el query se empezó a ejecutar.Este select requiere una versión 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

Page 18: UNIDAD4 ADMON

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 dónde toma Oracle la información 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 crítico para la consistencia de nuestros datos.

4.2 Definición de los modos de operación de un DBMS. (alta, baja, recovery)

Propósito de Backup y Recuperación

Como administrador de copia de seguridad, la tarea principal es diseñar, implementar y gestionar una estrategia de backup y recuperación. En general, el propósito de una estrategia de recuperación de copia de seguridad y es para proteger la base de datos contra la pérdida de datos y reconstruir la base de datos después de la pérdida de datos. Normalmente, las tareas de administración de seguridad son las siguientes:

• Planificación y probar las respuestas a diferentes tipos de fallas

• Configuración del entorno de base de datos de copia de seguridad y recuperación

• La creación de un programa de copia de seguridad

• Seguimiento de la copia de seguridad y entorno de recuperación

• Solución de problemas de copia de seguridad

• Para recuperarse de la pérdida 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 recuperación:

• La preservación de datos, lo que implica la creación 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 propósito de este manual es explicar cómo realizar las tareas anteriores.

De Protección de Datos

Como administrador de copia de seguridad, su trabajo principal es hacer copias de seguridad y

Page 19: UNIDAD4 ADMON

vigilancia para la protección 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 física o una copia de seguridad lógica.

Copias de seguridad físicas son copias de los archivos físicos utilizados en el almacenamiento y la recuperación 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 física es una copia de los archivos que almacenan información de base de datos a otra ubicación, ya sea en un disco o en medios de almacenamiento fuera de línea, tales como cinta.

Copias de seguridad lógicas contienen datos lógicos, como tablas y procedimientos almacenados. Puede utilizar Oracle Data Pump para exportar los datos a archivos lógicos binarios, que posteriormente puede importar a la base de datos. Clientes de línea de comandos La bomba datos expdp y impdp utilizan el DBMS_DATAPUMP y DBMS_METADATA PL / SQL paquetes.

Copias de seguridad físicas son la base de cualquier estrategia de recuperación de copia de seguridad sólida y. Copias de seguridad lógicas son un complemento útil de las copias de seguridad físicas en muchas circunstancias, pero no son suficiente protección contra la pérdida de datos y sin respaldos físicos

A menos que se especifique lo contrario, la copia de seguridad término tal como se utiliza en la copia de seguridad y la documentación de recuperación se refiere a una copia de seguridad física. Copia de seguridad de una base de datos es el acto de hacer una copia de seguridad física. El enfoque en la copia de seguridad y recuperación de documentación está casi exclusivamente en copias de seguridad físicas.

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 intervención del DBA y de recuperación de datos: un error de medios, errores de usuario, y los errores de aplicación. Otros fallos pueden requerir intervención DBA sin causar la pérdida de datos o que requieren la recuperación de copia de seguridad. Por ejemplo, es posible que tenga que reiniciar la base de datos tras un fallo de instancia o asignar más espacio de disco después de un fallo debido a la declaración de un archivo de datos completo.

Las fallas de medios.

La falta de medios es un problema físico 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 comunicación. La técnica de recuperación adecuada después de un fallo de los medios de comunicación depende de los archivos afectados y el tipo de copias de seguridad disponibles.

Un aspecto particularmente importante de la copia de seguridad y recuperación se está desarrollando una estrategia de recuperación ante desastres para proteger contra la pérdida de datos catastrófica, por ejemplo, la pérdida de toda una serie de bases de datos.

Errores de los usuarios

Page 20: UNIDAD4 ADMON

Los errores del usuario cuando se producen, ya sea debido a un error en la lógica de la aplicación 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 pérdida de datos debido a un error del usuario puede ser localizada o generalizada. Un ejemplo de daño localizado está eliminando a la persona equivocada en la tabla empleados. Este tipo de lesiones requiere la detección y la reparación quirúrgica. Un ejemplo de un daño generalizado es un trabajo por lotes que borra las órdenes de la empresa para el mes en curso. En este caso, se requiere una acción drástica para evitar una extensa base de datos de tiempo de inactividad.

Mientras que la formación de usuarios y el manejo cuidadoso de los privilegios pueden prevenir la mayoría 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 aplicación

A veces, un mal funcionamiento de software puede dañar los bloques de datos. En una corrupción física, que también se conoce como la corrupción los medios de comunicación, la base de datos no reconoce el bloque en absoluto: la suma de comprobación no es válida, el bloque contiene todos los ceros, o el encabezado y el pie de página del bloque no coinciden. Si el daño no es muy amplio, puede a menudo repara fácilmente con bloque de recuperación de medios.

Preservación de Datos

Conservación de datos se relaciona con la protección de datos, pero tiene un propósito diferente. Por ejemplo, puede que tenga que conservar una copia de una base de datos tal como existía al final de la cuarta parte del negocio. Esta copia de seguridad no es parte de la estrategia de recuperación de desastres. Los medios a los que estas copias de seguridad se escriben a menudo disponible después de la copia de seguridad. Usted puede enviar la cinta en almacenamiento incendio o enviar un disco duro portátil a un centro de pruebas. RMAN proporciona una manera conveniente para crear una copia de seguridad y eximirla de su política de retención 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 ubicación. Por ejemplo, puede utilizar el Administrador de recuperación (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 recuperación, 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 recuperación Soluciones

Al implementar una estrategia de backup y recuperación, dispone de las siguientes soluciones disponibles:

Page 21: UNIDAD4 ADMON

• Administrador de recuperación (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 recuperación, incluyendo el mantenimiento de un repositorio de RMAN de datos históricos acerca de las copias de seguridad. Se puede acceder a RMAN través de la línea de comandos oa través de Oracle Enterprise Manager.

• Copia de seguridad y recuperación gestionadas por el usuario

En esta solución, realizar copias de seguridad y recuperación con una mezcla de comandos del sistema operativo host y SQL * Plus recuperación commands.You son responsables de determinar todos los aspectos de cuándo y cómo las copias de seguridad y la recuperación se hacen.Estas soluciones están respaldadas por Oracle y se documentan, pero RMAN es la mejor solución para copia de seguridad y recuperación de bases de datos. RMAN proporciona una interfaz común para las tareas de copia de seguridad a través de diferentes sistemas operativos host, y ofrece varias técnicas de copia de seguridad que no están disponibles a través de métodos administrados por usuarios.

La mayor parte de este manual se centra en la copia de seguridad y recuperación de RMAN basado. Técnicas de copia de seguridad y recuperación gestionadas por el usuario se tratan en Realización de usuario-Managed Backup and Recovery. Las más destacables son los siguientes:

• Copias de seguridad incrementales

Una copia de seguridad incremental almacena sólo los bloques modificados desde la última copia de seguridad. Por lo tanto, proporcionan copias de seguridad más compacto y una recuperación más rápida, lo que reduce la necesidad de aplicar de rehacer en archivo de datos de recuperación de los medios de comunicación. 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 recuperación

Usted puede reparar un archivo de datos con sólo un pequeño número de bloques de datos corruptos sin tomarlo fuera de línea o la restauración desde copia de seguridad. Utilice el comando BLOQUE RECOVER para realizar la recuperación del bloque de comunicación.

• Compresión binaria

Un mecanismo de compresión binaria integrado en base de datos Oracle reduce el tamaño 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 opción de seguridad

Page 22: UNIDAD4 ADMON

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 opción de seguridad avanzada.

• Duplicación de la base de datos automatizada

Crea fácilmente una copia de su base de datos, el apoyo a diversas configuraciones de almacenamiento, incluida la duplicación directa entre las bases de datos de ASM.

• Conversión de datos entre plataformas

Ya sea que utilice RMAN o métodos administrados por usuarios, puede complementar las copias de seguridad físicas con copias de seguridad lógicas de objetos de esquema realizados con la utilidad Export Data Pump. Más tarde, puede utilizar Data Pump Import para volver a crear los datos después de la restauración y la recuperación. Copias de seguridad lógicas son en su mayoría más allá del alcance de la copia de seguridad y de recuperación de documentación.

4.3 Comandos de activacion de los modos de operación

4.4. Manejo de índices

Resumen índicesUn índice es una estructura opcional, asociado con una mesa o tabla de clúster, que a veces puede acelerar el acceso de datos. Mediante la creación de un índice en una o varias columnas de una tabla, se obtiene la capacidad en algunos casos, para recuperar un pequeño conjunto de filas distribuidas al azar de la tabla. Los índices son una de las muchas formas de reducir el disco I / O.Si una tabla de montón organizado no tiene índices, entonces la base de datos debe realizar un escaneo completo de tabla para encontrar un valor. Por ejemplo, sin un índice, una consulta de ubicación 2700 en la tabla hr.departments requiere la base de datos para buscar todas las filas de cada bloque de la tabla para este valor. Este enfoque no escala bien como datos de aumento de volúmenes.

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

ID 100: Box 3, position 1 (bottom)ID 101: Box 7, position 8 ID 200: Box 1, position 10Del mismo modo, el administrador podría crear índices separados para los últimos nombres de los empleados, los ID de departamento, y así sucesivamente. En general, considerar la creación de un índice en una columna en cualquiera de las siguientes situaciones:

Page 23: UNIDAD4 ADMON

• Las columnas indizadas se consultan con frecuencia y devuelven un pequeño porcentaje del número total de filas en la tabla.• Existe una restricción de integridad referencial en la columna o columnas indexadas. El índice es un medio para evitar un bloqueo de tabla completa que de otro modo se requeriría si se actualiza la clave principal de la tabla principal, se funden en la tabla principal, o eliminar de la tabla primaria.• Una restricción de clave única se coloca sobre la mesa y desea especificar manualmente el índice de todas las opciones sobre índices y.

Características de indexaciónLos índices son objetos de esquema que son lógica y físicamente independiente de los datos de los objetos con los que están asociados. Por lo tanto, un índice se puede quitar o creado sin afectar físicamente a la tabla para el índice.Nota:Si se le cae un índice, las aplicaciones siguen funcionando. Sin embargo, el acceso de los datos previamente indexado puede ser más lento.La ausencia o presencia de un índice no requiere un cambio en el texto de cualquier sentencia SQL. Un índice es una ruta de acceso rápido a una sola fila de datos. Sólo afecta a la velocidad de ejecución. Dado un valor de datos que se ha indexado, el índice apunta directamente a la ubicación de las filas que contienen ese valor.La base de datos mantiene automáticamente y utiliza los índices después de su creación. La base de datos también refleja automáticamente los cambios en los datos, como agregar, actualizar y eliminar filas, en todos los índices pertinentes sin acciones adicionales requeridas por los usuarios. Rendimiento de recuperación de datos indexados permanece casi constante, incluso cuando se insertan filas. Sin embargo, la presencia de muchos índices en una tabla degrada el rendimiento DML porque la base de datos también debe actualizar los índices.

Índices tienen las siguientes propiedades:• Facilidad de usoLos í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.• VisibilidadLos índices son visibles (por defecto) o invisible. Un índice invisible se mantiene por las operaciones DML y no se utiliza de forma predeterminada por el optimizador. Cómo hacer una invisible índice es una alternativa a lo que es inutilizable o se caiga. Índices invisibles son especialmente útiles para probar la eliminación de un índice antes de dejarlo caer o mediante índices temporalmente sin afectar a la aplicación general.Guía del administrador de aprender a manejar los índices• Base de datos Oracle Performance Tuning Guide para aprender cómo ajustar los índicesTeclas y ColumnasUna clave es un conjunto de columnas o expresiones en las que se puede construir un índice. Aunque los términos se usan indistintamente, los índices y las claves son diferentes. Los índices son estructuras almacenados en la base de datos que los usuarios a administrar el uso de sentencias de SQL. Las claves son estrictamente un concepto lógico.

Page 24: UNIDAD4 ADMON

La siguiente sentencia crea un índice en la columna customer_id de la muestra oe.orders tabla:

CREATE INDEX ord_customer_ix ON orders (customer_id);

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

Índices Compuestos

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

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

CREATE INDEX employees_ixON employees (last_name, job_id, salary);Las consultas que acceden a las tres columnas, sólo la columna last_name, o sólo el last_name y columnas job_id utilizan este índice. En este ejemplo, las consultas que no tienen acceso a la columna last_name no utilizan el índice.Nota:

En algunos casos, tales como cuando la columna principal tiene muy baja cardinalidad, la base de datos puede utilizar una búsqueda selectiva de este índiceMúltiples índices pueden existir para la misma mesa, siempre y cuando la permutación de columnas difiere para cada índice. Puede crear varios índices que utilizan las mismas columnas si se especifica claramente diferentes permutaciones de las columnas. Por ejemplo, las siguientes sentencias SQL especifican permutaciones válidas:

CREATE INDEX employee_idx1 ON employees (last_name, job_id);CREATE INDEX employee_idx2 ON employees (job_id, last_name);

Índices únicos y no único

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

Índices no únicas permiten valores duplicados en la columna o columnas indexadas. Por ejemplo,

Page 25: UNIDAD4 ADMON

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

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

Tipos de índices

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

• Los índices de árbol B

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

Índice de tablas organizadas o

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

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

Ö Descendente índices

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

o índices B-tree de racimo

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

• Mapa de bits y los índices bitmap join

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

• Los índices basados en funciones

Page 26: UNIDAD4 ADMON

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

Consulte "Indicadores basados en funciones".

• Índices de dominio de aplicación

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

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

Índices B-Tree

Árboles B, abreviatura de árboles balanceados, son el tipo más común de índice de base de datos. Un índice B-tree es una lista ordenada de valores dividida en rangos. Mediante la asociación de una tecla con una fila o rango de filas, los árboles B proporcionan un excelente rendimiento de la recuperación para una amplia gama de consultas, incluyendo coincidencia exacta y búsquedas por rango.

La figura 3-1 ilustra la estructura de un índice B-tree. El ejemplo muestra un índice en la columna department_id, que es una columna de clave externa en la tabla empleados.

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

Bloqueos de rama y Bloques Leaf

Page 27: UNIDAD4 ADMON

Un índice B-tree tiene dos tipos de bloques: bloques de sucursales para la búsqueda y la hoja de bloques que almacenan valores. Los bloqueos de rama de nivel superior de un índice B-tree contienen datos de índice que apunta a bloques de índices de nivel inferior. En la Figura 3-1, el bloqueo de la rama raíz tiene una entrada de 0-40, lo que apunta al bloque de izquierda en el siguiente nivel de sucursales. Este bloqueo de la rama contiene entradas como 0-10 y 11-19. Cada uno de estos puntos de entradas a un bloque de la hoja que contiene los valores de clave que caen en la gama.Un índice de árbol B está equilibrado porque todos los bloques hoja mantenerse de forma automática a la misma profundidad. Por lo tanto, la recuperación de cualquier documento desde cualquier lugar del índice toma aproximadamente la misma cantidad de tiempo. La altura del índice es el número de bloque requerido para pasar de el bloque de raíz a un bloque de la hoja. El nivel de las sucursales es la altura menos 1. En la Figura 3-1, el índice tiene una altura de 3 y un nivel de rama de la 2.Bloqueos de rama almacenar el prefijo de clave mínimo necesario para tomar una decisión de ramificación entre dos teclas. Esta técnica permite que la base de datos para adaptarse a la mayor cantidad de información posible sobre cada bloque de rama. Los bloqueos de rama contienen un puntero al bloque de niño que contiene la clave. El número de teclas y punteros está limitado por el tamaño del bloque.Los bloques de hojas contienen todos los valores de datos indexada y un ROWID correspondiente se utiliza para localizar la fila actual. Cada entrada está ordenada por (clave, ROWID). Dentro de un bloque de la hoja, una llave y ROWID está vinculada a sus hermanos entradas izquierda y derecha. Los propios bloques hoja también están doblemente enlazadas. En la Figura 3-1 el bloque de hoja más a la izquierda (0-10) está ligada a la segunda hoja bloque (11-19).

Nota:Los índices en columnas con datos de tipo carácter se basan en los valores binarios de los personajes en el juego de caracteres de base de datos.Scans ÍndiceEn un recorrido de índice, la base de datos recupera una fila al recorrer el índice, utilizando los valores de columna indexados especificados por la norma. Si la base de datos analiza el índice de un valor, entonces se encontrará este valor en n E / S donde n es la altura del índice B-tree. Este es el principio básico detrás de los índices de base de datos Oracle.Si una instrucción SQL sólo tiene acceso a columnas indexadas, a continuación, lee los valores de la base de datos directamente desde el índice en lugar de a partir de la tabla. Si la declaración accede columnas, además de las columnas indizadas, a continuación, la base de datos utiliza ROWIDs para encontrar las filas de la tabla. Típicamente, la base de datos recupera los datos de la tabla por alternativamente la lectura de un bloque de índice y luego un bloque de tabla.

Vea también:Oracle Database Performance Tuning Guide para obtener información detallada sobre las exploraciones de índicesÍndice Análisis CompletoEn un recorrido de índice completo, la base de datos lee el índice completo en orden. Una exploración de índice completo está disponible si una columna en el índice, y en algunas circunstancias, cuando no se especifica un predicado de un predicado (cláusula WHERE) en las referencias de sentencia de SQL. Un análisis completo puede eliminar la clasificación ya que los datos aparecen ordenados por clave de índice.Supongamos que una aplicación se ejecuta la siguiente consulta:

Page 28: UNIDAD4 ADMON

SELECT department_id, last_name, salary FROM employeesWHERE salary > 5000 ORDER BY department_id, last_name;

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

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

50,Atkinson,2800,rowid60,Austin,4800,rowid70,Baer,10000,rowid80,Abel,11000,rowid80,Ande,6400,rowid110,Austin,7200,rowid...EspañolInglésPortugués

Fast Índice Análisis CompletoUn análisis rápido índice completo es un análisis completo índice en el que la base de datos lee los bloques de índice en ningún orden en particular. La base de datos accede a los datos en el índice de sí mismo, sin acceso a la tabla. Exploraciones de índices completos rápidos son una alternativa a un escaneo completo de tabla cuando el índice contiene todas las columnas que son necesarios para la consulta, y al menos una columna en la clave de índice tiene la restricción NOT NULL. Por ejemplo, una aplicación emite la siguiente consulta, que no incluye una cláusula ORDER BY:

SELECT last_name, salaryFROM employees;

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

Baida,2900,rowidZlotkey,10500,rowidAustin,7200,rowidBaer,10000,rowidAtkinson,2800,rowidAustin,4800,rowid

Page 29: UNIDAD4 ADMON

.

.

.

Índice de escaneado

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

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

• 0, 1, o más valores son posibles para una clave de índice.

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

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

Abel,rowidAnde,rowidAtkinson,rowidAustin,rowidAustin,rowidBaer,rowid...

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

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

Page 30: UNIDAD4 ADMON

Index Scan Unique

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

SELECT *FROM employeesWHERE employee_id = 5;

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

1,rowid2,rowid4,rowid5,rowid6,rowid...

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

Índice Skip Scan

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

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

SELECT * FROM sh.customers WHERE cust_email = '[email protected]';

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,[email protected],rowid

Page 31: UNIDAD4 ADMON

F,[email protected],rowidF,[email protected],rowidF,[email protected],rowidF,[email protected],rowidF,[email protected],rowidM,[email protected],rowidM,[email protected],rowid

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

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

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

SELECT * FROM sh.customers WHERE cust_gender = 'F' AND cust_email = '[email protected]'UNION ALLSELECT * FROM sh.customers WHERE cust_gender = 'M' AND cust_email = '[email protected]';

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

La inversión de la llave soluciona el problema de la contención de los bloques de la hoja en el lado derecho de un índice B-tree. Este problema puede ser especialmente grave en un Oracle Real Application Clusters (Oracle RAC) de base de datos en la que varias instancias modificar varias veces el mismo bloque. Por ejemplo, en un ordena tablas las claves principales para las órdenes son secuenciales. Una instancia del clúster agrega fin 20, mientras que otro 21 añade, con cada instancia de escribir su clave para el mismo bloque de la hoja en el lado derecho del índice.En un índice de clave inversa, la revocación de la orden de bytes distribuye inserta a través de todas las claves de la hoja en el índice.Por ejemplo, las llaves, como 20 y 21, que habría sido enunciada en un índice de clave estándar están almacenados lejos en bloques separados. Por lo tanto, E / S para las inserciones de claves secuenciales se distribuye más uniformemente.Debido a que los datos en el índice no está ordenado por clave columna cuando se almacena, la disposición de las teclas inversa elimina la capacidad de ejecutar una serie de consulta de exploración de índice en algunos casos. Por ejemplo, si un usuario emite una consulta para los ID de orden superior a 20, a continuación, la base de datos no puede comenzar con el bloque que

Page 32: UNIDAD4 ADMON

contiene este ID y proceder horizontalmente a través de los bloques hoja.

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

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

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

Al especificar la palabra clave DESC en la sentencia CREATE INDEX, puede crear un índice descendente. En este caso, el índice almacena los datos en una columna o columnas especificado en orden descendente. Si el índice en la figura 3-1 en la columna employees.department_id se desciende, a continuación, la hoja de bloqueo que contenía 250 sería en el lado izquierdo del árbol y el bloque con 0 a la derecha. La búsqueda por defecto a través de un índice descendente es de mayor a menor valor.Descendente índices son útiles cuando una consulta de tipo algunas columnas que suben y otros descendente. Por ejemplo, supongamos que se crea un índice compuesto sobre el last_name y columnas department_id de la siguiente manera:

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

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

Compresión clave

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

Nota:

Page 33: UNIDAD4 ADMON

Si no se define una clave para tener una pieza única, entonces la base de datos proporciona una añadiendo un ROWID a la pieza de agrupación

De forma predeterminada, el prefijo de un índice único se compone de todas las columnas de clave excluyendo el último, mientras que el prefijo de un índice no único se compone de todas las columnas de clave. Por ejemplo, supongamos que crea un índice compuesto sobre la mesa oe.orders la siguiente manera:

CREATE INDEX orders_mod_stat_ix ON orders ( order_mode, order_status );

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

Example 3-2 Index Entries in Orders Table

online,0,AAAPvCAAFAAAAFaAAaonline,0,AAAPvCAAFAAAAFaAAgonline,0,AAAPvCAAFAAAAFaAAlonline,2,AAAPvCAAFAAAAFaAAmonline,3,AAAPvCAAFAAAAFaAAqonline,3,AAAPvCAAFAAAAFaAAt

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

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

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

online0,AAAPvCAAFAAAAFaAAa0,AAAPvCAAFAAAAFaAAg0,AAAPvCAAFAAAAFaAAl2,AAAPvCAAFAAAAFaAAm

Page 34: UNIDAD4 ADMON

3,AAAPvCAAFAAAAFaAAq3,AAAPvCAAFAAAAFaAAt

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

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

• Las columnas indexadas tienen baja cardinalidad, es decir, el número de valores distintos que es pequeño en comparación con el número de filas de la tabla.• La tabla de indexado es ya sea de sólo lectura o no sujetos a modificación significativa de las sentencias DML.

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

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

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

Índices de mapa de bits en una sola tabla

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

SQL> SELECT cust_id, cust_last_name, cust_marital_status, cust_gender 2 FROM sh.customers 3 WHERE ROWNUM < 8 ORDER BY cust_id; CUST_ID CUST_LAST_ CUST_MAR C---------- ---------- -------- - 1 Kessel M

Page 35: UNIDAD4 ADMON

2 Koch F 3 Emmerson M 4 Hardy M 5 Gowen M 6 Charles single F 7 Ingram single F 7 rows selected.

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

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

Table 3-1 Ejemplo de Bitmap

Value Row 1 Row 2 Row 3 Row 4 Row 5 Row 6 Row 7

M 1 0 1 1 1 0 0

F 0 1 0 0 0 1 1

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

Nota:Índices de mapa de bits pueden incluir claves que consisten enteramente en valores nulos, a diferencia de índices B-tree. Nulos de indexación puede ser útil para algunas sentencias SQL, como las consultas con el número de función de agregado.Un analista de la investigación de las tendencias demográficas de los clientes puede preguntar, "¿Cuántos de nuestros clientes son mujeres solteras o divorciadas?" Esta pregunta se corresponde con la siguiente consulta SQL

SELECT COUNT(*) FROM customers WHERE cust_gender = 'F' AND cust_marital_status IN ('single', 'divorced');

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

Page 36: UNIDAD4 ADMON

Tabla 3-2 Mapa de bits ejemplo

Value Row 1 Row 2 Row 3 Row 4 Row 5 Row 6 Row 7

M 1 0 1 1 1 0 0

F 0 1 0 0 0 1 1

single 0 0 0 0 0 1 1

divorced 0 0 0 0 0 0 0

single or divorced, and F 0 0 0 0 0 1 1

Indexación Bitmap combina eficientemente los índices que corresponden a una serie de condiciones en una cláusula WHERE. Las filas que satisfacer algunas, pero no todas, las condiciones se filtran antes de la propia tabla se accede. Esta técnica mejora el tiempo de respuesta, a menudo de forma espectacular.Bitmap Únete índicesUn índice de combinación de mapa de bits es un índice de mapa de bits para la unión de dos o más tablas. Para cada valor de una columna de la tabla, el índice almacena el identificador de fila de la fila correspondiente en la tabla indexada. Por el contrario, se crea un índice de mapa de bits estándar en una sola tabla.Un índice de unirse a mapa de bits es un medio eficaz de reducir el volumen de datos que se deben unir mediante la realización de las restricciones de antemano. Para un ejemplo de cuando un bitmap unirse índice sería útil, suponen que los usuarios a menudo consultan el número deempleados con un tipo de trabajo en particular. Una consulta típica podría ser como sigue:

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

CREATE BITMAP INDEX employees_bm_idx ON employees (jobs.job_title) FROM employees, jobsWHERE employees.job_id = jobs.job_id;

Figure 3-2 Bitmap Join Index

Page 37: UNIDAD4 ADMON

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

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

SELECT jobs.job_title AS "jobs.job_title", employees.rowid AS "employees.rowid"FROM employees, jobsWHERE employees.job_id = jobs.job_idORDER BY job_title; jobs.job_title employees.rowid----------------------------------- ------------------Accountant AAAQNKAAFAAAABSAALAccountant AAAQNKAAFAAAABSAANAccountant AAAQNKAAFAAAABSAAMAccountant AAAQNKAAFAAAABSAAJAccountant AAAQNKAAFAAAABSAAKAccounting Manager AAAQNKAAFAAAABTAAHAdministration Assistant AAAQNKAAFAAAABTAACAdministration Vice President AAAQNKAAFAAAABSAAC

Page 38: UNIDAD4 ADMON

Administration Vice President AAAQNKAAFAAAABSAAB...En un almacén de datos, la condición de unión es una unión igualitaria (que utiliza el operador de igualdad) entre las columnas de clave principal de las tablas de dimensiones y las columnas de clave externa de la tabla de hechos. Unirse a los índices de mapa de bits son a veces mucho más eficiente en el almacenamiento de materializada unen puntos de vista, una alternativa para materializar une con antelación.Vea también:Oracle Database Data Warehousing Guide para obtener más información acerca de unirse a los índices de mapa de bitsEstructura de almacenamiento BitmapOracle Database utiliza una estructura de índice B-tree para almacenar mapas de bits para cada clave indexada. Por ejemplo, si jobs.job_title es la columna de clave de un índice de mapa de bits, entonces los datos de índice se almacena en un B-árbol. Los mapas de bits individuales se almacenan en los bloques hoja. Supongamos que la columna tiene valores jobs.job_title único vendedor de envío, Stock Clerk, y varios otros. Una entrada de índice de mapa de bits para este índice tiene los siguientes componentes:• El título del trabajo como la clave del índice• Un ROWID ROWID bajo y alto para una variedad de ROWIDs• Un mapa de bits para ROWIDs específicos en el rangoConceptualmente, un bloque de la hoja de índice en este índice podría contener las entradas de la siguiente manera:

Shipping Clerk,AAAPzRAAFAAAABSABQ,AAAPzRAAFAAAABSABZ,0010000100Shipping Clerk,AAAPzRAAFAAAABSABa,AAAPzRAAFAAAABSABh,010010Stock Clerk,AAAPzRAAFAAAABSAAa,AAAPzRAAFAAAABSAAc,1001001100Stock Clerk,AAAPzRAAFAAAABSAAd,AAAPzRAAFAAAABSAAt,0101001001Stock Clerk,AAAPzRAAFAAAABSAAu,AAAPzRAAFAAAABSABz,100001...El mismo título del trabajo aparece en varias entradas debido a la gama ROWID difiere.

Supongamos que actualiza una sesión de trabajo de la identificación de un empleado del vendedor de envío de Stock Clerk. En este caso, la sesión requiere acceso exclusivo a la entrada de clave de índice para el valor antiguo (vendedor de envío) y el nuevo valor (Stock Clerk). Base de datos de Oracle bloquea las filas apuntada por estas dos entradas, pero no las filas apuntado por contador o cualquier otra tecla-hasta que la actualización comete.Los datos para un índice de mapa de bits se almacenan en un segmento. Base de datos Oracle almacena cada mapa de bits en una o más piezas. Cada pieza ocupa parte de un único bloque de datos.

Índices basados en funcionesPuede crear índices sobre las funciones y las expresiones que implican una o más columnas de la tabla está indexada. Un índice basado en funciones calcula el valor de una función o expresión que implique una o varias columnas y se almacena en el índice. Un índice basado en funciones

Page 39: UNIDAD4 ADMON

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

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

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

CREATE INDEX emp_total_sal_idx ON employees (12 * salary * commission_pct, salary, commission_pct);

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

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

SELECT employee_id, last_name, first_name, 12*salary*commission_pct AS "ANNUAL SAL"FROM employeesWHERE (12 * salary * commission_pct) < 30000ORDER BY "ANNUAL SAL" DESC;

EMPLOYEE_ID LAST_NAME FIRST_NAME ANNUAL SAL----------- ------------------------- -------------------- ---------- 159 Smith Lindsey 28800 151 Bernstein David 28500 152 Hall Peter 27000 160 Doran Louise 27000 175 Hutton Alyssa 26400 149 Zlotkey Eleni 25200 169 Bloom Harrison 24000

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

CREATE INDEX emp_fname_uppercase_idx ON employees ( UPPER(first_name) );

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

SELECT *

Page 40: UNIDAD4 ADMON

FROM employeesWHERE UPPER(first_name) = 'AUDREY';

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

CREATE INDEX cust_valid_idxON customers ( CASE cust_valid WHEN 'A' THEN 'A' END );

Optimización con índices basados en funciones

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

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

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

Índices dominio de la aplicación.

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

• Acomodar los índices de medida, los tipos de datos complejos, tales como documentos, datos espaciales, imágenes y clips de vídeo (ver "Datos no estructurados")

• Hacer uso de las técnicas de indexación especializadas. Puede encapsular las rutinas de administración de índices específicos de la aplicación como un objeto de esquema INDEXTYPE y definir un índice de dominio en columnas de tablas o atributos de un tipo de objeto.

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

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

Page 41: UNIDAD4 ADMON

Índice de almacenamiento

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

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

Visión general de las tablas de índice organizadas

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

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

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

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

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

Page 42: UNIDAD4 ADMON

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

Características de las tablas de índice organizadas

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

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

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

Figura 3-3 Cuadro de índice Organizada

Page 43: UNIDAD4 ADMON

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,180030,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,150060,IT,103,1400

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

50,Shipping,121,150020,Marketing,201,1800

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

30,Purchasing,114,170060,IT,103,1400

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

20,AAAPeXAAFAAAAAyAAD30,AAAPeXAAFAAAAAyAAA50,AAAPeXAAFAAAAAyAAC60,AAAPeXAAFAAAAAyAAB

Una exploración de las filas de la tabla con el fin de clave principal lee los bloques de segmentos de la tabla en la siguiente secuencia:1. Bloque 12. Bloque 23. Bloque 14. Bloque 2

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

Tablas de índice organizadas con Row Area Overflow

Page 44: UNIDAD4 ADMON

Cuando se crea una tabla organizada por índices, puede especificar un segmento separado como un área de desbordamiento fila. En las tablas de índice organizadas, las entradas del índice B-tree pueden ser grandes, ya que contienen una fila completa, por lo que un segmento aparte de contener las entradas es útil. Por el contrario, las entradas B-árboles son generalmente pequeñas, ya que consisten en la llave y ROWID. Si se especifica un área de desbordamiento de fila, a continuación, la base de datos se puede dividir una fila en una tabla organizada por índices de lo siguiente:• La entrada de índiceEsta parte contiene los valores de columna de todas las columnas de clave principal, una RowId físico que apunta a la parte desbordamiento de la fila y, opcionalmente, algunas de las columnas sin clave. Esta parte se almacena en el segmento de índice.• La parte de desbordamientoEsta 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 organizadasUn índice secundario es un índice en una tabla organizada por índices. En cierto sentido, es un índice en un índice. El índice secundario es un objeto de esquema independiente y se almacena por separado de la tabla organizada por índices. Como se explica en "Tipos de datos ROWID", Oracle Database utiliza identificadores de fila llamados ROWIDs lógicas para las tablas de índice organizadas. Un ROWID lógico es una representación codificada en base 64 de la clave primaria de tabla. La longitud ROWID lógico depende de la longitud de la clave primaria.

Las filas de bloques hoja de índice se pueden mover dentro o entre los bloques debido a inserciones. Las filas de las tablas de índice organizadas no migran como filas montón organizados hacen (véase "Las filas encadenadas y migradas"). Dado que las filas de las tablas de índice organizadas no tienen direcciones físicas permanentes, la base de datos utiliza ROWIDs lógicas basadas en la clave principal.Por ejemplo, supongamos que la tabla de departamentos es organizada por índices. La columna location_id almacena el ID de cada departamento. La tabla almacena las filas de la siguiente manera, con el último valor que el ID de la población:

10,Administration,200,170020,Marketing,201,180030,Purchasing,114,170040,Human Resources,203,2400

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

1700,*BAFAJqoCwR/+ 1700,*BAFAJqoCwQv+1800,*BAFAJqoCwRX+2400,*BAFAJqoCwSn+

Los índices secundarios proporcionan acceso rápido y eficiente a las tablas de índice organizadas con columnas que no son ni la clave principal ni un prefijo de la clave primaria. Por ejemplo, una

Page 45: UNIDAD4 ADMON

consulta de los nombres de los departamentos cuyo identificador es mayor que 1700 podrían usar el índice secundario para acelerar el acceso de datos.

ROWIDs conjeturas lógicas y físicas

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

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

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

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

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

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

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

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

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

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

Page 46: UNIDAD4 ADMON

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 también incluye la opción de compactar datos de objetos grandes. Los datos de objetos grandes son datos de tipo image, text, ntext, varchar(max), nvarchar(max), varbi-nary(max) o xml.La tarea Reorganizar índice encapsula la instrucción ALTER INDEX de Transact-SQL. Si elige com-pactar datos de objetos grandes, la instrucción utiliza la cláusula REORGANIZE WITH (LOB_COM-PACTION = ON); en caso contrario, se establece LOB_COMPACTION en OFFDentro 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 Con -sistencia, Copias de Seguridad o Compactación de las bases.Pero también es necesario ejecutar trabajos de mantenimiento cuyos objetivos sean el de mante-ner la performance de las bases de datos y evitar su degradación.Esos trabajos son la Reorganización de Índices y la Actualización de Estadísticas.Estos trabajos son independientes del estado de la base de datos. Puede ocurrir que a la base le falten estudios de optimización pero, al menos, mantendremos la performance actual.Si la base se encuentra optimizada, entonces más aún, son necesarios para evitar la degradación producto del uso continuo.Cualquiera de estos trabajos deben realizarse fuera de línea por motivos de: alto consumo de re-curso y bloqueo de las tablas en el momento de ejecución.Las tablas que contienen índices al ser actualizadas o por inserción de nuevos datos, generan fragmentación de estos índices. Estas fragmentaciones conllevan a la pérdida de performance al acceder a ellas.La instrucción DBCC DBREINDEX reorganiza el índice de una tabla o todos los índices definidos para una tabla. La reorganización de realiza dinámicamente sin necesidad de conocer la estructu-ra 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 además pertenece a algún índice, ya que la reorgani-zación no necesita eliminar y recrear éstas restricciones para realizar su trabajo.La sintaxis de esta instrucción es:DBCC DBREINDEX   (   ’basededatos.dueño.nombre_de_tabla‘             [ , índice               [ , fillfactor ]           ]   )   [ WITH NO_INFOMSGS ] Fillfactor es el porcentaje de espacio de página destinado a ser ocupado. El valor definido reem-plaza al que fue generado en el momento de la creación 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 ejecución.

Page 47: UNIDAD4 ADMON

No es necesario conocer los nombres de todos los índices de todas las tablas, ya que si utilizamos la instrucción de la siguiente forma:DBCC RBINDEX (Movimientos, ‘’, 0)Se reorganizarán todos los índices que contengan la tabla Movimientos, conservándose el fillfac-tor 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 periódica mediante un trabajo de man-tenimiento dentro de algún horario disponible.Por lo tanto, la recomendación será: elegir las tablas más accedidas y/o actualizadas, y reorgani-zarlas 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 pro-cedimientos se pueden encontrar en el Forum bajo el nombre de Tips, y la idea es generar un tra -bajo de mantenimiento que se ejecute, por ejemplo, en el fin de semana

4.4.3 Reconstruccion de indices

Es importante periódicamente examinar y determinar qué índices son susceptibles de ser recons-truidos. 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 pro -blemas de contención de disco o cuellos de botella en el sistema. Normalmente reconstruimos un Índice con el comando ALTER INDEX.Es importante tener actualizadas las estadísticas de la base de datos. Para saber si las estadísticas se están 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 estadísticas.

SELECT index_name, last_analyzedFROM dba_indexedWHERE table_owner=’nb_usuario’

Nota: Siendo nb_usuario el nombre del esquema del usuario para el que queramos validar las es -tadísticas. (Lanzar con usuario SYS)Para actualizar las estadísticas utilizamos el paquete DBM_STATS. Podemos actualizar las esta-dísticas 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 estadísticas de los Índices de la base de datos lanzamos la siguiente con -sulta:

SELECT index_name, blevel,DECODE(blevel,0,'OK BLEVEL',1,'OK BLEVEL',2,

Page 48: UNIDAD4 ADMON

'OK BLEVEL',3,'OK BLEVEL',4,'OK BLEVEL','BLEVEL HIGH') OKFROM dba_indexes where table_owner='Propietario';

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 HIGHLos Índices que deberíamos 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 número de veces que ORACLE ha tenido que reducir la búsqueda en ese Índice. Si este valor está por encima de 4 el Ín -dice 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 deberías de tener el privilegio alter any index. También tenemos que tener en cuenta que para realizar la reconstrucción de un Índice deberíamos de tener cuota suficiente sobre el ta -blespace que lo lanzamos.

Para reconstruir un Índice bastaría con lazar la siguiente sentencia:

ALTER INDEX <index_name> REBUILD;

Para reconstruir una partición de un Índice podríamos hacer lo siguiente

ALTER INDEX <index_name> REBUILD PARTITION <nb_partition> NOLOGGING;

Nota: En algunos casos cuando alguno de los Índices tiene algún tipo de corrupción no es posible reconstruirlo. La solución en este caso es borrar el Índice y recrearlo.http://www.itescam.edu.mx/principal/webalumnos/sylabus/asignatura.php?clave_asig=SCB-1001&carrera=ISIC-2010-224&id_d=136