exposicion de evaluacion

actividad # 20

actividad # 21

Confiabilidad

La confiabilidad es otro requerimiento indiscutible y probablemente el más importante. Una base de datos no confiable es simplemente inutilizable. Para la mayoría de las aplicaciones empotradas, en especial las empleadas en sistemas de tiempo real, la confiabilidad es una propiedad no negociable que deben tener
todos los componentes.Un sistema de manejo de bases de datos confiable es aquel que puede continua procesando las solicitudes de usuario aún cuando el sistema sobre el que opera no es confiable. En otras palabras, aun cuando los componentes de un sistema distribuido fallen, un DDMBS confiable debe seguir ejecutando las solicitudes de usuario sin violar la consistencia de la base de datos.

Protocolos REDO/UNDO. 
El registro de la base de datos contiene información que es utilizada por el proceso de recuperación para restablecer la base de datos a un estado consistente. Esta información puede incluir entre otras cosas:

• el identificador de la transacción,
• el tipo de operación realizada,
• los datos accesados por la transacción para realizar la acción,
• l valor anterior del dato (imagen anterior), y
• el valor nuevo del dato (imagen nueva).

Considere el escenario mostrado en la Figura de abajo. El DBMS inicia la ejecución en el tiempo 0 y en el tiempo t se presenta una falla del sistema. Durante el periodo [0, t] ocurren dos transacciones, T1 y T2. T1 ha sido concluida (ha realizado su commit) pero T2 no pudo ser concluida. La propiedad de durabilidad requiere que los efectos de T1 sean reflejados en la base de datos estable. De forma similar, la propiedad de atomicidad requiere que la base de datos estable no contenga alguno de los efectos de T2.


Puntos de verificación (checkpoints).
Cuando ocurre una falla en el sistema es necesario consultar la bitácora para determinar cuáles son las transacciones que necesitan volver a hacerse y cuando no necesitan hacerse. Estos puntos de verificación nos ayudan para reducir el gasto de tiempo consultando la bitácora. El punto de verificación es un registro que se genera en la bitácora para concluir en todo lo que se encuentra antes de ese punto está correcto y verificado.


Protocolo 2PC de confiabilidad distribuida. 
El protocolo 2PC básico un agente (un agente-DTM en el modelo) con un rol especial. Este es llamado el coordinador; todos los demás agentes que deben hacer commit a la vez son llamados participantes.
El coordinador es responsable de tomar la decisión de llevar a cabo un commit o abort finalmente. Cada participante corresponde a una subtransacción la cual ha realizado alguna acción de escritura en su base de datos local. Se puede asumir que cada participante está en un sitio diferente. Aun si un participante y el coordinador se encuentran en el mismo sitio, se sigue el protocolo como si estuvieran en distintos sitios. La idea básica del 2PC es determinar una decisión única para todos los participantes con respecto a hacer commit o abort en todas las subtransacciones locales.El protocolo consiste en dos fases:

• La primera fase tiene como objetivo alcanzar una decisión común,
• La meta de la segunda fase es implementar esta decisión.

El protocolo procede como sigue:
Fase uno:

• El coordinador escribe “prepare” en la bitácora y envía un mensaje donde pregunta a todos los participantes si preparan el commit (PREPARE).
• Cada participante escribe “ready” (y registra las subtransacciones) en su propia bitácora si está listo o “abort” de lo contrario.
• Cada participante responde con un mensaje READY o ABORT al coordinador.
• El coordinador decide el commit o abort en la transacción como un resultado de las respuestas que ha recibido de los participantes. Si todos respondieron READY, decide hacer un commit. Si alguno ha respondido ABORT o no ha respondido en un intervalo de tiempo determinado se aborta la transacción.

Fase dos:

• El coordinador registra la decisión tomada en almacenamiento estable; es decir, escribe “global_commit” o “global_abort” en la bitácora.
• El coordinador envía mensaje de COMMIT o ABORT según sea el caso para su ejecución.
• Todos los participantes escriben un commit o abort en la bitácora basados en el mensaje recibido del coordinador (desde este momento el procedimiento de recuperación es capaz de asegurar que el efecto de la subtransacción no será perdido).

Finalmente:

• Todos los participantes envían un mensaje de acuse de recibo (ACK) al coordinador, y ejecutan las acciones requeridas para terminar (commit) o abortar (abort) la subtransacción.
• Cuando el coordinador ha recibido un mensaje ACK de todos los participantes, escribe un nuevo tipo de registro en la bitácora, llamado un registro “completo”.

