Estructuras de Oracle

En cada base de datos Oracle tenemos uno o m�s segmentos de rollback en los que se almacena la informaci�n que ha sido cambiada por las transacciones. Estas transacciones pueden ser definitivas, es decir, se ha realizado ya el commit de ellas, o puede que a�n no se haya hecho dicho commit. Este tipo especial de segmento se utiliza principalmente para poder realizar una lectura consistente de la base de datos Oracle mientras se est�n modificando los datos y para poder llevar a cabo las recuperaciones de la base cuando �sta cae por alg�n motivo.

La informaci�n de un segmento de rollback se almacena en las llamadas entradas de rollback. En estas entradas se detalla en qu� datafile estaba el dato que ha sido modificado, en qu� bloque dentro de dicho datafile y tambi�n el dato viejo que se ha modificado en la transacci�n. Adem�s, todas las entradas de rollback de una misma transacci�n est�n encadenadas unas con otras para que as�, si se deben deshacer los cambios llevados a cabo en esa transacci�n, resulta m�s f�cil de encontrarlos todos.

Las vistas m�s importantes de las que podemos extraer informaci�n sobre los segmentos de rollback son: v$rollname, dba_rollback_segs y v$rollstat.

En una base de datos Oracle, se guardan todos cambios en los bloques modificados en una estructura llamada "logs de rehacer" o, "redo logs". Cuando se crea una nueva entrada de rollback en un segmento de rollback, realmente se est� modificando un bloque que se encuentra en dicho segmento de rollback con la informaci�n de dicha entrada, por lo que este cambio tambi�n se almacena en los log de rehacer. Este doble almacenamiento de la informaci�n que se guarda en los segmentos de rollback y en los log de rehacer es fundamental para poder realizar un buen proceso de recuperaci�n de la base de datos en caso de que se produzca en fallo en ella. Cuando se produce una ca�da de la base de datos, en el momento de la recuperaci�n, se recupera el estado de los segmentos de rollback tanto con las transacciones que ya se hab�an terminado como con aquellas transacciones cuyo commit a�n no se hab�a realizado. El siguiente paso que se produce es el rollback de todas aquellas transacciones que se encuentran en los segmentos de rollback y para las cuales no se hab�a completado el commit.

�Utilizaci�n de los segmentos de rollback

Como se ha indicado anteriormente, los segmentos de rollback se utilizan para poder deshacer los cambios de las transacciones para las que no se ha hecho un commit y para asegurar la consistencia de lectura. Para facilitar estas tareas, Oracle guarda por cada bloque una tabla de las transacciones que en cada momento se est�n ejecutando en el mismo. Adem�s, por cada transacci�n, por cada nuevo cambio que se realiza en los bloques de datos se crea una entrada de rollback que se encadena a las anteriores entradas de rollback asignadas a esa misma transacci�n de forma ordenada.

Gracias a este sistema, cada vez que se desea restaurar el estado de una transacci�n al realizar el rollback de la misma, simplemente se debe detectar en qu� bloque del segmento de rollback se est� almacenando los cambios producidos por dicha transacci�n mirando en las tablas de transacciones de los bloques del segmento de rollback y, una vez detectado el bloque, se deben seguir una a una las entradas de rollback de la transacci�n que se encuentran ordenadas y encadenadas, para ir restaurando los valores antiguos en los bloques de datos de forma ordenada.

De la misma manera, se utiliza para facilitar la lectura consistente ya que se detecta el valor antiguo de los bloques navegando por la cadena de las entradas de rollback de la transacci�n.

�C�mo se asignan las transacciones a los segmentos de rollback?.

Cada vez que comienza una nueva transacci�n, se asigna a un determinado segmento de dos formas diferentes:

