Manual del estudiante de Ingeniería en Sistemas de UTN/Bases de datos avanzadas/Los archivos de datos
- El DBA utiliza las tablespaces para
- Controlar la asignación del espacio de disco para la base de datos.
- Asignar quotas de espacio para cada usuario.
- Controlar disponibilidad de los datos a través de tablespaces online u offline.
- Realizar backup parcial o recuperación de base de datos.
- Asignar almacenamiento de datos a través de dispositivos para mejorar la performance.
- Un DBA puede
- Crear y eliminar tablespaces.
- Agregar archivos a las tablespaces.
- Designar o alterar los parámetros por omisión para los segmentos de almacenamiento creados en la tablespace.
- Hacer una tablespace solo-lectura o solo-escritura.
- Hacer una tablespace temporaria o permanente.
SYSTEM Tablespace
editarSe crea automáticamente junto con la creación de la base de datos. Contiene las tablas del diccionario de datos para toda la base. Oracle recomienda que se cree al menos una tablespace adicional para almacenar datos de usuario, separada de la información del diccionario de datos. Esto reduce la disputa entre los objetos del diccionario y los objetos esquema para los mismos archivos. La tablespace SYSTEM está siempre online cuando se abre la base. Todos los datos almacenados correspondientes a unidades de programas PL/SQL (procedimientos, funciones, paquetes y triggers) residen en la tablespace SYSTEM.
Asignar más espacio a una base de datos
editarSe puede ampliar una base de tres formas:
- Agregar un archivo a una tablespace.
ALTER TABLESPACE system ADD DATAFILE 'data2.ora'
- Agregar una tablespace nueva.
CREATE TABLESPACE users DATAFILE 'data2.ora'
- Incrementar el tamaño de un archivo de datos.
ALTER DATABASE DATAFILE 'data2.ora' AUTOEXTEND ON NEXT 20M MAXSIZE 1000m;
Se sugieren que cada base de datos tenga como mínimo 5 tablespaces además de SYSYEM:
- TEMP (para los datos temporarios que se generan en las consultas)
- RBS (rollback segments)
- TOOLS (para los Forms, Report Writer y Designer)
- APPL_DATA (para los applications data)
- APPL_INDX (para los applications index)
Las consideraciones por las que se sugieren estas divisiones son:
- Minimizar la fragmentación
- Minimizar la competencia por el disco
- Separar los segmentos
- Almacenar los archivos de datos
Los segmentos más propensos a la fragmentación son, en orden:
- TEMP
- RBSEGS
- INDICES
- TABLAS
- DICCIONARIO de DATOS
La competencia por el disco se puede minimizar separando los grupos de segmentos que pueden ser accedidos simultáneamente:
- Los segmentos del diccionario de datos y los demás segmentos.
- Los segmentos de rollback de los demás segmentos.
- Los segmentos de datos de sus correspondientes segmentos de índices.
Separar las tablas de acuerdo con sus características (necesidades de backup, requerimientos de acceso, necesidades de uso, crecimiento) deviene en ventajas en:
- Recuperación y backup
- Tamaño
- Seguridad
- Limpieza y claridad
Recomendaciones de Administración de los Archivos de Bases de Datos
- Mantener al menos dos copias activas de los archivos de control[1] de la base de datos en al menos dos dispositivos físicos diferentes.
- Mantener múltiples archivos de redo log y ubicarlos por grupos en diferentes discos.
- Separar los tablespaces que puedan competir por recursos en discos y ubicarlos en diferentes discos físicos.
Tablespaces Online y Offline
editarUn DBA puede poner cualquier tablespace (excepto la SYSTEM) de una base de datos Oracle online (accesible) u offline (inaccesible) siempre y cuando la base de datos esté abierta.
Colocar una tablespace offline puede ser necesario para:
- Hacer una porción de la base de datos inaccesible mientras permite acceso normalmente al resto.
- Realizar un backup de la tablespace offline.
- Hacer que una aplicación y su grupo de tablas temporalmente inaccesible mientras duren las tareas de actualización y mantenimiento.
La tablespace SYSTEM está necesariamente siempre online, porque allí reside el diccionario de datos, que Oracle necesita para funcionar.
No se puede llevar a una tablespace offline si contiene algún segmento de rollback que esté en uso.
Cuando una tablespace se pone offline, Oracle no permite que ninguna instrucción SQL referencie los objetos contenidos en esa tablespace.
Las transacciones activas no son afectadas por esto. Oracle guarda los datos de rollback correspondientes a aquellas sentencias en un segmento de rollback diferido (en la SYSTEM tablespace). Si es necesario cuando la tablespace se coloca online se aplican los rollbacks.
Cuando una tablespace se va a offline o vuelve a online, esto es registrado en el diccionario de datos. Así cuando se cierra una base, la tablespace permanece offline cuando la base sea reabierta o montada.
Una tablespace se puede llevar a online solo en la base en la cual fue creada, porque la información del diccionario de datos necesaria se mantiene en la SYSTEM.
Una tablespace offline no se puede leer ni editar por cualquier otra aplicación que no sea Oracle.
Las tablespaces no se pueden transferir de base a base.
Uso de las tablespaces para procedimientos especiales
editarSi dos tablespaces son usadas para separar datos de la tabla con los de índice pueden suceder dos cosas:
- Si la tablespace que contiene los índices está offline, las queries pueden aún acceder los datos de la tabla porque los queries no requieren un índice para acceder las tablas.
- Si la tablespace que contiene las tablas está offline, los datos en la base no son accesibles porque las tablas requieren acceder a los datos.
Tablespace de Solo-Lectura (Read-Only)
editarSu propósito es eliminar la necesidad de hacer backup y recuperación de porciones grandes y estáticas de una base. Los archivos de estos tablespaces pueden estar en un medio de solo-lectura.
Hacer una tablespace read-only no cambia su estado offline u online.
Para escribir se lo tiene que llevar a write-only con un comando ALTER TABLESPACE.
Se pueden suprimir ítems, tales como tablas o índices, desde una tablespace read-only, tal como se lo hace en una tablespace offline. Sin embargo, no se pueden ni crear ni modificar objetos. No se pueden añadir archivos, aún llevando la tablespace a offline.
Tablespaces temporarias
editarSe puede administrar espacio para operaciones de ordenamiento más eficientes a través del uso de tablespace temporarias exclusivas, para eliminar la serialización de la administración del espacio para operaciones de este tipo.
No pueden residir objetos permanentes en tablespace temporarias. Son útiles cuando se tienen múltiples operaciones de sort (joins, creación de índices, GRUP BY, ORDER BY, ANALYZE) que son demasiado grandes para hacerlas en la memoria.
El segmento de sort se asigna y se crea al momento de la primera operación de sort.
Archivos de datos (Datafiles)
editarOracle crea un archivo para una tablespace asignando la cantidad específica de espacio de disco más el overhead requerido para la cabecera. El sistema operativo se encarga de todos las autorizaciones para crear archivos.
Contenidos de los archivos de datos
editarCuando se crea un archivo, el espacio asignado es formateado pero no contiene dato alguno, sin embargo Oracle reserva el espacio para mantener los datos para segmentos futuros de la tablespace asociada.
Tamaño de los archivos de datos
editarEl tamaño de un archivo se puede alterar después de su creación o se puede especificar que un archivo crezca dinámicamente como los objetos schema crecen en una tablespace.
Archivos Offline
editarTodos los archivos que conforman una tablespace son llevados offline u online como una unidad cuando se lleva a la tablespace online u offline respectivamente. Se pueden llevar los archivos offline individualmente, sin embargo esto es normalmente hecho solamente durante algunos procedimientos de recuperación.
^ The control files of a database store the status of the physical structure of the database. The control file is absolutely crucial to database operation. It contains (but is not limited to) the following types of information:
- Database information (RESETLOGS SCN and their time stamp)
- Archive log history
- Tablespace and datafile records (filenames, datafile checkpoints, read/write status, offline or not)
- Redo threads (current online redo log)
- Database's creation date
- Database name
- Current archive log mode
- Log records (sequence numbers, SCN range in each log)
- RMAN catalog
- Database block corruption information
- Database ID, which is unique to each DB