Estructuras de Oracle

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; Select tablespace_name, contents from dba_tablespaces;

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

.�Temas Relacionados

Relacionado directamente con este tema, se pueden estudiar tambi�n los siguientes temas:

  • Parametrizaci�n de los tablespaces. �Qu� es la cl�usula storage? �qu� son initial_extent, next_extent, pct_increase?.
  • �C�mo conseguimos que un usuario pueda crear tablas o �ndices en un tablespace?.
  • �Qu� es la fragmentaci�n de los tablespaces y c�mo se soluciona?.
  • �Qu� son los tablespaces transportables?.
  • �Qu� son los tablespaces locales?.
  • �Qu� es la normativa O.F.A. de Oracle y c�mo se aplica a los tablespaces?.

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP
SIGUIENTE ARTÍCULO