Oracle Real Application Clusters環境でのOracleホーム次はじめに 3 ソフトウェア 3 Oracle Central Inventory

Oracle Real Application Clusters 環境での

Oracle ホーム

Oracle ホワイト・ペーパー

2008 年 1 月

目次はじめに .............................................................................................................. 3 ソフトウェア ...................................................................................................... 3

Oracle Central Inventory ........................................................................... 5 Oracle ホーム・インベントリ................................................................ 6 ローリング・アップグレード ............................................................... 7 Oracle ソフトウェアのクローニング.................................................... 8 非共有 Oracle ホーム .............................................................................. 8 長所 ........................................................................................................... 9 短所 ........................................................................................................... 9 欠点の詳細な検討 ................................................................................... 9

共有 Oracle ホーム............................................................................................ 11 共有 Oracle ベース ................................................................................ 12 共有ホーム内のバイナリ ..................................................................... 12 共有ホーム内の構成ファイル ............................................................. 12 共有ホーム内のログ・ファイル ......................................................... 13 共有ホームにおける Oracle Clusterware ............................................. 14 共有 Oracle ホームとしての OCFS2.................................................... 14 共有 Oracle ホームとしての NFS ........................................................ 15 長所 ......................................................................................................... 15 短所 ......................................................................................................... 15 欠点の詳細な検討 ................................................................................. 16

共有および非共有 Oracle ホームのメンテナンス ........................................ 16 Oracle Enterprise Manager の自動プロビジョニングの使用 ............. 16 ソフトウェアのインストール ............................................................. 16 サイレント・インストール ................................................................. 17 ソフトウェアのアップグレード ......................................................... 17 ワンオフパッチの適用 ......................................................................... 17 パッチセットの適用 ............................................................................. 18 ノードの追加 ......................................................................................... 19 ノードの削除 ......................................................................................... 19 ノード・リストのアップデート ......................................................... 19 インスタンスの配置 ............................................................................. 20

結論 .................................................................................................................... 21 付録 A：ORACLE CLUSTERWARE のアップグレード出力 ...................... 22 付録 B：参考資料............................................................................................. 23

Oracle RAC 11g： ........................................................................................ 23 Oracle RAC 10g Release 2：........................................................................ 23

Oracle Real Application Clusters 環境での Oracle ホーム

2

Oracle Corporation 発行「Oracle Homes in an Oracle Real Application Clusters Environment」の翻訳版です。


はじめに "共有すべきかせざるべきか"、それが問題だ。クラスタ環境内の各ノードからOracle Real Application Clusters（Oracle RAC）デー

タベースにアクセスするには、Oracleソフトウェアが必要であることは明白です。

明白でないのは、そのOracleソフトウェアを共有方式でインストールするべきか

（共有Oracleホーム）、それとも各ノードに個別にインストールするべきかという

点です。このホワイト・ペーパーでは、この 2 つの方法の長所と短所、またOPatch

とOracle Universal Installer（OUI）を使用して、ノードの追加や削除といったよく

ある操作を実行する方法について説明します。ここで説明する手順はすべて手動

によるものですが、これはOracle Enterprise Managerのライフ・サイクル管理（自

動プロビジョニング）1機能で完全に自動化される点に注意してください。また、

この説明はOracle RAC 10gとOracle RAC 11gを対象としています。詳細な資料につ

いては、参考資料の項を確認してください。

ソフトウェア

従来のクラスタ環境では、Oracle ソフトウェアにアクセスする必要があるサー

バーごとに、同ソフトウェアを個別にインストールしていました。しかし、たと

えば 16 ノードのクラスタ環境で、多数の同じソフトウェアのインストール、管理、

パッチ適用、バックアップを各ノードでおこなうのは、かなり面倒な作業になり

ます。そこで登場するのが、共有 Oracle ホームです。共有 Oracle ホームを使用す

れば、共有ファイル・システム上にソフトウェアを 1 度インストールするだけで

済みます。このようにソフトウェアのインストールと構成を 1 カ所でおこなうこ

とで、クラスタ環境におけるソフトウェアの管理と構成に伴う複雑さを軽減でき

ます。このホワイト・ペーパーでは、共有インストールと個別インストールの長

所と短所について詳細に説明していきます。

以下に、現在入手可能な共有ファイル・システムを示します。

クラスタ・ファイル・システムは大半の主要

なプラットフォーム上で利用できます。表 1 - 主要なオペレーティング・システムのクラスタ・ファイル・システム

クラスタ・ファイル・システムプロバイダプラットフォーム

CFS（Cluster File System） HP Tru64（TruCluster ソフトウェ

アの一部）

GPFS （ General Parallel File System）

IBM AIX、Linux、POWER

1 http://www.oracle.com/technology/products/oem/mgmt_solutions/provisioning.html （US OTN、英語）および

http://www.oracle.com/technology/global/jp/products/oem/mgmt_solutions/provisioning.html （OTN-Japan、日本

語）には、スクリーン・ウォッチ・デモ、自動実行デモ、データ・シートなどが多数用意されています。


3


http://h18000.www1.hp.com/products/quickspecs/12274_div/12274_div.html

http://www-03.ibm.com/servers/eserver/clusters/software/gpfs.html

http://www.oracle.com/technology/products/oem/mgmt_solutions/provisioning.html

http://www.oracle.com/technology/global/jp/products/oem/mgmt_solutions/provisioning.html

NFS（Network File system）認定済みの NFS デバイ

スサポートされている NFSサーバー/クライアント（大

半の OS）

OCFS2（Oracle Cluster File System 2）

Oracle Linux

OCFS（Oracle Cluster File System）Oracle Windows（Oracle RAC ソフト

ウェアの一部）

Matrix Server HP（Polyserve） Linux、Windows

GFS（Global File System） Red Hat Red Hat Enterprise Linux

StorEdge QFS Sun Microsystems Solaris

Veritas CFS（Cluster File System）

VxCFS Symantec Solaris、HP-UX、AIX、Linux

（ Storage Foundation for Windows も使用可能）

表 1 の注：

オラクルは、サードパーティ製のファイル・システムを直接認定してい

ません。認定はパートナー企業と協力しておこないます。正式なサポー

ト・ポリシーについては、MetalinkのCertifyの項を参照してください。Linux

の場合は、OTNのRAC Technologies Matrixが有効です。

上記の一覧はこのホワイト・ペーパーの発行時点で確認したものであり、

現時点で使用可能なクラスタ・ファイル・システムをすべて含むとはか

ぎりません。

クラスタ・ファイル・システムの認定プロセスは、共有データベース・

ファイルのサポートと共有 Oracle ホームのサポートで異なります。たと

えば、Linux 上では、OCFS1 はデータベース・ファイルのみをサポートし、

共有 Oracle ホームはサポートしません。共有 Oracle ホームをサポートす

るには、OCFS2 を使用する必要があります。

共有 Oracle ホームと非共有 Oracle ホームのどちらを選択するかについては、デー

タベースでも自動ストレージ管理（ASM）でもほとんど変わりません。個々の違

いについては、明確にしていきます。このホワイト・ペーパーでは、オラクルで

推奨されているとおり、データベースと ASM を個々の Oracle ホームにインストー

ルするものとします。Oracle Clusterware を共有ホーム方式でインストールするの

は、技術的には可能ですが推奨されていません。Oracle Clusterware ホームはシス

テム・レベルのソフトウェアで構成されているため、ノードの健全な動作に必要

である重要なソフトウェアが含まれています。このため、特殊なケースとして、

各ノードに個別にインストールする必要があります。Oracle ホームの種類に応じ

て共有方式と非共有方式を混在させることもできます。たとえば、テスト期間中

やセットアップの移行期間中では、共有 ASM ホーム/Database ホームと非共有

Oracle Clusterware ホームの組合せ、あるいは与えられた環境で意味をなす任意の

組合せによるセットアップが可能です。

Oracle Clusterware を共有ホーム方式でイン

ストールするのは、技術的には可能ですが推

