4.1 Bitácoras de Trabajo del DBMS
Una bitácora (log) es una herramienta (archivos o registros) que permite registrar, analizar, detectar y notificar eventos que sucedan en cualquier sistema de información utilizado en las organizaciones.
La estructura más amplia-mente usada para grabar las acciones que se llevan en la base de datos.
Nos ayuda a recuperar la información ante algunos incidentes de seguridad, detección de comportamiento inusual, información para resolver problemas, evidencia legal, es de gran ayuda en las tareas de computo forense.
Permite guardar las transacciones realizadas sobre una base de datos en específico, de tal manera que estas transacciones puedan ser auditadas y analizadas posteriormente.
Pueden obtenerse datos específicos de la transacción como:
1. Operación que se realizó
2. Usuario de BD
3. Fecha
4. Máquina
5. Programa
6. Tipo de conexión
7. Estado
No se requiere hacer cambios en los sistemas de producción o de desarrollo o en una simple instalación para la implementación de la bitácora.
A través de la parametrización se generan las pantallas de consulta y reportes sin necesidad de programar.
Acceso a la bitácora a través de una aplicación Web.
Control de Acceso a la información de la bitácora a través de Roles.
Se puede implementar en los sistemas de información que utilicen las principales bases de datos: Oracle, SQL Server, Informix, Sybase.
Permite hacer el seguimiento de todos los cambios que ha tenido un registro.
4.1.1. Funciones especifica de las bitacoras.
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 Transaccion
Ø 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 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 bloqueados. Es importante advertir que COMMIT y ROLLBACK terminan las transacción, no el programa.
4.1.2 Recuperacion rollback
En tecnologías de base de datos, un rollback es una operación que devuelve a la base de datos a algún estado previo. Los Rollbacks son importantes para la integridad de la base de datos, a causa de que significan que la base de datos puede ser restaurada a una copia limpia incluso después de que se han realizado operaciones erróneas. Son cruciales para la recuperación de crashes de un servidor de base de datos; realizando rollback(devuelto) cualquier transacción que estuviera activa en el tiempo del crash, la base de datos es restaurada a un estado consistente.
En SQL, ROLLBACK es un comando que causa que todos los cambios de datos desde la última sentencia BEGIN WORK, o START TRANSACTION sean descartados por el sistema de gestión de base de datos relacional (RDBMS), para que el estado de los datos sea "rolled back"(devuelto) a la forma en que estaba antes de que aquellos cambios tuvieran lugar.
Una sentencia ROLLBACK también publicará cualquier savepoint existente que puediera estar en uso.
En muchos dialectos de SQL, ROLLBACKs son específicos de la conexión. Esto significa que si se hicieron dos conexiones a la misma base de datos, un ROLLBACK hecho sobre una conexión no afectará a cualesquiera otras conexiones. Esto es vital para el buen funcionamiento de la Concurrencia.
La funcionalidad de rollback está normalmente implementada con un Log de transacciones, pero puede también estar implementada mediante control de concurrencia multiversión.
En el proceso de “Rollback”, SQL Server comienza a hacer un rollback de todas las transacciones que no fueron confirmadas además de las que fueron rechazadas, dejando de esta manera la base de datos en un estado consistente.
Este proceso de recuperación en algunos casos puede tardar mucho tiempo debido a la gran cantidad de información que tienen que replicar desde el log de transacciones. Es por eso que la frecuencia con la que se hacen los checkpoints dentro de la base de datos es crucial para el tiempo que tardara el servidor en ejecutar el proceso de recuperación.
Adicionalmente cabe mencionar que en algunas pocas ocasiones el terminar el servicio de SQL Server de manera inesperada puede causar corrupciones de datos, y esto sí es grave debido a que en algunos casos puede ser recuperable la información, pero siempre con un riesgo de perder algo de data, y en otros no es posible arreglar la base de datos, entonces lo único que queda en estas situaciones es la restauración de backups y es ahí donde si se tiene una buena estrategia de backups se puede llegar a recuperar absolutamente toda la información hasta el momento del desastre.
4.1.3 Permanencia commit
En cualquier momento, el programa podría decidir que es necesario hacer fallar la transacción, con lo que el sistema deberá revertir todos los cambios hechos por las operaciones ya hechas. En el lenguaje SQL se denomina COMMIT a aplicar_cambios y ROLLBACK a cancelar_cambios.
Las transacciones suelen verse implementadas en sistemas de bases de datos y, más recientemente, se han visto incorporadas a como gestiona un sistema operativo la interacción con un sistema de archivos (como varias características de las bases de datos, debido a que son muy similares arquitectónicamente).
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.
En términos de transacciones, lo opuesto de commit para descartar los cambios "en tentativa" de una transacción, es un rollback.
4.2 Definicion de los modos de operacion de un DBMS. (alta, baja, recovery)
El sistema de gestión de bases de datos es esencial para el adecuado funcionamiento y manipulación de los datos contenidos en la base. Se puede definir como: "El Conjunto de programas, procedimientos, lenguajes, etc. que suministra, tanto a los usuarios no informáticos como a los analistas, programadores o al administrador, los medios necesarios para describir, recuperar y manipular los datos almacenados en la base, manteniendo su integridad, confidencialidad y seguridad".
Las funciones esenciales de un SGDB son la descripción, manipulación y utilización de los datos.
Descripción: Incluye la descripción de: Los elementos de datos, su estructura, sus interrelaciones, sus validaciones. Tanto a nivel externo como lógico global e interno esta descripción es realizada mediante un LDD o Lenguaje de Descripción de Datos.
Manipulación: Permite: Buscar, Añadir, Suprimir y Modificar los datos contenidos en la Base de Datos.
La manipulación misma supone: Definir un criterio de selección, Definir la estructura lógica a recuperar, Acceder a la estructura física. Esta manipulación es realizada mediante un LMD o Lenguaje de Manipulación de Datos.
Utilización: La utilización permite acceder a la base de datos, no a nivel de datos sino a la base como tal, para lo cual: Reúne las interfaces de los usuarios y suministra procedimientos para el administrador.
En términos ideales, un DBMS debe contar con estas funciones, sin embargo, no todos las poseen, así existen algunos manejadores que no cumplen la función de respaldo o de seguridad, dejándola al usuario o administrador; sin embargo un DBMS que sea completo y que deba manejar una base de datos multiusuario grande, es conveniente que cuente con todas estas operaciones.
4.3 Comandos de activacion de los modos de operacion
Los índices son "estructuras" alternativa a la organización de los datos en una tabla. El propósito de los índices es acelerar el acceso a los datos mediante operaciones físicas más rápidas y efectivas. Para entender mejor la importancia de un índice pongamos un ejemplo; imagínate que tienes delante las páginas amarillas, y deseas buscar el teléfono de Manuel Salazar que vive en Alicante. Lo que harás será buscar en ese pesado libro la población Alicante, y guiándote por la cabecera de las páginas buscarás los apellidos que empiezan por S de Salazar. De esa forma localizarás más rápido el apellido Salazar. Pues bien, enhorabuena, has estado usando un índice.
4.4. Manejo de indices
En MySQL se tienen dos tipos de índices, los cuales son:
Índices agrupados
Los índices agrupados, definen el orden en que almacenan las filas de la tabla (nodos hoja/página de datos de la imagen anterior). La clave del índice agrupado es el elemento clave para esta ordenación; el índice agrupado se implementa como una estructura de árbol b que ayuda a que la recuperación de las filas a partir de los valores de las claves del índice agrupado sea más rápida. Las páginas de cada nivel del índice, incluidas las páginas de datos del nivel hoja, se vinculan en una lista con vínculos dobles. Además, el desplazamiento de un nivel a otro se produce recorriendo los valores de claves.
Consideraciones para usar índices agrupados
Ø Columnas selectivas
Ø columnas afectadas en consultas
Ø Columnas accedidas "secuencialmente"
Ø Columnas implicadas en JOIN, GROUP BY
Ø Acceso muy rápido a filas: lookups
Indices no agrupados
Los índices no agrupados tienen la misma estructura de árbol b que los índices agrupados, con algunos matices; como hemos visto antes, en los índices agrupados, en el último nivel del índice (nivel de hoja) están los datos; en los índices no-agrupados, en el nivel de hoja del índice, hay un puntero a la localización física de la fila correspondiente en el índice agrupado. Además, la ordenación de las filas del índice está construida en base a la(s) columna(s) indexadas, lo cual no quiere decir (a diferencia de los índices agrupados), que la organización física de las páginas de datos corresponda con el índice.
4.4.1 Tipos de Indices
Un índice es una estructura opcional, asociado con una mesa o tabla de clúster, que a veces puede acelerar el acceso de datos. Mediante la creación de un índice en una o varias columnas de una tabla, se obtiene la capacidad en algunos casos, para recuperar un pequeño conjunto de filas distribuidas al azar de la tabla. Los índices son una de las muchas formas de reducir el disco I / O.
Si una tabla de montón organizado no tiene índices, entonces la base de datos debe realizar un escaneo completo de tabla para encontrar un valor. Por ejemplo, sin un índice, una consulta de ubicación 2700 en la tabla hr.departments requiere la base de datos para buscar todas las filas de cada bloque de la tabla para este valor. Este enfoque no escala bien como datos de aumento de volúmenes.
Por analogía, supongamos que un gerente de Recursos Humanos tiene un estante de cajas de cartón. Las carpetas que contienen información de los empleados se insertan aleatoriamente en las cajas. La carpeta de empleado Whalen (ID 200) es de 10 carpetas desde el fondo de la caja 1, mientras que la carpeta para el rey (ID 100) se encuentra en la parte inferior del cuadro 3. Para localizar una carpeta, el gestor busca en cada carpeta en la casilla 1 de abajo hacia arriba, y luego se mueve de una casilla a otra hasta que se encuentra la carpeta. Para acelerar el acceso, el administrador puede crear un índice que enumera de forma secuencial todos los ID de empleado con su ubicación de la carpeta:
ID 100: Box 3, position 1 (bottom)
ID 101: Box 7, position 8
ID 200: Box 1, position 10
Del mismo modo, el administrador podría crear índices separados para los últimos nombres de los empleados, los ID de departamento, y así sucesivamente. En general, considerar la creación de un índice en una columna en cualquiera de las siguientes situaciones:
· Las columnas indizadas se consultan con frecuencia y devuelven un pequeño porcentaje del número total de filas en la tabla.
· Existe una restricción de integridad referencial en la columna o columnas indexadas. El índice es un medio para evitar un bloqueo de tabla completa que de otro modo se requeriría si se actualiza la clave principal de la tabla principal, se funden en la tabla principal, o eliminar de la tabla primaria.
· Una restricción de clave única se coloca sobre la mesa y desea especificar manualmente el índice de todas las opciones sobre índices y.
Características de Indexación
Los índices son objetos de esquema que son lógica y físicamente independiente de los datos de los objetos con los que están asociados. Por lo tanto, un índice se puede quitar o creado sin afectar físicamente a la tabla para el índice.
Nota: Si se le cae un índice, las aplicaciones siguen funcionando. Sin embargo, el acceso de los datos previamente indexado puede ser más lento.
La ausencia o presencia de un índice no requiere un cambio en el texto de cualquier sentencia SQL. Un índice es una ruta de acceso rápido a una sola fila de datos. Sólo afecta a la velocidad de ejecución. Dado un valor de datos que se ha indexado, el índice apunta directamente a la ubicación de las filas que contienen ese valor.
La base de datos mantiene automáticamente y utiliza los índices después de su creación. La base de datos también refleja automáticamente los cambios en los datos, como agregar, actualizar y eliminar filas, en todos los índices pertinentes sin acciones adicionales requeridas por los usuarios. Rendimiento de recuperación de datos indexados permanece casi constante, incluso cuando se insertan filas. Sin embargo, la presencia de muchos índices en una tabla degrada el rendimiento DML porque la base de datos también debe actualizar los índices.
Los índices tienen las siguientes propiedades:
· Facilidad de Uso
Los índices son utilizables (por defecto) o inutilizable. Un índice inutilizables no se mantiene por las operaciones DML y es ignorado por el optimizador. Un índice inutilizable puede mejorar el rendimiento de las cargas a granel. En lugar de dejar un índice y luego volverlo a crear, puede hacer que el índice inservible y luego reconstruirlo. Índices inutilizables y las particiones de índice no consumen espacio. Cuando usted hace un índice utilizable no utilizable, la base de datos cae su segmento de índice.
· Visibilidad
Los índices son visibles (por defecto) o invisible. Un índice invisible se mantiene por las operaciones DML y no se utiliza de forma predeterminada por el optimizador. Cómo hacer una invisible índice es una alternativa a lo que es inutilizable o se caiga. Índices invisibles son especialmente útiles para probar la eliminación de un índice antes de dejarlo caer o mediante índices temporalmente sin afectar a la aplicación general.
Guía del Administrador para Aprender a Manejar los Índices
· Base de datos Oracle Performance Tuning Guide para aprender cómo ajustar los índices
Teclas y Columnas
Una clave es un conjunto de columnas o expresiones en las que se puede construir un índice. Aunque los términos se usan indistintamente, los índices y las claves son diferentes. Los índices son estructuras almacenados en la base de datos que los usuarios a administrar el uso de sentencias de SQL. Las claves son estrictamente un concepto lógico.
La siguiente sentencia crea un índice en la columna customer_id de la muestra oe.orders tabla:
CREATE INDEX ord_customer_ix ON orders (customer_id);
En la declaración anterior, la columna customer_id es la clave de índice. El índice en sí se llama ord_customer_ix.
Índices Compuestos
Un índice compuesto, también llamado índice concatenado, es un índice de varias columnas de una tabla. Las columnas de un índice compuesto que deben aparecer en el orden que tenga más sentido para las consultas que recuperar datos y no necesita ser adyacente en la tabla.
Los índices compuestos pueden acelerar la recuperación de datos para las instrucciones SELECT en la que el DONDE referencias cláusula totalidad o la parte principal de las columnas en el índice compuesto. Por lo tanto, el orden de las columnas utilizadas en la definición es importante. En general, las columnas de acceso más común van primero.
Por ejemplo, supongamos que una aplicación realiza consultas frecuentes a apellidos, job_id, y columnas de salario en la tabla empleados. También asumir que last_name tiene alta cardinalidad, lo que significa que el número de valores distintos que es grande en comparación con el número de filas de la tabla. Se crea un índice con el siguiente orden de las columnas:
CREATE INDEX employees_ix
ON employees (last_name, job_id, salary);
Las consultas que acceden a las tres columnas, sólo la columna last_name, o sólo el last_name y columnas job_id utilizan este índice. En este ejemplo, las consultas que no tienen acceso a la columna last_name no utilizan el índice.
Nota: En algunos casos, tales como cuando la columna principal tiene muy baja cardinalidad, la base de datos puede utilizar una búsqueda selectiva de este índice.
Múltiples índices pueden existir para la misma mesa, siempre y cuando la permutación de columnas difiere para cada índice. Puede crear varios índices que utilizan las mismas columnas si se especifica claramente diferentes permutaciones de las columnas. Por ejemplo, las siguientes sentencias SQL especifican permutaciones válidas:
CREATE INDEX employee_idx1 ON employees (last_name, job_id);
CREATE INDEX employee_idx2 ON employees (job_id, last_name);
Índices Únicos y no Únicos
Los índices pueden ser únicos o no únicos. Índices únicos garantizar que no hay dos filas de una tabla tienen valores duplicados en la columna de clave o columna. Por ejemplo, dos empleados no pueden tener el mismo ID de empleado. Por lo tanto, en un índice único, existe una ROWID para cada valor de datos. Los datos de los bloques de hojas se ordenan sólo por clave.
Índices no únicas permiten valores duplicados en la columna o columnas indexadas. Por ejemplo, la columna 'nombre de la tabla de empleados puede contener varios valores Mike. Para un índice no único, el ROWID se incluye en la clave de forma ordenada, por lo que los índices no únicos se ordenan por la clave de índice y ROWID (ascendente).
Oracle Database no filas de la tabla de índice en el que todas las columnas clave son nulas, a excepción de los índices de mapa de bits o cuando el valor de la columna clave de clúster es nulo.
Tipos de Índices
Base de Datos Oracle ofrece varias combinaciones de indexación, que proporcionan una funcionalidad complementaria sobre el rendimiento. Los índices se pueden clasificar de la siguiente manera:
· Los Índices de Árbol B
Estos índices son el tipo de índice estándar. Son excelentes para la clave principal y los índices altamente selectivos. Utilizado como índices concatenados, B-tree índice pueden recuperar los datos ordenados por las columnas de índice. Índices B-tree tienen los siguientes subtipos:
· Índice de Tablas Organizadas
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.
· Índices Descendentes
Este tipo de índice almacena los datos en una columna o columnas de concreto en orden descendente.
· Í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.
· 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".
· Índices Basados en Funciones
Este tipo de índice incluye columnas que, o bien se transforman por una función, tales como la función UPPER, o incluidos en una expresión. Índices B-tree o mapa de bits puede ser basado en las funciones.
· Í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ísico 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".
· Í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.
4.4.2 Reorganizacion de indices
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), varbinary(max) o xml.
La tarea Reorganizar índice encapsula la instrucción ALTER INDEX de Transact-SQL. Si elige compactar datos de objetos grandes, la instrucción utiliza la cláusula REORGANIZE WITH (LOB_COMPACTION = ON); en caso contrario, se establece LOB_COMPACTION en OFF
Dentro de las tareas habituales de Mantenimiento de las Bases de Datos se encuentran aquellas destinadas al control y respaldo de las mismas como ser: Control de Integridad, Chequeo de Consistencia, Copias de Seguridad o Compactación de las bases.
Pero también es necesario ejecutar trabajos de mantenimiento cuyos objetivos sean el de mantener 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 recurso 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 estructura de la misma o las restricciones que ella tenga. Por lo tanto no es necesario conocer si una tabla tiene clave primaria o si esta clave es única y además pertenece a algún índice, ya que la reorganizació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 reemplaza 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.
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 fillfactor original de cada índice en particular.
Una de las formas de utilizarlo es, escribir un script con una sentencia DBCC RBINDEX por cada tabla que necesitemos reorganizar y agendarlas en forma periódica mediante un trabajo de mantenimiento dentro de algún horario disponible.
Por lo tanto, la recomendación será: elegir las tablas más accedidas y/o actualizadas, y reorganizarlas una vez entre semana. Para reorganizar todas las tablas que contengan índices se utiliza el mismo concepto, pero dentro de un procedimiento que recorra todas la tablas de la base y las reorganice, sin necesidad que escribamos todas la tablas que contiene la base de datos. Estos procedimientos se pueden encontrar en el Forum bajo el nombre de Tips, y la idea es generar un trabajo de mantenimiento que se ejecute, por ejemplo, en el fin de semana
4.4.3 Reconstruccion de indices
Es importante periódicamente examinar y determinar qué índices son susceptibles de ser reconstruidos. Cuando un Índice está descompensado puede ser porque algunas partes de Éste han sido accedidas con mayor frecuencia que otras. Como resultado de este suceso podemos obtener problemas de 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_analyzed FROM dba_indexed WHERE table_owner=’nb_usuario’
Nota: Siendo nb_usuario el nombre del esquema del usuario para el que queramos validar las estadísticas. (Lanzar con usuario SYS)
Para actualizar las estadísticas utilizamos el paquete DBM_STATS. Podemos actualizar las estadí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 consulta:
SELECT index_name, blevel, DECODE(blevel,0,'OK BLEVEL',1,'OK BLEVEL',2, 'OK BLEVEL',3,'OK BLEVEL',4,'OK BLEVEL','BLEVEL HIGH') OK FROM 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 HIGH
Los Í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 Índice deberá de ser reconstruido.
Comando ALTER INDEX
Como hemos comentado esta sentencia se utiliza para cambiar o reconstruir un Índice existente en la base de datos.
Para poder ejecutar este comando el Índice debe de estar en el propio esquema donde intentes ejecutarlo o 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 tablespace que lo lanzamos.
Para reconstruir un Índice bastaría con lazar la siguiente sentencia:
ALTER INDEX REBUILD;
Para reconstruir una partición de un Índice podríamos hacer lo siguiente
ALTER INDEX REBUILD 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.
