1. PRINCIPALES CARACTERÍSTICAS DE LOS GESTORES DE BASES DE DATOS.

Existen otras bases de datos relacionales, tanto bases de datos comerciales y de código abierto están disponibles, para este estudio se va a analizar Mysql como base de datos de código abierto y Oracle como base de datos comercial.

1. Mysql

1. Introducción

Mysql en los últimos años ha tenido un crecimiento vertiginoso. Es la base de datos de código abierto más popular del mundo. Código abierto significa que todo el mundo puede acceder al código fuente, es decir, al código de programación de Mysql, esto significa que también todos pueden contribuir con ideas, elementos, mejoras o sugerir optimizaciones. Y así es que Mysql ha pasado de ser una pequeña base de datos a una completa herramienta. Su rápido desarrollo se debe en gran medida a la contribución de mucha gente al proyecto, así como la dedicación del equipo de Mysql.

A diferencia de los proyectos propietarios, en los que el código fuente es desarrollado por un número reducido de personas y se protege atentamente, los proyectos de código abierto no excluyen a nadie interesado en aportar ideas, si disponen de los conocimientos necesarios.

Lo que en un tiempo se consideró como un sencillo juguete para uso en sitios Web, se ha convertido en la actualidad en una solución viable y de misión crítica para la administración de datos.

Mysql es un sistema de administración de bases de datos relacional (RDBMS). Se trata de un programa capaz de almacenar una enorme cantidad de datos de gran variedad y de distribuirlos para cubrir las necesidades de cualquier tipo de organización, desde pequeños establecimientos comerciales a grandes empresas y organismos administrativos. Mysql compite con sistemas RDBMS propietarios como Oracle, Sql Server y Db2.

Mysql incluye todos los elementos necesarios para instalar el programa, preparar diferentes niveles de acceso de usuario, administrar el sistema y proteger los datos. Puede desarrollar sus propias aplicaciones de bases de datos en la mayor parte de lenguajes de programación utilizados en la actualidad y ejecutarlos en casi todos los sistemas operativos, incluyendo algunos de los que probablemente no ha oído hablar nunca. Mysql utiliza el lenguaje de consulta estructurado (SQL).

Antes Mysql se consideraba como la opción ideal de sitios web; sin embargo, ahora

incorpora muchas de las funciones necesarias para otros entornos y conserva su gran velocidad. Mysql es una base de datos robusta que se la puede comparar con una base de datos comercial, es incluso más veloz en el procesamiento de las transacciones y dispone de un sistema de permisos elegante y potente, y ahora, además, incluye un motor de almacenamiento InnoDb[17] compatible con ACID[18], además dispone de store procedures, triggers, vistas.

Mysql es rápido, y una solución accesible para administrar correctamente los datos de una empresa. MysqlAB es la compañía responsable del desarrollo de Mysql, dispone de un sistema de asistencia eficiente y a un precio razonable, y, como ocurre con la mayor parte de las comunidades de código abierto, se puede encontrar una gran cantidad de ayuda en la Web.

Son muchas las razones para escoger a Mysql como una solución de misión crítica para la administración de datos:

• Costo: Mysql es gratuito para la mayor parte de los usos y su servicio de asistencia resulta económico.
• Asistencia: MysqlAB ofrece contratos de asistencia a precios razonables y existe una nutrida y activa comunidad Mysql.
• Velocidad: Mysql es mucho más rápido que la mayoría de sus rivales.
• Funcionalidad: Mysql dispone de muchas de las funciones que exigen los desarrolladores profesionales, como compatibilidad completa con ACID, compatibilidad para la mayor parte de SQL ANSI[19], volcados online, duplicación, funciones SSL e integración con la mayor parte de los entornos de programación.
• Portabilidad: Mysql se ejecuta en la inmensa mayoría de sistemas operativos y, la mayor parte de los casos, los datos se pueden transferir de un sistema a otro sin dificultad.
• Facilidad de uso: Mysql resulta fácil de utilizar y de administrar. Las herramientas de Mysql son potentes y flexibles, sin sacrificar su capacidad de uso.

Las tablas estáticas tienen longitud fija. Cada registro tiene asignado exactamente 10 Bytes.

Este tipo de tablas se caracterizan por:

• Ser muy rápidas (ya que Mysql sabe que el segundo nombre comienza siempre en el carácter número once)
• Resultan sencillas de almacenar en caché.
• Resultan sencillas para reconstruir tras un fallo.
• Requieren más espacio de disco

1. Tablas Dinámicas

Las columnas de las tablas dinámicas tienen diferentes tamaños. Auque este tipo de dato ahorra espacio, resulta sin embargo más complejo.

Las tablas de tipo dinámico presentan las siguientes características:

• Todas las columnas de cadena son dinámicas.
• Por regla general, ocupan mucho menos espacio de disco que las tablas fijas.
• Las tablas requieren un mantenimiento regular para evitar su fragmentación.
• No resulta tan sencillo de reconstruir tras un fallo, especialmente si las tablas están muy fragmentadas.

1. Tablas comprimidas

Las tablas comprimidas son tablas de solo lectura que utilizan mucho menos espacio en disco.

Son ideales para su uso con datos comprimidos que no cambien (que solo se pueden leer y no escribir) y donde no exista mucho espacio disponible.

Las tablas comprimidas presentan las siguientes características:

• Las tablas son mucho más pequeñas.
• Como cada registro se comprime de forma separada, la carga de acceso es reducida.
• Cada columna se podría comprimir de forma diferente, utilizando distintos algoritmos de compresión.
• Se puede comprimir formatos de tabla fija y dinámica.

1. Tablas Merge

Las tablas Merge son la fusión de las tablas MyISAM iguales.

Por lo general se usa cuando las tablas MyISAM comienzan a resultar demasiado grandes.

Entre las ventajas de estas tablas se pueden mencionar las siguientes:

• Resultan más rápidas en determinadas situaciones.
• El tamaño de la tabla es más pequeño