informacion

actividad # 19

Disciplinas del Interbloqueo: prevención, detección, eliminación y recuperación. 

Las estrategias de prevención de interbloqueo son muy conservadoras; resuelven el problema limitando el acceso a recursos e imponiendo  restricciones sobre los procesos. En cambio, las estrategias de detección de interbloqueo, no limitan el acceso a recursos ni restringen las acciones del proceso. La detección del interbloqueo es el proceso de determinar si realmente existe un interbloqueo e identificar los procesos y recursos implicados en él. Una posibilidad detectar un interbloqueo es monitorear cada cierto tiempo el estado de los recursos. Cada vez que se solicita o se devuelve un recurso, se actualiza el estado de los recursos y se hace una verificación para observar si existe algún ciclo.
Este método está basado en suponer que un interbloqueo no ser presente y que los recursos del sistema que han sido asignados, se liberarán en el momento que otro proceso lo requiera.
Una comprobación para interbloqueo puede hacerse con igual o menor frecuencia que cada solicitud de recursos, dependiendo de que tan probable es que ocurra un interbloqueo. Comprobar cada solicitud de recursos tiene dos ventajas: Conduce a la detección temprana y el algoritmo es simple, de
manera relativa porque se basa en cambios crecientes al estado del sistema. Además, las comprobaciones frecuentes consumen un tiempo considerable de procesador.

Un solo Tipo

Usaremos una variante del grafo de asignación de recursos, llamado grafo de espera. Podemos obtener este grafo a partir del grafo de asignación de recursos, eliminando los nodos correspondientes al recurso y uniendo los arcos de forma que habrá un arco del proceso Pi al proceso Pj, si Pj tiene un recurso que Pi ha solicitado. Existirá un interbloqueo si y solo si hay un ciclo en el grafo resultante.Para detectar un interbloqueo, el sistema necesita mantener el grafo de espera y periódicamente invocar un algoritmo que busque un ciclo en el grafo.


Varios tipos de recursos

Este algoritmo de detección emplea estructuras de datos que varían con el tiempo, muy similares a las que se usan en el algoritmo del banquero:

Variable                   Contenido
Disponible [m]         Número de recursos disponible de cada tipo
Asignado [n,m]        Cantidad de recursos asignados a los procesos
Petición [n,m]          Petición o solicitud actual de cada proceso

Estructuras de datos auxiliares:
Trabajo [m]: Acumula los recursos de los procesos que pueden evolucionar
Acabado[n]: Booleano que indica cuando un proceso ha acabado
Algoritmo:
Función Detección retorna Booleano
Trabajo:=Disponible
Para todo i
Sí Asignado [i] m<>0 Entonces
Acabado[i]:=False
Sino
Acabado[i]:= true
Fin Si
Fin Para
Mientras haya un i tal que Acabado [i]:=False y Petición [i]<=Trabajo
Trabajo:=Trabajo+Asignado[i]
Acabado[i]:= True
Fin Mientras
Si hay un i tal que Acabado [i]= False Entonces
Detección:=True
Sino
Detección:=False
Fin Si
El algoritmo de detección escrito se limita a investigar cada una de las
posibles secuencias de asignación para los procesos que quedan por
terminar. Aquellos procesos para los que Acabado[i] tengan un valor de
falso, formarán parte de un interbloqueo.



Recuperación de Interbloqueo
Cuando se ha detectado que existe un interbloqueo, podemos actuar de
varias formas. Una posibilidad es informar al operador que ha ocurrido un
interbloqueo y dejar que el operador se ocupe de él manualmente. La otra
posibilidad es dejar que el sistema se recupere automáticamente del
interbloqueo. Dentro de esta recuperación automática tenemos dos opciones
para romper el interbloqueo: Una consiste en abortar uno o más procesos
hasta romper la espera circular, y la segunda es apropiar algunos recursos
de uno o más de los procesos bloqueados.

La recuperación después de un interbloqueo se complica porque puede no
estar claro que el sistema se haya bloqueado.
Los procesos pueden eliminarse de acuerdo con algún orden de prioridad,
aunque es posible que no existan prioridades entre los procesos
bloqueados, de modo que el operador necesita tomar una decisión arbitraria
para decidir que procesos se eliminarán.

Recuperación Manual
Está forma de recuperación consiste en avisarle al administrador o al 

