Réponses:
30 à 90 minutes selon les meilleures pratiques d'Oracle pour la mise à niveau . Il s'agit de l'estimation la plus proche que vous obtiendrez compte tenu de toutes les inconnues dans cette situation.
La taille de la base de données importe très peu pour déterminer la durée de la mise à niveau. Voici les principaux facteurs affectant la durée (à partir du blog de mise à niveau d'Oracle.com) :
Nombre de composants et d'options de base de données installés - plus il y a de composants / d'options installés, plus les scripts de mise à niveau devront être exécutés, plus cela prendra du temps
Statistiques de dictionnaire valides et non périmées - même si la création de statistiques de dictionnaire dans certaines versions plus anciennes d'Oracle n'était pas une idée brillante, car sans le support de l'optimiseur basé sur des règles, le dictionnaire de données doit être analysé. Surtout juste avant une mise à niveau. Sinon, cela se produira pendant la mise à niveau alors que la base de données est démarrée dans un mode de mise à niveau restreint, provoquant des temps d'arrêt supplémentaires.
Nombre de lignes en AUD $ si audit_trail est défini sur DB
Nombre de synonymes lors de la mise à niveau à partir d'Oracle 9i - les synonymes seront touchés et obtiendront une nouvelle dépendance dans le dictionnaire en DÉPENDANCE $ - s'il y a un nombre élevé (comme 100 000), cela peut prendre du temps
Nombre d'objets dans XDB
À un taux très faible si COMPATIBLE sera augmenté: nombre de fichiers de données et taille des redologs
Voici quelques facteurs supplémentaires que vous voudrez peut-être considérer qui ne sont pas liés au cœur de la mise à niveau elle-même:
Le facteur le plus important affectant la mise à niveau est probablement l'inconnu. Même lorsque la mise à niveau est pratiquée à l'avance sur un matériel similaire avec des ensembles de données similaires, etc., des choses imprévues peuvent encore se produire et peuvent considérablement affecter la durée. Dans cet esprit, vous devez imiter l'environnement de production aussi étroitement que possible pour les mises à niveau de test. Autrement dit, aussi près que votre budget le permet.
Si l'espace est le problème qui vous empêche de tester la mise à niveau, envisagez de restaurer la base de données dans une zone de test excluant certains des plus grands espaces disque logiques utilisateur. Cela ne vous donnera pas une idée exacte du temps, mais cela devrait vous donner une idée plus précise et vous permettre de travailler à travers plus d'inconnues.
Vraisemblablement, vous avez une instance de développement et de test de cette base de données exécutée sur un matériel similaire avec un volume de données similaire et les mêmes composants de base de données installés, n'est-ce pas? Et, vraisemblablement, vous allez mettre à niveau ces environnements inférieurs (et tester que les applications qui utilisent cette base de données fonctionnent toujours correctement), n'est-ce pas?
En supposant que ce soit le cas, je prendrais le temps nécessaire pour mettre à niveau la base de données de développement et l'utiliser comme estimation du temps nécessaire pour mettre à niveau les autres instances. Il existe évidemment un certain nombre de facteurs qui déterminent la durée de la mise à niveau réelle. Je suppose que le temps d'arrêt ne devrait probablement être que d'une heure ou deux, mais il vaut mieux utiliser le temps réel nécessaire pour mettre à niveau le dev.