DABD_U3_A2_GAMQ

ADMINISTRACIÓN DE BASE DE DATOS

Unidad III: Administrar bases de datos

Actividad 2: Comandos de operación, secuencia y bitácoras

Profesor: Christian Leonel Islas Sánchez

Alumno: Gamaliel Marín Quebrado

Matrícula: AL13509837

13 de mayo de 2016

Introducción: Ahora, deberás analizar y discutir sobre aplicación de comandos de operación, la secuencia de los mismos y las bitácoras que se derivan. Por lo tanto:

1. Entra al Foro con subida de archivos y responde a las siguientes preguntas, en el orden que tu docente en línea las modere: ¿Qué es y para qué sirve un modo de operación en un sistema gestor de bases de datos? Los modos definen la sintaxis SQL que un Sistema Gestor de Base de Datos (SGBD) debe soportar y qué clase de chequeos de validación de datos debe efectuar. Esto hace más fácil usar un SGBD en un conjunto de entornos diferentes y con otros servidores de bases de datos. Un SGBD puede operar en distintos modos SQL y puede aplicar los modos de forma diferente para distintos clientes. Esto permite a una aplicación adaptar el funcionamiento del servidor a sus propios requerimientos.

¿Menciona un modo de operación de los que leíste y para qué sirve? Dos de los valores de los modos sql_mode más importantes son:

 STRICT_TRANS_TABLES Si un valor no puede insertarse tal y como se da en una tabla transaccional, se aborta el comando. Para tablas no transaccionales, aborta el comando si el valor se encuentra en un comando que implique un sólo registro o el primer registro de un comando de varios registros.

 ALLOW_INVALID_DATES No hace un chequeo total de los datos en modo estricto. Chequea sólo que los meses se encuentran en el rango de 1 a 12 y que los días están en el rango de 1 a 31. Esto es muy conveniente para aplicaciones Web donde obtiene un año, mes y día en tres campos distintos y quiere guardar exactamente lo que inserta el usuario (sin validación de datos). Este modo se aplica a columnas de tipo DATE y DATETIME. No se aplica a columnas TIMESTAMP, que siempre requieren una fecha válida. Este modo se implementó en MySQL 5.0.2. Antes de 5.0.2, este era el modo por defecto de MySQL para tratar datos. Desde 5.0.2, el permitir el modo estricto provoca que el servidor requiera que el mes y día se evalúen como valores legales y no simplemente en los rangos de 1 a 12 y de 1 a 31, respectivamente. Por ejemplo, '2016-04-31' es legal con el modo estricto desactivado, pero ilegal con el modo estricto activado.

¿Qué función tienen los registros de bitácora en un sistema gestor de bases de datos y cómo pueden ser administrados?

Una bitácora en un SGBD es usada para grabar las modificaciones de la base de datos, esta herramienta permite registrar, analizar detectar y notificar eventos que suceden en la base de datos. La función de las bitácoras es la de recuperar información ante incidentes de seguridad, detección de comportamiento inusual, información para resolver problemas, evidencia legal. Cada registro de la bitácora escribe una única escritura de base de datos y tiene lo siguiente: Nombre de la transacción: Nombre de la transacción que realizó la operación de escritura. Nombre del dato: El nombre único del dato escrito. Valor antiguo: El valor del dato antes de la escritura. Valor nuevo: El valor que tendrá el dato después de la escritura. Es fundamental que siempre se cree un registro en la bitácora cuando se realice una escritura antes de que se modifique la base de datos. También se tiene la posibilidad de deshacer una modificación que ya se ha escrito en la base de datos, esto se realizará usando el campo del valor antiguo de los registros de la bitácora. Los registros de la bitácora deben residir en memoria estable como resultado el volumen de datos en la bitácora puede ser exageradamente grande. Una bitácora puede registrar mucha información acerca de eventos relacionados con el sistema que la genera, los cuales pueden ser:    

Fecha y hora. Host origen. Usuario. Actividad realizada.

Las bitácoras se guardan en archivos de registros que pueden ayudar a encontrar lo que está sucediendo. En MySQL se maneja 4 tipos de bitácoras, administradas en 4 diferentes tipos de registros, que son:

 El registro de error. Registra problemas encontrados iniciando, ejecutando, o parando MySQL.  El registro de consultas. Registra las conexiones de clientes establecidas y las sentencias ejecutadas.  El registro binario. Registra todas las sentencias que cambian datos. También utilizado para replicación.  El registro de lentitud. Registra todas las sentencias que tardaron más de long_query_time segundos en ejecutarse, o no utilizaron índices.

