Oracle : impact de l'obsolescence du type LONG sur le modèle de données Planisware
Description
Le type de données LONG est un type obsolète pour les bases de données ORACLE. Il est encore présent dans les versions récentes d’Oracle pour des raisons évidentes de compatibilité mais il n’évolue plus et est destiné à disparaître à terme. Il est remplacé progressivement par les types CLOB et NCLOB. Cet article présente les impacts de l’obsolescence de ce type LONG sur le produit Planisware ainsi que des stratégies possibles de migration.
Obsolescence du type LONG
Depuis la version 8i, Oracle recommande d’utiliser les types CLOB et NLOB à la place du type LONG. Sur son site Oracle précise que ce type ne doit plus être utilisé et qu’il est encore présent pour des raisons de compatibilité.
Impact sur le produit Planisware
Le type LONG est utilisé historiquement dans le modèle de données Planisware pour un certain nombre de champs (ex. le champ HOLIDAYS de la table CALENDAR).
Champs de la table CALENDAR en P5 SP1
La requête SQL suivante exécutée sur le schéma applicatif Plansiware permet de lister les champs de type LONG :
select OWNER,TABLE_NAME,COLUMN_NAME from ALL_TAB_COLUMNS
WHERE OWNER=’BASE_DEV1’ AND DATA_TYPE = ’LONG’;
avec BASE_DEV1 le nom du schéma de base de données
Ce qui donne par exemple sur le modèle de données de P5 SP1 :
Champs de type LONG en P5 SP1
Tous les champs de type LONG ont été modifiés en SP3. Ils sont maintenant de type CLOB comme on peut le constater dans l’exemple suivant qui décrit la table CALENDAR en SP3 :
Champs de la table CALENDAR en P5 SP3
Ainsi depuis la P5 SP3 lorsque le client lourd vérifie le modèle données sur une base vierge, les champs historiquement créés en type LONG sont maintenant créés en type CLOB.
Stratégies de migration
Lors de la migration d’une base de données existante (de SP1 vers SP3) la modification du modèle de données via le client lourd ne modifiera pas le type de données des champs déjà présents en base. Pour assurer la migration de ces champs 2 stratégies peuvent être envisagées :
→ Migration des données directement en base (à l’aide de la fonction TO_LOB)
→ Migration des données via un import/export de dpx :
→ export de la base (contenant des champs de type LONG) sous forme de dpx
→ suppression des tables P5 du schéma de la BDD Oracle (car sinon les tables ne sont pas recréées et les champs de type LONG pas mis à jour)
→ recréation des tables P5 via le client lourd P5 SP3 (lors la vérification du modèle physique)
→ import du dpx via le client lourd dans le schéma ainsi mis à jour