Oracle Database 11g Release 2 Oracle Real Application Clusters 新機能

Size: px

Start display at page:

Download "Oracle Database 11g Release 2 Oracle Real Application Clusters 新機能"

こうざぶろうさかわ
4 years ago
Views:

1 1

2 2

3 本資料では以下の省略表記を使用している箇所があります名称省略表記 Baseboard Management Controller BMC Cluster Ready Services CSS Cluster Time Synchronization Service CTSS Cluster Verification Utility CVU Database Configuration Assistant DBCA Domain Name Service DNS Dynamic Host Configuration Protocol DHCP Enterprise Manager EM Grid Plug and Play ( プロファイル ) GPnP ( プロファイル ) Grid Naming Service GNS Intelligent Platform Management Interface IPMI multicast Domain Name Service mdns Network Interface Card NIC Network Time Protocol NTP Oracle Universal Installer OUI Oracle Automatic Storage Management Oracle ASM (ASM) Oracle ASM Cluster File System Oracle ACFS (ACFS) Oracle High Availability Services OHAS Oracle Cluster Registry OCR Single Client Access Name SCAN Virtual IP VIP 3

4 4

5 5

6 6

7 従来はシステムごとにサーバーが管理されリソースの配置は物理サーバーに制限されていましたそのため RAC データベースのインスタンスが起動する物理サーバーは固定されシステムごとに RAC データベースが別々に構築され管理されていましたクラスタへのノードの追加作業や構成変更はノード固有の情報の指定や更新を全てのノードに対して行う必要がありました 7

8 8

9 9

10 GPnP プロファイルの詳細について Oracle Clusterware アーキテクチャの資料を参照ください Single Client Access Name (SCAN) の詳細については Real Application Clusters ( ポリシーベース管理 ) の資料を参照ください 10

11 11

12 12

13 13

14 14

15 クラスタ名は作成するクラスタのメンバーノードの識別に使用されますネットワークドメインは node1.oracle.com という名前のノードの場合 oracle.com を指します GNS を構成する場合ネットワークドメインとは別に GNS が管理するサブドメインを用意します (GNS サブドメイン ) GNS を構成する場合クラスタのリソースは GNS サブドメイン内に構成されます GNS を構成するには Oracle Universal Installer (OUI) で以下のように指定します ( ステップ1) クラスタ用の Grid Infrastructure ソフトウェアのインストールおよび構成を選択 ( ステップ 2) 拡張インストールを選択 ( ステップ4) GNS の構成のチェックボックスにチェック GNS サブドメインと GNS VIP アドレスの情報を指定補足 : スタンドアロンサーバー用の環境では GNS は構成できません 11g R1 以前からのアップグレードでは GNS の構成は行えません 15

16 16

17 17

18 補足 : 複数サブネットの環境 ( 複数のネットワークリソースを構成する環境 ) で GNS を構成することはサポートしていません 18

19 GNS を使用したクラスタ内のリソースの名前解決の流れ 1 DNS サーバーが GNS サブドメイン内の名前解決のリクエストを GNS に転送 2 GNS がリクエストされた情報を得るため ( この場合は node4 というノードの情報) マルチキャスト 3 該当する情報を持つ mdns が GNS に情報を返信 4 GNS が DNS サーバーのリクエストに対する情報を返信 19

20 補足 : 複数サブネットの環境で 2 番目以降のネットワークの VIP リソースに対して DHCP による動的な IP アドレスの割り当ては行われません 20

21 21

22 GNS の構成確認状態確認の結果の例 : [grid@node1]$ srvctl config gns -a GNSは有効です GNSはポート53でDNSサーバーのリクエストをリスニングしています GNSはポート5353を使用してmDNSに接続しています GNSステータス : OK ドメインはGNSによってサービスを提供されています : grid.oracle.com GNSバージョン : GNS VIPネットワーク : ora.net1.network [grid@node1]$ srvctl status gns GNSはノードnode1で実行中です GNSはノードnode1で有効です [grid@node1]$ crsctl stat res -t ora.gns 1 ONLINE ONLINE node1 ora.gns.vip 1 ONLINE ONLINE node1 [grid@node1]$ 22

