Les migrations et les mises à jour représentent une partie importante de l’activité des DBA. Les exemples sont nombreux, ces jours-ci, où il faut passer les bases de données en 11.2.0.2 parfois depuis 9i ou même 8.0, les « downsizer » de Unix à Linux (ou l’inverse), les migrer d’une base de données relationnelle quelconque à Oracle (ou l’inverse), les « sauver » de Windows à Linux (ou l’inverse), les convertir de 32 à 64 bits, appliquer un Patch Set, un PSU, un CPU ou un one-off, les changer de SAN, les déplacer sur un NAS, les migrer sur des infrastructures clusters, consolidées, virtualisées ou les 3 à la fois. Le graal de ces migrations est sans doute d’ailleurs de les migrer d’un « superdome », d’un « starfire » ou un « regatta », même si ça fait des années que les gros serveurs Unix ont des noms moins sympathiques, ou d’un moteur spécialisé comme Teradata et Netezza à une Database Machine SUN (Exadata)… Mais on aura bientôt des projets de migration d’une DB Machine à une autre.

Bref migrations et mises à jour, ça n’arrête pas ! Ce qui n’empêche pas d’avoir toujours quelques trucs à apprendre sur le sujet. D’autant qu’avec chaque nouvelle version de la base de données vient un lot de fonctionnalités qui enrichissent encore les possibilités. Nous avons eu l’occasion de nous réunir la semaine dernière pour, pourquoi pas, essayer de classer les possibilités en fonction des cas et c’est bien moins simple qu’il n’y parait. Je vous propose de trouver ci-dessous un premier niveau de synthèse de nos réflexions. Je fais appel à votre génerosité : commentez cet article pour l’enrichir de vos réflexions et nous aider à nous balader sur les chemins de la mise à jour parfaite…

Préambule

Avec le temps et les évolutions, on pourrait se dire que les changements sont de moins en moins coûteux à opérer et nécessitent de moins en moins d’indisponibilité. De fait, c’est souvent le cas !

Aux premières places des technologies qui ont transformé les problèmes de changement d’infrastructure figurent (1) l’utilisation systématique de réseaux de stockage que ce soit un SAN fibre, IP ou infiniband ou de serveurs NAS et surtout (2) les technologies de virtualisation. On peut par exemple déplacer une machine virtuelle d’un serveur physique à un autre par un simple clic et avec moins de 10 secondes d’indisponibilité avec la virtualisation de serveurs. On peut également déplacer une LUN d’une baie de stockage à une autre sans aucun arrêt. En outre, certains outils comme les snapshots sont d’un redoutable soutien dans vos migrations.

La base de données Oracle n’est pas en reste. Elle embarque, elle aussi plusieurs technologies de virtualisation, qui facilitent ou enlèvent la nécessité de certaines migration. RAC ou RAC One-Node permettent de changer votre SGBD d’un serveur à un autre sans indisponibilité. Automatic Storage Manager permet de virtualiser le stockage et ainsi de déplacer vos données d’une baie à l’autre également sans aucun arrêt. D’autre part, certains outils sont également clé dans vos migrations. Je pense notamment à RMAN, Data Guard ou la notion de service réseau qui virtualise l’accès à vos bases de données.

Mais alors qu’il y a sans doute moins de migration qu’avant, celles qui restent sont souvent les plus compliquées. Il y a plusieurs explications à cette situation. D’abord les volumes sont de plus en plus importants et les migrations de bases multi-teraoctets sont désormais courantes. Ce n’est pas la contrainte la plus critique : les engagements de disponibilité ou le nombre d’utilisateurs impactés en cas d’échec peuvent être un facteur encore plus critique ; certaines migrations induisent des changements profonds et nécessitent de coupler des changements techniques à des changements fonctionnels ou interdisent d’utiliser des mécanismes Oracle pour les migrations. Il n’est donc pas rare qu’un projet de migration nécessite plusieurs semaines de préparation du fait des impacts en cas d’échecs. La préparation nécessaire va alors très au-delà de la simple validation technique de la mise à jour. Elle nécessite d’anticiper tous les problèmes possibles.

Cadre méthodologique

