2 Oracle Exadata Database Machineのデータベース・サーバーの保守
この章のトピックは、次のとおりです:
- データベース・サーバー上の管理サーバー
- Oracle Database Serverのハード・ディスクの保守
- Exadata Database Serverのフラッシュ・ディスクの保守
- データベース・サーバーへのディスク拡張キットの追加
- データベース・サーバーへのメモリー拡張キットの追加
- X7用クライアント・ネットワーク・ポートのリンク速度の検証および変更
- Oracle Exadata X6-2およびX7-2でのネットワーク・カードの追加および構成
- データベース・サーバーのアクティブ・コア数の増加
- LVMパーティションの拡張
- Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成
- Oracle Virtual Serverデプロイメントの管理ドメイン(dom0)とユーザー・ドメイン(domU)のバックアップ
- スナップショット・ベースのバックアップを使用したOracle Linuxデータベース・サーバーのリカバリ
- Oracle VM Serverデプロイメントでのリカバリ
- Oracle Exadata Database Serverの再イメージ化
- データベース・サーバーの既存のエラスティック構成の変更
- 高冗長性ディスク・グループのためのQuorumディスクの管理
- vmetricsの使用
注意:
読みやすさを考慮して、Oracle Exadata Database MachineとOracle Exadata Storage拡張ラックの両方に言及する場合、「Oracle Exadataラック」という名前を使用します。2.1 データベース・サーバー上の管理サーバー
データベース・サーバー上で実行される管理サーバー(MS)は監視やアラートなどの管理機能を提供します。DBMCLIコマンドライン管理ツールも提供します。
関連項目:
-
Oracle Exadata Database Machineシステム概要ガイドのデータベース・サーバー上の管理サーバー
2.2 Oracle Database Serverのハード・ディスクの保守
ハード・ディスクを修理する際には、Oracle Exadata Database Machineのデータベース・サーバーを停止する必要はありません。
ラックの停止時間は必要ありませんが、個別のサーバーが停止して、一時的にクラスタの外部で処理される場合があります。
2.2.1 データベース・サーバー構成の検証
ディスクの構成はRAID-5構成です。
各データベース・サーバーのディスク・ドライブは、MegaRAID SASディスク・コントローラによって管理されます。
表2-1 Exadata Database Machine Two-Socket Systemsのディスク構成
| サーバー・タイプ | RAIDコントローラ | ディスク構成 |
|---|---|---|
|
Oracle Exadata Database Machine X7-2 |
MegaRAID SAS 9361-16i |
データベース・サーバーごとにの4つのディスク・ドライブ |
|
Oracle Exadata Database Machine X6-2 |
MegaRAID SAS 9361-8i |
データベース・サーバーごとにの4つのディスク・ドライブ |
|
Oracle Exadata Database Machine X5-2 |
MegaRAID SAS 9361-8i |
データベース・サーバーごとにの4つのディスク・ドライブ |
|
Oracle Exadata Database Machine X4-2 |
MegaRAID SAS 9261-8i |
データベース・サーバーごとにの4つのディスク・ドライブ |
|
Oracle Exadata Database Machine X3-2 |
MegaRAID SAS 9261-8i |
データベース・サーバーごとにの4つのディスク・ドライブ |
|
Oracle Exadata Database Machine X2-2 |
MegaRAID SAS 9261-8i |
データベース・サーバーごとにの4つのディスク・ドライブ |
表2-2 Exadata Database Machine Eight-Socket Systemsのディスク構成
| サーバー・タイプ | RAIDコントローラ | ディスク構成 |
|---|---|---|
|
Oracle Exadata Database Machine X7-8 |
MegaRAID SAS 9361-16i |
データベース・サーバーごとに2つのNVMeフラッシュ・アクセラレータ・カード |
|
Oracle Exadata Database Machine X5-8 |
MegaRAID SAS 9361-8i |
データベース・サーバーごとに8つのディスク・ドライブとともに、RAIDセット全体にわたって作成された1つの仮想ドライブ |
|
Oracle Exadata Database Machine X4-8 |
MegaRAID SAS 9261-8i |
デフォルトで1つのグローバル・ホット・スペア・ドライブを搭載した1つの6ディスクRAID-5として構成された、データベース・サーバーごとに7つのディスク・ドライブ |
|
Oracle Exadata Database Machine X3-8 |
MegaRAID SAS 9261-8i |
データベース・サーバーごとに8つのディスク・ドライブとともに、RAIDセット全体にわたって作成された1つの仮想ドライブ |
データベース・サーバーRAIDデバイスのステータスを確認して、パフォーマンスへの影響がないか、または停止しないようにすることをお薦めします。RAIDデバイスの検証による影響は最小です。是正処置による影響は未対応の特定の問題によって異なり、単純な再構成から停止が必要になる場合があります。
2.2.1.1 ディスク・コントローラ構成の検証
ディスク・コントローラの確認
次のコマンドを使用して、すべてのシステム(Oracle Exadata Database Machine X7-8を除く)のデータベース・サーバーのディスク・コントローラ構成を確認します。
if [[ -d /proc/xen && ! -f /proc/xen/capabilities ]]
then
echo -e "\nThis check will not run in a user domain of a virtualized environment. Execute this check in the management domain.\n"
else
if [ -x /opt/MegaRAID/storcli/storcli64 ]
then
export CMD=/opt/MegaRAID/storcli/storcli64
else
export CMD=/opt/MegaRAID/MegaCli/MegaCli64
fi
RAW_OUTPUT=$($CMD AdpAllInfo -aALL -nolog | grep "Device Present" -A 8);
echo -e "The database server disk controller configuration found is:\n\n$RAW_OUTPUT";
fi;注意:
この確認は、従来型のディスク・ドライブを一切装備しないOracle Exadata Database Machine X7-8データベース・サーバーには適用されません。次に、ディスク拡張キットのないOracle Exadata Database Machine 2ソケット・システム(X2-2以降)に対するコマンドの出力例を示します。
Device Present
================
Virtual Drives : 1
Degraded : 0
Offline : 0
Physical Devices : 5
Disks : 4
Critical Disks : 0
Failed Disks : 0
次に、Oracle Exadata Database Machine X4-8フル・ラックのコマンドの出力例を示します。
Device Present
================
Virtual Drives : 1
Degraded : 0
Offline : 0
Physical Devices : 8
Disks : 7
Critical Disks : 0
Failed Disks : 0
次に、Oracle Exadata Database Machine X5-8またはX6-8 フル・ラックのコマンドの出力例を示します。
Device Present
================
Virtual Drives : 1
Degraded : 0
Offline : 0
Physical Devices : 9
Disks : 8
Critical Disks : 0
Failed Disks : 0
Oracle Exadata Database Machine X4-2、Oracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X2-2の場合、予想される出力は仮想ドライブ1、パフォーマンス低下0、オフライン0、物理デバイス5 (1つのコントローラと4つのディスク)、ディスク4、クリティカル・ディスク0、障害が発生したディスク0です。
Oracle Exadata Database Machine X3-8フル・ラックおよびOracle Exadata Database Machine X2-8フル・ラックの場合、予想される出力は仮想ドライブ1、パフォーマンス低下0、オフライン0、物理デバイス11 (1つのコントローラ、2つのSAS2拡張ポートおよび8つのディスク)、ディスク8、クリティカル・ディスク0、障害が発生したディスク0です。
出力が異なる場合は、問題点を調査して修正します。パフォーマンスが低下した仮想ドライブは、通常は存在しない物理ディスクまたは障害が発生したディスクです。ノードで障害が発生したディスクの数が、システムの動作を維持するのに必要な数を超えた場合は、データ損失のリスクを回避するために、クリティカル・ディスクをすぐに交換してください。障害が発生したディスクもすぐに交換してください。
注意:
その他の仮想ドライブまたはホット・スペアが存在する場合は、デプロイ時にディスク再利用手順が実行されなかったか、dualboot=no修飾子を使用せずにベア・メタル・リストア手順が実行された可能性があります。詳細および是正処置は、Oracleサポート・サービスに問い合せてください。また、My Oracle Supportノート1323309.1を参照してください。
ホット・スペアがあるデータベース・サーバーをOracle Exadata System Softwareリリース11.2.3.2.0以上にアップグレードする場合、ホット・スペアは削除され、アクティブ・ドライブとしてRAID構成に追加されます。データベース・サーバーはRAID5冗長性の観点では同じ可用性で稼働し続け、ドライブが1つ失われても存続できます。ドライブで障害が発生した場合は、Oracle Auto Service Request (ASR)により、そのドライブをできるだけ早く交換するように求める通知が送信されます。
Oracle Exadata Database Machine X7-8のディスク・コントローラの確認
次に示すようにmdstatの問合せを実行して、Oracle Exadata Database Machine X7-8のデータベース・サーバーのディスク・コントローラ構成を表示します。
[root@dbnode01adm01 ~]# cat /proc/mdstat
Personalities : [raid1]
md34 : active raid1 nvme3n1[1] nvme1n1[0]
3125613568 blocks super external:/md126/0 [2/2] [UU]
md24 : active raid1 nvme2n1[1] nvme0n1[0]
262144000 blocks super external:/md127/0 [2/2] [UU]
md25 : active raid1 nvme2n1[1] nvme0n1[0]
2863467520 blocks super external:/md127/1 [2/2] [UU]
md126 : inactive nvme3n1[1](S) nvme1n1[0](S)
6306 blocks super external:imsm
md127 : inactive nvme2n1[1](S) nvme0n1[0](S)
6306 blocks super external:imsm
unused devices: <none> 出力が異なる場合は、問題点を調査して修正します。パフォーマンスが低下した仮想ドライブは、通常は存在しない物理ディスクまたは障害が発生したディスクです。状態に対して[1/2]および[U_]または[_U]を示すディスクは、NVMEディスクのいずれかが停止していることを示します。障害が発生したディスクはすぐに交換してください。
2.2.1.2 仮想ドライブ構成の検証
仮想ドライブの構成を検証するには、次のコマンドを使用して、仮想ドライブの構成を検証します。
/opt/MegaRAID/MegaCli/MegaCli64 CfgDsply -aALL | grep "Virtual Drive:"; \
/opt/MegaRAID/MegaCli/MegaCli64 CfgDsply -aALL | grep "Number Of Drives"; \
/opt/MegaRAID/MegaCli/MegaCli64 CfgDsply -aALL | grep "^State"
次に、Oracle Exadata Database Machine X4-2、Oracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X2-2の場合の出力例を示します。仮想デバイス0は4つのドライブを持ち、状態はOptimalです。
Virtual Drive : 0 (Target Id: 0)
Number Of Drives : 4
State : Optimal
Oracle Exadata Database Machine X3-8フル・ラックおよびOracle Exadata Database Machine X2-8フル・ラックの場合は、仮想デバイスが8つのドライブを持ち、状態がOptimalであることを示す出力が表示されると予想されます。
注意:
データベース・サーバーでdualboot=noオプションを使用しないでディスク交換がされた場合、データベース・サーバーには3つの仮想デバイスがある可能性があります。詳細および是正処置は、Oracleサポートにお問合せください。また、My Oracle Supportノート1323309.1を参照してください。
2.2.1.3 物理ドライブ構成の検証
クリティカル・ディスク、機能が低下したディスクまたは障害が発生したディスクについてシステムを調査します。
物理ドライブの構成を検証するには、次のコマンドを使用して、データベース・サーバーの物理ドライブの構成を検証します。
/opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL | grep "Firmware state"
次に、Oracle Exadata Database Machine X4-2、Oracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X2-2の場合の出力例を示します。
Firmware state: Online, Spun Up
Firmware state: Online, Spun Up
Firmware state: Online, Spun Up
Firmware state: Online, Spun Up
ドライブの状態は、Online, Spun Upと表示されている必要があります。出力順序は重要ではありません。Oracle Exadata Database Machine X3-8フル・ラックまたはOracle Exadata Database Machine X2-8フル・ラックの場合は、Online, Spun Upの状態を示す出力が8行になります。
出力が異なる場合は、問題点を調査して修正します。
パフォーマンスが低下した仮想ドライブは、通常は存在しない物理ディスクまたは障害が発生したディスクです。ノードで障害が発生したディスクの数が、システムの動作を維持するのに必要な数を超えた場合は、データ損失のリスクを回避するために、クリティカル・ディスクをすぐに交換してください。障害が発生したディスクはすぐに交換してください。
2.2.2 データベース・サーバーRAIDセットの再構築の監視
データベース・サーバーのRAIDセットのドライブを交換した場合は、RAIDセットの再構築の進捗状況を監視する必要があります。
ディスクを交換したデータベース・サーバーで次のコマンドを使用します。コマンドはrootユーザーとして実行します。
/opt/MegaRAID/MegaCli/MegaCli64 -pdrbld -showprog -physdrv \ [disk_enclosure:slot_number] -a0
前述のコマンドで、disk_enclosureおよびslot_numberは、MegaCli64 -PDListコマンドによって識別された交換ディスクを示します。次に、コマンドの出力例を示します。
Rebuild Progress on Device at Enclosure 252, Slot 2 Completed 41% in 13 Minutes.
2.2.3 Oracle Exadata System Softwareリリース12.1.2.1.0以上へのアップグレード後のホット・スペア・ドライブのリクレイム
Oracle Exadata System Softwareリリース12.1.2.1.0以上にアップグレードしたホット・スペア・ドライブがあるOracle Exadata Database Machineは、reclaimdisks.shスクリプトを使用してドライブをリクレイムできません。手動でドライブをリクレイムする手順は、次のとおりです。
注意:
この手順の実行中に、データベース・サーバーが2度再起動されます。この項の手順では、サーバーの再起動の後、Oracle Grid Infrastructureの再起動が無効であることを前提としています。
ディスクが4つあるOracle Exadata Database Machine X2-2データベース・サーバーの出力例を、次に示します。エンクロージャ識別子、スロット番号などは、使用するシステムにより異なる場合があります。
2.2.4 自動ファイル削除のポリシーについて
管理サーバー(MS)には、データベース・サーバーの/ (root)ディレクトリに関するファイル削除ポリシーがあり、ファイル・システムの使用率が高い場合にトリガーされます。ファイルの削除はファイル使用率が80パーセントの場合にトリガーされ、削除開始前にアラートが送信されます。アラートには、ディレクトリの名前と、サブディレクトリの領域の使用率が含まれます。削除ポリシーは次のとおりです。
次に示すディレクトリ内のファイルは、ファイル変更のタイム・スタンプに基づいたポリシーを使用して削除されます。
-
/opt/oracle/dbserver/log -
/opt/oracle/dbserver/dbms/deploy/config/metrics -
/opt/oracle/dbserver/dbms/deploy/log
metricHistoryDays属性によって設定された日数より古いファイルが最初に削除され、続けて古いファイルから変更タイムスタンプが10分以前のファイル、またはファイル・システムの使用率が75パーセントまでのファイルが削除されます。metricHistoryDays属性は/opt/oracle/dbserver/dbms/deploy/config/metrics内のファイルに適用されます。その他のログ・ファイルとトレース・ファイルには、diagHistoryDays属性を使用します。
Oracle Exadata System Softwareリリース12.1.2.2.0以降では、ms-odl.trcファイルとms-odl.logファイルの領域の最大容量は、*.trcファイル用が100 MB (20個の5 MBファイル)、*.logファイル用が100 MB (20個の5 MBファイル)です。以前は、*.trcファイルと*.logファイルの両方とも、50 MB (10個の5 MBファイル)でした。
ms-odl生成ファイルは5 MBに達すると名前が変更され、100 MBの領域を使い切ると、最も古いファイルが削除されます。
2.3 Exadata Database Serverのフラッシュ・ディスクの保守
Exadata Database Machine X7-8以上のデータベース・サーバーでは、ハード・ディスクのかわりにフラッシュ・デバイスが使用されます。これらのフラッシュ・デバイスは、サーバーを停止しなくても交換できます。
2.3.1 フラッシュ・ディスクのステータスの監視
DBMCLI LIST PHYSICALDISKコマンドを使用して属性をチェックすることによって、Exadata Database Machineのフラッシュ・ディスクのステータスを監視できます。
たとえば、障害と同等のフラッシュ・ディスク・ステータスの問題が発生し、交換が必要である場合などです。
Exadata Database Serverのフラッシュ・ディスク・ステータスは次のとおりです。
-
正常
-
正常 - 交換のため切断
-
失敗
-
障害 - 交換のため切断
-
障害 - 不適切なディスク・モデルのため拒否
-
障害 - 不適切なディスク・モデルのため拒否 - 交換のため切断
-
障害 - 間違ったスロットのため拒否
-
障害 - 間違ったスロットのため拒否 - 交換のため切断
-
警告 - ピア障害
-
警告 - 予測障害、ライトスルー・キャッシュ
-
警告 - 予測障害
-
警告 - 予測障害 - 交換のため切断
-
警告 - ライトスルー・キャッシュ
2.4 データベース・サーバーへのディスク拡張キットの追加
ディスク拡張キットは、一部のOracle Exadata Database Serverに追加できます。
以下の制限に注意してください。
-
ディスク拡張キットはOracle Exadata Database Machine X5-2、X6-2およびX7-2システムでのみサポートされています。
-
Oracle Exadata System Softwareリリース12.1.2.3.0以降が必要です。
2.5 データベース・サーバーへのメモリー拡張キットの追加
データベース・サーバーにはメモリーを追加できます。メモリーの追加手順は、次のとおりです。
注意:
-
Sun Server X4-2 Oracle Database ServerおよびSun Server X3-2 Oracle Database Server用のメモリーは、メモリー拡張キットを使用して最大512GBに拡張できます。
-
Sun Fire X4170 Oracle Database Serverのメモリーは、既存のメモリーを取り外して、3個のX2-2メモリー拡張キットと交換することで、最大144GBに拡張できます。
-
Sun Fire X4170 M2 Oracle Database Serverは、8GB DIMMを使用した18個のDIMMスロットのうち12個が搭載された96GBのメモリーで工場から出荷されます。オプションのX2-2メモリー拡張キットを使用すると、残りの6つの空スロットに16GB DIMMを使用して合計メモリーを192GB (12 x 8GBおよび6 x 16GB)に拡張できます。
メモリー拡張キットは、主に各データベース・サーバー上で多くのデータベースを実行する場合のワークロード統合用です。このシナリオでは、メモリー使用率が非常に高くても、CPU使用率が低いことがよくあります。
ただし、DIMMメモリーの周波数が1333MHzから800MHzに落ちるため、すべてのメモリー・スロットの使用量は減ります。メモリーのパフォーマンス効果が遅いので、CPU使用率が高くなったように感じます。CPU使用率を測定すると、通常、増加率は平均して5%から10%です。増加量はワークロードによって大きく異なります。テスト用ワークロードでは、複数ワークロードの場合、増加率はほぼゼロでしたが、1つのワークロードの場合の増加率は約20%でした。
-
Oracle Linuxを実行しているOracle Exadata Database Machineにメモリーを追加する場合、次の値を使用して
/etc/security/limits.confファイルを更新することをお薦めします。oracle soft memlock 75% oracle hard memlock 75%
2.6 X7用クライアント・ネットワーク・ポートのリンク速度の検証および変更
Oracle Exadata Database Machine X7-2およびOracle Exadata Database Machine X7-8計算ノードに、正しいリンク速度を使用していることを確認してください。
注意:
クライアント・ネットワーク・ポートは、X7-2およびX7-8システムのデプロイメント時に、Oracle Exadata Deployment Assistant (OEDA)を使用して構成する必要があります。OEDAの「顧客ネットワーク構成ページ」を参照してください。次の手順は、OEDAデプロイメントが実行されていない場合や正しく実行されていない場合、X7-2またはX7-8クライアント・アクセス・ポートを構成するために必要になります。
2.7 Oracle Exadata X6-2およびX7-2でのネットワーク・カードの追加および構成
Oracle Exadata X6-2およびX7-2システムで追加のネットワーク・カードを追加できます。
前提条件
Oracle Exadata Database Machine X7-2およびOracle Exadata Database Machine X7-8計算ノードに、正しいリンク速度を使用していることを確認してください。「X7用クライアント・ネットワーク・ポートのリンク速度の検証および変更」の手順を完了します。
Oracle Exadata Database Machine X6-2
Oracle Exadata Database Machine X6-2データベース・サーバーでは、マザーボードで高可用性の銅線10Gネットワークが提供され、スロット2のPCIカードを介して光学10Gネットワークが提供されます。オラクル社では、追加の接続を必要とするお客様のために追加のイーサネット・カードを用意しています。追加のカードにより、デュアル・ポートの10GEの銅線接続(部品番号7100488)またはデュアル・ポートの10GEの光学接続(部品番号X1109A-Z)が提供されます。Oracle Exadata X6-2データベース・サーバーのPCIeスロット1にこのカードを設置します。
カードを取り付けてネットワークに接続すると、Oracle Exadata System Softwareは、自動的にその新しいカードを認識してX6-2データベース・サーバー上で2つのポートをeth6およびeth7インタフェースとして構成します。これらの追加のポートを使用して追加のクライアント・ネットワークを提供することも、個別のバックアップまたはデータ・リカバリ・ネットワークを作成することもできます。仮想マシンを実行するデータベース・サーバーでは、これを使用して2つの仮想マシンからトラフィックを分離できます。
Oracle Exadata Database Machine X7-2
Oracle Exadata Database Machine X7-2データベース・サーバーでは、マザーボード上で2つの銅線(RJ45)ネットワーク接続または2つの光(SFP28)ネットワーク接続を利用できるだけでなく、PCIeカード・スロット1で2つの光(SFP28)ネットワーク接続を追加で利用できます。オラクル社では、追加の接続を必要とするお客様のために4つの追加の銅線(RJ45) 10Gネットワーク接続を用意しています。追加のカードはOracle Quad Port 10GBase-Tカード(部品番号7111181)です。X7-2データベース・サーバーのPCIeスロット3にこのカードを設置します。
カードを取り付けてネットワークに接続すると、Oracle Exadata System Softwareは、自動的にその新しいカードを認識してX7-2データベース・サーバー上で4つのポートをeth5 - eth8インタフェースとして構成します。これらの追加のポートを使用して追加のクライアント・ネットワークを提供することも、個別のバックアップまたはデータ・リカバリ・ネットワークを作成することもできます。仮想マシンを実行するデータベース・サーバーでは、これを使用して2つの仮想マシンからトラフィックを分離できます。
データベース・サーバーにカードを追加した後、カードを構成する必要があります。次の項を参照してください。
2.7.1 ネットワーク・インタフェースの表示
ネットワーク・インタフェースを表示するには、ipconf.plコマンドを実行します。
例2-1 Oracle Exadata Database Machine X6-2データベース・サーバーのデフォルト・ネットワーク・インタフェースの表示
次に、ネットワーク・カードを追加していないOracle Exadata Database Machine X6-2データベース・サーバーの出力例を示します。出力には2つのネットワーク・カードが示されます。
-
eth0からeth3のクアッド・ポート10Gbカード
-
eth4およびeth5のデュアル・ポート10Gbカード
# cd /opt/oracle.cellos/
# ./ipconf.pl
Logging started to /var/log/cellos/ipconf.log
Interface ib0 is Linked. hca: mlx4_0
Interface ib1 is Linked. hca: mlx4_0
Interface eth0 is Linked. driver/mac: ixgbe/00:10:e0:8b:24:b6
Interface eth1 is ..... Linked. driver/mac: ixgbe/00:10:e0:8b:24:b7
Interface eth2 is ..... Linked. driver/mac: ixgbe/00:10:e0:8b:24:b8
Interface eth3 is ..... Linked. driver/mac: ixgbe/00:10:e0:8b:24:b9
Interface eth4 is Linked. driver/mac: ixgbe/90:e2:ba:ac:20:ec (slave of bondeth0)
nterface eth5 is Linked. driver/mac: ixgbe/90:e2:ba:ac:20:ec (slave of bondeth0)
例2-2 Oracle Exadata Database Machine X7-2データベース・サーバーのデフォルト・ネットワーク・インタフェースの表示
次に、ネットワーク・カードを追加していないOracle Exadata Database Machine X7-2データベース・サーバーの出力例を示します。出力には3つのネットワーク・カードが示されます。
-
eth0のシングル・ポート10Gbカード
-
eth1およびeth2のデュアル・ポート10または25Gbカード
-
eth3およびeth4のデュアル・ポート25Gbカード
# /opt/oracle.cellos/ipconf.pl
Logging started to /var/log/cellos/ipconf.log
Interface ib0 is Linked. hca: mlx4_0
Interface ib1 is Linked. hca: mlx4_0
Interface eth0 is Linked. driver/mac: igb/00:
10:e0:c3:ba:72
Interface eth1 is Linked. driver/mac: bnxt_en
/00:10:e0:c3:ba:73
Interface eth2 is Linked. driver/mac: bnxt_en
/00:10:e0:c3:ba:74
Interface eth3 is Linked. driver/mac: bnxt_en
/00:0a:f7:c3:14:a0 (slave of bondeth0)
Interface eth4 is Linked. driver/mac: bnxt_en
/00:0a:f7:c3:14:a0 (slave of bondeth0)
2.7.2 非Oracle VM環境での追加のネットワーク・カードの構成
非Oracle VM環境でOracle Exadata Database Machine X6-2以降のデータベース・サーバーに追加のネットワーク・カードを構成できます。
この手順では、Oracle Exadata Database Machineデータベース・サーバーにネットワーク・カードがすでにインストールされているが、まだOracle Exadata Deployment Assistant (OEDA)で構成を完了していないことを前提としています。
警告:
Oracle Exadata Database MachineでOracle Grid Infrastructureがすでにインストールされている場合、Oracle Clusterwareのドキュメントを参照してください。クラスタのネットワーク・インタフェースは慎重に変更してください。2.7.3 Oracle VM環境での追加のネットワーク・カードの構成
Oracle VM環境でOracle Exadata Database Machine X6-2以降のデータベース・サーバーに追加のネットワーク・カードを構成できます。
この手順では、Oracle Exadata Database Machineデータベース・サーバーにネットワーク・カードがすでにインストールされているが、まだOracle Exadata Deployment Assistant (OEDA)で構成を完了していないことを前提としています。
注意:
Oracle Exadata Database MachineでOracle Grid Infrastructureをすでにインストールしている場合は、この手順を実行しないでください。2.8 データベース・サーバーのアクティブ・コア数の増加
キャパシティ・オンデマンドを使用して、Oracle Exadata Database Machineのアクティブ・コア数を増やすことができます。
Oracle Exadata Database Machine X4-2以降のシステムで実行されるデータベース・サーバー上のアクティブ・コア数を、インストール中に減らすことができます。追加の容量が必要な場合は、アクティブ・コア数を増やすことができます。これは、キャパシティ・オンデマンドと呼ばれます。
追加のコアは、Oracle Exadata Database Machine X4-2およびそれ以降のシステムでは2コア増分で、Oracle Exadata Database Machine X4-8フル・ラックおよびそれ以降のシステムでは8コア増分で増やします。次の表に、キャパシティ・オンデマンドのコア・プロセッサの構成を示します。
表2-3 キャパシティ・オンデマンドのコア・プロセッサの構成
| Oracle Exadata Database Machine | 対象となるシステム | サーバー当たりの最小コア数 | サーバー当たりの最大コア数 | コアの増分 |
|---|---|---|---|---|
|
Oracle Exadata Database Machine X7-2 |
エイス・ラック以外の構成 |
14 |
48 |
14から48、2の倍数。 14, 16, 18, ..., 46, 48 |
|
Oracle Exadata Database Machine X7-2 |
エイス・ラック |
8 |
24 |
8から24、2の倍数。 8, 10, 12, ..., 22, 24 |
|
Oracle Exadata Database Machine X6-2 |
エイス・ラック以外の構成 |
14 |
44 |
14から44、2の倍数。 14, 16, 18, ..., 42, 44 |
|
Oracle Exadata Database Machine X6-2 |
エイス・ラック |
8 |
22 |
8から22、2の倍数。 8, 10, 12, ..., 20, 22 |
|
Oracle Exadata Database Machine X5-2 |
エイス・ラック以外の構成 |
14 |
36 |
14から36、2の倍数。 14, 16, 18, ..., 34, 36 |
|
Oracle Exadata Database Machine X5-2 |
エイス・ラック |
8 |
18 |
8から18、2の倍数。 8, 10, 12, ..., 16, 18 |
|
Oracle Exadata Database Machine X4-2 |
フル・ラック ハーフ・ラック クオータ・ラック |
12 |
24 |
12から24、2の倍数。 12, 14, 16, ..., 22, 24 |
|
Oracle Exadata Database Machine X7-8 |
任意の構成 |
56 |
192 |
56から192、8の倍数。 56, 64, 72,..., 184, 192 |
|
Oracle Exadata Database Machine X6-8およびX5-8 |
任意の構成 |
56 |
144 |
56から144、8の倍数。 56, 64, 72, ..., 136, 144 |
|
Oracle Exadata Database Machine X4-8 |
フル・ラック |
48 |
120 |
48から120、8の倍数。 48, 56, 64, ..., 112, 120 |
注意:
フェイルオーバーに備えて、各サーバーに同数のコアをライセンスすることをお薦めします。
追加できるデータベース・サーバーは一度に1つずつで、キャパシティ・オンデマンドは個別のデータベース・サーバーに適用されます。このオプションはOracle Exadata Database Machine X5-2エイス・ラックでも使用できます。
追加したコアを有効化してから、データベース・サーバーを再起動する必要があります。データベース・サーバーがクラスタの一部の場合、ローリング方式で有効化されます。
2.9 LVMパーティションの拡張
Logical Volume Manager (LVM)により、データベース・サーバー内のパーティションを再編成する柔軟性が提供されます。
注意:
-
VGExaDbボリューム・グループ内に、少なくとも1GBの空き領域が必要です。この領域は、ソフトウェア保守の際に、dbnodeupdate.shユーティリティで作成したLVMスナップショットで使用します。 -
「Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成」の手順に従い、
/(root)および/u01ディレクトリのバックアップをスナップショット・ベースで作成する場合、VGExaDbボリューム・グループに少なくとも6GBの空き領域が必要です。
この項では、次の項目について説明します。
2.9.1 ルートLVMパーティションの拡張
ルートLVMパーティションを拡張する手順は、Oracle Exadata System Softwareのリリースによって異なります。
次の各項では、Oracle Exadata System Softwareのリリースに応じた手順を説明します。
2.9.1.1 Oracle Exadata System Softwareリリース11.2.3.2.1以上を実行するシステムでの、ルートLVMパーティションの拡張
次の手順では、Oracle Exadata System Softwareリリース11.2.3.2.1以上を実行するシステム上で、ルート(/)パーティションのサイズを拡大する方法について説明します。
注意:
-
この手順では、サーバーを停止する必要はありません。
-
管理ドメインのシステムの場合、アクティブおよび非アクティブのSys LVMは、
LVDbSys2およびLVDbSys3です(LVDbSys1およびLVDbSys2ではありません)。 -
LVDbSys1およびLVDbSys2のサイズが同じに設定されていることを確認します。
2.9.1.2 Oracle Exadata System Softwareリリース11.2.3.2.1より前のリリースを実行するシステムでの、ルートLVMパーティションの拡張
次の手順では、Oracle Exadata System Softwareリリース11.2.3.2.1より前のリリースを実行するシステム上で、ルート(/)パーティションのサイズを拡大する方法について説明します。
注意:
-
この手順では、システムをオフラインにしてから再起動する必要があります。
-
ソフトウェア保守の際に
dbnodeupdate.shユーティリティで作成されるLVMスナップショットのために、VGExaDbボリューム・グループ内に、少なくとも1GBの空き領域が必要です。「Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成」の手順に従い、/(root)および/u01ディレクトリのバックアップをスナップショット・ベースで作成する場合、VGExaDbボリューム・グループに少なくとも6GBの空き領域が必要です。 -
管理ドメインのシステムの場合、アクティブおよび非アクティブのSys LVMは、
LVDbSys2とLVDbSys3です(LVDbSys1とLVDbSys2ではありません)。 -
LVDbSys1およびLVDbSys2のサイズが同じに設定されていることを確認します。
- システムを診断モードで再起動します。
- 「開く」をクリックします。
次のようなメッセージがコンソールに表示されます。
- 「開く」をクリックします。
2.9.2 ルート以外のLVMパーティションのサイズ変更
ルート以外のLVMパーティションのサイズを変更する手順は、Oracle Exadata System Softwareのリリースによって異なります。
次の各項では、Oracle Exadata System Softwareのリリースに応じた手順を説明します。
2.9.2.1 Oracle Exadata System Softwareリリース11.2.3.2.1以上を実行するシステムでの、非ルートLVMパーティションの拡張
この手順では、Oracle Exadata System Softwareリリース11.2.3.2.1以降を実行するシステム上で、非ルート(/u01)パーティションのサイズを拡大する方法について説明します。
この手順では、サーバーを停止する必要はありません。
2.9.2.2 Oracle Exadata System Softwareリリース11.2.3.2.1より前のリリースを実行するシステムでの、非ルートLVMパーティションの拡張
この手順では、Oracle Exadata System Softwareリリース11.2.3.2.1より前のリリースを実行するシステム上で、非ルート(/u01)パーティションのサイズを拡大する方法について説明します。
ここでは、/dev/VGExaDb/LVDbOra1が/u01でマウントされます。
注意:
-
VGExaDbボリューム・グループ内に、少なくとも1GBの空き領域が必要です。この領域は、ソフトウェア保守の際に、dbnodeupdate.shユーティリティで作成したLVMスナップショットで使用します。 -
「Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成」の手順に従い、
/(root)および/u01ディレクトリのバックアップをスナップショット・ベースで作成する場合、VGExaDbボリューム・グループに少なくとも6GBの空き領域が必要です。
2.9.3 スワップ・パーティションの拡張
この手順では、スワップ(/swap)パーティションのサイズを拡大する方法について説明します。
注意:
この手順では、システムをオフラインにしてから再起動する必要があります。
ソフトウェア保守の際にdbnodeupdate.shユーティリティで作成されるLogical Volume Manager (LVM)スナップショットのために、VGExaDbボリューム・グループ内に、少なくとも1GBの空き領域が必要です。「Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成」の手順に従い、/ (root)および/u01ディレクトリのバックアップをスナップショット・ベースで作成する場合、VGExaDbボリューム・グループに少なくとも6GBの空き領域が必要です。
2.10 Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成
データベース・サーバーのソフトウェアの重要な変更の前後にバックアップを行う必要があります。たとえば、次の手順の前後にバックアップを作成する必要があります。
-
オペレーティング・システム・パッチの適用
-
Oracleパッチの適用
-
重要な操作パラメータの再構成
-
重要なOracle以外のソフトウェアのインストールまたは再構成
この項では、次の項目について説明します。
2.10.1 Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成 - パーティションをカスタマイズしていない場合
この手順は、スナップショット・ベースのバックアップを取得する方法を示しています。手順で示す値は、例です。
元の出荷時の構成からデータベース・サーバー・パーティションをカスタマイズしていない場合、この項の手順を使用してバックアップを作成し、そのバックアップを使用してデータベース・サーバーをリストアします。
注意:
-
リカバリ手順により、出荷時の名前およびサイズを含む正確なパーティションがリストアされます。パーティションを少しでも変更した場合、この手順は使用できません。変更には、サイズや名前の変更、パーティションの追加または削除が含まれます。
-
rootユーザーとして、すべての手順を実行する必要があります。
2.11 Oracle Virtual Serverデプロイメントの管理ドメイン(dom0)とユーザー・ドメイン(domU)のバックアップ
Oracle Virtual Serverデプロイメントで、管理ドメイン(dom0)とユーザー・ドメイン(domU)をバックアップする必要があります。
2.11.1 スナップショット・ベースのバックアップを使用した管理ドメインdom0のバックアップ
この手順は、管理ドメインdom0のスナップショット・ベースのバックアップを取得する方法を示しています。
論理ボリューム/dev/VGExaDb/LVDoNotRemoveOrUseは、スナップショットを作成できるだけの空き領域を常に確保するためのプレースホルダです。dbserver_backup.shを実行すると、プレースホルダLVMがスクリプトによって削除され、それによって生まれた空き領域がスナップショットに使用され、スナップショットの作成後に再びLVMが作成されます。ここで説明する手動手順を実行する場合は、これらのタスクをすべて手動で実行する必要があります。
次の手順で示す値は、例です。rootユーザーとして、すべての手順を実行する必要があります。
2.11.2 ユーザー・ドメインのバックアップ
ユーザー・ドメインのバックアップ方法は2つあります。
-
方法1: Oracle Cluster File System (OCFS) reflinkを使用して記憶域リポジトリをバックアップし、一貫性のあるバックアップを取得する
この方法では、
/EXAVMIMAGESocfs2ファイル・システムである記憶域リポジトリをバックアップします。dom0によって管理されるすべてのユーザー・ドメインをバックアップする、
/EXAVMIMAGES全体をバックアップしたり、バックアップするユーザー・ドメインを選択したりできます。ユーザー・ドメインは、/EXAVMIMAGES/GuestImages/userディレクトリにあります。この方法では、方法2よりもより堅牢で包括的なバックアップが可能です。方法2は、特にロール別に分離された環境で、迅速で簡単なバックアップ方法が提供されます。
方法1は、dom0管理者がユーザー・ドメインのバックアップを担当している場合に最適です。
-
方法2: スナップショット・ベースのバックアップを使用してユーザー・ドメインをバックアップする
この方法では、ユーザー・ドメイン内部からスナップショット・ベースのバックアップを作成することで、単一のユーザー・ドメインをバックアップします。
方法2は、ユーザー・ドメイン管理者がユーザー・ドメインのバックアップを担当している場合に最適です。
2.11.2.1 方法1: すべてのユーザー・ドメインをバックアップする
/EXAVMIMAGES OCFS2ファイル・システムである記憶域リポジトリをバックアップすることができます
次に示す手順ではすべてのユーザー・ドメインがバックアップされます。
次のサンプル・コマンドは、前述の手順2から6にリストされている操作の参照として使用できます。
## Create the Backup Directory
find /EXAVMIMAGES -type d|grep -v 'lost+found'|awk '{print "mkdir -p /EXAVMIMAGES/Backup"$1}'|sh
## Pause user domains
xm list|egrep -v '^Domain-0|^Name'|awk '{print "xm pause",$2}'|sh
## Create Reflinks for all the files to be backed up
find /EXAVMIMAGES/ -type f|awk '{print "reflink",$0,"/EXAVMIMAGES/Backup"$0}'|sh
## Unpause user domains
xm list|egrep -v '^Domain-0|^Name'|awk '{print "xm unpause",$2}'|sh;
## Backup from the reflinks
pushd /EXAVMIMAGES/Backup/EXAVMIMAGES
tar -Spcvf /remote_FS/exavmimages-sparse.tar * 1> /tmp/Backup.log 2> /tmp/Backup.err
popd
rm -rf /EXAVMIMAGES/Backup/*
2.11.2.2 方法2: ユーザー・ドメイン内からユーザー・ドメインをバックアップする
次の手順は、ユーザー・ドメイン内からユーザー・ドメインのスナップショット・ベースのバックアップを取得する方法を示しています。
注意:
LVMスナップショットを使用してユーザー・ドメイン内からユーザー・ドメインをバックアップする方法では、リカバリ時の使用に関して制限があります。このようなバックアップは、ユーザー・ドメインがまだブート可能で、rootユーザーとしてログインできる場合のリカバリ用にのみ使用できます。これは、一部のファイルに損失または損傷が発生したが、ユーザー・ドメインがブートされ、/ (ルート)パーティションがマウントされた後に、tarバックアップからリストアできるような損傷です。そのような状況ではなくユーザー・ドメインをブートできない損傷の場合は、上述の方法1で作成したバックアップを使用してユーザー・ドメインをリカバリする必要があります。この場合は次の手順を実行して、ユーザー・ドメイン・レベルでリカバリ手順を実行する必要があります。
すべての手順はユーザー・ドメイン内から実行します。
この手順では、次がバックアップされます。
-
LVDbSys1 lvm
-
LVDbOra1 lvm
-
/bootパーティション -
Grid Infrastructureホーム
-
RDBMSホーム
rootユーザーとして、すべての手順を実行する必要があります。
-
バックアップの保存先を準備します。
# mkdir -p /remote_FS # mount -t nfs -o rw,intr,soft,proto=tcp,nolock ip_address:/nfs_location/ /remote_FS
ip_addressは、NFSサーバーのIPアドレスで、nfs_locationは、バックアップを保持するNFSの場所です。
-
次のように、/ (ルート)および/u01ディレクトリを含むファイル・システムのスナップショット・ベースのバックアップを取得します。
-
ルート・ディレクトリを含むファイル・システムに、LVDbSys1_snapと言う名前のスナップショットを作成します。ボリューム・グループには、コマンドを正常に実行するのに少なくとも1 GBの空き領域が必要です。
# lvcreate -L1G -s -n LVDbSys1_snap /dev/VGExaDb/LVDbSys1
-
スナップショットにラベルを付けます。
# e2label /dev/VGExaDb/LVDbSys1_snap DBSYS_SNAP
-
スナップショットをマウントします。
# mkdir /root/mnt # mount /dev/VGExaDb/LVDbSys1_snap /root/mnt -t ext4
-
/u01ディレクトリにu01_snapという名前のスナップショットを作成します。# lvcreate -L256M -s -n u01_snap /dev/VGExaDb/LVDbOra1
-
スナップショットにラベルを付けます。
# e2label /dev/VGExaDb/u01_snap DBORA_SNAP
-
スナップショットをマウントします。
# mkdir -p /root/mnt/u01 # mount /dev/VGExaDb/u01_snap /root/mnt/u01 -t ext4
-
バックアップのディレクトリに変更します。
# cd /root/mnt
-
バックアップ・ファイルを作成して、前述で取得した2つのスナップショット、
/bootパーティション、RDBMSホームおよびグリッド・インフラストラクチャのホームをバックアップします。# tar -pjcvf /remote_FS/mybackup.tar.bz2 * /boot /u01/app/12.1.0.2/grid /u01/app/oracle/product/12.1.0.2/dbhome_1 > /tmp/backup_tar.stdout 2> /tmp/backup_tar.stderr
-
/tmp/backup_tar.stderrファイルをチェックして、重大なエラーがないかを確認します。tarオープン・ソケットの障害に関するエラーおよび他の同様のエラーは無視できます。
-
-
ルート・ディレクトリを含むファイル・システムのスナップショットをアンマウントおよび削除します。
# cd / # umount /root/mnt/u01 # umount /root/mnt # /bin/rmdir /root/mnt # lvremove /dev/VGExaDb/u01_snap # lvremove /dev/VGExaDb/LVDbSys1_snap
-
NFS共有をアンマウントします。
# umount /remote_FS
2.12 スナップショット・ベースのバックアップを使用したOracle Linuxデータベース・サーバーのリカバリ
この項では、データベース・サーバーで重大な障害が発生した後またはサーバー・ハードウェアを新しいハードウェアに交換する必要がある場合に、スナップショット・ベースのバックアップを使用して、Oracle Linuxを実行するデータベース・サーバー・ファイル・システムをリカバリする方法について説明します。たとえば、すべてのハード・ディスクを交換すると、システムの元のソフトウェアはトレースできません。これは、ソフトウェアの完全なシステムの交換と似ています。さらに、障害状態になる前にデータベース・サーバーが正常であったときに取得したLVMスナップショット・ベースのバックアップを使用するデータベース・サーバーの障害リカバリ方法を提供します。
リカバリ手順では、diagnostics.isoイメージを仮想CD-ROMとして使用し、ILOMを使用してレスキュー・モードでデータベース・サーバーを再起動します。一般的なワークフローには次の作業があります。
-
次のものを再作成します。
-
ブート・パーティション
-
物理ボリューム
-
ボリューム・グループ
-
論理ボリューム
-
ファイル・システム
-
スワップ・パーティション
-
-
スワップ・パーティションをアクティブ化します。
-
/bootパーティションがアクティブなブート・パーティションであることを確認します。 -
データをリストアします。
-
GRUBを再構成します。
-
サーバーを再起動します。
この項で説明するリカバリ手順には、Oracle Exadata Storage Serverまたはデータベース・データのバックアップまたはリカバリは含まれません。バックアップとリカバリ手順は定期的にテストすることをお薦めします。この項では、次の項目について説明します。
注意:
テープからリストアする場合は、追加のドライブをロードする必要がありますが、この章では扱いません。ファイルはNFSの場所にバックアップし、既存のテープ・オプションを使用して、NFSホストとの間でバックアップとリカバリを行うことをお薦めします。
2.12.1 Oracle Linuxデータベース・サーバーのリカバリ - パーティションをカスタマイズしていない場合
パーティションをカスタマイズしていない場合にスナップショット・ベースのバックアップを使用してOracle Linuxデータベース・サーバーをリカバリできます。
この手順は、パーティション、論理ボリューム、ファイル・システム、およびそれらのサイズの配置がデータベース・サーバーの最初のデプロイ時の配置と等しい場合に適用されます。
注意:
ディスクの既存のすべてのデータは、この手順の実行中に失われます。- システムで要求された場合は、次のように入力します。レスポンスは太字で示されています。
Oracle Exadata System Softwareリリース12.1.2.2.0以上では、DHCPが使用されるため、ネットワークを手動で設定する必要はありません。
-
Oracle Exadata System Softwareリリース18.1以降を使用していて、Oracle Exadata Database Machine X7で実行している場合は、次のようなプロンプトが表示されます。
図boot_screen_18.1.jpgの説明 -
Oracle Exadata System Softwareリリース18.1以降を使用していて、Oracle Exadata Database Machine X3-2、X4-2、X5-2またはX6-2の10GbEイーサネットSFP+ポートのいずれかを使用してリストアしている場合は、次のようなプロンプトが表示されます。
------------------------------------------------------------------------------ Choose from the following by typing letter in '()': (e)nter interactive diagnostics shell. Use diagnostics shell password to login as root user (reboot or power cycle to exit the shell), (r)estore system from NFS backup archive, Select: r Continue (y/n) [n]: y Rescue password: [INFO ] Enter path to the backup file on the NFS server in format: Enter path to the backup file on the NFS server in format: <ip_address_of_the_NFS_share>:/<path>/<archive_file> For example, 10.124.1.15:/export/nfs/share/backup.2010.04.08.tar.bz2 NFS line: <nfs_ip>:/export/mybackup.tar.bz2 [INFO ] The backup file could be created either from LVM or non-LVM based COMPUTE node [INFO ] Versions below 11.2.1.3.0 do not support LVM based partitioning Use LVM based scheme. (y/n) [y]: y Configure network settings on host via DHCP. (y/n) [y]: n Configure bonded network interface. (y/n) [y]: y IP Address of bondeth0 on this host: <IP address of the DB host> Netmask of bondeth0 on this host: <netmask for the above IP address> Bonding mode:active-backup or 802.3ad [802.3ad]: active-backup Slave interface1 for bondeth0 (ethX) [eth4]: eth4 Slave interface2 for bondeth0 (ethX) [eth5]: eth5 ... [ 354.619610] bondeth0: first active interface up! [ 354.661427] ixgbe 0000:13:00.1 eth5: NIC Link is Up 10 Gbps, Flow Control: RX/TX [ 354.724414] bondeth0: link status definitely up for interface eth5, 10000 Mbps full duplex Default gateway: <Gateway for the above IP address> ------------------------------------------------------------------------------ -
Oracle Exadata System Softwareリリース12.1.xまたは12.2.xを使用している場合は、次のようなプロンプトが表示されます。
------------------------------------------------------------------------------ Use diagnostics shell password to login as root user (reboot or power cycle to exit the shell), (r)estore system from NFS backup archive. Select: r Continue (y/n) [n]: y Rescue password: [INFO: ] Enter path to the backup file on the NFS server in format: Enter path to the backup file on the NFS server in format: <ip_address_of_the_NFS_share>:/<path>/<archive_file> For example, 10.124.1.15:/export/nfs/share/backup.2010.04.08.tar.bz2 NFS line: <nfs_ip>:/export/mybackup.tar.bz2 [INFO: ] The backup file could be created either from LVM or non-LVM based COMPUTE node [INFO: ] Versions below 11.2.1.3.0 do not support LVM based partitioning Use LVM based scheme. (y/n) [y]: y ------------------------------------------------------------------------------ -
12.1.2.2.0より前のリリースのOracle Exadata System Softwareを使用している場合、プロンプトは次のようになります。
------------------------------------------------------------------------------ Choose from following by typing letter in '()': (e)nter interactive diagnostics shell. Must use credentials from Oracle support to login (reboot or power cycle to exit the shell), (r)estore system from NFS backup archive, Select:r Are you sure (y/n) [n]:y The backup file could be created either from LVM or non-LVM based compute node versions below 11.2.1.3.1 and 11.2.2.1.0 or higher do not support LVM based partitioning use LVM based scheme(y/n):y Enter path to the backup file on the NFS server in format: ip_address_of_the_NFS_share:/path/archive_file For example, 10.10.10.10:/export/operating_system.tar.bz2 NFS line:<nfs_ip>:/export/mybackup.tar.bz2 IP Address of this host:IP address of the DB host Netmask of this host:netmask for the above IP address Default gateway:Gateway for the above IP address. If there is no default gateway in your network, enter 0.0.0.0. ------------------------------------------------------------------------------
リカバリが完了すると、ログイン画面が表示されます。
-
2.12.2 Exadata X7データベース・サーバーのリカバリ - パーティションをカスタマイズしている場合
次の手順では、パーティションをカスタマイズしている場合に、スナップショット・ベースのバックアップを使用してOracle Exadata Database Machine X7-2以降のOracle Linuxデータベース・サーバーをリカバリする方法について説明します。
注意:
このタスクは、Oracle Exadata System Softwareリリース18c (18.1.0)以降を実行していることが前提です。2.12.3 Exadata X6以前のデータベース・サーバーのリカバリ - パーティションをカスタマイズしている場合
次の手順では、パーティションをカスタマイズしている場合に、スナップショット・ベースのバックアップを使用して、Oracle Linuxを実行しているOracle Exadata Database Machine X6-2以前のOracle Exadata Database Serverをリカバリする方法について説明します。
この手順は、diagnostics.isoを使用してデータベース・サーバーを起動した後にenter interactive diagnostics shellおよびrestore system from NFS backup archiveオプションの選択を要求されるまで、カスタマイズされていないパーティションのリストア手順と同じです。
2.12.4 Oracle Exadata Database Machineエイス・ラックのOracle Linuxデータベース・サーバーのリカバリ後の構成
Oracle Exadata Database Machineエイス・ラックのOracle Linuxデータベース・サーバーを再イメージ化、リストアまたはレスキューした場合は、エイス・ラックを再構成できます。次の手順のいずれかを使用します:
2.13 Oracle VM Serverデプロイメントでのリカバリ
次の手順では、重大な障害が発生してOracle VM Serverが損傷を受けた場合、またはサーバー・ハードウェアを新しいハードウェアに交換する必要がある場合に、スナップショット・ベースのバックアップからOracle VM Serverをリカバリする方法について説明します。たとえば、すべてのハード・ディスクを交換すると、システムの元のソフトウェアはトレースできません。これは、ソフトウェアの完全なシステムの交換と似ています。さらに、障害状態になる前にデータベース・サーバーが正常であったときに取得したLVMスナップショット・ベースのバックアップを使用するデータベース・サーバーの障害リカバリ方法を提供します。
リカバリ手順では、diagnostics.isoイメージを仮想CD-ROMとして使用し、Integrated Lights Out Manager (ILOM)を使用してレスキュー・モードでOracle VM Serverを再起動します。この手順の概要は、次のようになります。
-
次のものを再作成します。
-
ブート・パーティション
-
物理ボリューム
-
ボリューム・グループ
-
論理ボリューム
-
ファイル・システム
-
スワップ・パーティション
-
-
スワップ・パーティションをアクティブ化します。
-
/bootパーティションがアクティブなブート・パーティションであることを確認します。 -
データをリストアします。
-
GRUBを再構成します。
-
サーバーを再起動します。
この項で説明するリカバリ手順には、Oracle Exadata Storage ServerまたはOracle Databaseのデータのバックアップまたはリカバリは含まれません。バックアップとリカバリ手順は定期的にテストすることをお薦めします。
2.13.1 シナリオ1: Oracle VM Serverとすべてのユーザー・ドメインのバックアップからのリカバリ
Oracle VM Serverとそのすべてのユーザー・ドメインをバックアップからリカバリできます。
次の手順は、リカバリ・プロセスを示しています。システムにインストールされているOracle Exadata System Softwareのバージョンに応じて、次の手順のいずれかを選択します。
注意:
ディスクの既存のすべてのデータは、これらの手順の実行中に失われます。
2.13.1.1 Oracle Virtual Serverとそのすべてのユーザー・ドメインのリカバリ(12.2.1.1.0より前のリリース)
重大な障害が発生してOVSが損傷を受けた場合、またはサーバー・ハードウェアを新しいハードウェアに交換する必要がある場合は、スナップショット・ベースのバックアップからOracle Virtual Server (OVS)をリカバリできます。
- 正常なデータベース・サーバーにある
/opt/oracle.SupportTools/diagnostics.isoファイルをリストア対象のOracle Virtual ServerのILOMに仮想メディアとして接続します。次に、ILOMインタフェースを使用した仮想CD-ROMの設定方法の例を示します。diagnostics.isoファイルを開きます。
この時点で、すべてのユーザー・ドメインがOracle Grid Infrastructureおよびデータベース・インスタンスとともに起動し、残りの他のOracle Virtual Serverノードによって形成されたOracle RACクラスタに参加します。
2.13.1.2 Oracle Virtual Serverとそのすべてのユーザー・ドメインのリカバリ(12.2.1.1.0以上のリリース)
重大な障害が発生してOVSが損傷を受けた場合、またはサーバー・ハードウェアを新しいハードウェアに交換する必要がある場合は、スナップショット・ベースのバックアップからOracle Virtual Server (OVS)をリカバリできます。
- 正常なデータベース・サーバーにある
/opt/oracle.SupportTools/diagnostics.isoファイルをリストア対象のOracle Virtual ServerのILOMに仮想メディアとして接続します。次に、ILOMインタフェースを使用した仮想CD-ROMの設定方法の例を示します。diagnostics.isoファイルを開きます。
この時点で、すべてのユーザー・ドメインがOracle Grid Infrastructureおよびデータベース・インスタンスとともに起動し、残りの他のOracle Virtual Serverノードによって形成されたOracle RACクラスタに参加します。
2.13.2 シナリオ2: dom0の再イメージ化およびバックアップからのユーザー・ドメインのリストア
次の手順は、修復できないほどの損傷がOVS/dom0で発生し、バックアップがdom0に存在しないが、すべてのユーザー・ドメインを格納する記憶域リポジトリ(/EXAVMIMAGESファイル・システム)の中に利用可能なバックアップが存在する場合に使用できます。この手順では、dom0を再イメージ化し、すべてのユーザー・ドメインを再構築します。
-
「Oracle Exadata Database Serverの再イメージ化」の手順を使用して、ラック内のその他のOVS/dom0で使用されるイメージでOVSを再イメージ化します。
-
次のコマンドを実行します。
# /opt/oracle.SupportTools/switch_to_ovm.sh # /opt/oracle.SupportTools/reclaimdisks.sh –free –reclaim
-
リカバリをOracle Exadata Database Machineエイス・ラックで実行する場合は、「Oracle Exadata Database Machineエイス・ラックのOracle Linuxデータベース・サーバーのリカバリ後の構成」の手順を実行します。
-
ocfs2ファイル・システムを
/dev/sda3パーティションに再構築します。# umount /EXAVMIMAGES # mkfs -t ocfs2 -L ocfs2 -T vmstore --fs-features=local /dev/sda3 --force
-
ocfs2パーティション
/dev/sda3を/EXAVMIMAGESにマウントします。# mount -t ocfs2 /dev/sda3 /EXAVMIMAGES
-
バックアップNFSサーバーをマウントし、ユーザー・ドメイン・イメージを保持する
/EXAVMIMAGESファイル・システムをリストアします。# mkdir -p /remote_FS # mount -t nfs -o ro,intr,soft,proto=tcp,nolock nfs_ip:/location_of_backup /remote_FS
-
/EXAVMIMAGESファイル・システムをリストアします。# tar -Spxvf /remote_FS/backup-of-exavmimages.tar -C /EXAVMIMAGES注意:
記憶域リポジトリのリストア処理では、ユーザー・ドメイン固有のファイル(
/EXAVMINAGES/GuestImages/<user_domain>/下のファイル)が通常のファイルとしてリストアされ、ユーザー・ドメインの作成時にこれらのファイルが記憶域リポジトリに最初に作成されたocfs2 reflinkとしてはリストアされません。したがって、/EXAVMINAGES内の領域の使用量は、バックアップ時の元の領域の使用量に比べて、リストア処理後に増加することがあります。 -
ネットワーク・ブリッジを手動で設定します。
-
ovmutils rpmのバージョンを確認します。
# rpm -qa|grep ovmutils
-
ovmutils rpmのバージョンが12.1.2.2.0より前の場合は、次の手順を実行します。
-
/opt/exadata_ovm/exadata.img.domu_makerをバックアップします。このバックアップ・コピーは後ほど必要になります。# cp /opt/exadata_ovm/exadata.img.domu_maker /opt/exadata_ovm/exadata.img.domu_maker-orig
-
viなどのテキスト・エディタで
/opt/exadata_ovm/exadata.img.domu_makerファイルを開き、"g_do_not_set_bridge=yes"を検索します。これは、CASE文オプション"network-discovery"の数行下にあります。これを"g_do_not_set_bridge=no"に変更します。
/opt/exadata_ovm/exadata.img.domu_makerを保存して終了します。 -
/EXAVMIMAGES/confディレクトリのすべてのxmlファイルで/opt/exadata_ovm/exadata.img.domu_makerを手動で実行します。# cd /EXAVMIMAGES/conf # ls -1|while read file; do /opt/exadata_ovm/exadata.img.domu_maker network-discovery $file /tmp/netdisc-$file; done
-
バックアップ・コピーから
/opt/exadata_ovm/exadata.img.domu_makerをリストアします。# cp /opt/exadata_ovm/exadata.img.domu_maker-orig /opt/exadata_ovm/exadata.img.domu_maker
-
-
ovmutils rpmのバージョンが12.1.2.2.0以降の場合、次のコマンドを実行します。
# /opt/exadata_ovm/exadata.img.domu_maker add-bonded-bridge-dom0 vmbondeth0 eth4 eth5
-
-
/EXAVMIMAGES/GuestImagesディレクトリ内のユーザー・ドメイン・ディレクトリごとに、次の手順を実行します。-
ユーザー・ドメインのUUIDを取得します。
# grep ^uuid /EXAVMIMAGES/GuestImages/<user domain hostname>/vm.cfg|awk -F"=" '{print $2}'|sed s/"'"//g|sed s/" "//gコマンドを実行すると、
uuid値が返され、これは次のコマンドで使用されます。 -
# mkdir -p /OVS/Repositories/uuid -
# ln -s /EXAVMIMAGES/GuestImages/user_domain_hostname/vm.cfg/OVS/Repositories/uuid/vm.cfg -
# ln -s /OVS/Repositories/uuid/vm.cfg /etc/xen/auto/user_domain_hostname.cfg -
# mkdir VirtualDisks -
# cd VirtualDisks -
vm.cfgファイ内にある4つのディスク・イメージ名を使用して、このディレクトリに4つのシンボリック・リンクを作成します(/EXAVMIMAGES/GuestImages/user_domain_hostnameディレクトリ内にある4つの".img"ファイルを指します)。たとえば、
/OVS/Repositories/uuidディレクトリのサンプルvm.cfgファイルのサンプル・ディスク・エントリを次に示します。disk = ['file:/OVS/Repositories/6e7c7109c1bc4ebba279f84e595e0b27/VirtualDisks/dfd641a1c6a84bd69643da704ff98594.img,xvda,w','file:/OVS/Repositories/6e7c7109c1bc4ebba279f84e595e0b27/VirtualDisks/d349fd420a1e49459118e6a6fcdbc2a4.img,xvdb,w','file:/OVS/Repositories/6e7c7109c1bc4ebba279f84e595e0b27/VirtualDisks/8ac470eeb8704aab9a8b3adedf1c3b04.img,xvdc,w','file:/OVS/Repositories/6e7c7109c1bc4ebba279f84e595e0b27/VirtualDisks/333e7ed2850a441ca4d2461044dd0f7c.img,xvdd,w']
/EXAVMIMAGES/GuestImages/user_domain_hostnameディレクトリ内にある4つの".img"ファイルをリストできます。ls /EXAVMIMAGES/GuestImages/user_domain_name/*.img/EXAVMIMAGES/GuestImages/user_domain_name/System.img /EXAVMIMAGES/GuestImages/user_domain_name/grid12.1.0.2.2.img /EXAVMIMAGES/GuestImages/user_domain_name/db12.1.0.2.2-3.img /EXAVMIMAGES/GuestImages/user_domain_name/pv1_vgexadb.img
この場合、次のコマンドを使用して、4つのシンボリック・リンク(dbm01db08vm01はユーザー・ドメインのホスト名)を作成できます。
# ln -s /EXAVMIMAGES/GuestImages/dbm01db08vm01/System.img $(grep ^disk /EXAVMIMAGES/GuestImages/dbm01db08vm01/vm.cfg|awk -F":" '{print $2}'|awk -F"," '{print $1}'|awk -F"/" '{print $6}') # ln -s /EXAVMIMAGES/GuestImages/dbm01db08vm01/grid12.1.0.2.2.img $(grep ^disk /EXAVMIMAGES/GuestImages/dbm01db08vm01/vm.cfg|awk -F":" '{print $3}'|awk -F"," '{print $1}'|awk -F"/" '{print $6}') # ln -s /EXAVMIMAGES/GuestImages/dbm01db08vm01/db12.1.0.2.2-3.img $(grep ^disk /EXAVMIMAGES/GuestImages/dbm01db08vm01/vm.cfg|awk -F":" '{print $4}'|awk -F"," '{print $1}'|awk -F"/" '{print $6}') # ln -s /EXAVMIMAGES/GuestImages/dbm01db08vm01/pv1_vgexadb.img $(grep ^disk /EXAVMIMAGES/GuestImages/dbm01db08vm01/vm.cfg|awk -F":" '{print $5}'|awk -F"," '{print $1}'|awk -F"/" '{print $6}')
-
-
各ユーザー・ドメインを起動します。
# xm create /EXAVMIMAGES/GuestImages/user_domain_hostname/vm.cfg
この時点で、すべてのユーザー・ドメインと、それらの中のグリッド・インフラストラクチャおよびデータベース・インスタンスが起動し、残りの他のOVSノードによって形成されたOracle RACクラスタに参加します。
2.13.3 シナリオ3: スナップショット・バックアップからのユーザー・ドメインのリストアおよびリカバリ
失ったまたは損傷したユーザー・ドメイン内のファイルを、ユーザー・ドメイン内で作成したスナップショット・ベースのユーザー・ドメイン・バックアップを使用してリストアするには、次の手順を使用します。ユーザー・ドメイン・バックアップは「方法2: ユーザー・ドメイン内からユーザー・ドメインをバックアップする」の手順を使用して作成したものです。
2.14 Oracle Exadata Database Serverの再イメージ化
再イメージ化の手順が必要なのは、Oracle Linuxデータベース・サーバーで修復できないほどの損傷が発生した場合です。
損傷したデータベース・サーバーを新しいデータベース・サーバーと交換します。複数のディスク障害でローカル・ディスクのストレージに障害が発生し、データベース・サーバーがバックアップされなかった場合は、この手順も実行します。サーバーを再利用する場合は、データベース・サーバーを再イメージ化することもできます。
再イメージ化手順の実行中に、Oracle Exadata Database Machineの他のデータベース・サーバーを使用できます。クラスタに新しいサーバーを追加すると、ソフトウェアが既存のデータベース・サーバーから新しいサーバーにコピーされます。スクリプト、CRONジョブ、保守処置、Oracle以外のソフトウェアのリストアはユーザーが行います。
注意:
この項の手順は、データベースがOracle Database 11gリリース2 (11.2)以降であると仮定します。データベースがOracle Database 11gリリース1 (11.1)の場合、クラスタのサーバーの追加および削除の詳細は、該当するリリースのドキュメントを参照してください。Oracle Exadata System Softwareリリース19.1.0以降、ハードウェアがSecure Eraserをサポートしている場合、Secure Eraserは再イメージ化中に自動的に起動されます。これにより、パフォーマンスを維持しながら再イメージ化手順が大幅に簡略化されます。ラックを再購入する場合は、ラックをイメージ化するだけで、プロセスの一環としてセキュア・データ消去が透過的に行われます。
次のタスクは、Oracle Linuxを実行するOracle Exadata Database Serverを再イメージ化する方法を示しています。
2.14.1 Oracleサポート・サービスへの連絡
Oracleサポート・サービスでサポート・リクエストを開きます。サポート・エンジニアが障害が発生したサーバーを確認し、交換サーバーを送ります。サポート・エンジニアは、残存データベース・サーバーから実行したimagehistoryコマンドの出力結果を要求します。出力結果により、元のデータベース・サーバーのイメージ化に使用したcomputeImageMakerファイルへのリンクと、システムを同じレベルにリストアする手段が提供されます。
2.14.2 クラスタ検証ユーティリティの最新リリースのダウンロード
クラスタ検証ユーティリティ(cluvfy)の最新リリースは、My Oracle Supportで入手できます。
ダウンロードの手順およびその他の情報は、My Oracle Supportノート316817.1を参照してください。
2.14.3 障害が発生したデータベース・サーバーのクラスタからの削除
サーバーを再イメージ化する前に、障害が発生したデータベース・サーバーをクラスタから削除する必要があります。
この作業の手順は、クラスタで動作しているデータベース・サーバーを使用して実行されます。次のコマンドのworking_serverは動作しているデータベース・サーバー、replacement_serverは交換データベース・サーバーです。
2.14.4 交換データベース・サーバーのイメージ化
データベース・サーバーが交換されると、新しいデータベース・サーバーをイメージ化できます。USBサム・ドライブでインストール・メディアを使用することも、ILOMにアタッチされているPXEまたはISOを使用してタッチレス・オプションを使用することもできます。詳細は、Oracle Exadata Database Machineインストレーションおよび構成ガイドの新規システムのイメージ化を参照してください。
2.14.5 交換データベース・サーバーの構成
交換データベース・サーバーには、ホスト名、IPアドレス、DNSまたはNTP設定がありません。この作業の手順は、交換データベース・サーバーの構成方法を示しています。交換データベース・サーバーを構成する前に、次の情報が必要です。
-
ネーム・サーバー
-
南北アメリカ/シカゴなどのタイムゾーン
-
NTPサーバー
-
管理ネットワークのIPアドレス情報
-
クライアント・アクセス・ネットワークのIPアドレス情報
-
InfiniBandネットワークのIPアドレス情報
-
標準的なホスト名
-
デフォルトのゲートウェイ
Oracle Exadata Database Machineのすべてのデータベース・サーバーで情報を同じにする必要があります。IPアドレスは、DNSから取得できます。また、Oracle Exadata Database Machineがインストールされたときに、この情報を含むドキュメントが提供されています。
次の手順は、交換データベース・サーバーの構成方法を示しています。
- 交換データベース・サーバーの電源を投入します。システムがブートすると、自動的にOracle Exadataの構成ルーチンが実行され、情報の入力が要求されます。
- 要求された場合は情報を入力して、設定を確認します。起動プロセスが続行されます。
注意:
-
データベース・サーバーがすべてのネットワーク・インタフェースを使用していない場合は、構成プロセスが停止し、いずれかのネットワーク・インタフェースが切断されているという警告が出されます。検出プロセスを再試行するかどうかの確認を求められます。環境に応じて、
yesまたはnoと入力します。 -
クライアント・アクセス・ネットワークにボンディングが使用される場合、この時点でデフォルトのアクティブ/パッシブ・モードに設定されます。
2.14.6 クラスタの交換データベース・サーバーの準備
Oracle Exadata Database Machineの初期インストールの実行中、インストール・プロセスで特定のファイルが変更されました。次の手順は、初期インストールの実行中の変更が交換データベース・サーバーに行われることを確認する方法を示しています。
-
動作しているデータベース・サーバーのファイルを参照して、次のファイルの内容をコピーまたはマージします。
-
/etc/security/limits.confファイルの内容をコピーします。 -
/etc/hostsファイルの内容をマージします。 -
/etc/oracle/cell/network-config/cellinit.oraファイルをコピーします。 -
/etc/oracle/cell/network-config/cellinit.oraファイルを、交換サーバーのifcfg-bondib0インタフェース(アクティブ-パッシブ・ボンディングの場合)またはib0およびib1インタフェース(アクティブ-アクティブ・ボンディングの場合)のIP_ADDRESSで更新します。 -
/etc/oracle/cell/network-config/cellip.oraファイルをコピーします。すべてのデータベース・サーバーでcellip.oraファイルの内容を同じにする必要があります。 -
10GbEなど、追加ネットワーク要件を構成します。
-
/etc/modprobe.confファイルをコピーします。すべてのデータベース・サーバーでファイルの内容を同じにする必要があります。 -
/etc/sysctl.confファイルをコピーします。すべてのデータベース・サーバーでファイルの内容を同じにする必要があります。 -
データベース・サーバーを再起動し、ネットワーク変更を有効にします。
-
-
グループを追加して、交換データベース・サーバーにソフトウェア所有者のユーザーを設定します。ロール別管理を使用している場合、通常、ユーザーは
oracleおよびgridです。単一のソフトウェア所有者を使用する場合、通常、ユーザーはoracleです。グループ情報は、動作しているデータベース・サーバーで使用できます。-
次のコマンドを使用して、動作しているデータベース・サーバーから現在のグループ情報を取得します。
# id oracle uid=1000(oracle) gid=1001(oinstall) groups=1001(oinstall),1002(dba),1003(oper),1004(asmdba) -
次のように
groupaddコマンドを使用して、グループ情報を交換データベース・サーバーに追加します。# groupadd -g 1001 oinstall # groupadd -g 1002 dba # groupadd -g 1003 oper # groupadd -g 1004 asmdba -
次のコマンドを使用して、動作しているデータベース・サーバーから現在のユーザー情報を取得します。
# id oracle uid=1000(oracle) gid=1001(oinstall) \ groups=1001(oinstall),1002(dba),1003(oper),1004(asmdba) -
次のコマンドを使用して、ユーザー情報を交換データベース・サーバーに追加します。
# useradd -u 1000 -g 1001 -G 1001,1002,1003,1004 -m -d /home/oracle -s \ /bin/bash oracle -
次のコマンドを使用して、
/u01/app/oracleや/u01/app/12.2.0.1/gridなどのOracle BaseおよびGridのホーム・ディレクトリを作成します。# mkdir -p /u01/app/oracle # mkdir -p /u01/app/12.2.0.1/grid # chown -R oracle:oinstall /u01/app -
次のコマンドを使用して、
cellip.oraおよびcellinit.oraファイルの所有権を変更します。通常、所有権はoracle:dbaです。# chown -R oracle:dba /etc/oracle/cell/network-config -
次のコマンドを使用して、リストアしたデータベース・サーバーをセキュリティで保護します。
$ chmod u+x /opt/oracle.SupportTools/harden_passwords_reset_root_ssh $ /opt/oracle.SupportTools/harden_passwords_reset_root_ssh注意:
データベース・サーバーが再起動されます。プロンプトが表示されたら、rootユーザーとしてログインします。新しいパスワードが要求されます。他のデータベース・サーバーのパスワードrootと一致するパスワードを設定します。 -
次のコマンドを使用して、Oracleソフトウェア所有者のパスワードを設定します。通常、所有者は
oracleです。# passwd oracle
-
-
次に示すように、
oracleアカウントにSSHを設定します。-
次のコマンドを使用して、交換データベース・サーバーの
oracleアカウントにログインします。# su - oracle -
Oracleクラスタのサーバーをリストする交換データベース・サーバーの
dcliグループ・ファイルを作成します。 -
交換データベース・サーバーで次のコマンドを実行します。
$ dcli -g dbs_group -l oracle -k -
次のコマンドを使用して、交換データベース・サーバーに
oracleユーザーとしてログインします。# su - oracle -
次のコマンドを使用して、SSH等価を確認します。
$ dcli -g dbs_group -l oracle date
-
-
次のコマンドを使用して、動作しているデータベース・サーバーから交換データベース・サーバーにカスタム・ログイン・スクリプトを設定またはコピーします。
$ scp .bash* oracle@replacement_server:.前述のコマンドのreplacement_serverは、
dm01db01などの新しいサーバーの名前です。
2.14.7 Oracle Exadata System Softwareのパッチ・バンドルの交換データベース・サーバーへの適用
Oracle Exadata Database MachineのOracle Exadata System Softwareパッチ・バンドルが定期的にリリースされています。
computeImageMakerファイルのリリースよりも新しいパッチ・バンドルが動作しているデータベース・サーバーに適用された場合、パッチ・バンドルを交換するOracle Exadata Database Serverに適用する必要があります。次に示すように、パッチ・バンドルが適用されているか確認します。
-
Oracle Exadata System Softwareリリース11.2.1.2.3以前のデータベース・サーバーは、バージョン履歴情報を保持していません。リリース番号を確認するには、Oracle Exadata Storage Serverにログインし、次のコマンドを実行します。
imageinfo -verコマンドにより
computeImageMakerファイルで使用されるリリースと異なるリリースが表示された場合は、Oracle Exadata System SoftwareパッチがOracle Exadata Database Machineに適用されています。交換用のOracle Exadata Database Serverに適用する必要があります。 -
Oracle Exadata System Softwareリリース11.2.1.2.3以降では、
imagehistoryコマンドがOracle Exadata Database Serverにあります。交換用のOracle Exadata Database Serverの情報を、動作しているOracle Exadata Database Serverの情報と比較します。動作しているデータベースのリリースが新しい場合、Oracle Exadata Storage Serverパッチ・バンドルを交換用のOracle Exadata Storage Serverに適用します。
2.14.8 交換データベース・サーバーへのOracle Grid Infrastructureのクローニング
この手順では、交換データベース・サーバーにOracle Grid Infrastructureをクローニングする方法について説明します。
次のコマンドのworking_serverは動作しているデータベース・サーバー、replacement_serverは交換データベース・サーバーです。この手順中のコマンドは、動作しているデータベース・サーバーからグリッド・ホーム所有者として実行します。コマンドの実行にrootユーザーが必要な場合はコールアウトされます。
2.15 データベース・サーバーの既存のエラスティック構成の変更
この項では、既存のエラスティック構成に次の変更を行う方法について説明します。
ストレージ・セルを伴う変更については、「ストレージ・セルの既存のエラスティック構成の変更」を参照してください。
2.15.1 クラスタへの新しいデータベース・サーバーの追加
新しいデータベース・サーバーは、Oracle Exadata Database Machineで実行されている既存のOracle Real Application Clusters (Oracle RAC)クラスタに追加できます。
2.16 高冗長性ディスク・グループのためのQuorumディスクの管理
この項には次のサブセクションが含まれます:
2.16.1 Quorumディスク管理の概要
Oracle Exadataリリース12.1.2.3.0で導入されたQuorumディスク管理ユーティリティは、quorumディスクの管理に役立ちます。
このユーティリティを使用してiSCSI quorumディスクを2つのデータベース・ノード上に作成し、それら2つのquorumディスクに投票ファイルを格納できます。追加された2つの投票ファイルは、投票ファイル5つという高冗長性ディスク・グループの最小要件を満たすために使用されます。この機能は、次の要件を満たすOracle Exadataラックにのみ適用されます。
-
Oracle Exadataラック内のストレージ・サーバーの数が5台未満。
-
Oracle Exadataラック内に少なくとも2つのデータベース・ノードがある。
-
Oracle Exadataラックに少なくとも1つの高冗長性ディスク・グループがある。
さらに2つの障害グループが存在することから、この機能では投票ファイルがOracle Exadataラック(ストレージ・サーバーが5台未満)上の高冗長性ディスク・グループに格納されます。
この機能を使用しない場合、投票ファイルはExadataラック(ストレージ・サーバーが5台未満)上の標準冗長性ディスク・グループに格納されます。これによりOracle Grid Infrastructureは二重パートナ・ストレージ・サーバー障害に対して脆弱になり、投票ファイルquorumが喪失し、その結果クラスタおよびデータベースの完全停止を招くこともあります。このシナリオにおけるクラスタウェアおよびデータベースの再起動については、My Oracle Supportノート1339373.1を参照してください。
RDSの使用でib0とib1のIPアドレスの可用性が高くなるため、iSCSI quorumディスクの実装は高い可用性を実現します。将来的に内部ネットワークの構成の柔軟化または分離が行われても、このマルチパス機能によりiSCSI quorumディスク実装はシームレスに動作し続けます。
次の図内の各iSCSIデバイスは、iSCSIターゲットに向かう特定のパスに対応しています。各パスはデータベース・ノードのInfiniBandポートに対応しています。アクティブ–アクティブ・システム内のマルチパスquorumディスク・デバイスごとに、2つのiSCSIデバイス(ib0用とib1用)があります。
図2-1 アクティブ-アクティブ・システムにおいて、両方のiSCSIデバイスに接続するマルチパス・デバイス
「図2-1 アクティブ-アクティブ・システムにおいて、両方のiSCSIデバイスに接続するマルチパス・デバイス」の説明
この機能はベア・メタルOracle RACクラスタとOracle VM Oracle RACクラスタで使用できます。Oracle VM Oracle RACクラスタの場合、次の図に示すように、quorumディスク・デバイスが存在するOracle RACクラスタはOracle VMユーザー・ドメインです。
pkeyが有効の環境では、ターゲットの発見に使用するインタフェースをOracle Clusterware通信で使用するpkeyインタフェースにする必要があります。これらのインタフェースは次のコマンドを使用すると表示されます。
Grid_home/bin/oifcfg getif | grep cluster_interconnect | awk '{print $1}'Quorumディスク管理ユーティリティ(quorumdiskmgr)は、iSCSI構成、iSCSIターゲット、iSCSI LUN、iSCSIデバイスなど、この機能の実装に必要なすべてのコンポーネントを作成および管理するために使用します。
2.16.2 Quorumディスク管理のソフトウェア要件
この機能を使用するには、次のリリースが必要です。
-
Oracle Exadata softwareリリース12.1.2.3.0以上
-
すべてのデータベース・ホームにパッチ23200778を適用
-
Oracle Grid Infrastructure 12.1.0.2.160119(パッチ22722476および22682752を適用)またはOracle Grid Infrastructure 12.1.0.2.160419以上
新規のデプロイメントでは、OEDAによってパッチが自動的にインストールされます。
2.16.3 Quorumディスクのデータベース・ノードへの追加
高冗長性ディスク・グループおよび5台未満のストレージ・ディスクを含むOracle Exadataラック上のデータベース・ノードに、quorumディスクを追加することができます。
この項の例では、2つのデータベース・ノード(db01およびdb02)のあるクオータ・ラックにquorumディスクを作成します。
これは、アクティブ-アクティブ・システムです。db01およびdb02の両方には、2つのInfiniBandポート、ib0およびib1があります。
iSCSIデバイスとの通信に使用するネットワーク・インタフェースは次のコマンドを使用して確認できます。
$ oifcfg getif | grep cluster_interconnect | awk '{print $1}'
各インタフェースのIPアドレスは次のコマンドを使用して確認できます。
ip addr show interface_name
この例のInfiniBand IPアドレスは次のとおりです。
db01:
- ネットワーク・インタフェース: ib0、IPアドレス: 192.168.10.45
- ネットワーク・インタフェース: ib1、IPアドレス: 192.168.10.46
db02:
- ネットワーク・インタフェース: ib0、IPアドレス: 192.168.10.47
- ネットワーク・インタフェース: ib1、IPアドレス: 192.168.10.48
quorumディスクが追加されるOracle ASMディスク・グループは、DATAC1です。Oracle ASM所有者はgridで、ユーザー・グループはdbaです。
投票ファイルは当初、標準冗長性ディスク・グループRECOC1に配置されています。
$ Grid_home/bin/crsctl query css votedisk
## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------
1. ONLINE 21f5507a28934f77bf3b7ecf88b26c47 (o/192.168.76.187;192.168.76.188/RECOC1_CD_00_celadm12) [RECOC1]
2. ONLINE 387f71ee81f14f38bfbdf0693451e328 (o/192.168.76.189;192.168.76.190/RECOC1_CD_00_celadm13) [RECOC1]
3. ONLINE 6f7fab62e6054fb8bf167108cdbd2f64 (o/192.168.76.191;192.168.76.192/RECOC1_CD_00_celadm14) [RECOC1]
Located 3 voting disk(s).2.16.4 quorumディスクの再作成
状況によっては、quorumディスクの再作成が必要になる場合があります。
-
ゲストdomUを再作成するとき
-
quorumディスクを削除したが事前にOracle ASMディスク・グループからquorumディスクを削除(drop)していないとき
関連トピック
2.16.5 ユース・ケース
2.16.5.1 Oracle Exadata 12.1.2.3.0以降での新規デプロイメント
Oracle Exadataリリース12.1.2.3.0以上での新規デプロイメントでは、次の要件がすべて満たされる場合、OEDAによってデフォルトでこの機能が実装されます。
-
システムに少なくとも2つのデータベース・ノードと5台未満のストレージ・サーバーが含まれている。
-
OEDAリリース2016年2月以降を実行している。
-
「Quorumディスク管理のソフトウェア要件」に記載されているソフトウェア要件を満たしている。
-
Oracle Databaseが11.2.0.4以上である。
-
システム上に少なくとも1つの高冗長性ディスク・グループがある。
システム上に3台のストレージ・サーバーがある場合、OEDAによって選択されたクラスタ内の最初の2つのデータベース・ノードに、2つのquorumディスクが作成されます。
システム上に4台のストレージ・サーバーがある場合、OEDAによって選択された最初のデータベース・ノードに、1つのquorumディスクが作成されます。
2.16.5.2 Oracle Exadataリリース12.1.2.3.0以降へのアップグレード
ターゲットのExadataシステム内に5台未満のストレージ・サーバー、少なくとも1つの高冗長性ディスク・グループおよび2つ以上のデータベース・ノードがある場合、quorumdiskmgrを使用して手動でこの機能を実装できます。
関連トピック
2.16.5.3 12.1.2.3.0より前のOracle Exadataリリースへのダウングレード
quorumディスクをサポートする12.1.2.3.0以上のリリースからquorumディスクをサポートしない12.1.2.3.0より前のOracle Exadataリリースにロールバックするには、環境にquorumディスク実装が存在する場合はquorumディスク構成を削除する必要があります。Exadataソフトウェアのロールバックを実行する前に、quorumディスク構成を削除する必要があります。
quorumディスク構成を削除するには、次の手順を実行します。
-
1つ以上の標準冗長性ディスク・グループが存在することを確認します。ない場合は作成します。
-
標準冗長性ディスク・グループに投票ファイルを再配置します。
$GI_HOME/bin/crsctl replace votedisk +normal_redundancy_diskgroup
-
ASMからquorumディスクを削除します。各quorumディスクに対して次のコマンドを実行します。
SQL> alter diskgroup diskgroup_name drop quorum disk quorum_disk_name force;
リバランス操作が完了するまで待機します。
v$asm_operationによってディスク・グループの行が返されなくなったら、完了です。 -
quorumデバイスを削除します。quorumディスクが存在する各データベース・ノードから次のコマンドを実行します。
/opt/oracle.SupportTools/quorumdiskmgr --delete --device [--asm-disk-group asm_disk_group] [--host-name host_name]
-
ターゲットを削除します。quorumディスクが存在する各データベース・ノードから次のコマンドを実行します。
/opt/oracle.SupportTools/quorumdiskmgr --delete --target [--asm-disk-group asm_disk_group]
-
構成を削除します。quorumディスクが存在する各データベース・ノードから次のコマンドを実行します。
/opt/oracle.SupportTools/quorumdiskmgr --delete –config
2.16.5.4 エラスティック構成の変更
2.16.5.4.1 データベース・ノードの追加
既存のOracle RACクラスタに2つ未満のデータベース・ノードと5台未満のストレージ・サーバーが含まれていて、投票ファイルが高冗長性ディスク・グループに配置されていない場合は、quorumディスクをデータベース・ノードに追加し、投票ファイルを高冗長性ディスク・グループに移動することをお薦めします。
注意:
「Quorumディスク管理のソフトウェア要件」に示されている要件を満たしている必要があります。
既存のOracle RACクラスタにすでにquorumディスクが配置されている場合は、addnode.shプロシージャを使用してOracle RACクラスタにノードを追加する前に、新規に追加するノードにquorumディスクを公開する必要があります。追加するノードにquorumディスクを公開するには、次の手順を実行します。
関連トピック
2.16.5.4.2 データベース・ノードの削除
削除するデータベース・ノードがquorumディスクをホストしていない場合は、必要な処置はありません。
削除するデータベース・ノードが投票ファイルを含むquorumディスクをホストしていて、RACクラスタ内のストレージ・サーバーが5台未満の場合、データベース・ノードを削除する前に別のデータベース・ノードにquorumディスクを作成する必要があります。次の手順を実行します。
-
現在quorumディスクをホストしていないデータベース・ノードにquorumディスクを作成します。
-
db01およびdb02に、ルートとしてログインします。
-
quorumdiskmgrコマンドを
--create --configオプションを使用して実行し、quorumディスク構成をdb01およびdb02の両方に作成します。# /opt/oracle.SupportTools/quorumdiskmgr --create --config --owner=grid --group=dba --network-iface-list="ib0, ib1"
-
quorumdiskmgrコマンドを
--list --configオプションを使用して実行し、構成がdb01およびdb02の両方に正しく作成されたことを確認します。# /opt/oracle.SupportTools/quorumdiskmgr --list --config
出力は次のようになります:
Owner: grid Group: dba ifaces: exadata_ib1 exadata_ib0
-
quorumdiskmgrコマンドを
--create --targetオプションを使用して実行し、ASMディスク・グループDATAC1のターゲットをdb01およびdb02の両方に作成し、両方で表示されるようにします。# /opt/oracle.SupportTools/quorumdiskmgr --create --target --asm-disk-group=datac1 --visible-to="192.168.10.45, 192.168.10.46, 192.168.10.47, 192.168.10.48"
-
quorumdiskmgrコマンドを
--list --targetオプションを使用して実行し、ターゲットがdb01およびdb02の両方に正しく作成されたことを確認します。# /opt/oracle.SupportTools/quorumdiskmgr --list --target
db01では、出力は次のようになります。
Name: iqn.2015-05.com.oracle:QD_DATAC1_DB01 Size: 128 MB Host name: DB01 ASM disk group name: DATAC1 Visible to: 192.168.10.45, 192.168.10.46, 192.168.10.47, 192.168.10.48 Discovered by:
db02では、出力は次のようになります。
Name: iqn.2015-05.com.oracle:QD_DATAC1_DB02 Size: 128 MB Host name: DB02 ASM disk group name: DATAC1 Visible to: 192.168.10.45, 192.168.10.46, 192.168.10.47, 192.168.10.48 Discovered by:
-
quorumdiskmgrコマンドを
--create --deviceオプションを使用して実行し、db01およびdb02の両方のターゲットから、db01およびdb02の両方にデバイスを作成します。# /opt/oracle.SupportTools/quorumdiskmgr --create --device --target-ip-list="192.168.10.45, 192.168.10.46, 192.168.10.47, 192.168.10.48"
-
quorumdiskmgrコマンドを--list --deviceオプションを使用して実行し、デバイスがdb01およびdb02の両方に正しく作成されたことを確認します。
# /opt/oracle.SupportTools/quorumdiskmgr --list --device
db01およびdb02の両方で、出力は次のようになります。
Device path: /dev/exadata_quorum/QD_DATAC1_DB01 Size: 128 MB Host name: DB01 ASM disk group name: DATAC1 Device path: /dev/exadata_quorum/QD_DATAC1_DB02 Size: 128 MB Host name: DB02 ASM disk group name: DATAC1
-
2つのquorumディスク・デバイスを高冗長性ASMディスク・グループに追加します。
高冗長性ディスク・グループがない場合は、高冗長性ディスク・グループを作成して、この2つの新しいquorumディスクを含めます。次に例を示します。
SQL> create diskgroup DATAC1 high redundancy quorum failgroup db01 disk '/dev/exadata_quorum/QD_ DATAC1_DB01' quorum failgroup db02 disk '/dev/exadata_quorum/QD_ DATAC1_DB02' ...
高冗長性ディスク・グループがすでに存在する場合は、2つの新しいquorumディスクを追加します。次に例を示します。
SQL> alter diskgroup datac1 add quorum failgroup db01 disk '/dev/exadata_quorum/QD_DATAC1_DB02' quorum failgroup db02 disk '/dev/exadata_quorum/QD_DATAC1_DB01';
-
-
データベース・ノードを削除すると、投票ファイルが手順1で追加したquorumディスクに自動的に再配置されます。
2.16.5.4.3 Oracle Exadata Storage Serverの追加および既存の高冗長性ディスク・グループの拡張
quorumディスクを使用するストレージ・サーバーを追加する場合は、新しく追加するストレージ・サーバーにデータベース・ノード上の投票ファイルを再配置することをお薦めします。
-
Exadataストレージ・サーバーを追加します。詳細は、「セル・ノードの追加」を参照してください。
次の例では、追加される新しいストレージ・サーバーの名前は"celadm04"です。
-
ストレージ・サーバーの追加後、
v$asm_disk内の新しい障害グループを確認します。SQL> select distinct failgroup from v$asm_disk; FAILGROUP ------------------------------ ADM01 ADM02 CELADM01 CELADM02 CELADM03 CELADM04
-
少なくとも1つのデータベース・ノードに投票ファイルを含むquorumディスクが含まれていることを確認します。
$ crsctl query css votedisk ## STATE File Universal Id File Name Disk group -- ----- ----------------- --------- --------- 1. ONLINE 834ee5a8f5054f12bf47210c51ecb8f4 (o/192.168.12.125;192.168.12.126/DATAC5_CD_00_celadm01) [DATAC5] 2. ONLINE f4af2213d9964f0bbfa30b2ba711b475 (o/192.168.12.127;192.168.12.128/DATAC5_CD_00_celadm02) [DATAC5] 3. ONLINE ed61778df2964f37bf1d53ea03cd7173 (o/192.168.12.129;192.168.12.130/DATAC5_CD_00_celadm03) [DATAC5] 4. ONLINE bfe1c3aa91334f16bf78ee7d33ad77e0 (/dev/exadata_quorum/QD_DATAC5_ADM01) [DATAC5] 5. ONLINE a3a56e7145694f75bf21751520b226ef (/dev/exadata_quorum/QD_DATAC5_ADM02) [DATAC5] Located 5 voting disk(s).
この例では、2つのデータベース・ノード上に投票ファイルを含む2つのquorumディスクがあります。
-
いずれか1つのquorumディスクを削除します。
SQL> alter diskgroup datac5 drop quorum disk QD_DATAC5_ADM01;
削除したquorumディスク上の投票ファイルは、投票ファイルのリフレッシュ時にグリッド・インフラストラクチャによって、新しく追加したストレージ・サーバー上に自動的に再配置されます。これは次の方法で確認できます。
$ crsctl query css votedisk ## STATE File Universal Id File Name Disk group -- ----- ----------------- --------- --------- 1. ONLINE 834ee5a8f5054f12bf47210c51ecb8f4 (o/192.168.12.125;192.168.12.126/DATAC5_CD_00_celadm01) [DATAC5] 2. ONLINE f4af2213d9964f0bbfa30b2ba711b475 (o/192.168.12.127;192.168.12.128/DATAC5_CD_00_celadm02) [DATAC5] 3. ONLINE ed61778df2964f37bf1d53ea03cd7173 (o/192.168.12.129;192.168.12.130/DATAC5_CD_00_celadm03) [DATAC5] 4. ONLINE a3a56e7145694f75bf21751520b226ef (/dev/exadata_quorum/QD_DATAC5_ADM02) [DATAC5] 5. ONLINE ab5aefd60cf84fe9bff6541b16e33787 (o/192.168.12.131;192.168.12.132/DATAC5_CD_00_celadm04) [DATAC5]
2.16.6 quorumdiskmgrリファレンス
quorumディスク管理ユーティリティ(quorumdiskmgr)を各データベース・サーバーで実行すると、iSCSI quorumディスクをデータベース・サーバー上に作成できます。quorumdiskmgrを使用して、iSCSI quorumディスクをデータベース・サーバーで作成、リスト、変更および削除できます。出荷時に、ユーティリティはデータベース・サーバーにインストールされます。
このリファレンスの項の内容は、次のとおりです。
2.16.6.1 Quorumディスク管理ユーティリティの構文
quorumディスク管理ユーティリティは、コマンドライン・ツールです。構文は次のとおりです。
quorumdiskmgr --verb --object [--options]
verbは、オブジェクト上で実行されるアクションです。これは、alter、create、delete、listのいずれかです。
objectは、コマンドでアクションを実行するオブジェクトです。
optionsは、コマンドの追加パラメータを使用できるようにコマンドの組合せの使用範囲を拡大します。
quorumdiskmgrユーティリティを使用する場合は、次のルールが適用されます:
-
動詞、オブジェクトおよびオプションは、明示的に指定されている場合を除き、大/小文字が区別されます。
-
二重引用符文字を使用して、オプションの値をスペースおよび句読点を含めて囲みます。
2.16.6.2 quorumdiskmgrオブジェクト
| オブジェクト | 説明 |
|---|---|
|
|
quorumディスク構成には、iSCSI quorumディスクを追加するASMインスタンスの所有者およびグループ、およびローカルおよびリモートiSCSI quorumディスクの発見で使用するネットワーク・インタフェースのリストが含まれます。 |
|
|
ターゲットは、各データベース・サーバー上のエンドポイントで、iSCSIイニシエータがセッションを確立するまで待機し、必要なIOデータ転送を提供します。 |
|
|
デバイスは、iSCSIデバイスで、ローカルまたはリモート・ターゲットへのログインで作成されます。 |
2.16.6.3 Quorumディスク構成の作成(--create --config)
--create --configアクションは、quorumディスク構成を作成します。構成は、ターゲットまたはデバイスが作成される前に作成する必要があります。
構文
quorumdiskmgr --create --config [--owner owner --group group] --network-iface-list network-iface-list
パラメータ
次の表に、--create --configアクションのパラメータを示します。
| パラメータ | 説明 |
|---|---|
|
owner |
iSCSI quorumディスクを追加するASMインタフェースの所有者を指定します。これはオプションのパラメータです。デフォルト値は、 |
|
group |
iSCSI quorumディスクを追加するASMインタフェースのグループを指定します。これはオプションのパラメータです。デフォルト値は |
|
network-iface-list |
ローカルおよびリモート・ターゲットの発見で使用されるネットワーク・インタフェース名のリストを指定します。 |
例
quorumdiskmgr --create --config --owner=oracle --group=dba --network-iface-list="ib0, ib1"
2.16.6.4 ターゲットの作成(--create --target)
--create --targetアクションは、指定されたInfiniBand IPアドレスのリスト内のInfiniBand IPアドレスを使用してデータベース・サーバーによりアクセスされるターゲットを作成し、指定されたASMディスク・グループに追加されるデバイスを作成します。
ターゲットが作成されると、そのasm-disk-group、host-nameおよびsize属性は変更できません。
構文
quorumdiskmgr --create --target --asm-disk-group asm_disk_group --visible-to infiniband_ip_list [--host-name host_name] [--size size]
パラメータ
| パラメータ | 説明 |
|---|---|
|
asm-disk-group |
ターゲットから作成されるデバイスが追加されるASMディスク・グループを指定します。asm-disk-groupの値は大/小文字が区別されません。 |
|
visible-to |
InfiniBand IPアドレスのリストを指定します。リスト内のInfiniBand IPアドレスを持つデータベース・サーバーは、ターゲットへのアクセスがあります。 |
|
host-name |
quorumdiskmgrが稼働するデータベース・サーバーのホスト名を指定します。asm-disk-groupおよびhost-nameの合計の長さは、26文字を超えてはいけません。ホスト名が長すぎる場合、クオータ・ラックの各データベース・サーバーに別々のホスト名が指定されている場合にかぎり、短いホスト名を指定できます。 これはオプションのパラメータです。デフォルト値は、quorumdiskmgrが稼働するデータベース・サーバーのホスト名です。host-nameの値は大/小文字が区別されません。 |
|
size |
ターゲットのサイズを指定します。これはオプションのパラメータです。デフォルト値は128MBです。 |
例
quorumdiskmgr --create --target --size=128MB --asm-disk-group=datac1 --visible-to="192.168.10.45, 192.168.10.46" --host-name=db01
2.16.6.5 デバイスの作成(--create --device)
--create --deviceアクションは、指定されたIPアドレスのリスト内のInfiniBand IPアドレスを使用してターゲットを発見およびログインし、デバイスを作成します。
作成されたデバイスは、構成の作成中に指定された所有者およびグループのあるASMインスタンスにより、自動的に発見されます。
構文
quorumdiskmgr --create --device --target-ip-list target_ip_list
パラメータ
| パラメータ | 説明 |
|---|---|
|
target-ip-list |
InfiniBand IPアドレスのリストを指定します。quorumdiskmgrは、InfiniBand IPアドレスを持つデータベース・サーバー上のターゲットを発見し、ターゲットにログインしてデバイスを作成します。 |
例
quorumdiskmgr --create --device --target-ip-list="192.168.10.45, 192.168.10.46"
2.16.6.6 Quorumディスク構成のリスト(--list --config)
--list --configアクションは、quorumディスク構成をリストします。
構文
quorumdiskmgr --list --config
出力例
Owner: grid Group: dba ifaces: exadata_ib1 exadata_ib0
2.16.6.7 ターゲットのリスト(--list --target)
--list --targetアクションは、ターゲット名、サイズ、ホスト名、ASMディスク・グループ名、ターゲットに対してアクセスを持つデータベース・サーバーを示すIPアドレスのリスト(visible-to IPアドレス・リスト)およびターゲットにログインしたデータベース・サーバーを示すIPアドレスのリスト(discovered-by IPアドレス・リスト)を含むターゲットの属性をリストします。
ASMディスク・グループが指定された場合、アクションは、指定されたASMディスク・グループに作成されたすべてのローカル・ターゲットをリストします。それ以外の場合、アクションは、quorumディスクに作成されたすべてのローカル・ターゲットをリストします。
構文
quorumdiskmgr --list --target [--asm-disk-group asm_disk_group]
パラメータ
| パラメータ | 説明 |
|---|---|
|
asm-disk-group |
ASMディスク・グループを指定します。quorumdiskmgrは、このASMディスク・グループのすべてのローカル・ターゲットを表示します。asm-disk-groupの値は大/小文字が区別されません。 |
出力例
Name: iqn.2015-05.com.oracle:QD_DATAC1_DB01 Size: 128 MB Host name: DB01 ASM disk group name: DATAC1 Visible to: 192.168.10.48, 192.168.10.49, 192.168.10.46, 192.168.10.47 Discovered by: 192.168.10.47, 192.168.10.46
2.16.6.8 デバイスのリスト(--list --device)
--list --deviceアクションは、デバイス・パス、サイズ、ホスト名およびASMディスク・グループを含むデバイスの属性をリストします。
ASMディスク・グループ名のみが指定された場合、アクションは、ASMディスク・グループに追加されたすべてのデバイスをリストします。
ホスト名のみが指定された場合、アクションは、ホスト上のターゲットから作成されたすべてのデバイスをリストします。
ASMディスク・グループ名およびホスト名の両方が指定された場合、ホスト上のターゲットから作成され、ASMディスク・グループに追加された単一のデバイスをリストします。
ASMディスク・グループ名およびホスト名のいずれも指定されない場合、アクションは、すべてのquorumディスク・デバイスをリストします。
構文
quorumdiskmgr --list --device [--asm-disk-group asm_disk_group] [--host-name host_name]
パラメータ
| パラメータ | 説明 |
|---|---|
|
asm-disk-group |
デバイスが追加されたASMディスク・グループを指定します。asm-disk-groupの値は大/小文字が区別されません。 |
|
host-name |
ターゲット・デバイスが作成されたデータベース・サーバーのホスト名を指定します。host-nameの値は大/小文字が区別されません。 |
出力例
Device path: /dev/exadata_quorum/QD_DATAC1_DB01 Size: 128 MB Host name: DB01 ASM disk group name: DATAC1 Device path: /dev/exadata_quorum/QD_DATAC1_DB02 Size: 128 MB Host name: DB02 ASM disk group name: DATAC1
2.16.6.9 構成の削除(--delete --config)
--delete --configアクションは、quorumディスク構成を削除します。構成は、ターゲットまたはデバイスが存在しない場合にのみ削除できます。
構文
quorumdiskmgr --delete --config
2.16.6.10 ターゲットの削除(--delete --target)
--delete --targetアクションは、データベース・サーバー上のquorumディスクに作成されたターゲットを削除します。
ASMディスク・グループが指定された場合、アクションは、指定されたASMディスク・グループに作成されたすべてのローカル・ターゲットを削除します。それ以外の場合、アクションは、quorumディスクに作成されたすべてのローカル・ターゲットを削除します。
構文
quorumdiskmgr --delete --target [--asm-disk-group asm_disk_group]
パラメータ
| パラメータ | 説明 |
|---|---|
|
asm-disk-group |
ASMディスク・グループを指定します。このディスク・グループに作成されたローカル・ターゲットが削除されます。asm-disk-groupの値は大/小文字が区別されません。 |
例
quorumdiskmgr --delete --target --asm-disk-group=datac1
2.16.6.11 デバイスの削除(--delete --device)
--delete --deviceアクションは、quorumディスク・デバイスを削除します。
ASMディスク・グループ名のみが指定された場合、アクションは、ASMディスク・グループに追加されたすべてのデバイスを削除します。
ホスト名のみが指定された場合、アクションは、ホスト上のターゲットから作成されたすべてのデバイスを削除します。
ASMディスク・グループ名およびホスト名の両方が指定された場合、ホスト上のターゲットから作成され、ASMディスク・グループに追加された単一のデバイスを削除します。
ASMディスク・グループ名およびホスト名のいずれも指定されない場合、アクションは、すべてのquorumディスク・デバイスを削除します。
構文
quorumdiskmgr --delete --device [--asm-disk-group asm_disk_group] [--host-name host_name]
パラメータ
| パラメータ | 説明 |
|---|---|
|
asm-disk-group |
削除する対象のデバイスのASMディスク・グループを指定します。asm-disk-groupの値は大/小文字が区別されません。 |
|
host-name |
データベース・サーバーのホスト名を指定します。このホスト上のターゲットから作成されたデバイスが削除されます。host-nameの値は大/小文字が区別されません。 |
例
quorumdiskmgr --delete --device --host-name=db01
2.16.6.12 所有者とグループ値の変更(--alter --config)
--alter --configアクションは、所有者およびグループ構成を変更します。
構文
quorumdiskmgr --alter --config --owner owner --group group
パラメータ
| パラメータ | 説明 |
|---|---|
|
owner |
quorumディスク構成の新しい所有者を指定します。このパラメータは省略可能です。指定しない場合、所有者は変更されません。 |
|
group |
quorumディスク構成の新しいグループを指定します。このパラメータは省略可能です。指定しない場合、グループは変更されません。 |
例
quorumdiskmgr --alter --config --owner=grid --group=dba
2.16.6.13 InfiniBand IPアドレスの変更(--alter --target)
--alter --targetアクションは、指定されたASMディスク・グループに作成されたローカル・ターゲットへのアクセスを持つデータベース・サーバーのInfiniBand IPアドレスを変更します。
構文
quorumdiskmgr --alter --target --asm-disk-group asm_disk_group --visible-to infiniband_ip_list
パラメータ
| パラメータ | 説明 |
|---|---|
|
asm-disk-group |
ターゲットから作成されるデバイスが追加されるASMディスク・グループを指定します。asm-disk-groupの値は大/小文字が区別されません。 |
|
visible-to |
InfiniBand IPアドレスのリストを指定します。リスト内のInfiniBand IPアドレスを持つデータベース・サーバーは、ターゲットへのアクセスがあります。 |
例
quorumdiskmgr --alter --target --asm-disk-group=datac1 --visible-to="192.168.10.45, 192.168.10.47"
2.17 vmetricsの使用
vmetricsパッケージを使用すると、vmetricsサービスで収集されたシステム統計を表示できます。dom0またはdomUから、システム統計にアクセスできます。vmetricsサービスはdom0上で稼働して、統計を収集し、それらをxenstoreへプッシュします。これにより、domU'sが統計にアクセスできます。
vmetricsサービスによって収集されたシステム統計を、サンプル値を使用して次に表示します:
com.sap.host.host.VirtualizationVendor=Oracle Corporation;
com.sap.host.host.VirtProductInfo=Oracle VM 3;
com.sap.host.host.PagedInMemory=0;
com.sap.host.host.PagedOutMemory=0;
com.sap.host.host.PageRates=0;
com.sap.vm.vm.uuid=2b80522b-060d-47ee-8209-2ab65778eb7e;
com.sap.host.host.HostName=scac10adm01.us.oracle.com;
com.sap.host.host.HostSystemInfo=scac10adm01;
com.sap.host.host.NumberOfPhysicalCPUs=24;
com.sap.host.host.NumCPUs=4;
com.sap.host.host.TotalPhyMem=98295;
com.sap.host.host.UsedVirtualMemory=2577;
com.sap.host.host.MemoryAllocatedToVirtualServers=2577;
com.sap.host.host.FreeVirtualMemory=29788;
com.sap.host.host.FreePhysicalMemory=5212;
com.sap.host.host.TotalCPUTime=242507.220000;
com.sap.host.host.Time=1453150151;
com.sap.vm.vm.PhysicalMemoryAllocatedToVirtualSystem=8192;
com.sap.vm.vm.ResourceMemoryLimit=8192;
com.sap.vm.vm.TotalCPUTime=10160.1831404;
com.sap.vm.vm.ResourceProcessorLimit=4;
2.17.1 vmetricsサービスのインストールと起動
vmetricsサービスをインストールするには、dom0上でrootユーザーとしてinstall.shスクリプトを実行します:
[root@scac10adm01]# cd /opt/oracle.SupportTools/vmetrics [root@scac10adm01]# ./install.sh
install.shスクリプトは、それがdom0で実行中であり、現在実行中のvmetricsサービスを停止、パッケージ・ファイルを/opt/oracle.vmetricsにコピーおよびvmetrics.svcを/etc/init.dにコピーすることを、確認します。
vmetricsサービスをdom0で開始するには、dom0上でrootユーザーとして次のコマンドを実行します:
[root@scac10adm01 vmetrics]# service vmetrics.svc start
統計を収集するコマンドは、30秒ごとに実行されます。
2.17.2 vmetricsパッケージ内のファイル
vmetricsパッケージには次のファイルが含まれます:
| ファイル | 説明 |
|---|---|
|
|
このファイルは、パッケージをインストールします。 |
|
|
このスクリプトは、統計をxenstoreから読み取り、それらをXML形式で表示します。 |
|
|
このPythonスクリプトは、システム・コマンドを実行し、それらをxenstoreにアップロードします。システム・コマンドは、 |
|
|
このXMLファイルは、dom0がxenstoreへプッシュするべきメトリックおよび各メトリックで実行するシステム・コマンドを指定します。 |
|
|
vmetricsをLinuxサービスにする |
2.17.3 統計の表示
統計がxenstoreにプッシュされた後、次のいずれかのコマンドを実行すると、dom0およびdomU上に統計を表示できます:
注意:
domU's上に、xenstoreproviderおよびovmdパッケージがインストールされていることを確認してください。
xenstoreproviderは、ovmapiカーネル・インフラストラクチャと通信するライブラリです。
ovmdは、構成および再構成イベントを処理し、VMとOracle VMマネージャの間でメッセージを送信/受信するメカニズムを提供するするデーモンです。
次のコマンドを使用して、Oracle VM APIをサポートするためにOracle Linux 5および6で必要なパッケージをインストールします。
# yum install ovmd xenstoreprovider
-
/usr/sbin/ovmd -g vmhostコマンドは、1つのライン上の統計を表示します。sedコマンドは、ラインを複数のラインに分割し、ラインごとに統計します。このコマンドは、rootユーザーとして実行する必要があります。root@scac10db01vm04 ~]# /usr/sbin/ovmd -g vmhost |sed 's/; */;\n/g;s/:"/:"\n/g' com.sap.host.host.VirtualizationVendor=Oracle Corporation; com.sap.host.host.VirtProductInfo=Oracle VM 3; com.sap.host.host.PagedInMemory=0; com.sap.host.host.PagedOutMemory=0; com.sap.host.host.PageRates=0; com.sap.vm.vm.uuid=2b80522b-060d-47ee-8209-2ab65778eb7e; com.sap.host.host.HostName=scac10adm01.us.oracle.com; com.sap.host.host.HostSystemInfo=scac10adm01; com.sap.host.host.NumberOfPhysicalCPUs=24; com.sap.host.host.NumCPUs=4; ...
-
vm-dump-metricsコマンドは、XML形式でメトリックを表示します。[root@scac10db01vm04 ~]# ./vm-dump-metrics <metrics> <metric type='real64' context='host'> <name>TotalCPUTime</name> <value>242773.600000</value> </metric> <metric type='uint64' context='host'> <name>PagedOutMemory</name> <value>0</value> </metric> ...
vm-dump-metricsコマンドを、コマンドを実行するdomU'sにコピーすることに注意してください。