Discussion :

[lalystar]

Bonjour,


Nous allons migrer dans les semaines qui suivent notre base principale qui est actuellement en 8.1.7.4 vers Oracle 10gR2.

Il s'agit d'une base OLTP en journée, batch la nuit, base très critique. La migration se fera en week-end.

La base fait 140 Go, tous tablespaces confondus.

J'aurais souhaité avoir vos retours d'expérience pour ceux qui ont vécu ce genre de migration ainsi que les plans de tests que vous avez utilisé dans le cadre d'une telle migration.

Mon principal souci est que la base est en mode RULE, meme si les stats sont calculés hebdomadairement. Certains traitements utilise le CBO en hintant les requêtes avec first_rows ou all_rows mais c'est assez minoritaire.

Ce que je pense faire est de demander à chaque équipe successivement de lancer leurs traitements sur une base en 8i et sur une base en 10g afin d'assurer la non-regréssion et de pouvoir comparer les perfs.

Ma plus grande crainte est l'éventuelle dégradation de perfs suit au passage RBO=>CBO.

La base est également connecté par database link à d'autres base qui vont être migrées en même temps. Y a t'il des problématiques particulières s'y rapportant.


Je vous remercie d'avance pour votre aide.


Laly.

[pifor]

Je n'ai qu'une remarque générale car je n'ai pas d'expérience de migration de v8 en 10g ou de database links. Il faudrait simuler la migration sur un environnement de test copie conforme de l'environnement de production (machine, copie intégrale de la base, env. applicatif), idéalement sur une machine qui a la même configuration (processeurs, mémoire, disques) que la machine de production. Et tester au minimum les fonctionnalités critiques OLTP et batch. Mais il faut avoir les ressources nécessaires et ça c'est une autre histoire.

Si vous voulez être sûr de garder les mêmes plans d'exécution, vous pouvez étudier l'utilisation éventuelle des stored outlines qui sont fait pour ça.

[lalystar]

Merci pour ta réponse Pifor.

Nous ne pouvons malheureusement pas tester en meme environnement notre migration. Nous disposerons d'un vieux serveur bi-cpu pour cela, contre un octo-processeur en production.
Mais nous allons lancer successivement les mêmes jeux de tests sur une base 8i et 10g sur le même serveur, ce qui nous permettra je l'espère de comparer les perfs relatives et la non-regression.

Nous ne pouvons pas figer les plans d'exécution avec des outlines, car bcp de requêtes sont générés à la volée en fonction de critères définis par l'utilisateur. De plus je pense que nous aurons bcp d'améliorations du fait du passage RBO=>CBO mais qq très désagréable surprise, du moins c'est ce que je pressens.

Est-ce que quelqu'un a déjà vécu du moins un changement RBO vers CBO au niveau de toute la base. Comment avez-vous régler les pbs de perfs survenus ? (avec des histogrammes ?)


Merci,

Laly.

[SheikYerbouti]

Pensez surtout à automatiser régulièrement le calcul des stats.

[orafrance]

Pour rester en RBO sinon, il suffit de ne pas calculer les stats.

[LeoAnderson]

Pour rester en RBO sinon, il suffit de ne pas calculer les stats.

Attention, en 10g le calcul des stats se fait tout seul sans qu'on n'ait rien à faire via la tâche plannifiée "GATHER_STATS_JOB" (cf. dba_scheduler_jobs).

Mais le RBO, faut s'en débarrasser car il est en passe d'être (ou est déja) non maintenu.

[lalystar]

Au niveau du calcul de stats, il est déjà schédulé chaque dimanche, sur toutes les tables du modèle avec histogramme sur les colonnes indexées. Le problème c'est qu'une minorité de traitements utilise le CBO.

On veut absolumment passer en CBO pour rester sur des solutions supportées (c'est d'ailleurs pour ca qu'on migre en 10g).


Laly.

[ducho]

Bonjour,

je n' ai pas de retour sur ce genre de migration .

Nous sommes aussi en oracle 8.1.7.' et nous allons migrer en oracle 9.

Avez-vous déjà travaillé en oracle 10 ?

quelle type de migration envisagez-vous ?

pour la méthode rbo , cbo , je ne pense pas que vous y perdrez en utilisant le cbo pour l' oltp.
par contre si vous avez du dataware house
qui va migrer avec des requêtes style bo dessus, vous pourrez rencontrer des différences . ( nous en avons rencontré en 8.1.7.4) .

vous pouvez aussi déjà testé le cbo en oracle 8 aussi .

cdlt

[Yorglaa]

Salut Laly,
est-ce que tu dispose d'une base de Test en 8i (v actuelle si j'ai bien compris)?
une solution serait tester les processus critiques sur la test en RBO (pour avoir une référence) puis de la passer en CBO (paramètre OPTIMIZER_MODE) pour restester et identifier les processus pour qui ce passage est problèmatique, afin de commencer à les optimiser avant la Prod.

[Jaouad]

Bonjour ,


Pour arreter le calcul des stats il suffit de se servir de la procedure

DBMS_SCHEDULER.stop_job

Voila mon retour d'expérience d'une migration de base de 8i 8174 en 10g R2. La migration se fait avec un tout petit script et on croit que c'est super facile. Puis c'est la que les problémes interviennent.


Les plus gros probléme sont ceux de performance. Cependant laly ce que je te conseille c'est quand même d'enlever le rule.Celui va disparaitre avec la prochaine de version.

Ce que j'ai fait pour résoudre les différents problémes de performances :

- Enlever le calcul des stats par défaut
- Calculer les stats comme je le voulais
- Reprendre les opérations dont les temps ont explosés et essayez d'influencer l'optimiseur ...


Bon courage à toi