Desventajas de la tabla Merge:

• Resultan mucho más lentas en búsquedas.
• El comando REPLACE no funciona sobre ellas.

1. Tablas Heap

Las tablas Heap son el tipo de tabla más rápido porque se almacena en memoria y utilizan un índice asignado. La contrapartida es que como se almacenan en memoria, en el caso de una falla del sistema, los datos se pierden.

2. Tablas Innodb

Las tablas Innodb son tablas de transacción segura (lo que significa que dispone de las funciones COMMIT y ROLLBACK). En una tabla MyISAM, la tabla entera se bloquea al realizar funciones de inserción. Durante esa fracción de segundo, no se puede ejecutar ninguna otra instrucción sobre la tabla. Innodb utiliza funciones de bloqueo a nivel de fila de manera que solo se bloquee dicha fila y no toda la tabla, y se puedan seguir aplicando instrucciones sobre otras filas.

1. Transacciones y bloqueos

Las consultas sobre la base de datos se ejecutan una después de otra. En el caso de un sitio Web que sirva páginas, da lo mismo el orden en que la base de datos realice las consultas, siempre y cuando lo haga rápidamente. Sin embargo, ciertos tipos de consultas necesitan realizarse en un orden dado, como las que dependen de los resultados de una consulta anterior, o grupos de actualizaciones que necesitan realizarse en conjunto. Todos los tipos de tabla pueden utilizar la función de bloqueo, pero sólo los tipos innodb y BDB disponen de funciones transaccionales integradas.

2. Las transacciones en las tablas Inodb

La potencia de las tablas innodb procede del uso de transacciones o instrucciones SQL agrupadas en una. Un ejemplo típico son las transacciones bancarias.

Por ejemplo, si se transfiere una cantidad de dinero desde la cuenta de una persona a otra, se realizan al menos dos consultas:

UPDATE Persona1 SET Valor = ValorDisponible – ValorADebitar;

UPDATE Persona2 SET Valor = ValorDisponible + ValorADebitar;

El proceso parece claro, pero que ocurriría si algo sale mal durante el proceso y el sistema falla entre las dos consultas sin que llegue a completarse la segunda. Se habrá retirado los fondos de la cuenta de la primera persona, se creerá que el pago se ha realizado. Sin embargo, la segunda persona no estará muy contenta porque el pago no se ha realizado. En este tipo de transacciones, resulta fundamental asegurarse de que las dos consultas se levan a cabo o que no se hace ninguna de las dos. Para ello, se empaquetan en los que se conoce como una transacción, con una instrucción BEGIN para indicar el inicio de la transacción y una instrucción COMMIT para indicar el final. Solo tras procesar la instrucción COMMIT, las consultas se habrán convertido en permanentes. Si algo sale mal a media ejecución, podemos utilizar el comando ROLLBACK para invertir la parte incompleta de la transacción.

3. Lecturas coherentes

De manera predeterminada, las tablas innodb realizan una lectura coherente. Esto significa que al realizar una consulta de selección, Mysql devuelve los valores presentes de la base de datos hasta la última transacción completada. Si en el momento de realizar la consulta existe alguna transacción en progreso, los resultados de las instrucciones UPDATE o INSERT no se reflejarán, con una excepción: la transacción abierta puede modificarse (puede que haya observado que al realizar la consulta BEGIN-INSERT-SELECT, se visualizó el resultado insertado). Para poder verlo, necesita tener dos ventanas abiertas y estar conectado a la base de datos.

4. Lectura de Bloqueos para actualizaciones

Las lecturas coherentes no siempre resultan adecuadas. Por ejemplo, que ocurriría si varios usuarios están intentando agregar un nuevo registro en una tabla innotest? Cada nuevo registro inserta un número ascendente exclusivo, este campo no es clave principal o un campo de incremento automático, por lo tanto nada impide que cree el registro duplicado. Sin embargo, no queremos que eso ocurra. Lo que desearíamos es leer el valor actual e insertar un nuevo valor, incrementando en una unidad. Pero esta acción no garantiza un valor único.

La forma de evitar resultados erróneos es realizando un bloqueo de actualización sobre la operación de selección. Si indicamos a Mysql, que estamos realizando una lectura de actualización, no permitirá que nadie más lea el valor hasta que nuestra transacción se haya completado.

5. Bloqueos de lectura en modo compartido

Existe otro tipo de bloqueo de lectura que no devuelve un valor si el valor que está leyendo ha sido modificado por una transacción incompleta. Devuelve el último valor, pero no forma parte de una transacción cuya intención es modificar el valor.

6. Transacciones en tablas BDB

Las tablas BDB procesan las transacciones de forma ligeramente diferente a las tablas Innodb. Si una persona está realizando una transacción sobre una tabla x, si esta transacción no está completa, ninguna persona podrá consultar los datos de esta tabla mientras la transacción no finalice.

El periodo de tiempo que puede significar al llevar a cabo esta consulta es demasiado. El hecho de que no se trate de una consulta de selección "rápida" en las tablas BDB significa que todas las transacciones que se pospongan pueden dar lugar a graves problemas de rendimiento.

Como en el caso de las tablas innodb, el modo predeterminado de AUTOCOMMIT = 1. Esto significa que a menos que coloque sus cambios dentro de una transacción (comenzando con BEGIN), se completarán inmediatamente.  

7. Otros comportamientos transaccionales

Existe una serie de comandos adicionales que finalizan automáticamente una transacción (en otras palabras, que se comportan como si hubiéramos realizado una operación de confirmación):

• BEGIN
• ALTER TABLE
• CREATE INDEX
• RENAME TABLE
• TRUNCATE
• DROP TABLE
• DROP DATABASE
• LOCK TABLES

Hay que tener mucho cuidado cuando se realizan transacciones ya que al ejecutar cualquiera de estos comandos cuando las transacción este a medias, automáticamente se realizará un COMMIT.

1. Bloqueo de tablas

