Oracle compra Sun (y MySQL)

El índice Nasdaq ha temblado, digo se ha tambaleado, hoy más que nunca, y no precisamente por culpa de la crisis. Gracias a un tweet de Kirai, al mediodía me enteraba de la rápida y sigilosa maniobra empresarial consumada con "alevosía y nocturnidad" hoy mismo por el gigante Oracle. En lo que se ha convertido probablemente en la noticia tecnológica del día y del mes, Oracle ha anunciado públicamente (puede que la web esté caída) haber llegado a un acuerdo para la compra de Sun Microsystems por un valor aproximado de 7400 milloncejos de dólares, vamos, calderilla para tipos como yo ;-).

Si bien ya se habían hecho públicos ciertos movimientos y reuniones entre sheriffs de IBM y Sun durante las últimas semanas, este repentino anuncio de adquisición por parte de Oracle creo que ha pillado totalmente desprevenid@ a mucha más gente de la que podíamos llegar a imaginar.

La duda que asola Internet a esta hora reside en las implicaciones que tendrá esta vertiginosa pero inteligente maniobra en dos de los "productos estrella" de Sun, hablo, como no, de Java y de MySQL. Personalmente no espero demasiados cambios ni licencias más restrictivas en la tecnología Java que Sun "liberó" hace algún tiempo, el enfado de la community podría ser de los que hacen época e historia.

Respecto a MySQL, cuya adquisición por parte de Sun anuncié en este blog hace poco más de un año, por el momento todo el mundo dice que MySQL va incluída en el intercambio de cromos. Creo que ésta es sin duda la parte más inteligente de la operación realizada por Oracle, donde se me empiezan a ocurrir múltiples combinaciones y jugadas.

A día de hoy puede que MySQL no sea competencia directa de Oracle, pero doy por descontado que una de las grandes razones para que Oracle haya comprado Sun es precisamente MySQL y su excelente rendimiento y progresión en los últimos años. Si bien todo el mundo está hablando del jugoso pastel llamado "Java" del que Oracle acaba de apoderarse, yo me arriesgo y apuesto por MySQL como principal activo de la compra, tecnología en la que a buen seguro Oracle ha visto cosas que le pueden interesar sobremanera de cara al futuro.

¿Y ahora qué? ¿Tendremos un mix denominado MyOracle o apostarán por Oracle como sistema de base de datos comercial y seguirán ofreciendo MySQL como base de datos opensource? Sun tampoco lo hizo, con lo que no creo que Oracle se atreva ahora a quitar el rasgo opensource que ha caracterizado a MySQL desde sus inicios. Yo desde luego espero seguir viendo por mucho tiempo el adjetivo Community Edition al lado de la marca MySQL. Como siempre, lo veremos, o en su defecto, lo leeremos ;-). Señoras y señores, hagan sus apuestas...

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Error fantasma de MySQL en Windows

Una (durísima) semana entera sin escribir un post..., estoy entrando en una peligrosísima espiral de "estoy tan hasta las trancas de curro que no tengo ni tiempo, ni ganas, ni ideas sobre qué postear" que no mola nada..., por eso, a pesar de ser festivo (¡felicidades a todos los papis!), me pongo ahora mismo a intentar arreglar este pseudo-abandono al que he sometido a mi txoko últimamente. Además, como próximamente comprobaréis, se avecinan tiempos peores para mí y para mi blog, pero bueno, como muchas otras veces, con más o menos posts, sean más cortos o no de tanta calidad, saldremos del paso ;-).

Hoy vuelvo a hablar de una de "mis niñas bonitas", MySQL, quien desde hace tiempo se ha convertido en una de mis bases de datos favoritas, por no decir que es ahora mismo la primera base de datos en la que pienso cuando me mencionan que una aplicación software necesita algún tipo de soporte de almacenamiento. Ya he comentado en alguna ocasión que estoy más que contento con MySQL, pero según te vas adentrando en su mundillo, también te das cuenta que tiene alguna que otra limitación.

