プライマリ・コンテンツに移動
Oracle® Grid Infrastructureインストレーション・ガイド
12cリリース1 (12.1) for Linux
B71324-15
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

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

この章では、Oracle Grid Infrastructureソフトウェアをインストールした後に実行する、インストール後の作業について説明します。

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

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

パッチの更新をダウンロードしてインストールします。My Oracle Support Webサイトを参照して、ご使用の環境に対応するパッチの更新を確認します。

必要なパッチの更新をダウンロードするには、次の手順を実行します。

  1. Webブラウザを使用して、My Oracle Support Webサイトを表示します。

    https://support.oracle.com

  2. My Oracle Supportにログインします。


    注意:

    My Oracle Supportの登録ユーザーでない場合は、「My Oracle Supportへの登録」をクリックして登録してください。

  3. My Oracle Supportのメイン・ページで「パッチと更新版」をクリックします。

  4. 「パッチと更新版」ページで、「製品またはファミリ(拡張)」をクリックします。

  5. 「製品」フィールドで、「Oracle Database」を選択します。

  6. 「リリース」フィールドで、リリース番号を1つ以上選択します。たとえば、Oracle 12.1.0.1.0とします。

  7. 「検索」をクリックします。

  8. 「パッチ検索」ページに、使用可能なすべてのパッチの更新が表示されます。

  9. パッチ番号をクリックして、パッチをダウンロードします。

  10. パッチ番号を選択して「README」をクリックします。READMEページには、そのパッチ・セットに関する情報と、パッチの適用方法が記載されています。

  11. 「パッチ・セット」ページに戻って「ダウンロード」をクリックし、ファイルをシステムに保存します。

  12. Oracle Database 12cリリース1 (12.1)で提供されたunzipユーティリティを使用して、My Oracle SupportからダウンロードしたOracleのパッチ更新を解凍します。unzipユーティリティは$ORACLE_HOME/binディレクトリにあります。

  13. パッチをインストールする準備としてデータベース・プロセスを停止する方法の詳細は、付録B「Oracle Grid Infrastructure 12cリリース1へのアップグレード方法」を参照してください。

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

Oracle Grid Infrastructureをインストールした後で、必要に応じて次の作業を行うことをお薦めします。

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

デフォルトのセマフォ・パラメータ値が小さすぎてすべてのOracleプロセスに対応できない場合にのみ、次のガイドラインを使用してください。


注意:

セマフォ・パラメータの設定方法の詳細は、オペレーティング・システムのドキュメントを参照することをお薦めします。

  1. 次の計算式を使用して、全体的な最小セマフォ要件を計算します。

    2 * sum(システム上のすべてのデータベース・インスタンスのプロセス・パラメータ) + バックグラウンド・プロセスのオーバーヘッド + システムおよび他のアプリケーションの要件

  2. semmns(システム全体のセマフォ合計)を、この合計値に設定します。

  3. semmsl(各セットのセマフォ)を、250に設定します。

  4. semmnssemmslで割り、最も近い1024の倍数に切り上げた値を、semmni(セマフォ・セット合計)として設定します。


    関連項目:

    次のURLにあるMy Oracle Supportノート226209.01「Linux: How to Check Current Shared Memory, Semaphore Values」を参照してください。

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


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

インストール時、デフォルトでは1つのディスク・グループの作成が可能です。スタンドアロン・サーバー用のOracle Database、またはOracle RACデータベースを追加しようとする場合は、データベース・ファイルの高速リカバリ領域を作成する必要があります。

9.2.2.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つの異なるデータベースで共有するとします。各データベースの高速リカバリ領域のサイズを、そのデータベースの重要度によって設定することができます。たとえば、test1が最も重要度が低く、productsがそれよりも重要度が高く、ordersが最も重要度が高い場合、各データベースに異なるDB_RECOVERY_FILE_DEST_SIZE設定を適用し、それぞれの保存目標を満たすようにします。たとえば、test1には30GB、productsには50GB、ordersには70GBのように設定します。


関連項目:

Oracle Enterprise Manager Real Application Clustersガイドのオンライン・ヘルプ

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

