U09_Administración de Datos de Deshacer

Vista previa del material en texto

UNIVERSIDAD NACIONAL DE JUJUY 
FACULTAD DE INGENIERIA 
ANALISTA PROGRAMADOR UNIVERSITARIO 
Cátedra: BASE DE DATOS II 
 
Profesor Adjunto:  Ms. Ing. Héctor P. Liberatori  1/8 
 
 
UNIDAD 9 
ADMINISTRACIÓN DE LOS UNDO DATA (DATOS DE DESHACER) 
9.1.	OBJETIVOS	
 Explicar DML y la generación de datos deshacer. 
 Controlar y administrar datos de deshacer. 
 Describir la diferencia entre datos de deshacer y de redo. 
 Configurar la retención de deshacer. 
 Garantizar la retención de deshacer. 
 Utilizar el Asesor de Deshacer. 
9.2.	MANIPULACIÓN	DE	DATOS	
Los datos se manipulan, o modifican, mediante  la clase DML de sentencias SQL:  INSERT, UPDATE, DELETE y 
MERGE. Estas sentencias se ejecutan como parte de una transacción, que se  inicia con  la primera sentencia 
DML  correcta  y  termina  con un  comando COMMIT o ROLLBACK  (Figura  9.1).  En  las  transacciones  sólo  se 
puede  realizar  una  operación  de  confirmación  o  de  rollback.  La  operación  de  rollback  también  se  puede 
producir si hay un fallo del sistema o de proceso. 
 
Figura 9.1: Manipulación de datos 
9.3.	DATOS	DE	DESHACER	
La base de datos Oracle guarda el valor anterior (datos de deshacer) cuando un proceso cambia datos de una 
base  de  datos.  Almacena  los  datos  como  existían  antes  de  que  se modificaran.  La  captura  de  datos  de 
deshacer le permite realizar una operación de rollback en los datos no confirmados (Figura 9.2). Los datos de 
deshacer también soportan consultas de flashback y de lectura consistente. 
Las  consultas  de  lectura  consistente  proporcionan  resultados  que  son  consistentes  con  los  datos  en  el 
momento  en  que  se  inicia  una  consulta.  Para  que  una  consulta  de  lectura  consistente  se  realice 
correctamente, la  información original debe existir aún como información de deshacer. Mientras se retenga 
la  información de deshacer,  la base de datos Oracle puede reconstruir datos que cumplan  las consultas de 
lectura consistente. 
Las  consultas de  flashback  son  consultas que piden  con determinación una  versión de  los datos  tal  como 
existían  en  algún momento  del  pasado.  Siempre  que  la  información  de  deshacer  del  pasado  exista,  las 
consultas de flashback pueden terminar correctamente. 
 
UNIVERSIDAD NACIONAL DE JUJUY 
FACULTAD DE INGENIERIA 
ANALISTA PROGRAMADOR UNIVERSITARIO 
Cátedra: BASE DE DATOS II 
 
Profesor Adjunto:  Ms. Ing. Héctor P. Liberatori  2/8 
 
 
Los datos de deshacer  también  se utilizan para  la  recuperación de  transacciones  fallidas. Una  transacción 
fallida se produce cuando una sesión de usuario termina de forma anormal (posiblemente debido a errores 
de  red o a un  fallo en  la  computadora  cliente) antes de que el usuario decida  confirmar  la  transacción o 
realizar un rollback de  la misma. Las transacciones  fallidas también se pueden producir cuando  la  instancia 
falla. 
En caso de una  transacción  fallida, se selecciona el comportamiento más seguro y  la base de datos Oracle 
deshace todos los cambios realizados por el usuario, restaurando los datos originales. 
La información de deshacer se retiene para todas las transacciones al menos hasta que la transacción termine 
debido a:  
 •Usuarios que deshacen la transacción (operación de rollback) 
 Usuarios que terminan una transacción (confirmación) 
 Sesión de usuario que termina de forma anormal (operación de rollback) 
 Sesión de usuario que termina de forma normal con una salida (confirmación) 
La cantidad de datos de deshacer que se retienen y el tiempo de esa retención dependen de  la cantidad de 
actividad de la base de datos y de su configuración. 
 
