11g リリース1（11.1）
E05758-02
 目次 |
 索引 |
| Oracle Database アップグレード・ガイド 11g リリース1（11.1） E05758-02 |
|
この章では、データベースをOracle Database 11gリリース1（11.1）にアップグレードする前に、実行しておく手順について説明します。「データベースのアップグレード処理の概要」に示したアップグレード処理の手順1〜3を詳しく説明します。
この章では、次の項目について説明します。
アップグレードの準備として、次の作業を行います。
アップグレード処理を計画する前に、Oracle Database 11gリリース1（11.1）の新機能を理解する必要があります。Oracle Databaseのリリース間の相違点については、『Oracle Database新機能ガイド』を参照してください。 各コンポーネントの新機能については、Oracle Database 11gリリース1（11.1）ドキュメント・セットにある各コンポーネント固有のドキュメントを参照してください。たとえば、Oracle Real Application Clustersの変更点については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。
Oracle Database 11gリリース1（11.1）へアップグレードするために必要なパスは、現行のデータベースのリリース番号によって異なります。 現行のバージョンのOracle Databaseから最新のバージョンに直接アップグレードできない場合があります。 現行のリリースによっては、Oracle Database 11gリリース1（11.1）へのアップグレードには、1つ以上の中間リリースを介したアップグレードが必要となる場合があります。
たとえば、現行のデータベースがリリース8.1.6を実行している場合は、次の手順に従います。
表2-1に、Oracle Databaseのリリースごとに必要なアップグレード・パスを示します。ご使用のデータベースに固有のアップグレード・パスおよびドキュメントを使用してアップグレードします。
| 現行リリース | アップグレード・パス |
|---|---|
|
9.0.1.4 |
直接のアップグレードはサポートされていません。 次のように、Oracle Database 11gリリース1（11.1）へアップグレードする前に、中間リリースのOracle Databaseにアップグレードする必要があります。
Oracle Databaseの中間リリースのドキュメントの指示に従って、中間リリースへアップグレードします。 次に、第3章「新しいリリースへのアップグレード」の指示に従って、中間リリースのデータベースをOracle Database 11gリリース1（11.1）にアップグレードします。 |
|
10.2.0.x |
9.2.0.4以上、10.1.0.2以上および10.2.0.1以上からOracle Database 11gリリース1（11.1）への直接のアップグレードがサポートされています。 Oracle Clusterwareリリース10.2.0.xは、リリース10.2.0.3以上にしてからOracle Database 11gリリース1（11.1）にアップグレードする必要があることに注意してください。「Oracle Real Application Clusters（Oracle RAC）Databaseのアップグレード」を参照してください。 リリース9.2.0.3の場合は、次のように、まず中間リリースのOracle Databaseにアップグレードする必要があります。 Oracle Database 11gリリース1（11.1）にアップグレードするには、第3章「新しいリリースへのアップグレード」の指示に従ってください。 |
次の項で、データベースをOracle Database 11gリリース1（11.1）へアップグレードする際に使用できる方法を説明します。
Database Upgrade Assistant（DBUA）は、対話形式でアップグレード処理の手順を実行し、Oracle Database 11gリリース1（11.1）のデータベースを構成します。DBUAを使用すると、通常は手動で実行するアップグレード処理のすべてのタスクが自動化されます。DBUAでは、表領域、REDOログなどの構成オプションの適切な推奨値が提供されます。ユーザーは、この推奨値を使用できます。
DBUAでは、Oracle Real Application Clusters（Oracle RAC）および自動ストレージ管理（ASM）がサポートされています。
Oracle RAC環境では、DBUAは、クラスタ内のすべてのノードにあるすべてのデータベースおよび構成ファイルをアップグレードします。
DBUAでは、自動ストレージ管理（ASM）を使用するデータベースのアップグレードがサポートされています。ASMインスタンスが検出された場合は、データベースとASMの両方またはASMインスタンスのみの更新を選択できます。
手動アップグレードでは、コマンドラインからSQLスクリプトおよびユーティリティを実行して、データベースをOracle Database 11gリリース1（11.1）へアップグレードします。
手動アップグレードでは、アップグレード処理をより詳細に制御できますが、実行されなかったアップグレード手順またはアップグレード前の手順がある場合、または不適切な順序で実行された場合にエラーが発生する可能性がより高くなります。
データベースを手動でアップグレードする場合、次のアップグレード前の手順を実行します。
アップグレード前情報ツールでは、データベースで発生する可能性のあるアップグレードの問題に関する警告が表示されます。 また、Oracle Database 11gリリース1（11.1）で必要な初期化パラメータの情報が表示されます。
アップグレードしているデータベースのリリースに応じて、追加のアップグレード前の手順（アップグレードに向けたパラメータ・ファイルの調整、廃止された初期化パラメータの削除およびアップグレードの問題が発生する可能性のある初期化パラメータの調整）が必要な場合があります。
アップグレードのスプール・ログ・ファイルを確認し、アップグレード後の状態ツールを使用します。 アップグレード後の状態ツールは、Oracle Database 11gリリース1（11.1）に付属するSQLスクリプトです。新しいリリースの環境で実行する必要があります。
DBUAまたは手動アップグレードとは異なり、エクスポート/インポート・ユーティリティは、現行のデータベースのデータを新しいデータベースに物理的にコピーします。 Oracle Data Pump Export/Importユーティリティ（Oracle Database 10gリリース1（10.1）以上で使用可能）またはオリジナルのエクスポート/インポート・ユーティリティを使用してデータベースの全体または一部をエクスポートし、それを新しいOracle Database 11gリリース1（11.1）データベースにインポートします。エクスポート/インポートによって、元のデータベースを変更することなく、データベース内のデータのサブセットをコピーすることができます。
Oracle Database 10gリリース1（10.1）以上からアップグレードする場合は、パフォーマンス向上の点から、データ・ポンプ・エクスポート/インポートを使用することをお薦めします。
現行のデータベースのエクスポート・ユーティリティは、データベースの特定部分をエクスポート・ダンプ・ファイルにコピーします。 次に、Oracle Database 11gリリース1（11.1）のインポート・ユーティリティが、このエクスポートされたデータを新しいデータベースにロードします。 ただし、エクスポート・ダンプ・ファイルからロードする前に、Oracle Database 11gリリース1（11.1）の新規データベースを準備しておく必要があります。
以前のリリースからデータをインポートする場合、Oracle Database 11gリリース1（11.1）のインポート・ユーティリティでは、以前のリリースのエクスポート・ダンプ・ファイルを読み込む際に、データ定義に適切な変更を加えます。
次の項では、データベースのアップグレードにエクスポート/インポートを使用するかどうかを決定する際に有効な、エクスポート/インポートの特長について説明します。
エクスポート/インポートによるアップグレード方法では、現行のデータベースが変更されません。したがって、データベースは、アップグレード処理を通して常に使用可能な状態です。ただし、一貫性のあるデータベースのスナップショットが必要な場合（データの整合性保持またはその他の目的のため）、データベースは、制限モードで実行するか、またはエクスポート実行時に変更禁止にする必要があります。 現行のデータベースを使用可能な状態にしておくことができるため、たとえば、既存の本番データベースを実行しながら、エクスポート/インポートによるOracle Database 11gリリース1（11.1）の新規データベースの作成を同時に行うことができます。 このアップグレード処理中にデータベースの完全な一貫性を維持するには、データベースのデータを変更する場合に、Oracle Database 11gリリース1（11.1）の新規データベースにも同じ変更を加える必要があります。
最も重要なことは、エクスポート/インポート操作の結果として、新しいデータベースが作成されることです。現行のデータベースには最終的に指定したデータのコピーが含まれますが、アップグレードしたデータベースは、元のデータベースとは異なる方法で運用される場合があります。たとえば、エクスポート/インポート操作によってデータベースと同一のコピーを作成しても、データのディスク配置やチューニング・パラメータの解除など、その他の要素が予期しないパフォーマンスの劣化につながることがあります。
エクスポート/インポートを使用したアップグレードには、次のようなメリットがあります。
エクスポート/インポートを使用するデータベース全体のアップグレードは、DBUAを使用する場合または手動アップグレードを実行する場合と比較して、時間が長くかかる場合があります。したがって、ピーク時を外してアップグレードするようにスケジュールするか、またはアップグレード中に現行のデータベースに対して行われた変更を新しいデータベースに反映させる準備が必要です。
Oracle Database 11gリリース1（11.1）に、現行のリリースのOracleホーム・ディレクトリとは別のOracleホーム・ディレクトリを選択する必要があります。 Oracle Database 11gリリース1（11.1）のパッチ・セット・リリースをインストールしないかぎり、新しいソフトウェアを現行のリリースと同じOracleホーム・ディレクトリにインストールすることはできません。 パッチ・セット・リリースの場合、Oracle Database 11gリリース1（11.1）と同じOracleホームを使用できます。
別のインストール・ディレクトリを使用すると、既存のソフトウェアをインストールしたままで、新しいソフトウェアを使用できます。この方法によって、本番環境全体を置き換える前にテスト・データベース上でアップグレード処理をテストできます。
アップグレード処理のすべての段階を検証するために、一連のテストを慎重に設計する必要があります。緻密なテストを正常に完了できれば、本番データベースのアップグレード処理を十分に理解し、予測できるようになり、アップグレード処理の成功が確実になります。本番データベースをアップグレードする前に、できるだけ多くのテストを実行してください。テスト計画は、非常に重要です。
データベース・リプレイやSQLパフォーマンス・アナライザなどのReal Applicationのテスト機能を使用するか、または手動でテストを実行するかに関係なく、テスト・プランには次のタイプのテストを含める必要があります。
アップグレード・テストでは、DBUAの使用、手動アップグレードの実行、エクスポート/インポートまたはその他のデータのコピー方法を使用するかに関係なく、現行のソフトウェアからOracle Database 11gリリース1（11.1）へのアップグレード・パスを計画およびテストする必要があります。どのアップグレード方法を選択する場合でも、アップグレード計画を作成、テストおよび検証する必要があります。
最小テストでは、現行のデータベースからアプリケーションの全部または一部を新しいデータベースに移動し、データベースの新機能を使用可能にしないでアプリケーションを実行します。最小テストでは、実際の本番環境で発生するような問題が検出されない場合があります。ただし、アプリケーションの起動または呼出しに関する問題がある場合は、すぐに検出されます。
機能テストとは、システムの新機能と既存機能をアップグレード後にテストする一連のテストです。機能テストには、すべてのデータベース、ネットワーキングおよびアプリケーション・コンポーネントのテストが含まれます。機能テストの目的は、システムの各コンポーネントがアップグレード前と同様に機能し、新機能が正常に動作していることを検証することです。
統合テストでは、システムのコンポーネント間で相互作用をテストします。統合テストを計画するときは、次のことを考慮する必要があります。
新しいデータベースのパフォーマンス・テストでは、新しいデータベースでの様々なSQL文のパフォーマンスを、現行データベースでの同じ文のパフォーマンスと比較します。アップグレードする前に、現行データベースでのアプリケーションのパフォーマンス・プロファイルを理解する必要があります。特に、アプリケーションがデータベース・サーバーに対して実行するコールを理解する必要があります。
この項では、次のようなパフォーマンス・テストについて説明します。
Oracle Database 11gリリース1（11.1）より、新しいデータベース・リプレイ機能を使用して、本番データベースを実際にアップグレードする前に、ユーザーの本番ワークロード上でデータベースをアップグレードする現実的なテストを実行できるようになりました。この機能は、本番システム上で実際のデータベースのワークロードを取得して、これをテスト・システム上でリプレイします。たとえば、発生する可能性があるエラーやパフォーマンスの相違などの主要な問題の分析およびレポートの作成も行います。さらに、ADDM、AWRおよびASHなど、定期的なパフォーマンスの監視およびレポート作成ツールをすべて自由に使用して、問題を修正できます。
Oracle Database 11gリリース1（11.1）より、SQLパフォーマンス・アナライザを使用して、システムの変更がSQLワークロードに及ぼす影響を予測できるようになりました。SQLパフォーマンス・アナライザでは、アップグレードによって影響を受けたSQL文を識別してパフォーマンスの相違を測定することで、データベースのアップグレードなどの変更による影響を予測できます。これにより、アップグレードによるSQLパフォーマンスに対する全体的な影響を評価し、悪い結果をユーザーが影響を受ける前に回避できます。
新しいオプティマイザ・バージョンをインストールするデータベース・アップグレードでは、通常、SQL文に対して若干の計画変更がありますが、ほとんどの計画変更ではパフォーマンスは変化しません。ただし、ある一部の計画変更では、パフォーマンスが低下する場合があります。
SQL計画管理では、SQL計画の情報を取得、選択および展開するためのコンポーネントを提供することで、SQL文の実行計画が急に変更された場合に起こるパフォーマンスの低下を回避できます。
SQL計画管理を使用すると、オプティマイザによって実行計画が自動的に管理され、既知の計画または検証済の計画のみが使用されます。SQL文に対する新しい計画が検出されても、その計画が現行の計画と同等かそれ以上のパフォーマンスであることがデータベースによって確認されるまでは使用されません。つまり、SQL計画管理を現行（11gよりも前）の実行計画でシードすると、これらは各文のSQL計画のベースラインになり、これらの計画は、アップグレード後に使用されます。 異なる計画を使用する必要があると11gオプティマイザが判断した場合でも、新しい計画は検証のためにキューに格納され、現行の計画と同等かそれ以上のパフォーマンスを実現できる計画であることが確認されるまでは、使用されません。
SQL管理ベース（SMB）を実行計画にシードまたは移入するには、次の2つの方法があります。
実行計画またはSQL計画ベースラインのバルク・ロードは、データベースを以前のバージョンからOracle Database 11gにアップグレードする場合に特に役立ちます。バルク・ロードされるSQL計画は、自動的にそのまま使用され、SQL計画ベースラインとして既存または新規の計画履歴に追加されます。 次のいずれかの方法で、アップグレードの一部としてSQL管理ベースをバルク・ロードします。
次の手順を実行し、STSの実行計画を使用してSQL管理ベースをバルク・ロードします。
DBMS_SPM.LOAD_PLANS_FROM_SQLSETを使用して、実行計画をSQL管理ベースにロードします。
次の手順を実行し、すべての重要なSQL問合せをOracle Database 11gのテスト環境でテストおよびチューニングしてから、その正確なSQL実行計画をOracle Database 11gの本番環境に移動します。
DBMS_SPM.LOAD_PLAN_FROM_CURSOR_CACHEプロシージャまたはEnterprise Managerを使用して、カーソル・キャッシュ内の実行計画をすべてSQL管理ベースにロードします。
DBMS_SPM.CREATE_STGTAB_BASELINEプロシージャを使用して、ステージング表を作成します。
DBMS_SPM.PACK_STGTAB_BASELINEファンクションを使用して、手順1で作成したSQL計画ベースラインをステージング表に格納します。
DBMS_SPM.UNPACK_STGTAB_BASELINEファンクションを使用して、ステージング表からターゲット・システムのSQL管理ベースにSQL計画ベースラインを展開します。ボリューム/ロード・ストレス・テストでは、アップグレードしたデータベース全体を、大きいボリュームとロードでテストします。ボリュームとは、操作されるデータの量を表します。ロードとは、システム上の同時要求のレベルを表します。ボリューム/ロード・ストレス・テストの目的は、様々なボリュームとロードでの本番システムの動作をエミュレートすることです。
ボリューム/ロード・ストレス・テストは非常に重要ですが、一般に見過ごされがちです。ユーザーは、どのようなボリューム/ロード・ストレス・テストも実行しないことが多いようです。そのかわりに、ビジネス・アプリケーションを特に考慮しているわけではないベンチマークが広く利用されています。アプリケーションのベンチマークは、機能、パフォーマンスおよび統合に関する問題点を検証するために使用するものであり、ボリューム/ロード・ストレス・テストのかわりになるものではありません。
ロード・テストには、本番稼働時に発生する可能性のあるロード条件で新しいエラーやパフォーマンス上の問題などがアプリケーションに発生しないことを確認するため、新バージョンのデータベースに対するアプリケーション・ロードの実行を含みます。多くの場合、問題は特定のロード条件で明らかになるため、通常、機能テストでは見つかりません。データベース・リプレイ機能は、本番環境のシステム・ワークロードを取得し、テスト・システム上で同一形式でリプレイできるため、このようなロード・テストに最適です。
アップグレードが最終的に成功するかどうかは、適切なバックアップ計画の立案と実行で決まります。バックアップ計画を展開するには、次のような問題について考慮する必要があります。
バックアップ計画は、これらの問題のすべてに答え、データベースを正常にバックアップおよびリカバリするための手順を備えている必要があります。
現行の本番データベースに影響しないテスト環境を作成します。テスト環境は、選択したアップグレード方法によって異なります。
テスト環境を使用してデータベースのアップグレードを行います。最適なアップグレードのテストとは、ダウンサイズしたコピーまたはテスト・データに対してではなく、アップグレードするデータベースの正確なコピーに対して実行することです。
新しいOracle Databaseで使用するOCIとプリコンパイラ・アプリケーションを、必ずアップグレードしてください。それによって、現行の本番データベースをアップグレードする前に、それらのアプリケーションをサンプルのデータベースでテストできます。 詳細は、「プリコンパイラおよびOCIアプリケーションのアップグレード」を参照してください。
現行のデータベースおよびOracle Database 11gリリース1（11.1）へアップグレードされたテスト・データベースに対して、計画したテストを実行します。結果を比較し、相違点を記録します。必要に応じて、アップグレードのテストを繰り返します。
新しいOracle Databaseで既存のアプリケーションが正常に動作するかを確認するために、この新しくアップグレードされたテスト・データベースをテストします。 また、利用可能なOracle Databaseの機能を追加して、機能拡張についてもテストします。ただし、アプリケーションが現行のデータベースの場合と同様に動作するかを最初に確認してください。
|
 Copyright © 2008 Oracle Corporation. All Rights Reserved. |
|