Administración de Base de Datos: octubre 2013

sábado, 26 de octubre de 2013

miércoles, 23 de octubre de 2013

Una colección de operaciones que forman una unidad lógica de trabajo en una BD realizada por una o más sentencias SQL estrechamente relacionadas.
Una unidad de la ejecución de un programa que lee y escribe datos a y desde la Base de Datos. Puede consistir en varias operaciones de acceso a la base de datos. Una Transacción está delimitada por instrucciones de inicio transacción y fin transacción (la transacción consiste en todas las operaciones que se ejecutan entre inicio transacción y fin transacción).

2. ¿Qué significa ACID? y defina cada una de las palabras que forman las siglas
Una unidad lógica de trabajo debe exhibir cuatro propiedades.

Atomicidad
Coherencia
Aislamiento
Durabilidad

Atomicity : Una Transacción (Tx) se ejecuta completamente ó de otra manera se eliminan los cambios parciales realizados.
Begin Transaction - Programa - End Transaction
Responsable: El método de recuperación, de no completar todas las operaciones, devuelve la BD a su estado anterior a empezar esa Tx (rollback).

Coherencia: Asegura que los datos queobservamos no cambian (por otros usuarios) hasta que acabemos la Transacción.
Después de terminar una Transacción la Base de datos no viola ninguna de sus reglas: valores obligatorios, claves únicas,etc.
Responsable: los programadores mediante la definición adecuada de la integridad referencial: check, triggers, primary key, foreign key,…

Aislamiento: Los efectos de una Tx no son visibles a otros usuarios mientras no se confirmen.
Una Transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de finalizar.
Más aun, si varias transacciones, se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado secuencialmente. Esto se conoce como seriabilidad debido a que su resultado es la capacidad de volver a cargar los datos iniciales y reproducir una serie de transacciones para finalizar con los datos en el mismo estado en que estaban después de realizar transacciones originales.d
Responsable: el método de concurrencia: mecanismos, reglas, protocolos

Durabilidad: Si el sistema falla no debe permitir que se pierdan las operaciones realizadas por Tx ya confirmadas.
Responsable: el método o gestor de recuperación.

      3. Qué significa Tx?

      Es una Transaccion Abreviacion

      4.¿Para que nos sirve el Rollback?
Operación que devuelve a la base de datos a algún estado previo. Los Rollbacks son importantes para la integridad de la base de datos, a causa de que significan que la base de datos puede ser restaurada a una copia limpia incluso después de que se han realizado operaciones erróneas. Son cruciales para la recuperación de crashes de un servidor de base de datos; realizando rollback(devuelto) cualquier transacción que estuviera activa en el tiempo del crash, la base de datos es restaurada a un estado consistente.
En SQL, ROLLBACK es un comando que causa que todos los cambios de datos desde la última sentencia BEGIN WORK, o START TRANSACTION sean descartados por el sistema de gestión de base de datos relacional (RDBMS), para que el estado de los datos sea "rolled back"(devuelto) a la forma en que estaba antes de que aquellos cambios tuvieran lugar.

     5.   Defina Integridad de datos
La creación de un modelo de las entidades del espacio del problema y las asociaciones entre ellas es sólo una parte del proceso de modelización de los datos. También se deben captar las reglas que utilizará el sistema de base de datos para asegurar que los datos físicos que realmente mantiene son, si no correctos, al menos plausibles. En otras palabras, se debe modelar la integridad de los datos.
No puede garantizarse que los datos sean fidedignos; por ejemplo, que un pedido sea de 16 unidades o de 8 unidades depende de el usuario introductor de datos, con lo que para el sistema las dos posibles entradas serían validas aunque claro esta solo es una de ellas. Pero sí se puede garantizar mediante el diseño de la base de datos que los datos son conformes a las restricciones de integridad definidas para ellos.

Integridad de transiciones

Las restricciones de integridad de transiciones definen los estados por los que una tupla puede pasar válidamente. Por ejemplo solo se permitirá que el saldo de un cliente cambie a de“Normal” a “Preferente” si el límite de crédito del cliente supera un determinado valor o si lleva al menos un año comerciando con la empresa. El requisito del límite de crédito seguramente estará controlado por un atributo de la relación Clientes, pero puede que el tiempo que lleva el cliente trabajando con la empresa no esté explícitamente guardado en ningún sitio. Será necesario calcular el valor de acuerdo con el registro más antiguo en el que figure el cliente en la relación Pedidos.

6. Defina concurrencia
CONTROL DE CONCURRENCIA EN BASES DE DATOS
El control de transacciones concurrentes en una base de datos brinda un eficiente desempeño del Sistema de Base de Datos, puesto que permite controlar la ejecución de transacciones que operan en paralelo, accesando a información compartida y, por lo tanto, interfiriendo potencialmente unas con otras.
El hecho de reservar un asiento en una avión mediante un sistema basado en aplicaciones web, cuando decenas de personas en el mundo pueden reservarlo también, nos da una idea de lo importante y crucial que es el control de concurrencia en un sistema de base de datos a mediana o gran escala.

Otro ejemplo en el que podemos observar la incidencia del control de concurrencia en el siguiente: en una Base de Datos bancaria podría ocurrir que se paguen dos cheques en forma simultánea sobre una cuenta que no tiene saldo suficiente para cubrirlos en su totalidad, esto es posible evitarlo si se tiene un control de concurrencia.

7.Defina Grado de consistencia

Consistencia es un término más amplio que el de integridad. Podría definirse como la coherencia entre todos los datos de la base de datos. Cuando se pierde la integridad también se pierde la consistencia. Pero la consistencia también puede perderse por razones de funcionamiento.

Una transacción finalizada (confirmada parcialmente) puede no confirmarse definitivamente (consistencia).

Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos.
Si se anula los cambios que ha efectuado son deshechos.

La ejecución de una transacción debe conducir a un estado de la base de datos consistente (que cumple todas las restricciones de integridad definidas).

Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos.
Si se anula los cambios que ha efectuado son deshechos.

