Dba PostgreSQL

Academia De Software Libre www.codigolibre.
org
__________________________________________________________
PostgreSql
________________________________________
2010 Manual De Administracin de PostgreSql
1
Academia De Software Libre www.codigolibre.org
__________________________________________________________
Clase de Administracin
PostgreSql
Documentacin Realizada Por:
Ing. Jose Paredes Meidy Alvarez

DBA-Senior DBA-Junior
________________________________________
2
__________________________________________________________
NDICE
Dedicatoria..........................................................................................................5
Copyright.............................................................................................................6
Prefacio.................................................................................................................6
Qu se espera de un SGBD?...............................................................................7
Qu exigiremos a un SGBD?..............................................................................7
Gestin de los Recursos del kernel.......................................................................7
psql.......................................................................................................................8
Aplicaciones servidor...........................................................................................8
Arquitectura .........................................................................................................8
El proceso Postmaster..........................................................................................9
La memoria compartida.......................................................................................9
Almacenamiento fsico.........................................................................................9
Ficheros................................................................................................................9
Otros ficheros.......................................................................................................9
Directorios..........................................................................................................10
Creacin del cluster de bases de datos: initdb....................................................10
Creacin del cluster............................................................................................11
Modificacin de template1 + aadir extensiones-contrib..................................12
Puesta en marcha y parada del servidor.............................................................12
Internacionalizacin y localizacin....................................................................13
Ventajas..................................................................................................13
Para ver cmo est configurado en el SO ejecutar.............................................13
Procesamiento de instrucciones.........................................................................14
Gestin de transacciones....................................................................................15
Atomicidad (atomicity)...........................................................................15
Consistencia (consistency)......................................................................15
Aislamiento (isolation)............................................................................16
Persistencia (durability)..........................................................................16
Seguridad en PostgreSQL..................................................................................17
Seguridad en la manipulacin de los ficheros....................................................17
Respecto a las conexiones locales va sockets...................................................17
Seguridad en el acceso de los clientes................................................................18
Conexin local: usando los sockets del dominio Unix......................................18
Conexin remota sin encriptar usando TCP/IP (SSL y no SSL)........................19
Conexin remota encriptada SSL usando TCP/IP (solo SSL)...........................19
Esquema lgico..................................................................................................23
Creacin de roles (usuarios)...............................................................................24
Listando Usuarios..............................................................................................27
Modificando Usuarios.......................................................................................27
Permitir Usuario crear BD.................................................................................29
Cambiando Nombre a un Usuario......................................................................29
Cambiar contrasea...........................................................................................29
Eliminando Usuario............................................................................................29
Creando Grupo...................................................................................................29
Agregando o eliminando un Usuario de Grupo..................................................30
Viendo los Grupos..............................................................................................30
________________________________________
3
__________________________________________________________
Re-Nombrando Grupo........................................................................................30
Eliminando Grupo..............................................................................................31
Creacin de tablespaces.....................................................................................31
Creacin de bases de datos.................................................................................32
Esquemas............................................................................................................33
Permisos.............................................................................................................34
Asignando Privilegios........................................................................................35
Quitando Privilegios...........................................................................................35
Cambiando EL propietario de una tabla.............................................................43
Listar los Objetos en Schema Public..................................................................44
Permisos y Seguridad en Schema.......................................................................45
Eliminando Schema............................................................................................45
Funciones de Schema.........................................................................................45
Esquemas especiales...........................................................................................46
Limitaciones.......................................................................................................46
Administrar privilegios de copia de seguridad...................................................46
Administrando desde GNU/Linux......................................................................48
Iniciando postmaster...........................................................................................49
Autentificacin de Usuarios...............................................................................50
Creacin de una base de datos............................................................................50
Acceso a la base de datos...................................................................................51
Bases de datos grandes.......................................................................................52
Tratamiento de problemas..................................................................................53
Tareas administrativas: Copias de seguridad y recuperacin.............................53
Copy...................................................................................................................53
Mantenimiento del fichero de seguimiento........................................................55
Copias de seguridad............................................................................................55
Copias de seguridad de ficheros del SO.............................................................56
Desventajas de este mtodo................................................................................56
Volcado SQL......................................................................................................56
Recuperacin con psql........................................................................................58
Recuperacin con pg_restore.............................................................................58
Scripts Basico de hacer Backup.........................................................................62
Crontab...............................................................................................................62
Qu es cron?..........................................................................................62
Iniciar cron..............................................................................................62
Usando cron.............................................................................................63
Ejecutando Cron con mltiples usuarios, comando crontab...................64
Controlando el acceso a cron...................................................................65
COMANDO chkconfig.....................................................................................66
Fallos en memoria secundaria (disco)................................................................67
Volcado en lnea y recuperacin PITR...............................................................67
Tareas administrativas: Vacuum ...................................................................69
AUTOVACUUM...............................................................................................70
Reindex...............................................................................................................70
Monitorizacion...................................................................................................71
________________________________________
4
__________________________________________________________
Dedicatoria
Una mencin de forma especial para Antonio Perpin, Fundador del
Movimiento de Software Libre en Repblica Dominicana y en Amrica
Latina, persona de grandes principios y vastos conocimientos. No todo
hombre tiene el valor de aprender y mucho menos de ensear, por eso sea
siempre bendecido por su calidez y gran visin. El objeto ms noble que
puede ocupar el hombre es ilustrar a sus semejantes.
Meidy E. Alvarez Guerrero
________________________________________
5
__________________________________________________________
Copyright
Esta documentacin es regida por los reglamentos de la GNU Free Documentation

License y la GNU General Public License v3, sintase libre de copiar, modificar,
aprender, distribuir y redistribuir esta documentacin; haga uso de su derecho como si
fuere su deber.
Prefacio
En estas paginas se plasma de manera Teorico/Practico los conocimientos necesarios para
convertirse en un Administrador de Base de Datos, usando Postgresql; la finalidad es instruir de
manera interactiva todo lo que se debe saber para un manejo eficiente de Postgresql, y aplicarlos a
este y otros motores libres. Esta es una etapa de varias en este camino hacia la carrera profesional
de la administracin de base de datos y anlisis de estructuras de almacenamiento de
registros de datos.
________________________________________
6
__________________________________________________________
Qu se espera de un SGBD?
De un Sistema de Gestin de Bases de Datos esperamos:
Permita a los usuarios crear otras bases de datos y especificar su esquema por medio de
algn lenguaje de definicin.
Ofrezca a los usuarios la capacidad de consultar los datos y modificarlos, usando para ello
un lenguaje de consulta y manipulacin.
Brinde soporte al almacenamiento de cantidades voluminosas de datos durante un largo

perodo, protegindolo contra accidentes o utilizacin no autorizada.
Controle el acceso concurrente.
Qu exigiremos a un SGBD?
Para optar por un buen SGBD debe estudiar su:
Escalabilidad: Capacidad de mejorar con el incremento de los recursos invertidos.
Portabilidad: Exportacin e importacin de datos de una plataforma a otra.
Rendimiento: Recuperacin, actualizacin, concurrencia, etc. de una manera eficiente.
Universalidad: Mltiples tipos de datos (multimedia).
Disponibilidad: 7x24.
Aplicaciones clientes.
Gestion de los Recursos del kernel:

La instalacin de PostgreSQL requiere la comprobacin de que el servidor ser capaz de
soportarlo.
Normalmente, los valores por defecto son ms que suficientes. Estos recusos afectan a la
memoria compartida y a los semforos. Ser tarea del administrador de sistemas cambiar los
valores de los parmetros si es necesario. Si el sistema no puede proporcionar los recursos
que requiere el servidor, ste no se puede poner en marcha y devuelve un error. Para una
instalacin normal, los valores por defecto son suficientes.
Parmetros de PostgreSQL que afectan a la memoria compartida:
Corresponden con una rden de SQL ejecutadas dentro de la base de

datos, para saber ms detalles, consultar el manual de cada programa tal como se hace en
Linux / Unix:
clusterdb: equivalente al comando CLUSTER de SQL, reorganiza cluster de

tablas.
createdb:crea una base de datos.
createlang: define un nuevo lenguaje procedural en una base de datos.
createuser: creacin de usuarios.
________________________________________
7
__________________________________________________________
dropdb: borrar una base de datos.

droplang: borrar un lenguaje procedural.
dropuser: borrar un usuario.
ecpg: SQL C preprocesador embebido.
pg_config: recupera informacin sobre la versin instalada de PostgreSQL.
pg_dump: extrae una base de datos en un fichero script o en otros formatos.
pg_dumpall: extrae un cluster de base de datos en un fichero script.
pg_restore: restaura una base de datos desde un fichero creado con pg_dump.
psql:
Terminal interactivo de PostgreSQL. Es la herramienta cannica para la ejecucin de
sentencias SQL a travs del shell del SO. Es una herramienta de tipo frontend que permite
describir sentencias SQL, ejecutarlas y visualizar sus resultados. El mtodo de ingreso
puede ser mediante la insercin directa del cdigo en la consola, o la ejecucin de
sentencias dentro de un archivo de texto. Provee de diversos meta-comandos para la
ejecucin de las sentencias, as como diversas opciones tipo shell propias de la herramienta.
reindexdb: reindexa una base de datos.
vacuumdb: reorganiza y analiza una base de datos.
Aplicaciones servidor:
initdb: crea un cluster de base de datos.
ipcclean: libera la memoria compartida y los semforos de un servidor PostgreSQL.
pg_controldata: muestra informacin de control de un cluster de base de datos.
pg_ctl: inicia, para o reinicia un servidor PostgreSQL.
pg_resetxlog: reinicia el write-ahead log y otras informaciones de control de un
cluster de base de datos.
postgres: corre un servidor PostgreSQL en modo "single-user".
postmaster: servidor de base de datos PostgreSQL multiusuario.
Arquitectura
PostgreSQL funciona con una arquitectura Cliente/Servidor, un proceso servidor
(postmaster) y una serie de aplicaciones cliente que realizan solicitudes de acciones contra
la base de datos a su proceso servidor. Por cada una de estas aplicaciones cliente, el proceso
postmaster crea un proceso postgres.
El proceso Postmaster:
Es el proceso inicial. Gestiona los accesos multiusuario y multiconexion. Levanta la
memoria compartida. Esta al tanto de solicitudes de nuevas conexiones. Lanza procesos de
atencion de demanda, realizando las operaciones sobre la base de datos a solicitud de los
clientes. Realiza el enlazado con los archivos de datos, gestionando estos ficheros, donde los
ficheros
pueden pertenecer a varias bases de datos.
La comunicacion entre BackEnd/FrontEnd se realiza mediante TCP/IP, normalmente por el

puerto 5432, creando un socket (/tmp/.s.PGSQL.5432).
________________________________________
8
__________________________________________________________
La memoria compartida:
Gestiona los recursos entre procesos backend. Gestiona la cache del disco,
maneja otras estructuras internas. De esta manera podemos definir el concepto de
CLUSTER DE BASE DE DATOS, como una instancia de PostgreSQL, donde se lanza un
proceso postmaster, que puede gestionar varias bases de datos. En un servidor, pueden haber
varios cluster, cada uno tendra su postmaster, y cada postmaster escuchara por un puerto
diferente.
Nota: no confundir este concepto de cluster con los tipicos que se manejan en bases de
datos de base de datos en cluster o tablas en cluster.
Almacenamiento fisico:
En un servidor se crean uno o varios clusters de bases de datos. La estructura fisica del
cluster se crea con el programa initdb, con este programa se determina la ubicacion fisica y
el juego de caracteres.
En las instalaciones automticas a partir de paquetes (rpm, apt-get, etc) o en Windows, se

crea un cluster automticamente con tres bases de datos, template0, template1 y postgres. El
cluster se crea en un directorio data dentro del directorio donde se ha instalado postgres.
Normalmente, se define una variable de entorno, PGDATA que apunte al directorio donde
se crea el cluster.
Ficheros:
postgresql.conf: fichero de configuracion principal, contiene la asignacion a los
parametros que configuran el funcionamiento del servidor.
pg_hba.conf: fichero de configuracion de la autenticacion de los clientes y usuarios

y del acceso a las bases de datos del cluster.
pg_ident.conf: fichero accesorio al anterior, determina como se realiza la

autenticacion ident que contiene la correspondencia entre usuarios del Sistema
Operativo y de PostgreSQL.
PG_VERSION: fichero de texto con la version de software Postgres que crea el

cluster .
Otros ficheros:
postmaster.pid: se crea cuando el postmaster arranca, contiene el PID del proceso
postmaster.
postmaster.opts: contiene las opciones con las que se ha iniciado el postmaster.
recovery.conf, recovery.done: si se quiere o se ha hecho una recuperacion.
________________________________________
9
__________________________________________________________
Directorios:
base: las plantillas y las bases de datos. contiene un directorio por cada base de
datos, dentro hay un fichero por cada tabla o indice de una base de datos, los
numeros corresponden a los OIDs de las tablas o indices.
template0 (1): contiene las definiciones de las tablas del sistema, vistas, funciones y
tipos estandar. Nunca se debe modificar ni intentar conectarse a ella, ya que esta por
si template1 se corrompe.
template1 (N): base de datos plantilla para crear nuevas bases de datos, se puede
modificar su estructura, anadiendo tablas, indices, funciones, etc. Es la que se usara
como plantilla para crear otras bases de datos.
global: tablas e indices del catlogo comunes a todas las bases de datos.
catalogo compartido: pg_shadow (usuarios), pg_database, etc.
pgstat.stat: fichero usado por el monitor de estadsticas.
pg_control: fichero con parmetros del cluster, algunos inmutables (establecidos en

la creacin del cluster) y otros variables (establecidos en la puesta en marcha).
pg_log: ficheros de seguimiento del servidor. Se crea en la versin de Windows, en

la de Linux, se debe indicar al arrancar el postmaster en qu fichero se hace el
seguimiento.
pg_xlog: ficheros de diario del servidor (WAL).

Contiene los diarios de escritura adelantada, para usarlos en las recuperaciones. Se
implementan como un conjunto de segmentos (ficheros) de un tamao de 16Mb y
divididos en pginas de 8Kb.
pg_clog: ficheros de diario para las transacciones (estado de cada transaccin).

Contiene los ficheros de confirmacion. Un diario de confirmacin refleja el estado de
cada transaccin: confirmada, en progreso o abortada.
pg_multixact: contiene datos sobre el estado multi-transaccional, usado para los

bloqueos compartidos de filas.
pg_twophase: ficheros de estado para las transacciones preparadas.
pg_subtrans: para realizar los savepoints en medio de transacciones.
pg_tblspc: informacin sobre los tablespaces. Cuidado porque en linux/unix

contiene enlaces a los directorios donde se crean los tablespaces y hay que controlar,
en caso de cambios de ficheros, que estn correctos.
Creacin del cluster de bases de datos: initdb

Despus de instalar PostgreSQL, lo primero que hay que realizar es la creacin de un
cluster, teniendo en cuenta que en un servidor, se pueden crear todos los cluster que se
quieran.
________________________________________
10
__________________________________________________________
Creacion del cluster:
Ya vimos en un punto anterior cmo se crea un cluster de base de datos, por ejemplo, en
este curso, vamos a crear el siguiente cluster:
initdb --pgdata=$PGDATA --encoding=LATIN1 --locale=es_ES
Con este proceso se han creado tres bases de datos: template0 (que ya se ha dicho que no se
debe modificar ni debemos conectarnos a ella), template1 y postgres.
Al terminar de crear el cluster nos responde que ya podemos iniciar el postmaster de este
cluster de dos modos:
$ postmaster -D $PGDATA
o
pg_ctl -D $PGDATA -l $PGLOG start
Lo hacemos del segundo modo, ahora, una vez arrancada la instancia, podemos conectarnos
desde nuestro servidor a la base de datos usando el psql:
Si queremos parar el servidor:
$ pg_ctl stop
--Siqueremos ver la informacion inicializada por initdb:
[postgres@jp ~]$pg_controldata data/
pg_control version number: 843

Catalog version number: 200904091
Database system identifier: 5470533823675219895
Database cluster state: in production
pg_control last modified: Sat 05 Jun 2010 10:59:44 AM AST
Latest checkpoint location: 0/2E23574
Prior checkpoint location: 0/2BBB43C
Latest checkpoint's REDO location: 0/2E23574
Latest checkpoint's TimeLineID: 1
Latest checkpoint's NextXID: 0/3448
Latest checkpoint's NextOID: 35751
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0
Time of latest checkpoint: Sat 05 Jun 2010 10:57:32 AM AST
Minimum recovery ending location: 0/0
Maximum data alignment: 4
Database block size: 8192
Blocks per segment of large relation: 131072
WAL block size: 8192
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in an index: 32
Maximum size of a TOAST chunk: 2000
Date/time type storage: 64-bit integers
________________________________________
11
__________________________________________________________
Float4 argument passing: by value