Figura 9.2: Datos de deshacer 
9.4.	TRANSACCIONES	Y	DATOS	DE	DESHACER	
Al iniciar una transacción, ésta se asigna a un segmento de deshacer. A lo largo de la transacción, cuando se 
modifiquen  los datos,  los valores originales (antes del cambio) se copiarán al segmento de deshacer (Figura 
9.3).  Las  transacciones  se  asignan  a  los  distintos  segmentos de  deshacer  y  se  comprueba  con  la  vista  de 
rendimiento dinámico v$transaction. 
Los segmentos de deshacer son segmentos especializados que la instancia crea automáticamente, según sea 
necesario,  para  soportar  las  transacciones. Al  igual  que  todos  los  segmentos,  los  segmentos  de  deshacer 
están  formados  por  extensiones  que  a  su  vez  constan  de  bloques  de  datos.  Los  segmentos  de  deshacer 
crecen  y  se  reducen  automáticamente  si es necesario,  actuando  como buffer de  almacenamiento  circular 
para las transacciones asignadas. 
Las transacciones rellenan extensiones en los segmentos de deshacer hasta que se termina una transacción o 
se  consume  todo  el  espacio.  Si  una  extensión  se  llena  completamente  y  se  necesita  más  espacio,  la 
transacción adquiere ese espacio de la siguiente extensión del segmento. Al consumir todas las extensiones, 
la transacción se volverá a ajustar a  la primera extensión o solicitará que se asigne una extensión nueva al 
segmento de deshacer. 
 
UNIVERSIDAD NACIONAL DE JUJUY 
FACULTAD DE INGENIERIA 
ANALISTA PROGRAMADOR UNIVERSITARIO 
Cátedra: BASE DE DATOS II 
 
Profesor Adjunto:  Ms. Ing. Héctor P. Liberatori  3/8 
 
 
Las operaciones en paralelo pueden hacer que una  transacción utilice  realmente más de un  segmento de 
deshacer. 
 
Figura 9.3: Transacciones y datos de deshacer 
9.5.	ALMACENAMIENTO	DE	INFORMACIÓN	DE	DESHACER	
Los  segmentos  de  deshacer  sólo  pueden  existir  en  una  forma  especializada  de  tablespace  denominada 
tablespace de deshacer. Aunque una base de datos puede tener numerosos tablespaces de deshacer, sólo se 
puede designar uno de ellos como el tablespace actual en el que se escribirán los datos de deshacer (Figura 
9.4). 
Los segmentos de deshacer siempre son propiedad de SYS. Puesto que  los segmentos actúan como buffer 
circular, cada segmento tiene dos extensiones como mínimo. El número máximo de extensiones por defecto 
depende del tamaño del bloque de base de datos, aunque es muy alto (32.765 para un tamaño de bloque de 
8 KB). 
Los  tablespaces  de  deshacer  son  tablespaces  permanentes,  gestionados  localmente  con  asignación 
automática de extensiones. Se gestionan como cualquier otro  tablespace excepto en  lo que se  refiere a  la 
recuperación. Puesto que se necesitan datos de deshacer para recuperar transacciones fallidas (como las que 
se  pueden  producir  cuando  una  instancia  falla),  los  tablespaces  de  deshacer  sólo  se  pueden  recuperar 
mientras la instancia está en estado MOUNT.  
 
Figura 9.4: Almacenamiento de información de deshacer 
 
UNIVERSIDAD NACIONAL DE JUJUY 
FACULTAD DE INGENIERIA 
ANALISTA PROGRAMADOR UNIVERSITARIO 
Cátedra: BASE DE DATOS II 
 