Una transacción que termina con éxito se dice que está comprometida (commited), una transacción que haya sido comprometida llevará a la base de datos a un nuevo estado consistente que debe permanecer incluso si hay un fallo en el sistema. En cualquier momento una transacción sólo puede estar en uno de los siguientes estados.

Activa (Active): el estado inicial; la transacción permanece en este estado durante su ejecución.
Parcialmente comprometida (Uncommited): Después de ejecutarse la ultima transacción.
Fallida (Failed): tras descubrir que no se puede continuar la ejecución normal.
Abortada (Rolled Back): después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción.
Comprometida (Commited): tras completarse con éxito.

Aspectos relacionados al procesamiento de transacciones

Los siguientes son los aspectos más importantes relacionados con el procesamiento de transacciones:

Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas.
Consistencia de la base de datos interna. Los algoritmos de control de datos semántico tienen que satisfacer siempre las restricciones de integridad cuando una transacción pretende hacer un commit.
Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. Así también, se requieren protocolos para la recuperación local y para efectuar los compromisos (commit) globales.
Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.
Protocolos de control de réplicas. El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA).

8.Mencione aspectos relacionados al procesamiento de transacciones

Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas.
Consistencia de la base de datos interna. Los algoritmos de control de datos semántico tienen que satisfacer siempre las restricciones de integridad cuando una transacción pretende hacer un commit.
Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. Así también, se requieren protocolos para la recuperación local y para efectuar los compromisos (commit) globales.
Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.
Protocolos de control de réplicas. El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA).

9. Defina los estados de una transacción:

Activa (Active): el estado inicial; la transacción permanece en este estado durante su ejecución.

Parcialmente comprometida (Uncommited): Después de ejecutarse la ultima transacción.

Fallida (Failed): tras descubrir que no se puede continuar la ejecución normal.

Abortada (Rolled Back): después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción.

Comprometida (Commited): tras completarse con éxito.

El estándar ANSI/ISO SQL define cuatro niveles de aislamiento transaccional en función de tres eventos que son permitidos o no dependiendo del nivel de aislamiento. Estos eventos son:

Lectura sucia. Las sentencias SELECT son ejecutadas sin realizar bloqueos, pero podría usarse una versión anterior de un registro. Por lo tanto, las lecturas no son consistentes al usar este nivel de aislamiento.
Lectura norepetible. Una transacción vuelve a leer datos que previamente había leído y encuentra que han sido modificados o eliminados por una transacción cursada.
Lectura fantasma. Una transacción vuelve a ejecutar una consulta, devolviendo un conjuto de registros que satisfacen una condición de búsqueda y encuentra que otros registro que satisfacen la condición han sido insertadas por otra transacción cursada.

Actividad #21

Que es un índice?
Un índice (o KEY, o INDEX) es un grupo de datos que MySQL asocia con una o varias columnas de la tabla. En este grupo de datos aparece la relación entre el contenido y el número de fila donde está ubicado.
Los índices -como los índices de los libros- sirven para agilizar las consultas a las tablas, evitando que mysql tenga que revisar todos los datos disponibles para devolver el resultado.
Podemos crear el índice a la vez que creamos la tabla, usando la palabra INDEX seguida del nombre del índice a crear y columnas a indexar (que pueden ser varias):
INDEX nombre_indice (columna_indexada, columna_indexada2...)

La sintaxis es ligeramente distinta segun la clase de índice:

PRIMARY KEY (nombre_columna_1 [,nombre_columna2...])
UNIQUE INDEX nombre_indice (columna_indexada1 [,columna_indexada2 ...])
INDEX nombre_index (columna_indexada1 [,columna_indexada2...])

Podemos también añadirlos a una tabla después de creada:
ALTER TABLE nombre_tabla ADD INDEX nombre_indice (columna_indexada);
Si queremos eliminar un índice: ALTER TABLE tabla_nombre DROP INDEX nombre_indice¿para que sirven ?
LOs index permiten mayor rápidez en la ejecución de las consultas a la base de datos tipo SELECT ... WHERE
La regla básica es pues crear tus índices sobre aquellas columnas que vayas a usar con una cláusula WHERE, y no crearlos con aquellas columnas que vayan a ser objeto de un SELECT: SELECT texto from tabla_libros WHERE autor = Vazquez; En este ejemplo, la de autor es una columna buena candidata a un indice; la de texto, no.

Otra regla básica es que son mejores candidatas a indexar aquellas columnas que presentan muchos valores distintos, mientras que no son buenas candidatas las que tienen muchos valores idénticos, como por ejemplo sexo (masculino y femenino) porque cada consulta implicará siempre recorrer practicamente la mitad del indice.
La regla de la izquierda
Si necesitamos un select del tipo SELECT ... WHERE columna_1 = X AND columna_2 = Y y ya tenemos un INDEX con la columna_1, podemos crear un segundo indice con la columna 2, o mejor todavía, crear un único indice combinado con las columnas 1 y 2. Estos son los índices multicolumna, o compuestos.
No obstante si tienes indices multicolumna y los utilizas en las clausulas WHERE, debes incluir siempre de izquierda a derecha las columnas indexadas; o el indice NO se usará:
Supongamos un INDEX usuario (id, name, adress), y una cláusula SELECT ... WHERE NAME = x. Este Select no aprovechará el índice. Tampoco lo haría un SELECT ... WHERE ID =X AND ADRESS = Y. Cualquier consulta que incluya una columna parte del index sin incluir además las columnas a su izquierda, no usará el indice.

Por tanto en nuestro ejemplo solo sacarian provecho del indice las consultas SELECT ... WHERE ID = x, o WHERE ID = X AND NAME = y o WHERE ID = x AND NAME = y AND ADRESS = Z
Cuando un índice contiene mas de una columna, cada columna es leida por el orden que ocupa de izquierda a derecha, y a efectos prácticos, cada columna (por ese orden) es como si constituyera su propio índice. Esto significa que en el ejemplo anterior, no haría falta crear otro INDEX ID (id) ya que podríamos usar nuestro INDEX USUARIO simplemente con la cláusula SELECT ... WHERE ID = X;
Puedes ver si tu llamada sql usa o no los índices correctos anteponiendo a select la orden explain:
EXPLAIN SELECT * FROM mitable WHERE ....
Y para ser sinceros, usando explain para comprobar el uso de indices en distintos selects con indices multicolumna, he obtenido resultados poco consistentes con la 'regla de la izquierda' ya que en muchos casos parece que se usaban indices que teóricamente no debian estar disponibles ... posiblemente un caso de mala configuracion en mi tabla-test.

