GABD

En Oracle, los grupos de ficheros redolog: Entre otras cosas, permiten que Oracle siga una estrategia de gestión de buffer de datos de tipo robar/no forzar. Solo hay un grupo de ficheros redolog por base de datos. El modo ARCHIVELOG está activado. No hay ficheros REDOLOG offline.

En Oracle, los grupos de ficheros REDOLOG: Permiten que Oracle siga una estrategia robar/no forzar. Solo hay un grupo de ficheros REDOLOG por base de datos. Si no se permiten grupos de ficheros REDOLOG multiplexados, solo hay 1 grupo REDOLOG ACTIVE por base de datos. Si no se permiten grupos de ficheros REDOLOG multiplexados, solo hay 1 grupo REDOLOG ONLINE por base de datos.

En Oracle, decimos que los grupos de ficheros REDOLOG están multiplexados si y solo si: Hay varios grupos de ficheros REDOLOG online. Hay mas de 1 miembro por grupo. El modo ARCHIVELOG está activado. No hay ficheros REDOLOG offline.

Respecto a ARIES se puede afirmar: En los CHECKPOINTS se graban en el DATA FILES las DIRTY PAGES. Es un algoritmo de recuperación de caídas adecuado para una estrategia FORCE. Es un algoritmo de recuperación de caídas adecuado para una estrategia STEAL. En la fase de UNDO, se retrocede hasta alcanzar el primer evento que hizo que alguna página cambiara a sucia.

En Oracle, una transacción SERIALIZABLE: Puede generar una excepción si intenta modificar un dato que ha sido modificado en otra transacción T2, tras comenzar T1. Puede realizar lecturas de datos no actualizadas. Es el minimo nivel de aislamiento necesario para garantizar que no habrá DIRTY READS. Es el minimo nivel de aislamiento necesario para garantizar que no habrá PHANTOM READS.

En Oracle, los privilegios de tipo OBJECT: Son necesarios para crear una tabla. Pueden ser revocados exclusivamente por el mismo usuario que lo transmitió. No es posible eliminarlos en cascada. Pueden ser asignados a un ROLE.

El algoritmo de recuperación de caídas de un DBMS debe contar necesariamente con la operación UNDO si: El algoritmo de gestión buffer de memoria es de tipo NO STEAL. El algoritmo de gestión del buffer de memoria es de tipo NO FORCE. Se permiten transacciones concurrentes. Se permiten transacciones de larga duración.

En un DBMS donde se sigue un criterio de INMEDIATE UPDATE de DIRTY PAGES, la WAL#1: Es necesaria para garantizar la ATOMICITY. Es necesaria si el algoritmo de gestión de buffer de memoria es de tipo STEAL. Permite la implementación de la operación UNDO. No evita que transacciones 'committed' puedan perderse.

Un planificador que implementa el protocolo de 2PL ESTRICTO. Garantiza que cualquier planificación será serializable. Garantiza que cualquier planificación será recuperable. Garantiza que no habrá bloqueos. Garantiza que ninguna transacción esperará indefinidamente (sin aplazamiento indefinido).

Con respecto al nivel de aislamiento SERIALIZABLE de Oracle, se puede afirmar lo siguiente: Previene ACTUALIZACIONES PERDIDAS. Previene ELIMINACIONES EN CASCADA. Previene BLOQUEOS. Es una estrategia 2PL (Two-Phase Locking).

La fase de “rehacer” en ARIES, en su formulación original: Rehace única y exclusivamente aquellos eventos que aún no han sido almacenados en el archivo de datos. Rehace tanto aquellos eventos de transacciones que han sido confirmados como los que no. Utiliza el campo lastLSN almacenado en cada traza para rehacer con mayor eficiencia. Es precedida por la fase “deshacer.

Dadas dos transacciones T1 y T2 y una planificación P, se puede garantizar que: Si P es serializable, se garantiza que no hay estados conflictivos. Si P es SERIE, se garantiza que no hay estados conflictivos. Si P2 es una planificación alternativa a P, y P con P2 son serie, se garantiza que ambas dejarán la DB en el mismo estado. Si P es SERIE entonces es ESTRICTO.

Un planificador que garantice concurrencia, la serializabilidad, esté libre de borrados en cascada, no esté libre de interbloqueos y no conozca los datos que va a modificar cada transacción al inicio de esta, podría implementar una estrategia: Serie. Estrategia B2F(2PL) CONSERVADOR. Estrategia B2F(2PL) ESTRICTO. Estrategia B2F(2PL) RIGUROSO.

La fase de “deshacer” en ARIES, en su formulación original: Deshace única y exclusivamente aquellos eventos que aún no han sido almacenados en el archivo de datos. Deshace tanto aquellos eventos de transacciones que han sido confirmados como los que no. Utiliza el campo lastLSN almacenado en cada traza para deshacer con mayor eficiencia. Es precedida por la fase “análisis”. "rehacer" es la fase anterior.

En Oracle, los privilegios de tipo SYSTEM. Son necesarios para crear una tabla. Pueden ser revocados exclusivamente por el mismo usuario que lo transmitió. No es posible eliminarlos en cascada. Pueden ser asignados a un ROLE.

El algoritmo de recuperación de caídas de un DBMS debe contar necesariamente con la operación REDO si: El algoritmo de gestión del buffer de memoria es de tipo NO STEAL. El algoritmo de gestión del buffer de memoria es de tipo NO FORCE. Se permiten transacciones concurrentes. Se permiten transacciones de larga duración.

En la terminología de Oracle algunos de los elementos que conforman la DB son: DATA FILES. INSTANCE. Archivos REDOLOG. Archivos de control.

Sobre el diseño físico de la base de datos: Es consecuencia directa del diseño lógico de datos. Su principal objetivo es mejorar la integridad de los datos. Su principal objetivo es mejorar el rendimiento de la base de datos. Cualquier modificación del diseño físico de la base de datos conlleva modificar el modelo lógico de datos.

Si creamos un INDEX asociado a una comluman de una determinada tabla: Mejorará los TIME ACCESS a esa tabla a través de la columna indexada. Mejorará los INSERTS de nuevas filas en esa tabla. Conlleva que la columna no podrá almacenar valores nulos. Conlleva que la columna necesariamente es clave principal o parte de una clave externa.

En un DBMS donde se sigue un criterio de INMEDIATE UPDATE de DIRTY PAGES, la WAL #2: Es necesaria para garantizar la ATOMICITY. Es necesaria si el algoritmo de gestión de buffer de memoria es de tipo STEAL. Permite la implementación de la operación UNDO. No evita que transacciones 'committed' puedan perderse.