回答:
Oracleのアップグレードに関するベストプラクティスによると30〜90分。これは、この状況ですべての未知数が与えられる最も近い見積もりです。
データベースのサイズは、アップグレードにかかる時間を決定する上で非常に重要ではありません。期間に影響する主な要因は次のとおりです（Oracle.comアップグレードブログより）。
インストールされているデータベースコンポーネントとオプションの数-インストールされているコンポーネント/オプションの数が多いほど、実行する必要のあるアップグレードスクリプトが多くなり、時間がかかります
有効で古くないディクショナリ統計-いくつかの古いリリースのOracleでディクショナリ統計を作成することは、ルールベースのオプティマイザのサポートが廃止されたのでデータディクショナリを分析する必要があるため、すばらしいアイデアではありませんでした。特にアップグレードの直前。それ以外の場合、アップグレード中にデータベースが制限付きアップグレードモードで起動されているときに、これが発生し、追加のダウンタイムが発生します。
audit_trailがDBに設定されている場合、AUD $の行数
Oracle 9iからのアップグレード時の同義語の数-同義語が変更され、DEPENDENCY $のディクショナリで新しい依存関係が取得されます-大きな数（100,000など）がある場合、これは時間がかかる可能性があります
XDB内のオブジェクトの数
COMPATIBLEが増加する場合の非常に低いレート：データファイルの数とREDOログのサイズ
アップグレード自体の中核とは関係のない、考慮すべきいくつかの追加要因を以下に示します。
おそらく、アップグレードに影響を与える最大の要因は不明な要因です。同様のデータセットなどを備えた同様のハードウェアで事前にアップグレードを実行した場合でも、予期せぬ事態が発生し、期間に大幅な影響を与える可能性があります。このことを念頭に置いて、テストアップグレードの場合と同じように本番環境を模倣する必要があります。つまり、予算が許す限り近い。
スペースがアップグレードのテストを妨げる問題である場合は、データベースをテストボックスに復元して、より大きなユーザーテーブルスペースの一部を除外することを検討してください。これはあなたにその時の正確な感触を与えることはありませんが、それはあなたにあなたにもっと近い球場を与え、あなたがより多くの未知のものを処理することを可能にするはずです。
おそらく、あなたはこのデータベースの開発とテストのインスタンスが同じようなハードウェア上で同じようなデータボリュームと同じデータベースコンポーネントがインストールされた状態で動いているでしょう？そして、おそらく、これらのより低い環境をアップグレードします（そして、このデータベースを使用するアプリケーションがまだ正しく機能することをテストします）。
その場合を想定して、開発データベースのアップグレードにかかる時間を調べ、他のインスタンスのアップグレードに必要な時間の見積もりとして使用します。明らかに、実際のアップグレードにかかる時間を決定するいくつかの要因があります。私の推測では、ダウンタイムはおそらく1〜2時間で済みますが、devのアップグレードに必要な実際の時間を使用する方がはるかに良いでしょう。