Modos de operación de un sgbd

ROLLBACK
Señala el final sin éxito de una transacción, elimina todas las modificaciones de datos realizadas desde el inicio de la transacción y también libera los recursos que retiene la transacción. Su sintaxis es la siguiente:
ROLLBACK [WORK] [TO SAVEPOINT nombrePuntoRestauración | FORCE 'texto'];
COMMIT
Una sentencia COMMIT marca el final de una transacción correcta, implícita o definida por el usuario. COMMIT hace que todas las modificaciones efectuadas sobre los datos desde el inicio de la transacción sean parte permanente de la base de datos, y además, libera los recursos mantenidos por la conexión. Su sintaxis es la siguiente:
COMMIT COMMENT 'mensaje' | FORCE 'texto']

RECOVERY (RESTORE)

Restaura la tabla o tablas de una copia de seguridad que se hizo con BACKUP TABLE. Las tablas existentes no se sobreescriben; si trata restaurar una tabla existente, obtiene un error. Pero como BACKUP TABLE, RESTORE TABLE actualmente funciona sólo para tablas MyISAM. El directorio debe especificarse como una ruta completa.

 
ROLLBACK

En MYSQL

mysql> CREATE TABLE innotest (campo INT NOT NULL PRIMARY KEY) TYPE = InnoDB;

Query OK, 0 rows affected (0.10 sec)

mysql> INSERT INTO innotest VALUES(1);

Query OK, 1 row affected (0.08 sec)

mysql> INSERT INTO innotest VALUES(2);

Query OK, 1 row affected (0.01 sec)

mysql> INSERT INTO innotest VALUES(3);

Query OK, 1 row affected (0.04 sec)

mysql> SELECT * FROM innotest;

+-------+

| campo |

+-------+

|     1 |

|     2 |

|     3 |

+-------+

3 rows in set (0.00 sec)

De acuerdo, nada espectacular. Ahora veamos como usar transacciones.

mysql> BEGIN;

Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO innotest VALUES(4);

Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM innotest;

+-------+

| campo |

+-------+

|     1 |

|     2 |

|     3 |

|     4 |

+-------+

4 rows in set (0.00 sec)

Si en este momento ejecutamos un ROLLBACK, la transacción no será completada, y los cambios realizados sobre la tabla no tendrán efecto.

mysql> ROLLBACK;

Query OK, 0 rows affected (0.06 sec)

mysql> SELECT * FROM innotest;

+-------+

| campo |

+-------+

|     1 |

|     2 |

|     3 |

+-------+

En Oracle

Para deshacer los cambios realizados en una transacción. Rollback restaura el estado de la base de datos para el último punto de confirmación.

Ejemplo:
delete from emp;

rollback;          /* undo the changes */

COMMIT

En mysql

START TRANSACTION;
SELECT @A := presupuesto
FROM departamentos_externos
WHERE codigo =11;
INSERT INTO departamentos( codigo, nombre, presupuesto )
VALUES ( 11, ‘Department test’, @A );
COMMIT;

En Oracle

Para que los cambios realizados en un número de transacción permanente la sentencia COMMIT.

La sintaxis de la sentencia COMMIT es:

COMMIT  [WORK]  [COMMENT ‘your comment’];

RECOVERY (RESTORE)

En mysql

RESTORE TABLE tbl_name [, tbl_name] ... FROM '/path/to/backup/directory'

En Oracle

RECOVER [AUTOMATIC] [FROM 'localizacion'] [BD]

   [UNTIL CANCEL]

   [UNTIL TIME fecha]

   [UNTIL CHANGE entero]

[USING BACKUP CONTROLFILE]

BIBLIOGRAFIA

http://www.oracle-dba-online.com/sql/commit_rollback_savepoint.htm

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

http://www.infor.uva.es/~jvegas/cursos/bd/oraback/oraback.html

http://luauf.com/2008/10/13/commit-de-transacciones-en-mysql/

