Discussion :

[LeoAnderson]

oui mais restaurer un seul fichier t'expose à des problèmes d'intégrité de données... si tu as les contrats dans un fichier et les clients dans un autre fichier, il vaut mieux restaurer les 2 Wink

Oui, mais tu n'es pas obligé de restaurer le TBS de la cantine ! :-)

[ducho]

Des que nous aurons notre gestionnaire de sauvegardes, nous mettrons en place les archive logs et la stratégie de sauvegarde sera :
sauvegarde à froid le week-end
sauvegarde à chaud incrémental tous les soirs ( avec Rman...)
export full tous les soirs
mise en place archive logs pour les applications critiques

si avec tout ça , on s' en sort pas ....

cdlt

[Marc Musette]

comment peut-on comparer export et backup en archivelog mode !?!?!?

l'export n'est pas une méthode de backup physique des données, c'est un backup logique !

je me permets de vous rappeler qques points essentiels et de base:

- backup physique:
1) cold backup : db est arrêtée et on copie les fichiers
--> ne permet pas de point in time recovery
--> nécessite de restaurer toute la db en cas de problème
--> fonctionne en NOARCHIVELOG mode
2) hot backup : db est toujours accessible et on copie les fichiers
--> seul moyen d'avoir du point-in-time recovery
--> permet dans certains cas de ne restaurer que le fichier endommagé
--> nécessite l'archive log mode

le hot backup est réalisé via RMAN ou via des scripts mettant les tablespaces en mode BEGIN/END backup

l'export lui ne fait qu'exporter le contenu des schémas de la db
il offre une foule d'avantage (restaurer une seule table par exemple)
mais ne constitue pas une méthode de backup (il faut effectivement tout réinstaller, reconfigurer etc) ; de plus pas de point-in-time recovery et surtout possibilité d'une db inconsistante !!!

export et backup sont deux choses complémenataires dans un environnement OLTP

le sondage n'est pas très parlant selon moi ... la méthode de backup est adaptée aux SLA de chaque db/applic

effectivement c'est intéressant de savoir si lors de backup "à chaud" as you say in France ; le dba utilise rman (c'est tellement facile !!!) plutôt que des os scripts (c'est tellement souple!!!)

sur la centaines de db que j'ai, j'utilise un peu de tout (export pour le test, cold backup pour l'acceptation, hot backup pour la pré prod et la prod avec rman ou non) et même de la standby (physique seulement)

d'ailleurs là, pour l'instant, je suis entrain de migrer cette standby de v7 vers 9.2 ainsi que 7 autres db ... cross fingers...

dès que j'ai un peu de temps je mets tout cela en article (les backups, la standby etc)

[orafrance]

oui mais restaurer un seul fichier t'expose à des problèmes d'intégrité de données... si tu as les contrats dans un fichier et les clients dans un autre fichier, il vaut mieux restaurer les 2

donc, de ce point de vue, la sauvegarde à chaud n'est pas meilleure que l'export

Qui dit sauvegarde à chaud dit archivage, donc récupération de la base et synchronisation des fichiers possibles.
Ou alors je comprends mal ce que tu veux dire..

je parle du sauvegarde à froid dans ce cas bien sûr

Sinon, une sauvegarde à chaud en RESETLOG peut permettre (si j'ai bien compris ) de synchroniser les datafiles sans rejouer les redos risque de perte d'intégrité des données

[orafrance]

l'export lui ne fait qu'exporter le contenu des schémas de la db
il offre une foule d'avantage (restaurer une seule table par exemple)
mais ne constitue pas une méthode de backup (il faut effectivement tout réinstaller, reconfigurer etc) ; de plus pas de point-in-time recovery et surtout possibilité d'une db inconsistante !!!

tout à fait d'accord... une restore FULL avec un dump est beaucoup plus long qu'avec une sauvegarde des datafiles

[Marc Musette]

mais surtout, tu ne sais pas faire de point in time recovery , par exemple : revenir une minute avant un delete indésirable

[orafrance]

c'est clair

[aline]

et il existe encore une autre possibiliée très interessante que vous n'avez pas abordé:

Les bases de standby qui permettent d'avoir une base de secour immediatement en cas de gros problèmes. Cela peux être important aussi de pouvoir redémarrer une base en prod tout de suite et aprèe de commencer à voir comment on récupère notre première base cassée.
Evidement, cela ne dispense pas de faire des export ou des hots backup mais cela rassure.

Une solution stanby physique + export peut s'avérer très simple et performante.

[LeoAnderson]

Mais là, a mon avis, on sort de la problématique de pérénisation des données et on s'intérêsse à ne perdre ni les données, ni l'exploitation...
La standby est certes très intérêssante, mais à réserver aux applications "24/24, 7/7, 365/365" vu que cela implique un doublement des architectures matérielles ...

Considérer le parachute de secours qu'est la stanby comme étant une méthode de sauvegarde, c'est plutôt osé je trouve !

[aline]

oui et non,
La standby offre à peux près les mêmes fonctionalitées mais avec un cout plus elevé (au max, l'achat d'un serveur). et cela pour un plus grand confort d'utilisation.

Supposez que votre client n'a pas un dba à temps complet, il voudrait s'il a un problème pouvoir appuyer sur un fros bouton rouge et plus de problème (il vous appelle a ce moment et vous le reglez à posteriori) . Mais en tout cas, cela procure une situation bien lpus confortable pour lui