De hecho, hoy vamos con un bug en la instalación de MySQL, un error fantasma que me ha ocurrido durante no una, sino dos y hasta tres instalaciones de MySQL 5.1 sobre plataforma Windows. Resulta que últimamente, a pesar de tener varios MySQL 5.0 funcionando como la seda bajo Linux y Windows, ando trasteando con todas y cada una de las nuevas versiones de MySQL que se van liberando, tanto las versiones gratuitas (Community Edition), como las trials de la versión de pago (Enterprise Edition).

El curioso error, de ahí lo de fantasma, ha tenido lugar al instalar las dos últimas versiones gratuitas de MySQL disponibles para Windows, tanto en las versiones MySQL Community Edition 5.1.31, y 5.1.32 como en la versión 5.1.31 de la Enterprise Edition. Si por algo se caracterizan las instalaciones de MySQL para Windows es por la facilidad y rapidez con la que te instalas una base de datos en el típico PC normal y corriente con Windows XP. El error aparece en la parte final del wizard de instalación, cuando el asistente intenta aplicar la configuración de base de datos seleccionada por el usuario:

Al principio pensé que se trataba de un simple error que podía subsanarse yendo para atrás en el wizard y seleccionando alguna otra opción de configuración de MySQL no tan personalizada..., pero qué va, ¡el error seguía apareciendo aún seleccionando la "Default Configuration"! Esto fue hace algún tiempo, y en la primera instalación, pardillo de mí, me di por vencido y tras varias intentonas, hinqué la rodilla, pulsé apesadumbrado el botón "Cancel" y desinstalé MySQL. Eso sí, que conste que lo intenté por todos los medios: borrando a mano los archivos restantes relativos a una instalación previa de MySQL 5.0 en dicha máquina, reiniciando el equipo, volviéndolo a intentar en repetidas ocasiones con diferentes configuraciones de la misma versión, con la Enterprise Edition..., ¡no había manera de arrancar el **** servicio de MySQL, será perro!

Un poco hartito de dicho error, por un tiempo abandoné y olvidé aquella serie de intentonas. Me quedé con la sensación de que podía tener algo que ver que en dicho equipo hubiera existido antes un MySQL 5.0, que aún habiendo sido correctamente desinstalado antes de proceder con la instalación de la 5.1, no sé, quizás hubiera dejado algo de porquería en algún recóndito lugar del equipo..., misterios de la informática.

Sin embargo, esta misma semana he podido retomar el asunto ya que he tenido que correr una serie de tests con la versión 5.1.32 de MySQL Communty Edition, la ultimísima versión gratuita de MySQL a día de hoy. Claro, esta vez, vistos los antecedentes, he realizado la instalación en un PC más pelao que la calva de Mortadelo. ¿Qué tal me ha ido? Pues igual de mal, porque me ha salido el mismo error, con lo que mi mosqueo ha sido de los gordos, y cuando Lonifasiko se mosquea.... ;-). Esta vez, tan pronto como recibo el mismo error, juro en hebreo y corro a mirar los servicios que tiene Windows corriendo en ese instante, cuando para mi sorpresa veo que el servicio de MySQL está corriendo como un jabato. Paro el servicio, vuelvo atrás en el wizard, otra vez para adelante, pero me sigue dando el mismo error. Vuelvo a mirar el estado del dichoso servicio, y el servicio está corriendo más ancho que Pancho, ¡cómo va a crear el servicio de Windows para MySQL si incluso está ya arrancado!

Claro, en la situación en la que te deja el error del wizard, sólo ante el peligro, no te queda otra que cancelar la instalación, bueno, mejor dicho, cancelar el proceso de configuración. Esto último es un detalle muy importante, porque mucha gente, entre ellos yo, pensaba que con esto MySQL no se había terminado de instalar correctamente, por lo que optábamos por desinstalar MySQL desde "Panel de Control" pensando que la instalación se habría quedado "a medias". Pues bien, esto no es así, es más, al llegar a este punto, MySQL está sobradamente instalado, lo que ocurre es que los últimos paquetes de instalación de MySQL para Windows (archivos .msi), por la razón que sea, parece que tienen un pequeño bug y no son capaces de sobreponerse a un intento fallido de creación del servicio de Windows para MySQL. De momento no he reportado el bug, pero lo haré próximamente, aunque sea en los siempre útiles foros de MySQL.

