Estructuras de Oracle: Tablespaces

Tablespaces

 Introducción

En primer lugar vamos a dar a conocer muy por encima las unidades básicas que forman una base de datos. Estas unidades son los tablespaces y los datafiles.

Una base de datos está formada por una o varias unidades lógicas llamadas tablespaces. Además, cada una de estos tablespaces está formado por uno o varios ficheros físicos que son los datafiles. Un datafile solamente puede pertenecer a un tablespace. Por lo tanto, los datafiles de una base de datos son todos los datafiles que forman parte de todos los tablespaces de la base.

Cuando se crea una base de datos, hay que crear al menos un tablespace, por lo que durante el proceso de creación de la base de datos siempre se indica el tablespace principal de ésta, que se llama SYSTEM.

De igual manera, cuando se crea un tablespace que, como hemos dicho, es una unidad lógica, se debe indicar obligatoriamente también el nombre de al menos un datafile que formará parte de ese tablespace. El datafile es un fichero físico al que le tendremos que asignar un directorio, un nombre y un tamaño.

 El Tablespace System

Cuando se crea una base de datos es obligatorio crear un tablespace inicial en el que se van a crear los usuarios SYS y SYSTEM automáticamente. Estos usuarios son los que tienen la información necesaria para que funcione nuestra base de datos y podamos hacer todo tipo de operaciones como, por ejemplo, crear nuevos usuarios o crear nuevos tablespaces y tablas en esos nuevos tablespaces.

Este tablespace inicial se llama por defecto SYSTEM. Es una pieza clave para un buen funcionamiento de la base de datos ya que en él residen todos los objetos de los usuarios SYS y SYSTEM.

Es muy recomendable crear al menos otro tablespace nuevo distinto al SYSTEM. Así, todos los nuevos usuarios que creemos en nuestra base de datos, junto con todas sus tablas e índices se almacenarán en un tablespace diferente a SYSTEM. Se realiza esta separación para evitar que se bloquee toda la base de datos si ocurre algo grave en el tablespace SYSTEM. Suele ser habitual que para nuestras aplicaciones creemos usuarios y tablas en las que introducimos información y que sin darnos cuenta se llene de información el tablespace en el que están estas tablas. Si no hemos sido previsores, podemos haber llenado el tablespace SYSTEM con lo que es posible que se paralice toda la base de datos.

 Manipulando Tablespaces

Ahora que nos hemos hecho una idea acerca de qué es un tablespace, vamos a realizar sobre él las manipulaciones básicas.

Partimos de una base de datos creada y levantada. Nos conectaremos a la misma con el usuario SYSTEM y su contraseña. La contraseña del usuario SYSTEM al crear la base de datos es, por defecto, MANAGER. Como medida de seguridad se recomienda cambiarla cuanto antes. Por lo tanto nos conectaremos bien al SqlPlus mediante sqlplus system/manager, o bien al server manager mediante el comando svrmgrl system/manager.

Crear un Tablespace.

En primer lugar vamos a crear un tablespace llamado Prueba. Esto lo podemos hacer por ejemplo desde el SQLPLUS conectados como system.

Create tablespace prueba datafile  /users/oradata/orcl/prueba01.dbf  size 100M; 

Con esta sentencia estamos creando en nuestra base de datos un tablespace nuevo llamado "prueba" y que está formado físicamente por un fichero (datafile) llamado prueba01.dbf de 100 Mbytes y que está en el directorio "/users/oradata/orcl". Esta sentencia crea físicamente dicho fichero.

Aumentar de tamaño un Tablespace.

Para aumentar el tamaño de un tablespace que se nos ha quedado ya pequeño, tenemos varias posibilidades. La primera de ellas es crear un nuevo datafile y asignárselo al tablespace que queremos aumentar. Esto lo podemos hacer con la instrucción siguiente.

Alter tablespace prueba add datafile  /users/oradata/orcl/prueba02.dbf  size 50M; 

Con esta sentencia hemos creado un nuevo fichero físico en nuestro directorio /users/oradata/orcl de 50 Mbytes de tamaño y se lo hemos asignado al tablespace "prueba".

Otra posibilidad es ampliar el tamaño de uno de los ficheros físicos o datafiles que forman el tablespace. Esto lo podemos hacer fácilmente con la siguiente instrucción:

Alter datafile  /users/oradata/orcl/prueba01.dbf  resize 150M; 

Con esta sentencia lo que hacemos es aumentar el datafile que forma parte de nuestro tablespace en 50 Mbytes.

Tanto en la instrucción de creción como en la de aumentar el tamaño de un tablespace se puede observar fácilmente cómo un datafile pertenece solamente a un tablespace ya que en la propia sentencia se crea el fichero físico o datafile.

Borrando un tablespace.

Para eliminar un tablespace de la base de datos se debe utilizar la sentencia:

Drop tablespace prueba; 

 Tablespaces Online y Offline