Float8 argument passing: by reference
Modificacion de template1 + aadir extensiones-contrib:
Hay que tener en cuenta ciertos aspectos antes de empezar a trabajar con nuestras bases de
datos.
template1 es una plantilla para crear otras bases de datos, conviene que, antes de crear
nuevas bases de datos, la completemos con todos aquellos elementos que consideremos que
deben estar en todas las bases de datos que creemos, lenguajes, mdulos opcionales
(tsearch2, lo, dblink, etc), tablas comunes, etc. Ms adelante veremos cmo se instalan estas
opciones.
va a ser postgres nuestra base de datos o la reservamos para pruebas o como plantilla y no
usamos template1?, vamos a crear ms bases de datos?
Para modificar template1 no hay ms que conectarse a ella y ejecutar los scripts de base de
datos que hagan falta.
Por ejemplo, las bases de datos se suelen crear sin lenguajes, no existe el plpgsql, para
instalarlo, ejecutamos desde el sistema operativo:
$ createlang plpgsql template1
$ createlang plpgsql postgres
Lo ejecutamos tambin en postgres para que tenga las mismas opciones.
Pero adems, en el mundo del software libre se crea cdigo para aadir nuevas
funcionalidades. Estos mdulos los hemos aadido, por ejemplo, en la instalacin de
PostgreSQL en Windows, pero no en la de Linux, para poder instalarlos hay que ir al
directorio $PGSRC/contrib.
En $PGSRC/contrib hay un fichero README que indica el uso de cada una de estas
opciones.
Ejemplos de opciones que se tienen que instalar segn los requerimientos de las
aplicaciones:
tsearch2: soporte para indexacin usando GiST
lo: mantenimiento de tipos de datos LOB
vacuumlo: vacuum para objetos LOB
dblink: poder ejecutar sentencias en otras bases de datos
Puesta en marcha y parada del servidor:
La puesta en marcha del servidor se puede hacer de forma manual con dos comandos:
pg_ctl: facilidad para la puesta en marcha, parada y reconfiguracin del servidor. Hace uso
________________________________________
12
__________________________________________________________
de la instruccin que acta sobre el servidor postgres.
postmaster: proceso servidor de base de datos.
El comando pg_ctl es el que se usa normalmente, porque permite controlar ms aspectos

que el comando postmaster.
Operaciones:
start: puesta en marcha del servidor.
stop: parada del servidor.
restart: parada del servidor seguida de puesta en marcha.
reload: envia al postmaster una senal SIGHUP, que provoca que recargue toda
la informacion de configuracion. Algunas opciones de configuracion requieren
parar el servidor.
status: comprueba si hay un postmaster en marcha y muestra el PID y sus

opciones de puesta en marcha.
kill, register, unregister: opciones para la version de Windows para matar,

registrar como servicio o eliminar el servicio.
Internacionalizacin y localizacin:
Internacionalizacin: proceso de desarrollo de software de forma que pueda ser usado en
distintas ubicaciones.
Localizacin: proceso de adaptacin de una aplicacin para que sea usada en una ubicacin
especfica.
Ventajas:
1 Mensajes en varios idiomas.

2 Mensajes en varios juegos de caracteres.
3 Visualizacion de datos de usuario en diversos juegos de caracteres.
4 Diversos tipos de ordenaciones.
5 Clasificacion de caracteres: mayusculas, puntuacion, acentos, etc.
Para ver cmo est configurado en el SO ejecutar:
$ locale
Que nos mostrar la configuracin activa, podemos cambiar la configuracin entre

cualquiera de las que estn instaladas en el sistema operativo, para ver cules estn
disponibles:
$ locale -a
En cuanto a los juegos de caracteres:

Soporta distintos tipos: byte simple o multibyte.
________________________________________
13
__________________________________________________________
el cluster puede estar en un conjunto de caracteres y la base de datos en otro:
$ initdb -E unicode
$ createdb -E latin1 base1
SQL# create database base2 with encoding win ;
Se produce una conversin automtica entre servidor / cliente (en la tabla pg_conversion
estn las conversiones por defecto.
Procesamiento de instrucciones:
Se produce un dilogo bsico entre el proceso front-end (aplicacin) y el proceso back-end
(postgres), que consta bsicamente de los siguientes pasos:
1. La aplicacin enva una instruccin al proceso postgres.
2. El servidor realiza en anlisis y el proceso postgres responde OK o devuelve error.
3. La aplicacin solicita la ejecucin y el servidor la realiza, devolviendo Ok o error.
4. Por ltimo la aplicacin solicita la recuperacin de los datos y el servidor responde con
los resultados de la instruccin.
Para el procesamiento de instrucciones PostgreSQL usa la cach de la base de datos (shared

buffers), coleccin de buffers de 8Kb en la memoria compartida y que sirven como cach de
las pginas de los ficheros y sentencias que se han usado recientemente. Esta memoria se
reserva cuando se pone en marcha el servidor.
Los bloques de buffers modificados se llaman "sucios" y se colocan en una lista sucia. La
lista sucia controla todas las modificaciones de datos que se hacen en la cach y que no se
han vaciado al disco. La lista sucia se vaca, por ejemplo, cuando se produce un punto de
control (checkpoint) o simplemente se llena la lista.
Si la instruccin es una consulta, el servidor siempre lee primero si tiene estos bloques de
datos en la cach, en caso contrario, los lee del disco y los copia a la cache, realizando esta
operacin tantas veces como sea necesario para ejecutar una instruccin.
Si la instruccin es una actualizacin de datos entran en juego tambin los ficheros de diario
(WAL) y los buffers de diario (buffers WAL). Por ejemplo, al ejecutar un Update de una
fila:
1. Mirar si los datos estn en los buffers compartidos y recuperar el valor antiguo.
2.Si no estn recuperalos de los ficheros de datos y ponerlos en los shared buffers.
3.Se escribe el valor nuevo en el buffer WAL.
4.Se realiza la modiciacin y se escribe en los shared buffers.
todava no se han escrito los datos en disco!
________________________________________
14
__________________________________________________________
Gestin de transacciones:
PostgreSQL cumple las reglas ACID:
1 Atomicidad (atomicity).
2 Consistencia (consistency).
3 Aislamiento (isolation).
4 Persistencia (durability).
Atomicidad:
La palabra se deriva de tomo, que significa indivisible; como indivisibles son cada una de
las operaciones contenidas dentro de una transaccin. Una transaccin es un bloque de
operaciones o instrucciones dirigido a modificar una base de datos en una determinada
direccin.
En realidad, lo importante aqu, es que se cumpla la regla de todo o nada. Si todas las
operaciones se realizan con xito, los resultados producidos por la transaccin se guardan en
la base de datos. Si alguna operacin falla, todas las operaciones son deshechas (rollback),
incluso aunque alguna operacin haya sido realizada con xito.
Solucin
En PostgreSQL podemos hacer que un grupo de sentencias SQL se ejecuten dentro de una
transaccin, encerrndolas entre las sentencias BEGIN y COMMIT. De esta forma
aseguramos que se ejecutan todas o ninguna. Si llegados a algn punto dentro de la
transaccin necesitamos deshacerla completamente, utilizamos ROLLBACK, en lugar de
COMMIT, y todos los cambios son deshechos.
Durante las transacciones, existen restricciones diferidas (ser verifican al final de la

transaccin) o inmediatas (se verifican en cada operacin), en este caso, si alguna condicin
no se cumple, la transaccin queda en estado latente, algunas consultas no se pueden
realizar y las actualizaciones no tendrn efecto, con lo que solo se puede resolver
deshaciendo la transaccin.
Por otro lado, PostgreSQL trata cualquier sentencia aislada como si sta se ejecutara dentro
de una pequea transaccin; aunque no usemos BEGIN, cada sentencia incorpora
implcitamente un BEGIN y, si culmina con xito, un COMMIT, a este modo se le conoce
como "modo autoconfirmacin".
Consistencia:
Una base de datos es una herramienta para modelar y registrar una realidad cambiante. Sin
embargo, debe hacerlo consistentemente de acuerdo con unas reglas determinadas o
restricciones de integridad definidas. La realidad modelada as, puede ir cambiando al pasar
de un estado en el que cumple las reglas, a otro en el que tambin las cumple.
Si al ejecutar una transaccin, por el motivo que sea, se incumpliera alguna de estas reglas,
la transaccin no se llegara a completar. Esto garantiza que una base de datos siempre
permanezca en un estado vlido, es decir, consistente con las reglas.
________________________________________
15
__________________________________________________________
Solucion:
A partir de la version 7.0 se anadio gestion de integridad en PostgreSQL, las restricciones

soportadas son:
not null
check
unique
primary key
foreign key, con dos tipos match full (completa) y match partial (si en alguna
columna no hay valores no se comprueba la integridad, aunque esta opcion no esta
implementada)
Solo las instrucciones de clave ajena son diferibles, el resto son inmediatas.
Aislamiento:
Los resultados de una transaccin que est siendo ejecutada, son invisibles a cualquier otra
transaccin hasta que la primera no haya sido completada con xito. La ejecucin no
perturba a otras transacciones que se ejecuten concurrentemente.
Solucin:
Frente a otro modelos tradicionales que controlan el acceso concurrente a los datos a travs
de bloqueos, PostgreSQL utiliza un modelo denominado Multiversion Concurrency Control
(MVCC), segn el cual, al consultar la BD, cada transaccin ve una instantnea de la BD tal
como era hace un cierto tiempo (una versin de la BD) y no el estado actual de la BD. Este
mecanismo evita que una transaccin pueda ver datos inconsistentes modificados por otra.
Aislando las transacciones que operan concurrentemente en distintas sesiones, un lector no
necesita esperar a un escritor; y un escritor no necesita esperar a un lector.
Persistencia o Durabilidad:
La durabilidad garantiza que los efectos resultantes de una transaccin, una vez ha sido
completada con xito, permanecen en la base de datos para siempre, incluso cuando se
puedan producir posteriormente fallos de cualquier clase.
Por ejemplo, si durante una transaccin se produce un apagado del servidor, una vez
reiniciado el servidor, un sistema que lleve un registro de transacciones realizadas,
advertira rpidamente que existe una sin completar, finalizndola correctamente.
Solucin:
PostgreSQL utiliza una tcnica estndar denominada WAL (Write-ahead logging, o

escritura anticipada de registros) para controlar tanto la consistencia como la durabilidad de
las transacciones.
Brevemente explicada, consiste en que los cambios en los ficheros de datos (tablas e
ndices) slo se materializan cuando existe previamente en el disco un registro en el que
estn anotados dichos cambios. Siguiendo este procedimiento, no es necesario enviar
pginas al disco cada vez que una transaccin se completa. Esta tcnica no slo mejora el
rendimiento del servidor, sino que ante un fallo de la mquina, ser posible recuperar la BD
a partir de ese registro: cualquier cambio no aplicado a las pginas de datos en el disco ser
________________________________________
16
__________________________________________________________
nuevamente hecho desde el log (roll-forward recovery, o REDO) mientras que los posibles
cambios realizados en pginas de disco por transacciones incompletas, podrn ser deshechos
manteniendo la integridad y la consistencia de los datos (roll-backward recovery, o UNDO).
Estos ficheros de diario estn en $PGDATA/pg_xlog, son ficheros de 16Mb, divididos en

pginas de 8Kb, el sistema crea uno inicialmente y va creando ms segn las necesidades,
rotando de manera cclica segn marquen los parmetros de sistema que gestionan este
funcionamiento (checkpoint_segments y archive_command).
Siguiendo con la instruccin (update de una fila), al ejecutar un COMMIT se produce:
1. Se escriben los datos del buffer WAL en los ficheros de diario WAL.
2. Se pueden refrescar las copias multiversin en los shared buffers.
3. Se retorna el control a la aplicacin.
Entonces, los datos de los buffers no se han escrito en disco todava, pero los del diario si,
as los datos de la transaccin nunca se pierden.
Seguridad en PostgreSQL:
La seguridad en PostgreSQL se materializa en tres aspectos:
Seguridad en la manipulacin de los ficheros de PostgreSQL.
Seguridad en los accesos de los clientes.
Definicin de los privilegios para acceder a los objetos de la base de datos a los usuarios
PostgreSQL.
Seguridad en la manipulacin de los ficheros:
La informacin ms crtica est en $PGDATA.
Todos los ficheros deben pertenecer al usuario postgres.
El usuario postgres debe ser el nico que pueda:
Leer, escribir y ejecutar sobre los directorios en los ficheros
leer y escribir en los ficheros
Respecto a las conexiones locales va sockets:
Todos los usuarios usan la misma.
Se puede restringir el uso para algunos usuarios del SO.
Ver el directorio /tmp, donde existe un fichero .s.PGSQL.5432 que se crea cuando arranca
el postmaster, los permisos de este fichero son 777, cualquier usuario del SO se puede
conectar. Adems hay un .s.PGSQL.5432.lock que slo puede leer postgres.
________________________________________
17
__________________________________________________________
Los permisos de este socket se pueden configurar en postgresql.conf con los parmetros
unix_socket_directory, unix_socket_group y unix_socket_permission.
Seguridad en el acceso de los clientes:
Es importante poder definir desde qu equipos se pueden conectar a nuestra base de datos,
as como poder definir qu usuarios y a qu bases de datos se pueden conectar.
La configuracin de este nivel de seguridad se realiza en los ficheros pg_hba.conf (hba =

host based authentication) y pg_ident.conf.
Se trata de editar una serie de reglas que se irn procesando de arriba abajo, cuando se
encuentre una regla que cumpla la conexin, se ejecutar lo que ponga en el mtodo.
Conexin local: usando los sockets del dominio Unix:
base_datos:
ALL: se permite la conexin a cualquier base de datos.
SAMEUSER: solo a bases de datos que su nombre sea el mismo que el usuario que se
conecta.
SAMEROLE: solo a bases de datos que su nombre sea el mismo que el role que se conecta.
nombd1, nombd2, : se permite la conexin a cualquiera de las bases de datos de la lista.
@fichero: se permite la conexin a las bases de datos incluidas en el fichero, que debe estar
en el mismo directorio que pg_hba.conf.
usuario:
ALL: se permite la conexin de cualquier role.
role1, [+]role2, : se permite la conexin de los roles de la lista y adems se permite la

conexin de cualquier role que sea miembro de role2.
@fichero: se permite la conexin de los roles incluidos en el fichero, que debe estar en el
mismo directorio que pg_hba.conf.
Mtodo-Autenticacin:
TRUST: conexin aceptada sin condiciones.
REJECT: conexin rechazada sin condiciones.
PASSWORD: se solicita palabra de paso sin encriptar, las palabras de paso se almacenan
en la tabla pg_authid y pueden estar cifradas o no segn como se creara el role.
CRYPT: palabra de paso encriptada (versiones previas a la 7.2).
________________________________________
18
__________________________________________________________
MD5: palabra de paso con el mtodo de encriptacin md5, y se almacena tambin con este
mtodo. Es el mtodo recomendado por PostgreSQL. Se obtiene un cifrado a partir de la ID
de usuario y la palabra de paso, el cliente solicita una semilla al servidor y as se obtiene un
segundo cifrado que es envado al servidor, en el servidor se utiliza la palabra de paso
almacenada, el ID del usuario (la obtiene de la conexin) y la semilla para obtener un
cifrado
similar y los compara.
KRB5: se usa Kerberos v5 para autenticar el cliente, se ha de habilitar en la instalacin del

servidor.
IDENT correspondencia: a partir del usuario de la conexin cliente (se fa de la

autenticacin del cliente) y de la correspondencia indicada en la opcin, se obtiene un role
de PostgreSQL para realizar la conexin. Las correspondencias se obtienen del fichero
pg_ident.conf.
SAMEUSER: el usuario del sistema operativo es el mismo que se conecta a la BD.
Cambio-usuario: el sistema mira el fichero pg_ident.conf, y busca una fila donde est la
correspondencia llamada cambio-usuario y se corresponda con el usuario conectado al
SO, haciendo la conexin a la BD con el usuario con el usuario de la columna usuario-pg.
PAM servicio-pam: autenticacin usando Pluggable Authentication Method proporcionado

por el servicio PAM indicado en opcin. Este mtodo es proporcionado por el SO. Se debe
compilar el servidor con esta opcin. El PAM por defecto es postgresql. Se deben
configurar los mtodos PAM del SO, generalmente basta con incluir la definicin del un
nuevo mtodo en el directorio /etc/pam.d.
Conexin remota sin encriptar usando TCP/IP (SSL y no SSL):

Permite conexiones SSL y no SSL.
La palabra de paso se transmite en texto plano si es no SSL.
direccionCIDR direcccionIP mscara IP: especifica un rango de direcciones IP

192.168.200.0/24 192.168.200.0 255.255.255.0: se pueden conectar todas las IPs de la red
192.168.200
192.168.0.0/16 192.168.0.0 255.255.0.0: todos las IPs de la red 192.168
192.168.200.85/32: solo esa IP
0.0.0.0/0 0.0.0.0 0.0.0.0.: cualquier IP
Conexin remota encriptada SSL usando TCP/IP (solo SSL):

La transmisin cliente-servidor es encriptada.
Los registros HOST se utilizarn para conexiones remotas no-SSL y SSL.
Los registros HOSTSSL slo se utilizarn para conexiones remotas SSL.
Requiere instalar PostgreSQL con la opcin SSL, crear los ficheros de firmas y claves y
________________________________________
19
__________________________________________________________
ubicarlos en el lugar correspondiente.

Para configurar el servidor para estas opciones:
SSL tiene que estar instalado en el servidor y en los clientes que se conecten.
PostgreSQL debe estar compilado con la opcin SSL.
El servidor busca en $PGDATA los ficheros server.key (clave privada del servidor, que si
est protegida en el arranque. Hay otro fichero server.crt.
Se usa el comando OpenSSL.
/*****Ejemplos de conexiones remotas*****/
(18:25:48)][postgres:data]$ vim postgresql.conf
--Para poder aceptar conecciones de otras direcciones debemos descomentar listen_address y

cambiar su IP address(localhost) a que sea igual a '*, para que acepte todas las direcciones y
tambien descomentaremos el puerto(port)
#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------
# - Connection Settings -
listen_addresses = '*' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost', '*' = all
# (change requires restart)
port = 5432 # (change requires restart)
max_connections = 100 # (change requires restart)
--Luego de realizar los cambios se debe de reiniciar el sistema

-bash-4.0$ pg_ctl restart
/****AHORA CON EL pg_hba.conf (hba = host based authentication)****/

(19:00:20)][postgres:data]$ vim pg_hba.conf
--Ahora configuraremos el archivo pg_hba.conf la especificacion ya sea de: base de datos,