奨されていません。

以下、このホワイト・ペーパーで役立ついくつかの用語を定義します。


4


http://www.oracle.com/technology/products/database/clustering/certify/tech_generic_linux_new.html

http://oss.oracle.com/projects/ocfs2/

http://www.polyserve.com/products.php

http://www.redhat.com/gfs/

http://www.sun.com/storagetek/management_software/data_management/qfs/

http://www.symantec.com/business/products/overview.jsp?pcid=2245&pvid=209_1

Oracle Central Inventory 共有Oracleホームと非共有Oracleホームのどちらを選択した場合でも、各ノードは、そ

れぞれ個別にOracle Central Inventoryのコピーを保有していなければなりません。Unix

システムではOracle Central Inventoryを複数の場所に配置できますが、Windowsでは 1

カ所にしか配置できません。$ORACLE_BASEが設定されている場合、Oracle Central

Inventoryのデフォルトの場所は、Oracle Database 10gでは$ORACLE_BASE/oraInventory、

Oracle Database 11gでは$ORACLE_BASE/../oraInventoryになります。$ORACLE_BASE

が設定されていない場合は、$HOME/oraInventoryがデフォルトの場所になります。サ

イレント・インストールの場合は、あとで詳しく説明しますが、

INVENTORY_LOCATION変数によってOracle Central Inventoryの場所を指定します。

Oracle Central InventoryはDBAの望む任意の場所に配置できます。場所を示す実際の値

は、oraInst.loc2 テキスト・ファイル内のinventory_loc変数に格納されます。Oracle

Central Inventoryの場所が簡単に見つかるように、このファイルのコピーが各Oracle

ホームの上位ディレクトリに置かれています。Windowsでは、レジストリ・キー

HKLM¥SOFTWARE¥Oracle¥inst_locがOracle Central Inventoryの場所を指します。

Oracle Central InventoryはそのノードだけにインストールされているOracleソフトウェ

アの情報を保持する小さなリポジトリです。このため、クラスタ/共有ファイル・シス

テムに配置してOracle RAC環境内のそのほかのノードと共有することはできません。

実際、インストール中はOracle Central Inventoryがロックされるため、同一ノードのOUI

セッションでさえ同時には実行できません。同時に実行しようとすると、次のような

エラーが表示されます。

Oracle Central Inventory は、クラスタ・メン

バーだけでなく、インストール済みのすべて

のソフトウェアに関する情報を保持していま

す。各ノードは、共有ホームを使用している

場合でも、それぞれ個別に Oracle Central Inventory のコピーを保有しています。

SEVERE: oracle.sysman.oii.oiit.OiitTargetLockNotAvailableException: OUI-10004: The target area /opt/orabase/oraInventory is being written to by another session. Please close all the other (write) sessions for accessing inventory.

Oracle Central Inventoryのロック・ファイルは<Central Inventory>/locks/writer.

lockです。このファイルはノードごとに個別に作成されます。シングル・インスタン

スのインストールでは、同時実行性を高めるために、1 ノード内でいくつかのDBAグ

ループごとに3 Oracle Central Inventoryを配置することも可能ですが、Oracle RAC環境

ではこうした方法は避けるようにしてください。というのは、Oracle Clusterwareを

Oracle Central Inventoryごとに用意する必要があるからです。各Oracle Central Inventory

への関連づけはあとで実行できますが、そうすると管理が複雑になります。したがっ

て、Oracle RAC環境では、Oracle Central Inventoryを各ノードにつき 1 つだけに制限す

るようにします。

以下に、Oracle Central Inventory ファイルの例を示します（ファイル名は

<inventory_loc>/oraInventory/ContentsXML/inventory.xml で、テキスト・エディタで表示

できます）。Clusterware Oracle ホームとその Oracle ホームに関連づけられたノード（"

クラスタ・メンバー"）が記述されています。 <HOME NAME="crs10g" LOC="/crs10g" TYPE="O" IDX="1" CRS="true">

<NODE_LIST> <NODE NAME="node1"/> <NODE NAME="node2"/> … … … … … …

2 Solaris、HP-UX、Tru64 では/var/opt/oracle、LinuxおよびAIXでは/etc 3 技術的には、DBAグループごとに個別にOracle Central Inventoryを配置して、複数のOUIセッションを、

それぞれ異なるOracle Central Inventoryに対して同時に実行することも可能です。その場合は、そのノード

上で複数の異なるソフトウェア・ホームを管理することになります（この方法は、Oracle RAC環境では避

けてください）。


5


<NODE NAME="node15"/> <NODE NAME="node16"/> </NODE_LIST>

</HOME>

こうしたノードの関連づけが、インストール済みのOracleホームごとに存在します。

Oracleホーム・インベントリ（次項参照）に格納されたクラスタ・メンバーは、

Oracle Central Inventory内に定義されているクラスタ・メンバーよりも優先されま

す。これはフォールバックの仕組みとして機能します。この関連づけ情報は、イ

ンストール時にOracle Universal Installer（OUI）によって、またパッチの適用時に

はOPatchによって、管理および参照されます。ただし、-localフラグを指定した

場合はその限りではありません（-localフラグは、Oracleホームに関連づけられ

たすべてのノードではなく、現在のノードのみにパッチを適用せよ、という意味

です）。このフラグについては後述します。インベントリXML（Extensible Markup

Language）ファイルは、OUIが所定の方法に従って変更するため、手動で編集し

てはいけません。詳細な例については、OUIドキュメントの参考資料または本ド

キュメントのメンテナンスの項を参照してください。

Oracle ホーム・インベントリ

前述のとおり、ノードごとに個別に管理される Oracle Central Inventory では、その

ノードにインストールされているすべてのOracleホームを指定します。Oracleホー

ムは、各 Oracle ホームの"inventory"サブディレクトリに置かれます。Oracle ホー

ム・インベントリ内の情報も、OUI と OPatch によって参照され、Oracle Central

Inventory 内の情報よりも優先されます。Oracle ホーム・インベントリ・ファイル

には有用な情報が保管されていますが、手動で編集してはいけません。たとえば、

次のような Oracle ホーム・インベントリ・ファイルがあります。

$ORACLE_HOME/inventory/ContentsXML/comps.xml

このファイルには、このOracleホームにインストールされている製品、バージョン、

パッチセット、個別パッチがすべて記録されています。このファイルの内容を表

示するには、opatch lsinventoryコマンドを使用します。次のようなOracle

ホーム・インベントリ・ファイルもあります。

$ORACLE_HOME/inventory/ContentsXML/oraclehomeproperties.xml

このファイルには、次のような情報が記述されています。 <ORACLEHOME_INFO>

<GUID>182700754#.1304811780</GUID> <HOME/> <ARU_PLATFORM_INFO>

<ARU_ID>46</ARU_ID> <ARU_ID_DESCRIPTION>Linux x86</ARU_ID_DESCRIPTION>

</ARU_PLATFORM_INFO> <CLUSTER_INFO>

<NODE_LIST> <NODE NAME="node1"/> <NODE NAME="node2"/> … … … … … …

<NODE NAME="node15"/> <NODE NAME="node16"/> </NODE_LIST>

</CLUSTER_INFO> </ORACLEHOME_INFO>


6


プラットフォーム id（46 Linux x86）とこの Oracle ホームに関連づけられた 16 の

ノードが指定されているのがわかります。ノード単位またはクラスタ・メンバー

間で 2 つのインベントリ（Oracle Central Inventory と Oracle ホーム・インベントリ）

の同期がとれなくなることがまれにあります。2 つのインベントリの同期状態を

チェックし更新する所定の方法については後述します。上記の例には

LOCAL_NODE タグが含まれていません。これは、このホームが共有 Oracle ホー

ムであることを意味します。プライベート Oracle ホームでは、クラスタ・メンバー

のリストに加えて、LOCAL_NODE タグにローカル・ノード名が指定されます。

Oracle Clusterware にノード名を問い合わせて確認できるようになるまでは、この

