| Oracle® Databaseアップグレード・ガイド 12cリリース1 (12.1) B71306-08 |
|
 前 |
 次 |
Oracle Databaseをアップグレードする前に、要件および推奨事項を理解する必要があります。この章では、アップグレードに備えて新しいOracleソフトウェアをインストールするなどのアップグレード前の作業に関する情報および手順について説明しています。
この章の内容は次のとおりです。
Oracle Databaseのアップグレードに備えて、新しい機能を確認し、使用する最適なアップグレード・パスおよびアップグレード方法を決定します。アップグレード処理をテストし、バックアップ計画を準備することをお薦めします。
データベースのアップグレードの準備をするために、次の作業を実行します。
アップグレード処理を計画する前に、新しいOracle Databaseリリースの機能を理解します。Oracle Databaseのリリース間の相違点については、『Oracle Database新機能ガイド』を参照してください。また、特定のコンポーネントの新機能については、Oracle Databaseのドキュメント・ライブラリにある固有のガイドを参照してください。たとえば、Oracle Real Application Clustersの変更点については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。
|
注意: Oracle Databaseで使用可能な機能を活用する方法を習得するには、Oracle Databaseのトレーニング・クラスを受講することが最適です。詳細は、http://education.oracle.com/で説明されています。 |
Oracle Database 12cの最新リリースにアップグレードするために必要なパスは、現行のデータベースのリリース番号によって異なります。現行のOracle Databaseがリリース10.2.0.5、11.1.0.7または11.2.0.2以上の場合、新しいリリースへの直接のアップグレードを実行できます。リリース12.1.0.1から12.1.0.2へは直接アップグレードできます。
現行のOracle Databaseが10.2.0.5より前のリリースまたはリリース11.2.0.1の場合は、Oracle Databaseの現行のリリースから最新リリースへの直接のアップグレードはサポートされていません。この場合、Oracle Database 12cにアップグレードする前に、中間リリースにアップグレードする必要があります。
たとえば、アップグレード元となるデータベースでOracle Database 9iを実行している場合は、次の手順に従います。
10gリリース2 (10.2)の『Oracle Databaseアップグレード・ガイド』の指示に従って、リリース9.0.1.4からリリース10.2.0.5へアップグレードします。
『Oracle Databaseアップグレード・ガイド』(このマニュアル)の指示に従って、Oracle Database 10g リリース2 (10.2.0.5)を新しいOracle Database 12cへ直接アップグレードします。
表2-1に、Oracle Databaseのリリースごとに必要なアップグレード・パスを示します。Oracle Database 12cに完全にアップグレードする前に、ご使用のデータベースのアップグレード・パスおよび指定されたドキュメントを使用して中間アップグレードを実行します。
表2-1 Oracle Database 12cのアップグレード・パスの例
| 現行リリース | ダイレクトまたは中間アップグレード・パス |
|---|---|
|
12.1.0.1、11.2.0.2以上 11.1.0.7 10.2.0.5 |
直接のアップグレードがサポートされています。現行の『Oracle Databaseアップグレード・ガイド』(このマニュアル)を使用してアップグレードを実行します。 |
|
11.2.0.1 11.1.0.6 10.2.0.2、10.2.0.3および10.2.0.4 10.1.0.5 9.2.0.8以下 |
Oracle Database 12cへの直接のアップグレードはサポートされていません。 解決策: 新しいOracle Database 12cへアップグレードする前に、(リリース12.1に直接アップグレード可能な) Oracle Databaseの中間リリースにアップグレードします。これには、Oracle Data Pumpのエクスポート/インポートを使用したアップグレードは含まれません。Oracle Databaseの中間リリースのドキュメントの指示に従って、中間リリースへアップグレードします。次に、第3章「Oracle Databaseのアップグレード」の指示に従って、中間リリースのデータベースを新しいOracle Database 12cリリースにアップグレードします。 次に例を示します。
|
データベースのアップグレードには、最良の方法としてDatabase Upgrade Assistant (DBUA)を使用することをお薦めします。ただし、企業の複雑さを支えるご使用のデータベースを完全にアップグレードするための様々な方法が提供されています。データのアップグレードと移行の違いに関する定義および説明は、「Oracle Databaseのアップグレード・ツールおよびアップグレード処理の概要」を参照してください。
データベースを新しいOracle Databaseリリースにアップグレードする際に使用できるアップグレード方法は次のとおりです。
Database Upgrade Assistant (DBUA)は、対話形式でアップグレード処理の手順を実行し、新しいOracle Databaseリリースのデータベースを構成します。DBUAを使用すると、通常は手動で実行するアップグレード処理のすべてのタスクが自動化されます。DBUAでは、表領域、REDOログなどの構成オプションの適切な推奨値が提供されます。ユーザーは、この推奨値を使用できます。
Oracle Real Application Clusters (Oracle RAC)環境では、DBUAは、すべてのデータベースをアップグレードするわけではありません。DBUAは、クラスタ内のすべてのノードにあるすべてのデータベース・ファイルおよび構成ファイルをアップグレードします。
手動アップグレードでは、コマンドラインからSQLスクリプトおよびユーティリティを実行して、データベースを新しいOracle Databaseリリースへアップグレードします。
手動アップグレードでは、アップグレード処理をより詳細に制御できますが、実行されなかったアップグレード手順またはアップグレード前の手順がある場合、または不適切な順序で実行された場合にエラーが発生する可能性がより高くなります。
次のリストに、手動のアップグレード手順の概要を示します。
アップグレード前情報ツールを使用して、データベースを分析します。アップグレード前情報ツールは、Oracle Databaseに付属するSQLスクリプトであり、DBUAでは、アップグレード処理の一部としてこのスクリプトが使用されます。アップグレード対象のデータベースで、アップグレード前情報ツールを実行します。
アップグレード前情報ツールでは、データベースで発生する可能性のあるアップグレードの問題に関する警告が表示され、問題に対処するために使用する修正スクリプトも生成されます。また、新しいリリースのOracle Databaseで必要な初期化パラメータの情報も表示されます。
新しいOracleホームを準備します。
データベースのバックアップを実行します。
アップグレードしているデータベースのリリースに応じて、追加のアップグレード前の手順(アップグレードに向けたパラメータ・ファイルの調整、サポートが終了した初期化パラメータの削除およびアップグレードの問題が発生する可能性のある初期化パラメータの調整)が必要な場合があります。
アップグレードのスプール・ログ・ファイルを確認し、アップグレード後の状態ツール(utlu121s.sql)を使用します。アップグレード後の状態ツールは、Oracle Databaseに付属するSQLスクリプトです。アップグレード後の状態ツールは、新しいリリースの環境で実行します。アップグレード後の状態ツールは、データベースのアップグレード後にいつでも実行できます。
DBUAまたは手動のコマンドライン・アップグレードとは異なり、Oracle Data Pump ExportおよびImportユーティリティは、現行のデータベースのデータのコピーを新しいリリースの新しいデータベースに物理的に移行します。データ・ポンプ・エクスポートおよびインポートは、パフォーマンスの向上と新しいデータ型の確実なサポートの点で推奨されています。
エクスポート・ダンプ・ファイルの内容をロードする前に、新しいデータベースが存在している必要があるか、新しいOracleホームにデータベースが作成されている必要があります。
以前のリリースからデータをインポートする場合、新しいOracle Databaseリリースのインポート・ユーティリティでは、以前のリリースのエクスポート・ダンプ・ファイルを読み込む際に、データ定義に適切な変更を加えます。
|
注意:
|
エクスポート/インポートによるデータ移行方法では、現行のデータベースが変更されないため、データベースはアップグレード処理を通して常に使用可能な状態です。ただし、一貫性のあるデータベースのスナップショットが必要な場合(データの整合性保持またはその他の目的のため)、データベースは、制限モードで実行するか、またはエクスポート手順の実行中は変更禁止にする必要があります。現行のデータベースを使用可能な状態にしておくことができるため、たとえば、既存の本番データベースを実行しながら、新しくアップグレードしたOracle Databaseのデータベースの作成とエクスポート/インポートを同時に行うことができます。このアップグレード処理中にデータベースの完全な一貫性を維持するには、新しくアップグレードしたOracle Databaseのデータベースにも同じ変更を加えないかぎり、データベースのデータを変更できないようにします。
最も重要なことは、エクスポート/インポート操作の結果として、新しいデータベースが作成されることです。現行のターゲット・データベースには最終的に指定した移行済のデータのコピーが含まれますが、アップグレードしたデータベースは、元のソース・データベースとは異なる方法で運用される場合があります。たとえば、エクスポート/インポート操作によってデータベースと同一のコピーを作成しても、データのディスク配置やチューニング・パラメータの解除など、その他の要素が予期しないパフォーマンスの問題につながることがあります。
Oracle Databaseのアップグレード時のエクスポート/インポートを使用したデータ移行では、パフォーマンスを向上するためのデータベースの圧縮および再構築といった利点があります。
エクスポート/インポートを使用したデータの移行:
データの断片化を解消できます。インポートされたデータを圧縮することによって、パフォーマンスを向上できます。
データベースを再構築できます。新しい表領域を作成するか、または既存の表や表領域、インポートによってデータがロードされる先のパーティションを変更できます。
完全に新しいデータベースが作成されるため、Oracle Databaseの新旧リリースの比較テストを行うことができます。
指定されたデータベース・オブジェクトまたはユーザーをコピーできます。オブジェクト、ユーザーおよびその他の必要な項目のみをインポートすると、本番データのサブセットにのみ新規ソフトウェアのテスト環境を確立する場合に役に立ちます。データ・ポンプ・エクスポート/インポートでは、データのサブセット化機能を柔軟に使用できます。
バックアップ・アーカイブとして機能します。データベースの全体エクスポートを現行のデータベースのアーカイブとして使用できます。
アップグレードするデータベースをサポートしていないオペレーティング・システムまたはハードウェア・プラットフォーム上に、アップグレードしたデータベースを確立できます。
ネットワーク・ベースのデータ・ポンプ・インポートにより、新規Oracle Databaseは、アップグレード対象の古いデータベースからネットワークを介して直接ロードできます。したがって、ダンプ・ファイルが介在する必要はありません。
新しいリリースのOracle Databaseに、現行のリリースのOracleホームとは別のOracleホームの場所を選択する必要があります。新しいソフトウェアを現行のリリースと同じOracleホームの場所にインストールすることはできません。
別のインストール場所を使用すると、新しいOracleソフトウェアとともに、既存のOracleソフトウェアをインストールしたままにできます。この方法によって、本番環境全体を置き換える前にテスト・データベース上でアップグレード処理をテストできます。
アップグレード処理のすべての段階を検証するために、一連のテストを慎重に設計する必要があります。緻密なテストを正常に完了できれば、本番データベースのアップグレード処理を十分に理解し、予測できるようになり、アップグレード処理の成功が確実になります。本番データベースをアップグレードする前に、できるだけ多くのテストを実行してください。完全で反復可能なテスト処理は、非常に重要です。
データベース・リプレイやSQLパフォーマンス・アナライザなどのOracle Real Applicationのテスト機能を使用するか、または手動でテストを実行するかにかかわらず、実行するテストのタイプは同じです。
テスト計画には次のタイプのテストを含める必要があります。
Oracle Databaseのアップグレード・テストでは、DBUAの使用、手動アップグレードの実行、エクスポート/インポートまたはその他のデータのコピー方法を使用するかに関係なく、現行のソフトウェアからOracle Database 12cへのアップグレード・パスを計画およびテストする必要があります。どのアップグレード方法を選択する場合でも、アップグレード計画を作成、テストおよび検証する必要があります。
Oracle Databaseの最小テストでは、現行のデータベースからアプリケーションの全部または一部を新しいデータベースに移動し、データベースの新機能を使用可能にしないでアプリケーションを実行します。最小テストでは、実際の本番環境で発生するような問題が検出されない場合があります。ただし、アプリケーションの起動または呼出しに関する問題がある場合は、すぐに検出されます。
Oracle Databaseの機能テストとは、システムの新機能と既存機能をアップグレード後にテストする一連のテストです。機能テストには、すべてのデータベース、ネットワーキングおよびアプリケーション・コンポーネントのテストが含まれます。機能テストの目的は、システムの各コンポーネントがアップグレード前と同様に機能し、新機能が正常に動作していることを検証することです。
Oracle Databaseの高可用性テストでは、アップグレードしたシステムが、Recovery Time Objective (RTO)およびRecovery Point Objective (RPO)のビジネス要件を満たしていることを確認します。
Oracle RAC環境では、ストレス・テスト中にノードまたはインスタンスの挿入に失敗した場合、この事実からOracle RACのリカバリ可能性が変化したかどうかを評価することができます。
停止時間を最小化するために、フォールバック計画および手順をテストすることをお薦めします。
割り当てた時間内にアップグレード処理が実行されるように、データベースのパフォーマンスおよび安定性を確認し、パフォーマンスの問題を解決することをお薦めします。
Oracle Databaseの統合テストでは、システムのコンポーネント間で相互作用をテストします。
統合テストを計画するときは、次のことを考慮する必要があります。
Oracle Database 12cのインスタンスで稼働するPro*C/C++アプリケーションは、新しいソフトウェアで問題がないことを確認するためにテストする必要があります。Pro*C/C++アプリケーションの詳細は、『Pro*C/C++プログラマーズ・ガイド』を参照してください。
Graphical User Interfaceを他のコンポーネントでテストする必要があります。
新しいOracle Database 12cのインスタンスにアプリケーションが直接接続されるかどうかに関係なく、データ型やデータ・ディクショナリのデータ(データ・ディクショナリへの行の追加、オブジェクト型の変更)などのOracle Database 12cのわずかな変更でも、フロントエンド・アプリケーションにまで影響することがあります。
2つのコンポーネントがOracle NetまたはOracle Net Servicesを使用して接続されている場合は、ストレス・テストとともにその接続のテストも行う必要があります。Oracle Net Servicesのアップグレードに関する推奨事項については、『Oracle Database Net Servicesリファレンス』を参照してください。
Oracle Databaseの新しいデータベースのパフォーマンス・テストでは、新しいデータベースでの様々なSQL文のパフォーマンスを、現行データベースでの同じ文のパフォーマンスと比較します。アップグレードする前に、現行データベースでのアプリケーションのパフォーマンス・プロファイルを理解する必要があります。特に、アプリケーションがデータベース・サーバーに対して実行するコールを理解する必要があります。
この項では、次のようなパフォーマンス・テストについて説明します。
新しいデータベース・リプレイ機能を使用して、本番データベースを実際にアップグレードする前に、ユーザーのサイトの本番ワークロード上でデータベースをアップグレードする現実的なテストを実行できます。この機能は、本番システム上で実際のデータベースのワークロードを取得して、これをテスト・システム上でリプレイします。また、データベース・リプレイでは、潜在的な問題(エラーの発生やパフォーマンスの相違など)を示す分析とレポート作成も提供されます。さらに、自動データベース診断モニター、自動ワークロード・リポジトリ(AWR)およびアクティブ・セッション履歴など、定期的なEnterprise Managerパフォーマンスの監視およびレポート作成ツールをすべて使用して、問題に対処します。
|
注意: データベース内のストアド・プロシージャのロジックは変更できますが、アプリケーション・ロジックを実装しているストアドPL/SQLプロシージャでは、アップグレード前と同じインターフェースを維持する必要があります。アプリケーションのストアド・プロシージャがアップグレードによって影響を受ける場合は、ワークロードをリプレイできない場合があります。このようにデータベース・リプレイ・ツールを使用すると、サーバー内の新しいアプリケーション・ロジックがアップグレード後にも期待どおりに動作するかどうかを確認でき、有効な診断が行えます。 |
|
関連項目:
|
SQLパフォーマンス・アナライザを使用して、システムの変更がSQLワークロードに及ぼす影響を予測できます。SQLパフォーマンス・アナライザでは、アップグレードによって影響を受けたSQL文を識別してパフォーマンスの相違を測定することで、データベースのアップグレードなどの変更による影響を予測できます。分析により、アップグレードによるSQLパフォーマンスに対する全体的な影響を評価し、悪い結果をユーザーが影響を受ける前に回避できます。
|
関連項目: 潜在的なデータベース変更のWhat-if分析にSQLパフォーマンス・アナライザを使用した詳細および例は、『Oracle Database Testingガイド』を参照してください。 |
新しいオプティマイザ・バージョンをインストールするデータベース・アップグレードでは、通常、SQL文に対して若干の計画変更がありますが、ほとんどの計画変更ではパフォーマンスは変化しません。ただし、ある一部の計画変更では、パフォーマンスが低下する場合があります。SQL計画管理では、SQL計画の情報を取得、選択および展開するためのコンポーネントを提供することで、SQL文の実行計画が急に変更された場合に起こるパフォーマンスの低下を回避できます。SQL計画管理は、一定期間におけるSQL文の実行計画を記録および評価する予防的メカニズムであり、効率的であることが確認されている既存の計画で構成されたSQL計画のベースラインを構築します。SQL計画のベースラインは、システムで発生している変更に関係なく、対応するSQL文のパフォーマンスを保持するために使用されます。
SQL計画管理を使用すると、オプティマイザによって実行計画が自動的に管理され、既知の計画または検証済の計画のみが使用されます。SQL文に対する新しい計画が検出されても、その計画が現行の計画と同等かそれ以上のパフォーマンスであることがデータベースによって確認されるまでは使用されません。そのため、SQL計画管理を現行の実行計画でシードすると、これらは各文のSQL計画のベースラインになり、これらの計画は、オプティマイザによってアップグレード後に使用されます。異なる計画を使用する必要があるとOracle Database 12cオプティマイザが判断した場合でも、新しい計画は検証のためにキューに格納され、現行の計画と同等かそれ以上のパフォーマンスを実現できる計画であることが確認されるまでは、使用されません。
SQL管理ベース(SMB)を実行計画にシードまたは移入するには、複数の方法があります。
カーソル・キャッシュからのSQL管理ベースのバルク・ロード
実行計画またはSQL計画ベースラインのカーソル・キャッシュからのバルク・ロードは、データベースをOracle Database 11gからOracle Databaseの最新リリースにアップグレードする場合に役立ちます。カーソル・キャッシュは共有SQL領域で、バルク・ロードされるSQL計画は、自動的にそのまま使用され、SQL計画ベースラインとして既存または新規の計画履歴に追加されます。
Oracle Databaseのソース・リリースでは、DBMS_SPM.LOAD_PLAN_FROM_CURSOR_CACHEプロシージャまたはOracle Enterprise Managerを使用して、カーソル・キャッシュ内の実行計画をすべてSQL管理ベースにロードします。
データベースをアップグレードします。
|
関連項目: 共有SQL領域からPL/SQLまたはOracle Enterprise Managerを使用して計画をロードする方法の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
SQLチューニング・セット(STS)を使用したSQL管理ベースのバルク・ロード
実行計画またはSQL計画のベースラインのバルク・ロードは、SQLチューニング・セットを使用して実行できる場合があります。これは、カーソル・キャッシュから直接ロードするため、または自動ワークロード・リポジトリから履歴計画をロードするためのSQL Management Base (SMB)がないOracle Database 10gからアップグレードを行う場合に役立ちます。
Oracle Databaseのソース・リリースで、各SQL文の実行計画を含むSTSを作成します。
STSをステージング表にロードし、ステージング表をダンプ・ファイルにエクスポートします。
ステージング表をダンプ・ファイルからOracleの新しいリリースにインポートし、STSをアンロードします。
Oracle Enterprise ManagerまたはDBMS_SPM.LOAD_PLANS_FROM_SQLSETを使用して、実行計画をSQL管理ベースにロードします。
|
関連項目: 実行計画またはSQL計画のベースラインのバルク・ロードの詳細な手順は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
すべての重要なSQL問合せをOracle Databaseのテスト環境でテストおよびチューニングしてから、そのSQL実行計画をOracle Databaseの本番環境に移動できます。または、アップグレード前Oracle Databaseの本番環境からSQL問合せの計画を実行してから、アップグレード後の本番環境にそれらを移動できます。
Oracle Database 12cのテスト・システムで、すべてのテストとチューニングを完了してから、DBMS_SPM.LOAD_PLAN_FROM_CURSOR_CACHEプロシージャまたはEnterprise Managerを使用して、カーソル・キャッシュ内の実行計画をすべてSQL管理ベースにロードします。
DBMS_SPM.PACK_STGTAB_BASELINEファンクションを使用して、手順1で作成したSQL計画ベースラインをステージング表に格納します。
データ・ポンプを使用して、ステージング表をフラット・ファイルにエクスポートします。
このフラット・ファイルをターゲット・システムに転送します。
データ・ポンプを使用して、フラット・ファイルからステージング表をインポートします。
DBMS_SPM.UNPACK_STGTAB_BASELINEファンクションを使用して、ステージング表からターゲット・システムのSQL管理ベースにSQL計画ベースラインを展開します。
|
関連項目:
|
ボリューム/ロード・ストレス・テストでは、アップグレードしたOracle Database全体を、大きいボリュームとロードでテストします。ボリュームとは、操作されるデータの量を表します。ロードとは、システム上の同時要求のレベルを表します。ボリューム/ロード・ストレス・テストの目的は、様々なボリュームとロードでの本番システムの動作をエミュレートすることです。
ボリューム/ロード・ストレス・テストは非常に重要ですが、一般に見過ごされがちです。ユーザーは、どのようなボリューム/ロード・ストレス・テストも実行しないことが多いようです。そのかわりに、ビジネス・アプリケーションを特に考慮しているわけではないベンチマークが広く利用されています。アプリケーションのベンチマークは、機能、パフォーマンスおよび統合に関する問題点を検証するために使用するものであり、ボリューム/ロード・ストレス・テストのかわりになるものではありません。
ロード・テストには、本番稼働時に発生する可能性のあるロード条件で新しいエラーやパフォーマンス上の問題などがアプリケーションに発生しないことを確認するため、新リリースのデータベースに対するアプリケーション・ロードの実行を含みます。多くの場合、問題は特定のロード条件で明らかになるため、通常、機能テストでは見つかりません。データベース・リプレイ機能は、本番環境のシステム・ワークロードを取得し、テスト・システム上で同一形式でリプレイできるため、このようなロード・テストに最適です。
|
関連項目: ストレス・テストでのデータベース・リプレイの使用の詳細は、『Oracle Database Testingガイド』を参照してください。 |
アップグレードが最終的に成功するかどうかは、適切なバックアップ計画の立案と実行で決まります。
バックアップ計画を展開するには、次のような問題について考慮する必要があります。
業務上、本番データベースの実行不可能状態の許容範囲がどの程度の期間か。
可用性要件を満たすには、どのバックアップ計画が必要か。
サイトから離れた安全な場所にバックアップをアーカイブする必要があるか。
どのくらいの時間でバックアップをリストアできるか(オフサイト記憶域でのバックアップを含む)。
リカバリ手順は正常にテストされているか。
バックアップ計画は、これらの問題のすべてに答え、データベースを正常にバックアップおよびリカバリするための手順を備えている必要があります。
|
ヒント: RMANを使用したバックアップ計画の実装の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
オペレーティング・システムおよびデータベース環境のOracleコンポーネントに応じた、注意する固有の情報および要件があります。
次の各項目では、アップグレードの実行に関するシステムの推奨事項および要件について説明します。
|
関連項目:
|
古いOracle環境を削除する前に、古いOracle環境にあるデータ・ファイルをすべて新しいOracle Database環境に再配置する必要があります。
データ・ファイルを新しいOracle Database環境に再配置するには、次を行います。
Database Upgrade Assistant(DBUA)を使用し、アップグレード中に「データベース・ファイルの移動」オプションを選択します。
|
関連項目: 手動でアップグレードを行う場合は、『Oracle Database管理者ガイド』でデータ・ファイルの再配置の詳細を参照してください。 |
現在のリリースにアップグレードしようとしているデータベース上にすでにインストールされているパッケージは、自動的にアップグレードされない場合があります。パッケージが現在のリリースで使用可能かどうかを個別に確認し、そのパッケージを再インストールして最新バージョンにする必要があります。
新しいリリースにアップグレード後にダウングレードしてOracle Enterprise Manager Database Control (DB Control)をリストアできるようにする必要がある場合は、データベースをアップグレードする前に、構成ファイルおよびデータを保存する必要があります。Oracle Database 12c以上では、アップグレード処理の一部としてDB Controlは削除されます。データベースをアップグレードする前にDB Controlの制御ファイルとデータのコピーを保存するためのemdwgrdユーティリティが提供されています。これは、ダウングレードできるようにし、以前のデータベースからDB Controlの構成ファイルをリストアする場合に必要です。
emdwgrdユーティリティは、新しいOracle Database 12cリリースのORACLE_HOME/binディレクトリにあります。emdwgrdユーティリティは、LinuxとUNIX用のemdwgrdとemdwgrd.plおよびWindows用のemdwgrd.batとemdwgrd.plで構成されています。ユーティリティを実行する前に、Oracle Database 12cのソフトウェアをインストールして、新しいOracleホームからスクリプトを起動する必要があります。emdwgrdユーティリティでは、ORACLE_HOMEがアップグレード対象のリリースのOracleホームに設定されている必要があります。
emdwgrdを使用してDB Controlのファイルとデータを保存するには、次の手順を実行します。
新しいOracle Database 12cリリースのソフトウェアをインストールします。
ORACLE_HOMEを古いOracleホームに設定します。
ORACLE_SIDを、アップグレードするデータベースのSIDに設定します。
PATH、LD_LIBRARY_PATHおよびSHLIB_PATHが、アップグレードするデータベースのOracleホームを指すように設定します。
新しいOracle Database 12cリリースのOracleホームに移動します。
次のように、emdwgrdを実行します。
単一インスタンスのデータベースの場合は、次のコマンドを実行します。このとき、old_SIDはアップグレードするデータベースのSIDで、save_directoryはデータベースの制御ファイルとデータの格納場所として選択した場所へのパスです。
emdwgrd -save -sid old_SID -path save_directory
|
注意: このスクリプトは、LinuxおよびUNIXプラットフォーム場合、emdwgrd.shにあります。Windowsの場合、このスクリプトはemdwgrd.batにあります。 |
データベースがOracle RACデータベースの場合は、クラスタ・ノード間のリモート・コピーが必要です。構成済のリモート・コピーを示す環境変数を定義します。次に例を示します。
setenv EM_REMCP /usr/bin/scp
次に、emdwgrdを次のように実行します。
emdwgrd -save -cluster -sid old_SID -path save_directory
Oracleホームが共有デバイス上にある場合は、前述のコマンドラインに-sharedを追加します。
アップグレードするデータベースのSYSパスワードを入力します。
|
注意: データベースをアップグレードした後に、DBUAバックアップおよびリストア処理を使用して、以前のOracle Enterprise Manager Database Control環境に戻すことも可能です。ただし、アップグレードしてからリストアするまでの間に蓄積されたユーザー・データは、すべて失われます。データベースの制御ファイルおよびデータを保存しておくことで、データベースとDB Controlの両方をダウングレードできます。アップグレードしてからダウングレードするまでの間に蓄積されたDB Controlのデータはすべて失われますが、すべてのユーザー・データが保持されます。 |
アップグレード処理中の停止時間を最小化するには、アップグレード前準備の一部として、オプションでemremove.sqlスクリプトを実行できます。emremove.sqlスクリプトは、Oracle Enterprise Manager関連のスキーマおよびオブジェクトを削除します。このスクリプトは、処理の完了までに6つのフェーズがあるため、完了に数分かかる場合があります。このスクリプトは、SYSMANがあり、関連するセッションがSQL*Plus、Oracle Enterprise Managerまたはその他のクライアントからアクティブの場合に、さらに長くかかる場合があります。
|
重要: ダウングレードおよびDB Controlをリストアする場合は、「Oracle Enterprise Manager Database Controlの構成およびデータの保存」に従って、DB Controlの構成およびデータをバックアップする必要があります。 |
DB Controlを手動で削除するためにemremove.sqlを実行するには、次の手順を行います。
DB Controlアプリケーションをただちに停止します。
$ emctl stop dbconsole
SQL*Plusを起動し、SYSDBAとしてSYSアカウントを使用してデータベースに接続します。
オプションの手順です。このスクリプトをサイレント・モードで実行する場合は、これを設定しないでください。実行中のemremove.sqlの進行状況を確認するには、次の変数を設定します。
SET ECHO ON; SET SERVEROUTPUT ON;
emremove.sqlを実行します。このスクリプトは、新しいOracle Database 12cのOracleホームのORACLE_HOME/rdbms/admin/にあります。
$ @emremove.sql
emremove.sqlの完了後、ファイル・システムからORACLE_HOME/HOSTNAME_SIDディレクトリおよびORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_HOSTNAME_SIDディレクトリを手動で削除する必要があります。
|
注意: DB Controlがリリース10.2.0.3から10.2.0.4にアップグレードされた場合は、次のディレクトリもファイル・システムから削除する必要があります。
|
Windowsプラットフォームでは、通常、OracleDBConsoleSIDという名前のDatabase Consoleサービスも削除します。
Oracle Grid InfrastructureのOracle Universal Installer (OUI)を使用してOracle ASMインスタンスをアップグレードすることをお薦めします。OUIは、以前のリリース・レベルのOracle ASMインスタンスを検出すると、自動的にアップグレード・モードに切り替わります。Oracle Database 11g以上を実行している環境では、クラスタ化されたOracle ASMインスタンスに対してローリング・アップグレードを実行することもできます。Oracle ASMのローリング・アップグレードの実行手順の詳細は、ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。
|
関連項目: Oracle ClusterwareまたはOracle Automatic Storage Managementのローリング・アップグレードの詳細は、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
Oracle ClusterwareおよびOracle Real Application Clusters (Oracle RAC)は、既存のインストールとは別の新しいホームにインストールする必要があります。これにより、クラスタ内のノードのアップグレードに必要な停止時間が短縮され、企業内のクラスタのプロビジョニングが容易になります。クラスタのアップグレードに必要な計画停止時間を短縮することで、可用性サービス・レベルを満たし、企業全体への標準インストールを簡単に行うことができます。
|
関連項目: Oracle ClusterwareおよびOracle Automatic Storage Managementのアップグレードの実行方法の詳細は、オペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』および付録を参照してください |
Oracle Clusterware、Oracle Grid InfrastructureおよびOracle ASMインスタンスのアップグレードに関する推奨事項を次に示します。
Oracle Databaseをアップグレードするには、Oracle Grid Infrastructureソフトウェアを新しいGridホームに、およびOracle Database 12cソフトウェアを新しいOracleホームにインストールする必要があります。これは、スタンドアロン・サーバー(Oracle Restart)用のOracle Grid Infrastructureにも適用されます。サポートされているリリースからのみアップグレードできます。「Oracle Databaseのアップグレード・パスの決定」を参照してください。
Windows x64プラットフォームで、Oracle Clusterwareをリリース10.2.0.5および11.1.0.7からリリース12.1にアップグレードするには、Oracle Clusterwareで11.2.0.3への個別アップグレードを実行する必要があります。Oracle Clusterwareのリリース11.2.0.3へのアップグレード後に、Oracle Cluster Registry (OCR)および投票ファイル(VDSK)をOracle ASMに移動する必要があります。その後、Oracle Clusterwareをリリース11.2.0.3からリリース12.1にアップグレードできます。
WindowsまたはRAWデバイスのOCFSにOracle Clusterwareファイルを格納するOracle Databaseリリース10.2.0.5またはリリース11.1.0.7環境をアップグレードする場合、Oracle Database 12cへ直接アップグレードすることはできません。「Oracle Databaseリリース10.2または11.1およびOCFSとRAWデバイスのアップグレードの概要」を参照してください。
Oracle Databaseのリリース10.2.0.5では、Oracleユーザー(通常、oracle)がすべてのOracleソフトウェア・インストールを所有していた、またはOracle Databaseソフトウェアはoracleが所有し、Oracle Clusterwareソフトウェアは別のユーザー(通常、crsuser)が所有していました。
Oracle Databaseのリリース11.1以上では、リリース10.2.0.5のOracle Clusterwareソフトウェアの所有者として指定されたユーザー・アカウントが、Oracle Clusterwareリリース11.1.0.7のアップグレードを実行する必要があります。このアップグレードを実行するユーザー・アカウントは、以前のリリースのASMホームを所有するユーザーでもある必要があります。以前のASMホームの所有者が異なる場合、アップグレードを実行する前に所有者アカウントを変更する必要があります。
Oracle Databaseリリース11.1.07および10.2.0.5では、構成にOracle ASMが含まれていない場合は、クラスタ同期サービス(CSS)デーモンを停止し、deleteオプションを指定してlocalconfigコマンドを実行することによって、システムからCSSサービスを削除する必要があります。次に例を示します。
ORACLE_HOME/bin/localconfig delete
Oracle Clusterwareのアップグレード時に、OUIによってOracle ASM Configuration Assistant (ASMCA)が自動的にコールされ、Oracle Grid Infrastructureホームへのアップグレードが実行されます。Grid Infrastructureホームは、各ノードに対してローカルにできます。
単一インスタンス構成では、Oracle ASMおよびOracle Restartは、Oracle Grid Infrastructureホームから実行されます。このため、Oracle ASMおよびOracle Restartは、Oracle Grid Infrastructure 12cに同時にアップグレードされます。
Oracle ASMディスク・グループのデータベース互換性属性が、init.oraで設定されている互換性パラメータと同じであることを確認する必要があります。
|
関連項目: ご使用のオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』 |
Oracle Database 12c以上では、Oracle Real Application Clustersの非ローリング・アップグレードで、ローカル・ノード上のOracle Clusterwareが起動および稼働している必要があります。ローカル・ノード上のOracle Clusterwareスタックは稼働している必要があります。
Oracle Databaseの以前のリリースでは、クラスタの非ローリングは、アップグレード処理の開始前に、OUIによってすべてのスタック停止で、ISROLLINGがfalseに設定されていることを意味します。クラスタ・ノードのいずれかが起動していた場合は、ISROLLLINGはtrueに設定されました。ただし、Oracle Database 12cでは、ローリングは、アップグレード前にローカル・スタックが起動していて、その他のスタックは停止している必要があるという意味です。この状況においてのみ、OUIによってISROLLINGがfalseに設定されます。
ローカル・ノード上のOracle Clusterwareを起動するには、次の手順を実行します。
Oracle Clusterwareスタックが稼働しているノード上でOUIインストーラを実行するか、端末を開きます。
rootまたは管理者としてログインします。
Oracle Clusterwareホーム(Gridホーム)にディレクトリを変更(cd)し、次のコマンドを入力してOracle Clusterwareを起動します。
# crsctl start crs
Database Upgrade Assistant(DBUA)を使用して、既存のOracle RACデータベースをOracle Databaseの現行リリースにアップグレードできます。DBUAの指示に従ってアップグレード処理を実行し、新しいリリースのデータベースを構成します。DBUAがアップグレード処理を自動化し、表領域およびオンラインREDOログ・ファイルなどの構成オプションに対する適切な推奨を作成します。
手動でOracle RACデータベースをアップグレードする場合、ほとんどの処理はシステムの1つのノードのみで実行する必要があります。複数のノードで実行する必要がある処理については、該当する手順に示されています。
|
関連項目: ご使用のオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』 |
『Oracle Grid Infrastructureインストレーション・ガイド』のアップグレードの付録で説明する強制クラスタ・アップグレード・コマンドを使用する場合、この項の情報を適用します。
Oracle Database 12c以上では、アクセス不可能ノードの削除(以前のリリースでは必要)の代替手段として、アクセス不可能ノードを追加するオプションがあります。このノードに新しいOracle Database 12cソフトウェアをインストールしておく必要があります。
アクセス不可能ノードまたは到達不可能ノードで、次のコマンドを実行すると、このノードをアップグレードし、クラスタに追加することができます。
rootcrs.pl -join -existingNode upgraded_node
このコマンドのupgraded_node変数は、すでにアップグレードされているクラスタ内のノードの1つを参照します。-existingNode引数は、アップグレードされたノードを指定する必要があります。
Oracle Clusterware 12cのOracle Clusterwareでは、Oracle RACのデプロイ時にクラスタ内のすべてのノードで時間の同期を行う必要があります。
時間の同期には2つの方法があります。
|
関連項目: NTPおよびOracleクラスタ時刻同期化サービスの構成の詳細は、オペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
Oracle ASMは、Oracle Grid Infrastructureコンポーネントのインストール時にインストールされます。Oracle ASMは、Oracle RACとともにクラスタにインストールされた場合はOracle Clusterwareと、スタンドアロン・サーバーにインストールされた場合はOracle RestartとOracleホームを共有します。新しいOracle Databaseのソフトウェアがシステム上にインストールされる前に、Oracle Grid InfrastructureをアップグレードするためのrootスクリプトによってOracle ASM Configuration Assistant (ASMCA)が起動され、Oracle ASMが新しいリリースにアップグレードされます。
既存のOracle ASMインスタンスがある場合は、Oracle Grid Infrastructureをインストールするとき、またはインストール後にASMCAを使用してアップグレードできます。Oracle Database 12cの新しいソフトウェアのインストール時に、クラスタが検出されると、Oracle Universal Installer (OUI)によってスクリプトroot.shが実行されます。OUIでは、クラスタのノード上でrootスクリプトの実行作業を自動化するためのオプションが提供されています。OUIによるroot.shスクリプトの自動的な実行を可能にするための情報およびパスワードの入力が求められます。今後は、クラスタのノード上でroot.shスクリプトの実行作業を自動化するためのオプションが使用できます。
Oracle Automatic Storage Management (Oracle ASM)環境では、共有ASMパスワード・ファイルを作成できます。パスワード・ファイルは、ORAPWDユーティリティによって作成されます。ディスク・グループでの共有パスワード・ファイルの管理の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。SYSASM権限を使用して、データベース管理の職責とストレージ管理の職責を分離することをお薦めします。さらに、Oracle ASMおよび各データベースに対して異なるオペレーティング・システム資格証明を作成することもできるようになっています。これにより、データベース管理の職責とストレージ管理の職責をさらに厳重に分離することが可能になります。たとえば、あるノード上のOracle ASMを使用しているデータベースがn個ある場合、SYS権限を持つメンバーのオペレーティング・システム資格証明グループをn+1セット構成できます(つまり、各データベース用のSYSDBA権限を持つOSDBAグループが1つずつと、Oracle ASMインスタンス用のSYSASM権限を持つOSASMグループが1つです)。
|
関連項目: Oracle ASMのシステム認証の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle Databaseでは以前のリリースで作成されたファイル・ヘッダーを読み取ることができるため、アップグレード時にそれらに対して処理を行う必要はありません。アップグレード中に、表領域がスキーマ・ベースの表領域(SYSAUX、SYSTEM、XDB、HTMLDB、CTXSYSなど)でないかぎり、表領域を読取り専用またはオフライン・モードに設定します(それ以外の場合、アップグレードに失敗します)。オフラインのデータ・ファイルのファイル・ヘッダーは、後でオンラインにしたときに更新され、読取り専用の表領域のファイル・ヘッダーは、読取り/書込みに変更されたときに更新されます。
まれに、キュー表がアップグレード用に読取り専用に設定された表領域に存在する場合、その表領域を読取り/書込みに設定しなおす必要があります。これらのキュー・オブジェクトの再作成は、アップグレード後に再度試行できます。
|
関連項目: データベース間での表領域の転送の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Data Guard構成にスタンバイ・データベースが存在する場合にOracle Databaseソフトウェアをアップグレードする方法は、『Oracle Data Guard概要および管理』を参照してください。Oracle Data Guardブローカ構成でOracle DatabaseおよびOracle Enterprise Managerソフトウェアをアップグレードまたはダウングレードする方法は、『Oracle Data Guard Broker』を参照してください。
ローリング・アップグレード時に、プライマリ・データベースおよびスタンバイ・データベースで異なるリリースのOracle Databaseソフトウェアを実行して、一度に1つずつアップグレードし、プライマリ・データベースでの停止時間を最小にすることができます。次のいずれかの方法を使用します。
SQL Applyおよびロジカル・スタンバイ・データベース
ロジカル・スタンバイ・データベースでOracle Data Guard SQL Applyを使用して、新しいOracle Databaseリリースへのローリング・アップグレードを実行できます。ロジカル・スタンバイでは、アップグレードの進行中のアーカイブ・ログを受け入れます。スタンバイ・データベースがアップグレード・モードでオープンされている間にプライマリ・データベースのREDOを継続して受信するために、アップグレードのターゲットであるスタンバイ・データベースを有効化することによって、Data Guardデータベースのローリング・アップグレード処理中にデータ保護が維持されます。SQL Applyを使用したローリング・アップグレードによって、追加の障害保護が提供されます。
ローリング・アップグレード用のフィジカル・スタンバイ・データベースの使用
フィジカル・スタンバイ・データベースは、ロジカル・スタンバイによって提供されるローリング・アップグレード機能を利用できます。SQLのALTER DATABASE RECOVER TO LOGICAL STANDBY文でKEEP IDENTITY句オプションを使用することにより、ローリング・アップグレードのためにフィジカル・スタンバイ・データベースを一時的にロジカル・スタンバイ・データベースに変換してから、アップグレードの終了後、プライマリ・データベースとフィジカル・スタンバイ・データベースを元の構成に戻すことができます。
Oracle Database 12cでのActive Data Guardを使用したローリング・アップグレード
Oracle Database 12cではDBMS_ROLLING PL/SQLパッケージが提供され、これにより、Data Guard構成のデータベース・ソフトウェアのローリング方式でのアップグレードが可能です。Active Data Guardを使用したローリング・アップグレードでは、Data Guardのフィジカル・スタンバイ・データベースおよびSQL Applyプロセスを使用します。これは、Oracle Databaseリリース12.1以上のローリング・アップグレードでサポートされます。DBMS_ROLLINGを使用したローリング・アップグレードの実行の詳細は、『Oracle Data Guard概要および管理』を参照してください。
|
注意: Oracle Database 12c以上では、Oracle Enterprise Manager Cloud Controlで、Data Guard構成のデータベースのローリング・アップグレードを実行するためのオプションが提供されています。手順は、Cloud Control内のオンライン・ヘルプに記載されています。 |
|
関連項目:
|
新しいリリースのOracleソフトウェアにアップグレードする場合、オペレーティング・システム要件が変更されている可能性があります。必要に応じて、Oracle Databaseをアップグレードする前にオペレーティング・システムをアップグレードします。
|
関連項目:
|
DBUAを使用している場合またはOracle Databaseを手動でアップグレードしている場合は、オペレーティング・システム間でデータベースのデータは直接、移行または転送できません。たとえば、DBUAを使用して、Solaris上のOracle DatabaseのデータをWindows上のOracle 12cデータベースには移行できません。使用しているオペレーティング・システム・プラットフォーム固有の手順に従う必要があります。プラットフォーム間のデータの転送については、『Oracle Database管理者ガイド』を参照してください。
プラットフォーム間でのデータの転送がサポートされているプラットフォームを確認するには、SQL*Plusを使用して次の問合せを実行します。
SELECT * FROM V$TRANSPORTABLE_PLATFORM ORDER BY PLATFORM_NAME;
|
注意: ソース・プラットフォームとターゲット・プラットフォームでエンディアンが異なる場合、RMAN CONVERT DATABASEは使用できません。この処理では、ソースとターゲット・プラットフォームの両方が同じエンディアン値である必要があります。使用可能なオプションは、データ・ポンプ・レプリケーション、データ・ポンプ・エクスポート/インポートまたはトランスポータブル表領域、とRMAN CONVERT TABLESPACEの使用です。プラットフォームでエンディアンが同じ場合は、変換は必要なく、データは同じプラットフォーム上にある場合と同様に転送できます。 |
|
関連項目:
|
Oracle GoldenGateレプリケーション環境では、オンライン・データベース・アップグレードを実行して、最新のOracle Databaseのリリースにアップグレードできます。Oracle GoldenGateレプリケーション環境を使用すると、アップグレード時の停止時間が最小化されます。Oracle GoldenGateはプラットフォームの移行に加えて、アプリケーションおよびデータベースのアップグレードなどの、計画メンテナンス中の停止時間を最小化するための優れた方法です。Oracle GoldenGateはOracleおよびサード・パーティのデータベース管理システム用のOracle Databaseとは別に販売されているOracle製品です。
|
関連項目: 詳細はOracle GoldenGateドキュメントを参照してください。 |
Oracle GoldenGateを使用したOracle Database 12cへのアップグレードは、次の高度な手順で構成されています。特に指定がないかぎり、手順は、Oracle GoldenGateのドキュメント・ライブラリを参照してください。
以前のリリースのデータベース・ソフトウェアを実行中のスタンバイ・データべースを、既存のデータベースのバックアップを使用して設定します。
スタンバイ・データベースをOracle Database 12cにアップグレードします。「Oracle Database Upgrade Assistant (DBUA)を使用したアップグレード」を参照してください。
スタンバイ・データベースを本番データベースと同期化します。
アクティブ・モードまたはライブ・モードで環境をテストします。
アプリケーションをスタンバイ・データベースに切り替えます。
スタンバイ・データベースでアプリケーションの包括的なテストを行った後で、プライマリ・データベースをOracle Database 12cにアップグレードします。データベースのアップグレードのテストの詳細は、『Oracle Database Testingガイド』を参照してください。テストの後、第3章「Oracle Databaseのアップグレード」を参照してください。
Oracle Database 12cでは、Oracle OLAPは、Oracle Database 11gリリースで使用されていたExtensible Data Security (XDS)のかわりに、Oracle Real Application Security (ORAS)を使用して、OLAPデータ・セキュリティ・ポリシーを格納します。Oracle Databaseをリリース11gからリリース12cにアップグレードする場合、XDSデータ・セキュリティ・ポリシーはすべて自動的にORASに変換されます。
|
注意: リリース11gのOracle Databaseインスタンスで定義されたデータ・セキュリティ・ロールは、自動的にORASに変換されません。11gデータベースをOracle Database 12cにアップグレードする前に、11gデータベースで定義されたすべてのデータ・セキュリティ・ロールを削除する必要があります。アップグレード後に、Analytic Workspace Manager 12cを使用して、再度データ・セキュリティ・ロールを定義できます。11gデータ・セキュリティ・ロールを削除せずに、11gデータベースをOracle Database 12cにアップグレードする場合、データ・セキュリティ・ロールを含むデータ・セキュリティ・ポリシーは、Oracle Database 12cデータベースで無効になります。 |
|
関連項目: 『Oracle OLAPユーザーズ・ガイド』 |
Oracle Label Security (OLS)およびOracle Database Vaultを使用するOracle Databaseリリース12.1より前のデータベースをアップグレードする場合は、最初にOLS事前処理スクリプト(olspreupgrade.sql)を実行してaud$表のコンテンツを処理する必要があります。OLSアップグレードでは、aud$表が、SYSTEMスキーマからSYSスキーマに移動されます。olspreupgrade.sqlスクリプトは、この移動に必要な事前処理スクリプトです。
|
注意: Oracle Label SecurityおよびOracle Database Vaultを使用するOracle Databaseリリース12.1より前のデータベースをアップグレードする前には、 |
olspreupgrade.sqlスクリプトでは、SYSスキーマに一時表PREUPG_AUD$が作成され、SYSTEM.aud$レコードがSYS.PREUPG_AUD$に移動されます。安全性のため、olspreupgrade.sqlスクリプトを実行する前に、『Oracle Databaseセキュリティ・ガイド』の記載に従って、監査証跡をアーカイブすることをお薦めします。Oracle Label Securityがデータベースにインストールされていて、以前のリリースからアップグレードする場合は、アップグレードの前にOLS事前処理スクリプトを実行する必要があります。
この項には次のトピックが含まれます:
|
関連項目: OLS事前処理スクリプトの詳細は、Oracle Label Security管理者ガイドを参照してください。 |
Oracle Database Vaultを使用しているデータベースをアップグレードする前に、特定の要件、特にCDBのアップグレードについて、注意する必要があります。
Oracle Databaseリリース11.2以前からOracle Database 12cにアップグレードするとき、現在のOracleホームでOracle Database Vaultを有効にしている場合は、新しいターゲットのOracleホームではOracle Database Vaultはデフォルトで無効化されます。
Oracle Databaseリリース12.1.0.1からリリース12.1.0.2にアップグレードする場合、アップグレード処理を開始する前に、リリース12.1.0.1のOracleホームで、Oracle Database Vaultを手動で無効にする必要があります。
CDBをアップグレードする場合、次の注意の記載に従って、DV所有者としてdvsys.dbms_macadm.disable_dvを実行する必要があります。
|
重要: CDBrootおよびPDBでOracle Database Vaultを無効にするには、DV所有者として次のようにdvsys.dbms_macadm.disable_dvを実行します。 SQL> execute dvsys.dbms_macadm.disable_dv(); CDBを停止して再起動し、読取り/書込み状態でPDBを開きます。 |
アップグレードが完了したら、新しいOracleホームでOracle Database Vaultを再度有効にします。
|
関連項目: Oracle Database Vaultを無効および有効にする手順は、『Oracle Database Vault管理者ガイド』を参照してください。 |
アップグレード対象の以前のリリースにOracle Label Securityがインストールされている場合は、OLS事前処理olspreupgrade.sqlスクリプトを実行する必要があります。Oracle Database Vaultがリリース11.1.0.7データベースにインストールされていない場合は、この項の手順2、3、6および7をスキップできます。
アップグレード前にリリース11.1.0.7データベースでOLS事前処理スクリプトを実行するには、次の手順を実行します。
新しくインストールしたOracleホームからアップグレードするデータベースのOracleホームにORACLE_HOME/rdbms/admin/olspreupgrade.sqlスクリプトをコピーします。
SQL*Plusを起動し、アップグレードするデータベースにDVOWNERで接続します。
次の文を実行します。
SQL> EXEC dbms_macadm.add_auth_to_realm('Oracle Database Vault','SYS',NULL, 0);
システム・プロンプトで、次のように入力します。
CONNECT SYS AS SYSDBA
OLS事前処理スクリプトを実行します。
ORACLE_HOME/rdbms/admin/olspreupgrade.sql
OLS事前処理スクリプトの実行中も、データベース上でアプリケーションを継続して実行できます。
olspreupgrade.sqlの実行に成功したら、SQL*Plusを起動して、データベースにDVOWNERで接続します。
次の文を実行します。
SQL> EXEC dbms_macadm.delete_auth_from_realm('Oracle Database Vault','SYS');
アップグレード対象の以前のリリースにOracle Label Securityがインストールされている場合は、OLS事前処理olspreupgrade.sqlスクリプトを実行する必要があります。Oracle Database Vaultがリリース10.2.0.5または11.2データベースにインストールされていない場合は、この項の手順2、3、6および7をスキップできます。
アップグレード前にリリース10.2.0.5または11.2データベースでOLS事前処理スクリプトを実行するには、次の手順を実行します。
新しくインストールしたOracleホームからアップグレードするデータベースのOracleホームにORACLE_HOME/rdbms/admin/olspreupgrade.sqlスクリプトをコピーします。
SQL*Plusを起動し、アップグレードするデータベースにDVOWNERで接続します。
次の文を実行します。
SQL> GRANT DV_PATCH_ADMIN to SYS;
システム・プロンプトで、次のように入力します。
CONNECT SYS AS SYSDBA
OLS事前処理スクリプトを実行します。
ORACLE_HOME/rdbms/admin/olspreupgrade.sql
OLS事前処理スクリプトの実行中も、データベース上でアプリケーションを継続して実行できます。
olspreupgrade.sqlの実行に成功したら、SQL*Plusを起動して、データベースにDVOWNERで接続します。
次の文を実行します。
SQL> REVOKE DV_PATCH_ADMIN from SYS;
OWBはOracle Database 12cのソフトウェアの一部としてインストールされず、以前のリリースに存在したOWBコンポーネントは、Oracle Databaseのアップグレード処理の一部としてアップグレードされません。ただし、Oracle Database 12cではOWBリリース11.2.0.3を使用できます。リリース11.2.0.3より前のOWBリリースは、Oracle Database 12cでは動作しません。
OWBのリリース11.2.0.3は、次の方法でOracle Database 12cで使用できます。
OWB 11.2.0.3をOracle Database 12cとともに使用できるようにするパッチ更新が提供されています。既存のスタンドアロンOWB 11.2.0.3インストールがある場合、Oracle Database 12cでOWBにアクセスできるようにします。
Oracle Database 12cのアクセスを既存のスタンドアロンOWB 11.2.0.3インストールに追加するには、次の手順を実行します。
実行中のOWBランタイム・サービス、ブラウザおよびName AddressサーバーからすべてのOWBアプリケーションを停止します。
Oracle Database 12cソフトウェアをインストールし、第3章「Oracle Databaseのアップグレード」に記載されているデータベースのアップグレード手順に従います。
OWB累積パッチ16568042をOWBリリース11.2.0.3インストールに適用します。(OWBに対するパッチは、Oracle Database 12cのインストールの前後どちらでも適用できます。)
このパッチを入手するには、My Oracle Support (http://support.oracle.com)にアクセスし、「Patches」をクリックしてパッチ・リクエスト番号16568042を検索してください。
パッチのREADME.txtファイルのインプレース移行手順に従います。
スタンドアロンのOracleホームからOWBリリース11.2.0.3の実行を継続します。
スタンドアロンのインストールが使用可能でないプラットフォーム(Solaris、HP、AIXなど)上でOWBリリース11.2.0.3が稼働している場合は、Oracle Database 12cへの移行後にOracle Databaseリリース11.2.0.3ソフトウェアをインプレースで保持する必要があります。
Oracle Databaseリリース11.2.0.3と統合されたOWBを実行するには、次の手順を実行します。
実行中のOWBランタイム・サービス、ブラウザおよびName AddressサーバーからすべてのOWBアプリケーションを停止します。
Oracle Database 12cソフトウェアをインストールし、第3章「Oracle Databaseのアップグレード」に記載されているデータベースのアップグレード手順に従います。
Oracle Database 12cのインストール後に、Oracle Databaseリリース11.2.0.3を削除しないでください。このOracleホームからOWBを実行します。
Oracle Databaseリリース11.2.0.3のOracleホームにパッチ16568042を適用します。これはOWBインストールにパッチを適用します。(OWBに対するパッチは、Oracle Database 12cのインストールの前後どちらでも適用できます。)
このパッチを入手するには、My Oracle Support (http://support.oracle.com)にアクセスし、「Patches」をクリックしてパッチ・リクエスト番号16568042を検索してください。
パッチのREADME.txtファイルのインプレース移行手順に従います。
統合されたOracle Databaseリリース11.2.0.3のOracleホームからOWBを実行します。
スタンドアロン・インストールが可能なプラットフォーム(LinuxおよびWindows)上でOWB 11.2.0.3が稼働している場合は、スタンドアロン・ソフトウェアをインストールして、Oracle Databaseリリース11.2.0.3ソフトウェアを削除できます。
OWBを統合されたインストールからスタンドアロン・インストールに変換するには、次の手順を実行します。
実行中のOWBランタイム・サービス、ブラウザおよびName AddressサーバーからすべてのOWBアプリケーションを停止します。
OWBスタンドアロン・クライアントを自身のOWBホーム・ディレクトリにインストールします。
owb/bin/adminディレクトリ全体を、古いOWBインストールから新しいOWBインストールのowb/bin/adminディレクトリにコピーします。この手順によって、ファイルとサブディレクトリすべてが新しいOWBの場所にコピーされます。
Control Centerホーム値を再設定するために、OWBSYSユーザーとして次のSQL文を実行します。プロンプトが表示されたら、新しいOWB_HOMEのディレクトリの場所を入力します。
sqlplus OWBSYS/OWBSYS_PASSWORD
% New_OWB_HOME/owb/UnifiedRepos/reset_owbcc_home.sql
Oracle Database 12cソフトウェアをインストールし、第3章「Oracle Databaseのアップグレード」に記載されているデータベースのアップグレード手順に従います。
OWB累積パッチ16568042をOWBスタンドアロン・リリース11.2.0.3インストールに適用します。(OWBに対するパッチは、Oracle Database 12cのインストールの前後どちらでも適用できます。)
このパッチを入手するには、My Oracle Support (http://support.oracle.com)にアクセスし、「Patches」をクリックしてパッチ・リクエスト番号16568042を検索してください。
パッチのREADME.txtファイルのインプレース移行手順に従います。
スタンドアロンのOracleホームの場所からOWBリリース11.2.0.3を実行します。
AUDSYSスキーマとAUDIT_ADMINロールおよびAUDIT_VIEWERロールを削除します。この段階で、AUDSYSスキーマは存在しません。
SYSDBAシステム権限を持つユーザーSYSでSQL*Plusにログインします。
sqlplus sys as sysdba
Enter password: password
AUDSYSスキーマが存在する場合、データベースを移行モードで起動してAUDSYSユーザーを削除します。
SQL> startup migrate pfile=$T_WORK/t_init1.ora ORACLE instance started. SQL> drop user audsys cascade; User dropped.
AUDSYSスキーマ(存在する場合)およびAUDIT_ADMINロールおよびAUDIT_VIEWERロールを削除します。
DROP USER AUDSYS CASCADE; DROP ROLE AUDIT_ADMIN; DROP ROLE AUDIT_VIEWER;
次の手順では、新しいOracle Databaseリリースのソフトウェアのインストール方法を説明します。
|
重要: ソースおよびターゲットのOracleホームを異なるユーザーが所有している場合は、Database Upgrade Assistant (DBUA)を使用してデータベースをアップグレードできません。これを行うと、エラーPRKH-1014が返されます。ソースおよびターゲットのデータベースの所有者が同じであることを確認するか、または「マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード」に記載されている手動の手順を実行します。 |
このリリースの新しいOracle Databaseソフトウェアをインストールするには、次の手順を実行します。
Oracle RACデータベースをアップグレードする場合は、記述されている順番で次の手順を実行する必要があります。
ご使用のオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』の記載に従って、最初にOracle Clusterwareをアップグレードします。
|
注意: Oracle RAC以外のデータベースをアップグレードする場合は、DBUAを実行する前にOracle Net Configuration Assistant(NETCA)を実行する必要があります。「Oracle Databaseのアップグレード時のOracle Net Servicesに関する推奨事項」を参照してください。Oracle RACデータベースをOracle Clusterwareアップグレードの一部としてアップグレードする場合は、OUIによって自動的にNETCAが実行され、ネットワーク・リスナーがアップグレードされます。そのため、NETCAを個別に実行しないでください。 |
Oracle Grid Infrastructureのインストール・メディアをマウントします。
アップグレードを行う各ノードでオペレーティング・システムの前提条件チェックを実行し、ノードがOracle Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)に必要なシステムの前提条件を満たしていることを確認します。
必要に応じて、以前のリリースのOracle Clusterwareソフトウェアが最新のパッチ・バージョンになるように、パッチのアップグレードを実行します。
Oracle Grid Infrastructureインストールを所有するユーザーでログインしていることを確認し、Oracle Grid Infrastructureのインストールを実行します。インストーラの要求に応じて情報を入力します。
プロンプトが表示されたら、別のターミナル・セッションを開き、rootでログインしてroot.shを実行します。
|
関連項目:
|
Oracle Clusterwareをアップグレードした後、Oracleのオペレーティング・システム固有のマニュアルを参照して、Oracle Databaseソフトウェアのインストールの準備を行い、Oracle Universal Installerを起動します。
DBUAを使用してアップグレードする前に、アップグレード前情報ツールを実行することをお薦めします。DBUAでチェックされる項目のタイプを確認し、データベースに存在する可能性のある問題を事前に確認できます。アップグレード前情報ツールは、検出された前提条件の問題の修正に役立ちます。(「Oracle Databaseのアップグレード前情報ツールの概要」を参照してください。)インストールの完了後、単独でDBUAを実行できます。
Oracle Label Security、Oracle Database Vault、またはこれらの両方を使用する場合、データベース・エディションの選択ページで「Enterprise Edition」を選択し、「オプションの選択」をクリックして、コンポーネント・リストから一方または両方のコンポーネントを有効にします。「Oracle Label SecurityおよびOracle Database Vaultを使用しているデータベースのアップグレードの要件」を参照してください。
Oracle Databaseソフトウェアのインストールが正常に完了したら、「終了」ボタンをクリックしてOracle Universal Installerを閉じます。
Oracle Database 12cのソフトウェアには、Oracle Databaseのすべての最新パッチと更新を含む完全なリリースが含まれます。アップグレード後に、データベース管理の一部として、パッチおよびパッチ・セットの更新を確認することをお薦めします。
My Oracle Supportで、最新パッチの入手方法、およびライフサイクル管理と自動化パッチに使用するツールについて詳細に説明したノートが提供されています。My Oracle Supportの利用開始については、http://support.oracle.comにアクセスしてください。
|
関連項目: |
Oracle Database 12cのソフトウェアをインストールした後、新しいリリースにアップグレードする前にデータベースを分析する必要があります。これは、アップグレード対象のデータベースの環境からpreupgrd.sqlアップグレード前情報ツールを実行することによって行います。アップグレード前情報ツールを実行することで、DBUAが確認する項目のプレビューおよび修正が必要なすべてに関する情報が提供されます。アップグレード前情報ツールでは、ソース・データベースでフラグ付けされた問題を解決するために実行できる修正スクリプトが生成されます。
この項の内容は次のとおりです。
|
注意: 手動でアップグレードを行い、アップグレード前情報ツールを最初に実行しなかった場合は、catctl.plスクリプトがエラーで終了する可能性があります。アップグレード前に修正する問題が警告されるため、このツールの実行は必須です。 |
Oracle Database 12cでpreupgrd.sqlアップグレード前情報ツールが導入されました。新しいpreupgrd.sqlスクリプトによって、以前のバージョンのアップグレード前情報ツールが置換されます。新しいアップグレード前情報ツールでは、前提条件のアップグレード・チェックのデフォルトの動作が次のように強化されました。
アップグレード前情報ツールの出力が含まれるログ・ファイル(preupgrade.log)が作成されます。
ソース・データベースでSQL*Plusを使用して修正可能な問題をリストし、説明するためのpreupgrade_fixups.sqlスクリプトが作成されます。これは、実行すると、簡単な問題の解決も試みます。
データベースのアップグレード後に修正可能な問題に対処するためのpostupgrade_fixups.sqlスクリプトが作成されます。第4章「Oracle Databaseのアップグレード後の作業」を参照してください。
Oracle_Baseが定義されている場合、生成されたスクリプトおよびログ・ファイルはOracle_Base/cfgtoollogs/に作成されます。Oracle_Baseが定義されていない場合は、生成されたスクリプトおよびログ・ファイルはORACLE_HOME/cfgtoollogs/に作成されます。
ソース・データベース上でアップグレード前情報ツールを実行するには、次の手順を実行します。
Oracle Database 12cをインストールした新しいOracleホームのrdbms/adminディレクトリから、ソース・データベース(アップグレード対象のデータベース)への接続時にアクセス可能なディレクトリに、preupgrd.sqlおよびutluppkg.sqlをコピーします。可能な場合、これは一時ディレクトリにします。
アップグレード対象データベースの環境の所有者としてシステムにログインします。
|
重要: アップグレード対象のデータベースの環境にアップグレード前情報ツール(preupgrd.sqlおよびutluppkg.sqlが含まれる)をコピーして、その環境から実行する必要があります。 |
SQL*Plusを起動して、アップグレード対象のデータベースにDBA権限のあるアカウントを使用して接続します。
SQL> CONNECT / AS SYSDBA
(推奨)次のシナリオについて、アップグレード前情報ツール(preupgrd.sql)を実行します。
ソースOracleホームの非CDBをアップグレードする前です。
SQL> @$ORACLE_HOME/rdbms/temp/preupgrd.sql
ソースOracleホームのCDBをアップグレードする前です。
CDBでpreupgrd.sqlを実行する場合、すべてのPDBが開いていることを確認します。すべてのPDBを開くには、次を実行します。
SQL> alter pluggable database all open;
次のように、catcon.plおよびpreupgrd.sqlを実行します。
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -d
$ORACLE_HOME/rdbms/admin -l <output directory for catcon logs> -b preupgrd
preupgrd.sql
<catconログの出力ディレクトリ>にあるログ・ファイルpreupgrd0.logには、preupgrd.sqlの画面出力が含まれています。アップグレード前の結果および修正スクリプトの場所は、preupgrd0.logを参照してください。
ソースOracleホームでPDBを切断する前です。(詳細は、「プラガブル・データベース(PDB)のアップグレード」を参照してください。)
preupgrd.sqlを単一のPDBで実行している場合、次のようにCDBに接続し、PDBに切り替えます。
alter session set container = PDB1;
修正スクリプトおよびログ・ファイルが、ソース・データベースのpreupgradeディレクトリに生成されます。PDBの出力のみを表示するには、cfgtoollogs/SID/preupgrade/pdbfilesを参照します。PDBファイルは最初にpreupgrade/pdbfilesに書き込まれ、次にcfgtoollogs/SID/preupgradeディレクトリのpreupgrade.log、preupgrade_fixups.sql、およびpostupgrade_fixups.sqlに連結されます。
生成された修正スクリプトおよびログ・ファイルを表示して確認します(保存場所は、ORACLE_BASEが定義されている場合は$ORACLE_BASE/cfgtoollogs/db_unique_name/preupgrade、ORACLE_BASEが定義されていない場合は$ORACLE_HOME/cfgtoollogs/db_unique_name/preupgradeです)。
スクリプトを確認した後、ソース・データベースでpreupgrade_fixups.sqlを実行することをお薦めします。preupgrade_fixups.sqlスクリプトは、アップグレード前プロセスによって報告された問題の解決を試みます。
修正スクリプトで自動的に解決できない問題には、** USER ACTION REQUIRED **というフラグが付けられます。
手動の手順を完了する必要があるフラグ付けされた問題を修正します。実行するアクションの詳細は、「Oracle Databaseのアップグレードでのアップグレード前情報ツールの警告および推奨事項」を参照してください。
警告に対処し、解決するために必要な回数だけ、アップグレード前情報ツールを実行します。
Oracle Databaseの新しいリリースにアップグレードする前に、アップグレード前情報ツールによって表示された情報および警告の分析を行うことをお薦めします。
Oracle Database 12c以上では、Oracle DatabaseのReal Application Securityを使用したUTLパッケージ(UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTPおよびUTL_INADDR)のアクセス制御が実装されたため、Oracle XML DBは必要ありません。
ACLおよびネットワーク・ユーティリティ・パッケージを更新するには、次の手順を実行します。
ログイン中のユーザーに、DBMS_LDAP.initで指定されたホストおよびポートのconnect権限があることを確認します。DBMS_LDAP PL/SQLパッケージおよびHttpUriType型の新しい動作では、Oracle Databaseの新しいリリースにアップグレードした後にアクセス制御リスト(ACL)を作成または更新する必要があります。
たとえば、アプリケーションがDBMS_LDAPパッケージに依存している場合は、エラー「ORA-24247: アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されました」が発生する可能性があります。このエラーを防ぐには、ログイン中のユーザーは、DBMS_LDAP.initで指定されたホストおよびポートのconnect権限を持っている必要があります。
UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTPおよびUTL_INADDRパッケージのいずれかまたはすべてがインストールされている場合は、これらのパッケージが新しいOracle Database 12cリリースに対応した最新バージョンになるように、アップグレードの実行後にこれらのパッケージを再インストールする必要がある場合があります。
|
関連項目: アクセス制御リストの構成の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。 |
ネットワーク・ユーティリティ・パッケージの依存性を評価し、適切なアクセス制御リスト(ACL)を追加することによってアクセスを提供する必要がある場合があります。
ネットワーク・ユーティリティ・パッケージに対するアクセスのステータスを確認し、ネットワーク・ユーティリティ・パッケージのACLを追加するには、次の手順を実行します。
「アップグレード前情報ツール(preupgrd.sql)の使用方法」の説明に従って、アップグレード前情報ツールを実行します。
アップグレード前情報ツールの出力(preupgrade.log)で、次のようなメッセージを確認します。
WARNING: --> Database contains schemas with objects dependent on network packages. .... Refer to the Database Upgrade Guide for instructions to configure Network ACLs. .... USER WKSYS has dependent objects. .... USER SYSMAN has dependent objects. .... USER FLOWS_010600 has dependent objects. .
DBA_DEPENDENCIESビューを問い合せて、依存性の詳細を取得します。次に例を示します。
SELECT * FROM DBA_DEPENDENCIES
WHERE referenced_name IN ('UTL_TCP','UTL_SMTP','UTL_MAIL','UTL_HTTP','UTL_INADDR','DBMS_LDAP')
AND owner NOT IN ('SYS','PUBLIC','ORDPLUGINS');
データベース環境環境で使用できるようにアップグレード後のスクリプトを準備します。これによって、新しいアクセス制御がアップグレード・テストの一部に含まれます。
これらのパッケージが前のリリースと同様に動作するようにデータベースのネットワーク・アクセス制御リスト(ACL)を構成する場合は、「外部ネットワーク・サービスへのアクセス制御リスト(ACL)の構成」に示されているスクリプトの例を参照してください。このスクリプトには、DBMS_NETWORK_ACL_ADMINパッケージを使用してアクセス制御リストに対して権限の作成、割当ておよび追加を行う方法が示されています。
アップグレードが完了した後、特定の必要な権限を付与する必要があります。アクセス権は、元のデータベースでの使用方法に基づいて決定します。
|
関連項目: アクセス制御リストの構成の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。 |
この情報は、アップグレードの実行後に元のデータベース・リリースにダウングレードする場合にのみ重要となります。Oracle Database 12cへのアップグレード中に、データベース・リンク内のすべてのパスワードは暗号化されます。
アップグレード元のリリースにダウングレードするには、ダウングレードする前に、暗号化されたパスワードが指定されたすべてのデータベース・リンクを削除する必要があります。したがって、ダウングレードしたデータベースにはデータベース・リンクは存在しません。
元のリリースにダウングレードできるようにしておく必要があると予想される場合は、影響を受けるデータベース・リンクの情報をSYS.LINK$表から保存しておくことで、ダウングレード後にデータベース・リンクを再作成できます。
以前のリリースの詳細は、アップグレードする前のOracle Databaseリリース用の元のドキュメントを参照してください。プラットフォーム固有の以前のリリースのOracleインストレーション・ガイドを参照することもできます。
|
関連項目: 認証およびデータベース・リンクの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Database 12cに付属のタイムゾーン・ファイルは、一部のタイムゾーン地域の変換ルールに対して行われた変更を反映するために更新されています。これらの変更は、TIMESTAMP WITH TIME ZONEデータ型の既存のデータに影響する場合があります。
データベースをアップグレードする前に、最新のタイムゾーン・ファイルがあることを確認することをお薦めします。アップグレード対象のデータベースのタイムゾーン・ファイルのバージョンが、Oracle Databaseの新しいリリースで使用可能なタイムゾーン・ファイルの最新バージョンでない場合は、アップグレード前情報ツールによって、警告が表示されて続行方法が説明されます。表2-2、「タイムゾーン・ファイルのバージョンの修正を行う場合の選択肢」は、警告と、タイムゾーン・ファイルのバージョンの不一致を解決する方法の概要を示しています。
|
注意: タイムゾーン・ファイルのバージョンが一致していない場合、データベースに格納されている |
表2-2 タイムゾーン・ファイルのバージョンの修正を行う場合の選択肢
| アップグレード中のデータベースのタイムゾーン・バージョン | タイムゾーン・ファイルの修正方法 |
|---|---|
|
新しいデータベース・リリースに含まれている最新バージョンより前のバージョンの場合、アップグレード前情報ツールには「Database is using a time zone file older than version n」と表示されます。 |
データベースのアップグレードの完了後。
関連項目: |
|
新しいデータベース・リリースに含まれているバージョンより新しいバージョンの場合、アップグレード前情報ツールには、「Database is using a time zone file greater than version n.」と表示されます。 |
データベースのアップグレードの開始前。 使用しているタイムゾーン・ファイルのバージョンに適した |
|
関連項目:
|
統計が不足しているかOracle Databaseのアップグレード中に大幅に変更された表に対して統計収集が発生します。データベースを実際にアップグレードする前に統計を収集します。データベースに多数のディクショナリ表が含まれている場合は、アップグレードの開始前夜に統計を収集することをお薦めします。
停止時間を短縮するには、次を行います。
これらの統計の収集にはDBMS_STATS.GATHER_DICTIONARY_STATSプロシージャを使用することをお薦めします。たとえば、次のSQL文を入力します。
SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
|
関連項目: 構文およびGATHER_DICTIONARY_STATSプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
データベースのアップグレード前に検出された無効なSYSオブジェクトまたはSYSTEMオブジェクトは、アップグレード前情報ツールpreupgrd.sqlを実行した後に、registry$sys_inv_objsという名前の表に格納されます。また、データベースのアップグレード前に検出されたSYSまたはSYSTEM以外の無効なオブジェクトは、registry$nonsys_inv_objsに格納されます。
アップグレード前の無効なオブジェクトおよびアップグレードが原因で無効になったオブジェクトを識別するには、次の手順を実行します。
$ORACLE_HOME/rdbms/admin/からutluiobj.sqlを実行します。
アップグレードの前および後にutluiobj.sqlスクリプトを実行すると、アップグレード後に無効になったオブジェクトとアップグレード前に無効だったオブジェクトを比較できます。これは、データベースの健全性チェックに似ています。アップグレード後に無効なオブジェクトが増えた場合は、問題が発生したことを示しています。
無効なオブジェクトを修正するか、My Oracle Supportに問い合せてください。
|
注意: アップグレード・プロセスの一環として、最初にアップグレード前情報ツールを実行するようにしてください。DBUAは、前提条件チェックのフェーズでこのツールを実行します。このツールは、アップグレードの前に手動で実行することができます。アップグレード前情報ツールが1度も実行されていない場合は、表registry$sys_inv_objsが存在しないというエラーが表示されます。アップグレード前情報ツールによってregistry$sys_inv_objsが作成され、データが挿入されます。「アップグレード前情報ツール(preupgrd.sql)の使用方法」を参照してください。 |
|
関連項目: PL/SQLパッケージのプロシージャを使用した無効なオブジェクトの手動での再コンパイルの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Databaseをアップグレードする前に、すべてのマテリアライズド・ビューがリフレッシュを完了するまで待機する必要があります。システムに問い合せて、進行中のマテリアライズド・ビューのリフレッシュがあるかどうかを判断することができます。
進行中のマテリアライズド・ビューのリフレッシュがあるかどうかを判断するには、次を行います。
次のSQL問合せを実行します。
SQL> SELECT o.name FROM sys.obj$ o, sys.user$ u, sys.sum$ s
WHERE o.type# = 42 AND bitand(s.mflags, 8) =8;
|
関連項目:
|
Oracle Databaseをアップグレードする前に、メディア・リカバリを必要とするファイルがないことを確認する必要があります。システムに問い合せてファイルのリストを取得し、必要に応じてこれらのファイルのリカバリを行うことができます。
メディア・リカバリを必要とするファイルのリストを取得するには、次を行います。
次の文を実行します。
SQL> SELECT * FROM v$recover_file;
|
関連項目: ブロック・メディア・リカバリの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Oracle Databaseのバックアップ時にバックアップ・モードのファイルがあってはいけないため、バックアップが完了するまで待機する必要があります。システムに問い合せてバックアップ・モードのファイルのリストを表示できます。その後、バックアップが完了するまで待機、または必要のないバックアップを中止することで適切な対処を行います。
バックアップ・モードのファイルのリストを取得するには、次を行います。
次の文を実行します。
SQL> SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';
|
関連項目: データのバックアップおよびアーカイブの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Oracle Databaseをアップグレードする前に、未処理の分散トランザクションを解決する必要があります。これを行うには、最初に問合せによって保留中のトランザクションを確認してから、トランザクションをコミットします。保留中のすべての分散トランザクションがコミットされるまで待機する必要があります。
未処理の分散トランザクションを解決するには、次の手順を実行します。
次の文を実行します。
SQL> SELECT * FROM dba_2pc_pending;
前述の手順の問合せによって行が戻された場合は、次の各文を実行します。
SQL> SELECT local_tran_id FROM dba_2pc_pending;
SQL> EXECUTE dbms_transaction.purge_lost_db_entry('');
SQL> COMMIT;
|
ヒント: 分散トランザクションの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Databaseのアップグレード処理を開始する前に、データベース内のすべてのユーザーのゴミ箱を空にしておく必要があります。PURGE文を使用して、アイテムおよびその関連オブジェクトを削除して、記憶域の領域を解放します。SYSDBA権限がある場合は、RECYCLEBINのかわりに、DBA_RECYCLEBINを指定することによって、データベース全体のすべてのゴミ箱を消去できます。Oracle Database 12c以上では、SYSDBA権限を付与する必要なく、新しいPURGE DBA_RECYCLEBINシステム権限を使用して同じアクションを実行できます。
PURGE DBA_RECYCLEBIN文は、システム全体のごみ箱からすべてのオブジェクトを削除する特別なPURGEコマンドで、各ユーザーのごみ箱を空にすることと同じです。以前のリリースでは、この文にはSYSDBA管理者権限が必要であり、これは、義務の分離および最低限の権限の点で非常に望ましくないものです。義務の分離を順守するために、Oracle Database 12cでは新しいシステム権限であるPURGE DBA_RECYCLEBINが導入され、これによって、SYSDBA管理者権限を持たずにPURGE DBA_RECYCLEBINを実行することが可能です。
データベースのごみ箱を空にするには、次のコマンドを実行します。
SQL> PURGE DBA_RECYCLEBIN
|
注意: アップグレード処理を行う際は、 |
|
関連項目:
|
スタンバイ・データベースが存在する場合は、Oracle Databaseをアップグレードする前に、プライマリ・データベースと同期化する必要があります。
スタンバイ・データベースが存在するかどうかを確認して、そのスタンバイ・データベースと同期化するには、次の手順を実行します。
次の問合せを実行します。
SQL> SELECT SUBSTR(value,INSTR(value,'=',INSTR(UPPER(value),'SERVICE'))+1) FROM v$parameter WHERE name LIKE 'log_archive_dest%' AND UPPER(value) LIKE 'SERVICE%';
前の手順の問合せによって行が戻された場合は、スタンバイ・データベースとプライマリ・データベースを同期化します。
プライマリ・データベースでの最後のログ・スイッチの後のすべてのログがスタンバイ・サーバーに転送されていることを確認します。
NODELAYオプションを使用して、スタンバイ・データベースのリカバリを開始します。
|
関連項目: フィジカル・スタンバイ・データベースとプライマリ・データベースの同期の詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
Oracle Application Expressが含まれているデータベースをアップグレードする場合は、次のようになります。
データベースのアップグレード時間を短縮するために、Oracle Application Expressを個別にアップグレードできます。
open_cursorsには、最小値である150が必要です。Oracle Application Expressをアップグレードする場合、open_cursors = 150に設定することをお薦めします。それ以外の場合、次のエラーが表示される場合があります。
ORA-01000: maximum open cursors exceeded ORA-06512: at "APEX_040200.WWV_FLOW_API", line 1594
アップグレード前情報ツールでは、推奨事項が表示されますが、その推奨事項は自動的には実行されません(これは、修正スクリプトの実行方法およびタイミングをユーザーが制御できるようにするためです)。
次の例は、アップグレード対象のリリース11.2.0.3データベースでOracle Database 12cのアップグレード前情報ツール(preupgrd.sql)を実行することで、preupgrade.logに生成され、書き込まれた出力を示します。
Oracle Database Pre-Upgrade Information Tool 03-06-2014 12:18:01
Script Version: 12.1.0.2.0 Build: 006
**********************************************************************
Database Name: MyDB
ContainerName: Not Applicable in Pre-12.1 database
ContainerID: Not Applicable in Pre-12.1 database
Version: 11.2.0.3.0
Compatible: 11.1.0
Blocksize: 8192
Platform: Linux x86 64-bit
Timezone file: V14
**********************************************************************
[Update parameters]
[Update Oracle Database 11.2.0.3.0 init.ora or spfile]
--> If Target Oracle is 32-bit, refer here for Update Parameters:
WARNING: --> "shared_pool_size" needs to be increased to at least 247463936
WARNING: --> "java_pool_size" needs to be increased to at least 67108864
WARNING: --> "db_cache_size" needs to be increased to at least 50331648
WARNING: --> "processes" needs to be increased to at least 300
--> If Target Oracle is 64-bit, refer here for Update Parameters:
WARNING: --> "shared_pool_size" needs to be increased to at least 494927872
WARNING: --> "java_pool_size" needs to be increased to at least 134217728
WARNING: --> "db_cache_size" needs to be increased to at least 50331648
WARNING: --> "processes" needs to be increased to at least 300
**********************************************************************
**********************************************************************
[Renamed Parameters]
[No Renamed Parameters in use]
**********************************************************************
**********************************************************************
[Obsolete/Deprecated Parameters]
[No Obsolete or Desupported Parameters in use]
**********************************************************************
[Component List]
**********************************************************************
--> Oracle Catalog Views [upgrade] VALID
--> Oracle Packages and Types [upgrade] VALID
--> JServer JAVA Virtual Machine [upgrade] VALID
--> Oracle XDK for Java [upgrade] VALID
--> Real Application Clusters [upgrade] INVALID
--> Oracle Workspace Manager [upgrade] VALID
--> Oracle Text [upgrade] VALID
--> Oracle XML Database [upgrade] VALID
--> Oracle Java Packages [upgrade] VALID
--> Oracle Multimedia [upgrade] VALID
--> Expression Filter [upgrade] VALID
--> Rule Manager [upgrade] VALID
**********************************************************************
[Tablespaces]
**********************************************************************
--> SYSTEM tablespace is adequate for the upgrade.
minimum required size: 909 MB
--> SYSAUX tablespace is adequate for the upgrade.
minimum required size: 500 MB
--> TEMP tablespace is adequate for the upgrade.
minimum required size: 60 MB
--> UD1 tablespace is adequate for the upgrade.
minimum required size: 400 MB
[No adjustments recommended]
**********************************************************************
**********************************************************************
[Pre-Upgrade Checks]
**********************************************************************
WARNING: --> Process Count may be too low
Database has a maximum process count of 60 which is lower than the
default value of 300 for this release.
You should update your processes value prior to the upgrade
to a value of at least 300.
For example:
ALTER SYSTEM SET PROCESSES=300 SCOPE=SPFILE
or update your init.ora file.
INFORMATION: --> Older Timezone in use
Database is using a time zone file older than version 21.
After the upgrade, it is recommended that DBMS_DST package
be used to upgrade the 11.2.0.3.0 database time zone version
to the latest version which comes with the new release.
Please refer to My Oracle Support note number 977512.1 for details.
**********************************************************************
[Pre-Upgrade Recommendations]
**********************************************************************
*****************************************
********* Dictionary Statistics *********
*****************************************
Please gather dictionary statistics 24 hours prior to
upgrading the database.
To gather dictionary statistics execute the following command
while connected as SYSDBA:
EXECUTE dbms_stats.gather_dictionary_stats;
^^^ MANUAL ACTION SUGGESTED ^^^
*****************************************
*********** Hidden Parameters ***********
*****************************************
Please review and remove any unnecessary hidden/underscore parameters prior
to upgrading. It is strongly recommended that these be removed before upgrade
unless your application vendors and/or Oracle Support state differently.
Changes will need to be made in the init.ora or spfile.
^^^ MANUAL ACTION SUGGESTED ^^^
To view existing hidden parameters execute the following command
while connected AS SYSDBA:
SELECT name, value from SYS.V$PARAMETER WHERE name
LIKE '\_%' ESCAPE '\' order by name;
Or run the Pre-Upgrade Fixup Script to display the Hidden Parameters
currently set.
**********************************************************************
[Post-Upgrade Recommendations]
**********************************************************************
*****************************************
******** Fixed Object Statistics ********
*****************************************
Please create stats on fixed objects two weeks
after the upgrade using the command:
EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
^^^ MANUAL ACTION SUGGESTED ^^^
**********************************************************************
************ Summary ************
0 ERRORS exist in your database.
1 WARNING that Oracle suggests are addressed to improve database performance.
1 INFORMATIONAL message that should be reviewed prior to your upgrade.
After your database is upgraded and open in normal mode you must run
rdbms/admin/catuppst.sql which executes several required tasks and completes
the upgrade process.
You should follow that with the execution of rdbms/admin/utlrp.sql, and a
comparison of invalid objects before and after the upgrade using
rdbms/admin/utluiobj.sql
If needed you may want to upgrade your timezone data using the process
described in My Oracle Support note 977512.1
***********************************
アップグレード前情報ツールを実行し、正常にデータベースを停止した後、Oracle Databaseをバックアップすることをお薦めします。停止時間を最小化するために、オンライン・バックアップを実行するか、保証付きリストア・ポイントを作成できます。Database Upgrade Assistant (DBUA)によって、バックアップおよびリストア・ポイントを指定できます。
|
重要: Oracleソフトウェアを変更する前に、Oracleソフトウェアおよびデータベースのバックアップを作成することをお薦めします。Windowsオペレーティング・システム上で動作するOracleソフトウェアでは、Windowsレジストリもバックアップする必要があります。レジストリのバックアップがないと、Oracle Database 12cへのアップグレードが失敗して以前のソフトウェア・インストールに戻す場合に、Oracleソフトウェアを動作状態にリストアすることができません。 |
|
関連項目:
|
アップグレード対象のデータベースのバックアップを実行するには、次の手順を実行します。
rman "target / nocatalog"
次のRMANコマンドを実行します。
RUN
{
ALLOCATE CHANNEL chan_name TYPE DISK;
BACKUP DATABASE FORMAT 'some_backup_directory%U' TAG before_upgrade;
BACKUP CURRENT CONTROLFILE FORMAT 'controlfile location and name';
}
|
関連項目: RMANバックアップの実行方法は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
アップグレードするデータベースをバックアップした後、新しい場所に新しいOracleホームを準備します。Oracle Database 12cのソフトウェアを新しい場所にインストールします。
アップグレードのために新しいOracleホームを準備するには、次の手順を実行します。
アップグレードするデータベースのOracleホームから、Oracle Database 12cの新しいOracleホームに、構成ファイルをコピーします。DBUAを使用している場合、構成ファイルは自動的にコピーされ、この手順は無視できます。
構成ファイルを新しいOracleホームに手動でコピーする必要があるのは、次の場合です。
パラメータ・ファイルが古い環境のOracleホームに存在する場合は、新しいOracleホームへコピーします。デフォルトでは、パラメータ・ファイルを検索する場所は、LinuxまたはUNIXプラットフォームの場合はORACLE_HOME/dbsディレクトリで、Windowsオペレーティング・システムの場合はORACLE_HOME\databaseディレクトリです。パラメータ・ファイルは任意の場所に格納できますが、Oracle Database 12cにアップグレードした後は、古い環境のOracleホームには格納しないでください。
Oracle ASMインスタンス内にパラメータ・ファイルがある場合は、次のコマンドを使用してパラメータ・ファイルをバックアップしてください。
CREATE pfile FROM spfile;
SPFILEがOracle ASMにある環境のデータベースをダウングレードする必要がある場合は、ダウングレードする前にパラメータ・ファイルをリストアする必要があります。
パラメータ・ファイルがIFILE (インクルード・ファイル)エントリまたはSPFILE (サーバー・パラメータ・ファイル)エントリのいずれかを含むテキストベースの初期化パラメータ・ファイルであり、IFILEまたはSPFILEエントリ内に指定されたファイルが古い環境のOracleホームに存在する場合、IFILEまたはSPFILEエントリで指定されているファイルを新しいOracleホームへコピーします。IFILEエントリまたはSPFILEエントリ内に指定されたファイルには、追加の初期化パラメータがあります。
古い環境のOracleホームに格納されたパスワード・ファイルがある場合は、そのパスワード・ファイルをOracle Database 12cの新しいOracleホームに移動またはコピーします。
パスワード・ファイルの名前と位置は、オペレーティング・システムによって異なります。LinuxまたはUNIXプラットフォームのデフォルトのパスワード・ファイルはorapwSIDで、ORACLE_HOME/dbsディレクトリにあります。Windowsオペレーティング・システムのデフォルトのパスワード・ファイルはpwdSID.oraで、ORACLE_HOME\databaseディレクトリにあります。どちらの場合も、SIDはOracleインスタンスのIDです。
次の手順を実行して、Oracle Database 12cのパラメータ・ファイルを調整します。
サポートが終了した初期化パラメータを削除して、非推奨になった初期化パラメータを調整します。一部のパラメータはOracle Database 12cではサポートが終了しており、他のパラメータは非推奨となっています。Oracle Database 12cインスタンスを起動するすべてのパラメータ・ファイルから、サポートが終了したパラメータをすべて削除します。サポートが終了したパラメータは、Oracle Database 12cでエラーの原因となる可能性があります。また、新しいリリースで構文が変更になったパラメータも変更します。
アップグレード前情報ツールを使用すると、「非推奨パラメータ」および「サポートが終了したパラメータ」の各セクションに、検出された非推奨となったパラメータおよびサポートが終了したパラメータが表示されます。
初期化パラメータの値をアップグレード前情報ツールによって示された最小値以上に調整します。
パラメータ・ファイルのすべてのパス名が完全に指定されていることを確認します。パラメータ・ファイルには相対パス名を使用しないでください。
パラメータ・ファイルにIFILEエントリがある場合、パラメータ・ファイルのIFILEエントリを変更して、手順1で指定したインクルード・ファイルの新しい場所を指定するようにします。次に、手順aからdでパラメータ・ファイルを編集したときと同じ方法で、IFILEエントリに指定されているファイルを編集します。
クラスタ・データベースをアップグレードしている場合は、SPFILEまたはinitORACLE_SID.oraファイルの変更が必要となることがあります。
これらの調整後、変更したすべてのファイルを保存します。
クラスタ・データベースをアップグレードしている場合は、CLUSTER_DATABASE初期化パラメータをfalseに設定します。アップグレード後に、この初期化パラメータの設定をtrueに戻す必要があります。
|
関連項目:
|
セキュリティ上の理由により、他のOracleホームのOracleホーム・ユーザーとして構成された異なるWindowsユーザー・アカウントでは、同一のOracleベースを共有することはできません。
次の推奨事項は、WindowsプラットフォームでOracle Databaseをアップグレードする前に適用されます。
データベース・アップグレードは、ソースと宛先Oracleホームの両方で同じWindowsユーザー・アカウントがOracleホームのユーザーとして使用された場合にサポートされます。
データベース・アップグレードは、アップグレード対象のデータベースのOracleホームでWindows組込みアカウントを使用する場合にサポートされます。Windows上のOracleホームのユーザーの組込みアカウント・オプションは、Oracle Database 12cより前のリリース(リリース11.2以下)でのみサポートされていました。
Oracleホームのユーザーは、自身のOracleベースおよびOracleホームの外部にあるファイルにはアクセスできない可能性があります。したがって、アップグレード時に別のOracleベースを選択した場合は、Oracle Databaseサービスで古いOracleベースにあるファイルにアクセスできない可能性があります。データベースのアップグレードにDBUAを使用すると、Oracleホームのユーザーは、自身のOracleベースおよびOracleホームの外部にあるファイルにアクセスできます。
手動でのアップグレードまたは古いOracleベースのカスタム・ファイル(ウォレット、構成ファイルなど)を使用する前に、これらの外部ファイルに対してOracleホームのユーザーにアクセス権を付与するか、新しいOracleベースにこれらのファイルをコピーする必要があります。
|
関連項目: Windows上のデータベース管理の詳細は、Oracle Databaseプラットフォーム・ガイドfor Microsoft Windowsを参照してください。 |
Oracle Database 12cでは、新しい基礎となるネット・サービス・パラメータによってデータ圧縮が可能で、これにより、SQL TCP接続を介して転送されるセッション・データ・ユニットのサイズが縮小されます。
次のsqlnet.oraファイルの新しいパラメータで、圧縮、および優先圧縮方式を指定します。
これらの新しいパラメータは以前のリリースではサポートされておらず、Oracle Database 12cでのみ使用可能です。
|
関連項目: 新しいsqlnet.ora圧縮パラメータの詳細は、『Oracle Database Net Servicesリファレンス』 |
アップグレード元のデータベースでリスナーが設定されていない場合は、DBUAを実行する前に、Oracle Net Configuration Assistant (Net CA)を実行して、listener.oraファイルを含むOracle Databaseの新しいリリースのリスニング・プロトコルのアドレスおよびサービス情報を構成する必要があります。リリース11.2より前のリリースのOracle Databaseには、新しいバージョンのリスナーが必要です。新しいリスナーには、以前のOracle Databasesとの下位互換性があります。
DBUAを使用してOracle RACデータベースをアップグレードできます(この方法では、古いOracleホームから、新しいOracle Grid Infrastructureのホームに、リスナーが自動的に移行されます)。Oracle Grid Infrastructureホームでlsnrctlコマンドを使用してリスナーを管理する必要があります。以前のリリースのOracleホームの場所からlsnrctlコマンドを使用しないでください。
|
関連項目: Oracle Net Configuration Assistantの使用方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
アップグレード前の処理、アップグレード処理およびアップグレード後の処理のすべてをテストするデータベース環境の完全な作業用コピーを作成することをお薦めします。現行の本番Oracle Databaseに影響を与えないテスト環境を作成できます。たとえば、Oracle Data Guardでは、フィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースの作成が可能です。
テスト環境は、選択したアップグレード方法によって異なります。
DBUAを使用する場合または手動アップグレードを実行する場合は、現行の本番データベースのテスト・バージョンを作成します。
データ・ポンプ・エクスポート/インポートを使用する場合は、現行の本番データベースのサブセットを使用して、段階的にエクスポートおよびインポートします。
テスト環境を使用してデータベースのアップグレードを行います。ベスト・プラクティスは、ダウンサイズしたコピーまたはテスト・データに対してではなく、アップグレードするデータベースの正確なコピーに対してアップグレード処理のテストを実行することです。正確なコピーを実現できない場合は、テスト環境に移動する代表的なデータのサブセットを慎重に選択し、そのデータでアップグレードをテストします。
|
関連項目:
|
現行のデータベースおよびOracle Databaseの新しいリリースにアップグレードしたテスト・データベースに対して、計画したテストを実行します。
テスト結果を比較し、相違点を記録します。
問題が解決されるまで、必要な回数、テスト・アップグレードを繰り返します。
新しいOracle Databaseで既存のアプリケーションが正常に動作するかを確認するために、この新しくアップグレードされたテスト・データベースをテストします。
利用可能なOracle Databaseの機能を追加して、拡張された機能および新しい機能についてテストします。
アプリケーションが現行のデータベースの場合と同様に動作することを確認します。
|
関連項目:
|
