La version Oracle 11.2.0.2 est un patchset complet qui ne nécessite pas l’installation au préalable de la version antérieure 11.2.0.1. De plus pour une installation Standard Edition les composants sont prédéfinis sans aucune possibilité de sélectionner certains composants qui demeure une option réservée uniquement à la distribution Entreprise Edition.

 Avant d’envisager l’installation et la migration des bases de données en 11gR2 il est impératif au préalable que l’éditeur du logiciel qui accède à la base de données Oracle donne son aval en garantissant et en certifiant la compatibilité de la version 11gR2 avec son logiciel.

Le support d’une distribution Oracle se compose de trois types de support :

• Le support premier qui porte sur une période de 5 ans après la date de commercialisation du produit, couvre le support technique, la correction des anomalies (Patchset Upgrade), la certification avec les produits Oracle et tiers existants ainsi que la certification de nouveaux produits Oracle ou tiers
• Le support étendu qui porte sur une période de 3 ans couvre le même périmètre que le support premier hormis la certification avec des nouveaux produits Oracle ou tiers.
• Le support de maintenance qui est illimité couvre simplement le support technique sans aucune correction des anomalies.

Avant d’envisager la migration de la base de données vers la 11gR2, la matrice de compatibilité Oracle Net doit être validée aussi bien pour les communications entre clients/base de données que pour les communications entre bases de données/bases de données (DBLINK). Le tableau ci-après récapitule la compatibilité des versions entre le client et celles des serveurs de base de données.

Différentes méthodes de migration peuvent être appliquées, mais le choix de la méthode résultera principalement  des réponses à ces deux questions :

• La migration s’effectue-t-elle sur le même système d’exploitation ?
• La durée d’indisponibilité de la base de données est elle supérieure à 30 minutes ?

Systèmes d’exploitation différents

Dans le cas où la réponse à la première question est négative, la méthode la plus appropriée demeure le transfert de données soit par déchargement et rechargement des données (export, import) soit par chargement direct des données sur la base cible depuis un lien réseau de type dblink à partir de la base de données source (CTAS, COPY). Une autre considération peut aussi conditionner le choix de cette méthode, c’est le changement du jeu de caractères de la base d’origine (cf Note 225912.1). En préambule du changement du jeu de caractères l’outil Csscan (Character set scanner) permet de mesurer et d’identifier l’impact de ce changement sur les données de la base.

Export/Import des données

L’outil de déchargement/rechargement des données ‘datapump’ doit se conformer aux prérogatives suivantes :

• Le transfert du fichier de déchargement des données sur le serveur cible doit toujours s’effectuer en mode binaire
• L’export complet des données doit toujours s’effectuer avec l’utilisateur SYSTEM

• Générer les privilèges de l’utilisateur SYS dans un fichier d’export spécifique
• Garantir un export consistant
• Autoriser le parallélisme des ordres de mise à jour des données
• Au niveau performance

• Spécifier le parallélisme à deux fois le nombre de cœurs CPU
• Automatisation du meilleur choix de chargement (direct path, conventionnal path, external table)
• Exclure les statistiques de l’export et l’import EXCLUDE=STATISTICS
• Exclure le chargement des indexes à l’import EXCLUDE=INDEXES et générer la définition des indexes dans un fichier SQL avec l’option SQLFILE

Pour améliorer le temps de traitement de la migration et/ou en cas d’insuffisance d’espace disque pour héberger le fichier dump sur l’un des deux serveurs (source, cible) et au cas où l’on dispose d’une infrastructure réseau conséquente avec un lien éthernet au minimum de 1 Gbits/s l’option NETWORK_LINK de l’outil ‘impdp’ qui autorise un transfert à travers le réseau doit être privilégiée. Cette option permet de charger directement les données de la base de données source vers la base de données cible sans aucun transfert de fichiers dump intermédiaires, le gain de temps est non négligeable. Les seules restrictions concernant cette option sont :

• Le volume des données à transférer devrait être inférieur à 500Go pour ne pas saturer durablement le réseau. La fenêtre de transfert doit être choisie avec précaution selon les impératifs d’exploitation.
• Les objets de type tables imbriquées sont prohibés ainsi que les données de type LONG ou LONG RAW
• La limitation de la bande passante du réseau

