Dba PostgreSQL

Academia De Software Libre www.codigolibre.
org
__________________________________________________________
PostgreSql
________________________________________
2010 Manual De Administración de PostgreSql
1
Academia De Software Libre www.codigolibre.org
__________________________________________________________
Clase de Administración
PostgreSql
Documentación 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
• Gestión de los Recursos del kernel.......................................................................7
• psql.......................................................................................................................8
• Aplicaciones servidor...........................................................................................8
• Arquitectura .........................................................................................................8
• El proceso Postmaster..........................................................................................9
• La memoria compartida.......................................................................................9
• Almacenamiento físico.........................................................................................9
• Ficheros................................................................................................................9
• Otros ficheros.......................................................................................................9
• Directorios..........................................................................................................10
• Creación del cluster de bases de datos: initdb....................................................10
• Creación del cluster............................................................................................11
• Modificación de template1 + añadir extensiones-contrib..................................12
• Puesta en marcha y parada del servidor.............................................................12
• Internacionalización y localización....................................................................13
• Ventajas..................................................................................................13
• Para ver cómo está configurado en el SO ejecutar.............................................13
• Procesamiento de instrucciones.........................................................................14
• Gestión de transacciones....................................................................................15
• Atomicidad (atomicity)...........................................................................15
• Consistencia (consistency)......................................................................15
• Aislamiento (isolation)............................................................................16
• Persistencia (durability)..........................................................................16
• Seguridad en PostgreSQL..................................................................................17
• Seguridad en la manipulación de los ficheros....................................................17
• Respecto a las conexiones locales vía sockets...................................................17
• Seguridad en el acceso de los clientes................................................................18
• Conexión local: usando los sockets del dominio Unix......................................18
• Conexión remota sin encriptar usando TCP/IP (SSL y no SSL)........................19
• Conexión remota encriptada SSL usando TCP/IP (solo SSL)...........................19
• Esquema lógico..................................................................................................23
• Creación de roles (usuarios)...............................................................................24
• Listando Usuarios..............................................................................................27
• Modificando Usuarios.......................................................................................27
• Permitir Usuario crear BD.................................................................................29
• Cambiando Nombre a un Usuario......................................................................29
• Cambiar contraseña...........................................................................................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
• Creación de tablespaces.....................................................................................31
• Creación 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
• Autentificación de Usuarios...............................................................................50
• Creación 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 recuperación.............................53
• Copy...................................................................................................................53
• Mantenimiento del fichero de seguimiento........................................................55
• Copias de seguridad............................................................................................55
• Copias de seguridad de ficheros del SO.............................................................56
• Desventajas de este método................................................................................56
• Volcado SQL......................................................................................................56
• Recuperación con psql........................................................................................58
• Recuperación 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 múltiples usuarios, comando crontab...................64
• Controlando el acceso a cron...................................................................65
• COMANDO chkconfig.....................................................................................66
• Fallos en memoria secundaria (disco)................................................................67
• Volcado en línea y recuperación PITR...............................................................67
• Tareas administrativas: Vacuum …...................................................................69
• AUTOVACUUM...............................................................................................70
• Reindex...............................................................................................................70
• Monitorizacion...................................................................................................71
________________________________________
4
__________________________________________________________
Dedicatoria
Una mención de forma especial para Antonio Perpiñán, Fundador del
Movimiento de Software Libre en República Dominicana y en América
Latina, persona de grandes principios y vastos conocimientos. No todo
hombre tiene el valor de aprender y mucho menos de enseñar, por eso sea
siempre bendecido por su calidez y gran visión. “El objeto más noble que
puede ocupar el hombre es ilustrar a sus semejantes”.
Meidy E. Alvarez Guerrero
________________________________________
5
__________________________________________________________
Copyright
Esta documentación es regida por los reglamentos de la GNU Free Documentation

License y la GNU General Public License v3, siéntase libre de copiar, modificar,
aprender, distribuir y redistribuir esta documentación; 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 administración de base de datos y análisis de estructuras de almacenamiento de
registros de datos.
________________________________________
6
__________________________________________________________
¿Qué se espera de un SGBD?

De un Sistema de Gestión de Bases de Datos esperamos:
Permita a los usuarios crear otras bases de datos y especificar su esquema por medio de
algún lenguaje de definición.
Ofrezca a los usuarios la capacidad de consultar los datos y modificarlos, usando para ello
un lenguaje de consulta y manipulación.
Brinde soporte al almacenamiento de cantidades voluminosas de datos durante un largo

