Moi ce qui me titille, c'est de savoir quels problèmes vous avez rencontrés avec le catalogue pour en arriver à l'idée saugrenue de l'abandonner !Envoyé par billharry
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
Moi ce qui me titille, c'est de savoir quels problèmes vous avez rencontrés avec le catalogue pour en arriver à l'idée saugrenue de l'abandonner !
Saugrenue, pas tant que ça. c'est notre choix d'après notre expérience
C'est plus pour des problèmes organisationnels. Nous sommes 2 équipes. 1 équipe d'exploitation de 4 personnes, et une équipe de 2 DBA (dont ma personne). Le problème est que si 1 DBA est en vacance et que l'on ne peut pas venir pour des raisons de santé ou autre, Tout le monde est coincé.
L'exploitation est sensée gérer les sauvegardes ET les restaurations.
Ce dernier point pose problème, car ils ne connaissent pas RMAN, et quand il faut fouiller dans le catalogues pour retrouver la bonne sauvegarde, bonjour l'embrouille. On doit s'occuper de tout, et comme on ne fait pas des restauration tous les jours, on met approximativement 2h pour faire une restauration, et si l'exploitation doit le faire, ben non ils ne font pas car ils ne veulent pas savoir.
Sans catalogue, l'équipe d'exploitation nous restaure les fichiers, et nous avec le script, c'est restauré rapidement. Voir même un non rmaniste peut le faire.
En fait on a supprimé le catalogue pour diminuer les interactions avec RMAN.
Autre point: la base du catalogue
ça fait une base en moins à gérer, car là il faut de la haute dispo pour le catalogue et prévoir des migrations régulières, d'où de la maintenance supplémentaire pour une base critique.
Au moins maintenant si le système de sauvegarde plante, c'est pas notre affaire ET les sauvegardes peuvent quand même se faire...
En plus un autre besoin est venu se greffer :
une duplication quotidienne de base (on a choisi de ne pas mettre en place de standy, car cette base est complétée après pour faire un mini-infocentre).
Le script de duplication s'adapte très bien au mode sans catalogue.
Pour ce qui est de la gestion de la base catalogue, je considère ce point comme très exagéré, mais j'admets l'argument.
Pour le reste, je trouve dommage que vous n'utilisiez pas RMAN à sa pleine mesure, et ce en bonne partie pour de fausses raisons.
En effet, un avantage majeur de RMAN, c'est qu'il identifie lui-même les fichiers dont il a besoin pour une restauration, et va les chercher lui-même s'il en a la possibilité. Et dans certains cas (sauvegardes incrémentielles notamment), on a besoin de fichiers sauvegardés sur plusieurs jours, et on est content que RMAN les sélectionne et les ramène tout seul.
C'est pour ça qu'idéalement, il faut faire les sauvegardes directement sur bande, ce qui dans votre cas nécessitait l'usage de TDP pour communiquer avec TSM.
Malheureusement, cela n'est pas toujours matériellement faisable (disponibilité de la robotique en temps réel, encombrement réseau, etc), d'autant que TDP est loin d'être gratuit.
Catalogue ou pas catalogue, ça ne change rien sur ce point, les commandes LIST ou REPORT sont les mêmes.
Si vous aviez dû tirer une conclusion sur ce point, ça serait de ne pas utiliser RMAN !!!
Il est un fait qu'une restauration Oracle exige des compétences spécifiques, et vouloir l'ignorer conduit à des solutions pas très heureuses.
L'équipe d'exploitation est capable de nous redescendre les fichiers dont nous avons besoin, car nous faisons des full tous les jours et une incrémentielle le midi.
Justement, je n'utilise à aucun moment les commandes LIST et REPORT. C'est un script shell automatisé qui s'occupe des commandes RMAN.
Après s'il y a besoin, on peut utiliser le potentiel de RMAN pour récupérer des blocs corrompus, faire de la duplication, mettre en place une stand by...
Mais j'admets bien volontiers que le catalogue apporte beaucoup de fonctionnalités.
Seulement nous sommes 2 et nous nous occupons de la gestion avancée des bases et de tous les composants des systèmes d'informations. Pour cette raison nous devons beaucoup déléguer, notamment à des personnes qui ne connaissent pas RMAN, mais qui savent lancer un shell
Donc la solution a été choisie en fonction de critères qui nous sont propres, et vouloir jouer les extrémistes en imposant le catalogue n'aurait pas permis de résoudre la situation. Si on on voulait continuer à utiliser RMAN (ce qu'on préférait pour énormément de raisons), il fallait s'affranchir du catalogue.
Je rajoute mon point de vue :
Dans le cas de backups sur disques, avec l'autobackup, la restoration des controlefiles est très simple.
Et une fois les controlefiles en place, Rman retrouve ses petits, il me semble même l'avoir vu effectuer un "catalog" de sa propre initiative pour retrouver les éventuels éléments postérieur de backup.
Il faut atteindre un nombre de bases conséquent, entrainant un système de backup (bandes, robots etc) complexe, pour que "l'overload" de la gestion du catalogue soit négligeable.
A chacun d'étudier ses besoins
ET DE TESTER SES RESTORATIONS
Ah, merci
C'est rassurant de voir que quelqu'un est arrivé aux mêmes conclusions.
Pour tout le monde, le mieux est d'essayer et de voir ce qui s'adapte le mieux à son environnement
Votre "débat" est très intéressant dommage qu'il n'y ait pas plus de retour d'expérience. Je ferai le mien (j'espère que j'y penserai) après avoir mis une des méthodes en place. Pour le moment nous faisons une sauvegarde physique à froid plus une sauvegarde logique sur toutes nos bases de prod 9.2 et 10.2 (environ 50 bases) et sauvegarde physique uniquement de nos bases de test (environ 70-80).
Nous installons en ce moment Time Navigator et après avoir parcouru différents forums, je me dirige pour le moment vers du RMAN pour toutes mes bases de prod (au moins pour le moment) avec catalogue (contrainte TINA à priori lue dans un PDF). J'ai du boulot en perspective. Pour la suite je vous raconterai.
Répondre avec citation
Partager