Resumiendo, si al instalar MySQL sobre Windows os encontráis con este error pero veis que el servicio de MySQL está vivito y coleando, don't worry, pulsad "Cancel" con dó cohone y tirad millas, que MySQL ha sido correctamente instalado. Luego, si queréis hacer cambios en la configuración de MySQL, siempre os quedará hacerlos a través de herramientas gráficas como MySQL Administrator o tocando a mano parámetros en el mítico my.ini. ¿Se creían que un errorcillo de ná nos iba a quitar las ganas de utilizar MySQL 5.1? Por favor... ;-).

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Número de columnas máximo en MySQL

¿Se os ha pasado alguna vez por la cabeza poner a prueba el aguante y rendimiento de una base de datos? Sí, ¿verdad? Yo mismo, hace no mucho, estuve "jugando" con MySQL, ejecutando repetidamente desde una aplicación .NET tandas de 100.000 inserts, pruebas en las que el timeout por defecto del conector de base de datos utilizado no hacía más que quejarse ;-).

Si es que no lo puedo negar, ¡me flipa el mundillo de las bases de datos! Me ha gustado desde siempre eso de modelar y relacionar entidades y objetos del mundo real a través de diagramas de E/R. Todavía me acuerdo en la carrera, cuando en los exámenes de la asignatura "Bases de Datos", había que modelar, ¡en un folio en blanco!, el enunciado que se daba por medio de diagramas de E/R..., ¡qué tiempos aquellos!

En fin, es un tema y un currelo estresante, pero sin duda, muy interesante. ¿A quién no le gustaría ser un DBA de una base de datos Oracle? Sí, lo sé, supone gestionar un monstruo de base de datos y comerte miles de marrones..., pero si te gusta el mundillo y eres bueno en ello, los miles de euros que recibirás a final de mes seguro que te hacen olvidar todas las penas ;-). Siempre se ha dicho/oído que los DBAs son los profesionales de la rama de la informática que más ganan...

Sobra decir que no soy DBA (de momento ;-)), por lo que me tengo que contentar con discurrir y poner en práctica de vez en cuando mis ideas maquiavélicas para buscar las cosquillas de las bases de datos, en este caso, una vez más, las cosquillas de MySQL.

¿La idea maligna de hoy? Conocer el número de columnas máximo que puede tener una tabla de MySQL.

Admito que la idea es un tanto extraña y extrema, porque doy por hecho que el 99.9% de la gente que diseña bases de datos no se preocupa de esto en absoluto; es más, much@s seguro que en la vida se habían hecho esta pregunta. Sin embargo, la problemática está ahí, como tod@s sabemos, muchas veces se opta por añadir columnas sin ton ni son a tablas que de por sí tienen un montón de columnas y filas. Por eso, recientemente se me ocurrió investigar si MySQL establecía un límite para el número de columnas por tabla. Gracias a este excelente artículo de la ayuda de MySQL, hoy os confirmo que MySQL sí tiene un limite para el número de columnas por tabla.

Resumiendo y customizando lo allí leído, para empezar, ninguna tabla de MySQL puede tener más de 4096 columnas, siendo esta cifra el tope de los topes. Aún así, hay otros factores que hacen que este número máximo de columnas por tabla disminuya significativamente en MySQL:

• Las tablas tienen un tamaño de fila máximo (row size) de 65.535 bytes, longitud que depende en gran medida del tipo de dato que almacene cada columna. Lógicamente, no ocupa lo mismo un valor de tipo TINYINT (1 byte) que una columna de tipo VARCHAR(255) codificada en UTF-8 (255 x 3 bytes por carácter UTF-8 + 2 bytes para guardar la longitud del valor=767 bytes). Por ejemplo, los campos declarados por defecto a NULL también ocupan bytes extra. Por tanto, si nuestro row size o la suma de bytes que ocupan las columnas de la tabla pasa de 65.535 bytes, ¡sálvese quien pueda!

• El límite del fichero de definición de tabla (fichero .frm) no puede exceder de los 64 KBytes. En este factor influye algo que apriori parece totalmente inofensivo, como es la longitud del nombre de las columnas; si utilizamos columnas con nombres largos (entre otras cosas), el ficherito de marras irá creciendo poco a poco...