Tipos de indice

En algunas bases de datos existen diferencias entre KEY e INDEX. No así en MySQL donde son sinónimos.
Un índice que sí es especial es el llamado PRIMARY KEY. Se trata de un índice diseñado para consultas especialmente rápidas. Todos sus campos deben ser UNICOS y no admite NULL

Un indice UNIQUE es aquel que no permite almacenar dos valores iguales.

Los indices FULL TEXT permiten realizar búsquedas de palabras. Puedes crear indices FULLTEXT sobre columnas tipo CHAR, VARCHAR o TEXT.

Una vez creado puedes hacer búsquedas del tipo:
SELECT * FROM nombre_tabla WHERE MATCH(nombre_indice_fulltext) AGAINST('palabra_a_buscar');
Algunas limitaciones de los indices fulltext: solo busca por palabras completas. indice no encontrará indices. No se indexan las palabras de menos de cuatro letras. No se indexan columnas que contengan menos de tres filas, ni palabras que aparezcan en la mitad o mas de las filas. Las palabras separadas por guiones se cuentan como dos palabras.
Los indices ordinarios no tienen restricciones en cuanto a la existencia de valores idénticos o nulos. Una posibilidad interesante, si pensamos crear un índice sobre columnas CHAR y VARCHAR es la de limitar el campo a indexar. Por ejemplo, cada entrada en la columna puede ser de hasta 40 caracteres y nosotros indexar unicamente los primeros 10 de cada una. Para crear estos índices basta con indicar entre paréntesis el numero de caracteres a indexar despues del nombre de la columna:
ALTER TABLE libros ADD INDEX idx_autor(nombre(10), apellidos(10));

Desventajas de los indices

Los índices se actualizan cada vez que se modifica la columna o columnas que utiliza. Por ello no es aconsejable usar como indices columnas en las que serán frecuentes operaciones de escritura (INSERT, UPDATE, DELETE).

Tampoco tendría sentido crear indices sobre columnas cuando cualquier select sobre ellos va a devolver una gran cantidad de resultados; por ejemplo una columna booleana que admita los valores Y/N. En fin, tampoco es necesario usar indices en tablas demasiado pequeñas, ya que en estos casos no hay ganancia de rapidez frente a una consulta normal.
Finalmente, los índices ocupan espacio. A veces, incluso mas que la tabla de datos.

Creación de índices

Existen cuatro tipos de índices que podemos utilizar en MySQL; de clave primaria, únicos, de texto completo, y ordinarios. Cada uno de ellos será explicado a continuación.

Índices de clave primaria

Una clave primaria es un índice sobre uno o más campos donde cada valor es único y ninguno de los valores son NULL.

Para crear un índice de clave primaria tenemos básicamente dos opciones:

1. Crear el índice de clave primaria al momento de crear la tabla. En este caso se usa la opción PRIMARY KEY al final de la definición de los campos, con una lista de los campos que serán parte del índice.

CREATE TABLE nombreTabla(campo1 tipoDato,
 [campo2...,] PRIMARY KEY (campo1 [,campo2...]) );

Hacemos énfasis en que la palabra clave NOT NULL es obligatoria para un campo cuando éste vaya a formar parte de una clave primaria; como mencionamos anteriormente, las claves primarias no pueden contener valores nulos. Si intentamos crear una clave primaria sobre un campo nulo, MySQL nos marcará un error.

2. Crear una clave primaria en una tabla existente con el uso del comando ALTER TABLE:

ALTER TABLE nombreTabla ADD PRIMARY KEY(campo1 [,campo2...]);

Por ejemplo, suponiendo que ya tenemos en nuestro sistema una tabla que fue creada de la siguiente manera (sin clave primaria, y con el campo id aceptando valores NUL):

CREATE TABLE usuarios(id int, nombre varchar(50), apellidos varchar(70));

Podemos crear una clave primaria sobre el campo id con esta sentencia:

ALTER TABLE usuarios MODIFY id INT NOT NULL, ADD PRIMARY KEY(id);

Para observar los cambios que hemos hecho, podemos examinar las columnas de la tabla usuarios con una sentencia DESCRIBE:

mysql> DESCRIBE usuarios;
+-----------+-------------+------+-----+---------+-------+
| Field     | Type        | Null | Key | Default | Extra |
+-----------+-------------+------+-----+---------+-------+
| id        | int(11)     |      | PRI | 0       |       |
| nombre    | varchar(50) | YES  |     | NULL    |       |
| apellidos | varchar(70) | YES  |     | NULL    |       |
+-----------+-------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

El campo id no tiene un valor YES en la columna Null, lo que indica que este campo ya no podrá almacenar valores nulos. Se puede observar también que se tiene un valor PRI en la columna Key, lo que indica que este campo es una clave primaria.

Las claves primarias pueden constar de más de un campo. Hay algunas veces en las que un solo campo no puede identificar de manera única a un registro.

Índices ordinarios

Un índice que no es primario permite valores duplicados (a menos que los campos hayan sido especificados como UNIQUE).

Para crear un índice ordinario tenemos básicamente dos opciones:

1. Podemos crear un índice ordinario al mismo tiempo que creamos la tabla con el uso de la opción INDEX.

CREATE TABLE nombreTabla(campo1 tipoDato, campo2 tipoDato,..
  INDEX [nombreIndice] (campo1 [,campo2...]));

2. De igual manera, podemos crear el índice con el uso de la sentencia ALTER TABLE si es que la tabla ya existe.

ALTER TABLE nombreTabla ADD INDEX [nombreIndice] (campo1 [,campo2...]);

También es posible usar la sentencia CREATE INDEX para crear un índice en una tabla existente.

CREATE INDEX nombreIndice ON nombreTabla(campo1 [,campo2...]);