Mysql maneja bloqueo a nivel de fila como lo revisamos anteriormente en el análisis de las tablas innodb y BDB. Los bloqueos a nivel de fila son mucho más eficaces cuando se necesita realizar una gran cantidad de inserciones o actualizaciones en la tabla. El bloqueo a nivel de fila, sin embargo, solo está disponible para los tipos de tabla de transacción segura (BDB e Innodb). Mysql incorpora la función de bloqueo a nivel de tablas, que está disponible para todos los tipos de tabla.

Existen dos tipos de bloqueos de tabla: los bloqueos de lectura y los bloqueos de escritura. Los bloqueos de lectura solo permiten realizar lecturas sobre la tabla, quedando bloqueadas las operaciones de escritura. Los bloqueos de escritura impiden la realización de operaciones de lectura o escritura sobre la tabla durante el bloqueo.

2. Cómo evitar los bloqueos de tabla

Se debe evitar los bloqueos sobre tablas que necesiten realizar un gran volumen de actualizaciones, ya que, en el caso de los bloqueos de escritura, no se puede leer o escribir ningún registro de la tabla durante el bloqueo.

Además, como los bloqueos de escritura tienen prioridad sobre los de lectura de manera predeterminada, no se puede leer ningún registro hasta que todas las operaciones de actualización e inserción se completen, lo que puede provocar que Mysql se atasque de forma terrible. Existen varias formas de evitar los bloqueos de tabla. Una de ellas consiste en realizar la operación de lectura y actualización dentro de la misma instrucción (es lo que se conoce como actualización incremental).

3. Niveles de transacción

Se puede modificar el comportamiento predeterminado al trabajar con transacciones mediante el establecimiento del nivel de transacción. Existen varios niveles de transacción en Mysql. En concreto admite los siguientes niveles de aislamiento de transacción.

0. READ UNCOMMITTED

Este nivel permite transacciones para leer datos sin confirmar desde otras transacciones (es lo que se conoce como lectura sucia).

1. REPEATABLE READ

Este nivel no permite lecturas no susceptibles de repetición (que son las que se dan cuando otra transacción ha modificado los datos, incluso si se han confirmado).

2. SERIALIZABLE

Este nivel no permite lecturas fantasma, que tienen lugar cuando otra transacción ha confirmado una nueva fila que coincide con los resultados de nuestra consulta. Los datos serán los mismos en cada ocasión.

4. Indices y optimización de consultas

Es posible agilitar la velocidad en las consultas mediante el uso de métodos básicos.

El uso inteligente de índices ayudará a que la consulta, la actualización sea más rápida.

El ajuste correcto del servidor también contribuye a lograr mejoras notables.

5. Compresión de los índices

Al realizar una consulta sobre una tabla X de la base de datos, los registros son recuperados mediante un barrido completo de la tabla si la misma no utiliza índices, el problema es notorio cuando queremos buscar información con cierto criterio de búsqueda, haciendo que la consulta se demore demasiado.

La operación de recorrer la tabla de esta forma (de principio a fin, examinando todos los registros) se conoce como examen completo de la tabla. Cuando las tablas son de gran tamaño, esta operación resulta poco eficiente ya que la labor de examinar tablas compuestas de varios cientos de miles de registros puede resultar muy lenta. Para evitar este problema, se debe ordenar los registros. Sin embargo, puede ocurrir que deseemos buscar registros de la tabla utilizando otro criterio de búsqueda. La solución es crear listas separadas para cada campo que se desee ordenar, a este ordenamiento se le conoce como índice.

En Mysql existen cuatro tipos de índice: clave primaria, un índice exclusivo, un índice de texto completo, y un índice ordinario.

6. Tipos de Indice

0. Clave primaria

Una clave primaria es un índice establecido sobre un campo en el que cada valor es exclusivo y ninguno de los valores puede ser nulo.

Para establecer una clave primaria al crear la tabla, se debe utilizar la instrucción PRIMARY KEY al final de las definiciones del campo, es importante la palabra clave NOT NULL, es además obligatoria al crear un campo primario, esto indica a la base de datos que no se admiten valores nulos ni valores duplicados ya que la clave primaria es única.

1. Indice exclusivo

Los índices que no son primarios, permiten valores duplicados (a menos que los campos se especifiquen como únicos). Un índice exclusivo permite realizar búsquedas por un solo registro de la tabla que no necesariamente es único pero que la gran cantidad de registros almacenados amerita la creación de este índice.

2. Indice de texto completo

Se puede crear este tipo de índice sobre cualquier campo Char, Varchar o Text. Los índices de texto completo están diseñados para facilitar la búsqueda sobre palabras clave en capos de texto de tablas grandes.

Para devolver los resultados de una búsqueda de texto completo, se utiliza la función MATCH(), y se busca la correspondencia de un campo con un valor.  

3. Indice ordinario

Un índice ordinario es aquel que por necesidad del programador o de la consulta es necesario la creación del índice, este puede ser de uno o varios registros. Hay que tener cuidado en la creación de este tipo de índices, ya que pueden degradar el correcto funcionamiento de la base de datos, no se puede crear porque sí, es necesario examinar detenidamente si es óptimo o no.

7. Tipos de Tabla e índices

Cada tipo de tabla tiene su propio comportamiento en materia de índices y cada una de ellas lo procesa de manera diferente. No todos los tipos de índices están disponibles para los distintos tipos de tabla. Es importante tener claro como se va a utilizar una tabla y los índices que se van a necesitar ante de seleccionar el tipo de tabla. En ocasiones, lo que parece ser el tipo de tabla perfecta se convierte en la peor elección porque o se puede utilizar un determinado tipo de índice en ella.

A continuación se enlista las funciones y las diferencias de índices para cada tipo de tabla. Las tablas MyISAM presentan las siguientes características:

• Los índices se almacenan con la extensión .MYI
• Los índices de número se almacenan con el byte alto primero par permitir una mejor compresión del índice.
• Se puede utilizar índices BLOB y TEXT.
• Se permiten valores nulos en los índices.
• Los datos y el índice se pueden incluir en directorios diferentes ( lo que permite una mayor velocidad).