• Tipo de storage engine. Cada storage engine de MySQL tiene sus propias restricciones, entre los que destaca, todo sea dicho, para mal, InnoDB, un motor muy utilizado para bases de datos que han de soportar transacciones. InnoDB restringe, de entrada, la cifra máxima de columnas por tabla a 1000, con un row size de 8000 bytes.

¿A que al principio del post el límite sonaba lejos, muy lejos, casi irreal? ¿Y ahora ;-)? Estoy seguro que a más de un@ le han sorprendido las restricciones en el número máximo de columnas por tabla de MySQL, sobre todo las restricciones específicas del motor InnoDB.

Eso sí, a pesar de las restricciones, creo que el número máximo de columnas es suficientemente alto como para no tener problemas. ¿Que por una extraña razón (que no sea un mal diseño) andamos rozando el límite máximo de columnas? No hay muchas opciones que no pasen por un proceso de rediseño y tunning de la correspondiente tabla; a veces un rediseño sirve para darse cuenta de que no se han optimizado los tipos de datos de las columnas, también puede dar lugar a extraer cierta información a otras tablas que luego se relacionarán mediante claves externas, etc. No hay mal que por bien no venga, o aplicado a este área, no hay nada que un buen rediseño de la base datos no solucione ;-).

¿Conoce alguien si otras bases de datos como SQL Server, Oracle o PostgreSQL tienen un límite máximo para el número de columnas de una tabla? ¿Alguna otra restricción curiosa de MySQL con la que os hayáis topado?

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

El timeout del comando sí importa

Hoy retomo un tema relacionado con MySQL que la semana pasada no pude terminar por culpa de un error bastante serio de Google. No voy a hablar directamente de MySQL, pero sí voy a desahogarme con un problemilla (¡qué típico!) que he tenido a la hora de acceder a esta base de datos a través de programación. Sirva como adelanto comentar que este problemilla es extrapolable a todas las bases de datos del mercado; sin embargo, como las pruebas han sido contra MySQL, le daremos el dudoso honor de aparecer en mi post a ella ;-).

El caso es que la semana estuve midiendo tiempos y rendimiento de diferentes sentencias DML lanzadas contra MySQL. Más que nada, me interesaba analizar el comportamiento de los procedimientos almacenados o stored procedures que MySQL soporta a partir de la versión 5.0, frente a las clásicas sentencias en texto plano de select, insert, update y delete. Aunque existen herramientas tipo query analyzer que exprimen todo el jugo a cada consulta y miden tiempos y rendimiento de manera bastante precisa, me apetecía medir tiempos desde el mismísimo campo de batalla, desde la trinchera del programador, a pie de código. Inmejorable ocasión por tanto para probar MySQL Connector/NET 5.2 (última versión de este conector disponible a día de hoy) desde una aplicación de consola dummy programada en C#. Aparte de que quería probar este conector, tiene su lógica hacerlo de esta manera, ya que hoy en día toda aplicación que necesita acceder a base de datos utiliza conectores de diversos tipos dependiendo de la tecnología y lenguaje de programación que se esté utilizando.

Sin más preámbulos ni rollos macabeos, me centraré (por fin) en narrar lo que me pasó durante estas pruebas realizadas contra una base de datos MySQL remota, aunque dentro de las misma red que mi equipo de trabajo. Como siempre, todas estas pruebas y comparaciones suelen empezar suavecito, con sentencias select no demasiado complicadas, 1000 inserciones en una tabla, etc. Hasta aquí todo bien, tiempos parecidos, incluso ligeramente mejores para las queries en texto plano. Palabras mayores, paso a ejecutar un programita que realiza 100000 (cien mil) inserts en texto plano dentro de un bucle for en C#, es decir, ni más ni menos que 100000 llamadas a ExecuteNonQuery(). La ejecución tarda un rato, casi dos minutos, pero va bien, las filas son insertadas como Dios manda (¿Cómo manda Dios?).

Pasamos entonces a ver qué tal funciona lo mismo, pero haciendo una única llamada desde código al método ExecuteNonQuery(). ¿Cómo? Llamando (a gritos) a un stored procedure que realiza las mismas inserciones, aunque en un loop interno definido en el propio procedimiento almacenado, no a nivel de código cliente. ¡Vamos allá!