Ambas sentencias piden el nombre del índice, sin embargo con la sentencia CREATE INDEX el nombre es obligatorio.

Por ejemplo, para la siguiente definición de tabla:

CREATE TABLE usuarios(id int, nombre varchar(50), apellidos varchar(70));

Se puede crear un índice en la columna apellidos con una sentencia ALTER TABLE:

ALTER TABLE usuarios ADD INDEX idx_apellidos (apellidos);

O bien, con una sentencia CREATE INDEX:

CREATE INDEX idx_apellidos ON usuarios(apellidos);


Índices de texto completo 

Los 
índices de texto completo son del tipo FULLTEXT, se usan en tablas del 
tipo MyISAM, y pueden contener uno o más campos del tipo CHAR, VARCHAR y 
TEXT. Un índice de texto completo está diseñado para facilitar y optimizar la 
búsqueda de palabras clave en tablas que tienen grandes cantidades de 
información en campos de texto. 

Para crear un índice de texto completo 
tenemos básicamente dos opciones: 

1. Crear el índice al momento de crear 
la tabla. 
CREATE TABLE nombreTabla( campo1 TIPO, campo2 TIPO, 
FULLTEXT [nombreIndice] (campo1 [campo2,...]) );

2. Crear el índice una vez que ha sido creada la tabla. 
ALTER TABLE nombreTabla ADD FULTEXT [nombreIndice] (campo1 [,campo2,...]);

La siguiente sentencia también se puede usar para crear un índice 
cuando la tabla ya existe. 
CREATE FULLTEXT INDEX nombreIndice ON nombreTabla(campo1 [,campo2,...]);

UNICAMENTE para fines ilustrativos, consideremos la siguiente 
definición de tabla: 
CREATE TABLE usuarios(id int, nombre varchar(50), apellidos varchar(70));

Podríamos crear un índice FULLTEXT en la columna nombre, en la columna 
apellidos, o bien, un índice que ocupe ambos campos. A continuación se muestran 
los tres casos. CREATE FULLTEXT INDEX idx_nombre ON usuarios(nombre);
CREATE FULLTEXT INDEX idx_apellidos ON usuarios(apellidos);
CREATE FULLTEXT INDEX idx_nombre_apellidos ON usuarios(nombre,apellidos);

- Nota: Cuando se tienen grandes cantidades de datos, es 
mucho más rápido cargar los datos en una tabla que no tiene índices de texto 
completo y después crear los índices necesarios, ya que la carga de datos en una 
tabla que ya tiene índices de este tipo es un proceso lento. 

Índices únicos 

Los índices únicos son básicamente 
como los índices ordinarios, excepto que los valores duplicados no son 
permitidos. 

Para crear un índice UNIQUE se tienen básicamente dos 
opciones: 

1. Crear un índice único cuando la tabla es creada con el uso 
de la opción UNIQUE. 
CREATE TABLE nombreTabla(campo1 tipoDato, campo2 tipoDato,..
  UNIQUE [nombreIndice] (campo1 [,campo2...]));

2. O bien, si la tabla ya existe, se usa la sentencia ALTER TABLE. ALTER TABLE nombreTabla ADD UNIQUE [nombreIndice] (campo1, campo2) ...

De igual manera, también es posible usar la sentencia CREATE INDEX para 
crear un índice único en una tabla existente. CREATE UNIQUE INDEX nombreIndice ON nombreTabla(campo1 [,campo2...]);

UNICAMENTE para fines ilustrativos, consideremos de nuevo la 
siguiente definición de tabla: 
CREATE TABLE usuarios(id int, nombre varchar(50), apellidos varchar(70));

Podríamos crear un índice UNIQUE en la columna nombre, y un índice UNIQUE 
en la columna apellidos. ALTER TABLE usuarios ADD UNIQUE idx_nombre (nombre);
CREATE UNIQUE INDEX idx_apellidos ON usuarios(apellidos);

En el primer caso hacemos uso del comando ALTER TABLE, y en el segundo 
caso creamos el índice con la sentencia CREATE INDEX. 

Índices compuestos 

Los índices compuestos son 
simplemente aquellos que están basados en múltiples columnas. MySQL únicamente 
usa un índice por tabla cuando está procesando una consulta. Esto significa que 
si tenemos varias columnas que frecuentemente aparecen juntas en una cláusula 
WHERE, tenemos la oportunidad de acelerar estas consultas al crear un índice 
compuesto. 

Si una tabla tiene un índice formado por múltiples columnas, 
cualquier prefijo más a la izquierda puede ser usado por el optimizador de 
consultas de MySQL para encontrar las filas. Por ejemplo, si tenemos un índice 
compuesto por tres columnas (col1, col2, col3), tendríamos capacidades de 
búsqueda en (col1), (col1, col2) y (col1, col2, col3). 

MySQL no puede 
usar un índice parcial si las columnas no forman un prefijo más a la izquierda 
del índice. Supongamos que tenemos unas sentencias SELECT como estas: 
mysql> SELECT * FROM algunaTabla WHERE col1=valor1;
mysql> SELECT * FROM algunaTabla WHERE col2=valor2;
mysql> SELECT * FROM algunaTabla WHERE col2=valor2 AND col3=valor3;

Si el índice existe en (col1, col2, col3), sólo la primera de estas 
consultas usará el índice. La segunda y la tercera involucran a las columnas en 
el índice, pero (col2) y (col2, col3) no son los prefijos más a la izquierda de 
(col1, col2, col3). 

Este es otro ejemplo. Consideremos la siguiente 
definición de una tabla: CREATE TABLE usuarios(id int, nombre varchar(50), apellidos varchar(70));

Si frecuentemente hacemos consultas en la tabla usuarios basadas en el 
nombre como en los apellidos, podemos beneficiarnos de un índice compuesto en 
las columnas nombre y apellidos. ALTER TABLE usuarios ADD INDEX idx_nombre(nombre, apellidos);

Debido a la forma en que MySQL construye los índices compuestos, 
éste puede usar el índice idx_nombre para resolver consultas basadas sólo en el 
nombre, o en el nombre y los apellidos, sin embargo, no usará el índice en una 
consulta que haga referencia únicamente a la columna apellidos. 

