Unidad 3:
Configuración y Administración del Espacio en Disco
3.1
Estructuras Lógicas de Almacenamiento
Para la gestión
del almacenamiento de una base de datos existen 4 conceptos bien definidos que
deben ser conocidos para poder comprender la forma en la que se almacenan los
datos. Vamos a ver la diferencia entre bloque, extensión, segmento y espacio de
tablas.
Bloques: Se
tratan de la unidad más pequeña. Generalmente debe múltiple del tamaño de
bloque del sistema operativo, ya que es la unidad mínima que va a pedir Oracle
al sistema operativo. Si no fuera múltiple del bloque del sistema se añadiría
un trabajo extra ya que el sistema debería obtener más datos de los
estrictamente necesarios.
Extensiones: Se forma con uno o más bloques.
Cuando se aumenta tamaño de un objeto se usa una extensión para incrementar el
espacio.
Segmentos: Grupo de extensiones que forman un
objeto de la base de datos, como por ejemplo una tabla o un índice.
Espacio de
Tablas: Formado por
uno o más datafiles, cada datafile solo puede pertenecer a un determinado
tablespace
En general, el
almacenamiento de los objetos de la base de datos (tablas e índices
fundamentalmente) no se realiza sobre el archivo o archivos físicos de la base
de datos, sino que se hace a través de estructuras lógicas de almacenamiento
que tienen por debajo a esos archivos físicos, y que independizan por tanto las
sentencias de creación de objetos de las estructuras físicas de almacenamiento.
3.1.1
Definición de Almacenamiento de Bases de Datos
Las bases de
datos suelen ser creadas para almacenar grandes cantidades de datos de forma
permanente. Por lo general, los datos almacenados en éstas suelen ser
consultados y actualizados constantemente.
La mayoría de las
bases de datos se almacenan en las llamadas memorias secundarias, especialmente
discos duros, aunque, en principio, pueden emplearse también discos ópticos,
memorias flash, etc.
· En general, las
bases de datos son demasiado grandes para entrar en la memoria primaria.
· La memoria
secundaria suele ser más barata que la memoria primaria (aunque esta última
tiene mayor velocidad).
· La memoria
secundaria es más útil para el almacenamiento de datos permanente, puesto que
la memoria primaria es volátil.
3.1.2.-
Definición y Creación del Espacio Asignado para cada Base de Datos
Las bases de
datos se almacenan en ficheros o archivos. Existen diferentes formas de
organizaciones primarias de archivos que determinan la forma en que los
registros de un archivo se colocan físicamente en el disco y, por lo tanto,
cómo se accede a éstos.
Las distintas
formas de organizaciones primarias de archivos son:
· Archivos
de Montículos (o no Ordenados): esta técnica coloca los registros en
el disco sin un orden específico, añadiendo nuevos registros al final del
archivo.
· Archivos
Ordenados (o Secuenciales):mantiene el orden de los registros con respecto
a algún valor de algún campo (clave de ordenación).
· Archivos
de Direccionamiento Calculado: utilizan una función de direccionamiento
calculado aplicada a un campo específico para determinar la colocación de los
registros en disco.
· Árboles
B: se vale de la estructura de árbol para las colocaciones de
registros.
· Organización
Secundaria o Estructura de Acceso Auxiliar: Estas permiten que los
accesos a los registros de un archivo basado en campos alternativos, sean más
eficientes que los que han sido utilizados para la organización primaria de
archivos.
El DBMS asigna
espacio de almacenamiento a las bases de datos cuando los usuarios introducen
create database o alter database. El primero de los comandos puede especificar
uno o más dispositivos de base de datos, junto con la cantidad de espacio en
cada uno de ellos que será asignado a la nueva base de datos.
3.1.3.- Bitácoras
Son estructuras
ampliamente utilizadas para grabar las modificaciones de la base de datos.
Cada registro de
la bitácora escribe una única escritura de base de datos y tiene lo siguiente:
· Nombre
de la Transacción: Nombre de la transacción que realizó la operación
de escritura.
· Nombre
del Dato: El nombre único del dato escrito.
· Valor
Antiguo: El valor del dato antes de la escritura.
· Valor
Nuevo: El valor que tendrá el dato después de la escritura.
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.
La instrucción en
MySQL para crear una bitácora en .txt se crea antes de acceder a la base de
datos con la instrucción:
"xampp>mysql>bin>mysql
-hlocalhost -uroot --tee=C:bitacora.txt"
La bitácora debe
registrar todos los movimientos (insertar, eliminar y modificar) que se
realicen en las tablas de la base de datos. Para lograr lo anterior es
necesario crear un trigger para que se ejecute después de la operación de
insertar, otro para después de eliminar y el último para después de modificar
para cada una de las 3 tablas de la base de datos.
3.1.4
Particiones
Una
partición es una división de una base de datos lógica o sus elementos
constituyentes en partes independientes. La partición de bases de datos se hace
normalmente por razones de mantenimiento, rendimiento o manejo.
Una
aplicación popular y favorable es en un Sistema de Administración de Base de
Datos Distribuida. Cada partición puede ser extendida hasta múltiples nodos, y
los usuarios en el nodo pueden hacer transacciones locales en la partición.
Esto aumenta el rendimiento en sitios que tienen transacciones regularmente
involucrando ciertas vistas de datos, y manteniendo la disponibilidad y la
seguridad.
Esta
partición puede hacerse creando bases de datos más pequeñas separadas (cada una
con sus propias tablas, índices, y registros de transacciones) o dividiendo
elementos seleccionados, por ejemplo, solo una tabla.
3.1.5 Espacios privados
Un «espacio
privado» permite que los administradores y redactores gestionen el conjunto de
datos del sitio. Algunas bases de datos tienen estos espacios privados llamados
comúnmente paneles de control, que son formularios que aparecen al abrir la
base de datos.
Los paneles
de control sirven de "puerta principal" o "recibidor" de
una base de datos en el sentido de que dirigen a las personas hacia
determinadas tareas, como introducir o buscar datos. Sirven también para
mantener alejados a los usuarios de las tablas que contienen los datos en
tiempo real.
Cuando
reciba una base de datos, debe adentrarse más allá del panel de control para
averiguar cómo están estructurados los datos, pero merece la pena echar un
vistazo inicial al panel de control. Le puede ofrecer algún indicio sobre las
tareas que el diseñador de la base de datos consideró que realizarían los
usuarios habitualmente con los datos.
Puede hacer
clic en los vínculos del panel de control para ver qué objetos, como
formularios e informes, abren.
3.1.6.- Espacios para Objetos
El rendimiento de la base de datos depende de la entrada y salida a disco. La cantidad de datos almacenados es mayor que nunca antes, y los datos son almacenados por más tiempo.
Algunos DBMS permiten al tamaño de los archivos temporales de expandirse y contraerse de forma automática. Dependiendo del tipo y la naturaleza de las operaciones de base de datos en proceso, esta fluctuación puede provocar picos de uso del disco.
Hay muchos problemas de almacenamiento que deben ser resueltos antes de que un DBA pueda crear una base de datos. Uno de los temas más importantes es la cantidad de espacio para permitir la base de datos.
El cálculo espacial debe tener en cuenta no sólo tablas, índices, sino también, y dependiendo del DBMS, el registro de transacciones. Cada una de estas entidades probablemente requerirá un archivo separado o conjunto de datos, para el almacenamiento persistente.
El DBA debe separar en diferentes discos a los archivos para:
·
Mejorar el rendimiento
·
Separar índices de datos
- Aislar los logros en otro disco
3.2. Segmentos
Un
segmento contiene un tipo específico de objetos de la base de datos, como
por ejemplo una tabla. Un segmento está compuesto de extensiones que definen el
tamaño disponible para el segmento. A medida que se llenan las extensiones se
van añadiendo nuevas extensiones, es aquel espacio reservado por la base de
datos, dentro de un datafile, para ser utilizado por un solo objeto. Así una
tabla (o cualquier otro objeto) está dentro de su segmento, y nunca podrá salir
de él, ya que si la tabla crece, el segmento también crece con ella.
Físicamente
todo objeto en base de datos no es más que un segmento dentro de un datafile.
Se puede decir que, un segmento es a un objeto de base de datos, lo que un
datafile a un tablespace; el segmento es la representación física del objeto en
base de datos (el objeto es solo una definición lógica).
Los
segmentos son los equivalentes físicos de los objetos que almacenan datos. El
uso efectivo de los segmentos requiere que el DBA conozca los objetos, que
utiliza una aplicación, cómo los datos son introducidos en esos objetos y el
modo en que serán recuperados.
Un segmento
está constituido por secciones llamadas extensiones, que son conjuntos
contiguos de bloques. Una vez que una extensión existente en un segmento no
puede almacenar más datos, el segmento obtendrá del espacio de tabla otra
extensión. Este proceso de extensión continuará hasta que no quede más espacio
disponible en los ficheros del espacio de tablas, o hasta que se alcance un
número máximo de extensiones por segmento.
Existen 5
tipos de segmento:
Ø •De
datos.
Ø •De
índices.
Ø •De
rollback.
Ø
•Temporales.
Ø •De bootstrap.
3.3. Memoria
Compartida.
La memoria compartida contiene todos los datos intervenidos,
como:
Ø Grupo de memorias
intermedias
Ø Tabla de bloqueos
Ø Memoria intermedia
del registro, que contiene las entradas del registro que esperan a ser volcadas
en el almacenamiento estable
Ø Planes de consulta
en caché, que se pueden reutilizar si se envía de nuevo la misma consulta
La exclusión mutua se puede implementar por medio de
funciones del sistema operativo llamadas semáforos. Implementaciones
alternativas, con menos sobrecargas, utilizan instrucciones atómicas especiales
soportadas por el hardware de la computadora; un tipo de instrucción atómica
comprueba una posición de la memoria y la establece a uno automáticamente. Los
mecanismos de exclusión mutua también se utilizan para implementar pestillos.
3.4. Instancias
múltiples
Se llama instancia múltiple al hecho de poder ejecutar un
programa más de una vez al mismo tiempo. Hay programas que no admiten más que
una sola instancia, es decir que si ya se está ejecutando, por más que lo
cliquees de nuevo en el icono o en el menú no aparecerá un nuevo ejemplar del
programa. Con las bases de datos se complica un poco porque si un usuario
modifica un registro que otro usuario tiene también abierto, la modificación
que se haga en una instancia debe reflejarse de inmediato (actualizarse) en
cualquier otra instancia abierta de la misma base de datos.
Sin embargo, en las bases de datos se puede seleccionar la
opción en el diseño de la BD, y se reflejarán de inmediato las modificaciones
en todas las instancias abiertas
En programación, una instancia se produce con la creación de
un objeto perteneciente a una clase (se dice que se instancia la clase). El
objeto que se crea tiene los atributos, propiedades y métodos de la clase a la
que pertenece. Los objetos y sus características se usan en la construcción de
programas, ya sea como contenedores de datos o como partes funcionales del
programa. Los objetos también puede ser ocurrencia de las clases.
4.1 Bitacoras 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
Específicas 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 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
Recuperación (rollback)
Rollback señala el término no exitoso de la transacción. Le
dice al manejador de transacciones que algo salió mal, que la base de datos
podría estar en un estado inconsistente y que todas las modificaciones deben
retroceder o anularse.
Si una transacción falla, por alguna razón, después de la
actualización de la base de datos es necesario “anularla” (rollback o UNDO).
Cualquier valor del data ítem que haya sido cambiado por la transacción debe
volver a su valor previo
Si una transacción T es anulada (rollback), cualquier
transacción S, que es en ínterin, haya leído un valor de un data ítem X
modificado por T, entonces S también debe anularse (rollback)
De igual forma, si una transacción R ha leído un valor de un
data ítem Y que ha sido modificado por S, entonces R también se debe anular y
así sucesivamente.
Este fenómeno se conoce como rollback en cascada. El rollback
en cascada puede ser muy costoso y es por ello que los mecanismos de recovery
han catalogado a este fenómeno como indeseable o nunca requerido
Uso de
rollback
4.1.3
Permanencia (commit)
Commit(acción de comprometer) se refiere a la idea de guardar
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 y pone
visibles todos los cambios a otros usuarios. El formato general es emitir una
sentencia BEGIN WORK, una o mas sentencias SQL, y entonces la sentencia COMMIT.
Alternativamente, una sentencia ROLLBACK se puede emitir, la cual deshace todo
el trabajo realizado desde que se emitio BEGIN WORK. Una sentencia COMMIT
publicara cualquiera de los savepoints existentes que puedan estar en uso.
En términos de transacciones, lo opuesto de commit para
descartar cambios “en tentativa” de una transacción, es un rollback.
4.2 Definición de los modos de operación de un DBMS. (Alta, baja, recovery)
Una operación de alta en un archivo consiste en la adición de un nuevo registro. En un archivo de empleados, un alta consistirá en introducir los datos de un nuevo empleado. Para situar correctamente un alta, se deberá conocer la posición donde se desea almacenar el registro correspondiente: al principio, en el interior o al final de un archivo.
El algoritmo de ALTAS debe contemplar la comprobación de que el registro a dar de alta no existe previamente. Una baja es la acción de eliminar un registro de un archivo. La baja de un registro puede ser lógica o física. Una baja lógica supone el no borrado del registro en el archivo.
Altas
La operación de dar de alta un determinado registro es similar a la de añadir datos a un archivo. Es importante remarcar que en un archivo secuencial sólo permite añadir datos al final del mismo.
En otro caso, si se quiere insertar un registro en medio de los ya presentes en el archivo, sería necesaria la creación nueva del archivo.
Bajas
Existen dos métodos para dar de baja a un registro en un archivo secuencial, donde no es fácil eliminar un registro situado en el interior de una secuencia: Para ello podemos seguir dos métodos:
1) Utilizar y por tanto crear un segundo archivo auxiliar transitorio, también secuencial, copia del que se trata de actualizar. Se lee el archivo completo registro a registro y en función de su lectura se decide si el registro se debe dar de baja o no. En caso afirmativo, se omite la escritura en el archivo auxiliar. Si el registro no se va a dar de baja, este registro se reescribe en el archivo auxiliar
Tras terminar la lectura del archivo original, se tendrán dos archivos: original (o maestro) y auxiliar. El proceso de bajas del archivo concluye borrando el archivo original y cambiando el nombre del archivo auxiliar por el del inicial.
2) Guardar o señalar los registros que se desean dar de baja con un indicador o bandera que se guarda en un array; de esta forma los registros no son borrados físicamente, sino que son considerados como inexistentes.
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.
Algunas de las situaciones en las que se recomienda tener este respaldo de datos pueden ser alguna de las siguientes:
· De protección de datos
· Fallas de medios
· Errores de los usuarios
· Errores de la aplicación
· Transferencia de datos
4.3 Comandos de Activación para los
Modos de Operación
Para ser uso
de los diferentes comandos para un modo de operación debemos estar como
administrador o asuma un rol que incluya el perfil de derechos Service
Management.
Comando STARTUP
Para el
arranque de una base de datos hay tres fases de arranque, para realizar estas
fases podemos utilizar startup más un comando, las tres fases son las
siguientes:
·
Fase
de no montaje: startup nomount
·
Fase de montaje: start mount, alter
database mount.
·
Fase de aperture: startup open.
Comando
shutdown
El comando
shutdown lo utilizamos para parar una base de datos la cual consiste en varias
clausulas
·
Shutdown
normal
·
Shutdown
immediate
·
Shutdown
transactional
·
Shutdown
abort.
Comando describe
Este comando
permite conocer la estructura de una tabla, columnas que la forman y su tipo y
restricciones.
Comando SHOW
TABLES Y SHOW CREATE TABLE
El comando SHOW
TABLES muestra las tablas dentro de una base de datos y SHOW CREATE TABLES
muestra la estructura de creación de una tabla.
Comandos de modificación
Para
realizar una modificación utilizamos el comando ALTER TABLE. Para usar ALTER
TABLE, necesitamos permisos ALTER, INSERT y CREATE para la tabla
4.4 Manejo de índices.
El índice de una base de datos es una estructura alternativa 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. En pocas palabras, se mejoran las operaciones gracias a un aumento de la velocidad, permitiendo un rápido acceso a los registros de una tabla en una base de datos.
4.4.1 Tipos de índices
Existen diferentes tipos de índices algunos de ellos son:
● Índices agrupados: Son los que definen el orden en que almacenan las filas de la tabla (nodos hoja/página de datos de la imagen anterior).
● Índices no agrupados: tienen la misma estructura de árbol b que los índices agrupados, con algunos matices.
● Índices compuestos: es un índice de varias columnas de una tabla.
● Índices descendientes: Este tipo de índice almacena los datos en una columna o columnas de concreto en orden descendente.
4.4.2 Reorganización 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.
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
● La Actualización de Estadísticas.
La instrucción DBCC DBREINDEX reorganiza el índice de una tabla o todos los índices definidos para una tabla. La sintaxis de esta instrucción es:
DBCC DBREINDEX (’basededatos.dueño.nombre_de_tabla‘[, índice [, fillfactor] ]) [ WITH NO_INFOMSGS ]
4.4.3 Reconstrucción de índices
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
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
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:
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;
Para reconstruir una partición de un Índice podríamos hacer lo siguiente
ALTER INDEX REBUILD PARTITION NOLOGGING;
