Flashback query sur erreur humaine (DELETE)

Initialiser un cluster, gérer les accès, modifier les paramètres par défaut, interroger le catalogue avec psql ou pgAdmin, déplacer les données avec pgdump etc.
Répondre
Phil
Administrateur du site
Messages : 288
Enregistré le : mar. 1 sept. 2015 00:38
Localisation : France
Contact :

Flashback query sur erreur humaine (DELETE)

Message par Phil »

Merci à un administrateur Oracle pour sa question :

"Bonjour, avec Oracle j'ai déjà réussi à récupérer des informations supprimées (DELETE) par erreur grâce une flashback query, est-ce possible avec PostgreSQL ?"

Réponse :

Oui, l'utilisation n'est pas aussi générale qu'avec les flashback queries mais vous pouvez utiliser pg_dirtyread https://github.com/df7cb/pg_dirtyread , cet outil fait par exemple l'objet d'un package présent dans le repository Debian, ce qui le rend simple à déployer.
Avec Oracle, vous vous exposez à une ORA-1555 si les données d'annulation ne sont plus disponibles. De même, avec PostgreSQL, cela ne fonctionnera pas si la table a fait l'objet d'un vacuum automatique ou manuel.
Cdlt. Phil - pgphil.ovh
Phil
Administrateur du site
Messages : 288
Enregistré le : mar. 1 sept. 2015 00:38
Localisation : France
Contact :

Re: Flashback query sur erreur humaine (DELETE)

Message par Phil »

Les "flashback" Oracle recouvrent des fonctionnalités très différentes :
- Il n'y a pas d'équivalent dans PostgreSQL de la recycle bin d'Oracle qui permet de faire des "flashback table to before drop"
- Il n'y a pas d'équivalent direct dans PostgreSQL de "flashback database" même si pg_rewind s'en rapproche pour certaines utilisations
- Il n'y a pas d'équivalent direct dans PostgreSQL de "flashback query" même si pg_dirtyread s'en rapproche, à condition de configurer PostgreSQL pour retarder les vacuum

De manière générale, ces "flashback" permettent de se passer de faire une restauration dans certains cas mais ils présentent aussi des inconvénients et ne s'appliquent pas dans tous les cas.
il est de toute façon obligatoire d'avoir une "vraie" sauvegarde, par exemple avec pgBackrest pour les clusters PostgreSQL. Un export réalisé via pg_dump est obligatoire pour les bases en "noarchivelog" au sens Oracle, c'est un plus dans tous les cas.
Cdlt. Phil - pgphil.ovh
Répondre