http://www.programacion.com/articulo/transacciones_en_mysql_242

Exposición

Actividad #17, #18, #19 & #20

Actividad # 17

Planear y definir la estructura lógica de la base de datos de acuerdo a los recursos disponibles –memoria y disco. (Utilice el  problema de la Veterinaria)  incluya toda la secuencia, (esquema conceptual, esquema lógico y esquema físico), calcular el numero de bytes por registro (de acuerdo al tipo de datos) y cuantos bytes aproximados se requiere para almacenar los datos de  100 pacientes con un promedio de  6 consultas al año) deben contener todos los campos  incluidos en la hoja clínica en el diseño.

Nombre Tabla	Tamaño (Bytes)	100 Registros(KB)	Promedio 6 consultas por año (bytes)
Datos mascota	120	1.2	720
Datos medio ambiente	50	5.0	300
Historial medica	30	3.0	180
Motivo	40	4.0	240
Propietario	70	7.0	420
Total	310	20.2	1820

Actividad  #18

Implementar el esquema de base de datos de la clínica veterinaria (incluir todas las tablas y  datos de 5 pacientes con 2  registros de   visita a la clínica cada  uno) 

Actividad #19

Crear espacios de trabajo para tres usuarios de niveles distintos, con restricciones de almacenamiento acordes a cada perfil de usuario.
Usuario administrador :( todos los privilegios)
Usuario: medico veterinario: (con privilegios para  borrar, agregar y modificar datos pero no para modificar estructuras de las tablas)
Usuario Asistente: solo tiene privilegios de consulta

CREACIÓN DE INDICE

Bitacora

Base de datos en la nube

Base de datos en la nube

Una base de datos en la nube es una base de datos que se ejecuta en la nube. Hay dos modelos de implementación: los usuarios pueden ejecutar la base de datos en la nube de forma independiente, utilizando una imagen de máquina virtual, o pueden comprar el acceso a un servicio de base de datos, gestionada por un proveedor de base de datos en nube. De las bases de datos disponibles en la nube, algunas son basadas en SQL y algunos utilizan un modelo de datos NoSQL.

Implementación del modelo

Existen dos métodos principales para ejecutar una base de datos en la nube:

Imagen de máquina virtual: Las plataformas en la nube permiten a los usuarios comprar instancias de máquinas virtuales por un tiempo limitado. Es posible ejecutar una base de datos en estas máquinas virtuales. Los usuarios pueden subir su imagen propia con una base de datos instalada en ella, o utilizar imágenes prefabricadas de máquinas que ya incluyen una instalación optimizada de una base de datos. Por ejemplo Oracle provee una imagen prefabricada con una instalación de Oracle Database 11g Enterprise Edition on Amazon EC2.

Base de datos como servicio: Algunas plataformas en la nube ofrecen opciones para el uso de bases de datos como servicio, sin lanzar físicamente una instancia de máquina virtual para la base de datos. En esta configuración, los propietarios de aplicaciones no tienen que instalar y mantener la base de datos por su cuenta. En cambio, el proveedor de servicios de base de datos se encarga de la instalación y el mantenimiento de la base de datos, y los propietarios de aplicaciones pagan de acuerdo a su uso.

Por ejemplo, Amazon Web Services provee dos servicios de base de datos como parte de su oferta en la nube, SimpleDB que almacena pares llave-valor en formato NoSql y Amazon Relational Database Service que esta basado en SQL con una interfaz MySql.

Una tercera opción es administrar el alojamiento de una base de datos en la nube, donde la base de datos no se ofrece como un servicio, pero el proveedor de la nube aloja la base de datos y administra en nombre del propietario de la aplicación. Por ejemplo, el servicio en la nube de Rackspace ofrece alojamiento gestionado para bases de datos MySQL.

Arquitectura y características en común