2. Explica la propiedad de atomicidad que es considerada en las transacciones y revisa los aportes de tus compañeros. Por regla general en un sistema de base de datos todas las operaciones relacionadas entre sí que se ejecuten dentro un mismo flujo lógico de trabajo, deben ejecutarse en bloque. De esta manera si todas funcionan la

operación conjunta de bloque tiene éxito, pero si falla cualquiera de ellas, deberán retrocederse todas las anteriores que ya se hayan realizado. De esta forma evitamos que el sistema de datos quede en un estado incongruente. Por ejemplo, si vamos al banco y ordenamos una transferencia para pagar una compra que hemos realizado por Internet, el proceso en sí está formado por una conjuto (o bloque) de operaciones que deben ser realizadas para que la operación global tenga éxito:

1. Comprobar que nuestra cuenta existe es válida y está operativa. 2. Comprobar si hay saldo en nuestra cuenta. 3. Comprobar los datos de la cuenta del vendedor (que existe, que tiene posibilidad de recibir dinero, etc...). 4. Retirar el dinero de nuestra cuenta 5. Ingresar el dinero en la cuenta del vendedor. Dentro de este proceso hay cinco operaciones, las cuales deben tener éxito o fallar conjuntamente. En el caso de las operaciones 4 y 5 que modifican datos es algo obvio que no puede funcionar una y fallar la otra. Si se retira el dinero de nuestra cuenta en el paso 4 y hay algún problema que evita que pueda continuar el proceso, el dinero habrá salido de nuestra cuenta pero no se ha anotado en la cuenta de destino porque se ha producido un error. De repente hay un dinero que ha desaparecido y la base de datos se encuentra en un estado inconsistente. Es evidente que esto no puede ocurrir. Precisamente para evitar este tipo de situaciones existen las transacciones: marcan bloques completos de operaciones y comprueban que, o se realizan todas, o que si hay algún problema se deshacen todas. En nuestro ejemplo de transferencia fallida, al producirse un error en el paso 5 se habría deshecho automáticamente la operación de retirada de dinero del paso 4 y toda la información habría quedado como antes de comenzar el proceso. Propiedades ACID (de sus siglas en inglés: Atomicity, Consistency, Isolation y Durability). Una transacción, para cumplir con su propósito y protegernos de todos los problemas que hemos visto, debe presentar las siguientes características: Atomicidad: las operaciones que componen una transacción deben considerarse como una sola. Una transacción tiene que ser una serie atómica (“todo o nada”) de operaciones que o bien tiene éxito y serán confirmadas (COMMIT) o todas las operaciones son deshechas (ROLBACK). Otra forma de explicar la propiedad de atomicidad de una transacción es que todas las sentencias dentro de la transacción deben ejecutarse sin errores. Si por algún motivo no se cumplen, la transacción aborta en el punto de ruptura y deshace todo los cambios realizados. Como quien dice “¡O todo o Nada!”. Atomicidad significa que una transacción no se puede subdividir. Ya sea que se realice todo el trabajo en la transacción o que no se haga nada. Por ejemplo, la transacción en un cajero automático no representará débito en una cuenta sin también acreditar una cuenta correspondiente. La propiedad atómica implica que los cambios parciales que realiza una transacción deben deshacerse si ésta se cancela.

Consistencia: una operación nunca deberá dejar datos inconsistentes. Aislamiento: los datos "sucios" deben estar aislados, y evitar que los usuarios utilicen información que aún no está confirmado o validado. (Por ejemplo: ¿sigue siendo válido el saldo mientras realizo la operación?) Durabilidad: una vez completada la transacción los datos actualizados ya serán permanentes y confirmados.

Referencias:  Michael V. Mannino; Administración de Base de Datos Diseño y Desarrollo de Aplicaciones; Tercera Edición; McGraw-Hill; ISBN:13 13: 978-970-10-6109; México; 2007  Manual de referencia de MySQL 5.7; Consultado el 12 de mayo del 2016 en la siguiente dirección: http://dev.mysql.com/doc/refman/5.7/en/  SQL Transactions Teoría y ejercicios en la práctica, DBTech VET, 2014. Consultado el 12 de mayo del 2016 en la siguiente dirección: http://myy.haaga-helia.fi/~dbms/dbtechnet/download/SQLTransactions_handbook_SP.pdf