¡Pues va a ser que ha petado! A ver qué dice el error lanzado por el conector..."Fatal error encountered during command execution". Buff, ¡qué mal rollo Arroyo! Sinceramente, me he quedado igual o peor, no tengo ni idea de qué está pasando, y el error lanzado no es de gran ayuda, como ocurre desgraciadamente muchas veces.

Vuelvo a ejecutar varias veces lo mismo con idéntico resultado, hasta que me apiado y paulatinamente voy bajando el número de inserciones del procedimiento almacenado hasta llegar a un punto en que ¡funciona! ¿Tendrá MySQL un límite de memoria/hilos/procesos en los procedimientos almacenados? No creo..., entonces, ¿será cosa del conector? Mientras me hago esta última pregunta me quedo mirando fijamente la consola, concretamente mi atención se centra en el tiempo cronometrado (por mí) que se muestra tras el error, 30 segundos y pico. ¡Ajá! Ya caigo..., me suena que las sentencias SQL tienen un timeout, es más, me suena que ese timeout suele tener por defecto un valor de 30 segundos. Vamos a tirar de la ayuda, que para algo la suelen realizar...

Efectivamente, confirmado queda que el comando para atacar la base de datos tiene un timeout por defecto de 30 segundos, lo que implica que si el comando no termina, se dispara un error. Claro, ahora todo coincide ya que seguramente la ejecución del stored procedure dura más de 30 segundos, lanzándose la excepción nada aclarativa recibida. ¿Solución? Establecer un valor más alto para dicho timeout. Aunque no se recomienda tocar este parámetro ya que es difícil que la ejecución de una query o stored procedure dure más de 30 segundos (excepto en las monstruosas transacciones y procesos batch que realizan bancos y demás), esta vez vamos a añadir una simple línea de código C# asignando un valor entero muy alto al timeout del command, pa' cubrirnos las espaldas ;-).

Compilamos, y ¡allá vamos de nuevo!

¡Voilá! Como se puede apreciar en la imagen de arriba, las 100000 inserciones se han realizado perfectamente, en un tiempo ligeramente inferior a las 100000 inserciones realizadas "a pelo".

Como adelantaba al principio del post, aunque en este caso particular el ejemplo se ha desarrollado con el conector de .NET para MySQL, esto mismo sirve para otros conectores, tanto a MySQL, como a Oracle, SQL Server, Sybase, o el repositorio de datos que sea. De hecho, si no me equivoco, todos los conectores a base de datos vienen por defecto con un timeout por comando de 30 segundos, tiempo más que suficiente en el 99.99% de los casos, y si no anda Lonifasiko por ahí cerca con ganas de marcheta ;-).

Tened en cuenta por tanto que el timeout en los accessos a base de datos existe, y aunque rara vez se da, hay casos en los que se supera y es necesario reajustar su valor manualmente por código. Soy el primer timeout-breaker, o ¿tiene alguien alguna otra experiencia similar que contar con otro conector hacia MySQL o hacia otra base de datos? Seguro que sí...

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Razones del éxito de MySQL

Apostaría ahora mismo sin titubear a que el 75% de las webs en la onda de las redes sociales y otros servicios online del estilo, llevan MySQL como servidor de base de datos. ¿Por qué se ha convertido MySQL en piedra angular de muchísimos proyectos que tanto éxito están teniendo? Son muchas y variadas las razones, así que antes de aburriros y hacer que os enganchéis a la aleatoriedad de StumbleUpon, os las resumo en este post, como diría el amigo Frank, my way:

• Despacito pero con buena letra. Esta filosofía de trabajo y de publicación de versiones es a mi entender, la que está haciendo que esta base de datos sea hoy por hoy una de las grandes. El equipo de MySQL lleva muchos años trabajando duro en la sombra, sin hacer demasiado ruido, sin prometer cosas que saben no pueden cumplir; han ido poquito a poco pero siempre con paso firme, y es ahora cuando están recogiendo los frutos de todo el trabajo realizado. Sinceramente, creo se lo han ganado.