Por 
ejemplo, de las siguientes tres consultas, sólo las dos primeras harían uso de 
nuestro índice idx_nombre. 
SELECT * FROM usuarios WHERE nombre='Eduardo';
SELECT * FROM usuarios WHERE nombre='Eduardo' AND apellidos='Zarate M';
SELECT * FROM usuarios WHERE apellidos='Zarate M';

La idea es que los índices compuestos pueden usarse frecuentemente 
para acelerar algunas consultas complejas, pero necesitamos entender sus 
limitaciones y debemos ejecutar algún tipo de prueba en vez de asumir que estos 
índices siempre nos van a ayudar. 

Índices de parte de 
campos 

En las columnas CHAR y VARCHAR se nos permite crear un 
índice que no use el campo por completo. Retomemos el ejemplo anterior de la 
tabla usuarios. A pesar de que el nombre de una persona puede ser de hasta 50 
caracteres, es muy común que los nombres de las personas sean diferentes en los 
primeros 10 caracteres. Al usar un índice de 10 caracteres en lugar de 50, el 
índice será más pequeño, y permitirá que las consultas INSERT y UPDATE sean más 
rápidas, a la vez que no se afecta la velocidad de las consultas SELECT. 


Para crear un índice como parte de un campo, sólo se tiene que 
especificar el tamaño entre paréntesis después del nombre de la columna. Por 
ejemplo, nuestro índice idx_nombre pudo haber sido creado también de la 
siguiente manera: 
ALTER TABLE usuarios ADD INDEX idx_nombre(nombre(10), apellidos(20));






Eliminar o cambiar un índice 


Algunas veces tendremos la necesidad de cambiar o eliminar un índice. 
Cuando hagamos algún cambio en el índice, necesitamos eliminar primero el índice 
y entonces reconstruirlo con la nueva definición. 

Para eliminar un 
índice de clave primaria podemos usar la siguiente sintaxis: 
ALTER TABLE nombreTabla DROP PRIMARY KEY;

Para eliminar un índice ordinario, único, o de texto completo, necesitamos 
especificar el nombre del índice y usar esta sintaxis: ALTER TABLE nombreTabla DROP INDEX nombreIndice;

También es válida esta otra sintaxis: DROP INDEX nombreIndice ON nombreTabla;

Si no estamos seguros de cuál es el nombre del índice que deseamos 
eliminar, podemos hacer uso de la sentencia SHOW KEYS: SHOW KEYS FROM nombreTabla;

Este es un ejemplo. CREATE TABLE usuarios
(
   id INT NOT,
   nombre VARCHAR(50) NOT NULL,
   apellidos VARCHAR(70) NOT NULL,
   PRIMARY KEY (id),
   INDEX (nombre, apellidos)
);

Veamos los índices que existen en esta tabla: mysql> SHOW KEYS FROM usuarios;
+----------+------------+----------+--------------+-------------+ 
| Table    | Non_unique | Key_name | Seq_in_index | Column_name |  
+----------+------------+----------+--------------+-------------+  .
| usuarios |          0 | PRIMARY  |            1 | id          |  .
| usuarios |          1 | nombre   |            1 | nombre      |  .
| usuarios |          1 | nombre   |            2 | apellidos   | 
+----------+------------+----------+--------------+-------------+ 

3 rows in set (0.00 sec)

La tercera columna es la que nos proporciona los nombres de los índices. 
Podemos observar que al no especificar un nombre al índice ordinario en (nombre, 
apellidos), se le ha asignado el nombre de la primera columna que forma el 
índice. 

A continuación vamos a eliminar los dos índices que existen en 
esta tabla: mysql> ALTER TABLE usuarios DROP PRIMARY KEY;
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> ALTER TABLE usuarios DROP INDEX nombre;
Query OK, 0 rows affected (0.00 sec)
Records: 0  Duplicates: 0  Warnings: 0

Por último, podemos verificar que estos índices ya no existen: mysql> SHOW KEYS FROM usuarios;
Empty set (0.00 sec)

Usando índices efectivamente 


Dado que los índices hacen que las consultas se ejecuten más rápido, 
podemos estar incitados a indexar todas las columnas de nuestras tablas. Sin 
embargo, lo que tenemos que saber es que el usar índices tiene un precio. Cada 
vez que hacemos un INSERT, UPDATE, REPLACE, o DELETE sobre una tabla, MySQL 
tiene que actualizar cualquier índice en la tabla para reflejar los cambios en 
los datos. 

¿Así que, cómo decidimos usar índices o no?. La respuesta es 
"depende". De manera simple, depende que tipo de consultas ejecutamos y que tan 
frecuentemente lo hacemos, aunque realmente depende de muchas otras cosas. 


La razón para tener un índice en una columna es para permitirle a MySQL 
que ejecute las búsquedas tan rápido como sea posible (y evitar los escaneos 
completos de tablas). Podemos pensar que un índice contiene una entrada por cada 
valor único en la columna. En el índice, MySQL debe contar cualquier valor 
duplicado. Estos valores duplicados decrementan la eficiencia y la utilidad del 
índice. 

Así que antes de indexar una columna, debemos considerar que 
porcentaje de entradas en la tabla son duplicadas. Si el porcentaje es demasiado 
alto, seguramente no veremos alguna mejora con el uso de un índice. 

Otra 
cosa a considerar es qué tan frecuentemente los índices serán usados. MySQL 
puede usar un índice para una columna en particular únicamente si dicha columna 
aparece en la cláusula WHERE en una consulta. 

Si muy rara vez usamos una 
columna en una cláusula WHERE, seguramente no tiene mucha sentido indexar dicha 
columna. De esta manera, probablemente sea más eficiente sufrir el escaneo 
completo de la tabla las raras ocasiones en que se use esta columna en una 
consulta, que estar actualizando el índice cada vez que cambien los datos de la 
tabla. 

Ante la duda, no tenemos otra alternativa que probar. Siempre 
podemos ejecutar algunas pruebas sobre los datos de nuestras tablas con y sin 
índices para ver como obtenemos los resultados más rápidamente. Lo único a 
considerar es que las pruebas sean lo más realistas posibles.