Las tablas MERGE presentan las siguientes características:

• Las tablas MERGE no contienen índices propios.
• El archivo .MRG contiene una lista de los archivos .MYI de índice procedentes de las tablas MyISAM integrantes.
• Sigue siendo necesario especificar los índices al crear la tabla MERGE.

Las tablas HEAP presentan las siguientes características:

• Utilizan un índice de asignación almacenado en memoria, que resulta muy rápido.
• Solo puede utilizar índices con los operadores = y <=>.
• No puede usar un índice en una columna que permita valores nulos.
• Los índices no se pueden utilizar con la cláusula ORDER BY.
• Mysql no puede determinar el número aproximado de filas que existen entre los dos valores ( este resultado es utilizado por el optimizador de consultas para seleccionar el índice más eficaz que utilizar).

Las tablas ISAM utilizan un índice B-TREE almacenado en archivos con la extensión .ism.

Las tablas InnoDB no pueden utilizar índices de texto completo.

1. Uso eficaz de los índices

Las tablas con pocos índices devolverán los resultados muy rápido. Pero la inclusión de demasiados índices, aunque no suele ser normal, también ocasiona degradación de la base de datos. Los índices ocupan espacio de disco y, como están ordenados, cada vez que se realice una operación de inserción o de actualización, es necesario volver a organizar el índice para incluir los cambios, lo que da como resultado una carga de trabajo adicional significativa. La eficiencia en el uso de los índices depende también de la configuración de Mysql.

2. Dónde utilizar los índices

El uso más común de un índice consiste en recuperar filas que cumplan una condición incluida en la cláusula WHERE.

Es muy importante crear el índice correcto, sobre el campo correcto, revisando siempre que forme parte de la condición.

Al buscar valores máximos o mínimos, Mysql, sólo necesita tomar el primer valor o el último de una tabla ordenada con un índice, lo que resulta extremadamente rápido.

Si se solicita con frecuencia valores máximos o mínimos, resulta muy útil crear un índice sobre el campo pertinente.

3. Sistema de prefijación más a la izquierda

Comenzando por la parte izquierda de la lista de campos del índice, Mysql puede utilizar cada uno de ellos, uno tras otro, siempre y cuando sigan la secuencia empezando por la izquierda.

Para una mejor comprensión de este concepto se va a utilizar el siguiente índice:

Tabla: Customer, INDEX(surname, inicial, first_name).

Si se realiza una consulta incluyendo los tres campos que forman parte del índice, lograríamos el mayor provecho del índice creado;

SELECT * FROM customer WHERE surname = ‘Clegg’ AND inicial = ‘X’ AND first_name = ‘Yvonne’.

También sacaríamos el máximo partido del índice si buscamos por el apellido y la inicial.

SELECT * FROM customer WHERE surname = ‘Clegg’ AND inicial = ‘X’.

O simplemente por el apellido:

SELECT * FROM customer WHERE surname = ‘Clegg’.

Sin embargo, si se rompe la secuencia de disposición más a la izquierda y realiza la búsqueda por el nombre o la inicial o por ambos campos, Mysql no utilizará el índice:

SELECT * FROM customer WHERE inicial = ‘X’ AND first_name = ‘Yvonne’.

SELECT * FROM customer WHERE first_name = ‘Yvonne’.

SELECT * FROM customer WHERE inicial = ‘X’.

Ninguna de las anteriores consultas utiliza el índice.

4. Selección de Indices

Se debe tomar en cuenta los siguientes consejos antes de seleccionar un índice:

• Los índices solo deben crearse en aquellas consultas que lo utilicen (por ejemplo, sobre campos de la condición WHERE) y no sobre campos que o vayan a utilizarlos (como en el caso en el que el primer carácter de la condición sea un comodín).
• Crear índices que devuelvan el menor número de filas posibles. El mejor lugar es sobre una clave primaria ya que estas se asignan de manera exclusiva sobre un registro. De manera similar, los índices sobre campos enumerados no resultan particularmente útiles (por ejemplo, un índice sobre un campo que contenga valores si o no, solo serviría para reducir la selección a la mitad, con toda la carga que supone el mantenimiento de un índice ).
• Utilizar índices cortos (crear un índice sobre los 10 primeros caracteres de un nombre, por ejemplo, en lugar de hacerlo sobre el campo completo).
• NO se debe crear demasiados índices. Los índices aumentan el tiempo necesario para actualizar o agregar un registro. Por ello, si el índice se crea para una consulta que se utilice en contadas ocasiones y pueda aceptarse un rendimiento ligeramente más lento, considere la opción de no crear el índice.
• Utilice el sistema de prefijación más a la izquierda.

1. Optimización de Selecciones

Mientras mayor sea el número de tablas que se combinan, mayor será la cantidad de filas examinadas. Parte del buen diseño de las bases de datos consiste en hallar un equilibrio entre las tablas pequeñas de las bases de datos que necesitan más combinaciones y las tablas de mayor tamaño que resultan más difíciles de mantener.

Lo principal para que una consulta sea óptima es la selección correcta del índice y la cláusula WHERE correctamente definida, tomando en cuenta la prefijación más a la izquierda.

En Mysql un detalle importante es el comando EXPLAIN, que ayuda al programador a conocer en detalle que índice se está utilizando, cuantos registros revisó para sacar la consulta, como es procesada la instrucción SELECT, esta instrucción es de gran ayuda para escribir consultas optimas y seleccionar el índice adecuado a la consulta.

Cuando más complejos sean los permisos, mayor será la carga de trabajo que experimentan las consultas.

2. Optimización de actualizaciones, eliminaciones e inserciones

Una operación de actualización es prácticamente igual a una operación de selección con la diferencia de que se realiza una operación de escritura al final.

