Planeta PostgreSQL-es

Con la versión 9.1 de PostgreSQL tenemos disponible una nueva funcionalidad llamada SQL/MED mediante la cual se puede acceder a datos externos a nuestra base de datos mediante comandos SQL.

En SQL/MED existen los llamados "Foreign Data Wrapper (FDW)" que es una especie de "driver" para acceder a un tipo de datos externos. Existen diferentes tipos y con la versión 9.1 existe uno en los modulos contrib que se llama file_fdw. Este FDW se puede utilizar para acceder ficheros en formato CSV.

leer más

Introducción
Hace unos días una persona me dejó una duda a modo de comentario en la entrada de DBLinks en PostgreSQL. Esta duda es sencilla, y, a la vez interesante, por eso, he decidido crear una entrada explicando la solución.

La duda
¿Es posible crear una vista en PostgreSQL utilizando un DBLink con parámetros dinámicamente?

Es decir, lo que queremos es hacer los siguiente:

SELECT device_name FROM remote_database_v(param1, param2);

La solución
Sobre si es posible crear una Vista con un DBLink parametrizado, lo cierto es que no se puede, es decir, no podemos crear una vista pasando un argumento.

Sin embargo, podemos crear un procedimiento que nos devuelva un tipo "record" y pasarle como parámetros la cadena de conexión, por ejemplo:

CREATE OR REPLACE FUNCTION test_dblink_with_parameter(dbname character varying, dbhost character varying, dbuser character varying, dbuserpass character varying)
  RETURNS SETOF record AS
$BODY$
    SELECT t.device_name
    FROM dblink('dbname=' || $1 || '  port=5432 host=' || $2 || ' user=' || $3 ||' password=' || $4 , 'SELECT device_name FROM devices.as_device') as
     t(device_name character varying);
$BODY$
  LANGUAGE sql VOLATILE;

Y ahora podemos llamar a nuestro procedimiento como si fuese una tabla o vista.

Recordar que al ser de tipo "record" tenemos que decirle cómo es el formato del registro <AS (field1 type, field2 type, fieldn type)>, en nuestor caso devuelve el campo "as_device" que es de type "character varying".

SELECT * FROM test_dblink_with_parameter('dbname','localhost','user','password') AS (device_name character varying);

Algunas Mejoras
En función de los datos que estamos obteniendo, podemos, por ejemplo, optimizar el coste <COST> y el número de rows <ROWS> del procedimiento. En el ejemplo, hemos dejado el coste y el número de rows "por defecto",  COST 100 y  ROWS 100.

Referencias

• Instalación de PostgreSQL 9.0 en OpenIndiana
• Instalación de PostgreSQL en Solaris 10
• Copias de Seguridad en PostgreSQL 
• PostgreSQL 9.0.3 x86 64bit para OpenIndiana con UUID
• Instalación de OSSP UUID en OpenIndiana

Esta mañana leyendo los mensajes de Twitter que me llegaron por la noche, me encontre con uno que me llamó la atención, "Steward Smith blogs on Optimazing InnoDB for creating 30.000 tables (and nothing else)".

Empece a leerlo y estuvo entretenido. Trataba de lo que se podia hacer para acelerar la creación de muchos objetos en MySQL usando InnoDB, esto es especialmente importante cuando se vaya a importar una nueva base de datos que sea grande.

leer más

El proyecto PostgreSQL ha lanzado nuevas versiones menores de todas las series activas de PostgreSQL. Las nuevas versiones disponibles son 9.1.2, 9.0.6, 8.4.10, 8.3.17 y 8.2.23. Recordamos que la serie 8.2 no se actualizará más y la versión 8.2.23 es la última versión de esta serie.

Anuncio oficial de este lanzamiento:
http://www.postgresql.org/about/news/1366/

Más información sobre las versiones lanzadas:
http://www.postgresql.org/docs/current/static/release.html

Descargas:
http://www.postgresql.org/download/

Código fuente:
http://www.postgresql.org/ftp/source/

leer más

Cuando ví el Episodio IV de la Guerra de las Galaxias ("El Imperio Contraataca"), aún era un niño impresionable, y me llamó la atención la reprenda que hizo Yoda a Luke y que cito aquí. Era uno de ésos consejos marciales que se enuncian solemnes como un consejo vital.

Con el tiempo te das cuenta que como consejo está bien, y puede ser incluso un buen objetivo... pero en ciertas facetas de la vida no es válido. Por ejemplo, en el mundo científico y en nuestro mundo profesional el consejo es justamente el contrario: inténtalo, pruébalo y compruébalo. Y sólo cuando lo hayas hecho y consigas un resultado repetible, ponlo en práctica, esto es, súbelo a producción.

Gracias a no seguir el consejo de Yoda fui consciente de una (grave) carencia de PostgreSQL con respecto a los niveles de aislamiento. Como ya hice una introducción al aislamiento en otro artículo, no voy a extenderme más en el tema y voy al grano. El caso que me ocupaba es que tenía que hacer una importación transaccional de datos masiva en un sistema en OLTP de producción en el que se están modificando constantemente datos relacionados con los que voy a importar. El resultado de la importación es que la transacción gigante bloquea datos e impide que se efectúen modificaciones en datos relacionados paralizando en la práctica buena parte de las operaciones de producción produciéndose un efecto "bola de nieve" al sumarse cada vez más transacciones en cola a la transacción gigante pendiente. Sin embargo, para lo único que quiero la transacción es para tener atomicidad en la operación, es decir, para que no se quede a medias en caso de algún problema, pero no me importa que se puedan producir eventualmente casos de dirty read, que no afectarían a los usuarios del sistema de producción en su trabajo. Vale, no hay problema. La transacción de inserción la podemos realizar con el nivel de aislamiento más bajo (READ_UNCOMMITED) y problema solucionado. ¿No? No obstante, no hagamos caso a Yoda, y probémoslo en pre-producción. Resultado: exactamente el mismo que si no hubiera especificado nada del nivel de aislamiento.

¿Qué ha pasado?

En la documentación de SET TRANSACTION, en efecto compruebo que PostgreSQL admite los cuatro niveles de aislamiento como la mayoría de las bases de datos (de hecho, la sentencia no dio error)... pero sólo sintácticamente: no están todos implementados. Si contiúas leyendo te das cuenta que no son 4, sino 2 los niveles implementados:

"The SQL standard defines two additional levels, READ UNCOMMITTED and REPEATABLE READ. In PostgreSQL READ UNCOMMITTED is treated as READ COMMITTED, while REPEATABLE READ is treated as SERIALIZABLE."

Lo que viene a decir: "¿Pensabas que eran cuatro, no? Pues no. Son dos". De hecho, ahora (con la versión 9.1) ya son 3. Pero sigue sin estar soportada la lectura sucia (dirty read). En la documentación sobre aislamiento también es bastante claro:

"In PostgreSQL, you can request any of the four standard transaction isolation levels. But internally, there are only two distinct isolation levels, which correspond to the levels Read Committed and Serializable. When you select the level Read Uncommitted you really get Read Committed, and when you select Repeatable Read you really get Serializable, so the actual isolation level might be stricter than what you select."

Un verdadero jarro de agua a mis pretensiones, ya que no puedo conseguir atomicidad sin bloqueo (aunque sea realizando lecturas de transacciones no confirmadas) en PostgreSQL, al menos con la versión actual 9.1.


Referencias y más información:

• Transaction Isolation (Documentación de PostgreSQL 9.0) (2 Niveles)
• SET TRANSACTION (Documentación de PostgreSQL 9.0) (2 Niveles)
• Transaction Isolation (Documentación de PostgreSQL 9.1) (3 Niveles)
  
• SET TRANSACTION (Documentación de PostgreSQL 9.1) (3 Niveles)

El modelo EAV
El modelo Entidad-Atributo-Valor (EAV, Entity-Attribute-Value), también conocido como Objeto-Atributo-Valor o Esquema Abierto, se usa en casos donde el número de atributos (propiedades, parámetros) usados para describir una entidad u objeto es potencialmente grande, pero que aplicados individualmente a una entidad concreta es pequeño. Las circunstancias donde se suelen aplicar son:

• Entidades con atributos heterogéneos:
  
• Entidades dinámicas en el tiempo, donde los atributos de una entidad son fijos, pero durante un período de tiempo variable. Es decir, son cambiantes (pueden crecer o decrecer) en el tiempo.
• Entidades conceptualmente dinámicas, dependiendo de la interpretación del sistema en un determinado momento. Es decir, entidades cuyo número de atributos cambia según el contexto (p.e.: atributos definidos por el usuario)
• Entidades con atributos homogéneos muy poco densos. Es decir, entidades con una desproporción muy grande entre el número de atributos posibles y el número de atributos con valor (no nulos).

