Je comprends mieux ton point de vue et le confirme sur plusieurs points
Et je m'aperçoit que les bases que l'on gère sont beaucoup beaucoup plus simple, ne serait ce que par les contraintes gérées différemment.
De plus en 2004 nos plus grosses bases ( sous AIX oracle 8 et 9) dépassaient rarement les 15-20 go de données
( a part une de 50-60 go mais le matos avait été bien choisi )
Maintenant les plus grosses frises les 100 Go (de données uniquement sans coté le reste ) mais le matos est choisi en conséquence.
Nous utilisions l'import export exp (maintenant on est passé à datapump) dans les fenêtres de sauvegardes prévus à cet effet, et nous n'avions que très peu de base TRES SOLLICITE 24h/24h
Pour les bases critiques, ou la journée d'arrêt coûte TRES TRES cher, on a mis en place les principes suivants :
- STANDBY Database ( avec une différence max de 5 minutes )
- sauvegarde RMAN
- export datapump
importer la base dure environ 1h30
restauration from scratch depuis rman 45 minutes
mais le plus sécurisant pour le client c'est la STANDBY en plus dans ce cas c'est réellement 2 salles blanches avec 2 SAN etc ...
Mais à cause de toi le flashback vient de passer sur la pile des technologies à étudier et à maîtriser ...
[^] # 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.
Merci pour tes réponses précises et pertinentes.
Je comprends mieux ton point de vue et le confirme sur plusieurs points
Et je m'aperçoit que les bases que l'on gère sont beaucoup beaucoup plus simple, ne serait ce que par les contraintes gérées différemment.
De plus en 2004 nos plus grosses bases ( sous AIX oracle 8 et 9) dépassaient rarement les 15-20 go de données
( a part une de 50-60 go mais le matos avait été bien choisi )
Maintenant les plus grosses frises les 100 Go (de données uniquement sans coté le reste ) mais le matos est choisi en conséquence.
Nous utilisions l'import export exp (maintenant on est passé à datapump) dans les fenêtres de sauvegardes prévus à cet effet, et nous n'avions que très peu de base TRES SOLLICITE 24h/24h
Pour les bases critiques, ou la journée d'arrêt coûte TRES TRES cher, on a mis en place les principes suivants :
- STANDBY Database ( avec une différence max de 5 minutes )
- sauvegarde RMAN
- export datapump
importer la base dure environ 1h30
restauration from scratch depuis rman 45 minutes
mais le plus sécurisant pour le client c'est la STANDBY en plus dans ce cas c'est réellement 2 salles blanches avec 2 SAN etc ...
Mais à cause de toi le flashback vient de passer sur la pile des technologies à étudier et à maîtriser ...