Archive for the ‘PostgreSQL’ Category

Transacciones ACID

miércoles, julio 25th, 2012

En el contexto de transacciones de bases de datos, ACID es un acrónimo de Atomico (Atomic), Consistente (Consistent), Aislado (Isolation) y Durabilidad(Durable). Las transacciones proporcionan un modelo sencillo de éxito o fracaso una o un conjunto de operaciones en la base de datos. Una transacción se compromete (es decir, todas sus acciones se ejecutaron de forma correcta), o se anula (es decir, si una accion fallo, entonces todas sus acciones hechas hasta ese momento se deshacen). Los atributos de una transacción ACID son las siguientes:

Atomicidad

Una transacción permite la agrupación de uno o más cambios en las tablas y filas en la base de datos para formar una operación atómica e indivisible. Es decir, o bien se producen todos los cambios o ninguno de ellos. Si por alguna razón la transacción no puede completarse, la operación debe restablecer el estado de la base de datos al momento en que estaba antes del inicio de la transacción a través de una operación de reversa (rollback).

Consistencia

Las transacciones siempre operan en una visión coherente de los datos y cuando terminan deben también dejar los datos en un estado coherente. Mientras que una transacción se ejecuta se generan inconsistencias momentaneas dentro de la base de datos, pero la transaccion no puede dejar ver estas inconsistencias; al finalizar, debido a que en la finalización todas las inconsistencias deben son eliminadas, la transaccion libera los datos para que puedan ser leídos/escritos nuevamente.

Aislamiento

Para una operación determinada, debería ser como si ésta se estuviese ejecutando sola en la base de datos. Los efectos de la ejecución simultánea de las transacciones son invisibles para esta transacción, y los efectos de esta transacción son invisibles para los demás hasta que la transacción ha comprometido su trabajo.

Durabilidad

Una vez que se confirma una transacción y sus efectos, se garantiza que persista incluso en el caso de fallos posteriores del sistema. Hasta antes de que se confirme la transacción, los cambios realizados por esa transacción no son durables, y no persisten en la cara de un fallo del sistema, al recuperarse de un fallo se deshacen las inconsistencias provocas por la ejecución no terminada de la transaccion.

La simplicidad de las transacciones ACID es especialmente importante en un entorno de base de datos distribuida, donde las transacciones se realizan de forma simultánea.

Borrar usuarios de GForge

martes, enero 18th, 2011

Cuando uno elimina desde la interfaz de GFoge un usuario, el usuario realmente no es borrado, sino que queda en un status eliminado (status=2), en general no borro usuarios debido a que estos pertenecen a la historia de los proyectos, pero en algunos casos existen usuarios que se han inscrito de forma spam, por lo que realmente estan en estado pendiente. Cuando existen en ese estado puede ser porque realmente estan incritos coherentemente o es spam. En mi caso los elimino manualmente, y a todos los eliminados les ejecuto en orden el siguiente script ( asumiendo que #id_usuario es el id del usuario)

delete from public.audit_trail where user_id=#id_usuario;
delete from public.mailmen where user_id=#id_usuario;
delete from public.user_session where user_id=#id_usuario;
delete from public.user_preference where user_id=#id_usuario;
delete from public.user where user_id=#id_usuario;
commit;

En el caso que estuviesemos absolutamente seguros de que todos los eliminados son sólo spam, entonces puede servir el SQL

delete from public.user where status = 2 and unix_name <> 'none';

Exportar esquema en postgresql

martes, enero 18th, 2011

Para la exportacion de un esquema en PostgreSQL asumiendo que posees el login y password sería

pg_dump -U login -s database > database_schema_create.sql

en donde:

  • database es la base de datos que deseas exportar
  • login es el usuario de la base de datos (con los pribvilegios disponibles)