Profesor Adjunto:  Ms. Ing. Héctor P. Liberatori  4/8 
 
 
9.6.	DATOS	DE	DESHACER	FRENTE	A	DATOS	DE	REDO	
En un principio, los datos de deshacer y de redo se parecen bastante, aunque sirven para obtener resultados 
diferentes. Los datos de deshacer son necesarios cuando hay que deshacer un cambio y esto ocurre en  las 
operaciones  de  consistencia  de  lectura  y  de  rollback.  Los  datos  de  redo  son  necesarios  cuando  hay  que 
realizar de nuevo los cambios, en el caso de que se hayan perdido por algún motivo (Tabla  9.1). 
El proceso de confirmación implica una verificación de que los cambios de la transacción se han escrito en el 
archivo  de  redo  log,  que  se  encuentra  almacenado  de manera  persistente  en  el  disco,  en  lugar  de  en  la 
memoria. Además, normalmente está multiplexado. Es decir, hay varias copias de  los datos de  redo en el 
disco. Incluso aunque no se hayan escrito los cambios en los archivos de datos en los que están almacenados 
realmente los bloques de la tabla, la garantía de que los cambios se han escrito en el archivo de redo log es 
suficiente. 
Por  ejemplo,  un  corte  en  el  suministro  eléctrico  justo  antes  de  que  loscambios  confirmados  se  hayan 
reflejado en  los archivos de datos no causa ningún problema ya que la transacción se ha confirmado. Por lo 
tanto, cuando se vuelva a iniciar el sistema, se podrán aplicar los cambios de los registros de redo que no se 
llegaron a reflejar en los archivos de datos en el momento del corte de electricidad. 
 
Tabla 9.1: Comparación de datos de Deshacer y Datos de Redo 
9.7.	CONTROL	DE	DESHACER	
La mayor  parte  del  tiempo  la  instancia  gestiona  automáticamente  las  operaciones  de  deshacer  casi  sin 
intervención  del  administrador  de  base  de  datos  (DBA).  Puede  que  sea  necesaria  la  participación  del 
administrador cuando se produce lo siguiente (Figura 9.2): 
 Espacio insuficiente para deshacer 
 Los usuarios reciben mensajes de error ORA-01555 snapshot too old (número y tamaño de  los 
segmentos deshacer) 
La  información de deshacer siempre se  retiene hasta que una  transacción  termina. Esto significa que si se 
suprimen o actualizan cantidades muy grandes de datos (las operaciones de  inserción consumen muy poco 
espacio de deshacer porque  la  imagen original de  los datos  insertados es un  valor nulo)  sin  confirmar, el 
tablespace de deshacer debe ser lo bastante grande para contener los datos originales. Imagine un caso en el 
que en una tabla de 50 GB se hubieran suprimido todas las filas con el comando siguiente: 
SQL> DELETE FROM reallybigtable; 
Sería necesario que el tablespace tuviera espacio para 50 GB de  información original sólo en caso de que el 
usuario  que  emitió  esta  sentencia  cambiara  de  opinión  y  quisiera  realizar  un  rollback  del  cambio.  Si  el 
tablespace de deshacer se queda sin espacio para los datos de deshacer, los usuarios reciben un mensaje de 
error como el siguiente: 
ORA-01650: unable to extend rollback segment 
El control proactivo detecta problemas de espacio en un tablespace de deshacer antes de que afecte a  los 
usuarios. 
 
UNIVERSIDAD NACIONAL DE JUJUY 
FACULTAD DE INGENIERIA 
ANALISTA PROGRAMADOR UNIVERSITARIO 
Cátedra: BASE DE DATOS II 
 
Profesor Adjunto:  Ms. Ing. Héctor P. Liberatori  5/8 
 
 
Otro problema, con el que el administrador se puede encontrar con  la  información de deshacer, es cuando 
una consulta tiene que acceder a  información de deshacer que ya se ha sobrescrito. Esto puede suceder en 
una consulta de flashback o con una ejecución muy larga. Cuando una consulta necesita una “instantánea” de 
los datos como eran en algún momento del pasado y  la reconstrucción de dicha  instantánea necesita datos 
de deshacer que ya no existen, la consulta devuelve el siguiente error: 
ORA-01555: snapshot too old 
Esto puede suceder porque la base de datos Oracle presenta al usuario una vista consistente de los datos tal 
y como son en el momento en que se  inicia  la ejecución de  la consulta. Si hay cambios sin confirmar en  la 
tabla  en  la  que  se  realiza  la  consulta,  la base de datos Oracle  lee  los  datos  de deshacer  para obtener  la 
versión confirmada de los datos. Esto es lo que se denomina consistencia de lectura. 
Si  la  consulta  se  ejecuta  durante  tanto  tiempo  que, mientras  tanto,  esas modificaciones  se  han  acabado 
confirmando  y, posteriormente,  sus datos de deshacer  se han  liberado  y  sobrescrito,  la  consulta de  larga 
ejecución no podrá visualizar una vista consistente de  los datos  tal y como eran en el momento en que se 
inició dicha consulta. Por este motivo,  la  retención de deshacer se debe configurar para que se ajuste a  la 
consulta de ejecución más larga. 
 