ノード名が OUI によって使用されます。

ローリング・アップグレード Oracle RAC環境では、ローリング・アップグレードと呼ばれる方法で、Oracleソフ

トウェアを更新できます。この方法4を使用すると、OPatch（ワンオフパッチの場

合）またはOUI（パッチセットの場合）によって各Oracleホームにパッチが順番に

適用されるため、クラスタ全体でデータベースが停止する状態が回避されます。

ローリング・アップグレードの詳細については標準のOracleドキュメント5に記載

されています。以下に、留意すべき点をいくつか挙げておきます。

ローリング・アップグレード方式でパッチを

適用することにより、クラスタ全体のデータ

ベースの停止を完全に回避できます。

共有 Oracle ホームを使用している場合、ローリング・アップグレードは

実行できません。共有 Oracle ホームでは、1 つのソフトウェアをすべての

ノードで共有しているためです。

Oracle Clusterwareのローリング・アップグレードは、非共有Oracleホーム

を使用している場合のみ実行可能です。

ASMは、Oracle RAC 11gの起動時に、パッチセットを含め、ローリング・

アップグレード方式でアップグレードできます。スタンバイ・データベースが用意されていない場合、Oracle RDBMS（10g

と 11g）または ASM（10g）のローリング・アップグレードは、一部のワ

ンオフパッチ適用に限ってサポートされており（Oracle RAC 環境の複数

のインスタンスを利用）、パッチセットまたはフル・メジャー・リリース

の適用はサポートされていません。ワンオフパッチをローリング・アッ

プグレード方式で適用できるかどうかは、そのパッチの README ファイ

ルを参照するか、次のどちらかのコマンドを実行してください。

Unix / Linux の場合：$ opatch query [patch location] | grep rolling

または

Windowsの場合：C:¥> opatch query [patch location] | findstr rolling

スタンバイ・データベースが用意されている場合は、Oracle RAC がインストール

されていなくても、小限の停止時間で、パッチセットおよびフル・リリース

（Oracle Database 10g または Oracle Database 11g）のローリング・アップグレードが

4 インスタンスの停止、パッチの適用、インスタンスの起動を実行し、次のノードに移ります。 5 『Oracle Databaseアップグレード・ガイド 11g』の第 1 章 6 Oracle Clusterwareローリング・アップデートについて、詳しくは『Oracle Clusterware インストレーショ

ン・ガイド 11g』（付録A）またはMetalink Note: 338706.1 を参照してください。 7 ASMのローリング・アップグレードについては、『Oracle Database 11g ストレージ管理者ガイド』を参照

してください。


7


可能です。詳しくは、Metalink Note 300479.1 および OTN の記事『SQL Apply ロー

リング・アップグレードのベスト・プラクティス』を参照してください。

Oracle ソフトウェアのクローニングクローニングにより導入時間を短縮できますインストールおよび導入時間を短縮するには、多くの場合、Oracleソフトウェアを

あるノードからローカル・ノードまたはリモート・ノード上の別の場所に単純に

コピーします。この方法は、クローニングと呼ばれる以下の手順によってサポー

トされています。クローニングについては、『Oracle Universal Installerおよび

OPatchユーザー・ガイド 11g』の 6 章に詳細な説明があります。初に、前述のと

おり、Oracleホームを別の場所に単純にコピーします（tar、zip、cpなどを使用）。

コピーの際、所有権とパーミッションはそのまま維持し、ログ・ファイルとその

ほかのホスト固有のディレクトリはコピーの対象外とします。次に、Perlスクリプ

ト<Oracle Home>/clone/bin/clone.plをコピー先で実行します。このスク

リプトは次の処理を実行します。

1. 新しい Oracle ホーム配下のファイルをすべて解析し、そのテキストに記

載されているパスをコピー先のパスに変更します。

2. 新しい Oracle ホームを Oracle Central Inventory に関連づけ、固有のインベ

ントリ・ファイルに必要なすべての修正をおこないます。

3. 新しい Oracle ホーム内のすべてのバイナリを再リンクします。

このスクリプトの処理が完了すると、クローニングされたOracleホームに対して、

新規にインストールした場合とまったく同じように、OPatchやOUIを使用した

パッチの適用やアップグレードといった操作を実行できるようになります。

clone.plスクリプトはかならず実行する必要があります。というのは、コピー

されたホームは古いOracleホームの各パスを参照したままになっており、インベン

トリにも正しく関連づけられていないからです。

非共有 Oracle ホーム

非共有Oracleホーム（別称プライベートOracleホーム）では、図 1 のように、クラ

スタ内の各ノードが、ローカル・ストレージ上に当該Oracleソフトウェア8・ツリー

の完全なコピーを保持しています。

図 1：非共有 Oracle ホーム

8 この場合、Oracleソフトウェアとは、Oracle RAC（Database）、ASM、またはOracle Clusterwareのいずれ

かを指します。


8


Oracle Real Application Clusters は通常、非共有ホーム方式でインストールされます。

非共有ホームでは、ソフトウェアをノードごとにコピーするため、必要なディス

ク領域とインストール所要時間が増えるものの、通常それに見合うだけの価値は

あります。たとえば、パッチを適用する場合、各ノードを個別に処理できるため、

パッチの適用中でもデータベースに対するサービスを提供し続けることができま

す（ローリング・アップグレード）。すべての Oracle ツールは、非共有 Oracle ホー

ムを完全にサポートしているため、管理も容易です。

非共有ホームでは、必要なディスク領域とイ

ンストール所要時間が増えるものの、通常そ

れに見合うだけの価値はあります。

以下に、非共有 Oracle ホームの長所と短所を要約します。

長所

特定のワンオフパッチをローリング方式で適用できます。OPatch による

パッチ適用中にサービスが停止するインスタンスはパッチ対象インスタ

ンスだけに限定されるため、データベースに対するサービス全体が中断

することはありません。ただし、この方式ですべてのパッチを適用でき

るわけではありません。詳しくは、前述のローリング・アップグレード

の項を参照してください。

非共有 Oracle ホームでは、停止時間なしの

ローリング・アップグレード方式でパッチを

適用できるため、ほとんどのケースで推奨さ

れます。

ソフトウェア・ツリーがシングル・ポイント障害になることはありませ

ん。ソフトウェア・ツリーが破損しても、その影響を受けるのは単一ノー

ドのみです。

短所

各ノードに対してパッチの管理と適用を実行するため、所要時間が長く

なります。すべてのノードにすべてのパッチが適用されたことを毎回確

認する必要があります。具体的には、opatch lsinventoryを使用して

すべてのノードに正しくパッチが適用されたことを確認します9。多くの

場合、md5sumなどのチェックサム・ユーティリティを使用してバイナ

リ・チェックサムを比較できますが、この方法は信頼できません。一部

のリンカーがバイナリにタイムスタンプを埋め込むため、これがチェッ

クサム不一致の原因になることがあるからです10。

構成ファイルとログ・ファイルがすべてのノードにまたがって分散配置

されるため、中央の一カ所で表示するのが難しくなります。

欠点の詳細な検討

複数の Oracle ホームを個別に管理する作業は確かに時間を要しますが、そうした

複雑な作業を軽減するためのツールがいくつか用意されています。

たとえば、OPatch はクラスタ対応であり、デフォルトで当該 Oracle ホームに関連

づけられたすべてのノードに、Oracle インベントリ内の指定に従って、パッチを

適用します（単一のノードに適用するには-local フラグを指定します）。

9 OPatchの新バージョンには、すべてのファイルが正しくコピーされたことを保証するパッチ確認

フェーズが追加されています。詳しくは、Metalink Note: 353150.1 を参照してください。 10 各種チェックサムの例については、Metalink Note: 443460.1 を参照してください。


9


このほかにも分散操作を容易にする外部ツールがあります。たとえば、Linuxでは、

クラスタ環境でシームレスなリモート・コマンド実行を可能にするpdsh（Parallel

