GABD UJA General
|
|
Título del Test:
![]() GABD UJA General Descripción: Todas las preguntas Tipo Test de GABD |



| Comentarios |
|---|
NO HAY REGISTROS |
|
La independencia de datos implica. Cualquier modificación en una BBDD conllevará la necesaria modiificación de las aplicaciones que la accedan. La independencia de datos se establece solo entre la capa física y lógica de la BBDD. Si modificamos el modelo lógico de datos no es necesario modificar el modelo físico de datos. Si modificamos el modelo físico de datos entonces debemos modificar el modelo lógico de datos. Respecto a los procedimientos almacenados. Es un procedimiento que se ejecuta en el DBMS. Es un procedimiento que se almacena en el DBMS, pero se ejecuta en el cliente que lo invoca. Es un procedimiento que se ejecuta en el DBMS, pero se almacena en el cliente que lo invoca. Permite compartir código entre distintas sesiones. Sea la sentencia SQL "INSERT X SET X.a = X.a+1" un disparador declarado "CREATE TRIGGER TRG_UPD_X_A AFTER INSERT FOR EACH ROW". Se ejecutará una única vez, en cualquier caso. Se ejecutará una vez antes de actualizarse cada una de las filas de la tabla X. No tendrá acceso a las variables :new ni :old. Tendrá acceso de lectura a la tabla X. Una tabla mutante. No puede ser leída por un disparador de tupla. No puede ser modificada por un disparador de tupla. Puede ser leída por un disparador de sentencia. Es una tabla a la que le ha picado una araña radioactiva. Respecto a las variables en PL/SQL. Pueden ser de tipo base y de tipo ancla. Las de tipo ancla pueden, entre otras cosas, ser del mismo tipo que una columna de una tabla. Las de tipo ancla pueden, entre otras cosas, almacenar varias filas de una tabla. Las de tipo ancla pueden, entre otras cosas, almacenar una única fila de un cursor. El diccionario de datos. Viene predefinido por el DBMS, que a su vez es el encargado de mantenerlo actualizado. Un usuario solo puede realizar operaciones de lectura sobre éste. Describe, entre otras cosas, el modelo lógico de datos de la BBDD. Describe, entre otras cosas, el modelo físico de datos de la BBDD. En Oracle, los siguientes elementos son parte de la memoria global del sistema. Los espacios de tablas o tablespace. El buffer de la bitácora. La memoria global del proceso. El buffer de datos. En Oracle, el límite marcado por pctfree. Tiene relevancia en operaciones de tipo UPDATE. Incide en el modo que se gestiona el aprovechamiento de los bloques de datos. Debe tener un valor elevado en tablas que raramente son actualizadas. Tiene relevancia en operaciones de tipo DELETE. En Oracle, es posible tener. Una única base de datos y varias instancias manipulándola. Varias bases de datos, manipuladas por una única instancia. Una base de datos replicada en varias máquinas. La base de datos y la instancia en una única máquina. En Oracle, los siguientes elementos son parte de una instancia. La memoria global del sistema (SGA). El proceso de escritura en la base de datos (database writter, o DBWR). SQL* Plus. El proceso de archivado de datos (archiver o ARCH). En Oracle, los espacios de tablas (tablespace). Son manipulados por el proceso database writter (DBWR). Se organizan en segmentos, extensiones y bloques de datos. Se almacenan en uno o más archivos. No son parte de ninguna instancia. En Oracle, una tabla se puede almacenar físicamente. En un único segmento. En un único fichero. En varias extensiones. En varios espacios de tablas. En Oracle, para cada nueva sesión que se conecta a la BBDD, es posible configurar el DBMS para que. Se cree un nuevo proceso servidor. Comparta un proceso servidor con otras sesiones. Se cree una nueva instancia. Comparta la instancia con las demás sesiones. En Oracle, decimos que los grupos de ficheros redolog están multiplexados si y solo si. Hay más de un miembro por grupo. El modo ARCHIVELOG está activado. Hay varios grupos de ficheros redolog online. No hay ficheros redolog offline. En Oracle, los grupos de ficheros redolog. Solo puede haber un grupo de ficheros redolog online por base de datos. Solo hay un grupo de ficheros redolog activo por base de datos. Solo hay un grupo de ficheros redolog por base de datos. Entre otras cosas, permiten que Oracle siga una estrategia de gestión del buffer de datos de tipo robar/no forzar. En Oracle, el límite marcado por pctused. Tiene relevancia en operaciones de tipo DELETE. Debe tener un valor elevado en tablas que raramente son actualizadas. Tiene relevancia en operaciones de tipo UPDATE. Incide en el modo que se gestiona el aprovechamiento de los bloques de datos. En la terminología de Oracle, algunos de los elementos que conforman la base de datos son. Archivos de datos. Archivos redolog. Instancia. Archivos de control. En el diseño físico de la base de datos, sobre una partición se puede afirmar que. Distribuye una tabla entre diferentes segmentos. Cada segmento almacena solo algunas de las columnas de la tabla. Se almacenan físicamente juntas tuplas de un conjunto de tablas que comparten una o más columnas. Todas las particiones de una misma tabla se almacenan en el mismo espacio de tablas. Su finalidad principal es optimizar las operaciones de actualización de datos. Si creamos un índice asociado a una columna de una determinada tabla. Mejorará los tiempos de acceso a la tabla a través de la columna indexada. Mejorará las inserciones de nuevas filas en esa tabla. Conlleva que la columna necesariamente es clave principal o parte de una clave externa. Conlleva que la columna no podrá almacenar valores nulos. Una tabla organizada por índice. Es aquella donde todos los atributos son primos. Es aquella donde almacenamos toda la tupla en el índice asociado a la clave principal. Optimiza el acceso a tablas con pocos atributos no primos. Es aquella cuya clave está indexada. En el diseño físico de la base de datos, sobre un cluster se puede afirmar que. Se almacenan físicamente juntas tuplas de un mismo conjunto de tablas que comparten una o más columnas. Optimiza operaciones de tipo reunión natural atendiendo a los atributos que definen el cluster. Es un tipo de organización física de tabla donde almacenamos toda la tupla en el índice asociado a la clave principal. Una tabla puede pertenecer a varios clusters simultáneamente. Sobre el diseño físico de la base de datos. Su principal objetivo es mejorar el rendimiento de la base de datos. Su principal objetivo es mejorar la integridad de los datos. Es consecuencia directa del diseño lógico de datos. Cualquier modificación del diseño físico de la base de datos conlleva modificar el modelo lógico de datos. En Oracle, los privilegios de tipo sistema. Son necesarios para crear una tabla. Pueden ser asignados a un rol. Pueden ser revocados exclusivamente por el mismo usuarios que lo transmitió. No es posible eliminarlos en cascada. Un usuario en Oracle puede. Tener asignados varios roles y un único perfil. Tener asignados un único rol y un único perfil. Tener asignados un único rol y varios perfiles. Tener asignados varios roles y perfiles. La gestión de privilegios en Oracle. Almacena el instante en que se concedió un privilegio a un usuario. Un usuario puede tener una cantidad indeterminada de privilegios. Si un usuario A revoca un privilegio P a otro usuario B, entonces necesariamente B pierde el privilegio P y a su vez todos aquellos a los que B concedió el privilegio P. Es posible que un mismo privilegio sea asignado a un mismo usuario por varios usuarios. En Oracle, los privilegios de tipo objeto. Pueden ser revocados exclusivamente por el mismo usuario que lo transmitió. Son necesarios para crear una tabla. No es posible eliminarlos en cascada. Pueden ser asignados a un rol. En Oracle, una transacción serializable. Es el mínimo nivel de aislamiento necesario para garantizar que no habrá lecturas sucias. 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 mínimo nivel de aislamiento necesario para garantizar que no habrá lecturas fantasmas. Un planificador que garantice concurrencia, la seriabilidad, 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 ésta, podría implementar una estrategia. Serie. Estrategia B2F conservadora. Estrategia B2F estricta. Estrategia B2F rigurosa. Dadas dos transacciones T1 y T2 y una planificación P, se puede garantizar que. Si P2 es una planificación alternativa a P, y P y P2 son serie, se garantiza que ambas dejarán la base de datos en el mismo estado. Si P es serie, se garantiza que no hay estados conflictivos. Si P es serializable, se garantiza que no hay estados conflictivos. Si P es serie entonces es estricta. Sobre el nivel de aislamiento READ COMMITED de Oracle podemos afirmar. Está libre de interbloqueos. Está libre de borrados en cascada. Está libre de actualizaciones perdidas. Está libre de lecturas sucias. Sobre el nivel de aislamiento SERIALIZABLE de Oracle podemos afirmar. Está libre de interbloqueos. Está libre de actualizaciones perdidas. Está libre de borrados en cascada. Sigue una estrategia de bloqueos B2F. Dadas dos transacciones T1 y T2 que se ejecutan concurrentemente como a continuación se indica, podemos afirmar: Con un nivel de aislamiento READ UNCOMMITED se generaría una lectura fantasma. Con un nivel de aislamiento READ UNCOMMITED se generaría lectura sucia. Con un nivel de aislamiento READ COMMITED se generaría una lectura fantasma. Con un nivel de aislamiento READ COMMITED se generaría una lectura sucia. Un planificador que implemente el protocolo de bloqueo B2F estricto: Garantiza que cualquier planificación será serializable. Garantiza que ninguna transacción quedará en espera indefinida. Garantiza que no habrá interbloqueos. Garantiza que cualquier planificación será recuperable. Dado el siguiente código SQL, ¿qué devolverá la sentencia SELECT de la línea 8 (transacción T2)?. Se generará una excepción en T2. Se generará una excepción en T1. 10. 20. Respecto a ARIES se puede afirmar. Es un algoritmo de recuperación de caídas adecuado para una estrategia del buffer de datos de tipo forzar. Es un algoritmo de recuperación de caídas adecuado para una estrategia del buffer de datos de tipo robar. En la fase de deshacer se retrocede hasta alcanzar el primer evento que hizo que alguna página cambiara a sucia. Los puntos de verificación se graban en el archivo de datos las páginas sucias. El algoritmo de recuperación de caídas de un DBMS debe contar necesariamente con la operación DESHACER si. El algoritmo de gestión del buffer de memoria es de tipo "no forzar escritura". El algoritmo de gestión del buffer de memoria es de tipo "no robar página". Se permiten transacciones de larga duración. Se permiten transacciones concurrentes. En un DBMS donde se sigue un criterio de actualización inmediata de páginas sucias, la primera regla de la escritura anticipada de trazas, WAL#1: No evita que transacciones cometidas puedan perderse. Permite la implementación de la operación DESHACER. Es necesaria si el algoritmo de gestión del buffer de memoria es de tipo "robar página". Es necesaria para garantizar la atomicidad. La fase de "deshacer" en ARIES, en su formulación original. Utiliza el campo lastLSN almacenado en cada traza para deshacer con mayor eficiencia. Deshace tanto aquellos eventos de transacciones que han sido confirmados como los que no. Es precedida por la fase "análisis". Deshace única y exclusivamente aquellos eventos que aún no han sido almacenados en el archivo de datos. En un DBMS donde se sigue un criterio de actualización inmediata de páginas sucias, la segunda regla de la escritura anticipada de trazas, WAL#2: Permite la implementación de la operación DESHACER. Es necesaria para garantizar la atomicidad. Es necesaria si el algoritmo de gestión del buffer de memoria es de tipo "robar página". No evita que transacciones cometidas puedan perderse. El algoritmo de recuperación de caídas de un DBMS debe contar necesariamente con la operación REHACER si. El algoritmo de gestión del buffer de memoria es de tipo "no forzar escritura". Se permiten transacciones concurrentes. El algoritmo de gestión del buffer de memoria es de tipo "no robar página". Se permiten transacciones de larga duración. La fase de "rehacer" en ARIES, en su formulación original. Rehace única y exclusivamente aquellos eventos que aún no han sido almacenadas en el archivo de datos. Utiliza el campo lastLSN almacenado en cada traza para rehacer con mayor eficiencia. Rehace tanto aquellos eventos de transacciones que han sido confirmados como los que no. Es precedida por la fase "deshacer". En ARIES se puede afirmar que la base de datos se encuentra exactamente en el estado que se encontraba en el instante de la caída. Al final de la fase "rehacer". Nunca. Al final de la fase de análisis. Al final de la fase "deshacer". El algoritmo de recuperación de caídas de un DBMS debe contar necesariamente con la operación REHACER si. El algoritmo de gestión del buffer de memoria es de tipo "no robar página". El algoritmo de gestión del buffer de memoria es de tipo "no forzar escritura". Se permiten transacciones concurrentes. Se permiten transacciones de larga duración. El algoritmo de recuperación de caídas de un DBMS debe contar necesariamente con la operación DESHACER si. Se permiten transacciones concurrentes. El algoritmo de gestión del buffer de memoria es de tipo "no robar página". Se permiten transacciones de larga duración. El algoritmo de gestión del buffer de memoria es de tipo "no forzar escritura". |