Figura 9.5: Control de Deshacer 
9.8.	ADMINISTRACIÓN	DE	DESHACER	
Se  recomienda  el  uso  de  la  gestión  automática  de  deshacer,  que  se  configura mediante  la  definición  del 
parámetro de inicialización UNDO_MANAGEMENT en AUTO (Figura 9.5). La gestión manual de deshacer está 
soportada para  la  compatibilidad  con Oracle8i  y  versiones  anteriores, pero necesita más participación del 
DBA. 
Con  la gestión automática de deshacer, el DBA gestiona  los datos de deshacer en el nivel del  tablespace, 
controla  qué  tablespace  de  deshacer  utiliza  una  instancia  con  el  parámetro  de  inicialización 
UNDO_TABLESPACE.  Una  vez  seleccionado  el  tablespace  de  deshacer,  el  administrador  sólo  se  debe 
preocupar de proporcionar espacio suficiente y de configurar un  intervalo de retención de deshacer (Figura 
9.6). 
Con la gestión manual, el DBA también debe tener en cuenta lo siguiente: 
 Asignación  de  tamaño  a  los  segmentos,  que  incluye  las  extensiones  máximas  y  el  tamaño  de  las 
extensiones 
 Identificación y eliminación de transacciones bloqueantes 
 Creación  de  segmentos  de  rollback  suficientes  para  manejar  transacciones  (en  el  modo  manual  los 
segmentos de deshacer se denominan segmentos de rollback) 
 Selección de un tablespace que contenga  los segmentos de rollback (los tablespaces de deshacer sólo se 
utilizan con la gestión automática de deshacer) 
 
UNIVERSIDAD NACIONAL DE JUJUY 
FACULTAD DE INGENIERIA 
ANALISTA PROGRAMADOR UNIVERSITARIO 
Cátedra: BASE DE DATOS II 
 
Profesor Adjunto:  Ms. Ing. Héctor P. Liberatori  6/8 
 
 
 
Figura 9.6: Administración de Deshacer 
9.9.	CONFIGURACIÓN	DE	RETENCIÓN	DE	DESHACER	
UNDO_RETENTION especifica  (en segundos) el valor de umbral  inferior de  la retención de deshacer. En  los 
tablespaces  de  deshacer  AUTOEXTEND,  el  sistema  retiene  la  operación  de  deshacer  durante  al menos  el 
tiempo especificado en este parámetro y, de manera automática, ajusta el período de retención para cumplir 
con los requisitos de deshacer de las consultas (Figura 9.7). 
En los tablespaces de deshacer de tamaño fijo, el sistema ajusta automáticamente el período máximo posible 
de  retención  de  deshacer  en  función  del  tamaño  e  historial  de  uso  del  tablespace  de  deshacer;  ignora 
UNDO_RETENTION  a  menos  que  esté  activada  la  garantía  de  retención.  De  esta  forma,  en  la  gestión 
automática  de  deshacer,  para  los  tres  casos  aquí mostrados,  se  utiliza  el  valor  de UNDO_RETENTION.  En 
casos distintos a los aquí mostrados, este parámetro se ignora. 
La información de deshacer está dividida en tres categorías: 
 Información de deshacer sin confirmar: soporta una transacción que se está ejecutando en ese momento 
y es necesaria  si un usuario desea  realizar un  rollback o  si  la  transacción ha  fallado. La  información de 
deshacer sin confirmar nunca se sobrescribe. 
 Información de deshacer confirmada: ya no es necesaria para dar soporte a una transacción en ejecución, 
pero  aún  es  necesaria  para  cumplir  con  el  intervalo  de  retención  de  deshacer.  También  se  denomina 
información  de  deshacer  “no  vencida”.  La  información  de  deshacer  confirmada  se  retiene  cuando  es 
posible sin que una transacción activa falle debido a la falta de espacio. 
 Información de deshacer vencida: ya no es necesaria para dar soporte a una transacción en ejecución. La 
información de deshacer vencida se sobrescribe cuando se necesita espacio para una transacción activa. 
 