• Se asigna la transacci�n al siguiente segmento de rollback que se encuentre libre en ese momento de manera autom�tica. Solamente se asigna una transacci�n cuando se realiza una instrucci�n de DDL o de DML que no sea una select.
• Tambi�n se puede asignar una transacci�n a un segmento de rollback en concreto de forma manual. De esta forma, se puede asignar a un segmento de rollback grande una transacci�n que conocemos de antemano que modifica un gran volumen de datos. Una vez finalizada la transacci�n, Oracle vuelve a asignar la siguiente de manera autom�tica al primer rollback que encuentra libre. La instrucci�n es la siguiente: Set transaction use rollback segment nombre_segmento_rollback;

Cuando se finaliza una transaccion, Oracle libera la informaci�n de rollback aunque no la destruye, esto es para soportar la lectura consistente de consultas que han comenzado antes de que se realizara el commit. Para asegurarse que la informaci�n se encuentra en los segmentos de rollback el mayor tiempo posible para estas consutas sin borrarla, Oracle va asignando las extensiones a los segmentos de rollback de manera secuencial y, cuando se ha llenado el segmento, se reutilizan las extensiones empezando nuevamente por la primera, como si fuera un segmento circular.

Un segmento de rollback puede tener asignadas solamente un n�mero fijo de transacciones como m�ximo. Oracle se encarga de asignar las transacciones de una instancia de manera que todos los segmentos tengan el mismo n�mero de transacciones aproximadamente, sin tener en cuenta el tama�o de las mismas ya que, de antemano no lo puede conocer. El n�mero de transacciones que puede contener cada segmento de rollback depende del tama�o del bloque.

�Asignaci�n de extensiones

Como hemos indicado anteriormente, un segmento de rollback debe tener al menos dos extensiones y cada una de sus extensiones est� formada por un n�mero determinado de bloques. A continuaci�n vamos a explicar c�mo se organizan las transacciones en los segmentos de rollback.

En un segmento de rollback pueden estar realiz�ndose a la vez varias transacciones. Estas transacciones pueden estar escribiendo en distintas extensiones o incluso en la misma. Sin embargo, en un bloque de una extensi�n solamente puede contener informaci�n de una transacci�n, es decir, que no pueden escribir dos transacciones en el mismo bloque de la misma extensi�n a la vez. Adem�s, como hemos indicado que la escritura de transacciones es secuencial, en cada momento una transacci�n escribe en una sola extensi�n. Cuando una transacci�n se queda sin espacio para escribir en la extensi�n en la que estaba, puede hacer dos cosas, bien reutilizar una extensi�n que ya estaba asignada al segmento o bien requerir una nueva extensi�n para el segmento de rollback.

La primera transacci�n que necesita m�s espacio nuevo chequea la siguiente extensi�n del segmento de rollback, y si no contiene informaci�n de transacciones activas, la adquiere. A partir de ese momento, todas las dem�s transacciones que necesiten espacio utilizar�n esta extensi�n. Si, nuevamente se llena esta extensi�n y alguna transacci�n sigue necesitando espacio libre, Oracle vuelve a comprobar si en la siguiente extensi�n que le toca ocupar, siguiendo el orden secuencial y circular de asignaci�n de extensiones, no se est�n realizando transacciones activas (insistimos en la naturaleza circular de los segmentos de rollback que, una vez ocupada la �ltima extensi�n, vuelve a intentar ocupar la primera como si formaran todas un anillo).

Como estamos viendo, Oracle mantiene un anillo formado por las extensiones que ha ido adquiriendo este segmento de rollback y siempre intenta reusar una de las extensiones que lo forman antes que adquirir una nueva del sistema. Si en alg�n momento Oracle necesita utilizar una extensi�n y, en todas los que forman parte del anillo se est�n escribiendo transacciones activas, se ve obligado a adquirir una nueva extensi�n del sistema y a a�adirla al anillo del segmento de rollback para seguir escribiendo. El n�mero m�ximo de extensiones que pueden formar parte de un segmento de rollback viene determinado por una par�metro definido en el initSID.ora y que es MAXEXTENTS.

Ya hemos visto c�mo se asignan extensiones a un segmento de rollback, pero �c�mo se van desasignando?.

