Vous pouvez également préciser les avantages/inconvénients et risques que vous avez rencontrés avec telle ou telle solution....
(Si vous êtes adeptes de "ceinture et bretelles", ne précisez que la méthode la plus efficace/pertinente selon vous)
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Méthodes de sauvegardes
Vous pouvez également préciser les avantages/inconvénients et risques que vous avez rencontrés avec telle ou telle solution....
(Si vous êtes adeptes de "ceinture et bretelles", ne précisez que la méthode la plus efficace/pertinente selon vous)
j'utilise tj la méthode d'export/import car elle est simple et efficace a utiliser
tous les fin de journée j'effectue un export des donnée d'un utilisateur dans un fichier .dmp puis lors de l'import je suprimme cet utilisateur et je le recrée et j'importe les données..
La 1° méthode pour moi :
- ça marche très bien et on peut tracer chacune des étapes
La 2° est bien aussi mais c'est pas toujours possible d'arrêter la base
L'import/export, je n'aime pas du tout parce qu'elle ne permet pas de récupérer la base si elle ne démarre pas
Je ne connais pas RMAN... ça me semble compliqué pour des fonctionnalités qui ne me paraissent pas vitales... mais mon ignorance me trompe probablement
RMan a quand même de gros avantages, notamment :
[/list:u:d2e4692eb4]
- Possibilité de contrôler des robots de sauvegardes en natif
Sauvegardes incrémentales de plusieurs niveaux
Sauvegardes et purge optionnelle des archive log en même temps que le reste de la base
[list:d2e4692eb4]
ha oui c'est vrai... j'y avais pas pensé
Bonjour,
Nous utilisons ici trois méthodes :
- export full en développement,
- sauvegarde à froid en homologation,
- sauvegarde à chaud en production, doublée d'un export de type full ou au niveau user. Cet export est surtout fait pour se protéger d'un drop de table malhencontreux, et il est parfois plus facile de récupérer la table par un import, que par la sauvegarde à chaud qui nécessite une récupération avec point dans le temps, la difficulté étant justement de bien situer ce point dans le temps (juste avant le drop de la table).
Toutes nos bases ont récemment migré en 9i, et les DBA réflechissent pour utiliser RMAN.
J'ai fait tout récemment la formation de sauvegarde / restauration chez Oracle, où RMAN est présenté de manière light, puisqu'il existe une formation de 3 jours sur RMAN.
Par contre, j'ai retenu qq fonctionnalités importantes sur RMAN :
1 ) on peut faire de la sauvegarde incrémentielle,
2 ) la sauvegarde se fait au niveau bloc Oracle, et seuls les blocs utilisés sont sauvegardés => c'est très important pour les bases genre VLDB,
3 ) RMAN est un produit qui doit s'intégrer avec OEM, d'où la possibilité de scheduler des tâches sous OEM et d'avoir des notifications par mail par exemple en cas de pb,
4 ) la prise en charge des sauvegardes sur bandes par RMAN,
5 ) la souplesse d'utilisation de l'outil, car tout se fait en ligne de commande (en mode commande, pas par OEM) et l'on a pas mal d'info en tapant des commandes simples,
6 ) la performance, car RMAN ne nécessite pas de basculer les TBS en mode begin backup. Du coup, on génère beaucoup moins de redo log si un batch se déclenche en même temps que la sauvegarde à chaud.
En final, RMAN est un outil puissant, et d'après ce qui m'a été dit en formation Oracle, Oracle va pas mal pousser sur ce produit. Par contre, il nécessite un temps de prise en main et d'adaptation.
On touche justement là la question sous-jacente : tout le monde semble d'accord pour reconnaitre que sur le papier RMan est un super outil, mais dans le même temps, presque personne ne l'utilise....
C'est comme toute nouvelle technologie, ou tout nouveau produit : cela demande un peu de temps avant d'être utilisé.
De plus, avec RMAN, on touche là à un domaine très sensible : la sauvegarde et surtout la restauration. Cela demande du temps pour se former et faire des manips. D'où une certaine réticence...
RMan nouveau ??? ça existe au moins depuis la 8i....
Et la sauvegarde est certes un sujet sensible, mais l'espace consommé par les backup l'est au moins tout au tant, et Rman permet de faire des économies à ce sujet.
D'accord, RMAN n'est pas si nouveau que cela.
Ce que je veux dire, c'est que nous ne sommes pas près d'essuyer les plâtres !!!
Par exemple ici, pour migrer en 9i, on a attendu la sortie de la 10g, et surtout le fait que la 8i ne soit plus supporté par Oracle.
Quant aux économies, tout à fait d'accord que RMAN permet d'en faire. Mais moi, je suis en prestation chez un client qui a de l'argent, donc le disque n'est pas un soucis prioritaire. De plus, les DBA sont surbookées à cause d'une part du nombre de projets qui sortent, donc toutes les bases Oracle à installer, et du fait aussi qu'ils interviennent sur de nombreus sujets et SGBD autre qu'Oracle. Donc pas le temps de se mettre à RMAN, ni à d'autre sujet comme ADDM sous Oralce 10g.
En un mot, ça va vite, trop vite pour mal de monde et de sociétés.
+1, pas évident de faire comprendre que l'investissement dans une formation et la mise en oeuvre permettra de réduire les coûts par la suite... et puis quand les disques sont achetés, c'est trop tard pour se mettre à RMANEnvoyé par rouardg
Alors ça....et puis quand les disques sont achetés, c'est trop tard pour se mettre à RMAN
C'est pas trop dur de trouver un projet ou un autre qui serait intérêssé pour avoir quelques Go de plus.... ;-)
Je crois surtout que les DBA ont peur de se mouiller en proposant une nouvelle technique qu'ils ne maitrisent pas totalement...
et les décisionnaires, ça leur va pas mal aussi parce que la dépense d'espace disque est communément admise et qu'elle se justifie plus facilement que des dépenses de formations...
Et c'est là que je dis que nous devrions être plus courageux et peser pour mettre en place RMan, et bénéficier de formations au passage ! :-)
bah détrompe toi, tous les clients n'ont pas plusieurs projets qui nécessite des Go de disques
Qu'ils m'appellent, je trouverais bien une utilité à ces disques ...
Bonjour ,
En tant que DBA , j' ai eu l' occasion de mettre en route RMAN avec NETBACKUP .
Rman sera la seule solution de sauvegarde habilitée par oracle
(dixit le support ) , maintenant cela reste une grosse usine à gaz
(en oracle 8) .
Mes sauvegardes sont essentiellement basées sur export import avec
au pire perte des données de la journée .
Nous allons envisager une autre solutiion pour les bases trés importantes .
(sauvegardes à chaud par outils de sauvegardes ).
Il faut reconnaitre que l' export-import est trés simple à utiliser alors
que les restaurations via archivelog , comme l' a dit rouardg, sont plus délicates ..
cf la commande recover until cancel ...
à plus
Certes, l'Import/Export est assez simple d'utilisation mais il a cependant de telles contraintes que je ne le considère pas comme un moyen de sauvegarde :
- - Entre 2 exports, toutes les transactions validées sont perdues
- Pour des raisons d'intégrité des données, si on ne perd qu'un petit fichier sur lequel il n'y a que quelques tables, on est quand même obligé de tout supprimer et de tout réimporter
- Il ne garantit pas que la base "restaurée" fonctionnera aussi bien qu'au départ (indexes, tablespaces, ....)
- Les temps de traitement sont assez long
- ...
Et en quoi les restau avec rejeu des archive log vous semble complexe ?
Il suffit de donner les bons fichiers au bon endroit ! :-)
Mais quand vous parlez de grosse usine à gaz pour RMan, vous voulez parler à la mise en place ? à l'exploit ? à la restauration ? au monitoring ?
Nous avons la chance de travailler sur des petites bases ( <10Go) .
de plus nous n' avons qu' une application par base de données .
- pertes de petits fichiers : le pb reste le même avec n' importe quel
oultil de sauvegarde ( il faut tout restaurer pour garantir l' intégrité des données )
- perte des transactions de la journée : oui
- garantie du fonctionnement de la base : aucun souci
(tous mes exports sont régulierement réimportées dans des bases de test
testées par l' utilisateur )
- Temps de traitement : cela dépends des bases , cela est vrai
pour nos "grosses" bases ( 1 journée pour importer la paye !!)
mais c' est la seule ...
pour avoir testé le recover avec les archive logs , je sais qu' il faut connaitre exactement jusqu' à quel fichier on doit restaurer,
l' utilisateur peut supprimer des données par inadvertance sans connaitre l' heure exacte ...
rman est difficle ( en oracle8) à mettre en exploit ( avec un catalogue )
ensuite , effectivement c' est un peu plus simple ( et encore ...)
( les essais que j' ai effectué datent de trois ans , je pense que le produit
est nettement plus convivial en oracle9 ..)
Nous sommes dans l' attente d' un gestionnaire de sauvegardes en réseau
capable de lancer des sauvegardes à chaud en utilisant rman ,
donc je serai bien obligé de connaitre le produit ( en espérant pouvoir
récupérer une formation chez oracle sur rman ).
cdlt
Effectivement, ça change un peu la donne...
ben non, avec l'archive log, on ne restaure que le fichier endommagé...
C'est clair que si vous pouvez vous le permettre, vous auriez tort de chercher d'autres solutions; cependant, même si la perte d'activité est tolérée, il est préférable de l'éviter quand cela est possible, et cela est possible avec les archive log. (indépendamment du système de sauvegarde choisi)
il est vrai que les archive log permettent notamment ce genre d'opérations qui elles sont complexes, mais dans le cas simple : "fichier abimé, base cassée, on doit réparer tout", le recover database suffit et fait tout (ou presque) ! :-)
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 2ben non, avec l'archive log, on ne restaure que le fichier endommagé...
donc, de ce point de vue, la sauvegarde à chaud n'est pas meilleure que l'export
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
Ou alors je comprends mal ce que tu veux dire..
Répondre avec citation
Partager