LOGGING/NOLOGGING ayuda a administrar la habilitación de escrituras de rutas directas para reducir la generación de REDO y UNDO. Es una de varias formas de controlar el delicado equilibrio entre la capacidad de recuperación y el rendimiento.
Información general sobre la arquitectura de Oracle
REHACER es como Oracle proporciona durabilidad, la "D" en ACID. Cuando se confirma una transacción, los cambios no se almacenan necesariamente de forma ordenada en los archivos de datos. Eso mantiene las cosas rápidas y permite que los procesos en segundo plano manejen algo de trabajo. REDO es una descripción del cambio. Se almacena rápidamente, en varios discos, en un registro "tonto". Los cambios son rápidos y si el servidor pierde energía un microsegundo después de que se devolvió la confirmación, Oracle puede revisar los registros REDO para asegurarse de que el cambio no se pierda.
DESHACER ayuda a Oracle a proporcionar consistencia, la "C" en ACID. Almacena una descripción de cómo revertir el cambio. Esta información puede ser necesaria para otro proceso que esté leyendo la tabla y necesite saber cuál es el valor usado estar en un momento anterior.
Escrituras de rutas directas omita REDO, UNDO, el caché y algunas otras funciones, y modifique directamente los archivos de datos. Esta es una opción rápida pero potencialmente peligrosa en muchos entornos, razón por la cual existen tantas opciones confusas para controlarla. Las escrituras de rutas directas solo se aplican a INSERTOS, y solo en los escenarios que se describen a continuación.
Si no hace nada, la opción predeterminada es la más segura, INICIAR SESIÓN.
Las muchas formas de controlar las escrituras de rutas directas
LOGGING/NOLOGGING es una de varias opciones para controlar las escrituras de rutas directas. Mire esta tabla de Pregúntale a Tom para comprender cómo funcionan juntas las diferentes opciones:
Table Mode Insert Mode ArchiveLog mode result
----------- ------------- ----------------- ----------
LOGGING APPEND ARCHIVE LOG redo generated
NOLOGGING APPEND ARCHIVE LOG no redo
LOGGING no append ARCHIVE LOG redo generated
NOLOGGING no append ARCHIVE LOG redo generated
LOGGING APPEND noarchive log mode no redo
NOLOGGING APPEND noarchive log mode no redo
LOGGING no append noarchive log mode redo generated
NOLOGGING no append noarchive log mode redo generated
FORCE LOGGING puede anular todas esas configuraciones. Probablemente hay algunos otros interruptores que no conozco. Y, por supuesto, existen muchas limitaciones que impiden la ruta directa:activadores, claves externas, clúster, tablas organizadas por índice, etc.
Las reglas son aún más restrictivas para los índices. Un índice siempre generar REDO durante declaraciones DML. Solo declaraciones DDL, como CREATE INDEX ... NOLOGGING o ALTER INDEX ... REBUILD en un índice NOLOGGING no generará REDO.
¿Por qué hay tantas formas? Porque la capacidad de recuperación es increíblemente importante y los diferentes roles pueden tener diferentes puntos de vista al respecto. Y a veces las decisiones de algunas personas deben anular otras.
Desarrolladores decidir en el nivel de declaración, "Modo de inserción". Muchas cosas raras pueden pasar con un /*+ APPEND */ sugerencia y los desarrolladores deben elegir cuidadosamente cuándo usarla.
Arquitectos decidir a nivel de objeto, "Modo Tabla". Algunas tablas, independientemente de la rapidez con la que un desarrollador quiera insertarlas, siempre deben ser recuperables.
Administradores de bases de datos decida en el modo de base de datos o tablespace, "Archivar registro" y FORZAR REGISTRO. Tal vez a la organización simplemente no le importe recuperar una base de datos específica, así que configúrela en modo NOARCHIVELOG. O tal vez la organización tiene una regla estricta de que todo debe ser recuperable, así que establezca el tablespace en FORCE LOGGING.