Database Transportable

Cette méthode permet uniquement la migration des fichiers de données d’une base entre  différents systèmes d’exploitation mais de même format endian little ou big (poids du bit le plus à gauche) en revanche la montée de version de la distribution Oracle ne peut pas s’effectuer en parallèle. Cette méthode utilise l’outil RMAN  qui convertit les fichiers de données dans le format cible par la commande RMAN : CONVERT DATABASE. La base de données est prête à la migration lorsque celle-ci est basculée en mode lecture (READ ONLY) la commande RMAN CONVERT DATABASE est exécutée en spécifiant la plate-forme de destination et le format des noms des fichiers de données, RMAN produit alors les fichiers dont il aura besoin pour convertir la base sur la plate-forme cible. (Cf Note 413586.1)

Les principales restrictions concernant la migration inter plates-formes de cette méthode sont :

• Les plates-formes source et destination doivent partager le même endian format
• Les fichiers de contrôles et les journaux de la base source ne sont pas transportés
• Les fichiers BFILEs, les tables externes, les répertoires et le fichier de mot de passe ne sont pas transportés.

Indisponibilité inférieure à 30 minutes

Dans le cas où l’exigence d’indisponibilité de la base de données doit être inférieure à 30mn les méthodes de migration s’orienteront vers des solutions de duplication ou réplication telles que :

• Tablespace Transportable
• Streams & Golden Gate
• Oracle Dataguard

Tablespace Transportable

Le concept est simple il s’agit de créer une base de données vide dans un nouvel environnement avec la version cible 11gR2 puis de brancher tous les ‘tablespaces’ à cette nouvelle base de données en ayant au préalable recopié les fichiers de données et importé les métadonnées.

Mais avant d’effectuer le transfert des fichiers de données et des métadonnées il est obligatoire de transférer dans la base de données cible les objets non segmentés de type utilisateurs, vues, synonymes, profils, privilèges, séquences, procédures, déclencheurs, packages….. Cette opération peut s’avérer complexe et contraignante en fonction du nombre d’objets non segmentés et du nombre de schémas à transférer.

Une des principales contraintes concernant cette méthode de migration demeure la version des fuseaux horaires pour l’instance cible qui doit être identique à celle de la source. Pour cela, la variable $ORA_TZFILE doit être forcée à la version des fuseaux horaires d’origine dans la session qui crée la base de données cible afin que la version 14 par défaut ne soit pas appliquée automatiquement.

G:oracleproduct11.2.0db > set ORA_TZFILE=%ORACLE_HOME%oracorezoneinfotimezlrg_4.dat
G:oracleproduct11.2.0db > sqlplus / as sysdba
eSQL > CREATE DATABASE TMSMIG

Streams & Golden Gate

Le concept de réplication de ces deux composants Oracle est similaire :

• Démarrer la capture des modifications sur la base de données source
• Créer une copie de la base sur l’environnement cible (Data pump, RMAN backup/restore)
• Migrer la base de données cible dans la nouvelle version Oracle dans le cas d’une restauration RMAN
• Appliquer les modifications en provenance de la base source à la base de données cible.
• Une fois la base cible synchronisée, rediriger les connexions des clients sur la base cible. L’indisponibilité est limitée à la durée de déconnexion/reconnexion des clients. (switchover)

 Les exigences de migration demeurent les moins contraignantes vis-à-vis des autres méthodes puisque ces deux méthodes permettent de synchroniser les données :

• Entre des plates-formes différentes
• Entre des plates-formes de format endian différents
• Entre des versions Oracle différentes
• Un retour arrière est possible entre la version cible et la version d’origine (switchback)

Transient Logical Standby

Cette méthode peut être envisagée à partir de la version 11gR1, elle permet d’utiliser une physical standby en la convertissant temporairement en logical standby pour pouvoir effectuer la migration en 11gR2 ainsi le temps d’indisponibilité d’accès aux données est limité à la durée de changement des rôles de la base primaire et standby (switchover) soit quelques secondes au plus quelques minutes. Vous pouvez aussi utiliser une logical standby temporaire pour effectuer un rolling update à partir d’un base Oracle 10.2 mais la procédure nécessite des étapes supplémentaires cf.Oracle MetaLink note: 300479.1.

