この章では、Oracle Universal Installer(OUI)を起動してクラスタ用Oracle Grid Infrastructureをインストールする前に完了する必要があり、クラスタにOracle Real Application Clusters(Oracle RAC)をインストールする場合に完了する必要があるシステム構成作業について説明します。
この章の内容は次のとおりです。
注意: 構成の変更を開始する前に、既存のデータベースのバックアップを必ず作成してください。 |
既存のOracleインストールがある場合は、バージョン番号、パッチおよびその他の構成情報を記録して、既存のインストール用のアップグレード手順を確認します。インストールを進める前に、アップグレードに関するOracleドキュメントを確認し、その後の処理を確認します。
Oracle Automatic Storage Management(Oracle ASM)11gリリース1(11.1)は、クラスタ内の個別のノードに対して、または複数のノードに対してまとめてローリング・アップグレードを行うことで、Oracle RACデータベースを停止することなくアップグレードできます。ただし、Oracle ASMを使用しているクラスタにスタンドアロン・データベースがある場合、アップグレードする前にそのスタンドアロン・データベースを停止する必要があります。Oracle ASM 10gからアップグレードする場合は、Oracle ASMクラスタ全体を停止してアップグレードを行う必要があります。
Oracle ASMがすでにインストールされている場合は、Oracleのアップグレードに関するドキュメントを確認します。今回のリリースでは、Oracle ASMホームの場所が変更されています。したがって、ストレージ管理を簡略化またはカスタマイズするためには、他の構成の変更も検討することが必要な場合があります。以前のリリースのOracle ASMホームがすでにある場合は、Oracle Clusterwareのアップグレードに使用する予定のユーザーが所有している必要があります。
オペレーティング・システムのローリング・アップグレード時に、そのオペレーティング・システムの両方のバージョンが、使用しているOracle Databaseリリースで保証されている場合は、異なるオペレーティング・システム・バイナリを使用できます。
注意: 異なるバージョンのオペレーティング・システムを使用できるのは、アップグレードの間の数時間だけです。Oracle Clusterwareでは、同じクラスタで異なる命令セット・アーキテクチャ(ISA)を使用するプロセッサを搭載するノードはサポートされていません。各ノードは、バイナリ・レベルでクラスタ内の他のノードとの互換性が必要です。たとえば、同じクラスタの1つのノードでIntel 64プロセッサを使用し、別のノードでIA-64(Itanium)プロセッサを使用することはできません。同じクラスタの1つのノードでIntel 64プロセッサを使用し、別のノードでAMD64プロセッサを使用することはできますが、これは、プロセッサが同じx86-64 ISAを使用し、同じバイナリ・バージョンのOracleソフトウェアを実行するためです。クラスタに異なる処理速度やサイズのCPUを搭載するノードをインストールできますが、ハードウェア構成が同じノードを使用することをお薦めします。 |
最新のソフトウェア更新情報や、アップグレードの前後、互換性、相互運用性に関するベスト・プラクティスについては、「Oracle Upgrade Companion」を参照してください。「Oracle Upgrade Companion」は、My Oracle SupportのNote 785351.1で参照できます。
Oracle Clusterware 11gリリース2では、インストールの最小要件を満たしていない場合はOracle Universal Installer(OUI)によって検知され、要件を満たしていないシステム構成手順を実行するために、修正スクリプトと呼ばれるシェル・スクリプト・プログラムが作成されます。OUIによって不完全な作業が検知されると、修正スクリプト(runfixup.sh
)が生成されます。「修正および再チェック」ボタンをクリックした後で、修正スクリプトを実行できます。
CVUで、インストールの前に修正スクリプトを生成することもできます。
関連項目: cluvfy コマンドの使用の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
修正スクリプトによって、次の作業が実行されます。
必要に応じて、インストールを正しく実行するために必要な値を次のカーネル・パラメータに設定します。
共有メモリのパラメータ
オープン・ファイル記述子とUDP送受信のパラメータ
Oracle Inventory(中央インベントリ)ディレクトリに権限を設定します。
インストール所有者、必要な場合はOracleインベントリ・ディレクトリ、オペレーティング・システム権限グループの、プライマリおよびセカンダリ・グループ・メンバーシップが再構成されます。
必要に応じて、シェル制限が必要な値に設定されます。
インストールに使用するユーザー・アカウントのために、クラスタ・メンバー・ノード間でSSHを構成している場合は、インストール前にクラスタ構成を確認し、インストールを開始する前にオペレーティング・システムの変更を行うための修正スクリプトを生成できます。
これを行うには、インストールを実行するユーザー・アカウントでログインし、runcluvfyコマンドがあるステージング領域に移動し、次のコマンド構文を使用します。nodeは、クラスタ・メンバーにするノードをカンマで区切ったリストです。
$ ./runcluvfy.sh stage -pre crsinst -n node -fixup -verbose
たとえば、node1とnode2の2ノードがあるクラスタを構成する場合は、次のコマンドを入力します。
$ ./runcluvfy.sh stage -pre crsinst -n node1,node2 -fixup -verbose
インストール中は、rootまたは他のユーザーとして、リモート端末上で作業を行う必要があります。リモート表示できるようにする必要があるユーザー・アカウントに対して、次の手順を実行します。
注意: 別のユーザー(oracle など)としてログインする場合は、そのユーザーでもこの手順を繰り返します。 |
リモート表示を可能にするには、次のいずれかの手順を実行します。
ソフトウェアをX Window SystemワークステーションまたはX端末からインストールする場合は、次の手順を実行します。
X端末(xterm
)などのローカル端末セッションを開始します。
ソフトウェアを別のシステムにインストールし、そのシステムをX11ディスプレイとして使用する場合は、次の構文を使用してコマンドを入力し、リモート・ホストがローカルのXサーバーでXアプリケーションを表示できるようにします。
# xhost + RemoteHost
RemoteHost
は完全修飾されたリモートのホスト名です。次に例を示します。
# xhost + somehost.example.com somehost.example.com being added to the access control list
ソフトウェアをローカル・システムにインストールしない場合は、ssh
,コマンドを使用してソフトウェアをインストールするシステムに接続します。
# ssh -Y RemoteHost
RemoteHost
は完全修飾されたリモートのホスト名です。-Y
フラグ(Yes)により、元のX11ディスプレイに対する完全なアクセス権がリモートのX11クライアントに付与されます。次に例を示します。
# ssh -Y somehost.example.com
root
ユーザーでログインしていない場合は、次のコマンドを入力してユーザーをroot
に切り替えます。
$ su - root password: #
Xサーバー・ソフトウェアがインストールされているPCまたはその他のシステムからソフトウェアをインストールする場合は、次の手順を実行します。
注意: この手順の詳細は、ご使用のXサーバーのマニュアルを参照してください。ご使用のXサーバー・ソフトウェアによっては、異なった順序で作業を実行する必要があります。 |
Xサーバー・ソフトウェアを起動します。
リモート・ホストがローカル・システムでXアプリケーションを表示できるようにXサーバー・ソフトウェアのセキュリティを設定します。
ソフトウェアをインストールするリモート・システムに、クラスタ用Oracle Grid Infrastructureソフトウェアの所有者(grid
、oracle
)として接続し、システムでX端末(xterm
)などの端末セッションを開始します。
リモート・システム上で別の端末セッションを開き、root
ユーザーとしてリモート・システムにログインします。プロンプトが表示されたら、root
としてスクリプトを実行できます。
root
としてログインし、次の手順を実行して、Oracle InventoryグループおよびOracle Grid Infrastructureのソフトウェア所有者を検索または作成します。
注意: Oracle Grid Infrastructureのインストールでは、Oracle Clusterwareおよび Oracle Automatic Storage Managementの両方がインストールされます。Oracle Clusterwareのインストール所有者とOracle Automatic Storage Managementのインストール所有者は、分離することができなくなりました。 |
システムに初めてOracleソフトウェアをインストールする場合は、OUIによってoraInst.loc
ファイルが作成されます。このファイルに、Oracle Inventoryグループのグループ名(デフォルトはoinstall
)およびOracle中央インベントリ・ディレクトリのパスが示されます。oraInst.loc
ファイルには、次のような内容が含まれます。
inventory_loc=central_inventory_location inst_group=group
この場合、central_inventory_location
はOracle中央インベントリの場所、group
は中央インベントリへの書込み権限を持つグループの名前です(OINSTALLグループ権限)。
既存のOracle中央インベントリがある場合は、必ずすべてのOracleソフトウェア・インストールで同じOracle Inventoryを使用し、インストールに使用するすべてのOracleソフトウェア・ユーザーがこのディレクトリへの書込み権限を持つようにします。
システムにOracle Inventoryがあるかどうかを確認するには、次のようにします。
# more /var/opt/oracle/oraInst.loc
oraInst.loc
ファイルが存在する場合、このコマンドの出力結果は、次のようになります。
inventory_loc=/u01/app/oracle/oraInventory inst_group=oinstall
前述の出力例の意味は次のとおりです。
inventory_loc
グループは、Oracle Inventoryの場所を示します。
inst_group
パラメータは、Oracle Inventoryグループの名前(この例では、oinstall
)を示します。
Oracle Inventoryグループ・メンバーにHP-UXのRTPRIO、MLOCKおよびRTSCHED権限が付与されていることを確認します。次に例を示します。
# /usr/bin/getprivgrp oinstall oinstall: RTPRIO MLOCK RTSCHED
グループにこれらの権限が付与されていない場合は、次の項の説明に従って権限を追加します。
oraInst.loc
ファイルが存在しない場合は、次の手順を実行します。
次のようなコマンドを入力して、Oracle Inventoryグループを作成します。
# /usr/sbin/groupadd -g 1000 oinstall
このコマンドによって、グループID番号が1000のoraInventoryグループoinstall
が作成されます。oraInventoryグループのメンバーには、Oracle中央インベントリ(oraInventory
)への書込み権限が付与されます。
oraInventoryグループが存在しない場合、デフォルトでは、クラスタ用Oracle Grid Infrastructureソフトウェアのインストール所有者のプライマリ・グループが、oraInventoryグループとして表示されます。使用するOracleソフトウェア・インストール所有者のすべてが、このグループをプライマリ・グループとして利用できることを確認します。
/etc/privgroup
ファイルが存在しない場合は、作成します。次のような行を追加して、Oracleインストール所有者にRTPRIO、MLOCKおよびRTSCHED権限を付与します。
oinstall RTPRIO MLOCK RTSCHED
/etc/privgroup
が存在する場合は、これらの権限をOracle Inventoryグループに追加します。次に例を示します。
# /usr/sbin/setprivgrp oinstall RTPRIO MLOCK RTSCHED
グループに権限が付与されていることを確認します。次に例を示します。
# /usr/bin/getprivgrp oinstall oinstall: RTPRIO MLOCK RTSCHED
他のすべてのクラスタ・ノードでこの手順を繰り返します。
次の場合は、Oracle Clusterwareのソフトウェア所有者を作成する必要があります。
Oracleソフトウェア所有者ユーザーが存在しない場合(たとえば、システムへOracleソフトウェアを初めてインストールする場合)。
Oracleソフトウェア所有者ユーザーは存在するが、他のグループに所属する別のオペレーティング・システム・ユーザーを使用して、Oracle Grid InfrastructureとOracle Databaseの管理権限を分離する場合。
Oracleドキュメントでは、Oracle Grid Infrastructureソフトウェアのインストールのみを所有するために作成されたユーザーをgrid
ユーザーと呼びます。すべてのOracleインストールを所有するために作成されたユーザー、またはOracle Databaseのインストールのみを所有するために作成されたユーザーをoracle
ユーザーと呼びます。
異なるOracle Databaseホームに対して複数のOracleソフトウェア所有者を使用する場合は、Oracle Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)ソフトウェアに対して別途ソフトウェア所有者を作成し、その所有者でOracle Grid Infrastructureをインストールすることをお薦めします。
Oracle DatabaseまたはOracle RACをインストールする予定がある場合は、Oracle Grid InfrastructureおよびOracle Databaseのインストール・ユーザーを別々に作成することをお薦めします。使用するインストール所有者が1つの場合は、管理タスクを実行するときに、$ORACLE_HOME
の値を管理対象のインスタンス(Oracle ASM、Oracle Grid Infrastructureホーム内、またはOracleホームのデータベース)に変更する必要があります。そのコマンド構文の例は次のようになります。ここで/u01/app/11.2.0/grid
はOracle Grid Infrastructureホームです。
$ ORACLE_HOME=/u01/app/11.2.0/grid; export ORACLE_HOME
sqlplus
、lsnrctl
、asmcmd
のいずれかのコマンドを使用してインスタンスを管理しようとしたときに、$ORACLE_HOMEが別のバイナリ・パスに設定されていると、エラーが発生します。データベース・ホームからsrvctlを起動する場合、$ORACLE_HOME
が設定されていないと、srvctl
は失敗します。ただし、Oracle Grid Infrastructureホームでsrvctl
を使用している場合は、$ORACLE_HOME
が無視されるため、Oracleホームのパスはsrvctl
コマンドに影響しません。$ORACLE_HOME
は必ず、管理対象のインスタンスに変更する必要があります。
異なるOracleソフトウェアのインストール環境に対して、ユーザーを別々に作成し、オペレーティング・システム権限グループを別々に作成するためにOracleソフトウェア所有者を別々に作成する場合は、そのユーザーのプライマリ・グループとしてOracle中央インベントリ・グループ(oraInventoryグループ)が必要なことに注意してください。このグループのメンバーはOracle中央インベントリ(oraInventory
)ディレクトリに対する書込み権限を所有します。また、様々なOracle Clusterwareリソース、OCRキー、DBAが書込み権限を必要とするOracle Clusterwareホーム内のディレクトリに対する権限やその他の必要な権限が付与されます。Oracleドキュメントのコード例では、このグループをoinstall
で表しています。
それぞれのOracleソフトウェア所有者は、同じ中央インベントリ・グループのメンバーであることが必要です。Oracleインストールに対して複数の中央インベントリを持たないことをお薦めします。あるOracleソフトウェア所有者が別の中央インベントリ・グループを持っている場合、その中央インベントリは破損することがあります。
oracle
やgrid
というOracleソフトウェア所有者ユーザーが存在するかどうかを確認するには、次のようなコマンドを入力します(この場合、oracle
の存在を確認します)。
# id oracle
ユーザーが存在する場合、このコマンドの出力結果は、次のようになります。
uid=501(oracle) gid=501(oinstall) groups=502(dba),503(oper)
既存ユーザーを使用するか、別のユーザーを作成するかを決定します。ユーザーIDおよびグループIDの番号は、クラスタ・メンバー・ノードにする各ノード上で同一である必要があります。
既存ユーザーを使用する場合は、ユーザーのプライマリ・グループがOracle Inventoryグループ(oinstall
)であることを確認します。Oracle Databaseインストールにこのユーザー・アカウントを使用する場合は、OracleアカウントがASM用のOSDBAグループ(メンバーがOracle ASM記憶域への書込みを許可されているグループ)として指定する予定のグループのメンバーであることを確認します。
Oracleソフトウェア所有者ユーザー(oracle
、grid
)が存在しない、または新しいOracleソフトウェア所有者ユーザーが必要な場合は作成します。既存のユーザー・アカウントを使用する場合は、各クラスタ・メンバー・ノードでユーザーIDおよびグループIDが一致していることを確認します。次の手順では、Oracleソフトウェア所有者の名前としてgrid
が、OSASMグループとしてdba
が使用されています。異なる管理権限に対して個別のシステム権限グループを作成するには、ユーザーを作成する前に、グループ作成を行います(第2.4.5項「役割区分によるオペレーティング・システム権限グループおよびユーザーの作成」)。
既存のシステム権限グループ(この例ではdba
)がある場合にグリッド・インストール所有者アカウントを作成し、グループのメンバーにOracle ASMインスタンスを管理するためのSYSASM
権限を付与する場合、次のようなコマンドを入力します。
# /usr/sbin/useradd -u 1100 -g oinstall -G dba grid
前述のコマンドの意味は、次のとおりです。
-u
オプションは、ユーザーIDを指定します。システムによって自動的にユーザーID番号を生成するようにできるため、このコマンド・フラグの使用は任意です。ただし、Oracle Grid Infrastructure用に作成するユーザーのユーザーID番号は、この後のインストール前の作業で必要になるため、記録しておく必要があります。また、クラスタのすべてのノードで、このユーザーのユーザーIDを一致させる必要があります。
-g
オプションは、プライマリ・グループを指定します。プライマリ・グループは、Oracle Inventoryグループである必要があります。たとえば、oinstall
です。
-Gオプションには、セカンダリ・グループ(この例ではdba
)を指定します。
セカンダリ・グループにはOSASMグループを含める必要があります。このグループのメンバーは、Oracle ASMインスタンスを管理するためのSYSASM
権限を付与されます。SYSASM
システム権限を付与するグループは1つのグループのみ指定でき、データベース管理者グループとは別のグループか、またはOSASMグループとOSDBAグループとして1つのグループを指定できます。この場合、グループのメンバーにはSYSASM
およびSYSDBA
権限が付与され、Oracle ASMインスタンスとOracle Databaseインスタンスの両方を管理するためのシステム権限が与えられます。コード例では、このグループはasmadmin
です。
このユーザーを、Oracle Grid InfrastructureとOracle Databaseインストールの両方の所有者として作成する場合は、ASM用のOSDBAグループをユーザーのセカンダリ・グループにする必要があります。コード例では、このグループ名はasmdba
です。ASM用のOSDBAグループのメンバーには、Oracle ASM記憶域へのアクセス権限が付与されます。Oracle ASM記憶域にアクセスするデータベースが複数になる場合は、ASM用のOSDBAグループを作成するか、または、ASM用のOSDBAグループとして、すべてのデータベースに対するOSDBAグループと同じグループを使用する必要があります。
usermod
コマンドを使用して、既存のユーザーID番号とグループを変更します。
次に例を示します。
# id oracle uid=501(oracle) gid=501(oracle) groups=501(oracle) # /usr/sbin/usermod -u 1001 -g 1000 -G 1000,1001 oracle # id oracle uid=1001(oracle) gid=1000(oinstall) groups=1000(oinstall),1001(oracle)
Oracle Grid Infrastructureを所有するユーザーのパスワードを設定します。次に例を示します。
# passwd grid
他のすべてのクラスタ・ノードでこの手順を繰り返します。
グリッド・インストール所有者のOracleベース・ディレクトリは、Oracle ASMおよびOracle Clusterwareに関する診断ログ、管理ログ、およびその他のログが格納される場所です。
Oracleソフトウェアのパスとして、Oracle Optimal Flexible Architecture(OFA)ガイドラインに準拠したOracle Clusterwareホームのパスを作成した場合は、Oracleベース・ディレクトリを作成する必要はありません。OUIでOFA準拠のパスが検出されると、そのパスにOracleベース・ディレクトリが作成されます。
OUIがパスをOracleソフトウェアのパスとして認識するには、u[00-99]/appという形式にし、oraInventory(oinstall
)グループのすべてのメンバーによる書込みを可能にする必要があります。OracleベースのOFAパスは、/u01/app/
user
です。user
は、ソフトウェアのインストール所有者の名前です。
クラスタ用Oracle Grid InfrastructureおよびOracle Databaseソフトウェア所有者が別の場合は特に、Oracle Grid InfrastructureのGridホームおよびOracleベース・ホームを手動で作成することをお薦めします。そうすることで、ログ・ファイルを分けることができます。
次に例を示します。
# mkdir -p /u01/app/11.2.0/grid # mkdir -p /u01/app/grid # mkdir -p /u01/app/oracle # chown grid:oinstall /u01/app/11.2.0/grid # chown grid:oinstall /u01/app/grid # chown oracle:oinstall /u01/app/oracle # chmod -R 775 /u01/ # chown -R grid:oinstall /u01
注意: クラスタ用Oracle Grid Infrastructureバイナリをクラスタ・ファイル・システムに配置することはサポートされていません。 |
役割区分によるOracle ASMの権限構成は、Oracle ASMインストール環境に対する管理アクセス権限と、他のOracleインストール環境に関連付けられた管理権限グループおよびユーザーとを分離するためのグループおよびユーザーを持つ構成です。管理アクセス権は、個々のオペレーティング・システム・グループのメンバーシップによって付与され、インストール権限は、Oracleをインストールするたびにインストール所有者を変えることで付与されます。
注意: この構成はオプションで、Oracleソフトウェアに対するユーザー・アクセスを、様々な管理者ユーザーの役割に応じて制限するための構成です。 |
必要な場合、記憶域およびデータベース層におけるすべてのシステム権限について、1つの管理ユーザーと1つのグループをオペレーティング・システム認証で使用できるように、オペレーティング・システム・ユーザー権限を割り当てることができます。
たとえば、すべてのOracleソフトウェアのインストール所有者をoracle
ユーザーとし、Oracle Clusterware、Oracle ASM、サーバー上のすべてのOracle Databaseに対するすべてのシステム権限、およびインストール所有者としてのすべての権限をメンバーに付与されるグループをoinstall
とすることができます。このグループは、Oracle Inventoryグループであることも必要です。
少なくとも2つのグループを使用することをお薦めします。メンバーに管理システム権限が付与されるシステム権限グループと、個別のインストール権限であるOINSTALL
権限が付与されるインストール所有者グループ(oraInventoryグループ)です。クラスタ検証ユーティリティなどのOracleツールでデフォルトを使用しやすくするため、すべてのシステム権限とoraInventoryへの書込み権限を1つのオペレーティング・システム・グループに付与する場合は、そのグループ名をoinstall
にする必要があります。
この項では、ユーザーおよびグループを作成し、役割区分を使用する方法の概要を説明します。これらのグループおよびユーザーを作成するには、root
でログインします。
個別のソフトウェア・インストール所有者を作成するすべてのインストールで、次のオペレーティング・システム・グループとユーザーを作成することをお薦めします。
各Oracleソフトウェア製品を所有する1つのソフトウェア所有者(通常、データベース・ソフトウェアの所有者ユーザーはoracle
、Oracle Grid Infrastructureの所有者ユーザーはgrid
)。
システムに初めてOracleソフトウェアをインストールするときは、少なくとも1つのソフトウェア所有者を作成する必要があります。このユーザーがOracle Grid InfrastructureソフトウェアのOracleバイナリを所有します。このユーザーをOracle DatabaseまたはOracle RACのバイナリ所有者にすることもできます。
Oracleソフトウェア所有者には、プライマリ・グループとしてOracle Inventoryグループが必要です。これによって、それぞれのOracleソフトウェア・インストールの所有者が中央インベントリ(oraInventory
)に書込みできるようになり、OCRとOracle Clusterwareリソース権限が適切に設定されます。データベース・ソフトウェア所有者には、セカンダリ・グループ(作成する場合)としてOSDBAグループとOSOPERグループが必要です。Oracleドキュメントでは、Oracleソフトウェア所有者ユーザーをoracle
ユーザーとします。
ソフトウェア所有者ユーザーを個別に作成し、各Oracleソフトウェア・インストールの所有者にすることをお薦めします。特に、システムに複数のデータベースをインストールする場合にお薦めします。
Oracleドキュメントでは、Oracle Grid Infrastructureバイナリを所有するために作成されたユーザーをgrid
ユーザーとします。このユーザーは、Oracle ClusterwareとOracle Automatic Storage Managementの両方のバイナリを所有します。
関連項目: OSDBAグループ、OSASMグループおよびOSOPERグループと、SYSDBA 権限、SYSASM 権限およびSYSOPER 権限の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』および『Oracle Database管理者ガイド』を参照してください。 |
Oracle Databaseをインストールするには、次のオペレーティング・システム・グループおよびユーザーが必要です。
システムに初めてOracle Databaseソフトウェアをインストールする場合は、このグループを作成する必要があります。このグループのオペレーティング・システム・ユーザー・アカウントには、データベースの管理権限(SYSDBA
権限)があります。Oracle ASMインスタンスに個別のOSDBA、OSOPERおよびOSASMグループを作成しない場合は、SYSOPER
およびSYSASM
権限を持つオペレーティング・システム・ユーザー・アカウントが、このグループのメンバーである必要があります。Oracleのコード例では、このグループにdba
という名前を使用します。OSASMグループとして個別のグループを指定しない場合は、定義するOSDBAグループもデフォルトでOSASMとなります。
デフォルト(dba
)以外のグループ名を指定するには、拡張インストール・タイプを選択してソフトウェアをインストールするか、またはこのグループのメンバーではないユーザーとしてOracle Universal Installer(OUI)を起動する必要があります。この場合、OUIによって、グループ名の指定を求めるプロンプトが表示されます。
以前は、OSDBAグループのメンバーにOracle ASMインスタンスのSYSASM
権限(ディスク・グループのマウントおよびマウント解除を含む)が付与されていました。Oracle Grid Infrastructure 11g リリース2 (11.2)の場合、別々のオペレーティング・システム・グループがOSDBAとOSASMグループとして指定されているときには、この権限が付与されません。同じグループが、OSDBAとOSASMの両方に使用されている場合は、権限がそのまま保持されます。
Oracle DatabaseのOSOPERグループ(通常、oper
)
これは、オプションのグループです。制限付きのデータベース管理権限(SYSOPER
権限)を別のグループのオペレーティング・システム・ユーザーに付与する場合に、このグループを作成します。OSDBAグループのメンバーには、デフォルトで、SYSOPER
権限によって付与されるすべての権限もあります。
OSOPERグループを使用してデフォルトのdba
グループより少ない権限でデータベース管理者グループを作成するには、拡張インストール・タイプを選択してソフトウェアをインストールするか、またはdba
グループのメンバーでないユーザーとしてOUIを起動する必要があります。この場合、OUIによって、グループ名の指定を求めるプロンプトが表示されます。このグループの標準的な名前はoper
です。
SYSASM
は、Oracle ASMストレージ管理権限をSYSDBAから切り離すことができる新しいシステム権限です。Oracle Automatic Storage Management 11gリリース2(11.2)では、OSASMグループに指定されたオペレーティング・システム・グループと、OSDBAグループに指定されたグループが同じ場合を除き、データベースOSDBAグループのメンバーにSYSASM
権限は付与されません。
Oracle ASMに対する権限のオペレーティング・システム認証グループとして、別のオペレーティング・システム・グループを選択します。OUIを起動する前に、Oracle ASM用に次のグループとユーザーを作成します。
Oracle Automatic Storage Managementグループ(通常、asmadmin
)
これは、必須のグループです。Oracle ASM管理者用とOracle Database管理者用の管理権限グループを別にする場合、このグループは個別のグループとして作成します。Oracleドキュメントでは、メンバーに権限が付与されたオペレーティング・システム・グループをOSASMグループと呼びます。コード例には、この権限を付与するために特別に作成された、asmadmin
と呼ばれるグループがあります。
システムに複数のデータベースがあり、複数のOSDBAグループがあるために、各データベースに別々のSYSDBA権限を付与できる場合は、OSASMグループを別途作成し、データベース・ユーザーとは別のユーザーにOracle Grid Infrastructureインストール(Oracle ClusterwareおよびOracle ASM)を所有させる必要があります。Oracle ASMでは、複数のデータベースがサポートされます。
OSASMグループのメンバーは、SQLを使用して、SYSASM
としてOracle ASMインスタンスに接続できます。このとき、オペレーティング・システム認証が使用されます。SYSASM
権限では、ディスク・グループのマウント、マウント解除およびその他の記憶域管理作業が許可されます。SYSASM
権限には、RDBMSインスタンスに対するアクセス権限はありません。
Oracle ASMデータベース管理者グループ(ASM用のOSDBA、通常はasmdba
)
Oracle ASMデータベース管理者グループ(ASM用のOSDBA)のメンバーには、Oracle ASMによって管理されるファイルへの読取りおよび書込みアクセス権限が付与されます。Oracle Grid Infrastructureインストール所有者とすべてのOracle Databaseソフトウェア所有者は、このグループのメンバーである必要があります。また、Oracle ASMによって管理されるファイルへアクセスするデータベースに対するOSDBAメンバーシップを持つすべてのユーザーが、ASM用のOSDBAグループのメンバーである必要があります。
Oracle ASMオペレータ・グループ(ASM用のOSOPER、通常はasmoper
)
これは、オプションのグループです。Oracle ASMインスタンスの起動と停止を含む、制限付きのOracle ASMインスタンスの管理権限(ASM用のSYSOPER権限)を別のグループのオペレーティング・システム・ユーザーに付与する場合に、このグループを作成します。OSASMグループのメンバーには、デフォルトで、ASM用のSYSOPER権限によって付与されるすべての権限もあります。
Oracle ASMオペレータ・グループを使用してデフォルトのasmadmin
グループより少ない権限でOracle ASM管理者グループを作成するには、拡張インストール・タイプを選択してソフトウェアをインストールする必要があります。この場合、OUIによって、グループ名の指定を求めるプロンプトが表示されます。コード例では、このグループはasmoper
です。
次の項では、必要なオペレーティング・システム・ユーザーおよびグループを作成する方法について説明します。
Oracle DatabaseをインストールしてOracle Grid Infrastructure環境で使用するときに、次のような場合はOSDBAグループを作成する必要があります。
OSDBAグループが存在しない場合(たとえば、システムへOracle Databaseソフトウェアを初めてインストールする場合)。
OSDBAグループが存在するが、新しいOracle Database環境では、データベースの管理権限を別のグループのオペレーティング・システム・ユーザーに付与する場合。
OSDBAグループが存在しない場合または新しいOSDBAグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはdba
を使用します。
# /usr/sbin/groupadd -g 1031 dba
OSOPERグループを作成する必要があるのは、制限付きのデータベース管理権限(SYSOPERオペレータ権限)を持つオペレーティング・システム・ユーザーのグループを指定する場合のみです。ほとんどの環境では、OSDBAグループを作成するのみで十分です。次の場合にOSOPERグループを使用するには、このグループを作成する必要があります。
OSOPERグループが存在しない場合(たとえば、システムへOracle Databaseソフトウェアを初めてインストールする場合)
OSOPERグループが存在するが、新しいOracle環境で、データベースのオペレータ権限を別のグループのオペレーティング・システム・ユーザーに付与する場合
新しいOSOPERグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはoper
を使用します。
# /usr/sbin/groupadd -g 1032 oper1
OSASMグループが存在しない場合または新しいOSASMグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmadmin
を使用します。
# /usr/sbin/groupadd -g 1020 asmadmin
データベース管理者などのオペレーティング・システム・ユーザーのグループを指定し、Oracle ASM記憶域の起動と停止を含む、Oracle ASM記憶域層に対する制限付きの管理権限を付与する場合には、ASM用のOSOPERグループを作成します。ほとんどの環境では、OSASMグループを作成するのみで十分です。インストールのインタビュー時に、そのグループをASM用のOSOPERグループとして指定します。
新しいASM用のOSOPERグループが必要な場合は、次の手順で作成します。次の手順では、既存のグループですでに使用されていないかぎり、グループ名にはasmoper
を使用します。
# /usr/sbin/groupadd -g 1022 asmoper
Oracle ASMインスタンスへのアクセスを可能にするには、ASM用のOSDBAグループを作成する必要があります。これは、OSASMとOSDBAが異なるグループである場合に必要です。
ASM用のOSDBAグループが存在しない場合、または新しいASM用のOSDBAグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmdba
を使用します。
# /usr/sbin/groupadd -g 1021 asmdba
次の場合は、Oracleソフトウェア所有者ユーザーを作成する必要があります。
Oracleソフトウェア所有者ユーザーが存在するが、新しいOracle Database環境では、別のオペレーティング・システム・ユーザー(異なるグループ・メンバーシップを持つ)を使用して、このグループにデータベースの管理権限を付与する場合。
Oracle Grid Infrastructureに対してgrid
などのOracleソフトウェア所有者が作成されており、Oracle Databaseソフトウェアに対してoracle
などの別のOracleソフトウェア所有者を作成する場合。
oracle
やgrid
というOracleソフトウェア所有者ユーザーが存在するかどうかを確認するには、次のようなコマンドを入力します(この場合、oracle
の存在を確認します)。
# id oracle
ユーザーが存在する場合、このコマンドの出力結果は、次のようになります。
uid=501(oracle) gid=501(oinstall) groups=502(dba),503(oper)
既存ユーザーを使用するか、別のユーザーを作成するかを決定します。既存のユーザーを使用する場合は、そのユーザーのプライマリ・グループがOracleインベントリ・グループであり、そのユーザーが適切なOSDBAグループおよびOSOPERグループのメンバーであることを確認します。詳細は、次の項も参照してください。
既存のユーザーを変更するには、第2.4.5.2.9項「既存のOracleソフトウェア所有者ユーザーの変更」を参照してください。
ユーザーを作成するには、次の項を参照してください。
Oracleソフトウェア所有者ユーザーが存在しない、または新しいOracleソフトウェア所有者ユーザーが必要な場合は、次の手順で作成します。既存のユーザーですでに使用されていないかぎり、ユーザー名にはoracle
を使用します。
# /usr/sbin/useradd -u 1101 -g oinstall -G dba,asmdba oracle
前述のコマンドの意味は、次のとおりです。
-uオプションは、ユーザーIDを指定します。システムによって自動的にユーザーID番号を生成するようにできるため、このコマンド・フラグの使用は任意です。ただし、oracle
ユーザーID番号は、この後のインストール前の作業で必要になるため、記録しておく必要がります。
-g
オプションは、プライマリ・グループを指定します。プライマリ・グループは、oinstall
などのOracle Inventoryグループである必要があります。
-G
オプションは、セカンダリ・グループを指定します。セカンダリ・グループには、OSDBAグループとASM用のOSDBAグループ、必要に応じてASM用のOSOPERグループを含める必要があります。たとえば、dba
、asmdba
、またはdba
、asmdba
、asmoper
などです。
oracle
ユーザーのパスワードを設定します。
# passwd oracle
Oracleソフトウェア所有者ユーザー、Oracle Inventory、OSDBAグループおよびOSOPERグループは、すべてのクラスタ・ノードに存在し、また同一である必要があります。同一のユーザーおよびグループを作成するには、ユーザーおよびグループを作成したノードで割り当てられたユーザーIDおよびグループIDを確認してから、他のクラスタ・ノードで同じ名前とIDを持つユーザーおよびグループを作成する必要があります。
注意: 次の手順は、ローカル・ユーザーおよびグループを使用している場合にのみ実行する必要があります。NISなどのディレクトリ・サービスで定義されたユーザーおよびグループを使用している場合、各クラスタ・ノードのユーザーおよびグループはすでに同一です。 |
grid
またはoracle
ユーザーのユーザーID(uid
)と、既存のOracleグループのグループID(gid
)を確認するには、次の手順を実行します。
次のコマンドを入力します(ここでは、oracle
ユーザーのユーザーIDを確認します)。
# id oracle
このコマンドの出力結果は、次のようになります。
uid=502(oracle) gid=501(oinstall) groups=502(dba),503(oper),506(asmdba)
表示された情報から、ユーザーのユーザーID(uid
)および所属するグループのグループID(gid
)を特定します。これらのID番号がクラスタの各ノードで同じであることを確認します。ユーザーのプライマリ・グループはgid
の後に表示されます。セカンダリ・グループはgroups
の後に表示されます。
他のクラスタ・ノードでユーザーおよびグループを作成するには、各ノードで次の手順を繰り返します。
次のクラスタ・ノードへroot
でログインします。
次のコマンドを入力して、oinstall
、asmadmin
およびasmdba
グループを作成します。また、必要に応じて、asmoper
、dba
およびoper
グループを作成します。-g
オプションを使用して、各グループに正しいgid
を指定します。
# /usr/sbin/groupadd -g 1000 oinstall # /usr/sbin/groupadd -g 1020 asmadmin # /usr/sbin/groupadd -g 1021 asmdba # /usr/sbin/groupadd -g 1022 asmoper # /usr/sbin/groupadd -g 1031 dba # /usr/sbin/groupadd -g 1032 oper
注意: グループがすでに存在している場合は、必要に応じてgroupmod コマンドを使用してそのグループを変更します。このノードのグループに、同じグループIDを使用できない場合、すべてのノードの/etc/group ファイルを表示し、どのノードでも使用できるグループIDを特定します。すべてのノードのグループIDが同じになるように、グループIDを変更する必要があります。 |
oracle
ユーザーまたはOracle Grid Infrastructure(grid
)ユーザーを作成するには、次のようなコマンドを入力します(この例では、oracle
ユーザーを作成します)。
# /usr/sbin/useradd -u 1101 -g oinstall -G asmdba,dba oracle
前述のコマンドの意味は、次のとおりです。
-u
オプションは、ユーザーIDを指定します。ユーザーIDは、前の項で特定したユーザーIDである必要があります。
-g
オプションは、プライマリ・グループを指定します。プライマリ・グループは、oinstall
などのOracle Inventoryグループである必要があります。
-G
オプションは、セカンダリ・グループを指定します。セカンダリ・グループには、OSASM、OSDBA、ASM用のOSDBA、OSOPERまたはASM用のOSOPERグループを含めることができます。次に例を示します。
グリッド・インストール所有者: OSASM(asmadmin
)。メンバーはSYSASM権限を付与されます。
SYSASMアクセス権限のないOracle Databaseインストール所有者: OSDBA(dba
)、ASM用のOSDBA(asmdba
)、ASM用のOSOPER(asmoper
)。
注意: ユーザーがすでに存在している場合は、必要に応じてusermod コマンドを使用して変更します。すべてのノードのユーザーに、同じユーザーIDを使用できない場合、すべてのノードの/etc/passwd ファイルを表示して、どのノードでも使用できるユーザーIDを特定します。すべてのノードのユーザーにそのIDを指定する必要があります。 |
# passwd oracle
「グリッド・インフラストラクチャ・ソフトウェア所有者ユーザー環境の構成」で説明するとおり、各ユーザーに対してユーザー環境の構成を行います。
Oracle Inventoryグループ(oinstall
)を作成し、OSDBA、OSASM、Oracle ASM用のOSDBAグループとして1つのグループ(dba
)を作成する方法の例を次に示します。また、適切なグループ・メンバーシップを持つ、Oracle Grid Infrastructureソフトウェア所有者(grid
)と1つのOracle Database所有者(oracle
)を作成する方法も示します。また、この例は、適切な権限を持つ、OFA構造に準拠したOracleベース・パスの構成方法も示しています。
# groupadd -g 1000 oinstall # groupadd -g 1031 dba # useradd -u 1100 -g oinstall -G dba grid # useradd -u 1101 -g oinstall -G dba oracle # mkdir -p /u01/app/11.2.0/grid # mkdir -p /u01/app/grid # chown -R grid:oinstall /u01 # mkdir /u01/app/oracle # chown oracle:oinstall /u01/app/oracle # chmod -R 775 /u01/
これらのコマンドを実行すると、次のグループとユーザーができます。
Oracle中央インベントリ・グループ、つまりoraInventoryグループ(oinstall
)。プライマリ・グループが中央インベントリ・グループであるメンバーは、oraInventory
ディレクトリに書込みできるOINSTALL権限を付与されます。
OSASM、OSDBA、ASM用のOSDBAおよびASM用のOSOPERグループとして使用される1つのシステム権限グループ(dba
)。メンバーは、Oracle Clusterware、Oracle ASM、Oracle Databaseを管理するためのSYSASMおよびSYSDBA権限を付与され、さらにOracle ASM記憶域にアクセスするためのSYSASMおよびASM用のOSOPER権限を付与されます。
クラスタ用Oracle Gridのインストール所有者(grid
)。プライマリ・グループはoraInventoryグループ、セカンダリ・グループはOSASMグループ。Oracleベース・ディレクトリは/u01/app/grid
。
Oracle Database所有者(oracle
)。プライマリ・グループはoraInventoryグループ、セカンダリ・グループはOSDBAグループ。Oracleベース・ディレクトリは/u01/app/oracle
。
インストール前は775権限でgrid:oinstall
が所有し、インストール中にroot.shスクリプトが実行された後はrootが所有する/u01/app
。この所有権と権限によって、OUIはパス/u01/app/oraInventory
にOracle Inventoryディレクトリを作成できるようになります。
インストール前はgrid:oinstall
が所有し、インストール中にroot.sh
スクリプトが実行された後はroot
が所有する/u01
。
775権限でgrid:oinstall
が所有する/u01/app/11.2.0/grid
。これらの権限はインストールに必要であり、インストール・プロセスで変更されます。
インストール前は775権限で、インストール後は755権限でgrid:oinstallが所有する/u01/app/grid
。
775権限でoracle:oinstall
が所有する/u01/app/oracle
。
Optimal Flexible Architecture(OFA)デプロイメントに準拠した、ロール割当てをしたグループおよびユーザーを作成する方法の例を、次に示します。
# groupadd -g 1000 oinstall # groupadd -g 1020 asmadmin # groupadd -g 1021 asmdba # groupadd -g 1031 dba1 # groupadd -g 1041 dba2 # groupadd -g 1022 asmoper # useradd -u 1100 -g oinstall -G asmadmin,asmdba grid # useradd -u 1101 -g oinstall -G dba1,asmdba oracle1 # useradd -u 1102 -g oinstall -G dba2,asmdba oracle2 # mkdir -p /u01/app/11.2.0/grid # mkdir -p /u01/app/grid # chown -R grid:oinstall /u01 # mkdir -p /u01/app/oracle1 # chown oracle1:oinstall /u01/app/oracle1 # mkdir -p /u01/app/oracle2 # chown oracle2:oinstall /u01/app/oracle2 # chmod -R 775 /u01
これらのコマンドを実行すると、次のグループとユーザーができます。
Oracle中央インベントリ・グループ、つまりoraInventoryグループ(oinstall
)。プライマリ・グループがこのグループであるメンバーは、oraInventory
ディレクトリへの書込み権限を付与されます。
個別のOSASMグループ(asmadmin
)。メンバーは、Oracle ClusterwareおよびOracle ASMを管理するためのSYSASM権限を付与されます。
個別のASM用OSDBAグループ(asmdba
)。メンバーは、grid
、oracle1
、oracle2
の他、Oracle ASMへのアクセス権を付与されたユーザーです。
個別のASM用のOSOPERグループ(asmoper
)。メンバーはOracle ASMインスタンスの起動と停止を含む、制限付きのOracle ASMの管理者権限が付与されたユーザーです。
クラスタ用Oracle Gridのインストールの所有者(grid
)。プライマリ・グループはoraInventoryグループ、セカンダリ・グループはOSASM(asmadmin
)、ASM用のOSDBAグループ(asmdba)。
2つの異なるデータベースに対する、2つの別々のOSDBAグループ(dba1
とdba2
)。それぞれのデータベースに対して、別々のSYSDBA権限を設定します。
Oracleデータベース・バイナリの所有権を分けるための、2つのOracle Databaseソフトウェア所有者(oracle1
とoracle2
)。プライマリ・グループはoraInventoryグループ。セカンダリ・グループは、それぞれのデータベースに対するOSDBAグループ(dba1
またはdba2
)と、ASM用のOSDBAグループ(asmdba
)。
grid:oinstall
が所有する、OFA準拠のマウント・ポイント/u01
(インストール前)。
775権限でgrid:oinstall
が所有する、グリッド・インストール所有者のOracleベース/u01/app/grid
。インストール・プロセスで755権限に変更されます。
775権限でoracle1:oinstall
が所有する、Oracleベース/u01/app/oracle1
。
775権限でoracle2:oinstall
が所有する、Oracleベース/u01/app/oracle2
。
775(drwxdrwxr-x
)権限でgrid:oinstall
が所有する、Gridホーム/u01/app/11.2.0/grid
。これらの権限はインストールに必要であり、インストール・プロセスでroot:oinstall
の755権限(drwxr-xr-x
)に変更されます。
/u01/app/oraInventory
。このパスの所有者はgrid:oinstall
のままで、他のOracleソフトウェア所有者による中央イベントリへの書込みを可能にします。
HP-UXプラットフォームで、Oracle Grid Infrastructure上にOracle DatabaseまたはOracle Real Application Clustersをインストールする場合は、次の手順を実行して外部ジョブ・ユーザー・アカウントを作成して、外部ジョブを実行可能な権限の低いユーザーを用意します。
rootユーザーでログインします。
権限を付与されていないユーザーextjob
を作成します。次に例を示します。
# useradd extjob
同じ命令セット・アーキテクチャのサーバーを選択します(同じクラスタ・スタックで32-bitおよび64-bitのOracleソフトウェア・バージョンを実行することはできません)。
各サーバーで、同じオペレーティング・システム・バイナリと同じプロセッサ・アーキテクチャが実行されていることを確認します。Oracle Grid InfrastructureインストールとOracle Real Application Clusters(Oracle RAC)では、同一クラスタ内でハードウェアが異なるサーバーを使用できます。
各システムは、次の最小ハードウェア要件を満たしている必要があります。
Cluster用Oracle Grid Infrastructureインストール用に2.5GB以上のRAM(Oracle RACをインストールする計画があるインストールを含む)。
1024 x 768以上のディスプレイ解像度。Oracle Universal Installer(OUI)を正しく表示するため。
次の表に示す使用可能なRAMの倍数と同等のスワップ領域
/tmp
ディレクトリに7GBの領域。
クラスタ用Oracle Grid Infrastructureホーム(Gridホーム)に、5.1GB以上の領域。ここには、Oracle ClusterwareおよびOracle Automatic Storage Management(ASM)のファイルとログ・ファイルが格納されます。
注意: Oracle DatabaseまたはOracle RACデータベースをクラスタ上にインストールする場合は、各サーバーの/dev/shm マウント領域が、サーバーのデータベースのシステム・グローバル領域(SGA)およびプログラム・グローバル領域(PGA)より大きいサイズである必要があることに注意してください。SGAおよびPGAの予想サイズをデータベース管理者に確認し、データベースをクラスタにインストールした後に/dev/shm を増やす必要がないようにしてください。 |
Oracle Databaseバイナリに8.2GB以上の領域(計画した場合)。
Enterprise Editionのデータ・ファイルに2.72GB以上
トレース・ファイル・アナライザおよびコレクタによって生成された診断収集用に、グリッド・インフラストラクチャ所有者のOracleベース・ディレクトリに最大10GBの追加の領域
Oracle Databaseのインストールでは、自動バックアップを構成する場合は、高速リカバリ領域用に追加の領域(ファイル・システムまたはOracle Automatic Storage Managementディスク・グループ)が必要です。
関連項目: 『Oracle Databaseストレージ管理者ガイド』 |
システムが各要件を満たしていることを確認するには、次の手順を実行します。
次のコマンドを入力して、物理RAMのサイズを確認します。
# /usr/contrib/bin/machinfo | grep -i Memory
システムに搭載されている物理RAMのサイズが要件のサイズより少ない場合、次の手順に進む前にメモリーを増設する必要があります。
次のコマンドを入力して、構成されたスワップ領域のサイズを確認します。
# /usr/sbin/swapinfo -a
注意:
|
次のコマンドを入力して、/tmp
ディレクトリで使用できるディスク領域の大きさを確認します。
# bdf /tmp
/tmp
ディレクトリで使用できるディスク領域が7GB未満の場合、次のいずれかの手順を完了します。
必要なディスク領域を確保するために、/tmp
ディレクトリから不要なファイルを削除します。
/tmp
ディレクトリを含むファイル・システムを拡張します。ファイル・システムの拡張については、必要に応じてシステム管理者に連絡してください。
次のコマンドを入力して、システムの空きディスク領域の大きさを確認します。
# bdf
次の表に、インストール・タイプごとにソフトウェア・ファイルのディスク領域要件の概要を示します。
インストール・タイプ | ソフトウェア・ファイルの要件(GB) |
---|---|
Enterprise Edition | 8.2 |
Standard Edition | 7.1 |
次の項で、クラスタ用Oracle Grid Infrastructure環境に必要なネットワーク・ハードウェアおよびインターネット・プロトコル(IP)・アドレスがあるかを確認します。
注意: Oracle RAC環境でサポートされるネットワーク・プロトコルおよびハードウェアの最新情報は、次のURLのMy Oracle Support Webサイトの「動作保証」ページを参照してください。
|
次にネットワーク構成要件を示します。
各ノードには2つ以上のネットワーク・アダプタまたはネットワーク・インタフェース・カード(NIC)が必要です。パブリック・ネットワーク・インタフェース用とプライベート・ネットワーク・インタフェース(インターコネクト)用のネットワーク・アダプタです。
冗長インターコネクトを使用すると、ボンディングなどのテクノロジを使用しなくても、複数のインタフェースを指定してクラスタ・プライベート・ネットワークに使用します。この機能は、Oracle Database 11g リリース2(11.2.0.2)以上で使用可能です。
複数のインタフェースを定義すると、Oracle Clusterwareは1つから4つの高可用性IP(HAIP)アドレスを作成します。Oracle RACおよびOracle ASMインスタンスはこれらのインタフェース・アドレスを使用して、ノード間でのロード・バランシングされた高可用性インタフェース通信を保証します。インストーラは、冗長インターコネクトを使用して、高可用性プライベート・ネットワークを提供します。
デフォルトでは、Oracle Grid InfrastructureソフトウェアはすべてのHAIPアドレスをプライベート・ネットワーク通信に使用して、プライベート・ネットワークとして指定した一連のインタフェースにロード・バランシングを提供します。プライベート・インターコネクト・インタフェースに障害が発生するか、または通信できなくなった場合、Oracle Clusterwareは、機能している残りのインタフェースのいずれかに対応するHAIPアドレスを透過的に移動します。
注意: プライベート・ネットワーク・インタフェースとして2つ以上のインタフェースを定義した場合は、Oracle Clusterwareが一度にアクティブにするインタフェースは1つのみであることに注意してください。ただし、そのアクティブなインタフェースに障害が発生した場合は、その障害が発生したインタフェースに構成されたHAIPアドレスを、一連の定義済プライベート・インタフェースのうちの予備インタフェースの1つに移します。 |
ノードをOracle Grid Infrastructure 11gリリース2(11.2.0.2)以上にアップグレードする場合、アップグレードされたシステムは既存のネットワーク分類を使用します。
複数のパブリック・インタフェースを構成するには、ご使用のプラットフォーム用のサード・パーティ・テクノロジを使用して、インストールを開始する前に複数のパブリック・インタフェースを集約する必要があります。その後、結合されたインタフェースの単一のインタフェース名をパブリック・インタフェースとして選択します。Oracle Grid Infrastructureのインストール中に、複数のパブリック・インタフェース名を指定しないことをお薦めします。集約テクノロジを使用せずに、2つのネットワーク・インタフェースをクラスタ内のパブリック・ネットワーク・インタフェースとして構成する場合、ノード上の1つのパブリック・インタフェースで発生した障害によって、もう1つのパブリック・インタフェースへの自動VIPフェイルオーバーが行われることはないことに注意してください。
プライベート・ネットワークに複数のインタフェースを使用するには、冗長インターコネクト機能を使用することをお薦めします。ただし、サード・パーティのテクノロジを使用しても、プライベート・ネットワークを冗長にすることは可能です。
OUIを使用してOracle Clusterwareをインストールする場合は、各ネットワークのネットワーク・アダプタに関連付けるパブリック・インタフェース名は、すべてのノードで同じである必要があり、ネットワーク・アダプタに関連付けるプライベート・インタフェース名もすべてのノードで同じである必要があります。この制限は、新しいクラスタを作成するため、または既存のクラスタにノードを追加するためにクローニングを使用する場合は適用されません。
たとえば、2ノードのクラスタのネットワーク・アダプタの場合、パブリック・インタフェースとしてnode1
ではlan0
、node2
ではlan1
というようには構成できません。パブリック・インタフェース名は同じである必要があります。このため、両方のノードでパブリックとしてlan0
を構成する必要があります。同じネットワークのアダプタでは、プライベート・インタフェースも同様に構成する必要があります。lan1
がnode1
のプライベート・インタフェースであれば、node2
のプライベート・インタフェースもlan1
である必要があります。
関連項目: クローニングを使用してノードを追加する方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
パブリック・ネットワークの場合、各ネットワーク・アダプタではTCP/IPがサポートされている必要があります。
プライベート・ネットワークでは、インタフェースにTCP/IPをサポートする高速ネットワーク・アダプタおよびスイッチ(最低要件: 1ギガビット・イーサネット)を使用して、ユーザー・データグラム・プロトコル(UDP)がサポートされている必要があります。
注意: UDPはOracle RAC用のデフォルトのインタフェース・プロトコルで、TCPはOracle Clusterware用のインターコネクト・プロトコルです。インターコネクト用のスイッチを使用する必要があります。専用のスイッチを使用することをお薦めします。インターコネクト用のトークン・リングまたはクロスオーバー・ケーブルはサポートされていません。 |
各ノードのインターコネクト用のプライベート・インタフェースは同じサブネット上にある必要があり、これらのサブネットはクラスタのすべてのノードに接続する必要があります。たとえば、プライベート・インタフェースのサブネット・マスクが255.255.255.0の場合、プライベート・ネットワークの範囲は192.168.0.0から192.168.0.255になり、プライベート・アドレスの範囲は192.168.0.[0-255]である必要があります。プライベート・インタフェースのサブネット・マスクが255.255.0.0の場合、プライベート・アドレスの範囲は192.168.[0-255].[0-255]になります。
冗長インターコネクトを使用するクラスタの場合、各プライベート・インタフェースは、異なるサブネット上にある必要があります。ただし、各クラスタ・メンバー・ノードは各プライベート・インターコネクト・サブネット上にインタフェースを持つ必要があり、これらのサブネットがクラスタのすべてのノードに接続されている必要があります。たとえば、プライベート・ネットワークがサブネット192.168.0および10.0.0上にある場合、各クラスタ・メンバー・ノードにはサブネット192.168.0および10.0.0に接続されているインタフェースが必要です。
プライベート・ネットワークでは、指定されているすべてのインターコネクト・インタフェースのエンドポイントがネットワークで確実にアクセス可能である必要があります。ノードはすべてのプライベート・ネットワーク・インタフェースに接続されている必要があります。ping
を使用して、インターコネクト・インタフェースが接続可能であるかどうかをテストできます。
インストールを開始する前に、各ノードにインタフェースが2つ以上構成されている必要があります。1つはプライベートIPアドレス用、もう1つはパブリックIPアドレス用です。
IPアドレスは、次のいずれかのオプションで構成できます。
Oracle Grid Naming Service(GNS)を使用した動的IPアドレスの割当て。このオプションを選択すると、ネットワーク管理者は静的IPアドレスを物理ホスト名に割り当て、動的に割り当てられたIPをOracle Clusterware管理VIPアドレスに割り当てます。この場合、VIPのIPアドレスはDHCPによって割り当てられ、クラスタ内でOracle Clusterwareの一部として構成されたマルチキャスト・ドメイン・ネーム・サーバーを使用して解決されます。GNSを使用する場合は、次のものが必要です。
クラスタのために、パブリック・ネットワーク上で実行されているDHCPサービス。
DHCP上の十分なアドレス。これにより、各ノードの仮想IPとしてIPアドレスを1つずつ、そしてクラスタの単一クライアント・アクセス名(SCAN)によって使用される、クラスタのIPアドレスを3つ提供します。
静的IPアドレスの割当て。このオプションを選択すると、ネットワーク管理者は固定IPアドレスをクラスタの各物理ホスト名とOracle Clusterware管理VIPのIPに割り当てます。また、各ノードには、ドメイン・ネーム・サーバー(DNS)に基づいた静的名前解決が使用されます。このオプションを選択する場合は、クラスタの変更時にネットワーク管理の更新を依頼する必要があります。
注意: すべてのサーバー・ノードのパブリック・ホスト名には、静的なホスト名を使用することをお薦めします。パブリックIPアドレスと仮想IPアドレスは、同じサブネット内にある必要があります。 DHCP割当てのネットワークは、デフォルトのネットワークでのみサポートされ、その後のネットワークではサポートされません。 |
グリッド・ネーミング・サービス(GNS)を有効にする場合、クラスタへの名前解決要求はGNSに委任され、GNSによってGNS仮想IPアドレスでリスニングされます。このアドレスは、インストール前にDNSドメインに定義します。DNSは、クラスタ名(クラスタに委任されたサブドメイン内のすべての名前)の解決要求がGNSに委任されるように構成する必要があります。要求がドメインに届くと、GNSによってその要求が処理され、要求された名前に対する適切なアドレスとともに応答が返されます。
GNSを使用するには、インストールの前に、サブドメインのDNS解決をクラスタに指示するDNS参照をDNS管理者が設定しておく必要があります。GNSを有効にする場合は、クラスタで必要な仮想IPアドレスをクラスタによって動的に割り当てるために、パブリック・ネットワーク上にDHCPサービスが必要です。
注意: 次の制限事項が、ご使用のシステムのベンダー構成に適用されます。
|
GNSを有効にしない場合、各ノードのパブリックIPアドレスおよび仮想IPアドレスは、静的アドレスであることが必要です。このアドレスは、インストール前に各ノードで構成しておく必要がありますが、現在未使用である必要があります。パブリックIPアドレスと仮想IPアドレスは、同じサブネット内にある必要があります。
インストールのインタビュー時にプライベートとして指定したインタフェース上のプライベート・サブネットに含まれるプライベートIPアドレスが、Oracle Clusterwareによって管理されます。
クラスタには、次のアドレスが構成されている必要があります。
次の特性がある、各ノードのパブリックIPアドレス:
静的IPアドレス
各ノードでインストール前に構成済で、インストール前にそのノードに対して解決可能
他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある
次の特性がある、各ノードの仮想IPアドレス:
静的IPアドレス
各ノードでインストール前に構成済だが、現在は使用されていない
他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある
次の特性がある、クラスタの単一クライアント・アクセス名(SCAN):
SCANとして指定された名前に3つの静的IPアドレスが関連付けられ、そのすべてのアドレスがランダムな順序でDNSによってリクエスタに返されるように、インストール前にドメイン・ネーム・サーバー(DNS)上で静的IPアドレスが3つ構成されている
現在使用されていないアドレスに解決されるためにDNSでインストール前に構成済
数値以外で始まる名前が指定されている
他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある
RFC 952標準に準拠し、英数字とハイフン("-")は使用できるが、アンダースコア("_")は使用できない
次の特性がある、各ノードのプライベートIPアドレス:
静的IPアドレス
インストール前に構成済だが、独自のサブネットを持つ別のプライベート・ネットワーク上では、他のクラスタ・メンバー・ノード以外が解決することはできない
SCANは、クラスタへのサービス・アクセスをクライアントに提供するために使用される名前です。SCANは、特定のノードではなくクラスタ全体に関連付けされているため、クライアントの再構成を必要とせずに、クラスタでノードを追加または削除することを可能にします。また、データベースに場所の独立性がもたらされるため、クライアント構成は特定のデータベースがどのノードで実行されているかに依存しません。クライアントは引き続き、以前のリリースと同じ方法でクラスタにアクセスできますが、クラスタにアクセスするクライアントではSCANの使用をお薦めします。
注意: 標準インストールでは、SCANはクラスタ名にもなります。拡張インストールでは、SCANおよびクラスタ名はインストール時に別々のフィールドに入力されます。SCANおよびクラスタ名は、どちらも、長さが1文字以上15文字以下の英数字である必要があり、先頭に数字を使用することはできませんが、ハイフン(-)を含むことができます。 |
nslookupコマンドを使用して、DNSによってSCANが正常にアドレスに関連付けられていることを確認できます。次に例を示します。
root@node1]$ nslookup mycluster-scan Server: dns.example.com Address: 192.0.2.001 Name: mycluster-scan.example.com Address: 192.0.2.201 Name: mycluster-scan.example.com Address: 192.0.2.202 Name: mycluster-scan.example.com Address: 192.0.2.203
インストール後、クライアントがクラスタにリクエストを送信すると、Oracle Clusterware SCANリスナーは、クライアント・リクエストをクラスタのサーバーにリダイレクトします。
注意: SCAN VIPアドレスの構成は、hostsファイルで行わないことを強くお薦めします。SCAN VIPにはDNS解決を使用します。SCANの解決にhostsファイルを使用すると、1つのIPアドレスへの解決しかできず、SCANアドレスは1つのみになってしまいます。サポートされているのは、DNSまたはホスト・ファイルでのSCANの構成のみです。Network Information Service(NIS)でのSCANの構成はサポートされていません。 |
ブロードキャスト通信(ARPおよびUDP)は、Oracle Grid Infrastructureリリース2パッチセット1(11.2.0.2)以上で使用するために構成されたすべてのパブリックおよびプライベート・インタフェース全体で適切に動作する必要があります。
ブロードキャストは、パブリックまたはプライベート・インタフェースによって使用されるものとして構成されたVLAN全体で動作する必要があります。
Oracle Grid Infrastructureリリース2(11.2)では、各クラスタ・メンバー・ノードで、Oracle mDNSデーモンがすべてのインタフェースでマルチキャスティングを使用して、クラスタの他のノードと通信します。
Oracle Grid Infrastructureリリース2パッチセット1(11.2.0.2)以上では、マルチキャスティングはプライベート・インターコネクトで必須です。このため、少なくとも次のクラスタでマルチキャスティングを有効にする必要があります。
プライベート・インターコネクトとして定義されたブロードキャスト・ドメイン全体
IPアドレス・サブネット範囲224.0.0.0/24および230.0.1.0/24
ルーター全体でマルチキャスト通信を有効にする必要はありません。
GNSを使用する場合、Oracle Grid Infrastructureのインストール前に、GNSが提供するサブドメイン(クラスタ・メンバー・ノード)に対する名前解決要求がGNSへ送信されるよう、ドメイン・ネーム・サーバー(DNS)を構成しておく必要があります。次にドメイン委任に必要な手順の概要を示します。実際の手順はこの例と異なる場合があります。
委任を使用してGNS名前解決要求を送信するようにDNSを構成します。
DNSでGNS仮想IPアドレスのエントリを作成します。アドレスの書式はgns-server.CLUSTERNAME.DOMAINNAMEです。たとえば、クラスタ名がmycluster
で、ドメイン名がexample.com
で、IPアドレスが192.0.2.1の場合、次のようなエントリを作成します。
mycluster-gns.example.com A 192.0.2.1
指定したアドレスは、ルーティング可能である必要があります。
GNSでGNSサブドメインへのアドレスを解決できるように、GNS仮想IPアドレスへのGNSサブドメインの転送を設定します。これには、委任されたドメインに対して次のようなBIND構成エントリを作成します。cluster01.example.com
は、委任するサブドメインです。
cluster01.example.com NS mycluster-gns.example.com
GNSを使用する場合、クラスタ内のノードのresolve.conf
(または解決情報を提供するシステムのファイル)を構成し、社内のDNSサーバーに解決可能なネーム・サーバーのエントリを追加する必要があります。オプションの試行回数(リトライ回数)とオプションのタイムアウト(指数バックオフ)を組み合せた合計タイムアウト時間の構成は、30秒以下にすることをお薦めします。たとえば、xxx.xxx.xxx.42とxxx.xxx.xxx.15がネットワーク内で有効なネーム・サーバーのアドレスである場合、/etc/resolv.conf
に次のようなエントリを入力します。
options attempts: 2 options timeout: 1 search cluster01.example.com example.com nameserver xxx.xxx.xxx.42 nameserver xxx.xxx.xxx.15
/etc/nsswitch.conf
によって、ネーム・サービスの参照順序が制御されます。一部のシステム構成では、ネットワーク情報システム(NIS)によってOracle SCANアドレス解決に問題が発生することがあります。nis
エントリは、検索リストの最後に配置することをお薦めします。次に例を示します。
/etc/nsswitch.conf hosts: files dns nis
注意: ホスト名およびユーザー名の解決が失敗する可能性があるため、NISを使用することがケーブルのプル・テストを実行するときの問題の原因になることがあることに注意してください。 |
GNSを使用する場合は、GNSのVIPアドレスに静的IPアドレスを指定し、その静的なGNSのIPアドレスにサブドメインを委任する必要があります。
クラスタにノードが追加されると、社内のDHCPサーバーによって、これらのノードに動的にアドレスが提供されます。これらのアドレスは自動的にGNSに登録され、GNSによってサブドメイン内で、GNSに登録されたクラスタ・ノード・アドレスの解決が行われます。
アドレスの割当てと構成はGNSによって自動的に行われるため、これ以上の構成は必要ありません。Oracle Clusterwareによって、クラスタに対してノードが追加または削除されるときに、動的なネットワーク構成が行われます。参考までに例を示します。
2ノードのクラスタで、GNSのVIPが定義されている場合、インストール後に次のような構成を2ノードのクラスタに対して行います。クラスタ名はmycluster
、GNSの親ドメインはexample.com
、サブドメインはgrid.example.com
です。IPアドレスの192.0.2はクラスタのパブリックIPアドレス・ネットワークを表し、192.168.0はプライベートIPアドレス・サブネットを表します。
表2-2 グリッド・ネーミング・サービスのネットワーク例
ID | ホーム・ノード | ホスト・ノード | 指定された名前 | 種類 | アドレス | アドレスの割当て元 | 解決方法 |
---|---|---|---|---|---|---|---|
GNS VIP |
なし |
Oracle Clusterwareにより選択 |
|
仮想 |
192.0.2.1 |
ネットワーク管理者が固定 |
DNS |
ノード1パブリック |
ノード1 |
|
|
パブリック |
192.0.2.101 |
固定 |
GNS |
ノード1 VIP |
ノード1 |
Oracle Clusterwareにより選択 |
|
仮想 |
192.0.2.104 |
DHCP |
GNS |
ノード1プライベート |
ノード1 |
|
|
プライベート |
192.168.0.1 |
固定またはDHCP |
GNS |
ノード2パブリック |
ノード2 |
|
|
パブリック |
192.0.2.102 |
固定 |
GNS |
ノード2 VIP |
ノード2 |
Oracle Clusterwareにより選択 |
|
仮想 |
192.0.2.105 |
DHCP |
GNS |
ノード2プライベート |
ノード2 |
|
|
プライベート |
192.168.0.2 |
固定またはDHCP |
GNS |
SCAN VIP 1 |
なし |
Oracle Clusterwareにより選択 |
|
仮想 |
192.0.2.201 |
DHCP |
GNS |
SCAN VIP 2 |
なし |
Oracle Clusterwareにより選択 |
|
仮想 |
192.0.2.202 |
DHCP |
GNS |
SCAN VIP 3 |
なし |
Oracle Clusterwareにより選択 |
|
仮想 |
192.0.2.203 |
DHCP |
GNS |
脚注 1 ノードのホスト名が、ホスト上で使用されているVIPアドレスなど、複数のアドレスに解決される場合があります。
GNSを使用しない場合は、インストールの前に、パブリックIPアドレス、仮想IPアドレスおよびプライベートIPアドレスを構成する必要があります。また、ping
コマンドを実行し、デフォルトのゲートウェイにアクセスできることも確認してください。デフォルトのゲートウェイを検出するには、route
コマンドを使用します(オペレーティング・システムのヘルプを参照)。
たとえば、各ノードに1つのパブリック・インタフェースと1つのプライベート・インタフェースがある2ノードのクラスタの場合に、3つのIPアドレスのいずれかに解決されるSCANドメイン・アドレスがDNSに定義してあるとすると、ネットワーク・インタフェースには、次の表に示す構成が考えられます。
表2-3 手動によるネットワークの構成例
ID | ホーム・ノード | ホスト・ノード | 指定された名前 | 種類 | アドレス | アドレスの割当て元 | 解決方法 |
---|---|---|---|---|---|---|---|
ノード1パブリック |
ノード1 |
|
|
パブリック |
192.0.2.101 |
固定 |
DNS |
ノード1 VIP |
ノード1 |
Oracle Clusterwareにより選択 |
|
仮想 |
192.0.2.104 |
固定 |
DNSおよびhostsファイル |
ノード1プライベート |
ノード1 |
|
|
プライベート |
192.168.0.1 |
固定 |
DNSおよびhostsファイル、またはなし |
ノード2パブリック |
ノード2 |
|
|
パブリック |
192.0.2.102 |
固定 |
DNS |
ノード2 VIP |
ノード2 |
Oracle Clusterwareにより選択 |
|
仮想 |
192.0.2.105 |
固定 |
DNSおよびhostsファイル |
ノード2プライベート |
ノード2 |
|
|
プライベート |
192.168.0.2 |
固定 |
DNSおよびhostsファイル、またはなし |
SCAN VIP 1 |
なし |
Oracle Clusterwareにより選択 |
mycluster-scan |
仮想 |
192.0.2.201 |
固定 |
DNS |
SCAN VIP 2 |
なし |
Oracle Clusterwareにより選択 |
mycluster-scan |
仮想 |
192.0.2.202 |
固定 |
DNS |
SCAN VIP 3 |
なし |
Oracle Clusterwareにより選択 |
mycluster-scan |
仮想 |
192.0.2.203 |
固定 |
DNS |
脚注 1 ノード・ホスト名が、複数のアドレスに解決される場合があります。
インターコネクト用にプライベート名を指定する必要はありません。インターコネクト用に名前解決が必要な場合は、hostsファイルかDNSでプライベートIP名を構成できます。ただしOracle Clusterwareでは、インストール中にプライベート・インタフェースとして定義されたインタフェース(lan1
など)と、プライベート・サブネットに使用されるサブネットに、インターコネクト・アドレスが割り当てられます。
SCANが解決されるアドレスはOracle Clusterwareによって割り当てられるため、特定のノードには固定されません。VIPのフェイルオーバーが有効になるように、前述の表で示した構成では、SCANアドレスと、両方のノードのパブリック・アドレスおよびVIPアドレスが同一のサブネット(192.0.2)上に定義されています。
注意: すべてのホスト名はRFC 952標準(英数字を許可)に準拠している必要があります。アンダースコア(_)を使用するホスト名は使用できません。 |
選択する正確なネットワーク構成は、構成するクラスタのサイズおよび使用方法と、必要な可用性のレベルによって異なります。
動作保証されているネットワーク接続ストレージ(NAS)をOracle RAC用に使用し、このストレージにイーサネットベースのネットワークを介して接続する場合は、NAS I/O用に3つ目のネットワーク・インタフェースが必要です。この場合、3つの別々のインタフェースを使用しないと、負荷によってパフォーマンスと安定性の問題が発生します。
Oracle ClusterwareがNASデバイスまたはNFSマウントの使用によるネットワーク障害をより許容できるようにするには、ネーム・サービス・キャッシュ・デーモン(nscd
)を有効にします。nscd
によって、最も一般的なネーム・サービス・リクエストに対するキャシング・メカニズムが提供されます。システムがマルチユーザーの状態で起動すると、自動的に起動します。Oracleソフトウェアでは、サーバーがマルチユーザー実行レベル(3)で起動される必要があります。これはHP-UXのデフォルトです。
サーバーが3に設定されていることを確認するには、コマンドwho -r
を入力します。次に例を示します。
# who -r . run-level 3 Jan 4 14:04 3 0 S
実行レベルの変更が必要な場合は、ご使用のオペレーティング・システムのドキュメントを参照してください。
パスワードおよびグループのキャッシュ・デーモン(pwgrd
)が実行されていることを確認するには、次のコマンドを入力します。
ps -aef |grep pwgrd
インストールする製品に応じて、次のオペレーティング・システム・ソフトウェアがシステムにインストールされていることを確認します。パッチ要件は必要最小限のパッチ・バージョンであり、前のパッチ番号は後のパッチ更新に含められていることに注意してください。
ソフトウェア要件を確認するには、第2.8項「ソフトウェア要件の確認」を参照してください。
ここに記載されている要件は、初回リリース日時点で最新のものです。カーネル要件の最新情報については、Oracle Technology Network(OTN)を参照してください。URLは次のとおりです。
http://www.oracle.com/technetwork/indexes/documentation/index.html
OUIによって、ご使用のシステムが示されたオペレーティング・システムの要件を満たしていることを確認する検証が実行されます。これらの検証が正常に完了するように、OUIを起動する前に要件を確認してください。
サポートされているHP-UXプラットフォームおよびリリース時における要件のリストを次に示します。
注意: 現在のリリース時点では、Oracle Grid Infrastructure 11gリリース2のリリース11.2.0.3は、HP-UX Itaniumでのみサポートされています。 |
表2-4 HP-UX Itaniumの要件
項目 | 要件 |
---|---|
オペレーティング・システム |
|
HP-UX 11.31パッケージとバンドル |
PHCO_43503 - 11.31 diskowner(1M) cumulative patch PHCO_41479 - 11.31 diskowner patch PHKL_38038 - VM cumulative patch PHKL_38938 - 11.31 SCSI cumulative I/O patch PHKL_40941 - Scheduler patch : post wait hang PHSS_36354 - 11.31 assembler patch PHSS_37042 - 11.31 hppac (packed decimal) PHSS_37959 - Libcl patch for alternate stack issue fix (QXCR1000818011) PHSS_39094 - 11.31 linker + fdp cumulative patch PHSS_39100 - 11.31 Math Library Cumulative Patch PHSS_39102 - 11.31 Integrity Unwind Library PHSS_38141 - 11.31 aC++ Runtime |
Oracle Clusterware |
Oracle Clusterwareの追加要件はありません。 このリリースの時点では、Hyper Messagingプロトコル(HMP)はサポートされていません。 Oracle Clusterware 11gリリース2 (11.2)では、HP Serviceguard A.11.20がサポートされています。 注意: HP Serviceguardはオプションです。必要となるのは、Oracle Clusterwareまたはデータベース・ファイルに共有論理ボリュームを使用する場合のみです。 |
HP-UX論理ボリューム・マネージャ(LVM) |
|
VERITASファイル・システム |
注意: VERITAS File Systemはオプションです。このパッチは、VERITAS File System 5.0を使用する場合にのみ必要です。 |
Oracle Database 11gリリース2(11.2)での、Pro*C/C++用のC/C++コンパイラ・パッチ、Oracle Call Interface、Oracle C++ Call InterfaceおよびOracle XML Developer's Kit (XDK) |
C / C++コンパイラ
Cコンパイラ・パッチ
Gccコンパイラ
|
Oracle JDBC/OCIドライバ |
ODBCを使用するには、 注意: JDBC/OCIの場合は、Oracle Java Database ConnectivityおよびOracle Call Interfaceドライバを使用して、JNDI拡張を含むJDKをインストールしてください。ただし、データベース・インストールの場合、これらは必須ではありません。このリリースでは、JDK 1.5がインストールされています。 |
Oracle Messaging Gateway |
Oracle Messaging Gatewayでは、Oracle Streams Advanced Queuing(AQ)と次のソフトウェアの統合がサポートされています。 IBM MQ Series V. 6.0、クライアントおよびサーバー
TIBCO Rendezvous 7.2 |
Oracle ODBC |
HP UX Itanium上のOracle ODBCドライバは、ODBCドライバ・マネージャ2.2.14で動作保証されています。ドライバ・マネージャは、次のURLからダウンロードしてインストールできます。
Oracle DatabasesをインストールするためにODBCドライバ・マネージャは必要ありません。ODBCを使用するには、gcc 4.2.3以上もインストールする必要があります。 |
Perl |
Perl 5.8.8 |
プログラミング・ソフトウェア(オプション) |
Pro*Cobol - Micro Focus Server Express 5.1 Pro*FORTRAN - HP FORTRAN/90 - Sep 2008 release |
VERITASファイル・システム |
PHKL_39773: 11.31 VRTS 5.0 GARP6 VRTSvxfs Kernel Patch 注意: このパッチが必要になるのは、VERITAS File System 5.0を使用する場合のみです。 |
SSH |
Oracle ClusterwareにはSSHが必要です。必要なSSHソフトウェアは、オペレーティングシステムに付属のデフォルトのSSHです。 |
現在のリリース時点では、Oracle Grid Infrastructure 11gリリース2のリリース11.2.0.4は、HP-UX Itaniumでのみ利用できます。HP-UX PA-RISCシステムのOracle Grid Infrastructure 11gリリース2 (リリース11.2.0.3)の要件は次のとおりです。
表2-5 HP-UX PA-RISC(64-bit)の要件
項目 | 要件 |
---|---|
オペレーティング・システム |
|
HP-UX 11.31パッケージとバンドル |
PHKL_39773 (11.31 VRTS 5.0 GARP6 VRTSvxfs Kernel Patch. このパッチはVxFS 5.0がインストールされた場合にのみ必要です。 このパッチに他の依存関係はありません。HP-UX 11.31の2009年9月の更新に含まれています。 PHCO_40381 - 11.31 Disk Owner Patch PHKL_38038 - VM patch - hot patching/Core file creation directory PHKL_38938 - 11.31 SCSI cumulative I/O patch PHKL_39351 - 11.31 scheduler cumulative patch PHSS_37959 - Libcl patch for alternate stack issue fix (QXCR1000818011) PHSS_38141 - 11.31 aC++ Runtime PHSS_39094 - 11.31 linker + fdp cumulative patch PHSS_39080 - PA32 program startup code for PBO instrumented builds PHSS_47276 - core dump from u_get_previous_frame_x |
Oracle Database 11gリリース2(11.2)での、Pro*C/C++用のC/C++コンパイラ・パッチ、Oracle Call Interface、Oracle C++ Call InterfaceおよびOracle XML Developer's Kit (XDK) |
C++コンパイラ
Cコンパイラ
Cコンパイラ・パッチ
Gccコンパイラ
|
プログラミング・ソフトウェア(オプション) |
Micro Focus Server Express 5.1 HP Fortran/90 - Sep 2008 - リリース |
Oracle Clusterware |
Oracle Clusterwareの追加要件はありません。 このリリースの時点では、Hyper Messagingプロトコル(HMP)はサポートされていません。 Oracle Clusterware 11gリリース2 (11.2)では、HP Serviceguard A.11.20がサポートされています。 注意: HP Serviceguardはオプションです。必要となるのは、Oracle Clusterwareまたはデータベース・ファイルに共有論理ボリュームを使用する場合のみです。 |
Oracle Messaging Gateway(オプション) |
Oracle Messaging Gatewayでは、Oracle Streams Advanced Queuing(AQ)と次のソフトウェアの統合がサポートされています。 IBM MQ Series V. 6.0、クライアントおよびサーバー
TIBCO Rendezvous 7.2 |
Oracle ODBC |
このリリースの時点では、Oracle ODBCはPA-RISC上のHP-UXでサポートされていません。 |
Oracle JDBC/OCIドライバ |
|
VERITASファイル・システム |
PHKL_39773: 11.31 VRTS 5.0 GARP6 VRTSvxfs Kernel Patch 注意: このパッチには、他の依存性はありません。HP-UX 11.31のSeptember 2009 updateに含まれています。VxFS 5.0がインストールされている場合のみ必要です。 |
SSH |
Oracle ClusterwareにはSSHが必要です。必要なSSHソフトウェアは、オペレーティングシステムに付属のデフォルトのSSHです。 |
システムがこれらの要件を満たしていることを確認するには、次の手順を実行します。
次のコマンドを入力して、インストールされているHP-UXのバージョンを確認します。
# uname -a
"HP-UX hostname
B.11.31 U ia64 4156074294 unlimited-user license"
この例では、HP-UX 11のバージョンは11.31で、プロセッサはItaniumです。
次のコマンドを使用して、システムが最小パッチ・バンドル要件を満たしていることを確認します。
# /usr/sbin/swlist -l bundle |grep QPK
QPK(Quality Pack)バンドルには、B.11.31.0809.326a(2008年9月リリースの場合)や、B.11.31.0903.334a(2009年3月リリースの場合)という形式のバージョン番号が付いています。必要なバンドル、製品またはファイルセットがインストールされていない場合は、インストールする必要があります。製品のインストールについては、ご使用のオペレーティング・システムまたはソフトウェアのマニュアルを参照してください。
注意: 前の段落にリストされているパッチのバージョンより新しいパッチがシステムにインストールされている場合があります。記載のパッチがインストールされていない場合、記載のバージョンをインストールする前に、それより新しいバージョンがインストールされているかどうかを確認します。 |
必要なパッチがインストールされていない場合は、次のWebサイトからダウンロードして、インストールします。
http://itresourcecenter.hp.com
Webサイトに表示されるパッチのバージョンの方が新しい場合は、そのバージョンをダウンロードしてインストールします。
WebSphere MQのCSDが必要な場合は、次のWebサイトでダウンロードおよびインストールの情報を参照してください。
http://www-01.ibm.com/software/
注意: リストされているパッチのバージョンより新しいパッチがシステムにインストールされている場合があります。リストされているパッチがインストールされていない場合、リストされているバージョンをインストールする前に、より新しいバージョンがインストールされているかどうかを確認します。 |
Oracle Clusterwareでは、すべてのクラスタ・ノードで同じのタイムゾーン設定が必要です。インストール中に、インストール・プロセスは、OUIを実行しているノードでグリッド・インストール所有者のタイムゾーン設定を選択し、Oracle Clusterwareによって管理されるすべてのプロセスのデフォルトのTZ設定として、すべてのノードでその設定を使用します。このデフォルトは、データベース、Oracle ASMおよびその他の管理プロセスで使用されます。
時刻を同期させるための手段は2つあります。オペレーティング・システムに構成されているネットワーク・タイム・プロトコル(NTP)と、Oracleクラスタ時刻同期化サービスです。Oracleクラスタ時刻同期化サービスは、クラスタ・サーバーからNTPサービスにアクセスできない組織のために設計されています。NTPを使用する場合は、Oracleクラスタ時刻同期化デーモン(ctssd)は、オブザーバ・モードで起動します。NTPデーモンがない場合、ctssd
はアクティブ・モードで起動し、外部時間サーバーに接続しなくても、クラスタ・メンバー間で時刻を同期します。
注意: Oracle Grid Infrastructureのインストールを開始する前に、すべてのノードの時計が同じ時刻になっていることを確認することをお薦めします。 |
サーバー上にNTPデーモンがある場合でも、時間サーバーの時刻と同期されるように構成できず、クラスタ時刻同期化サービスを使用して、クラスタ内で同期化サービスを提供する場合は、ネットワーク・タイム・プロトコル(NTP)を非アクティブにし、削除します。
NTPサービスを非アクティブ化するには、既存のntpd
サービスを停止し、初期化シーケンスでは無効化し、ntp.conf
ファイルを削除します。この手順を行うには、次のコマンドをroot
ユーザーとして実行します。
# /sbin/init.d/xntpd stop # rm /etc/ntp.conf
または、mv /etc/ntp.conf
/etc/ntp.conf.org
を実行します。
NTPプロトコルがアクティブでないとインストーラによって判断されると、クラスタ時刻同期化サービスがアクティブ・モードでインストールされ、ノード間で時刻が同期されます。NTPが構成されていると判断された場合は、クラスタ時刻同期化サービスはオブザーバ・モードで起動され、クラスタ内でOracle Clusterwareによるアクティブな時刻同期化は行われません。
インストール後にctssd
がアクティブになっていることを確認するには、グリッド・インストール所有者として次のコマンドを入力します。
$ crsctl check ctss
NTPを使用しており、クラスタ時刻同期化サービスではなくNTPを使用し続ける場合は、NTP初期化ファイルを変更してスルーイングを有効にし、逆向きの時間調整が行われないようにします。この作業が終わった後で、ネットワーク・タイム・プロトコル・デーモンを再起動します。
HP-UXでこれを実行するには、テキスト・エディタを使用して/etc/rc.config.d/netdaemons
ファイルを開き、export XNTPD_ARGS="-x"
行をファイルに追加します。XNTPD_ARGS
行を追加した後、設定を読み込ませるために、/sbin/init.d/xntpd stop
コマンドおよび/sbin/init.d/xntpd start
コマンドを使用して、xntpd
を停止して再起動します。
Intelligent Platform Management Interface(IPMI)は、コンピュータのハードウェアおよびファームウェアへの共通インタフェースを提供し、システム管理者はそのインタフェースを使用して、システム状態の監視およびシステムの管理を実行できます。Oracle 11g リリース2では、Oracle ClusterwareにIPMIを統合して、障害分離をサポートしたりクラスタの整合性を確保することができます。
現在、Oracle ClusterwareではHP-UXでネイティブIPMIドライバをサポートしていないため、OUIでは管理者資格証明が収集されません。また、CSSではIPアドレスを取得できません。インストール前に静的IPアドレスを使用してBMCを構成し、インストール後にcrsctl
を使用してIPアドレスおよびIPMI資格証明を格納することによって、障害分離を手動で構成する必要があります。
この項の内容は次のとおりです。
参照: インストール後にIPMIの構成を行う方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
クラスタ・ノードをIPMIで管理できるようするには、次のようにハードウェアおよびソフトウェアを構成する必要があります。
各クラスタ・メンバー・ノードにBaseboard Management Controller(BMC)が必要です。このBMCは、IPMI over LANをサポートするIPMIバージョン1.5以上と互換性があるファームウェアを実行し、LANを使用したリモート制御に対応するように構成されている必要があります。
クラスタに、IPMI用の管理ネットワークが必要です。これは共有ネットワークでも可能ですが、専用ネットワークの構成をお薦めします。
BMCで使用する各クラスタ・メンバー・ノードのポートが、IPMI管理ネットワークに接続されている必要があります。
各クラスタ・メンバーが管理ネットワークに接続されている必要があります。
一部のサーバー・プラットフォームでは、電源を切るとネットワーク・インタフェースが省電力モードになります。この場合には、低いリンク速度(1GBではなく100MBなど)で動作することになります。こうしたプラットフォームの場合、BMCが接続されるネットワーク・スイッチ・ポートで、低い速度に合わせた自動ネゴシエートが可能である必要があります。そうでない場合は、IPMIが正常に動作しません。
HP-UXプラットフォームでは、BMCは構成情報を管理プロセッサ(iLO)と共有します。Oracle Clusterwareの場合は、ilO/BMCを静的IPアドレス用に構成する必要があります。HP-UXでは、BMCを動的アドレス(DHCP)を使用して構成することはサポートされていません。
注意: IPMIを構成し、グリッド・ネーミング・サービス(GNS)を使用する場合でも、IPMIインタフェースには別のアドレスを構成する必要があります。IPMIアダプタはホストから直接には認識できないため、GNSはホスト上のアドレスとしてIPMIアダプタを認識できません。 |
各ノードで、次の手順を実行してIPMIベースのノード・フェンシングをサポートするようにBMCを構成します。
BMC用に静的IPアドレスを構成します。
BMCのnull(noname
)アカウントのパスワードを設定します。
HP-UXでは、BMCとiLOはネットワーク構成を共有します。同じIPアドレス、同じハードウェアMACアドレス、同じデフォルトのゲートウェイ・アドレスを使用します。
iLOプロセッサがすでに静的アドレスを使用したネットワーク・アクセス用に構成されている場合は、必要なBMCネットワーク構成がすでに確立されています。iLO用に静的アドレスを設定していない場合は静的アドレスを設定し、インストール後にOracle Clusterwareのローカル・レジストリに入力できるように、そのアドレスを記録しておく必要があります。
また、null(noname
)ユーザー・アカウントはBMCが使用する単一のアカウントであるため、このアカウントのパスワードも設定する必要があります。iLOの管理アカウントはBMCには関係しません。セキュリティ上の理由から、BMCアカウントにパスワードを設定する必要があります。
BMCの構成方法については、HP-UXのドキュメントを参照してください。BMCが各クラスタ・メンバー・ノードに構成されていることを確認してください。
HPプラットフォームのiLOプロセッサでIPMIを構成し、null(noname
ユーザー)のパスワードを設定するには、次の手順を実行します。
iLO Webインタフェースにログインし、「Administration」→「Network Settings」でiLOおよびBMCに必要なネットワーク設定を構成し、IPアドレスを取得して、ネットマスクおよびデフォルトのゲートウェイを確認します。
構成するノードのBMCにネットワーク接続されたデバイスから端末セッションを起動します。
端末セッションで、ユーザー・パスワードを変更するノードに接続されているクライアントまたはサーバーからipmitool
などのIPMI管理ツールを使用して、ネットワーク経由で匿名ユーザー(noname
)のIPMIパスワードを設定します。たとえば、IPMIアドレスがipmiaddr
で、パスワードがpassword
の場合は次のようになります。
% ipmitool -H ipmiaddr -U "" user set password 1 "password"
この例では、わかりやすいように匿名ユーザー名が-U ""
を使用して明示的に指定されていますが、ユーザー名の引数が指定されていない場合は暗黙的に行われます。このコマンドを実行すると、現行のパスワードを入力するように求められます。これをnullの初期パスワードにできます。パスワードが正常に変更されると、「Close session command failed.」のようなエラーが出力されます。このメッセージは、コマンドが前のパスワードを使用してIPMIネットワーク・セッションを終了しようとしたために出力されます。
注意: 「Local Accounts」Webインタフェース・ページを使用して、IPMI管理者アカウントのパスワードを設定することはできません。 |
各クラスタ・メンバー・ノードでBMCを構成し、Oracle Grid Infrastructureのインストールを完了した後、IPMI管理者資格証明およびBMC静的IPアドレスを各クラスタ・メンバー・ノードのOracle Local Registry(OLR)に格納する必要があります。これを行うには、第5.2.2項「crsctlを使用したIPMIベース障害分離の構成」で説明されているとおり、crsctl
を使用します。ただし、IPMI資格証明をOLRに格納する場合は、明示的に指定した匿名ユーザーが必要です。ない場合は、解析エラーがレポートされます。
% crsctl set css ipmiadmin ""
プロンプトに対し、IPMI管理者ツールで設定したパスワードを指定します。
Oracleソフトウェアをインストールするには、すべてのクラスタ・メンバー・ノード間にセキュア・シェル(SSH)の接続が設定されている必要があります。OUIは、インストール中にssh
およびscp
コマンドを使用して、他のクラスタ・ノードに対してリモート・コマンドを実行し、そのクラスタ・ノードにファイルをコピーします。これらのコマンドを使用する際にパスワードを求めるプロンプトが表示されないように、SSHを構成する必要があります。
注意: SSHは、Oracle Configuration Assistantによる、ローカル・ノードからリモート・ノードに対する構成操作に使用されます。Enterprise Managerでも使用されます。 |
OUIインタフェースから、インストール中に、インストールを実行しているユーザー・アカウントにSSHを構成することができます。自動構成によって、パスワードなしのSSH接続をすべてのクラスタ・メンバー・ノード間に作成することができます。可能なかぎり、この自動手順を利用することをお薦めします。
スクリプトを実行できるようにするには、すべてのOracleソフトウェア・インストール所有者のプロファイルからstty
コマンドを削除するとともに、ログイン時にトリガーされる他のセキュリティ手段で、端末に対してメッセージを生成するものを削除する必要があります。これらのメッセージやメール・チェックなどが表示されていると、Oracleソフトウェア・インストール所有者は、Oracle Universal Installerに組み込まれているSSH構成スクリプトを使用できません。これらの表示が無効になっていない場合は、SSHを手動で構成してからでなければ、インストールを実行できません。
まれに、リモート・ノードがSSH接続を閉じると、「AttachHome」操作時にOracle Clusterwareインストールが失敗する場合があります。この問題を回避するために、すべてのクラスタ・ノードでSSHデーモン構成ファイルopt/ssh/etc/sshd_config
に次のパラメータを設定し、タイムアウト待機時間を無制限に設定します。
LoginGraceTime 0
インストーラ・ソフトウェアは、Oracle Grid Infrastructureインストール所有者ユーザー・アカウント(oracle
またはgrid
)で実行します。ただし、インストーラを起動する前に、インストール所有者ユーザー・アカウントの環境を構成する必要があります。また、必要に応じて、他の必要なOracleソフトウェア所有者を作成します。
この項の内容は次のとおりです。
Oracle Grid Infrastructureソフトウェア所有者の環境を構成するには、次の変更を行う必要があります。
シェル起動ファイルで、インストール・ソフトウェア所有者ユーザー(grid
、oracle
)のデフォルトのファイル・モード作成マスク(umask)を022に設定します。 マスクを022に設定すると、ソフトウェア・インストールを実行するユーザーが作成するファイルの権限は常に644になります。
インストール・ソフトウェア所有者(grid
、oracle
)のファイル記述子およびプロセスに対して、ulimitを設定します。
Oracle Grid Infrastructureをインストールする準備として、ソフトウェア所有者のDISPLAY環境変数を設定します。
注意: ご使用のオペレーティング・システム・ベンダーでサポートされているシェル・プログラムを使用してください。ご使用のオペレーティング・システムでサポートされていないシェル・プログラムを使用すると、インストール中にエラーが発生する場合があります。 |
Oracleソフトウェア所有者の環境を設定するには、ソフトウェア所有者(grid
、oracle
)ごとに次の手順を実行します。
X端末(xterm
)などの端末セッションを新規に開始します。
次のコマンドを入力して、このシステムでX Windowアプリケーションが表示可能であることを確認します。
$ xhost + hostname
hostnameは、ローカル・ホストの名前です。
ソフトウェアをインストールするシステムにまだログインしていない場合は、ソフトウェア所有者ユーザーとしてそのシステムにログインします。
そのユーザーでログインしていない場合は、構成するソフトウェア所有者に切り替えます。たとえば、grid
ユーザーの場合は次のようになります。
$ su - grid
次のコマンドを入力して、ユーザーのデフォルトのシェルを確認します。
$ echo $SHELL
テキスト・エディタでユーザーのシェル起動ファイルを開きます。
Bourneシェル(sh
)またはKornシェル(ksh
):
$ vi .profile
Cシェル(csh
またはtcsh
):
% vi .login
環境変数ORACLE_SID
、ORACLE_HOME
またはORACLE_BASE
がファイルに設定されている場合は、そのファイルから適切な行を削除します。
ファイルを保存して、テキスト・エディタを終了します。
シェル起動スクリプトを実行するには、次のいずれかのコマンドを入力します。
BourneまたはKornシェル:
$ . ./.profile
Cシェル:
% source ./.login
ローカル・システムにソフトウェアをインストールしていない場合は、次のコマンドを入力してXアプリケーションをローカル・システムに表示します。
BourneまたはKornシェル:
$ DISPLAY=local_host
:0.0 ; export DISPLAY
Cシェル:
% setenv DISPLAY local_host
:0.0
この例で、local_host
は、OUIを表示するために使用するシステム(ご使用のワークステーションまたはPC)のホスト名またはIPアドレスです。
/tmp
ディレクトリの空き領域が7GB未満である場合は、空き領域が7GB以上のファイル・システムを選択し、環境変数TEMP
およびTMPDIR
を設定してこのファイル・システムの一時ディレクトリを指定します。
注意: Oracle RACのインストール用の一時ファイル・ディレクトリ(通常、/tmp )の場所として、共有ファイル・システムは使用できません。共有ファイル・システムに/tmp を配置すると、インストールは失敗します。 |
bdf
コマンドを使用して、十分な空き領域を持つ適切なファイル・システムを選択します。
必要に応じて、次のコマンドを入力し、選択したファイル・システムに一時ディレクトリを作成して、そのディレクトリに適切な権限を設定します。
$ su - root # mkdir /mount_point/tmp # chmod a+wr /mount_point/tmp # exit
次のコマンドを入力して、環境変数TEMPおよびTMPDIRを設定します。
BourneまたはKornシェル:
$ TEMP=/mount_point/tmp $ TMPDIR=/mount_point/tmp $ export TEMP TMPDIR
Cシェル:
% setenv TEMP /mount_point/tmp % setenv TMPDIR /mount_point/tmp
次のコマンドを入力して、ORACLE_HOMEおよびTNS_ADMIN環境変数が設定されていないことを確認します。
BourneまたはKornシェル:
$ unset ORACLE_HOME $ unset TNS_ADMIN
Cシェル:
% unsetenv ORACLE_HOME % unsetenv TNS_ADMIN
注意: ORACLE_HOME環境変数が設定されていると、インストーラはOracleホーム・ディレクトリのデフォルトのパスとして指定されている値を使用します。ただし、ORACLE_BASE環境変数を設定する場合は、ORACLE_HOME環境変数の設定を削除し、インストーラによって示されるデフォルトのパスを選択することをお薦めします。 |
インストール時にFixupスクリプトを生成して実行し、データベースを正常にインストールするために必要なカーネル・パラメータ値を確認および設定できます。このスクリプトは、必要なカーネル・パッケージを必要に応じて最小値に更新します。
Fixupスクリプトを使用できない場合は、カーネル・パラメータが付録D「カーネル・パラメータの手動構成」に示す最小値以上に設定されていることを確認してください。値を手動で確認および設定する方法については、表に続く手順で説明します。
注意: 付録D「カーネル・パラメータの手動構成」に示されている、Fixupスクリプトで構成したカーネル・パラメータおよびシェル制限値は最小値です。本番データベース・システムでは、これらの値を調整してシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。 |
リモート端末で作業を行っていて、そのローカル・ノードのみが表示されている場合(通常は、この状態になります)、次の構文を使用して、環境変数DISPLAYを設定します。
Bourne、KornおよびBashシェル:
$ export DISPLAY=hostname:0
Cシェル:
$ setenv DISPLAY hostname:0
たとえば、Bashシェルを使用していて、ホスト名がnode1
の場合は、次のコマンドを入力します。
$ export DISPLAY=node1:0
X11転送によってインストールが失敗しないように、次の手順に従って、Oracleソフトウェア所有者ユーザー用にユーザー・レベルのSSHクライアント構成ファイルを作成します。
テキスト・エディタを使用して、ソフトウェア・インストール所有者の~/.ssh/config
ファイルを編集または作成します。
ForwardX11属性がno
に設定されていることを確認します。次に例を示します。
Host * ForwardX11 no
Oracle Grid Infrastructureのインストール中、OUIは、SSHを使用してコマンドを実行したり、他のノードにファイルをコピーします。システム上の隠しファイル(.bashrc
や.cshrc
など)にstty
コマンドが含まれていると、インストール中にMakeファイルやその他のインストールに関するエラーが発生します。
この問題を防止するには、すべてのSTDOUT
またはSTDERR
出力(stty
、xtitle
などのコマンド)が停止されるように、次の例に示すように、Oracleインストール所有者ユーザーのホーム・ディレクトリにあるこれらのファイルを変更する必要があります。
Bourne、BashまたはKornシェル:
if [ -t 0 ]; then stty intr ^C fi
Cシェル:
test -t 0 if ($status == 0) then stty intr ^C endif
注意: SSHを使用できない場合、インストーラは、ssh およびscp コマンドのかわりにremsh コマンドを使用します。
リモート・シェルによってロードされる隠しファイルに |
注意: この作業は、Motif 2.1開発環境パッケージ(X11MotifDevKit.MOTIF21-PRG)がインストールされていない場合にのみ必要です。 |
このソフトウェアをインストールした後で、Oracle製品を正常に再リンクできるようにするには、次のコマンドを使用して、必須のXライブラリ・シンボリック・リンクを/usr/lib
ディレクトリに作成します。
# cd /usr/lib # ln -s libX11.3 libX11.sl # ln -s libXIE.2 libXIE.sl # ln -s libXext.3 libXext.sl # ln -s libXhp11.3 libXhp11.sl # ln -s libXi.3 libXi.sl # ln -s libXm.4 libXm.sl # ln -s libXp.2 libXp.sl # ln -s libXt.3 libXt.sl # ln -s libXtst.2 libXtst.sl
Oracle Universal Installerでは、前提条件チェック時に、すべてのノードの/dev/async
デバイスのマイナー番号がデバイス・ファイルで0x4
または0x104
に設定されているか確認します。デフォルトでは、マイナー番号は0x0
に設定されます。インストールの開始前にマイナー番号を変更するには、次の手順を実行します。
root
ユーザーとしてログインします。
/dev/async
が存在するか確認します。デバイスが存在しない場合、次のコマンドを使用し作成します。
# /sbin/mknod /dev/async c 101 0x4
また、次のコマンドを使用するとマイナー番号値を0x104に設定できます。
# /sbin/mknod /dev/async c 101 0x104
/dev/async
が存在する場合、次の例のとおりマイナー番号の現在の値を確認します。
# ls -l /dev/async
crw-r--r-- 1 root sys 101 0x000000 Sep 28 10:38 /dev/async
ファイルの現在のマイナー番号が0x4
または0x104
でない場合、次のいずれかのコマンドを使用し、期待の値に変更します。
# /sbin/mknod /dev/async c 101 0x4 or # /sbin/mknod /dev/async c 101 0x104
インストール中に、Oracle Grid Infrastructureソフトウェアを格納するホーム・ディレクトリへのパスを指定するように求められます。指定するディレクトリ・パスが次の要件を満たすことを確認します。
Oracle Clusterwareホームを含む、既存のOracleホーム以外のパスに作成する必要があります。
ユーザー・ホーム・ディレクトリには作成できません。
すべてのファイルをroot
によって所有可能なパス内のサブディレクトリとして作成するか、一意のパス内に作成します。
インストール前にパスを作成する場合は、Oracle Grid Infrastructureのインストール所有者(通常、すべてのOracleソフトウェアに対して1つのインストール所有者の場合はoracle
、ロール・ベースのOracleインストール所有者の場合はgrid
)が所有し、権限が775に設定されている必要があります。
Oracle Grid Infrastructureは、共有記憶域の共有ホームではなく、ローカル・ホームにインストールすることをお薦めします。
Oracle Grid Infrastructureのみをインストールする場合は、Oracle Optimal Flexible Architecture(OFA)に準拠したパスを作成することをお薦めします。これによって、Oracle Universal Installer(OUI)がインストール中にそのディレクトリを選択できるようになります。OUIがパスをOracleソフトウェア・パスとして認識するには、u0[1-9]/appという形式にする必要があります。
OUIでOFA準拠のパスが検出されると、Oracle Grid InfrastructureおよびOracle Inventory(oraInventory
)ディレクトリが作成されます。
手動でOracle Grid Infrastructureのパスを作成する場合は、既存のOracleベース・パスではなく、別のパスの下に作成します。次に例を示します。
# mkdir -p /u01/app/11.2.0/grid # chown grid:oinstall /u01/app/11.2.0/grid # chmod -R 775 /u01/app/11.2.0/grid
このパスでは、インストール所有者の名前がgridの場合、OUIによってデフォルトで、グリッド・ホームとして次のパスが作成されます。
/u01/app/11.2.0/grid
データベースのインストールのために、Oracle Databaseインストール所有者アカウントを所有者とするOracleベース・パスを作成します。OracleベースのOFAパスは、/u01/app/
user
です。user
は、Oracleソフトウェア・インストールの所有者アカウントです。たとえば、次のコマンドを使用して、データベース・インストールの所有者アカウントoracle
のOracleベースを作成します。
# mkdir -p /u01/app/oracle # chown -R oracle:oinstall /u01/app/oracle # chmod -R 775 /u01/app/oracle
クラスタ名は、長さが1文字以上15文字以下の英数字である必要があり、先頭に数字を使用することはできませんが、ハイフン(-)を含むことができます。
標準インストールでは、SCANはクラスタ名にもなるため、SCAN名はクラスタ名の要件を満たす必要があります。拡張インストールでは、SCANおよびクラスタ名はインストール時に別々のフィールドに入力されるため、クラスタ名の要件はSCAN名に適用されません。