J’ai beaucoup de chance et je suis un excellent préparateur. Si ce ne sont pas les raisons qui font que les projets de migration auxquels je participe se passent bien. Ca aide forcément !

Pour qu’un projet se passe bien, plus que tout, il faut savoir pourquoi on fait ce qu’on fait. A la fin, on est tous pris par le temps et autant, vous pourrez trouver ça fun de concevoir une solution pour migrer une base de données de 5 To d’une 9i sur un E15K à une 11g sur une Database Machine avec moins de 3 heures d’indisponibilité autant, au 3e tir à blanc, on se demande tous pourquoi on n’a pas pris option plagiste au baccalauréat. Combien de fois avez-vous constaté que le 3e tir a servi à quelque chose ? Si bien que soit vous en faite un 4e soit la migration se plante d’une manière ou d’une autre. Et bien, croyez moi, le fait de savoir à quoi sert le 3e tir est salvateur.

S’inscrire dans un cadre méthodologique, pour une opération de 3 semaines ou le déplacement d’un fichier de 2 Go évite bien des déceptions. La méthode évolue toujours mais le cadre méthodologique reste, me semble-t-il, toujours assez semblable. Il s’agit notamment :

• De comprendre le contexte et de définir clairement les objectifs : une migration ne peut pas se passer de la même manière selon les compétences disponibles sur le projet, pour une base de 10Go ou une base de 10To, avec une baie Netapp ou une baie EMC. Le contexte est fondamental. De la même manière les objectifs doivent être clairement exprimés. C’est encore une lapalissade de dire que « Ne pas détériorer les performances » est un objectif complètement différent « d’améliorer les performances »… et encore faut-il qualifier de quelles performances on parle. Vous serez étonné de constater que 30 minutes de réflexions peuvent bouleverser un projet de 3 semaines et de 50 jours de charge dans un sens, comme dans l’autre.
• D’évaluer les risques avec soin : dans les organisations, un risque c’est de l’argent et c’est un sujet un « peu » sensible. En tant que DBA, vous avez l’occasion de faire prendre des risques de plusieurs millions d’euros ou même de ruiner certaines vies où vous travaillez, sans vous en rendre compte parfois. Vous croyez que j’exagère ? J’y suis particulièrement sensible dans la mesure où mon petit frère est responsable d’une équipe de « risk manager » dans une grande compagnie d’assurance et qu’il prend des décisions qui peuvent amener au dépôt de bilan d’entreprises pour en préserver d’autres ou par profit. Mais au delà de cette proximité, j’ai surtout eu l’opportunité, sinon d’exploser un système, au moins d’assister à des explosions que j’aurais, à coup sur, pu éviter si j’avais été plus lucide des risques encourus. Si on devait cumuler les pertes associées, je dépasserai sûrement le millions d’euros, juste pour « des risques » qui se sont matérialisés et je ne compte pas ceux avec lesquels j’ai juste eu de la chance. Cela dit, la maturité nous apporte prudence et tempérance. Pour balancer ces pertes, nous avons aussi tous virtuellement sauvés des millions d’euros. Gérer vos risques permet d’en prendre conscience et de les éviter. Cela permet aussi de mieux communiquer, de justifier des choix, de favoriser des prises de décisions : qu’est-ce que 10 milles euros, quand il s’agit d’éviter d’en perdre 10 millions ?   
• De construire un plan (projet) : avant même de commencer à travailler… Il y a quelques années, j’ai travaillé avec un DBA qui faisait systématiquement cet effort avant de commencer une opération en mode « crise » ou résolution d’incidents. Ces, parfois, 15 minutes de « perdues » avant de commencer à travailler effectivement, lui en a probablement f
  ait économiser des centaines au final. Encore aujourd’hui, c’est la personne la plus pertinente en mode crise qu’il m’a été donné de rencontrer.  Ça m’avait frappé de voir non seulement comment ça l’aidait à savoir où il allait, à gérer des discussions avec les gens qui l’entouraient et, si je pense que je l’ai parfois aidé dans ces crises, c’est seulement parce qu’il arrivait par cette étape à se rendre disponible aux autres et à se mettre en mode d’écoute. Après, il ne faisait plus rien au hasard. Il dégageait une véritable sérénité tout simplement parce qu’il savait où il allait. Faire un plan, ne signifie pas qu’on arrive toujours en une seule fois à une cible mais ça change tout. Tout est organisé, chacun à sa place. La communication avec les utilisateurs devenait cristalline, juste et même douce malgré des niveaux de frustration parfois extrême. J’ai vécu une situation assez proche lors d’une autre crise, il y a quelques mois où, c’est le DSI de l’entreprise qui a fait ce travail et, je vous promets que ça vous scotche ; ça force le respect d’autant qu’il avait un sens du timing exceptionnel. Si faire un plan pour un travail de 20 minutes est si important, imaginez pour un changement que vous pouvez planifier ! Le fait qu’on voit de tout ne justifie pas qu’on ne fasse pas soi-même ce travail, y compris lorsqu’on n’est qu’une partie d’un ensemble plus large.
