Discussion :

[zidane2012]

Hi ,

Certes la durée d'une migration 10g/11g via export/import ou expdp/impdp dépend de la volumétrie de la base oracle à migrer.

Mais s'il s'agit d'un upgrade sans bouger les données de la base, est-ce que le volume des données joue dans la durée de l'opération ?
En effet nous avons 2 bases en production à upgrader :

• 1 base 9 To
• 1 base 150 Go

Est-ce que la durée de l'upgrade 10g / 11g est le même pour chacune ?

merciiiiiiii

[ojo77]

La durée de la migration en tant que telle n'est pas cencée durer plus ou moins longtemps en fonction de la volumétrie.

Par contre, avant toute migration, vous devriez faire une sauvegarde de la base et là, la durée dépend, toutes choses égales par ailleurs, de la volumétrie.

[funoracle]

Bonjour,

l'upgrade proprement dit ne prends pas plus de temps sur une base de 20G ou une de 500 car il s'agit de mettre à jour le dictionnaire, systématique quelque soit la taille.
Par contre statistiquement plus la base est volumineuse et plus il y a de risque d'avoir des objets invalides en pré diagnostic, donc le temps de correction de ces objets invalides peut varier énormément suivant ce que l'on veut/doit faire sur ces objets cassés. L'analyse peut prendre du temps ici.

Le reste c'est uniquement de la mise à jour/rajout de packages dans le dictionnaire, le timezone, etc ... donc peu sensible à la volumétrie.

Il y a ensuite la mise à jour des statistiques en post requis. Tout dépends du niveau de maille utilisé. On peut prendre celles ci par exemple après l'upgrade :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
exec dbms_stats.gather_dictionary_stats;
exec dbms_stats.gather_schema_stats('WMSYS',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('OUTLN',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('DBSNMP',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('SYSTEM',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('SYS',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

Et effectivement comme dit ojo77 la sauvegarde pré requise.

Franck.

[zidane2012]

Bonjour ,

J'ai remarqué que vous préconisez tous la sauvegarde : Le downgrade est-il risqué à ce point dans le cas d'un retour arrière ?

Peut-on limiter la sauvegarde uniquement aux schémas NON applicatifs(SYS ,SYSTEM ,...) puisque notre migration se fait par upgrade sur le dictionnaire et qu'on touche RIEN aux schémas applicatifs ?

Enfin existe-il un moyen simple (script , ...) permettant de valider l’opération technique d'upgrade 10g vers 11g ? et surtout l'état du dictionnaire après l'upgrade ?

Enfin dans quels cas faut-il décider de faire un retour arrière (downgrade) ?

merci

[funoracle]

Bonjour,

j'ai bien peur qu'à ce stade il faille passer par la case "lecture" :

Voir la Master Note : ID 1152016.1

Limiter la sauvegarde aux schémas SYS, etc ... c'est faire au plus simple un datapump. Il faut tester le cas de retour arrière sur ces schémas uniquement après un upgrade 11G. Je ne l'ai jamais fait, je ne sais pas dire. en tous cas il faut éplucher les scripts d'upgrade pour savoir précisement quoi sauvegarder.

Franck.