período, protegiéndolo contra accidentes o utilización 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: Exportación e importación de datos de una plataforma a otra.
Rendimiento: Recuperación, actualización, concurrencia, etc. de una manera eficiente.
Universalidad: Múltiples tipos de datos (multimedia).
Disponibilidad: 7x24.
Aplicaciones clientes.
Gestion de los Recursos del kernel:

La instalación de PostgreSQL requiere la comprobación de que el servidor será capaz de
soportarlo.
Normalmente, los valores por defecto son más que suficientes. Estos recusos afectan a la
memoria compartida y a los semáforos. Será tarea del administrador de sistemas cambiar los
valores de los parámetros 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
instalación normal, los valores por defecto son suficientes.
Parámetros de PostgreSQL que afectan a la memoria compartida:
Corresponden con una órden de SQL ejecutadas dentro de la base de

datos, para saber más 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: creación 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 información sobre la versión 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 canónica para la ejecución de
sentencias SQL a través del shell del SO. Es una herramienta de tipo frontend que permite
describir sentencias SQL, ejecutarlas y visualizar sus resultados. El método de ingreso
puede ser mediante la inserción directa del código en la consola, o la ejecución de
sentencias dentro de un archivo de texto. Provee de diversos meta-comandos para la
ejecución 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 semáforos de un servidor PostgreSQL.
• pg_controldata: muestra información 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 automáticas a partir de paquetes (rpm, apt-get, etc) o en Windows, se

crea un cluster automáticamente 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 catálogo comunes a todas las bases de datos.
catalogo compartido: pg_shadow (usuarios), pg_database, etc.
• pgstat.stat: fichero usado por el monitor de estadísticas.
• pg_control: fichero con parámetros del cluster, algunos inmutables (establecidos en

la creación del cluster) y otros variables (establecidos en la puesta en marcha).
• pg_log: ficheros de seguimiento del servidor. Se crea en la versión 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 tamaño de 16Mb y
divididos en páginas de 8Kb.
• pg_clog: ficheros de diario para las transacciones (estado de cada transacción).

Contiene los ficheros de confirmacion. Un diario de confirmación refleja el estado de
cada transacción: 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: información 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 estén correctos.
Creación del cluster de bases de datos: initdb

Después de instalar PostgreSQL, lo primero que hay que realizar es la creación 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 cómo 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 + añadir 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, módulos opcionales
(tsearch2, lo, dblink, etc), tablas comunes, etc. Más adelante veremos cómo 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 más bases de datos?
Para modificar template1 no hay más 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 también en postgres para que tenga las mismas opciones.
Pero además, en el mundo del software libre se crea código para añadir nuevas
funcionalidades. Estos módulos los hemos añadido, por ejemplo, en la instalación 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 según los requerimientos de las
aplicaciones:
tsearch2: soporte para indexación 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 reconfiguración del servidor. Hace uso
________________________________________
12
__________________________________________________________
de la instrucción que actúa sobre el servidor postgres.
postmaster: proceso servidor de base de datos.
El comando pg_ctl es el que se usa normalmente, porque permite controlar más 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.
Internacionalización y localización:
Internacionalización: proceso de desarrollo de software de forma que pueda ser usado en
distintas ubicaciones.
Localización: proceso de adaptación de una aplicación para que sea usada en una ubicación
específica.
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 cómo está configurado en el SO ejecutar:
$ locale
Que nos mostrará la configuración activa, podemos cambiar la configuración entre