• Apoyo y respaldo de gran parte de la comunidad opensource. A cambio, dicha comunidad juega un papel determinante en las decisiones que se toman en torno al producto: roadmap, corrección de bugs, adición de nueva funcionalidad, etc. Por si esto fuera poco, a primeros de año Sun Microsystems compraba MySQL, con lo que la inyección de dinero e ideas habrá sido considerable.
  

• Muchísima funcionalidad a coste reducido/cero. Aunque como muchos otros productos opensource, MySQL también tiene una edición de pago denominada MySQL Enterprise, a la mayoría de aplicaciones y webs les sobra con la edición gratuita MySQL Community Server. Es así de simple, si ofreces algo que funciona muy bien, es sencillo de configurar y gestionar, y encima es gratis, te has metido a muchos desarrolladores en el bolsillo, tarea harta difícil con la variedad de productos y plataformas que tenemos hoy en día. Es un modelo de negocio acertado, si alguien necesita soporte o funcionalidad extra, don't worry, ya se informará y pagará la licencia de la edición "pro", licencia por cierto irrisoria si la comparamos con licencias del resto de bases de datos del mercado.

• Multiplataforma. Es una ventaja el que ofrezca versiones tanto para Linux como para Windows, y más, comprobar que en ambos casos el rendimiento es muy bueno. A eso se le llama hacer amigos...
  

Como podéis comprobar, se nota que MySQL no tiene abuela, ya estoy yo, sin estar en nómina de Sun, para alabar todas sus bondades ;-). Simplemente hablo desde la óptica de mi relativamente corta experiencia con MySQL, pero hasta el momento sólo tengo buenas palabras hacia esta base de datos cuya mascota es un simpático delfín llamado Sakila.

Durante esta corta pero intensa convivencia, he tenido el placer de comprobar como MySQL aguanta y gestiona como un campeón (y sin demasiados recursos hardware), bases de datos con tablas pobladas por millones de registros, tablas sometidas a infinitas sentencias insert a lo largo del día, acompañadas de un estrés continuo de sentencias select realizadas sin piedad, alguna. Y ahí sigue, al pie del cañón, con el delfín venga bucear ;-).

Por todas estas razones, no es de extrañar que a fecha de hoy, a la hora de arrancar un nuevo proyecto o desarrollo de aplicación software, MySQL sea una de las candidatas mejor situadas (sino la mejor...) en la cada vez más apretada parrilla de salida del Gran Premio de las Bases de Datos.

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Trasteando con MySQL sobre Windows

MySQL es sin duda la base de datos de moda. Gratuita en su edición "Community Server", es una base de datos muy potente, fiable, escalable y altamente configurable. En todos los sitios en los que he trabajado siempre se atacaban las mismas bases de datos: distintas versiones de SQL Server, Sybase y rara vez, algo de Oracle. Por aquel entonces, MySQL estaba emergiendo, y yo, erróneamente asociaba MySQL única y exclusivamente con Linux. Pues va a ser que no...

A día de hoy puedo decir que MySQL me ha sorprendido gratamente, tanto en entornos Linux (su hábitat natural), como en entornos Windows. Hemos llegado a un punto en el que para cualquier proyecto software que necesite una base de datos (por cierto, conozco muy poco software que no va de la mano de una base de datos), a menos que los requisitos del cliente sean muy específicos o que la aplicación software a desarrollar necesite una base de datos con características muy especiales (Sybase, DB2, etc.), nuestra opción number one para actuar como servidor de base de datos es sin duda MySQL Community Server.

Actualmente tenemos varias instancias instaladas, tanto en Linux como en Windows, y sinceramente estamos metiéndoles una cera impresionante, sobre todo a una instancia de MySQL Community Server que tenemos montada sobre un entorno Windows "normal". Aparte de un susto que tuvimos hace tiempo (al final no era culpa de la base de datos sino del tipo de partición de Windows), la base de datos está aguantando como una jabata.

Como digo, está de moda, y tiene por detrás una comunidad de desarrolladores y usuarios impresionante. Y yo, como ya me considero parte de la comunidad, me he animado a escribir unas pequeñas anotaciones personales que espero os sirvan para conocer algo más sobre el funcionamiento de MySQL Community Server montado en un entorno Windows:

• Estructura interna de directorios. Bajo la carpeta de instalación por defecto (normalmente algo parecido a C:\Archivos de programa\MySQL\MySQL Server 5.0), se encuentra el directorio "data", obviamente el directorio encargado de almacenar los datos.

