PGSQL

Curso de Bases de Datos relacionales usando PostgreSQL en entornos Linux
Lic. Martn A. Marqus <martin.marques@gmail.com>
II
Derechos de Autor c 2007-2008 Martn A. Marqus. Todos los derechos reservados.
No esta permitida la reproduccin total o parcial de esta obra, ni su tratamiento o transmisin por cualquier medio o mtodo sin autorizacin escrita del autor.
Cursos de OSS
http://trac.marquesminen.com.ar/cursos/
Prlogo
Este documento lo he realizado para el dictado de los cursos de PostgreSQL que he dado. Al momento, esta basado en PostgreSQL versin 8.3.1. El interes mo es ir mejorando el documento con el tiempo, haciendo que evolucione con la salida de nuevas versiones de este motor de bases de datos, y si es posible publicarlo. Adems, hay un inters mo de difundir conocimientos y experiencias en el uso de este motor de bases de datos, que contiene capacidades similares a productos comerciales del mismo rubro, pero manteniendo el espiritu del Software Libre.
III
IV
Cursos de OSS
ndice general
1. Introduccin de PostgreSQL 1.1. Breve historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Caractersticas del sistema . . . . . . . . . . . . . . . . . . . . . 2. Instalacin de PostgreSQL 2.1. Instalacin de fuentes . . . . . . . . . . . . 2.1.1. Conguracin de la instalacin . . . 2.1.2. Compilacin e instalacin . . . . . 2.2. Instalacin usando binarios empaquetados . 2.3. Inicializacin del motor de la base de datos 2.4. Levantando el servicio de Bases de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 5 6 6 9 10 12 14 17 17 19 20 20 21 22 22 23 24 25 26 27 27 28 30 31 31 31
3. Conguracin 3.1. Conguracin general del servidor . . . . . . . . . . . . . . . . . 3.2. Conguracin de los parmetros de conexin . . . . . . . . . . . 3.3. Seguridad y autenticacin . . . . . . . . . . . . . . . . . . . . . . 3.4. Usos de memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5. Mapa de espacio libre . . . . . . . . . . . . . . . . . . . . . . . . 3.6. WAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1. Conguracin de WAL . . . . . . . . . . . . . . . . . . . 3.6.2. Puntos de control de WAL . . . . . . . . . . . . . . . . . . 3.7. Constantes de costo del planicador . . . . . . . . . . . . . . . . 3.8. Otras opciones del planicador . . . . . . . . . . . . . . . . . . . 3.9. Opciones de limpieza y recoleccin de estadstica: autovacuum 3.10. Conguracin de registros de PostgreSQL . . . . . . . . . . . . . 3.10.1. Conguracin general . . . . . . . . . . . . . . . . . . . 3.10.2. Cundo escribir registros . . . . . . . . . . . . . . . . . . 3.10.3. Qu datos escribir en los registros . . . . . . . . . . . . . 3.11. Estadsticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11.1. Monitoreo de estadsticas . . . . . . . . . . . . . . . . . . 3.11.2. Recolector de estadsticas de consultas e ndices . . . . .
V
VI
ndice general 3.12. Valores predeterminados para conexiones de clientes . . . . . . . 3.12.1. Formato y localizacin . . . . . . . . . . . . . . . . . . . 32 32 33 33 33 36 36 38 38 40 41 42 43 44 46 47 48 49 50 50 53 53 54 55 55 59 59 60 61 65 66 67 69 71 72
4. Administracin 4.1. Congurando accesos a la Base de Datos . . . . . . . . . . . . . . 4.1.1. Conguracin del archivo pg_hba.conf . . . . . . . . 4.2. Creacin de Bases de Datos . . . . . . . . . . . . . . . . . . . . . 4.3. Administracin de Roles de Bases de Datos . . . . . . . . . . . . 4.4. Tareas de Administracin . . . . . . . . . . . . . . . . . . . . . . 4.4.1. Limpiando y buscando estadsticas (Vacuum y Analyze) . 4.4.2. Copias de respaldo con pg_dump y pg_dumpall . . . 4.5. Respaldo de archivos WAL y PITR . . . . . . . . . . . . . . . . . 4.5.1. Preparando para archivar los registros de WAL . . . . . . . 4.5.2. Realizar un respaldo inicial . . . . . . . . . . . . . . . . . 4.5.3. Restaurando la Base de Datos con los Respaldos Continuos de Archivos de WAL . . . . . . . . . . . . . . . . . . 4.5.3.1. Preparando conguracin para restaurar copia . 4.5.4. Advertencias y cuidados . . . . . . . . . . . . . . . . . . 4.6. Actualizacin de PostgreSQL . . . . . . . . . . . . . . . . . . . . 4.6.1. Actualizacin fcil en Debian . . . . . . . . . . . . . . . 4.6.2. Otras cosas a tener en cuenta . . . . . . . . . . . . . . . . 4.7. Usando el catlogo de PostgreSQL . . . . . . . . . . . . . . . . . 5. Monitoreo de actividad de la base de datos 5.1. Uso de herramientras de administracin del Sistema Operativo 5.2. Buscando procesos que poseen Locks . . . . . . . . . . . . 5.3. Vericando uso de disco desde el motor . . . . . . . . . . . . 5.3.1. Quin est usando el espacio de disco? . . . . . . . .
. . . .
. . . .
6. Interactuando con el motor de la base de datos 6.1. Aplicacin de lnea de comandos: psql . . . . . . . . . . . . . . 6.1.1. Argumentos de psql . . . . . . . . . . . . . . . . . . . 6.1.2. Comandos especiales . . . . . . . . . . . . . . . . . . . . 7. Alta disponibilidad y balanceo de cargas 7.1. Replicacin de las Bases de Datos con Slony-I . . . . . . . . . . . 7.1.1. Conguracin de los archivos slon.conf y slon_tools.conf 7.1.2. Iniciando la replicacin . . . . . . . . . . . . . . . . . . . 7.2. Pool de conexiones: pgpool-II . . . . . . . . . . . . . . . . . . . 7.2.1. Replicacin ms Balanceo de Carga . . . . . . . . . . . .
Cursos de OSS
ndice general 8. Aplicaciones para ayudar en las tareas administrativas macin 8.1. pgAdmin III . . . . . . . . . . . . . . . . . . . . . . 8.2. phpPgAdmin . . . . . . . . . . . . . . . . . . . . . 8.3. Postgresql Autodoc . . . . . . . . . . . . . . . . . . 8.4. PG IO Monitor . . . . . . . . . . . . . . . . . . . . 8.5. pgTop: Top de procesos de PostgreSQL . . . . . . . 8.6. pgFouine: Analizador de Logs . . . . . . . . . . . . y de progra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VII
73 73 75 82 83 84 84
Cursos de OSS
VIII
ndice general
Cursos de OSS
ndice de guras
4.1. Ejemplo de archivo de recuperacin recovery.conf . . . . . . . 46 4.2. Dump y restore en una sola lnea . . . . . . . . . . . . . . . . . . 50 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. Bases de datos disponibles en nuestro Cluster . . . . Ingresando a psql . . . . . . . . . . . . . . . . . . . . Listado de tablas de la base de datos prueba . . . . . . Listado de los ndices de la base de datos prueba . . . . Detalle de la tabla usuarios . . . . . . . . . . . . . . . Recuperando datos desde un archivo SQL de dos formas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 61 62 63 63 64
7.1. Archivo slon_tools.conf . . . . . . . . . . . . . . . . . . . . . . . 69 8.1. Ventana de conguracin de una conexin nueva en pgadmin3 . . 8.2. pgadmin3 mostrando toda la estructura del Cluster, bases de datos, esquemas, tablas y el SQL que se uso para crear dicha tabla . 8.3. Ventana para ejecutar consultas SQL y ver los resulados . . . . . . 8.4. Ventana para ejecutar consultas SQL y ver los resulados . . . . . . 8.5. Listado de las bases de datos . . . . . . . . . . . . . . . . . . . . 8.6. Marco central con todas las Bases de Datos dispoibles e informacin sobre ellas . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7. Marco principal mostrando la estructura de una tabla seleccionada 8.8. Marco central mostrando los datos de una tabla tras usar la opcin examinar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.9. Formulario para crear una nueva tabla . . . . . . . . . . . . . . . 8.10. Ventana para ejecutar cdigo SQL . . . . . . . . . . . . . . . . . 74 75 76 76 79 79 80 80 81 82
IX
ndice de guras
Cursos de OSS
Captulo 1 Introduccin de PostgreSQL

1.1. Breve historia
La historia de PostgreSQL comienza en la Universidad de California en Berkeley, donde entre los aos 1977 y 1985 se desarroll Ingres, el antecesor de PostgreSQL . Luego, tambin en Berkeley, Michael Stonebraker encabez un grupo que desarrollara un servidor de base de datos objeto-relacional, basado en Ingres, llamada Postgres entre 1986 y 1994. Los estudiantes graduados de Berkeley Jolly Chen y Andrew Yu agregaron soporte para el lenguaje SQL a Postgres y lo llamaron Postgres95. A principios del 1996, con la notable demanda de un servidor de base de datos SQL de cdigo libre, se form un grupo que continu el desarrollo. As fue como se cre PostgreSQL , haciendo honor al nombre con el que naci en Berkeley y al lenguaje SQL.
1.2. Caractersticas del sistema

Cdigo Abierto (Licencia BSD). Integridad Referencial: Posibilidad de atar campos de dos tablas con referencias de llaves forneas a una llave primaria de la otra tabla. MVCC: Multi-Version Concurrency Control (Control de Concurrencias de Mltiples Versiones). Mxima compatibilidad posible con el lenguaje ANSI SQL. Cumple con las premisas del ACID test (Atomicidad, Consistencia, Aislamiento, Durabilidad). 1
Captulo 1. Introduccin de PostgreSQL Bloqueo de tabla a nivel de las (Row level locking): til para luego actualizar alguno o todos los campos de los registros bloqueados en dicha tabla, con la garanta de que otra conexin no los modique. Esto se hace con el comando SELECT ... FOR UPDATE. Replicacin: soluciones comerciales y no comerciales que permiten la duplicacin de bases de datos maestras en mltiples sitios de rplica. La ms conocida es Slony-I. Interfaces nativas para ODBC, JDBC, C, C++, PHP, Perl, TCL, ECPG, Python y Ruby. Vistas. Reglas. Disparadores (Triggers). Secuencias: Objetos que son conocidos en motores como Oracle y sirven para generar secuencias de nmeros enteros. Outer Joins. Sub-selects. Procedimientos almacenados. Soporte nativo SSL. Lenguajes procedurales: PL/pgSQL, PL/Perl, PL/PHP, PL/Java, PL/Python, etc. Respaldo en caliente: Se pueden realizar copias de seguridad sin la necesidad de sacar el servidor de sus funciones habituales. ndices parciales y funcionales: Usando una clasula WHERE en la creacin del ndice har que slo los registros que cumplan con dicha condicin sean indexados (de ah que se los llame parcial). Si por otra parte en vez de indicar una columna a indexar, usamos una funcin, como por ejemplo lower(nombre_campo), el ndice almacenar los valores que devuelve la funcin aplicada al campo y no los datos del campo. Este ndice no se usar si en la restriccin la columna no se usa con la funcin especicada. Autenticacin Kerberos nativa. Soporte para consultas con UNION, UNION ALL y EXCEPT. Extensiones para SHA1, MD5, XML y otras funcionalidades. Herramientas para generar SQL portable para compartir con otros sistemas compatibles con SQL.
Cursos de OSS
1.2. Caractersticas del sistema
Sistema extensible para proveer tipos de datos denidos por el usuario, y rpido desarrollo de nuevos tipos. Funciones de compatibilidad para ayudar en la transicin desde otros sistemas menos compatibles con SQL. Una vez iniciado PostgreSQL , se pondr a correr el servidor (el programa postmaster) que escuchar en el puerto 5432 (o el puerto que se le haya especicado al iniciar el motor). El postmaster quedar esperando por nuevas conexiones, y cada vez que se abra una nueva, crear un proceso hijo que se encargar de manejar las consultas o comandos requeridos y toda la conexin con el cliente. De ah que, segn la cantidad de clientes que se vayan a conectar a la base de datos simultneamente (que puede obtenerse de estudios del sistema, o de la prctica, una vez que la aplicacin est en funcionamiento), ser importante el valor que tendr la variable max_connections, que se ver en la seccin 3.2.
Cursos de OSS
Captulo 1. Introduccin de PostgreSQL
Cursos de OSS
Captulo 2 Instalacin de PostgreSQL

PostgreSQL por ser una aplicacin de Cdigo abierto permite la compi-
lacin de fuentes. Por lo general esto no es necesario, ya que existen (salvo en contados casos) binarios del motor para los distintos sistemas operativos. En el caso de Linux, existen tambin paquetes para las distintas distribuciones. A pesar de ello, es recomendable saber cmo compilarlo ya que uno se puede encontrar con que no existen binarios para el sistema operativo que debe usar, o para la arquitectura del procesador. Lo ms aconsejable es buscar el paquete que viene con la distribucin que se esta usando. Dichos paquetes ya traen herramientas para inicializar la base de datos, generalmente en el mismo script de inicio1 , haciendo mucho ms fcil la puesta en marcha del servidor. Esto no debe, obviamente, tomarse como se instala y listo ya que hay muchas cosas para congurar, de lo contrario tendramos un motor con bajo rendimiento. Por ejemplo, en Debian se conguran automticamente tareas que se corren cada cinco horas ejecutando vacuum (para ms informacin ver la seccin 4.4.1) a cada base de datos, tarea que puede ser insuciente en algunas ocasiones, o excesiva en otras. De todas formas, veremos como se instala PostgreSQL de fuentes, y como se termina de congurar para dejar el servidor andando. Ms adelante, en la seccin 4.6, veremos los pasos adicionales que debemos tener en cuenta para realizar una actualizacin de PostgreSQL entre versiones diferentes.
1 De acuerdo a las distintas distribuciones, los scripts de arranque se pueden encontrar en lugares diferentes, como /etc/init.d/postgresql o /etc/rc.d/init.d/postgresql
Captulo 2. Instalacin de PostgreSQL
2.1. Instalacin de fuentes

Para poder compilar PostgreSQL se necesitan los fuentes, que pueden obtenerse en:
http://www.postgresql.org/download/
Una vez que tenemos los fuentes, podemos proceder a descomprimirlos y comenzar la conguracin. Para descomprimir los fuentes vamos a necesitar tener instaladas las utilidades bzip22 y GNU tar (estas aplicaciones estn en la mayora de las distribuciones de Linux o pueden ser instaladas sin mayores esfuerzos). La descompresin se hace con los siguientes pasos:
martin $ bunzip2 postgresql-8.3.1.tar.bz2 martin $ tar xf postgresql-8.3.1.tar martin $ ls postgresql* postgresql-8.3.1.tar postgresql-8.3.1 martin $
A continuacin nos situamos en el directorio que acaba de crearse, y que contiene los fuentes de nuestro motor de bases de datos. Dentro de dicho directorio se encuentran varias carpetas y algunos archivos. Uno de esos archivos se llama configure 3 y es un script que sirve para congurar la posterior compilacin e instalacin de los fuentes.
2.1.1.
Conguracin de la instalacin
El script configure tratar de buscar en el sistema aplicaciones, bibliotecas y archivos necesarios para la compilacin, y de acuerdo a lo que encuentre, agregar soporte para las distintas partes del motor PostgreSQL . Adems, hay bibliotecas y aplicaciones que deben estar en el sistema si o si, y en caso de no encontrarlas configure terminar un un mensaje de error y retornar un valor distinto de cero. Si ejecutamos configure sin opciones, usar valores predeterminados para inspeccionar el sistema y congurar la instalacin. El archivo configure tiene una opcin especial, --help, para ver todas las opciones de conguracin disponibles. Si se ejecuta slo con esta opcin, se mostrar en pantalla las opciones que tiene el script y concluir la ejecucin. Vamos a ver algunas de las opciones en profundidad:
Los fuentes tambin pueden bajarse en formato comprimidos con gzip Los interesados en saber ms sobre como se genera este script pueden buscar en los manuales y documentacin en internet de las herramientas autoconf y automake
3 2
Cursos de OSS

martin $ ./configure --help configure configures PostgreSQL 8.3.1 to adapt to many kinds of systems. Usage: ./configure [OPTION]... [VAR=VALUE]...
La manera de usar configure, como dice la ayuda en ingls, es ejecutar el script con las distintas opciones que se necesitan. Dichas opciones se vern a continuacin. Adems se pueden agregar variables de entorno que deba usar el script, como por ejemplo el nombre del compilador, opciones de compilacin, etc.
Installation directories: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local/pgsql]
--prefix especica dnde se van a instalar los programas de PostgreSQL . La ruta que se usa por defecto, que aparece entre corchetes (/usr/local/pgsql),
es recomendable para la mayora de los sistemas que se instalan del cdigo fuente (las versiones empaquetadas instalan distintas partes del motor en distintos directorios, como se ver en la seccin 2.2)
Optional Features: --enable-nls[=LANGUAGES] enable Native Language Support
Habilita el uso de soporte de lengua nativa (Native Language Support), que es la habilidad para que un programa muestre mensajes en otro idioma que no sea ingls. LANGUAGES debe ser una lista de idiomas separados por espacios (por ejemplo --enable-nsl=es pt). Si no se especica una lista de idiomas se tomarn todos los que estn disponibles en el sistema. Para usar esta opcin debe tener instalada alguna implementacin de gettext, por ejemplo, GNU/Gettext, y sus correspondientes archivos de desarrollo.
--with-includes=DIRS --with-libraries=DIRS --with-libs=DIRS look for additional header files in DIRS look for additional libraries in DIRS alternative spelling of --with-libraries
Estas opciones son para indicar otros directorios donde poder encontrar cabeceras y bibliotecas de aplicaciones que deban usarse al momento de compilar.
--with-pgport=PORTNUM change default port number 5432
Esto indica cual ser el puerto en el que escuchar por defecto PostgreSQL para comunicaciones por TCP (congurable al iniciar el servidor como se ver en la seccin 3.1). Por lo general est bien dejar el valor predeterminado, o sea, no usar esta opcin.
Cursos de OSS
8
--with-tcl --with-tclconfig=DIR

build Tcl modules (PL/Tcl) tclConfig.sh is in DIR
Opciones necesarias para compilar soporte de PL/Tcl. Para usar estas opciones, debe tener instalada una implementacin de Tcl, y sus correspondientes archivos de desarrollo (por lo general cabeceras necesarias para compilar).
--with-perl --with-python build Perl modules (PL/Perl) build Python modules (PL/Python)
Especando estas opciones se compilar soporte de lenguajes procedurales PL/Perl y PL/Python respectivamente. Perl y Python, y sus archivos de desarrollo deben estar respectivamente instalados para usar estas opciones.
--with-krb5[=DIR] --with-krb-srvnam=NAME --with-pam --with-ldap build with Kerberos 5 support [/usr/athena] name of the service principal in Kerberos postgres build with PAM support build with LDAP support
Esta opcin da soporte de autenticacin por Kerberos o a travs de un Pluggable Authentication Module (Mdulo de Autenticacin insertable).
--with-openssl build with OpenSSL support
Compilar con soporte de SSL. Esto es necesario si quiere que las comunicaciones vayan por canales encriptados. Una vez que hemos analizado las opciones, simplemente ejecutamos configure con las opciones deseadas, una detrs de la otra, separadas por un espacio. Por lo general con ejecutar configure sin opciones es suciente. Una vez ejecutado se puede observar como el script nos va diciendo paso a paso lo que est haciendo y con qu resultado. Por ejemplo, si est vericando que nuestro compilador funciona correctamente primero dir, casi siempre en idioma ingls, que est tratando de compilar un pequeo programa y a continuacin si tuvo xito o no. Algunas opciones pueden fallar, quitndose el soporte para dicho mdulo u opcin de PostgreSQL . Pero si falla una opcin como la enunciada anteriormente (fall al intentar compilar) el script de configure terminar con un error y un mensaje explicando por qu no pudo terminar (por lo general dando pistas de cmo corregir el problema).
Cursos de OSS
2.1.2. Compilacin e instalacin