operador del sistema que se ha presentado un interbloqueo, y será el
administrador el que solucione dicho problema de la manera más
conveniente posible, de modo que su decisión no afecte demasiado a al
usuario del proceso en conflicto, y sobre todo que no afecte a los demás
usuarios del sistema.

Abortar los Procesos
Para eliminar interbloqueos abortando un proceso, tenemos dos métodos;
en ambos, el sistema recupera todos los recursos asignados a los procesos
terminados.

1. Abortar todos los procesos interbloqueados. Esta es una de las soluciones más comunes, adoptada por Sistemas Operativos. Este método romperá definitivamente el ciclo de interbloqueo pero con un costo muy elevado, ya que estos procesos efectuaron cálculos durante mucho tiempo y habrá que descartar los resultados de estos cálculos parciales, para quizá tener que volver a calcularlos más tarde.
2. Abortar un proceso en cada ocasión hasta eliminar el ciclo de interbloqueo. El orden en que se seleccionan los procesos para abortarlos debe basarse en algún criterio de costo mínimo. Después de cada aborto, debe solicitarse de nuevo el algoritmo de detección, para ver si todavía existe el interbloqueo. Este método cae en mucho tiempo de procesamiento adicional.

Si se utiliza el método de terminación parcial, entonces, dado un conjunto de procesos bloqueados, debemos determinar cuál proceso o procesos debe terminarse para intentar romper el interbloqueo. Se trata sobre todo de una cuestión económica, debemos abortar los procesos que nos representen el menor costo posible. Existen muchos factores que determinan el proceso que se seleccionará, siendo los principales los
siguientes:

1. La prioridad del proceso. Se elimina el proceso de menor prioridad.
2. Tiempo de procesador usado. Se abortará aquel proceso que haya utilizado menos tiempo el procesador, ya que se pierde menos trabajo y será más fácil recuperarlo más tarde.
3. Tipos de recursos utilizados. Si los recursos son muy necesarios y escasos será preferible liberarlos cuanto antes.
4. Cuántos recursos más necesita el proceso. Es conveniente eliminar a aquellos procesos que necesitan un gran número de recursos.
5. Facilidad de suspensión / reanudación.Se eliminarán aquellos procesos cuyo trabajo perdido sea más fácil de recuperar.Apropiación de Recursos

Apropiación de recursos
Para eliminar interbloqueos utilizando la apropiación de recursos, vamos quitando sucesivamente recursos de los procesos y los asignamos a otros hasta romper el ciclo de interbloqueo. Si se utiliza la apropiación de recursos para tratar los interbloqueos, hay que considerar tres aspectos:

• Selección de la víctima
• Retroceso
• Bloqueo indefinido

La detección y recuperación es la estrategia que a menudo se utiliza en  grandes computadoras, especialmente sistemas por lote en los que la eliminación de un proceso y después su re iniciación suele aceptarse

actividad #18

Algoritmos de Control de Concurrencia

Basados en Bloqueos

En los algoritmos basados en candados, las transacciones indican sus intenciones solicitando candados al despachador (llamado el administrador de candados). Los candados son de lectura (rl), también llamados compartidos, o de escritura (wl), también llamados exclusivos. Como se aprecia en la tabla siguiente, los candados de lectura presentan conflictos con los candados de escritura, dado que las operaciones de lectura y escritura son incompatibles.

	rl	wl
rl	Si	No
Wl	No	No

En sistemas basados en candados, el despachador es un administrador de candados (LM). El administrador de transacciones le pasa al administrador de candados la operación sobre la base de datos (lectura o escritura) e información asociada, como por ejemplo el elemento de datos que es accesado y el identificador de la transacción que está enviando la operación a la base de datos. El administrador de candados verifica si el elemento de datos que se quiere accesar ya ha sido bloqueado por un candado. Si candado solicitado es incompatible con el candado con que el dato está bloqueado, entonces, la transacción solicitante es retrasada. De otra forma, el candado se define sobre el dato en el modo deseado y la operación a la base de datos es transferida al procesador de datos. El administrador de transacciones es informado luego sobre el resultado de la operación. La terminación de una transacción libera todos los candados y se puede iniciar otra transacción que estaba esperando el acceso al mismo dato.

Basados en estampas de tiempo