Distributed Shell http://www.llnl.gov/linux/pdsh/）という便利なユーティリティが用

意されています。構成ファイル（/usr/local/etc/machines）にクラスタを構成するす

べてのメンバーが記載されているため、pdshは単一のコマンドをクラスタ全体ま

たは一部のノードに対して実行できます。

分散して存在するログ・ファイルやトレース・ファイル・ディレクトリに対する

アクセスの集中管理については、すべてのクラスタ・メンバーのトレースを保持

する共有ファイル・システムをセットアップすることで簡単に実現できます。

Oracle Database 10gでは、user_dump_destとbackground_dump_destに、共

有ファイル・システムの場所を設定します。Oracle Database 11gでは、次のコマン

ドを実行することで、Automatic Diagnostic Repository（ADR）を簡単に再配置でき

ます $ alter system set diagnostic_dest='/ocfs2' scope=both;

これにより、/ocfs2 の下に"diag"（およびその下位ディレクトリ）が自動的に作成

され、そこにすべてのトレース情報が出力されるようになります。


10


http://www.llnl.gov/linux/pdsh/

共有 Oracle ホーム

共有 Oracle ホームでは、図 2 に示したとおり、クラスタ内のすべてのノードがソ

フトウェアの同一コピーを使用します。

図 2：共有 Oracle ホーム

共有Oracleホームのインストールは簡単に実

現できます。Oracle ホームの場所を尋ねる

OUI（Oracle Universal Installer）のインタ

ビュー・ステージで共有マウント・ポイント

を指定するだけです。

これにより、各ノードではなく単一の場所で多数のデータベース操作を集中管理

できるため、データベースの構成と管理が簡素化されます。共有Oracleホームのイ

ンストールは簡単に実現できます。Oracleホームの場所を尋ねるOUI（Oracle

Universal Installer）のインタビュー・ステージで共有マウント・ポイントを指定す

るだけです。次の例では、/opt/oracleが、クラスタ内のすべてのノードのマウ

ント・ポイントになります。

# mount -t ocfs2 /dev/sdb5 /opt/oracle

マウント・ポイントは、認定NFSサーバーやOCFS211といった、サポートされてい

るクラスタ・ファイル・システム上に存在しなければいけません。

インストーラは、このマウント・ポイントが共有されている場所であることを自

動的に認識し、ソフトウェアのリモート・ノードへのコピー/伝播ステージを無視

します。すなわち、バイナリは共有ファイル・システム上に 1 回インストールさ

れるだけなので、とくに大規模なクラスタでのインストール時間が短縮されます。

共有 Oracle ホームのインストール中、ログには次のようなメッセージが出力され

ます。 INFO: FASTCOPYRAC: Oracle Home < /opt/oracle/db-10201> is shared. Instantiating RAC files

… … … … … … INFO: This is a shared oracle home or remote nodes are null. No copy required.

一方、典型的な非共有ホームのログ出力メッセージは次のようになります。 INFO: FASTCOPYRAC: Oracle Home < /opt/oracle/db-10201> is not shared. Instantiating RAC files

… … … … … … INFO: Updating files in Oracle home '/opt/oracle/db-10201' to remote nodes 'node2,node3,node4,…,node16'.

11 Linuxでは、OCFS1 は、共有データ・ファイルは配置できますが、ソフトウェア・ツリーは配置できま

せん。このため、OCFS1 で共有Oracleホームをホスティングすることはできません。OCFS2 は、ソフト

ウェアとデータの両方を配置できるOracle RAC完全対応のファイル・システムです。詳しくは、上記の表

1 を参照してください。


11


ソフトウェア・ファイルは非共有ホームの場合のみ、リモート・ノードに伝播さ

れます。共有ホームでは、共有クラスタ・ファイル・システムを使用してすべて

のノードでソフトウェア・ファイルを共有するため、コピーする必要はありませ

ん。特定の場所がノード間で共有されているかどうかを確認するには、次のよう

に CVU を使用します。

$ cluvfy comp cfs ?f /opt/oracle/db-10201 ?n node1,node2,…,node16

共有 Oracle ベース

Oracle ベース・ディレクトリを共有することもできますが、その場合は Oracle

Central Inventory の配置に注意が必要です。というのは、OUI は Oracle Central

Inventory の場所を$ORACLE_BASE からの相対ディレクトリとみなすことがある

からです。初期インストールの際、$ORACLE_BASE を共有ファイル・システム

上の場所に設定すると、すべてのノードが同じ Oracle Central Inventory にアクセス

することになる可能性があります。前述のとおり、Oracle Central Inventory はノー

ドごとに個別に用意する必要があります。特定の Oracle Central Inventory に複数の

ノードから書き込むことはできません。このため、Oracle ベースを共有の場所に

配置する場合は、Oracle Central Inventory の場所を、かならず各ノードで使用可能

なローカルのファイル・システムに対して（初期インストール時に）明確に定義

するようにしてください。

共有ホーム内のバイナリ

多くの場合、実行可能なバイナリは特定の Java バージョンや OS 共有ライブラリ

などのローカルのファイルに依存しています。こうしたバイナリをすべてのノー

ド間で共有した場合、ノードをアップグレードまたは変更したときに、何らかの

手を加えないとこれらの共有バイナリを実行できなくなる可能性があります。た

とえば、OS のアップグレードによって依存ライブラリが置換されたため、共有バ

イナリを再リンクする必要が生じたとします。このような再リンクを実行すると、

その共有バイナリは、依存ライブラリがアップグレードされていないほかのノー

ドでは実行できなくなります。このため、共有 Oracle ホームを使用する場合は、

OS の互換性が確保されるように注意する必要があります。

共有ホーム内の構成ファイル

すべての Oracle 構成ファイルには、マルチノード・サポートを有効化するための

クラスタ対応の構文か、または個別のディレクトリがあります。たとえば、init.ora

ファイルのデータベース初期化パラメータの構文は次のとおりです。

[*.|SID.]<parameter>=<value>

これは、各パラメータをデータベース全体またはインスタンスごとに設定できる

ことを意味します。したがって、単一のinit.oraファイルまたは推奨されたspfileで、

すべてのノードをサポートできます。構成ファイルにも同様の仕組みが存在しま

す。たとえば、listener.ora構成ファイルでは、次のようにノード名がデフォ

