Temas GABBDD

INFORMACIÓN
ESTADÍSTICAS
RÉCORDS
Título del test:
Temas GABBDD

Descripción:
Gestión y Administración de BBDD

Autor:
AVATAR

Fecha de Creación:
11/01/2019

Categoría:
Informática
Sigue en facebook las noticias y los mejores tests de daypo apretando en 'Me gusta'
Últimos Comentarios
No hay ningún comentario sobre este test.
Temario:
La independencia de datos implica: Si modificamos el modelo físico de datos entonces debemos modificar el modelo lógico de datos Si modificamos el modelo lógico de datos no es necesario modificar el modelo físico de datos Cualquier modificación en una BBDD conllevará la necesaria modificació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.
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.
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.
Sea la sentencia SQL INSERT X SET X.a=X.a+1. Un disparador declarado “CREATE TRIGGER TRG_UPD_X_A AFTER INSERT” 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 y escritura 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.
El diccionario de datos: Viene predefinido por el DBMS, que a su vez es el encargado de mantenerlo actualizado Un usuario solo puede realizar de 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 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 grupos de ficheros redolog: Entre otras cosas, permiten que Oracle siga una estrategia de gestión del buffer de datos de tipo robar/no forzar Solo hay un grupo de ficheros redolog por base de datos Solo hay un grupo de ficheros redolog activo por base de datos Solo puede haber un grupo de ficheros 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 más de un miembro por grupo El modo ARCHIVELOG está activado No hay ficheros redolog offline.
En Oracle, los espacios de tablas o tablespace: No son parte de ninguna instancia Se organizan en segmentos, extensiones y bloques de datos Son manipulados por el proceso database writter (dbwr) Se almacenan en uno o más archivos.
En Oracle, una tabla se puede almacenar físicamente En un único segmento En varias extensiones En varios espacios de tablas En un único fichero.
En Oracle, el límite marcado por pctfree: Debe tener un valor elevado en tablas que raramente son actualizadas Incide en el modo que se gestiona el aprovechamiento de los bloques de datos Tiene relevancia en operaciones de tipo DELETE Tiene relevancia en operaciones de tipo UPDATE.
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 Se cree una nueva instancia Comparta un proceso servidor con otras sesiones Comparta la instancia con las demás sesiones.
En la terminología de Oracle algunos de los elementos que conforman la base de datos son: Archivos de datos Instancia Archivos redo log Archivos de control.
En Oracle, los siguientes elementos son parte de una instancia: La memoria global del sistema (SGA) SQL*Plus El proceso de escritura en la base de datos (database writter, o DBWR) El proceso de archivado de datos (archiver o ARCH).
En Oracle, los siguientes elementos son parte de la memoria global del sistema La memorial global del proceso El buffer de la bitácora El buffer de datos Los espacios de tablas o tablespace.
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 índice asociado a una columna de una determinada tabla Mejorará los tiempos de acceso a esa tabla a través de la columna indexada Mejorará las inserciones 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.
Una tabla organizada por índice Es aquella donde almacenamos toda la tupla en el índice asociado a la clave principal Es aquella cuya clave está indexada Optimiza el acceso a tablas con pocos atributos no primos Es aquella donde todos los atributos son primos.
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 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.
En el diseño físico de la base de datos, sobre una partición se puede afirmar que: 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 Distribuye una tabla entre diferentes segmentos. Cada segmento almacena solo algunas de las columnas de la tabla Su finalidad principal es optimizar las operaciones de actualización de datos.
La gestión de privilegios en Oracle: Almacena el instante en que se concedió un privilegio a un usuario Es posible que un mismo privilegio sea asignado a un mismo usuario por varios usuarios 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 Un usuario puede tener una cantidad indeterminada de privilegios.
En Oracle, los privilegios de tipo objeto: 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.
En Oracle, los privilegios de tipo sistema: 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.
Un usuario en Oracle puede: Tener asignados varios roles y perfiles Tener asignados varios roles y un único perfil Tener asignados un único role y un único perfil Tener asignados un único role y varios perfiles.
Dado el siguiente código SQL, ¿qué devolverá la sentencia select de la línea 8 (transacción T2) 10 20 se generará una excepción en T1 se generará una excepción en T2.
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 sucia Con un nivel de aislamiento READ UNCOMMITED se generaría una lectura fantasma Con un nivel de aislamiento READ COMMITED se generaría una lectura sucia Con un nivel de aislamiento READ COMMITED se generaría una lectura fantasma.
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 mínimo nivel de aislamiento necesario para garantizar que no habrá lecturas sucias Es el mínimo nivel de aislamiento necesario para garantizar que no habrá lecturas fantasma.
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 P2 es serie, se garantiza que ambas dejarán la base de datos en el mismo estado Si P es serie entonces es estricta.
Un planificador que implemente el protocolo de bloqueo B2F estricto Garantiza que cualquier planificación será serializable Garantiza que cualquier planificación será recuperable Garantiza que no habrá interbloqueos Garantiza que ninguna transacción quedará en espera indefinida.
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 ésta, podría implementar una estrategia Serie Estrategia B2F conservadora Estrategia B2F estricta Estrategia B2F rigurosa.
Sobre el nivel de aislamiento SERIALIZABLE de Oracle podemos afirmar: Está libre de actualizaciones perdidas Está libre de borrados en cascada Está libre de interbloqueos Sigue una estrategia de bloqueos B2F.
Sobre el nivel de aislamiento READ COMMITED de Oracle podemos afirmar Está libre de actualizaciones perdidas Está libre de borrados en cascada Está libre de interbloqueos Está libre de lecturas 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 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 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.
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: Es necesaria para garantizar la atomicidad Es necesaria si el algoritmo de gestión del buffer de memoria es de tipo “robar página” Permite la implementación de la operación DESHACER No evita que transacciones cometidas puedan perderse.
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#2: Es necesaria para garantizar la atomicidad Es necesaria si el algoritmo de gestión del buffer de memoria es de tipo “robar página” Permite la implementación de la operación DESHACER No evita que transacciones cometidas puedan perderse.
Respecto ARIES se puede afirmar: En los puntos de verificación se graban en el archivo de datos las páginas sucias 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 cambara a sucia.
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”.
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”.
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 de análisis Al final de la fase “rehacer” Al final de la de “deshacer” Nunca.
Denunciar test Condiciones de uso
Usamos cookies para personalizar su experiencia. Si sigue navegando estará aceptando su uso. Más información.