Si la ejecucin del script configure termin con xito, podemos pasar a la etapa de compilacin de PostgreSQL . Gracias al esfuerzo de buena parte de la comunidad de Software Libre esto es muy sencillo. Primero, porque todo el sistema de compilacin de PostgreSQL est centrado en GNU autoconf, GNU automake y GNU make. Para eso existe configure que har casi toda la conguracin por nosotros, generando los archivos Makefile que usar make. Lo nico que tenemos que hacer ahora es ejecutar make4 .
martin $ make
A continuacin comenzarn a aparecer mensajes de compilacin, no slo diciendonos que se est ejecutando, sino tambin la salida de los comandos de compilacin. Si todo sale bien, ya estarn nuestros binarios listos para ser instalados (se debe recordar que los fuentes fueron compilados en el directorio /home/martin/postgresql-8.3.1 que por lo general no es accesible para los dems usuarios del sistema). Antes de que se copien los archivos en el directorio donde van a quedar denitivamente, debemos vericar que exista el usuario postgres y el grupo postgres, necesarios para que funcione nuestro motor de base de datos. Estas tareas las debe realizar una persona que conozca el sistema y tenga acceso a la cuenta de root (super-usuario del sistema). Una vez que el usuario y grupo estn cargados en el sistema se puede comenzar con la instalacin, usando nuevamente make pero con una opcin adicional:
root # make install
Esto instalar todos los archivos necesarios para que el motor de la base de datos funcione, las bibliotecas adicionales para que otras aplicaciones puedan conectarse al motor, archivos de cabeceras para poder compilar aplicaciones con soporte para esta base de datos (dichas aplicaciones hablarn con el motor a travs de las bibliotecas antes mencionadas), aplicaciones adicionales (veremos algunas en las secciones 6.1 y 4.4.2) y la documentacin. Ahora, como se realiz una instalacin manual, muchas cosas de nuestro sistema van a estar en directorios que el mismo (el sistema operativo) no reconoce. Para eso hay que hacer algunos ajustes. Para empezar hay que indicarle al sistema dnde van a estar las bibliotecas de PostgreSQL , para que cuando las puedan usar otras aplicaciones que requieren hablar con PostgreSQL a travs de la biblioteca libpq.
4 make es una poderosa herramienta que casi siempre se usa al compilar, pero que puede usarse para hacer cualquier otra tarea
Cursos de OSS
10
En la mayora de los Linux, esto se hace agregando la ruta donde fueron instaladas dichas bibliotecas en el archivo /etc/ld.so.conf y ejecutando el programa ldconfig para que dichos cambios se actualicen. Tal accin no es necesaria si, por ejemplo, agregamos opciones en el configure para que al instalar, las bibliotecas se instalen en /usr/lib o /lib, o posiblemente /usr/local/lib (esta ltima no siempre est en /etc/ld.so.conf) con la opcin --libdir=[DIR]. Tambin es conveniente, aunque no necesario, incluir el directorio donde se han instalado los binarios (las aplicaciones) en la ruta de bsqueda de aplicaciones5 . Por ejemplo, si en la conguracin no se han modicado las opciones predeterminadas de dnde ubicar los distintos componentes de PostgreSQL , los binarios estarn en /usr/local/pgsql/bin y dicha ruta conviene que est incluida en PATH, para poder ejecutar, por ejemplo, psql6 sin necesidad de indicar toda la ruta. Una vez que terminamos con esto exitosamente, podemos pasar a la seccin 2.3 y seguir con la conguracin e inicializacin del motor de bases de datos.
2.2. Instalacin usando binarios empaquetados

La instalacin de binarios empaquetados es la forma fcil de hacer una instalacin de PostgreSQL y seguidamente veremos cmo se realiza la instalacin para dos distribuciones: Fedora y Debian. En el caso de Fedora y las dems distribuciones basadas en rpm (Mandriva, SuSE, etc.), lo mejor es buscar los rpm de PostgreSQL que viene con la distribucin que se est usando, e instalarlos. En caso de preferir una versin ms nueva de PostgreSQL de la que viene con su distribucin, puede tratar de bajar los rpm, o mejor an, los srpm (fuentes en formato rpm), del sitio de PostgreSQL :
http://www.postgresql.org/ftp/binary/v8.3.1/linux/srpms /fedora/fedora-8-x86_64/
general la persona encargada de armar los rpm de PostgreSQL , los prueba con distintas versiones de Red Hat y Fedora, pero no en las otras distribuciones, por lo que puede no funcionar en ellas (problemas de dependencias por lo general). Por eso se recomienda usar los paquetes que vienen con la distribucin que se esta usando, y si la versin de PostgreSQL es muy vieja, lo mejor es actualizar el servidor a una versin que s tenga esa versin de PostgreSQL .
5 6
En
esto se realiza seteando la variable de entorno PATH veremos esta aplicacin en la seccin 6.1 http://trac.marquesminen.com.ar/cursos/
Cursos de OSS
2.2. Instalacin usando binarios empaquetados
11
Tanto Debian y Fedora, tienen herramientas para instalar de manera automtica paquetes que vienen distribuidos. Esto hace muy fcil todo lo que hemos visto antes, y se recomienda usar esta forma. En Fedora hay una herramienta escrita en python llamada yum (viene de Yellow Dog Update Manager7 ). Para ello llamamos al programa como superusuario (ya que es quien tiene privilegios para instalar) con las opciones update, install o search. El siguiente ejemplo muestra como instalar el servidor de PostgreSQL en Fedora usando yum:
root # yum install postgresql-server.x86_64 Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package postgresql-server.x86_64 0:8.2.7-1.fc8 set to be updated --> Finished Dependency Resolution Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: postgresql-server x86_64 8.2.7-1.fc8 updates 4.1 M Transaction Summary ============================================================================= Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 4.1 M Is this ok [y/N]: y Downloading Packages: (1/1): postgresql-server- 100% |=========================| 4.1 MB 00:45 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: postgresql-server ######################### [1/1] Installed: postgresql-server.x86_64 0:8.2.7-1.fc8 Complete!
La herramienta que viene con Debian (es la herramienta para instalar, desinstalar y actualizar paquetes por defecto) se llama apt, e incluye dos comandos: apt-get y apt-cache. El primero sirve para instalar o actualizar paquetes, mientras que el segundo se usa para hacer busquedas o ver dependencias, polticas de instalacin, etc. Con estas herramientas pueden buscar paquetes usando palabras de bsqueda e instalar dicho paquete, previa descarga del mismo.
7
Yellow Dog es una dsitribucion basada en rpm
Cursos de OSS
12
root # apt-get update Hit http://security.debian.org stable/updates/main Packages ... root # apt-get install postgresql-8.3 Leyendo lista de paquetes... Hecho Creando rbol de dependencias Leyendo la informacin de estado... Hecho Se instalarn los siguientes paquetes extras: libpq5 libreadline5 postgresql-client-8.3 postgresql-common Paquetes sugeridos: postgresql-doc-8.3 Se instalarn los siguientes paquetes NUEVOS: libpq5 libreadline5 postgresql-8.3 postgresql-client-8.3 postgresql-common 0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded. Do you want to continue? [Y/n]
Con la respuesta Y comenzar la descarga de los paquetes que deben instalarse y al concluir se irn instalando uno por uno. En el caso de Debian el paquete tiene la posibilidad de irse congurando durante la instalacin, dicindole dnde quiere que se alojen las bases de datos, y otras opciones que se puedan congurar (conjunto de caracteres, usuario y grupo). Adems verica la existencia de los usuarios que son necesarios para arrancar el motor de base de datos. Cuando todo termina ya est listo para inicializar el motor, levantar el servicio y tenerlo esperando por conexiones.
2.3. Inicializacin del motor de la base de datos

Al terminar por primera vez de instalar PostgreSQL (o casi cualquier otro motor de base de datos) hay que inicializar el espacio de almacenamiento de datos en disco (tambin conocido como Cluster). Esto se realiza en PostgreSQL con el comando initdb. El usuario que usemos para inicializar el espacio de la base de datos ser el super-usuario del Cluster, teniendo jerarqua similar a la de root en los sistemas operativos UNIX. Por lo general se usa el usuario postgres que ya se ha creado (ver seccin 2.1 si instal PostgreSQL de fuentes, o 2.2 si lo instal de binarios). Hay que tener en cuenta, si se est trabajando con versiones empaquetadas que vienen con la distribucin, que pueden tener scripts para automatizar la creacin del Cluster. Pero antes de inicializar la base de datos, se deben tomar algunas decisiones, que aunque muchas veces triviales, si son omitidas podemos terminar con resultados no deseados. Primero debemos analizar qu conjunto de caracteres vamos a usar. Esto es importante, especialmente para los hispano parlantes, ya que afecta cmo se almacenarn los caracteres en nuestra base de datos. Por eso lo recomendable para
Cursos de OSS
2.3. Inicializacin del motor de la base de datos
13
bases de datos que almacenan texto en espaol, es usar codicacin de caracteres LATIN1 (ISO-8859-1) UTF-8.
postgres$ initdb -E UNICODE
Otro aspecto a analizar mucho ms en profundidad, es la localizacin que se usar. Esto es importante ya que si se elige una que se ajuste mejor a nuestra cultura obtendremos mejores resultados. Principalmente la localizacin afecta el alfabeto, el orden, particularmente de cadenas de caracteres, y el formato numrico (coma o punto como separador decimal) entre otras cosas. La desventaja de usar una localizacin distinta de la predeterminada C, es que se perder en performace, por lo que debe usarse cuando se est seguro de necesitarla (los hispano parlantes deberamos usarlo siempre, ya que sino tendramos problemas de orden con cadenas que contengan letras acentuadas, letras con diresis o ). La localizacin, si no se le especica como opcin a initdb, se toma de las variables de entorno donde se est ejecutando initdb, que por lo general se ajustan al lugar donde vivimos (en el caso particular nuestro, debera ser es_AR). La forma de modicarlo es usando la opcin:
postgres$ initdb --locale=es_AR
Tambin se puede especicar por separado localizaciones distintas para distintos tipos. Por ejemplo usar localizacin es para mensajes y todo tipo de caracteres, pero usar C en nmeros y otros tipos. Para ello se recomienda al usuario leer detenidamente el manual de Administracin del Servidor, particularmente la parte de localizacin. La inicializacin de la base de datos cambia si se usan los script que traen las distribuciones de Linux (si lo traen). Las distribuciones basadas en RedHat tienen una opcin para inicializar el Cluster en el script de arranque. Si an no fue creado el Cluster cuando trate de arrancar el motor con el script /etc/init.d/postgresql, ste imprimir un mensaje en pantalla avisando que no no hay Cluster, indicando a continuacin cmo crearlo (usando el mismo script). Otras distribuciones, como es el caso de Debian, permiten tener varios Clusters en disco (en diferentes directorios). Para ello se valen de scripts propios de cada distribucin para crear, destruir o realizar tareas determinadas:
pg_createcluster: Crear un nuevo Cluster de PostgreSQL . Tiene op-
ciones para pasar determiandos parmetros.

pg_dropcluster: Destruir un Cluster. http://trac.marquesminen.com.ar/cursos/
Cursos de OSS
14

pg_lsclusters: Mostrar informacin sobre todos los Clusters. pg_ctlcluster: Controlar cada uno de los Clusters que estan denidos
en el servidor. Se usa para iniciar, parar, recargar, y otras tareas para el Cluster especicado.
pg_upgradecluster: Actualizar el Cluster a una nueva versin (vea la
seccin 4.6 para informacin sobre actualizacin entre versiones).
2.4.
Levantando el servicio de Bases de Datos
Cuando se ha concludo con la fase de inicializacin del Cluster de Bases de Datos, se debe levantar el servicio de PostgreSQL , siempre usando el usuario postgres, ya sea ejecutando el programa postmaster, usando el script pg_ctl, o con los scripts de arranque que vienen con la distribucin (usualmente ubicados en /etc/init.d/, como por ejemplo /etc/init.d/postgresql). pg_ctl es el script que se recomienda usar, y por lo general, los archivos de arranque que vienen con las distintas distribuciones de Linux simplemente lo ejecutan con determinados parmetros. Para obtener ayuda sobre cmo usarlo, simplemente ejectelo con la opcin especial --help.
postgres$ pg_ctl --help pg_ctl is a utility to start, stop, restart, reload configuration files, report the status of a PostgreSQL server, or signal a PostgreSQL process. Usage: pg_ctl pg_ctl pg_ctl pg_ctl pg_ctl pg_ctl
start stop restart reload status kill
[-w] [-D DATADIR] [-s] [-l FILENAME] [-o "OPTIONS"] [-W] [-D DATADIR] [-s] [-m SHUTDOWN-MODE] [-w] [-D DATADIR] [-s] [-m SHUTDOWN-MODE] [-o "OPTIONS"] [-D DATADIR] [-s] [-D DATADIR] SIGNALNAME PID
Common options: -D, --pgdata DATADIR location of the database storage area -s, --silent only print errors, no informational messages -w wait until operation completes -W do not wait until operation completes --help show this help, then exit --version output version information, then exit (The default is to wait for shutdown, but not for start or restart.) If the -D option is omitted, the environment variable PGDATA is used. Options for start or restart: -l, --log FILENAME write (or append) server log to FILENAME -o OPTIONS command line options to pass to the postmaster (PostgreSQL server executable) -p PATH-TO-POSTMASTER normally not necessary Options for stop or restart:
Cursos de OSS
2.4. Levantando el servicio de Bases de Datos

-m SHUTDOWN-MODE may be "smart", "fast", or "immediate"
15
Shutdown modes are: smart quit after all clients have disconnected fast quit directly, with proper shutdown immediate quit without complete shutdown; will lead to recovery on restart Allowed signal names for kill: HUP INT QUIT ABRT TERM USR1 USR2 Report bugs to <pgsql-bugs@postgresql.org>. postgres$ pg_ctl start
Como ya vimos en la seccin 2.3, en Debian se pueden tener varios Clusters, e incluso pueden correr simultneamente (slo deben denirse sockets y puertos de conexin distintos). Por ello es ms conveniente usar pg_ctlcluster.
postgres$ pg_ctlcluster help Usage: /usr/bin/pg_ctlcluster <version> <cluster> <action> postgres$ pg_ctlcluster 8.3 main start
Cuando el motor ya esta levantado, los usuarios pueden acceder a l a travs de alguna aplicacin que se comunique usando las bibliotecas libpq del motor (veremos, por ejemplo, psql en la seccin 6.1). En este momento las nicas bases de datos, aparte del catlogo que veremos en la seccin 4.7, son template1, template0 y postgres. En el caso de la primera, como su nombre lo sugiere, es una plantilla que se usa para la creacin de futuras bases de datos. Esto signica que cuando creamos una nueva base de datos, lo que se hace realmente es una copia de template1. Por eso hay que tener en cuenta dos cosas: 1. No debe trabajarse sobre la base template1. 2. Si quiere que algo aparezca en cada una de las nuevas bases que se creen, lo ms sencillo es agregarlo a template1, y al crear cada nueva base, dichos objetos ser copiados con el resto de los contenidos de template1. Adems de la base template1 existe una base template0, que sirve de respaldo de la anteriormente citada, y no debe ser usada, salvo que se quiera rescatar la base template1. Como no debe usarse, el motor esta congurado para rechazar toda conexin a dicha base.
Cursos de OSS
16
Cursos de OSS
Captulo 3 Conguracin
Cuando ya hemos terminado de instalar el motor y tenemos nuestro Cluster funcionando, debemos comenzar a congurar aspectos relacionados con el uso de los recursos, particularmente de memoria compartida, y los permisos de acceso al motor de la base de datos. La tarea de congurar el motor de Bases de Datos es realizada por el DBA1 (Database Administrator, o Administrador de Bases de Datos), y es una tarea que casi nunca termina, particularmente por cambios en consultas, nuevas aplicaciones (por ende nuevas consultas), y especialmente cambios en los datos (crecimiento de registros en las bases existentes). Veremos adems de esto, cmo y por qu hay que mantener las bases de datos limpias y cmo recolectar datos estadsticos que luego sern usados en las secciones 4.4.1 y 4.4.2.
3.1. Conguracin general del servidor

El archivo de conguracin de los recursos que usar PostgreSQL se encuentra dentro del directorio de datos PGDATA (donde se encuentra nuestro Cluster), y se llama postgresql.conf2 . Este archivo se crea automticamente, con valores predeterminados3 y puede tener efectos muy importantes en el rendimiento del motor de la base de datos como se ver en toda esta seccin.
1 este termino se usa mucho para identicar a la persona que se dedica a la administracin de bases de datos, y en bsquedas laborales suele aparecer como un tipo de puesto 2 Por lo general es el archivo /var/lib/pgsql/data/postgresql.conf 3 En versiones de PostgreSQL anteriores a 7.4 el archivo era nico para todos los sistemas operativos y todas las plataformas, por lo que tena valores conservadores. A partir de la versin 7.4 el archivo se genera en base a datos del sistema (cantidad de memoria, CPU, etc.) durante la ejecucin de initdb
17
18
Captulo 3. Conguracin
Trataremos de ver paso por paso las opciones ms importantes, explicando para qu sirven, y cmo se usan. Pero antes vamos a ver algunas convenciones que se usan en la edicin de este archivo. Los comentarios comienzan con un smbolo #, pudiendo estar en cualquier parte de una lnea. O sea, al leer PostgreSQL el archivo, obviar todo lo que se encuentre despus de un # en esa lnea, como por ejemplo:
# Esto es un comentario variable = valor # El comentario empieza ac
Los nombres de los parmetros no son sensibles a las maysculas, y los valores a tomar pueden ser de alguno de estos cuatro tipos: 1. Booleano (verdadero o falso): Maysculas o minsculas son indistintas y puede tomar los valores siguientes: a) ON, OFF b) TRUE, FALSE c) YES, NO d) 1, 0 2. Entero 3. Punto otante (nmero decimal) 4. Cadena de caracteres El comando SHOW permite ver cuales son los valores actuales de todos los parmetros:
prueba=> show max_connections; max_connections ----------------32
Algunos parmetros se pueden modicar en la sesin de SQL utilizando el comando SET, por ejemplo:
SET ENABLE_SEQSCAN TO OFF; Cursos de OSS
3.2. Conguracin de los parmetros de conexin
19
Si est permitido, se modicar el valor que tenga. El superusuario tiene permitido setear una mayor cantidad de parmetros que los usuarios comunes, en particular parmetros relacionados con el sistema. Detallaremos quienes tiene privilegios para poder modicarlos en el caso de poder hacerse por sesin. Los valores de cada una de las variables internas del motor pueden tener valores por defecto dados en el archivo postgresql.conf, o pasados como parmetros al postmaster4 en el arranque. A continuacin se enumerarn las opciones con una breve descripcin, explicando si puede ser seteado en la sesin actual o si se necesita reiniciar el motor para comenzar a trabajar con el nuevo valor del parmetro. Adems estn agrupados por tipos.
3.2. Conguracin de los parmetros de conexin

listen_addresses (cadena): Especica los IP o nombres de dominios por
los que el motor escuchar por pedidos de clientes. Si se especica el caracter comodn *, el motor aceptar pedidos en cualquier interface de red, siempre que sea aceptado por la conguracin de pg_hba.conf (vea la seccin 4.1.1 para saber como funciona este archivo). Si se especica una cadena vaca, el motor no aceptar conexiones TCP/IP, slo conexiones por el socket local (Unix domain socket). Tambin se puede especicar una lista de IP separndolos por comas. El valor predeterminado es localhost.
port (entero): El puerto TCP en el que va a escuchar el servidor. Por defecto
usa el 5432. El motor escuchara en el mismo puerto en todas las direcciones IP que tenga seteadas (pero solo las especicadas en listen_addresses). Este parmetro solo puede ser seteado en el arranque del motor.
max_connections (entero): Este parmetro determina el mximo nmero
de conexiones concurrentes que aceptar el servidor de bases de datos. Hasta la versin 7.3 el valor que se usaba por defecto era de 32 conexiones concurrentes. A partir de la versin 7.4, y gracias a una nueva implementacin de initdb este valor ser por lo general de 100, a menos que el ncleo del sistema operativo no soporte un nmero tan alto. El valor slo puede ser seteado al iniciar el motor de la base de datos. Si quiere aumentar este valor, debe revisar tambin la cantidad de memoria compartida en la seccin 3.4 ya que cada conexin necesita un mnimo de memoria compartida para arrancar.
4
programa que ejecuta el motor de las Bases de Datos
Cursos de OSS
20
superuser_reserved_connections (entero): Determina la cantidad de
conexiones que sern reservadas para el superusuario de PostgreSQL . Cuando la cantidad de conexiones activas sea de max_connections menos superuser_reserved_connections, nuevas conexiones slo sern aceptadas por el superusuario (el usuario postgres por lo general). El valor por defecto es de dos conexiones, no pudiendo superar el valor dado en max_connections, y slo pudiendo modicar su valor al arrancar el motor.
3.3.
Seguridad y autenticacin
password_encryption (booleano): Esta opcin da el valor por defecto que
usar PostgreSQL cuando tenga que decidir si encripta o no las contraseas de los usuarios al usar los comandos CREATE USER o ALTER USER. El valor predeterminado, si no se especica, es true (verdadero). Este valor puede cambiarse usando las palabras claves ENCRYPTED o UNENCRYPTED cuando se ejecuta alguno de los comandos antes mencionados.
CREATE USER martin ENCRYPTED PASSWORD micontrasea
El mismo efecto se puede conseguir usando la opcin -E con el comando createuser (para ms informacion sobre este comando vea la seccin 4.3)
ssl (booleano): Habilitar conexiones seguras para el motor. El valor por
defecto es false.
3.4. Usos de memoria

