Echándole un vistazo a los foros de Tom Kyte, he encontrado uno en el cual resuelve  un problema que nos encontramos muchas veces los desarrolladores de base de datos. Cuando se realiza la modificación de un registro de una tabla, Oracle efectua efectivamente los cambios sobre la tabla y guarda la operación en el segmento de rollback, de tal forma que podamos deshacer los cambios si es necesario. La memoria ocupada por el segmento de rollback se libera en el momento en el que se realiza un commit o un rollback.

El problema, tal como se plantea en el foro, lo tenemos cuando es preciso modificar a la vez millones de registros de una tabla. El segmento de rollback se desborda y salta un error de memoria. ¿Qué podemos hacer? ¿Aumentar el tamaño del segmento de rollback? ¿Modificar la tabla por partes? La solución aportada por Tom es tan simple que resulta genial … Crear una nueva tabla !!!! El “pseudo-script” sería algo como:

CREATE TABLE nueva_tabla as select <poner aquí la función de modificación> from tabla_original;

Crear índices sobre la nueva tabla

Crear los grants sobre la nueva tabla

Etc.

Drop  table tabla_original;

Rename nueva_tabla to tabla_original;

Artículos relacionados

• No hay artículos relacionados

1. Walter dice:
   28 de julio de 2008 a las 21:26

   Hola a todos,
   Esta opcion no me parece conveniente cuando la tabla que se desa actualizar tiene integridad referencial con otras.
   Para evitar desbordamientos por segmentos de RollBack en la actualizacion de millones de registros, lo conveniente puede ser seccionar la actualizacion y utilizar instrucciones avanzadas como BULK COLLECT y FORALL, que son mas eficiente para estos eventos.

   Cordialmente Walter Huerfano

2. Carlos A. García dice:
   29 de julio de 2008 a las 8:09

   Hola, Walter. Primero, darte las gracias por tu aportación y pedirte que contribuyas al foro. No me gusta soltar monólogos, prefiero diálogos.
   Quizás debería haber dejado claro que la solución aportada por Tom Kyte es para situaciones extraordinarias. No sé tú, pero yo no puedo crear tablas en producción sin la aprobación del DBA, y aun así debe ser él el que ejecute el script.
   A veces no es posible seccionar la actualización, por el otro tipo de restricción que tienen las bases de datos relacionales: integridad transaccional. Es en estas situaciones (y sólo en estas, ya que como bien dices el BULK COLLECT es clarísimamente más eficiente) cuando nos interesa utilizar la técnica CTAS.
   Saludos