usuario, IP-address y/o metodo de autenticacion de la cual se le va a permitir conectarce al servidor.
PostgreSQL Client Authentication Configuration File

# ===================================================
#
# Refer to the "Client Authentication" section in the
# PostgreSQL documentation for a complete description
________________________________________
20
__________________________________________________________
# of this file. A short synopsis follows.

#
# This file controls: which hosts are allowed to connect, how clients
# are authenticated, which PostgreSQL user names they can use, which
# databases they can access. Records take one of these forms:
#
# local DATABASE USER METHOD [OPTIONS]
# host DATABASE USER CIDR-ADDRESS METHOD [OPTIONS]
# hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTIONS]
# hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTIONS]
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
host all all ::1/128 trust
--Configuraremos la conexion local IPv4

--Nota: siempre que se realice algun cambio en este archivo hay que ejecutar pg_ctl restart.
/***Queremos que acepte coneccion desde cualquier IP y cualquier usuario pero solo para la DB
sacademico***/
host sacademico all 0.0.0.0/0 password
--Comprobemos la coneccion
-bash-4.0$ psql -U mexy -h 168.100.0.2 sacademico

Password for user mexy:
Timing is on.
psql (8.4.3)
Type "help" for help.
[168:5432/mexy@sacademico][]#
--Otra prueba con diferente IP y usuario
-bash-4.0$ psql -U jparedes -h 192.168.100.2 sacademico

Password for user jparedes:
Timing is on.
psql (8.4.3)
[192:5432/jparedes@sacademico][]>
--Si no cumplimos los parametros nos dira lo siguiente:
-bash-4.0$ psql -U jparedes -h 192.168.100.2 HR

psql: FATAL: no pg_hba.conf entry for host "192.168.100.2", user "jparedes", database "HR", SSL
off
________________________________________
21
__________________________________________________________
/***Aqui especificamos que aceptara coneccion a cualquier DB y de cualquier ip pero siempre con
el usuario mexy'.***/

host all mexy 0.0.0.0/0 md5
--Hagamos la coneccion

Timing is on.
psql (8.4.3)
[192:5432/mexy@sacademico][]#
--Chevere
--Lo mismo pero con diferente IP y DB.
-bash-4.0$ psql -U mexy -h 168.100.0.2 HR

Timing is on.
psql (8.4.3)
[168:5432/mexy@HR][]#
--Pero siempre con el usuario mexy porque si no nos dara el siguiente:

-bash-4.0$ psql -U jparedes -h 168.100.0.2 HR
psql: FATAL: no pg_hba.conf entry for host "168.100.0.2", user "jparedes", database "HR", SSL
off
/***Ahora especificaremos una sola IP(en este caso cualquier IP) con cualquier DB y/o usuario
pero con metodo password.***/

host all all 0.0.0.0/0 password
--Probemos

Timing is on.
psql (8.4.3)
[10:5432/mexy@sacademico][]>
--Nitido!
/*** Practica***/
--Realiza una conexion remota desde tu maquina, con un usuario, IP especifico y el metodo
password.
________________________________________
22
__________________________________________________________
Esquema lgico:
Concepto de Cluster de bases de datos en PostgreSQL:
Repositorio que engloba un conjunto de bases de datos, que contienen objetos que se pueden
guardar en distintos tablespaces y un conjunto de usuarios que se conectan al cluster.
Una base de datos engloba un conjunto de esquemas, los cuales tienen un usuario
propietario. En los esquemas es donde se crean los objetos (tablas, ndices, procedimientos,
vistas, etc.).
Una sesin se abre contra una base de datos.
Con lo que tenemos aqu los tres elementos principales a nivel lgico en un cluster:
Bases de datos: agrupaciones de esquemas. Por defecto, siempre hay tres bases de datos
creadas, template0, template1 y postgres.
Tablespaces: ubicaciones alternativas a la que por defecto tiene el cluster. Por defecto no se
crea ninguno.
Roles: engloba el concepto de usuarios (roles de login) y grupos de permisos (roles de

grupo), estos ltimos son lo mismo que los roles de Oracle. Hasta la versin 8 de Postgres
no se podan anidar roles, ahora si. Por defecto, si al crear el cluster no se ha indicado otro
usuario, se crea el usuario postgres como superusuario.
Todos los usuarios son comunes a las bases de datos del cluster, se pueden conectar con
cualquiera de las bases de datos. En este punto, las bases de datos se comportan como
esquemas de Oracle.
Las bases de datos son independientes entre ellas, no se pueden ver objetos de una base de
datos desde otra base de datos, excepto si se usan dblinks. Esto marca cmo se deben crear
las bases de datos:
Si es un servidor que acoge proyectos separados y no se han de interrelacionar:

separacin en bases de datos distintas.
Si es un servidor de proyectos con recursos comunes: una nica base de datos y distintos
esquemas para cada proyecto.
/****Ejemplo****/
--Viendo los Logs:
--Si queremos ver el history de todos los comandos ejecutados en el plsql:
[[local]:5432/jparedes@HR] [] # \s
[postgres@jp ~]$cat .psql_history
________________________________________
23
__________________________________________________________
--Si queremos modificar el numero de comando en el History:
[[local]:5432/acolon@HR] [] > \set HISTSIZE 50000
--Para ponerlo permanente la colocamos en el archivo oculto .psqlrc:
[postgres@jp ~]$echo "\set HISTSIZE 7000" >> .psqlrc
--Verificamos el mismo:
[postgres@jp ~]$cat .psqlrc

\set PROMPT1 '[%m:%>/%n@%/] [%x] %# ':
\set HISTSIZE 5000
--Siqueremos agregar que cada consulta nos revuelva el tiempo en ejecucion en una
session:
[[local]:5432/postgres@sacademico] [] # \timing
--Si queremos que sea permanente:
[postgres@jp ~]$echo "\timing on" >> .psqlrc
--Desactivar el AUTOCOMMIT:
[postgres@jp ~]$echo "\set AUTOCOMMIT off" >> .psqlrc
--Verificar:
[[local]:5432/postgres@sacademico] [] # \set
AUTOCOMMIT = 'off'
PROMPT1 = '[%m:%>/%n@%/] [%x] %# '
PROMPT2 = '%/%R%# '
PROMPT3 = '>> '
VERBOSITY = 'default'
VERSION = 'PostgreSQL 8.4.4 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC)
4.1.2 20080704 (Red Hat 4.1.2-46), 32-bit'
DBNAME = 'sacademico'
USER = 'postgres'
PORT = '5432'
ENCODING = 'UTF8'
HISTSIZE = '5000'
--Ya podemos hacer uso de COMMIT Y ROLLBACK.
Creacin de roles (usuarios):

En PostgreSQL los usuarios son tipos de roles, el role es el concepto general.
Los roles son globales al cluster, se almacenan en la tabla del catlogo pg_authid y se
pueden consultar en las vistas pg_user y pg_roles.
________________________________________
24
__________________________________________________________
Desde el sistema operativo:
createuser [OPCIN]... [ROL]

Opciones:
-s, --superuser el rol ser un superusuario
-S, --no-superuser el rol no ser un superusuario
-d, --createdb el rol podr crear bases de datos
-D, --no-createdb el rol no podr crear bases de datos
-r, --createrole el rol podr crear otros roles
-R, --no-createrole el rol no podr crear otros roles
-l, --login el rol podr conectarse (predeterminado)
-L, --no-login el rol no podr conectarse
-i, --inherit el rol heredar los privilegios de los roles de
los cuales es miembro (predeterminado)
-I, --no-inherit rol no heredar privilegios
-c, --connection-limit=N lmite de conexiones para el rol
(predeterminado: sin lmite)
-P, --pwprompt asignar una contrasea al nuevo rol
-E, --encrypted almacenar la constrasea cifrada
-N, --unencrypted almacenar la contrasea sin cifrar
-e, --echo mostrar los comandos a medida que se ejecutan
-q, --quiet no escribir ningn mensaje
--help desplegar esta ayuda y salir
--version desplegar informacin de versin y salir
Opciones de conexin:
-h, --host=ANFITRIN nombre del servidor o directorio del socket
-p, --port=PUERTO puerto del servidor
-U, --username=NOMBRE nombre de usuario con el cual conectarse
(no el usuario a crear)
-W, --password pedir contrasea para conectarse
Si no se especifican -s, -S, -d, -D, -r, -R o el ROL, se preguntar
interactivamente.
El comando CREATE USER es ahora un alias de CREATE ROLE, pero con la opcin
LOGIN por defecto.
/****Ejemplo****/
--Primero creamos un usuario:
--Creando Usuario Primero desde el Shell:
[postgres@jp ~]$createuser -W -S -d -r -e pomavid

Password:
CREATE ROLE pomavid NOSUPERUSER CREATEDB CREATEROLE INHERIT
LOGIN;
/***Practica***/
--Explique las opciones utilizadas anteriores y luego cree un usuario que no pueda
--crear usuario, y que tenga un limite de 5 conexiones ?
________________________________________
25
__________________________________________________________
--Creando usuario desde otro usuario con su -:
[postgres@jp ~]$su - postgres -c "createuser --no-superuser --createrole --no-createdb

nitido2 --echo"
Password:
CREATE ROLE nitido2 NOSUPERUSER NOCREATEDB CREATEROLE INHERIT
LOGIN;
/***Practica***/
--Explique la opcion -c y --echo?
CREATE USER:
Tambien puede utilizar el comando CREATE USER SQL, que tiene varias opciones
disponibles con el comando createuser.
CREATE USER username [ [ WITH ]

SYSID uid
| [ ENCRYPTED | UNENCRYPTED ] PASSWORD 'password'
| CREATEDB | NOCREATEDB
| CREATEUSER | NOCREATEUSER
| IN GROUP groupname [, ...]
| VALID UNTIL 'abstime' ]
Forma Simple:
CREATE USER user;
Creara un usuario con ninguna contrasea ni privilegios adicionales. Tambien puede agregar
un usuario a un grupo ya existente y especificar una fecha en la que la contrasea del
usuario expirara. El sysid es como el numero uid de UNIX y postgres tomara un valor
predeterminado adecuado.
template1=# CREATE USER alice WITH PASSWORD 'pAssw0rd';

CREATE USER
template1=# CREATE USER bob VALID UNTIL 'Jan 31 2030';

CREATE USER
Desde el Shell:
CREATEUSER jp
/****Ejemplo****/
--Creado Usuario desde el PSQL:
[[local]:5432/postgres@postgres] [] # CREATE USER pomavid WITH PASSWORD 'plsql'

CREATEDB NOCREATEUSER;
CREATE ROLE
________________________________________
26
__________________________________________________________
/***Practica***/
--Crear un usuario que expire en 3 dia y que su password este encriptado?
Listando Usuarios:
Puedes ver los usuarios en el servidor mediante la seleccion de la tabla de sistema
pg_shadow. Si usted no es un super usuario, no tendra permiso para acceder a esta tabla y
tendra que acceder a la vista pg_user lugar, que es identico, pero muestra la contrasea
como estrellas.
--Vista donde tenemos todos los usuarios almacenados:
[[local]:5432/postgres@postgres] [] # SELECT * from pg_user;
--Vamos a mostrar donde se almancenan las contraseas:
[[local]:5432/postgres@postgres] [] # SELECT * from pg_shadow ;
Modificando Usuarios:
Si desea cambiar un usuario puede utilizar el comando SQL ALTER USER, que es similar
al comando CREATE USER excepto que usted no puede cambiar el sysid.
ALTER USER name [ [ WITH ]

[ ENCRYPTED | UNENCRYPTED ] PASSWORD 'password'
| CREATEDB | NOCREATEDB
| CREATEUSER | NOCREATEUSER
| VALID UNTIL 'abstime' ]
/****Ejemplo****/
--Cambiando contrasea de un usuario:
[[local]:5432/postgres@postgres] [] # ALTER USER pepe WITH PASSWORD 'pomavid';
--Creacion de Roles:
CREATE ROLE General ;
CREATE ROLE Coronel ;
CREATE ROLE Cabo ;
CREATE ROLE Henry ;
--Agregamos un comentario a un ROLE, igual para otro Objeto

COMMENT ON ROLE henry IS 'Este Role es el pela papa';
--Ahora vamos a crear los Usuarios a logins en sus respectivos Roles:
--Usuario de Jose Paredes

CREATE ROLE jparedes
WITH LOGIN ENCRYPTED PASSWORD 'kikla'
IN ROLE General;
________________________________________
27
__________________________________________________________
--Usuario de Orange
CREATE ROLE orange
WITH LOGIN PASSWORD 'orange'
IN ROLE General;
--Usuario de Deivi Bolges

CREATE ROLE dbolges
WITH LOGIN PASSWORD 'venaito'
IN ROLE General;
--Usuario de Felipe Mateo

CREATE ROLE fmateo
WITH LOGIN PASSWORD 'gentoo'
IN ROLE General;
--Usuario de Amaurys Rodriguez

CREATE ROLE arodriguez
WITH LOGIN PASSWORD 'centos'
IN ROLE Coronel
VALID UNTIL '2010-05-30';
--Usuario de Felipe Cristhian Nuez

CREATE ROLE cnunez
WITH LOGIN PASSWORD 'salsa'
IN ROLE Coronel;
--Usuario de Felipe Franky Almonte

CREATE ROLE falmonte
WITH LOGIN PASSWORD 'bacula'
IN ROLE Coronel;
--Usuario de Elvyn Bolges

CREATE ROLE ebolges
WITH LOGIN PASSWORD 'bolsa'
IN ROLE Cabo
--Usuario de Lus Merlin

CREATE ROLE lmerlin
WITH LOGIN PASSWORD 'quimica'
IN ROLE Cabo
--Usuario de Henry Terrero

CREATE ROLE hterrero
WITH LOGIN PASSWORD 'java'
IN ROLE henry;
--Usuario de Anyelina Colon

CREATE ROLE acolon
WITH LOGIN PASSWORD 'secre'
IN ROLE henry;
________________________________________
28
__________________________________________________________
--Validamos los objetos creados:
[[local]:5432/postgres@postgres] [] # SELECT * from pg_roles ;
[[local]:5432/postgres@postgres] [] # SELECT * from pg_user ;
[[local]:5432/postgres@postgres] [] # SELECT * from pg_group ;
[[local]:5432/postgres@postgres] [] # \du
[[local]:5432/postgres@postgres] [] # \dg
Permitir Usuario crear BD:

template1=# ALTER USER alice CREATEDB;
ALTER USER
Cambiando Nombre a un Usuario:

ALTER USER name RENAME TO newname;
template1=# ALTER USER bob RENAME TO colin;

ALTER USER
Cambiar contrasea:
template1=# ALTER USER colin WITH PASSWORD 'letmein';
ALTER USER
Comprobamos los Cambios y vemos los cambios: En la tabla pg_user
Eliminando Usuario:
Al igual que la creacion de usuarios, existen dos formas de eliminar los usuarios, utilizando
la lnea de comandos o SQL. En la lnea de comandos usariamos:
Desde el Shell
$ dropuser alice
DROP USER
Desde SQL
template1=# DROP USER colin;

DROP USER
Creando Grupo:
Los grupos son totalmente opcionales en postgresql. Solo se usan para simplificar la
concesion y revocacion de privilegios para el administrador db, y los usuarios no tienen que
ser un miembro de ningun grupo.
A diferencia de la creacion de usuarios, solo se pueden crear grupos utilizando SQL. El

comando es:
________________________________________
29
__________________________________________________________
CREATE GROUP name [ [ WITH ]

SYSID gid
| USER username [, ...]]
Si quisieramos crear un grupo con alice como miembro inicial, se puede utilizar:
template1=# CREATE GROUP sales WITH USER alice;
CREATE GROUP
/****Ejemplo****/
--Creando Grupos:
[[local]:5432/postgres@postgres] [] # CREATE GROUP contabilidad;
--Creando grupo incluyendo un usuario:
[[local]:5432/postgres@postgres] [] # CREATE GROUP contabilidad user pepe;
Agregando o eliminando un Usuario de Grupo:

ALTER GROUP groupname [ADD|DROP] USER username [, ... ]
template1=# ALTER GROUP sales ADD USER bob;