shared_buffers (entero): Este parmetro especica la cantidad de bfers
de memoria compartida que usar el servidor de bases de datos. El valor predeterminado es por lo general 32Mb, pero puede ser menor dependiendo del ncleo del sistema operativo y la cantidad de memoria RAM de la mquina (initdb se encarga de vericar esto). No se pueden especicar valores menores a 128Kb, ni tampoco menores a 16Kb por la cantidad mxima de conexiones concurrentes max_connections (ver seccin 3.2), pero para poder tener buena performace con el servidor se debe especicar valores signicativamente mayores a los mnimos.
Cursos de OSS
3.5. Mapa de espacio libre
21
Esta opcin slo puede ser modicada al iniciar el servidor de bases de datos. Incrementar demasiado este parmetro puede causar que PostgreSQL pida ms memoria compartida de la que el sistema operativo permite en su conguracin. La conguracin de estos parmetros del sistema operativo son complejos ya que varan de una implementacin de UNIX a otra. Ante la duda, consulte con un administrador de sistemas, busque un libro que explique cmo modicar parmetros en su ncleo (el kernel de Linux es un ejemplo) o informacin en la documentacin de PostgreSQL en la web (http://www.postgresql.org).
work_mem (entero): Especica la cantidad de memoria que se usar para
operaciones internas de ordenamiento antes de comenzar a usar archivos temporales en disco. El valor esta especicado en kilobytes, y su valor predeterminado es de 1024 kilobytes (1 megabyte). Debe tenerse presente que este valor es para cada operacin de ordenamiento, y que una consulta puede tener varias operaciones de ordenamiento de datos que corran en paralelo. Adems pueden existir varias sesiones corriendo simultneamente que requieren de operaciones de ordenamiento de datos, por lo que la cantidad de memoria que se est usando puede ser varias veces el valor de work_mem. Las operaciones de ordenamiento son usadas por las sentencias SQL ORDER BY, algunas uniones, y al usar subconsultas con IN.
maintenance_work_mem (entero): Especica, como mximo, cunta me-
moria se puede llegar a usar en tareas de mantenimiento con los comandos VACUUM (ver seccin 4.4.1), CREATE INDEX, y ALTER TABLE ADD FOREIGN KEY. El valor se especica en kilobytes, y por defecto es de 16384 kb.
3.5. Mapa de espacio libre

max_fsm_pages (entero): Especica el mximo nmero de pginas de disco
para las cuales se mantendr registro del espacio libre disponible en el mapa de espacio libre compartido. Seis bytes de memoria compartida son usados por cada pgina. El valor predeterminado es de 20000, y su valor debe ser mayor a 16 veces max_fsm_relations. Esta opcin slo puede cambiarse al iniciar el servidor de bases de datos.
max_fsm_relations (entero): Especica el mximo nmero de relaciones
(tablas e ndices) para las cuales se mantendr un registro de espacio libre

Cursos de OSS
22
Captulo 3. Conguracin disponible en el mapa de espacio libre compartido. Como mucho se usarn cincuenta bytes de memoria compartida por cada uno. El valor por defecto es 1000, y slo puede ser modicado al inicializar el servidor de bases de datos.
3.6.
WAL
WAL es un acrnimo de Write-Ahead Log, o traducido Log de Escritura Previa. Lo que PostgreSQL hace con WAL, en lugar de escribir las modicaciones (INSERT, UPDATE, DELETE, etc.) sobre la estructura de datos, es ir guardando la informacin de dichas modicaciones en un archivo aparte (los archivos de WAL estn en el directorio pg_xlog dentro de $PGDATA) que se garantizar su escritura usando llamadas al Sistema Operativo (fsync, fdatasync, etc. dependiendo del Sistema Operativo en el que corra el motor) despus de cada COMMIT.
Dependiendo de la conguracin, que veremos a continuacin en la seccin 3.6.1, cada tanto tiempo PostgreSQL escribir los datos que antes fueron guardados en los archivos de WAL a disco, generando un checkpoint (puntos de control). Todo esto es importante para cuando se produce una caida del sistema, ya que aunque los datos de las bases no esten en disco, al volver a arrancar el motor buscar cual fue el ltimo checkpoint y a partir de ah recuperar los datos restantes de transacciones que fueron efectivamente comprometidas antes de la cada del servidor, de los archivos de WAL que s fueron efectivamente guardados.
3.6.1. Conguracin de WAL

fsync (booleano): Si este parmetro tiene el valor verdadero, PostgreSQL va a usar la llamada a sistema fsync(), o la llamada que se especique en wal_sync_method, en diversos lugares para asegurar que la modicacin de los datos se escriba fsicamente a disco en el archivo de WAL. Esto da mayor certeza que el Cluster se recuperar de manera consistente ante una eventual cada del sistema.
Por otra parte, usar fsync() genera prdidas en cuanto al rendimiento: cuando se invoca a realizar las sentencias de una transaccin, PostgreSQL deber esperar a que el sistema operativo termine de escribir el WAL (WriteAhead Log) a disco. Si fsync() est deshabilitado el sistema operativo puede hacer buffering, reordenar los datos o dejar en espera la escritura de otros. Esto puede dar como resultado mejoras signicativas en la performace, particularmente cuando las consultas modican los datos (INSERT, UPDATE o DELETE). Sin embargo, si el sistema se cae, los resultados de
Cursos de OSS
3.6. WAL
23
las transacciones a las que se les mand un COMMIT pueden perderse parcial o totalmente. En el peor de los casos puede ocurrir que los datos se corrompan de manera irrecuperable. Esta opcin slo puede ser modicada al iniciar el servidor de bases de datos.
full_page_writes (boolean): Este parmetro le indica a PostgreSQL si debe escribir todos los contenidos de cada pgina de disco a WAL cuando se
realice la primera modicacin despus de un checkpoint. Esto es necesario porque las pginas de cada segmento de WAL son tpicamente de 8Kb, mientras que los sectores de disco por lo general son de 512 bytes. Si el sistema tiene una cada en el medio de la escritura de los 16 sectores de discos que conforman los 8Kb, el archivo de WAL tendr informacin de una pgina que fue escrita parcialmente, con lo que quedara una mezcla de datos nuevos y datos viejos en dicha pgina. Este parmetro tiene valor verdadero por defecto, y slo debe ponerse en falso si se cuenta con un controlador de discos con backup de bateras, o se est usando una estructura de archivos que reduzca los riesgos de escritura parcial de pginas de memoria a disco (por ejemplo ReiserFS 4).
wal_buffers (entero): Cantidad de memoria compartida que se usar para WAL. El valor por defecto es 64kb. El tamao debera ser sucientemente grande como para contener los datos de WAL de una transaccin promedio
(no es necesario que todas la transacciones entren en esta cantidad de memoria, pero si la mayora, ya que los datos son escritos a disco al ejecutar el COMMIT). Slo se puede modicar este valor al iniciar el servidor de Bases de Datos.
3.6.2. Puntos de control de WAL

checkpoint_segments (entero): Mximo nmero de segmentos de archivos de WAL entre puntos de control (los segmentos son de 16Mb). El valor
predeterminado es 3, y si se incrementa el valor se incrementar tambin el tiempo requerido para recuperar los datos despus de una cada del servicio, aunque evitar que se vuelquen los datos que se registraron en los logs de WAL muy a menudo. Este parmetro slo puede modicarse al arrancar el motor.
checkpoint_timeout (entero): Mxima cantidad de tiempo en segundos
entre puntos de control. Al igual que en el parmetro anterior, incrementar

Cursos de OSS
24
Captulo 3. Conguracin el valor har que se produzcan menos puntos de control, pero eso generar que demore ms en volver a un estado conable despus de una cada del motor. Este parmetro slo puede modicase al arrancar el motor.
checkpoint_completion_target (punto otante): Especica la longitud
que abarca un punto de control. Su posible valor est entre 0 y 1, e indica el porcentaje de segmentos de puntos de control o de tiempo de puntos de control (lo que pase primero) que tendr el motor para volcar a disco los registros de WAL. El valor por defecto es de 0.5 y el parmetro slo puede ser seteado al arrancar el motor.
checkpoint_warning (entero): Este parmetro especica el tiempo mni-
mo en que pueden pasar dos puntos de control sin que el motor enve una advertencia al sistema de logs, lo que sugiere que el valor de checkpoint_segments debe incrementarse). Por defecto el valor es de 30 segundos (un valor de cero deshabilita las advertencias), y slo puede setearse al arrancar el motor.
3.7. Constantes de costo del planicador

Las variables de costo que veremos a continuacin se miden en valores relativos unos de otros, por lo que aumentar todos por un mismo factor har que no tenga efecto alguno el cambio. Por lo general lo que se estila es setear seq_page_cost con un valor de 1.0, y que el costo de las dems variables se seteen como un factor de ste, utilizando valores menores a 1.0 si quiere que dicho parmetro tenga menor preponderancia que seq_page_cost, o mayor a ese valor si por el contrario quiere que predomine ese parmetro. Desafortunadamente no hay mtodo alguno para determinar valores adecuados para la familia de variables de costos especicadas abajo. Se recomienda experimentar con los valores y compartir los resultados.
seq_page_cost (punto otante): Especica la estimacin del planicador
de consultas del costo de traer una pgina de disco que es parte de una serie de pginas a traer secuencialmente. Su valor predeterminado, como ya se dijo antes, es de 1.0.
Cursos de OSS
3.8. Otras opciones del planicador
25
effective_cache_size (punto otante): Especica el valor que el plani-
cador de consultas presume acerca del tamao efectivo del cache de disco. Se mide en pginas de disco, que por lo general tienen 8192 bytes cada una, y el valor por defecto es de 1000.
random_page_cost (punto otante): Especica el valor que el planicador
de consultas estima es el costo de traer una pgina de disco de forma no secuencial. Esto es medido como un mltiplo del costo de traer una pgina en forma secuencial. Ponerle un valor alto a este parmetro hace que sea ms probable que el planicador de consultas haga un escaneo secuencial, mientras que un valor chico aumenta la probabilidad de hacer una bsqueda por ndice. Por defecto su valor es 4.
cpu_tuple_cost (punto otante): Especica el costo que el planicador
de consultas estimar para procesar cada la durante una consulta. Se mide como una fraccin del costo de traer una pgina en forma secuencial. Por defecto su valor es de 0.01.
cpu_index_tuple_cost (punto otante): Especica el costo que el plani-
cador de consultas estimar para procesar cada la de un ndice durante un escaneo por ndice. Se mide como una fraccin del costo de traer una pgina en forma secuencial. Por defecto su valor es de 0.001.
cpu_operator_cost (punto otante): Especica el costo que el plani-
cador de consultas estimar para procesar cada operador en una clasula WHERE. Se mide como una fraccin del costo de traer una pgina en forma secuencial. Por defecto su valor es de 0.0025.
3.8. Otras opciones del planicador

default_statistics_target (entero): Especica el valor que se usar, si no se ha espedicado un valor con ALTER TABLE SET STATISTICS, para juntar datos estadsticos con ANALYZE de una columna en particular. Un valor ms alto har que ANALYZE colecte ms datos en la tabla pg_statistics,
haciendo que este proceso y la ejecucin del planicador de consultas demoren ms, y que la tabla pg_statistics sea ms grande.
Cursos de OSS
26
Captulo 3. Conguracin Como contrapartida, se pueden tener mejores consultas ya que el planicador cuenta con ms informacin para poder decidir qu camino tomar.
constraint_exclusion (booleano): Lo habilita o inhabilita al planicador
de consultas a usar restricciones de tablas para optimizar consultas. El valor por defecto es falso (no se usarn).
3.9.
Opciones de limpieza y recoleccin de estadstica: autovacuum
Autovacuum se planic para evitar tener que realizar rutinarias ejecuciones de VACUUM y VACUUM ANALYZE, que se ven en la seccin 4.4.1. La idea, en sus principios, fue tener un daemon que fuese realizando la tarea de limpieza y actualizacin de datos estadsticos de forma espaciada, durmiendo despus de cierto tiempo de accin (congurable por supuesto). En la version 8.2 de PostgreSQL los desarrollos de Alvaro Herrera incorporaron autovacuum en el motor, congurndose desde postgresql.conf con los parmetros que veremos enseguida. Ya en la versin 8.3, tras madurar autovacuum se lo habilit automticamente (valor que tiene por defecto ahora). Las opciones ms importantes se resumen a continuacin: autovacuum (booleano): Indica si el servidor debe lanzar el daemon de autovacuum. Aunque su valor por defecto es verdadero, se debe tener especial cuidado en tener el parmetro track_counts habilitado (ver seccin 3.11.2) para que autovacuum funcione.
Este parmetro slo puede ser seteado cuando arranca el servidor.

autovacuum_max_workers (entero): Especica el mximo nmero de procesos de autovacuum que en un instante cualquiera pueden estar corriendo.
Por defecto el mximo es tres, y este valor slo puede ser seteado al arrancar el servidor.
autovacuum_vacuum_threshold (entero): Especica el umbral de tuplas modicadas o borradas necesarias para disparar un proceso de VACUUM en
una tabla en particular. El valor predeterminado es 50, y slo puede ser seteado al inicial el servidor. Sin embargo los valores pueden ser ser modicados para una tabla particular modicando las entradas en la tabla del catlogo pg_autovacuum.
Cursos de OSS
3.10. Conguracin de registros de PostgreSQL
27
autovacuum_analyze_threshold (entero): Especica el umbral de tuplas
insertadas, modicadas o borradas necesarias para disparar un proceso de ANALYZE en una tabla particular. El valor por defecto es 50, y slo puede ser seteado al inicial el servidor. Sin embargo los valores pueden ser ser modicados para una tabla particular modicando las entradas en la tabla del catlogo pg_autovacuum.

