Vous n'êtes pas identifié(e).
Bonjour Messieurs,
Ok, je vais tenter l'utilisation de COPY en premier.
Merci.
Bonjour,
Je travaille sous CenOS 5.9 avec un moteur PostgreSQL 9.2.4.
Je cherche un moyen pour transférer RAPIDEMENT (je ne peux bloquer plus d'un quart d'heure les 2 serveurs en production) une partie des données d'une table d'une base de données sur un serveur (4 millions de lignes), vers une autre table d'une autre base de données d'un autre serveur (avec quelques modifications de champ à la volée).
Quelle solution préconisez-vous ?
D'avance merci.
Bonjour Guillaume,
Que dois-je faire pour pouvoir utiliser pgstat ?
Merci.
Bonjour Guillaume,
Retour de la commande :
[postgres@mon_serveur pgstats-master]$ git log -1 --pretty=oneline
-bash: git : commande introuvable
Concernant la récupération de gleu/pgstats, j'ai téléchargé pgstats-master.zip, décompressé sur PC cela donne un répertoire, que j'ai copié sur mon serveur, puis make.
Guillaume,
C'est une commande linux ? pas de souci à l'exécuter sur une machine de prod ?
Bonjour à tous,
Le message complet du make :
[postgres@mon_serveur pgstats-master]$ make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -I/usr/local/pgsql/include -I. -I. -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -c -o pgcsvstat.o pgcsvstat.c
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv pgcsvstat.o -L/usr/local/pgsql/lib -lpgport -L/usr/local/pgsql/lib -lpq -L/usr/local/pgsql/lib -Wl,--as-needed -Wl,-rpath,'/usr/local/pgsql/lib',--enable-new-dtags -lpgport -lz -lreadline -lcrypt -ldl -lm -o pgcsvstat
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -I/usr/local/pgsql/include -I. -I. -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -c -o pgstat.o pgstat.c
pgstat.c: In function 'main':
pgstat.c:1600: attention : implicit declaration of function 'pqsignal'
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv pgstat.o -L/usr/local/pgsql/lib -lpgport -L/usr/local/pgsql/lib -lpq -L/usr/local/pgsql/lib -Wl,--as-needed -Wl,-rpath,'/usr/local/pgsql/lib',--enable-new-dtags -lpgport -lz -lreadline -lcrypt -ldl -lm -o pgstat
La commande rpm -qa |grep postgresql me retourne : postgresql-libs-8.4.13-1.el6_3.x86_64
Bonjour Julien,
Merci pour votre retour.
La commande pgconfig me retourne :
BINDIR = /usr/local/pgsql/bin
DOCDIR = /usr/local/pgsql/share/doc
HTMLDIR = /usr/local/pgsql/share/doc
INCLUDEDIR = /usr/local/pgsql/include
PKGINCLUDEDIR = /usr/local/pgsql/include
INCLUDEDIR-SERVER = /usr/local/pgsql/include/server
LIBDIR = /usr/local/pgsql/lib
PKGLIBDIR = /usr/local/pgsql/lib
LOCALEDIR = /usr/local/pgsql/share/locale
MANDIR = /usr/local/pgsql/share/man
SHAREDIR = /usr/local/pgsql/share
SYSCONFDIR = /usr/local/pgsql/etc
PGXS = /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk
CONFIGURE =
CC = gcc
CPPFLAGS = -D_GNU_SOURCE
CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv
CFLAGS_SL = -fpic
LDFLAGS = -Wl,--as-needed -Wl,-rpath,'/usr/local/pgsql/lib',--enable-new-dtags
LDFLAGS_EX =
LDFLAGS_SL =
LIBS = -lpgport -lz -lreadline -lcrypt -ldl -lm
VERSION = PostgreSQL 9.2.4
Et non, pas de fichier pgsignal.h dans le répertoire /usr/local/pgsql/include/libpq.
Comment voir si j'ai les bibliothèques de développement ?
Bonjour Guillaume,
Sous Cent-OS 6.4 et PostgreSQL 9.2.4.
J'essaye d'installer pgstats avec la commande MAKE
J'obtiens le message suivant :
pgstat.c: In function 'main':
pgstat.c:1600: attention : implicit declaration of function 'pqsignal'
Pouvez-vous m'aider, svp ?
Bonjour Julien,
Si, si, ensuite je veux déclencher ce type de requête à intervalle régulier.
Est-ce que l'on peut attaquer des bases sur différentes machines avec dblink ?
Merci pour votre retour.
Bonjour,
J'ai installé pgAgent sur mon PC (Win7-64Bits, PostgreSQL 9.3, pgAdmin 1.18.1) par l'intermédiaire de Application Stack Builder. Tout est OK.
Je voudrais faire une requête sur un serveur distant (Cent-OS 5.9, PostgreSQL 9.3) et stocker le résultat dans la BD de mon PC.
Je voudrais donc un Step du style : INSERT INTO MON_PC.MA_BASE.MA_TABLE (SELECT champ1, champ2 FROM MON_SERVEUR.MA_BASE.MA_TABLE);
Est-ce faisable ? ou faut-il utiliser une autre technique ?
Bonjour Guillaume,
Les temps de réponse sont pour nous correctes, nous n'avons pas d'alerte ni de plainte des utilisateurs.
Pouvez-vous au moins me dire si l'inquiétude doit être réelle ? faut-il mener une action ?
Merci pour votre analyse.
Bonjour Guillaume,
La configuration est la suivante :
Cent-OS 6.4, 32Go de RAM, disques : sda 300Go 10000 tours FS ext4 en mirroir supportant OS + Moteur + TRACES, sdb 150Go 15000 tours FS ext4 en mirroir supportant les DATA, sdc 150Go 15000 tours FS ext4 en mirroir supportant les XLOG.
PostgreSQL 9.3.2, max_connections = 300, shared_buffers = 8192MB, work_mem = 10MB, maintenance_work_mem = 4096MB, checkpoint_segments = 64, checkpoint_timeout = 10min, effective_cache_size = 21840MB.
La base de données fait 14.86Go, la plus grosse table avec ces indexes 11.21Go.
Chaque nuit, nous faisons un export de la base.
Chaque dimanche un vacuum full analyze suivi d'un reindex full.
Les statistiques ne sont jamais réinitialisées.
Le fait d'écrire un maximum de traces peut-il avoir une influence ? nous écrivons 1 fichier trace par heure sur 7 jours, la taille moyenne de ce fichier est de 25Mo.
Nous avons également un outil exécuté à la demande (agrégation de données suivant différents critères) qui génère des fichiers temporaires sur 2 requêtes :
1) appelée 140 fois sur la semaine dernière, 13Mo de fichiers temporaires par appel
2) appelée autant de fois, de 10 à 300Mo de fichiers temporaires par appel en fonction des critères.
Voilà les infos que je peux vous donner.
Bonjour Guillaume,
Ci-dessous le résultat de l'exécution de "pgstat -s database -h localhost -p 5432 -U postgres -d geo 600 36" lancé ce matin à 8h (tout ce qui a eu lieu).
- backends - ------ xacts ------ -------------- blocks -------------- -------------- tuples -------------- ------ temp ------ ------- misc --------
commit rollback read hit read_time write_time ret fet ins upd del files bytes conflicts deadlocks
116 62667070 1021866 780798564 -1724966436 0 0 1036952403 -2100971209 140440282 64152880 50238910 4905 -2076033748 0 0
117 2866 7 18273 5205563 0 0 12890565 6176230 2989 260 1885 0 0 0 0
117 2228 1 208 1506250 0 0 4387706 2282211 1515 4166 829 3 44556288 0 0
119 3235 0 6230 1381983 0 0 10495604 9959448 2659 386 1607 0 0 0 0
117 2778 6 106 1338849 0 0 3642857 965869 3259 553 2091 0 0 0 0
122 3297 2 6416 2008136 0 0 38174376 1644245 2328 1874 1051 0 0 0 0
123 3617 0 96 1470061 0 0 19150577 2011722 2912 426 1616 1 12787712 0 0
124 4673 7 207 2430493 0 0 29280004 2137002 4046 2289 2381 2 25575424 0 0
129 3654 0 838 2344306 0 0 17024838 1489403 6842 13074 384 2 31768576 0 0
130 4627 1 295 2375126 0 0 14999212 1788435 4149 4490 2053 0 0 0 0
133 3635 6 582 1956167 0 0 29699306 2375048 17226 16596 2333 2 25575424 0 0
128 3190 1 195 763102 0 0 1969741 1170803 2028 2715 66 0 0 0 0
131 4131 1 1131 7027385 0 0 31521146 10017023 14198 9828 2206 0 0 0 0
133 3583 7 167 3235014 0 0 12167972 4440983 6425 3269 1891 0 0 0 0
129 3171 0 152 794621 0 0 5551380 4265262 2224 336 699 2 31768576 0 0
132 4639 1 157 2166058 0 0 8869797 4206843 5294 1454 2230 1 22224896 0 0
133 3448 6 49548 1897220 0 0 9262109 8274324 1784 560 362 3 45080576 0 0
137 4327 1 169 898598 0 0 16895576 1267621 4006 1178 2306 1 12787712 0 0
136 4079 1 517 2520267 0 0 46515918 13475128 11766 15900 1900 0 0 0 0
136 3390 7 120 1884020 0 0 21614976 1483029 2134 1184 742 2 25575424 0 0
134 4353 0 672 3199981 0 0 59556380 2385774 21007 19694 2089 2 31768576 0 0
133 3777 1 393 2216931 0 0 10124941 1142114 3308 7801 1752 0 0 0 0
130 3986 6 613 2851846 0 0 23086720 2722556 10847 14478 1030 0 0 0 0
129 3522 1 296 1861231 0 0 2734813 1567914 2981 5015 1428 1 12787712 0 0
129 4182 1 1048 3353941 0 0 80455912 1691901 30804 35626 2215 0 0 0 0
132 4485 7 745 3239114 0 0 84782158 2638797 29155 18082 1234 3 45244416 0 0
131 3994 0 90 1631796 0 0 3522389 1744780 2797 633 1380 2 28139520 0 0
134 3269 1 84 1659407 0 0 2268146 1404724 2497 438 1194 1 12787712 0 0
129 3777 6 883 1433209 0 0 2148366 1272089 3166 847 1302 0 0 0 0
129 3795 1 2376 1557558 0 0 5908336 1316736 3566 598 2241 0 0 0 0
131 2946 1 101 1093563 0 0 1370378 612119 2357 210 829 0 0 0 0
130 3790 14 93 1471737 0 0 2400263 914007 3376 593 1898 0 0 0 0
131 3603 0 88 985765 0 0 3178593 1930041 3169 565 2018 1 15351808 0 0
131 3260 8 88 2507415 0 0 21466543 16671828 2084 412 556 0 0 0 0
133 4174 6 167 1440929 0 0 5982096 657790 4174 420 2319 0 0 0 0
135 3929 1 139 1352136 0 0 3723485 1679173 3588 1186 1732 1 12787712 0 0
Ci-dessous le résultat de l'exécution de "pgstat -s bgwriter -h localhost -p 5432 -U postgres -d geo 600 36" lancé ce matin à 8h (tout ce qui a eu lieu).
------------ checkpoints ------------- ------------- buffers ------------- ---------- misc ----------
timed requested write_time sync_time checkpoint clean backend alloc maxwritten backend_fsync
50446 2 1672102325 246903 19637645 35952 12933553 127406553 239 0
1 0 50332 7 503 0 562 18273 0 0
1 0 62558 6 626 0 379 208 0 0
1 0 61654 7 615 0 444 6229 0 0
1 0 49126 6 491 0 675 107 0 0
1 0 95323 5 953 0 432 6416 0 0
1 0 56746 10 568 0 470 96 0 0
1 0 82900 7 828 0 818 205 0 0
1 0 97632 5 977 0 320 844 0 0
1 0 133506 5 1333 0 1113 298 0 0
1 0 119378 13 1196 0 1186 602 0 0
1 0 119776 7 1197 0 191 168 0 0
1 0 114464 8 1144 0 921 1132 0 0
1 0 70670 9 708 0 224 167 0 0
1 0 86704 7 867 0 697 153 0 0
1 0 83599 9 835 0 709 155 0 0
1 0 79996 11 798 8 187 49548 0 0
1 0 85105 9 850 0 722 171 0 0
1 0 118682 5 1187 0 631 483 0 0
1 0 130804 3 1306 0 649 143 0 0
1 0 0 0 1463 0 1213 686 0 0
1 0 157259 3 1568 0 832 390 0 0
1 0 148242 4 1484 0 867 610 0 0
1 0 213496 6 2137 0 650 299 0 0
1 0 148737 5 1488 0 1615 1048 0 0
1 0 305711 6 1588 0 943 715 0 0
1 0 0 0 1453 0 507 90 0 0
1 0 277534 6 1319 0 300 88 0 0
1 0 85302 5 854 0 515 879 0 0
1 0 90433 5 903 0 702 2374 0 0
1 0 70675 4 707 0 144 102 0 0
1 0 73680 2 736 0 758 94 0 0
1 0 82793 3 826 0 608 89 0 0
1 0 74383 4 743 0 229 89 0 0
1 0 87702 4 877 0 746 196 0 0
1 0 111054 5 1110 0 502 110 0 0
1 0 91615 5 915 0 318 126 0 0
Bonjour Guillaume,
Ci-dessous le résultat de l'exécution de pgstat -s database, entre 9h30 et 14h00.
- backends - ------ xacts ------ -------------- blocks -------------- -------------- tuples -------------- ------ temp ------ ------- misc --------
commit rollback read hit read_time write_time ret fet ins upd del files bytes conflicts deadlocks
90 62285286 1018383 779780505 1886651224 0 0 -1634587321 337229365 139972928 63834815 49909835 4799 727170348 0 0
90 2672 1 1413 1691245 0 0 2877916 898087 1596 407 827 1 15351808 0 0
94 3953 5 849 2341810 0 0 22678845 19328412 2679 1602 1508 0 0 0 0
95 5496 1 313 3064589 0 0 11119367 2279581 3803 3328 2520 1 12787712 0 0
101 3003 2 111 1219584 0 0 10455479 1286876 2133 2016 1058 1 12787712 0 0
103 3584 0 9751 1610034 0 0 26280002 2709627 2690 3178 1372 0 0 0 0
101 3470 7 270 1357361 0 0 3275358 2008902 4043 3449 2374 1 12787712 0 0
105 3127 1 1416 4159083 0 0 23051002 8887199 1346 6904 170 2 28139520 0 0
104 4428 5 8284 3653189 0 0 68072807 8239907 5257 5373 2393 5 74825728 0 0
108 3973 1 542 2938568 0 0 49247516 4083653 15370 16468 2174 1 12787712 0 0
109 4018 1 825 2062025 0 0 21221041 3155162 2234 5243 57 0 0 0 0
110 5230 1 868 4001613 0 0 52724664 6935993 27767 27330 2183 0 0 0 0
118 4015 7 119 1925693 0 0 11095999 2242938 3391 662 1661 1 12787712 0 0
119 3957 0 408 3252257 0 0 36502381 23010516 16267 10575 914 4 57344000 0 0
116 4795 6 170 11917524 0 0 37463404 35305096 5684 1483 2339 2 32833536 0 0
115 3318 1 82 5932096 0 0 16105320 14297391 1812 612 169 0 0 0 0
113 3832 1 145 4238698 0 0 14807865 9822398 5192 1865 2266 0 0 0 0
113 3835 1 208 2299132 0 0 11326862 3482203 3250 2690 1512 2 32833536 0 0
117 3705 7 302 11693487 0 0 38690144 34424724 6869 5627 1028 2 25575424 0 0
118 3387 0 9509 4807710 0 0 16361653 13861136 6909 3003 1718 4 57344000 0 0
118 4475 6 155 2789898 0 0 55737846 6712421 3997 920 2181 1 12787712 0 0
115 3607 1 110 1661475 0 0 5606692 3907622 2762 1241 849 3 38363136 0 0
121 4682 1 2299 2597198 0 0 8588015 5589749 3265 4132 1401 4 39772160 0 0
120 5480 1 809 4623199 0 0 26282878 8899716 16587 23789 2192 4 51150848 0 0
120 4637 7 295 3338287 0 0 25708436 5436817 5838 5419 717 1 12787712 0 0
112 4564 0 694 21378142 0 0 76312278 45253018 23131 23751 1880 3 33087488 0 0
123 4843 6 337 14396172 0 0 141559503 32403821 14274 8451 1358 4 51150848 0 0
119 3809 1 8566 17710632 0 0 56781912 55315858 2553 1064 1159 3 31375360 0 0
123 3599 1 84 5378015 0 0 19721536 15237423 3534 863 2246 2 25575424 0 0
129 4108 8 96 8485486 0 0 28197447 16823116 2107 887 370 2 11730944 0 0
129 4159 7 139 14392825 0 0 31743005 30292882 3805 817 2370 0 0 0 0
132 3721 7 96 6833793 0 0 18600751 17535521 3741 706 2219 1 15351808 0 0
135 3751 6 102 4198172 0 0 13930888 8376580 2272 832 517 0 0 0 0
135 4097 1 161 10539580 0 0 28196901 27533267 4484 938 2176 0 0 0 0
137 4235 1 132 26823171 0 0 65662727 64657153 3491 785 1401 2 25575424 0 0
136 3962 1 126 4613835 0 0 12227439 11382508 2851 785 869 1 6750208 0 0
J'espère que l'échantillon est représentatif, sinon je peux le relancer.
Bonjour Guillaume,
Je ne trouve pas de doc sur l'installation et l'utilisation de l'outil.
Avez-vous un lien à me donner ?
Est-ce que je peux l'installer et l'utiliser sans risque sur une base en production ?
Merci.
Bonjour à tous,
Meilleurs vœux pour cette nouvelle année qui commence.
Je me permets un dernier up afin d'obtenir de l'aide pour régler ce problème.
D'avance merci.
Bonjour Guillaume,
Mais alors le fait que les buffers_backend ne soient pas "très fortement supérieurs" aux buffers_checkpoint et buffers_clean est-il inquiétant ?
Je ne comprend pas pourquoi le hit ratio reste si haut si de plus en plus de lectures se font sur disque ?
Désolé d'être insistant.
Bonjour Guillaume,
Pour le 1er point, je ne comprend pas, il y a également 20 utilisateurs qui font 150000 insert. Pouvez-vous m'expliquer ?
Pour le 2ème point, nous avons :
Quelques tables avec des "données statiques" (moins de 400Mo pour l'ensemble des tables avec leurs indexes),
Deux tables avec des "données dynamiques" (tables avec horodatage purgées cycliquement sur une période de 3 mois, volume 1,5Go tables+indexes). Les 20 utilisateurs qui font les 150000 inserts le font dans ces tables.
une table qui grossit au fil du temps (12Go aujourd'hui table+indexes). L'utilisateur qui fait les 150000 inserts le fait sur cette table et les 150000 update sur les 2 tables précédentes.
Donc se ne sont pas toujours les mêmes données.
Bonjour Guillaume,
Désolé de reprendre ce post un peu tardivement, mais d'autres priorités :-(
Donc mon hit ratio reste à plus de 96%.
Concernant le nombre de connexions :
20 utilisateurs qui font en moyenne par jour (7h-17h) : 150000 insert, 25000 update, très peu de select
75 utilisateurs qui font en moyenne par jour (7h-17h) : 40000 select, 50000 appels à des procédures stockées, 40 insert, 15 update
1 utilisateur qui fait en moyenne chaque jour à 5h : 90000 select, 150000 insert, 150000 update
10 utilisateurs en moyenne par jour qui font un peu de select/insert/update/delete en cours de journée
20 utilisateurs en moyenne par jour qui font quelques "gros select" au cours de la journée
Pour les checkpoints, toutes les 10min (checkpoint_timeout), aucun warning, moins d'une dizaine de fichiers recyclés à l'heure.
Reste que les buffers_backend ne sont pas "très fortement supérieurs" aux buffers_checkpoint et buffers_clean. C'est la 1ère chose qui m'inquiête.
La 2ème chose qui m'inquiête ce n'est pas trop le volume des écritures, qui a certes augmenté mais comme nous avons intégré les données et traitements de différents sites dans cette base "centralisée" je pense que c'est normal. Par contre le volume des lectures a très fortement augmenté. Cela veut bien dire que davantage de données doivent être lu sur disque et pas en mémoire ? le hit ratio ne devrait-il pas se dégrader ?
Bonjour Guillaume,
Ok, merci, je vais gérer :-)
Bonjour,
Ok, je laisse tomber l'idée de faire du dump/restore par trigger.
Je regarde pour écrire moi même une fonction en utilisant les informations du catalogue système et autres.
En utilisant la commande : CREATE TABLE nom_table (LIKE modele.table INCLUDING ALL); la duplication se fait bien MAIS, par exemple, le nom de la clé primaire ou d'un index est différent de l'original.
Pourquoi ?
Guillaume,
Cette table des clients ne contiendra pas plus d'une centaine de lignes.
Sinon, avec le dump/restore, est-il possible de faire exécuter ces commandes par une fonction Trigger ?
Bonjour Messieurs,
Guillaume, oui c'est bien ça, faire un insert dans une table, tout simplement.
C'était pour que le User (non DBA), puisse ajouter un schéma (client) et sa structure dans la base, lorsqu'un nouveau client arrive, sans avoir besoin de nous.
Sinon, avec le dump/restore, est-il possible de faire exécuter ces commandes par une fonction Trigger ?
Bonjour Guillaume,
La solution du dump/restore ne me convient pas dans le cas présent.
Je voudrai qu'un User (non DBA), puisse ajouter dans une table CLIENTS du schéma public des informations liées au client, notamment un nom et un "modèle" (structure d'un schéma prédéfini).
Et ensuite par un système de trigger sur la table CLIENTS, déclencher la duplication de la structure "modèle" dans un nouveau schéma au nom du client.
Il n'existe donc "rien", pas de projets, sur ce style d'exercice ?
Merci.