jueves, 17 de octubre de 2013

Actividad #18 y #19

Equipo

Valeria Sifuentes Reyes

Ismael Guillen Fernandez

martes, 15 de octubre de 2013

Actividad #16

Creacion De Bitacoras

Que es una Bitacora en una Base de Datos

Es una herramienta que permite registrar,analizar,detectar y notificar eventod que
Suceden en cualquier sistema de informacion utilizado en las organizaciones.
La estructura más ampliamente usada para grabar las modificaciones de la base de datos es la Bitácora.
Cada registro de la bitácora escribe una única escritura de base de datos y tiene lo siguiente :

1.Nombre de la transacción : Nombre de la transacción que realizó la operación de escritura.

2.Nombre del dato : El nombre único del dato escrito.
3.Valor antiguo : El valor del dato antes de la escritura.
4.Valor nuevo : El valor que tendrá el dato después de la escritura.

Funciones

recuperar informacion ante incidentes de seguridad
deteccion de comportamientos inusuales
informacion para resolver problemas
evidencia legal
Es de gran ayuda en las tareas de computo forense
tipo de bitacoras

Bitacora de Transacciones

Cada base de datos en SQL Server tiene un Transaction Log asociado con ella. El transaction log (en español bitácora de transacciones) es un componente escencial de SQL Server, el cual la utiliza para registrar un historial de cada modificación que sufre la base de datos como resultado de las transacciones. Dicho registro es de vital importancia para mantener la integridad de los datos y poder deshacer los cambios resultantes de transacciones incompletas ya sea por error del sistema o por la cancelación por parte de los usuarios.

Tipos de bitacoras

El sistema guarda diferentes tipos de
registros en la bit¡cora, dependiendo del
evento ocurrido en la BD.

Por ejemplo:
Un registro de actualizacion describe una
escritura unica en la BD y tiene los campos:
ID_Transaccion.
ID_elemento_datos.
Valor anterior.Valor nuevo.

Tipos de Bitacoras
BITACORAS DE USUSARIOS:
Usuario, password, depto, sistema, archivos, terminal, permisos.
BITACORAS DE ARCHIVOS:
Password, dueño, sistema que lo usan, dominios, formatos, ubicación, usuarios.
CATALOGO DE SISTEMAS.
Dpto, sistema, archivos, terminal, programas, responsable.
BITACORAS DE ERRORES.
Tipo, programa, desc. pcron, hora, lugar, usuario, fecha, archivo, sistema.
BITACORAS DE USO.
Fecha, usuario, sistema, permiso, terminal, registro, tipo de acceso, imagen vieja, imagen nueva.
MANUALES DEL SISTEMA.
Sistema, depto, archivos, procedimiento de uso, nivel de sistematización y automatización

Como crear una bitacora en mysql

Si estás llamando al interprete de comandos mysql.exe, un par de consejos:
- Si usas la forma abreviada -u o -p, no debes dejar espacio entre el parámetro y el texto:

Código:

mysql -uroot -pclaveroot

- -tee requiere el formato -tee=archivo. Te estás olvidando una parte.

Código:

mysql -uroot -pclaveroot -tee=x:prueba.txt

Un detalle más: Normalmente el root tiene password. Si no se lo pusieron es un error muy grave. Tiene una falla de seguridad catastrófica.

[digital@pcproal digital]$mysqldump--opt-ucarlos-pprueba > prueba.bak

Para restaurar un respaldo completo de una base
[digital@pcproal digital]$ mysql -u carlos -p prueba<prueba.bak

BITACORAS

¿Que es?
Es un gestor de información personal que te permitirá organizar tus colecciones de libros, discos, vídeos, software y direcciones de Internet.
MODOS DE UTILIZACION:
BITACORAS DE USUSARIOS:
Usuario, password, depto, sistema, archivos, terminal, permisos.
BITACORAS DE ARCHIVOS:
Password, dueño, sistema que lo usan, dominios, formatos, ubicación, usuarios.
CATALOGO DE SISTEMAS.
Dpto, sistema, archivos, terminal, programas, responsable.
BITACORAS DE ERRORES.
Tipo, programa, desc. pcron, hora, lugar, usuario, fecha, archivo, sistema.
BITACORAS DE USO.
Fecha, usuario, sistema, permiso, terminal, registro, tipo de acceso, imagen vieja, imagen nueva.
MANUALES DEL SISTEMA.
Sistema, depto, archivos, procedimiento de uso, nivel de sistematización y automatización
Bitácoras
Para un buen mantenimiento de las bitácoras de una base de datos es necesario tener presente la organización de la empresa; es decir que tantas transacciones se reportan diariamente, y que también respaldado se quieren tener esas transacciones (en la mayoría de las empresas estas bitácoras son primordiales en caso de una posible caída de la base de datos).
A la hora de crear una base de datos se debe hacer un estudio previo del manejo de la empresa y la cantidad de recursos disponibles para la construcción de la base, con estos datos ya cuantificados es posible determinar el número de bitácoras, así como el tamaño necesario para cada una de ellas.
En caso de que la base ya haya sido creada y lo que se necesite sea darle mantenimiento a las bitácoras, es muy importante también el estudio preciso del número promedio de transacciones diarias de la empresa, para así asegurar que el tamaño y el numero de bitácoras a adicionar sea el más preciso, y brinde el mejor funcionamiento de la base de datos.

Creando una base de datos Oracle básica

Oracle tiene buenas herramientas para ayudarte a crear bases de datos (como Enterprise Manager o DBCA), pero si quieres crear una base de datos a mano o usando scripts y quieres sólo la base de datos sin componentes extra, entonces podrías querer revisar este método. Es casi el mismo para bases de datos Oracle 10g y 11g, y si eres nuevo en Oracle es una buena manera de entender cómo funciona.

Vamos a crear una base de datos 10g para este ejemplo, y el primer paso es crear un Pfile para esta base de datos y colocarlo en $ORACLE_HOME/dbs; tienes que nombrarlo initDBNAME.ora donde DBNAME es el nombre de tu base de datos. Si necesitas ejemplos de Pfile puedes ver este ejemplo para 10g y también este ejemplo para 11g.

