MIGUEL ANGEL AGUILAR ESTANISLAO

ES1511109383

UNIVERSIDAD ABIERTA Y A DISTANCIA DE MEXICO

DESARROLLO DE SOFTWARE

ADMINISTRACIN DE BASES DE DATOS

5TO SEMESTRE

UNIDAD 1

ACTIVIDAD 3

ANLISIS DE SIMILITUDES Y DIFERENCIAS DE UN DD

PARA INSTALAR MYSQL
 ANLISIS DE SIMILITUDES Y DIFERENCIAS DE UN DD
PARA INSTALAR MYSQL

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:

o 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.

o 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 ptimo para
nuestro sistema o bien incluso modificar el cdigo (que es C y C++).

MEMORIA EN EL DISCO

Del 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 MEMORIA

El 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 402649088

Como 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= 256M

 Si 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 DATOS

Hablando 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 Mis.

Las 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 REGISTRO

Siempre 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 ORDENACIN

Tal 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= 8M

Puedes 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 8388600

El 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 REGISTRO

Antes 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 DATOS

Con 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 3844786889
key_reads 16525182
Key_write_requests 303516563
Key_writes 152315649
 Estas 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 SISTEMA

Monitorear 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 progresos

DIFERENCIAS ENTRE UN DISCO PREPARADO Y UN DISCO QUE NO SEA

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.

FUENTES

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

www.jorgesanchez.net/bd/adb1.pdf. Apndice: Instalacin de MySQL