A diferencia de los algoritmos basados en candados, los algoritmos basados en estampas de tiempo no pretenden mantener la seriabilidad por exclusión mutua. En lugar de eso, ellos seleccionan un orden de serialización a priori y ejecutan las transacciones de acuerdo a ellas. Para establecer este ordenamiento, el administrador de transacciones le asigna a cada transacción Ti una estampa de tiempo única ts (Ti ) cuando ésta inicia. Una estampa de tiempo es un identificador simple que sirve para identificar cada transacción de manera única. Otra propiedad de las estampas de tiempo es la monoticidad , esto es, dos estampas de tiempo generadas por el mismo administrador de transacciones deben ser monotonicamente crecientes. Así, las estampas de tiempo son valores derivados de un dominio totalmente ordenado.

Control de concurrencia optimista 

asumen que los conflictos entre transacciones, son muy frecuentes y no permiten el acceso a un dato si existe una transacción conflictiva que accesa el mismo dato. Así, la ejecución de cualquier operación de una transacción sigue la secuencia de fases: 

• validación (V), 
• lectura (R),
• cómputo (C) y
• escritura (W)

Los algoritmos optimistas, por otra parte, retrasan la fase de validación justo antes de la fase de escritura . De esta manera, una operación sometida a un despachador optimista nunca es retrasada. Las operaciones de lectura, cómputo y escrita de cada transacción se procesan libremente sin actualizar la base de datos corriente. 

La fase de validación consiste en verificar si esas actualizaciones conservan la consistencia de la base de datos. Si la respuesta es positiva, los cambios se hacen globales (escritos en la base de datos corriente). De otra manera, la transacción es abortada y tiene que reiniciar

actividad # 17 B

Los mecanismos de control de transacciones para una base de datos distribuida

En la norma SQL el comienzo de una transacción se especifica explícitamente (usualmente begin/start transaction) 

Las transacciones terminan con una de las siguientes instrucciones: 

commit work (compromete la transacción actual)

 rollback work (provoca que la transacción aborte Si el programa termina sin ninguna de estas órdenes, los cambios se comprometen o abortan según indique cada sistema)

savepoint: guarda un punto de recuperación, es muy útil ya que podemos regresar al punto deseado.

Estructura de una transacción

La estructura de una transacción usualmente viene dada según el modelo de la transacción, estas pueden ser planas (simples) o anidadas.

Transacciones planas: Consisten en una secuencia de operaciones primitivas encerradas entre las palabras clave BEGIN y END. Por ejemplo: 

            BEGIN _TRANSACTION Reservación

              ....

             END.

Transacciones Anidadas: Consiste en tener transacciones que dependen de otras, estas transacciones están incluidas dentro de otras de un nivel superior y se las conoce como subtransacciones. La transacción de nivel superior puede producir hijos (subtransacciones) que hagan más fácil la programación del sistema y mejoras del desempeño.

En las transacciones anidadas las operaciones de una transacción pueden ser así mismo otras transacciones. Por ejemplo:

 Una transacción anidada dentro de otra conserva las mismas propiedades que las de su padre, esto implica, que puede contener así mismo transacciones dentro de ella.

Operaciones de una transacción

• Inicio de Transacción: Operación que marca el momento en el que una transacción comienza a ejecutarse.
• Leer o Escribir: Operaciones de lectura/escritura de elementos de la base de datos.
• Fin de la Transacción: Se verifica si la transacción debe abortarse por alguna razón.
• Confirmar (COMMIT): La operación termino con éxito.
• Abortar (ROLLBACK): La transacción termino sin éxito.

Estados de una Transacción

• Transacción Activa: se encuentra en este estado justo después de iniciar su ejecución.
• Transacción Parcialmente Confirmada: en este punto, se efectúan diferentes operaciones de verificación para asegurar que la transacción no interfiera con otras transacciones en ejecución.
• Transacción Confirmada: Ha concluido su ejecución con éxito.
• Transacción Fallida: En este caso, es posible que la transacción deba ser cancelada.
• Transacción Terminada: indica que la transacción a abandonado el sistema.

Representación de los estados de una transacción

Ejecución de transacciones distribuidas 
Una transacción distribuida asegura la actualización consistente del estado global del sistema o la restauración del estado previo si la transacción no termina. Un sistema de transacciones distribuidas pretende garantizar las propiedades transaccionales pese al fallo de alguno de sus componentes. Estos sistemas, a diferencia de los basados en comunicación a grupos, asumen siempre un modelo de sistema síncrono; si un proceso no responde en un plazo prefijado, se considera que el proceso falla.