Al borrar un segmento de rollback, todas las extensiones que ten�a asignadas el segmento se devuelven al tablespace y pueden ser utilizadas por el resto de objetos que pertenecen al tablespace. Existe otra manera de devolver el espacio utilizado por un segmento sin tener que eliminarlo. A la hora de crear un segmento de rollback se puede indicar un valor en el par�metro OPTIMAL de la cl�usula storage que representa el tama�o �ptimo de dicho segmento en bytes. Cada vez que Oracle necesista una nueva extensi�n para el segmento de rollback, compara el tama�o que tiene dicho segmento con el valor del par�metro optimal y, si lo ha sobrepasado, ir� devolviendo al tablespace las extensiones m�s antiguas que se va encontrando en las que ya no quedan transacciones activas ya que, son las que menor probabilidad tienen de tener datos necesarios para mantener la consistencia de lectura. Si puede, liberar� tantas extensiones como para quedarse con un tama�o aproximado al indicado en optimal pero siempre por encima.

El valor del par�metro �ptimal nuca podr� ser menor que el espacio necesario para la creaci�n del segmento, en el que participan el par�metro initial_extent, next_extent, y min_extents (recordemos que pct_increase no tiene sentido en los segmentos de rollback, todas las extensiones deben ser iguales). Para consultar los valores de estos par�metros podemos utilizar la vista dba_rollback_segs de la siguiente forma:

Select segment_name, initial_extent, next_extent, min_extents, max_extents 
from dba_rollack_segs; 

Y para conocer si nuestros rollback segments tiene asignado un tama�o �ptimo:

Select name, optsize from v$rollname, v$rollstat 
where v$rollname.usn = v$rollstat.usn order by 1; 

�Estados de un segmento de rollback

Un segmento de rollback puede encontrarse en un determinado estado dependiendo de cada momento. Los estados en los que puede encontrarse son:

• OFFLINE: No ha sido adquirido por ninguna instancia de la base de datos.
• ONLINE: Ha sido adquirido por alguna de las instancias y puede contener datos de transacciones activas.
• NEEDS RECOVERY: Contiene datos de transacciones que no se pueden hacer rollback porque sus datafiles est�n inaccesibles o corruptos.
• PARTLY AVAILABLE: Contiene informaci�n de una transacci�n "en duda" que son transacciones en entornos de base de datos distribuidas de las que a�n no se ha recibido respuesta.
• INVALID: Ha sido borrado.

Esta informaci�n se puede obtener de la vista dba_rollback_segs. Las causas por las que un segmento puede pasar de un estado a otro son las siguientes:

Los estados de Partly Available y Needs recovery son pr�cticamente iguales. En ambos el segmento contiene informaci�n de transacciones que no han sido resueltas. En un estado Partly Available, las transcciones distribuidas no han sido resueltas por culpa de un fallo en la red mientras que en el estado de Needs Recovery, las transacciones no han sido resueltas por un fallo del medio o por estar corrupto el propio segmento.

Una diferencia entre ambos estados es que un adminstrador o el propio Oracle puede poner un segmento Partly Available en estado Online, mientras que un segmento que necesita Recovery, primero debe pasar a estado Offline y luego Online. Adem�s, un segmento en estado Needs Recovery puede ser borrado por el administrado para eliminarlo si estaba corrupto, sin embargo, no se puede borrar un segmento Partly available, primero se debe resolver la transacci�n en duda.

�Temas Relacionados

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

• �Qu� son los segmentos de rollback privados y p�blicos?.
• �C�mo se puede poner un segmento online u offline y en qu� condiciones?.
• �C�mo borrar un segmento de rolback?.
• �Qu� es un Shrink?.
• �C�mo se modifican los par�metros de un segmento de rollback?.
• �C�mo se consigue la consistencia de lectura?.
• �C�mo se lleva a cabo el rollback de las transacciones?.
• �Cu�l es el proceso seguido en la recuperaci�n de la base de datos?.