Oracle® Grid Infrastructure

インストレーション・ガイド

12cリリース1 (12.1) for HP-UX Itanium

E52983-07(原本部品番号:E51134-05)

2017年7月

Oracle Grid Infrastructureインストレーション・ガイド, 12cリリース1 (12.1) for HP-UX Itanium

E52983-07

Copyright © 2014, 2017, Oracle and/or its affiliates. All rights reserved.

原本著者: Aparna Kamath

原本協力者: Mark Bauer、Jonathan Creighton、Barb Lundhild、Sundar Matpadi、Markus Michalewicz、Soma Prasad、Janet Stern、Douglas Williams

原本協力者: Dharma Sirnapalli、Angad Gokakkar、Diego Iglesias、Binoy Sukumaran、Taisuke Gishi、Aneesh Khandelwal、Peng Miao、Ken Natsume、Ayaka Saeki、Jarod Wang、Jessica Ye、Min Yu

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle およびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このリリースでの『Oracle Grid Infrastructureインストレーション・ガイド』の変更点

- Oracle Grid Infrastructure 12c リリース1 (12.1)の変更点

1 Oracle Grid Infrastructureインストールのチェックリスト

- 1.1 システムのハードウェア、ソフトウェアおよび構成のチェックリスト

- 1.1.1 Oracle Grid Infrastructureインストールのサーバー・ハードウェアのチェックリスト

- 1.1.2 Oracle Grid InfrastructureおよびOracle RAC環境のチェックリスト

- 1.1.3 Oracle Grid Infrastructureのネットワークのチェックリスト

- 1.1.4 Oracle Grid InfrastructureおよびOracle RACのアップグレードのチェックリスト

- 1.1.5 Oracle Grid Infrastructureの記憶域の構成作業

- 1.1.6 Oracle Grid Infrastructureのインストール開始時の作業

2 Oracle Grid InfrastructureおよびOracle RACのサーバーの構成

- 2.1 サーバーのハードウェアとメモリー構成の確認

- 2.2 一般的なサーバーの最小要件

- 2.3 サーバーの最小記憶域要件

- 2.4 サーバーの最小メモリー要件

- 2.4.1 64-bitシステムの最小メモリー要件

- 2.4.2 共有メモリーの要件

3 Oracle Grid InfrastructureおよびOracle RACのオペレーティング・システムの構成

- 3.1 オペレーティング・システムとソフトウェアのアップグレードに関するベスト・プラクティスの確認

- 3.1.1 アップグレードの一般的なベスト・プラクティス

- 3.1.2 Oracle ASMのアップグレード通知

- 3.1.3 ローリング・アップグレード手順の通知

- 3.2 オペレーティング・システム・セキュリティの共通プラクティスの確認

- 3.3 インストール修正スクリプトの使用

- 3.4 X端末を使用したリモート・システムへのログイン

- 3.5 ソフトウェア要件について

- 3.6 HP-UX Itaniumプラットフォームでのオペレーティング・システム要件

- 3.7 HP-UX用の追加ドライバとソフトウェア・パッケージ

- 3.7.1 Open Database Connectivityのインストール要件

- 3.7.1.1 ODBCドライバとOracle Databaseについて

- 3.7.1.2 HP-UX Itaniumシステム用のODBCドライバのインストール

- 3.7.2 Oracle Messaging Gatewayのインストール要件

- 3.7.2.1 Oracle Messaging Gatewayの概要

- 3.7.2.2 Oracle Messaging Gatewayのインストール

- 3.7.3 HP-UX Itaniumシステムのプログラミング環境のインストール要件

- 3.7.3.1 プログラミング環境とOracle Databaseについて

- 3.7.3.2 プログラミング環境のサポートの構成

- 3.7.4 Webブラウザのインストール要件

- 3.8 ソフトウェア要件の確認

- 3.9 クラスタ時刻同期のためのネットワーク・タイム・プロトコルの設定

- 3.10 インストール時におけるSSHの自動構成の使用

- 3.11 必須のシンボリック・リンクの作成

- 3.12 デバイス・ファイルのマイナー番号の設定

- 3.13 実行レベルおよびネーム・サービス・キャッシュ・デーモンの確認

4 Oracle Grid InfrastructureおよびOracle RACのネットワークの構成

- 4.1 ネットワーク・インタフェースのハードウェア要件

- 4.2 IPインタフェース構成の要件

- 4.3 プライベート・インターコネクト冗長ネットワークの要件

- 4.4 IPv4およびIPv6プロトコルの要件

- 4.5 Oracle Grid InfrastructureのIP名およびアドレスの要件

- 4.5.1 Oracle Grid Infrastructureの名前解決オプションについて

- 4.5.2 クラスタ名およびSCANの要件

- 4.5.3 グリッド・ネーミング・サービス(GNS)のIP名およびアドレスの要件

- 4.5.4 マルチクラスタのGNSのIP名およびアドレスの要件

- 4.5.4.1 マルチクラスタのGNSネットワークについて

- 4.5.4.2 GNSサーバー・クラスタの構成

- 4.5.4.3 GNSクライアント・クラスタの構成

- 4.5.4.4 GNSクライアント・データ・ファイルの作成および使用

- 4.5.5 標準クラスタの手動構成のIP名およびアドレスの要件

- 4.6 Oracle Flex ASMクラスタのネットワークについて

- 4.7 Oracle Grid Infrastructureが使用するネットワークのブロードキャスト要件

- 4.8 Oracle Grid Infrastructureが使用するネットワークのマルチキャスト要件

- 4.9 グリッド・ネーミング・サービスへのドメイン委任

- 4.9.1 グリッド・ネーミング・サービスで使用するためのサブドメイン名の選択

- 4.9.2 クラスタでグリッド・ネーミング・サービスへドメイン委任するためのDNSの構成

- 4.10 Oracle Flex Clusterの構成要件

- 4.10.1 Oracle Flex Cluster構成の一般的な要件

- 4.10.2 Oracle Flex ClusterのDHCP割当ての仮想IP (VIP)アドレス

- 4.10.3 Oracle Flex Clusterの手動割当てのアドレス

- 4.11 グリッド・ネーミング・サービスの標準クラスタの構成例

- 4.12 手動によるIPアドレスの構成例

- 4.13 ネットワーク・インタフェース構成のオプション

5 Oracle Grid InfrastructureおよびOracle RACのユーザー、グループおよび環境の構成

- 5.1 Oracle Grid Infrastructureのグループ、ユーザーおよびパスの作成

- 5.1.1 Oracle InventoryおよびOracle Inventoryグループの存在の確認

- 5.1.2 Oracle Inventoryが存在しない場合のOracle Inventoryグループの作成

- 5.1.3 Oracle Grid Infrastructureユーザーの作成

- 5.1.3.1 Oracleソフトウェアのインストール所有者に対する制限の理解

- 5.1.3.2 Oracleソフトウェア所有者ユーザーの存在の確認

- 5.1.3.3 Oracle Grid InfrastructureのOracleソフトウェア所有者ユーザーの作成または変更

- 5.1.4 GridユーザーのOracleベース・ディレクトリについて

- 5.1.5 Oracle Grid InfrastructureソフトウェアのOracleホーム・ディレクトリについて

- 5.1.6 OracleホームおよびOracleベース・ディレクトリの作成

- 5.1.7 役割区分によるオペレーティング・システム権限グループおよびユーザーについて

- 5.1.7.1 役割区分によるグループおよびユーザーの作成の概要

- 5.1.8 役割区分によるグループおよびユーザーの説明

- 5.1.8.1 Oracleソフトウェア製品ごとのOracleソフトウェア所有者

- 5.1.8.2 役割区分用の標準Oracle Databaseグループ

- 5.1.8.3 役割区分用の拡張Oracle Databaseグループ

- 5.1.8.4 役割区分用のOracle ASMグループ

- 5.1.9 役割区分によるオペレーティング・システム権限グループおよびユーザーの作成

- 5.1.9.1 データベース・インストールの準備のためのOSDBAグループの作成

- 5.1.9.2 データベース・インストールのためのOSOPERグループの作成

- 5.1.9.3 OSASMグループの作成

- 5.1.9.4 ASMのためのOSOPERグループの作成

- 5.1.9.5 Oracle ASMへのデータベース・アクセスのためのASM用のOSDBAグループの作成

- 5.1.9.6 Oracleソフトウェア所有者ユーザーのインストール作業

- 5.1.9.7 他のクラスタ・ノードでの同一データベース・ユーザーおよびグループの作成

- 5.1.10 標準的なグループ、ユーザーおよびパスの作成例

- 5.1.11 ロール割当てをしたグループ、ユーザーおよびパスの作成例

- 5.1.11.1 Oracle Grid Infrastructureのグループおよびユーザーの例

- 5.1.11.2 Oracle Database DB1のグループおよびユーザーの例

- 5.1.11.3 Oracle Database DB2のグループおよびユーザーの例

- 5.1.12 HP-UXに対する外部ジョブ・ユーザー・アカウントの作成

- 5.2 グリッド・インフラストラクチャ・ソフトウェア所有者ユーザー環境の構成

- 5.2.1 Oracleソフトウェア所有者の環境要件

- 5.2.2 Oracleソフトウェア所有者の環境の構成手順

- 5.2.3 リモート表示およびX11転送の構成の設定

- 5.2.4 インストール中に端末出力コマンドによって発生するエラーの防止

- 5.3 Intelligent Platform Management Interface(IPMI)の有効化

- 5.3.1 IPMIを有効化するための要件

- 5.3.2 IPMI管理ネットワークの構成

- 5.3.3 BMCの構成

- 5.3.3.1 HP-UXでのiLOプロセッサの構成

- 5.4 rootスクリプトの実行計画の決定

- 5.5 Oracleベース・ディレクトリのパスの作成

6 Oracle Grid InfrastructureおよびOracle RACの記憶域の構成

- 6.1 Oracle Grid Infrastructureの記憶域オプションの確認

- 6.1.1 サポートされている記憶域オプション

- 6.1.2 Oracle Grid InfrastructureおよびOracle RACの記憶域についての一般的な考慮事項

- 6.1.2.1 Oracle Clusterwareの記憶域についての一般的な考慮事項

- 6.1.2.2 Oracle RACの記憶域についての一般的な考慮事項

- 6.1.3 記憶域にOracle ASMディスク・グループを使用するためのガイドライン

- 6.1.4 Oracle Grid InfrastructureおよびOracle RACでの論理ボリューム・マネージャの使用

- 6.1.5 ディスクの記憶域オプションを選択した後の作業

- 6.2 共有ファイル・システムの記憶域の構成について

- 6.2.1 共有ファイル・システムを使用するための要件

- 6.2.2 Oracle Grid Infrastructure共有ファイル・システムのボリューム・サイズ要件

- 6.2.3 Oracle Clusterwareファイル用のクラスタ・ファイル・システムの使用の確認

- 6.2.4 データ・ファイル用のDirect NFSクライアントの使用の確認

- 6.2.4.1 Direct NFSクライアント・ストレージについて

- 6.2.4.2 oranfstabファイルおよびDirect NFSクライアントについて

- 6.2.4.3 Direct NFSクライアントを使用したNFSストレージ・デバイスのマウントについて

- 6.2.4.4 oranfstabファイルを使用したネットワーク・パスの指定

- 6.2.5 データ・ファイル用のNFSの使用の確認

- 6.3 オペレーティング・システムおよびDirect NFSクライアントの構成

- 6.3.1 記憶域のNFSマウントおよびバッファ・サイズ・パラメータの構成

- 6.3.2 Oracle Clusterware用のNFSマウントおよびバッファ・サイズ・パラメータの確認

- 6.3.3 Oracle RAC用のNFSマウントおよびバッファ・サイズ・パラメータの確認

- 6.3.4 Direct NFSクライアントのためのTCPネットワーク・プロトコル・バッファの確認

- 6.3.5 NFSのDirect NFSクライアントのOracle Disk Manager制御の有効化

- 6.3.6 oranfstabファイルを使用したネットワーク・パスの指定

- 6.3.7 Direct NFSクライアントにおけるハイブリッド列圧縮の有効化

- 6.3.8 共有ファイル・システムでのOracle Clusterwareファイル用のディレクトリの作成

- 6.3.9 共有ファイル・システムでのOracle Databaseファイル用のディレクトリの作成

- 6.3.10 NFSのDirect NFSクライアントのOracle Disk Management制御の無効化

- 6.4 Oracle 自動ストレージ管理の記憶域の構成

- 6.4.1 Oracle Automatic Storage Management用の記憶域の構成

- 6.4.1.1 Oracle ASMの記憶域要件の指定

- 6.4.1.2 Oracle ASMで使用するためのNASデバイスでのファイルの作成

- 6.4.1.3 既存のOracle ASMディスク・グループの使用

- 6.4.1.4 Oracle ASM用のディスク・デバイスの構成

- 6.4.2 Oracle ASMでのOracle Databaseファイルとディスク・グループの使用

- 6.4.2.1 ASM上の既存のOracle Databaseディスク・グループの指定と使用

- 6.4.2.2 Oracle Databaseデータ・ファイルのためのディスク・グループの作成

- 6.4.2.3 Oracle ASM資格証明ファイルの作成と使用

- 6.4.3 既存のOracle ASMインスタンスのアップグレード

7 クラスタ用Oracle Grid Infrastructureのインストール

- 7.1 グリッド・インフラストラクチャのインストール

- 7.1.1 OUIの実行によるグリッド・インフラストラクチャのインストール

- 7.1.2 クラスタ構成ファイルを使用したグリッド・インフラストラクチャのインストール

- 7.2 ソフトウェアのみのインストールを使用したグリッド・インフラストラクチャのインストール

- 7.2.1 ソフトウェア・バイナリのインストール

- 7.2.2 ソフトウェア・バイナリの構成

- 7.2.3 レスポンス・ファイルを使用したソフトウェア・バイナリの構成

- 7.2.4 ネットワーク・チェックのためのpingターゲットの設定

- 7.3 Oracle Clusterwareの機能の確認

- 7.4 Oracle Clusterwareファイルを対象とするOracle ASM機能の確認

- 7.5 Oracle Grid Infrastructureでのオフライン・プロセスの理解

8 Oracle Grid Infrastructureのインストール後の手順

- 8.1 インストール後に必要な作業

- 8.2 インストール後の推奨作業

- 8.2.1 crsctlを使用したIPMIベース障害分離の構成

- 8.2.2 セマフォ・パラメータの調整

- 8.2.3 高速リカバリ領域ディスク・グループの作成

- 8.2.3.1 高速リカバリ領域および高速リカバリ領域ディスク・グループについて

- 8.2.3.2 高速リカバリ領域ディスク・グループの作成

- 8.2.4 SCAN構成の確認

- 8.2.5 Oracle RAC構成監査ツールの実行

- 8.2.6 Oracle Clusterwareと関連するデータベースおよびアプリケーションのリソース制限の設定

- 8.3 Oracle Grid Infrastructureでの以前のOracle Databaseリリースの使用

- 8.3.1 前のバージョンのOracle Databaseの使用に関する一般的な制限

- 8.3.2 以前のデータベース・バージョンによるサーバー・プールの管理

- 8.3.3 ASMCAを使用した前のバージョンのデータベースのディスク・グループの管理

- 8.3.4 Oracle Databaseリリース10.xまたは11.x用のクラスタ・ノードの固定

- 8.3.5 適切なLSNRCTLコマンドの使用

- 8.4 インストール後のOracle Clusterwareバイナリの変更

9 Oracle Grid Infrastructureを変更または削除する方法

- 9.1 Oracle Clusterwareを削除するタイミングの決定

- 9.2 クラスタへのスタンドアロン・グリッド・インフラストラクチャ・サーバーの移行

- 9.3 クラスタ用Oracle Grid Infrastructureのバイナリの再リンク

- 9.4 Oracle Grid Infrastructureホーム・パスの変更

- 9.5 バイナリを削除せずに行うOracle Clusterwareの構成解除

- 9.6 Oracle ClusterwareとASMの削除

- 9.6.1 削除ツールについて

- 9.6.1.1 以前のリリースのGridホームの削除

- 9.6.2 Oracle Grid Infrastructureの削除ツールのコマンドの例

- 9.6.3 クラスタ用グリッド・インフラストラクチャの削除レスポンス・ファイルの例

A Oracle Grid Infrastructureのインストール・プロセスに関するトラブルシューティング

- A.1 Oracleサポートに連絡する際のベスト・プラクティス

- A.2 一般的なインストールの問題

- A.2.1 その他のインストールの問題およびエラー

- A.3 詳細モードによるCVUの「不明」出力メッセージの解釈

- A.4 Oracle Grid Infrastructureの設定に関するCVUメッセージの解釈

- A.5 Oracle Grid Infrastructureのアラート・ログについて

- A.6 Oracle Grid Infrastructureのインストール中のクラスタ診断の実行

- A.7 インストール後のCVUのクラスタ・ヘルス・チェックの使用について

- A.8 インターコネクト構成の問題

- A.9 SCAN VIPおよびSCANリスナーの問題

- A.10 ストレージ構成の問題

- A.10.1 ノード・ファイル・システムまたはGridホーム損失からのリカバリ

- A.11 失敗または不完全なインストールおよびアップグレード

- A.12 失敗または中断されたインストールおよびアップグレードの完了

- A.12.1 最初のノードでの不完全なインストールの続行

- A.12.2 最初のノード以外のノードでのインストールの続行

B Oracle Grid Infrastructure 12cリリース1へのアップグレード方法

- B.1 アップグレード前のOracleソフトウェアのバックアップ

- B.2 Oracle環境変数の設定削除

- B.3 Oracle Grid InfrastructureおよびOracle ASMのアップグレードおよびダウングレードについて

- B.4 クラスタウェアおよびOracle ASMのアップグレードとダウングレードのオプション

- B.5 クラスタウェアおよびOracle ASMアップグレードの制限事項

- B.6 既存のOracle Clusterwareインストールをアップグレードするための準備

- B.6.1 既存のOracle Clusterwareインストールをアップグレードする前の完了の確認

- B.6.2 ORAchkアップグレード準備状況評価の実行

- B.7 CVUを使用した、Oracle Clusterwareのアップグレードに対する準備状況の検証

- B.7.1 CVUのグリッド・アップグレード検証コマンドのオプションについて

- B.7.2 グリッド・インフラストラクチャのシステム・アップグレードの準備状況の検証例

- B.7.3 Oracle Databaseアップグレードに対するシステム準備状況の検証

- B.8 バッチを使用したローリング・アップグレードの理解

- B.9 Oracle Grid Infrastructureのローリング・アップグレードの実行

- B.9.1 以前のリリースからの標準的なアップグレードの実行

- B.9.2 ノードにアクセスできなくなった場合のOracle Clusterwareのアップグレードの完了

- B.9.3 アップグレードの強制後のアクセス不可のノードのアップグレード

- B.9.4 インストールとアップグレードに使用する最初のノードの変更

- B.9.5 Oracle Automatic Storage Managementのローリング・アップグレードの実行

- B.9.5.1 Oracle ASMの完全リリースのローリング・アップグレードについて

- B.9.5.2 個々の(個別)Oracle ASMパッチについて

- B.9.5.3 Oracle Grid Infrastructureのソフトウェア・パッチ・レベルについて

- B.9.6 Oracle ASMの個別アップグレードの実行準備

- B.9.7 Oracle Grid InfrastructureアップグレードからのOracle ASMの個別パッチ適用

- B.9.8 ソフトウェア・パッチ・レベルへのOracle ASMのアップグレード

- B.10 Oracle Enterprise Manager Cloud Controlのターゲット・パラメータの更新

- B.10.1 アップグレード後のEnterprise Manager Cloud Controlターゲットの更新

- B.10.2 アップグレード後のEnterprise Managerエージェント・ベース・ディレクトリの更新

- B.11 既存のOracle Clusterwareインストールのロック解除

- B.12 アップグレード後のOracle Clusterwareのダウングレード

- B.12.1 アップグレード後のOracle Clusterwareのダウングレードについて

- B.12.2 11gリリース2 (11.2.0.2)より前のリリースへのダウングレード

- B.12.3 11gリリース2 (11.2.0.2)以上のリリースへのダウングレード

C レスポンス・ファイルを使用したOracle Databaseのインストールおよび構成

- C.1 レスポンス・ファイルの機能

- C.1.1 サイレント・モードまたはレスポンス・ファイル・モードを使用する理由

- C.1.2 レスポンス・ファイルの一般的な使用手順

- C.2 レスポンス・ファイルの準備

- C.2.1 レスポンス・ファイル・テンプレートの編集

- C.2.2 レスポンス・ファイルの記録

- C.3 レスポンス・ファイルを使用したインストーラの実行

- C.4 レスポンス・ファイルを使用したNet Configuration Assistantの実行

- C.5 レスポンス・ファイルを使用したインストール後の構成

- C.5.1 インストール後の構成ファイルについて

- C.5.2 レスポンス・ファイルを使用したインストール後の構成の実行

D クラスタ用Oracle Grid Infrastructureのインストールの概要

- D.1 インストール前の構成の理解

- D.1.1 Oracle Grid Infrastructureに関するOptimal Flexible Architectureガイドライン

- D.1.2 クラスタ用Oracle Grid InfrastructureとOracle Restart用Oracle Grid Infrastructureの違い

- D.1.3 Oracle Inventoryグループの理解

- D.1.4 Oracle Inventoryディレクトリの理解

- D.1.5 Oracleベース・ディレクトリの理解

- D.1.6 Oracle Grid Infrastructureソフトウェア用Oracleホームの理解

- D.1.7 OracleベースおよびOracle Grid Infrastructureソフトウェアのディレクトリの場所

- D.2 ネットワーク・アドレスの理解

- D.2.1 パブリックIPアドレスについて

- D.2.2 プライベートIPアドレスについて

- D.2.3 仮想IPアドレスについて

- D.2.4 グリッド・ネーミング・サービス(GNS)の仮想IPアドレスについて

- D.2.5 Oracle Grid InfrastructureインストールのSCANについて

- D.3 ネットワークの時刻要件の理解

- D.4 Oracle Flex ClusterおよびOracle ASM Flexクラスタの理解

- D.5 記憶域の構成の理解

- D.5.1 既存のOracle ASMインスタンスの移行について

- D.5.2 スタンドアロンのOracle ASMインストールのクラスタ・インストールへの変換

- D.6 アウトオブプレース・アップグレードの理解

E インストール作業を手動で行う方法

- E.1 すべてのクラスタ・ノードでの手動によるSSHの構成

- E.1.1 システム上の既存のSSH構成の確認

- E.1.2 クラスタ・ノードでのSSHの構成

- E.1.2.1 各ノードでのSSHディレクトリおよびSSH鍵の作成

- E.1.2.2 共通のauthorized_keysファイルへのすべての鍵の追加

- E.1.3 クラスタ・ノードでのSSHユーザー等価関係の有効化

- E.2 カーネル・パラメータの構成

- E.2.1 カーネル・パラメータの最小値

- E.2.2 カーネル・パラメータの手動設定

- E.2.2.1 KCTUNEを使用したカーネル設定の変更

- E.2.2.2 SMHを使用したカーネル設定の変更

- E.2.2.3 KCWEBを使用したカーネル設定の変更

- E.2.3 HP-UXシステムのカーネル・パラメータの構成

- E.3 UDPおよびTCPカーネル・パラメータの手動設定

索引

表一覧

- 1-1 Oracle Grid Infrastructureのサーバー・ハードウェアのチェックリスト

- 1-2 Oracle Grid InfrastructureおよびOracle RACの環境構成

- 1-3 Oracle Grid InfrastructureおよびOracle RACのネットワーク構成作業

- 1-4 Oracle Grid Infrastructureのインストール・アップグレードのチェックリスト

- 1-5 Oracle Grid Infrastructureの記憶域の構成チェック

- 1-6 インストーラの起動前に実行するOracle Grid Infrastructureのチェック

- 2-1 64-bitシステムで必要なスワップ領域

- 3-1 HP-UX Itaniumの要件

- 3-2 HP-UX Itaniumシステムのプログラミング環境の要件

- 4-1 グリッド・ネーミング・サービスのネットワーク例

- 4-2 手動によるネットワークの構成例

- 6-1 Oracle ClusterwareおよびOracle RACでサポートされている記憶域オプション

- 6-2 Oracle Clusterware共有ファイル・システムのボリューム・サイズ要件

- 6-3 Oracle RAC共有ファイル・システムのボリューム・サイズ要件

- 6-4 冗長タイプによるOracle Clusterwareに必要な記憶領域の合計

- 6-5 冗長タイプによるOracle Databaseに必要な記憶領域の合計

- C-1 Oracle Databaseのレスポンス・ファイル

- C-2 Oracle Grid Infrastructureのレスポンス・ファイル

- E-1 HP-UXでのカーネル・パラメータの最小値

はじめに

『Oracle Grid Infrastructureインストレーション・ガイドfor HP-UX Itanium』では、Oracle Grid Infrastructure環境(Oracle ClusterwareおよびOracle Automatic Storage Management)をインストールして構成する準備としてサーバーを構成する方法について説明します。また、Oracle Real Application Clusters(Oracle RAC)をインストールする準備としてサーバーと記憶域を構成する方法についても説明します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Grid Infrastructureインストレーション・ガイドfor HP-UX Itanium』では、ネットワークおよびシステムの管理者が必要とする構成についての情報と、クラスタ用Oracle Grid Infrastructureのインストールで、Oracle ClusterwareおよびOracle Automatic Storage Managementをインストールして構成するデータベース管理者(DBA)が必要とするデータベースのインストールについての情報を記載しています。

Oracle RACをインストールする、特別なシステム・ロールを持つユーザーに対しては、システム管理者、ネットワーク管理者またはストレージ管理者として、クラスタ用Oracle Grid Infrastructureのインストール準備段階でシステムを構成すること、およびオペレーティング・システムのroot権限を必要とするすべての構成タスクを完了することを目的としています。Oracleグリッド・インフラストラクチャのインストールおよび構成が正常に完了した場合、システム管理者が行う必要があることは、構成情報の指定と、Oracle RACのインストール中にrootとしてスクリプトを実行する権限をデータベース管理者に付与することのみです。

このマニュアルは、Oracle Databaseの概念を十分に理解していることを前提としています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、次のOracleマニュアルを参照してください。

Oracle ClusterwareおよびOracle Real Application Clustersのドキュメント

このマニュアルでは、Oracle ClusterwareおよびOracle Automatic Storage Managementのインストールを完了するために必要な手順、およびOracle RACのインストール前の手順を実行するために必要な手順を確認します。

Oracle DatabaseまたはOracle RACをインストールする場合は、このマニュアルの説明に従ってインストール前の作業およびグリッド・インフラストラクチャのインストールを完了します。追加情報については次のインストール関連のマニュアルを参照してください。スタンドアロン・サーバー用Oracle DatabaseをOracle Grid Infrastructureインストールにインストールするか、またはOracle RACデータベースをインストールすることができます。グリッド・インフラストラクチャのOracle Restartのデプロイメントをインストールする場合は、『Oracle Databaseインストレーション・ガイドfor HP-UX Itanium』を参照してください。

ほとんどのOracleエラー・メッセージのドキュメントは、HTML版のみが存在します。Oracleドキュメント・メディアを使用する場合は、エラー・メッセージを範囲ごとに参照できます。特定の範囲のページを表示したら、ブラウザの「このページの検索」機能を使用して特定のメッセージを検索できます。インターネットに接続できる場合、Oracleオンライン・ドキュメントのエラー・メッセージ検索機能を使用して特定のエラー・メッセージを検索できます。

インストレーション・ガイド

- 『Oracle Databaseインストレーション・ガイドfor HP-UX Itanium』

- 『Oracle Real Application Clustersインストレーション・ガイド for Linux and UNIX』

オペレーティング・システム固有の管理者ガイド

- 『Oracle Database管理者リファレンス 12c リリース1 (12.1) for UNIX Systems』

Oracle ClusterwareおよびOracle Automatic Storage Managementの管理者ガイド

- 『Oracle Clusterware管理およびデプロイメント・ガイド』

- 『Oracle Databaseストレージ管理者ガイド』

Oracle Real Application Clustersの管理者ガイド

- 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

- 『Oracle Database 2日でReal Application Clustersガイド』

共通マニュアル

- 『Oracle Database 2日でデータベース管理者』

- 『Oracle Database管理者ガイド』

- 『Oracle Database概要』

- 『Oracle Database新機能ガイド』

- 『Oracle Database Net Services管理者ガイド』

- 『Oracle Databaseリファレンス』

印刷版のドキュメントは、次のWebサイトのOracle Storeで入手可能です。

https://shop.oracle.com

リリース・ノート、インストール関連ドキュメント、ホワイト・ペーパーまたはその他の関連ドキュメントは、OTN (Oracle Technology Network)から、無償でダウンロードできます。OTNを使用するには、オンラインでの登録が必要で、登録は、次のWebサイトから無償で行えます。

http://www.oracle.com/technetwork/index.html

すでにOTNのユーザー名およびパスワードを取得している場合は、OTN Webサイトのドキュメントのセクションに直接接続できます。

http://www.oracle.com/technetwork/indexes/documentation/index.html

ほとんどのOracleエラー・メッセージのドキュメントは、HTML版のみが存在します。インストール・メディアのドキュメント・ディレクトリで、エラー・メッセージを範囲ごとに参照できます。特定の範囲のページを表示したら、ブラウザの検索機能を使用して特定のメッセージを検索できます。インターネットに接続できる場合、Oracleオンライン・ドキュメントのエラー・メッセージ検索機能を使用して特定のエラー・メッセージを検索できます。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ドキュメントのタイトル、強調またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このリリースでの『Oracle Grid Infrastructureインストレーション・ガイド』の変更点

この章の内容は次のとおりです。

- Oracle Grid Infrastructure 12c リリース1 (12.1)の変更点

Oracle Grid Infrastructure 12c リリース1 (12.1)の変更点

Oracle Grid Infrastructure 12cリリース1のOracle Grid Infrastructureインストレーション・ガイドには、次の変更点があります。

- Oracle Grid Infrastructure 12cリリース1 (12.1.0.2)の新機能

- Oracle Grid Infrastructure 12cリリース1 (12.1.0.1)の新機能

- 非推奨となった機能

- サポート対象外機能

- その他の変更

Oracle Grid Infrastructure 12cリリース1 (12.1.0.2)の新機能

- Oracleホームの迅速なプロビジョニング
高速ホーム・プロビジョニングは、クラウド・コンピューティング環境で、データベース、ミドルウェア、アプリケーションなどのOracleソフトウェアのホーム・イメージ(ゴールド・イメージと呼ばれます)を格納する単一のクラスタから、ソフトウェアのホームをノードにデプロイする方法です。高速ホーム・プロビジョニング・サーバー(RHPS)クラスタは、高速ホーム・プロビジョニング・クラスタ(RHPC)のゴールド・イメージを提供します。

『Oracle Clusterware管理およびデプロイメント・ガイド』と『Oracle Real Application Clustersインストレーション・ガイド』を参照してください。

- クラスタおよびOracle RAC診断ツールの拡張機能
トレース・ファイル・アナライザ(TFA)コレクタは、Oracle Grid Infrastructureのインストール時に自動的にインストールされます。トレース・ファイル・アナライザ・コレクタは、Oracle Grid InfrastructureおよびOracle RACシステムの診断データの収集を簡素化する、診断を収集するためのユーティリティです。

関連項目:
トレース・ファイル・アナライザ・コレクタの使用に関する詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- グリッド・インフラストラクチャ管理リポジトリの自動インストール
グリッド・インフラストラクチャ管理リポジトリは、Oracle Grid Infrastructure 12cリリース1 (12.1.0.2)とともに自動的にインストールされます。

注意:
グリッド・インフラストラクチャ管理リポジトリ機能は、HP-UX Itanium構成ではサポートされていません。

- Oracle RACキャッシュ・フュージョン・アクセラレータ
Oracle RACは、キャッシュ・フュージョン・プロトコルとグローバル・キャッシュ・サービス(GCS)を使用して、高速で信頼性の高いインスタンス間データ通信をOracle RACクラスタで実現するため、複数インスタンスの個々のメモリー・バッファ・キャッシュが、データベースに対して1つのグローバル・キャッシュとして機能します。キャッシュ・フュージョン・プロバイダを使用すると、ほとんどのアプリケーションでほぼリニアなスケーラビリティが実現します。このリリースでは、すべてのアプリケーションでスケーラビリティを強化するキャッシュ・フュージョン・プロトコルのアクセラレーション機能が用意されています。

Oracle Grid Infrastructure 12cリリース1 (12.1.0.1)の新機能

- Oracle Flex Cluster
Oracle Flex Clusterは新しい概念であり、少数のノード数を持つ従来の密結合クラスタを、多数の疎結合ノードと結合します。この新しい概念を使用して作成された様々な構成をサポートするため、SRVCTLでは、インストールと構成を容易にする、新しいコマンドおよびコマンド・オプションが提供されています。

第4.10項「Oracle Flex Clusterの構成要件」を参照してください。

関連項目:
Oracle Flex Clusterの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を、Oracle Flex Clusterのデプロイメントの詳細は、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

- ASMディスク・グループでのOracle Cluster Registryバックアップのサポート
Oracle Cluster Registry (OCR)バックアップ・メカニズムによりOracle ASMディスク・グループでOCRのバックアップを格納することができます。Oracle ASMディスク・グループにOCRのバックアップを格納すると、OCRのリカバリが必要になった場合にクラスタの任意のノードからOCRバックアップへのアクセスを許可することによって、OCR管理が簡素化されます。

- パブリック・ネットワークに対するIPv6のサポート
Oracle Clusterware 12cリリース1 (12.1)では、IPv6ベースのパブリックIPアドレスおよびパブリックVIPアドレスがサポートされます。

今日のデータ・センターでの情報テクノロジ・インフラストラクチャでは、IPv6ベースのIPアドレスが標準になってきています。このリリースでは、Oracle RACおよびOracle Grid Infrastructureで、この標準がサポートされます。インストール時に、同じネットワークでIPv4またはIPv6アドレスを使用してクラスタ・ノードを構成できます。データベース・クライアントは、IPv4アドレスまたはIPv6アドレスのどちらにも接続できます。単一クライアント・アクセス名(SCAN)のリスナーは、クライアントの接続要求を、そのクライアント要求のIPプロトコルに適したデータベース・リスナーへ自動的にリダイレクトします。

第4.4項「IPv4およびIPv6のプロトコル要件」を参照してください。

- Grid Infrastructureのインストールとアップグレードのスクリプト自動化
この機能によって、インストーラおよびその他の構成アシスタントを使用したroot権限を必要とするすべてのスクリプトを実行できるので、デプロイ時に手動でrootベースのスクリプトを実行する必要はなくなりました。

インストールとアップグレードのスクリプト自動化を使用すると、Oracle Grid Infrastructureのインストールまたはアップグレードの最終手順で、各ノードでスクリプトを手動で実行する必要がなくなります。

第1.1.2項「Oracle Grid InfrastructureおよびOracle RAC環境のチェックリスト」を参照してください。

- Oracle Grid Infrastructureの個別パッチ対応ローリング・マイグレーション
Oracle Grid Infrastructureの個別パッチのローリング移行およびOracle ASMとOracle Clusterwareへのアップグレードにより、個別パッチによる、クラスタ化されたOracle Grid Infrastructureノードへのアップグレードまたはパッチ適用を、データベースの可用性に影響することなく、独立して実行することができます。この機能により、稼働時間を大きく向上させ、柔軟にパッチ適用を行うことができます。また、このリリースでは、新しいクラスタ状態(「ローリング・パッチ」)が導入されています。パッチ静止状態で可能な操作は、既存のローリング・アップグレード・クラスタ状態と類似しています。

B.9.5項「Oracle Automatic Storage Managementのローリング・アップグレードの実行」を参照してください

関連項目:
ASMのローリングでの移行およびパッチの詳細は、『Oracle Database Storage管理者ガイド』を参照してください。

- Oracle Flex ASMサーバーとOracle CloudFS
Oracle Flex ASMによって、Oracle ASMインスタンスをデータベース・サーバーから切り離し、データベース・サーバーとは別の物理サーバーでOracle ASMインスタンスを実行することができます。任意の数のOracle ASMインスタンスをクラスタ化し、多数のデータベース・クライアントをサポートすることができます。これは、Oracle CloudFSのコンポーネント機能です。

Oracle CloudFSは、クラウド・コンピューティング環境の主な要件であるリソース・プーリング、ネットワーク・アクセス可能性、迅速な弾力性とプロビジョニングによる、ストレージのクラウド・インフラストラクチャです。

この機能によって、すべての記憶域要件をディスク・グループの1つの設定に統合できるようになります。これらすべてのディスク・グループは、単一のCluster Synchronization Services (CSS)クラスタで動作している少数のOracle ASMインスタンスによって管理されます。様々なOracle ASMクライアントが、ディスク・グループ内の自身のファイルにどのようにアクセスするかについて、性能要件に応じてポリシーを決定することができます。

Oracle Flex ASMでは、Oracle Database 12 cリリース1 (12.1)以上がサポートされます。Oracle Database 10 gリリース2 (10.2)以上からOracle Database 11 gリリース(11.2)までは、パッチをインストールするという要件はなく、ASMディスク・グループの使用を続けることができます。

第4.6項「Oracle Flex ASMクラスタのネットワークについて」を参照してください。

関連項目:
Oracle Flex ASMサーバー使用の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

- ポリシーベースのクラスタ処理および管理
Oracle Grid Infrastructureでは、1つのクラスタで複数のアプリケーションを実行することができます。ポリシーベースの方法を使用すると、これらのアプリケーションによって発生するワークロードを、ポリシーを使用したクラスタ全体に振り分けることができます。またポリシー設定によって、時間の経過とともに必要に応じて異なるポリシーをクラスタに適用することができます。ポリシー設定は、Webベースのインタフェースまたはコマンドライン・インタフェースを使用して定義することができます。

同じクラスタ内で様々なワークロードを受け入れることで、共有インフラストラクチャにワークロードを集約することができ、高可用性とスケーラビリティが実現されます。集中管理されたポリシーベースの方法を使用することで、要求の変化に応じてリソースを動的に再配分し、優先度付けが可能になります。

ポリシーを使用してアプリケーションを管理する方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- 複数のクラスタに渡る共有グリッド・ネーミング・サービス(GNS)
以前のリリースのグリッド・ネーミング・サービス(GNS)は、1つのOracle Grid Infrastructureベースのクラスタ専用であり、自身のクラスタ・メンバー・ノードに対してのみ名前解決が可能でした。このリリースでは、1つのOracle GNSで、自身のクラスタのクラスタ・メンバー・ノードを管理することや、名前解決がOracle GNSに委任されたデータ・センターのすべてのクラスタに渡るすべてのノードの名前解決が可能です。

データ・センターのOracle Grid Infrastructureクラスタに属するすべてのノードに対して、1つのOracle GNSを使用すると、ネーミング規則が簡素化されるだけではなく、データ・センター・クラウドの日々の管理労力を最小限にすることができます。

第4.5項「Oracle Grid InfrastructureのIP名およびアドレスの要件」を参照してください。

- データベース管理義務の分離のサポート
Oracle Database 12cリリース1 (12.1)では、SYSDBA管理権限を必要としない、タスク固有の管理権限と最小管理権限が導入されたことにより、Oracle Databaseの管理業務の分離がサポートされます。これらの新しい権限には、バックアップおよびリカバリのSYSBACKUP、Oracle Data GuardのSYSDGおよび暗号化鍵管理のSYSKMがあります。

第5.1.8.3項「役割区分による拡張されたOracle Databaseグループ」を参照してください。

参照:

- システム権限およびオペレーティング・システム認証の概要については、『Oracle Database管理者ガイド』を参照してください。

- システム権限の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

非推奨となった機能

次の機能は今回のリリースで非推奨となり、今後のリリースではサポートされない可能性があります。このリリースの非推奨となった機能の完全なリストは、『Oracle Databaseアップグレード・ガイド』を参照してください。

- スタンドアロン削除ツールの変更点

削除ツールはインストール・メディアに統合されました。

- -cleanupOBaseの非推奨
削除ツールの-cleanupOBaseフラグは、このリリースでは非推奨です。このフラグの代替機能はありません。

サポート対象外機能

次の機能は、Oracleではサポートされなくなりました。サポート対象外の機能のすべてのリストは、『Oracle Databaseアップグレード・ガイド』を参照してください。

- Oracle Enterprise Manager Database Control

- CLEANUP_ORACLE_BASEプロパティは削除済

- RAWデバイスおよびブロック・デバイスはサポートされていません

その他の変更

- ドキュメント構造の変更
このマニュアルは、Oracle ClusterwareとOracle Automatic Storage Managementのインストールで構成される、Oracle Grid Infrastructureインストールのためのチェックリストを記載するために、構成が変更されています。チェックリストを使用して、インストールの準備をします。詳細は、インストール前のタスクをカテゴリ・トピックに細分化した章を参照してください。

- インストール前の作業の変更内容
クラスタ・デプロイメントを簡素化するため、インストールの最小要件を満たしていない場合はOracle Universal Installer (OUI)およびCluster Verification Utility (CVU)によって検知され、要件を満たしていないシステム構成の多くを解決するために、修正スクリプトと呼ばれるシェル・スクリプト・プログラムが作成されます。「修正可能」とマークされている不完全な作業がOUIで検知されたときは、「修正および再チェック」ボタンをクリックして修正スクリプトを生成することで、簡単に問題を解決できます。

修正スクリプトは、システム・チューニングのかわりになるものではありませんが、初期のデプロイメントに必要な手動のシステム構成の量は低減されます。このため、修正スクリプトが実行するいくつかの手動のタスクが、付録に移動されています。その場合は、手動でサーバーの構成を続けることができます。

第3.3項「インストール修正スクリプトの使用」および付録E「インストール作業を手動で行う方法」を参照してください。

- サポート対象外の32ビット・プラットフォーム
Oracle Grid InfrastructureおよびOracle Real Application Clustersは32ビット・システムにはインストールできません。

1 Oracle Grid Infrastructureインストールのチェックリスト

このチェックリストを使用して作業を調整し、クラスタ用Oracle Grid Infrastructureのインストールを開始する前に、すべてのシステムおよび記憶域の準備と構成作業が完了していることを確認できます。

1.1 システムのハードウェア、ソフトウェアおよび構成のチェックリスト

この項には、次のサーバー構成インストールのチェックリストが含まれます。

- Oracle Grid Infrastructureインストールのサーバー・ハードウェアのチェックリスト

- Oracle Grid InfrastructureおよびOracle RAC環境のチェックリスト

- Oracle Grid Infrastructureのネットワークのチェックリスト

- Oracle Grid InfrastructureおよびOracle RACのアップグレードのチェックリスト

- Oracle Grid Infrastructureの記憶域の構成作業

- Oracle Grid Infrastructureのインストール開始時の作業

1.1.1 Oracle Grid Infrastructureインストールのサーバー・ハードウェアのチェックリスト

すべてのインストールで次のハードウェア・チェックリストを確認します。

表1-1 Oracle Grid Infrastructureのサーバー・ハードウェアのチェックリスト

チェック

作業

サーバー・ハードウェア

サーバーの型、モデル、コア・アーキテクチャおよびホスト・バス・アダプタ(HBA)がOracle RACとともに動作することを確認します。

ネットワーク・スイッチ

- 1GbE以上のパブリック・ネットワーク・スイッチ(パブリック・ゲートウェイに接続)。

- 1GbE以上、10GbE推奨のプライベート・ネットワーク・スイッチ(他のクラスタ・メンバー・ノードにのみ使用するための専用)。インタフェースで、TCP/IPをサポートする高速ネットワーク・アダプタおよびスイッチを使用して、ユーザー・データグラム・プロトコル(UDP)がサポートされている必要があります。かわりに、インターコネクトにInfiniBandを使用することもできます。

実行レベル

サーバーは実行レベル3または実行レベル5である必要があります。

ランダム・アクセス・メモリー(RAM)の要件

Cluster用Oracle Grid Infrastructureインストール用に4GB以上のRAM(Oracle RACをインストールする計画があるインストールを含む)。

一時ディスク領域の割当ての要件

/tmpに1 GB以上を割り当てます。

オペレーティング・システム

- 3.6項「HP-UX Itaniumプラットフォームでのオペレーティング・システム要件」に示されたサポートされているカーネルおよびリリースのリストにおいてサポート。

- 各クラスタ・メンバー・ノードで同じオペレーティング・システム・カーネルが実行されている。

- OpenSSHがまだインストールされていない場合、3.10項「インストール時におけるSSHの自動構成の使用」の説明に従って手動でインストールします。

ストレージ・ハードウェア

ストレージ・エリア・ネットワーク(SAN)またはネットワーク・アタッチ・ストレージ(NAS)が必要です。

Oracleソフトウェア用のローカル記憶領域

- クラスタ用Oracle Grid Infrastructureホーム(Gridホーム)に8GB以上の領域。パッチ用の追加領域を確保するために100GBを割り当てることをお薦めします。

- Oracle Grid Infrastructureインストール所有者(Gridユーザー)のOracleベース用に12GB以上の領域。Oracleベースには、Oracle ClusterwareおよびOracle ASMのログ・ファイルが含まれます。

- トレース・ファイル・アナライザ(TFA)コレクタによって生成された診断収集用に、グリッド・インフラストラクチャ所有者のOracleベース・ディレクトリに10GBの追加の領域。

Intelligent Platform Management Interface(IPMI)

構成を完了し、インストールを実行するユーザーがIPMI管理者アカウント情報を利用できるようにします。

IPMIを使用する場合は、Baseboard Management Controller(BMC)インタフェースが構成されていることを確認し、インストール時の指示に従って管理アカウントのユーザー名およびパスワードを指定できるように用意します。

非標準のインストールで、インストール後に1つ以上のノード構成の変更が必要な場合は(たとえば、クラスタ・ノード上のBMCインタフェースの管理者のユーザー名およびパスワードを別のものにする場合は)、インストール後にBMCインタフェースを構成しなおすかどうかや、IPMI管理者アカウント情報を変更するかどうかを決定します。

1.1.2 Oracle Grid InfrastructureおよびOracle RAC環境のチェックリスト

すべてのインストールで次の環境チェックリストを確認します。

表1-2 Oracle Grid InfrastructureおよびOracle RACの環境構成

チェック

作業

グループおよびユーザーを作成します。

実行するデプロイメントで作成する必要があるグループおよびユーザーについては、第5.1項「Oracle Grid Infrastructureのグループ、ユーザーおよびパスの作成」を参照してください。インストール所有者には、リソース制限設定などの要件があります。グループおよびユーザーの名前には、ASCII文字のみを使用する必要があります。

ソフトウェア・バイナリのマウント・ポイント・パスを作成します。

ご使用のプラットフォームの『Oracle Databaseインストレーション・ガイド』のOptimal Flexible Architectureに関する説明に記載されている、Optimal Flexible Architecture構成のガイドラインに従うことをお薦めします。

Oracleインベントリ(oraInventory)およびOINSTALLグループの要件を確認します。

Oracleインベントリ・ディレクトリは、システムにインストールされているOracleソフトウェアの中央インベントリです。プライマリ・グループがOracle Inventoryグループであるユーザーは、中央インベントリに書込みできるOINSTALL権限が付与されます。

- 既存のインストールがある場合、OUIは既存のoraInventoryディレクトリを/etc/oraInst.locファイルから検出し、この場所を使用します。

- Oracleソフトウェアを初めてインストールし、システムにoraInventoryディレクトリがない場合、Oracle Grid InfrastructureインストールのOracleベースよりもディレクトリ・レベルが1つ上のOracleインベントリがインストーラによって作成され、インストール所有者のプライマリ・グループがOracleインベントリ・グループとして指定されます。使用するOracleソフトウェア・インストール所有者のすべてが、このグループをプライマリ・グループとして利用できることを確認します。

Gridホームのパス

Gridホーム(Oracle Grid Infrastructure用に選択するOracleホームのパス)に、ASCII文字のみが使用されていることを確認します。

この制限には、ホームのパスによってはデフォルト名に使用されるインストール所有者ユーザー名に加えて、パスに選択する可能性があるその他のディレクトリ名も含まれます。

Oracleソフトウェアの環境変数の設定を解除します。

環境変数にORA_CRS_HOMEを設定した場合は、インストールまたはアップグレードを開始する前に、その設定を削除します。ORA_CRS_HOMEをユーザー環境変数に使用しないでください。

システムに既存のインストール環境があり、同じユーザー・アカウントを使用して今回のインストールを行う場合、次の環境変数ORA_CRS_HOME、ORACLE_HOME、ORA_NLS10、TNS_ADMINの設定を削除します。

インストールのroot権限の委任オプションを確認します。

インストール中に、rootユーザーとして構成スクリプトを実行する必要があります。プロンプトに従ってrootとしてこれらのスクリプトを手動で実行するか、インストール時にroot権限の委任オプションを使用して構成情報およびパスワードを指定できます。

rootスクリプトを自動的に実行するには、インストール時に「構成スクリプトを自動的に実行」を選択します。自動構成オプションを使用するには、すべてのクラスタ・メンバー・ノードのrootユーザーが同じパスワードを使用する必要があります。

- rootユーザーの資格証明を使用
クラスタ・メンバー・ノード・サーバーのスーパーユーザー・パスワードを指定します。

- sudoを使用
sudoはUNIXおよびLinuxのユーティリティで、sudoersリスト権限のメンバーは、個々のコマンドをrootとして実行できます。sudoersのメンバーであり、各クラスタ・メンバー・ノードでsudoを実行する権限を持つオペレーティング・システム・ユーザーのユーザー名およびパスワードを指定します。

Sudoを有効にするには、適切な権限を持つシステム管理者がsudoersリストのメンバーであるユーザーを構成し、インストール時の求めに応じてユーザー名とパスワードを指定します。

- rootスクリプトを手動で実行
rootスクリプトを手動で実行する場合は、最初のノードでroot.shスクリプトを実行し、これが完了するまで待つ必要があります。その後、他のすべてのノードでroot.shを同時に実行します。

1.1.3 Oracle Grid Infrastructureのネットワークのチェックリスト

すべてのインストールでこのネットワークのチェックリストを確認し、クラスタに必要なハードウェア、名前およびアドレスがあることを確認します。インストール時に、どのインタフェースがパブリックまたはプライベートなのか、あるいは別の目的(ネットワーク・ファイル・システムなど)で使用されるインタフェースなのか、指定するように求められます。

サード・パーティのクラスタ・ソフトウェアを使用する場合、パブリック・ホスト名情報はそのソフトウェアから取得されます。

インストール時、インタフェースをパブリック、プライベートまたはOracle ASMインタフェースとして使用するように指定します。また、他の目的に使用され、Oracle Grid Infrastructureインタフェースには使用できないインタフェースを指定することもできます。

表1-3 Oracle Grid InfrastructureおよびOracle RACのネットワーク構成作業

チェック

作業

パブリック・ネットワーク・ハードウェア

- パブリック・ゲートウェイおよび各クラスタ・メンバー・ノードのパブリック・インタフェース・ポートに接続されるパブリック・ネットワーク・スイッチ(冗長スイッチを推奨)。

- イーサネット・インタフェース・カード(1つのイーサネット・ポート名としてトランクされた冗長ネットワーク・カードを推奨)。

- スイッチおよびネットワーク・インタフェースは、1GbE以上である必要があります。

- ネットワーク・プロトコルはTCP/IPです。

インターコネクト用のプライベート・ネットワーク・ハードウェア

- 各クラスタ・メンバー・ノードのプライベート・インタフェース・ポートに接続される、専用のプライベート・ネットワーク・スイッチ(冗長スイッチを推奨)。注意: 各サーバーに複数のプライベート・ネットワーク・インタフェース・カードがある場合、Oracle Clusterwareが、グリッド・プロセス間通信(GIPC)およびグリッド・インフラストラクチャの冗長インターコネクト(クラスタの高可用性IP (HAIP)とも呼ばれる)を使用してプライベート・ネットワークのこれらのインタフェースを自動的に関連付けることに注意してください。

- スイッチおよびネットワーク・インタフェース・アダプタは1GbE以上である必要があり、推奨は10GbEです。かわりに、インターコネクトにInfiniBandを使用することもできます。

- インターコネクトでユーザー・データグラム・プロトコル(UDP)がサポートされている必要があります。

Oracle Flex ASMのネットワーク・ハードウェア

Oracle Flex ASMでは、Oracle Clusterwareと同じプライベート・ネットワークか、独自の専用プライベート・ネットワークを使用できます。各ネットワークは、パブリック、プライベートとASM、プライベート、ASMのいずれかに分類できます。ASMネットワークではTCPプロトコルが使用されます。

クラスタの名前およびアドレス

クラスタの次の名前およびアドレスを決定して構成します

- クラスタ名: クラスタの名前を決定し、インストール時に入力できるようにしておきます。クラスタ名は次の特性を持つ必要があります。

- DNSドメインが異なる場合も含め、すべてのホスト間でグローバルに一意である。

- 1文字以上、15文字以下である。

- RFC 1123に準拠して、ホスト名に使用されるキャラクタ・セット(ハイフン(-)およびシングルバイト英数字(aからz、AからZ、および0から9)を含む)と同じキャラクタ・セットで構成されている。

- サード・パーティ・ベンダーのクラスタウェア: サード・パーティ・ベンダーのクラスタウェアを使用する場合は、そのベンダーのクラスタ名を使用することをお薦めします。

- グリッド・ネーミング・サービスの仮想IPアドレス(GNS VIP): GNSを使用する場合は、GNS VIP用にDNSでGNS名および固定アドレスを構成し、クラスタ・アドレスの解決のためにGNS VIPに委任されるサブドメインをDNSで構成します。GNSのドメイン委任は、動的パブリック・ネットワーク(DHCP、自動構成)では必須です。

- 単一クライアント・アクセス名(SCAN)およびアドレス
グリッド・ネーミング・サービスの解決の使用: DNSでSCANの名前およびアドレスを構成しないでください。SCANはGNSによって管理されます。

手動構成およびDNS解決の使用: ドメイン・ネーム・サービス(DNS)で3つのアドレスに解決されるSCAN名を構成します。

標準またはハブ・ノードのパブリック、プライベートおよび仮想IP名およびアドレス

GNSを使用せず、標準クラスタを構成する場合は、各ハブ・ノードに対して次を構成します。

- パブリック・ノード名およびアドレス: DNSおよび/etc/hostsで構成します(例: node1.example.com、アドレス192.0.2.10)。パブリック・ノード名は、各ノードのプライマリ・ホスト名(hostnameコマンドによって表示される名前)である必要があります。

- プライベート・ノード・アドレス: 各ノードのプライベート・インタフェースで構成します。
プライベート・インタフェースが使用するプライベート・サブネットは、クラスタ・メンバーにする予定のすべてのノードに接続する必要があります。プライベート・ネットワーク用に選択したネットワークでは、RFC 1918でプライベートとして定義されている範囲のアドレスを使用することをお薦めします。

- パブリック・ノードの仮想IP名およびアドレス(例: node1-vip.example.com、アドレス192.0.2.11)。
GNSを使用していない場合は、各ノードに仮想ホスト名を指定します。仮想ホスト名は、パブリック・ノード名で、ノードが停止している場合にノードに送信されるクライアントの要求を再ルーティングするために使用されます。Oracle Databaseでは、クライアントとデータベース間の接続にVIPを使用するため、VIPアドレスはパブリックにアクセス可能である必要があります。名前はhostname-vip形式で指定することをお薦めします。たとえば、myclstr2-vipです。

1.1.4 Oracle Grid InfrastructureおよびOracle RACのアップグレードのチェックリスト

既存のOracle Grid InfrastructureまたはOracle RACインストールがある場合は、このアップグレード・チェックリストを確認します。クラスタは、すべてのクラスタ･メンバー･ノードでOracle Grid Infrastructure 12cリリース1 (12.1)が実行されて、新しいクラスタウェアがアクティブなバージョンになるまでアップグレードされます。

Oracle RACをインストールする場合は、Oracle Database 12cリリース1 (12.1)バージョンのOracle RACをインストールする前に、まず、すべてのクラスタ・ノードでOracle Grid Infrastructure 12cリリース1 (12.1)へのアップグレードを完了する必要があります。

注意:
Oracle Grid Infrastructureのアップグレード(Oracle ClusterwareおよびOracle ASMの既存のインストール環境のアップグレード)は、すべてアウトオブプレース・アップグレードです。既存のOracle Grid InfrastructureインストールからOracle Flex Clusterインストールにアップグレードできません。

表1-4 Oracle Grid Infrastructureのインストール・アップグレードのチェックリスト

チェック

作業

ドキュメントの読取り

『Oracle Databaseアップグレード・ガイド』を確認します。

最新のパッチセット

使用可能な最新のパッチセットのリリースをインストールします。

インストール所有者

使用する予定のインストール所有者が、既存のOracle Grid Infrastructureインストールを所有するインストール所有者と同じであることを確認します。

アップグレードしている新しいOracle Grid InfrastructureインストールおよびOracle Grid Infrastructureホームのインストールは同じオペレーティング・システム・ユーザーが所有する必要があり、異なる場合は権限エラーが発生します。

Oracle Automatic Storage Management (Oracle ASM)インスタンス

所有するOracle Automatic Storage Management (Oracle ASM)インスタンスで、標準のOracle ASMインスタンス名が使用されていることを確認します。

単一インスタンス・データベース用のデフォルトASM SIDは+ASM、Oracle Real Application ClustersノードのASMのデフォルトSIDは+ASMnode#です(node#はノードの番号)。Oracle Grid Infrastructure 11.2.0.1以上では、デフォルト以外のOracle ASMインスタンス名はサポートされません。

デフォルト以外のOracle ASMインスタンス名がある場合は、クラスタをアップグレードする前に既存のリリースのsrvctlを使用して、デフォルト以外の名前を持つ個々のOracle ASMインスタンスを削除し、デフォルト名を持つOracle ASMインスタンスを追加します。

標準のOracle Grid Infrastructureデプロイメントのネットワーク・アドレス

標準のOracle Grid Infrastructureデプロイメントのネットワーク・アドレスを確認し、パブリック・ネットワークおよびプライベート・ネットワークのIPアドレスに関して次のことを確認します。

- プライベートIPアドレスおよびパブリックIPアドレスがそれぞれ関連性のない別々のサブネット内にある。プライベート・サブネットは、専用のプライベート・サブネットにある必要があります。

- パブリックIPアドレスおよび仮想IPアドレス(SCANアドレスを含む)が同じサブネット内にある(サブネット・ネットワークのサブネット・マスクで許可されるアドレスの範囲)。

- プライベートIPアドレスでもパブリックIPアドレスでもリンク・ローカル・サブネット(169.254.*.*)が使用されていない。

Oracle Cluster Registry (OCR)ファイル

RAWデバイスまたはブロック・デバイスからOracle ASMまたはサポートされるファイル・システムにOCRファイルを移行します。RAWデバイスおよびブロック・デバイスはサポートされていません。

オペレーティング・システムの構成

サポート対象のオペレーティング・システム、カーネル・リリース、新しいOracle Grid Infrastructureインストールに必要なすべてのオペレーティング・システム・パッケージを使用していることを確認します。

Oracle Cluster Registry (OCR)ファイルの整合性

ocrcheckコマンドを実行してOracle Cluster Registry (OCR)ファイルの整合性を確認します。このチェックに失敗した場合は、続行する前にOCRを修復します。

Oracle 12c Upgrade Companion

他のアップグレードの問題に関する最新情報について、「Oracle 12c Upgrade Companion」(My Oracle SupportのNote 1462240.1)を確認します。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1462240.1

Oracle Databaseのアップグレード前ユーティリティの実行

Oracle Grid Infrastructureインストールの完了後、アップグレード用にデータベースを準備するために、パス$ORACLE_HOME/rdbms/adminにあるOracle Databaseのアップグレード前ユーティリティのSQLスクリプトを実行します。

詳細は、My Oracle SupportのNote 884522.1を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=884522.1

1.1.5 Oracle Grid Infrastructureの記憶域の構成作業

すべてのインストールで次の記憶域構成作業のチェックリストを確認します。

表1-5 Oracle Grid Infrastructureの記憶域の構成チェック

チェック

作業

ORAchkアップグレード準備状況評価の実行

インストール中に、次のOracle Clusterwareファイルのパスを指定するように求められます。これらのパスの場所は、Oracle Grid Infrastructureインストール所有者(Gridユーザー)によって書込み可能である必要があります。インストール時に作成されるファイルはすべてのクラスタ･メンバー･ノードが利用できる必要があるため、これらの場所は、Oracle ASM (推奨)またはクラスタ・ファイル・システム上にあり、クラスタのすべてのノードで共有される必要があります。

- 投票ディスクは、Oracle Clusterwareでクラスタ・ノードのメンバーシップおよび状態の検証に使用されるファイルです。
投票ディスク・ファイルの場所は、インストールを実行しているユーザー(oracleまたはgrid)が所有し、権限が640に設定されている必要があります。

- Oracle Cluster Registryファイル(OCR)には、Oracle Clusterwareのクラスタおよびデータベースの構成情報が含まれます。
インストール前は、インストールを実行するユーザー(gridまたはoracle)がOCRファイルの場所を所有している必要があります。そのインストール・ユーザーのプライマリ・グループはoinstallである必要があります。インストール中、インストーラによってOCRファイルが作成され、パスおよびOCRファイルの所有権がrootに変更されます。

1.1.6 Oracle Grid Infrastructureのインストール開始時の作業

表1-6 インストーラの起動前に実行するOracle Grid Infrastructureのチェック

チェック

作業

Oracleプロセスの実行を確認し、必要に応じて停止する

- Oracle ASMを使用していないスタンドアロンのデータベースが存在するノードの場合: Oracle Grid Infrastructureソフトウェアのインストールの間、データベースを停止する必要はありません。

- Oracle ASMを使用するスタンドアロンのOracle Databaseが存在するノードの場合: 既存のOracle ASMインスタンスを停止します。Oracle ASMインスタンスは、インストール中に再起動されます。

- Oracle RAC Databaseノードの場合: このインストールでは、Oracle ClusterwareがOracle RACを実行する必要があるため、Oracle Clusterwareのアップグレードが必要です。アップグレードの一環として、データベースを停止する必要がありますが、その際、一度に1ノードずつ停止します。これは、ローリング・アップグレードがノードからノードへと実行されるためです。

インストール中にcronジョブが実行されないことを確認する

日常のcronジョブが開始するときにインストーラが実行中の場合、インストールの完了前にcronジョブによるクリーンアップが実行されて一時ファイルが削除されると、予期しないインストールの問題が発生することがあります。日常のcronジョブを実行する前にインストールを完了するか、インストールが完了するまで、クリーンアップを行う日常のcronジョブを無効にすることをお薦めします。

他の言語をインストールするかどうかを決定する

インストール中に、ユーザー・インタフェースのテキストをデフォルト(英語)以外の言語に翻訳するかどうかを選択します。オペレーティング・システムの言語セットがインストーラでサポートされていない場合、インストーラは、デフォルトでは英語で実行されます。

キャラクタ・セットおよび言語構成の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

2 Oracle Grid InfrastructureおよびOracle RACのサーバーの構成

この章では、クラスタ用のOracle Grid InfrastructureとOracle Real Application Clusters (Oracle RAC)をインストールする前に、サーバーで完了する必要があるオペレーティング・システムの構成作業について説明します。この章に示す値は、最低限のインストール用です。計画されたシステム負荷に応じて、本番システムを設定することをお薦めします。

この章の内容は次のとおりです。

- サーバーのハードウェアとメモリー構成の確認

- 一般的なサーバーの最小要件

- サーバーの最小記憶域要件

- サーバーの最小メモリー要件

2.1 サーバーのハードウェアとメモリー構成の確認

システムが各要件を満たしていることを確認するには、次の手順を実行します。

1. 次のコマンドを入力して、物理RAMのサイズを確認します。

# /usr/contrib/bin/machinfo  | grep -i Memory

システムに搭載されている物理RAMのサイズが要件のサイズより少ない場合、次の手順に進む前にメモリーを増設する必要があります。

2. 次のコマンドを入力して、構成されたスワップ領域のサイズを確認します。

# /usr/sbin/swapinfo -a

注意:

- 値をファイナライズする前に、使用可能なRAM領域およびスワップ領域用に複数の値を選択することをお薦めします。これは、使用可能なRAMとスワップ領域が、ユーザーとコンピュータの対話に応じて変化するためです。

- サーバーのスワップ領域の割当てガイドラインについては、ご使用のオペレーティング・システムのベンダーにお問い合せください。ベンダーのガイドラインは、このマニュアルに示すスワップ領域要件より優先されます。

3. 次のコマンドを入力して、/tmpディレクトリで使用できるディスク領域の大きさを確認します。

- # bdf /tmp

/tmpディレクトリで使用できるディスク領域が7GB未満の場合、次のいずれかの手順を完了します。

- 必要なディスク領域を確保するために、/tmpディレクトリから不要なファイルを削除します。

- /tmpディレクトリを含むファイル・システムを拡張します。ファイル・システムの拡張については、必要に応じてシステム管理者に連絡してください。

4. 次のコマンドを入力して、システムの空きディスク領域の大きさを確認します。

# bdf

5. 次のコマンドを入力して、システム・アーキテクチャでソフトウェアを実行できるかどうかを確認します。

$ uname -m

プロセッサ・アーキテクチャがインストールするOracleソフトウェアのリリースと適合することを確認します。

想定した出力(ia64)が表示されない場合、このシステムにそのソフトウェアはインストールできません。

6. 共有メモリー・カーネル・パラメータ(shmmni、shmsegおよびshmmax)を表示して、システムに変更が必要かどうかを判断します。

kctune -v shmmni
kctune -v shmseg
kctune -v shmmax

kctune shmmni=1024コマンドを使用して、メモリー・カーネル・パラメータを必要な値に設定します。共有メモリーの計画の詳細は、第2.4項「サーバーの最小メモリー要件」を参照してください。

2.2 一般的なサーバーの最小要件

- 同じ命令セット・アーキテクチャのサーバーを選択します(同じクラスタ・スタックで32-bitおよび64-bitのOracleソフトウェア・バージョンを実行することはできません)。

- サーバーが実行レベル3で起動されていることを確認します。

- システム・コンソールベースのインストールを実行する間、OUIが正しく表示されるように、ディスプレイ・カードのディスプレイ解像度を1024×768以上にします。

- 各サーバーで、同じオペレーティング・システム・バイナリが実行されていることを確認します。

- Oracle Grid InfrastructureインストールとOracle Real Application Clusters(Oracle RAC)では、同一クラスタ内でハードウェアが異なるサーバーを使用できます。クラスタに異なる処理速度やサイズのCPUを搭載するノードをインストールできますが、ハードウェア構成が同じノードを使用することをお薦めします。
異なる構成を使用してクラスタを構成する場合、サーバー・カテゴリ化管理ポリシーの一部として同種のプールにクラスタ・ノードを分類することをお薦めします。

関連項目:
サーバーの状態と構成属性の詳細およびサーバー・プールを使用してリソースとワークロードを管理する方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

2.3 サーバーの最小記憶域要件

各システムは、次の最小記憶域要件を満たしている必要があります。

- /tmpディレクトリに1GBの領域。
/tmpディレクトリの空き領域が、必要な領域の要件を満たさない場合、次のいずれかの手順を実行します。

- 必要な領域を確保するために、/tmpディレクトリから不要なファイルを削除します。

- /tmpディレクトリを含むファイル・システムを拡張します。ファイル・システムの拡張については、必要に応じてシステム管理者に連絡してください。

- クラスタ用Oracle Grid Infrastructureホーム(Gridホーム)に8GB以上の領域。パッチ用の追加領域を確保するために100GBを割り当てることをお薦めします。

- Oracle Grid Infrastructureインストール所有者(Gridユーザー)のOracleベース用に12GB以上の領域。Oracleベースには、Oracle ClusterwareおよびOracle ASMのログ・ファイルが含まれます。

- トレース・ファイル・アナライザ(TFA)コレクタによって生成された診断収集用に、グリッド・インフラストラクチャ所有者のOracleベース・ディレクトリに10GBの追加の領域。

Oracle Databaseのインストールでは、自動バックアップを構成する場合は、高速リカバリ領域用に追加の領域(ファイル・システムまたはOracle Automatic Storage Managementディスク・グループ)が必要です。

関連項目:
高速リカバリ領域のサイジングの詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照

2.4 サーバーの最小メモリー要件

システム・アーキテクチャに応じて、システムが次の最小要件を満たしていることを確認します。

- 64-bitシステムの最小メモリー要件

- 共有メモリーの要件

注意:
スワップ領域のサイズが足りないというOUIエラーが発生したにもかかわらず、スワップ領域はここに記載された要件を満たしている場合は、エラーを無視してかまいません。

2.4.1 64-bitシステムの最小メモリー要件

各システムは、次の最小メモリー要件を満たしている必要があります。

- Cluster用Oracle Grid Infrastructureインストール用に4GB以上のRAM(Oracle RACをインストールする計画があるインストールを含む)。

- 次の表に示す使用可能なRAMの倍数と同等のスワップ領域

表2-1 64-bitシステムで必要なスワップ領域

使用可能なRAM

必要なスワップ領域

4GBから16GB

RAMと同等

16GBを超える

16GBのRAM

注意:
32ビット・システムはサポート対象外となりました。

2.4.2 共有メモリーの要件

Oracle DatabaseまたはOracle RACデータベースをクラスタ上にインストールする場合、各サーバーの共有メモリのマウント領域は、サーバーのデータベースのシステム・グローバル領域(SGA)およびプログラム・グローバル領域(PGA)よりも大きいサイズである必要があることに注意してください。SGAおよびPGAの予想サイズをデータベース管理者に確認し、データベースをクラスタにインストールした後に共有メモリのマウント領域を増やす必要がないようにしてください。

3 Oracle Grid InfrastructureおよびOracle RACのオペレーティング・システムの構成

この章では、Oracle Universal Installer(OUI)を起動してクラスタ用Oracle Grid Infrastructureをインストールする前に完了する必要があり、クラスタにOracle Real Application Clusters(Oracle RAC)をインストールする場合に完了する必要があるシステム構成作業について説明します。

この章の内容は次のとおりです。

- オペレーティング・システムとソフトウェア・アップグレードに関するベスト・プラクティスの確認

- オペレーティング・システムの一般的なセキュリティの措置の確認

- インストール修正スクリプトの使用

- X端末を使用したリモート・システムへのログイン

- ソフトウェア要件について

- HP-UX Itaniumプラットフォームでのオペレーティング・システム要件

- HP-UX用の追加ドライバとソフトウェア・パッケージ

- ソフトウェア要件の確認

- クラスタ時刻同期のためのネットワーク・タイム・プロトコルの設定

- インストール時におけるSSHの自動構成の使用

- 必須のシンボリック・リンクの作成

- デバイス・ファイルのマイナー番号の設定

- 実行レベルおよびネーム・サービス・キャッシュ・デーモンの確認

3.1 オペレーティング・システムとソフトウェアのアップグレードに関するベスト・プラクティスの確認

アップグレードに関して次の点を確認してください。

- アップグレードの一般的なベスト・プラクティス

- Oracle ASMのアップグレード通知

- ローリング・アップグレード手順の通知

3.1.1 アップグレードの一般的なベスト・プラクティス

すでにOracleがインストールされている場合は、次の手順を実行します。

注意:
構成の変更を開始する前に、既存のデータベースのバックアップを必ず作成してください。

- バージョン番号、パッチおよびその他の構成情報を記録します

- 既存のインストールのアップグレード手順を確認します。

- インストールを進める前に、アップグレードに関するOracleドキュメントを確認し、その後の処理を確認します。

最新のソフトウェア更新情報や、アップグレードの前後、互換性、相互運用性に関する推奨ベスト・プラクティスについては、「Oracle 12c Upgrade Companion」(My Oracle SupportのNote 1462240.1)を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1462240.1

関連項目:
付録B「Oracle Grid Infrastructure 12cリリース1へのアップグレード方法」

3.1.2 Oracle ASMのアップグレード通知

Oracle ASMアップグレードに関して、次の問題に注意してください。

- Oracle Automatic Storage Management (Oracle ASM) 11gリリース1(11.1)以上では、クラスタ内の個別のノードに対して、または複数のノードに対してまとめてローリング・アップグレードを行うことで、Oracle RACデータベースを停止することなくアップグレードできます。ただし、Oracle ASMを使用しているクラスタにスタンドアロン・データベースがある場合、アップグレードする前にそのスタンドアロン・データベースを停止する必要があります。Oracle ASM 10gからアップグレードする場合は、Oracle ASMクラスタ全体を停止してアップグレードを行う必要があります。

- Oracle Grid Infrastructure 11 gリリース2 (11.2)では、Oracle ASMがOracle ClusterwareとともにOracle Grid Infrastructureホーム(Gridホーム)にインストールされるように、Oracle ASMホームの場所が変更されました。
以前のリリースのOracle ASMホームがすでにある場合は、Oracle Clusterwareのアップグレードに使用する予定のユーザーが所有している必要があります。

3.1.3 ローリング・アップグレード手順の通知

ローリング・アップグレードに関して、次の情報に注意してください。

- オペレーティング・システムのローリング・アップグレード時に、そのオペレーティング・システムの両方のバージョンが、使用しているOracle Databaseリリースで保証されている場合は、異なるオペレーティング・システム・バイナリを使用できます。

- 異なるバージョンのオペレーティング・システムを混在させて使用できるのは、アップグレードの間のみです。
異なるバージョンのオペレーティング・システムを使用できるのは、アップグレードの間の数時間のみであることに注意してください。

- Oracle Clusterwareでは、同じクラスタで異なる命令セット・アーキテクチャ(ISA)を使用するプロセッサを搭載するノードはサポートされていません。各ノードは、バイナリ・レベルでクラスタ内の他のノードとの互換性が必要です。
たとえば、同じクラスタの1つのノードでIntel 64プロセッサを使用し、別のノードでIA-64(Itanium)プロセッサを使用することはできません。同じクラスタの1つのノードでIntel 64プロセッサを使用し、別のノードでAMD64プロセッサを使用することはできますが、これは、プロセッサが同じx86-64 ISAを使用し、同じバイナリ・バージョンのOracleソフトウェアを実行するためです。

3.2 オペレーティング・システム・セキュリティの共通プラクティスの確認

セキュアなオペレーティング・システムは、一般的なシステム・セキュリティの重要な基本です。オペレーティング・システムのデプロイメントが、オペレーティング・システム・ベンダーのセキュリティ・ガイドに記載されている一般的なセキュリティの措置に準拠していることを確認してください。

3.3 インストール修正スクリプトの使用

インストールの最小要件を満たしていない場合はOracle Universal Installer(OUI)によって検知され、要件を満たしていないシステム構成手順を実行するために、修正スクリプトと呼ばれるシェル・スクリプトが作成されます。OUIによって不完全な作業が検知されると、修正スクリプト(runfixup.sh)が生成されます。「修正および再チェック」をクリックした後で、修正スクリプトを実行できます。

CVUで、インストールの前に修正スクリプトを生成することもできます。

関連項目:
cluvfyコマンドの使用の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

修正スクリプトでは、次のことが実行されます。

- 必要に応じて、インストールを正しく実行するために必要な値を次のカーネル・パラメータに設定します。

- 共有メモリのパラメータ

- オープン・ファイル記述子とUDP送受信のパラメータ

- Oracle Inventory(中央インベントリ)ディレクトリに権限を作成し、設定します。

- インストール所有者、必要な場合はOracle Inventoryディレクトリおよびオペレーティング・システム権限グループの、プライマリおよびセカンダリ・グループ・メンバーシップを作成または再構成します。

- 必要に応じて、シェル制限に必須の値を設定します。

注意:
HTTPまたはFTPのプロキシ・アドレスを設定していない場合には、カーネル・パッケージの更新を含む構成タスクの一部が正常に完了しない場合があります。

インストールに使用するユーザー・アカウントのために、クラスタ・メンバー・ノード間で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

3.4 X端末を使用したリモート・システムへのログイン

インストール中は、rootまたは他のユーザーとして、リモート端末上で作業を行う必要があります。リモート表示できるようにする必要があるユーザー・アカウントに対して、次の手順を実行します。

注意:
別のユーザー(oracleなど)としてログインする場合は、そのユーザーでもこの手順を繰り返します。

リモート表示を可能にするには、次のいずれかの手順を実行します。

- ソフトウェアをX Window SystemワークステーションまたはX端末からインストールする場合は、次の手順を実行します。

1. Xターミナル・セッション(xterm)を開始します。

2. ソフトウェアを別のシステムにインストールし、そのシステムをX11ディスプレイとして使用する場合は、次の構文を使用してコマンドを入力し、リモート・ホストがローカルのXサーバーでXアプリケーションを表示できるようにします。

# xhost + RemoteHost

RemoteHostは完全修飾されたリモートのホスト名です。次に例を示します。

# xhost + somehost.example.com
somehost.example.com being added to the access control list

3. ソフトウェアをローカル・システムにインストールしない場合は、sshコマンドを使用してソフトウェアをインストールするシステムに接続します。

# ssh -Y RemoteHost

RemoteHostは完全修飾されたリモートのホスト名です。-Yフラグ(Yes)により、元のX11ディスプレイに対する完全なアクセス権がリモートのX11クライアントに付与されます。次に例を示します。

# ssh -Y somehost.example.com

4. rootユーザーでログインしていない場合は、次のコマンドを入力してユーザーをrootに切り替えます。

$ su - root
password:
#

- Xサーバー・ソフトウェアがインストールされているPCまたはその他のシステムからソフトウェアをインストールする場合は、次の手順を実行します。

注意:
必要に応じて、この手順の実行の詳細についてX Window Systemのドキュメントを参照してください。使用しているXソフトウェアによっては、異なる順序でタスクを実行することが必要な場合があります。

1. X Window Systemソフトウェアを起動します。

2. X Window Systemソフトウェアのセキュリティ設定を、リモート・ホストでローカル・システムのXアプリケーションを表示できるように構成します。

3. ソフトウェアをインストールするリモート・システムに、クラスタ用Oracle Grid Infrastructureソフトウェアの所有者(grid、oracle)として接続し、システムでX端末(xterm)などの端末セッションを開始します。

4. リモート・システム上で別の端末セッションを開き、rootユーザーとしてリモート・システムにログインします。プロンプトが表示されたら、rootとしてスクリプトを実行できます。

3.5 ソフトウェア要件について

インストールする製品に応じて、必要なオペレーティング・システム・カーネルとパッケージがインストールされていることを確認してください。パッチ要件は必要最小限のパッチ・バージョンであり、前のパッチ番号は後のパッチ更新に含められていることに注意してください。

このマニュアルに記載されているのは、タイトル・ページに記載されている日付での最新の要件です。カーネル要件の最新情報については、次のURLのOracle Technology Networkでオンライン版を参照してください。

http://www.oracle.com/technetwork/indexes/documentation/index.html

OUIによって、ご使用のシステムが示されたオペレーティング・システムの要件を満たしていることを確認する検証が実行されます。これらの検証が正常に完了するように、OUIを起動する前に要件を確認してください。

注意:
オペレーティング・システムのアップグレード時を除いて、クラスタ・メンバー間で異なるオペレーティング・システム・バージョンを実行することはできません。各オペレーティング・システムがサポートされている場合でも、同じクラスタのメンバーで異なるオペレーティング・システム・バージョンのバイナリを実行することはできません。

3.6 HP-UX Itaniumプラットフォームでのオペレーティング・システム要件

表3-1 HP-UX Itaniumの要件

項目

要件

SSH要件

Oracle ClusterwareにはSSHが必要です。必要なSSHソフトウェアは、オペレーティングシステムに付属のデフォルトのSSHです。

オペレーティング・システム

HP-UX 11iV3パッチ・バンドルSep/ 2008 (B.11.31.0809.326a)以上

HP-UX 11.31パッケージとバンドル

次のパッチがインストールされている必要があります。

PHCO_43503 - 11.31 diskowner(1M) cumulative patch
PHKL_38038 - 11.31 vm cumulative patch
PHKL_38938 - 11.31 SCSI cumulative I/O patch
PHKL_40941 - 11.31 scheduler cumulative patch
PHSS_36354 - 11.31 assembler patch
PHSS_37042 - 11.31 hppac
PHSS_37959 - Libcl patch for alternate stack issue fix (QXCR1000818011)
PHSS_38141 - 11.31 aC++ Runtime
PHSS_39094 - 11.31 linker + fdp cumulative patch
PHSS_39100 - 11.31 Math Library Cumulative Patch
PHSS_39102 - 11.31 Integrity Unwind Library

Oracle Clusterware

すべてのHP-UX 11.31インストール

Oracle Clusterwareの追加要件はありません。

このリリースの時点では、Hyper Messagingプロトコル(HMP)はサポートされていません。

HP Serviceguard A.11.20をサポートしています。

注意: HP Serviceguardはオプションです。必要となるのは、Oracle Clusterwareまたはデータベース・ファイルに共有論理ボリュームを使用する場合のみです。

3.7 HP-UX用の追加ドライバとソフトウェア・パッケージ

追加のドライバやパッケージをインストールする必要はありませんが、次のリストのドライバおよびパッケージをインストールまたは構成することが可能です。

- Open Database Connectivityのインストール要件

- Oracle Messaging Gatewayのインストール要件

- HP-UX Itaniumシステムのプログラミング環境のインストール要件

- Webブラウザのインストール要件

3.7.1 Open Database Connectivityのインストール要件

Open Database Connectivity (ODBC)をインストールする場合は、次の項を確認してください。

- ODBCドライバおよびOracle Databaseについて

- HP-UX Itaniumシステム用のODBCドライバのインストール

3.7.1.1 ODBCドライバとOracle Databaseについて

Open Database Connectivity (ODBC)は、データベースにアクセスするためのAPIのセットで、データベースに接続してデータベース上でSQL文を実行します。ODBCドライバを使用するアプリケーションは、スプレッドシートやカンマ区切りファイルなど、不均一なデータ・ソースにアクセスできます。

3.7.1.2 HP-UX Itaniumシステム用のODBCドライバのインストール

HP-UX Itaniumでは、Oracle ODBCドライバはODBCドライバ・マネージャ2.3.1について動作保証されています。ODBCを使用するには、gcc 4.2.3以上もインストールする必要があります。

Oracle ClusterwareまたはOracle DatabaseにODBCドライバは必要ありません。

ODBCドライバを次のWebサイトからダウンロードし、インストールします。

http://www.unixodbc.org/

3.7.2 Oracle Messaging Gatewayのインストール要件

Oracle Messaging Gatewayのインストールについては、次の項を確認してください。

- Oracle Messaging Gatewayの概要

- Oracle Messaging Gatewayのインストール

3.7.2.1 Oracle Messaging Gatewayの概要

Oracle Messaging Gatewayは、Oracle Databaseの機能の1つです。これを使用すると、Oracle以外のメッセージ・システムとOracle Streams Advanced Queuingに基づくアプリケーション間の通信が可能になります。

Oracle Messaging Gatewayでは、Oracle Streams Advanced Queuing (AQ)とWebSphereおよびTIBCO Rendezvousをベースとするアプリケーションとの統合がサポートされています。サポートされるバージョンについては、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。

3.7.2.2 Oracle Messaging Gatewayのインストール

Oracle Messaging GatewayはOracle Databaseでインストールされます。

My Oracle Supportの証明書で最新の要件を確認してください。証明書は次のURLで入手できます。

https://support.oracle.com

IBM WebSphere MQのCSDが必要な場合は、次のWebサイトでダウンロードおよびインストールの情報を参照してください。

http://www.ibm.com

3.7.3 HP-UX Itaniumシステムのプログラミング環境のインストール要件

プログラミング環境をインストールする場合は、次の項を確認してください。

- プログラミング環境およびOracle Databaseについて

- プログラミング環境のサポートの構成

3.7.3.1 プログラミング環境とOracle Databaseについて

Oracle Databaseでは、様々な環境でのアプリケーション開発用に複数のプログラミング言語がサポートされています。一部の言語では、使用しているオペレーティング・システムの追加のコンパイラ・パッケージをインストールする必要があります。

プログラミング環境は任意です。Oracle Databaseに必須ではありません。

関連項目:
プログラミング環境の概要は、Oracle Databaseアドバンスト・アプリケーション開発者ガイドを参照してください。

3.7.3.2 プログラミング環境のサポートの構成

システムが、構成するプログラミング環境の要件を満たしていることを確認してください。

表3-2 HP-UX Itaniumシステムのプログラミング環境の要件

プログラミング環境

サポート要件

Java Database Connectivity (JDBC) / Oracle Call Interface (OCI)

Oracle Java Database ConnectivityおよびOracle Call InterfaceのドライバとJNDI拡張機能付きJDK 6 (1.6.0.16)またはJava 7 (1.7.0.00)以上を使用してください。

このリリースでは、JDK 1.6.0.16がインストールされています。

注意: これらはOracle Grid Infrastructureのインストールにおいて必須ではありません。

Pro*C/C++、
Oracle Call Interface、
Oracle C++ Call Interface、
Oracle XML Developer's Kit (XDK)

コンパイラ・バージョン: A.06.20 (HP C/aC++ Swlist Bundle - C.11.31.04) - Sep 2008

HP-UX Itanium上のHP-UX 11i V3(11.31)用パッチ:

- PHSS_39824 - 11.31 HP C/aC++ Compiler(A.06.23)patch

- PHSS_39826 - 11.31 u2comp/be/plugin (C.06.23) patch

デプロイするアプリケーションに応じて、追加のパッチが必要な場合があります。

Pro*COBOL

Micro Focus Server Express 5.1

Pro*FORTRAN

HP FORTRAN/90 - Sep 2008リリース

VERITASファイル・システム

PHKL_39773: 11.31 VRTS 5.0 GARP6 VRTSvxfs Kernel Patch

注意: VERITAS File Systemはオプションです。このパッチは、VERITAS File System 5.0を使用する場合にのみ必要です。

3.7.4 Webブラウザのインストール要件

Oracle Enterprise Manager Database ExpressおよびOracle Enterprise Manager Cloud Controlを使用する場合のみ、Webブラウザが必要です。WebブラウザがJavaScriptおよびHTML 4.0標準とCSS 1.0標準をサポートしている必要があります。これらの要件を満たすブラウザの一覧については、My Oracle SupportでEnterprise Manager動作保証マトリックスを参照してください。

https://support.oracle.com

関連項目:
Enterprise Manager動作保証マトリックスにアクセスする手順については、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

3.8 ソフトウェア要件の確認

システムがこれらの要件を満たしていることを確認するには、次の手順を実行します。

1. 次のコマンドを入力して、インストールされているHP-UXのバージョンを確認します。

# uname -a
"HP-UX hostname B.11.31 U ia64 4156074294 unlimited-user license"

この例では、HP-UX 11iのバージョンはItanium上の11.31です。

2. 次のコマンドを使用して、システムが最小パッチ・バンドル要件を満たしていることを確認します。

# /usr/sbin/swlist -l bundle |grep QPK

QPK(Quality Pack)バンドルには、B.11.31.0809.326a(2008年9月リリースの場合)や、B.11.31.0903.334a(2009年3月リリースの場合)という形式のバージョン番号が付いています。必要なバンドル、製品またはファイルセットがインストールされていない場合は、インストールする必要があります。製品のインストールについては、ご使用のオペレーティング・システムまたはソフトウェアのマニュアルを参照してください。

注意:
前の段落にリストされているパッチのバージョンより新しいパッチがシステムにインストールされている場合があります。記載のパッチがインストールされていない場合、記載のバージョンをインストールする前に、それより新しいバージョンがインストールされているかどうかを確認します。

3. 必要なパッチがインストールされていない場合は、次のWebサイトからダウンロードしてインストールします。
http://itresourcecenter.hp.com">>http://itresourcecenter.hp.com

Webサイトに表示されるパッチのバージョンの方が新しい場合は、そのバージョンをダウンロードしてインストールします。

4. WebSphere MQのCSDが必要な場合は、次のWebサイトでダウンロードおよびインストールの情報を参照してください。
http://www.ibm.com

注意:
リストされているパッチのバージョンより新しいパッチがシステムにインストールされている場合があります。リストされているパッチがインストールされていない場合、リストされているバージョンをインストールする前に、より新しいバージョンがインストールされているかどうかを確認します。

3.9 クラスタ時刻同期のためのネットワーク・タイム・プロトコルの設定

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サービスを非アクティブ化するには、既存のntpdサービスを停止し、初期化シーケンスでは無効化し、ntp.confファイルを削除します。この手順を行うには、次のコマンドをrootユーザーとして実行します。

# /sbin/init.d/xntpd stop
# rm /etc/ntp.conf

または、mv /etc/ntp.conf /etc/ntp.conf.orgを実行します。

NTPプロトコルがアクティブでないとインストーラによって判断されると、クラスタ時刻同期化サービスがアクティブ・モードでインストールされ、ノード間で時刻が同期されます。NTPが構成されていると判断された場合は、クラスタ時刻同期化サービスはオブザーバ・モードで起動され、クラスタ内でOracle Clusterwareによるアクティブな時刻同期化は行われません。

インストール後にctssdがアクティブになっていることを確認するには、グリッド・インストール所有者として次のコマンドを入力します。

$ crsctl check ctss

3.10 インストール時におけるSSHの自動構成の使用

Oracleソフトウェアをインストールするには、すべてのクラスタ・メンバー・ノード間にセキュア・シェル(SSH)の接続が設定されている必要があります。OUIは、インストール中にsshおよびscpコマンドを使用して、他のクラスタ・ノードに対してリモート・コマンドを実行し、そのクラスタ・ノードにファイルをコピーします。これらのコマンドを使用する際にパスワードを求めるプロンプトが表示されないように、SSHを構成する必要があります。

注意:
SSHは、Oracle Configuration Assistantによる、ローカル・ノードからリモート・ノードに対する構成操作に使用されます。Enterprise Managerでも使用されます。

OUIインタフェースから、インストール中に、インストールを実行しているユーザー・アカウントにSSHを構成することができます。自動構成によって、パスワードなしのSSH接続をすべてのクラスタ・メンバー・ノード間に作成することができます。可能なかぎり、この自動手順を利用することをお薦めします。

スクリプトを実行できるようにするには、すべてのOracleソフトウェア・インストール所有者のプロファイルからsttyコマンドを削除するとともに、ログイン時にトリガーされる他のセキュリティ手段で、端末に対してメッセージを生成するものを削除する必要があります。これらのメッセージやメール・チェックなどが表示されていると、Oracleソフトウェア・インストール所有者は、Oracle Universal Installerに組み込まれているSSH構成スクリプトを使用できません。これらの表示が無効になっていない場合は、SSHを手動で構成してからでなければ、インストールを実行できません。

まれに、リモート・ノードがSSH接続を閉じると、「AttachHome」操作時にOracle Clusterwareインストールが失敗する場合があります。この問題を回避するために、すべてのクラスタ・ノードでSSHデーモン構成ファイル/opt/ssh/etc/sshd_configに次のパラメータを設定し、タイムアウト待機時間を無制限に設定します。

LoginGraceTime 0

関連項目:
ユーザー・プロファイルのsttyコマンドを削除する方法の詳細は、第5.2.4項「インストール中に端末出力コマンドによって発生するエラーの防止」を参照してください。

3.11 必須のシンボリック・リンクの作成

注意:
この作業は、Motif 2.1開発環境パッケージ(X11MotifDevKit.MOTIF21-PRG)がインストールされていない場合にのみ必要です。

このソフトウェアをインストールした後で、Oracle製品を正常に再リンクできるようにするには、次のコマンドを使用して、必須のXライブラリ・シンボリック・リンクを/usr/libディレクトリに作成します。

# cd /usr/lib
# ln -s libX11.3 libX11.sl
# ln -s libXIE.2 libXIE.sl
# ln -s libXext.3 libXext.sl
# ln -s libXhp11.3 libXhp11.sl
# ln -s libXi.3 libXi.sl
# ln -s libXm.4 libXm.sl
# ln -s libXp.2 libXp.sl
# ln -s libXt.3 libXt.sl
# ln -s libXtst.2 libXtst.sl

3.12 デバイス・ファイルのマイナー番号の設定

Oracle Universal Installerでは、前提条件チェック時に、すべてのノードの/dev/asyncデバイスのマイナー番号がデバイス・ファイルで0x4または0x104に設定されているか確認します。デフォルトでは、マイナー番号は0x0に設定されます。インストールの開始前にマイナー番号を変更するには、次の手順を実行します。

1. rootユーザーとしてログインします。

2. /dev/asyncが存在するか確認します。デバイスが存在しない場合、次のコマンドを使用し作成します。

# /sbin/mknod /dev/async c 101 0x4

また、次のコマンドを使用するとマイナー番号値を0x104に設定できます。

# /sbin/mknod /dev/async c 101 0x104

3. /dev/asyncが存在する場合、次の例のとおりマイナー番号の現在の値を確認します。

# ls -l /dev/async

crw-r--r--   1 root       sys        101 0x000000 Sep 28 10:38 /dev/async

4. ファイルの現在のマイナー番号が0x4または0x104でない場合、次のいずれかのコマンドを使用し、期待の値に変更します。

# /sbin/mknod /dev/async c 101 0x4
or
# /sbin/mknod /dev/async c 101 0x104

3.13 実行レベルおよびネーム・サービス・キャッシュ・デーモンの確認

Oracle ClusterwareがNASデバイスまたはNFSマウントの使用によるネットワーク障害をより許容できるようにするには、ネーム・サービス・キャッシュ・デーモン(nscd)を有効にします。nscdによって、最も一般的なネーム・サービス・リクエストに対するキャシング・メカニズムが提供されます。システムがマルチユーザーの状態で起動すると、自動的に起動します。Oracleソフトウェアでは、サーバーがマルチユーザー実行レベル(3)で起動される必要があります。これはHP-UXのデフォルトです。

サーバーが3に設定されていることを確認するには、コマンドwho -rを入力します。次に例を示します。

# who -r
.run-level 3  Jan 4 14:04     3      0  S

実行レベルの変更が必要な場合は、ご使用のオペレーティング・システムのドキュメントを参照してください。

パスワードおよびグループのキャッシュ・デーモン(pwgrd)が実行されていることを確認するには、次のコマンドを入力します。

ps -aef |grep pwgrd

4 Oracle Grid InfrastructureおよびOracle RACのネットワークの構成

次の項で、クラスタ用Oracle Grid Infrastructure環境に必要なネットワーク・ハードウェアおよびインターネット・プロトコル(IP)・アドレスがあるかを確認します。

この章の内容は次のとおりです。

- ネットワーク・インタフェースのハードウェア要件

- IPインタフェース構成の要件

- プライベート・インターコネクト冗長ネットワークの要件

- IPv4およびIPv6プロトコルの要件

- Oracle Grid InfrastructureのIP名およびアドレスの要件

- Oracle Flex ASMクラスタ・ネットワークについて

- Oracle Grid Infrastructureが使用するネットワークのブロードキャスト要件

- Oracle Grid Infrastructureが使用するネットワークのマルチキャスト要件

- グリッド・ネーミング・サービスへのドメイン委任

- Oracle Flex Clusterの構成要件

- グリッド・ネーミング・サービスの標準クラスタの構成例

- 手動によるIPアドレスの構成例

- ネットワーク・インタフェース構成のオプション

関連項目:
Oracle RAC環境でサポートされるネットワーク・プロトコルおよびハードウェアの最新情報は、My Oracle Supportの「動作保証」ページを参照してください。
https://support.oracle.com

4.1 ネットワーク・インタフェースのハードウェア要件

次にネットワーク構成要件を示します。

- 各ノードには2つ以上のネットワーク・アダプタまたはネットワーク・インタフェース・カード(NIC)が必要です。パブリック・ネットワーク・インタフェース用とプライベート・ネットワーク・インタフェース(インターコネクト)用のネットワーク・アダプタです。
ノードをOracle Grid Infrastructure 11gリリース2 (11.2.0.2)以上にアップグレードする場合、アップグレードされたシステムは既存のネットワーク分類を使用します。

複数のパブリック・インタフェースを構成するには、ご使用のプラットフォーム用のサード・パーティ・テクノロジを使用して、インストールを開始する前に複数のパブリック・インタフェースを集約する必要があります。その後、結合されたインタフェースの単一のインタフェース名をパブリック・インタフェースとして選択します。Oracle Grid Infrastructureのインストール中に、複数のパブリック・インタフェース名を指定しないことをお薦めします。集約テクノロジを使用せずに、2つのネットワーク・インタフェースをクラスタ内のパブリック・ネットワーク・インタフェースとして構成する場合、ノード上の1つのパブリック・インタフェースで発生した障害によって、もう1つのパブリック・インタフェースへの自動VIPフェイルオーバーが行われることはないことに注意してください。

プライベート・ネットワークに複数のインタフェースを使用するには、冗長インターコネクト機能を使用することをお薦めします。ただし、サード・パーティのテクノロジを使用しても、プライベート・ネットワークを冗長にすることは可能です。

注意:
冗長インターコネクトを使用する場合、完全なOracle Grid InfrastructureおよびOracle Databaseリリース2 (11.2.0.2)または上位のスタックが必要です。以前のOracle Databaseのリリースでは、この機能を利用できず、サード・パーティのNICボンディング技術を使用する必要がありました。異なるデータベース・リリースを1つのクラスタで統合し、Oracle Database 11gリリース2 (11.2.0.2)より前のデータベースを使用する場合は、両方の技術が必要な場合があります。

- パブリック・ネットワークの場合、各ネットワーク・アダプタではTCP/IPがサポートされている必要があります。

- プライベート・ネットワークでは、インタフェースにTCP/IPをサポートする高速ネットワーク・アダプタおよびスイッチ(最低要件: 1ギガビット・イーサネット)を使用して、ユーザー・データグラム・プロトコル(UDP)がサポートされている必要があります。

注意:
UDPは、Oracle RAC用およびOracle Clusterware用のデフォルトのインタフェース・プロトコルです。インターコネクト用のスイッチを使用する必要があります。専用のスイッチを使用することをお薦めします。
インターコネクト用のトークン・リングまたはクロスオーバー・ケーブルはサポートされていません。

4.2 IPインタフェース構成の要件

- プライベート・ネットワークに単一のインタフェースを使用するクラスタの場合、各ノードのインターコネクト用のプライベート・インタフェースは同じサブネット上にある必要があり、そのサブネットはクラスタのすべてのノードに接続する必要があります。たとえば、プライベート・インタフェースのサブネット・マスクが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を使用して、インターコネクト・インタフェースが接続可能であるかどうかをテストできます。

4.3 プライベート・インターコネクト冗長ネットワークの要件

冗長インターコネクトを使用すると、ボンディングなどのテクノロジを使用しなくても、複数のインタフェースを指定してクラスタ・プライベート・ネットワークに使用することができます。この機能は、Oracle Database 11gリリース2(11.2.0.2)以上で使用できます。Oracle Clusterwareの冗長インターコネクト機能を使用する場合は、インタフェースにIPv4アドレスを使用する必要があります。

複数のインタフェースを定義すると、Oracle Clusterwareは1つから4つの高可用性IP(HAIP)アドレスを作成します。Oracle RACおよびOracle Automatic Storage Management (Oracle ASM)インスタンスはこれらのインタフェース・アドレスを使用して、ノード間でのロード・バランシングされた高可用性インタフェース通信を保証します。インストーラは、冗長インターコネクトを使用して、高可用性プライベート・ネットワークを提供します。

デフォルトでは、Oracle Grid InfrastructureソフトウェアはすべてのHAIPアドレスをプライベート・ネットワーク通信に使用して、プライベート・ネットワークとして指定した一連のインタフェースにロード・バランシングを提供します。プライベート・インターコネクト・インタフェースに障害が発生するか、または通信できなくなった場合、Oracle Clusterwareは、機能している残りのインタフェースのいずれかに対応するHAIPアドレスを透過的に移動します。

注意:
インストール中、プライベート・ネットワークに最大4つのインタフェースを定義できます。インストール中に作成されるHAIPアドレスの数は、ネットワーク・アダプタに構成されている物理インタフェースと論理インタフェースによって異なります。インストール後、追加のインタフェースを定義できます。プライベート・ネットワーク・インタフェースとして5つ以上のインタフェースを定義した場合は、Oracle Clusterwareが一度にアクティブにするインタフェースは4つのみであることに注意してください。ただし、4つのアクティブなインタフェースのうちの1つに障害が発生した場合は、その障害が発生したインタフェースに構成されたHAIPアドレスを、一連の定義済プライベート・インタフェースのうちの予備インタフェースの1つに移します。

関連項目:
HAIPアドレスの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

4.4 IPv4およびIPv6プロトコルの要件

Oracle Grid InfrastructureとOracle RACは、RFC 2732で指定されている標準IPv6のアドレス表記法と、RFC 4193で定義されているグローバルおよびサイトローカルのIPv6アドレスをサポートしています。

クラスタ・メンバー・ノードのインタフェースは、IPv4、IPv6または両方のタイプのインターネット・プロトコル・アドレスを使用するように構成できます。ただし、次の点に注意してください。

- パブリックVIPを構成する場合: インストール時に、特定のパブリック・ネットワークのVIPアドレスに、IPv4またはIPv6タイプを構成できます。
サード・パーティーの技術を使用して冗長なネットワーク・インタフェースを構成する場合、Oracleでは、1つのインタフェースがIPv4アドレスをサポートし、別のインタフェースがIPv6アドレスをサポートするような構成はサポートしていません。冗長なインタフェースのネットワーク・インタフェースは、同じIPプロトコルを使用して構成する必要があります。

インストール時、IPv4とIPv6の両方のアドレスに解決されるVIPおよびSCAN名を使用してクラスタは構成できません。たとえば、一部のクラスタ・メンバー・ノードのVIPおよびSCANSはIPv4アドレスに解決されるように構成して、他のクラスタ・メンバー・ノードのVIPおよびSCANはIPv6アドレスに解決されるようにはできません。この構成はサポートされていません。

IPv6クラスタを構成するには、クラスタのIPv6サブネットに解決されるVIPおよびSCAN名を選択して、インストール時にそのサブネットをパブリックとして選択します。

IPv4クラスタに静的な仮想IP (VIP)アドレスを使用してインストールを行う場合、インストール時に指定したVIP名はIPv4アドレスのみに解決されます。静的なIPv6アドレスを使用してインストールを行う場合、インストール時に指定したVIP名はIPv6アドレスのみに解決されます。

インストール中、同じクラスタ内の一部のノードをすべてIPv6アドレスで構成し、他のノードをすべてIPv4アドレスで構成したり、一部のノードがIPv4アドレスまたはIPv6アドレスのみで構成されているのに、他のノードがIPv4アドレスとIPv6アドレスの両方で構成されるようにすることはできません。インストール中に、クライアントがIPv6アドレスまたはIPv4アドレスを使用して接続できるように選択できます。インストール後、IPv4アドレスをIPv6クラスタに、またはIPv6アドレスをIPv4クラスタに追加できます。

- プライベートIPインタフェース(インターコネクト)の構成: プライベート・ネットワークはIPv4ネットワークとして構成する必要があります。IPv6アドレスは、インターコネクトでサポートされません。

- GNSまたはマルチクラスタのアドレス: Oracle Grid InfrastructureはIPv4 DHCPアドレス、およびRFC 2462に記載されているステートレス・アドレス自動設定プロトコルで構成されているIPv6アドレスをサポートします。

注意:
RFC 1884で定義されているリンクローカルとサイトローカルのIPv6アドレスはサポートされません。

関連項目:

- RFC 2732およびIPv6表記の表現については、http://www.ietf.org/rfc/rfc2732.txtを参照してください。

- RFC 3513および正しいIPv6アドレス指定については、http://www.ietf.org/rfc/rfc3513.txtを参照してください。

- RFC 2462およびIPv6ステートレス・アドレス自動設定プロトコルについては、http://www.ietf.org/rfc/rfc2462.txtを参照してください。

- ネットワーク通信およびIPアドレス・プロトコルのオプションの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

4.5 Oracle Grid InfrastructureのIP名およびアドレスの要件

この項の内容は次のとおりです。

- Oracle Grid Infrastructureの名前解決オプションについて

- クラスタ名およびSCANの要件

- グリッド・ネーミング・サービス(GNS)のIP名およびアドレスの要件

- 標準クラスタの手動構成のIP名およびアドレスの要件

4.5.1 Oracle Grid Infrastructureの名前解決オプションについて

インストールを開始する前に、各ノードにインタフェースが2つ以上構成されている必要があります。1つはプライベートIPアドレス用、もう1つはパブリックIPアドレス用です。

IPアドレスは、次のいずれかのオプションで構成できます。

- マルチクラスタまたは標準のOracle Grid Naming Service (GNS)を使用した動的IPアドレスの割当て。このオプションを選択した場合、ネットワーク管理者は、GNS (標準またはマルチクラスタ)によって解決されるようにサブドメインを委任します。GNSの要件は、GNSをゾーン委任を使用して構成するよう選択するか(ドメインの解決をGNSに委任)、ゾーン委任を使用せず構成するかによって異なります(ドメインを委任しないGNS仮想IPアドレス)。
ゾーン委任を使用するGNSの場合:

- IPv4の場合、クラスタが使用するパブリック・ネットワーク上で実行されているDHCPサービス。

- IPv6の場合、クラスタが使用するパブリック・ネットワーク上で実行されている自動構成サービス。

- 各ノードのIPアドレスを1つずつ、そしてクラスタの単一クライアント・アクセス名(SCAN)によって使用される、クラスタのIPアドレスを3つ提供するのに十分なDHCPアドレス

- DNSまたはホスト・ファイルの解決を使用した静的IPアドレスの割当て。このオプションを選択すると、ネットワーク管理者は固定IPアドレスをクラスタの各物理ホスト名とOracle Clusterware管理VIPのIPに割り当てます。また、各ノードにドメイン・ネーム・サーバー(DNS)に基づいた静的名前解決が使用されるか、クラスタとクライアントの両方のホスト・ファイルを更新する必要があるため、SCAN機能は限定されます。このオプションを選択する場合は、クラスタの変更時にネットワーク管理の更新を依頼する必要があります。
ゾーン委任を使用しないGNSの場合:

クラスタにGNS仮想IPアドレス(VIP)を構成。Oracle Flex Clusterを有効にするには、GNS仮想IPアドレスを1つ以上構成する必要があります。

注意:
静的ホスト名をVIP以外のすべてのサーバー・ノード・パブリック・ホスト名に使用することをお薦めします。
パブリックIPアドレスと仮想IPアドレスは、同じサブネット内にある必要があります。

4.5.2 クラスタ名およびSCANの要件

クラスタ名は、組織全体で一意であり、長さは最短で1文字、最長で15文字であり、英数字を使用し、数字で開始されず、ハイフン(-)を含むことが可能です。アンダースコア文字(_)は許可されません。

標準クラスタを構成して標準インストールを選択する場合、SCANはクラスタの名前でもあります。この場合、SCANはクラスタ名の要件を満たす必要があります。SCANは、15文字以下にする必要があります。

拡張インストールでは、SCANとクラスタ名はインストール時に別のフィールドに入力するため、クラスタ名要件はSCANに使用される名前に適用されず、SCANの文字数を15文字より多くできます。SCAN名を使用しドメインに入り、ゾーン委任を使用するGNSを使用する場合、そのドメインはGNSドメインである必要があります。

注意:
名前は慎重に選択してください。インストールの完了後は、クラスタ名はOracle Grid Infrastructureを再インストールしないと変更できません。

4.5.3 グリッド・ネーミング・サービス(GNS)のIP名およびアドレスの要件

グリッド・ネーミング・サービス(GNS)を有効にする場合、クラスタへの名前解決要求はGNSに委任され、GNSによってGNS仮想IPアドレスでリスニングされます。ネットワーク管理者は、ドメイン・ネーム・サーバー(DNS)を、クラスタ名(クラスタに委任されたサブドメイン内のすべての名前)の解決要求がGNSに委任されるように構成する必要があります。要求がドメインに届くと、GNSによってその要求が処理され、要求された名前に対する適切なアドレスとともに応答が返されます。GNSを使用するには、GNS VIPアドレスに静的IPアドレスを指定する必要があります。

注意:
次の制限事項が、ご使用のシステムのベンダー構成に適用されます。

- 標準クラスタで、ベンダーのクラスタウェアがインストールされている場合、ベンダーのクラスタウェアはGNSをサポートしないため、GNSを使用するように選択することはできません。ベンダーのクラスタウェアは、Oracle Flex Cluster構成ではサポートされません。

- 別のマルチキャストDNSでGNSを使用することはできません。GNSを使用するには、システム上のすべてのサード・パーティmDNSデーモンを無効にします。

4.5.4 マルチクラスタのGNSのIP名およびアドレスの要件

マルチクラスタのGNSを使用する場合は、次の要件を確認します。

- マルチクラスタのGNSネットワークについて

- GNSサーバー・クラスタの構成

- GNSクライアント・クラスタの構成

- GNSクライアント・データ・ファイルの作成および使用

4.5.4.1 マルチクラスタのGNSネットワークについて

マルチクラスタのGNSの一般的要件は、標準のGNSの一般的要件に類似しています。マルチクラスタのGNSは、単一のクラスタにネットワーク・サービスを提供するのではなく、クラスタのセット全体で単一のネットワーク・サービスを提供する点が標準のGNSと異なります。

ネットワーク・サービスを提供するために、DHCPアドレスを使用してマルチクラスタのGNSが構成され、次のコンポーネントで名前の通知および解決が実行されます。

- GNSサーバー・クラスタは、GNSクライアント・クラスタのアドレス解決を実行します。GNSサーバー・クラスタは、マルチクラスタのGNSが実行され、クラスタのセットに委任されるサブドメインの名前解決が実行されるクラスタです。

- GNSクライアント・クラスタは、GNSサーバー・クラスタからアドレス解決を受け取ります。GNSクライアント・クラスタは、GNSサーバー・クラスタを使用してクラスタ・メンバー・ノード名を通知するクラスタです。

4.5.4.2 GNSサーバー・クラスタの構成

このオプションを使用するには、ネットワーク管理者により、解決するGNSにサブドメインが委任されている必要があります。

インストール前に、GNS VIPアドレスに対する静的IPアドレスを作成し、解決する静的GNS IPアドレスにDNSサーバーが委任するサブドメインを指定します。

4.5.4.3 GNSクライアント・クラスタの構成

GNSクライアント・クラスタを構成するには、次に示す要件がすべて満たされていることを確認します。

- GNSサーバー・インスタンスがネットワーク上で稼働しており、アクセス可能である必要があります(たとえば、ファイアウォールでブロックされていないこと)。

- GNSドメイン内のすべてのノード名が一意であり、アドレス範囲とクラスタ名がGNSサーバーおよびGNSクライアント・クラスタの両方で一意であることが必要です。

- 名前の解決をGNSサーバー・クラスタに委任するために必要な情報にGNSクライアント・クラスタがアクセスできるよう、GNSサーバー・クラスタにGNSクライアント・データ・ファイルを生成しておく必要があり、Oracle Grid Infrastructureインストールを実行しているGNSクライアント・クラスタ・メンバーに、そのファイルをコピーしておく必要があります。

4.5.4.4 GNSクライアント・データ・ファイルの作成および使用

GNSサーバー・クラスタ・メンバーで次のコマンドを実行します(path_to_fileは、作成するGNSクライアント・データ・ファイルの名前およびパスの場所)。

srvctl export gns -clientdata path_to_file

次に例を示します。

$ srvctl export gns -clientdata /home/grid/gns_client_data

GNSクライアント・クラスタのインストールを実行するGNSクライアント・ノード上の安全なパスに、GNSクライアント・データ・ファイルをコピーします。Oracleインストール・ユーザーには、このファイルへのアクセス権限が必要です。他のユーザーにGNSクライアント・データ・ファイルへのアクセス権限を付与しないことをお薦めします。インストールの実行中、そのファイルへのパスを入力するように求めるメッセージが表示されます。

GNSクライアント・クラスタ・インストールの完了後、いずれかのGNSサーバー・クラスタ・メンバーで次のコマンドを実行してGNSサービスを起動する必要があります(path_to_fileは、GNSクライアント・データ・ファイルの名前およびパスの場所)。

srvctl add gns -clientdata path_to_file

次に例を示します。

$ srvctl add gns -clientdata /home/grid/gns_client_data

関連項目:
GNSサーバーおよびGNSクライアント管理の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

4.5.5 標準クラスタの手動構成のIP名およびアドレスの要件

GNSを有効にしない場合は、インストールを開始する前に静的なクラスタ・ノード名とアドレスを構成する必要があります。

パブリックおよび仮想IP名は、英数字とハイフン("-")は使用できるがアンダースコア("_")は使用できないという、RFC 952標準に準拠している必要があります。

インストールのインタビュー時にプライベートとして指定したインタフェース上のプライベート・サブネットに含まれるプライベートIPアドレスが、Oracle Clusterwareによって管理されます。

クラスタの名前およびアドレスは、次のようにする必要があります。

- 次の特性がある、各ノードのパブリックIPアドレス:

- 静的IPアドレス

- 各ノードでインストール前に構成済で、インストール前にそのノードに対して解決可能

- クラスタ内の他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある

- 次の特性がある、各ノードの仮想IPアドレス:

- 静的IPアドレス

- 各ノードでインストール前に構成済だが、現在は使用されていない

- クラスタ内の他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある

- 次の特性がある、クラスタの単一クライアント・アクセス名(SCAN):

- SCANとして指定された名前に3つの静的IPアドレスが関連付けられ、そのすべてのアドレスがランダムな順序でDNSによってリクエスタに返されるように、インストール前にドメイン・ネーム・サーバー(DNS)上で静的IPアドレスが3つ構成されている

- 現在使用されていないアドレスに解決されるためにDNSでインストール前に構成済

- クラスタ内の他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にあるアドレスが指定される

- 先頭が数値以外であり、英数字とハイフン(-)は使用できるがアンダースコア(_)は使用できないという、RFC-952標準に準拠している名前が指定される

- 次の特性がある、各ノードのプライベートIPアドレス:

- 静的IPアドレス

- インストール前に構成済だが、独自のサブネットを持つ別のプライベート・ネットワーク上では、他のクラスタ・メンバー・ノード以外が解決することはできない

SCANは、クラスタへのサービス・アクセスをクライアントに提供するために使用される名前です。SCANは、特定のノードではなくクラスタ全体に関連付けされているため、クライアントの再構成を必要とせずに、クラスタでノードを追加または削除することを可能にします。また、データベースに場所の独立性がもたらされるため、クライアント構成は特定のデータベースがどのノードで実行されているかに依存しません。クライアントは引き続き、以前のリリースと同じ方法でクラスタにアクセスできますが、クラスタにアクセスするクライアントではSCANの使用をお薦めします。

注意:
標準インストールでは、指定したSCANはクラスタの名前でもあるため、SCAN名はクラスタ名の要件を満たしている必要があります。拡張インストールでは、SCANとクラスタ名はインストール時に別のフィールドに入力するため、クラスタ名要件はSCAN名に適用されません。

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解決を使用します。hostsファイルを使用してSCANを解決する場合、SCANは1つのIPアドレスのみに解決できます。
サポートされているのは、DNSまたはホスト・ファイルでのSCANの構成のみです。SCANをNetwork Information Service(NIS)で構成することはできません。

関連項目:
ネットワーク・アドレスの詳細は、付録D.2「ネットワーク・アドレスの理解」を参照してください。

4.6 Oracle Flex ASMクラスタのネットワークについて

Oracle Grid Infrastructure 12cリリース1 (12.1)以上では、Oracle Flex Clusterインストールの一部として、Oracle Grid Infrastructure内にOracle ASMが構成され記憶域サービスを提供します。各Oracle Flex ASMクラスタには、エンタープライズ内でグローバルに一意である固有の名前があります。

Oracle Flex ASMを使用すると、データベース・サーバーとは異なる物理サーバーでOracle ASMインスタンスを実行できます。多数のデータベース・クライアントをサポートするために、多くのOracle ASMインスタンスをクラスタ化できます。

すべての記憶域要件を単一のディスク・グループ・セットに統合できます。これらのディスク・グループはすべて、単一のOracle Flex Cluster内で実行されている小規模なOracle ASMインスタンス・セットによって管理されます。

すべてのOracle Flex ASMクラスタには、Oracle ASMインスタンスが実行される1つ以上のハブ・ノードがあります。

関連項目:

- Oracle Flex Clusterの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- Oracle Flex ASMの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

Oracle Flex ASMでは、Oracle Clusterwareと同じプライベート・ネットワークか、独自の専用プライベート・ネットワークを使用できます。各ネットワークは、パブリック、ASMとプライベート、プライベート、ASMのいずれかに分類できます。

Oracle Flex ASMクラスタ・ネットワークには、次の要件と特性があります。

- ASMネットワークは、インストール中に構成するか、インストール後に構成または変更できます。

クラスタ・ノードは次のように構成できます。

- 次の特性を持つOracle Flex ASMクラスタのハブ・ノード

- ハブ・ノード役割で構成されているすべてのサーバーがピアであるため、以前のリリースのOracle Grid Infrastructureのクラスタ・メンバー・ノードに類似しています。

- ASMディスクに直接接続します。

- 直接的なASMクライアント・プロセスを実行します。

- ハブ・ノードのみとしてASMディスクにアクセスします(これらは、その記憶域用のハブ・ノードとして指定されています)。

- Oracle Flex ASMクラスタに構成されているグローバルASMリスナーを介して委任されるサービス要求に応答します(このクラスタでは、Oracle Flex ASMクラスタ・メンバーのハブ・ノード・リスナーのうちの3つがOracle Flex ASMクラスタのリモート・リスナーとして指定されます)。

関連項目:
Oracle Flex ASMの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

4.7 Oracle Grid Infrastructureが使用するネットワークのブロードキャスト要件

ブロードキャスト通信(ARPおよびUDP)は、Oracle Grid Infrastructureで使用するために構成されたすべてのパブリックおよびプライベート・インタフェース全体で適切に動作する必要があります。

ブロードキャストは、パブリックまたはプライベート・インタフェースによって使用されるものとして構成されたVLAN全体で動作する必要があります。

Oracle RAC用のパブリックおよびプライベートのネットワーク・インタフェースを構成するときは、ARPを有効にする必要があります。高可用性IP (HAIP)アドレスはパブリック・ネットワーク上のARPを必要としませんが、VIPフェイルオーバーを行うにはARPの有効化が必要になります。NOARPを構成しないでください。

4.8 Oracle Grid Infrastructureが使用するネットワークのマルチキャスト要件

各クラスタ・メンバー・ノードでは、Oracle mDNSデーモンがすべてのインタフェースでマルチキャスティングを使用して、クラスタの他のノードと通信します。マルチキャスティングは、プライベート・インターコネクトで必要です。このため、少なくとも次のクラスタでマルチキャスティングを有効にする必要があります。

- プライベート・インターコネクトとして定義されたブロードキャスト・ドメイン全体

- IPアドレス・サブネット範囲224.0.0.0/24(およびオプションで230.0.1.0/24)

ルーター全体でマルチキャスト通信を有効にする必要はありません。

4.9 グリッド・ネーミング・サービスへのドメイン委任

標準クラスタのグリッド・ネーミング・サービス(GNS)を構成する場合は、Oracle Grid Infrastructureのインストール前に、GNSによって提供されるサブドメインに対する名前解決要求がGNSへ送信されるよう、DNSを構成する必要があります。GNSが提供するサブドメインは、クラスタ・メンバー・ノードを表します。

4.9.1 グリッド・ネーミング・サービスで使用するためのサブドメイン名の選択

GNSを実装するには、ネットワーク管理者がDNSを構成してクラスタのドメインを設定し、そのドメイン解決をGNS VIPに委譲する必要があります。別のドメインを使用するか、クラスタに既存のドメインのサブドメインを作成できます。サブドメイン名には、sales-cluster.rac.comなど、サポートされている任意のDNS名を指定できます。

サブドメイン名は企業ドメインとは別のドメインにすることをお薦めします。たとえば、企業ドメインがmycorp.example.comの場合、GNSのサブドメインはrac-gns.mycorp.example.comなどにします。

サブドメインが区別できるものでない場合、それはGNSで専用に使用するものにします。たとえば、サブドメインmydomain.example.comをGNSに委任する場合は、lab1.mydomain.example.comのように、このサブドメインを他のドメインが共有しないようにします。

関連項目:

- GNSの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- ネットワーク識別名の選択の詳細は、第4.5.2項「クラスタ名およびSCANの要件」を参照してください。

4.9.2 クラスタでグリッド・ネーミング・サービスへドメイン委任するためのDNSの構成

委任されたドメインでグリッド・ネーミング・サービス(GNS)を使用する場合は、Oracle Grid Infrastructureのインストール前に、GNSが提供するサブドメイン(クラスタ・メンバー・ノード)に対する名前解決要求がGNSへ送信されるよう、ドメイン・ネーム・サーバー(DNS)を構成します。GNSのドメイン委任は、動的パブリック・ネットワーク(DHCP、自動構成)では必須です。GNSのドメイン委任は、静的パブリック・ネットワーク(静的アドレス、手動構成)では必要ありません。

関連項目:
GNSのオプション、委任およびパブリック・ネットワークの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

次に、ドメインを委任するために実行する必要のある手順の概要を示します。実際の手順はこの例と異なる場合があります。

委任を使用してGNS名前解決要求を送信するようにDNSを構成します。

1. DNSでGNS仮想IPアドレスのエントリを作成します(アドレスの書式は、gns-server.clustername.domainnameです)。たとえば、クラスタ名がmyclusterで、ドメイン名がexample.comで、IPアドレスが192.0.2.1の場合、次のようなエントリを作成します。

mycluster-gns-vip.example.com  A  192.0.2.1

指定したアドレスは、ルーティング可能である必要があります。

2. GNSでGNSサブドメインへのアドレスを解決できるように、GNS仮想IPアドレスへのGNSサブドメインの転送を設定します。これには、委任されたドメインに対して次のようなBIND構成エントリを作成します。cluster01.example.comは、委任するサブドメインです。

cluster01.example.com  NS  mycluster-gns-vip.example.com

3. 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)によってSCANアドレス解決に問題が発生することがあります。nisエントリは、検索リストの最後に配置することをお薦めします。次に例を示します。

/etc/nsswitch.conf
hosts:    files   dns   nis

注意:
ホスト名およびユーザー名の解決が失敗する可能性があるため、NISを使用することがケーブルのプル・テストを実行するときの問題の原因になることがあることに注意してください。

4.10 Oracle Flex Clusterの構成要件

Oracle Flex Clusterを構成する場合は、次の情報を確認します。

- Oracle Flex Cluster構成の一般的な要件

- Oracle Flex ClusterのDHCP割当ての仮想IP (VIP)アドレス

- Oracle Flex Clusterの手動割当てのアドレス

4.10.1 Oracle Flex Cluster構成の一般的な要件

Oracle Flex Cluster構成の次の要件に注意してください。

- Oracle Flex Clusterのデプロイメントではグリッド・ネーミング・サービス(GNS)を使用する必要があります。

- ハブ・ノードの静的IPアドレスとして、GNS VIPを構成する必要があります。

- マルチクラスタ構成では、リーフ・ノードのGNSクライアント・データ・ファイルの場所を指定する必要があります。GNSクライアントのデータ・ファイルは、GNSクライアント・クラスタの構成前にGNSサーバーからコピーされます。

- ハブ・ノードとリーフ・ノードのすべてのパブリック・ネットワーク・アドレスは、割当てが手動か自動かにかかわらず、同じサブネット範囲内にある必要があります。

- Oracle Flex Clusterのすべてのアドレスは静的IPアドレスか、GNSを介してクラスタに登録された、DHCPを介して割り当てられたDHCPアドレス(IPｖ4)、または自動構成サービスを介して割り当てられている自動構成アドレス(IPv6)である必要があります。

4.10.2 Oracle Flex ClusterのDHCP割当ての仮想IP (VIP)アドレス

DHCP割当てのVIPを構成する場合は、インストール時に次のいずれかのオプションを使用して、ハブ・ノードとリーフ・ノードの両方にクラスタ・ノードVIP名を構成する必要があります。

- 手動の名前: DHCPを介してクラスタ・メンバー・ノードに委任され、DNSによって解決されるVIPアドレスに割り当てられる、各クラスタ・メンバー・ノードのノード名およびノードVIP名を入力します(linnode1、linnode1-vip、linnode2、linnode2-vipなど)。手動の名前は、英数字とハイフン("-")は使用できるがアンダースコア("_")は使用できないという、RFC 952標準に準拠している必要があります。

- 自動で割り当てられる名前: 「自動割当て」を選択すると、name#およびname#-vipのパターンを使用するDHCPを介して自動的に生成されるVIPアドレス名がインストーラによって割り当てられます(ここで、nameはクラスタ名で#は自動的に割り当てられた番号です)。アドレスはDHCPから割り当てられGNSによって解決されます。

4.10.3 Oracle Flex Clusterの手動割当てのアドレス

手動割当てのVIPを構成する場合は、インストール時に次のオプションのいずれかを使用して、ハブ・ノードとリーフ・ノードのクラスタ・ノードVIP名を構成する必要があります。

- 手動の名前: 各ノードのホスト名と仮想IP名を手動で入力し、ハブ・ノードかリーフ・ノードかを選択します。入力する名前は、DNSで構成されているアドレスに解決される必要があります。名前は、英数字とハイフン("-")は使用できるがアンダースコア("_")は使用できないという、RFC 952標準に準拠している必要があります。

- 自動割当ての名前: DNSで構成したホスト名に対応する値の文字列変数を入力します。文字列変数を使用すると、インストール時に多数の名前を短時間で割り当てることができます。DNSで次の特性を持つアドレスを構成します。

- ホスト名の接頭辞: クラスタ・メンバー・ノードが使用する、DNSで構成される各アドレスで使用される接頭辞の文字列。たとえば、mycloudです。

- 範囲: クラスタ・メンバー・ノードに割り当てられる番号の範囲で、開始ノード番号と終了ノード番号から構成され、範囲の終わりを指定します(例: 001および999)。

- ノード名の接尾辞: パブリック・ノード名の範囲番号の後ろに追加される接尾辞。たとえば、ndです。

- VIP名の接尾辞: 仮想IPノード名の後ろに追加される接尾辞。たとえば、-vipです。

英数字文字列を使用して手動のアドレスを作成できます。たとえば、mycloud001nd、mycloud046nd、mycloud046-vip、mycloud348nd、mycloud784-vipなどの文字列は、許容される名前の例です。

4.11 グリッド・ネーミング・サービスの標準クラスタの構成例

GNSを使用する場合は、GNSのVIPアドレスに静的IPアドレスを指定し、サブドメインをDNSで構成して、静的なGNSのIPアドレスにそのサブドメインの解決を委任する必要があります。

クラスタにノードが追加されると、組織のDHCPサーバーによって、これらのノードに動的にアドレスが提供されます。これらのアドレスは自動的にGNSに登録され、GNSによってサブドメイン内で、GNSに登録されたクラスタ・ノード・アドレスの解決が行われます。

アドレスの割当てと構成はGNSによって自動的に行われるため、これ以上の構成は必要ありません。Oracle Clusterwareによって、クラスタに対してノードが追加または削除されるときに、動的なネットワーク構成が行われます。参考までに例を示します。

2ノードのクラスタで、GNSのVIPが定義されている場合、インストール後に次のような構成を2ノードのクラスタに対して行いますが、クラスタ名はmycluster、GNSの親ドメインはgns.example.com、サブドメインはcluster01.example.comです(IPアドレスの192.0.2の部分はクラスタのパブリックIPアドレスのサブドメインを表し、192.168はプライベートIPアドレス・サブドメインを表します)。

表4-1 グリッド・ネーミング・サービスのネットワーク例

ID

ホーム・ノード

ホスト・ノード

指定された名前

種類

アドレス

アドレスの割当て元

解決方法

GNS VIP

なし

Oracle Clusterwareにより選択

mycluster-gns-vip.example.com

仮想

192.0.2.1

ネットワーク管理者が固定

DNS

ノード1パブリック

ノード1

node1

node1脚注 1

パブリック

192.0.2.101

固定

GNS

ノード1 VIP

ノード1

Oracle Clusterwareにより選択

node1-vip

仮想

192.0.2.104

DHCP

GNS

ノード1プライベート

ノード1

node1

node1-priv

プライベート

192.168.0.1

固定またはDHCP

GNS

ノード2パブリック

ノード2

node2

node2脚注 1

パブリック

192.0.2.102

固定

GNS

ノード2 VIP

ノード2

Oracle Clusterwareにより選択

node2-vip

仮想

192.0.2.105

DHCP

GNS

ノード2プライベート

ノード2

node2

node2-priv

プライベート

192.168.0.2

固定またはDHCP

GNS

SCAN VIP 1

なし

Oracle Clusterwareにより選択

mycluster-scan.cluster01.example.com

仮想

192.0.2.201

DHCP

GNS

SCAN VIP 2

なし

Oracle Clusterwareにより選択

mycluster-scan.cluster01.example.com

仮想

192.0.2.202

DHCP

GNS

SCAN VIP 3

なし

Oracle Clusterwareにより選択

mycluster-scan.cluster01.example.com

仮想

192.0.2.203

DHCP

GNS

脚注 1 ノードのホスト名が、ホスト上で使用されているVIPアドレスなど、複数のアドレスに解決される場合があります。

4.12 手動によるIPアドレスの構成例

GNSを使用しない場合は、インストールの前に、パブリックIPアドレス、仮想IPアドレスおよびプライベートIPアドレスを構成する必要があります。また、pingコマンドを実行し、デフォルトのゲートウェイにアクセスできることも確認してください。デフォルトのゲートウェイを検出するには、routeコマンドを使用します(オペレーティング・システムのヘルプを参照)。

たとえば、各ノードに1つのパブリック・インタフェースと1つのプライベート・インタフェースがある2ノードのクラスタの場合に、3つのIPアドレスのいずれかに解決されるSCANドメイン・アドレスがDNSに定義してあるとすると、ネットワーク・インタフェースには、次の表に示す構成が考えられます。

表4-2 手動によるネットワークの構成例

ID

ホーム・ノード

ホスト・ノード

指定された名前

種類

アドレス

アドレスの割当て元

解決方法

ノード1パブリック

ノード1

node1

node1脚注 1

パブリック

192.0.2.101

固定

DNS

ノード1 VIP

ノード1

Oracle Clusterwareにより選択

node1-vip

仮想

192.0.2.104

固定

DNSおよびhostsファイル

ノード1プライベート

ノード1

node1

node1-priv

プライベート

192.168.0.1

固定

DNSおよびhostsファイル、またはなし

ノード2パブリック

ノード2

node2

node2脚注 1

パブリック

192.0.2.102

固定

DNS

ノード2 VIP

ノード2

Oracle Clusterwareにより選択

node2-vip

仮想

192.0.2.105

固定

DNSおよびhostsファイル

ノード2プライベート

ノード2

node2

node2-priv

プライベート

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では、インストール中にプライベート・インタフェースとして定義されたインタフェース(eth1など)と、プライベート・サブネットに使用されるサブネットに、インターコネクト・アドレスが割り当てられます。

SCANが解決されるアドレスはOracle Clusterwareによって割り当てられるため、特定のノードには固定されません。VIPのフェイルオーバーが有効になるように、前述の表で示した構成では、SCANアドレスと、両方のノードのパブリック・アドレスおよびVIPアドレスが同一のサブネット(192.0.2)上に定義されています。

注意:
すべてのホスト名はRFC 952標準(英数字を許可)に準拠している必要があります。ホスト名にアンダースコア(_)は使用できません。

4.13 ネットワーク・インタフェース構成のオプション

選択する正確なネットワーク構成は、構成するクラスタのサイズおよび使用方法と、必要な可用性のレベルによって異なります。ネットワーク・インタフェースは1GbE以上である必要があり、推奨は10GbEです。かわりに、インターコネクトにInfiniBandを使用することもできます。

動作保証されているネットワーク接続ストレージ(NAS)をOracle RAC用に使用し、このストレージにイーサネットベースのネットワークを介して接続する場合は、NAS I/O用に3つ目のネットワーク・インタフェースが必要です。この場合、3つの別々のインタフェースを使用しないと、負荷によってパフォーマンスと安定性の問題が発生します。

5 Oracle Grid InfrastructureおよびOracle RACのユーザー、グループおよび環境の構成

この章では、クラスタ用のOracle Grid InfrastructureとOracle Real Application Clustersをインストールする前に完成させるユーザー、グループ・ユーザー環境および管理環境の設定について説明します。

この章の内容は次のとおりです。

- Oracle Grid Infrastructureのグループ、ユーザーおよびパスの作成

- グリッド・インフラストラクチャ・ソフトウェア所有者ユーザー環境の構成

- Intelligent Platform Management Interface(IPMI)の有効化

- rootスクリプトの実行計画の決定

5.1 Oracle Grid Infrastructureのグループ、ユーザーおよびパスの作成

rootとしてログインし、次の手順を実行して、Oracle InventoryグループおよびOracle Grid Infrastructureのソフトウェア所有者を検索または作成します。

- Oracle InventoryおよびOracle Inventoryグループの存在の確認

- Oracle Inventoryが存在しない場合のOracle Inventoryグループの作成

- Oracle Grid Infrastructureユーザーの作成

- Oracleベース・ディレクトリのパスの作成

- 役割区分によるオペレーティング・システム権限グループおよびユーザーについて

- 標準的なグループ、ユーザーおよびパスの作成例

- ロール割当てをしたグループ、ユーザーおよびパスの作成例

- HP-UXの外部ジョブ・ユーザー・アカウントの作成

注意:
Oracle Grid Infrastructureのインストールでは、Oracle Clusterwareおよび Oracle Automatic Storage Managementの両方がインストールされます。Oracle Clusterwareのインストール所有者とOracle Automatic Storage Managementのインストール所有者は、分離することができなくなりました。

5.1.1 Oracle InventoryおよびOracle Inventoryグループの存在の確認

システムに初めて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があるかどうかを確認するには、次のようにします。

1. 次のコマンドを入力します。

# more /var/opt/oracle/oraInst.loc

oraInst.locファイルが存在する場合、このコマンドの出力は次のようになります。

inventory_loc=/u01/app/oracle/oraInventory
inst_group=oinstall

前述の出力例は、次の内容を示します。

- inventory_locグループは、Oracleインベントリの場所を示します。

- inst_groupパラメータは、Oracleインベントリ・グループ名(この例ではoinstall)を示します。

2. Oracle Inventoryグループ・メンバーにHP-UXのRTPRIO、MLOCKおよびRTSCHED権限が付与されていることを確認します。次に例を示します。

# /usr/bin/getprivgrp oinstall
oinstall: RTPRIO MLOCK RTSCHED

グループにこれらの権限が付与されていない場合は、次の項の説明に従って権限を追加します。

5.1.2 Oracle Inventoryが存在しない場合のOracle Inventoryグループの作成

oraInst.locファイルが存在しない場合は、次の手順を実行します。

1. 次のようなコマンドを入力して、Oracle Inventoryグループを作成します。

# /usr/sbin/groupadd -g 54321 oinstall

このコマンドによって、グループID番号が54321のoraInventoryグループoinstallが作成されます。oraInventoryグループのメンバーには、Oracle中央インベントリ(oraInventory)への書込み権限が付与されます。

oraInventoryグループが存在しない場合、デフォルトでは、クラスタ用Oracle Grid Infrastructureソフトウェアのインストール所有者のプライマリ・グループが、oraInventoryグループとして表示されます。使用するOracleソフトウェア・インストール所有者のすべてが、このグループをプライマリ・グループとして利用できることを確認します。

注意:
クラスタ内のすべてのノードで、グループIDおよびユーザーIDが一致している必要があります。使用するグループIDおよびユーザーIDが各クラスタ・メンバー・ノードで使用できることを確認し、クラスタ用Oracle Grid Infrastructureの各インストール所有者のプライマリ・グループが、同じ名前とグループIDであることを確認します。

2. /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

3. 他のすべてのクラスタ・ノードでこの手順を繰り返します。

5.1.3 Oracle Grid Infrastructureユーザーの作成

次の場合は、Oracle Clusterwareのソフトウェア所有者を作成する必要があります。

- Oracleソフトウェア所有者ユーザーが存在しない場合(たとえば、システムへOracleソフトウェアを初めてインストールする場合)。

- Oracleソフトウェア所有者ユーザーは存在するが、他のグループに所属する別のオペレーティング・システム・ユーザーを使用して、Oracle Grid InfrastructureとOracle Databaseの管理権限を分離する場合。
Oracleドキュメントでは、Oracle Grid Infrastructureソフトウェア・インストールのみを所有するために作成されたユーザーはgridユーザーと呼ばれます。すべてのOracleインストール、またはOracle Databaseインストールのみのいずれかを所有するために作成されたユーザーはoracleユーザーと呼ばれます。

5.1.3.1 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ソフトウェア所有者が別の中央インベントリ・グループを持っている場合、その中央インベントリは破損することがあります。

5.1.3.2 Oracleソフトウェア所有者ユーザーの存在の確認

oracleやgridというOracleソフトウェア所有者ユーザーが存在するかどうかを確認するには、次のようなコマンドを入力します(この場合、oracleの存在を確認します)。

# id oracle

ユーザーが存在する場合、このコマンドの出力結果は、次のようになります。

uid=54421(oracle) gid=54321(oinstall) groups=54322(dba),54323(oper)

既存ユーザーを使用するか、別のユーザーを作成するかを決定します。ユーザーIDおよびグループIDの番号は、クラスタ・メンバー・ノードにする各ノード上で同一である必要があります。

既存ユーザーを使用する場合は、ユーザーのプライマリ・グループがOracle Inventoryグループ(oinstall)であることを確認します。

5.1.3.3 Oracle Grid InfrastructureのOracleソフトウェア所有者ユーザーの作成または変更

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項「役割区分によるオペレーティング・システム権限グループおよびユーザーについて」を参照)。

1. 既存のシステム権限グループ(この例では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)

2. Oracle Grid Infrastructureを所有するユーザーのパスワードを設定します。次に例を示します。

# passwd grid

3. 他のすべてのクラスタ・ノードでこの手順を繰り返します。

注意:
既存ユーザーを使用または変更する前に、必要に応じて、システム管理者に連絡してください。

5.1.4 GridユーザーのOracleベース・ディレクトリについて

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

5.1.5 Oracle Grid InfrastructureソフトウェアのOracleホーム・ディレクトリについて

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

注意:
クラスタ・インストールのOracle Grid Infrastructureの場合は、Oracle Grid Infrastructureバイナリ・ホーム(Oracle Grid InfrastructureのGridホーム・ディレクトリ)の次の制限事項に注意してください。

- Oracle Grid Infrastructureインストール所有者のOracleベース・ディレクトリを含む、どのOracleベース・ディレクトリの下にも配置できません。

- インストール所有者のホーム・ディレクトリには配置できません。

これらの要件は、クラスタ・インストールのOracle Grid Infrastructureに固有です。スタンドアロン・サーバー(Oracle Restart)のOracle Grid Infrastructureは、Oracle DatabaseインストールのOracleベースにインストールできます。

関連項目:
Optimal Flexible Architecture (OFA)のガイドラインの詳細については、『Oracle Databaseインストレーション・ガイド』を参照してください。

5.1.6 OracleホームおよびOracleベース・ディレクトリの作成

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ベースおよびOracleホーム・ディレクトリの詳細は、付録D「クラスタ用Oracle Grid Infrastructureのインストールの概要」を参照してください。

5.1.7 役割区分によるオペレーティング・システム権限グループおよびユーザーについて

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にする必要があります。

注意:
ネットワーク情報サービス(NIS)などのネットワーク・ディレクトリ・サービス上のインストールに対してユーザーを構成するには、そのディレクトリ・サービスのドキュメントを参照してください。

関連項目:

- システム権限の認証計画の詳細は、『Oracle Database管理者ガイド』を参照してください。

- Oracle ASMオペレーティング・システム認証の詳細は、『Oracle Database Storage管理者ガイド』を参照してください。

5.1.7.1 役割区分によるグループおよびユーザーの作成の概要

この項では、ユーザーおよびグループを作成し、役割区分を使用する方法の概要を説明します。これらのグループおよびユーザーを作成するには、rootでログインします。

- 役割区分を使用したOracleインストールのためのユーザー

- 役割区分によるインストールのためのデータベース・グループ

- 役割区分によるインストールのためのOracle ASMグループ

5.1.7.1.1 役割区分を使用したOracleインストールのためのユーザー

個別のソフトウェア・インストール所有者を作成するすべてのインストールで、次のオペレーティング・システム・グループとユーザーを作成することをお薦めします。

各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管理者ガイド』を参照してください。

5.1.7.1.2 役割区分によるインストールのためのデータベース・グループ

Oracle Databaseをインストールするには、次のオペレーティング・システム・グループおよびユーザーが必要です。

- OSDBAグループ(通常、dba)
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です。

5.1.7.1.3 役割区分によるインストールのためのOracle ASMグループ

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です。

5.1.8 役割区分によるグループおよびユーザーの説明

この項の内容は次のとおりです。

- Oracleソフトウェア製品ごとのOracleソフトウェア所有者

- 役割区分用の標準Oracle Databaseグループ

- 役割区分用の拡張Oracle Databaseグループ

- 役割区分用のOracle ASMグループ

5.1.8.1 Oracleソフトウェア製品ごとのOracleソフトウェア所有者

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管理者ガイド』を参照してください。

5.1.8.2 役割区分用の標準Oracle Databaseグループ

標準Oracle Databaseグループのリストを次に示します。これらのグループは、データベース管理システム権限のオペレーティング・システム認証を提供します。

- OSDBAグループ(通常、dba)
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権限)を持つ別個のオペレーティング・システム・ユーザー・グループが必要な場合は、このグループの作成を選択できます。

5.1.8.3 役割区分用の拡張Oracle Databaseグループ

Oracle Database 12cリリース1 (12.1)からは、データベースを起動および停止するためのOSOPER権限に加えて、日常のデータベース操作に必要な特定の管理権限タスクをサポートする、よりタスク固有で、OSDBA/SYSDBAシステム権限より権限の少ない新しい管理権限を作成できます。ユーザーが付与したこれらのシステム権限は、オペレーティング・システム・グループ・メンバーシップを通じても認証されます。

これらの特定のグループ名を作成する必要はありませんが、インストール中にオペレーティング・システム・グループを指定するように求められます(そのメンバーに、これらのシステム権限へのアクセス権が付与されます)。同じグループを、これらの権限の認証を提供するために割り当てることができますが、各権限の指定には固有のグループを提供することをお薦めします。

OSDBAサブセット役割区分の権限およびグループは、次のもので構成されます。

- Oracle Database用のOSBACKUPDBAグループ(通常、backupdba)
このグループは、オペレーティング・システム・ユーザーの別のグループにバックアップおよびリカバリ関連権限の一部(SYSBACKUP権限)を付与する場合に作成します。

- Oracle Data Guard用のOSDGDBAグループ(通常、dgdba)
このグループは、オペレーティング・システム・ユーザーの別のグループにOracle Data Guardを管理および監視する権限の一部(SYSDG権限)を付与する場合に作成します。

- 暗号化鍵管理用のOSKMDBAグループ(通常、kmdba)
このグループは、オペレーティング・システム・ユーザーの別のグループに、Oracle Wallet Managerの管理など暗号化鍵を管理権限の一部(SYSKM権限)を付与する場合に作成します。

5.1.8.4役割区分用のOracle ASMグループ

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です。

5.1.9 役割区分によるオペレーティング・システム権限グループおよびユーザーの作成

次の項では、Oracle Grid InfrastructureおよびOracle Databaseに必要なオペレーティング・システム・ユーザーおよびグループを作成する方法を説明します。

- データベース・インストールの準備のためのOSDBAグループの作成

- データベース・インストールのためのOSOPERグループの作成

- OSASMグループの作成

- ASMのためのOSOPERグループの作成

- Oracle ASMへのデータベース・アクセスのためのASM用のOSDBAグループの作成

- Oracleソフトウェア所有者ユーザーのインストール作業

- 他のクラスタ・ノードでの同一データベース・ユーザーおよびグループの作成

5.1.9.1 データベース・インストールの準備のためのOSDBAグループの作成

Oracle DatabaseをインストールしてOracle Grid Infrastructure環境で使用するときに、次のような場合はOSDBAグループを作成する必要があります。

- OSDBAグループが存在しない場合(たとえば、システムへOracle Databaseソフトウェアを初めてインストールする場合)。

- OSDBAグループは存在するが、新規のOracle Databaseインストールでは、異なるオペレーティング・システム・ユーザー・グループにデータベース管理権限を付与する場合。

OSDBAグループが存在しない場合または新しいOSDBAグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはdbaを使用します。

# /usr/sbin/groupadd -g 54323 dba

5.1.9.2 データベース・インストールのためのOSOPERグループの作成

OSOPERグループを作成する必要があるのは、制限付きのデータベース管理権限(SYSOPERオペレータ権限)を持つオペレーティング・システム・ユーザーのグループを指定する場合のみです。ほとんどのインストールの場合、OSDBAグループを作成するのみで十分です。次の場合にOSOPERグループを使用するには、このグループを作成する必要があります。

- OSOPERグループが存在しない場合。たとえば、これがシステムに対するOracle Databaseソフトウェアの初回インストールの場合。

- OSOPERグループは存在するが、新規のOracleインストールでは、異なるオペレーティング・システム・ユーザー・グループにデータベース・オペレータ権限を付与する場合。

新しいOSOPERグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはoperを使用します。

# /usr/sbin/groupadd -g 54324 oper1

5.1.9.3 OSASMグループの作成

OSASMグループが存在しない場合、または新規のOSASMグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmadminを使用します。

# /usr/sbin/groupadd -g 54325 asmadmin

5.1.9.4 ASMのためのOSOPERグループの作成

データベース管理者などのオペレーティング・システム・ユーザーのグループを指定し、Oracle ASM記憶域の起動と停止を含む、Oracle ASM記憶域層に対する制限付きの管理権限を付与する場合には、ASM用のOSOPERグループを作成します。ほとんどの環境では、OSASMグループを作成するのみで十分です。インストールのインタビュー時に、そのグループをASM用のOSOPERグループとして指定します。

新しいASM用のOSOPERグループが必要な場合は、次の手順で作成します。次の手順では、既存のグループですでに使用されていないかぎり、グループ名にはasmoperを使用します。

# /usr/sbin/groupadd -g 54326 asmoper

5.1.9.5 Oracle ASMへのデータベース・アクセスのためのASM用のOSDBAグループの作成

Oracle ASMインスタンスへのアクセスを可能にするには、ASM用のOSDBAグループを作成する必要があります。これは、OSASMとOSDBAが異なるグループである場合に必要です。

ASM用のOSDBAグループが存在しない場合、または新しいASM用のOSDBAグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmdbaを使用します。

# /usr/sbin/groupadd -g 54327 asmdba

5.1.9.6 Oracleソフトウェア所有者ユーザーのインストール作業

この項では、通常Oracle Databaseまたはその他のOracleアプリケーション・ソフトウェアを所有するユーザーである、Oracleソフトウェア所有者ユーザーに関する情報を説明します。この項の内容は次のとおりです。

5.1.9.6.1 Oracleソフトウェア所有者ユーザーの作成について

次の場合、Oracleソフトウェア所有者ユーザーを作成する必要があります。

- Oracleソフトウェア所有者ユーザーは存在するが、異なるグループ・メンバーシップを持つ異なるオペレーティング・システム・ユーザーを使用するために、新しいOracle Databaseインストール環境でそれらのグループにデータベース管理権限を付与する場合

- Oracle Grid InfrastructureのOracleソフトウェア所有者(gridなど)を作成し、Oracle Databaseソフトウェア用に別のOracleソフトウェア所有者(oracleなど)を作成する場合。

5.1.9.6.2 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ソフトウェア所有者ユーザーの変更」を参照してください。

- ユーザーを作成する場合は、次の項を参照してください。

注意:
既存ユーザーを使用または変更する前に、必要に応じて、システム管理者に連絡してください。
各ノードのUIDおよびGIDのデフォルトを使用しないことをお薦めします。グループIDやユーザーIDが、ノードによって一致しなくなることがあるためです。かわりに、一般的に割り当てられるグループおよびユーザーIDを指定し、グループおよびユーザーを作成または変更する前にどのノードでも使用されていないことを確認してください。

5.1.9.6.3 Oracleソフトウェア所有者ユーザーの作成

Oracleソフトウェア所有者ユーザーが存在しない、または新しいOracleソフトウェア所有者ユーザーが必要な場合は、次の手順で作成します。既存のユーザーですでに使用されていないかぎり、ユーザー名にはoracleを使用します。

1. 次のコマンドを入力して、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などです。

2. oracleユーザーのパスワードを設定します。

# passwd oracle

5.1.9.6.4 既存のOracleソフトウェア所有者ユーザーの変更

oracleユーザーは存在するが、プライマリ・グループがoinstallではない場合、またはユーザーが適切なOSDBAまたはASM用OSDBAグループのメンバーではない場合は、次のコマンドで変更します。-gオプションでプライマリ・グループを指定し、-Gオプションで必要なセカンダリ・グループを指定します。

# /usr/sbin/usermod -g oinstall -G dba,asmdba oracle

他のすべてのクラスタ・ノードでこの手順を繰り返します。

5.1.9.7 他のクラスタ・ノードでの同一データベース・ユーザーおよびグループの作成

Oracleソフトウェア所有者ユーザー、Oracle Inventory、OSDBAグループおよびOSOPERグループは、すべてのクラスタ・ノードに存在し、また同一である必要があります。同一のユーザーおよびグループを作成するには、ユーザーおよびグループを作成したノードで割り当てられたユーザーIDおよびグループIDを確認してから、他のクラスタ・ノードで同じ名前とIDを持つユーザーおよびグループを作成する必要があります。

注意:
次の手順は、ローカル・ユーザーおよびグループを使用している場合にのみ実行する必要があります。NISなどのディレクトリ・サービスで定義されたユーザーおよびグループを使用している場合、各クラスタ・ノードのユーザーおよびグループはすでに同一です。

既存のユーザーIDおよびグループIDの確認

gridまたはoracleユーザーのユーザーID(uid)と、既存のOracleグループのグループID(gid)を確認するには、次の手順を実行します。

1. 次のコマンドを入力します(ここでは、oracleユーザーのユーザーIDを確認します)。

# id oracle

このコマンドの出力結果は、次のようになります。

uid=54321(oracle) gid=54421(oinstall) groups=54322(dba),54323(oper),54327(asmdba)

2. 表示された情報から、ユーザーのユーザーID(uid)および所属するグループのグループID(gid)を特定します。これらのID番号がクラスタの各ノードで同じであることを確認します。ユーザーのプライマリ・グループはgidの後に表示されます。セカンダリ・グループはgroupsの後に表示されます。

他のクラスタ・ノードでのユーザーおよびグループの作成

他のクラスタ・ノードでユーザーおよびグループを作成するには、各ノードで次の手順を繰り返します。

1. 次のクラスタ・ノードへrootでログインします。

2. 次のコマンドを入力して、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を変更する必要があります。

3. 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を指定する必要があります。

4. ユーザーのパスワードを設定します。次に例を示します。

# passwd oracle

5. 「グリッド・インフラストラクチャ・ソフトウェア所有者ユーザー環境の構成」で説明するとおり、各ユーザーに対してユーザー環境の構成を行います。

5.1.10 標準的なグループ、ユーザーおよびパスの作成例

この構成例では、次を示します。

- 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ソフトウェア・インストールごとに別のインストール所有者アカウントを使用することをお薦めします。

5.1.11 ロール割当てをしたグループ、ユーザーおよびパスの作成例

この項では、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 Grid Infrastructureのグループおよびユーザーの例

- Oracle Database DB1のグループおよびユーザーの例

- Oracle Database DB2のグループおよびユーザーの例

5.1.11.1 Oracle Grid Infrastructureのグループおよびユーザーの例

- 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)に変更されます。

5.1.11.2 Oracle Database DB1のグループおよびユーザーの例

- 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パスのその他のディレクトリは対象外です)。

5.1.11.3 Oracle Database DB2のグループおよびユーザーの例

- 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パスのその他のディレクトリは対象外です)。

5.1.12 HP-UXの外部ジョブ・ユーザー・アカウントの作成

HP-UXプラットフォームで、Oracle Grid Infrastructure上にOracle DatabaseまたはOracle Real Application Clustersをインストールする場合は、次の手順を実行して外部ジョブ・ユーザー・アカウントを作成して、外部ジョブを実行可能な権限の低いユーザーを用意します。

1. rootユーザーでログインします。

2. 権限を付与されていないユーザーextjobを作成します。次に例を示します。

# useradd extjob

5.2 グリッド・インフラストラクチャ・ソフトウェア所有者ユーザー環境の構成

インストーラ・ソフトウェアは、Oracle Grid Infrastructureインストール所有者ユーザー・アカウント(oracleまたはgrid)で実行します。ただし、インストーラを起動する前に、インストール所有者ユーザー・アカウントの環境を構成する必要があります。また、必要に応じて、他の必要なOracleソフトウェア所有者を作成します。

この項の内容は次のとおりです。

- Oracleソフトウェア所有者の環境要件

- Oracleソフトウェア所有者の環境の構成手順

- リモート表示およびX11転送の構成の設定

- 端末出力コマンドが原因のインストール・エラーの回避

5.2.1 Oracleソフトウェア所有者の環境要件

Oracle Grid Infrastructureソフトウェア所有者の環境を構成するには、次の変更を行う必要があります。

- シェル起動ファイルで、インストール・ソフトウェア所有者ユーザー(grid、oracle)のデフォルトのファイル・モード作成マスク(umask)を022に設定します。マスクを022に設定すると、ソフトウェア・インストールを実行するユーザーは644の権限を持つファイルを作成できます。

- インストール・ソフトウェア所有者(grid、oracle)のファイル記述子およびプロセスに対して、ulimitを設定します。

- Oracle Grid Infrastructureをインストールする準備として、ソフトウェア所有者のDISPLAY環境変数を設定します。

注意:
オペレーティング・システムのベンダーでサポートされるシェル・プログラムを使用してください。オペレーティング・システムでサポートされないシェル・プログラムを使用した場合、インストールの際にエラーが発生する可能性があります。

5.2.2 Oracleソフトウェア所有者の環境の構成手順

Oracleソフトウェア所有者の環境を設定するには、ソフトウェア所有者(grid、oracle)ごとに次の手順を実行します。

1. X端末(xterm)などの端末セッションを新規に開始します。

2. 次のコマンドを入力し、Xウィンドウ・アプリケーションがこのシステム上に表示されることを確認します。

$ xhost + hostname

hostnameは、ローカル・ホストの名前です。

3. ソフトウェアをインストールするシステムにまだログインしていない場合は、ソフトウェア所有者ユーザーとしてそのシステムにログインします。

4. そのユーザーでログインしていない場合は、構成するソフトウェア所有者に切り替えます。たとえば、gridユーザーの場合は次のようになります。

$ su - grid

5. 次のコマンドを入力して、ユーザーのデフォルトのシェルを確認します。

$ echo $SHELL

6. テキスト・エディタでユーザーのシェル起動ファイルを開きます。

- Bourneシェル(sh)またはKornシェル(ksh):

$ vi .profile

- Cシェル(cshまたはtcsh):

% vi .login

7. 次のように行を入力または編集して、デフォルトのファイル・モード作成マスクの値に022を指定します。

umask 022

8. 環境変数ORACLE_SID、ORACLE_HOMEまたはORACLE_BASEがファイルに設定されている場合は、そのファイルから適切な行を削除します。

9. ファイルを保存して、テキスト・エディタを終了します。

10. シェル起動スクリプトを実行するには、次のいずれかのコマンドを入力します。

- BourneまたはKornシェルの場合:

$ . ./.profile

- Cシェル:

% source ./.login

11. 次のコマンドを使用してPATH環境変数をチェックします。

$ echo $PATH

すべてのOracle環境変数を削除します。

12. ローカル・システムにソフトウェアをインストールしていない場合は、次のコマンドを入力してXアプリケーションをローカル・システムに表示します。

- BourneまたはKornシェルの場合:

$ DISPLAY=local_host:0.0 ; export DISPLAY

- Cシェル:

% setenv DISPLAY local_host:0.0

この例で、local_hostは、OUIを表示するために使用するシステム(ご使用のワークステーションまたはPC)のホスト名またはIPアドレスです。

13. /tmpディレクトリの空きディスク領域が7GB未満である場合は、7GB以上の空き領域があるファイル・システムを特定し、そのファイル・システムの一時ディレクトリを指定するようにTEMPおよびTMPDIR環境変数を設定します。

注意:
Oracle RACのインストール用の一時ファイル・ディレクトリ(通常、/tmp)の場所として、共有ファイル・システムは使用できません。共有ファイル・システムに/tmpを配置すると、インストールは失敗します。

1. bdfコマンドを使用して、十分な空き領域を持つ適切なファイル・システムを選択します。

2. 必要に応じて、次のようなコマンドを入力し、識別したファイル・システム上に一時ディレクトリを作成し、そのディレクトリに適切な権限を設定します。

$ su - root
# mkdir /mount_point/tmp
# chmod a+wr /mount_point/tmp
# exit

3. 次のコマンドを入力して、環境変数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

14. 次のコマンドを入力して、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環境変数の設定を削除し、インストーラによって示されるデフォルトのパスを選択することをお薦めします。

5.2.3 リモート表示およびX11転送の構成の設定

リモート端末で作業を行っていて、そのローカル・ノードのみが表示されている場合(通常は、この状態になります)、次の構文を使用して、環境変数DISPLAYを設定します。

Bourne、KornおよびBashシェル:

$ export DISPLAY=hostname:0

Cシェル:

$ setenv DISPLAY hostname:0

たとえば、Bashシェルを使用していて、ホスト名がnode1の場合は、次のコマンドを入力します。

$ export DISPLAY=node1:0

X11転送が原因でインストールが失敗しないようにするには、次のように、Oracleソフトウェア所有者ユーザーに対してユーザーレベルのSSHクライアント構成ファイルを作成します。

1. テキスト・エディタを使用して、ソフトウェア・インストール所有者の~/.ssh/configファイルを編集または作成します。

2. ~/.ssh/configファイルでForwardX11属性がnoに設定されていることを確認します。次に例を示します。

Host *
ForwardX11 no

3. ~/.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

5.2.4 端末出力コマンドが原因のインストール・エラーの回避

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コマンドを使用します。
リモート・シェルによってロードされる隠しファイルにsttyコマンドが含まれている場合も、OUIによりエラーが発生し、インストールが停止されます。

5.3 Intelligent Platform Management Interface(IPMI)の有効化

Intelligent Platform Management Interface(IPMI)は、コンピュータのハードウェアおよびファームウェアへの共通インタフェースを提供し、システム管理者はそのインタフェースを使用して、システム状態の監視およびシステムの管理を実行できます。Oracle ClusterwareにIPMIを統合して、障害分離をサポートしたりクラスタの整合性を確保することができます。

現在、Oracle ClusterwareではHP-UXでネイティブIPMIドライバをサポートしていないため、OUIでは管理者資格証明が収集されません。また、CSSではIPアドレスを取得できません。インストール前に静的IPアドレスを使用してBMCを構成し、インストール後にcrsctlを使用してIPアドレスおよびIPMI資格証明を格納することによって、障害分離を手動で構成する必要があります。

この項の内容は次のとおりです。

- IPMIを有効化するための要件

- IPMI管理ネットワークの構成

- BMCの構成

関連項目:
インストール後にIPMIの構成を行う方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

5.3.1 IPMIを有効化するための要件

クラスタ・ノードを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のベンダーに問い合せてください。

5.3.2 IPMI管理ネットワークの構成

HP-UXプラットフォームでは、BMCは構成情報を管理プロセッサ(iLO)と共有します。Oracle Clusterwareの場合は、ilO/BMCを静的IPアドレス用に構成する必要があります。HP-UXでは、BMCを動的アドレス(DHCP)を使用して構成することはサポートされていません。

注意:
IPMIを構成し、グリッド・ネーミング・サービス(GNS)を使用する場合でも、IPMIインタフェースには別のアドレスを構成する必要があります。IPMIアダプタはホストから直接には認識できないため、GNSはホスト上のアドレスとしてIPMIアダプタを認識できません。

5.3.3 BMCの構成

各ノードで、次の手順を実行して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が各クラスタ・メンバー・ノードに構成されていることを確認してください。

5.3.3.1 HP-UXでのiLOプロセッサの構成

HPプラットフォームのiLOプロセッサでIPMIを構成し、null(nonameユーザー)のパスワードを設定するには、次の手順を実行します。

1. iLO Webインタフェースにログインし、「Administration」→「Network Settings」でiLOおよびBMCに必要なネットワーク設定を構成し、IPアドレスを取得して、ネットマスクおよびデフォルトのゲートウェイを確認します。

2. 構成するノードのBMCにネットワーク接続されたデバイスから端末セッションを起動します。

3. 端末セッションで、ユーザー・パスワードを変更するノードに接続されているクライアントまたはサーバーから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管理者アカウントのパスワードを設定することはできません。

4. 各クラスタ・メンバー・ノードでBMCを構成し、Oracle Grid Infrastructureのインストールを完了した後、IPMI管理者資格証明およびBMC静的IPアドレスを各クラスタ・メンバー・ノードのOracle Local Registry(OLR)に格納する必要があります。これを行うには、第8.2.1項「crsctlを使用したIPMIベース障害分離の構成」で説明されているとおり、crsctlを使用します。ただし、IPMI資格証明をOLRに格納する場合は、明示的に指定した匿名ユーザーが必要です。ない場合は、解析エラーがレポートされます。

% crsctl set css ipmiadmin ""

プロンプトに対し、IPMI管理者ツールで設定したパスワードを指定します。

5.4 rootスクリプトの実行計画の決定

Oracle Grid Infrastructureのインストール中に、多数のシステム構成タスクを完了するために、スーパーユーザー(root)権限でスクリプトを実行するようにインストーラから求められます。

次のオプションのいずれかを使用して、rootとして手動でスクリプトを実行するか、rootとして構成手順を実行する権限をインストーラに委任することができます。

- rootパスワードを使用: その他の構成情報を入力する際に、インストーラにパスワードを提供します。パスワードはインストール中に使用され、格納されません。rootユーザー・パスワードは、各クラスタ・メンバー・ノードで同一である必要があります。
rootコマンドの委任を有効にするには、要求された際に、インストーラにrootパスワードを提供します。

- sudoを使用: sudoはUNIXおよびLinuxのユーティリティで、sudoersリスト権限のメンバーは、個々のコマンドをrootとして実行できます。
Sudoを有効にするには、適切な権限を持つシステム管理者がsudoersリストのメンバーであるユーザーを構成し、インストール時の求めに応じてユーザー名とパスワードを指定します。

5.5 Oracleベース・ディレクトリのパスの作成

グリッド・インストール所有者の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バイナリをクラスタ・ファイル・システムに配置することはサポートされていません。

6 Oracle Grid InfrastructureおよびOracle RACの記憶域の構成

この章では、インストーラを起動してOracle ClusterwareとOracle Automatic Storage Management(Oracle ASM)をインストールする前、およびOracle Real Application Clusters(Oracle RAC)のインストールをクラスタへ追加する前に完了しておく必要がある、記憶域の構成作業について説明します。

この章の内容は次のとおりです。

- Oracle Grid Infrastructureの記憶域オプションの確認

- 共有ファイル・システムの記憶域の構成について

- オペレーティング・システムおよびDirect NFSクライアントの構成

- Oracle Automatic Storage Managementの記憶域の構成

6.1 Oracle Grid Infrastructureの記憶域オプションの確認

この項では、クラスタ用Oracle Grid Infrastructureの格納用にサポートされている記憶域オプションについて説明します。内容は次のとおりです。

- サポートされている記憶域オプション

- Oracle Grid InfrastructureおよびOracle RACの記憶域についての一般的な考慮事項

- 記憶域にOracle ASMディスク・グループを使用するためのガイドライン

- Oracle Grid InfrastructureおよびOracle RACでの論理ボリューム・マネージャの使用

- ディスクの記憶域オプションを選択した後の作業

関連項目:
動作保証されている記憶域オプションの最新情報については、My Oracle Supportの動作保証についてのサイトを参照してください。

https://support.oracle.com

6.1.1 サポートされている記憶域オプション

次の表に、Oracle ClusterwareおよびOracle RACファイルを格納するために使用できる記憶域オプションを示します。

表6-1 Oracle ClusterwareおよびOracle RACでサポートされている記憶域オプション

記憶域オプション

OCRおよび投票ディスク

Oracle Clusterwareバイナリ

Oracle RACバイナリ

Oracle Databaseファイル

Oracleリカバリ・ファイル

Oracle Automatic Storage Management

注意: ループバック・デバイスは、Oracle ASMでは使用できません。

可

不可

不可

可

可

ローカル・ファイル・システム

不可

可

可

不可

不可

動作保証されているNASファイラ上のNFSファイル・システム

注意: Direct NFSクライアントはOracle Clusterwareファイルをサポートしていません。

可

可

可

可

可

共有ディスク・パーティション(ブロック・デバイスまたはRAWデバイス)

不可

不可

不可

不可

不可

共有論理ボリューム・マネージャ

非推奨。これは、Oracle Grid Infrastructure 12c以降、Oracle ClusterwareファイルのRAWデバイスおよびブロック・デバイスがサポートされていないためです。

不可

不可

非推奨。これは、Oracle Grid Infrastructure 12c以降、Oracle DatabaseファイルのRAWデバイスおよびブロック・デバイスがサポートされていないためです。

不可

クラスタ・ファイル・システム脚注 2

可

可

可

可

可

脚注 1 リストされているオプションは、Oracle ASMには適用されません。Oracle ASMでサポートされている記憶域オプションについては、この表のOracle ASMエントリを参照してください。

脚注 2 共有論理ボリューム・マネージャはクラスタ・ファイル・システムとともに使用できます。

次のガイドラインに従って、記憶域オプションを選択します。

- 選択した記憶域オプションの要件がすべて満たされている場合、各ファイル・タイプでサポートされている記憶域オプションのいずれの組合せでも使用できます。

- Oracle Clusterwareファイルの格納には、Oracle ASMを使用できません。

- RAWデバイスまたはブロック・デバイスの直接の使用はサポートされていません。

関連項目:
既存のデータベースをアップグレードするための準備方法については、『Oracle Databaseアップグレード・ガイド』を参照してください。

- 外部ファイルを冗長化できる記憶域オプションを選択できない場合は、冗長性を確保するために3つ以上の投票ディスクの場所および2つ以上のOracle Cluster Registryの場所を構成する必要があります。

6.1.2 Oracle Grid InfrastructureおよびOracle RACの記憶域についての一般的な考慮事項

すべてのインストールに対して、Oracle Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)およびOracle Real Application Clusters(Oracle RAC)データベースに使用する記憶域オプションを選択する必要があります。

6.1.2.1 Oracle Clusterwareの記憶域についての一般的な考慮事項

Oracle Clusterware投票ディスクは、クラスタ・ノードのステータスの監視に使用されます。Oracle Cluster Registry(OCR)ファイルには、クラスタに関する構成情報が格納されます。投票ディスクとOCRファイルは、Oracle ASMディスク・グループ、クラスタ・ファイル・システム、共有ネットワーク・ファイル・システムのいずれかに配置できます。記憶域は共有される必要があります。構成されている投票ディスクの大半(過半数)が利用できないノードは再起動されます。

6.1.2.2 Oracle RACの記憶域についての一般的な考慮事項

Standard EditionおよびStandard Edition 2 (SE2)のOracle RACインストールでは、データベース・ファイルおよびリカバリ・ファイルの記憶域オプションとして、Oracle ASMのみがサポートされています。すべてのインストールについて、2つの以上のOracle ASMディスク・グループを作成することをお薦めします(Oracle Databaseデータ・ファイルおよびリカバリ・ファイル用にそれぞれ1つずつ)。Oracle Databaseディスク・グループおよびリカバリ・ファイル・ディスク・グループは別の障害グループに配置することをお薦めします。

Oracle ASMを使用しない場合は、データ・ファイルと高速リカバリ領域を、異なる場所にあるOracleホーム以外の共有記憶域に配置し、ハードウェアの障害による可用性の低下を防ぐことをお薦めします。

関連項目:

- 高速リカバリ領域の使用の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- 障害グループ、および高可用性とリカバリのベスト・プラクティスの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

サポートされている記憶域のオプションには、次の追加のガイドラインを考慮してください。

- 選択した記憶域オプションの要件がすべて満たされている場合、各ファイル・タイプでサポートされている記憶域オプションのいずれの組合せでも使用できます。

- Oracle RACでOracle ASMを使用するために新しいOracle ASMインスタンスを構成する場合は、システムが次の条件を満たしている必要があります。

- クラスタ用Oracle Grid Infrastructureのインストールの一部として、クラスタ内のすべてのノードにOracle ClusterwareおよびOracle ASM 12cリリース1(12.1)がインストールされている。

- クラスタ内のすべてのノードで既存のすべてのOracle ASMインスタンスが停止されている。

- 外部ファイルの冗長性が適用される記憶域オプションがない場合は、3つ以上の投票ディスク領域を構成して、投票ディスクの冗長性を確保する必要があります。

6.1.3 記憶域にOracle ASMディスク・グループを使用するためのガイドライン

Oracle Grid Infrastructureのインストール中、1つのディスク・グループを作成できます。Oracle Grid Infrastructureをインストール後、Oracle Automatic Storage Management Configuration Assistant (ASMCA)、SQL*Plus、または自動ストレージ管理コマンドライン・ユーティリティ(ASMCMD)を使用してディスク・グループを追加作成できます。Oracle Database 11gリリース2 (11.2)以上のリリースでは、Oracle Database Configuration Assistant (DBCA)にOracle ASM用のディスク・グループを作成する機能がないことに注意してください。

Oracle Grid Infrastructureをインストールした後にOracle DatabaseまたはOracle RACをインストールする場合は、データベース・ファイル、OCRおよび投票ディスク・ファイル用に同じディスク・グループを使用するか、または異なるディスク・グループを使用できます。Oracle RACのインストール前またはデータベースの作成前に、複数のディスク・グループを作成する場合は、次のいずれかを実行できます。

- Oracle Clusterwareファイルとしてデータ・ファイルを同じディスク・グループに配置する。

- データ・ファイルおよびリカバリ・ファイル用に同じOracle ASMディスク・グループを使用する。

- ファイル・タイプごとに異なるディスク・グループを使用する。

記憶域用に1つのディスク・グループのみを作成した場合、OCRと投票ディスク・ファイル、データベース・ファイルおよびリカバリ・ファイルは、1つのディスク・グループに配置されます。記憶域用に複数のディスク・グループを作成した場合は、ファイルは異なるディスク・グループに配置できます。

注意:
既存のディスク・グループを管理するOracle ASMインスタンスは、Gridホームで実行されている必要があります。

関連項目:
ディスク・グループの作成の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

6.1.4 Oracle Grid InfrastructureおよびOracle RACでの論理ボリューム・マネージャの使用

Oracle Grid InfrastructureおよびOracle RACは、クラスタ対応のボリューム・マネージャのみをサポートします。いくつかのサード・パーティのボリューム・マネージャはクラスタ対応ではないため、サポートされていません。使用するボリューム・マネージャがサポートされているかどうかを確認するには、My Oracle Supportの「動作保証」をクリックし、そのボリューム・マネージャがOracle RACで動作保証されているかどうかを確認します。My Oracle Supportは、次のURLで使用可能です。

https://support.oracle.com

6.1.5 ディスクの記憶域オプションを選択した後の作業

ディスクの記憶域オプションを決定したら、共有記憶域の構成を行います。

- ファイル・システムを使用する場合は、第6.2項「共有ファイル・システムの記憶域の構成」を参照してください。

- Oracle ASMを使用する場合は、第6.4項「Oracle Automatic Storage Managementの記憶域の構成」を参照してください。

6.2 共有ファイル・システムの記憶域の構成について

インストーラでは、Oracle Cluster Registry(OCR)またはOracle Clusterware投票ディスク用のデフォルトの格納先は提供されません。ファイル・システムにこれらのファイルを作成する場合は、次の項を確認して、Oracle Clusterwareファイル用の記憶域要件を満たしておきます。

- 共有ファイル・システムを使用するための要件

- Oracle Clusterwareファイル用のクラスタ・ファイル・システムの使用の確認

- データ・ファイル用のDirect NFSクライアントの使用の確認

- データ・ファイル用のNFSの使用の確認

- 記憶域のNFSマウントおよびバッファ・サイズ・パラメータの構成

- Oracle Clusterware用のNFSマウントおよびバッファ・サイズ・パラメータの確認

- Oracle RAC用のNFSマウントおよびバッファ・サイズ・パラメータの確認

- NFSのDirect NFSクライアントのOracle Disk Manager制御の有効化

- 共有ファイル・システムでのOracle Clusterwareファイル用のディレクトリの作成

- 共有ファイル・システムでのOracle Databaseファイル用のディレクトリの作成

注意:
OCRは、クラスタの構成情報とステータスを含むファイルです。OCRは、Oracle Universal Installer(OUI)によって、Oracle Clusterwareのインストール時に自動的に初期化されます。Database Configuration Assistantは、OCRを使用して、作成するクラスタ・データベースの構成情報を格納します。

6.2.1 共有ファイル・システムを使用するための要件

Oracle Clusterware、Oracle ASM、Oracle RACに共有ファイル・システムを使用するには、ファイル・システムで次の要件を満たす必要があります。

- NFSファイル・システムを使用するには、動作保証されているNASデバイス上にある必要があります。次のURLでMy Oracle Supportにログインし、「動作保証」タブをクリックして、動作保証されているNASデバイスのリストを調べます。
https://support.oracle.com/

- Oracle Cluster Registry(OCR)ファイルを共有ファイル・システムに配置するように選択する場合は、次のいずれかに該当していることが推奨されます。

- ファイル・システムに使用されるディスクが、高可用性のストレージ・デバイス(RAIDデバイスなど)にある。

- 2つ以上のファイル・システムがマウントされていて、Oracle Clusterware 11g リリース2(11.2)の機能を使用してOCRに冗長性を提供している。

- データベース・ファイルを共有ファイル・システムに配置するように選択する場合、次のいずれかに該当している必要があります。

- ファイル・システムに使用されるディスクが、高可用性のストレージ・デバイス(RAIDデバイスなど)にある。

- ファイル・システムは、2つ以上の独立したファイル・システムで構成されています。一方のファイル・システムではデータベース・ファイル、もう一方のファイル・システムではリカバリ・ファイルが使用されます。

- インストールを実行するユーザー・アカウント(oracleまたはgrid)には、指定したパスにファイルを作成するための書込み権限が必要です。

注意:
SRVM構成リポジトリに使用したRAWデバイスまたは共有ファイルをOCRに使用しているOracle9iリリース2からのアップグレードは、サポートされていません。
Oracle Clusterwareをアップグレードする場合、既存のクラスタでOCRパーティションに100MB、投票ディスク・パーティションに20MBが使用されている場合、OCRパーティションを400MB以上に拡張する必要があり、投票ディスク・パーティションは300MB以上に拡張した方がよいでしょう。パーティションは使用せず、OCRおよび投票ディスクをQUORUMディスク・グループとしてマークされたディスク・グループに配置することをお薦めします。

すべてのストレージ製品は、サーバー・ベンダーとストレージ・ベンダーの両方でサポートされている必要があります。

6.2.2 Oracle Grid Infrastructure共有ファイル・システムのボリューム・サイズ要件

表6-2と表6-3を使用して、共有ファイル・システムの最小サイズを決定します。

表6-2 Oracle Clusterware共有ファイル・システムのボリューム・サイズ要件

格納されるファイル・タイプ

ボリュームの数

ボリュームのサイズ

外部冗長で作成された投票ディスク

1

投票ディスク・ボリュームごとに300MB以上

外部冗長で作成されたOracle Cluster Registry(OCR)

1

OCRボリュームごとに400MB以上

表6-3 Oracle RAC共有ファイル・システムのボリューム・サイズ要件

格納されるファイル・タイプ

ボリュームの数

ボリュームのサイズ

Oracle Databaseファイル

1

ボリュームごとに1.5GB以上

リカバリ・ファイル

注意: リカバリ・ファイルはデータベース・ファイルとは異なるボリュームに配置する必要があります。

1

ボリュームごとに2GB以上

表6-2および表6-3で、必要なボリューム・サイズの合計を加算して求めます。たとえば、標準冗長を使用してすべてのOracle Clusterwareファイルを共有ファイル・システムに格納するには、3つ以上のボリューム(OCRと2つのOCRミラー用に3つの別々のボリューム位置と、ボリュームごとに1つの投票ディスク)で2GB以上の記憶域が使用可能である必要があります。投票ディスクおよびOCRファイルを別々の物理ディスクに確実に配置するには、500MB以上の物理ディスクが3つ以上必要です。Oracle RACを追加して、データベース・ファイルにボリューム1つ、リカバリ・ファイルにボリューム1つを使用する場合、2つのボリュームで3.5GB以上、全ボリュームの合計で6.9GB以上の利用可能な記憶域が必要です。

注意:
fdiskでデバイス・サイズ(+400Mなど)を指定し、共有パーティション上にパーティションを作成する際、実際に作成されるデバイスは、ディスクのシリンダ・ジオメトリに基づいて、要求したサイズより小さくなる場合があります。これは、現在のfdiskにおける制限事項が原因です。Oracle ASMで使用するために割り当てたディスク全体をパーティション化することをお薦めします。

6.2.3 Oracle Clusterwareファイル用のクラスタ・ファイル・システムの使用の確認

新規インストールの場合は、Oracle Automatic Storage Management(Oracle ASM)を使用して、投票ディスクおよびOCRファイルを格納することをお薦めします。

6.2.4 データ・ファイル用のDirect NFSクライアントの使用の確認

カーネルで管理されるNFSのかわりにDirect NFSクライアントを使用することもできます。この項では、Direct NFSクライアントについて次の内容で説明します。

- Direct NFSクライアント・ストレージについて

- oranfstabファイルおよびDirect NFSクライアントについて

- Direct NFSクライアントを使用したNFS記憶域デバイスのマウントについて

- oranfstabファイルを使用したネットワーク・パスの指定

6.2.4.1 Direct NFSクライアント・ストレージについて

Oracle Database 11g リリース2(11.2)では、オペレーティング・システムのカーネルNFSクライアントを使用するかわりに、Oracle内部のDirect NFSクライアントを使用してNFS V3サーバーに直接アクセスするようにOracle Databaseを構成できます。

Oracle DatabaseでDirect NFSクライアントを使用できるようにするには、インストールを開始する前に、NFSファイル・システムをマウントし、通常のNFSマウントを介して使用できるようにする必要があります。設定は、インストール後にDirect NFSクライアントで管理されます。その場合でも、カーネルのマウント・オプションをバックアップとして設定する必要はありますが、通常の動作では、Direct NFSクライアントでNFSマウントが管理されます。

NFSの構成およびマウントを実行する方法については、ベンダーのマニュアルを参照してください。

一部のNFSファイル・サーバーでは、予約されたポートを使用してNFSクライアントを接続する必要があります。予約されたポートのチェックを使用してファイラを実行している場合は、Direct NFSクライアントが動作するように、予約されたポートのチェックを無効にする必要があります。予約されたポートのチェックを無効にする方法については、使用しているNFSファイル・サーバーのドキュメントを参照してください。

ポート範囲を制限するNFSサーバーの場合、rootでNFSサーバーに接続するのではなく、insecureオプションを使用してクライアントを有効化できます。または、第6.3.10項「NFSのDirect NFSクライアントのOracle Disk Management制御の無効化」の説明に従って、Direct NFSクライアントを無効にできます。

注意:
Oracle RACでサポートされているNFSサーバーを使用してください。動作保証については、次のURLを参照してください。
https://support.oracle.com

6.2.4.2 oranfstabファイルおよびDirect NFSクライアントについて

Direct NFSクライアントを使用する場合、Oracleのデータ・ファイル管理専用の新しいファイル(oranfstab)を使用して、Direct NFSクライアントにOracle Database固有のオプションを追加指定できます。たとえば、oranfstabを使用して、マウント・ポイントの追加のパスを指定できます。oranfstabファイルは、/etcまたは$ORACLE_HOME/dbsのいずれかに追加できます。

共有Oracleホームでは、oranfstabファイルが$ORACLE_HOME/dbsに格納されている場合、このファイルのエントリは、単一データベースに固有のエントリとなります。この場合、Oracle RACデータベースを実行するすべてのノードで同じ$ORACLE_HOME/dbs/oranfstabファイルが使用されます。共有されていないOracle RACインストールでは、oranfstabをすべてのノードにコピーする必要があります。

oranfstabファイルが/etcに格納されている場合、このファイルはすべてのOracle Databaseでグローバルに使用できます。また、oranfstabファイルには、クラスタ内のノードで実行されているすべてのOracle Database(スタンドアロン・データベースを含む)で使用されるマウント・ポイントを含めることができます。ただし、Oracle RACシステムでは、oranfstabファイルが/etcに格納されている場合、/etc/fstabファイルの場合と同様に、すべてのノードに/etc/oranfstabファイルをレプリケートし、各/etc/oranfstabファイルをすべてのノードで同期させる必要があります。

関連項目:
/etc/fstabの構成の詳細は、第6.3.1項「記憶域のNFSマウントおよびバッファ・サイズ・パラメータの構成」を参照してください。

マウント・ポイントがDirect NFSクライアントを使用して処理されているときでも、マウント・ポイントはカーネルNFSシステムによってマウントされる必要があります。オペレーティング・システムNFSの構成およびマウントを実行する方法については、そのベンダーのドキュメントを参照してください。

注意:
Direct NFSクライアントは、NFSサーバーの書込みサイズ値(wtmax)が32768未満の場合は機能しません。

6.2.4.3 Direct NFSクライアントを使用したNFSストレージ・デバイスのマウントについて

Direct NFSクライアントでは、/etc/mnttabの構成に基づいてNFSストレージ・デバイスに対するマウント・ポイント設定が決定されます。このファイルの構成は、/etc/fstabファイルの構成によって変更されます。

Direct NFSクライアントでは、次の順序でマウント・エントリが検索され、最初に検索された一致するエントリを使用します。

1. $ORACLE_HOME/dbs/oranfstab

2. /etc/oranfstab

3. /etc/mnttab

Direct NFSクライアントでは、最初に検出されたエントリがマウント・ポイントとして使用されます。

Oracle Databaseでは、Direct NFSクライアントを介して提供されている場合でも、マウント・ポイントはカーネルNFSシステムによってマウントされる必要があります。

注意:
インスタンスごとにアクティブなDirect NFSクライアントを1つのみ実装することができます。インスタンスでDirect NFSクライアントを使用すると、別のDirect NFSクライアントは実装できなくなります。

Oracle Databaseでoranfstabを使用して構成されたDirect NFSクライアントのマウント・ポイントを使用する場合は、まず、オペレーティング・システムのNFSマウント・ポイントを使用してoranfstab内のエントリをクロスチェックすることによってカーネルNFSマウントが検証されます。不一致が存在する場合、Direct NFSクライアントでは、情報メッセージを記録し、動作しません。

Oracle DatabaseでDirect NFSクライアントを使用してNFSサーバーを開くことができない場合は、プラットフォームのオペレーティング・システムのカーネルNFSクライアントが使用されます。この場合、カーネルNFSマウント・オプションは、第6.3.3項「Oracle RAC用のNFSマウントおよびバッファ・サイズ・パラメータの確認」で定義されているとおりに設定する必要があります。また、Direct NFSクライアントをNFSサーバーに接続することができなかったことを示す情報メッセージが、Oracleアラート・ファイルおよびトレース・ファイルに記録されます。

第6.1.1項「サポートされている記憶域オプション」に、Direct NFSクライアントでサポートされているファイル・タイプを示します。

Direct NFSクライアントによって処理されるNFSサーバーに存在するOracleファイルにも、オペレーティング・システムのカーネルNFSクライアントを介してアクセスできます。

関連項目:
Direct NFSクライアントまたはカーネルNFSで作成されたOracle Databaseデータ・ファイルの管理におけるガイドラインについては、『Oracle Database Storage管理者ガイド』を参照してください。

6.2.4.4 oranfstabファイルを使用したネットワーク・パスの指定

Direct NFSクライアントでは、NFSサーバー用のoranfstabファイルに定義されている最大4つのネットワーク・パスを使用できます。Direct NFSクライアントによって、指定したすべてのパス間でロード・バランシングが実行されます。指定したパスで障害が発生した場合は、Direct NFSクライアントによって、残りのパスに対してI/Oコマンドが再発行されます。

クラスタ環境でDirect NFSクライアントを管理するには、次のSQL*Plusのビューを使用します。

- gv$dnfs_servers: Direct NFSクライアントを使用してアクセスしたサーバーの表が表示されます。

- gv$dnfs_files: Direct NFSクライアントを使用して現在開かれているファイルの表が表示されます。

- gv$dnfs_channels: Direct NFSクライアントによってファイルが提供されるサーバーに対するオープン・ネットワーク・パス(またはチャネル)の表が表示されます。

- gv$dnfs_stats: Direct NFSクライアントのパフォーマンス統計の表が表示されます。

注意:
シングル・インスタンスにはv$ビューを使用し、Oracle ClusterwareおよびOracle RAC記憶域にはgv$ビューを使用します。

6.2.5 データ・ファイル用のNFSの使用の確認

ネットワーク接続ストレージ(NAS)システムでは、データへのアクセスにNFSが使用されます。サポートされているNFSシステムにデータ・ファイルを格納できます。

インストールを開始する前に、NFSファイル・システムをマウントし、NFSマウントを介して使用できるようにする必要があります。NFSの構成およびマウントを実行する方法については、ベンダーのマニュアルを参照してください。

OracleソフトウェアおよびデータベースがNASデバイスに格納されている場合、そのパフォーマンスは、OracleサーバーとNASデバイス間のネットワーク接続のパフォーマンスによって左右されることに注意してください。

そのため、サーバーとNASデバイスの接続には、ギガビット・イーサネット以上のプライベートな専用ネットワーク接続を使用することをお薦めします。

6.3 オペレーティング・システムおよびDirect NFSクライアントの構成

オペレーティング・システムおよびDirect NFSクライアントを構成するには、次の項を参照してください。

- 記憶域のNFSマウントおよびバッファ・サイズ・パラメータの構成

- Oracle Clusterware用のNFSマウントおよびバッファ・サイズ・パラメータの確認

- Oracle RAC用のNFSマウントおよびバッファ・サイズ・パラメータの確認

- Direct NFSクライアントのためのTCPネットワーク・プロトコル・バッファの確認

- NFSのDirect NFSクライアントのOracle Disk Manager制御の有効化

- oranfstabファイルを使用したネットワーク・パスの指定

- 共有ファイル・システムでのOracle Clusterwareファイル用のディレクトリの作成

- 共有ファイル・システムでのOracle Databaseファイル用のディレクトリの作成

- NFSのDirect NFSクライアントのOracle Disk Management制御の無効化

6.3.1 記憶域のNFSマウントおよびバッファ・サイズ・パラメータの構成

GridホームまたはOracle RACホームにNFSを使用している場合、次を有効にするために記憶域にNFSマウントを設定する必要があります。

- 記憶域にマウントされるクライアントのrootユーザーは、(匿名ユーザーとしてマップされているのではなく、)ファイル・サーバーのrootユーザーとみなすことができます。

- クライアント・サーバーのrootユーザーは、ファイル・サーバーのrootが所有しているNFSファイル・システムにファイルを作成できます。

NFSでは、サーバー側でroot=access_listを有効にすることで、記憶域に書込みを行うクライアントにrootアクセス権を取得できます。たとえば、ドメインmycluster.example.comのノードnode1、node2、node3について、パス/vol/gridのOracle Clusterwareファイル記憶域を設定するには、次のような行を/etc/dfs/dfstabファイルに追加します。

share -F nfs -o
rw=node1.mycluster.example.com,node2,mycluster.example.com,node3.mycluster.example
.com,root=node1.mycluster.example.com,node2.mycluster.example.com,node3.mycluster.
example.com /vol/grid

注意:
共有設定は1行で入力してください。

ドメインまたはDNSがセキュアで、許可されていないシステムはそのIPアドレスを取得できない場合には、特定のクラスタ・メンバー・ノードを指定するのではなく、ドメインごとにrootアクセス権を付与します。

次に例を示します。

/vol/grid/ *.mycluster.example.com

この構文を使用すると、NFSサーバーの再構成を行うことなくノードの追加や削除を行えます。セキュアなDNSまたはドメインを使用して、そのドメインを利用するクラスタ・メンバー・ノードにrootアクセス権を付与することをお薦めします。

グリッド・ネーミング・サービス(GNS)を使用する場合、クラスタ内でGNSによる解決で割り当てられるサブドメインは、セキュアなドメインです。適切に署名されたGPnP(グリッドのプラグ・アンド・プレイ)のプロファイルがないサーバーは、クラスタに参加できません。そのため、許可されていないシステムは、GNSサブドメイン内の名前を取得または使用できません。

注意:
ドメイン単位でrootアクセス権を付与すると、システムへの不正アクセスに利用される場合があります。システム管理者は、root=accessの使用に付随するリスクについて、オペレーティング・システムのドキュメントを参照してください。

/etc/dfs/dfstabを変更したら、次のコマンドを使用してファイル・システムのマウントをリロードします。

# /usr/sbin/shareall

6.3.2 Oracle Clusterware用のNFSマウントおよびバッファ・サイズ・パラメータの確認

クラスタ・メンバー・ノード上では、NFSバッファ・サイズ・パラメータrsizeおよびwsizeの値を32768に設定する必要があります。

データ・ファイルのNFSクライアント側のマウント・オプションは次のとおりです。

rw,bg,vers=3,proto=tcp,noac,forcedirectio,hard,nointr,timeo=600,rsize=32768,wsize=32768

Oracle Clusterwareファイル(OCRおよび投票ディスク・ファイル)のNFSクライアント側のマウント・オプションは次のとおりです。

rw,bg,vers=3,proto=tcp,noac,
forcedirectio,hard,nointr,timeo=600,
rsize=32768,wsize=32768,suid

ご使用のプラットフォームのNFSマウント・オプションを含むエントリで各ノードの/etc/fstabファイルを更新します。たとえば、Oracle Clusterwareファイル用のマウント・ポイントを作成する場合には、/etc/fstabファイルを次のエントリで更新します。

nfsserver:/vol/grid  /u02/oracle/cwfiles nfs \
rw,bg,vers=3,proto=tcp,noac,forcedirectio,hard,nointr,timeo=600,rsize=32768,wsize=32768,suid 0 0

Oracle Clusterwareファイル(OCRおよび投票ディスク)およびデータ・ファイルと比較して、Oracleソフトウェアのバイナリのマウント・ポイント・オプションが異なることに注意してください。

バイナリ専用のマウント・ポイントを作成するには、バイナリ・マウント・ポイントに次のようなエントリを入力します。

nfs-server:/vol/bin /u02/oracle/grid nfs \
rw,bg,vers=3,proto=tcp,noac,hard,nointr,timeo=600,rsize=32768,wsize=32768,suid

関連項目:
マウント・オプションの最新情報については、My Oracle Supportのbulletin 359515.1「Mount Options for Oracle Files When Used with NAS Devices」を参照してください。次のURLから入手可能です。
https://support.oracle.com

注意:
マウント・オプションの詳細は、ストレージ・ベンダーのマニュアルを参照してください。

6.3.3 Oracle RAC用のNFSマウントおよびバッファ・サイズ・パラメータの確認

NFSマウントを使用する場合、データベース・ファイルの格納に使用するNFSボリュームは、特別なマウント・オプションを指定し、Oracle RACインスタンスのある各ノード上にマウントする必要があります。NFSファイル・システムをマウントするときは、NASベンダーがデバイスの動作保証に使用したのと同じマウント・ポイント・オプションを使用することをお薦めします。推奨されるマウント・ポイント・オプションについては、デバイスのドキュメントを参照するか、ベンダーにご相談ください。

各ノードの/etc/fstabファイルを次のエントリで更新します。

nfs-server:/vol/DATA/oradata  /u02/oradata     nfs\
rw,bg,hard,nointr,noac,proto=tcp,vers=3,timeo=600,
rsize=32768,wsize=32768 0 0

必須のマウント・オプションは、NFSボリュームのマウント時に使用する必要のある最小限のマウント・オプション・セットを構成します。これらのマウント・オプションは、データの整合性を保護し、データベースの破損を防ぐために不可欠です。これらのマウント・オプションを使用しなかった場合は、ファイル・アクセス・エラーが発生する可能性があります。ご使用のプラットフォームでサポートされている個々のオプションの詳細は、オペレーティング・システムまたはNASデバイスのドキュメントを参照してください。

関連項目:
NASマウント・オプションの最新情報については、次のURLにあるMy Oracle SupportのNote 359515.1を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=359515.1

6.3.4 Direct NFSクライアントのためのTCPネットワーク・プロトコル・バッファの確認

デフォルトでネットワークのバッファ・サイズは、TCPでは1 MB、UDPでは2 MBに設定されます。TCPバッファ・サイズはファイル転送に制限を設定することが可能で、これはDirect NFSクライアント・ユーザーのパフォーマンスにマイナスの影響を与える場合があります。

現在のTCPバッファ・サイズをチェックするには、次のコマンドを入力します。

bash-4.0$ ndd -get /dev/tcp tcp_xmit_hiwater_max
bash-4.0$ ndd -get /dev/tcp tcp_recv_hiwater_max

サーバーのリンク速度に基づいて値を設定することをお薦めします。次に例を示します。

bash-4.0# ndd -set /dev/tcp tcp_xmit_hiwater_max 10485760
bash-4.0# ndd -set /dev/tcp tcp_recv_hiwater_max 10485760

6.3.5 NFSのDirect NFSクライアントのOracle Disk Manager制御の有効化

デフォルトでは、Direct NFSクライアントは有効な状態でインストールされます。ただし、Direct NFSクライアントが無効になっており、有効にする場合には、次の手順を完了させてDirect NFSクライアントを有効にします。

1. Direct NFSクライアントを使用してアクセスする各NFSサーバーの次の属性を使用してoranfstabファイルを作成します。

- server: NFSサーバー名。

- local: IPアドレスまたは名前のいずれかで指定された、データベース・ホスト上の最大4つのパスであり、データベース・ホスト上でifconfigコマンドを使用して表示できます。

- path: IPアドレスまたは名前のいずれかで指定された、NFSサーバーへの最大4つのネットワーク・パスであり、NFSサーバー上でifconfigコマンドを使用して表示できます。

- export: NFSサーバーからエクスポートされたパス。

- mount: エクスポートされたボリュームに対応する、ローカル・マウント・ポイント。

- mnt_timeout: Direct NFSクライアントがマウント成功を待機し、タイムアウトするまでの時間(秒)を指定します。このパラメータはオプションです。デフォルトのタイムアウトは10分(600)です。

- nfs_version: Direct NFSクライアントが使用するNFSプロトコルのバージョンを指定します。設定可能な値は、NFSv3、NFSv4およびNFSv4.1です。デフォルトのバージョンはNFSv3です。NFSv4.xを選択する場合、oranfstabでnfs_versionの値を構成する必要があります。

- dontroute: 送信メッセージをオペレーティング・システムでルーティングせず、そのかわりに、そのメッセージがバインドされたIPアドレスを使用して送信するよう指定します。

関連項目:
非同期I/Oの制限の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

この後の例では、oranfstabのNFSサーバー・エントリを3種類示しています。1つのoranfstabに、複数のNFSサーバー・エントリを含めることができます。

例6-1 ローカルおよびパスのNFSサーバー・エントリを使用

次の例では、ローカルとパスの両方を使用しています。それぞれが異なるサブネットにあるため、dontrouteを指定する必要がありません。

server: MyDataServer1
local: 192.0.2.0
path: 192.0.2.1
local: 192.0.100.0
path: 192.0.100.1
export: /vol/oradata1 mount: /mnt/oradata1

例6-2 同一サブネット内のローカルおよびパスを使用(dontrouteを指定)

次の例では、同一サブネット内のローカルおよびパスを示しています。ここではdontrouteが指定されています。

server: MyDataServer2
local: 192.0.2.0
path: 192.0.2.128
local: 192.0.2.1
path: 192.0.2.129
dontroute
export: /vol/oradata2 mount: /mnt/oradata2

例6-3 IPアドレスのかわりに名前を使用(複数のエクスポート)

server: MyDataServer3
local: LocalPath1
path: NfsPath1
local: LocalPath2
path: NfsPath2
local: LocalPath3
path: NfsPath3
local: LocalPath4
path: NfsPath4
dontroute
export: /vol/oradata3 mount: /mnt/oradata3
export: /vol/oradata4 mount: /mnt/oradata4
export: /vol/oradata5 mount: /mnt/oradata5
export: /vol/oradata6 mount: /mnt/oradata6

2. Oracle Databaseでは、Direct NFSクライアントを有効にするためにODMライブラリlibnfsodm11.soを使用します。標準のODMライブラリ$ORACLE_HOME/lib/libodm11.soをODM NFSライブラリlibnfsodm11.soと置き換えるには、Oracleホーム・ディレクトリが共有されていないかぎり、すべてのノードで次の手順を実行します。

1. $ORACLE_HOME/libに移動します。

2. 次のコマンドを入力します。

cp libodm11.so libodm11.so_stub
ln -s libnfsodm11.so libodm11.so

6.3.6 oranfstabファイルを使用したネットワーク・パスの指定

Direct NFSクライアントでは、NFSサーバー用のoranfstabファイルに定義されている最大4つのネットワーク・パスを使用できます。Direct NFSクライアントによって、指定したすべてのパス間でロード・バランシングが実行されます。指定したパスで障害が発生した場合は、Direct NFSクライアントによって、残りのパスに対してI/Oコマンドが再発行されます。

クラスタ環境でDirect NFSクライアントを管理するには、次のSQL*Plusのビューを使用します。

- gv$dnfs_servers: Direct NFSクライアントを使用してアクセスしたサーバーの表が表示されます。

- gv$dnfs_files: Direct NFSクライアントを使用して現在開かれているファイルの表が表示されます。

- gv$dnfs_channels: Direct NFSクライアントによってファイルが提供されるサーバーに対するオープン・ネットワーク・パス(またはチャネル)の表が表示されます。

- gv$dnfs_stats: Direct NFSクライアントのパフォーマンス統計の表が表示されます。

注意:
シングル・インスタンスにはv$ビューを使用し、Oracle ClusterwareおよびOracle RAC記憶域にはgv$ビューを使用します。

6.3.7 Direct NFSクライアントにおけるハイブリッド列圧縮の有効化

Direct NFSクライアントでハイブリッド列圧縮(HCC)を有効にする手順:

1. ZFSストレージ・サーバーでSNMPが有効であることを確認します。次に例を示します。

$ snmpget -v1 -c public server_name .1.3.6.1.4.1.42.2.225.1.4.2.0
SNMPv2-SMI::enterprises.42.2.225.1.4.2.0 = STRING: "Sun Storage 7410"

2. NFSサーバー以外のインタフェースでSNMPが有効な場合は、managementパラメータを使用してoranfstabを構成します。

3. public以外のコミュニティ文字列を使用してSNMPが構成されている場合は、communityパラメータを使用してoranfstabファイルを構成します。

4. snmpgetが使用可能かどうかを確認して、libnetsnmp.soがインストールされていることを確認します。

6.3.8 共有ファイル・システムでのOracle Clusterwareファイル用のディレクトリの作成

次の手順に従って、Oracle Clusterwareファイル用のディレクトリを作成します。また、Oracle Databaseおよびリカバリ・ファイル用に共有ファイル・システムを構成することもできます。

注意:
NFS記憶域については、Oracleベース・ディレクトリとは別のファイル・システムにOracle Clusterwareファイルを格納する場合にのみ、この手順を実行する必要があります。

Oracleベース・ディレクトリとは別のファイル・システムにOracle Clusterwareファイル用のディレクトリを作成するには、次の手順を実行します。

1. 必要に応じて、各ノードで使用する共有ファイル・システムを構成し、マウントします。

注意:
ファイル・システムに使用するマウント・ポイントは、すべてのノードで同一である必要があります。ノードの再起動時、自動的にマウントされるように、ファイル・システムが構成されていることを確認してください。

2. bdfコマンドを使用して、マウントされた各ファイル・システムの空きディスク領域を確認します。

3. 表示された情報から、使用するファイル・システムを特定します。600MB以上の空きディスク領域(外部冗長を使用、OCRと投票ディスクを1つずつ)があるファイル・システムを選択します。
複数のファイル・タイプに対して同じファイル・システムを使用している場合は、各タイプに対するディスク領域要件を追加して、ディスク領域要件の合計を判断します。

4. 選択したファイル・システムに対するマウント・ポイント・ディレクトリの名前を書き留めます。

5. インストールを実行しているユーザー(通常、gridかoracle)が、Oracle Clusterwareファイルをインストールする記憶域の場所にディレクトリを作成する権限を所有している場合は、OUIによってOracle Clusterwareファイル・ディレクトリが作成されます。
インストールを実行しているユーザーが書込み権限を所有していない場合は、次のコマンドを使用してこれらのディレクトリを手動で作成する必要があります。次のコマンドでは、それぞれのマウント・ポイント・ディレクトリに推奨されるサブディレクトリが作成され、そのディレクトリに適切な所有者、グループおよび権限が設定されます。たとえば、ユーザーがoracle、Oracle Clusterwareファイルの記憶域がclusterの場合は、次のようになります。

# mkdir /mount_point/cluster
# chown oracle:oinstall /mount_point/cluster
# chmod 775 /mount_point/cluster

注意:
インストール後、Oracle Cluster Registry(OCR)ファイルのインストール・パスにあるディレクトリはrootが所有し、root以外のアカウントでは書込みできないようにする必要があります。

マウント・ポイント・ディレクトリにサブディレクトリを作成し、適切な所有者、グループおよび権限を設定したら、Oracle Grid Infrastructure用のNFSの構成は完了です。

6.3.9 共有ファイル・システムでのOracle Databaseファイル用のディレクトリの作成

Oracle Databaseの共有ファイル・システム用のディレクトリ、および(Oracle RACデータベース用などの)リカバリ・ファイル用のディレクトリを作成するには、次の手順を実行します。

1. 必要に応じて、各ノードで共有ファイル・システムを構成し、マウントします。

注意:
ファイル・システムに使用するマウント・ポイントは、すべてのノードで同一である必要があります。ノードの再起動時、自動的にマウントされるように、ファイル・システムが構成されていることを確認してください。

2. bdfコマンドを使用して、マウントされた各ファイル・システムの空きディスク領域を確認します。

3. 表示された情報から、ファイル・システムを特定します。

ファイル・タイプ

ファイル・システムの要件

データベース・ファイル

次のいずれかを選択します。

- 1.5GB以上の空き領域を持つ単一のファイル・システム

- 合計1.5GB以上の空き領域を持つ複数のファイル・システム

リカバリ・ファイル

2GB以上の空き領域を持つ単一のファイル・システムを選択します。

複数のファイル・タイプに対して同じファイル・システムを使用している場合は、各タイプに対するディスク領域要件を追加して、ディスク領域要件の合計を判断します。

4. 選択したファイル・システムに対するマウント・ポイント・ディレクトリの名前を書き留めます。

5. インストールを実行しているユーザー(通常、oracle)がOracle Databaseをインストールするディスクにディレクトリを作成する権限を所有している場合は、DBCAによってOracle Databaseファイル・ディレクトリおよびリカバリ・ファイル・ディレクトリが作成されます。
インストールを実行しているユーザーが書込み権限を所有していない場合は、次のコマンドを使用してこれらのディレクトリを手動で作成する必要があります。次のコマンドでは、それぞれのマウント・ポイント・ディレクトリに推奨されるサブディレクトリが作成され、適切な所有者、グループおよびそのサブディレクトリの権限が設定されます。

- データベース・ファイル・ディレクトリ:

# mkdir /mount_point/oradata
# chown oracle:oinstall /mount_point/oradata
# chmod 775 /mount_point/oradata

- リカバリ・ファイル・ディレクトリ(高速リカバリ領域):

# mkdir /mount_point/fast_recovery_area
# chown oracle:oinstall /mount_point/fast_recovery_area
# chmod 775 /mount_point/fast_recovery_area

oinstallグループのメンバーをこれらのディレクトリの所有者にすると、これらのディレクトリが複数のOracleホーム(異なるOSDBAグループによるものも含む)から読み取られるようになります。

それぞれのマウント・ポイント・ディレクトリにサブディレクトリを作成し、適切な所有者、グループおよび権限を設定すると、Oracle Databaseの共有記憶域用のNFSの構成は完了です。

6.3.10 NFSのDirect NFSクライアントのOracle Disk Management制御の無効化

Direct NFSクライアントを無効にするには、次の手順を実行します。

1. Oracle Grid Infrastructureインストール所有者としてログインして、次のコマンドを使用してDirect NFSクライアントを無効にします(ここで、Grid_homeはOracle Grid Infrastructureホームへのパスです)。

$ cd Grid_home/rdbms/lib
$ make -f ins_rdbms.mk dnfs_off

クラスタの各ノード、または共有Gridホーム(Oracle Grid Infrastructureインストールに共有ホームを使用している場合)でこれらのコマンドを入力します。

2. oranfstabファイルを削除します。

注意:
Oracle Databaseで使用されているNFSパスを削除する場合は、データベースを再起動してその変更を有効にする必要があります。

6.4 Oracle Automatic Storage Managementの記憶域の構成

次の項で、Oracle Automatic Storage Management(Oracle ASM)の記憶域の構成について説明します。

- Oracle Automatic Storage Management用の記憶域の構成

- Oracle ASMでのOracle Databaseファイルとディスク・グループの使用

6.4.1 Oracle Automatic Storage Management用の記憶域の構成

この項では、Oracle Automatic Storage Management(Oracle ASM)で使用する記憶域の構成方法について説明します。

- Oracle ASMの記憶域要件の指定

- Oracle ASMで使用するためのNASデバイスでのファイルの作成

- 既存のOracle ASMディスク・グループの使用

- Oracle ASM用のディスク・デバイスの構成

6.4.1.1 Oracle ASMの記憶域要件の指定

Oracle ASMを使用するための記憶域要件を指定するには、必要なデバイス数およびディスクの空き領域を確認する必要があります。この作業を実行するには、次の手順を実行します。

1. Oracle ASMを、Oracle Clusterwareファイル(OCRおよび投票ディスク)、Oracle Databaseファイルまたはリカバリ・ファイルに使用するか、Oracle ClusterwareおよびOracle Databaseのバイナリを除くすべてのファイルに使用するかを決定します。Oracle Databaseファイルには、データ・ファイル、制御ファイル、REDOログ・ファイル、サーバー・パラメータ・ファイルおよびパスワード・ファイルが含まれています。

注意:
Oracle Clusterware、Oracle Databaseファイルおよびリカバリ・ファイルに対して、同じメカニズムの記憶域を使用する必要はありません。一方のファイル・タイプに共有ファイル・システムを、他方にOracle ASMを使用することもできます。
自動バックアップを有効にすることを選択し、使用可能な共有ファイル・システムがない場合は、リカバリ・ファイルの記憶域にOracle ASMを使用する必要があります。

インストール中に自動バックアップを有効にした場合は、高速リカバリ領域にOracle Automatic Storage Managementディスク・グループを指定することで、リカバリ・ファイル用の記憶域メカニズムとしてOracle ASMを選択できます。非対話型のインストール・モードを選択した場合、デフォルトで1つのディスク・グループが作成され、そこにOCRと投票ディスク・ファイルが格納されます。後続のデータベース・インストールで使用するために他のディスク・グループが必要な場合は、対話型モードを選択するか、ASMCA(コマンドライン・ツール)を実行して、データベースのインストールを開始する前に、適切なディスク・グループを作成します。

2. Oracle ASMディスク・グループに使用するOracle ASMの冗長レベルを選択します。
Oracle ASMディスク・グループに選択した冗長レベルによって、Oracle ASMでディスク・グループ内のファイルをミラー化する方法および必要となるディスク数と空きディスク領域は次のようになります。

- 外部冗長
外部冗長ディスク・グループでは、最小で1台のディスク・デバイスが必要です。外部冗長のディスク・グループで有効なディスク領域は、全デバイスのディスク領域の合計です。

Oracle Clusterwareファイルの場合、外部冗長ディスク・グループは、コピーなしの1つの投票ディスクと1つのOCRを提供します。高可用性を確保するためにミラー化を行うには、外部テクノロジを使用する必要があります。

Oracle ASMは外部冗長ディスク・グループ内のデータをミラー化しないため、RAIDなどのストレージ・デバイスによる外部冗長を使用するか、または独自のデータ保護メカニズムを持つ類似デバイスを使用することをお薦めします。

- 標準冗長
標準冗長ディスク・グループでは、パフォーマンスおよび信頼性を向上させるために、Oracle ASMはデフォルトで2方向のミラー化を使用します。標準冗長ディスク・グループでは、最小で2台のディスク・デバイス(または2つの障害グループ)が必要です。標準冗長のディスク・グループで有効なディスク領域は、すべてのデバイスのディスク領域の合計の半分です。

Oracle Clusterwareファイルの場合、標準冗長ディスク・グループでは、投票ディスク・ファイルが3つ、OCRが1つ、コピーが2つ(1つはプライマリ、1つはセカンダリ・ミラー)になります。標準冗長のクラスタは、障害グループを1つ失っても存続できます。

ほとんどの使用環境では、標準冗長を選択することをお薦めします。

- 高冗長
高冗長ディスク・グループでは、Oracle ASMはデフォルトで3方向のミラー化を使用してパフォーマンスを向上させ、最高レベルの信頼性を提供します。高冗長ディスク・グループでは、最小で3台のディスク・デバイス(または3つの障害グループ)が必要です。高冗長のディスク・グループで有効なディスク領域は、全デバイスのディスク領域の合計の3分の1です。

Oracle Clusterwareファイルの場合、高冗長ディスク・グループでは、投票ディスク・ファイルが5つ、OCRが1つ、コピーが3つ(1つはプライマリ、2つはセカンダリ・ミラー)になります。高冗長のクラスタは、障害グループを2つ失っても存続できます。

高冗長ディスク・グループでは、高レベルのデータ保護が提供されますが、この冗長レベルの使用を決定する前に、追加するストレージ・デバイスのコストを考慮する必要があります。

3. Oracle Clusterwareファイルと、データベース・ファイルおよびリカバリ・ファイルに必要なディスク領域の合計容量を決定します。
表6-4と表6-5を使用して、Oracle Clusterwareファイルのインストールと、初期データベースのインストールに必要なディスクの最小台数およびディスクの最小領域を決定します。投票ディスクは別のディスク・グループにあるものとします。

表6-4 冗長タイプによるOracle Clusterwareに必要な記憶領域の合計

冗長レベル

ディスクの最小台数

Oracle Cluster Registry(OCR)ファイル

投票ディスク・ファイル

合計

外部

1

300MB

300MB

600MB

標準

3

600MB

900MB

1.5GB脚注 1

高

5

840MB

1.4GB

4GB

脚注 1 インストール中にディスク・グループを作成する場合は、2GB以上にする必要があります。

注意:
投票ディスク・ファイルがディスク・グループにある場合、Oracle Clusterwareファイル(OCRおよび投票ディスク・ファイル)があるディスク・グループの障害グループの最小数は、他のディスク・グループよりも多くなります。
インストール中に、OCRおよび投票ディスク・ファイルのインストール先としてディスク・グループを作成する場合、使用可能な領域が2GB以上あるディスク・グループ上にこれらのファイルを作成するよう、インストーラによって求められます。

定数障害グループは特別なタイプの障害グループであり、これらの障害グループのディスクにユーザー・データは含まれません。定数障害グループは、ユーザー・データを格納するための冗長性要件を決定する際には考慮されません。ただし、ディスク・グループをマウントする場合は定数障害グループが考慮されます。

表6-5 冗長タイプによるOracle Databaseに必要な記憶領域の合計

冗長レベル

ディスクの最小台数

データベース・ファイル

リカバリ・ファイル

合計

外部

1

1.5GB

3GB

4.5GB

標準

2

3GB

6GB

9GB

高

3

4.5GB

9GB

13.5GB

4. Oracle Clusterwareインストールでは、Oracle ASMのメタデータ用にディスク領域を追加する必要もあります。次の計算式を使用して、OCR、投票ディスク・ファイルおよびOracle ASMメタデータの追加のディスク領域の要件(単位: MB)を計算します。
合計 = [2 * ausize * disks] + [redundancy * (ausize * (nodes * (clients + 1) + 30) + (64 * nodes) + 533)]

説明は次のとおりです。

- redundancy: ミラー数(外部 = 1、標準 = 2、高 = 3)

- ausize: メタデータのAUサイズ(MB単位)

- nodes: クラスタ内のノード数

- clients - 各ノードのデータベース・インスタンス数

- disks - ディスク・グループ内のディスク数

たとえば、標準冗長ディスク・グループに3台のディスクを使用する4ノードのOracle RACインストールでは、追加領域が必要になります。

[2 * 1 * 3] + [2 * (1 * (4 * (4 + 1) + 30) + (64 * 4) + 533)] = 1684MB

Oracle ASMでのOracle Clusterwareファイルの高可用性を確保するには、Oracle Clusterwareファイル用として、別々の3つの障害グループ(物理ディスクは3つ以上)に2GB以上のディスク容量が必要です。各ディスクには1GB以上の容量を確保して、容量に余裕を持ってOracle Clusterwareファイルを作成できるようにする必要があります。

5. 必要な場合は、Oracle ASMディスク・グループのデバイスに障害グループを指定します。
標準または高冗長ディスク・グループを使用する場合は、カスタム障害グループのディスク・デバイスを関連付けることによって、ハードウェア障害に対するデータベースの保護を強化できます。デフォルトでは、各デバイスに独自の障害グループが含まれます。ただし、標準冗長ディスク・グループの2台のディスク・デバイスが同じSCSIコントローラに接続されている場合、コントローラに障害が発生すると、ディスク・グループは使用できなくなります。この例でのコントローラは、シングル・ポイント障害です。

このタイプの障害を防止するためには、2つのSCSIコントローラを使用します。各コントローラに2台のディスクを接続し、各コントローラに接続されたディスクに障害グループを定義します。この構成では、ディスク・グループが1つのSCSIコントローラの障害を許容できるようになります。

注意:
インストール後に、GUIツールのASMCA、コマンドライン・ツールのasmcmd、またはSQLコマンドを使用して、カスタム障害グループを定義します。
カスタム障害グループを定義する際、データベース・ファイルのみを格納する障害グループの場合、標準冗長ディスク・グループでは最小で2つの障害グループ、高冗長ディスク・グループでは3つの障害グループを指定する必要があります。

データベース・ファイルと、投票ディスクを含むClusterwareファイルを格納する障害グループの場合は、標準冗長ディスク・グループでは3つ以上の障害グループ、高冗長ディスク・グループでは5つ以上の障害グループを指定する必要があります。

投票ファイルを格納するディスク・グループの場合、標準冗長では最小で3つの障害グループ、高冗長では最小で5つの障害グループが必要です。それ以外の場合、最小数はそれぞれ2つと3つです。障害グループの最小数は、カスタム障害グループかどうかにかかわらず適用されます。

6. システムに適切なディスク・グループが存在しない場合は、適切なディスク・デバイスを設置または指定して、新しいディスク・グループを追加します。次のガイドラインに従って、適切なディスク・デバイスを指定します。

- Oracle ASMディスク・グループのすべてのデバイスは、サイズおよびパフォーマンス特性が同じである必要があります。

- 単一の物理ディスクにある複数のパーティションを、1つのディスク・グループのデバイスとして指定しないでください。Oracle ASMは、各ディスク・グループのデバイスが、別々の物理ディスク上に存在するとみなします。

- 論理ボリュームは、Oracle ASMディスク・グループのデバイスとして指定できますが、Oracle ASMには不要なほどレイヤーが複雑になるため、この使用はお薦めしません。さらに、Oracle ASMおよびOracle RACで論理ボリュームを使用する場合、Oracle RACでは、クラスタ論理ボリューム・マネージャが必要です。
論理ボリューム・マネージャを使用する場合は、ストライプ化またはミラー化なしの単一のLUNとして論理ボリューム・マネージャを使用し、追加の記憶域レイヤーの影響を最小限に抑えるようにすることをお薦めします。

6.4.1.2 Oracle ASMで使用するためのNASデバイスでのファイルの作成

動作保証されているNASストレージ・デバイスがある場合は、NFSマウント・ディレクトリにゼロ埋込みファイルを作成し、そのファイルをOracle ASMディスク・グループのディスク・デバイスとして使用できます。

そのファイルを作成するには、次の手順を実行します。

1. 必要に応じて、NASデバイスのディスク・グループ・ファイル用にエクスポート・ディレクトリを作成します。
この手順の実行方法の詳細は、NASデバイスのドキュメントを参照してください。

2. ユーザーをrootに切り替えます。

3. マウント・ポイント・ディレクトリをローカル・システムに作成します。

4. システムの再起動時にNFSファイル・システムが確実にマウントされるように、マウント・ファイル/etc/fstabにファイル・システムのエントリを追加します。

関連項目:
NASマウント・オプションの最新情報については、次のURLにあるMy Oracle SupportのNote 359515.1を参照してください。

https://support.oracle.com

オペレーティング・システムに対応したマウント・ファイルの編集方法の詳細は、manページを参照してください。推奨されるマウント・オプションの詳細は、第6.3.3項「Oracle RAC用のNFSマウントおよびバッファ・サイズ・パラメータの確認」を参照してください。

5. NFSファイル・システムをローカル・システムにマウントします。

6. 作成するディスク・グループの名前を選択します。たとえば、sales1とします。

7. NFSファイル・システムにファイルのディレクトリを作成します。ディレクトリ名には、ディスク・グループの名前を付けます。

8. 次のようなコマンドを使用して、このディレクトリに必要な数のゼロ埋込みファイルを作成します。

# dd if=/dev/zero of=/mnt/nfsdg/disk1 bs=1024k count=1000

この例では、NFSファイル・システムに1GBのファイルを作成します。外部冗長、標準冗長または高冗長のディスク・グループを作成するには、それぞれ1つ、2つまたは3つのファイルを作成する必要があります。

9. 作成したディレクトリとファイルの所有者、グループおよび権限を変更するには、次のようなコマンドを入力します。インストール所有者はgrid、OSASMグループはasmadminです。

# chown -R grid:asmadmin /mnt/nfsdg
# chmod -R 660 /mnt/nfsdg

10. Oracle RACまたはスタンドアロンのOracle Databaseをインストールする場合は、インストール時に、Oracle ASMのディスク検出文字列を編集して、作成したファイル名と一致する正規表現を指定します。次に例を示します。

/mnt/nfsdg/sales1/

6.4.1.3 既存のOracle ASMディスク・グループの使用

既存のOracle ASMディスク・グループにデータベースまたはリカバリ・ファイルを格納するために、インストール方法に応じて次のいずれかを選択します。

- Database Configuration Assistantを対話型モードで実行するインストール方法を選択した場合、新しいディスク・グループを作成するか、または既存のディスク・グループを使用するかを選択できます。
インストール後にDatabase Configuration Assistantを使用してデータベースを作成する場合に、同じ選択内容を使用できます。

- Database Configuration Assistantを非対話型モードで実行するインストール方法を選択した場合、新しいデータベースには既存のディスク・グループを選択する必要があり、新しいディスク・グループは作成できません。ただし、要件に対して既存ディスク・グループの空き領域が不十分である場合は、既存ディスク・グループにディスク・デバイスを追加できます。

注意:
既存ディスク・グループを管理するOracle ASMインスタンスは、異なるOracleホーム・ディレクトリで実行されている可能性があります。

Oracle ASMディスク・グループがすでに存在するかどうか、またはディスク・グループのディスク領域が十分にあるかどうかを判断するには、Oracle Enterprise Manager Cloud ControlまたはOracle ASMコマンドライン・ツール(asmcmd)を次のとおりに使用します。

1. Oracle ASMインスタンスに接続し、必要に応じてインスタンスを起動します。

$ $ORACLE_HOME/bin/asmcmd
ASMCMD> startup

2. 次のコマンドのいずれかを入力して、既存のディスク・グループ、それらの冗長レベルおよび各グループでのディスクの空き領域を表示します。

ASMCMD> lsdb

または

$ORACLE_HOME/bin/asmcmd -p lsdg

3. 出力結果から、適切な冗長レベルが設定されているディスク・グループを特定し、そのディスク・グループにある空き領域を記録します。

4. 必要に応じて、前述の記憶域要件を満たすために必要な追加のディスク・デバイスを設置または指定します。

注意:
既存のディスク・グループにデバイスを追加する場合は、サイズおよびパフォーマンス特性が、そのディスク・グループ内の既存デバイスと同じであるデバイスの使用をお薦めします。

6.4.1.4 Oracle ASM用のディスク・デバイスの構成

HP-UX上のOracle ASMで使用するようにディスクを構成するには、次の手順を実行します。

1. 必要に応じて、Oracle ASMディスク・グループに使用する共有ディスクをインストールします。

2. ディスクが使用できることを確認するには、すべてのノードで次のコマンドを入力します。

# /usr/sbin/ioscan -fun -C disk

このコマンドの出力結果は、次のようになります。

Class  I  H/W Path    Driver S/W State   H/W Type     Description
==========================================================================
disk    0  0/0/1/0.6.0 sdisk  CLAIMED     DEVICE       HP   DVD-ROM 6x/32x
/dev/rdsk/c0t6d0   /dev/rdsk/c0t6d0
disk    1  0/0/1/1.2.0 sdisk  CLAIMED     DEVICE      SEAGATE ST39103LC
/dev/rdsk/c1t2d0   /dev/rdsk/c1t2d0

このコマンドによって、システムに接続されている各ディスクの情報が表示されます。キャラクタRAWデバイス名(/dev/rdsk/)も含まれます。

注意:
HP-UX 11i v.3では、アジャイル・ビューを使用して、キャラクタRAWデバイス(/dev/rdisk/diskxyz)を含む、マス・ストレージ・デバイスを確認することもできます。次に例を示します。

#>ioscan -funN -C disk
Class     I  H/W Path  Driver S/W State   H/W Type     Description
===================================================================
disk      4  64000/0xfa00/0x1   esdisk   CLAIMED     DEVICE       HP 73.4GST373454LC
/dev/disk/disk4   /dev/rdisk/disk4
disk    907  64000/0xfa00/0x2f  esdisk   CLAIMED     DEVICE       COMPAQ  MSA1000 VOLUME
/dev/disk/disk907   /dev/rdisk/disk907

3. ioscanコマンドで、使用するデバイスのデバイス名情報が表示されない場合は、次のコマンドを入力して、すべての新しいデバイス用に特別なデバイス・ファイルをインストールします。

# /usr/sbin/insf -e

4. ディスク・グループに追加するディスクごとに、任意のノードで次のコマンドを入力して、そのディスクがLVMボリューム・グループにまだ属していないことを確認します。

# /sbin/pvdisplay /dev/dsk/cxtydz

このコマンドによってボリューム・グループ情報が表示された場合、そのディスクはボリューム・グループにすでに属しています。選択するディスクは、LVMボリューム・グループに属していないものである必要があります。

注意:
別のボリューム管理ソフトウェアを使用する場合(VERITAS Volume Managerなど)、ディスクが使用されていないことを確認する方法について、該当するマニュアルを参照してください。

5. 各ノードで次のコマンドを入力し、所有者がOracle Grid Infrastructure所有者(この例では、grid)、アクセス権を持つグループがOSASMグループ(この例では、asmadmin)になるように、ディスク・グループに追加する各ディスクのキャラクタRAWデバイス・ファイルの所有者、グループおよび権限を変更します。

# chown grid:asmadmin /dev/rdsk/cxtydz
# chmod 660 /dev/rdsk/cxtydz

注意:
ASMでマルチ・パス・ディスク・ドライバを使用している場合は、そのディスクに正しい論理デバイス名の権限のみを設定してください。
ノード構成が異なる場合に、特定のデバイスのデバイス名が一部のノードで異なる場合があります。各ノードで正しいデバイス名を指定してください。

6.4.2 Oracle ASMでのOracle Databaseファイルとディスク・グループの使用

次の項で、Oracle ClusterwareおよびOracle DatabaseファイルのためのOracle ASMの記憶域の構成について説明します。

- ASM上の既存のOracle Databaseディスク・グループの指定と使用

- Oracle Databaseデータ・ファイルのためのディスク・グループの作成

6.4.2.1 ASM上の既存のOracle Databaseディスク・グループの指定と使用

次の項では、既存ディスク・グループの指定方法およびそのディスク・グループが持つ空きディスク領域の確認方法について説明します。

- 必要な場合は、Oracle ASMディスク・グループのデバイスに障害グループを指定します。
標準または高冗長ディスク・グループを使用する場合は、カスタム障害グループのディスク・デバイスを関連付けることによって、ハードウェア障害に対するデータベースの保護を強化できます。デフォルトでは、各デバイスに独自の障害グループが含まれます。ただし、標準冗長ディスク・グループの2台のディスク・デバイスが同じSCSIコントローラに接続されている場合、コントローラに障害が発生すると、ディスク・グループは使用できなくなります。この例でのコントローラは、シングル・ポイント障害です。

このタイプの障害を防止するためには、2つのSCSIコントローラを使用します。各コントローラに2台のディスクを接続し、各コントローラに接続されたディスクに障害グループを定義します。この構成では、ディスク・グループが1つのSCSIコントローラの障害を許容できるようになります。

注意:
カスタム障害グループを定義する場合、標準冗長では2つ以上の障害グループ、高冗長では3つ以上の障害グループを指定する必要があります。

6.4.2.2 Oracle Databaseデータ・ファイルのためのディスク・グループの作成

システムに適切なディスク・グループが存在しない場合は、適切なディスク・デバイスを設置または指定して、新しいディスク・グループを追加します。次のガイドラインに従って、適切なディスク・デバイスを指定します。

- Oracle ASMディスク・グループのすべてのデバイスは、サイズおよびパフォーマンス特性が同じである必要があります。

- 単一の物理ディスクにある複数のパーティションを、1つのディスク・グループのデバイスとして指定しないでください。Oracle ASMは、各ディスク・グループのデバイスが、別々の物理ディスク上に存在するとみなします。

6.4.2.3 Oracle ASM資格証明ファイルの作成と使用

Oracle ASMストレージ・クライアントには、ノードで実行中のOracle ASMがなく、他のクライアント・クラスタのOracle ASM記憶域サービスを使用します。

Oracle ASMの資格証明ファイルを作成するには、ストレージ・サーバー上のGrid_home/binディレクトリから、メンバー・ノードの1つで次のコマンドを実行します(credential_fileが、作成するOracle ASM資格証明ファイルの名前とパスです)。

Grid_home/bin/asmcmd mkcc client_cluster_name credential_file

次に例を示します。

Grid_home/bin/asmcmd mkcc clientcluster1 /home/grid/clientcluster1_credentials.xml

クライアント・クラスタのインストールを実行するクライアント・クラスタ・ノード上の安全なパスに、Oracle ASM資格証明ファイルをコピーします。Oracleインストール・ユーザーには、このファイルへのアクセス権限が必要です。他のユーザーにOracle ASM資格証明ファイルへのアクセス権限を付与しないことをお薦めします。インストールの実行中、ファイルへのパスを入力するように求めるメッセージが表示されます。

注意:

- Oracle ASM資格証明ファイルは、1回しか使用できません。Oracle ASMクライアントを構成および構成解除する場合は、新しいOracle ASM資格証明ファイルを作成する必要があります。

- Oracle ASM資格証明ファイルを使用してクライアント・クラスタを構成する場合、それを共有したり他のクライアント・クラスタの構成に再利用したりすることはできません。

関連項目:
ASMCMDクライアントのクラスタ管理コマンドの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

6.4.3 既存のOracle ASMインスタンスのアップグレード

以前のリリースのOracle ASMが、サーバー上または既存のOracle Clusterwareインストール環境内にインストールされている場合は、パスGrid_home/binにあるOracle Automatic Storage Management Configuration Assistant (ASMCA)を使用して、既存のOracle ASMインスタンスを12cリリース1 (12.1)にアップグレードし、その後で障害グループ、Oracle ASMボリュームを構成します。

注意:
既存のOracle ASMインスタンスのアップグレードは、そのノード上のすべてのデータベース・インスタンスおよびアプリケーションを停止してから実行する必要があります。

インストール時に、11.2より前のOracle ASMリリースからアップグレードする際に、Oracle ASMを使用することを選択し、ASMCAによって以前のOracle ASMバージョンが別のOracle ASMホームにインストールされていることが検出された場合は、Oracle ASM 12cリリース1 (12.1)のバイナリをインストールした後に、ASMCAを起動して既存のOracle ASMインスタンスをアップグレードできます。

Oracle ASM 11gリリース2 (11.2.0.1)以上からアップグレードする場合は、Oracle ASMはローリング・アップグレードの一部として常にOracle Grid Infrastructureとともにアップグレードされ、アップグレード中にrootスクリプトによってASMCAが起動されます。以前のリリースから現在のリリースまで、ASMCAがOracle ASMを個別にアップグレードすることはできません。

Oracle ClusterwareまたはOracle RACの既存のインストール環境で、すべてのノード上のOracle ASMインスタンスの旧バージョンが11gリリース1以上の場合は、Oracle ASMインスタンスのローリング・アップグレードを実行できます。Oracle RACのインストール環境で、旧バージョンのOracle ASMインスタンスが11gリリース1よりも前のリリースの場合は、ローリング・アップグレードを実行できません。その場合、すべてのノード上のOracle ASMは12cリリース1 (12.1)にアップグレードされます。

7 クラスタ用Oracle Grid Infrastructureのインストール

この章では、クラスタ用Oracle Grid Infrastructureをインストールする手順について説明します。Oracle Grid Infrastructureは、Oracle ClusterwareおよびOracle Automatic Storage Management(Oracle ASM)で構成されます。後でOracle DatabaseおよびOracle Real Application Clusters(Oracle RAC)をインストールする場合、このフェーズは2つあるインストール・フェーズの1つとなります。

この章の内容は次のとおりです。

- グリッド・インフラストラクチャのインストール

- ソフトウェアのみのインストールを使用したグリッド・インフラストラクチャのインストール

- Oracle Clusterwareの機能の確認

- Oracle Clusterwareファイルを対象とするOracle ASM機能の確認

- Oracle Grid Infrastructureでのオフライン・プロセスの理解

7.1 グリッド・インフラストラクチャのインストール

この項では、インストーラを使用してOracle Grid Infrastructureをインストールする方法について説明します。内容は次のとおりです。

- OUIの実行によるグリッド・インフラストラクチャのインストール

- クラスタ構成ファイルを使用したグリッド・インフラストラクチャのインストール

7.1.1 OUIの実行によるグリッド・インフラストラクチャのインストール

クラスタにOracle Grid Infrastructure(Oracle ClusterwareおよびOracle Automatic Storage Management)をインストールするには、次の手順を実行します。インストール中に、求められている操作に対して疑問がある場合は、OUIページの「ヘルプ」ボタンをクリックします。

1. インストール・メディアか、インストールのバイナリをダウンロードした場所で、runInstallerコマンドを実行します。次に例を示します。

$ cd /home/grid/oracle_sw/
$ ./runInstaller

2. 次のインストール・オプションから1つ選択します。

- クラスタ用のOracle Grid Infrastructureのインストールおよび構成
このオプションは、標準クラスタ、またはハブ・ノードおよびリーフ・ノードを含むOracle Flex Clusterをインストールする場合に選択します。

- スタンドアロン・サーバー用のOracle Grid Infrastructureのインストールおよび構成
このオプションは、Oracle Restart構成にOracle Grid Infrastructureをインストールする場合に選択します。このオプションは、Oracle Databaseおよびその他のアプリケーションをサポートする単一のサーバーに使用します。

関連項目:
スタンドアロン・サーバー・インストールの詳細は、使用しているプラットフォームの『Oracle Databaseインストレーション・ガイド』を参照してください(このインストール・オプションについてはこのドキュメントに記載されていないため)。

- Oracle Grid InfrastructureまたはOracle Automatic Storage Managementのアップグレード
このオプションは、Oracle Grid Infrastructure (Oracle ClusterwareおよびOracle Grid Infrastructure)をアップグレードする場合またはOracle ASM.をアップグレードする場合に選択します。

注意:
必ずOracle Clusterwareの方が新しいリリースである必要があるため、Oracle Clusterwareより新しいリリースにOracle ASMをアップグレードすることはできません。

- Oracle Grid Infrastructureソフトウェアのインストールのみ
このオプションは、GridホームにOracle Grid Infrastructureをインストールし、ソフトウェアを構成しない場合に選択します。

3. インストール画面は、選択したインストール・オプションによって異なります。必要に応じて構成プロンプトに応答し、クラスタを構成します。

注意:
インストール時に送信を要求された情報について質問がある場合は、「ヘルプ」をクリックします。

クラスタ･メンバー･ノードのパブリックおよびVIPネットワーク・アドレスには、構成しているクラスタの種類に応じて必要な情報を指定します。

- GNSを介して構成および解決されるDHCPアドレスによる自動クラスタ構成を使用する場合、指定する必要があるのはDNSで構成されているGNS VIP名のみです。

- DNSで構成および解決される固定IPアドレスによる手動クラスタ構成を使用する場合は、クラスタのSCAN名、各クラスタ・メンバー・ノードのパブリック名およびVIP名(およびオプションでクラスタのGNS VIP)を指定する準備をしておきます。

次に、ノードIPアドレスに関する追加情報を示します。

- ローカル・ノードの場合のみ、OUIによってパブリックおよびVIPフィールドが自動的に書き込まれます。システムでベンダーのクラスタウェアが使用されている場合は、OUIにより追加のフィールドが書き込まれることがあります。

- ホスト名および仮想ホスト名は、ドメイン修飾されません。インストール中にアドレス・フィールドにドメインを入力すると、そのドメインは、OUIによってアドレスから削除されます。

- プライベートIPアドレス用にプライベートとして指定したインタフェースは、パブリック・インタフェースとしてアクセスできないようにする必要があります。キャッシュ・フュージョンにパブリック・インタフェースを使用すると、パフォーマンスの問題が発生する可能性があります。

ハブ・ノードおよびリーフ・ノードのタイプを手動で構成したり、クラスタ内のハブ・ノード数のターゲット・サイズを設定してOracle Grid Infrastructureがクラスタに必要な数のハブ・ノードを自動的に保持できるようにすることができます。

パブリック・ノード名の入力には、各ノードのプライマリ・ホスト名を使用します。この名前は、hostnameコマンドによって表示される名前です。

4. rootスクリプトを自動化するための情報を入力するか、OUIのプロンプトが表示されたらrootとしてスクリプトを実行します。 「詳細」をクリックしてログファイルを確認します。いずれかのノードでroot.shが失敗する場合は、問題を修正してから第9.5項「バイナリを削除せずに行うOracle Clusterwareの構成解除」の手順に従い、そのノードでroot.shを再実行して続行します。
rootスクリプトの実行の自動化を構成し、rootスクリプトが失敗した場合は、問題を手動で修正して「再試行」をクリックし、スクリプトの実行に失敗したノードで再度rootスクリプトを実行できます。

注意:
最初のノードでroot.shスクリプトを実行し、完了するまで待機する必要があります。クラスタに3つ以上のノードが存在する場合は、最初のノードを除くすべてのノードで同時にroot.shを実行することができます。ノード番号は、root.shを実行した順序に従って割り当てられます。特定のノード番号割当てが必要な場合は、rootスクリプトをその順序で実行し、1つのノードでスクリプトが完了するまで待ってから次のノードで実行してください。

5. すべてのノードでroot.shを実行すると、OUIによってNet Configuration Assistant(netca)およびクラスタ検証ユーティリティが起動されます。これらのプログラムはユーザーの介入なしに起動されます。

6. Oracle Automatic Storage Management Configuration Assistant (asmca)によって、インストール中にOracle ASMが構成されます。

7. Oracle Grid Infrastructureのインストール時にroot.shを実行すると、ディレクトリgrid_home/tfaに、トレース・ファイル・アナライザ(TFA)およびコレクタもインストールされます。

関連項目:
トレース・ファイル・アナライザ・コレクタの使用に関する詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

Oracle Grid Infrastructureのインストールが正常に完了したことが検証されると、他のアプリケーションの高可用性を維持するために使用するか、またはOracle Databaseをインストールできます。

次に、インストールに関する追加情報を示します。

Oracle Database 12cリリース1 (12.1)およびOracle RACをインストールする場合は、『Oracle Real Application Clustersインストレーション・ガイドfor Linux and UNIX』を参照してください。

関連項目:
Oracle Grid Infrastructureのクローニングについては『Oracle Clusterware管理およびデプロイメント・ガイド』を、クローニングの使用、およびOracle RACノードを追加するためのノード追加手順については『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

7.1.2 クラスタ構成ファイルを使用したグリッド・インフラストラクチャのインストール

Oracle Grid Infrastructureのインストール時には、クラスタ構成情報を手動で指定するか、クラスタ構成ファイルを使用するかを選択できます。クラスタ構成ファイルはテキスト・ファイルで、OUIを起動する前に作成でき、このファイルによって、クラスタの構成に必要なクラスタ・ノード・アドレスがOUIに提供されます。

テスト・クラスタへのインストールを繰り返し実行する場合、または多数のノードでインストールを実行する場合は、クラスタ構成ファイルの使用をお薦めします。

クラスタ構成ファイルを手動で作成するには、テキスト・エディタを起動し、各クラスタ・メンバー・ノードのパブリックIPアドレスと仮想IPアドレスの名前を提供するファイルを次の形式で作成します。

node1 node1-vip /node-role
node2 node2-vip /node-role
.
.
.

node-roleには、値としてHUBまたはLEAFを指定できます。

次に例を示します。

mynode1 mynode1-vip /HUB
mynode2 mynode2-vip /LEAF

7.2 ソフトウェアのみのインストールを使用したグリッド・インフラストラクチャのインストール

この項の内容は次のとおりです。

- ソフトウェア・バイナリのインストール

- ソフトウェア・バイナリの構成

- レスポンス・ファイルを使用したソフトウェア・バイナリの構成

注意:
ソフトウェアのみのインストールにはOracle Grid Infrastructureソフトウェアを有効にするための手動のインストール後の手順が必要なため、上級ユーザーのみが実行することをお薦めします。

ソフトウェアのみのインストールでは、1つのノードでクラスタ用Oracle Grid Infrastructureをインストールします。

インストール時に「Grid Infrastructureソフトウェアのインストールのみ」オプションを使用すると、ローカル・ノードにソフトウェア・バイナリがインストールされます。クラスタ用のインストールを完了するには、追加の手順として、Oracle ClusterwareおよびOracle ASMの構成、ローカル・インストールのクローンの作成、他のノードでのこのクローンのデプロイ、クラスタへの他のノードの追加を行う必要があります。

参照:
Oracle Grid Infrastructureインストールを他のノードにクローニングして、クラスタに追加する方法については、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

7.2.1 ソフトウェア・バイナリのインストール

ソフトウェアのみのインストールを行うには、次の手順を実行します。

1. Oracle Database 12cリリース1 (12.1)のインストール・メディアの該当ディレクトリからrunInstallerコマンドを実行します。次に例を示します。

$ cd /home/grid/oracle_sw
$ ./runInstaller

2. 最初のノードで、Oracle Grid Infrastructureのソフトウェアのみのインストールを完了します。

3. ソフトウェアがインストールされたら、プロンプトに従ってorainstRoot.shスクリプトを実行します。

4. root.shスクリプトの出力は、このインストールで完了しようとする構成内容に基づいて、どのように処理を進めるかについての情報を提供します。この情報を書き留めます。
ただし、Oracle Grid Infrastructureをスタンドアロン・サーバー(Oracle Restart)にインストールしない場合は、roothas.plスクリプトを実行する指示は無視してください。

5. runcluvfy.sh stage -pre crsinst -n node_listコマンドを使用して、すべてのクラスタ・ノードがインストール要件を満たしていることを検証します。すべての記憶域およびサーバーのインストール前要件が満たされていることを確認してください。

6. 手順1から4の説明に従って、Oracle Universal Installerを使用して、クラスタに含める残りのすべてのノードでOracle Grid Infrastructureソフトウェアをインストールします。そして、すべてのノードでOracle Grid Infrastructureのソフトウェアのみのインストールを完了します。

7. 第7.2.2項「ソフトウェア・バイナリの構成」で説明されているとおり、完全なOUI構成ウィザードGUIを使用してクラスタを構成するか、または第7.2.3項「レスポンス・ファイルを使用したソフトウェア・バイナリの構成」の項で説明されているとおり、レスポンス・ファイルを使用してクラスタを構成します。

7.2.2 ソフトウェア・バイナリの構成

GUIモードでOracle Grid Infrastructure構成ウィザードを開始して、ソフトウェア・バイナリを構成します。

1. グリッド・インフラストラクチャ・インストール所有者として端末にログインし、grid_home/crs/configに移動します。

2. 次のコマンドを入力します。

$ ./config.sh

構成スクリプトによってOUIが構成ウィザード・モードで起動します。必要に応じて構成情報を指定します。各ページには同じユーザー・インタフェースが表示され、OUIが通常実行するのと同じ妥当性チェックが実行されます。ただし、インストールを実行するのではなく、構成ウィザード・モードで入力が検証され、すべてのクラスタ・ノードでインストールが構成されます。

3. 入力を完了すると、OUIにより「サマリー」ページが表示され、クラスタに指定したすべての入力がリストされます。サマリーにクラスタの正しい情報が表示されていることを確認し、「インストール」をクリックしてローカル・ノードの構成を開始します。
ローカル・ノードの構成が完了すると、OUIによりOracle Grid Infrastructure構成ファイルが他のクラスタ・メンバー・ノードにコピーされます。

4. プロンプトが表示されたら、rootスクリプトを実行します。

5. すべてのrootスクリプトが実行されたことを確認すると、OUIによってクラスタの構成ステータスが確認され、必要に応じてその他の構成ツールが起動されます。

7.2.3 レスポンス・ファイルを使用したソフトウェア・バイナリの構成

ソフトウェアをどのノードにインストールまたはコピーする場合でも、構成を後で行うことができます。この項では、構成ウィザード・ユーティリティ(config.sh)を使用して、ノードにソフトウェアをインストールまたはコピーした後で構成を行う手順について説明します。

参照:
構成ウィザードの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

レスポンス・ファイルを使用してOracle Grid Infrastructureソフトウェア・バイナリを構成するには、次の手順を実行します。

1. Oracle Grid Infrastructureインストール所有者(grid)として、次の構文を使用して、Oracle Grid InfrastructureソフトウェアのみのホームからOracle Grid Infrastructure構成ウィザード・モードでOUIを起動します(Grid_homeはOracle Grid Infrastructureホームで、filenameはレスポンス・ファイル名)。
Grid_home/crs/config/config.sh [-debug] [-silent -responseFile filename]

次に例を示します。

$ cd /u01/app/12.1.0/grid/crs/config/
$ ./config.sh -responseFile /u01/app/grid/response/response_file.rsp

構成スクリプトによってOUIが構成ウィザード・モードで起動します。各ページには同じユーザー・インタフェースが表示され、OUIが通常実行するのと同じ妥当性チェックが実行されます。ただし、インストールを実行するのではなく、構成ウィザード・モードで入力が検証され、すべてのクラスタ・ノードでインストールが構成されます。

2. 入力を完了すると、OUIにより「サマリー」ページが表示され、クラスタに指定したすべての入力がリストされます。サマリーにクラスタの正しい情報が表示されていることを確認し、「インストール」をクリックしてローカル・ノードの構成を開始します。
ローカル・ノードの構成が完了すると、OUIによりOracle Grid Infrastructure構成ファイルが他のクラスタ・メンバー・ノードにコピーされます。

3. プロンプトが表示されたら、rootスクリプトを実行します。

4. すべてのrootスクリプトが実行されたことを確認すると、OUIによってクラスタの構成ステータスが確認され、必要に応じてその他の構成ツールが起動されます。

7.2.4 ネットワーク・チェックのためのpingターゲットの設定

ネットワーク・ケーブルを取り外したときにネットワーク・リンクのステータスが正しく返されない環境、たとえば仮想マシンでは、次のようにインストーラを使用して、Oracle Grid InfrastructureのインストールにPing_Targetsパラメータを設定することによって、ネットワーク・ステータスに関する通知を受け取ることができます。

./runInstaller oracle_install_crs_Ping_Targets=Host1/IP1,Host2/IP2

pingユーティリティは、ホスト名またはIPアドレスのカンマ区切りリストHost1/IP1,Host2/IP2に接続し、パブリック・ネットワークが使用できるかどうかを判定します。そのいずれも応答しない場合、ネットワークはオフラインであるとみなされます。スイッチまたはルーターのように、クラスタ外のアドレスを使用してください。

次に例を示します。

./runInstaller oracle_install_crs_Ping_Targets=192.0.2.1,192.0.2.2

7.3 Oracle Clusterwareの機能の確認

インストール後にrootとしてログインし、各ノードで次のコマンド構文を使用して、Oracle Clusterwareインストールが適切にインストールされ、動作していることを確認します。

crsctl check cluster

次に例を示します。

$ crsctl check cluster

CRS-4537 Cluster Ready Services is onlineCRS-4529 Cluster Synchronization Services is onlineCRS-4533 Event Manager is online

注意:
インストールが完了したら、Oracle Clusterwareの動作中は/tmp/.oracleまたは/var/tmp/.oracle、あるいはそのファイルを手動で削除したり、それらを削除するcronジョブを実行しないでください。これらのファイルを削除すると、Oracle Clusterwareが断続的にハングアップする可能性があり、エラーCRS-0184「CRSデーモンと通信できません。」が発生します。

7.4 Oracle Clusterwareファイルを対象とするOracle ASM機能の確認

OCRおよび投票ディスク・ファイルをOracle ASMにインストールした場合、Oracle Grid Infrastructureインストール所有者として次のコマンド構文を使用し、Oracle ASMインストールが実行されていることを確認します。

srvctl status asm

次に例を示します。

$ srvctl status asm
ASM is running on node1,node2

Oracle ASMは、Oracle Clusterwareファイルに必要な場合のみ、実行されています。OCRおよび投票ディスク・ファイルをOracle ASMにインストールしなかった場合、Oracle ASMインスタンスは停止しています。

注意:
Oracle ASMまたはOracle Net 11gリリース2(11.2)以上のインストールを管理するには、クラスタ用Oracle Grid Infrastructureホーム(Gridホーム)のsrvctlバイナリを使用します。Oracle Real Application ClustersまたはOracle Databaseがインストールされている場合は、データベース・ホームのsrvctlバイナリを使用してOracle ASMまたはOracle Netを管理することはできません。

7.5 Oracle Grid Infrastructureでのオフライン・プロセスの理解

Oracle Grid Infrastructureでは、様々なOracle製品およびコンポーネントに必要なリソースが提供されます。一部の製品およびコンポーネントはオプションのため、Oracle Grid Infrastructureのインストール後にインストールして有効にできます。インストール後の追加を簡単にするため、Oracle Grid Infrastructureでは、これらの製品およびコンポーネントで使用可能なすべての製品に必要なすべてのリソースが構成および登録されます。ただし、アクティブ化するのはそれらを追加することを選択した場合のみです。そのため、一部のコンポーネントは、Oracle Grid Infrastructureのインストール後はOFFLINEとして表示される場合があります。

TARGET:OFFLINEおよびSTATE:OFFLINEとして表示されるリソースを監視する必要はありません。登録済でも有効でないコンポーネントであるため、システム・リソースは使用されません。Oracle製品またはコンポーネントがシステムにインストールされていて、オンラインにする特定のリソースが必要な場合は、必要なオフライン・リソースのアクティブ化を求めるプロンプトが表示されます。

8 Oracle Grid Infrastructureのインストール後の手順

この章では、Oracle Grid Infrastructureソフトウェアをインストールした後に実行する、インストール後の作業について説明します。

この章の内容は次のとおりです。

- インストール後に必要な作業

- インストール後の推奨作業

- Oracle Grid Infrastructureでの以前リリースのOracle Databaseの使用

- インストール後のOracle Clusterwareバイナリの変更

8.1 インストール後に必要な作業

パッチの更新をダウンロードしてインストールします。My Oracle Support Webサイトを参照して、インストールした環境に必要なパッチの更新を確認します。

注意:
My Oracle Supportを利用するには、ブラウザにAdobe Flashプラグインのバージョン9.0.115以上が必要です。Adobe Flashのチェッカ・ページに移動して、ご使用のブラウザでFlashプラグインの正確なバージョンをチェックし、最新バージョンのAdobe Flashがインストールされていることを確認します。
Flashをインストールしていない場合は、次のAdobe Webサイトから最新バージョンのFlash Playerをダウンロードします。

http://www.adobe.com/go/getflashplayer

必要なパッチの更新をダウンロードするには、次の手順を実行します。

1. Webブラウザを使用して、My Oracle Support Webサイトを表示します。
https://support.oracle.com

2. My Oracle Support Webサイトにログインします。

注意:
My Oracle Supportの登録ユーザーでない場合は、「My Oracle Supportへの登録」をクリックして登録してください。

3. My Oracle Supportのメイン・ページで「パッチと更新版」をクリックします。

4. 「Patches & Update」ページで「Advanced Search」をクリックします。

5. 「Advanced Search」ページで「Product or Product Family」フィールドの横にある検索アイコンをクリックします。

6. 「検索と選択: 製品ファミリ」フィールドで「検索」リスト・フィールドの「データベースとツール」を選択し、テキスト・フィールドにRDBMS Serverと入力して「検索」をクリックします。
RDBMSサーバーが「Product or Product Family」フィールドに表示されます。現行のリリースが「Release」フィールドに表示されます。

7. 「Platform」フィールドのリストからプラットフォームを選択して、選択リストの下の「Go」をクリックします。

8. 「結果」ヘッダーの下に使用可能なパッチの更新が表示されます。

9. パッチ番号をクリックして、パッチをダウンロードします。

10. 「パッチ・セット」ページで「READMEの表示」をクリックして、表示されるページを読みます。  READMEページには、そのパッチ・セットに関する情報と、パッチの適用方法が記載されています。

11. 「パッチ・セット」ページに戻って「ダウンロード」をクリックし、ファイルをシステムに保存します。

12. Oracle Database 12cリリース1 (12.1)で提供されたunzipユーティリティを使用して、My Oracle SupportからダウンロードしたOracleのパッチ更新を解凍します。unzipユーティリティは$ORACLE_HOME/binディレクトリにあります。

13. パッチをインストールする準備としてデータベース・プロセスを停止する方法の詳細は、付録B「Oracle Grid Infrastructure 12cリリース1へのアップグレード方法」を参照してください。

8.2 インストール後の推奨作業

Oracle Grid Infrastructureをインストールした後で、必要に応じて次の作業を行うことをお薦めします。

- Crsctlを使用したIPMIベースの障害分離の構成

- セマフォ・パラメータの調整

- 高速リカバリ領域ディスク・グループの作成

- SCAN構成の確認

- Oracle RAC構成監査ツールの実行

- Oracle Clusterwareおよび関連するデータベースやアプリケーションに対するリソース制限の設定

8.2.1 crsctlを使用したIPMIベース障害分離の構成

HP-UXプラットフォームでは、現在ネイティブIPMIドライバはサポートされていないため、DHCPアドレッシングはサポートされていません。IPMIをサポートするには手動での構成が必要です。OUIでは管理者資格証明が収集されないため、BMCは静的IPアドレスを使用して構成する必要があります。また、アドレスは手動でOLRに格納する必要があります。

IPMIを使用して障害分離を構成するには、各クラスタ・メンバー・ノードで次の手順を実行する必要があります。

1. 必要に応じて、次のコマンドを使用してOracle Clusterwareを起動します。

$ crsctl start crs

2. BMC管理ユーティリティを使用してBMCのIPアドレスを取得してから、クラスタ制御ユーティリティcrsctlを使用してcrsctl set css ipmiaddr addressコマンドを発行し、BMCのIPアドレスをOracle Local Registry(OLR)に格納します。次に例を示します。

$ crsctl set css ipmiaddr 192.168.10.45

3. 次のcrsctlコマンドを入力して、常駐BMCのユーザーIDおよびパスワードをOLRに格納します。nonameユーザーはIPMI管理者ユーザー・アカウントで、プロンプトが表示されたらパスワードを指定します。

$ crsctl set css ipmiadmin ""
IPMI BMC Password:

このコマンドによって、ユーザーが入力した資格証明が別のクラスタ・ノードに送信され、この資格証明の検証が行われます。クラスタ・ノードが資格証明を使用してローカルのBMCにアクセスできない場合、コマンドは失敗します。

IPMI資格証明をOLRに格納する場合は、明示的に指定した匿名ユーザーが必要です。ない場合は、解析エラーがレポートされます。

8.2.2 セマフォ・パラメータの調整

デフォルトのセマフォ・パラメータ値が低すぎて、すべてのOracleプロセスに対応できない場合のみ、次のガイドラインを参照してください。

注意:
セマフォ・パラメータの設定方法の詳細は、オペレーティング・システムのドキュメントを参照することをお薦めします。

1. 次の計算式を使用して、全体的な最小セマフォ要件を計算します。
2 * sum(システム上のすべてのデータベース・インスタンスのプロセス・パラメータ) + バックグラウンド・プロセスのオーバーヘッド + システムおよび他のアプリケーションの要件

2. semmns(システム全体のセマフォ合計)を、この合計値に設定します。

3. semmsl(各セットのセマフォ)を、250に設定します。

4. semmnsをsemmslで割り、最も近い1024の倍数に切り上げた値を、semmni(セマフォ・セット合計)として設定します。

8.2.3 高速リカバリ領域ディスク・グループの作成

インストール時、デフォルトでは1つのディスク・グループの作成が可能です。スタンドアロン・サーバー用のOracle Database、またはOracle RACデータベースを追加しようとする場合は、データベース・ファイルの高速リカバリ領域を作成する必要があります。

8.2.3.1 高速リカバリ領域および高速リカバリ領域ディスク・グループについて

高速リカバリ領域は、リカバリに関連するすべてのOracle Databaseファイルのための、統合された記憶域の場所です。データベース管理者は、DB_RECOVERY_FILE_DESTパラメータを高速リカバリ領域のパスに定義することで、ディスク上へのバックアップやデータの迅速なリカバリが可能になります。最近のデータを迅速にバックアップできれば、リカバリ作業のためにバックアップ・テープを探さなければならないシステム管理者の負担を軽減できます。

init.oraファイルで高速リカバリを有効にすると、すべてのRMANバックアップ、アーカイブ・ログ、制御ファイルの自動バックアップ、およびデータベースのコピーが高速リカバリ領域に書き込まれます。RMANは、リカバリに必要でなくなった古いバックアップおよびアーカイブ・ファイルを削除することで、高速リカバリ領域のファイルを自動的に管理します。

高速リカバリ領域ディスク・グループを作成することをお薦めします。Oracle ClusterwareファイルとOracle Databaseファイルは同じディスク・グループに配置できます。また、高速リカバリ・ファイルも同じディスク・グループに入れることができます。ただし、ストレージ・デバイスの競合を緩和するため、高速リカバリ・ディスク・グループを別に作成することをお薦めします。

高速リカバリ領域は、DB_RECOVERY_FILE_DESTを設定することで有効にできます。高速リカバリ領域のサイズは、DB_RECOVERY_FILE_DEST_SIZEで設定します。一般的に、高速リカバリ領域は大きいほど使いやすくなります。使い勝手を良くするため、少なくとも3日分のリカバリ情報を格納できるストレージ・デバイスに、高速リカバリ領域ディスク・グループを作成することをお薦めします。理想的には、高速リカバリ領域は、保存ポリシーに基づいて保存されたデータ・ファイルのバックアップを使用してデータベースをリカバリする際に必要な、すべてのデータ・ファイルと制御ファイル、オンラインREDOログ、およびアーカイブREDOログ・ファイルのコピーを格納できるサイズであることが求められます。

複数のデータベースに同じ高速リカバリ領域を使用できます。たとえば、150GBの記憶域を持つディスク上に1つの高速リカバリ領域ディスク・グループを作成し、それを3つの異なるデータベースで共有するとします。各データベースの高速リカバリ領域のサイズを、そのデータベースの重要度によって設定することができます。たとえば、データベース1が最も重要度が低く、データベース2がそれよりも重要度が高く、データベース3が最も重要度が高い場合、各データベースに異なるDB_RECOVERY_FILE_DEST_SIZE設定を適用し、それぞれの保存目標を満たすようにします。たとえば、データベース1には30GB、データベース2には50GB、データベース3には70GBのように設定します。

関連項目:
『Oracle Databaseストレージ管理者ガイド』

8.2.3.2 高速リカバリ領域ディスク・グループの作成

高速リカバリ・ファイル・ディスク・グループを作成するには、次の手順を実行します。

1. グリッド・ホームのbinディレクトリに移動し、Oracle ASM Configuration Assistant(asmca)を起動します。次に例を示します。

$ cd /u01/app/12.1.0/grid/bin
$ ./asmca

2. ASMCAが開き、「ディスク・グループ」タブが表示されます。新しいディスク・グループを作成するには、「作成」をクリックします。

3. 「ディスク・グループの作成」ウィンドウが開きます。
「ディスク・グループ名」フィールドに、高速リカバリ領域グループの説明的な名前を入力します。たとえば、FRAです。

「冗長性」セクションで、適用する冗長レベルを選択します。

「メンバー・ディスクの選択」フィールドで、高速リカバリ領域に追加する適切なディスクを選択し、「OK」をクリックします。

4. 「ディスク・グループの作成」ウィンドウが開き、ディスク・グループの作成が完了したというメッセージが表示されます。「OK」をクリックします。

5. 「終了」をクリックします。

8.2.4 SCAN構成の確認

単一クライアント・アクセス名(SCAN)は、クラスタへのサービス・アクセスをクライアントに提供するために使用される名前です。SCANは、特定のノードではなくクラスタ全体に関連付けされているため、クライアントの再構成を必要とせずに、クラスタでノードを追加または削除することを可能にします。また、データベースに場所の独立性がもたらされるため、クライアント構成は特定のデータベース・インスタンスがどのノードで実行されているかに依存しません。クライアントは引き続き、以前のリリースと同じ方法でクラスタにアクセスできますが、クラスタにアクセスするクライアントではSCANの使用をお薦めします。

DNSによってSCANが正しくアドレスに関連付けられていることを確認するには、(Gridホーム/binにある)コマンドcluvfy comp scanを使用します。次に例を示します。

$ cluvfy comp scan

Verifying scan

Checking Single Client Access Name (SCAN)...

Checking TCP connectivity to SCAN Listeners...
TCP connectivity to SCAN Listeners exists on all cluster nodes

Checking name resolution setup for ”node1.example.com”...

Verification of SCAN VIP and Listener setup passed

Verification of scan was successful.

インストール後、クライアントがクラスタにリクエストを送信すると、Oracle ClusterwareのSCANリスナーはクライアント・リクエストをクラスタのサーバーにリダイレクトします。

関連項目:
システム・チェックおよび構成については、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

8.2.5 Oracle RAC構成監査ツールの実行

Oracle RAC構成監査ツール(ORAchk)を実行して、Oracle RACインストールを確認することをお薦めします。ORAchkは、Oracle Real Application Clusters、Oracle Clusterware、Oracle Automatic Storage ManagementおよびOracle Grid Infrastructure環境の様々な重要な構成設定の確認を行うOracle RACの監査ツールです。

ORAchkユーティリティの構成および実行の詳細は、次のURLにあるMy Oracle SupportのNote 1268927.1を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1268927.1

8.2.6 Oracle Clusterwareと関連するデータベースおよびアプリケーションのリソース制限の設定

Oracle Grid Infrastructureのインストールの終了後、Grid_home/crs/install/s_crsconfig_nodename_env.txtファイルにリソース制限を設定できます。これらのリソース制限は、すべてのOracle ClusterwareプロセスおよびOracle Clusterwareで管理されるOracle Databaseに適用されます。たとえば、より多くの数のプロセス制限を設定するには、このファイルを編集してCRS_LIMIT_NPROCパラメータに高い値を設定します。

8.3 Oracle Grid Infrastructureでの以前のOracle Databaseリリースの使用

次の項で、Oracle Grid Infrastructure 12cリリース1 (12.1)インストールで前のリリースのOracle Databaseを使用する場合について説明します。

- 前のバージョンのOracle Databaseの使用に関する一般的な制限

- 以前のデータベース・バージョンによるサーバー・プールの管理

- ASMCAを使用した前のバージョンのデータベースのディスク・グループの管理

- Oracle Databaseリリース10.xまたは11.x用のクラスタ・ノードの固定

- 適切なLSNRCTLコマンドの使用

8.3.1 前のバージョンのOracle Databaseの使用に関する一般的な制限

Oracle Database 10gリリース2およびOracle Database 11gリリース1および2は、Oracle Clusterware 12cリリース1 (12.1)で使用できます。

srvctl、lsnrctlまたは他のOracle Grid Infrastructureホーム・ツールのバージョンを、以前のバージョンのデータベースを管理するために使用しないでください。以前のOracle Databaseリリースは、以前のOracle Databaseホームにあるツールのみを使用して管理します。以前のリリースのデータベースに対応する正しいツールのバージョンを使用するには、管理対象のデータベースまたはオブジェクトのOracleホームからツールを実行します。

既存バージョンのOracle ClusterwareとOracle ASMをOracle Grid Infrastructure 11g以上(Oracle ClusterwareとOracle ASMを含む)にアップグレードする場合で、Oracle RACデータベースを12cリリース1 (12.1)にアップグレードする計画もある場合は、Oracle RACのアップグレードが完了したときに、既存のデータベースに必要な構成も自動的に完了するため、この項の説明を読む必要はありません。

注意:
Oracle Database 11g リリース1 (11.1.0.7または11.1.0.6)またはOracle Database 10gリリース2 (10.2.0.4)からアップグレードする場合は、Oracle Clusterware 12cリリース1 (12.1) インストールへのOracle RACまたはOracle Databaseのインストールを始める前に、アップグレード元のリリースに推奨される最新のパッチを確認し、必要に応じて既存のデータベース・インストールに適用してから、アップグレードすることをお薦めします。
推奨パッチの詳細は、「Oracle 12c Upgrade Companion」(My Oracle Support Note 1462240.1)を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1462240.1

8.3.2 以前のデータベース・バージョンによるサーバー・プールの管理

Oracle Grid Infrastructure 12cから、Oracle Databaseサーバーのカテゴリに、HubおよびLeafという、以前のリリースにはなかったロールが含まれるようになりました。このため、Oracle RAC 11 gバージョンのDatabase Configuration Assistant (DBCA)を使用してサーバー・プールを作成することはできません。以前のリリースのOracle RACインストールに対応するサーバー・プールを作成するには、次の手順を使用します。

1. Oracle Grid Infrastructureインストール所有者(Gridユーザー)としてログインします。

2. ディレクトリをGridホーム内の12.1 Oracle Grid Infrastructureバイナリのディレクトリに変更します。次に例を示します。

# cd /u01/app/12.1.0/grid/bin

3. Oracle Grid Infrastructure 12cバージョンのsrvctlを使用し、ハブ・ノードのロールで構成されるサーバー・プールを作成します。たとえば、最大サイズのクラスタ・ノードを1つ使用して、p_hubというサーバー・プールを作成するには、次のコマンドを入力します。

srvctl add serverpool -serverpool p_hub -min 0 -max 1 -category hub;

4. Oracle RACインストール所有者としてログインし、Oracle RACのOracleホームからDBCAを起動します。次に例を示します。

$ cd /u01/app/oracle/product/11.2.0/dbhome_1/bin
$ dbca

DBCAは、Oracle Grid Infrastructure 12 cのsrvctlコマンドで作成したサーバー・プールを検出します。使用するサービスに対して、必要に応じてサーバー・プールを構成します。

関連項目:
ポリシーを使用してリソースを管理する方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

8.3.3 ASMCAを使用した前のバージョンのデータベースのディスク・グループの管理

前のリリースのOracle DatabaseおよびOracle RACデータベースをOracle Grid Infrastructureにインストールするときに、Oracle ASM Configuration Assistant (ASMCA)を使用して、ディスク・グループを作成および変更します。Oracle Database 11gリリース2 (11.2)以上では、Oracle ASMはOracle ClusterwareとともにOracle Grid Infrastructureインストールの一部としてインストールされます。Database Configuration Assistant(DBCA)を使用してOracle ASMで管理タスクを実行することはできなくなりました。

関連項目:
Oracle Database 11g以下のソフトウェアをOracle Grid Infrastructure 12c (12.1)とともに使用した、データベースに対するディスク・グループの互換性の構成に関する詳細は、『Oracle Database Storage管理者ガイド』を参照してください。

8.3.4 Oracle Databaseリリース10.xまたは11.x用のクラスタ・ノードの固定

旧バージョンのOracleソフトウェアがインストールされていないクラスタにOracle Clusterware 12cリリース1 (12.1)をインストールすると、Oracle Databaseリリース11.2以上と互換性のあるクラスタ・ノードが動的に構成されます。ただし、Oracle Database 10gおよび11.1では、永続構成が必要です。ノード名とノード番号を関連付けるこの手順を固定と呼びます。

注意:
アップグレード中、すべてのクラスタ・メンバー・ノードには自動的に固定されるため、既存のデータベースに対して手動で固定する必要はありません。この手順は、Oracle Grid Infrastructure 12cリリース1 (12.1)ソフトウェアをインストールした後に、以前のバージョンのデータベースをインストールする場合にのみ必要です。

前のバージョンのOracle Databaseをインストールして使用するための準備でノードを固定するには、Grid_home/bin/crsctlを使用して次のコマンド構文を実行します。nodesは、構成を固定するクラスタ内の1つまたは複数のノードを示す、スペース区切りリストです。

crsctl pin css -n nodes

たとえば、ノードnode3およびnode4を固定するには、rootとしてログインし、次のコマンドを入力します。

$ crsctl pin css -n node3 node4

ノードが固定状態か非固定状態かを確認するには、Grid_home/bin/olsnodesを使用して次のコマンド構文を実行します。

固定されたすべてのノードを表示する場合:

olsnodes -t -n

次に例を示します。

# /u01/app/12.1.0/grid/bin/olsnodes -t -n
node1 1       Pinned
node2 2       Pinned
node3 3       Pinned
node4 4       Pinned

特定のノードの状態を表示する場合:

olsnodes -t -n node3

次に例を示します。

# /u01/app/12.1.0/grid/bin/olsnodes -t -n node3
node3 3       Pinned

関連項目:
ノードの固定および固定解除の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

8.3.5 適切なLSNRCTLコマンドの使用

lsnrctlコマンドを使用してローカル・リスナーおよびSCANリスナーを管理するには、環境変数$ORACLE_HOMEにOracle Grid Infrastructureホーム(Gridホーム)のパスを設定します。以前のリリースで使用していたOracleホームの位置からlsnrctlコマンドを使用しないでください。この位置は新しいリリースでは使用できません。

8.4 インストール後のOracle Clusterwareバイナリの変更

インストール後にOracle Clusterware構成の変更が必要になった場合は、グリッド・ホームをロック解除する必要があります。

たとえば、個別パッチを適用する場合や、Oracle Exadata構成を変更して、デフォルトのUDPを使用するかわりにインターコネクト上でRDS経由のIPCトラフィックを実行する場合は、Gridホームのロック解除が必要になります。

注意:
実行可能ファイルを再リンクする前に、Oracleホーム・ディレクトリで実行されている、ロック解除および再リンク対象の実行可能ファイルをすべて停止する必要があります。また、Oracle共有ライブラリにリンクされているアプリケーションも停止してください。

次の手順に従って、ホームをロック解除します。

1. rootとしてログインし、パスGrid_home/crs/install(Grid_homeはGridホームのパス)に移動し、コマンドrootcrs.sh -unlock -crshome Grid_home(Grid_homeは使用しているGrid Infrastructureホームのパス)を使用して、Gridホームをロック解除します。たとえば、Gridホームが/u01/app/12.1.0/gridの場合、次のコマンドを入力します。

# cd /u01/app/12.1.0/grid/crs/install
# perl rootcrs.sh -unlock -crshome /u01/app/12.1.0/grid

2. ユーザーをOracle Grid Infrastructureソフトウェア所有者に変更し、コマンド構文make -f Grid_home/rdbms/lib/ins_rdbms.mk targetを使用してバイナリを再リンクします(ここで、Grid_homeはGridホーム、targetは再リンクするバイナリです)。たとえばGridユーザーがgridで、$ORACLE_HOMEがGridホームに設定されている場合、インターコネクト・プロトコルをUDPからIPCに更新するには、次のコマンドを入力します。

# su grid
$ make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk ipc_rds ioracle

注意:
バイナリを再リンクする場合、Oracle Grid Infrastructureのインストール所有者に変更して、コマンドGrid_home/bin/relinkを実行することも可能です。

3. 次のコマンドを使用して、Gridホームを再度ロックし、クラスタを再起動します。

# perl rootcrs.sh -patch

4. 各クラスタ・メンバー・ノードで、手順1から3を繰り返します。

注意:
Gridホームのディレクトリは削除しないでください。たとえば、Grid_home/Opatchディレクトリを削除しないでください。このディレクトリを削除すると、グリッド・インフラストラクチャ・インストール所有者はOpatchを使用してGridホームにパッチを適用できず、Opatchによって「checkdirエラー: Grid_home/OPatchを作成できません」というエラー・メッセージが表示されます。

9 Oracle Grid Infrastructureを変更または削除する方法

この章では、Oracle ClusterwareとOracle ASMの削除方法について説明します。

Oracle Database 11gリリース2(11.2)以降では、削除ツールを使用して、Oracle Database、Oracle Clusterware、Oracle ASM、Oracle RACまたはOracle Databaseクライアントのインストールに関連付けられているOracleホーム全体を削除することをお薦めします。個々の製品またはコンポーネントの削除はサポートされていません。

この章の内容は次のとおりです。

- Oracle Clusterwareを削除するタイミングの決定

- クラスタへのスタンドアロン・グリッド・インフラストラクチャ・サーバーの移行

- クラスタ用Oracle Grid Infrastructureのバイナリの再リンク

- Oracle Grid Infrastructureホーム・パスの変更

- バイナリを削除せずに行うOracle Clusterwareの構成解除

- Oracle ClusterwareとASMの削除

関連項目:
個々の製品を削除する場合は、要件および制限について製品固有のドキュメントを参照してください。

9.1 Oracle Clusterwareを削除するタイミングの決定

次のような場合に、インストールされたコンポーネントを削除します。

- 学習環境またはテスト環境のいずれかで、Oracle Clusterwareを正常にインストールした後、Oracle Clusterwareインストールを削除する必要がある場合。

- Oracle Clusterwareのインストールまたはアップグレード中、またはその後にエラーが発生し、インストールを再試行する場合。

- ハードウェア障害またはオペレーティング・システム障害のため、インストールまたはアップグレードが停止した場合。

- Oracle Clusterwareを再インストールするようにOracleサポート・サービスからアドバイスされた場合。

9.2 クラスタへのスタンドアロン・グリッド・インフラストラクチャ・サーバーの移行

Oracle Restart(スタンドアロン・サーバー用のOracle Grid Infrastructureインストール)を使用するOracle Databaseインストールがあり、そのサーバーをクラスタ・メンバー・ノードとして構成する場合は、次の作業を行います。

関連項目:
構成ウィザードの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

1. 次の構文でsrvctlを使用してOracle Restartの構成を調べます(ここで、db_unique_nameはデータベースの一意の名前で、lsnrnameはリスナー名です)。
srvctl config database -db db_unique_name

srvctl config service -db db_unique_name

srvctl config listener -listener lsnrname

サーバーの構成情報を書き留めます。

2. rootとしてログインし、Grid home/crs/installディレクトリに移動します。次に例を示します。

# cd /u01/app/12.1.0/grid/crs/install

3. 手順1で調べたすべてのデータベース、サービスおよびリスナーを停止します。

4. 次のコマンドを使用して、スタンドアロン・サーバー(Oracle Restart)に対するOracle Grid Infrastructureインストールの構成を解除します。

# roothas.sh -deconfig -force

5. このマニュアルの説明に従って、Oracle Clusterware構成のためにサーバーを準備します。また、クラスタ用Oracle Grid InfrastructureをOracle Restartと同じ場所にインストールするか、別の場所にインストールするかを選択します。
Oracle Restartと同じ場所にインストールする場合

1. 削除ツールを使用してOracle Restartソフトウェアを削除しますが、すべてのディスク・グループはそのまま保持します。

2. 手順6に進みます。

Oracle Restartと異なる場所にインストールする場合

1. クラスタ用Oracle Grid Infrastructureを新しいGridホーム・ソフトウェアの場所にインストールします。

6. Oracle Grid Infrastructureインストール所有者として、Oracle Clusterware構成ウィザードを実行し、レスポンス・ファイルを保存してステージングします。次に例を示します。

$ Grid_home/crs/config/config.sh -silent -responseFile $HOME/GI.rsp

7. Oracle Clusterware構成ウィザードでroot.shを実行します。

8. Oracle Restartディスク・グループをマウントします。

9. volenableコマンドを実行し、すべてのOracle Restartディスク・グループ・ボリュームを有効にします。

10. 手順1で記録した情報を使用して、Oracle ClusterwareサービスをOracle Clusterwareホームに戻します。次に例を示します。

/u01/app/grid/product/11.2.0/grid/bin/srvctl add filesystem -device
/dev/asm/db1  -diskgroup ORestartData -volume db1 -mountpointpath
/u01/app/grid/product/11.2.0/db1 -user grid

11. 手順1で記録した構成情報を使用して、クラスタ用Oracle Grid InfrastructureでサポートされるようにOracle Databaseを追加します。次のコマンド構文を使用します(db_unique_nameはノード上のデータベースの一意の名前、nodenameはノードの名前)。
srvctl add database -db db_unique_name -oraclehome $ORACLE_HOME -node nodename

たとえば、最初にORACLE_HOME環境変数にデータベース・ホーム・ディレクトリの場所が設定されていることを確認します。

次に、データベース名mydb、サービスmyserviceを追加する場合は、次のコマンドを入力します。

srvctl add database -db mydb -oraclehome $ORACLE_HOME -node node1

12. srvctl add serviceコマンドを使用して、各サービスをデータベースに追加します。次に例を示します。

srvctl add service -db mydb -service myservice

9.3 クラスタ用Oracle Grid Infrastructureのバイナリの再リンク

クラスタ用Oracle Grid Infrastructure(クラスタ用に構成されたOracle ClusterwareとOracle ASM)をインストールした後、バイナリを変更する必要がある場合は、次の手順を実行します。Grid_homeはクラスタ用Oracle Grid Infrastructureホームです。

注意:
実行可能ファイルを再リンクする前に、Oracleホーム・ディレクトリで実行されている、再リンク対象の実行可能ファイルをすべて停止する必要があります。また、Oracle共有ライブラリにリンクされているアプリケーションも停止してください。

rootで次のコマンドを実行します。

# cd Grid_home/crs/install
# perl rootcrs.sh -unlock

クラスタ用Oracle Grid Infrastructure所有者で次のコマンドを実行します。

$ export ORACLE_HOME=Grid_home
$ Grid_home/bin/relink

再度rootで次のコマンドを入力します。

# cd Grid_home/rdbms/install/
# ./rootadd_rdbms.sh
# cd Grid_home/crs/install
# perl rootcrs.sh -patch

オペレーティング・システムのパッチを適用したときやオペレーティング・システムのアップグレードをした後は毎回、Oracle ClusterwareとOracle ASMのバイナリを再リンクする必要があります。

以前のリリースからアップグレードする場合に、以前のリリースのGridホームを削除するには、まず以前のリリースのGridホームをロック解除する必要があります。以前のリリースのホームからコマンドrootcrs.sh -unlockを実行し、以前のリリースのGridホームをロック解除します。スクリプトが完了したら、削除ツールを実行できます。

9.4 Oracle Grid Infrastructureホーム・パスの変更

クラスタ用Oracle Grid Infrastructure(クラスタ用に構成されているOracle ClusterwareおよびOracle ASM)をインストールした後、Gridホームのパスを変更する必要がある場合は、次の例に従って、既存のGridホームでデタッチして、新しいGridホームをアタッチします。

注意:
Gridホームを変更する前に、再リンクしているGridホーム・ディレクトリで実行されるすべての実行可能ファイルを停止する必要があります。また、Oracle共有ライブラリにリンクされているアプリケーションも停止してください。

1. Oracle Grid Infrastructureインストール所有者(grid)としてログインします。

2. ディレクトリをGrid_home/binに移動し、コマンドcrsctl stop crsを入力します。次に例を示します。

$ cd /u01/app/12.1.0/grid/bin
$ ./crsctl stop crs

3. 次のコマンドを実行し、既存のGridホームをデタッチします。/u01/app/12.1.0/gridは既存のGridホームの場所です。

$ /u01/app/12.1.0/grid/oui/bin/runInstaller -silent -waitforcompletion\
-detachHome ORACLE_HOME='/u01/app/12.1.0/grid' -local

4. rootとして、古いGridホームの場所から新しいGridホームの場所にグリッド・バイナリを移動します。たとえば、古いGridホームが/u01/app/12.1.0/gridで、新しいGridホームが/u01/app/12c/の場合は次のようにします。

# mkdir /u01/app/12c
# mv /u01/app/12.1.0/grid /u01/app/12c

5. 『Oracle Clusterware管理およびデプロイメント・ガイド』の説明に従ってOracle Grid Infrastructureインストールをクローニングします。
Grid home/clone/binディレクトリに移動してclone.plスクリプトを実行するときに、新しいGridホームにパス情報を提供する入力パラメータに値を指定します。

6. 再度rootで次のコマンドを入力し、新しいホームの場所で起動します。

# cd /u01/app/12c/crs/install
# perl rootcrs.sh -patch -dstcrshome /u01/app/12c/

7. 各クラスタ・メンバー・ノードで、手順1から4を繰り返します。

Gridホームを移動するたびに、Oracle ClusterwareとOracle ASMのバイナリを再リンクする必要があります。

9.5 バイナリを削除せずに行うOracle Clusterwareの構成解除

rootcrs.shコマンドにフラグ-deconfig -forceを指定して実行すると、インストール済のバイナリを削除しなくても、1つ以上のノードでOracle Clusterwareを構成解除できます。この機能は、あるノードでオペレーティング・システム・パッケージの欠落など、インストール時にroot.shコマンドを実行する際、1つ以上のクラスタ・ノードでエラーが発生した場合に役立ちます。インストール・エラーが発生するノードでrootcrs.sh -deconfig -forceを実行することによって、それらのノードでOracle Clusterwareを構成解除し、エラーの原因を修正した後、再度root.shを実行できます。

注意:
Oracle Clusterwareを構成解除する前に、インストールおよび実行されている可能性のあるデータベース、サービスおよびリスナーを停止してください。

注意:
この項で使用するコマンドでは、クラスタ全体のOracle Grid Infrastructureインストールが削除されます。個々のノードからインストールを削除する場合は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

Oracle Clusterwareの構成を解除するには、次の手順を実行します。

1. エラーが発生したノードでrootユーザーとしてログインします。

2. Grid_home/crs/installディレクトリに移動します。次に例を示します。

# cd /u01/app/12.1.0/grid/crs/install

3. -deconfigおよび-forceフラグを指定してrootcrs.shを実行します。次に例を示します。

# perl rootcrs.sh -deconfig -force

必要に応じて他のノードで繰り返します。

4. クラスタ内のすべてのノードでOracle Clusterwareを構成解除する場合は、最後のノードで次のコマンドを入力します。

# perl rootcrs.sh -deconfig -force -lastnode

-lastnodeフラグを指定すると、OCRおよび投票ディスクを含む、クラスタの構成解除が完了します。

注意:
ハブ・ノードでrootcrs.sh -deconfig -force -lastnodeコマンドを実行します。-lastnodeフラグでコマンドを実行する前に、すべてのリーフ・ノードの構成を解除します。

9.6 Oracle ClusterwareとASMの削除

deinstallコマンドによって、Oracle ClusterwareおよびOracle ASMをサーバーから削除できます。次の項では、このコマンドと、それを使用するための追加オプションについて説明します。

- 削除ツールについて

- Oracle Grid Infrastructureの削除ツールのコマンドの例

- クラスタ用グリッド・インフラストラクチャの削除レスポンス・ファイルの例

注意:
Oracleソフトウェアを削除するには、同じリリースの削除ツールを使用する必要があります。以前のリリースのOracleソフトウェアを削除するとき、それより新しいリリースの削除ツールは使用しないでください。たとえば、既存の11.2.0.4OracleホームにあるOracleソフトウェアを削除するとき、12.1.0.1のインストール・メディアに収録されている削除ツールは実行しないでください。

9.6.1 削除ツールについて

Oracle Database 12cから、削除ツールはデータベース・インストール・メディアに統合されています。Oracle Database、Oracle DatabaseクライアントまたはOracle Grid Infrastructureインストール・メディアのベース・ディレクトリから、runInstallerコマンドに-deinstallオプションと-homeオプションを使用して削除ツールを実行できます。

削除ツールは、インストール後のOracleホーム・ディレクトリにある別のコマンド(deinstall)でも実行できます。削除ツールの場所は、$ORACLE_HOME/deinstallディレクトリです。

削除ツールのコマンドでは、指定した情報と、ソフトウェア・ホームから収集した情報を使用して、レスポンス・ファイルを作成します。このファイルのかわりに、以前のdeinstallコマンドで生成されたレスポンス・ファイルを指定するには、–checkonlyオプションを使用するか、レスポンス・ファイル・テンプレートを編集します。

削除ツールによって、Oracleソフトウェアが停止され、特定のOracleホームのOracleソフトウェアおよびオペレーティング・システムの構成ファイルが削除されます。削除ツールを実行してOracle Grid Infrastructureを削除する場合、rootユーザーとしてrootcrs.shスクリプトを実行してOracle Grid Infrastructureを構成解除するか、またはroothas.shスクリプトを実行してスタンドアロン・サーバー用のOracle Grid Infrastructureを構成解除します。

注意:
Oracle Database 12c リリース1 (12.1.0.2)以上では、Oracle Grid Infrastructureホームのroothas.plスクリプトはroothas.shスクリプトに置き換わりました。

Oracleホームのソフトウェアが実行されていない場合(インストール失敗の後など)、削除ツールは構成を確認できないため、対話的に、またはレスポンス・ファイルですべての構成の詳細を提供する必要があります。

注意:
削除ツールを実行すると、構成解除して削除するホーム以外に、中央インベントリ(oraInventory)に他の登録済ホームが含まれていない場合、削除ツールはOracle Databaseインストール所有者のOracleベース・ディレクトリで次のファイルおよびディレクトリの内容を削除します。

- admin

- cfgtoollogs

- checkpoints

- diag

- oradata

- flash_recovery_area

Optimal Flexible Architecture(OFA)構成を使用してインストールを構成し、Oracleソフトウェアが排他的に使用するために、OracleベースとOracleホーム・パスを予約しておくことをお薦めします。Oracleソフトウェアを所有するユーザー・アカウントによって所有されるOracleベース内のこれらの場所に、ユーザーのデータがある場合、このデータは削除ツールによって削除されます。

また、Oracle Grid Infrastructureインストールの場合:

- グリッド・ネーミング・サービス(GNS)が使用中の場合、サブドメインのエントリはDNS管理者によってDNSから削除される必要があります。

削除ツールは、デフォルトでは、インストール所有者としてOracleホームのdeinstallディレクトリから実行します。

$ $ORACLE_HOME/deinstall/deinstall

deinstallコマンドでは、次の構文を使用します。変数はイタリックで示しています。

deinstall [-silent] [-checkonly] [-local] [-paramfile complete path of input response file]
[-params name1=value name2=value . . .] [-o complete path of directory for saving files] [-help]

データベースのインストール・メディアから削除ツールを実行するには、runInstallerコマンドに-deinstallオプションと、その後に-homeオプションを使用し、次の構文を使用して、削除したいOracleホームのパスを指定します(変数の内容はイタリック)。

runInstaller -deinstall -home complete path of Oracle home [-silent] [-checkonly] [-local] [-paramfile complete path of input response file] [-params name1=value
name2=value . . .] [-o complete path of directory for saving files] [-help]

サーバーに関する情報の入力を求められたら、情報を入力するかデフォルトを受け入れます。

削除ツールは、Oracleソフトウェアを停止し、オペレーティング・システム上のOracleソフトウェアおよび構成ファイルを削除します。

また、削除ツールは、レスポンス・ファイルを使用して実行するか、次のオプションを選択して実行することができます。

- -home
このフラグは、確認または削除するOracleホームのホーム・パスを指定します。

$ORACLE_HOME/deinstallパスからdeinstallを実行する場合は、実行されているホームの場所をツールで特定できるため、-homeフラグは不要です。インストール・メディアからrunInstaller -deinstallを使用する場合、-homeは必須です。

削除しようとしているOracleホームでdeinstallコマンドを使用してOracleソフトウェアを削除する場合は、Oracle以外の場所にパラメータ・ファイルを用意し、-homeフラグは使用しないでください。

- -silent
このフラグは、非対話型モードで削除ツールを実行します。

- インストールと構成情報を確認するためにアクセスできる動作中のシステム。-silentフラグを使用すると、障害が発生したインストールは処理されません。

- 削除または構成解除するOracleホームの構成値が記述されたレスポンス・ファイル

使用または変更するレスポンス・ファイルは、ツールに-checkonlyフラグを指定して実行すると生成できます。ツールにより、削除および構成解除するOracleホームの情報が検出されます。これによって、次に-silentフラグで使用できるレスポンス・ファイルが生成されます。-silentフラグを使用すると、障害が発生したインストールは処理されません。

- -checkonly
このフラグを指定すると、Oracleソフトウェアのホーム構成の状態が確認されます。-checkonlyフラグを指定してdeinstallコマンドを実行した場合、Oracleの構成は削除されません。-checkonlyフラグにより、deinstallコマンドと-silentオプションで使用できるレスポンス・ファイルが生成されます。

- -local
このフラグは、複数ノード環境でクラスタ内のOracleソフトウェアを削除する場合に使用します。

このフラグを指定してdeinstallを実行すると、ローカル・ノード(deinstallが実行されたノード)のOracleソフトウェアの構成が解除され、Oracleソフトウェアが削除されます。リモート・ノードのOracleソフトウェアの削除または構成解除は行われません。

- -paramfile 入力レスポンス・ファイルの完全パス
このフラグを指定すると、デフォルト以外の場所にあるレスポンス・ファイルを使用してdeinstallが実行されます。このフラグを使用するときは、レスポンス・ファイルがある完全パスを指定します。

レスポンス・ファイルのデフォルトの位置は、deinstallの位置によって異なります。

- インストール・メディアまたはステージの場所からの場合: stagelocation/response
stagelocationは、インストール・メディアまたはステージ・ファイルの場所にあるベース・ディレクトリのパスです。

- インストール済Oracleホームからの場合(インストール後): $ORACLE_HOME/deinstall/response

- -params [name1=value name2=value name3=value . . .]
このフラグは、パラメータ・ファイルとともに使用して、以前作成したレスポンス・ファイルで変更する1つ以上の値を上書きします。

- -o 保存するレスポンス・ファイルのディレクトリの完全パス
このフラグを指定すると、デフォルト以外の場所に、レスポンス・ファイル(deinstall.rsp.tmpl)を保存するパスが指定されます。

レスポンス・ファイルのデフォルトの位置は、deinstallの位置によって異なります。

- インストール・メディアまたはステージの場所からの場合: stagelocation/response
stagelocationは、インストール・メディアまたはステージ・ファイルの場所にあるベース・ディレクトリのパスです。

- インストール済Oracleホームからの場合(インストール後): $ORACLE_HOME/deinstall/response

- -help
ヘルプ・オプション(-help)を指定すると、削除ツールのオプション・フラグに関する追加情報を取得できます。

9.6.1.1 以前のリリースのGridホームの削除

以前のリリースからアップグレードする場合に、以前のリリースのGridホームを削除するには、rootユーザーとして以前のリリースのGridホームの権限を手動で変更し、削除ツールを実行する必要があります。

次に例を示します。

# chown -R grid:oinstall /u01/app/grid/11.2.0
# chmod -R 775 /u01/app/grid/11.2.0

この例では、/u01/app/grid/11.2.0が以前のリリースのGridホームです。

9.6.2 Oracle Grid Infrastructureの削除ツールのコマンドの例

$ORACLE_HOME/deinstallフォルダから削除ツールを使用して削除ツールを実行すると、ORACLE_HOMEに対するプロンプトは表示されずに削除が開始されます。

レスポンス・ファイルにパスを指定するには、オプション・フラグ-paramfileを使用します。

下記の例で、runInstallerコマンドは、パス/directory_pathにあり、directory_pathは、インストール・メディアのdatabaseディレクトリへのパスで、/u01/app/12.1.0/grid/は削除するGridホームへのパスです。

$ cd /directory_path/
$ ./runInstaller -deinstall -home /u01/app/12.1.0/grid

次の例では、ソフトウェア所有者の場所/home/usr/gridにあるレスポンス・ファイルを使用します。

$ cd /directory_path/runInstaller
$ ./runInstaller -deinstall -paramfile /home/usr/grid/my_db_paramfile.tmpl

9.6.3 クラスタ用グリッド・インフラストラクチャの削除レスポンス・ファイルの例

削除ツールに-paramfileオプションを指定して実行すると、レスポンス・ファイルに指定した値を使用することができます。ノードnode1およびnode2のクラスタ用のレスポンス・ファイルの例を次に示します(この例では、クラスタ用Oracle Grid Infrastructureソフトウェアのバイナリ所有者はgrid、Oracle Grid Infrastructureホーム(Gridホーム)はパス/u01/app/12.1.0/gridにあり、Oracleベース(Oracle ASMログ・ファイルやOracle Clusterwareログなどの管理ファイルが格納されたOracle Grid InfrastructureのOracleベース)は/u01/app/grid/、中央Oracle Inventoryホーム(oraInventory)は/u01/app/oraInventory、仮想IPアドレス(VIP)は192.0.2.2と192.0.2.4、ローカル・ノード(削除セッションを実行しているノード)はnode1です)。

#Copyright (c) 2005, 2006 Oracle Corporation.  All rights reserved.
#Fri Feb 06 00:08:58 PST 2009
LOCAL_NODE=node1
HOME_TYPE=CRS
ASM_REDUNDANCY=\
ORACLE_BASE=/u01/app/12.1.0/grid/
VIP1_MASK=255.255.252.0
VOTING_DISKS=/u02/storage/grid/vdsk
SCAN_PORT=1522
silent=true
ASM_UPGRADE=false
ORA_CRS_HOME=/u01/app/12.1.0/grid
GPNPCONFIGDIR=$ORACLE_HOME
LOGDIR=/home/grid/SH/deinstall/logs/
GPNPGCONFIGDIR=$ORACLE_HOME
ORACLE_OWNER=grid
NODELIST=node1,node2
CRS_STORAGE_OPTION=2
NETWORKS="eth0"/192.0.2.1\:public,"lan1"/10.0.0.1\:cluster_interconnect
VIP1_IP=192.0.2.2
NETCFGJAR_NAME=netcfg.jar
ORA_DBA_GROUP=dba
CLUSTER_NODES=node1,node2
JREDIR=/u01/app/12.1.0/grid/jdk/jre
VIP1_IF=eth0
REMOTE_NODES=node2
VIP2_MASK=255.255.252.0
ORA_ASM_GROUP=asm
LANGUAGE_ID=AMERICAN_AMERICA.WE8ISO8859P1
CSS_LEASEDURATION=400
NODE_NAME_LIST=node1,node2
SCAN_NAME=node1scn
SHAREJAR_NAME=share.jar
HELPJAR_NAME=help4.jar
SILENT=false
local=false
INVENTORY_LOCATION=/u01/app/oraInventory
GNS_CONF=false
JEWTJAR_NAME=jewt4.jar
OCR_LOCATIONS=/u02/storage/grid/ocr
EMBASEJAR_NAME=oemlt.jar
ORACLE_HOME=/u01/app/12.1.0/grid
CRS_HOME=true
VIP2_IP=192.0.2.4
ASM_IN_HOME=n
EWTJAR_NAME=ewt3.jar
HOST_NAME_LIST=node1,node2
JLIBDIR=/u01/app/12.1.0/grid/jlib
VIP2_IF=eth0
VNDR_CLUSTER=false
CRS_NODEVIPS='node1-vip/255.255.252.0/eth0,node2-vip/255.255.252.0/eth0'
CLUSTER_NAME=node1-cluster

注意:
次の場合を除いて、変数に引用符を使用しないでください。

- CRS_NODEVIPSのアドレスの前後:

CRS_NODEVIPS='n1-vip/255.255.252.0/lan0,n2-vip/255.255.252.0/eth0'

- NETWORKSのインタフェース名の前後:

NETWORKS="eth0"/192.0.2.1:public,"lan1"/10.0.0.1:cluster_interconnect "eth2"/192.0.2.2:vip1_ip

A Oracle Grid Infrastructureのインストール・プロセスに関するトラブルシューティング

この付録では、Oracle Grid Infrastructureのインストールに関するトラブルシューティング情報について説明します。

関連項目:
ドキュメント・ディレクトリに含まれるOracle Database 12cリリース1 (12.1) Oracle RACのドキュメントを参照してください。

- 『Oracle Clusterware管理およびデプロイメント・ガイド』

- 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

この付録の内容は次のとおりです。

- Oracleサポートに連絡する際のベスト・プラクティス

- 一般的なインストールの問題

- 詳細モードによるCVUの「不明」出力メッセージの解釈

- Oracle Grid Infrastructureの設定に関するCVUメッセージの解釈

- Oracle Grid Infrastructureアラート・ログについて

- Oracle Grid Infrastructureのインストール中のクラスタ診断の実行

- インストール後のCVUのクラスタ・ヘルス・チェックの使用について

- インターコネクト構成の問題

- SCAN VIPおよびSCANリスナーの問題

- ストレージ構成の問題

- 失敗したまたは不完全なインストールおよびアップグレード

- 失敗または中断されたインストールおよびアップグレードの完了

A.1 Oracleサポートに連絡する際のベスト・プラクティス

Oracleサポートに連絡して問題を報告する必要がある場合は、サービス・リクエストを入力するときに次のガイドラインに従うことをお薦めします。

- 問題の明確な説明(正確なエラー・メッセージを含む)を提供します。

- 問題のトラブルシューティングを行うために実行した手順と、この手順の結果の説明を提供します。

- 影響を受けたソフトウェアの正確なバージョン(メジャー・リリースとパッチ・リリース)を提供します。

- Oracleサポートが問題を再現できるように、問題が発生したときに実行した処置の段階ごとの手順を提供します。

- 問題の影響の評価(影響を受けた最終期限およびコストを含む)を提供します。

- スクリーンショット、ログ、Remote Diagnostic Agent (RDA)出力などの関連情報を提供します。

A.2 一般的なインストールの問題

次に、インストール中に発生する可能性のある様々なエラーの例を示します。内容は次のとおりです。

- root.shが途中で異常終了し、「リソース'ora.cluster_interconnect.haip'の起動に失敗しました」などのエラー・メッセージが表示される

- ディスクの取得中にエラーが発生する

- CRS-5823: エージェント・フレームワークを初期化できない

- サーバーに接続できない(サーバーによって接続を拒否されたか、または表示を開くことができない)

- ocrconfigを初期化できない

- INS-32026 INSTALL_COMMON_HINT_DATABASE_LOCATION_ERROR

- OUIのノードの選択画面で選択可能なノードがない

- ノードnodenameに到達できない

- PROT-8: 指定したファイルからクラスタ・レジストリにデータをインポートできない

- PRVE-0038: SSH LoginGraceTime設定(致命的: 認証前にタイムアウトした)

- タイムスタンプが未来である

- CRSスタックの開始を待機していてタイムアウトした

- その他のインストールの問題とエラー

root.shが途中で異常終了し、「リソース'ora.cluster_interconnect.haip'の起動に失敗しました」などのエラー・メッセージが表示される

原因: Oracle RAC用のパブリックおよびプライベートのネットワーク・インタフェースを構成するときは、ARPを有効にする必要があります。高可用性IP (HAIP)アドレスはパブリック・ネットワーク上のARPを必要としませんが、VIPフェイルオーバーを行うにはARPの有効化が必要になります。NOARPを構成しないでください。

処置: hsi0 (またはeth)デバイスがARPプロトコルを使用するように、次のコマンドを実行して構成します。

# ifconfig lan(n) arp

ディスクの取得中にエラーが発生する

原因: 存在しないOracleホームを指しているエントリが/etc/oratabにあります。OUIのログ・ファイルには、エラーが「java.io.IOException: /home/oracle/OraHome//bin/kfod: 見つかりませんでした」のように出力されます。

処置: 存在しないOracleホームを指しているエントリを/etc/oratabから削除してください。

/usr/X11R6/bin/xdpyinfoコマンドを使用して表示色の自動チェックを実行できない

原因: DISPLAY変数が設定されていないか、インストールを実行しているユーザーにX Windowを開く権限がありません。これは、リモート端末からインストールを実行している場合や、ディスプレイ上でX Windowを開く権限のあるユーザーからX Windowを開く権限のないユーザー・アカウントへsuコマンドを使用して変更している場合(rootユーザーのコンソール・ディスプレイで低い権限のユーザーがウィンドウを開いている場合など)に起こります。

処置: echo $DISPLAYコマンドを使用して、環境変数に正しいディスプレイ、つまり正しいホストが設定されていることを確認してください。DISPLAY変数が正しく設定されていたら、X Windowを開く権限のあるユーザーでログインしていることを確認するか、またはxhost +コマンドを実行してすべてのユーザーにX Windowを開く許可を与えてください。
サーバー・コンソール上でrootとしてローカルでログインし、su -コマンドを使用してOracle Grid Infrastructureのインストール所有者に変更した場合は、サーバーからログアウトし、Gridのインストール所有者としてログインしなおしてください。

CRS-5823: エージェント・フレームワークを初期化できない

原因: root.shを実行したとき、Oracle Grid Infrastructureのインストールが失敗しました。ローカル・ホスト・エントリがhostsファイルから欠落しているため、Oracle Grid Infrastructureは起動に失敗しました。
Oracle Grid Infrastructureのalert.logファイルには、次のように示されます。

[/oracle/app/grid/bin/orarootagent.bin(11392)]CRS-5823:Could not initialize
agent framework. Details at (:CRSAGF00120:) in
/oracle/app/grid/log/node01/agent/crsd/orarootagent_root/orarootagent_root.log
2010-10-04 12:46:25.857
[ohasd(2401)]CRS-2765:Resource 'ora.crsd' has failed on server 'node01'.

crsdOUT.logファイルを確認し、次を見つけることで、これが原因であることを検証できます。

Unable to resolve address for localhost:2016
ONS runtime exiting
Fatal error: eONS: eonsapi.c: Aug 6 2009 02:53:02

処置: hostsファイルにローカル・ホスト・エントリを追加します。

サーバーに接続できない(サーバーによって接続を拒否されたか、または表示を開くことができない)

原因: これらは、xhostが適切に構成されていない場合か、Xサーバーを起動するためにstartxコマンドで使用したアカウントとは異なるユーザー・アカウントで実行している場合の、WindowsまたはUNIXシステムに特有のX Window表示エラーです。

処置: ローカル端末ウィンドウで、X Windowセッションを開始したユーザーとしてログインし、次のコマンドを入力してください。
$ xhost fullyqualifiedRemoteHostname

次に例を示します。

$ xhost somehost.example.com

その後、次のコマンドを入力してください。workstationnameはワークステーションのホスト名またはIPアドレスです。

Bourne、BashまたはKornシェル:

$ DISPLAY=workstation_name:0.0
$ export DISPLAY

X Windowアプリケーションがローカル・システムで適切に表示されるかどうかを確認するには、次のコマンドを入力します。

$ xclock

モニターにXクロックが表示されます。xclockを使用できない場合、これをシステムにインストールし、テストを繰り返します。xclockがシステムにインストールされているにもかかわらず、ディスプレイ上にXクロックを表示できない場合、xhostコマンドの使用は制限される可能性があります。

VNCクライアントを使用してサーバーにアクセスしている場合は、インストールに使用しようとしているユーザーに割り当てられているビジュアルにアクセスしていることを確認します。たとえば、suコマンドを使用して、別のユーザー・ビジュアルでインストール所有者になった場合、xhostコマンドの使用は制限され、xhostコマンドを使用して表示を変更することはできません。インストール所有者に割り当てられたビジュアルを使用すると、正しく表示でき、xclockコマンドの入力によってxclockがディスプレイに表示されます。

Xクロックが表示されたら、Xクロックを閉じてインストーラを再度起動します。

ocrconfigを初期化できない

原因: /etc/fstabファイル内のNFS用に構成されたオプションが間違っています。
これを確認するには、Grid_home/log/nodenumber/clientパスにあるocrconfig.logファイルをチェックし、次の行を検索します。

/u02/app/crs/clusterregistry, ret -1, errno 75, os err string Value too large
for defined data type
2007-10-30 11:23:52.101: [ OCROSD][3085960896]utopen:6'': OCR location

処置: NFSにマウントされたファイル・システムの場合は、NFSマウントの正しいマウント構成を/etc/fstabファイル内で指定します。次に例を示します。

rw,sync,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768,actimeo=0

注意:
マウントの指定にnetdevやvers=2を含めないでください。netdevオプションを必要とするのは、OCFSファイル・システムを対象とした場合のみです。また、vers=2を指定すると、カーネルによって強制的にNFSがマウントされます。この場合、古いバージョン2のプロトコルが使用されます。

NFSマウント情報を修正した後にNFSマウント・ポイントを再マウントし、root.shスクリプトを再度実行します。たとえば、マウント・ポイント/u02の場合は次のようになります。

#umount /u02
#mount -a -t nfs
#cd $GRID_HOME
#sh root.sh

INS-32026 INSTALL_COMMON_HINT_DATABASE_LOCATION_ERROR

原因: クラスタ用のインストールでGridホームに選択した場所が、Oracleベース・ディレクトリの下にあります。

処置: クラスタ用Oracle Grid Infrastructureのインストールでは、Gridホームを、Oracleベース・ディレクトリ、Oracle Databaseインストール所有者のOracleホーム・ディレクトリ、インストール所有者のホーム・ディレクトリのいずれの下にも配置しないでください。インストール中に、Gridホームへのパスの所有権がrootに変更されます。この変更により、他のインストールで権限エラーが発生します。また、Oracle Clusterwareソフトウェア・スタックも、Oracleベース・パスの下に配置しないでください。

CLSRSC-444: ノードのOUIセッションでroot.shコマンドを実行します

原因: このメッセージが表示され、OUIを実行していないノードがリストされる場合、root.shスクリプトの実行が完了する間または前に、示されたノードシャットダウンされた可能性があります。

処置: クラスタの他のすべてのメンバー・ノードでroot.shスクリプトの実行を完了させ、エラー・メッセージに示されたノードではrootスクリプトを実行しないようにします。Oracle Grid Infrastructureが計画しているクラスタ・メンバー・ノードのセットですべてまたは一部完了したら、OUIを起動し、エラーに示されているノードで、失敗したOracle Grid Infrastructureのインストールをアンインストールします。そのノードから失敗したインストールをアンインストール後、そのノードを手動でクラスタに追加します。

関連項目:
ノードを追加する方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

OUIのノードの選択画面で選択可能なノードがない

原因: Oracle Grid Infrastructureがインストールされていないか、またはOracle Grid Infrastructureサービスが起動および実行されていません。

処置: Oracle Grid Infrastructureをインストールするか、またはOracle Grid Infrastructureインストールの状態を確認してください。また、ノードを再起動すると問題を解決できる場合があります。

ノードnodenameに到達できない

原因: IPホストが使用不可能です。

処置: 次の手順を実行してください。

1. シェル・コマンドnetstat -inを実行します。このコマンドの出力と/etc/hostsファイルの内容を比較して、ノードIPがリストされていることを確認します。

2. シェル・コマンドnslookupを実行して、ホストが到達可能であるかどうかを確認します。

3. oracleユーザーとして、sshまたはrshを使用してノードへの接続を試行します。パスワードを求められた場合、ユーザー等価関係が正しく設定されていません。インストーラによってSSHが構成されます。自動SSH構成が使用できない場合は、付録Eにある「すべてのクラスタ・ノードでの手動によるSSHの構成」を確認してください。

PROT-8: 指定したファイルからクラスタ・レジストリにデータをインポートできない

原因: 既存のOracle Cluster Registryデバイスのパーティションに十分な領域がないため、rootupgradeの実行中に移行障害が発生します。確認するには、ログ・ファイルGrid_home/log/hostname/client/ocrconfig_pid.logでエラー「utopen:12:Not enough space in the backing store」を検索してください。

処置: 280MB以上の使用可能な領域があるストレージ・デバイスを指定します。/var/opt/oracle/srvConfig.locで既存のRAWデバイス名を確認し、コマンドddを使用して、このRAWデバイスの内容を新しいデバイスにコピーしてください。

PRVE-0038: SSH LoginGraceTime設定(致命的: 認証前にタイムアウトした)

原因: PRVE-0038: ノードnodenameのSSH LoginGraceTime設定では、ユーザーがログイン完了前に切断される可能性があります。このエラーは、SSH接続のデフォルトのタイムアウト値が低すぎるか、LoginGraceTimeパラメータがコメント・アウトされているために発生します。

処置: OpenSSH構成ファイルopt/ssh/etc/sshd_configのLoginGraceTimeパラメータのコメントを解除し、値に0(無制限)を設定することをお薦めします。

タイムスタンプが未来である

原因: 1つ以上のノードの時計の時刻がローカル・ノードと異なっています。このような場合には、次のような出力が表示される場合があります。

time stamp 2005-04-04 14:49:49 is 106 s in the future

処置: クラスタ内のすべてのメンバー・ノードの時計を同じ時刻にしてください。

CRSスタックの起動の待機中にタイムアウトした

原因: 構成の問題によってOracle Grid Infrastructureソフトウェアをすべてのノードに正常にインストールできない場合は、CRSスタックの起動の待機中にタイムアウトしたことを示すエラー・メッセージが表示される場合があります。または、インストーラを終了した後、Oracle Grid Infrastructureで管理するリソースが一部のノードで作成されなかったことに気がつく場合があります。リソースのステータスがONLINE以外であることに気がつく場合もあります。

処置: バイナリを削除せずにOracle Grid Infrastructureインストールの構成を解除し、構成の問題の原因を判断するためにログ・ファイルを確認します。構成の問題を修正した後、インストール時にOracle Grid Infrastructureの構成に使用したスクリプトを再実行します。

関連項目:
第9.5項「バイナリを削除せずに行うOracle Clusterwareの構成解除」

YPBINDPROC_DOMAIN: ドメインがバインドされない

原因: このエラーは、インストール後のテスト時に、ノードのパブリック・ネットワーク・インターコネクトが取り外され、VIPによるフェイルオーバーが行われない場合に発生する可能性があります。このエラーでは、ノードがハングし、ユーザーはシステムにログインできなくなります。このエラーは、Oracleホーム、listener.ora、Oracleログ・ファイルまたはアクション・スクリプトがNASデバイスまたはNFSマウントに格納されていて、ネーム・サービス・キャッシュ・デーモンnscdがアクティブになっていない場合に発生します。

処置: Oracle ClusterwareがNASデバイスまたはNFSマウントの使用によるネットワーク障害をより許容できるようにするには、ネーム・サービス・キャッシュ・デーモン(nscd)を有効にします。nscdは、ほとんどの共通ネーム・サービス要求に対するキャッシング・メカニズムを提供します。システムがマルチユーザーの状態で起動すると、自動的に起動します。Oracleソフトウェアでは、サーバーがマルチユーザー実行レベル(3)で起動される必要があります。これはHP-UXのデフォルトです。サーバーが3に設定されていることを確認するには、コマンドwho -rを入力します。次に例を示します。

# who -r
. run-level 3 Jan 4 14:04 3 0 S

関連項目:
3.13項「実行レベルおよびネーム・サービス・キャッシュ・デーモンの確認」

A.2.1 その他のインストールの問題およびエラー

エラー・メッセージの解決でさらに支援が必要な場合は、My Oracle Supportを参照してください。たとえば、Doc ID 1367631.1のNoteには、Oracle Grid InfrastructureおよびOracle Clusterwareの最も一般的なインストールの問題の一部が含まれています。

A.3 詳細モードによるCVUの「不明」出力メッセージの解釈

-verbose引数を使用してクラスタ検証ユーティリティを実行し、特定のノードに対するクラスタ検証ユーティリティ・コマンドの結果がUNKNOWNになる場合、その原因は、検証時に問題が検出されたかどうかをクラスタ検証ユーティリティで判断できないことにあります。結果が「不明」になる場合の、考えられる原因を次に示します。

- ノードが停止している。

- クラスタ検証ユーティリティで必要な、オペレーティング・システムの共通コマンド・バイナリが、Oracle Grid Infrastructureホームの/binディレクトリまたはOracleホーム・ディレクトリで不足している。

- クラスタ検証ユーティリティを起動したユーザー・アカウントには、ノードでオペレーティング・システムの共通コマンドを実行する権限がない。

- ノードで、オペレーティング・システム・パッチ、または必須パッケージが不足している。

- ノードの最大プロセス数または最大オープン・ファイル数を超えているか、共有メモリー、セマフォなど、IPCセグメントに問題が発生している。

A.4 Oracle Grid Infrastructureの設定に関するCVUメッセージの解釈

Oracle Grid Infrastructureをインストールするための要件をシステムが満たしていないことがクラスタ検証ユーティリティのレポートに示された場合は、この項の説明に従ってレポートに示されている問題を解決し、クラスタ検証ユーティリティを再実行します。

- 「ユーザーのユーザー等価チェックが失敗しました。」

- 「ノードからのノード到達可能性チェックが失敗しました。」または「ノード接続性チェックが失敗しました。」

- 「ユーザーの存在チェックが失敗しました。」または「ユーザーとグループの関係チェックが失敗しました」

「ユーザーのユーザー等価チェックが失敗しました。」

原因: すべてのノード間でユーザー等価関係の設定に失敗しました。必要なユーザーが作成されていないか、またはセキュア・シェル(SSH)構成が適切に完了していないことが原因である可能性があります。

処置: クラスタ検証ユーティリティによって、ユーザー等価関係の設定に失敗したノードのリストが表示されます。
失敗したノードと示されている各ノードに対して、ユーザー構成およびSSH構成が正常に完了していることをインストール所有者のユーザー構成で確認してください。Oracle Grid Infrastructureのインストールを実行するユーザーには、SSH接続を作成する権限が必要です。

SSHの構成は、OUIのSSH構成オプションで行うことをお薦めします。手動でSSHの構成を行う場合はインストール前に、インストールのためにSSHが構成済の場合はインストール後に、クラスタ検証ユーティリティを使用できます。

たとえば、ユーザー・アカウントoracleのユーザー等価関係を確認するには、su - oracleコマンドを使用し、dateコマンド引数を指定したsshコマンドを次の構文を使用してローカル・ノードで実行し、ユーザー等価関係を手動で確認します。

$ ssh nodename date

このコマンドによって、nodenameに指定した値で指定されたリモート・ノードのタイムスタンプが出力されます。パスワードを求められた場合、SSHの構成を行う必要があります。デフォルトの場所(/usr/binディレクトリ)にsshがある場合は、sshを使用してユーザー等価関係を構成します。ユーザー等価関係は、rshを使用しても確認できます。

SSHを使用してdateコマンドを入力した際に次のメッセージが表示された場合、この問題はユーザー等価関係エラーが原因である可能性があります。

The authenticity of host 'node1 (140.87.152.153)' can't be established.
RSA key fingerprint is 7z:ez:e7:f6:f4:f2:4f:8f:9z:79:85:62:20:90:92:z9.
Are you sure you want to continue connecting (yes/no)?

「yes」と入力してクラスタ検証ユーティリティを実行し、ユーザー等価関係エラーが解決されたかどうか確認します。

sshがデフォルト(/usr/bin)以外の場所にある場合は、クラスタ検証ユーティリティによって、ユーザー等価関係の検証に失敗したことがレポートされます。このエラーを回避するには、Grid_home/cv/adminディレクトリに移動し、テキスト・エディタでcvu_configファイルを開き、ORACLE_SRVM_REMOTESHELLキーを追加または更新してシステム上のsshパスの位置を指定します。次に例を示します。

# Locations for ssh and scp commands
ORACLE_SRVM_REMOTESHELL=/usr/local/bin/ssh
ORACLE_SRVM_REMOTECOPY=/usr/local/bin/scp

cvu_configファイルを変更する場合は、次の規則に注意します。

- キー・エントリはname=value構文で指定する。

- キーに割り当てる各キー・エントリおよび値は適切なものを1のみ定義する。

- シャープ記号(#)で始まる行はコメント行であり無視される。

- name=value構文が前にない行は無視される。

パス設定の変更後、再度クラスタ検証ユーティリティを実行します。また、sshがデフォルト以外の場所にある場合は、リモート・シェルおよびリモート・コピー・コマンドに別の場所を指定するために引数を追加してOUIを起動する必要があります。これらの引数の使用方法の詳細を表示するには、runInstaller -helpを入力してください。

注意:
ユーザーまたはOUIがsshまたはrshコマンド(ログインや起動するその他のシェル・スクリプトを含む)を実行し、それらのスクリプトによって出力が行われると、無効な引数または標準の入力に関するエラーが表示されます。これらのエラーの原因を解決する必要があります。
エラーを回避するには、sshまたはrshコマンドを実行すると出力を生成する、oracleユーザーのログイン・スクリプトからすべてのコマンドを削除してください。

X11転送についてのメッセージが表示されたら、タスクを完了します。

この問題を解決するには、第5.2.3項「リモート表示およびX11転送の構成の設定」を参照してください。

次のようなエラーが出力される場合もあります。

stty: standard input: Invalid argument
stty: standard input: Invalid argument

これらのエラーは、システム上の隠しファイル(.bashrc、.cshrcなど)にsttyコマンドが含まれている場合に発生します。このエラーが表示された場合は、第5.2.4項「インストール中に端末出力コマンドによって発生するエラーの防止」を参照してこれらの問題の原因を解決してください。

「ノードからのノード到達可能性チェックが失敗しました。」または「ノード接続性チェックが失敗しました。」

原因: クラスタ内に、TCP/IPプロトコルを使用したパブリックまたはプライベート・インターコネクトで到達できない1つ以上のノードがあります。

処置: /bin/ping addressコマンドを使用して、各ノードのアドレスを確認してください。到達できないアドレスを発見した場合は、パブリックおよびプライベート・アドレスのリストを確認して、それらを正しく構成してください。他社ベンダーのクラスタウェアを使用する場合に役立つ情報については、そのベンダーのドキュメントを参照してください。パブリック・ネットワーク・インタフェースおよびプライベート・ネットワーク・インタフェースのインタフェース名は、クラスタ内の各ノードで同じである必要があります。

「ユーザーの存在チェックが失敗しました。」または「ユーザーとグループの関係チェックが失敗しました」

原因: インストールに必要なユーザーおよびグループの管理権限が付与されていないか、または正しくありません。

処置: 各ノードでidコマンドを使用して、インストール所有者ユーザー(gridやoracleなど)が正しいグループ・メンバーシップで作成されていることを確認してください。必要なグループを作成していることを確認し、影響のあるノードでユーザー・アカウントを作成または変更して、必要なグループ・メンバーシップを設定してください。

関連項目:
必要なグループの作成方法およびインストール所有者ユーザーの構成方法については、第5章の「Oracle Grid InfrastructureおよびOracle RACのユーザー、グループおよび環境の構成」を参照してください。

A.5 Oracle Grid Infrastructureのアラート・ログについて

深刻なエラーを見つけるには、まずOracle Grid Infrastructureのアラート・ログを見ます。エラーが発生すると、エラーの原因に関する具体的な情報がある診断ログのパス情報が含まれていることがあります。

重要なイベントが発生した場合には、インストール後に、Oracle Grid Infrastructureがアラート・メッセージを書き込みます。たとえば、Cluster Ready Services(CRS)デーモン・プロセスからのアラート・メッセージは、起動時、中断した場合、フェイルオーバー・プロセスが失敗した場合、CRSリソースの自動再起動が失敗した場合に出力されます。

Oracle Enterprise ManagerはClusterwareのログ・ファイルを監視し、エラーが検出されると「クラスタ・ホーム」ページにアラートを書き込みます。たとえば、投票ディスクが利用できない場合はCRS-1604エラーが発生し、「クラスタ・ホーム」ページにクリティカル・アラートが書き込まれます。「メトリックとポリシー設定」ページで、エラー検出とアラートの設定をカスタマイズできます。

Oracle Grid Infrastructureのログ・ファイルの場所は、Grid_home/log/hostname/alerthostname.logです。Grid_homeはOracle Grid Infrastructureがインストールされたディレクトリ、hostnameはローカル・ノードのホスト名です。

関連項目:
『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

A.6 Oracle Grid Infrastructureのインストール中のクラスタ診断の実行

Oracle Universal Installer (OUI)で「ノードの選択」ページが表示されない場合は、次のコマンド構文を使用してクラスタ・マネージャの整合性を検証します。

cluvfy comp clumgr -n node_list -verbose

前述の構文例で、node_list変数は、クラスタ内のノードのカンマ区切りリストです。

注意:
cronジョブの実行中または実行後に予期しないインストール・エラーが発生した場合は、インストールが完了する前にcronジョブによって一時ファイルが削除されている可能性があります。日常のcronジョブを実行する前にインストールを完了するか、インストールが完了するまで、クリーンアップを行う日常のcronジョブを無効にすることをお薦めします。

A.7 インストール後のCVUのクラスタ・ヘルス・チェックの使用について

Oracle Grid Infrastructure 11gリリース2(11.2.0.3)以上では、CVUのhealthcheckコマンド・オプションを使用してOracle Grid InfrastructureおよびOracle Databaseインストールをチェックし、必須要件およびベスト・プラクティス・ガイドラインへの適合性を調べたり、正しく動作していることを確認できます。

次の構文を使用してhealthcheckコマンド・オプションを実行します。

cluvfy comp healthcheck [-collect {cluster|database}] [-db db_unique_name] [-bestpractice|-mandatory] [-deviations] [-html] [-save [-savedir directory_path]

次に例を示します。

$ cd /home/grid/cvu_home/bin
$ ./cluvfy comp healthcheck -collect cluster -bestpractice -deviations -html

オプションは次のとおりです。

- -collect [cluster|database]
このフラグを使用して、Oracle Grid Infrastructure (クラスタ)またはOracle Database (データベース)のチェックを実行することを指定します。healthcheckオプションでcollectフラグを使用しない場合、cluvfy comp healthcheckではOracle Grid InfrastructureとOracle Databaseの両方のチェックが実行されます。

- -db db_unique_name
このフラグを使用して、dbフラグの後に入力した一意のデータベース名に対するチェックを指定します。

CVUでは、JDBCを使用してcvusysユーザーとしてデータベースに接続し、様々なデータベース・パラメータが検証されます。このため、-dbフラグで指定したデータベースに対してチェックを実行する場合は、最初にそのデータベースでcvusysユーザーを作成し、このユーザーにCVU固有の役割であるcvusappを付与する必要があります。cvusappの役割のメンバーに、システム表に対するselect権限を付与する必要もあります。

SQLスクリプトがCVU_home/cv/admin/cvusys.sqlに含まれており、このユーザーの作成を容易にします。このSQLスクリプトを使用して、CVUにより検証するすべてのデータベースでcvusysユーザーを作成します。

dbフラグを使用し、一意のデータベース名を指定しない場合、CVUではクラスタのすべてのOracle Databaseが検出されます。これらのデータベースでベスト・プラクティス・チェックを実行する場合は、各データベースでcvusysユーザーを作成し、ベスト・プラクティス・チェックを実行するのに必要なcvusappの役割とselect権限をこのユーザーに付与する必要があります。

- [-bestpractice | -mandatory] [-deviations]
ベスト・プラクティス・チェックを指定するにはbestpracticeフラグを使用し、必須チェックを指定するにはmandatoryフラグを使用します。ベスト・プラクティスの推奨事項または必須要件からの差異のみを確認することを指定するには、deviationsフラグを追加します。-bestpracticeまたは-mandatoryのいずれかのフラグを指定できますが、両方のフラグを指定することはできません。-bestpracticeまたは-mandatoryのいずれも指定しない場合は、ベスト・プラクティスと必須要件の両方が表示されます。

- -html
htmlフラグを使用すると、詳細レポートがHTML形式で生成されます。

htmlフラグを指定し、CVUで認識されるブラウザがシステムで使用可能な場合は、チェックの完了時にブラウザが起動されてレポートがブラウザに表示されます。

htmlフラグを指定しない場合、詳細レポートはテキスト・ファイルで生成されます。

- -save [-savedir dir_path]
検証レポート(cvuchecdkreport_timestamp.txtおよびcvucheckreport_timestamp.htm)を保存するには、saveフラグまたは-save -savedirフラグを使用します(timestampは検証レポートの日時)。

saveフラグを単独で使用すると、レポートはパスCVU_home/cv/reportに保存されます(CVU_homeはCVUバイナリの場所)。

-save -savedirフラグを使用し、CVUレポートを保存するパスを入力すると、指定したパスにCVUレポートが保存されます。

A.8 インターコネクト構成の問題

インターコネクトに複数のネットワーク・インタフェース・カード(NIC)を使用する場合で、それらを冗長インターコネクトを使用してインストール時またはインストール後に構成していない場合は、サード・パーティのソリューションを使用して、オペレーティング・システム・レベルでインタフェースを集約する必要があります。そうしない場合、1つのNICの障害が、クラスタ・ノードの可用性に影響します。

集約されたNICカードを使用し、Oracle Clusterware冗長インターコネクト機能を使用する場合、それらのカードは異なるサブネット上に存在する必要があります。サード・パーティ・ベンダーの集約方法を使用する場合は、そのベンダーの製品に対する指示に従います。

エラーが発生したら、次のシステム検証を実行してください。

- スイッチに適切なケーブル(長さやタイプ)やソフトウェアが使用されていることを、ネットワーク・プロバイダに確認してください。場合によっては、負荷によって切断を起こす不具合を回避するため、またはジャンボ・フレームなどの追加機能をサポートするために、インターコネクト・スイッチのファームウェアのアップグレードや、新しいNICドライバ、オペレーティング・システム・レベルの新しいファームウェアが必要になることがあります。こうした修正を行わずに実行すると、初めのインストールは正常に見えても、後でOracle RACデータベースが不安定になることがあります。

- ベンダーおよびOracleの推奨事項に従って、VLAN構成、二重化設定、自動ネゴシエーションを確認してください。

A.9 SCAN VIPおよびSCANリスナーの問題

インストールでSCAN VIPアドレスまたはリスナーに関連するエラーが報告される場合は、次の項目をチェックしてネットワークが正しく構成されていることを確認します。

- ファイル/etc/resolv.confをチェックし、各ノードで内容が同じであることを確認します。

- SCANのDNSエントリがあること、およびこれによって3つの有効なIPアドレスが解決されることを確認します。コマンドnslookup scan-nameを使用します(このコマンドにより、SCANに対して構成されたDNSサーバー名と3つのIPアドレスが返されます)。

- pingコマンドを使用して、SCANに割り当てられたIPアドレスをテストします(IPアドレスごとに応答を受け取ります)。

注意:
クラスタ環境にDNSを構成していない場合は、各ノードの/etc/hostsファイルにSCANのエントリを作成できます。ただし、SCAN結果の解決に/etc/hostsファイルを使用した場合、クラスタ全体で使用可能なSCANは、3つではなく1つのみになります。hostsファイルのSCANの最初のエントリのみが使用されます。

- パブリック・インタフェースと同じサブネットがSCAN VIPで使用されていることを確認してください。

SCAN、SCAN VIPまたはリスナーに関連するエラーのトラブルシューティングについてさらに支援が必要な場合は、My Oracle Supportを参照してください。たとえば、Doc ID 1373350.1のNoteには、SCAN VIPおよびリスナーの最も一般的な問題の一部が含まれています。

A.10 ストレージ構成の問題

次にストレージ構成の問題を示します。

- ノード・ファイル・システムまたはグリッド・ホーム損失からのリカバリ

A.10.1 ノード・ファイル・システムまたはGridホーム損失からのリカバリ

Oracle Grid Infrastructureリリース11.2以上では、誤ってファイル・システムを削除したり、Oracle Local Registryを失うことになる別のストレージ構成の問題が発生したり、ノードが破損した場合は、次のいずれかの方法でノードをリカバリできます。

- オペレーティング・システム・レベルのバックアップからノードをリストアする(推奨)。

- ノードを削除した後、ノードを追加する。11.2以上のクラスタでは、プロファイル情報はノードにコピーされ、ノードがリストアされます。

addnode.shを使用するとクラスタ・ノードを削除して再度追加でき、クラスタ内の残りのノードからリストアできるようになります。GNS構成でノードを追加した場合は、グリッドのプラグ・アンド・プレイ(GPnP)と呼ばれます。GPnPではプロファイルを使用してノードが構成されるため、ノードの構成データ要件がなくなり、明示的にノードを追加したり削除する必要性がなくなります。GPnPによって、システム管理者は、テンプレートのシステム・イメージを取得するだけで、それ以上の構成を行わなくても、新しいノードでそのイメージを実行できます。GPnPにより、多くの手動操作が不要になり、エラーの発生する可能性が減るだけでなく、構成の変更をより簡単に行えるようになります。個々のノードの構成が排除されると、個々の状態をノードで保持して管理する必要がなくなるため、ノードの交換が容易になります。

GPnPにより、ノードの状態が使い捨て可能になることで、データベース・ノードのインストール、構成および管理のコストが削減されます。これによって、再生成された状態でノードを簡単に交換できるようになります。

関連項目:
手動でまたはGNSでノードを追加する方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

A.11 失敗または不完全なインストールおよびアップグレード

Oracle Grid Infrastructureのインストール中に、次のアクションが起こります。

1. システムにOracle Grid Infrastructureソフトウェアを設定するために、Oracle Universal Installer (OUI)により入力が求められます。

2. スクリプトorainstRoot.shおよびroot.shを実行するように指示されます。

3. スクリプトを実行し、OUIで「OK」をクリックします。

4. OUIによりコンフィギュレーション・アシスタントが実行されます。Oracle Grid Infrastructureソフトウェアのインストールが正常に完了します。

root.shスクリプトの実行前にOUIが終了した場合、またはインストールのセッションが正常に完了する前にOUIが終了した場合、Oracle Grid Infrastructureのインストールは不完全になります。インストールが完了していない場合は、Oracle Clusterwareが正しく動作しません。アップグレードを行い、インストールが正常に完了しない場合、一部のノードは最新のソフトウェアにアップグレードされ、その他のノードはまったくアップグレードされないということになります。

このエラーを解決するには、サーバーを再起動し、A.12項「失敗または中断されたインストールおよびアップグレードの完了」で説明された、不完全なインストールを完了させるための手順に従ってください。

A.12 失敗または中断されたインストールおよびアップグレードの完了

インストールを開始したノードでOUIが終了する場合、またはroot.shまたはrootupgrade.shスクリプトがノードで実行されたことを確認する前にノードが再起動された場合、インストールは不完全となります。インストールが不完全でも、コンフィギュレーション・アシスタントを実行する必要があり、中央Oracle Inventoryで新しいGridホームをアクティブとマーク付けする必要があります。インストールを完了させる必要があります。

この項の内容は次のとおりです。

- 失敗したまたは不完全なインストールおよびアップグレード

- 失敗または中断されたインストールおよびアップグレードの完了

A.12.1 最初のノードでの不完全なインストールの続行

最初のノードでの不完全なインストールを続行するには、次の手順を実行します。

1. クラスタ内の他のすべてのノードでアップグレードを完了します。

2. 最初のノード(インストールを開始したノード)を再起動します。

3. rootとしてログインし、orainstRoot.shスクリプトを実行します。次に例を示します。

$ sudo -s
[root@node1]# cd /u01/app/oraInventory
[root@node1]# ./orainstRoot.sh

4. 最初のノードでGridホームのディレクトリに移動し、そのノードで再度rootスクリプトを実行します。次に例を示します。

[root@node1]# cd /u01/app/12.1.0/grid
[root@node1]# ./root.sh

5. レスポンス・ファイルを構成し、インストール用のパスワードを指定します。レスポンス・ファイルの作成方法の詳細は、第C.5項「レスポンス・ファイルを使用したインストール後の構成」を参照してください。

6. アップグレードまたはインストールを完了するには、Gridインストール所有者としてログインしてから、Gridhome/cfgtoollogs/configToolAllCommandsのパスにあるスクリプトconfigToolAllCommandsを実行して、作成したレスポンス・ファイルを指定します。たとえば、レスポンス・ファイルがgridinstall.rspの場合は次のとおりです。

[grid@node1]$ cd /u01/app/12.1.0/grid/cfgtoollogs
[grid@node1]$ ./configToolAllCommands RESPONSE_FILE=gridinstall.rsp

A.12.2 最初のノード以外のノードでのインストールの続行

最初のノード(インストールを開始したノード)以外のノード:

1. エラーが発生したノードを再起動します。

2. rootとしてログインし、orainstRoot.shスクリプトを実行します。次に例を示します。

$ sudo -s
[root@node6]# cd /u01/app/oraInventory
[root@node6]# ./orainstRoot.sh

3. Gridホームのディレクトリに変更し、そのノードでrootスクリプトを実行します。次に例を示します。

[root@node6]# cd /u01/app/12.1.0/grid
[root@node6]# ./root.sh

B Oracle Grid Infrastructure 12cリリース1へのアップグレード方法

この付録では、Oracle ClusterwareおよびOracle Automatic Storage Managementのアップグレードの実行方法について説明します。

Oracle Clusterwareのアップグレードでは、ローリング・アップグレードが可能です。ローリング・アップグレードでは、他のノードはアクティブなまま、ノードのサブセットを停止してアップグレードします。Oracle Automatic Storage Management 11gリリース2 (11.2)のアップグレードでは、ローリング・アップグレードが可能です。ノードのサブセットをアップグレードする場合は、アップグレードの対象として選択しなかった既存のクラスタ・ノードでソフトウェアのみのインストールが実行されます。

この付録の内容は次のとおりです。

- アップグレード前のOracleソフトウェアのバックアップ

- Oracle環境変数の設定の削除

- Oracle Grid InfrastructureおよびOracle ASMのアップグレードおよびダウングレードについて

- クラスタウェアおよびOracle ASMのアップグレードとダウングレードのオプション

- クラスタウェアおよびOracle ASMアップグレードの制限事項

- 既存のOracle Clusterwareインストールをアップグレードするための準備

- CVUを使用した、Oracle Clusterwareのアップグレードに対する準備状況の検証

- Oracle Grid Infrastructureのローリング・アップグレードの実行

- Oracle Enterprise Manager Cloud Controlのターゲット・パラメータの更新

- 既存のOracle Clusterwareインストールのロック解除

- アップグレード後のOracle Clusterwareのダウングレード

B.1 アップグレード前のOracleソフトウェアのバックアップ

Oracleソフトウェアを変更する前に、Oracleソフトウェアおよびデータベースのバックアップを作成することをお薦めします。

B.2 Oracle環境変数の設定削除

Oracle環境変数の設定を削除します。

環境変数にORA_CRS_HOMEを設定した場合は、Oracleサポートの指示に従ってから、インストールまたはアップグレードを開始する前にその設定を削除します。Oracleサポートから明示的に指示がないかぎり、ORA_CRS_HOMEを環境変数として使用しないでください。

インストール所有者のログイン・シェル・プロファイル(.profileや.cshrcなど)にORA_CRS_HOMEが設定されていないことを確認します。

システムに既存のインストール環境があり、同じユーザー・アカウントを使用して今回のインストールを行う場合、環境変数ORA_CRS_HOME、ORACLE_HOME、ORA_NLS10、TNS_ADMIN、またはOracleソフトウェア・ホームに接続されているOracleインストール・ユーザーに対して設定されたその他の環境変数の設定を削除します。

また、$ORACLE_HOME/binパスがPATH環境変数から削除されていることを確認します。

B.3 Oracle Grid InfrastructureおよびOracle ASMのアップグレードおよびダウングレードについて

次のいずれかの方法で、Oracle Grid Infrastructureをアップグレードできます。

- クラスタ内の他のノードのOracle Grid Infrastructureを停止せずに個々のノードをアップグレードする、ローリング・アップグレード

- 1つを除くすべてのノードを停止する、非ローリング・アップグレード。アップグレードを開始するノードでrootスクリプトが古いOracle Clusterwareスタックを停止して新しいOracle Clusterwareスタックを起動する間、クラスタ全体が停止します。アップグレードが完了した後、新しいOracle Clusterwareがすべてのノードで起動します。

1つ以上のノードがアップグレード中のときは一部のサービスが無効になります。すべてのアップグレードはアウトオブプレース・アップグレードですが、これは、以前のリリースで使用されたGridホームとは異なるGridホームにソフトウェア・バイナリが配置されることを意味します。

Oracle Grid Infrastructure 12cリリース1 (12.1)から、以前のリリースのOracle Grid Infrastructureにダウングレードできます。以前のリリースにダウングレードする場合、クラスタは以前のそのリリースの構成要件に準拠する必要があり、クラスタで利用できる機能は以前のそのリリースのOracle ClusterwareとOracle ASMで利用できる機能のみとなることに注意してください。

既存のOracle ASM 11gリリース1 (11.1)または10gリリースのインスタンスがあり、Oracle ASMが別のホームにある場合は、これをOracle Grid Infrastructureのインストール時にアップグレードするか、Oracle ASM Configuration Assistant (ASMCA)を使用してインストール後にアップグレードできます。ただし、Oracle ASMをアップグレードするまで、多数のOracle ASM機能が無効であることに注意してください。また、Oracle ASMがアップグレードされるまで、Oracle ASMのOracle Clusterware管理は正しく機能しません。これは、Oracle Grid Infrastructureホームで実行されているときのみ、Oracle ClusterwareはOracle ASMを管理するためです。このことから、Oracle Clusterwareのアップグレードと同時にOracle ASMをアップグレードしない場合は、Oracle ASMを直後にアップグレードすることをお薦めします。この問題は、Oracle ASM 11gリリース2 (11.2)以上には該当しません(Oracle Grid InfrastructureホームにOracle ASMバイナリも含まれるため)。

Oracle ASM Configuration Assistant(ASMCA)を使用すると、Oracle ASMインスタンスにアウトオブプレース・アップグレードを実行できます。グラフィカル・ユーザー・インタフェースを使用する以外に、非対話型(サイレント)モードでもASMCAを実行できます。

注意:
クラスタのバックアップ・ファイルを使用する前に、アップグレードを完了する必要があります。アップグレードが完了していないクラスタのバックアップは使用できません。

関連項目:
既存のOracle ASMインストールのアップグレードについては、『Oracle Databaseアップグレード・ガイド』および『Oracle Database Storage管理者ガイド』を参照してください。

B.4 クラスタウェアおよびOracle ASMのアップグレードとダウングレードのオプション

Oracle Grid Infrastructure 11gからOracle Grid Infrastructure 12cへのアップグレード・オプションには次のものがあります。

- クラスタ内の他のノードのOracle Grid Infrastructureを停止せずに個々のノードをアップグレードする、Oracle Grid Infrastructureのローリング・アップグレード

- クラスタを停止せず、クラスタ全体をアップグレードするOracle Grid Infrastructureのローリングではないアップグレード

Oracle Grid Infrastructure 11gリリース2 (11.2)より前のリリースからOracle Grid Infrastructure 12cへのアップグレード・オプションには次のものがあります。

- Oracle Grid Infrastructureのローリング・アップグレード(OCRと投票ディスクはOracle ASM以外の記憶域上にある)

- Oracle Grid Infrastructureのクラスタ全体のアップグレード(停止時間、非ローリング)(OCRと投票ディスクはOracle ASM以外の記憶域上にある)

Oracle Grid Infrastructure 11gリリース2(11.2)からOracle Grid Infrastructure 12cへのアップグレード・オプションには次のものがあります。

- Oracle Grid Infrastructureのローリング・アップグレード(OCRと投票ディスクはOracle ASMまたは共有ファイル・システム上にある)

- Oracle Grid Infrastructureのクラスタ全体のアップグレード(停止時間、非ローリング)(OCRと投票ディスクはOracle ASMまたは共有ファイル・システム上にある)

Oracle Grid Infrastructure 12cから以前のリリースへのダウングレード・オプションには次があります。

- Oracle Grid Infrastructure 11gリリース2 (11.2)へのOracle Grid Infrastructureのダウングレード

- Oracle Grid Infrastructure 11gリリース2 (11.2)より前のリリースであるOracle Grid Infrastructure 11gリリース1 (11.1)、Oracle ClusterwareおよびOracle ASM 10gへのOracle Grid Infrastructureのダウングレード(OCRと投票ファイル用の記憶域がOracle ASM以外の記憶域上にある場合)

B.5 クラスタウェアおよびOracle ASMアップグレードの制限事項

クラスタ検証ユーティリティ・ツール(CVU)を使用して、既存のOracle Grid Infrastructure 11gリリース2 (11.2)またはOracle RACデータベース11gリリース2 (11.2)のインストールをアップグレードするために必要なパッチがあるかどうかを確認することをお薦めします。

関連項目:
第B.7項「CVUを使用した、Oracle Clusterwareのアップグレードに対する準備状況の検証」

Oracle ClusterwareおよびOracle Automatic Storage Management(Oracle ASM)で構成されるOracle Grid Infrastructure環境へのアップグレードには、次の制限と変更点があることに注意してください。

- Oracle Grid Infrastructure 11gまたはOracle ClusterwareおよびOracle ASM 10gリリースの標準クラスタから、Oracle Grid Infrastructure 12cリリース1 (12.1)のOracle Flex Cluster構成へのアップグレードはサポートされません。

- 現在のインストールのOracle Cluster Registry(OCR)および投票ファイルの場所がRAWまたはブロック・デバイス上にある場合は、Oracle Grid Infrastructure 12 cにアップグレードする前に、これらをOracle ASMディスク・グループまたは共有ファイル・システムに移行する必要があります。

- Oracle Grid Infrastructure 12cリリース1 (12.1)のOracle Flex Cluster構成から標準クラスタ構成へのダウングレードはサポートされません。Oracle Grid Infrastructure 12cより前のリリースのクラスタ構成はすべて、標準クラスタ構成です。このダウングレードの制限には、Oracle Flex ClusterからOracle Grid Infrastructure 11gのクラスタまたはOracle ClusterwareおよびOracle ASM 10gのクラスタへのダウングレードが含まれます。

- アップグレードした元のOracle Grid Infrastructureのリリースにダウングレードできます。たとえば、Oracle Grid Infrastructure 11gリリース2 (11.2)からOracle Grid Infrastructure 12cリリース1 (12.1)にアップグレードした場合、Oracle Grid Infrastructure 11gリリース2 (11.2)にのみダウングレードできます。

- アップグレードすると、常に標準クラスタになります。クラスタ・メンバー・ノードの役割をリーフに変更するには、すべてのOracle Grid InfrastructureノードをOracle Grid Infrastructure 12cリリース1 (12.1)以上にアップグレードし、アクティブなリリースをOracle Grid Infrastructure 12cリリース1 (12.1)以上にアップグレードする必要があります。

- Oracle Grid Infrastructure 11gリリース2 (11.2)より前のOracle Grid Infrastructureリリースをアップグレードするときに、OCRと投票ディスク・ファイルがRAWまたはブロック・デバイス上にあり、これらのファイルを共有ファイル・システムではなく、Oracle ASMに移行する場合は、Oracle Grid Infrastructure 12cにアップグレードする前に、Oracle Grid Infrastructure 11gリリース2 (11.2)にアップグレードする必要があります。

- 既存のOracle Clusterwareインストールを標準構成のOracle Grid Infrastructure 12cのクラスタにアップグレードするには、リリースがOracle Clusterware 10gリリース1 (10.1.0.5)、Oracle Clusterware 10gリリース2 (10.2.0.3)、Oracle Grid Infrastructure 11gリリース1 (11.1.0.6)、Oracle Grid Infrastructure 11gリリース2 (11.2)以上である必要があります。

- 既存のOracle Grid InfrastructureインストールをOracle Grid Infrastructure 11gリリース2 (11.2.0.2)から新しいリリースにアップグレードするには、パッチ11.2.0.2.3 (11.2.0.2 PSU 3)以上を適用する必要があります。

- 既存のOracle Grid InfrastructureインストールをOracle Grid Infrastructure 12cリリース1 (12.1)にアップグレードするには、まず、アップグレードを正常に実行するのに必須のパッチを適用する必要があるかどうかを確認する必要があります。準備状況の確認手順については、第B.6.1項を参照してください。

関連項目:
「Oracle 12c Upgrade Companion」(My Oracle SupportのNote 1462240.1):
https://support.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1462240.1

- Oracle ClusterwareおよびOracle ASMのアップグレードは、常にアウトオブプレース・アップグレードで行われます。既存のホームへのOracle ClusterwareおよびOracle ASMのインプレース・アップグレードは実行できません。

- 既存のOracle Clusterwareホームが共有ホームの場合、Oracle ClusterwareおよびOracle ASM 12cリリース1 (12.1)のクラスタ用Oracle Grid Infrastructureホームに、共有されていないホームを使用できます。

- 以前のリリースのOracle Grid Infrastructureソフトウェアを所有していた同じユーザーが、Oracle Grid Infrastructure 12cリリース1 (12.1)アップグレードを実行する必要があります。Oracle Database 11gの前は、すべてのOracleソフトウェアのインストールをOracleユーザー(通常はoracle)が所有していたか、またはOracle Databaseソフトウェアはoracleが所有し、Oracle Clusterwareソフトウェアは別のユーザー(通常はcrs)が所有していました。

- Oracle ASMとOracle Clusterwareの両方がOracle Grid Infrastructureホームで実行されます。

- Oracle Grid Infrastructure 12cリリース1 (12.1)へのメジャー・リリース・アップグレード中、12cリリース1 (12.1)のOracle Grid Infrastructureホームにあるソフトウェアは、アップグレードが完了するまで完全には機能しません。最終的にrootupgrade.shスクリプトが実行され、すべてのノードでアップグレードが完了するまで、新しいGridホームからのsrvctl、crsctl、その他コマンドの実行はサポートされません。
Oracle Grid Infrastructureのアップグレード中に既存の旧リリースのデータベース・ホームのデータベースを管理するには、既存のデータベース・ホームからsrvctlを使用します。

- 共有Oracle Clusterwareホームでアップグレードを実行できます。

- Oracle Clusterwareのインストール中に、シングル・インスタンスのOracle ASMリリースがローカル・ノードに存在する場合、そのOracle ASMはクラスタ化されたOracle ASM 12cリリース1 (12.1)に変換され、Oracle ASMはすべてのノードのOracle Grid Infrastructureホームで実行されます。

- ローカル・ノード(Oracle Grid Infrastructureのインストールを実行中のノード)以外のリモート・ノードにシングル・インスタンスの(クラスタ化されていない)Oracle ASMがインストールされている場合は、シングル・インスタンスのOracle ASM環境がそのまま維持されます。ただし、インストール中に、Oracle Cluster Registry(OCR)および投票ディスクのファイルをOracle ASMに置くように選択した場合は、クラスタ化されたOracle ASMのインストール環境がクラスタ内のすべてのノードに作成され、リモート・ノードにインストールされているシングル・インスタンスのOracle ASMは機能しなくなります。

関連項目:
アップグレードの準備の詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

B.6 既存のOracle Clusterwareインストールをアップグレードするための準備

既存のOracle Clusterwareインストールがある場合は、アウトオブプレース・アップグレードを行うことにより、既存のクラスタをアップグレードします。インプレース・アップグレードは実行できません。

B.6.1 既存のOracle Clusterwareインストールをアップグレードする前の完了の確認

アップグレードを開始する前に、次の作業を行います。

1. 各ノードで、クラスタ検証ユーティリティを使用して、インストール前の手順が完了していることを確認します。これは、サーバーの準備をするための修正スクリプトを生成することができます。また、インストーラでは、必要な前提条件をすべて満たしていることが確認されます。
次の情報を含めて、インストール時に必要な情報がすべて揃っていることを確認します。

- Oracle ClusterwareのOracleベースの場所。

- 既存のOracle Clusterwareの場所とは異なる、Oracle Grid Infrastructureホームの場所。

- SCAN名およびアドレスと、その他のネットワーク・アドレス(第4章を参照)。

- 特権ユーザーのオペレーティング・システム・グループ(第5章を参照)。

- 第7.1.1項で説明されているオプションのいずれかを使用して、インストール中にrootとしてスクリプトを実行するためのrootユーザー・アクセス。

2. インストールを実行するインストール所有者に関しては、既存のインストールに対して環境変数が設定済の場合は、$ORACLE_HOMEおよび$ORACLE_SIDの設定を解除します。これらの環境設定がアップグレード中に使用されてしまうからです。次に例を示します。

$ unset ORACLE_BASE
$ unset ORACLE_HOME
$ unset ORACLE_SID

関連項目:
第B.2項「Oracle環境変数の設定の削除」

B.6.2 ORAchkアップグレード準備状況評価の実行

ORAchk (Oracle RAC構成監査ツール)アップグレード準備状況評価は、Oracle Grid Infrastructure 11.2.0.3、11.2.0.4および12.1.0.1にアップグレードする際のアップグレード固有のヘルス・チェックを自動的に行うために使用できます。ORAchkアップグレード準備状況評価ツールを実行すると、手動によるアップグレード前およびアップグレード後のチェックの多くを自動化できます。

My Oracle SupportからORAchkの最新バージョンをダウンロードして実行することをお薦めします。ORAchk構成監査ツールのダウンロード、構成および実行の詳細は、My Oracle SupportのNote 1457357.1を参照してください(次のURLから入手可能)。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1457357.1

B.7 CVUを使用した、Oracle Clusterwareのアップグレードに対する準備状況の検証

クラスタがアップグレードできる状態であることを検証するには、この項の内容を確認します。

B.7.1 CVUのグリッド・アップグレード検証コマンドのオプションについて

runcluvfy.shコマンドがあるアップグレードのステージング領域に移動し、runcluvfy.sh stage -pre crsinst -upgradeコマンドを実行してアップグレードに対するOracle Clusterwareインストールの準備状況を確認します。-pre crsinst -upgradeフラグを指定してruncluvfy.shを実行すると、既存のクラスタウェア・インストールのアップグレードに対してクラスタが適切な状態にあるかどうかを確認するためのシステム・チェックが実行されます。

このコマンドでは次の構文を使用します。可変的な内容はイタリック体で示されています。

runcluvfy.sh stage -pre crsinst -upgrade [-rolling] -src_crshome src_Gridhome -dest_crshome dest_Gridhome -dest_version dest_release
[-fixup][-method {sudo|root} [-location dir_path] [-user user_name]] [-verbose]

オプションは次のとおりです。

- -rolling
このフラグを使用すると、ローリング・アップグレードに対する準備状況が検証されます。

- -src_crshome src_Gridhome
このフラグは、アップグレードするソースOracle ClusterwareまたはGridホームの場所を指定します(src_Gridhomeはアップグレードするホームへのパス)。

- -dest_crshome dest_Gridhome
このフラグは、アップグレードGridホームの場所を指定します(dest_ GridhomeはGridホームへのパス)。

- -dest_version dest_version
dest_versionフラグは、パッチセットを含む、アップグレードのリリース番号を指定します。リリース番号には、リリースをプラットフォーム固有のパッチのレベルに指定する5つの数字を含める必要があります。たとえば、11.2.0.2.0などです。

- -fixup [-fixupdir fixupdirpath]
-fixupフラグは、クラスタのアップグレードの準備ができていることを確認するために実行が必要な必須手順に関する命令を生成することを示すために使用します。デフォルトの場所は、CVUの作業ディレクトリです。別のディレクトリに修正指示を配置する場合は、-fixupdirフラグを追加して必要な修正の指示を配置するディレクトリへのパスを指定します。

- -verbose
-verboseフラグを使用すると、個々のチェックの詳細な出力が生成されます。

B.7.2 グリッド・インフラストラクチャのシステム・アップグレードの準備状況の検証例

次のコマンドを実行すると、Oracle Clusterwareのインストールに必要な権限が構成されているかどうかを検証できます。

$ ./runcluvfy.sh stage -pre crsinst -upgrade -rolling -src_crshome
/u01/app/grid/11.2.0.1 -dest_crshome /u01/app/grid/11.2.0.2 -dest_version 11.2.0.3.0 -fixup -fixupdir /home/grid/fixup -verbose

B.7.3 Oracle Databaseアップグレードに対するシステム準備状況の検証

クラスタ検証ユーティリティを使用すると、データベースのアップグレードを開始する前準備として、システムをチェックできます。インストーラによって適切なCVUチェックが自動的に実行され、問題の修正を求めるプロンプトが表示されるか、またはアップグレードを進める前にクラスタ内のすべてのノード上で実行するための修正スクリプトが提供されます。

関連項目:
『Oracle Databaseアップグレード・ガイド』

B.8 バッチを使用したローリング・アップグレードの理解

以前のリリースからのアップグレードでは、クラスタ全体をアップグレードする必要があります。アップグレード対象の個々のノードを選択または選択解除することはできません。ローリング・アップグレード中にノードをクラスタに追加する操作はサポートされていません。

Oracle Clusterwareのアップグレード中、Oracle RACインスタンスは、実行したままにしておくことをお薦めします。各ノードでrootスクリプトを起動すると、そのノードのデータベース・インスタンスが停止され、rootupgrade.shスクリプトによってインスタンスは再度起動されます。Oracle Grid Infrastructure 11gリリース11.2.0.2以上をOracle Grid Infrastructureの任意の新しいリリースにアップグレードする場合は、すべてのノードがデフォルトでアップグレード対象として選択されます。

rootユーザーの自動化を使用して、アップグレード時のrootupgrade.shスクリプトの実行を自動化できます。rootの自動化を使用すると、ノードをグループ(バッチ)に分けてこれらのバッチのアップグレードを開始できます。バッチ間で、以前のリリースを実行しているノードからアップグレード済のノードにサービスを移動して、サービスがアップグレードの影響を受けないようにできます。rootの自動化を使用して、rootupgrade.shスクリプトがインスタンスを自動的に停止および起動できるようにすることをお薦めします。引き続きrootスクリプトを手動で実行することもできます。

B.9 Oracle Grid Infrastructureのローリング・アップグレードの実行

Oracle ClusterwareまたはOracle Automatic Storage Managementをアップグレードするには、次の手順を実行します。

- 以前のリリースからの標準的なアップグレードの実行

- ノードにアクセスできなくなった場合のOracle Clusterwareのアップグレードの完了

注意:
Oracle Clusterware 11gリリース2 (11.2)にアップグレードすると、Oracle Automatic Storage Management (Oracle ASM)がOracle Clusterwareと同じホームにインストールされます。このホームは、Oracleドキュメントでは、Oracle Grid InfrastructureホームまたはGridホームと呼ばれます。また、ローリング・アップグレード中に、ノードをクラスタに追加する操作はサポートされていません。

B.9.1 以前のリリースからの標準的なアップグレードの実行

クラスタを以前のリリースからアップグレードするには、次の手順を実行します。

1. インストーラを起動し、インストールされている既存のOracle ClusterwareおよびOracle ASMをアップグレードするオプションを選択します。

2. ノード選択ページで、すべてのノードを選択します。

3. 指示どおりに、インストール・オプションを選択します。rootスクリプトの自動化を構成して、アップグレード中にrootupgrade.shスクリプトが自動的に実行されるようにすることをお薦めします。

4. rootスクリプトを自動的に、または手動で実行します。

- rootスクリプトを自動的に実行する場合
rootスクリプトの自動化を構成した場合は、以前のリリースを実行しているノードから新しいリリースにサービスを再配置するために、バッチ間で一時停止を使用します。

- rootスクリプトを手動で実行する場合
rootスクリプトの自動化を構成していない場合は、プロンプトに従って、アップグレードするクラスタ内の各ノードでrootupgrade.shスクリプトを実行します。

rootスクリプトを手動で実行する場合は、最初にローカル・ノードでスクリプトを実行します。このスクリプトは、前のリリースのインストール環境を停止し、新しいOracle Clusterwareリリースに置き換えて、新しいOracle Clusterwareのインストールを開始します。

スクリプトが正常に完了したら、最後のノードとして選択した1つを除いて、すべてのノード上で並行してスクリプトを実行できます。最後のノードを除いたすべてのノード上でスクリプトが正常に実行されたら、最後のノード上でスクリプトを実行します。

5. クラスタ内の最後のノードでrootupgrade.shスクリプトを実行した後、Oracle Grid Infrastructure 11gリリース2 (11.2.0.1)よりも前のリリースからアップグレードしている場合にASMCAというラベルのチェックボックスが選択されている(デフォルト)ままにすると、Oracle Automatic Storage Management Configuration Assistant (ASMCA)が自動的に実行し、Oracle Grid Infrastructureのアップグレードが完了します。アップグレードのインタビュー・ステージでボックスの選択を解除すると、ASMCAは自動的には実行しません。
前のリリースのOracle Automatic Storage Management(Oracle ASM)がインストールされている場合、Oracle ASMを12cリリース1 (12.1)へアップグレードするために、インストーラによってASMCAが起動されます。Oracle ASMをこのときにアップグレードするか、または後でアップグレードするか、選択することができます。

Oracle Clusterwareバイナリをアップグレードするのと同時に、Oracle ASMもアップグレードすることをお薦めします。Oracle ASMがアップグレードされるまで、Oracle ASMを使用するOracle Databaseインストールはインストールできません。Oracle ASMがアップグレードされるまで、Gridホームにある12cリリース1 (12.1)のOracle ASM管理ツール(srvctlなど)は動作しません。

6. Oracle Grid Infrastructureホームは、以前のOracle ClusterwareホームおよびOracle ASMホームとは異なる場所にあるため、Oracle ClusterwareホームおよびOracle ASMホームにあるユーティリティ、ライブラリなどのファイルを使用するスクリプトまたはアプリケーションを更新します。

注意:
アップグレードの最後に、Oracle Cluster Registry (OCR)のバックアップ場所を前のリリースのOracle Clusterwareホーム(CRSホーム)に手動で設定していた場合は、新しいOracle Grid Infrastructureホーム(Gridホーム)に変更する必要があります。OCRのバックアップ場所を手動で設定しなかった場合は、アップグレード中にバックアップ場所が変更されます。
Oracle Clusterwareのアップグレードはアウトオブプレース・アップグレードなので、前のリリースのOracle Clusterwareホームを現在のリリースのOCRのバックアップ場所にすることはできません。以前のOracle Clusterwareホーム内のバックアップは削除できます。

B.9.2 ノードにアクセスできなくなった場合のOracle Clusterwareのアップグレードの完了

アップグレードの途中で一部のノードにアクセスできなくなった場合は、アクセスできないノードでアップグレード・スクリプト(rootupgrade.sh)が実行されないため、アップグレードを完了できません。アップグレードが完了していないため、Oracle Clusterwareは以前のリリースのままになります。crsctl query crs activeversionコマンドを入力すると、アップグレードが完了していないことを確認できます。

この問題を解決するには、rootupgrade.shスクリプトがすでに完了しているノードのいずれかで、-forceフラグを指定してrootupgrade.shコマンドを実行します。

Grid_home/rootupgrade -force

次に例を示します。

# /u01/app/12.1.0/grid/rootupgrade -force

このコマンドによってアップグレードが強制的に完了されます。crsctl query crs activeversionコマンドを使用して、アップグレードが完了したことを確認します。アクティブなリリースはアップグレード・リリースです。

クラスタの強制アップグレード・コマンドには、次の制限があります。

- すべてのアクティブ・ノードが新しいリリースにアップグレードされる必要があります。

- すべての非アクティブ・ノード(アクセス可能またはアクセス不可能)は、アップグレードされても、アップグレードされなくてもどちらでもかまいません。

- 強制コマンドを実行した後、アクセスできないノードには次の制限があります。

- パッチ・セット・アップグレードの後は、ノードをクラスタから削除できます。ノードが後でアクセス可能になり、パッチ・リリース・アップグレードのパスがサポートされる場合は、このノードを新しいパッチ・リリースにアップグレードできます。

B.9.3 アップグレードの強制後のアクセス不可のノードのアップグレード

以前のリリースでは、アクセスできないノードを削除する必要がありましたが、Oracle Grid Infrastructure 12cからは、クラスタの強制アップグレード・コマンドの完了後にそのようなノードをクラスタに統合できます。このオプションを使用するには、Oracle Grid Infrastructure 12cリリース1 (12.1)ソフトウェアがノードにインストールされている必要があります。

アクセス不可または接続不可なノードをアップグレードするには、次の手順を実行します。

1. クラスタに追加するノードで、グリッド・ユーザーとしてログインします。

2. Oracle Grid Infrastructure 12cリリース1 (12.1)のGridホームで/crs/installディレクトリに移動します。次に例を示します。

$ cd /u01/12.1.0/grid/crs/install

3. 次のPERLコマンドを実行します。existingnodeはコマンドを実行しているクラスタ内のノード、upgraded_nodeはクラスタに統合する、アクセスできないノードまたは到達できないノードです。

$ rootcrs.sh -join -existingnode upgraded_node

注意:
リリース11.2.0.1.0より前のOracle Clusterwareでは、-join操作はサポートされていません。その場合はノードを削除し、addNodeコマンドを使用してクラスタウェアに追加します。

B.9.4 インストールとアップグレードに使用する最初のノードの変更

最初のノードにアクセスできなくなった場合、別のノードを、インストールまたはアップグレードに使用する最初のノードに強制的に設定することができます。インストール時に、最初のノードでroot.shが失敗した場合、-forceオプションを使用して、別のノードで次のコマンドを実行します。

root.sh -force -first

アップグレードするには、次のコマンドを実行します。

rootupgrade.sh -force -first

B.9.5 Oracle Automatic Storage Managementのローリング・アップグレードの実行

Oracle ASMのローリング・アップグレード・オプションの詳細は、次の各項を参照してください。

- Oracle ASMの完全リリースのローリング・アップグレードについて

- 個々の(個別) Oracle ASMパッチについて

- Oracle Grid Infrastructureのソフトウェア・パッチ・レベルについて

B.9.5.1 Oracle ASMの完全リリースのローリング・アップグレードについて

Oracle Grid Infrastructure 12cリリース1 (12.1)アップグレードのOracle Clusterwareの部分が完了した後、次の状況でOracle ASMを個別にアップグレードする必要がある場合があります。

- Oracle ASM 10gリリース2 (10.2)またはOracle ASM 11gリリース1 (11.1)など、Oracle ASMが別のOracleホームにあるリリースからアップグレードする場合

- Oracle Grid InfrastructureのアップグレードがOracle ASMの部分で失敗した場合や、他の理由でAutomatic Storage Management Configuration Assistant(asmca)が実行されなかった場合

asmcaを使用するとアップグレードを別途行うことはできますが、Oracle ASMがアップグレードされるまでsrvctlなどのOracle ASM管理ツールは機能しないため、Oracle Clusterwareのアップグレード後にすぐに行う必要があります。

注意:
ASMCAによってローリング・アップグレードが実行されるのは、Oracle ASMの以前のリリースが11.1.0.6または11.1.0.7の場合のみです。そうでない場合、ASMCAによって通常のアップグレードが行われます。このアップグレードでは、ASMCAによって、クラスタのすべてのノードにおいて、すべてのOracle ASMインスタンスが停止され、新しいGridホームですべて再起動されます。

Oracle Grid Infrastructure 12cリリース1でOracle ASMをアップグレードした後、Oracle ASMの個々のパッチをOracle Automated Release Updateサイトからダウンロードしてインストールできます。

B.9.5.2 個々の(個別)Oracle ASMパッチについて

個々のパッチは個別パッチと呼ばれます。Oracle ASMの個別パッチは、特定のリリース済リリースのOracle ASM向けに用意されています。必要なパッチが使用可能である場合は、パッチをダウンロードし、OPatchユーティリティを使用してOracle ASMに適用できます。OPatchインベントリでは、Oracle ASMリリース用にインストールしたパッチが記録されます。インストール済のパッチと、適用するパッチの間に競合がある場合は、OPatchユーティリティからこれらの競合について通知されます。

B.9.5.3 Oracle Grid Infrastructureのソフトウェア・パッチ・レベルについて

Oracle Grid Infrastructureのソフトウェア・パッチ・レベルは、Oracle ASMを含むOracle Grid Infrastructureソフトウェア・リリースに適用される、すべての個別パッチのセットを表します。リリースとはリリース番号であり、メジャー、マイナー、パッチ・セットのリリースの形式です。たとえば、リリース番号が12.1.0.1である場合は、メジャー・リリースが12、マイナー・リリースが1、0.0がパッチ・セット番号です。個別パッチでは、メジャーおよびマイナー・リリースは変わりませんが、パッチ・レベルは個別パッチの適用またはロールバックのたびに変更されます。

Oracle Grid Infrastructureの標準アップグレードと同様、クラスタの正常な稼働には、どの時点でもクラスタ内のすべてのノードのソフトウェア・リリースおよびパッチ・レベルが同じである必要があります。個別パッチはローリング・アップグレードとして適用できるため、特定のソフトウェア・リリースのすべてのパッチ・レベルは相互に互換性があります。

B.9.6 Oracle ASMの個別アップグレードの実行準備

Oracle ASMのアップグレードを個別に完了する必要がある場合は、次の要件に注意してください。

- Oracle Clusterwareのアクティブなリリースは、12cリリース1 (12.1)である必要があります。アクティブなリリースを確認するには、次のコマンドを入力します。

$ crsctl query crs activeversion

- シングル・インスタンスのOracle ASM環境を、クラスタ化されたOracle ASM環境へアップグレードできます。ただし、シングル・インスタンスの既存のOracle ASM環境をアップグレードできるのは、そのOracle ASM環境があるノードからインストールを実行する場合のみです。リモート・ノードにあるシングル・インスタンスのOracle ASM環境をアップグレードすることはできません。

- アップグレード・プロセスを開始する前に、既存のOracle ASM環境で行われているリバランス操作が完了していることを確認する必要があります。

- アップグレード・プロセスの進行中は、Oracle ASMインスタンスをアップグレード状態に変更することになります。データベース・クライアントは、Oracle ACFS上にある場合を除き、停止する必要はありません。ただし、このアップグレード状態ではOracle ASM操作が制限されるため、アップグレード・プロセスは開始してすぐに完了する必要があります。Oracle ASMインスタンスがアップグレード状態にあるときに可能な操作は、次のとおりです。

- ディスク・グループのマウントとマウント解除

- データベース・ファイルのオープン、クローズ、サイズ変更または削除

- インスタンスのリカバリ

- 固定ビューおよび固定パッケージの問合せ(固定ビューの問合せと、dbms_diskgroupなどの固定パッケージを使用した匿名PL/SQLブロックの実行は可能です)

B.9.7 Oracle Grid InfrastructureアップグレードからのOracle ASMの個別パッチ適用

別のOracleホームにOracle ASMがインストールされたOracle ASMリリースからアップグレードする必要がある場合、またはOracle Grid InfrastructureのOracle ASMの部分が完了しなかった場合、次の作業を行います。

1. アップグレードを開始しようとしているノードで、環境変数ASMCA_ROLLING_UPGRADEの値をtrueにします。次に例を示します。

$ export ASMCA_ROLLING_UPGRADE=true

2. Oracle Grid Infrastructure 12cリリース1 (12.1)のホームから、ASMCAを起動します。次に例を示します。

$ cd /u01/12.1/grid/bin
$ ./asmca

3. 「アップグレード」を選択します。
ASM Configuration Assistantにより、クラスタ内にあるすべてのノードのOracle ASMが連続してアップグレードされます。

4. アップグレードが完了したら、コマンドを実行して、ASMCA_ROLLING_UPGRADE環境変数の設定を解除します。

関連項目:
Oracle ASMのアップグレード計画の準備、およびOracle ASMアップグレードの開始、実行、停止の詳細は、『Oracle Databaseアップグレード・ガイド』および『Oracle Database Storage管理者ガイド』を参照してください。

B.9.8 ソフトウェア・パッチ・レベルへのOracle ASMのアップグレード

Oracle Grid Infrastructure 12cリリース1 (12.1)以上では、「ローリング・パッチ」と呼ばれる新しいクラスタ状態が使用可能です。このモードは、この休止状態でOracle ASM操作が許可されるという点で、既存の「ローリング・アップグレード」モードに類似しています。

1. 適用するパッチをMy Oracle Supportからダウンロードします。
https://support.oracle.com

「パッチと更新版」タブを選択してパッチを検索します。

「推奨パッチ・アドバイザ」を選択して、ご使用のソフトウェアの製品グループ、リリースおよびプラットフォームを入力することをお薦めします。My Oracle Supportに、最新のパッチ・セット更新(PSU)と重要なパッチ更新(CPU)のリストが表示されます。

/tmpなど、アクセス可能なディレクトリにパッチを配置します。

2. ディレクトリをGridホーム内の/opatchディレクトリに変更します。次に例を示します。

$ cd /u01/app/12.1.0/grid/opatch

3. 適用するパッチのパッチ・ドキュメントを確認し、パッチのアップグレードを開始する前に必要な手順をすべて完了します。

B.10 Oracle Enterprise Manager Cloud Controlのターゲット・パラメータの更新

Oracle Clusterware 12cリリース1 (12.1)は新しい場所(クラスタ用Oracle Grid Infrastructureホーム、またはGridホーム)でOracle Clusterwareホームをアウトオブプレース・アップグレードしたものであるため、いくつかのパラメータ・ファイルでCRS_HOMEパラメータのパスを変更する必要があります。パラメータを変更しないと、Oracle Enterprise Manager Cloud Controlで、クラスタ・ターゲットの不正などのエラーが発生します。

問題を解決するには、次の各項の説明に従って、Enterprise Manager Cloud Controlターゲットをアップグレードし、エージェントを実行している各クラスタ・メンバー・ノードでEnterprise Managerのエージェント・ベース・ディレクトリを更新します。

- アップグレード後のEnterprise Manager Cloud Controlターゲットの更新

- アップグレード後のEnterprise Managerエージェント・ベース・ディレクトリの更新

B.10.1 アップグレード後のEnterprise Manager Cloud Controlターゲットの更新

1. Enterprise Manager Cloud Controlにログインします。

2. 「ターゲット」メニューに移動し、次に「クラスタ」ページに移動します。

3. アップグレードされたクラスタ・ターゲットをクリックします。

4. メニューで「クラスタ」→「ターゲット設定」→「監視構成」をクリックします。

5. 「Oracleホーム」の値を新しいGridホームのパスで更新します。

6. 更新を保存します。

B.10.2 アップグレード後のEnterprise Managerエージェント・ベース・ディレクトリの更新

1. エージェント・ベース・ディレクトリのbinディレクトリに移動します。
エージェント・ベース・ディレクトリは、管理エージェント・ホームが作成されるディレクトリです。これは、パスEMAgent_home/core/EMAgent_Version/binにあります。たとえば、エージェント・ベース・ディレクトリが/u01/app/gridの場合、管理エージェント・ホームは/u01/app/emagent/core/12.1.0.1.0/binのように作成されます。

2. binディレクトリのemctlファイルをテキスト・エディタで開きます。

3. CRS_HOMEパラメータを検索し、これを新しいGridホーム・パスに更新します。

4. Enterprise Managerエージェントを含むクラスタの各ノードで手順1-3を繰り返します。

B.11 既存のOracle Clusterwareインストールのロック解除

以前のリリースからアップグレードした後、以前のリリースのOracle Grid InfrastructureのGridホームを削除する場合は、以前のリリースのGridホームの権限と所有権を変更する必要があります。このタスクは、次の手順を使用して行います。

rootとしてログインし、次のコマンド構文を使用して以前のリリースのGridホームの権限と所有権を変更します(oldGHは以前のリリースのGridホーム、swownerはOracle Grid Infrastructureのインストール所有者、oldGHParentは以前のリリースのGridホームの親ディレクトリです)。

#chmod -R 755 oldGH
#chown -R swowner oldGH
#chown swowner oldGHParent

次に例を示します。

#chmod -R 755 /u01/app/11.2.0/grid
#chown -R grid /u01/app/11.2.0/grid
#chown grid /u01/app/11.2.0

以前のリリースのGridホームの権限と所有権を変更した後、Oracle Grid Infrastructureインストール所有者(前述の例ではgrid)としてログインし、同じリリースのOracle Grid Infrastructureスタンドアロン削除ツールを使用して、以前のリリースのGridホーム(oldGH)を削除します。

注意:
Oracleソフトウェアを削除するには、同じリリースの削除ツールを使用する必要があります。以前のリリースからOracleソフトウェアを削除するとき、それより新しいリリースの削除ツールは実行しないでください。たとえば、既存の11.2.0.4 OracleホームからOracleソフトウェアを削除する場合、12.1.0.1のインストール・メディアから削除ツールを実行しないでください。

スタンドアロン削除ツールは、次のURLから入手できます。

http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html

ご使用のオペレーティング・システム・プラットフォームに対応するダウンロードの「すべて見る」リンクをクリックして、削除ユーティリティ用のダウンロードのリストを調べます。

B.12 アップグレード後のOracle Clusterwareのダウングレード

Oracle Clusterware 12cリリース1 (12.1)へのアップグレードが成功または失敗した後で、Oracle Clusterwareを前のリリースにリストアすることができます。この項の内容は次のとおりです。

- アップグレード後のOracle Clusterwareのダウングレードについて

- 11gリリース2 (11.2.0.2)より前のリリースへのダウングレード

- 11gリリース2 (11.2.0.2)以上のリリースへのダウングレード

B.12.1 アップグレード後のOracle Clusterwareのダウングレードについて

Oracle Clusterwareをダウングレードすると、Oracle Clusterwareの構成は、Oracle Clusterware 12cリリース1 (12.1)のアップグレード前の状態にリストアされます。Oracle Grid Infrastructure 12cリリース1 (12.1)のアップグレードの最中または後で行った変更はすべて消去され、リカバリされません。

ダウンロード手順では、次の変数が使用されます。

- local nodeは、rootupgradeスクリプトを実行した最初のノードです。

- remote nodesは、rootupgradeスクリプトを実行したその他のすべてのノードです。

Oracle Clusterwareを以前のリリースにリストアするには、ダウングレードするリリースのダウングレード手順を使用します。

B.12.2 11gリリース2 (11.2.0.2)より前のリリースへのダウングレード

1. すべてのリモート・ノードで、コマンド構文Grid_home/crs/install/rootcrs.sh -downgradeを使用して12cリリース1 (12.1)リソースを停止し、Oracle Grid Infrastructure 12cリリース1 (12.1)スタックを停止します。

2. すべてのリモート・ノードでrootcrs.sh -downgradeスクリプトが完了した後、ローカル・ノードでコマンド構文Grid_home/crs/install/rootcrs.sh -downgrade -lastnodeを使用します。
次に例を示します。

# /u01/app/12.1.0/grid/crs/install/rootcrs.sh -downgrade  -lastnode

注意:
Oracle Grid Infrastructure 12cでは、以前のリリースのGridホームやリリース番号の場所を指定する必要がなくなりました。

3. rootupgrade.shスクリプトが正しく実行されたいずれかのクラスタ・メンバー・ノードで次を実行します。

1. Oracle Grid Infrastructureインストール所有者としてログインします。

2. 次のコマンドを使用してインストーラを開始します(ここで/u01/app/12.1.0/gridは新しい(アップグレードされた)Gridホームです)。

./runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=false ORACLE_HOME=/u01/app/12.1.0/grid

Gridホームが共有ホームの場合は、フラグ-cfsを追加します。

4. rootupgrade.shスクリプトが正しく実行されたクラスタ・メンバー・ノードで次を実行します。

1. Oracle Grid Infrastructureインストール所有者(grid)としてログインします。

2. 次のコマンドを使用してインストーラを起動します(フラグORACLE_HOMEに指定したパスは以前のOracle Clusterwareインストールのホーム・ディレクトリの場所です)。

次に例を示します。

$ cd /u01/app/12.1.0/grid/oui/bin
$ ./runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=true ORACLE_HOME=/u01/app/crs

3. 11.1以下のリリースにダウングレードする場合
Oracle Clusterware 11gリリース1 (11.1)以前のリリースにダウングレードするには、以前のリリースのOracle Clusterwareホームからroot.shを手動で実行し、手順bの完了後にダウングレードを完了させます。

クラスタの各メンバー・ノード上で順に、前のリリースのOracle Clusterwareインストールのホームからroot.shを手動で実行するようOUIから要求されます。この作業が終了したら、ダウングレードは完了です。

前のリリースのOracle Clusterwareインストールのホームからroot.shを実行することにより、Oracle Clusterwareスタックが再起動され、以前のリリースでOracle Clusterwareに前に登録されていたすべてのリソースが起動され、そして前のリリースのOracle Clusterwareスタックを実行するように古い初期化スクリプトが構成されます。

ダウングレードの完了後、クラスタ内の各ノードでoratabファイル(/etc/oratabまたは/var/opt/oracle/oratab)のOracle ASMインスタンスに対するエントリを次のように更新します。

+ASM<instance#>:<RAC-ASM home>:N

B.12.3 11gリリース2 (11.2.0.2)以上のリリースへのダウングレード

1. すべてのリモート・ノードで、コマンド構文Grid_home/crs/install/rootcrs.sh -downgradeを使用して12cリリース1 (12.1)リソースを停止し、Oracle Grid Infrastructure 12cリリース1 (12.1)スタックを停止します。

2. コマンド構文rootcrs.sh -downgradeを使用します。次に例を示します。

# /u01/app/12.1.0/grid/crs/install/rootcrs.sh -downgrade

3. すべてのリモート・ノードでrootcrs.sh -downgradeスクリプトが完了した後、ローカル・ノードでコマンド構文Grid_home/crs/install/rootcrs.sh -downgrade -lastnodeを使用します。
次に例を示します。

# /u01/app/12.1.0/grid/crs/install/rootcrs.sh -downgrade  -lastnode

注意:
Oracle Grid Infrastructure 12cリリース1 (12.1)から、以前のリリースのGridホームやリリース番号の場所を指定する必要がなくなりました。

4. rootupgrade.shスクリプトが正しく実行されたクラスタ・メンバー・ノードで次を実行します。

1. Oracle Grid Infrastructureインストール所有者としてログインします。

2. 次のコマンドを使用してインストーラを開始します(ここで/u01/app/12.1.0/gridは新しい(アップグレードされた)Gridホームです)。

$ cd /u01/app/12.1.0/grid/oui/bin
./runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=false ORACLE_HOME=/u01/app/12.1.0/grid

Gridホームが共有ホームの場合は、フラグ-cfsを追加します。

5. rootupgradeスクリプトが正しく実行されたいずれかのクラスタ・メンバー・ノードで次を実行します。

1. Oracle Grid Infrastructureインストール所有者としてログインします。

2. 次のコマンドを使用してインストーラを起動します(フラグORACLE_HOMEに指定したパスは以前のOracle Clusterwareインストールのホーム・ディレクトリの場所です)。

次に例を示します。

$ cd /u01/app/12.1.0/grid/oui/bin
$ ./runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=true ORACLE_HOME=/u01/app/crs

3. 11.2.0.2にダウングレードする場合
Oracle Clusterware 11gリリース1 (11.2.0.1)にダウングレードする場合、手順bの完了後、Oracle Clusterwareスタックを手動で起動する必要があります。

各ノードで、crsctl start crsコマンドを使用して前のリリースのOracle ClusterwareホームからOracle Clusterwareを起動します。たとえば、前のリリースのホームが/u01/app/11.2.0/gridである場合は、各ノードで次のコマンドを使用します。

/u01/app/11.2.0/grid/bin/crsctl start crs

4. 12.1.0.1にダウングレードする場合
Oracle Grid Infrastructure 12cリリース1 (12.1.0.1)をダウンロードしている場合は、次のコマンドを実行してGrid Management Databaseを構成します。

1. すべてのノードで12.1.0.1のOracle Clusterwareスタックを起動します。

2. 各ノードで、次のようにしてMGMTDBリソースを削除します。

12101_Grid_home/bin/srvctl remove mgmtdb

3. 次のように、12.1.0.1Oracleホームからサイレント・モードでDBCAを実行し、Management Databaseを作成します。

12101_Grid_home/bin/dbca -silent -createDatabase -templateName
MGMTSeed_Database.dbc -sid -MGMTDB -gdbName _mgmtdb -storageType ASM
-diskGroupName ASM_DG_NAME
-datafileJarLocation 12101_grid_home/assistants/dbca/templates -characterset AL32UTF8 -autoGeneratePasswords

4. 12101_Grid_home/bin/mgmtcaからConfiguration Assistantを実行し、Management Databaseを構成します。

C レスポンス・ファイルを使用したOracle Databaseのインストールおよび構成

この付録では、レスポンス・ファイルを使用してOracle製品をインストールおよび構成する方法について説明します。内容は次のとおりです。

- レスポンス・ファイルの機能

- レスポンス・ファイルの準備

- レスポンス・ファイルを使用したインストーラの実行

- レスポンス・ファイルを使用したNet Configuration Assistantの実行

- レスポンス・ファイルを使用したインストール後の構成

C.1 レスポンス・ファイルの機能

インストーラの起動時にレスポンス・ファイルを使用して、Oracleソフトウェアのインストールと構成を完全にまたは部分的に自動実行できます。インストーラはレスポンス・ファイルに含まれる値を使用して、一部またはすべてのインストール・プロンプトに応答します。

通常、インストーラは対話型で、つまりGraphical User Interface(GUI)画面で情報の入力を求めながら動作します。この情報をレスポンス・ファイルで提供する場合は、次のいずれかのモードで、コマンド・プロンプトからインストーラを起動します。

- サイレント・モード
レスポンス・ファイルにすべてのプロンプトへの応答を含め、インストーラの起動時に-silentオプションを指定すると、インストーラはサイレント・モードで動作します。サイレント・モードでのインストール中、インストーラは画面上に何も表示しません。かわりに、起動に使用した端末上に進捗情報を表示します。

- レスポンス・ファイル・モード
レスポンス・ファイルに一部またはすべてのプロンプトへの応答を含めて、-silentオプションを指定しないと、インストーラはレスポンス・ファイル・モードで動作します。レスポンス・ファイル・モードでのインストール中は、レスポンス・ファイルで情報を指定した画面も、レスポンス・ファイルに必要な情報を指定しなかった画面も含めて、インストーラはすべての画面を表示します。

サイレント・モードまたはレスポンス・ファイル・モードでインストールするための設定は、レスポンス・ファイルにリストされた変数に値を入力して定義します。たとえば、Oracleホームの名前を指定するには、次のように、ORACLE_HOME変数に適切な値を入力します。

ORACLE_HOME="OraDBHome1"

レスポンス・ファイルの変数設定を指定するもう1つの方法は、インストーラの起動時にコマンドライン引数として渡す方法です。次に例を示します。

-silent "ORACLE_HOME=OraDBHome1" ...

関連項目:
レスポンス・ファイルの詳細は、『Oracle Universal InstallerおよびOpatchユーザーズ・ガイドfor Microsoft Windows and UNIX Systems』を参照してください。

C.1.1 サイレント・モードまたはレスポンス・ファイル・モードを使用する理由

次の表に、インストーラをサイレント・モードまたはレスポンス・ファイル・モードで実行する場合の例を示します。

モード

用途

サイレント

サイレント・モードは次の場合に使用します。

- atなどのオペレーティング・システム・ユーティリティを使用してスケジュールを設定し、自動インストールを実行する。

- ユーザーの介入なしで、複数のシステムで同様のインストールを数回実行する。

- X Window Systemソフトウェアがインストールされていないシステムにソフトウェアをインストールする。

インストーラは起動元の端末に進捗情報を表示しますが、インストーラ画面はまったく表示しません。

レスポンス・ファイル

レスポンス・ファイル・モードは、インストーラ・プロンプトの全部ではなく一部にデフォルトの応答を提供し、複数のシステムに同様のOracleソフトウェア・インストールを行う場合に使用します。
レスポンス・ファイル・モードでは、すべてのインストーラ画面が表示されますが、これらの画面の該当フィールドには、レスポンス・ファイルによってデフォルトの値が入力されます。レスポンス・ファイルで値を指定していないものについては、画面のフィールドに情報を入力する必要があります。

C.1.2 レスポンス・ファイルの一般的な使用手順

次に、インストーラをサイレント・モードまたはレスポンス・ファイル・モードで使用して、Oracle製品をインストールし構成する一般的な手順を示します。

注意:
インストーラをサイレント・モードまたはレスポンス・ファイル・モードで実行する前に、必要なインストール前の手順をすべて終了しておく必要があります。

1. レスポンス・ファイルを準備します。

2. インストーラをサイレント・モードまたはレスポンス・ファイル・モードで実行します。

3. ソフトウェアのみのインストールを終了したら、次にNet Configuration AssistantおよびDatabase Configuration Assistantをサイレント・モードまたはレスポンス・ファイル・モードで実行します。

この手順については、次の項で説明します。

C.2 レスポンス・ファイルの準備

この項では、レスポンス・ファイルを準備して、サイレント・モードまたはレスポンス・ファイル・モードのインストールで使用する、次の方法について説明します。

- レスポンス・ファイル・テンプレートの編集

- レスポンス・ファイルの記録

C.2.1 レスポンス・ファイル・テンプレートの編集

Oracleでは、各製品およびインストール・タイプと各構成ツールに対応する、レスポンス・ファイルのテンプレートを提供しています。ファイルは、インストール・メディアのdatabase/responseディレクトリに格納されています。

注意:
ソフトウェアをハード・ディスクにコピーした場合、レスポンス・ファイルは/responseディレクトリにあります。

表C-1に、このソフトウェアに付属するレスポンス・ファイルを示します。

表C-1 Oracle Databaseのレスポンス・ファイル

レスポンス・ファイル

説明

db_install.rsp

Oracle Database 11g のサイレント・インストール

dbca.rsp

Database Configuration Assistantのサイレント・インストール

netca.rsp

Oracle Net Configuration Assistantのサイレント・インストール

表C-2 Oracle Grid Infrastructureのレスポンス・ファイル

レスポンス・ファイル

説明

grid_install.rsp

Oracle Grid Infrastructureインストール環境のサイレント・インストール

注意:
レスポンス・ファイル・テンプレートを変更し、保存して使用する場合、レスポンス・ファイルに暗号化されていないパスワードが含まれている場合があります。レスポンス・ファイルの所有者はOracleソフトウェア・インストール所有者のみとし、レスポンス・ファイルの権限を600に変更してください。データベース管理者またはその他の管理者には、使用していないレスポンス・ファイルを削除または保護することをお薦めします。

レスポンス・ファイルをコピーして変更するには、次の手順を実行します。

1. レスポンス・ファイル・ディレクトリからシステム上のディレクトリに、レスポンス・ファイルをコピーします。

$ cp /directory_path/response/response_file.rsp local_directory

この例では、directory_pathはインストール・メディアのdatabaseディレクトリのパスです。ソフトウェアをハード・ドライブにコピーしている場合は、必要に応じてresponseディレクトリ内のファイルを編集することも可能です。

2. テキスト・エディタでレスポンス・ファイルを開きます。

$ vi /local_dir/response_file.rsp

関連項目:
レスポンス・ファイルの生成の詳細は、『Oracle Universal InstallerおよびOpatchユーザーズ・ガイドfor Microsoft Windows and UNIX Systems』を参照してください。

3. ファイルに記載された説明に従って編集します。

注意:
レスポンス・ファイルを正しく構成しないと、インストーラまたはコンフィギュレーション・アシスタントが失敗します。

4. ファイルの権限を600に変更します。

$ chmod 600 /local_dir/response_file.rsp

注意:
Oracle Databaseのインストールに必要なすべての項目を指定したレスポンス・ファイルには、データベース管理アカウント用のパスワードと、OSDBAグループのメンバーであるユーザー用のパスワード(自動バックアップに必要)が含まれています。Oracleソフトウェア所有者であるユーザーのみがレスポンス・ファイルを参照または変更できるようにするか、インストールの正常終了後にレスポンス・ファイルを削除することを検討してください。

C.2.2 レスポンス・ファイルの記録

インストーラを対話モードで使用してレスポンス・ファイルに記録し、このファイルを編集して完全なサイレント・モードまたはレスポンス・ファイル・モードのインストールに使用できます。この方法は、カスタム・インストールまたはソフトウェアのみのインストールに役立ちます。

Oracle Database 11g リリース2(11.2)以降では、「サマリー」ページで「レスポンス・ファイルの保存」をクリックすると、インストール中のすべてのインストール手順をレスポンス・ファイルに保存できます。生成されたレスポンス・ファイルは、後でサイレント・インストールに使用できます。

レスポンス・ファイルを記録する際は、インストールを最後まで実行することも、またはシステムにソフトウェアをコピーする前に「サマリー」ページで終了することもできます。

レスポンス・ファイル・モードのインストール中に記録モードを使用すると、インストーラは元のレスポンス・ファイルに指定されていた変数値を新しいレスポンス・ファイルに記録します。

注意:
Oracle Universal Installerは、レスポンス・ファイルにパスワードを記録しません。

レスポンス・ファイルを記録するには、次の手順を実行します。

1. 通常のインストールと同様にインストール前の作業を実行します。

2. Oracle Grid Infrastructureソフトウェア所有者ユーザー(通常はgrid)が、インストーラ実行時に指定するOracleホームのパスに対して作成または書込みの権限を持っていることを確認します。

3. インストールの各画面で、必要な情報を指定します。

4. インストーラの「サマリー」画面が表示されたら、次の手順を実行します。

1. 「レスポンス・ファイルの保存」をクリックして、値をレスポンス・ファイルに保存するためのファイル名と場所を指定し、「保存」をクリックします。

2. レスポンス・ファイルを作成してインストールを継続するには、「終了」をクリックします。
レスポンス・ファイルを作成するだけでインストールを継続しない場合は、「レスポンス・ファイルの保存」をクリックした後、「取消」をクリックします。インストールは中断されますが、入力した設定はレスポンス・ファイルに記録されます。

5. 保存したレスポンス・ファイルを別のシステムで使用する前に、ファイルを編集して必要な変更を加えます。
編集する際は、ファイルに記載された説明をガイドとして使用してください。

C.3 レスポンス・ファイルを使用したインストーラの実行

コマンドラインでOracle Universal Installerを実行し、作成したレスポンス・ファイルを指定します。Oracle Universal Installerの実行可能ファイルrunInstallerでは、いくつかのオプションを使用できます。すべてのオプションのヘルプ情報を参照するには、runInstallerコマンドで-helpオプションを指定します。次に例を示します。

$ directory_path/runInstaller -help

しばらくすると、ウィンドウ上にヘルプ情報が表示されます。

レスポンス・ファイルを使用してインストーラを実行するには、次の手順を実行します。

1. 通常のインストールと同様にインストール前の作業を実行します。

2. ソフトウェア・インストール所有者ユーザーとしてログインします。

3. レスポンス・ファイル・モードでインストールを実行する場合は、DISPLAY環境変数を設定します。

注意:
サイレント・モードでインストールを実行する場合は、DISPLAY環境変数を設定する必要はありません。

4. コマンドを次のように入力して、サイレント・モードまたはレスポンス・ファイル・モードでインストーラを起動します。

$ /directory_path/runInstaller [-silent] [-noconfig] \
-responseFile responsefilename

注意:
レスポンス・ファイルのパスを相対パスで指定しないでください。相対パスを指定すると、インストーラが失敗します。

この例の意味は次のとおりです。

- directory_pathは、インストール・メディアのパス、またはインストール・バイナリをコピーしたハード・ドライブ上のディレクトリのパスです。

- -silentは、インストーラをサイレント・モードで実行します。

- -noconfigを指定すると、インストール中にコンフィギュレーション・アシスタントは実行されず、ソフトウェアのみのインストールが実行されます。

- responsefilenameは、構成したインストール用レスポンス・ファイルのフルパスとファイル名です。

5. インストールが終了したら、rootユーザーとしてログインし、root.shスクリプトを実行します。次に例を示します。

$ su root
password:
# /oracle_home_path/root.sh

C.4 レスポンス・ファイルを使用したNet Configuration Assistantの実行

サイレント・モードでNet Configuration Assistantを実行して、システム上でOracle Net Listenerを構成して起動し、ネーミング・メソッドを構成し、Oracleネット・サービス名を構成できます。Net Configuration Assistantをサイレント・モードで実行するには、レスポンス・ファイル・テンプレートをコピーして編集する必要があります。Oracleでは、DVD上のdatabase/responseディレクトリのresponseディレクトリで、netca.rspという名前のレスポンス・ファイル・テンプレートを提供しています。

注意:
ソフトウェアをハード・ディスクにコピーした場合、レスポンス・ファイル・テンプレートはdatabase/responseディレクトリに格納されています。

レスポンス・ファイルを使用してNet Configuration Assistantを実行するには、次の手順を実行します。

1. レスポンス・ファイル・テンプレートnetca.rspを、レスポンス・ファイルのディレクトリから使用するシステムのディレクトリへコピーします。

$ cp /directory_path/response/netca.rsp local_directory

この例では、directory_pathはDVDのdatabaseディレクトリのパスです。ソフトウェアをハード・ドライブにコピーした場合は、responseディレクトリのファイルを編集することもできます。

2. テキスト・エディタでレスポンス・ファイルを開きます。

$ vi /local_dir/netca.rsp

3. ファイルに記載された説明に従って編集します。

注意:
レスポンス・ファイルを正しく構成しないと、Net Configuration Assistantが失敗します。

4. Oracleソフトウェア所有者ユーザーとしてログインし、ORACLE_HOME環境変数に正しいOracleホーム・ディレクトリを指定します。

5. 次のようなコマンドを入力して、Net Configuration Assistantをサイレント・モードで実行します。

$ $ORACLE_HOME/bin/netca /silent /responsefile /local_dir/netca.rsp

この例の意味は次のとおりです。

- /silentオプションは、Net Configuration Assistantをサイレント・モードで実行することを意味します。

- local_dirは、netca.rspレスポンス・ファイル・テンプレートのコピー先ディレクトリのフルパスです。

C.5 レスポンス・ファイルを使用したインストール後の構成

Oracleソフトウェアのインストール後にレスポンス・ファイルによる構成を作成して実行するには、次の項の手順を使用します。

C.5.1 インストール後の構成ファイルについて

サイレント・モードまたはレスポンス・ファイル・モードでのインストールを実行する場合は、使用するサーバーについての情報をレスポンス・ファイルに指定します。指定しない情報は、Graphical User Interfaceによるインストール中に手動で入力します。ただし、レスポンス・ファイルには、ソフトウェアのインストール後にコンフィギュレーション・アシスタントから要求されるユーザー・アカウントのパスワードは含まれていません。コンフィギュレーション・アシスタントは、configToolAllCommandsというスクリプトによって起動されます。パスワード・レスポンス・ファイルを作成して使用すると、このスクリプトをレスポンス・ファイル・モードで実行できます。スクリプトはこのパスワードを使用して、構成が完了するまで連続的に構成ツールを実行します。

クローン・インストール用にこのパスワード・ファイルを保持する場合は、セキュアな場所に保存することをお薦めします。また、エラーを解決するためにインストールを中断する必要がある場合も、configToolAllCommandsおよびパスワード・レスポンス・ファイルを使用して、コンフィギュレーション・アシスタントを実行できます。

configToolAllCommandsパスワード・レスポンス・ファイルには、次の構文オプションがあります。

- internal_component_nameは、コンフィギュレーション・アシスタントで構成するコンポーネントの名前です。

- variable_nameは、構成ファイルの変数の名前です。

- valueは、構成に使用する値です。

コマンド構文は次のとおりです。

internal_component_name|variable_name=value

次に例を示します。

oracle.assistants.asm|S_ASMPASSWORD=welcome

パスワード・レスポンス・ファイルのセキュリティは、次の方法で維持することをお薦めします。

- レスポンス・ファイルの権限を600に設定します。

- レスポンス・ファイルの所有者をインストール所有者ユーザーにして、グループは中央インベントリ(oraInventory)グループに設定します。

C.5.2 レスポンス・ファイルを使用したインストール後の構成の実行

configToolAllCommandsスクリプトを使用してコンフィギュレーション・アシスタントを実行するには、次の手順を実行します。

1. 構文filename.propertiesを使用してレスポンス・ファイルを作成します。次に例を示します。

$ touch cfgrsp.properties

2. テキスト・エディタでこのファイルを開き、パスワード・テンプレートを切り取って貼り付け、必要に応じて変更します。

例C-1 クラスタ用Oracle Grid Infrastructureインストールのパスワード・レスポンス・ファイル

Oracle Grid Infrastructureには、Oracle Automatic Storage Management Configuration Assistant (ASMCA)のパスワードが必要です。また、BMCカードがある場合にその機能を有効にするには、Intelligent Platform Management Interface Configuration Assistant(IPMICA)のパスワードが必要になります。この場合、次のレスポンス・ファイルを使用します。

oracle.assistants.asm|S_ASMPASSWORD=password
oracle.assistants.asm|S_ASMMONITORPASSWORD=password
oracle.crs|S_BMCPASSWORD=password

BMCカードがない場合、またはIPMIを有効にしない場合は、S_BMCPASSWORD入力フィールドを空白のままにしておきます。

例C-2 Oracle Real Application Clustersのパスワード・レスポンス・ファイル

Oracle Databaseの構成には、Database Configuration Assistant(DBCA)で使用するSYS、SYSTEM、SYSMAN、DBSNMPのパスワードの構成が必要です。また、Oracle ASMストレージを使用する場合は、ASMSNMPパスワードを構成します。また、Oracle Enterprise Managerの構成を選択した場合は、S_HOSTUSERPASSWORDレスポンスにOracleソフトウェア・インストール所有者のパスワードを指定する必要があります。

oracle.assistants.server|S_SYSPASSWORD=password
oracle.assistants.server|S_SYSTEMPASSWORD=password
oracle.assistants.server|S_SYSMANPASSWORD=password
oracle.assistants.server|S_DBSNMPPASSWORD=password
oracle.assistants.server|S_HOSTUSERPASSWORD=password
oracle.assistants.server|S_ASMSNMPPASSWORD=password

Oracle Enterprise ManagerまたはOracle ASMを有効にしない場合、これらのパスワード・フィールドは空白のままにします。

3. 権限を変更してファイルを保護します。次に例を示します。

$ ls -al cfgrsp.properties
-rw------- 1 oracle oinstall 0 Apr 30 17:30 cfgrsp

4. $ORACLE_HOME/cfgtoollogsに移動し、次の構文を使用して構成スクリプトを実行します。
configToolAllCommands RESPONSE_FILE=/path/name.properties

次に例を示します。

$ ./configToolAllCommands RESPONSE_FILE=/home/oracle/cfgrsp.properties

D クラスタ用Oracle Grid Infrastructureのインストールの概要

この付録では、インストール前に実行を要求される作業の理由、およびその他のインストールの概要について説明します。

この付録の内容は次のとおりです。

- インストール前の構成の理解

- ネットワーク・アドレスの理解

- ネットワークの時刻要件の理解

- Oracle Flex ClusterおよびOracle ASM Flexクラスタの理解

- 記憶域の構成の理解

- アウトオブプレース・アップグレードの理解

D.1 インストール前の構成の理解

この項では、クラスタ用Oracle Grid Infrastructureのインストール前に必要な作業の概要を確認します。内容は次のとおりです。

- Oracle Grid Infrastructureに関するOptimal Flexible Architectureガイドライン

- クラスタ用Oracle Grid InfrastructureとOracle Restart用Oracle Grid Infrastructureの違い

- Oracle Inventoryグループの理解

- Oracle Inventoryディレクトリの理解

- Oracleベース・ディレクトリの理解

- Oracle Grid Infrastructureソフトウェア用Oracleホームの理解

- OracleベースおよびOracle Grid Infrastructureソフトウェアのディレクトリの場所

D.1.1 Oracle Grid Infrastructureに関するOptimal Flexible Architectureガイドライン

Oracle Grid Infrastructureのみをインストールする場合は、Oracle Optimal Flexible Architecture(OFA)に準拠したOracleベースおよびGridホームのパスを作成して、Oracle Universal Installer(OUI)がインストール中にそのディレクトリを選択できるようにすることをお薦めします。OUIがパスをOracleソフトウェア・パスとして認識するには、u[0-9][1-9]/appという形式にする必要があります。

OracleベースのOFAパスは、u[0-9][1-9]/app/user,であり、ここでのuserは、Oracleソフトウェア・インストールの所有者アカウントの名前です。

Oracle Grid Infrastructure OracleホームのOFAパスは、u[0-9][1-9]/app/release/gridであり、ここでのreleaseは3桁のOracle Grid Infrastructureリリースです(例: 12.1.0)。

OUIはOFA準拠のソフトウェア・パス(u[0-9][1-9]/app)を検出すると、Oracle Grid Infrastructure GridホームおよびOracleインベントリ(oraInventory)ディレクトリを作成します。たとえば、パス/u01/appおよび/u89/appはOFAに準拠したパスです。

Oracle Grid Infrastructureホームは、Oracle Grid Infrastructureインストール所有者のGridホームとは異なるパスにある必要があります。Oracle Grid Infrastructureベース・パスを手動で作成する場合、このリリース専用の個別のパスであることと、既存のOracleベース・パスの下にないことを確認します。

注意:
Oracle Grid Infrastructureホームを手動で作成する場合は、クラスタのOracle Grid Infrastructureホームを、Oracle Grid Infrastructureインストール所有者(grid)のOracleベースや、Oracle Databaseインストール所有者(oracle)のOracleベースに作成しないでください。Oracleベース・ディレクトリにOracle Clusterwareインストールを作成すると、その後のOracleインストールが失敗します。
Oracle Grid Infrastructureホームは、以前のリリースの既存のOracle Clusterwareホームが共有された場所にある場合でも、サーバーのローカル・ホームに配置できます。

D.1.2 クラスタ用Oracle Grid InfrastructureとOracle Restart用Oracle Grid Infrastructureの違い

クラスタ用Oracle Grid Infrastructureの要件は、Oracle Restart構成の単一インスタンスのOracle Grid Infrastructureとは異なります。

関連項目:
Oracle Restartの要件の詳細は、『Oracle Databaseインストレーション・ガイド』を参照してください。

D.1.3 Oracle Inventoryグループの理解

メンバーにOracle Inventory(oraInventory)ディレクトリへの書込み権が付与されたグループを所有する必要があります。このディレクトリは、サーバー上のすべてのOracleソフトウェア・インストールの中央インベントリ・レコードです。このグループのメンバーはOracle中央インベントリ(oraInventory)ディレクトリに対する書込み権限を所有します。また、様々なOracle Clusterwareリソース、OCRキー、DBAが書込み権限を必要とするOracle Clusterwareホーム内のディレクトリに対する権限やその他の必要な権限が付与されます。このグループのデフォルトはoinstallです。Oracle Inventoryグループは、Oracleソフトウェアのインストール所有者のプライマリ・グループである必要があります。

oraInventoryディレクトリには、次のものが含まれています。

- システム上のOracleホーム・ディレクトリ(Oracle Grid InfrastructureおよびOracle Database)のレジストリ。

- Oracleソフトウェアのインストール時のインストール・ログおよびトレース・ファイル。これらのファイルは、将来参照するためにそれぞれのOracleホームにもコピーされます。

- Oracleインストールに関するその他のメタデータ・インベントリ情報は、個々のOracleホーム・インベントリ・ディレクトリに格納されており、中央インベントリとは分離されています。

1つのグループをアクセス制御グループとして構成し、Oracle Inventory、データベース管理者(OSDBA)、およびOracleソフトウェアがオペレーティング・システムの認証に使用する他のすべてのアクセス制御グループに適用できます。ただし、すべてのシステム権限のオペレーティング・システム認証の提供に1つのグループを使用する場合、このグループは、管理システム権限を付与する対象のすべてのユーザーに対するプライマリ・グループである必要があります。

注意:
Oracleソフトウェアがすでにシステムにインストールされている場合は、既存のOracle Inventoryグループが、Oracle Grid Infrastructureのインストールに使用するオペレーティング・システム・ユーザー(oracleまたはgrid)のプライマリ・グループである必要があります。既存のOracle Inventoryグループを確認するには、第5.1.1項「Oracle InventoryおよびOracle Inventoryグループの存在の確認」を参照してください。

D.1.4 Oracle Inventoryディレクトリの理解

Oracle Inventoryディレクトリ(oraInventory)には、サーバーにインストールされたすべてのOracleソフトウェア用の中央インベントリがあります。各クラスタ･メンバー･ノードには、固有の中央インベントリ・ファイルがあります。共有のOracle Inventoryディレクトリを持つことはできません(ノードにインストールされているすべてのOracleソフトウェアのインストール済Oracleホームを指すために使用されるため)。

Oracleソフトウェアをシステムにはじめてインストールする場合は、oraInventoryディレクトリのパスを入力するように求められます。

oraInventoryグループが存在しない場合、デフォルトでは、クラスタ用Oracle Grid Infrastructureソフトウェアのインストール所有者のプライマリ・グループが、oraInventoryグループとして表示されます。使用するOracleソフトウェア・インストール所有者のすべてが、このグループをプライマリ・グループとして利用できることを確認します。

すべてのOracleインストール所有者のプライマリ・グループは、メンバーにサーバーの中央Oracle Inventoryへの書込みやログ・ファイルの書込みができるOINSTALLシステム権限などの権限が付与される、Oracle Inventoryグループ(oinstall)である必要があります。

注意:
クラスタ内のすべてのノードで、グループIDおよびユーザーIDが一致している必要があります。使用するグループIDおよびユーザーIDが各クラスタ・メンバー・ノードで使用できることを確認し、クラスタ用Oracle Grid Infrastructureの各インストール所有者のプライマリ・グループが、同じ名前とグループIDであることを確認します。

インストール所有者のプライマリ・グループが、ユーザーのホーム・ディレクトリ(/home/oracleなど)である場合、Oracle Inventoryはインストール所有者のホーム・ディレクトリに格納されます。この配置によって、複数のOracleソフトウェア所有者で後続のインストールを行うときに権限エラーが発生する可能性があります。そのため、このオプションを受け入れずにOFA準拠のパスを使用することをお薦めします。

Oracleベースの変数を/u01/app/gridや/u01/app/oracleなどのパスに設定すると、Oracle Inventoryは、デフォルトでパスu01/app/oraInventoryになり、すべてのOracleインストール所有者がこの中央インベントリ・ディレクトリに書込みができるように正しい権限を使用するようになります。

デフォルトでは、Oracle Inventoryディレクトリはインストール所有者のOracleベース・ディレクトリ下にはインストールされません。これは、すべてのOracleソフトウェア・インストールが同じOracle Inventoryを共有し、1つしかないOracle Inventoryをすべてのユーザーが使用するためです。一方、Oracleベースは各ユーザーに個別に存在します。

D.1.5 Oracleベース・ディレクトリの理解

インストール時に、Oracleベースの場所を指定するように求められます。Oracleベースは、インストールを実行するユーザーが所有します。Oracleベース・ディレクトリは、ユーザーに固有のログ・ファイルが配置される場所です。既存のOracleホームが含まれるディレクトリを選択するか、またはOracleベース・ディレクトリの構造を持っていない別のディレクトリを選択できます。

Oracleベース・ディレクトリ・パスを使用すると、Oracleインストールの構造が簡略化され、複数のデータベース・インストールでOptimal Flexible Architecture(OFA)構成を保持しやすくなります。

Oracle Grid InfrastructureインストールのOracleベース・ディレクトリは、Oracle ASMおよびOracle Clusterwareに関する診断ログ、管理ログおよびその他のログが格納される場所です。クラスタのOracle Grid Infrastructureを除くOracleインストールの場合、Oracleホームが配置される場所でもあります。

ただし、Oracle Grid Infrastructureインストールの場合は、別のパスを作成し、Oracleベースのパスをその他のOracleインストールが使用できるようにする必要があります。

OUIがOracleベース・パスを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インストールは1つのみで、すべてのアップグレードがホーム外アップグレードであるため、Grid Infrastructureソフトウェア所有者(grid)用のOracleベースを作成し、そのインストールのリリース番号を使用して、Oracle Grid Infrastructureバイナリ用のOracleホームを作成することをお薦めします。

D.1.6 Oracle Grid Infrastructureソフトウェア用Oracleホームの理解

Oracle Grid Infrastructureソフトウェア用Oracleホーム(Gridホーム)は、u[00-99][00-99]/app/release/grid (releaseはOracle Grid Infrastructureソフトウェアのリリース番号)形式のパスにある必要があります。次に例を示します。

/u01/app/12.1.0/grid

インストール中に、Gridホームへのパスの所有権がrootに変更されます。Gridホームへの一意のパスを作成しない場合は、グリッドのインストール後に、同じパスにある既存のインストールを含むその他のインストールの権限エラーが発生します。

Oracle Grid Infrastructureソフトウェアの場所(Gridホーム)に指定するディレクトリ・パスが次の要件を満たすことを確認します。

- インストール前にパスを作成する場合は、Oracle Grid Infrastructureのインストール所有者(通常、すべてのOracleソフトウェアに対して1つのインストール所有者の場合はoracle、ロール・ベースのOracleインストール所有者の場合はgrid)が所有し、権限が775に設定されている必要があります。

- Oracle Clusterwareホームを含む、既存のOracleホーム以外のパスに作成する必要があります。

- ユーザー・ホーム・ディレクトリには作成できません。

- Oracle Grid Infrastructureインストール所有者のOracleベース(grid)または他のOracleインストール所有者のOracleベース(/u01/app/oracleなど)と異なる場所である必要があります。

- すべてのファイルをrootによって所有可能なパス内のサブディレクトリとして作成するか、一意のパス内に作成します。

Oracle Grid Infrastructureバイナリを、共有ストレージの共有ホームを使用するのではなく、ローカル・ホームにインストールすることをお薦めします。

D.1.7 OracleベースおよびOracle Grid Infrastructureソフトウェアのディレクトリの場所

Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)のインストールとOracle Databaseのインストールに同じソフトウェア所有者を使用しない場合でも、Oracle Grid Infrastructureのインストールでroot.shスクリプトを実行することによって、クラスタウェア・バイナリが配置されるホーム・ディレクトリの所有権がrootに変更されることに注意してください。また、ルート・レベル(/)までのすべての祖先ディレクトリもrootに変更されます。このため、クラスタ用Oracle Grid Infrastructureのホームは、他のOracleソフトウェアと同じ場所に置くことができません。

ただし、Oracle Restartは他のOracleソフトウェアと同じ場所に置くことができます。

関連項目:
Oracle Restartの詳細は、使用しているプラットフォームのOracle Databaseインストレーション・ガイドを参照してください。

D.2 ネットワーク・アドレスの理解

インストール時に、OUIがクラスタ・ノードで検出するネットワーク・インタフェースごとに計画された使用方法を指定するように求められます。各インタフェースを、パブリック・インタフェースまたはプライベート・インタフェース、あるいはOracle Grid InfrastructureやOracle Flex ASMクラスタで使用しないインタフェースとして指定します。パブリックIPアドレスと仮想IPアドレスは、パブリック・インタフェース上に構成されます。プライベート・アドレスはプライベート・インタフェース上に構成されます。

各アドレス・タイプの詳細は、次の項を参照してください。

- パブリックIPアドレスについて

- プライベートIPアドレスについて

- 仮想IPアドレスについて

- グリッド・ネーミング・サービス(GNS)の仮想IPアドレスについて

- Oracle Grid InfrastructureインストールのSCANについて

D.2.1 パブリックIPアドレスについて

パブリックIPアドレスは、DHCPを使用して動的に割り当てられるか、DNSまたはホスト・ファイルで静的に定義されます。パブリック・インタフェース(クライアントからアクセス可能なインタフェース)が使用されます。パブリックIPアドレスは、クラスタ･メンバー･ノードのプライマリ・アドレスであり、コマンドhostnameを入力したときに返される名前に解決されるアドレスである必要があります。

IPアドレスを手動で構成した場合は、Oracle Grid Infrastructureをインストールした後で、ドメイン修飾子の追加や削除も含め、ホスト名を変更しないでください。新しいホスト名を持つノードは、新しいホストと見なされるので、クラスタに追加する必要があります。古い名前のノードは、クラスタから削除されるまで、停止状態で表示されます。

D.2.2 プライベートIPアドレスについて

Oracle Clusterwareは、プライベートとマークされたインタフェースを使用してノード間通信を行います。各クラスタ・ノードは、インストール時にプライベート・インタフェースとして指定されたインタフェースを持つ必要があります。プライベート・インタフェースはそのインタフェース用に構成されたアドレスを持つ必要がありますが、それ以上の構成は必要ありません。Oracle Clusterwareは、プライベートと指定されたインタフェースを、クラスタ・インターコネクトとして使用します。プライベート・ネットワークに関する情報に複数のインタフェースを指定すると、Oracle Clusterwareはそれらを冗長インターコネクトを使用して構成します。プライベートとして指定するインタフェースはいずれも、クラスタのすべてのノードに接続するサブネット上に存在しなければなりません。Oracle Clusterwareは、プライベート・インタフェース用に指定された、すべてのインタフェースを使用します。

プライベート・インターコネクトの場合は、ノード間のキャッシュ・フュージョンおよびその他のトラフィックのため、物理的に別のプライベート・ネットワークを使用することをお薦めします。DNSを使用してアドレスを構成する場合は、プライベートIPアドレスがクラスタ・ノードからのみ到達可能であることを確認する必要があります。

インストール後、CLUSTER_INTERCONNECTS初期化パラメータを使用してOracle RACのインターコネクトを変更する場合は、パブリックIPアドレスで使用されていないサブネット上で、パラメータをプライベートIPアドレスに変更する必要があります。パブリック・サブネットとして指定したサブネットを使用するインタフェースにインターコネクトを変更することはできません。

プライベート・ネットワークIPアドレスを使用したネットワークではファイアウォールを使用しないでください。プライベート・ネットワークIPアドレスによってインターコネクト・トラフィックがブロックされる可能性があるためです。

D.2.3 仮想IPアドレスについて

グリッド・ネーミング・サービス(GNS)を使用していない場合は、各ノードに仮想ホスト名を指定します。仮想ホスト名は、パブリック・ノード名で、ノードが停止している場合にノードに送信されるクライアントの要求を再ルーティングするために使用されます。Oracle Databaseでは、クライアントとデータベース間の接続にVIPを使用するため、VIPアドレスはパブリックにアクセス可能である必要があります。名前はhostname-vip形式で指定することをお薦めします。たとえば、myclstr2-vipです。

仮想IP(VIP)アドレスは、GNSまたはDNSに登録されています。次の要件を満たすVIPのアドレスを選択します。

- IPアドレスとホスト名は、現在未使用である(DNSに登録できるが、pingコマンドでアクセスできない)

- VIPはパブリック・インタフェースと同じサブネット上にある

D.2.4 グリッド・ネーミング・サービス(GNS)の仮想IPアドレスについて

GNS仮想IPアドレスは、DNSで構成される静的なIPアドレスです。DNSはGNS仮想IPアドレスに問合せを委任し、GNSデーモンはそのアドレスで、受信した名前解決要求に応答します。

GNSは、Oracle Clusterwareで提供されるマルチキャスト・ドメイン・ネーム・サービス(mDNS)をサブドメイン内で使用し、クラスタにノードが追加または削除されると、ホスト名およびIPアドレスを動的にマップできるようにします。DNSで新たにホスト構成を行う必要はありません。

GNSを有効にするには、クラスタに割り当てられたサブドメインのIPアドレス(grid.example.comなど)をネットワーク管理者に教えてもらい、そのサブドメインへのDNS要求を、クラスタのGNS仮想IPアドレスに委任してもらう必要があります。GNSはそのアドレスで機能します。一連のIPアドレスはDHCP経由でクラスタに提供されます。これらのアドレスは、クラスタのパブリック・ネットワーク上で使用できる状態でなくてはなりません。

関連項目:
グリッド・ネーミング・サービスの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

D.2.5 Oracle Grid InfrastructureインストールのSCANについて

Oracle Databaseクライアントは、SCANを使用してOracle Real Application Clustersデータベースに接続します。SCANとそれに関連付けられたIPアドレスは、クラスタを構成するノードとは無関係に、クライアントが接続に使用する安定した名前を提供します。SCANアドレス、仮想IPアドレス、およびパブリックIPアドレスはすべて、同じサブネット上に存在する必要があります。

SCANは、node1-vipのような、仮想IPアドレスに使用される名前に類似した仮想IP名です。ただし、仮想IPと異なり、SCANは個別のノードではなくクラスタ全体と関連付けられており、1つではなく複数のIPアドレスと関連付けられています。

SCANは、パブリック・クライアント接続を処理するクラスタ内の複数のIPアドレスに解決可能であることで機能します。クライアントから要求が送信されると、SCAN IPアドレスおよびSCANポート上でリスニングしているSCANリスナーがクライアントから使用できるようになります。クラスタ上のすべてのサービスがSCANリスナーに登録されているため、SCANリスナーは、現在サービスを提供している最も負荷が低いノードのローカル・リスナー・アドレスを使用して応答します。最後に、サービスが提供されているノード上のリスナーを通じて、クライアントがサービスへの接続を確立します。これらすべての動作はクライアントに対して透過的に行われ、クライアントでの明示的な構成は必要ありません。

インストール中にリスナーが作成されます。リスナーは、SCAN IPアドレス用のノードに指定されたSCAN IPアドレスをリスニングします。Oracle Net Servicesは、サービスを提供している最も負荷が低いインスタンスに、アプリケーションの要求をルーティングします。SCANアドレスはクラスタ内のノード・アドレスではなくクラスタに解決されるため、SCANアドレス構成に影響を与えることなく、クラスタでノードを追加または削除できます。

SCANは、クラスタ内のグリッド・ネーミング・サービス(GNS)、またはドメイン・ネーム・サービス(DNS)解決のいずれかで解決できるように構成する必要があります。高い可用性とスケーラビリティを実現するために、3つのIPアドレスに解決されるようにSCAN名を構成することをお薦めします。SCANは少なくとも1つのアドレスに解決される必要があります。

GNSドメインを指定する場合、SCAN名のデフォルトはclustername-scan.GNS_domainです。指定しない場合のデフォルトはclustername-scan.current_domainです。たとえば、Oracle Grid Infrastructureインストールをサーバーnode1から起動し、クラスタ名がmycluster、GNSドメインがgrid.example.comの場合、SCAN名はmycluster-scan.grid.example.comです。

Oracle Database 11g リリース2より前のOracle DatabaseリリースのIPアドレスを使用するように構成されたクライアントは、既存の接続アドレスを引き続き使用できるため、SCANを使用する必要はありません。Oracle Clusterware 12cリリース1 (12.1)にアップグレードするとSCANが有効になり、Oracle Database 11gリリース2以上のデータベースへの接続にSCANが必要になります。以前のバージョンのOracle DatabaseをアップグレードするとSCANリスナーに登録されるため、クライアントがSCANを使用してそのデータベースに接続できるようになります。データベースはinit.oraファイルのリモート・リスナー・パラメータを通じてSCANリスナーに登録されます。REMOTE_LISTENERパラメータは、SCAN:PORT形式で設定する必要があります。HOST=SCANとしてSCANが指定された1つのアドレスのTNSNAMES別名は設定しないでください。

SCANはほとんどのデプロイメントでオプションです。ただし、Oracle Database 11gリリース2以上でサーバー・プールを使用しているポリシー管理データベースを使用しているクライアントは、SCANを使用してデータベースにアクセスする必要があります。これは、ポリシー型管理のデータベースは異なるサーバーで異なる時刻に実行されることがあるためです。そのため、あるポリシー型管理のデータベースの特定ノードの仮想IPアドレスへの接続はできません。

クラスタへのクライアント・アクセス用のSCANアドレスを指定します。このアドレスは、ドメイン・ネーム・サービス(DNS)にラウンド・ロビン・アドレスとして構成してください。SCANアドレスは、3つ指定することをお薦めします。

注意:
次に、ノードIPアドレスに関する追加情報を示します。

- ローカル・ノードの場合のみ、OUIによってパブリックおよびVIPフィールドが自動的に書き込まれます。システムでベンダーのクラスタウェアが使用されている場合は、OUIにより追加のフィールドが書き込まれることがあります。

- ホスト名および仮想ホスト名は、ドメイン修飾されません。インストール中にアドレス・フィールドにドメインを入力すると、そのドメインは、OUIによってアドレスから削除されます。

- プライベートIPアドレス用にプライベートとして指定したインタフェースは、パブリック・インタフェースとしてアクセスできないようにする必要があります。キャッシュ・フュージョンにパブリック・インタフェースを使用すると、パフォーマンスの問題が発生する可能性があります。

パブリック・インタフェースおよびプライベート・インタフェースを指定します。OUIは、パブリックIPアドレスおよび仮想IPアドレスによって使用されるようにパブリック・インタフェースを構成し、プライベートIPアドレスをプライベート・インタフェース上に構成します。

プライベート・インタフェースが使用するプライベート・サブネットは、クラスタ・メンバーにする予定のすべてのノードに接続する必要があります。

D.3 ネットワークの時刻要件の理解

Oracle Clusterware 12cリリース1 (12.1)には、クラスタ時刻同期化サービス(CTSS)が自動的に構成されます。このサービスでは、デプロイしたクラスタのタイプに最適な同期方法で、すべてのクラスタ・ノードが自動的に同期されます。NTPなどの既存のクラスタ時刻同期化サービスがある場合、このサービスはオブザーバ・モードで開始されます。それ以外の場合は、アクティブ・モードで開始され、クラスタ・ノード間の時刻の同期を確実にします。CTSSで互換性の問題が発生することはありません。

CTSSモジュールはOracle Grid Infrastructureのインストールの一環としてインストールされます。CTSSデーモンはOHASデーモン(ohasd)によって起動されるため、コマンドライン・インタフェースは必要ありません。

D.4 Oracle Flex ClusterおよびOracle ASM Flexクラスタの理解

Oracle Flex Cluster構成でインストールされるOracle Grid Infrastructureは、スケーラブルで動的、強固なノード・ネットワークです。Oracle Flex Clusterでは、高可用性のために調整および自動化が必要な他のサービス・デプロイメントのプラットフォームも提供されます。

Oracle Flex Cluster内のすべてのノードは、単一のOracle Grid Infrastructureクラスタに属します。このアーキテクチャでは、様々なサービス・レベル、負荷、障害のレスポンス、およびリカバリに対処するために、アプリケーション・ニーズに基づいてリソースのデプロイメントに対するポリシー決定が集中管理されます。

Oracle Flex Clusterには、ハブおよびスポーク・アーキテクチャに配置される2つのタイプのノード(ハブ・ノードおよびリーフ・ノード)が含まれます。Oracle Flex Cluster内のハブ・ノードの最大数は64です。リーフ・ノードの数は、さらに多くできます。ハブ・ノードおよびリーフ・ノードでは、様々なタイプのアプリケーションをホストできます。

Oracle Flex Clusterのハブ・ノードは、密接に接続されて共有記憶域に直接アクセスできる点が、標準構成のOracle Grid Infrastructureノードに類似しています。

リーフ・ノードは、共有記憶域への直接アクセスが必要ない点で、標準のOracle Grid Infrastructureノードと異なります。ハブ・ノードは、リーフ・ノードをクラスタ･メンバー･ノードとして含まないOracle Flex Cluster構成で実行できますが、リーフ・ノードは、ハブ・ノードのプールを含むクラスタのメンバーである必要があります。

関連項目:

- Oracle Flex Clusterのデプロイメントの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- Oracle Flex ASMの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

D.5 記憶域の構成の理解

既存のOracle ASMインスタンスの移行について

スタンドアロンのOracle ASMインストールのクラスタ・インストールへの変換

D.5.1 既存のOracle ASMインスタンスの移行について

以前のリリースのOracle ASMが、サーバー上または既存のOracle Clusterwareインストール環境内にインストールされている場合は、パスGrid_home/binにあるOracle Automatic Storage Management Configuration Assistant (ASMCA)を使用して、既存のOracle ASMインスタンスをOracle ASM 12cリリース1 (12.1)にアップグレードし、その後で障害グループ、Oracle ASMボリュームを構成できます。

注意:
既存のOracle ASMインスタンスのアップグレードは、そのノード上のすべてのデータベース・インスタンスおよびアプリケーションを停止してから実行する必要があります。

インストール時に、Oracle ASMを使用することを選択したときに、以前のOracle ASMバージョンが別のホームにインストールされていることがASMCAで検出された場合は、Oracle ASM 12cリリース1 (12.1)のバイナリをインストールした後に、ASMCAを起動して既存のOracle ASMインスタンスをアップグレードできます。

Oracle ClusterwareまたはOracle RACの既存のインストール環境で、すべてのノード上のOracle ASMインスタンスの旧バージョンがOracle ASM 11gリリース1 (11.1)の場合は、Oracle ASMインスタンスのローリング・アップグレードを実行できます。Oracle RACのインストール環境で、旧バージョンのOracle ASMインスタンスがOracle ASM 11gリリース1 (11.1)よりも前のリリースの場合は、ローリング・アップグレードを実行できません。Oracle ASMは、すべてのノードで12cリリース1 (12.1)にアップグレードされます。

D.5.2 スタンドアロンのOracle ASMインストールのクラスタ・インストールへの変換

クラスタのメンバー・ノードの中に、既存のスタンドアロンのOracle ASMがインストールされているノードが1つ以上ある場合でも、OUIは、クラスタ用のOracle Grid Infrastructureのインストールを開始します。

Oracle Clusterwareファイル(OCRおよび投票ディスク)をOracle ASM上に配置すると、クラスタウェアのインストール終了時にASMCAが起動し、ローカル・ノード上のOracle ASMインスタンスを移行およびアップグレードするためのプロンプトが表示され、Oracle ASM 12cリリース1 (12.1)環境が作成されます。

リモート・ノードでスタンドアロンのOracle ASMインスタンスが実行されていることをASMCAが認識すると、そのOracle ASMインスタンスと、そのOracle ASMインスタンスを使用しているデータベース・インスタンスを停止するように求められます。次に、ASMCAは、クラスタ化されたOracle ASMインスタンスをクラスタ内のすべてのノードに展開します。ただし、クラスタ対応のOracle ASMインスタンスのディスク・グループ名は、既存のスタンドアロンのディスク・グループ名と異なっている必要があります。

関連項目:
『Oracle Databaseストレージ管理者ガイド』

D.6 アウトオブプレース・アップグレードの理解

アウトオブプレース・アップグレードでは、インストーラは新しいバージョンを別のOracle Clusterwareホームにインストールします。Oracle Clusterwareの新旧バージョンが各クラスタ・メンバー・ノードに存在することになりますが、アクティブになるバージョンは1つのみです。

ローリング・アップグレードは、ソフトウェアの新バージョンへのアップグレード中、停止時間をなくし、可用性の継続を保証します。

各ノード上に別々のOracle Clusterwareホームがある場合、すべてのノードでアウトオブプレース・アップグレードを行うか、またはアウトオブプレース・ローリング・アップグレードを行うことができます。そうすることで、あるノードでは旧バージョンのOracle ClusterwareホームからOracle Clusterwareを実行し、別のノードでは新バージョンのOracle ClusterwareホームからOracle Clusterwareを実行することが可能です。

Oracle Grid Infrastructureのインプレース・アップグレードはサポートされません。

関連項目:
ローリング・アップグレードの実行手順については、付録B「Oracle Grid Infrastructure 12cリリース1へのアップグレード方法」を参照してください。

E インストール作業を手動で行う方法

この付録では、通常Cluster Verification Utility(CVU)およびインストーラ(OUI)がインストール時に完了する構成作業を、手動で行う方法について説明します。この付録は、修正スクリプトを使用できないときに参考にしてください。

この付録の内容は次のとおりです。

- すべてのクラスタ・ノードでの手動によるSSHの構成

- カーネル・パラメータの構成

- UDPおよびTCPカーネル・パラメータの手動設定

E.1 すべてのクラスタ・ノードでの手動によるSSHの構成

パスワードなしのSSH構成は、必須のインストール要件です。SSHは、インストール時にクラスタ・メンバー・ノードの構成に使用され、またインストール後にはコンフィギュレーション・アシスタント、Oracle Enterprise Manager、Opatchおよび他の機能によって使用されます。

OUIを使用したパスワードなしのSSHの自動構成によって、クラスタのすべてのノード上にRSA暗号化キーが作成されます。システム上の制約により、DSA鍵を使用するなどして手動でSSHを設定することが求められる場合は、この手順を参考にして、パスワードなしのSSHを設定してください。

この後の例では、Oracleソフトウェア所有者をgridユーザーとしています。

SSHが使用できない場合は、OUIはかわりにrshとrcpの使用を試行します。ただし、多くの場合、セキュリティのためこれらのサービスを使用できません。

この項の内容は次のとおりです。

- システム上の既存のSSH構成の確認

- クラスタ・ノードでのSSHの構成

- クラスタ・ノードでのSSHユーザー等価関係の有効化

E.1.1 システム上の既存のSSH構成の確認

次のコマンドを入力して、SSHが実行されているかどうかを確認します。

$ pgrep sshd

SSHが実行されている場合、このコマンドの結果は1つ以上のプロセスID番号になります。インストール・ソフトウェア所有者(grid、oracle)のホーム・ディレクトリで、コマンドls -alを使用して、.sshディレクトリを所有し、そのディレクトリへの書込みが可能であるのはそのユーザーのみであることを確認します。

SSHプロトコルには、RSA鍵またはDSA鍵のいずれかが必要です。RSAはSSH 1.5プロトコルで使用され、DSAはSSH 2.0プロトコルのデフォルトです。OpenSSHの場合は、RSAまたはDSAのいずれかを使用できます。この後の説明ではSSH1を想定しています。SSH2をインストールしており、SSH1を使用できない場合は、SSHディストリビューションのドキュメントを参照して、SSH1互換を構成するか、またはDSAを使用してSSH2を構成します。

E.1.2 クラスタ・ノードでのSSHの構成

SSHを構成するには、最初に各クラスタ・ノードにRSA鍵およびDSA鍵を作成してから、すべてのクラスタ・ノード・メンバーで生成されたすべての鍵を各ノードで同じ認証鍵ファイルにコピーする必要があります。SSHファイルを読み取ることができのは、rootおよびソフトウェア・インストール・ユーザー(oracle、grid)のみである必要があります。これは、SSHが他のユーザーによってアクセス可能であると、SSHは秘密鍵を無視するためです。この後の例では、DSA鍵が使用されています。

インストールに使用するOracleソフトウェアのインストール所有者ごとにSSHを構成する必要があります。

SSHを構成するには、次の手順を実行します。

E.1.2.1 各ノードでのSSHディレクトリおよびSSH鍵の作成

各ノードに対し、次の手順を実行します。

1. ソフトウェア所有者(この例ではgridユーザー)としてログインします。

2. コマンドidおよびid gridを入力して、gridとしてログインしていること、およびユーザーIDがgridユーザーに割り当てたユーザーIDと一致していることを確認します。Oracleユーザー・グループおよびユーザーと、使用しているユーザー端末ウィンドウ・プロセスのグループIDおよびユーザーIDが同じであることを確認します。次に例を示します。

$ id
uid=502(grid) gid=501(oinstall) groups=501(oinstall),502(grid,asmadmin,asmdba)
$ id grid
uid=502(grid) gid=501(oinstall) groups=501(oinstall),502(grid,asmadmin,asmdba)

3. 必要に応じて、gridユーザーのホーム・ディレクトリに.sshディレクトリを作成して適切な権限を設定し、読取り/書込み権限を持っているのはoracleユーザーのみであることを確認します。

$ mkdir ~/.ssh
$ chmod 700 ~/.ssh

注意:
権限が700に設定されていないと、SSH構成は失敗します。

4. 次のコマンドを入力します。

$ /usr/bin/ssh-keygen -t dsa

プロンプトで、鍵ファイルには、デフォルトの位置を使用します([Enter]を押します)。

注意:
パス・フレーズを持つSSHは、Oracle Clusterware 11gリリース2以上のリリースではサポートされません。

このコマンドによって、DSA公開鍵が~/.ssh/id_dsa.pubファイルに、秘密鍵が~/.ssh/id_dsaファイルに書き込まれます。

秘密鍵は、Oracleソフトウェア・インストールの実行を許可されていない他のユーザーには配布しないでください。

5. DSA鍵を使用して、クラスタ・メンバーを作成する各ノードで手順1から手順4を実行します。

E.1.2.2 共通のauthorized_keysファイルへのすべての鍵の追加

次の手順を実行します。

1. ローカル・ノードで、Oracle Grid Infrastructure所有者のホーム・ディレクトリ(通常、gridまたはoracle)にある.sshディレクトリに移動します。
次に、次のコマンドを使用してDSA鍵をauthorized_keysファイルに追加します。

$ cat id_dsa.pub >> authorized_keys
$ ls

.sshディレクトリに、作成したid_dsa.pub鍵とauthorized_keysファイルが表示されるはずです。

2. ローカル・ノードで、SCP(セキュア・コピー)またはSFTP(セキュアFTP)を使用して、authorized_keysファイルをリモート・ノードのoracleユーザーの.sshディレクトリにコピーします。次の例では、node2というノードでSCPを使用しています。Oracle Grid Infrastructureの所有者はgridです。gridユーザーのパスは/home/gridです。

[grid@node1 .ssh]$ scp authorized_keys node2:/home/grid/.ssh/

DSA鍵を受け入れるように求められます。Yesと入力して、コピー先のノードがknown_hostsファイルに追加されていることを確認します。

プロンプトに従って、gridユーザーのパスワードを入力します。パスワードは、クラスタ内のすべてのノードで同じにする必要があります。authorized_keysファイルがリモート・ノードにコピーされます。

出力結果は、次のようになります。xxxは有効なIPアドレスの一部を示しています。

[grid@node1 .ssh]$ scp authorized_keys node2:/home/grid/.ssh/
The authenticity of host 'node2 (xxx.xxx.173.152) can't be established.
DSA key fingerprint is 7e:60:60:ae:40:40:d1:a6:f7:4e:zz:me:a7:48:ae:f6:7e.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'node1,xxx.xxx.173.152' (dsa) to the list
of known hosts
grid@node2's password:
authorized_keys       100%             828             7.5MB/s      00:00

3. SSHを使用して、authorized_keysファイルをコピーしたノードにログインします。.sshディレクトリに移動し、catコマンドを使用して2つ目のノードのDSA鍵をauthorized_keysファイルに追加します。このとき、パスワードを求められたら[Enter]をクリックすることで、パスワードなしのSSHが設定されます。

[grid@node1 .ssh]$ ssh node2
[grid@node2 grid]$ cd .ssh
[grid@node2 ssh]$ cat id_dsa.pub  >> authorized_keys

各ノードからクラスタ内の他の各メンバー・ノードに対して手順2および3を繰り返します。

クラスタ・ノード・メンバーにする最後のノードのauthorized_keysファイルに各クラスタ・ノード・メンバーから鍵を追加した後、scpを使用して、すべてのノードの鍵を含むauthorized_keysファイルを各クラスタ・ノード・メンバーに再度コピーし、他のノードの既存のバージョンを上書きします。

authorized_keysファイルにすべてのノードが含まれていることを確認するには、more authorized_keysコマンドを入力して、各メンバー・ノードのDSA鍵が存在するかどうかを確認します。ファイルには、鍵のタイプ(ssh-dsa)、鍵、ユーザーおよびサーバーの順で示されます。次に例を示します。

ssh-dsa AAAABBBB . . . = grid@node1

注意:
各ノードのgridユーザーの/.ssh/authorized_keysファイルには、すべてのクラスタ・ノードで生成した/.ssh/id_dsa.pubファイルのすべての内容が含まれている必要があります。

E.1.3 クラスタ・ノードでのSSHユーザー等価関係の有効化

すべての鍵が含まれているauthorized_keysファイルをクラスタ内の各ノードにコピーしたら、示されている順に次の手順を実行します。この例では、Oracle Grid Infrastructureソフトウェア所有者の名前はgridです。

1. OUIを実行するシステムにgridユーザーとしてログインします。

2. 次のコマンド構文を使用して、ローカル・ノードから各ノードにSSHを実行します(ローカル・ノードからローカル・ノード自体へのSSHの実行、各ノードから他の各ノードへのSSHの実行を含みます)。hostname1やhostname2などは、クラスタ内のノードのパブリック・ホスト名(別名および完全修飾されたドメイン名)です。

[grid@nodename]$ ssh hostname1 date
[grid@nodename]$ ssh hostname2 date
.
.
.

次に例を示します。

[grid@node1 grid]$ ssh node1 date
The authenticity of host 'node1 (xxx.xxx.100.101)' can't be established.
DSA key fingerprint is 7z:60:60:zz:48:48:z1:a0:f7:4e.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'node1,xxx.xxx.100.101' (DSA) to the list of
known hosts.
Mon Dec 4 11:08:13 PST 2006
[grid@node1 grid]$ ssh node1.example.com date
The authenticity of host 'node1.example.com (xxx.xxx.100.101)' can't be
established.
DSA key fingerprint is 7z:60:60:zz:48:48:z1:a0:f7:4e.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'node1.example.com,xxx.xxx.100.101' (DSA) to the
list of known hosts.
Mon Dec 4 11:08:13 PST 2006
[grid@node1 grid]$ ssh node2 date
Mon Dec 4 11:08:35 PST 2006
.
.
.

この処理の終了時に、各メンバー・ノードのパブリック・ホスト名を、他のすべてのクラスタ・ノードのknown_hostsファイルに登録する必要があります。

リモート・クライアントを使用してローカル・ノードに接続しているときに、xauthデータがなく、X11転送に偽の認証データを使用することを示す警告メッセージが表示された場合は、認証鍵ファイルは適切に構成されているが、SSH構成でX11転送が有効になっていることを示しています。この問題を解決するには、第5.2.3項「リモート表示およびX11転送の構成の設定」に進みます。

3. 各クラスタ・ノード・メンバーに対して手順2を繰り返します。

SSHが適切に構成されていれば、パスワードを求めるプロンプトは表示されることなくsshやscpコマンドを使用できます。次に例を示します。

[grid@node1 ~]$ ssh node2 date
Mon Feb 26 23:34:42 UTC 2009
[grid@node1 ~]$ ssh node1 date
Mon Feb 26 23:34:48 UTC 2009

パスワードを求めるノードがある場合、そのノードの~/.ssh/authorized_keysファイルに適切な公開鍵が含まれていること、および同じグループ・メンバーシップおよびIDを持つOracleソフトウェア所有者が作成されていることを確認します。

E.2 カーネル・パラメータの構成

注意:
次の項には、カーネル・パラメータの推奨値のみを示します。本番データベース・システムでは、これらの値を調整してシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。
HP-UX 11.31(バージョン3)では、次のパラメータは有効ではありません。

- msgmap

- msgseg

E.2.1 カーネル・パラメータの最小値

すべてのクラスタ・ノードで、表E-1に示すカーネル・パラメータが、表に示されている計算式または推奨値以上に設定されていることを確認します。表の後に、値を確認して設定する手順を示します。

表E-1 HP-UXでのカーネル・パラメータの最小値

パラメータ

必要最小値

ksi_alloc_max

32768

executable_stack

0

max_thread_proc

1024

maxdsiz

1073741824(1GB)

maxdsiz_64bit

2147483648(2GB)

maxfiles

1024

maxfiles_lim

63488

maxssiz

134217728(128MB)

maxssiz_64bit

1073741824(1GB)

maxuprc

3686

msgmni

4096

msgtql

4096

ncsize

35840

nflocks

4096

ninode

34816

nkthread

7184

nproc

4096

semmni

4096

semmns

8192

semmnu

4092

semvmx

32767

shmmax

1073741824

shmmni

4096

shmseg

512

tcp_largest_anon_port

65500

udp_largest_anon_port

65500

TCPおよびUDPカーネル・パラメータが、「UDPおよびTCPカーネル・パラメータの手動設定」の項の説明に従って設定されていることを確認します。

注意:

- パラメータに対する現行の値がこの表の値より大きい場合は、そのパラメータの値を変更しないでください。

- HFSを使用しない場合は、デフォルトのninode値を保持してください。

E.2.2 カーネル・パラメータの手動設定

これらのカーネル・パラメータに指定されている現行の値または計算式を表示し、必要に応じて変更するには、kctune、HP System Management Homepage(HP SMH)またはHP-UX Kernel Configuration(kcweb)を使用します。

- KCTUNEを使用したカーネル設定の変更

- SMHを使用したカーネル設定の変更

- KCWEBを使用したカーネル設定の変更

E.2.2.1 KCTUNEを使用したカーネル設定の変更

/usr/sbin/kctuneを使用してカーネル・パラメータを表示または変更します。たとえば、カーネル・パラメータを表示するには、kctuneに-dフラグを付けて入力します。次に例を示します。

# /usr/sbin/kctune -d

カーネル・パラメータを変更するには、kctune variable=valueを入力します。次に例を示します。

# /usr/sbin/kctune aio_listio_max=512

他のすべてのクラスタ・ノードでこの手順を実行します。

E.2.2.2 SMHを使用したカーネル設定の変更

次に、HP System Management Homepage(SMH)を使用してカーネル設定を変更する手順を示します。

1. オプションで、DISPLAY環境変数を設定し、ローカル・システムの表示を指定します。

- Bourne、BashまたはKornシェル:

# DISPLAY=local_host:0.0 ; export DISPLAY

- Cシェル:

# setenv DISPLAY local_host:0.0

2. SMHを起動します。

# /usr/sbin/smh

3. 「Kernel Configuration」領域→「Configurable Parameters」領域の順に選択します。

4. これらのパラメータに指定した値または式を確認し、必要に応じてその値または式を変更します。
必要に応じて、この手順の詳細についてSMHのオンライン・ヘルプを参照してください。

注意:
動的でないパラメータの値を変更した場合は、システムを再起動する必要があります。

5. 必要に応じて、システムの再起動時に、ログインしてユーザーをrootに切り替えます。

6. 他のすべてのクラスタ・ノードでこの手順を実行します。

E.2.2.3 KCWEBを使用したカーネル設定の変更

次に、手順を示します。

1. 次のコマンドを入力して、kcwebアプリケーションを起動します。

# /usr/sbin/kcweb -F

2. これらのパラメータに指定した値または式を確認し、必要に応じてその値または式を変更します。
必要に応じて、この手順の詳細についてkcwebのオンライン・ヘルプを参照してください。

注意:
動的でないパラメータの値を変更した場合は、システムを再起動する必要があります。

3. 必要に応じて、システムの再起動時に、ログインしてユーザーをrootに切り替えます。

4. 他のすべてのクラスタ・ノードでこの手順を実行します。

E.2.3 HP-UXシステムのカーネル・パラメータの構成

インストール時にFixupスクリプトを生成して実行し、データベースを正常にインストールするために必要なカーネル・パラメータ値を確認および設定できます。このスクリプトは、必要なカーネル・パッケージを必要に応じて最小値に更新します。

Fixupスクリプトを使用できない場合は、カーネル・パラメータが付録E「カーネル・パラメータの構成」に示す最小値以上に設定されていることを確認してください。値を手動で確認および設定する方法については、表に続く手順で説明します。

注意:
付録E「カーネル・パラメータの構成」に示されている、Fixupスクリプトで構成したカーネル・パラメータおよびシェル制限値は最小値です。本番データベース・システムでは、これらの値を調整してシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。

E.3 UDPおよびTCPカーネル・パラメータの手動設定

サーバーの予測負荷に対応できる十分なエフェメラル・ポートを提供するために、NDDを使用してHP-UXカーネルTCP/IPエフェメラル・ポート範囲が十分な広さを持つことを確認します。使用するアプリケーションに予約済のポートを避けるようにポート範囲を高く設定します。

次に例を示します。

# /usr/bin/ndd /dev/tcp tcp_largest_anon_port
65535

この例では、tcp_largest_anon_portはデフォルト値に設定されています。

必要に応じて、ファイル/etc/rc.config.d/nddconfを編集し、エントリを追加してUDPおよびTCPエフェメラル・ポート値を更新します。次に例を示します。

TRANSPORT_NAME[0]=tcp
NDD_NAME[0]=tcp_largest_anon_port
NDD_VALUE[0]=65500

TRANSPORT_NAME[1]=udp
NDD_NAME[1]=udp_largest_anon_port
NDD_VALUE[1]=65500

エントリに正しい順番で番号が付いていることを確認してください。たとえば、nddconfにTCPポートおよびUDPポートのエントリが2つ存在する場合は、0と1(TRANSPORT_NAME[0]=tcp、TRANSPORT_NAME[1]=udp)にナンバリングされます。

注意:
tcp_smallest_anon_portパラメータおよびudp_smallest_anon_portパラメータは廃止されているため、設定する必要はありません。

索引
A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  R  S  T  U  V  W  X

数字

32-bitと64-bit

同じクラスタでソフトウェア・バージョンがサポートされない, 2.2

A

修正スクリプト機能, 3.3

アーキテクチャ

システム・アーキテクチャの確認, 2.1

ASM

複数のデータベース, 5.1.7.1.3

ディスクの所有者および権限の変更

HP-UX, 6.4.1.4, 6.4.1.4

キャラクタ・デバイス名

HP-UX, 6.4.1.4

障害グループの特性, 6.4.1.1, 6.4.2.1 HP-UXでのディスク可用性の確認, 6.4.1.4 ASMのためのOSDBAグループの作成, 5.1.9.5 ディスク・グループ, 6.4.1.1 障害グループ, 6.4.1.1

例, 6.4.1.1, 6.4.2.1

確認, 6.4.1.1, 6.4.2.1

HP-UXでの使用可能なディスクの確認, 6.4.1.4 HP-UXでのディスクの確認, 6.4.1.4 OSASM管理者またはASM管理者, 5.1.7.1.3 ASM用のOSDBAグループ, 5.1.7.1.3 ディスク・グループの推奨事項, 6.4.1.1 Oracle Clusterwareファイルに必要な領域, 6.4.1.1 事前構成済データベースに必要な領域, 6.4.1.1 ASMグループ

作成, 5.1.9.3

ASM。「Oracle ASM」を参照 ASMCA

Oracle ASMでの以前のOracle Databaseリリースのディスク・グループ作成に使用, 8.3.3

ASMSNMP, 1.1.3

B

Bashシェル

デフォルト・ユーザーの起動ファイル, 5.2.2

.bash_profileファイル, 5.2.2 bdf, 2.1, 2.1 バイナリ

再リンク, 8.4

ブロック・デバイス

Oracle Clusterwareファイル用の権限ファイルの作成, 6.4.1.4

直接記憶域ではサポートされない, 6.1.1

BMC

構成, 5.3.3

BMCインタフェース

インストール前のタスク, 5.3

結合アドレス

同一のIPプロトコルを使用する必要性, 4.4

Bourneシェル

デフォルト・ユーザーの起動ファイル, 5.2.2

C

Cシェル

デフォルト・ユーザーの起動ファイル, 5.2.2

中央インベントリ, 5.1.7.1.1, 5.1.8.1

概要, D.1.3

各クラスタ・メンバー・ノードでローカル, 5.1.1

中央インベントリ。「OINSTALLグループ」および「Oracle Inventoryグループ」も参照 ホスト名の変更, D.2.1 キャラクタ・デバイス

HP-UXでのデバイス名, 6.4.1.4

checkdirエラー, 8.4 バージョンの確認, 3.8 chmodコマンド, 6.3.8, 6.3.9, 6.4.1.4 chownコマンド, 6.3.8, 6.3.9, 6.4.1.4 クライアント

SCANへの接続, D.2.5

クローニング

他のノードへのグリッド・ホームのクローニング, 7.2

クラスタ構成ファイル, 7.1.2 クラスタ・ファイル・システム

データ・ファイルの記憶域オプション, 6.1.2

クラスタ・インターコネクト

Hyper Messagingプロトコル, 3.6

クラスタ名, 1.1.3

要件, 1.1.3

クラスタ・ノード

プライベート・ネットワーク・ノードのインタフェース, 1.1.3

プライベート・ノード名, D.2.5

パブリック・ネットワーク・ノードの名前およびアドレス, 1.1.3

パブリック・ノード名, 7.1.1

uidおよびgidの指定, 5.1.9.7

仮想ノード名, 1.1.3, D.2.3

クラスタ時刻同期化サービス, 3.9 クラスタ検証ユーティリティ

修正スクリプト, 3.3

ユーザー等価関係のトラブルシューティング, A.4

クラスタウェア

サード・パーティのクラスタウェアの要件, 1.1.3

コマンド

asmca, 7.1.1, 7.1.1, 8.2.3.2, B.9.5.1

asmcmd, 5.1.3.1

chmod, 6.3.8, 6.3.8, 6.3.9

chown, 6.3.8, 6.3.8, 6.3.9

crsctl, 7.3, 8.3.4, B.5, B.9.6

df, 2.3

fdisk, 6.4.1.4

groupadd, 5.1.9.7

id, 5.1.9.7

mkdir, 6.3.8, 6.3.8, 6.3.9

nscd, 3.13

passwd, 5.1.9.7

ping, 4.2

rootcrs.sh, 8.4

deconfigオプション, 9.5

rootupgrade.sh, B.5 sqlplus, 5.1.3.1 srvctl, B.5 umask, 5.2.1 uname, 2.1 unset, B.6.1 useradd, 5.1.3.3, 5.1.9.6.3, 5.1.9.7 usermod, 5.1.9.6.4 xhost, 3.4 xterm, 3.4 カーネル・パラメータの構成, E.2 Xライブラリの必要なシンボリック・リンクの作成, 3.11 cron jobs, 1.1.6, A.6 crs_install.rspファイル, C.2.1 CSD

WebSphere MQ用のダウンロード場所, 3.8

ctsdd, 3.9 カスタム・データベース

ASMの障害グループ, 6.4.1.1, 6.4.2.1

ASMを使用する場合の要件, 6.4.1.1

カスタム・インストール・タイプ

選択する理由, 5.1.7.1.2, 5.1.8.2

D

データ・ファイル

個別のディレクトリの作成, 6.3.8, 6.3.9

データ・ファイル・ディレクトリでの権限の設定, 6.3.8, 6.3.9

記憶域オプション, 6.1.2

データ消失

ASMによるリスクの最小化, 6.4.1.1, 6.4.2.1

データベース・ファイル

サポートされている記憶域オプション, 6.1.1

データベース

ASM要件, 6.4.1.1

dbaグループ

HP-UX上のASMディスク, 6.4.1.4

DBCA

Oracle ASMディスク・グループ管理には使用されない, 8.3.3

以前のOracle Databaseリリースのサーバー・プール作成に使用, 8.3.2

dbca.rspファイル, C.2.1 デフォルトのファイル・モード作成マスク

設定, 5.2.1

削除, 9.1 削除, 9.1 削除ツール

概要, 9.6.1

例, 9.6.2

以前のGridホーム, 9.6.1.1

Oracle Flex Clusterおよび-lastnodeフラグの制限事項, 9.5

roothas.sh, 9.6.1

以前のGridホームの削除, 9.6.1.1 デバイス名

HP-UX, 6.4.1.4

dfコマンド, 2.3 DHCP

GNS, 4.5.1

Direct NFS

無効化, 6.3.10, 6.3.10

有効化, 6.3.5

データ・ファイル, 6.2.4

Direct NFSクライアント

書込みサイズの最小値, 6.2.4.2

ディレクトリ

個別のデータ・ファイル・ディレクトリの作成, 6.3.8, 6.3.9

データ・ファイル・ディレクトリの権限, 6.3.8, 6.3.9

ディスク

ASMの所有者および権限の変更

HP-UX, 6.4.1.4

ディスク・グループ

ASM, 6.4.1.1

Oracle ASMディスク・グループの推奨事項, 6.4.1.1

ディスク・グループ

推奨事項, 6.4.1.1

ディスク領域

確認, 2.1

ASMでの事前構成済データベース要件, 6.4.1.1

ディスク

ASMの所有者および権限の変更

HP-UX, 6.4.1.4

HP-UXでのASMの可用性の確認, 6.4.1.4 HP-UXでのLVMディスクの確認, 6.4.1.4 ディスク。「ASMディスク」も参照 DISPLAY環境変数, E.2.2.2

設定, 5.2.2

DNS, A.9

E

エミュレータ

Xエミュレータからのインストール, 3.4

enterprise.rspファイル, C.2.1 環境

oracleユーザーの構成, 5.2

環境変数

DISPLAY, 5.2.2, E.2.2.2

ORACLE_HOME, 5.1.3.1, 5.2.2, B.6.1

ORACLE_SID, B.6.1

シェル起動ファイルからの削除, 5.2.2

SHELL, 5.2.2

TEMPおよびTMPDIR, 2.1, 2.3, 5.2.2

TNS_ADMIN, 5.2.2

エラー

X11転送, 5.2.3, E.1.3

Opatch使用時のエラー, 8.4 Exadata

バイナリの再リンク例, 8.4

例

ASM障害グループ, 6.4.1.1, 6.4.2.1

executable_stackパラメータ

最小値, E.2.1

F

障害グループ

ASM, 6.4.1.1

ASM障害グループの特性, 6.4.1.1, 6.4.2.1

ASM障害グループの例, 6.4.1.1, 6.4.2.1

フェンシング

IPMI, 1.1.1, 5.3

ファイル・モード作成マスク

設定, 5.2.1

ファイル・システム

データ・ファイルの記憶域オプション, 6.1.2

ファイル・システム, 6.1.5 ファイル

$ORACLE_HOME/lib/libnfsodm11.so, 6.3.5

$ORACLE_HOME/lib/libodm11.so, 6.3.5

.bash_profile, 5.2.2

dbca.rsp, C.2.1

シェル起動ファイルの編集, 5.2.2

enterprise.rsp, C.2.1

.login, 5.2.2

oraInst.loc, 5.1.1

.profile, 5.2.2

レスポンス・ファイル, C.2

ファイル・セット, 3.5 fixupスクリプト

トラブルシューティング, 3.3

修正スクリプト, 3.3

G

GFS, 6.1.5

gid

既存の確認, 5.1.9.7

指定, 5.1.9.7

他のノードでの指定, 5.1.9.7

サポートされていない既存のインストール所有者のGIDの変更, 5.1.3.3 GNS

説明, 4.5.3

構成, 4.5.1

GNSクライアント・クラスタ

GNSクライアント・データ・ファイル, 4.5.4.4

インストールに必要なGNSクライアント・データ・ファイル, 4.5.4.1

名前解決, 4.5.4.1

GNSクライアント・データ・ファイル

作成方法, 4.5.4.4

GNS仮想IPアドレス, 1.1.3 GPFS, 6.1.5 Gridホーム

Oracleベースの制限, 5.1.5

ディスク領域, 1.1.1, 2.3

最小必須ディスク領域, 2.3

ロック解除, 8.4

gridユーザー, 5.1.7.1.1 Gridユーザー, 5.1.8.1 グループID

既存の確認, 5.1.9.7

指定, 5.1.9.7

他のノードでの指定, 5.1.9.7

グループ

oinstallグループの存在の確認, 5.1.1, 5.1.1

他のノードでの同一グループの作成, 5.1.9.7, 5.1.9.7

ASMグループの作成, 5.1.9.3, 5.1.9.3

ASMのためのOSDBAグループの作成, 5.1.9.5

OSDBAグループの作成, 5.1.9.1

OINSTALL, 5.1.1, 5.1.2

OSASM (asmadmin), 5.1.7.1.3, 5.1.8.4

OSBACKUPDBA (backupdba), 5.1.8.3

OSDBA (dba), 5.1.7.1.2, 5.1.8.2

ASMのためのOSDBA(asmdba), 5.1.7.1.3, 5.1.8.4

OSDBAグループ(dba), 5.1.7.1.2, 5.1.8.2

OSDGDBA (dgdba), 5.1.8.3

OSKMDBA (kmdba), 5.1.8.3

ASMのためのOSOPER, 5.1.7.1.3

ASM用のOSOPER (asmoper), 5.1.8.4

OSOPERグループ(oper), 5.1.7.1.2

OSOPER (oper), 5.1.7.1.2, 5.1.8.2

インストール所有者ユーザーに必要, 5.1.7.1.1

Oracleソフトウェア所有者ユーザーに必須, 5.1.8.1

ユーザー作成時の指定, 5.1.9.7, 5.1.9.7

NISの使用, 5.1.7, 5.1.9.7

H

高可用性IPアドレス, 4.3

ホスト名

変更, D.2.1

有効なホスト名, 1.1.3

HP-UX

キャラクタ・デバイス名, 6.4.1.4

ASMのディスク可用性の確認, 6.4.1.4

ASMのディスクの確認, 6.4.1.4

LVMディスクの確認, 6.4.1.4

パラメータのチューニング, E.2.2

ハブ・ノード, 4.6, D.4, D.4

名前およびアドレス, 1.1.3

Hyper Messagingプロトコル

クラスタ・インターコネクトとしての使用, 3.6

HyperFabricソフトウェア

要件, 3.6

I

idコマンド, 5.1.9.7

アクセス不可ノード

アップグレード, B.9.3

INS-32026エラー, 5.1.5 インストール

cronジョブ, 1.1.6

他のノードへのグリッド・インフラストラクチャ・ホームのクローニング, 7.2

レスポンス・ファイル, C.2

準備, C.2, C.2.2

テンプレート, C.2

サイレント・モード, C.3 クラスタ構成ファイルの使用, 7.1.2 インストール・タイプ

ASM, 6.4.1.1

インターコネクト, 1.1.3 インタフェース, 1.1.3

プライベート・インターコネクトの要件, D.2.2

断続的なハングアップ

ソケット・ファイル, 7.3

ioscanコマンド, 6.4.1.4 IOServers

概要, D.4

IPプロトコル

冗長インタフェース, 4.4

IPMI

インストール前のタスク, 5.3

インストールの準備, 1.1.1

必要な構成, 8.2.1

IPv4の要件, 4.4 IPv6要件, 4.4 IPv6のサポート

概要, はじめに

Itanium

オペレーティング・システムの要件, 3.6

J

JDK要件, 3.5

役割区分によるユーザー,5.1.7.1.1, 5.1.8.1

K

kctune, E.2.2

kcweb, E.2.2

カーネル・パラメータ

構成, E.2

設定, E.2.2.2

Kornシェル

デフォルト・ユーザーの起動ファイル, 5.2.2

ksi_alloc_maxパラメータ

最小値, E.2.1

L

リーフ・ノード, 4.6, D.4

有効なホスト名, 1.1.3

libnfsodm11.so, 6.3.5

libodm11.so, 6.3.5

ログ・ファイル

インストール時のアクセス方法, 7.1.1

.loginファイル, 5.2.2 LVM

HP-UXでのボリューム・グループ・デイバスの確認, 6.4.1.4

ASMの推奨事項, 6.4.1.1

M

マスク

デフォルトのファイル・モード作成マスクの設定, 5.2.1

max_thread_proc

最小値, E.2.1

max_thread_procパラメータ

最小値, E.2.1

maxdsizパラメータ

最小値, E.2.1

maxdsiz_64bitパラメータ

最小値, E.2.1

maxfilesパラメータ

最小値, E.2.1

maxfiles_lim

最小値, E.2.1

maxssizパラメータ

最小値, E.2.1

maxssiz_64bitパラメータ

最小値, E.2.1

maxuprcパラメータ

最小値, E.2.1

デバイス・ファイルのマイナー番号, 3.12 複合バイナリ, 3.5 mkdirコマンド, 6.3.8, 6.3.9 モード

デフォルトのファイル・モード作成マスクの設定, 5.2.1

msgmap

無効, E.2

msgmniパラメータ

最小値, E.2.1

msgseg

無効, E.2

msgtqlパラメータ

最小値, E.2.1

複数のデータベース

ASM, 5.1.7.1.3

複数のoracleホーム, 6.3.9 複数のOracleホーム, 5.1.3.1 My Oracle Support, 8.1

N

ncsizeパラメータ

最小値, E.2.1

Net Configuration Assistant(NetCA)

レスポンス・ファイル, C.4

コマンド・プロンプトでの実行, C.4

netca, 7.1.1 netca.rspファイル, C.2.1 ネットワーク

Oracle Flex Cluster, 4.6, D.4

IPプロトコル要件, 4.4

Oracle Flex ASM, 1.1.3, 4.6, D.4

nflocksパラメータ

最小値, E.2.1

NFS, 6.1.5, 6.3.2

データ・ファイル, 6.2.5

Oracle Clusterwareファイル, 6.2.1

バッファ・サイズ・パラメータ, 6.3.1, 6.3.3

Direct NFS, 6.2.4

データ・ファイル, 6.2.5

rsize, 6.3.2

ninodeパラメータ

最小値, E.2.1

NIS

ローカル・ユーザーおよびグループの代替, 5.1.7

nkthreadパラメータ

最小値, E.2.1

nprocパラメータ

最小値, E.2.1

nslookupコマンド, A.9

O

oinstallグループ

存在の確認, 5.1.1

OINSTALLグループ

概要, D.1.3

oraInst.loc, 5.1.1

他のノードでの指定, 5.1.9.7

付与されるシステム権限, 5.1.3.1

OINSTALLグループ。「Oracleインベントリ・グループ」も参照 Opatch, 8.4 オペレーティング・システム

バージョンの確認, 3.8

クラスタ・メンバーで異なる, 3.5

システム権限のオペレーティング・システム認証, 5.1.8.2 オペレーティング・システム権限グループ, 5.1.8.2 オペレーティング・システム要件, 3.5

Itanium, 3.6

Optimal Flexible Architecture

oraInventoryディレクトリ, D.1.4

Oracle ASM

ローリング・アップグレード, B.9.5

Oracle Grid Infrastructureインストールの一部としてのインストール, はじめに

ASM管理者のOSASM, 5.1.8.4

ASM用のOSDBAグループ, 5.1.8.4

ASM用のOSOPERグループ, 5.1.8.4

データ・ファイルの記憶域オプション, 6.1.2

Oracle Clusterwareファイルの格納, 6.1.1

Oracle ASMクライアント, 4.6 Oracleベース・ディレクトリ

GridホームはOracle DatabaseのOracleベースに配置しない, 5.1.5

Gridホームの禁止, D.1.1

最小ディスク領域, 1.1.1, 2.3

Oracle Grid Infrastructureの要件, D.1.6

Oracle Cluster Registry

構成, 1.1.5

ミラー化, 6.2.1

パーティション・サイズ, 6.2.1

ブロック・デバイス・パーティションを所有する権限ファイル, 6.4.1.4

サポートされている記憶域オプション, 6.1.1

Oracle Clusterware

ファイル・システム, 6.1.5

Oracle Grid Infrastructureインストールの一部としてのインストール, はじめに

インストール, 7

サポートされている記憶域オプション, 6.1.1

アップグレード, 6.2.1

Oracle Clusterwareファイル

ASMディスク領域要件, 6.4.1.1

Oracle Clusterwareのインストレーション・ガイド

Oracle Grid Infrastructureインストレーション・ガイドに置き換え 7

Oracle Database

データ・ファイル・ディレクトリの作成, 6.3.8, 6.3.9

データ・ファイルの記憶域オプション, 6.1.2

権限を付与されたグループ, 5.1.7.1.2, 5.1.8.2

ASMの要件, 6.4.1.1

Oracle Database Configuration Assistant

レスポンス・ファイル, C.2.1

Oracle Disk Manager

Direct NFS, 6.3.5

Oracle Flex ASM

概要, D.4

Oracle ASMクライアント, 1.1.3, 4.6, D.4

ネットワーク, 1.1.3, 4.6, D.4

Oracle Flex Cluster

概要, はじめに

ハブ・ノード, 8.3.2, D.4

IOServer, D.4

リーフ・ノード, 8.3.2

Oracle Flex ASM, 4.6, D.4

ハブ・ノードの構成, 1.1.3

Oracle Grid Infrastructure所有者(grid), 5.1.7.1.1, 5.1.8.1 Oracle Grid Infrastructureレスポンス・ファイル, C.2.1 Oracleホーム

複数のoracleホーム, 6.3.9

Oracleホーム

asmcmdエラー, 5.1.3.1

ASCIIパスの制限, 1.1.2

複数のOracleホーム, 5.1.3.1

Oracleインベントリ

ポインタ・ファイル, 5.1.1

Oracle Inventoryグループ

概要, D.1.3

存在の確認, 5.1.1

作成, 5.1.2

他のノードでの指定, 5.1.9.7

Oracle Net Configuration Assistant

レスポンス・ファイル, C.2.1

Oracleパッチの更新, 8.1 Oracleソフトウェア所有者ユーザー

作成, 5.1.3

定義, 5.1.7.1.1

Oracleソフトウェア所有者ユーザー

ASMディスク, 6.4.1.4, 6.4.1.4

構成環境, 5.2

作成, 5.1.3.2, 5.1.9.6.1, 5.1.9.6.2

他のノードでの指定, 5.1.9.7

デフォルトのシェルの確認, 5.2.2

必要なグループ・メンバーシップ, 5.1.7.1.1

Oracleソフトウェア所有者ユーザー

説明, 5.1.8.1

必要なグループ・メンバーシップ, 5.1.8.1

Oracle Universal Installer

レスポンス・ファイル

リスト, C.2.1

Oracle Upgrade Companion, 3.1.1 oracleユーザー

ASMディスク, 6.4.1.4, 6.4.1.4

構成環境, 5.2

作成, 5.1.3, 5.1.3.2, 5.1.3.3, 5.1.9.6.1, 5.1.9.6.2, 5.1.9.6.3

他のノードでの指定, 5.1.9.7

定義, 5.1.7.1.1

デフォルトのシェルの確認, 5.2.2

必要なグループ・メンバーシップ, 5.1.7.1.1

Oracleユーザー

説明, 5.1.8.1

必要なグループ・メンバーシップ, 5.1.8.1

環境変数ORACLE_BASE

シェル起動ファイルからの削除, 5.2.2

環境変数ORACLE_HOME

シェル起動ファイルからの削除, 5.2.2

設定の削除, 5.2.2

環境変数ORACLE_SID

シェル起動ファイルからの削除, 5.2.2

oraInst.loc

中央インベントリ, 5.1.1

内容, 5.1.1

oraInst.locファイル

場所, 5.1.1

場所, 5.1.1

oraInventory, 5.1.7.1.1, 5.1.8.1

概要, D.1.3

作成, 5.1.2

OSASMグループ,5.1.7.1.3, 5.1.8.4

概要, 5.1.7.1.3, 5.1.8.4

複数のデータベース, 5.1.7.1.3

SYSASM, 5.1.7.1.3

作成, 5.1.9.3

OSBACKUPDBAグループ(backupdba), 5.1.8.3 ASM用のOSDBAグループ, 5.1.7.1.3, 5.1.8.4

概要, 5.1.7.1.3, 5.1.8.4

OSDBAグループ

HP-UX上のASMディスク, 6.4.1.4

SYSDBA権限, 5.1.7.1.2

SYSDBAシステム権限, 5.1.8.2

作成, 5.1.9.1

他のノードでの作成, 5.1.9.7, 5.1.9.7

説明, 5.1.7.1.2, 5.1.8.2

ASM用のOSDBAグループ

作成, 5.1.9.5

OSDGDBAグループ(dgdba), 5.1.8.3 OSKMDBAグループ(kmdba), 5.1.8.3 ASM用のOSOPERグループ, 5.1.8.4

概要, 5.1.7.1.3, 5.1.8.4

作成, 5.1.9.4

OSOPERグループ

SYSOPER権限, 5.1.7.1.2

SYSOPERシステム権限, 5.1.8.2

作成, 5.1.9.2

他のノードでの作成, 5.1.9.7, 5.1.9.7

説明, 5.1.7.1.2, 5.1.8.2

OUI, 3.3

P

パラメータ

手動でのチューニング, E.2.2

パーティション

ASMでの使用, 6.4.1.1

passwdコマンド, 5.1.9.7 パッチのダウンロード場所, 3.8 パッチの更新

ダウンロード, 8.1

インストール, 8.1

My Oracle Support, 8.1

パッチ

ダウンロード場所, 3.8

権限

データ・ファイル・ディレクトリ, 6.3.8, 6.3.9

pingコマンド, A.9 ポリシー管理データベース

SCAN, D.2.5

インストール後

パッチのダウンロードおよびインストール, 8.1

事前構成済データベース

ASMディスク領域要件, 6.4.1.1

ASMを使用する場合の要件, 6.4.1.1

プライマリ・ホスト名, 1.1.3 権限を付与されたグループ

Oracle Database, 5.1.7.1.2, 5.1.8.2

プロセッサ

システム・アーキテクチャの確認, 2.1

.profileファイル, 5.2.2 パブリック・ノード名

プライマリ・ホスト名, 1.1.3

pvdisplayコマンド, 6.4.1.4

R

RAC

HP-UXでのASMのディスクの構成, 6.4.1.4

RAID

Oracle Cluster Registryおよび投票ディスクのミラー化, 6.2.1

ASMの推奨冗長レベル, 6.4.1.1

RAWデバイス

サポート対象外, 6.1.1

既存のパーティションのアップグレード, 6.2.1

推奨事項

クラスタへのクライアント・アクセス, 8.2.4

リカバリ・ファイル

サポートされている記憶域オプション, 6.1.1

冗長レベル

事前構成済データベースの領域要件, 6.4.1.1

冗長インターコネクトの使用, 4.3 冗長インタフェース

同一のIPプロトコルを使用する必要性, 4.4

Oracle Grid Infrastructureホーム・バイナリの再リンク, 8.4, 9.3, 9.4 要件, 6.4.1.1 resolv.confファイル, A.9 レスポンス・ファイル・モードでのインストール

準備, C.2

レスポンス・ファイル

テンプレート, C.2

サイレント・モード, C.3 レスポンス・ファイル・モード

概要, C.1

使用する理由, C.1.1

「レスポンス・ファイル」および「サイレント・モード」も参照

レスポンス・ファイル

概要, C.1

テンプレートで作成, C.2.1

crs_install.rsp, C.2.1

dbca.rsp, C.2.1

enterprise.rsp, C.2.1

一般的な手順, C.1.2

Net Configuration Assistant, C.4

netca.rsp, C.2.1

コマンドラインでの値の引渡し, C.1

Oracle Universal Installerでの指定, C.3

レスポンス・ファイル, 「サイレント・モード」を参照

概要, C.1

使用する理由, C.1.1

「レスポンス・ファイル」も参照,

ローリング・アップグレード

Oracle ASM, B.9.5

rootユーザー

ログインに使用, 3.4

rootcrs.pl

Oracle Flex Clusterの削除の制限事項, 9.5

roothas.sh, 9.6.1 root.sh, 7.1.1 rsizeパラメータ, 6.3.2 実行レベル, 2.2

S

SAM, E.2.2

起動, E.2.2.2

samコマンド, E.2.2.2 SCANアドレス, 1.1.3, A.9 SCANリスナー, A.9, D.2.5 SCAN, 1.1.3, 4.5.5

クライアント・アクセス, 8.2.4

構成, 1.1.3

説明, 8.2.4

理解, D.2.5

ポリシー管理データベースのクライアントに必要なSCANの使用, D.2.5

セキュア・シェル

インストーラによる構成, 3.10

セキュリティ

Oracleソフトウェアの所有権の分割, 5.1.7

semmniパラメータ

最小値, E.2.1

semmnsパラメータ

最小値, E.2.1

semmnuパラメータ

最小値, E.2.1

semvmxパラメータ

最小値, E.2.1

Serviceguard

要件, 3.6

カーネル・パラメータの設定, E.2.2.2 シェル

oracleユーザーのデフォルトのシェルの確認, 5.2.2

環境変数SHELL

値の確認, 5.2.2

シェル起動ファイル

編集, 5.2.2

環境変数の削除, 5.2.2

shmmaxパラメータ

最小値, E.2.1

shmmniパラメータ

最小値, E.2.1

shmsegパラメータ

最小値, E.2.1

サイレント・モード・インストール, C.3 ソフトウェア要件, 3.5

ソフトウェア要件の確認, 3.8

ssh

X11転送, 5.2.3

OUIからの自動構成, 3.10

構成, E.1

使用時, 3.10

標準クラスタ

アップグレード結果, B.5

起動ファイル

シェル, 5.2.2

stty

インストール・エラーを回避するための抑止, 5.2.4

サポートされている記憶域オプション

Oracle Clusterware, 6.1.1

抑制モード

使用する理由, C.1.1

シンボリック・リンク

Xライブラリの必須のリンク, 3.11

SYSASM, 5.1.7.1.3

OSASM, 5.1.7.1.3

SYSASMシステム権限, 5.1.8.4 SYSBACKUPDBAシステム権限, 5.1.8.3 SYSDBA

ASMでのデータベースSYSDBAの使用は非推奨, 5.1.7.1.3

ASM用のSYSDBAシステム権限, 5.1.8.4 SYSDBA権限

関連するグループ, 5.1.7.1.2

SYSDBAシステム権限

関連するグループ, 5.1.8.2

SYSDGDBAシステム権限, 5.1.8.3 SYSKMDBAシステム権限, 5.1.8.3 ASM用のSYSOPERシステム権限, 5.1.8.4 SYSOPER権限

関連するグループ, 5.1.7.1.2

SYSOPERシステム権限

関連するグループ, 5.1.8.2

システム管理マネージャ

「SAM」を参照

System Administration Manager (SAM), E.2.2.2, E.2.2.2 システム・アーキテクチャ

確認, 2.1

システム権限

SYSASM, 5.1.8.4

SYSBACKUPDBA, 5.1.8.3

SYSDBA, 5.1.8.2

ASM用のSYSDBA, 5.1.8.4, 5.1.8.4

SYSDGDBA, 5.1.8.3

SYSKMDBA, 5.1.8.3

SYSOPER, 5.1.8.2

ASM用のSYSOPER, 5.1.8.4

T

TEMP環境変数, 2.1, 2.3

設定, 5.2.2

端末出力コマンド

Oracleインストール所有者アカウントのための抑止, 5.2.4

サード・パーティのマルチキャストDNS

制限, 4.5.3

TMPDIR環境変数, 2.1, 2.3

設定, 5.2.2

TNS_ADMIN環境変数

設定の削除, 5.2.2

トラブルシューティング

削除, 9.1

asmcmdエラーおよびOracleホーム, 5.1.3.1

OUIからの自動SSH構成, 3.10, 5.1.3.1

ディスク領域エラー, 1.1.2

DISPLAYエラー, 5.2.3

環境パス・エラー, 1.1.2

ログ・ファイルのスクリプト入力のガベージ文字列, 5.2.4

GID, 5.1.3.3

断続的なハングアップ, 7.3

ログ・ファイル, 7.1.1

NFSマウント, 3.13

権限エラーとoraInventory, D.1.3

パブリック・ネットワーク障害, 3.13

root.shエラー, 9.5

実行レベル・エラー, 2.2

SQLPlusエラーおよびOracleホーム, 5.1.3.1

ssh, E.1.1

SSH構成の失敗, E.1.2.1

sshエラー, 5.2.4

SSHタイムアウト, A.2

sttyエラー, 5.2.4

UID, 5.1.3.3

root.shエラーの原因修正のためのOracle Clusterwareの構成解除, 9.5

不明なインストールのエラー, 1.1.6, A.6

ユーザー等価関係, A.4, E.1.1

異なるユーザーIDとグループIDによるユーザー等価関係エラー, 5.1.9.6.2

ユーザー等価関係エラー, 5.1.2, D.1.4

X11転送エラー, 5.2.3

トラブルシューティング

DBCAがOracle ASMディスク・サイズを認識せずディスク・グループの作成に失敗, 8.3.3

U

uid

既存の確認, 5.1.9.7

指定, 5.1.9.7

他のノードでの指定, 5.1.9.7

サポートされていない既存のインストール所有者のUIDの変更, 5.1.3.3 umaskコマンド, 5.2.1 unameコマンド, 3.8 Oracle Clusterwareの構成解除, 9.5 アンインストール, 9.1 削除, 9.1 UNIXコマンド

chmod, 6.4.1.4

chown, 6.4.1.4

ioscan, 6.4.1.4

pvdisplay, 6.4.1.4

sam, E.2.2.2

uname, 3.8

unset, 5.2.2

unsetenv, 5.2.2

接続不可ノード

アップグレード, B.9.3

unsetコマンド, 5.2.2 unsetenvコマンド, 5.2.2 アップグレード

リーフ・ノード, B.5

OCRパーティション・サイズ, 6.2.1

Oracle ASMのローリング・アップグレード, B.9.5

SCAN, D.2.5

投票ディスク・パーティション・サイズ, 6.2.1

ベスト・プラクティス, 3.1.1

Oracle ASM, B.9.5.1

制限事項, B.5

ローカルのGridホームに対する共有のOracle Clusterwareホーム, D.1.1

環境変数の設定の削除, B.6.1

アップグレード

アクセス不可ノード, B.9.3

ユーザー等価関係

テスト, A.4

ユーザー等価関係エラー

グループおよびユーザー, 5.1.9.6.2

ユーザーID

既存の確認, 5.1.9.7

指定, 5.1.9.7

他のノードでの指定, 5.1.9.7

useraddコマンド, 5.1.3.3, 5.1.9.6.3, 5.1.9.7 ユーザー

他のノードでの同一ユーザーの作成, 5.1.9.7, 5.1.9.7

gridユーザーの作成, 5.1.3, 5.1.3

oracleユーザーの作成, 5.1.3.2, 5.1.3.2, 5.1.9.6.1, 5.1.9.6.1, 5.1.9.6.2, 5.1.9.6.2

Oracleソフトウェア所有者ユーザー(oracle), 5.1.7.1.1

Oracleソフトウェア所有者ユーザー, 5.1.8.1

作成時のグループの指定, 5.1.9.7, 5.1.9.7

NISの使用, 5.1.7, 5.1.9.7

V

ベンダーのクラスタウェア

Oracle Grid Infrastructureのクラスタ名, 1.1.3

VIP

SCAN, A.9

投票ディスク

構成, 1.1.5

ミラー化, 6.2.1

パーティション・サイズ, 6.2.1

サポートされている記憶域オプション, 6.1.1

W

WebSphere MQ

CSDのダウンロード場所, 3.8

ワークステーション

インストール, 3.4

wsizeパラメータ, 6.3.2 wtmax, 6.2.4.2

Direct NFSクライアントの最小値, 6.2.4.2

X

Xエミュレータ

インストール, 3.4

Xライブラリのシンボリック・リンク

必須, 3.11

X端末

インストール, 3.4

X Window System

リモート・ホストの有効化, 3.4, 3.4

X11転送

エラー, 5.2.3

X11転送エラー, E.1.3 xhostコマンド, 3.4 xtermコマンド, 3.4 xtitle

インストール・エラーを回避するための抑止, 5.2.4

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。