UNIVERSIDAD NACIONAL DE SAN MARTN

FACULTAD DE INGENIERA DE SISTEMAS E INFORMTICA

CURSO DOCENTE CICLO TEMA

: : : :

ADMINISTRACION DE BASE DE DATOS ING. ANDY RUCOBA RAMIREZ V

Nombre Integrantes Melndez Coral, Mackennedy Pezo Ruiz, Marquinho Rivera Delgado, Miller Paul Ruiz Marreros, Jorge Junior Salazar Novoa, Franko Ral

Cdigos 107146 107120 107153 107156 117124

Participacin (100%) 100% 100% 100% 100% 100%

SEMESTRE

2013 II

TARAPOTO PER 2013

CONTROL DE CONCURRENCIA Definicin. El control de transacciones concurrentes en una base de datos brinda un eficiente
desempeo del Sistema de Administracin de Base de Datos, puesto que permite controlar la ejecucin de transacciones que operan en paralelo, accediendo a informacin compartida y, por lo tanto, interfiriendo potencialmente unas con otras. El objetivo de los mtodos de control de concurrencia es garantizar la no inferencia o la propiedad de aislamiento de transacciones que se ejecutan de manera concurrente. Los distintos objetivos atacan el problema garantizando que las transacciones se ejecuten en un plan que sea serializable, es decir, que el resultado sea equivalente a el resultante de ejecutar un plan en serie. El criterio de clasificacin ms comn de los algoritmos de control de concurrencia es el tipo de primitiva de sincronizacin. Esto resulta en dos clases: aquellos algoritmos que estn basados en acceso mutuamente exclusivo a datos compartidos (bloqueos) y aquellos que intentar ordenar la ejecucin de las transacciones de acuerdo a un conjunto de reglas (protocolos). Sin embargo, esas primitivas se pueden usar en algoritmos con dos puntos de vista diferentes: el punto de vista pesimista que considera que muchas transacciones tienen conflictos con otras, o el punto de vista optimista que supone que no se presentan muchos conflictos entre transacciones. Los algoritmos pesimistas sincronizan la ejecucin concurrente de las transacciones en su etapa inicial de su ciclo de ejecucin. Los algoritmos optimistas retrasan la sincronizacin de las transacciones hasta su terminacin. Ambos grupos de mtodos, pesimistas y optimistas, consisten de algoritmos basados en bloqueos y algoritmos basados en marcas de tiempo, entre otros. Los protocolos basados en bloqueos son los ms utilizados por los DBMS comerciales. Los dems tienen un alcance ms terico que prctico. Problemas en el Control de Concurrencia. Existen tres formas en las que una transaccin, aunque sea correcta por s misma, puede producir una respuesta incorrecta si alguna otra transaccin interfiere con ella en alguna forma. Consideremos que la transaccin que interfiere tambin puede ser correcta; lo que produce el resultado incorrecto general es el intercalado sin control entre las operaciones de las dos transacciones correctas. Los tres problemas son:

El problema de la Actualizacin Perdida. Una actualizacin se puede perder cuando una transaccin sobrescribe los cambios de otra transaccin. Por ejemplo: dos usuarios pueden actualizar la misma informacin, pero slo la ltima modificacin queda reflejada en la base de datos. El problema de la Dependencia No Confirmada. Una dependencia no confirmada ocurre cuando una transaccin lee los datos sin confirmar de otra transaccin. La transaccin puede hacer cambios segn datos que no son correctos o que no existen.

El problema del Anlisis Inconsistente. Un anlisis incoherente ocurre cuando una transaccin lee la misma fila varias veces y cuando, entre las dos (o ms) lecturas, otra transaccin modifica esa fila. Lecturas Fantasmas. Las lecturas fantasmas pueden ocurrir cuando las transacciones no estn aisladas unas de otras. Por ejemplo: se podra hacer una actualizacin en todos los registros de una regin al mismo tiempo que otra transaccin inserta un nuevo registro de esa regin. La prxima vez que la transaccin lea los datos, aparecer un registro adicional. CONTROL DE CONCURRENCIA EN MYSQL MySQL a partir de las versiones 4.0 instala por defecto el motor de base de datos InnoDB. Su caracterstica principal es que soporta transacciones de tipo ACID, bloqueo de registros e integridad referencial.