Entidades en escenarios típicos de este tipo de modelos son, por ejemplo:

• documentos (en una base de datos documental) cuyos atributos asignados a cada documento depende de la empresa, departamento, tipo de documento, etc...
• información cuya catalogación adicional depende de parámetros definidos por el usuario
• conceptos de negocio o abstractos cuyos atributos dependen de varios factores y varían en el tiempo: "expediente", "valoración", "indicencia", etc...

Este modelo se suele resolver sobre el modelo relacional con tres tablas: la de entidad, la de atributos posibles de dicha entidad y la de valores. La información se registra conceptualmente en la tabla de valores, que relaciona la información a través de tres columnas: clave ajena de entidad, clave ajena de atributo y valor.

Incidencia Id Fecha 1 17/05/1922:10 2 18/05/1910:13 3 18/05/1917:05

Datos Id NombreAtributo 1 Longitud 2 Temperatura 3 Volumen 4 Sector

DatosIncidencia IdInc IdDato Valor 1 1 5 1 4 A 2 2 6 2 3 4 2 4 A

Los problemas que aporta este modelo son:

• Consultas SQL complejas (muchos "CASE"), que en algunos casos deben usar herramientas típicas de datawarehouse (PIVOT, crosstab, etc), para convertir en columnas lo que, en realidad, son filas.
• Tipo de dato único para todos los atributos, sean numéricos, fechas o cadenas, que luego deberán convertirse, o complicar el modelo con distintas tablas de atributos en función del tipo de dato.

XML y Xpath al rescate
Una buena alternativa a este tipo de problemas es implementar un campo con XML y procesarlo con herramientas XPath. Lamentablemente, el tipo de dato XML de PostgreSQL 8.3 aún no tiene operadores de comparación ni se pueden crear índices sobre este tipo de dato, pero se puede tratar como String y indexar expresiones XPath como veremos a continuación.

La ventaja de usar XML es que podemos contar con un número de atributos variable encapsulados en un documento XML en un sólo campo y evitar tener que usar el modelo EAV, por ejemplo: 

Incidencia
Id	Fecha	DatosIncidencia
1	17/05/19 22:10	<data><longitud>5</longitud><sector>A</sector></data>
2	18/05/19 10:13	<data><temperatura>5</temperatura><volumen>4</volumen><sector>A</sector></data>

 
Con una tabla como la anterior, podemos realizar consultas sencillas con XPath, tipo

SELECT xpath('/data/temperatura/text()', DatosIncidencia)
FROM incidencia

que nos permite un control total en la consulta de atributos sin complicadas consultas. Puede haber quien le parezca que XPath es complicado y que no se gana tanto, pero en mi opinión, es más sencillo tratar con un único campo y una única tabla aunque tengamos que realizar un pequeño aprendizaje de XPath. A la larga, todo es más simple: tanto las consultas como el mantenimiento.

También se pueden optimizar ciertas consultas comunes creando índices, aunque usando algún truco.

El soporte de XML "de serie" en PostgreSQL no ha hecho más que empezar, y le queda un gran camino por recorrer, pero ya estamos en disposición de empezar a aprovecharlo.


Referencias y más información:

• XML con PostgreSQL

Acabo de publicar un artículo sobre como PostgreSQL graba y organiza nuestros datos en el disco. Una introducción a un tema que todo administrador de bases de datos deberia saber algo sobre el mismo.

El artículo se titula "¿Dónde están nuestros datos en el disco?" y está disponible en http://www.postgresql.org.es/node/667

--
Rafael Martinez Guerrero
PostgreSQL-es

El proyecto PostgreSQL ha lanzado nuevas versiones menores de todas las series activas de PostgreSQL. Las nuevas versiones disponibles son 9.1.1, 9.0.5, 8.4.9, 8.3.16 y 8.2.22. Recordamos que la serie 8.2 dejará de actualizarse a partir de noviembre 2011.

Anuncio oficial de este lanzamiento:
http://www.postgresql.org/about/news.1355

Más información sobre las versiones lanzadas:
http://www.postgresql.org/docs/current/static/release.html

Descargas:
http://www.postgresql.org/download/

Código fuente:
http://www.postgresql.org/ftp/source/

Instalador fácil:

leer más

Introducción
Alguna vez hemos necesitado clonar una tabla, tanto estructura como contenido desde el propio SQL sin tener que recurrir a <pg_dump>.
Tal vez alguno esté pensando en un CREATE TABLE AS SELECT ... pero lo cierto es que esta solución no nos crea los modificadores, índices, etc.

Sin embargo, no os preocupéis, que en PostgreSQL se puede hacer todo, o casi, y este caso sí que está muy resuelto.

Pasos Ejemplo de Clonado "completo"
A continuación os muestro -de una forma sencilla- lo que vamos a hacer, paso a paso para que no resulte complicado:

1. Crearemos una tabla llamada test con los campos company y homepage
2. Añadiremos un índice único en company
3. Añadiremos un par de compañías
4. Crearemos una tabla nueva copiando el contenido de la tabla con un CREATE TABLE  AS SELECT para comprobar cómo no clona los índices, defaults, etc.
5. Utilizaremos un clonado completo

Una vez explicado, vamos a ponernos manos a la obra

search=> CREATE TABLE test(company VARCHAR(20) NOT NULL, homepage VARCHAR(40) NOT NULL);
CREATE TABLE
search=> CREATE UNIQUE INDEX test_company_uq ON test(company);
CREATE INDEX
search=> \d test
             Table "public.test"
  Column  |         Type          | Modifiers
----------+-----------------------+-----------
 company  | character varying(20) | not null
 homepage | character varying(40) | not null
Indexes:
    "test_company_uq" UNIQUE, btree (company)

Ahora, añadimos un par de registros

search=> INSERT INTO test(company,homepage) VALUES('SFChildren', 'http://www.sfchildren.com');
INSERT 0 1
search=> INSERT INTO test(company,homepage) VALUES('HavocTec', 'http://www.havoctec.com');
INSERT 0 1
search=> SELECT * FROM test;
  company   |         homepage         
------------+---------------------------
 SFChildren | http://www.sfchildren.com
 HavocTec   | http://www.havoctec.com
(2 rows)

Copiamos su contenido utilizando CREATE TABLE newTable AS SELECT * FROM sourceTable y comprobaremos su resultado

search=> CREATE TABLE test2 AS SELECT * FROM test;
SELECT
search=> \d test2
             Table "public.test2"
  Column  |         Type          | Modifiers
----------+-----------------------+-----------
 company  | character varying(20) |
 homepage | character varying(40) |

Como podemos observar, lo primero que nos falta es el índice que hemos creado <test_company_uq> y los modificadores <NOT NULL> en ambos campos.

Es decir, utilizando esta forma copiamos el contenido y estructura de campos pero no sus modificadores, pero, que no cunda el pánico, vamos a ver cómo lo podemos hacer de una forma sencilla.

Borramos la tabla test2 que hemos creado para poder volver a clonarla, esta vez de forma completa.

search=> DROP TABLE test2;
DROP TABLE

Clonar "todo", para ello vamos a utilizar los modificadores LIKE tabla INCLUIDING [DEFAULTS | CONSTRAINTS | INDEXES]. En nuestro ejemplo, queremos "clonar" toda la estructura  así que utilizamos todas.

search=> CREATE TABLE test2 (LIKE test INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES);
CREATE TABLE
search=> \d test2
             Table "public.test2"
  Column  |         Type          | Modifiers
----------+-----------------------+-----------
 company  | character varying(20) | not null
 homepage | character varying(40) | not null
Indexes:
    "test2_company_key" UNIQUE, btree (company)

Conclusiones
Aunque el ejemplo es sencillo, la idea era mostrar la potencia de la opción LIKE ... INCLUIDING sin tener que mostrar una estructura muy compleja.

Además, para aquellos que no os guste el SQL, siempre podéis utilizar el comando <pg_dump> para exportar una tabla.


Referencias

• Copias de Seguridad en PostgreSQL - Parte 1
• Instalación de PostgreSQL en OpenIndiana - Parte 1

Por primera vez en Ecuador se realizará un PGDay. ¿Pero que es un PGDay y por qué deberíamos hacer uno?

leer más