El algoritmo para ejecutar la transacción es el siguiente:

• El iniciador envía a todos los participantes un mensaje de inicio con la transacción y un plazo de tiempo para realizarla.

• Cada participante (incluido el iniciador):
1. Recibe el mensaje de inicio de la transacción.
2. Ejecuta las operaciones especificadas en la transacción.
3. Dependiendo del resultado, establece su voto, SI o NO, para la actualización del estado global.
4. Ejecuta un protocolo de acuerdo atómico.

actividad #17 A

Transacciones

Se llama transacción a una colección de operaciones que forman una unidad lógica de trabajo en una BD realizada por una o más sentencias SQL estrechamente relacionadas.

Una transacción es una unidad de la ejecución de un programa que lee y escribe datos a y desde la Base de Datos. Puede consistir en varias operaciones de acceso a la base de datos. Una Transacción está delimitada por instrucciones de inicio transacción y fin transacción (la transacción consiste en todas las operaciones que se ejecutan entre inicio transacción y fin transacción).

Las transacciones agrupan una serie de operaciones de manera que es posible garantizar la integridad del resultado final. O todas las operaciones se ejecutan con éxito y se confirman (se escriben en la base de datos), o toda la transacción se considera no realizada. La acción de cancelar una transacción se denomina deshacer la transacción. Deshacer una transacción permite anular los cambios y recuperar el estado de la base de datos previo a la transacción.

Propiedades de la Transacción

Una unidad lógica de trabajo debe exhibir cuatro propiedades, conocidas como propiedades ACID (atomicidad, coherencia, aislamiento y durabilidad), para ser calificada como transacción.

Atomicity: Una Transacción (Tx) se ejecuta completamente o de otra manera se eliminan los cambios parciales realizados.

Begin Transaction - Programa - End Transaction

Responsable: El método de recuperación, de no completar todas las operaciones, devuelve la BD a su estado anterior a empezar esa Tx rollback).

Coherencia: Asegura que los datos que observamos no cambian (por otros usuarios) hasta que acabemos la Transacción.

Después de terminar una Transacción la Base de datos no viola ninguna de sus reglas: valores obligatorios, claves únicas, etc.

Responsable: los programadores mediante la definición adecuada de la integridad referencial: check, triggers, primary key, foreign key,…

Aislamiento: Los efectos de una Tx no son visibles a otros usuarios mientras no se confirmen.

Una Transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de finalizar.

Durabilidad: Si el sistema falla no debe permitir que se pierdan las operaciones realizadas por Tx ya confirmadas.

Funcionamiento de una transacción:

En este diagrama se puede observar que el principio de O se hace bien o no se hace se mantiene.

Control de transacciones en Oracle

Inicio de transacción

Cuando no hay ya una transacción en progreso, y se ejecuta una sentencia LDD o LMD.

Cada sentencia LDD es tratada como una transacción N No existe sentencia de tipo BEGIN TRANSACTION

Fin de transacción

COMMIT: Finaliza la transacción actual y hace permanentes (confirma) los cambios realizados

ROLLBACK: Finaliza la transacción actual y deshace los cambios realizados. En caso de que la transacción no se complete o haya un error.

Sentencia COMMIT

Una sentencia COMMIT marca el final de una transacción correcta, implícita o definida por el usuario. COMMIT hace que todas las modificaciones efectuadas sobre los datos desde el inicio de la transacción sean parte permanente de la base de datos, y además, libera los recursos mantenidos por la conexión. Su sintaxis es la siguiente:

COMMIT COMMENT 'mensaje' | FORCE 'texto']

COMMENT sirve para comentar la transacción en un máximo 255 caracteres.

FORCE fuera de modo manual una transacción dudosa y es de uso exclusivo en sistemas distribuidos de base de datos.

Una vez que el COMMIT t se presenta en una transacción y asegura que todo salió bien, entonces los usuario puede utilizar las tablas y registros que al empezar la transacción se bloquearon.

Sentencia SAVEPOINT

Esta sentencia permite crear un punto de restauración dentro de una transacción, es decir, un punto al que podremos retroceder deshaciendo todo lo hecho deshaciendo todo lo hecho desde él en adelante. Su sintaxis es la siguiente:

SAVEPOINT nombrePuntoRestauración;

Sentencia ROLLBACK

