Le blog de Pierre

Dans le cadre d'un cluster Oracle Grid Infrastructure 11g R2 utilisé pour gérer des bases de données en mode FAILOVER, j'ai été amené à me pencher sur l'algorithme de basculement d'une ressource et des paramètres le régissant.

L'objet de ce posting est de décrire la mise en place et l'utilisation d'un gestionnaire de sauvegarde pour un cluster de  base postgresql. Barman - acronyme de "backup recovery manager"- pour PostgreSQL est le logiciel sur lequel nous nous pencherons. C'est un outil permettant de centraliser la gestion des sauvegardes dans une situation avec plusieurs serveurs.

Nous avons dans les articles précédents vu comment installer PostgreSQL et quels étaient les composants d'une base. Nous abordons maintenant le point de l'action sur le moteur avec deux outils orientés administration de la base, généralement utilisés par les DBAs. Il s'agit de psql et de PgAdmin. Nous aborderons aussi dans cet article la configuration de connexion au travers des fichiers de configuration du serveur.

Dans mon dernier article sur PostgreSQL, j'ai présenté l'installation du logiciel en explorant les 2 solutions suivantes, l'installation Debian et l'installation EntrepriseDB. Ces deux installations créent immédiatement un cluster de base de données, Debian nous imposant le point de stockage et EntrepriseDB nous proposant de saisir une destination. Je vous propose maintenant d'explorer ce qui a été installé sur votre disque à la mise en route de ce cluster de base et d'analyser les différences entre les deux installations.

Dans mon précédent article concernant PostgreSQL, j'ai annoncé une serie d'article sur ce SGBDR, aprés une courte introduction et avant de plonger dans le fonctionnement interne, l'architecture etc... je vous propose d'aborder l'installation du produit.

En 2012, les principaux systèmes de gestion de bases de données relationnelles (SGBDR) sur le marché sont propriétaires. Nous parlons régulièrement d'Oracle Database, MySQL, Microsoft SQL Server. En dehors de ces solutions commerciales, il existe un SGDBR open-source largement utilisé: il s'agit de PostgreSQL et il est l'objet de cet article.

Aprés le post sur « Utilisons les securefile », revenons sur le sujet LOB avec une approche performance, stockage. Nous rencontrons parfois des modèles de données étranges, nous aurions envie en tant que DBA de tout reprendre à zéro pour refaire un modele relationnel en 3eme forme normale (3NF), plus efficace et mieux conçu dans notre « RDBMS » favori, mais la réalité étant ce qu'elle est nous devons faire avec, et au mieux. De plus Oracle n'est pas qu'une base de données relationnelle :-) on l'oublie trop souvent.

La nouvelle version d'Oracle SQL Developer (version 3.0.03.45) est prête pour les administrateurs de base de données/DBA (voici une vidéo sur cette version). Elle s'est vue agrémentée d'outils nécessaires aux tâches d'administration. Les tests ci-dessous vous présentent, à travers quelques copies d'écrans, les fonctionnalités de l'outil,  en espérant vous donner l'envie de l'adopter.

Le stockage des LOB est souvent négligé lors de la création des tables. Hors les choix de stockage ont un impact sur la performance d'accès aux données. Nous allons voir rapidement dans cet article l'avantage à utiliser le stockage SecureFiles proposé par Oracle à partir de la version 11gR1.

Aprés une migration de 10gR2 vers 11gR2, une application utilisant les packages DBMS_XMLQUERY pour générer des documents xml est en erreur. Le format des dates a changé, qu'a fait le DBA ?