practica 18

Siempre es necesario tener un respaldo de nuestras bases de datos, pero que pasa cuando nuestras bases de datos estan tan pesadas que el phpMyAdmin se queda colgado :s. Para eso nos sirve mysqldump un comando que nos trae MySQL para hacer respaldos de nuestras bases de datos su sintaxis es la siguiente:

mysqldump [OPTIONS] database [tables]
O mysqldump [OPTIONS] –databases [OPTIONS] DB1 [DB2 DB3...]
O mysqldump [OPTIONS] –all-databases [OPTIONS]

Algunos de sus parametros mas utilizados son los siguientes:

-A, –all-databases Dump all the databases. This will be same as –databaseswith all databases selected.
–add-drop-database Add a ‘DROP DATABASE’ before each create.
–add-drop-table Add a ‘drop table’ before each create.
–add-locks Add locks around insert statements.
–allow-keywords Allow creation of column names that are keywords.
–create-options Include all MySQL specific create options.
-e, –extended-insert Allows utilization of the new, much faster INSERT syntax.
-p, –password[=name] Password to use when connecting to server. If password is not given it’s solicited on the tty.
-u, –user=name User for login if not current user.

Bien, ahora pongo un ejemplo de su uso:

1. #Respaldando una única base de datos
2.  
3. mysqldump -uroot -p –all –add-locks -e mibase > bkmibase.sql;
4.  
5. #Respaldar todas mis bases de datos
6.  
7. mysqldump -uroot -p –all –all-databases –add-locks -e > bkmisbases.sql;

Ok, ya tenemos nuestro respaldo ahora como la importamos? pues bien para cargarlo existen varias formas aqui les presento una que me sirve bastate:

1. #Nos conectamos a mysql
2.  
3. mysql -uroot -p
4.  
5. USE mibase;
6.  
7. source /path/TO/mibase.sql;

como comentario para importar tablas tipo innodb se recomienda agregar:

1. SET FOREIGN_KEY_CHECKS=0;

Al inicio del archivo y:

1. SET FOREIGN_KEY_CHECKS=1;

al final con el fin de no obtener errores.

practica 17

1 Posibilidades

---

Oracle pone al alcance del DBA varios niveles de seguridad:

• Seguridad de cuentas para la validación de usuarios.
• Seguridad en el acceso a los objetos de la base de datos.
• Seguridad a nivel de sistema para la gestión de privilegios globales.

1.1 Seguridad de Cuentas

Para acceder a los datos en una BD Oracle, se debe tener acceso a una cuenta en esa BD. Cada cuenta debe tener una palabra clave o password asociada. Una cuenta en una BD puede estár ligada con una cuenta de sistema operativo. Los passwords son fijados cuando se crea un usuario y pueden ser alterados por el DBA o por el usuario mismo. La BD almacena una versión encriptada del password en una tabla del diccionario llamada dba_users. Si la cuenta en la BD está asociada a una cuenta del sistema operativo puede evitarse la comprobación del password, dándose por válida la comprobación de la identidad del usuario realizada por el SO.

1.2 Seguridad de Objetos

El acceso a los objetos de la BD se realiza via privilegios. Estos permiten que determinados comandos sean utilizados contra determinados objetos de la BD. Esto se especifica con el comando GRANT, conceder. Los privilegios se pueden agrupar formando lo que se conoce por roles. La utilización de los roles simplifica la administración de los privilegios cuando tenemos muchos usuarios. Los roles pueden ser protegidos con passwords, y pueden activarse y desactivarse dinámicamente, con lo que constituyen una capa más de seguridad en el sistema.

1.3 Roles del Sistema

Los roles se pueden utilizar para gestionar los comandos de sistema disponibles para los usuarios. Estos incluyen comandos como CREATE TABLE o SELECT ANY TABLE. Todos los usuarios que quieran acceder a la BD deben tener el rol CONNECT; aquellos que necesiten crear segmentos necesitaran el rol RESOURCE. Un usuario con el rol DBA tiene derecho para ver y manejar todos los datos de la BD. En Oracle CONNECT, RESOURCE y DBA son roles de sistema. Las acciones contra cada tipo de objeto son autorizadas por privilegios separados. Así, un usuario puede tener concedido el privilegio CREATE TABLE, pero no el ALTER TABLE.

---

2 Implementación de Seguridad

---

No se podrá acceder a la BD a menos que se acceda primero al servidor en el que la BD está ejecutándose. El primer paso en la seguridad de la BD es asegurar la plataforma en la que reside. Una vez que esto ha sido conseguido, se debe considerar la seguridad del sistema operativo. Oracle utiliza una serie de ficheros a los que los usuario no tienen porque acceder de manera directa. Por ejemplo, los ficheros de datos o los de redo log son escritos y leidos sólo por los procesos Oracle. Así, sólo los DBAs que han creado estos ficheros necesitan acceder directamente a ellos a nivel del sistema operativo.