Señala el final sin éxito de una transacción, elimina todas las modificaciones de datos realizadas desde el inicio de la transacción y también libera los recursos que retiene la transacción. Su sintaxis es la siguiente:

ROLLBACK [WORK] [TO SAVEPOINT nombre PuntoRestauración | FORCE 'texto'];

Lo que básicamente hace este código es regresar todo a como estaba al momento de iniciar la transacción esta función es de gran utilidad ya que en caso de un error sea el que sea, mantiene los valores congruentes.

Grados de consistencia

Consistencia es un término más amplio que el de integridad. Podría definirse como la coherencia entre todos los datos de la base de datos. Cuando se pierde la integridad también se pierde la consistencia. Pero la consistencia también puede perderse por razones de funcionamiento.

·         Una transacción finalizada (confirmada parcialmente) puede no confirmarse definitivamente (consistencia).

·         Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos.

·         Si se anula los cambios que ha efectuado son deshechos.

·         La ejecución de una transacción debe conducir a un estado de la base de datos consistente (que cumple todas las restricciones de integridad definidas).

·         Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos.

·         Si se anula los cambios que ha efectuado son deshechos.

Una transacción que termina con éxito se dice que está comprometida (commited), una transacción que haya sido comprometida llevará a la base de datos a un nuevo estado consistente que debe permanecer incluso si hay un fallo en el sistema. En cualquier momento una transacción sólo puede estar en uno de los siguientes estados:

·         Activa (Active): el estado inicial; la transacción permanece en este estado durante su ejecución.

·         Parcialmente comprometida (Uncommited): Después de ejecutarse la última transacción.

·         Fallida (Failed): tras descubrir que no se puede continuar la ejecución normal.

·         Abortada (Rolled Back): después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción.

·         Comprometida (Commited): tras completarse con éxito.

Niveles de aislamiento

Las transacciones especifican un nivel de aislamiento que define el grado en que se debe aislar una transacción de las modificaciones de recursos o datos realizadas por otras transacciones. Los niveles de aislamiento se describen en cuanto a los efectos secundarios de la simultaneidad que se permiten, como las lecturas desfasadas o ficticias.

Control de los niveles de aislamiento de transacción:

·         Controla si se 11realizan bloqueos cuando se leen los datos y qué tipos de bloqueos se solicitan.

·         Duración de los bloqueos de lectura.

·         Si una operación de lectura que hace referencia a filas modificadas por otra transacción:

o    Se bloquea hasta que se libera el bloqueo exclusivo de la fila.

o    Recupera la versión confirmada de la fila que existía en el momento en el que empezó la instrucción o la transacción.

o    Lee la modificación de los datos no confirmados.

El nivel de aislamiento para una sesión SQL establece el comportamiento de los bloqueos para las instrucciones SQL.

Se usa el aislamiento en:

Lectura sucia. Las sentencias SELECT son ejecutadas sin realizar bloqueos, pero podría usarse una versión anterior de un registro. Por lo tanto, las lecturas no son consistentes al usar este nivel de aislamiento.

·         Lectura no repetible. Una transacción vuelve a leer datos que previamente había leído y encuentra que han sido modificados o eliminados por una transacción cursada.

·         Lectura fantasma. Una transacción vuelve a ejecutar una consulta, devolviendo un conjunto de registros que satisfacen una condición de búsqueda y encuentra que otros registro que satisfacen la condición han sido insertadas por otra transacción cursada.

COMMIT Y ROLLBACK

Ejemplo básico en MySQL precio del dolar con respecto al peso 1995 al 2012.

CREATE TABLE IF NOT EXISTS dolar ( fecha DATE, precio DECIMAL (8,4), PRIMARY KEY (fecha)) ENGINE = InnoDB DEFAULT CHARSET=latin1;

 

Lecturas consistentes

Por default, las tablas InnoDB ejecutan una  lectura consistente (consistent read). Esto significa que cuando una sentencia SELECT es ejecutada, MySQL regresa los valores presentes en la base de datos hasta la transacción más reciente que ha sido completada.

Si alguna transacción está en progreso, los cambios hechos por alguna sentencia DELETE, INSERT o UPDATE no serán reflejados. Sin embargo, existe una excepción: las transacciones abiertas si pueden ver sus propios cambios. Para demostrar esto, necesitamos establecer dos conexiones al servidor MySQL.

actividad # 16

optimización de consultas

