Oracle® Grid Infrastructure

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

11gリリース2 (11.2) for IBM AIX on POWER Systems (64-Bit)

B57777-08(原本部品番号:E48294-03)

2016年12月

Oracle Grid Infrastructureインストレーション・ガイド, 11gリリース2 (11.2) for IBM AIX on POWER Systems (64-Bit)

B57777-08

Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved.

原本著者: Aparna Kamath

原本協力者: Douglas Williams、Mark Bauer、Jonathan Creighton、Prakash Jashnani、Barb Lundhild、Saar Maoz、Sundar Matpadi、Markus Michalewicz、Hanlin Qian、Dipak Saggi、Ara Shakian

協力者: Alex Huang、Rache Wang

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

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

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

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のインストールおよび構成に関する新機能

- リリース2(11.2.0.4)の新機能

- リリース2 (11.2.0.4)でサポート対象外となったオプション

- リリース2(11.2.0.3)の新機能

- リリース2(11.2.0.2)の新機能

- リリース2(11.2)の新機能

- リリース1(11.1)の新機能

1 クラスタ用Oracle Grid Infrastructureの標準インストール

- 1.1 標準インストールと拡張インストール

- 1.2 標準インストールを使用して実行するインストール前の手順

- 1.3 手作業を必要とするインストール前の手順

- 1.3.1 システム要件の確認

- 1.3.2 ネットワーク要件の確認

- 1.3.2.1 クラスタの単一クライアント・アクセス名(SCAN)

- 1.3.2.2 IPアドレス要件

- 1.3.2.3 冗長インターコネクトの使用

- 1.3.2.4 ネットワーク・インタフェースの意図した使用方法

- 1.3.3 オペレーティング・システム・パッケージの確認

- 1.3.4 グループおよびユーザーの作成

- 1.3.5 Oracleインストール所有者のシェル制限の構成

- 1.3.6 記憶域の確認

- 1.3.7 Oracle Automatic Storage Management用の記憶域の準備

- 1.3.8 Oracle Grid Infrastructureソフトウェアのインストール

2 クラスタ用Oracle Grid Infrastructureの拡張インストール前の作業

- 2.1 アップグレードのベスト・プラクティスの確認

- 2.2 インストール修正スクリプト

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

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

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

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

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

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

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

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

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

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

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

- 2.4.5.2 役割区分によるデータベース・グループおよびユーザーの作成

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

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

- 2.5 ハードウェア要件の確認

- 2.6 ネットワーク要件の確認

- 2.6.1 ネットワーク・ハードウェア要件

- 2.6.2 IPアドレス要件

- 2.6.2.1 グリッド・ネーミング・サービスのIPアドレス要件

- 2.6.2.2 手動で構成する場合のIPアドレス要件

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

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

- 2.6.5 グリッド・ネーミング・サービスへのドメイン委任のためのDNS構成

- 2.6.6 グリッド・ネーミング・サービスの構成例

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

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

- 2.7 ソフトウェア要件の特定

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

- 2.9 UDPおよびTCPカーネル・パラメータの検証

- 2.10 AIXのリソース制限のチェック

- 2.11 AIXシステム環境のチューニング

- 2.11.1 非同期入出力プロセスの確認

- 2.11.2 Virtual Memory Manager(VMM)のチューニング

- 2.11.3 システムのブロック・サイズ割当ての追加

- 2.11.4 AIXでのSSH LoginGraceTimeパラメータの構成

- 2.11.5 シェル制限の構成

- 2.11.6 ユーザー・プロセス・パラメータの構成

- 2.11.7 ネットワーク・チューニング・パラメータの構成

- 2.12 ネットワーク・タイム・プロトコルの設定

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

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

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

- 2.14.2 Oracle DatabaseおよびOracle ASM所有者の環境要件

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

- 2.14.4 表示およびX11転送の構成の設定

- 2.14.5 端末出力が原因のインストール・エラーの回避

- 2.15 rootpre.shスクリプトの実行

- 2.16 hagsuserグループへのグリッド・インフラストラクチャ・インストール所有者の追加

- 2.17 Oracle Grid Infrastructureホーム・ディレクトリの作成要件

- 2.18 クラスタ名の要件

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

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

- 3.1.1 Oracle ClusterwareおよびOracle RACの記憶域オプションの概要

- 3.1.1.1 既存の9.2クラスタウェア・インストールでの定数ディスクの位置の制限

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

- 3.1.2 Oracle ACFSの一般情報

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

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

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

- 3.1.4 ストレージにOracle ASMディスク・グループを使用するときのガイドライン

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

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

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

- 3.2 共有ファイル・システムの記憶域の構成

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

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

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

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

- 3.2.3.2 Direct NFSクライアントでのoranfstabファイルの使用

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

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

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

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

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

- 3.2.7 HACMP Multinode Disk Heartbeat(MNDHB)の構成

- 3.2.7.1 Oracle ClusterwareでHACMPを使用するための要件の概要

- 3.2.7.2 Oracle Clusterwareに対するHACMPおよびMDNDHBのデプロイ

- 3.2.7.3 既存のOracle ClusterwareおよびHACMPインストールのアップグレード

- 3.2.8 Oracle Clusterware用のRAW論理ボリュームの構成

- 3.2.9 新しいOracle Clusterwareボリューム・グループへのRAW論理ボリュームの構成

- 3.2.10 データベース・ファイル用のボリューム・グループの作成

- 3.2.11 Oracle Clusterware用のボリューム・グループの作成

- 3.2.12 他のクラスタ・ノードでのボリューム・グループのインポート

- 3.2.13 べてのクラスタ・ノードでのコンカレント・モードによるボリューム・グループのアクティブ化

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

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

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

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

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

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

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

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

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

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

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

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

- 3.3.5 Oracle Automatic Storage Managementクラスタ・ファイル・システムの構成

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

- 3.4 RAWディスクのサポート終了

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

- 4.1 OUIを使用してOracle Grid Infrastructureをインストールするための準備

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

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

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

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

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

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

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

- 4.4 Oracle Berkeley DBの制限事項

- 4.5 Oracle Clusterwareの機能の確認

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

- 4.7 Oracle Clusterwareの機能の確認

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

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

- 5.1.1 パッチの更新のダウンロードおよびインストール

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

- 5.2.1 root.shスクリプトのバックアップ

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

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

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

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

- 5.2.4 RACcheck構成監査ツールの実行

- 5.3 旧バージョンのOracle DatabaseのGrid Infrastructureでの使用

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

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

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

- 5.3.4 Oracle Databaseリリース9.2のためのグローバル・サービス・デーモン(GSD)の有効化

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

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

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

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

- 6.2 Oracle RestartからOracle Clusterwareへの移行

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

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

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

- 6.6 Oracle ClusterwareとOracle ASMの削除

- 6.6.1 削除ツールについて

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

- 6.6.3 失敗したインストールで使用するための削除ツールのダウンロード

- 6.6.4 削除ツールの実行

- 6.6.5 Oracle ClusterwareとOracle ASMの削除コマンドの例

- 6.6.6 クラスタ用グリッド・インフラストラクチャの削除パラメータ・ファイルの例

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

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

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

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

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

- A.5 AIXでのトラブルシューティング

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- C.1.1 Oracleグループおよびユーザーの理解

- C.1.1.1 Oracle Inventoryグループの理解

- C.1.1.2 Oracle Inventoryディレクトリの理解

- C.1.2 Oracleベース・ディレクトリのパスの理解

- C.1.2.1 Oracleベース・ディレクトリの概要

- C.1.2.2 Oracleベース・ディレクトリとグリッド・インフラストラクチャ・ディレクトリの理解

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

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

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

- C.1.3.3 仮想IPアドレスについて

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

- C.1.3.5 SCANについて

- C.1.4 ネットワークの時刻要件の理解

- C.2 記憶域の構成の理解

- C.2.1 Oracle Automatic Storage Managementクラスタ・ファイル・システムの理解

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

- C.2.3 スタンドアロンのOracle ASMインストールからクラスタ化されたインストールへの変換について

- C.3 サーバー・プールの理解

- C.3.1 サーバー・プールおよびポリシー・ベース管理の概要

- C.3.2 サーバー・プールの動作

- C.3.3 空きサーバー・プール

- C.3.4 汎用サーバー・プール

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

D インストールの前提条件の作業を手動で行う方法

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

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

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

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

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

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

E Oracle Grid Infrastructure 11gリリース2へのアップグレード方法

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

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

- E.3 Oracle ASMおよびOracle Grid Infrastructureのインストールおよびアップグレードについて

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

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

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

- E.5.2 Oracle RACcheckアップグレード準備状況評価の実行

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

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

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

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

- E.7 前のリリースからのローリング・アップグレードの実行

- E.7.1 Oracle Clusterwareのローリング・アップグレードの実行

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

- E.7.2.1 Oracle ASMをアップグレードするための準備

- E.7.2.2 Oracle ASMのアップグレード

- E.8 DB ControlおよびGrid Controlのターゲット・パラメータの更新

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

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

- E.11 アップグレード後のクラスタ状態モニターのリポジトリ・サイズの確認

索引

表一覧

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

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

- 2-3 AIXオペレーティング・システムのカーネル要件

- 2-4 AIX APARおよびその他のオペレーティング・システム修正

- 2-5 Virtual Memory Managerの推奨値

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

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

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

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

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

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

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

はじめに

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

対象読者

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

Oracle Real Application Clusters(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 IBM AIX on POWER Systems(64-Bit)』を参照してください。

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

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

- 『Oracle Databaseインストレーション・ガイド for IBM AIX on POWER Systems(64-Bit)』

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

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

- 『Oracle Database管理者リファレンス 11g リリース2(11.2) 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のユーザー名およびパスワードを取得している場合は、次のURLでOTN Webサイトのドキュメントのセクションに直接接続できます。

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

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

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

Oracle Grid Infrastructureのインストールおよび構成に関する新機能

ここでは、Oracle Grid Infrastructure(Oracle ClusterwareとOracle Automatic Storage Management)およびOracle Real Application Clusters(Oracle RAC)のインストールおよび構成に関連する新機能について説明します。このマニュアルは、『Oracle Clusterwareインストレーション・ガイド』に置き換るものです。内容は次のとおりです。

- リリース2(11.2.0.4)の新機能

- リリース2 (11.2.0.4)でサポート対象外となったオプション

- リリース2(11.2.0.3)の新機能

- リリース2(11.2.0.2)の新機能

- リリース2(11.2)の新機能

- リリース1(11.1)の新機能

リリース2(11.2.0.4)の新機能

リリース2(11.2.0.4)の新機能は、次のとおりです。

クラスタおよびOracle RAC診断ツールの拡張機能

Oracle Grid Infrastructure 11gリリース2 (11.2.0.4)以上から、Oracle Grid Infrastructureをインストールすると、トレース・ファイル・アナライザおよびコレクタが自動的にインストールされます。トレース・ファイル・アナライザおよびコレクタは、Oracle Clusterware、Oracle Grid InfrastructureおよびOracle RACシステムの診断データの収集を簡素化する、診断を収集するためのユーティリティです。

注意:
トレース・ファイル・アナライザおよびコレクタは、Oracle Grid Infrastructure 11gリリース2 (11.2.0.4)以上で使用可能です。

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

Oracle Databaseのヘルス・チェックおよびベスト・プラクティスの推奨事項

Oracle Grid Infrastructure 11gリリース2 (11.2.0.4)に含まれるOracle RAC構成監査ツール(RACcheck)では、構成の既知の問題、ベスト・プラクティス、通常のヘルス・チェックおよびアップグレード前後のベスト・プラクティスに対して、単一インスタンスおよびOracle RACデータベースのインストールを評価できます。

注意:
Oracle RAC構成監査ツールは、Oracle Grid Infrastructure 11gリリース2 (11.2.0.4)以上に含まれています。

関連項目:
『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

リリース2 (11.2.0.4)でサポート対象外となったオプション

Oracle Grid Infrastructure 11gリリース2 (11.2.0.4)では、次の機能のサポートが終了しています。

OUIでのブロック・デバイスおよびRAWデバイスの非サポート

このリリースでは、ブロック・デバイスまたはRAWデバイスへのOracle ClusterwareファイルのインストールがOUIでサポートされなくなりました。Oracle Clusterwareファイルは、Oracle Automatic Storage Managementディスク・グループまたはサポートされている共有ファイル・システムのいずれかにインストールしてください。

-cleanupOBaseの非推奨

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

リリース2(11.2.0.3)の新機能

リリース2(11.2.0.3)の新機能は、次のとおりです。

Oracle Clusterware(CHM)に含まれたクラスタ状態モニター

11.2.0.3.0では、AIXでクラスタ状態モニター(CHM)を使用できます。クラスタ状態モニターはリアルタイムにオペレーティング・システムのメトリックを収集し、後で分析するためにリポジトリに格納します。これによって、Oracleサポートの支援を受けながら、Oracle ClusterwareおよびOracle RACの多くの問題の原因を判断できるようになります。

また、クラスタ状態モニターは、ノードでのメモリーのオーバーコミットメントを検出するためのメトリックを提供することによって、Oracle Databaseにおけるサービスのクオリティ管理(QoS)とあわせて使用することもできます。QoS管理は、負荷を軽減するためにオーバーロードしたノードのサービスを停止して、既存のワークロードを保持することができます。

QoS管理をサポートするために、Oracle Database Resource Managerおよびメトリックは、ファイン・グレイン・パフォーマンス・メトリックをサポートするように拡張され、ユーザー定義のパフォーマンス・クラスを使用してワーククロードを管理できるようにもなりました。

AIXに対するOracle ACFSおよびADVMの拡張サポート

ACFS(ACFSスナップショットを含む)およびADVMは、AIX 7.1およびAIX 6.1に対するAIX 6.1 TL4 SP2以上の更新(PPC64のみ)でサポートされています。

Oracle Clusterwareのアップグレード構成の強制機能

アップグレードの途中でノードにアクセスできなくなった場合、リリース11.2.0.3以上では、-forceフラグを指定してrootupgrade.shスクリプトを実行し、アップグレードを強制的に完了させることができます。

リリース2(11.2.0.2)の新機能

リリース2(11.2.0.2)の新機能は、次のとおりです。

Oracle Grid Infrastructureソフトウェアの構成ウィザード

Oracle Grid Infrastructure構成ウィザードを使用して、ソフトウェアのみのインストールを行った後にOracle Grid Infrastructureソフトウェアを構成できます。このウィザードでは、順を追ってプロセスが進められるため、config_params構成ファイルを手動で編集する必要がなくなりました。

関連項目:
構成ウィザードの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

拡張されたパッチ・セットのインストール

Oracle Grid Infrastructure 11gリリース2(Oracle ClusterwareおよびOracle Automatic Storage Management)のリリース11.2.0.2以降のパッチ・セットでは、Oracle Grid Infrastructureのパッチ・セットによってOracle Grid Infrastructureソフトウェアが完全にインストールされます。新しいパッチ・セットのパッケージの次の変更に注意してください。

- 以前のリリース(11.x、10.x)からの最新のパッチ・セットへの直接アップグレードがサポートされます。

- 新規インストールでは、基になるリリースをインストールしてからパッチ・リリースにアップグレードするのではなく、最新のパッチ・セットをインストールします。

- アウトオブプレース・パッチ・セット・アップグレードのみがサポートされます。アウトオブプレース・アップグレードでは、新しい個別のホームにパッチ・セットをインストールします。

関連項目:
My Oracle SupportのNote 1176177「Important Changes to Oracle Database Patch Sets Starting With 11.2.0.2」を参照してください。次のURLから入手可能です。
https://support.oracle.com

Oracle ACFSおよびADVMでのAIXのサポート

ASM用のOracle ASM 11g リリース2(11.2.0.2)以上では、ACFSスナップショットを含む、Oracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)およびOracle ASM動的ボリューム・マネージャ(ADVM)がサポートされます。

ACFS(ACFSスナップショットを含む)およびADVMは、AIX 6.1(PPC64)に対するAIX 6.1 TL4 SP2以上の更新でのみサポートされています。

Oracle Clusterwareに含まれたクラスタ状態モニター

クラスタ状態モニターはリアルタイムにオペレーティング・システムのメトリックを収集し、後で分析するためにリポジトリに格納します。これによって、Oracleサポートの支援を受けながら、Oracle ClusterwareおよびOracle RACの多くの問題の原因を判断できるようになります。

また、クラスタ状態モニターは、ノードでのメモリーのオーバーコミットメントを検出するためのメトリックを提供することによって、Oracle Databaseにおけるサービスのクオリティ管理(QoS)とあわせて使用することもできます。QoS管理は、負荷を軽減するためにオーバーロードしたノードのサービスを停止して、既存のワークロードを保持することができます。

QoS管理をサポートするために、Oracle Database Resource Managerおよびメトリックは、ファイン・グレイン・パフォーマンス・メトリックをサポートするように拡張され、ユーザー定義のパフォーマンス・クラスを使用してワーククロードを管理できるようにもなりました。

グリッド・インストールの所有者およびASMOPER

インストール中に「権限付きオペレーティング・システム・グループ」ウィンドウでグループをASM用のOSOPERグループとして指定することはオプションになりました。ASM用のOSOPERグループを作成する場合は、すべてのクラスタ・メンバー・ノードで構成したグループ名をASM用のOSOPERグループとして入力できます。また、Oracle Grid Infrastructureのインストール所有者は、メンバーである必要がなくなりました。

新しいソフトウェア更新オプション

ソフトウェアの更新機能を使用し、Oracle Databaseインストールの一部として、ソフトウェアの更新を動的にダウンロードして適用します。更新のダウンロード・オプションを使用して更新を個別にダウンロードし、更新が格納されている場所を指定することによって、インストール中に後で適用することもできます。

冗長インターコネクトの使用

以前のリリースでは、インターコネクトに冗長ネットワークを使用するには、ボンディング、トランキング、チーム化などのテクノロジが必要でした。現在、Oracle Grid InfrastructureおよびOracle RACは冗長ネットワーク・インターコネクトを使用できるようになり、他のネットワーク・テクノロジを使用しなくても、クラスタ内の最適な通信を拡張できるようになりました。この機能は、Oracle Database 11g リリース2(11.2.0.2)以上で使用可能です。

冗長インターコネクトを使用することによって、複数(最大4つ)のプライベート・ネットワーク(インターコネクトとも呼ばれる)におけるロード・バランシングおよび高可用性が実現します。

Oracle Databaseのサービスのクオリティ管理

データベースにおけるサービスのクオリティ管理(QoS)サーバーを使用すると、正確な実行時パフォーマンスとリソース・メトリックを関連付け、エキスパート・システムで分析することによって、システム管理者がOracle Databaseクラスタに干すティングされたアプリケーションのサービス・レベルを管理できるようになり、ポリシー・ベースのパフォーマンス目的を満たす推奨リソース調整を生成することができます。

関連項目:
『Oracle Database Quality of Service Managementユーザーズ・ガイド』

リリース2 (11.2)の新機能

Oracle ClusterwareおよびOracle ASM 11gリリース2 (11.2)のインストールに関する新機能は、次のとおりです。

自動ストレージ管理およびOracle Clusterwareのインストール

Oracle Grid Infrastructure 11gリリース2(11.2)では、Oracle Automatic Storage Management(Oracle ASM)およびOracle Clusterwareが1つのホーム・ディレクトリ(Grid Infrastructureホーム)にインストールされます。インストーラのインタビュー・プロセスが終了すると、Oracle ASMおよびOracle Clusterwareを構成するConfiguration Assistantが起動します。

これらの製品を組み合せたインストール環境をOracle Grid Infrastructureと呼びます。ただし、Oracle ClusterwareとOracle Automatic Storage Managementは依然として別々の製品です。

関連項目:
スタンドアロン・サーバー用のOracle Grid Infrastructure(Oracle ASMおよびOracle Clusterwareバイナリ)をインストールする方法の詳細は、IBM AIX on POWER Systems(64-Bit)用の『Oracle Databaseインストレーション・ガイド』を参照してください。この機能によって、シングル・インスタンス・サーバーの高可用性が保証されます。

自動ストレージ管理およびOracle Clusterwareのファイル

このリリースでは、Oracle Cluster Registry(OCR)および投票ディスクをOracle Automatic Storage Management(Oracle ASM)に配置できます。

この機能により、Oracle ASMは、統合ストレージ・ソリューションとして、他社のボリューム・マネージャやクラスタ・ファイル・システムを使用せずに、クラスタウェアおよびデータベースのすべてのデータを保存できます。

新しいインストール環境では、Oracle ASM、クラスタ・ファイル・システムまたはNFSシステムのいずれかにOCRと投票ディスクのファイルを配置できます。既存システムがアップグレードされる場合を除いて、RAWデバイスまたはブロック・デバイスへのOracle Clusterwareファイルのインストールはサポートされなくなりました。

SYSASMによるOracle ASM役割区分オプション

Oracle ASM 11gリリース1(11.1)で導入されたSYSASM権限が、SYSDBA権限と完全に分離されました。このオプション機能を使用すると、OSASMおよびOSDBAグループとして異なるオペレーティング・システム・グループを指定した場合に、OSASMグループのメンバーのみがSYSASM管理権限を使用できます。Oracle ASMインスタンス上でパスワード認証を使用して、SYSASM権限を付与することもできます。

OPERATOR権限(ASMの起動および停止権限を含む、SYSASM権限のサブセット)をASMグループのOSOPERのメンバーに指定できます。

SYSDBA権限のかわりにSYSASM権限を使用して記憶域層に対するシステム権限を付与すると、Oracle ASM管理とデータベース管理での役割を明確に区別できます。また、同じ記憶域を使用する異なるデータベース間で、互いのファイルを誤って上書きするのを防ぐこともできます。

関連項目:
『Oracle Databaseストレージ管理者ガイド』

クラスタ時刻同期化サービス

クラスタ・ノードの時刻は、同期させておく必要があります。このリリースのOracle Clusterwareでは、同期サービスがクラスタ内にあることを保証するクラスタ時刻同期化サービス(CTSS)を提供しています。クラスタの構成時にネットワーク・タイム・プロトコル(NTP)が検出されなかった場合は、CTSSが構成されて時刻の同期が保証されます。

Enterprise Manager Database Controlのプロビジョニング

Enterprise Manager Database Control 11gには、Oracle Grid InfrastructureおよびOracle RACのインストール環境を新しいノードに自動的にプロビジョニングし、そのノードに対してOracle Grid InfrastructureおよびOracle RACの既存のデータベースを拡張する機能があります。このプロビジョニング手順を実行するには、この機能を使用する前にOracle RACが正しくインストールされている必要があります。

関連項目:
この機能の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

修正スクリプトおよびグリッド・インフラストラクチャのチェック

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

修正スクリプトはインストール中に生成されます。rootとして別の端末セッションでスクリプトを実行するように求められます。スクリプトを実行すると、必要に応じて各カーネル値を最小要件まで引き上げ、その他のオペレーティング・システム構成タスクが完了します。

クラスタ検証ユーティリティ(CVU)で、インストールの前に修正スクリプトを生成することもできます。

グリッドのプラグ・アンド・プレイ

これまでは、クラスタ内のサーバーを追加または削除しようとすると、様々な準備を手動で行う必要がありました。今回のリリースでは、引続き手動でサーバー・ノードを構成することも、クラスタでノードが追加または削除されたときに、グリッドのプラグ・アンド・プレイを使用して動的に構成することもできます。

グリッドのプラグ・アンド・プレイは、サーバー・ノードのインストール、構成および管理にかかるコストを低減できます。これは、クラスタ内でグリッド・ネーミング・サービスを起動し、各ノードで次のタスクを動的に実行できるようすることで実現されます。

- ノードの適切なネットワークIDをネゴシエートする。

- 動作に必要な追加情報を構成プロファイルから取得する。

- プロファイル・データを使用してノードを構成または再構成し、ホスト名およびアドレスをネットワーク上で解決可能にする。

これらのタスクはサーバーによって動的に実行されるため、ノードの追加または削除に必要な手順は最小限です。

Oracle Clusterwareのアウトオブプレース・アップグレード

このリリースでは、既存のOracle Clusterwareインストール環境とは別のホームに新しいバージョンのOracle Clusterwareをインストールできます。この機能により、クラスタ内のノードのアップグレードに必要な停止時間が短縮されます。アウトオブプレース・アップグレードを行う場合、ソフトウェアの新旧バージョンがノード上で同時に、それぞれ異なるホームの場所に存在することになりますが、アクティブになるソフトウェア・バージョンは1つのみです。

Oracle Enterprise Managerを使用したOracle Clusterwareの管理

このリリースでは、高可用性アプリケーションおよびOracle Cluster Resource Managementを使用し、スタンドアロン・データベース環境とOracle RAC環境の両方について、Oracle Enterprise Managerの「クラスタ・ホーム」ページから、すべての管理および監視を行うことができます。

Oracle Enterprise ManagerがOracle Clusterwareとともにインストールされている場合は、Oracle Enterprise ManagerでOracle Clusterwareの管理者ロールを持つ一連のユーザーが用意されており、高可用性アプリケーションおよびOracle Clusterwareのリソース管理に必要なすべての管理および監視を実行できます。インストールが完了してOracle Enterprise Managerをデプロイしたら、Oracle Enterprise Managerを使用して、クラスタに追加するノードのプロビジョニングを実行できます。

SCANによるクライアント・アクセスの簡略化

このリリースでは、単一クライアント・アクセス名(SCAN)が、クラスタに接続するすべてのクライアントに提供されるホスト名です。SCANは、ドメイン・ネーム・サービス(DNS)またはグリッド・ネーミング・サービス(GNS)のいずれかにある、1つ以上3つ以下のIPアドレスに登録されたドメイン名です。SCANによって、クラスタに対してノードを追加または削除するときに、クライアントを変更する必要がなくなります。SCANを使用するクライアントは、EZCONNECTを使用してクラスタにアクセスすることもできます。

パッチ処理に対するSRVCTLコマンドの機能強化

このリリースでは、パッチ処理の準備をするために、srvctlを使用して、Oracleホーム内で実行されているすべてのOracleソフトウェアを停止できます。Oracle Grid Infrastructureのパッチ処理は、すべてのノードで自動化されています。パッチは、複数のノードにマルチパッチ方式で適用できます。

標準インストール・オプション

クラスタのインストールを簡単に行うため(特にクラスタリングを初めて使用するお客様向けに)、標準インストールによる方法を使用できるようになりました。標準インストールでは、できるかぎり多くのオプションを、ベスト・プラクティスとして推奨されるデフォルト設定にします。

投票ディスクのバックアップ手順の変更

以前のリリースでは、ddコマンドを使用して投票ディスクをバックアップする作業が、インストール後に必要でした。Oracle Clusterwareリリース11.2以上では、ddコマンドを使用した投票ディスクのバックアップとリストアはサポートされていません。

手動による投票ディスクのバックアップは、必要なくなりました。構成が変更されると、その一環としてOCRで自動的に投票ディスクがバックアップされ、そして投票ディスクが追加されると、投票ディスクのデータが自動的にリストアされるためです。

関連項目:
『Oracle Clusterware管理およびデプロイメント・ガイド』

リリース1(11.1)の新機能

リリース1(11.1)の新機能は、次のとおりです。

インストールに関するマニュアルでの変更

Oracle Database 11gリリース1では、Oracle Clusterwareを独立した製品としてインストールおよび構成できるため、記憶域管理に関して追加のマニュアルが提供されています。インストール計画については、次のマニュアルを参照してください。

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

このマニュアルでは、2ノードのOracle ClusterwareおよびOracle RAC環境をインストールおよび構成する手順の概要および例を示しています。

Oracle Clusterwareのインストレーション・ガイド

このマニュアル(現在参照中のマニュアル)では、Oracle Clusterwareをスタンドアロン製品としてインストールする手順、またはOracle ClusterwareをOracle DatabaseまたはOracle RACのいずれかとともにインストールする手順について説明しています。システム管理者権限が必要なシステム構成手順が含まれています。

Oracle Real Application Clustersのインストレーション・ガイド

プラットフォームごとに提供されているこのマニュアルでは、Oracle Clusterwareのインストールを正常に完了した後にOracle RACをインストールする手順について説明しています。データベース管理者用のデータベース構成手順が含まれています。

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

このマニュアルでは、ストレージの管理またはOracle Automatic Storage Management(Oracle ASM)の構成および管理を行うデータベース管理者およびストレージ管理者用の情報を記載しています。

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

これは、Oracle Clusterware用の管理者リファレンスです。オペレーティング・システム構成への変更およびOracle Clusterwareのクローニングに関連するタスクを含む管理タスクについて説明しています。

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

Oracle RACの管理者リファレンスです。管理作業についての情報が記載されています。データベースのクローニング、ノードの追加および削除、Oracle Cluster Registry(OCR)の管理、SRVCTLおよびその他のデータベース管理ユーティリティの使用、オペレーティング・システム構成の変更のチューニングなどの作業が含まれます。

インストールに関するリリース1(11.1)の拡張機能および新機能

次に、Oracle Database 11gリリース1(11.1)での拡張機能および新機能を示します。

ASMの管理における新しいSYSASM権限およびOSASMオペレーティング・システム・グループ

この機能では、ASMの管理タスクを実行するための新しいSYSASM権限が導入されています。SYSDBA権限のかわりにSYSASM権限を使用すると、Oracle ASM管理とデータベース管理での役割を明確に区別できます。

OSASMは、Oracle ASM専用に使用する新しいオペレーティング・システム・グループです。OSASMグループのメンバーは、オペレーティング・システム認証を使用してSYSASMとして接続し、Oracle ASMに対して完全なアクセス権を所有しています。

1 クラスタ用Oracle Grid Infrastructureの標準インストール

この章では、クラスタ用Oracle Grid Infrastructureの標準インストールと拡張インストールの違いについて説明し、さらに標準インストールを完了するために必要な手順について説明します。

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

- 標準インストールと拡張インストール

- 標準インストールを使用して実行するインストール前の手順

- 手作業を必要とするインストール前の手順

1.1 標準インストールと拡張インストール

Oracle Grid Infrastructureのインストールには、2つのインストール・オプションがあります。

- 標準インストール: 標準インストール・オプションは、手動による構成選択の数が少ない、簡単なインストールです。ほとんどのクラスタ実装に、このインストール・タイプを選択することをお薦めします。

- 拡張インストール: 拡張インストール・オプションは、より高度なシステム知識を必要とする詳細な手順です。追加の記憶域およびネットワークの選択、ロール・ベースの管理権限のためのオペレーティング・システムのグループ認証の利用、Oracle Automatic Storage Managementロールのより粒度の細かい指定など、詳細に構成を選択できます。

1.2 標準インストールを使用して実行するインストール前の手順

Oracle Clusterware 11gリリース2 (11.2)では、インストール中に、Oracle Universal Installer (OUI)によって修正スクリプト(runfixup.sh)が生成され、このスクリプトを実行すると、インストール前の必要な手順を完了できます。

修正スクリプトは、インストール中に生成されます。rootとして別の端末セッションでスクリプトを実行するように求められます。スクリプトを実行すると、次の構成作業が行われます。

- 必要に応じて、インストールと実行時に必要とされるカーネル・パラメータに、最低限の値が設定されます。

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

- 必要に応じて、シェル制限が必要な値に設定されます。

1.3 手作業を必要とするインストール前の手順

次の手動の構成作業を行います。

- システム要件の確認

- ネットワーク要件の確認

- オペレーティング・システム・パッケージの確認

- グループおよびユーザーの作成

- 記憶域の確認

- Oracle Automatic Storage Management用の記憶域の準備

- Oracle Grid Infrastructureソフトウェアのインストール

関連項目:
これらの作業を行う方法について詳細は、第2章「クラスタ用Oracle Grid Infrastructureの拡張インストール前の作業」と第3章「Oracle Grid InfrastructureおよびOracle RACの記憶域の構成」を参照してください。

1.3.1 システム要件の確認

使用可能なメモリーを確認するには、次のコマンドを入力します。

# /usr/sbin/lsattr -E -l sys0 -a realmem
# /usr/sbin/lsps -a

クラスタ用Oracle Grid Infrastructureインストール用のRAMの最小要件は、2.5GB以上です(Oracle RACをインストールする計画があるインストールを含む)。

スワップ領域の最小要件は1.5GBです。RAMが2.5GBから16GBのシステムでは、RAMと同等のスワップ領域を使用することをお薦めします。2.RAMが16GBを超えるシステムでは、RAMの16GBをスワップ領域に使用します。スワップ領域とGridホームが同じファイルシステム上にある場合は、それぞれ最小領域要件を合計したディスク領域が必要になります。

Oracle Clusterwareファイルで使用可能な領域を確認します。次に例を示します。

GPFSの場合:

/usr/bin/df -k

Oracle ASMディスク・グループのインストール準備としてRAWデバイス・ボリュームを確認するには、次のようにします。

コンカレントVGのRAW論理ボリューム(HACMP)の場合: この例の変数lv_nameは、検証する領域を持つRAW論理ボリューム名です。

lslv lv_name

RAWハード・ディスクの場合: この例の変数rhdisk#は、検証するRAWハード・ディスク番号であり、変数size_mbは、検証するパーティション・サイズ(MB単位)です。

lsattr -El rhdisk# -a size_mb

OCRおよび投票ディスク・ファイルに対して標準の冗長性(3つのOracle Cluster Registry(OCR)および3つの投票ディスク、個々のディスクに別々のファイル・システムを推奨)を使用する場合は、Oracle Clusterwareファイル用に用意されている個々の物理ディスク上で1GB以上のディスク領域が使用可能である必要があります。Oracle Clusterwareファイルの各ファイル・システムのサイズは、280MB以上である必要があります。

注意:
RAWパーティションにOCRまたは投票ディスク・ファイルをインストールすることはできません。インストールできる場所は、Oracle ASM、サポートされているネットワーク接続ストレージまたはクラスタ・ファイル・システムです。RAWデバイスは、ASMディスクとしてのみ使用できます。

Oracle ASMでのOracle Clusterwareファイルの高可用性を確保するには、Oracle Clusterwareファイル用として、別々の3つの障害グループ(物理ディスクは3つ以上)に2GB以上のディスク容量が必要です。各ディスクには1GB以上の容量を確保して、容量に余裕を持ってOracle Clusterwareファイルを作成できるようにする必要があります。

クラスタ用Oracle Grid Infrastructureホーム(Gridホーム)には、13GB以上の領域を確保してください(ここには、Oracle ClusterwareおよびOracle Automatic Storage Management(Oracle ASM)のファイルとログ・ファイル、Oracle ACFSログ・ファイルが含まれ、クラスタ状態モニター・リポジトリが格納されます)。

/usr/bin/df -k /tmp

/tmpに1GB以上の領域があることを確認してください。この領域を確保できない場合は、サイズを大きくするか、または/tmp内の不要なファイルを削除します。

1.3.2 ネットワーク要件の確認

次のものが利用可能であることを確認します。

- クラスタの単一クライアント・アクセス名(SCAN)

- IPアドレス要件

- 冗長インターコネクトの使用

- ネットワーク・インタフェースの意図した使用方法

1.3.2.1 クラスタの単一クライアント・アクセス名(SCAN)

標準インストール中に、実行中のノードに関係なくクラスタ内のデータベースに接続するために使用される、デフォルトの単一クライアント・アクセス名(SCAN)を確認するよう求められます。デフォルトでは、SCANとして使用される名前がクラスタ名にもなります。SCANのデフォルト値は、ローカル・ノード名に基づいています。SCANをデフォルトから変更する場合、使用する名前は、社内全体でグローバルに一意である必要があります。

標準インストールでは、SCANはクラスタ名にもなります。SCANおよびクラスタ名は長さ1文字以上15文字以下の英数字である必要があり、ハイフン(-)も使用できます。

次に例を示します。

NE-Sa89

15文字を超えるSCANが必要な場合は、SCANの最初の15文字がクラスタ名のデフォルトになることに注意してください。

1.3.2.2 IPアドレス要件

インストールを開始する前に、各ノードにインタフェースが2つ以上構成されている必要があります。1つはプライベートIPアドレス用、もう1つはパブリックIPアドレス用です。

1.3.2.2.1 手動で構成する場合のIPアドレス要件

GNSを有効にしない場合、各ノードのパブリックIPアドレスおよび仮想IPアドレスは、静的アドレスであることが必要です。このアドレスは、インストール前に各ノードで構成しておく必要がありますが、現在未使用である必要があります。パブリックIPアドレスと仮想IPアドレスは、同じサブネット内にある必要があります。

インストールのインタビュー時にプライベートとして指定したインタフェース上のプライベート・サブネットに含まれるプライベートIPアドレスが、Oracle Clusterwareによって管理されます。

クラスタには、次のアドレスが構成されている必要があります。

クラスタには、次のアドレスが構成されている必要があります。

- 次の特性がある、各ノードのパブリックIPアドレス:

- 静的IPアドレス

- 各ノードへのインストール前に構成され、インストール前にそのノードに対して解決可能

- 他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある

- 次の特性がある、各ノードの仮想IPアドレス:

- 静的IPアドレス

- 各ノードへのインストール前に構成されるが、現在は使用されていない

- 他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある

- 次の特性がある、クラスタの単一クライアント・アクセス名(SCAN):

- 3つの静的IPアドレスにSCANとして指定された名前が関連付けられ、3つのアドレスすべてがDNSによってリクエスタにランダムな順番で戻されるように、インストール前にその3つのIPアドレスがドメイン・ネーム・サーバー(DNS)に構成されている

- インストール前にDNSで構成され、現在は使用されていないアドレスに解決される

- 数字以外で始まる名前が指定される

- 他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある

- RFC 952標準に準拠し、英数字とハイフン("-")は使用できるが、アンダースコア("_")は使用できない。

- 次の特性がある、各ノードのプライベートIPアドレス:

- 静的IPアドレス

- インストール前に構成され(ただし、別のプライベート・ネットワーク上で、独自のサブネットを使用)、他のクラスタ・メンバー・ノード以外では解決できない

インストール後、クライアントがクラスタにリクエストを送信すると、Oracle ClusterwareのSCANリスナーはクライアント・リクエストをクラスタのサーバーにリダイレクトします。

注意:
SCAN VIPアドレスの構成は、hostsファイルで行わないことを強くお薦めします。SCAN VIPにはDNS解決を使用します。SCANの解決にhostsファイルを使用すると、1つのIPアドレスへの解決しかできず、SCANアドレスは1つのみになってしまいます。

関連項目:
ネットワーク・アドレスの詳細は、付録C「ネットワーク・アドレスの理解」を参照してください。

1.3.2.3 冗長インターコネクトの使用

以前のリリースでは、インターコネクトに冗長ネットワークを使用するには、ボンディング、トランキング、チーム化などのテクノロジが必要でした。現在、Oracle Grid InfrastructureおよびOracle RACは冗長ネットワーク・インターコネクトを使用できるようになり、他のネットワーク・テクノロジを使用しなくても、クラスタ内の最適な通信を拡張できるようになりました。この機能は、Oracle Database 11g リリース2(11.2.0.2)以上で使用可能です。

冗長インターコネクトを使用することによって、複数(最大4つ)のプライベート・ネットワーク(インターコネクトとも呼ばれる)におけるロード・バランシングおよび高可用性が実現します。

1.3.2.4 ネットワーク・インタフェースの意図した使用方法

インストール時に、OUIがクラスタ・ノードで検出するネットワーク・インタフェースごとに計画された使用方法を指定するように求められます。各インタフェースをパブリック、プライベート、または「使用しない」インタフェースとして指定する必要があります。他の目的に使用する予定のインタフェース(ネットワーク・ファイル・システム専用のインタフェースなど)の場合、そのインスタンスがOracle Clusterwareで無視されるように、「使用しない」インタフェースとして指定する必要があります。

冗長インターコネクトを使用しても、パブリックな通信で使用されるインタフェースを保護することはできません。パブリック・インタフェースに高可用性またはロード・バランシングが必要な場合は、サードパーティのソリューションを使用します。通常、これにはボンディング、トランキングなどのテクノロジが使用できます。

プライベート・インタフェースとして使用する複数のインタフェースを選択すると、プライベート・ネットワークで冗長インターコネクトを使用できます。複数のインタフェースをプライベートとして指定する場合は、冗長インターコネクトを使用することで冗長なインターコネクトが作成されます。この機能は、Oracle Grid Infrastructure 11g リリース2(11.2.0.2)以上で使用可能です。

1.3.3 オペレーティング・システム・パッケージの確認

ご使用のオペレーティング・システムで必須のパッケージのリストについては、第2.8項「ソフトウェア要件の確認」に示す表を参照してください。

1.3.4 グループおよびユーザーの作成

デフォルトのグループおよびユーザーを作成するには、次のコマンドを入力します。

オペレーティング・システムで認証されるすべての管理権限(インストールされている場合はOracle RACも含む)のために、システム権限グループを1つ作成します。

# mkgroup -'A' id='1000' adms='root' oinstall
# mkgroup -'A' id='1031' adms='root' dba
# mkuser id='1100' pgrp='oinstall' groups='dba' home='/home/grid' grid
# mkuser id='1101' pgrp='oinstall' groups='dba' home='/home/oracle' oracle
# mkdir -p  /u01/app/11.2.0/grid
# chown -R grid:oinstall /u01
# mkdir /u01/app/oracle
# chown oracle:oinstall /u01/app/oracle
# chmod -R 775 /u01/

この一連のコマンドによって、OraInventoryシステム権限(oinstall)、およびOSASM/SYSASMとOSDBA/SYSDBAシステム権限を付与するための必要なシステム権限グループを持った単一のインストール所有者が作成されます。また、Oracle Grid InfrastructureとOracle RAC両方のOracleベース(/u01/app/oracle)も作成されます。Gridホーム(Oracle Grid Infrastructureバイナリの格納場所)/u01/app/11.2.0/gridも作成されます。

Oracle Grid Infrastructureインストール所有者アカウントで、CAP_NUMA_ATTACH、CAP_BYPASS_RAC_VMMおよびCAP_PROPAGATEが可能であることを確認します。

すでに設定されている権限を確認するには、rootで次のコマンドを入力します。この例では、グリッド・インストールのユーザー・アカウントはgridです。

# /usr/bin/lsuser -a capabilities grid

権限を追加するには、次のコマンドを入力します。

# /usr/bin/chuser
capabilities=CAP_NUMA_ATTACH,CAP_BYPASS_RAC_VMM,CAP_PROPAGATE grid

グリッド・インストールの所有者アカウントにパスワードを設定します。

passwd grid

各クラスタのメンバー・ノードに対して、この手順を繰り返します。

1.3.5 Oracleインストール所有者のシェル制限の構成

Oracle Grid Infrastructureインストール所有者およびrootのシェル制限を無制限に設定します。smitユーティリティを使用するか、/etc/security/limitsファイルを編集し、両方のアカウントが無制限に設定されていることを確認します。crsデーモン(crsd)はrootで実行されるため、rootユーザーにはこれらの設定が必要です。limitsファイルに次の行を追加します。

default:
fsize = -1
core = 2097151
cpu = -1
data = -1
rss = -1
stack = -1
nofiles = -1

1.3.6 記憶域の確認

スタンドアロンまたはOracle Real Application Clustersのデータベースをインストールする場合は、Oracle Clusterwareファイル(投票ディスクとOracle Cluster Registry)用、およびOracle Databaseファイル用として、サポートされているファイル・システムまたはOracle Automatic Storage Management上に使用可能な領域が必要です。新しいインストール環境では、Oracle Clusterwareファイルをブロック・デバイスやRAWデバイスに作成することができなくなりました。

注意:
Oracle Automatic Storage Management(Oracle ASM)をOracle ClusterwareファイルまたはOracle Databaseファイルに使用する場合、データベースの数に関係なく、クラスタ内のノードごとにOracle ASMインスタンスが1つ作成されます。

1.3.7 Oracle Automatic Storage Management用の記憶域の準備

構成するインストール・オプションについては、第3章の関連する項を参照してください。

関連項目:
第3章「Oracle Grid InfrastructureとOracle RACの記憶域の構成」

1.3.8 Oracle Grid Infrastructureソフトウェアのインストール

1. インストール・メディアのルート・レベルからOUIを起動します。次に例を示します。

./runInstaller

2. 「クラスタ用のGrid Infrastructureのインストールおよび構成」を選択し、次に「標準インストール」を選択します。この後のインストール画面で、構成情報を指示どおりに入力します。
修正スクリプトで修正できないインストール検証エラーが発生した場合は、第2章「クラスタ用Oracle Grid Infrastructureの拡張インストールのインストール前作業」でクラスタ・ノードの構成の項を参照してください。修正が完了したら、インストールを最後まで続けます。

関連項目:
第4章「クラスタ用Oracle Grid Infrastructureのインストール」

2 クラスタ用Oracle Grid Infrastructureの拡張インストール前の作業

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

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

- アップグレードのベスト・プラクティスの確認

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

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

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

- ハードウェア要件の確認

- ネットワーク要件の確認

- ソフトウェア要件の特定

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

- UDPおよびTCPカーネル・パラメータの検証

- AIXのリソース制限のチェック

- AIXシステム環境のチューニング

- ネットワーク・タイム・プロトコルの設定

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

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

- rootpre.shスクリプトの実行

- hagsuserグループへのグリッド・インフラストラクチャ・インストール所有者の追加

- Oracle Grid Infrastructureホーム・ディレクトリの作成要件

- クラスタ名の要件

2.1 アップグレードのベスト・プラクティスの確認

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

既存のOracleインストールがある場合は、バージョン番号、パッチおよびその他の構成情報を記録して、既存のインストール用のアップグレード手順を確認します。インストールを進める前に、アップグレードに関するOracleドキュメントを確認し、その後の処理を確認します。

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

Oracle Automatic Storage Management(Oracle ASM)がすでにインストールされている場合は、Oracleのアップグレードに関するドキュメントを確認してください。今回のリリースでは、Oracle ASMホームの場所が変更されています。したがって、ストレージ管理を簡略化またはカスタマイズするためには、他の構成の変更も検討することが必要な場合があります。以前のリリースのOracle ASMホームがすでにある場合は、Oracle Clusterwareのアップグレードに使用する予定のユーザーが所有している必要があります。

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

注意:
異なるバージョンのオペレーティング・システムの混在は、数時間のアップグレードでのみサポートされています。Oracle Clusterwareでは、同じクラスタに異なるインストラクション・セット・アーキテクチャ(ISA)を使用するプロセッサを搭載するノードはサポートされていません。各ノードは、クラスタ内のほかのノードとバイナリ互換が必要です。たとえば、同じクラスタ内で、あるノードではIntel 64プロセッサを使用し、別のノードではIA-64(Itanium)プロセッサを使用することはできません。同じクラスタ内のあるノードでIntel 64プロセッサを使用し、別のノードでAMD64プロセッサを使用することはできますが、これはこれらのプロセッサが同じx86-64 ISAを使用し、同じバイナリ・バージョンのOracleソフトウェアを実行するためです。
クラスタに異なる処理速度やサイズのCPUを搭載するノードをインストールできますが、ハードウェア構成が同じノードを使用することをお薦めします。

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

https://support.oracle.com

2.2 インストール修正スクリプト

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

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

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

修正スクリプトによって、次の作業が実行されます。

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

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

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

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

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

- 必要に応じて、シェル制限が必要な値に設定されます。

インストールに使用するユーザー・アカウントのために、クラスタ・メンバー・ノード間でSSHを構成している場合は、インストール前にクラスタ構成を確認し、インストールを開始する前にオペレーティング・システムの変更を行うための修正スクリプトを生成できます。

これを行うには、インストールを実行するユーザー・アカウントでログインし、runcluvfyコマンドがあるステージング領域に移動し、次のコマンド構文を使用します。nodeは、クラスタ・メンバーにするノードをカンマで区切ったリストです。

$ ./runcluvfy.sh stage -pre crsinst -n node -fixup -verbose

たとえば、node1とnode2の2ノードがあるクラスタを構成する場合は、次のコマンドを入力します。

$ ./runcluvfy.sh stage -pre crsinst -n node1,node2 -fixup -verbose

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

Oracleソフトウェアをインストールする前に、Oracleソフトウェアをインストールするシステムでrootユーザーとして複数の作業を実行する必要があります。リモート・サーバーでrootユーザーとして作業を実行するには、rootとしてリモート表示を有効にする必要があります。

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

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

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

1. X端末(xterm)などのローカル端末セッションを開始します。

2. ソフトウェアをローカル・システムにインストールしない場合は、次の構文を使用してコマンドを入力し、リモート・ホストにローカルのXサーバーでXアプリケーションを表示させます。

$ xhost + remote_host

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

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

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

$ ssh remote_host

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

$ ssh somehost.example.com

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

$ su - root
password:
#

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

注意:
この手順の詳細は、ご使用のXサーバーのマニュアルを参照してください。ご使用のXサーバー・ソフトウェアによっては、異なった順序で作業を実行する必要があります。

1. Xサーバー・ソフトウェアを起動します。

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

3. ソフトウェアをインストールするリモート・システムに接続し、システムでX端末(xterm)などの端末セッションを開始します。

4. rootユーザーとしてリモート・システムにログインしていない場合は、次のコマンドを入力し、ユーザーをrootに切り替えます。

$ su - root
password:
#

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

rootとしてログインし、次の手順を実行して、インストールに必要なグループおよびユーザーを検索または作成します。

注意:
すべてのクラスタ・メンバー・ノードで、グループおよびユーザーのすべての番号が同一であることを確認します。

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

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

- Oracle Grid Infrastructureユーザーの作成

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

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

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

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

注意:
Oracle Grid Infrastructureのインストールでは、Oracle Clusterwareおよび Oracle Automatic Storage Managementの両方がインストールされます。Oracle Clusterwareのインストール所有者とOracle Automatic Storage Managementのインストール所有者は、分離することができなくなりました。

2.4.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中央インベントリがある場合は、必ずすべてのOracleソフトウェア・インストールで同じOracle Inventoryを使用し、インストールに使用するすべてのOracleソフトウェア・ユーザーがこのディレクトリへの書込み権限を持つようにします。

システムにOracle中央インベントリ・ディレクトリ(oraInventory)があるかどうかを確認するには、次のようにします。

次のコマンドを入力します。

# more /etc/oraInst.loc

oraInst.locファイルが存在する場合、このコマンドの出力結果は、次のようになります。

inventory_loc=/u01/app/oracle/oraInventory
inst_group=oinstall

前述の出力例の意味は次のとおりです。

- inventory_locグループは、Oracle Inventoryの場所を示します。

- inst_groupパラメータは、Oracle Inventoryグループの名前(この例では、oinstall)を示します。

grep groupname /etc/groupコマンドを使用して、Oracle Inventoryグループとして指定されたグループがまだシステムに存在していることを確認します。次に例を示します。

$ grep oinstall /etc/group
oinstall:x:1000:grid,oracle

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

oraInst.locファイルが存在しない場合は、次のコマンドを入力して、Oracle Inventoryグループを作成します。

# mkgroup id=1000 adms='root' oinstall

このコマンドによって、グループID番号が1000のoraInventoryグループoinstallが作成されます。oraInventoryグループのメンバーには、Oracle中央インベントリ(oraInventory)への書込み権限が付与されます。

oraInventoryグループが存在しない場合、デフォルトでは、クラスタ用Oracle Grid Infrastructureソフトウェアのインストール所有者のプライマリ・グループが、oraInventoryグループとして表示されます。使用するOracleソフトウェア・インストール所有者のすべてが、このグループをプライマリ・グループとして利用できることを確認します。

注意:
クラスタ内のすべてのノードで、グループIDおよびユーザーIDが一致している必要があります。使用するグループIDおよびユーザーIDが各クラスタ・メンバー・ノードで使用できることを確認し、クラスタ用グリッド・インフラストラクチャの各インストール所有者のプライマリ・グループが、同じ名前とグループIDであることを確認します。

2.4.3 Oracle Grid Infrastructureユーザーの作成

次の場合は、Oracle Grid Infrastructureのソフトウェア所有者を作成する必要があります。

- Oracleソフトウェア所有者ユーザーが存在しない場合(たとえば、システムへOracleソフトウェアを初めてインストールする場合)。

- Oracleソフトウェア所有者ユーザーは存在するが、他のグループに所属する別のオペレーティング・システム・ユーザーを使用して、グリッド・インフラストラクチャとOracle Databaseの管理権限を分離する場合。
Oracleドキュメントでは、Oracle Grid Infrastructureソフトウェアのインストールのみを所有するために作成されたユーザーをgridユーザーと呼びます。すべてのOracleインストールを所有するために作成されたユーザー、またはOracle Databaseのインストールのみを所有するために作成されたユーザーをoracleユーザーと呼びます。

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

異なるOracle Databaseホームに対して複数のOracleソフトウェア所有者を使用する場合は、Oracle Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)ソフトウェアに対して別途ソフトウェア所有者を作成し、その所有者でOracle Grid Infrastructureをインストールすることをお薦めします。

Oracle DatabaseまたはOracle RACをインストールする予定がある場合は、Oracle Grid InfrastructureおよびOracle Databaseのインストール・ユーザーを別々に作成することをお薦めします。使用するインストール所有者が1つの場合は、管理タスクを実行するときに、$ORACLE_HOMEの値を管理対象のインスタンス(ASM、Oracle Grid Infrastructureホーム内、またはOracleホームのデータベース)に次のコマンド構文などを使用して変更する必要があります(ここで/u01/app/11.2.0/gridはOracle Grid Infrastructureホームです)。

$ ORACLE_HOME=/u01/app/11.2.0/grid; export ORACLE_HOME

sqlplus、lsnrctl、asmcmdのいずれかのコマンドを使用してインスタンスを管理しようとしたときに、$ORACLE_HOMEが別のバイナリ・パスに設定されていると、エラーが発生します。データベース・ホームからsrvctlを起動する場合、$ORACLE_HOMEが設定されていないと、srvctlは失敗します。ただし、Oracle Grid Infrastructureホームでsrvctlを使用している場合は、$ORACLE_HOMEが無視されるため、Oracleホームのパスはsrvctlコマンドに影響しません。$ORACLE_HOMEは必ず、管理対象のインスタンスに変更する必要があります。

異なるOracleソフトウェアのインストール環境に対して、ユーザーを別々に作成し、オペレーティング・システム権限グループを別々に作成するためにOracleソフトウェア所有者を別々に作成する場合は、そのユーザーのプライマリ・グループとしてOracle中央インベントリ・グループ(oraInventoryグループ)が必要なことに注意してください。このグループのメンバーはOracle中央インベントリ(oraInventory)ディレクトリに対する書込み権限を所有します。また、様々なOracle Clusterwareリソース、OCRキー、DBAが書込み権限を必要とするOracle Clusterwareホーム内のディレクトリに対する権限やその他の必要な権限が付与されます。Oracleドキュメントのコード例では、このグループをoinstallで表しています。

それぞれのOracleソフトウェア所有者は、同じ中央インベントリ・グループのメンバーであることが必要です。Oracleインストールに対して複数の中央インベントリを持たないことをお薦めします。あるOracleソフトウェア所有者が別の中央インベントリ・グループを持っている場合、その中央インベントリは破損することがあります。

注意:
クラスタ用グリッド・インフラストラクチャのインストールでは、Gridホームを、Oracleベース・ディレクトリ、Oracle Databaseインストール所有者のOracleホーム・ディレクトリ、インストール所有者のホーム・ディレクトリのいずれの下にも配置しないでください。インストール中に、Gridホームへのパスの所有権がrootに変更されます。この変更により、他のインストールで権限エラーが発生します。

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

oracleやgridというOracleソフトウェア所有者ユーザーが存在するかどうかを確認するには、次のようなコマンドを入力します(この場合、oracleの存在を確認します)。

# id oracle

ユーザーが存在する場合、このコマンドの出力結果は、次のようになります。

uid=501(oracle) gid=501(oinstall) groups=502(dba),503(oper)

既存ユーザーを使用するか、別のユーザーを作成するかを決定します。ユーザーIDおよびグループIDの番号は、クラスタ・メンバー・ノードにする各ノード上で同一である必要があります。

既存ユーザーを使用する場合は、ユーザーのプライマリ・グループがOracle Inventoryグループ(oinstall)であることを確認します。Oracle Databaseインストールにこのユーザー・アカウントを使用する場合は、OracleアカウントがASM用のOSDBAグループ(メンバーがOracle ASM記憶域への書込みを許可されているグループ)として指定する予定のグループのメンバーであることを確認します。

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

Oracleソフトウェア所有者ユーザー(oracle、grid)が存在しない、または新しいOracleソフトウェア所有者ユーザーが必要な場合は作成します。既存のユーザー・アカウントを使用する場合は、各クラスタ・メンバー・ノードでユーザーIDおよびグループIDが一致していることを確認します。次の手順では、Oracleソフトウェア所有者の名前としてgridが、OSASMグループとしてdbaが使用されています。異なる管理権限に対して個別のシステム権限グループを作成するには、ユーザーを作成する前に、グループ作成を行います(第2.4.5項「役割区分によるオペレーティング・システム権限グループおよびユーザーの作成」)。

注意:
既存ユーザーを使用および変更する前に、必要に応じてシステム管理者に連絡してください。
各ノードのUIDおよびGIDのデフォルトを使用しないことをお薦めします。グループIDやユーザーIDが、ノードによって一致しなくなることがあるためです。そのかわりに、共通で割り当てるグループIDとユーザーIDを用意し、グループとユーザーの作成または変更を行う前に、いずれのノードでもそのIDが使用されていないことを確認しておきます。

2.4.3.3.1 新規ユーザーの作成

新規ユーザーを作成するには、次の手順を実行します。

1. 次のコマンドを入力します。

# smit security

2. 「Security & Users」メニューで、「Users」を選択します。

3. 「Users」メニューで、「Add a User」を選択します。

4. 適切なメニュー項目を選択して、Oracle Grid Infrastructureソフトウェアのインストール所有者(grid)を作成します。「Primary GROUP」フィールドに、Oracle Inventoryグループを指定します。他のノードでも同じ値を指定できるように、このエントリ・フィールドに指定した情報をメモしておいてください。

5. [Enter]を押した後、[Esc]+[0]を押して終了します。

6. Oracle Grid Infrastructureソフトウェアのインストール所有者(grid)のパスワードを設定します。次に例を示します。

# passwd grid

7. Oracle Grid Infrastructureソフトウェアのインストール所有者(grid)で、CAP_NUMA_ATTACH、CAP_BYPASS_RAC_VMMおよびCAP_PROPAGATEが可能であることを確認します。
既存の権限を確認するには、rootとして次のコマンドを入力します。

# /usr/bin/lsuser -a capabilities grid

権限を追加するには、次のコマンドを入力します。

# /usr/bin/chuser
capabilities=CAP_NUMA_ATTACH,CAP_BYPASS_RAC_VMM,CAP_PROPAGATE grid

8. 他のすべてのクラスタ・ノードでこの手順を繰り返します。

2.4.3.3.2 既存のユーザーの変更

既存のユーザーを変更するには、次の手順を実行します。

1. 次のコマンドを入力します。

# smit security

2. 適切なメニュー項目を選択して、グリッド・インフラストラクチャの所有者ユーザーを変更します。

3. 「Primary GROUP」フィールドに、Oracle Inventoryグループを指定します。たとえば、oinstallです。

4. [Enter]を押した後、[Esc]+[0]を押して終了します。

5. 他のすべてのクラスタ・ノードでこの手順を繰り返します。

2.4.4 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/11.2.0/grid
# mkdir -p /u01/app/grid
# mkdir -p /u01/app/oracle
# chown grid:oinstall /u01/app/11.2.0/grid
# chown grid:oinstall /u01/app/grid
# chown oracle:oinstall /u01/app/oracle
# chmod -R 775 /u01/
# chown -R grid:oinstall /u01

注意:
クラスタ用Oracle Grid Infrastructureバイナリをクラスタ・ファイル・システムに配置することはサポートされていません。

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

役割区分によるOracle ASMの権限構成は、Oracle ASMインストール環境に対する管理アクセス権限と、他のOracleインストール環境に関連付けられた管理権限グループおよびユーザーとを分離するためのグループおよびユーザーを持つ構成です。管理アクセス権は、個々のオペレーティング・システム・グループのメンバーシップによって付与され、インストール権限は、Oracleをインストールするたびにインストール所有者を変えることで付与されます。

注意:
この構成はオプションで、Oracleソフトウェアに対するユーザー・アクセスを、様々な管理者ユーザーの役割に応じて制限するための構成です。

必要な場合、記憶域およびデータベース層におけるすべてのシステム権限について、1つの管理ユーザーと1つのグループをオペレーティング・システム認証で使用できるように、オペレーティング・システム・ユーザー権限を割り当てることができます。

たとえば、すべてのOracleソフトウェアのインストール所有者をoracleユーザーとし、Oracle Clusterware、Oracle Automatic Storage Management、サーバー上のすべてのOracle Databaseに対するすべてのシステム権限、およびインストール所有者としてのすべての権限をメンバーに付与されるグループをoinstallとすることができます。このグループは、Oracle Inventoryグループであることも必要です。

少なくとも2つのグループを使用することをお薦めします。メンバーに管理システム権限が付与されるシステム権限グループと、個別のインストール権限であるOINSTALL権限が付与されるインストール所有者グループ(oraInventoryグループ)です。クラスタ検証ユーティリティなどのOracleツールでデフォルトを使用しやすくするため、すべてのシステム権限とoraInventoryへの書込み権限を1つのオペレーティング・システム・グループに付与する場合は、そのグループ名をoinstallにする必要があります。

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

- 役割区分によるデータベース・グループおよびユーザーの作成

注意:
ネットワーク情報サービス(NIS)などのディレクトリ・サービスを使用する場合の詳細は、オペレーティング・システムのドキュメントを参照してください。

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

この項では、ユーザーおよびグループを作成し、役割区分を使用する方法の概要を説明します。これらのグループおよびユーザーを作成するには、rootでログインします。

- 役割区分を使用したOracleインストールのためのユーザー

- 役割区分によるインストールのためのデータベース・グループ

- 役割区分によるインストールのためのOracle ASMグループ

2.4.5.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管理者ガイド』を参照してください。

2.4.5.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の場合、別々のオペレーティング・システム・グループがOSDBAとOSASMグループに指定されているときには、この権限が付与されません。同じグループが、OSDBAとOSASMの両方に使用されている場合は、権限がそのまま保持されます。

- Oracle DatabaseのOSOPERグループ(通常、oper)
これは、オプションのグループです。制限付きのデータベース管理権限(SYSOPER権限)を別のグループのオペレーティング・システム・ユーザーに付与する場合に、このグループを作成します。OSDBAグループのメンバーには、デフォルトで、SYSOPER権限によって付与されるすべての権限もあります。

OSOPERグループを使用してデフォルトのdbaグループより少ない権限でデータベース管理者グループを作成するには、拡張インストール・タイプを選択してソフトウェアをインストールするか、またはdbaグループのメンバーでないユーザーとしてOUIを起動する必要があります。この場合、OUIによって、グループ名の指定を求めるプロンプトが表示されます。このグループの標準的な名前はoperです。

2.4.5.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グループより少ない権限でASM管理者グループを作成するには、拡張インストール・タイプを選択してソフトウェアをインストールする必要があります。この場合、OUIによって、グループ名の指定を求めるプロンプトが表示されます。コード例では、このグループはasmoperです。

2.4.5.2 役割区分によるデータベース・グループおよびユーザーの作成

次の項では、必要なオペレーティング・システム・ユーザーおよびグループを作成する方法について説明します。

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

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

- OSASMグループの作成

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

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

- Oracleソフトウェア所有者ユーザーを作成するタイミング

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

- Oracleソフトウェア所有者ユーザーの作成

- 既存のOracleソフトウェア所有者ユーザーの変更

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

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

Oracle DatabaseをインストールしてOracle Grid Infrastructure環境で使用するときに、次のような場合はOSDBAグループを作成する必要があります。

- OSDBAグループが存在しない場合(たとえば、システムへOracle Databaseソフトウェアを初めてインストールする場合)。

- OSDBAグループが存在するが、新しいOracle Database環境では、データベースの管理権限を別のグループのオペレーティング・システム・ユーザーに付与する場合。

OSDBAグループが存在しない場合または新しいOSDBAグループが必要な場合は、smitを使用するか、シェル・コマンドラインを使用して作成します。既存のグループですでに使用されていないかぎり、グループ名にはdbaを使用します。次に例を示します。

# mkgroup -'A' id='1031' adms='root' dba

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

OSOPERグループを作成する必要があるのは、制限付きのデータベース管理権限(SYSOPERオペレータ権限)を持つオペレーティング・システム・ユーザーのグループを指定する場合のみです。ほとんどの環境では、OSDBAグループを作成するのみで十分です。次の場合にOSOPERグループを使用するには、このグループを作成する必要があります。

- OSOPERグループが存在しない場合(たとえば、システムへOracle Databaseソフトウェアを初めてインストールする場合)

- OSOPERグループが存在するが、新しいOracle環境で、データベースのオペレータ権限を別のグループのオペレーティング・システム・ユーザーに付与する場合

新しいOSOPERグループが必要な場合は、smitを使用するか、シェル・コマンドラインを使用して作成します。既存のグループですでに使用されていないかぎり、グループ名にはoperを使用します。

# mkgroup -'A' id='1032' adms='root' oper1

2.4.5.2.3 OSASMグループの作成

OSASMグループが存在しない場合または新しいOSASMグループが必要な場合は、smitを使用するか、シェル・コマンドラインを使用して作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmadminを使用します。

# mkgroup -'A' id='1020' adms='root' asmadmin

2.4.5.2.4 ASMのためのOSOPERグループの作成

データベース管理者などのオペレーティング・システム・ユーザーのグループを指定し、Oracle ASM記憶域の起動と停止を含む、Oracle ASM記憶域層に対する制限付きの管理権限を付与する場合には、ASM用のOSOPERグループを作成します。ほとんどの環境では、OSASMグループを作成するのみで十分です。インストールのインタビュー時に、そのグループをASM用のOSOPERグループとして指定します。

ASM用の新しいOSOPERグループが必要な場合は、smitを使用するか、シェル・コマンドラインを使用して作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmoperを使用します。

# mkgroup -'A' id='1022' adms='root' asmoper

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

Oracle ASMインスタンスへのアクセスを可能にするには、ASM用のOSDBAグループを作成する必要があります。これは、OSASMとOSDBAが異なるグループである場合に必要です。

ASM用のOSDBAグループが存在しない場合またはASM用の新しいOSDBAグループが必要な場合は、smitを使用するか、シェル・コマンドラインを使用して作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmdbaを使用します。次に例を示します。

# mkgroup -'A' id='1021' adms='root' asmdba

2.4.5.2.6 Oracleソフトウェア所有者ユーザーを作成するタイミング

次の場合は、Oracleソフトウェア所有者ユーザーを作成する必要があります。

- Oracleソフトウェア所有者ユーザーが存在するが、新しいOracle Database環境では、別のオペレーティング・システム・ユーザー(異なるグループ・メンバーシップを持つ)を使用して、このグループにデータベースの管理権限を付与する場合。

- Oracle Grid Infrastructureに対してgridなどのOracleソフトウェア所有者が作成されており、Oracle Databaseソフトウェアに対してoracleなどの別のOracleソフトウェア所有者を作成する場合。

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

oracleやgridというOracleソフトウェア所有者ユーザーが存在するかどうかを確認するには、次のようなコマンドを入力します(この場合、oracleの存在を確認します)。

# id oracle

ユーザーが存在する場合、このコマンドの出力結果は、次のようになります。

uid=501(oracle) gid=501(oinstall) groups=502(dba),503(oper)

既存ユーザーを使用するか、別のユーザーを作成するかを決定します。既存のユーザーを使用する場合は、そのユーザーのプライマリ・グループがOracleインベントリ・グループであり、そのユーザーが適切なOSDBAグループおよびOSOPERグループのメンバーであることを確認します。詳細は、次のいずれかの項を参照してください。

- 既存のユーザーを変更するには、第2.4.5.2.9項「既存のOracleソフトウェア所有者ユーザーの変更」を参照してください。

- ユーザーを作成するには、次の項を参照してください。

注意:
既存ユーザーを使用および変更する前に、必要に応じてシステム管理者に連絡してください。
各ノードのUIDおよびGIDのデフォルトを使用しないことをお薦めします。グループIDやユーザーIDが、ノードによって一致しなくなることがあるためです。そのかわりに、共通で割り当てるグループIDとユーザーIDを用意し、グループとユーザーの作成または変更を行う前に、いずれのノードでもそのIDが使用されていないことを確認しておきます。

2.4.5.2.8 Oracleソフトウェア所有者ユーザーの作成

Oracleソフトウェア所有者ユーザーが存在しない、または新しいOracleソフトウェア所有者ユーザーが必要な場合は、次の手順で作成します。既存のユーザーですでに使用されていないかぎり、ユーザー名にはoracleを使用します。

1. oracleユーザーを作成するには、smitを使用するか、次のコマンドを入力します。

# mkuser id='1101' pgrp='oinstall' groups='dba,asmdba' home='/home/oracle' oracle

2. oracleユーザーのパスワードを設定します。

# passwd oracle

2.4.5.2.9 既存のOracleソフトウェア所有者ユーザーの変更

oracleユーザーは存在するが、プライマリ・グループがoinstallではない場合、または適切なOSDBAまたはASM用OSDBAグループのメンバーでない場合は、smitを使用して更新します。

1. シェル・プロンプトでsmitを入力して、SMITを起動します。

2. メイン・メニューで次のように選択します。

- セキュリティおよびユーザー

- グループ

- グループの特性の変更/表示

特定のグループの名前を入力できるフォームが表示されます。

3. グループ名を入力するか、[F4]キーを使用してグループ名を強調表示させ、[Enter]キーを押します。
次のフィールドがあるフォームが表示されます。

- Group NAME: アカウントのグループ名です。

- Group ID: グループの識別子番号(GID)です。

- User list: グループのメンバーであるユーザーのリストです。使用可能なユーザーのリストを表示するには[F4]キーを使用し、追加するユーザーにマークを付けるには[F7]キーを使用します。

4. 必要に応じてこれらのフィールドを変更し、[Enter]を押してフォームを終了します。

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

Oracleソフトウェア所有者ユーザー、Oracle Inventory、OSDBAグループおよびOSOPERグループは、すべてのクラスタ・ノードに存在し、また同一である必要があります。同一のユーザーおよびグループを作成するには、ユーザーおよびグループを作成したノードで割り当てられたユーザーIDおよびグループIDを確認してから、他のクラスタ・ノードで同じ名前とIDを持つユーザーおよびグループを作成する必要があります。

注意:
次の手順は、ローカル・ユーザーおよびグループを使用している場合にのみ実行する必要があります。NISなどのディレクトリ・サービスで定義されたユーザーおよびグループを使用している場合、各クラスタ・ノードのユーザーおよびグループはすでに同一です。

既存のユーザーIDおよびグループIDの確認

gridまたはoracleユーザーのユーザーID(UID)と、既存のOracleグループのグループID(GID)を確認するには、次の手順を実行します。

1. 次のコマンドを入力します(ここでは、oracleユーザーのユーザーIDを確認します)。

# id oracle

このコマンドの出力結果は、次のようになります。

uid=502(oracle) gid=501(oinstall) groups=502(dba),503(oper),506(asmdba)

2. 表示された情報から、ユーザーのユーザーID(uid)および所属するグループのグループID(gid)を特定します。これらのID番号がクラスタの各ノードで同じであることを確認します。ユーザーのプライマリ・グループはgidの後に表示されます。セカンダリ・グループはgroupsの後に表示されます。

他のクラスタ・ノードでのユーザーおよびグループの作成

他のクラスタ・ノードでユーザーおよびグループを作成するには、各ノードで次の手順を繰り返します。

1. 次のクラスタ・ノードへrootでログインします。

2. smitを使用するか、コマンドラインを使用して、必要に応じてグループおよびユーザーを作成します。コマンドラインを使用するには、次のコマンドを入力して、oinstall、asmadminおよびasmdbaグループを作成します。また、必要に応じて、asmoper、dbaおよびoperグループを作成します。idオプションを使用して、各グループに正しいgidを指定します。

# mkgroup -'A' id='1000' adms='root' oinstall
# mkgroup -'A' id='1020' adms='root' asmadmin
# mkgroup -'A' id='1021' adms='root' asmdba
# mkgroup -'A' id='1022' adms='root' asmoper
# mkgroup -'A' id='1031' adms='root' dba
# mkgroup -'A' id='1032' adms='root' oper

注意:
グループがすでに存在している場合は、必要に応じてsmitを使用してそのグループを変更します。このノードのグループに、同じグループIDを使用できない場合、すべてのノードの/etc/groupファイルを表示し、どのノードでも使用できるグループIDを特定します。すべてのノードのグループIDが同じになるように、グループIDを変更する必要があります。

3. oracleユーザーまたはOracle Grid Infrastructure (grid)ユーザーを作成するには、smitを使用するか、次のようなコマンドを入力します(この例では、oracleユーザーを作成します)。

# mkuser id='1001' pgrp='oinstall' groups='dba,asmdba' home='/home/oracle' oracle

前述のコマンドの意味は、次のとおりです。

- idオプションは、ユーザーIDを指定します。ユーザーIDは、前の項で特定したユーザーIDである必要があります。

- pgrpオプションは、プライマリ・グループを指定します。プライマリ・グループは、oinstallなどのOracle Inventoryグループである必要があります。

- groupsオプションは、セカンダリ・グループを指定します。セカンダリ・グループには、OSASM、OSDBA、ASM用のOSDBA、OSOPERまたはASM用のOSOPERグループを含めることができます。次に例を示します。

- グリッド・インストール所有者: OSASM(asmadmin)。メンバーはSYSASM権限を付与されます。

- SYSASMアクセス権限のないOracle Databaseインストール所有者: OSDBA(dba)、ASM用のOSDBA(asmdba)、ASM用のOSOPER(asmoper)。

注意:
ユーザーがすでに存在している場合は、必要に応じてsmitを使用してそのユーザーを変更します。すべてのノードのユーザーに、同じユーザーIDを使用できない場合、すべてのノードの/etc/passwdファイルを表示して、どのノードでも使用できるユーザーIDを特定します。すべてのノードのユーザーにそのIDを指定する必要があります。

4. ユーザーのパスワードを設定します。次に例を示します。

# passwd oracle

5. 第2.14.1項「Oracle Grid Infrastructureソフトウェア所有者の環境要件」で説明するとおり、各ユーザーに対してユーザー環境の構成を行います。

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

次に、コマンドラインを使用してOracle Inventoryグループ(oinstall)および単一のグループ(dba)をOSDBA、OSASMおよびASM用OSDBAグループとして作成する例を示します。また、適切なグループ・メンバーシップを持つ、Oracle Grid Infrastructureソフトウェア所有者(grid)と1つのOracle Database所有者(oracle)を作成する方法も示します。適切な権限を持つ、OFA構造準拠のOracleベース・パスの構成方法についても示します。

# mkgroup -'A' id='1000' adms='root' oinstall
# mkgroup -'A' id='1031' adms='root' dba
# mkuser id='1100' pgrp='oinstall' groups='dba' home='/home/grid' grid
# mkuser id='1101' pgrp='oinstall' groups='dba' home='/home/oracle' oracle
# mkdir -p  /u01/app/grid
# chown -R grid:oinstall /u01
# mkdir /u01/app/oracle
# chown oracle:oinstall /u01/app/oracle
# chmod -R 775 /u01/

これらのコマンドを実行すると、次のグループとユーザーができます。

- Oracle中央インベントリ・グループ(oraInventoryグループ(oinstall))。プライマリ・グループが中央インベントリ・グループであるメンバーは、oraInventoryディレクトリに書込みできるOINSTALL権限を付与されます。

- OSASM、OSDBA、ASM用OSDBAおよびASM用OSOPERグループ(dba)として使用される単一のシステム権限グループ。このメンバーには、Oracle Clusterware、Oracle ASMおよびOracle Databaseを管理するためのSYSASMおよびSYSDBA権限が付与され、Oracle ASMストレージへのSYSASMおよびASM用OSOPERとしてアクセスできる権限が付与されます。

- クラスタ用Oracle Gridのインストール所有者(grid)。プライマリ・グループはoraInventoryグループ、セカンダリ・グループはOSASMグループ。Oracleベース・ディレクトリは/u01/app/grid。

- Oracle Database所有者(oracle)。プライマリ・グループはoraInventoryグループ、セカンダリ・グループはOSDBAグループ。Oracleベース・ディレクトリは/u01/app/oracle。

- インストール前は775権限でgrid:oinstallが所有し、インストール中にroot.shスクリプトが実行された後はrootが所有する/u01/app。この所有権と権限によって、OUIはパス/u01/app/oraInventoryにOracle Inventoryディレクトリを作成できるようになります。

- インストール前はgrid:oinstallが所有し、インストール中にroot.shスクリプトが実行された後はrootが所有する/u01。

- 775権限でgrid:oinstallが所有する/u01/app/11.2.0/grid。これらの権限はインストールに必要であり、インストール・プロセスで変更されます。

- インストール前は775権限で、インストール後は755権限でgrid:oinstallが所有する/u01/app/grid。

- 775権限でoracle:oinstallが所有する/u01/app/oracle。

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

次に、Optimal Flexible Architecture(OFA)デプロイメントに準拠する、ロール割当てをしたグループおよびユーザーの作成方法の例を示します。

# mkgroup -'A' id='1000' adms='root' oinstall
# mkgroup -'A' id='1020' adms='root' asmadmin
# mkgroup -'A' id='1021' adms='root' asmdba
# mkgroup -'A' id='1031' adms='root' dba1
# mkgroup -'A' id='1041' adms='root' dba2
# mkgroup -'A' id='1022' adms='root' asmoper
# mkuser id='1100' pgrp='oinstall' groups='asmadmin' home='/home/grid' grid
# mkuser id='1101' pgrp='oinstall' groups='dba1,asmdba' home='/home/oracle' oracle1
# mkuser id='1102' pgrp='oinstall' groups='dba2,asmdba' home='/home/oracle' oracle2
# mkdir -p  /u01/app/11.2.0/grid
# mkdir -p /u01/app/grid
# chown -R grid:oinstall /u01/app/grid
# mkdir -p /u01/app/oracle1
# chown oracle1:oinstall /u01/app/oracle1
# mkdir -p /u01/app/oracle2
# chown oracle2:oinstall /u01/app/oracle2
# chmod -R 775 /u01

これらのコマンドを実行すると、次のグループとユーザーができます。

- Oracle中央インベントリ・グループ、つまりoraInventoryグループ(oinstall)。プライマリ・グループがこのグループであるメンバーは、oraInventoryディレクトリへの書込み権限を付与されます。

- 個別のOSASMグループ(asmadmin)。メンバーはOracle ClusterwareおよびOracle ASMを管理するための権限が付与されます。

- 個別のASM用OSDBAグループ(asmdba)。メンバーはgrid、oracle1およびoracle2で、Oracle ASMへのアクセス権が付与されます。

- 個別のASM用のOSOPERグループ(asmoper)。メンバーはOracle ASMインスタンスの起動と停止を含む、制限付きのOracle ASMの管理者権限が付与されたユーザーです。

- クラスタ用Oracle Gridのインストールの所有者(grid)。プライマリ・グループはoraInventoryグループ、セカンダリ・グループはOSASM(asmadmin)、ASM用のOSDBAグループ(asmdba)。

- 2つの異なるデータベース(dba1およびdba2)用の2つの別々のOSDBAグループ。各データベースには別々のSYSDBA権限があります。

- Oracleデータベース・バイナリの所有権を分けるための、2つのOracle Databaseソフトウェア所有者(oracle1とoracle2)。プライマリ・グループはoraInventoryグループ。セカンダリ・グループは、それぞれのデータベースに対するOSDBAグループ(dba1またはdba2)と、ASM用のOSDBAグループ(asmdba)。

- インストール前にgrid:oinstallが所有するOFA準拠のマウント・ポイント/u01。

- 775権限でgrid:oinstallが所有する、グリッド・インストール所有者のOracleベース/u01/app/grid。インストール・プロセスで755権限に変更されます。

- 775権限でoracle1:oinstallが所有するOracleベースの/u01/app/oracle1。

- 775権限でoracle2:oinstallが所有するOracleベースの/u01/app/oracle2。

- 775(drwxdrwxr-x)権限でgrid:oinstallが所有する、Gridホーム/u01/app/11.2.0/grid。これらの権限はインストールに必要であり、インストール・プロセス中、755権限(drwxr-xr-x)でroot:oinstallに変更されます。

- /u01/app/oraInventory。このパスは、引き続きgrid:oinstallが所有し、他のOracleソフトウェア所有者が中央インベントリに書込みできるようにします。

2.5 ハードウェア要件の確認

- 同じインストラクション・セット・アーキテクチャを持つサーバーを選択します。

- サーバーが実行レベル2(デフォルトまたは通常のマルチユーザー・モード)で起動されていることを確認します。

- 各サーバーが、同じオペレーティング・システム・レベル、APARおよびファイル・セットで実行されていることを確認します。Oracle Grid InfrastructureインストールとOracle Real Application Clusters(Oracle RAC)では、同一クラスタ内でハードウェアが異なるサーバーを使用できます。

各システムは、次の最小ハードウェア要件を満たしている必要があります。

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

- 1024 x 768以上のディスプレイ解像度。Oracle Universal Installer(OUI)を正しく表示するため。

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

使用可能なRAM

必要なスワップ領域

2.5GBから16GB

RAMサイズと同等

16GBを超える

16GB

- /tmpディレクトリに1GBのディスク領域。

- クラスタ用Oracle Grid Infrastructureホーム(Gridホーム)に13GBの領域(ここには、Oracle ClusterwareおよびOracle Automatic Storage Management(Oracle ASM)のファイルとログ・ファイル、Oracle ACFSログ・ファイル、およびクラスタ状態モニター・リポジトリが格納されます)。

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

- Oracle Databaseファイル用に7.5GBのディスク領域(Oracleベース)

- ファイル・システムの記憶域を使用する事前構成済データベース用に2GBのディスク領域(任意)
自動バックアップを構成する場合は、ファイル・システムまたはOracle Automatic Storage Managementディスク・グループのいずれかに、追加のディスク領域が必要です。

関連項目:
『Oracle Databaseストレージ管理者ガイド』

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

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

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

# /usr/sbin/lsattr -E -l sys0 -a realmem

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

2. 次のコマンドを入力して、使用可能なRAMおよびスワップ領域を確認します。

# /usr/sbin/lsps -s

注意:

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

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

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

# /usr/sbin/lsps -a

追加のスワップ領域を構成する(必要な場合)方法については、ご使用のオペレーティング・システムのマニュアルを参照してください。

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

# /usr/bin/df -k /tmp

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

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

- oracleユーザーの環境設定の際に、環境変数TEMPおよびTMPDIRを設定します。

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

関連項目:
第2.14項「グリッド・インフラストラクチャ・ソフトウェア所有者ユーザー環境の構成」

5. システム上の空きディスク領域の量を確認します。Oracle Clusterwareファイルを配置する場所に合わせて次のいずれかのコマンドを使用します。
GPFSの場合:

# /usr/bin/df -k

コンカレントVGのRAW論理ボリューム(HACMP)の場合: この例の変数lv_nameは、検証する領域を持つRAW論理ボリューム名です。

# lslv lv_name

RAWハード・ディスクの場合: この例の変数rhdisk#は、検証するRAWハード・ディスク番号であり、変数size_mbは、検証するパーティション・サイズ(MB単位)です。

# lsattr -El rhdisk# -a size_mb

6. 次のコマンドを入力して、システムが64-bitモードで起動されているかどうかを確認します。

# bootinfo -K

このコマンドの結果は、64-bitカーネルが有効であることを示す64になるはずです。

2.6 ネットワーク要件の確認

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

- ネットワーク・ハードウェア要件

- IPアドレス要件

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

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

- グリッド・ネーミング・サービスへのドメイン委任のためのDNS構成

- グリッド・ネーミング・サービスの構成例

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

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

注意:
Oracle RAC環境でサポートされるネットワーク・プロトコルおよびハードウェアの最新情報は、次のMy Oracle Support Webサイトの「動作保証」ページを参照してください。WebサイトのURLは次のとおりです。

https://support.oracle.com

2.6.1 ネットワーク・ハードウェア要件

次にネットワーク構成要件を示します。

- 各ノードには2つ以上のネットワーク・アダプタまたはネットワーク・インタフェース・カード(NIC)が必要です。1つはパブリック・ネットワーク・インタフェース用、もう1つはプライベート・ネットワーク・インタフェース(インターコネクト)用です。
冗長インターコネクトを使用すると、ボンディングなどのテクノロジを使用しなくても、複数のインタフェースを指定してクラスタ・プライベート・ネットワークに使用します。この機能は、Oracle Database 11g リリース2(11.2.0.2)以上で使用可能です。

複数のインタフェースを定義すると、Oracle Clusterwareは1つから4つの高可用性IP(HAIP)アドレスを作成します。Oracle RACおよびOracle ASMインスタンスはこれらのインタフェース・アドレスを使用して、ノード間でのロード・バランシングされた高可用性インタフェース通信を保証します。インストーラは、冗長インターコネクトを使用して、高可用性プライベート・ネットワークを提供します。

デフォルトでは、Oracle Grid InfrastructureソフトウェアはすべてのHAIPアドレスをプライベート・ネットワーク通信に使用して、プライベート・ネットワークとして指定した一連のインタフェースにロード・バランシングを提供します。プライベート・インターコネクト・インタフェースに障害が発生するか、または通信できなくなった場合、Oracle Clusterwareは、機能している残りのインタフェースのいずれかに対応するHAIPアドレスを透過的に移動します。

注意:
プライベート・ネットワーク・インタフェースとして5つ以上のインタフェースを定義した場合は、Oracle Clusterwareが一度にアクティブにするインタフェースは4つのみであることに注意してください。ただし、4つのアクティブなインタフェースのうちの1つに障害が発生した場合は、その障害が発生したインタフェースに構成されたHAIPアドレスを、一連の定義済プライベート・インタフェースのうちの予備インタフェースの1つに移します。

ノードをOracle Grid Infrastructure 11gリリース2(11.2.0.2)以上にアップグレードする場合、アップグレードされたシステムは既存のネットワーク分類を使用します。

複数のパブリック・インタフェースを構成するには、ご使用のプラットフォーム用のサード・パーティ・テクノロジを使用して、インストールを開始する前に複数のパブリック・インタフェースを集約する必要があります。その後、結合されたインタフェースの単一のインタフェース名をパブリック・インタフェースとして選択します。Oracle Grid Infrastructureのインストール中に、複数のパブリック・インタフェース名を指定しないことをお薦めします。集約テクノロジを使用せずに、2つのネットワーク・インタフェースをクラスタ内のパブリック・ネットワーク・インタフェースとして構成する場合、ノード上の1つのパブリック・インタフェースで発生した障害によって、もう1つのパブリック・インタフェースへの自動VIPフェイルオーバーが行われることはないことに注意してください。

プライベート・ネットワークに複数のインタフェースを使用するには、冗長インターコネクト機能を使用することをお薦めします。ただし、サード・パーティのテクノロジを使用しても、プライベート・ネットワークを冗長にすることは可能です。

注意:
複数のNICを使用するためにNICボンディングは必要ありません。インストール時に、インストーラで検出されたすべてのインタフェースの計画的な使用を指定できます。Oracle Clusterwareは、プライベートと指定されたすべてのNICを、プライベート・インターコネクトとして使用します。
冗長インターコネクトを使用する場合、完全な11.2.0.2リリースまたは上位のスタック(Oracle Grid InfrastructureおよびOracleデータベース)が必要です。以前のOracle Databasesのリリースでは、この機能を利用できず、サード・パーティのNICボンディング技術を使用する必要がありました。異なるデータベース・リリースを1つのクラスタで統合し、Oracle Databaseリリース11.2.0.2より前のデータベースを使用する場合は、両方の技術が必要な場合があります。

- OUIを使用してOracle Clusterwareをインストールする場合は、各ネットワークのネットワーク・アダプタに関連付けるパブリック・インタフェース名は、すべてのノードで同じである必要があり、ネットワーク・アダプタに関連付けるプライベート・インタフェース名もすべてのノードで同じである必要があります。この制限は、新しいクラスタを作成するため、または既存のクラスタにノードを追加するためにクローニングを使用する場合は適用されません。
たとえば、2ノードのクラスタのネットワーク・アダプタの場合、パブリック・インタフェースとしてnode1ではeth0、node2ではeth1というようには構成できません。パブリック・インタフェース名は同じである必要があるため、両方のノードでパブリックとしてeth0を構成する必要があります。同じネットワークのアダプタでは、プライベート・インタフェースも同様に構成する必要があります。eth1がnode1のプライベート・インタフェースであれば、node2のプライベート・インタフェースもeth1である必要があります。

関連項目:
クローニングを使用してノードを追加する方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- パブリック・ネットワークの場合、各ネットワーク・アダプタではTCP/IPがサポートされている必要があります。

- プライベート・ネットワークでは、インタフェースにTCP/IPをサポートする高速ネットワーク・アダプタおよびスイッチ(最低要件: 1ギガビット・イーサネット)を使用して、ユーザー・データグラム・プロトコル(UDP)がサポートされている必要があります。

注意:
UDPはOracle RAC用のデフォルトのインタフェース・プロトコルで、TCPはOracle Clusterware用のインターコネクト・プロトコルです。インターコネクト用のスイッチを使用する必要があります。専用のスイッチを使用することをお薦めします。
インターコネクト用のトークン・リングまたはクロスオーバー・ケーブルはサポートされていません。

- 各ノードのインターコネクト用のプライベート・インタフェースは同じサブネット上にある必要があり、これらのサブネットはクラスタのすべてのノードに接続する必要があります。たとえば、プライベート・インタフェースのサブネット・マスクが255.255.255.0の場合、プライベート・ネットワークの範囲は192.168.0.0から192.168.0.255で、プライベート・アドレスの範囲は192.168.0.[0-255]である必要があります。プライベート・インタフェースのサブネット・マスクが255.255.0.0の場合、プライベート・アドレスの範囲は192.168.[0-255].[0-255]をとることもできます。
冗長インターコネクトを使用するクラスタの場合、各プライベート・インタフェースは、異なるサブネット上にある必要があります。ただし、各クラスタ・メンバー・ノードは各プライベート・インターコネクト・サブネット上にインタフェースを持つ必要があり、これらのサブネットがクラスタのすべてのノードに接続されている必要があります。たとえば、プライベート・ネットワークがサブネット192.168.0および10.0.0上にある場合、各クラスタ・メンバー・ノードにはサブネット192.168.0および10.0.0に接続されているインタフェースが必要です。

- プライベート・ネットワークでは、指定されているすべてのインターコネクト・インタフェースのエンドポイントがネットワークで確実にアクセス可能である必要があります。ノードはすべてのプライベート・ネットワーク・インタフェースに接続されている必要があります。pingを使用して、インターコネクト・インタフェースが接続可能であるかどうかをテストできます。

2.6.2 IPアドレス要件

インストールを開始する前に、各ノードにインタフェースが2つ以上構成されている必要があります。1つはプライベートIPアドレス用、もう1つはパブリックIPアドレス用です。

クラスタのIPアドレスおよび名前解決は、次のいずれかの方法で管理できます。

- Oracle Grid Naming Service(GNS)を使用した動的IPアドレスの割当て。このオプションを選択すると、ネットワーク管理者は静的IPアドレスを物理ホスト名に割り当て、動的に割り当てられたIPをOracle Clusterware管理VIPアドレスに割り当てます。この場合、VIPのIPアドレスはDHCPによって割り当てられ、クラスタ内でOracle Clusterwareの一部として構成されたマルチキャスト・ドメイン・ネーム・サーバーを使用して解決されます。GNSを使用する場合は、次のものが必要です。

- クラスタのために、パブリック・ネットワーク上で実行されているDHCPサービス。

- DHCP上の十分なアドレス。これにより、各ノードの仮想IPとしてIPアドレスを1つずつ、そしてクラスタの単一クライアント・アクセス名(SCAN)によって使用される、クラスタのIPアドレスを3つ提供します。

- 静的IPアドレスの割当て。このオプションを選択すると、ネットワーク管理者は固定IPアドレスをクラスタの各物理ホスト名とOracle Clusterware管理VIPのIPに割り当てます。また、各ノードには、ドメイン・ネーム・サーバー(DNS)に基づいた静的名前解決が使用されます。このオプションを選択する場合は、クラスタの変更時にネットワーク管理の更新を依頼する必要があります。

注意:
すべてのサーバー・ノードのパブリック・ホスト名には、静的なホスト名を使用することをお薦めします。
パブリックIPアドレスと仮想IPアドレスは、同じサブネット内にある必要があります。

DHCP割当てのネットワークは、デフォルトのネットワークでのみサポートされ、その後のネットワークではサポートされません。

2.6.2.1 グリッド・ネーミング・サービスのIPアドレス要件

グリッド・ネーミング・サービス(GNS)を有効にする場合、クラスタへの名前解決要求はGNSに委任され、GNSによってGNS仮想IPアドレスでリスニングされます。このアドレスは、インストール前にDNSドメインに定義します。DNSは、クラスタ名(クラスタに委任されたサブドメイン内のすべての名前)の解決要求がGNSに委任されるように構成する必要があります。要求がドメインに届くと、GNSによってその要求が処理され、要求された名前に対する適切なアドレスとともに応答が返されます。

GNSを使用するには、インストールの前に、サブドメインのDNS解決をクラスタに指示するDNS参照をDNS管理者が設定しておく必要があります。GNSを有効にする場合は、クラスタで必要な仮想IPアドレスをクラスタによって動的に割り当てるために、パブリック・ネットワーク上にDHCPサービスが必要です。

注意:
次の制限事項が、ご使用のシステムのベンダー構成に適用されます。

- ベンダーのクラスタウェアがインストールされている場合、ベンダーのクラスタウェアはGNSをサポートしないため、GNSを使用するように選択することはできません。

- 別のマルチキャストDNSでGNSを使用することはできません。GNSを使用する場合は、システム上のすべてのサード・パーティmDNSデーモンを無効にします。

2.6.2.2 手動で構成する場合のIPアドレス要件

GNSを有効にしない場合、各ノードのパブリックIPアドレスおよび仮想IPアドレスは、静的アドレスであることが必要です。このアドレスは、インストール前に各ノードで構成しておく必要がありますが、現在未使用である必要があります。パブリックIPアドレスと仮想IPアドレスは、同じサブネット内にある必要があります。

インストールのインタビュー時にプライベートとして指定したインタフェース上のプライベート・サブネットに含まれるプライベートIPアドレスが、Oracle Clusterwareによって管理されます。

クラスタには、次のアドレスが構成されている必要があります。

- 次の特性がある、各ノードのパブリックIPアドレス:

- 静的IPアドレス

- 各ノードへのインストール前に構成され、インストール前にそのノードに対して解決可能

- 他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある

- 次の特性がある、各ノードの仮想IPアドレス:

- 静的IPアドレス

- 各ノードへのインストール前に構成されるが、現在は使用されていない

- 他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある

- RFC 952標準に準拠し、英数字とハイフン("-")は使用できるが、アンダースコア("_")は使用できない。

- 次の特性がある、クラスタの単一クライアント・アクセス名(SCAN):

- 3つの静的IPアドレスにSCANとして指定された名前が関連付けられ、3つのアドレスすべてがDNSによってリクエスタにランダムな順番で戻されるように、インストール前にその3つのIPアドレスがドメイン・ネーム・サーバー(DNS)に構成されている

- インストール前にDNSで構成され、現在は使用されていないアドレスに解決される

- 数字以外で始まる名前が指定される

- 他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある

- RFC 952標準に準拠し、英数字とハイフン("-")は使用できるが、アンダースコア("_")は使用できない。

- 次の特性がある、各ノードのプライベートIPアドレス:

- 静的IPアドレス

- インストール前に構成され(ただし、別のプライベート・ネットワーク上で、独自のサブネットを使用)、他のクラスタ・メンバー・ノード以外では解決できない

SCANは、クラスタへのサービス・アクセスをクライアントに提供するために使用される名前です。SCANは、特定のノードではなくクラスタ全体に関連付けされているため、クライアントの再構成を必要とせずに、クラスタでノードを追加または削除することを可能にします。また、データベースに場所の独立性がもたらされるため、クライアント構成は特定のデータベースがどのノードで実行されているかに依存しません。クライアントは引き続き、以前のリリースと同じ方法でクラスタにアクセスできますが、クラスタにアクセスするクライアントではSCANの使用をお薦めします。

注意:
標準インストールでは、指定したSCANはクラスタの名前でもあります。拡張インストールでは、SCANとクラスタ名はインストール時に別のフィールドに入力します。
SCANおよびクラスタ名は長さ1文字以上15文字以下の英数字である必要があり、数字以外で始める必要があり、ハイフン(-)も使用できます。

DNSによってSCANが正しくアドレスに関連付けられていることを確認するには、nslookupコマンドを使用します。次に例を示します。

root@node1]$ nslookup mycluster-scan
Server:         dns.example.com
Address:        192.0.2.001

Name:   mycluster-scan.example.com
Address: 192.0.2.201
Name:   mycluster-scan.example.com
Address: 192.0.2.202
Name:   mycluster-scan.example.com
Address: 192.0.2.203

インストール後、クライアントがクラスタにリクエストを送信すると、Oracle ClusterwareのSCANリスナーはクライアント・リクエストをクラスタのサーバーにリダイレクトします。

注意:
SCAN VIPアドレスの構成は、hostsファイルで行わないことを強くお薦めします。SCAN VIPにはDNS解決を使用します。SCANの解決にhostsファイルを使用すると、1つのIPアドレスへの解決しかできず、SCANアドレスは1つのみになってしまいます。
DNSまたはhostsファイルでのSCANの構成のみがサポートされています。SCANをNetwork Information Service(NIS)で構成することはできません。

関連項目:
ネットワーク・アドレスの詳細は、付録C「ネットワーク・アドレスの理解」を参照してください。

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

ブロードキャスト通信(ARPおよびUDP)は、Oracle Grid Infrastructureリリース2パッチセット1(11.2.0.2)以上で使用するために構成されたすべてのパブリックおよびプライベート・インタフェース全体で適切に動作する必要があります。

ブロードキャストは、パブリックまたはプライベート・インタフェースによって使用されるものとして構成されたVLAN全体で動作する必要があります。

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

Oracle Grid Infrastructureリリース2(11.2)では、各クラスタ・メンバー・ノードで、Oracle mDNSデーモンがすべてのインタフェースでマルチキャスティングを使用して、クラスタの他のノードと通信します。

Oracle Grid Infrastructureリリース2パッチセット1(11.2.0.2)以上では、マルチキャスティングはプライベート・インターコネクトで必須です。このため、少なくとも次のクラスタでマルチキャスティングを有効にする必要があります。

- プライベート・インターコネクトとして定義されたブロードキャスト・ドメイン全体

- IPアドレス・サブネット範囲224.0.0.0/24および230.0.1.0/24

ルーター全体でマルチキャスト通信を有効にする必要はありません。

2.6.5 グリッド・ネーミング・サービスへのドメイン委任のためのDNS構成

GNSを使用する場合、Oracle Grid Infrastructureのインストール前に、GNSが提供するサブドメイン(クラスタ・メンバー・ノード)に対する名前解決要求がGNSへ送信されるよう、ドメイン・ネーム・サーバー(DNS)を構成しておく必要があります。次にドメイン委任に必要な手順の概要を示します。実際の手順はこの例と異なる場合があります。

委任を使用してGNS名前解決要求を送信するようにDNSを構成します。

1. DNSでGNS仮想IPアドレスのエントリを作成します。アドレスの書式はgns-server.CLUSTERNAME.DOMAINNAMEです。たとえば、クラスタ名がmyclusterで、ドメイン名がexample.comで、IPアドレスが192.0.2.1の場合、次のようなエントリを作成します。

mycluster-gns.example.com  A  192.0.2.1

指定したアドレスは、ルーティング可能である必要があります。

2. GNSでGNSサブドメインへのアドレスを解決できるように、GNS仮想IPアドレスへのGNSサブドメインの転送を設定します。これには、委任されたドメインに対して次のようなBIND構成エントリを作成します。cluster01.example.comは、委任するサブドメインです。

cluster01.example.com  NS  mycluster-gns.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)によってOracle SCANアドレス解決に問題が発生することがあります。nisエントリは、検索リストの最後に配置することをお薦めします。次に例を示します。

/etc/nsswitch.conf
hosts:    files   dns   nis

注意:
ホスト名およびユーザー名の解決が失敗する可能性があるため、NISを使用することがケーブルのプル・テストを実行するときの問題の原因になることがあることに注意してください。

2.6.6 グリッド・ネーミング・サービスの構成例

GNSを使用する場合は、GNSのVIPアドレスに静的なIPアドレスを指定し、その静的なGNSのIPアドレスにサブドメインを委任する必要があります。

クラスタにノードが追加されると、社内のDHCPサーバーによって、これらのノードに動的にアドレスが提供されます。これらのアドレスは自動的にGNSに登録され、GNSによってサブドメイン内で、GNSに登録されたクラスタ・ノード・アドレスの解決が行われます。

アドレスの割当てと構成はGNSによって自動的に行われるため、これ以上の構成は必要ありません。Oracle Clusterwareによって、クラスタに対してノードが追加または削除されるときに、動的なネットワーク構成が行われます。参考までに例を示します。

2ノードのクラスタで、GNSのVIPが定義されている場合、インストール後に次のような構成を2ノードのクラスタに対して行います。クラスタ名はmycluster、GNSの親ドメインはexample.com、サブドメインはgrid.example.comです。IPアドレスの192.0.2はクラスタのパブリックIPアドレス・ネットワークを表し、192.168.0はプライベートIPアドレス・サブネットを表します。

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

ID

ホーム・ノード

ホスト・ノード

指定された名前

種類

アドレス

アドレスの割当て元

解決方法

GNS VIP

なし

Oracle Clusterwareにより選択

mycluster-gns.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アドレスなど、複数のアドレスに解決される場合があります。

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

GNSを使用しない場合は、インストールの前に、パブリックIPアドレス、仮想IPアドレスおよびプライベートIPアドレスを構成する必要があります。また、pingコマンドを実行し、デフォルトのゲートウェイにアクセスできることも確認してください。デフォルトのゲートウェイを検出するには、routeコマンドを使用します(オペレーティング・システムのヘルプを参照)。

たとえば、各ノードに1つのパブリック・インタフェースと1つのプライベート・インタフェースがある2ノードのクラスタの場合に、3つのIPアドレスのいずれかに解決されるSCANドメイン・アドレスがDNSに定義してあるとすると、ネットワーク・インタフェースには、次の表に示す構成が考えられます。

表2-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では、インストール中にプライベート・インタフェースとして定義されたインタフェース(en1など)と、プライベート・サブネットに使用されるサブネットに、インターコネクト・アドレスが割り当てられます。

SCANが解決されるアドレスはOracle Clusterwareによって割り当てられるため、特定のノードには固定されません。VIPのフェイルオーバーが有効になるように、前述の表で示した構成では、SCANアドレスと、両方のノードのパブリック・アドレスおよびVIPアドレスが同一のサブネット(192.0.2)上に定義されています。

注意:
すべてのホスト名はRFC 952標準(英数字を許可)に準拠している必要があります。アンダースコア(_)を使用するホスト名は使用できません。

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

選択する正確なネットワーク構成は、構成するクラスタのサイズおよび使用方法と、必要な可用性のレベルによって異なります。

動作保証されているネットワーク接続ストレージ(NAS)をOracle RAC用に使用し、このストレージにイーサネットベースのネットワークを介して接続する場合は、NAS I/O用に3つ目のネットワーク・インタフェースが必要です。この場合、3つの別々のインタフェースを使用しないと、負荷によってパフォーマンスと安定性の問題が発生します。

2.7 ソフトウェア要件の特定

インストールする製品に応じて、次のオペレーティング・システム・ソフトウェアがシステムにインストールされていることを確認します。これらの要件を確認するには、第2章「ソフトウェア要件の確認」を参照してください。

ここに記載されている要件は、初回リリース日時点で最新のものです。カーネル要件の最新情報については、Oracle Technology Network(OTN)を参照してください。URLは次のとおりです。

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

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

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

表2-3 AIXオペレーティング・システムのカーネル要件

項目

要件

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

AIX 7.2 TL 0 SP 1 ("7200-00-01")以上、64ビット・カーネル

AIX 7.1 TL 0 SP1 (" 7100-00-01") 64-Bitカーネル

AIX 6.1 TL 02 SP1("6100-02-01")、64ビット・カーネル

AIX 5L V5.3 TL 09 SP1("5300-09-01")、64-Bitカーネル以上

AIX 7.2オペレーティング・システムのファイル・セット

次のオペレーティング・システムのファイル・セットが必要です。

bos.adt.base
bos.adt.lib
bos.adt.libm
bos.perf.libperfstat
bos.perf.perfstat
bos.perf.proctools
xlC.aix61.rte.13.1.2.0 or later
xlC.rte.13.1.2.0 or later

インストールには、IBM XL C/C++ランタイム・ファイル・セットが必要ですが、C/C++コンパイラは必要ありません。XL C/C++ランタイム・ファイル・セットのライセンスは必要ありません。

AIX 7.1オペレーティング・システムのファイル・セット

次のオペレーティング・システムのファイル・セットが必要です。

bos.adt.base
bos.adt.lib
bos.adt.libm
bos.perf.libperfstat
bos.perf.perfstat
bos.perf.proctools
xlC.rte.11.1.0.2 or later

インストールには、IBM XL C/C++ランタイム・ファイル・セットが必要ですが、C/C++コンパイラは必要ありません。XL C/C++ランタイム・ファイル・セットのライセンスは必要ありません。

AIX 6.1オペレーティング・システムのファイル・セット

次のオペレーティング・システムのファイル・セットが必要です。

bos.adt.base
bos.adt.lib
bos.adt.libm
bos.perf.libperfstat 6.1.2.1 or later
bos.perf.perfstat
bos.perf.proctools
rsct.basic.rte
rsct.compat.clients.rte
xlC.aix61.rte.10.1.0.0 or later
xlC.rte:10.1.0.0 or later

インストールには、IBM XL C/C++ランタイム・ファイル・セットが必要ですが、C/C++コンパイラは必要ありません。XL C/C++ランタイム・ファイル・セットのライセンスは必要ありません。

バージョン: IBM XL C/C++ Enterprise Edition for AIX、V9.0 September 2008 PTF

AIX 5Lオペレーティング・システムのファイル・セット

次のオペレーティング・システムのファイル・セットが必要です。

bos.adt.base
bos.adt.lib
bos.adt.libm
bos.perf.libperfstat
bos.perf.perfstat
bos.perf.proctools
rsct.basic.rte
rsct.compat.clients.rte
xlC.aix50.rte:10.1.0.0 (or later)

インストールには、IBM XL C/C++ランタイム・ファイル・セットが必要ですが、C/C++コンパイラは必要ありません。XL C/C++ランタイム・ファイル・セットのライセンスは必要ありません。バージョン: IBM XL C/C++ Enterprise Edition for AIX、V9.0 September 2008 PTF

C/C++コンパイラの取得

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

https://support.oracle.com

Oracle Grid Infrastructureでサポートされている最小のコンパイラはV. 9.0です。このソフトウェアは、次のWebサイトからダウンロードできます。

http://www-1.ibm.com/support/docview.wss?uid=swg24019055

注意: IBM XL C/C++コンパイラをインストールしない場合でも、AIX Runtime Environment Componentにコンパイラが必要です。ランタイム環境のファイルセットは、ライセンス要件なしにダウンロードすることができます。AIX 5.3およびAIX 6.1の最小推奨ランタイム環境は、次のURLから入手できます。

AIX 5.3およびAIX 6.1の場合:

IBM XL C/C++ for AIX, V10.1 Runtime Environment

http://www-01.ibm.com/support/docview.wss?rs=2239&uid=swg24019829

AIX 7.1の場合:

2010年9月版のRuntime for XL C/C++ for AIX (V11.1)

http://www-01.ibm.com/support/docview.wss?uid=swg24028034

AIX 7.2の場合:

2015年11月版のRuntime for XL C/C++ for AIX (V13.1)

http://www-01.ibm.com/support/docview.wss?uid=swg24041340

Oracle RACおよびHACMP

High Availability Cluster Multi-Processing(HACMP)5.4.1

注意: HACMPが必要となるのは、Oracle Clusterwareまたはデータベース・ファイル記憶域にRAW論理ボリュームを使用する場合のみです。ただし、これはすべてのインストールでサポートされます。OCRまたは投票ディスク・ファイルにRAWデバイスを使用することはできません。

HACMPまたはGPFSを使用する場合は、My Oracle Supportの証明書で最新の要件を確認してください。証明書は次のURLで入手できます。

https://support.oracle.com

HACMPを使用しない場合は、システムにHACMPをインストールしないでください。すでにHACMPがインストールされている場合は、次のものを削除する必要があります。

- HACMPファイル・セット(cluster.es.*)

- rsct.hacmp.rte

- rsct.compat.basic.hacmp.rte

- rsct.compat.clients.hacmp.rte

HACMPを使用する場合は、パッチ・セットを確認して、必要なパッチを確実に適用します。HACMP 5.4(5.4.1を含む)のファイル・セット・パッケージの変更には、Oracleのrootpre.shスクリプトに対する更新が必要です。Oracle Clusterwareをインストールする前に、パッチ6718715をダウンロードしてインストールします。

Oracle RACおよびGPFS

General Parallel File System(GPFS):

AIX 7.1:

GPFS 3.3.0.11

AIX 6.1:

gpfs.base 3.2.1.8 or later.

AIX 5L:

gpfs.base 3.2.1.8 or later

注意: GPFSは必須ではありません。GPFSは、Oracle Clusterwareにさらにクラスタ・ファイル・システムが必要な場合のみインストールしてください。

SSH

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

ADA

OC Systems PowerAda 5.5

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

https://support.oracle.com

JDK

次のいずれかのバージョンのJavaを使用してください。

Java 6 64-bit 6.0.0.50 IZ30726(SR2)

Java 5 64-bit 5.0.0.250 IZ55274 (SR10)

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

https://support.oracle.com

Pro*FORTRAN

IBM XL Fortran v. 11.1 April 2008 PTF for AIX

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

https://support.oracle.com

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

注意: C/C++コンパイラをインストールしない場合でも、インストールにはC/C++ランタイム・ファイル・セットが必要です(この表の「オペレーティング・システムのファイル・セット」を参照)。

- IBM XL C/C++ Enterprise Edition for AIX, V9.0 April 2008 PTF:
PTFは、次のリンクからダウンロードできます。

http://www-1.ibm.com/support/docview.wss?uid=swg24015075

ライセンス要件のないC++ランタイム環境ファイル・セットは、次のWebサイトからダウンロードします。

http://www-1.ibm.com/support/docview.wss?uid=swg24015077

- gcc 3.4.5

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

https://support.oracle.com

Pro*COBOL

- IBM COBOL for AIXバージョン4.1 (September 2010 PTF)

- IBM COBOL for AIXバージョン3.1

- Micro Focus Server Express 5.1

AIX 7.1およびAIX 7.2の場合は、My Oracle Supportの証明書で最新の要件を確認してください。証明書は次のURLで入手できます。

https://support.oracle.com

Oracle Messaging Gateway

IBM WebSphere MQ for AIX V6.0.2.3、クライアントおよびサーバー

mqm.Client.Bnd
mqm.Server.Bnd

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

https://support.oracle.com

次のパッチがシステムにインストールされていることを確認します。表の後に、これらの要件を確認する手順を示します。

注意:

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

- AIX APAR番号は、AIXのバージョンおよびテクノロジ・レベルと関係付けられています。AIXのバージョンおよびテクノロジ・レベルと合致するAPARを、次のURLのIBM Fix Central Webサイトからダウンロードし、インストールしてください。
http://www-933.ibm.com/support/fixcentral/

表2-4 AIX APARおよびその他のオペレーティング・システム修正

インストール・タイプまたは製品

要件

AIX 7.2インストール

前述のAIX 7.2にオペレーティング・システムの最小TLレベルを使用している場合は、次のAIX 7.2 TL 0 SP1用のAuthorized Problem Analysis Report(APAR)をインストールします。

IV79639 - ライブ・アップデート後、ifixの状態がQのままになる場合があり、再起動が必要です。

IV79848 - 最小およびマイグレーション・インストールでmirrorvg/syncvgが失敗します。

IV80412 - アプリケーションによるシグナル・マスクの設定でシステムがクラッシュします。

注意: IV79441 (procfsを使用した32ビット・プロセス・マップ・ファイルの読取りによるシステム・クラッシュの可能性)に必要な修正を含むIV80412m1aをインストールしてください。

このリリース用に示されている最小レベルより後のTLを使用する場合は、IBMに連絡して、システムにインストールされているTLレベルに、ここに示されている必要なAPARが含まれているかどうかを確認してください。含まれている場合は、インストールする必要はありません。含まれていない場合は、該当するTLレベル用に同等のAPARをインストールする必要があります。

AIX 7.1のインストール

前述のAIX 7.1にオペレーティング・システムの最小TLレベルを使用している場合は、次のAIX 7.1 TL 0 SP1用のAuthorized Problem Analysis Report(APAR)をインストールします。

IZ87216
IZ87564
IZ89165
IZ97035

このリリース用に示されている最小レベルより後のTLを使用する場合は、IBMに連絡して、システムにインストールされているTLレベルに、ここに示されている必要なAPARが含まれているかどうかを確認してください。含まれている場合は、インストールする必要はありません。含まれていない場合は、該当するTLレベル用に同等のAPARをインストールする必要があります。

AIX 6.1のインストール

このリリース用に示されている最小レベルより後のTLを使用する場合は、IBMに連絡して、システムにインストールされているTLレベルに、ここに示されている必要なAPARが含まれているかどうかを確認してください。含まれている場合は、インストールする必要はありません。含まれていない場合は、該当するTLレベル用に同等のAPARをインストールする必要があります。

前述のAIX 6.1にオペレーティング・システムの最小TLレベルを使用している場合は、次のAIX 6.1 TL 02 SP1用のAuthorized Problem Analysis Report(APAR)をインストールします。

IZ41855
IZ51456
IZ52319
IZ97457
IZ89165

これらの6.1修正は、すでに次のTLレベルに存在します。

- AIX 6.1 TL 02 SP-04以上

- AIX 6.1 TL 03 SP-02以上

- AIX 6.1 TL 04

このリリース用に示されている最小レベルよりも後のTLレベルを使用している場合、オペレーティング・システムの不具合用の次のパッチを適用します。

BIND64 CORES WITH -BLAZY OPTION

オペレーティング・システムのTLレベルに適した次のAPAR番号を使用したパッチをダウンロードします。

- AIX 6.1 TL 03の場合: AIX APAR IZ89304を使用

- AIX 6.1 TL 04の場合: AIX APAR IZ89302を使用

- AIX 6.1 TL 05の場合: AIX APAR IZ89300を使用

- AIX 6.1 TL 06 SP4の場合: AIX APAR IZ88711を使用

- AIX 6.1 TL 06 SP5の場合: AIX APAR IZ89514を使用

- AIX 6.1 TL 07の場合: AIX APAR IZ88880を使用

AIX 5Lインストール

このリリース用に示されている最小レベルより後のTLを使用する場合は、IBMに連絡して、システムにインストールされているTLレベルに、ここに示されている必要なAPARが含まれているかどうかを確認してください。含まれている場合は、インストールする必要はありません。含まれていない場合は、該当するTLレベル用に同等のAPARをインストールする必要があります。

前述のAIX 5Lにオペレーティング・システムの最小TLレベルを使用している場合は、次のAIX 5L V5.3 TL 09 SP1用のAuthorized Problem Analysis Report(APAR)をインストールします。

IZ42940
IZ49516
IZ52331

これらの修正は、すでに次のTLレベルに存在します。

- AIX 5.3 TL 09 SP-05以上

- AIX 5.3 TL 10 SP-02以上

- AIX 5.3 TL 11

Oracle JDBC/OCIドライバ

AIX 5L v5.3

注意: これらのAPARが必要となるのは、関連するJDKバージョンを使用する場合のみです。

JDK 1.4.2(64-bit)に必要なAPAR:

- IY63533: JDK 1.4.2 64-bit SR1 caix64142-20040917

Oracle ODBCドライバ

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

Oracle DatabaseでODBCを使用するには、gcc 3.4.5以上もインストールする必要があります。

AIXでは、Oracle ODBCドライバはODBCドライバ・マネージャ2.2.12について動作保証されています。ドライバ・マネージャは次のリンクからダウンロードしてインストールできます。

http://www.unixodbc.org

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

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

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

# oslevel -r

オペレーティング・システムのバージョンがAIX 5.3未満の場合は、オペレーティング・システムをこのメンテナンス・レベル以上にアップグレードします。AIX 5Lバージョン5.3メンテナンス・パッケージは、次のWebサイトから入手できます。

http://www-933.ibm.com/support/fixcentral/

2. 次のコマンドを入力して、必要なファイル・セットがインストールおよびコミットされているかどうかを確認します。

# lslpp -l bos.adt.base bos.adt.lib bos.adt.libm bos.perf.libperfstat \
bos.perf.perfstat bos.perf.proctools rsct.basic.rte rsct.compat.clients.rte \
xlC.aix61.rte

ファイル・セットがインストールおよびコミットされていない場合は、インストールします。ファイル・セットのインストールについては、ご使用のオペレーティング・システムまたはソフトウェアのマニュアルを参照してください。

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

1. 次のコマンドを入力して、必要なAPARがインストールされているかどうかを確認します。

# instfix -i -k "IZ41855 IZ51456 IZ52319"

APARがインストールされていない場合は、次のWebサイトからダウンロードして、インストールします。

http://www-933.ibm.com/support/fixcentral/

2. 次のコマンドを入力して、PTFがインストールされているかどうかを確認します。

# lslpp -l -B U489726 U485561 ...

PTFがインストールされていない場合は、次のWebサイトからダウンロードして、インストールします。

http://www-933.ibm.com/support/fixcentral/

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

http://www-01.ibm.com/software/

2.9 UDPおよびTCPカーネル・パラメータの検証

サーバーの予測負荷に対応できる十分なエフェメラル・ポートを提供するために、AIXカーネルのTCP/IPエフェメラル・ポート範囲が十分な大きさになるようにNDDを使用します。Well Knownポートを避け、通常、Oracleとその他のサーバー・ポートが使用する登録済ポートの範囲にあるポートを避けるために、範囲の下限が9000以上になるようにします。ポート範囲は、使用する予定のアプリケーションに予約されているポートを避けるために十分に高く設定します。範囲の下限値が9000より大きく、予測負荷に十分対応するだけの大きさがある場合は、エフェメラル・ポート範囲に関するOUIの警告は無視してかまいません。

次に例を示します。

# /usr/sbin/no -a | fgrep ephemeral
tcp_ephemeral_low = 32768
tcp_ephemeral_high = 65535
udp_ephemeral_low = 32768
udp_ephemeral_high = 65535

上の例で、TCPおよびUDPエフェメラル・ポートはデフォルトの範囲(32768-65536)に設定されています。

高い値のエフェメラル・ポートが必要な負荷になることが予測できる場合は、UDPおよびTCPエフェメラル・ポートの範囲を広くします。次に例を示します。

# /usr/sbin/no -p -o tcp_ephemeral_low=9000 -o tcp_ephemeral_high=65500
# /usr/sbin/no -p -o udp_ephemeral_low=9000 -o udp_ephemeral_high=65500

2.10 AIXのリソース制限のチェック

AIXプラットフォームでは、/etc/security/login.cfgファイルが、システム上のユーザーのリソースを制御および制限します。サービス攻撃の否認を防ぐために、pam.confファイルを通じて認証が行われるようにするため、ログイン時にシステム上のユーザーのリソースの制御および制限を設定する必要があります。

AIXオペレーティング・システムに対して、リソース制限はデフォルトではstd_authに設定されます。uswスタンザのauth_typeをstd_authからpam_authに変更するには、ファイル/etc/security/login.cfgファイルを編集します。

これらのリソース制限が考慮されることを確認するには、login session required /usr/lib/security/pam_aix行が/etc/pam.confに設定されていることを確認します。次に例を示します。

dtsession auth  required        /usr/lib/security/pam_aix
dtlogin session required        /usr/lib/security/pam_aix
ftp     session required        /usr/lib/security/pam_aix
imap    session required        /usr/lib/security/pam_aix
login   session required        /usr/lib/security/pam_aix
rexec   session required        /usr/lib/security/pam_aix
rlogin  session required        /usr/lib/security/pam_aix
rsh     session required        /usr/lib/security/pam_aix
snapp   session required        /usr/lib/security/pam_aix
su      session required        /usr/lib/security/pam_aix
swrole  session required        /usr/lib/security/pam_aix
telnet  session required        /usr/lib/security/pam_aix
xdm     session required        /usr/lib/security/pam_aix
OTHER   session required        /usr/lib/security/pam_prohibit
websm_rlogin    session    required     /usr/lib/security/pam_aix
websm_su        session    required     /usr/lib/security/pam_aix
wbem       session       required    /usr/lib/security/pam_aix

2.11 AIXシステム環境のチューニング

すべてのクラスタ・ノードで、次のシステム・チューニングおよび構成を実行します。

- 非同期入出力プロセスの確認

- Virtual Memory Manager(VMM)のチューニング

- システムのブロック・サイズ割当ての追加

- AIXでのSSH LoginGraceTimeパラメータの構成

- シェル制限の構成

- ユーザー・プロセス・パラメータの構成

- ネットワーク・チューニング・パラメータの構成

注意:
この項には、パラメータおよびシェル制限の推奨値のみを示します。本番データベース・システムでは、これらの値を調整してシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。

2.11.1 非同期入出力プロセスの確認

AIX 5では、rootpre.shスクリプトを実行して、Asynchronous Input Output(AIO)デバイス・ドライバを有効にします。AIX 6では、AIOデバイス・ドライバはデフォルトで有効になっています。AIX 5とAIX 6の両方で、aioserverプロセスの数をデフォルトから増やします。aio_maxreqsの推奨値は64k(65536)です。AIX 5とAIX 6の両方で、この値を確認してください。

ご使用のリリースごとの手順で、aio_maxreqs値を確認します。

AIX 6.1および7.1:

# ioo -o aio_maxreqs
aio_maxreqs = 65536

AIX 5.3:

# lsattr -El aio0 -a maxreqs
maxreqs 65536 Maximum number of REQUESTS True

ファイル・システムへの非同期I/Oの実行時、それぞれの非同期I/O操作が1つの非同期I/Oサーバーに関連付けられていることに注意してください。つまり、非同期I/Oサーバーの数によって、システムで同時実行される非同期I/O操作の数が決まります。

システムの再起動時に起動されるサーバーの初期数は、minserversパラメータによって決まります。同時実行される非同期I/O操作が発生すると、最大でmaxserversパラメータに設定した値の追加の非同期I/Oサーバーが起動します。

AIX 5.3でファイル・システムにデータファイルのあるOracle Databaseを使用する場合は、minserversおよびmaxserversのデフォルト値が小さすぎるため、これらの値を増やします。各プロセッサのI/O kprocsに基づいてminserversおよびmaxservers値を増やします。

通常、非同期I/Oサーバーの数を設定するには、次の手順を実行します。

1. maxserversの初期値を、同時に実行するディスク数の10倍をCPU数で割った値(ただし、80以下)に調整します。

2. 高I/Oアクティビティ期間のシステムのパフォーマンスへの影響を監視します。すべてのAIOサーバー・プロセスが起動したら、maxserversの値を増やします。また、AIOサーバーを追加したことによるメリットがあったかどうかを判断するために、I/Oアクティビティのピーク時のシステム・パフォーマンスも監視し続けます。非同期I/Oサーバーが多すぎると、追加プロセスによるメモリーおよびプロセッサのオーバーロードが増えますが、これによるデメリットはわずかです。AIOパラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。

起動されているAIOサーバー・プロセスの数を監視するには、次のコマンドを入力します。

# ps -ek|grep -v grep|grep –v posix_aioserver|grep -c aioserver

注意:
AIX 6.1以上では、minserversおよびmaxserversは、それぞれaio_minserversおよびaio_maxserversパラメータに置き換えられています。

関連項目:
第2.15項「rootpre.shスクリプトの実行」

2.11.2 Virtual Memory Manager(VMM)のチューニング

vmoコマンドを使用して、仮想メモリーで次の値を使用するようにチューニングすることをお薦めします。

表2-5 Virtual Memory Managerの推奨値

パラメータ

値

minperm%

3(AIX 5.3のデフォルトは20)

maxperm%

90(AIX 5.3のデフォルトは80)

maxclient% = 90

90(AIX 5.3のデフォルトは80)

lru_file_repage

0(AIX 5.3のデフォルトは1)

strict_maxclient

1(AIX 5.3のデフォルトは1)

strict_maxperm

0(AIX 5.3のデフォルトは0)

次に例を示します。

vmo -p -o minperm%=3
vmo -p -o maxperm%=90
vmo -p -o maxclient%=90
vmo -p -o lru_file_repage=0
vmo -p -o strict_maxclient=1
vmo -p -o strict_maxperm=0

これらの変更を有効にするには、システムを再起動する必要があります。

2.11.3 システムのブロック・サイズ割当ての追加

ARG/ENVリストへの領域割当てを128に増やすことをお薦めしますサイズは4Kブロックの数で指定します。

次に例を示します。

/usr/sbin/chdev -l sys0 -a ncargs='128'

2.11.4 AIXでのSSH LoginGraceTimeパラメータの構成

AIXシステムでは、OpenSSHパラメータLoginGraceTimeはデフォルトでコメント・アウトされており、AIXでのOpenSSHのデフォルトの動作は、タイムアウト・エラーになる場合があります。これらのエラーを回避するには、次の手順を実行します。

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

2. テキスト・エディタを使用して、OpenSSH構成ファイル/etc/ssh/sshd_configを開きます。

3. コメント行#LoginGraceTime 2mを検索します。

4. その行をコメント解除して、値を0(無制限)に変更します。次に例を示します。

LoginGraceTime 0

5. /etc/ssh/sshd_configを保存します。

6. SSHを再起動します。

2.11.5 シェル制限の構成

Oracle Grid Infrastructureのインストール所有者およびrootのシェル制限を設定します。smitユーティリティを使用するか、/etc/security/limitsファイルを編集し、両方のアカウントが無制限に設定されていることを確認します。crsデーモン(crsd)はrootで実行されるため、rootユーザーにはこれらの設定が必要です。

シェル制限

limits.conf内の項目

ハード制限

オープン・ファイル記述子の最大数

nofile

-1(無制限)

ユーザー1人当たりに使用可能なプロセスの最大数

nproc

-1(無制限)

プロセスのスタック・セグメントの最大サイズ

stack

-1(無制限)

シェル制限を増やすには、次の手順を実行します。

1. /etc/security/limitsファイルに、次の行を追加します。

default:
fsize = -1
core = 2097151
cpu = -1
data = -1
rss = -1
stack = -1
nofiles = -1

2. 次のコマンドを入力して、Oracleソフトウェア・ユーザーに許可されている現在の最大プロセス数をリストします。

/usr/sbin/lsattr -E -l sys0 -a maxuproc

必要に応じて、次のコマンドを使用してmaxuproc設定を変更します。

/usr/sbin/chdev -l sys0 -a maxuproc=16384

3. クラスタの他のすべてのノードで、この手順を繰り返します。

注意:
ご使用のオペレーティング・システム・ベンダーでサポートされているシェル・プログラムを使用してください。ご使用のオペレーティング・システムでサポートされていないシェル・プログラムを使用すると、インストール中にエラーが発生する場合があります。

2.11.6 ユーザー・プロセス・パラメータの構成

各ユーザーに許可されているプロセスの最大数が2048以上であることを確認します。

注意:
本番システムの場合、この値は、システムで実行している各データベースのPROCESSESおよびPARALLEL_MAX_SERVERS初期化パラメータの合計に128を加算した値以上である必要があります。

1. 次のコマンドを入力します。

# smit chgsys

2. 「Maximum number of PROCESSES allowed for each user」に表示される値が2048以上であることを確認します。
必要に応じて既存の値を編集します。

3. 変更が完了したら、[Enter]を押した後、[Esc]+[0]を押して終了します。

2.11.7 ネットワーク・チューニング・パラメータの構成

次の表に示すネットワーク・チューニング・パラメータが、表に示されている値以上に設定されていることを確認します。表の後に、値を確認して設定する手順を示します。

ネットワーク・チューニング・パラメータ

推奨値

ipqmaxlen

512

rfc1323

1

sb_max

4194304

tcp_recvspace

65536

tcp_sendspace

65536

udp_recvspace

655360
注意: このパラメータの推奨値は、udp_sendspaceパラメータの値の10倍です。これは、sb_maxパラメータの値より小さい値である必要があります。

udp_sendspace

65536
注意: この値は、デフォルトのデータベース・インストールに適しています。本番データベースの場合、このパラメータの最小値は、データベースのDB_BLOCK_SIZE初期化パラメータの値をDB_MULTIBLOCK_READ_COUNT初期化パラメータの値で乗算したものに4KBを加算した値です。

(DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT) + 4 KB

これらのパラメータに指定されている現行の値を表示し、必要に応じて変更するには、次の手順を実行します。

1. 次のコマンドを入力して、ネットワーク・チューニング・パラメータの現行の値を確認します。

# no -a | more

2. パラメータの値を変更する必要がある場合は、次のコマンドを入力し、システムが互換性モードで実行されているかどうかを確認ます。

# lsattr -E -l sys0 -a pre520tune

システムが互換性モードで実行されている場合、出力は次のようになり、pre520tune属性の値がenableであることが示されます。

pre520tune enable Pre-520 tuning compatibility mode True

3. システムが互換性モードで実行されている場合は、次の手順に従って、パラメータの値を変更します。

1. 次のコマンドを入力して、各パラメータの値を変更します。

# no -o parameter_name=value

次に例を示します。

# no -o udp_recvspace=655360

2. 前述の手順で変更した各パラメータの/etc/rc.netファイルに、次のエントリを追加します。

if [ -f /usr/sbin/no ] ; then
/usr/sbin/no -o udp_sendspace=65536
/usr/sbin/no -o udp_recvspace=655360
/usr/sbin/no -o tcp_sendspace=65536
/usr/sbin/no -o tcp_recvspace=65536
/usr/sbin/no -o rfc1323=1
/usr/sbin/no -o sb_max=4194304
/usr/sbin/no -o ipqmaxlen=512
fi

これらの行を/etc/rc.netファイルに追加すると、システムの再起動時に値が保持されます。

システムを再起動せずにRFC1323値を設定することもできます。

chdev -l en5 -a rfc1323=1

4. システムが互換性モードで実行されていない場合は、次のコマンドを入力して、パラメータの値を変更します。

- ipqmaxlenパラメータ:

/usr/sbin/no -r -o ipqmaxlen=512

- その他のパラメータの場合:

/usr/sbin/no -p -o parameter=value

注意:
ipqmaxlenパラメータを変更した場合は、システムを再起動する必要があります。

これらのコマンドによって/etc/tunables/nextbootファイルが変更され、システムの再起動時に属性の値が保持されるようになります。

5. パラメータを変更する必要があり、システムを再起動しない場合は、noグローバル設定の変更後、ifconfigコマンドを使用し、各ネットワーク・パラメータを確認します。
次に例を示します。

# ifconfig en0
en0:
flags=1e080863,2c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,6
4BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN,MONITOR>
inet 192.0.2.1 netmask 0xfffff800 broadcast 192.0.2.0
inet 192.0.2.2 netmask 0xfffff800 broadcast 192.0.2.0
inet 192.0.2.3 netmask 0xfffff800 broadcast 192.0.2.0
inet 192.0.2.4 netmask 0xfffff800 broadcast 192.0.2.0
tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0

ISNOパラメータtcp_sendspaceの設定には、次のコマンドを使用します。

# ifconfig en0 tcp_sendspace 65536

関連項目:
使用しているシステムに合わせAIXパラメータを調整する方法の詳細は、IBMのマニュアルを参照してください。

2.12 ネットワーク・タイム・プロトコルの設定

Oracle Clusterwareでは、すべてのクラスタ・ノードで同じのタイムゾーン設定が必要です。インストール中に、インストール・プロセスは、OUIを実行しているノードでグリッド・インストール所有者のタイムゾーン設定を選択し、Oracle Clusterwareによって管理されるすべてのプロセスのデフォルトのTZ設定として、すべてのノードでその設定を使用します。このデフォルトは、データベース、Oracle ASMおよびその他の管理プロセスで使用されます。

時刻を同期させるための手段は2つあります。オペレーティング・システムに構成されているネットワーク・タイム・プロトコル(NTP)と、Oracleクラスタ時刻同期化サービスです。Oracleクラスタ時刻同期化サービスは、クラスタ・サーバーからNTPサービスにアクセスできない組織のために設計されています。NTPを使用する場合は、Oracle Cluster時刻同期化デーモン(ctssd)は、オブザーバ・モードで起動します。NTPデーモンがない場合、ctssdはアクティブ・モードで起動し、外部時間サーバーに接続しなくても、クラスタ・メンバー間で時刻を同期します。

注意:
Oracle Grid Infrastructureのインストールを開始する前に、すべてのノードの時計が同じ時刻になっていることを確認することをお薦めします。

サーバー上にNTPデーモンがあっても時間サーバーの時刻と同期されるように構成できない場合に、クラスタ時刻同期化サービスを使用してクラスタ内で同期化サービスを提供する場合は、NTPを非アクティブにし、削除します。

NTPサービスを無効にするには、次のコマンドをrootユーザーとして実行します。

# stopsrc -s xntpd

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

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

$ crsctl stat resource ora.ctssd -t -init

NTPを使用しており、クラスタ時刻同期化サービスではなくNTPを使用し続ける場合は、NTP初期化ファイルを変更してスルーイングを有効にし、逆向きの時間調整が行われないようにします。この作業が終わった後で、ネットワーク・タイム・プロトコル・デーモンを再起動します。

AIXでこれを行うには、ファイル/etc/rc.tcpipを編集し、システムが再起動するたびにXNTPデーモンが起動するように構成します。

1. /etc/rc.tcpipファイルを開き、次の行を検索します。

start /usr/sbin/xntpd "$src_running"

2. この行を次の行に変更します。

start /usr/sbin/xntpd "$src_running" "-x"

3. ファイルを保存します。

無効にしたXNTPを有効にするには、各クラスタ・メンバー・ノードで次のコマンドを入力します。

# startsrc -s xntpd -a "-x"

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

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

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

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

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

関連項目:
ユーザー・プロファイルのsttyコマンドを削除する方法の詳細は、第2.14.5項「端末出力が原因のインストール・エラーの回避」を参照してください。

デフォルトでは、OUIはディレクトリ/usr/local/etc/でSSH公開鍵、/usr/local/binでssh-keygenバイナリを検索します。ただし、AIXの場合、SSH公開鍵は通常はパス/etc/sshにあり、ssh-keygenバイナリはパス/usr/binにあります。OUIでSSHを設定できるようにするには、次のコマンドを使用してソフト・リンクを作成します。

# ln -s /etc/ssh /usr/local/etc
# ln -s /usr/bin /usr/local/bin

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

LoginGraceTime 0

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

インストーラ・ソフトウェアは、Oracle Grid Infrastructureインストール所有者ユーザー・アカウント(oracleまたはgrid)で実行します。ただし、インストーラを起動する前に、インストール所有者ユーザー・アカウントの環境を構成する必要があります。また、必要に応じて、他の必要なOracleソフトウェア所有者を作成します。

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

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

- Oracle DatabaseおよびOracle ASM所有者の環境要件

- 表示およびX11転送の構成の設定

- 端末出力が原因のインストール・エラーの回避

2.14.1 Oracle Grid Infrastructureソフトウェア所有者の環境要件

Oracle Grid Infrastructureソフトウェア所有者の環境を構成するには、次の変更を行う必要があります。

- シェル起動ファイルで、インストール・ソフトウェア所有者ユーザー(grid、oracle)のデフォルトのファイル・モード作成マスク(umask)を022に設定します。 マスクを022に設定すると、ソフトウェア・インストールを実行するユーザーが作成するファイルの権限は常に644になります。

- インストール・ソフトウェア所有者(grid、oracle)のファイル記述子およびプロセスに対して、ulimitを設定します。

- Oracle Grid Infrastructureをインストールする準備として、ソフトウェア所有者のDISPLAY環境変数を設定します。

2.14.2 Oracle DatabaseおよびOracle ASM所有者の環境要件

Oracle DatabaseまたはOracle ASMをインストールする場合は、次の追加タスクを実行します。ロールベースの権限メソッドを使用して他のソフトウェアをインストールする場合は、Oracle Databaseソフトウェア所有者(oracle)およびOracle ASMソフトウェア所有者(asm)に対し、次のタスクを実行します。

- Oracleベースのパスを作成します。OracleベースのOptimal Flexible Architectureパスは、/u01/app/userです。userは、Oracle Databaseソフトウェアを所有するユーザー・アカウントの名前です。たとえば、/u01/app/oracleです。

注意:
Oracle ClusterwareホームをOracleベースに作成しないでください。Oracleベース・ディレクトリのパスにOracle Clusterwareインストールを作成すると、その後のOracleインストールが失敗します。

- シェル起動ファイルで、インストール・ソフトウェア所有者ユーザー(asm、oracle)のデフォルトのファイル・モード作成マスク(umask)を022に設定します。 マスクを022に設定すると、ソフトウェア・インストールを実行するユーザーが作成するファイルの権限は常に644になります。

- Oracle ASMまたはOracle Databaseをインストールする準備として、ソフトウェア所有者の環境変数にDISPLAY環境変数を設定します。

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

Oracleソフトウェア所有者の環境を設定するには、ソフトウェア所有者(grid、oracle)ごとに次の手順を実行します。

1. X端末(xterm)などの端末セッションを新規に開始します。

2. 次のコマンドを入力して、このシステムでX Windowアプリケーションが表示可能であることを確認します。

$ 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、BashまたはKornシェル:

$ . ./.profile

- Cシェル:

% source ./.login

11. ローカル・システムにソフトウェアをインストールしていない場合は、次のコマンドを入力してXアプリケーションをローカル・システムに表示します。

- Bourne、BashまたはKornシェル:

$ DISPLAY=local_host:0.0 ; export DISPLAY

- Cシェル:

% setenv DISPLAY local_host:0.0

この例で、local_hostは、OUIを表示するためのシステム(ご使用のワークステーションまたはPC)のホスト名またはIPアドレスです。

12. /tmpディレクトリの空き領域が1GB未満である場合は、空き領域が1GB以上のファイル・システムを選択し、環境変数TEMPおよびTMPDIRを設定してこのファイル・システムの一時ディレクトリを指定します。

注意:
Oracle RACのインストール用の一時ファイル・ディレクトリ(通常、/tmp)の場所として、共有ファイル・システムは使用できません。共有ファイル・システムに/tmpを配置すると、インストールは失敗します。

1. df -kコマンドを使用して、十分な空き領域を持つ適切なファイル・システムを選択します。

2. 必要に応じて、次のコマンドを入力し、選択したファイル・システムに一時ディレクトリを作成して、そのディレクトリに適切な権限を設定します。

$ su - root
# mkdir /mount_point/tmp
# chmod 775 /mount_point/tmp
# exit

3. 次のコマンドを入力して、環境変数TEMPおよびTMPDIRを設定します。

- Bourne、BashまたはKornシェル:

$ TEMP=/mount_point/tmp
$ TMPDIR=/mount_point/tmp
$ export TEMP TMPDIR

- Cシェル:

% setenv TEMP /mount_point/tmp
% setenv TMPDIR /mount_point/tmp

2.14.4 表示および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. ForwardX11属性がnoに設定されていることを確認します。次に例を示します。

Host *
ForwardX11 no

2.14.5 端末出力が原因のインストール・エラーの回避

Oracle Grid Infrastructureのインストール中、OUIは、SSHを使用してコマンドを実行したり、他のノードにファイルをコピーします。システム上の隠しファイル(.bashrcや.cshrcなど)にsttyコマンドが含まれていると、インストール中にMakeファイルやその他のインストールに関するエラーが発生します。

この問題を回避するには、STDOUTまたはSTDERRでのすべての出力が停止されるように、次の手順に従って、Oracleインストール所有者ユーザーのホーム・ディレクトリにあるこれらのファイルを変更する必要があります(sttyやxtitleなどのコマンド)。

- Bourne、BashまたはKornシェル:

if [ -t 0 ]; then
stty intr ^C
fi

- Cシェル:

test -t 0
if ($status == 0) then
stty intr ^C
endif

注意:
SSHを使用できない場合、インストーラは、 ssh および scp コマンドのかわりに rsh および rcp を使用します。
リモート・シェルによってロードされる隠しファイルにsttyコマンドが含まれている場合も、エラーが発生し、インストールが停止されます。

2.15 rootpre.shスクリプトの実行

注意:
このシステムに、より新しいリリースのOracleデータベース・ソフトウェアをすでにインストールしている場合は、rootpre.shスクリプトを実行しないでください。

rootpre.shスクリプトは、次の手順で実行します。

1. ユーザーをrootに切り替えます。

$ su - root

2. インストールの場所に応じて、次の手順のいずれかを実行します。
インストール・ファイルがディスクにある場合は、次のコマンドを入力します。directory_pathは、ディスク・マウント・ポイント・ディレクトリまたはDVDのデータベース・ディレクトリのパスです。

# /directory_path/rootpre.sh

インストール・ファイルがハード・ディスクにある場合は、ディレクトリをDisk1ディレクトリに変更し、次のコマンドを入力します。

# ./rootpre.sh

3. rootアカウントを終了します。

# exit

4. クラスタのすべてのノードで手順1から3を繰り返します。

注意:
このシステムに、より新しいリリースのOracleデータベース・ソフトウェアをすでにインストールしている場合は、rootpre.shスクリプトを実行しないでください。

2.16 hagsuserグループへのグリッド・インフラストラクチャ・インストール所有者の追加

システムにHACMPをインストール済の場合は、rootpre.shコマンドによってhagsuserグループが作成されます。グリッド・インフラストラクチャのインストール所有者(grid)をそのグループのメンバーにする必要があります。

次のようなコマンドを入力して、Oracle Grid Infrastructure所有者(grid)をhaguserに追加します。

# /usr/bin/chgrpmem -m + grid hagsuser

Oracle Grid Infrastructureインストール所有者をhagsuserグループに追加した後、Oracle Grid Infrastructureで使用する前に、HACMPを停止して再起動します。

2.17 Oracle Grid Infrastructureホーム・ディレクトリの作成要件

インストール中に、Oracle Clusterwareバイナリを格納するホーム・ディレクトリへのパスを指定するように求められます。指定するディレクトリ・パスが次の要件を満たすことを確認します。

- Oracle Clusterwareホームを含む、既存のOracleホーム以外のパスに作成する必要があります。

- ユーザー・ホーム・ディレクトリには作成できません。

- すべてのファイルをrootによって所有可能なパス内のサブディレクトリとして作成するか、一意のパス内に作成します。

- インストール前にパスを作成する場合は、Oracle Grid Infrastructureのインストール所有者(通常、すべてのOracleソフトウェアに対して1つのインストール所有者の場合はoracle、ロール・ベースのOracleインストール所有者の場合はgrid)が所有し、権限が775に設定されている必要があります。

Oracle Grid Infrastructureは、共有記憶域の共有ホームではなく、ローカル・ホームにインストールすることをお薦めします。

Oracle Grid Infrastructureのみをインストールする場合は、Oracle Optimal Flexible Architecture(OFA)に準拠したパスを作成することをお薦めします。これによって、Oracle Universal Installer(OUI)がインストール中にそのディレクトリを選択できるようになります。OUIがパスをOracleソフトウェア・パスとして認識するには、u0[1-9]/appという形式にする必要があります。

OUIでOFA準拠のパスが検出されると、Oracle Grid InfrastructureおよびOracle Inventory(oraInventory)ディレクトリが作成されます。

手動でOracle Grid Infrastructureのパスを作成する場合は、既存のOracleベース・パスではなく、別のパスの下に作成します。次に例を示します。

# mkdir -p  /u01/app/11.2.0/grid
# chown grid:oinstall /u01/app/11.2.0/grid
# chmod -R 775 /u01/app/11.2.0/grid

このパスでは、インストール所有者の名前がgridの場合、OUIによってデフォルトで、グリッド・ホームとして次のパスが作成されます。

/u01/app/11.2.0/grid

データベースのインストールのために、Oracle Databaseインストール所有者アカウントを所有者とするOracleベース・パスを作成します。OracleベースのOFAパスは、/u01/app/userです。userは、Oracleソフトウェア・インストールの所有者アカウントです。たとえば、次のコマンドを使用して、データベース・インストールの所有者アカウントoracleのOracleベースを作成します。

# mkdir -p  /u01/app/oracle
# chown -R oracle:oinstall /u01/app/oracle
# chmod -R 775 /u01/app/oracle

注意:
Oracle Grid Infrastructureホームを手動で作成する場合は、クラスタのOracle Grid Infrastructureホームを、グリッド・インストール所有者のOracleベースや、Oracle Databaseインストール所有者のOracleベースに作成しないでください。Oracleベース・ディレクトリにOracle Clusterwareインストールを作成すると、その後のOracleインストールが失敗します。
Oracle Grid Infrastructureホームは、以前のリリースの既存のOracle Clusterwareホームが共有された場所にある場合でも、サーバーのローカル・ホームに配置できます。

スタンドアロン・サーバー(Oracle Restart)用のOracle Grid InfrastructureのホームはOracleベースの下にあります。Oracle Restartの詳細は、使用しているプラットフォームのOracle Databaseインストレーション・ガイドを参照してください。

2.18 クラスタ名の要件

クラスタ名は長さ1文字以上15文字以下の英数字である必要があり、数字以外で始める必要があり、ハイフン(-)も使用できます。

標準インストールでは、指定したSCANはクラスタの名前でもあるため、SCAN名はクラスタ名の要件を満たしている必要があります。拡張インストールでは、SCANとクラスタ名はインストール時に別のフィールドに入力するため、クラスタ名要件はSCAN名には適用されません。

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

この章では、インストーラを起動してOracle ClusterwareとOracle Automatic Storage Management (Oracle ASM)をインストールする前、およびOracle Real Application Clusters(Oracle RAC)のインストールをクラスタへ追加する前に完了しておく必要がある、記憶域の構成作業について説明します。

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

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

- 共有ファイル・システムの記憶域の構成

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

- RAWディスクのサポート終了

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

この項では、クラスタ用Oracle Grid Infrastructureの格納用にサポートされている記憶域オプションについて説明します。内容は次のとおりです。

- Oracle ClusterwareおよびOracle RACの記憶域オプションの概要

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

- ストレージにOracle ASMディスク・グループを使用するときのガイドライン

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

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

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

関連項目:
動作保証されている記憶域オプションの最新情報については、My Oracle Supportの動作保証についてのサイトを参照してください。

https://support.oracle.com

3.1.1 Oracle ClusterwareおよびOracle RACの記憶域オプションの概要

Oracle Clusterwareファイルの格納には、次の2つの方法があります。

- Oracle Automatic Storage Management(Oracle ASM): Oracle Clusterwareファイル(OCRおよび投票ディスク)をOracle ASMのディスク・グループにインストールできます。
標準インストールとStandard EditionのOracle RACインストールにおいて、Oracle ASMは必須のデータベース記憶域オプションです。それは、Oracle ClusterwareとOracle Databaseファイル用の、統合された高性能のデータベース・ファイル・システムおよびディスク・マネージャです。データベース・ファイルのストライプ化およびミラー化を自動的に実行します。

ノード上のデータベース・インスタンスの数に関係なく、各ノードに許可されるOracle ASMインスタンスは1つのみです。

- サポートされている共有ファイル・システム: サポートされているファイル・システムには、次のものがあります。

- General Parallel File System(GPFS): 同時ファイル・アクセスを提供するAIXのクラスタ・ファイル・システム

- サポートされているクラスタ・ファイル・システム:データ・ファイルにクラスタ・ファイル・システムを使用する場合、Oracle Clusterware用のパーティションを作成する際に、データベース・ファイル用のパーティションを十分に大きく作成する必要があることに注意してください。

関連項目:
サポートされているクラスタ・ファイル・システムについては、My Oracle Supportの「動作保証」ページを参照してください。

- ネットワーク・ファイル・システム(NFS): データ・ファイルにNFSを使用する場合、Oracle Grid Infrastructure用のパーティションを作成する際に、データベース・ファイル用のパーティションを十分に大きく作成する必要があることに注意してください。NFSマウントは、ソフトウェア・バイナリ、Oracle Clusterwareファイル、データベース・ファイルで、それぞれ異なります。

注意:
OUIを使用して、Oracle ClusterwareやOracle DatabaseのファイルをRAWディスクにインストールすることはできなくなりました。

関連項目:
サポートされているファイル・システムと、NFSまたはNASファイラについては、My Oracle Supportを参照してください。

3.1.1.1 既存の9.2クラスタウェア・インストールでの定数ディスクの位置の制限

Oracle9i リリース9.2のOracle RAC環境をOracle Database 11g リリース2(11.2)にアップグレードする際、Oracle Clusterwareのインストール時に、1つ以上の投票ディスクを指定するよう求められます。Oracle Database 11g リリース1(11.1)の投票ディスクの位置を新しく指定する必要があります。この目的で、古いOracle9i リリース9.2の定数ディスクを再利用することはできません。

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

ディスクの記憶域オプションを決定したら、次の作業をここに示す順序どおりに実行する必要があります。

1: Oracle Clusterwareファイル用の共有記憶域の構成

- Oracle Clusterwareファイルにファイル・システム(ローカルまたはGPFS)を使用する場合: 「共有ファイル・システムの記憶域の構成」を参照してください。

2: Oracle Databaseファイルおよびリカバリ・ファイル用の記憶域の構成

- データベース・ファイルまたはリカバリ・ファイル記憶域にファイル・システムを使用する場合: 第3.2項「共有ファイル・システムの記憶域の構成」を参照してください。また、Oracle Clusterwareファイル用に作成するボリュームの他に、データベース・ファイルを格納するために十分なサイズのボリュームをさらに作成する必要があります。

関連項目:
第3.2.15項「共有ファイル・システムでのOracle Databaseファイル用のディレクトリの作成」

3.1.2 Oracle ACFSの一般情報

Oracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)は、汎用のファイル・システムです。このシステムにはOracle Databaseバイナリを配置できますが、Oracleデータ・ファイルやOracle Clusterwareファイルを配置することはできません。Oracle ACFSの次の点に注意してください。

- Oracle Restartは、rootベースのOracle Clusterwareリソースをサポートしません。このため、Oracle Restart構成でOracle ACFSを実行する場合は、次の制限が適用されます。

- Oracle ACFSドライバは手動でロードおよびアンロードする必要があります。

- Oracle ASMインスタンスの起動後、Oracle ACFSファイル・システムを手動でマウントおよびマウント解除する必要があります。

- 他の登録済Oracle ACFSファイル・システムとともに、Oracle ACFSマウント・レジストリにOracle ACFSデータベース・ホーム・ファイル・システムを配置できます。

- Oracle ClusterwareのバイナリおよびファイルをOracle ACFSに配置することはできません。

- Oracle DatabaseファイルをOracle ACFSに配置することはできません。

- Oracle ACFSは、他のファイルのための汎用ファイル・システムとなります。

注意:
AIXでは、Oracle ACFSに次のインストール要件があります。

- AIXのバージョンは、AIX 7.1またはPPC64のAIX 6.1に対してはAIX 6.1 TL4 SP2以上である必要があります。

- システムはRBACモードで実行している必要があります(デフォルト)。

- Oracle Grid Infrastructureのインストール所有者はローカル・ユーザーである必要があります。

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

すべてのインストールに対して、Oracle Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)およびOracle Real Application Clustersデータベース(Oracle RAC)に使用する記憶域オプションを選択する必要があります。また、インストール中に自動バックアップを有効にするには、リカバリ・ファイル(高速リカバリ領域)に使用する記憶域オプションを選択する必要があります。各ファイル・タイプに同一の記憶域を使用する必要はありません。

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

Oracle Clusterware投票ディスクは、クラスタ・ノードのステータスの監視に使用されます。Oracle Cluster Registry(OCR)ファイルには、クラスタに関する構成情報が格納されます。投票ディスクとOCRファイルは、ASMディスク・グループ、クラスタ・ファイル・システム、共有ネットワーク・ファイル・システムのいずれかに配置できます。記憶域は共有される必要があります。構成されている投票ディスクの大半(過半数)が利用できないノードは再起動されます。

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

次のガイドラインに従って、各ファイル・タイプで使用する記憶域オプションを選択します。

- 選択した記憶域オプションの要件がすべて満たされている場合、各ファイル・タイプでサポートされている記憶域オプションのいずれの組合せでも使用できます。

- データベース・ファイルおよびリカバリ・ファイルの記憶域オプションとして、Oracle ASMを選択することをお薦めします。

- Standard EditionのOracle RACインストールでは、データベース・ファイルまたはリカバリ・ファイルの記憶域オプションとして、Oracle ASMのみがサポートされています。

- Oracle RACでOracle ASMを使用するために新しいOracle ASMインスタンスを構成する場合は、システムが次の条件を満たしている必要があります。

- クラスタ用Oracle Grid Infrastructureのインストールの一部として、クラスタ内のすべてのノードにOracle ClusterwareおよびOracle ASM 11gリリース2(11.2)がインストールされている。

- クラスタ内のすべてのノードで既存のすべてのOracle ASMインスタンスが停止されている。

- RAWディスクは、構成済のディスクを使用している既存のインストールをアップグレードする場合のみ、サポートされます。新規インストールでのディスクの使用は、Oracle Automatic Storage Management Configuration Assistant(ASMCA)やOracle Universal Installer(OUI)ではサポートされていません。ただし、手動で構成を行えば、ソフトウェアでサポートされます。

関連項目:
既存のデータベースをアップグレードするための準備方法については、『Oracle Databaseアップグレード・ガイド』を参照してください。

- 外部ファイルの冗長性が適用される記憶域オプションがない場合は、3つ以上の投票ディスク領域を構成して、投票ディスクの冗長性を確保する必要があります。

3.1.4 ストレージにOracle ASMディスク・グループを使用するときのガイドライン

Oracle Grid Infrastructureのインストール時に、ディスク・グループを1つ作成できます。Oracle Grid Infrastructureのインストール後は、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および投票ディスク・ファイル、データベース・ファイル、リカバリ・ファイルはそのディスク・グループに格納されます。複数のディスク・グループを作成した場合は、ファイルを別のディスク・グループに格納することもできます。

注意:
既存ディスク・グループを管理するOracle ASMインスタンスは、Gridホームで実行する必要があります。

関連項目:

ディスク・グループの作成の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

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

Oracle Grid InfrastructureおよびOracle RACは、クラスタ対応のボリューム・マネージャのみをサポートします。これは、使用するボリューム・マネージャが特定のベンダー・クラスタ・ソリューションとともに提供されることを意味します。使用するボリュームがサポートされていることを確認するには、My Oracle Supportの「動作保証」タブで、関連するクラスタ・ソリューションがOracle RACで動作保証されているかどうかを確認します。My Oracle Supportは、次のURLで使用可能です。

https://support.oracle.com

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

次の表に、Oracle ClusterwareおよびOracle RACファイルを格納するために使用できる記憶域オプションを示します。

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

記憶域オプション

OCRおよび投票ディスク

Oracle Clusterwareバイナリ

Oracle RACバイナリ

Oracle Databaseファイル

Oracleリカバリ・ファイル

Oracle Automatic Storage Management

注意: ループバック・デバイスは、Oracle ASMでは使用できません。

可

不可

不可

可

可

Oracle Automatic Storage Management Cluster File System (Oracle ACFS)

不可

不可

可

不可

不可

General Parallel File System(GPFS)

- 注意: GPFSにASMファイルを配置することはできません。

- HACMPが使用されている場合、投票ディスクにはGPFSを使用しないことをお薦めします。

可

可

可

可

可

ローカル・ファイル・システム

不可

可

可

不可

不可

動作保証されているNASファイラ上のNFSファイル・システム

注意: 動作保証されているNASデバイスが必要です。HACMPが使用されている場合、投票ディスクにはNFSを使用しないことをお薦めします。

可

可

可

可

可

共有ディスク・パーティション(RAWディスク)(HACMPによって管理されるRAW論理ボリュームを含む)

OUIおよびASMCAでは非サポートだが、ソフトウェアでサポート。インストール後に追加または削除できます。

不可

不可

OUIおよびASMCAでは非サポートだが、ソフトウェアでサポート。インストール後に追加または削除できます。

不可

次のガイドラインに従って、記憶域オプションを選択します。

- 選択した記憶域オプションの要件がすべて満たされている場合、各ファイル・タイプでサポートされている記憶域オプションのいずれの組合せでも使用できます。

- Oracle Clusterwareファイルを格納するには、Oracle ASM 11gリリース2 (11.2)以上を保存できます。これには以前のリリースのOracle ASMは使用できません。

- 外部ファイルの冗長性が適用される記憶域オプションがない場合は、3つ以上の投票ディスクの場所、および3つ以上のOracle Cluster Registryの場所を構成して、冗長性を確保する必要があります。

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

ディスクの記憶域オプションを決定したら、共有記憶域の構成を行います。

- ファイル・システムを使用する場合は、第3.2項「共有ファイル・システムの記憶域の構成」を参照してください。

- Oracle Automatic Storage Managementを使用する場合は、第3.3項「Oracle Automatic Storage Managementの記憶域の構成」を参照してください。

3.2 共有ファイル・システムの記憶域の構成

インストーラでは、Oracle Cluster Registry(OCR)またはOracle Clusterware投票ディスク用のデフォルトの格納先は提供されません。ファイル・システムにこれらのファイルを作成する場合は、次の項を確認して、Oracle Clusterwareファイル用の記憶域要件を満たしておきます。

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

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

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

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

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

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

- HACMP Multinode Disk Heartbeat(MNDHB)の構成

- Oracle Clusterware用のRAW論理ボリュームの構成

- 新しいOracle Clusterwareボリューム・グループへのRAW論理ボリュームの構成

- データベース・ファイル用のボリューム・グループの作成

- Oracle Clusterware用のボリューム・グループの作成

- 他のクラスタ・ノードでのボリューム・グループのインポート

- すべてのクラスタ・ノードでのコンカレント・モードによるボリューム・グループのアクティブ化

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

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

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

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

Oracle Clusterware、Oracle ASM、Oracle RACに共有ファイル・システムを使用するには、ファイル・システムで次の要件を満たす必要があります。

- クラスタ・ファイル・システムを使用するには、サポートされているクラスタ・ファイル・システムである必要があります。サポートされているクラスタ・ファイル・システムのリストは、My Oracle Support(https://support.oracle.com)を参照してください。

- NFSファイル・システムを使用するには、サポートされているNASデバイス上にある必要があります。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のパーティションが使用されている場合は、これらのパーティションを300MB以上に拡張する必要があります。パーティションは使用せず、OCRおよび投票ディスクをQUORUMディスク・グループとしてマークされたディスク・グループに配置することをお薦めします。

すべてのストレージ製品は、サーバー・ベンダーとストレージ・ベンダーの両方でサポートされている必要があります。

表3-2と表3-3を使用して、共有ファイル・システムの最小サイズを決定します。

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

格納されるファイル・タイプ

ボリュームの数

ボリュームのサイズ

外部冗長で作成された投票ディスク

1

投票ディスク・ボリュームごとに300MB以上

外部冗長で作成されたOracle Cluster Registry(OCR)

1

OCRボリュームごとに300MB以上

Oracleソフトウェア提供の冗長で作成されたOracle Clusterwareファイル(OCRおよび投票ディスク)

3

OCRボリュームごとに300MB以上

投票ディスク・ボリュームごとに300MB以上

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

格納されるファイル・タイプ

ボリュームの数

ボリュームのサイズ

Oracle Databaseファイル

1

ボリュームごとに1.5GB以上

リカバリ・ファイル

注意: リカバリ・ファイルはデータベース・ファイルとは異なるボリュームに配置する必要があります。

1

ボリュームごとに2GB以上

表3-2および表3-3で、必要なボリューム・サイズの合計を加算して求めます。たとえば、標準冗長を使用してすべてのOracle Clusterwareファイルを共有ファイル・システムに格納するには、3つ以上のボリューム(OCRと2つのOCRミラー用に3つの別々のボリューム位置と、ボリュームごとに1つの投票ディスク)で2GB以上の記憶域が使用可能である必要があります。投票ディスクおよびOCRファイルを別々の物理ディスクに確実に配置するには、500MB以上の物理ディスクが3つ以上必要です。Oracle RACを追加して、データベース・ファイルにボリューム1つ、リカバリ・ファイルにボリューム1つを使用する場合、2つのボリュームで3.5GB以上、全ボリュームの合計で5.5GB以上の利用可能な記憶域が必要です。

注意:
+300Mなどのデバイス・サイズを指定して、fdiskで共有パーティション上にパーティションを作成すると、ディスクのシリンダ・ジオメトリに基づいて、作成した実際のデバイスが要求したサイズより小さくなる場合があります。これは、現在のfdiskにおける制限事項が原因です。Oracle ASMで使用するために割り当てたディスク全体をパーティション化することをお薦めします。

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

新規インストールの場合は、Oracle Automatic Storage Management (Oracle ASM)を使用して、投票ディスクおよびOCRファイルを格納することをお薦めします。

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

カーネルで管理されるNFSのかわりにDirect NFSクライアントを使用することもできます。この項では、Direct NFSクライアントについて次の内容で説明します。

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

- Direct NFSクライアントでのoranfstabファイルの使用

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

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

3.2.3.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オプションを使用してクライアントを有効化できます。または、第3.2.16項「NFSのDirect NFSクライアントのOracle Disk Management制御の無効化」の説明に従って、Direct NFSクライアントを無効にできます。

注意:
Oracle RACでサポートされているNFSサーバーを使用してください。サポート情報については、次のURLを参照してください。
https://support.oracle.com

3.2.3.2 Direct NFSクライアントでのoranfstabファイルの使用

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の構成の詳細は、第3.2.3.3項「Direct NFSクライアントを使用したNFSストレージ・デバイスのマウント」を参照してください。

マウント・ポイントがDirect NFSクライアントを使用して処理されているときでも、マウント・ポイントはカーネルNFSシステムによってマウントされる必要があります。

注意:
Direct NFSクライアントは、NFSサーバーの書込みサイズ値(wtmax)が32768未満の場合は機能しません。

3.2.3.3 Direct NFSクライアントを使用したNFSストレージ・デバイスのマウント

Direct NFSクライアントでは、/etc/mtabの構成に基づいてNFSストレージ・デバイスに対するマウント・ポイントの設定を判断します(これは、/etc/fstabファイルを構成することによって変更できます)。

Direct NFSクライアントでは、次の順序でマウント・エントリが検索されます。

1. $ORACLE_HOME/dbs/oranfstab

2. /etc/oranfstab

3. /etc/mtab

Direct NFSでは、最初に検出された一致エントリが使用されます。

Oracle Databaseのデフォルトの設定では、ダイレクトNFSは有効ではありません。Direct NFSクライアントを有効にするには、次の手順を実行します。

1. $ORACLE_HOME/rdbms/libディレクトリに移動します。

2. 次のコマンドを入力します。

make -f ins_rdbms.mk dnfs_on

注意:
インスタンスごとにアクティブなDirect NFSクライアントを1つのみ実装することができます。インスタンスでDirect NFSクライアントを使用すると、別のDirect NFSクライアントは実装できなくなります。

Oracle Databaseでoranfstabを使用して構成されたDirect NFSクライアントのマウント・ポイントを使用する場合は、まず、オペレーティング・システムのNFSマウント・ポイントを使用してoranfstab内のエントリをクロスチェックすることによってカーネルNFSマウントが検証されます。不一致が存在する場合、Direct NFSクライアントでは、情報メッセージを記録し、動作しません。

Oracle DatabaseでDirect NFSクライアントを使用してNFSサーバーを開くことができない場合は、プラットフォームのオペレーティング・システムのカーネルNFSクライアントが使用されます。この場合、カーネルNFSのマウント・オプションが第3.2.8項「Oracle Clusterware用のRAW論理ボリュームの構成」で説明するように設定されている必要があります。また、ダイレクトNFSクライアントがNFSサーバーに接続できなかったことを示す情報メッセージが、Oracleアラート・ファイルおよびトレース・ファイルに記録されます。

第3.1.6項「サポートされている記憶域オプション」に、Direct NFSクライアントでサポートされているファイル・タイプを示します。

Direct NFSクライアントによって処理されるNFSサーバーに存在するOracleファイルにも、オペレーティング・システムのカーネルNFSクライアントを介してアクセスできます。

関連項目:
Direct NFSクライアントまたはカーネルNFSで作成されたOracle Databaseデータ・ファイルの管理におけるガイドラインについては、『Oracle Database管理者ガイド』を参照してください。

3.2.3.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$ビューを使用します。

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

ネットワーク接続ストレージ(NAS)システムでは、データへのアクセスにNFSが使用されます。サポートされているNFSシステムにデータ・ファイルを格納できます。

インストールを開始する前に、NFSファイル・システムをマウントし、NFSマウントを介して使用できるようにする必要があります。NFSの構成およびマウントを実行する方法については、ベンダーのマニュアルを参照してください。

OracleソフトウェアおよびデータベースがNASデバイスに格納されている場合、そのパフォーマンスは、OracleサーバーとNASデバイス間のネットワーク接続のパフォーマンスによって左右されることに注意してください。

そのため、サーバーとNASデバイスの接続には、ギガビット・イーサネット以上のプライベートな専用ネットワーク接続を使用することをお薦めします。

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

GridホームまたはOracle RACホームにNFSを使用している場合、記憶域にNFSマウントを設定する必要があり、こうすることで、記憶域にマウントしているクライアントのrootが、匿名ユーザーにマップされるかわりにrootと見なされ、クライアント・サーバーのrootが、NFSファイル・システム上にroot所有のファイルを作成できるようにします。

NFSを使用している場合は、NFSバッファ・サイズ・パラメータrsizeおよびwsizeの値を32768に設定する必要があります。 バイナリのNFSマウント・オプションは次のとおりです。

rw,bg,hard,nointr,rsize=32768,wsize=32768,proto=tcp,vers=3,timeo=600

Oracle Clusterwareファイル(OCRおよび投票ディスク・ファイル)のNFSクライアント側のマウント・オプションは次のとおりです。

cio,rw,bg,hard,intr,rsize=32768,wsize=32768,tcp,noac,vers=3,timeo=600

Oracle Databaseデータ・ファイルのNFSクライアント側のマウント・オプションは次のとおりです。

cio,rw,bg,hard,nointr,rsize=32768,wsize=32768,proto=tcp,noac,vers=3,timeo=600

各ノードの/etc/filesystemsファイルを次のエントリで更新します。

/NFS_mount:
dev = "/vol/gridhome"
vfs = nfs
nodename = /vol/gridhome
mount = true
options = rw,bg,hard,nointr,rsize=32768,wsize=32768,proto=tcp,vers=3,timeo=600
account = false
/NFS_mount:
dev = "/vol/CWfiles"
vfs = nfs
nodename = /vol/CWfiles
mount = true
options = cio,rw,bg,hard,intr,rsize=32768,wsize=32768,tcp,noac,vers=3,timeo=600
account = false
/NFS_mount:
dev = "/vol/datafiles"
vfs = nfs
nodename = /u02/app/oracle/data
mount = true
options = cio,rw,bg,hard,nointr,rsize=32768,wsize=32768,proto=tcp,noac,vers=3,timeo=600
account = false

Oracleソフトウェアのバイナリ、Oracle Clusterwareファイル(OCRおよび投票ディスク)、データ・ファイルでマウント・ポイント・オプションが異なることに注意してください。

バイナリ専用のマウント・ポイントを作成する場合は、バイナリ・マウント・ポイントに次の行を入力します。

nfs_server:/vol/grid /u01/oracle/grid nfs -yes
rw,bg,hard,nointr,rsize=32768,wsize=32768,proto=tcp,vers=3,timeo=600

NFSでは、サーバー側でno_root_squashを有効にすることで、記憶域に書込みを行うクライアントにrootアクセス権を取得できます。たとえば、ドメインmycluster.example.comのノードnode1、node2、node3について、パス/vol/gridのOracle Clusterwareファイル記憶域を設定するには、次のような行を/etc/exportsファイルに追加します。

/vol/grid/ node1.mycluster.example.com(rw,no_root_squash)
node2.mycluster.example.com(rw,no_root_squash) node3.mycluster.example.com
(rw,no_root_squash)

ドメインまたはDNSがセキュアで、許可されていないシステムはそのIPアドレスを取得できない場合には、特定のクラスタ・メンバー・ノードを指定するのではなく、ドメインごとにrootアクセス権を付与します。

次に例を示します。

/vol/grid/ *.mycluster.example.com(rw,no_root_squash)

この構文を使用すると、NFSサーバーの再構成を行うことなくノードの追加や削除を行えます。セキュアなDNSまたはドメインを使用して、そのドメインを利用するクラスタ・メンバー・ノードにrootアクセス権を付与することをお薦めします。

グリッド・ネーミング・サービス(GNS)を使用する場合、クラスタ内でGNSによる解決で割り当てられるサブドメインは、セキュアなドメインです。適切に署名されたGPnP(グリッドのプラグ・アンド・プレイ)のプロファイルがないサーバーは、クラスタに参加できません。そのため、許可されていないシステムは、GNSサブドメイン内の名前を取得または使用できません。

注意:
ドメイン単位でrootアクセス権を付与すると、システムへの不正アクセスに利用される場合があります。システム管理者は、no_root_squashの使用に付随するリスクについて、オペレーティング・システムのドキュメントを参照してください。

/etc/exportsを変更したら、次のコマンドを使用してファイル・システムのマウントをリロードします。

# /usr/sbin/exportfs -avr

関連項目:
マウント・オプションの最新情報については、My Oracle Supportのbulletin 359515.1「Mount Options for Oracle Files When Used with NAS Devices」を参照してください。次のURLから入手可能です。
https://support.oracle.com

注意:
マウント・オプションの詳細は、ストレージ・ベンダーのマニュアルを参照してください。

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

Direct NFSクライアントを有効にするには、次の手順を実行します。

1. Direct NFSクライアントを使用してアクセスする各NFSサーバーの次の属性を使用してoranfstabファイルを作成します。

- サーバー: NFSサーバー名。

- ローカル: IPアドレスまたは名前のいずれかで指定された、データベース・ホスト上の最大4つのパス。データベース・ホスト上でifconfigコマンドを使用して表示できます。

- パス: IPアドレスまたは名前のいずれかで指定された、NFSサーバーへの最大4つのネットワーク・パス。NFSサーバー上でifconfigコマンドを使用して表示できます。

- エクスポート: NFSサーバーからエクスポートされたパス。

- マウント: エクスポートされたボリュームに対応する、ローカル・マウント・ポイント。

- マウント・タイムアウト: Direct NFSクライアントがマウント成功を待機し、タイムアウトするまでの時間(秒)を指定します。このパラメータはオプションです。デフォルトのタイムアウトは10分(600)です。

- ルーティング不可: 送信メッセージをオペレーティング・システムでルーティングせず、そのかわりに、バインドされたIPアドレスを使用して送信するよう指定します。

この後の例では、oranfstabのNFSサーバー・エントリを3種類示しています。1つのoranfstabに、複数のNFSサーバー・エントリを含めることができます。

例3-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

例3-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

例3-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. デフォルトでは、Direct NFSクライアントは無効な状態でインストールされます。Direct NFSクライアントを有効にするには、各ノードで次の手順を完了します。共有Gridホームをクラスタに使用する場合は、共有Gridホームで次の手順を完了します。

1. Oracle Grid Infrastructureインストール所有者としてログインします。

2. Grid_home/rdbms/libディレクトリに移動します。

3. 次のコマンドを入力します。

$ make -f ins_rdbms.mk dnfs_on

3.2.7 HACMP Multinode Disk Heartbeat(MNDHB)の構成

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

関連項目:
HACMPのデプロイメントおよび動作保証についての追加情報は、My Oracle Supportを参照してください。

- Oracle ClusterwareでHACMPを使用するための要件の概要

- Oracle Clusterwareに対するHACMPおよびMDNDHBのデプロイ

- 既存のOracle ClusterwareおよびHACMPインストールのアップグレード

3.2.7.1 Oracle ClusterwareでHACMPを使用するための要件の概要

Oracle Clusterwareの投票ディスクごとに、1つのMulti-node Disk Heartbeat(MNDHB)ネットワークを定義する必要があります。MNDHBと投票ディスクの各ペアは、他のペアとは別の、単一のハード・ディスクに配置する必要があります。また、拡張コンカレント・ボリューム・グループにあるMNDHBネットワークの定数に対してアクセスが失われるとノードが停止されるようにMNDHBを構成する必要があります。

クラスタができるだけ分断されないように、複数のIPネットワークと1つ以上の非IPネットワークを使用してHACMPをデプロイすることをIBMは薦めています。非IPネットワークは、RS232またはディスク・ハートビートを使用して実装できます。データベースの記憶域にOracle RACおよびHACMP拡張コンカレント・リソース(拡張されたコンカレント論理ボリューム)を使用するシステムの場合は、MNDHBネットワークを構成する必要があります。

Oracle Clusterwareをインストールする前に、HACMPをインストールおよび構成し、稼働させる必要があります。Oracle RAC構成では、Oracle RACネットワーク・インタフェース(パブリック、VIPまたはプライベート)上のIPフェイルオーバーにHACMPを使用しないでください。Oracle RACのVIPフェイルオーバーは、Oracle Clusterwareによって管理されるため、これらのネットワーク・インタフェースは、HACMP IPフェイルオーバーを使用する構成にはしないでください。Oracle RACネットワーク・インタフェースは、個々のノードとOracle RACインスタンスに割り当てられます。HACMPが、異なるインタフェースでIPアドレスを再構成したり、異なるノードでアドレスをフェイルオーバーすると、Oracle Clusterwareで問題が発生する場合があります。Oracle RACノード上のIPアドレスのフェイルオーバーにHACMPを使用できるのは、Oracle RACがこれらのアドレスを使用しない場合のみです。

3.2.7.2 Oracle Clusterwareに対するHACMPおよびMDNDHBのデプロイ

次の作業を完了します。イタリック体の部分は、ご使用のシステムにあわせて適切な応答に読み換えてください。または、示された操作を実行し、必要に応じて適切な応答を入力してください。

1. HACMPを起動します。

2. 次のコマンドを入力して、HACMPのclcomdESデーモンが実行中であることを確認します。

# lssrc -s clcomdES

デーモンが実行されていない場合は、次のコマンドを使用して起動します。

# startsrc –s clcomdES

3. ご使用のHACMPとAIXのバージョンが、第2.7項「ソフトウェア要件の特定」に示されているシステム要件を満たしていることを確認します。

4. HACMPクラスタを作成し、Oracle Clusterwareノードを追加します。次に例を示します。

# smitty cm_add_change_show_an_hacmp_cluster.dialog
* Cluster Name [mycluster]

5. 各Oracle Clusterwareノードに、HACMPクラスタ・ノードを作成します。次に例を示します。

# smitty cm_add_a_node_to_the_hacmp_cluster_dialog
* Node Name [mycluster_node1]
Communication Path to Node []

6. HACMPイーサネット・ハートビート・ネットワークを作成します。HACMP構成には、ネットワーク定義が必要です。ネットワークでIPアドレスが引き継がれるように「No」を選択します。これらのネットワークはOracle Clusterwareによって使用されるためです。
2つ以上のネットワーク定義を作成します。1つは、Oracleのパブリック・インタフェース用、もう1つはOracleのプライベート(クラスタ・インターコネクト)・ネットワーク用です。必要に応じて、さらにイーサネット・ハートビート・ネットワークを追加できます。

次に例を示します。

# smitty cm_add_a_network_to_the_hacmp_cluster_select
- select ether network
* Network Name [my_network_name]
* Network Type ether
* Netmask [my.network.netmask.here]
* Enable IP Address Takeover via IP Aliases [No]
IP Address Offset for Heart beating over IP Aliases []

7. 前述の手順で追加したネットワークごとに、そのネットワークに関連付けられた各Oracle ClusterwareノードのすべてのIP名(各Oracle Clusterwareノードのパブリック、プライベートおよびVIP名)を定義します。次に例を示します。

# smitty cm_add_communication_interfaces_devices.select
- select: Add Pre-defined Communication Interfaces and Devices / Communication Interfaces / desired network
* IP Label/Address [node_ip_address]
* Network Type ether
* Network Name some_network_name
* Node Name [my_node_name]
Network Interface []

8. 拡張コンカレント・ボリューム・グループのリソースに対して、次のオプションを使用してHACMPリソース・グループを作成します。

# smitty config_resource_group.dialog.custom
* Resource Group Name [my_resource_group_name]
* Participating Nodes (Default Node Priority) [mynode1,mynode2,mynode3]
Startup Policy Online On All Available Nodes
Fallover Policy Bring Offline (On Error Node Only)
Fallback Policy Never Fallback

9. コマンド(smitty mkvg)またはコマンドラインを使用して、AIXの拡張コンカレント・ボリューム・グループ(Big VGまたはScalable VG)を作成します。ボリューム・グループには、各投票ディスク用に1つ以上のハード・ディスクが含まれている必要があります。3つ以上の投票ディスクを構成する必要があります。
次の例のdefaultは、デフォルトの応答をそのまま使用することを示しています。

# smitty _mksvg
VOLUME GROUP name [my_vg_name] PP SIZE in MB
* PHYSICAL VOLUME names [mydisk1,mydisk2,mydisk3]
Force the creation of a volume group? no
Activate volume group AUTOMATICALLY no at system restart?
Volume Group MAJOR NUMBER []
Create VG Concurrent Capable? enhanced concurrent
Max PPs per VG in kilobytes default
Max Logical Volumes default

10. 「Change/Show Resources for a Resource Group (standard)」で、前述の手順で追加したリソース・グループに対するコンカレント・ボリューム・グループを追加します。
次に例を示します。

# smitty cm_change_show_resources_std_resource_group_menu_dmn.select
- select_resource_group_from_step_6
Resource Group Name shared_storage
Participating Nodes (Default Node Priority) mynode1,mynode2,mynode3
Startup Policy Online On All Available Nodes
Fallover Policy Bring Offline (On Error Node Only)
Fallback Policy Never Fallback
Concurrent Volume Groups [enter_VG_from_step_7]
Use forced varyon of volume groups, if necessary false
Application Servers []

11. 次のコマンドを使用して、Oracle Clusterwareの投票ディスクごとに1つのMNDHBネットワークが定義されていることを確認します。MNDHBと投票ディスクの各ペアは、他のペアとは別の、単一のハード・ディスクに配置する必要があります。MNDHBネットワークと投票ディスクは、HACMPが管理する拡張コンカレント論理ボリュームの共有論理ボリュームに、拡張コンカレント・リソースとして存在します。投票ディスクの論理ボリューム(LV)を配置するために手順6で作成したボリューム・グループにあるハード・ディスクごとにMNDHB論理ボリュームを作成します。

# smitty cl_add_mndhb_lv
- select_resource_group_defined_in_step_6
* Physical Volume name enter F4, then select a hard disk
Logical Volume Name []
Logical Volume Label []
Volume Group name ccvg
Resource Group Name shared_storage
Network Name [n]

注意:
Oracle Clusterwareの投票ディスクに使用する論理ボリュームを定義する際は、同じディスクに定義する必要があります(各ディスクに1つ)。このMNDHB論理ボリュームの手順と同様です。

12. 拡張コンカレント・ボリューム・グループにあるMNDHBネットワークの定数に対してアクセスが失われるとノードが停止されるようにMNDHBを構成します。次に例を示します。

# smitty cl_set_mndhb_response
- select_the_VG_created_in_step_7
On loss of access Halt the node
Optional notification method []
Volume Group ccvg

13. HACMP構成を確認し、同期させます。次に例を示します。

# smitty cm_initialization_and_standard_config_menu_dmn
- select "Verify and Synchronize HACMP Configuration"

「Would you like to import shared VG: ccvg, in resource group my_resource_group onto node: mynode to node: racha702 [Yes / No]:」というプロンプトが表示されたら「Yes」と入力します。

14. /usr/es/sbin/cluster/etc/rhostsファイルにHACMPクラスタ・ノードのIP名を追加します。

3.2.7.3 既存のOracle ClusterwareおよびHACMPインストールのアップグレード

次の手順を実行します。

1. すべてのデータベースをバックアップした後、Oracle Cluster Registry(OCR)をバックアップします。

2. すべてのノードですべてのOracle RACデータベース、すべてのノード・アプリケーションおよびOracle Clusterwareを停止します。

3. 次のコマンドを入力し、ノードを再起動したときにOracle Clusterwareを無効にします。

# crsctl disable crs

4. すべてのノードでHACMPを停止します。

5. HACMP APAR IZ01809をインストールします。APARに添付されているREADMEの指示に従います。

6. 既存の投票ディスク論理ボリュームが別々のハード・ディスクにあり、かつこれらの各ディスクに十分な領域(MNDHB論理ボリューム用に256MB以上)があるかどうかを確認します。ある場合は、各ハード・ディスクにMNDHB論理ボリュームを作成します。ない場合は、次のコマンドを使用して、別々のハード・ディスクにMNDHB論理ボリュームと投票ディスクを新しく作成します。イタリック体の部分は、ご使用のシステムに合わせて適切に読み換えてください。

# smitty cl_add_mndhb_lv
- Select_resource_group
* Physical Volume name Enter F4, then select disk for the MNDHB and Voting Disk pair
Logical Volume Name []
Logical Volume Label []
Volume Group name ccvg
Resource Group Name shared_storage
Network Name [net_diskhbmulti_01]

7. HACMP構成を確認し、同期させます。

8. すべてのノードでHACMPを起動します。

9. 手順5で投票ディスク用に論理ボリュームを新しく追加した場合は、既存の投票ディスクを新しいディスクに置き換えます。

10. 次のコマンドを入力して、Oracle Clusterwareを再度有効にします。

# crsctl enable crs

11. すべてのノードのOracle Clusterwareを起動し、すべてのリソースが適切に起動することを確認します。

3.2.8 Oracle Clusterware用のRAW論理ボリュームの構成

注意:
Oracle ClusterwareにRAW論理ボリュームを使用するには、すべてのクラスタ・ノードにHACMPをインストールおよび構成する必要があります。

この項では、Oracle Clusterwareおよびデータベース・ファイル記憶域用にRAW論理ボリュームを構成する方法について説明します。この項では、両方のファイル・タイプに必要な論理ボリュームを含む新しいボリューム・グループを作成する手順を説明します。

続行する前に、今回のリリースのOracle RACでボリューム・グループを使用する場合の重要な情報が含まれている次のガイドラインを確認してください。

- Oracle Clusterwareには、コンカレント対応のボリューム・グループを使用する必要があります。

- Oracle Clusterwareファイルには、560MB未満のディスク領域(外部冗長を使用)が必要です。ボリューム・グループのディスク領域を効率的に使用するには、Oracle Clusterwareファイルおよびデータベース・ファイルの両方で、論理ボリュームに同じボリューム・グループを使用することをお薦めします。

- RAW論理ボリュームを使用する既存のOracle9iリリース2のOracle RACインストールをアップグレードする場合は、OCR用の既存のSRVM構成リポジトリ論理ボリュームを使用し、同じボリューム・グループにOracle Clusterware投票ディスク用の新しい論理ボリュームを作成できます。ただし、Oracle Clusterwareをインストールする前に、このボリューム・グループをアクティブ化するHACMPのコンカレント・リソース・グループからこのボリューム・グループを削除しておく必要があります。

関連項目:
コンカレント・リソース・グループからのボリューム・グループの削除については、HACMPのドキュメントを参照してください。

注意:
データベースをアップグレードする場合は、SYSAUX表領域用に新しい論理ボリュームも作成する必要があります。Oracle Clusterware投票ディスクおよびSYSAUX論理ボリュームの要件の詳細は、「新しいOracle Clusterwareボリューム・グループへのRAW論理ボリュームの構成」を参照してください。

- データベース・ファイルのみを含む(Oracle Clusterwareファイルは含まない)新しいボリューム・グループまたは既存のボリューム・グループをアクティブ化するには、HACMPのコンカレント・リソース・グループを使用する必要があります。

関連項目:
新規または既存のコンカレント・リソース・グループへのボリューム・グループの追加については、HACMPのドキュメントを参照してください。

- Oracle Clusterwareに使用するすべてのボリューム・グループは、インストールを開始する前に、コンカレント・モードでアクティブ化する必要があります。

- この項では、基本的なボリューム・グループとボリュームを作成する手順について説明します。ミラー化を使用するなど、より複雑なボリュームを構成する場合は、この項とともにHACMPのドキュメントも参照してください。

3.2.9 新しいOracle Clusterwareボリューム・グループへのRAW論理ボリュームの構成

新しいOracle Clusterwareボリューム・グループに必要なRAW論理ボリュームを作成するには、次の手順を実行します。

1. 作成する必要がある論理ボリュームを確認します。

2. 必要に応じて、コマンドsmit mklvを使用し、RAW論理ボリュームを作成することもできます。
次の例は、物理パーティション・サイズが114MB(1792/7 = 256)の場合に、SYSAUX表領域用の論理ボリュームをocrボリューム・グループに作成するために使用するコマンドを示しています。

# /usr/sbin/mklv -y test_sysaux_raw_1792m -T O -w n -s n -r n ocr 7

3. 次のように、作成した論理ボリュームに関連付けられるキャラクタ・デバイス・ファイルの所有者、グループおよび権限を変更します。

注意:
Oracle Cluster Registryに関連付けられるデバイス・ファイルは、rootが所有する必要があります。その他のすべてのデバイス・ファイルは、Oracleソフトウェア所有者ユーザー(oracle)が所有する必要があります。

# chown oracle:dba /dev/rora_vote_raw_280m
# chmod 660 /dev/rora_vote_raw_280m
# chown root:oinstall /dev/rora_ocr_raw_280m
# chmod 640 /dev/rora_ocr_raw_280m

3.2.10 データベース・ファイル用のボリューム・グループの作成

Oracleデータベース・ファイル用のボリューム・グループを作成するには、次の手順を実行します。

1. 必要に応じて、使用する共有ディスクをインストールします。

2. すべてのノードで次のコマンドを入力し、ディスクが使用可能であることを確認します。

# /usr/sbin/lsdev -Cc disk

このコマンドの出力結果は、次のようになります。

hdisk0 Available 1A-09-00-8,0  16 Bit LVD SCSI Disk Drive
hdisk1 Available 1A-09-00-9,0  16 Bit LVD SCSI Disk Drive
hdisk2 Available 17-08-L       SSA Logical Disk Drive

3. ディスクが使用可能として表示されないノードがある場合は、次のコマンドを入力して、新しいディスクを構成します。

# /usr/sbin/cfgmgr

4. 任意のノードで次のコマンドを入力し、デバイス名と、各ディスクの関連ボリューム・グループを確認します。

# /usr/sbin/lspv

このコマンドの出力結果は、次のようになります。

hdisk0     0000078752249812   rootvg
hdisk1     none               none
hdisk4     00034b6fd4ac1d71   ccvg1

このコマンドは、各ディスクについて次の内容を示します。

- ディスク・デバイス名

- 16文字の物理ボリュームID(PVID)(ディスクにある場合)またはnone

- ディスクが属しているボリューム・グループまたはnone

使用するディスクにPVIDがあっても、既存のボリューム・グループには属していない必要があります。

5. ボリューム・グループとして使用するディスクにPVIDがない場合は、次のコマンドを入力してディスクに割り当てます。

# /usr/sbin/chdev -l hdiskn -a pv=yes

6. クラスタの各ノードで次のコマンドを入力して、使用されているデバイスのメジャー番号を確認します。

# ls -la /dev | more

このコマンドの出力結果に、すべての構成済デバイスの情報が次のように表示されます。

crw-rw----   1 root     system    45,  0 Jul 19 11:56 vg1

この例では、45はvg1ボリューム・グループ・デバイスのメジャー番号です。

7. クラスタ内のすべてのノードで使用されていない適切なメジャー番号を特定します。

8. 次のコマンドを入力するか、またはSMIT(smit mkvg)を使用して、ボリューム・グループを作成します。

# /usr/sbin/mkvg -y VGname -B -s PPsize -V majornum -n \
-C PhysicalVolumes

9. 次の表に、この例で使用されるオプションと変数を示します。これらのオプションの詳細は、mkvgのマニュアル・ページを参照してください。

コマンド・オプション

SMITフィールド

サンプル値および説明

-y VGname

VOLUME GROUP name

oracle_vg1

ボリューム・グループの名前を指定します。指定する名前は、ここに示すような一般的な名前や、作成するデータベースの名前にすることができます。

-y VGname

VOLUME GROUP name

oracle_vg1

ボリューム・グループの名前を指定します。ここに示すような一般的な名前を指定できます。また、データベース・ボリューム・グループの場合は、作成するデータベースの名前を指定できます。

-B

Create a big VG format Volume Group

ビッグVGフォーマットのボリューム・グループを作成する場合に、このオプションを指定します。
注意: SMITを使用している場合、このフィールドは「yes」を選択します。

-s PPsize

Physical partition SIZE in megabytes

32

データベースの物理パーティションのサイズを指定します。ここに示すサンプル値では、最大サイズ32GB(32MB * 1016)のディスクを含めることができます。

-V Majornum

Volume Group MAJOR NUMBER

46

手順7で特定したボリューム・グループのデバイスのメジャー番号を指定します。

-n

Activate volume group AUTOMATICALLY at system restart

ボリューム・グループがシステムの再起動時にアクティブ化されないようにする場合に、このオプションを選択します。
注意: SMITを使用している場合、このフィールドは「no」を選択します。

-C

Create VG Concurrent Capable

コンカレント対応のボリューム・グループを作成する場合に、このオプションを指定します。
注意: SMITを使用している場合、このフィールドは「yes」を選択します。

PhysicalVolumes

PHYSICAL VOLUME names

hdisk3 hdisk4

ボリューム・グループに追加するディスクのデバイス名を指定します。

10. 次のコマンドを入力して、作成したボリューム・グループを有効にします。

# /usr/sbin/varyonvg VGname

3.2.11 Oracle Clusterware用のボリューム・グループの作成

Oracle Clusterwareファイル用のボリューム・グループを作成するには、次の手順を実行します。

1. 必要に応じて、使用する共有ディスクをインストールします。

2. すべてのノードで次のコマンドを入力し、ディスクが使用可能であることを確認します。

# /usr/sbin/lsdev -Cc disk

このコマンドの出力結果は、次のようになります。

hdisk0 Available 1A-09-00-8,0  16 Bit LVD SCSI Disk Drive
hdisk1 Available 1A-09-00-9,0  16 Bit LVD SCSI Disk Drive
hdisk2 Available 17-08-L       SSA Logical Disk Drive

3. ディスクが使用可能として表示されないノードがある場合は、次のコマンドを入力して、新しいディスクを構成します。

# /usr/sbin/cfgmgr

4. 任意のノードで次のコマンドを入力し、デバイス名と、各ディスクの関連ボリューム・グループを確認します。

# /usr/sbin/lspv

このコマンドの出力結果は、次のようになります。

hdisk0     0000078752249812   rootvg
hdisk1     none               none
hdisk4     00034b6fd4ac1d71   ccvg1

このコマンドは、各ディスクについて次の内容を示します。

- ディスク・デバイス名

- 16文字の物理ボリュームID(PVID)(ディスクにある場合)またはnone

- ディスクが属しているボリューム・グループまたはnone

使用するディスクにPVIDがあっても、既存のボリューム・グループには属していない必要があります。

5. ボリューム・グループとして使用するディスクにPVIDがない場合は、次のコマンドを入力してディスクに割り当てます。

# /usr/sbin/chdev -l hdiskn -a pv=yes

6. クラスタの各ノードで次のコマンドを入力して、使用されているデバイスのメジャー番号を確認します。

# ls -la /dev | more

このコマンドの出力結果に、すべての構成済デバイスの情報が次のように表示されます。

crw-rw----   1 root     system    45,  0 Jul 19 11:56 vg1

この例では、45はvg1ボリューム・グループ・デバイスのメジャー番号です。

7. クラスタ内のすべてのノードで使用されていない適切なメジャー番号を特定します。

8. 次のコマンドを入力するか、またはSMIT(smit mkvg)を使用して、ボリューム・グループを作成します。

# /usr/sbin/mkvg -y VGname -B -s PPsize -V majornum -n \
-C PhysicalVolumes

9. 次の表に、この例で使用されるオプションと変数を示します。これらのオプションの詳細は、mkvgのマニュアル・ページを参照してください。

コマンド・オプション

SMITフィールド

サンプル値および説明

-y VGname

VOLUME GROUP name

oracle_vg1

ボリューム・グループの名前を指定します。指定する名前は、ここに示すような一般的な名前や、作成するデータベースの名前にすることができます。

-y VGname

VOLUME GROUP name

oracle_vg1

ボリューム・グループの名前を指定します。ここに示すような一般的な名前を指定できます。また、データベース・ボリューム・グループの場合は、作成するデータベースの名前を指定できます。

-B

Create a big VG format Volume Group

ビッグVGフォーマットのボリューム・グループを作成する場合に、このオプションを指定します。
注意: SMITを使用している場合、このフィールドは「yes」を選択します。

-s PPsize

Physical partition SIZE in megabytes

32

データベースの物理パーティションのサイズを指定します。ここに示すサンプル値では、最大サイズ32GB(32MB * 1016)のディスクを含めることができます。

-V Majornum

Volume Group MAJOR NUMBER

46

手順7で特定したボリューム・グループのデバイスのメジャー番号を指定します。

-n

Activate volume group AUTOMATICALLY at system restart

ボリューム・グループがシステムの再起動時にアクティブ化されないようにする場合に、このオプションを選択します。
注意: SMITを使用している場合、このフィールドは「no」を選択します。

-C

Create VG Concurrent Capable

コンカレント対応のボリューム・グループを作成する場合に、このオプションを指定します。
注意: SMITを使用している場合、このフィールドは「yes」を選択します。

PhysicalVolumes

PHYSICAL VOLUME names

hdisk3 hdisk4

ボリューム・グループに追加するディスクのデバイス名を指定します。

10. 次のコマンドを入力して、作成したボリューム・グループを有効にします。

# /usr/sbin/varyonvg VGname

3.2.12 他のクラスタ・ノードでのボリューム・グループのインポート

ボリューム・グループをクラスタ内のすべてのノードで使用可能にするには、次の手順に従って、各ノードにインポートする必要があります。

1. 物理ボリューム名は他のノードでは異なる場合があるため、次のコマンドを入力して、ボリューム・グループが使用する物理ボリュームのPVIDを確認します。

# /usr/sbin/lspv

2. ボリューム・グループが使用する物理デバイスのPVIDを書き留めます。

3. ボリューム・グループを作成したノードで次のコマンドを入力し、使用するボリューム・グループを無効にします。

# /usr/sbin/varyoffvg VGname

4. 各クラスタ・ノードで、次の手順を実行します。

1. 次のコマンドを入力して、前述の手順で書き留めたPVIDに関連付けられている物理ボリューム名を確認します。

# /usr/sbin/lspv

2. クラスタの各ノードで、次のコマンドを入力し、ボリューム・グループの定義をインポートします。

# /usr/sbin/importvg -y VGname -V MajorNumber PhysicalVolume

この例では、MajorNumberはボリューム・グループのデバイスのメジャー番号、PhysicalVolumeはボリューム・グループにある物理ボリュームのうちの1つの名前です。

たとえば、hdisk3およびhdisk4物理ボリューム上のデバイスのメジャー番号45を持つoracle_vg1ボリューム・グループの定義をインポートする場合は、次のコマンドを入力します。

# /usr/sbin/importvg -y oracle_vg1 -V 45 hdisk3

3. 次のように、作成した論理ボリュームに関連付けられるキャラクタ・デバイス・ファイルの所有者、グループおよび権限を変更します。

# chown oracle:dba /dev/rora_vote_raw_280m
# chmod 660 /dev/rora_vote_raw_280m
# chown root:oinstall /dev/rora_ocr_raw_280m
# chmod 640 /dev/rora_ocr_raw_280m

4. 次のコマンドを入力して、ノードの起動時に、オペレーティング・システムによってボリューム・グループがアクティブ化されないことを確認します。

# /usr/sbin/chvg -a n VGname

3.2.13 べてのクラスタ・ノードでのコンカレント・モードによるボリューム・グループのアクティブ化

すべてのクラスタ・ノードで、ボリューム・グループをコンカレント・モードでアクティブ化するには、各ノードで次のコマンドを入力します。

# /usr/sbin/varyonvg -c VGname

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

次の手順に従って、Oracle Clusterwareファイル用のディレクトリを作成します。また、Oracle Databaseおよびリカバリ・ファイル用に共有ファイル・システムを構成することもできます。

注意:
NFSまたはGPFS記憶域の場合、別々のファイル・システムにあるOracle ClusterwareファイルをOracleベース・ディレクトリに格納する場合にのみ、この手順を実行する必要があります。

Oracleベース・ディレクトリとは別のファイル・システムにOracle Clusterwareファイル用のディレクトリを作成するには、次の手順を実行します。

1. 必要に応じて、各ノードで使用する共有ファイル・システムを構成し、マウントします。

注意:
ファイル・システムに使用するマウント・ポイントは、すべてのノードで同一である必要があります。ノードの再起動時、自動的にマウントされるように、ファイル・システムが構成されていることを確認してください。

2. df -kコマンドを使用して、マウントされた各ファイル・システムの空きディスク領域を確認します。

3. 表示された情報から、使用するファイル・システムを特定します。

ファイル・タイプ

ファイル・システムの要件

Oracle Clusterwareファイル

600MB以上の空きディスク領域(外部冗長を使用、OCRと投票ディスクを1つずつ)があるファイル・システムを選択します。

データベース・ファイル

次のいずれかを選択します。

- 1.5GB以上の空き領域を持つ単一のファイル・システム

- 合計1.5GB以上の空き領域を持つ複数のファイル・システム

リカバリ・ファイル

2GB以上の空き領域を持つ単一のファイル・システムを選択します。

複数のファイル・タイプに対して同じファイル・システムを使用している場合は、各タイプに対するディスク領域要件を追加して、ディスク領域要件の合計を判断します。

4. 選択したファイル・システムに対するマウント・ポイント・ディレクトリの名前を書き留めます。

5. インストールを実行しているユーザーが、Oracle Clusterwareをインストールする記憶域にディレクトリを作成する権限を所有している場合は、OUIによってOracle Clusterwareファイル・ディレクトリが作成されます。

1. 必要に応じて、各ノードで使用する共有ファイル・システムを構成し、マウントします。

注意:
ファイル・システムに使用するマウント・ポイントは、すべてのノードで同一である必要があります。ノードの再起動時、自動的にマウントされるように、ファイル・システムが構成されていることを確認してください。

2. dfコマンドを使用して、マウントされた各ファイル・システムの空きディスク領域を確認します。

3. 表示された情報から、使用するファイル・システムを特定します。600MB以上の空きディスク領域(外部冗長を使用、OCRと投票ディスクを1つずつ)があるファイル・システムを選択します。
複数のファイル・タイプに対して同じファイル・システムを使用している場合は、各タイプに対するディスク領域要件を追加して、ディスク領域要件の合計を判断します。

注意:
GPFSを使用している場合は、すべての用途に同じファイルシステムを使用できます。Oracleホーム・ディレクトリとしての使用や、データ・ファイルやログの格納などです。パフォーマンスを最適にするために、GPFSのブロック・サイズは大きくする必要があります(通常は512KB以上)。GPFSはスケーラビリティに対応するように設計されており、単一のGPFSファイル・システムに格納できるデータ量であれば、複数のGPFSファイル・システムを作成する必要はありません。

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以外のアカウントでは書込みできないようにする必要があります。

それぞれのマウント・ポイント・ディレクトリにサブディレクトリを作成し、適切な所有者、グループおよび権限を設定すると、GPFSの構成は完了です。

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

Oracle Databaseの共有ファイル・システム用のディレクトリ、および(Oracle RACデータベース用などの)リカバリ・ファイル用のディレクトリを作成するには、次の手順を実行します。

1. 必要に応じて、各ノードで共有ファイル・システムを構成し、マウントします。

注意:
ファイル・システムに使用するマウント・ポイントは、すべてのノードで同一である必要があります。ノードの再起動時、自動的にマウントされるように、ファイル・システムが構成されていることを確認してください。

2. df -kコマンドを使用して、マウントされた各ファイル・システムの空きディスク領域を確認します。

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の構成は完了です。

3.2.16 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パスを削除する場合は、データベースを再起動してその変更を有効にする必要があります。

3.3 Oracle Automatic Storage Managementの記憶域の構成

次の項で、Oracle Automatic Storage Managementの記憶域の構成について説明します。

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

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

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

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

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

3.3.1 Oracle Automatic Storage Management用の記憶域の構成

この項では、Oracle Automatic Storage Management (Oracle ASM)で使用する記憶域の構成方法について説明します。

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

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

3.3.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ファイルと、データベース・ファイルおよびリカバリ・ファイルに必要なディスク領域の合計容量を決定します。
表3-4と表3-5を使用して、Oracle Clusterwareファイルのインストールと、初期データベースのインストールに必要なディスクの最小台数およびディスクの最小領域を決定します。投票ディスクは別のディスク・グループにあるものとします。

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

冗長レベル

ディスクの最小台数

Oracle Cluster Registry(OCR)ファイル

投票ディスク・ファイル

合計

外部

1

300MB

600MB

900MB

標準

3

600MB

900MB

1.5GB脚注 1

高

5

900MB

1.5GB

2.4GB

脚注1 インストール中にディスク・グループを作成する場合は、2GB以上にする必要があります。

注意:
投票ディスク・ファイルがディスク・グループにある場合、Oracle Clusterwareファイル(OCRおよび投票ディスク)があるディスク・グループの障害グループの最小数は、他のディスク・グループよりも多くなります。
インストール中に、OCRおよび投票ディスク・ファイルのインストール先としてディスク・グループを作成する場合、使用可能な領域が2GB以上あるディスク・グループ上にこれらのファイルを作成するよう、インストーラによって求められます。

定数障害グループは特別なタイプの障害グループであり、これらの障害グループのディスクにユーザー・データは含まれません。定数障害グループは、ユーザー・データを格納するための冗長性要件を決定する際には考慮されません。ただし、ディスク・グループをマウントする場合は定数障害グループが考慮されます。

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

冗長レベル

ディスクの最小台数

データベース・ファイル

リカバリ・ファイル

合計

外部

1

1.5GB

3GB

4.5GB

標準

2

3GB

6GB

9GB

高

3

4.5GB

9GB

13.5GB

4. 割当て単位サイズを決定します。すべてのOracle ASMディスクは割当て単位(AU)に分割されます。割当て単位は、ディスク・グループ内の割当ての基本単位です。特定のディスク・グループ互換レベルに応じて、AUサイズの値に1、2、4、8、16、32、64MBを選択できます。デフォルト値は1MBに設定されています。

5. 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以上のディスク容量が必要です。Oracle Clusterwareファイルを作成するのに効果的な2GBのディスク容量を確保するには、各ディスクに2.1GB以上、3台のディスクで合計6.3GB以上の容量を確保する必要があります。

6. 必要な場合は、Oracle ASMディスク・グループのデバイスに障害グループを指定します。
標準または高冗長ディスク・グループを使用する場合は、カスタム障害グループのディスク・デバイスを関連付けることによって、ハードウェア障害に対するデータベースの保護を強化できます。デフォルトでは、各デバイスに独自の障害グループが含まれます。ただし、標準冗長ディスク・グループの2台のディスク・デバイスが同じSCSIコントローラに接続されている場合、コントローラに障害が発生すると、ディスク・グループは使用できなくなります。この例でのコントローラは、シングル・ポイント障害です。

このタイプの障害を防止するためには、2つのSCSIコントローラを使用します。各コントローラに2台のディスクを接続し、各コントローラに接続されたディスクに障害グループを定義します。この構成では、ディスク・グループが1つのSCSIコントローラの障害を許容できるようになります。

注意:
インストール後に、GUIツールのASMCA、コマンドライン・ツールのasmcmd、またはSQLコマンドを使用して、カスタム障害グループを定義します。
カスタム障害グループを定義する際、データベース・ファイルのみを格納する障害グループの場合、標準冗長ディスク・グループでは最小で2つの障害グループ、高冗長ディスク・グループでは3つの障害グループを指定する必要があります。

データベース・ファイルと、投票ディスクを含むClusterwareファイルを格納する障害グループの場合は、標準冗長ディスク・グループでは3つ以上の障害グループ、高冗長ディスク・グループでは5つ以上の障害グループを指定する必要があります。

投票ファイルを格納するディスク・グループの場合、標準冗長では最小で3つの障害グループ、高冗長では最小で5つの障害グループが必要です。それ以外の場合、最小数はそれぞれ2つと3つです。障害グループの最小数は、カスタム障害グループかどうかにかかわらず適用されます。

7. システムに適切なディスク・グループが存在しない場合は、適切なディスク・デバイスを設置または指定して、新しいディスク・グループを追加します。次のガイドラインに従って、適切なディスク・デバイスを指定します。

- Oracle ASMディスク・グループのすべてのデバイスは、サイズおよびパフォーマンス特性が同じである必要があります。

- 単一の物理ディスクにある複数のパーティションを、1つのディスク・グループのデバイスとして指定しないでください。Oracle ASMは、各ディスク・グループのデバイスが、別々の物理ディスク上に存在するとみなします。

- 論理ボリュームは、Oracle ASMディスク・グループのデバイスとして指定できますが、Oracle ASMには不要なほどレイヤーが複雑になるため、この使用はお薦めしません。さらに、Oracle ASMおよびOracle RACで論理ボリュームを使用する場合、Oracle RACでは、クラスタ論理ボリューム・マネージャが必要です。
論理ボリューム・マネージャを使用する場合は、ストライプ化またはミラー化なしの単一のLUNとして論理ボリューム・マネージャを使用し、追加の記憶域レイヤーの影響を最小限に抑えるようにすることをお薦めします。

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

動作保証されているNASストレージ・デバイスがある場合は、NFSマウント・ディレクトリにゼロ埋込みファイルを作成し、そのファイルをOracle ASMディスク・グループのディスク・デバイスとして使用できます。

そのファイルを作成するには、次の手順を実行します。

1. 必要に応じて、NASデバイスのディスク・グループ・ファイル用にエクスポート・ディレクトリを作成します。
この手順の実行方法の詳細は、NASデバイスのドキュメントを参照してください。

2. ユーザーをrootに切り替えます。

3. マウント・ポイント・ディレクトリをローカル・システムに作成します。次に例を示します。

# mkdir -p /mnt/asm

4. システムの再起動時にNFSファイル・システムが確実にマウントされるように、マウント・ファイル/etc/vfstabにファイル・システムのエントリを追加します。

関連項目:
NASマウント・オプションの最新情報については、次のURLにあるMy Oracle SupportのNote 359515.1を参照してください。

https://support.oracle.com

オペレーティング・システムに対応したマウント・ファイルの編集方法の詳細は、manページを参照してください。推奨されるマウント・オプションの詳細は、第3.2.5項「記憶域のNFSマウントおよびバッファ・サイズ・パラメータの構成」を参照してください。

5. 次のコマンドを入力して、NFSファイル・システムをローカル・システムにマウントします。

# mount /mnt/asm

6. 作成するディスク・グループの名前を選択します。たとえば、sales1とします。

7. NFSファイル・システムにファイルのディレクトリを作成します。ディレクトリ名には、ディスク・グループの名前を付けます。次に例を示します。

# mkdir /mnt/asm/nfsdg

8. 次のようなコマンドを使用して、このディレクトリに必要な数のゼロ埋込みファイルを作成します。

# dd if=/dev/zero of=/mnt/asm/nfsdg/disk1 bs=1024k count=1000

この例では、NFSファイル・システムに1GBのファイルを作成します。外部冗長、標準冗長または高冗長のディスク・グループを作成するには、それぞれ1つ、2つまたは3つのファイルを作成する必要があります。

9. 作成したディレクトリとファイルの所有者、グループおよび権限を変更するには、次のようなコマンドを入力します。インストール所有者はgrid、OSASMグループはasmadminです。

# chown -R grid:asmadmin /mnt/asm
# chmod -R 660 /mnt/asm

10. Oracle RACまたはスタンドアロンのOracle Databaseをインストールする場合は、インストール時に、Oracle ASMのディスク検出文字列を編集して、作成したファイル名と一致する正規表現を指定します。次に例を示します。

/mnt/asm/sales1/

注意:
インストール中に、Oracle ASMにマウントされたディスク・パスがデフォルトのデータベース記憶域の候補ディスクとしてリストされます。

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

既存のOracle ASMディスク・グループにデータベースまたはリカバリ・ファイルを格納するために、インストール方法に応じて次のいずれかを選択します。

- Database Configuration Assistantを対話型モードで実行するインストール方法を選択した場合、新しいディスク・グループを作成するか、または既存のディスク・グループを使用するかを選択できます。
インストール後にDatabase Configuration Assistantを使用してデータベースを作成する場合に、同じ選択内容を使用できます。

- Database Configuration Assistantを非対話型モードで実行するインストール方法を選択した場合、新しいデータベースには既存のディスク・グループを選択する必要があり、新しいディスク・グループは作成できません。ただし、要件に対して既存ディスク・グループの空き領域が不十分である場合は、既存ディスク・グループにディスク・デバイスを追加できます。

注意:
既存ディスク・グループを管理するOracle ASMインスタンスは、異なるOracleホーム・ディレクトリで実行されている可能性があります。

既存のOracle ASMディスク・グループが存在するかどうか、またはディスク・グループに十分なディスク領域があるかどうかを判断するために、Oracle ASMコマンドライン・ツール(asmcmd)、Oracle Enterprise Manager Grid ControlまたはDatabase Controlを使用できます。また、次の手順も使用できます。

1. oratabファイルの内容を表示して、Oracle ASMインスタンスがシステムに組み込まれているかどうかを判断します。

$ more /etc/oratab

Oracle ASMインスタンスがシステムに組み込まれている場合、oratabファイルには次のような行が含まれます。

+ASM2:oracle_home_path

この例では、+ASM2はOracle ASMインスタンスのシステム識別子(SID)、oracle_home_pathは自動ストレージ管理インスタンスが組み込まれているOracleホーム・ディレクトリです。表記規則により、Oracle ASMインスタンスのSIDは、プラス(+)記号で始まります。

2. 環境変数ORACLE_SIDおよびORACLE_HOMEを設定して、Oracle ASMインスタンスに対して適切な値を指定します。

3. Oracle ASMインスタンスに接続し、必要に応じてインスタンスを起動します。

$ $ORACLE_HOME/bin/asmcmd
ASMCMD> startup

4. 次のコマンドのいずれかを入力して、既存のディスク・グループ、それらの冗長レベルおよび各グループでのディスクの空き領域を表示します。

ASMCMD> lsdb

または

$ORACLE_HOME/bin/asmcmd -p lsdg

5. 出力結果から、適切な冗長レベルが設定されているディスク・グループを特定し、そのディスク・グループにある空き領域を記録します。

6. 必要に応じて、前述の記憶域要件を満たすために必要な追加のディスク・デバイスを設置または指定します。

注意:
既存のディスク・グループにデバイスを追加する場合は、サイズおよびパフォーマンス特性が、そのディスク・グループ内の既存デバイスと同じであるデバイスの使用をお薦めします。

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

Oracle Automatic Storage Management (Oracle ASM)ディスク・グループとして使用するRAWディスクを構成できます。Oracle ASMをRAWディスクで使用するには、データ・ファイル用に十分なパーティションを作成した後、そのパーティションをRAWディスクにバインドする必要があります。データ・ファイル用に作成するRAWディスク名のリストを作成し、そのリストをデータベースのインストール時に使用できるようにします。

次の手順で、物理ボリュームID(PVID)をRAWディスク用に設定するように指示されます。構成の問題を回避するために、ご使用のシステムでPVIDを構成していない場合でも、この手順全体を完了することをお薦めします。

注意:
ストレージにHitachi HDLM(dmlfデバイス)を使用する場合、ASMインスタンスは自動的には物理ディスクを検出せず、論理ボリューム・マネージャ(LVM)ディスクのみを検出します。これは、物理ディスクをオープンできるのはrootで実行しているプログラムのみであるためです。
物理ディスクのパスには、次のようなパス名があります。

/dev/rdlmfdrv8
/dev/rdlmfdrv9

ディスクを構成するには、次の手順を実行します。

1. 必要に応じて、ディスク・グループに使用するディスクを設置し、システムを再起動します。

2. Oracle ASMディスク・グループに含めるディスクを指定または作成します。任意のノードで、rootユーザーとして次のコマンドを入力し、使用するディスク・デバイスのデバイス名を確認します。

# /usr/sbin/lspv | grep -i none

このコマンドによって、ボリューム・グループに構成されていないディスク・デバイスごとに、次のような情報が表示されます。

hdisk17         0009005fb9c23648                    None

この例では、hdisk17はディスクのデバイス名、0009005fb9c23648は物理ボリュームID(PVID)です。

3. 使用するディスク・デバイスにPVIDがない場合は、次のコマンドを入力してディスク・デバイスに割り当てます。nはhdiskの数です。

# chdev -l hdiskn -a pv=yes

注意:
既存のPVIDがある場合は、chdevによって上書きされます。以前のPVIDに依存するアプリケーションがある場合、それらは失敗することに注意してください。

4. 他のそれぞれのノードで、次のコマンドを入力し、そのノードの各PVIDに関連付けられているデバイス名を確認します。

# /usr/sbin/lspv | grep -i "0009005fb9c23648"

このコマンドの出力結果は、次のようになります。

hdisk18         0009005fb9c23648                    None

この例では、ディスク・デバイスに関連付けられているデバイス名(hdisk18)は、前述のノードのものとは異なります。

5. デバイス名がすべてのノードで同じである場合は、すべてのノードで次のコマンドを入力し、ディスク・デバイスのキャラクタRAWデバイス・ファイルの所有者、グループおよび権限を変更します。gridは、Oracle Grid Infrastructureインストールの所有者、asmadminはOSASMグループです。

# chown grid:asmadmin /dev/rhdiskn
# chmod 660 /dev/rhdiskn

6. 複数のノードからディスク・デバイスに同時アクセスできるようにするには、ディスクで使用する予約属性のタイプに応じて、適切なObject Data Manager(ODM)属性を設定する必要があります。次の項では、論理名hdiskを使用してこのタスクを実行する方法について説明します。論理デバイス名については、ご使用のオペレーティング・システムのマニュアルを参照してください。
ディスクで使用する予約設定を確認するには、次のコマンドを入力します。nはhdiskのデバイス番号です。

# lsattr -E -l hdiskn | grep reserve_

このコマンドの結果として、reserve_lock設定またはreserve_policy設定が返されます。属性がreserve_lockの場合は、設定がreserve_lock = noであることを確認します。属性がreserve_policyの場合は、設定がreserve_policy = no_reserveであることを確認します。

必要に応じて、chdevコマンドで次の構文を使用して設定を変更します。nはhdiskのデバイス番号です。

chdev -l hdiskn -a [ reserve_lock=no | reserve_policy=no_reserve ]

たとえば、デバイスhdisk4の設定をreserve_lock=yesからreserve_lock=noに変更するには、次のコマンドを入力します。

# chdev -l hdisk4  -a  reserve_lock=no

すべてのディスク・デバイスで設定が適切であることを確認するには、次のコマンドを入力します。

# lsattr -El hdiskn | grep reserve

7. 任意のノードで次のコマンドを入力し、使用する各ディスク・デバイスからPVIDを消去します。

# /usr/sbin/chdev -l hdiskn -a pv=clear

Oracle Clusterwareをインストールする際に、OCRおよびOracle Clusterware投票ディスクのパスを求められたら、適切なデバイス・ファイルへのパスを入力する必要があります。次に例を示します。

/dev/rhdisk10

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

次の項で、Oracle ClusterwareおよびOracle DatabaseファイルのためのOracle Automatic Storage Managementの記憶域の構成について説明します。

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

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

3.3.4.1 Oracle ASM上の既存のOracle Databaseディスク・グループの使用

次の項では、既存ディスク・グループの指定方法およびそのディスク・グループが持つ空きディスク領域の確認方法について説明します。

- 必要な場合は、Oracle Automatic Storage Managementディスク・グループのデバイスに障害グループを指定します。
標準または高冗長ディスク・グループを使用する場合は、カスタム障害グループのディスク・デバイスを関連付けることによって、ハードウェア障害に対するデータベースの保護を強化できます。デフォルトでは、各デバイスに独自の障害グループが含まれます。ただし、標準冗長ディスク・グループの2台のディスク・デバイスが同じSCSIコントローラに接続されている場合、コントローラに障害が発生すると、ディスク・グループは使用できなくなります。この例でのコントローラは、シングル・ポイント障害です。

このタイプの障害を防止するためには、2つのSCSIコントローラを使用します。各コントローラに2台のディスクを接続し、各コントローラに接続されたディスクに障害グループを定義します。この構成では、ディスク・グループが1つのSCSIコントローラの障害を許容できるようになります。

注意:
カスタム障害グループを定義する場合、標準冗長では2つ以上の障害グループ、高冗長では3つ以上の障害グループを指定する必要があります。

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

システムに適切なディスク・グループが存在しない場合は、適切なディスク・デバイスを設置または指定して、新しいディスク・グループを追加します。次のガイドラインに従って、適切なディスク・デバイスを指定します。

- Oracle Automatic Storage Managementディスク・グループのすべてのデバイスは、サイズおよびパフォーマンス特性が同じである必要があります。

- 単一の物理ディスクにある複数のパーティションを、1つのディスク・グループのデバイスとして指定しないでください。Oracle Automatic Storage Managementは、各ディスク・グループのデバイスが、別々の物理ディスク上に存在するとみなします。

- 論理ボリュームは、Oracle ASMディスク・グループのデバイスとして指定できますが、これを使用することはお薦めしません。共有されていない論理ボリュームはOracle RACではサポートされません。論理ボリュームをOracle RACデータベースに使用する場合は、クラスタ対応の論理ボリューム・マネージャによって作成された共有同時実行RAW論理ボリュームを使用する必要があります。

3.3.5 Oracle Automatic Storage Managementクラスタ・ファイル・システムの構成

Oracle ACFSは、Oracle Grid Infrastructure(Oracle ClusterwareおよびOracle Automatic Storage Management)11gリリース2(11.2)のインストールの一部として、インストールされます。Oracle ACFSをデータベース・ホーム用に構成したり、ASMCAを使用して汎用ファイルシステムとしてACFSを構成することができます。

注意:
Oracle ACFSは、AIX 6.1(PPC64)に対するAIX 6.1 TL4 SP2以上の更新でのみサポートされています。クラスタ用Oracle Grid Infrastructure 11gリリース2(11.2)でサポートされている他のAIXリリースはいずれも、Oracle ACFSをサポートしていません。

Oracle RACデータベース用にOracle Databaseホーム用のOracle ACFSを構成するには、次の手順を実行します。

1. クラスタ用Oracle Grid Infrastructure(Oracle ClusterwareおよびOracle Automatic Storage Management)をインストールします。

2. Oracle Grid Infrastructureホームに移動します。次に例を示します。

$ cd /u01/app/11.2.0/grid

3. Oracle Grid Infrastructureインストール所有者が、使用するストレージ・マウント・ポイントに対する読込みおよび書込み権限を持っていることを確認します。たとえば、マウント・ポイント/u02/acfsmounts/を使用する場合は次のようになります。

$ ls -l /u02/acfsmounts

4. Gridインストールの所有者として、Oracle ASM Configuration Assistantを起動します。次に例を示します。

./asmca

5. 「ASMの構成: ASMディスク・グループ」ページに、インストール中に作成したOracle ASMディスク・グループが表示されます。「ASMクラスタ・ファイルシステム」タブをクリックします。

6. 「ASMクラスタ・ファイルシステム」ページでデータ・ディスクを右クリックし、「データベース・ホームのACFSの作成」を選択します。

7. 「ACFSホスト・データベース・ホームの作成」ウィンドウで次の情報を入力します。

- データベース・ホームのADVMボリューム・デバイス名: データベース・ホームの名前を入力します。この名前は、社内で一意である必要があります。たとえば、dbase_01とします。

- データベース・ホームのマウント・ポイント: マウント・ポイントのディレクトリ・パスを入力します。たとえば、/u02/acfsmounts/dbase_01とします。
後で参照するために、このマウント・ポイントを書き留めます。

- データベース・ホーム・サイズ(GB): データベース・ホームのサイズをGB単位で入力します。

- データベース・ホームの所有者名: データベースのインストールに使用するOracle Databaseインストール所有者の名前を入力します。たとえば、oracle1とします。

- データベース・ホームの所有者グループ: データベースのインストール時に指定するメンバーが含まれるOSDBAグループを入力します。このグループのメンバーには、データベースに対するSYSDBA権限のオペレーティング・システム認証が付与されます。たとえば、dba1とします。

- 入力が完了したら、「OK」をクリックします。

8. 特権ユーザー(root)として、Oracle ASM Configuration Assistantによって生成されたスクリプトを実行します。Oracle Clusterware環境では、Oracle Clusterwareによって管理されるリソースとしてACFSが登録されます。リソースとしてACFSを登録することによって、ACFSがOracle RACデータベース・ホームに使用される場合に、Oracle ClusterwareがACFSを適切な順序で自動的にマウントできるようになります。

9. Oracle RACのインストール中に、Oracle RACをインストールするユーザーまたはDBAが、「データベース・ホームのマウント・ポイント」フィールドで指定したマウント・ポイントをOracleホームに選択するようにします(前の例では/u02/acfsmounts/dbase_01)。

関連項目:
Oracle ACFSを使用してストレージを構成および管理する方法の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

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

以前のリリースのOracle ASMが、サーバー上または既存のOracle Clusterwareインストール環境内にインストールされている場合は、パスGrid_home/binにあるOracle Automatic Storage Management Configuration Assistant (ASMCA)を使用して、既存のOracle ASMインスタンスをOracle ASM 11gリリース2(11.2)にアップグレードし、その後で障害グループ、Oracle ASMボリュームおよびOracle Automatic Storage Management Cluster File System (ACFS)を構成できます。

注意:
既存のOracle ASMインスタンスのアップグレードは、そのノード上のすべてのデータベース・インスタンスおよびアプリケーションを停止してから実行する必要があります。

インストール時、11.2より前のOracle ASMリリースからアップグレードしていて、Oracle ASMを使用することを選択し、以前のOracle ASMバージョンが別のOracle ASMホームにインストールされていることが検出された場合は、Oracle ASM 11gリリース2(11.2)のバイナリをインストールした後に、ASMCAを起動して既存のOracle ASMインスタンスをアップグレードできます。次に、Oracle ASMボリュームを作成し、アップグレードしたOracle ASMを使用してOracle ACFSを作成することで、Oracle ACFSのデプロイメントを構成できます。

Oracle ASM 11gリリース2(11.2.0.1)以上からアップグレードしている場合は、Oracle ASMはローリング・アップグレードの一部として常にOracle Grid Infrastructureとともにアップグレードされ、アップグレード中にrootスクリプトによってASMCAが起動されます。リリース11.2.0.1から11.2.0.2では、ASMCAがOracle ASMを個別にアップグレードすることはできません。

Oracle ClusterwareまたはOracle RACの既存のインストール環境で、すべてのノード上のOracle ASMインスタンスの旧バージョンが11gリリース1の場合は、Oracle ASMインスタンスのローリング・アップグレードを実行できます。Oracle RACのインストール環境で、旧バージョンのOracle ASMインスタンスが11gリリース1よりも前のリリースの場合は、ローリング・アップグレードを実行できません。Oracle ASMは、すべてのノードで11gリリース2(11.2)にアップグレードされます。

3.4 RAWディスクのサポート終了

Oracle Database 11gリリース2(11.2)およびOracle RAC 11gリリース2(11.2)では、Database Configuration Assistantまたはインストーラを使用して、RAWデバイス上に直接Oracle ClusterwareまたはOracle Databaseファイルを格納する処理がサポートされなくなりました。

既存のOracle RACデータベースをアップグレードする場合、またはOracle ASMインスタンスを使用するOracle RACデータベースをアップグレードする場合は、既存のRAWディスクまたはRAW論理ボリュームを使用して、既存のインストールをローリング・アップグレードできます。RAWディスクまたはRAW論理ボリュームを使用した、新しいインストールは実行できません。

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

この章では、クラスタ用Oracle Grid Infrastructureをインストールする手順について説明します。Oracle Grid Infrastructureは、Oracle ClusterwareおよびOracle Automatic Storage Managementで構成されます。後でOracle DatabaseおよびOracle Real Application Clusters(Oracle RAC)をインストールする場合、このフェーズは2つあるインストール・フェーズの1つとなります。

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

- OUIを使用してOracle Grid Infrastructureをインストールするための準備

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

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

- Oracle Clusterwareの機能の確認

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

4.1 OUIを使用してOracle Grid Infrastructureをインストールするための準備

インストーラを使用してOracle Grid Infrastructureをインストールする前に、次のチェックリストを使用して、インストール中に必要なすべての情報が揃っていること、およびインストールを開始する前に実行しておく必要があるすべての作業が完了していることを確認します。次に示す各作業を完了するたびにチェック・マークを付け、インストール中に使用できるように必要な情報を書き込みます。

- 実行中のOracleプロセスを停止する
実行中のOracleプロセスを停止する必要がある場合があります。

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

Oracle ASM上で実行しているスタンドアロンのOracle Database 11gリリース2(11.2)インストールがすでに存在するノードにインストールする場合: 既存のOracle ASMインスタンスを停止します。Oracle ASMインスタンスは、インストール中に再起動されます。

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

注意:
Oracle RAC 9iリリース2(9.2)のノードをアップグレードするときに、SCANがリスニングするポートと同じポート(デフォルトは1521)でTNSLSNRがリスニングしている場合は、TNSLSNRを停止する必要があります。

Oracle9iリリース2(9.2)以前のグローバル・サービス・デーモン(GSD)が実行されている場合は、まずそれを停止し、次のコマンドを実行してOracle Grid Infrastructureをインストールします。

$ Oracle_home/bin/gsdctl stop

Oracle_homeは、GSDが実行されているOracle Databaseのホームです。

注意:
Oracle9iリリース2(9.2)の既存のOracle Cluster Manager(Oracle CM)がインストールされている場合、Oracle CMサービスは停止しないでください。停止すると、Oracle Grid Infrastructure 11gリリース2(11.2)のソフトウェアでOracle9iリリース2のノード・リストを検出できなくなり、Oracle Grid Infrastructureのインストールが失敗する原因になります。

注意:
OUIを起動した後にすべてのOracleサービスの停止を要求する警告が表示された場合は、次のコマンドを入力します。

Oracle_home/bin/localconfig delete

Oracle_homeは既存のOracle Clusterwareホームです。

- Oracle Automatic Storage ManagementおよびOracle Clusterwareのインストール環境がすでにある場合は、そのアップグレードを準備する
Oracle Grid Infrastructureのインストール中に、既存のOracle Clusterwareおよびクラスタ化されたOracle ASMインストールの両方がアップグレードされます。

クラスタ内のすべてのメンバー・ノードでOracle Grid Infrastructure 11gリリース2(11.2)が実行されている場合は、新しいクラスタウェアがアクティブなバージョンになります。

Oracle RACをインストールする場合は、最初にすべてのクラスタ・ノードでOracle Grid Infrastructure 11gリリース2(11.2)へのアップグレードを完了してから、Oracle Database 11gリリース2(11.2)バージョンのOracle RACをインストールする必要があります。

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

- Oracle Inventory(oraInventory)の位置を指定する
システムにすでにOracleソフトウェアがインストールされている場合は、OUIによって既存のOracle Inventory(oraInventory)ディレクトリが/var/opt/oracle/oraInst.locファイルから検出され、この位置が使用されます。このディレクトリは、システムにインストールされているOracleソフトウェアの中央インベントリです。プライマリ・グループがOracle Inventoryグループであるユーザーは、中央インベントリに書込みできるOINSTALL権限が付与されます。

Oracleソフトウェアをシステムに初めてインストールする際にoraInventoryディレクトリがシステムに存在しない場合、インストール所有者のプライマリ・グループはOracle Inventoryグループになります。使用するOracleソフトウェア・インストール所有者のすべてが、このグループをプライマリ・グループとして利用できることを確認します。

注意:
oraInventoryディレクトリは、共有ファイル・システム上に配置することはできません。

関連項目:
Oracle Inventoryの作成方法および必要なシステム構成の設定方法については、第2章のインストール前の手順に関する章を参照してください。

- rootアカウントへのアクセス権を取得する
インストール中に、rootユーザーとして構成スクリプトを実行する必要があります。これらのスクリプトは、rootユーザーとして実行するか、またはシステム管理者に実行を依頼する必要があります。最初のノードでroot.shスクリプトを実行し、完了するまで待機する必要があります。クラスタに4つ以上のノードが存在する場合、最初と最後のノードを除いて、すべてのノードでroot.shを同時に実行することができます。

- 他の言語をインストールするかどうかを決定する
インストール中に、ユーザー・インタフェースのテキストをデフォルト(英語)以外の言語に翻訳するかどうかを選択します。

注意:
オペレーティング・システムの言語セットがインストーラでサポートされていない場合、インストーラは、デフォルトでは英語で実行されます。

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

- クラスタ名、パブリック・ノード名、SCAN、仮想ノード名、GNS VIP、およびクラスタ内の各ノードのインタフェース使用計画を指定する
インストール中、他社のクラスタ・ソフトウェアを使用していないかぎり、パブリック・ホスト名および仮想ホスト名を提供するように求められます。その場合は、パブリック・ホスト名の情報を入力します。また、どのインタフェースがパブリックまたはプライベートなのか、あるいは別の目的(ネットワーク・ファイル・システムなど)で使用されるインタフェースなのか、指定するように求められます。

グリッド・ネーミング・サービス(GNS)を使用している場合、パブリック・ホスト名および仮想ホスト名のアドレスは自動的に構成されるため、OUIはこれらのアドレスにAUTOと表示します。

注意:
IPアドレスを手動で構成した場合は、Oracle Grid Infrastructureをインストールした後で、ドメイン修飾子の追加や削除も含め、ホスト名を変更しないでください。新しいホスト名を持つノードは、新しいホストと見なされるので、クラスタに追加する必要があります。古い名前のノードは、クラスタから削除されるまで、停止状態で表示されます。

他社のクラスタウェアを使用する場合は、そのベンダーのドキュメントを参照して、パブリックおよびプライベートのドメイン・アドレスを設定してください。

パブリック・ノード名の入力には、各ノードのプライマリ・ホスト名を使用します。この名前は、hostnameコマンドによって表示される名前です。

さらに、次の処理を実行します。

- 次の特性を持ったクラスタ名を指定します。

- ホスト・ドメイン内でグローバルに一意である。

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

- RFC 1123に準拠して、ホスト名に使用されるキャラクタ・セット(ハイフン(-)およびシングルバイト英数字(aからz、AからZ、および0から9)を含む)と同じキャラクタ・セットで構成されている。他社ベンダーのクラスタウェアを使用する場合は、そのベンダーのクラスタ名を使用することをお薦めします。

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

- クラスタへのクライアント・アクセス用のSCANアドレスを指定します。このアドレスは、ドメイン・ネーム・サービス(DNS)にラウンド・ロビン・アドレスとして構成してください。SCANアドレスは、3つ指定することをお薦めします。

注意:
次に、ノードIPアドレスに関する追加情報を示します。

- ローカル・ノードの場合のみ、OUIによってパブリックおよびVIPフィールドが自動的に書き込まれます。システムでベンダーのクラスタウェアが使用されている場合は、OUIにより追加のフィールドが書き込まれることがあります。

- ホスト名および仮想ホスト名は、ドメイン修飾されません。インストール中にアドレス・フィールドにドメインを入力すると、そのドメインは、OUIによってアドレスから削除されます。

- プライベートIPアドレス用にプライベートとして指定したインタフェースは、パブリック・インタフェースとしてアクセスできないようにする必要があります。キャッシュ・フュージョンにパブリック・インタフェースを使用すると、パフォーマンスの問題が発生する可能性があります。

- パブリック・インタフェースおよびプライベート・インタフェースを指定します。OUIは、パブリックIPアドレスおよび仮想IPアドレスによって使用されるようにパブリック・インタフェースを構成し、プライベートIPアドレスをプライベート・インタフェース上に構成します。
プライベート・インタフェースが使用するプライベート・サブネットは、クラスタ・メンバーにする予定のすべてのノードに接続する必要があります。

- ネットワーク上にプロキシ・レルムがある場合は、プロキシ・レルムの認証情報を取得する
インストール時に、OUIによって更新のダウンロードが試行されます。プロキシ・サービスを介してインターネットにアクセスするために、プロキシ・レルムおよびユーザー認証情報を入力するように求められます。プロキシ・レルムを構成済の場合は、この情報を入力する準備をしておきます。プロキシ・レルムがない場合は、プロキシ認証のフィールドを空白のままにできます。

- Oracle Clusterwareファイル用の共有記憶域を指定し、記憶域を準備する(必要な場合)
インストール中に、次のOracle Clusterwareファイルのパスを指定するように求められます。これらのファイルは、クラスタのすべてのノードで共有し、Oracle ASMまたはサポートされているファイル・システム上のいずれかに存在する必要があります。

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

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

ファイル・システムに外部記憶域の冗長性が適用されていない場合は、OCRディスク用に2つ、投票ディスク用に2つの場所を追加し、合計6つのパーティション(OCR用に3つ、投票ディスク用に3つ)を確保することをお薦めします。冗長性のある記憶域の場所を作成すると、障害の発生時にOCRおよび投票ディスクが保護されます。クラスタを完全に保護するには、OCRおよび投票ディスクのコピーを格納する記憶域の場所について、そのパス、コントローラおよびディスクを完全に別にして、複数の記憶域の場所に影響するシングル・ポイント障害がないようにする必要があります。

OCRをOracle ASM上に格納するように選択した場合、デフォルト構成では、OCRは1つのASMディスク・グループに作成されます。標準冗長または高冗長でディスク・グループを作成した場合は、OCRは物理ディスク障害から保護されます。

OCRを論理ディスク障害から保護するには、インストール後に別のASMディスク・グループを作成し、ocrconfigコマンドを使用してOCRをこの2つ目のディスク・グループに追加します。

関連項目:
ディスク・グループへのディスクの追加については、第2章「クラスタ用Oracle Grid Infrastructureの拡張インストールのインストール前作業」および『Oracle Databaseストレージ管理者ガイド』を参照してください。

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

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

- Oracle環境変数の設定を削除する。環境変数にORA_CRS_HOMEを設定した場合は、インストールまたはアップグレードを開始する前に、その設定を削除します。ORA_CRS_HOMEを環境変数に使用しないでください。
システムに既存のインストール環境があり、同じユーザー・アカウントを使用して今回のインストールを行う場合、次の環境変数ORA_CRS_HOME、ORACLE_HOME、ORA_NLS10、TNS_ADMINの設定を削除します。

- ソフトウェア更新オプションを使用するかどうかを決定する。OUIでは、重要なパッチ更新、サポートされているオペレーティング・システムのシステム要件の更新(ハードウェア、オペレーティング・システム・パラメータおよびカーネル・パッケージ)、およびインストールをスムーズに行うためのその他の重要な更新をインストールすることができます。インストール時はソフトウェア更新を有効にすることをお薦めします。
ソフトウェア更新を有効にする場合は、OUIで最新の更新をダウンロードするためにインストール中にMy Oracle Supportの有効なユーザー名とパスワードを指定する必要があります。または、すでにダウンロード済のソフトウェア更新パッケージの場所へのパスを指定する必要があります。

保護されたデータ・センターでインストールを実行する場合は、更新ダウンロード・モードでインターネットにアクセスできるシステムでOUIを起動することによって、インストールを開始する前に更新をダウンロードできます。OUIを起動して更新をダウンロードするには、次のコマンドを入力します。

$ ./runInstaller -downloadUpdates

My Oracle Supportのユーザー名とパスワード、および必要に応じてプロキシ設定を指定します。更新をダウンロードした後、インストールを実行するサーバー上のディレクトリに更新ファイルを転送します。

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

この項では、インストーラを使用してOracle Grid Infrastructureをインストールする方法について説明します。内容は次のとおりです。

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

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

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

クラスタにグリッド・インフラストラクチャ(Oracle ClusterwareおよびOracle Automatic Storage Management)をインストールするには、次の手順を実行します。インストール中に、求められている操作に対して疑問がある場合は、OUIページの「ヘルプ」ボタンをクリックします。

1. インストール・メディア上の/Disk1ディレクトリか、インストールのバイナリをダウンロードした場所に移動し、runInstallerコマンドを実行します。次に例を示します。

$ cd /home/grid/oracle_sw/Disk1
$ ./runInstaller

2. 「標準」または「詳細」インストールを選択します。

3. OUIのプロンプトが表示されたら、情報を入力するか、またはrootとしてスクリプトを実行します。インストール手順の詳細は、「ヘルプ」をクリックしてください。 「詳細」をクリックしてログファイルを確認します。いずれかのノードでroot.shが失敗する場合は、問題を修正してから第6.5項「バイナリを削除せずに行うOracle Clusterwareの構成解除」の手順に従い、そのノードでroot.shを再実行して続行します。

注意:
最初のノードでroot.shスクリプトを実行し、完了するまで待機する必要があります。クラスタに4つ以上のノードが存在する場合、最初と最後のノードを除いて、すべてのノードでroot.shを同時に実行することができます。最後のノードでは、最初のノードと同様に、root.shスクリプトを個別に実行する必要があります。

4. すべてのノードでroot.shを実行すると、OUIによってNet Configuration Assistant(netca)およびクラスタ検証ユーティリティが起動されます。これらのプログラムはユーザーの介入なしに起動されます。

5. Oracle Automatic Storage Management Configuration Assistant (asmca)によって、インストール中にOracle ASMが構成されます。

Oracle Grid Infrastructureのインストールが正常に完了したことが検証されると、他のアプリケーションの高可用性を維持するために使用するか、またはOracle Databaseをインストールできます。

次に、インストールに関する追加情報を示します。

- Oracle Database 11gリリース2 (11.2)およびOracle RACをインストールする場合は、Oracle Real Application Clustersインストレーション・ガイド for IBM AIX on POWER Systems (64-Bit)を参照してください。

関連項目:
クローニングの使用およびノードの追加手順については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』、Oracle Grid Infrastructureのクローニングについては、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- Oracle Grid Infrastructureのインストール時にroot.shを実行すると、ディレクトリgrid_home/tfaに、トレース・ファイル(TF)アナライザおよびコレクタもインストールされます。

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

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

Oracle Grid Infrastructureのインストール時には、クラスタ構成情報を手動で指定するか、クラスタ構成ファイルを使用するかを選択できます。クラスタ構成ファイルはテキスト・ファイルで、OUIを起動する前に作成でき、このファイルによって、クラスタの構成に必要なクラスタ・ノード・アドレスがOUIに提供されます。

テスト・クラスタへのインストールを繰り返し実行する場合、または多数のノードでインストールを実行する場合は、クラスタ構成ファイルの使用をお薦めします。

クラスタ構成ファイルを手動で作成するには、テキスト・エディタを起動し、各クラスタ・メンバー・ノードのパブリックIPアドレスと仮想IPアドレスの名前を提供するファイルを次の形式で作成します。

node1 node1-vip
node2 node2-vip
.
.
.

次に例を示します。

mynode1 mynode1-vip
mynode2 mynode2-vip

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

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

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

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

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

注意:
ソフトウェアのみのインストールにはOracle Grid Infrastructureソフトウェアを有効にするための手動のインストール後の手順が必要なため、上級ユーザーのみが実行することをお薦めします。

ソフトウェアのみのインストールでは、1つのノードでクラスタ用Oracle Grid Infrastructureをインストールします。

インストール時に「Grid Infrastructureソフトウェアのインストールのみ」オプションを使用すると、ローカル・ノードにソフトウェア・バイナリがインストールされます。クラスタ用のインストールを完了するには、追加の手順として、Oracle ClusterwareおよびOracle ASMの構成、ローカル・インストールのクローンの作成、他のノードでのこのクローンのデプロイ、クラスタへの他のノードの追加を行う必要があります。

参照:
Oracle Grid Infrastructureインストールを他のノードにクローニングして、クラスタに追加する方法については、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

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

ソフトウェアのみのインストールを行うには、次の手順を実行します。

1. ローカル・ノードで、runcluvfy.sh stage -pre crsinstコマンドを使用して、クラスタ・ノードがインストール要件を満たしていることを検証します。すべての記憶域およびサーバーのインストール前要件が満たされていることを確認してください。

2. Oracle Database 11gリリース2 (11.2)のインストール・メディア上の関連ディレクトリまたはダウンロード・ディレクトリで、runInstallerコマンドを実行します。次に例を示します。

$ cd /home/grid/oracle_sw/Disk1
$ ./runInstaller

3. 最初のノードで、Oracle Grid Infrastructureのソフトウェアのみのインストールを完了します。

4. ソフトウェアがインストールされたら、プロンプトに従ってorainstRoot.shスクリプトを実行します。

5. Oracle RACリリース11.2.0.2以上でのインストールの場合は手順6に進みます。Oracle RACリリース11.2.0.1でのインストールの場合、Oracle RACオプションが有効になっているOracle Clusterwareを再リンクするには、次のようなコマンドを実行します(この例では、Gridホームは/u01/app/11.2.0/gridです)。

$ cd /u01/app/11.2.0/grid/
$ set env ORACLE_HOME pwd
$ cd rdbms/lib
$ make -f ins_rdbms.mk rac_on ioracle

6. root.shスクリプトの出力は、このインストールで完了しようとする構成内容に基づいて、どのように処理を進めるかについての情報を提供します。この情報を書き留めます。
ただし、Oracle Grid Infrastructureをスタンドアロン・サーバー(Oracle Restart)にインストールしない場合は、roothas.plスクリプトを実行する指示は無視してください。

7. 残りの各ノードで、runcluvfy.sh stage -pre crsinstコマンドを使用して、クラスタ・ノードがインストール要件を満たしていることを検証します。すべての記憶域およびサーバーのインストール前要件が満たされていることを確認してください。

8. 手順1から4の説明に従って、Oracle Universal Installerを使用して、クラスタに含める残りのすべてのノードでOracle Grid Infrastructureソフトウェアをインストールします。そして、すべてのノードでOracle Grid Infrastructureのソフトウェアのみのインストールを完了します。
第4.3.2項「ソフトウェア・バイナリの構成」で説明されているとおり、完全なOUI構成ウィザードGUIを使用してクラスタを構成するか、または第4.3.3項「レスポンス・ファイルを使用したソフトウェア・バイナリの構成」の項で説明されているとおり、レスポンス・ファイルを使用してクラスタを構成します。

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

リリース11.2.0.2以上で使用可能なOracle Grid Infrastructure構成ウィザードをGUIモードで起動して、ソフトウェア・バイナリを構成します。

1. グリッド・インフラストラクチャ・インストール所有者として端末にログインし、grid_home/crs/configに移動します。

2. 次のコマンドを入力します。

$ ./config.sh

構成スクリプトによってOUIが構成ウィザード・モードで起動します。必要に応じて構成情報を指定します。各ページには同じユーザー・インタフェースが表示され、OUIが通常実行するのと同じ妥当性チェックが実行されます。ただし、インストールを実行するのではなく、構成ウィザード・モードで入力が検証され、すべてのクラスタ・ノードでインストールが構成されます。

3. 入力を完了すると、OUIにより「サマリー」ページが表示され、クラスタに指定したすべての入力がリストされます。サマリーにクラスタの正しい情報が表示されていることを確認し、「インストール」をクリックしてローカル・ノードの構成を開始します。
ローカル・ノードの構成が完了すると、Oracle Grid Infrastructure構成ファイルが他のクラスタ・メンバー・ノードにOUIによりコピーされます。

4. プロンプトが表示されたら、rootスクリプトを実行します。

5. すべてのrootスクリプトが実行されたことを確認すると、OUIによってクラスタの構成ステータスが確認され、必要に応じてその他の構成ツールが起動されます。

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

ソフトウェアをどのノードにインストールまたはコピーする場合でも、構成を後で行うことができます。この項では、リリース11.2.0.2以上で使用可能な構成ウィザード・ユーティリティ(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/grid/crs/config/
$ ./config.sh -responseFile /u01/app/grid/response/response_file.rsp

構成スクリプトによってOUIが構成ウィザード・モードで起動します。各ページには同じユーザー・インタフェースが表示され、OUIが通常実行するのと同じ妥当性チェックが実行されます。ただし、インストールを実行するのではなく、構成ウィザード・モードで入力が検証され、すべてのクラスタ・ノードでインストールが構成されます。

2. 入力を完了すると、OUIにより「サマリー」ページが表示され、クラスタに指定したすべての入力がリストされます。サマリーにクラスタの正しい情報が表示されていることを確認し、「インストール」をクリックしてローカル・ノードの構成を開始します。
ローカル・ノードの構成が完了すると、Oracle Grid Infrastructure構成ファイルが他のクラスタ・メンバー・ノードにOUIによりコピーされます。

3. プロンプトが表示されたら、rootスクリプトを実行します。

4. すべてのrootスクリプトが実行されたことを確認すると、OUIによってクラスタの構成ステータスが確認され、必要に応じてその他の構成ツールが起動されます。

4.4 Oracle Berkeley DBの制限事項

クラスタ用Oracle Grid Infrastructure 11gリリース2(11.2.0.2)に含まれるOracle Berkeley DB埋込みデータベース・インストールは、Oracle Grid Infrastructureインストール製品でのみ使用できます。Berkeley DBのライセンス条項については、次のURLを参照してください。

http://www.oracle.com/technetwork/database/berkeleydb/downloads/index.html

4.5 Oracle Clusterwareの機能の確認

インストール後にrootとしてログインし、各ノードで次のコマンド構文を使用して、Oracle Clusterwareインストールが適切にインストールされ、動作していることを確認します。

crsctl check crs

次に例を示します。

$ crsctl check crs

CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

注意:
インストールが完了したら、Oracle Clusterwareの動作中は/tmp/.oracleまたは/var/tmp/.oracle、あるいはそのファイルを手動で削除したり、それらを削除するcronジョブを実行しないでください。これらのファイルを削除すると、Oracle Clusterwareが断続的にハングアップする可能性があり、エラーCRS-0184「CRSデーモンと通信できません。」が発生します。

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

OCRおよび投票ディスク・ファイルをOracle ASMにインストールした場合、グリッド・インフラストラクチャ・インストール所有者として次のコマンド構文を使用し、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を管理することはできません。

4.7 Oracle Clusterwareの機能の確認

インストール後にrootとしてログインし、各ノードで次のコマンド構文を使用して、Oracle Clusterwareインストールが適切にインストールされ、動作していることを確認します。

crsctl check crs

次に例を示します。

$ crsctl check crs

CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

注意:
インストールが完了したら、Oracle Clusterwareの動作中は/tmp/.oracleまたは/var/tmp/.oracle、あるいはそのファイルを手動で削除したり、それらを削除するcronジョブを実行しないでください。これらのファイルを削除すると、Oracle Clusterwareが断続的にハングアップする可能性があり、エラーCRS-0184「CRSデーモンと通信できません。」が発生します。

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

この章では、Oracle Grid Infrastructureソフトウェアをインストールした後に実行する、インストール後の作業について説明します。

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

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

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

- 旧バージョンのOracle Databaseのグリッド・インフラストラクチャでの使用

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

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

インストールを完了したら、次の作業を実行する必要があります。

- パッチの更新のダウンロードおよびインストール

注意:
以前のリリースでは、ddコマンドを使用して投票ディスクをバックアップする作業が、インストール後に必要でした。Oracle Clusterwareリリース11.2以上では、ddコマンドを使用した投票ディスクのバックアップとリストアは投票ディスクの障害につながる可能性があるため、この手順はサポートされていません。

5.1.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. 「パッチと更新版」ページで、「拡張検索」をクリックします。

5. 「拡張検索」ページで「製品または製品ファミリ」フィールドの横にある検索アイコンをクリックします。

6. 「検索と選択:製品ファミリ」フィールドで、「検索リスト」フィールドの「データベースとツール」を選択し、テキスト・フィールドにRDBMS Serverと入力した後、「検索」をクリックします。
RDBMSサーバーが「製品または製品ファミリ」フィールドに表示されます。現行のリリースが「リリース」フィールドに表示されます。

7. 「プラットフォーム」フィールドのリストからプラットフォームを選択して、選択リストの下にある「検索」をクリックします。

8. 「結果」ヘッダーの下に使用可能なパッチの更新が表示されます。

9. パッチ番号をクリックして、パッチをダウンロードします。

10. 「パッチ・セット」ページで「READMEの表示」をクリックして、表示されるページを読みます。  READMEページには、そのパッチ・セットに関する情報と、パッチの適用方法が記載されています。

11. 「パッチ・セット」ページに戻って「ダウンロード」をクリックし、ファイルをシステムに保存します。

12. Oracle Database 11gリリース2(11.2)で提供された解凍ユーティリティを使用して、My Oracle SupportからダウンロードしたOracleのパッチ更新を解凍します。unzipユーティリティは$ORACLE_HOME/binディレクトリにあります。

13. パッチをインストールする準備としてデータベース・プロセスを停止する方法については、付録Eを参照してください。

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

Oracle Grid Infrastructureをインストールした後で、必要に応じて次の作業を行うことをお薦めします。

- root.shスクリプトのバックアップ

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

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

- RACcheck構成監査ツールの実行

5.2.1 root.shスクリプトのバックアップ

インストールの完了後に、root.shスクリプトをバックアップすることをお薦めします。同じOracleホーム・ディレクトリに他の製品をインストールすると、インストーラは、インストール中に既存のroot.shスクリプトの内容を更新します。元のroot.shスクリプトの情報が必要になった場合は、root.shファイルのコピーから元に戻すことができます。

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

デフォルトのセマフォ・パラメータ値が低すぎて、すべてのOracleプロセスに対応できない場合のみ、次のガイドラインを参照してください。

注意:
セマフォ・パラメータの設定方法の詳細は、オペレーティング・システムのドキュメントを参照することをお薦めします。

1. MAXUPROCを16384に設定します。

2. 「NCARGS」を128に設定します。

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

インストール時、デフォルトでは1つのディスク・グループの作成が可能です。スタンドアロン・サーバー用のOracle Database、またはOracle RACデータベースを追加しようとする場合は、データベース・ファイルの高速リカバリ領域を作成する必要があります。

5.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ストレージ管理者ガイド』

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

高速リカバリ・ファイル・ディスク・グループを作成するには、次の手順を実行します。

1. Gridホームのbinディレクトリに移動し、Oracle ASM Configuration Assistant(ASMCA)を起動します。次に例を示します。

$ cd /u01/app/11.2.0/grid/bin
$ ./asmca

2. ASMCAが開き、「ディスク・グループ」タブが表示されます。新しいディスク・グループを作成するには、「作成」をクリックします。

3. 「ディスク・グループの作成」ウィンドウが開きます。
「ディスク・グループ名」フィールドに、高速リカバリ領域グループの説明的な名前を入力します。たとえば、FRAです。

「冗長性」セクションで、適用する冗長レベルを選択します。

「メンバー・ディスクの選択」フィールドで、高速リカバリ領域に追加する適切なディスクを選択し、「OK」をクリックします。

4. 「ディスク・グループの作成」ウィンドウが開き、ディスク・グループの作成が完了したというメッセージが表示されます。「OK」をクリックします。

5. 「終了」をクリックします。

5.2.4 RACcheck構成監査ツールの実行

Oracle RACのインストールを確認するために、RACcheck監査ツールを実行することをお薦めします。RACcheckは、Oracle Real Application Clusters、Oracle Clusterware、Oracle Automatic Storage ManagementおよびOracle Grid Infrastructure環境の様々な重要な構成設定の確認を行うOracle RACの監査ツールです。

RACcheckユーティリティの構成および実行の詳細は、次のURLにあるMy Oracle SupportのNote 1268927.1を参照してください。

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

5.3 旧バージョンのOracle DatabaseのGrid Infrastructureでの使用

次の項で、11gリリース2(11.2)のOracle Grid InfrastructureインストールでOracle Databaseの旧リリースを使用する場合について説明します。

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

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

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

- Oracle Databaseリリース9.2のためのグローバル・サービス・デーモン(GSD)の有効化

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

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

Oracle Databaseリリース9.2、リリース10.xおよびリリース11.1を、Oracle Clusterware 11gリリース2 (11.2)とともに使用できます。

ただし、以前のリリースはOracle ACFSを使用するように設計されていないため、Oracle Databaseリリース11.2より前のOracle DatabaseホームをOracle ACFSに配置することはできません。

Oracle Clusterwareの既存のバージョンをアップグレードする場合、既存のデータベースの必要な構成は自動的に行われます。ただし、クラスタ用Oracle Grid Infrastructureの新規インストールを完了し、11.2より前のバージョンのOracle Databaseをインストールする場合は、追加の構成作業を手動で行う必要があります。

注意:
リリース11.1.0.7、11.1.0.6および10.2.0.4からアップグレードする場合は、Oracle RACまたはOracle DatabaseインストールをOracle Clusterwareリリース11.2インストールで起動する前に、アップグレード元となるリリース用の最新の推奨パッチを確認し、必要に応じてアップグレード前にそれらのパッチをインストールすることをお薦めします。
推奨パッチの詳細は、My Oracle SupportのNote 785351.1から入手可能な「Oracle Upgrade Companion」を参照してください。

https://support.oracle.com

各リリースの推奨パッチの最新リストについては、Note 756388.1および756671.1でも参照できます。

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

旧バージョンのOracle DatabaseおよびOracle RACデータベースをOracle Grid Infrastructureにインストールするときに、ASM Configuration Assistant(ASMCA)を使用して、ディスク・グループを作成および変更します。11g リリース2以上では、Oracle ASMはOracle ClusterwareとともにOracle Grid Infrastructureのインストールの一部としてインストールされます。Database Configuration Assistant(DBCA)を使用してOracle ASMで管理タスクを実行することはできなくなりました。

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

前のバージョンのOracleソフトウェアがインストールされていないクラスタにOracle Clusterware 11gリリース11.2をインストールすると、Oracle Database 10gおよび11.1では永続的な構成が必要であるにもかかわらず、クラスタ・ノードは動的にOracle Databaseリリース11.2以上と互換性があるよう構成されます。ノード名とノード番号を関連付けるこの手順を固定と呼びます。

注意:
アップグレード中、すべてのクラスタ・メンバー・ノードには自動的に固定されるため、既存のデータベースに対して手動で固定する必要はありません。この手順は、Oracle Grid Infrastructureリリース11.2ソフトウェアをインストールした後、旧バージョンのデータベースをインストールする場合にのみ必要です。

旧バージョンの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/11.2.0/grid/bin/olsnodes -t -n
node1 1       Pinned
node2 2       Pinned
node3 3       Pinned
node4 4       Pinned

特定のノードの状態を表示する場合:

olsnodes -t -n node3

次に例を示します。

# /u01/app/11.2.0/grid/bin/olsnodes -t -n node3
node3 3       Pinned

関連項目:
ノードの固定および固定解除の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

5.3.4 Oracle Databaseリリース9.2のためのグローバル・サービス・デーモン(GSD)の有効化

デフォルトでは、グローバル・サービス・デーモン(GSD)は無効になっています。Oracle Database 9iリリース2(9.2)をクラスタ用Oracle Grid Infrastructure 11gリリース2(11.2)にインストールする場合は、GSDを有効にする必要があります。Oracle Databaseリリース9.2をインストールする前に、次のコマンドを使用してGSDを有効にします。

srvctl enable nodeapps -g
srvctl start nodeapps

5.3.5 適切なLSNRCTLコマンドの使用

lsnrctlコマンドを使用して11gリリース2のローカル・リスナーおよびSCANリスナーを管理するには、環境変数$ORACLE_HOMEにOracle Grid Infrastructureホーム(Gridホーム)のパスを設定します。以前のリリースで使用していたOracleホームの位置からlsnrctlコマンドを使用しないでください(この位置は新しいリリースでは使用できません)。

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

インストール後にOracle Clusterware構成の変更が必要になった場合は、Gridホームをロック解除する必要があります。

たとえば、個別パッチを適用する場合や、Oracle Exadata構成を変更して、デフォルトのUDPを使用するかわりにインターコネクト上でRDS経由のIPCトラフィックを実行する場合は、Gridホームのロック解除が必要になります。

注意:
実行可能ファイルを再リンクする前に、Oracleホーム・ディレクトリで実行されている、再リンク対象の実行可能ファイルをすべて停止する必要があります。また、Oracle共有ライブラリにリンクされているアプリケーションも停止してください。

次の手順に従って、ホームをロック解除します。

1. パスGrid_home/crs/installに移動し(Grid_homeはGridホームのパスです)、コマンドrootcrs.pl -unlock -crshome Grid_homeを使用して、Gridホームをロック解除します(Grid_homeは使用しているグリッド・インフラストラクチャ・ホームのパスです)。たとえば、Gridホームが/u01/app/11.2.0/gridの場合、次のコマンドを入力します。

# cd /u01/app/11.2.0/grid/crs/install
# perl rootcrs.pl -unlock -crshome /u01/app/11.2.0/grid

2. ユーザーをOracle Grid Infrastructureソフトウェア所有者に変更し、コマンド構文make -f Grid_home/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

注意:
バイナリを再リンクする場合、グリッド・インストール所有者に変更して、コマンドGrid_home/bin/relinkを実行することも可能です。

3. 次のコマンドを使用して、Gridホームを再度ロックし、クラスタを再起動します。

# perl rootcrs.pl -patch

4. 各クラスタ・メンバー・ノードで、手順1から3を繰り返します。

6 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 RestartからOracle Clusterwareへの移行

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

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

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

- Oracle ClusterwareとOracle ASMの削除

関連項目:
個々の製品を削除する場合は、要件および制限について製品固有のドキュメントを参照してください。

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

次のような場合に、インストールされたコンポーネントを削除します。

- 学習環境またはテスト環境のいずれかで、Oracle Clusterwareを正常にインストールした後、Oracle Clusterwareインストールを削除する必要がある場合。

- Oracle Clusterwareのインストールまたはアップグレード中、またはその後にエラーが発生し、インストールを再試行する場合。

- ハードウェア障害またはオペレーティング・システム障害のため、インストールまたはアップグレードが停止した場合。

- Oracle Clusterwareを再インストールするようにOracleサポート・サービスからアドバイスされた場合。

6.2 Oracle RestartからOracle Clusterwareへの移行

Oracle Restart(スタンドアロン・サーバー用のOracle Grid Infrastructureインストール)を使用するOracle Databaseインストールがあり、そのサーバーをクラスタ・メンバー・ノードとして構成する場合は、次の作業を行います。

注意:
この手順では、リリース11.2.0.2以上で使用可能なOracle Clusterware構成ウィザードを使用します。

1. 次の構文でsrvctlを使用してOracle Restartの構成を調べます(ここで、db_unique_nameはデータベースの一意の名前で、lsnrnameはリスナー名です)。
srvctl config database -d db_unique_name

srvctl config service -d db_unique_name

srvctl config listener -l lsnrname

サーバーの構成情報を書き留めます。

2. Gridホーム/crs/installに移動します。次に例を示します。

# cd /u01/app/11.2.0/grid/crs/install

3. 手順1で確認したすべてのデータベース、サービスおよびリスナーを停止します。

4. すべてのOracle ACFSファイルシステムをマウント解除します(存在する場合)。

5. 次のコマンドを使用して、スタンドアロン・サーバー用のOracle Grid Infrastructureインストールを構成解除し、削除します。

# roothas.pl -deconfig -force

6. このマニュアルの説明に従って、Oracle Clusterware構成のためにサーバーを準備します。

7. Oracle Grid Infrastructureインストール所有者として、Oracle Clusterware構成ウィザードを実行し、レスポンス・ファイルを保存してステージングします。次に例を示します。

$ Grid_home/crs/config/config.sh -silent -responseFile $HOME/GI.rsp

8. Oracle Clusterware構成ウィザードでroot.shを実行します。

9. Oracle Restartディスク・グループをマウントします。

10. volenableコマンドを実行し、すべてのOracle Restartディスク・グループ・ボリュームを有効にします。

11. 手動ですべてのOracle ACFSファイルシステムをマウントします。

12. 手順1で記録した情報を使用して、Oracle ClusterwareサービスをOracle Clusterwareホームに戻します。Oracle ACFSリソースも戻します。次に例を示します。

/u01/app/grid/product/11.2.0/grid/bin/srvctl add filesystem -d /dev/asm/db1  -g ORestartData -v db1 -m /u01/app/grid/product/11.2.0/db1 -u grid

13. 手順1で記録した構成情報を使用して、クラスタ用Oracle Grid InfrastructureでサポートされるようにOracle Databaseを追加します。次のコマンド構文を使用します。db_unique_nameはノード上のデータベースの一意の名前、nodenameはノード名です。
srvctl add database -d db_unique_name -o $ORACLE_HOME -x nodename

たとえば、データベース名がmydb、サービスがmyserviceの場合は、次のコマンドを入力します。

srvctl add database -d mydb -o $ORACLE_HOME -x node1

14. srvctl add serviceコマンドを使用して、各サービスをデータベースに追加します。次に例を示します。

srvctl add service -d mydb -s myservice

6.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.pl -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.pl -patch

クラスタ用Oracle Grid Infrastructure所有者で、次を実行します(ここで、Grid_homeはOracle Grid Infrastructureホームのパスです)。

オペレーティング・システムのパッチを適用したときやオペレーティング・システムのアップグレードをした後は毎回、Oracle ClusterwareとOracle ASMのバイナリを再リンクする必要があります。

以前のリリースからアップグレードする場合に、以前のリリースのGridホームを削除するには、まず以前のリリースのGridホームをロック解除する必要があります。以前のリリースのホームからコマンドrootcrs.pl -unlockを実行し、以前のリリースのGridホームをロック解除します。スクリプトが完了したら、削除コマンドを実行できます。

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

リリース11.2.0.3以降では、クラスタ用Oracle Grid Infrastructure(クラスタ用に構成されているOracle ClusterwareおよびOracle ASM)をインストールした後、Gridホームのパスを変更する必要がある場合は、次の例に従って、既存のGridホームでデタッチして、新しいGridホームをアタッチします。

注意:
Gridホームを変更する前に、再リンクしているGridホーム・ディレクトリで実行されるすべての実行可能ファイルを停止する必要があります。また、Oracle共有ライブラリにリンクされているアプリケーションも停止してください。

1. Oracle Grid Infrastructureインストール所有者(grid)として次のコマンドを実行し、既存のGridホームをデタッチします(/u01/app/11.2.0/gridは既存のGridホームの場所です)。

$ cd /u01/app/11.2.0/grid/oui/bin
$ ./detachhome.sh -silent -local -invPtrLoc /u01/app/11.2.0/grid/oraInst.loc

2. rootとして、古いGridホームの場所から新しいGridホームの場所にグリッド・バイナリを移動します。たとえば、古いGridホームが/u01/app/11.2.0/gridで、新しいGridホームが/u01/app/gridの場合は次のようにします。

# mv /u01/app/11.2.0/grid /u01/app/grid

3. 『Oracle Clusterware管理およびデプロイメント・ガイド』のOracle Clusterwareのクローニングによるクラスタの作成(手順3: 各宛先ノードでのclone.plスクリプトの実行)に関する説明に記載されている手順を使用して、Oracle Grid Infrastructureインストールをクローニングします。
Grid_home/clone/binディレクトリに移動してclone.plスクリプトを実行するときに、新しいGridホームにパス情報を提供する入力パラメータに値を指定します。

4. 再度rootで次のコマンドを入力し、新しいホームの場所で起動します。

# cd Grid_home/rdbms/install/
# ./rootadd_rdbms.sh
# cd Grid_home/crs/install
# perl rootcrs.pl -patch -destcrshome /u01/app/grid

5. 各クラスタ・メンバー・ノードで、手順1から4を繰り返します。

Gridホームを移動するたびに、Oracle ClusterwareとOracle ASMのバイナリを再リンクする必要があります。

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

rootcrs.plコマンドで-deconfig -forceフラグを指定して実行すると、インストールしたバイナリを削除せずに、1つ以上のノードでOracle Clusterwareを構成解除できます。この機能は、あるノードでオペレーティング・システム・パッケージの欠落など、インストール時にroot.shコマンドを実行する際、1つ以上のクラスタ・ノードでエラーが発生した場合に役立ちます。インストール・エラーが発生したノードでrootcrs.pl -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/11.2.0/grid/crs/install

3. -deconfig -forceフラグを指定してrootcrs.plを実行します。次に例を示します。

# perl rootcrs.pl -deconfig -force

必要に応じて他のノードで繰り返します。

4. クラスタ内のすべてのノードでOracle Clusterwareを構成解除する場合は、最後のノードで次のコマンドを入力します。

# perl rootcrs.pl -deconfig -force -lastnode

-lastnodeフラグを指定すると、OCRおよび投票ディスクを含む、クラスタの構成解除が完了します。

6.6 Oracle ClusterwareとOracle ASMの削除

deinstallコマンドによって、Oracle ClusterwareおよびOracle ASMをサーバーから削除できます。次の項では、このコマンドと、それを使用するための追加オプションについて説明します。

- 削除ツールについて

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

- 失敗したインストールで使用するための削除ツールのダウンロード

- 削除ツールの実行

- Oracle ClusterwareとOracle ASMの削除コマンドの例

- クラスタ用グリッド・インフラストラクチャの削除パラメータ・ファイルの例

注意:
Oracleソフトウェアを削除するには、同じリリースの削除ツールを使用する必要があります。以前のリリースのOracleソフトウェアを削除するとき、それより新しいリリースの削除ツールは使用しないでください。たとえば、既存の11.2.0.4OracleホームにあるOracleソフトウェアを削除するとき、12.1.0.1のインストール・メディアに収録されている削除ツールは実行しないでください。

6.6.1 削除ツールについて

削除ツール(deinstall)は、Oracleソフトウェアを停止し、Oracleソフトウェアおよびオペレーティング・システムの構成ファイルを削除します。これは、インストール前にはインストール・メディアから使用可能で、インストール後にはOracleホーム・ディレクトリから使用可能です。パス$ORACLE_HOME/deinstallにあります。この削除ツール・コマンドは、次のURLのOracle Technology Network(OTN)からダウンロードできます。

http://www.oracle.com/technetwork/database/enterprise-edition/downloads

すべてのOracle Database 11gリリース2ソフトウェアとともに削除ツールをダウンロードすることも、単独のアーカイブ・ファイルとしてダウンロードすることもできます。削除ツールを個別にダウンロードするには、ソフトウェア・バージョンの横にある「すべて見る」リンクをクリックします。

削除ツール・コマンドでは、ユーザーが入力した情報およびソフトウェア・ホームから収集した情報を使用してパラメータ・ファイルが作成されます。または、-checkonlyフラグと-oフラグを使用して、deinstallコマンドによって以前に生成されたパラメータ・ファイルを使用することもできます。レスポンス・ファイル・テンプレートを編集して、パラメータ・ファイルを作成することもできます。

削除ツール・コマンドによって、Oracleソフトウェアが停止され、特定のOracleホームのOracleソフトウェアおよびオペレーティング・システムの構成ファイルが削除されます。削除ツールを実行してクラスタ・インストール用Oracle Grid Infrastructureを削除する場合、rootとしてrootcrs.plスクリプトを実行するよう求められます。

注意:
削除コマンドを実行した場合に、構成解除して削除しようとしているホーム以外の登録済ホームが中央インベントリ(oraInventory)に含まれていなければ、削除コマンドは、Oracle RACインストール所有者のOracleベース・ディレクトリ内の次のファイルとディレクトリ・コンテンツを削除します。

- admin

- cfgtoollogs

- checkpoints

- diag

- oradata

- flash_recovery_area

Optimal Flexible Architecture(OFA)構成を使用してインストールを構成することと、Oracleソフトウェアを排他的に使用するためにOracleベースとOracleホームのパスを予約することをお薦めします。Oracleソフトウェアを所有するユーザー・アカウントが所有するOracleベースのこれらの場所に、ユーザー・データが存在する場合、deinstallコマンドによってこのデータは削除されます。

このコマンドでは次の構文を使用します。可変的な内容はイタリック体で示されています。

deinstall -home complete path of Oracle home [-silent] [-checkonly] [-local]
[-paramfile complete path of input parameter property file]
[-params name1=value name2=value . . .] [-o complete path of directory for saving files] -h

デフォルトでは、削除ツールはGridホームのdeinstallディレクトリから実行します。次に例を示します。

$ cd /u01/app/11.2.0/grid/deinstall
$ ./deinstall

削除ツールは、他の場所から実行することも、パラメータ・ファイルを指定して実行することも、ツールを実行するための他のオプションを選択することもできます。

オプションは次のとおりです。

- -home
このフラグは、確認または削除するOracleホームのパスを指定します。削除しようとしているOracleホームでdeinstallコマンドを使用してOracleソフトウェアを削除する場合は、別の場所にパラメータ・ファイルを用意し、-homeフラグは使用しないでください。

deinstallをパス$ORACLE_HOME/deinstallから実行する場合は、実行元となるホームがツールで認識されるため、-homeフラグは不要です。スタンドアロンのツールを使用する場合、-homeは必須です。

- -silent
このフラグを使用すると、コマンドが非対話モードで実行されます。このオプションを指定する場合は、削除または構成解除するOracleホームの構成値が記述されたプロパティ・ファイルが必要です。

プロパティ・ファイルを作成し、必要なパラメータを指定するには、削除ツールのホームまたはOracleホームのresponseフォルダにある、テンプレート・ファイルdeinstall.rsp.tmplを参照してください。

作業中のシステムがある場合は、テンプレート・ファイルを使用するのではなく、-checkonlyフラグを指定してdeinstallコマンドを実行し、プロパティ・ファイルを生成することができます。deinstallコマンドにより、削除および構成解除するOracleホームの情報が検出されます。生成されたプロパティ・ファイルは、-silentオプションで使用できます。

- -checkonly
このフラグを指定すると、Oracleソフトウェアのホーム構成の状態が確認されます。checkonlyフラグを指定してコマンドを実行した場合、Oracleの構成は削除されません。

- -local
このフラグを複数ノードの非共有環境で指定すると、クラスタのOracleソフトウェアの構成が解除されます。

このフラグを指定してdeinstallを実行すると、非共有ホーム・ディレクトリのローカル・ノード(deinstallが実行されたノード)のOracleソフトウェアの構成が解除され、Oracleソフトウェアが削除されます。リモート・ノードでは、Oracleソフトウェアの構成は解除されますが、Oracleソフトウェアは削除されません。

- -paramfile 入力パラメータのプロパティ・ファイルの完全パス
このフラグを指定すると、デフォルト以外の場所にあるパラメータ・ファイルを使用してdeinstallが実行されます。このフラグを使用する場合は、パラメータ・ファイルが存在する場所を完全パスで指定します。削除する予定のOracleホームからdeinstallコマンドを実行している場合、-paramfileフラグを使用する必要はありません。

パラメータ・ファイルのデフォルトの位置は、deinstallの位置によって異なります。

- インストール・メディアまたはステージングの場所: $ORACLE_HOME/inventory/response

- Oracle Technology Network(OTN)から解凍されたアーカイブ・ファイル: /ziplocation/response

- インストール済Oracleホームからの場合(インストール後): $ORACLE_HOME/deinstall/response

- -params [name1=value name2=value name3=value ...]
このフラグをパラメータ・ファイルとともに使用すると、作成済のパラメータ・ファイルに記述された1つ以上の値を上書きできます。

- -o 保存するレスポンス・ファイルのディレクトリの完全パス
このフラグを指定すると、デフォルト以外の場所に、プロパティ・ファイル(deinstall.rsp.tmpl)を保存するパスが指定されます。

パラメータ・ファイルのデフォルトの位置は、deinstallの位置によって異なります。

- インストール・メディアまたはインストール前のステージングの場所: $ORACLE_HOME/

- OTNから解凍されたアーカイブ・ファイル: /ziplocation/response/

- インストール済Oracleホームからの場合(インストール後): $ORACLE_HOME/deinstall/response

- -h
ヘルプ・オプション(-h)を指定すると、コマンドのオプション・フラグに関する追加情報を取得できます。

6.6.2 以前のリリースのGridホームの削除

以前のリリースからアップグレードする場合に、以前のリリースのGridホームを削除するには、rootユーザーとして以前のリリースのGridホームの権限を手動で変更し、deinstallコマンドを実行する必要があります。

次に例を示します。

# 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ホームです。

6.6.3 失敗したインストールで使用するための削除ツールのダウンロード

削除ツール(deinstall)を使用すると、失敗または不完全なインストールを削除できます。Oracle Technology Network(OTN)のWebサイトから個別のダウンロードとして入手できます。

削除ツールをダウンロードするには、次の手順を実行します。

1. 次のURLへ移動します。

http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html

2. 「Oracle Database 11g Release 2」で、削除ツールをダウンロードするプラットフォームの「すべて見る」をクリックします。
このページの終わりで削除ツールをダウンロードできます。

6.6.4 削除ツールの実行

deinstallコマンドは、Oracle Grid Infrastructureのインストール所有者またはOracle Clusterwareを所有するgridユーザーとして実行することをお薦めします。

削除ツールをダウンロード後、必ず次に従っていることを確認します。

- すべてのクラスタ・メンバー・ノードで同一のユーザーが削除ツールを実行する

- ユーザー等価が設定されている

削除ツールを実行するには、次の手順に従います。

1. gridユーザー・ホーム・ディレクトリに削除ツールをダウンロードするかコピーします。

2. 削除バイナリの所有者がgridユーザーであることを確認します。

3. 削除ツールを実行します。

6.6.5 Oracle ClusterwareとOracle ASMの削除コマンドの例

deinstallコマンドを実行すると、システムから削除するOracleソフトウェアのホーム・ディレクトリを指定するように求めるプロンプトが表示されます。プロンプトが表示されたら、さらに情報を入力します。

クラスタ用Oracle Grid Infrastructureホームからdeinstallコマンドを実行するには、次のコマンドを入力します。

$ cd /u01/app/11.2.0/grid/deinstall/
$ ./deinstall

ホームを削除するコマンドを実行する前に、-checkonlyフラグを使用してdeinstallコマンドを実行すると、deinstallパラメータ・ファイルを生成できます。またはレスポンス・ファイル・テンプレートを使用して手動で編集し、deinstallコマンドで使用するパラメータ・ファイルを作成することもできます。

6.6.6 クラスタ用グリッド・インフラストラクチャの削除パラメータ・ファイルの例

-paramfileオプションを指定してdeinstallコマンドを実行し、パラメータ・ファイルで指定した値を使用できます。ノードnode1およびnode2のクラスタ用のパラメータ・ファイルの例を次に示しますが、この例では、クラスタ用Oracle Grid Infrastructureソフトウェアのバイナリ所有者はgrid、Oracle Grid Infrastructureホーム(Gridホーム)はパス/u01/app/11.2.0/gridにあり、Oracleベース(Oracle ASMログ・ファイルやOracle Clusterwareログなどの管理ファイルが格納されたグリッド・インフラストラクチャのOracleベース)は/u01/app/11.2.0/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/11.2.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/11.2.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,"eth1"/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/11.2.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/11.2.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/11.2.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/eth0,n2-vip/255.255.252.0/eth0'

- NETWORKSのインタフェース名の前後:

NETWORKS="eth0"/192.0.2.1\:public,"eth1"/10.0.0.1\:cluster_interconnect VIP1_IP=192.0.2.2

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

この付録では、Oracle Grid Infrastructureのインストールに関するトラブルシューティング情報について説明します。

関連項目:
ドキュメント・ディレクトリにインストール・メディアとともに含まれるOracle Database 11g Oracle RACのドキュメントを参照してください。

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

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

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

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

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

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

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

- AIXでのトラブルシューティング

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

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

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

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

- ストレージ構成の問題

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

次に、インストール中に発生する可能性のある様々なエラーの例を示します。内容は次のとおりです。

- ディスクの取得中にエラーが発生する

- /usr/X11R6/bin/xdpyinfoコマンドを使用して表示色の自動チェックを実行できない

- CRS-5823: エージェント・フレームワークを初期化できない

- サーバーに接続できない(サーバーによって接続を拒否されたか、または表示を開くことができない)

- OUIのノードの選択画面で選択可能なノードがない

- ノードnodenameに到達できない

- PROT-8: 指定したファイルからクラスタ・レジストリにデータをインポートできない

- PRVE-0038: SSH LoginGraceTime設定(致命的: 認証前にタイムアウトした)

- タイムスタンプが未来である

- CRSスタックの起動の待機中にタイムアウトした

ディスクの取得中にエラーが発生する

原因: 存在しない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 fully_qualified_remote_host_name

次に例を示します。

$ xhost somehost.example.com

その後、次のコマンドを入力してください。workstation_nameはワークステーションのホスト名またはIPアドレスです。

Bourne、BashまたはKornシェル:

$ DISPLAY=workstation_name:0.0
$ export DISPLAY

X Windowアプリケーションがローカル・システムで適切に表示されるかどうかを確認するには、次のコマンドを入力します。

$ xclock

モニターにXクロックが表示されます。Xクロックが表示されたら、Xクロックを閉じてOracle Universal Installerを再度起動します。

OUIのノードの選択画面で選択可能なノードがない

原因: Oracle Grid Infrastructureがインストールされていないか、またはOracle Grid Infrastructureサービスが起動および実行されていません。

処置: Oracle Grid Infrastructureをインストールするか、またはOracle Grid Infrastructureのインストールの状態を確認してください。また、ノードを再起動すると問題を解決できる場合があります。

ノードnodenameに到達できない

原因: IPホストが使用不可能です。

処置: 次の手順を実行してください。

1. シェル・コマンドifconfig -aを実行します。このコマンドの出力と/etc/hostsファイルの内容を比較して、ノードIPがリストされていることを確認します。

2. シェル・コマンドnslookupを実行して、ホストが到達可能であるかどうかを確認します。

3. oracleユーザーとして、sshまたはrshを使用してノードへの接続を試行します。パスワードを求められた場合、ユーザー等価関係が正しく設定されていません。

PROT-8: 指定したファイルからクラスタ・レジストリにデータをインポートできない

原因: 既存のOracle Cluster Registryデバイスのパーティションに十分な領域がないため、rootupgrade.shの実行中に移行障害が発生します。確認するには、ログ・ファイル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設定では、ユーザーがログイン完了前に切断される可能性があります。このエラーは、AIXでのSSH接続のデフォルトのタイムアウト値が低すぎるか、LoginGraceTimeパラメータがコメント・アウトされているために発生します。

処置: OpenSSH構成ファイル/etc/ssh/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の構成に使用したスクリプトを再実行します。

関連項目:
第6.5項「バイナリを削除せずに行うOracle Clusterwareの構成解除」

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

-verbose引数を使用してクラスタ検証ユーティリティを実行し、特定のノードに対するクラスタ検証ユーティリティ・コマンドの結果がUNKNOWNになる場合、その原因は、検証時に問題が検出されたかどうかをクラスタ検証ユーティリティで判断できないことにあります。結果が「不明」になる場合の、考えられる原因を次に示します。

- ノードが停止している。

- クラスタ検証ユーティリティで必要な、オペレーティング・システムの共通コマンド・バイナリが、Oracle Grid Infrastructureホームの/binディレクトリまたはOracleホーム・ディレクトリで不足している。

- クラスタ検証ユーティリティを起動したユーザー・アカウントには、ノードでオペレーティング・システムの共通コマンドを実行する権限がない。

- ノードで、オペレーティング・システム・パッチ、または必須パッケージが不足している。

- ノードの最大プロセス数または最大オープン・ファイル数を超えているか、共有メモリー、セマフォなど、IPCセグメントに問題が発生している。

A.3 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転送についてのメッセージが表示されたら、第2.14.4項「表示およびX11転送構成の設定」のタスクを完了し、この問題を解決します。

次のようなエラーが出力される場合もあります。

stty: standard input: Invalid argument
stty: standard input: Invalid argument

これらのエラーは、システム上の隠しファイル(.bashrc、.cshrcなど)にsttyコマンドが含まれている場合に発生します。このエラーが表示された場合は、第2.14.5項「端末出力コマンドが原因のインストール・エラーの回避」を参照してこれらの問題の原因を解決してください。

「ノードからのノード到達可能性チェックが失敗しました。」または「ノード接続性チェックが失敗しました。」

原因: クラスタ内に、TCP/IPプロトコルを使用したパブリックまたはプライベート・インターコネクトで到達できない1つ以上のノードがあります。

処置: /bin/ping addressコマンドを使用して、各ノードのアドレスを確認してください。到達できないアドレスを発見した場合は、パブリックおよびプライベート・アドレスのリストを確認して、それらを正しく構成してください。他社ベンダーのクラスタウェアを使用する場合に役立つ情報については、そのベンダーのドキュメントを参照してください。パブリック・ネットワーク・インタフェースおよびプライベート・ネットワーク・インタフェースのインタフェース名は、クラスタ内の各ノードで同じである必要があります。

「ユーザーの存在チェックが失敗しました。」または「ユーザーとグループの関係チェックが失敗しました」

原因: インストールに必要なユーザーおよびグループの管理権限が付与されていないか、または正しくありません。

処置: 各ノードでidコマンドを使用して、インストール所有者ユーザー(gridやoracleなど)が正しいグループ・メンバーシップで作成されていることを確認してください。必要なグループを作成していることを確認し、影響のあるノードでユーザー・アカウントを作成または変更して、必要なグループ・メンバーシップを設定してください。

関連項目:
必要なグループの作成方法およびインストール所有者ユーザーの構成方法については、2.4項「Oracle Grid Infrastructureのグループ、ユーザーおよびパスの作成」を参照してください。

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

深刻なエラーを見つけるには、まずOracle Grid Infrastructureのアラート・ログを見ます。エラーが発生すると、エラーの原因に関する具体的な情報がある診断ログのパス情報が含まれていることがあります。

重要なイベントが発生した場合には、インストール後に、Oracle Grid Infrastructureがアラート・メッセージを書き込みます。たとえば、Cluster Ready Services(CRS)デーモン・プロセスからのアラート・メッセージは、起動時、中断した場合、フェイルオーバー・プロセスが失敗した場合、CRSリソースの自動再起動が失敗した場合に出力されます。

Oracle Enterprise ManagerはClusterwareのログ・ファイルを監視し、エラーが検出されると「クラスタ・ホーム」ページにアラートを書き込みます。たとえば、投票ディスクが利用できない場合はCRS-1604エラーが発生し、「クラスタ・ホーム」ページにクリティカル・アラートが書き込まれます。「メトリックとポリシー設定」ページで、エラー検出とアラートの設定をカスタマイズできます。

Oracle Grid Infrastructureのログ・ファイルの場所は、CRS_home/log/hostname/alerthostname.logです。CRS_homeはOracle Grid Infrastructureがインストールされたディレクトリ、hostnameはローカル・ノードのホスト名です。

関連項目:
『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

A.5 AIXでのトラブルシューティング

IBM AIXリリース6.1では、次の問題が発生する可能性があります。

Oracle Universal InstallerエラーINS-13001「環境が、最低要件を満たしていません。」およびCLUVFYレポート「このオペレーティング・システムのディストリビューションの前提条件の検証に参照データを使用できません」

原因: 検証済のOSが次のサポート・レベルにあります。

/bin/oslevel
6.1.4.0

/bin/oslevel -s
6100-04-01-0944

この問題は、誤ったオペレーティング・システム・レベルをレポートしているAIXによって発生します。この例では、/bin/oslevelによって戻される値は6.1.0.0です。

処置: AIXパッチIZ64508をインストールして、OSレベルの不具合を修正してください。

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

Oracle Universal Installer (OUI)のノードの選択ページが表示されない場合、Oracle Grid Infrastructureホーム(LinuxおよびUNIXベース・システムの場合はGrid_home/bin、Windowsベース・システムの場合はGrid_home\BIN)のバイナリ・ディレクトリからolsnodes -vコマンドを実行してクラスタウェア診断を実行し、その出力を分析します。クラスタウェアが動作していないことが出力に示された場合は、クラスタウェアのドキュメントを参照してください。

また、次のコマンド構文を使用してクラスタ・マネージャの整合性を検証します。

cluvfy comp clumgr -n node_list -verbose

前述の構文例で、node_list変数は、クラスタ内のノードのカンマ区切りリストです。

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のエントリを作成できます。ただし、/etc/hostsファイルを使用してSCANを解決すると、クラスタ全体に使用可能なSCANは3つではなく1つのみになります。hostsファイル内のSCANの最初のエントリのみが使用されます。

- パブリック・インタフェースと同じサブネットがSCAN VIPで使用されていることを確認してください。

SCAN、SCAN VIPまたはリスナーに関連するエラーのトラブルシューティングについてさらに支援が必要な場合は、My Oracle Supportを参照してください。たとえば、Doc ID 1373350.1のNoteにはSCAN VIPおよびリスナーの最も一般的ないくつかの問題が含まれます。

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

次にストレージ構成の問題を示します。

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

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

Oracle Grid Infrastructureリリース11.2以上では、ファイル・システムを誤って削除した場合、または記憶域の構成に関する別の問題が発生してOracle Local Registryを失うか、あるいはノードを破損した場合、次の2通りの方法のいずれかでノードをリカバリできます。

1. オペレーティング・システム・レベルのバックアップからノードをリストアする(推奨)。

2. ノードを削除した後、ノードを追加する。11.2以上のクラスタでは、プロファイル情報はノードにコピーされ、ノードがリストアされます。

クラスタ内の残りのノードからリストアできるように、クラスタ・ノードを削除して再度追加することを可能にする機能をグリッドのプラグ・アンド・プレイ(GPnP)と呼びます。グリッドのプラグ・アンド・プレイによって、ノードごとの構成データが削減され、明示的にノードを追加したり削除する必要性がなくなります。この機能によって、システム管理者は、テンプレートのシステム・イメージを取得するだけで、それ以上の構成を行わなくても、新しいノードでそのイメージを実行できます。そのため多くの手動操作が不要になり、エラーの発生する可能性が減るだけでなく、構成の変更をより簡単に行えるようになります。ノード単位の構成が排除されると、個々の状態をノードで保持して管理する必要がなくなるため、ノードの交換が容易になります。

グリッドのプラグ・アンド・プレイ機能により、ノード単位の状態が使い捨て可能になることで、データベース・ノードのインストール、構成および管理のコストが削減されます。これによって、再生成された状態でノードを簡単に交換できるようになります。

次のようなaddnode構文を使用してノードのリカバリを開始します。lostnodeは、クラスタに再度追加しているノードです。

グリッド・ネーミング・サービス(GNS)を使用している場合:

$ ./addNode.sh -silent "CLUSTER_NEW_NODES=lostnode"

GNSを使用していない場合:

$ ./addNode.sh -silent "CLUSTER_NEW_NODES={lostnode}" "CLUSTER_NEW_VIRTUAL_HOSTNAMES={lostnode-vip}"

リストアするノードでroot.shスクリプトを実行できるようにし、OCRキーを再作成し、他の構成タスクを実行するには、ルートにアクセスする必要があることに注意してください。/usr/local/binの既存の情報を上書きするプロンプトが表示された場合は、デフォルトを受け入れます。

The file "dbhome" already exists in /usr/local/bin. Overwrite it? (y/n) [n]:
The file "oraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]:
The file "coraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]:

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

この付録では、レスポンス・ファイルを使用してOracle製品をインストールおよび構成する方法について説明します。内容は次のとおりです。

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

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

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

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

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

B.1 レスポンス・ファイルの使用方法

インストーラの起動時にレスポンス・ファイルを使用して、Oracleソフトウェアのインストールと構成を完全にまたは部分的に自動実行できます。インストーラはレスポンス・ファイルに含まれる値を使用して、一部またはすべてのインストール・プロンプトに応答します。

通常、インストーラは対話型で、つまりグラフィカル・ユーザー・インタフェース(GUI)画面で情報の入力を求めながら動作します。この情報をレスポンス・ファイルで提供する場合は、次のいずれかのモードで、コマンド・プロンプトからインストーラを起動します。

- サイレント・モード
レスポンス・ファイルにすべてのプロンプトへの応答を含め、インストーラの起動時に-silentオプションを指定すると、インストーラはサイレント・モードで動作します。サイレント・モードでのインストール中、インストーラは画面上に何も表示しません。かわりに、起動時に使用した端末に進捗情報が表示されます。

- レスポンス・ファイル・モード
レスポンス・ファイルに一部またはすべてのプロンプトへの応答を含めて、-silentオプションを指定しないと、インストーラはレスポンス・ファイル・モードで動作します。レスポンス・ファイル・モードでのインストール中は、レスポンス・ファイルで情報を指定した画面も、レスポンス・ファイルに必要な情報を指定しなかった画面も含めて、インストーラはすべての画面を表示します。

サイレント・モードまたはレスポンス・ファイル・モードでインストールするための設定は、レスポンス・ファイルにリストされた変数に値を入力して定義します。たとえば、Oracleホームの名前を指定するには、次のように、ORACLE_HOME変数に適切な値を入力します。

ORACLE_HOME="OraDBHome1"

レスポンス・ファイルの変数設定を指定するもう1つの方法は、インストーラの起動時にコマンドライン引数として渡す方法です。次に例を示します。

-silent "ORACLE_HOME=OraDBHome1" ...

関連項目:
レスポンス・ファイルの詳細は、『Oracle Universal InstallerおよびOpatchユーザーズ・ガイドfor Microsoft Windows and UNIX Systems』を参照してください。

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

次の表に、インストーラをサイレント・モードまたはレスポンス・ファイル・モードで実行する場合の例を示します。

モード

用途

サイレント

サイレント・モードは次の場合に使用します。

- atなどのオペレーティング・システム・ユーティリティを使用してスケジュールを設定し、自動インストールを実行する。

- ユーザーの介入なしで、複数のシステムで同様のインストールを数回実行する。

- X Window Systemソフトウェアがインストールされていないシステムにソフトウェアをインストールする。

インストーラは起動元の端末に進捗情報を表示しますが、インストーラ画面はまったく表示しません。

レスポンス・ファイル

レスポンス・ファイル・モードは、インストーラ・プロンプトの全部ではなく一部にデフォルトの応答を提供し、複数のシステムに同様のOracleソフトウェア・インストールを行う場合に使用します。
レスポンス・ファイル・モードでは、すべてのインストーラ画面が表示されますが、これらの画面の該当フィールドには、レスポンス・ファイルによってデフォルトの値が入力されます。レスポンス・ファイルで値を指定していないものについては、画面のフィールドに情報を入力する必要があります。

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

次に、インストーラをサイレント・モードまたはレスポンス・ファイル・モードで使用して、Oracle製品をインストールし構成する一般的な手順を示します。

注意:
インストーラをサイレント・モードまたはレスポンス・ファイル・モードで実行する前に、必要なインストール前の手順をすべて終了しておく必要があります。

1. レスポンス・ファイルを準備します。

2. インストーラをサイレント・モードまたはレスポンス・ファイル・モードで実行します。

3. ソフトウェアのみのインストールを終了したら、次にNet Configuration AssistantおよびDatabase Configuration Assistantをサイレント・モードまたはレスポンス・ファイル・モードで実行します。

この手順については、次の項で説明します。

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

この項では、レスポンス・ファイルを準備して、サイレント・モードまたはレスポンス・ファイル・モードのインストールで使用する、次の方法について説明します。

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

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

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

Oracleでは、各製品およびインストール・タイプと各構成ツールに対応する、レスポンス・ファイルのテンプレートを提供しています。ファイルは、インストール・メディアのdatabase/responseディレクトリに格納されています。

注意:
ソフトウェアをハード・ディスクにコピーした場合、レスポンス・ファイルは/responseディレクトリにあります。

表B-1に、このソフトウェアに付属するレスポンス・ファイルを示します。

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

レスポンス・ファイル

説明

db_install.rsp

Oracle Database 11g のサイレント・インストール

dbca.rsp

Database Configuration Assistantのサイレント・インストール

netca.rsp

Oracle Net Configuration Assistantのサイレント・インストール

表B-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. ファイルに記載された説明に従って編集します。

注意:
レスポンス・ファイルを正しく構成しないと、インストーラまたはConfiguration Assistantが失敗します。

4. ファイルの権限を600に変更します。

$ chmod 600 /local_dir/response_file.rsp

注意:
Oracle Databaseのインストールに必要なすべての項目を指定したレスポンス・ファイルには、データベース管理アカウント用のパスワードと、OSDBAグループのメンバーであるユーザー用のパスワード(自動バックアップに必要)が含まれています。Oracleソフトウェア所有者であるユーザーのみがレスポンス・ファイルを参照または変更できるようにするか、インストールの正常終了後にレスポンス・ファイルを削除することを検討してください。

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

インストーラを対話モードで使用してレスポンス・ファイルに記録し、このファイルを編集して完全なサイレント・モードまたはレスポンス・ファイル・モードのインストールに使用できます。この方法は、カスタム・インストールまたはソフトウェアのみのインストールに役立ちます。

Oracle Database 11g リリース2(11.2)以降では、「サマリー」ページで「レスポンス・ファイルの保存」をクリックすると、インストール中のすべてのインストール手順をレスポンス・ファイルに保存できます。生成されたレスポンス・ファイルは、後でサイレント・インストールに使用できます。

レスポンス・ファイルを記録する際は、インストールを最後まで実行することも、またはシステムにソフトウェアをコピーする前に「サマリー」ページで終了することもできます。

レスポンス・ファイル・モードのインストール中に記録モードを使用すると、インストーラは元のレスポンス・ファイルに指定されていた変数値を新しいレスポンス・ファイルに記録します。

注意:
Oracle Universal Installerは、レスポンス・ファイルにパスワードを記録しません。

レスポンス・ファイルを記録するには、次の手順を実行します。

1. 通常のインストールと同様にインストール前の作業を実行します。

2. Oracle Grid Infrastructureソフトウェア所有者ユーザー(通常はgrid)が、インストーラ実行時に指定するOracleホームのパスに対して作成または書込みの権限を持っていることを確認します。

3. インストールの各画面で、必要な情報を指定します。

4. インストーラの「サマリー」画面が表示されたら、次の手順を実行します。

1. 「レスポンス・ファイルの保存」をクリックして、値をレスポンス・ファイルに保存するためのファイル名と場所を指定し、「保存」をクリックします。

2. レスポンス・ファイルを作成してインストールを継続するには、「終了」をクリックします。
レスポンス・ファイルを作成するだけでインストールを継続しない場合は、「レスポンス・ファイルの保存」をクリックした後、「取消」をクリックします。インストールは中断されますが、入力した設定はレスポンス・ファイルに記録されます。

5. 保存したレスポンス・ファイルを別のシステムで使用する前に、ファイルを編集して必要な変更を加えます。
編集する際は、ファイルに記載された説明をガイドとして使用してください。

B.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を指定すると、インストール中にConfiguration Assistantは実行されず、ソフトウェアのみのインストールが実行されます。

- responsefilenameは、構成したインストール用レスポンス・ファイルのフルパスとファイル名です。

5. インストールが終了したら、rootユーザーとしてログインし、root.shスクリプトを実行します。次に例を示します。

$ su root
password:
# /oracle_home_path/root.sh

B.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レスポンス・ファイル・テンプレートのコピー先ディレクトリのフルパスです。

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

Oracleソフトウェアのインストール後にレスポンス・ファイルによる構成を作成して実行するには、次の項の手順を使用します。

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

サイレント・モードまたはレスポンス・ファイル・モードでのインストールを実行する場合は、使用するサーバーについての情報をレスポンス・ファイルに指定します。指定しない情報は、グラフィカル・ユーザー・インタフェースによるインストール中に手動で入力します。ただし、レスポンス・ファイルには、ソフトウェアのインストール後にConfiguration Assistantから要求されるユーザー・アカウントのパスワードは含まれていません。Configuration Assistantは、configToolAllCommandsというスクリプトによって起動されます。パスワード・レスポンス・ファイルを作成して使用すると、このスクリプトをレスポンス・ファイル・モードで実行できます。スクリプトはこのパスワードを使用して、構成が完了するまで連続的に構成ツールを実行します。

クローン・インストール用にこのパスワード・ファイルを保持する場合は、セキュアな場所に保存することをお薦めします。また、エラーを解決するためにインストールを中断する必要がある場合も、configToolAllCommandsおよびパスワード・レスポンス・ファイルを使用して、Configuration Assistantを実行できます。

configToolAllCommandsパスワード・レスポンス・ファイルには、次の構文オプションがあります。

- internal_component_nameは、Configuration Assistantで構成するコンポーネントの名前です。

- variable_nameは、構成ファイルの変数の名前です。

- valueは、構成に使用する値です。

コマンド構文は次のとおりです。

internal_component_name|variable_name=value

次に例を示します。

oracle.assistants.asm|S_ASMPASSWORD=welcome

パスワード・レスポンス・ファイルのセキュリティは、次の方法で維持することをお薦めします。

- レスポンス・ファイルの権限を600に設定します。

- レスポンス・ファイルの所有者をインストール所有者ユーザーにして、グループは中央インベントリ(oraInventory)グループに設定します。

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

configToolAllCommandsスクリプトを使用してConfiguration Assistantを実行するには、次の手順を実行します。

1. 構文filename.propertiesを使用してレスポンス・ファイルを作成します。次に例を示します。

$ touch cfgrsp.properties

2. テキスト・エディタでこのファイルを開き、パスワード・テンプレートを切り取って貼り付け、必要に応じて変更します。

例B-1 クラスタ用Oracle Grid Infrastructureインストールのパスワード・レスポンス・ファイル

Oracle Grid Infrastructureには、Oracle Automatic Storage Management Configuration Assistant(ASMCA)用のパスワードが必要です。この場合、次のレスポンス・ファイルを使用します。

oracle.assistants.asm|S_ASMPASSWORD=password
oracle.assistants.asm|S_ASMMONITORPASSWORD=password

例B-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

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

この付録では、インストール前に実行を要求される作業の理由、およびその他のインストールの概要について説明します。

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

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

- 記憶域の構成の理解

- サーバー・プールの理解

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

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

この項では、クラスタ用Oracle Grid Infrastructureのインストール前に必要な作業の概要を確認します。内容は次のとおりです。

- Oracleグループおよびユーザーの理解

- Oracleベース・ディレクトリのパスの理解

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

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

C.1.1 Oracleグループおよびユーザーの理解

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

- Oracle Inventoryグループの理解

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

C.1.1.1 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グループを確認するには、「Oracle InventoryおよびOracle Inventoryグループの存在の確認」を参照してください。

C.1.1.2 Oracle Inventoryディレクトリの理解

Oracle Inventoryディレクトリ(oraInventory)には、サーバーにインストールされたすべてのOracleソフトウェア用の中央インベントリがあります。

Oracleソフトウェアをシステムにはじめてインストールする場合は、oraInventoryディレクトリのパスを入力するように求められます。

インストール時の指示に従ってOracleベースのパスを指定するか、Oracle Grid Infrastructureのインストールを実行しているユーザーに対して環境変数$ORACLE_BASEが設定されている場合は、OUIによってOracle Inventoryディレクトリがパス$ORACLE_BASE/../oraInventoryに作成されます。たとえば、$ORACLE_BASEが/opt/oracle/11に設定されている場合は、すべてのインストールの中央インベントリがこの特定のOracleインストール・ユーザーのOracleベースの外部になるように、パス/opt/oracle/oraInventoryにOracle Inventoryディレクトリが作成されます。

パスの入力も、ORACLE_BASEの設定も行わなければ、Oracle Inventoryディレクトリはインストールを実行しているユーザーのホーム・ディレクトリに格納されます。次に例を示します。

/home/oracle/oraInventory

この配置によって、複数のOracleソフトウェア所有者で後続のインストールを行うときに権限エラーが発生する可能性があるため、このオプションを受け入れずにOFA準拠のパスを使用することをお薦めします。

新規インストールの場合は、OFA準拠の構造でOracleパス(/u01/app/oraInventoryなど、所有者がOracleソフトウェア所有者)を作成するか、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ベースは各ユーザーに個別に存在します。

C.1.2 Oracleベース・ディレクトリのパスの理解

この項では、Oracleベース・ディレクトリの準備について説明します。

C.1.2.1 Oracleベース・ディレクトリの概要

インストール時に、Oracleベースの場所を指定するように求められます。Oracleベースは、インストールを実行するユーザーが所有します。既存のOracleホームが含まれるディレクトリを選択するか、またはOracleベース・ディレクトリの構造を持っていない別のディレクトリを選択できます。

Oracleベース・ディレクトリ・パスを使用すると、Oracleインストールの構造が簡略化され、複数のデータベース・インストールでOptimal Flexible Architecture(OFA)構成を保持しやすくなります。

C.1.2.2 Oracleベース・ディレクトリとグリッド・インフラストラクチャ・ディレクトリの理解

Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)のインストールとOracle Databaseのインストールに同じソフトウェア所有者を使用しない場合でも、Oracle Grid Infrastructureのインストールでroot.shスクリプトを実行することによって、クラスタウェア・バイナリが配置されるホーム・ディレクトリの所有権がrootに変更されることに注意してください。また、ルート・レベル(/)までのすべての祖先ディレクトリもrootに変更されます。このため、クラスタ用Oracle Grid Infrastructureのホームは、他のOracleソフトウェアと同じ場所に置くことができません。

ただし、スタンドアロン・データベース用のOracle Grid Infrastructure(Oracle Restart)は、他のOracleソフトウェアと同じ場所に配置できます。

関連項目:
Oracle Restartの詳細は、使用しているプラットフォームのOracle Databaseインストレーション・ガイドを参照してください。

C.1.3 ネットワーク・アドレスの理解

インストール時に、OUIがクラスタ・ノードで検出するネットワーク・インタフェースごとに計画された使用方法を指定するように求められます。各インタフェースを、パブリック・インタフェースまたはプライベート・インタフェース、あるいはOracle Clusterwareで使用しないインタフェースとして指定します。パブリックIPアドレスと仮想IPアドレスは、パブリック・インタフェース上に構成されます。プライベート・アドレスはプライベート・インタフェース上に構成されます。

各アドレス・タイプの詳細は、次の項を参照してください。

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

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

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

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

- SCANについて

C.1.3.1 パブリックIPアドレスについて

パブリックIPアドレスは、DHCPを使用して動的に割り当てられるか、DNSまたはホスト・ファイルで静的に定義されます。パブリック・インタフェース(クライアントからアクセス可能なインタフェース)が使用されます。

C.1.3.2 プライベートIPアドレスについて

Oracle Clusterwareは、プライベートとマークされたインタフェースを使用してノード間通信を行います。各クラスタ・ノードは、インストール時にプライベート・インタフェースとして指定されたインタフェースを持つ必要があります。プライベート・インタフェースはそのインタフェース用に構成されたアドレスを持つ必要がありますが、それ以上の構成は必要ありません。Oracle Clusterwareは、プライベートと指定されたインタフェースを、クラスタ・インターコネクトとして使用します。プライベート・ネットワークに関する情報に複数のインタフェースを指定すると、Oracle Clusterwareはそれらを冗長インターコネクトを使用して構成します。プライベートとして指定するインタフェースはいずれも、クラスタのすべてのノードに接続するサブネット上に存在しなければなりません。Oracle Clusterwareは、プライベート・インタフェース用に指定された、すべてのインタフェースを使用します。

プライベート・インターコネクトの場合は、ノード間のキャッシュ・フュージョンおよびその他のトラフィックのため、物理的に別のプライベート・ネットワークを使用することをお薦めします。DNSを使用してアドレスを構成する場合は、プライベートIPアドレスがクラスタ・ノードからのみ到達可能であることを確認する必要があります。

インストール後、CLUSTER_INTERCONNECTS初期化パラメータを使用してOracle RACのインターコネクトを変更する場合は、パブリックIPアドレスで使用されていないサブネット上で、パラメータをプライベートIPアドレスに変更する必要があります。パブリック・サブネットとして指定したサブネットを使用するインタフェースにインターコネクトを変更することはできません。

プライベート・ネットワークIPアドレスを使用したネットワークではファイアウォールを使用しないでください。プライベート・ネットワークIPアドレスによってインターコネクト・トラフィックがブロックされる可能性があるためです。

C.1.3.3 仮想IPアドレスについて

仮想IP(VIP)アドレスは、GNSまたはDNSに登録されています。次の要件を満たすVIPのアドレスを選択します。

- IPアドレスとホスト名は、現在未使用である(DNSに登録できるが、pingコマンドでアクセスできない)

- VIPはパブリック・インタフェースと同じサブネット上にある

C.1.3.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管理およびデプロイメント・ガイド』を参照してください。

C.1.3.5 SCANについて

Oracle Database 11gリリース2のクライアントは、SCANを使用してデータベースに接続します。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 11gリリース2 (11.2)にアップグレードすると、SCANが使用可能になり、SCANを使用してOracle Database 11gリリース2以降のデータベースに接続する必要があります。以前のバージョンのOracle DatabaseをアップグレードするとSCANリスナーに登録されるため、クライアントがSCANを使用してそのデータベースに接続できるようになります。データベースはinit.oraファイルのリモート・リスナー・パラメータを通じてSCANリスナーに登録されます。REMOTE_LISTENERパラメータは、SCAN:PORT形式で設定する必要があります。HOST=SCANとしてSCANが指定された1つのアドレスのTNSNAMES別名は設定しないでください。

SCANはほとんどのデプロイメントでオプションです。ただし、Oracle Database 11gリリース2以上でサーバー・プールを使用しているポリシー管理データベースを使用しているクライアントは、SCANを使用してデータベースにアクセスする必要があります。これは、ポリシー型管理のデータベースは異なるサーバーで異なる時刻に実行されることがあるためです。そのため、あるポリシー型管理のデータベースの特定ノードの仮想IPアドレスへの接続はできません。

C.1.4 ネットワークの時刻要件の理解

Oracle Clusterware 11gリリース2(11.2)には、クラスタ時刻同期化サービス(CTSS)が自動的に構成されます。このサービスでは、デプロイしたクラスタのタイプに最適な同期方法で、すべてのクラスタ・ノードが自動的に同期されます。NTPなどの既存のクラスタ同期サービスがある場合、このサービスはオブザーバ・モードで開始されます。既存のサービスがない場合、このサービスはアクティブ・モードで開始され、クラスタ・ノード間の時刻の同期を確実にします。CTSSで互換性の問題が発生することはありません。

CTSSモジュールはOracle Grid Infrastructureのインストールの一環としてインストールされます。CTSSデーモンはOHASデーモン(ohasd)によって起動されるため、コマンドライン・インタフェースは必要ありません。

C.2 記憶域の構成の理解

- Oracle Automatic Storage Managementクラスタ・ファイル・システムの理解

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

- スタンドアロンのOracle ASMインストール環境からクラスタ化されたOracle ASMインストール環境への変換について

C.2.1 Oracle Automatic Storage Managementクラスタ・ファイル・システムの理解

Oracle Automatic Storage Managementは、拡張されて汎用ファイル・システムであるOracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)を含むようになりました。Oracle ACFSは、複数のプラットフォームに対応するスケーラブルな新しいファイル・システムとしてストレージを管理します。このテクノロジにより、Oracle Automatic Storage Management(Oracle ASM)機能は、Oracle Databaseの外で保持されているカスタマ・ファイルをサポートするように拡張されます。Oracle ACFSがサポートするファイルには、アプリケーション・バイナリ、アプリケーション・レポートなどがあります。他にも、ビデオ、オーディオ、テキスト、イメージ、設計図、その他の汎用アプリケーションのファイル・データがサポートされます。

C.2.2 既存のOracle ASMインスタンスの移行について

以前のリリースのOracle ASMが、サーバー上または既存のOracle Clusterwareインストール環境内にインストールされている場合は、パスGrid_home/binにあるOracle Automatic Storage Management Configuration Assistant (ASMCA)を使用して、既存のOracle ASMインスタンスをOracle ASM 11gリリース2(11.2)にアップグレードし、その後で障害グループ、ASMボリュームおよびOracle Automatic Storage Management Cluster File System (Oracle ACFS)を構成できます。

注意:
既存のOracle ASMインスタンスのアップグレードは、そのノード上のすべてのデータベース・インスタンスおよびアプリケーションを停止してから実行する必要があります。

インストール時に、Oracle ASMを使用することを選択したときに、以前のOracle ASMバージョンが別のホームにインストールされていることがASMCAで検出された場合は、Oracle ASM 11gリリース2(11.2)のバイナリをインストールした後に、ASMCAを起動して既存のOracle ASMインスタンスをアップグレードできます。次に、Oracle ASMボリュームを作成し、アップグレードしたOracle ASMを使用してOracle ACFSを作成することで、Oracle ACFSのデプロイメントを構成できます。

Oracle ClusterwareまたはOracle RACの既存のインストール環境で、すべてのノード上のOracle ASMインスタンスの旧バージョンがOracle ASM 11gリリース1の場合は、Oracle ASMインスタンスのローリング・アップグレードを実行できます。Oracle RACのインストール環境で、旧バージョンのOracle ASMインスタンスがOracle ASM 11gリリース1よりも前のリリースの場合は、ローリング・アップグレードを実行できません。Oracle ASMは、すべてのノードで11gリリース2(11.2)にアップグレードされます。

C.2.3 スタンドアロンのOracle ASMインストールからクラスタ化されたインストールへの変換について

クラスタのメンバー・ノードの中に、既存のスタンドアロンのOracle ASMがインストールされているノードが1つ以上ある場合でも、OUIは、クラスタ用のOracle Grid Infrastructureのインストールを開始します。

Oracle Clusterwareファイル(OCRおよび投票ディスク)をOracle ASM上に配置すると、クラスタウェアのインストール終了時にASMCAが起動し、ローカル・ノード上のOracle ASMインスタンスを移行およびアップグレードするためのプロンプトが表示され、Oracle ASM 11gリリース2(11.2)環境が作成されます。

リモート・ノードでスタンドアロンのOracle ASMインスタンスが実行されていることをASMCAが認識すると、そのOracle ASMインスタンスと、そのOracle ASMインスタンスを使用しているデータベース・インスタンスを停止するように求められます。次に、ASMCAは、クラスタ化されたOracle ASMインスタンスをクラスタ内のすべてのノードに展開します。ただし、クラスタ対応のOracle ASMインスタンスのディスク・グループ名は、既存のスタンドアロンのディスク・グループ名と異なっている必要があります。

関連項目:
『Oracle Databaseストレージ管理者ガイド』

C.3 サーバー・プールの理解

次の項で、サーバー・プールの概要を簡単に説明します。内容は次のとおりです。

- サーバー・プールおよびポリシー・ベース管理の概要

- サーバー・プールの動作

- 空きサーバー・プール

- 汎用サーバー・プール

関連項目:
サーバー・プールの構成および管理の方法については、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

C.3.1 サーバー・プールおよびポリシー・ベース管理の概要

Oracle Clusterware 11g リリース2(11.2)以上では、Oracle Clusterwareが管理するリソースは、サーバー・プールという、サーバーの論理グループに格納されます。リソースは共有インフラストラクチャ上でホスト指定され、サーバー・プールに格納されます。リソースは、ポリシーによってハードウェア・リソース(CPUやメモリーなど)の使用量にのみ制限され、単一システム環境にデプロイされているように動作します。

リソースは、サーバー・プールを使用して動的に管理することで、クラスタ内のリソースをポリシー・ベースで管理することができます。また、特定のノードで実行するように物理的にリソースを割り当てる従来の方法で管理することもできます。

注意:
デフォルトでは、すべての名前付きユーザーがサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するには、CRS管理者リストに特定のユーザーを追加することをお薦めします。

関連項目:
CRS管理者リストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

Oracle Grid Infrastructureのインストール所有者には、SRVCTL、Oracle Enterprise Manager Database ControlまたはOracle Database Configuration Assistant(DBCA)を使用して、サーバー・プールを作成および構成する権限があります。

ポリシー・ベースの管理:

- 必要時に動的な容量の割当てが可能で、ポリシーで設定した優先度に従ってサーバーの容量を指定できます。

- 重要度ごとにリソースの割当てが可能で、アプリケーションが可能なかぎり必要最小限のリソースを取得できます。また、優先度が低いアプリケーションが、より重要なアプリケーションのリソースを消費しないようにすることもできます。

- 必要時には分離が保証され、アプリケーションとデータベースについて、クラスタの専用サーバーを指定できます。

サーバー・プールで実行しているアプリケーションとデータベースは、リソースを共有しません。このため、サーバー・プールは必要に応じてリソースを分離しますが、必要時は動的な容量の割当てが可能です。役割区分による管理とともにこの機能を使用することで、標準化されたクラスタ環境を持つ組織のニーズに対応できますが、複数の管理者グループが共通のクラスタ・インフラストラクチャを共有できるようになります。

C.3.2 サーバー・プールの動作

サーバー・プールは、クラスタを同じまたは類似したリソースのホスティングするサーバーのグループに分割します。サーバー・プールによって、クラスタの複数のサーバーに対し、統一されたワークロード(一連のOracle Clusterwareリソース)が分散されます。たとえば、Oracle Databaseが特定のサーバー・プールのみで実行されるように制限できます。役割区分管理を有効にすると、特定のサーバー・プールの属性を変更する権限をオペレーティング・システム・ユーザーに明示的に付与できます。

最上位のサーバー・プール:

- クラスタを論理的に分割します。

- 常に排他的です。これは、1つのサーバーが特定の時期に1つの特定のサーバー・プールにのみ存在できることを意味します。

各サーバー・プールには、作成時に割り当てられる3つの属性があります。

- MIN_SIZE: サーバー・プールに含まれるサーバーの最小数。サーバー・プール内のサーバーの数がこの属性値を下回る場合、Oracle Clusterwareは、サーバーの数がこの属性値に達するまで、またはより重要性の低いプールに空きサーバーがなくなるまで、他のサーバー・プールからこのサーバー・プールにサーバーを自動的に移動します。

- MAX_SIZE: サーバー・プールに含まれるサーバーの最大数。

- IMPORTANCE: クラスタ内のすべてのサーバー・プールをランク付けする、0から1000の数値(0は重要性が最も低いことを示す)。

Oracle Clusterwareをインストールすると、汎用サーバー・プールと空きサーバー・プールという2つのサーバー・プールが自動的に作成されます。はじめは、新規インストールのすべてのサーバーは空きサーバー・プールに割り当てられます。空きサーバー・プールにあるサーバーは、新しく定義したサーバー・プールに自動的に移動します。Oracle Clusterwareをアップグレードすると、すべてのノードが汎用サーバー・プールに割り当てられます。これによって、Oracle Database 11g リリース2(11.2)より前のデータベース・リリースとの互換性が保証されます。

C.3.3 空きサーバー・プール

空きサーバー・プールには、他のサーバー・プールに割り当てられないサーバーが含まれます。空きサーバー・プールの属性は、次のように制限されます。

- SERVER_NAMES、MIN_SIZEおよびMAX_SIZEをユーザーが編集することはできません。

- IMPORTANCEおよびACLはユーザーが編集できます。

関連項目:
『Oracle Clusterware管理およびデプロイメント・ガイド』

C.3.4 汎用サーバー・プール

汎用サーバー・プールには、11g リリース2(11.2)より前のデータベース、および管理者が管理する構成が固定されたデータベースが格納されます。また、次のいあずれかを満たすサーバーも含まれます。

- アプリケーション・リソース・タイプのすべてのリソースのHOSTING_MEMBERS属性で指定したサーバー

- 汎用サーバー・プールを親サーバー・プールとするサーバー・プールのSERVER_NAMES属性で指定した名前を持つサーバー

汎用サーバー・プールの属性は、次のように制限されています。

- 汎用サーバー・プールの構成属性は誰も変更できません(すべての属性は読取り専用です)。

- HOSTING_MEMBERS属性でサーバー名を指定した場合、サーバーが次の状態であるときにOracle Clusterwareはその名前を許可します。

- オンラインで汎用サーバー・プールに存在する。

- オンラインで空きサーバー・プールに存在する。この場合、Oracle Clusterwareによってサーバーが汎用サーバー・プールに移動されます。

- オンラインで、他のサーバー・プールに存在し、クライアントがCRS管理者(サーバー・プールのリソース管理を制御するユーザー・ロール)であるか、またはサーバー・プールのサーバーを使用することが許可されている。この場合、サーバーは汎用サーバー・プールに移動されます。

- オフラインで、クライアントがCRS管理者の場合。

- 子サーバー・プールを汎用サーバー・プールに登録した場合、リソースに対して以前に指定したものと同じ要件をサーバー名が満たす場合にのみ、Oracle Clusterwareはその子サーバー・プールを許可します。
サーバーは、クラスタの起動時またはサーバーがクラスタに追加されるときに汎用サーバー・プールに割り当てられ、その後で、他のサーバー・プールに割り当てられます。

C.4 アウトオブプレース・アップグレードの理解

アウトオブプレース・アップグレードでは、インストーラは新しいバージョンを別のOracle Clusterwareホームにインストールします。Oracle Clusterwareの新旧バージョンが各クラスタ・メンバー・ノードに存在することになりますが、アクティブになるバージョンは1つのみです。

ローリング・アップグレードは、ソフトウェアの新バージョンへのアップグレード中、停止時間をなくし、可用性の継続を保証します。

各ノード上に別々のOracle Clusterwareホームがある場合、すべてのノードでアウトオブプレース・アップグレードを行うか、またはアウトオブプレース・ローリング・アップグレードを行うことができます。そうすることで、あるノードでは旧バージョンのOracle ClusterwareホームからOracle Clusterwareを実行し、別のノードでは新バージョンのOracle ClusterwareホームからOracle Clusterwareを実行することが可能です。

Oracle Clusterware 11gリリース2のインプレース・アップグレードはサポートされていません。

関連項目:
ローリング・アップグレードの実行手順については、付録E「Oracle Grid Infrastructure 11gリリース2へのアップグレード方法」を参照してください。

D インストールの前提条件の作業を手動で行う方法

この付録では、通常Cluster Verification Utility(CVU)およびインストーラ(OUI)がインストール時に完了する構成作業を、手動で行う方法について説明します。この付録は、修正スクリプトを使用できないときに参考にしてください。

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

パスワードなしのSSH構成は、必須のインストール要件です。SSHは、インストール時にクラスタ・メンバー・ノードの構成に使用され、またインストール後にはConfiguration Assistant、Oracle Enterprise Manager、Opatchおよび他の機能によって使用されます。

OUIを使用したパスワードなしのSSHの自動構成によって、クラスタのすべてのノード上にRSA暗号化キーが作成されます。システム上の制約により、DSA鍵を使用するなどして手動でSSHを設定することが求められる場合は、この手順を参考にして、パスワードなしのSSHを設定してください。

この後の例では、Oracleソフトウェア所有者をgridユーザーとしています。

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

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

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

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

D.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を構成します。

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

SSHを構成するには、最初に各クラスタ・ノードにRSA鍵およびDSA鍵を作成してから、すべてのクラスタ・ノード・メンバーで生成されたすべての鍵を各ノードで同じ認証鍵ファイルにコピーする必要があります。SSHファイルを読み取ることができのは、rootおよびソフトウェア・インストール・ユーザー(oracle、grid)のみである必要があります。これは、SSHが他のユーザーによってアクセス可能であると、SSHは秘密鍵を無視するためです。この後の例では、DSA鍵が使用されています。

インストールに使用するOracleソフトウェアのインストール所有者ごとにSSHを構成する必要があります。

SSHを構成するには、次の手順を実行します。

D.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を実行します。

D.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ファイルのすべての内容が含まれている必要があります。

D.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転送が有効になっていることを示しています。この問題を解決するには、第2.14.4項「表示および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 Oracle Grid Infrastructure 11gリリース2へのアップグレード方法

この付録では、Oracle ClusterwareおよびOracle Automatic Storage Managementのアップグレードの実行方法について説明します。

Oracle Clusterwareのアップグレードでは、ローリング・アップグレードが可能です。ローリング・アップグレードでは、他のノードはアクティブなまま、ノードのサブセットを停止してアップグレードします。Oracle Automatic Storage Management 11gリリース2(11.2)のアップグレードでは、ローリング・アップグレードが可能です。ノードのサブセットをアップグレードする場合は、アップグレードの対象として選択しなかった既存のクラスタ・ノードでソフトウェアのみのインストールが実行されます。

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

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

- Oracle環境変数の設定の削除

- Oracle ASMおよびOracle Grid Infrastructureのインストールおよびアップグレードについて

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

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

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

- 前のリリースからのローリング・アップグレードの実行

- DB ControlおよびGrid Controlのターゲット・パラメータの更新

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

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

- アップグレード後のクラスタ状態モニターのリポジトリ・サイズの確認

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

Oracleソフトウェアを変更する前に、Oracleソフトウェアおよびデータベースのバックアップを作成することをお薦めします。

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

Oracle環境変数の設定を削除します。

環境変数にORA_CRS_HOMEを設定した場合は、Oracle Supportの指示に従って、インストールまたはアップグレードを開始する前に、その設定を削除します。Oracleサポートから明示的に指示がないかぎり、ORA_CRS_HOMEを環境変数として使用しないでください。

インストール所有者のログイン・シェル・プロファイル(.profileや.cshrcなど)にORA_CRS_HOMEが設定されていないことを確認します。

システムに既存のインストール環境があり、同じユーザー・アカウントを使用して今回のインストールを行う場合、環境変数ORA_CRS_HOME、ORACLE_HOME、ORA_NLS10、TNS_ADMIN、またはOracleソフトウェア・ホームに接続されているOracleインストール・ユーザーに対して設定されたその他の環境変数の設定を削除します。

E.3 Oracle ASMおよびOracle Grid Infrastructureのインストールおよびアップグレードについて

以前のリリースでは、Oracle Automatic Storage Management(Oracle ASM)はOracle Databaseインストールの一部としてインストールされました。Oracle Database 11gのリリース2(11.2)では、Oracle ASMはOracle Grid Infrastructureコンポーネントをインストールするときにインストールされ、Oracle RACやスタンドアロン・サーバーでOracle RestartとともにクラスタにインストールされたときにOracle ClusterwareとOracleホームを共有します。

既存の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 Configuration Assistant(ASMCA)を使用すると、Oracle ASMインスタンスにアウトオブプレース・アップグレードを実行できます。Graphic User Interfaceを使用する以外に、非対話型(サイレント)モードでもASMCAを実行できます。

以前のリリースでは、Oracle DatabaseまたはOracle ASMにアップグレードするためにDatabase Upgrade Assistant(DBUA)を使用できました。現在では使用できません。DBUAを使用できるのは、Oracle Databaseインスタンスをアップグレードするときのみです。Oracle ASMをアップグレードするには、Oracle ASM Configuration Assistant(ASMCA)を使用します。

関連項目:
既存のOracle ASMインストールのアップグレードについては、『Oracle Databaseアップグレード・ガイド』および『Oracle Database Storage管理者ガイド』を参照してください。

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

CVUを使用して、既存のOracle Grid Infrastructure 11gリリース2またはOracle RACデータベース11gリリース2のインストールをアップグレードするのに必要なパッチがあるかどうかを確認することをお薦めします。

関連項目:
「CVUを使用した、Oracle Clusterwareのアップグレードに対する準備状況の検証」

Oracle ClusterwareおよびOracle Automatic Storage Management(Oracle ASM)で構成されるOracle Grid Infrastructure環境へのアップグレードには、次の制限と変更点があることに注意してください。

- 既存のOracle ClusterwareインストールをOracle Grid Infrastructure 11gにアップグレードするには、リリースが10.1.0.3、10.2.0.3、11.1.0.6、11.2以上である必要があります。

- 既存のOracle Grid Infrastructureを11.2.0.2から11.2.0.3以上にアップグレードするには、パッチ11.2.0.2.1(11.2.0.2 PSU 1)以上を適用する必要があります。

- 既存の11.1のOracle ClusterwareインストールをOracle Grid Infrastructure 11.2.0.3以上にアップグレードするには、リリース11.1のOracle Clusterwareホームにバグ7308467のパッチを適用する必要があります。

- Oracle Grid Infrastructure 11g リリース2(11.2.0.1)にOracle ACFSファイル・システムがある場合は、Oracle Grid Infrastructureを新しいバージョン(11.2.0.2または11.2.0.3)にアップグレードし、冗長インターコネクトを使用して、1つ以上のプライベート・インタフェースをプライベート・ネットワークに追加し、その後、アップグレードされた各クラスタ・メンバー・ノードでOracle ASMインスタンスを再起動する必要があります。

- Gridホームのディレクトリは削除しないでください。たとえば、Grid_home/Opatchを削除しないでください。このディレクトリを削除すると、グリッド・インフラストラクチャ・インストール所有者はOpatchを使用してGridホームにパッチを適用できず、Opatchによって「checkdirエラー: Grid_home/OPatchを作成できません」というエラーが表示されます。

- 既存の11.2.0.1 Oracle Grid InfrastructureインストールをOracle Grid Infrastructure 11.2.0.2にアップグレードするには、まず、アップグレードを正常に実行するのに必須のパッチを適用する必要があるかどうかを確認する必要があります。準備状況を確認する手順の詳細は、「CVUを使用した、Oracle Clusterwareのアップグレードに対する準備状況の検証」を参照してください。

関連項目:
My Oracle SupportのNote 785351.1「Oracle 11gR2 Upgrade Companion」
https://support.oracle.com

- 既存のOracle Grid Infrastructureを11.2.0.2から11.2.0.3以上にアップグレードするには、パッチ11.2.0.2.1(11.2.0.2 PSU 1)以上を適用する必要があります。

- 既存の11.1のOracle ClusterwareインストールをOracle Grid Infrastructure 11.2.0.3以上にアップグレードするには、リリース11.1のOracle Clusterwareホームにバグ7308467のパッチを適用する必要があります。

- Oracle ClusterwareおよびOracle ASMのアップグレードは、常にアウトオブプレース・アップグレードで行われます。11gリリース2(11.2)では、Oracle ClusterwareおよびOracle ASMのインプレース・アップグレードを既存のホームに対して実行することはできません。

- 既存のOracle Clusterwareホームが共有ホームの場合、Oracle ClusterwareおよびOracle ASM 11gリリース2(11.2)のクラスタ用Oracle Grid Infrastructureホームに、共有されていないホームを使用できます。

- Oracle Clusterware 11g リリース1以上では、Oracle Clusterware 10g ソフトウェアを所有していた同じユーザーがOracle Clusterware 11g のアップグレードを実行する必要があります。Oracle Database 11gより前は、すべてのOracleソフトウェアのインストールをOracleユーザー(通常はoracle)が所有していたか、またはOracle Databaseソフトウェアはoracleが所有し、Oracle Clusterwareソフトウェアは別のユーザー(通常はcrs)が所有していました。

- Oracle ASMとOracle Clusterwareの両方がOracle Grid Infrastructureホームで実行されます。

- 11gリリース2(11.2)へのメジャー・バージョン・アップグレード中、11gリリース2(11.2)のOracle Grid Infrastructureホームにあるソフトウェアは、アップグレードが完了するまで完全には機能しません。最終的にrootupgrade.shスクリプトが実行され、すべてのノードでアップグレードが完了するまで、11gリリース2(11.2)ホームからのsrvctl、crsctl、その他コマンドの実行はサポートされません。
Oracle Grid Infrastructureのアップグレード中に既存の旧バージョン(リリース10.xまたは11.1)のデータベース・ホームを管理するには、既存のデータベース・ホームからsrvctlを使用します。

- Oracle Clusterwareのインストール中に、シングル・インスタンスのOracle ASMがローカル・ノードに存在する場合、そのOracle ASMはクラスタ化されたOracle ASM 11gリリース2(11.2)に変換され、Oracle ASMはすべてのノードのOracle Grid Infrastructureホームで実行されます。

- ローカル・ノード(Oracle Grid Infrastructureのインストールを実行中のノード)以外のリモート・ノードにシングル・インスタンスの(クラスタ化されていない)Oracle ASMがインストールされている場合は、シングル・インスタンスのOracle ASM環境がそのまま維持されます。ただし、インストール中に、Oracle Cluster Registry(OCR)および投票ディスクのファイルをOracle ASMに置くように選択した場合は、クラスタ化されたOracle ASMのインストール環境がクラスタ内のすべてのノードに作成され、リモート・ノードにインストールされているシングル・インスタンスのOracle ASMは機能しなくなります。

関連項目:
『Oracle Databaseアップグレード・ガイド』

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

既存のOracle Clusterwareインストールがある場合は、アウトオブプレース・アップグレードを行うことにより、既存のクラスタをアップグレードします。インプレース・アップグレードは実行できません。

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

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

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

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

アップグレードを開始する前に、次の作業を行います。

1. 各ノードで、クラスタ検証ユーティリティを使用して、インストール前の手順が完了していることを確認します。サーバーの準備をするための修正スクリプトを生成することができます。また、インストーラでは、必要な前提条件をすべて満たしていることが確認されます。
次の情報を含めて、インストール時に必要な情報がすべて揃っていることを確認します。

- Oracle ClusterwareのOracleベースの場所。

- 既存のOracle Clusterwareの場所とは異なる、Oracle Grid Infrastructureホームの場所。

- SCANアドレス。

- Oracle ASMデータ・ファイルへのアクセス権(ASMグループのOSDBA)、Oracle ASMインスタンスに対する管理権限(OSASMグループ)、Oracle ASMインスタンスに対する管理権限のサブセット(ASMグループのOSOPER)を付与する権限を持つユーザー・オペレーティング・システム・グループ。

- インストール中にrootとしてスクリプトを実行するためのrootユーザー・アクセス。

2. インストールを実行するインストール所有者に関しては、既存のインストールに対して環境変数が設定済の場合は、$ORACLE_HOMEおよび$ORACLE_SIDの設定を解除します。これらの環境設定がアップグレード中に使用されてしまうからです。次に例を示します。

$ unset ORACLE_BASE
$ unset ORACLE_HOME
$ unset ORACLE_SID

3. AIX HACMPベンダー・クラスタウェアがOracle Clusterwareリリース11.1 (11.1.0.7)上にある場合は、次の手順を実行します。

1. OUIに求められた際、rootpre.shを実行しないでください。

2. InstallタイプにUpgradeを選択し、アップグレードを完了します。求められた際にrootupgrade.shを実行しないでください。

3. 第1ノードで、Oracle Clusterwareをrootでシャットダウンします。rootpre.shを実行し、エラーがないことを確認します。次にrootupgrade.shを実行します。

4. 最後のノード以外の各ノードで、ステップcをrootで実行します。

5. 最後のノードで、ステップcをrootで順次実行します。

6. 最後のノードでrootupgrade.shが正常に完了したら、OUIに戻り、残りのアップグレード手順を続行します。

E.5.2 Oracle RACcheckアップグレード準備状況評価の実行

RACcheck (Oracle RAC構成監査ツール)アップグレード準備状況評価は、Oracle Grid Infrastructure 11.2.0.3、11.2.0.4および12.1.0.1にアップグレードする際のアップグレード固有のヘルス・チェックを自動的に行うために使用できます。RACcheckアップグレード準備状況評価ツールを実行すると、多数のアップグレード前およびアップグレード後のチェックを自動化できます。

My Oracle SupportからRACcheckの最新バージョンをダウンロードして実行することをお薦めします。RACcheck構成監査ツールのダウンロード、構成および実行方法の詳細は、My Oracle SupportのNote 1457357.1を参照してください(次のURLから入手可能)。

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

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

クラスタがアップグレードできる状態であることを検証するには、この項の内容を確認します。

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

runcluvfy.shコマンドがあるアップグレードのステージング領域に移動し、runcluvfy.sh stage -pre crsinst -upgradeコマンドを実行してアップグレードに対するOracle Clusterwareインストールの準備状況を確認します。-pre crsinst -upgradeフラグを指定してruncluvfy.shを実行すると、既存のクラスタウェア・インストールのアップグレードに対してクラスタが適切な状態にあるかどうかを確認するためのシステム・チェックが実行されます。

このコマンドでは次の構文を使用します。可変的な内容はイタリック体で示されています。

runcluvfy.sh stage -pre crsinst -upgrade [-n node_list] [-rolling] -src_crshome
src_Gridhome -dest_crshome dest_Gridhome -dest_version dest_version
[-fixup[-fixupdir path]] [-verbose]

オプションは次のとおりです。

- -n nodelist
-nフラグはクラスタ・メンバー・ノードを示し、nodelistはアップグレード前の検証を実行する非ドメイン修飾ノード名のカンマ区切りのリストを示します。検証コマンドに-nフラグを追加しない場合は、クラスタ内のすべてのノードが検証されます。runcluvfy.shを実行しているノードでクラスタウェアが停止している場合は、-nフラグを追加する必要があります。

- -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 path]
-fixupフラグは、クラスタがアップグレードできる状態であることを確認するのに実行する必要がある手順の指示を生成することを指定します。デフォルトの場所は、CVUの作業ディレクトリです。別のディレクトリに修正指示を配置する場合は、-fixupdirフラグを追加して、必要な修正指示を配置するディレクトリ・パスを指定します。

- -verbose
-verboseフラグを使用すると、個々のチェックの詳細な出力が生成されます

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

次のコマンドを実行すると、Oracle Clusterwareのインストールに必要な権限が、ノードnode1およびnode2で構成されているかどうかを検証できます。

$ ./runcluvfy.sh stage -pre crsinst -upgrade -n node1,node2 -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

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

クラスタ検証ユーティリティを使用すると、データベースのアップグレードを開始する前準備として、システムをチェックできます。インストーラによって適切なCVUチェックが自動的に実行され、問題の修正を求めるプロンプトが表示されるか、またはアップグレードを進める前にクラスタ内のすべてのノード上で実行するための修正スクリプトが提供されます。

関連項目:
『Oracle Databaseアップグレード・ガイド』

E.7 前のリリースからのローリング・アップグレードの実行

Oracle ClusterwareまたはOracle Automatic Storage Managementをアップグレードするには、次の手順を実行します。

- Oracle Clusterwareのローリング・アップグレードの実行

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

注意:
Oracle Clusterware 11gリリース2(11.2)にアップグレードすると、Oracle Automatic Storage Management(Oracle ASM)がOracle Clusterwareと同じホームにインストールされます。このホームは、Oracleドキュメントでは、グリッド・インフラストラクチャ・ホームまたはGridホームと呼ばれます。また、ローリング・アップグレード中に、ノードをクラスタに追加する操作はサポートされていません。

E.7.1 Oracle Clusterwareのローリング・アップグレードの実行

Oracle Clusterwareを前のリリースから新しいリリースにアップグレードするには、次の手順を実行します。

注意:
Oracle RACインスタンスは、実行したままにしておくことをお薦めします。各ノードでrootupgrade.shスクリプトを起動すると、そのノードのインスタンスが停止され、そのスクリプトによって再度起動されます。
クラスタ上のスタンドアロンのOracle Databaseは、Oracle ASMを使用する場合のみ、停止が必要です。リスナーを停止する必要はありません。

1. インストーラを起動し、インストールされている既存のOracle ClusterwareおよびOracle ASMをアップグレードするオプションを選択します。

2. ノード選択ページで、すべてのノードを選択します。

注意:
Oracle Clusterware 11gリリース2より前のリリースとは対照的に、すべてのノードをアップグレード対象に選択したとしても、アップグレードはすべてローリング・アップグレードになります。リリース11.2.0.1から11.2.0.2にアップグレードする場合は、デフォルトですべてのノードが選択されます。ノードを選択したり、選択解除することはできません。
すべてのクラスタ・メンバー・ノードをアップグレード対象として選択し、アップグレードのrootスクリプトを実行する前に各ノードでデータベース・インスタンスを停止し、アップグレードの完了後に各ノードでデータベース・インスタンスを再度起動することをお薦めします。この手順を実行して、クラスタのノードのサブセットをアップグレードすることもできます。

3. 指示どおりに、インストール・オプションを選択します。
AIX HACMPベンダー・クラスタウェアがインストールされている場合は、手順4に進みます。

HACMPクラスタがない場合は、アップグレード対象のクラスタ内にある各ノードでrootupgrade.shスクリプトを実行します。スクリプトにより、以前のリリースのインストールが停止されて新しいOracle Clusterwareリリースに置き換えられ、新しいOracle Clusterwareインストールが起動されます。ノードでrootupgrade.shスクリプトが実行された後、アップグレードされたOracle ClusterwareスタックおよびAUTOSTARTリソースがノードで起動されます。ローリング・アップグレードを実行する各ノードで、rootupgrade.shスクリプトを実行します。まず、ローカル・ノード上でスクリプトを実行します。スクリプトが正常に完了したら、最後のノードとして選択した1つを除いて、すべてのノード上で並行してスクリプトを実行できます。最後のノードを除いたすべてのノード上でスクリプトが正常に実行されたら、最後のノード上でスクリプトを実行します。

HACMPクラスタがない場合は、手順9に進みます。

4. Oracle ClusterwareクラスタにAIX HACMPベンダー・クラスタウェアがある場合は、クラスタ内の1つのノードでインストーラを起動し、既存のOracle ClusterwareおよびOracle ASMインストールをアップグレードするオプションを選択します。

5. HACMPクラスタの場合、クラスタ内のクラスタ・ノードにある以前のリリースのOracle Clusterwareソフトウェア・スタックを停止します。

6. 停止するクラスタ・ノードでrootpre.shスクリプトを実行します。このスクリプトは、前のリリースのインストール環境を停止し、新しいOracle Clusterwareリリースに置き換えて、新しいOracle Clusterwareのインストールを開始します。

7. ノードでrootpre.shスクリプトが実行された後、Oracle Grid Infrastructure 11.2のrootupgrade.shスクリプトを実行します。ノード上で、アップグレードしたOracle ClusterwareスタックとAUTOSTARTリソースが起動されます。

8. 各HACMPクラスタ・メンバー・ノードで、手順5から7を繰り返します。

9. クラスタの最後のノードでrootupgrade.shスクリプトを実行した後、チェック・ボックスでASMCAがマークされている(デフォルト)ままにすると、ASM Configuration Assistantが自動的に実行し、Oracle Clusterwareのアップグレードが完了します。アップグレードのインタビュー・ステージでボックスのマークを外すと、ASMCAは自動的には実行しません。

前のバージョンのOracle Automatic Storage Managementがインストールされている場合、Oracle ASMを11gリリース2(11.2)へアップグレードするために、インストーラによってASM Configuration Assistantが起動されます。Oracle ASMをこのときにアップグレードするか、または後でアップグレードするか、選択することができます。

Oracle Clusterwareバイナリをアップグレードするのと同時に、Oracle ASMもアップグレードすることをお薦めします。ASMがアップグレードされるまで、ASMを使用するOracle Databaseは作成できません。ASMがアップグレードされるまで、Gridホームにある11gリリース2(11.2)のASM管理ツール(srvctlなど)は動作しません。

10. Oracle Grid Infrastructureホームは、以前のOracle ClusterwareホームおよびOracle ASMホームとは異なる場所にあるため、Oracle ClusterwareホームおよびOracle ASMホームにあるユーティリティ、ライブラリなどのファイルを使用するスクリプトまたはアプリケーションを更新します。

注意:
アップグレードの最後に、OCRのバックアップ場所を前のリリースのOracle Clusterwareホーム(CRSホーム)に手動で設定していた場合は、Oracle Grid Infrastructureホーム(Gridホーム)に変更する必要があります。OCRのバックアップ場所を手動で設定しなかった場合は、この問題は関係がありません。
Oracle Clusterwareのアップグレードはアウトオブプレース・アップグレードなので、前のリリースのOracle ClusterwareホームをOCRのバックアップ場所にすることはできません。前のOracle Clusterwareホームにあるバックアップは、削除されることがあります。

E.7.2 Oracle Automatic Storage Managementのローリング・アップグレードの実行

Oracle Clusterware 11gリリース2(11.2)のアップグレードが完了した後、Oracle Clusterwareのアップグレード時にOracle ASMのアップグレードをしなかった場合は、Oracle Automatic Storage Managementコンフィギュレーション・アシスタント(asmca)を使用して、ローリング・アップグレードを別途行うことができます。

asmcaを使用してアップグレードを別途行うことはできますが、Oracle Clusterwareのアップグレード後すぐに行う必要があります。Oracle ASMがアップグレードされるまでsrvctlなどのOracle ASM管理ツールが機能しないためです。

注意:
前のバージョンのOracle ASMが11.1.0.6または11.1.0.7の場合のみ、ASMCAによってローリング・アップグレードが行われます。そうでない場合、ASMCAによって通常のアップグレードが行われ、このアップグレードでは、ASMCAによって、クラスタのすべてのノードにおいて、すべてのOracle ASMインスタンスが停止され、新しいGridホームですべて再起動されます。

E.7.2.1 Oracle ASMをアップグレードするための準備

Oracle ASMのローリング・アップグレードを実行する場合は、次の点に注意してください。

- Oracle Clusterwareのアクティブなバージョンが、11gリリース2(11.2)である必要があります。次のコマンドを入力して、アクティブなバージョンを確認します。

$ crsctl query crs activeversion

- スタンドアロンのOracle ASM環境を、クラスタ化されたOracle ASM環境へアップグレードできます。ただし、スタンドアロンの既存のOracle ASM環境をアップグレードできるのは、そのOracle ASM環境があるノードからインストールを実行する場合のみです。リモート・ノードにあるシングル・インスタンスのOracle ASM環境をアップグレードすることはできません。

- アップグレード・プロセスを開始する前に、既存のOracle ASM環境で行われているリバランス操作が完了していることを確認する必要があります。

- アップグレード・プロセスの進行中は、Oracle ASMインスタンスをアップグレード状態に変更することになります。このアップグレード状態ではOracle ASM操作が制限されるため、アップグレード・プロセスは開始してすぐに完了する必要があります。Oracle ASMインスタンスがアップグレード状態にあるときに可能な操作は、次のとおりです。

- ディスク・グループのマウントとマウント解除

- データベース・ファイルのオープン、クローズ、サイズ変更または削除

- インスタンスのリカバリ

- 固定ビューおよび固定パッケージの問合せ(固定ビューの問合せと、dbms_diskgroupなどの固定パッケージを使用した匿名PL/SQLブロックの実行は可能です)

E.7.2.2 Oracle ASMのアップグレード

Oracle ASMをアップグレードするには、次の手順を実行します。

1. アップグレードを開始しようとしているノードで、環境変数ASMCA_ROLLING_UPGRADEの値をtrueにします。次に例を示します。

$ export ASMCA_ROLLING_UPGRADE=true

2. Oracle Grid Infrastructure 11gリリース2(11.2)のホームから、ASMCAを起動します。次に例を示します。

$ cd /u01/11.2/grid/bin
$ ./asmca

3. 「アップグレード」を選択します。
ASM Configuration Assistantにより、クラスタ内にあるすべてのノードのOracle ASMが連続してアップグレードされます。

4. アップグレードが完了したら、コマンドを実行して、ASMCA_ROLLING_UPGRADE環境変数の設定を解除します。

関連項目:
Oracle ASMのアップグレード計画の準備に関する追加情報と、Oracle ASMアップグレードの開始、完了、停止については、『Oracle Databaseアップグレード・ガイド』および『Oracle Database Storage管理者ガイド』を参照してください。

E.8 DB ControlおよびGrid Controlのターゲット・パラメータの更新

Oracle Clusterwareリリース2(11.2)は新しい場所(クラスタ用Oracle Grid Infrastructureホーム、またはGridホーム)でOracle Clusterwareホームをアウトオブプレース・アップグレードしたものであるため、いくつかのパラメータ・ファイルでCRS_HOMEパラメータのパスを変更する必要があります。パラメータを変更しないと、DB ControlまたはGrid Controlで、クラスタ・ターゲットの不正などのエラーが発生します。

この問題を解決するには、次の手順を実行します。

1. dbconsoleまたはgridconsoleにログインします。

2. 「クラスタ」タブに移動します。

3. 「監視構成」をクリックします。

4. 「Oracleホーム」の値を新しいGridホームのパスで更新します。

E.9 既存の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.1/grid
#chown -R grid /u01/app/11.2.0.1/grid
#chown grid /u01/app/11.2.0.1

E.10 アップグレード後のOracle Clusterwareのダウングレード

Oracle Clusterware 11gリリース2(11.2)へのアップグレードが成功または失敗した後で、Oracle Clusterwareを前のバージョンにリストアすることができます。

この項のリストア手順では、クラスタウェアの構成をOracle Clusterware 11gリリース2(11.2)のアップグレードをする前の状態までリストアします。11gリリース2(11.2)のアップグレード中またはアップグレード後に実行した構成変更は削除され、リカバリできません。

次の手順にあるローカル・ノードは、rootupgradeスクリプトが実行された最初のノードです。リモート・ノードは、アップグレードされたその他のすべてのノードです。

Oracle Clusterwareを前のリリースにリストアするには、次の手順を実行します。

1. ダウングレード先のリリース用のダウングレード手順を使用します。
11gリリース2(11.2.0.1)より前のリリースにダウングレードする場合:

すべてのリモート・ノード上で、コマンド構文Grid_home/perl/bin/perl/ rootcrs.pl -downgrade [-force]を使用して、11gリリース2(11.2)リソースを停止し、11gリリース2(11.2)スタックを停止します。

注意:
このコマンドによってOCRがリセットされたり、ocr.locが削除されたりすることはありません。

コマンド構文は次のとおりです。

# /u01/app/11.2.0/grid/perl/bin/perl rootcrs.pl -downgrade -oldcrshome -version

次に例を示します。

# /u01/app/11.2.0/grid/perl/bin/perl rootcrs.pl -downgrade -oldcrshome
/u01/app/crs -version 11.1.0.1.0

注意:
Oracle Clusterwareのバージョン・フォーマットが正しく指定されていることを確認します。たとえば、11.1.0.1.0などです。

11gリリース2(11.2)の部分的なインストールまたは失敗したインストールを停止し、Oracle Clusterwareの以前のリリースをリストアするには、このコマンドで-forceフラグを使用します。

11.2.0.1以上のリリースにダウングレードする場合:

コマンド構文/rootcrs.pl -downgrade -oldcrshome oldGridHomePath -version oldGridversionを使用します(oldGridhomepathは以前のリリースのOracle Grid Infrastructureホームへのパス、oldGridversionはダウングレード先のリリース)。次に例を示します。

/rootcrs.pl -downgrade -oldcrshome /u01/app/11.2.0/grid -version 11.2.0.1

11gリリース2(11.2)の部分インストールまたは失敗したインストールを停止して、以前のリリースのOracle Clusterwareをリストアする場合は、このコマンドで-forceフラグを使用します。

2. rootcrs.pl -downgradeスクリプトをすべてのリモート・ノードで実行し終わったら、ローカル・ノードでコマンド構文Grid_home/crs/install/rootcrs.pl -downgrade -lastnode -oldcrshome pre11.2_crs_home -version pre11.2_crs_version [-force]を使用します。pre11.2_crs_homeは前のOracle Clusterwareインストールのホーム、pre11.2_crs_versionは前のOracle Clusterwareインストールのリリース番号です。
次に例を示します。

# /u01/app/11.2.0/grid/crs/install/rootcrs.pl -downgrade  -lastnode -oldcrshome
/u01/app/crs -version 11.1.0.6.0

このスクリプトではOCRがダウングレードされます。11gリリース2(11.2)の部分的なインストールまたは失敗したインストールを停止し、Oracle Clusterwareの以前のリリースをリストアするには、このコマンドで-forceフラグを使用します。

3. グリッド・インフラストラクチャのインストール所有者としてログインし、次のコマンドを実行します(/u01/app/gridはアップグレードされた新しいGridホーム(11.2)です)。

.Grid_home/oui/bin/runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=false ORACLE_HOME=/u01/app/grid

4. グリッド・インフラストラクチャのインストール所有者として、コマンド./runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=true ORACLE_HOME=pre11.2_crs_homeを実行します(pre11.2_crs_homeは以前のOracle Clusterwareインストールのホーム・ディレクトリを表します)。
次に例を示します。

.Grid_home/oui/bin/runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=true ORACLE_HOME=/u01/app/crs

5. 11.2以上のリリースにダウングレードする場合

1. Oracle Grid Infrastructureリリース2 (11.2.0.4)を以前のリリースの11.2にダウングレードする場合、すべてのクラスタ・ノードでrootupgrade.shの実行を完了し、次のコマンドを11.2.0.4 Gridホームから実行します。

acfsroot uninstall

2. 以前のリリースのGridホームから、特権ユーザー(root)として次のコマンドを実行します。

acfsroot install

3. 各ノードで、crsctl start crsコマンドを使用して前のリリースのOracle ClusterwareホームからOracle Clusterwareを起動します。たとえば、前のリリースのホームがcrshome11202である場合は、各ノードで次のコマンドを使用します。
crshome11202/bin/crsctl start crs

11.1以下のリリースにダウングレードする場合

クラスタの各メンバー・ノード上で順に、前のリリースのOracle Clusterwareインストールのホームからroot.shを実行するようプロンプトが表示されます。この作業が終了したら、ダウングレードは完了です。

前のリリースのOracle Clusterwareインストールのホームからroot.shを実行することにより、Oracle Clusterwareスタックが再起動され、以前に古いバージョンでOracle Clusterwareに登録されていたすべてのリソースが起動され、そして前のリリースのOracle Clusterwareスタックを実行するように古い初期化スクリプトが構成されます。

6. 次の環境変数がダウングレード先のリリースのディレクトリを指定するように変更します。

- ORACLE_HOME

- PATH

oratabファイル、およびORACLE_HOME値を設定するすべてのクライアント・スクリプトが、ダウングレードされたOracleホームを指していることを確認する必要があります。

E.11 アップグレード後のクラスタ状態モニターのリポジトリ・サイズの確認

IPD/OSを使用する以前のリリースからOracle Grid Infrastructureリリース2(11.2.0.3以上)にアップグレードする場合は、クラスタ状態モニターのリポジトリ・サイズ(CHMリポジトリ)を確認する必要があります。CHMリポジトリの要件を確認し、より大規模なCHMリポジトリを保持する場合はリポジトリ・サイズを大きくすることをお薦めします。

注意:
Oracle Grid Infrastructureのインストール時に各ノードでroot.shスクリプトを実行すると、以前のIPD/OSリポジトリは削除されます。

デフォルトでは、リリース11.2.0.3以上のCHMリポジトリのサイズは、最小で1GBまたは3600秒(1時間)です。

CHMリポジトリを大きくするには、次のコマンド構文を使用します。RETENTION_TIMEはCHMリポジトリのサイズ(秒数)です。

oclumon manage -repos resize RETENTION_TIME

RETENTION_TIMEは、3600(1時間)より大きく、259200(3日)より小さい値である必要があります。CHMリポジトリ・サイズを大きくする場合は、クラスタのノードごとに選択するリポジトリ・サイズに使用できるローカル領域があることを確認する必要があります。十分な領域がない場合は、リポジトリを共有ストレージに移動できます。

たとえば、リポジトリ・サイズを4時間に設定するとします。

$ oclumon manage -repos resize 14400

索引
A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  R  S  T  U  V  W  X

A

ボリューム・グループのアクティブ化, 3.2.13

AIX

仮想メモリー・マネージャ, 2.11.2

asmcmdエラー, 2.4.3.1 APAR

ダウンロード場所, 2.8

APARダウンロードの場所, 2.8 ASM

複数のデータベース, 2.4.5.1.3

ローリング・アップグレード, E.7.2

障害グループの特性, 3.3.1.1, 3.3.4.1

ASMのためのOSDBAグループの作成, 2.4.5.2.5

ディスク・グループ, 3.3.1.1

障害グループ, 3.3.1.1

例, 3.3.1.1, 3.3.4.1

確認, 3.3.1.1, 3.3.4.1

GPFSではサポートされないファイル, 3.1.6 各ノードのインスタンスの数, 1.3.6, 3.1.1 OSASM管理者またはASM管理者, 2.4.5.1.3 ASM用のOSDBAグループ, 2.4.5.1.3 ディスク・グループの推奨事項, 3.3.1.1 Standard EditionのOracle RACに必要, 3.1.1 標準インストール・タイプに必要, 3.1.1 ローリング・アップグレード, 4.1, 4.1 Oracle Clusterwareファイルに必要な領域, 3.3.1.1 事前構成済データベースに必要な領域, 3.3.1.1 データ・ファイルの記憶域オプション, 3.1.3 Oracle Clusterwareファイルの格納, 3.1.6 ASMグループ

作成, 2.4.5.2.3

ASMCA

Oracle ASMでの旧リリースのOracle Databaseディスク・グループの作成に使用, 5.3.2

ASMSNMP, B.5.2 自動ストレージ管理クラスタ・ファイル・システム,「Oracle ACFS」を参照

概要, C.2.1

B

Bashシェル

デフォルト・ユーザーの起動ファイル, 2.14.3

バイナリ

再リンク, 5.4

Bourneシェル

デフォルト・ユーザーの起動ファイル, 2.14.3

C

Cコンパイラ

要件, 2.7

「Pro*C/C++」も参照

Cシェル

デフォルト・ユーザーの起動ファイル, 2.14.3

中央インベントリ, 2.4.5.1.1

概要, C.1.1.1

中央インベントリ。「OINSTALLグループ」および「Oracle Inventoryグループ」も参照 cfgmgrコマンド, 3.2.10, 3.2.11 ホスト名の変更, 4.1 chdevコマンド, 3.2.10, 3.2.11 checkdirエラー, E.4 RAWディスクのディスク可用性の確認, 3.2.10, 3.2.11 メンテナンス・レベルの確認, 2.8 バージョンの確認, 2.8 chmodコマンド, 3.2.15 chownコマンド, 3.2.15 クライアント

SCANへの接続, C.1.3.5

クローニング

他のノードへのGridホームのクローニング, 4.3

クラスタ構成ファイル, 4.2.2 クラスタ・ファイル・システム

データ・ファイルの記憶域オプション, 3.1.3

クラスタ名

要件, 4.1

クラスタ・ノード

ボリューム・グループのアクティブ化, 3.2.13

RAWディスク・デバイス・グループのインポート, 3.2.12

プライベート・ノード名, 4.1

パブリック・ノード名, 4.1

uidおよびgidの指定, 2.4.5.2.10

仮想ノード名, 4.1

クラスタ時刻同期化サービス, 2.12 クラスタ検証ユーティリティ

修正スクリプト, 2.2

ユーザー等価関係のトラブルシューティング, A.3

クラスタウェア診断, A.6 コマンド

asmca, 3.3.5, 4.2.1, 4.2.1, 5.2.3.2, E.7.2

asmcmd, 2.4.3.1

chmod, 3.2.15

chown, 3.2.15

crsctl, 4.5, 4.7, 5.3.3, E.4, E.7.2.1

dd, はじめに

df, 1.3.1, 1.3.1

groupadd, 2.4.5.2.10

id, 2.4.5.2.10

mkdir, 3.2.15

passwd, 2.4.5.2.10

ping, 2.6.1

rootcrs.pl, 5.4

構成解除オプション, 6.5

rootupgrade.sh, E.4 sqlplus, 2.4.3.1 srvctl, E.4 umask, 2.14.1, 2.14.2 unset, E.5.1 useradd, 2.4.5.2.8, 2.4.5.2.10 xhost, 2.3 xterm, 2.3 新しいディスクの構成, 3.2.10, 3.2.11 ボリューム・グループの作成, 3.2.10, 3.2.11 RAW論理ボリュームの作成, 3.2.9 ボリューム・グループの作成, 3.2.10, 3.2.11 cronジョブ, 4.1 crs_install.rspファイル, B.2.1 CSD

WebSphere MQ用のダウンロード場所, 2.8

ctsdd, 2.12 カスタム・データベース

ASMの障害グループ, 3.3.1.1, 3.3.4.1

ASMを使用する場合の要件, 3.3.1.1

カスタム・インストール・タイプ

選択する理由, 2.4.5.1.2

D

データ・ファイル

個別のディレクトリの作成, 3.2.14, 3.2.15

データ・ファイル・ディレクトリでの権限の設定, 3.2.15

記憶域オプション, 3.1.3

データ消失

ASMによるリスクの最小化, 3.3.1.1, 3.3.4.1

データベース・ファイル

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

データベース

ASM要件, 3.3.1.1

dbaグループ

RAWデバイス・グループ, 3.2.9, 3.2.12

DBCA

Oracle ASMディスク・グループ管理には使用されない, 5.3.2

dbca.rspファイル, B.2.1 Oracle Clusterwareの構成解除, 6.5 デフォルトのファイル・モード作成マスク

設定, 2.14.1, 2.14.2

削除, 6.1 削除, 6.1 サポート終了

RAWディスク, Preface

デバイス番号

メジャー番号の確認, 3.2.10, 3.2.11

dfコマンド, 2.14.3 診断, A.6 Direct NFS

無効化, 3.2.16, 3.2.16

有効化, 3.2.6, 3.2.6

Oracle Databaseに対する有効化, 3.2.3.3

データ・ファイル, 3.2.3

書込みサイズの最小値, 3.2.3.2

ディレクトリ

個別のデータ・ファイル・ディレクトリの作成, 3.2.14, 3.2.15

データ・ファイル・ディレクトリ用権限, 3.2.15

ディスク・グループ

ASM, 3.3.1.1

Oracle ASMディスク・グループの推奨事項, 3.3.1.1

ディスク・グループ

推奨事項, 3.3.1.1

ディスク領域

確認, 2.5

ASMでの事前構成済データベース要件, 3.3.1.1

ディスク

RAWディスクの可用性の確認, 3.2.10, 3.2.11

新しいディスクの構成, 3.2.10, 3.2.11

LVMディスクの確認, 3.2.10, 3.2.11

環境変数DISPLAY

設定, 2.14.3

DNS, A.9

E

エミュレータ

Xエミュレータからのインストール, 2.3, 2.3

enterprise.rspファイル, B.2.1 環境

oracleユーザーの構成, 2.14

環境変数

DISPLAY, 2.14.3

ORACLE_BASE, C.1.1.2

ORACLE_HOME, 2.4.3.1, E.5.1

ORACLE_SID, E.5.1

シェル起動ファイルからの削除, 2.14.3

SHELL, 2.14.3

TEMPおよびTMPDIR, 2.5, 2.14.3

エラー

X11転送, 2.14.4, D.1.3

Opatch使用時のエラー, E.4 /etc/security/limits.soファイル, 2.11.5 Exadata

バイナリの再リンク例, 5.4

例

ASM障害グループ, 3.3.1.1, 3.3.4.1

F

障害グループ

ASM, 3.3.1.1

ASM障害グループの特性, 3.3.1.1, 3.3.4.1

ASM障害グループの例, 3.3.1.1, 3.3.4.1

新機能, はじめに ファイル・モード作成マスク

設定, 2.14.1, 2.14.2

ファイル・システム

データ・ファイルの記憶域オプション, 3.1.3

ファイル・システム, 3.1.7 ファイル

.bash_profile, 2.14.3

dbca.rsp, B.2.1

シェル起動ファイルの編集, 2.14.3

enterprise.rsp, B.2.1

/etc/security/limits.so, 2.11.5

.login, 2.14.3

oraInst.loc, 2.4.1

.profile, 2.14.3

レスポンス・ファイル, B.2

ファイル・セット, 2.7

確認, 2.8

修正スクリプト, 2.2

概要, 1.2

G

ゲートウェイ

「Oracle Messaging Gateway」を参照

gid

既存の確認, 2.4.5.2.10

指定, 2.4.5.2.10

他のノードでの指定, 2.4.5.2.10

グローバリゼーション

サポート, 4.1

GNS

概要, 2.6.2.1

GPFS, 3.1.1

データ・ファイルの記憶域, 3.1.6

Gridホーム

Oracleベースの制限, 2.4.3.1

デフォルトのパス, 2.17

ディスク領域, 2.5

ロック解除, 5.4

グリッド・インフラストラクチャ所有者(grid), 2.4.5.1.1 gridユーザー, 2.4.5.1.1 グループID

既存の確認, 2.4.5.2.10

指定, 2.4.5.2.10

他のノードでの指定, 2.4.5.2.10

グループ

OINSTALLグループの存在の確認, 2.4.1, 2.4.1

他のノードでの同一グループの作成, 2.4.5.2.10, 2.4.5.2.10

ASMグループの作成, 2.4.5.2.3, 2.4.5.2.3

ASMのためのOSDBAグループの作成, 2.4.5.2.5

OSDBAグループの作成, 2.4.5.2.1

OINSTALL, 2.4.1, 2.4.2

OSASM(asmadmin), 2.4.5.1.3

OSDBA(dba), 2.4.5.1.2

ASMのためのOSDBA(asmdba), 2.4.5.1.3

OSDBAグループ(dba), 2.4.5.1.2

ASMのためのOSOPER, 2.4.5.1.3

OSOPERグループ(oper), 2.4.5.1.2

OSOPER(oper), 2.4.5.1.2

インストール所有者ユーザーに必要, 2.4.5.1.1

ユーザー作成時の指定, 2.4.5.2.10, 2.4.5.2.10

NISの使用, 2.4.5, 2.4.5.2.10

H

HACMP, 3.2.7

hagsuserグループへのOracle Grid Infrastructureインストール所有者の追加, 2.16

データベースの記憶域, 3.1.6

デプロイ, 3.2.7.2

アップグレード, 3.2.7.3

空きディスク領域の確認, 2.5

hagsuserグループ

Oracle Grid Infrastructureインストール所有者の追加, 2.16

ハードウェア要件, 2.5 高可用性IPアドレス, 2.6.1 ホスト名

変更, 4.1

有効なホスト名, 4.1

I

IBM WebSphere MQ

要件, 2.7

idコマンド, 2.4.5.2.10 LVMディスクの確認, 3.2.10, 3.2.11 LVMディスクの確認, 3.2.10, 3.2.11 RAWディスク・デバイス・グループのインポート, 3.2.12 importvgコマンド, 3.2.12, 3.2.12 LVMディスクの初期化, 3.2.10, 3.2.11 INS-32026エラー, 2.4.3.1 インストール

cronジョブ, 4.1

グローバリゼーション, 4.1

他のノードへのグリッド・インフラストラクチャ・ホームのクローニング, 4.3

レスポンス・ファイル, B.2

準備, B.2, B.2.2

テンプレート, B.2

サイレント・モード, B.3 クラスタ構成ファイルの使用, 4.2.2 インストール・タイプ

ASM, 3.3.1.1

instfixコマンド, 2.8 インタフェース

プライベート・インターコネクトの要件, C.1.3.2

断続的なハングアップ

ソケット・ファイル, 4.5, 4.7

J

JDK要件, 2.7

役割区分によるユーザー, 2.4.5.1.1

K

Kornシェル

デフォルト・ユーザーの起動ファイル, 2.14.3

L

有効なホスト名, 4.1

limits.soファイル, 2.11.5

ログ・ファイル

インストール時のアクセス方法, 4.2.1

.loginファイル, 2.14.3 lsdevコマンド, 3.2.10, 3.2.11 lslppコマンド, 2.8, 2.8 lspvコマンド, 3.2.10, 3.2.11, 3.2.12, 3.2.12 LVM

ボリューム・グループの作成, 3.2.10, 3.2.11

RAW論理ボリュームの作成, 3.2.9

ボリューム・グループの作成, 3.2.10, 3.2.11

使用可能なディスクの確認, 3.2.10, 3.2.11

メジャー・デバイス番号の確認, 3.2.10, 3.2.11

ボリューム・グループ・デバイスの確認, 3.2.10, 3.2.11

ディスクの初期化, 3.2.10, 3.2.11

ASMの推奨事項, 3.3.1.1

M

メンテナンス・レベル

確認, 2.8

メジャー・デバイス番号

確認, 3.2.10, 3.2.11

マスク

デフォルトのファイル・モード作成マスクの設定, 2.14.1, 2.14.2

メモリー要件, 2.5 メッセージ・ゲートウェイ

「Oracle Messaging Gateway」を参照

複合バイナリ, 2.7 mkdirコマンド, 3.2.15 mkvgコマンド, 3.2.10, 3.2.11 モード

デフォルトのファイル・モード作成マスクの設定, 2.14.1, 2.14.2

複数のデータベース

ASM, 2.4.5.1.3

複数のoracleホーム, 2.4.3.1, 3.2.15 My Oracle Support, 5.1.1

N

Net Configuration Assistant(NetCA)

レスポンス・ファイル, B.4

コマンド・プロンプトでの実行, B.4

netca, 4.2.1 netca.rspファイル, B.2.1 ネットワーク情報サービス

「NIS」を参照

新機能, はじめに NFS, 3.1.7, 3.2.5

データ・ファイル, 3.2.4

Oracle Clusterwareファイル, 3.2.1

バッファ・サイズ・パラメータ, 3.2.5

Direct NFS, 3.2.3

データ・ファイル, 3.2.4

rsize, 3.2.5

NIS

ローカル・ユーザーおよびグループの代替, 2.4.5

nofile

シェル制限, 2.11.5

nproc

シェル制限, 2.11.5

nslookupコマンド, A.9 NTPプロトコル

スルーイング, 2.12

O

OINSTALLグループ

概要, C.1.1.1

oraInst.loc, 2.4.1

既存の確認, 2.4.1

他のノードでの作成, 2.4.5.2.10

OINSTALLグループ。「Oracleインベントリ・グループ」も参照 olsnodesコマンド, A.6 Opatch, E.4 オペレーティング・システム

バージョンの確認, 2.8

クラスタ・メンバーで異なる, 2.7

Oracle ACFSの制限, C.2.1

オペレーティング・システム要件, 2.7 Optimal Flexible Architecture

oraInventoryディレクトリ, C.1.1.2

Oracleベース

Gridホームの禁止, 2.17

Oracleベース・ディレクトリ

概要, C.1.2

GridホームはOracle DatabaseのOracleベースに配置しない, 2.4.3.1

最小ディスク・サイズ, 2.5

Oracle Berkeley DB

制限, 4.4

Oracle Cluster Registry

構成, 4.1

ミラー化, 3.2.1

パーティション・サイズ, 3.2.1

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

Oracle Clusterware

ファイル・システム, 3.1.7

Oracle ASMインスタンスのアップグレード, 1.3.6, 3.1.1

インストール, 4

ローリング・アップグレード, 4.1

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

アップグレード, 3.2.1

Oracle Clusterwareファイル

ASMディスク領域要件, 3.3.1.1

Oracle Clusterwareのインストレーション・ガイド

Oracle Grid Infrastructureインストレーション・ガイドに置換え, はじめに, 4

Oracle Database

データ・ファイル・ディレクトリの作成, 3.2.14, 3.2.15

データ・ファイルの記憶域オプション, 3.1.3

権限を付与されたグループ, 2.4.5.1.2

ASMの要件, 3.3.1.1

Oracle Database Configuration Assistant

レスポンス・ファイル, B.2.1

Oracle Disk Manager

Direct NFS, 3.2.6

Oracle Enterprise Manager

ASMSNMPアカウント, B.5.2

Oracle Grid Infrastructureレスポンス・ファイル, B.2.1 Oracleホーム, 2.4.3.1

ASCIIパスの制限, 4.1

複数のoracleホーム, 2.4.3.1, 3.2.15

Oracle Inventoryグループ

概要, C.1.1.1

既存の確認, 2.4.1

作成, 2.4.2

他のノードでの作成, 2.4.5.2.10

oraInst.locファイル, 2.4.1

Oracle Messaging Gateway

要件, 2.7

Oracle Net Configuration Assistant

レスポンス・ファイル, B.2.1

Oracleパッチの更新, 5.1.1 Oracleソフトウェア所有者ユーザー

説明, 2.4.5.1.1

Oracleソフトウェア所有者ユーザー

環境の構成, 2.14

作成, 2.4.3, 2.4.3.2, 2.4.5.2.6, 2.4.5.2.7

他のノードでの作成, 2.4.5.2.10

デフォルトのシェルの確認, 2.14.3

RAWデバイス所有者, 3.2.9, 3.2.12

必要なグループ・メンバーシップ, 2.4.5.1.1

Oracle Universal Installer

レスポンス・ファイル

リスト, B.2.1

Oracle Upgrade Companion, 2.1 oracleユーザー

環境の構成, 2.14

作成, 2.4.3, 2.4.3.2, 2.4.3.3, 2.4.5.2.6, 2.4.5.2.7, 2.4.5.2.8

他のノードでの作成, 2.4.5.2.10

説明, 2.4.5.1.1

デフォルトのシェルの確認, 2.14.3

RAWデバイス所有者, 3.2.9, 3.2.12

必要なグループ・メンバーシップ, 2.4.5.1.1

環境変数ORACLE_BASE

シェル起動ファイルからの削除, 2.14.3

環境変数ORACLE_HOME

シェル起動ファイルからの削除, 2.14.3

環境変数ORACLE_SID

シェル起動ファイルからの削除, 2.14.3

oraInst.loc

中央インベントリ, 2.4.1

内容, 2.4.1

oraInst.locファイル

位置, 2.4.1

位置, 2.4.1

oraInventory, 2.4.5.1.1

概要, C.1.1.1

作成, 2.4.2

OSASMグループ, 2.4.5.1.3

概要, 2.4.5.1.3

複数のデータベース, 2.4.5.1.3

SYSASM, 2.4.5.1.3

作成, 2.4.5.2.3

ASM用のOSDBAグループ, 2.4.5.1.3

概要, 2.4.5.1.3

OSDBAグループ

SYSDBA権限, 2.4.5.1.2

作成, 2.4.5.2.1

他のノードでの作成, 2.4.5.2.10, 2.4.5.2.10

説明, 2.4.5.1.2

RAWデバイス・グループ, 3.2.9, 3.2.12

ASM用のOSDBAグループ

作成, 2.4.5.2.5

oslevelコマンド, 2.8 ASMのためのOSOPERグループ

概要, 2.4.5.1.3

作成, 2.4.5.2.4

OSOPERグループ

SYSOPER権限, 2.4.5.1.2

作成, 2.4.5.2.2

他のノードでの作成, 2.4.5.2.10, 2.4.5.2.10

説明, 2.4.5.1.2

P

パーティション

ASMでの使用, 3.3.1.1

passwdコマンド, 2.4.3.3.1, 2.4.5.2.10 パッチの更新

ダウンロード, 5.1.1

インストール, 5.1.1

My Oracle Support, 5.1.1

パッチ

ダウンロード場所, 2.8

PC Xサーバー

インストール, 2.3, 2.3

権限

データ・ファイル・ディレクトリ, 3.2.15

物理RAM要件, 2.5 pingコマンド, A.9 ポリシー管理データベース

SCAN, C.1.3.5

インストール後

パッチのダウンロードおよびインストール, 5.1.1

root.shのバックアップ, 5.2.1

プリコンパイラ

要件, 2.7

事前構成済データベース

ASMディスク領域要件, 3.3.1.1

ASMを使用する場合の要件, 3.3.1.1

権限を付与されたグループ

Oracle Database, 2.4.5.1.2

Pro*C/C++

要件, 2.7

.profileファイル, 2.14.3 PRVF-5436エラー, 2.12 PTF

確認, 2.8

ダウンロード場所, 2.8

PTFダウンロードの場所, 2.8

R

RAC

RAW論理ボリュームの構成, 3.2.10, 3.2.11

RAID

Oracle Cluster Registryおよび投票ディスクのミラー化, 3.2.1

ASMの推奨冗長レベル, 3.3.1.1

RAM要件, 2.5 RAWディスク・サイズ, 3.2.9 RAWディスク

クラスタ・ノードのボリューム・グループのアクティブ化, 3.2.13

アップグレード, 3.1.3.2

ディスクの可用性の確認, 3.2.10, 3.2.11

RAW論理ボリュームの作成, 3.2.9

ディスクの確認, 3.2.10, 3.2.11

クラスタ・ノードのディスク・グループのインポート, 3.2.12

LVMディスクの初期化, 3.2.10, 3.2.11

必要なサイズ, 3.2.9

所有者と権限の指定, 3.2.9, 3.2.12

既存のパーティションのアップグレード, 3.2.1

RAWディスクのサポート終了, Preface リカバリ・ファイル

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

冗長レベル

事前構成済データベースの領域要件, 3.3.1.1

冗長インターコネクトの使用, 2.6.1 グリッド・インフラストラクチャ・ホーム・バイナリの再リンク, 5.4 Oracle Grid Infrastructureホーム・バイナリの再リンク, 6.3, 6.4 要件, 3.3.1.1

ハードウェア, 2.5

resolv.confファイル, A.9 レスポンス・ファイル・モードでのインストール

準備, B.2

レスポンス・ファイル

テンプレート, B.2

サイレント・モード, B.3 レスポンス・ファイル・モード

概要, B.1

使用する理由, B.1.1

「レスポンス・ファイル」および「サイレント・モード」も参照

レスポンス・ファイル

概要, B.1

テンプレートでの作成, B.2.1

crs_install.rsp, B.2.1

dbca.rsp, B.2.1

enterprise.rsp, B.2.1

一般的な手順, B.1.2

Net Configuration Assistant, B.4

netca.rsp, B.2.1

コマンドラインで値を渡す, B.1

Oracle Universal Installerを使用した指定, B.3

レスポンス・ファイル, 「サイレント・モード」を参照

概要, B.1

使用する理由, B.1.1

「レスポンス・ファイル」も参照,

ローリング・アップグレード

ASM, 4.1, E.7.2

Oracle Clusterware, 4.1

rootユーザー

ログイン, 2.3

root.sh, 4.2.1

バックアップ, 5.2.1

実行, 4.1

rsizeパラメータ, 3.2.5 実行レベル, 2.5

S

SCANアドレス, A.9

SCANリスナー, A.9, C.1.3.5

SCAN, 2.6.2.2

理解, C.1.3.5

ポリシー管理データベースのクライアントに必要なSCANの使用, C.1.3.5

スクリプト

root.sh, 4.1

セキュア・シェル

インストーラによる構成, 2.13

セキュリティ

Oracleソフトウェアの所有権の分割, 2.4.5

シェル制限の設定, 2.11.5 シェル

oracleユーザーのデフォルトのシェルの確認, 2.14.3

環境変数SHELL

値の確認, 2.14.3

シェル制限, 2.11.5 シェル起動ファイル

編集, 2.14.3

環境変数の削除, 2.14.3

サイレント・モードによるインストール, B.3 単一クライアント・アクセス名,「SCANアドレス」を参照 smitコマンド, 2.4.3.3.1 ソフトウェア要件, 2.7

ソフトウェア要件の確認, 2.8

RAWディスクの所有者と権限の指定, 3.2.9, 3.2.12 ssh

X11転送, 2.14.4

OUIからの自動構成, 2.13

構成, D.1

使用時, 2.13

起動ファイル

シェル, 2.14.3

記憶域

GPFS

サポートされないASMファイル, 3.1.6

HACMP, 3.1.6 stty

インストール・エラーを回避するための抑止, 2.14.5

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

Oracle Clusterware, 3.1.6

抑制モード

使用する理由, B.1.1

スワップ領域

要件, 2.5

SYSASM, 2.4.5.1.3

OSASM, 2.4.5.1.3

SYSDBA

ASMでのデータベースSYSDBAの使用は非推奨, 2.4.5.1.3

SYSDBA権限

関連するグループ, 2.4.5.1.2

SYSOPER権限

関連するグループ, 2.4.5.1.2

T

TEMP環境変数, 2.5

設定, 2.14.3

一時ディレクトリ, 2.5 一時ディレクトリ。「/tmpディレクトリ」を参照 一時ディスク領域

確認, 2.5

解放, 2.5

要件, 2.5

端末出力コマンド

Oracleインストール所有者アカウントのための抑止, 2.14.5

/tmpディレクトリ

領域の確認, 2.5

領域の解放, 2.5

TMPDIR環境変数, 2.5

設定, 2.14.3

トラブルシューティング

削除, 6.1

asmcmdエラーおよびOracleホーム, 2.4.3.1

OUIからのSSHの自動構成, 2.13

root.shエラーの原因を修正するためのOracle Clusterwareの構成解除, 6.5

ディスク領域エラー, 4.1

DISPLAYエラー, 2.14.4

環境変数エラー, 4.1

ログ・ファイルのスクリプト入力のガベージ文字列, 2.14.5

INS-13001, A.5

断続的なハングアップ, 4.5, 4.7

ログ・ファイル, 4.2.1

権限エラーとoraInventory, C.1.1.1

インストール時の権限エラー, C.1.1.2

前提条件の検証に参照データを使用できない, A.5

root.shエラー, 6.5

実行レベル・エラー, 2.5

sqlplusエラーおよびOracleホーム, 2.4.3.1

ssh, D.1.1

SSH構成の失敗, D.1.2.1

sshエラー, 2.14.5

sttyエラー, 2.14.5

不明なインストールのエラー, 4.1

ユーザー等価関係, A.3, D.1.1

異なるユーザーIDとグループIDによるユーザー等価関係エラー, 2.4.3.3, 2.4.5.2.7

ユーザー等価関係エラー, 2.4.2

ddコマンドを使用した投票ディスクのバックアップ, はじめに

X11転送エラー, 2.14.4

トラブルシューティング

DBCAがOracle ASMディスク・サイズを認識せずディスク・グループの作成に失敗, 5.3.2

U

uid

既存の確認, 2.4.5.2.10

指定, 2.4.5.2.10

他のノードでの指定, 2.4.5.2.10

umaskコマンド, 2.14.1, 2.14.2 削除, 6.1 削除, 6.1 UNIXコマンド

cfgmgr, 3.2.10, 3.2.11

chdev, 3.2.10, 3.2.11

importvg, 3.2.12, 3.2.12

instfix, 2.8

lsdev, 3.2.10, 3.2.11

lslpp, 2.8, 2.8

lspv, 3.2.10, 3.2.11, 3.2.12, 3.2.12

mkvg, 3.2.10, 3.2.11

oslevel, 2.8

passwd, 2.4.3.3.1

smit, 2.4.3.3.1

swap, 2.5

swapon, 2.5

varyoffvg, 3.2.12

varyonvg, 3.2.10, 3.2.11

xterm, 2.3

アップグレード

Oracle Clusterware, 4.1

制限, E.4

環境変数の設定の解除, E.5.1

アップグレード, 2.1

SCAN, C.1.3.5

Oracle ASM, E.7.2

RAWディスクの使用, 3.1.3.2

アップグレード

既存のOracle ASMインスタンス, 1.3.6, 3.1.1

OCRパーティション・サイズ, 3.2.1

投票ディスク・パーティション・サイズ, 3.2.1

ローカルのGridホームに対する共有のOracle Clusterwareホーム, 2.17

ユーザー等価関係

テスト, A.3

ユーザー等価関係エラー

グループとユーザー, 2.4.3.3, 2.4.5.2.7

ユーザーID

既存の確認, 2.4.5.2.10

指定, 2.4.5.2.10

他のノードでの指定, 2.4.5.2.10

useraddコマンド, 2.4.5.2.8, 2.4.5.2.10 ユーザー

他のノードでの同一ユーザーの作成, 2.4.5.2.10, 2.4.5.2.10

oracleユーザーの作成, 2.4.3, 2.4.3, 2.4.3.2, 2.4.3.2, 2.4.5.2.6, 2.4.5.2.6, 2.4.5.2.7, 2.4.5.2.7

Oracleソフトウェア所有者ユーザー(oracle), 2.4.5.1.1

作成時のグループの指定, 2.4.5.2.10, 2.4.5.2.10

NISの使用, 2.4.5, 2.4.5.2.10

V

varyoffvgコマンド, 3.2.12

varyonvgコマンド, 3.2.10, 3.2.11

VIP

SCAN, A.9

仮想メモリー・マネージャ

チューニング, 2.11.2

ボリューム・グループ

作成, 3.2.10, 3.2.11

ボリューム・グループ

作成, 3.2.10, 3.2.11

投票ディスク

ddコマンドを使用したバックアップは非推奨, はじめに

構成, 4.1

ミラー化, 3.2.1

パーティション・サイズ, 3.2.1

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

W

WebSphere MQ

CSDのダウンロード場所, 2.8

要件, 2.7

ワークステーション

インストール, 2.3

wsize, 3.2.5 wsizeパラメータ, 3.2.5 wtmax, 3.2.3.2

Direct NFSの最小値, 3.2.3.2

X

Xエミュレータ

インストール, 2.3, 2.3

X Window System

リモート・ホストの有効化, 2.3, 2.3, 2.3

X11転送

エラー, 2.14.4

X11転送エラー, D.1.3 xhostコマンド, 2.3 xtermコマンド, 2.3, 2.3 xtitle

インストール・エラーを回避するための抑止, 2.14.5

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)を参照してください。