Bonjour,

Je plussoie.

Cordialement,

Arkhena

Effectivement, tant que vous ne voyez pas tourner l'instance, c'est compliqué de faire de l'optimisation...

Je suis surprise que le lien que vous citez ne parle pas de modifier le paramètre min_wal_size...

Bref, Avant de vous lancer dans la modification de vm.dirty_background_bytes et de vm.dirty_bytes, settez les paramètres basiques et voyez la fréquence de vos checkpoints. S'ils ont lieu plus souvent que checkpoint_timeout, ajustez le paramétrage. Si ensuite vous avez des soucis et que vous identifiez que ces soucis sont liés aux checkpoints, vous pourrez jouer avec dirty_background et dirty_bytes.

Cordialement,

Arkhena

NB: De manière générale, les serveurs n'étant de nos jours plus trop pauvres en RAM,  je mets WAL_buffers à 16 Mo pour pouvoir avoir un fichier entier en mémoire...

Je plussoie!!!

Bonjour,

Copy vous permet de gérer les données pas les structures. Créez votre table d'abord.
(Assurez-vous également que le search_path comporte bien le schéma.)

Cordialement,

Arkhena

Bonjour,

Effectivement, dans le cas de petites bases avec peu de transaction, il y a des chances que ça marche. En faisant un start_backup, puis un stop_backup, vous augmentez les chances que ça se passe bien (mais assurez-vous de bien archiver vos WAL ailleurs). Dès que vous atteindrez un certain volume et un certain nombre de transactions, vos sauvegardes ne vaudront plus rien.

En tant que DBA, je ne prendrai jamais le risque de reposer sur de la chance pour mes sauvegardes.

Donc, mise en place de l'archivage continu et sauvegardes physiques régulières des bases avec l'outil prévu pour ça (barman ou backrest, mais il y en a d'autres).

À vous de voir quels sont vos objectifs de perte de données maximale admissible et durée maximale d'interruption admissible.

Cordialement,

Arkhena

Bonjour,

La sauvegarde logique ne vous donne que l'état des données à un instant T.
La sauvegarde physique vous permet de revenir au plus près de vos données (si vous avez les WAL correspondant).

Prenons un exemple:
- Vous faites une sauvegarde logique toutes les nuits à 2h00
- Vous avez un crash à 10h00
-> Votre restauration vous fera perdre toutes les transactions commitées entre 2h00 et 10h00.

- Maintenant, vous faites une sauvegardes physique à 2h00 tous les matins. De plus vous avez mis en place l'archivage des Wal
- Vous avez un crash à 10h00
-> Votre restauration ne vous fera perdre aucune transaction commitée

De plus, la sauvegarde physique vous permet de faire du PITR (Point In Time Recovery).
Imaginons le scénario suivant:
Le développeur se trompe et envoie un DELETE sans la clause WHERE sur la base de production. Il committe sa transaction avant de se rendre compte de son erreur.
La sauvegarde logique fera là encore perdre tous les changements commités entre la date et l'heure de la sauvegarde et la date et l'heure de l'incident.
La sauvegarde physique permet de revenir juste avant l'erreur du développeur.

Enfin, de manière générale, la sauvegarde/restauration physique dure moins longtemps que son homologue logique (cet argument n'est bien sûr valable que pour les bases conséquentes).

Cordialement,

Arkhena

Ok, cela fait partie des trucs qu'on m'a dits il y a très longtemps et que j'ai intégrés sans me poser de questions (shame)...
Je viens de vérifier et effectivement, rien dans la doc ne va dans ce sens...

J'ai trouvé un forum (mais après de longues recherches) où un gars va dans ce sens (http://serverfault.com/questions/110154 … ew-install) mais sans l'étayer de preuves formelles, donc ça n'a pas de valeur...

Bonjour,

Cela se paramètre dans le fichier postgresql.conf.
Vous trouverez toutes les informations nécessaires sur cette page: https://www.postgresql.org/docs/9.6/sta … gging.html
Regardez notamment le paramètre log_filename.

Cordialement,

Arkhena

Bonjour,

Je ne suis pas fan des triggers qui ralentissent le DML...

Je vais donc commencer par répondre à côté (et je m'en excuse, vous êtes libres de sauter ce paragraphe):
A priori, ce que je comprends de votre besoin, c'est que vous voulez empêcher les DELETE physiques pour les remplacer par des DELETE logiques. Dans ce cas, pourquoi ne pas faire un REVOKE du droit de DELETE sur cette table (ou cet ensemble de données) pour imposer de faire des UPDATE permettant un DELETE logique ? Vous trouverez les informations sur le REVOKE ici: https://www.postgresql.org/docs/9.6/sta … evoke.html

Sinon, vous pouvez créer un trigger INSTEAD OF. Vous trouverez la documentation ici: https://www.postgresql.org/docs/9.6/sta … igger.html

Cordialement,

Arkhena

Bonjour,

Vous pouvez aussi créer vos requêtes d'insertion sous Excel en utilisant la fonction de concaténation et en copiant vers le bas sur toutes les lignes.

Cordialement,

Arkhena

Bonjour,

Qui est propriétaire du répertoire /data/pgsql/donnees?
Quel user utilisez-vous pour démarrer le serveur ?

Cordialement,

Arkhena

C'est pour ça que j'utilise proargtypes  qui correspond à la signature... :-)

Je dois juste dropper une cinquantaine de fonctions sur une soixante-dizaine de schémas... J'aurai voulu générer mon script par un programme...