Dba-PostgreSQL

Academia De Software Libre www.codigolibre.org__________________________________________________________

PostgreSql

________________________________________2010 Manual De Administración de PostgreSql

1

http://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: 843Catalog version number: 200904091Database system identifier: 5470533823675219895Database cluster state: in productionpg_control last modified: Sat 05 Jun 2010 10:59:44 AM ASTLatest checkpoint location: 0/2E23574Prior checkpoint location: 0/2BBB43CLatest checkpoint's REDO location: 0/2E23574Latest checkpoint's TimeLineID: 1Latest checkpoint's NextXID: 0/3448Latest checkpoint's NextOID: 35751Latest checkpoint's NextMultiXactId: 1Latest checkpoint's NextMultiOffset: 0Time of latest checkpoint: Sat 05 Jun 2010 10:57:32 AM ASTMinimum recovery ending location: 0/0Maximum data alignment: 4Database block size: 8192Blocks per segment of large relation: 131072WAL block size: 8192Bytes per WAL segment: 16777216Maximum length of identifiers: 64Maximum columns in an index: 32Maximum size of a TOAST chunk: 2000Date/time type storage: 64-bit integers


11



Float4 argument passing: by valueFloat8 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 onlylocal all all trust# IPv4 local connections:host all all 127.0.0.1/32 trust# IPv6 local connections: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’***/

# TYPE DATABASE USER CIDR-ADDRESS METHOD

# IPv4 local connections: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)Type "help" for help.

