| Oracle® Grid Infrastructureインストレーション・ガイド 12cリリース1 (12.1) for Oracle Solaris B71326-09 |
|
 前 |
 次 |
この章では、Oracle Grid Infrastructureソフトウェアをインストールした後に実行する、インストール後の作業について説明します。
この章の内容は次のとおりです。
パッチの更新をダウンロードしてインストールします。My Oracle Support Webサイトを参照して、ご使用の環境に対応するパッチの更新を確認します。
必要なパッチの更新をダウンロードするには、次の手順を実行します。
Webブラウザを使用して、My Oracle Support Webサイトを表示します。
My Oracle Support Webサイトにログインします。
|
注意: My Oracle Supportの登録ユーザーでない場合は、「My Oracle Supportへの登録」をクリックして登録してください。 |
My Oracle Supportのメイン・ページで「パッチと更新版」をクリックします。
「パッチと更新版」ページで「拡張検索」をクリックします。
「拡張検索」ページで「製品または製品ファミリ」フィールドの横にある検索アイコンをクリックします。
「検索と選択: 製品ファミリ」フィールドで「検索」リスト・フィールドの「データベースとツール」を選択し、テキスト・フィールドにRDBMS Serverと入力して「検索」をクリックします。
RDBMSサーバーが「製品または製品ファミリ」フィールドに表示されます。現行のリリースが「リリース」フィールドに表示されます。
「プラットフォーム」フィールドのリストからプラットフォームを選択して、選択リストの下の「検索」をクリックします。
「結果」ヘッダーの下に使用可能なパッチの更新が表示されます。
パッチ番号をクリックして、パッチをダウンロードします。
「パッチ・セット」ページで「READMEの表示」をクリックして、表示されるページを読みます。 READMEページには、そのパッチ・セットに関する情報と、パッチの適用方法が記載されています。
「パッチ・セット」ページに戻って「ダウンロード」をクリックし、ファイルをシステムに保存します。
Oracle Database 12cリリース1 (12.1)で提供されたunzipユーティリティを使用して、My Oracle SupportからダウンロードしたOracleのパッチ更新を解凍します。unzipユーティリティは$ORACLE_HOME/binディレクトリにあります。
パッチをインストールする準備としてデータベース・プロセスを停止する方法については、付録Bを参照してください。
Oracle Grid Infrastructureをインストールした後で、必要に応じて次の作業を行うことをお薦めします。
現在、ネイティブのIPMIドライバがサポートされていないOracle Solarisプラットフォームでは、DHCPアドレッシングはサポートされていないため、IPMIサポートには手動の構成が必要になります。OUIは管理者資格証明を収集しないため、障害分離は手動で構成される必要があり、BMCは静的IPアドレスで構成される必要があり、アドレスはOLRに手動で格納される必要があります。
IPMIを使用して障害分離を構成するには、各クラスタ・メンバー・ノードで次の手順を実行します。
必要に応じて、次のコマンドを使用してOracle Clusterwareを起動します。
$ crsctl start crs
BMC管理ユーティリティを使用してBMCのIPアドレスを取得してから、クラスタ制御ユーティリティcrsctlを使用してcrsctl set css ipmiaddr addressコマンドを発行し、BMCのIPアドレスをOracle Local Registry(OLR)に格納します。次に例を示します。
$crsctl set css ipmiaddr 192.168.10.45
次のcrsctlコマンドを入力して、常駐BMCのユーザーIDおよびパスワードをOLRに格納します。youradminacctはIPMI管理者ユーザー・アカウントで、プロンプトが表示されたらパスワードを入力します。
$ crsctl set css ipmiadmin youradminact
IPMI BMC Password:
このコマンドによって、ユーザーが入力した資格証明が別のクラスタ・ノードに送信され、この資格証明の検証が行われます。クラスタ・ノードが資格証明を使用してローカルのBMCにアクセスできない場合、コマンドは失敗します。
IPMI資格証明をOLRに格納する場合は、明示的に指定した匿名ユーザーが必要です。ない場合は、解析エラーがレポートされます。
デフォルトのセマフォ・パラメータ値が低すぎて、すべてのOracleプロセスに対応できない場合のみ、次のガイドラインを参照してください。
|
注意: セマフォ・パラメータの設定方法の詳細は、オペレーティング・システムのドキュメントを参照することをお薦めします。 |
次の計算式を使用して、全体的な最小セマフォ要件を計算します。
2 * sum(システム上のすべてのデータベース・インスタンスのプロセス・パラメータ) + バックグラウンド・プロセスのオーバーヘッド + システムおよび他のアプリケーションの要件
semmns(システム全体のセマフォ合計)を、この合計値に設定します。
semmsl(各セットのセマフォ)を、250に設定します。
semmnsをsemmslで割り、最も近い1024の倍数に切り上げた値を、semmni(セマフォ・セット合計)として設定します。
インストール時、デフォルトでは1つのディスク・グループの作成が可能です。スタンドアロン・サーバー用のOracle Database、またはOracle RACデータベースを追加しようとする場合は、データベース・ファイルの高速リカバリ領域を作成する必要があります。
高速リカバリ領域は、リカバリに関連するすべての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 Automatic Storage Management管理者ガイド』 |
高速リカバリ・ファイル・ディスク・グループを作成するには、次の手順を実行します。
Gridホームのbinディレクトリに移動し、Oracle ASM Configuration Assistant(ASMCA)を起動します。次に例を示します。
$ cd /u01/app/12.1.0/grid/bin $ ./asmca
ASMCAが開き、「ディスク・グループ」タブが表示されます。新しいディスク・グループを作成するには、「作成」をクリックします。
「ディスク・グループの作成」ウィンドウが開きます。
「ディスク・グループ名」フィールドに、高速リカバリ領域グループの説明的な名前を入力します。たとえば、FRAです。
「冗長性」セクションで、適用する冗長レベルを選択します。
「メンバー・ディスクの選択」フィールドで、高速リカバリ領域に追加する適切なディスクを選択し、「OK」をクリックします。
「ディスク・グループ: 作成」ウィンドウが開き、ディスク・グループの作成が完了したというメッセージが表示されます。「OK」をクリックします。
「終了」をクリックします。
単一クライアント・アクセス名(SCAN)は、クラスタへのサービス・アクセスをクライアントに提供するために使用される名前です。SCANは、特定のノードではなくクラスタ全体に関連付けされているため、クライアントの再構成を必要とせずに、クラスタでノードを追加または削除することを可能にします。また、データベースに場所の独立性がもたらされるため、クライアント構成は特定のデータベース・インスタンスがどのノードで実行されているかに依存しません。クライアントは引き続き、以前のリリースと同じ方法でクラスタにアクセスできますが、クラスタにアクセスするクライアントではSCANの使用をお薦めします。
DNSによってSCANが正しくアドレスに関連付けられていることを確認するには、(Gridホーム/binにある)コマンドcluvfy comp scanを使用します。次に例を示します。
$ cluvfy comp scan Verifying scan Checking Single Client Access Name (SCAN)... Checking TCP connectivity to SCAN Listeners... TCP connectivity to SCAN Listeners exists on all cluster nodes Checking name resolution setup for ”node1.example.com”... Verification of SCAN VIP and Listener setup passed Verification of scan was successful.
インストール後、クライアントがクラスタにリクエストを送信すると、Oracle ClusterwareのSCANリスナーはクライアント・リクエストをクラスタのサーバーにリダイレクトします。
|
関連項目: システム・チェックおよび構成については、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
ORAchkユーティリティをダウンロードしてインストールし、Oracleソフトウェア・スタックの事前ヘルス・チェックを実行します。
ORAchkは、RACCheckユーティリティに代わるもので、ヘルス・チェックの範囲をOracleソフトウェア・スタック全体に拡張しており、Oracleユーザーから報告された主な問題を特定し、それに対処します。ORAchkは、Oracleの製品とデプロイメントについて次のような既知の問題をあらかじめスキャンします。
スタンドアロンのOracleデータベース
Oracle Grid Infrastructure
Real Application Clusters
最大可用性アーキテクチャ(MAA)の検証
アップグレード対応の検証
Oracle Golden Gate
E-Business Suite
ORAchkユーティリティの構成および実行方法の詳細は、次のMy Oracle Supportのノート1268927.1を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1268927.1
Oracle Grid Infrastructureのインストールが完了したら、Grid_home/crs/install/s_crsconfig_nodename_env.txtファイルでリソース制限を設定できます。これらのリソース制限は、Oracle Clusterwareによって管理されるすべてのOracle ClusterwareプロセスおよびOracle Databaseに適用されます。たとえば、プロセス数の制限をより高くするには、このファイルを編集してCRS_LIMIT_NPROCパラメータに高い値を設定します。
次の項で、Oracle Grid Infrastructure 12cリリース1 (12.1)インストールで前のリリースのOracle Databaseを使用する場合について説明します。
Oracle Database 10gリリース2とOracle Database 11gリリース1および2は、Oracle Clusterware 12cリリース1 (12.1)とともに使用できます。
srvctl、lsnrctlまたは他のOracle Grid Infrastructureホーム・ツールのバージョンを、以前のバージョンのデータベースを管理するために使用しないでください。以前のOracle Databaseリリースは、以前のOracle Databaseホームにあるツールのみを使用して管理します。以前のリリースのデータベースに対応する正しいツールのバージョンを使用するには、管理対象のデータベースまたはオブジェクトのOracleホームからツールを実行します。
データベースのバージョンがOracle Database 11gリリース2以上の場合にのみ、Oracle DatabaseホームをOracle ASM Cluster File System (Oracle ACFS)に格納できます。前のリリースのOracle DatabaseはOracle ACFSを使用するように設計されていないため、Oracle DatabaseをOracle ACFSにインストールすることはできません。
Flex ASMクラスタに11.2データベースをインストールする場合は、ASMカーディナリティがAllに設定されている必要があります。
|
注意: Oracle Database 11g リリース1 (11.1.0.7または11.1.0.6)またはOracle Database 10gリリース2 (10.2.0.4)からアップグレードする場合は、Oracle Clusterware 12cリリース1 (12.1) インストールへのOracle RACまたはOracle Databaseのインストールを始める前に、アップグレード元のリリースに推奨される最新のパッチを確認し、必要に応じて既存のデータベース・インストールに適用してから、アップグレードすることをお薦めします。推奨パッチの詳細は、「Oracle 12c Upgrade Companion」(My Oracle Support Note 1462240.1)を参照してください。
|
Oracle Grid Infrastructure 12cから、Oracle Databaseサーバーのカテゴリに、HubおよびLeafという、以前のリリースにはなかったロールが含まれるようになりました。このため、Oracle RAC 11 gバージョンのDatabase Configuration Assistant (DBCA)を使用してサーバー・プールを作成することはできません。以前のリリースのOracle RACインストールに対応するサーバー・プールを作成するには、次の手順を使用します。
Oracle Grid Infrastructureインストール所有者(Gridユーザー)としてログインします。
ディレクトリをGridホーム内の12.1 Oracle Grid Infrastructureバイナリのディレクトリに変更します。次に例を示します。
# cd /u01/app/12.1.0/grid/bin
Oracle Grid Infrastructure 12cバージョンのsrvctlを使用し、Hubノードのロールで構成されるサーバー・プールを作成します。たとえば、最大サイズのクラスタ・ノードを1つ使用して、p_hubというサーバー・プールを作成するには、次のコマンドを入力します。
srvctl add serverpool -serverpool p_hub -min 0 -max 1 -category hub;
Oracle RACインストール所有者としてログインし、Oracle RACのOracleホームからDBCAを起動します。次に例を示します。
$ cd /u01/app/oracle/product/12.1.0/dbhome_1/bin $ dbca
DBCAは、Oracle Grid Infrastructure 12 cのsrvctlコマンドで作成したサーバー・プールを検出します。使用するサービスに対して、必要に応じてサーバー・プールを構成します。
|
関連項目: ポリシーを使用してリソースを管理する方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
前のリリースのOracle DatabaseおよびOracle RACデータベースをOracle Grid Infrastructureにインストールするときに、Oracle ASM Configuration Assistant (ASMCA)を使用して、ディスク・グループを作成および変更します。Oracle Database 11gリリース2以上では、Oracle ASMはOracle ClusterwareとともにOracle Grid Infrastructureインストールの一部としてインストールされます。Database Configuration Assistant(DBCA)を使用してOracle ASMで管理タスクを実行することはできなくなりました。
|
関連項目: Oracle Database 11g以下のソフトウェアをOracle Grid Infrastructure 12c (12.1)とともに使用した、データベースに対するディスク・グループの互換性の構成に関する詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle Database 12cより前のOracle DatabaseリリースでOracle ASMを使用するには、ローカルのASMを使用するか、Flex ASMのカーディナリティをデフォルトの3ではなくALLに設定します。Oracle Grid Infrastructure 12cをインストールした後、Oracle ASMを使用してOracle Database 12cより前のOracle Databaseリリースに記憶域サービスを提供する場合は、次のコマンドを使用してOracle ASMリソース(ora.asm)を変更する必要があります。
$ srvctl modify asm -count ALL
この設定によりOracle ASMリリースのカーディナリティが変更されるので、Flex ASMインスタンスはすべてのノードで実行されるようになります。クラスタのノード数が3以下の場合でも、11gリリース2より前のデータベース・リリースがora.node.sid.instリソースの別名を検出できるように設定を変更する必要があります。
旧バージョンのOracleソフトウェアがインストールされていないクラスタにOracle Clusterware 12cリリース1 (12.1)をインストールすると、Oracle Databaseリリース11.2以上と互換性のあるクラスタ・ノードが動的に構成されます。ただし、Oracle Database 10gおよび11.1では、永続構成が必要です。ノード名とノード番号との関連付けを行うプロセスは、固定と呼ばれます。
|
注意: アップグレード中、すべてのクラスタ・メンバー・ノードには自動的に固定されるため、既存のデータベースに対して手動で固定する必要はありません。この手順は、Oracle Grid Infrastructure 11gリリース2 (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/12.1.0/grid/bin/olsnodes -t -n node1 1 Pinned node2 2 Pinned node3 3 Pinned node4 4 Pinned
特定のノードの状態を表示する場合:
olsnodes -t -n node3
次に例を示します。
# /u01/app/12.1.0/grid/bin/olsnodes -t -n node3 node3 3 Pinned
|
関連項目: ノードの固定および固定解除の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
Oracle Database 11gリリース2のローカルおよびSCANリスナーを、lsnrctlコマンドを使用して管理するには、$ORACLE_HOME環境変数をOracle Grid Infrastructureホーム(Gridホーム)のパスに設定します。以前のリリースで使用していたOracleホームの位置からlsnrctlコマンドを使用しないでください。この位置は新しいリリースでは使用できません。
インストール後にOracle Clusterware構成の変更が必要になった場合は、Gridホームをロック解除する必要があります。
たとえば、個別パッチを適用する場合や、Oracle Clusterware構成を変更して、デフォルトのUDPを使用するかわりにインターコネクト上でRDS経由のIPCトラフィックを実行する場合は、Gridホームのロック解除が必要になります。
|
注意: 実行可能ファイルを再リンクする前に、Oracleホーム・ディレクトリで実行されている、ロック解除および再リンク対象の実行可能ファイルをすべて停止する必要があります。また、Oracle共有ライブラリにリンクされているアプリケーションも停止してください。 |
次の手順に従って、ホームをロック解除します。
パスGrid_home/crs/installに移動します。Grid_homeはGridホームのパスです。次に、コマンドrootcrs.sh -unlock -crshome Grid_homeを使用して、Gridホームをロック解除します。ここでは、Grid_homeは使用しているグリッド・インフラストラクチャ・ホームのパスです。たとえば、Gridホームが/u01/app/12.1.0/gridの場合、次のコマンドを入力します。
# cd /u01/app/12.1.0/grid/crs/install # perl rootcrs.sh -unlock -crshome /u01/app/12.1.0/grid
ユーザーを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を実行することも可能です。 |
次のコマンドを使用して、Gridホームを再度ロックし、クラスタを再起動します。
# perl rootcrs.sh -patch
各クラスタ・メンバー・ノードで、手順1から3を繰り返します。