• De préparer : Le fait que cette partie soit toujours au menu des migrations ne signifie par qu’elle soit toujours bien faite. Alors bien sur, il faut faire des tests, des « dry run », migrer les différents environnements de développements, de tests unitaires, d’intégration, qualification, pré-production, plan de reprise. Il faut préparer et valider le retour arrière, anticiper les problèmes ; il faut blah, blah, blah… Je dis : sors de ce corps ! Ce qu’il faut faire c’est, en fait :
• Vous assurer que les objectifs seront atteints quitte à les modifier ou modifier les contraintes, avec l’accord de tous
• Réduire les risques jusqu’à un niveau tolérable et compris
• Trouver et mettre en place des raccourcis pour réduire le temps et les coûts mais surtout pour sécuriser les opérations. Vous avez en général moins de chance de vous tromper sur une opération de 5 minutes que sur une opération de 3 heures
• Coordonner les opérations, rester à l’écoute de vos collègues et partenaires
• Communiquer : les DBA doivent parfois annoncer de mauvaises nouvelles. Il faut pouvoir le faire rapidement mais aussi dans la transparence et la sérénité. Il faut savoir communiquer les bonnes comme les mauvaises nouvelles et aligner les gens sur l’objectif.
• D’exécuter : ça parait évident ; ne le fait-on pas pour ça ? Encore faut-il le faire au bon moment, s’arrêter quand l’opération est terminée et que tous les objectifs sont atteints ou qu’on a admis, ensemble, qu’on pouvait vivre sans atteindre tel ou tel objectif et, dans le pire des cas, faire le chemin inverse. Combien de fois ai-je vu le succès annoncé sans que personne ne sache encore si le système ainsi mis à jour pourrait gérer l’ensemble des utilisateurs ou le traitement de la fin de la semaine ? Bien sur on peut avoir de la chance… L’exécution de la migration ou des mises à jour doit prendre en compte l’ensemble des objectifs mais également les attentes de tous et les « non-objectifs ». Nous sommes des techniciens mais c’est très différent de réussir techniquement et que tout le monde pense qu’on a réussi. Il ne s’agit pas de manipuler les foules quoiqu’on voit de tout là encore mais de créer les conditions d’une certaine justice. Lors d’un des projets de migrations sur lesquels j’ai travaillé l’an dernier, nous avons décalé la date d’exécution parce que nous estimions que les risques étaient encore trop grand. Pour des raisons assez obscures, une majeure partie des utilisateurs n’a pas été informée de cette annulation. Et bien croyez-le ou non, le lundi matin, à l’ouverture théorique du service, le centre d’appel a reçu plus d’appels qu’il n’en avait jamais reçu et trois fois supérieur aux autres lundis. Les gens se plaignaient de l’échec de la migration (qui n’avait pas eu lieu !) et d’après les études menées ensuite, ce lundi n’avait pas été pire que les autres. La communication fait donc partie de l’exécution :
• Elle doit être transparente : ne vous faites pas d’illusion, 1984 n’existe pas, si quelque chose se passe mal, ça se saura toujours (c’est vrai des incidents aussi !)
• Elle doit être régulière, rien de pire que d’avoir des nouvelles toutes les 15 minutes pendant une phase et puis plus rien pendant 2 heures. 
• Elle doit être juste et positive : vous rencontrerez peut-être des problèmes lors vos changements ; annoncez-les et annoncez en même temps quand vous serez en mesure de faire un diagnostique clair avec un temps de résolution connu. 
• Elle doit être fiable. C’est en particulier le cas sur le timing. Si ce n’est pas bon de mettre 2x plus de temps qu’initialement annoncé à moins d’avoir une bonne raison, ce n’est pas non plus terrible d’être 2 fois plus rapide. 
• Elle doit être source d’émulation. Il faut penser aux utilisateurs mais également aux gens qui travaillent. Le meilleur exemple, je l’ai également vécu avec mon « super » DSI ! Il a fait faire un montage photos qu’il a présenté le soir de la réouverture du service lors d’un pot avec le directeur général. Il restait encore plein de problèmes et les équipes étaient sur le pont depuis 3 jours mais il a su montrer à tous qu’il avait confiance et sans mentir mettre en avant les victoires. Le soir du sur-lendemain, tout était terminé et dieu sait combien d’imprévus ont été gérés à cette occasion. Il a probablement rénové 95% de son SI et j’ai rarement vu autant de gens contents de travailler nuits, jours et même un jour férié ; tous ensemble !
• Elle doit avoir une conclusion et rester ouverte
• De faire le bilan : que vous travailliez 10 minutes ou plusieurs semaines, c’est dommage de ne pas tirer les enseignements de ce qui c’est passé et de ne pas faire une liste des choses qu’on peut améliorer « pour la prochaine fois ». 

