D'après ce que j'avais compris ... Cela ne remplace pas l'export régulier dans les cas ou il y a beaucoup de volume, et quand une partie d'une grosse table est flinguée, on ne veut pas TOUT restaurer c'est trop long
Justement, ça permet de faire des restauration partielles de tables. Exemple avec leur fameuse table EMP :
INSERT INTO EMP
(SELECT *
FROM EMP AS OF TIMESTAMP
TO_TIMESTAMP('2005-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')
WHERE name = 'JOHN');
Sachant qu'une procédure de restauration/recovery DOIT être simple ... car en situation de stress c'est pas évident de réfléchir
Il y a toujours un compromis à trouver entre la restauration simple et bourrine qui revient sur la connerie faite par un utilisateur en écrasant le travail réalisé par ailleurs, et le travail dans la dentelle.
Et c’est sûr que l’urgence est mauvaise conseillère : l’idéal est de pouvoir remonter les données suspectes à leur dernier état sain connu dans des tables de travail, puis de faire les remplacements avec délicatesse...
[^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand
Posté par Thierry Thomas (site web personnel, Mastodon) . En réponse au journal De l'importance (des tests réguliers) des sauvegardes. Évalué à 2.
Justement, ça permet de faire des restauration partielles de tables. Exemple avec leur fameuse table EMP :
INSERT INTO EMP(SELECT *
FROM EMP AS OF TIMESTAMP
TO_TIMESTAMP('2005-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')
WHERE name = 'JOHN');
Il y a toujours un compromis à trouver entre la restauration simple et bourrine qui revient sur la connerie faite par un utilisateur en écrasant le travail réalisé par ailleurs, et le travail dans la dentelle.
Et c’est sûr que l’urgence est mauvaise conseillère : l’idéal est de pouvoir remonter les données suspectes à leur dernier état sain connu dans des tables de travail, puis de faire les remplacements avec délicatesse...