3 新しいハードウェアの構成
この項では、新しいハードウェアの構成に必要な次のタスクについて説明します:
ノート:
新しいラックおよび既存のラックは、オペレーティング・システムを含め、Oracle Exadata Database ServerおよびOracle Exadata Storage Serverで同じパッチ・レベルにする必要があります。詳細は、リリースおよびパッチ・レベルの確認を参照してください。- インタフェース名の変更
- 新しいサーバーの設定
Exadata Database Machineのエラスティック構成を拡張する場合は、新しいサーバーを構成する必要があります。 - 新しいラックの設定
新しいラックは工場で構成されます。ただし、既存のラックで使用するためにネットワークおよび構成ファイルを設定する必要があります。 - ユーザー等価の設定
サーバーがオンラインになった後、ユーザー等価を構成してすべてのサーバーを含めることができます。 - クラスタの起動
- Oracle ASMディスク・グループへのグリッド・ディスクの追加
- クラスタへのサーバーの追加
この手順では、サーバーをクラスタに追加する方法について説明します。 - 新しいOracle Exadata Storage Serverのセル・アラートの構成
新しいOracle Exadata Storage Serverにセル・アラートを構成する必要があります。 - 新しいサーバーへのOracle Databaseソフトウェアの追加
- 新しいサーバーへのデータベース・インスタンスの追加
- ラックの再有効化
3.1 インタフェース名の変更
RoCEネットワーク・ファブリック (X8M以降)を備えたシステムでは、結合イーサネット・クライアント・ネットワークにBONDETH0
が使用されます。
InfiniBandネットワーク・ファブリック(X3からX8)を含む後続のシステムでは、通常、BONDIB0
およびBONDETH0
が、結合RDMAネットワーク・ファブリックおよび結合Ethernetクライアント・ネットワークにそれぞれ使用されます。
Oracle Exadata Database Machine X2-2およびそれ以前のシステム(X4170およびX4275サーバー搭載)では、BOND0
およびBOND1
が、それぞれ結合RDMAネットワーク・ファブリックおよび結合イーサネット・クライアント・ネットワークの名前です。
既存のExadata Database Machineに新しいサーバーを追加する場合は、データベース・サーバーが結合構成に同じ名前を使用していることを確認してください。既存のサーバー・インタフェース名に合せて、新しいデータベース・サーバーを変更したり、新しいサーバーに合せて、既存のサーバー・インタフェース名およびOracle Cluster Registry (OCR)構成を変更できます。
インタフェース名の変更後、次の手順を実行します。
-
RDMAネットワーク・ファブリックのエントリが一致するように、データベース・サーバーの
/etc/sysctl.conf
ファイルのエントリを編集します。編集前のファイル・エントリの例は、次のとおりです。片方のセットのエントリは、もう一方のセットと一致するように変更する必要があります。Found in X2 node net.ipv4.neigh.bondib0.locktime = 0 net.ipv4.conf.bondib0.arp_ignore = 1 net.ipv4.conf.bondib0.arp_accept = 1 net.ipv4.neigh.bondib0.base_reachable_time_ms = 10000 net.ipv4.neigh.bondib0.delay_first_probe_time = 1 Found in V2 node net.ipv4.conf.bond0.arp_accept=1 net.ipv4.neigh.bond0.base_reachable_time_ms=10000 net.ipv4.neigh.bond0.delay_first_probe_time=1
-
sysctl.conf
ファイルに変更を保存します。 -
新しい名前がOCRの現在の名前と異なる場合、OCR構成を変更するには、
oifcfg
ユーティリティを使用します。Oracle Exadata Storage Serverのインタフェース名は変更する必要はありません。 -
次のように、新しいハードウェアの構成を続行します。
-
ハードウェアが新しいサーバーの場合は、新しいサーバーの設定に進んでサーバーを構成します。
-
ハードウェアが新しいラックの場合は、新しいラックの設定に進んでラックを構成します。
-
親トピック: 新しいハードウェアの構成
3.2 新しいサーバーの設定
Exadata Database Machineのエラスティック構成の拡張時には、新しいサーバーを構成する必要があります。
新しいサーバーは構成情報を格納しないため、Oracle Enterprise Manager Cloud Controlを使用してサーバーを構成することはできません。Oracle Exadata Deployment Assistant (OEDA)を使用するか手動でサーバーを構成します。
- OEDAを使用したサーバーの構成
Exadata Database Machineにサーバーを追加する場合は、OEDAを使用できます。 - 新しいサーバーの手動構成
Exadata Database Machineにサーバーを追加する場合は、OEDAを使用するかわりにサーバーを手動で構成できます。
親トピック: 新しいハードウェアの構成
3.2.1 OEDAを使用したサーバーの構成
Exadata Database Machineにサーバーを追加する場合は、OEDAを使用できます。
ノート:
Oracle Exadata Deployment Assistant (OEDA)を使用してサーバーを構成するには、新しいサーバー情報をOEDAに入力し、構成ファイルを生成する必要があります。3.3 新しいラックの設定
新しいラックは工場で構成されます。ただし、既存のラックで使用するためにネットワークおよび構成ファイルを設定する必要があります。
-
Oracle Exadata Database Machineインストレーションおよび構成ガイドのOracle Exadata Database Machineの構成の説明に従って、新しいラックおよびサーバーを構成します。
適切なタスクを実行してラックとそのコンポーネントを構成しますが、Exadataの構成情報およびソフトウェアをサーバーにインストールする作業は実行しません。このタスクは、この手順の後半で実行します。
-
新しいサーバーと既存のサーバーで時刻が同じであることを確認します。このチェックはストレージ・サーバーおよびデータベース・サーバーで実行されます。
-
新しいサーバーと既存のサーバーでNTP設定が同じであることを確認します。このチェックはストレージ・サーバーおよびデータベース・サーバーで実行されます。
-
既存のサーバーにあわせて、新しいサーバーでHugePagesを構成します。
-
新しいデータベース・サーバーのRDMAネットワーク・ファブリックおよび結合クライアント・イーサネット・インタフェースの名前が、既存のデータベース・サーバーと一致していることを確認します。
-
Oracle Exadata Database Machineインストレーションおよび構成ガイドの構成情報のロードおよびソフトウェアのインストールの説明に従って、ラックを構成します。Oracle Exadata Deployment Assistant (OEDA)またはOracle Enterprise Manager Cloud Controlを使用して、ラックを構成します。
ノート:
- OEDAを
Create Grid Disks
ステップまで実行した後、Oracle Exadata System Softwareユーザーズ・ガイドのCellCLIを使用したセル、セル・ディスクおよびグリッド・ディスクの構成の説明に従って、ストレージ・サーバーを構成します。 - 3TBの大容量(HC)ディスクを搭載したサーバーを、2TBのディスクを搭載した既存のサーバーに追加する場合、My Oracle Support Doc ID 1476336.1の手順に従って、グリッド・ディスクおよびディスク・グループを適切に定義することをお薦めします。ラックの設定のこの時点では、グリッド・ディスクのみを定義する必要があります。ディスク・グループは、新しいノードでクラスタが拡張された後に作成されます。
- 既存のストレージ・サーバーがExtreme Flash (EF)で、大容量(HC)ストレージ・サーバーを追加する場合、または既存のストレージ・サーバーがHCでEFストレージ・サーバーを追加する場合は、新しいディスクを新しいディスク・グループに配置する必要があります。EFとHCディスクを同じディスク・グループ内に混在させることはできません。
- OEDAを
-
ユーザー等価の設定に進み、ハードウェアの構成を続行します。
3.4 ユーザー等価の設定
サーバーがオンラインになった後、ユーザー等価を構成してすべてのサーバーを含めることができます。
配線後ユーティリティを実行する前に、この手順を実行する必要があります。
-
SSHを使用して新しい各サーバーに手動でログインし、パスワードが正しく各サーバーにログインできることを確認します。
-
すべてのサーバーの
dbs_group
およびcell_group
ファイルを変更して、すべてのサーバーを含めます。-
最初の既存のデータベース・サーバーに新しいディレクトリを作成します。
# mkdir /root/new_group_files # mkdir /root/old_group_files # mkdir /root/group_files
-
新しいサーバーのグループ・ファイルを
/root/new_group_files
ディレクトリにコピーします。 -
既存のサーバーのグループ・ファイルを
/root/old_group_files
ディレクトリにコピーします。 -
既存のサーバーのグループ・ファイルを
/root/group_files
ディレクトリにコピーします。 -
グループ・ファイルを更新して既存のサーバーと新しいサーバーを含めます。
cat /root/new_group_files/dbs_group >> /root/group_files/dbs_group cat /root/new_group_files/cell_group >> /root/group_files/cell_group cat /root/new_group_files/all_group >> /root/group_files/all_group cat /root/new_group_files/dbs_priv_group >> /root/group_files/dbs_priv_group cat /root/new_group_files/cell_priv_group >> /root/group_files/cell_priv_group cat /root/new_group_files/all_priv_group >> /root/group_files/all_priv_group
-
更新したグループ・ファイルをデフォルトのグループ・ファイルにします。更新したグループ・ファイルには、既存のサーバーと新しいサーバーが含まれます。
cp /root/group_files/* /root cp /root/group_files/* /opt/oracle.SupportTools/onecommand
-
更新したグループ・ファイルのコピーを
root
ユーザー、oracle
ユーザーおよびOracle Grid Infrastructureユーザーのホーム・ディレクトリに置き、ファイルがそれぞれのユーザーに所有されていることを確認します。
-
-
既存および新しいデータベース・サーバーの
/etc/hosts
ファイルを変更して、データベース・サーバーおよびストレージ・サーバーの既存のRDMAネットワーク・ファブリックIPアドレスを含めます。既存および新しいall_priv_group
ファイルをこのステップに使用できます。ノート:
あるサーバーから別のサーバーに/etc/hosts
ファイルをコピーしないでください。各サーバーのファイルを編集します。 -
次のコマンドを使用して、既存のデータベース・サーバーのいずれかの
root
ユーザーとしてsetssh-Linux.sh
スクリプトを実行して、すべてのサーバーのユーザー等価を構成します。最初のデータベース・サーバーを使用することをお薦めします。# /opt/oracle.SupportTools/onecommand/setssh-Linux.sh -s -c N -h \ /path_to_file/all_group -n N
前述のコマンドのpath_to_fileは、既存および新しいサーバーの名前が含まれる
all_group
ファイルのディレクトリ・パスです。ノート:
Oracle Exadata Database Machine X2-2 (X4170およびX4275サーバー搭載)システムの場合、
setssh.sh
コマンドを使用して、ユーザー等価を構成します。setssh.sh
コマンドのコマンドライン・オプションは、setssh-Linux.sh
コマンドと異なります。正しい構文を表示するには、パラメータを指定せずにsetssh.sh
を実行します。 -
RDMAネットワーク・ファブリックを使用して、既知のホストを追加します。このステップを実行するには、すべてのデータベース・サーバーがInfiniBandインタフェース経由でアクセスできる必要があります。
# /opt/oracle.SupportTools/onecommand/setssh-Linux.sh -s -c N -h \ /path_to_file/all_priv_group -n N -p password
-
等価が構成されていることを確認します。
# dcli -g all_group -l root date # dcli -g all_priv_group -l root date
-
次のコマンドを使用して、既存のデータベース・サーバーのいずれかで
oracle
ユーザーとしてsetssh-Linux.sh
スクリプトを実行し、すべてのサーバーのユーザー等価を構成します。最初のデータベース・サーバーを使用することをお薦めします。Oracle Grid Infrastructureソフトウェアの別の所有者が存在する場合、所有者ごとに同様のコマンドを実行します。$ /opt/oracle.SupportTools/onecommand/setssh-Linux.sh -s -c N -h \ /path_to_file/dbs_group -n N
前述のコマンドのpath_to_fileは、
dbs_group
ファイルのディレクトリ・パスです。ファイルには、既存のサーバーと新しいサーバーの名前が含まれます。ノート:
-
Oracle Exadata Database Machine X2-2 (X4170およびX4275サーバー搭載)システムの場合、
setssh.sh
コマンドを使用して、ユーザー等価を構成します。 -
このステップのために、
setssh-Linux.sh
ファイルの権限を一時的に755に変更することが必要になる場合があります。このステップが完了したら、権限を元の設定に戻します。
-
-
RDMAネットワーク・ファブリックを使用して、既知のホストを追加します。このステップを実行するには、すべてのデータベース・サーバーがInfiniBandインタフェース経由でアクセスできる必要があります。
$ /opt/oracle.SupportTools/onecommand/setssh-Linux.sh -s -c N -h \ /root/group_files/dbs_priv_group -n N
-
等価が構成されていることを確認します。
$ dcli -g dbs_group -l oracle date $ dcli -g dbs_priv_group -l oracle date
別のOracle Grid Infrastructureユーザーが存在する場合は、そのユーザーにも前述のコマンドを実行し、
oracle
ユーザーのかわりにgrid
ユーザー名を使用します。
親トピック: 新しいハードウェアの構成
3.5 クラスタの起動
次の手順では、追加のラックの配線でクラスタが停止した場合に、クラスタを起動する方法について説明します。
ノート:
-
1台のサーバーを起動し、完全に起動させてから残りのサーバーでOracle Clusterwareを起動することをお薦めします。
-
Oracle Exadata Database Machineハーフ・ラックからフル・ラックに拡張する場合、またはクオータ・ラックからハーフ・ラックまたはフル・ラックに拡張する場合は、クラスタを停止する必要はありません。
-
元のクラスタの
root
ユーザーとしてログインします。 -
クラスタのサーバーを1台起動します。
# Grid_home/grid/bin/crsctl start cluster
-
サーバーのステータスを確認します。
Grid_home/grid/bin/crsctl stat res -t
最初のサーバーが起動したと表示されるまで、前述のコマンドを実行します。
-
クラスタ内の他のサーバーを起動します。
# Grid_home/grid/bin/crsctl start cluster -all
-
サーバーのステータスを確認します。
Grid_home/grid/bin/crsctl stat res -t
すべてのサーバーを起動してクラスタに結合するには、数分かかる場合があります。
親トピック: 新しいハードウェアの構成
3.6 Oracle ASMディスク・グループへのグリッド・ディスクの追加
新しいサーバーをクラスタに追加する前または後に、グリッド・ディスクをOracle ASMディスク・グループに追加できます。新しいサーバーを追加する前にグリッド・ディスクを追加する利点は、リバランス操作を早めに開始できることです。新しいサーバーを追加した後にグリッド・ディスクを追加する利点は、リバランス操作を新しいサーバーで実行できることであり、これにより、既存のサーバーの負荷が減少します。
次の手順は、グリッド・ディスクを既存のOracle ASMディスク・グループに追加する方法を示しています。
ノート:
-
次の例では、新しくインストールしたストレージ・サーバーのグリッド・ディスク構成は既存のストレージ・サーバーと同じで、追加グリッド・ディスクは既存のディスク・グループに追加されることを前提とします。
現在の構成に関して収集される情報は、グリッド・ディスクの設定時に使用するようにしてください。
-
既存のストレージ・サーバーに高パフォーマンス(HP)ディスクがあり、大容量(HC)ディスクを搭載するストレージ・サーバーを追加している場合や、既存のストレージ・サーバーにHCディスクがあり、HPディスクを搭載するストレージ・サーバーを追加している場合は、新しいディスク・グループに新しいディスクを配置する必要があります。同じディスク・グループ内にHPディスクとHCディスクを混在させることはできません。
-
新しいストレージ・サーバーで、すでに使用されているストレージ・サーバーと同じバージョンのソフトウェアが実行されていることを確認します。最初のデータベース・サーバーで次のコマンドを実行します。
dcli -g dbs_group -l root "imageinfo -ver"
ノート:
ストレージ・サーバーのOracle Exadata System Softwareが一致しない場合、ソフトウェアのアップグレードまたはパッチの適用を実行して、同じレベルにします。これにより、既存のサーバーまたは新しいサーバーにパッチを適用できます。詳細は、リリースおよびパッチ・レベルの確認を参照してください。 -
すべてのデータベース・サーバーの
/etc/oracle/cell/network-config/cellip.ora
ファイルを変更して、すべてのストレージ・サーバーの完全なリストを使用します。すべてのデータベース・サーバーでcellip.ora
ファイルを同じにする必要があります。Oracle Exadata Storage Server X4-2Lサーバーを追加する場合、
cellip.ora
ファイルには、各セルにリストされている2個のIPアドレスが含まれます。2個のIPアドレスを含めるために各行を完全にコピーし、既存のクラスタのcellip.ora
ファイルでそのアドレスを統合します。-
任意のデータベース・サーバーから、
cellip.ora
ファイルのバックアップ・コピーを作成します。cp /etc/oracle/cell/network-config cp cellip.ora cellip.ora.orig cp cellip.ora cellip.ora-bak
cellip.ora-bak
ファイルを編集して、新しいストレージ・サーバーのIPアドレスを追加します。-
dcli
を使用して、編集したファイルをすべてのデータベース・ノード上のcellip.ora
ファイルにコピーします。dbnodes
という名前のファイルを使用します。このファイルには、クラスタ内のすべてのデータベース・サーバーの名前が含まれ、各データベース名が別々の行に示されます。cellip.ora-bak
ファイルが格納されているディレクトリから次のコマンドを実行します。/usr/local/bin/dcli -g dbnodes -l root -f cellip.ora-bak -d /etc/oracle/cell/network-config/cellip.ora
次に、Oracle Exadata Storage Server X4-2Lサーバーを使用してOracle Exadata Database Machine X3-2ハーフ・ラックをフル・ラックに拡張した後の
cellip.ora
ファイルの例を示します。cell="192.168.10.9" cell="192.168.10.10" cell="192.168.10.11" cell="192.168.10.12" cell="192.168.10.13" cell="192.168.10.14" cell="192.168.10.15" cell="192.168.10.17;192.168.10.18" cell="192.168.10.19;192.168.10.20" cell="192.168.10.21;192.168.10.22" cell="192.168.10.23;192.168.10.24" cell="192.168.10.25;192.168.10.26" cell="192.168.10.27;192.168.10.28" cell="192.168.10.29;192.168.10.30"
この例では、1行目から7行目が元のサーバー用で、8行目から14行目が新しいサーバー用です。Oracle Exadata Storage Server X4-2Lサーバーには、それぞれ2個のIPアドレスがあります。
-
-
更新された
cellip.ora
ファイルがすべてのデータベース・サーバーに格納されていることを確認します。更新されたファイルには、すべてのストレージ・サーバーの完全なリストが含まれる必要があります。 -
元のデータベース・サーバーのいずれかで、すべてのグリッド・ディスクのアクセスを確認します。
root
ユーザーまたはoracle
ユーザーとして、コマンドを実行できます。$ Grid_home/grid/bin/kfod disks=all dscvgroup=true
コマンドの出力結果には、元のストレージ・サーバーと新しいストレージ・サーバーからのグリッド・ディスクが表示されます。
-
次のようなコマンドを使用して、新しいストレージ・サーバーから既存のディスク・グループにグリッド・ディスクを追加します。高パフォーマンス・ディスクと大容量ディスクの両方を同じディスク・グループに指定することはできません。
$ .oraenv ORACLE_SID = [oracle] ? +ASM1 The Oracle base for ORACLE_HOME=/u01/app/11.2.0/grid is /u01/app/oracle $ sqlplus / as sysasm SQL> ALTER DISKGROUP data ADD DISK 2> 'o/*/DATA*dm02*' 3> rebalance power 11;
前述のコマンドでは、フル・ラックが既存のOracle Exadata Rackに追加されました。新しいラックの接頭辞は
dm02
、グリッド・ディスクの接頭辞はDATA
です。次の例では、Oracle Exadata Database Machineハーフ・ラックがフル・ラックにアップグレードされています。元のシステムのセル・ホスト名には、
dm01cel01
からdm01cel07
の名前が付けられています。新しいセル・ホスト名には、dm01cel08
からdm01cel14
の名前が付けられています。$ .oraenv ORACLE_SID = [oracle] ? +ASM1 The Oracle base for ORACLE_HOME=/u01/app/11.2.0/grid is /u01/app/oracle $ SQLPLUS / AS sysasm SQL> ALTER DISKGROUP data ADD DISK 2> 'o/*/DATA*dm01cel08*', 3> 'o/*/DATA*dm01cel09*', 4> 'o/*/DATA*dm01cel10*', 5> 'o/*/DATA*dm01cel11*', 6> 'o/*/DATA*dm01cel12*', 7> 'o/*/DATA*dm01cel13*', 8> 'o/*/DATA*dm01cel14*' 9> rebalance power 11;
ノート:
-
システムでOracle Database 11gリリース2 (11.2.0.1)を実行している場合、できるだけ迅速にリバランスが完了するように指数制限値に11を使用することをお薦めします。システムでOracle Database 11gリリース2 (11.2.0.2)を実行している場合、指数制限値に32を使用することをお薦めします。指数制限は、リバランス中に実行されているアプリケーションに影響を与えます。
-
異なるOracle ASMインスタンスから
ALTER DISKGROUP
コマンドが実行されていることを確認します。これにより、複数のディスク・グループのリバランス操作をパラレルに実行できます。 -
ディスクを
SYSTEMDG
またはDBFS_DG
を含むすべてのディスク・グループに追加します。 -
3 TBの大容量(HC)ディスクを搭載したサーバーを、2 TBのディスクを搭載した既存のサーバーに追加する場合、My Oracle Supportノート1476336.1の手順に従って、グリッド・ディスクおよびディスク・グループを適切に定義することをお薦めします。ラックの設定のこの時点では、新しいグリッド・ディスクは定義されますが、ディスク・グループに配置される必要があります。My Oracle Supportノート1476336.1のステップを参照してください。
-
既存のストレージ・サーバーに高パフォーマンス(HP)ディスクがあり、大容量(HC)ディスクを搭載するストレージ・サーバーを追加している場合や、既存のストレージ・サーバーにHCディスクがあり、HPディスクを搭載するストレージ・サーバーを追加している場合は、新しいディスク・グループに新しいディスクを配置する必要があります。同じディスク・グループ内にHPディスクとHCディスクを混在させることはできません。
-
-
Oracle ASMインスタンスで次のような問合せを使用して、リバランス操作のステータスを監視します。
SQL> SELECT * FROM GV$ASM_OPERATION WHERE STATE = 'RUN';
リバランスの進行中に、残りのタスクを実行できます。
関連項目:
-
既存のグリッド・ディスクの詳細は、現在の構成情報の取得を参照してください。
-
グリッド・ディスクの構成の詳細は、新しいサーバーの設定を参照してください。
-
ASM_POWER_LIMIT
パラメータの詳細は、Oracle Automatic Storage Management管理者ガイドを参照してください。
親トピック: 新しいハードウェアの構成
3.7 クラスタへのサーバーの追加
次の手順では、サーバーをクラスタに追加する方法について説明します。
Oracle VMクラスタにノードを追加するには、Oracle Exadata Database Machineメンテナンス・ガイドのExadataでのOracle VM RACクラスタの拡張を参照してください。
注意:
Oracle Clusterwareで、Oracle GoldenGateなど、新しいノードにまだインストールされていない追加サービスを管理する場合は次の点に注意してください。
-
addNode.sh
スクリプトを実行する前に、既存のノードでそれらのサービスを停止する必要がある場合があります。 -
これらの追加サービスを実行する新しいデータベース・サーバーに任意のユーザーとグループを作成する必要があります。
-
Oracle Clusterwareが新しいノードでサービスを開始しないように、それらのサービスの自動起動を無効にする必要がある場合があります。
ノート:
既存のノードと新しいノード間でファイルを転送する際に問題が発生するのを防ぐため、SSH等価を設定する必要があります。詳細は、「ExadataでのOracle VM Oracle RACクラスタの拡張」のステップ4を参照してください。-
すべてのデータベース・サーバーの
/etc/oracle/cell/network-config/*.ora
ファイルを、正しく一貫性があるものにします。cellip.ora
ファイルのすべてのデータベース・サーバーには、より古いデータベース・サーバーとストレージ・サーバー、より新しいデータベース・サーバーとストレージ・サーバーを含めます。 -
ORACLE_BASE
およびdiag
宛先ディレクトリがOracle Grid Infrastructure宛先ホームに作成されていることを確認します。次に、Oracle Grid Infrastructure 11
g
の例を示します。# dcli -g /root/new_group_files/dbs_group -l root mkdir -p \ /u01/app/11.2.0/grid /u01/app/oraInventory /u01/app/grid/diag # dcli -g /root/new_group_files/dbs_group -l root chown -R grid:oinstall \ /u01/app/11.2.0 /u01/app/oraInventory /u01/app/grid # dcli -g /root/new_group_files/dbs_group -l root chmod -R 770 \ /u01/app/oraInventory # dcli -g /root/new_group_files/dbs_group -l root chmod -R 755 \ /u01/app/11.2.0 /u01/app/11.2.0/grid
次に、Oracle Grid Infrastructure 12
c
の例を示します。# cd / # rm -rf /u01/app/* # mkdir -p /u01/app/12.1.0.2/grid # mkdir -p /u01/app/oracle/product/12.1.0.2/dbhome_1 # chown -R oracle:oinstall /u01
-
inventory
ディレクトリおよびグリッド・インフラストラクチャ・ホーム・ディレクトリが作成され、適切な権限があることを確認します。ディレクトリの所有者はグリッド・ユーザーでOINSTALL
グループである必要があります。inventory
ディレクトリには770個の権限、Oracle Grid Infrastructureホーム・ディレクトリには755個の権限があります。Oracle Grid Infrastructure 12
c
以降を実行している場合は、次のようにします。-
oraInventory
が/u01/app
内に存在していないことを確認します。 -
/etc/oraInst.loc
が存在していないことを確認します。
-
-
既存のノードと同じユーザー識別子およびグループ識別子を使用して、新しいノードにユーザーおよびグループを作成します。
ノート:
以前にOracle Exadata Deployment Assistant (OEDA)を使用したときに、これらのユーザーおよびグループが作成されています。それらが存在し、UID値とGID値が適切なことを確認します。 -
グリッド・ユーザーとして、既存のホストにログインします。
-
Oracle Cluster Registry (OCR)のバックアップが存在することを確認します。
ocrconfig -showbackup
-
次のようなコマンドを使用して、データベース・サーバーをクラスタに追加できることを確認します。
$ cluvfy stage -post hwos -n \ dm02db01,dm02db02,dm02db03,dm02db04,dm02db05,dm02db06,dm02db07,dm02db08 \ -verbose $ cluvfy comp peer -refnode dm01db01 -n \ dm02db01,dm02db02,dm02db03,dm02db04,dm02db05,dm02db06,dm02db07,dm02db08 \ -orainv oinstall -osdba dba | grep -B 3 -A 2 mismatched $ cluvfy stage -pre nodeadd -n \ dm02db01,dm02db02,dm02db03,dm02db04,dm02db05,dm02db06,dm02db07,dm02db08 \ -verbose -fixup -fixupdir /home/grid_owner_name/fixup.d
前述のコマンドで、gi_owner_nameはOracle Grid Infrastructureソフトウェアの所有者の名前、dm02db01からdb02db08は、新しいデータベース・サーバー、refnodeは既存のデータベース・サーバーです。
ノート:
-
2番目と3番目のコマンドでは、コマンドが正常に完了した場合は出力が表示されません。
-
投票ディスクに関するエラーが次のように表示される場合があります。
ERROR: PRVF-5449 : Check of Voting Disk location "o/192.168.73.102/ \ DATA_CD_00_dm01cel07(o/192.168.73.102/DATA_CD_00_dm01cel07)" \ failed on the following nodes: Check failed on nodes: dm01db01 dm01db01:No such file or directory … PRVF-5431 : Oracle Cluster Voting Disk configuration check
そのようなエラーが発生した場合:
- Oracle Grid Infrastructure 11
g
を実行している場合、環境変数を次のように設定します。$ export IGNORE_PREADDNODE_CHECKS=Y
環境変数を設定しても、
cluvfy
コマンドの実行時のエラーを防止できませんが、addNode.sh
スクリプトは正常に完了できます。- Oracle Grid Infrastructure 12
c
以降を実行している場合、addnode
パラメータの-ignoreSysPrereqs -ignorePrereq
を使用します。Oracle Grid Infrastructure 12
c
以降では、addnode
はIGNORE_PREADDNODE_CHECKS
環境変数を使用しません。 -
データベース・サーバーが特定のイメージでインストールされ、後で以降のイメージにパッチが適用された場合、一部のオペレーティング・システム・ライブラリは
cluvfy
コマンドで期待されるバージョンよりも古い場合があります。この場合、cluvfy
コマンドは失敗し、addNode.sh
スクリプトも失敗する可能性があります。バージョンでの相違が小さな場合は、以前のバージョンを使用できます。たとえば、
glibc-common-2.5-81.el5_8.2
とglibc-common-2.5-49
です。バージョンは異なりますが、両方ともバージョン2.5であるため相違は小さく、違いを許容できます。この問題を回避するために、
addNode.sh
スクリプトを実行する前に環境変数IGNORE_PREADDNODE_CHECKS=Y
を設定するか、addnode
パラメータの-ignoreSysPrereqs -ignorePrereq
をaddNode.sh
スクリプトで使用します。
-
-
既存のサーバーのOracle Grid Infrastructureホーム内のすべてのディレクトリに実行可能なビット・セットがあることを確認します。次のコマンドを
root
ユーザーとして実行します。find /u01/app/11.2.0/grid -type d -user root ! -perm /u+x ! \ -perm /g+x ! -perm o+x find /u01/app/11.2.0/grid -type d -user grid_owner_name ! -perm /u+x ! \ -perm /g+x ! -perm o+x
前述のコマンドのgrid_owner_nameはOracle Grid Infrastructureソフトウェアの所有者の名前で、
/u01/app/11.2.0/grid
はOracle Grid Infrastructureホーム・ディレクトリです。ディレクトリが表示される場合、グループおよびその他の権限が
+x
であることを確認します。Grid_home/network/admin/samples
,$GI_HOME/crf/admin/run/crfmond
およびGrid_home/crf/admin/run/crflogd
ディレクトリには、+x
権限セットが必要な場合があります。Oracle Grid Infrastructure 12
c
以降を実行している場合、次のようなコマンドを実行します。# chmod -R u+x /u01/app/12.1.0.2/grid/gpnp/gpnp_bcp* # chmod -R o+rx /u01/app/12.1.0.2/grid/gpnp/gpnp_bcp* # chmod o+r /u01/app/12.1.0.2/grid/bin/oradaemonagent /u01/app/12.1.0.2/grid/srvm/admin/logging.properties # chmod a+r /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/*O # chmod a+r /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/*0 # chown -f gi_owner_name:dba /u01/app/12.1.0.2/grid/OPatch/ocm/bin/emocmrsp
Grid_home/network/admin/samples
ディレクトリは、+x
権限が必要です:chmod -R a+x /u01/app/12.1.0.2/grid/network/admin/samples
-
次のコマンドを実行します。Oracle Grid Infrastructureホームはグリッド・ユーザーに所有されているとします。
$ dcli -g old_db_nodes -l root chown -f grid_owner_name:dba \ /u01/app/11.2.0/grid/OPatch/ocm/bin/emocmrsp
-
このステップは、Oracle Grid Infrastructure 11
g
を実行している場合にのみ必要です。Oracle Grid Infrastructure 12c
では、値はコマンドラインで指定されるため、レスポンス・ファイルは必要ありません。レスポンス・ファイル
add-cluster-nodes.rsp
をグリッド・ユーザーとして作成し、次のような新しいサーバーを追加します。RESPONSEFILE_VERSION=2.2.1.0.0 CLUSTER_NEW_NODES={dm02db01,dm02db02, \ dm02db03,dm02db04,dm02db05,dm02db06,dm02db07,dm02db08} CLUSTER_NEW_VIRTUAL_HOSTNAMES={dm0201-vip,dm0202-vip,dm0203-vip,dm0204-vip, \ dm0205-vip,dm0206-vip,dm0207-vip,dm0208-vip}
前述のファイルでは、ホスト名
dm02db01
からdb02db08
は、クラスタに追加されている新しいノードです。ノート:
サーバー名を示す複数の行は、連続した1つの行で表示されます。ページ制限により、ドキュメント内で折り返されています。 -
クラスタを拡張する前に、
Grid_home/rdbms/audit
およびGrid_home/log/diag/*
ディレクトリのファイルの大部分が移動または削除されていることを確認します。 -
インストーラがメモリー不足になる場合は、My Oracle Supportノート744213.1を参照してください。このノートは、
Grid_home/oui/ora-param.ini
ファイルを編集する方法、およびJRE_MEMORY_OPTIONS
パラメータを-Xms512m-Xmx2048m
に変更する方法について説明しています。 -
グリッド・ユーザーとして既存のサーバーから
addNode.sh
スクリプトを実行して、新しいサーバーを追加します。-
Oracle Grid Infrastructure 11
g
を実行している場合は、次のようにします。$ cd Grid_home/oui/bin $ ./addNode.sh -silent -responseFile /path/to/add-cluster-nodes.rsp
-
Oracle Grid Infrastructure 12
c
以降を実行している場合は、addnode.sh
コマンドをCLUSTER_NEW_NODES
およびCLUSTER_NEW_VIRTUAL_HOSTNAMES
パラメータを指定して実行します。構文は次のとおりです。$ ./addnode.sh -silent "CLUSTER_NEW_NODES={comma_delimited_new_nodes}" "CLUSTER_NEW_VIRTUAL_HOSTNAMES={comma_delimited_new_node_vips}"
次に例を示します。
$ cd Grid_home/addnode/ $ ./addnode.sh -silent "CLUSTER_NEW_NODES={dm02db01,dm02db02,dm02db03,dm02db04,dm02db05, dm02db06,dm02db07,dm02db08}" "CLUSTER_NEW_VIRTUAL_HOSTNAMES={dm02db01-vip,dm02db02-vip, dm02db03-vip,dm02db04-vip,dm02db05-vip,dm02db06-vip,dm02db07-vip,dm02db08-vip}" -ignoreSysPrereqs -ignorePrereq
-
-
グリッド・ディスクが新しいデータベース・サーバーのそれぞれから表示できることを確認します。
$ Grid_home/grid/bin/kfod disks=all dscvgroup=true
-
要求された場合、
dcli
ユーティリティを使用して、root
ユーザーとしてorainstRoot.sh
スクリプトを実行します。$ dcli -g new_db_nodes -l root \ /u01/app/oraInventory/orainstRoot.sh
-
新しいサーバーでHAIPを無効にします。
root.sh
スクリプトを実行する前に、新しい各サーバーで環境変数HAIP_UNSUPPORTED
をTRUE
に設定します。$ export HAIP_UNSUPPORTED=true
-
Grid_home/root.sh
スクリプトを、順次、各サーバーで実行します。これによりプロセスが簡略化され、問題を明確に識別して対処できます。ノート:
ノード識別子は、root.sh
スクリプトが実行されるノードの順に設定されます。通常、スクリプトは番号の最も小さいノードから最も大きいノードに実行されます。 -
root.sh
スクリプトからログ・ファイルをチェックし、次のサーバーに進む前にサーバーに問題がないことを確認します。問題がある場合、先に進む前に問題を解決します。 -
サーバーの追加後のクラスタのステータスを確認します。
$ cluvfy stage -post nodeadd -n \ dm02db01,dm02db02,dm02db03,dm02db04,dm02db05,dm02db06,dm02db07,dm02db08 \ -verbose
-
すべてのサーバーが追加され、基本サービスが実行されていることを確認します。
crsctl stat res -t
ノート:
場合によっては、新しいサーバーのディスク・グループをマウントする必要があります。
oracle
ユーザーとして次のコマンドを実行する必要があります。$ srvctl start diskgroup -g data $ srvctl start diskgroup -g reco
-
Oracle Grid Infrastructureリリース11.2.0.2以降を実行している場合、次のステップを実行します。
-
CLUSTER_INTERCONNECTS
パラメータを各Oracle ASMインスタンスのSPFILEに手動で追加します。ALTER SYSTEM SET cluster_interconnects = '192.168.10.x' \ sid='+ASMx' scope=spfile
-
新しい各サーバーでクラスタを再起動します。
-
パラメータが正しく設定されていることを確認します。
-
親トピック: 新しいハードウェアの構成
3.8 新しいOracle Exadata Storage Serverのセル・アラートの構成
新しいOracle Exadata Storage Serverにセル・アラートを構成する必要があります。
構成は設置のタイプによって異なります。
-
Oracle Exadata Database Machineラックを拡張する場合:
新しいストレージ・サーバーに手動でセル・アラートを構成します。元のストレージ・サーバーの設定をガイドとして使用します。元のストレージ・サーバーの設定を表示するには、次のようなコマンドを使用します。
dcli -g new_cells_nodes -l celladmin cellcli -e list cell detail
新しいストレージ・サーバーのアラート通知を構成するには、次のようなコマンドを使用します。
dcli -g new_cell_nodes -l root "cellcli -e ALTER CELL \ mailServer=\'mail_relay.example.com\' \ smtpPort=25, \ smtpUseSSL=false,smtpFrom=\'DBM dm01\', \ smtpFromAddr=\'storecell@example.com\', \ smtpToAddr=\'dbm-admins@example.com\', \ notificationMethod=\'mail,snmp\', \ notificationPolicy=\'critical,warning,clear\', \ snmpSubscriber=\(\(host=\'snmpserver.example.com, port=162\')\)"
ノート:
dcliユーティリティのエスケープ文字および前述のコマンドの行継続文字として、バックスラッシュ(\
)が使用されます。 -
ラックを配線する場合:
root
ユーザーとしてOracle Exadata Deployment Assistant (OEDA)を使用して、元のラックから新しいラックにストレージ・サーバーの電子メール・アラートを設定します。このユーティリティにはアラートを構成するSetupCellEmailAlertsステップが含まれます。
親トピック: 新しいハードウェアの構成
3.9 新しいサーバーへのOracle Databaseソフトウェアの追加
クラスタ変更が完了してすべてのサーバーがクラスタに配置された後、Oracle Databaseソフトウェア・ディレクトリORACLE_HOME
をデータベース・サーバーに追加する必要があります。
-
Oracle_home/bin
ディレクトリで、root
ユーザーが所有し、oinstall
権限や全ユーザー読取り権限がない、nmb0
のようにゼロ(0)で終わるファイルがないか確認します。次のコマンドを使用して、ファイルの権限を変更します。# chmod a+r $ORACLE_HOME/bin/*0
Oracle Database release 12c以降を実行している場合、ゼロで終了するファイルに加え、大文字のOで終了するファイルの権限を変更する必要もあります。
# chmod a+r $ORACLE_HOME/bin/*O
-
このステップは、Oracle Database 11gのみで必要です。Oracle Database 12cを実行している場合、ディレクトリが作成済のため、このステップをスキップできます。
次のコマンドを使用してOracle Grid Infrastructureソフトウェアの所有者(グリッド・ユーザー)ではない場合、データベース所有者の
ORACLE_BASE
ディレクトリを作成します。# dcli -g root/new_group_files/dbs_group -l root mkdir -p /u01/app/oracle # dcli -g root/new_group_files/dbs_group -l root chown oracle:oinstall \ /u01/app/oracle
-
次のコマンドを実行して、Oracle Database
$ORACLE_HOME
ディレクトリのemocmrsp
ファイルの所有権を設定します。# dcli -g old_db_nodes -l root chown -f oracle:dba \ /u01/app/11.2.0/grid/OPatch/ocm/bin/emocmrsp
-
このステップは、Oracle Database 11gのみで必要です。Oracle Database 12cを実行している場合、値はコマンドライン上で入力されるため、このステップをスキップできます。
oracle
所有者としてレスポンス・ファイルadd-db-nodes.rsp
を作成し、次のような新しいサーバーを追加します。RESPONSEFILE_VERSION=2.2.1.0.0 CLUSTER_NEW_NODES={dm02db01,dm02db02,dm02db03,dm02db04,dm02db05, \ dm02db06,dm02db07,dm02db08}
ノート:
サーバー名を示す複数の行は、連続した1つの行で表示されます。ページ制限により、ドキュメント内で折り返されています。 -
データベース所有者のユーザーとして既存のサーバーから
addNode.sh
スクリプトを実行して、Oracle DatabaseORACLE_HOME
ディレクトリを新しいサーバーに追加します。-
Oracle Grid Infrastructure 11gを実行している場合は、次のようにします。
$ cd $ORACLE_HOME/oui/bin $ ./addNode.sh -silent -responseFile /path/to/add-db-nodes.rsp
-
Oracle Grid Infrastructure 12cを実行している場合、コマンドラインでノードを指定します。構文は次のとおりです。
./addnode.sh -silent "CLUSTER_NEW_NODES={comma_delimited_new_nodes}"
次に例を示します。
$ cd $Grid_home/addnode $ ./addnode.sh -silent "CLUSTER_NEW_NODES={dm02db01,dm02db02,dm02db03,dm02db04,dm02db05, dm02db06,dm02db07,dm02db08}" -ignoreSysPrereqs -ignorePrereq
-
-
$ORACLE_HOME/oui/oraparam.ini
ファイルに、Oracle Grid Infrastructureホームで設定されたパラメータと一致するメモリー設定があることを確認します。 -
要求された場合、dcliユーティリティを使用して、
root
ユーザーとして各サーバーにroot.sh
スクリプトを実行します。$ dcli -g new_db_nodes -l root $ORACLE_HOME/root.sh
前述のコマンドのnew_db_nodesは、新しいデータベース・サーバーのリストを含むファイルです。
-
ORACLE_HOME
ディレクトリが新しいサーバーに追加されていることを確認します。# dcli -g /root/all_group -l root du -sm \ /u01/app/oracle/product/11.2.0/dbhome_1
親トピック: 新しいハードウェアの構成
3.10 新しいサーバーへのデータベース・インスタンスの追加
データベース・インスタンスを新しいサーバーに追加する前に、次をチェックします。
-
最大ファイル・サイズ: データファイルが最大ファイル・サイズに達すると、
addInstance
コマンドがORA-00740エラーで停止する場合があります。DBA_DATA_FILES
に示されているファイルがいずれも最大サイズに達していないことを確認することをお薦めします。最大サイズに達したファイルは修正するようにしてください。 -
オンラインREDOログ:
DB_RECOVERY_FILE_DEST
パラメータで指定されたディレクトリにオンラインREDOログが保持されている場合は、割り当てられている領域が、追加する新しいインスタンスのREDOログに対して十分にあることを確認します。必要に応じて、DB_RECOVERY_FILE_DEST_SIZE
パラメータのサイズを増加します。 -
クラスタのインスタンスの合計数: 各データベースのSPFILEで初期化パラメータ
cluster_database_instances
の値を、新しいサーバーを追加した後のクラスタ内のインスタンスの合計数に設定します。 -
HugePages設定は、既存のサーバーに一致するように新しいサーバーで正しく構成されます。
-
既存のデータベース・サーバーから次のようなコマンドを使用して、新しいサーバーにインスタンスを追加します。このコマンドでは、インスタンス
dbm9
がサーバーdm02db01
に追加されています。dbca -silent -addInstance -gdbName dbm -nodeList dm02db01 -instanceName dbm9 \ -sysDBAUsername sys
必要に応じてサーバー名およびインスタンス名を置き換えて、コマンドをすべてのサーバーおよびインスタンスで実行する必要があります。
ノート:
コマンドが失敗する場合は、REDOログ・ファイルなど、作成したファイルがクリーンアップされていることを確認します。deleteInstance
コマンドでは、addInstance
コマンドによって作成されたログ・ファイルまたはデータファイルはクリーンアップされません。 -
CLUSTER_INTERCONNECTS
パラメータを新しい各インスタンスに追加します。-
CLUSTER_INTERCONNECTS
パラメータを新しい各データベース・インスタンスのSPFILEに手動で追加します。追加内容は既存のエントリと似ていますが、各インスタンスが実行されるサーバーに対応するRDMAネットワーク・ファブリックのアドレスです。 -
新しい各サーバーでインスタンスを再起動します。
-
パラメータが正しく設定されていることを確認します。
-
親トピック: 新しいハードウェアの構成
3.11 ラックの再有効化
次の手順を使用して、新しいハードウェアが正しく構成されて使用できることを確認します。
-
RDMAネットワーク・ファブリック・ケーブルが接続され固定されていることを確認します。
- RoCEの場合は、My Oracle Supportから入手できる
verify_roce_cables.py
スクリプトを実行します。 - InfiniBandの場合は、
/opt/oracle.SupportTools/ibdiagtools/verify-topology
コマンドを実行します。
- RoCEの場合は、My Oracle Supportから入手できる
-
My Oracle Supportノート1070954.1に説明されているステップに従って、Oracle Exadata Database Machine HealthCheckユーティリティを実行します。
-
次のコマンドを使用して、インスタンスの追加を確認します。
srvctl config database -d dbm srvctl status database -d dbm
-
次のコマンドを使用して、クラスタ・リソースを確認します。
crsctl stat res -t
-
元のクラスタ・デプロイメントの元の構成サマリー・レポートが更新されてすべてのサーバーが含まれていることを確認します。このドキュメントには、新しいラックの補正とネットワーク検証、およびRDMAネットワーク・ファブリック・ケーブルのチェックが含まれます。
-
可能な場合は、電源切断テストを実行します。新しいExadata Storage Serverの電源を切断できない場合は、新しいインスタンスを使用する新しいデータベース・サーバーの電源を切断および投入でき、すべてのプロセスが自動的に開始されることを確認します。
ノート:
Oracle ASMディスク・リバランス・プロセスがすべてのディスク・グループに対して完了していることを確認します。SQL*Plusを使用してOracle ASMインスタンスに接続し、次のコマンドを発行します。
SELECT * FROM gv$asm_operation;
このコマンドでは、行は返されません。
-
次のような構成設定を確認します。
- すべての並列処理設定
- バックアップ構成
- 存在する場合、スタンバイ・サイト
- サービス構成
- Oracle Database File System (DBFS)構成および新規サーバー上のマウント・ポイント(X7以降のサーバーでは必要ありません)
- 新しいデータベース・サーバーのOracle Enterprise HugePage Managerエージェントのインストール
- HugePages設定
-
新しいセルおよびデータベース・サーバーをOracle自動サービス・リクエスト(ASR)に組み込みます。
-
Oracle Enterprise Manager Cloud Controlを更新して、新しいノードを含めます。