InnoDB implementa un bloqueo a nivel de fila estndar, donde hay dos tipos de bloqueos: Compartido (Shared) (S) le permite a una transaccin leer una fila. Exclusivo (Exclusive) (X) le permite a una transaccin actualizar o eliminar una fila. Si una transaccin A sostiene un bloqueo exclusivo (X) sobre una tupla t, entonces una solicitud de otra transaccin B para establecer un bloqueo de cualquier tipo sobre t no puede ser atendida inmediatamente. En lugar de eso, la transaccin B debe esperar a que la transaccin A libere el bloqueo en la tupla t. Si la transaccin A sostiene un bloqueo compartido (S) sobre una tupla t, entonces Una solicitud de otra transaccin B para un bloqueo X sobre t no puede ser atendido inmediatamente. Una solicitud de otra transaccin B para un bloqueo S sobre t puede ser atendido inmediatamente. En consecuencia, tanto A como B sostendrn un bloqueo S sobre t.

Adicionalmente, InnoDB soporta bloqueo de granularidad mltiple (multiple granularity locking), el cual permite que existan simultneamente bloqueos en registros y bloqueos en tablas enteras. Para hacer prctico el nivel de bloqueo de granularidad mltiple, se emplean tipos adicionales de bloqueo, llamados bloqueos de intencin (intention locks). Los bloqueos de intencin son bloqueos de tabla en InnoDB. La idea detrs de los mismos es que una transaccin indique qu tipo de bloqueo (compartido o exclusivo) requerir ms tarde sobre una fila de esa tabla. En InnoDB se utilizan dos tipos de bloqueos de intencin (asumiendo que la transaccin T ha solicitado un bloqueo del tipo indicado en la tabla R):

Intencin compartida (Intention shared) (IS): La transaccin T trata de establecer bloqueos S en tuplas individuales de la tabla T. Intencin exclusiva (Intention exclusive) (IX): La transaccin T trata de establecer bloqueos X en las tuplas. Luego, el protocolo de bloqueo de intencin es el siguiente: Antes de que de una determinada transaccin logre un bloqueo S en una determinada fila, primero debe conseguir establecer un bloqueo IS o superior en la tabla que contiene a la fila. Antes de que de una determinada transaccin logre un bloqueo X en una

determinada fila, primero debe conseguir establecer un bloqueo IX en la tabla que contiene a la fila. OPTIMIZACION DE CONSULTAS Significa buscar la mejor manera de realizar una actividad; por otra define que una consulta es la bsqueda de datos sobre una materia. Aunado a las dos definiciones anteriores expresa que La Optimizacin de Consulta consiste en Mejorar los tiempos de respuesta en la gestin de bases de datos. Siguiendo el mismo orden de ideas otros libros afirma que la Optimizacin de Consultas significa: Mejorar los tiempos de respuesta en un sistema de gestin de bases de datos relacional, pues la optimizacin es el proceso de modificar un sistema para mejorar su eficiencia o tambin el uso de los recursos disponibles. OPTIMIZACION DE CONSULTAS EN MYSQL MySQL permite analizar las consultas y conocer el tiempo y plan de ejecucin. Esta informacin permite comprender lo que hace que las consultas sean lentas y optimizar la ejecucin de stas. Detectar las consultas lentas Para detectar las consultas lentas es posible:
1. Observar las consultas lentas durante su ejecucin y los tiempos de respuesta

anormales.
2. Hacer un benchmark: testear las aplicaciones para ver qu componentes son los

ms lentos. 3. Verificar el Slow query log: es posible activar esta opcin en MySQL configurando la variable --log-slow-queries Una vez detectadas las consultas lentas, la ejecucin del comando EXPLAIN permite comprender la ejecucin y por lo tanto conocer o intervenir para optimizar. Recomendaciones Comparando columnas que tengan el mismo tipo Intente hacer que las columnas indexadas permanezcan solas en las comparaciones No utilice comodines al comienzo de un patrn LIKE Ayude al optimizador a estimar mejor la efectividad de los ndices Use EXPLAIN para verificar la operacin del optimizador. Las pruebas sustituyen a los formularios de las consultas, pero se ejecuta ms de una vez. OPTIMIZACION HEURISTICA

Definicin. De encontrar la solucin de manera emprica, es decir haciendo una prueba, analizando los resultados y formulando nuevas pruebas a base de los errores anteriores. La idea de este mtodo es utilizarlo en los ndices de bsqueda para encontrar el atributo de la condicin porque usan las estadsticas de ocurrencia de los atributos que forman el ndice. Cambiar la consulta original por otra equivalente de forma de minimizar los resultados intermedios.

