この章では、クラスタ用のOracle Grid InfrastructureとOracle Real Application Clustersをインストールする前に完成させるユーザー、グループ・ユーザー環境および管理環境の設定について説明します。
この章の内容は次のとおりです。
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 Grid Infrastructureインストールの場合、中央インベントリはノード上のローカル記憶域にある必要があります。
既存の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インベントリの場所を示します。
inst_group
パラメータは、Oracleインベントリ・グループ名(この例ではoinstall
)を示します。
Oracle Inventoryグループ・メンバーにHP-UXのRTPRIO、MLOCKおよびRTSCHED権限が付与されていることを確認します。次に例を示します。
# /usr/bin/getprivgrp oinstall oinstall: RTPRIO MLOCK RTSCHED
グループにこれらの権限が付与されていない場合は、次の項の説明に従って権限を追加します。
oraInst.loc
ファイルが存在しない場合は、次の手順を実行します。
次のようなコマンドを入力して、Oracle Inventoryグループを作成します。
# /usr/sbin/groupadd -g 54321 oinstall
このコマンドによって、グループID番号が54321の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ソフトウェアに作成されるユーザーに対して、次の制限事項を確認してください。
異なるOracle Databaseホームに対して複数のOracleソフトウェア所有者を使用する場合は、Oracle Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)ソフトウェアに対して別途ソフトウェア所有者を作成し、その所有者でOracle Grid Infrastructureをインストールすることをお薦めします。
インストール中に、クラスタ・メンバー・ノード間にSSHを設定する必要があります。SSHは、Oracle Universal Installer (インストーラ)によって自動で設定できます。SSHの自動設定を有効にするには、プロファイルにstty
コマンドがないOracleインストール所有者を作成し、ログイン中にトリガーされて端末へのメッセージを生成する他のセキュリティ対策を削除します。これらのメッセージやメール・チェックなどが表示されていると、Oracleソフトウェア・インストール所有者アカウントは、インストーラに組み込まれているSSH構成スクリプトを使用できません。これらの表示が無効になっていない場合は、SSHを手動で構成してからでなければ、インストールを実行できません。
Oracle DatabaseまたはOracle RACをインストールする予定がある場合は、Oracle Grid InfrastructureおよびOracle Databaseのインストール・ユーザーを別々に作成することをお薦めします。使用するインストール所有者が1つの場合は、管理タスクを実行するときに、$ORACLE_HOME
の値を管理対象のインスタンス(Oracle ASM、Oracle Grid Infrastructureホーム内、またはOracleホームのデータベース)に変更する必要があり、その際のコマンド構文の例は次のようになります(ここで、/u01/app/12.1.0/grid
はOracle Grid Infrastructureホームです)。
$ ORACLE_HOME=/u01/app/12.1.0/grid; export ORACLE_HOME
環境変数$ORACLE_HOME
に異なるOracleホームまたはGridホーム・パスが設定されている一方で、sqlplus
、lsnrctl
またはasmcmd
コマンドを使用してOracleホームまたはGridホーム・インスタンスを管理しようとすると、エラーが発生します。たとえば、データベース・ホームからSRVCTLを開始する場合は$ORACLE_HOME
にそのデータベース・ホームを設定する必要があり、そうしないと、SRVCTLが失敗します。ただし、Oracle Grid InfrastructureホームでSRVCTLを使用する場合は例外です。その場合、$ORACLE_HOME
は無視され、Oracleホーム環境変数はSRVCTLコマンドに影響を与えません。その他のすべての場合は、$ORACLE_HOME
を管理対象のインスタンスに変更する必要があります。
別のOracleソフトウェア所有者を作成して、Oracleソフトウェア・インストールごとに、オペレーティング・システム権限グループを分離するには、各ユーザーのプライマリ・グループとして、Oracle中央インベントリ・グループ(oraInventoryグループ)が設定されている必要があります。このグループのメンバーにはOracle中央インベントリ(oraInventory
)ディレクトリに書き込むための、OINSTALLシステム権限が付与され、様々なOracle Clusterwareリソース、OCRキー、DBAが書込みアクセスを必要とするOracle Clusterwareホーム内のディレクトリに対する権限やその他の必要な権限も付与されます。Oracleドキュメントのコード・サンプルでは、このグループはoinstall
と表されています。
各Oracleソフトウェア所有者は、すべてのOracleソフトウェア・インストール所有者が同じOINSTALLシステム権限を共有するように、同じ中央インベントリoraInventoryグループのメンバーである必要があり、また、このグループをプライマリ・グループとして持つ必要があります。Oracleインストールに対して複数の中央インベントリを使用しないことをお薦めします。あるOracleソフトウェア所有者が別の中央インベントリ・グループを持っている場合、その中央インベントリは破損することがあります。
oracle
やgrid
というOracleソフトウェア所有者ユーザーが存在するかどうかを確認するには、次のようなコマンドを入力します(この場合、oracle
の存在を確認します)。
# id oracle
ユーザーが存在する場合、このコマンドの出力結果は、次のようになります。
uid=54421(oracle) gid=54321(oinstall) groups=54322(dba),54323(oper)
既存ユーザーを使用するか、別のユーザーを作成するかを決定します。ユーザーIDおよびグループIDの番号は、クラスタ・メンバー・ノードにする各ノード上で同一である必要があります。
既存ユーザーを使用する場合は、ユーザーのプライマリ・グループがOracle Inventoryグループ(oinstall
)であることを確認します。
Oracleソフトウェア所有者ユーザー(oracle
、grid
)が存在しない、または新しいOracleソフトウェア所有者ユーザーが必要な場合は作成します。既存のユーザー・アカウントを使用する場合は、各クラスタ・メンバー・ノードでユーザーIDおよびグループIDが一致していることを確認します。
デフォルトで割り当てられたUIDおよびGIDはノードごとに異なる可能性があるため、各ノードでデフォルト値を使用しないことをお薦めします。かわりに、特別に指定して番号を付けたUIDおよびGIDを決定し、グループまたはユーザーを作成または変更する前に、他のノードでそれらが使用されていないことを確認します。インストールを開始する前に、クラスタ・メンバー・ノードにする予定の各ノードのユーザー構成が同一で、UIDおよびGIDは変更する必要がないことを確認することをお薦めします。OracleソフトウェアのユーザーおよびグループのUIDおよびGIDを変更する必要がある場合、ソフトウェアを再インストールする必要があります。
Oracle RACまたはOracle Grid Infrastructureをインストールおよび構成するために以前使用したユーザー・アカウントのUID、GID、グループ・メンバーシップの変更はサポートされていません。あるOracleユーザーから別のユーザーに既存のOracle Databaseホームの所有者を変更することはサポートしていません。
Oracle Grid Infrastructureを一度インストールした後に既存のGridインストールの所有者を変更する必要がある場合(たとえば、Oracle Grid Infrastructure所有者とOracle RAC Oracle Database所有者ユーザー・アカウントを区別するために、Oracle RACをインストールする前に既存のOracle Databaseユーザー・アカウントを変更したい場合)、各ノードで(ローリング方式で)Oracle Clusterwareを停止後に開始してOracle Grid Infrastructureを所有するユーザー・アカウントに対して行われた変更を取得する必要があります。
次の手順では、Oracleソフトウェア所有者の名前としてgrid
が、OSASMグループとしてasmadmin
が使用されています。異なる管理権限に対して個別のシステム権限グループを作成するには、ユーザーを作成する前に、グループ作成を完了します(第5.1.7項「役割区分によるオペレーティング・システム権限グループおよびユーザーについて」を参照)。
既存のシステム権限グループ(この例ではdba
)がある場合にグリッド・インストール所有者アカウントを作成し、グループのメンバーにOracle ASMインスタンスを管理するためのSYSASM
権限を付与する場合、次のようなコマンドを入力します。
# /usr/sbin/useradd -u 54321 -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 54421 -g 54331 -G 54321,54322,54327 oracle # id oracle uid=54421(oracle) gid=54331(oinstall) groups=54321(oinstall),54322(dba),54327 (asmdba)
Oracle Grid Infrastructureを所有するユーザーのパスワードを設定します。次に例を示します。
# passwd grid
他のすべてのクラスタ・ノードでこの手順を繰り返します。
注意: 既存ユーザーを使用または変更する前に、必要に応じて、システム管理者に連絡してください。 |
Oracle Grid InfrastructureインストールのOracleベース・ディレクトリは、Oracle ASMおよびOracle Clusterwareに関する診断ログ、管理ログおよびその他のログが格納される場所です。クラスタのOracle Grid Infrastructureを除くOracleインストールの場合、Oracleホームが配置される場所でもあります。
ただし、Oracle Grid Infrastructureインストールの場合は、別のパスを作成し、Oracleベースのパスをその他のOracleインストールが使用できるようにする必要があります。
OUIがOracleベース・パスを認識するには、u[00-99][00-99]/appという形式にし、oraInventory(oinstall
)グループのすべてのメンバーによる書込みを可能にする必要があります。OracleベースのOFAパスはu[00-99][00-99]/app/
user
で、user
はソフトウェア・インストール所有者の名前です。次に例を示します。
/u01/app/grid
Oracle Grid Infrastructureソフトウェア用Oracleホーム(Gridホーム)は、他のOracleソフトウェアのOracleホーム・ディレクトリのパスとは異なるパスにある必要があります。Optimal Flexible Architectureガイドラインでは、Gridホームには、/pm/v/uの形式のパスを作成することとされています(ここで、/pは文字定数、/mは一意な固定長キー(通常は2桁の数字)、/vはソフトウェアのバージョン、/uはOracle Grid Infrastructureソフトウェアのインストール所有者(Gridユーザー)です)。クラスタに対してOracle Grid Infrastructureをインストールする際に、Gridホームのパスはroot
ユーザーに変更されるため、その他のユーザーがパス内のコマンドを読取り、書込みまたは実行することはできません。
たとえば、標準のマウント・ポイント形式のu[00-99][00-99]/app/release/gridでGridホームを作成するには(ここで、releaseはOracle Grid Infrastructureソフトウェアのリリース番号です)、次のパスを作成します。
/u01/app/12.1.0/grid
インストール中に、Gridホームへのパス全体の所有者がroot
に変更されます(/u01
、/u01/app
、/u01/app/12.1.0
、/u01/app/12.1.0/grid
)。Gridホームへの一意のパスを作成しない場合は、グリッドのインストール後に、同じパスにある既存のインストールを含むその他のインストールの権限エラーが発生します。
rootが所有するマウント・ポイントにアプリケーション・ディレクトリを配置することを避けるには、Gridホーム用に次などのパスを作成および選択できます。
/u01/12.1.0/grid
関連項目: Optimal Flexible Architecture (OFA)のガイドラインの詳細については、『Oracle Databaseインストレーション・ガイド』を参照してください。 |
Oracle Grid Infrastructureインストール所有者のログ・ファイルを別のOracleベースに分離できるようにし、Oracleベースのパスの下にGridホームが誤って配置されないようにするために、Oracle Grid InfrastructureのGridホームおよびOracleベース・ホームは手動で作成することをお薦めします(特に、クラスタ用Oracle Grid InfrastructureおよびOracle Databaseソフトウェア所有者が別の場合にお薦めします)。
次に例を示します。
# mkdir -p /u01/app/12.1.0/grid # mkdir -p /u01/app/grid # mkdir -p /u01/app/oracle # chown -R grid:oinstall /u01 # chown oracle:oinstall /u01/app/oracle # chmod -R 775 /u01/
Oracle DatabaseとOracle ASMの役割区分の構成は、オペレーティング・システム認証の個別のグループを提供するためのグループおよびユーザーを作成する構成です。
Oracle Databaseの役割区分では、各Oracle Databaseインストールが別個のオペレーティング・システム・グループを保持して、そのOracle Databaseでのシステム権限の認証を提供することにより、システム権限のオペレーティング・システム認証を共有することなく、クラスタに複数のデータベースをインストールできるようになります。また、各Oracleソフトウェア・インストールを別々のインストール所有者が所有することで、Oracle Databaseバイナリへの変更に対してオペレーティング・システム・ユーザー認証が提供されます。
Oracle Grid Infrastructureの役割区分では、Oracle ASMは別々のオペレーティング・システム・グループを持ち、記憶域層の管理に関するOracle ASMシステム権限のオペレーティング・システム認証を提供します。このオペレーティング・システム認証は、Oracle Databaseオペレーティング・システム認証から分離されています。また、Oracle Grid Infrastructureインストール所有者は、Oracle Grid Infrastructureバイナリへの変更に対してオペレーティング・システム・ユーザー認証を提供します。
Oracle Databaseのインストール中に、Oracle Universal Installer (OUI)から、OSDBA、OSOPER、OSBACKUPDBA、OSDGDBAおよびOSKMDBAグループの名前を指定するように求められます。これらのグループのメンバーには、各グループが認可するデータベース・システム権限セットに対するオペレーティング・システム認証が付与されます。システム権限のセットごとに、異なるオペレーティング・システム・グループを作成することをお薦めします。
注意: この構成はオプションで、Oracleソフトウェアに対するユーザー・アクセスを、様々な管理者ユーザーの役割に応じて制限するための構成です。 |
記憶域層およびデータベース層のすべてのシステム権限のオペレーティング・システム認証に対して、1つの管理ユーザーと1つのグループを作成することもできます。
たとえば、oracle
ユーザーをすべてのOracleソフトウェアのインストール所有者として指定し、oinstall
グループのメンバーにOracle Clusterwareのすべてのシステム権限、Oracle ASMのすべてのシステム権限、サーバー上のすべてのOracle Databaseに対するすべてのシステム権限、およびインストール所有者のすべてのOINSTALLシステム権限を付与することを指定できます。このグループは、Oracleインベントリ・グループでもあります。
ロール割当てをしたグループを使用しない場合は、2つ以上のグループを使用することを強くお薦めします。
システム権限グループ: OSDBA、OSASM、その他のシステム権限グループなどがあり、そのメンバーには管理システム権限が付与されます。
インストール所有者グループ(oraInventoryグループ): メンバーには、Oracleインストール所有者システム権限(OINSTALLシステム権限)が付与されます。
クラスタ検証ユーティリティなどの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ソフトウェア製品ごとに、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、OSBACKUPDBA、OSDGDBAおよびOSKMDBAグループが必要です。Oracleドキュメントでは、Oracleソフトウェア所有者ユーザーをoracle
ユーザーとします。
ソフトウェア所有者ユーザーを個別に作成し、各Oracleソフトウェア・インストールの所有者にすることをお薦めします。特に、システムに複数のデータベースをインストールする場合にお薦めします。
Oracleドキュメントでは、Oracle Grid Infrastructureバイナリを所有するために作成されたユーザーをgrid
ユーザーとします。このユーザーは、Oracle ClusterwareとOracle Automatic Storage Managementの両方のバイナリを所有します。
関連項目: オペレーティング・システム・グループおよびシステム権限認証の詳細は、『Oracle Database Storage管理者ガイド』および『Oracle Database管理者ガイド』を参照してください。 |
標準Oracle Databaseグループのリストを次に示します。これらのグループは、データベース管理システム権限のオペレーティング・システム認証を提供します。
Oracle Databaseソフトウェアをシステムに初めてインストールする場合は、このグループを作成する必要があります。このグループのオペレーティング・システム・ユーザー・アカウントには、データベースの管理権限(SYSDBA権限)があります。Oracle ASMインスタンスに個別のOSDBA、OSOPERおよびOSASMグループを作成しない場合は、SYSOPERおよびSYSASM権限を持つオペレーティング・システム・ユーザー・アカウントが、このグループのメンバーである必要があります。Oracleコードの例で使用されるこのグループ名はdba
です。OSASMグループとして個別のグループを指定しない場合は、定義するOSDBAグループもデフォルトでOSASMとなります。
デフォルト(dba
)以外のグループ名を指定するには、拡張インストール・タイプを選択してソフトウェアをインストールするか、またはこのグループのメンバーではないユーザーとしてOracle Universal Installer (OUI)を起動する必要があります。dba
と呼ばれるグループのメンバーではないユーザーでOUIを開始すると、OSDBAグループの名前を指定するようにOUIから求められます。
以前は、OSDBAグループのメンバーにOracle ASMインスタンスのSYSASM権限(ディスク・グループのマウントおよびマウント解除を含む)が付与されていました。Oracle Grid Infrastructure 11g リリース2 (11.2)の場合、別々のオペレーティング・システム・グループがOSDBAとOSASMグループとして指定されているときには、この権限が付与されません。同じグループが、OSDBAとOSASMの両方に使用されている場合は、権限がそのまま保持されます。
Oracle DatabaseのOSOPERグループ(通常、oper
)
データベースを起動および停止するためのデータベース管理権限の一部(SYSOPER
権限)を持つ別個のオペレーティング・システム・ユーザー・グループが必要な場合は、このグループの作成を選択できます。
Oracle Database 12cリリース1 (12.1)からは、データベースを起動および停止するためのOSOPER権限に加えて、日常のデータベース操作に必要な特定の管理権限タスクをサポートする、よりタスク固有で、OSDBA/SYSDBAシステム権限より権限の少ない新しい管理権限を作成できます。ユーザーが付与したこれらのシステム権限は、オペレーティング・システム・グループ・メンバーシップを通じても認証されます。
これらの特定のグループ名を作成する必要はありませんが、インストール中にオペレーティング・システム・グループを指定するように求められます(そのメンバーに、これらのシステム権限へのアクセス権が付与されます)。同じグループを、これらの権限の認証を提供するために割り当てることができますが、各権限の指定には固有のグループを提供することをお薦めします。
OSDBAサブセット役割区分の権限およびグループは、次のもので構成されます。
Oracle Database用のOSBACKUPDBAグループ(通常、backupdba
)
このグループは、オペレーティング・システム・ユーザーの別のグループにバックアップおよびリカバリ関連権限の一部(SYSBACKUP権限)を付与する場合に作成します。
Oracle Data Guard用のOSDGDBAグループ(通常、dgdba
)
このグループは、オペレーティング・システム・ユーザーの別のグループにOracle Data Guardを管理および監視する権限の一部(SYSDG権限)を付与する場合に作成します。
このグループは、オペレーティング・システム・ユーザーの別のグループに、Oracle Wallet Managerの管理など暗号化鍵を管理権限の一部(SYSKM権限)を付与する場合に作成します。
SYSASM、ASM用のSYSOPERおよびASM用のSYSDBAシステム権限では、SYSDBAからOracle ASMストレージ管理権限の分離が可能になります。指定するオペレーティング・システムのメンバーには、これらのロールのシステム権限が付与されます。Oracle ASMに対する権限のオペレーティング・システム認証グループとして、別のオペレーティング・システム・グループを選択します。
OUIを開始する前に、Oracle ASMに対して次のOSグループおよびユーザーを作成します(そのメンバーには対応するSYS権限が付与されます)。
Oracle ASM管理用のOSASMグループ(通常、asmadmin
)
Oracle ASM管理者用とOracle Database管理者用の管理権限グループを別にする場合、このグループを別のグループとして作成します。このグループのメンバーには、Oracle ASMを管理するためのSYSASMシステム権限が付与されます。Oracleドキュメントでは、メンバーに権限が付与されたオペレーティング・システム・グループをOSASMグループと呼びます。コード例には、この権限を付与するために特別に作成された、asmadmin
と呼ばれるグループがあります。
Oracle ASMは、複数のデータベースをサポートできます。システム上に複数のデータベースがあり、複数のOSDBAグループを使用してデータベースごとに別々のSYSDBA権限を提供できるようにする場合は、グループを作成してそのメンバーにOSASM/SYSASM管理権限が付与されるようにし、データベース・インストールを所有しないグリッド・インフラストラクチャ・ユーザー(grid
)を作成する必要があります(これによって、Oracle Grid Infrastructure SYSASM管理権限がデータベース管理権限グループから分離されます)。
OSASMグループのメンバーは、SQLを使用して、SYSASMとしてOracle ASMインスタンスに接続できます。このとき、オペレーティング・システム認証が使用されます。SYSASM権限では、ディスク・グループのマウント、マウント解除およびその他の記憶域管理作業が許可されます。SYSASM権限には、RDBMSインスタンスに対するアクセス権限はありません。
ASMに対するASM用のOSDBAデータベース管理者グループ(通常、asmdba
)
ASMデータベース管理者グループ(ASM用のOSDBA)のメンバーには、Oracle ASMによって管理されるファイルへの読取りおよび書込みアクセス権限が付与されます。Oracle Grid Infrastructureインストール所有者とすべてのOracle Databaseソフトウェア所有者は、このグループのメンバーである必要があります。また、Oracle ASMによって管理されるファイルへアクセスするデータベースに対するOSDBAメンバーシップを持つすべてのユーザーが、ASM用のOSDBAグループのメンバーである必要があります。
ASMオペレータに対するASM用のOSOPERグループ(ASM用のOSOPER、通常はasmoper
)
これはオプションのグループです。Oracle ASMインスタンスの起動と停止を含む、制限付きのOracle ASMインスタンスの管理権限(ASM用のSYSOPER権限)を別のグループのオペレーティング・システム・ユーザーに付与する場合に、このグループを作成します。デフォルトでは、OSASMグループのメンバーには、ASMのSYSOPER権限により付与されるすべての権限もあります。
Oracle ASMオペレータ・グループを使用してデフォルトのasmadmin
グループより少ない権限でOracle ASM管理者グループを作成するには、拡張インストール・タイプを選択してソフトウェアをインストールする必要があります。この場合、OUIによって、グループ名の指定を求めるプロンプトが表示されます。コード例では、このグループはasmoper
です。
次の項では、Oracle Grid InfrastructureおよびOracle Databaseに必要なオペレーティング・システム・ユーザーおよびグループを作成する方法を説明します。
Oracle DatabaseをインストールしてOracle Grid Infrastructure環境で使用するときに、次のような場合はOSDBAグループを作成する必要があります。
OSDBAグループが存在しない場合(たとえば、システムへOracle Databaseソフトウェアを初めてインストールする場合)。
OSDBAグループは存在するが、新規のOracle Databaseインストールでは、異なるオペレーティング・システム・ユーザー・グループにデータベース管理権限を付与する場合。
OSDBAグループが存在しない場合または新しいOSDBAグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはdba
を使用します。
# /usr/sbin/groupadd -g 54323 dba
OSOPERグループを作成する必要があるのは、制限付きのデータベース管理権限(SYSOPERオペレータ権限)を持つオペレーティング・システム・ユーザーのグループを指定する場合のみです。ほとんどのインストールの場合、OSDBAグループを作成するのみで十分です。次の場合にOSOPERグループを使用するには、このグループを作成する必要があります。
OSOPERグループが存在しない場合。たとえば、これがシステムに対するOracle Databaseソフトウェアの初回インストールの場合。
OSOPERグループは存在するが、新規のOracleインストールでは、異なるオペレーティング・システム・ユーザー・グループにデータベース・オペレータ権限を付与する場合。
新しいOSOPERグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはoper
を使用します。
# /usr/sbin/groupadd -g 54324 oper1
OSASMグループが存在しない場合、または新規のOSASMグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmadmin
を使用します。
# /usr/sbin/groupadd -g 54325 asmadmin
データベース管理者などのオペレーティング・システム・ユーザーのグループを指定し、Oracle ASM記憶域の起動と停止を含む、Oracle ASM記憶域層に対する制限付きの管理権限を付与する場合には、ASM用のOSOPERグループを作成します。ほとんどの環境では、OSASMグループを作成するのみで十分です。インストールのインタビュー時に、そのグループをASM用のOSOPERグループとして指定します。
新しいASM用のOSOPERグループが必要な場合は、次の手順で作成します。次の手順では、既存のグループですでに使用されていないかぎり、グループ名にはasmoper
を使用します。
# /usr/sbin/groupadd -g 54326 asmoper
Oracle ASMインスタンスへのアクセスを可能にするには、ASM用のOSDBAグループを作成する必要があります。これは、OSASMとOSDBAが異なるグループである場合に必要です。
ASM用のOSDBAグループが存在しない場合、または新しいASM用のOSDBAグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmdba
を使用します。
# /usr/sbin/groupadd -g 54327 asmdba
この項では、通常Oracle Databaseまたはその他のOracleアプリケーション・ソフトウェアを所有するユーザーである、Oracleソフトウェア所有者ユーザーに関する情報を説明します。この項の内容は次のとおりです。
次の場合、Oracleソフトウェア所有者ユーザーを作成する必要があります。
Oracleソフトウェア所有者ユーザーは存在するが、異なるグループ・メンバーシップを持つ異なるオペレーティング・システム・ユーザーを使用するために、新しいOracle Databaseインストール環境でそれらのグループにデータベース管理権限を付与する場合
Oracle Grid InfrastructureのOracleソフトウェア所有者(grid
など)を作成し、Oracle Databaseソフトウェア用に別のOracleソフトウェア所有者(oracle
など)を作成する場合。
oracle
やgrid
というOracleソフトウェア所有者ユーザーが存在するかどうかを確認するには、次のようなコマンドを入力します(この場合、oracle
の存在を確認します)。
# id oracle
ユーザーが存在する場合、このコマンドの出力結果は、次のようになります。
uid=54321(oracle) gid=54421(oinstall) groups=54322(dba),54323(oper)
既存ユーザーを使用するか、別のユーザーを作成するかを決定します。既存のユーザーを使用する場合は、そのユーザーのプライマリ・グループがOracleインベントリ・グループであり、そのユーザーが適切なOSDBAグループおよびOSOPERグループのメンバーであることを確認します。詳細は、次の項を参照してください。
既存のユーザーを変更するには、第5.1.9.6.4項「既存のOracleソフトウェア所有者ユーザーの変更」を参照してください。
ユーザーを作成する場合は、次の項を参照してください。
Oracleソフトウェア所有者ユーザーが存在しない、または新しいOracleソフトウェア所有者ユーザーが必要な場合は、次の手順で作成します。既存のユーザーですでに使用されていないかぎり、ユーザー名にはoracle
を使用します。
# /usr/sbin/useradd -u 54321 -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=54321(oracle) gid=54421(oinstall) groups=54322(dba),54323(oper),54327(asmdba)
表示された情報から、ユーザーのユーザーID(uid
)および所属するグループのグループID(gid
)を特定します。これらのID番号がクラスタの各ノードで同じであることを確認します。ユーザーのプライマリ・グループはgid
の後に表示されます。セカンダリ・グループはgroups
の後に表示されます。
他のクラスタ・ノードでユーザーおよびグループを作成するには、各ノードで次の手順を繰り返します。
次のクラスタ・ノードへroot
でログインします。
次のコマンドを入力して、oinstall
、asmadmin
およびasmdba
グループを作成します。また、必要に応じて、asmoper
、dba
およびoper
グループを作成します。-g
オプションを使用して、各グループに正しいgid
を指定します。
# /usr/sbin/groupadd -g 54431 oinstall # /usr/sbin/groupadd -g 54322 asmadmin # /usr/sbin/groupadd -g 54323 asmdba # /usr/sbin/groupadd -g 54324 asmoper # /usr/sbin/groupadd -g 54325 dba # /usr/sbin/groupadd -g 54326 oper
注意: グループがすでに存在している場合は、必要に応じてgroupmod コマンドを使用してそのグループを変更します。このノードのグループに、同じグループIDを使用できない場合、すべてのノードの/etc/group ファイルを表示し、どのノードでも使用できるグループIDを特定します。すべてのノードのグループIDが同じになるように、グループIDを変更する必要があります。 |
oracle
ユーザーまたはOracle Grid Infrastructure(grid
)ユーザーを作成するには、次のようなコマンドを入力します(この例では、oracle
ユーザーを作成します)。
# /usr/sbin/useradd -u 54321 -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インベントリ・グループ(oinstall
)の作成
すべてのOracle Grid Infrastructure、Oracle ASMおよびOracle Databaseシステム権限に割り当てる唯一のシステム権限グループとして、単一グループ(dba
)の作成
適切なグループ・メンバーシップを持つOracle Grid Infrastructureソフトウェア所有者(grid
)および1つのOracle Database所有者(oracle
)の作成
OFA構造に準拠し、正しい権限を持つOracleベースのパスの作成および構成
次のコマンドを入力して、オペレーティング・システム認証の最小構成を作成します。
# groupadd -g 54431 oinstall # groupadd -g 54432 dba # useradd -u 53333 -g oinstall -G dba grid # useradd -u 53334 -g oinstall -G dba oracle # mkdir -p /u01/app/12.1.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権限を付与されます。
Oracle Grid Infrastructure、Oracle ASMおよびOracle Databaseシステム権限の1つのシステム権限グループ(dba
)。dba
グループをプライマリまたはセカンダリ・グループとして持つメンバーには、Oracle Clusterware、Oracle ASMおよびOracle Databaseを管理するためのOSASM/SYSASM、OSDBA/SYSDBA、OSOPER/SYSOPER、OSBACKUPDBA/SYSBACKUP、OSDGDBA/SYSDG、OSKMDBA/SYSKM、ASM用のOSDBA/ASM用のSYSDBA、およびASM用のOSOPER/ASM用のSYSOPERのオペレーティング・システム認証が付与され、Oracle ASMストレージへのSYSASMおよびASM用のOSOPERアクセスが付与されます。
クラスタ用のOracle Grid Infrastructureの所有者、つまりGridユーザー(grid
)。プライマリ・グループはoraInventoryグループ(oinstall
)、セカンダリ・グループはOSASMグループ(dba
)。Oracleベース・ディレクトリは/u01/app/grid
。
Oracle Database所有者(oracle
)。プライマリ・グループはoraInventoryグループ(oinstall
)、セカンダリ・グループはOSDBAグループ(dba
)。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/12.1.0/grid
。これらの権限はインストールに必要であり、インストール・プロセスで変更されます。
インストール前は775権限で、インストール後は755権限でgrid:oinstall
が所有する/u01/app/grid
。
775権限でoracle:oinstall
が所有する/u01/app/oracle
。
注意: Oracle Grid Infrastructureとその他のOracleインストールの両方に対して、1つのインストール所有者を使用できます。ただし、Oracleソフトウェア・インストールごとに別のインストール所有者アカウントを使用することをお薦めします。 |
この項では、Optimal Flexible Architecture(OFA)デプロイメントに準拠する、ロール割当てされたグループおよびユーザーの作成方法の例を示します。
この例のシナリオは次のとおりです。
Oracle Grid Infrastructureインストール
クラスタに対して計画された2つの別々のOracle Databaseインストール(DB1およびDB2)
Oracle Grid Infrastructureおよび各Oracle Databaseの別々のインストール所有者
Oracle ASMおよび各Oracle Databaseのシステム権限の完全なロール割当て
Oracle Database所有者oracle1
(Oracle ASMインスタンスの起動および停止権限を持つ)
次のコマンドを使用して、このシナリオのロール割当てをした構成のグループおよびユーザーを作成します。
# groupadd -g 54321 oinstall # groupadd -g 54322 asmadmin # groupadd -g 54323 asmdba # groupadd -g 54324 dba1 # groupadd -g 54325 dba2 # groupadd -g 54326 asmoper # useradd -u 54421 -g oinstall -G asmadmin,asmdba grid # useradd -u 54322 -g oinstall -G dba1,asmdba oracle1 # useradd -u 54323 -g oinstall -G dba2,asmdba oracle2 # mkdir -p /u01/app/12.1.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 Grid Infrastructureおよび2つの別々のOracle Database (DB1とDB2)の管理権限グループおよびユーザーのセットが作成されます。
Oracle中央インベントリ・グループ、つまりoraInventoryグループ(oinstall
)。メンバーは、このグループをプライマリ・グループとして持ちます。このグループのメンバーにはOINSTALLシステム権限が付与され、これによってoraInventory
ディレクトリへの書込み権限と、その他の関連するバイナリのインストール権限が付与されます。
OSASMグループ(asmadmin
)。このグループはインストール中にOracle Grid Infrastructureと関連付けられ、そのメンバーにはOracle ASMを管理するためのSYSASM権限が付与されます。
ASM用のOSDBAグループ(asmdba
)。インストール中にOracle Grid Infrastructure記憶域に関連付けられます。メンバーにはgrid
とすべてのデータベース・インストール所有者(oracle1
、oracle2
など)が含まれ、これらのメンバーはOracle ASMへのアクセス権が付与されます。記憶域にOracle ASMを使用するその他のインストール所有者も、このグループのメンバーである必要があります。
Oracle ASMのためのASM用のOSOPERグループ(asmoper
)。インストール中にOracle Grid Infrastructureに関連付けられます。asmoperグループのメンバーには、Oracle ASMインスタンスの起動および停止の権限など、制限付きのOracle ASM管理者権限が付与されます。
Oracle Grid Infrastructureインストール所有者(grid
)。プライマリ・グループはoraInventoryグループ(oinstall
)、セカンダリ・グループはOSASM(asmadmin
)グループおよびASM用のOSDBA(asmdba
)グループ。
/u01/app/oraInventory
。クラスタ上のOracleインストールの中央インベントリ。このパスの所有者はgrid:oinstall
のままで、他のOracleソフトウェア所有者による中央インベントリへの書込みを可能にします。
インストール前にgrid:oinstall
によって所有されるOFA準拠のマウント・ポイント/u01
。Oracle Universal Installerがそのパスに書き込めるようになります。
775権限でgrid:oinstall
が所有する、グリッド・インストール所有者のOracleベース/u01/app/grid
。インストール・プロセスで755権限に変更されます。
775(drwxdrwxr-x
)権限でgrid:oinstall
が所有する、Gridホーム/u01/app/12.1.0/grid
。これらの権限はインストールに必要であり、インストール・プロセスでroot:oinstall
の755権限(drwxr-xr-x
)に変更されます。
Oracle Databaseソフトウェア所有者(oracle1
)。DB1のOracle Databaseバイナリを所有します。oracle1
ユーザーは、プライマリ・グループとしてoraInventoryグループ、そのデータベースのOSDBAグループ(dba1
)、およびセカンダリ・グループとしてのOracle Grid InfrastructureのASM用のOSDBAグループ(asmdba
)を持ちます。また、oracle1
ユーザーはasmoper
のメンバーであり、Oracle ASMを起動および停止するユーザー権限が付与されます。
OSDBAグループ(dba1
)。インストール中に、ユーザーoracle1
によってインストールされたデータベースのOSDBAグループとして、グループdba1
を指定します。dba1
のメンバーには、Oracle Database DB1に対するSYSDBA権限が付与されます。SYSDBAとして接続するユーザーは、DB1でユーザーSYSとして識別されます。
OSBACKUPDBAグループ(backupdba1
)。インストール中に、ユーザーoracle1
によってインストールされたデータベースのOSDBAグループとして、グループbackupdba1
を指定します。backupdba1
のメンバーには、ユーザーoracle1
によってインストールされたデータベースに対する、データベースをバックアップするためのSYSBACKUP権限が付与されます。
OSDGDBAグループ(dgdba1
)。インストール中に、ユーザーoracle1
によってインストールされたデータベースのOSDGDBAグループとして、グループdgdba1
を指定します。dgdba1
のメンバーには、ユーザーoracle1
によってインストールされたデータベースに対する、Oracle Data Guardを管理するためのSYSDG権限が付与されます。
OSKMDBAグループ(kmdba1
)。インストール中に、ユーザーoracle1
によってインストールされたデータベースのOSKMDBAグループとして、グループkmdba1
を指定します。kmdba1
のメンバーには、ユーザーoracle1
によってインストールされたデータベースに対する、暗号化鍵を管理するためのSYSKM権限が付与されます。
OSOPERグループ(oper1
)。インストール中に、ユーザーoracle1
によってインストールされたデータベースのOSOPERグループとして、グループoper1
を指定します。oper1
のメンバーには、DB1データベースの起動および停止の権利など、SYSOPER権限(SYSDBA権限の一部)が付与されます。OSOPER権限として接続するユーザーは、DB1でユーザーPUBLICとして識別されます。
775権限でoracle1:oinstall
が所有する、Oracleベース/u01/app/oracle1
。ユーザーoracle1
は、このディレクトリにソフトウェアをインストールする権限を持ちます(/u01/app
パスのその他のディレクトリは対象外です)。
Oracle Databaseソフトウェア所有者(oracle2
)。DB2のOracle Databaseバイナリを所有します。oracle2ユーザーは、そのプライマリ・グループとしてのoraInventoryグループ、そのデータベースのOSDBAグループ(dba2
)、およびセカンダリ・グループとしてのOracle Grid InfrastructureのASM用のOSDBAグループ(asmdba
)を持ちます。ただし、oracle2
ユーザーはasmoper
グループのメンバーでないため、oracle2
はOracle ASMを停止または起動できません。
OSDBAグループ(dba2
)。インストール中に、ユーザーoracle2
によってインストールされたデータベースのOSDBAグループとして、グループdba2
を指定します。dba2
のメンバーには、Oracle Database DB2に対するSYSDBA権限が付与されます。SYSDBAとして接続するユーザーは、DB2でユーザーSYSとして識別されます。
OSBACKUPDBAグループ(backupdba2
)。インストール中に、ユーザーoracle2
によってインストールされたデータベースのOSDBAグループとして、グループbackupdba2
を指定します。backupdba2
のメンバーには、ユーザーoracle2
によってインストールされたデータベースに対する、データベースをバックアップするためのSYSBACKUP権限が付与されます。
OSDGDBAグループ(dgdba2
)。インストール中に、ユーザーoracle2
によってインストールされたデータベースのOSDGDBAグループとして、グループdgdba2
を指定します。dgdba2
のメンバーには、ユーザーoracle2
によってインストールされたデータベースに対する、Oracle Data Guardを管理するためのSYSDG権限が付与されます。
OSKMDBAグループ(kmdba2
)。インストール中に、ユーザーoracle2
によってインストールされたデータベースのOSKMDBAグループとして、グループkmdba2
を指定します。kmdba2
のメンバーには、ユーザーoracle2
によってインストールされたデータベースに対する、暗号化鍵を管理するためのSYSKM権限が付与されます。
OSOPERグループ(oper2
)。インストール中に、ユーザーoracle2
によってインストールされたデータベースのOSOPERグループとして、グループoper2
を指定します。oper2
のメンバーには、DB2データベースの起動および停止の権利など、SYSOPER権限(SYSDBA権限の一部)が付与されます。OSOPER権限として接続するユーザーは、DB2でユーザーPUBLICとして識別されます。
775権限でoracle1:oinstall
が所有する、Oracleベース/u01/app/oracle2
。ユーザーoracle2
は、このディレクトリにソフトウェアをインストールする権限を持ちます(/u01/app
パスのその他のディレクトリは対象外です)。
HP-UXプラットフォームで、Oracle Grid Infrastructure上にOracle DatabaseまたはOracle Real Application Clustersをインストールする場合は、次の手順を実行して外部ジョブ・ユーザー・アカウントを作成して、外部ジョブを実行可能な権限の低いユーザーを用意します。
rootユーザーでログインします。
権限を付与されていないユーザーextjob
を作成します。次に例を示します。
# useradd extjob
インストーラ・ソフトウェアは、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ウィンドウ・アプリケーションがこのシステム上に表示されることを確認します。
$ 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またはKornシェルの場合:
$ . ./.profile
Cシェル:
% source ./.login
次のコマンドを使用してPATH環境変数をチェックします。
$ echo $PATH
すべてのOracle環境変数を削除します。
ローカル・システムにソフトウェアをインストールしていない場合は、次のコマンドを入力して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環境変数の設定を削除し、インストーラによって示されるデフォルトのパスを選択することをお薦めします。 |
リモート端末で作業を行っていて、そのローカル・ノードのみが表示されている場合(通常は、この状態になります)、次の構文を使用して、環境変数DISPLAYを設定します。
Bourne、KornおよびBashシェル:
$ export DISPLAY=hostname:0
Cシェル:
$ setenv DISPLAY hostname:0
たとえば、Bashシェルを使用していて、ホスト名がnode1
の場合は、次のコマンドを入力します。
$ export DISPLAY=node1:0
X11転送が原因でインストールが失敗しないようにするには、次のように、Oracleソフトウェア所有者ユーザーに対してユーザーレベルのSSHクライアント構成ファイルを作成します。
テキスト・エディタを使用して、ソフトウェア・インストール所有者の~/.ssh/config
ファイルを編集または作成します。
~/.ssh/config
ファイルでForwardX11
属性がno
に設定されていることを確認します。次に例を示します。
Host * ForwardX11 no
~/.sshに対する権限がGridユーザーに固定されることを確認します。次に例を示します。
$ ls -al .ssh total 28 drwx------ 2 grid oinstall 4096 Jun 21 2015 drwx------ 19 grid oinstall 4096 Jun 21 2015 -rw-r--r-- 1 grid oinstall 1202 Jun 21 2015 authorized_keys -rwx------ 1 grid oinstall 668 Jun 21 2015 id_dsa -rwx------ 1 grid oinstall 601 Jun 21 2015 id_dsa.pub -rwx------ 1 grid oinstall 1610 Jun 21 2015 known_hosts
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 コマンドのかわりにremsh コマンドを使用します。
リモート・シェルによってロードされる隠しファイルに |
Intelligent Platform Management Interface(IPMI)は、コンピュータのハードウェアおよびファームウェアへの共通インタフェースを提供し、システム管理者はそのインタフェースを使用して、システム状態の監視およびシステムの管理を実行できます。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ドライバがインストールされている必要があります。
クラスタに、IPMI用の管理ネットワークが必要です。これは共有ネットワークでも可能ですが、専用ネットワークの構成をお薦めします。
BMCで使用する各クラスタ・メンバー・ノードのイーサネット・ポートが、IPMI管理ネットワークに接続されている必要があります。
各クラスタ・メンバーが管理ネットワークに接続されている必要があります。
一部のサーバー・プラットフォームでは、電源を切るとネットワーク・インタフェースが省電力モードになります。この場合には、低いリンク速度(1GBではなく100MBなど)で動作することになります。こうしたプラットフォームの場合、BMCが接続されるネットワーク・スイッチ・ポートで、低い速度に合わせた自動ネゴシエートが可能である必要があります。そうでない場合は、IPMIが正常に動作できません。
注意: IPMIは、ベースボード管理コントローラ(BMC)のネットワーク・インタフェースを通して物理ハードウェア・プラットフォームに作用します。実際のシステム構成によっては、IPMIによるサーバー再起動が、そのサーバーでホスティングされているすべての仮想環境に影響を及ぼす可能性があります。詳細は、お使いのハードウェアおよびOSのベンダーに問い合せてください。 |
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)に格納する必要があります。これを行うには、第8.2.1項「crsctlを使用したIPMIベース障害分離の構成」
で説明されているとおり、crsctlを使用します。ただし、IPMI資格証明をOLRに格納する場合は、明示的に指定した匿名ユーザーが必要です。ない場合は、解析エラーがレポートされます。
% crsctl set css ipmiadmin ""
プロンプトに対し、IPMI管理者ツールで設定したパスワードを指定します。
Oracle Grid Infrastructureのインストール中に、多数のシステム構成タスクを完了するために、スーパーユーザー(root
)権限でスクリプトを実行するようにインストーラから求められます。
次のオプションのいずれかを使用して、root
として手動でスクリプトを実行するか、root
として構成手順を実行する権限をインストーラに委任することができます。
root
パスワードを使用: その他の構成情報を入力する際に、インストーラにパスワードを提供します。パスワードはインストール中に使用され、格納されません。rootユーザー・パスワードは、各クラスタ・メンバー・ノードで同一である必要があります。
rootコマンドの委任を有効にするには、要求された際に、インストーラにroot
パスワードを提供します。
sudoを使用: sudoはUNIXおよびLinuxのユーティリティで、sudoersリスト権限のメンバーは、個々のコマンドをroot
として実行できます。
Sudoを有効にするには、適切な権限を持つシステム管理者がsudoersリストのメンバーであるユーザーを構成し、インストール時の求めに応じてユーザー名とパスワードを指定します。
グリッド・インストール所有者の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/12.1.0/grid # mkdir -p /u01/app/grid # mkdir -p /u01/app/oracle # chown grid:oinstall /u01/app/12.1.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バイナリをクラスタ・ファイル・システムに配置することはサポートされていません。 |