アップグレードの計画
アップグレード・プロセスには、更新と比較して追加の計画ステップが必要となり、アップグレードを適切に計画するには、アップグレードを開始する前に次の点を考慮する必要があります。
アップグレードの計画を開始する前に、次のことを考慮する必要があります:
アップグレードの計画は、次の4つのステップに分かれています:
- 新しいOracle Databaseのリリースの機能を理解します
- 新しいリリースへのアップグレード・パスを決定します
- アップグレード方法を選択します
- 新しいリリースのOracleホーム・ディレクトリを選択します
- テスト計画を作成します
- バックアップ計画を準備します
- アップグレード前の推奨事項に従います
- アップグレード前修正スクリプトを実行するか、手動によるアップグレード前システム更新を実行します
- アップグレード目標の定義: アップグレードに着手する理由は様々あります。たとえば、古いデータベース・バージョンで実行していて、問題を修正するためのオラクル社からのサポートがない場合や、コンプライアンス・ポリシーによって新しいバージョンにする必要があると示されている場合などです。いずれの理由であっても、アップグレードを成功させるには、アップグレード・プロセス、パフォーマンスの許容範囲、停止期間、使用不可によるビジネスへの影響、およびアップグレードのスケジュールに関して、明記、明言されている必要があります。
- アップグレード・ポリシーの定義: アップグレード・ポリシーでは、ロールバック・シナリオを考慮する必要があります。これらは、アップグレードの失敗、アップグレード後のデータベース・パフォーマンスの低下に関連していることがあります。また、ロールバックによってデータベースが使用不可になることも考慮する必要があります。
ロールバックと同様に、未使用のOracleホームのクリーン・アップも考慮する必要があります。アップグレードが正常に完了し、すべての参加チームがアップグレード後に結果を受け入れたら、クリーン・アップ・ポリシーに基づいて未使用のホームを削除する必要があります。
- 編成:
- イメージの量: イメージの数はできるだけ少なくすることをお薦めします。多数のイメージを保持すると、メンテナンスのオーバーヘッドが大幅に増加する可能性があります。イメージは、様々なアプリケーション・タイプ、データ・センター名または場所、アプリケーションの使用状況(テスト、開発、本番またはマスター)に基づいて作成できます。
- イメージごとにサブスクライブするターゲット: イメージ作成の基準に基づいて、ターゲットのイメージ・サブスクリプションについても同様の基準に従うことができます。ERPなどの特定のアプリケーション・タイプ用にゴールド・イメージを保持し、すべてのERPサポート・データベースをこのイメージにサブスクライブできます。
- 統合計画: アップグレードは、データベース資産を再編成する機会です。可能なかぎり統合し、データベースの数を減らすことを目指して、マルチテナントが前進への道となります。複数の固有データベースを1つ以上のコンテナ・データベース(CDB)に統合してみてください。
- SQLパフォーマンス分析の準備: データベースのアップグレード後にパフォーマンスが低下しているSQL問合せを確認、分析および修正できるように、SQLパフォーマンスのベンチマークを設定することが重要です。