Es posible optimizar una instrucción UPDATE de la misma forma con la que haríamos con la instrucción SELECT. Así mismo, hay que tener en cuenta que cuando menor sea el número de índices y el número de datos, más rápida resultará la operación.

La velocidad de la instrucción DELETE depende del número de índices. Al eliminar registros, resulta necesario suprimir, cada uno de ellos de todos los índices.

El mejor método para insertar datos consiste en utilizar LOAD DATA en lugar de INSERT, ya que puede resultar 20 veces más rápido.

• PMON.- Process Monitor, Monitorea los procesos de los usuarios en caso de que la conexión falle. Su misión es monitorizar los procesos del servidor y tomar acciones correctivas cuando alguno de ellos se interrumpe en forma abrupta, limpiando la caché y liberando los posibles recursos que pudieran estar asignados en ese momento. También es responsable por el restablecimiento de aquel proceso que se ha interrumpido bruscamente.
• SMON.- System Monitor, este proceso es el encargado de recuperar la instancia y abrir la base da datos en caso de que ocurra alguna falla. Levanta una instancia cuando se le da la instrucción de partida (al comienzo del trabajo, encontrándose previamente en shutdown). Enseguida limpia los segmentos temporales y recupera las transacciones que pudieran haberse interrumpido debido a una falla del sistema. Además disminuye la fragmentación del sistema agrupando aquellas extensiones libres que existen dentro de la base de datos.
• CKPT.- CheckPoint Process, Sintoniza las tareas de grabación en la base de datos. Es el responsable de advertir al proceso DBWR de efectuar un proceso de actualización en el disco de los datos mantenidos en memoria, incluyendo los datafiles y control files (para registrar el checkpoint). Este proceso es opcional, si no está presente, es el proceso LGWR quien asume la responsabilidad de la tarea.
• DBWR.- DataBase Writer, escribe los bloques de datos de la memoria en la base de datos. Es el responsable de la escritura en disco de toda la información almacenada en los buffers de bloques que no se han actualizado.
• LGWR.- Log Writer, graba los bloques del redo log del buffer a los archivos Redo Log File.
• ARCH (archiver): La función de este proceso es la de respaldar la información almacenada en los archivos redo log cuando éstos se llenan. Este proceso está siempre activo cuando se ha establecido el modo ARCHIVELOG. Si el sistema no está operando en este modo se hace más difícil recuperar el sistema sin problemas luego de una falla general.

1. Area Global del sistema (SGA)

El SGA es un área de memoria compartida que se utiliza para almacenar información de control y de datos de la instancia. Se crea cuando la instancia es levantada y se borra cuando ésta se deja de usar (cuando se hace shutdown). La información que se almacena en esta área consiste de los siguientes elementos, cada uno de ellos con un tamaño fijo:

El buffer de caché (database buffer cache): almacena los bloques de datos utilizados recientemente (se hayan o no confirmado sus cambios en el disco). Al utilizarse este buffer se reducen las operaciones de entrada y salida y por esto se mejora el rendimiento.

El buffer de redo log: Guarda los cambios efectuados en la base de datos. Estos buffers escriben en el archivo físico de redo log tan rápido como se pueda sin perder eficiencia. Este último archivo se utiliza para recuperar la base de datos ante eventuales fallas del sistema.

El área shared pool: Esta sola área almacena estructuras de memoria compartida, tales como las áreas de código SQL compartido e información interna del diccionario. Una cantidad insuficiente de espacio asignado a esta área podría redundar en problemas de rendimiento. En resumen, contiene las áreas del caché de biblioteca y del caché del diccionario de datos.

• El caché de biblioteca se utiliza para almacenar código SQL compartido. Aquí se manejan los árboles de parsing y el plan de ejecución de las queries. Si varias aplicaciones utilizan la misma sentencia SQL, esta área compartida garantiza el acceso por parte de cualquiera de ellas en cualquier instante.
• El caché del diccionario de datos está conformado por un grupo de tablas y vistas que se identifican la base de datos. La información que se almacena aquí guarda relación con la estructura lógica y física de la base de datos. El diccionario de datos contiene información tal como los privilegios de los usuarios, restricciones de integridad definidas para algunas tablas, nombres y tipos de datos de todas las columnas y otra información acerca del espacio asignado y utilizado por los objetos de un esquema.

1. Area Global de programas (PGA)

Esta área de memoria contiene datos e información de control para los procesos que se ejecutan en el servidor de Oracle (relacionados con la base de datos, por supuesto). El tamaño y contenido de la PGA depende de las opciones del servidor que se hayan instalado.

2. La Base da Datos

Dentro de los procesos que forman parte de las base de datos tenemos:

• Control File, que contiene la información para controlar y mantener la integridad de la base de datos.
• Data files, son lo archivos en los cuales se almacenan los datos de las aplicaciones.
• Redo Log Files, almacena los cambios hechos en la base de datos con propósito de recuperarlos en caso de falla.

1. Estructuras adicionales

• Parameter File, contiene parámetros y valores que definen las características de la instancia y de la base de datos.
• Password File, se utiliza para validar al usuario que puede bajar y subir la instancia Oracle.
• Achived Log Files, son copias fuera de línea de los archivos Redo Log Files que son necesarios para el proceso de recovery en caso de falla del medio de almacenamiento.  

1. Conexión a la instancia Oracle

De la relación de servicios creados durante la instalación de Oracle, por ahora nos interesa básicamente dos.

• El servicio relacionado con la instancia y la base de datos, cuyo nombre tiene la siguiente estructura: OracleServiceXXX, donde XXX representa el nombre de la instancia.
• El servicio relacionado con la disponibilidad de servidor para el acceso remoto, el nombre del servicio es: OracleOraHome92TNSListener.

Para una correcta conexión, estos dos servicios deben estar ejecutándose.

1. Esquema General

Gráfico # 7: Esquema General

Fuente: Manual de Oracle

Autor: Diego Burbano