Figura 9.7: Configuración de Retención de Deshacer 
9.10.	GARANTÍA	DE	RETENCIÓN	DE	DESHACER	
El comportamiento por defecto de deshacer es sobrescribir  las  transacciones confirmadas que aún no han 
vencido, en lugar de permitir que una transacción activa falle debido a la falta de espacio de deshacer. 
 
UNIVERSIDAD NACIONAL DE JUJUY 
FACULTAD DE INGENIERIA 
ANALISTA PROGRAMADOR UNIVERSITARIO 
Cátedra: BASE DE DATOS II 
 
Profesor Adjunto:  Ms. Ing. Héctor P. Liberatori  7/8 
 
 
Este comportamiento se puede cambiar al garantizar  la retención. Con  la retención garantizada,  los valores 
de retención de deshacer se aplican cuando las transacciones fallen (Figura 9.8). RETENTION GUARANTEE 
es un atributo de tablespace más que un parámetro de inicialización. Este atributo sólo se puede cambiar con 
las sentencias de líneade comandos SQL. 
La sintaxis para cambiar un tablespace de deshacer por una retención de garantía es la siguiente: 
SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE; 
Para devolver un tablespace de deshacer garantizado a su valor normal, utilice el siguiente comando: 
SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE; 
La  garantía  de  retención  se  aplica  sólo  a  los  tablespaces  de  deshacer.  Los  intentos  de  definirla  en  un 
tablespace que no sea de deshacer tiene como resultado el siguiente error: 
SQL ALTER TABLESPACE l RETENTION GUARANTEE 
ERROR at line 1: 
ORA-30044: 'Retention' can only specified for undo tablespace 
 
Figura 9.8: Garantía de Retención de Deshacer 
9.11.	TAMAÑO	DE	LOS	TABLESPACES	DE	DESHACER	
Se debe asignar un tamaño a los tablespaces de deshacer para que puedan contener la información original 
de  todas  las  transacciones.  Al  hacer  clic  en  el  enlace Undo Management  de  la  página  Administration  de 
Enterprise Manager aparece una visión general de los datos de deshacer del sistema que incluye los valores 
actuales,  el  consumo  de  deshacer  por  minuto  y  la  longitud  de  la  consulta  con  la  ejecución  más  larga 
observada durante un determinado período de tiempo (Figura 9.9). 
Los  archivos  de datos  que  pertenecen  a un  tablespace  de  deshacer  se  pueden  ampliar  automáticamente 
cuando se quedan sin espacio libre. A diferencia de otros tablespaces, Oracle Corporation recomienda que los 
archivos de datos asociados a  los  tablespaces de deshacer no  tengan activada  la extensión automática. La 
primera vez que se determinan  los requisitos de espacio de deshacer, puede que desee activar la extensión 
automática  de  los  archivos  de  datos,  pero  después  de  haber  asignado  correctamente  el  tamaño  del 
tablespace debe desactivarla. 
La desactivación de la extensión automática en archivos de datos de un tablespace de deshacer evita que un 
único usuario consuma  involuntariamente grandes cantidades de espacio en disco dejando de confirmar las 
transacciones. 
 
UNIVERSIDAD NACIONAL DE JUJUY 
FACULTAD DE INGENIERIA 
ANALISTA PROGRAMADOR UNIVERSITARIO 
Cátedra: BASE DE DATOS II 
 
Profesor Adjunto:  Ms. Ing. Héctor P. Liberatori  8/8 
 
 
 
Figura 9.9: Establecer el tamaño de los Tablespaces de Deshacer con OEM 
9.12.	USO	DEL	ASESOR	DE	DESHACER	
A  través  de  la  página  de  propiedades  Undo Management  se  accede  al  Asesor  de  Deshacer. Ofrece  una 
estimación del  tamaño del  tablespace de deshacer que  resulta necesario para  satisfacer una  retención de 
deshacer determinada (Figura 9.10). 
Indique el período de retención deseado y la región de análisis del asesor mostrará el tamaño de tablespace 
necesario para soportar el período de retención. También cabe  la posibilidad de hacer clic en un punto del 
gráfico para ver el tamaño del tablespace requerido para soportar el período elegido. 
Una  vez  seleccionado  un  período  de  retención  de  deshacer,  haga  clic  en OK  para  implementar  el  nuevo 
período de retención. 
 
Figura 9.10: Asesor de Deshacer