Bien sur, l’énergie que vous dépenserez sur chacune de ces phases ainsi que la manière de le faire dépendra beaucoup des enjeux, de la complexité et des risques des opérations. Néanmoins, vous gagnerez toujours à prendre du recul. Et passons maintenant du projet de migration en général aux techniques et technologies support aux migrations…

Les risques liés aux mises à jour

Les risques liés aux migrations sont très similaires quels que soient les projets. En voici quelques exemples ci-dessous :

• La migration technique échoue
• Le plan de retour arrière échoue
• Certaines fonctionnalités ne sont plus assurés du fait de la migration
• Les performances de certaines requêtes sont dégradées
• La plateforme cible n’est pas stable. Un bug bloquant et non anticipé empêche d’utiliser l’application
• Un ou plusieurs composants de l’infrastructure sont mal configurés ou dimensionnés
• Les paramétrages de la cible (connexions, scripts du plan de production, …) sont faux
• Les équipes opérationnelles ne maîtrisent pas la nouvelle architecture et sont incapables de l’opérer voire l’altèrent
• Les tests réalisés ne sont pas représentatifs du fonctionnement de l’application en production
• Certaines fonctionnalités de la version Oracle ne fonctionnement comme attendues
• …

Notes :
Cette liste de risques n’est pas exhaustive pour des raisons que vous comprendrez. D’autre part l’évaluation de chacun de ces risques est très contextuelle et doit faire l’objet d’une
projection dans le contexte de votre projet. De cette liste de risques, de leur évaluation dans votre contexte et des objectifs, vous construirez votre plan de travail !

Une taxonomie des migrations et mises à jour

Il existe des dizaines de techniques qui peuvent être mises en oeuvre pour réaliser des migrations et des mises à jour. J’en présenterai quelques unes dans le paragraphe suivant. Notre intention initiale était de dégager quelques règles simples pour aider nos clients et partenaires dans l’élaboration de leur trajectoire de transformation mais il s’avère que c’est plus compliqué qu’il n’y parait au premier abord. Pour contourner la difficulté, nous sommes partis du principe qu’il existe plusieurs types de migrations ou de mise à jour et que chaque type complexe peut être ramené à une succession de type simples.

Dans cette section, nous nous concentrons uniquement sur les changements dans l’infrastructure. J’ai bien conscience que dans beaucoup de cas, les changements sont réalisés conjointement à des changements fonctionnels et que, du coup, les changements de l’infrastructure peuvent paraître anodin. Enfin, je n’ai pas la prétention d’inventer en quelques heures un système expert à qui vous soumettez vos hypothèses et qui vous fournit la meilleure solution. Je serai d’ailleurs bien bête de le faire, puisqu’après tout, je me fais payer pour ça.

Si on regarde froidement les choses, les différentes situations de changements correspondent toujours à une combinaison des cas suivants :

