| Oracle® Grid Infrastructureインストレーション・ガイド 11gリリース2 (11.2) for IBM AIX on POWER Systems (64-Bit) B57777-08 |
|
 前 |
 次 |
| Oracle® Grid Infrastructureインストレーション・ガイド 11gリリース2 (11.2) for IBM AIX on POWER Systems (64-Bit) B57777-08 |
|
前 |
次 |
この章では、Oracle Universal Installer(OUI)を起動してクラスタ用Oracle Grid Infrastructureをインストールする前に完了する必要があり、クラスタにOracle Real Application Clusters(Oracle RAC)をインストールする場合に完了する必要があるシステム構成作業について説明します。
この章の内容は次のとおりです。
|
注意: 構成の変更を開始する前に、既存のデータベースのバックアップを必ず作成してください。 |
既存のOracleインストールがある場合は、バージョン番号、パッチおよびその他の構成情報を記録して、既存のインストール用のアップグレード手順を確認します。インストールを進める前に、アップグレードに関するOracleドキュメントを確認し、その後の処理を確認します。
Oracle ASM 11gリリース1(11.1)は、クラスタ内の個別のノードに対して、または複数のノードに対してまとめてローリング・アップグレードを行うことで、Oracle RACデータベースを停止することなくアップグレードできます。ただし、Oracle ASMを使用しているクラスタにスタンドアロン・データベースがある場合、アップグレードする前にそのスタンドアロン・データベースを停止する必要があります。Oracle ASM 10gからアップグレードする場合は、Oracle ASMクラスタ全体を停止してアップグレードを行う必要があります。
Oracle Automatic Storage Management(Oracle ASM)がすでにインストールされている場合は、Oracleのアップグレードに関するドキュメントを確認してください。今回のリリースでは、Oracle ASMホームの場所が変更されています。したがって、ストレージ管理を簡略化またはカスタマイズするためには、他の構成の変更も検討することが必要な場合があります。以前のリリースのOracle ASMホームがすでにある場合は、Oracle Clusterwareのアップグレードに使用する予定のユーザーが所有している必要があります。
オペレーティング・システムのローリング・アップグレード時に、そのオペレーティング・システムの両方のバージョンが、使用しているOracle Databaseリリースで保証されている場合は、異なるオペレーティング・システム・バイナリを使用できます。
|
注意: 異なるバージョンのオペレーティング・システムの混在は、数時間のアップグレードでのみサポートされています。Oracle Clusterwareでは、同じクラスタに異なるインストラクション・セット・アーキテクチャ(ISA)を使用するプロセッサを搭載するノードはサポートされていません。各ノードは、クラスタ内のほかのノードとバイナリ互換が必要です。たとえば、同じクラスタ内で、あるノードではIntel 64プロセッサを使用し、別のノードではIA-64(Itanium)プロセッサを使用することはできません。同じクラスタ内のあるノードで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
Oracleソフトウェアをインストールする前に、Oracleソフトウェアをインストールするシステムでrootユーザーとして複数の作業を実行する必要があります。リモート・サーバーでrootユーザーとして作業を実行するには、rootとしてリモート表示を有効にする必要があります。
|
注意: 別のユーザー(oracleなど)としてログインする場合は、そのユーザーでもこの手順を繰り返す必要があります。 |
リモート表示を可能にするには、次のいずれかの手順を実行します。
ソフトウェアをX Window SystemワークステーションまたはX端末からインストールする場合は、次の手順を実行します。
X端末(xterm)などのローカル端末セッションを開始します。
ソフトウェアをローカル・システムにインストールしない場合は、次の構文を使用してコマンドを入力し、リモート・ホストにローカルのXサーバーでXアプリケーションを表示させます。
$ xhost + remote_host
remote_hostは完全修飾されたリモートのホスト名です。次に例を示します。
$ xhost + somehost.example.com somehost.example.com being added to the access control list
ソフトウェアをローカル・システムにインストールしない場合は、ssh,コマンドを使用してソフトウェアをインストールするシステムに接続します。
$ ssh remote_host
remote_hostは完全修飾されたリモートのホスト名です。次に例を示します。
$ ssh somehost.example.com
rootユーザーでログインしていない場合は、次のコマンドを入力してユーザーをrootに切り替えます。
$ su - root password: #
Xサーバー・ソフトウェアがインストールされているPCまたはその他のシステムからソフトウェアをインストールする場合は、次の手順を実行します。
|
注意: この手順の詳細は、ご使用のXサーバーのマニュアルを参照してください。ご使用のXサーバー・ソフトウェアによっては、異なった順序で作業を実行する必要があります。 |
Xサーバー・ソフトウェアを起動します。
リモート・ホストがローカル・システムでXアプリケーションを表示できるようにXサーバー・ソフトウェアのセキュリティを設定します。
ソフトウェアをインストールするリモート・システムに接続し、システムでX端末(xterm)などの端末セッションを開始します。
rootユーザーとしてリモート・システムにログインしていない場合は、次のコマンドを入力し、ユーザーをrootに切り替えます。
$ su - root password: #
rootとしてログインし、次の手順を実行して、インストールに必要なグループおよびユーザーを検索または作成します。
|
注意: すべてのクラスタ・メンバー・ノードで、グループおよびユーザーのすべての番号が同一であることを確認します。 |
|
注意: 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中央インベントリ・ディレクトリ(oraInventory)があるかどうかを確認するには、次のようにします。
# more /etc/oraInst.loc
oraInst.locファイルが存在する場合、このコマンドの出力結果は、次のようになります。
inventory_loc=/u01/app/oracle/oraInventory inst_group=oinstall
前述の出力例の意味は次のとおりです。
inventory_locグループは、Oracle Inventoryの場所を示します。
inst_groupパラメータは、Oracle Inventoryグループの名前(この例では、oinstall)を示します。
grep groupname /etc/groupコマンドを使用して、Oracle Inventoryグループとして指定されたグループがまだシステムに存在していることを確認します。次に例を示します。
$ grep oinstall /etc/group oinstall:x:1000:grid,oracle
oraInst.locファイルが存在しない場合は、次のコマンドを入力して、Oracle Inventoryグループを作成します。
# mkgroup id=1000 adms='root' oinstall
このコマンドによって、グループID番号が1000のoraInventoryグループoinstallが作成されます。oraInventoryグループのメンバーには、Oracle中央インベントリ(oraInventory)への書込み権限が付与されます。
oraInventoryグループが存在しない場合、デフォルトでは、クラスタ用Oracle Grid Infrastructureソフトウェアのインストール所有者のプライマリ・グループが、oraInventoryグループとして表示されます。使用するOracleソフトウェア・インストール所有者のすべてが、このグループをプライマリ・グループとして利用できることを確認します。
次の場合は、Oracle Grid Infrastructureのソフトウェア所有者を作成する必要があります。
Oracleソフトウェア所有者ユーザーが存在しない場合(たとえば、システムへOracleソフトウェアを初めてインストールする場合)。
Oracleソフトウェア所有者ユーザーは存在するが、他のグループに所属する別のオペレーティング・システム・ユーザーを使用して、グリッド・インフラストラクチャと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の値を管理対象のインスタンス(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項「役割区分によるオペレーティング・システム権限グループおよびユーザーの作成」)。
新規ユーザーを作成するには、次の手順を実行します。
# smit security
「Security & Users」メニューで、「Users」を選択します。
「Users」メニューで、「Add a User」を選択します。
適切なメニュー項目を選択して、Oracle Grid Infrastructureソフトウェアのインストール所有者(grid)を作成します。「Primary GROUP」フィールドに、Oracle Inventoryグループを指定します。他のノードでも同じ値を指定できるように、このエントリ・フィールドに指定した情報をメモしておいてください。
[Enter]を押した後、[Esc]+[0]を押して終了します。
Oracle Grid Infrastructureソフトウェアのインストール所有者(grid)のパスワードを設定します。次に例を示します。
# passwd grid
Oracle Grid Infrastructureソフトウェアのインストール所有者(grid)で、CAP_NUMA_ATTACH、CAP_BYPASS_RAC_VMMおよびCAP_PROPAGATEが可能であることを確認します。
既存の権限を確認するには、rootとして次のコマンドを入力します。
# /usr/bin/lsuser -a capabilities grid
権限を追加するには、次のコマンドを入力します。
# /usr/bin/chuser capabilities=CAP_NUMA_ATTACH,CAP_BYPASS_RAC_VMM,CAP_PROPAGATE 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 Automatic Storage Management、サーバー上のすべての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の場合、別々のオペレーティング・システム・グループが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グループより少ない権限でASM管理者グループを作成するには、拡張インストール・タイプを選択してソフトウェアをインストールする必要があります。この場合、OUIによって、グループ名の指定を求めるプロンプトが表示されます。コード例では、このグループはasmoperです。
次の項では、必要なオペレーティング・システム・ユーザーおよびグループを作成する方法について説明します。
Oracle DatabaseをインストールしてOracle Grid Infrastructure環境で使用するときに、次のような場合はOSDBAグループを作成する必要があります。
OSDBAグループが存在しない場合(たとえば、システムへOracle Databaseソフトウェアを初めてインストールする場合)。
OSDBAグループが存在するが、新しいOracle Database環境では、データベースの管理権限を別のグループのオペレーティング・システム・ユーザーに付与する場合。
OSDBAグループが存在しない場合または新しいOSDBAグループが必要な場合は、smitを使用するか、シェル・コマンドラインを使用して作成します。既存のグループですでに使用されていないかぎり、グループ名にはdbaを使用します。次に例を示します。
# mkgroup -'A' id='1031' adms='root' dba
OSOPERグループを作成する必要があるのは、制限付きのデータベース管理権限(SYSOPERオペレータ権限)を持つオペレーティング・システム・ユーザーのグループを指定する場合のみです。ほとんどの環境では、OSDBAグループを作成するのみで十分です。次の場合にOSOPERグループを使用するには、このグループを作成する必要があります。
OSOPERグループが存在しない場合(たとえば、システムへOracle Databaseソフトウェアを初めてインストールする場合)
OSOPERグループが存在するが、新しいOracle環境で、データベースのオペレータ権限を別のグループのオペレーティング・システム・ユーザーに付与する場合
新しいOSOPERグループが必要な場合は、smitを使用するか、シェル・コマンドラインを使用して作成します。既存のグループですでに使用されていないかぎり、グループ名にはoperを使用します。
# mkgroup -'A' id='1032' adms='root' oper1
OSASMグループが存在しない場合または新しいOSASMグループが必要な場合は、smitを使用するか、シェル・コマンドラインを使用して作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmadminを使用します。
# mkgroup -'A' id='1020' adms='root' asmadmin
データベース管理者などのオペレーティング・システム・ユーザーのグループを指定し、Oracle ASM記憶域の起動と停止を含む、Oracle ASM記憶域層に対する制限付きの管理権限を付与する場合には、ASM用のOSOPERグループを作成します。ほとんどの環境では、OSASMグループを作成するのみで十分です。インストールのインタビュー時に、そのグループをASM用のOSOPERグループとして指定します。
ASM用の新しいOSOPERグループが必要な場合は、smitを使用するか、シェル・コマンドラインを使用して作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmoperを使用します。
# mkgroup -'A' id='1022' adms='root' asmoper
Oracle ASMインスタンスへのアクセスを可能にするには、ASM用のOSDBAグループを作成する必要があります。これは、OSASMとOSDBAが異なるグループである場合に必要です。
ASM用のOSDBAグループが存在しない場合またはASM用の新しいOSDBAグループが必要な場合は、smitを使用するか、シェル・コマンドラインを使用して作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmdbaを使用します。次に例を示します。
# mkgroup -'A' id='1021' adms='root' 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を使用します。
oracleユーザーは存在するが、プライマリ・グループがoinstallではない場合、または適切なOSDBAまたはASM用OSDBAグループのメンバーでない場合は、smitを使用して更新します。
シェル・プロンプトでsmitを入力して、SMITを起動します。
メイン・メニューで次のように選択します。
セキュリティおよびユーザー
グループ
グループの特性の変更/表示
特定のグループの名前を入力できるフォームが表示されます。
グループ名を入力するか、[F4]キーを使用してグループ名を強調表示させ、[Enter]キーを押します。
次のフィールドがあるフォームが表示されます。
Group NAME: アカウントのグループ名です。
Group ID: グループの識別子番号(GID)です。
User list: グループのメンバーであるユーザーのリストです。使用可能なユーザーのリストを表示するには[F4]キーを使用し、追加するユーザーにマークを付けるには[F7]キーを使用します。
必要に応じてこれらのフィールドを変更し、[Enter]を押してフォームを終了します。
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でログインします。
smitを使用するか、コマンドラインを使用して、必要に応じてグループおよびユーザーを作成します。コマンドラインを使用するには、次のコマンドを入力して、oinstall、asmadminおよびasmdbaグループを作成します。また、必要に応じて、asmoper、dbaおよびoperグループを作成します。idオプションを使用して、各グループに正しいgidを指定します。
# mkgroup -'A' id='1000' adms='root' oinstall # mkgroup -'A' id='1020' adms='root' asmadmin # mkgroup -'A' id='1021' adms='root' asmdba # mkgroup -'A' id='1022' adms='root' asmoper # mkgroup -'A' id='1031' adms='root' dba # mkgroup -'A' id='1032' adms='root' oper
|
注意: グループがすでに存在している場合は、必要に応じてsmitを使用してそのグループを変更します。このノードのグループに、同じグループIDを使用できない場合、すべてのノードの/etc/groupファイルを表示し、どのノードでも使用できるグループIDを特定します。すべてのノードのグループIDが同じになるように、グループIDを変更する必要があります。 |
oracleユーザーまたはOracle Grid Infrastructure (grid)ユーザーを作成するには、smitを使用するか、次のようなコマンドを入力します(この例では、oracleユーザーを作成します)。
# mkuser id='1001' pgrp='oinstall' groups='dba,asmdba' home='/home/oracle' oracle
前述のコマンドの意味は、次のとおりです。
idオプションは、ユーザーIDを指定します。ユーザーIDは、前の項で特定したユーザーIDである必要があります。
pgrpオプションは、プライマリ・グループを指定します。プライマリ・グループは、oinstallなどのOracle Inventoryグループである必要があります。
groupsオプションは、セカンダリ・グループを指定します。セカンダリ・グループには、OSASM、OSDBA、ASM用のOSDBA、OSOPERまたはASM用のOSOPERグループを含めることができます。次に例を示します。
グリッド・インストール所有者: OSASM(asmadmin)。メンバーはSYSASM権限を付与されます。
SYSASMアクセス権限のないOracle Databaseインストール所有者: OSDBA(dba)、ASM用のOSDBA(asmdba)、ASM用のOSOPER(asmoper)。
|
注意: ユーザーがすでに存在している場合は、必要に応じてsmitを使用してそのユーザーを変更します。すべてのノードのユーザーに、同じユーザーIDを使用できない場合、すべてのノードの/etc/passwdファイルを表示して、どのノードでも使用できるユーザーIDを特定します。すべてのノードのユーザーにそのIDを指定する必要があります。 |
# passwd oracle
第2.14.1項「Oracle Grid Infrastructureソフトウェア所有者の環境要件」で説明するとおり、各ユーザーに対してユーザー環境の構成を行います。
次に、コマンドラインを使用してOracle Inventoryグループ(oinstall)および単一のグループ(dba)をOSDBA、OSASMおよびASM用OSDBAグループとして作成する例を示します。また、適切なグループ・メンバーシップを持つ、Oracle Grid Infrastructureソフトウェア所有者(grid)と1つのOracle Database所有者(oracle)を作成する方法も示します。適切な権限を持つ、OFA構造準拠のOracleベース・パスの構成方法についても示します。
# mkgroup -'A' id='1000' adms='root' oinstall # mkgroup -'A' id='1031' adms='root' dba # mkuser id='1100' pgrp='oinstall' groups='dba' home='/home/grid' grid # mkuser id='1101' pgrp='oinstall' groups='dba' home='/home/oracle' oracle # 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グループ(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)デプロイメントに準拠する、ロール割当てをしたグループおよびユーザーの作成方法の例を示します。
# mkgroup -'A' id='1000' adms='root' oinstall # mkgroup -'A' id='1020' adms='root' asmadmin # mkgroup -'A' id='1021' adms='root' asmdba # mkgroup -'A' id='1031' adms='root' dba1 # mkgroup -'A' id='1041' adms='root' dba2 # mkgroup -'A' id='1022' adms='root' asmoper # mkuser id='1100' pgrp='oinstall' groups='asmadmin' home='/home/grid' grid # mkuser id='1101' pgrp='oinstall' groups='dba1,asmdba' home='/home/oracle' oracle1 # mkuser id='1102' pgrp='oinstall' groups='dba2,asmdba' home='/home/oracle' oracle2 # mkdir -p /u01/app/11.2.0/grid # mkdir -p /u01/app/grid # chown -R grid:oinstall /u01/app/grid # 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を管理するための権限が付与されます。
個別の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つの異なるデータベース(dba1およびdba2)用の2つの別々のOSDBAグループ。各データベースには別々の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。これらの権限はインストールに必要であり、インストール・プロセス中、755権限(drwxr-xr-x)でroot:oinstallに変更されます。
/u01/app/oraInventory。このパスは、引き続きgrid:oinstallが所有し、他のOracleソフトウェア所有者が中央インベントリに書込みできるようにします。
同じインストラクション・セット・アーキテクチャを持つサーバーを選択します。
各サーバーが、同じオペレーティング・システム・レベル、APARおよびファイル・セットで実行されていることを確認します。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の倍数と同等のスワップ領域
| 使用可能なRAM | 必要なスワップ領域 |
|---|---|
| 2.5GBから16GB | RAMサイズと同等 |
| 16GBを超える | 16GB |
/tmpディレクトリに1GBのディスク領域。
クラスタ用Oracle Grid Infrastructureホーム(Gridホーム)に13GBの領域(ここには、Oracle ClusterwareおよびOracle Automatic Storage Management(Oracle ASM)のファイルとログ・ファイル、Oracle ACFSログ・ファイル、およびクラスタ状態モニター・リポジトリが格納されます)。
|
注意: Oracle DatabaseまたはOracle RACデータベースをクラスタ上にインストールする場合は、各サーバーの/dev/shmマウント領域が、サーバーのデータベースのシステム・グローバル領域(SGA)およびプログラム・グローバル領域(PGA)より大きいサイズである必要があることに注意してください。SGAおよびPGAの予想サイズをデータベース管理者に確認し、データベースをクラスタにインストールした後に/dev/shmを増やす必要がないようにしてください。 |
ファイル・システムの記憶域を使用する事前構成済データベース用に2GBのディスク領域(任意)
自動バックアップを構成する場合は、ファイル・システムまたはOracle Automatic Storage Managementディスク・グループのいずれかに、追加のディスク領域が必要です。
|
関連項目: 『Oracle Databaseストレージ管理者ガイド』 |
トレース・ファイル・アナライザおよびコレクタによって生成された診断収集用に、グリッド・インフラストラクチャ所有者のOracleベース・ディレクトリに最大10GBの追加の領域
システムが各要件を満たしていることを確認するには、次の手順を実行します。
次のコマンドを入力して、物理RAMのサイズを確認します。
# /usr/sbin/lsattr -E -l sys0 -a realmem
システムに搭載されている物理RAMのサイズが要件のサイズより少ない場合、次の手順に進む前にメモリーを増設する必要があります。
次のコマンドを入力して、使用可能なRAMおよびスワップ領域を確認します。
# /usr/sbin/lsps -s
|
注意:
|
次のコマンドを入力して、構成されたスワップ領域のサイズを確認します。
# /usr/sbin/lsps -a
追加のスワップ領域を構成する(必要な場合)方法については、ご使用のオペレーティング・システムのマニュアルを参照してください。
次のコマンドを入力して、/tmpディレクトリで使用できるディスク領域の大きさを確認します。
# /usr/bin/df -k /tmp
/tmpディレクトリで使用できるディスク領域が1GB未満の場合、次のいずれかの手順を完了します。
必要なディスク領域を確保するために、/tmpディレクトリから不要なファイルを削除します。
oracleユーザーの環境設定の際に、環境変数TEMPおよびTMPDIRを設定します。
/tmpディレクトリを含むファイル・システムを拡張します。ファイル・システムの拡張については、必要に応じてシステム管理者に連絡してください。
システム上の空きディスク領域の量を確認します。Oracle Clusterwareファイルを配置する場所に合わせて次のいずれかのコマンドを使用します。
GPFSの場合:
# /usr/bin/df -k
コンカレントVGのRAW論理ボリューム(HACMP)の場合: この例の変数lv_nameは、検証する領域を持つRAW論理ボリューム名です。
# lslv lv_name
RAWハード・ディスクの場合: この例の変数rhdisk#は、検証するRAWハード・ディスク番号であり、変数size_mbは、検証するパーティション・サイズ(MB単位)です。
# lsattr -El rhdisk# -a size_mb
次のコマンドを入力して、システムが64-bitモードで起動されているかどうかを確認します。
# bootinfo -K
このコマンドの結果は、64-bitカーネルが有効であることを示す64になるはずです。
次の項で、クラスタ用Oracle Grid Infrastructure環境に必要なネットワーク・ハードウェアおよびインターネット・プロトコル(IP)・アドレスがあるかを確認します。
|
注意: Oracle RAC環境でサポートされるネットワーク・プロトコルおよびハードウェアの最新情報は、次のMy Oracle Support Webサイトの「動作保証」ページを参照してください。WebサイトのURLは次のとおりです。
|
次にネットワーク構成要件を示します。
各ノードには2つ以上のネットワーク・アダプタまたはネットワーク・インタフェース・カード(NIC)が必要です。1つはパブリック・ネットワーク・インタフェース用、もう1つはプライベート・ネットワーク・インタフェース(インターコネクト)用です。
冗長インターコネクトを使用すると、ボンディングなどのテクノロジを使用しなくても、複数のインタフェースを指定してクラスタ・プライベート・ネットワークに使用します。この機能は、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アドレスを透過的に移動します。
|
注意: プライベート・ネットワーク・インタフェースとして5つ以上のインタフェースを定義した場合は、Oracle Clusterwareが一度にアクティブにするインタフェースは4つのみであることに注意してください。ただし、4つのアクティブなインタフェースのうちの1つに障害が発生した場合は、その障害が発生したインタフェースに構成されたHAIPアドレスを、一連の定義済プライベート・インタフェースのうちの予備インタフェースの1つに移します。 |
ノードをOracle Grid Infrastructure 11gリリース2(11.2.0.2)以上にアップグレードする場合、アップグレードされたシステムは既存のネットワーク分類を使用します。
複数のパブリック・インタフェースを構成するには、ご使用のプラットフォーム用のサード・パーティ・テクノロジを使用して、インストールを開始する前に複数のパブリック・インタフェースを集約する必要があります。その後、結合されたインタフェースの単一のインタフェース名をパブリック・インタフェースとして選択します。Oracle Grid Infrastructureのインストール中に、複数のパブリック・インタフェース名を指定しないことをお薦めします。集約テクノロジを使用せずに、2つのネットワーク・インタフェースをクラスタ内のパブリック・ネットワーク・インタフェースとして構成する場合、ノード上の1つのパブリック・インタフェースで発生した障害によって、もう1つのパブリック・インタフェースへの自動VIPフェイルオーバーが行われることはないことに注意してください。
プライベート・ネットワークに複数のインタフェースを使用するには、冗長インターコネクト機能を使用することをお薦めします。ただし、サード・パーティのテクノロジを使用しても、プライベート・ネットワークを冗長にすることは可能です。
|
注意: 複数のNICを使用するためにNICボンディングは必要ありません。インストール時に、インストーラで検出されたすべてのインタフェースの計画的な使用を指定できます。Oracle Clusterwareは、プライベートと指定されたすべてのNICを、プライベート・インターコネクトとして使用します。冗長インターコネクトを使用する場合、完全な11.2.0.2リリースまたは上位のスタック(Oracle Grid InfrastructureおよびOracleデータベース)が必要です。以前のOracle Databasesのリリースでは、この機能を利用できず、サード・パーティのNICボンディング技術を使用する必要がありました。異なるデータベース・リリースを1つのクラスタで統合し、Oracle Databaseリリース11.2.0.2より前のデータベースを使用する場合は、両方の技術が必要な場合があります。 |
OUIを使用してOracle Clusterwareをインストールする場合は、各ネットワークのネットワーク・アダプタに関連付けるパブリック・インタフェース名は、すべてのノードで同じである必要があり、ネットワーク・アダプタに関連付けるプライベート・インタフェース名もすべてのノードで同じである必要があります。この制限は、新しいクラスタを作成するため、または既存のクラスタにノードを追加するためにクローニングを使用する場合は適用されません。
たとえば、2ノードのクラスタのネットワーク・アダプタの場合、パブリック・インタフェースとしてnode1ではeth0、node2ではeth1というようには構成できません。パブリック・インタフェース名は同じである必要があるため、両方のノードでパブリックとしてeth0を構成する必要があります。同じネットワークのアダプタでは、プライベート・インタフェースも同様に構成する必要があります。eth1がnode1のプライベート・インタフェースであれば、node2のプライベート・インタフェースもeth1である必要があります。
|
関連項目: クローニングを使用してノードを追加する方法の詳細は、『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アドレスと同じサブネット上にある
RFC 952標準に準拠し、英数字とハイフン("-")は使用できるが、アンダースコア("_")は使用できない。
次の特性がある、クラスタの単一クライアント・アクセス名(SCAN):
3つの静的IPアドレスにSCANとして指定された名前が関連付けられ、3つのアドレスすべてがDNSによってリクエスタにランダムな順番で戻されるように、インストール前にその3つのIPアドレスがドメイン・ネーム・サーバー(DNS)に構成されている
インストール前にDNSで構成され、現在は使用されていないアドレスに解決される
数字以外で始まる名前が指定される
他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある
RFC 952標準に準拠し、英数字とハイフン("-")は使用できるが、アンダースコア("_")は使用できない。
次の特性がある、各ノードのプライベートIPアドレス:
静的IPアドレス
インストール前に構成され(ただし、別のプライベート・ネットワーク上で、独自のサブネットを使用)、他のクラスタ・メンバー・ノード以外では解決できない
SCANは、クラスタへのサービス・アクセスをクライアントに提供するために使用される名前です。SCANは、特定のノードではなくクラスタ全体に関連付けされているため、クライアントの再構成を必要とせずに、クラスタでノードを追加または削除することを可能にします。また、データベースに場所の独立性がもたらされるため、クライアント構成は特定のデータベースがどのノードで実行されているかに依存しません。クライアントは引き続き、以前のリリースと同じ方法でクラスタにアクセスできますが、クラスタにアクセスするクライアントではSCANの使用をお薦めします。
|
注意: 標準インストールでは、指定したSCANはクラスタの名前でもあります。拡張インストールでは、SCANとクラスタ名はインストール時に別のフィールドに入力します。SCANおよびクラスタ名は長さ1文字以上15文字以下の英数字である必要があり、数字以外で始める必要があり、ハイフン(-)も使用できます。 |
DNSによってSCANが正しくアドレスに関連付けられていることを確認するには、nslookupコマンドを使用します。次に例を示します。
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またはhostsファイルでのSCANの構成のみがサポートされています。SCANをNetwork Information Service(NIS)で構成することはできません。 |
ブロードキャスト通信(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-1 グリッド・ネーミング・サービスのネットワーク例
| 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-2 手動によるネットワークの構成例
| 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では、インストール中にプライベート・インタフェースとして定義されたインタフェース(en1など)と、プライベート・サブネットに使用されるサブネットに、インターコネクト・アドレスが割り当てられます。
SCANが解決されるアドレスはOracle Clusterwareによって割り当てられるため、特定のノードには固定されません。VIPのフェイルオーバーが有効になるように、前述の表で示した構成では、SCANアドレスと、両方のノードのパブリック・アドレスおよびVIPアドレスが同一のサブネット(192.0.2)上に定義されています。
|
注意: すべてのホスト名はRFC 952標準(英数字を許可)に準拠している必要があります。アンダースコア(_)を使用するホスト名は使用できません。 |
選択する正確なネットワーク構成は、構成するクラスタのサイズおよび使用方法と、必要な可用性のレベルによって異なります。
動作保証されているネットワーク接続ストレージ(NAS)をOracle RAC用に使用し、このストレージにイーサネットベースのネットワークを介して接続する場合は、NAS I/O用に3つ目のネットワーク・インタフェースが必要です。この場合、3つの別々のインタフェースを使用しないと、負荷によってパフォーマンスと安定性の問題が発生します。
インストールする製品に応じて、次のオペレーティング・システム・ソフトウェアがシステムにインストールされていることを確認します。これらの要件を確認するには、第2章「ソフトウェア要件の確認」を参照してください。
ここに記載されている要件は、初回リリース日時点で最新のものです。カーネル要件の最新情報については、Oracle Technology Network(OTN)を参照してください。URLは次のとおりです。
http://www.oracle.com/technetwork/indexes/documentation/index.html
示されているオペレーティング・システム・パッケージの要件をご使用のシステムが満たしていることが、OUIによって検証されます。これらの検証が正常に完了するように、OUIを起動する前に要件を確認してください。
表2-3 AIXオペレーティング・システムのカーネル要件
| 項目 | 要件 |
|---|---|
|
オペレーティング・システム |
AIX 7.2 TL 0 SP 1 ("7200-00-01")以上、64ビット・カーネル AIX 7.1 TL 0 SP1 (" 7100-00-01") 64-Bitカーネル AIX 6.1 TL 02 SP1("6100-02-01")、64ビット・カーネル AIX 5L V5.3 TL 09 SP1("5300-09-01")、64-Bitカーネル以上 |
|
AIX 7.2オペレーティング・システムのファイル・セット |
次のオペレーティング・システムのファイル・セットが必要です。 bos.adt.base bos.adt.lib bos.adt.libm bos.perf.libperfstat bos.perf.perfstat bos.perf.proctools xlC.aix61.rte.13.1.2.0 or later xlC.rte.13.1.2.0 or later インストールには、IBM XL C/C++ランタイム・ファイル・セットが必要ですが、C/C++コンパイラは必要ありません。XL C/C++ランタイム・ファイル・セットのライセンスは必要ありません。 |
|
AIX 7.1オペレーティング・システムのファイル・セット |
次のオペレーティング・システムのファイル・セットが必要です。 bos.adt.base bos.adt.lib bos.adt.libm bos.perf.libperfstat bos.perf.perfstat bos.perf.proctools xlC.rte.11.1.0.2 or later インストールには、IBM XL C/C++ランタイム・ファイル・セットが必要ですが、C/C++コンパイラは必要ありません。XL C/C++ランタイム・ファイル・セットのライセンスは必要ありません。 |
|
AIX 6.1オペレーティング・システムのファイル・セット |
次のオペレーティング・システムのファイル・セットが必要です。 bos.adt.base bos.adt.lib bos.adt.libm bos.perf.libperfstat 6.1.2.1 or later bos.perf.perfstat bos.perf.proctools rsct.basic.rte rsct.compat.clients.rte xlC.aix61.rte.10.1.0.0 or later xlC.rte:10.1.0.0 or later インストールには、IBM XL C/C++ランタイム・ファイル・セットが必要ですが、C/C++コンパイラは必要ありません。XL C/C++ランタイム・ファイル・セットのライセンスは必要ありません。 バージョン: IBM XL C/C++ Enterprise Edition for AIX、V9.0 September 2008 PTF |
|
AIX 5Lオペレーティング・システムのファイル・セット |
次のオペレーティング・システムのファイル・セットが必要です。 bos.adt.base bos.adt.lib bos.adt.libm bos.perf.libperfstat bos.perf.perfstat bos.perf.proctools rsct.basic.rte rsct.compat.clients.rte xlC.aix50.rte:10.1.0.0 (or later) インストールには、IBM XL C/C++ランタイム・ファイル・セットが必要ですが、C/C++コンパイラは必要ありません。XL C/C++ランタイム・ファイル・セットのライセンスは必要ありません。バージョン: IBM XL C/C++ Enterprise Edition for AIX、V9.0 September 2008 PTF |
|
C/C++コンパイラの取得 |
AIX7.1の場合は、My Oracle Supportの証明書で最新の要件を確認してください。証明書は次のURLで入手できます。
Oracle Grid Infrastructureでサポートされている最小のコンパイラはV. 9.0です。このソフトウェアは、次のWebサイトからダウンロードできます。
注意: IBM XL C/C++コンパイラをインストールしない場合でも、AIX Runtime Environment Componentにコンパイラが必要です。ランタイム環境のファイルセットは、ライセンス要件なしにダウンロードすることができます。AIX 5.3およびAIX 6.1の最小推奨ランタイム環境は、次のURLから入手できます。 AIX 5.3およびAIX 6.1の場合: IBM XL C/C++ for AIX, V10.1 Runtime Environment
AIX 7.1の場合: 2010年9月版のRuntime for XL C/C++ for AIX (V11.1)
AIX 7.2の場合: 2015年11月版のRuntime for XL C/C++ for AIX (V13.1) |
|
Oracle RACおよびHACMP |
High Availability Cluster Multi-Processing(HACMP)5.4.1 注意: HACMPが必要となるのは、Oracle Clusterwareまたはデータベース・ファイル記憶域にRAW論理ボリュームを使用する場合のみです。ただし、これはすべてのインストールでサポートされます。OCRまたは投票ディスク・ファイルにRAWデバイスを使用することはできません。 HACMPまたはGPFSを使用する場合は、My Oracle Supportの証明書で最新の要件を確認してください。証明書は次のURLで入手できます。
HACMPを使用しない場合は、システムにHACMPをインストールしないでください。すでにHACMPがインストールされている場合は、次のものを削除する必要があります。
HACMPを使用する場合は、パッチ・セットを確認して、必要なパッチを確実に適用します。HACMP 5.4(5.4.1を含む)のファイル・セット・パッケージの変更には、Oracleの |
|
Oracle RACおよびGPFS |
General Parallel File System(GPFS): AIX 7.1: GPFS 3.3.0.11 AIX 6.1: gpfs.base 3.2.1.8 or later. AIX 5L: gpfs.base 3.2.1.8 or later 注意: GPFSは必須ではありません。GPFSは、Oracle Clusterwareにさらにクラスタ・ファイル・システムが必要な場合のみインストールしてください。 |
|
SSH |
Oracle ClusterwareにはSSHが必要です。必要なSSHソフトウェアは、オペレーティング・システムに付属のデフォルトのSSHです。 |
|
ADA |
OC Systems PowerAda 5.5 AIX7.1の場合は、My Oracle Supportの証明書で最新の要件を確認してください。証明書は次のURLで入手できます。
|
|
JDK |
次のいずれかのバージョンのJavaを使用してください。 Java 6 64-bit 6.0.0.50 IZ30726(SR2) Java 5 64-bit 5.0.0.250 IZ55274 (SR10) AIX7.1の場合は、My Oracle Supportの証明書で最新の要件を確認してください。証明書は次のURLで入手できます。
|
|
Pro*FORTRAN |
IBM XL Fortran v. 11.1 April 2008 PTF for AIX AIX7.1の場合は、My Oracle Supportの証明書で最新の要件を確認してください。証明書は次のURLで入手できます。
|
|
Pro*C/C++、 |
注意: C/C++コンパイラをインストールしない場合でも、インストールにはC/C++ランタイム・ファイル・セットが必要です(この表の「オペレーティング・システムのファイル・セット」を参照)。
AIX7.1の場合は、My Oracle Supportの証明書で最新の要件を確認してください。証明書は次のURLで入手できます。
|
|
Pro*COBOL |
AIX 7.1およびAIX 7.2の場合は、My Oracle Supportの証明書で最新の要件を確認してください。証明書は次のURLで入手できます。
|
|
Oracle Messaging Gateway |
IBM WebSphere MQ for AIX V6.0.2.3、クライアントおよびサーバー mqm.Client.Bnd mqm.Server.Bnd AIX7.1の場合は、My Oracle Supportの証明書で最新の要件を確認してください。証明書は次のURLで入手できます。
|
次のパッチがシステムにインストールされていることを確認します。表の後に、これらの要件を確認する手順を示します。
|
注意:
|
表2-4 AIX APARおよびその他のオペレーティング・システム修正
| インストール・タイプまたは製品 | 要件 |
|---|---|
|
AIX 7.2インストール |
前述のAIX 7.2にオペレーティング・システムの最小TLレベルを使用している場合は、次のAIX 7.2 TL 0 SP1用のAuthorized Problem Analysis Report(APAR)をインストールします。 IV79639 - ライブ・アップデート後、ifixの状態がQのままになる場合があり、再起動が必要です。 IV79848 - 最小およびマイグレーション・インストールでmirrorvg/syncvgが失敗します。 IV80412 - アプリケーションによるシグナル・マスクの設定でシステムがクラッシュします。 注意: IV79441 (procfsを使用した32ビット・プロセス・マップ・ファイルの読取りによるシステム・クラッシュの可能性)に必要な修正を含むIV80412m1aをインストールしてください。 このリリース用に示されている最小レベルより後のTLを使用する場合は、IBMに連絡して、システムにインストールされているTLレベルに、ここに示されている必要なAPARが含まれているかどうかを確認してください。含まれている場合は、インストールする必要はありません。含まれていない場合は、該当するTLレベル用に同等のAPARをインストールする必要があります。 |
|
AIX 7.1のインストール |
前述のAIX 7.1にオペレーティング・システムの最小TLレベルを使用している場合は、次のAIX 7.1 TL 0 SP1用のAuthorized Problem Analysis Report(APAR)をインストールします。 IZ87216 IZ87564 IZ89165 IZ97035 このリリース用に示されている最小レベルより後のTLを使用する場合は、IBMに連絡して、システムにインストールされているTLレベルに、ここに示されている必要なAPARが含まれているかどうかを確認してください。含まれている場合は、インストールする必要はありません。含まれていない場合は、該当するTLレベル用に同等のAPARをインストールする必要があります。 |
|
AIX 6.1のインストール |
このリリース用に示されている最小レベルより後のTLを使用する場合は、IBMに連絡して、システムにインストールされているTLレベルに、ここに示されている必要なAPARが含まれているかどうかを確認してください。含まれている場合は、インストールする必要はありません。含まれていない場合は、該当するTLレベル用に同等のAPARをインストールする必要があります。 前述のAIX 6.1にオペレーティング・システムの最小TLレベルを使用している場合は、次のAIX 6.1 TL 02 SP1用のAuthorized Problem Analysis Report(APAR)をインストールします。 IZ41855 IZ51456 IZ52319 IZ97457 IZ89165 これらの6.1修正は、すでに次のTLレベルに存在します。
このリリース用に示されている最小レベルよりも後のTLレベルを使用している場合、オペレーティング・システムの不具合用の次のパッチを適用します。
オペレーティング・システムのTLレベルに適した次のAPAR番号を使用したパッチをダウンロードします。
|
|
AIX 5Lインストール |
このリリース用に示されている最小レベルより後のTLを使用する場合は、IBMに連絡して、システムにインストールされているTLレベルに、ここに示されている必要なAPARが含まれているかどうかを確認してください。含まれている場合は、インストールする必要はありません。含まれていない場合は、該当するTLレベル用に同等のAPARをインストールする必要があります。 前述のAIX 5Lにオペレーティング・システムの最小TLレベルを使用している場合は、次のAIX 5L V5.3 TL 09 SP1用のAuthorized Problem Analysis Report(APAR)をインストールします。 IZ42940 IZ49516 IZ52331 これらの修正は、すでに次のTLレベルに存在します。
|
|
Oracle JDBC/OCIドライバ AIX 5L v5.3 |
注意: これらのAPARが必要となるのは、関連するJDKバージョンを使用する場合のみです。 JDK 1.4.2(64-bit)に必要なAPAR:
|
|
Oracle ODBCドライバ |
Oracle ClusterwareまたはOracle DatabaseにODBCドライバは必要ありません。 Oracle DatabaseでODBCを使用するには、gcc 3.4.5以上もインストールする必要があります。 AIXでは、Oracle ODBCドライバはODBCドライバ・マネージャ2.2.12について動作保証されています。ドライバ・マネージャは次のリンクからダウンロードしてインストールできます。 |
システムがこれらの要件を満たしていることを確認するには、次の手順を実行します。
次のコマンドを入力して、インストールされているAIXのバージョンを確認します。
# oslevel -r
オペレーティング・システムのバージョンがAIX 5.3未満の場合は、オペレーティング・システムをこのメンテナンス・レベル以上にアップグレードします。AIX 5Lバージョン5.3メンテナンス・パッケージは、次のWebサイトから入手できます。
次のコマンドを入力して、必要なファイル・セットがインストールおよびコミットされているかどうかを確認します。
# lslpp -l bos.adt.base bos.adt.lib bos.adt.libm bos.perf.libperfstat \ bos.perf.perfstat bos.perf.proctools rsct.basic.rte rsct.compat.clients.rte \ xlC.aix61.rte
ファイル・セットがインストールおよびコミットされていない場合は、インストールします。ファイル・セットのインストールについては、ご使用のオペレーティング・システムまたはソフトウェアのマニュアルを参照してください。
システムがこれらの要件を満たしていることを確認するには、次の手順を実行します。
次のコマンドを入力して、必要なAPARがインストールされているかどうかを確認します。
# instfix -i -k "IZ41855 IZ51456 IZ52319"
APARがインストールされていない場合は、次のWebサイトからダウンロードして、インストールします。
http://www-933.ibm.com/support/fixcentral/
次のコマンドを入力して、PTFがインストールされているかどうかを確認します。
# lslpp -l -B U489726 U485561 ...
PTFがインストールされていない場合は、次のWebサイトからダウンロードして、インストールします。
http://www-933.ibm.com/support/fixcentral/
WebSphere MQのCSDが必要な場合は、次のWebサイトでダウンロードおよびインストールの情報を参照してください。
http://www-01.ibm.com/software/
サーバーの予測負荷に対応できる十分なエフェメラル・ポートを提供するために、AIXカーネルのTCP/IPエフェメラル・ポート範囲が十分な大きさになるようにNDDを使用します。Well Knownポートを避け、通常、Oracleとその他のサーバー・ポートが使用する登録済ポートの範囲にあるポートを避けるために、範囲の下限が9000以上になるようにします。ポート範囲は、使用する予定のアプリケーションに予約されているポートを避けるために十分に高く設定します。範囲の下限値が9000より大きく、予測負荷に十分対応するだけの大きさがある場合は、エフェメラル・ポート範囲に関するOUIの警告は無視してかまいません。
次に例を示します。
# /usr/sbin/no -a | fgrep ephemeral
tcp_ephemeral_low = 32768
tcp_ephemeral_high = 65535
udp_ephemeral_low = 32768
udp_ephemeral_high = 65535
上の例で、TCPおよびUDPエフェメラル・ポートはデフォルトの範囲(32768-65536)に設定されています。
高い値のエフェメラル・ポートが必要な負荷になることが予測できる場合は、UDPおよびTCPエフェメラル・ポートの範囲を広くします。次に例を示します。
# /usr/sbin/no -p -o tcp_ephemeral_low=9000 -o tcp_ephemeral_high=65500 # /usr/sbin/no -p -o udp_ephemeral_low=9000 -o udp_ephemeral_high=65500
AIXプラットフォームでは、/etc/security/login.cfgファイルが、システム上のユーザーのリソースを制御および制限します。サービス攻撃の否認を防ぐために、pam.confファイルを通じて認証が行われるようにするため、ログイン時にシステム上のユーザーのリソースの制御および制限を設定する必要があります。
AIXオペレーティング・システムに対して、リソース制限はデフォルトではstd_authに設定されます。uswスタンザのauth_typeをstd_authからpam_authに変更するには、ファイル/etc/security/login.cfgファイルを編集します。
これらのリソース制限が考慮されることを確認するには、login session required /usr/lib/security/pam_aix行が/etc/pam.confに設定されていることを確認します。次に例を示します。
dtsession auth required /usr/lib/security/pam_aix dtlogin session required /usr/lib/security/pam_aix ftp session required /usr/lib/security/pam_aix imap session required /usr/lib/security/pam_aix login session required /usr/lib/security/pam_aix rexec session required /usr/lib/security/pam_aix rlogin session required /usr/lib/security/pam_aix rsh session required /usr/lib/security/pam_aix snapp session required /usr/lib/security/pam_aix su session required /usr/lib/security/pam_aix swrole session required /usr/lib/security/pam_aix telnet session required /usr/lib/security/pam_aix xdm session required /usr/lib/security/pam_aix OTHER session required /usr/lib/security/pam_prohibit websm_rlogin session required /usr/lib/security/pam_aix websm_su session required /usr/lib/security/pam_aix wbem session required /usr/lib/security/pam_aix
すべてのクラスタ・ノードで、次のシステム・チューニングおよび構成を実行します。
|
注意: この項には、パラメータおよびシェル制限の推奨値のみを示します。本番データベース・システムでは、これらの値を調整してシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。 |
AIX 5では、rootpre.shスクリプトを実行して、Asynchronous Input Output(AIO)デバイス・ドライバを有効にします。AIX 6では、AIOデバイス・ドライバはデフォルトで有効になっています。AIX 5とAIX 6の両方で、aioserverプロセスの数をデフォルトから増やします。aio_maxreqsの推奨値は64k(65536)です。AIX 5とAIX 6の両方で、この値を確認してください。
ご使用のリリースごとの手順で、aio_maxreqs値を確認します。
AIX 6.1および7.1:
# ioo -o aio_maxreqs aio_maxreqs = 65536
AIX 5.3:
# lsattr -El aio0 -a maxreqs maxreqs 65536 Maximum number of REQUESTS True
ファイル・システムへの非同期I/Oの実行時、それぞれの非同期I/O操作が1つの非同期I/Oサーバーに関連付けられていることに注意してください。つまり、非同期I/Oサーバーの数によって、システムで同時実行される非同期I/O操作の数が決まります。
システムの再起動時に起動されるサーバーの初期数は、minserversパラメータによって決まります。同時実行される非同期I/O操作が発生すると、最大でmaxserversパラメータに設定した値の追加の非同期I/Oサーバーが起動します。
AIX 5.3でファイル・システムにデータファイルのあるOracle Databaseを使用する場合は、minserversおよびmaxserversのデフォルト値が小さすぎるため、これらの値を増やします。各プロセッサのI/O kprocsに基づいてminserversおよびmaxservers値を増やします。
通常、非同期I/Oサーバーの数を設定するには、次の手順を実行します。
maxserversの初期値を、同時に実行するディスク数の10倍をCPU数で割った値(ただし、80以下)に調整します。
高I/Oアクティビティ期間のシステムのパフォーマンスへの影響を監視します。すべてのAIOサーバー・プロセスが起動したら、maxserversの値を増やします。また、AIOサーバーを追加したことによるメリットがあったかどうかを判断するために、I/Oアクティビティのピーク時のシステム・パフォーマンスも監視し続けます。非同期I/Oサーバーが多すぎると、追加プロセスによるメモリーおよびプロセッサのオーバーロードが増えますが、これによるデメリットはわずかです。AIOパラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。
起動されているAIOサーバー・プロセスの数を監視するには、次のコマンドを入力します。
# ps -ek|grep -v grep|grep –v posix_aioserver|grep -c aioserver
|
注意: AIX 6.1以上では、minserversおよびmaxserversは、それぞれaio_minserversおよびaio_maxserversパラメータに置き換えられています。 |
vmoコマンドを使用して、仮想メモリーで次の値を使用するようにチューニングすることをお薦めします。
表2-5 Virtual Memory Managerの推奨値
| パラメータ | 値 |
|---|---|
|
minperm% |
3(AIX 5.3のデフォルトは20) |
|
maxperm% |
90(AIX 5.3のデフォルトは80) |
|
maxclient% = 90 |
90(AIX 5.3のデフォルトは80) |
|
lru_file_repage |
0(AIX 5.3のデフォルトは1) |
|
strict_maxclient |
1(AIX 5.3のデフォルトは1) |
|
strict_maxperm |
0(AIX 5.3のデフォルトは0) |
次に例を示します。
vmo -p -o minperm%=3 vmo -p -o maxperm%=90 vmo -p -o maxclient%=90 vmo -p -o lru_file_repage=0 vmo -p -o strict_maxclient=1 vmo -p -o strict_maxperm=0
これらの変更を有効にするには、システムを再起動する必要があります。
ARG/ENVリストへの領域割当てを128に増やすことをお薦めしますサイズは4Kブロックの数で指定します。
次に例を示します。
/usr/sbin/chdev -l sys0 -a ncargs='128'
AIXシステムでは、OpenSSHパラメータLoginGraceTimeはデフォルトでコメント・アウトされており、AIXでのOpenSSHのデフォルトの動作は、タイムアウト・エラーになる場合があります。これらのエラーを回避するには、次の手順を実行します。
rootユーザーでログインします。
テキスト・エディタを使用して、OpenSSH構成ファイル/etc/ssh/sshd_configを開きます。
コメント行#LoginGraceTime 2mを検索します。
その行をコメント解除して、値を0(無制限)に変更します。次に例を示します。
LoginGraceTime 0
/etc/ssh/sshd_configを保存します。
SSHを再起動します。
Oracle Grid Infrastructureのインストール所有者およびrootのシェル制限を設定します。smitユーティリティを使用するか、/etc/security/limitsファイルを編集し、両方のアカウントが無制限に設定されていることを確認します。crsデーモン(crsd)はrootで実行されるため、rootユーザーにはこれらの設定が必要です。
| シェル制限 | limits.conf内の項目 | ハード制限 |
|---|---|---|
| オープン・ファイル記述子の最大数 | nofile |
-1(無制限) |
| ユーザー1人当たりに使用可能なプロセスの最大数 | nproc |
-1(無制限) |
| プロセスのスタック・セグメントの最大サイズ | stack |
-1(無制限) |
/etc/security/limitsファイルに、次の行を追加します。
default:
fsize = -1
core = 2097151
cpu = -1
data = -1
rss = -1
stack = -1
nofiles = -1
次のコマンドを入力して、Oracleソフトウェア・ユーザーに許可されている現在の最大プロセス数をリストします。
/usr/sbin/lsattr -E -l sys0 -a maxuproc
必要に応じて、次のコマンドを使用してmaxuproc設定を変更します。
/usr/sbin/chdev -l sys0 -a maxuproc=16384
クラスタの他のすべてのノードで、この手順を繰り返します。
|
注意: ご使用のオペレーティング・システム・ベンダーでサポートされているシェル・プログラムを使用してください。ご使用のオペレーティング・システムでサポートされていないシェル・プログラムを使用すると、インストール中にエラーが発生する場合があります。 |
各ユーザーに許可されているプロセスの最大数が2048以上であることを確認します。
|
注意: 本番システムの場合、この値は、システムで実行している各データベースのPROCESSESおよびPARALLEL_MAX_SERVERS初期化パラメータの合計に128を加算した値以上である必要があります。 |
次のコマンドを入力します。
# smit chgsys
「Maximum number of PROCESSES allowed for each user」に表示される値が2048以上であることを確認します。
必要に応じて既存の値を編集します。
変更が完了したら、[Enter]を押した後、[Esc]+[0]を押して終了します。
次の表に示すネットワーク・チューニング・パラメータが、表に示されている値以上に設定されていることを確認します。表の後に、値を確認して設定する手順を示します。
| ネットワーク・チューニング・パラメータ | 推奨値 |
|---|---|
| ipqmaxlen | 512 |
| rfc1323 | 1 |
| sb_max | 4194304 |
| tcp_recvspace | 65536 |
| tcp_sendspace | 65536 |
| udp_recvspace | 655360
注意: このパラメータの推奨値は、udp_sendspaceパラメータの値の10倍です。これは、sb_maxパラメータの値より小さい値である必要があります。 |
| udp_sendspace | 65536
注意: この値は、デフォルトのデータベース・インストールに適しています。本番データベースの場合、このパラメータの最小値は、データベースの ( |
これらのパラメータに指定されている現行の値を表示し、必要に応じて変更するには、次の手順を実行します。
次のコマンドを入力して、ネットワーク・チューニング・パラメータの現行の値を確認します。
# no -a | more
パラメータの値を変更する必要がある場合は、次のコマンドを入力し、システムが互換性モードで実行されているかどうかを確認ます。
# lsattr -E -l sys0 -a pre520tune
システムが互換性モードで実行されている場合、出力は次のようになり、pre520tune属性の値がenableであることが示されます。
pre520tune enable Pre-520 tuning compatibility mode True
システムが互換性モードで実行されている場合は、次の手順に従って、パラメータの値を変更します。
次のコマンドを入力して、各パラメータの値を変更します。
# no -o parameter_name=value
次に例を示します。
# no -o udp_recvspace=655360
前述の手順で変更した各パラメータの/etc/rc.netファイルに、次のエントリを追加します。
if [ -f /usr/sbin/no ] ; then /usr/sbin/no -o udp_sendspace=65536 /usr/sbin/no -o udp_recvspace=655360 /usr/sbin/no -o tcp_sendspace=65536 /usr/sbin/no -o tcp_recvspace=65536 /usr/sbin/no -o rfc1323=1 /usr/sbin/no -o sb_max=4194304 /usr/sbin/no -o ipqmaxlen=512 fi
これらの行を/etc/rc.netファイルに追加すると、システムの再起動時に値が保持されます。
システムを再起動せずにRFC1323値を設定することもできます。
chdev -l en5 -a rfc1323=1
システムが互換性モードで実行されていない場合は、次のコマンドを入力して、パラメータの値を変更します。
ipqmaxlenパラメータ:
/usr/sbin/no -r -o ipqmaxlen=512
その他のパラメータの場合:
/usr/sbin/no -p -o parameter=value
|
注意: ipqmaxlenパラメータを変更した場合は、システムを再起動する必要があります。 |
これらのコマンドによって/etc/tunables/nextbootファイルが変更され、システムの再起動時に属性の値が保持されるようになります。
パラメータを変更する必要があり、システムを再起動しない場合は、noグローバル設定の変更後、ifconfigコマンドを使用し、各ネットワーク・パラメータを確認します。
次に例を示します。
# ifconfig en0
en0:
flags=1e080863,2c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,6
4BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN,MONITOR>
inet 192.0.2.1 netmask 0xfffff800 broadcast 192.0.2.0
inet 192.0.2.2 netmask 0xfffff800 broadcast 192.0.2.0
inet 192.0.2.3 netmask 0xfffff800 broadcast 192.0.2.0
inet 192.0.2.4 netmask 0xfffff800 broadcast 192.0.2.0
tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0
ISNOパラメータtcp_sendspaceの設定には、次のコマンドを使用します。
# ifconfig en0 tcp_sendspace 65536
|
関連項目: 使用しているシステムに合わせAIXパラメータを調整する方法の詳細は、IBMのマニュアルを参照してください。 |
Oracle Clusterwareでは、すべてのクラスタ・ノードで同じのタイムゾーン設定が必要です。インストール中に、インストール・プロセスは、OUIを実行しているノードでグリッド・インストール所有者のタイムゾーン設定を選択し、Oracle Clusterwareによって管理されるすべてのプロセスのデフォルトのTZ設定として、すべてのノードでその設定を使用します。このデフォルトは、データベース、Oracle ASMおよびその他の管理プロセスで使用されます。
時刻を同期させるための手段は2つあります。オペレーティング・システムに構成されているネットワーク・タイム・プロトコル(NTP)と、Oracleクラスタ時刻同期化サービスです。Oracleクラスタ時刻同期化サービスは、クラスタ・サーバーからNTPサービスにアクセスできない組織のために設計されています。NTPを使用する場合は、Oracle Cluster時刻同期化デーモン(ctssd)は、オブザーバ・モードで起動します。NTPデーモンがない場合、ctssdはアクティブ・モードで起動し、外部時間サーバーに接続しなくても、クラスタ・メンバー間で時刻を同期します。
|
注意: Oracle Grid Infrastructureのインストールを開始する前に、すべてのノードの時計が同じ時刻になっていることを確認することをお薦めします。 |
サーバー上にNTPデーモンがあっても時間サーバーの時刻と同期されるように構成できない場合に、クラスタ時刻同期化サービスを使用してクラスタ内で同期化サービスを提供する場合は、NTPを非アクティブにし、削除します。
NTPサービスを無効にするには、次のコマンドをrootユーザーとして実行します。
# stopsrc -s xntpd
NTPプロトコルがアクティブでないとインストーラによって判断されると、クラスタ時刻同期化サービスがアクティブ・モードでインストールされ、ノード間で時刻が同期されます。NTPが構成されていると判断された場合は、クラスタ時刻同期化サービスはオブザーバ・モードで起動され、クラスタ内でOracle Clusterwareによるアクティブな時刻同期化は行われません。
インストール後にctssdがアクティブになっていることを確認するには、グリッド・インストール所有者として次のコマンドを入力します。
$ crsctl stat resource ora.ctssd -t -init
NTPを使用しており、クラスタ時刻同期化サービスではなくNTPを使用し続ける場合は、NTP初期化ファイルを変更してスルーイングを有効にし、逆向きの時間調整が行われないようにします。この作業が終わった後で、ネットワーク・タイム・プロトコル・デーモンを再起動します。
AIXでこれを行うには、ファイル/etc/rc.tcpipを編集し、システムが再起動するたびにXNTPデーモンが起動するように構成します。
/etc/rc.tcpipファイルを開き、次の行を検索します。
start /usr/sbin/xntpd "$src_running"
この行を次の行に変更します。
start /usr/sbin/xntpd "$src_running" "-x"
ファイルを保存します。
無効にしたXNTPを有効にするには、各クラスタ・メンバー・ノードで次のコマンドを入力します。
# startsrc -s xntpd -a "-x"
Oracleソフトウェアをインストールするには、すべてのクラスタ・メンバー・ノード間にセキュア・シェル(SSH)の接続が設定されている必要があります。OUIは、インストール中にsshおよびscpコマンドを使用して、他のクラスタ・ノードに対してリモート・コマンドを実行し、そのクラスタ・ノードにファイルをコピーします。これらのコマンドを使用する際にパスワードを求めるプロンプトが表示されないように、SSHを構成する必要があります。
|
注意: SSHは、Oracle Configuration Assistantによる、ローカル・ノードからリモート・ノードに対する構成操作に使用されます。Oracle Enterprise Managerでも使用されます。 |
Oracle Universal Installer(OUI)インタフェースから、インストール中に、インストールを実行しているユーザー・アカウントにSSHを構成することができます。自動構成によって、パスワードなしのSSH接続をすべてのクラスタ・メンバー・ノード間に作成することができます。可能なかぎり、この自動手順を利用することをお薦めします。
スクリプトを実行できるようにするには、すべてのOracleソフトウェア・インストール所有者のプロファイルからsttyコマンドを削除するとともに、ログイン時にトリガーされる他のセキュリティ手段で、端末に対してメッセージを生成するものを削除する必要があります。これらのメッセージやメール・チェックなどが表示されていると、Oracleソフトウェア・インストール所有者は、Oracle Universal Installerに組み込まれているSSH構成スクリプトを使用できません。これらの表示が無効になっていない場合は、SSHを手動で構成してからでなければ、インストールを実行できません。
デフォルトでは、OUIはディレクトリ/usr/local/etc/でSSH公開鍵、/usr/local/binでssh-keygenバイナリを検索します。ただし、AIXの場合、SSH公開鍵は通常はパス/etc/sshにあり、ssh-keygenバイナリはパス/usr/binにあります。OUIでSSHを設定できるようにするには、次のコマンドを使用してソフト・リンクを作成します。
# ln -s /etc/ssh /usr/local/etc # ln -s /usr/bin /usr/local/bin
まれに、リモート・ノードがSSH接続を閉じると、「AttachHome」操作時にOracle Clusterwareインストールが失敗する場合があります。この問題を回避するために、すべてのクラスタ・ノードでSSHデーモン構成ファイル/etc/ssh/sshd_configに次のパラメータを設定し、タイムアウト待機時間を無制限に設定します。
LoginGraceTime 0
インストーラ・ソフトウェアは、Oracle Grid Infrastructureインストール所有者ユーザー・アカウント(oracleまたはgrid)で実行します。ただし、インストーラを起動する前に、インストール所有者ユーザー・アカウントの環境を構成する必要があります。また、必要に応じて、他の必要なOracleソフトウェア所有者を作成します。
この項の内容は次のとおりです。
Oracle Grid Infrastructureソフトウェア所有者の環境を構成するには、次の変更を行う必要があります。
Oracle DatabaseまたはOracle ASMをインストールする場合は、次の追加タスクを実行します。ロールベースの権限メソッドを使用して他のソフトウェアをインストールする場合は、Oracle Databaseソフトウェア所有者(oracle)およびOracle ASMソフトウェア所有者(asm)に対し、次のタスクを実行します。
Oracleベースのパスを作成します。OracleベースのOptimal Flexible Architectureパスは、/u01/app/userです。userは、Oracle Databaseソフトウェアを所有するユーザー・アカウントの名前です。たとえば、/u01/app/oracleです。
|
注意: Oracle ClusterwareホームをOracleベースに作成しないでください。Oracleベース・ディレクトリのパスにOracle Clusterwareインストールを作成すると、その後のOracleインストールが失敗します。 |
シェル起動ファイルで、インストール・ソフトウェア所有者ユーザー(asm、oracle)のデフォルトのファイル・モード作成マスク(umask)を022に設定します。 マスクを022に設定すると、ソフトウェア・インストールを実行するユーザーが作成するファイルの権限は常に644になります。
Oracle ASMまたはOracle Databaseをインストールする準備として、ソフトウェア所有者の環境変数に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
次のように行を入力または編集して、デフォルトのファイル・モード作成マスクの値に022を指定します。
umask 022
環境変数ORACLE_SID、ORACLE_HOMEまたはORACLE_BASEがファイルに設定されている場合は、そのファイルから適切な行を削除します。
ファイルを保存して、テキスト・エディタを終了します。
シェル起動スクリプトを実行するには、次のいずれかのコマンドを入力します。
Bourne、BashまたはKornシェル:
$ . ./.profile
Cシェル:
% source ./.login
ローカル・システムにソフトウェアをインストールしていない場合は、次のコマンドを入力してXアプリケーションをローカル・システムに表示します。
Bourne、BashまたはKornシェル:
$ DISPLAY=local_host:0.0 ; export DISPLAY
Cシェル:
% setenv DISPLAY local_host:0.0
この例で、local_hostは、OUIを表示するためのシステム(ご使用のワークステーションまたはPC)のホスト名またはIPアドレスです。
/tmpディレクトリの空き領域が1GB未満である場合は、空き領域が1GB以上のファイル・システムを選択し、環境変数TEMPおよびTMPDIRを設定してこのファイル・システムの一時ディレクトリを指定します。
|
注意: Oracle RACのインストール用の一時ファイル・ディレクトリ(通常、/tmp)の場所として、共有ファイル・システムは使用できません。共有ファイル・システムに/tmpを配置すると、インストールは失敗します。 |
必要に応じて、次のコマンドを入力し、選択したファイル・システムに一時ディレクトリを作成して、そのディレクトリに適切な権限を設定します。
$ su - root # mkdir /mount_point/tmp # chmod 775 /mount_point/tmp # exit
次のコマンドを入力して、環境変数TEMPおよびTMPDIRを設定します。
Bourne、BashまたはKornシェル:
$ TEMP=/mount_point/tmp $ TMPDIR=/mount_point/tmp $ export TEMP TMPDIR
Cシェル:
% setenv TEMP /mount_point/tmp % setenv TMPDIR /mount_point/tmp
リモート端末で作業を行っていて、そのローカル・ノードのみが表示されている場合(通常は、この状態になります)、次の構文を使用して、環境変数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でのすべての出力が停止されるように、次の手順に従って、Oracleインストール所有者ユーザーのホーム・ディレクトリにあるこれらのファイルを変更する必要があります(sttyやxtitleなどのコマンド)。
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 コマンドのかわりに rsh および rcp を使用します。リモート・シェルによってロードされる隠しファイルに |
|
注意: このシステムに、より新しいリリースのOracleデータベース・ソフトウェアをすでにインストールしている場合は、rootpre.shスクリプトを実行しないでください。 |
rootpre.shスクリプトは、次の手順で実行します。
ユーザーをrootに切り替えます。
$ su - root
インストールの場所に応じて、次の手順のいずれかを実行します。
インストール・ファイルがディスクにある場合は、次のコマンドを入力します。directory_pathは、ディスク・マウント・ポイント・ディレクトリまたはDVDのデータベース・ディレクトリのパスです。
# /directory_path/rootpre.sh
インストール・ファイルがハード・ディスクにある場合は、ディレクトリをDisk1ディレクトリに変更し、次のコマンドを入力します。
# ./rootpre.sh
rootアカウントを終了します。
# exit
クラスタのすべてのノードで手順1から3を繰り返します。
|
注意: このシステムに、より新しいリリースのOracleデータベース・ソフトウェアをすでにインストールしている場合は、rootpre.shスクリプトを実行しないでください。 |
システムにHACMPをインストール済の場合は、rootpre.shコマンドによってhagsuserグループが作成されます。グリッド・インフラストラクチャのインストール所有者(grid)をそのグループのメンバーにする必要があります。
次のようなコマンドを入力して、Oracle Grid Infrastructure所有者(grid)をhaguserに追加します。
# /usr/bin/chgrpmem -m + grid hagsuser
Oracle Grid Infrastructureインストール所有者をhagsuserグループに追加した後、Oracle Grid Infrastructureで使用する前に、HACMPを停止して再起動します。
インストール中に、Oracle Clusterwareバイナリを格納するホーム・ディレクトリへのパスを指定するように求められます。指定するディレクトリ・パスが次の要件を満たすことを確認します。
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名には適用されません。
