Actividad 4. Reporte con similitudes y diferencias de un disco duro para instalar MySQL

Actividad 4. Reporte con similitudes y diferencias de un disco duro para instalar MySQL Primera Unidad

Universidad Abierta y a Distancia de Mxico21/04/2015Alumno: Roberto Nieto Morales al13502595Asignatura: Administracin de Base de DatosCuarto SemestreDocente: Liliana Corona Granados

1. Redacta un reporte donde incluyas las consideraciones para preparar un disco duro cuando se va a instalar el MySQL y una base de datos.

Cuando intentamos hacer ms rpida una aplicacin de bases de datos, hay que empezar con la aplicacin en s y asegurarse de que las tablas estn normalizadas de forma adecuada, y las columnas estn indexadas, esto es siempre un buen comienzo. Pero si ya se ha hecho todo lo anterior y las cosas siguen siendo lentas.Entonces los pasos previos a la instalacin de MySQL (al igual que otro software cuya instalacin sea crtica) se deben tomar ciertas consideraciones para preparar en un disco duro la instalacin de MySQL. Comprobar hardware mnimo necesario Decidir la distribucin. MySQL est disponible para numerosas plataformas, hay que decidir cul es la que nos interesa, en base a la caracterstica del sistema, fiabilidad, buena integracin etc. Decidir el formato de distribucin. Hay dos posibilidades: Distribucin binaria. Se trata de una forma ms fcil y rpida de instalar. Puede ser a travs de un instalador preparado o bien a travs de binarios genricos comprimidos. En el ltimo caso, simplemente con descomprimir y realizar unos cuantos ajustes, tenemos la instalacin finalizada. Cdigo fuente. Se trata de que debemos compilar el cdigo fuente para que funcione el SGBD. Es ms complicada de realizar pero permite un mayor control de todos los componentes a instalar, as como preparar un ejecutable optimo para nuestro sistema o bien incluso modificar el cdigo (que es C y C++).Memoria en el discoDel lado del servidor, el nico y ms importante factor en determinar cmo de bien rendir MySQL, es la memoria. MySQL es capaz de ejecutar varios subprocesos a la vez. Esto significa que cada vez que se realiza una conexin, MySQL crea un subproceso. Cada subproceso consume memoria. El almacenamiento en cach de los resultados tambin consume memoria. Se puede pensar entonces, que entre ms memoria tengamos en el servidor, ser lo mejor. Sin embargo no es suficiente con tener mucha memoria disponible, es necesario indicarle a MySQL como queremos que use la memoria.En la administracin del disco duro los datos estn organizados por bloques que pueden ser manejados por tamaos fijos o variables, el acceso a cierto bloque de datos en un disco duro variara de acuerdo a la suma del tiempo que tarda en brazo del cabezal a la pista correcta del plato, esperar la rotacin del eje hasta el sector que deber ser ledo y en transferir los datos desde el inicio del sector hasta el extremo del sector.El proceso de lectura y escritura dentro del disco duro ocurre cuando el brazo del cabezal se desplaza al sector indicado para leer o escribir los datos que se procesan dentro de MySQL.El SGBD puede leer una seccin continua de datos desde el disco duro, por medio de peticiones de operaciones de exploracin al sistema operativo, para organizar los datos en el disco duro en un orden secuencial, al optimizar MySQL mediante comando optimize table, las tablas de sus grupos de registros y de los ndices son agrupadas en forma de bloque-Las configuraciones por defecto de MySQL son bastante conservadoras para el hardware de hoy en da, sin embargo, si se tiene un servidor MySQL dedicado con varios cientos de mega bytes de RAM, se debe ser capaz de darle a MySQL una porcin bastante grande de ella para trabajar. Por defecto, slo usar una pequea porcin de lo que haya disponible; esto se debe a que no hay ninguna forma de saber si est corriendo en un servidor dedicado donde ser usado de forma continua o si est corriendo en un esforzado porttil donde slo se usa para almacenar una pequea aplicacin.Mucha de la informacin presentada a continuacin se centrar en el uso de la memoria y se asume que se est usando el tipo de tabla por defecto de MySQL, MyISAM. Actualmente existen otros tipos de tablas transaccionales ms avanzadas, tales como InnoDB o Gemini.MySQL usa la memoria para una variedad de bfferes internos y cachs que influyen en el nmero de veces que se ha de acceder a archivos que residen en el disco. Cuanto ms a menudo tenga que esperar a que responda un disco, ms lento ser. An los discos duros ms modernos siguen siendo un orden de magnitud ms lenta que la memoria RAM, y dado la reciente baja en los precios de la memoria, es muy factible que se pueda aadir ms memoria al servidor y as acelerar los procesos. Actualizar a discos duros ms rpidos debera ser la ltima opcin.Los bfferes y cachs de MySQL son de dos tipos: globales, y por hilo.Globales: tal y como sugiere el nombre, estas reas de memoria son reservadas una vez y son compartidas a travs de todos los hilos de MySQL. Dos de los ms importantes son el bffer de claves y la cach de tablas. Debido a que son bfferes compartidos, el objetivo es que sean lo ms grandes posibles.Por hilo: estos bfferes reservan memoria individualmente a medida que necesitan realizar operaciones particulares, tales como ordenar o agrupar datos. A propsito, la mayora de los bfferes MySQL se reservan en esta forma.A continuacin se examina primero que funcin tienen cada uno de los bfferes y como configurar e inspeccionar sus valores, posteriormente se mostrar como examinar contadores de rendimiento de MySQL y juzgar si los cambios que se realizan tienen implicaciones o no.Uso de memoriaEl bffer de claves es donde MySQL cachea los bloques de ndices para tablas MyISAM. Cada vez que una bsqueda usa un ndice, MySQL mirar antes de nada a ver si el ndice relevante est o no en memoria. El parmetro key_buffer en el archivo my.cnf determina que tan grande puede ser este bffer. Una vez que el bffer este lleno, MySQL har sitio para nuevos datos reemplazando datos antiguos que no hayan sido usados recientemente.El tamao del bffer de claves aparece como key_buffer_size en la salida de SHOW VARIABLES. Con un bffer de claves 384 Mega Bytes, se vera algo como:key_buffer_size 402649088Como una recomendacin general, en un servidor MySQL dedicado se debera reservar entre el 20 y el 50 por ciento de la memoria RAM para el bffer de claves de MySQL. Si se tiene un giga byte de memoria se puede empezar con algo como:set-variable= key_buffer= 128M incluso:set-variable= key_buffer= 256MSi slo se permitiera modificar un parmetro en el servidor MySQL, el bffer de claves sera lo primero que se tendra que considerar. Los ndices son tambin muy importantes para el rendimiento global de cualquier servidor de bases de datos por lo que es difcil equivocarse al hacer ms espacio en su memoria para ellos.Si no se especifica un tamao al bffer de claves, MySQL usar su tamao por defecto que est cerca de los 8MB. Pero claro, tiene muy poco sentido configurar el valor del bffer de claves tan alto, hacerlo podra matar de hambre al sistema operativo respecto a la memoria que necesita para escrituras de disco y otras tareas.Base de datosHablando especficamente de las tablas que integrarn la base de datos, en MySQL, debe respetarse un tamao mximo, el cual vara dependiendo del sistema operativo donde se encuentre instalado el MySQL.Al conocer estos datos el administrador y planeador de la base de datos conocers el mximo crecimiento al que puede llegar una base de datos.El tamao de las tablas variar dependiendo del tamao de los tipos de datos, los cuales pueden ser comnmente: numricos, caracteres y fechas.Existen valores null, este se considera como valor no existente y se puede aplicar a todos los tipos de columnas; existen tambin smbolos utilizados para la definicin de los diferentes tipos de datos en MisLas tablas MyISAM estn compuestas de tres archivos en disco:El archivo de datos nombredetabla.MYD, el archivo ndice nombredetabla.MYI, y finalmente, el archivo de definicin de la tabla llamado nombredetabla.FRM. Para poder usar una nica tabla, MySQL necesita de hecho abrir los tres archivos. El archivo .FRM se cerrar despus de que lea el esquema, pero los dems permanecern abiertos, MySQL no los cerrar hasta que lo necesite. Esto evita una sobrecarga asociada con la apertura y cierre de los archivos si la tabla se usa frecuentemente. Los archivos normalmente no se suelen cerrar hasta que ocurre uno de los siguientes eventos:1. La tabla se ha cerrado de forma explcita mediante FLUSH TABLES. 2. La tabla se ha desechado 3. El servidor est siendo reiniciado 4. El nmero total de tablas abiertas ha alcanzado el valor del parmetro table_cache El ltimo evento es particularmente importante si se tienen muchas tablas que se usan a menudo entre todas las bases de datos. El valor por defecto de table_cache es de 64, as que si se tienen unos cientos de tablas que se usen de forma activa, MySQL va a desperdiciar mucho tiempo y esfuerzo abriendo y cerrando innecesariamente estos archivos.Incrementar el tamao de la cach de tablas ciertamente ayudar en esta situacin, pero se debe tener cuidado de no hacer el valor demasiado grande, ya que todos los sistemas operativos tienen un lmite en el nmero de los archivos abiertos por un mismo proceso. De hecho. Algunos tambin tienen limitado el nmero total de archivos abiertos que puede tener un nico usuario. Si MySQL intenta abrir demasiados archivos, el sistema operativo se negar a permitirlo y MySQL generar un mensaje de error en el archivo de registro de errores. Ante la duda, se tienen que comprobar las limitaciones del sistema operativo.En casos extremos, se puede incrementar el nmero de descriptores de archivos disponibles por medio de las opciones de configuracin del kernel. Los descriptores de archivos abiertos estn reservados por un nico proceso y compartidos por todos sus hilos. Al contrario que muchos de los dems parmetros, la cach de tablas se aplica a todos los tipos de tablas basadas en disco de MySQL.Bfferes de registroSiempre que MySQL ha de escanear una tabla, el hilo que realiza el escaneo reservar un bffer de registro para cada tabla que ha de escanear. Esto sucede tpicamente cuando MySQL decide que es ms eficiente escanear la tabla que usar un ndice para una bsqueda. Tambin ocurre cuando simplemente no hay un ndice que se pueda usar.Al incrementar el valor de record_buffer en el archivo my.cnf, se permite que MySQL lea las tablas en trozos ms grandes. Es probable que esto reduzca el nmero de bsquedas en el disco y haga que el escaneo sea significativamente ms rpido en un servidor muy atareado.Sin embargo, se tiene que ser muy cuidadoso con el bffer de registro si se tienen muchos clientes que realizan bsquedas completas sobre tablas. Debido a que el bffer de registro se reserva por cada hilo, se puede acabar en una situacin donde clientes individuales hagan que se reserven bfferes de registro al mismo tiempo. Si el resto de la memoria est limitada es probable que se empiece a hacer uso de la memoria de intercambio y se ver dramticamente reducido el rendimiento. En la versin 3.23.41 se introdujo un parmetro relacionado denominado record_rnd_buffer.Al igual que record_buffer, se usa para escanear un gran nmero de filas. El record_rnd_buffer se usa para bsquedas que resultan en una ordenacin intermedia del archivo adems de algunas lecturas de registro no secuenciales. Afortunadamente, si no se fija el valor de record_rnd_buffer se establecer por defecto el valor de record_buffer.Bffer de ordenacinTal y como implica su nombre, el bffer de ordenacin se usa para responder a bsquedas que involucren el ordenamiento de los datos -aquellas con una sentencia ORDER BY en ellas. Adems, el bffer de ordenacin se usa para las bsquedas que involucren agrupar datos -aquellas con una sentencia GROUP BY. Al igual que los dems bfferes que se han visto, el bffer de ordenacin es relativamente pequeo por defecto. Al ajustar la entrada de sort_buffer en el archivo my.cnf:set-variable= sort_buffer= 8MPuedes reducir dramticamente la cantidad de tiempo que se usa para ordenar grandes grupos de resultados. El bffer de ordenacin aparece como sort_buffer en la salida de SHOW VARIABLES, por ejemplo:sort_buffer 8388600El mismo tipo de aviso se aplica al bffer de ordenacin que para el bffer de registros. Es un bffer que MySQL reserva frecuentemente y se reserva por hilo. As que, hay que incrementarlo con cuidado en un servidor que ejecute muchas bsquedas concurrentes.Bfferes de registroAntes de discutir cmo medir o juzgar los efectos de cualquier cambio que se realice, se debe considerar brevemente un acercamiento a la afinacin del rendimiento. Hay unas cuantas cosas que se deben tener en mente cuando se empiezan hacer y probar cambios:1. Slo cambiar un parmetro cada vez. Puede que los cambios no resulten siempre en el comportamiento esperado. Si se cambian demasiados parmetros a la vez, se corre el riesgo de asignar un cambio en el comportamiento al parmetro equivocado. 2. No hacer cambios en sistemas en produccin. Si es del todo posible, se debe tener un servidor de pruebas disponible que sea parecido en naturaleza al servidor de bases de datos de produccin. Hacer cambios en la configuracin de MySQL seguramente requerir que se pare y reinicie el servidor, lo que har que los usuarios experimenten interrupciones en el servicio. 3. Usar datos reales. El tipo de datos que se estn usando afecta a cmo responde MySQL a las bsquedas. Idealmente, se debera usar una copia de las bases de datos de produccin. Si no es posible hacer esto; entonces se debera intentar construir un subconjunto representativo de datos. 4. Realizar pruebas realistas. Es fcil asumir que se sabe que pruebas aplicar simplemente porque se sabe cules son las reas problemticas. Sin embargo, algunos cambios de la configuracin aceleran partes lentas de una aplicacin al mismo tiempo que ralentizan cosas que antes eran bastante rpidas. 5. Ser sistemtico y registrar descubrimientos. Es importante que se mantenga la pista de los cambios que se realizan y como afectan al rendimiento. Despus de varias horas (o incluso das) de pruebas, es ms que probable que no se recuerde exactamente qu es lo que se ha cambiado y si los cambios fueron positivos o negativos. Observando los nmeros de rendimiento de la base de datosCon los pocos puntos de partida en mente y un concepto de cmo hacer pruebas, ahora se debe considerar cmo monitorizar el progreso. Afortunadamente, MySQL tiene ms de 50 contadores internos (o variables de estado), que mantienen la pista de cuntas veces ocurren varios tipos de eventos.Dado que el espacio en este artculo sirve para comentar solamente algunas de las variables de estado de MySQL, en el manual de MySQL se describen todas y cada una de ellas en mayor detalle. Para ver estos nmeros, se puede usar la sentencia SHOW STATUS. En este caso se mencionan nicamente las variables relacionadas con el bffer de claves:SHOW STATUS LIKE 'Key%'