23 GNS を構成している場合クラスタのリソースは GNS によって内部的に次のような名前で管理されていますノード VIP : < ホスト名 >-vip.<gns サブドメイン > SCAN : < スキャン名 >.<GNS サブドメイン > SCAN VIP : < クラスタ名 >-scan[1-3]-vip.<gns サブドメイン > GNS VIP : < クラスタ名 >-gns-vip.<gns サブドメイン > ノード : < ホスト名 >.<GNS サブドメイン > ノードに対する問い合わせはノードに割り当てられている全ての IP アドレスの情報が返ります GNS の構成確認状態確認の結果の例 : [grid@node1]$ nslookup scan.grid.oracle.com Server: Address: #53 Non-authoritative answer: Name: scan.grid.oracle.com Address: Name: scan.grid.oracle.com Address: Name: scan.grid.oracle.com Address: [grid@node1]$ 23

24 24

25 GNS を構成した場合クラスタのリソースは GNS VIP を除き全て GNS によって名前解決が行われます GNS VIP SCAN VIP はホームノードを持たないため自動フェイルバックの動作はありません DHCP を使用した IP アドレスの割り当てはノードまたはクラスタリソースの起動時に行われます NODE VIP SCAN VIP がフェイルオーバーする場合フェイルオーバー前の IP アドレスが引き継がれます GNS を構成しない場合は従来までと同様に DNS や /etc/hosts によって名前解決が行われます GNS を構成しない場合 ( 基本構成 ) タイプ起動するノード IP アサイン名前解決ノード1 パブリックノード1 固定 DNS ノード1 VIP ノード1(*1) 固定 DNS ノード1 プライベートノード1 固定 DNS ノード2 パブリックノード2 固定 DNS ノード2 VIP ノード2(*1) 固定 DNS ノード 2 プライベートノード 2 固定 DNS SCAN VIP1 いずれかのノード固定 DNS SCAN VIP2 いずれかのノード固定 DNS SCAN VIP3 いずれかのノード固定 DNS 25

26 GPnP 関連プロセスの起動の流れ 1 OHASD が oraagent を介して GPNPD MDNSD を起動 2 MDNSD がローカルノードのネットワークインターフェースに割り当てられている IP アドレスを取得しネットワーク上の MDNSD に向けて通知 3 GPNPD がローカルノードの GPnP プロファイルを読み込み 4 GPNPD が MDNSD を介して他ノードの GPNPD の存在を確認し各ノードの GPnP プロファイルで最も新しいものを取得 5 CRS が orarootagent を起動 # 以上は GNS を構成しない場合も共通して行われます以下の 7 9 は GNS を構成している場合固有の起動時の動作です 7 orarootagent が GNSD.VIP リソースと GNSD を起動 8 orarootagent が SCAN VIP リソースと NODE VIP リソースを起動 GNS 環境 : DHCP によって VIP 用の IP アドレスを取得非 GNS 環境 : OLR/OCR から VIP 用の IP アドレスを取得 9 orarootagent が VIP の名前と IP アドレスの情報を GNS に通知 26

27 27

28 28

29 29

30 GNS を使用したデータベースへの接続 ( 専用サーバー構成 ) の流れ 1 SCAN リスナー経由で ORCL サービスへの接続要求 2 scan.grid.oracle.com は GNS ドメイン内のリソースであるため DNS は GNS に名前解決のリクエストを転送 3 GNS が SCAN リスナーのアドレスを解決し DNS に SCAN VIP の情報を通知 4 DNS が SCAN VIP の情報をクライアントに通知 5 クライアントは SCAN VIP のアドレスポート番号を使用し SCAN リスナーに対して接続要求を送信 6 SCAN リスナーは ORCL サービスが稼動している接続先情報をクライアントに送信 ( 接続のリダイレクト ) 7 クライアントは接続先サーバーのデフォルトリスナーを介してデータベースに接続 GNS に対して行われた名前解決は DNS サーバー上にキャッシュされます (TTL は 120 秒 ) 30