A continuación necesitamos crear algunos directorios para la base de datos (para 11g solo $ORACLE_BASE/oradata/example):

oracle@myserver:~$ mkdir -p $ORACLE_HOME/admin/example/bdump
oracle@myserver:~$ mkdir $ORACLE_HOME/admin/example/cdump
oracle@myserver:~$ mkdir $ORACLE_HOME/admin/example/udump
oracle@myserver:~$ mkdir $ORACLE_HOME/oradata/example

Antes de crear la base de datos también necesitamos configurar variables de entorno:

oracle@myserver:~$ export ORACLE_SID=example
oracle@myserver:~$ set | grep ORA
ORACLE_BASE=/opt/oracle/app/oracle
ORACLE_HOME=/opt/oracle/app/oracle/product/10.2.0/db_1
ORACLE_SID=example

Ahora iniciamos la nueva base de datos en modo nomount y la creamos:

oracle@myserver:~$ sqlplus '/ as sysdba'

SQL*Plus: Release 10.2.0.5.0 - Production on Tue Sep 13 15:11:12 2011

Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.

Connected to an idle instance.

SQL> startup nomount
ORACLE instance started.

Total System Global Area  167772160 bytes
Fixed Size                  1272600 bytes
Variable Size              88081640 bytes
Database Buffers           75497472 bytes
Redo Buffers                2920448 bytes
SQL> CREATE  DATABASE example
    MAXDATAFILES  500
    MAXINSTANCES  1
    MAXLOGFILES   10
    MAXLOGMEMBERS 4
    DATAFILE
        '?/oradata/example/system01.dbf'          size 512M
    DEFAULT TEMPORARY TABLESPACE TEMP
         TEMPFILE '?/oradata/example/temp01.dbf'  size 256M
         EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M
    LOGFILE
        GROUP 1 (
        '?/oradata/example/redo01a.rdo',
        '?/oradata/example/redo01b.rdo')          size 64M,
        GROUP 2 (
        '?/oradata/example/redo02a.rdo',
        '?/oradata/example/redo02b.rdo')          size 64M,
        GROUP 3 (
        '?/oradata/example/redo03a.rdo',
        '?/oradata/example/redo03b.rdo')          size 64M
    SYSAUX
        DATAFILE '?/oradata/example/sysaux01.dbf' size 512M
    UNDO TABLESPACE UNDO
        DATAFILE '?/oradata/example/undo01.dbf'   size 512M
/

Database created.

Por supuesto tienes que configurar nombres de archivo que concuerden con el directorio oradata creado, modificar tamaños de archivos si son demasiado pequeños, colocar archivos en lugares adecuados como redo logs en diferentes sistemas de archivos, y finalmente modificar o agregar parámetros de acuerdo a tus necesidades específicas.

A continuación creamos el tablespace USERS y el catálogo de la base de datos:

SQL> CREATE TABLESPACE USERS LOGGING DATAFILE
'?/oradata/example/users.dbf' SIZE 256M REUSE AUTOEXTEND ON NEXT 16M MAXSIZE 512M
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

Tablespace created.

SQL> @?/rdbms/admin/catalog

...

Grant succeeded.


PL/SQL procedure successfully completed.

SQL> @?/rdbms/admin/catproc

...

1 row created.


PL/SQL procedure successfully completed.

SQL> @?/rdbms/admin/catexp

...

0 rows created.


Commit complete.

SQL> @?/rdbms/admin/catblock

...

Synonym created.


Grant succeeded.

SQL> connect system/manager
Connected.
SQL> @?/sqlplus/admin/pupbld

...

DROP PUBLIC SYNONYM PRODUCT_USER_PROFILE
                    *
ERROR at line 1:
ORA-01432: public synonym to be dropped does not exist



Synonym created.

SQL> @?/rdbms/admin/catdbsyn

...

Synonym created.


Synonym created.

SQL> exit;
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
oracle@myserver:~$ sqlplus '/ as sysdba'

SQL*Plus: Release 10.2.0.5.0 - Production on Tue Sep 13 15:39:32 2011

Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> @?/rdbms/admin/utlrp.sql

..

DOC>#

OBJECTS WITH ERRORS
-------------------
                  0

DOC> The following query reports the number of errors caught during
DOC> recompilation. If this number is non-zero, please query the error
DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors
DOC> are due to misconfiguration or resource constraints that must be
DOC> fixed before objects can compile successfully.
DOC>#

ERRORS DURING RECOMPILATION
---------------------------
                          0


PL/SQL procedure successfully completed.

Tu nueva base de datos está casi completa, sólo tienes que crear un SPfile y revisar los componentes instalados:

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  167772160 bytes
Fixed Size                  1272600 bytes
Variable Size              88081640 bytes
Database Buffers           75497472 bytes
Redo Buffers                2920448 bytes
Database mounted.
Database opened.
SQL> create spfile from pfile;

File created.

SQL> startup force;
ORACLE instance started.

Total System Global Area  167772160 bytes
Fixed Size                  1272600 bytes
Variable Size              88081640 bytes
Database Buffers           75497472 bytes
Redo Buffers                2920448 bytes
Database mounted.
Database opened.
SQL> set pagesize 9999
SQL> col comp_id for a10
SQL> col comp_name for a40
SQL> col version for a15
SQL> column status format a10
SQL> select comp_id, comp_name, version, status from dba_registry;

COMP_ID    COMP_NAME                                VERSION         STATUS
---------- ---------------------------------------- --------------- ----------
CATALOG    Oracle Database Catalog Views            10.2.0.5.0      VALID
CATPROC    Oracle Database Packages and Types       10.2.0.5.0      VALID

Y si lo prefieres, puedes configurar PERFSTATS de esta manera:

SQL> CREATE TABLESPACE PERFSTAT DATAFILE
'?/oradata/example/perfstat.dbf' SIZE 192M AUTOEXTEND ON NEXT 16M MAXSIZE 512M
NOLOGGING ONLINE PERMANENT EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K SEGMENT SPACE MANAGEMENT AUTO FLASHBACK ON;

Tablespace created.

