Sunteți pe pagina 1din 58

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 OUTER JOIN cumpliendo


estándares de sintaxis SQL y ODBC.

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 case-
insensitive.

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 <nombre de la instancia>.

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 <nombre de la instancia>. 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 entrada-
salida 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
Engine 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

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> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'localhost'


-> IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'%'
-> IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
mysql> GRANT RELOAD,PROCESS ON *.* TO 'admin'@'localhost';
mysql> 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 DB2
create database create database
drop database drop database
drop table drop table
delete delete
alter table alter table
connect db2 connect
update update
select select
create user create user
insert insert
rename rename
alter database alter database
start db2start
stop db2stop
-- db2icrt
Start activate database
shutdown 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
OS 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

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 Compatib Reglas de Acceso
ó c
n o
m
d p
e l
e
r j
e i
d d
a
n d
a
t d
i e
v
a c
Usable sin Auditoria Recursos Separació Certificació
o
n n
t
d
r
e
a
s s
e e
ñ g
a u
s r
DB2 SI - SI SI - i
d
a
d
MyS
DB2 SI
SI -
SI SISI SI SI SI SI
QL

MyS SI SI SI SI SI
QL
Max DB Max Max Max Max Blob
Size Table rowsize columns /Clobsize
size per row
DB2 512 TB 512 TB 32,677 1012 2 GB
B

MySQL 524,258 524,258 Unlimit 30000 2 GB


TB TB ed

Max Max Min Max Max Column


char Number DATE DATE Name Size
Size size Value Value
DB2 32 KB 64 bits 0001 9999 128

MySQL 2 GB 126 bits 0001 9999 128


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-de-
almacenamiento
• http://www.tizag.com/mysqlTutorial/mysqlinsert.php

S-ar putea să vă placă și