La mayoría de los servicios de bases de datos ofrecen consolas web, que el usuario final puede utilizar para aprovisionar y configurar las instancias de la base de datos. Por ejemplo, la consola web de Amazon Web Services permite a los usuarios lanzar instancias de bases de datos, crear instantáneas (similar a las copias de seguridad) de bases de datos y realizar un seguimiento de las estadísticas de la base de datos.

Los servicios de las bases de datos consisten en un componente de administración que controla las instancias de cada base de datos subyacente utilizando una API de servicios. La API de servicios se expone al usuario final, y permite a los usuarios realizar operaciones de mantenimiento y ampliar sus instancias de la base de datos. Por ejemplo, el servicio de Amazon Relational Database provee una API que permite crear una instancia de una base de datos, modificar los recursos disponibles de cada instancia, eliminar una instancia, la creación de una instantánea (similar a una copia de seguridad) de una base de datos y restauración de una base de datos a partir de una instantánea.

Los servicios de las bases de datos mantienen la pila del software subyacente, transparente al usuario - la pila normalmente incluye el sistema operativo, base de datos y el software de terceros utilizado por la base de datos. El proveedor de servicios es responsable de la instalación, parches y actualización de la pila de software subyacente.

Los servicios de las bases de datos cuidan la escalabilidad y la alta disponibilidad de la base de datos. Características de escalabilidad difieren entre los proveedores - algunos ofrecen auto-escala, mientras que otros permiten al usuario ampliar mediante una API, pero no escalar automáticamente.

Modelo de datos

También es importante diferenciar entre bases de datos en la nube que son relacionales en oposición a las no relacionales (NoSQL):

Bases de datos SQL, son un tipo de base de datos que se puede ejecutar en la nube (ya sea como una imagen de máquina virtual o como un servicio, dependiendo del proveedor). Las bases de datos SQL poseen baja escalabilidad, ya que no fueron nativamente diseñadas para entornos en la nube, aunque los servicios en la nube de base de datos basado en SQL están tratando de hacer frente a este desafío.

Bases de datos NoSQL, son otro tipo de base de datos que puede ejecutarse en la nube. Las bases de datos NoSQL están diseñados para servir cargas pesadas de lecto-escritura y son capaces de escalar hacia arriba y hacia abajo con facilidad.
Y por lo tanto son más adecuadas para funcionar de forma nativa en la nube. Sin embargo, la mayoría de las aplicaciones actuales se construyen en torno a un modelo de datos SQL, así que trabajar con bases de datos NoSQL con frecuencia requiere una reescritura completa del código de la aplicación

Diez de las más útiles bases de datos en la nube

Amazon Web Services
Tiene una variedad de servicios de bases de datos basadas en la nube, incluyendo bases de datos relacionales y NoSQL. Amazon Relational Database (SDR) ejecuta MySQL, Oracle o instancias de SQL Server, mientras que Amazon SimpleDB es una base de datos en menor escala pensada para cargas de trabajo más pequeñas. Por el lado de NoSQL, Amazon DynamoDB es su base de datos de unidad de estado sólido (SSD) que automáticamente replica cargas de trabajo en al menos tres zonas de disponibilidad. El CTO de AWS, Werner Vogels, señala que DynamoDB es el servicio de más rápido crecimiento en la historia de AWS. Amazon también ofrece una variedad de servicios auxiliares de gestión de datos, tales como su almacén de datos denominado Redshift, así como Data Pipeline, que ayuda a que los usuarios integren datos de múltiples fuentes para facilitar la gestión.

EnterpriseDB
Se centra en las bases de datos de código abierto PostgreSQL, pero su verdadero reclamo a la fama es su capacidad para trabajar con las aplicaciones de la base de datos Oracle. Con Postgres Plus Advanced Server de EnterpriseDB, las organizaciones pueden utilizar las aplicaciones escritas para bases de datos en las instalaciones de Oracle a través de EnterpriseDB, que se ejecuta en nubes de Amazon Web Services y HP. Tiene replicación binaria y copias de seguridad programadas.