• Mettre à jour le logiciel de base de données sur le même serveur :
• En place, c’est à dire sur le même ORACLE_HOME
• Dans un autre ORACLE_HOME
• Mettre à jour le catalogue de la base de données
• Pour appliquer un changement mineur comme un one-off, un CPU ou un PSU
• Pour passer d’une version N à une version M ; M et N étant différent d’au moins 1 Patch Set 
• Déplacer un moteur de base de données d’un serveur à un autre :
• Les serveurs source et destination ayant le même OS, la même architecture et taille du jeux d’instructions (e.g. 32 bits vers 32 bits)
• Les serveurs source et destination ayant des le même OS, la même architecture et des tailles de jeux d’instruction différents (e.g. 32 bits vers 64 bits)
• Le serveurs source et destination ayant des OS différents mais compatibles et la même architecture ; en 11.2, le seul cas est le cas où un des serveurs est un Linux alors que l’autre est un Windows
• Les serveurs source et destination ont des architectures ou des OS différents mais l’endianess des serveurs est identique (e.g. HP-UX/Itanium et AIX/Power)
• Les serveurs source et destination ont des architectures ou des OS différents et l’endianess des serveurs est différente (e.g. Solaris/SPARC et Solaris/x86_64 ou HP-UX et Linux/x86_64)
• Déplacer une base de données de stockage
• Pour conserver une copie en cas de nécessité de retour arrière
• Pour changer de baie ou de sous-système de stockage
• Parce que les systèmes de stockages associés aux serveurs sont incompatibles (e.g. ext3 et vxfs ou ext3 à ASM)
• Changer le jeu de caractères d’une base de données :
• Avec des jeux de caractères compatibles (e.g. WE8ISO8859P1 à WE8ISO8859P1)
• Avec des jeux de caractères incompatibles (e.g. WE8ISO8859P1 à AL32UTF8)
• Changer les structures de données :
• Avec un nombre de différences limité et maitrisé (e.g. des indexes supplémentaires, des types de colonnes qui changent, …)
• Avec un nombre de différences important ou non maitrisé

D’autre part, les changements de la cible, les problématiques de migration et de mises à jour induisent d’autres enjeux qui sont :

• La capacité de revenir à l’état initial après migration en cas de nécessité de retour arrière
• à T0 moment de démarrage de la migration
• à T moment de la prise de décision du retour arrière
• La capacité de masquer le temps de migration par un mécanisme qui permet de capturer les changements de manière différentielle
• La capacité de reproduire les environnements et la charge applicative pour valider les hypothèses de fonctionnement :
• Avec une application identique
• Avec une application différente

Techniques et outils

Dans le tableau ci-dessous, vous trouverez un draft de tableau que regroupe l’ensemble des technologies Oracle qui peuvent être utilisées pendant des migrations ainsi que les cas de migration auxquels ces technologies s’applique en fonction de la taxonomie précédente :

Je vous propose de laisser vos commentaires sur cet article pour compléter ce tableau et en faire un outil utile pour tous. La solution que vous devrez mettre en place au final est sans doute un « lego » constitué d’un sous-ensemble de ces technologies et de technologies non Oracle pour faciliter chacune des opérations nécessaire pour votre cas concret.

Note :
Au delà des technologies tiers, il n’est même pas évident de faire la liste des technologies Oracle. Les diagnostic et tuning packs, par exemple, n’ont a priori rien à voir avec les migrations et pourtant, ce sont un facteur clé de réussite des migrations puisqu’ils vous permettront de corriger certains problèmes au moment de l’ouverture du service. J’en ai fait l’expérience plusieurs fois et les préconise, quand c’est possible, dans la phase d’ouverture du service pour réduire la charge des serveurs et améliorer les temps de réponse en quelques minutes.

Le « Top 5 » des outils de migration

S’il y a de très nombreuses options pour mettre à jour ou migrer les infrastructures, il faut reconnaitre que certaines solutions sont des hits dans ce domaines. D’autres au contraire ont moins de succès. Je vous propose d’explorer le Top 5 des outils de migrations :

