Avant même le flashback on pouvait restaurer une table, la manipulation était lourde (en 12c elle est simplifiée), les exports/imports n'étaient pas fiables, datapump est devenu consistent mais n'apporte strictement rien pour une sauvegarde.
C'est vrai j'oublie que notre ERP utilise de manière très basique la base de données, en gros il n'y a que des tables, des séquences plus quelques vues et roles. Les contraintes d'intégrité sont gérées à part.
Je croyais que l'export était consistent depuis la v8 (d'ailleurs il y avait une option pour cela)
Quels problèmes as tu rencontré avec les exports / imports ? le renommage des TBS ? le volume des données ? ou autre ?
cela m’intéressent beaucoup
Par contre pour nous c'est un élément de la sauvegarde, car dans certains cas tordus nos devs préfèrent que l'on remonte une table d'un export (même de la veille) pour qu'ils puissent refaire la (ou les) table(s) endommagée(s)
C'est même certainement la restauration la plus courante chez nous ...
[^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand
Posté par Christophe B. (site web personnel) . En réponse au journal De l'importance (des tests réguliers) des sauvegardes. Évalué à 2.
C'est vrai j'oublie que notre ERP utilise de manière très basique la base de données, en gros il n'y a que des tables, des séquences plus quelques vues et roles. Les contraintes d'intégrité sont gérées à part.
Je croyais que l'export était consistent depuis la v8 (d'ailleurs il y avait une option pour cela)
Quels problèmes as tu rencontré avec les exports / imports ? le renommage des TBS ? le volume des données ? ou autre ?
cela m’intéressent beaucoup
Par contre pour nous c'est un élément de la sauvegarde, car dans certains cas tordus nos devs préfèrent que l'on remonte une table d'un export (même de la veille) pour qu'ils puissent refaire la (ou les) table(s) endommagée(s)
C'est même certainement la restauration la plus courante chez nous ...