12 de Septiembre del 2011: El Grupo Global de Desarrollo de PostgreSQL anuncia el lanzamiento de PostgreSQL 9.1. Esta nueva versión de la bases de datos de código abierto líder ofrece tecnología innovadora, extensibilidad sin igual, y nuevas características como replicación sincrónica, método de indexado "K-Nearest Neighbor", and conectores de datos foráneos.

leer más

Hoy se lanza una nueva versión principal de PostgreSQL, la versión 9.1. Después de un año de desarrollo y pruebas, este lanzamiento trae muchas características nuevas y potentes.

A continuación teneis un resumen de la nota de prensa oficial. El documento completo lo teneis en http://www.postgresql.org/about/press/presskit91.html.es

leer más

En Mayo de este año se lanzo la edición # 00 de pgmag que es la primera revista exclusivamente sobre PostgreSQL.
En realidad eso fue solo una prueba, que al parecer ha sido exitosa con mas de 4000 descargas de la página y se ha repartido en varios eventos.

Ha decir verdad, pensaba anunciarla por aqui pero esperaba a que se terminará la traducción al español que aparentemente no termino

leer más

¿Con qué frecuencia se le ha pedido a alguno de ustedes que se registren todos los cambios de las tablas para auditoria? AFAIR, todos y cada uno de los clientes que he tenido me ha pedido esto