SQL> define default_tablespace='PERFSTAT'
SQL> define temporary_tablespace='TEMP'
SQL> define perfstat_password='perfstat'
SQL> @?/rdbms/admin/spcreate.sql

...

No errors.

NOTE:
SPCPKG complete. Please check spcpkg.lis for any errors.

Eso es todo! Tienes una mínima base de datos nueva lista para usar; sólo no olvides agregar tu base de datos al archivo oratab, crear un listener para esta base de datos, cambiar los passwords por default y desactivar cuentas por default, y hacer cualquier cosa administrativa como estas requerida.

miércoles, 9 de octubre de 2013

Comparación particion de disvo y archivos de sistema

PARTICIONES

Cuando hablamos de particiones estamos hablando de dividir un disco duro en varias partes, cada una de las cuales se comportará como si fuera un disco duro independiente de los demás.
L os sistemas operativos no trabajan con unidades físicas directamente, sino con unidades lógicas que reciben el nombre de particiones. Por regla general al instalar un nuevo sistema operativo una sola partición ocupará toda la superficie del disco. Sin embargo, es muy interesante tener más de una partición para, por ejemplo, hacer una copia de seguridad de nuestros datos. Para ello, el sistema operativo simula un segundo disco aunque físicamente solo dispongamos de uno.

Las particiones pueden ser de dos tipos:

1. Partición primaria. Es la partición desde la que puede arrancar el sistema operativo. Para que esto sea posible, esta partición debe estar marcada como partición activa.

2. Partición extendida. Es la p artición que no puede contener los archivos necesarios para arrancar el sistema y que puede ser subdividida en unidades lógicas. Este tipo de particiones sirven para guardar ficheros. En esta partición extendida se crean las unidades lógicas.

SISTEMA DE ARCHIVOS

Un sistema de archivos es una estructura que permite tanto el almacenamiento, organización jerárquica, manipulación, navegación, acceso y consulta de datos de en una partición, como su modificación y recuperación. Para que una partición pueda ser utilizada, es necesario asignarle previamente un sistema de archivos. Esta operación se denomina dar formato a una partición .Normalmente, cada sistema de archivos ha sido diseñado para obtener el mejor rendimiento de un sistema operativo concreto, pero sin embargo, es muy normal que un sistema operativo reconozca varios tipos de sistemas de archivos.

Los sistemas de archivos más comunes:

FAT (File Allocation Table, tabla de asignación de archivos)

Este sistema de archivos se basa en un índice en el que se hace referencia a los datos que hay en un disco duro, y a la situación de los mismos.

Este sistema es compatible con la mayoría de sistemas operativos, pero también posee una serie de limitaciones como por ejemplo que el tamaño máximo de la partición es de 2 GB, que solo admite nombres de archivos cortos, una elevada fragmentación de los archivos debido a un tamaño del cluster demasiado grande, etc. Es el sistema de archivos típico de DOS.

VFAT (Virtual FAT)

Este sistema de archivos es una mejora del anterior con el que se logra ampliar el límite de los nombres de archivos y directorios de 8 a 255 caracteres entre el nombre y la extensión.

FAT32 (FAT de 32 bits)

Nos permite trabajar con particiones mayores de 2 GB. Además, el tamaño del cluster es mucho menor, con lo que la fragmentación de los archivos disminuye, el sistema no se ralentiza tanto y no se desperdicia tanto espacio como ocurría en las particiones FAT.

Este sistema de archivos lo podemos encontrar en Windows95 (no en sus primeras versiones) pero sobre todo a partir de Windows 98, por lo que hay que tener en cuenta que versiones anteriores de Windows y MS-DOS no pueden acceder a los datos almacenados en una partición FAT32.

NTFS (New Technology File System, sistema de archivos de nueva tecnología)

Este es el sistema de archivos nativo de Windows NT, que además de ser muy eficiente y robusto, permite controlar el acceso a archivos o directorios utilizando todas las características de seguridad y protección de archivos de Windows NT. NTFS es recomendable para particiones grandes, ya que las estructuras del sistema consumen gran cantidad de espacio. Además, podemos definir el tamaño del cluster a partir de 512 bytes (tamaño de un sector) de forma independiente al tamaño de la partición. De esta manera se evita la fragmentación y hay un menor desaprovechamiento del disco, lo que hace de este sistema de archivos el sistema ideal para las particiones de gran tamaño requeridas en ordenadores de gran capacidad y servidores.

Es el sistema de archivos empleado en Windows NT, Windows 2000, Windows XP y Windows 2003.

HPFS (High Performance File System, sistema de archivos de alto rendimiento)

Es el sistema de archivos propio de OS/2. Utiliza una estructura muy eficiente para organizar los datos en las particiones, ya que no utiliza clusters, sino que directamente los organiza en sectores del disco (que equivalen a un cluster de 512 bytes).

EXT2 (second extended filesystem o "segundo sistema de archivos extendido")

Es un sistema de archivos mucho más avanzado que el FAT de windows. Este sistema de archivos tiene soporte de corrección y detección de errores, compresión de archivos, menor fragmentación de los archivos y una velocidad de acceso a los datos muy superiores, aunque para ello tiene que utilizar más memoria.El ext2 tiene una unidad similar al cluster, llamada bloque, y que es, por lo general de 1K, independiente del tamaño de la partición y con un tamaño que puede ser modificado por el usuario, lo cual asegura un aprovechamiento eficaz del espacio libre con archivos pequeños.

Ext3 ( third extended filesystem o "tercer sistema de archivos extendido") Es una versión mejorada de ext2 en la que se incorpora un registro por diario (en inglés journaling), que se utiliza para mantener la consistencia en el sistema.

EXT3 posee una serie de mejoras con respecto a EXT2 como por ejemplo:

· Permite migrar del sistema de archivos EXT2 sin necesidad de reformatear el disco.

· Puede ser montado y usado como un sistema de archivos EXT2.

· • Proporciona una integridad superior de los datos si se produce un cierre incorrecto del sistema.

· • El registro por diario permite optimizar el movimiento de los cabezales de los discos duros aumentando la velocidad de escritura/lectura de los datos.