1. catupgrd.sql et DBUA. Ces 2 solutions se situent sur le même plan dans la mesure ou DBUA utilise catupgrd.sql. En réalité, je reconnais que personne que je connais, à part moi, est plus tenté par DBUA que par la méthode manuelle. Enfin ces 2 méthodes, lorsqu’elles sont applicables sont d’une simplicité déconcertantes. Pour un peu que vous ayez un serveur « explosif », vous serez en droit de vous poser la question de l’intérêt d’une autre méthode. Mon record personnel dans ce domaine est 17 minutes d’indisponibilité (de l’application) pour une migration RAC de 10g à 11g. Certes, pour en arriver là il faut un peu de préparation mais bon… Un autre intêrêt est que le chemin inverse peut être repris relativement simplement et sans perte de données pour peu que vous l’ayez testé.
2. exp/imp ou expdp/impdp. Ces 2 solutions sont a priori les plus bêtes qui existent et surtout ne souffrent quasiment d’aucune restriction. Si vous devez basculer d’une 10g sur z/OS à une 11g sur Windows et d’EBCDIC à UTF8, vous êtes presque sur d’y arriver sans rien préparer. Cela étant, elles ne sont pas exempts de bugs (cf ma manip datapump, il y a 2 semaines en 10.2.0.5). En plus elle peuvent devenir un petit casse-tête quand il faut reconstruire les droits ou recharger des sous-parties de bases. Enfin et surtout, les temps d’exécution dépendent du volume des bases de données ce qui est rédibitoire pour certaines situations. Personellement, je fuis ces méthodes dès que possible mais on a
   beau ne pas aimer, il faut parfois savoir prendre son mal en patience notamment pour vos migrations vers UTF8.

   Note:
   J’ai remarqué qu’on a un peu tendance à oublier impdp via un network_link. Pourtant cette solution est parfois élegante malgré ses restrictions notamment sur la clause parallel

3. Transportable Tablespace. J’adore… Cette méthode est simple, fiable, efficace et relativement passe partout. Elle a quelques restrictions comme d’être en 10g pour être « cross » plate-formes, de nécessiter des tablespaces « locally managed », self content ou en lecture seule. Cela dit, ce n’est pas vraiment restrictif et vous pouvez facilement vous mettre dans cette position avant la migration avec catupgrd.sql ou un Recovery Manager Duplicate. Bref, la complexité réside le plus souvent dans la construction des droits que vous contournerez avec dbms_metadata ou expdp/impdp. Les tablespaces transportables ou TTS peuvent également servir de base pour instancier vos bases avant de mettre en place Streams ou GoldenGate et, à l’exception du changement de jeu de caractères, se prêtent à tous les genres de manipulation. Bref, si vous mettez les tuyaux et la CPU, vous pourrez migrer 10To en moins de 3H et changeant presque tout.
4. Streams, Logical Standby et GoldenGate. Nous avons utilisé les 3 solutions en production ; MA préférence reste pour Streams. Je conviens que c’est plus affectif que raisonné : la technologie très élégante en termes d’architecture, plus ouverte que la standby logique et j’aime assez l’idée que ce soit déjà disponible en Enterprise Edition. Enfin, j’imagine que l’efficacité, la couverture fonctionnelle, l’ouverture, la robustesse et la simplicité priment pour certains ; GoldenGate est donc le hit : moins de restrictions, simple et fiable pour autant que la réplication SQL puisse l’être, je crois. Enfin, même si GoldenGate permet d’instancier la base de destination, ces technologies sont plutôt des solutions pour masquer le temps de copie en capturant les changements depuis le moment de l’instantiation. Si vous utilisez Streams ou Goldengate vous utiliserez probablement les export ou tablespace transportable aussi.
5. RMAN duplicate et standby physique. Ces méthodes ne constituent pas à proprement parler ou à elle seule des méthodes de migration. Toutefois, vous noterez qu’elle peuvent s’appliquer dans certains cas particuliers comme (1) Un changement de stockage ou la migration vers un environnement cluster sans changement de version de base de données ou (2) depuis 11.2 le passage de Oracle sur Windows à Oracle sur Linux ou l’inverse. Malgré tout, elles font parties des hits de la migration (au même titre que les snapshots) puisqu’elle peuvent constituer des outils pour créer des « copies temporaires » de la production.