2.1 Creación de Usuarios

El objetivo de la creación de usuarios es establecer una cuenta segura y útil, que tenga los privilegios adecuados y los valores por defecto apropiados. En Oracle se puede especificar todo lo necesario para abrir una cuenta con el comando CREATE USER. Los parámetros que se le pueden pasar son:

Parámetro	Significado
Username	Nombre del Usuario (Esquema)
Password	Palabra clave de la cuenta. Puede ser asociada directamente a una cuenta del sistema operativo.
Default Tablespace	Espacio de tablas por defecto en el que los objetos de este usuario serán creados. Esto no da al usuario derechos de crear objetos.
Temporary Tablespace	El espacio de tablas en el que se almacenarán los segmentos temporales de las ordenaciones.
Quota	Espacio máximo que puede ocupar en un espacio de tablas.
Profile	Asigna un perfil al usuario. Los perfiles se utilizan para restringir el uso de recursos como el tiempo de CPU.

A continuación se puede ver un ejemplo de uso del comando CREATE USER en el que se crea una cuenta para el usuario Pérez:

SVRMGR> create user perez 
     2> identified by zerep
     3> default tablespace users
     4> temporary tablespace temp;

Si no se especifica un perfil, se aplica el perfil por defecto de la BD, que se llama DEFAULT y tiene asignados todos los límites a UNLIMITED.

Si no se especifíca una cuota el usuario no puede crear objetos.

2.2 Eliminación de Usuarios

Los usuarios pueden ser eliminados de la BD utilizando el comando DROP USER. Este comando tiene un único parámetro, CASCADE, el cual permite borrar todos los objetos del usuario antes de eliminar el usuario.

A continuación un ejemplo en el que eliminamos al usuario Pérez:

SVRMGR> drop user perez cascade; 

Si a continuación se crea otro usuario con el mismo nombre no hereda los objetos del anterior usuario con ese nombre. La razón estriba en que Oracle asigna a cada cuenta un número además del nombre, y utiliza ese número para determinar el propietario de todos los objetos que crea esa cuenta, y no utiliza el nombre sino para la comunicación con los usuarios. De este modo al crear un nuevo usuario, aunque sea con el mismo nombre, no puede heredar los objetos que antes eran de otro usuario con el mismo nombre.

2.3 Privilegios del Sistema

Los roles de sistema se utilizan para distribuir la disponibilidad de los comandos del sistema utilizados para gestionar la BD. Los privilegios más comunes están en la siguiente tabla. En ella se distinguen entre privilegios de manejo de objetos y de gestión de la BD. La palabra clave ANY significa que ese usuario tiene el privilegio para todos los esquemas en la BD. Hay que hacer notar que ANY y PUBLIC no son sinónimos.

Privilegio	Capacidades
Manejo de Objetos	...
CREATE ANY INDEX	Crear cualquier índice.
CREATE [PUBLIC] SYNONYM	Crear sinónimos [públicos].
CREATE [ANY] TABLE	Crear tablas. El usuario debe tener cuota en el espacio de tablas, o ha de tener asignado el privilegio UNLIMITED TABLESPACE.
CREATE [ANY] VIEW	Crear vistas.
ALTER ANY INDEX	Alterar cualquier índice.
ALTER ANY TABLE	Alterar cualquier tabla
DROP ANY INDEX	Borrar cualquier índice.
DROP ANY SYNONYM	Borrar cualquier sinónimo.
DROP PUBLIC SYNONYM	Borrar sinónimos públicos.
DROP ANY VIEW	Borrar cualquier vista.
DROP ANY TABLE	Borrar cualquier tabla.
SELECT ANY TABLE	Efectuar selecciones de cualquier tabla o vista.
INSERT ANY TABLE	Insertar en cualquier tabla o vista.
DELETE ANY TABLE	Borrar filas de cualquier tabla o vista, y también truncar.
ALTER SESSION	Alterar los parámetros de la sesión.
CREATE SESSION	Conectarse a la BD.
Gestión de la BD	...
CREATE PROFILE	Crear perfiles de usuario.
CREATE ROLE	Crear roles.
CREATE ROLLBACK SEGMENT	Creación de segmentos de rollback.
CREATE TABLESPACE	Crear espacios de tablas.
CREATE USER	Crear usuarios.
ALTER PROFILE	Alterar perfiles existentes.
ALTER ANY ROLE	Alterar cualquier rol.
ALTER ROLLBACK SEGMENT	Alterar segmentos de rollback.
ALTER TABLESPACE	Alterar espacios de tablas.
ALTER USER	Alterar usuarios.
DROP PROFILE	Borrar un perfil existente.
DROP ANY ROLE	Borrar cualquier rol.
DROP ROLLBACK SEGMENT	Borrar un segmento de rollback existente.
DROP TABLESPACE	Borrar un espacio de tablas.
DROP USER	Borrar un usuario. Añadir CASCADE si el usuario posee objetos.
ALTER DATABASE	Permite una sentencia ALTER DATABASE.
GRANT ANY PRIVILEGE	Otorgar cualquiera de estos privilegios.
GRANT ANY ROLE	Otorgar cualquier rol a un usario.
UNLIMITED TABLESPACE	Puede usar una cantidad de almacenamiento ilimitada.
DROP PROFILE	Borrar un perfil existente.