Garantia Data
Ofrece un servicio de puerta de enlace para que los usuarios ejecuten Redis de código abierto y servicios de bases de datos Memcached NoSQL en memoria en la nube pública de AWS. El uso de software de Garantia permite la configuración automática de estos datos de código abierto al ayudar a que los desarrolladores de plataformas escalen nodos, creen grupos y construyan la tolerancia a fallas.

Google Cloud SQL
El servicio de base de datos en la nube de Google se centra en dos productos principales: Google Cloud SQL, que Google describe como una infraestructura de base de datos MySQL completamente relacional; y Google BigQuery, una herramienta de análisis para ejecutar consultas en grandes conjuntos de datos almacenados en la nube.

Microsoft Azure
Microsoft utiliza su tecnologia de servidor de SQL para proporcionar una base de datos relacional, permitiendo que los clientes accedan a una base de datos SQL ya sea en su nube, o en instancias de servidor SQL en las máquinas virtuales. Microsoft también hace hincapié en las bases de datos híbridas que combinan datos tanto en las instalaciones del cliente como en la nube Azure a través de SQL Data Sync. Microsoft tiene un servicio de nube alojada en la base de datos NoSQL llamada Tables, mientras que Blobs (almacenamiento de objeto binario grande), se ha optimizado para archivos multimedia, como audio y video.

MongoLab

En el mundo NoSQL, hay una variedad de plataformas de base de datos para elegir, incluyendo Mongob. MongoLab ofrece a los usuarios el acceso a MongoDB en una variedad de otros importantes proveedores de nube, incluyendo AWS, Azure y Joyent. Al igual que los otros tipos de servicios de puerta de enlace, MongoLab también se integra con varias herramientas de plataformas como servicio (PaaS) en el nivel de aplicación. MongoLab funciona con entornos compartidos o dedicados, siendo el último ligeramente más caro.

Rackspace
La base de datos de Rackspace viene en una nube o en una oferta gestionada a través de Cloud Databases es el nombre de su producto. Rackspace pone énfasis en la virtualización basada en contenedores de sus Cloud Databases, que dicen permitir un mayor rendimiento en el servicio de base de datos en comparación a si se ejecuta por completo en la infraestructura virtualizada. Cloud Databases también incorpora una red de almacenamiento SAN y se basa en una plataforma OpenStack. En diciembre pasado, Rackspace anunció una base de datos NoSQL en su nube del proveedor Cloudant.

SAP
Es una plataforma basada en la tecnología en memoria. Su base de datos en nube complementa las herramientas de base de datos que están en las instalaciones de la empresa -incluyendo Sybase-, y está disponible en la nube de Amazon Web Services. HANA incluye otras aplicaciones que no son de bases de datos, como herramientas de gestión empresarial y desarrollo de aplicaciones.

StormDB
Sigue su distribución completa de base de datos relacional en los servidores de metal, lo que significa que no hay virtualización de máquinas. Los funcionarios de StormDB afirman que esto conduce a un mejor rendimiento y a una gestión más sencilla, porque los usuarios no tienen que elegir el tamaño de las instancias de máquina virtual que se ejecuta en su base de datos. A pesar de que se ejecuta en ‘bare metal’, los clientes no tienen que escoger el tamaño de instancias de máquinas virtuales sobre la que se ejecuta su base de datos, aunque StormDB promete aislamiento entre las bases de datos de los clientes. StormDB también fragmenta automáticamente bases de datos en la nube. La compañía se encuentra actualmente en versión beta gratuita.

Xeround
Es una herramienta de gestión para la implementación de bases de datos MySQL fácilmente escalables a través de una variedad de proveedores y plataformas de nube. Su software permite una alta disponibilidad y escalabilidad, y funciona a través de una variedad de proveedores de nube incluyendo AWS, Rackspace, Joyent y HP, así como OpenStack y plataformas Citrix.

 