ALTER GROUP
template1=# ALTER GROUP sales DROP USER alice;

ALTER GROUP
/****Ejemplo****/
--Agregando usuario al grupo creado:
[[local]:5432/postgres@postgres] [] # ALTER GROUP contabilidad ADD USER pomavid ;
--Eliminando usuario de un grupo:
[[local]:5432/postgres@postgres] [] # ALTER GROUP contabilidad DROP USER pepe ;
Viendo los Grupos:

Podemos ver la pertenencia al grupo al ver la tabla de sistema pg_group. En este ejemplo he
aadido alice nuevamente en el grupo de ventas.
template1=# select * from pg_group ;
La columna grolist muestra una lista de identificadores de usuario que estan en el grupo. Si
desea ver los nombres de usuario en un grupo en particular se puede utilizar:
template1=# select usename from pg_user, (select grolist from pg_group w
Re-Nombrando Grupo:
ALTER GROUP groupname RENAME TO newname
template1=# ALTER GROUP sales RENAME TO presales;
________________________________________
30
__________________________________________________________
/****Ejemplo****/
--Vamos a renombrar un grupo:
[[local]:5432/postgres@postgres] [] # ALTER GROUP contabilidad RENAME TO dba;
Eliminando Grupo:
template1=# DROP GROUP presales;
/****Ejemplo****/
--Eliminando Grupo:
[[local]:5432/postgres@postgres] [] # DROP GROUP dba ;
/***Practica***/
--Crear un grupo llamado fcld y agregar tres usuario al mismo:
Creacion de tablespaces:
Si queremos especificar ubicaciones alternativas para determinadas bases de datos o tablas,
por ejemplo, queremos que ciertas tablas estn en otros discos distintos a los que se
encuentran por defecto, debemos crear tablespaces.
CREATE TABLESPACE tablespacename [ OWNER username ] LOCATION 'directory'
Tablespacename: no puede empezar en pg_ porque est reservado a los tablespaces de

sistema.
Username: debe ser un superusuario del cluster.
Directory: se deben indicar trayectorias absolutas y el propietario del directorio debe ser el
usuario con el que se ha instalado PostgreSQL.
En versiones anteriores de PostgreSQL, exista el comando initlocation, que serva para

indicar ubicaciones alternativas para las bases de datos, y que exiga que se definiese una
variable de entorno similar a PGDATA para cada base de datos.
Nota: cuando se crean tablespaces, en $PGDATA/pg_tblspc se crean enlaces simblicos a

los directorios fsicos donde se encuentran, esto es importante tenerlo en cuenta en procesos
como el cambio de ubicaciones o en la restauracin de ficheros desde una copia de
seguridad.
/****Ejemplo****/
--Trabajando con TableSpace:
--Auntomaticamente creamos el directorio tablespace en data y creamos los Los directorios

donde se alojaran los TableSpace:
[postgres@jp ~]$mkdir -p data/tablespace/tbe_{2008_{1,2},2009_{1,2},2010_1,0000_0}
________________________________________
31
__________________________________________________________
...
--Queremos dos simplemente, uno para los datos y otro para los indices:
[postgres@jp ~]$mkdir -p data/tablespace/tablespace_datos
[postgres@jp ~]$mkdir -p data/tablespace/tablespace_index
--Aqui creamos nuestros TableSpaces:
[[local]:5432/postgres@postgres] [] # CREATE TABLESPACE TS_Pomavid_Datos

OWNER pepe LOCATION '/var/lib/pgsql/data/tablespace/tablespace_datos';
[[local]:5432/postgres@postgres] [] # CREATE TABLESPACE TS_Pomavid_Indices

OWNER pepe LOCATION '/var/lib/pgsql/data/tablespace/tablespace_index';
--Si queremos poner unos de los TableSpace por defecto:
SET default_tablespace=TS_Pomavid_Datos;
--Para saber el tamao de que ocupa los TableSpace:
[[local]:5432/postgres@postgres] [] # SELECT
spcname,spclocation,pg_tablespace_size(spcname)/1024 "Tamao MB"
FROM pg_tablespace
WHERE spclocation LIKE '/var/lib/pgsql/data/tablespace/tablespaces_datos%';
spcname | spclocation | Tamao MB

---------+-------------+-----------
(0 rows)
Creacin de bases de datos:

Una base de datos se puede crear desde la lnea de comandos del sistema operativo (con el
usuario de sistema) o desde una conexin a una base de datos.(con un usuario que tenga
privilegios para crear bases de datos).
Desde el sistema operativo:
$ createdb [OPCIN]... [NOMBRE] [DESCRIPCIN]

Opciones:
-D, --tablespace=TBLSPC tablespace por omisin de la base de datos
-E, --encoding=CODIFICACIN codificacin para la base de datos
-O, --owner=DUEO usuario que ser dueo de la base de datos
-T, --template=PATRN base de datos patrn a copiar
-e, --echo m ostrar los comandos enviados al servidor
-q, --quiet no desplegar mensajes
--help mostrar esta ayuda y salir
--version mostrar el numero de versin y salir
________________________________________
32
__________________________________________________________
Opciones de conexin:
-h, --host=ANFITRIN nombre del servidor o directorio del socket
-p, --port=PUERTO puerto del servidor
-U, --username=USUARIO nombre de usuario para la conexin
-W, --password preguntar la contrasea
Si no se especifica, se crear una base de datos con el mismo nombre que el
usuario actual.
Desde un cliente SQL:
CREATE DATABASE name

[ [ WITH ] [ OWNER [=] dbowner ]
[ TEMPLATE [=] template ]
[ ENCODING [=] encoding ]
[ TABLESPACE [=] tablespace ]
[ CONNECTION LIMIT [=] connlimit ] ]
/****Ejemplo****/
--Ahora con el TableSpace creado ya podemos crear nuestra Bases Datos

--La misma alojara todos los objeto en el TableSpace ya creado:
--Desde el Shell:
[postgres@jp ~]$createdb poma -O pepe -D ts_pomavid_datos -e

CREATE DATABASE poma OWNER pepe TABLESPACE ts_pomavid_datos;
--Desde PsqL:
[[local]:5432/postgres@postgres] [] # CREATE DATABASE poma OWNER pepe

tablespace ts_pomavid_datos;
CREATE DATABASE
--Si queremos pasar una Base Datos ya creada a un TableSapce:
[[local]:5432/postgres@postgres] [] # ALTER DATABASE poma SET tablespace

ts_pomavid_datos ;
Esquemas:
Las bases de datos se organizan mediante esquemas, contenedores lgicos de objetos de
base de datos (tablas, vistas, procedimientos, etc.), bsicamente son un espacio de nombres.
Es caracterstico de los esquemas:
Tienen un propietario.
Permiten el uso de la base de datos por multiples usuarios sin interferencias.
Permiten que se puedan instalar aplicaciones realizadas por terceros si que existan
colisiones en los nombres de los objetos.
Para poder ver objetos de un esquema, debe usarse la notacin esquema.objeto ya
que en PostgreSQL no existe el concepto de sinnimos como en Oracle.
Mas delante seguiremos hablando de Schema.!!!
________________________________________
33
__________________________________________________________
/****Ejemplo****/
--Una vez creada la Base Datos procedemos a crear el Schema:
[[local]:5432/postgres@postgres] [] # CREATE SCHEMA cole authorization pepe;

CREATE SCHEMA
--Para crear un Objeto dentro del Schema creado es y en el TableSpace :
[[local]:5432/postgres@postgres] [] # CREATE TABLE cole.Bbella (Nombre Varchar(30))

tablespace ts_pomavid_datos;
--Podemos setear el search_path a nivel de base de datos y Schema, Por defecto :

[[local]:5432/postgres@postgres] [] # SET search_path TO cole;
SET
[[local]:5432/postgres@postgres] [] # SHOW search_path ;

search_path
-------------
cole
(1 row)
--Una vez creado el Schema todo objeto debe ser creado asi:
--**************Schema.Objeto**************
[[local]:5432/postgres@postgres] [] # SELECT * from cole.TAB TAB ;
--Listar los Schema:

[[local]:5432/postgres@pomavid] [] # \dn+
Permisos
Todos los objetos (tablas, vistas y secuencias) tienen un propietario, que es la persona que lo
creo. El propietario o un superusuario, puede establecer permisos en el objeto. Los permisos
se compone de un nombre de usuario o grupo y un conjunto de derechos. Estos derechos
descritos en la tabla de abajo.
Privilege short name Description

