migration bases oracle

Comment mener un vaste projet de migration de bases Oracle ?

08/01/2013
Données

Comment mettre en Ĺ“uvre efficacement un vaste projet de migration de bases Oracle vers la version 11gR2 ? Telle est la question qui a Ă©tĂ© posĂ©e Ă  Digora par un de ses clients. Approfondissons les points forts de cette  prĂ©-Ă©tude  confiĂ©e Ă  Digora…

Le contexte

Notre client utilise les bases Oracle sur une grande échelle. Cette pré-étude de migration couvre une bonne part des bases Oracle mises en oeuvre :

  • plus de 50 bases
  • plus de 20 serveurs
  • versions Oracle Database allant de 8i Ă  11g

Voici le périmètre que Digora a proposé de traiter :

  • rĂ©alisation d’une cartographie des bases de donnĂ©es conformĂ©ment au pĂ©rimètre fourni par les Ă©quipes d’ingĂ©nierie du client
  • dĂ©finition d’un lotissage en fonction des diffĂ©rentes contraintes (techniques, et fonctionnelles)
  • rĂ©alisation d’une Ă©tude de compatibilitĂ© menĂ©e Ă  plusieurs niveaux : entre les produits Oracle et sur les technologies d’accès aux donnĂ©es
  • Ă©tude des diffĂ©rentes certifications logicielles prĂ©vues pour Oracle Server 11gR2
  • Ă©tude des prĂ©requis matĂ©riels
  • Ă©tablissement de prĂ©conisations sur les mĂ©thodes de migration des bases de donnĂ©es possibles
  • rĂ©daction d’une liste de technologies pouvant amener une plus-value au client pendant et après la migration
  • revue de points existants d’intĂ©rĂŞt relatifs Ă  l’exploitation existante et post-migration

Déroulement de la pré-étude

Nous avons débuté la pré-étude par un recensement des bases concernée par le projet de migration. Toutes les informations pertinentes pour chaque base ont été collectées et formalisées dès le démarrage de la pré-étude.

Digora a prĂ©conisĂ© de regrouper en lots fonctionnels les bases Ă  migrer. Ce lotissage est basĂ© sur le pĂ´le d’activitĂ© pour lequel les bases concernĂ©es sont utilisĂ©es.

Nous avons Ă©galement prĂ©conisĂ© pour chaque lot fonctionnel un sous-lotissage en lots techniques, en privilĂ©giant la migration des bases de versions les plus anciennes en premier pour des raisons techniques qui vont ĂŞtre prĂ©sentĂ©es ci-dessous.

Environ 15 regroupements ont ainsi Ă©tĂ© dĂ©finis pour les environnements de Dev/Recette et un nombre un peu plus faible pour les environnements de production.

La pré-étude a abordé de nombreux aspects techniques dont un extrait est présenté ci-après.

COMPATIBILITÉ CLIENT/SERVEUR – SERVEUR/SERVEUR

La compatibilitĂ© Client/Serveur (et Serveur/Serveur pour les DB Links) est dĂ©finie par Oracle et doit ĂŞtre prise en compte dans un projet de migration de version de bases :

ORACLE DATA PROVIDER .NET

Il faut examiner attentivement les matrices de compatibilitĂ© concernant Oracle Data Provider .NET, le client SQL*Net et les bases Oracle. Voici quelques informations Ă  ce sujet :

 JDBC THIN CLIENT

Il en est de mĂŞme pour l’accès aux bases de donnĂ©es par utilisation du driver JDBC-THINconformĂ©ment au tableau ci-dessous :

 JDBC OCI

JDBC-OCI est une autre mĂ©thode de connexion Java vers les bases Oracle. Dans ce cas, le tableauCompatibilitĂ© Client/Serveur – Serveur/Serveur prĂ©sentĂ© plus haut doit Ă©galement ĂŞtre pris en compte.

CERTIFICATIONS DES ÉDITEURS

Il est essentiel de prendre en compte la certification des Ă©diteurs dans le cadre de ce projet de migration des bases vers une version supĂ©rieure.

Un contact avec chaque éditeur est essentiel dans ce contexte.

PRÉREQUIS MATÉRIELS

Afin d’aider notre client Ă  dĂ©finir sa configuration cible, nous avons spĂ©cifiĂ© les besoins de ressources pour les serveurs Oracle et les versions d’OS recommandĂ©s suite Ă  la migration vers des versions supĂ©rieures.

ELÉMENTS TECHNIQUES DE MIGRATION DES BASES DE DONNÉES

Il convenait Ă©galement d’inclure dans la prĂ©-Ă©tude les points suivants :

  • recensement des diffĂ©rentes techniques de migration ou d’Upgrade, avec leurs avantages et inconvĂ©nients
  • prise en compte de l’utilisation de Change Data Capture (fonctionnalitĂ© de rĂ©plication d’Oracle)
  • prĂ©sentation des apports majeurs d’Oracle 11g
  • revue des mĂ©thodes de sauvegardes actuelles et amĂ©liorations possibles
  • mĂ©thodes visant Ă  garantir une amĂ©lioration si possible, sinon un maintien Ă  tout le moins des performances
  • Ă©tude des mĂ©thodes actuelles de supervision et amĂ©liorations envisageables (ex. Oracle Cloud Control)

LA SUITE…

Une fois la prĂ©-Ă©tude terminĂ©e, nous avons proposĂ© d’entamer les actions suivantes :

  • Etablissement d’un planning de tests en fonction des lots Ă©tablis
  • Etablissement d’un planning de migration des lots de production
  • Etude des arrĂŞts de production envisageable par base ou par lots de base
  • Mise en Ĺ“uvre des migrations en prĂ©-production avec Ă©ventuellement des tests de charge et de non-rĂ©gression.
  • Accompagnement sur la mise en Ĺ“uvre des choix technologiques rĂ©alisĂ©s
  • Accompagnement sur la migration des plates-formes

Conclusion

La mise en Ĺ“uvre d’un vaste projet de migration de bases Oracle est toujours un projet Ă  considĂ©rer avec prĂ©caution. La prĂ©-Ă©tude que nous avons rĂ©alisĂ©e pour ce client a pleinement rĂ©pondu Ă  ses attentes. A l’issue de cette Ă©tude, il a en effet souhaitĂ© faire intervenir un consultant expert DIGORA pour aider ses Ă©quipes Ă  rĂ©aliser la migration de ses bases dans les meilleures conditions.

Digora se tient  Ă  votre disposition pour discuter de vos projets de migration de bases Oracle. Contactez-nous !

copy-link