PARTICIONAMIENTO MYSQL & ORACLE

PARTICIONAMIENTO MYSQL

Particionar tablas en MySQL nos permite rotar la información de nuestras tablas en diferentes particiones, consiguiendo así realizar consultas más rápidas y recuperar espacio en disco al borrar los registros. El uso más común de particionado es según fecha (date).

Para ver si nuestra base de datos soporta particionado simplemente ejecutamos:

SHOW VARIABLES LIKE '%partition%';

Consiste en dividir los datos en particiones más pequeñas (hasta 1024) procurando, porque de otra forma sería absurdo, que sólo haya que acceder a una partición a la hora de buscar una tupla.

Se puede particionar una tabla de 5 maneras diferentes:

Por rango: para construir nuestras particiones especificamos rangos de valores. Por ejemplo, podríamos segmentar los datos en 12 particiones: una para los contratos de 1950 a 1960, otra para los años 60, los 70, 80, 90, la década del 2000 y la década actual
    

1. ALTER TABLE contratos
2. PARTITION BY RANGE(YEAR(fechaInicio)) (
3. PARTITION partDecada50 VALUES LESS THAN (1960),
4. PARTITION partDecada60 VALUES LESS THAN (1970),
5. PARTITION partDecada70 VALUES LESS THAN (1980),
6. PARTITION partDecada80 VALUES LESS THAN (1990),
7. PARTITION partDecada90 VALUES LESS THAN (2000),
8. PARTITION partDecada00 VALUES LESS THAN (2010),
9. PARTITION partDecada10 VALUES LESS THAN MAXVALUE
10. );

• Por listas: para construir nuestras particiones especificamos listas de valores concretos.
  
  
1. ALTER TABLE contratos
2. PARTITION BY LIST(YEAR(fechaInicio)) (
3. PARTITION partDecada50 VALUES IN (1950, 1951, 1952, 1953, 1954, 1955, 1956, 1957, 1958, 1959),
4. PARTITION partDecada60 VALUES IN (1960, 1961, 1962, 1963, 1964, 1965, 1966, 1967, 1968, 1969),
5. PARTITION partDecada70 VALUES IN (1970, 1971, 1972, 1973, 1974, 1975, 1976, 1977, 1978, 1979),
6. PARTITION partDecada80 VALUES IN (1980, 1981, 1982, 1983, 1984, 1985, 1986, 1987, 1988, 1989),
7. PARTITION partDecada90 VALUES IN (1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999),
8. PARTITION partDecada00 VALUES IN (2000, 2001, 2002, 2003, 2004, 2005, 2006,
9. 2007, 2008, 2009),
10. PARTITION partDecada10 VALUES IN (2010, 2011, 2012, 2013, 2014, 2015, 2016,
11. 2017, 2018, 2019)
12. );

• Por hash: MySQL se encarga de distribuir las tuplas automáticamente usando una operación de módulo. Sólo hay que pasarle una columna o expresión que resulte en un entero (el hash) y el número de particiones que queramos crear.
1. ALTER TABLE contratos
2. PARTITION BY HASH(YEAR(fechaInicio))
3. PARTITIONS 7; R TABLE contratos

PARTITION BY HASH(YEAR(fechaInicio))PARTITIONS

• Por clave: similar a la partición por hash, pero en este caso no necesitamos pasarle un entero; MySQL utilizará su propia función de hash para generarlo. Si no se indica ninguna columna a partir de la que generar el hash, se utiliza la clave primaria por defecto.
1. ALTER TABLE contratos
2. PARTITION BY KEY()
3. PARTITIONS 7;
• Compuesta: podemos combinar los distintos métodos de particionado y crear particiones de particiones

Por último, un pequeño ejemplo de cómo afectaría el particionado a una consulta sencilla como obtener el número total de tuplas que cumplen una condición. Estas son las estadísticas de la consulta sin particionado (ni índices)