cualquiera de las que estén instaladas en el sistema operativo, para ver cuáles están
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 conversión automática entre servidor / cliente (en la tabla pg_conversion
están las conversiones por defecto.
Procesamiento de instrucciones:
Se produce un diálogo básico entre el proceso front-end (aplicación) y el proceso back-end
(postgres), que consta básicamente de los siguientes pasos:
1. La aplicación envía una instrucción al proceso postgres.
2. El servidor realiza en análisis y el proceso postgres responde OK o devuelve error.
3. La aplicación solicita la ejecución y el servidor la realiza, devolviendo Ok o error.
4. Por último la aplicación solicita la recuperación de los datos y el servidor responde con
los resultados de la instrucción.
Para el procesamiento de instrucciones PostgreSQL usa la caché de la base de datos (shared

buffers), colección de buffers de 8Kb en la memoria compartida y que sirven como caché de
las páginas 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 vacía, por ejemplo, cuando se produce un punto de
control (checkpoint) o simplemente se llena la lista.
Si la instrucción 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
operación tantas veces como sea necesario para ejecutar una instrucción.
Si la instrucción es una actualización de datos entran en juego también 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 están en los buffers compartidos y recuperar el valor antiguo.
2.Si no están 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 modiciación y se escribe en los shared buffers.
¡todavía no se han escrito los datos en disco!
________________________________________
14
__________________________________________________________
Gestión 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 transacción. Una transacción es un bloque de
operaciones o instrucciones dirigido a modificar una base de datos en una determinada
dirección.
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 transacción se guardan en
la base de datos. Si alguna operación falla, todas las operaciones son deshechas (rollback),
incluso aunque alguna operación haya sido realizada con éxito.
Solución
En PostgreSQL podemos hacer que un grupo de sentencias SQL se ejecuten dentro de una
transacción, encerrándolas entre las sentencias BEGIN y COMMIT. De esta forma
aseguramos que se ejecutan todas o ninguna. Si llegados a algún punto dentro de la
transacción 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

transacción) o inmediatas (se verifican en cada operación), en este caso, si alguna condición
no se cumple, la transacción queda en estado latente, algunas consultas no se pueden
realizar y las actualizaciones no tendrán efecto, con lo que solo se puede resolver
deshaciendo la transacción.
Por otro lado, PostgreSQL trata cualquier sentencia aislada como si ésta se ejecutara dentro
de una pequeña transacción; aunque no usemos BEGIN, cada sentencia incorpora
implícitamente un BEGIN y, si culmina con éxito, un COMMIT, a este modo se le conoce
como "modo autoconfirmación".
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 también las cumple.
Si al ejecutar una transacción, por el motivo que sea, se incumpliera alguna de estas reglas,
la transacción no se llegaría a completar. Esto garantiza que una base de datos siempre
permanezca en un estado válido, 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 transacción que está siendo ejecutada, son invisibles a cualquier otra
transacción hasta que la primera no haya sido completada con éxito. La ejecución no
perturba a otras transacciones que se ejecuten concurrentemente.
Solución:
Frente a otro modelos tradicionales que controlan el acceso concurrente a los datos a través
de bloqueos, PostgreSQL utiliza un modelo denominado Multiversion Concurrency Control
(MVCC), según el cual, al consultar la BD, cada transacción ve una instantánea de la BD tal
como era hace un cierto tiempo (una versión de la BD) y no el estado actual de la BD. Este
mecanismo evita que una transacción 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 transacción, 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 transacción se produce un apagado del servidor, una vez
reiniciado el servidor, un sistema que lleve un registro de transacciones realizadas,
advertiría rápidamente que existe una sin completar, finalizándola correctamente.
Solución:
PostgreSQL utiliza una técnica estándar 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) sólo se materializan cuando existe previamente en el disco un registro en el que
están anotados dichos cambios. Siguiendo este procedimiento, no es necesario enviar
páginas al disco cada vez que una transacción se completa. Esta técnica no sólo mejora el
rendimiento del servidor, sino que ante un fallo de la máquina, será posible recuperar la BD
a partir de ese registro: cualquier cambio no aplicado a las páginas de datos en el disco será
________________________________________
16
__________________________________________________________
nuevamente hecho desde el log (roll-forward recovery, o REDO) mientras que los posibles
cambios realizados en páginas de disco por transacciones incompletas, podrán ser deshechos
manteniendo la integridad y la consistencia de los datos (roll-backward recovery, o UNDO).
Estos ficheros de diario están en $PGDATA/pg_xlog, son ficheros de 16Mb, divididos en