Un tablespace puede estar en dos estados: Online y Offline. Que un tablespace esté online significa que está disponible para operar en él, mientras que si está offline quiere decir que no se puede utilizar. Cuando creamos un tablespace, se crea en estado online y, por lo tanto, podemos crear en dicho tablespace objetos como índices, tablas, etc.

¿Cómo sabemos en qué estado se encuentran nuestros tablespaces?.

Existe una vista que nos da información sobre los tablespaces de nuestra base de datos. Esta vista es la dba_tablespaces. Consultándola podemos conocer qué tablespaces tenemos en nuestra base de datos y en qué estado se encuentran.

select tablespace_name, status from dba_tablespaces; 

¿Para qué queremos poner un tablespace offline?.

Hay que tener en cuenta que cuando un tablespace está offline, no se puede acceder a ningún objeto que se encuentre en él, es decir, que si en el tablespace hay tablas, no se podrá hacer consultas ni inserciones ni modificaciones de estas tablas, sin embargo, el resto de los objetos que se encuentran en otros tablespaces de la base de datos si están accesibles. Por lo tanto, pondremos un tablespace offline en general para realizar tareas administrativas.

• Para poder hacer una copia de seguridad del tablespace estando completamente seguros de que nadie está modificando los objetos del tablespace y que no quedan transacciones pendientes sin terminar y que pueden modificar estos objetos.
• Para poder actualizar una aplicación que se basa en los objetos de este tablespace sin que ningún usuario pueda modificar los datos en medio de la actualización.

En un tablespace puede haber objetos de varios tipos, como hemos indicado. Si en un tablespace existen segmentos de rollback activos, no se puede poner offline, primero hay que desactivar los segmentos de rollback activos del tablespace.

¿Cómo sabemos los rollback segments que existen en un tablespace y su estado?. Muy sencillo, con la siguiente sentencia:

select rollback_segment, status, tablespace_name from dba_rollback_segs; 

Así podremos ver todos los rollback que tenemos, en qué estado se encuentran (online, offline) y en qué tablespace están. Si comprobamos que en el tablespace que vamos a poner offline tenemos algún segmento de rollback online (activo), debemos ponerlo offline antes que el tablespace. Para desactivar un segmento de rollback, ejecutaremos la siguiente sentencia desde el SqlPlus o desde el server manager.

alter rollback segment nombre_de_segmento offline; 

Cuando ya no queden segmentos de rollback en estado online en nuestro tablespace, ya podremos desactivarlo para que no se pueda acceder a él.

alter tablespace nombre_de_tablespace offline; 

Finalmente, cuando terminemos nuestras tareas administrativas sobre dicho tablespace, ya podemos activarlo para que todos sus objetos vuelvan a estar accesibles por los usuarios.

alter tablespace nombre_de_tablespace online; 

Por supuesto, no debemos olvidar que si hemos tenido que desactivar algún segmento de rollback que se encontraba en nuestro tablespace, ahora deberemos volver a activarlo.

alter rollback segment nombre_de_segmento online; 

Una curiosidad sobre los tablespaces que no están disponibles (offline), es que, como ya hemos comentado, no se pueden realizar consultas ni modificaciones ni inserciones en los datos de las tablas que están en ellos, pero si que se pueden eliminar objetos de dicho tablespace, que no es lo mismo que borrar datos de objetos del tablespace.

También es muy habitual que en el diseño de las bases de datos, se creen tablespaces para almacenar los índices de la aplicación y otros distintos para almacenar las tablas o datos. En estos casos, si desactivamos el tablespace en el que se encuentran los índices, podemos seguir accediendo a las tablas y realizar consultas sobre ellas porque su tablespace está accesible.

Por otro lado, es posible que si en servidor Oracle se encuentra con graves problemas para escribir en un tablespace, al cabo de varios intentos lo ponga automáticamente offline.

Queremos apuntar aquí, aunque se escapa a los objetivos de este manual, que cuando un tablespace está offline, la información de que esto ha ocurrido se queda almacenadada en el tablespace SYSTEM de esta base de datos. Existe una forma de transportar un tablespace de una base de datos a otra para tener accesibles sus objetos en la segunda, pero si el tablespace está offline en la primera, nunca podrá ponerse online en la base de datos destino ya que, como hemos dicho, la información del estado de este tablespace se encuentra en el tablespace SYSTEM de la base de datos originaria del tablespace.

 Tablespaces Read Only

Cuando creamos un tablespace, podemos crear en él todos los objetos que queramos y acceder a ellos y eliminarlos y también consultar los datos de las tablas que se encuentren en este tablespace, así como borrar, insertar y modificar estos datos. Existe la posibilidad de poner un tablespace en un estado en el cual, solamente se pueden consultar los datos de los objetos, no se puede ni borrar ni insertar nada en ellos.

¿Para qué me viene bien un tablespace read only?.

