| Oracle Database高可用性ベスト・プラクティス 11gリリース1（11.1） B54839-01 |
|
 戻る |
 次へ |
この章では、計画済の停止について説明します。また、各停止タイプを許容するか管理することで停止時間を最小化できるOracle運用ベスト・プラクティスについて説明します。
この章には、次の各項が含まれます。
計画済の停止は、アプリケーションをサポートするテクノロジ・インフラストラクチャの定期メンテナンスのために必要です。これには、次のタスクが含まれます。
ハードウェアのメンテナンス、修復およびアップグレード
ソフトウェアのアップグレードとパッチ適用
アプリケーションの（プログラム的な）変更、パッチおよびアップグレード
システムのパフォーマンスと管理性を向上するための変更
これらの作業の多くは、アプリケーションの可用性を連続的に維持したまま、実装することができます。
表5-1に、プライマリ・サイトまたはセカンダリ・サイトのいずれかに影響を与える計画済の停止を示します。
表5-1 計画済の停止
| 停止範囲 | 説明 | 例 |
|---|---|---|
|
サイト全体 |
現行のプライマリ・データベースが存在するサイト全体が使用不可能になります。通常は、事前に広く通知されます。 |
計画済の停電 サイト・メンテナンス テスト・インフラストラクチャへの定期的な計画済のスイッチオーバー |
|
ハードウェア・メンテナンス（ノードに影響） |
データベース・サーバーでのハードウェア・メンテナンスです。データベース・クラスタの1つのノードに制限されます。 |
メモリー・カードやCPUボードなどの障害コンポーネントの修復 データベース層の既存のノードへのメモリーまたはCPUの追加 |
|
ハードウェア・メンテナンス（クラスタ全体に影響） |
データベース・サーバー・クラスタでのハードウェア・メンテナンスです。 |
クラスタにノードを追加する一部の場合 クラスタ・インターコネクトのアップグレードまたは修復 データベース層の停止を必要とするストレージ層のアップグレード |
|
システム・ソフトウェア・メンテナンス（ノードに影響） |
データベース・サーバーでのシステム・ソフトウェア・メンテナンスです。停止の範囲は、1つのノードに制限されます。 |
オペレーティング・システムなどのソフトウェア・コンポーネントのアップグレード オペレーティング・システムの構成パラメータの変更 |
|
システム・ソフトウェア・メンテナンス（クラスタ全体に影響） |
データベース・サーバー・クラスタでのシステム・ソフトウェア・メンテナンスです。 |
クラスタ・ソフトウェアのアップグレードまたはパッチ適用 ボリューム管理ソフトウェアのアップグレード |
|
データベースのOracleパッチのアップグレード |
Oracleパッチのインストールによる計画済の停止です。 |
特定の顧客問題を修正するためのOracleソフトウェアへのパッチ適用 |
|
データベースのOracleパッチ・セットまたはソフトウェアのアップグレード |
Oracleパッチ・セットまたはソフトウェアのアップグレードによる計画済の停止です。 |
パッチ・セットを使用したOracleソフトウェアへのパッチ適用 Oracleソフトウェアのアップグレード |
|
データベース・オブジェクトの再編成または再定義 |
主にパフォーマンスや管理性を向上する目的で、Oracleデータベース・オブジェクトの論理構造または物理編成を変更します。 データまたはスキーマの変更です。 Oracleデータベースのオンライン再定義機能を使用すると、再編成または再定義中にオブジェクトを使用できます。 |
異なる表領域へのオブジェクトの移動 パーティション表への表の変換 表またはクラスタの1つ以上の列の追加、変更、または削除 |
|
ストレージ・メンテナンス |
データベース・ファイルが存在するストレージのメンテナンスです。 |
ASMへの変換 ストレージの追加または削除 |
|
プラットフォーム移行 |
プライマリ・データベースとスタンバイ・データベースのオペレーティング・システム・プラットフォームを変更します。 |
Linuxオペレーティング・システムへの移行 |
|
ロケーション移行 |
プライマリ・データベースの物理的な場所を変更します。 |
あるデータ・センターから別のデータ・センターへのプライマリ・データベースの移行 |
|
プログラム的な変更 |
データ変更、スキーマおよびその他のプログラム的な変更が含まれます。 |
アプリケーション・アップグレード |
次の各項では、プライマリ・サイトとセカンダリ・サイトでの計画済の停止を削減するための推奨ベスト・プラクティスについて説明します。
表5-2に、プライマリ・サイトで計画済の停止を実行するための適切なソリューションを示します。この表には、5.2項「計画済の停止による停止時間の回避または短縮」の詳細な説明へのリンクが含まれます。
表5-2 プライマリ・サイトでの計画済の停止のソリューション
| 計画済のメンテナンス | 優先されるOracleソリューション | 停止時間見積り |
|---|---|---|
|
サイト・メンテナンス |
|
5分未満 |
|
ハードウェア・メンテナンスまたはシステム・ソフトウェア・メンテナンス（クラスタ全体に影響） |
|
5分未満 |
|
ハードウェア・メンテナンスまたはシステム・ソフトウェア・メンテナンス（ノードに影響） |
Oracle RACサービスの再配置（5.2.10項「システム・メンテナンス」参照） |
停止時間なし |
|
Oracle RAC Cluster Ready Service（CRS）のアップグレード |
Oracle CRSのローリング・パッチ・アップグレード（詳細は、使用するプラットフォームに対応するOracleクラスタウェアのインストレーション・ガイドを参照） |
停止時間なし |
|
データベースのOracleパッチのアップグレード、クリティカル・パッチ更新（CPU） |
opatchを使用したOracle RACローリング・パッチ・アップグレード（5.2.3項「Oracle RACデータベース・パッチ」を参照） |
停止時間なし |
|
Oracle診断個別パッチ |
|
停止時間なし |
|
ASMのアップグレード |
オンラインASMアップグレード（『Oracle Databaseストレージ管理者ガイド』の「ASMのローリング・アップグレードの使用」を参照） |
停止時間なし |
|
データベースのOracleパッチ・セットまたはソフトウェアのアップグレード |
Data Guard SQL Applyを使用したOracle Databaseのローリング・アップグレード（5.2.5項「データベース・アップグレード」）を参照 |
5分未満 |
|
データベース・オブジェクトの再編成または再定義 |
|
停止時間なし |
|
データベース・ストレージ・メンテナンス |
ASMを使用したオンライン・ストレージ・メンテナンス（5.2.4項「ストレージ・メンテナンス」を参照） |
停止時間なし |
|
データベースのプラットフォームまたはロケーションのメンテナンス |
|
5分未満 |
|
アプリケーションの変更 |
「オンライン・データベース・アップグレードでのOracle Streams」 |
5分未満 |
クライアントは常にプライマリ・サイトにアクセスするため、セカンダリ・サイトでの停止は可用性に影響しません。セカンダリ・サイトで停止が発生したときにプライマリ・サイトで同時障害が発生すると、RTOに影響する可能性があります。セカンダリ・サイトで発生する停止は、可用性に影響を与えることなく管理できます。
最大保護データベース・モードで構成しており、プライマリ・データベースを保護するスタンバイ・データベースが1つのみの場合、プライマリ・データベースで停止時間が発生しないように、スタンバイ・インスタンスまたはデータベースで計画済の停止を実行する前に保護モードをダウングレードする必要があります。
最大保護データベース・モードで構成されていて、複数のスタンバイ・データベースが存在する場合、LGWR SYNC AFFIRM属性で構成された1つ以上のスタンバイ・データベースが利用でき、それプライマリ・データベースがREDOデータを転送できるかぎり、保護モードをダウングレードする必要はありません。
セカンダリ・サイトのメンテナンスをスケジュールする場合、サイト全体またはクラスタ全体の停止期間が増加するほどスタンバイ・データベースとプライマリ・データベースの差異が拡大し、それによりフォルト・トレランスを回復するための時間も増加することに注意してください。Data Guardの保護モードの概要は、2.6.2項「適切なデータ保護レベルの選択」を参照してください。
表5-3に、セカンダリ・サイトで計画済の停止を実行するための手順をまとめます。
表5-3 セカンダリ・サイトでの計画済の停止の管理
| 計画済のメンテナンス | Data Guardを使用したOracle Database 11g | Oracle Database 11g（MAA） |
|---|---|---|
|
サイト停止 |
停止前: 停止後: |
停止前: 停止後: |
|
管理リカバリ・プロセス（MRP）を実行しているノードでのハードウェアまたはソフトウェア・メンテナンス |
停止前: |
停止前: |
|
MRPを実行していないノードでのハードウェアまたはソフトウェア・メンテナンス |
適用なし |
プライマリ・スタンバイ・ノードまたはインスタンスは、管理リカバリ・プロセスで適用されるREDOログを受信するため、影響はありません。 停止後: 使用可能になったら、ノードとインスタンスを再起動します。 |
|
ハードウェアまたはソフトウェア・メンテナンス（クラスタ全体に影響） |
適用なし |
停止前: 停止後: |
|
Oracleパッチとソフトウェアのアップグレード |
アップグレードのために停止時間が必要ですが、構成が最大保護データベース・モードでないかぎり、プライマリ・ノードに影響はありません。 |
アップグレードのために停止時間が必要ですが、構成が最大保護データベース・モードでないかぎり、プライマリ・ノードに影響はありません。 |
この項では、計画済の停止による停止時間を回避または短縮するためのベスト・プラクティスについて説明します。この項には、次の各項目が含まれます。
一般に、アップグレードの範囲が小さいデバッグ・パッチや個別パッチを適用する場合は、オンライン・パッチが、停止時間を回避するための推奨ソリューションです。オンライン・パッチを使用してアップグレードを実行できない場合、Oracle Data Guardを使用する前のOracle RACが次の推奨ソリューションです。次がトランスポータブル表領域、次がOracle Streamsです。使用する方法に関係なく、必ず『Oracle Databaseアップグレード・ガイド』と、その付属ドキュメント『Oracle 11g Upgrade Companion』（http://metalink.oracle.com/から入手できるサポート・メモ601807.1に含まれています）で説明されるガイドラインと推奨事項に従ってください。また、ローリング・アップグレードを実行する前に、広範囲のテストの実行をお薦めします。
スイッチオーバーは、プライマリ・データベースとスタンバイ・データベースの間でデータベース・ロールを切り替えるための一連の手順を含む計画済の移行です。スイッチオーバー操作に成功すると、スタンバイ・データベースがプライマリ・ロールを引き継ぎ、プライマリ・データベースがスタンバイ・データベースとなります脚注1。Data Guardを使用すると、Oracle Enterprise Managerとブローカを使用するか、SQL*Plus文を手動で発行することによって、これらのロールを動的に変更することができます。
スイッチオーバーは、サイト・メンテナンス、およびハードウェアやソフトウェアのメンテナンス（データベース・アップグレードなど）を実行するとき、多くの状況で便利です。
プライマリ・データベースが起動しており、ターゲット・スタンバイ・データベースが使用可能で、すべてのアーカイブREDOログが使用できる場合、いつでもスイッチオーバーを実行できます。
スイッチオーバーは、次のような状況で役立ちます。
計画されたメンテナンス（プライマリ・ホストでのハードウェア・メンテナンスやファームウェア・パッチ適用など）
プライマリ・データベースをオープンしたままでのデータ障害の解決
セカンダリ・リソースのテストと検証（障害時リカバリの準備状況をテストする手段として）
SQL Applyを使用したローリング・アップグレードの実行（5.2.5.2項「Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベース」を参照）
スイッチオーバーは、次の場合には使用できないか、または効果がありません。
適用に必要なアーカイブREDOログ・ファイルがない場合
ポイント・イン・タイム・リカバリが必要な場合
プライマリ・データベースがオープンしておらず、オープンできない場合
スイッチオーバーを実行する前に、2.6.7.1.1項「スイッチオーバーのベスト・プラクティス」で説明されている構成ベスト・プラクティスに従います。
Oracle Enterprise Managerを使用して、動的にスイッチオーバーを実行することをお薦めします。Oracle Enterprise Managerを使用していない場合、DGMGRLコマンドライン・インタフェースまたはSQL*Plus文を使用して、手動でスイッチオーバーを実行することができます。
Oracle Enterprise Managerの使用（『Oracle Data Guard Broker』を参照）
DGMGRLコマンドライン・インタフェースの使用（『Oracle Data Guard Broker』を参照）
SQL*Plusの使用
この項は、スイッチオーバー手順の概要を説明します。詳細な手順は『Oracle Data Guard概要および管理』を参照してください。
フィジカル・スタンバイ・データベースへのスイッチオーバーを実行するには、次の手順を実行します。
ユーザー・セッションを切断し（存在する場合）、アプリケーション処理を無効化または停止します。
プライマリ・データベースがOracle RACの場合、1つを残してすべてのプライマリ・インスタンスをシャットダウンします。この操作を迅速化するには、SHUTDOWN ABORT文を発行します。
プライマリ・データベースに次のSQL文を発行してスタンバイ・データベース・ロールに変換します。
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN;
スタンバイ・データベースがOracle RACの場合、1つを残してすべてのスタンバイ・インスタンスをシャットダウンします。この操作を迅速化するには、SHUTDOWN ABORT文を発行します。
スタンバイ・データベースが読取り専用でオープンされていたことがないか確認します。
元のスタンバイ・データベースに次のSQL文を発行してスイッチオーバーを実行します。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
新しいプライマリ・データベースをオープンします。
ALTER DATABASE OPEN;
|
注意:
|
新しいスタンバイ・データベース（元のプライマリ・データベース）上で、データベースをマウント状態にしてREDO Applyを起動します。新しいプライマリ・データベースがオープンすると同時に、次のコマンドを発行することができます。
SHUTDOWN IMMEDIATESTARTUP MOUNTALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
ユーザー・セッションとアプリケーション処理を再開します。
本番データベースとスタンバイ・データベースがOracle RAC構成の場合、プライマリおよびスタンバイ・データベース上のすべてのインスタンスを起動します。
この項は、スイッチオーバー手順の概要を説明します。詳細な手順は『Oracle Data Guard概要および管理』を参照してください。
SQL*Plusコマンドを使用してスイッチオーバーを実行する場合、新規プライマリ・データベースに移行する予定の元のスタンバイ・データベースで、スイッチオーバーを実行する前にLogMinerディクショナリを構築して現在のプライマリ・データベース（新規スタンバイ・データベース）に転送できます。これにより、スイッチオーバーの実行に要する合計時間を短縮できます。次の手順では、この最適化された操作の実行方法について説明します。
プライマリ・データベースに次のSQL文を発行して、現在のスタンバイ・データベースからのREDO受信を有効化します。
ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;
現在のロジカル・スタンバイ・データベースで、LogMinerディクショナリを構築して現在のプライマリ・データベースに転送します。
ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
ユーザー・セッションを切断し（存在する場合）、アプリケーション処理を無効化または停止します。
V$DATABASEビューのSWITCHOVER_STATUS列の問合せによりTO LOGICAL STANDBYが戻された場合、次の文を発行してプライマリ・データベースをスタンバイ・データベースに変換します。
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY WITH SESSION SHUTDOWN;
元のスタンバイ・データベースに次の文を発行します。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Oracle Database 11g以降では、特定の性質を持つ個別パッチにオンライン・パッチをサポートしています。オンライン・パッチは、インスタンスを停止しないでOracleインスタンスのプロセスにパッチを当てる機能です。インスタンスに関連付けられる各プロセスは、安全実行点でパッチを適用したコードをチェックし、続いてそのコードをプロセス空き領域にコピーします。このように、パッチを適用したプロセスは、正確に同じ時間に新しいコードを取り上げるわけではありません。
従来のパッチとオンライン・パッチの主要な違いは、従来のパッチがソフトウェア・レベルで実装され、オンライン・パッチがソフトウェアまたはOracleインスタンス・レベルで実装されるということです。つまり、従来のパッチを受信するORACLE_HOMEを使用するインスタンスは常にパッチが適用されたコードを受信するのに対して、オンライン・パッチを受信するORACLE_HOMEを受信するインスタンスがパッチを適用されたコードを受信するのは、パッチが適用されるときにそのインスタンスが指定されていた場合のみです。
一般に、修正の範囲が小さいデバッグ・パッチや個別パッチを適用する場合は、オンライン・パッチが推奨ソリューションです。ローリング・パッチに適用される同じ制約はオンライン・パッチにも適用され、さらにいくつかの追加の制約があります。
オンライン・パッチのベスト・プラクティスには、次のような点があります。
パッチは一度に1つのインスタンスに適用します。
オンライン・パッチをロールバックする場合、パッチを適用されたインスタンスがすべて含まれることを確認してください。
同じ$ORACLE_HOMEを使用する複数インスタンスにわたって異なるソフトウェアがあるような、危険で混乱した状況は回避します。
本番環境にデプロイする前に、テスト・システムへのメモリーの影響を評価します（例: pmapコマンド）。
$ORACLE_HOME/hpatchディレクトリは決して削除しないでください。
|
関連項目:
|
Oracle RACでは、特定のデータベース・パッチをノードまたはインスタンスごとに適用できるため、アプリケーションとデータベースを継続的に使用できます。データベース・ソフトウェア用の個別パッチ、個別パッチおよびクリティカル・パッチ更新（CPU）を適用するのは、通常、インストール環境で発生したソフトウェア問題の既知の修正策を実装する場合か、問題に関する情報を収集するための診断パッチを適用する場合です。このようなパッチ適用は、一般的に、計画された停止期間中のメンテナンスで実行されます。
Oracleでは、データベースをまったく停止しないか、最小限の停止時間でOracle RACのローリング・パッチ・アップグレードを実行できます。この操作を行うためのツールは、opatchコマンドライン・ユーティリティです。
Oracle RACローリング・アップグレードのメリットは、パッチ・アップグレードに必要とされる計画済の停止期間中でも、Oracle RACインストール環境の一部のインスタンスを使用できることです。停止する必要があるのは、現在パッチを適用中のOracle RACインスタンスのみです。その他のインスタンスは、引き続き使用できます。これにより、このような計画済の停止に必要とされるアプリケーションの停止時間に対する影響を最小限に抑えることができます。Oracleのopatchユーティリティでは、Oracle RACインストール環境の異なるインスタンスに対して連続的にパッチを適用できます。
ローリング・アップグレード機能は、オラクル社がローリング・アップグレードに適切であると認定したパッチでのみ使用できます。一般的に、ローリング・アップグレードでは次のパッチをインストールできます。
データベースの内容（データ・ディクショナリなど）に影響を与えないパッチ
Oracle RACのノード間通信に関連しないパッチ
SQL*Plus、Oracleユーティリティ、開発ライブラリ、Oracle Netなどのクライアント側のツールに関連しないパッチ
データファイル・ヘッダー、制御ファイル、カーネル・モジュールの共通ヘッダー定義などの共有データベース・リソースを変更しないパッチ
パッチのローリング・アップグレードは、現在個別パッチでのみ使用可能です。パッチ・セットでは使用できません。
ローリング・パッチ・アップグレードは、Oracleデータベース・ソフトウェアが異なるノード間で共有されるデプロイメントでは使用できません。これに該当するのは、クラスタ・ファイル・システム（CFS）上、またはファイル・サーバーやNFSマウント・ドライブにより提供される共有ボリューム上にOracleホームが存在する場合です。この機能を使用できるのは、各ノードがOracleデータベース・ソフトウェアの独自のコピーを所有している場合のみです。
すべてのデータベース・パッチ・アップグレードで、次の推奨プラクティスを使用します。
Oracleサポート・サービスに連絡して、パッチが現在の問題とデプロイメント環境に有効であることを必ず確認します。
パッチを適用する計画とともに、パッチをバック・アウトする計画を作成します。
パッチは先にテスト環境に適用し、問題が修正されることを確認します。
パッチを適用する際の所要時間を見積もる場合、必要に応じてテクノロジ・スタックの他の層を起動および停止する時間も含めます。
パッチがOracle RACローリング・アップグレードに適しておらず、パッチの適用時に停止時間が発生する可能性がある場合、5.2.5項「データベース・アップグレード」を参照して他の解決方法を実行できないかどうかを検討します。
次に、Oracle RACローリング・アップグレードの追加の推奨プラクティスを示します。
複数のインスタンスでOracleホームを共有している場合、それらすべてのインスタンスがパッチの適用により影響を受けます。管理者は、これにより意図しない別の問題が発生しないことを確認する必要があります。また、パッチの適用中は、ノード上のこのようなインスタンスをすべて停止する必要があります。計画済の停止を計画する場合、そのことを考慮する必要があります。ベスト・プラクティスとしては、類似するアプリケーションのみでノード上のOracleホームを共有します。これにより、パッチ適用の柔軟性が向上します。
各ノードのOracleインベントリは、そのノードにインストールされているOracleデータベース・ソフトウェアのリポジトリです。インベントリは、各ノードに固有です。インベントリは、ノードにインストールされているすべてのOracleソフトウェアにより共有されます。このインベントリがノード間で類似するのは、デプロイされているOracleデータベース・ソフトウェア、デプロイメント構成およびパッチ・レベルに関してすべてのノードが同じである場合のみです。Oracleインベントリは、パッチ適用およびパッチ管理プロセスに非常に役立つため、その整合性を維持することをお薦めします。Oracleインベントリは、特定のノードのOracleソフトウェアにパッチをインストールするたびにバックアップする必要があります。この原則は、クラスタの各ノードのOracleインベントリに適用されます。
Oracle Universal Installerを使用してすべてのOracleデータベース・ソフトウェアをインストールします。これにより、関連するリポジトリ・エントリがクラスタの各ノードのOracleインベントリに作成されます。また、既存のOracle RACクラスタにノードを追加する場合もOracle Universal Installerを使用します。
ただし、この操作を実行していない場合や、なんらかの理由で実行できない場合、opatchユーティリティのattachオプションを使用して、既存のOracleデータベース・ソフトウェア・インストールに関する情報をOracleインベントリに追加できます。ノード情報もこのオプションで追加できます。
Oracleローリング・パッチ・アップグレードでは、その性質上、パッチをOracle RACクラスタの一部のノードにのみ適用できます。そのため、パッチの適用されているインスタンスと、パッチの適用されていないインスタンスが同時に稼働することになります。この状態は、ローリング・パッチ・アップグレード以外の方法では発生しません。Oracle RACデプロイをアクティブ化する前であれば、ローリング・パッチ・アップグレード以外の方法ですべてのインスタンスにパッチを適用します。パッチをすべてのインスタンスにデプロイする前にテストする必要がある場合、混在環境は役立ちます。これを実現するのに推奨される方法は、-localオプション付きでパッチを適用することです。
Oracle RACクラスタのすべてのインスタンスを同じパッチ・レベルで維持するため、検証の完了したパッチは、Oracle RACインストール環境のすべてのノードに適用することを強くお薦めします。Oracle RACクラスタの各インスタンスが同じパッチ・ソフトウェアを維持している場合、パッチの修正対象である問題を発生させることなくインスタンス間でサービスを移行できます。
すべてのパッチ（ローリング・アップグレードにより適用されるパッチを含む）は、オンラインで管理し、適用後も削除しないようにします。パッチを保存しておくと、パッチをロールバックまたは再適用する場合に役立ちます。
パッチは、クラスタのすべてのノードからアクセスできる場所に保存します。これにより、クラスタのすべてのノードで、同じようにパッチを適用またはロールバックできます。
ローリング・パッチ・アップグレードは、他の任意のパッチ・アップグレードと同様に、ノードで別のパッチ・アップグレードまたはOracleインストールが行われていない場合に実行します。複数のパッチの適用は、順次処理するため、計画済の停止はあらかじめそれに応じて計画します。
複数のパッチを同時に適用する必要があるが、ローリング・アップグレードできるパッチがその一部のみである場合は、すべてのパッチをローリング・アップグレードでない方式で適用します。これにより、パッチ適用プロセスの完了に必要とされる合計時間を短縮できます。
ローリング・アップグレードに適さないパッチの場合、Oracle RACデプロイ用として次に適切なオプションは、APPLYコマンドのMINIMIZE_DOWNTIMEオプションです。
ローリング・アップグレードを実行するのは、システム使用率が低く、エンド・ユーザーへのサービス中断の影響を最小にできるのが確実であるときです。
|
関連項目: opatchユーティリティの詳細は、『Oracle Universal InstallerおよびOpatchユーザーズ・ガイド』を参照してください。 |
システム上にストレージを追加したり、アップグレードしたりするときは、次の手順を使用します。次の各項の手順では、ストレージをASMディスク・グループに追加すると仮定します。
ファイル・システムまたはRAWデバイスにデータベース・ファイルを格納する既存のOracleデータベースがある場合、それらのデータベース・ファイルの一部または全部をASMに移行できます。停止時間を最小にするには、フィジカル・スタンバイ・データベースを使用して、データをASMストレージに移行します。
|
関連項目:
|
ディスクは、停止時間なしでASMを対象に追加または削除できます。ディスクを追加または削除すると、ASMによって自動的にリバランス操作が開始され、ディスク・グループの内容がディスク・グループ内のすべてのドライブに均等に分散されます。ストレージを追加または削除するためのベスト・プラクティスは、次のとおりです。
ASMを使用してストレージの追加や削除を行う前に、ホスト・オペレーティング・システムとストレージ・ハードウェアが、停止時間なしでのストレージの追加や削除をサポートしていることを確認します。
複数のディスク・ドライブを追加または削除する場合、単一のALTER DISKGROUPコマンドを使用します。
たとえば、ストレージ・メンテナンスでドライブを追加し、既存のドライブを削除する場合、ドライブを追加するためのADD DISK句と、既存のドライブを削除するためのDROP DISK句を指定した単一のALTER DISKGROUPコマンドを使用します。たとえば、次のようになります。
ALTER DISKGROUP data
DROP DISK diska5
ADD FAILGROUP failgrp1 DISK '/devices/diska9' NAME diska9;
ディスク・グループからディスクを削除する場合、削除対象のドライブの内容が他のドライブに移行されるまでALTER DISKGROUP文が戻されないように、REBALANCE句にWAITオプションを指定します。文が完了したら、システムから安全にドライブを削除できます。たとえば、次のようになります。
ALTER DISKGROUP data DROP DISK diska5 ADD FAILGROUP failgrp1 DISK '/devices/diska9' NAME diska9 REBALANCE WAIT;
標準または高冗長性ディスク・グループのディスクを削除する場合、完全な冗長性を再構築するのに十分な空き領域がディスク・グループに存在することを確認します。
Enterprise Managerを使用するか、V$ASM_OPERATIONを問い合せることでリバランス操作の進行状況を監視します。
データベース・アクティビティの頻度が低い期間に長く実行されるリバランス操作では、リバランスの最大能力が向上するため、リバランス時間を短縮できます。
|
関連項目: 『Oracle Databaseストレージ管理者ガイド』 |
ASMローリング・アップグレードを実行すると、クラスタ化ASMノードのアップグレードまたはパッチ適用を独立して行うことで、データベース可用性に影響を与えずに稼働時間を最大化できます。ASMローリング・アップグレードを使用できるのは、Oracle Database 11g以上のリリースを実行している環境でクラスタ化ASMインスタンスをアップグレードする場合のみです。
|
関連項目: 詳細は、『Oracle Databaseストレージ管理者ガイド』の「ASMのローリング・アップグレードの使用」を参照してください。 |
データベース・アップグレードを実行する場合、次のOracle機能を使用できます。
データベース・アップグレードの実行方法は、次のことを考慮したうえで選択します。
アップグレードを完了するのに必要な停止時間
停止時間の前に必要な設定時間および作業
一時的に必要となる追加リソース（ディスク領域やCPUなど）
アップグレードを完了するのに許容される手順の複雑さ
表5-4に、データベース・アップグレードに使用できる方法と、その方法の使用が推奨される場合についてリストします。
表5-4 データベース・アップグレード・オプション
| アップグレード方法 | この方法を使用する場合 |
|---|---|
|
|
メンテナンス・ウィンドウが十分であるか、データ型制約によりこの表の他の方法を使用できない場合の推奨の方法 |
|
Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベース |
DBUAがメンテナンス・ウィンドウ内に終了せず、データベースがOracle RACローリング・パッチ・アップグレードに適していない場合 フィジカル・スタンバイ・データベースが1つのみの構成の場合は、一時ロジカル・スタンバイを使用 |
|
|
Streamsが実装されている場合、または使用中のデータベース・リリースがData Guard SQL Applyのローリング・アップグレードでサポートされない場合 |
|
|
Data Guard SQL ApplyまたはOracle Streamsでサポートされないデータ型をデータベースで使用しており、ユーザー・スキーマが単純な場合 |
使用するアップグレード方法に関係なく、『Oracle Databaseアップグレード・ガイド』と、その付属ドキュメント『Oracle 11g Upgrade Companion』（http://metalink.oracle.com/から入手できるサポート・メモ601807.1に含まれています）で説明されるガイドラインと推奨事項に従ってください。
Database Upgrade Assistant（DBUA）は、データベースを以前のソフトウェア・リリースからインプレースでアップグレードする際に使用します。
最小限の停止時間でデータベース・アップグレードを実行する際に、DBUAを適切なツールとして使用するかどうかを決定する場合、次の点を考慮してください。
DBUAにより、データベース・ディクショナリとインストール済のすべてのコンポーネント（Java、XDB、Streamsなど）がアップグレードされますが、アップグレード中は通常のユーザー・アクティビティでデータベースを使用できなくなります。
DBUAを使用したデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。
すべてのデータベース・ディクショナリ・オブジェクトを新規バージョンにアップグレードする時間
データベースの再起動
すべてのデータベース辞書オブジェクトのアップグレード
すべてのPL/SQLを再コンパイルする時間
アップグレードしたデータベースにクライアントを再接続する時間
DBUAの使用時にデータベース・アップグレードに必要とされる停止時間を短縮するには、次のようにします。
使用されていないデータベース・オプションをすべて削除します。
DBUAでは、アプリケーションで必要とされるかどうかにかかわらず、インストール済のすべてのデータベース・オプションがアップグレードされます。アップグレードの必要なオプションの数を減らすことで、アップグレード時間全体を短縮できます。
使用されていないユーザー指定のPL/SQLプロシージャを削除します。
データベースのすべてのPL/SQLルーチンは、アップグレード・プロセスの一環として無効化され、再コンパイルされます。アップグレード時に必要とされる再コンパイルの量を減らすことで、アップグレード時間全体を短縮できます。
DBUAによるアップグレードの実行時間がメンテナンス・ウィンドウ内に収まる場合は、データベース・アップグレードにDBUAを使用してください。
|
関連項目:
|
ローリング・アップグレードと呼ばれるプロセスを使用して、最小の停止時間でデータベースをアップグレードするには、Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用します。現在のところ、Data Guardでは、プライマリ・データベースとスタンバイ・データベースが同じプラットフォームで稼働する同機種環境をサポートしています。
|
関連項目: 異機種環境に固有の例外と、SQL Applyによるローリング・アップグレードのその他の最新情報は、サポート・ノート413484.1を参照してください（http://metalink.oracle.com/）。 |
SQL Applyローリング・アップグレード
従来の方法によるアップグレードがメンテナンス・ウィンドウ内に完了せず、アプリケーションでユーザー定義型を使用していない場合は、Data Guard SQL Applyのローリング・データベース・アップグレードを使用してください。
データベース・アップグレード時の停止時間を最小化するためにSQL Applyが適切な方法であるかどうかを決定する場合、次の点を考慮してください。
SQL ApplyとOracle Streamsは、同一のログ・マイニング・インフラストラクチャを使用するため、ユーザー定義型に関するデータ型の制限も同じです（オブジェクト型、REF値、VARRAY、ネストした表など）。SQL Applyには、データ型の制限がいくつかあります（制限のリストは、『Oracle Data Guard概要および管理』を参照）。データ型の制限がある場合は、拡張データ型サポート（EDS）の実装を検討してください。
EDSでは、SQL Applyを使用して、ネイティブにサポートされない一部のデータ型を含む表に対する変更を、あるデータベースから別のデータベースにレプリケートします。Oracle Database 10gリリース2（10.2.0.4）パッチ・セット3以上では、SQL Applyにより、ロジカル・スタンバイ・データベースでトリガーを起動できますが、これはEDSの基礎となります。EDSの概要は、次の場所で入手できるMAAホワイト・ペーパー『Extended Datatype Support: with SQL Apply and Oracle Streams』を参照してください。
http://www.oracle.com/technology/deploy/availability/pdf/maa_edtsoverview.pdf
EDSを使用して、SQL Applyでネイティブ・サポートされていないデータ型をサポートする例については、サポート・ノート559353.1を参照してください（http://metalink.oracle.com/）。
SQL Applyローリング・アップグレードは、ソース・リリースがOracle Database 10gリリース1（10.1.0.3）以上であれば、メジャー・リリース・アップグレードを含むすべてのアップグレードに対して実行できます。作業を開始する前に、『Oracle Data Guard概要および管理』でSQL Applyローリング・アップグレードの詳細な手順と、サポートされるデータ型を確認してください。
Data Guard SQL Applyを使用したデータベース・アップグレード（ローリング・アップグレード）に必要な停止時間は、次の操作に要する時間によって決定されます。
Data Guardスイッチオーバーを実行する時間
新規データベースにクライアントを再接続する時間
|
関連項目:
|
一時ロジカル・スタンバイ・データベースのローリング・アップグレード
一時ロジカル・スタンバイ・データベースを使用して、ローリング・データベース・アップグレードを実行することができます。それには、現在のフィジカル・スタンバイ・データベースを一時的にロジカル・スタンバイ・データベースに変換します。フィジカル・スタンバイ・データベースが1つのみの構成の場合は、一時ロジカル・スタンバイを使用します。一時ロジカル・スタンバイを使用するローリング・アップグレードの実行は、標準的なSQL Applyのローリング・アップグレードに類似していますが、次の点が異なります。
保証付きリストア・ポイントがプライマリ・データベース上に作成され、スイッチオーバーの後、データベースをフィジカル・スタンバイ・データベースにフラッシュバックします。
フィジカル・スタンバイ・データベースのロジカル・スタンバイ・データベースへの変換では、KEEP IDENTITY句を使用して、プライマリ・データベースと同じDB_NAMEとDBIDを保持します。
ALTER DATABASE CONVERT TO PHYSICAL STANDBY文が、元のプライマリ・データベースを、ロジカル・スタンバイからフィジカル・スタンバイ・データベースに変換します。
元のプライマリ・データベースは、一時ロジカル・スタンバイ・データベース・ロールからフィジカル・スタンバイ・データベースに変換された後で、REDO Applyを使用して実際にアップグレードされます。
図5-1に、一時ロジカル・スタンバイ・データベースを使用してローリング・アップグレードを実行するときに発生する処理のフローを示します。
図5-1 一時ロジカル・スタンバイ・データベースを使用したデータベース・ローリング・アップグレード
この手順は、『Oracle Data Guard概要および管理』の「既存のフィジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行」に記載されています。
|
関連項目: MAAホワイト・ペーパー『Rolling Database Upgrades for Physical Standby Databases Using Transient Logical Standby 11g』 |
最小限の停止時間でデータベース・ソフトウェアをあるリリースから別のリリースにアップグレードするには、Oracle Streamsを使用します。その理由は、Oracle Streamsでは、異なるデータベース・リリースに基づいてプライマリ・データベースとそのレプリカが稼働する構成がサポートされるためです。
データベース・アップグレードにOracle Streamsが適切な方法であるかどうかを決定する場合、次の点を考慮してください。
Oracle Streamsでは、ユーザー定義型がサポートされません（オブジェクト型、REF値、VARRAY、ネストした表など）。ただし、データ型の制限がある場合は、拡張データ型サポート（EDS）の実装を検討してください。
EDSでは、Streamsを使用して、ネイティブにサポートされない一部のデータ型を含む表に対する変更を、あるデータベースから別のデータベースにレプリケートします。EDSの概要は、次の場所で入手できるMAAホワイト・ペーパー『Extended Datatype Support』を参照してください。
http://www.oracle.com/technology/deploy/availability/pdf/maa_edtsoverview.pdf
EDSを使用して、SQL Applyでネイティブ・サポートされていないデータ型をサポートする例については、サポート・ノート556742.1『To obtain additional information about EDS for Oracle Streams』を参照してください（http://metalink.oracle.com/）。
ソース・データベースでは、Oracle9iリリース2以上が稼働している必要があります。
データベース・アップグレードのためにOracle Streams環境をセットアップして、維持するには、大きな管理上の労力が必要とされることがあります。
Oracle Streamsのローカル取得では、ソース・データベースとターゲット・データベースをパラレルに実行してターゲット・データベースに変更を伝播する場合、ソース・データベースにパフォーマンス上の影響が発生する可能性があります。
Oracle Streamsを使用したデータベース・アップグレードに必要な停止時間は、新しいデータベースにクライアントを再接続する時間によって決定されます。
次の場合は、Oracle Streamsの使用を検討してください。
アプリケーションでStreamsを使用している場合。
アップグレードされた（ターゲット）データベースで、ソースで生成されるよりも速く変更を適用できる場合。
|
関連項目: Oracle Streamsを使用したデータベース・アップグレードの詳細は、『Oracle Streams概要および管理』を参照してください。 |
トランスポータブル表領域を使用すると、すべてのユーザー・データファイルを事前に作成および準備されたターゲット・データベースにトランスポートすることで、データベース・アップグレードを実行できます。
データベース・アップグレードの実行にトランスポータブル表領域が適切な方法であるかどうかを決定する場合、次の点を考慮してください。
SYSTEM表領域は、トランスポータブル表領域で移動できません。ユーザー定義やアプリケーションに必要なオブジェクトを含むターゲット・データベースのSYSTEM表領域の内容は、手動で構築する必要があります。SYSTEM表領域の内容を移動する場合、データ・ポンプを使用します。
トランスポータブル表領域を使用したデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。
ソース・データベースの表領域を読取り専用モードにする時間。
トランスポータブル・メタデータのネットワーク・インポートを実行する時間。
ターゲット・データベースがリモート・システムに存在する場合、ソース・システムからターゲット・システムにすべてのデータファイルを転送する時間。ただし、トランスポータブル表領域を使用してデータベース・アップグレードを実行すると有益なのは、データファイルをその現在の場所で使用できる場合のみです。データファイルをターゲットの場所にコピーする必要がある場合、トランスポータブル表領域による方法は推奨されません。
データファイルの転送時間を大幅に短縮するには、ファイルを物理的に移動することなくターゲット・システムでデータファイルを使用可能にするストレージ・インフラストラクチャを使用するか、フィジカル・スタンバイ・データベースを使用します。
トランスポータブル表領域を使用したデータベース・アップグレードの実行は、次の場合に推奨されます。
トランスポート・プロセスの一環としてデータファイルをコピーせずに、現在の場所でデータファイルを使用できる場合。ターゲット・データベースが異なるマシン上に存在する場合、ソース・システムとターゲット・システムの両方からそのストレージにアクセスできる必要があります。
DBUAがメンテナンス・ウィンドウ内に完了しない場合。
データ型の制限によりOracle StreamsまたはData Guard SQL Applyを使用できない場合。
Oracleデータベースに単純なスキーマが含まれる場合。
|
関連項目:
|
プラットフォーム移行とアップグレードを実行する場合、次のOracle機能を使用できます。
これらのデータベース・メンテナンス・タスクの実行方法は、次のことを考慮したうえで選択します。
メンテナンス操作を完了するのに必要な停止時間
停止時間の前に必要な設定時間および作業
一時的に必要となる追加リソースの量（ディスク領域やCPUなど）
メンテナンス操作を完了するのに許容される手順の複雑さ
表5-5に、プラットフォーム移行およびデータベース・アップグレードに使用できる方法と、操作ごとにその方法の使用が推奨される場合についてまとめます。
表5-5 プラットフォームおよびロケーション移行のオプション
| 操作 | 推奨される方法 | 代替の方法 |
|---|---|---|
|
同じエンディアン・プラットフォームへのプラットフォーム移行 |
プラットフォーム移行のためのフィジカル・スタンバイ・データベース |
|
|
異なるエンディアン・プラットフォームへのプラットフォーム移行 |
プラットフォーム移行のためのOracle Data Pump |
|
|
ロケーション移行のみ |
ロケーション移行のためのData Guard REDO Apply（フィジカル・スタンバイ・データベース） |
なし |
プラットフォーム移行に推奨されるアプローチは、フィジカル・スタンバイ・データベースを作成してスイッチオーバーを実行することです。フィジカル・スタンバイ・データベースでは、特定の異機種プラットフォームの組合せがサポートされます。最新のリストは、サポート・ノート413484.1を参照してください。Oracle Data Guardとフィジカル・スタンバイ・データベースは、Oracle RACローリング・アップグレードを使用してアップグレードできないシステムおよびクラスタのアップグレードを実行するための推奨ソリューションです。たとえば、Data Guardは、次の場合にも推奨されます。
システム制約のためにOracle RACローリング・アップグレードを使用してアップグレードできないシステム・アップグレード。
ASMへの移行、クラスタ化されていない環境からのOracle RACへの移行、64ビット・システムへの移行、同じエンディアン形式の異なるプラットフォームへの移行、同じプロセッサ・アーキテクチャの異なるプラットフォームへの移行、またはWindowsからLinuxへ、LinuxからWindowsへの移行。
32ビットOracleバイナリを持つプライマリ・データベースがRed Hat 32ビット上にあり、64ビットOracleバイナリを持つフィジカル・スタンバイ・データベースがRed Hat 64ビット上にある場合。このような構成は、Data Guardのロール移行（スイッチオーバーおよびフェイルオーバー）時に、サポート・ノート414043.1に記載されている追加の手順に従う必要があります。
Oracle Database 10gリリース2（10.2）以上で使用可能なトランスポータブル・データベースは、データベース全体を、同じエンディアン形式を持つ別のプラットフォームに移行する場合、ただし移行対象のプラットフォームの組合せで、クロスプラットフォームのフィジカル・スタンバイ・データベースが使用できない場合のみに推奨される方法です。
データベースを別のプラットフォームに移行する際にトランスポータブル・データベースが適切な方法であるかどうかを決定する場合、次の点を考慮してください。
トランスポータブル・データベースでは、同じエンディアン形式のプラットフォーム間でのデータベースの移行がサポートされます。
トランスポータブル・データベースを使用したプラットフォーム移行に必要な停止時間は、次の操作に要する時間によって決定されます。
ソース・データベースを読取り専用モードにする時間。
UNDOを含むすべてのデータファイルを変換する時間。詳細は、サポート・ノート415884.1を参照してください（http://metalink.oracle.com/）。
すべてのデータファイルをソース・システムからターゲット・システムに転送する時間。
停止時間の総量を大幅に短縮するには、ファイルを物理的に移動することなくターゲット・システムでデータファイルを利用可能にするストレージ・インフラストラクチャを使用します。
|
関連項目:
|
Oracle Streamsを使用すると、最小限の停止時間でデータベースをあるプラットフォームから別のプラットフォームに移行できます。その理由は、Oracle Streamsでは、異なるプラットフォームに基づいてプライマリ・データベースとそのレプリカが稼働する構成がサポートされるためです。
トランスポータブル・データベースで移行を迅速に実行できない状況において、アプリケーションでユーザー定義型を使用しておらず、移行を実行するために追加の管理作業が発生してもかまわない場合は、Oracle Streamsの使用を検討してください。
プラットフォーム移行の実行にOracle Streamsが適切な方法であるかどうかを決定する場合、次の点を考慮してください。
Oracle Streamsでは、ユーザー定義型がサポートされません（オブジェクト型、REF値、VARRAY、ネストした表など）。データ型の制限がある場合は、拡張データ型サポート（EDS）の実装を検討してください。
EDSでは、Streamsを使用して、ネイティブにサポートされない一部のデータ型を含む表に対する変更を、あるデータベースから別のデータベースにレプリケートします。EDSの概要は、次の場所で入手できるMAAホワイト・ペーパー『Extended Datatype Support: SQL Apply and Streams』を参照してください。
http://www.otn.oracle.com/goto/maa
EDSを使用して、ネイティブ・サポートされていないデータ型をサポートする例については、サポート・ノート556742.1を参照してください（http://metalink.oracle.com/）。
Oracle Streamsを使用してアップグレードを実行するには、ソース・データベースでOracle9iリリース2以上が稼働している必要があります。
Oracle Streams環境をセットアップして、維持するには、追加の管理上の労力が必要とされることがあります。
ソース・データベースとターゲット・データベースをパラレルに実行してターゲット・データベースに変更を伝播する場合、ソース・データベースにパフォーマンス上の影響が発生する可能性があります。
Oracle Streamsを使用したプラットフォーム移行に必要な停止時間は、キュー内の残りのトランザクションを適用する時間と、新規データベースにクライアントを再接続する時間によって決定されます。
|
関連項目: Oracle Streams概要および管理 |
Oracle Data Pumpテクノロジを使用すると、異なるプラットフォーム間や異なるデータベース・リリース間でデータおよびメタデータをあるデータベースから別のデータベースに高速に移動できます。
プラットフォーム移行にデータ・ポンプが適切な方法であるかどうかを決定する場合、次の点を考慮してください。
Oracle Data Pumpは、Oracle Database 10gリリース1（10.1）以上でのみ使用できます。
データ・ポンプを使用したプラットフォーム移行に必要な停止時間は、データベース全体のネットワーク・インポートを実行する時間によって決定されます。ネットワーク・インポートでは、ターゲット・システムとリモート・ソース・システム間のデータベース・リンクを使用してデータを取得し、そのデータをターゲット・システムに直接書き込みます（ダンプ・ファイルは使用しません）。
異なるエンディアン形式のプラットフォームにデータベースを移行する場合、ネットワーク・インポート時間が許容範囲内であれば、データ・ポンプを使用してください。
|
関連項目:
|
トランスポータブル表領域は、すべてのユーザー・データファイルを事前に作成および準備されたターゲット・データベースにトランスポートすることで、プラットフォーム移行を実行します。トランスポータブル表領域は、Oracle Streamsでサポートされないデータ型をデータベースで使用しており、ユーザー・スキーマが単純な場合に使用します。
プラットフォーム移行の実行にトランスポータブル表領域が適切な方法であるかどうかを決定する場合、次の点を考慮してください。
SYSTEM表領域は、トランスポータブル表領域で移動できません。ユーザー定義やクライアントに必要なオブジェクトを含むターゲット・データベースのSYSTEM表領域の内容は、手動で構築する必要があります。SYSTEM表領域の必要な内容を移動する場合、データ・ポンプを使用します。
トランスポータブル表領域を使用したプラットフォーム移行またはデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。
ソース・データベースの表領域を読取り専用モードにする時間。
トランスポータブル・メタデータのネットワーク・インポートを実行する時間。
すべてのデータファイルをソース・システムからターゲット・システムに転送する時間。
この時間を大幅に短縮するには、ファイルを物理的に移動することなくターゲット・システムでデータファイルを利用可能にするストレージ・インフラストラクチャを使用します。
RMANを使用してすべてのデータファイルを新規プラットフォームの形式に変換する時間
Oracle Data Pumpがメンテナンス・ウィンドウ内に完了せず、データ型の制限からOracle StreamsまたはData Guard SQL Applyを使用できない場合は、プラットフォームへの移行にトランスポータブル表領域を使用してください。
|
関連項目: トランスポータブル表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Data Guard REDO Applyを使用すると、一時スタンバイ・データベースをリモートの場所に設定してスイッチオーバー操作を実行することで、最小限の停止時間でデータベースの場所をリモート・サイトに変更できます。
Data Guard REDO Applyを使用したロケーション移行に必要な停止時間は、スイッチオーバー操作を実行する時間によって決定されます。
|
関連項目: REDO Applyとフィジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
Oracleデータベース・アップグレードは、すでに存在する以前のリリースのOracleデータベース・システムを現在のリリースのOracleデータベース・システムに変換するプロセスであり、場合によっては非常に長くかかります。
Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースによるデータベース・アップグレードを使用できず、データベースまたはアプリケーションのアップグレードの際の停止時間を0（ゼロ）にするか最小限に抑える必要がある場合、Oracle Streamsを構成してデータベース・アップグレードを実行することで、停止時間を0（ゼロ）または最小限に抑えることができます。これを行うには、次のデータベースでOracle Streams単一ソース・レプリケーション環境を使用します。
ソース・データベース: アップグレード対象である元のデータベース
宛先データベース: アップグレード・プロセス中に発生したソース・データベースに対する変更を適用プロセスで適用する場所となるソース・データベースのコピー。適用プロセスは、変更を、同じスキーマまたは異なるスキーマとオブジェクト構造に適用できます。
データベースをオンラインにしたままデータベース・アップグレードを実行する方法を、次の一般的な手順に示します。
空の宛先データベースを作成します。
元のデータベースがソース・データベースとなり、データベースのコピーがソースの変更を適用するための宛先データベースとなるOracle Streamsの単一ソース・レプリケーション環境を構成します。
宛先データベースでデータベース・アップグレードを実行します。この間、元のソース・データベースはオンラインで使用可能です。
Oracle Streamsを使用して、ソース・データベースで発生した変更を宛先データベースに適用します。
宛先データベースにソース・データベースの変更がすべて適用されたら、ソース・データベースをオフラインにし、宛先データベースをアプリケーションおよびユーザーから使用可能にします。
スキーマまたはオブジェクト構造が宛先データベースで異なる場合、Streams変換を組み入れて新規構造の変更を操作する必要があります。
|
関連項目: 『Oracle Streams概要および管理』の付録B「Oracle Streamsによるデータベースのオンライン・アップグレード」 |
アプリケーション・アップグレードには、データベース・アップグレードと、必要なアプリケーション・コードおよびスキーマの変更が含まれることがあります。データベースまたはアプリケーション・アップグレードを実行しつつ、停止時間を0（ゼロ）にするか最小限に抑える必要がある場合、Oracle Streamsを構成してデータベース・アップグレードを実行することで、停止時間を0（ゼロ）または最小限に抑えることができます（5.2.7項「オンライン・データベース・アップグレードでのOracle Streams」も参照）。
Oracle Streamsを使用してユーザーが作成したアプリケーションをアップグレードするプロセスには、インスタンス化後に、宛先データベースでスキーマ・オブジェクトを変更および作成する作業が含まれることがあります。ソース・データベースと宛先データベースの違いに対処するために、宛先データベースで、1つ以上の宣言的ルール・ベースの変換とDMLハンドラを使用して、変更を処理することができます。
一般に、宣言的ルール・ベースの変換の方が、DMLハンドラより使用が簡単です。このため、行LCRへの変更が必要な場合、DMLハンドラを使用する前に、まず宣言的ルール・ベースの変換の構成を試してください。1つ以上のLOB列を含む表の行LCRを変更する必要がある場合は、DMLハンドラとLOBアセンブリの使用をお薦めします。
データベース・メンテナンス操作を開始する前に、『Oracle Streams概要および管理』の付録C「Oracle Streamsを使用したオンラインでのデータベースのメンテナンス」の説明に従って、次の作業を行います。
宣言的ルール・ベースの変換またはDMLハンドラの準備をします。
宛先データベースで必要になる、宣言的ルール・ベースの変換とDMLハンドラを決定します。この決定は、アップグレードされるアプリケーションが必要とするスキーマ・オブジェクトに対する変更に左右されます。
データベース・メンテナンス操作の際、あらゆるDMLハンドラで必要になるPL/SQL手順を作成します。
1つ以上のLOB列を含む表の行LCRを変更する必要がある場合は、LOBアセンブリを使用します。
適用プロセスで、並行して適用される行LCRの依存性を検出するための追加情報が必要になる場合は、論理依存性を処理します（データベースでなくアプリケーションにより論理依存性が強制されるのかどうか、または、アプリケーション・アップグレードをサポートするためにスキーマ・オブジェクトが変更され、ソース・データベースと宛先データベースの違いに対処するために行LCRがDMLハンドラにより変更されているかどうか、など）。
|
関連項目: 『Oracle Streams概要および管理』の付録E「Oracle Streamsを使用したオンラインでのデータベースのメンテナンス」 |
データ・サーバーに関連する多くの計画済の停止には、データベース・オブジェクトの再編成が伴います。Oracle Databaseのオンライン再編成および再定義機能を使用すると、基礎となるデータが変更されている間でも、データ再編成を実行することができます。この機能により、ユーザーがデータベースに完全にアクセスできる状態でデータ再編成操作が可能になるため、可用性と管理性が拡張されます。
表の物理属性を変更してデータと表構造の両方を変換する機能は、Oracle8iから利用できました。データ再編成機能の詳細な説明は、『Oracle Database高可用性概要』を参照してください。
高可用性システムでは、問合せやDMLのパフォーマンスを向上するために、頻繁にアクセスされる大規模な表を定期的に再定義する必要があります。オンライン再編成および再定義機能を使用すると、管理者は、ユーザーによるデータベースへの完全なアクセスを維持しながら、表の物理属性を変更し、データと表構造の両方を変換できる柔軟性を手にできます。この機能により、ミッション・クリティカルな環境で重要となるデータ可用性、問合せパフォーマンス、レスポンス時間およびディスク領域使用率が向上します。また、オンライン再編成および再定義機能により、アプリケーション・アップグレード・プロセスは、より簡単、安全、迅速になります。
推奨ベスト・プラクティスは、DBMS_REDEFINITION PL/SQLパッケージを使用した表の再編成です。この方法を使用すると、表をオフラインにする必要のある従来の表の再定義方法と比較して可用性が大幅に向上するためです。DBMS_REDEFINITIONをコマンドラインから手動でコールするか、Oracle Enterprise Managerから自動でコールするかにかかわらず、再編成プロセス全体がユーザーによる表への完全なアクセスを維持したまま実行されるため、システムの可用性が確保されます。
図5-2は、Oracle Enterprise Managerのオブジェクトの再編成ウィザードを示しています。このウィザードは、SQL*PlusのコマンドラインでDBMS_REDEFINITIONパッケージをコールする方法のかわりとして使用できます。ウィザードでいくつかの質問に答えると、スクリプトが自動生成されて再編成が実行されます。
図5-2 Oracle Enterprise Managerを使用したデータベース・オブジェクトの再編成
DBMS_REDEFINITIONパッケージによる方法では、適切なすべての属性を含む仮表が作成されます。再編成プロセスは、表の現行バージョンと新規バージョンの間の列マッピングを記述するためのSTART_REDEF_TABLEプロシージャをコールすることにより開始されます。トリガー、制約、索引などのすべての依存オブジェクトが、COPY_TABLE_DEPENDENTSプロシージャの使用によって仮表に自動的にコピーされます。再編成中に元表に発生した変更は、SYNC_INTERIM_TABLEプロシージャがコールされて仮表に追加されます。FINISH_REDEF_TABLEプロシージャのコールにより再編成が完了すると、仮表の名前が変更されて主表になります。
Oracle Database 10g以上では、列、表およびデータファイルの名前と同様に、表領域の名前を変更できます。これまでは、表領域名を変更する唯一の方法は、その表領域を削除して再作成することでしたが、この方法では表領域の内容を削除して後で再構築する必要がありました。表領域名のオンライン変更機能では、ユーザー操作への割込みは発生しません。
ALTER TABLESPACE USERS RENAME TO new_tablespace_name;
Tablespace altered.
データの再編成を実行する場合は、次のことも考慮してください。
オンライン操作中の表における同時アクティビティを最小化します。
オンライン操作中は、実表でのユーザー・アクティビティを最小化することをお薦めします。オンライン操作中のデータベース・アクティビティによる影響は、表の10%未満とする必要があります。データベース管理者は、データベース・リソース・マネージャを使用してユーザーに十分なリソースを割り当てることで、データ再編成の影響を最小限に抑えることができます。
ピーク期間中にオンライン操作を実行することや、データのオンライン再編成中に大容量のデータ変更を伴うバッチ・ジョブを実行することは避けてください。
実際、オンライン操作中は、パラレルDML、ダイレクト・ロードおよびインポート/エクスポート機能は実行できません。
オンラインで索引を再構築する方法と、索引を削除してからオンラインで索引を再作成する方法の比較。
オンラインで索引を再構築する場合、操作中に新規索引用の追加ディスク領域が必要です。一方、索引を削除して再作成する場合、追加ディスク領域は必要ありません。
オンライン索引結合とオンライン索引再構築の比較。
オンライン索引結合は、インプレースのデータ再編成操作であるため、索引を再構築する場合のような追加ディスク領域は必要ありません。索引の再構築では、索引とソート領域の合計サイズに等しい一時ディスク領域が操作中に必要です。オンライン索引結合では、Bツリーの高さは減少しません。この場合、リーフ・ブロック数の削減が試行されるのみです。結合操作では、ユーザー用の領域は解放されませんが、索引スキャンのパフォーマンスは向上します。
索引を新規表領域に移動する必要がある場合は、オンライン索引再構築を使用してください。
ローカル索引およびグローバル索引のオンライン・メンテナンスの実行。
Oracle Database 11gでは、オンライン操作でローカル・パーティション索引とグローバル・パーティション索引の両方がサポートされます。表および索引がパーティション化されている場合、管理者は、一度に1つのパーティションを対象にこれらのオブジェクトのメンテナンスを実行することで、他のパーティションをオンラインのまま維持できます。
|
関連項目:
|
インスタンス、ノード、またはその他のコンポーネントを分離する必要のある計画済の停止では、サービスを再配置、無効化および有効化するOracle RACの機能を使用できます。再配置機能では、サービスを別のインスタンスに移行できます。サービスとインスタンスは、ハードウェアまたはシステム・ソフトウェアでの修復、変更、アップグレードの実行中に選択的に無効化し、メンテナンスの完了後に再有効化することが可能です。これにより、メンテナンスによる停止中はサービスまたはインスタンスが起動しないことが保証されます。サービスとインスタンスは、計画済の停止の開始時に無効化します。その後、メンテナンスによる停止の後に有効化します。
|
関連項目:
|
Oracle RACを使用している場合、ノードの開始時にOracleクラスタウェア・デーモンが自動的に起動します。1回以上のシステム再起動を必要とするメンテナンス、またはオペレーティング・システム以外のすべてのプロセスを停止する必要のあるメンテナンスを実行する場合、crsctlコマンドの使用によりOracleクラスタウェア・デーモンの起動を停止して無効化します。メンテナンスが完了したら、crsctlコマンドでOracleクラスタウェア・デーモンを有効化して起動します。
|
関連項目: crsctlコマンドの使用方法の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
脚注の説明
脚注1 データベースのロール管理の分野では、スイッチバックという用語も使用されることがあります。スイッチバックは、スイッチオーバー操作の後にスタンバイ・データベースを元のロールに戻す操作です。