Key_read_requests 3844786889key_reads 16525182Key_write_requests 303516563Key_writes 152315649Estas cuatro variables dicen mucho sobre el rendimiento del bffer de claves de MySQL. Cada vez que MySQL sea capaz de leer una clave (o ndice) del bffer de claves (en vez de ir a disco), incrementar automticamente el valor de key_read_requests. Si MySQL ha de leer la clave del disco porque no estaba ya en la cach, incrementar key_reads. La misma lgica se aplica para las escrituras de disco. Sabiendo esto, podemos calcular la eficiencia (o hit rate) para el bffer de claves.Usando una formula Como:100 - ((Key_reads / Key_read_requests) * 100)Podemos obtener un porcentaje que representa cmo a menudo es capaz MySQL de leer las claves directamente de la cach en vez de irse a disco. Cuanto ms cerca est el valor de 100, mucho mejor. Usando los nmeros de arriba, se tiene un hit rate de cerca del 99.57 por ciento. Generalmente, suele ser una buena idea mantener este porcentaje por encima del 90 por ciento. A fin de cuentas, de lo que se trata, es de tener una mejora medible del rendimiento de MySQL.Observando los nmeros de rendimiento del sistemaMonitorear los cambios de rendimiento en MySQL es slo una parte de la labor, tambin es necesario ver qu es lo que est pasando desde el punto de vista del sistema operativo, ya que como cualquier otra aplicacin, est a merced de lo que el sistema operativo quiera permitirle hacer, as que es importante que se mantenga una vista global sobre toda la actividad del sistema operativo.Se debe tener una idea de la actividad actual del sistema y caractersticas del rendimiento de MySQL antes de empezar a hacer pruebas. Sin una base para la comparacin, realmente no se sabr cmo ha cambiado el impacto de MySQL en el sistema. Finalmente, cabe mencionar que nicamente se ha descrito una mnima parte de lo que representa el rendimiento en el lado del servidor para MySQL. El manual de MySQL contiene muchas otras ideas sobre cmo incrementar el rendimiento de MySQL y monitorizar los progresos2. Especfica cules son las diferencias entre un disco preparado y un disco que no sea preparado para instalarlos.La diferencia es de que debe determinarse si la plataforma donde se desea hacer la instalacin esta soportada, aqu debemos notar que no todos los sistemas soportados son igualmente adecuados para ejecutar MySQL. En algunas plataformas el funcionamiento ser mucho ms robusto y eficiente que otras.Debe elegirse la distribucin que se instalara, hay varias versiones de MySQL disponibles y la mayora lo estn en varios formatos de distribucin. Se puede elegir entre distribuciones pre armadas que contienen programas binarios (pre compilado) o bien cdigo fuente. La eleccin siempre se debe considerar a travs del manual de instalacin y debemos verificar que sistema operativo tenemos en nuestro ordenador.Conclusiones:Al estar investigando, hubo un cambio en la visin para poder instalar el sistema gestor de base de datos MySQL, ya que anteriormente no tomaba en consideracin como preparar un disco duro en la instalacin.En cierto momento descargue el Sistema Gestor en Windows XP y no poda instalarlo.ltimamente tengo Windows 8 y al azar lo descargue por de medio de Oracle, pero ahora al documentarme, he tenido una visin ms clara de que tan importante es tomar todas estas consideraciones que se debe tener para trabajar con MySQL.

Manuales.guebs.com/mysql-5.0/installing.html

Instalar MySQL

www.jorgesanchez.net/bd/adb1.pdf

Apndice: Instalacin de MySQL