Los privilegios se pueden agrupar en roles, para así satisfacer a distintos tipos de usuarios. En la instalación se crea un rol llamado OSOPER que sirve para los operarios de la máquina donde está la BD y permite realizar copias de seguridad en frio y en caliente. Los privilegios de OSOPER son STARTUP, SHUTDOWN, ALTER DATABASE OPEN/MOUNT, ALTER DATABASE BACKUP, ARCHIVE LOG, RECOVER y RESTRICTED SESSION.

Se pueden crear nuevos roles. Por ejemplo, podemos crear un rol llamado creadorCuentas que sólo pueda crear usuarios y no pueda realizar ninguna otra operación de DBA. Las sentencias que permiten hacer esto son las siguientes:

SVRMGR> create role creadorCuentas;
Statement processed.
SVRMGR> grant create session, create user to creadorCuentas;
Statement processed.

Oracle incluye otros tres roles de sistema: CONNECT, RESOURCE y DBA, cuyos privilegios son:

Rol	Privilegios
CONNECT	alter session, create session, create cluster, create table, create view, create synonym, create sequence, create database link
RESOURCE	create cluster, create table, create procedure, create sequence, create trigger
DBA	todos los privilegios de sistema con la opcion with admin option

2.4 Perfiles de Usuario

Los perfiles se utilizan para limitar la cantidad de recursos del sistema y de la BD disponibles para un usuario. Si no se definen perfiles para un usuario se utiliza el perfil por defecto, que especifica recursos ilimitados.

Los recursos que pueden ser limitados via perfil son los siguientes:

Recurso	Descripción
SESSIONES_PER_USER	El número de sesiones concurrentes que un usuario puede tener en una instancia.
CPU_PER_SESSION	El tiempo de CPU, en centenas de segundos, que una sesión puede utilizar.
CONNECT_TIME	El número de minutos que una sesión puede permanecer activa.
IDLE_TIME	El número de minutos que una sesión puede permanecer sin que sea utilizada de manera activa.
LOGICAL_READS_PER_SESSION	El número de bloques de datos que se pueden leer en una sesión.
LOGICAL_READS_PER_CALL	El número de bloques de datos que se pueden leer en una operación.
PRIVATE_SGA	La cantidad de espacio privado que una sesión puede reservar en la zona de SQL compartido de la SGA.
COMPOSITE_LIMIT	El número de total de recursos por sesión, en unidades de servicio. Esto resulta de un calculo ponderado de CPU_PER_SESSION, CONNECT_TIME, LOGICAL_READS_PER_SESSION y PRIVATE_SGA, cuyos pesos se pueden variar con el comando ALTER RESOURCE COST.

Los perfiles se pueden crear via el comando CREATE PROFILE, y se pueden modificar con la sentencia ALTER PROFILE.

En general, el perfil por defecto debe ser adecuado para los usuarios normales; los usuarios con requerimientos especiales deberían tener perfiles especiales.

2.5 Cuentas BD sobre Cuentas SO

Los usuarios pueden entrar en la BD una vez que han dado un nombre de usuario y una palabra de paso. Sin embargo, es posible aprovecharse del Sistema Operativo para obtener un nivel adicional de autentificación.

La cuenta de la BD y del SO pueden relacionarse de manera que la de la BD se diferencie sólo en un prefijo de la cuenta del SO. Este prefijo se fija en el parámetro OS_AUTHENTIC_PREFIX del fichero init.ora. Por defecto esta puesto a "OPS$", pero puede tomar cualquier forma, incluso ser la cadena nula, "", con lo que no existe prefijo que diferencie las cuentas en la BD y en el SO.

Por ejemplo, consideremos la cuenta del SO llamada alu10. La correspondiente cuenta en la BD sería OPS$ALU10. Cuando el usuario alu10 está en activo en el SO, puede acceder a su cuenta OPS$ALU10 sin especificar el password, como se muestra a continuación:

$ sqlplus /

En este caso el carácter "/" toma el lugar de la combinación del nombre de usuario y del password que debería aparecer.

Las cuentas pueden ser creadas con passwords aunque no vaya a ser utilizado. Ya que de este modo será posible acceder a la cuenta de OPS$ALU10 desde otra cuenta diferente a la alu10 del SO. La sentencia de creación de la cuenta OPS$ALU10 puede ser la siguiente:

SVRMGR> create user ops$alu10
     2> identified by 01ula
     3> default tablespace users
     4> temporary tablespace temp;

Así, la forma de conectarse como OPS$ALU10 desde una cuenta del SO diferente es:

$ sqlplus ops$alu10/01ula

Existen dos formas de evitar este problema. La primera es creando el usuario BD sin especificar un password, utilizando la claúsula IDENTIFIED EXTERNALLY. De esta manera evitamos la necesidad de expecificar un password para la cuenta, obligando a la conexión entre las cuentas de la BD y del SO:

SVRMGR> create user ops$alu10
     2> identified externally
     3> default tablespace users
     4> temporary tablespace temp;

La otra manera de evitar el problema es crear una cuenta con un password imposible, aspecto este que se explicará más adelante.

2.6 Protegidos por passwords

Los passwords puede proteger tanto cuentas como roles. Los passwords se fijan a la hora de la creación de ambos y se pueden modificar con los comandos ALTER USER y ALTER ROLE, respectivamente.

No es necesario asignar un password a un rol, pero si tiene uno debe ser especificado por el usuario cuando se asigna ese rol.

3.2

INTRODUCCIÓN
En este manual se encuentras las funciones básicas de PostgreSQL, como la
autentificación ante PostgreSQL, el manejo de contraseñas, el manejo de
usuarios (creación, modificación y eliminación) y sus privilegios, el manejo de
grupos, (creación, eliminación), algunas otras funciones de PostgreSQL, como lo
son los triggers, la creación, modificación y eliminación de tablas, creación y
eliminación de bases de datos, los tipos de datos y los tipos numéricos.
Para cada sentencia o comando se muestra su sintaxis, y se parte del hecho de
que la persona que haga uso de este manual, tiene conocimientos básicos,
sobre el lenguaje SQL.
1. AUTENTICACIÓN EN POSTGRESQL
PostgreSQL es un Sistema de Gestión de Bases de Datos Objeto-Relacionales.
Comenzó como un proyecto denominado Ingres en la Universidad Berkeley de
California. Ingres fue desarrollado comercialmente más tarde por la Relational
Technologies / Ingres Corporation.
A partir de PostgreSQL 7.1.x, los accesos de clientes basados en máquina
(host) se encuentran especificados en el archivo pg_hba.conf. El archivo
pg_hba.conf le permite establecer el tipo de autenticación basasda en máquina a
ser usada. Esta autenticación es realizada antes de que PostgreSQL estblezca
una conexión a la base de datos en cuestión, donde los permisis de usuarios
serían relevantes.
El archivo pg_hba.conf está localizado en el directorio de datos de PostgreSQL
(p.ej., /usr/local/pgsql/data/), y es instalado automáticamente con la ejecución del
comando initdb cuando PostgreSQL es instalado.
1.1 Autenticación de Contraseña
Las contraseñas de usuario son almacenadas en un texto plano en la tabla de
sistema pg_shadow, pero sólo los superusuarios de PostgreSQL tienen permiso
para ver la tabla pg_shadow y esta tabla además es accesible desde cualquier
base de datos.
La estructura de la tabla es:
Columna Tipo
usename name
usesysid integer
usecreatedb boolean
usetrace boolean
usesuper boolean
usecatupd boolean
passwd text
valuntil abstime
En dado caso que la contraseña no sea definida, por defecto el sistema asignara
NULL.
2. ADMINISTRACIÓN DE POSTGRESQL
PostgreSQL almacena los datos de usuarios así como también los datos de los
grupos dentro de sus propios catálogos de sistema. De esta manera, cualquier
conexión a PostgreSQL debe ser realizada con un usuario específico, y
cualquier usuario puede pertenecer a uno o más grupos definidos.
La tabla de usuarios en PostgreSQL controla los permisos de acceso y quién
está autorizado a realizar acciones en el sistema, al igual qué las acciones
puede realizar. Los grupos existen como un mecanismo para simplificar la
ubicación de estos permisos. Tanto las tablas de usuarios como de grupos
existen como objetos globales de base de datos, por consiguiente no están
agregadas a ninguna base de datos en particular.
2.1 Gestión de Usuarios
Cada usuario tiene un ID de sistema interno en PostgreSQL (llamado sysid),
así como una contraseña. El ID es utilizado para asociar objetos en una base
de datos con su propietario
PostgreSQL crea por defecto a un superusuario llamado postgres. Todos los
demás superusuarios pueden ser creados por éste, o por cualquier otro
superusuario creado posteriormente.
PostgreSQL proporciona dos métodos para la creación de usuarios de bases
de datos. Cada uno de ellos requiere autenticación como superusuario.
Los métodos son:
· A través del uso del comando SQL CREATE USER.
· Un programa de línea de comandos llamado createuser
2.1.1 CREATE USER
La sintaxis para CREATE USER es:
CREATE USER nombre_usuario
[ WITH [ SYSID uid ]
[ PASSWORD 'password' ] ]
[ CREATEDB | NOCREATEDB ]
[ CREATEUSER | NOCREATEUSER ]
[ IN GROUP groupname [, ...] ]
[ VALID UNTIL 'abstime' ]
A continuación se describe cada una de las partes de la sintaxis de CREATE
USER:
· SYSID uid
Especifica que el ID que va a definirse debe establecerse al valor de uid.
Si se omite, un razonable y único valor numérico por defecto es escogido.
· PASSWORD 'password'
Establece la nueva contraseña del usuario. Si no se especifica, la
contraseña por defecto es NULL.
· CREATEDB | NOCREATEDB
Usando la palabra clave CREATEDB se le garantiza al nuevo usuario el
privilegio de crear nuevas bases de datos, así como el de destruir las de
su propiedad. Usando NOCREATEDB se deniega este permiso (que es lo
que ocurre por defecto).
· CREATEUSER | NOCREATEUSER
Certifica el privilegio de crear nuevos usuarios. Si un usuario tiene los
privilegios de crear a otros usuarios tendrá además todos los privilegios,
en todas las bases de datos (incluyendo los permisos para crear una base
de datos, aunque se haya especificado NOCREATEDB).
NOCREATEUSER explícitamente fuerza a la situación por defecto, que
deniega el privilegio.
· IN GROUP nombre_grupo [, ...]
Añade al nuevo usuario al grupo llamado nombre_grupo. Pueden ser
especificados múltiples nombres de grupo, separándolos mediante
comas. El o los grupos deben existir para que funcione la condición.
· VALID UNTIL 'abstime'
Establece que la contraseña del usuario expirará el abstime, el cual debe
ser un formato reconocible de fecha/hora (timestamp). Tras esa fecha, la
contraseña se resetea, y la expiración se hace efectiva.
· VALID UNTIL 'infinity'
Establece validez permanente para la contraseña del usuario.
2.1.2 createuser
El script createuser es ejecutado directamente desde la línea de comandos, y
puede operar de dos formas.
Si se utiliza sin argumentos, él interactivamente le pedirá el nombre de
usuario y cada uno de los privilegios que se le van a asignar. Alternamente,
puede optar por especificar las opciones y el nombre del usuario a ser creado
en la misma línea de comandos.
La sintaxis de createuser es:
createuser [ opciones ] [ nombre_usuario ]
El nombre_usuario en la sintaxis representa el nombre del usuario que va a
crear. Reemplace opciones con una o más de las siguientes:
· -d, -createdb Equivalente a la palabra clave CREATEDB. Permite al
nuevo usuario crear bases de datos.
· -D, -no-createdb Equivalente a la palabra clave NOCREATEDB
Explícitamente indica que el nuevo usuario no puede crear bases de
datos.
· -a, -adduser Equivalente a la palabra clave CREATEUSER Perimte al
nuevo usuario la creación de otros usuarios, y asigna el status de
superusurario al usuario.
· -A, -no-adduser Equivalente a la palabra clave NOCREATEUSER.
Explícitamente indica que el nuevo usuario no es superusuario.
· -i SYSID, -sysid=SYSID Establece el nuevo ID de sistema del usuario a
SYSID.
· -P, -pwprompt Resulta en una petición de introducción de contraseña,
permitiéndole establecer la contraseña del nuevo usuario.
· -h NOMBRE_MAQUINA, -host=NOMBRE_MAQUINA Especifica desde
qué NOMBRE_MAQUINA se conectará, además de la local (localhost), o
la máquina definida por la variable de entorno PGHOST.
· -p PUERTO, -port=PUERTO Especifica que la conexión de base de
datos se realizará por el puerto PUERTO, en vez de por el puerto por
defecto.
· -U NOMBRE_USUARIO, -username=NOMBRE_USUARIO Especifica
que NOMBRE_USUARIO será el usuario que conecte a PostgreSQL (por
defecto se conecta usando el nombre de usuario del sistema).
· -W, -password Resulta en una petición de contraseña para el usuario
que conecta, lo cual ocurre automáticamente si el archivo pg_hba.conf
está configurado para no confiar en la máquina solicitante.
2.2Modificación de Usuarios
Los usuarios existentes sólo pueden ser modificados por superusuarios
PostgreSQL mediante el comando SQL ALTER USER, donde su sintaxis es:
ALTER USER nombre_usuario
[ WITH PASSWORD 'password' ]
[ CREATEDB | NOCREATEDB ]
[ CREATEUSER | NOCREATEUSER ]
[ VALID UNTIL 'abstime' ]
Aquí nuevamente se hace uso de las palabras claves utilizadas en
CREATE USER.
2.3 Eliminación de Usuarios
Al igual que en la creación de usuarios, en la eliminación de usuarios también
existen dos formas de hacerlo:
· El comando DROP USER
· El programa psql
La sintaxis para DROP USER es:
DROP USER nombre_usuario
La sintaxis para psql es:
[~]$ psql -U manager template1
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
template1=# DROP USER salesuser;
DROP USER
2.4Manejo de Grupos
Cualquier superusuario puede crear un nuevo grupo en PostgreSQL con el
comando CREATE GROUP. Aquí tiene la sintaxis de CREATE GROUP:
CREATE GROUP nombre_grupo
[ WITH [ SYSID groupid ]
[ USER username [, ...] ] ]
En la sintaxis, nombre_grupo es el nombre del grupo a ser creado. debe iniciar
por una carácter alfabético, y no puede exeder los 31 caracteres de longitud. El
proporcionar la palabra clave WITH permite especificar cualquiera de los
atributos opcionales. Si desea especificar el ID de sistema a usar con el nuevo
grupo, utilice la palabra clave SYSID para especificar el valor de groupid. Use la
palabra clave USER para incluir a uno o más usuarios al grupo en tiempo de
creación. Separe los distintos usuarios mediante comas.
Adicionalmente, el usuario PostgreSQL y las tablas de grupos operan
separadamente las unas de las otras. Esta separación que los ID de usuarios y
grupos puedan ser idénticos dentro del sistema PostgreSQL.
Y para la eliminación de un grupo se usa el comando SQL DROP GROUP. Su
sintaxis es:
DROP GROUP nombre_grupo
Para añadir o eliminar un usuario a un grupo se usa el comando SQL ALTER
GROUP, especificando si es para añadirlo ADD y si es para eliminarlo DROP, y
sin son varios usuarios simplemente se separan por ‘,’.
Su sintaxis es:
ALTER GROUP nombre_grupo { ADD | DROP } USER username [, ... ]
3. OTRAS FUNCIONES BÁSICAS DE PostgreSQL
Estas son algunas otras funciones a tener en cuenta para el manejo de bases
de datos en PostgreSQL.
· Abort: Aborta la transacción en curso
· Modificar Grupo:
MODIFICAR GRUPO nombre AÑADIR USUARIO nombre de usuario [, ...
]MODIFICAR GRUPO nombre ELIMINAR USUARIO nombre de usuario [,
... ]
· CREATE TABLE: Crea una nueva tabla
CREATE [ TEMPORARY | TEMP ] TABLE table (
column type
[ NULL | NOT NULL ] [ UNIQUE ] [ DEFAULT value ]
[column_constraint_clause | PRIMARY KEY } [ ... ] ]
[, ... ]
[, PRIMARY KEY ( column [, ...] ) ]
[, CHECK ( condition ) ]
[, table_constraint_clause ]
) [ INHERITS ( inherited_table [, ...] ) ]
· Modificar Tabla:
MODIFICAR TABLA tabla [ * ]
AÑADIR [ COLUMNA ] columna tipo
MODIFICAR TABLA tabla [ * ]
MODIFICAR [ COLUMNA ] columna { SET DEFAULT valor | DROP
DEFAULT }
MODIFICAR TABLA tabla [ * ]
RENOMBRAR [ COLUMNA ] columna A nueva columna
MODIFICAR TABLA tabla
RENOMBRAR A nueva tabla
· Modificar usurario:
MODIFICAR USUARIO nombre de usuario[ WITH PASSWORD ’palabra
clave’ ][ CREATEDB | NOCREATEDB ][CREATEUSER |
NOCREATEUSER][ VALID UNTIL ’abstime’ ]
· BEGIN: comienza una transacción en modo encadenado
BEGIN [ WORK | TRANSACTION ]
· CLUSTER:
CLUSTER indexname ON table
· COMMIT: Realiza la transacción actual.
COMMIT [ WORK | TRANSACTION ]
· COPY: Copia datos entre ficheros y tablas.
COPY [ BINARY ] table [ WITH OIDS ]FROM { ’filename’ | stdin }[ [USING]
DELIMITERS ’delimiter’ ][ WITH NULL AS ’null string’ ]COPY [ BINARY ]
table [ WITH OIDS ]TO { ’filename’ | stdout }[ [USING] DELIMITERS
’delimiter’ ][ WITH NULL AS ’null string’ ]
· CREATE AGGREGATE: Define una nueva función de agregado
CREATE AGGREGATE name [ AS ] ( BASETYPE = data_type [ ,
SFUNC1 = sfunc1, STYPE1 = sfunc1_return_type ][ , SFUNC2 = sfunc2,
STYPE2 = sfunc2_return_type ][ , FINALFUNC = ffunc ][ , INITCOND1 =
initial_condition1 ][ , INITCOND2 = initial_condition2 ] )
· CREATE DATABASE: Crea una nueva base de datos.
CREATE DATABASE name [ WITH LOCATION = ’dbpath’ ]
· CREATE FUNCTION: Crea una nueva función.
CREATE FUNCTION name ( [ ftype [, ...] ] )
RETURNS rtype
[ WITH ( attribute [, ...] ) ]
AS obj_file , link_symbol
LANGUAGE ’C’
· CREATE INDEX: Crear un índice secundario.
CREATE [ UNIQUE ] INDEX nombre_indice ON tabla
[ USING nombre_acceso ] ( columna [ nombre_operador] [, ...] )
CREATE [ UNIQUE ] INDEX nombre_indice ON tabla
[ USING nombre_acceso ] ( nombre_funcion( r">columnale> [, ... ])
nombre_operador )
· CREATE TRIGGER: Crea un nuevo disparador
CREATE TRIGGER name
{ BEFORE | AFTER } { event
[OR ...] } ON table
FOR EACH { ROW | STATEMENT } EXECUTE PROCEDURE
ER">funcBLE>
( arguments )
· DELETE: Borrar filas de una tabla
DELETE FROM table [ WHERE condition ]
· DROP AGGREGATE: Elimina la definición de una función agregada
DROP AGGREGATE name type
· DROP DATABASE: Elimina una base de datos existente
DROP DATABASE name
· DROP TABLE: Eliminar tablas de una base de datos
DROP TABLE nombre [, ...]
· DROP TRIGGER: Eliminar la definición de un disparador
DROP TRIGGER nombre ON tabla

3.1.1

Transacción (base de datos)

Una transacción en un Sistema de Gestión de Bases de Datos
(SGBD), es un conjunto de órdenes que se ejecutan formando una
unidad de trabajo, es decir, en forma indivisible o atómica.

Un SGBD se dice transaccional, si es capaz de mantener la
integridad de los datos, haciendo que estas transacciones no puedan
finalizar en un estado intermedio. Cuando por alguna causa el sistema
debe cancelar la transacción, empieza a deshacer las órdenes
ejecutadas hasta dejar la base de datos en su estado inicial (llamado
punto de integridad), como si la orden de la transacción nunca se
hubiese realizado.
La Recuperación deinformacion por medio de Transiciones

vence los defectos de recuperación tradicionales eliminando el tiempo
de indisponibilidad y evitando la pérdida de datos buenos. La
Recuperación de Transacción es “el proceso de borrar los efectos
indeseados de transacciones específicas de la base de datos”. La
recuperación tradicional está en el nivel de objeto de base de datos:
por ejemplo, en el espacio de datos, espacio de mesa o nivel de
índice. Realizando una recuperación tradicional, un objeto de base de
datos específico es elegido. Entonces, una copia de seguridad de
aquel objeto es aplicada, seguida volviendo a aplicar entradas de
registro para cambios que ocurrieron después de que la copia de
imagen fue tomada. Recuerde que todos los cambios hechos a una
base de datos relacional son capturados en el registro de base de
datos. De este modo, si los detalles de cambio pueden ser leídos del
registro, la recuperación puede ser conseguida invirtiendo el impacto
de los cambios registrados.

Una de las formas de la Recuperación de Transacción es el Registro
la recuperación de transacción basada toma dos forma: DESHAGA la
recuperación o REHAGA la recuperación. Para DESHACEN la
recuperación, el registro de base de datos es leído para encontrar las
modificaciones de datos que fueron aplicadas durante un margen de
tiempo dado y : el ENCARTE es girado en BORRAR. La
ACTUALIZACIÓN es girada para ACTUALIZAR al viejo valor en
Efecto, una recuperación DESHARÉ invierte modificaciones de base de datos usando SQL. 
DESHAGA la Recuperación de Transacción es
la recuperación de base de datos en línea. Por supuesto, si es
deseable conservarse la base de datos en línea durante una
Recuperación de Transacción dependerá en la naturaleza y la
severidad del problema de base de datos.

El segundo tipo de la Recuperación de Transacción es REHACEN la
Recuperación de Transacción. Ya que el proceso REHACER no
genera las transacciones de problema, realizando una recuperación y
luego ejecutando REHACER SQL puede restaurar los datos a un
estado corriente que no incluye las transacciones de problema. Una
Recuperación de Transacción REHARÉ requiere una interrupción para
la recuperación de HOYO. Rehaciendo transacciones en un ambiente
donde la disponibilidad es crucial, la base de datos puede ser rebajada
durante la recuperación de HOYO y cuando hecho, la base de datos
puede devuelto en línea. Rehacer subsecuente de las transacciones
válidas para completar la recuperación puede ser hecho con los datos
en línea, así reduciendo el tiempo de indisponibilidad de aplicación.

La Recuperación de Transacción permite que un usuario recupere una
parte específica de los datos basados en criterios definidos por el
usuario. Una recuperación tradicional es realizada objeto por el objeto
por la base de datos. Una transacción es un juego de operaciones
relacionadas que, cuando agrupado juntos, definen una unidad lógica
del trabajo dentro de una aplicación. Las transacciones son definidas
por la vista del usuario del proceso. Mientras la Recuperación de
Transacción puede parecer a la respuesta a todos sus problemas de
recuperación de base de datos, hay tiempos cuando no es posible o
no aconsejable. El coste tenía que equilibrar contra el coste de
exploraciones largas de los juegos de datos de registro para aislar
datos para deshacer y el coste de aplicación de aquellos datos usando
SQL.

La solución de recuperación de base de datos última debería analizar
su ambiente total y las transacciones que tienen que ser recuperado, y
recomendar que el tipo de la recuperación funcionar. Además, esto
debería generar automáticamente los empleos apropiados para
realizar la recuperación para evitar los errores que están seguros para
ser introducido con escrituras a mano desarrolladas y empleos.

Protocolo de prevención de
Bloqueo por adelantado: obliga a que las
transacciones bloqueen todos los elementos que
necesitan por adelantado. En caso de no poder
conseguir todos esos elementos no bloquea
ninguno y se queda en espera hasta volver a
intentarlo.
Ordenación: Ordena todos los elementos de la
base de datos y una transacción que necesite
varios de esos elementos los bloqueará en ese orden. Esto no es muy práctico.
B. Manejo de 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.

Técnicas de bloqueo sobre Base de Datos: Bloqueo Pesimista y
Bloqueo Optimista
10 enero 2011 — Luis Miguel Gracia Luis

Bloqueo pesimista

El bloqueo pesimista es la técnica por la cual los datos son
bloqueados previos a su modificación para evitar que nadie los
modifique. Una vez que los datos a actualizar han sido bloqueados la
aplicación puede acometer los cambios, con commit o rollback, en ese
caso el bloqueo es automáticamente eliminado. Si alguien intenta
adquirir un bloqueo de los mismos datos durante el proceso será
obligado a esperar hasta que la primera transacción finalice.

Esta técnica es muy simple pero tiene dos problemas fundamentales:

Ø Bloqueo: un usuario selecciona un registro para actualizar, y
entonces abandona la operación. Todos los usuarios que necesitan
actualizar ese registro tienen que esperar hasta que se complete la
transacción, o hasta que se mate y finalice el bloqueo.

Ø Deadlock: Si los usuarios A y B están ambos actualizando la base
de datos a la vez y A bloqueo un registro e intenta adquirir un bloqueo
mantenido por B, que a su vez está esperando a adquirir un bloqueo
mantenido por A ambas transacciones quedarían en espera
indefinidamente, dando lugar a un Deadlock.

En general los Sistemas RDBMS ofrecen cláusulas para este bloqueo.
Oracle soporta bloqueo pesimista a nivel de fila. La sentencia estándar
para el bloqueo es SELECT FOR UPDATE que hace que todas las
sentencias UPDATE o SELECT FOR UPDATE de otras conexiones se
bloqueen hasta que un commit, rollback o deadlock se produzca. Se
produce un deadlock cuando un usuario que tiene la fila A bloqueada
intenta bloquear la fila B, mientras que otro usuario tiene la fila B
bloqueada e intenta bloquear la A. En este caso Oracle deshabilita uno
de los bloqueos del usuario permitiendo al otro usuario bloquear
ambas filas.

Oracle además tiene el bloqueo SELECT FOR UPDATE NO WAIT, de
modo que Oracle causará una excepción cuando una fila bloqueada
es seleccionada. Esto puede ser útil si no se quiere bloquear un
usuario para un tiempo indefinido.

Bloqueo optimista con control de concurrencia

El bloqueo optimista no bloquea los registros que se van a actualizar
y asume que los datos que están siendo actualizados no van a
cambiar desde que se han leído. Puesto que en nuestro caso no se
puede asumir esto es necesario un control de la concurrencia, de
esta manera el bloqueo optimista con control de
concurrencia asegura que los datos que están siendo escritos son
consistentes con los leídos en primera instancia, es decir que ninguna
otra transacción ha actualizado los datos después de la lectura. El
procedimiento para asegurar la consistencia es muy sencillo: se leerá
un valor junto al registro, se actualizará ese valor a la BD cuando el
registro es actualizado.

Existen varios mecanismos asegurar el control de la concurrencia, el
más común es el uso de un timestamp modificado. Este mecanismo
sólo ofrece una resolución de un segundo.

Bloqueo y Motores ORM

Hibernate, y en general los motores de persistencia, y por supuesto
JPA soportan el bloqueo optimista simplificando su uso. Algunos
motores como Hibernate o JPA 2 soportan incluso el bloqueo
pesimista.
En este post hay un artículo sobre cómo gestiona JPA 2 la
concurrencia.
Técnicas de bloqueos
impidiendo a otros usuarios la recuperación o
actualización de los elementos bloqueados.