[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'.***/

# TYPE DATABASE USER CIDR-ADDRESS METHOD# IPv4 local connections:host all mexy 0.0.0.0/0 md5

--Hagamos la coneccion


[192:5432/mexy@sacademico][]#

--Chevere--Lo mismo pero con diferente IP y DB.

-bash-4.0$ psql -U mexy -h 168.100.0.2 HRPassword for user mexy: Timing is on.psql (8.4.3)Type "help" for help.

[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 HRpsql: 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.***/

# TYPE DATABASE USER CIDR-ADDRESS METHOD# IPv4 local connections:host all all 0.0.0.0/0 password

--Probemos


[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

o

[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] [] # \setAUTOCOMMIT = '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 ObjetoCOMMENT 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 ParedesCREATE ROLE jparedesWITH LOGIN ENCRYPTED PASSWORD 'kikla'IN ROLE General;


27



--Usuario de OrangeCREATE ROLE orangeWITH LOGIN PASSWORD 'orange'IN ROLE General;

--Usuario de Deivi BolgesCREATE ROLE dbolgesWITH LOGIN PASSWORD 'venaito'IN ROLE General;

--Usuario de Felipe MateoCREATE ROLE fmateoWITH LOGIN PASSWORD 'gentoo'IN ROLE General;

--Usuario de Amaurys RodriguezCREATE ROLE arodriguezWITH LOGIN PASSWORD 'centos'IN ROLE CoronelVALID UNTIL '2010-05-30';

--Usuario de Felipe Cristhian NuñezCREATE ROLE cnunezWITH LOGIN PASSWORD 'salsa'IN ROLE Coronel;

--Usuario de Felipe Franky AlmonteCREATE ROLE falmonteWITH LOGIN PASSWORD 'bacula'IN ROLE Coronel;

--Usuario de Elvyn BolgesCREATE ROLE ebolgesWITH LOGIN PASSWORD 'bolsa'IN ROLE CaboVALID UNTIL '2010-06-01';

--Usuario de Lus MerlinCREATE ROLE lmerlinWITH LOGIN PASSWORD 'quimica'IN ROLE CaboVALID UNTIL '2010-05-31';

--Usuario de Henry TerreroCREATE ROLE hterreroWITH LOGIN PASSWORD 'java'IN ROLE henry;

--Usuario de Anyelina ColonCREATE ROLE acolonWITH 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_tablespaceWHERE 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 -eCREATE 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 relationsSchema | Name | Type | Owner --------+-----------------------+----------+----------public | countries | table | postgrespublic | departments | table | postgrespublic | employees | table | postgrespublic | job_history | table | postgrespublic | jobs | table | postgrespublic | locations | table | postgrespublic | regions | table | postgrespublic | 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 relationsSchema | Name | Type | Owner --------+-----------------------+----------+----------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)Type "help" for help.

[[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 ;ERROR: permission denied for relation 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)Type "help" for help.

[[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;ERROR: permission denied for relation employees

--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)Type "help" for help.

--Hacemos una consulta a la tabla cursos del Schema sacademicoschema:

[[local]:5432/hterrero@sacademico] [] > SELECT * from sacademicoschema.cursos;ERROR: relation "sacademicoschema.curso" does not existLINE 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:

[[local]:5432/hterrero@sacademico] [] > SELECT * from sacademicoschema.cursos limit 1;ERROR: permission denied for schema sacademicoschemaLINE 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:

[[local]:5432/hterrero@sacademico] [] > SELECT * from sacademicoschema.cursos limit 3;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@localhost(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;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;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;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;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 HRpsql (8.4.4)Type "help" for help.

--Luego vemos informacion sobre los permisos de los objetos exists, no tenemos:

[[local]:5432/falmonte@HR] [] > \z


39



: coronel=r/postgres : cnunez=w/postgres : arodriguez=d/postgres : general=arwdDxt/postgres

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)

-- Si queremos Permitir conceder el mismo privilegios a otro:

[[local]:5432/postgres@HR] [] # GRANT ALL ON locations TO coronel with grant option;

--Verificamos:

[[local]:5432/falmonte@HR] [] > \z Access privilegesSchema | Name | Type | Access privileges | Column access

privileges ----------+---------------------------+------------+-------------------------------------+----------------public | countries | table | postgres=arwdDxt/postgres |

: coronel=r/postgres : cnunez=w/postgres : arodriguez=d/postgres : general=arwdDxt/postgres

public | departments | table | | public | employees | table | | public | job_history | table | | public | jobs | table | | public | locations | table | postgres=arwdDxt/postgres |

: coronel=a*r*w*d*D*x*t*/postgres public | pepe | sequence | | public | regions | table | | public | regions_region_id_seq | sequence | | (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 ;ERROR: permission denied for relation countries

[[local]:5432/acolon@HR] [] > SELECT country_id from countries ;ERROR: permission denied for relation countries

[[local]:5432/acolon@HR] [] > SELECT name from countries ;ERROR: permission denied for relation countries

[[local]:5432/acolon@HR] [] > SELECT * from countries ;ERROR: permission denied for relation 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 -----------ArgentinaAustraliaBelgium(3 rows)

--Intentamos hacer SELECT a otra columna de la misma tabla:

[[local]:5432/acolon@HR] [] > SELECT country_id from countries ;ERROR: permission denied for relation 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';ERROR: permission denied for relation countries


42



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]$ls1 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

o

% 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: COPYDescription: copy data between a file and a tableSyntax: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.copJoseMexyBiancaJoelJorge

--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 5Time: 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 5Time: 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.copJose, ParedesMexy, AlvarezBianca, SAntanaJoel, SantosJorge, 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 5Time: 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 | ParedesMexy | AlvarezBianca | SAntanaJoel | SantosJorge | 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_dumpall se 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 -lList of databasesName | Owner | Encoding | Collation | Ctype | Access privileges --------------+---------------+-----------+-----------------+-------------+--------------HR | fcld | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =Tc/fcld

: fcld=CTc/fcldpoma | 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/postgressacademico | sacademico | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres

: postgres=CTc/postgrestemplate1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres

: postgres=CTc/postgres(7 rows)

--Haciendo Backup de la Bases Datos HR:

[postgres@jp ~]$pg_dump -v HR > HR_Backup.sql


59



--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.sqlPassword: 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/bashDIR=/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 cronCron 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 cronHay 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 respaldocd /usr/documentostar czf * respaldocp 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 crontabLinux 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 cronCron 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.

[root@guerrero ~]# chkconfig --list iptables 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

[root@guerrero ~]# chkconfig --list iptables

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 %precovery_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 pomavidVACUUM 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 CMD5668 ? 00:00:01 postmaster5970 ? 00:00:00 postmaster5972 ? 00:00:00 postmaster5973 ? 00:00:00 postmaster5974 ? 00:00:00 postmaster5975 ? 00:00:01 postmaster7830 ? 00:00:00 postmaster7831 ? 00:00:00 postmaster7850 ? 00:00:00 postmaster8090 pts/1 00:00:01 bash8160 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_toplast pid: 14812; load avg: 0.74, 0.43, 0.33; up 0+02:55:34 12:07:284 processes: 4 sleepingCPU states: 10.3% user, 0.0% nice, 3.0% system, 86.7% idle, 0.0% iowaitMemory: 1613M used, 2365M free, 103M buffers, 860M cachedSwap: 8000M free

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND7831 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 2procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------r b swpd free buff cache si so bi bo in cs us sy id wa st0 0 0 2421036 105964 880432 0 0 37 36 558 826 8 2 89 2 00 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 2Linux 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_wrtnsda 10.53 144.87 142.59 1557037 1532508sda1 0.01 0.19 0.00 2012 4sda2 10.52 144.65 142.59 1554721 1532504dm-0 2.12 22.06 11.36 237146 122088dm-1 0.04 0.31 0.01 3282 56dm-2 4.09 75.25 12.52 808794 134520dm-3 11.38 35.92 76.29 386026 819944dm-4 6.15 11.02 42.42 118465 455896dm-5 0.01 0.05 0.00 576 0sdb 0.03 0.88 0.00 9474 2sdb1 0.03 0.84 0.00 9018 2dm-6 6.11 10.93 42.42 117514 455896sdc 0.04 0.26 0.00 2814 17sdc1 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% /boottmpfs 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

Documents

Transcript of Dba-PostgreSQL