3.10.1. Conguracin general
log_destination (cadena de caracteres): PostgreSQL soporta varios mecanismos para archivar mensajes de logueo, entre los que est syslog y stderr (algo como standard error), siendo este ltimo el predeterminado.
Se pueden especicar varios separados por comas. Esta opcin slo puede ser cambiada al arrancar el motor.
logging_collector (booleano): Este parmetro hace que PostgreSQL
capture y redireccione los mensajes enviados por stderr5 a archivos de log. Este parmetro necesita que se reinicie el motor para tener efecto.
syslog_facility (cadena de caracteres): Esta opcin determina cul servicio (facility) de syslog se deber usar para registrar, si syslog est habilitado. Puede elegir LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7, siendo el valor por defecto LOCAL0. syslog_ident (cadena de caracteres): Si est habilitado el sistema para guardar los registros a travs de syslog, esta opcin determina el nombre
que se usar para identicar los mensajes de PostgreSQL entre los dems mensajes de syslog. El valor predeterminado es postgres. La forma de loguear registros que el autor usa es: 1. Apagar la redireccin de mensajes de error del motor: redirect_collector
= off
Esto hace que al ejecutar el motor los mensajes que el postmaster devuelva no sean redireccionados a un archivo, sino que vayan a la salida de error estandard.
5
Salida estandard de error de Sistemas Operativos UNIX
Cursos de OSS
28
Captulo 3. Conguracin 2. En el script de inicio (por lo general /etc/init.d/postgresql) setear correctamente la variable PGLOG para que apunte a donde se va a loguear: PGLOG=/var/log/postgresql/postgresql.log. 3. Crear un archivo /etc/logrotate.d/poostgresql que tenga lo siguiente:
/var/log/postgresql/*.log { weekly rotate 16 copytruncate delaycompress compress notifempty missingok }
Cambiar los valores para reejar las necesidades de rotacin de logs que tiene el servidor. Esta es la forma en que Debian loguea los registros de PostgreSQL por defecto (slo hay que instalar). Los pasos enumerados antes son los que el autor llev a cabo en Fedora y CEntOS.
3.10.2. Cundo escribir registros

client_min_messages y log_min_messages (cadena de caracteres): Estas dos opciones controlan el nivel de mensajes que sern enviados a los clientes y al servidor de registros respectivamente. Los valores pueden ser DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING, ERROR, FATAL y PANIC. Cada nivel incluye a todos los que le siguen, por lo que los ltimos niveles tendrn menor cantidad de mensajes que los primeros. El valor por defecto es NOTICE para ambos parmetros. El parmetro que controla los mensajes que irn al servidor de registros slo puede ser modicado por el superusuario de PostgreSQL . log_min_error_statement (cadena de caracteres): Este parmetro controla si las consultas de SQL que causan un error deben o no ser registradas en el servidor de registros.
Todas las consultas que provocan un error en el nivel especicado, o un nivel superior, sern registradas. El valor predeterminado es PANIC, por lo que estar apagado para el uso normal, y los valores vlidos son DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, FATAL,
Cursos de OSS
29
y PANIC. Por ejemplo, si se setea esta opcin en ERROR, todas las consultas que causen un error, error fatal (la conexin se interrumpe) o un error de pnico (se cae el servidor de la base de datos) sern registradas. Esta opcin puede ser de ayuda para encontrar la fuente de errores que aparecen en el servidor de registros. Slo el superusuario de PostgreSQL puede modicar este valor.
log_min_duration_statement (entero): Este parmetro setea la duracin
mnima (en milisegundos) que debera tener una consulta para ser registrada. Todas las consultas cuya ejecucin demore ms que esa cantidad de tiempo, sern registradas con el tiempo de duracin. Seteando este parmetro a 0 imprimir todas las consultas con el tiempo de duracin que tuvieron. En cambio, el valor por defecto, menos uno (-1) lo deshabilita. Este parmetro puede ser muy til para encontrar consultas que no estn debidamente optimizadas en sus aplicaciones. Slo el superusuario de la base de datos puede modicar este valor.
silent_mode (booleano): Servidor silencioso. Si este parmetro tiene va-
lor verdadero, el servidor correr de fondo dejando libre la terminal en la que fue iniciado. Por lo tanto, ningn mensaje llegar por la salida estndar (stdio) o de error (stderr). A menos que est habilitada la opcin de syslog, no es recomendable habilitar esta opcin ya que hace imposible poder encontrar mensajes de error. Aqu hay una lista de los distintos niveles de severidad de los mensajes usados: DEBUG[1-5]: Provee informacin de uso para los desarrolladores. INFO: Provee informacin implcitamente requerida por el usuario, por ejemplo durante VACUUM VERBOSE (ver seccin 4.4.1) NOTICE: Provee informacin que puede ser til para los usuarios, por ejemplo creacin de ndices de llaves primarias. WARNING: Provee avisos para el usuario, por ejemplo si intenta ejecutar COMMIT fuera de un bloque transaccional. ERROR: Reporta un error que caus el aborto de la transaccin actual. LOG: Reporta informacin de inters para los administradores, como por ejemplo actividad de puntos de control.
Cursos de OSS
30
Captulo 3. Conguracin FATAL: Reporta un error que caus que se abortara la sesin actual. PANIC: Reporta un error que caus que todas las sesiones abortaran.
3.10.3.
Qu datos escribir en los registros
debug_print_parse (booleano) debug_print_rewritten (booleano) debug_print_plan (booleano) debug_pretty_print (booleano)
Estas opciones habilitan diversas salidas de depuracin a ser enviadas al cliente o servidor de registros. Para cada consulta imprimen el rbol de anlisis sintctico, la reescritura de la consulta, o el plan de ejecucin. debug_pretty_print indenta estos mensajes para producir una versin ms legible, aunque tambin ms larga. client_min_messages o log_min_messages debe ser DEBUG1 o menor para poder enviar mensajes al cliente o servidor. Todas estas opciones estn deshabilitadas por defecto.
log_connections (booleano): Si esta opcin est habilitada se escribir
una lnea en los registros por cada conexin exitosa que se haga al servidor. Por defecto esta deshabilitado, aunque es una opcin muy til. Esta opcin slo puede ser seteada al iniciar el servidor.
log_duration (booleano): Esta opcin produce, si est habilitada, que se registre la duracin de cada consulta. Para usar esta opcin debe habilitar log_statement y log_pid para poder enlazar la consulta con su duracin usando el nmero del proceso. Por defecto est deshabilitado y slo el superusuario puede deshabilitar esta opcin si es habilitada por el administrador. log_min_duration_statement (entero): Hace que, de cada consulta que
tard ms de la cantidad de milisegundos especicadas en esta opcin, se registre dicha duracin en los logs. Un valor de cero imprime la duracin de todas las consultas. Para desabilitar el registro de duracin de registros, se debe asignar el valor -1 (menos uno) a esta opcin.
log_statement (cadena): Controla cuales comandos SQL van a loguearse. Valores vlidos son: none, ddl, mod y all. Por defecto toma el valor none, y slo el superusuario puede cambiar el valor a esta opcin.
Cursos de OSS
3.11. Estadsticas
31
3.11. Estadsticas
PostgreSQL guarda datos estadsticos sobre tablas, ndices, etc. para poder
planicar los caminos para ejecutar una consulta. Las opciones que a continuacin se detallan en la seccin 3.11.1 sirven para indicar que informacin estadstica se escribir en los logs de PostgreSQL . En la seccin 3.11.2 se indica qu informacin se va a recolectar en las tablas pg_stat_* y pg_statio_*. Las ltimas son de utilidad para monitorear los recursos con pgiomonitor.
3.11.1. Monitoreo de estadsticas

log_statement_stats (booleano) log_parser_stats (booleano) log_planner_stats (booleano) log_executor_stats (booleano)
Para cada consulta escribir estadsticas de rendimiento, del mdulo respectivo (statement, parser, etc), al servidor de log. Todas estas opciones estn deshabilitadas por defecto y slo los super-usuarios pueden deshabilitar cualquiera de las opciones si el administrador las habilit.
3.11.2. Recolector de estadsticas de consultas e ndices

track_activities (booleano): Esta opcin habilita la recoleccin de in-
formacin de los comandos que se estn ejecutando en ese instante en cada sesin, junto con la hora en la que ese comando empez a ejecutarse. Hay que notar que, aunque est habilitada esta opcin, la informacin que se recolecte slo ser visible para el dueo de la sesin y los super-usuarios. Un usuario sin propiedad de super-usuario no podr ver informacin de consultas ejecutadas en otras sesiones de otros usuarios. Esta opcin est habilitada por defecto.
track_counts (booleano): Esta opcin habilita a recolectar estadsticas de
la actividad de la Base de Datos. Este parmetro est habilitado por defecto ya que autovacuum (vea la seccin 3.9) necesita de dicha informacin.
Cursos de OSS
32
update_process_title (booleano): Habilita la actualizacin del ttulo de los procesos cada vez que un nuevo comando SQL es recibido por el servi-
dor. Esto es til para cuando se monitorean los procesos del motor usando comandos UNIX como ps o, como veremos en la seccin 8.5, con pgTop. Slo los super-usuarios pueden modicar el valor de este parmetro.
3.12.
Valores predeterminados para conexiones de clientes
3.12.1. Formato y localizacin

datestyle (cadena de caracteres): Determina cmo ser el formato de fecha y hora, cuando se extraigan o inserten datos de este tipo de consultas. Esta variable contiene dos componentes independientes: uno para especicar el formato de salida (ISO, Postgres, SQL, o German), y otro para especicar el orden de los datos en las fechas (DMY, MDY, o YMD). Pueden setearse juntos o por separado. Las palabras claves Euro y European son sinnimos de DMY, mientras que US, NonEuro, y NonEuropean son sinnimos para MDY. El valor predeterminado es ISO, MDY. timezone (cadena de caracteres): Setea el huso horario para mostrar e interpretar datos de tipo timestamp. El valor por defecto es unknown (o desco-
nocido) lo que signica que se usar el valor que tiene el Sistema Operativo.
client_encoding (cadena de caracteres): Setea el tipo de codicacin que
usar el cliente. El valor predeterminado es usar el tipo de codicacin que tiene el servidor.
lc_messages (cadena de caracteres): Setea en qu idioma se mostrarn los
mensajes. Los valores probables dependen del sistema donde est el servidor (se vi el locale en la seccin 2.1). Si la variable se setea con la cadena vaca (que es el valor predeterminado), entonces su valor ser heredado de las variables de entorno del intrprete de comandos donde se inici el servidor.
Cursos de OSS
Captulo 4 Administracin
4.1. Congurando accesos a la Base de Datos
Cuando una aplicacin quiere realizar una conexin a una base de datos, le especica a PostgreSQL con qu usuario se va conectar, muy parecido a los mtodos de autenticacin en sistemas UNIX. Autenticarse es el proceso en el cual el servidor establece la identidad de la aplicacin (cliente), para saber si la aplicacin (o el usuario que esta usando la aplicacin) tiene permiso para conectarse con el usuario que especic a determinada base de datos. PostgreSQL ofrece una variedad de posibilidades de autenticacin, desde usuarios y contraseas en el catlogo del servidor (ver seccin 4.7), hasta autenticacin con el sistema operativo. Por lo general es apropiado separar los usuarios del sistema operativo de los de la base de datos, para as facilitar la administracin de las aplicaciones (y los usuarios que usen dichas aplicaciones) que se conectan a las bases de datos.
4.1.1. Conguracin del archivo pg_hba.conf

El mecanismo de autenticacin es complejo, pero no difcil de entender, y se compone de varias partes. Todas las lneas del archivo pg_hba.conf que comiencen con el smbolo (#) son consideradas comentarios, y por lo tanto, ignoradas al momento de evaluar si una conexin es aceptada o rechazada. Cada lnea determina un tipo de autenticacin posible, y cada vez que un cliente intente conectarse al motor de la base de datos, deber coincidir sus datos con los de al menos una de estas deniciones. Cada denicin de una posible conexin debe tener una de las siguientes estructuras: 33
34
local host hostssl hostnossl db db db db usuario usuario usuario usuario
Captulo 4. Administracin
auth [auth-op] IP mscara auth IP mscara auth IP mscara auth
[auth-op] [auth-op] [auth-op]
El primer campo que vemos en cada una de las lneas de arriba indica el tipo de conexin que se va a realizar, y puede ser: local: Para conexiones realizadas a travs de socket de UNIX. Como puede verse estas conexiones no tienen especicacin de IP o mscara, ya que no son conexiones remotas por protocolo TCP/IP. host: Para conexiones a travs del protocolo TCP/IP hostssl: Para conexiones a travs del protocolo TCP/IP nicamente con soporte de SSL (Secure Socket Layer). hostnossl: Para conexiones a travs del protocolo TCP/IP nicamente sin soporte de SSL (Secure Socket Layer).
hostssl slo aceptar conexiones seguras, hostnossl slo aceptara conexiones no seguras (o sin SSL), mientras que host puede aceptar tanto conexiones seguras como inseguras. Las tres ltimas carecen de utilidad si no se ha arrancado el servidor con el parmetro -i o la variable listen_addresses seteada a un valor distinto de . El segundo campo es la base de datos a la que el cliente se va a conectar. Se debe especicar la base de datos que quiere, o puede usar la palabra clave all para especicar todas. Se puede tambin especicar varias bases de datos separndolas por comas. El tercer campo es el usuario al que se le va a denir el acceso. Ser este el usuario que usar la aplicacin para conectarse a la base de datos especicada en el segundo campo. Si no se quiere hacer distincin con los usuarios puede usar la palabra clave all aqu tambin, adems de poder especicar varios usuarios separados por comas. Tambin se puede especicar un grupo anteponindole un +. Los campos cuatro y cinco son la direccin IP y una mscara de red respectivamente, y sirven para identicar desde qu mquinas en la red se van a permitir conexiones. Ante la duda, pida consejo al administrador de redes para su correcta conguracin. El ltimo campo es el mtodo de autenticacin que se va a utilizar, y puede ser uno de los siguientes:
Cursos de OSS
4.1. Congurando accesos a la Base de Datos
35
trust: Puede ingresar a la base de datos sin restricciones. Este mtodo per-
mite que cualquiera que pueda conectarse a la base de datos pueda loguearse sin necesidad de especicar una contrasea.
reject: La conexin es rechazada. Esta opcin es til para poder ltrar a
ciertas mquinas de un grupo.

md5: El cliente deber proveer la contrasea encriptada con algoritmo md5 para la autenticacin. Este es el nico mtodo que permite contraseas encriptadas en pg_shadow. crypt: Parecido al mtodo md5, pero usa el algoritmo crypt() que es ne-
cesario para clientes anteriores a 7.2. Para clientes 7.2 y superior se recomienda usar md5.
password: Parecido al mtodo md5, pero la contrasea va sin encriptar por
la red. No es recomendable usar en redes que no tengan la debida seguridad.

krb4 y krb5: Autenticacin usando Kerberos v4 y v5. ident: Obtener el nombre del usuario del sistema operativo del cliente (con-
tactando el servidor ident del cliente en el caso de conexiones remotas o requirindolas al sistema operativo en el caso de conexiones locales) y vericar si el usuario tiene permiso de conectarse a la base de datos tras consultar el mapa especicado despus de la palabra clave ident. Si se usa el mapa sameuser el cliente solo podr conectarse con el mismo usuario que ident obtuvo. Sino el mapa se buscar en pg_ident.conf que se encuentra en el mismo directorio que pg_hba.conf.
pam: Autenticar usando Pluggable Autentication Module (PAM) del sis-
tema operativo. Un ejemplo de registro de pg_hba.conf puede ser el siguiente:

# Permite a usuarios desde 192.168.12.10 a conectarse a la base # de datos "template1" si la contrasea del usuario es la # correcta # # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD host template1 all 192.168.12.10 255.255.255.255 md5
Con esta nica lnea en pg_hba.conf slo se podr acceder al motor de la base de datos desde la mquina con direccin IP 192.168.12.10, con cualquier usuario que se autentique contra el catlogo (usuarios del motor), pero nicamente a la base de datos template1.
Cursos de OSS
36
4.2. Creacin de Bases de Datos

Lo primero que debemos tener para comenzar a trabajar con nuestro motor es una base de datos donde poner nuestras tablas y dems objetos (comnmente llamados relaciones en charlas de bases de datos). Para eso debemos enviar al motor un comando de creacin de dicha base. Esto se puede hacer desde una interface que se comunica con el motor, como por ejemplo psql, ejecutando el comando CREATE DATABASE, o desde la lnea de comandos usando el comando createdb. El primero require saber bien los comandos SQL, mientras el segundo es un script que accepta distintos parmetros y con ellos fabrica el comando que luego ejecutar el motor. Si recin empezamos a trabajar con el motor, el nico usuario habilitado para crear bases de datos es postgres, pero se pueden crear usuarios nuevos que tengan privilegios para poder crear bases de datos (si uso la opcin CREATEDB en el comando CREATE USER o ALTER USER). Lo ms comn es que se creen las bases desde una consola de texto usando el comando createdb, con determinadas opciones. Por ejemplo, para crear nuestra base de datos de pruebas prueba con codicacin de caracteres LATIN1, se debe ejecutar el siguiente comando
martin@bugs:/home/martin> createdb -E LATIN1 prueba
Otras opciones tiles son:

-O: Indica quin ser el dueo de la base de datos que se va a crear -D: Indica cul ser el tablespace que se usuar para almacenar los objetos
de la base de datos por defecto Para ver todas las opciones ejecute createdb --help.
4.3.
Administracin de Roles de Bases de Datos
Cuando creamos el Cluster, como se vi en 2.3, usamos el usuario postgres para que sea el superusuario. Este usuario ser el dueo del Cluster, y ser el nico usuario en la tabla pg_authid (tabla que contiene informacin sobre los Roles, con sus privilegios, contraseas, etc.). Como esta tabla contiene informacin condencial (las contraseas), slo los super-usuarios tienen permisos de lectura sobre ella. Para poder ver los roles existe la vista pg_roles que muestra la informacin sobre roles ocultando la informacin condencial. Los Roles engloba a usuarios y grupos, que era como PostgreSQL manejaba permisos antes de la version 8.1. Un Role puede ser dueo de objetos, y a su
Cursos de OSS
4.3. Administracin de Roles de Bases de Datos
37
vez darle privilegios a otros Roles sobre dichos objetos. Adems se le puede dar membreca a otros Roles sobre un Role particular (esto es parecido al concepto de usuario que pertenece a un grupo). Los usuarios son Roles que tienen atributo de LOGIN (slo los que tienen este atributo pueden iniciar una conexin al motor). Para poder crear nuevos Roles, con o sin privilegios especiales, usamos el comando CREATE ROLE (est tambin ALTER ROLE para modicar un Role existente), que tiene opciones para darle ms o menos privilegios al Role. Los atributos posibles de un Role son:
privilegio de login:
Solamente los Roles que tengan el atributo de LOGIN pueden ser usados para iniciar una conexin a la Base de Datos. Estos Roles son los que uno considerara un usuario de la Base de Datos. Estos son ejemplos de como usar este comando. CREATE ROLE nombre_role LOGIN;
privilegio de super-usuarios1 :
Un super-usuario de la Base de Datos puede pasar por alto todos los chequeos de permisos. Para crear un usuarios con estos privilegios use CREATE ROLE nombre_role SUPERUSER. Slo un Role con privilegio de superusuario puede crear otro super-usuario.
privilegio para crear Bases de Datos:
Para que un Role pueda crear nuevas Bases de Datos se le debe dar este privilegio explcitamente (salvo los super-usuarios). Para ello hay que usar
CREATE ROLE nombre_role CREATEDB privilegio para crear role:
Para que un Role pueda crear otros Roles, debe tener el atributo CREATEROLE, con la excepcin de los super-usuarios. Para crear un Role con este atributo usamos el coamndo CREATE ROLE nombre_role CREATEROLE. Con este atributo, un Role puede crear, modicar o eliminar otros Roles, as como dar o quitar privilegios en ellos (usando los comandos GRANT y REVOKE. Sin embargo este atributo no permite crear, modicar o cambiar la membreca de un super-usuarios. Solamente otro super-usuario puede hacer eso.
1 Los super-usuarios no deben usarse, a menos que se requiera realizar una tarea que slo puede hacerse con un usuario con este privilegio especial. Debe tener mucho cuidado quien lo use ya que puede ejecutar tareas peligrosas
Cursos de OSS
38
contrasea:
La contrasea slo ser importante si el mtodo de autenticacin del cliente requiere que el usuario entregue una palabra clave para poder conectarse a la Base de Datos (vea la seccin sobre Conguracin de accesos a la Base de Datos y particularmente Conguracin del archivo pg_hba.conf en 4.1.1). Las contraseas del motor de Bases de Datos estn separadas de las del Sistema Operativo, y para especicar la contrasea del Role en la creacin del mismo se usa la siguiente sintaxis: CREATE ROLE nombre_role PASSWORD lacontrasea. Alternativamente PostgreSQL trae un script interactivo para crear nuevos roles del motor, que se ejecuta desde el shell del Sistema Operativo, llamado createuser. El comando createuser acepta varias opciones para especicar si va a ser un super usuario, o si este nuevo role puede crear bases de datos o nuevos roles. Si no se especican estas opciones el script preguntar interactivamente por cada una de ellas para saber si tiene o no dicho atributo. Las opciones del comando son:
-s: El rol ser un superusuario -S: El rol no ser un superusuario -d: El rol podr crear bases de datos -D: El rol no podr crear bases de datos -r: El rol podr crear otros roles -R: El rol no podr crear otros roles -P: Asignar una contrasea al nuevo rol -E: Almacenar la constrasea cifrada
4.4. Tareas de Administracin

4.4.1. Limpiando y buscando estadsticas (Vacuum y Analyze)
Para modicar datos a travs de un UPDATE en las tablas, PostgreSQL crea una nueva tupla, con los datos actualizados, pero no elimina la tupla original
Cursos de OSS
4.4. Tareas de Administracin
39
que fue modicada, sino que la marca como borrada. Para el caso de borrado de registros, hace algo similar: solamente marca al registro como borrado. Esto es necesario para que funcione MVCC, ya que transacciones que se estn ejecutando en un instante podran necesitar ver an dichas tuplas. Esto tiene pros y contras. Lo que tiene a favor es la implementacin de MVCC que permite manejar conexiones concurrentes. La contra es que guardar registros borrados, o peor, registros que fueron modicados puede hacer que nuestras tablas se llenen de basura (datos que realmente no deberan estar, a pesar de que no se ven al ejecutar SELECT sobre una tabla) y se pierda mucho rendimiento. Por esta forma de manejar la informacin que tiene PostgreSQL es que existe una herramienta que esta dentro del motor de PostgreSQL llamada VACUUM. VACUUM2 va a revisar las tablas buscando registros que fueron marcados como borrados y los va a eliminar denitivamente, liberando espacio en disco, as como tambin dando mejor rendimiento al motor. Veamos ms en profundidad las opciones que acepta VACUUM, todas ellas siendo opcionales (no son requeridas para que VACUUM funcione):
FULL: Realiza un aspirado profundo liberando ms espacio, pero a su vez
tardando ms y bloqueando las tablas. Esto ltimo es lo que hace poco recomendable esta opcin.
VERBOSE: Modo verborrgico. Imprimir informacin del espacio reclamado por VACUUM. table: Slo ejecutar VACUUM sobre los registros de esta tabla. ANALYZE: Actualiza las estadsticas de la tabla que usa el optimizador para
determinar la forma ms adecuada de ejecutar una consulta. De manera adicional se puede agregar un parmetro ms a tabla, indicando sobre que columna se quiere sacar estadsticas. Esto slo tiene utilidad cuando se usa la palabra clave ANALYZE. Adems de ejecutar VACUUM desde algun cliente, como por ejemplo psql que se ver en la seccin 6.1, existe una aplicacin que realiza estas mismas tareas, con las mismas opciones, pero pasadas como parmetros. Se llama vacuumdb. Esto permite ejecutar VACUUM sin necesidad de abrir un cliente como psql, o incluso agregar trabajos de cron para realizar la tarea sistemticamente. Este ejemplo limpia las tablas de la base de datos prueba guardando datos estadsticos.
2
signica limpiar o aspirar en ingls
Cursos de OSS
40
postgres@dbserver ~ > vacuumdb -z prueba
Para ms parmetros de vacuumdb vea el manual.
4.4.2.
Copias de respaldo con pg_dump y pg_dumpall
pg_dump y pg_dumpall son dos aplicaciones binarias que se encargan de rea-
lizar copias de respaldo de las bases de datos en un formato de texto3 . Ante cualquier eventualidad, como puede ser una falla del Hardware, especialmente los discos, estas copias sirven para poder recuperar los datos que estaban en las bases. Por eso, las copias deberan ser guardadas en otro dispositivo, preferentemente externo al servidor de bases de datos, como puede ser una unidad de cintas o el disco de una mquina remota. Las dos aplicaciones devolvern el respaldo por STDOUT, que por lo general es la pantalla o terminal en la que se est trabajando. Lo nico que hay que hacer es redireccionar la salida al archivo donde se quiere almacenar el respaldo. La diferencia entre pg_dump y pg_dumpall es que la primera hace la copia de una base de datos (inclusive pudiendo slo hacer el respaldo de una nica tabla de la base de datos) y la segunda lo hace sobre todo el Cluster. Una vez realizado el respaldo de los datos, se podr ver que la salida es un archivo de texto con comados SQL para crear tablas, secuencias, disparadores, y todo objeto que haya en la base de datos, seguido por comandos de COPY de los datos de las tablas. Convencionalmente las formas adecuadas de usar estos comandos se muestran en estos ejemplos: Respado de todo nuestro Cluster en el archivo /backup/respaldo.sql
postgres@dbserver ~ > pgdumpall > /backup/respaldo.sql
Respado
de
la
base
de
datos
servicios
en
el
archivo
/backup/respaldo-servicios.sql
postgres@dbserver ~ > pgdump servicios > /backup/respaldo-servicios.sql
Respado de la tabla admin de la base de datos servicios en el archivo /backup/respaldo-servicios.sql usando comandos INSERT en lugar de
COPY
postgres@dbserver ~ > pgdump servicios -t admin -d > /backup/respaldo-servicios.sql

3 hay motores de Bases de Datos comerciales que realizan copias de respaldo en binario, lo que es ms rpido, aunque el respaldo puede que slo sirva para la aplicacin de recuperacin que tiene actualmente el motor
Cursos de OSS
4.5. Respaldo de archivos WAL y PITR
41

Como ya se vi en la seccin 3.6, WAL mantiene en el directorio pg_xlog un log de la actividad del Cluster. Estos segmentos de WAL se usan principalmente para poder recuperar los datos en caso de una cada del sistema, simplemente aplicando los cambios producidos por transacciones que se produjeron despus del ltimo Punto de Control (vea la seccin 3.6.2). La existencia de estos archivos hace posible una nueva estrategia para respaldar Bases de Datos, que es combinar respaldos de sistema de archivos4 con repaldos de los archivos (o segmentos) de WAL. Si en algn momento es requerido el respaldo, se recupera el respaldo del sistema de archivos y luego aplicamos los archivos de WAL que fueron tambin respaldados luego, lo que traer la Base de Datos en estado actualizado al momento de corte (o cada) del servidor. Como ya se puede ver, este mtodo es mucho ms complejo de administrar, pero trae aparejado otros benecios: No es necesario tener consistencia de datos en el respaldo que se haga a nivel de sistema de archivos. Cualquier inconsistencia que aparezca quedar subsanada al aplicar los logs de WAL. Esto signica que no es necesario tener una instantnea de la Base de Datos al momento de hacer el repaldo, como hace pg_dump, sino que se puede usar cualquier aplicacin tpica de respaldos de sistemas de archivos, como puede ser tar, cpio, o cualquier aplicacin similar. Como la recuperacin de un Cluster usando los archivos de WAL se puede hacer con una gran cantidad de segmentos para ser aplicados (note que cuantos ms sean, mas tiempo le llevar al proceso postgres poner en estado consistente la estructura de datos, y as poder empezar a recibir nuevas consultas). Esto hace que no sea necesario hacer frecuentes repaldos completos de la Base de Datos, que puede ser conveniente en sistemas muy grandes. En ningn lugar dice que hay que aplicar todas las entradas de WAL hasta la ltima. Se puede parar de aplicar en un instante cualquiera, y tener una Base de Datos consistente a este instante de tiempo. Por lo tanto podemos tener Recuperacin a un instante determinado (Point-in-Time Recovery en ingls, o con el acrnimo PITR): es posible recuperar una Base de Datos al estado que tena en cualquier instante anterior al ltimo respaldo de segmentos de WAL.
4
En sistemas UNIX se usa por lo general la aplicacin tar
Cursos de OSS
42
Captulo 4. Administracin Si copiamos continuamente los archivos de WAL a otro servidor que tiene un respaldo de archivos (los archivos que se encuentran en PGDATA) del servidor principal, tenemos un servidor que est listo para reemplazar al principal en caso de cada. En otras palabras, en cualquier instante podemos levantar el servidor secundario y este va a tener una copia casi actualizada de la Base de Datos (puede que se hayan perdido las ltimas transacciones que no llegaron a copiarse en los ltimos segmentos de WAL).
4.5.1.
Preparando para archivar los registros de WAL
PostgreSQL produce una indenidamente larga secuencia de registros de

WAL, que el sistema los divide en segmentos que paran en los archivos de WAL en
pg_xlog/, normalmente de 16Mb. Los arvhivos tienen nombres, que contienen
caracteres que reejan su posicion en la secuencia de WAL. Si no se hace uso del archivado de WAL, el motor crear algunos segmentos y luego los reciclar renombrando los segmentos que ya no son necesarios para garantizar consistencia, dandole nmeros ms altos. Se supone que los archivos cuyos contenidos anteceden al penltimo punto de control ya no son necesarios y por ende pueden ser reciclados. Para realizar el archivado de los segmentos de WAL debemos asegurarnos de guardar los contenidos de cada segmento que se ha llenado, para que luego puedan ser reciclados. Esto se puede realizar copiando los archivos a un disco remoto (en otro servidor), o como suelen recomendarse en otros motores de Bases de Datos, en cintas, o en CDs. Como la variedad es grande, se deja en manos del administrador jar cmo se va a realizar esta tarea usando la variable archive_command que se setea en el archivo postgresql.conf, donde se puede colocar una llamada al comando cp (copiar en sistemas UNIX) o un script que devuelva cero en caso de xito, y solamente en caso de xito, ya que en ese caso PostgreSQL supondr que el archivo est resguardado y ya puede proceder a su reciclado. En caso contrario PostgreSQL tratar de ejecutar el comando especicado ms adelante. Por lo tanto, si queremos tener un respaldo de los archivos de WAL antes que sean reciclados dichos archivos, debemos habilitar la opcin archive_mode (slo se puede hacer al arrancar el motor) y especicar el comando que se va a usar en el parmetro archive_command. En este ltimo, los %p se reemplazarn por el camino al archivo (PATH) desde el directorio PGDATA, y los %f se reemplazan por el nombre del archivo noms. Un ejemplo podra ser:
archive_command = cp -i %p /mnt/servidor-respaldo/archivado/%f < /dev/null
En el ejemplo este, cuando se haya llenado el archivo de WAL %f, este se copiar al directorio /mnt/servidor-respaldo/archivado/ que puede ser
Cursos de OSS
43
una sistema de archivos de red, o una carpeta separada del mismo servidor. La opcin -i la usamos para que cp no sobre-escriba archivos de WAL que han sido copiados con anterioridad. Esto se repetir para cada archivo de WAL que se vaya llenando.
4.5.2. Realizar un respaldo inicial

Para poder realizar un respaldo base, sobre los que luego incorporaremos los archivos de WAL que se han copiado, se deben realizar los siguientes pasos: 1. Habilitar el archivado de WAL en postgresql.conf, y asegurarse que est funcionado. 2. Conectarse al motor de Bases de Datos y ejecutar el comando:
SELECT pg_start_backup(etiqueta);
El parmetro que acepta esta funcin, en este caso la cadena etiqueta, puede ser cualquier cadena, y servir para identicar al respaldo que se est por empezar (una buena etiqueta podra ser el nombre del archivo al que se va a volcar la Base de Datos). Lo que hace la ejecucin de esta funcin es activar el archivado, creando un archivo backup_label en el directorio del Cluster con informacin sobre el respaldo. 3. Realizar el respaldo usando alguna aplicacin del Sistema Operativo como pueden ser tar o cpio. Este respaldo se puede hacer en caliente (sin tener que detener el motor). 4. Conectarse nuevamente a la Base de Datos y ejecutar el siguiente comando:
SELECT pg_stop_backup();
Esta funcin terminar con el proceso de respaldo y automticamente pasa al prximo segmento de archivo de WAL. La razn para pasar al prximo segmento de archivo es asegurarse que el ltimo segmento de WAL escrito durante el respaldo puede archivarse inmediatamente. 5. Cuando los segmentos de archivos de WAL fueron respaldados ya est terminado el respaldo de todos los datos. El archivo cuyo nombre devuelve pg_stop_backup es el ltimo archivo de WAL que debe ser respaldado. Esto
Cursos de OSS
44
Captulo 4. Administracin se har automticamente, ya que se ha congurado adecuadamente el parmetro archive_command en postgresql.conf. De todas maneras, debe asegurarse el administrador a cargo de los repaldos de que efectivamente se hayan copiado todos los archivos de WAL necesarios para restaurar el Cluster.
4.5.3.
Restaurando la Base de Datos con los Respaldos Continuos de Archivos de WAL
Para restaurar una copia que se ha realizado con pg_start_backup() debemos seguir determinados pasos para asegurarnos que la restauracin de la Base de Datos se realiz correctamente. 1. Detener el servidor de Bases de datos si est corriendo. 2. Hacer una copia de todos los archivos del Cluster incluyendo directorios de tablespaces para ser usados luego. Si no tiene espacio suciente como para copiar todos los datos, por lo menos copie los datos del directorio pg_xlog/, que puede contener transacciones que no se archivaron al momento de apagar PostgreSQL . 3. Borrar todos los archivos del directorio del Cluster y de las races de los directorios de las tablespaces, si hubiese alguna. 4. Recupere los archivos de la Base de Datos del respaldo que hizo (el .tar por ejemplo). Hay que tener la precaucin de que sean restitudas con los atributos de dueo de los archivos correctos, en este caso, el super-usuario del Cluster (postgres por lo general), y los permisos adecuados (o mejor dicho, correctos). Si se us tar, es aconsejable agregar la opcin -p cuando se vuelquen los datos de vuelta al disco. Si tiene tablespaces debe vericar tambin que los enlaces simblicos que se encuentran en pg_tblspc/ estn bien. 5. Borre cualquier archivo que se encuentre en el directorio pg_xlog/, esto claro, si en el respaldo de nivel de sistema de archivos estaba este directorio. En caso que se haya respaldado, este contendr informacin errnea u obsoleta. Si no respaldo el directorio, entonces creel, y asegrese de crear tambin el directorio pg_xlog/archive_status/. 6. Si tiene segmentos de WAL que no fueron archivados y guard en el paso 2, cpielos al directorio pg_xlog/. No los mueva, ya que si algo sale mal, tener una copia original de dichos archivos le permitir empezar de nuevo.
Cursos de OSS
45
7. Crear el archivo recovery.conf para la ejecucin de comando de recuperacin en el directorio del Cluster (vea la seccin 4.5.3.1 para informacin de sintaxis del archivo). Adems debera deshabilitarse el acceso de otros usuarios a las Bases de Datos, modicando el archivo de control de accesos pg_hba.conf (vea la seccin 4.1.1 para ms informacin) hasta asegurarse que la recuperacin fue exitosa. 8. Inicie el servidor de Bases de Datos. El servidor entrar en modo de recuperacin y proceder a leer los archivos de WAL archivados con archive_command necesarios para realizar la restauracin del Cluster completo. Si por alguna razn la recuperacin termina debido a un error, puede reiniciar el servidor de Bases de Datos y continuar la recuperacin de datos. Una vez que se complet el proceso de recuperacin, el servidor renombrar el archivo recovery.conf a recovery.done para prevenir entrar accidentalmente en modo de recuperacin nuevamente. A partir de este momento empieza el motor a recibir operaciones normales de una base de datos. 9. Verique que los datos y estructura de su Base de Datos est como quizo recuperarla. Si no, vuelva al paso 1 y empiece de nuevo. Si todo est como esperaba, restituya el archivo de accesos pg_hba.conf a su estado anterior a empezar la recuperacin. Reinicie el motor (para que el cambio de pg_hba.conf surta efecto y ya esta el motor de nuevo en produccin). Lo importante ac es escribir correctamente el archivo recovery.conf. El parmetro que tiene que estar s o s es la conguracin de recovery_command, que es similar, pero a la inversa, de archive_command: el segundo archiva los logs de WAL, mientras que el primero recupera los archivos que archiv el segundo. Como en el caso de archive_command, es importante que el comando que se ejecute devuelva un valor distinto de cero en el caso de error en el copiado de los archivos. Cuando se le pida al comando congurado en recovery_command por archivos que no han sido archivados, debe devolver un valor distinto de cero (como es la convencin en programacin). Los segmentos de WAL que no fueron archivados sern buscados en el directorio pg_xlog/, lo que posibilita el uso de los archivos de WAL que no fueron archivados, como explicamos en el paso 6 de los pasos de recuperacin. Si en el archivo recovery.conf slo se especic el parmetro recovery_command, el proceso de recuperacin seguir adelante hasta que no haya ms segmentos de WAL, lo que recuperar los datos al instante, o casi, en que se
Cursos de OSS
46
guardo la ltima transaccin en los segmentos de WAL. Esto signica que la recuperacin terminar con un mensaje de le not found, o No existe el chero o el directorio en el caso de tener seteado el idioma en espaol, que es el mensaje que dar el comando que se congur cuando trate de copiar un segmento que no est (esto pasa despus de copiar el ltimo segmento). Si durante la recuperacin de los datos, se encuentra un segmento de WAL corrupto, el proceso se interrumpir en ese instante y el servidor no se iniciar. En estos casos se puede intentar correr nuevamente el proceso de recuperacin desde el principio, modicando los parmetros recovery_target_* para que recupere todo, hasta un instante antes del punto de corrupcin. Si la falla es debido a una cada del sistema durante la recuperacin, o si los archivos de WAL dejaron de ser accesibles en algn momento, entonces la recuperacin de los datos se puede reiniciar (por lo gerenal simplemente iniciando el servidor) y reanudar la recuperacin desde el punto en el que fall. 4.5.3.1. Preparando conguracin para restaurar copia
PostgreSQL revisa el archivo recovery.conf para saber cmo se va a rea-
lizar la recuperacin de las transacciones que quedaron en los logs de WAL que fueron archivados. Todos los parmetros que se incluyen en este archivo no pueden ser modicados una vez que se comenz con la restauracin del respaldo de los archivos de WAL. Un ejemplo de archivo recovery.conf simple de como recuperar TODAS las transacciones que fueron archivadas en los segmentos de WAL sera:
# Comando de recuperacion de los archivos respaldados restore_command = cp /mnt/servidor-respaldo/archivado/%f %p
Figura 4.1: Ejemplo de archivo de recuperacin recovery.conf Sin embargo hay otras opciones que se pueden agregar para hacer PITR. Vamos a dar las opciones con el tipo de dato de ella y qu signica.
recovery_command (cadena): El comando que debe ejecutar PostgreSQL para recuperar la serie de segmentos de WAL que fueron archivados. Este
parmetro es requerido, sino no se har la restauracin de las transacciones. La sintaxis es igual, o al menos similar, a la del comando archive_command. Este comando debera tener el efecto inverso a archive_command, o sea, debe traer los segmentos que fueron archivados para su posterior recuperacin.
Cursos de OSS
47
recovery_target_time (timestamp): este parmetro especica el instan-
te hasta el que se va a recuperar datos comprometidos en transacciones. Si se especica recovery_target_time, no se puede usar la opcin recovery_target_xid.
recovery_target_xid (cadena): Este parmetro especica el identicador
de transaccin hasta el que se recuperarn datos. Esta opcin, como se explic antes, no se puede combinar con recovery_target_time (se puede usar una opcin o la otra). Recuerde que, aunque las transacciones tienen identicadores que se asignan de manera secuencial, no necesariamente se comprometen, en el tiempo, en ese mismo orden. Por lo tanto entre el inicio de una transaccin y su COMMIT, puede haber otras transacciones que empezaron despus (o sea, tienen ID superior) pero se comprometiron antes que sta, y por lo tanto entraran en dicha recuperacin.
recovery_target_inclusive (boleano): Especica si se debe detener la
recuperacin justo despus de recuperar la transaccin especicada en recovery_target_xid o en recovery_target_time, o si debe recuperar hasta justo antes. En otras palabras, si la transaccin especicada, tanto explcitamente por su ID, o implcitamente con un instante de tiempo (si es que hay una transaccin que cae justo en ese instante), debe recuperarse tambin o no. El valor por defecto es verdadero.
log_restartpoints (boleano): Especica si se debe registrar cada instante
de reinicio de recuperacin. Esto puede ser necesario para ver el progreso de una recuperacin larga. El valor por defecto es falso.
4.5.4. Advertencias y cuidados

Al usar archivado de segmentos de WAL para tener un respaldo On-line hay algunos cuidados que se deben tener: Las operaciones sobre ndices hash no son registrados en los segmentos de WAL, por lo tanto, no van a estar cuando se recuperen las transacciones archivadas en los segmentos de WAL. Para subsanar este problema, hay que ejecutar un REINDEX manual cada uno de estos ndices una vez terminada la recuperacin total de las transacciones.
Cursos de OSS
48
Captulo 4. Administracin Si se ejecuta CREATE DATABASE mientras se est realizando el respaldo, y luego la Base de Datos plantilla (template1 por ejemplo) cuando an no concluy el respaldo (tanto la creacin de la Base de Datos, como la modicacin de la plantilla suceden durante el respaldo), es posible que despus de la recuperacin de los datos, dichos cambios en la plantilla se propaguen a la Base de Datos creada. Por ello, hay que evitar modicar las Bases de Datos plantilla durante un respaldo. Los comandos CREATE TABLESPACE son registrados en los segmentos de WAL con el recorrido de rbol absoluto a donde estn, y por lo tanto sern recuperados en ese mismo directorio. Esto puede no ser lo que se desea si el respaldo ser recuperado, por ejemplo en otra mquina, o si se hace en la misma maquina, pero en otro directorio. Para evitar estos problemas, se recomienda realizar un nuevo respaldo despus de crear o eliminar tablespaces.
4.6. Actualizacin de PostgreSQL

La actualizacin del motor, o sea la instalacin de una versin ms nueva de los binarios del motor, debe realizarse con cuidados especiales, porque cambios de versiones pueden conlleva cambios en cmo almacena el motor los datos de las bases. O sea, puede que dos versiones diferentes de PostgreSQL no almacenen los datos en disco de la misma forma, y en una actualizacin, los datos que fueron generados con el sistema viejo ya no podrn ser ledos con el nuevo. Por suerte PostgreSQL tiene una poltica de versiones que hace muy sencillo para el administrador saber si se requiere o no actualizar la estructura de datos. Primero veamos como es la estructura de versiones de PostgreSQL . Las versiones de PostgreSQL estn formadas por tres nmeros separados por puntos, por ejemplo 8.2.7. Los primeros dos nmeros son para identicar a una nueva versin, donde se han agregado nuevas caractersticas y funcionalidades, que casi siempre traen aparejado cambios en el manejo interno de la estructura de los datos. El ltimo nmero es el Patch Level (nivel de parches). En nuestro ejemplo la nueva versin que sali fue la 8.2 y hubo 7 parches5 posteriores hasta llegar a dicha versin. Ahora, si se quisiera actualizar la versin 8.2.7 de PostgreSQL a, por ejemplo, la versin 8.3.1, la instalacin nueva no podra leer la estructura de los datos
5 no son exactamente 7 parches, sino varios parches. Cada Patch Level son muchos parches que se han incorporado al cdigo desde el ltimo release
Cursos de OSS
4.6. Actualizacin de PostgreSQL
49
que fue generada por una versin actual, ya que no son compatibles. Por eso debemos guardar la estructura y los datos en algn formato que pueda ser interpretado, a travs de alguna aplicacin, por ambas versiones. Dicho formato es simplemente el lenguaje SQL. Para obtener toda la estructura adems de los datos de todas las bases de datos que viven en nuentro motor usamos pg_dumpall.
postgres$ pg_dumpall > backup-total.sql
pg_dumpall devuelve por la salida estndar el vuelco de la estructura y los datos de todas las bases. Si slo se quiere guardar algunas bases se puede usar el programa pg_dump. Ambos programas se vern en profundidad en la seccin 4.4.2 En sntesis, se debe hacer un respaldo de las estructuras y sus datos usando pg_dumpall (ver seccin 4.4.2), actualizar los binarios del motor, inicializar el nuevo espacio de datos, con el nuevo formato, usando initdb (ver seccin 2.3), luego se arranca el motor (ver seccin 2.4), y terminar volcando en el nuevo espacio de datos las estructuras y datos del archivo del respaldo. Todo esto se ve en el siguiente esquema: Vuelco de los datos Inicializar (ver 2.3) Actualizacin de binarios Borrar $PGDATA Arrancar motor (ver 2.4) Recuperar datos del vuelco
Por otro lado no es necesario este procedimiento cuando se actualiza a un nivel de parche superior dentro de la misma versin. Por ejemplo, si se va a actualizar de la versin 8.2.4 a la 8.2.7, no es necesario volcar los datos, inicializar nuevamente el espacio de datos para volcar la estructura otra vez, aunque siempre se recomienda tener una copia de respaldo a mano por cualquier eventualidad, y en particular cuando se realizan operaciones tan sencibles como una actualizacin de los binarios del motor.
4.6.1. Actualizacin fcil en Debian

Si se est usando una distribucin basada en Debian el administrador puede hacer uso del sistema de mltiples Clusters (y mltiples versiones) que trae esta distribucin. El procedimiento en este caso sera: 1. Instalar la nueva versin del motor, por lo general usando apt-get. El congurador que se ejecuta al instalar va a detectar que ya se encueentra un PostgreSQL corriendo en puerto 5432 y por lo tanto lo congurar en otro puerto (5433, si est disponible). Tambin le asignar otro Socket.
Cursos de OSS
50
Captulo 4. Administracin 2. Inicializar y arrancar el nuevo motor (recordar que en la seccion 2.3 vimos que Debian tiene los Clusters en directorios separados por versin, etc.). 3. Volcar y recuperar simultneamente los datos de las bases (ver gura 4.2) 4. Modicar el archivo postgresql.conf cambiando el puerto y socket para que tenga las que usan las aplicaciones que se conectan. 5. Dar de baja el servidor viejo y reiniciar el nuevo (para que tome los valores de puerto y socket modicados anteriormente)
postgres$ pg_dumpall -p 5432 | psql -p 5433
Figura 4.2: Dump y restore en una sola lnea La gran ventaja con este procedimiento es que casi6 no sale de servicio el servidor. Igualmente hay que tener precauciones, ya que si se producen actualizaciones sobre los datos de la base vieja mientras se esta haciendo el volcado de datos o despus, cuando an no arranc el nuevo motor en el puerto por defecto, dichos cambios no estarn en la nueva estructura.
4.6.2.
Otras cosas a tener en cuenta
Adems de todo lo explicado anteriormente, pueden aparecer otros problemas cuando se actualiza el motor entre versiones. Algunas funciones que vienen con la instalacin pueden ya no estar ms, o cambiar el comportamiento. Es por ello que se recomienda siempre leer el archivo Release Notes de la versin que se va a instalar (por lo general est en la documentacin online y en el archivo que se descarga con los fuentes), para as estar prevenido de cambios que se produjeron, y poder subsanarlos antes de realizar la actualizacin en un sistema en produccin.
4.7.
Usando el catlogo de PostgreSQL
El catlogo del motor de base de datos es donde se guardan los datos del motor, como son las estructuras de las bases de datos, los usuarios, otros objetos (como vistas, reglas, operadores, ndices, etc.). La informacin de estos objetos
6 El casi se debe a que hay que reiniciar el servicio al cambiar el puerto, cosa que no demora mas de 30 segundos dependiendo de la capacidad del servidor y la cantidad de conexiones abiertas en ese momento
Cursos de OSS
4.7. Usando el catlogo de PostgreSQL
51
son almacenados en tablas de sistema que no pertenecen a ninguna base de datos que sea accesible, sino que estn en el catlogo, y pueden ser accedidas desde conexiones hechas a cualquier base de datos del Cluster. Todas estas tablas tienen nombres especiales que tiene el prejo pg_7 , por lo que son fciles de distinguir. Adems, por lo complejas que son las tablas, en las ltimas versiones de PostgreSQL se han incorporado vistas que facilitan la bsqueda de determinada informacin. Si se desea ver todas las tablas de sistema que se encuentran en el catlogo slo debe invocar el comando \dS (la S es mayscula) dentro del intrprete de comandos psql que veremos ms en detalle en la seccin 6.1. Vamos a ver algunas de estas tablas y vistas ms en detalle.
pg_database: Guarda informacin de las bases de datos, como: su nombre,
el dueo, la codicacin de la base, y otros datos.

pg_authid: Tiene informacin de los roles del sistema (los roles que se
guardan en la Base de Datos), incluyendo la contrasea. Slo el super usuario postgres puede acceder para leer los datos de la tabla.
pg_roles: Esta es una vista que lee los datos de pg_authid, salvo la contrasea (en su lugar escribe asteriscos) y es accesible para todos los usuarios a diferencia de pg_authid. pg_stat_activity: Es una vista que devuelve informacin de las conexio-
nes que estn activas en el motor, e informacin como: a qu base de datos est conectado, con qu role, y qu consulta est ejecutando.
pg_indexes: Vista que muestra informacin de los ndices de la base de
datos a la que est conectado.

pg_views y pg_rules: Como su nombre lo dice, contienen informacin
de las vistas y reglas respectivamente de la base de datos en la que est conectado. Ambas son vistas.
pg_setting: Es una vista que devuelte informacin de seteo de variables, como por ejemplo shared_buffers. pg_statistic y pg_stats: pg_stats es una vista de pg_statistic que
slo muestra informacin de las tablas que el usuario puede leer. Si intenta
7 los usuarios pueden tambin crear tablas con dicho prejo, pero no es recomendable ya que lleva a confusin con las tablas de sistema
Cursos de OSS
52
Captulo 4. Administracin ver datos de la tabla pg_statistic, salvo con el usuario portgres, el motor le devolvera un mensaje de error diciendo que no tiene permiso para ver los contenidos de dicha tabla, pero s podr ver los de la vista pg_stats.
pg_statistic tiene datos estadsticos que se guardan durante la ejecucin de ANALYZE o VACUUM ANALYZE, y que le servirn al planner para encon-
trar el mejor plan para la ejecucin de determinada consulta.
Cursos de OSS
Captulo 5 Monitoreo de actividad de la base de datos

5.1. Uso de herramientras de administracin del Sistema Operativo
En Sistemas Operativos UNIX el comando ps nos dar la informacin sobre los procesos que se estn corriendo en un momento determinado. Usando otras herramientas de administracin del Sistema Operativo, como grep, podemos ver los procesos de postgres:
# ps auxw | grep ^postgres postgres 2515 0.0 0.5 433552 10892 ? postgres 2520 0.0 0.1 433892 3992 ? postgres 2521 0.0 0.0 433756 1264 ? postgres 2522 0.1 0.1 435900 3040 ? postgres 2523 0.0 0.1 15480 2468 ? postgres 9357 0.0 0.2 435132 5716 ? postgres 9359 0.0 0.2 435384 6088 ? postgres 9393 0.0 0.2 435124 5656 ? postgres 13975 0.0 0.2 435384 6108 ? postgres 13977 0.0 0.2 435384 6088 ? postgres 14065 0.0 0.2 435384 6088 ? postgres 14077 0.0 0.2 435124 5660 ? postgres 14435 62.6 2.2 435860 47132 ? S Ss Ss Ss Ss Ss Ss Ss Ss Ss Ss Ss Rs 12:03 12:03 12:03 12:03 12:03 15:09 15:09 15:09 17:33 17:33 17:34 17:35 17:45 0:01 0:00 0:00 0:22 0:12 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:11 /usr/lib/postgresql/8.3/bin/postgres postgres: writer process postgres: wal writer process postgres: autovacuum launcher process postgres: stats collector process postgres: sigesbi trac-sigesbi 127.0.0.1(40350) idle postgres: sigesbi trac-sigesbi 127.0.0.1(40351) idle postgres: sigesbi trac-sigesbi 127.0.0.1(40352) idle postgres: sigesbi trac-sigesbi 127.0.0.1(50241) idle postgres: sigesbi trac-sigesbi 127.0.0.1(50242) idle postgres: sigesbi trac-sigesbi 127.0.0.1(50243) idle postgres: sigesbi trac-sigesbi 127.0.0.1(50244) idle postgres: biblioteca siprebi 127.0.0.1(55777) SELECT
Claramente se pueden ver los procesos que postgres ha levantado, empezando por el primero que es el proceso servidor (se ejecuta cuando se inicia el servidor, y es el encargado de iniciar los dems procesos postgres). Luego se ve unos procesos de escritura en segundo plano (procesos de WAL, de autovacuum, etc.), y despus hay 8 procesos de postgres (uno por cada conexin que se est realizando sobre el motor de Bases de Datos). La estructura de estos procesos es la siguiente:
postgres: usuario basededatos host actividad
53
54
Captulo 5. Monitoreo de actividad de la base de datos
Cada vez que se inicializa una conexin el proceso tendr una estructura como la de arriba, donde actividad ser, hasta que se enve algn comando al motor, idle (en espera). Al ejecutarse, por ejemplo, una consulta, se modicar la lnea de procesos, cambiando actividad por el tipo de procesos que se ha ejecutado (vea el ltimo proceso de postgres que est ejecutando una consulta SELECT). Recordar, de la seccin 3.11.2, que para que el nombre del proceso cambie de acuerdo al estado de la conexin, update_process_title debe estar habilitado. En algunos Sistemas Operativos esto puede penalizar mucho al servidor en cuanto a rendimiento, y en otros casi ni inuir. Por lo general es lo ltimo.
5.2.
Buscando procesos que poseen Locks
Otra tarea administrativa que puede aparecer (aunque por lo general los desarrolladores son quienes ms harn uso de lo que se va a tratar en esta seccin) es la visualizacin de bloqueos que estn en actividad en la base de datos. Esto puede ser importante para ver que conexin est bloqueando alguna consulta que queremos realizar. PostgreSQL guarda en el catlogo toda la informacin de la Base de Datos, entre ello, las Bases, sus tablas, las conexiones, y obviamente los bloqueos que se han seteado con informacin de qu tipo de bloqueo es, sobre qu objeto, etc. Toda esa informacin se puede ver en vivo a travs de la vista del catlogo pg_locks. Esta vista se puede usar, por ejemplo, para las siguientes actividades: Ver todos los bloqueos activos al momento de la ejecucin de la consulta, todos los bloqueos sobre relaciones de una Base de Datos en particular, los bloqueos en una relacin en particular, o todos los bloques colocados en una sesin particular de PostgreSQL . Ver si hay bloqueos que estn esperando a que otras transacciones liberen el acceso a las relaciones que se estn tratando de acceder. Ac se vern los bloqueos que estn esperando, y que otro bloqueo los esta reteniendo. Esto signica que alguna transaccin solicit un bloqueo sobre una relacin, y que an no fue levantado, y otras transacciones que se han iniciado y quieren acceder a dicha relacin estn en espera. Determinar los efectos que producen determinados bloqueos en el rendimiento global de una Base de Datos. La vista no es muy amigable, ya que no tiene los nombre de los objetos a los que hace mencin (tablas, Bases de Datos por ejemplo), pero se pueden relacionar bastante bien con otras vistas o tablas del catlogo.
Cursos de OSS
5.3. Vericando uso de disco desde el motor Un ejemplo podra ser:
55
SELECT pl.locktype AS tipo,pl.mode AS modo, pd.datname AS database,pc.relname AS relacion FROM (pg_locks pl JOIN pg_class pc ON (pc.oid=pl.relation)) JOIN pg_database pd ON (pl.database=pd.oid)
En este caso obtenemos el nombre de la Base de Datos sobre la que se realiz la conexin, el nombre de la relacin sobre la que est ejecutadose el bloqueo, el tipo de bloque y el modo de bloqueo.
5.3. Vericando uso de disco desde el motor

Algo con lo que hay que tener cuidado es en el uso que PostgreSQL hace de los recursos fsicos de disco, ya que cosas muy malas pueden suceder si estos recursos se acaban. Algunas veces puede ser buena idea linquear a otro disco los directorios pg_xlog y pg_clog (un disco separado, al que slo se escriban archivos de estos dos directorio, o el primero). Esto dar como resultado 2 cosas: 1. Cuando el disco donde est $PGDATA se llene, el sistema dar error (no pueden ejecutarse los puntos de control (vea la seccin 3.6.2) que pasan las transacciones comprometidas en el log de WAL a las tablas). Si el llenado de dicha particin se debe a la creacion de un nuevo segmento de WAL, ste puede quedar incompleto, no pudiendo recuperarse su informacin. Lo mismo vale para el log de estado de las transacciones. 2. En sistemas con mucha actividad de modicacin de datos, el motor har gran uso de fsync sobre el directorio pg_xlog (directorio donde estn los segmentos de WAL). Si este directorio est en un disco separado, y al escribirse contnuamente sobre l, se mejora mucho la performace de escritura ya que el cabezal de este disco estara siempre al nal del log de WAL, que es justamente donde tiene que escribir (en este caso pg_clog no debera estar en este disco, ya que el cabezal del disco ir de los archivos de pg_xlog al de pg_clog).
5.3.1. Quin est usando el espacio de disco?

Una pregunta que se hace el administrador cuando se encuentra con un disco que super cierto lmite de uso es: quin est usando el espacio de disco? Para ello podemos usar herramientas de sistemas UNIX como du dentro del directorio $PGDATA/base/. Este directorio tiene un montn de directorios con
Cursos de OSS
56
nmeros como nombres. Cada uno de estos directorio contiene los archivos de una Base de Datos. Los nmeros son los oid de las Bases de Datos en la tabla pg_database. Otra forma, ms granular, de ver, ya dentro de una Base de Datos, cunto est usando cada objeto de dicha base, es ver el valor alojado en la columna relpages de la tabla pg_class, dato que actualiza VACUUM, ANALYZE y algunos otros comandos de SQL como REINDEX. Esta columna lo que tiene es una estimacin de la cantidad de pginas en disco de tamao BLCKSZ (por lo general de 8kb, salvo que se modique en el momento de compilacin). Ac damos un ejemplo para ver el nombre y cantidad de pginas de disco de todas las tablas del esquema biblioteca:
SELECT relname, relpages FROM pg_class WHERE relkind = r AND relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = biblioteca)
Modicando el valor de restriccin relkind podemos ver el tamao de los ndices, por ejemplo. Para poder ver cuales son las relaciones que ms espacio estn ocupando se puede usar un ORDER BY as en seguida vemos los que estn ocupando ms espacio, como por ejemplo usando la siguiente consulta:
SELECT relname, relpages FROM pg_class ORDER BY relpages DESC LIMIT 10;
Tambin VACUUM con la opcin verborrgica da mucha informacin entre la que se encuentra la cantidad de pginas de disco que usan las tablas y sus ndices. Debemos siempre recordar que PostgreSQL no guarda toda la informacin de las tuplas en las tablas. Si el tamao de una tupla excede cierto tamao, parte de dicha informacin ir a parar a las tablas de TOAST1 correspondientes a la Base de Datos donde se encuentra la relacin. En el siguiente ejemplo vemos las pginas de TOAST usadas para guardar tuplas de la tabla importaciones. Esta tabla tiene un campo reporte de tipo TEXT, y por lo general los valores que se ingresan a dicho campo superan, por lo general, holgadamente los 8000 caracteres. Podemos ver que la tabla importaciones ocupa ms de 1Mb en pginas de
TOAST
1 Es un acrnimo que signica The Oversized-Attribute Storage Technique, o La Tcnica de Almacenaje de Atributos Sobredimensionados que existe en PostgreSQL desde la versin 7.1
Cursos de OSS
5.3. Vericando uso de disco desde el motor

SELECT relname, relpages FROM pg_class, (SELECT reltoastrelid FROM pg_class WHERE relname = importaciones) ss WHERE oid = ss.reltoastrelid OR oid = (SELECT reltoastidxid FROM pg_class WHERE oid = ss.reltoastrelid) ORDER BY relname; relname | relpages ------------------------+---------pg_toast_8921084 | 144 pg_toast_8921084_index | 4
57
Cursos de OSS
58
Cursos de OSS
Captulo 6 Interactuando con el motor de la base de datos

Una vez que ya tenemos el motor funcionando, y se han congurado adecuadamente los archivos de acceso y de conguracin del motor, llega el momento de interactuar con l. Trataremos entonces de mostrar algunas aplicaciones adicionales que vienen con PostgreSQL , o que se pueden instalar aparte (por lo general vienen en las distribuciones ms populares).
6.1. Aplicacin de lnea de comandos: psql

Muchas veces el programador debe probar contnuamente distintas consultas a la base de datos, volviendo a ejecutar con cambios menores (o no tanto) para poder conseguir consultas ms veloces. Como an existen programadores que no se ven identicados con la programacin visual y preeren una interface de comandos en lnea y un editor, para ellos existe un shell para ejecutar directamente las consultas sobre el motor de la base de datos: psql. Adems ser de gran utilidad cuando tengamos que volcar datos de archivos de texto (una copia de respaldo, o datos que provienen de, por ejemplo, una planilla de clculo). El psql trabaja en modo texto, por lo que se debe ejecutar desde una terminal de texto: tty[1-6], xterm, konsole, o por una terminal remota como ssh, etc. Al ejecutarlo dentro de dicha terminal de texto, psql puede devolver informacin en la terminal y volver al prompt del shell de sistema operativo, por ejemplo cuando se ejecuta con la opcin -l, o quedarse con el prompt del psql esperando por consultas para la base de datos. Trataremos en esta seccin de mostrar las virtudes de este shell para que lo pueda aprovechar al mximo. La aplicacin psql tiene muchas opciones y argu59
60
Captulo 6. Interactuando con el motor de la base de datos
mentos que se le pueden pasar, pero nosotros nos concentraremos en los que son ms importantes en este momento (ms informacin sobre los posibles argumentos en el manual de psql: man psql).
6.1.1.
Argumentos de psql
Cuando se inicia psql se le pueden dar argumentos que afectaran el comportamiento de la aplicacin. Adems hay variables de entorno que tambin afectn cmo va a trabajar la aplicacin psql. Antes de seguir debemos decir que nuestro motor puede tener muchas bases de datos, que pertenezcan a distintos usuarios. Por lo tanto debemos saber cules tengo en mi sistema para luego poder elegir cul estaremos interesado en usar. Para eso es que est la opcin -l. Ac se da un pequeo ejemplo:
martin@bugs:~> psql -l List of databases Name | Owner | Encoding --------------+----------+---------diario | diario | LATIN1 horde | postgres | LATIN1 lismarch | lismarch | LATIN1 novedades | aroman | LATIN1 phppgadmin | postgres | LATIN1 prueba | martin | LATIN1 siprebi | postgres | LATIN1 template0 | postgres | LATIN1 template1 | postgres | LATIN1 (13 rows) martin@bugs:~>
Figura 6.1: Bases de datos disponibles en nuestro Cluster Se puede observar primero que esta opcin devuelve una lista de las bases de datos existentes en el sistema, y vuelve al shell del sistema operativo. La salida se compone de 3 columnas: El nombre de la base de datos, a quien le pertenece (el dueo de dicha base), y la codicacin usada. Otras opciones importantes que acepta psql son:
-d nombreBD: Sirve para indicar a qu Base de Datos nos vamos a conectar. En la ausencia de esta opcin psql buscar en la variable de entorno
Cursos de OSS
61
PGDATABASE para saber a qu base conectarse. Si dicha variable no estuvie-
se seteada, tratar de conectarse a la base de datos del mismo nombre que el usuario que est estableciendo la conexin.
-U usuario: Indica con qu usuario se quiere conectar a la base de datos. En su ausencia, se revisar la variable de entorno PGUSER, que si no esta seteada psql se conectar al servidor usando el mismo usuario que ejecuto psql en el sistema operativo. -h servidor: Indica el servidor al que se debe conectar. Si no se especica, se buscar la variable de entorno PGHOST para saber el host al que se debe conectarse. Por defecto psql se conectar a travs del socket situado en el directorio /tmp. -c consulta: Especica que psql ejecute las consultas especicadas en consulta y vuelva al interprete de comandos del sistema operativo, mos-
trando en pantalla los resultados de la ejecucin de dicho comando. Esta opcin es muy til para cuando hay que ejecutar consultas dentro de un script de shell.
-f archivo: Usar el archivo especicado como fuente de las consultas
que deban ser ejecutadas en vez de trabajar en modo interactivo. Cuando se termina de ejecutar la ltima consulta, psql terminar volviendo al prompt sistema operativo.
6.1.2. Comandos especiales

Para poder conectarse a una base de datos determinada, por ejemplo a la base prueba se debe ejecutar el comando psql prueba o psql -d prueba, dando como resultado en pantalla lo que se observa en la gura 6.2.
martin@bugs:~> psql prueba Welcome to psql 7.3.2, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit
prueba=>
Figura 6.2: Ingresando a psql

Cursos de OSS
62
Ahora estamos dentro del shell de motor. Se puede observar que el prompt est formado por el nombre de la base de datos a la que se est conectado, seguido de los caracteres =>1 . Entonces se est listo para escribir consultas para la base de datos. Pero que tal si se quieren ver los objetos que contiene esta base de datos (tablas, secuencias, ndices, vistas, etc.). Ac es donde se ven las cualidades especiales que tiene este shell. Para eso se necesita usar comandos internos de psql. Estos comandos especiales empiezan con una contra barra (\) y una o ms letras que identican el comando. Por ejemplo \dt har un listado de todas las tablas, como se ve en la gura 6.3. Como se puede ver, la informacin que devuelve este comando es bastante completa, pudiendo saber en qu esquema se encuentra dicha tabla, y a quin pertenece. Otros comandos importantes son \di para ver los ndices (ver gura 6.4) o \ds para ver las secuencias.
prueba=> \dt List of relations Schema | Name | Type | Owner --------+-------------+-------+---------public | archivo | table | lismarch public | dias | table | martin public | dominio | table | martin public | hora | table | martin public | ingresantes | table | martin public | nodo | table | postgres public | nodos | table | martin public | numero | table | martin public | prueba | table | postgres public | pruebita | table | postgres public | reglas | table | martin public | test1 | table | martin public | thread_mail | table | lismarch public | times | table | postgres public | usuarios | table | martin (15 rows)
Figura 6.3: Listado de tablas de la base de datos prueba Adems, si se agrega detrs del comando \d el nombre de un objeto (tabla, secuencia, ndice, etc.), psql nos devolver un detalle de las propiedades del objeto. Por ejemplo, sabemos que existe la tabla usuarios en nuestra base, pero
1 Si se inicia la conexin al motor con el superusuario, el prompt cambia a =#, similar a lo que sucede en UNIX
Cursos de OSS
63
queremos saber cmo es dicha tabla, ver sus campos, sus restricciones, etc. Para eso usamos el comando \d usuarios como se ve en la gura 6.5. Se puede ver adems que da un detalle de los ndices que afectan a campos de dicha tabla.
prueba=> \di List of relations Schema | Name | Type | Owner | Table --------+------------------------+-------+----------+------------public | archivo_from_arch_idx | index | lismarch | archivo public | archivo_id_archivo_key | index | lismarch | archivo public | archivo_subject_idx | index | lismarch | archivo public | dominio_idx | index | martin | nodos public | dominio_pkey | index | martin | dominio public | ing_dni_idx | index | martin | ingresantes public | nodo_nombre_key | index | postgres | nodo public | nodos_id_key | index | martin | nodos public | nodos_idx | index | martin | nodos public | numero_id_key | index | martin | numero public | prueba_ident_key | index | postgres | prueba public | pruebita_id_key | index | postgres | pruebita public | pruebita_nodo_key | index | postgres | pruebita public | pruebita_pkey | index | postgres | pruebita public | times_id_key | index | postgres | times public | usuarios_nombre_key | index | martin | usuarios public | usuarios_pkey | index | martin | usuarios (17 rows)
Figura 6.4: Listado de los ndices de la base de datos prueba
prueba=> \d usuarios Table public.usuarios Column | Type | Modifiers --------+--------------------------+------------------------------------------------------------codigo | integer | not null default nextval(usuarios_codigo_seq::text) nombre | character(30) | not null tmodif | timestamp with time zone | not null default (now::text)::timestamp(6) with time zone Indexes: usuarios_pkey primary key btree (codigo), usuarios_nombre_key unique btree (nombre) Check constraints: usuarios_nombre (nombre <> ::bpchar)
Figura 6.5: Detalle de la tabla usuarios Para obtener un listado de los comandos, hay que usar el comando de ayuda \?. Para salir del shell de psql slo hay que ejecutar el comando \q. Como ya lo anunciamos antes, este shell tambin es muy til para volcar datos de una copia de respaldo, o de cualquier otro archivo que tenga el formato de consultas de PostgreSQL. Para esto psql tiene una opcin especial -f (ver el ejemplo de la gura 6.6) que acepta como argumento un archivo que debe contener una secuencia de consultas para ser enviadas a la base de datos. psql ir ejecutando consulta por consulta devolviendo en pantalla los resultados, volviendo al prompt del sistema cuando se termine con la ltima consulta.
Cursos de OSS
64
Otra forma de realizar esto mismo, pero desde el prompt del psql, es usando el comando especial \i archivo, como tambin se indica en la gura 6.6.
martin@bugs:/space/home/martin> psql -d prueba -f archivo.sql prueba=> \i archivo.sql
Figura 6.6: Recuperando datos desde un archivo SQL de dos formas Ms adelante se darn ejemplos por lo general escritos en este shell.
Cursos de OSS
Captulo 7 Alta disponibilidad y balanceo de cargas

En los tiempos que corren, una de las preguntas que los administradores se hacen es si servidores, no nicamente de Bases de Datos, pueden comunicarse unos con los otros para as lograr prestaciones extras, como podran ser: 1. Alta disponibiblidad, por lo que, si el servidor que est en funciones se cae, haya un servidor de respaldo que cumpla con las tareas de este. 2. Balanceo de carga entre varios servidores, muy comn en los servidores web. Esto puede ser sencillo en el caso de servicios con datos estticos, como servir pginas web (descartamos ac la dinmica de las Bases de Datos detrs de los servidores web), e inclusive no es tan complicado en el caso de Bases de Datos de slo lectura. Pero el tema se pone ms complicado cuando no slo se leen datos, sino que tambin se modican. Esto se debe a lo complicado que es propagar transacciones entre los servidores, asegurando algn grado de consistencia de los datos. Como la sincronizacin de los datos puede ser complicada, dependiendo de las necesidades existentes y los recursos con los que se cuentan, con PostgreSQL no hay una nica solucin para los dos casos expuestos, sino que el administrador puede elegir entre una gran variedad de soluciones. Dependiendo de las necesidades, una u otra solucin puede ajustarse mejor. Por ejemplo, si las replicacin de los datos es sincrnica o asincrnica. Algunas implementaciones tratan el tema de la sincronizacin de los datos slo permitiendo modicaciones en un nodo, llamado maestro, y de ste se replican los cambios a los dems nodos, llamados esclavos. 65
66
Captulo 7. Alta disponibilidad y balanceo de cargas
7.1. Replicacin de las Bases de Datos con Slony-I

Slony-I es un sistema de replicacin maestro a mltiples esclavos con so-
porte de replicacin en cascada y promocin a Maestro de algn esclavo. En el concepto de replicacin de Slony-I tenemos algunas cosas que denir antes de seguir adelante:
Nodos: son las distintas Bases de Datos que participan en la replicacin.
Dentro de los Nodos hay varias categoras: Origin: Este es el nodo origen, o Maestro, de dnde se replican todos los datos. Es el nico nodo que debe aceptar modicaciones sobre las tablas que se estn replicando. Los otros nodos se subscriben al Cluster indicando que quieren recibir los datos replicados. Subscriber: Son los nodos que se suscriben al conjunto a replicar para as recibir los datos de la replicacin. Estos son los nodos esclavos. Providers: Estos son nodos Subscriber, o sea que son esclavos, pero que a su vez pueden proveer los datos replicados a otros nodos del Cluster. En tal caso estaramos en presencia de replicacin en cascada.
Cluster: es el conjunto de Nodos, junto con un nombre de Cluster. Replication set (o conjunto a replicar): es el conjunto de relaciones que
intervienen en la replicacin (recuerde que no es necesario replicar una base de datos entera; se puede seleccionar algunas tablas noms).
slon Daemon: Cada nodo en el Cluster debe tener un proceso slon corrien-
do, que es quien se encarga de manejar la actividad de replicacin para ese nodo. Hay dos tipos de eventos que manejar: Eventos de conguracin: Esto ocurre cuando se corre slonik para actualizar conguracin en el Cluster Eventos SYNC: Las modicaciones de los datos de las tablas que se estn replicando son agrupadas en SYNCs, y aplicadas en conjunto a los nodos subscriptos al Cluster.
Cursos de OSS
67
slonik: El comando slonik procesa scripts que se usan para enviar eventos de actualizacin al Cluster de Slony-I. Estos eventos pueden realizar
acciones como agregar y remover nodos, modicar conguracin de comunicacin entre los nodos, agregar o remover subscripciones.
Slony-I se basa en un sistema de disparadores (o Triggers) para replicar modicaciones sobre las tablas que van a estar replicadas en el servidor esclavo. Una ventaja de esta solucin frente a otras es que permite replicar parte de la Base de Datos, o inclusive unas pocas tablas. Veamos como son los pasos para empezar a replicar una base de datos, que puede tener datos al momento de empezar esta conguracin. Primero debemos ver que los accesos esten bien denidos, as se podr acceder de un nodo al otro al momento de enviar los cambios realizados en transacciones que fueron comprometidas.
Los nodos que estan subscriptos al Cluster de replicacin deben tener la opcin listen_addresses adecuadamente congurada para que se accepten las conexiones. Debe tambin ajustarse correctamente el archivo de accesos a la Base de Datos pg_hba.conf.
7.1.1. Conguracin de los archivos slon.conf y slon_tools.conf

Vamos a suponer que tenemos una Base de Datos llamada prueba y queremos que se repliquen los datos de las tablas horas, minutos y apost, todas con llaves primarias bien denidas (alguna columna de la tabla tiene una restriccin de PRIMARY KEY) a otro servidor (en nuestro caso el maestro se va a llamar bugs y el esclavo max). Para ello se escribe la conguracin de Slony-I en los archivos slon.conf, que tienen informacin de cmo se sincronizan los datos, si hay logs, el nombre del Cluster, etc. (que no vamos a tratar, ya que los valores predeterminados son muy difciles de superar en rendimiento) y slon_tools.conf dnde se denen los nodos y el conjunto de relaciones a replicar. La conguracin que se ve en la gura 7.1 comienza con la denicin del nombre del Cluster, que es a eleccin del administrador, pero siempre teniendo presente que Slony-I crear un esquema propio en cada nodo con este nombre, antecediendo un guin bajo. Por ejemplo en el caso de nuestra conguracin, la Base de Datos prueba, en cada uno de los nodos, tendr un esquema llamado _replicaprueba donde Slony-I guardar informacin que precisa.
Cursos de OSS
68
En este archivo tambin se dene el directorio de logs de Slony-I que ser el lugar para buscar por problemas cuando no funcione adecuadamente la replicacin. Luego se denen los nodos y se indica cul va a ser el Maestro. La opcin MASTERNODE debe tener asignada el nmero de nodo, denido ms abajo, que ser el Maestro, quedando los dems nodos relegados a Esclavos. Los nodos se denen usando la funcin add_node() que tiene determinados argumentos que le indican datos del nodo a agregar. La denicin de un nodo, que se basa en dichos argumentos es:
node: El identicador del nodo. Por lo general se los enumera de manera creciente, empezando en 1 (por lo gereral se le da el 1 al nodo Maestro. host: Nombre de host, o direccin IP del nodo (para evitar resoluciones de nombres, es mejor usar lo segundo). dbname: Nombre de la base de datos en este nodo. Es de notar que la Base de Datos puede tener nombres distintos en cada nodo. A Slony-I no le
interesa el nombre de la Base de Datos, slo que est la estructura necesaria para tomar datos, en caso del nodo Maestro o modicarlos en el caso de los Esclavos.
port: Puerto en el que corre el PostgreSQL de este nodo. user: Usuario con el que se va a realizar la conexin. Recuerde que este Role debe tener privilegios de super-usuario, pero no tiene que ser el usuario postgres necesariamente. password: La contrasea del usuario.
Es buena idea vericar que la conexin se realiza con los datos subministrados, por ejemplo usando psql (para ms informacin sobre como usarlo, vea 6.1). En nuestro ejemplo, se debera probar as (ingresando la contrasea indicada cuando es pedida):
$ psql -U slony -d prueba -h max Contrasea para usuario slony:
Ms abajo en el archivo slon_tools.conf se encuentra la conguracin de los conjuntos de relaciones a replicar. Estos se pueden separar en varios conjuntos (nuestro ejemplo, demostrativo, tiene uno slo). Se indica entonces con el nombre del conjunto, en nuestro caso set1 y a continuacin, encerrado entre llaves, cada uno de los parmetros del conjunto, que son:
Cursos de OSS

$CLUSTER_NAME = replicaprueba; $LOGDIR = /var/log/slony1; $MASTERNODE = 1; add_node(node => 1, host => bugs, dbname => prueba, port => 5432, user => slony, password => slonpass); add_node(node host dbname port user password => => => => => => 2, max, prueba, 5432, slony, slonpass);
69
$SLONY_SETS = { "set1" => { "set_id" => 1, "table_id" => 1, "sequence_id" => 1, "pkeyedtables" => [ horas, minutos, apost, ], }, };
Figura 7.1: Archivo slon_tools.conf

set_id: ID del conjunto. Se usa cuando se invoca a las aplicaciones de lnea de comandos de Slony-I, como por ejemplo slonik_create_set y slonik_subscribe_set. pkeyedtables: Lista de tablas con PRIMARY KEY bien denida que se van
a replicar.
7.1.2. Iniciando la replicacin

Cuando ya se ha adecuado el archivo slon_tools.conf con las opciones de relaciones a replicar, y nodos que van a intervenir en el Cluster, debemos asegurarnos que los nodos estn listos para comenzar a recibir informacin de los
Cursos de OSS
70
procesos slon y que tenemos la estructura inicial copiada del Maestro en todos los esclavos. En el caso del ejemplo nuestro de 7.1 solamente hay un Maestro y un Esclavo: bugs y max. El motor en bugs ya tiene la base prueba, que la hemos usado y por lo tanto tiene algunos datos. Vamos entonces a pasar la estructura y los datos a una base recin creada en max tambin llamada prueba.
postgres@bugs$ pg_dump prueba | psql -U slony -W -h max -d prueba
Se debe notar que durante todo este proceso, y hasta que no est en funciones la aplicacin slon no se deberan aceptar conexiones de modicacin a la base de datos prueba, ya que dichos cambios no estaran reejados en la base replicada. Vamos a pasar ahora por cada uno de los pasos para terminar de levantar nuestro Cluster: Primero debemos inicializar el Cluster:
$ slonik_init_cluster | slonik
El comando slonik_init_cluster es un script escrito en Perl que devuelve instrucciones que usar slonik para enviar a todos los nodos. Estas instrucciones son para inicializar el Cluster y entre otras cosas crea el esquema _replicaprueba y la estructura dentro de ese esquema que Slony-I va a necesitar. Debemos arrancar los daemon de slon para cada nodo del Cluster. En nuestro caso, como son slo dos, sera as:
$ slon_start 1 $ slon_start 2
El comando slonik_create_set es un script escrito en Perl que devuelve instrucciones que usar slonik para enviar a todos los nodos instrucciones de creacin de estructura necesaria para replicar los datos del conjunto 1 (nico conjunto en nuestro ejemplo).
$ slonik_create_set 1 | slonik
El comando slonik_subscribe_set es un script escrito en Perl que devuelve instrucciones que usar slonik para subscribir el conjunto 1 al nodo 2.
$ slonik_subscribe_set 1 2 | slonik Cursos de OSS
7.2. Pool de conexiones: pgpool-II
71
7.2. Pool de conexiones: pgpool-II

Otra aplicacin que se puede usar para mejorar el rendimiento en sistemas de gran demanda de consultas, o hacer replicacin sobre varios nodos, es pgpool-II. Las cualidades de pgpool-II son dos: 1. Puede hacer replicacin sobre varios servidores (en realidad lo hace sobre todos los que estan denidos en la conguracin), por lo que escribe en todos los datos modicados (por lo que no hay Maestros ni Esclavos). 2. Y hace, si se lo especica, balanceo de carga, permitiendo repartir conexiones entre los distintos nodos. La forma en que trabaja pgpool-II es hacerse pasar por servidor, escuchando los comandos que envan las aplicaciones (o servidores de aplicaciones), tanto de consulta como de modicacin de datos, y luego pasarlos ecientemente a los nodos con las Bases de Datos. Esto es siempre que se usen determinadas opciones. Este tipo de replicacin es la que se llama Statement-Based Replication Middleware (Replicacin por Middleware Declarativo) ya que los comandos que modican datos se envan a pgpool-II y l se encarga de reenviarlo a cada uno de los nodos, pero como sentencia a ejecutar. Esto puede tener efectos no deseados cuando intervienen funciones o declaraciones que pueden dar valores distintos en cada nodo: por ejemplo la funcin random() o el uso de now(), CURRENT_TIMESTAMP, que son funciones que varan de acuerdo a la hora que tenga el nodo dnde se ejecute. Si esto no es problema para su aplicacin, entonces pgpool-II puede ser una buena solucin. La conguracin de pgpool-II es muy sencilla, y se realiza casi toda en pgpool.conf. Este archivo tiene un formato similar al de postgresql.conf (vea el captulo 3), e incluso tiene opciones que, como conguran parmetros parecidos, se llaman igual (como es el caso de listen_addresses).
listen_addresses: Este valor tiene el mismo efecto, pero sobre pgpool-II que el del mismo nombre del archivo postgresql.conf. Vea dicha opcin
en 3.2.
port: Puerto en el que va a escuchar. A este puerto debern abrir cone-
xiones las aplicaciones que deban usar el pool de conexiones que brinda pgpool-II. Tambin hay que denir los nodos que van a intervenir en el Cluster que forma pgpool-II, con un formato como el siguiente:
Cursos de OSS
72

backend_hostname0 = bugs backend_port0 = 5432 backend_weight0 = 1 backend_hostname1 = max backend_port1 = 5432 backend_weight1 = 1
Ac tenemos 2 nodos, bugs y max. Si se quiere poner ms seguridad en cuanto a quines y cmo se conectan, pgpool-II trae un archivo llamado pool_hba.conf, cuya sintaxis es igual a la del archivo pg_hba.conf, visto en 4.1.1, de PostgreSQL . Para poder usarlo hay que habilitar la opcin enable_pool_hba en el archivo pgpool.conf.
7.2.1.
Replicacin ms Balanceo de Carga
Si se usan las siguientes opciones, se tendr un sistema (en el que interviene pgpool-II y los nodos asociados) donde los cambios se aplican a todos los nodos, pero las consultas son distribuidas entre los nodos intervinentes, o sea, balanceando la carga de sistema.
replication_strict = true load_balance_mode = true
El primer parmetro indica que los datos que se modican (con INSERT, UPDATE, DELETE, etc.) se pararn a todos los nodos. El segundo parametro le indica a pgpool-II que debe balancear la carga de las consultas de SELECT entre los distintos nodos. Hay otras opciones que pueden modicar la forma en que trabaja la replicacin, particularmente los parmetros replication_*.
Cursos de OSS
Captulo 8 Aplicaciones para ayudar en las tareas administrativas y de programacin

En esta seccin se vern algunas aplicaciones grcas que van a permitir administrar de manera ms amigable nuestra base de datos. Algunas de las aplicaciones tambin tendrn utilidad en la programacin y armado de las base de datos.
8.1. pgAdmin III

pgadmin3 se est transformando en una de las aplicaciones ms populares
entre los usuarios de PostgreSQL , por su facilidad de uso, el intensivo desarrollo que se ve en las mejoras que han salido desde pgadmin, pasando por pgadminII, y por estar disponible tanto en sistemas UNIX como Windows1 . Las caractersticas principales de esta aplicacin, como realizar una conexin, revisar los datos, etc., se explicarn en detalla para que los usuarios de PostgreSQL que estn interesados en tener una herramienta como pgadmin3 puedan empezar a usarla de inmediato. Cuando abramos por primera vez pgadmin3 los tres marcos de la aplicacin estarn vacos, ya que an no hay ninguna conexin congurada. Para poder congurar una, podemos ir a [Archivo ->Aadir servidor...] o lo que es lo mismo, apretar con el mouse sobre el primer botn de la barra de botones. Aparecer entonces una ventana (como la que vemos en la gura 8.1) con un formulario en donde debern completarse los datos de la conexin (el usuario ya debera estar familiarizado con estos datos). Una vez completado y aceptado el formulario de la ventana aparecer en el lado izquierdo (marco izquierdo) un nuevo cono con
1
En las versiones anteriores solo estaba disponible para windows
73
74
Captulo 8. Aplicaciones para ayudar en las tareas administrativas y de programacin
el nombre que le di a la conexin. De ahora en ms conectarse a ese Cluster es tan fcil como cliquear 2 veces sobre el cono (o seleccionar conectar del men que se despliega al presionar con el botn derecho sobre l).
Figura 8.1: Ventana de conguracin de una conexin nueva en pgadmin3 Una vez conectado los tres marcos de la aplicacin mostrarn determinada informacin relevante del Cluster de la base de datos. Marco izquierdo: Este marco muestra un rbol con todos los servidores (Cluster) que tiene congurado, y los objetos que contiene. A medida que se abren conexiones a los servidores congurados, y despus a las distintas Bases de Datos que estos contienen, se ir expandiendo la informacin en este marco en un formato de rbol. Marco principal superior: Este marco muestra un detalle del objeto que est seleccionado en el marco izquierdo. Algunos objetos pueden tener estadsticas adems de sus propiedades. Marco principal inferior: este marco muestra la informacin que devuelve el script de ingeniera inversa, una de las utilidades interesantes que se encuentran en esta aplicacin. En un Cluster con varias bases creadas, usuarios y grupos se podr ver mucha informacin en los marcos antes descriptos, como se observa en la gura 8.2.
Cursos de OSS
8.2. phpPgAdmin
75
Figura 8.2: pgadmin3 mostrando toda la estructura del Cluster, bases de datos, esquemas, tablas y el SQL que se uso para crear dicha tabla Adems pgadmin3 permite realizar consultas a la base de datos, o comandos de modicacin de datos tambin, buscando en la barra de men [Herramientas ->Herramienta para consultas] con lo que se abrir una ventana como la de la gura 8.3, en donde se puede escribir sintaxis SQL que ser enviada al servidor para ser ejecutada, mostrando los resultados de la consulta en el marco inferior. Si la consulta que se ejecuta es de inters para el usuario, l puede guardarla para as recuperarla en algn otro momento que quiera ejecutarla nuevamente. Con toda esta informacin, y por la facilidad de uso que tiene, el usuario que ya lleg hasta el punto de realizar la conexin puede fcilmente desplazarse por la aplicacin viendo las destacadas caractersticas que tiene, entre las que se encuentra una herramienta de exportacin de datos, una herramienta para realizar consultas a la base de datos, herramienta de mantenimiento, como muestra la gura 8.4 (limpia, analiza (ver seccin 4.4.1) las tablas y reindexa los ndices) y una ventana de estado de las bases de datos.
8.2. phpPgAdmin
phpPgAdmin en una aplicacin para administrar PostgreSQL , desarrollada http://trac.marquesminen.com.ar/cursos/
Cursos de OSS
76
Figura 8.3: Ventana para ejecutar consultas SQL y ver los resulados
Figura 8.4: Ventana para ejecutar consultas SQL y ver los resulados en PHP, con grandes funcionalidades para facilitar la administracin, traducciones (est traducido al castellano), y facilidad de uso por lo que puede ser usado por usuarios que deban administrar bases de datos en el o los Clusters. Entre las posibilidades que permite se encuentran: Posibilidad de administrar mltiples servidores: Esto facilita enormemente la administracin, y el trabajo diario en ambientes con ms de un servidor de bases de datos. Por lo general hay un solo servidor en produccin, pero es comn tener uno o ms servidores de desarrollo, donde no slo se prueban nuevas versiones de PostgreSQL , sino tambin las aplicaciones que van a
Cursos de OSS
8.2. phpPgAdmin usar el motor.
77
Soporte para PostgreSQL 7.0, 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2 y 8.3: Una aplicacin para todas las versiones de PostgreSQL , as, no importa que versin de PostgreSQL se est usando, phpPgAdmin ser igualmente til. Por lo general (hasta ahora siempre fue as) en las ltimas etapas de desarrollo de una nueva versin de PostgreSQL (generalmente cuando aparece la primer beta), phpPgAdmin ya tiene soporte para esa versin, y esto asegura que tendr buen soporte para dicha versin cuando sea estable. Fcil manipulacin de datos Visualizacin de tablas, vistas y reportes Ejecutar consultas SQL Seleccionar, insertar, actualizar y borrar registros Realizar vuelcos de datos en una variedad de formatos SQL, COPY, XML, XHTML, CSV, tabulado, pg_dump Una vez que ingresamos con nuestro usuario y contrasea, phpPgAdmin nos presentar dos marcos, cada uno de los cuales mantiene determinada informacin, muchas veces informacin que no tiene que ser refrescada con cada cliqueo sobre un enlace. Veamos que informacin nos provee cada uno de los tres marcos: Marco izquierdo: Muestra las base de datos en una estructura de rbol, como se ve en la gura 8.5. Cliqueando sobre alguna de las bases abre una conexin a ella, haciendo que se despliege debajo del cono de la Base de Datos las ramas del rbol con sus esquemas, que a su vez contiene tablas, vistas, secuencias, etc. Marco central: Contiene informacin del servidor, cual es el usuario logueado, y enlaces para entrar a distintas partes del programa. Los enlaces varan dependiendo de que privilegios tenga el usuario y de la parte de la Base de Datos que est observando. Todos los usuarios vern todos los enlaces excepto por los de Roles, que slo podrn ver los usuarios con privilegio de administrador (los super-usuarios). Adems se muestra la informacin que el usuario esta requiriendo. En la parte superior hay algunos enlaces para acceder a determinadas partes generales de phpPgAdmin. Por la condicin de ser generales es que no cambian cuando el usuario va pasando a las distintas partes de la Base de Datos. Todo esto se puede ver en la gura 8.6. Estas opciones son:
Cursos de OSS
78
Captulo 8. Aplicaciones para ayudar en las tareas administrativas y de programacin SQL: Este enlace abrir una nueva ventana donde se puede escribir cdigo SQL que ser ejecutado en la base de datos seleccionada. La gura 8.10 muestra cmo se ve dicha ventana. Buscar: Abrir una ventana similar a la vista en el tem anterior (gura 8.10), pero permite buscar objetos (tablas, ndices, restricciones, etc.) de la base de datos que contengan la cadena de caracteres ingresada. Todos los usuarios ven esta opcin. Salir: Salir de la aplicacin. Todos los usuarios ven esta opcin. Los botones que ver apenas se conecta a una de los Cluster sern: Base de Datos: Las Bases de Datos dispobles en el Cluster seleccionado. Cuenta: Opciones de la cuenta del usuario logueado. Todos los usuarios ven esta opcin. Roles: Permite administrar los usuarios y grupos del motor de base de datos. Slo los superusuarios pueden realizar dichas tareas2 . Datos de consultas que hemos realizado Datos solicitados, como ndices, restricciones Formularios para completar informacin del esquema de una tabla que estamos por crear Todo tipo de informacin que hemos solicitado Ms abajo, en el mismo marco se encuentra informacin requerida por el usuario. como puede ser: Datos de consultas que hemos realizado Datos solicitados, como ndices, restricciones Formularios para completar informacin del esquema de una tabla que estamos por crear Todo tipo de informacin que hemos solicitado
Como se puede ver en la gura 8.5, hay un esquema muy simple de rbol que se despliega al conectarse a una base, mostrando los esquemas que tiene dicha base de datos y debajo de cada esquema un nodo de tablas que contiene todas las tablas de dicho esquema. Adems hay otros nodos para poder ver las vistas, secuencias, funciones y dominios. Cada uno de ellos abrir una nueva pgina en el marco central con informacin relacionada con la opcin que se seleccion.
2
Usuarios que tienen el atributo CREATEUSER http://trac.marquesminen.com.ar/cursos/
Cursos de OSS
8.2. phpPgAdmin
79
Figura 8.5: Listado de las bases de datos
Figura 8.6: Marco central con todas las Bases de Datos dispoibles e informacin sobre ellas
Cursos de OSS
80
Si cliquemos sobre una tabla se podr ver que en el marco central aparecer una pgina con la estructura de la tabla (ver gura 8.7) y enlaces ms abajo para poder realizar ciertas acciones sobre dicha tabla, como por ejemplo examinar los datos que contiene dicha tabla, insertar datos, vaciarla, agregar una nueva columna, etc. (los ttulos explican bastante bien las acciones que realizan).
Figura 8.7: Marco principal mostrando la estructura de una tabla seleccionada Una de las opciones que se mencion es la de examinar los datos que contiene dicha tabla, como se ve en la gura 8.8. Esta accin generar una tabla con un registro de la tabla por la, armando columnas con los campos. Adems mostrar los datos por pginas de 20 registros, haciendo ms sencilla la visualizacin. Hay dos columnas adicionales que tienen enlaces para poder eliminar el registro o modicarlo.
Figura 8.8: Marco central mostrando los datos de una tabla tras usar la opcin examinar Una de las acciones interesantes es la de creacin de una tabla. Al seleccionar la opcin para crear una nueva tabla se le presentar en el marco principal un formulario para completar el nombre que quiere darle a la tabla, la cantidad de campos (columnas) que va a tener la tabla (debe ser un nmero entero mayor o igual a uno), y una opcin especial para indicar si quiere que la tabla no tenga
Cursos de OSS
8.2. phpPgAdmin
OID3 como se ve en la gura 8.9.
81
Una vez que se complet el formulario y aceptamos, aparecer en el marco central una nueva pgina con un formulario en forma de tabla para que se complete la informacin de la nueva tabla (nombre de los campos, tipo y longitud de dato de cada campo, valor predeterminado si lo tiene y la posibilidad de denir si el campo acepta o no valores nulos).
Figura 8.9: Formulario para crear una nueva tabla Una de las opciones que se comentaron en esta seccin es la de ejecutar consultas SQL en una ventana separada (ver las opciones de enlaces del marco central). Cuando uno selecciona el enlace SQL se abre una ventana nueva como ya se explic y que se ve en la gura 8.10. Esta ventana tiene dos enlaces en la parte superior: SQL que representa lo que estamos viendo y Buscar que explicaremos despus. Adems aparece un men desplegable con todas la bases de datos disponibles en el Cluster. Tambin est la posibilidad de especicar la ruta de bsqueda en los esquemas (algo as como setear antes de ejecutar la consulta el valor de search_path al valor especicado). La consulta que realicemos se ejecutar sobre la base de datos que seleccionemos en este men. A continuacin hay un espacio para poder escribir una consulta. Lo interesante de esta nueva ventana de SQL, disponible a partir de la versin 3.1, es que no se cierra y los resultados de la consulta se muestran en el marco central de la ventana principal de la aplicacin, no modicndose la ventana de SQL. Esto permite realizar reiteradamente consultas que pueden ir ajustndose, por ejemplo, cambiando algunos parmetros en el WHERE de la consulta y as ver datos que se ajusten mejor a lo que se desea. Entre los botones que se encuentran en la parte inferior de la ventana estn seguir que sirve para ejecutar la consulta que hemos escrito, restablecer para vaciar el espacio donde se escriben las consultas. Por la facilidad de uso de esta aplicacin, con lo que hemos explicado en esta seccin, ms los conocimientos que se van a adquirir a lo largo de todo este curso,
3
Object IDs son identicadores no visibles de cada registro que tiene la tabla
Cursos de OSS
82
Figura 8.10: Ventana para ejecutar cdigo SQL el alumno la puede usar sin mayores inconvenientes, e instamos a los que estn desarrollando aplicaciones web con PostgreSQL como mecanismo de almacenamiento a usar phpPgAdmin como herramienta de administracin, por su facilidad de instalacin (ms an si ya se tiene un servidor web con todo el soporte que se necesita para desarrollar aplicaciones web con PostgreSQL ) y uso.
8.3.
Postgresql Autodoc
Esta aplicacin permite obtener descripciones de las bases de datos en variados formatos, como HTML, dia4 o DocBook XML. Es una aplicacin escrita en Perl y simplemente realiza una conexin a la base de datos, extrae la informacin de todos los objetos y genera, de acuerdo a las opciones que se le han pasado, un archivo de salida en alguno de los formatos antes mencionados. Trae adems un sistema de plantillas que pueden ser modicas, o incluso se pueden crear nuevas plantillas para ser usadas. En apariencia esta aplicacin no parece muy importante por la sencillez del uso, pero siempre durante el desarrollo de aplicaciones se requiere de informacin de estructuras o esquemas de las bases de datos y esta aplicacin provee eso, y en varios formatos.
4
aplicacin de cdigo libre para realizar diagramas de ujo http://trac.marquesminen.com.ar/cursos/
Cursos de OSS
8.4. PG IO Monitor
83
Esta aplicacin est disponible con algunas distribuciones de Linux, pero si no la encuentra puede ir a http://www.rbt.ca/autodoc/ y bajar la ltima versin disponible. A continuacin se muestra cmo usar el programa para poder obtener un archivo en diversos formatos con todos los datos de la base prueba.
martin@bugs:/home/martin> postgresql_autodoc -d prueba
8.4. PG IO Monitor
pgiomonitor es un pequeo programa escrito en PERL que realiza una cone-
xin a una base de datos, local o remota, devolviendonos informacin al instante de informacin de monitoreo de dicha base. Este script simplemente saca informacin de las tablas pg_statio_* y muestra actividad que hay en la base.
PG IOMonitor prueba IO+Cache Thu Aug 11 20:35:50 2005 Total: 2272 Real: 0 Cache: 2272 Cache Hits: 100% Units: kB/sec Table (T)otal H(e)ap (I)ndex T(o)ast To(a)stIdx -------------------------------------------------------------------------------pg_cast 504 24 480 0 0 pg_opclass 320 288 32 0 0 pg_attribute 308 116 192 0 0 pg_operator 240 60 180 0 0 pg_class 164 84 80 0 0 pg_proc 148 36 112 0 0 pg_amop 124 68 56 0 0 pg_statistic 112 32 80 0 0 pg_index 84 44 40 0 0 pg_type 72 24 48 0 0 pg_amproc 48 16 32 0 0 pg_namespace 36 12 24 0 0 pg_shadow 36 12 24 0 0 pg_rewrite 32 4 8 12 8 pg_trigger 24 8 16 0 0 pg_aggregate 12 4 8 0 0 pg_am 4 4 0 0 0 pg_database 4 4 0 0 0
Para tener en cuenta: pgiomonitor versin 0.3 no se poda conectar a PostgreSQL 8.3 por cambios en la variables de conguracin. Subsanar esto es muy simple y se resume en el siguiente parche:
--- pgiomonitor 2005-04-07 13:10:23.000000000 -0300 +++ pgiomonitor-8.3 2008-04-26 09:38:11.000000000 -0300 @@ -124,7 +124,7 @@ $dbname =~ s/ [[:ascii:]]+//; # Check to see if we have block stats enabled -$blockOn = @{$db->selectcol_arrayref("show stats_block_level")}->[0];
Cursos de OSS
84
+$blockOn = @{$db->selectcol_arrayref("show track_counts")}->[0]; if($blockOn ne "on") { print "ERROR: you need to enable stats_block_level in postgresql.conf\n";
8.5. pgTop: Top de procesos de PostgreSQL

pg_top es una aplicacin parecida al top de Linux (y otros UNIX) que permite monitorear los procesos de PostgreSQL . Este es un ejemplo de pg_top:
last pid: 14172; load avg: 0.16, 0.06, 0.01; up 10+15:49:17 16 processes: 2 running, 14 sleeping CPU states: 16.5% user, 0.0% nice, 11.9% system, 71.6% idle, 0.1% iowait Memory: 1543M used, 475M free, 140M buffers, 519M cached Swap: PID 14166 13545 21891 21877 21272 21382 21274 21997 22012 21870 21376 21290 21289 21301 21377 14173 USERNAME PRI NICE postgres 20 0 postgres 20 0 postgres 20 0 postgres 20 0 postgres 20 0 postgres 20 0 postgres 20 0 postgres 20 0 postgres 20 0 postgres 20 0 postgres 20 0 postgres 20 0 postgres 20 0 postgres 20 0 postgres 20 0 postgres 20 0 SIZE 434M 425M 425M 425M 425M 425M 425M 425M 425M 425M 425M 425M 425M 425M 425M 424M RES 44M 6420K 7380K 7100K 7044K 6996K 7068K 7000K 6924K 6816K 6336K 6176K 6392K 6176K 5620K 4380K STATE run sleep sleep sleep sleep sleep sleep sleep sleep sleep sleep sleep sleep sleep sleep run TIME 0:02 0:08 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00 10:38:38
WCPU CPU COMMAND 4.26% 50.75% postgres: biblioteca siprebi 127.0.0. 0.31% 0.40% postgres: biblioteca siprebi 127.0.0. 0.00% 0.00% postgres: sigesbi trac-sigesbi 127.0. 0.00% 0.00% postgres: sigesbi trac-sigesbi 127.0. 0.00% 0.00% postgres: sigesbi trac-sigesbi 127.0. 0.00% 0.00% postgres: sigesbi trac-sigesbi 127.0. 0.00% 0.00% postgres: sigesbi trac-sigesbi 127.0. 0.00% 0.00% postgres: sigesbi trac-sigesbi 127.0. 0.00% 0.00% postgres: sigesbi trac-sigesbi 127.0. 0.00% 0.00% postgres: sigesbi trac-sigesbi 127.0. 0.00% 0.00% postgres: sgsu trac-sgsu 127.0.0.1(58 0.00% 0.00% postgres: sgsu trac-sgsu 127.0.0.1(39 0.00% 0.00% postgres: sgsu trac-sgsu 127.0.0.1(39 0.00% 0.00% postgres: sgsu trac-sgsu 127.0.0.1(51 0.00% 0.00% postgres: sgsu trac-sgsu 127.0.0.1(58 0.00% 0.00% postgres: postgres postgres [local] i
8.6.
pgFouine: Analizador de Logs
pgFouine es una analizador de logs de PostgreSQL . Genera reportes en texto o en HTML de los logs de PostgreSQL . pgFouine est escrito en PHP, y permite, poniendo valores adecuados al parmetro log_min_duration_statement y log_duration (se vi esto en la seccin 3.10.3), hacer anlisis de consultas
lentas. La contra de esta aplicacin es que requiere que los logs se escriban de manera especial para poder analizarlo, lo que no siempre es cmodo. Si esto no es inconveniente, pgFouine es de gran ayuda. Usando PostgreSQL 8.3 con las siguientes opciones:
log_destination = syslog redirect_stderr = off silent_mode = on
Cursos de OSS
8.6. pgFouine: Analizador de Logs
85
Luego hay que setear adecuadamente syslog para indicarle que los logs de PostgreSQL vayan a parar al archivo adecuado. Otro inconveniente con el que nos podemos topar es el hecho que nuestros registros estn en castellano, y pgFouine no los va a poder interpretar correctamente (directamente los va a ignorar a todos). Para ello debemos poner la opcin lc_messages a algun valor en ingls, por ejemplo en_US. Adems de poder analizar logs de PostgreSQL , tambin puede analizar, usando un otro script que viene, salidas de VACUUM VERBOSE.
Cursos de OSS

PGSQL

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

PGSQL

Caricato da

Copyright:

Formati disponibili

Curso de Bases de Datos relacionales usando PostgreSQL en entornos Linux

Lic. Martn A. Marqus <martin.marques@gmail.com>

Derechos de Autor c 2007-2008 Martn A. Marqus. Todos los derechos reservados.

Captulo 1 Introduccin de PostgreSQL

1.2. Caractersticas del sistema

1.2. Caractersticas del sistema

Captulo 1. Introduccin de PostgreSQL

Captulo 2 Instalacin de PostgreSQL

Captulo 2. Instalacin de PostgreSQL

2.1. Instalacin de fuentes

2.1. Instalacin de fuentes

Captulo 2. Instalacin de PostgreSQL

2.1. Instalacin de fuentes

2.1.2. Compilacin e instalacin

Captulo 2. Instalacin de PostgreSQL

2.2. Instalacin usando binarios empaquetados

2.2. Instalacin usando binarios empaquetados

Yellow Dog es una dsitribucion basada en rpm

Captulo 2. Instalacin de PostgreSQL

2.3. Inicializacin del motor de la base de datos

2.3. Inicializacin del motor de la base de datos

ciones para pasar determiandos parmetros.

Captulo 2. Instalacin de PostgreSQL

seccin 4.6 para informacin sobre actualizacin entre versiones).

Levantando el servicio de Bases de Datos

start stop restart reload status kill

2.4. Levantando el servicio de Bases de Datos

Captulo 2. Instalacin de PostgreSQL

3.1. Conguracin general del servidor

3.2. Conguracin de los parmetros de conexin

3.2. Conguracin de los parmetros de conexin

programa que ejecuta el motor de las Bases de Datos

3.4. Usos de memoria

3.5. Mapa de espacio libre

3.5. Mapa de espacio libre

(tablas e ndices) para las cuales se mantendr un registro de espacio libre

3.6.1. Conguracin de WAL

3.6.2. Puntos de control de WAL

entre puntos de control. Al igual que en el parmetro anterior, incrementar

3.7. Constantes de costo del planicador

3.8. Otras opciones del planicador

effective_cache_size (punto otante): Especica el valor que el plani-

3.8. Otras opciones del planicador

Opciones de limpieza y recoleccin de estadstica: autovacuum

Este parmetro slo puede ser seteado cuando arranca el servidor.

3.10. Conguracin de registros de PostgreSQL

autovacuum_analyze_threshold (entero): Especica el umbral de tuplas

3.10. Conguracin de registros de PostgreSQL

Salida estandard de error de Sistemas Operativos UNIX

3.10.2. Cundo escribir registros

3.10. Conguracin de registros de PostgreSQL

Qu datos escribir en los registros

debug_print_parse (booleano) debug_print_rewritten (booleano) debug_print_plan (booleano) debug_pretty_print (booleano)

3.11.1. Monitoreo de estadsticas

3.11.2. Recolector de estadsticas de consultas e ndices

Valores predeterminados para conexiones de clientes

3.12.1. Formato y localizacin

4.1.1. Conguracin del archivo pg_hba.conf

[auth-op] [auth-op] [auth-op]

4.1. Congurando accesos a la Base de Datos

ciertas mquinas de un grupo.

la red. No es recomendable usar en redes que no tengan la debida seguridad.

tema operativo. Un ejemplo de registro de pg_hba.conf puede ser el siguiente: