Vous n'êtes pas identifié(e).
Je m'énerve pas... Je rigole !!! ;-)
Pour info : Windows XP sp3 / Intel Core2 Quad CPU à 2.66Ghz, 3.5 Go de RAM
A +
je suis sous Windows !!!!
Et la log sous windows me dit constamment des truc comme ça :
2011-06-16 15:48:37 CEST LOG: le système de bases de données a été interrompu ; dernier lancement connu à 2011-06-16 15:47:28 CEST
2011-06-16 15:48:37 CEST LOG: le système de bases de données n'a pas été arrêté proprement ; restauration
automatique en cours
2011-06-16 15:48:37 CEST LOG: état de restauration cohérent atteint à 0/1DE5638
2011-06-16 15:48:37 CEST LOG: enregistrement de longueur nulle à 0/1DE5638
2011-06-16 15:48:37 CEST LOG: la ré-exécution n'est pas nécessaire
2011-06-16 15:48:37 CEST LOG: le système de bases de données est prêt pour accepter les connexions
2011-06-16 15:48:37 CEST LOG: lancement du processus autovacuum
2011-06-16 16:09:45 CEST LOG: processus serveur (PID 9284) a été arrêté par l'exception 0xC0000005
2011-06-16 16:09:45 CEST ASTUCE : Voir le fichier d'en-tête C « ntstatus.h » pour une description de la valeur
hexadécimale.
2011-06-16 16:09:45 CEST LOG: arrêt des autres processus serveur actifs
2011-06-16 16:09:45 CEST ATTENTION: arrêt de la connexion à cause de l'arrêt brutal d'un autre processus serveur
2011-06-16 16:09:45 CEST DÉTAIL: Le postmaster a commandé à ce processus serveur d'annuler la transaction
courante et de quitter car un autre processus serveur a quitté anormalement
et qu'il existe probablement de la mémoire partagée corrompue.
2011-06-16 16:09:45 CEST ASTUCE : Dans un moment, vous devriez être capable de vous reconnecter à la base de
données et de relancer votre commande.
2011-06-16 16:09:45 CEST ATTENTION: arrêt de la connexion à cause de l'arrêt brutal d'un autre processus serveur
2011-06-16 16:09:45 CEST DÉTAIL: Le postmaster a commandé à ce processus serveur d'annuler la transaction
courante et de quitter car un autre processus serveur a quitté anormalement
et qu'il existe probablement de la mémoire partagée corrompue.
2011-06-16 16:09:45 CEST ASTUCE : Dans un moment, vous devriez être capable de vous reconnecter à la base de
données et de relancer votre commande.
2011-06-16 16:09:45 CEST ATTENTION: arrêt de la connexion à cause de l'arrêt brutal d'un autre processus serveur
2011-06-16 16:09:45 CEST DÉTAIL: Le postmaster a commandé à ce processus serveur d'annuler la transaction
courante et de quitter car un autre processus serveur a quitté anormalement
et qu'il existe probablement de la mémoire partagée corrompue.
2011-06-16 16:09:45 CEST ASTUCE : Dans un moment, vous devriez être capable de vous reconnecter à la base de
données et de relancer votre commande.
2011-06-16 16:09:45 CEST LOG: tous les processus serveur se sont arrêtés, réinitialisation
2011-06-16 16:09:55 CEST FATAL: le bloc de mémoire partagé pré-existant est toujours en cours d'utilisation
2011-06-16 16:09:55 CEST ASTUCE : Vérifier s'il n'y a pas de vieux processus serveur en cours d'exécution. Si c'est le
cas, fermez-les.
Aurais-tu une idées ???
A +
béta 1...
Comment je désingue dans l'IHM ?
Clic droit et supprimer je suppose...
A +
Désolé j'ai pas trouvé ou posté car ma demande concerne plutôt de l'admin, mais il n'y a pas de forum admin...
Voici le problème étrange que je rencontre :
Sur machine Windows XP (PC de test, base quasi vides)
3 instance de postGreSQL sont installées : 8.3 (port 5433), 8.4 (port 5435), 9.1 (port 5434)
Je voit bien mes 3 services
Mais dans l'interface pgAdminIII (version 1.12.3) je vois 4 serveurs en 2 groupes :
- le premier groupe contient les 3 serveur
- le deuxième groupe ne contient que le 9.1
Déjà je ne comprend pas pourquoi et comment y remédier.
Mais plus grave, lorsque je fais des requêtes via l'IHM query de pgAdminIII sur l'instance 9.1 et que la requête part en erreur, la connexion est immédiatement rompue et le service est stoppé !
Exemple de requête qui tourne sur les instances 8.3 et 8.4 :
SELECT 'Aujourd''hui ' || CAST(CURRENT_DATE AS CHAR(50)) AS TOTO;Sur le 9.1 cela me donne :
********** Erreur **********
et si je ressaye :
********** Erreur **********
no connection to the server
et dans la liste des services actifs PG 9.1 n'écoute plus, il faut redémarrer le service !!!
Bref, je sais pas ce qui se passe et comment y remédier.
Merci d'avance.
A +
...Par contre en faisant une recherche sur "bucardo" je suis tombé sur ce post http://forums.postgresql.fr/viewtopic.php?id=260 qui traite de la même problématique et dans lequel vous disiez carrément que
gleu a écrit :Non, ça n'existe pas, quelque soit le moteur de base de données...
...
Erreur, cela existe depuis plus de 13 ans dans SQL Server. C'est la réplication de fusion (MERGE).
A lire : http://msdn.microsoft.com/fr-fr/library/ms152746.aspx
La seule chose à penser elle qu'elle induit fatalement des conflits, que vous pouvez résoudre manuellement ou automatiquement.
En gros comment faire si la même ligne a été mise à jour par deux serveur différents ?
La solution consiste à rajouter des règles, si possible sans équivoque.
Exemple de règle équivoque : prendre la ligne la plus récente (que faire si exactement la même dateheure ?)
Exemple de règle non équivoque : le serveur central gagne toujours.
Si vous voulez des détails sur l'implémentation d'une telle solution, faites le moi savoir.
A +
Ce serait effectivement beaucoup plus simple en PowerShell !
A +
En écrivant votre requête ainsi, vous rendez le prédicat non "sargable", car vous obligez la colonnes à une transformation via une fonction, ce qui empêche toute utilisation d'index.. Vous aurez donc des performances de plus en plus mauvaise au fur et à mesure de la montée en charge...
Préférez faire l'inverse : calculez le TIMESTAMP des bornes à l'aide d'une fonction....
A +
S'il avait utilisé une vue dès le départ, il n'y aurait eu aucun impact sur le code client lors du refactoring de la table....
A +
Guillaume, pas exagéré !!! Vécu... 10 ans d'audit... 15 ans de BD et toujours les mêmes erreurs au final, l'absence du MED (Modèle Externe de Données) avec ses vues !
Par exemple quand on arrive à une table sensible dans une application vieillissante dont la clef est composée de 5 colonnes avec du varchar, qui pose 80% des problèmes de perf, et que l'on dit au client : la solution est de restructurer votre table avec une seule colonne clef et que cela impacte 30% du code applicatif parce que aucune vue n'a été créé.... Moi je me marre !
A +
Il est vrai qu'avec un trigger BEFORE c'est possible. Néanmoins il est toujours plus intéressant d'accéder aux données d'une base par des vues et le moins possible directement par les tables. Ceci pour des raisons diverses comme la facilité de refactoring des bases ou la meilleures réutilisation des plans de requête.
A +
Il suffit de faire un trigger INSTEAD OF INSERT sur la vue et de gérer les insertions de deux tables dans le trigger.
Ainsi vu du côté client vous ne faites qu'un seul INSERT directement sur la vue.
A +
Les littéraux ont besoin de plus de traitement que les numériques pour toutes comparaisons du simple fait de la gestion de la collation (sensibilité à la casse, aux accents...) qui induit un extra overhead systématique lors des comparaisons.
En sus les données de tailles variables, comme les VARCHAR, stockent la taille réelle de la données en sus soit 2 ou 3 octets supplémentaires.
Donc un VARCHAR(2) fait entre 4 et 5 octets, soit plus qu'un integer.
Enfin les VARCHAR sont plus complexes à retrouver, car étant, de par leur nature, avec une taille variable, il faut parcourir toutes les colonnes précédente de la ligne de la table pour en lire la valeur, ce qui n'est pas le cas des numériques qui sont de taille fixe et regroupés au début de la ligne physique de la table (slot) et directement accessible par un offset calculé par rapport au début de la ligne.
En conclusion, les numériques sont toujours systématiquement plus rapide dans tous les cas de figure et si vous voulez les meilleures performances, alors il faut prendre un entier de la taille exacte du mot du processeurs, soit INT sur 32 bits et BIGINT sur 64 bits, car vous n'aurez ni a gérer une double lecture (cas du BIGINT sur OS 32 bits => 100 % de durée supplémentaire en général) ni à vérifier les bits de poids haut pour renvoyer une erreur de dépassement de capacité (cas du INT sur OS 64 bits => de 2 à 5 % de durée supplémentaire).
A +
Un bon FillFactor dépend de 3 choses :
1) du pourcentage de données mises à jour (INSERT/UPDATE/DELETE) par rapport au volume global avant reconstruction de l'index
2) du volume des données
3) de la nature des données.
Par exemple au début de la vie de la base, les tables ont peu de données et le nombre de MAJ étant assez constant par unité de temps, la fragmentation va être importante, c'est pourquoi un FILL FACTOR assez faible est intéressant.
Si l'index est organisé en CLUSTER et que les données sont chrono ordonnées ce qui est le cas des auto incréments (SERIAL, SEQUENCE) ou de colonnes horodatées, alors la fragmentation sera très faible, voire voisine de zéro, sauf si certaines colonnes de la table sont en taille variables et que des UPDATE sur ces colonnes sont fréquents (déplacement de la ligne du fait de l'augmentation de la taille des données stockées) ou bien en cas de suppression.
Autrement dit, il est difficile de dire quel est le FILL FACTOR optimum sans auditer la fragmentation.
Ce que je peut vous dire, c'est qu'en début de vie d'une base un FF de 60 à 75 % avec défragmentation tous les jours peut être envisagé, sauf pour les CLUSTER. En fin de vie un FF de 80 à 95 % est souvent tout à fait approprié.
L'augmentation du volume de l'index n'est pas très important pour les performances, car le but des index est plus d'être lu en SEEK qu'en SCAN ce qui minimise les entrées de page d'index en mémoire de toute façons.
A noter, le split de pages évoqué par Marc Cousin n'est pas le seul mécanisme qui fragmente naturellement l'index. La suppression de ligne (DELETE) induit des slots fantômes et la mise à jour (UPDATE) est susceptible d'engendrer le déplacement des lignes (donc un SPLIT + 1 SLOT fantôme).
Pour de plus amples explications sur les phénomènes de fragmentation des index, lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/optimisati … exVLDB.pdf (en particulier chapitre 2)
Certes c'est pour SQL Server, mais les structures d'index et les algo étant similaires, les effets sont les mêmes sous PG.
A +
Pour le second point (performance du trigger), faites le test. L'argumentation de sqlpro sur ce point est assez sujette à caution, pour ne pas dire pire…
merci pour le commentaire !!! ;-)
Sérieusement, le problème des triggers PG c'est qu'il ne sont pas ensemblistes, il opèrent uniquement ligne à ligne (FORE EACH ROW) donc beaucoup moins rapide encore que ce que j'ai testé dans SQL Server....
Dès que j'ai du temps je ferais le test avec PG pour comparer ces mêmes contraintes en version PG !
A +
PS: tiens, la sauvegarde que vous décrivez ressemble beaucoup à la sauvegarde PITR de PostgreSQL (http://docs.postgresql.fr/9.0/continuous-archiving.html), si vous voulez continuer sur ce sujet, lancez un fil à côté
C'est normal, les mécanismes des journalisation des transactions des SGBDR sont tous basés sur le même algo de base : ARIES (sauf MySQL), suite aux travaux de Gray et Bernstein sur le sujet, vers la fin des années 70...
A lire :
http://portal.acm.org/citation.cfm?id=128770
http://www.cs.uwaterloo.ca/~david/cs448/aries-mohan.pdf
A +
Je ne voit pas ce qu'il y a de gonflant à comparer des techniques mise en œuvre. Chacune à ses limites, ses avantages et inconvénients.
Il s'agit juste de replacer l'outil à son usage et comprendre ce que font les autres permet de choisir ce qu'il y a de mieux.
Par exemple si la base de données doit en permanence subir des ordres DDL la sauvegarde PG sera un point bloquant.
Il faut donc, soit déporter ses commandes DDL à un moment hors sauvegarde, soit changer de SGBDR.
La plupart des SGBDR, y compris PG et SQL Server s'inspirent de réalisation déjà existantes pour s'améliorer...
Il n'y a donc aucune honte à montrer cela. Ce n'est pas du dénigrement, comme certains intégristes voudrait le faire croire.
PG a fait de grand progrès depuis que je le connais (c'est à dire depuis 1997 - à l'époque PostGres95)...
Et aujourd'hui, depuis la V9, c'est un SGBDR que je recommande pour un grande partie des applications de gestion non critique (c'est à dire la majeure partie)...
Par exemple dans ce post, j'ai commis le crime de défendre PG... http://www.developpez.net/forums/d10844 … se-donnee/
A +
C'est surtout aussi pour des raisons de performance... C'est beaucoup plus rapide dans les calculs sur des grosses bases.....
A +
Ordinairement lorsque l'on fait un DUMP on sépare les commandes en trois fichiers pour pouvoir reprendre facilement :
1) fichier contenant les CREATE basique des tables sans aucune contraintes (ni PK, ni FK, ni CHECK, ni UNIQUE, pas même NOT NULL et DEFAULT.....)
2) insertion basique des données (INSERT)
3) ALTER TABLE pour la pose de toutes les contraintes + CREATE INDEX.
C'est en outre ce qu'il y aura de plus rapide pour la reprise des données.
Il faudra bien entendu les lancer dans le même ordre :
1) CREATE
2) INSERT
3) ALTER + INDEX
C'est d'ailleurs ce que font les bons outils de modélisation comme Power AMC !
Vous pouvez l'utiliser pour ce faire sur la partie DDL en faisant une rétro ingéniérie de votre base.
A +
Comment font les autres utilisateurs qui sauvegarde a 3 heures du matin mais
un utilisateur a lancer une une grosse requete qui est en train de tourner ?
La sauvegarde à chaud est quelque chose de complexe. Par exemple elle n'est toujours pas implémentée sous MySQL.
Pour vous donner un exemple de ce que fais SQL Server qui possède un des algo les plus avancés sur le sujet, il procède de cette manière :
1) avant de démarrer la sauvegarde il met une marque dans le journal de transaction.
2) il sauvegarde les pages de données de manière binaire, sans aucun verrouillage en commençant par les pages les moins modifiées depuis les fichiers et en finissant par les pages les plus modifiées depuis la mémoire (pour calculer cela il conserve des statistiques en mémoire pendant toute la durée de vie du serveur, stats qui sont remise à zéro à chaque sauvegarde)
Les pages vides ou supprimées sont ignorées.
3) il sauvegarde le journal des transactions, depuis la marque qu'il a fait et jusqu'à la fin du journal.
Ainsi, aucun verrouillage ne ralentis la production. Seule les ressources utilisées par le processus de sauvegarde ralentissent globalement le serveur, et notamment les écritures disques des fichiers de sauvegardes.
Comme dans SQL Serveer les CREATE TABLE, ALTER et DROP sont journalisés, aucune transaction n'est perturbée !
Lors de la restaurations, le processus est le suivant :
1) recréation des fichiers originaux vide.
2) lecture des pages et replacement des pages dans les fichiers
3) lecture du journal de transaction et application des transactions validées.
Hélas, PG a encore du boulot pour arriver à ce niveau... Mais comparer à MySQL, y'a pas photo....
A +
Ah non, le moteur PG n'est pas ingres. C'est juste le même créateur, au départ.
Quelqu'un a déjà fait ce test sur PostgreSQL, sinon?
Oui, enfin, ce sont les mêmes prinipes, algo et tutti quanti qui sont mis en jeu...
Lisez ce que raconte Stonebraker dans ce livre : http://www.amazon.com/Readings-Database … 0262693143
A +
je me réponds partiellement à moi-même : dans certains cas les triggers sont quand même préférables
voir l'exemple de mon autre post, relatif à la désactivation des contraintes check : dans le cas où on n'a pas deux tables, mais une seule table avec une contrainte check "circulaire" (ie d'une colonne sur une autre de la même table), un problème se pose lors de la restauration, car à priori on ne peut pas désactiver les contraintes check
on est donc obligé dans ce cas d'utiliser des triggers, qu'on peut désactiver lors d'une sauvegarde / restauration
J'ai fait des tests sur SQL Server (pas sur PG) pour un livre à paraître aux US, sur la comparaison des contraintes complexes entre trigger et check avec fonction. La fonctions gagne dans 95% des cas par rapport aux triggers.
Comme le moteur PG est, à la base, le même (ingres) je pense que les résultats seraient similaires avec PG.
Mais dans le doute, seul un benchmark serait le bienvenu !
A +
Pourquoi ne stockez vous pas vos temps directement sous forme décimale ? Dans les applications, je stocke toujours les durées sous forme décimale avec des UDF de conversion en sexagésimale, uniquement pour l'affichage et la saisie. De ce fait il n'y a aucune erreur !
A +
Pas la peine de faire un trigger pour si peu: vous pouvez le faire simplement avec une contrainte check qui appelle une fonction. Évidemment, vous n'aurez pas les options 'CASCADE' par exemple.
Quelque chose comme CHECK ( verif_valide(toto_id))
Et définir la fonction verif_valide comme suit (non testé, mais c'est pour vous donner une idée de la chose):
CREATE FUNCTION verif_valide(int) RETURNS BOOLEAN LANGUAGE SQL AS $$
SELECT EXISTS (SELECT 1 FROM toto WHERE VALIDE=true AND id=$1;
$$;
Non, ta solution est fausse. Car que fais t-on si valide passe de true à false ?
En fait il n'existe aucun solution simple car il s'agit d'une contrainte dynamique. Ce serait possible si PG implémentait les assertions. Dans ce cas, l'ordre SQL serait :
CREATE ASSERTION A_TOTO_TOTI
AS
CHECK NOT EXIST(SELECT *
FROM titi
WHERE toto_id IN (SELECT id
FROM toto
WHERE valide IS TRUE));Malheureusement ce n'est pas possible et rare sont les SGBDR à la faire car cela pose des problèmes de performance...
La seule solution reste donc aux trggers et il en faut deux :
1 sur INSERT + UPDATE sur la table TITI
1 sur INSERT + UPDATE sur la table TOTO
A +
Oui, mais attention, ceci doit se faire au sein d'une seule et même session. Autrement dit, pas de déconnexion entre l'initialisation et la finalisation de la transaction.
En sus une transaction côté client (PHP) sera incommensurablement plus longue (donc plus bloquante) que si elle est effectuée côté serveur dans une fonction.
Pendant tout le temps de dialogue entre les serveur, les objets risquent d'être bloqués, provoquant des attentes pour les autres utilisateurs, voir des timeoiut, voir des verrous mortels....
Je vous invite à lire les articles que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sgbdr/#L3.2
http://sqlpro.developpez.com/cours/sqlaz/techniques/
http://sqlpro.developpez.com/isolation-transaction/
A +
Il n'y a aucun intérêt, sinon celui de pourrir sciemment les performances que de répartir la charge d'une même base de données sur plusieurs serveur. Même en plusieurs bases, cela a des conséquences (heureusement moins fortes).
Un SGBDR comme PG étant fortement sécurisé par le biais des utilisateurs SQL et des privilèges, il est possible que jamais les utilisateurs n'accèdent directement aux mots de passe.
Pour cela il suffit de bien gérer les privilèges et de passer par une procédure stockée (fonction dans PG) qui masque cette lecture.
De plus les volumes que PG est capable de supporter peuvent être de plusieurs centaines de Go. Dans une base de données de lien social, le lien entre deux individus n'étant qu'une paire de clef, on peut considérer que bien indexé cela ne représente au plus que 40 octets, pour gérer jusqu'à 2 milliards d'individus, et pour ce nombre, la table des liens fera donc : 75 Go ce qui est peu !
A +