Les étapes de la procédure de rolling upgrade avec une logical standby temporaire sont les suivantes :

1. Créer un point de restauration garanti avec Flashback sur la base primaire
2. Convertir la physical standby en logical standby temporairement
3. Effectuer la migration en 11gR2 sur la logical standby et la resynchroniser avec la base primaire
4. Inverser les rôles des bases (switchover)
5. Retour de la base primaire d’origine (maintenant logical standby) au point de restauration garanti de l’étape 1
6. Remonter la base primaire d’origine (maintenant logical) sous le nouvel ORACLE_HOME de la 11gR2
7. Convertir la logical standby en physical standby et la resynchroniser avec la nouvelle base primaire, automatiquement les mises à jour de la migration seront effectuées.
8. Attendre que la physical standby soit mise à jour à partir de la nouvelle base primaire via redo stream.
9. Retourner à la situation initiale par une inversion des rôles (switchover)
10. Initialiser le paramètre COMPATIBLE à 11.2.0

Même système d’exploitation et indisponibilité supérieure à 30 minutes

Dans le cas de figure où nous demeurons sur le même système d’exploitation et où nous disposons d’une fenêtre d’indisponibilité de la base comprise entre trente minutes et plusieurs heures la méthode de migration à privilégier est la migration directe soit par l’assistant graphique proposé par Oracle Database Assistant Upgrade (DBUA) soit par des commandes manuelles SQL en ligne.

Quelle que soit la méthode et contrairement aux idées reçues la durée de migration n’est pas tributaire de la taille de la base de données mais elle dépendra :

• Du nombre de composants et d’options à mettre à jour
• De la validité des statistiques sur les données du dictionnaire
• Du nombre d’objets dans le référentiel XDB

Les versions requises des bases de données ‘source’ pour envisager une migration directe sont les suivantes :

Pour pouvoir effectuer une migration directe de la base de données soit via l’assistant de migration DBUA ou par une migration manuelle à travers des scripts, les versions sources doivent être au minimum celles référencées dans le tableau ci-dessus. Si  la version d’origine est inférieure à celle qui est requise pour la migration, alors l’application d’un patchset d’un niveau supérieur ou égal à celui exigé dans le tableau est obligatoire (ex : Si version source 10.2.0.1 il est impératif d’appliquer au minimum le patchset 10.2.0.2).

Description des phases de migration en mode manuel
La migration manuelle 11gR2 se décompose en 5 phases principales :
–       Installation de la distribution Oracle 11gR2
–       Sauvegarde de la base de données 10gR2 à migrer
–       Migration de la base de données
–       SQL Tuning
–       Test de performance & non régression

La durée globale de la migration manuelle devrait se situer entre 30 minutes et 1h30, et comprend les différentes opérations suivantes :

1. Suivre les recommandations du script utlu112i.sql à partir de la base source
2. Copier les fichiers password, pfile, listener.ora dans le nouveau répertoire de la base cible
3. Changer les variables d’environnement pour pointer sur le nouvel environnement 11gR2
4. Démarrer le listener associé à la nouvelle distribution 11gR2
5. Démarrer la base de données en mode UPGRADE : STARTUP UPGRADE
6. Exécuter le script de migration : @catupgrd.sql
7. Exécuter le script de post migration : @catuppst.sql
8. Exécuter le script de recompilation des objets : @utlrp.sql
9. Exécuter le script de vérification de la migration : @utlu112s.sql
10. Exécuter le script de comparaison des objets avant et après migration : @utluiobj.sql
11. Migrer la version du Time Zone.

 Alors si vous désirez poursuivre et approfondir l’étude de ces différentes méthodes n’hésitez pas à consulter ces différents documents de références qui m’ont permis d’élaborer ce petit article.

http://www.oracle.com/technetwork/database/upgrade/upgrade11gr2-2day-workshop-173044.pdf
Database Rolling Upgrade using transient logical standby
http://download.oracle.com/docs/cd/E11882_01/server.112/e17222.pdf