Evidemment, ce classement est partial et adresse les changements les plus répandus. Si vous devez faire une migration vers une Database Machine SUN (Exadata), il est probable que vous utilisiez en plus, une des 2 solutions ci-dessous :

• SQL Developer Migration Workbench qui permet de décharger des données de différentes bases de données non Oracle sous la forme de fichiers puis de les charger ensuite dans votre base de données 11.2
• D’autre part, si votre base Oracle est un DataWarehouse, il est probable qu’utiliser une technologie de capture du SQL (y compris de standby physique) ne soit pas compatible avec vos opérations en mode nologging ou d’échanges de tablespaces et de partitions qu’on voit régulièrement dans ce type d’environnements. Dans ce cas, la duplication, en Y, des flux d’alimentation ETL et EAI peut vous permettre de faire tourner 2 environnements en parallèle et peut constituer une solution avec de nombreux avantages. On pourra utiliser GoldenGate pour capturer les « quelques activités interactives » de votre système décisionnel.

Précautions techniques

Soyez très attentif au changement de valeur du paramètre compatible qui influence les capacités de retour arrière de votre migration mais aussi le comportement de l’optimiseur et certaines fonctionnalités comme la capacité de Flashback Database.

Transformer vos projets de migration

Comme je vous l’aurez compris, le projet de migration est certes un projet technique, mais c’est avant tout un projet avec des dimensions de conduite du changement et de réduction des risques. Pour la plupart d’entre-nous, l’enjeu est de trouver le chemin le plus court et le plus fiable pour arriver à nos fins. Dans ce cadre Oracle offre de nombreuses technologies qui peuvent vous aider. Il ne faut certes pas mettre tous ses oeufs dans le même panier mais il faut aussi être ouvert et, encore une fois, gagner 20 jours de travail, c’est aussi parfois fiabiliser ses conclusions. Il parait juste de mentionner certains accélérateurs et raccourcis qui transforment les projets de migration aujourd’hui. La liste minimum contient :

• Flashback Database permet de réaliser en chaîne des tests et de recommencer sans perdre plusieurs heures entre chaque exécution. Si c’est trop compliqué d’utiliser Snapshots et Clones, c’est de loin une alternative aux nombreuses restaurations.
• SQL Performance Analyzer (SPA) est une technologie très simple compatible avec 9i, 10g et 11g, qui, si vous savez construire des sous-ensembles représentatifs vous permet de circonstancier vos risques en quelques heures. J’ai écris plusieurs articles pour parler de ses limites comme  SQL Performance Analyzer et Virtual Private Database ou Quelques limites d’Oracle SQL Performance Analyzer. Mais au delà de ces limites, c’est sans doute l’outil le plus simple pour simuler des changements et réaliser des analyses d’impacts
• DB Replay est « exhaustif » quoiqu’il ait également ses propres limites. J’ai écrit un article sur le blog Easyteam intitulé Utiliser Oracle Database Replay pour migrer vers 11g Release 2. Cet outil vous permettra, s’il est pertinent de gagner des jours de travail. 
• Application Test est une suite pour enregistrer des scénarios de tests fonctionnels et simuler de la charge. C’est beaucoup plus lourds que Real Application Testing mais les outils associés permettent de gérer des cas d’évolution de l’application par la construction de cas représentatifs.

Conclusion

Prenez cet article comme un essai sur les problématiques de migration et de mise à jour. Je suis intimement persuadé de la plupart de ce que j’ai écrit. Cela ne signifie pas que j’ai raison ! J’entretien le secret espoir que vos commentaires viendront l’enrichir de vos expériences, de vos remarques ou de vos désaccords. Après tout, ce blog est également un moyen de partager et de progresser tous.

Si vous êtes arrivé jusqu’à cette conclusion, c’est peut-être aussi que vous travaillez sur un projet de migration autre qu’un simple export/import. Si c’est le cas, je vous souhaite beaucoup de réussite. Pensez bien aussi à la chance que vous avez. Parce qu’ils sont parfois très risqués, les projets d’infrastructures sont une formidable opportunité de partager avec des gens qui « se mouillent ». Le résultat et la satisfaction n’en sont que meilleurs. Have fun !