La principal ventaja de un tablespace read only es que, como no se pueden modificar los datos que en él se encuentran, no hace falta hacer backup del mismo. Dependiendo de las apliaciones que tengamos en nuestra base de datos nos puede interesar tener tablespaces read only o no. Por ejemplo, si tenemos una aplicación en la que se pueden consultar cientos de fotos de animales salvajes o de paisajes, podríamos crear un tablespace en el que introducir estas imágenes y luego ponerlo read only.

Generalmente un tablespace de estas características, que sirve de almacenamiento de fotos o temas similares, suele ocupar mucho espacio, por lo que hacer un backup del mismo todos los días puede resultar muy costoso en tiempo y espacio. Además, si no se modifican nunca estas fotos no tiene mucho sentido hacer copia de seguridad del mismo, y no solo eso, podríamos incluso almacenar dicho tablespace en un CDROM en vez de ocupar espacio en disco.

Para poner un tablespace en estado read only, simplemente debemos ejecutar la siguiente instrucción:

alter tablespace nombre_de_tablespace read only; 

Como hemos indicado, en un tablespace read only solo se pueden realizar consultas de los datos, por lo tanto, si en el instante de ejecutar esta sentencia se están realizando modificaciones o inserciones o borrado de datos, el servidor espera hasta que acaben para poner el tablespace en estado read only. Para ver si ha quedado en estado read only, simplemente ejecutamos la misma select que al principio para ver la información general de los tablespaces:

select tablespace_name, status from dba_tablespaces; 

Si por algún motivo necesitamos modificar los datos que se encuentran almacenados en espace un tablespace read only, simplemente deberemos ponerlo en primer lugar en estado read write y una vez realizada la modificación, volver a ponerlo en su estado read only. La sentencia que debemos ejecutar será:

alter tablespace nombre_de_tablespace read write; 

Tenemos un concepto que debe quedar claro. Un tablespace read only no necesita backup, y por tanto, recovery, pero, esto no hay que tomarlo al pie de la letra. Siempre hay que hacer al menos un backup. En primer lugar creamos un tablespace vacío en el que iremos metiendo poco a poco toda la información que nos interesa que, como en el caso que hemos supuesto anteriormente, pueden ser varias tablas que almacenan fotos de animales y paisajes. Cuando ya no vamos a crear nuevas imágenes es cuando ponemos el tablespace read only, pero ahí si debemos hacer una copia de seguridad, backup, y como ya no vamos a tocar nunca más este tablespace será la única. Si por algún motivo decidimos poner este tablespace otra vez read write para crear o borrar datos, después de volver a ponerlo read only deberemos hacer un backup de los nuevos datos.

También hay que diferenciar dos ideas. Por un lado hemos dicho que en un tablespace read only no se pueden modificar, ni insertar ni borrar datos de sus tablas. Sin embargo y, al igual que en los tablespaces offline, si se pueden borrar objetos enteros del tablespace, como por ejemplo un índice o una tabla.

 Tablespaces Temporales

Un tablespace temporal es aquél en el que solamente puede haber objetos temporales. No se pueden crear en él objetos permanentes como pueden ser los índices, las tablas o los segmentos de rollback. Están especialmente preparados para optimizar las operaciones en las que se lleven a cabo ordenaciones. Por lo tanto está muy recomendado tener al menos un tablespace temporal en cada base de datos. Algunas de las operaciones que implican realizar ordenaciones son, las selects que tienen group by, las que tienen order by, la creación de índices y analizar índices para calcularles las estadísticas. En todos estos casos, cuando para realizar la ordenación el servidor no encuentra espacio suficente libre en la memoria, utiliza el tablespace temporal. Los rendimientos son muy superiores comparándolos con los tiempos que se emplearía en realizar las ordenaciones en tablespaces normales. Esto se debe a que el mecanismo que se utiliza para reservar y desreservar el espacio en los tablespaces temporales es muy distinto que en los normales ya que está orientado a objetos que crecen mucho y rápido y que a continuación disminuyen totalmente su tamaño y desaparecen.

Para crear un tablespace temporal simplemente hay que añadir la palabra TEMPORARY a la instrucción utilizada para crear tablespaces normales. Siguiendo el ejemplo indicado en la creación de tablespaces, podríamos tener lo siguiente:

Create tablespace prueba datafile  /users/oradata/orcl/prueba01.dbf  
size 100M temporary; 

Para indicar a un usuario de base de datos que sus ordenaciones debe hacerlas en un determinado tablespace temporal, hay que lanzar una sentencia como la que sigue.

Alter user nombre_de_usuario temporary tablespace nombre_de_tablespace; 

Y para conocer qué usuarios existen en nuestra base de datos y cual es el tablespace temporal que utilizan, podemos consultar la base de datos de la siguiente manera:

Select username, temporary_tablespace from dba_users; 

Y finalmente, si queremos conocer qué tablespaces tenemos y cuáles son temporales y cuales son permanentes, podemos consultar la vista que nos da la información sobre los tablespaces, es decir, la vista dba_tablespaces;

Como nota final apuntaremos que un tablespace permanente puede pasar a temporal y que uno temporal puede pasar a permanente.