31 クラスタリソースはクラスタのいずれかのサーバーに配置されサーバー障害時などリソースが起動できない場合はフェイルオーバーするリソースであることを表していますスであることを表しています GNS と GNS VIP は orarootagent によって監視が行われておりダウンまたは異常を検知した場合再起動またはフェイルオーバーが行われます GNS/GNS VIP のフェイルオーバーが発生した場合 GNS/GNS VIP はホームノードが存在しないためフェイルバックは行われません GPnP 関連プロセスのログ分類 mdns GNS GPNPD OHAS エージェント CRS エージェントログの場所 <Grid_Home> /log/<hostname> /mdnsd/* <Grid_Home> /log/<hostname> /gnsd/* <Grid_Home> /log/<hostname> /gpnpd/* <Grid_Home> /log/<hostname> /agent/ohasd/* <Grid_Home> /log/<hostname> /agent/crsd/* GNS のログレベルの変更 srvctl start gns -l < ログレベル > を使用して GNS を起動することでログレベルを変更することが可能ですデフォルトのログレベルは 0 です (root.sh で起動時のみログレベル 6 で起動 ) 最も詳細なログを出力する場合は 6 を指定しますただしログの出力量が多く CPU も多く必要とするため注意が必要ですログレベル 5 はログ出力量 CPU 消費量も抑えられます 31

32 32

33 GNS を構成する場合少なくとも GNS VIP 用の IP アドレスは固定 IP アドレスとして必要ですパブリック IP アドレスを DHCP を使用して動的に割り当てる場合ダイナミック DNS などを使用してクラスタ内のノード間の名前解決が行える必要があります NIC については GNS を構成する場合も GNS を構成しない場合と同様に少なくとも 2 枚が必要です 33

34 GNS サブドメインを別途用意する必要があります node1.jp.mycompany.com / node2.jp.mycompany.com の 2 台のマシンを使用してクラスタを構築する場合例えば GNS サブドメインを mycluster.jp.mycompany.com として準備しますまた GNS サブドメインはクラスタを構築するマシンのネットワークドメインの子ゾーンを含むサブドメインである必要はなく上記のマシンに対して例えば mycomp.co.jp を GNS サブドメインとすることもできます DNS サーバーには GNS サブドメイン内の名前解決のリクエストを GNS へ転送するための設定を予め行っておく必要があります設定例 1) 親ゾーン側で GNS サブドメインに対して権限委譲 GNS サブドメイン : mycluster.jp.mycompany.com jp.mycompany.com ドメインのゾーンファイルで mycluster サブドメインに対する NS レコードを作成設定例 2) GNS サブドメインのゾーンに対して forward を指定 GNS サブドメイン : mycomp.co.jp mycomp.co.jp ゾーンに対する名前解決リクエストを forward するよう設定 DNS サーバー DHCP サーバーの設定例については後述します 34

35 DHCP サーバーはパブリックネットワーク上で稼動している必要があります DHCP サーバーによる IP アドレスの割り当てが行えない場合 NODE VIP/SCAN VIP リソースの起動が失敗しますインターコネクトで使用するプライベート IP アドレスも DHCP を使用して動的割り当てを行う場合はプライベートネットワーク上で DHCP サーバーが稼動している必要があります 35

36 36

37 クラスタ用 Grid Infrastructure のインストール時の指定例 : 補足 : /etc/named.conf の options ステートメント内に forwarders 設定をしている場合 GNS サブドメインに適切に転送されない場合があります 37

38 クラスタ用 Grid Infrastructure のインストール時の指定例 : 38

39 39

40 40

41 41

42 42

43 43

44 本資料では 4 ノード (node1, node2, node3, node4) の 11g R2 RAC クラスタ環境に 1 ノード (node5) d を追加するケースについて addnode.sh d を使用した手順を説明しますインストールユーザー : Oracle Grid Infrastructure Oracle RAC : grid : oracle db_name : orcl ノード追加を行う場合以下の作業が完了している必要があります物理的な接続の確立オペレーティングシステムのインストールグループ / ユーザーとディレクトリの作成 SSH の設定クラスタ検証ユーティリティ (Cluster Verification i Utility: CVU) による確認 $ cluvfy stage -post hwos -n node5 [-verbose] $ cluvfy comp peer [-refnode ref_node] -n node5 [-verbose] 44

45 11g R2 ではプライベートネットワークに関するパラメータ指定は必要ありませんまた Oracle Universal Installer の対話モードを使用した Grid Infrastructure の拡張する方法はありませんクラスタ検証ユーティリティ (Cluster Verification Utility: CVU) によるノード追加前の確認 $ cluvfy stage -pre nodeadd -n node5 [-fixup [-fixupdir fixup_dir]] [- verbose] クラスタ検証ユーティリティ (Cluster Verification Utility: CVU) によるノード追加後の確認 $ cluvfy stage -post nodeadd -n node5 [-verbose] 注意 : *1 : 現時点では GNS 環境も非 GNS 環境と同様に VIP 情報の指定が必要 45

46 46

47 Enterprise Manager Database Control を使用してサーバープールの属性変更を行うことも可能です 47

48 Enterprise Manager Database Control を使用してクラスタデータベースへのインスタンスの追加を行うことも可能です 48

クラスタデータベース: ホームページでソフトウェアとサポートタブをクリックします 2

ライブラリのデプロイとプロビジョニングをクリックします 3 管理タブをクリックします 4

49 プロビジョニングデプロイメントプロシージャを使用する場合ソフトウェアライブラリが構成されている必要がありますソフトウェアライブラリの構成は以下の手順で行います 1 クラスタデータベース: ホームページでソフトウェアとサポートタブをクリックします 2 デプロイメントプロシージャマネージャセクションのソフトウェアライブラリのデプロイとプロビジョニングをクリックします 3 管理タブをクリックします 4 プロビジョニングページでソフトウェアライブラリ構成セクションまで下にスクロールします 5 追加ボタンをクリックしテキストボックスにソフトウェアライブラリのディレクトリの場所を指定します 49

50 Enterprise Manager Database Control によって SCAN リスナーまたはノードの構成が変更されたことが検知された場合クラスタのホーム画面の一般セクションに再構成アクティビティの情報が出力されますノードをコマンドラインで追加した場合新しく追加したノードも Enterprise Manager で管理する場合構成を行う必要があります再構成アクティビティのリンクのナビゲーションに従って Enterprise Manager の再構成を行うことが可能ですまたコマンドラインの emca コマンドを addnode オプションを指定して実行することで同様に再構成行うことも可能です $ <DB_home>/bin/emca -addnode db -silent -DB_UNIQUE_NAME orcl - MODIFY_NODE node5 -SERVICE_NAME orcl 50

51 51

52 本資料では 5 ノード (node1, node2, node3, node4, node5) の 11g R2 RAC クラスタ環境から 1 ノード (node5) d を削除するケースの手順を説明します 52

53 Enterprise Manager Database Control を構成している場合削除するノードを含まないように再構成しますコマンドラインの emca コマンドを deletenode オプションを指定して実行します $ <DB_home>/bin/emca -deletenode db -silent -DB_UNIQUE_NAME orcl - MODIFY_NODE node5 -SERVICE_NAME orcl 53

54 削除するインスタンスで稼動するサービスを作成している場合インスタンスを削除する前にサービスの構成を削除するインスタンスを含まないように変更します Enterprise Manager Database Control を使用してクラスタデータベースからインスタンスを削除を行うことも可能です Enterprise Manager Database Control を構成している場合削除するノードを含まないように再構成しますコマンドラインの emca コマンドを deletenode オプションを指定して実行します $ <DB_home>/bin/emca -deletenode db -silent -DB_UNIQUE_NAME orcl - MODIFY_NODE node5 -SERVICE_NAME orcl 54

55 55

56 56

57 57

58 クラスタ検証ユーティリティ (Cluster Verification Utility: CVU) によるノード削除後の確認 $ cluvfy stage -post nodedel -n node5 [-verbose] 58

59 59

60 60

61 61

62 62

63 63

64 基本的にクラスタ以外のサーバーとも時刻同期を行う必要がある場合は NTP を使用した時刻同期を行うことを推奨しますクラスタ用 Grid Infrastructure をインストールすると自動的に CTSS デーモンが起動されます特に事前の設定は必要ありませんサーバー上で NTP が設定されている場合は CTSS デーモンは起動するのみで何も処理しません (observer mode) その場合システム時刻の同期は NTP に任せるためです CTSS の時刻調整は Slew モード ( 時刻の後戻りをしないで徐々に時刻を調整する ) で時刻補正を行いますクラスタ時刻同期化サービスの注意点 NTP を利用しない場合は NTP の設定ファイル (Linux 環境では /etc/ntp.conf) がないことを確認してください NTP が起動していない状況でも NTP の設定ファイルが存在する場合 CTSS は時刻同期を行いません (observer mode) クラスタ用 Grid Infrastructure をインストールする前に一旦全サーバーで時刻を合わせておくことをお奨めしますサーバー間で時刻の格差が大きい場合時刻同期に時間を要するためです 64

65 CTSS の稼動モードの確認例 : - Active mode [grid@node1]$ crsctl check ctss CRS-4701: クラスタ時刻同期化サービスはアクティブモードになっています CRS-4702: オフセット ( ミリ秒 ): 0 - Observer mode [grid@node1]$ crsctl check ctss CRS-4700: クラスタ時刻同期化サービスはオブザーバモードになっています 65

66 OUI では NTP の起動の有無だけではなく NTP の設定ファイル (/etc/ntp.conf) の有無もチェックしています OUI のチェックでは以下のケースは成功しますクラスタを構成する全サーバーで NTP が起動されているかつ設定ファイルが存在する NTP による時刻同期が有効と判断 CTSS の時刻同期サービスを無効 (observer mode) にするクラスタを構成する全サーバーで NTP が起動されていないかつ設定ファイルも存在しない NTP による時刻同期は無効と判断 CTSS の時刻同期サービスを有効 (active mode) にするチェックに失敗するケースとしては以下があります設定ファイルは存在するものの NTP が起動されていないサーバー間で NTP の起動や設定ファイルの整合性が取れていない slew オプション -x を指定して起動されていない slew オプション -x は /etc/sysconfig/ntpd で指定します /etc/sysconfig/ntpd の設定例 : # Drop root to id 'ntp:ntp' by default. OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid" # Set to 'yes' to sync hw clock after successful ntpdate SYNC_HWCLOCK=no # Additional options for ntpdate NTPDATE_OPTIONS="" 66

67 67

68 68

69 crsctl stop cluster による停止 crsctl stop cluster コマンドを使用して Oracle Clusterware stack を停止した場合次のデーモンとエージェント以外が全て停止されます OHAS デーモン GIPC デーモン mdns デーモン GPNP デーモン OHAS エージェント (orarootagent, oraagent) OHAS デーモンの起動 / 停止 OHAS デーモンの起動と停止はローカルノードから実行しますリモートノードから行うことができません 69

70 パッチの適用時など o オプションで指定したホームから起動されるリソースを一括して起動と停止を行うことができます DB_home を指定して実行した場合に起動 / 停止されるリソースサービス (svc) データベース (db) Grid_home を指定して実行した場合に起動 / 停止されるリソースディスクグループ (diskgroup) リスナー (lsnr) スキャンリスナー (scan_listener) スキャン VIP (scan_vip) ONS (ons) eons (eons) GNS (gns) NODE VIP (vip) ネットワーク (net) 70

71 71

72 サーバーが複数のサブネットのネットワークに接続されている場合は RAC 11g R2 ではサブネットごとに VIP を作成することが可能になります 1 つのサブネットに 1 つの VIP を構成できます同じサブネットに複数の VIP は構成できませんセキュリティ要件や負荷分散の観点でサブネットを分離したい場合に有効ですネットワークリソース複数サブネットに対して VIP を作成した際のネットワークリソースのステータスは以下のようになります $ crsctl status resource t ora.net1.network ONLINE ONLINE ONLINE ONLINE ora.net2.network ONLINE ONLINE ONLINE ONLINE デフォルトのネットワークリソース node1 異なるサブネットに VIP を作成した際の node2 ネットワークリソース node1 node2 ネットワーク番号ネットワークリソースはネットワーク番号を持ちます Grid Infrastructure インストール時に構成されるネットワークのネットワーク番号は 1 ( デフォルト ) です RAC 11g R2 の新機能で複数サブネットに対して VIP を作成することが可能ですその場合はサブネットごとにネットワーク番号 (2,3 ) を割り当てそれに応じたネットワークリソース (ora.net(2,3 ).network) が作成されます 72

73 サービスを作成する際に -k オプションを指定するとサービスとそのネットワーク上で稼動する VIP との依存関係が構築されますパブリックネットワーク障害時にク障害時に VIP がフェイルオーバーするとそのノード上のサービスは OFFLINE (UNIFORM の場合 ) になりますリスナーに対するサービスの登録 (PMON による登録 ) はサブネットが異なるリスナーに対しても行われますが -k オプションで指定したネットワーク以外からそのサービスを使用した接続が行われないようにしてください 73

74 ポリシー管理 RAC データベースでの利用についてポリシー管理 RAC データベースでは RAC インスタンスの配置先が動的に変わるため LISTENER_NETWORKS の LOCAL_LISTENER / REMOTE_LISTENER にクラスタを構成する全サーバーの VIP をリストする必要があります 74

75 75

76 11g R2 では CLUSTER と SERVICE_NAME パラメータが追加されました CLUSTER パラメータで Y と指定されている場合 Data Pump のプロセス ( ワーカープロセス ) を複数のインスタンス上で起動が可能となります ( デフォルト CLUSTER=Y) 実際に複数のインスタンスでワーカープロセスが起動するかどうかはデータ量などによって決定されますパラレルスレーブプロセスについては 11g R1 までも複数ノードで起動する場合がありました SERVICE_NAME パラメータを使用することでサービスが稼動しているインスタンス上で Data Pump の処理が行われるように指定することが可能ですまた Data Pump を複数のインスタンスで並列実行する場合ダンプファイルが各ノードからアクセス可能である必要があります 76

77 user1 と user2 でそれぞれ node1 と node4 から同時に Data Pump を実行した場合の DBA_DATAPUMP_SESSIONS DATAPUMP の出力例 : SQL> select * from dba_datapump_sessions order by 1; OWNER_NAME JOB_NAME INST_ID SADDR SESSION_TYPE USER1 SYS_EXPORT_TABLE_ EEF430 DBMS_DATAPUMP USER1 SYS_EXPORT_TABLE_ D49B1C MASTER USER1 SYS_EXPORT_TABLE_01 TABLE 2 36DF361C WORKER USER1 SYS_EXPORT_TABLE_ E951D8 WORKER USER1 SYS_EXPORT_TABLE_ E52D4C EXTERNAL TABLE USER1 SYS_EXPORT_TABLE_ DEE144 EXTERNAL TABLE USER1 SYS_EXPORT_TABLE_ D4C588 EXTERNAL TABLE USER1 SYS_EXPORT_TABLE_ CAD438 WORKER USER2 SYS_EXPORT_TABLE_ CAFEA4 DBMS_DATAPUMP USER2 SYS_EXPORT_TABLE_ DE6200 MASTER USER2 SYS_EXPORT_TABLE_01 TABLE 4 36E52D4C WORKER USER2 SYS_EXPORT_TABLE_ E87DBC EXTERNAL TABLE USER2 SYS_EXPORT_TABLE_ E3AF80 EXTERNAL TABLE USER2 SYS_EXPORT_TABLE_ E8D294 EXTERNAL TABLE USER2 SYS_EXPORT_TABLE_ E52D44 WORKER 14 行が選択されました SQL> Worker プロセスが複数ノードで起動 Data Pump のジョブが複数ノードで実行 77

78 78

79 ノード障害やインターコネクト障害などクラスタからノードを排除する際に CSS は LAN 経由の IPMI power off コマンドで障害ノードを強制的に停止させることが可能ですこれによりよドを強制的に停止させることが可能ですこれによりより確実に早期にノードを排除することができダウンタイムを最小化しますまた CSS により power off の後に power on コマンドも実行されるため障害ノードは自動的に再起動されます Intelligent Platform Management Interface (IPMI) IPMI はサーバープラットフォームの状態 ( 温度電圧ファンバスなど ) 監視や復旧リモート制御を行うための標準インターフェイス仕様です特定のハードウェアシステムやイ OS に依存することなく遠隔からハードウェアの監視管理が可能です Baseboard Management Controller (BMC) BMC はベースボードに実装されたサーバーから独立した管理チップですサーバーがダウンした状態からでもシステムを制御することが可能です IPMI ドライバを利用してユーザープロセスから BMC に IPMI メッセージを送信することでハードウェアの監視管理が可能です 79

80 80

81 IPMI ドライバがロードされている場合はデフォルトで Intelligent Platform Management Interface (IPMI) を使用しますにチェックがされます 81

82 82

83 次の OTN (US) のサイトからダウンロード可能ですまたは Linux ( カーネル以上 ) と Windows (Windows Server 2003 Service Pack 以上 ) プラットフォームで使用可能ですインストールはサーバーとクライアントの 2 つの方法があります 1) サーバーのインストールクラスタを構成する全てのノードにインストールを行いますクラスタが node1 node2 node3 node4 で構成されており node1 をマスターとする場合の Linux プラットフォームでのインストール例 : $./crfinst.pl -i node1,node2,node3,node4node2 node3 node4 -b /data/oracrfdb -m node1 2) クライアントのインストール収集した情報を参照するためにクライアント環境にインストールを行いますクラスタの一部ではないクライアントマシンにインストールします $./crfinst.pl -g < インストールディレクトリ > 83

84 NODENAME 列のノード名をダブルクリックすると該当のノードのノードビューのウィンドウが出現します 84

85 DEVICE 列のデバイス名をダブルクリックすると該当のデバイスのデバイスビューのウィンドウが出現します 85

86 86

87 87

88 88

89 89

90 90

< 写真欄 > 11g R2 Real Application Clusters スキルチェックポイント解説

< 写真欄 > 11g R2 Real Application Clusters スキルチェックポイント解説 Agenda 11g R2 RAC Expert 資格スキルチェック問題の解説トレーニングオンデマンドのご紹介 2 11g R2 RAC Expert 資格試験名 :Oracle Real Application Clusters 11g Release 2 and Grid Infrastructure