高速リカバリ領域ディスク・グループを作成するには、次の手順を実行します。

  1. Gridホームのbinディレクトリに移動し、Oracle ASM Configuration Assistant(ASMCA)を起動します。次に例を示します。

    $ cd /u01/app/12.1.0/grid/bin
    $ ./asmca
    
  2. ASMCAが開き、「ディスク・グループ」タブが表示されます。「作成」をクリックして新しいディスク・グループを作成します。

  3. 「ディスク・グループの作成」ウィンドウが開きます。

    「ディスク・グループ名」フィールドに、高速リカバリ領域グループの説明的な名前を入力します。たとえば、FRAです。

    「冗長性」セクションで、適用する冗長レベルを選択します。

    「メンバー・ディスクの選択」フィールドで、高速リカバリ領域に追加する適切なディスクを選択し、「OK」をクリックします。

  4. 「ディスク・グループの作成」ウィンドウが開き、ディスク・グループの作成が完了したというメッセージが表示されます。「OK」をクリックします。

  5. 「終了」をクリックします。

9.2.3 SCAN構成の確認

単一クライアント・アクセス名(SCAN)は、クラスタへのサービス・アクセスをクライアントに提供するために使用される名前です。SCANは、特定のノードではなくクラスタ全体に関連付けされているため、クライアントの再構成を必要とせずに、クラスタでノードを追加または削除することを可能にします。また、データベースに場所の独立性がもたらされるため、クライアント構成は特定のデータベース・インスタンスがどのノードで実行されているかに依存しません。クライアントは引き続き、以前のリリースと同じ方法でクラスタにアクセスできますが、クラスタにアクセスするクライアントではSCANの使用をお薦めします。

DNSによってSCANが正しくアドレスに関連付けられていることを確認するには、(Gridホーム/binにある)コマンドcluvfy comp scanを使用します。次に例を示します。

$ cluvfy comp scan 


Verifying scan

Checking Single Client Access Name (SCAN)...

Checking TCP connectivity to SCAN Listeners...
TCP connectivity to SCAN Listeners exists on all cluster nodes

Checking name resolution setup for ”node1.example.com”...

Verification of SCAN VIP and Listener setup passed

Verification of scan was successful.

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


関連項目:

システム・チェックおよび構成については、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

9.2.4 ORAchkヘルス・チェック・ツールのダウンロードとインストール

ORAchkユーティリティをダウンロードしてインストールし、Oracleソフトウェア・スタックの事前ヘルス・チェックを実行します。

ORAchkは、RACCheckユーティリティに代わるもので、ヘルス・チェックの範囲をOracleソフトウェア・スタック全体に拡張しており、Oracleユーザーから報告された主な問題を特定し、それに対処します。ORAchkは、Oracleの製品とデプロイメントについて次のような既知の問題をあらかじめスキャンします。

  • スタンドアロンのOracleデータベース

  • Oracle Grid Infrastructure

  • Oracle 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

9.2.5 Oracle Clusterwareおよび関連するデータベースやアプリケーションに対するリソース制限の設定

Oracle Grid Infrastructureのインストールの終了後、Grid_home/crs/install/s_crsconfig_nodename_env.txtファイルにリソース制限を設定できます。これらのリソース制限は、すべてのOracle ClusterwareプロセスおよびOracle Clusterwareで管理されるOracle Databaseに適用されます。たとえば、より多くの数のプロセス制限を設定するには、このファイルを編集してCRS_LIMIT_NPROCパラメータに高い値を設定します。

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

次の項で、Oracle Grid Infrastructure 12cリリース1 (12.1)インストールで前のリリースのOracle Databaseを使用する場合について説明します。

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

Oracle Database 10gリリース2およびOracle Database 11gリリース1および2は、Oracle Clusterware 12cリリース1 (12.1)で使用できます。

srvctllsnrctlまたは他の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にインストールすることはできません。

既存バージョンのOracle ClusterwareとOracle ASMをOracle Grid Infrastructure 11g以上(Oracle ClusterwareとOracle ASMを含む)にアップグレードする場合で、Oracle RACデータベースを12cリリース1 (12.1)にアップグレードする計画もある場合は、Oracle RACのアップグレードが完了したときに、既存のデータベースに必要な構成も自動的に完了するため、この項の説明を読む必要はありません。


注意:

Oracle Database 11g リリース1 (11.1.0.7または11.1.0.6)またはOracle Database 10gリリース2 (10.2.0.4)からアップグレードする場合は、Oracle Clusterware 12cリリース1 (12.1) インストールへのOracle RACまたはOracle Databaseのインストールを始める前に、アップグレード元のリリースに推奨される最新のパッチを確認し、必要に応じて既存のデータベース・インストールに適用してから、アップグレードすることをお薦めします。

推奨パッチの詳細は、「Oracle 12c Upgrade Companion」(My Oracle Support Note 1462240.1)を参照してください。

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


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

Oracle Grid Infrastructure 12cから、Oracle Databaseサーバーのカテゴリに、HubおよびLeafという、以前のリリースにはなかったロールが含まれるようになりました。このため、Oracle RAC 11 gバージョンのDatabase Configuration Assistant (DBCA)を使用してサーバー・プールを作成することはできません。以前のリリースのOracle RACインストールに対応するサーバー・プールを作成するには、次の手順を使用します。

  1. Oracle Grid Infrastructureインストール所有者(Gridユーザー)としてログインします。

  2. ディレクトリをGridホーム内の12.1 Oracle Grid Infrastructureバイナリのディレクトリに変更します。次に例を示します。

    # cd /u01/app/12.1.0/grid/bin
    
  3. Oracle Grid Infrastructure 12cバージョンのsrvctlを使用し、ハブ・ノードのロールで構成されるサーバー・プールを作成します。たとえば、最大サイズのクラスタ・ノードを1つ使用して、p_hubというサーバー・プールを作成するには、次のコマンドを入力します。

    srvctl add serverpool -serverpool p_hub -min 0 -max 1 -category hub;
    
  4. Oracle RACインストール所有者としてログインし、Oracle RACのOracleホームからDBCAを起動します。次に例を示します。

    $ cd /u01/app/oracle/product/11.2.0/dbhome_1/bin
    $ dbca
    

    DBCAは、Oracle Grid Infrastructure 12 csrvctlコマンドで作成したサーバー・プールを検出します。使用するサービスに対して、必要に応じてサーバー・プールを構成します。


関連項目:

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

9.3.3 以前のOracle DatabaseリリースでOracle ASMを使用可能にする

Oracle Database 12c以前のOracle DatabaseでOracle ASMを使用するには、ローカルのASMを使用するか、Flex ASMのカーディナリティをデフォルトの3ではなくALLに設定します。Oracle Grid Infrastructure 12cのインストール後、Oracle Database 12c以前のOracle Databaseの記憶域サービスにOracle ASMを使用する場合、次のコマンドを使用してOracle ASMリソース(ora.asm)を変更します。

$ srvctl modify asm -count ALL

この設定によりOracle ASMリリースのカーディナリティが変更されるので、Oracle Flex ASMインスタンスはすべてのクラスタ・ノードで実行されるようになります。クラスタのノード数が3または3未満の場合でも、11gリリース2以前のデータベースがora.node.sid.instリソース・エイリアスを検出できるように設定を変更する必要があります。

記憶域にOracle ASMを使用するOracle Database 10g リリース2データベースをご使用の場合は、$crs_home/network/admin/sqlnet.oraファイルでSQLNET.ALLOWED_LOGON_VERSION=8と設定してください。

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

前のリリースのOracle DatabaseおよびOracle RACデータベースをOracle Grid Infrastructureにインストールするときに、Oracle ASM Configuration Assistant (ASMCA)を使用して、ディスク・グループを作成および変更します。Oracle Database 11gリリース2 (11.2)以上では、Oracle ASMはOracle ClusterwareとともにOracle Grid Infrastructureインストールの一部としてインストールされます。Database Configuration Assistant(DBCA)を使用してOracle ASMで管理タスクを実行することはできなくなりました。


関連項目:

Oracle Database 11g以下のソフトウェアをOracle Grid Infrastructure 12c (12.1)とともに使用した、データベースに対するディスク・グループの互換性の構成に関する詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

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

前のバージョンのOracleソフトウェアがないクラスタにOracle Clusterware 12cリリース1 (12.1)をインストールすると、クラスタ・ノードが動的に構成されます(これは、Oracle Databaseリリース11.2以上と互換性がありますが、Oracle Database 10gおよび11.1では永続的な構成が必要です)。ノード名とノード番号との関連付けを行うこのプロセスを固定と呼びます。


注意:

アップグレード中、すべてのクラスタ・メンバー・ノードには自動的に固定されるため、既存のデータベースに対して手動で固定する必要はありません。この手順は、Oracle Grid Infrastructure 12cリリース1 (12.1)ソフトウェアをインストールした後に、以前のバージョンのデータベースをインストールする場合にのみ必要です。

前のバージョンのOracle Databaseをインストールして使用するための準備でノードを固定するには、Grid_home/bin/crsctlを使用して次のコマンド構文を実行します。nodesは、構成を固定するクラスタ内の1つまたは複数のノードを示す、スペース区切りリストです。

crsctl pin css -n nodes

たとえば、ノードnode3およびnode4を固定するには、rootとしてログインし、次のコマンドを入力します。

$ crsctl pin css -n node3 node4

ノードが固定状態か非固定状態かを確認するには、Grid_home/bin/olsnodesを使用して次のコマンド構文を実行します。

固定されたすべてのノードを表示する場合:

olsnodes -t -n 

次に例を示します。

# /u01/app/12.1.0/grid/bin/olsnodes -t -n
node1 1       Pinned
node2 2       Pinned
node3 3       Pinned
node4 4       Pinned

特定のノードの状態を表示する場合:

olsnodes -t -n node3

次に例を示します。

# /u01/app/12.1.0/grid/bin/olsnodes -t -n node3
node3 3       Pinned

関連項目:

ノードの固定および固定解除の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

9.3.6 適切なLSNRCTLコマンドの使用

lsnrctlコマンドを使用してローカル・リスナーおよびSCANリスナーを管理するには、環境変数$ORACLE_HOMEにOracle Grid Infrastructureホーム(Gridホーム)のパスを設定します。以前のリリースで使用していたOracleホームの位置からlsnrctlコマンドを使用しないでください(この位置は新しいリリースでは使用できません)。

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

インストール後にOracle Clusterware構成の変更が必要になった場合は、Gridホームをロック解除する必要があります。

たとえば、個別パッチを適用する場合や、Oracle Clusterware構成を変更して、デフォルトのUDPを使用するかわりにインターコネクト上でRDS経由のIPCトラフィックを実行する場合は、Gridホームのロック解除が必要になります。


注意:

実行可能ファイルを再リンクする前に、Oracleホーム・ディレクトリで実行されている、ロック解除および再リンク対象の実行可能ファイルをすべて停止する必要があります。また、Oracle共有ライブラリにリンクされているアプリケーションも停止してください。

次の手順に従って、ホームをロック解除します。

  1. rootとしてログインし、パスGrid_home/crs/install(Grid_homeはGridホームのパス)に移動し、コマンドrootcrs.sh -unlock -crshome Grid_home(Grid_homeは使用しているGrid Infrastructureホームのパス)を使用して、Gridホームをロック解除します。たとえば、Gridホームが/u01/app/12.1.0/gridの場合、次のコマンドを入力します。

    # cd /u01/app/12.1.0/grid/crs/install
    # perl rootcrs.sh -unlock -crshome /u01/app/12.1.0/grid
    
  2. ユーザーをOracle Grid Infrastructureソフトウェア所有者に変更し、コマンド構文make -f Grid_home/rdbms/lib/ins_rdbms.mk targetを使用してバイナリを再リンクします(ここで、Grid_homeはGridホーム、targetは再リンクするバイナリです)。たとえばGridユーザーがgridで、$ORACLE_HOMEがGridホームに設定されている場合、インターコネクト・プロトコルをUDPからIPCに更新するには、次のコマンドを入力します。

    # su grid
    $ make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk ipc_rds ioracle
    

    注意:

    バイナリを再リンクする場合、Oracle Grid Infrastructureのインストール所有者に変更して、コマンドGrid_home/bin/relinkを実行することも可能です。

  3. 次のコマンドを使用して、Gridホームを再度ロックし、クラスタを再起動します。

    # perl rootcrs.sh -patch
    
  4. 各クラスタ・メンバー・ノードで、手順1から3を繰り返します。


注意:

Gridホームのディレクトリは削除しないでください。たとえば、Grid_home/Opatchディレクトリを削除しないでください。このディレクトリを削除すると、グリッド・インフラストラクチャ・インストール所有者はOpatchを使用してGridホームにパッチを適用できず、Opatchによって「checkdirエラー: Grid_home/OPatchを作成できません」というエラー・メッセージが表示されます。