1. MySQL representa a las bases de datos alojadas en el servidor de base de datos como directorios o carpetas. Y dentro de cada carpeta/base de datos, por cada tabla que creemos tendremos un fichero con el formato nombreTabla.frm.
2. Los datos propiamente dichos, es decir, las filas que pueblan las distintas tablas se guardan en el fichero "ibdata1". A mí también me extrañó, pero MySQL Community Server sobre Windows gestiona todos los datos de las distintas bases de datos del servidor en un único fichero. Un poco peligroso a mi entender...pero sobre todo, diferente a otros servidores, donde cada base de datos tiene su propio fichero independiente (en SQL Server, 1 base de datos - 1 fichero .mdf + 1 fichero .ldf).
3. En una instalación típica, por defecto se generan dos ficheros de log (ib_logfile0 y ib_logfile1).

• Parámetros de configuración: Aunque durante la instalación es posible configurar muchos de los parámetros de forma visual, muchas veces es a posteriori cuando hay que empezar el tunning a base de cambiar valores de parámetros de configuración. El fichero maestro de parámetros de configuración de MySQL se denomina my.ini, situado en la raíz del directorio de instalación del servidor. Como en muchos otros productos, el proceso de configuración de parámetros es el siguiente:

1. Detener el servicio (Panel de Control-->Herramientas administrativas-->Servicios) denominado "MySQL" (si no se ha cambiado el nombre durante la instalación).
2. Editar el fichero my.ini, cambiar los valores requeridos y guardar el fichero.
   
3. Iniciar de nuevo el servicio "MySQL", con lo que se aplicarán los cambios realizados.

Como se puede apreciar en la figura, este fichero almacena parámetros como el número de puerto (port) sobre el que corre MySQL, cual es el directorio de datos por defecto (datadir), el número máximo de conexiones concurrentes que permite (max_connections), y un largo etcétera.

• Herramientas gráficas de MySQL: Se puede atacar la base de datos desde línea de comandos, pero como que no...¿verdad? Para eso están las MySQL GUI Tools, un set de herramientas gráficas para Windows formado por MySQL Query Browser, MySQL Administrator y MySQL Migration Toolkit. Los nombres dejan bastante claro para qué sirve cada una, así que os invito a probarlas. Las herramientas están bien, sobre todo para tareas sencillas, pero he de admitir que todavía tienen mucho margen de mejora. Quizás porque hemos trabajado con versiones beta y hemos tenido algún que otro problemilla...
  

• Conectores: Los hay para todos los gustos ;-). Hemos probado los conectores para Java y .NET y hay que decir que van muy finos. Significar que el conector de Java para MySQL está aguantando "como un león" unas transacciones muy pero que muy potentes.

Ya veis, no son muchas las tips o pautas que os acabo de contar acerca de MySQL corriendo sobre un entorno Windows, pero menos es nada; la idea del post era comentar muy por encima mi corta experiencia con MySQL sobre Windows, y de paso, hacer este pequeño "mini-análisis personalizado" para que a la gente le suenen estas cosillas, por si algún día le toca trabajar contra MySQL.

SaludoX.

SQL Server 2005 Driver for PHP

Pensaba que el matrimonio entre SQL Server y PHP era simplemente imposible, que tenía una incompatibilidad del 101%. Es más, estoy seguro que si preguntas a cualquier desarrollador, te dirá: "¡Ese matrimonio no puede funcionar bien!".

Hombre, si nos atenemos a que casi todos los sitios web que se desarrollan últimamente llevan como bandera el binomio "PHP-MySQL", y que MS no tiene precisamente buena fama en cuanto a interoperabilidad se refiere, está claro que el divorcio está asegurado. Pero bueno, al igual en la vida real, hay matrimonios que se llevan a matar, pero funcionan, ¡y funcionan bien! Sólo por eso, hay que dar un voto de confianza a este recién estrenado matrimonio ;-)

El caso es que el otro día aluciné cuando vi que MS había publicado un driver de acceso a SQL Server desde PHP. Acaba de salir, pero parece que garantiza el acceso desde PHP a SQL Server 2000, SQL Server 2005 y a todas las ediciones Express gratuitas.

