La fragmentación tiene lugar sobretodo en tablas donde hay mucho movimiento insert/delete. Este crece mucho cuando el volumen de datos de la tabla es muy variable en el tiempo: por ejemplo en tablas de control de transacciones, de logueos de usuarios, de tablas intermedias, etc. El primer sintoma de fragmentación sería lentitud en las consultas, principalmente perceptible en tablas con muchos registros..
En mysql los triggers que existen son básicos y solo a nivel de tabla. No existe como en SqlServer o Oracle un trigger que permita cazar las conexiones que se abren y obtener cierta información complementaria referente a las sesiones.
Un mal ejemplo. Se puede dar el caso que en un entorno web tengamos un granja de servidores apache y por lo que sea a alguno se le va la olla. Empieza a abrir threads en nuestro mysql de forma masiva (por el motivo que sea) y nos colapsa el servidor porque no tenemos limitidas el número de conexiones simultaneas para ese usuario. ¿Que mal rollo no? Y si encima esto pasa cuando no estamos en la oficina nos podemos encontrar que no podemos saber mucho de lo que ha pasado, por ejemplo vemos el pico en cacti pero no tenemos detalle.
Para tener algo más y poder auditar cuando y quien abre conexiones, haremos lo siguiente:
Creamos schema un schema (o no).
De vez en cuando puede pasar que dos sesiones que se pisen se bloqueen al intentar hacer cambios en los mismos datos (a nivel de registro o a nivel de tabla). En sistemas no concurrentes y/o bien diseñados no tiene por que pasar ya que las aplicaciones suelen estar mínimamente pensadas para evitarlo; o en todo caso en pruebas pre-producción ya se detecta y se corrige. El caso es que incluso aunque se planee evitarlos se pueden producir. En la mayoría de casos se resuelven solitos al acabar de realizar los cambios la sesión bloqueante, incluso ni nos daremos cuenta. En otros casos más infrecuentes se producen bloqueos circulares irresolubles, “deadlocks”, donde se acaba haciendo rollback de una transacción y se genera una entrada en el fichero de alerta:
ORA-00060: Deadlock detected. More info in file /opt/oracle/admin/XXX/udump/XXX_ora_28205.trc
Recientemente he pasado un entorno mysql de la versión 5.0.32 a una más reciente que ya incluye la base de datos information_schema con tablas de metadatos equivalentes a algunos comandos SHOW ya disponibles anteriormente.
"INFORMATION_SCHEMA es la base de datos de información, que almacena información acerca de todas las otras bases de datos que mantiene el servidor MySQL. Dentro del INFORMATION_SCHEMA hay varias tablas de sólo lectura. En realidad son vistas, no tablas, así que no puede ver ningún fichero asociado con ellas. Cada usuario MySQL tiene derecho a acceder a estas tablas, pero sólo a los registros que se corresponden a los objetos a los que tiene permiso de acceso. "..
Con SQL Server podemos caer muy fácilmente en lo que se dice habitualmente sobre los productos Microsoft "Siguiente, siguiente y listo". No vamos a negarlo, Microsoft consigue hacer que gente sin mucha idea salga adelante y es todo un mérito. Pero vayamos al tema. Si se empieza una nueva aplicación y tenemos que crear la estructura de datos, no dejemos solos a los desarroladores y tampoco que usen el MS Management Studio. Normalmente, en lo que a la base de datos se refiere, cuando se crean se tienen en cuenta varias cosas...
A MySql le acompaña mysqlslap (creo que a partir de 5.x), un ejecutable que permite hacer ejecuciones de scripts masivas para simular carga la carga de trabajo en el servidor generada por clientes mysql. Le podemos pasar un script de preparación y un script de consultas DML sobre el que medir tiempos. Con esto lo interesante también es que podemos obtener el tiempo mínimo, máximo y medio con distintas concurrencias.
Podemos empezar con un ejemplo básico con script de creación y de carga...
Esta obra está bajo una licencia de Creative Commons Reconocimiento-CompartirIgual | Servicios Publicidarios | Aviso legal