páginas de 8Kb, el sistema crea uno inicialmente y va creando más según las necesidades,
rotando de manera cíclica según marquen los parámetros de sistema que gestionan este
funcionamiento (checkpoint_segments y archive_command).
Siguiendo con la instrucción (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 multiversión en los shared buffers.
3. Se retorna el control a la aplicación.
Entonces, los datos de los buffers no se han escrito en disco todavía, pero los del diario si,
así los datos de la transacción nunca se pierden.
Seguridad en PostgreSQL:
La seguridad en PostgreSQL se materializa en tres aspectos:
Seguridad en la manipulación de los ficheros de PostgreSQL.
Seguridad en los accesos de los clientes.
Definición de los privilegios para acceder a los objetos de la base de datos a los usuarios
PostgreSQL.
Seguridad en la manipulación de los ficheros:
La información más crítica 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 vía 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. Además hay un .s.PGSQL.5432.lock que sólo puede leer postgres.
________________________________________
17
__________________________________________________________
Los permisos de este socket se pueden configurar en postgresql.conf con los parámetros
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 configuración 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 irán procesando de arriba abajo, cuando se
encuentre una regla que cumpla la conexión, se ejecutará lo que ponga en el método.
Conexión local: usando los sockets del dominio Unix:
base_datos:
ALL: se permite la conexión 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 conexión a cualquiera de las bases de datos de la lista.
@fichero: se permite la conexión 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 conexión de cualquier role.
role1, [+]role2, : se permite la conexión de los roles de la lista y además se permite la

conexión de cualquier role que sea miembro de role2.
@fichero: se permite la conexión de los roles incluidos en el fichero, que debe estar en el
mismo directorio que pg_hba.conf.
Método-Autenticación:
TRUST: conexión aceptada sin condiciones.
REJECT: conexión 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 según como se creara el role.
CRYPT: palabra de paso encriptada (versiones previas a la 7.2).
________________________________________
18
__________________________________________________________
MD5: palabra de paso con el método de encriptación md5, y se almacena también con este
método. Es el método 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 envíado al servidor, en el servidor se utiliza la palabra de paso
almacenada, el ID del usuario (la obtiene de la conexión) 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 instalación del

servidor.
IDENT correspondencia: a partir del usuario de la conexión cliente (se fía de la

autenticación del cliente) y de la correspondencia indicada en la opción, se obtiene un role
de PostgreSQL para realizar la conexión. 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 conexión a la BD con el usuario con el usuario de la columna usuario-pg.
PAM servicio-pam: autenticación usando Pluggable Authentication Method proporcionado

por el servicio PAM indicado en opción. Este método es proporcionado por el SO. Se debe
compilar el servidor con esta opción. El PAM por defecto es postgresql. Se deben
configurar los métodos PAM del SO, generalmente basta con incluir la definición del un
nuevo método en el directorio /etc/pam.d.
Conexión 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 máscara 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
Conexión remota encriptada SSL usando TCP/IP (solo SSL):

La transmisión cliente-servidor es encriptada.
Los registros HOST se utilizarán para conexiones remotas no-SSL y SSL.
Los registros HOSTSSL sólo se utilizarán para conexiones remotas SSL.
Requiere instalar PostgreSQL con la opción 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 opción 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 lógico:
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 sesión se abre contra una base de datos.
Con lo que tenemos aquí los tres elementos principales a nivel lógico 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 versión 8 de Postgres
no se podían 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 cómo se deben crear
las bases de datos:
Si es un servidor que acoge proyectos separados y no se han de interrelacionar:

separación 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.
Creación 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 catálogo pg_authid y se
pueden consultar en las vistas pg_user y pg_roles.
________________________________________
24
__________________________________________________________
Desde el sistema operativo:
createuser [OPCIÓN]... [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 lÍmite de conexiones para el rol
(predeterminado: sin lÍmite)
-P, --pwprompt asignar una contraseña al nuevo rol
-E, --encrypted almacenar la constraseña cifrada
-N, --unencrypted almacenar la contraseña sin cifrar
-e, --echo mostrar los comandos a medida que se ejecutan
-q, --quiet no escribir ningún mensaje
--help desplegar esta ayuda y salir
--version desplegar información de versión y salir
Opciones de conexión:
-h, --host=ANFITRIÓN 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 contraseña 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 opción
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 contraseña ni privilegios adicionales. Tambien puede agregar
un usuario a un grupo ya existente y especificar una fecha en la que la contraseña 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 contraseña
como estrellas.
--Vista donde tenemos todos los usuarios almacenados:
[[local]:5432/postgres@postgres] [] # SELECT * from pg_user;
--Vamos a mostrar donde se almancenan las contraseñas:
[[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 contraseña 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 Nuñez

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 contraseña:
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 línea de comandos o SQL. En la línea 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
añadido 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 estén 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, existía el comando initlocation, que servía para

indicar ubicaciones alternativas para las bases de datos, y que exigía 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 simbólicos a

los directorios físicos donde se encuentran, esto es importante tenerlo en cuenta en procesos
como el cambio de ubicaciones o en la restauración 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 tamaño de que ocupa los TableSpace:
[[local]:5432/postgres@postgres] [] # SELECT
spcname,spclocation,pg_tablespace_size(spcname)/1024 "Tamaño MB"
FROM pg_tablespace
WHERE spclocation LIKE '/var/lib/pgsql/data/tablespace/tablespaces_datos%';
spcname | spclocation | Tamaño MB

---------+-------------+-----------
(0 rows)
Creación de bases de datos:

Una base de datos se puede crear desde la línea de comandos del sistema operativo (con el
usuario de sistema) o desde una conexión a una base de datos.(con un usuario que tenga
privilegios para crear bases de datos).
Desde el sistema operativo:
$ createdb [OPCIÓN]... [NOMBRE] [DESCRIPCIÓN]

Opciones:
-D, --tablespace=TBLSPC tablespace por omisión de la base de datos
-E, --encoding=CODIFICACIÓN codificación para la base de datos
-O, --owner=DUEÑO usuario que será dueño de la base de datos
-T, --template=PATRÓN base de datos patrón 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 versión y salir
________________________________________
32
__________________________________________________________
Opciones de conexión:
-h, --host=ANFITRIÓN nombre del servidor o directorio del socket
-p, --port=PUERTO puerto del servidor
-U, --username=USUARIO nombre de usuario para la conexión
-W, --password preguntar la contraseña
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 lógicos de objetos de
base de datos (tablas, vistas, procedimientos, etc.), básicamente son un espacio de nombres.
Es característico 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 notación esquema.objeto ya
que en PostgreSQL no existe el concepto de sinónimos 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 dueño 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 dueño ni tiene privilegios sobre la Bases
Datos HR,
--Tenemos que hacer login con el dueño 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 sesión 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 Actualización 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 añaden 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 línea, 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 línea
$ ps ax | grep postmaster |grep -v grep
que le dara la misma salida, pero sin incluir la línea 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
contraseña. 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 tamaño 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 tamaño 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
solución de problemas. Si desea ver mensajes de depuración de postmaster, puede iniciarlo
con la opción -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. Nótese 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 recuperación:

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 restauración 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 ejecución.
Copias de seguridad:
Las copias de seguridad son esenciales para las recuperaciones frente a fallos, se deben
determinar las frecuencia conveniente, que será función del tamaño 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 permitirán además poder
trasladar datos de unas bases de datos a otras.
________________________________________
55
__________________________________________________________
Además hemos de asegurarnos de que los logs, ficheros WAL, estén en otro disco, o hacer
copias más frecuentes de estos logs ya que en la versión 8 ya se pueden copiar
automáticamente y usar en la recuperación.
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 línea y recuperación 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 método más sencillo, pero el más 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 método:

La base de datos debe estar parada
No se pueden recuperar partes del cluster (bases de datos, esquemas, tablas, etc.)
La recuperación 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 permitirán hacer
copias de seguridad de toda la base de datos o de partes de ella, y luego, dada una copia de
seguridad, nos permitirán restaurar lo que
queramos.
Además, estas herramientas sirven para la transmisión 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 realizón 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 más flexible
Sólo 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 más 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 más 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 opción de indicar el fichero de salida, con lo cual hay que redireccionar la
salida a un fichero.
No tiene la opción de formatos de fichero de salida, la salida es siempre un fichero de texto

plano.
Tiene una opción muy interesante que es "-g" que permite exportar únicamente los objetos
globales, con lo que podemos generar un script que contenga la creación 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 además, tiene otro superusuario
$ pg_dump_all -g -h otroservidor -U otrosuperusuario -p 6432 > misusuarios.sql
-- Exportar solo los esquemas
$ pg_dumpall -s > misesquemas.sql
Recuperación con psql:

La recuperación 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 código 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 codificación 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.
Recuperación 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 selección.
Hay dos modos de hacerlo:
Directamente a una base de datos, es la opción 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
__________________________________________________________
Recuperación 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 transacción
confirmada.
Los ficheros de log permiten que además, la base de datos no tenga que estar
completamente actualizada (sync) para mantener los datos ante fallos en la memoria
principal (pérdida de valores en los bufferes compartidos).
Hay un número máximo 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
más logs.
El trabajo y el tiempo de recuperación dependen del número de checkpoint_segments,

cuanto mayor sea el sistema aguantará más tiempo sin llevar los búferes sucios a disco y
será más eficiente, aunque también se requiere más espacio en disco y las recuperaciones
requeriran más 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 tamaño 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 automáticamente
en nuestro sistema, digamos por ejemplo descargar un archivo de respaldo diariamente, o borrar
ciertos archivos periódicamente, ejecutar un script que haga algo, etc, digamos que podemos
automatizar las tareas, para no estar haciéndolas a mano.
¿Qué es cron?
Cron es el nombre del programa que permite a usuarios Linux/Unix ejecutar automáticamente
comandos o scripts (grupos de comandos) a una hora o fecha específica. Es usado normalmente
para comandos de tareas administrativas, como respaldos, pero puede ser usado para ejecutar
cualquier cosa. Como se define en las páginas 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 mayoría de las
distribuciones el servicio se instala automáticamente 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 también revisar a través 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 razón, 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, bastaría 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 encontrarás 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 día, 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/.
Nótese que la primera línea empieza con #!, que indica que se trata de un script shell de bash, las
demás líneas son los comandos que deseamos ejecute el script. Este script podría nombrarse por
ejemplo respaldo.sh y también 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
días, en un momento se entenderá el porque.
________________________________________
63
__________________________________________________________
Como segundo modo de ejecutar o usar cron es a través de manipular directamente el archivo
/etc/crontab. En la instalación 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 líneas 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 línea /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 envía 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 válido del
sistema o de algún otro sistema. Si no se especifica, entonces cron enviará el correo al usuario
propietario del comando que se ejecuta.
HOME es el directorio raíz o principal del comando cron, si no se indica entonces, la raíz 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 línea.
Después de lo anterior vienen las líneas que ejecutan las tareas programadas propiamente. No hay
límites de cuantas tareas pueda haber, una por renglón. Los campos (son 7) que forman estas líneas
están 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 múltiples 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 según la distribución), 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á automáticamente 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 través 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 sería agregar su
nombre de usuario en /etc/cron.allow, si por alguna razón 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 bastaría.
/****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 teoría el uso de cron esta entonces sin
restricciones de usuario. Si se añaden 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 tendrán que especificar los demás
usuarios que se quiere usen cron, en este archivo.
COMANDO chkconfig:
El comando chkconfig se usa para cambiar, actualizar y consultar información 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 través de la cual los administradores crean reglas para cada
filtrado de paquetes y módulos de NAT. Iptables es la herramienta estándar 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 versión 7.X no había recuperación total, si se producía una pérdida dentro del
$PGDATA, había que recurrir a la copia de seguridad física más reciente y desde ese
momento las actualizaciones se perdían, aunque tuviéramos los ficheros de log. Aquí es
donde, en la versión 8.X se incorpora el volcado en línea y la recuperación PITR.
Volcado en línea y recuperación PITR:

A partir de la versión 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 opción 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 renombrándolos a números
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, parámetro 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 línea 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 recuperación se siguen los siguientes pasos:
1. parar el postmaster
2. si tenemos espacio, copiar el cluster dañado y los tablespaces a otra ubicación
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 estarán 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 recuperación, 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 están en su sitio, no hay que tocar nada.
8. se arranca PostgreSQL que entra en modo de recuperación y procede a leer la

información de los WAL que necesite, siendo necesario evitar que se conecten usuarios
normales durante la recuperación.
9. inspeccionar la base de datos, si todo ha ido correcto, los datos estarán recuperados hasta
la última transacción 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
recuperación sea mejor. Para ello, debemos mover el directorio pg_xlog a otro disco y crear
un enlace simbólico, con el cluster parado.
Por ejemplo:
$ mkdir /disco2/pg/
$ cd $PGDATA
$ mv pg_xlog /disco2/pg
$ ln s /disco2/pg/pg_xlog pg_xlog
Además, para asegurarnos que no se nos pierden archivos de log, podemos hacer un cron
que copie los archivos que no están llenos en una ubicación distinta.
En el fichero recovery_conf hay una serie de parámetros que pueden ayudar a recuperar
hasta el momento o la transacción que queramos (lo que se conoce como recuperación
Point-in-time):
restore_command: lo que ejecuta esta variable es lo que PostgreSQL ejecutará antes de

empezar la recuperación.
________________________________________
68
__________________________________________________________
Por ejemplo:
restore_command = cp /mnt/server/archivedir/%f %p
recovery_target_time: hasta qué momento
recovery_target_xid: hasta una transacción 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 estadísticas usadas por el planificador / optimizador
• evitar la pérdida de datos muy antiguos debido al reuso del identificador de

transacción
/****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 más frecuencia sobre tablas con mucha carga de actualización.
Determinar las tablas grandes con pocas actualizaciones para eliminarlas del VACUUM.
Dentro del VACUUM, se pueden actualizar las estadísticas con la opción ANALYZE,
haciendo lo mismo que hace el comando ANALYZE, así proporciona:
1 información usada por el optimizador
1 no es muy pesado el proceso porque se realiza sobre una muestra al azar.

1 necesario si la distribución de los datos cambia mucho
El problema del XID (identificador de transacción):
Otro problema que resuelve VACUUM es el evitar la pérdida de datos muy antiguos,
porque MVCC introduce el concepto de marca de tiempo XID identificador de transacción.
________________________________________
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 perderían datos. Existen además dos XID
especiales: BootstrapXID y FrozenXID. Cada vez que se ejecuta VACUUM se guarda
información 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 ejecución de VACUUM, a partir de la versión 8,
PostgreSQL incorpora un proceso de fondo AUTOVACUUM que se ejecuta
periódicamente cuando está habilitado y él mismo comprueba las tablas con alta carga de
actualizaciones. Hay una serie de parámetros 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 páginas 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 catálogo 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 catálogo compartido (pg_database, pg_group, pg_shadow,

-- etc.). No se debe levantar postmaster si no que hay que arrancar un proceso
-- autónomo:
$ 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 añadimos estas líneas:
0 3 * * * psql -c 'VACUUM FULL;' test
________________________________________
70
__________________________________________________________
0 3 * * * vacuumdb -a -f
0 30 * * * reindexdb bd
¡ATENCIÓN!, 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 reindexación
de toda la base de datos implica que se puede duplicar el tamaño de los ficheros de la base
de datos, ya que el sistema de WAL crea archivos de log para cada cambio.
Monitorizacion:
La monitorización 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 monitorización 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 física y por otra la swap, también 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 dinámica se deben especificar los argumentos:
vmstat -n <numero de segundos por actualizacion >
Uso del disco (iostat, etc.)
● iostat informa repetidamente de las estadísticas 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
__________________________________________________________
--además también muestra una media en % del uso de CPU en la máquina.
[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 tamaño 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 tamaño ocupado por el server de PostgreSQL:
[postgres@jp ~]$du -sch data/

108M data/
108M total
________________________________________
73

Dba PostgreSQL

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Dba PostgreSQL

Hochgeladen von

Copyright:

Verfügbare Formate

Academia De Software Libre www.codigolibre.

Documentación Realizada Por:

Ing. Jose Paredes Meidy Alvarez

Meidy E. Alvarez Guerrero

Esta documentación es regida por los reglamentos de la GNU Free Documentation

¿Qué se espera de un SGBD?

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

Controle el acceso concurrente.

¿Qué exigiremos a un SGBD?

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

Portabilidad: Exportación e importación de datos de una plataforma a otra.

Rendimiento: Recuperación, actualización, concurrencia, etc. de una manera eficiente.

Universalidad: Múltiples tipos de datos (multimedia).

Gestion de los Recursos del kernel:

Parámetros 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 automáticas 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 estadísticas.

• pg_control: fichero con parámetros del cluster, algunos inmutables (establecidos en

• pg_log: ficheros de seguimiento del servidor. Se crea en la versión de Windows, en

• pg_xlog: ficheros de diario del servidor (WAL).

• pg_clog: ficheros de diario para las transacciones (estado de cada transacción).

• 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: información sobre los tablespaces. Cuidado porque en linux/unix

Creación 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 + añadir extensiones-contrib:

$ createlang plpgsql template1

$ createlang plpgsql postgres

Lo ejecutamos también en postgres para que tenga las mismas opciones.

tsearch2: soporte para indexación 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 instrucción que actúa sobre el servidor postgres.

postmaster: proceso servidor de base de datos.

• 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 cómo está configurado en el SO ejecutar:

Que nos mostrará la configuración activa, podemos cambiar la configuración 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

• pg_subtrans: para realizar los savepoints en medio de transacciones.

SQL# create database base2 with encoding win ;

/Ejemplos de conexiones remotas/

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