#postgresql Hace unos dias instalamos un nuevo servidor PostgreSQL 9.2 que se va a utilizar por diferentes cursos de bases de datos que se imparten en la facultad de informática de la Universidad de Oslo.
La idea es que cada alumno registrado en alguno de estos cursos tenga acceso a su base de datos postgreSQL para realizar sus prácticas.
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.
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.
Al final del día, una base de datos tiene toda la información que necesita para funcionar grabada en nuestro disco duro. PostgreSQL no es una excepción.
En este artículo vamos a intentar dar una introducción sobre como PostgreSQL 9.1 graba nuestros datos en el disco y como se las arregla para encontrar los mismos cuando los necesitamos. Tener las cosas claras en lo que respecta a este tema nos puede ayudar en momentos difíciles como administradores de bases de datos, en el caso que nuestros datos se corrompan por alguna causa.
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.
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.
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.
Este artículo es el segundo de una serie de artículos sobre monitorización que estamos publicando en PostgreSQL-es. En el vamos a ver como podemos generar gráficos de una manera fácil a partir de los datos generados usando monitorización Ad Hoc.
En el artículo anterior de la serie, "Monitorización", hablamos de dos tipos de monitorización, Ad Hoc y Preventiva.
Una de las tareas más importantes de un administrador de bases de datos es monitorizar los sistemas a su cargo para saber como están funcionando y planear futuras modificaciones y actualizaciones de los mismos.
Este artículo es una introducción a la monitorización de sistemas de bases de datos en sistemas Linux/Unix y está basado en un entrenamiento especializado que se impartio en el PGDay Latinoamericano 2011 en Cuba. Más adelante escribiremos otros artículos más específicos que nos ayuden a usar e interpretar los datos obtenidos de monitorizar nuestros sistemas.
Con el lanzamiento de la versión 9.0 se han introducido una serie de nuevas características y cambios con respecto a la version 8.4, que en muchos casos harán la vida más fácil a todos los usuarios que usen esta base de datos.
Este artículo está basado prácticamente en su totalidad en información publicada en el wiki oficial de PostgreSQL y en las pruebas realizadas durante el periodo de desarrollo de la versión 9.0.