Pueden existir varias alternativas. Se basa en aplicar equivalencias de los operadores del lgebra de forma que: 1. Las selecciones se apliquen lo antes posible. 2. Las ramas izquierdas de los join sean ms chicas que las derechas. Aplicacin de reglas de transformacin y heursticas para modificar la representacin interna de una consulta (lgebra Relacional o rbol de consulta) a fin de mejorar su rendimiento Varias expresiones del lgebra Relacional pueden corresponder a la misma consulta Optimizacin heurstica en MYSQL Lenguajes de consulta, en MYSQL permiten expresar una misma consulta de muchas formas diferentes, pero el rendimiento no debe depender de cmo sea expresada la consulta. El Analizador Sintctico genera rbol de consulta inicial sin optimizacin Ejecucin ineficiente El Optimizador de Consultas transforma el rbol de consulta inicial en rbol de consulta final equivalente y eficiente Aplicacin de reglas de transformacin guiadas por reglas heursticasConversin de la consulta en su forma cannica equivalente.

CREACION DE INDICES Es una estructura de datos que mejora la velocidad de las operaciones, por medio de identificador nico de cada fila de una tabla, permitiendo un rpido acceso a los registros de una tabla en una base de datos. Al aumentar drsticamente la velocidad de acceso, se suelen usar sobre aquellos campos sobre los cuales se hacen frecuentes bsquedas.

El ndice tiene un funcionamiento similar al ndice de un libro, guardando parejas de elementos: el elemento que se desea indexar y su posicin en la base de datos. Para buscar un elemento que est indexado, slo hay que buscar en el ndice dicho elemento para, una vez encontrado, devolver el registro que se encuentre en la posicin marcada por el ndice. Los ndices pueden ser creados usando una o ms columnas, proporcionando la base tanto para bsquedas rpidas al azar como de un ordenado acceso a registros eficiente. Creacin de ndices en MYSQL
Normalmente, todos los ndices de una tabla se crean al mismo tiempo que se crea la propia tabla con. CREATE INDEX permite aadir ndices a tablas existentes. Una lista de columnas de la forma (col1,col2,...) crea un ndice multi-columna. Los valores de ndice se forman por la concatenacin de valores de las columnas dadas. Para columnas CHAR y VARCHAR, los ndices pueden ser creados para usar slo parte de una columna, usando la sintaxis col_name(longitud) para indexar un prefijo que contiene los primeros 'longitud' caracteres de cada valor de columna. Las columnas BLOB y TEXT tambin pueden ser indexadas, pero se debe proporcionar una longitud de prefijo. La sentencia mostrada a continuacin crea un ndice usando los 10 primeros caracteres de la columna 'name':

A partir de MySQL 4.1.0, algunos motores de almacenamiento permiten especificar un tipo de ndice cuando este es creado. La sintaxis para el especificador index_type es USING type_name. Los valores posibles de type_name soportados por los diferentes motores de almacenamiento se muestran en la siguiente tabla. Cuando se listan varios tipos de ndices, el primero es el valor por defecto cuando no se especifica uno.

PLAN DE EJECUCION DE CONSULTAS EN MYSQL Para poder mejorar el rendimiento de una consulta debemos conocer antes cmo las resuelve MySQL. Es lo que se conoce como proceso de consulta. Cuando MySQL recibe una consulta, procede de la siguiente forma: En primer lugar, busca la consulta en la cach. Si hay suerte, ya tendr los resultados guardados de una consulta anterior y no tendr que resolverla. En segundo lugar, si no ha podido utilizar la cach, analiza la consulta, comprueba su sintaxis e identifica su tipo; es la fase de parseo. Con la informacin obtenida del anlisis, llega al siguiente paso, la planificacin. Este es el punto crtico y del que depender el tiempo de resolucin. El planificador de MySQL decide cual ser el proceso para resolver la consulta, qu parte se resolver primero, qu ndices se utilizarn y cmo se obtendrn los datos. Por ltimo, en la fase de ejecucin solo resta ejecutar el plan trazado y entregar los resultados al cliente. Vamos a ver este proceso paso a paso: La Cach de Consultas MySQL registra las consultas de tipo SELECT y su resultado. Como lo normal es que se acceda a la base de datos a travs de una aplicacin, las consultas repetidas son muy frecuentes (listas de poblaciones, de cdigos, de nombres...). Si MySQL recibe una consulta que tiene en la cach, simplemente entrega al cliente el mismo conjunto de resultados que produjo en su ejecucin anterior. Naturalmente, las consultas de modificacin de datos (INSERT, DELETE, UPDATE...) invalidan las consultas afectadas de la cach y provocan la eliminacin de estas de la cach. Podemos utilizar la cach para mejorar el rendimiento de nuestra base de datos. La variable mysql_cache_type (en my.cnf) establece el tipo de cach que utilizar MySQL. Un valor a 1 har que todas las consultas de tipo SELECT sean cacheadas, salvo que expresamente indiquen lo contrario mediante el modificador SQL_NO_CACHE en la sentencia SELECT. Un valor de query_cache_type igual a 2 har lo contrario. Las consultas no sern cacheadas salvo que expresamente lo soliciten con SQL_CACHE. De esta forma podremos controlar y mejorar la calidad de la cach, haciendo que las consultas repetidas sean cacheadas y evitando que las consultas que no se repiten (buscadores, datos de un cliente...) consuman espacio de almacenamiento. El tamao de la cache se establece en la variable query_cache_size. Y el lmite de almacenamiento por consulta en la variable query_cache_limit. La estrategia concreta de uso de estas variables depender de las caractersticas del servidor y de la aplicacin. Anlisis El proceso de anlisis (parseo), MySQL determina el tipo de consulta, las tablas relacionadas, las caractersticas de la clausula WHERE... pero todo esto apenas tiene incidencia en el rendimiento. Lo nico que puedes tener en cuenta es, que cuanto ms largas sean las consultas, ms tiempo de anlisis necesitarn. As que, lo bueno