ルトのリスナー名の一部になっています。 LISTENER_NODE1 = (DESCRIPTION_LIST = … HOST=node1 … LISTENER_NODE2 = (DESCRIPTION_LIST = … HOST=node2 … LISTENER_NODE3 = (DESCRIPTION_LIST = … HOST=node3 …


12


このため、すべてのリスナーを単一のlistener.oraファイル内に定義できます。

共有ホーム内のログ・ファイル

Oracle Database 11gでは、init.oraパラメータdiagnostic_destを指定することで、

ADRによってすべてのトレースとログを 1 カ所に集中配置できます。ADRでは、

各ノードが個別のサブディレクトリを持つことで、共有と非共有の両方を完全に

サポートします。

Oracle Database 10gでは、デフォルトですべてのOracleディレクトリ、ログ・ファ

イル、トレース・ファイルに、SIDとノード名またはノード番号（Oracle Clusterware

ホームの場合）が埋め込まれているため、Oracleソフトウェア・ツリーをRAC対

応にするための追加設定は必要ありません。ただし、auditおよびcdumpディレ

クトリ配下のファイルは例外で、ファイル名の先頭にSIDが付いていません。した

がって、初期化パラメータaudit_file_destとcore_dump_destを使用して再

配置することが推奨されます。具体的には、各ノードを異なる場所に対応させ、

異なるノードの同名のファイルを使用した複数のプロセスが間違って同じファイ

ルを上書きしてしまわないようにします。

Oracle Database 10g では、デフォルトでデータベース・ログとトレース・ファイル

が次のディレクトリの配下に置かれます。

$ORACLE_BASE/admin/<dbname>

$ORACLE_BASE を共有ファイル・システム上に置くようにしていなければ、各

ノードは自身のローカルのファイル・システムに書き出します。この場合、共有

ログ・ディレクトリを設定するには、次のコマンドを実行します。 SQL> alter system set background_dump_dest='<shared-location>'12 scope=both;

共有ログ/トレース・リポジトリを 1 カ所で集

中管理すると、DBA はすべてのクラスタ・メ

ンバーのログやトレースを探すのに 1 つの場

所だけを見れば済むため、クラスタの管理に

おける負担が大幅に軽減されます。

共有ログ/トレース・リポジトリを 1 カ所で集中管理すると、DBA はすべてのクラ

スタ・メンバーのログやトレースを探すのに、各サーバーにログインしてログや

トレースを表示する代わりに 1 つの場所だけを見れば済むため、クラスタの管理

における負担が大幅に軽減されます。前述のとおり、非共有 Oracle ホームでロギ

ング用ディレクトリを 1 カ所にまとめる構成も可能です。また、共有ファイル・

システムが存在している場合は、ソフトウェアではなくログとトレースだけを共

有できます。

ただし、構成（ハードウェア、OS、クラスタ・ファイル・システムの選択）によっ

ては、多数のノードにまたがる大規模な障害が発生すると、多数のインスタンス

が同時に診断トレースをダンプしようとするため、クラスタ・ファイル・システ

ムに大きな負荷がかかり、トレースの出力に通常よりもかなり多くの時間を要す

ることがあります。そうした場合は、init.ora パラメータを使用するか、クラスタ・

ファイル・システムからローカル・ファイル・システムへのシンボリック・リン

クを定義して、トレース出力の負荷の一部をローカル・ファイル・システムに処

理させると効果的です。このように大きな書込み負荷が発生するとクラスタの可

用性が低下するケースがあることが確認されていますが、実際にそうした事態に

陥るかどうかは、使用するハードウェアとソフトウェアに大きく左右されます。

12 <shared-location>は、共有ファイル・システム上のディレクトリ名で読み替えてください。user_dump_destについても同じコマンドを実行します。


13


共有ホームにおける Oracle Clusterware

前述のとおり、Oracle Clusterware ソフトウェアを共有ファイル・システム上にイ

ンストールしてはいけません。それには次の 2 つの理由があります。

1. すべてのクラスタ・メンバーが Clusterware ソフトウェアの同一コピーを

使用すると、OPatchによるワンオフパッチの適用やOUIによるパッチセッ

トの適用をローリング・アップグレード方式で実行できません。この点に

ついては、Clusterware のすべてのパッチの README ファイルにも明記さ

れています。パッチの適用時にはクラスタ全体の停止をスケジューリング

する必要があります。

2. シングル・ポイント障害が発生します。たとえば、ユーザーがOracle

Clusterware共有ホーム配下の一部のバイナリを誤って削除してしまうと、

すべてのノードのClusterwareに即座に影響し、クラスタ全体が停止したり、

バイナリが見つからないために重大な誤動作が発生したりする可能性が

あります。もう 1 つの例は、広く利用されているNFSマウントされた共有

Oracleホームや共有Oracle Clusterwareホームにおける問題です。ネット

ワーク・ケーブルが誤って引き抜かれたため、ネットワーク障害が発生し

たとします。Oracle ClusterwareのすべてのソフトウェアとロジックはNFS

ファイル・システム上に存在するため、それがネットワーク障害によって

利用できなくなるとプロセスがハングし（大半のケースでは、kill -9に

よってプロセスを除去することさえできなくなります）、クラスタのリ

ソースはUNKNOWN状態となり、そのほかにもさまざまな問題が発生します。

共有 Oracle ホームとしての OCFS2

OCFS2 を共有 Oracle ホームとして使用する場合は、 OCFS2 の FAQ

（http://oss.oracle.com/）を確認してください。とくに、OCFS213が、現時点ではEM

エージェント 14とASM15が使用する書込み可能なmmapファイルをサポートして

いない点に注意してください。したがって、書込み可能なmmapファイルをサポー

トするファイル・システム（ext3 など）に、EMエージェントとASMを再配置する

必要があります。ただし、全ノードで共有する必要はありません。EMエージェン

トを停止し、次のコマンドを実行してください。

$ mv $ORACLE_HOME/dbs/hc_<SID>.dat /<mmap_filesystem>/hc_<SID>.dat $ ln ?s /<mmap_filesystem>/hc_<SID>.dat $ORACLE_HOME/dbs/hc_<SID>.dat

ASM ファイルについても同じ手順を実行します。

また、OCFS2 のタイムアウトは、OCFS2 クラスタ・モニターによってノードがリ

ブートされないように、FAQ や MetalinkNote 434255.1 と 395878.1 に従って注意深

く設定する必要があります。

13 OCFS2 1.4 では、書込みが可能なmmapファイルがサポートされる予定です。 14 EMエージェントのヘルスチェック・ファイルは$ORACLE_HOME/dbs/hc_$ORACLE_SID.datです。 15 ASMファイルは$ASM_HOME/dbs/ab_$ORACLE_SID.datです。


14


http://oss.oracle.com/projects/ocfs2/dist/documentation/ocfs2_faq.html

共有 Oracle ホームとしての NFS

Oracle RAC 11gでは、$ORACLE_HOME/bin/oradismをsetuid root16として実行す

ることにより、VKTMおよびLMSプロセスがリアルタイム優先順位（SCHED_RR）

で実行されるように構成されます。NFSマウントは、通常セキュリティ上の理由

で、エクスポートされたファイル・システム上でsetuid rootを禁止するように構成

されます。このようなNFSファイル・システム上でOracleホームを共有する場合は、

リリース・ノートに記載されている回避策に従って、setuid rootの実行を許可する

ようにNFSサーバーを再構成するか、以下に示すようにNFSのバイナリをローカル

のファイル・システム（すべてのノード上で同じパスに配置する必要があります）

またはsetuid rootがサポートされているほかのファイル・システム（OCFS2 など）

に再配置してください。

すべてのノード上で、root としてコピーを実行し、正しいパーミッションと所有

権が維持されていることを確認します。 # cp $ORACLE_HOME/bin/oradism /<setuid_filesystem>/oradism # chown root.oinstall /<setuid_filesystem>/oradism # chmod 4750 /<setuid_filesystem>/oradism

コピーできたら、いずれかのノードで次のコマンドを実行します。 $ rm $ORACLE_HOME/bin/oradism $ ln ?s /<setuid_filesystem>/oradism $ORACLE_HOME/bin/oradism

プロセスの実行優先順位を確認します（次の例は Linux の場合） $ ps -eo pid,class,rtprio,command | grep -e vktm -e lms 6092 RR 1 ora_vktm_orcl1 6114 RR 1 ora_lms0_orcl1 6118 RR 1 ora_lms1_orcl1

"RR"が SCHED_RR の意味であること、"rtprio"フィールドが 1 になっている（す

なわち、これらのプロセスはリアルタイム優先順位で実行されるように正しく設

定されている）ことに注意してください。どちらの回避策も実行しないと、優先

順位はタイムシェアリング（"TS"）、"rtprio"フィールドは Null になります。

以下に、共有 Oracle ホームの長所と短所を要約します。

長所

共有 Oracle ホームを使用すると、迅速にソフ

トウェアをインストールでき、環境の保守も

容易です。ただし、シングル・ポイント障害

が発生するため、ローリング・アップグレー

ドが実行できなくなります。

ソフトウェアが全ノードに伝播されないため、インストール時間が短縮

される

すべてのクラスタ・メンバーのすべてのノードのログ・ファイルおよび

トレース・ファイルに簡単にアクセスできる

ユーザーによる保守が簡単でエラーが減少し、ファイルは常に同期され

る

短所

すべてのノードが同じソフトウェア・ツリーを使用するため、パッチの

適用やソフトウェアの再リンクによる機能の有効化/無効化をローリン

グ・アップグレード方式で実行できなくなる

共有バイナリがローカルのライブラリに依存するため、ノード間で OS の

互換性を維持する必要がある（前述の共有ホーム内のバイナリの項参照） 16 こうしたバイナリの一覧については、Metalink Note: 461144.1 を参照してください。


15


シングル・ポイント障害を引き起こす：何らかの原因でソフトウェア・

ツリーが破損すると、クラスタ全体が影響を受けることになる

欠点の詳細な検討

単一の共有ホームはシングル・ポイント障害（SPOF）を引き起こします。ただし、

場合によっては、ファイル・システムの単純なリストアによってシステムがオン

ライン状態に復旧することがあります。一般に、ソフトウェア・ツリーの変更は

頻繁におこなわれるわけではないので、バックアップも容易で、ファイル・シス

テム障害が発生した場合でも迅速にリストアできます。ソフトウェア・ツリーは

RAID テクノロジで保護することが推奨されますが、RAID を実装しても人的エ

ラーやファイル・システム関連の破損を防ぐことはできない点に注意してくださ

い。共有 Oracle ホームで十分に定義されたバックアップ戦略を用意して RAID に

よる保護をおこなっても、機能停止を完全になくすことはできませんが、サービ

ス・レベルの目標値が維持できる程度に機能停止の発生頻度を小化することは

できます。サイトによっては、クラスタ全体をアップグレードするためにクラス

タ全体をダウンさせても、重大な影響を受けない可能性があります。

共有および非共有 Oracle ホームのメンテナンス

標準のドキュメントおよびパッチセット README に記載されている標準的な方

法に従ってください。以下に、共有または非共有 Oracle ホームでおこなわれる一

般的な操作と方法を示します。

Oracle Enterprise Manager の自動プロビジョニングの使用

Oracle Enterprise Managerの自動プロビジョニングは、デプロイメント・プロシー

ジャ17を使用して、この項で説明するすべての手順をスムーズに自動化します。

これらの手順は、再利用可能、拡張可能、ホット・プラグ可能な構成要素で、ノー

ドの追加/削除や、パッチの適用などの操作を完全に自動化できます。この方式の

利点は、ソフトウェア・スタック全体を考慮して拡張される点です。Clusterware

が見つからなければインストールされます。ASMやほかのコンポーネントについ

ても同様です。パッチ適用エンジンはMetalinkにオンライン接続されているため、

パッチの自動的な配信と適用が可能です。Oracle Enterprise Managerは、共有およ

び非共有Oracleホームを完全にサポートしています。詳細は概要とこの項に示した

リンクを参照してください。

Oracle Enterprise Manager の自動プロビジョ

ニングは、スケールアップおよびスケールダ

ウン操作のスムーズな自動化をはじめ、多く

の機能を備えています。

ソフトウェアのインストール

OUI を使用した Oracle ソフトウェアの標準的なインストール手順に従います。

Oracle Clusterware、Oracle Database、ASM について、共有および非共有の Oracle

ホームを完全にサポートしています。3 種類のホーム（Oracle Clusterware、ASM、

Oracle RDBMS）を完全にサポートするには、Oracle Clusterware のバージョンが常

に新である必要があります。Metalink Note: 337737.1 を参照してください。

17 http://www.oracle.com/technology/products/oem/pdf/grid-automation-deployment-procedures.pdf （英語）に記

載されている、スケールアップとスケールダウンの配置手順を使用します。


16


http://www.oracle.com/technology/products/oem/pdf/grid-automation-deployment-procedures.pdf

サイレント・インストール

通常、Oracle Universal Installer（OUI）はGUI（グラフィカル・ユーザー・インタ

フェース）モードで起動しますが、Oracleソフトウェアのインストールを自動化す

る場合やグラフィック端末を持っていない場合もあります。サイレント・インス

トールをもっとも簡単におこなうには、まず-recordフラグを指定してOUIを起

動し、現在のインストール・セッションから応答ファイルを作成します。次に、

-silentフラグおよび–response Fileフラグと作成した応答ファイルを指定し

て再度OUIを起動すると、サイレント・インストールを実行できます。セキュリ

ティ上の理由で、パスワードは応答ファイルには記録されないため、パスワード

が見つからないためにサイレント・インストールがエラーにならないように、応

答ファイルを手動で編集してパスワードを追加しておく必要があります（応答

ファイル内でs_superAdminSamePasswd & s_superAdminSamePasswdAgainと入力す

るとパスワードを追加する場所が見つかります）。インストール・ソースを変更

するには、 FROM_LOCATION 変数を調整する（通常は、

"../stage/products.xml"に設定する）必要があります。先頭に".."を指定し

ているのは、この変数にはインストール・メディア上のinstallサブディレクト

リに置かれているoraparams.iniファイルからの相対パスを設定する必要があ

るためです。別の有効なOUIフラグとして-forceがあります。このフラグを指定

すると、空ではないディレクトリ（たとえば、lost+foundサブディレクトリや

何らかの理由で上位ディレクトリに置く必要があるアプリケーション固有の

ファイルが存在するディレクトリ）に対して、サイレント・モードでインストー

ルできます。ただし、インストールでエラーが発生しリカバリを実行するときは、

このフラグを指定してはいけません。その場合は、インストール先フォルダから

不要なファイルを削除しておく必要があります。インストールの進行状況は標準

出力に書き出されます。また通常の方法でOUIを起動したときと同様、<Central

Inventory>/logsサブディレクトリと$ORACLE_HOME/db/cfgtoollogs/ouiディ

レクトリの両方にインストール・アクション・ログが記録されます。リモート・

ノードのログ・ファイルは、リモートのホスト名が末尾に付いた名前でローカル・

ノードにコピーされます。同一のOUI呼出しから出力されたすべてのファイルの

作成日付には、そのことがすぐにわかるように、（ローカル・ノードの）タイム

スタンプが使用されます。

あらゆるケースにおいて、サイレント・イン

ストールはOracle製品のインストールを迅速

化および自動化するもっとも優れた方法です

ソフトウェアのアップグレード

ソフトウェアをアップグレードする際には、アップグレードの種類に関係なく、

同じタイプの Oracle ホームでアップグレードする必要があります。アップグレー

ドの際に、非共有 Oracle ホームから共有 Oracle ホームに変更してはいけません。

ワンオフパッチの適用

OPatchユーティリティを使用した標準のパッチ適用方法に従います。Metalinkから

OPatchの新バージョン（10.2 bug placeholder: 4898608、10.1 bug placeholder:

2617419）をダウンロードしてください。共有ホームの場合は、パッチが正しく適

用されるように-localフラグを指定する必要があります（共有Oracleホームなの

で、いずれか 1 つのノードでパッチを適用すれば、すべてのノードが修正されま

す）。共有Oracleホームの場合は、ワンオフパッチをローリング・アップグレード

方式で適用することはできません。このため、OPatchを起動する場合はクラスタ


17


全体のデータベースの停止をスケジューリングしておく必要があります。

Clusterwareのパッチを適用する場合で、Oracle ClusterwareのバージョンがOracle

DatabaseまたはASMのバージョンと異なる場合には特別な注意が必要になります。

詳しくは、Metalink Note: 363254.1 を参照してください。

パッチセットの適用

OUI を使用した標準のパッチセット適用方法に従います。詳しくは、パッチセッ

トの README ファイルを参照してください。以下に、手順の概要を示します。

初に、すべてのノード上のOracle Clusterwareホームにパッチセットを適

用します18。非共有Oracle Clusterwareホームを使用している場合は、ロー

リング・アップグレード方式で実行できます。共有Oracle Clusterwareホー

ムを使用している場合は、パッチセットを適用する前にクラスタ全体を

停止する必要があります。

次に、すべてのノード上の Database Oracle ホームにパッチセットを適用

します。ASM ホームについても Oracle ホームと同様です。ただし、Oracle

ASM 11g より、ローリング・アップグレードが全面的にサポートされる

ようになりました。パッチセット（10.2.0.2 の上に 10.2.0.3 を適用する場

合）の Database 部分をローリング・アップグレード方式で適用すること

はできません（ただし、論理スタンバイ・データベースが配置されてい

る場合はその限りではありません）。したがって、パッチセットを適用す

る場合にはクラスタ全体のデータベースの停止をスケジューリングして

おく必要があります。非共有 Oracle ホームの場合は、次のようにしてク

ラスタ全体の停止時間を短縮できます。

o パッチ対象の Oracle ホームを使用している、ノード上のすべて

のデータベースのインスタンスを停止します。

o OUIを起動するときに-localフラグを指定することで、パッチ

セットのDatabase部分を、当該ローカル・ノードのみに適用しま

す（リモート・ノード上のインスタンスは影響を受けないため、

パッチ適用中も稼働し続けます）。

o 上記で選択したノードに対するパッチセットの適用が完了した

ら、すべてのリモート・ノード上で当該 Oracle ホームを使用し

ているすべてのデータベースの残りのインスタンスを停止しま

す。

o 新しいパッチが適用された Oracle ホームを使用してデータベー

スを（排他的に）起動し、パッチセット適用後の手順（パッチセッ

トの README ファイルに記載されているとおり、データベース

に対するカタログ・スクリプトの実行など）を実行します。

o 同時に、-enableRollingUpgradeフラグを指定してOUIを起

18 Oracle Clusterwareのローリング・アップグレードの出力例については、付録Aを参照してください。


18


動することにより、すべてのノード上にパッチセットを適用しま

す。クラスタ・ノード・ページで、すでにパッチ適用済みの 1 つ

のノードを除き、すべてのノードを選択します。

o カタログ・スクリプトが完了したら、残りのすべてのノードでイ

ンスタンスを起動します。カタログ・スクリプトの実行所要時間

は、クラスタのノード数に関係なく一定です。

ノードの追加

共有および非共有Oracleホームのどちらの場合も、標準のドキュメント（『Oracle

RAC 11g管理およびデプロイメント・ガイド』）に記載されている、クラスタへ

の標準的なノード追加手順に従います19。非共有Oracleホームで、ソフトウェア・

ツリーをコピーする必要があることがわかると、インストーラは自動的にコピー

を実行します。以下に、手順の概要を示します。

既存のクラスタ・メンバーの Oracle Clusterware ホームから

oui/bin/addNode.shを起動します。GUI OUIインタフェースが表示さ

れ、クラスタにノードを追加できるようになります。必要なら、Oracle

Clusterwareソフトウェアをリモート・ノードにコピーします。

次に、既存のクラスタ・メンバーの Database Oracle ホームから

oui/bin/addNode.shを起動します。GUI OUIインタフェースが表示さ

れ、ノードのDatabase部分の追加が実行されます。また、必要に応じて、

Oracle Databaseソフトウェアがリモート・ノードにコピーされます。

ノードの削除

共有および非共有Oracleホームのどちらの場合も、標準のドキュメント『Oracle

RAC 11g管理およびデプロイメント・ガイド』20に記載されている、クラスタへの

標準的なノード削除手順に従います。このMetalink Noteに、共有ホームの場合の

手順が記載されています。ノードを削除する際に誤って共有ソフトウェアを削除

してしまわないようにする必要があります。たとえば、共有ホームでは、Oracle

ホームを切り離す必要がありますが、非共有ホームでは安全にアンインストール

できます。

ノード・リストのアップデート

Oracle Central Inventoryで管理されているクラスタ・ノード・リストとOracleホー

ム・インベントリで管理されているクラスタ・ノード・リストの同期がとれてい

ない状態になることがあります。たとえば、あるノードが使用できないときにソ

フトウェアのインストールが実行されたり、早期の一時点からOracleホームのリス

トアをおこなったりした場合にこの状態になります。21このドキュメントの初

に説明したとおり、インベントリ・ファイルの内容をビジュアルで確認すること

によって、こうした同期のとれていない状態になっているかどうかを確認できま

Oracle Inventory XML ファイルを手動で編集

してはいけません。かならず適切な OUI コマ

ンドを使用してください。

19 Oracle RAC 10g Release 1（10.1.x）については、Metalink Note: 270512.1を参照してください。 20 Oracle RAC 10g Release 1（10.1.x）については、Metalink Note: 269320.1を参照してください。 21 インベントリ操作とリカバリ手順の詳細については、『Universal InstallerおよびOPatch ユーザーズ・ガ

イド 11g Release 1 (11.1)』の 2.6 項を参照してください。


19


https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=270512.1

https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=270512.1

す22。ノード・リストをアップデートするには、次のようにOUIの-updateNodeList

フラグを使用します（Oracle Inventoryファイルを手動で編集してはいけません）。

$ORACLE_HOME/oui/bin/<runInstaller or setup.exe> -updateNodeList -silent ORACLE_HOME=”<oracle home path>” “CLUSTER_NODES={node1,node2,node3}”

上のコマンドは、指定したノードで自動的に実行され、Oracle Central Inventoryと

Oracleホーム・インベントリ内の指定したOracleホームのクラスタ・メンバーに、

指定した 3 つのノード、node1、node2、node3 を設定します。共有Oracleホームを

使用している場合は、-cfsフラグを指定して、このホームが共有Oracleホームで

あることを示す必要があります。共有Oracleホームで、-localフラグを指定して

OUIを起動すると、ノード・リストのアップデート・コマンドが、そのローカル・

ノード上でのみ実行されます。ただし、-localフラグを指定すると、リモート・ノー

ド上のOracle Central Inventoryがアップデートされないため、このコマンドをすべ

てのノード上で実行しないと適切な結果が得られません。

ノード・リストのアップデート操作によって次のような正常終了メッセージが出

力されていることを確認してください。

'UpdateNodeList' was successful.

または、Oracle ホームの下の次の場所にある OUI ログ・ファイルの内容を確認し

てください。 $ORACLE_HOME/db/cfgtoollogs/oui

インスタンスの配置

Oracle Database 10gでは、Oracle Clusterwareが、クラスタ内のインスタンス（およ

びそのほかのサービスやユーザー定義のアプリケーション）の自動起動と自動停

止を実行します。その際、ノードとインスタンスの事前定義の関連づけが使用さ

れます。この関連づけはOCRファイルに格納されており、srvctlユーティリティ

を使用していつでも簡単に変更できます。たとえば、node12 がメンテナンスのた

めダウンしている場合は、そのインスタンスをnode4 に割り当てるといったことが

可能です。 $ srvctl modify instance -d racdb -i racdb12 -n node4

このコマンドは、インスタンス racdb12 を、デフォルトのノード（node12）ではな

く node4 に割り当てます。この変更は、Oracle Clusterware が次にこのインスタン

スを停止および起動したときに有効になります。racdb12 インスタンスに必要な

ファイル（init.ora、password ファイルなど）がターゲット・ノード上、つまり node4

に存在している必要があります。

インスタンスの配置は手動で変更できます。つまり、構成ファイル、具体的には

init.oraファイルの配置が適切にアップデートされていれば（上記の例では、

initracdb12.oraがnode4 のOracleホームに存在していれば）、任意のインスタンスを

任意のノード/Oracleホームから手動で起動できます。共有Oracleホームの場合は、

すべてのファイルが 1 カ所に存在するため、この操作は自動的におこなわれます。

非共有Oracleホームの場合は、オプションのインスタンス配置を簡単におこなうた

めに、DBAがこれらのファイルのシンボリック・リンクを作成するかコピーする

22 ノード・リストが現実のリストと一致していないと、すべてのクラスタ・メンバーではなく、そのリ

ストに指定されたノードだけにソフトウェアがインストールされるといった現象が起こります。


20


必要があります。たとえば、非共有Oracleホームで、DBCAが各Oracleホームにプ

ライベートなinit.oraを 1 つ作成したとき、複数のリモートOracleホームからそのイ

ンスタンスを起動するには、DBAがそのinit.oraファイルをそれらのOracleホームに

コピーする必要があります。SQL*Plusを使用してデータベースを起動する必要が

あるため、passwordファイルorapw<ORACLE_SID>もコピーする必要があります。

非共有 Oracle ホーム：ほとんどのケースで推奨されます。

共有 Oracle ホーム：サポートされていますが、シングル・ポイント障害が発生す

るため、ローリング・アップグレードが難しくなります。

結論 Oracle RAC 環境における Oracle ソフトウェアの管理は、共有 Oracle ホームと非共

有 Oracle ホームのどちらを選択しても簡単です。停止時間なしのローリング・アッ

プグレード方式でパッチを適用でき、シングル・ポイント障害やバイナリの依存

性の問題が排除されることから、ほとんどのケースで非共有 Oracle ホームが選択

されます。Oracle Enterprise Manager のライフ・サイクル管理（自動プロビジョニ

ング）機能を使用すると、このホワイト・ペーパーで説明したすべての手動操作

を完全に自動化するための作業が、大幅に簡素化されます。

非共有 Oracle ホーム：ほとんどのケースで推

奨されます。共有Oracleホーム：サポートされていますが、

シングル・ポイント障害が発生するため、ロー

リング・アップグレードが難しくなります。


21


付録 A：ORACLE CLUSTERWARE のアップグレード出力

Oracle Clusterware の 10.2.0.1 から 10.2.0.4 へのローリング・アップグレードの出力

例を以下に示します。

アップグレード前： [node1]$ crsctl query crs softwareversion CRS software version on node [node1] is [10.2.0.1.0] [node1]$ crsctl query crs activeversion CRS software version on node [node1] is [10.2.0.1.0]

どちらのバージョンも同様の出力になっています。

node1 のみ 10.2.0.4 にアップグレードされた後（残りのノードは 10.2.0.1 のまま）：

[node1]$ crsctl query crs softwareversion CRS software version on node [node1] is [10.2.0.4.0] [node1]$ crsctl query crs activeversion CRS software version on node [node1] is [10.2.0.1.0]

ソフトウェアのバージョンがアクティブなクラスタウェア・バージョンよりも高

くなっています。

すべてのノードが 10.2.0.4 にアップグレードされた後：

[node1]$ crsctl query crs softwareversion CRS software version on node [node1] is [10.2.0.4.0] [node1]$ crsctl query crs activeversion CRS software version on node [node1] is [10.2.0.4.0]

両方のバージョンが一致し、すべてのノードが新しいバージョンにアップグレー

ドされています。

後にアップグレードされるノードが新しいバージョンで Oracle Clusterware ス

タックを起動すると、クラスタウェア・ログに次のようなメッセージが出力され

ます。

<timestamp>: [CRSD][3086870208]0Daemon Version: 10.2.0.4.0 Active Version: 10.2.0.1.0 <timestamp>: [CRSD][3086870208]0Active Version is less than Software Version <timestamp>: [CRSD][90975152]0New Active Version:10.2.0.4.0 <timestamp>: [CRSD][90975152]0Active Version changed to 10.2.0.4.0

アップグレード中、Oracle Clusterware は、低いバージョンをクラスタウェアの"ア

クティブ"なプロトコルとして保持している点に注意してください。すべてのノー

ドに新バージョンがインストールされると、スタックが新バージョンに自動的に

切り替わり、アップグレード・プロセスが完了します。


22


付録 B：参考資料

以下のオラクルが提供する正式ドキュメントには、共有および非共有

Oracle ホームと、そのほかの関連事項について解説されています。

Oracle RAC 11g：

『Oracle Clusterwareインストレーション・ガイド 11gリリース 1 (11.1) for Linux』 ®

Oracle Clusterware 11g ソフトウェアのインストール（またはローリング・

アップグレード）

『Oracle Real Application Clustersインストレーション・ガイド 11gリリース 1 ®

(11.1) for Linux and UNIX』

Oracle RAC 11g ソフトウェアのインストール

『Oracle Clusterware管理およびデプロイメント・ガイド 11gリリース 11 (11.1)』 ®

共有および非共有 Oracle ホームにおける Oracle Clusterware ソフトウェア

のクローニング/削除

『Oracle Real Application Clusters管理およびデプロイメント・ガイド 11gリリー

ス 1 (11.1)』

®

共有および非共有 Oracle ホームにおけるノードの追加または削除

『Oracle Databaseアップグレード・ガイド 11gリリース 1 (11.1)』 ®

Oracle RAC 環境におけるローリング・アップグレードの説明

『Oracle Universal InstallerおよびOPatchユーザー・ガイド 11gリリース 1 (11.1)

for Windows and UNIX』

®

共有 Oracle ホームにおける Oracle Universal Installer と OPatch の使用方法

の概要（OPatch と OUI の-local フラグなど）。現在入手可能なもっとも

広範な Oracle ホームのドキュメントです。

Oracle RAC 10g Release 2：

『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersイン

ストレーション・ガイド 10gリリース 2 (10.2) for Linux』

®

共有 Oracle ホームの基本的な説明

『Oracle ClusterwareおよびOracle Real Application Clusters管理およびデプロイメ

ント・ガイド 10gリリース 2 (10.2)』

共有 Oracle ホームの管理とノードの追加/削除をおこなうために、共有

ホームと非共有ホーム環境で使用するコマンドの詳細な説明

『Oracle Databaseアップグレード・ガイド 10gリリース 2 (10.2)』 ®


23


Oracle RAC 環境におけるローリング・アップグレードの説明

『Oracle Universal InstallerおよびOPatchユーザー・ガイド 10gリリース 2 (10.2)

for Microsoft Windows and UNIX Systems』

®

共有 Oracle ホームにおける Oracle Universal Installer および OPatch の使用

方法の説明（OPatch の-local フラグなど）

Metalink Note: 338706.1 『Cluster Ready Services (CRS) rolling upgrade』

Metalink Note: 300479.1 『Rolling Upgrades with Logical Standby』

Metalink Note: 302806.1 『IBM General Parallel File System (GPFS) and Oracle

RAC on AIX 5L and IBM eServer pSeries』

OTN：『SQL Applyローリング・アップデートのベスト・プラクティス』

推奨ドキュメント OTN：『Oracle ClusterwareとOracle Real Application Clustersを使用して計画外

停止時の可用性を適化するためのベスト・プラクティス』

『ライフ・サイクルの管理（プロビジョニングと自動化）』


（US OTN、英語）

http://www.oracle.com/technology/global/jp/products/oem/mgmt_solutions/provisioning.html （OTN-Japan、日本語）

多数のスクリーン・ウォッチ・デモ、自動実行方デモ、データ・シートを提供

デプロイメント・プロシージャを使用したスケールアップとスケールダウン：

http://www.oracle.com/technology/products/oem/pdf/grid-automation-deployment-procedures.pdf（英語）


24







Oracle Real Application Clusters 環境での Oracle ホーム 2008 年 1 月著者：Saar Maoz 共著者：Roland Knapp、John McHugh、Philip Newlan、Juan Telez、Jonathan Creighton、Bharat Paliwal、Kirk McGowan、Barb Lundhild、Dan Norris Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口：電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 www.oracle.com Copyright © 2008, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容

は予告なく変更されることがあります。本文書は一切間違いがないことを保

証するものではなく、さらに、口述による明示または法律による黙示を問わ

ず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含

み、いかなる他の保証や条件も提供するものではありません。オラクル社は

本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的ま

たは間接的に確立される契約義務はないものとします。本文書はオラクル社

の書面による許可を前もって得ることなく、いかなる目的のためにも、電子

または印刷を含むいかなる形式や手段によっても再作成または送信すること

はできません。Oracle、JD Edwards、および PeopleSoft は、米国 Oracle Corporationおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会

社の商標です。

Documents

Oracle Real Application Clusters環境でのOracleホーム 次 はじめに 3 ソフトウェア 3 Oracle Central Inventory

Oracle Real Application Clusters環境でのOracleホーム次はじめに 3 ソフトウェア 3 Oracle Central Inventory