Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous...
Dans nos maintenances de nuit nous avons deux backups (par Pg_dump) :
1 pour notre database TOTO
1 pour la database postgrès
S'il arrive un gros pépin sur TOTO, suis-je sois obliger de restaurer TOTO et Postgrès (qui pour moi est le catalogue) ?
Hors ligne
non, bien sûr, vous pouvez ne restaurer qu'une base. De toutes façons, pg_dump ne fait de dump que par bases individuelles. Essayez le format 'compressed' de pg_dump, c'est celui qui offre le plus de souplesse à la restauration.
Marc.
Hors ligne
Et pour un supplément d'informations, non, la base postgres n'est pas un catalogue. La base postgres est une base comme toutes les autres.
Guillaume.
Hors ligne
Oui. Et il vaut mieux utiliser une base 'normale', créée pour l'occasion, que la base postgres.
Marc.
Hors ligne
Effectivement, je me suis trompé entre la database Postgrès et le pg_catalogue postgrèsSQl interne à chaque database... nul, le mec !
Plusieurs questions :
1°) Je lis dans la doc que la database postgrès est 'une base de données nommée qui a pour but d'être la base de données par défaut utilisée par les outils, les utilisateurs et les applications tiers' ... j'ai pas compris le rôle vrai de cette database, avez-vous des exemples ?
2°) Chaque database a 2 catalogues ANSI (information_schéma) et PostgresSql (pg_catalogue)... quelle est la différence entre les deux ?
3°) La notion de schéma n'est pas identique à oracle => Ok ... Par quoi/qui est défini un schéma dans postgrès (dans mes databases le seul schéma qui existe est le schéma 'public')...
4°) Quelle est la différence entre les tablespaces pg_default et pg_global ?
Excusez encore pour mon ignorance !
Hors ligne
1) vous pouvez avoir plusieurs bases dans un 'cluster'. Par exemple une base compta, une base paie, etc… postgres est plutôt une base administrative, qui ne sert normalement qu'à se connecter.
2) c'est le information_schema qui est ansi, en fait. le pg_catalog, c'est la version 'maison' du catalogue postgresql. information_schema est une série de vue sur pg_catalog présentant pg_catalog dans un format compatible avec la norme.
3) un schema est défini par le propriétaire de la base, ou un super utilisateur. public est là par défaut.
4) pg_global contient les objets globaux à toutes les bases (users, tablespaces, liste des bases, etc…). pg_default est le tablespace 'par défaut' des bases (le répertoire base du cluster tout simplement).
Marc.
Hors ligne
Quelques compléments :
1) Les outils createdb, createuser, dropdb, droplang, etc se connectent par défaut sur cette base (postgres). Sans sa présence, il faut passer par la variable d'environnement PGDATABASE pour en sélectionner une autre et ça devient rapidement galère.
2) Tous les objets ne sont pas décrits dans information_schema, ne serait-ce que pour les objects qui sont extensions spécifiques à PostgreSQL.
Guillaume.
Hors ligne
1°) La connexions à la database Postgrès (avec le user postgrès) donne t'il plus de droits sur les autres databases du 'cluster' ?
3°) Ma database TOTO n'a que le schéma 'public' => Ok ... Quand je crée une table trucmuche.table, j'ai une erreur de type : 'le schéma trucmuche n'existe pas' alors que le rôle de connexion 'trucmuche' existe ... comment expliquez-vous ça d'autant plus que je me suis connecté avec le user 'trucmuche' ...
4°) Si je crée la base TITI dans le 'cluster' de la base TOTO, le pg_default contiendra les objets de TITI et TOTO ?
5°) Si oui, imaginons que TOTO soit une copie de TITI sur le même cluster (pour effectuer des mise à jour de charge par exemple), si TOTO n'a que le user public, il y aura des redondances dans le nom des objets non ? Et donc plantage à chaque CREATES ?
Hors ligne
1) Non
3) Schema <> User sous PostgreSQL. Créer un utilisateur ne crée pas le schéma. Il faut faire un create schema avec pour propriétaire l'utilisateur, si vous voulez vraiment retrouver le fonctionnement à la oracle
4)oui
5) non, les noms des objets sont heureusement logiquement séparés entre chaque base. ainsi qu'entre chaque schéma. vous pouvez avoir le même nom de table dans deux schémas différents, et dans deux bases différentes aussi.
Marc.
Hors ligne
Merci pour vos réponses...
3°) Donc, dans le cas d'un applicatif qui accède à ma table, il sera obligé de préfixer la table accédée, par le nom du schéma ?
5°) Quelle information me donne le répertoire ou sont placées les objets du tablespace pg_default ? La documentation n'en parle pas !
5° encore) L'arborescence de Pg-default sera t'elle identique entre TOTO et TITI ?
Hors ligne
3) non. c'est à cela que sert le search_path
5) pg_default, c'est le répertoire 'base' du cluster
l'arborescence sera identique, puisqu'il s'agit d'un même et unique tablespace. vous aurez juste un sous-répertoire dedans par base.
Marc.
Hors ligne
Merci et bonne soirée...
Hors ligne
E
2°) Chaque database a 2 catalogues ANSI (information_schéma) et PostgresSql (pg_catalogue)... quelle est la différence entre les deux ?
3°) La notion de schéma n'est pas identique à oracle => Ok ... Par quoi/qui est défini un schéma dans postgrès (dans mes databases le seul schéma qui existe est le schéma 'public')...
La norme SQL définit la notion de schema SQL qui est un espace logique de placement des objets dans les bases.
Les schémas SQL (la notion de "catalog" est en fait la dénomination normative de la notion de "base de données") sont obligatoire et vous ne pouvez pas créer d'objet sans passer par un schéma.
Il y a donc un schéma SQL par défaut par base et par utilisateur :
- Dans postgreSQL le schéma par défaut de la base s'apelle PUBLIC. (Dans SQL Server il s'appelle dbo).
- pour l'utilisateur c'est aussi PUBLIC à moins que vous n'ayez spécifié un autre schéma à la création de l'utilisateur.
INFORMATION_SCHEMA est un schéma SQL par défaut contenant les vues d'information de schéma de la norme SQL. Voir : http://sqlpro.developpez.com/cours/sqla … partie2#L9
pg_catalogue est un schéma spécifique à PostGreSQL qui contient des objets de méta description et les fonctions système (par exemple ABS).
Vous pouvez créer autant de schéma SQL que vous souhaitez afin de structurer vos objets. C'est en général une bonne façon de faire que de mettre les objets de la paye dans un schéma paye, ceux de la compta dans un schéma compta, de la prod....
Il vaut mieux toujours préfixer les objets par leurs schémas. Ceci possède deux avantages :
1) la résolution de nom est instantanée (il n'y a pas à interroger les tables système pour savoir quel est le schéma par défaut de l'utilisateur)
2) le cache conserve mieux les plans de requête : les objets sont connus et strict
A +
Dernière modification par SQLpro (12/01/2011 18:47:11)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Pages : 1