1. EXPLAIN SELECT COUNT(*)
2. FROM contratos
3. WHERE fechaInicio BETWEEN '1950-01-01' AND '1955-12-31'

EXPLAIN SELECT COUNT(*)

FROM contratosWHERE fechaInicio BETWEEN '1950-01-01' AND '1955-12-31'

select_type	table	type	key	rows	Extra
SIMPLE	contratos	ALL		239796	Using where

Y este el resultado de añadir las particiones (nótese la palabra clave PARTITIONS para que nos muestre también la información relativa a las particiones)

1.     EXPLAIN PARTITIONS SELECT COUNT(*)

2.    FROM contratos

3.    WHERE fechaInicio BETWEEN '1950-01-01' AND '1955-12-31'

WHERE fechaInicio BETWEEN '1950-01-01' AND '1955-12-31'

select_type	table	partitions	type	key	rows	Extra
SIMPLE	contratos	partDecada50	ALL		8640	Using where

Como véis, el número de tuplas que MySQL tiene que comprobar se ve disminunido en 2 órdenes de magnitud.

PARTICIONES EN ORACLE

El particionado se realiza utilizando una clave de particionado (partitioning key), que determina en que partición de las existentes en la tabla van a residir los datos que se insertan. Oracle también permite realizar el particionado de indices y de tablas organizadas por indices. Cada partición ademas puede tener sus propias propiedades de almacenamiento. Las tablas particionadas aparecen en el sistema como una única tabla, realizando el sistema la gestión automatica de lectura y escritura en cada una de las particiones (excepto para el caso de la partición de Sistema introducida en la versión 11g). La definición de las particiones se indica en la sentencia de creación de las tablas, con la sintaxis oportuna para cada uno de los tipos.

• Particionado Range: la clave de particionado viene determinada por un rango de valores, que determina la partición donde se almacenara un valor.
• Particionado Hash: la clave de particionado es una función hash, aplicada sobre una columna, que tiene como objetivo realizar una distribución equitativa de los registros sobre las diferentes particiones. Es útil para particionar tablas donde no hay unos criterios de particionado claros, pero en la que se quiere mejor el rendimiento.
• Particionado List: la clave de particionado es una lista de valores, que determina cada una de las particiones.
• Particionado Composite: los particionados anteriores eran del tipo simples (single o one-level), pues utilizamos un unico método de particionado sobre una o mas columnas. Oracle nos permite utilizar metodos de particionado compuestos, utilizando un primer particionado de un tipo determinado, y luego para cada particion, realizar un segundo nivel de particionado utilizando otro metodo. Las combinaciones son las siguientes (se han ido ampliando conforme han ido avanzando las versiones): range-hash, range-list, range-range, list-range, list-list, list-hash y hash-hash (introducido en la versión 11g).
• Particionado Interval: tipo de particionado introducido igualmente en la versión 11g. En lugar de indicar los rangos de valores que van a determinar como se realiza el particionado, el sistema automáticamente creara las particiones cuando se inserte un nuevo registro en la b.d. Las técnicas de este tipo disponible son Interval, Interval List, Interval Range e Interval Hash (por lo que el particionado Interval es complementario a las técnicas de particionado vistas anteriormente).
• Particionado System: se define la tabla particionada indicando las particiones deseadas, pero no se indica una clave de particionamiento. En este tipo de particionado, se delega la gestión del particionado a las aplicaciones que utilicen la base de datos (por ejemplo, en las sentencias sql de inserción deberemos de indicar en que partición insertamos los datos).

REFERENCIAS

http://mundogeek.net/archivos/2012/03/09/particiones-en-mysql/.

http://infodocs.net/articulo/mysql/particionado-de-tablas-en-mysql

http://repositorio.utn.edu.ec/bitstream/123456789/522/5/04%20ISC%20151%20CAPITULO%20III.pdf