El objetivo del procesamiento de consultas en un ambiente distribuido es transformar una consulta sobre una base de datos distribuida en una especificación de alto nivel a una estrategia de ejecución eficiente expresada en un lenguaje de bajo nivel sobre bases de datos locales.

Así, el problema de optimización de consultas es minimizar una función de costo tal que

función de costo total = costo de I/O + costo de CPU + costo de comunicación

Los diferentes factores pueden tener pesos diferentes dependiendo del ambiente distribuido en el que se trabaje. Por ejemplo, en las redes de área amplia (WAN), normalmente el costo de comunicación domina dado que hay una velocidad de comunicación relativamente baja, los canales están saturados y el trabajo adicional requerido por los protocolos de comunicación es considerable. Así, los algoritmos diseñados para trabajar en una WAN, por lo general, ignoran los costos de CPU y de I/O. En redes de área local (LAN) el costo de comunicación no es tan dominante, así que se consideran los tres factores con pesos variables.

Operación Complejidad

La complejidad de las operaciones sugiere dos principios:

1. Dado que la complejidad es con base en las cardinalidades de las relaciones, las operaciones más selectivas que reducen las cardinalidades deben ser ejecutadas primero.

2. Las operaciones deben ser ordenadas en el orden de complejidad creciente de manera que el producto Cartesiano puede ser evitado o, al menos, ejecutado al final de la estrategia.

Tipo de optimización

El problema de optimización de consultas es altamente demandante en tiempo de ejecución y, en el caso general, es un problema de la clase NP. Así existen dos estrategias para su solución: búsqueda exhaustiva o el uso de heurísticas. Los algoritmos de búsqueda exhaustiva tienen una complejidad combinatorial en el número de relaciones de la consulta. Obtienen la transformación óptima, pero sólo se aplican a consultas simples dado su tiempo de ejecución.

Por otro lado, los algoritmos heurísticos obtienen solo aproximaciones a la transformación óptima pero lo hacen en un tiempo de ejecución razonable. Las heurísticas más directas a aplicar son el agrupamiento de expresiones comunes para evitar el cálculo repetido de las mismas, aplicar primero las operaciones de selección y proyección, reemplazar una junta por una serie de semijuntas y reordenar operaciones para reducir el tamaño de las relaciones intermedias.

Granularidad de la optimización

Tiempo de optimización

Una consulta puede ser optimizada en tiempos diferentes con relación a tiempo de ejecución de la consulta. La optimización se puede realizar de manera estática antes de ejecutar la consulta o de forma dinámica durante la ejecución de la consulta. 

La optimización estática se hace en tiempo de compilación de la consulta. Así, el costo de la optimización puede ser amortizada sobre múltiples ejecuciones de la misma consulta. 

Durante la optimización de consultas dinámica la elección de la mejor operación siguiente se puede hacer basado en el conocimiento exacto de los resultados de las operaciones anteriores. Por tanto, se requiere tener estadísticas acerca del tamaño de los resultados intermedios para aplicar esta estrategia. 

Un tercer enfoque, conocido como híbrido, utiliza básicamente un enfoque estático, pero se puede aplicar un enfoque dinámico cuando los tamaños de las relaciones estimados están alejados de los tamaños actuales.

Optimización Global de Consultas: El objetivo de esta capa es hallar una estrategia de ejecución para la consulta cercana a la óptima. La estrategia de ejecución para una consulta distribuida puede ser descrita con los operadores del álgebra relacional y con primitivas de comunicación para transferir datos entre nodos. Para encontrar una buena transformación se consideran las características de los fragmentos, tales como, sus cardinalidades.

Optimización Local de Consultas: El trabajo de la última capa se efectúa en todos los nodos con fragmentos involucrados en la consulta. Cada subconsulta que se ejecuta en un nodo, llamada consulta local, es optimizada usando el esquema local del nodo. Hasta este momento, se pueden eligen los algoritmos para realizar las operaciones relacionales. La optimización local utiliza los algoritmos de sistemas centralizados.

Estrategias de procesamiento de consultas distribuidas

Transformaciones equivalentes

Cuando una base de datos se encuentra en multiples servidores y distribuye a un numero determinado de nodos tenemos:

1.-el servidor recive una peticion de un nodo

2.-el servidor es atacado por el acceso concurrente a la base de datos cargada localmente

3.-el servidor muestra un resultado y le da un hilo a cada una de las maquinas nodo de la red local.