Desconozco si algún 'suicida tecnológico' ya ha tenido ocasión de trastear con él. Es más, tengo una enorme curiosidad por ver si alguien utiliza o ha utilizado alguna vez la extravagante combinación "PHP-SQL Server" a la hora de construir una aplicación web. He leído por ahí que existe bastante interés por parte de MS, en permitir el aterrizaje de aplicaciones web creadas con este lenguaje de scripting, en el mundo Windows. Y es que no olvidemos que PHP es sinónimo de servidor web Apache y plataforma Linux.

Hombre, para gente acostumbrada a trabajar contra SQL Server, puede ser una forma más que interesante de hacer algún pinito con PHP.

Se puede encontrar más información en este blog exclusivamente dedicado al driver recién publicado. ¡Que vivan los novios!

SaludoX.

MySQL Error: The table is full

El otro día nuestra aplicación nos sorprendió con un mensaje del driver de MySQL de lo más cachondo: "The table 'tableName' is full" donde 'tableName' es una de las principales tablas de la BD. Hoy digo cachondo; el otro día empecé a sudar como un pollito...

Tenemos un servidor de base de datos MySQL Community Edition 5.0 en la que el volumen de datos empieza a ser importante. Estoy hablando de alguna tabla con 22 millones de filas por ejemplo. Pero bueno, hasta ahora no nos habíamos preocupado porque la BD ocupaba poco más de 4GBytes de espacio en disco, y con los discos de hoy en día, ¡no problem!

Consulto el error al amigo Google, y me cuenta que el tamaño máximo de las tablas de MySQL está únicamente limitado por las restricciones del sistema operativo en cuanto a tamaño máximo de archivo, no por límites internos de la base de datos. La aplicación y el servidor de base de datos residen en la misma máquina, máquina que lleva XP Pro, por lo que, ¡imposible! Según la web de MySQL, ¡el tamaño máximo de fichero para NTFS es de 2TeraBytes! ¡Ni de coña vamos!

Bien, es entonces cuando en medio de más sudores, temblores, suspiros que hacen presagiar lo peor, y comentarios sin sentido, se nos ocurre la brillantes idea, por casualidad, de mirar el sistema de archivos del disco duro: para nuestra sorpresa, ¡nuestro querido XP Pro viene montado sobre FAT32! ¡Bravo! No sé porqué, pero todos dábamos por hecho que XP Pro vendría montado sobre NTFS. ¡Pues no! Venía así, con FAT32, de la tienda del barrio.

En medio de la tensión, la palabra que más alto suena es formatear y reinstalar todo de nuevo. ¡Menudo marrón! Hay comentarios llenos de ánimo como "aunque hagamos backup de la base de datos y luego restore, ya verás, seguro que perdemos datos", etc. Lo típico...

De repente, Google nos da un halo de esperanza: la utilidad convert.
Aparentemente, basta con teclear desde una ventana de comandos "CONVERT C: /fs:ntfs" para que la partición, en el siguiente reinicio, se convierta de FAT32 a NTFS, y lo más importante, ¡sin perder los datos! De perdidos al río, se hace un backup de la BD, se abre una ventana de comandos y se teclea la frase de la muerte. Más sudor, hasta el más ateo rezando a no sabemos quién, y de repente...pulsación nada convincente al "enter". ¡Allá vamos! La utilidad pregunta por la etiqueta de la unidad, la introducimos, y avisa que tiene que desmontar la unidad para proseguir. Tecleamos 's' minúscula confirmando la acción y un nuevo toquecito aún menos convincente al "enter". Hay que salir de la consola, y reiniciar la máquina.

¡No pensaba que un reinicio podía durar tanto! Entonces aparece la típica ventana azul (distinto de pantallazo azul) de comprobación de errores en disco, y en cosa de 15 minutos...voilá! Disco en formato NTFS y los datos a buen recaudo. Arranca la aplicación y hasta hoy felices y contentos sin ver el demoniaco mensaje de "The table 'tableName' is full".

En fin, casualidades del informático: un siniestro error de MySQL me ha permitido descubrir una utilidad milagrosa como Convert. ¡Qué grande!

SaludoX.