si breve, dos veces bueno. Planificacin El planificador es el punto crtico en la resolucin de una consulta. Del plan de ejecucin que elabore depender que la consulta tarde unas pocas dcimas de segundo o varios minutos. Pero el trabajo del Planificador no es fcil, para entenderlo debemos tener en cuenta dos factores: El planificador trabaja para cualquier consulta. No es viable programar un planificador especfico para nuestra aplicacin, as que nos tenemos que conformar con el planificador de MySQL. Este est optimizado para cualquier aplicacin. Y, aunque acumula los aos de experiencia de los programadores de MySQL y utiliza estadsticas de ejecucin para decidir cul ser el mejor plan, no siempre acertar. En segundo lugar, el planificador no tiene tiempo de encontrar la solucin ptima. Sera absurdo que utilizara tres segundos en planificar una consulta que, en el peor de los casos, slo requerir dos segundos para resolverse. El planificador debe encontrar el mejor plan posible, en el menor tiempo posible. Por eso necesitamos conocer cmo trabaja, qu decisiones toma y, sobre todo, como influir en sus decisiones cuando nos convenga. Centrndonos en lo importante, el planificador debe decidir dos aspectos principales en el plan de ejecucin: qu ndice se va a utilizar para resolver la consulta y en qu orden se realizarn los joins de las tablas. Vamos a revisar primero los tipos de ndices que hay en MySQL para despus analizar cmo toma sus decisiones el Planificador. ESTIMACION DE COSTOS DE PROCESAMIENTO DE CONSULTAS El costo de un plan es la suma de los costos de los operadores que contiene El costo de cada operador es estimado obteniendo informacin del catlogo, tal como tamaos de las tablas, organizacin fsica y estructuras de bsquedas definidas. Tambin se requiere para esto estimar los tamaos de los resultados de los operadores internos, porque ellos sern usados para otros operadores cuyo costo de ejecucin depende del tamao de sus operando. La mtrica usada para la estimacin de costos es el nmero de operaciones de entrada y salida que se requieren en el plan.

El volumen de operaciones en memoria principal o tiempo de CPU, en general, no es considerado en el costo de los planes en consultas a bases de datos por ser este un

problema ligado al acceso a disco (I/O Bound) y no ligado a memoria o CPU (Memory Bound o CPU Bound). BALANCEO DE CARGAS Metodologa para distribuir la carga de trabajo entre varios equipos o un clster de ordenadores, conexiones de red, unidades centrales de procesamiento, unidades de disco u otros recursos, para lograr la utilizacin ptima de los recursos, maximizar el rendimiento, minimizar el tiempo de respuesta y evitar la sobrecarga. Existen varios mtodos que los DBA puede utilizar para que de una manera inteligente enruten los requerimientos entrantes del usuario a una arquitectura escalamiento MySQL. A travs del uso de los balanceadores de carga, los entrantes del usuario se enrutan a la base de datos MySQL apropiada. En un escenario de escalamiento MySQL, el balanceador de carga puede estar basado tanto en un hardware como en un software. Un ejemplo del balance basado en un hardware es un enrutador inteligente que puede interceptar los requerimientos entrantes y sabe a qu servidor MySQL enviarlos. El balanceo de carga basado en un software es tambin llamado solicitud lgica. La solicitud final se construy en la solicitud misma para enrutar el requerimiento al servidor MySQL correcto.