Cuando una base de datos es accesada de esta manera la técnica que se utiliza es la de fragmentación de datos que puede ser hibrida, horizontal y vertical.

En esta fragmentación lo que no se quiere es perder la consistencia de los datos, por lo tanto se respetan las formas normales de la base de datos.

Bueno para realizar una transformación en la consulta primero desfragmentamos siguiendo los estandares marcados por las reglas formales y posteriormente realizamos el envio y la maquina que recibe es la que muestra el resultado pertinente para el usuario, de esta se puede producir una copia que sera la equivalente a la original.

 Métodos de ejecución de join

Sean (R) y s(S) dos relaciones:
Si R S= entonces r s es lo mismo que r x s, y por lo tanto se puede utilizar la estimación del producto cartesiano.
Si R S es una clave de R entonces el número de tuplas en r s no es mayor que el número de tuplas en S. Si R S es una clave externa de R entonces el número de tuplas de r s es exactamente el número de tuplas de S.
Si R S no es clave de R ni de S entonces se supone que cada valor aparece con la misma probabilidad , por lo tanto, sea t una tupla de r y sea R S=Ā, entonces se estima que la tupla t produce :
tuplas en s, por lo tanto se estima el tamaño de r s = (a) al cambiar los papeles de r y s se tiene (b)
Estos valores serán distintos si y sólo si V(A,r) V(A,s), si este es el caso, la más baja estimación de ambas será la más conveniente.
Join en bucles anidados.
Si z = r s, r recibirá el nombre de relación externa y s se llamará relación interna, el algoritmo de bucles anidados se puede presentar como sigue.
para cada tupla tr en rpara cada tupla ts en ssi (tr,ts) satisface la condición entonces añadir tr ts al resultado Algoritmo 5–1 - Join en bucles anidados.
Donde tr ts será la concatenación de las tuplas tr y ts .

Como para cada registro de r se tiene que realizar una exploración completa de s, y suponiendo el peor caso, en el cual la memoria intermedia sólo puede concatenar un bloque de cada relación, entonces el número de bloques a acceder es de . Por otro lado, en el mejor de los casos si se pueden contener ambas relaciones en la memoria intermedia entonces sólo se necesitarían accesos a bloques.

Ahora bien, si la más pequeña de ambas relaciones cabe completamente en la memoria, es conveniente utilizar esta relación como la relación interna, utilizando así sólo accesos a bloques.

Join en bucles anidados por bloques.

Una variante del algoritmo anterior puede lograr un ahorro en el acceso a bloques si se procesan las relaciones por bloques en vez de por tuplas.

para cada bloque Br de rpara cada bloque Bs de spara cada tupla tr en Brpara cada tupla ts en Bssi (tr,ts) satisface la condición entonces añadir tr ts al resultado

Algoritmo 5–2 - Join en bucles anidados por bloques.

La diferencia principal en costos de este algoritmo con el anterior es que en el peor de los casos cada bloque de la relación interna s se lee una vez por cada bloque de r y no por cada tupla de la relación externa, de este modo el número de bloques a acceder es de donde además resulta más conveniente utilizar la relación más pequeña como la relación externa.

Join en bucles anidados por índices.

Este algoritmo simplemente sustituye las búsquedas en tablas por búsquedas en índices, esto puede ocurrir siempre y cuando exista un índice en el atributo de join de la relación interna. Este método se utiliza cuando existen índices así como cuando se crean índices temporales con el único propósito de evaluar la reunión.

El costo de este algoritmo se puede calcular como sigue: para cada tupla de la relación externa r se realiza una búsqueda en el índice de s para recuperar las tuplas apropiadas, sea c = costo de la búsqueda en el índice, el cual se puede calcular con cualquiera de los algoritmos A3, A4 o A5. Entonces el costo del join es ; si hay índices disponibles para el atributo de join en ambas relaciones, es conveniente utilizar la relación con menos tuplas.

Join por mezcla.

El algoritmo de Join por mezcla se pude utilizar para calcular un Join natural o un equi-join. Para tales efectos ambas relaciones deben estar ordenadas por los atributos en común.

Este algoritmo asocia un puntero a cada relación, al principio estos punteros apuntan al inicio de cada una de la relaciones. Según avanza el algoritmo, el puntero se mueve a través de la relación. De este modo se leen en memoria un grupo de tuplas de una relación con el mismo valor en los atributos de la reunión.

link de la informacion