Hasta ahora, he usado table_log (http://pgfoundry.org/projects/tablelog) para eso, pero eso esta lejos de ser una solución ideal por varias razones.

leer más

Como comente en el artículo anterior de este blog, el 11 y 12 de Julio se realizó la conferencia CHAR(11). Y al igual que el lunes 11, el programa del martes 12 fue impresionante. Así que aprovechare el viaje en tren a Londres para comentarles un poco lo que pasó.

leer más

El día de ayer, 11 de Julio, dio inicio a la conferencia denominada CHAR(11) (un interesante uso de siglas para Clustering, High Availability and Replication).

leer más

Como saben estamos en etapa beta de PostgreSQL 9.1, así que estoy empezando a chequear algunas de las nuevas características. Y como es natural, debido a que 2ndQuadrant es quien la auspicio, empece con "replicación sincrónica".

leer más

El primer beta de PostgreSQL 9.1 ha sido liberado, el anuncio oficial esta aqui: http://www.postgresql.org/about/news.1313

Esta versión trae algunas adiciones mayores a PostgreSQL, he aqui algunas de las mas esperadas:
* Synchronous Replication
* Per-column collations for multilingual databases
* Unlogged Tables
* K-Nearest-Neighbor Indexing
* Serializable Snapshot Isolation

leer más

Herramientas de modelado de datos gratuitas (para PostgreSQL)

Las herramientas de modelado de datos son muy útiles a la hora de realizar un diseño de datos nuevo o acercarnos a la comprensión y estudio de un modelo existente (en aquellas con características de ingeniería inversa). La capacidad de realizar un diseño de modelo visualizándolo de forma gráfica, a través de los Diagramas E-R, o de obtener un diagrama y documentación de una base de datos existente aumenta enormemente la eficiencia de nuestro trabajo reduciendo drásticamente el tiempo necesario con respecto a una realización manual de dichas tareas de diseño, análisis y estudio.

La mejor y más completa herramienta de modelado que conozco es PowerDesigner^©. No es objeto de este artículo describir la enorme cantidad de características que tiene, ni lo perfectamente resuelto que están en ella las tareas de modelado e ingeniería directa e inversa, pero te aseguro que es casi perfecta, contemplando todo el ciclo de modelado (lógico y físico, con multitud de bases de datos) de datos, además de otras tareas de modelado como el de objetos (con generación de código), esquemas xml, etc...

PowerDesigner tiene, empero, un (grave) inconveniente: sólo está disponible para Windows, y en Sybase/SAP no se han preocupado (al contrario que otras compañías, como por ejemplo Spotify) de que pueda ejecutarse con Wine perfectamente.

Vale. Así que tenemos Linux (por ejemplo) y no podemos ejecutar PowerDesigner pero necesitamos una herramienta que nos ayude en nuestro trabajo. ¿Qué alternativas hay?. He buscado en internet "herramientas de modelado de datos", "data modelling tools", "PowerDesigner alternatives"... con resultados decepcionantes: apenas listas de herramientas poco comentadas o algún comentario en foros... Así que me puse manos a la obra a buscar por mi cuenta y compartirlo con la comunidad.

Lo primero que hay que tener en cuenta es que no existe ninguna herramienta gratuita alternativa comparable a PowerDesigner, ni por calidad ni cantidad de características. Pero existen herramientas bastante decentes (para ser gratuitas) que nos pueden servir para la mayor parte de nuestras necesidades. De hecho, hay una lista publicada con una cantidad enorme de herramientas diferentes de modelado que me llevaría muchos días probar. Así que, como en otras ocasiones, fijé una serie de características y condicionantes necesarios para mi, con lo que el número de herramientas candidatas se redujo considerablemente. Mi lista de características y condiciones ha sido la siguiente:

• Debe estar disponible para Linux, como mínimo.
• Debe tener características de modelado de datos (no basta con una herramienta de diagramas o que sea sólo para UML)
• Debe tener características de ingeniería directa e inversa.
• Debe soportar (para la ingeniería directa e inversa) como mínimo, PostgreSQL. Adicionalmente se valorará otras bases de datos como MySQL, Oracle, SQL Server, DB2, Derby, etc...
• Debe tener características de documentación: generar diagramas E-R, y documentación de la base de datos.
• Por supuesto, debe ser gratuita y, preferentemente, libre.

A continuación, os detallo las herramientas analizadas

Open System Architect 4.0.0

Es Open Source. Frecuencia de actualización: desconocida.
De todas las herramientas, analizadas es la que más se parece (dicho esto con todas las cautelas y salvando mucho, mucho las diferencias) a PowerDesigner, y es la que más características y posibilidades incorpora. Por ejemplo, es la única de las analizadas que integra el modelado lógico. Tiene la mejor organización de proyectos y menús y es rápida. Me han gustado muchos aspectos que aparentemente la podrían convertir en la más completa...sin embargo, también es la que más me ha decepcionado en el resultado final. El acceso a las bases de datos es vía ODBC (es la única de las analizadas que no está hecha en Java), lo cual me ha resultado un poco arcaico y engorroso de configurar, aunque al final ese no ha sido el inconveniente, sino la falta de acabados finales que hacían perder la lucidez de las funcionalidades:

• Diagramas
• los diagramas generados son feos (si bien este inconveniente es generalizado en todas las herramientas analizadas)
• faltan opciones de presentación gráficas, de reordenado y de diseño de las tablas y sus relaciones
• Ingeniería inversa:
• La importación de tablas no es cómoda y no se sabe muy bien de qué esquemas estás importando. No puedes agregar tablas referenciadas relacionadas (hijas) o que la relacionen (padres) automáticamente.
• Documentación:
• No encontré las características de documentación mínimas que buscaba.

En definitiva, debería ser la mejor... pero al final no me ha gustado. Es como si te montas en un Mercedes, que hace ruido, no tiene aire acondicionado y la dirección y el cambio son muy duros. No me ha resultado cómoda y no la voy a usar. Estaré atento a futuras versiones si es que se producen.

SQL Power Architect 1.0.6

Aunque es un producto comercial, la versión community es Open Source y gratuíta.Frecuencia de actualización: alta.

La versión community gratuita es suficiente para un trabajo de modelado básico. Soporta ingeniería directa e  inversa de forma cómoda (se pueden agregar fácilmente las tablas hijas) con bastantes opciones gráficas de presentación. Es rápido, amigable y con él se puede generar una documentación mínima decente. De todos los analizados es el que menos opciones de modelado y documentación tiene, aunque cumple su cometido muy dignamente.

SQuirreL SQL 3.2.1

Open Source. Alta actualización. Esta herramienta es en realidad un cliente SQL multi-bases-de-datos (bastante bueno, la verdad) con capacidades de modelado e ingeniería directa e inversa.

SQuirrel no destaca por sus capacidades gráficas de diagramas E-R. La organización de las tablas en una importación vía ingeniería inversa deja bastante que desear (como se puede observar) aunque salvando el detalle de tener que organizar y posicionar las tablas a mano, tenemos suficientes opciones para añadir tablas referenciadas o elegir la presentación de las tablas. Sin embargo, como he comentado, SQuirrel es un cliente multipropósito y multibase bastante completo, con muchos plugins y potentes editores de datos, SQL, DML y esquemas. Este es probablemente el más completo multi-propósito de todos los analizados.

Druid III (3.11)

Open Source. Frecuencia actualización: Alta

Druid es fundamentalmente una herramienta pensada para crear bases de datos de forma gráfica y documentarlas. Su capacidad de documentación de bases de datos supera a todas las del análisis: es capaz de generar documentación tipo javadoc de una base de datos con los diagramas E-R y sus tablas de forma detallada, como se puede comprobar en la siguiente ilustración.

La interfaz es un poco "extraña" (por llamarla de alguna manera) y muy poco intuitiva (probablemente la peor interfaz de todas). Sin embargo, si quieres documentar una base de datos, ésta es tu heramienta. Permite documentar una base de datos existente vía ingeniería inversa, realizando diagramas temáticos y realizando documentación adicional, de forma muy sencilla, añadiendo tablas relacionadas, y presentando la información que deseemos. En todo caso, a pesar de que le faltan opciones gráficas de zooming y layout y de tener una interfaz difícil, para documentar una base de datos vía ingeniería inversa, es la que más me ha gustado.

Resumen:

• Todos tienen carencias en la presentación de los diagramas E-R: faltan opciones de "layout" y los diagramas son poco vistosos.
• Todos son multiplataforma (todos salvo Open Systems Architect están hechos en Java).
• Todas las herramientas son válidas. Y deberías probarlas todas. Ahora bien, cada una tiene un punto fuerte
• Documentación: Druid
• Algo para empezar, sencillo: SQL Power Architect.
• Cliente completo, todo en uno: SQuirrel
• OSA no me ha gustado, a pesar de ser la única que incorpora modelado lógico de forma explícita.

Todo esto, como siempre, es cuestión de gustos y de necesidades concretas. Así que, como en otras ocasiones, recomiendo probar y sacar conclusiones... y si las compartes conmigo comentando, te lo agradezco.

¿Conoces alguna otra herramienta que cumpla las condiciones iniciales?

Referencias y más información:

• Modelling tools
• PostgreSQL GUI Tools
• SQL Power Architect
• SQuirrel SQL
• Druid
• Open Systems Architect

El proyecto PostgreSQL ha lanzado nuevas versiones menores de todas las series activas de PostgreSQL. Las nuevas versiones disponibles son 9.0.4, 8.4.8, 8.3.15 y 8.2.21.

Como ya avisamos la semana pasada, esta actualización corrige entre otras cosas, un fallo grave en pg_upgrade y se recomienda a todos los usuarios actualizar a las nuevas versiones tan pronto como sea posible. No olvidar leer el procedimiento a seguir con esta actualización.

Más información sobre el fallo de pg_upgrade se puede encontrar en:
http://www.postgresql.org.es/node/607

leer más

Hace unos dias escribi una entrada sobre como generar un gráfico de las llaves foráneas de una base de datos. El método utilizado fue escribir una consulta SQL que utilizando datos contenidos en el esquema information_schema generase una salida que se pudiese utilizar con Graphviz para generar un gráfico.

leer más

Este artículo se describe la instalación de PostgreSQL 9 en CentOS.
PostgreSQL 9 es el primer gran lanzamiento de PostgreSQL desde hace buen tiempo y la estructura de archivos ha cambiado un poco.

Si usted está usando Webmin, también le mostrare cómo configurar Webmin para administrar PostgreSQL 9.

Hay una versión 9.1.1 alpha disponible, pero hoy vamos a instalar 9.0.2 Para CentOS y voy a necesitar:

http://yum.pgrpms.org/reporpms/9.0/pgdg-centos-9.0-2.noarch.rpm

Asi que desde la consola terminal escriba lo siguiente para descargar el RPM.

[root@superahacker ~]
# wget http://yum.pgrpms.org/reporpms/9.0/pgdg-centos-9.0-2.noarch.rpm
--2010-10-29 15:38:15--  http://yum.pgrpms.org/reporpms/9.0/pgdg-centos-9.0-2.noarch.rpm
Resolving yum.pgrpms.org... 77.79.103.58
Connecting to yum.pgrpms.org|77.79.103.58|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4623 (4.5K) [application/x-rpm]
Saving to: `pgdg-centos-9.0-2.noarch.rpm'

100%[=================================>] 4,623       --.-K/s   in 0s

2010-10-29 15:38:15 (259 MB/s) - `pgdg-centos-9.0-2.noarch.rpm' saved [4623/4623]

Completa la descarga es momento de instalar el RPM.

[root@superahacker ~]# rpm -ivh pgdg-centos-9.0-2.noarch.rpm

Ahora es necesario editar nuestra configuración de repositorios e indicarle que excluya o ignore el paquete Postgres para los repositorios [base] y [updates]

[root@superahacker ~]# vim /etc/yum.repos.d/CentOS-Base.repo

Agregaremos exclude=postgresql* para [base] y [updates].

[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
exclude=postgresql*

#released updates
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?
release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
exclude=postgresql* 

Ahora instalaremos con YUM, PostgreSQL y sus dependencias.

[root@superahacker ~]# yum -y install postgresql90*
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * addons: mirror.ash.fastserv.com
 * base: yum.singlehop.com
 * extras: mirrors.netdna.com
 * updates: mirror.cogentco.com
Excluding Packages from CentOS-5 - Base
Finished
Excluding Packages from CentOS-5 - Updates
Finished
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package postgresql90-server.x86_64 0:9.0.1-1PGDG.rhel5 set to be updated
--> Processing Dependency: postgresql90 = 9.0.1-1PGDG.rhel5 for package: postgresql90-server
--> Running transaction check
---> Package postgresql90.x86_64 0:9.0.1-1PGDG.rhel5 set to be updated
---> Package postgresql90-libs.x86_64 0:9.0.1-1PGDG.rhel5 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package                  Arch        Version                 Repository   Size
================================================================================
Installing:
 postgresql90-server      x86_64      9.0.1-1PGDG.rhel5       pgdg90      4.6 M
Installing for dependencies:
 postgresql90             x86_64      9.0.1-1PGDG.rhel5       pgdg90      1.3 M
 postgresql90-libs        x86_64      9.0.1-1PGDG.rhel5       pgdg90      209 k

Transaction Summary
================================================================================
Install      3 Package(s)
Update       0 Package(s)
Remove       0 Package(s)

Total download size: 6.5 M
Is this ok [y/N]: y
Downloading Packages:
(1/3): postgresql90-libs-9.0.1-1PGDG.rhel5.x86_64.rpm    | 209 kB     00:01
(2/3): postgresql90-9.0.1-1PGDG.rhel5.x86_64.rpm         | 1.3 MB     00:02
(3/3): postgresql90-server-9.0.1-1PGDG.rhel5.x86_64.rpm  | 4.6 MB     00:07
--------------------------------------------------------------------------------
Total                                           535 kB/s | 5.9 MB     00:10
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing     : postgresql90-libs                                        1/4
  Installing     : libxslt                                                  2/4
  Installing     : postgresql90                                             3/4
  Installing     : postgresql90-server                                      4/4

Installed:
  postgresql90-server.x86_64 0:9.0.1-1PGDG.rhel5

Dependency Installed:  
  postgresql90.x86_64 0:9.0.1-1PGDG.rhel5
  postgresql90-libs.x86_64 0:9.0.1-1PGDG.rhel5

Complete!

Definimos y generamos el directorio de datos (PGDATA) de PostgreSQL.

[root@superahacker ~]# service postgresql-9.0 initdb

Registramos PostreSQL para que carge con el arranque del sistema.

[root@superahacker ~]# chkconfig postgresql-9.0 on 

Iniciamos el servicio postgreSQL.

[root@superahacker ~]# service postgresql-9.0 start 

Si necesita ingresar a la consola PGSQL lo puede hacer con el siguiente comando.

[root@superahacker ~]# su - postgres -c 'psql'

Configuración de Webmin

Para que Webmin pueda trabajar con PostgreSQL 9 necesitamos hacer unos cambios en la configuración del modulo de [Postgres Database Server] en Webmin.



1. Path to psql command:

Original:

/usr/bin/psql

Cambiar por:

/usr/pgsql-9.0/bin/psql

2. Command to start PostgreSQL

Original:

if [ -r /etc/rc.d/init.d/rhdb ]; then /etc/rc.d/init.d/rhdb start; else /etc/rc.d/init.d/postgresql start; fi

Cambiar por:

if [ -r /etc/rc.d/init.d/rhdb ]; then /etc/rc.d/init.d/rhdb start; else /etc/rc.d/init.d/postgresql-9.0 start; fi

3. Command to stop PostgreSQL

Original:

if [ -r /etc/rc.d/init.d/rhdb ]; then /etc/rc.d/init.d/rhdb stop; else /etc/rc.d/init.d/postgresql stop; fi

Cambiar por:

if [ -r /etc/rc.d/init.d/rhdb ]; then /etc/rc.d/init.d/rhdb stop; else /etc/rc.d/init.d/postgresql-9.0 stop; fi

4. Command to initialize PostgreSQL

Original:

if [ -r /etc/rc.d/init.d/rhdb ]; then /etc/rc.d/init.d/rhdb start; else /etc/rc.d/init.d/postgresql initdb ; /etc/rc.d/init.d/postgresql start; fi

Cambiar por:

if [ -r /etc/rc.d/init.d/rhdb ]; then /etc/rc.d/init.d/rhdb start; else /etc/rc.d/init.d/postgresql-9.0 initdb ; /etc/rc.d/init.d/postgresql-9.0 start; fi

5. Path to postmaster PID file

Original:

/var/run/postmaster.pid

Cambiar por:

/var/run/postmaster-9.0.pid

6. Paths to host access config file

Original:

/var/lib/pgsql/data/pg_hba.conf

Cambiar por:

/var/lib/pgsql/9.0/data/pg_hba.conf

7. Default backup repository directory

Original:

/home/db_repository

Cambiar por:

/var/lib/pgsql/9.0/backups

Guardamos la configuración y ahora podemos administrar PostreSQL desde Webmin, Saludos desde Perú.

Ayer, uno de los sistemas de monitorización de red que utilizamos en la universidad (NAV - Network Administration Visualized) tuvo problemas con una de las consultas DELETE que mandaba a la base de datos PostgreSQL que utiliza.

leer más

Los desarrolladores de PostgreSQL han descubierto un fallo en todas las versiones actuales de pg_upgrade y pg_migrator (antiguo nombre). Todos los usuarios que hayan usado pg_upgrade o pg_migrator para actualizar sus bases de datos a nuevas versiones, deben actuar a la mayor brevedad posible.

Este fallo puede causar el siguiente error:

ERROR: could not access status of transaction ######
DETAIL: could not open file "pg_clog/####": No such file or directory=20

leer más

Los PGcon y otros eventos relacionados son excelentes lugares donde aprender más de PostgreSQL y de la gente que colabora en que continue siendo "el gestor de bases de datos mas avanzado del mundo".

Y en este año han habido y aun habrán algunas conferencias y eventos, por ejemplo:

leer más

Introducción
Aunque PostgreSQL tiene un tipo de datos UUID nativo, no existe implementación para la generación de los mismos. Por eso, es necesario utilizar una biblioteca que lo implemente, en nuestro caso OSSP-UUID.

Antes de Empezar
Lo cierto es que la Instalación de OSSP-UUID no comienza con buen pie, ya que la página oficial proporciona un servidor ftp para su descarga, pero ... no ha sido posible, así que he tenido que utilizar algún mirror para poder descargarlo.

Después de este pequeño contratiempo, ya podemos comenzar con la compilación, no exenta de problemillas, así que si no tenéis mucho tiempo y/o ganas, podéis utilizar la versión que he compilado tanto en 32bit como 64bits, aunque en la versión de 64bits no he incluido soporte para C++ ya que ha sido imposible.

Instalación desde el binario
Para aquellos que no tengáis tiempo, podéis instalar OSSP-UUID desde el binario descargando y descomprimiendo sobre el directorio </opt>

root@openzooey:/# cd /opt
root@openzooey:/opt# wget http://blog.sfchildren.com/blogger/postgres/ossp-uuid/openindiana/ossp-uuid-1.6.2-OpenIndiana-x86-32bit-64bit.tar.gz
...
root@openzooey:/opt# gzip -dc ossp-uuid-1.6.2-OpenIndiana-x86-32bit-64bit.tar.gz | tar xpf -
root@openzooey:/opt# rm ossp-uuid-1.6.2-OpenIndiana-x86-32bit-64bit.tar.gz
root@openzooey:/opt# cd ossp-uuid
root@openzooey:/opt/ossp-uuid# bin/64/uuid
2645be62-5b18-11e0-8701-8f5adc896ddd
root@openzooey:/opt/ossp-uuid# bin/uuid
2a08e9ca-5b18-11e0-9914-47107445423d

Instalación desde el código fuente
Para la instalación desde el código fuente, deberemos tener en cuenta que la compilación en 64bits no es posible realizarla utilizando el flag <--with-cxx> y debemos separar las bibliotecas de 64bits de las de 32bits utilizando <--bindir=> y <--libdir>.

Además, hay que hacer un ajuste para que nos enlace de forma correcta la biblioteca, utilizando CC="cc -m64" ya que libtool no lo pasa correctamente

Descargamos el Código Fuente

itily@openzooey:~$ wget http://www.mirrorservice.org/sites/ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz
itily@openzooey:~$ gzip -dc uuid-1.6.2.tar.gz | tar xpf -

Compilación en 64bits

itily@openzooey:~$ cd uuid-1.6.2
itily@openzooey:~/uuid-1.6.2$ export CC="cc -m64"
itily@openzooey:~/uuid-1.6.2$ export CXX=cc
itily@openzooey:~/uuid-1.6.2$ export CFLAGS="-xO3 -xspace -Xa -xildoff -m64 -xc99=none -fast -native -xCC"
itily@openzooey:~/uuid-1.6.2$ export CXXFLAGS="-xO3 -xspace -Xa -xildoff -m64 -xc99=none -fast -native -xCC"
itily@openzooey:~/uuid-1.6.2$ ./configure \
     --prefix=/opt/ossp-uuid \
     --bindir=/opt/ossp-uuid/bin/64 \
     --libdir=/opt/ossp-uuid/lib/64
itily@openzooey:~/a/uuid-1.6.2$ pfexec make install

Compilación en 32bits

itily@openzooey:~/uuid-1.6.2$ export CC="cc"
itily@openzooey:~/uuid-1.6.2$ export CFLAGS="-xO3 -xspace -Xa -xildoff -m32 -xc99=none -xCC"
itily@openzooey:~/uuid-1.6.2$ export CXXFLAGS=$CFLAGS
itily@openzooey:~/uuid-1.6.2$ ./configure \
     --prefix=/opt/ossp-uuid \
     --bindir=/opt/ossp-uuid/bin \
     --libdir=/opt/ossp-uuid/lib
itily@openzooey:~/uuid-1.6.2$ pfexec make install

Comprobación de Funcionamiento

itily@openzooey:~$ /opt/ossp-uuid/bin/uuid -v 4 -n 4
2dadf532-fddf-4902-b89b-4354f208b882
441823a3-5f73-4a9e-be28-0ed394091f7f
926c0d16-99b4-4d72-b5c7-e91933a4818a
c3347042-de2b-4407-9ba5-03ea4ef5a984
itily@openzooey:~$ /opt/ossp-uuid/bin/64/uuid -v 4 -n 4
4376f895-750a-4eef-a865-f06a89baed61
0e4bf68c-7386-4329-9aaa-9e3c3cbc0672
cb5134d4-5cbb-401b-aa70-0edcce7f1a04
ccabcd16-3227-4b59-b0de-3bad19d988f9

Conclusion
Bueno, al principio parece un poco complicado, aunque, al final, no es más que una instalación normal y, como siempre, son los 64bits los que más problemas nos dan.

Ahora sólo nos queda compilar correctamente nuestro PostgreSQL 9 con Soporte par UUID e Instalarlo en OpenIndiana

Refrencias

• Página oficial de OSSP UUID
• UUID para OpenIndiana x86 32bit y 64bit
• Instalar PostgreSQL 9.0.3 64bits en OpenIndiana con soporte UUID
• Instalar PostgreSQL 9.0.x 64bits en OpenIndiana

Introducción
Continuando con algunas de las características de los módulos "contrib" que tenemos en PostgreSQL, y de algunas dependencias de OpenBravo, vamos a ver cómo podemos Instalar PostgreSQL 9.0.3 en 64bits sobre OpenIndiana con soporte para UUID.

Requisitos Previos
Antes de poder continuar, es necesario Instalar OSSP-UUID en OpenIndiana, en nuestro caso en 64bits -como vimos anteriormente-

Además, os recomiendo -si no lo sabéis ya- leer los post sobre Instalar PostgreSQL 9.x en OpenIndiana y Requisitos de Instalación de PostgreSQL 9.x en OpenIndiana

Instalación desde el Binario
Para aquellos que no tengáis tiempo -o ganas- os dejo una versión de PostgreSQL 9.0.3 64bits con soporte para OSSP UUID que simplemente hay que descargar e Instalar el módulo en PostgreSQL -ver más abajo-

root@openzooey:/# cd /
root@openzooey:/# wget http://blog.sfchildren.com/blogger/postgres/9.0.3/openindiana/postgresql-9.0.3-x86-64bit-openindiana-with-uuid.tar.gz
root@openzooey:/# gzip -dc postgresql-9.0.3-x86-64bit-openindiana-with-uuid.tar.gz | tar xpf -
root@openzooey:/# chown -R postgres:postgres /u01
root@openzooey:/# rm postgresql-9.0.3-x86-64bit-openindiana-with-uuid.tar.gz 

Compilación de PostgreSQL
La compilación de PostgreSQL no supone mayor problema que añadir en el script de configuración la opción <--with-ossp-uuid> para que nos permita utilizar nuestro creador de UUID.

Sin embargo, tendremos que exportar nuestro <LD_LIBRARY_PATH> para que el script <configure> pueda "testear" correctamente el acceso a la biblioteca "uuid" que hemos compilado.

Una vez hecho esto, la compilación es, igual que siempre. Vamos a verlo:

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/ossp-uuid/lib/64
$ export CC=cc
$ export CFLAGS="-xO3  -xspace -Xa  -xildoff  -m64  -xc99=none -xCC -fast -native"
$ export LDFLAGS="-R/usr/sfw/lib/64 -R/usr/lib/64 -R/opt/ossp-uuid/lib/64"
$ ./configure \
    --prefix=/u01/app/postgres/9.0/db \
    --exec-prefix=/u01/app/postgres/9.0/db \
    --bindir=/u01/app/postgres/9.0/db/bin/64 \
    --libexecdir=/u01/app/postgres/9.0/db/bin/64 \
    --sbindir=/u01/app/postgres/9.0/db/bin/64 \
    --datadir=/u01/app/postgres/9.0/db/share \
    --sysconfdir=/u01/app/postgres/9.0/db/etc \
    --mandir=/u01/app/postgres/9.0/db/man \
    --libdir=/u01/app/postgres/9.0/db/lib/64 \
    --includedir=/u01/app/postgres/9.0/db/include \
    --sharedstatedir=/var/postgres/9.0 \
    --localstatedir=/var/postgres/9.0 \
    --enable-nls \
    --docdir=/u01/app/postgres/9.0/db/doc \
    --with-system-tzdata=/usr/share/lib/zoneinfo \
    --with-python \
    --with-pam \
    --with-openssl \
    --with-libedit-preferred \
    --with-libxml \
    --with-libxslt \
    --with-gssapi \
    --enable-thread-safety \
    --enable-dtrace \
    --disable-integer-datetimes \
    --with-includes=/usr/include:/usr/sfw/include:/opt/ossp-uuid/include \
    --with-libs=/lib/64:/usr/lib/64:/usr/sfw/lib/64:/opt/ossp-uuid/lib/64 \
    --with-ossp-uuid

Compilación e Instalación
Como siempre, ejecutaremos los comando <make> y <pfexec make install>

$ make
$ pfexec make install

Compilación del Módulo UUID
Para compilar el módulo de UUID, será necesario tener instalado PostgreSQL y situarse en el directorio <contrib> del código fuente de PostgreSQL.

Además, tener en cuenta que debemos compilarlo con GNU Make y no con SVR4 Make. Para comprobar "cual tenéis en el path" simplemente se puede utilizar <which make> y ver cuál es, o, simplemente utilizamos <gmake>

itily@openzooey:~/postgresql-9.0.3$ cd contrib
itily@openzooey:~/postgresql-9.0.3/contrib$ cd uuid-ossp
itily@openzooey:~/postgresql-9.0.3/contrib/uuid-ossp$ gmake
itily@openzooey:~/postgresql-9.0.3/contrib/uuid-ossp$ pfexec gmake install

Esto nos creará una nueva biblioteca de enlace dinámico <uuid-ossp.so> en nuestro directorio <lib/64> de PostgreSQL:

itily@openzooey:~$ cd /u01/app/postgres/9.0/db/lib/64
itily@openzooey:/u01/app/postgres/9.0/db/lib/64$ ls -ltrh uuid-ossp.so
-rwxr-xr-x   1 root root   16K mar 30 21:09 uuid-ossp.so
itily@openzooey:/u01/app/postgres/9.0/db/lib/64$ file uuid-ossp.so
uuid-ossp.so:   ELF 64-bit LSB dynamic lib AMD64 Version 1, dynamically linked, not stripped
itily@openzooey:/u01/app/postgres/9.0/db/lib/64$ ldd uuid-ossp.so
        libuuid.so.16 => /opt/ossp-uuid/lib/64/libuuid.so.16
        libc.so.1 =>     /usr/lib/64/libc.so.1
        libm.so.2 =>     /lib/64/libm.so.2

Instalación en PostgreSQL
Por último, sólo nos queda crear las funciones en nuestra DB de PostgreSQL, para ello, utilizaremos el script <uuid-ossp.sql> que encontraremos en $POSTGRES_HOME/share/contrib

itily@openzooey:/$ cd /u01/app/postgres/9.0/db/share/contrib
itily@openzooey:/u01/app/postgres/9.0/db/share/contrib$ ls -ltr
total 7
-rw-r--r-- 1 root mar 30 21:09 uninstall_uuid-ossp.sql
-rw-r--r-- 1 root mar 30 21:09 uuid-ossp.sql

Deberemos añadirlo a las DB que queramos, utilizando el comando <psql> y un usuario con permisos para "crear languages"

postgres@openzooey:~$ /u01/app/postgres/9.0/db/bin/64/psql -U postgres -d testdb -f uuid-ossp.sql
SET
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
postgres@openzooey:~$ /u01/app/postgres/9.0/db/bin/64/psql -U test -d testdb
psql (9.0.3)
Type "help" for help.

testdb=> SELECT uuid_generate_v3(uuid_ns_url(), 'http://www.postgresql.org');
           uuid_generate_v3          
--------------------------------------
 cf16fe52-3365-3a1f-8572-288d8d2aaa46
(1 row)

testdb=> SELECT uuid_generate_v3(uuid_ns_url(), 'http://www.havoctec.com/');
           uuid_generate_v3          
--------------------------------------
 5f2f3ed0-ce36-3968-b065-4bbaf6684d22
(1 row)

testdb=> \q

Desinstalación del módulo
Para poder desinstalarlo, simplemente utilizaremos el script <uninstall_uuid-ossp.sql> de la siguiente forma:

postgres@openzooey:~$ /u01/app/postgres/9.0/db/bin/64/psql -U postgres -d testdb -f uninstall_uuid-ossp.sql
SET
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION

Algunos Errores
Si no hemos podido instalar correctamente el módulo dentro de PostgreSQL, se nos mostrará el siguiente error al tratar de usar la función:

testdb=> SELECT uuid_generate_v3(uuid_ns_url(), 'http://www.postgresql.org');
ERROR:  function uuid_ns_url() does not exist
LINE 1: SELECT uuid_generate_v3(uuid_ns_url(), 'http://www.postgresq...
                                ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

Si intentamos crear las funciones con un usuario que no tiene permisos suficientes, tendremos el siguiente error:

postgres@openzooey:~$ /u01/app/postgres/9.0/db/bin/64/psql -U testuser -d testdb -f uuid-ossp.sql
SET
psql:uuid-ossp.sql:9: ERROR:  permission denied for language c
psql:uuid-ossp.sql:14: ERROR:  permission denied for language c
psql:uuid-ossp.sql:19: ERROR:  permission denied for language c
psql:uuid-ossp.sql:24: ERROR:  permission denied for language c
psql:uuid-ossp.sql:29: ERROR:  permission denied for language c
psql:uuid-ossp.sql:34: ERROR:  permission denied for language c
psql:uuid-ossp.sql:39: ERROR:  permission denied for language c
psql:uuid-ossp.sql:44: ERROR:  permission denied for language c
psql:uuid-ossp.sql:49: ERROR:  permission denied for language c
psql:uuid-ossp.sql:54: ERROR:  permission denied for language c

Conclusiones
Parece más complicado de lo que parece, pero al final, resulta bastante sencillo. Además, debemos recordar que a partir de ahora, tenemos que incluir OSSP-UUID como dependencia de nuestro PostgreSQL

Referencias

• Instalación de PostgreSQL 9.0 en OpenIndiana
• Instalación de PostgreSQL en Solaris 10
• Copias de Seguridad en PostgreSQL 
• PostgreSQL 9.0.3 x86 64bit para OpenIndiana con UUID
• Instalación de OSSP UUID en OpenIndiana

Nota: "Este artículo ha sido una broma por el "Día de los bufones de abril" (April fools' day). Todo lo expresado en el mismo sobre el proyecto PostgreSQL es pura ficción y no tiene nada que ver con la realidad."

Como muchos ya sabeis, hace unos días unos hackers atacaron los servidores de MySQL.com. Mediante este ataque consiguieron, entre otras cosas, acceder a varias bases de datos de esta compañia y a los datos contenidos en las mismas.

leer más

Introducción
Ya hemos hablado varias veces de Cómo Instalar PosgreSQL en OpenIndiana y, también Cómo Actualizar PostgreSQL en OpenIndiana.

En esta ocasión, vamos a compilar PostgreSQL 9.0.3 en 64bits y, debido a las peticiones que tengo por parte de vosotros, también en 32bits.

Además, veremos todos los requisitos necesarios para poder gestionar PostgreSQL 9.0.3 en OpenIndiana utilizando Solaris SMF y, utilizar RBAC para su gestión.

Antes de comenzar
He visto que alguno de vosotros tenéis problemas con la forma de instalación de PostgreSQL sobre OpenIndiana, y, al parecer también con el role <postgres> o los pasos de compilación.

Todos los pasos de compilación de estos post se realizan sobre OpenIndiana 64bits utilizando para la instalación el formato de <Text Install> y siguiendo los pasos de Instalar OpenIndiana en VirtualBox Paso a Paso

Así mismo, os recomiendo -si no lo habéis hecho antes- leer el post sobre Actualización de PostgreSQL 9.0.2 64bits en OpenIndiana, donde explico los pasos de una forma más detallada.

Upgrade desde OpenSolaris
Si hemos hecho el <upgrade> desde OpenSolaris, tendremos el role <postgres> y las autorizaciones necesarias, si por el contrario hemos Instalado OpenIndiana directamente, no existirán y las deberemos crear.


Comprobación de las Autorizaciones
Debemos comprobar también que tenemos las autoriaciones necesarias para poder gestionar el servicio <postgresql_9> en nuestro sistema a través de Solaris SMF.

itily@openzooey:~$ pfexec  cat /etc/security/auth_attr|grep postgres
solaris.smf.manage.postgres:::Manage Postgres service states::
solaris.smf.value.postgres:::Change Postgres value properties::

Si no nos devuelve nada, entonces deberemos crearlo, para ello añadiremos las autorizaciones de la siguiente forma

root@openzooey:/# echo "solaris.smf.manage.postgres:::Manage Postgres service states::" >> /etc/security/auth_attr
root@openzooey:/# echo "solaris.smf.value.postgres:::Change Postgres value properties::" >> /etc/security/auth_attr

Verificación del Profile <Postgres Administration>
Por último, debemos comprobar que tenemos el <profile> de Administración de PostgreSQL definido en nuestro sistema, para ello, haremos

itily@openzooey:~$ pfexec cat /etc/security/prof_attr|grep Postgres
Postgres Administration::::auths=solaris.smf.manage.postgres,solaris.smf.value.postgres

Si no nos devuelve nada, deberemos crearlo de la siguiente manera:

root@openzooey:/# echo "Postgres Administration::::auths=solaris.smf.manage.postgres,solaris.smf.value.postgres" >> /etc/security/prof_attr

Comprobación del Role <postgres>
Debemos comprobar que nuestro sistema tiene el role <postgres> creado, sino, lo crearemos nosotros, para ello, simplemente buscaremos en la base de datos </etc/user_attr> y nos fijaremos en el valor de <type=> para comprobar que es un <role>, por ejemplo

itily@openzooey:~$ pfexec cat /etc/user_attr|grep postgres
postgres::::type=role;profiles=Postgres Administration,All

Llegado a este punto, debemos tener en cuenta que si no existe el <role> postgres, comprobaremos si es un usuario, ya que en OpenIndiana viene como Usuario y no como Role, para ello comprobaremos que existe en </etc/passwd>

root@openzooey:/# cat /etc/passwd |grep postgres
postgres:x:90:90:PostgreSQL Reserved UID:/:/usr/bin/pfksh

Como vemos, existe como usuario, pero no dispone del <profile> Postgres Aministration que necesitamos, así que vamos a añadirlo utilizando la opción "-P 'Postgres Administration'".

Si intentamos modificar el <profile> de un usuario utilizando el comando <rolemod> OpenIndiana nos contestará con un mensaje come este:

root@openzooey:/# rolemod -P 'Postgres Administration' postgres
UX: rolemod: ERROR: Users must be modified with ``usermod''.

Así que utilizaremos el comando <usermod> con la misma opción

root@openzooey:/# usermod -P "Postgres Administration" postgres

Comprobamos que tenemos asignado correctamente todo, y que las autorizaciones están definidas. Para ello, utilizaremos el comando <auth postgres> para las autorizaciones y <profiles postgres> para los profiles.

root@openzooey:~# profiles postgres
postgres:
          Postgres Administration
          Basic Solaris User
          All
root@openzooey:~# auths postgres
 solaris.admin.wusb.read,
 solaris.device.cdrw,
 solaris.device.mount.removable,
 solaris.mail.mailq,
 solaris.profmgr.read,
 solaris.smf.manage.postgres,
 solaris.smf.value.postgres

Ahora debemos dedicir si queremos seguir manteniendo el usuario, o por el contrario convertirlo a un Role y así, poder delegar las tareas de administración.

Mi recomendación es convertirlo a un role -si no lo es-, para ello, utilizaremos el comando <usermod> y la opción <-K type=role> para convertirlo, por ejemplo:

root@openzooey:/# usermod -K type=role postgres
root@openzooey:/# cat /etc/user_attr|grep postgres
postgres::::type=role;profiles=Postgres Administration

Configurar base de datos de <pfexec>
Por último, deberemos definir los comandos que el <profile> Postgres Administration puede ejecutar utilizando <pfexec>, para ello, deberemos de dar de alta.

Es muy importante que entendáis que estáis haciendo, para ello, os recomiendo leer la serie de artículos sobre Solaris RBAC y Modelo de Privilegios.

Con esto, ya tenemos la estructura para poder gestionar nuestro PostgreSQL con RBAC

Comprobación de la Arquitectura y Kernel
A continuación, vamos a comprobar que tipo de arquitectura tenemos: SPARC o x86 y sobre esta, qué tipo de kernel tenemos, de 32bit o 64bit.

Para verificar nuestra arquitectura, utilizaremos el comando <uname -a> por ejemplo:

itily@openzooey:~$ pfexec uname -a
SunOS openzooey 5.11 oi_148 i86pc i386 i86pc

Hay que tener en cuenta que el comando <uname> no nos va a decir si es o no una arquitectura de 64bits, ya que nos dirá <i386>. Esto es porque la diferencia de arquitectura es para SPARC o i386.

Para saber si nuestro kernel es de 32bit o 64bits, deberemos utilizar el comando <isainfo> con las opciones <-kv>, por ejemplo:

itily@openzooey:~$ pfexec isainfo -kv
64-bit amd64 kernel modules

Por lo tanto, ahora sabemos que estamos ejecutando OpenIndiana -o Solaris- sobre una plataforma x86 con un kernel de 64bit.
 
Instalación de PostgreSQL 9.0.3 desde Binarios
Ahora que ya sabemos qué arquitectura tenemos, y nuestro tipo de kernel, podemos seleccionar la versión de PostgreSQL 9.0.3 que deseemos.

• PostgreSQL 9.0.3 i86pc 32bits para OpenIndiana
• PostgreSQL 9.0.3 i86pc 64bits para OpenIndiana

Simplemente, descargaremos el binario que queramos (de 32bit o 64bit) y lo descomprimiremos en nuestro sistema, en </>

itily@openzooey:/# cd /
itily@openzooey:/# wget http://blog.sfchildren.com/blogger/postgres/9.0.3/openindiana/postgresql-9.0.3-x86-64bit-openindiana.tar.gz
itily@openzooey:/# gzip -dc postgresql-9.0.3-x86-64bit-openindiana.tar.gz | tar xvpf -
itily@openzooey:/# chown -R postgres:postgres /u01
itily@openzooey:/# chmod 750 /u01

Configuración de PostgreSQL en SMF
A continuación configuraremos nuestro servicio postgres para que sea controlado mediante SMF, para ello, debemos descargar el Manifest para Solaris y OpenIndiana SMF  PostgreSQL 9 y el Method para Solaris y OpenIndiana SMF PostgreSQL 9

# cd /lib/svc/method
# wget http://blog.sfchildren.com/blogger/openindiana/postgresql/9.0/smf/postgres_9
# chown root:bin postgres_9
# chmod 555 postgres_9
# mkdir -p /var/svc/manifest/application/database
# cd /var/svc/manifest/application/database
# wget http://blog.sfchildren.com/blogger/openindiana/postgresql/9.0/smf/postgresql_9.xml
# svccfg
svc:> validate postgresql_9.xml
svc:> import postgresql_9.xml
svc:> quit
# svcs -p postgresql_9
STATE          STIME    FMRI
disabled        9:29:24 svc:/application/database/postgresql_9:default_32bit
disabled       10:24:40 svc:/application/database/postgresql_9:default_64bit

Conclusion
En esta ocasión hemos visto algunos puntos necesarios para la instalación de PostgreSQL en OpenIndiana.

Además, gracias a los comentarios y dudas, creo que en esta ocasión he intentado despejar esas "dudas" que os asaltan,

Espero que os ayude y, sobre todo, aclarar los pasos de instalación.


Referencias

• Actualizar PostgreSQL 9.0.2 en OpenIndiana
• Instalación de PostgreSQL 9.0 en OpenIndiana
• Instalación de PostgreSQL en Solaris 10
• Copias de Seguridad en PostgreSQL
• RBAC, Roles y Privilegios - Parte 1
• RBAC, Roles y Privilegios - Parte 2
• Manifest PostgreSQL 9.0 OpenIndiana
• Method PostgreSQL 9.0 OpenIndiana
• Página principal PostgreSQL

Acabo de publicar el segundo artículo sobre monitorización de la serie que estamos haciendo sobre este tema.

Este segundo artículo trata sobre como generar gráficos con gnuplot a partir de datos obtenidos con monitorización Ad Hoc.

El artículo se titula "Monitorizacion II - Generando gráficos de datos Ad Hoc" y está disponible en http://www.postgresql.org.es/node/594

--
Rafael Martinez
PostgreSQL-es

Estamos planificando un cambio de dirección en PostgreSQL-es. En los próximos dias actualizaremos el servidor para que la dirección oficial del mismo pase a ser http://www.postgresql.org.es/

La dirección http://www.postgresql-es.org/ se redirigirá automáticamente a http://www.postgresql.org.es/ después del cambio. Los usuarios de PostgreSQL-es no deberian de tener ningún problema accediendo a los contenidos. Si teneis algún problema podeis mandar un mensaje a webmaster@postgresql.org.es.

leer más

Como comentaba en "las 8 falacias de los sistemas distribuídos", en los entornos de producción debemos tener en cuenta que pueden suceder hechos que no se producen en nuestros entornos de desarrollo, integración o preproducción... y ciertamente ocurren. En estos entornos son necesarios procesos y tareas concurrentes inherentes a su propia naturaleza y ambiente de "explotación" (tareas de mantenimiento tanto programados -backups-, como no programados -recuperaciones de datos-, arranque eventual de otras -nuevas- aplicaciones, procesos de datawarehousing, etc).

Uno de estos sucesos típicos suele ser el inexplicable y aleatorio bloqueo de una sesión o de toda una aplicación entera. Tras el correspondiente susto y examen exhaustivo, detectamos la causa en una consulta de base de datos que, eventualmente, tarda demasiado. En algunas ocasiones las causas son muy poco evidentes y muy difíciles de detectar, ya que sólo se producen por la coincidencia de determinados eventos (periódicos o no), e incluso en un determinado orden.

¿Y por qué tarda tanto una consulta que en nuestro entorno de preproducción se lleva apenas unas pocas decenas de milisegundos? Pues típicamente porque ocurre un bloqueo en la base de datos debido a una transacción de larga duración. Si las cosas se complican, puede existir incluso un deadlock (bloqueo mutuo) que deje nuestro sistema completamente bloqueado y produzca un efecto dominó en otras aplicaciones dependientes de la misma base de datos.

Obviamente, la solución pasa por detectar la casuística concreta y evitarla, pero mientras buscamos la causa o la solución, necesitamos mantener nuestro sistema funcionando con normalidad. Para protegernos a este tipo de eventualidades, se debe establecer un valor de timeout en nuestras consultas y transacciones a bases de datos que impida que una consulta se quede indefinidamente esperando el resultado y, por tanto, todas las sesiones de la aplicación que llegan a ese punto. En los entornos JEE, donde se configuran pools de conexiones a bases de datos que permiten un uso eficiente de recursos y conexiones de bases de datos, la ausencia de estos timeouts en esas condiciones pueden suponer el agotamiento de las conexiones del pool, debido a que no se liberan las conexiones y, por tanto, la imposibilidad de que nuevas sesiones de la aplicación puedan funcionar.

Configuración de Statement Timeout en Glassfish

En la mayoría de los servidores de aplicaciones y contenedores web JEE, existe una forma de indicar este parámetro para cada uno de nuestros pools, permitiendo especificar distintos parámetros en función de las características de las aplicaciones o de la duración de las transacciones. En el caso de Glassfish, por ejemplo, es a través del atributo StatementTimeout del pool (que internamente realiza las llamadas a setQueryTimeout() del driver.


Usando PostgreSQL, este atributo sin embargo nos ha dado una desagradable sorpresa:

Caused by: org.postgresql.util.PSQLException: Method org.postgresql.jdbc4.Jdbc4PreparedStatement.setQueryTimeout(int) is not yet implemented.
        at org.postgresql.Driver.notImplemented(Driver.java:753)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.setQueryTimeout(AbstractJdbc2Statement.java:635)
        at com.sun.gjc.spi.base.ConnectionHolder.prepareStatement(ConnectionHolder.java:477)
        at oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.prepareStatement(DatabaseAccessor.java:1162)
        at oracle.toplink.essentials.internal.databaseaccess.DatabaseCall.prepareStatement(DatabaseCall.java:612)
        at oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:485)

Pues si, aunque parezca increíble, el driver jdbc de Postgresql no implementa aún setQueryTimeout(), al menos hasta la versión disponible en el momento de escribir este artículo (versión Version 9.0-801 de 2010-09-20).

Establecimiento de propiedades de la conexión en el pool de conexiones de Glassfish

La solución es establecer el parámetro de conexión SocketTimeout, que especifica en segundos el tiempo máximo que se espera respuestas del servidor antes de cerrar la conexión. Este parámetro tiene el mismo efecto que el atributo StatementTimeout / QueryTimeout que comentaba anteriormente.


Para nuestros scripts PL/pgSQL, podemos establecer directamente el parámetro statement_timeout al inicio:

SET statement_timeout TO 5000; -- para 5 segundos

 <...resto del PL>

RESET statement_timeout; -- reset

En general, establecer un valor de timeout en operaciones síncronas es una buena práctica para evitar sorpresas desagradables.

Acabo de publicar el primer artículo sobre monitorización perteneciente a una serie que tengo planeada hacer sobre este tema. La idea surgio en el entrenamiento especializado que impartí en el PGDay Latinoamericano 2011 en Cuba a principios de mes.

Este primer artículo es una introducción sobre el tema y en sucesivos artículos trataremos como usar e interpretar los datos obtenidos de monitorizar nuestros sistemas. Tambien veremos como instalar y configurar los programas más utilizados para estas tareas.

El artículo está disponible en http://www.postgresql.org.es/node/582

--

leer más

Esta mañana leyendo la lista pgsql-performance he visto un mensaje de Greg Smith con información interesante.

Generalmente cada vez que un usuario pide ayuda por un problema de configuración o uso inadecuado de recursos se le suele pedir más información sobre los cambios que ha realizado en el fichero de configuración postgresql.conf. Muchas veces los usuarios no mandan toda esta información o simplemente se les olvida mandar todos los cambios que han realizado en la configuración de su sistema.

leer más

Hemos creado un "Planeta PostgreSQL-es" para recoger publicaciones de blogs en español que tengan información sobre PostgreSQL y/o temas relacionados.

Con este servicio se pretende facilitar el acceso a la información creada por usuarios de PostgreSQL en diferentes blogs a lo largo y ancho del planeta.

leer más

Una vez concluido el PGDay Latinoamericano 2011 que se realizó en la Universidad de Ciencias Informáticas (UCI) en La Habana, Cuba; he tratado de extraer ideas y opiniones. He aquí algunas de ellas:

leer más