• Author / Uploaded
• Chri Rivera

Citation preview

UNIVERSIDAD SAN IGNACIO DE LOYOLA

FACULTAD DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS ARQUITECTURA DE DATOS II TRABAJO PARCIAL INTEGRANTES: PROFESOR: VELÁZQUEZ NUÑEZ, ÁNGEL BLOQUE:

2011

Contenido

1. INTRODUCCION..........................................................................................4 2. FUNDAMENTO TEORICO ............................................................................5 2.1 IBM DB2................................................................................................5 2.1.1 Introducción....................................................................................5 2.1.2 Reseña histórica..............................................................................6 2.1.3 Compatibilidad................................................................................7 2.1.4 Escalabilidad...................................................................................7 2.1.5 Integridad........................................................................................9 2.1.6 Seguridad........................................................................................9 2.1.7 Características..............................................................................10 2.2 MySQL.................................................................................................11 2.2.1 Introducción..................................................................................11 2.2.2 Reseña Histórica...........................................................................12 2.2.3 Interioridades y portabilidad ........................................................12 2.2.4 Tipos de columnas .......................................................................13 2.2.5 Sentencias y funciones ................................................................13 2.2.6 Seguridad .....................................................................................14 2.2.7 Escalabilidad y límites .................................................................14 2.2.8 Conectividad ................................................................................14 2.2.9 Localización ..................................................................................14 2.2.10 Clientes y herramientas .............................................................15 3. ARQUITECTURA........................................................................................15 3.1 Arquitectura general...........................................................................15 3.2 Arquitectura DB2................................................................................19 3.2.1 Funcionamiento............................................................................21 Client Programs................................................................................22 . Listener..........................................................................................22 Agents..............................................................................................22

db2fmp.............................................................................................23 Threads y Procesos..........................................................................23 Hilos y procesos del servidor de la base de datos............................24 3.2.2 Instancia.......................................................................................24 Almacenamiento Físico..........................................................................27 Almacenamiento Logico.........................................................................28 3.2 Arquitectura MySQL............................................................................30 FUNCIONAMIENTO DEL SERVIDOR MySQL..............................................30 Arquitectura lógica de MySQL................................................................31 Motores de almacenamiento..................................................................34 ¿Cómo seleccionar el motor de almacenamiento?.................................36 La capa de aplicación MySQL.................................................................37 La capa lógica MySQL............................................................................38 Administración de transacciones......................................................38 Los conectores.......................................................................................40 El gestor de conexiones.........................................................................40 El procesamiento y optimización de consultas.......................................41 La caché de consultas............................................................................41 El Control de Concurrencia.....................................................................42 La gestión de transacciones y recuperación..........................................42 3.3 Sentencias..........................................................................................42 4. COMPARACIONES.....................................................................................44 IBM DB2....................................................................................................44 MySQL.......................................................................................................45 Comandos Principales...............................................................................46 MY SQL MINIMUN REQUIREMENTS.............................................................48 DB2 WINDOWS..........................................................................................49 DB2 EXPRESS C VS MYSQL COMMUNITY...................................................54 Encriptación de red nativa...........................................................55 Protección de fuerza bruta...........................................................55 Compatible con el directorio empresarial.....................................55 Reglas de complejidad de contraseñas........................................55 Acceso a parches ........................................................................55

Usable sin privilegios ...................................................................55 Auditoria.......................................................................................55 Recursos limitables......................................................................55 Separación de trabajos ...............................................................55 Certificación de seguridad............................................................55 CONCLUSIONES............................................................................................57 6. BIBLIOGRAFIA...........................................................................................58

1. INTRODUCCION

El presente proyecto de investigación se desarrolla con la finalidad de promover el estudio comparativo entre los productos de Oracle y de IBM para base de datos (DBMS). Los productos a desarrollar son MySQL Community Server Edition y DB2-C Express Edition. El primero de ellos es una versión de descarga gratuita de la base de datos mundial de código abierto más popular, este es compatible

con una comunidad activa de desarrolladores de código abierto. El segundo producto es un software que ofrece la base de datos y las herramientas más avanzadas para ayudar a las diversas compañías del mercado a gestionar su información. El objetivo principal de este proyecto es ofrecer información adecuada y ordenada para que esta pueda ser accesible al usuario, ayudando la misma a incrementar el conocimiento con facilidad. Asimismo, se busca afianzar los conocimientos adquiridos en el curso acerca de estas herramientas; lo cual se hará a través de la investigación sobre las características, ventajas y desventajas de dichos productos. A partir de la investigación realizada se ha desarrollado un caso básico, el cual nos ayudara a establecer un estudio comparativo entre la base de datos MYSQL y DB2. Gracias a los resultados de dicha investigación, los estudiantes involucrados hemos logrado incrementar, complementar y profundizar los temas que hemos ido desarrollando a lo largo del período de estudios y a su vez, hemos incrementado los conocimientos adquiridos.

2. FUNDAMENTO TEORICO

2.1 IBM DB2 2.1.1 Introducción DB2 es una marca comercial, propiedad de IBM, bajo la cual se comercializa el sistema de gestión de base de datos relacional de dicha compañía, así como otras herramientas relacionadas encuadradas en la misma línea de producto. DB2 es el sistema de gerencia de base de datos que entrega una plataforma flexible y rentable de la base de datos a la estructura robusta en usos de

negocio de la demanda. Fomenta sus recursos con la amplia ayuda para los estándares abiertos y las plataformas populares del desarrollo como J2EE y Microsoft .NET e incluye las soluciones adaptadas para necesidades específicas como inteligencia de negocio y útiles avanzados. El producto incluye todo lo necesario para implementar una solución de replicación de datos en cualquier tipo de ambiente distribuido o heterogéneo, pues permite enviar los datos a cualquier sitio para cubrir todos los requerimientos de una empresa, desde oficinas centrales a sucursales, usuarios móviles, proveedores, clientes y socios de negocios. Si tu negocio es grande o pequeño, DB2 tiene una solución construida y tasada para resolver tus necesidades únicas. DB2 Express-C es la versión gratuita para la comunidad de DB2 que permite desarrollar, implementar y distribuir aplicaciones que no usen las características avanzadas de las versiones comerciales de DB2. Esta versión del producto puede ser concebida como el núcleo de DB2. Las diferentes ediciones incluyen las características de Express-C más funcionalidades específicas. En la actualidad la última versión de RDBMS DB2 es la versión Express-C 9.7. Esta funciona correctamente sobre las plataformas Linux y Windows, pero el motor de la base de datos no utiliza más de 2 procesadores de núcleo y 2 GB de memoria RAM. Asimismo, actualmente IBM está ofreciendo en forma de prueba la versión 9.7.2 del Express – C en su página web.

2.1.2 Reseña histórica •

1970: Se da el origen del producto DB2, perteneciente a la firma IBM.

•

1983: Se empieza a vender el producto DB2 con la versión 2.0.

•

1994: DB2 UDB (DB2 Universal Database) fue construido en base a dos productos incluidos en el DB2 de AIX, DB2 Common Server, que para propósitos generales incluía funciones avanzadas para el mercado de servidores de bases de datos, con soporte de hardware SMP y OLTP; y el DB2 Parallel Edition, que fue desarrollado para soportar aplicaciones de gran escala, como Data Warehousing y Data Mining.

En la actualidad la tecnología de gestión de datos de IBM es utilizada por más de 40 millones de usuarios de 300.000 empresas en todo el mundo. Mientras que la evolución del DB2, Universal Data Base dispone de más de 6 millones de usuarios y 1.300.000 licencias instaladas.

2.1.3 Compatibilidad Se podría decir que este producto de cierta manera pretende ser el servidor de bases de datos genérico para Windows; no tanto porque la causa de desarrollo sea la misma, ni siquiera porque el SQL Server, a diferencia de otros servidores, solo trabaja bajo Windows; sino porque Microsoft promete integración con todos los productos suyos (por ejemplo MsOffice 2000, ya que Access 2000 traerá consigo un nuevo MSDE−DATA−Engine, como alternativa al existente y compatible con SQL Server). También será posible llamar a SQL Server desde MS-Access. DB2 es el sistema relacional de IBM y es una de las bases de datos relaciónales más antiguas en el mercado. Se usa principalmente en sistemas de computadoras mainframe como AS/400 y RS/6000. Esta base de datos proporciona características avanzadas y se usa principalmente para soluciones de base de datos a gran escala. Se dice también ser la base de datos más utilizada en el mundo, más que Oracle y que Microsoft SQL, ya que es la que mejor responde a las exigencias del e−business de hoy; y sabemos que detrás de cada e−business está siempre una base de datos.

2.1.4 Escalabilidad DB2 Universal Database de IBM es el primer y único servidor de bases de datos del mundo cuya escalabilidad va desde un computador de bolsillo a una laptop, de un servidor de rango mediano a clusters ,de servidores para servidores empresariales masivamente paralelos a través de 23 plataformas en 14 lenguajes con una sólida confiabilidad.

Incluye todo lo necesario para implementar una solución de replicación de datos de cualquier tipo, ambiente distribuido o heterogéneo, pues permite enviar los datos a cualquier sitio para cubrir los requerimientos de una empresa, desde oficinas centrales a sucursales, usuarios móviles, proveedores, clientes y socios de negocios. Después de que un backup en línea está completo, DB2 obligará a cerrar el log actualmente activo y como resultado se archivará fuera de él. Esto asegura que su disco auxiliar en línea tenga un juego completo de logs archivados y disponibles para la recuperación. Usted puede obligar el log actualmente activo al cierre y puede forzar que el log sea archivado.

DB2 está disponible para múltiples sistemas de operaciones, incluyendo UNIX, Microsoft Windows, OS/2, AS/400, y OS/390. Este producto le permite distribuir y acceder a los datos por una red de sistemas. Los usuarios pueden preguntar, agregar, anular, y poner al día los datos en las bases de datos locales y remotos. Pueden dividirse las bases de datos de DB2 por computadoras independientes múltiples conectadas por un LAN o por secciones. También significa que los funcionamientos pueden correr en paralelo en las particiones de la base de datos individuales, reduciendo el tiempo de ejecución. DB2 proporciona un juego de datos de acceso de las interfaces para los diferentes tipos de usuarios y aplicaciones. Se puede realizar la administración de la DB2 desde cualquier puesto de trabajo. No importa si la base de datos es local o remota. Se puede administrar la BD incluso desde un navegador (Web Browser). DB2 incluye herramientas gráficas que le permiten poner a punto la actualización, acceso a los servidores de DB2 remotos, manejar todos los servidores de un solo sitio, desarrollar las aplicaciones, y proceso de pregunta SQL. Este producto guarda sus datos contra la pérdida, acceso desautorizado, o entradas inválidas proporcionando los backups o logs periódicos para restaurar una base de datos al mismo estado que tenía antes del fallo. Una estrategia de recuperación de base de datos debe asegurar que todas las informaciones estén disponibles cuando son requeridos para la recuperación de base de datos. Debe incluir un horario de respaldo y, en el caso de sistemas de base de datos distribuidos, incluye las copias de base de datos cuando los servidores o nodos están agregados o eliminados. La estrategia global debe incluir los procedimientos para los scripts de comando de recuperación, aplicaciones, funciones definidas por usuario, código de procedimiento almacenado en biblioteca de sistema de operación. DB2 tiene tres tipos de recuperación: •

Version recovery, que es la restauración de la base de datos a la versión anterior con una imagen de la base de datos que fue creado durante la operación de respaldo.

•

Rollforward recovery, que es la reaplicación de transacciones registradas en los archivos de log después que una base de datos o una tabla esta restaurada.

•

Crash recovery, que es la recuperación automática de la base de datos si una falla ocurre antes de que todas las transacciones se encuentren completas.

Todas las bases de datos tienen los archivos de log asociados. Los logs registran cambios de base de datos. Si una base de datos necesita ser recuperada a un punto después del último respaldo, los logs son requeridos para realizar la recuperación. Estos tienen dos tipos de comportamiento en DB2: Circular logging, es el comportamiento default cuando se crea una nueva base de datos. Archived logs, son logs cerrados y guardados, y son usados específicamente para rollforward recovery.

2.1.5 Integridad Las restricciones son reglas que el administrador de la base de datos establece. Existen tres tipos de restricciones: Restricción Única: Es una regla que prohíbe que haya valores duplicados en una o en más columnas en una tabla. Restricción Referencial: Es una regla lógica sobre valores en una o en más columnas, en una o más tablas. Tabla de Control de Restricciones: Es un grupo de restricciones que se agregan a los datos de una tabla específica.

2.1.6 Seguridad DB2 utiliza una combinación de seguridad externa y control interno de acceso a protección de datos. Para poder acceder a un servidor de base de datos, es necesario pasar por unas revisiones de seguridad. El primer paso de seguridad se llama Autentificación, donde el usuario prueba que es quien dice. El segundo paso de seguridad se llama Autorización, donde SGBD decide si el usuario auténtico es permitido a realizar acción solicitada o acceder a los datos solicitados.

2.1.7 Características •

Manejo de objetos grandes (hasta 2 GB).

•

La definición de datos y funciones por parte del usuario.

•

Verificación de integridad referencial.

•

SQL recursivo. Soporta SQL y XQuery

•

Soporte multimedia: texto, imágenes, video, audio; queries paralelos, commit de dos fases, backup/recuperación on−line y offline.

•

Cuenta con un monitor gráfico de rendimiento, el cual permite observar el tiempo de ejecución de una sentencia SQL y corregir detalles para aumentar el rendimiento.

•

Con DB2 es posible acceder a los datos usando JDBC, Java y SQL (tanto el SQL estático, como complementa el SQL dinámico), mediante Internet.

•

Tiene implementación nativa de almacenamiento de datos XML.

•

Tiene aplicaciones para .NET, CLI, JAVA, PHYTON, PHP, C++, entre otros lenguajes de programación. También soporta integración en los ambientes de desarrollo integrado de Eclipse y Visual Studio .NET.

2.2 MySQL 2.2.1 Introducción

MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario con más de seis millones de instalaciones. MySQL AB —desde enero de 2008 una subsidiaria de Sun Microsystems y ésta a su vez de Oracle Corporation desde abril de 2009— desarrolla MySQL como software libre en un esquema de licenciamiento dual. Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta licencia, pero para aquellas empresas que quieran incorporarlo en productos privativos deben comprar a la empresa una licencia específica que les permita este uso. Está desarrollado en su mayor parte en ANSI C. Al contrario de proyectos como Apache, donde el software es desarrollado por una comunidad pública y el copyright del código está en poder del autor individual, MySQL es patrocinado por una empresa privada, que posee el copyright de la mayor parte del código. Esto es lo que posibilita el esquema de licenciamiento anteriormente mencionado. Además de la venta de licencias privativas, la compañía ofrece soporte y servicios. Para sus operaciones contratan trabajadores alrededor del mundo que colaboran vía Internet. MySQL AB fue fundado por David Axmark, Allan Larsson y Michael Widenius. La versión gratuita de MySQL es MySQL Community Server es la herramienta perfecta para la creación de bases de datos a través de lenguaje SQL. MySQL Server es un servidor que les servirá tanto a usuarios que desean iniciarse en el mundo de la programación SQL como a aquellos empresarios que desean tener todos sus datos almacenados y seguros en una base de datos. MySQL Community Server además es una aplicación de código abierto. Esto significa que aquella gente que posea los conocimientos necesarios podrá modificar y mejorar el código para conseguir un mejor rendimiento de sus bases de datos. MySQL Community Server permite almacenar una gran cantidad de datos pudiendo utilizar varias bases de datos diferentes para diferenciar diferentes trabajos que estemos ejerciendo. Todos nuestros datos serán dirigidos mediante consultas SQL que podrán realizarse desde cualquier lenguaje de programación (PHP, C++, Java, Python, Perl, etc.). Mediante este tipo de consultas conseguiremos dar a nuestros programas funciones dinámicas como por ejemplo sistemas de identificación, registros, etc. Además MySQL Community Server apuesta por la seguridad, ya que nos permite establecer una contraseña diferente para cada una de las bases de

datos que contenga. Así podrán acceder a ellas únicamente personas con autorización para ello.

2.2.2 Reseña Histórica MySQL surgió alrededor de la década del 90, Michael Windenis comenzó a usar mSQL para conectar tablas usando sus propias rutinas de bajo nivel (ISAM). Tras unas primeras pruebas, llegó a la conclusión de que mSQL no era lo bastante flexible ni rápido para lo que necesitaba, por lo que tuvo que desarrollar nuevas funciones. Esto resulto en una interfaz SQL a su base de datos, totalmente compatible a mSQL. El origen del nombre MySQL no se sabe con certeza de donde proviene, por una lado se dice que en sus librerías han llevado el prefijo “my” durante los diez últimos años, por otra parte, la hija de uno de los desarrolladores se llama My. Así que no está claramente definido cual de estas dos causas han dado lugar al nombre de este conocido gestor de bases de datos.

2.2.3 Interioridades y portabilidad • • • • • • •

• • • • • •

Escrito en C y en C++ Probado con un amplio rango de compiladores diferentes Funciona en diferentes plataformas. Usa GNU Automake, Autoconf, y Libtool para portabilidad. APIs disponibles para C, C++, Eiffel, Java, Perl, PHP, Python, Ruby, y Tcl. Uso completo de multi-threaded mediante threads del kernel. Pueden usarse fácilmente multiple CPUs si están disponibles. Proporciona sistemas de almacenamiento transaccionales y no transaccionales. Usa tablas en disco B-tree (MyISAM) muy rápidas con compresión de índice. Relativamente sencillo de añadir otro sistema de almacenamiento. Esto es útil si desea añadir una interfaz SQL para una base de datos propia. Un sistema de reserva de memoria muy rápido basado en threads. Joins muy rápidos usando un multi-join de un paso optimizado. Tablas hash en memoria, que son usadas como tablas temporales. Las funciones SQL están implementadas usando una librería altamente optimizada y deben ser tan rápidas como sea posible. Normalmente no hay reserva de memoria tras toda la inicialización para consultas.

• •

El código MySQL se prueba con Purify (un detector de memoria perdida comercial) así como con Valgrind, una herramienta GPL El servidor está disponible como un programa separado para usar en un entorno de red cliente/servidor. También está disponible como biblioteca y puede ser incrustado (linkado) en aplicaciones autónomas. Dichas aplicaciones pueden usarse por sí mismas o en entornos donde no hay red disponible..

2.2.4 Tipos de columnas •

Diversos tipos de columnas: enteros con/sin signo de 1, 2, 3, 4, y 8 bytes de longitud, FLOAT, DOUBLE, CHAR, VARCHAR, TEXT, BLOB, DATE, TIME, DATETIME, TIMESTAMP, YEAR, SET, ENUM, y tipos espaciales OpenGIS. Registros de longitud fija y longitud variable.

2.2.5 Sentencias y funciones •

Soporte completo para operadores y funciones en las cláusulas de consultas SELECT y WHERE. Por ejemplo: mysql> SELECT CONCAT(first_name, ' ', last_name) -> FROM citizen -> WHERE income/dependents > 10000 AND age > 30;

Soporte completo para las cláusulas SQL GROUP BY y ORDER BY. Soporte de funciones de agrupación (COUNT(), COUNT(DISTINCT ...), AVG(), STD(), SUM(), MAX(), MIN(), y GROUP_CONCAT()). Soporte para LEFT OUTER JOIN y RIGHT estándares de sintaxis SQL y ODBC.

OUTER

JOIN cumpliendo

Soporte para alias en tablas y columnas como lo requiere el estándar SQL. DELETE, INSERT, REPLACE, y UPDATE devuelven el número de filas que han cambiado (han sido afectadas). Es posible devolver el número de filas que serían afectadas usando un flag al conectar con el servidor. El comando específico de MySQL SHOW puede usarse para obtener información acerca de la base de datos, el motor de base de datos, tablas e índices. El comando EXPLAIN puede usarse para determinar cómo el optimizador resuelve una consulta. Los nombres de funciones no colisionan con los nombres de tabla o columna. Por ejemplo, ABS es un nombre válido de columna. La única restricción es que para una llamada a una función, no se permiten espacios entre el nombre de función y el '(' a continuación. Puede mezclar tablas de distintas bases de datos en la misma consulta (como en MySQL 3.22).

2.2.6 Seguridad

•

Un sistema de privilegios y contraseñas que es muy flexible y seguro, y que permite verficación basada en el host. Las contraseñas son seguras porque todo el tráfico de contraseñas está encriptado cuando se conecta con un servidor.

2.2.7 Escalabilidad y límites Soporte a grandes bases de datos. Usamos MySQL Server con bases de datos que contienen 50 millones de registros. También conocemos a usuarios que usan MySQL Server con 60.000 tablas y cerca de 5.000.000.000.000 de registros. Se permiten hasta 64 índices por tabla (32 antes de MySQL 4.1.2). Cada índice puede consistir desde 1 hasta 16 columnas o partes de columnas. El máximo ancho de límite son 1000 bytes (500 antes de MySQL 4.1.2).Un índice puede usar prefijos de una columna para los tipos de columna CHAR, VARCHAR, BLOB, o TEXT. 2.2.8 Conectividad Los clientes pueden conectar con el servidor MySQL usando sockets TCP/IP en cualquier plataforma. En sistemas Windows de la familia NT (NT,2000,XP, o 2003), los clientes pueden usar named pipes para la conexión. En sistemas Unix, los clientes pueden conectar usando ficheros socket Unix. En MySQL 5.0, los servidores Windows soportan conexiones con memoria compartida si se inicializan con la opción --shared-memory. Los clientes pueden conectar a través de memoria compartida usando la opción --protocol=memory. La interfaz para el conector ODBC (MyODBC) proporciona a MySQL soporte para programas clientes que usen conexiones ODBC (Open Database Connectivity). Por ejemplo, puede usar MS Access para conectar al servidor MySQL. Los clientes pueden ejecutarse en Windows o Unix. El código fuente de MyODBC está disponible. Todas las funciones para ODBC 2.5 están soportadas, así como muchas otras. La interfaz para el conector J MySQL proporciona soporte para clientes Java que usen conexiones JDBC. Estos clientes pueden ejecutarse en Windows o Unix. El código fuente para el conector J está disponible.

2.2.9 Localización El servidor puede proporcionar mensajes de error a los clientes en muchos idomas. Soporte completo para distintos conjuntos de caracteres, incluyendo latin1 (ISO-8859-1), german, big5, ujis, y más. Por ejemplo, los caracteres

escandinavos 'â', 'ä' y 'ö' están permitidos en nombres de tablas y columnas. El soporte para Unicode está disponible Todos los datos se guardan en el conjunto de caracteres elegido. Todas las comparaciones para columnas normales de cadenas de caracteres son caseinsensitive. La ordenación se realiza acorde al conjunto de caracteres elegido (usando colación Sueca por defecto). Es posible cambiarla cuando arranca el servidor MySQL. Para ver un ejemplo de ordenación muy avanzada, consulte el código Checo de ordenación. MySQL Server soporta diferentes conjuntos de caracteres que deben ser especificados en tiempo de compilación y de ejecución. 2.2.10 Clientes y herramientas MySQL server tiene soporte para comandos SQL para chequear, optimizar, y reparar tablas. Estos comandos están disponibles a través de la línea de comandos y el cliente mysqlcheck. MySQL también incluye myisamchk, una utilidad de línea de comandos muy rápida para efectuar estas operaciones en tablas MyISAM. Todos los programas MySQL pueden invocarse con las opciones --help o -? para obtener asistencia en línea.

3. ARQUITECTURA

3.1 Arquitectura general

3.1.1 Capa de Aplicación

La capa de aplicación representa la interfaz para todos los usuarios del sistema, sino que básicamente proporciona los medios por el cual el mundo exterior puede interactuar con el servidor de base de datos. En general, se ha encontrado que los usuarios puedan se clasifican en cuatro grupos principales: 1. Usuarios sofisticados interactúan con el sistema sin necesidad de utilizar ningún tipo de aplicación, sino que forma sus solicitudes directamente con el uso de un lenguaje de consulta de bases de datos. 2. Usuarios especializados son los programadores de aplicaciones que escriben aplicaciones de bases de datos especializadas que no encajan en el marco tradicional de procesamiento de datos. 3. Usuarios ingenuos son usuarios sofisticados, que interactúan con el sistema mediante la invocación de una de los programas permanentes de aplicación que han sido previamente

escrito. 4. Los administradores de base de datos tiene el control total sobre el

sistema de base de datos. Ellos tienen una amplia variedad de responsabilidades, incluyendo la definición del esquema, la concesión de acceso autorización, así como la especificación de restricciones de integridad. Todos los sistemas de bases de datos proporcionan amplios servicios para cada uno de estos grupos, sino que se deja a la capa de lógica de adecuadamente el proceso de peticiones diversas. 3.1.2 Capa lógica

La funcionalidad básica del RDBMS está representado en la capa de lógica de la arquitectura, es en esta parte del el sistema que hay una gran variedad de implementaciones de proveedores específicos (ver Figura 2). Sin embargo, al la lectura de una serie de textos generales de gestión de bases de datos, se encontró que en general la funcionalidad de núcleo lógico de hecho se puede abstraer. El siguiente diagrama es una abstracción de alto nivel de los módulos se encuentra en cualquier sólido RDBMS.

Se puede observar que hay cuatro módulos principales presentes en el RDBMS, y sus implementaciones y interacciones se resumen basado en la documentación general de una variedad de fuentes. Es interesante tener en cuenta que desde el flujo de control importante es, en efecto a la baja, la capa de lógica en sí mismo puede ser considerado como un Garlan y Shaw capas de la arquitectura. Cabe señalar que las implementaciones

específicas y las interacciones entre los subsistemas varían mucho de un proveedor a otro, en la siguiente sección, los subsistemas de MySQL estos elementos serán analizados en detalle.

3.1.3 Capa Física El RDBMS se encarga de la conservación de una variedad de información, que se mantiene en el almacenamiento secundario y acceder a través del gestor de almacenamiento. Los principales tipos de datos almacenados en el sistema son: 1. Los archivos de datos, que almacenan los datos del usuario en la base de datos 2. Diccionario de datos, que almacena metadatos acerca de la estructura de la base de datos 3. Índices, que proporcionan un acceso rápido a los elementos de datos que contienen valores particulares 4. Datos estadísticos, que almacenan la información estadística sobre los datos en la base de datos que es utilizado por el procesador de consultas para seleccionar formas eficientes para ejecutar una consulta. 5. La información del registro, que sirve para hacer un seguimiento de las consultas ejecutadas de manera que el gestor de recuperación puede utilizar la información para recuperar con éxito la base de datos en el caso de un fallo del sistema. Ver diccionario detallado

3.2 Arquitectura DB2

 Instance shared memory: Este se refiere al administrador global de

memoria compartida de la base de datos, el cual es asignado cuando la instancia es iniciada mediante el comando DB2START (para DB2) y permanece asignado así hasta que el comando DB2STOP (para DB2) es ejecutado para detener la instancia.

 Database shared memory: Este se refiere a la memoria global de la base de datos, el cual es asignado cuando la base de datos es activada o conectada por primera vez. La memoria asignada incluye buffer pools, locklist, database heap, utility heap, package cache y catalog cache.

 Application shared memory: Esta se refiere a la memoria asignada cuando una aplicación se conecta a la base de datos y es usada por agentes que pueden hacer el trabajo solicitado por los clientes conectados. Cada aplicación conectada a la base de datos tiene memoria asignada a sí misma; así es que la configuración precisa de los parámetros que afectan a la aplicación de la memoria compartida se vuelve crucial.

 Nivel de Instancia: Estos son los procesos que se inicializan al momento de comenzar la instancia:

1. DB2 Daemon Spawner (db2gds): Procesador daemon global iniciado por cada instancia (solo en UNIX).

2. DB2 System Controller (db2sysc): Procesador principal del DB2.

3. DB2 Watchdog (db2wdog): Proceso padre para todos los procesos.

4. DB2 Format Log (db2fmtlg): Proceso que pre-asigna los log files en el log path

 Nivel de Base de Datos: Estos son los procesos que se inicializan al momento de crear una conexión con una base de datos.

1. DB2 Log Reader (db2loggr): Similar al proceso PMON de Oracle . Este proceso lee los log files durante el rollback, restart recovery y el roll forward.

1. DB2 Log Writer (db2logw): Equivalente al proceso LogWriter de Oracle.

1. DB2 Page Cleaner (db2pclnr): Equivalente al proceso DBWR de Oracle.

2. DB2 Prefetcher (db2pfchr): Recupera las páginas del disco y los coloca al buffer pool justo antes de ser necesitada.

3. DB2 Deadlock Detector (db2dlock): Proceso que detecta los Deadlock.

3.2.1 Funcionamiento

Client Programs Este programa funciona remotamente, así como también en la misma máquina que el servidor de la base de datos. Su primer contacto es con la base de datos a través de un listener. Un agente del coordinador (db2agent) entonces se asigna a ellos. . Listener El Client Program hace contacto inicial con communication listerner., la cual se inicializa a la vez que con el DB2. Existe un listener para cada protocolo de comunicación configurado, y un listener para las comunicaciones entre procesos (IPC) (db2ipccm) para los local Client Program. Los listener incluyen:

•

db2ipccm, para las conexiones locales del cliente

•

db2tcpcm, para las conexiones del TCP/IP

•

db2snacm, para las conexiones de APPC

•

db2tcpdm, para peticiones de la herramienta TCP/IP

Agents Todas las peticiones de conexión de la aplicación

del cliente, ya sean

locales o remotas, son asignados a un agente correspondiente del coordinador (db2agent). Cuando se crea el agente del coordinador, realiza todas las peticiones de la base de datos a favor de la aplicación. En algunos ambientes, en los cuales se permite el parámetro de la configuración del encargado de base de datos del intra_parallel, el agente del coordinador distribuye las peticiones de la base de datos a los subagentes

(db2agntp).

Estos

agentes

realizan

los

pedidos

de

la

aplicación. Una vez que se crea el agente del coordinador, maneja todas las peticiones de la base de datos a favor de la aplicación mediante la coordinación de subagentes (db2agntp) que realizan peticiones en la base de datos. Un agente del coordinador puede ser:

•

Conectado con la base de datos con alias. Por ejemplo,

“db2agent (DATA1)” está conectado con la base de datos alias “DATA1”. •

Adjuntado a una instancia. Por ejemplo, “db2agent

(user1)” se adjunta a la instancia del “user1”. Un tipo adicional del agente, db2agnsc es creado por DB2 para realizar ciertas operaciones en paralelo. Particularmente, se utilizan en acciones de la recuperación de base de datos. Los Idle agents residen en el agent pool. Estos agentes están disponibles para las peticiones de los agentes del coordinador que funcionan a favor de programas del cliente, o de los subagentes que funcionan a favor de agentes existentes del coordinador. El número de agentes disponibles es dependiente en los maxagents y los num_poolagents de los parámetros de la configuración del encargado de base de datos. db2fmp El proceso modo fenced. Es responsable de ejecutar procedimientos almacenados cercados y funciones definidas por el usuario fuera del firewall. db2fmp es siempre un proceso separado pero puede hacer un multithread dependiendo de los tipos de rutinas que se ejecuta. Threads y Procesos La siguiente lista incluye algunos de los threads y procesos más importantes de la base de datos



db2pfchr, para los buffer pool prefetchers.



db2pclnr, para los buffer pool page cleaners



db2loggr, para manipulación de log files manejar

procesos de transacciones y procesos de recuperación



db2loggw, para escribir los log records en los log files.



db2logts, para recoger información histórica sobre los

logs que se activan cuando un tablespace es modificado. Esta información se registra en última instancia en DB2TSCHG.HIS file

en el directorio de base de datos. Se usa para acelerar la recuperación del TableSpace Rollforward.

Hilos y procesos del servidor de la base de datos El regulador del sistema (db2sysc) debe existir para que el servidor de la base de datos a funcionar. También, los hilos de rosca y los procesos siguientes se pueden comenzar para realizar varias tareas:

•

db2resyn, el agente de la RESYNC que explora la lista

global de la RESYNC

•

db2gds, el spawner global del demonio en sistemas

basados en UNIX que comienza nuevos procesos

•

db2wdog, el perro guardián en sistemas basados

en

UNIX que maneja terminaciones anormales

•

db2fcmdm, el demonio rápido del encargado de las

comunicaciones para manejar la comunicación de la inter-partición (usada solamente en bases de datos multi-repartidas)

•

db2pdbc, el regulador paralelo del sistema, que maneja

peticiones paralelas de los nodos alejados (usados solamente en un ambiente de base de datos repartido).

•

db2cart, para archivar ficheros de diario cuando tener

acceso a una base de datos configurada con USEREXIT permitió

•

db2fmtlg, para los ficheros de diario del formato, al

tener acceso a una base de datos configurada con LOGRETAIN permitido, pero con USEREXIT inhabilitados

•

db2panic, el agente del pánico, que maneja peticiones

urgentes después de que los límites del agente se hayan alcanzado en un nodo particular (usado solamente en un ambiente de base de datos repartido)

3.2.2 Instancia

Una instancia en DB2 tiene sus propias bases de datos (las cuales no pueden ser utilizadas por otras instancias), y todas sus particiones de bases de datos comparten los mismos directorios del sistema. En DB2, después de instalar el producto en una plataforma de Windows, la instancia "DB2" es creada por defecto. En Linux y UNIX, la instancia por defecto es llamada "db2inst1". Para crear otra instancia en la misma máquina, se ejecuta el comando db2icrt . Para referenciar una instancia DB2 dada desde una interfaz de línea de comandos, se usa la variable de ambiente DB2INSTANCE. Esta variable permite que especifiques a la instancia actual, a la que todos los comandos se aplicaran. Por ejemplo, si el DB2INSTANCE fue asignado a “prod”, y después ejecutas el comando CREATE DATABASE “mydb1”, se creará una base de datos asociada a la instancia “prod”. Si hubieses querido que se creara la base de datos en la instancia “db2”, entonces se debe cambiar el valor de la variable DB2INSTANCE a “db2”. Esto es similar al ORACLE_SID (System Identifier) el cual también es usado cuando los usuarios quieren cambiar entre instancias. Para eliminar una instancia en DB2, se ejecuta el comando db2idrop . Para una instancia en DB2 existen los comandos CREATE, MODIFY, START, STOP y DELETE. Una instancia puede contener varias bases de datos. Cada base de datos es una unidad independiente y cerrada a las otras. Cada base de datos tiene su propio espacio de tabla de catálogos, espacio de tablas temporales, y espacio de tablas de usuario los cuales son creados por defecto al momento de crear la base de datos. DB2 contiene un archivo binario conocido como el directorio system database que contiene entradas de todas las bases de datos de las que puedes conectar desde una maquina de DB2. Este directorio es contenido al nivel de la instancia. Cuando una instancia es creada, no se crea ninguna base de datos por defecto. Uno tiene que explícitamente crear una base de

datos usando el comando CREATE DATABASE. Para eliminar una base de datos, se utiliza el comando DROP DATABASE. Las bases de datos de una instancia no interactúan normalmente entre ellas. Sin embargo, si una aplicación necesita interactuar con más de una base de datos, este requerimiento puede ser obtenido por medio de la habilitación de un soporte federal.

Almacenamiento Físico Contenedores: •

Asignación de almacenamiento físico tal como un archivo o un dispositivo, cada uno de ellos puede ser administrado por el sistema operativo o por el mismo DB2

•

Un container es asignado a un tablespace

•

Un solo tablespace puede expandirse a muchos containers, pero cada container puede pertenecer solo a un table space

Directorio: Agrupación de archivos de datos, atendiendo a su contenido, propósito o a cualquier criterio que decida el usuario. Almacena información acerca de los archivos que contiene: como los atributos de los archivos o dónde se encuentran físicamente en el dispositivo de almacenamiento. Dispositivos: Lugar donde se puede almacenar la información como discos duros, memorias, etc.

Ficheros : Son los archivos de datos donde se almacenarán la información.

Almacenamiento Logico

Instancia: Conjunto de estructuras de memoria y procesos que administra datos y los recursos del sistema asignados a ella. Base de datos: Conjunto de datos almacenados sistemáticamente para su posterior uso, en diferentes tipos de archivos. Tablespace: Espacio Lógico utilizado para almacenar objetos de la base de datos administrados por el DBMS. Soporta dos tipos: En DB2, un tablespace es un objeto lógico usado como una capa entre las tablas lógicas y los containers físicos. Cuando creas un tablespace, puedes asociarlo a un buffer pool (database cache) especifico así como a un container especifico. Esto te da la flexibilidad del manejo de ejecución. Por ejemplo, si tienes a una tabla llamada "hot", puedes definirla a su propio tablespace asociado a su propio buffer pool. Esto ayuda a asegurar que la data para esta tabla es continua en el caché de la memoria.

En DB2, tres tablespaces son creadas automáticamente por defecto al momento de crear una base de datos cuando se utilizan las opciones de valor por defecto para el comando CREATE DATABASE. Estas son:



SYSCATSPACE: Es el tablespace de catalogo, contiene la metadata.

 TEMPSPACE1: Es el tablespace del sistema temporal usado para realizar operaciones tales como JOIN y SORT. El nombre de esta tabla puede ser cambiada.

 USERSPACE1: Este tablespace es opcional y puede ser usada para guardar las tablas de los usuarios cuando un tablespace no es indicado explícitamente al momento de la creación de la tabla. Debido a que las bases de datos en DB2 son unidades independientes, los tablespaces no son compartidos entre ellos. Considerando de que son conocidos dentro de solo una base de datos, dos bases de datos diferentes pueden tener tablespaces del mismo nombre. Los tablespaces en DB2 pueden ser clasificados como SMS (system-managed spaces) o DMS (database-managed spaces). Los SMS tablespaces son manejados por el sistema operativo y solo pueden ser directorios. Pueden crecer automáticamente cuando es necesario, lo que indica que los SMS dan un buen funcionamiento con una administración mínima. Los DMS tablespaces son manejados por el DB2, y pueden ser archivos o dispositivos brutos. Este tipo de tablespace permite el mejor funcionamiento, pero requiere de cierta administración. Por ejemplo, se necesita especificar antes ded tiempo la cantidad de espacio que se desea asignar al tablespace, porque su crecimiento no es automático.

SMS (System Managed Space): •

El SO controla el espacio

•

Un objeto no puede estar en dos tablespaces distintos.

•

El número de contenedores es determinado al crear el tablespace y no

puede ser aumentado a después.

DMS (Database Managed Space: • El gestor de base de datos controla el espacio • El Tablespace por defecto para el usuario se llama USERPACE1. • Los objetos pueden expandirse en varios tablespaces. • El tamaño de un DMS tablespace puede ser incrementado añadiendo containers

después de ser creados.

• Ideal para grandes bases de datos y con alto nivel de rendimiento.

El concepto de data buffer del Oracle es el equivalente al bufferpool del DB2. Sin embargo, el DB2 permite que existan mas de un bufferpool. No hay un numero predefinido de bufferpools que se puedan crear y pueden tener cualquier nombre. El concepto de un Oracle block es muy similar al page del DB2. Un page de DB2 puede tener un tamaño de 4k, 8k, 16k o 32k. Un registro de tabla (fila) debe caber en un solo page; no se puede expandir a otros pages como lo hace en Oracle.

3.2 Arquitectura MySQL La arquitectura de MySQL tiene como característica más notable el separar el motor de almacenamiento (que se encarga de los detalles de entradasalida y representación de la información en memoria secundaria) del resto de los componentes de la arquitectura. Es decir, el diseño del gestor está preparado para que se pueda cambiar el gestor de almacenamiento. Esto permite incluso crear nuevos motores de almacenamiento especializados para ciertas tareas o tipos de aplicaciones. FUNCIONAMIENTO DEL SERVIDOR MySQL Funcionamiento: 1. Los clientes se conectan a servidor.

2. Los clientes inician autentificación, codifican y envían peticiones, comprimen y cifran peticiones, cachean los resultados del servidor 3. El servidor procesa las peticiones y devuelve las respuestas. 4. Las peticiones son procesadas primero por la capa de manipulación, que las desencripta, valida su sintaxis, las busca en la caché, y las envía al correspondiente motor de almacenamiento. 5. Los motores de almacenamiento (MyISAM, InnoDB, Memory, ...) manejan la representación en memoria y disco de bases de datos, tablas e índices, así como generación de estadísticas y algunos logs. 6. La capa de manejo escribe logs a disco, guarda y lee caches en memoria, lee logs binarios de la red, Los motores de almacenamiento guardan datos (tablas, logs,...) en disco y en memoria, envía datos a otros servidores remotos.

Arquitectura lógica de MySQL La siguiente figura es una visión abstracta de la arquitectura lógica de MySQL. La figura hace una división entre los componentes que conforman el servidor, las aplicaciones cliente que lo utilizan y las partes del sistema operativo en las que se basa el almacenamiento físico.

Figura 1

* El -

servidor MySQL utiliza espacio en disco para almacenar lo siguiente: Los programas cliente y servidor, y sus librerías. Los ficheros de registro ("logs") y de estado. Las bases de datos. Los ficheros de formato de tablas ('*.frm') para todos los motores de almacenamiento, y los ficheros de datos y ficheros de índices para algunos motores de almacenamiento. Los ficheros de "tablespaces" de InnoDB, si el motor de almacenamiento InnoDB está activado. Tablas temporales internas que han sobrepasado el límite de tamaño en memoria y deben ser convertidas a tablas en disco.

* El servidor MySQL utiliza espacio en memoria para almacenar lo siguiente: - Gestores de conexión (cada conexión consume memoria). - Buffers que guardan tablas temporales internas que no han sobrepasado el límite de tamaño en memoria. - Cachés: caché de hosts, la caché de tablas, la caché de consultas, ... - Una copia de la tabla de permisos. - El contenido de las tablas HEAP (motor de almacenamiento en memoria). Su fichero de formato ('*.frm') se continua guardando en disco. * El servidor MySQL utiliza los siguientes buffers por cada cliente: - Buffers de registros para las búsquedas secuenciales en tablas

-

('read_buffer_size') y para leer las líneas después de una ordenación ('read_rnd_buffer_size') normalmente conseguida mediante la cláusula ORDER. Buffer de join para las uniones de tablas. Buffer de ordenación para las operaciones de ordenación. Buffer de comunicaciones para intercambiar información con el cliente. Comienza con un tamaño de 'net_buffer_length', pero si es necesario el Servidor aumenta su tamaño al señalado por 'max_allowed_packet'.

* Los límites que el sistema operativo puede imponer al servidor MySQL son: - El máximo número de ficheros abiertos por proceso limita el tamaño máximo de la caché de tablas, que guarda los descriptores de ficheros para los ficheros de tablas. - El máximo número de hilos de ejecución por proceso limita el número de clientes que se pueden conectar simultáneamente al servidor MySQL. - El 'backlog' permitido por el sistema limita el número de conexiones de red en cola debido a clientes que esperan a conectarse. - El sistema de ficheros donde se guardan los datos limita el tamaño máximo del fichero, pero este límite puede esquivarse repartiendo los datos en varios ficheros. -

Para registrar los errores podemos iniciar el servidor mediante 'mysqld_safe'. Para ver los errores debemos buscar un fichero en el directorio de datos con el nombre de la máquina y con el sufijo '.err'. Para registrar las modificaciones de datos de las tablas podemos iniciar el servidor con la opción "--log-bin". Para ver dicho registro se utiliza la herramienta 'mysqlbinlog'.

* Ver la actividad del servidor: mysql> SHOW STATUS; shell> mysqladmin extended-status * Ver la configuración del servidor: mysql> SHOW VARIABLES; shell> mysqladmin variables

Las utilidades y herramientas de MySQL son los programas y aplicaciones que se incluyen con la distribución del gestor, o que pueden instalarse como aplicaciones adicionales. Estas incluyen las herramientas de backup, el navegador de consultas (QueryBrowser), las aplicaciones administrativas de interfaz gráfico y la herramienta de diseño MySQL Workbench, entre otras.

Motores de almacenamiento El elemento más notable de la arquitectura de MySQL es la denominada arquitectura de motores de almacenamiento reemplazables (pluggable storage engine architecture). La idea de esa arquitectura es hacer una interfaz abstracta con funciones comunes de gestión de datos en el nivel físico. De ese modo, el gestor de almacenamiento puede intercambiarse, e incluso un mismo servidor MySQL puede utilizar diferentes motores de almacenamiento para diferentes bases de datos o para diferentes tablas en la misma base de datos. Esto permite utilizar el motor de almacenamiento más adecuado para cada necesidad concreta. También permite que terceros puedan implementar motores de almacenamiento nuevos para necesidades específicas, o adaptar el código de los existentes a ciertos requisitos de almacenamiento. Así, las interfaces definidas por MySQL aíslan el resto de los componentes de la arquitectura de las complejidades de la gestión física de datos, facilitando el mantenimiento de los motores de almacenamiento. También esto permite que ciertos motores de almacenamiento no implementen parte de los servicios, lo cual les hace inapropiados para algunas aplicaciones pero más eficientes para otros. Por ejemplo, un motor de almacenamiento que no implementa bloqueos en la base de datos no debe utilizarse en aplicaciones multi-usuario, pero la ausencia de sobrecarga de procesamiento en la gestión de los bloqueos para el acceso concurrente lo hará mucho más eficiente para una aplicación monousuario. •

•

•

•

•

•

MyISAM, el motor por defecto, permite lo típico, pero no permite transacciones, todas las consultas se realizan con autocommit. Por lo demás no hay mucho que comentar, como curiosidad decir que los BLOB o TEXT pueden ser indices, e incluso un campo que sea indice puede tomar valor NULL. Usa Arboles B internamete para los indices (separado de los datos) y tiene herramientas para chequeo y reparación de tablas. BLACKHOLE: El sorprendente uso de este motor es no almacenar los datos sino crear un log con la consulta SQL utilizada. Como no almacena ningún dato lógicamente no soporta índices, ni transacciones. Su principal utilidad es mantener un servidor esclavo que mantenga un log del sistema principal. CSV, motor completamente trivial, que guarda cada tabla en un fichero y cada fila de datos es una línea con los datos separados por comas. ARCHIVE, el motor almacén, solo soporta INSERT's y SELECT's. Además, siempre que escribes datos se comprimen (con zlib), así que es el motor típico para una base de datos histórica o cuando vamos a tener una cantidad realmente enorme de datos EXAMPLE, es un motor de almacenamiento "tonto" que no hace nada. Puede crear tablas con este motor, pero no puede almacenar datos ni recuperarlos. El objetivo es que sirva como ejemplo en el código MySQL para ilustrar cómo escribir un motor de almacenamiento. Como tal, su interés primario es para desarrolladores. FEDERATED, motor nuevo que se incorporó en la versión 5 de MySQL, para poder crear bases de datos federadas, esto significa que estaremos consultando a una bases de datos remota, es decir en nuestro servidor creamos la tabla pero le decimos, oye que esta tabla esta en otro lado, si eso, le preguntas, que fijo que te responde. Este

•

•

•

•

modelo tiene ciertas limitaciones, no permite ALTER's ni transacciones. MERGE, este es facil, si tienes dos tablas con motor MyISAM y con la misma estructura, al crear una tabla MERGE, juntarás los datos de ambas tablas. Un caso para el cual puede ser útil este motor, podría ser, por ejemplo, diferentes tablas de log en diferentes servidores y te creas en uno de ellos tablas FEDERATED de esas tablas (que serán MyISAM) y entonces creas una tabla de "log_principal" (usando MERGE) que tendrá el log de todos los servidores. arrr marinero. MEMORY, tablas que se guardan en memoria, es decir, cuando reinicies MySQL, adios datos. No le encuentro ninguna utilidad la verdad, si quieres un almacenamiento temporal, que sentido tiene entonces usar un SGBD? Pues ninguno!. Berkeley DB, una de las bases de datos openSource más famosa y utilizada. El motor es independiente de MySQL, con las ventajas e inconvenientes que esto pueda acarrear. Permite transacciones (COMMIT & ROLLBACK) y solo puede ejecutarse en sistemas operativos soportados (Linux x86 y Windows, si; Mac OS X feo y Linux AMD64/Alpha, no). Como curiosidad decir que su organización de ficheros se basa en solo dos, puesto que utiliza árboles B donde, en cada nodo, están tanto los datos como el índice primario (lo cual implica que será algo más lento a la hora de recorrerlo secuencialmente) InnoDB, es el motor más avanzado (junto con BDB) en cuanto a opciones y funcionalidad. Permite transacciones seguras (COMMIT y tal) y está orientado a manejar grandes cantidad de datos. Realiza el bloqueo usando como gradualidad la fila (BDB lo hace a nivel de página, es decir mayor salvo casos raros de filas enormes) e incluso soporta lecturas consistentes tanto bloqueantes como no bloqueantes.

En consecuencia, una primera tarea de diseño físico en MySQL es la de decidir el motor de almacenamiento más apropiado. Los elementos que puede implementar un motor de almacenamiento son los siguientes: •

• • • •

•

Concurrencia. Es responsabilidad del motor implementar una política de bloqueos (o no implementar ninguna). Una estrategia de bloqueos por fila permite una mayor concurrencia, pero también consume más tiempo de procesamiento en aplicaciones en las que la concurrencia no es realmente grande. Soporte de transacciones. No todas las aplicaciones necesitan soporte de transacciones. Comprobación de la integridad referencial, declarada como restricciones en el DDL de SQL. Almacenamiento físico, incluyendo todos los detalles de la representación en disco de la información. Soporte de índices. Dado que la forma y tipo de los índices depende mucho de los detalles del almacenamiento físico, cada motor de almacenamiento proporciona sus propios métodos de indexación (aunque algunos como los árboles B casi siempre se utilizan). Cachés de memoria. La eficiencia de los cachés de datos en memoria depende mucho de cómo procesan los datos las aplicaciones. MySQL

•

implementa cachés comunes en el gestor de conexiones y la caché de consultas, pero algunos motores de almacenamiento pueden implementar cachés adicionales. Otros elementos para ayudar al rendimiento, como puede ser el uso de múltiples hilos para operaciones paralelas o mejoras de rendimiento para la inserción masiva.

Además de lo anterior, los motores de almacenamiento pueden implementar características no comunes, como la gestión de tipos de datos geoespaciales, o cualquier función adicional específica de cierto tipo de aplicaciones. La implementación de un gestor de almacenamiento implica escribir un software con una interfaz en lenguaje C, que implemente una biblioteca de funciones (storage engine API) que es la que el servidor MySQL invoca para pedir los servicios al gestor. Por ejemplo, si estamos implementando un gestor de almacenamiento, una de las funciones es la que crea una nueva tabla, que tiene la siguiente signatura. int ha_tina::create(const char *name, TABLE *table_arg, HA_CREATE_INFO *create_info) { ... } El parámetro name es, como cabe esperar, el nombre de la nueva tabla, y TABLE es una estructura que representa el esquema de la tabla. Las opciones de creación están en create_info, que incluye, por ejemplo, la asociación con índices, restricciones en el tamaño de la tabla, etc. MySQL crea una representación del esquema de las tablas independiente del motor de almacenamiento, en ficheros denominados nombretabla.frm, uno por cada tabla del esquema. TABLE es una referencia a esa representación. ¿Cómo seleccionar el motor de almacenamiento?

No hay una receta única que permita definir el motor de almacenamiento. La selección debe hacerse una vez tenemos el modelo lógico de la base de datos y conocemos los requisitos de rendimiento y no funcionales de la aplicación o aplicaciones que vamos a construir. La sentencia SHOW ENGINES nos muestra la lista de motores en MySQL, incluyendo el motor por defecto y los que no están disponibles con la configuración actual. El resultado para MySQL 5.1. es el siguiente:

Suppor Comment t Default engine as of MySQL 3.23 with great MyISAM YES performance Hash based, stored in memory, useful for MEMORY YES temporary tables DEFAU Supports transactions, row-level locking, and InnoDB LT foreign keys BerkeleyDB NO Supports transactions and page-level locking /dev/null storage engine (anything you write to it BLACKHOLEYES disappears) EXAMPLE NO Example storage engine ARCHIVE YES Archive storage engine CSV NO CSV storage engine ndbcluster NO Clustered, fault-tolerant, memory-based tables FEDERATEDYES Federated MySQL storage engine MRG_MYISA YES Collection of identical MyISAM tables M ISAM NO Obsolete storage engine Tabla 1 Engine

De la tabla anterior solo podemos tener nociones iniciales del tipo de gestor, y dirigirnos a alguno de ellos para casos concretos, por ejemplo, ndbcluster tiene características únicas si necesitamos soporte para alta disponibilidad. No obstante, hace falta conocer más en profundidad las características de cada uno para tomar decisiones, y en ocasiones es necesario hacer pruebas de rendimiento con varios de ellos para compararlos y seleccionar el que mejor se ajusta a nuestras necesidades. La capa de aplicación MySQL La capa de aplicación MySQL es donde los clientes y los usuarios interactúan con el RDBMS de MySQL. Hay tres componentes en esta capa. Estos componentes se ilustran los diferentes tipos de usuarios que pueden interactuar con el RDBMS de MySQL, que son los administradores, clientes y usuarios de la consulta. Los administradores utilizan la interfaz de administración y servicios públicos. En MySQL, algunas de estas utilidades son mysqladmin que realiza tareas como apagar el servidor y crear o borrar bases de datos, isamchk y myisamchk que ayudan a realizar el análisis de mesa y optimización, así como recuperación de fallos si las tablas se dañan, y mysqldump para hacer copias de seguridad las bases de datos de base de datos o la copia a otro servidor. Los clientes se comunican con el RDBMS de MySQL a través de la interfaz o los servicios públicos. La interfaz de cliente utiliza las API de MySQL para varios lenguajes de programación diferentes, tales como la API de C, API DBI para Perl, PHP API, API de Java, la API de Python, MySQL API C + + y Tcl. usuarios de consulta interactuar con el RDBMS de MySQL a través de una interfaz de consulta que es mysql. MySQL es un monitor (programa interactivo) que permite a los usuarios de consulta para emitir sentencias SQL al servidor y ver los resultados.

La capa lógica MySQL Se encontró que MySQL tiene de hecho una arquitectura lógica que es prácticamente DentiCal. La documentación de MySQL dio una indicación de la manera exacta de estos módulos puede subdividirse en subsistemas organizados en una jerarquía de capas que corresponden a la arquitectura en capas en Garlan y Shaw. Ver diccionario detallado Procesador de consultas La gran mayoría de las interacciones en el sistema se producen cuando un usuario desea ver o manipular los datos subyacentes de almacenamiento. Estas consultas, que se especifican en un lenguaje de manipulación de datos (es decir, SQL), se analizan y optimizado por un procesador de consultas. Este procesador, se puede representar como la tubería y la arquitectura de filtro en el sentido de Garlan y Shaw, donde el resultado de la componente anterior se convierte en un requisito de entrada o al siguiente componente. El Ure arquitecto componente del procesador de consultas es conformado por: • • • • • • • •

Precompliador LMD Incorporado Compilador DDL Analizador de consultas Preprocesador de Consultas Seguridad / Integration Manager Optimizador de consultas Motor de ejecución Escalabilidad / evolucionabilidad

Administración de transacciones Administrador de transacciones A partir de la versión de MySQL 4.0.x, se ha añadido soporte para las transacciones en MySQL. Una transacción es una sola unidad de trabajo que tiene uno o más comandos de MySQL en la misma. El administrador de transacciones es responsable de asegurarse de que la transacción se registra y se ejecuta de forma atómica. Lo hace a través de la ayuda del administrador de registro y el administrador de control de concurrencia. Por otra parte, el administrador de transacciones también se encarga de resolver las situaciones de estancamiento que se producen. Esta situación puede ocurrir cuando dos transacciones no puede continuar porque cada uno tiene algunos datos que el otro necesita para continuar. Por otra parte, el administrador de transacciones es responsable de la expedición del COMMIT y ROLLBACK los comandos SQL. El comando COMMIT se compromete a realizar una transacción. Por lo tanto,

una transacción es incompleto hasta que se ha comprometido a. El comando ROLLBACK se utiliza cuando se produce un bloqueo durante la ejecución de una transacción. Si una transacción se quedaron incompletos, el comando ROLLBACK que deshacer todos los cambios realizados por esa transacción. El resultado de ejecutar este comando es la restauración de la base de datos a su estado estable anterior. Administrador de control de concurrencia El gerente de control de concurrencia es responsable de asegurarse de que las transacciones se realizan por separado y de forma independiente. Lo hace mediante la adquisición de bloqueos, de la tabla de bloqueo que se almacena en la memoria, en las piezas adecuada de los datos en la base de datos del administrador de recursos. Una vez que el bloqueo se adquiere, sólo las operaciones en una transacción pueden manipular los datos. Si otra transacción trata de manipular los mismos datos bloqueados, el administrador de la concurrencia de control rechaza la solicitud hasta que la transacción se completa la primera. Administración de la Recuperación Log Manager El administrador de registro se encarga de registrar e muy operación ejecutada en la base de datos. Lo hace mediante el almacenamiento en el registro en el disco a través del administrador de búfer. Las operaciones en el registro se almacenan como comandos de MySQL. Así, en el caso de un fallo del sistema, ejecutar cualquier comando en el registro traerá de vuelta la base de datos a su estado estable anterior. Recovery Manager El gestor de recuperación es el responsable de la restauración de la base de datos a su estado estable anterior. Lo hace mediante el registro de la base de datos, que se adquiere desde el administrador de búfer y la ejecución de cada operación en el registro. Desde el gestor de registro de los registros de todas las operaciones realizadas sobre la base de datos (desde el inicio de la vida de la base de datos), la ejecución de cada comando en el archivo de registro se recuperaría la base de datos a su estado estable anterior. Administración de almacenamiento El almacenamiento se realiza físicamente en algún tipo de almacenamiento secundario, sin embargo el acceso dinámico de este medio no es práctico. Por lo tanto, todo el trabajo se realiza a través de un número de búferes. Los tampones residen en la memoria principal y virtual y son administrados por un administrador de búfer. Este gerente trabaja en conjunto con dos entidades relacionadas con gestor de almacenamiento: el Administrador de recursos y el Administrador de almacenamiento.

Administrador de Almacenamiento En el nivel inferior existe el Administrador de almacenamiento. El papel del Administrador de almacenamiento es la de mediar entre las peticiones administrador de búfer y almacenamiento secundario. El Administrador de almacenamiento hace solicitudes a través del controlador de disco subyacente (ya veces el sistema operativo) para recuperar datos del disco físico y informes de vuelta al administrador de búfer. Buffer Manager El papel del administrador de búfer es asignar los recursos de memoria para el uso de la visualización y manipulación de datos. El administrador de búfer toma de las solicitudes con formato y decide la cantidad de memoria para asignar al búfer y cuántos búferes de asignar por solicitud. Todas las solicitudes se realizan desde el Administrador de recursos. Administrador de recursos El propósito del Administrador de recursos es aceptar las peticiones del motor de ejecución, los puso en las solicitudes de mesa, y solicitar las tablas desde el Administrador de búfer. El Administrador de recursos recibe referencias a los datos dentro de la memoria desde el Administrador de búfer y devuelve estos datos a las capas superiores. Ver diccionario detallado

Los conectores Los conectores son bibliotecas en diferentes lenguajes de programación que permiten la conexión (remota o local) con servidores MySQL y la ejecución de consultas. Por ejemplo, el conector Connector/J permite conectarse a MySQL desde cualquier aplicación programada en lenguaje Java, y utilizando el Java Database Connectivity (JDBC) API. El gestor de conexiones La gestión de conexiones es responsable de mantener las múltiples conexiones de los clientes. Un gestor de conexiones inexistente o laxo simplemente crearía una conexión por cada cliente conectado. No obstante, las conexiones consumen recursos de máquina, y crearlas y destruirlas son también procesos costosos. Por eso, el gestor de conexiones de MySQL puede configurarse para limitar el número de conexiones concurrentes, y también implementa un pool de conexiones. La idea es que muchas aplicaciones abren una conexión y la mantienen abierta y ociosa durante mucho tiempo (por ejemplo, durante toda la sesión de un usuario, que de vez en cuando se levanta para diferentes tareas mundanas como tomar café), y solo “de vez en cuando” se utiliza un hilo de ejecución para ejecutar una consulta, que además, típicamente tarda como

mucho unos milisegundos. No tiene sentido mantener una conexión ociosa para cada usuario. De aquí proviene la idea de los pools de conexiones: hay un número de conexiones disponibles, y cada vez que una aplicación hace una solicitud, se le asigna una conexión del pool que no esté ocupada. Lógicamente, la aplicación cliente no es consciente de este mecanismo. En términos por ejemplo, de las interfaces JDBC, esto quiere decir que cada vez que enviamos una sentencia con llamadas como Statement.executeQuery() realmente puede que se cree una nueva colección, o quizá se tome una del pool. Es decir, las llamadas a Driver.getConnection() y a Connection.close() no siempre determinan el tiempo de vida de una conexión real en MySQL. Además de la reducción en el tiempo de establecimiento de conexión (si se reusa una conexión ya creada del pool), la técnica permite limitar el número de conexiones simultáneas. Dado que las conexiones consumen recursos, es mejor limitar este número que llevar a una carga excesiva en el servidor, que podría acabar en una caída del sistema o un comportamiento impredecible. Nótese que gracias a los pools de conexiones, puede darse servicio a muchas conexiones concurrentes con un número limitado de conexiones que se reutilizan. El gestor de conexiones también se ocupa de la autentificación de los usuarios. La autentificación por defecto se basa en el nombre de usuario, la máquina desde la que se conecta y la password. El servidor puede también configurarse para soportar certificados X.509. El procesamiento y optimización de consultas Cada vez que una consulta llega al gestor de MySQL, se analiza sintácticamente y se produce una representación intermedia de la misma. A partir de esa representación, MySQL toma una serie de decisiones, que pueden incluir el determinar el orden de lectura de las tablas, el uso de ciertos índices, o la re-escritura de la consulta en una forma más eficiente. Existe la posibilidad de utilizar ciertas cláusulas en las consultas para ayudar al optimizador en su tarea, o bien podemos pedirle al servidor ciertas “explicaciones” sobre cómo ha planificado nuestras consultas, para entender mejor su funcionamiento. Dado que la optimización de las consultas depende de las capacidades del gestor de almacenamiento que se esté utilizando, el optimizador “pregunta” al gestor si soporta ciertas características, y de este modo, puede decidir el tipo de optimización más adecuado. La caché de consultas MySQL implementa un caché de consultas, donde guarda consultas y sus resultados enteros. De este modo, el procesador de consultas, antes ni siquiera de plantear la optimización, busca la consulta en la caché, para evitarse realizar el trabajo en el caso de que tenga suerte y encuentre la consulta en la caché.

El Control de Concurrencia El control de concurrencia en un gestor de bases de datos es simplemente el mecanismo que se utiliza para evitar que lecturas o escrituras simultáneas a la misma porción de datos terminen en inconsistencias o efectos no deseados. El mecanismo que se utiliza para controlar este acceso es el de los bloqueos (locks). La idea es muy simple, cada vez que una aplicación quiere acceder a una porción de los datos, se le proporciona un bloqueo sobre los mismos. Lógicamente, varias aplicaciones que quieran leer simultáneamente no tienen ningún problema en hacerlo, de modo que para la lectura se proporcionan bloqueos compartidos (shared locks). Sin embargo, varios escritores o un escritor simultáneo con lectores puede producir problemas. Por eso, para la escritura se proporcionan bloqueos exclusivos (exclusive locks). Aunque la idea parece simple, hay que tener en cuenta que la obtención y liberación de los bloqueos se realiza continuamente, y esto produce una sobrecarga en el procesamiento dentro del servidor. Además, hay diferentes políticas de bloqueo, por ejemplo, ¿es mejor bloquear cada tabla completa afectada o solo las filas de la tabla a las que quiere acceder una consulta?. Dada la existencia de diferentes técnicas, el control de concurrencia en MySQL se divide entre el servidor y cada gestor de almacenamiento. La gestión de transacciones y recuperación

La gestión de transacciones permite dotar de semántica “todo o nada” a una consulta o a un conjunto de consultas que se declaran como una sola transacción. Es decir, si hay algún problema y parte de la consulta o algunas de las consultas no consiguen llevarse a cabo, el servidor anulará el efecto parcial de la parte que ya haya sido ejecutada. La recuperación permite “volver hacia atrás” (rollback) partes de una transacción. Para complicarlo aún más, puede que una transacción implique más de una base de datos, y en ocasiones, a más de un servidor (transacciones distribuidas). MySQL proporciona soporte para todos estos tipos de transacciones, siempre que los gestores de almacenamiento utilizados en las bases de datos implicadas también lo soporten.

3.3

Sentencias

CREATE TABLE en MySQL CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name [(create_definition,...)] [table_options] [select_statement] CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name [(] LIKE old_tbl_name [)];

Tipos de Datos:

TINYINT[(length)] [UNSIGNED] [ZEROFILL] SMALLINT[(length)] [UNSIGNED] [ZEROFILL] MEDIUMINT[(length)] [UNSIGNED] [ZEROFILL] INT[(length)] [UNSIGNED] [ZEROFILL] INTEGER[(length)] [UNSIGNED] [ZEROFILL] BIGINT[(length)] [UNSIGNED] [ZEROFILL] REAL[(length,decimals)] [UNSIGNED] [ZEROFILL] DOUBLE[(length,decimals)] [UNSIGNED] [ZEROFILL] FLOAT[(length,decimals)] [UNSIGNED] [ZEROFILL] DECIMAL(length,decimals) [UNSIGNED] [ZEROFILL] NUMERIC(length,decimals) [UNSIGNED] [ZEROFILL] DATE TIME TIMESTAMP DATETIME CHAR(length) [BINARY | ASCII | UNICODE] VARCHAR(length) [BINARY] TINYBLOB BLOB MEDIUMBLOB LONGBLOB TINYTEXT [BINARY] TEXT [BINARY] MEDIUMTEXT [BINARY] LONGTEXT [BINARY] ENUM(value1,value2,value3,...) SET(value1,value2,value3,...)

| | | | | | | | | | | | | | | | | | | | | | | | | | | spatial_type

CREATE TABLESPACE en MySQL CREATE TABLESPACE tablespace_name ADD DATAFILE 'file_name' USE LOGFILE GROUP logfile_group [EXTENT_SIZE [=] extent_size] [INITIAL_SIZE [=] initial_size] [AUTOEXTEND_SIZE [=] autoextend_size] [MAX_SIZE [=] max_size] [NODEGROUP [=] nodegroup_id] [WAIT] [COMMENT [=] comment_text] ENGINE [=] engine_name

CREATE INDEX en MySQL

CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name [USING index_type] ON tbl_name (index_col_name,...) index_col_name: col_name [(length)] [ASC | DESC

ejemplo:  CREATE INDEX part_of_name ON customer (name(10));

CREAR NUEVAS CUENTAS DE USUARIO en MySQL mysql> -> mysql> -> mysql> mysql>

GRANT ALL PRIVILEGES ON *.* TO 'monty'@'localhost' IDENTIFIED BY 'some_pass' WITH GRANT OPTION; GRANT ALL PRIVILEGES ON *.* TO 'monty'@'%' IDENTIFIED BY 'some_pass' WITH GRANT OPTION; GRANT RELOAD,PROCESS ON *.* TO 'admin'@'localhost'; GRANT USAGE ON *.* TO 'dummy'@'localhost';

4. COMPARACIONES

IBM DB2 •

•

•

•

Capacidad para trabajar con todo tipo de datos, ya sea tanto texto como imágenes, audio o vídeo o páginas Web, de forma homogénea, sea cual sea su formato, o incluso dónde residen físicamente. Primera base de datos de la industria capaz de gestionar tanto datos relacionales convencionales como datos XML en formato nativo sin necesidad de transformarlos Además de la capacidad XML nativa, la versión 9 de IBM DB2 incluye otros dos significativos avances como son la compresión de almacenamiento avanzada y capacidades mejoradas para la gestión autónoma de datos Diseñada para convertirse en el motor de información de preferencia para entornos SOA y para lograr el acceso a los datos tanto si están almacenados en bases de datos convencionales como en tablas de Oracle o MySQL

•

• •

•

•

•

•

•

•

Cuenta con compresión automática de almacenamiento, denominada “Venos”, que aporta una capacidad de compresión de almacenamiento similar a la de los grandes servidores corporativos (mainframes) para entornos Linux, UNIX y Windows. Ofrece capacidades de recuperación mucho más completas, robustas y versátiles que cualquier otro servidor de datos anterior IBM ha implementado una nueva función de seguridad para el administrador que, por primera vez, permite unificar distintos privilegios bajo un solo usuario, ofreciendo así mayor control sobre quién tiene acceso a la información IBM DB2 9 cuenta con un avanzado sistema de partición de datos que permite enlazar hasta un máximo de 999 servidores en clúster, manejando una sola base de datos en paralelo. Las limitaciones de almacenamiento en una máquina se multiplican acorde con el número de servidores en el clúster, pudiendo así alcanzar hasta 16 Tb por partición multiplicado por hasta 999 máquinas. DB2 9 es la primera base de datos que soporta simultáneamente los tres sistemas más usados de particionamiento: range partitioning, multi-dimensional clustering y hashing. Además de gran funcionalidad, DB2 9 ofrece mejoras para reducir significativamente la complejidad y el tiempo que los desarrolladores necesitan para crear aplicaciones que puedan acceder tanto a repositorios de datos relacionales como a repositorios XML. La tecnología nativa XML de esta nueva base de datos también da soporte a XQuery, un potente lenguaje estándar de la industria que ha sido diseñado especialmente para procesar datos XML. Los desarrolladores de aplicaciones tendrán la flexibilidad de utilizar XQuery, XPath, el estándar SQL o los tres simultáneamente para consultar datos. DB2 9 incluye también soporte para Visual Studio 2005, servicios web y la capacidad para crear aplicaciones y páginas web sin necesidad de escribir código. DB2 Express-C aparte de ser mas ligero es mas rapido asi como una mejor performance en el uso de mensajes xml( en el blog utiliza iTunes para utilizlar la funionalidad llamada pureXML de DB2).

MySQL • • • • • • • • • •

Un amplio subconjunto de ANSI SQL 99, y varias extensiones. Soporte a multiplataforma. Procedimientos almacenados Disparadores (triggers). Cursores Vistas actualizables. Soporte a VARCHAR INFORMATION_SCHEMA Modo Strict Soporte X/Open XA de transacciones distribuidas; transacción en dos fases como parte de esto, utilizando el motor InnoDB de Oracle.

• • • • • • • • • • • • • • • • • • • • •

• • •

Motores de almacenamiento independientes (MyISAM para lecturas rápidas, InnoDB para transacciones e integridad referencial). Transacciones con los motores de almacenamiento InnoDB, BDB Y Cluster; puntos de recuperación (savepoints) con InnoDB. Soporte para SSL. Query caching Sub-SELECTs (o SELECTs anidados). Réplica con un maestro por esclavo, varios esclavos por maestro, sin soporte automático para múltiples maestros por esclavo. indexing y búsqueda de campos de texto completos usando el motor de almacenamiento MyISAM. Embedded database library Soporte completo para Unicode. Conforme a las reglas ACID usando los motores InnoDB, BDB y Cluster. Shared-nothing clustering through MySQL Cluster. Usa GNU Automake, Autoconf, y Libtool para portabilidad Uso de multihilos mediante hilos del kernel. Usa tablas en disco b-tree para búsquedas rápidas con compresión de índice Tablas hash en memoria temporales El código MySQL se prueba con Purify (un detector de memoria perdida comercial) así como con Valgrind, una herramienta GPL Completo soporte para operadores y funciones en cláusulas select y where. Completo soporte para cláusulas group by y order by, soporte de funciones de agrupación Seguridad: ofrece un sistema de contraseñas y privilegios seguro mediante verificación basada en el host y el tráfico de contraseñas está cifrado al conectarse a un servidor. Soporta gran cantidad de datos. MySQL Server tiene bases de datos de hasta 50 millones de registros. Se permiten hasta 64 índices por tabla (32 antes de MySQL 4.1.2). Cada índice puede consistir desde 1 hasta 16 columnas o partes de columnas. El máximo ancho de límite son 1000 bytes (500 antes de MySQL 4.1.2). Los clientes se conectan al servidor MySQL usando sockets TCP/IP en cualquier plataforma. En sistemas Windows se pueden conectar usando named pipes y en sistemas Unix usando ficheros socket Unix. En MySQL 5.1, los clientes y servidores Windows se pueden conectar usando memoria compartida. MySQL contiene su propio paquete de pruebas de rendimiento proporcionado con el código fuente de la distribución de MySQL.

Comandos Principales MySQL create database drop database drop table delete

DB2 create database drop database drop table delete

alter table connect update select create user insert rename alter database start stop -Start shutdown

alter table db2 connect update select create user insert rename alter database db2start db2stop db2icrt activate database deactivate database

 CREATE DATABASE: Crea una base de datos  DROP DATABASE: Elimina una base de datos  DROP TABLE: Elimina una tabla  DELETE: Elimina informacion relativa en una tabla.  ALTER TABLE: Cambia las propiedades de una table existente.  CONNECT / db2 connect: Inicia una sesion de usuario.  UPDATE: modifica información en una tabla.  SELECT: Recupera la informacion de una o más tablas especificando criterios de selección.  CREATE USER: Crea un usuario.  INSERT: Adiciona información a una tabla, vista, etc.  RENAME:

Renombra una tabla, vista, secuencia, etc.  ALTER DATABASE: Abre una base de datos existente, y/o modificar los archivos asociados.  DB2START / START INSTANCE: Permite iniciar una instancia

 DB2STOP / STOP INSTANCE: Detener una instancia  DB2ICRT / CREATE INSTANCE: Crea una instancia  START / ACTIVATE DATABASE / START: Inicia la base de datos  SHUTDOWN / DEACTIVATE DATABASE / Cierra la base de datos.

MY SQL MINIMUN REQUIREMENTS

Mac OSX AIX 4.x, 5.x BSDI 3.0, 3.1 and 4.x FreeBSD 3.x, 4.x, 5.x OpenBSD 2.5+ Digital Unix 4.x HP-UX 10.20, 11.x NetBSD 1.3/1.4 Intel, 1.3 Alpha SCO Open Server, UnixWare 7.1 SGI Irix 6.5 Solaris 2.5

OS

Memory

32 MB of RAM

Hard Drive

60 to 85 MB depending on the components and operating system; 200 MB recommended for Windows.

DB2 WINDOWS

DB2 UNIX

DB2 EXPRESS C VS MYSQL COMMUNITY

Encriptaci Protecci ó n

Compatib

Reglas de

d e r e d

Usable sin

n a t i v a

c o m p l e j i d a d

Acceso

d e Auditoria

Recursos

Separació

c

Certificació o n n

t r a s e ñ a s

d e

DB2

SI

-

SI

SI

-

MyS DB2 QL

SI SI

SI

SISI

SI SI

SI SI

MyS QL

SI

SI

SI

SI

SI

s e g u r i d a d

Max DB Size DB2

512 TB

MySQL 524,258 TB

DB2

Max char Size 32 KB

MySQL 2 GB

Max Table size 512 TB

Max rowsize 32,677 B

Max columns per row 1012

Max Blob /Clobsize 2 GB 2 GB

524,258 TB

Unlimit ed

30000

Max Number size 64 bits

Min DATE Value 0001

Max DATE Value 9999

128

126 bits

0001

9999

128

Max Column Name Size

CONCLUSIONES •

Todas las bases de datos tienen los archivos de log asociados, estos registran cambios de base de datos.

•

DB2 de IBM es el primer y el único servidor de bases de datos del mundo cuya escalabilidad va desde un computador de bolsillo a una laptop

•

DB2 guarda sus datos contra la pérdida, acceso desautorizado, o entradas inválidas proporcionando

•

MySQL es una dbms open souce por lo tanto se puede modificar el código para hace mejoras necesarias

•

MySQL fue en principio diseñado para manejar bases de datos medianas o pequeñas

•

MySQL se relaciona mejor con aplicaciones PHP, APACHE, entre otras aplicaciones web

•

Se debe recuperar la BD lo más rápidamente posible e intentar que exista una pérdida de datos mínima.

•

DB2 utiliza una combinación de seguridad externa y control interno de acceso a proteger datos, proporciona un juego de datos de acceso de las interfaces para los diferentes tipos de usuarios y aplicaciones, también guarda sus datos contra la pérdida, acceso desautorizado, o entradas inválidas. Usted puede realizar la administración de la DB2 desde cualquier puesto de trabajo.

•

DB2 proporciona una colección de herramientas y los wizard para simplificar la construcción y desplagamiento de aplicaciones para DB2 para Microsoft Windows que usa SQL incluido dentro del Microsoft C++ Integrated Visual el Ambiente de Desarrollo.

6. BIBLIOGRAFIA •

www.lawebdelprogramador.com/cursos/mostrar.php? id=66&texto=Oracle

•

www.ibm.com/db2

•

www-306.ibm.com/software/es/demos/db2.shtml

•

http://www.swen.uwaterloo.ca/~mrbannon/cs798/assignment_0 1/mysql.pdf

•

http://dev.mysql.com/doc/falcon/es/se-falcon-createtable.html

•

http://www.xtec.es/~acastan/textos/Administracion%20de %20MySQL.ht

•

http://swik.net/MySQL/MySQL+vs+MS+SQL+Server

•

http://bicosyes.com/motores-de-almacenamiento-de-mysql/

•

http://www.uaem.mx/posgrado/mcruz/cursos/miic/MySQL.pdf

•

http://dev.mysql.com/doc/refman/5.0/es/features.html

•

http://dev.mysql.com/doc/refman/5.0/es/table-size.html

•

http://www.iessanvicente.com/colaboraciones/motoresMySQL.pd f

•

http://www.treeweb.es/blog-tecnico-mysql-motores-dealmacenamiento

•

http://www.tizag.com/mysqlTutorial/mysqlinsert.php