• Proceso Usuario. Programa, aplicación ó herramienta que usa el usuario para iniciar un proceso de usuario y establecer una conexión.
• Proceso Servidor. Una vez que el proceso del usuario estable ce conexión, un proceso servidor es iniciado, el cual manejará las peticiones del usuario. Un proceso servidor puede ser dedicado, es decir solo atiende las peticiones de un solo proceso usuario, ó puede ser compartido, con lo cual puede atender múltiples procesos usuario.
• Sesión. Una sesión es una conexión específica de un usuario a un servidor Oracle. Se inicia cuando el usuario es validado por el servidor Oracle. Finaliza cuando el usuario termina la sesión en forma normal (logout) ó aborta la sesión.

1. Conexión Remota

Gráfico # 8: Conexión Remota

Fuente: Manual de Oracle

Autor: Diego Burbano

Oracle tiene su herramienta de red que permite a las aplicaciones en general conectarse a servidores Oracle. Para que una aplicación pueda conectarse a un servidor Oracle, es necesario que el Proceso Escucha se encuentre ejecutándose en el servidor(OracleOraHome92TNSListener).

El esquema de conexión remota se puede apreciar en el gráfico # 8.

El proceso se describe a continuación:

1. El cliente establece una conexión al proceso Escucha usando el protocolo configurado y envía un paquete CONNECT.
2. El proceso Escucha comprueba que el SID esté definido. Si es así, genera un nuevo proceso para ocuparse de la conexión. Una conexión, se establece en el proceso Escucha y el nuevo proceso del servidor para pasarle la información del proceso de inicialización. Luego la conexión es cerrada.
3. El proceso del servidor envía un paquete al cliente.
4. Un nuevo paquete CONNECT es enviado al proceso servidor dedicado.
5. El proceso del servidor dedicado acepta la conexión entrante y remite un mensaje de ACEPTADO al nuevo cliente.

1. Tipos de datos

Los tipos de datos Oracle se agrupan en los siguientes conjuntos:

Tabla # 6: Tipos de datos Oracle

Fuente: Manual de Oracle

Autor: Diego Burbano

Los valores alfanuméricos van encerrados entre comilla simple.

Los valores numéricos son número simple: 123

Las fechas van encerradas entre comillas simples ejm: ‘14/09/1977’.

Los valores binarios no pueden ser representados, son videos, fotos.

Para los textos, oracle dispone de los siguientes tipos:

• VARCHAR(2), para textos de longitud variable de hasta 4000 caracteres.
• CHAR, para textos de longitud fija de hasta 2000 caracteres.
• NCHAR, para el almacenamiento de caracteres nacionales, de texto fijo.
• NVARCHAR(2), para el almacenamiento de caracteres nacionales de longitud variable.

En todos estos tipos se indica el tamaño en paréntesis tras el nombre del tipo, este tamaño, en el caso de los tipos VARCHAR(2), es obligatorio, en el caso de los tipos CHAR son opcionales (si no se pone toma uno como default).

El tipo de dato Number es un tipo de dato versátil, que permite representar todo tipo de números de entre 10E-130 y 9,99999999999 * 10E128. Fuera de estos rangos, oracle devuelve un error.

Los números decimales, se indican con NUMBER (p, s), donde p es la precisión máxima y s es la escala.

El tipo de dato DATE, permite almacenar fechas. Las fechas se puede escribir en formato día, mes, año entre comillas. El separador puede ser /, - y casi cualquier símbolo.

El tipo de dato TIMESTAMP, es una extensión del anterior, almacena valores de día, mes, año, junto con la hora, minutos y segundos, con lo que representa un instante concreto en el tiempo.

El tipo de dato INTERVAL representa intervalos de tiempo.

El tipo de dato RAW sirve para almacenar valores binarios de hasta 2000 bytes (se puede especificar el tamaño máximo entre paréntesis).

LOB, son varios tipos de datos que permiten almacenar valores muy grandes. Incluye BLOB, CLOB, NCLOB y BFILE.

El tipo ROWID, es un valor hexadecimal que representa la dirección única de una fila en su tabla.

1. Transacciones y bloqueos
2. Transacciones

Se denomina transacción al espacio de tiempo que transcurre desde la primera sentencia DML que no sea SELECT (INSERT, UPDATE O DELETE) hasta que damos por finalizada la transacción explícitamente (con las sentencias apropiadas) o implícitamente (finalizando la sesión). Una base de datos está en estado consistente si, obedece todas las restricciones de integridad definidas sobre ella. Durante la transacción, todas las modificaciones realizadas sobre la base de datos, no son definitivas, más concretamente, se realizan en un TABLESPACE especial que se denomina ROOLLBACK o RBS (Roolback segment). Este tablespace, tiene reservado un espacio para cada sesión activa en el servidor, y es en este espacio donde, se almacenan cada una de las modificaciones de la transacción. Una vez que la transacción se ha finalizado, las modificaciones temporales almacenadas en el RBS, se vuelcan al tablespace original, donde está almacenada nuestra tabla. Esto permite que ciertas modificaciones que se realizan en varias sentencias, se puedan validar todas a la vez, o rechazar todas a la vez. Es importante asegurar siempre que la base de datos nunca este en un estado de inconsistencia. Sin embargo, durante la ejecución de una transacción, la base de datos puede estar temporalmente en un estado inconsistente. El punto importante aquí, es que la base de datos regrese al estado consistente al final de la transacción.

 

Gráfico #9: Estado transaccional de la base de datos



Fuente: Manual Administración de Oracle

Autor : Diego Burbano

0. Operación de transacciones

 El siguiente gráfico, ilustra el funcionamiento de una transacción, cuando es confirmada y cuando es cancelada.

Gráfico #10: Ejecución de transacciones



Fuente: Manual Administración de Oracle

Autor : Diego Burbano

El inicio de una transacción es de manera automática cuando ejecutamos una sentencia insert, update o delete. La ejecución de cualquiera de estas sentencias da inicio a una transacción. Las instrucciones que se ejecuten a continuación formarán parte de la misma transacción.

