2008-10-10 10 views
8

No soy DBA, y estoy teniendo dificultades para comprender el proceso de administración de transacciones de Oracle.Oracle: ¿cómo funcionan la transacción, el segmento de retrotracción y el parámetro deshacer restauración?

Por lo que entendí al leer algunas páginas de aspecto fiables en Internet (más notablemente este AskTom note - pero no se moleste con los comentarios), cuando se compromete una transacción, los nuevos datos se no informó sobre el bloque de datos real aún, pero permanece registrado en el segmento de reversión. Cuando alguien emite un SELECT en los datos, o cuando han transcurrido los segundos UNDO_RETENTION (lo que ocurra primero en estos dos eventos), los datos nuevos se escriben (y solo entonces) en los bloques de datos.

Pero alguien en nuestra compañía, supuestamente enterado, recientemente me dijo lo contrario: según él, cuando se compromete una transacción, los nuevos datos son escritos inmediatamente en los bloques de datos, y el segmento rollback/deshacer tablespace mantiene los datos anteriores durante un tiempo de UNDO_RETENTION segundos. Estos datos antiguos permanecen disponibles durante este tiempo para el acceso de las consultas iniciadas en los SCN antes de la transacción.

Entonces, ¿qué sucede realmente dentro de Oracle, y puede proporcionar referencias para respaldar su respuesta?

Estamos usando Oracle 9.2.0.8.

Gracias de antemano.

Respuesta

13

¡Hay mucho por cubrir aquí! La persona en su compañía es esencialmente correcta, excepto que los cambios se escriben en el bloque de datos en la memoria a medida que se crean, incluso antes de la confirmación; y se escriben en el disco de forma completamente independiente de cuando se confirma (posiblemente antes, posiblemente después, nunca como parte de la operación de confirmación).

1) UNDO_RETENCIÓN no tiene nada que ver con cuando sus cambios se escriben en el bloque de datos, ya sea en la memoria o en el disco. UNDO_RETENTION controla cuánto tiempo los datos necesarios para deshacer su cambio persisten DESPUÉS de que usted confirme el cambio. El propósito es que otras consultas o transacciones serializables que comenzaron antes de su confirmación aún puedan querer esa información. Referencia: http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/undo.htm#sthref1477

2) Cuando hace una actualización, los bloques de datos en la memoria se modifican.Pueden o no escribirse en el disco (incluso antes de comprometerse, creo); esto se hace mediante un proceso en segundo plano. Además, la información de rehacer se escribe en el búfer de registro redo. Deshacer se genera y se almacena en un segmento de deshacer.

3) Cuando se compromete, Oracle se asegura de que su información de rehacer se escriba en el disco y marca los datos de deshacer como confirmados. Pero no escribe los bloques de datos modificados en la memoria en el disco, ni retrocede y marca cada bloque como confirmado. Esto es para hacer el compromiso lo más rápido posible. Referencia: http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/transact.htm#sthref628

4) Los bloques de datos en la memoria se marcarán como comprometidos cuando se escriben en disco por el proceso de fondo o la próxima vez que se utilizan (mediante SELECCIONAR o cualquier otra operación). Eso es lo que está discutiendo la nota AskTom. No se trata de si sus cambios en los datos se escriben en el bloque; se trata de si están marcados como cometidos en el bloque mismo.

+0

Gracias por esta exhaustiva respuesta. – Manur

+2

Sí, tienes razón en que los bloques sucios se pueden escribir en el disco antes de que se produzca la confirmación. Esta es la razón por la cual una instrucción SELECT puede generar rehacer, puede necesitar realizar una "limpieza de bloque demorada". La parte importante es que una confirmación solo garantiza que la escritura se escribe en el disco, no los datos en sí. –

0

Mi comprensión es (básicamente) la última, This link tiene los detalles.

Los bloques de datos no tienen que escribirse, simplemente se actualizan en el búfer, pueden escribirse o no en el disco. El rehacer debe escribirse en el disco antes de que pueda continuar la confirmación.

0

También voto por la segunda versión basada en
link (que es Oracle 10.2, pero creo que todavía se aplica a 9.2 también). Dice: "Después de confirmar una transacción, los datos de deshacer ya no son necesarios para retrotracción o recuperación de transacciones. Sin embargo, para fines de lectura consistentes, las consultas de larga ejecución pueden requerir esta información antigua de deshacer para producir imágenes antiguas de bloques de datos ".

y

"Cuando se habilita la gestión automática de deshacer, siempre hay un período de retención de deshacer actual, que es la cantidad mínima de tiempo que la base de datos Oracle intenta retener vieja información de deshacer antes de sobrescribirlo."

Cuestiones relacionadas