| Oracle Grid Infrastructureインストレーション・ガイド リリース12.1 For Windows B72965-06 |
|
 前 |
 次 |
この付録では、インストールの完了に必要な概念および用語の概要を説明します。
Oracle Universal Installerでは、ソフトウェアのインストール時に様々なディレクトリが使用されます。
SYSTEM_DRIVE:\app\user_name\です。Oracle Optimal Flexible Architecture (OFA)ルールは、異なるユーザーが所有する異なるバージョンの複数のデータベースが共存できるように、データベース・ソフトウェアを編成してデータベースを構成する際に役立ちます。
Oracle Grid Infrastructureのみをインストールする場合は、Oracle Optimal Flexible Architecture(OFA)に準拠したOracleベースおよびGridホームのパスを作成して、Oracle Universal Installer(OUI)がインストール中にそのディレクトリを選択できるようにすることをお薦めします。
OracleベースのOFAパスは、X:\app\userです。userは、Oracle Installationユーザー・アカウントの名前です。
Oracle Grid Infrastructure OracleホームのOFAパスは、X:\app\release\gridであり、releaseは3桁のOracle Grid Infrastructureリリースです(12.1.0など)。
OUIはOFA準拠のソフトウェア・パスを検出すると、Oracle Grid Infrastructure GridホームおよびOracle Inventory (oraInventory)ディレクトリを作成します。たとえば、パスC:\appおよびG:\appはOFAに準拠したパスです。
Oracle Grid Infrastructureホームは、Oracle Grid InfrastructureのOracleインストール・ユーザー用Gridホームとは異なるパスにある必要があります。Oracle Grid Infrastructureベース・パスを手動で作成する場合、このリリース専用の個別のパスであることと、既存のOracleベース・パスの下にないことを確認します。
注意:
Oracle Grid Infrastructureホームを手動で作成することを選択した場合は、次のディレクトリの下にクラスタのOracle Grid Infrastructureホームを作成しないでください。
Oracle Grid InfrastructureのOracleインストール・ユーザー(gridなど)のOracleベース・ディレクトリ
Oracle DatabaseのOracleインストール・ユーザー(oracleなど)のOracleベース・ディレクトリ
Oracleベース・ディレクトリにOracle Clusterwareインストールを作成すると、その後のOracleインストールが失敗します。
Oracle Grid Infrastructureホームは、以前のリリースの既存のOracle Clusterwareホームが共有された場所にある場合でも、サーバーのローカル・ホームに配置できます。
Oracleインベントリ・ディレクトリには、サーバーにインストールされたすべてのOracleソフトウェア用の中央インベントリがあります。
Oracle Inventoryディレクトリの場所はSystem_drive:\Program Files\Oracle\Inventoryです。
システムにOracleソフトウェアを初めてインストールする場合、Oracleインベントリ・ディレクトリが存在するかどうかがインストーラによって確認されます。Oracleインベントリ・ディレクトリの場所は、Windowsレジストリ・キーHKEY_LOCAL_MACHINE\SOFTWARE\Oracle\inst_locによって判断されます。Oracleインベントリ・ディレクトリが存在しない場合は、インストーラによってC:\Program Files\Oracle\Inventoryのデフォルトの場所に作成されます。
注意:
Windowsレジストリでのinst_locの値の変更は、サポートされていません。
デフォルトでは、Oracleインベントリ・ディレクトリは、Oracleインストール・ユーザーのOracleベース・ディレクトリの下にはインストールされません。これは、すべてのOracleソフトウェア・インストールで共通のOracleインベントリを共有するため、Oracleインベントリはすべてのユーザー用に1つしかありませんが、Oracleベース・ディレクトリはユーザーごとにあるからです。
Oracleインベントリ・ディレクトリには、次のものが含まれています。
システム上のOracleホーム・ディレクトリ(Oracle Grid InfrastructureおよびOracle Database)のレジストリ。
Oracleソフトウェアのインストール時のインストール・ログおよびトレース・ファイル。これらのファイルは、将来参照するためにそれぞれのOracleホームにもコピーされます。
Oracleインストールに関するその他のメタデータ・インベントリ情報は、個々のOracleホーム・インベントリ・ディレクトリに格納されており、中央インベントリとは分離されています。
中央インベントリは、すべてのクラスタ・ノードに作成されます。コア・ノードの場合、インベントリにはOracleホームのノードリストの処理ノードは含まれません。処理ノードの場合、中央インベントリのノードリストにはローカル・ノードのみが含まれています。コア・ノードのリストは、コア・ノードの中央インベントリでのみ更新されます。
インストール時に、Oracleベースの場所を指定するように求められます。この場所は、Oracleインストール・ユーザーが基準となります。既存のOracleホームが含まれるディレクトリを選択するか、またはOracleベース・ディレクトリの構造を持っていない別のディレクトリを選択できます。Oracleベース・ディレクトリのデフォルトの場所は、SYSTEM_DRIVE:\app\user_name\です。
Oracleベース・ディレクトリ・パスを使用すると、Oracleインストールの構造が簡略化され、複数のデータベース・インストールでOptimal Flexible Architecture(OFA)構成を保持しやすくなります。
複数のOracle Databaseインストールで、同じOracleベース・ディレクトリを使用できます。Oracle Grid Infrastructureインストールは、異なるディレクトリ・パス(Oracleベース以外のパス)を使用します。異なるオペレーティング・システム・ユーザーでOracleソフトウェアをインストールする場合は、各ユーザーが異なるデフォルトのOracleベースの場所を持つことになります。
ただし、Oracle Restartは他のOracleソフトウェアと同じ場所に置くことができます。
クラスタに存在できるOracle Grid Infrastructureインストールは1つのみで、すべてのアップグレードがアウトオブプレース・アップグレードであるため、Oracle Grid InfrastructureのOracleインストール・ユーザー用のOracleベース(C:\app\gridなど)を作成し、そのインストールのリリース番号を使用して、Oracle Grid Infrastructureバイナリ用のOracleホーム(C:\app\12.1.0\gridなど)を作成することをお薦めします。
Oracle Grid Infrastructureでは、様々なオペレーティング・システム・グループが使用されます。これらのオペレーティング・システム・グループには、Oracle ClusterwareおよびOracle ASMに対して、管理システム権限のオペレーティング・システム・グループ認証を付与する論理ロールが指定されます。
ORA_DBAグループおよびORA_HOMENAME_DBAグループです。オプションの2つのグループORA_OPERおよびORA_HOMENAME_OPERも使用できます。ORA_DBAグループのメンバーにSYSASM権限は付与されていません。メンバーに、Oracleインベントリ・ディレクトリへの書込み権限が付与された、1つのグループが必要です。このディレクトリは、サーバー上のすべてのOracleソフトウェア・インストールの中央インベントリ・レコードです。
Oracleインベントリ・グループのメンバーには、Oracle中央インベントリ・ディレクトリに対する書込み権限があり、様々なOracle Clusterwareリソース、OCRキー、DBAが書込み権限を必要とするOracle Clusterwareホーム内のディレクトリに対する権限やその他の必要な権限も付与されます。デフォルトでは、このグループはORA_INSTALLです。
すべてのOracleソフトウェア・インストール・ユーザーは、Oracleインベントリ・グループのメンバーである必要があります。このグループのメンバーは、クラスタ同期サービス(CSS)と通信できます。
注意:
Oracleソフトウェアがシステムにすでにインストールされている場合は、新しいインベントリ・グループを作成するかわりに、既存のOracleインベントリ・グループが使用されます。Windowsプラットフォームでは、Oracle Databaseを管理するために使用するオペレーティング・システム・グループは、ORA_DBAグループおよびORA_HOMENAME_DBAグループです。オプションの2つのグループORA_OPERおよびORA_HOMENAME_OPERも使用できます。
Oracle Databaseをインストールすると、ORA_DBAという特別なWindowsローカル・グループが作成され(過去のOracle Databaseインストールで作成されていない場合)、Oracleインストール・ユーザーがこのグループに自動的に追加されます。このORA_DBAグループのメンバーには、自動的にSYSDBA権限が付与されます。ORA_DBAグループのメンバーシップによって、ユーザーは次の操作を実行できます。
パスワードなしでOracle Databaseインスタンスに接続できます。
ローカル・データベースの起動および停止など、データベース管理手順を実行できます。
別のWindowsユーザーをORA_DBAに追加し、そのユーザーにSYSDBA権限を付与できます。
ORA_DBAグループのメンバーシップによって、サーバー上のすべてのデータベースに対する完全なアクセス権が付与されます。ORA_HOMENAME_DBAグループのメンバーシップによって、特定のOracleホームから実行されるすべてのデータベースに対する完全なアクセス権が付与されます。いずれのグループに属しても、Oracle ASMインスタンスに関しては、ユーザーに特別な権限は付与されません。これらのグループのメンバーは、Oracle ASMインスタンスには接続できません。
インストール時には、ORA_OPERおよびORA_HOMENAME_OPERグループも作成されます。ただし、これらはオプションのグループです。すべてのデータベースまたは1つのOracleホームから実行されるデータベースのための、限定された一連のデータベース管理権限(SYSOPER権限)を持つ、個別のユーザーのグループが必要な場合に、これらのグループにユーザーを割り当てます。
デフォルトでは、データベースORA_DBAグループのメンバーにSYSASM権限は付与されていません。
SYSASMは、Oracle ASMストレージ管理権限をSYSDBAから切り離すことができるシステム権限です。次の表に、インストール時に作成されるOracle ASM権限を管理するためのグループを示します。
表C-1 Windows用のOracle ASMオペレーティング・システム・グループおよび権限
| ロール | オペレーティング・システム・グループ | 説明 |
|---|---|---|
OSASM |
|
このグループのメンバーは、SYSASM権限を使用し、オペレーティング・システム認証を介してOracle ASMインスタンスに接続できます。インストール時に、Oracle Grid InfrastructureのOracleインストール・ユーザーおよびOracle DatabaseサービスIDはこのグループのメンバーとして構成されます。 |
ASM用のOSDBA |
|
このグループは、Oracle ASMに対するデータベース・アクセス権を付与します。Oracle ASMで管理される記憶域にアクセスする必要のある、すべてのASMクライアントが、このグループに属する必要があります。 |
ASM用のOSOPER |
|
このグループのメンバーは、SYSOPER権限を使用し、オペレーティング・システム認証を介してOracle ASMインスタンスに接続できます。インストール後、このグループにはメンバーが含まれませんが、インストールの完了後、このグループに手動でユーザーを追加できます。 |
関連項目:
役割区分用のOracle ASMグループOracle DatabaseおよびOracle RACには、SYSDBAおよびSYSOPERという2つの特別な管理権限があり、これらの権限の受領者は、データベースの作成やデータベース・インスタンスの起動や停止などの重要なデータベース管理タスクを実行できます。
Windowsでは、SYSDBAおよびSYSOPERデータベース管理権限のオペレーティング・システム・グループはORA_DBAおよびORA_OPERグループに固定されており、これらのグループ名は変更できません。ただし、SYSDBA権限は便利である一方で、SYSDBA権限によってもたらされるアクセス権は、管理者が割り当てられるタスクに必要とされるよりも多くなります。
Oracle Database 12cでは、よりタスク固有で、かつ、それらのタスクをサポートする最小限の権限を備えた、新しい管理権限が導入されました。一般的なデータベース・タスクのニーズを満たすため、4つの新しい管理権限が作成されています。次の表に、これらの新しい権限および関連するオペレーティング・システム・グループを示します。
表C-2 特定タスク向けのOracle Database管理権限およびロール
| 権限 | オペレーティング・システム・グループ | 説明 |
|---|---|---|
SYSBACKUP |
|
バックアップおよびリカバリ・タスク用の管理権限 |
SYSDG |
|
Data Guard管理タスク用の管理権限 |
SYSKM |
|
暗号化鍵管理タスク用の管理権限 |
これらのオペレーティング・システム・グループの名前は変更できません。データベースの作成後、これらのグループにはメンバーが登録されていませんが、インストール後、管理者ユーザーはこれらのグループにユーザーを割り当てることができます。各オペレーティング・システム・グループは、関連する一連のデータベース権限が割り当てられた、オペレーティング・システム・ユーザーのグループを識別します。
インストール時に、Oracle Universal Installer(OUI)がクラスタ・ノードで検出するネットワーク・インタフェースごとに計画された使用方法を指定するように求められます。
各インタフェースを、パブリック・インタフェースまたはプライベート・インタフェース、あるいはOracle Grid InfrastructureやOracle ASMで使用しないインタフェースとして指定します。パブリック・アドレスおよび仮想インターネット・プロトコル(VIP)・アドレスは、パブリック・インタフェース上に構成されます。プライベート・アドレスはプライベート・インタフェース上に構成されます。
各アドレス・タイプの詳細は、次の項を参照してください。
パブリックIPアドレスでは、パブリック・インタフェース(クライアントからアクセス可能なインタフェース)が使用されます。
パブリックIPアドレスは、動的ホスト構成プロトコル(DHCP)を使用して動的に割り当てられるか、ドメイン・ネーム・システム(DNS)またはhostsファイルで静的に定義されます。パブリックIPアドレスは、クラスタ･メンバー･ノードのプライマリ・アドレスであり、コマンドhostnameを入力したときに返される名前に解決されるアドレスである必要があります。
IPアドレスを手動で構成した場合は、Oracle Grid Infrastructureをインストールした後で、ドメイン修飾子の追加や削除も含め、ホスト名を変更しないでください。新しいホスト名を持つノードは、新しいホストと見なされるので、クラスタに追加する必要があります。古い名前のノードは、クラスタから削除されるまで、停止状態で表示されます。
Oracle Clusterwareは、プライベートとマークされたインタフェースを使用してノード間通信を行います。
各クラスタ・ノードは、インストール時にプライベート・インタフェースとして指定されたインタフェースを持つ必要があります。プライベート・インタフェースはそのインタフェース用に構成されたアドレスを持つ必要がありますが、それ以上の構成は必要ありません。Oracle Clusterwareは、プライベートと指定されたインタフェースを、クラスタ・インターコネクトとして使用します。プライベート・ネットワークに関する情報に複数のインタフェースを指定すると、Oracle Clusterwareはそれらを冗長インターコネクトを使用して構成します。プライベートとして指定するインタフェースはいずれも、クラスタのすべてのノードに接続するサブネット上に存在しなければなりません。Oracle Clusterwareは、プライベート・インタフェース用に指定された、すべてのインタフェースを使用します。
プライベート・インターコネクトの場合は、ノード間のキャッシュ・フュージョンおよびその他のトラフィックのため、物理的に別のプライベート・ネットワークを使用することをお薦めします。DNSを使用してアドレスを構成する場合は、プライベートIPアドレスがクラスタ・ノードからのみ到達可能であることを確認する必要があります。
インストール後、CLUSTER_INTERCONNECTS初期化パラメータを使用してOracle Real Application Clusters(Oracle RAC)のインターコネクトを変更する場合は、パブリックIPアドレスで使用されていないサブネット上またはoifcfgでパブリック・サブネットとしてマークされていないサブネット上で、インターコネクトをプライベートIPアドレスに変更する必要があります。パブリック・サブネットとして指定したサブネットを使用するインタフェースにインターコネクトを変更することはできません。
プライベート・ネットワークIPアドレスを使用したネットワークではファイアウォールを使用しないでください。プライベート・ネットワークIPアドレスによってインターコネクト・トラフィックがブロックされる可能性があるためです。
仮想IP(VIP)アドレスは、グリッド・ネーミング・サービス(GNS)またはDNSに登録されています。
次の要件を満たすVIPのアドレスを選択します。
IPアドレスとホスト名は、現在未使用である(DNSに登録できるが、pingコマンドでアクセスできない)
VIPはパブリック・インタフェースと同じサブネット上にある
グリッド・ネーミング・サービス(GNS)を使用していない場合は、各ノードに仮想ホスト名を指定します。仮想ホスト名は、ノードが停止している場合にノードに送信されるクライアントの要求を再ルーティングするパブリック・ノードの名です。Oracle Databaseでは、クライアントとデータベース間の接続にVIPを使用するため、VIPアドレスはパブリックにアクセス可能である必要があります。名前はhostname-vip形式で指定することをお薦めします。たとえば、myclstr2-vipです。
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によってクラスタに提供されるため、クラスタのパブリック・ネットワーク上でDHCPを使用できる必要があります。
関連項目:
GNSの詳細は、Oracle Clusterware管理およびデプロイメント・ガイドを参照してください。Oracle Databaseクライアントは、単一クライアント・アクセス名(SCAN)を使用してデータベースに接続します。
SCANとそれに関連付けられたIPアドレスは、クラスタを構成するノードとは無関係に、クライアントが接続に使用する安定した名前を提供します。SCANアドレス、仮想IPアドレス、およびパブリックIPアドレスはすべて、同じサブネット上に存在する必要があります。
SCANは、node1-vipのような、仮想IPアドレスに使用される名前に類似した仮想IP名です。ただし、仮想IPと異なり、SCANは個別のノードではなくクラスタ全体と関連付けられており、1つではなく複数のIPアドレスと関連付けられています。
SCANは、パブリック・クライアント接続を処理するクラスタ内の複数のリスナーを反映し、複数のIPアドレスに解決されます。クライアントから要求が送信されると、SCAN IPアドレスおよびSCANポート上でリスニングしているSCANリスナーがクライアントから使用できるようになります。クラスタ上のすべてのサービスがSCANリスナーに登録されているため、SCANリスナーは、現在サービスを提供している最も負荷が低いノードのローカル・リスナー・アドレスを使用して応答します。最後に、サービスが提供されているノード上のリスナーを通じて、クライアントがサービスへの接続を確立します。これらすべての動作はクライアントに対して透過的に行われ、クライアントでの明示的な構成は必要ありません。
インストール中にリスナーが作成されます。これらのSCANリスナーは、SCAN IPアドレスでリスニングを行います。SCANリスナーは、Oracle Clusterwareによって決定されるノードで起動されます。Oracle Net Servicesは、サービスを提供している最も負荷が低いインスタンスに、アプリケーションの要求をルーティングします。SCANアドレスはクラスタ内のノード・アドレスではなくクラスタに解決されるため、SCANアドレス構成に影響を与えることなく、クラスタでノードを追加または削除できます。
SCANは、クラスタ内のグリッド・ネーミング・サービス(GNS)、またはドメイン・ネーム・サービス(DNS)解決のいずれかで解決できるように構成する必要があります。高い可用性とスケーラビリティを実現するために、3つのIPアドレスに解決されるようにSCAN名を構成することをお薦めします。SCANは少なくとも1つのアドレスに解決される必要があります。
GNSドメインを指定する場合、SCAN名のデフォルトはclustername-scan.GNS_domainです。そうでない場合のデフォルトはclustername-scan.current_domainです。たとえば、Oracle Grid Infrastructureインストールをサーバーnode1から起動し、クラスタ名がmycluster、GNSドメインがgrid.example.comの場合、SCAN名はmycluster-scan.grid.example.comです。
Oracle Database 11gリリース2より前のOracle DatabaseリリースのIPアドレスを使用するように構成されたクライアントは、既存の接続アドレスを引き続き使用できるため、SCANを使用する必要はありません。Oracle Clusterware 12cリリース1 (12.1)にアップグレードするとSCANが有効になり、Oracle Database 11g リリース2以上のデータベースへの接続にSCANが必要になります。以前のリリースのOracle Databaseをアップグレードすると、SCANリスナーに登録されるため、クライアントがSCANを使用してそのデータベースに接続できるようになります。データベースはinit.oraファイルのリモート・リスナー・パラメータを通じてSCANリスナーに登録されます。REMOTE_LISTENERパラメータは、SCAN:PORT形式で設定する必要があります。HOST= SCAN_nameなどを使用して、SCANの1つのアドレスが指定されたTNSNAMES別名は設定しないでください。
SCANはほとんどのデプロイメントでオプションです。ただし、サーバー・プールを使用するOracle Database 11g リリース2以上のポリシー管理データベースを使用するクライアントは、SCANを使用してデータベースにアクセスする必要があります。ポリシー管理データベースは異なるサーバーで異なる時刻に実行されることがあるため、これは必須であり、そのため、あるポリシー管理データベースの仮想IPアドレスを使用して特定ノードに接続することはできません。
クラスタへのクライアント・アクセス用のSCANアドレスを指定します。このアドレスは、ドメイン・ネーム・サービス(DNS)にラウンド・ロビン・アドレスとして構成してください。SCANアドレスは、3つ指定することをお薦めします。
注意:
次に、ノードIPアドレスに関する追加情報を示します。
ローカル・ノードの場合のみ、OUIによってパブリックおよびVIPフィールドが自動的に書き込まれます。システムでベンダーのクラスタウェアが使用されている場合は、OUIにより追加のフィールドが書き込まれることがあります。
ホスト名および仮想ホスト名は、ドメイン修飾されません。インストール中にアドレス・フィールドにドメインを入力すると、そのドメインは、OUIによってアドレスから削除されます。
プライベートIPアドレス用にプライベートとして指定したインタフェースは、パブリック・インタフェースとしてアクセスできないようにする必要があります。キャッシュ・フュージョンにパブリック・インタフェースを使用すると、パフォーマンスの問題が発生する可能性があります。
パブリック・インタフェースおよびプライベート・インタフェースを指定します。OUIは、パブリックIPアドレスおよび仮想IPアドレスによって使用されるようにパブリック・インタフェースを構成し、プライベートIPアドレスをプライベート・インタフェース上に構成します。
プライベート・インタフェースが使用するプライベート・サブネットは、クラスタ・メンバーにする予定のすべてのノードに接続する必要があります。
Oracle Clusterware 12cリリース1 (12.1)には、クラスタ時刻同期化サービス(CTSS)が自動的に構成されます。
CTSSは、すべてのクラスタ・ノードの時刻設定を自動同期する機能を提供しています。CTSSは、デプロイしたクラスタのタイプに最適な同期戦略を使用します。
ネットワーク・タイム・プロトコル(NTP)、Windows Timeサービスなどの既存のクラスタ同期サービスがある場合、CTSSはオブザーバ・モードで開始されます。それ以外の場合、CTSSはアクティブ・モードで開始され、クラスタ・ノード間の時刻の同期を確実にします。CTSSで互換性の問題が発生することはありません。
CTSSモジュールはOracle Grid Infrastructureのインストールの一環としてインストールされます。CTSSデーモンはOracle高可用性サービス・デーモン(ohasd)によって起動されるため、コマンドライン・インタフェースは必要ありません。
次の項では、Oracle Automatic Storage Management (Oracle ASM)の記憶域の概要について説明します。
Oracle ASMは、拡張されて汎用ファイル・システムであるOracle Automatic Storage Management (Oracle ACFS)を含むようになりました。
Oracle ACFSは、複数のプラットフォームに対応するスケーラブルな新しいファイル・システムとしてストレージを管理し、このテクノロジにより、Oracle ASM機能は、Oracle Databaseの外で保持されているカスタマ・ファイルをサポートするように拡張されます。Oracle ACFSがサポートするファイルには、アプリケーション実行可能ファイル、データ・ファイルおよびアプリケーション・レポートなどがあります。他にも、ビデオ、オーディオ、テキスト、イメージ、設計図、その他の汎用アプリケーションのファイル・データがサポートされます。
注意:
Oracle ASM 11gリリース2 (11.2.0.2)から、Oracle ACFSは、Windows Server 2008 R2 x64でサポートされます。Oracle ACFSでは、Oracle Databaseバイナリなど、すべてのOracleファイルのための最適化された記憶域を提供できます。その他のアプリケーション・ファイルも格納できます。ただし、Oracle ClusterwareバイナリまたはOracle Clusterwareファイルには使用できません。
関連項目:
Oracle ACFSの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。Oracle Automatic Storage Management Configuration Assistant (ASMCA)を使用して、既存のOracle ASMインスタンスをOracle ASM 12cリリース1 (12.1)以上にアップグレードできます。
ASMCAはパスGrid_home\binにあります。また、ASMCAを使用して、障害グループ、Oracle ASMボリュームおよびOracle ACFSを構成できます。
注意:
既存のOracle ASMインスタンスのアップグレードは、そのノード上のすべてのデータベース・インスタンスおよびアプリケーションを停止してから実行する必要があります。インストール時に、Oracle ASMを使用することを選択したときに、以前のOracle ASMリリースが別のOracle ASMホームにインストールされていることがASMCAで検出された場合は、Oracle ASM 12cリリース1 (12.1)のソフトウェアをインストールした後に、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は、すべてのノードで12cリリース1 (12.1)にアップグレードされます。
クラスタのメンバー・ノードの中に、既存のスタンドアロンのOracle ASMがインストールされているノードが1つ以上ある場合でも、OUIは、クラスタ用のOracle Grid Infrastructureのインストールを開始します。Oracle Clusterwareファイル(OCRおよび投票ファイル)をOracle ASM上に配置すると、クラスタウェアのインストール終了時にASMCAが起動し、ローカル・ノード上のOracle ASMインスタンスを移行およびアップグレードするためのプロンプトが表示され、Oracle ASM 12cリリース1 (12.1)環境が作成されます。
リモート・ノードでスタンドアロンのOracle ASMインスタンスが実行されていることをASMCAが認識すると、そのOracle ASMインスタンスと、そのOracle ASMインスタンスを使用しているデータベース・インスタンスを停止するように求められます。次に、ASMCAは、クラスタ化されたOracle ASMインスタンスをクラスタ内のすべてのノードに展開します。ただし、クラスタ対応のOracle ASMインスタンスのディスク・グループ名は、既存のスタンドアロンのディスク・グループ名と異なっている必要があります。
関連項目:
『Oracle Automatic Storage Management管理者ガイド』Oracle Grid Infrastructureのアウトオブプレース・アップグレードでは、インストーラは新しいリリースのソフトウェアを別のGridホームにインストールします。両方のリリースのOracle Clusterwareが、各クラスタ・メンバー・ノードに存在しますが、1つのリリースのみがアクティブになります。
ローリング・アップグレードは、ソフトウェアの新リリースへのアップグレード中、停止時間をなくし、可用性の継続を保証します。
各ノード上に別々のOracle Clusterwareホームがある場合、すべてのノードでアウトオブプレース・アップグレードを行うか、アウトオブプレース・ローリング・アップグレードを行うことで、あるノードでは以前のリリースのOracle ClusterwareホームからOracle Clusterwareを実行し、別のノードでは新しいリリースのOracle ClusterwareホームからOracle Clusterwareを実行することが可能です。
Oracle Clusterware 11gリリース2以上のインプレース・アップグレードはサポートされていません。