Para confirmar los cambios realizados durante una transacción, utilizamos la sentencia COMMIT.

Para cancelar los cambios realizados durante una transacción, utilizamos la sentencia ROLLBACK.

Opcionalmente existe la sentencia SAVEPOINT para establecer puntos de transacción.

Si el número de sentencias es tan grande que el RBS se llena, Oracle hará un rollback, por lo que perdemos todos los datos. Así que es recomendable hacer COMMIT cada vez que el estado de la base de datos sea consistente.

Si terminamos la sesión, con una transacción pendiente, Oracle consultará el parámetro AUTOCOMMIT, y si este está en TRUE, hará COMMIT, si está en FALSE hará ROLLBACK.

Hay que tener en cuenta que cualquier instrucción DDL (como alter table por ejemplo), o una instrucción DCL (como grant), si es ejecutada durante la transacción, ese instante pasan a ser definitivas y finaliza toda la transacción.

También es importante tomar en cuanta que si el usuario que inicia la transacción, realiza una consulta a los datos, está, mostrará los datos ya modificados, el resto de usuarios, ve los datos tal y como estaban antes de la transacción, de hecho, los registros afectados por la transacción, aparecen bloqueados hasta que la transacción finalice. Tras la transacción, todos los usuarios ven los datos que quedan al final de la transacción. Los bloqueos son liberados y los puntos de ruptura borrados.

1. Bloqueos

Se pueden diferenciar dos clases de cloqueos:

• Un bloqueo de lectura que da acceso de solo lectura a un objeto y evita que cualquier otra transacción actualice el objeto, esta clase de bloqueo se llama a menudo, de lectura compartida puesto que varias transacciones pueden tener este tipo de bloqueo al mismo tiempo.
• Un bloqueo de escritura que otorga un acceso exclusivo de lectura-escritura y previene a la fuerza, que otras transacciones lean o escriban sobre el mismo objeto.

Es importante notar que no es necesario bloquear un registro de la base de datos durante la duración de la transacción ya que esto incrementaría la posibilidad de que ocurra un bloqueo mutuo (dead lock), por esta razón, el bloqueo se lo podría hacer solamente durante el acceso real al objeto.

Para resolver el conflicto creado por bloqueo mutuo, lo más usual es deshacer alguna de las transacciones. En Oracle se escoge aquella que tenga la menor cantidad de trabajo realizado.

1. Dead Lock

Consideremos el siguiente ejemplo:

• T1 efectúa un bloqueo de escritura en el objeto A.
• T2 efectúa un bloqueo de escritura en el objeto B.
• T1 solicita un bloqueo sobre el objeto B pero debe esperar porque T2 lo tiene bloqueado.
• T2 solicita un bloqueo sobre el objeto A pero debe esperar porque T1 lo tiene bloqueado.

En este punto, ni T1 ni T2 pueden proceder porque están bloqueadas mutuamente. La estrategia para resolver este tipo de problemas, es , permitir que los bloqueos mutuos ocurran, detectarlos y resolverlos. La técnica de detección de un bloqueo mutuo (dead lock) puede ser muy costosa si el nivel de granularidad es alto.

El bloqueo en Oracle es completamente automático y no requiere intervención del usuario. No obstante, también se le permite al usuario bloquear cuando lo considere necesario, deshabilitando el bloqueo por defecto.

La forma de hacerlo es:

LOCK TABLE tabla1 IN {SHARE | SHARE UPDATE | EXCLUSIVE} MODE [NOWAIT].

Candado.- impide que una transacción, accese a un registro reservado previamente por otra transacción, hasta que la transacción libere el registro o el campo.

Granularidad.- es el tamaño del item sobre el cual se ejerce el bloqueo. Este item, puede ser una página, bloque, una tabla o toda la base de datos.

1. Características relacionales orientadas a objetos

Oracle tiene soporte extensivo para constructores relacionales orientados a objetos, incluyendo:

• Tipos de objetos. Se soporta un único modelo de herencia para las jerarquías de tipos.
• Tipos de colecciones. Oracle soporta varrays, que son arrays de longitud variable, y tablas anidadas.
• Tablas de objetos. Se utilizan para almacenar objetos mientras se proporciona una vista relacional de los atributos de los objetos.
• Funciones de tablas. Son funciones que producen conjuntos de filas como salida y se pueden utilizar en la cláusula From de una consulta.
• Vistas de objetos. Proporcionan una vista de tablas de objetos virtuales de datos almacenados en una tabla relacional normal. Permite acceder a ver los datos en un estilo orientado a objetos incluso si los datos están realmente almacenados en un formato relacional tradicional.
• Métodos. Se pueden escribir en PL/SQL, Java o C.
• Tipos de datos XML. Se pueden utilizar para almacenar e indexar documentos XML.

Oracle tiene dos lenguajes procedimentales principales, PL/SQL y Java. PL/SQL fue el lenguaje original de Oracle para los procedimientos almacenados y tiene una sintaxis similar al utilizado en el lenguaje Ada. Java se soporta mediante una máquina virtual Java dentro del motor de base de datos. Oracle proporciona un paquete para encapsular procedimientos, funciones y variables relacionadas en unidades únicas.

1. Disparadores

Oracle proporciona varios tipos de disparadores y varias opciones para el momento y forma en que se invocan. Los disparadores se pueden escribir en PL/SQL o java o como llamadas a C.

Para los disparadores que se ejecutan sobre instrucciones DML tales como insert, update o delete, Oracle soporta disparadores de filas (row) y disparadores de instrucciones (statement). Lo disparadores de filas se pueden ejecutar una vez por cada fila que se vea afectada (actualización o borrado, por ejemplo) por la operación DML. Un disparados de instrucciones, se ejecuta solamente una vez por instrucción. En cada caso, el disparador se puede definir tanto como un disparador "before" o "alter" dependiendo de si se va a invocar antes o después de que se lleva a cabo la operación DML.