SELECT r Puede leer los datos del objeto.
INSERT a Puede insertar datos en el objeto.
UPDATE w Puede cambiar los datos en el objeto.
DELETE d Puede eliminar los datos del objeto.
RULE R Puede crear una regla sobre la tablas.
REFERENCES x Se puede crear una clave externa a una tabla.Necesita
esto en ambos lados de la llave.
TRIGGER t Se puede crear un desencadenador en la tabla.
TEMPORARY T Se puede crear una tabla temporal.
EXECUTE X Se puede ejecutar la funcion.
USAGE U Puede usar la lengua del procedimiento.
ALL All privilegios adecuados. Para las tablas, esto equivale a
arwdRxt
________________________________________
34
__________________________________________________________
Viendo los privilegios:
sales=# \dp
Asignando Privilegios:
GRANT { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES |
TRIGGER }
[,...] | ALL [ PRIVILEGES ] }
ON [ TABLE ] tablename [, ...]
TO { username | GROUP groupname | PUBLIC } [, ...] [ WITH GRANT OPTI
GRANT INSERT, UPDATE, DELETE ON TABLE suppliers TO bob;
Quitando Privilegios:
REVOKE INSERT UPDATE DELETE ON TABLE suppliers FROM bob CASCASE
/****Ejemplo****/
--Ahora vamos Asignacion de Derechos sobre Objetos:

--Utilizaremos el Scripts de hr mas otros objetos creados por los usuarios:
[postgres@jp ~]$psql < hr_Postgreql.sql
--Vemos los objetos insertados desde el Scripts hr:
[[local]:5432/postgres@HR] [] # \d
List of relations
Schema | Name | Type | Owner
--------+-----------------------+----------+----------
public | countries | table | postgres
public | departments | table | postgres
public | employees | table | postgres
public | job_history | table | postgres
public | jobs | table | postgres
public | locations | table | postgres
public | regions | table | postgres
public | regions_region_id_seq | sequence | postgres
(8 rows)
--Para cambiar el dueo de una tabla, de esta manera usted puede tener todos los privilegios
sobre un objeto:
[[local]:5432/postgres@HR] [] # ALTER TABLE countries owner to jparedes ;

ALTER TABLE
[[local]:5432/postgres@HR] [] # \d
List of relations
--------+-----------------------+----------+----------
public | countries | table | jparedes
________________________________________
35
__________________________________________________________
--Ahora nos logueamos con el usuario jparedes en la Bases Datos HR:
[postgres@jp ~]$psql -U jparedes HR

psql (8.4.4)
[[local]:5432/jparedes@HR] [] >
--Ahora tratamos de consultar una de las tablas de la Base Datos HR:
[[local]:5432/jparedes@HR] [] > SELECT * from employees ;

ERROR: permission denied for relation employees
--Vamos otorgar privilegios al usuario jparedes para hacer SELECT sobre la tabla
employees;
--como hicimos login con jparedes que no es el dueo ni tiene privilegios sobre la Bases
Datos HR,
--Tenemos que hacer login con el dueo del objeto o el DBA:
[postgres@jp ~]$psql -U postgres HR
--Ortogamos privilegios de SELECT al usuario jparedes:
[[local]:5432/postgres@HR] [] # GRANT SELECT ON employees TO jparedes;

GRANT
--Listo ya el usuario jparedes puede hacer SELECT sobre la tabla employees:
[[local]:5432/jparedes@HR] [] > SELECT first_name, salary from employees limit 1;
first_name | salary
------------+--------
John | 14000
(1 row)
--Le revocamos los privilegios de SELECT al usuario jparedes:
[[local]:5432/postgres@HR] [] # REVOKE SELECT ON employees FROM jparedes;

REVOKE
--Hacer pruebas:
[[local]:5432/jparedes@HR] [] > SELECT * from employees ;

--Tenenos un ROLE llamado General y el mismo estan agregados varios usuarios

--Vamos darle privilegios de SELECT a ese ROLE completo:
[[local]:5432/postgres@HR] [] # GRANT SELECT ON employees TO general ;
--Ahora cualquira de los usuarios que estan en ese ROLE puede hacer SELECT sobre las
tablas del Schema HR:
________________________________________
36
__________________________________________________________
--Hacer pruebas:
[postgres@jp ~]$psql -U orange HR

psql (8.4.4)
[[local]:5432/orange@HR] [] > SELECT first_name, salary from employees limit 1;

first_name | salary
-------------+--------
John | 14000
(1 row)
--Vamos REVOCAR los privilegios al ROlE General:
[[local]:5432/postgres@HR] [] # REVOKE SELECT ON employees FROM general ;

REVOKE
--Hacer pruebas:
[[local]:5432/fmateo@HR] [] > SELECT first_name, salary from employees limit 1;

--Vamos a darle todos los priviegio al ROLE General sobre un Schema:?

--Primero hacemos logion con el usuario hterrero el General de los pela papa:
[postgres@jp ~]$psql -U hterrero sacademico

psql (8.4.4)
--Hacemos una consulta a la tabla cursos del Schema sacademicoschema:
[[local]:5432/hterrero@sacademico] [] > SELECT * from sacademicoschema.cursos;

ERROR: relation "sacademicoschema.curso" does not exist
LINE 1: SELECT * from sacademicoschema.cursos;
^
sacademico
--Otorga los permisos en el Schema SacademicoSchema:
[[local]:5432/postgres@sacademico] [] # GRANT ALL ON SCHEMA sacademicoschema

to hterrero;
GRANT
--Prueba:
[[local]:5432/hterrero@sacademico] [] > SELECT * from sacademicoschema.cursos;

ERROR: permission denied for relation cursos
--Otorgamos privilegios al objeto dentro del Schema:
[[local]:5432/postgres@sacademico] [] # GRANT ALL ON sacademicoschema.cursos to

hterrero;
________________________________________
37
__________________________________________________________
GRANT
--Prueba:
[[local]:5432/hterrero@sacademico] [] > SELECT * from sacademicoschema.cursos limit 2;
id_curso | curso | costo | fecha_registro | quien_registro
-----------+---------------------------------+--------+--------------------------+-----------
1 | Diplomado GNU/Linux | 3500 | 2009-08-05 21:57:24 | admin
2 | Unixs(Solaris*Aix*Hp-Ux) | 3500 | 2009-08-05 21:57:31 | admin
(2 rows)
--Revocando los privilegios de de un ROLE sobre un Schema:
[[local]:5432/postgres@sacademico] [] # REVOKE ALL ON SCHEMA sacademicoschema

from hterrero;
--Prueba:

ERROR: permission denied for schema sacademicoschema
LINE 1: SELECT * from sacademicoschema.cursos limit 1;
--Acceso a los requerimientos previamente solicitados:
[[local]:5432/postgres@sacademico] [] # GRANT USAGE ON SCHEMA

sacademicoschema to hterrero;
GRANT
--Prueba:

id_curso | curso | costo | fecha_registro | quien_registro
-----------+-----------------------------------+---------+---------------------------+-----------
1 | Diplomado GNU/Linux | 3500 | 2009-08-05 21:57:24 | admin
2 | Unixs(Solaris*Aix*Hp-Ux) | 3500 | 2009-08-05 21:57:31 | admin
3 | Asterisk-I | 12500 | 2009-08-16 15:57:14 | root@local
host
(3 rows)
--El usuario puede cambiar la misma session:

--Primero vemos nuestra session y usuario:
[[local]:5432/orange@sacademico] [] # SELECT session_user, current_user;

session_user | current_user
---------------+--------------
orange | orange
(1 row)
--Cambiamos de session:
[[local]:5432/jparedes@sacademico] [] # SET session AUTHORIZATION hterrero ;

SET
--Resultado:
________________________________________
38
__________________________________________________________
[[local]:5432/hterrero@sacademico] [] > SELECT session_user, current_user;

----------------+--------------
hterrero | hterrero
(1 row)
--Para cambiar solo de usuario en una session:

--Primero vemos nuestra session y usuario:
[[local]:5432/jparedes@sacademico] [] # SELECT session_user, current_user;

----------------+--------------
jparedes | jparedes
(1 row)
--Cambio de ROLE:
[[local]:5432/jparedes@sacademico] [] # SET role hterrero ;

SET
--Resultado:
[[local]:5432/jparedes@sacademico] [] > SELECT session_user, current_user;

----------------+--------------
jparedes | lmerlin
(1 row)
--Para resetiar la session:
[[local]:5432/jparedes@sacademico] [] > RESET session AUTHORIZATION ;

RESET
--Verifico:
[[local]:5432/jparedes@sacademico] [] # SELECT session_user, current_user;

----------------+--------------
jparedes | jparedes
(1 row)
--Ver los permisos de los objetos existentes:

--Hacemos login en la Bases Datos HR:
[postgres@jp ~]$psql -U falmonte HR

psql (8.4.4)
--Luego vemos informacion sobre los permisos de los objetos exists, no tenemos:
[[local]:5432/falmonte@HR] [] > \z
________________________________________
39
__________________________________________________________
Access privileges
Schema | Name | Type | Access privileges | Column access privileges
--------+----------------------------+---------------+----------------------+--------------------------
public | countries | table | |
public | departments | table | |
public | employees | table | |
public | job_history | table | |
public | jobs | table | |
public | locations | table | |
public | pepe | sequence | |
public | regions | table | |
public | regions_region_id_seq | sequence | |
(9 rows)
--Verificamos si pordemos consultas algunos de esos objetos:
[[local]:5432/hterrero@HR] [] > SELECT * from countries ;

ERROR: permission denied for relation countries
--No tenemos ningunos vamos a otorgar algunos privilegios al ROLE coronel, en el cual se
encuentra el usuario falmonte:
[[local]:5432/postgres@HR] [] # GRANT SELECT ON countries TO coronel ;

GRANT
[[local]:5432/postgres@HR] [] # GRANT UPDATE ON countries TO cnunez ;

GRANT
[[local]:5432/postgres@HR] [] # GRANT DELETE ON countries TO arodriguez ;

GRANT
[[local]:5432/postgres@HR] [] # GRANT ALL ON countries TO general ;

GRANT
--Prueba:
[[local]:5432/falmonte@HR] [] > SELECT * from countries limit 3;

country_id | region_id | name
-------------+-------------+-----------
AR | 2 | Argentina
AU | 3 | Australia
BE | 1 | Belgium
(3 rows)
--Luego vemos informacion sobre los permisos de los objetos exists ya aplicados:
Access privileges
Schema | Name | Type | Access privileges | Column access
privileges
----------+--------------------------+---------+-------------------------------+--------------------
public | countries | table | postgres=arwdDxt/postgres |
________________________________________
40
__________________________________________________________
: coronel=r/postgres
: cnunez=w/postgres
: arodriguez=d/postgres
: general=arwdDxt/postgres
(9 rows)
-- Si queremos Permitir conceder el mismo privilegios a otro:
[[local]:5432/postgres@HR] [] # GRANT ALL ON locations TO coronel with grant option;
--Verificamos:
Access privileges
privileges
----------+---------------------------+------------+-------------------------------------+----------------
public | countries | table | postgres=arwdDxt/postgres |
: coronel=r/postgres
: cnunez=w/postgres
: arodriguez=d/postgres
: general=arwdDxt/postgres
public | locations | table | postgres=arwdDxt/postgres |
: coronel=a*r*w*d*D*x*t*/postgres
(9 rows)
/***Practica***/
--Explique en detalle los permisos reflejados:
--Revoque el permiso de lectura a general.

--Otorgue el permiso de escritura y actualizacion a falmonte
--*****Restableciendo y Eliminando Obejtos--*****:
--Nota: Si queremos eliminar algunos objetos o Bases Datos no debe existir ningun ROLE
asociado al mismo:
________________________________________
41
__________________________________________________________
--Regresamos a la sesin principal por defecto.
RESET SESSION AUTHORIZATION;

--Ahora vamos a otorgar y rebocar privilegios a nivel de columnas:
--Revocamos todos los privilegios al usuario acolon sobre la tabla countries de la Bases
Datos HR:
[[local]:5432/postgres@HR] [] # REVOKE ALL ON countries FROM acolon ;
--Prueba:
[[local]:5432/acolon@HR] [] > SELECT region_id from countries ;

[[local]:5432/acolon@HR] [] > SELECT country_id from countries ;

[[local]:5432/acolon@HR] [] > SELECT name from countries ;

[[local]:5432/acolon@HR] [] > SELECT * from countries ;

--Actualmente no tenemos privilegios sobre ninguna columna de la tabla countries.
--Procedemos a Otorgar privilegios a una columna de la tabla countries:
[[local]:5432/postgres@HR] [] # GRANT SELECT (name) on countries to acolon;

GRANT
--Prueba:
[[local]:5432/acolon@HR] [] > SELECT name from countries limit 3;
name
-----------
Argentina
Australia
Belgium
(3 rows)
--Intentamos hacer SELECT a otra columna de la misma tabla:
[[local]:5432/acolon@HR] [] > SELECT country_id from countries ;

--De igualmenare solo tenemos privilegios de hacer consulta sobre esa columna
--si tratamos de actualizar nos dira:
[[local]:5432/acolon@HR] [] > UPDATE countries SET name = 'R.D' where

name='Belgium';
________________________________________
42
__________________________________________________________
--Vamos Otorgar privilegios de Actualizacin sobre la columna name de la tabla countries:
[[local]:5432/postgres@HR] [] # GRANT UPDATE (name) on countries to acolon;
--Prueba:
[[local]:5432/acolon@HR] [] > UPDATE countries SET name = 'San Juam' where

name='Argentina';
UPDATE 1
--Si queremos ver los privilegios de la columna name de la tabla countries:
[[local]:5432/postgres@HR] [] # \dp
Access privileges
privileges
----------+----------------------------+-----------+----------------------------------+-----------------
public | countries | table | postgres=arwdDxt/postgres | name:
: acolon=rw/postgres
(8 rows)
--Para Revocar privilegios de una columna:
[[local]:5432/jparedes@HR] [] # REVOKE SELECT (name) on countries from acolon;

REVOKE
--Prueba:
[[local]:5432/acolon@HR] [] > SELECT name from countries limit 3;

--Verificamos los privilegios:

[[local]:5432/acolon@HR] [] > \dp countries
Access privileges
Schema | Name | Type | Access privileges | Column access privileges
----------+-------------+-------+----------------------------------+-----------------------
public | countries | table | postgres=arwdDxt/postgres | name: acolon=w/postgres
(1 row)
Cambiando EL propietario de una tabla:
ALTER TABLE suppliers OWNER TO bob;
Trabajando con Schema:

test=# CREATE SCHEMA foo;
CREATE SCHEMA
________________________________________
43
__________________________________________________________
test=# CREATE TABLE foo.info (id INT, txt TEXT);

CREATE TABLE
test=# INSERT INTO foo.info VALUES(1, 'This is schema foo');

INSERT 23062 1
test=# CREATE SCHEMA bar;

CREATE SCHEMA
test=# CREATE TABLE bar.info (id INT, txt TEXT);

CREATE TABLE
test=# INSERT INTO bar.info VALUES(1, 'This is schema bar');

INSERT 23069 1
test=# SELECT foo.info.txt, bar.info.txt

FROM foo.info, bar.info
WHERE foo.info.id=bar.info.id;
Listar los Objetos en Schema Public:
test=# \dv
Cuando el nombre de esquema no esta previsto en un objeto de base de datos, PostgreSQL

se refiere a la ruta de busqueda ", que define el orden en el que buscar a traves de esquemas
de un nombre de objeto no calificados.
En el ejemplo anterior, info_view fue creado en el esquema publico porque el publico es

siempre por defecto que figuran en la ruta de busqueda. La configuracion actual de la ruta
de busqueda se puede ver con SHOW search_path:
test=# SHOW search_path;
Una ruta de busqueda se mantiene para cada conexion de base de datos, para cambiar la ruta
de busqueda uso search_path SET ...:
test=# SET search_path TO foo;

test=# \dt
Para alterar permanentemente la ruta de busqueda establecidos en cada conexion, el uso:
ALTER USER test SET search_path TO bar,foo;
Este cambio solo tendra efecto despues de volver a conectarse a la base de datos. Para
continuar con los ejemplos anteriores, el establecimiento de la ruta de busqueda a la barra,
foo significa ahora info bar mesa seran seleccionados por defecto:
test=# SET search_path TO bar, foo;
test=# SELECT txt FROM info;
test=# \d info
________________________________________
44
__________________________________________________________
Permisos y Seguridad en Schema:
CREATE SCHEMA tarzan AUTHORIZATION tarzan;
or
CREATE SCHEMA AUTHORIZATION tarzan;
El permiso USAGE determina si un usuario puede realizar ninguna operacion sobre el

esquema de otro usuario:
GRANT USAGE ON SCHEMA tarzan TO jane;

REVOKE USAGE ON SCHEMA tarzan TO jane;
Una vez que el permiso USAGE ha sido concedida, privilegios en tanto existentes como de
nueva creacion, los objetos de esquema se debe conceder de forma explicita:
GRANT SELECT ON tarzan.banana_inventory TO jane;

REVOKE SELECT ON tarzan.banana_inventory FROM jane;
Si el uso es revocado, ni objetos personales, incluidos los que el usuario tiene privilegios en
adelante, se puede acceder. Si el uso se concede de nuevo, cualquier privilegios anteriores se
reactiva automaticamente sobre el objeto.
El gran privilegio CREATE en un esquema permite a un usuario para crear objetos en el

esquema de otro usuario:
GRANT CREATE ON SCHEMA tarzan TO jane;

REVOKE CREATE ON SCHEMA tarzan TO jane;
Utilice el nombre de usuario reservado PUBLIC la hora de conceder o revocar privilegios

de todos los usuarios:
GRANT ALL ON SCHEMA tarzan TO PUBLIC;
Eliminando Schema:
Forma Simple:
DROP SCHEMA tarzan;

DROP SCHEMA tarzan CASCADE;
Funciones de Schema:
* Current_schema ()
Devuelve el nombre del esquema actual (esquema por primera vez en la ruta de
busqueda), segun lo establecido por search_path SET... Tenga en cuenta que se resolveran
en el primer esquema existente en la ruta de busqueda, no necesariamente el primero. Si no
hay un esquema se encuentra, se devuelve NULL.
* Current_schemas (boolean)
Devuelve todos los esquemas en la ruta de busqueda como una matriz, si se llama con
TRUE, esquemas implicitos (esquemas especiales como pg_catalog que se aaden a la ruta
de busqueda de forma automatica si no se especifica explicitamente) se devuelven.
________________________________________
45
__________________________________________________________
Esquemas especiales
Cada base de datos PostgreSQL contiene una serie de esquemas especiales requeridas por el
servidor y que no puede ser suprimida o alterada. Todos comienzan con pg_. Tenga en
cuenta que los nombres de esquema a partir de pg_ no estan permitidos.
Los esquemas especiales son:
* Pg_catalog: Contiene las tablas del sistema, las funciones y puntos de vista explotacion
de meta-informacion sobre la base de datos.
* Pg_temp_x: Contiene las tablas temporales que solo son visibles para una conexion de
base de datos concreta
* Pg_toast: Contiene manteca y dulces surtidos.
Desde PostgreSQL 7.4, tambien habra un INFORMATION_SCHEMA compuesto de

puntos de vista predefinidos que contienen informacion descriptiva sobre la base de datos
actual. Esta informacion se presenta en un formato definido en el estandar SQL y
proporciona informacion consistente y estandarizada sobre la base de datos y en cierta
medida las capacidades de la base de datos. El INFORMATION_SCHEMA es para
propositos de compatibilidad y probables, no seran relevantes para la mayoria de las
aplicaciones.
Limitaciones
Actualmente no es posible la "transferencia" objetos entre esquemas. soluciones posibles:
* Uso
CREATE TABLE AS new_schema.mytable SELECT * FROM old_schema.mytable
para transferir los datos y recrear todas las restricciones asociadas, indices, etc secuencias
manualmente.
* Crear la tabla en el nuevo esquema con la definicion actual y el uso
INSERT INTO new_schema.mytable SELECT * FROM old_schema.mytable;
para rellenar la tabla.
Cambiar el nombre de los esquemas se introducira en PostgreSQL 7.4 utilizando el esquema

ALTER .. RENOMBRAR CON ... de comandos.
Administrar privilegios de copia de seguridad:

Supongamos que usted quiere tener un 'backup' de usuario, que solo tienen la copia de
seguridad permanentes cuando este en funcionamiento. Asi pues, aqui una funcion que
puede administrar los privilegios para cada esquema (conceder y revocar).
________________________________________
46
__________________________________________________________
CREATE OR REPLACE FUNCTION manage_backup_privileges(p_user text, p_schema

text, action BOOLEAN)
RETURNS void AS
$BODY$
DECLARE
objeto text;
BEGIN
FOR objeto IN
SELECT tablename FROM pg_tables WHERE schemaname = p_schema
UNION
SELECT relname FROM pg_statio_all_sequences WHERE schemaname =
p_schema
LOOP
IF action = true THEN
RAISE NOTICE 'Asignando todos los privilegios a % sobre %.%', p_user,p_schema,
objeto;
EXECUTE 'GRANT ALL PRIVILEGES ON ' || p_schema || '.' || objeto || ' TO ' ||
p_user ;
ELSE
RAISE NOTICE 'Quitando todos los privilegios a % sobre %.%', p_user,p_schema,
objeto;
EXECUTE 'REVOKE ALL PRIVILEGES ON ' || p_schema || '.' || objeto || ' FROM ' ||
p_user ;
END IF;
END LOOP;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
Ejecutalo, es muy simple. Si desea activa los privilegios de uso de este formulario:
SELECT manage_backup_privileges('usuario','esquema', true);
Si desea que las Revocar los Privilegios:
SELECT manage_backup_privileges('usuario','esquema', false);
Script Bash Para Proporcionar acceso de solo lectura para cada tabla en la base de datos
PostgreSQL:
#!/bin/sh
#
# Proporcionar acceso de solo lectura en base de datos PostgreSQL
# Use: ./pgaccess $database $username
tables=$(psql $1 -A -t -c "SELECT table_name FROM information_schema.tables WHERE

table_schema = 'public';")
for table in $tables

do
echo "Proporcionar select to $2 on $table"
psql $1 -c "GRANT SELECT ON $table to $2;"
________________________________________
47
__________________________________________________________
done
Como se puede ver en la actualidad hay dos variables necesarias para ejecutar el script que
son base de datos y nombre de usuario. El script anterior debe ejecutarse en el siguiente
formato. El nombre de la secuencia de comandos para pgaccess.sh eso es lo que se utiliza en
el ejemplo siguiente.
Leer usuario solo sintaxis de secuencias de comandos:
./pgaccess $database $username
Basta con sustituir $ base de datos con el nombre de la base de datos que estan
proporcionando el acceso y reemplazar $ nombre de usuario con el nombre del usuario que
se facilitara el acceso SELECT a la base de datos PostgreSQL.
Atencion
Debe usted asegurarse de que su base de datos no se
actualiza durante su backup. Si es necesario, pare el
postmaster, edite los permisos del fichero
/usr/local/pgsql/data/pg_hba.conf para permitirle
a usted solo su uso, y relance de nuevo postmaster.
Si esta usted actualizando un sistema existente, mate ahora el servidor de la base de datos.
Teclee:
$ ps ax | grep postmaster
Esto deberia listar los numeros de proceso para una serie de procesos, de un modo similar a:
263 ? SW 0:00 (postmaster)

777 p1 S 0:00 grep postmaster
Teclee la siguiente lnea, reemplazando pid con el identificador (id) del proceso postmaster
(263 en el caso anterior). (No utilice el id del proceso "grep
postmaster".) (N. del T. tambien puede hacerlo con la lnea
$ ps ax | grep postmaster |grep -v grep
que le dara la misma salida, pero sin incluir la lnea correspondiente al mismo proceso
"grep". Fin de la N. del T.)
$ kill pid
Sugerencia: En sistemas que arrancan PostgreSQL en el durante la

secuencia de arranque de la maquina, probablemente se encontrara un
fichero startup que cumplira el mismo cometido. Por ejemplo, en un sistema
Linux RedHat, se deberia encontrar que
$ /etc/rc.d/init.d/postgres.init stop
funcione correctamente para parar la base.
________________________________________
48
__________________________________________________________
Administrando desde GNU/Linux

Todas las ordenes de Postgres que se ejecutan directamente desde un shell de Unix se
encuentran en el directorio .../bin . Incluir este directorio en su variable de entorno
path facilitara mucho la ejecucion de los mismos.
Existe una coleccion de catalogos del sistema en cada servidor. La misma incluye una clase
(pg_user) que contiene una instancia para cada usuario valido en Postgres. La instancia
especifica un conjunto de privilegios sobre Postgres, como la posibilidad de actuar como
superusuario en Postgres, la posibilidad de crear/destruir bases de datos y la posibilidad de
actualizar los catalogos del sistema. Un usuario de Unix no puede hacer nada con Postgres
hasta que se instale una instancia apropiada en dicha clase. Puede encontrarse mas
informacion sobre los catalogos del sistema ejecutando consultas sobre las clases
apropiadas.
Iniciando postmaster
No le puede suceder nada a una base de datos a menos que este corriendo el proceso
postmaster. Como administrador, hay una serie de cosas que debe recordar antes de iniciar
postmaster. Vea las secciones de instalacion y configuracion en este mismo manual. De
todos modos, si ha unstalado Postgres siguiendo las instrucciones de instalacion al pie de la
letra, lo unico que tendra que hacer para iniciar el proceso postmaster es introducir esta
simple orden:
% postmaster
Ocasionalmente, postmaster escribe mensajes que le seran de ayuda para resolver

problemas. Si desea ver los mensajes de diagnostico de postmaster, puede iniciarlo con la
opcion -d y redirigir la salida al archivo de registro:
% postmaster -d > pm.log 2>&1 &
Si no desea ver los mensajes, inicielo de la forma
% postmaster -S
y postmaster sera "S"ilencioso. Observe que al no haber el signo ampersand ("&") al final
del ultimo ejemplo, no se ejecuta como proceso de fondo.
Seguridad:
La seguridad de la base de datos esta implementada en varios niveles:
Proteccion de los ficheros de la base de datos. Todos los ficheros almacenados en la base
de datos estan protegidos contra escritura por cualquier cuenta que no sea la del
superusuario de Postgres.
Las conexiones de los clientes al servidor de la base de datos estan permitidas, por
defecto, unicamente mediante sockets Unix locales y no mendiante sockets TCP/IP. Ha de
arrancarse el demonio con la opcion -i para permitir la conexion de clientes no locales.
Las conexiones de los clientes se pueden restringir por direccion IP y/o por nombre de
________________________________________
49
__________________________________________________________
usuario mediante el fichero pg_hba.conf situado en PG_DATA.

Las conexiones de los clientes pueden ser autentificadas mediante otros paquetes externos.
A cada usuario de Postgres se le asigna un nombre de usuario y (opcionalmente) una
contrasea. Por defecto, los usarios no tienen permiso de escritura a bases de datos que no
hayan creado.
Los usuarios pueden ser incluidos en grupos, y el acceso a las tablas puede restringirse en
base a esos grupos.
Autentificacion de Usuarios:
Autentificacion es el proceso mediante el cual el servidor de la base de datos y el postmaster
se aseguran de que el usario que esta solicitando acceso a la base de datos es en realidad
quien dice ser. Todos los usarios que quieren utilizar Postgres se comprueban en la tabla
pg_user para asegurarse que estan autorizados a hacerlo. Actualmente, la verificacion de la
identidad del usuario se realiza de distintas formas:
Desde la shell del usuario
Un demonio que se lanza desde la shell del usuario anota el id original del usuario antes
de realizar un setuid al id del usuario postgres. El id original del usuario se emplea como
base para todo tipo de comprobaciones.
Desde la red
Si Postgres se instala como distribuido, el acceso al puerto TCP del postmaster esta
disponible para todo el mundo. El ABD configura el fichero pg_hba.conf situado en el
directorio PG_DATA especificando el sistema de autentificacion a utilizar en base al equipo
que realiza la conexion y la base de datos a la que se conecta. Ver pg_hba.conf(5) para
obtener una descripcion de los sistemas de autentificacion disponibles. Por supuesto la
autentificacion basada en equipos no es perfecta incluso en los sistemas Unix. Es posible,
para determinados intrusos, enmascarar el equipo de origen. Estos temas de seguridad estan
fuera del alcance de Postgres.
Creacion de una base de datos:

Supongamos que quiere crear una base de datos llamada mibase. Puede hacerlo con el
siguiente orden:
% createdb nombredb
Postgres le permite crear cualquier numero de bases de datos en una maquina dada, y usted
se convierte automaticamente en el administrador de la base de datos que acaba de crear.
Los nombres de las bases de datos han de comenzar por un caracter alfabetico, y su longitud
esta limitada a 31 caracteres. No todos los usuarios estan autorizados para convertirse en
administradores de bases de datos. Si Postgres rechaza la orden de crear bases de datos, es
que necesita que el administrador del sistema le garantice derechos para crear las bases de
datos. Consulte a su administrador de sistemas si le ocurre eso.
________________________________________
50
__________________________________________________________
/****Ejemplo****/
/*********Shell***************/
--Si entramos al directorio data/base y queremos el oids para cual Bases Datos corresponde:
[postgres@jp base]$pwd
/var/lib/pgsql/data/base
[postgres@jp base]$ls
1 11563 11564 27369 27627 pgsql_tmp
--Comando a utilizar:
[postgres@jp ~]$oid2name
All databases:
Oid Database Name Tablespace
----------------------------------------
27627 HR pg_default
16428 poma ts_pomavid_datos
16411 pomavid ts_pomavid_datos
11564 postgres pg_default
27369 sacademico pg_default
11563 template0 pg_default
1 template1 pg_default
Acceso a la base de datos:

Una vez que ha construido la base de datos, puede acceder a ella por los siguientes medios:
Ejecutando el programa monitor de terminal de Postgres (psql) que le permite introducir,

editar y ejecutar ordenes SQL de un modo interactivo.
Escribiendo un programa en C que use la biblioteca de rutinas libpq. Esto le permite enviar
ordenes SQL desde C y obtener las respuestas y mensajes de estado en su programa. Esta
interfaz se discute en el documento Guia de programacion en PostgreSQL.
Puede que quiera ejecutar el programa psql, para probar los ejemplos de este manual. Puede
activarlo para la base de datos nombredb escribiendo la orden:
% psql nombredb
Recibira como respuesta el siguiente mensaje:
Welcome to the Postgres interactive sql monitor:

type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: nombredb
nombredb=>
Copia de seguridad y restauracion:
________________________________________
51
__________________________________________________________
Atencion
Deben realizarse copias de seguridad de las bases de datos

regularmente. Dado que Postgres gestiona sus propios ficheros
en el sistema, no se recomienda confiar en los sistemas de copia
de seguridad del sistema para las copias de respaldo de las
bases de datos; no hay garantia de que los ficheros esten en un
estado consistente que permita su uso despues de la
restauracion.
Postgres proporciona dos utilidades para realizar las copias de seguridad de su sistema:
pg_dump para copias de seguridad de bases de datos individuales y pg_dumpall para
realizar copias de seguridad de toda la instalacion de una sola vez.
La copia de seguridad de una sola base de datos puede realizarse usando la siguiente orden:
% pg_dump nombredb > nombredb.pgdump
y puede ser restaurada usando
cat nombredb.pgdump | psql nombredb
Esta tecnica puede usarse para mover bases de datos a una nueva localizacion y para
renombrar bases de datos existentes.
Bases de datos grandes:

Dado que Postgres permite tablas de mayor tamao que el permitido por el sistema de
ficheros, puede resultar problematico el volcado de una tabla a un fichero, ya que el fichero
resultante seguramente superara el tamao maximo permitido.
Como pg_dump escribe en stdout, puede usar las herramientas *nix para sortear estos
posibles problemas:
Uso de volcados comprimidos:
% pg_dump nombredb | gzip > nombrefichero.dump.gz
la recuperamos con:
% createdb nombredb
% gunzip -c nombrefichero.dump.gz | psql nombredb
% cat nombrefichero.dump.gz | gunzip | psql nombredb
Use split:
% pg_dump nombredb | split -b 1m - nombrefichero.dump.
y lo recuperamos con:
________________________________________
52
__________________________________________________________
% createdb nombredb
% cat nombrefichero.dump.* | pgsql nombredb
Por supuesto, el nombre del fichero (nombrefichero) y el contenido de la salida de pg_dump

no tiene por que coincidir con el nombre de la base de datos. Ademas, la base de datos
restaurada puede tener un nombre distinto, por lo que este mecanismo tambien es efectivo
para renombrar bases de datos.
Tratamiento de problemas :
El postmaster presenta ocasionalmente mensajes que pueden ser de ayuda en la
solucin de problemas. Si desea ver mensajes de depuracin de postmaster, puede iniciarlo
con la opcin -d y redirigir la salida a un fichero de registro:
% postmaster -d > pm.log 2>&1 &
Si no desea ver estos mensajes, puede escribir
% postmaster -S
y el postmaster entrar en modo S ilencioso. Ntese que no se incluye el simbolo & en

el ltimo ejemplo, ya que el postmaster se ejecutar en segundo plano.
Tareas administrativas: Copias de seguridad y recuperacin:

Una vez el sistema est en marcha, el administrador de base de datos debe establecer una
serie de tareas rutinarias para mantener el servidor en buenas condiciones, estas tareas se
pueden resumir en las siguientes:
Copias de seguridad ( y pruebas de restauracin de vez en cuando)
Tarea de limpieza: VACUUM

Tarea de reindexar: REINDEX
Copy
[[local]:5432/postgres@postgres][]# \h COPY
Command: COPY
Description: copy data between a file and a table
Syntax:
COPY tablename [ ( column [, ...] ) ]
FROM { 'filename' | STDIN }
[ [ WITH ]
[ BINARY ]
[ OIDS ]
[ DELIMITER [ AS ] 'delimiter' ]
[ NULL [ AS ] 'null string' ]
[ CSV [ HEADER ]
[ QUOTE [ AS ] 'quote' ]
[ ESCAPE [ AS ] 'escape' ]
[ FORCE NOT NULL column [, ...] ]
COPY { tablename [ ( column [, ...] ) ] | ( query ) }
________________________________________
53
__________________________________________________________
TO { 'filename' | STDOUT }
[ [ WITH ]
[ BINARY ]
[ OIDS ]
[ DELIMITER [ AS ] 'delimiter' ]
[ NULL [ AS ] 'null string' ]
[ CSV [ HEADER ]
[ QUOTE [ AS ] 'quote' ]
[ ESCAPE [ AS ] 'escape' ]
[ FORCE QUOTE column [, ...] ]
/****Ejemplo****/
--creemos una tabla de prueba
[[local]:5432/postgres@postgres][]# CREATE TABLE prueba (nombre varchar, apellidos

varchar);
--Creamos el archivo con las informaciones que queramos
-bash-4.0$ cat > prueba.cop

Jose
Mexy
Bianca
Joel
Jorge
--Vamos a esto....
--Realicemos el copy para la tabla prueba en la columna nombre
[[local]:5432/postgres@postgres][]# COPY prueba (nombre) from '/var/lib/pgsql/prueba.cop';

COPY 5
Time: 32.212 ms
--Veamos nuestra tabla

[[local]:5432/postgres@postgres][]# select * from prueba ;
nombre | apellidos
--------+-----------
Jose |
Mexy |
Bianca |
Joel |
Jorge |
(5 rows)
Time: 0.777 ms
--Nitido se efectuo correctamente
--Ahora haremos un DELETE a al tabla para borrar los datos introducidos
[[local]:5432/postgres@postgres][]# DELETE FROM prueba where nombre is not null;

DELETE 5
Time: 28.648 ms
[[local]:5432/postgres@postgres][]# SELECT * from prueba ;
nombre | apellidos
---------+-----------
(0 rows)
Time: 1.023 ms
________________________________________
54
__________________________________________________________
--Okay esta vasia.

--Cambiamos el contenido de nuestro archivo
-bash-4.0$ cat > prueba.cop

Jose, Paredes
Mexy, Alvarez
Bianca, SAntana
Joel, Santos
Jorge, Almonte
--Ahora haremos el copy con un delimiter, asi especificamos que informacion va para cada
columna.
[[local]:5432/postgres@postgres][]# COPY prueba (nombre, apellidos) from '/var/lib/pgsql/

prueba.cop' with delimiter ',';
COPY 5
Time: 31.330 ms
--Tambien podemos realizarlo con \copy de la misma manera asi
[[local]:5432/postgres@postgres][]# \copy prueba (nombre, apellidos) from

'/var/lib/pgsql/prueba.cop' with delimiter ','
Time: 25.355 ms
[[local]:5432/postgres@postgres][]# select * from prueba ;

nombre | apellidos
--------+-----------
Jose | Paredes
Mexy | Alvarez
Bianca | SAntana
Joel | Santos
Jorge | Almonte
(5 rows)
Time: 0.718 ms
--Tendra el mismo resultado.
--Todo Ready...
Mantenimiento del fichero de seguimiento

Conviene automatizar estas tareas mediante el uso de herramientas del SO (como el cron,
rotatelogs, etc) y/o scripts.
Se deben realizar rutinariamente, se debe fijar la frecuencia adecuada para cada una de ellas
y comprobar su correcta ejecucin.
Copias de seguridad:
Las copias de seguridad son esenciales para las recuperaciones frente a fallos, se deben
determinar las frecuencia conveniente, que ser funcin del tamao de los datos y de la
frecuencia con que son modificados, lo cual marcar la estrategia de copias de seguridad.
Algunas herramientas usadas para las copias de seguridad nos permitirn adems poder
trasladar datos de unas bases de datos a otras.
________________________________________
55
__________________________________________________________
Adems hemos de asegurarnos de que los logs, ficheros WAL, estn en otro disco, o hacer
copias ms frecuentes de estos logs ya que en la versin 8 ya se pueden copiar
automticamente y usar en la recuperacin.
Existen tres formas principales de realizar copias de seguridad:
1-copia de seguridad de ficheros del SO
2-Volcado SQL usando las herramientas PostgreSQL: pg_dump (pg_dumpall) y pg_restore.

3-Volcado en lnea y recuperacin en el punto (PITR)
Hay que tener claro que lo que estamos tratando aqu es la copia de seguridad de las bases
de datos, de los clusters, no estamos haciendo copia de seguridad del software instalado, del
cual, conviene de vez en cuando hacer una copia de seguridad de los ficheros del SO.
Copias de seguridad de ficheros del SO:

Es el mtodo ms sencillo, pero el ms ineficaz, se trata de realizar una copia de todos los
ficheros de un cluster, por ejemplo:
$ su - postgres
$ cd /tmp/backup
$ tar cvfz copia.tar.gz $PGDATA
Desventajas de este mtodo:

La base de datos debe estar parada
No se pueden recuperar partes del cluster (bases de datos, esquemas, tablas, etc.)
La recuperacin consiste en borrar todo el cluster y descomprimir el fichero de copia de
seguridad, con lo que se pierden los datos que se hayan modificado desde la ltima copia de
la base de datos.
Volcado SQL:
Los volcados de este tipo se realizan usando las herramientas que nos proporciona
PostgreSQL. Estos volcados son muy flexibles y de gran utilidad, nos permitirn hacer
copias de seguridad de toda la base de datos o de partes de ella, y luego, dada una copia de
seguridad, nos permitirn restaurar lo que
queramos.
Adems, estas herramientas sirven para la transmisin de datos entre bases de datos.
Las herramientas que se van a utilizar son:
pg_dump: vuelca una base de datos o parte de ella a un fichero, bien en texto plano o en un
formato propio de PostgreSQL. Se puede recuperar cualquier objeto que est en el fichero
aisladamente. El servidor debe estar en marcha.
pg_dumpall: vuelca un cluster completo
pg_restore: recupera los objetos volcados en una copia de seguridad que no se realizn en
texto plano sino en un formato propio de PostgreSQL.
________________________________________
56
__________________________________________________________
psql: se usa para recuperar los volcados en texto plano.
pg_dump: Con este comando, podemos volcar una base de datos o parte de ella a un fichero
script en texto plano o en un formato propio de PostgreSQL.
Si lo hacemos en un fichero de texto plano:
Tendremos un fichero de texto con instrucciones SQL.

Podemos usar psql para restaurar.
Es portable a servidores SQL.
Si lo hacemos en un formato propio de PostgreSQL:
Debemos usar pg_restore para restaurar
Es ms flexible
Slo es portable entre servidores PostgreSQL (aunque esto no es del todo cierto, debido a
que con pg_restore se pueden crear ficheros SQL en texto plano).
Si no se especifica un nombre de base de datos entonces el valor de la variable de ambiente

PGDATABASE es usado, y lo mismo con PGUSER, PGHOST y PGPORT.
Tiene ms opciones, usando $ man pg_dump se pueden ver detalles de esas opciones.
Ejemplos de uso:
-- Exportar una base de datos:
$ pg_dump -f bdnominas.sql -h otro host -p 6432 bdnominas

-- Exportar un esquema, redireccionando la salida
$ pg_dump -n nominas2004 > esq_nominas2004.sql

-- Volcar una base de datos llamada mibd en un fichero tar:
$ pg_dump -Ft mibd > bd.tar
pg_dumpall:
Con pg_dumpall se realizan volcados del cluster completo, incluyendo roles de grupo y
roles de login.
Tiene ms opciones, usando $man pg_dumpallse pueden ver detalles de esas opciones.
Como se ve, este comando es similar a pg_dump, pero tiene algunas diferencias:
No permite la opcin de indicar el fichero de salida, con lo cual hay que redireccionar la
salida a un fichero.
No tiene la opcin de formatos de fichero de salida, la salida es siempre un fichero de texto

plano.
Tiene una opcin muy interesante que es "-g" que permite exportar nicamente los objetos
globales, con lo que podemos generar un script que contenga la creacin de usuarios y roles.
________________________________________
57
__________________________________________________________
Ejemplos de uso:
-- Exportar un cluster:
$ pg_dumpall > micluster.sql
-- Exportar solo los datos

$ pg_dumpall -a > misdatos.sql
-- Exportar solo los roles / usuarios de una base de datos en otro servidor
-- que adems, tiene otro superusuario
$ pg_dump_all -g -h otroservidor -U otrosuperusuario -p 6432 > misusuarios.sql
-- Exportar solo los esquemas
$ pg_dumpall -s > misesquemas.sql
Recuperacin con psql:

La recuperacin con psql se puede hacer cuando los ficheros de volcado son texto plano con
sentencias SQL. Hacemos uso de la posibilidad que tiene psql de ejecutar cdigo que le
viene redireccionado de entrada desde un fichero.
$ psql [bd_destino] < fichero.sql
El fichero se puede modificar antes de cargarlo, pero hay que llevar mucho cuidado con los
editores que gastemos, porque hay algunos que realizan conversiones de codificacin de
caracteres o formatos y esto puede producir efectos indeseados.
Si lo que se quiere recuperar es un cluster completo o la parte global (roles/usuarios),

siempre se debe restaurar en la base de datos template1.
Recuperacin con pg_restore:

Con pg_restore se pueden restaurar a partir de ficheros en formato distinto a texto plano (tar
o uno propio de PostgreSQL comprimido). Se puede seleccionar y reordenar la seleccin.
Hay dos modos de hacerlo:
Directamente a una base de datos, es la opcin por defecto -d
Volcando en otro fichero que actua de conversor. Se crea asi un script en texto plano que
podemos modificar antes de ejecutarlo.
Por ejemplo, supongamos que hemos hecho una copia de seguridad de nuestra base de datos
en formato comprimido y se han perdido datos de una tabla de empleados, para recuperarlos
hacemos:
$ pg_restore -Fc -f empleados.sql -t empleados bd.dump

$ pgsql bdorigen c drop table empleados
$ psql bdorigen < empleados.sql
________________________________________
58
__________________________________________________________
Recuperacin ante fallos:
Fallos en la memoria principal
PostgreSQL se recupera bien en fallos de la memoria primaria (cortes de luz ,cuelgues, etc.),
el sistema se recupera usando los ficheros de log (WAL) y nunca se pierde una transaccin
confirmada.
Los ficheros de log permiten que adems, la base de datos no tenga que estar
completamente actualizada (sync) para mantener los datos ante fallos en la memoria
principal (prdida de valores en los bufferes compartidos).
Hay un nmero mximo de logs: 2*CHECKPOINT_SEGMENTS+1
Si se llenan sin que se haya hecho sync,el sistema hace un sync y avisa de que hacen falta
ms logs.
El trabajo y el tiempo de recuperacin dependen del nmero de checkpoint_segments,

cuanto mayor sea el sistema aguantar ms tiempo sin llevar los bferes sucios a disco y
ser ms eficiente, aunque tambin se requiere ms espacio en disco y las recuperaciones
requeriran ms tiempo.
/***Ejemplo****/
/****************** Backups******************/
--Vamos iniciar la parte de los Backups:
/*********PG_DUMP***************/
--Listamos todas las Bases Datos:
[postgres@jp ~]$psql -l
List of databases
Name | Owner | Encoding | Collation | Ctype | Access privileges
--------------+---------------+-----------+-----------------+-------------+--------------
HR | fcld | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =Tc/fcld
: fcld=CTc/fcld
poma | pepe | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
pomavid | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =T/postgres
: postgres=CTc/postgres
sacademico | sacademico | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres
template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres
(7 rows)
--Haciendo Backup de la Bases Datos HR:
[postgres@jp ~]$pg_dump -v HR > HR_Backup.sql
________________________________________
59
__________________________________________________________
--Si queremos ver el tamao del Backup:
[postgres@jp ~]$du -sch HR_Backup.sql

K HR_Backup.sql
K total
--Si queremos restaurar el Backup:
--Borramos la Bases Datos:
[postgres@jp ~]$dropdb HR
--Creamos la Bases Datos:
[postgres@jp ~]$createdb HR
--Hacemos login en ella y verificamos q esta vacia:

Timing is on.
psql (8.4.4)
[[local]:5432/jparedes@HR] [] # \d
No relations found.
--Ahora procedemos a restautar el Backup:
[postgres@jp ~]$psql -d HR -f HR_Backup.sql
--Hacemos login en ella y verificamos:

Timing is on.
psql (8.4.4)
[[local]:5432/jparedes@HR] [] # \d
List of relations
--------+-----------------------+----------+----------
public | countries | table | postgres
public | departments | table | postgres
public | employees | table | postgres
public | job_history | table | postgres
public | jobs | table | postgres
public | locations | table | postgres
public | regions | table | postgres
public | regions_region_id_seq | sequence | postgres
(8 rows)
--Tambien podemos restaurar el Backup de esta manera:
[postgres@jp ~]$psql HR < HR_Backup.sql
________________________________________
60
__________________________________________________________
--Tambien con cat volcamos el backup:
[postgres@jp backups]$cat caro_hr_backup.sql |psql HR

--Ahora vamos hacer un Backup Comprimido de la Bases Datos Sacademico:
[postgres@jp ~]$pg_dump sacademico |gzip -c > sacademico_Backup.sql.gz
--Verificamos el archivo:
[postgres@jp ~]$file sacademico_Backup.sql.gz
sacademico_Backup.sql.gz: gzip compressed data, from Unix, last modified: Wed Jun 2
08:49:50 2010
--Restaurando un Backup comprimido:
[postgres@jp ~]$gunzip sacademico_Backup.sql.gz |xargs psql -d sacademico -f

sacademico_Backup.sql
/*^o^*/
--Podemos hacerlo paso a paso:
--Primero descomprimimos el Backup:
[postgres@jp ~]$gunzip -v sacademico_Backup.sql.gz
--Restauramos el Backup descomprimido:
[postgres@jp ~]$psql < sacademico_Backup.sql
--Ahora vamos hacer un Backups de una tabla especifica:
[postgres@jp ~]$pg_dump -t sacademicoschema.cursos sacademico >

sacademico_Tcurso.sql
--Realizando Backup de una maquina remota:
[postgres@jp ~]$pg_dump sacademico -h 192.168.100.13 -U postgres >

remote_sacademico.sql
Password: pepe
/***Practica***/
--Realice un backup de la DB HR utilizando la opcion -a

--Haga lo mismo pero con la opcion -v
--Explique la diferencia, Segun su resultado (verificar cada archivo.sql con cat)
/*********PG_DUMPALL***************/
--Vamos Extraer toda las Bases Datos:
[postgres@jp ~]$pg_dumpall > Full_Backup.dmp

--Volvemos a restaurar el Backup:
[postgres@jp ~]$psql -e template1 < Full_Backup.dmp
________________________________________
61
__________________________________________________________
--Backup de una sola Bases Datos:
/*********PG_RESTORE***************/
--Primeros Hacemos un Backup del usuarios HR:
[postgres@jp ~]$pg_dump -Ft HR > hr.tar

--Ahora vamos a restaurarlo en una Bases Datos ya Existente:
[postgres@jp ~]$pg_restore -d poma hr.tar
/***Practica***/
--Restaura los backups ya realizados dela DB HR
Scripts Basico de hacer Backup:
#!/bin/bash
DIR=/backup/psql
[ ! $DIR ] && mkdir -p $DIR || :
LIST=$(psql -l | awk '{ print $1}' | grep -vE '^-|^List|^Name|template[0|1]')
for d in $LIST
do
pg_dump $d | gzip -c > $DIR/$d.out.gz
Crontab
El crontab, es un archivo en donde podemos configurar tareas para que se ejecuten automticamente
en nuestro sistema, digamos por ejemplo descargar un archivo de respaldo diariamente, o borrar
ciertos archivos peridicamente, ejecutar un script que haga algo, etc, digamos que podemos
automatizar las tareas, para no estar hacindolas a mano.
Qu es cron?
Cron es el nombre del programa que permite a usuarios Linux/Unix ejecutar automticamente
comandos o scripts (grupos de comandos) a una hora o fecha especfica. Es usado normalmente
para comandos de tareas administrativas, como respaldos, pero puede ser usado para ejecutar
cualquier cosa. Como se define en las pginas del manual de cron (#> man cron) es un demonio que
ejecuta programas agendados.
Iniciar cron
Cron es un demonio (servicio), lo que significa que solo requiere ser iniciado una vez, generalmente
con el mismo arranque del sistema. El servicio de cron se llama crond. En la mayora de las
distribuciones el servicio se instala automticamente y queda iniciado desde el arranque del sistema,
se puede comprobar de varias maneras:
/***Ejemplo****/
[root@guerrero ~]# /etc/init.d/crond status

crond (pid 1320) is running...
________________________________________
62
__________________________________________________________
--Tambien con
/etc/rc.d/init.d/crond status
Usa cualquiera de los dos dependiendo de tu distro
--o si tienes el comando service instalado:
[root@guerrero ~]# service crond status

crond (pid 1320) is running...
--se puede tambin revisar a travs del comando ps:

[root@guerrero ~]# ps -ef | grep crond
root 14320 1 1 15:51 ? 00:00:00 crond
root 14328 4304 0 15:51 pts/0 00:00:00 grep crond
--si por alguna razn, cron no esta funcionando:

[root@guerrero ~]# /etc/init.d/crond start
Starting crond: [ OK ]
--Si el servicio no estuviera configurado para arrancar desde un principio, bastara con agregarlo
con el comando chkconfig:
[root@guerrero ~]# chkconfig --level 35 crond on
Usando cron
Hay al menos dos maneras distintas de usar cron: La primera es en el directorio /etc, donde muy
seguramente encontrars los siguientes directorios:
cron.hourly
cron.daily
cron.weekly
cron.monthly
Si se coloca un archivo tipo script en cualquiera de estos directorios, entonces el script se ejecutar
cada hora, cada da, cada semana o cada mes, dependiendo del directorio.
Para que el archivo pueda ser ejecutado tiene que ser algo similar a lo siguiente:
#!/bin/sh
#script que genera un respaldo
cd /usr/documentos
tar czf * respaldo
cp respaldo /otra_directorio/.
Ntese que la primera lnea empieza con #!, que indica que se trata de un script shell de bash, las
dems lneas son los comandos que deseamos ejecute el script. Este script podra nombrarse por
ejemplo respaldo.sh y tambin debemos cambiarle los permisos correspondientes para que pueda
ser ejecutado, por ejemplo:
#> chmod 700 respaldo.sh
#> ls -l respaldo.sh
-rwx------ 1 root root 0 Jul 20 09:30 respaldo.sh
La "x" en el grupo de permisos del propietario (rwx) indica que puede ser ejecutado.
Si este script lo dejamos en cron.hourly, entonces se ejecutar cada hora con un minuto de todos los
das, en un momento se entender el porque.
________________________________________
63
__________________________________________________________
Como segundo modo de ejecutar o usar cron es a travs de manipular directamente el archivo
/etc/crontab. En la instalacin por defecto de varias distribuciones Linux, este archivo se ver a algo
como lo siguiente:
[root@guerrero ~]# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
#|||||
# * * * * * command to be executed
Las primeras cuatro lneas son variables que indican lo siguiente:
SHELL es el 'shell' bajo el cual se ejecuta el cron. Si no se especifica, se tomar por defecto el
indicado en la lnea /etc/passwd correspondiente al usuario que este ejecutando cron.
PATH contiene o indica la ruta a los directorios en los cuales cron buscar el comando a ejecutar.
Este path es distinto al path global del sistema o del usuario.
MAIL TO es a quien se le enva la salida del comando (si es que este tiene alguna salida). Cron
enviar un correo a quien se especifique en este variable, es decir, debe ser un usuario vlido del
sistema o de algn otro sistema. Si no se especifica, entonces cron enviar el correo al usuario
propietario del comando que se ejecuta.
HOME es el directorio raz o principal del comando cron, si no se indica entonces, la raz ser la
que se indique en el archivo /etc/passwd correspondiente al usuario que ejecuta cron.
Los comentarios se indican con # al inicio de la lnea.
Despus de lo anterior vienen las lneas que ejecutan las tareas programadas propiamente. No hay
lmites de cuantas tareas pueda haber, una por rengln. Los campos (son 7) que forman estas lneas
estn formados de la siguiente manera:
Minuto Hora DiaDelMes Mes DiaDeLaSemana Usuario Comando
Un asterisco * como valor en los primeros cinco campos, indicar inicio-fin del campo, es decir
todo. Un * en el campo de minuto indicar todos los minutos.
Ejecutando Cron con mltiples usuarios, comando crontab

Linux es un sistema multiusuario y cron es de las aplicaciones que soporta el trabajo con varios
usuarios a la vez. Cada usuario puede tener su propio archivo crontab, de hecho el /etc/crontab se
asume que es el archivo crontab del usuario root, aunque no hay problema que se incluyan otros
usuarios, y de ah el sexto campo que indica precisamente quien es el usuario que ejecuta la tarea y
es obligatorio en /etc/crontab.
Pero cuando los usuarios normales (e incluso root) desean generar su propio archivo de crontab,
entonces utilizaremos el comando crontab.
En el directorio /var/spool/cron (puede variar segn la distribucin), se genera un archivo cron para
cada usuario, este archivo aunque es de texto, no debe editarse directamente.
________________________________________
64
__________________________________________________________
Se tiene entonces, dos situaciones, generar directamente el archivo crontab con el comando:
/***Ejemplo****/
[root@guerrero ~]# crontab -e
Con lo cual se abrira el editor por default (generalemente vi) con el archivo llamado crontab vacio y
donde el usuario ingresar su tabla de tareas y que se guardar automticamente como
/var/spool/cron/usuario.
16 8 * 1-5 ls /etc/lvm
# me listara el contenido de /lvm a las 4:20 de todos los 8 sea de lunes a viernes
crontab: installing new crontab
--Revisemos:
[root@guerrero ~]# cat /var/spool/cron/root
16 8 * 1-5 ls /etc/lvm
# me listara el contenido de /lvm a las 4:20 de todos los 8 sea de lunes a viernes
--Podemos comprobar el resultado del cron revisando:

[root@guerrero ~]# cat /var/spool/mail/root
--Super!!
Controlando el acceso a cron

Cron permite controlar que usuarios pueden o no pueden usar los servicios de cron. Esto se logra de
una manera muy sencilla a travs de los siguientes archivos:
/etc/cron.allow
/etc/cron.deny
Para impedir que un usuario utilice cron o mejor dicho el comando crontab, basta con agregar su
nombre de usuario al archivo /etc/cron.deny, para permitirle su uso entonces sera agregar su
nombre de usuario en /etc/cron.allow, si por alguna razn se desea negar el uso de cron a todos los
usuarios, entonces se puede escribir la palabra ALL al inicio de cron.deny y con eso bastara.
/****Ejemplos****/
--Le impediremos al Usuario Brouli que utilice cron

[root@guerrero ~]# echo Brouli >>/etc/cron.deny
--Revisemos el archivo
[root@guerrero ~]# cat /etc/cron.deny
Brouli
--Ahora comprovemoslo
[Brouli@guerrero ~]$ crontab -e
You (Brouli) are not allowed to use this program (crontab)
See crontab(1) for more information
________________________________________
65
__________________________________________________________
--Si negao y pico jeje!!

Sigamos
--Impidiendo el uso para todos
[root@guerrero ~]# echo ALL >>/etc/cron.deny
o para agregar un usuario mas a cron.allow

[root@guerrero ~]# echo Brouli >>/etc/cron.allow
Si no existe el archivo cron.allow ni el archivo cron.deny, en teora el uso de cron esta entonces sin
restricciones de usuario. Si se aaden nombres de usuarios en cron.allow, sin crear un archivo
cron.deny, tendr el mismo efecto que haberlo creado con la palabra ALL. Esto quiere decir que
una vez creado cron.allow con un solo usuario, siempre se tendrn que especificar los dems
usuarios que se quiere usen cron, en este archivo.
COMANDO chkconfig:
El comando chkconfig se usa para cambiar, actualizar y consultar informacin de runlevel para los
servicios del sistema. chkconfig es un comando de administrador.
SINTAXIS:
La sintaxis es
chkconfig [opciones]
/****Ejemplo****/
--Nos lista los niveles de ejecucion y el estado del servicio (si esta activo o no).
[root@guerrero ~]# chkconfig --list
--Veamos el estado del servicio iptables
[root@guerrero ~]# chkconfig --list iptables
iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Iptables: es el nombre de la herramienta de espacio de usuario (User Space, es decir, rea de

memoria donde todas las aplicaciones, en modo de usuario, pueden ser intercambiadas hacia
memoria virtual cuando sea necesario) a travs de la cual los administradores crean reglas para cada
filtrado de paquetes y mdulos de NAT. Iptables es la herramienta estndar de todas las
distribuciones modernas de GNU/Linux
--Ahora estableceremos el estado de iptables Podemos utilizar <on | off| reset| resetpriorities>, en
este caso sera off, veamos...
[root@guerrero ~]# chkconfig iptables off
--El estado del servicio iptables es totalmente inactivo.

iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:off
--Tambien podemos definirlo por levels asi:

[root@guerrero ~]# chkconfig --level 345 iptables on
________________________________________
66
__________________________________________________________
--Ahora los levels 3,4 y 5 estan ON. verifiquemos

iptables 0:off 1:off 2:off 3:on 4:on 5:on 6:off
--Chevere!
Fallos en memoria secundaria (disco):
Hasta la versin 7.X no haba recuperacin total, si se produca una prdida dentro del
$PGDATA, haba que recurrir a la copia de seguridad fsica ms reciente y desde ese
momento las actualizaciones se perdan, aunque tuviramos los ficheros de log. Aqu es
donde, en la versin 8.X se incorpora el volcado en lnea y la recuperacin PITR.
Volcado en lnea y recuperacin PITR:

A partir de la versin 8.0.0, PostgreSQL permite actualizar la copia de seguridad con los
cambios que proporcionan en los ficheros de log que hayan sobrevivido.
Para poder utilizar esta opcin tiene que estar habilitado el archivado WAL y en
funcionamiento. Los ficheros WAL son segmentos de 16Mb que se nombran
secuencialmente en el cual el sistema va copiando los cambios en la base de datos. El
sistema recicla los ficheros de log que no van a ser necesitados renombrndolos a nmeros
superiores dentro de la secuencia.
Para activar el archivado, en el fichero postgresql.conf debemos indicar el comando de

copia para preservar los ficheros de log, parmetro archive_command, haciendo, por
ejemplo:
archive_command = cp -i %p /mnt/server/archivedir/%f < /dev/null
donde %p representa el nombre del fichero con la ruta absoluta y %f sin la ruta.
Para realizar copias de seguridad en lnea se siguen los siguientes pasos:
1. activar el archivado WAL
2. antes de empezar y desde una consola SQL hay que ejecutar:
select pg_start_backup(nombre_copia);
3. con el servidor en marcha, hacemos la copia desde el sistema operativo, no hace falta
parar el servidor, por ejemplo:
$ tar cvf backup_nombre_copia.tar $PGDATA
4. cuando acaba, desde la consola SQL, marcamos el final, ejecutamos:
select pg_stop_backup();
________________________________________
67
__________________________________________________________
5. se crea as un fichero de marca en el directorio $PGDATA/pg_xlog/archive_status y

copia los logs que se reciclan en donde se haya indicado en archive_command.
Para realizar una recuperacin se siguen los siguientes pasos:
1. parar el postmaster
2. si tenemos espacio, copiar el cluster daado y los tablespaces a otra ubicacin
3. borrar todos los ficheros que hay dentro del cluster asi como los correspondientes a los
tablespaces
4. recuperar la copia de seguridad (comprobando los tablespaces en pg_tblspc)
$ tar xvf backup_nombre_copia
5. borrar los ficheros WAL en $PGDATA/pg_xlog porque probablemente estarn obsoletos.
6. si existen ficheros WAL sin archivar, tal como hemos hecho en el paso 2, copiarlos a
pg_xlog
7. crear un fichero de comandos de recuperacin, recovery.conf en el directorio $PGDATA.

Existe una plantilla, recovery.conf.sample, en el directorio $HOME/pgsql/share. Se copia
con el nombre recovery.conf en $PGDATA y se edita. En principio, si se quiere recuperar
todo y los logs estn en su sitio, no hay que tocar nada.
8. se arranca PostgreSQL que entra en modo de recuperacin y procede a leer la

informacin de los WAL que necesite, siendo necesario evitar que se conecten usuarios
normales durante la recuperacin.
9. inspeccionar la base de datos, si todo ha ido correcto, los datos estarn recuperados hasta
la ltima transaccin confirmada y el fichero recovery.conf se renombra a recovery.done.
Conviene tener los ficheros log en un disco distinto al que est el cluster, para que la
recuperacin sea mejor. Para ello, debemos mover el directorio pg_xlog a otro disco y crear
un enlace simblico, con el cluster parado.
Por ejemplo:
$ mkdir /disco2/pg/
$ cd $PGDATA
$ mv pg_xlog /disco2/pg
$ ln s /disco2/pg/pg_xlog pg_xlog
Adems, para asegurarnos que no se nos pierden archivos de log, podemos hacer un cron
que copie los archivos que no estn llenos en una ubicacin distinta.
En el fichero recovery_conf hay una serie de parmetros que pueden ayudar a recuperar
hasta el momento o la transaccin que queramos (lo que se conoce como recuperacin
Point-in-time):
restore_command: lo que ejecuta esta variable es lo que PostgreSQL ejecutar antes de

empezar la recuperacin.
________________________________________
68
__________________________________________________________
Por ejemplo:
restore_command = cp /mnt/server/archivedir/%f %p
recovery_target_time: hasta qu momento
recovery_target_xid: hasta una transaccin determinada
recovery_target_inclusive: si los dos casos anteriores son inclusive o no.
Tareas administrativas: Vacuum:

Vacuum es un proceso de limpieza que se encarga de:
Recuperar el espacio de disco ocupado por filas modificadas o borradas.

Actualizar las estadsticas usadas por el planificador / optimizador
evitar la prdida de datos muy antiguos debido al reuso del identificador de

transaccin
/****Ejemplo****/
/*********VACUUMDB***************/
--Vamos a limpiar y analizar la Bases Datos HR:
[postgres@jp ~]$vacuumdb HR -v
[postgres@jp ~]$vacuumdb -ze pomavid

VACUUM ANALYZE;
Recomendaciones:
Usar VACUUM FULL si alguna tabla ha cambiado mucho y no va a crecer en el futuro.
Ejecutar VACUUM diariamente en todas las bases de datos
Hacerlo con ms frecuencia sobre tablas con mucha carga de actualizacin.
Determinar las tablas grandes con pocas actualizaciones para eliminarlas del VACUUM.
Dentro del VACUUM, se pueden actualizar las estadsticas con la opcin ANALYZE,
haciendo lo mismo que hace el comando ANALYZE, as proporciona:
1 informacin usada por el optimizador
1 no es muy pesado el proceso porque se realiza sobre una muestra al azar.

1 necesario si la distribucin de los datos cambia mucho
El problema del XID (identificador de transaccin):
Otro problema que resuelve VACUUM es el evitar la prdida de datos muy antiguos,
porque MVCC introduce el concepto de marca de tiempo XID identificador de transaccin.
________________________________________
69
__________________________________________________________
XID est limitado a 32 bits, es decir cuando llega a 232 se reinicializa, tiene un
funcionamiento circular, si esto llega a ocurrir, se perderan datos. Existen adems dos XID
especiales: BootstrapXID y FrozenXID. Cada vez que se ejecuta VACUUM se guarda
informacin que se puede consultar:
select datname, age(datfrozenxid) from pg_database;
As, si se ejecuta poco el vacuum, la base de datos avisa al administrador, se deben limpiar
las tablas una vez cada mil millones de transacciones. El caso es que se recomienda hacer
VACUUM diario.
AUTOVACUUM:
Para evitar los problemas con la ejecucin de VACUUM, a partir de la versin 8,
PostgreSQL incorpora un proceso de fondo AUTOVACUUM que se ejecuta
peridicamente cuando est habilitado y l mismo comprueba las tablas con alta carga de
actualizaciones. Hay una serie de parmetros en postgresql.conf para modificar el
comportamiento de este proceso.
Reindex:
Otras tareas importantes son las reindexaciones, ya que pueden haber ndices incorrectos por
problemas en el software o hardware o porque haya que optimizar el ndice debido a que
tiene pginas muertas que hay que eliminar.
Ejemplos:
-- reparar un indice:
reindex index nomindice;
-- reparar todos los ndices de una tabla:

reindex table nomtabla;
-- reparar los ndices del catlogo de base de datos, para esto

-- hay que levantar postmaster sin que use los ndices y luego reindexar
$ export PGOPTIONS="-P: // significa lo mismo que $ postmaster -P

$ psql bd
bd=# reindex database bd;
-- reparar los ndices del catlogo compartido (pg_database, pg_group, pg_shadow,

-- etc.). No se debe levantar postmaster si no que hay que arrancar un proceso
-- autnomo:
$ postgres -D $PGDATA -P prueba

backend> reindex index indice_catalogo_compartido
Se puede introducir en el cron que realice ciertas operaciones de mantenimiento:
$ crontab -e
// se abre el fichero de cron y aadimos estas lneas:
0 3 * * * psql -c 'VACUUM FULL;' test
________________________________________
70
__________________________________________________________
0 3 * * * vacuumdb -a -f
0 30 * * * reindexdb bd
ATENCIN!, problema entre Reindex y Archivado WAL:
Hay que tener presente que cuando reindexamos, se rehacen muchos ficheros, con lo que
hay que llevar especial cuidado si el archivado WAL est activado, pues una reindexacin
de toda la base de datos implica que se puede duplicar el tamao de los ficheros de la base
de datos, ya que el sistema de WAL crea archivos de log para cada cambio.
Monitorizacion:
La monitorizacin de la actividad del servidor PostgreSQL se puede hacer con herramientas
del SO o con herramientas propias de la base de datos.
Comandos del Sistema Operativo (Linux / Unix):
La monitorizacin se debe fijar sobre todo en:
Uso de swap (free, vmstat, etc.)
Free muestra la cantidad de memoria libre y usada que tiene el sistema. Por una
parte muestra la memoria fsica y por otra la swap, tambin muestra la memoria
cach y de buffer consumida por el Kernel.
vmstat : Es muy similar a top ya que es un condensado de los procesos del sistema,
para que esta herramienta se vuelva dinmica se deben especificar los argumentos:
vmstat -n <numero de segundos por actualizacion >
Uso del disco (iostat, etc.)
iostat informa repetidamente de las estadsticas de E/S para cada disco activo del
sistema.
Monitoreo interactivo (top, ps, htop, pg_top)
ps
Usando el comando ps, podemos filtrar las filas en las que salga "postmaster:"
-- ver el proceso servidor:

$ ps -ef |grep "postmaster" | grep -v grep
-- ver los procesos backend
$ ps -ef |grep "postgres:" | grep -v grep
supongamos que tenemos una salida como la siguiente:
$ ps -ef | grep postmaster | grep v grep
/****Ejemplo****/
/*********PROCESOS***************/
--Vamos a ver los procesos generados por el Usuario PostgreSQL:
________________________________________
71
__________________________________________________________
[postgres@jp ~]$ps -Upostgres

PID TTY TIME CMD
5668 ? 00:00:01 postmaster
5970 ? 00:00:00 postmaster
5972 ? 00:00:00 postmaster
5973 ? 00:00:00 postmaster
5974 ? 00:00:00 postmaster
5975 ? 00:00:01 postmaster
7830 ? 00:00:00 postmaster
7831 ? 00:00:00 postmaster
7850 ? 00:00:00 postmaster
8090 pts/1 00:00:01 bash
8160 pts/2 00:00:00 bash
--Tambien podemos utilizar herramientas como top, htop:
--Si queremos monitoriar nuesto server con una herramienta nativa:
[postgres@jp ~]$pg_top
last pid: 14812; load avg: 0.74, 0.43, 0.33; up 0+02:55:34
12:07:28
4 processes: 4 sleeping
CPU states: 10.3% user, 0.0% nice, 3.0% system, 86.7% idle, 0.0% iowait
Memory: 1613M used, 2365M free, 103M buffers, 860M cached
Swap: 8000M free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
7831 postgres 25 0 54M 6964K sleep 0:00 0.00% 0.00% postgres: postgres pomavid
127.0.0.1(13687) idle
7830 postgres 24 0 53M 5600K sleep 0:00 0.00% 0.00% postgres: postgres postgres
127.0.0.1(13686) idle
14813 postgres 20 0 53M 4228K sleep 0:00 0.00% 0.00% postgres: postgres postgres
[local] idle
7850 postgres 17 0 53M 4340K sleep 0:00 0.00% 0.00% postgres: postgres pomavid
127.0.0.1(13705) idle
/***Pratica***/
--Utiliza las opciones -p y -d

--Explique su resultado.
/******Para monitorear la memoria virtual******/
[postgres@jp ~]$vmstat 2
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 2421036 105964 880432 0 0 37 36 558 826 8 2 89 2 0
0 0 0 2421036 105972 880432 0 0 0 6 1088 1249 6 1 89 4 0
--Siqueremos monitorizar la actividad de los dispositivos, particiones y sistemas en red

(NFS) del sistema,
________________________________________
72
__________________________________________________________
--adems tambin muestra una media en % del uso de CPU en la mquina.
[postgres@jp ~]$iostat 2
Linux 2.6.18-194.3.1.el5PAE (jp.fcld.local) 06/05/2010
avg-cpu: %user %nice %system %iowait %steal %idle

7.60 0.03 2.04 1.72 0.00 88.61
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn

sda 10.53 144.87 142.59 1557037 1532508
sda1 0.01 0.19 0.00 2012 4
sda2 10.52 144.65 142.59 1554721 1532504
dm-0 2.12 22.06 11.36 237146 122088
dm-1 0.04 0.31 0.01 3282 56
dm-2 4.09 75.25 12.52 808794 134520
dm-3 11.38 35.92 76.29 386026 819944
dm-4 6.15 11.02 42.42 118465 455896
dm-5 0.01 0.05 0.00 576 0
sdb 0.03 0.88 0.00 9474 2
sdb1 0.03 0.84 0.00 9018 2
dm-6 6.11 10.93 42.42 117514 455896
sdc 0.04 0.26 0.00 2814 17
sdc1 0.04 0.26 0.00 2742 17
--Para ver el tamao completo disponible en nuestro FileSystem:
[postgres@jp ~]$df -h
Filesystem Size Used Avail Use% Mounted on

/dev/mapper/VGOracle-VLBarra
38G 1.1G 35G 3% /
/dev/mapper/VGOracle-VLOpt
141G 98G 37G 74% /opt
/dev/mapper/VGOracle-VLUsr
76G 42G 31G 58% /usr
/dev/mapper/VGOracle-VLVar
48G 1.5G 44G 4% /var
/dev/mapper/luks-e42c95a5-a0d9-47ad-a57f-53dc36e13592
142G 121G 14G 90% /home
/dev/sda1 99M 75M 20M 80% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/sdb1 149G 149G 77M 100% /media/disk
--Si queremos ver el tamao ocupado por el server de PostgreSQL:
[postgres@jp ~]$du -sch data/

108M data/
108M total
________________________________________
73

Dba PostgreSQL

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Dba PostgreSQL

Cargado por

Copyright:

Formatos disponibles

Academia De Software Libre www.codigolibre.

Documentacin Realizada Por:

Ing. Jose Paredes Meidy Alvarez

Meidy E. Alvarez Guerrero

Esta documentacin es regida por los reglamentos de la GNU Free Documentation

Brinde soporte al almacenamiento de cantidades voluminosas de datos durante un largo

Controle el acceso concurrente.

Escalabilidad: Capacidad de mejorar con el incremento de los recursos invertidos.

Portabilidad: Exportacin e importacin de datos de una plataforma a otra.

Rendimiento: Recuperacin, actualizacin, concurrencia, etc. de una manera eficiente.

Universalidad: Mltiples tipos de datos (multimedia).

Gestion de los Recursos del kernel:

Parmetros de PostgreSQL que afectan a la memoria compartida:

Corresponden con una rden de SQL ejecutadas dentro de la base de

clusterdb: equivalente al comando CLUSTER de SQL, reorganiza cluster de

dropdb: borrar una base de datos.

La comunicacion entre BackEnd/FrontEnd se realiza mediante TCP/IP, normalmente por el

En las instalaciones automticas a partir de paquetes (rpm, apt-get, etc) o en Windows, se

pg_hba.conf: fichero de configuracion de la autenticacion de los clientes y usuarios

pg_ident.conf: fichero accesorio al anterior, determina como se realiza la

PG_VERSION: fichero de texto con la version de software Postgres que crea el

postmaster.opts: contiene las opciones con las que se ha iniciado el postmaster.

recovery.conf, recovery.done: si se quiere o se ha hecho una recuperacion.

pgstat.stat: fichero usado por el monitor de estadsticas.

pg_control: fichero con parmetros del cluster, algunos inmutables (establecidos en

pg_log: ficheros de seguimiento del servidor. Se crea en la versin de Windows, en

pg_xlog: ficheros de diario del servidor (WAL).

pg_clog: ficheros de diario para las transacciones (estado de cada transaccin).

pg_multixact: contiene datos sobre el estado multi-transaccional, usado para los

pg_twophase: ficheros de estado para las transacciones preparadas.

pg_subtrans: para realizar los savepoints en medio de transacciones.

pg_tblspc: informacin sobre los tablespaces. Cuidado porque en linux/unix

Creacin del cluster de bases de datos: initdb

Creacion del cluster:

initdb --pgdata=$PGDATA --encoding=LATIN1 --locale=es_ES

Si queremos parar el servidor:

--Siqueremos ver la informacion inicializada por initdb:

[postgres@jp ~]$pg_controldata data/

pg_control version number: 843

Float4 argument passing: by value

Modificacion de template1 + aadir extensiones-contrib:

$ createlang plpgsql template1

$ createlang plpgsql postgres

Lo ejecutamos tambin en postgres para que tenga las mismas opciones.

tsearch2: soporte para indexacin usando GiST

lo: mantenimiento de tipos de datos LOB

vacuumlo: vacuum para objetos LOB

dblink: poder ejecutar sentencias en otras bases de datos

Puesta en marcha y parada del servidor:

de la instruccin que acta sobre el servidor postgres.

postmaster: proceso servidor de base de datos.

El comando pg_ctl es el que se usa normalmente, porque permite controlar ms aspectos

stop: parada del servidor.

restart: parada del servidor seguida de puesta en marcha.

status: comprueba si hay un postmaster en marcha y muestra el PID y sus

kill, register, unregister: opciones para la version de Windows para matar,

1 Mensajes en varios idiomas.

Para ver cmo est configurado en el SO ejecutar:

Que nos mostrar la configuracin activa, podemos cambiar la configuracin entre

En cuanto a los juegos de caracteres:

el cluster puede estar en un conjunto de caracteres y la base de datos en otro:

$ createdb -E latin1 base1

SQL# create database base2 with encoding win ;

/Ejemplos de conexiones remotas/

/AHORA CON EL pg_hba.conf (hba = host based authentication)/