Oracle también tiene disparadores que ejecutan otros eventos, tales como el inicio o finalización de la base de datos, mensajes de error del servidor, inicio o finalización de sesión de un usuario e instrucciones DDL tales como instrucciones create, alter o drop.

2. Almacenamiento e indexación

0. TableSpace (Espacio de tablas)

La base de datos Oracle se divide en unidades lógicas denominadas TABLESPACES. Cada TABLESPACE, consiste en una o más estructuras físicas denominadas DATAFILES.

Un TableSpace no es un fichero físico en disco, simplemente es el nombre que tiene un conjunto de propiedades de almacenamiento que se aplican a los objetos (tablas, secuencias…) que se crean en la base de datos bajo el tablespace indicado.

Un objeto en la base de datos debe estar almacenado obligatoriamente dentro de un tablespace.

Las propiedades que se asocian a un tablespace son:

• Localización de los ficheros de datos.
• Especificación de máximas cuotas de consumo de disco.
• Control de la disponibilidad de los datos (en línea o fuera de línea).
• Backup de los datos.

Cuando un objeto se crea dentro de un tablespace, este objeto adquiere todas las propiedades antes descritas del tablespace utilizado.

Si creamos por ejemplo una tabla llamada Artículo, esta se almacena dentro del tablespaceA, y que por lo tanto tendrá todas las propiedades del TableSpaceA que pueden ser:

• Sus ficheros de datos están en $ORACLE_HOME/datos/tablespaceA
• Los objetos no pueden ocupar más de 10Mb de espacio de la base de datos.
• En cualquier momento se puede poner fuera de línea todos los objetos de un cierto tablespace.
• Se puede hacer copia de seguridad solo de ciertos tablespace.

Si nos fijamos, se puede apreciar que es posible tener una tabla en un Tablespace, y los índices de esta tabla en otro tablespace. Esto es debido a que los índices no son más que objetos independientes dentro de la base de datos, como lo son las tablas. Y al ser objetos independientes, pueden ir en tablespaces independientes.

En las bases de datos Oracle encontramos el tablespace SYSTEM es un tablespace por defecto en todas las bases de datos Oracle. En él se almacenan todos los datos del sistema, el catálogo y todo el código fuente y compilado de procedimientos PL/SQL. También es posible utilizar el mismo tablespace para guardar datos del usuario. Este tablespace contiene además, el diccionario de datos, almacenamiento para disparadores y los procedimientos almacenados.

Por otra parte, también existe un tablespace Temporal. Este tablespace representa las propiedades que tendrán los objetos que la base de datos cree temporalmente para sus cálculos internos (normalmente para ordenaciones y agrupaciones).

El tablespace se puede crear con ciertas restricciones como por ejemplo un tablespace de solo lectura (Read Only), que por lo tanto, todos los objetos en el contenidos pueden recibir ordenes de consulta de datos, pero no de modificación de datos.

Un tablespace puede estar en línea o fuera de ella (OnLine o OffLine), esto es que el tablespace completo está a disposición de los usuarios o está desconectado para restringir el uso.

1. DataFile (Archivo de datos)

Un datafile es la representación física de un tablespace. Son los "Archivos de datos" donde se almacena la información físicamente.

Un datafile puede tener cualquier nombre y extensión (siempre dentro de las limitaciones del sistema operativo), y puede estar localizado en cualquier directorio del disco duro, aunque su localización típica suele ser $ORACLE_HOME/Database.

Un datafile tiene un tamaño predefinido en su creación (por ejemplo 100Mb) y este puede ser alterado en cualquier momento.

Cuando se cree un datafile, este ocupará tanto espacio en disco como hayamos indicado en su creación, aunque internamente esté vacío. Oracle hace esto para direccionar espacio continuo en disco y evitar así la fragmentación. Conforme se vayan creando objetos en el tablespace, se irá ocupando el espacio definido.

Un datafile está asociado a un solo tablespace y un tablespace está asociado a uno o varios datafiles.

Es decir, la relación lógica entre tablespaces y datafiles es de 1-N, maestro-detalle.

En la estructura manejada por Oracle un TableSpace está compuesto (físicamente) por uno o más. Estos datafiles son los ficheros físicos que soportan los objetos contenidos dentro del tablespace.

Aunque siempre se dice que los objetos están dentro del tablespace, en realidad las tablas están dentro del datafile, pero tienen propiedades asociadas al tablespace.

Cada uno de los datafiles utilizados está ocupado un tamaño en disco ( 50 mb los dos primeros y 25 mb el último) aunque en realidad solo contenga dos objetos y estos objetos no llenen el espacio asignado para los datafiles.

Los datafiles tienen un propiedad llamada AUTOEXTEND, que si está activa se encarga de que el datafile crezca automáticamente (según un tamaño indicado) cada vez que se necesite espacio y no exista.

Al igual que los tablespaces, los datafiles también pueden estar en línea o fuera de ella.

2. Segment (Segmento, trozo, sección)

El espacio en un espacio de tablas se divide en unidades denominadas segmentos, cada una de las cuales contiene los datos para una estructura de datos específica.

Hay cuatro tipos de segmentos:

• Segmento de datos.- cada tabla en un espacio de tablas tiene su propio segmento de datos donde se almacenan los datos de la tabla a menos que ésta se encuentre dividida; si esto ocurre, existe un segmento de datos por división ( regularmente esta división se da por partición de las tablas).
• Segmento de índices.- cada índice en un espacio de tablas posee su propio segmento de índices, excepto los índices divididos, los cuales mantienen un segmento de índice por división.
• Segmentos temporales.- son segmentos utilizados cuando una operación de ordenación necesita escribir datos al disco o cuando éstos se insertan en una taba temporal.
• Segmento de retroceso.- se trata de segmentos que contienen información para deshacer los cambios de las transacciones de forma de que pueda deshacer una copia no terminada. También juegan un papel muy importante en el modelo de control de concurrencia en Oracle y para la recuperación de la base de datos.