1. メンテナンス・ガイド
  2. Oracle Exadata Storage Serverの保守

3 Oracle Exadata Storage Serverの保守

Oracle Exadata Storage Serverに含まれているディスクやメモリー・デバイスには保守が必要になることがあります。

ノート:

  • この章のすべての手順は、Exadata Database MachineおよびOracle Exadata Storage拡張ラックに適用されます。
  • 読みやすさを考慮して、Exadata Database MachineとOracle Exadata Storage拡張ラックの両方に言及する場合、「Oracle Exadataラック」という名前を使用します。

3.1 Oracle Exadata Storage Serverの保守

この項では、Oracle Exadata Storage Serverの保守を実行する方法について説明します。

親トピック: Oracle Exadata Storage Serverの保守

3.1.1 Exadata Storage Serverのシャットダウン

Exadata Storage Serverの保守を実行する場合、セルの電源切断または再起動が必要になることがあります。

1つ以上のデータベースの実行中にExadata Storage Serverを停止する場合、Exadata Storage ServerのオフラインによるOracle ASMディスク・グループおよびデータベース可用性への影響がないことを確認する必要があります。データベースの可用性に影響を及ぼすことなくExadata Storage Serverをオフラインにする機能は、影響を受けるディスク・グループで使用されるOracle ASMの冗長性レベルによって異なります。可用性は、オフラインにするExadata Storage Serverのデータのミラー・コピーを持つ他のExadata Storage Serverのディスクの現在のステータスによっても異なります。

  1. オプション: セルの再起動後にオフラインのままになるようにグリッド・ディスクを構成します。
    再起動を複数回行うことを予定している場合、またはExadata Storage Serverがアクティブになるタイミングを制御する場合は、このステップを実行できます。グリッド・ディスクを非アクティブにすると、グリッド・ディスクを再度使用可能にする前に、計画したメンテナンス・アクティビティが成功したことを確認できます。
    1. グリッド・ディスクを非アクティブに設定します。
      CellCLI> ALTER GRIDDISK ALL INACTIVE
    2. 30秒以上待機するか、Oracle ASMで対応するOracle ASMディスクがオフラインになるまで待ちます。
      リリース18.1より前のバージョンのOracle Exadata System Softwareを使用している場合、このステップは非常に重要です。スクリプトにコマンドを記述する場合は、30秒を超える値でsleepコマンドを追加してください。

    ノート:

    グリッド・ディスクを非アクティブに設定した場合は、後でステップ6を実行してグリッド・ディスクをアクティブ化する必要があります。
  2. セル・サービスを停止します。
    CellCLI> ALTER CELL SHUTDOWN SERVICES ALL

    前述のコマンドでは、オフラインのディスクがないか、predictive failureステータスのディスクがないか、またはミラーにコピーする必要があるディスクがないかをチェックします。Oracle ASM冗長性が損なわれていない場合は、コマンドによりOracle ASMでグリッド・ディスクがオフラインに変更され、セル・サービスが停止されます。次のエラーが表示された場合は、冗長性が原因でディスク・グループが強制的にディスマウントされ、セル・サービスを安全に停止できない可能性があります。 

    Stopping the RS, CELLSRV, and MS services...
The SHUTDOWN of ALL services was not successful.
CELL-01548: Unable to shut down CELLSRV because disk group DATA, RECO may be
forced to dismount due to reduced redundancy.
Getting the state of CELLSRV services... running
Getting the state of MS services... running
Getting the state of RS services... running

    CELL-01548エラーが発生した場合は、Oracle ASMディスク・グループの冗長性をリストアし、すべてのディスクのディスク・ステータスが正常に戻ってからコマンドを再試行してください。

  3. Exadata Storage Serverをシャットダウンします。
  4. メンテナンスの実行後、Exadata Storage Serverを再起動します。セル・サービスが自動的に開始されます。Exadata Storage Serverの起動の一環として、Oracle ASMですべてのグリッド・ディスクがONLINEに自動的に変更されます。
  5. すべてのグリッド・ディスクが正常にオンラインになったことを確認します。
    CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus

    すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。

  6. オプション: グリッド・ディスクのステータスをONLINEに変更します。

    このステップは、ステップ1を実行した場合にのみ必要です。ステップ1を実行しなかった場合、Exadata Storage Serverの再起動時にグリッド・ディスクが自動的にオンラインに設定されます。 

    CellCLI> ALTER GRIDDISK ALL ACTIVE

親トピック: Oracle Exadata Storage Serverの保守

3.1.2 リバランス操作のステータスのチェック

ディスクの削除時または追加時に、Oracle ASMリバランス操作のステータスを確認できます。

  • リバランス操作が正常に完了している可能性があります。Oracle ASMアラート・ログを確認してください。

  • リバランス操作が現在実行されている可能性がある場合。GV$ASM_OPERATIONビューを確認して、リバランス操作が実行されているかどうか判別します。

  • リバランス操作が失敗した可能性がある場合。V$ASM_OPERATION.ERRORビューを確認して、リバランス操作が失敗したかどうか判別します。

  • 交換される物理ディスクに複数のディスク・グループのOracle ASMディスクが含まれる場合、複数のディスク・グループのリバランス操作を同じクラスタの異なるOracle ASMインスタンスで実行できます。Oracle ASMインスタンスは、一度に1つのリバランス操作を実行できます。すべてのOracle ASMインスタンスがビジー状態の場合、リバランス操作がキューに入れられます。

ノート:

BP4のOracle Databaseリリース12.1.0.2と一緒にOracle Exadata System Softwareリリース12.1.2.0を実行しているOracle Exadata Storage Serverの場合、Oracle ASMはリバランス操作のステータスについての電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。

親トピック: Oracle Exadata Storage Serverの保守

3.1.3 診断ISOを使用したネットワーク接続の有効化

ストレージ・サーバーが再起動しない場合は、セルにアクセスして手動で修復できるようにするために、診断ISOが必要になることがあります。

USBの使用など、他のブート方法が機能しない場合は、診断ISOを使用してください。

次に、ファイルを転送してセルを修復できるように、診断ISOとのネットワーキングを有効にする手順を示します。

  1. diagnostics.isoファイルを使用してシステムを再起動します。
    Oracle Exadata System Softwareユーザーズ・ガイドの診断ISOファイルを使用したサーバーの起動を参照してください。
  2. 診断シェルにrootユーザーとしてログインします。
    プロンプトが表示されたら、診断シェルに入ります。

    次に例を示します。

    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, 
Type e to enter the diagnostics shell and log in as the root user.
    プロンプトが表示されたら、rootユーザーとしてシステムにログインします。rootユーザーのパスワードの入力を求められ、それが不明である場合は、Oracleサポート・サービスに連絡してください。
  3. 次のコマンドを使用してpingを回避します。
    alias ping="ping -c"
  4. /etc/networkという名前のディレクトリを作成します。
  5. /etc/network/if-pre-up.dという名前のディレクトリを作成します。
  6. /etc/network/interfacesファイルに次の行を追加します。 
    iface eth0 inet static
address IP_address_of_cell
netmask netmask_of_cell
gateway gateway_IP_address_of_cell
  7. 次のコマンドを使用して、eth0インタフェースを起動します。
    ifup eth0

    いくつかの警告メッセージが表示される場合もありますが、インタフェースは稼働しています。

  8. FTPまたはwgetコマンドを使用して、セルを修理するためのファイルを取得します。

親トピック: Oracle Exadata Storage Serverの保守

3.2 Exadata拡張(XT)ストレージ・サーバーの使用

Oracle Exadata拡張(XT)ストレージ・サーバーは、アクセス頻度の低いデータ、古いデータまたは規制データに使用できる低コストのストレージ・オプションを提供します。

親トピック: Oracle Exadata Storage Serverの保守

3.2.1 Oracle Exadata拡張(XT)ストレージ・サーバーについて

Oracle Exadata拡張(XT)ストレージ・サーバーは、オンライン状態の維持が必要なアクセス頻度の低いデータに向けて、Exadata Database Machineの操作性および管理性の利点を拡張するために利用できます。

各XTストレージ・サーバーには、12個の大容量ディスク・ドライブが含まれています。ただし、低コストを実現するため、フラッシュ・デバイスは含まれていません。また、Oracle Exadata System Softwareのライセンスはオプションであり、一部のソフトウェア機能はライセンスがないかぎり無効になります。ハイブリッド列圧縮は、Oracle Exadata System Softwareライセンスを必要とせずに組み込まれています。

XTストレージ・サーバーは、Oracle Exadataラック内のその他のサーバーと同じRDMAネットワーク・ファブリックを使用します。XTストレージ・サーバーにより、アプリケーションに対する透過性、SQLに対する透過性、および同一の操作モデルを維持したまま、ストレージ容量が追加されます。Exadataに使用しているものと同じセキュリティ・モデルと暗号化を使用できます。

XTストレージ・サーバーは、エイス・ラック構成を含むOracle ExadataラックX4以降に追加できます。最初に少なくとも2台のサーバーを追加する必要があります。最初の2台のサーバーの後は、必要に応じてXTストレージ・サーバーを追加できます。高冗長性を実装するには、最小3台のXTストレージ・サーバーが必要になります。XTストレージ・サーバーは、High Capacity (HC)およびExtreme Flash (EF)ストレージ・サーバーと同じ配置パターンに従います。

Oracle ASMディスク・グループは、ストレージ・サーバー(HC、EFまたはXT)のいずれかのタイプのみが提供するストレージを使用する必要があります。XTストレージ・サーバーをラックに追加したら、そのストレージを使用する新しいディスク・グループを作成します。XTストレージ・サーバーのデフォルトのディスク・グループ名はXTNDです。ただし、別の名前を必要に応じて使用することもできます。

XTストレージ・サーバーは、Oracle Databaseに完全統合されるストレージを提供します。Oracleパーティション化、Oracle自動データ最適化、Oracle拡張圧縮などのデータベース機能が備わった新しいディスク・グループを使用できます。

親トピック: Exadata拡張(XT)ストレージ・サーバーの使用

3.2.2 Oracle Exadata拡張(XT)ストレージ・サーバーに格納できるデータについて

Oracle Exadata拡張(XT)ストレージ・サーバーは、アクセス頻度の低いデータ、古いデータまたは規制データのために低コストのストレージを提供することを目的としています。

XTストレージ・サーバーは、すべての必須データのオンライン状態を維持して問合せで利用できるようにするために役立ちます。次のようなデータが挙げられます。

  • 履歴データ
  • イメージ、BLOB、契約内容などの大きな表ベースのオブジェクト
  • コンプライアンスおよび規制データ
  • ローカル・バックアップ

XTストレージ・サーバーは、本番データベースと比べてパフォーマンス要件の緩い開発データベースにストレージを提供することもできます。

親トピック: Exadata拡張(XT)ストレージ・サーバーの使用

3.2.3 Exadata拡張(XT)ストレージ・サーバーのスマート・スキャンの有効化

Oracle Exadata拡張(XT)ストレージ・サーバーのOracle Exadata System Softwareライセンスを購入していると、スマート・スキャンやストレージ索引などのパフォーマンスを向上するための機能を有効化できます。

  1. Oracle Exadata System Softwareライセンスを購入するか譲り受けます。

    スマート・スキャンを有効化するには、すべてのデバイスにライセンスが必要です。

  2. XTストレージ・サーバーのenableSmartStorage属性を変更します。

    最初にストレージ・サーバーを停止する必要はありません。ライセンスのある各XTストレージ・サーバーで、次のコマンドを実行します。

    cellcli -e ALTER CELL enableSmartStorage=true
  3. セルが変更されたことを確認します。
    cellcli -e "LIST CELL ATTRIBUTES name, status, enableSmartStorage"

親トピック: Exadata拡張(XT)ストレージ・サーバーの使用

3.3 Oracle Exadata Storage Serverのハード・ディスクの保守

Oracle Exadataラック内のすべてのOracle Exadata Storage Serverにシステム領域があり、その領域にOracle Exadata System Softwareシステム・ソフトウェアが常駐しています。Exadata Database Machine X7以降のシステムでは、このシステム領域は2つの内蔵M.2デバイスにあります。その他すべてのシステムでは、Oracle Exadata Storage Serverの最初の2つのディスクがシステム・ディスクとなっています。これらのシステム・ディスクの一部はシステム領域と呼ばれています。

Exadata Database Machine X7以降のシステムでは、セル内のハード・ディスクはすべてデータ・ディスクになっています。Exadata Database Machine X7より前のシステムでは、システム・ディスクのシステム領域以外の部分(データ・パーティションと呼ばれる)が通常のデータ・ストレージとして使用されます。セル内の他のディスクはすべてデータ・ディスクです。

Oracle Exadata System Softwareリリース11.2.3.2.0以降では、ディスク障害が発生すると、Oracle Exadata System Softwareによってディスクが交換可能であることを示すアラートが送信され、そのディスクの外部にすべてのデータがリバランスされた後で予測障害のあるハード・ディスクの青色の取外しOKのLEDが点灯します。リリース11.2.3.2.0より前のOracle Exadata System Softwareでは、ハード・ディスクに予測障害がある場合、青色のLEDではなく黄色の障害サービス必須LEDが点灯していました。このような場合、ディスクの交換を進める前に、すべてのデータがそのディスクの外部にリバランスされたかどうかを手動でチェックする必要があります。

Oracle Exadata System Softwareリリース18.1.0.0.0およびExadata Database Machine X7システム以降では、冗長性が低くなったことを示す白色のサービス不可LEDが追加され、これにより、システム管理者やフィールド・エンジニアは、サービスのためにストレージ・サーバーの電源を切断することは避ける必要があることがわかります。冗長性がリストアされると、Oracle Exadata System Softwareによりサービス不可LEDが自動的に消灯され、サービスのためにセルの電源を切断できることが示されます。

ハード・ディスクで障害が発生すると、ドライブの青色の取外しOKのLEDと黄色の障害サービス必須LEDが両方とも点灯し、ディスク交換作業を実施できることが示されます。動作はすべてのリリースで同じです。Oracle Exadata System Softwareリリース11.2.3.2.0以降ではドライブLEDが点灯しますが、それより前のリリースではドライブLEDが点滅します。

ノート:

Oracle Exadata Storage Serverの物理ディスクを交換しているあいだ、Oracle Exadataラックはオンラインであり、使用可能です。

この項では、次の項目について説明します。

関連トピック

親トピック: Oracle Exadata Storage Serverの保守

3.3.1 ハード・ディスクのステータスの監視

CellCLI LIST PHYSICALDISKコマンドを使用して属性をチェックすることによって、ハード・ディスクのステータスを監視できます。

たとえば、ハード・ディスクのステータスが障害 (以前のリリースでは、障害が発生したハード・ディスクのステータスはクリティカルでした)または警告 - 予測障害と同等の場合、問題が発生している可能性があり、交換が必要です。内部しきい値を超えると、ディスク・ファームウェアによってエラー・カウンタが保守され、ドライブはPredictive Failureとマーク付けされます。交換が必要かどうかは、セル・ソフトウェアではなくドライブによって決定されます。

  • CellCLIコマンドLIST PHSYICALDISKを使用すると、ハード・ディスクのステータスを調べることができます。
    CellCLI> LIST PHYSICALDISK WHERE disktype=harddisk AND status!=normal DETAIL
         name:                            8:4
         deviceId:              12
           deviceName:                   /dev/sde
           diskType:                      HardDisk
         enclosureDeviceId:      8
         errOtherCount:          0
         luns:                   0_4
           makeModel:                    "HGST    H7280A520SUN8.0T"
         physicalFirmware:         PD51
         physicalInsertTime:      2016-11-30T21:24:45-08:00
         physicalInterface:     sas
         physicalSerial:            PA9TVR
         physicalSize:               7.153663907200098T
         slotNumber:                  4
         status:                        failed

ディスクI/Oエラーが発生すると、Oracle ASMはメディア・エラーによる読取りエラーの障害範囲の修理を実行します。ディスクはオンラインのままで、アラートは送信されません。Oracle ASMが物理的に対処されたメタデータ・ブロックに関する読取りエラーを取得すると、ブロックはミラーリングされず、ディスクはオフラインになります。その後、Oracle ASMはFORCEオプションを使用してディスクを削除します。

Oracle Exadata Storage Serverのハード・ディスク・ステータスは次のとおりです。

  • Oracle Exadata System Softwareリリース11.2.3.3以降:

    • 正常
    • 正常 - 交換のため切断
    • 正常 - 制限されたオンライン
    • 正常 - 制限されたオンライン - 交換のため切断
    • 存在しない
    • 失敗
    • 障害 - 交換のため切断
    • 障害 - 不適切なディスク・モデルのため拒否
    • 障害 - 不適切なディスク・モデルのため拒否 - 交換のため切断
    • 障害 - 間違ったスロットのため拒否
    • 障害 - 間違ったスロットのため拒否 - 交換のため切断
    • 警告 - 制限されたオンライン
    • 警告 - 制限されたオンライン - 交換のため切断
    • 警告 - ピア障害
    • 警告 - 低いパフォーマンス
    • 警告 - 低いパフォーマンス - 交換のため切断
    • 警告 - 低いパフォーマンス、ライトスルー・キャッシュ
    • 警告 - 予測障害、低いパフォーマンス
    • 警告 - 予測障害、低いパフォーマンス - 交換のため切断
    • 警告 - 予測障害、ライトスルー・キャッシュ
    • 警告 - 予測障害
    • 警告 - 予測障害 - 交換のため切断
    • 警告 - 予測障害、低いパフォーマンス、ライトスルー・キャッシュ
    • 警告 - ライトスルー・キャッシュ

  • Oracle Exadata System Softwareリリース11.2.3.2:

    • 正常
    • 正常 - 制限されたオンライン
    • 存在しない
    • 失敗
    • 障害 - 不適切なディスク・モデルのため拒否
    • 障害 - 間違ったスロットのため拒否
    • 警告 - 制限されたオンライン
    • 警告 - ピア障害
    • 警告 - 低いパフォーマンス
    • 警告 - 低いパフォーマンス、ライトスルー・キャッシュ
    • 警告 - 予測障害、低いパフォーマンス
    • 警告 - 予測障害、ライトスルー・キャッシュ
    • 警告 - 予測障害
    • 警告 - 予測障害、低いパフォーマンス、ライトスルー・キャッシュ
    • 警告 - ライトスルー・キャッシュ

  • Oracle Exadata System Softwareリリース11.2.3.1.1以前:

    • 正常
    • critical
    • 低いパフォーマンス
    • 予測障害
    • 存在しない

関連トピック

親トピック: Oracle Exadata Storage Serverのハード・ディスクの保守

3.3.2 ハード・ディスク・コントローラのライトスルー・キャッシュ・モードの監視

各Oracle Exadata Storage Serverのハード・ディスク・コントローラは、定期的にコントローラのバッテリの放電と充電を実行します。操作中は、書込みキャッシュ・ポリシーにより、ライトバック・キャッシュからライトスルー・キャッシュに変更されます。

ライトスルー・キャッシュ・モードはライトバック・キャッシュ・モードより時間を要します。ただし、Oracle Exadata Storage Serverの電源が落ちたり障害が発生したりすると、ライトバック・キャッシュ・モードの場合はデータ損失のリスクがあります。Oracle Exadata System Softwareリリース11.2.1.3以前の場合は、この処理が毎月発生します。リリース11.2.1.3.0以上のOracle Exadata System Softwareの場合、この処理は3か月ごとに発生します(たとえば、1月、4月、7月、10月の17日の01:00時)。

  • 学習サイクルの開始時間を変更するには、次のようなコマンドを使用します。
    CellCLI> ALTER CELL bbuLearnCycleTime="2013-01-22T02:00:00-08:00"

    サイクルが終了すると、時間はデフォルト学習時間に戻ります。

  • 次の学習サイクル時間を確認するには、次のコマンドを使用します。
    CellCLI> LIST CELL ATTRIBUTES bbuLearnCycleTime

    Oracle Exadata Storage Serverによって、次のようなセル上の論理ドライブのキャッシュ・モードの状態に関するアラート情報が生成されます。 

    HDD disk controller battery on disk controller at adapter 0 is going into a learn
cycle. This is a normal maintenance activity that occurs quarterly and runs for
approximately 1 to 12 hours. The disk controller cache might go into WriteThrough
caching mode during the learn cycle. Disk write throughput might be temporarily
lower during this time. The message is informational only, no action is required.
  • バッテリのステータスを表示するには、次の例に示すようなコマンドを使用します。

    ノート:

    Oracle Exadata System Software 19.1.0以上を実行している場合は、次のコマンドで/opt/MegaRAID/MegaCli/MegaCli64を/opt/MegaRAID/storcli/storcli64に置き換えます。 
    # /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuStatus -a0
BBU status for Adapter: 0
 
BatteryType: iBBU08
Voltage: 3721 mV
Current: 541 mA
Temperature: 43 C
 
BBU Firmware Status:
Charging Status : Charging
Voltage : OK
Temperature : OK
Learn Cycle Requested : No
Learn Cycle Active : No
Learn Cycle Status : OK
Learn Cycle Timeout : No
I2c Errors Detected : No
Battery Pack Missing : No
Battery Replacement required : No
Remaining Capacity Low : Yes
Periodic Learn Required : No
Transparent Learn : No
 
Battery state:
 
GasGuageStatus:
Fully Discharged : No
Fully Charged : No
Discharging : No
Initialized : No
Remaining Time Alarm : Yes
Remaining Capacity Alarm: No
Discharge Terminated : No
Over Temperature : No
Charging Terminated : No
Over Charged : No
 
Relative State of Charge: 7 %
Charger System State: 1
Charger System Ctrl: 0
Charging current: 541 mA
Absolute state of charge: 0 %
Max Error: 0 %
 
Exit Code: 0x00

親トピック: Oracle Exadata Storage Serverのハード・ディスクの保守

3.3.3 ディスク障害によるハード・ディスクの交換

ハード・ディスクの停止により、パフォーマンスおよびデータの冗長性の低下が発生する場合があります。したがって、すぐにディスクを新しいディスクに交換する必要があります。ディスクに障害が発生すると、ハード・ディスクのグリッド・ディスクに関連するOracle ASMディスクがFORCEオプションで自動的に削除され、Oracle ASMリバランスでデータの冗長性がリストアされます。

ディスクに障害が発生すると、Exadataアラートが生成されます。アラートには、ディスクを交換する特定の手順が含まれます。システムのアラート通知を構成している場合、電子メールでアラートが指定したアドレスに送信されます。

ハード・ディスクを交換すると、そのスロットの前のディスクにあったグリッド・ディスクとセル・ディスクは新しいハード・ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMグループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

ノート:

BP4のOracle Databaseリリース12.1.0.2と一緒にOracle Exadata System Softwareリリース12.1.2.0を実行しているストレージ・サーバーの場合、Oracle ASMはリバランス操作のステータスについての電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。

以前のリリースのリバランス操作ステータスについて、「リバランス操作のステータスのチェック」を参照してください

次の手順は、ディスク障害によるハード・ディスクの交換方法を示しています。

  1. 次のコマンドを使用して、障害が発生したディスクを特定します。
    CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status=failed DETAIL

    次に、コマンドの出力例を示します。スロット番号はディスクの場所、ステータスはディスクに障害が発生したことを示します。 

    CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status=failed DETAIL

         name:                   28:5
         deviceId:               21
         diskType:               HardDisk
         enclosureDeviceId:      28
         errMediaCount:          0
         errOtherCount:          0
         foreignState:           false
         luns:                   0_5
         makeModel:              "SEAGATE ST360057SSUN600G"
         physicalFirmware:       0705
         physicalInterface:      sas
         physicalSerial:         A01BC2
         physicalSize:           558.9109999993816G
         slotNumber:             5
         status:                 failed
  2. ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。
  3. Oracle Exadata Storage Server上のハード・ディスクを交換し、3分待ちます。ハード・ディスクはホットプラグ対応で、電源の投入時に交換できます。
  4. ディスクがオンラインであることを確認します。

    交換したハード・ディスクは、RAIDコントローラによって認識されるまで使用できません。この処理にあまり時間は要しません。

    次のようなLIST PHYSICALDISKコマンドを使用して、ステータスがNORMALであることを確認します。 

    CellCLI> LIST PHYSICALDISK WHERE name=28:5 ATTRIBUTES status
  5. ALTER CELL VALIDATE CONFIGURATIONコマンドを使用して、ファームウェアが正しいことを確認します。

まれに、自動ファームウェア更新が機能せず、LUNが再構築されない場合があります。これは、ms-odl.trcファイルをチェックして確認できます。

関連項目:

親トピック: Oracle Exadata Storage Serverのハード・ディスクの保守

3.3.4 ディスクの問題によるハード・ディスクの交換

ハード・ディスクが警告 - 予測障害ステータスになったために、ディスクの交換が必要になる場合もあります。

予測障害ステータスは、ハード・ディスクに障害が発生する可能性があり、できるだけすぐに交換する必要があることを示します。ハード・ドライブのグリッド・ディスクに関連するOracle ASMディスクが自動的に削除され、Oracle ASMリバランスで障害が発生する可能性のあるディスクから他のディスクにデータが移動されます。

ハード・ドライブが故障する前に削除を完了できなかった場合は、「ディスク障害によるハード・ディスクの交換」を参照してください

ディスクを削除すると、アラートが送信されます。ハード・ディスクを交換すると、スロットの前のディスクにあったグリッド・ディスクとセル・ディスクは新しいハード・ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

ノート:

BP4のOracle Databaseリリース12.1.0.2と一緒にOracle Exadata System Softwareリリース12.1.2.0を実行しているOracle Exadata Storage Serverでは、Oracle ASMはリバランス操作のステータスについての電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。

以前のリリースのリバランス操作ステータスについて、「リバランス操作のステータスのチェック」を参照してください

  1. 障害が発生したディスクを特定します。
    CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status= \
        "warning - predictive failure" DETAIL

    出力例を次に示します。スロット番号はディスクの場所、ステータスはディスクに障害が発生する可能性があることを示します。 

    CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status= \
         "warning - predictive failure" DETAIL
         name:                   28:3
         deviceId:               19
         diskType:               HardDisk
         enclosureDeviceId:      28
         errMediaCount:          0
         errOtherCount:          0
         foreignState:           false
         luns:                   0_3
         makeModel:              "SEAGATE ST360057SSUN600G"
         physicalFirmware:       0705
         physicalInterface:      sas
         physicalSerial:         E07L8E
         physicalSize:           558.9109999993816G
         slotNumber:             3
         status:                 warning - predictive failure
  2. ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。
  3. ハード・ディスクのグリッド・ディスクに関連するOracle ASMディスクが正しく削除されるまで待機します。グリッド・ディスクが削除されたかどうか判別するには、Oracle ASMインスタンスのV$ASM_DISK_STATビューの問合せを実行します。

    注意:

    Oracle Exadata Database Machine X7より前のすべてのシステムで、最初の2つのスロットのディスクは、オペレーティング・システムおよびOracle Exadata System Softwareを格納するシステム・ディスクになります。1つのシステム・ディスクを稼働して、サーバーを維持する必要があります。

    他のシステム・ディスクを交換する前に、ALTER CELL VALIDATE CONFIGURATIONでmdadmエラーが表示されなくなり、システム・ディスクの再同期化が完了するまで待機します。

  4. Oracle Exadata Storage Server上のハード・ディスクを交換し、3分待ちます。ハード・ディスクはホットプラグ対応で、電源の投入時に交換できます。
  5. ディスクがオンラインであることを確認します。

    交換したハード・ディスクは、RAIDコントローラによって認識されるまで使用できません。この処理にあまり時間は要しません。LIST PHYSICALDISKコマンドを使用して、ステータスがNORMALであることを確認します。 

    CellCLI> LIST PHYSICALDISK WHERE name=28:3 ATTRIBUTES status
  6. ALTER CELL VALIDATE CONFIGURATIONコマンドを使用して、ファームウェアが正しいことを確認します。

関連項目:

親トピック: Oracle Exadata Storage Serverのハード・ディスクの保守

3.3.5 低いパフォーマンスによるハード・ディスクの交換

1つの不良ハード・ディスクが、他の正常なディスクのパフォーマンスを低下させることがあります。不良ディスクはそのままにしないでシステムから削除する必要があります。

Oracle Exadata System Softwareリリース11.2.3.2以降では、パフォーマンスの低いディスクが自動的に識別され、アクティブな構成から削除されます。その後、Oracle Exadata Database Machineにより一連のパフォーマンス・テストが実行されます。CELLSRVでパフォーマンスの低いディスクが検出されると、セル・ディスクのステータスが正常 - 制限されたオンラインに変更され、ハード・ディスクのステータスが警告 - 制限されたオンラインに変更されます。

次の状況はディスク制限のトリガーとなります。

  • ディスクの応答停止。ストレージ・アラート・ログ内の原因コードはCD_PERF_HANGです。

  • セル・ディスクの速度低下。次に例を示します。

    • サービス時間のしきい値が高い(原因コードCD_PERF_SLOW_ABS)

    • 相対的サービス時間のしきい値が高い(原因コードCD_PERF_SLOW_RLTV)

  • 読取りまたは書込みでの長期待機時間。次に例を示します。

    • 書込みでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_WT)

    • 読取りでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_RD)

    • 読取りおよび書込みでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_RW)

    • 頻繁に発生する個々のI/Oでの絶対的待機時間が非常に長い(原因コードCD_PERF_SLOW_LAT_ERR)

  • I/Oエラーなどのエラー(原因コードCD_PERF_IOERR)。

ディスクの問題が一時的なものであり、テストに合格した場合は、そのディスクは構成に戻されます。ディスクがテストに合格しない場合は、poor performanceとしてマークされ、Oracle Auto Service Request (ASR)によりディスク交換のためのサービス・リクエストが送信されます。可能な場合は、Oracle ASMによりグリッド・ディスクがテスト用にオフラインに変更されます。Oracle ASMがディスクをオフラインに変更できない場合、セル・ディスクのステータスは、ディスクを安全にオフラインに変更できるようになるまで、normal - confinedOnlineのまま変わりません。

ディスクのステータスの変更は、セルのアラート履歴にある次のエントリに関連付けられています。

MESSAGE ID date_time info "Hard disk entered confinement status. The LUN
 n_m changed status to warning - confinedOnline. CellDisk changed status to normal
 - confinedOnline. Status: WARNING - CONFINEDONLINE  Manufacturer: name  Model
 Number: model  Size: size  Serial Number: serial_number  Firmware: fw_release 
 Slot Number: m  Cell Disk: cell_disk_name  Grid Disk: grid disk 1, grid disk 2
 ... Reason for confinement: threshold for service time exceeded"

ストレージ・セルのアラート・ログには次の情報が記録されます。

CDHS: Mark cd health state change cell_disk_name  with newState HEALTH_BAD_
ONLINE pending HEALTH_BAD_ONLINE ongoing INVALID cur HEALTH_GOOD
Celldisk entering CONFINE ACTIVE state with cause CD_PERF_SLOW_ABS activeForced: 0
inactiveForced: 0 trigger HistoryFail: 0, forceTestOutcome: 0 testFail: 0
global conf related state: numHDsConf: 1 numFDsConf: 0 numHDsHung: 0 numFDsHung: 0
...

ノート:

Oracle Exadata System Softwareリリース11.2.3.2より前のリリースでは、CALIBRATEコマンドを使用して不良ハード・ディスクを識別し、各ハード・ディスクについてスループットやIOPSが極端に低くないか調べてください。

次の手順は、不良ディスクが確認された場合のハード・ディスクの取外し方法を示しています。

  1. 次のようなコマンドを使用してハード・ドライブのサービスLEDを点灯させ、交換対象のドライブを特定します。ここで、disk_nameは交換対象のハード・ディスクの名前です(20:2など)。
    cellcli -e 'alter physicaldisk disk_name serviceled on'
  2. 不良ディスクのすべてのグリッド・ディスクを確認します。

    次に例を示します。

    [root@exa05celadm03 ~]# cellcli -e "list physicaldisk 20:11 attributes name, id"
        20:11 RD58EA 
[root@exa05celadm03 ~]# cellcli -e "list celldisk where physicalDisk='RD58EA'"
        CD_11_exa05celadm03 normal 
[root@exa05celadm03 ~]# cellcli -e "list griddisk where cellDisk='CD_11_exa05celadm03'"
        DATA_CD_11_exa05celadm03 active
        DBFS_CD_11_exa05celadm03 active
        RECO_CD_11_exa05celadm03 active
        TPCH_CD_11_exa05celadm03 active
  3. Oracle ASMに不良ディスクの使用をただちに停止するよう指示します。
    SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name;
  4. ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。
  5. V$ASM_DISK_STATビューの問合せを実行して、不良ディスクのグリッド・ディスクに関連するOracle ASMディスクが正しく削除されたことを確認します。
  6. 不良ディスクを取り外します。ディスクを削除すると、アラートが送信されます。
  7. 新しいディスクを使用できる場合、システムに新しいディスクを設置します。セル・ディスクおよびグリッド・ディスクが新しいハード・ディスクに自動的に作成されます。

    ノート:

    交換したハード・ディスクは、RAIDコントローラによって認識されるまで使用できません。承認処理に時間はかかりませんが、LIST PHYSICALDISKコマンドを使用してステータスがNORMALであることを確認してください。

関連項目:

親トピック: Oracle Exadata Storage Serverのハード・ディスクの保守

3.3.6 ハード・ディスクの事前交換

Exadata Storageソフトウェアでは、ハード・ディスクで障害が発生したり、問題のあるディスクとしてフラグ付けされた場合に、自動化された一連の操作でディスクを保守できます。ただし、状況によっては、構成からハード・ディスクを事前に取り外すことが必要になります。

CellCLIのALTER PHYSICALDISKコマンドでは、DROP FOR REPLACEMENTオプションによって、データ損失のリスクなく安全に、正常に機能しているハード・ディスクを削除できるかどうかが確認されます。ただし、コマンドを実行した後、ストレージ・セルでハード・ディスクのグリッド・ディスクが非アクティブ化され、Oracle ASMディスク・グループでオフラインに設定されます。

ディスク・グループで十分な冗長性を確保できないリスクを抑えて、事前にハード・ディスクを交換するには、次の手順を実行します。

  1. ハード・ディスクに関連付けられたLUN、セル・ディスクおよびグリッド・ディスクを特定します。

    次のようなコマンドを使用します。ここで、X:Yは交換するドライブのハード・ディスク名を示します。 

    # cellcli –e "list diskmap" | grep 'X:Y'

    出力は次のようになります。

       20:5            KEBTDJ          5                       normal  559G           
    CD_05_exaceladm01    /dev/sdf                
    "DATAC1_CD_05_exaceladm01, DBFS_DG_CD_05_exaceladm01, 
     RECOC1_CD_05_exaceladm01"

    LUNを取得するには、次のようなコマンドを発行します。

    CellCLI> list lun where deviceName='/dev/sdf/'
         0_5     0_5     normal
  2. ディスクを削除します。

    • Oracle Exadata System Softwareリリース21.2.0以上を使用している場合は、次のコマンドを使用して、冗長性を維持しながら物理ディスクを削除します。 

      CellCLI> alter physicaldisk X:Y drop for replacement maintain redundancy

      操作が完了するまで待ってから続行します。

    • 21.2.0より前のOracle Exadata System Softwareリリースを使用している場合は、次の手順を実行します。

      1. 通常のモードで、影響を受けるグリッド・ディスクをOracle ASMディスク・グループから削除します。

        SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name;

      2. ASMリバランス操作が完了するまで待ってから続行します。

      3. 物理ディスクを削除します。

        次のようなコマンドを使用します。ここで、X:Yは交換するドライブのハード・ディスク名を示します。 

        CellCLI> alter physicaldisk X:Y drop for replacement
  3. ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認します。
  4. 新しいハード・ディスクに交換します。
  5. ハード・ディスクに関連付けられたLUN、セル・ディスクおよびグリッド・ディスクが作成されていることを確認します。
    CellCLI> list lun lun_name
CellCLI> list celldisk where lun=lun_name
CellCLI> list griddisk where celldisk=celldisk_name
  6. グリッド・ディスクがOracle ASMディスク・グループに追加されたことを確認します。

    次の問合せでは行が戻されません。

    SQL> SELECT path,header_status FROM v$asm_disk WHERE group_number=0;

    次の問合せでは、すべての障害グループのディスク数が同じかどうかが示されます。

    SQL> SELECT group_number, failgroup, mode_status, count(*) FROM v$asm_disk
     GROUP BY group_number, failgroup, mode_status;

親トピック: Oracle Exadata Storage Serverのハード・ディスクの保守

3.3.7 別のExadata Storage Serverへのすべてのドライブの移動

Exadata Storage Serverから別のExadata Storage Serverへのすべてのドライブの移動が必要になることがあります。

この作業が必要になるのは、マザーボードやILOM障害などのシャーシ・レベルのコンポーネント障害がある場合またはハードウェアの問題のトラブルシューティングを行う場合です。

  1. 次のディレクトリのファイルをバックアップします。

    • /etc/hosts

    • /etc/modprobe.conf

    • /etc/sysconfig/network

    • /etc/sysconfig/network-scripts

  2. すべてのグリッド・ディスクを安全に非アクティブにして、Exadata Storage Serverを停止します。

    Exadata Storage Serverのシャットダウンを参照してください。別のExadata Storage Serverでグリッド・ディスクをアクティブ化する前にOracle ASMによってディスクが削除されないように、Oracle ASMのdisk_repair_time属性に十分に大きい値が設定されていることを確認してください。

  3. ハード・ディスク、フラッシュ・ディスク、ディスク・コントローラおよびUSBフラッシュ・ドライブを元のExadata Storage Serverから新しいExadata Storage Serverに移動します。

    注意:

    • システム・ディスクの最初の2つのディスクが同じ最初の2つのスロットにあることを確認してください。そうしないと、Exadata Storage Serverが正常に機能しません。

    • フラッシュ・カードが元のExadata Storage Serverと同じPCIeスロットに設置されていることを確認してください。

  4. サービス・プロセッサ・インタフェースまたは電源ボタンを使用して、新しいExadata Storage Serverの電源を投入します。
  5. サービス・プロセッサまたはKVMスイッチを使用して、コンソールにログインします。
  6. 次のディレクトリのファイルを確認します。破損している場合、バックアップからリストアします。

    • /etc/hosts

    • /etc/modprobe.conf

    • /etc/sysconfig/network

    • /etc/sysconfig/network-scripts

  7. ifconfigコマンドを使用して、eth0、eth1、eth2およびeth3の新しいMACアドレスを取得します。次に例を示します。
    # ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:14:4F:CA:D9:AE
          inet addr:10.204.74.184  Bcast:10.204.75.255  Mask:255.255.252.0
          inet6 addr: fe80::214:4fff:feca:d9ae/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:141455 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6340 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9578692 (9.1 MiB)  TX bytes:1042156 (1017.7 KiB)
          Memory:f8c60000-f8c80000
  8. ステップ7の出力に基づいて、/etc/sysconfig/network-scriptsディレクトリのifcfg-eth0ファイル、ifcfg-eth1ファイル、ifcfg-eth2ファイルおよびifcfg-eth3ファイルを編集してHWADDR値を変更します。次に、ifcfg-eth0ファイルの例を示します。
    #### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.204.74.184
NETMASK=255.255.252.0
NETWORK=10.204.72.0
BROADCAST=10.204.75.255
GATEWAY=10.204.72.1
HOTPLUG=no
IPV6INIT=no
HWADDR=00:14:4F:CA:D9:AE
  9. Exadata Storage Serverを再起動します。
  10. 次のコマンドを使用して、グリッド・ディスクをアクティブ化します。
    CellCLI> ALTER GRIDDISK ALL ACTIVE

    セルのディスクのOracle ASMディスクが削除されなかった場合、それらのディスクは自動的にONLINEに変更され、使用が開始されます。

  11. 次のコマンドを使用して、構成を検証します。
    CellCLI> ALTER CELL VALIDATE CONFIGURATION
  12. ASRのILOMをアクティブ化します。

関連項目:

親トピック: Oracle Exadata Storage Serverのハード・ディスクの保守

3.3.8 ハード・ディスクの再利用

ディスクのすべてのデータを削除し、別の目的でディスクを使用できます。

ハード・ディスクを再利用する前に、ディスクのデータをコピーしてください。

システム・ディスク(ディスク0およびディスク1)に対してこの手順を使用した場合は、データ・パーティションのみが消去され、システム・パーティションは消去されません。

  1. CellCLIのLISTコマンドを使用して、Exadata Storage Serverオブジェクトを表示します。ハード・ドライブのグリッド・ディスクおよびセル・ディスクを確認する必要があります。次に例を示します。
    CellCLI> LIST PHYSICALDISK
         20:0   D174LX    normal
         20:1   D149R0    normal
         ...
  2. 次のようなコマンドを使用して、LUNのセル・ディスクおよびグリッド・ディスクを特定します。
    CellCLI> LIST LUN WHERE physicalDrives='20:0' DETAIL
  name:              0_0
  deviceName:        /dev/sda
  diskType:          HardDisk
  id:                0_0
  isSystemLun:       TRUE
  lunSize:           557.861328125G
  lunUID:            0_0
  physicalDrives:    20:0
  raidLevel:         0
  lunWriteCacheMode: "WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU"
  status:            normal

    セル・ディスクおよびグリッド・ディスクを取得するには、次のようなコマンドを使用します。

    #cellcli -e "list diskmap" | grep 20:0

   20:0            K68DWJ          0                       normal  559G
   CD_00_burd01celadm01    /dev/sda3   
   "DATAC1_CD_00_burd01celadm01, RECOC1_CD_00_burd01celadm01"
  3. Oracle ASMから次のコマンドを使用して、ハード・ディスクのOracle ASMディスクを削除します。
    SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name;
  4. Exadata Storage Serverから次のコマンドを使用して、ハード・ディスクのセル・ディスクおよびグリッド・ディスクを削除します。
    CellCLI> DROP CELLDISK celldisk_on_this_lun FORCE

    ノート:

    セル・ディスクのすべてのデータを上書きするには、DROP CELLDISKコマンドでERASEオプションを使用します。このコマンドの例を次に示します。 

    CellCLI> DROP CELLDISK CD_03_cell01 ERASE=1pass NOWAIT

CellDisk CD_03_cell01 erase is in progress
  5. ホット削除するドライブを削除します。次に例を示します。
    CellCli> ALTER PHYSICALDISK 20:0 DROP FOR REPLACEMENT
  6. ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。

    注意:

    ドライブを取り外す前に、ディスクの青色のLEDが点灯していることを確認します。青色のLEDが消灯している場合にドライブを取り外すと、システムがクラッシュする場合があるため、取り外さないでください。

  7. 再利用するディスクを取り外し、新しいディスクを挿入します。
  8. 新しいハード・ディスクがLUNとして追加されるまで待機します。
    CellCLI> LIST LUN

    セル・ディスクとグリッド・ディスクが新しいハード・ディスクに自動的に作成され、グリッド・ディスクがOracle ASMグループに追加されます。

関連トピック

親トピック: Oracle Exadata Storage Serverのハード・ディスクの保守

3.3.9 同じハード・ディスクの取外しおよび交換

誤って意図しないハード・ディスクを取り外した場合はどうなるでしょうか。

不注意で間違ったハード・ディスクを取り外した場合、ディスクを元に戻します。Oracle ASMディスク・グループに自動的に追加され、そのデータは再同期化されます。

ノート:

ディスク障害またはディスクの問題でディスクを交換すると、ディスク上でLEDが点灯し識別できます。

親トピック: Oracle Exadata Storage Serverのハード・ディスクの保守

3.3.10 拒否されたハード・ディスクの再有効化

不適切なスロットに挿入されたことが原因で物理ディスクが拒否された場合は、ディスクを再び有効にすることができます。

次のコマンドを実行します。

注意:

次のコマンドでは、物理ディスク上のデータをすべて削除します。

CellCLI> ALTER PHYSICALDISK hard_disk_name reenable force

次に、コマンドの出力例を示します。

Physical disk 20:0 was reenabled.

親トピック: Oracle Exadata Storage Serverのハード・ディスクの保守

3.4 Oracle Exadata Storage Serverのフラッシュ・ディスクの保守

データはExadataセル間でミラー化され、書込み操作が少なくとも2つのストレージ・セルに送信されます。Oracle Exadata Storage Serverのフラッシュ・カードに問題が発生すると、別のOracle Exadata Storage Serverのミラー化されたデータによって読取りおよび書込み操作が実行されます。アプリケーションでサービスの中断は発生しません。

ライトバック・モード時にフラッシュ・カードに障害が発生すると、Oracle Exadata System Softwareは、残存ミラーからデータを読み取ってフラッシュ・キャッシュ内のデータを確認します。次に、フラッシュ・カードに障害が発生したセルにデータが書き込まれます。障害が発生したフラッシュ・キャッシュ内での損失データの場所が、Oracle Exadata System Softwareによってフラッシュの障害発生時に保存されます。損失データをミラー・コピーに置き換えることにより、復元が開始されます。復元中、グリッド・ディスクのステータスはACTIVE -- RESILVERING WORKINGになります。PMEMキャッシュがライトスルー・モードになっている場合、障害が発生したPMEMデバイスのデータはデータ・グリッド・ディスクにすでに存在しているため、ミラー復元の必要はありません。

親トピック: Oracle Exadata Storage Serverの保守

3.4.1 フラッシュ・ディスク障害によるフラッシュ・ディスクの交換

Oracle Exadata Storage Serverには、それぞれフラッシュ・デバイスが付属しています。

Oracle Exadata Database Machine X7以降では、Oracle Exadata Storage Serverでフラッシュ・デバイスはホットプラグに対応しています。Oracle Exadata Storage Server X7以降でフラッシュ・デバイスのホットプラグ交換を実行する場合は、ディスク・ステータスが交換のため切断になり、かつフラッシュ・カードの電源LEDが消灯している必要があり、このことは、フラッシュ・ディスクのオンライン交換が可能であることを示します。

注意:

電源LEDが点灯しているカードを取り外すと、システムがクラッシュする可能性があります。障害が発生したディスクのステータスが障害 - 交換のため切断であるのに電源LEDがまだ点灯している場合は、Oracleサポート・サービスに連絡してください。

Oracle Exadata Database Machine X6以前の場合、フラッシュ・デバイスはExtreme Flash (EF)ストレージ・サーバーではホットプラグ対応ですが、High Capacity (HC)ストレージ・サーバーではホットプラグ対応ではありません。HCストレージ・サーバーでは、ストレージ・サーバーを交換する前に電源を切断する必要があります。

障害が発生したフラッシュ・ディスクを確認するには、次のコマンドを使用します。

CellCLI> LIST PHYSICALDISK WHERE disktype=flashdisk AND status=failed DETAIL

Extreme Flashストレージ・サーバーからの出力例を次に示します。


    name:                          NVME_10
    deviceName:                    /dev/nvme7n1
    diskType:                      FlashDisk
    luns:                          0_10
    makeModel:                     "Oracle NVMe SSD"
    physicalFirmware:              8DV1RA13
    physicalInsertTime:            2016-09-28T11:29:13-07:00
    physicalSerial:                CVMD426500E21P6LGN
    physicalSize:                  1.4554837569594383T
    slotNumber:                    10
    status:                        failed

次に、Oracle Flash Accelerator F160 PCIeカードからの出力例を示します。

CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS=failed DETAIL

         name:                   FLASH_5_1
         deviceName:             /dev/nvme1n1
         diskType:               FlashDisk
         luns:                   5_1
         makeModel:              "Oracle Flash Accelerator F160 PCIe Card"
         physicalFirmware:       8DV1RA13
         physicalInsertTime:     2016-11-30T21:24:45-08:00
         physicalSerial:         1030M03UYM
         physicalSize:           1.4554837569594383T
         slotNumber:             "PCI Slot: 5; FDOM: 1"
         status:                 failed

次に、Sun Flash Accelerator F40 PCIeカードからの出力例を示します。

         name:                   FLASH_5_3
         diskType:               FlashDisk
         luns:                   5_3
         makeModel:              "Sun Flash Accelerator F40 PCIe Card"
         physicalFirmware:       TI35
         physicalInsertTime:     2012-07-13T15:40:59-07:00
         physicalSerial:         5L002X4P
         physicalSize:           93.13225793838501G
         slotNumber:             "PCI Slot: 5; FDOM: 3"
         status:                 failed

PCIeカードの場合、nameおよびslotNumber属性は、PCIスロットおよびFDOM番号を示します。Extreme Flashストレージ・サーバーの場合、slotNumber属性は前面パネルのNVMeスロットを示します。

Oracle Exadata Database Machine X7以降のシステムでは、すべてのフラッシュ・ディスクがAdd-in-Card (AIC)方式でマザーボードのPCIeスロットに挿入されます。slotNumber属性は、EFストレージ・サーバーかHCストレージ・サーバーかを問わず、PCI番号およびFDOM番号を示します。

フラッシュ・ディスクの障害が検出されると、フラッシュ・ディスクとそのLUNで障害が発生したことを示すアラートが生成されます。アラート・メッセージには、PCIスロット番号とFDOM番号か、またはNVMeスロット番号が含まれています。これらの番号により、フィールド交換可能ユニット(FRU)が一意に識別されます。システムのアラート通知を構成している場合は、指定したアドレスにアラートが電子メール・メッセージで送信されます。

フラッシュ・ディスクの停止により、パフォーマンスの低下およびデータの冗長性が発生する場合があります。できるだけすぐに障害が発生したディスクを新しいフラッシュ・ディスクに交換する必要があります。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、ストレージ・サーバーの有効なキャッシュ・サイズが縮小します。フラッシュ・ログにフラッシュ・ディスクを使用する場合、ディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、FORCEオプションによってグリッド・ディスクに関連するOracle Automatic Storage Management (Oracle ASM)ディスクがOracle ASMディスク・グループから自動的に削除され、リバランス操作でデータの冗長性のリストアが開始されます。

次の手順は、フラッシュ・ディスクのオンライン交換をサポートしていないHigh Capacityストレージ・サーバーでディスク障害が発生した場合にFDOMを交換する方法を示しています。Extreme Flashストレージ・サーバーでのNVMeドライブの交換は、物理ディスクの交換と同様に、前面パネルからNVMeドライブを取り外して新しいものを挿入するのみです。ストレージ・サーバーを停止する必要はありません。

  1. ストレージ・サーバーを停止します。Exadata Storage Serverのシャットダウンを参照してください
  2. PCI番号およびFDOM番号に基づいて、障害が発生したフラッシュ・ディスクを交換します。白色のロケータLEDが点灯し、影響を受けているストレージ・サーバーを特定できます。
  3. ストレージ・サーバーの電源を投入します。セル・サービスが自動的に開始されます。ストレージ・サーバーの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にONLINEになります。
  4. 次のコマンドを使用して、すべてのグリッド・ディスクが正常にオンラインになったことを確認します。
    CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus
         data_CD_00_testceladm10     ONLINE
         data_CD_01_testceladm10     ONLINE
         data_CD_02_testceladm10     ONLINE
         ...

    すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。

新しいフラッシュ・ディスクがシステムによって自動的に使用されます。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、有効なキャッシュ・サイズが拡張します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクが新しいフラッシュ・ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

関連項目:

親トピック: Oracle Exadata Storage Serverのフラッシュ・ディスクの保守

3.4.2 フラッシュ・ディスクの低下したパフォーマンス・ステータスについて

フラッシュ・ディスクのパフォーマンスが低下している場合は、ディスクを交換する必要があることがあります。

ディスクが次のステータスのいすれかになるため、フラッシュ・ディスクの交換が必要な場合があります。

  • 警告 - 予測障害
  • 警告 - 低いパフォーマンス
  • 警告 - ライトスルー・キャッシュ
  • 警告 - ピア障害

ノート:

リリース11.2.3.2.2より前のOracle Exadata System Softwareリリースの場合、ステータスはnot presentです。

フラッシュ・ディスクがpredictive failure、poor performance、write-through cachingまたはpeer failureステータスの場合、アラートが生成されます。アラートには、フラッシュ・ディスクを交換する特定の手順が含まれます。システムのアラート通知を構成している場合、電子メール・メッセージでアラートが指定したアドレスに送信されます。

予測障害

フラッシュ・ディスクのpredictive failureステータスは、フラッシュ・ディスクに障害が発生する可能性があり、できるだけすぐに交換する必要があることを示します。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、引き続きフラッシュ・キャッシュとして使用されます。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクに関連するOracle ASMディスクが自動的に削除され、Oracle ASMリバランスで障害が発生する可能性のあるディスクから他のディスクにデータが移動されます。

フラッシュ・ディスクが1つのため、フラッシュ・ディスクがpredictive failureになると、データがコピーされます。グリッド・ディスクにフラッシュ・ディスクを使用する場合、Oracle ASMと関連パートナが再びパートナになり、リバランスが実行されます。ライトバック・フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、フラッシュ・ディスクからグリッド・ディスクにデータがフラッシュされます。

predictive failureのフラッシュ・ディスクを確認するには、次のコマンドを使用します。 

CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS=  \
'warning - predictive failure' DETAIL

         name:               FLASH_1_1
         deviceName:         /dev/nvme3n1
         diskType:           FlashDisk
         luns:               1_1
         makeModel:          "Oracle Flash Accelerator F160 PCIe Card"
         physicalFirmware:   8DV1RA13
         physicalInsertTime: 2016-11-30T21:24:45-08:00
         physicalSerial:     CVMD519000251P6KGN
         physicalSize:       1.4554837569594383T
         slotNumber:         "PCI Slot: 1; FDOM: 1"
         status:             warning - predictive failure

低いパフォーマンス

フラッシュ・ディスクのpoor performanceステータスは、フラッシュ・ディスクのパフォーマンスが非常に低く、できるだけすぐに交換する必要があることを示します。Oracle Exadata System Softwareリリース11.2.3.2以降では、パフォーマンスの低いディスクが自動的に識別され、アクティブな構成から削除されます。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクからフラッシュ・キャッシュが削除され、ストレージ・サーバーの有効なフラッシュ・キャッシュ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、このフラッシュ・ディスクのグリッド・ディスクに関連するOracle ASMディスクがFORCEオプションによって可能な場合に自動的に削除されます。オフライン・パートナのためにDROP...FORCEが失敗した場合、通常グリッド・ディスクが自動的に削除され、Oracle ASMリバランスでパフォーマンスの低いディスクから他のディスクにデータが移動されます。

その後、Oracle Exadata Database Machineにより一連のパフォーマンス・テストが実行されます。CELLSRVでパフォーマンスの低いディスクが検出されると、セル・ディスクのステータスがnormal - confinedOnlineに変更され、物理ディスクのステータスがwarning - confinedOnlineに変更されます。次の状況はディスク制限のトリガーとなります。

  • ディスクの応答停止。ストレージ・アラート・ログ内の原因コードはCD_PERF_HANGです。
  • セル・ディスクの速度低下。次に例を示します。
    • サービス時間のしきい値が高い(原因コードCD_PERF_SLOW_ABS)
    • 相対的サービス時間のしきい値が高い(原因コードCD_PERF_SLOW_RLTV)
  • 読取りまたは書込みでの長期待機時間。次に例を示します。
    • 書込みでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_WT)
    • 読取りでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_RD)
    • 読取りおよび書込みでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_RW)
    • 頻繁に発生する個々のI/Oでの絶対的待機時間が非常に長い(原因コードCD_PERF_SLOW_LAT_ERR)
  • I/Oエラーなどのエラー(原因コードCD_PERF_IOERR)。

ディスクの問題が一時的なものであり、テストに合格した場合は、そのディスクは構成に戻されます。ディスクがテストに合格しない場合は、poor performanceとしてマークされ、Oracle Auto Service Request (ASR)によりディスク交換のためのサービス・リクエストが送信されます。可能な場合は、Oracle ASMによりグリッド・ディスクがテスト用にオフラインに変更されます。Oracle ASMがディスクをオフラインに変更できない場合、セル・ディスクのステータスは、ディスクを安全にオフラインに変更できるようになるまで、normal - confinedOnlineのまま変わりません。

poor performanceのフラッシュ・ディスクを確認するには、次のコマンドを使用します。 

CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS= \
'warning - poor performance' DETAIL

         name:                FLASH_1_4
         diskType:            FlashDisk
         luns:                1_4
         makeModel:           "Sun Flash Accelerator F20 PCIe Card"
         physicalFirmware:    D20Y
         physicalInsertTime:  2012-09-27T13:11:16-07:00
         physicalSerial:      508002000092e70FMOD2
         physicalSize:        22.8880615234375G
         slotNumber:          "PCI Slot: 1; FDOM: 3"
         status:              warning - poor performance

ディスクのステータスの変更は、セルのアラート履歴にある次のエントリに関連付けられています。

MESSAGE ID date_time info "Hard disk entered confinement status. The LUN
 n_m changed status to warning - confinedOnline. CellDisk changed status to normal
 - confinedOnline. Status: WARNING - CONFINEDONLINE  Manufacturer: name  Model
 Number: model  Size: size  Serial Number: serial_number  Firmware: fw_release 
 Slot Number: m  Cell Disk: cell_disk_name  Grid Disk: grid disk 1, grid disk 2
 ... Reason for confinement: threshold for service time exceeded"

ストレージ・サーバーのアラート・ログには次の情報が記録されます。

CDHS: Mark cd health state change cell_disk_name  with newState HEALTH_BAD_
ONLINE pending HEALTH_BAD_ONLINE ongoing INVALID cur HEALTH_GOOD
Celldisk entering CONFINE ACTIVE state with cause CD_PERF_SLOW_ABS activeForced: 0
inactiveForced: 0 trigger HistoryFail: 0, forceTestOutcome: 0 testFail: 0
global conf related state: numHDsConf: 1 numFDsConf: 0 numHDsHung: 0 numFDsHung: 0
...

ノート:

11.2.3.2より前のOracle Exadata System Softwareリリースでは、CALIBRATEコマンドを使用して不良フラッシュ・ディスクを識別し、各フラッシュ・ディスクについてスループットやIOPSが極端に低くないか調べてください。

フラッシュ・ディスクのパフォーマンスが非常に低い場合、poor performanceとしてマークされます。該当するフラッシュ・ディスクのフラッシュ・キャッシュが自動的に無効になり、そのフラッシュ・ディスクのグリッド・ディスクがOracle ASMディスク・グループから自動的に削除されます。

ライトスルー・キャッシュ

フラッシュ・ディスクのwrite-through cachingステータスは、PCIeカードのデータ・キャッシュのサポートに使用するキャパシタに障害が発生したため、できるだけすぐにカードを交換する必要があることを示します。

peer failure

フラッシュ・ディスクのpeer failureステータスは、同じSun Flash Accelerator PCIeカードのいずれかのフラッシュ・ディスクに障害または問題が発生したことを示します。たとえば、FLASH_5_3に障害が発生すると、FLASH_5_0、FLASH_5_1およびFLASH_5_2がpeer failureステータスになります。次に、例を示します。 

CellCLI> LIST PHYSICALDISK
         36:0            L45F3A          normal
         36:1            L45WAE          normal
         36:2            L45WQW          normal
...
         FLASH_5_0       5L0034XM        warning - peer failure
         FLASH_5_1       5L0034JE        warning - peer failure
         FLASH_5_2       5L002WJH        warning - peer failure
         FLASH_5_3       5L002X4P        failed

CellSRVにより、ライトバック・フラッシュ・キャッシュに使用されているフラッシュ・ディスクで予測障害またはピア障害が検出され、不良FDOMが1つのみの場合は、その不良FDOMのデータが復元され、残りの3つのFDOMのデータはフラッシュされます。その後、有効なグリッド・ディスクが存在する場合、CellSRVはディスクに対してOracle ASMリバランスを開始します。不良ディスクは、タスクが完了するまで交換できません。ディスク交換が可能になると、MSによりアラートが送信されます。

親トピック: Oracle Exadata Storage Serverのフラッシュ・ディスクの保守

3.4.3 フラッシュ・ディスクの問題によるフラッシュ・ディスクの交換

Oracle Exadata Storage Serverには、4枚のPCIeカードが付属しています。各カードに4個のフラッシュ・ディスク(FDOM)があり、合計16個のフラッシュ・ディスクが提供されます。4枚のPCIeカードは、PCIスロット番号1、2、4および5にあります。Oracle Exadata Database Machine X7以上では、ストレージ・サーバーの電源を切断しなくてもPCIeカードを交換できます。フラッシュ・ディスクのホットプラグ交換の実行を参照してください。

Oracle Exadata Database Machine X6以前のシステムでは、PCIeカードはホットプラグに対応していません。フラッシュ・ディスクまたはカードを交換する前にOracle Exadata Storage Serverの電源を切断する必要があります。

Oracle Exadata Database Machine X7以降では、High Capacityストレージ・サーバーおよびExtreme Flashストレージ・サーバーの各フラッシュ・カードは、フィールド交換可能ユニット(FRU)です。フラッシュ・カードはホットプラグにも対応しており、ストレージ・サーバーを停止しなくても取り外すことができます。

Oracle Exadata Database Machine X5およびX6システムでは、High Capacity上の各フラッシュ・カードおよびExtreme Flash上の各フラッシュ・ドライブはFRUです。これは、これらのシステムにはピア障害がないことを意味します。

Oracle Exadata Database Machine X3およびX4システムでは、フラッシュ・カード自体がFRUであるため、FDOMで障害が発生した場合、Oracle Exadata System Softwareは、そのカードの残りのFDOMを自動的にピア障害の状態にして、フラッシュ・カード交換の準備のためにデータを移動できるようにします。

Oracle Exadata Database Machine V2およびX2システムでは、各FDOMはFRUです。これらのシステムのフラッシュにはピア障害がありません。

ディスク交換にいつ進むかの決定は、次に示されているように、リリースによって異なります。

  • Oracle Exadata System Softwareリリース11.2.3.2より前の場合:

    フラッシュ・ディスクの交換に進む前に、V$ASM_DISK_STATビューの問合せを実行してOracle ASMディスクが正常に削除されるまで待機します。フラッシュ・ディスクで障害が発生する前に通常の削除を完了できなかった場合、FORCEオプションによってOracle ASMディスク・グループからOracle ASMディスクが自動的に削除されます。フラッシュ・ディスクで障害が発生する前にDROPコマンドが完了しなかった場合は、「フラッシュ・ディスク障害によるフラッシュ・ディスクの交換」を参照してください。

  • Oracle Exadata System Softwareリリース11.2.3.2以降の場合:

    Oracle ASMディスクが削除されている場合は、アラートが送信され、フラッシュ・ディスクを安全に交換できます。フラッシュ・ディスクをライトバック・フラッシュ・キャッシュに使用する場合、フラッシュ・ディスクによってキャッシュされるグリッド・ディスクがなくなるまで待機します。すべてのグリッド・ディスクのcachedBy属性をチェックするには、次のコマンドを使用します。フラッシュ・ディスクのセル・ディスクは、グリッド・ディスクのcachedBy属性には表示されません。 

    CellCLI> LIST GRIDDISK ATTRIBUTES name, cachedBy

    フラッシュ・ディスクをグリッド・ディスクとフラッシュ・キャッシュの両方に使用する場合は、アラートを受信し、セル・ディスクがグリッド・ディスクのcachedBy属性に表示されなくなるまで待機します。

次の手順では、ディスクの問題により、Oracle Exadata Database Machine X6以前のHigh Capacityストレージ・サーバーのフラッシュ・ディスクを交換する方法について説明します。

ノート:

Oracle Exadata Database Machine X6のExtreme Flashストレージ・サーバーおよびOracle Exadata Database Machine X7以降のすべてのストレージ・サーバーでは、前面パネルからフラッシュ・ディスクを取り外し、新しいフラッシュ・ディスクを挿入するだけです。ストレージ・サーバーを停止する必要はありません。
  1. 次のコマンドを使用して、セル・サービスを停止します。
    CellCLI> ALTER CELL SHUTDOWN SERVICES ALL

    前述のコマンドでは、オフラインのディスクがないか、predictive failureステータスのディスクがないか、またはミラーにコピーする必要があるディスクがないかをチェックします。Oracle ASM冗長性が損なわれていない場合は、コマンドによりOracle ASMでグリッド・ディスクがオフラインに変更され、セル・サービスが停止されます。次のエラーが表示された場合は、冗長性が原因でディスク・グループが強制的にディスマウントされ、セル・サービスを安全に停止できない可能性があります。 

    Stopping the RS, CELLSRV, and MS services...
The SHUTDOWN of ALL services was not successful.
CELL-01548: Unable to shut down CELLSRV because disk group DATA, RECO may be
forced to dismount due to reduced redundancy.
Getting the state of CELLSRV services... running
Getting the state of MS services... running
Getting the state of RS services... running

    エラーが発生した場合は、Oracle ASMディスク・グループの冗長性をリストアし、すべてのディスクのディスク・ステータスが正常に戻ってからコマンドを再試行してください。

  2. ストレージ・サーバーを停止します。
  3. PCI番号およびFDOM番号に基づいて、障害が発生したフラッシュ・ディスクを交換します。白色のロケータLEDが点灯し、影響を受けているストレージ・サーバーを特定できます。
  4. ストレージ・サーバーの電源を投入します。セル・サービスが自動的に開始されます。ストレージ・サーバーの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にONLINEになります。
  5. 次のコマンドを使用して、すべてのグリッド・ディスクが正常にオンラインになったことを確認します。
    CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus

    すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。

新しいフラッシュ・ディスクがシステムによって自動的に使用されます。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、有効なキャッシュ・サイズが拡張します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクが新しいフラッシュ・ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

関連トピック

関連項目:

親トピック: Oracle Exadata Storage Serverのフラッシュ・ディスクの保守

3.4.4 フラッシュ・ディスクのホットプラグ交換の実行

Oracle Exadata Database Machine X7以上では、フラッシュ・ディスクはExtreme Flash (EF)ストレージ・サーバーとHigh Capacity (HC)ストレージ・サーバーの両方でホットプラグに対応しています。

また、Oracle Exadata Database Machine X6以前の場合、EFストレージ・サーバーのフラッシュ・デバイスはホットプラグ対応です。ただし、Oracle Exadata Database Machine X6以前のシステムのHCストレージ・サーバーの場合、フラッシュ・ディスクを交換する前にストレージ・サーバーの電源を切断する必要があります。

ホットプラグ対応のフラッシュ・ディスク・デバイスを交換するには:

  1. 必要に応じて、ホットプラグ交換のためにディスクを準備します。

    通常は、Oracle Exadata System Softwareで問題が特定され、フラッシュ・ディスクのオンライン交換が可能であることを示す障害 - 交換のため切断にデバイスのステータスが設定された後にのみ、フラッシュ・ドライブを交換します。

    別の状態のフラッシュ・ディスクを交換する必要がある場合は、まず、CellCLIのALTER PHYSICALDISKコマンドをDROP FOR REPLACEMENT句とともに使用して、ホットプラグ交換のためにディスクを準備する必要があります。

  2. フラッシュ・ディスクでホットプラグ交換の準備ができていることを確認します。

    デバイスのステータスが障害 - 交換のため切断であることを確認します。

    CellCLIのLIST PHYSICALDISKコマンドを使用して、デバイスのステータスを確認できます。次に例を示します。 

    CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS LIKE '.*dropped 
for replacement.*' DETAIL

         name:               FLASH_6_1
         deviceName:         /dev/nvme0n1
         diskType:           FlashDisk
         luns:               6_0
         makeModel:          "Oracle Flash Accelerator F640 PCIe Card"
         physicalFirmware:   QDV1RD09
         physicalInsertTime: 2017-08-11T12:25:00-07:00
         physicalSerial:     PHLE6514003R6P4BGN-1
         physicalSize:       2.910957656800747T
         slotNumber:         "PCI Slot: 6; FDOM: 1"
         status:             failed - dropped for replacement

    FDOMが1つ失敗すると、影響を受けるフラッシュ・ディスクのPCIカードに障害が発生したと見なされ、カード全体を交換する必要があることに注意してください。

  3. フラッシュ・ディスク・デバイスを物理的に見つけます。

    CellCLIのLIST PHYSICALDISKコマンドの出力のslotNumber情報を使用すると、影響を受けるフラッシュ・デバイスを含むPCIスロットを識別しやすくなります。

    また、白色のロケータLEDが点灯し、影響を受けているストレージ・サーバーを特定できます。黄色の障害サービス必須LEDが点灯し、影響を受けるフラッシュ・デバイスを特定できます。

  4. フラッシュ・ディスクの電源LEDが消灯していることを確認します。

    注意:

    電源LEDが点灯しているときにフラッシュ・デバイスを取り外すと、システムがクラッシュする可能性があります。ステータスが障害 - 交換のため切断であるのに電源LEDがまだ点灯している場合は、Oracleサポート・サービスに連絡してください。
  5. フラッシュ・ディスク・デバイスを取り外して交換します。

関連トピック

親トピック: Oracle Exadata Storage Serverのフラッシュ・ディスクの保守

3.4.5 ライトバック・フラッシュ・キャッシュの有効化

ディスクではなくフラッシュによって処理される書込み操作は、ライトバック・フラッシュ・キャッシュと呼ばれます。

Oracle Exadata System Softwareリリース11.2.3.2.1以上では、Exadataスマート・フラッシュ・キャッシュにより、頻繁にアクセスするデータを高速のソリッド状態の記憶装置に透過的にキャッシュして、問合せの応答時間とスループットを向上させることができます。

親トピック: Oracle Exadata Storage Serverのフラッシュ・ディスクの保守

3.4.5.1 11.2.3.3.1以上でのライトバック・フラッシュ・キャッシュの有効化

ストレージ・サーバーのライトバック・フラッシュ・キャッシュを有効にして、問合せの応答時間とスループットを向上させます。

Oracle Exadata System Softwareリリース11.2.3.3.1以降では、フラッシュ・キャッシュをライトスルー・モードからライトバック・モードに変更するときに、セル・サービスを停止したり、グリッド・ディスクを非アクティブ化する必要はありません。

ノート:

フラッシュ・キャッシュを削除して再作成すると、データベース操作のパフォーマンスに影響します。フラッシュ・キャッシュが再移入される間に、データベース・パフォーマンスに影響するキャッシュ・ミスがあります。
  1. Exadataスマート・フラッシュ・キャッシュを変更する前に、すべての物理ディスクが正常な状態であることを検証します。

    次のコマンドでは行が戻されません。

    # dcli –l root –g cell_group cellcli –e “list physicaldisk attributes name,status”|grep –v NORMAL
  2. フラッシュ・キャッシュを削除します。
    # dcli –l root –g cell_group cellcli -e drop flashcache
  3. flashCacheMode属性をwritebackに設定します。
    # dcli –l root – g cell_group cellcli -e "alter cell flashCacheMode=writeback"
  4. フラッシュ・キャッシュを再作成します。
    # dcli –l root –g cell_group cellcli -e create flashcache all
  5. flashCacheModeがwritebackに設定されていることを確認します。
    # dcli –l root –g cell_group cellcli -e list cell detail | grep flashCacheMode
  6. グリッド・ディスク属性のcachingPolicyとcachedbyを検証します。
    # cellcli –e list griddisk attributes name,cachingpolicy,cachedby
3.4.5.2 11.2.3.3.1より前のソフトウェア・バージョンのローリング形式でのライトバック・フラッシュ・キャッシュの有効化

ライトバック・フラッシュ・キャッシュは、ローリング形式で有効化できます。

フラッシュ・キャッシュの属性をwritethroughからwritebackに変更するには、まず、そのフラッシュ・キャッシュを削除しておく必要があります。11.2.3.3.1より前のリリースのOracle Exadata System Softwareでは、ライトバック・フラッシュ・キャッシュを有効にするときに、セル・サービスを停止するか、グリッド・ディスクを非アクティブ化する必要があります。

ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。

ノート:

フラッシュ・キャッシュを削除して再作成すると、データベース操作のパフォーマンスに影響します。フラッシュ・キャッシュが再移入される間に、データベース・パフォーマンスに影響するキャッシュ・ミスがあります。

ライトバック・フラッシュ・キャッシュを使用するには、Oracle Grid InfrastructureホームおよびOracle Databaseホームをリリース11.2.0.3 BP9以上にする必要があります。Oracle Exadata System Software、Oracle Grid InfrastructureホームおよびOracle Databaseホームの最小リリース要件は、My Oracle Supportノート888828.1を参照してください。

  1. ライトバック・フラッシュ・キャッシュを有効にする最初のセルにrootユーザーとしてログインします。
  2. フラッシュ・キャッシュが正常であり、どのフラッシュ・ディスクにも機能低下やクリティカル状態が発生していないことを確認します。
    # cellcli -e LIST FLASHCACHE detail
  3. セルのフラッシュ・キャッシュを削除します。
    # cellcli -e DROP FLASHCACHE
  4. セルのグリッド・ディスクを非アクティブ化します。
    # cellcli -e ALTER GRIDDISK ALL INACTIVE
  5. CELLSRVサービスを停止します。
    # cellcli -e ALTER CELL SHUTDOWN SERVICES CELLSRV
  6. flashCacheMode属性をwritebackに設定します。
    # cellcli -e "ALTER CELL FLASHCACHEMODE=writeback"
  7. セル・サービスを再起動します。
    # cellcli -e ALTER CELL STARTUP SERVICES CELLSRV
  8. セルのグリッド・ディスクを再アクティブ化します。
    # cellcli -e ALTER GRIDDISK ALL ACTIVE
  9. フラッシュ・キャッシュを再作成します。
    # cellcli -e CREATE FLASHCACHE ALL
  10. セルのステータスを確認します。
    # cellcli -e LIST CELL DETAIL | grep flashCacheMode

    flashCacheMode属性がwritebackに設定されている必要があります。

  11. 次のセルに移る前に、次のコマンドを使用して、グリッド・ディスクのasmDeactivationOutcome属性とasmModeStatus属性をチェックします。
    CellCLI> LIST GRIDDISK ATTRIBUTES name,asmdeactivationoutcome,asmmodestatus

    asmDeactivationOutcome属性がyesに、asmModeStatus属性がonlineになっている必要があります。

  12. 次のセルに対して前述のステップを繰り返します。
3.4.5.3 11.2.3.3.1より前のソフトウェア・バージョンの非ローリング形式でのライトバック・フラッシュ・キャッシュの有効化

ライトバック・フラッシュ・キャッシュは、非ローリング形式で有効化できます。

flashCacheMode属性を変更する前に、セル・サービスをシャットダウンする必要があります。11.2.3.3.1より前のリリースのOracle Exadata System Softwareでは、非ローリング形式でライトバック・フラッシュ・キャッシュを無効にするときに、セル・サービスを停止する必要があります。

ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。

ライトバック・フラッシュ・キャッシュを使用するには、Oracle Grid InfrastructureホームおよびOracle Databaseホームをリリース11.2.0.3 BP9以上にする必要があります。Oracle Exadata System Software、Oracle Grid InfrastructureホームおよびOracle Databaseホームの最小リリース要件は、My Oracle Supportノート888828.1を参照してください。

  1. データベース・ノードにrootユーザーとしてログインします。
  2. クラスタ全体を停止します。
    # cd $Grid_home/bin
# ./crsctl stop cluster -all
  3. すべてのセルのフラッシュ・キャッシュを削除します。
    # dcli -g cell_group -l root cellcli -e DROP FLASHCACHE
  4. CELLSRVサービスを停止します。
    # dcli -g cell_group -l root cellcli -e ALTER CELL SHUTDOWN SERVICES CELLSRV
  5. フラッシュ・キャッシュがwritethroughモードに設定されていることを確認します。
    # dcli -g cell_group -l root "cellcli -e list cell detail | grep -i flashcachemode"
  6. flashCacheMode属性をwritebackに設定します。
    # dcli -g cell_group -l root cellcli -e "ALTER CELL FLASHCACHEMODE=writeback"
  7. セル・サービスを再起動します。
    # dcli -g cell_group -l root cellcli -e ALTER CELL STARTUP SERVICES CELLSRV
  8. フラッシュ・キャッシュを再作成します。
    # dcli -g cell_group -l root cellcli -e CREATE FLASHCACHE ALL
  9. クラスタを再起動します。
    # cd $Grid_home/bin
# ./crsctl start cluster -all

3.4.6 ライトバック・フラッシュ・キャッシュの無効化

ライトスルー・フラッシュ・キャッシュを有効にして、ライトバック・フラッシュ・キャッシュを無効化できます。

Oracle Exadata System Softwareリリース11.2.3.2.1以降では、Exadataスマート・フラッシュ・キャッシュにより、頻繁にアクセスするデータが高速のソリッドステート記憶装置に透過的にキャッシュされ、問合せの応答時間とスループットを向上させることができます。

ディスクではなくフラッシュによって処理される書込み操作は、「ライトバック・フラッシュ・キャッシュ」と呼ばれます。

親トピック: Oracle Exadata Storage Serverのフラッシュ・ディスクの保守

3.4.6.1 Exadata X8M以降のサーバーでのライトバック・フラッシュ・キャッシュの無効化

PMEMキャッシュを含むExadata Database Machine X8M以降のシステムで、PMEMキャッシュがライトバックモードの場合に、フラッシュ・キャッシュ・モードをライトバックからライトスルーに変更するには、最初にPMEMキャッシュを変更する必要があります。

ノート:

アプリケーションのパフォーマンスへの影響を抑えるには、ワークロードが低い期間にライトバック・フラッシュ・キャッシュを無効化します。
  1. PMEMキャッシュを含むX8M以降のシステムで、PMEMキャッシュがライトバック・モードの場合:
    1. PMEMキャッシュをフラッシュします。

      PMEMキャッシュが、すべての使用可能なPMEMセル・ディスクを使用する場合は、次に示すようにALLキーワードを使用できます。 

      # dcli –l root –g cell_group cellcli ALTER PMEMCACHE ALL FLUSH

      それ以外の場合は、CELLDISK="cdisk1 [,cdisk2] ..."句を使用して特定のディスクをリストします。

    2. PMEMキャッシュを削除します。
      # dcli –l root –g cell_group cellcli DROP PMEMCACHE
    3. ライトスルー・モードを使用するようにPMEMキャッシュを変更します。
      # dcli –l root –g cell_group cellcli ALTER CELL pmemCacheMode=WriteThrough
    4. PMEMキャッシュを再作成します。

      PMEMキャッシュが、すべての使用可能なPMEMセル・ディスクを使用する場合は、次に示すようにALLキーワードを使用できます。それ以外の場合は、CELLDISK="cdisk1 [,cdisk2] ..."句を使用して特定のディスクをリストします。size属性が指定されていない場合は、最大サイズが割り当てられます。リスト内の各セル・ディスクの使用可能なすべての領域が、PMEMキャッシュに使用されます。 

      # dcli –l root –g cell_group cellcli -e CREATE PMEMCACHE ALL
    5. pmemCacheModeがwritethroughに設定されていることを確認します。
      # dcli –l root –g cell_group cellcli -e list cell detail | grep pmemCacheMode
  2. フラッシュ・キャッシュを変更する前に、すべての物理ディスクがNORMAL状態であることを検証します。
    # dcli –l root –g cell_group cellcli –e “LIST PHYSICALDISK ATTRIBUTES name,status”
|grep –v NORMAL
    コマンドでは行が戻されません。
  3. フラッシュ・キャッシュ内のダーティ・データの量を確認します。
    # cellcli -e "LIST METRICCURRENT ATTRIBUTES name,metricvalue WHERE
 name LIKE \'FC_BY_DIRTY.*\' "
  4. フラッシュ・キャッシュをフラッシュします。

    フラッシュ・キャッシュが、すべての使用可能なフラッシュ・セル・ディスクを使用する場合は、フラッシュ・ディスクをリストするかわりにALLキーワードを使用できます。 

    # dcli –g cell_group –l root cellcli -e "ALTER FLASHCACHE CELLDISK=\'FD_02_dm01celadm12,
FD_03_dm01celadm12,FD_00_dm01celadm12,FD_01_dm01celadm12\' FLUSH"
  5. フラッシュ・キャッシュのフラッシュの進捗状況をチェックします。

    FC_BY_DIRTYが0MBになると、フラッシュ・プロセスは完了します。

    # dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT ATTRIBUTES name,metricvalue
 WHERE name LIKE \'FC_BY_DIRTY.*\' "

    属性flushstatusがCompletedに設定されたかどうかを確認することもできます。 

    # dcli -g cell_group -l root cellcli -e "LIST CELLDISK ATTRIBUTES name, flushstatus, 
flusherror" | grep FD
  6. フラッシュ・キャッシュのフラッシュが完了した後、フラッシュ・キャッシュを削除します。
    # dcli -g cell_group -l root cellcli -e drop flashcache
  7. ライトスルー・モードを使用するようにフラッシュ・キャッシュを変更します。
    # dcli -g cell_group -l root cellcli -e "ALTER CELL flashCacheMode=writethrough"
  8. フラッシュ・キャッシュを再作成します。

    フラッシュ・キャッシュが、すべての使用可能なフラッシュ・セル・ディスクを使用する場合は、セル・ディスクをリストするかわりにALLキーワードを使用できます。

    size属性を含めない場合、リスト内の各セル・ディスク上の使用可能なすべての領域が、Exadataスマート・フラッシュ・キャッシュに使用されます。 

    # dcli –l root –g cell_group cellcli -e "create flashcache celldisk=\'FD_02_dm01celadm12,
FD_03_dm01celadm12,FD_00_dm01celadm12,FD_01_dm01celadm12\'
  9. flashCacheModeがwritethroughに設定されていることを確認します。
    # dcli –l root –g cell_group cellcli -e list cell detail | grep flashCacheMode
3.4.6.2 11.2.3.3.1以上でのライトバック・フラッシュ・キャッシュの無効化

モードをライトスルーに変更することで、ストレージ・サーバーのライトバック・フラッシュ・キャッシュを無効化できます。

リリース11.2.3.3.1以上では、CELLSRVプロセスを停止する必要も、グリッド・ディスクを非アクティブ化する必要もありません。

ノート:

アプリケーションのパフォーマンスへの影響を抑えるには、ワークロードが低い期間にライトバック・フラッシュ・キャッシュを無効化します。
  1. フラッシュ・キャッシュを変更する前に、すべての物理ディスクが正常な状態であることを検証します。

    次のコマンドでは行が戻されません。

    # dcli –l root –g cell_group cellcli –e “LIST PHYSICALDISK ATTRIBUTES name,status”|grep –v NORMAL
  2. フラッシュ・キャッシュ内のダーティ・データの量を確認します。
    # cellcli -e "LIST METRICCURRENT ATTRIBUTES name,metricvalue WHERE name LIKE \'FC_BY_DIRTY.*\' "
  3. フラッシュ・キャッシュをフラッシュします。
    # dcli –g cell_group –l root cellcli -e "ALTER FLASHCACHE ALL FLUSH"
  4. フラッシュ・キャッシュのフラッシュの進捗状況をチェックします。

    FC_BY_DIRTYが0MBになると、フラッシュ・プロセスは完了します。

    # dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT ATTRIBUTES name,metricvalue WHERE name LIKE \'FC_BY_DIRTY.*\' "

    属性flushstatusがCompletedに設定されたかどうかを確認することもできます。 

    # dcli -g cell_group -l root cellcli -e "LIST CELLDISK ATTRIBUTES name, flushstatus, flusherror" | grep FD
  5. フラッシュ・キャッシュのフラッシュが完了した後、フラッシュ・キャッシュを削除します。
    # dcli -g cell_group -l root cellcli -e drop flashcache
  6. flashCacheMode属性をwritethroughに設定します。
    # dcli -g cell_group -l root cellcli -e "ALTER CELL flashCacheMode=writethrough"
  7. フラッシュ・キャッシュを再作成します。
    # dcli –l root –g cell_group cellcli -e create flashcache all
  8. flashCacheModeがwritethroughに設定されていることを確認します。
    # dcli –l root –g cell_group cellcli -e list cell detail | grep flashCacheMode
3.4.6.3 11.2.3.3.1より前のソフトウェア・バージョンのローリング形式でのライトバック・フラッシュ・キャッシュの無効化

ローリング方式を使用して、各ストレージ・サーバーのライトバック・フラッシュ・キャッシュを有効化できます。

flashCacheMode属性を変更する前に、セル・サービスをシャットダウンする必要があります。セル・サービスは、ローリング形式でシャットダウンできます。属性をwritethroughに変更する前に、フラッシュ・キャッシュをフラッシュして削除する必要があります。フラッシュ操作が開始されると、フラッシュ・キャッシュへのすべてのキャッシュが停止されます。現在のストレージ・サーバーでセル・サービスの再同期化が完了してから、次のストレージ・サーバーを変更してください。

ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。

  1. ライトバック・フラッシュ・キャッシュを無効にする最初のセルにrootユーザーとしてログインします。
  2. セルのすべてのグリッド・ディスクのasmDeactivationOutcome属性がyesになっていることを確認します。
    # dcli -g cell_group -l root cellcli -e "LIST GRIDDISK WHERE   \
 asmdeactivationoutcome != 'Yes' attributes name, asmdeactivationoutcome, \
asmmodestatus"
    次のセルに移る前に、現在のセルのすべてのグリッド・ディスクでグリッド・ディスク属性asmDeactivationOutcome属性がyesに、asmModeStatus属性がonlineになっている必要があります。グリッド・ディスクのasmDeactivationOutcome属性値がyesでない場合は、続行する前に、この問題を解決する必要があります。
  3. フラッシュ・キャッシュ内のダーティ・データの量を確認します。
    # dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT ATTRIBUTES  \
name,metricvalue WHERE name LIKE \'FC_BY_DIRTY.*\'"
  4. フラッシュ・キャッシュをフラッシュします。
    # dcli -g cell_group -l root cellcli -e ALTER FLASHCACHE ALL FLUSH
  5. フラッシュ・キャッシュのステータスをチェックします。
    # dcli -g cell_group -l root cellcli -e LIST CELLDISK ATTRIBUTES name, \
flushstatus, flusherror | grep FD

    フラッシュが完了すると、ステータスがcompletedになります。

  6. 1セルずつ、すべてのセルに次の一連のステップを実行します。
    つまり、すべてのセルを処理するまで、1つのセルにステップ(a)から(i)を実行した後、別のセルに同じステップを実行します。
    1. フラッシュ・キャッシュを削除します。
      # cellcli -e DROP FLASHCACHE
    2. セル上のすべてのグリッド・ディスクを無効化します。
      # cellcli -e ALTER GRIDDISK ALL INACTIVE
    3. CELLSRVサービスを停止します。
      # cellcli -e ALTER CELL SHUTDOWN SERVICES CELLSRV
    4. flashCacheMode属性をwritethroughに設定します。
      # cellcli -e "ALTER CELL FLASHCACHEMODE=writethrough"
    5. セル・サービスを再起動します。
      # cellcli -e ALTER CELL STARTUP SERVICES CELLSRV
    6. セルのグリッド・ディスクを再アクティブ化します。
      # cellcli -e ALTER GRIDDISK ALL ACTIVE
    7. フラッシュ・キャッシュを再作成します。
      # cellcli -e CREATE FLASHCACHE ALL
    8. セルのステータスを確認します。
      # cellcli -e LIST CELL DETAIL | grep flashCacheMode
    9. グリッド・ディスクのasmDeactivationOutcome属性とasmModeStatus属性をチェックします。
      # cellcli -e LIST GRIDDISK ATTRIBUTES name,status,asmdeactivationoutcome,asmmodestatus

      asmDeactivationOutcome属性がyesに、asmModeStatus属性がonlineになっている必要があります。

      ディスク・ステータスがSYNCINGの場合は、続行せずにACTIVEになるまで待ちます。

3.4.6.4 11.2.3.3.1より前のソフトウェア・バージョンの非ローリング形式でのライトバック・フラッシュ・キャッシュの無効化

ライトバック・フラッシュ・キャッシュは、非ローリング形式で有効化できます。

フラッシュ・キャッシュ・モードを非ローリング形式で変更する場合は、クラスタ全体(Oracle Clusterwareスタックとすべてのデータベースを)含むを停止してください。flashCacheMode属性を変更する前に、セル・サービスをシャットダウンする必要があります。属性をwritethroughに変更する前に、フラッシュ・キャッシュをフラッシュして削除する必要があります。フラッシュ・キャッシュのフラッシュ操作は、クラスタ全体を停止する前に実行できます。フラッシュ操作が開始されると、フラッシュ・キャッシュへのすべてのキャッシュが停止されます。

  1. ライトバック・フラッシュ・キャッシュを無効にする最初のデータベース・ノードにrootユーザーとしてログインします。
  2. 次のコマンドを使用して、フラッシュ・キャッシュ内のダーティ・データの量をチェックします。
    # dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT ATTRIBUTES  \
        name,metricvalue WHERE name LIKE \'FC_BY_DIRTY.*\'"
  3. 次のコマンドを使用して、フラッシュ・キャッシュをフラッシュします。
    # dcli -g cell_group -l root cellcli -e ALTER FLASHCACHE ALL FLUSH
  4. 次のコマンドを使用して、ブロックがディスクに移動されたときのステータスをチェックします。件数はゼロまで減ります。
    # dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT ATTRIBUTES name, \
       metricvalue WHERE NAME LIKE \'FC_BY_DIRTY.*\'"
  5. 次のコマンドを使用して、フラッシュ・ディスクのステータスをチェックします。
    # dcli -g cell_group -l root cellcli -e LIST CELLDISK ATTRIBUTES name, flushstatus, flusherror | grep FD

    フラッシュが完了すると、ステータスがcompletedになります。

  6. 次のコマンドを使用して、データベースとクラスタ全体を停止します。
    # cd Grid_home/bin
# ./crsctl stop cluster -all
  7. 次のコマンドを使用して、すべてのセルのフラッシュ・キャッシュを削除します。
    # dcli -g cell_group -l root cellcli -e DROP FLASHCACHE
  8. 次のコマンドを使用して、CELLSRVサービスを停止します。
    # dcli -g cell_group -l root cellcli -e ALTER CELL SHUTDOWN SERVICES CELLSRV
  9. 次のコマンドを使用して、flashCacheMode属性をwritethroughに設定します。
    # dcli -g cell_group -l root cellcli -e "ALTER CELL FLASHCACHEMODE=writethrough"
  10. 次のコマンドを使用して、セル・サービスを再起動します。
    # dcli -g cell_group -l root cellcli -e ALTER CELL STARTUP SERVICES CELLSRV
  11. 次のコマンドを使用して、フラッシュ・キャッシュを再作成します。
    # dcli -g cell_group -l root cellcli -e CREATE FLASHCACHE ALL
  12. 次のコマンドを使用して、セルのフラッシュ・キャッシュ・モードをチェックします。
    # dcli -g cell_group -l root cellcli -e LIST CELL DETAIL | grep flashCacheMode
  13. 次のコマンドを使用して、クラスタとデータベースを再起動します。
    # cd Grid_home/bin
# ./crsctl start cluster -all

3.4.7 フラッシュ・キャッシュの圧縮の有効化

Oracle Exadata Database Machine X4-2、Oracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X3-8フル・ラックの各システムでは、フラッシュ・キャッシュの圧縮を有効にできます。Oracle Exadata Database Machine X5-2およびX5-8以降のシステムにフラッシュ・キャッシュの圧縮機能はありません。フラッシュ・キャッシュの圧縮では、ユーザー・データがフラッシュ・キャッシュにロードされる際にデータを透過的に圧縮することによって、フラッシュ・キャッシュの論理容量が大幅に増加します。

ノート:

  • フラッシュ・キャッシュ圧縮を有効化するには、Oracle拡張圧縮オプションが必要です。

  • フラッシュ・キャッシュの圧縮を有効にした場合、ユーザー・データは保持されません。

次の手順では、フラッシュ・キャッシュの圧縮を有効にする方法について説明します。

  1. このステップは、ライトバック・フラッシュ・キャッシュが有効化されている場合にのみ実行します。ライトバック・フラッシュ・キャッシュが無効の場合は、このステップをスキップします。ライトバック・フラッシュ・キャッシュが無効の場合にこのステップを実行すると、エラー・メッセージが表示される場合があります。次のコマンドを実行してフラッシュ・キャッシュ・モードを確認できます。
    # cellcli -e LIST CELL DETAIL | grep flashCacheMode

    ライトバック・フラッシュ・キャッシュが有効化されている場合は、フラッシュ・セル・ディスクにユーザー・データを保存します。

    # cellcli -e ALTER FLASHCACHE ALL FLUSH

    フラッシュ操作の進行中は、flushstatus属性の値がworkingになります。フラッシュ操作が正常に完了すると、値がcompleteに変更されます。グリッド・ディスクの属性cachedbyはnullである必要があります。また、フラッシュが完了すると、ダーティ・バッファ(フラッシュされていないもの)の数が0になります。 

    # cellcli -e LIST METRICCURRENT FC_BY_DIRTY
          FC_BY_DIRTY     FLASHCACHE      0.000 MB
  2. セルからフラッシュ・キャッシュを削除します。
    # cellcli -e DROP FLASHCACHE ALL
  3. セルからフラッシュ・ログを削除します。
    # cellcli -e DROP FLASHLOG ALL
  4. フラッシュ・ディスク上のセル・ディスクを削除します。
    # cellcli -e DROP CELLDISK ALL FLASHDISK
  5. システムに応じて、次のコマンドを使用してフラッシュ・キャッシュの圧縮を有効にします。

    • Oracle Exadata System Softwareリリース11.2.3.3.1以降を使用したOracle Exadata Database Machine X3-2、Oracle Exadata Database Machine X3-8およびOracle Exadata Database Machine X4-2のストレージ・サーバーの場合: 

      # cellcli -e ALTER CELL flashcachecompress=true

    • Oracle Exadata System Softwareリリース11.2.3.3.0を使用したOracle Exadata Database Machine X3-2のストレージ・サーバーの場合: 

      # cellcli -e ALTER CELL flashCacheCompX3Support=true
# cellcli -e ALTER CELL flashCacheCompress=true
  6. 物理ディスクのサイズが増えていることを確認します。
    # cellcli -e LIST PHYSICALDISK attributes name,physicalSize,status WHERE disktype=flashdisk

    ステータスは正常である必要があります。次の情報を使用して、圧縮をオンにしたときの想定サイズを検証します。

    • Aura 2.0/F40/X3:

      • 物理ディスク・サイズ: 93.13G (オフ)または186.26G (オン)

      • フラッシュ・キャッシュ・サイズ: 1489G (オフ)または2979G (オン)

    • Aura 2.1/F80/X4:

      • 物理ディスク・サイズ: 186.26G (オフ)または372.53G (オン)

      • フラッシュ・キャッシュ・サイズ: 2979G (オフ)または5959G (オン)

  7. フラッシュ・ディスク上にセル・ディスクを作成します。
    # cellcli -e CREATE CELLDISK ALL FLASHDISK
CellDisk FD_00_exampleceladm18 successfully created
...
CellDisk FD_15_exampleceladm18 successfully created
  8. フラッシュ・ログを作成します。
    # cellcli -e CREATE FLASHLOG ALL
Flash log RaNdOmceladm18_FLASHLOG successfully created
  9. セル上にフラッシュ・キャッシュを作成します。
    # cellcli -e CREATE FLASHCACHE ALL
Flash cache exampleceladm18_FLASHCACHE successfully created

親トピック: Oracle Exadata Storage Serverのフラッシュ・ディスクの保守

3.4.8 Exadataスマート・フラッシュ・キャッシュ使用状況統計の監視

Exadataスマート・フラッシュ・キャッシュの使用状況は次の方法で監視します。

  • AWRレポート(Exadata統計のセクション)。
    • 「パフォーマンス・サマリー」では、フラッシュ・キャッシュに関連する様々な統計とその効果を確認できます。
    • Exadataスマート統計には、Exadataスマート・フラッシュ・キャッシュの統計に関する複数のレポートが含まれているフラッシュ・キャッシュについてのセクションがあります。
  • ExaWatcherのレポート

    フラッシュ・キャッシュのサイズと、読取り操作、書込み操作および移入操作に関連する統計は、セル・サーバー・チャート内およびFlashCacheに関連する統計セクション内で公開されます。

  • CellCLI LISTコマンドを使用して、フラッシュ・キャッシュのメトリックを表示および監視します。

関連トピック

親トピック: Oracle Exadata Storage Serverのフラッシュ・ディスクの保守

3.4.9 フラッシュ・キャッシュの圧縮の無効化

Oracle Exadata Database Machine X4-2、Oracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X3-8フル・ラックの各システムでは、フラッシュ・キャッシュの圧縮を無効にできます。Oracle Exadata Database Machine X5-2、X5-8およびそれ以上のシステムにフラッシュ・キャッシュの圧縮機能はありません。

ノート:

  • フラッシュ・キャッシュの圧縮を無効にした場合、ユーザー・データは保持されません。

次の手順では、フラッシュ・キャッシュの圧縮を無効にする方法について説明します。

  1. フラッシュ・セル・ディスクにユーザー・データを保存します。
    # cellcli -e ALTER FLASHCACHE ALL FLUSH

    グリッド・ディスクの属性cachedbyはnullである必要があります。また、フラッシュが完了すると、ダーティ・バッファ(フラッシュされていないもの)の数が0になります。 

    # cellcli -e LIST METRICCURRENT FC_BY_DIRTY
          FC_BY_DIRTY     FLASHCACHE      0.000 MB
  2. セルからフラッシュ・キャッシュを削除します。
    # cellcli -e DROP FLASHCACHE ALL
  3. セルからフラッシュ・ログを削除します。
    # cellcli -e DROP FLASHLOG ALL
  4. フラッシュ・ディスク上のセル・ディスクを削除します。
    # cellcli -e DROP CELLDISK ALL FLASHDISK
  5. システムに応じて、次のコマンドを使用してフラッシュ・キャッシュの圧縮を無効にします。

    • Exadata Storage Cell Serverイメージが11.2.3.3.1以上で、Exadata Storage CellがX3-2またはX4-2である場合:

      # cellcli -e ALTER CELL flashcachecompress=false

    • Exadata Storage Cell Serverイメージが11.2.3.3.0で、Exadata Storage CellがX3-2である場合:

      # cellcli -e ALTER CELL flashCacheCompX3Support=true
# cellcli -e ALTER CELL flashCacheCompress=false

      ノート:

      flashCacheCompressをfalseに設定しますが、flashCacheCompX3Supportはtrueに設定する必要があります。

    セルの属性を表示して、フラッシュ・キャッシュの圧縮が無効になっていることを確認できます。

    # cellcli -e LIST CELL attributes name,flashCacheCompress

    正しい値はFALSEまたはnull文字列です。

  6. 物理ディスクのサイズが減っていることを確認します。
    # cellcli -e LIST PHYSICALDISK attributes name,physicalSize,status WHERE disktype=flashdisk

    ステータスは正常である必要があります。次の情報を使用して、圧縮をオフにしたときの想定サイズを検証します。

    • Aura 2.0/F40/X3:

      • 物理ディスク・サイズ: 93.13G (オフ)または186.26G (オン)

      • フラッシュ・キャッシュ・サイズ: 1489G (オフ)または2979G (オン)

    • Aura 2.1/F80/X4:

      • 物理ディスク・サイズ: 186.26G (オフ)または372.53G (オン)

      • フラッシュ・キャッシュ・サイズ: 2979G (オフ)または5959G (オン)

  7. フラッシュ・ディスク上にセル・ディスクを作成します。
    # cellcli -e CREATE CELLDISK ALL FLASHDISK
CellDisk FD_00_exampleceladm18 successfully created
...
CellDisk FD_15_exampleceladm18 successfully created
  8. フラッシュ・ログを作成します。
    # cellcli -e CREATE FLASHLOG ALL
Flash log RaNdOmceladm18_FLASHLOG successfully created

    フラッシュ・ログが通常のモードであることを確認します。

    # cellcli -e LIST FLASHLOG DETAIL
  9. セル上にフラッシュ・キャッシュを作成します。
    # cellcli -e CREATE FLASHCACHE ALL
Flash cache exampleceladm18_FLASHCACHE successfully created

    フラッシュ・キャッシュが通常のモードであることを確認します。

    # cellcli -e LIST FLASHCACHE DETAIL
  10. フラッシュ・キャッシュの圧縮が無効になっていることを確認します。
    # cellcli -e LIST CELL

    flashCacheCompress属性の値がfalseに設定されている必要があります。

親トピック: Oracle Exadata Storage Serverのフラッシュ・ディスクの保守

3.5 Oracle Exadata Storage ServerのPMEMデバイスの保守

Oracle Exadata X8M以降、大容量(HC)およびExtreme Flash (EF)ストレージ・サーバーには永続メモリー(PMEM)デバイスが含まれます。

PMEMデバイスに障害が発生すると、Oracle Exadata System Softwareは障害が発生したデバイスを分離し、必要に応じてPMEMキャッシュを自動的にリカバリします。

PMEMキャッシュがライトバック・モードの場合、リカバリ操作(ミラー復元とも呼ばれる)は残っているミラー・コピーを読み取ることで、失われたデータをリストアします。復元中、グリッド・ディスクのステータスはACTIVE -- RESILVERING WORKINGになります。PMEMキャッシュがライトスルー・モードになっている場合、障害が発生したPMEMデバイスのデータはデータ・グリッド・ディスクにすでに保存されており、リカバリは必要ありません。

親トピック: Oracle Exadata Storage Serverの保守

3.5.1 デバイス障害によるPMEMデバイスの交換

PMEMデバイスのステータスがFailedの場合は、Oracle Exadata Storage ServerのPMEMデバイスを交換する必要があります。

PMEMの障害は、サーバーの再起動の原因になることがあります。障害が発生したデバイスは、できるだけすぐに新しいPMEMデバイスに交換する必要があります。デバイスを交換するまでは、ストレージ・サーバーの有効なPMEMキャッシュ・サイズが減少します。PMEMデバイスがPMEMログに使用されている場合、ディスク上のPMEMログは無効になり、有効なPMEMログ・サイズが減少します。

PMEMデバイスの障害が検出されると、アラートが生成されます。アラート・メッセージには、スロット番号とセル・ディスク名が含まれています。システムのアラート通知を構成している場合は、指定したアドレスにアラートが電子メール・メッセージで送信されます。

障害が発生したPMEMデバイスの特定には、次のコマンドを使用することもできます。

CellCLI> LIST PHYSICALDISK WHERE disktype=PMEM AND status=failed DETAIL

    name:                          PMEM_0_1
    diskType:                      PMEM
    luns:                          P0_D1
    makeModel:                     "Intel NMA1XBD128GQS"
    physicalFirmware:              1.02.00.5365
    physicalInsertTime:            2019-09-28T11:29:13-07:00
    physicalSerial:                8089-A2-1838-00001234
    physicalSize:                  126.375G
    slotNumber:                    "CPU: 0; DIMM: 1"
    status:                        failed

前述の出力で、slotNumberにソケット番号とDIMMスロット番号が表示されます。

  1. 障害が発生したPMEMデバイスが含まれているストレージ・サーバーを特定します。
    白色のロケータLEDが点灯し、影響を受けているストレージ・サーバーを特定できます。サーバーを特定したら、障害検知ボタンを使用して、障害が発生したDIMMを特定します。

    注意:

    サービス不可LEDインジケータが点灯しているときに、障害が発生したDCPMM DIMMを取り外さないでください。
  2. 障害が発生したPMEMデバイスがあるストレージ・サーバーの電源をオフにして、サーバーの電源コードを取り外します。
  3. 障害が発生したPMEMデバイスを交換します。
  4. ストレージ・サーバーを再起動します。

    ノート:

    再起動時に、ストレージ・サーバーは新しいPMEMデバイスの初期化を完了するために再度シャットダウンします。

新しいPMEMデバイスがシステムによって自動的に使用されています。PMEMキャッシュにPMEMデバイスを使用している場合は、有効なPMEMキャッシュ・サイズが増加します。PMEMデバイスがPMEMログ用に使用されている場合は、そのデバイスでPMEMログが有効になります。

親トピック: Oracle Exadata Storage ServerのPMEMデバイスの保守

3.5.2 パフォーマンスの低下によるPMEMデバイスの交換

PMEMデバイスのパフォーマンスが低下している場合は、モジュールの交換が必要になることがあります。

PMEMデバイスでパフォーマンスの低下が検出された場合、モジュール・ステータスはwarning - predictive failureに設定され、アラートが生成されます。このアラートには、PMEMデバイスの交換に関する特定の手順が含まれています。システムのアラート通知を構成している場合、電子メール・メッセージでアラートが指定したアドレスに送信されます。

predictive failure (予測障害)ステータスは、PMEMデバイスに障害が発生する可能性があり、できるだけ早く交換する必要があることを示しています。新しいデータは、交換されるまでPMEMデバイスにキャッシュされません。

ステータスがpredictive failure (予測障害)のPMEMデバイスの特定には、次のコマンドを使用することもできます。 

CellCLI> LIST PHYSICALDISK WHERE disktype=PMEM AND status='warning - predictive failure' DETAIL

         name:               PMEM_0_6
         diskType:           PMEM
         luns:               P0_D6
         makeModel:          "Intel NMA1XBD128GQS"
         physicalFirmware:   1.02.00.5365
         physicalInsertTime: 2019-11-30T21:24:45-08:00
         physicalSerial:     8089-A2-1838-00001234
         physicalSize:       126.375G
         slotNumber:         "CPU: 0; DIMM: 6"
         status:             warning - predictive failure

そのPMEMデバイスは、LIST DISKMAPコマンドで次の情報によって特定することもできます。 

CellCLI> LIST DISKMAP
Name      PhysicalSerial         SlotNumber        Status       PhysicalSize
   CellDisk       DevicePartition    GridDisks
PMEM_0_1  8089-a2-0000-00000460  "CPU: 0; DIMM: 1"  normal      126G
   PM_00_cel01    /dev/dax5.0        PMEMCACHE_PM_00_cel01
PMEM_0_3  8089-a2-0000-000004c2  "CPU: 0; DIMM: 3"  normal      126G
   PM_02_cel01    /dev/dax4.0        PMEMCACHE_PM_02_cel01
PMEM_0_5  8089-a2-0000-00000a77  "CPU: 0; DIMM: 5"  normal      126G
   PM_03_cel01    /dev/dax3.0        PMEMCACHE_PM_03_cel01
PMEM_0_6  8089-a2-0000-000006ff  "CPU: 0; DIMM: 6"  warning -   126G
   PM_04_cel01    /dev/dax0.0        PMEMCACHE_PM_04_cel01
PMEM_0_8  8089-a2-0000-00000750  "CPU: 0; DIMM: 8"  normal      126G
   PM_05_cel01    /dev/dax1.0        PMEMCACHE_PM_05_cel01
PMEM_0_10 8089-a2-0000-00000103  "CPU: 0; DIMM: 10" normal      126G
   PM_01_cel01    /dev/dax2.0        PMEMCACHE_PM_01_cel01
PMEM_1_1  8089-a2-0000-000008f6  "CPU: 1; DIMM: 1"  normal      126G
   PM_06_cel01    /dev/dax11.0       PMEMCACHE_PM_06_cel01
PMEM_1_3  8089-a2-0000-000003bb  "CPU: 1; DIMM: 3"  normal      126G
   PM_08_cel01    /dev/dax10.0       PMEMCACHE_PM_08_cel01
PMEM_1_5  8089-a2-0000-00000708  "CPU: 1; DIMM: 5"  normal      126G
   PM_09_cel01    /dev/dax9.0        PMEMCACHE_PM_09_cel01
PMEM_1_6  8089-a2-0000-00000811  "CPU: 1; DIMM: 6"  normal      126G
   PM_10_cel01    /dev/dax6.0        PMEMCACHE_PM_10_cel01
PMEM_1_8  8089-a2-0000-00000829  "CPU: 1; DIMM: 8"   normal     126G
   PM_11_cel01    /dev/dax7.0        PMEMCACHE_PM_11_cel01
PMEM_1_10 8089-a2-0000-00000435  "CPU: 1; DIMM: 10"   normal    126G
   PM_07_cel01    /dev/dax8.0        PMEMCACHE_PM_07_cel01

PMEMデバイスがライトバックPMEMキャッシュに使用されている場合、データはPMEMデバイスからフラッシュ・キャッシュにフラッシュされます。PMEMデバイスからデータがフラッシュされていることを確認するには、すべてのグリッド・ディスクのcachedBy属性を調べて、影響を受けたPMEMデバイスがリストされていないことを確認します。

  1. 障害が発生したPMEMデバイスが含まれているストレージ・サーバーを特定します。
    白色のロケータLEDが点灯し、影響を受けているストレージ・サーバーを特定できます。サーバーを特定したら、障害検知ボタンを使用して、障害が発生したDIMMを特定します。

    注意:

    サービス不可LEDインジケータが点灯しているときに、障害が発生したDCPMM DIMMを取り外さないでください。
  2. 障害が発生したPMEMデバイスがあるストレージ・サーバーの電源をオフにして、サーバーの電源コードを取り外します。
  3. 障害が発生したPMEMデバイスを交換します。
  4. ストレージ・サーバーを再起動します。

    ノート:

    再起動時に、ストレージ・サーバーは新しいPMEMデバイスの初期化を完了するために再度シャットダウンします。

新しいPMEMデバイスがシステムによって自動的に使用されています。PMEMキャッシュにPMEMデバイスを使用している場合は、有効なPMEMキャッシュ・サイズが増加します。PMEMデバイスがPMEMログ用に使用されている場合は、そのデバイスでPMEMログが有効になります。

親トピック: Oracle Exadata Storage ServerのPMEMデバイスの保守

3.5.3 ライトバックPMEMキャッシュの有効化および無効化

Oracle Exadata System Softwareリリース19.3以降では、PMEMキャッシュにより、頻繁にアクセスするデータが高速のソリッドステート記憶装置に透過的にキャッシュされ、問合せの応答時間とスループットを向上させることができます。

ディスクではなくPMEMキャッシュによって処理される書込み操作は、ライトバックPMEMキャッシュと呼ばれます。この機能は必要に応じて有効または無効にできます。

ノート:

PMEMキャッシュを削除して再作成すると、データベース操作のパフォーマンスに影響します。PMEMキャッシュの再移入中には、データベースのパフォーマンスに影響するキャッシュ・ミスが増加します。
  • ライトバックPMEMキャッシュの有効化
    Exadata Database Machine X8M以降のシステムで、フラッシュ・キャッシュがライトスルー・モードの場合に、PMEMキャッシュ・モードをライトスルーからライトバックに変更するには、最初にフラッシュ・キャッシュを変更する必要があります。
  • ライトバックPMEMキャッシュの無効化
    ストレージ・サーバーのライトバックPMEMキャッシュを無効化する必要がある場合は、次のステップを使用します。

親トピック: Oracle Exadata Storage ServerのPMEMデバイスの保守

3.5.3.1 ライトバックPMEMキャッシュの有効化

Exadata Database Machine X8M以降のシステムで、フラッシュ・キャッシュがライトスルー・モードの場合に、PMEMキャッシュ・モードをライトスルーからライトバックに変更するには、最初にフラッシュ・キャッシュを変更する必要があります。

ノート:

  • ベスト・プラクティスの推奨事項は、ライトスルー・モードでPMEMキャッシュを構成することです。この構成によって、最高のパフォーマンスと可用性が提供されます。
  • PMEMキャッシュ・モードをライトスルーからライトバックに変更する場合は、ワークロードが低い期間に構成を変更して、アプリケーションのパフォーマンスへの影響を抑えます。
  1. フラッシュ・キャッシュが現在ライトスルー・モードに設定されている場合は、最初にフラッシュ・キャッシュ・モードをライトバックに変更する必要があります。

    次のコマンドを使用して、フラッシュ・キャッシュの現在の設定を判別します。ここで、cell_groupは、問い合せるストレージ・サーバーがリストされたテキスト・ファイルです。 

    # dcli –l root –g cell_group cellcli -e list cell detail | grep flashCacheMode
    1. フラッシュ・キャッシュを変更する前に、すべての物理ディスクがNORMAL状態であることを検証します。
      # dcli –l root –g cell_group cellcli –e “LIST PHYSICALDISK ATTRIBUTES name,status”
|grep –v NORMAL
    2. フラッシュ・キャッシュを変更する前に、すべての物理ディスクがNORMAL状態であることを検証します。
      コマンドでは行が戻されません。
    3. フラッシュ・キャッシュ内のダーティ・データの量を確認します。
      # cellcli -e "LIST METRICCURRENT ATTRIBUTES name,metricvalue WHERE
 name LIKE \'FC_BY_DIRTY.*\' "
    4. フラッシュ・キャッシュをフラッシュします。

      フラッシュ・キャッシュが、すべての使用可能なフラッシュ・セル・ディスクを使用する場合は、フラッシュ・ディスクをリストするかわりにALLキーワードを使用できます。 

      # dcli –g cell_group –l root cellcli -e "ALTER FLASHCACHE CELLDISK=\'FD_02_dm01celadm12,
FD_03_dm01celadm12,FD_00_dm01celadm12,FD_01_dm01celadm12\' FLUSH"
    5. フラッシュ・キャッシュのフラッシュの進捗状況をチェックします。

      FC_BY_DIRTYが0MBになると、フラッシュ・プロセスは完了します。

      # dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT ATTRIBUTES name,metricvalue
 WHERE name LIKE \'FC_BY_DIRTY.*\' "

      属性flushstatusがCompletedに設定されたかどうかを確認することもできます。 

      # dcli -g cell_group -l root cellcli -e "LIST CELLDISK ATTRIBUTES name, flushstatus, 
flusherror" | grep FD
    6. フラッシュ・キャッシュのフラッシュが完了した後、フラッシュ・キャッシュを削除します。
      # dcli -g cell_group -l root cellcli -e drop flashcache
    7. ライトバック・モードを使用するようにフラッシュ・キャッシュを変更します。
      # dcli -g cell_group -l root cellcli -e "ALTER CELL flashCacheMode=writeback"
    8. フラッシュ・キャッシュを再作成します。

      フラッシュ・キャッシュが、すべての使用可能なフラッシュ・セル・ディスクを使用する場合は、セル・ディスクをリストするかわりにALLキーワードを使用できます。

      size属性を含めない場合、リスト内の各セル・ディスク上の使用可能なすべての領域が、フラッシュ・キャッシュに使用されます。 

      # dcli –l root –g cell_group cellcli -e "create flashcache celldisk=\'FD_02_dm01celadm12,
FD_03_dm01celadm12,FD_00_dm01celadm12,FD_01_dm01celadm12\'
    9. flashCacheModeがwritebackに設定されていることを確認します。
      # dcli –l root –g cell_group cellcli -e list cell detail | grep flashCacheMode
  2. PMEMキャッシュをフラッシュします。

    PMEMキャッシュが、すべての使用可能なPMEMセル・ディスクを使用する場合は、次に示すようにALLキーワードを使用できます。 

    # dcli –l root –g cell_group cellcli ALTER PMEMCACHE ALL FLUSH

    それ以外の場合は、CELLDISK="cdisk1 [,cdisk2] ..."句を使用して特定のディスクをリストします。

  3. PMEMキャッシュを削除します。
    # dcli –l root –g cell_group cellcli DROP PMEMCACHE
  4. ライトバック・モードを使用するようにPMEMキャッシュを変更します。
    # dcli –l root –g cell_group cellcli ALTER CELL pmemCacheMode=WriteBack

    Oracle Exadata System Softwareリリース20.1.0以降、このコマンドでは、PMEMキャッシュをライトスルー・モードで使用するベスト・プラクティスの推奨事項に関する警告が表示され、変更の確認を求めるプロンプトが表示されます。

  5. PMEMキャッシュを再作成します。

    PMEMキャッシュが、すべての使用可能なPMEMセル・ディスクを使用する場合は、次に示すようにALLキーワードを使用できます。それ以外の場合は、CELLDISK="cdisk1 [,cdisk2] ..."句を使用して特定のディスクをリストします。size属性が指定されていない場合は、最大サイズが割り当てられます。リスト内の各セル・ディスクの使用可能なすべての領域が、PMEMキャッシュに使用されます。 

    # dcli –l root –g cell_group cellcli -e CREATE PMEMCACHE ALL
  6. pmemCacheModeがwritebackに設定されていることを確認します。
    # dcli –l root –g cell_group cellcli -e list cell detail | grep pmemCacheMode
3.5.3.2 ライトバックPMEMキャッシュの無効化

ストレージ・サーバーのライトバックPMEMキャッシュを無効化する必要がある場合は、次のステップを使用します。

ライトバックPMEMキャッシュを無効化するときには、cellsrvプロセスを停止する必要も、グリッド・ディスクを非アクティブ化する必要もありません。ただし、アプリケーションのパフォーマンスへの影響を抑えるために、ライトバックPMEMキャッシュはワークロードが低い期間に無効化してください。

  1. PMEMキャッシュを変更する前に、すべての物理ディスクが正常な状態であることを確認します。

    次のコマンドでは行が戻されません。

    # dcli –l root –g cell_group cellcli –e “LIST PHYSICALDISK ATTRIBUTES name,status”|grep –v NORMAL
  2. PMEMキャッシュをフラッシュします。
    # dcli –g cell_group –l root cellcli -e "ALTER PMEMCACHE ALL FLUSH"

    PMEMキャッシュにより、ダーティ・データが下位層のライトバック・フラッシュ・キャッシュにフラッシュされます。

  3. PMEMキャッシュのフラッシュ操作が完了したことを確認します。

    フラッシュ・プロセスは、グリッド・ディスクのcachedBy属性にPMEMデバイスが表示されなくなったときに完了しています。 

    CellCLI> LIST GRIDDISK ATTRIBUTES name, cachedBy
DATA_CD_00_cel01     FD_00_cel01
DATA_CD_01_cel01     FD_01_cel01
DATA_CD_02_cel01     FD_03_cel01
DATA_CD_03_cel01     FD_02_cel01
DATA_CD_04_cel01     FD_00_cel01
DATA_CD_05_cel01     FD_02_cel01
...
  4. PMEMキャッシュを削除します。
    # dcli -g cell_group -l root cellcli -e drop pmemcache all
  5. pmemCacheMode属性をwritethroughに設定します。
    # dcli -g cell_group -l root cellcli -e "ALTER CELL pmemCacheMode=writethrough"
  6. PMEMキャッシュを再作成します。
    # dcli –l root –g cell_group cellcli -e create pmemcache all
  7. pmemCacheModeがwritethroughに設定されていることを確認します。
    CellCLI> LIST CELL ATTRIBUTES pmemcachemode
   WriteThrough

3.6 Oracle Exadata Storage ServerのM.2ディスクの保守

Exadata Database Machine X7以降のシステムには、システム領域を含む2つの内蔵M.2デバイスが付属しています。

以前のすべてのシステムでは、Oracle Exadata Storage Serverの最初の2つのディスクがシステム・ディスクで、これらのシステム・ディスクの一部がシステム領域と呼ばれています。

ノート:

Oracle ExadataラックおよびOracle Exadata Storage Serverは、M.2ディスクの交換中もオンライン状態で使用可能です。

親トピック: Oracle Exadata Storage Serverの保守

3.6.1 M.2ディスクのステータスの監視

CellCLI LIST PHYSICALDISKコマンドを使用して属性をチェックすることによって、M.2ディスクのステータスを監視できます。

ディスク・ファームウェアによってエラー・カウンタが保守され、ディスクで障害が発生しそうになると、ドライブに予測障害というマークが付けられます。交換が必要かどうかは、セル・ソフトウェアではなくドライブによって決定されます。

  • CellCLIコマンドLIST PHSYICALDISKを使用すると、M.2ディスクのステータスを調べることができます。
    CellCLI> LIST PHYSICALDISK WHERE disktype='M2Disk' DETAIL
         name:                           M2_SYS_0
           deviceName:                  /dev/sdm
           diskType:                      M2Disk
           makeModel:                    "INTEL SSDSCKJB150G7"
         physicalFirmware:         N2010112
         physicalInsertTime:      2017-07-14T08:42:24-07:00
         physicalSerial:            PHDW7082000M150A
         physicalSize:               139.73558807373047G
         slotNumber:                  "M.2 Slot: 0"
         status:                failed

         name:                  M2_SYS_1        
         deviceName:            /dev/sdn
         diskType:              M2Disk
         makeModel:             "INTEL SSDSCKJB150G7"
         physicalFirmware:      N2010112
         physicalInsertTime:    2017-07-14T12:25:05-07:00
         physicalSerial:        PHDW708200SZ150A
         physicalSize:          139.73558807373047G
         slotNumber:            "M.2 Slot: 1"
         status:                normal

    Exadata Storage ServerのM.2ディスク・ステータスは次のとおりです。

    • 正常

    • 存在しない

    • 失敗

    • 警告 - 予測障害

親トピック: Oracle Exadata Storage ServerのM.2ディスクの保守

3.6.2 障害またはその他の問題によるM.2ディスクの交換

M.2ディスクで障害が発生すると、システム領域の冗長性が低くなり、パッチ適用、イメージ化およびシステムのレスキューに影響を及ぼす場合があります。したがって、すぐにディスクを新しいディスクに交換する必要があります。M.2ディスクで障害が発生すると、非アクティブなシステム・ディスクに格納されているソフトウェアを使用するようにストレージ・サーバーが自動的かつ透過的に切り替わり、そのシステム・ディスクがアクティブになります。

M.2ディスクに障害が発生すると、Exadataアラートが生成されます。アラートには、ディスクを交換する特定の手順が含まれます。システムのアラート通知を構成している場合、電子メールでアラートが指定したアドレスに送信されます。

M.2ディスクはホットプラグ対応で、電源の投入時に交換できます。

M.2ディスクの交換後、Oracle Exadata System Softwareによって新しいデバイスが自動的にシステム・パーティションに追加され、再構築プロセスが開始されます。

  1. 障害が発生したM.2ディスクを特定します。
    CellCLI> LIST PHYSICALDISK WHERE diskType=M2Disk AND status!=normal DETAIL
         name:                      M2_SYS_0
         deviceName:                /dev/sda
         diskType:                  M2Disk
         makeModel:                 "INTEL SSDSCKJB150G7"
         physicalFirmware:          N2010112
         physicalInsertTime:        2017-07-14T08:42:24-07:00
         physicalSerial:            PHDW7082000M150A
         physicalSize:              139.73558807373047G
         slotNumber:                "M.2 Slot: 0"
         status:                    failed
  2. 白色のLEDが点灯しているセルを特定します。
  3. シャーシを開き、ステップ1のスロット番号でM.2ディスクを特定します。サービスが必要な場合は、このディスクの黄色のLEDが点灯します。

    M.2ディスクはホットプラグに対応しているため、セルの電源を切断しなくてもディスクを交換できます。

  4. M.2ディスクを取り外します。
    1. ライザー・ボードの両方のソケット・イジェクタを上方外側いっぱいまで回転させます。
      ソケット・イジェクタを開くと、ライザー・ボードの緑色の電源LEDが消灯します。
    2. ライザー・ボードをまっすぐ上に慎重に持ち上げて、ソケットから取り外します。
  5. 交換用のM.2ディスクを挿入します。
    1. 交換用のフラッシュ・ライザー・ボードを開封し、静電気防止マットに置きます。
    2. 交換用のライザー・ボードのノッチをコネクタ・ソケットのコネクタ・キーに合わせます。
    3. コネクタ・ソケットにしっかりと固定されるまで、ライザー・ボードをソケットに押し込みます。

      注意:

      ライザー・ボードがコネクタ・ソケットに楽に入っていかない場合は、ライザー・ボードのノッチとコネクタ・ソケットのコネクタ・キーが合っているかどうか確認してください。ノッチが合っていないと、ライザーボードが損傷する可能性があります。

    4. ライザー・ボードの両方のソケット・イジェクタを内側に回転し、イジェクタのタブによってライザー・ボードの位置が固定されるようにします。
      ソケット・イジェクタを閉じると、ライザー・ボードの緑色の電源LEDが点灯します。
  6. M.2ディスクが交換されたことを確認します。
    CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=M2Disk DETAIL
   name:                  M2_SYS_0 
   deviceName:            /dev/sdm   
   diskType:              M2Disk   
   makeModel:             "INTEL SSDSCKJB150G7"   
   physicalFirmware:      N2010112    
   physicalInsertTime:    2017-08-24T18:55:13-07:00   
   physicalSerial:        PHDW708201G0150A   
   physicalSize:          139.73558807373047G   
   slotNumber:            "M.2 Slot: 0"   
   status:                normal   

   name:                  M2_SYS_1   
   deviceName:            /dev/sdn   
   diskType:              M2Disk   
   makeModel:             "INTEL SSDSCKJB150G7"    
   physicalFirmware:      N2010112   
   physicalInsertTime:    2017-08-24T18:55:13-07:00   
   physicalSerial:        PHDW708200SZ150A   
   physicalSize:          139.73558807373047G   
   slotNumber:            "M.2 Slot: 1"   
   status:                normal
  7. システム・ディスク・アレイがactive syncステータスになっているか、再構築中であることを確認します。
    # mdadm --detail /dev/md[2-3][4-5]
/dev/md24:
      Container : /dev/md/imsm0, member 0
     Raid Level : raid1
     Array Size : 104857600 (100.00 GiB 107.37 GB)
  Used Dev Size : 104857600 (100.00 GiB 107.37 GB)
   Raid Devices : 2
  Total Devices : 2

               State  : active
 Active Devices  : 2
Working Devices  : 2
 Failed Devices  : 0
   Spare Devices : 0  

            UUUID : 152f728a:6d294098:5177b2e5:8e0d766c
   Number    Major    Minor    RaidDevice    State
        1        8       16             0    active sync  /dev/sdb
        0        8        0             1    active sync  /dev/sda
/dev/md25:
      Container : /dev/md/imsm0, member 1
     Raid Level : raid1
     Array Size : 41660416 (39.73 GiB 42.66 GB)
  Used Dev Size : 41660544 (39.73 GiB 42.66 GB)
   Raid Devices : 2
  Total Devices : 2

               State  : clean
 Active Devices  : 2
Working Devices  : 2
 Failed Devices  : 0
   Spare Devices : 0  

             UUID : 466173ba:507008c7:6d65ed89:3c40cf23
   Number    Major    Minor    RaidDevice    State
        1        8       16             0    active sync  /dev/sdb
        0        8        0             1    active sync  /dev/sda

親トピック: Oracle Exadata Storage ServerのM.2ディスクの保守

3.7 ストレージ・サーバーのRAMキャッシュの管理

セルのRAMキャッシュはフラッシュ・キャッシュの直前にあるキャッシュとして、データベース・キャッシュを拡張します。フラッシュ・キャッシュよりも高速ですが、容量が小さくなります。

セルのRAMキャッシュ機能は、Oracle Exadata System Softwareリリース18c (18.1.0.0.0)で導入されました。セルのRAMキャッシュはデフォルトでは無効になっています(ramCacheModeがautoに設定されています)。

ノート:

2022年9月のOracle Exadata System Softwareリリース更新(バージョン22.1.3、21.2.16以降)以降では、ストレージ・サーバーのRAMキャッシュ機能は非推奨になりました。

親トピック: Oracle Exadata Storage Serverの保守

3.7.1 セルのRAMキャッシュについて

セルのRAMキャッシュは、オンライン・トランザクション処理(OLTP)読取りのIO待機時間を大幅に短縮します。

OLTPワークロードでは通常、cell single block physical readの待機統計がデータベース処理時間の上位コンシューマとして表示されます。これらの読取りをセルのRAMキャッシュから調達できる場合、待機時間を大幅に短縮し、これらの読取りのIO待機時間を短縮し、OLTPアプリケーションのパフォーマンスを向上させることができます。

または、データベース・バッファ・キャッシュの拡張機能としてセルのRAMキャッシュを参照することもできます。バッファ・キャッシュ・ミスはセルのRAMキャッシュとなり、バッファ・キャッシュとセルのRAMキャッシュの能力の組合せによってより多くのキャッシュ・ヒットを取得できるため、OLTPのパフォーマンスが向上します。

親トピック: ストレージ・サーバーのRAMキャッシュの管理

3.7.2 セルのRAMキャッシュのサイズ指定に関する推奨事項

ピークのOLTPワークロード時の自動ワークロード・リポジトリ(AWR)レポートのバッファ・プール・アドバイザ・セクションを使用して、セルのRAMキャッシュの推奨サイズを決定します。

メモリー拡張キットのないExadata Storage Server上のセルのRAMキャッシュのデフォルト・サイズは制限されるため、この機能はデフォルトで有効になっていません。アクセラレーションの利点を得るには、まずストレージ・サーバーにメモリー拡張キットをインストールする必要があります。その後、セルのRAMキャッシュを有効にでき、Oracle Exadata System SoftwareはExadata Storage Serverの空きメモリーに基づいてセルのRAMキャッシュを自動的にサイズ設定します。

ピークのOLTPワークロード中にAWRレポートのバッファ・プール・アドバイザ・セクションを使用すると、セルのRAMキャッシュをどのように構成するかを決定するのに役立ちます。次に例を示します。


awr-buffer-pool-advisory-report-cell-ram-cache-sizing.pngの説明が続きます
図awr-buffer-pool-advisory-report-cell-ram-cache-sizing.pngの説明

前述のレポートでは、現在のバッファ・キャッシュ・サイズ(1.00のサイズ係数)を使用すると、データベースでは約338,000,000回の物理読取りが実行されます。バッファ・キャッシュを87% (1.87のサイズ係数)増やすと、物理読取りが約12,000,000回に減少します。

バッファ・キャッシュ・サイズの87%であるセルのRAMキャッシュを作成した場合、338,431,000回の読取り - 11,971,000回の読取り、つまり、約326,000,000回の読取りがセルのRAMキャッシュによって満たされることになります。セルのRAMキャッシュは、セルのRAMキャッシュを活用するOLTP読取りの回数に基づいてサイズ設定できます。セルのRAMキャッシュの合計サイズを使用可能なストレージ・サーバーの数で除算して、ストレージ・サーバーごとに使用するターゲットRAMサイズを取得する必要があります。

Oracle Real Application Clusters (Oracle RAC)データベースが複数のデータベース・インスタンスを使用して設定されている場合、各データベース・インスタンスにはそれぞれのAWRレポート内に独立したバッファ・プール・アドバイザを持ちます。物理読取りの削減回数は、インスタンスによって異なる場合があります。このレポートでは、バッファ・キャッシュ・ミスが別のインスタンスからのキャッシュ・フュージョン・ブロック転送によって満たされる場合がすでに考慮されています。そのため、バッファ・プール・アドバイザ・レポートでは、キャッシュ・フュージョン・ブロックの転送回数をあらかじめ計算に入れた後の実際のストレージの読取り回数のみ推定されます。Oracle RACのセルのRAMキャッシュのサイズ設定方法は非常に簡潔です。各インスタンスに必要な追加領域がどのくらいであるかを確認し、それらの値を加算します。その合計は、プロビジョニングする必要のあるセルのRAMキャッシュの量です。

同様に、複数のデータベースが同じセルセットを共有している場合は、データベースごとに追加のバッファ・キャッシュ・サイズを合計できます。その合計は、セルでプロビジョニングする必要があるセルのRAMキャッシュの合計量です。

必要なセルのRAMキャッシュのサイズがわかったら、どのメモリー拡張キットがニーズに対して最適であるかを決定できます。データベース・サーバーとストレージ・サーバーの両方に追加メモリーを追加することにより、サーバーを任意の順序でアップグレードできます。

  • データベース・サーバー・メモリーを展開すると、指定されたサーバー上でより多くのメモリーが提供され、より大容量のSGAやPGAなどに加えて、より大きいバッファ・キャッシュを潜在的に持つことが可能になります。

  • ストレージ・サーバー・メモリーを展開すると、セルのRAMキャッシュはすべてのデータベース・サーバーで共有されます。追加のメモリーは、すべてのOracle Virtual Machine (Oracle VM)およびデータベース・インスタンス全体にわたって利用できます。

様々なデータベース・サーバーまたはOracle VMで異なるタイミングで様々なワークロードを実行する場合、または複数のデータベースを持つ統合環境を実行している場合、ストレージ・サーバー・メモリーを展開すると、メモリーをすべてのデータベースで共有できるため、追加メモリーの使用量をより柔軟に最大化できる可能性があります。

親トピック: ストレージ・サーバーのRAMキャッシュの管理

3.7.3 セルのRAMキャッシュの有効化

セルのRAMキャッシュ機能を有効にするには、各Oracle Exadata Storage ServerでramCacheModeセル属性をonに設定します。

セルのRAMキャッシュ機能はデフォルトでは無効になっています(ramCacheModeがautoに設定されています)。各ストレージ・サーバーで、ramCacheMode=onを設定すると、セルのRAMキャッシュの作成に、使用可能なすべての空きメモリーが自動的に使用されます。
  1. 各セルでramCacheMode属性の値を変更します。

    dcliを使用して単一のコマンドで複数のセルを変更したり、各Oracle Exadata Storage Serverで次のコマンドを実行したりできます。 

    CellCLI> ALTER CELL ramCacheMode=on
Cell host03celadm10 successfully altered
  2. CellSrvを再起動します。
    CellCLI> ALTER CELL RESTART SERVICES CELLSRV

親トピック: ストレージ・サーバーのRAMキャッシュの管理

3.7.4 セルのRAMキャッシュのサイズの表示

ramCacheMode属性をonに設定した後、ストレージ・サーバーでセルのRAMキャッシュを作成するために可能なかぎり使用可能な空きメモリーが自動的に使用されます。

RAMキャッシュの作成はバックグラウンドで非同期に行われます。この機能を有効にした直後にセルのRAMキャッシュのサイズを問い合せても、正確なサイズは表示されません。セルのalert.logを監視すると、セルのRAMキャッシュの作成の進行状況を追跡できます。
  • セルのRAMキャッシュの現在のステータスを確認するには、セルのramCacheMode、ramCacheSizeおよびramCacheMaxSize属性を取得します。
    CellCLI> LIST CELL ATTRIBUTES ramCacheMaxSize,ramCacheMode, ramCacheSize 
     18.875G         On          18.875G

親トピック: ストレージ・サーバーのRAMキャッシュの管理

3.7.5 セルのRAMキャッシュのサイズ変更

ストレージ・サーバーでセルのRAMキャッシュを作成するために可能なかぎり使用可能な空きメモリーが自動的に使用されます。

セルのRAMキャッシュ機能を有効にしても、Oracle Exadata Storage ServerでセルのRAMキャッシュを作成するために可能なかぎり使用可能な空きメモリーが自動的に使用されます。セルのRAMキャッシュのサイズは、CellCLI LIST CELL ramCacheSizeコマンドを使用することで判別できます。

ramCacheMaxSize属性により、セルのRAMキャッシュに使用できるメモリーの最大量が決まります。

セルのRAMキャッシュのサイズを制限するには、各ストレージ・サーバーでramCacheMaxSize属性の値を変更します。

exadcliを使用して単一のコマンドで複数のストレージ・サーバーを変更したり、各Oracle Exadata Storage Serverで次のコマンドを実行したりできます。 

CellCLI> ALTER CELL ramCacheMaxSize=1G
Cell host03celadm10 successfully altered

例3-1 セルのRAMキャッシュのサイズ制限

セルのRAMキャッシュの最大サイズを1GBに制限するには、次のコマンドを使用して、複数のOracle Exadata Storage Serverを変更します。 

exadcli -c cell01,cell02,cell03 -l celladministrator alter cell ramCacheMaxSize=1G

関連トピック

親トピック: ストレージ・サーバーのRAMキャッシュの管理

3.7.6 セルのRAMキャッシュ使用状況統計の監視

次の方法を使用して、セルのRAMキャッシュ使用状況を監視します。

  • ExaWatcherのレポート

    RamCacheサイズと読取り操作、書込み操作および移入操作に関連する統計は、RamCache関連統計のセクションにあるcellsrvstatで公開されます。

  • AWRレポート(メモリー・キャッシュのセクション)。

    次の3つのサブセクションがあります。

    • メモリー・キャッシュ領域使用状況: 各セルについて、この表にはセルのRAMキャッシュに割り当てられた領域と、OLTPアクティビティにセルのRAMキャッシュが使用している領域の割合が示されます。
    • メモリー・キャッシュのユーザー読取り回数: 各セルについて、この表は読取り回数とデータの読取り量(MB)に基づいてセルのRAMキャッシュの読取り統計を示します。
    • メモリー・キャッシュの内部書込み数: 各セルについて、この表は書込みリクエストの回数とデータの書込み量(MB)に基づいてセルのRAMキャッシュの書込み統計を示します。

親トピック: ストレージ・サーバーのRAMキャッシュの管理

3.7.7 セルのRAMキャッシュの無効化

セルのRAMキャッシュ機能を無効にするには、各Oracle Exadata Storage ServerでramCacheMode属性をoffに設定します。

ノート:

セルのRAMキャッシュ機能はデフォルトでは無効になっています(ramCacheModeがautoに設定されています)。
  1. 各セルでramCacheMode属性の値を変更します。

    dcliを使用して単一のコマンドで複数のセルを変更したり、各Oracle Exadata Storage Serverで次のコマンドを実行したりできます。 

    CellCLI> ALTER CELL ramCacheMode=off
Cell host03celadm10 successfully altered
  2. CellSrvを再起動します。
    CellCLI> ALTER CELL RESTART SERVICES CELLSRV

親トピック: ストレージ・サーバーのRAMキャッシュの管理

3.8 グリッド・ディスクのサイズ変更

グリッド・ディスクおよびOracle ASMディスク・グループのサイズを変更して、空き領域があるものを縮小し、いっぱいに近いもののサイズを増やすことができます。

Exadata Database Machineのディスク・グループ・サイズの初期構成は、Oracleベスト・プラクティスおよびバックアップ・ファイルの場所に基づきます。

  • 内部バックアップの場合: 使用可能な領域の割当ては、DATAディスク・グループで40%、RECOディスク・グループで60%です。

  • 外部バックアップの場合: 使用可能な領域の割当ては、DATAディスク・グループで80%、RECOディスク・グループで20%です。

ディスク・グループの割当ては、デプロイ後に変更できます。たとえば、DATAディスク・グループの割当てが60%では小さすぎるため、80%にサイズ変更する必要が生じる場合があります。

システムで、セル・ディスクに空き領域がないが、1つのディスク・グループ(たとえばRECO)には十分な空き領域がある場合、RECOディスク・グループのサイズを小さくして、空き領域をDATAディスク・グループに再割当てすることができます。RECOディスク・グループを縮小した後で得られる空き領域は、DATAディスク・グループの既存の領域割当てとは連続しないオフセットにあります。グリッド・ディスクは、セル・ディスク上のどこにある領域でも使用することができ、連続している必要はありません。

グリッド・ディスクを拡張しようとするとき、十分な領域がセル・ディスクにすでにあり、既存のグリッド・ディスクを拡張できる場合には、最初に既存のディスク・グループをサイズ変更する必要はありません。RECOディスク・グループとグリッド・ディスクの縮小について説明しているステップ2と3は省略することもできます(ただし、DATAグリッド・ディスクを拡張する前に十分な空き領域があることを確認する必要はあります)。管理者が確保する必要がある空き領域の量は、障害時の補償範囲のレベルによって異なります。

グリッド・ディスクのサイズを縮小する場合は、ミラー化のために領域を確保する方法を理解する必要があります。データは、標準または高冗長性を使用してOracle ASMによって保護され、ファイル・エクステントとして保存される1つまたは2つのデータのコピーが作成されます。これらのコピーは、個別の障害グループに保存されます。1つの障害グループで障害が発生しても、ミラー・コピーには影響がないため、データにはまだアクセスできます。

障害が発生すると、アクセスできないエクステントがOracle ASMによって再ミラー化(またはリバランス)されるため、冗長性が再確立されます。プロセスの再ミラー化を成功するには、新しいファイル・エクステントのミラー・コピーの作成に十分な空き領域がディスク・グループに存在する必要があります。十分な空き領域がないと、一部のエクステントが再ミラー化されず、他のデータ・コピーで後で障害が発生した場合に、ディスク・グループをバックアップからリストアする必要があります。領域の不足により再ミラー化プロセスが失敗すると、Oracle ASMはエラーを送信します。

Oracle Exadata System Softwareリリース12.1.2.1.0以上を使用しているか、バグ19695225用のパッチがソフトウェアに適用されている必要があります。

グリッド・ディスクのサイズを変更するこの手順は、ベア・メタルおよび仮想マシン(VM)デプロイメントに適用されます。

関連トピック

親トピック: Oracle Exadata Storage Serverの保守

3.8.1 使用可能な領域の容量の判別

ディスク・グループ内のディスクのサイズを増やすには、未割当てのディスク領域があるか、別のディスク・グループが現在使用している領域を再割当てする必要があります。

また、Exadataの新規グリッド・ディスクおよびディスク・グループのサイズを計算するためのスクリプト(My Oracle Supportのドキュメント ID 1464809.1)で使用可能なスクリプトを使用すると、ディスク・グループを縮小するために使用可能な空き領域の量の判別に役立ちます。

  1. ディスク・グループによって現在使用されている領域を表示します。 
    SELECT name, total_mb, free_mb, total_mb - free_mb used_mb, round(100*free_mb/total_mb,2) pct_free
FROM v$asm_diskgroup
ORDER BY 1;

NAME                             TOTAL_MB    FREE_MB    USED_MB   PCT_FREE
------------------------------ ---------- ---------- ---------- ----------
DATAC1                           68812800    9985076   58827724      14.51
RECOC1                           94980480   82594920   12385560      86.96

    この例では、DATAC1ディスク・グループには空き領域が約15%しかありませんが、RECOC1ディスク・グループには約87%の空きディスク領域があります。ここに表示されているPCT_FREEは未加工の空き領域です。使用できる空き領域ではありません。リバランス操作のためには追加の領域が必要です。

  2. サイズを変更しようとするディスク・グループについて、ディスク・グループによって使用される障害グループの数とステータスを表示します。
    SELECT dg.name, d.failgroup, d.state, d.header_status, d.mount_mode, 
 d.mode_status, count(1) num_disks
FROM V$ASM_DISK d, V$ASM_DISKGROUP dg
WHERE d.group_number = dg.group_number
AND dg.name IN ('RECOC1', 'DATAC1')
GROUP BY dg.name, d.failgroup, d.state, d.header_status, d.mount_status,
  d.mode_status
ORDER BY 1, 2, 3;

NAME       FAILGROUP      STATE      HEADER_STATU MOUNT_S  MODE_ST  NUM_DISKS
---------- -------------  ---------- ------------ -------- -------  ---------
DATAC1     EXA01CELADM01  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM02  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM03  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM04  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM05  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM06  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM07  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM08  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM09  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM10  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM11  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM12  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM13  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM14  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM01  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM02  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM03  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM04  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM05  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM06  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM07  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM08  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM09  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM10  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM11  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM12  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM13  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM14  NORMAL     MEMBER        CACHED  ONLINE   12

    この例は、フル・ラック(DATAC1とRECOC1に対して14個のセルと14個の障害グループがある)のものです。障害グループごとに、NORMAL状態のディスクが12個以上あることを確認します(num_disks)。MISSINGと表示されているディスクがある、または予期しない数のディスクが構成されている場合は、問題を解決するまで手順を進めないでください。

    Extreme Flashシステムでは、num_disksのディスク数は12ではなく8になります。

  3. 各セルと各障害グループに関連付けられた対応するグリッド・ディスクを表示して、サイズ変更するグリッド・ディスクを確認します。
    SELECT dg.name, d.failgroup, d.path
FROM V$ASM_DISK d, V$ASM_DISKGROUP dg
WHERE d.group_number = dg.group_number
AND dg.name IN ('RECOC1', 'DATAC1')
ORDER BY 1, 2, 3;

NAME        FAILGROUP      PATH
----------- -------------  ----------------------------------------------
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_00_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_01_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_02_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_03_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_04_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_05_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_06_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_07_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_08_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_09_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_10_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_11_exa01celadm01
DATAC1      EXA01CELADM02  o/192.168.74.44/DATAC1_CD_00_exa01celadm01
DATAC1      EXA01CELADM02  o/192.168.74.44/DATAC1_CD_01_exa01celadm01
DATAC1      EXA01CELADM02  o/192.168.74.44/DATAC1_CD_02_exa01celadm01
...
RECOC1      EXA01CELADM13  o/192.168.74.55/RECOC1_CD_00_exa01celadm13
RECOC1      EXA01CELADM13  o/192.168.74.55/RECOC1_CD_01_exa01celadm13
RECOC1      EXA01CELADM13  o/192.168.74.55/RECOC1_CD_02_exa01celadm13
...
RECOC1      EXA01CELADM14  o/192.168.74.56/RECOC1_CD_09_exa01celadm14
RECOC1      EXA01CELADM14  o/192.168.74.56/RECOC1_CD_10_exa01celadm14
RECOC1      EXA01CELADM14  o/192.168.74.56/RECOC1_CD_11_exa01celadm14  

168 rows returned.
  4. 使用可能な空き領域をセル・ディスクで調べます。
    セル・ディスク上の空き領域は、DATAC1グリッド・ディスクのサイズを増やすために使用できます。DATAC1グリッド・ディスクを拡張するために十分な空き領域がない場合は、RECOC1グリッド・ディスクを縮小して、DATAC1グリッド・ディスクの望ましいサイズを実現するために空き領域を提供する必要があります。
    [root@exa01adm01 tmp]# dcli -g ~/cell_group -l root "cellcli -e list celldisk \
  attributes name,freespace" 
exa01celadm01: CD_00_exa01celadm01 0 
exa01celadm01: CD_01_exa01celadm01 0 
exa01celadm01: CD_02_exa01celadm01 0 
exa01celadm01: CD_03_exa01celadm01 0 
exa01celadm01: CD_04_exa01celadm01 0 
exa01celadm01: CD_05_exa01celadm01 0 
exa01celadm01: CD_06_exa01celadm01 0 
exa01celadm01: CD_07_exa01celadm01 0 
exa01celadm01: CD_08_exa01celadm01 0 
exa01celadm01: CD_09_exa01celadm01 0 
exa01celadm01: CD_10_exa01celadm01 0 
exa01celadm01: CD_11_exa01celadm01 0 
...

    この例では空き領域がないため、最初にRECOC1グリッド・ディスクを縮小してDATAC1グリッド・ディスクのための領域を提供する必要があります。構成に使用可能な空き領域が豊富にある場合は、RECOC1グリッド・ディスクを縮小するかわりにその空き領域を使用できます。

  5. RECOC1ディスク・グループと各グリッド・ディスクを縮小する領域の容量を計算します。

    ディスク・グループとそのグリッド・ディスクを安全に縮小できる許容最小サイズは、次の要素を考慮して判断する必要があります。

    • 現在使用中の領域(USED_MB)

    • 想定される増加のための領域(GROWTH_MB)

    • ディスク障害の場合にリバランスに必要な領域(DFC_MB)。通常は合計ディスク・グループ・サイズの15%

    上の要素を考慮した最小サイズ計算は次のようになります。 

    Minimum DG size (MB) = ( USED_MB + GROWTH_MB ) * 1.15

    • USED_MBは、V$ASM_DISKGROUPのTOTAL_MB - FREE_MBを計算することによって導出できます。

    • GROWTH_MBは、ディスク・グループの将来の使用量に固有の見積もりとなり、増加パターンの履歴をその基礎とする必要があります

    ステップ1で示されたRECOC1ディスク・グループの領域の使用量から、増加がないと仮定して、最小で、次のサイズまで縮小できることがわかります。

    RECOC1の最小サイズ = (TOTAL_MB - FREE_MB + GROWTH_MB) * 1.15

    = (94980480 - 82594920 + 0) * 1.15 = 14243394MB = 13,910GB

    ステップ1に表示されている出力例では、RECOC1には豊富な空き領域があり、DATAC1の空き領域は15%未満でした。そこで、RECOC1を縮小して、解放されたディスク領域をDATAC1に提供します。RECOC1を現在のサイズの半部に縮小する場合、新しいサイズは94980480 / 2 = 47490240MBになります。このサイズは、RECOC1ディスク・グループに対して上で計算した最小サイズを大きく上回るため、この値まで縮小しても安全です。

    ステップ2の問合せでは、14個のセルとセルごとに12個のディスクがあるため、RECOC1には168個のグリッド・ディスクがあります(14 * 12 = 168)。RECOC1ディスク・グループの各グリッド・ディスクの新しいサイズの見積もりは、47490240 / 168すなわち282,680MBです。

    新しいグリッド・ディスク・サイズに最も近い16MBごとの境界を調べます。このチェックを実行しない場合は、セルにより、グリッド・ディスクのサイズが最も近い16MB境界に自動的に切り捨てられるため、Oracle ASMディスクとグリッド・ディスクのサイズが一致しなくなる可能性があります。 

    SQL> SELECT 16*TRUNC(&new_disk_size/16) new_disk_size FROM dual;
Enter value for new_disk_size: 282680

NEW_DISK_SIZE
-------------
       282672

    前述の結果に基づいて、RECOC1ディスク・グループのグリッド・ディスクの新しいサイズとして282672MBを選択することをお薦めします。グリッド・ディスクのサイズを変更すると、RECOC1ディスク・グループのサイズは47488896MBになります。

  6. DATAC1ディスク・グループの各グリッド・ディスクのサイズをどれだけ増やすかを計算します。

    Oracle ASMディスクのサイズとグリッド・ディスクのサイズがディスク・グループ全体で一致することを確認します。次の問合せによって、各ディスク・グループのディスク・サイズの組合せが表示されます。すべてのディスクのサイズが同じで、Oracle ASM (total_mb)ディスクとグリッド・ディスク(os_mb)のサイズが一致しているのが理想です。 

    SELECT dg.name, d.total_mb, d.os_mb, count(1) num_disks
FROM v$asm_diskgroup dg, v$asm_disk d
WHERE dg.group_number = d.group_number
GROUP BY dg.name, d.total_mb, d.os_mb;

NAME                             TOTAL_MB      OS_MB  NUM_DISKS
------------------------------ ---------- ---------- ----------
DATAC1                             409600     409600        168
RECOC1                             565360     565360        168

    RECOC1のグリッド・ディスクを縮小した後で、DATAC1の各ディスクに次の領域が提供されます。

    DATAC1ディスクの追加領域 = RECOC1_current_size - RECOC1_new_size
                                                           = 565360 - 282672 = 282688MB

    DATAC1ディスク・グループの新しいサイズを計算するには、次を使用します。

    DATAC1のディスクの新しいサイズ  = DATAC1_ disks_current_size + new_free_space_from_RECOC1
                                              = 409600 + 282688 = 692288MB

    新しいグリッド・ディスク・サイズに最も近い16MBごとの境界を調べます。このチェックを実行しない場合は、セルにより、グリッド・ディスクのサイズが最も近い16MB境界に自動的に切り捨てられるため、Oracle ASMディスクとグリッド・ディスクのサイズが一致しなくなる可能性があります。 

    SQL> SELECT 16*TRUNC(&new_disk_size/16) new_disk_size FROM dual;
Enter value for new_disk_size: 692288

NEW_DISK_SIZE
-------------
       692288

    問合せの結果に基づいて、DATAC1ディスク・グループのディスクについて計算したサイズ692288MBを使用できます。このサイズは16MBごとの境界に合っています。問合せの結果が指定した値と異なる場合は、問合せから返された値を使用する必要があります。セルによってこの値のグリッド・ディスク・サイズに切り上げ(または切り捨て)られるためです。

    新しいグリッド・ディスク・サイズの計算値から、DATAC1ディスク・グループの合計サイズは116304384MB (168ディスク * 692288MB)になります。

親トピック: グリッド・ディスクのサイズ変更

3.8.2 ドナー・ディスク・グループのOracle ASMディスクの縮小

セル・ディスク上に使用可能な空き領域がない場合は、あるディスク・グループが使用する領域を減らして、別のディスク・グループに追加のディスク領域を提供することができます。

このタスクは、RECOC1ディスク・グループの領域をDATAC1ディスク・グループに再割当てする例の続きです。
ディスク・グループのサイズを変更する前に、領域を減らすディスク・グループに十分な空き領域があることを確認します。
  1. RECOディスク・グループ用のOracle ASMディスクをすべてのディスクの新しいサイズに縮小します。

    「使用可能な領域量の確認」のステップ5で計算したRECOディスク・グループのディスクの新しいサイズを使用します。 

    SQL> ALTER DISKGROUP recoc1 RESIZE ALL SIZE 282672M REBALANCE POWER 64;

    ノート:

    ALTER DISKGROUPコマンドが完了するまで数分かかることがあります。この処理が完了するまで、SQLプロンプトは表示されません。

    指定したディスク・グループでディスク・グループ内にquorumディスクが構成されている場合、ALTER DISKGROUP ... RESIZE ALLコマンドはエラーORA-15277で失敗することがあります。quorumディスクは、高冗長性ディスク・グループのためのquorumディスクの管理で指定されている要件が満たされている場合に構成されます。対処方法としては、ストレージ・サーバー障害グループ名(FAILURE_TYPEがREGULARであり、QUORUMではない)をSQLコマンドに明示的に指定してください。次に例を示します。 

    SQL> ALTER DISKGROUP recoc1 RESIZE DISKS IN FAILGROUP exacell01 SIZE 282672M,
exacell02 SIZE 282672M, exacell03 SIZE 282672M REBALANCE POWER 64;

    リバランスが終了するまで待機してから、ビューGV$ASM_OPERATIONをチェックします。

    SQL> set lines 250 pages 1000
SQL> col error_code form a10
SQL> SELECT dg.name, o.*
  2  FROM gv$asm_operation o, v$asm_diskgroup dg
  3  WHERE o.group_number = dg.group_number;

    GV$ASM_OPERATIONへの問合せで、変更中のディスク・グループの行が表示されない場合のみ、次のステップに進みます。

  2. 次の問合せを使用してASMディスクの新しいサイズを確認します。
    SQL> SELECT name, total_mb, free_mb, total_mb - free_mb used_mb,
  2   ROUND(100*free_mb/total_mb,2) pct_free
  3  FROM v$asm_diskgroup
  4  ORDER BY 1;

NAME                             TOTAL_MB    FREE_MB    USED_MB   PCT_FREE
------------------------------ ---------- ---------- ---------- ----------
DATAC1                           68812800    9985076   58827724      14.51
RECOC1                           47488896   35103336   12385560      73.92

SQL> SELECT dg.name, d.total_mb, d.os_mb, COUNT(1) num_disks
  2  FROM v$asm_diskgroup dg, v$asm_disk d
  3  WHERE dg.group_number = d.group_number
  4  GROUP BY dg.name, d.total_mb, d.os_mb;

NAME                             TOTAL_MB      OS_MB  NUM_DISKS
------------------------------ ---------- ---------- ----------
DATAC1                             409600     409600        168
RECOC1                             282672     565360        168

    前述の問合せの例では、RECOC1ディスク・グループのディスクのサイズが各々変更されて282672MGになり、ディスク・グループの合計サイズが47488896MBになったことが表示されます。

親トピック: グリッド・ディスクのサイズ変更

3.8.3 ドナー・ディスク・グループのグリッド・ディスクの縮小

Oracle ASMディスク・グループのディスクを縮小した後、各セルのグリッド・ディスクのサイズを縮小します。

このタスクは、RECOC1ディスク・グループの領域をDATAC1ディスク・グループに再割当てする例の続きです。
「ドナー・ディスク・グループのOracle ASMディスクの縮小」のタスクを完了しておく必要があります。
  1. すべてのセルのRECOディスク・グループに関連付けられたグリッド・ディスクを新しいサイズに縮小します。

    「使用可能な領域量の確認」のステップ3で確認されたストレージ・セルごとに、前のタスクで縮小したOracle ASMディスクのサイズに合わせてグリッド・ディスクを縮小します。次のようなコマンドを使用します。 

    dcli -c exa01celadm01 -l root "cellcli -e alter griddisk RECOC1_CD_00_exa01celadm01 \
,RECOC1_CD_01_exa01celadm01 \
,RECOC1_CD_02_exa01celadm01 \
,RECOC1_CD_03_exa01celadm01 \
,RECOC1_CD_04_exa01celadm01 \
,RECOC1_CD_05_exa01celadm01 \
,RECOC1_CD_06_exa01celadm01 \
,RECOC1_CD_07_exa01celadm01 \
,RECOC1_CD_08_exa01celadm01 \
,RECOC1_CD_09_exa01celadm01 \
,RECOC1_CD_10_exa01celadm01 \
,RECOC1_CD_11_exa01celadm01 \
size=282672M "

dcli -c exa01celadm02 -l root "cellcli -e alter griddisk RECOC1_CD_00_exa01celadm02 \
,RECOC1_CD_01_exa01celadm02 \
,RECOC1_CD_02_exa01celadm02 \
,RECOC1_CD_03_exa01celadm02 \
,RECOC1_CD_04_exa01celadm02 \
,RECOC1_CD_05_exa01celadm02 \
,RECOC1_CD_06_exa01celadm02 \
,RECOC1_CD_07_exa01celadm02 \
,RECOC1_CD_08_exa01celadm02 \
,RECOC1_CD_09_exa01celadm02 \
,RECOC1_CD_10_exa01celadm02 \
,RECOC1_CD_11_exa01celadm02 \
size=282672M "

...

dcli -c exa01celadm14 -l root "cellcli -e alter griddisk RECOC1_CD_00_exa01celadm14 \
,RECOC1_CD_01_exa01celadm14 \
,RECOC1_CD_02_exa01celadm14 \
,RECOC1_CD_03_exa01celadm14 \
,RECOC1_CD_04_exa01celadm14 \
,RECOC1_CD_05_exa01celadm14 \
,RECOC1_CD_06_exa01celadm14 \
,RECOC1_CD_07_exa01celadm14 \
,RECOC1_CD_08_exa01celadm14 \
,RECOC1_CD_09_exa01celadm14 \
,RECOC1_CD_10_exa01celadm14 \
,RECOC1_CD_11_exa01celadm14 \
size=282672M "
  2. 次のコマンドを使用してグリッド・ディスクの新しいサイズを確認します。
    [root@exa01adm01 tmp]# dcli -g cell_group -l root "cellcli -e list griddisk attributes name,size where name like \'RECOC1.*\' "

exa01celadm01: RECOC1_CD_00_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_01_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_02_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_03_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_04_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_05_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_06_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_07_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_08_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_09_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_10_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_11_exa01celadm01 276.046875G  
...

    前述の例では、RECOC1ディスク・グループのディスクのサイズが各々変更されて282672MB (276.046875 * 1024)になったことが表示されます。

親トピック: グリッド・ディスクのサイズ変更

3.8.4 使用可能な領域によるグリッド・ディスクのサイズの拡張

割り当てられていないディスク領域がすでに使用可能か、異なるOracle ASMディスク・グループが使用する領域を縮小して使用可能にした場合、グリッド・ディスクが使用するサイズを増やすことができます。

このタスクは、RECOC1ディスク・グループの領域をDATAC1ディスク・グループに再割当てする例の続きです。既存のディスク・グループを拡張するために十分な領域がすでにある場合は、別のディスク・グループの領域を再割当てする必要はありません。

  1. セル・ディスクに必要な量の空き領域があることを確認します。
    Oracle ASMディスクとグリッド・ディスクを縮小するタスクを完了している場合、セル・ディスクの空き領域は次のように表示されます。 
    [root@exa01adm01 tmp]# dcli -g ~/cell_group -l root "cellcli -e list celldisk \
attributes name,freespace"

exa01celadm01: CD_00_exa01celadm01 276.0625G
exa01celadm01: CD_01_exa01celadm01 276.0625G
exa01celadm01: CD_02_exa01celadm01 276.0625G
exa01celadm01: CD_03_exa01celadm01 276.0625G
exa01celadm01: CD_04_exa01celadm01 276.0625G
exa01celadm01: CD_05_exa01celadm01 276.0625G
exa01celadm01: CD_06_exa01celadm01 276.0625G
exa01celadm01: CD_07_exa01celadm01 276.0625G
exa01celadm01: CD_08_exa01celadm01 276.0625G
exa01celadm01: CD_09_exa01celadm01 276.0625G
exa01celadm01: CD_10_exa01celadm01 276.0625G
exa01celadm01: CD_11_exa01celadm01 276.0625G 
...
  2. ストレージ・セルごとにDATAグリッド・ディスクのサイズを目標の新しいサイズに増やします。

    「使用可能な領域の容量の判別」で計算したサイズを使用します。 

    dcli -c exa01celadm01 -l root "cellcli -e alter griddisk DATAC1_CD_00_exa01celadm01 \
,DATAC1_CD_01_exa01celadm01 \
,DATAC1_CD_02_exa01celadm01 \
,DATAC1_CD_03_exa01celadm01 \
,DATAC1_CD_04_exa01celadm01 \
,DATAC1_CD_05_exa01celadm01 \
,DATAC1_CD_06_exa01celadm01 \
,DATAC1_CD_07_exa01celadm01 \
,DATAC1_CD_08_exa01celadm01 \
,DATAC1_CD_09_exa01celadm01 \
,DATAC1_CD_10_exa01celadm01 \
,DATAC1_CD_11_exa01celadm01 \
size=692288M "
...
dcli -c exa01celadm14 -l root "cellcli -e alter griddisk DATAC1_CD_00_exa01celadm14 \
,DATAC1_CD_01_exa01celadm14 \
,DATAC1_CD_02_exa01celadm14 \
,DATAC1_CD_03_exa01celadm14 \
,DATAC1_CD_04_exa01celadm14 \
,DATAC1_CD_05_exa01celadm14 \
,DATAC1_CD_06_exa01celadm14 \
,DATAC1_CD_07_exa01celadm14 \
,DATAC1_CD_08_exa01celadm14 \
,DATAC1_CD_09_exa01celadm14 \
,DATAC1_CD_10_exa01celadm14 \
,DATAC1_CD_11_exa01celadm14 \
size=692288M "
  3. 次のコマンドを使用して、DATAC1ディスク・グループに関連付けられているグリッド・ディスクの新しいサイズを確認します。
    dcli -g cell_group -l root "cellcli -e list griddisk attributes name,size \ 
where name like \'DATAC1.*\' "

exa01celadm01: DATAC1_CD_00_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_01_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_02_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_03_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_04_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_05_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_06_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_07_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_08_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_09_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_10_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_11_exa01celadm01 676.0625G

DATAディスク・グループのサイズを増やすかわりに、新しい空き領域を使用して新しいディスク・グループを作成することや、将来使用するために空き領域のままにしておくこともできます。一般的には、必要な最小限の数のディスク・グループ(通常はDATA、RECOおよびDBFS_DG)を使用して、高い柔軟性と管理のしやすさを実現することをお薦めします。ただし、場合によっては、仮想マシンを使用するとき、または多数のデータベースを統合するときなど、追加のディスク・グループや将来のための使用可能な空き領域が必要になる可能性があります。

将来のためにグリッド・ディスクに空き領域を残しておく場合は、後から既存のディスク・グループに空き領域を割り当てるステップについて「My Oracle Support Note 1684112.1」を参照してください。

関連トピック

親トピック: グリッド・ディスクのサイズ変更

3.8.5 Oracle ASMディスクのサイズの拡張

関連するグリッド・ディスクに割り当てられる領域を増やした後、Oracle ASMディスクが使用するサイズを増やすことができます。

このタスクは、RECOC1ディスク・グループの領域をDATAC1ディスク・グループに再割当てする例の続きです。
対応するOracle ASMディスク・グループのサイズを変更する前に、グリッド・ディスクのサイズを変更するタスクを完了する必要があります。
  1. DATAC1ディスク・グループのOracle ASMディスクをストレージ・セルのグリッド・ディスクの新しいサイズまで増やします。
    SQL> ALTER DISKGROUP datac1 RESIZE ALL;

    このコマンドにより、Oracle ASMディスクのサイズがグリッド・ディスクのサイズと一致するように変更されます。

    ノート:

    指定したディスク・グループでディスク・グループ内にquorumディスクが構成されている場合、ALTER DISKGROUP ... RESIZE ALLコマンドはエラーORA-15277で失敗することがあります。quorumディスクが構成されるのは、『Oracle Exadata Database Machineメンテナンス・ガイド』に記載されている要件が満たされる場合です。

    対処方法としては、ストレージ・サーバー障害グループ名(FAILURE_TYPEが"REGULAR"であり、"QUORUM"ではない)をSQLコマンドに明示的に指定してください。次に例を示します。

    SQL> ALTER DISKGROUP datac1 RESIZE DISKS IN FAILGROUP exacell01, exacell02, exacell03;
  2. リバランス操作が完了するまで待機します。
    SQL> set lines 250 pages 1000 
SQL> col error_code form a10 
SQL> SELECT dg.name, o.* FROM gv$asm_operation o, v$asm_diskgroup dg 
     WHERE o.group_number = dg.group_number;

    変更されたディスク・グループについて問合せから行が戻されなくなるまで、次のステップに進まないでください。

  3. Oracle ASMディスクおよびディスク・グループの新しいサイズが必要なサイズになっていることを確認します。
    SQL> SELECT name, total_mb, free_mb, total_mb - free_mb used_mb, 
     ROUND(100*free_mb/total_mb,2) pct_free
     FROM v$asm_diskgroup
     ORDER BY 1;

NAME                             TOTAL_MB    FREE_MB    USED_MB   PCT_FREE
------------------------------ ---------- ---------- ---------- ----------
DATAC1                          116304384   57439796   58864588      49.39
RECOC1                           47488896   34542516   12946380      72.74

SQL>  SELECT dg.name, d.total_mb, d.os_mb, COUNT(1) num_disks
      FROM  v$asm_diskgroup dg, v$asm_disk d
      WHERE dg.group_number = d.group_number
      GROUP BY dg.name, d.total_mb, d.os_mb;
 
NAME                             TOTAL_MB      OS_MB  NUM_DISKS
------------------------------ ---------- ---------- ----------
DATAC1                             692288     692288        168
RECOC1                             282672     282672        168

    問合せの結果は、RECOC1およびDATAC1ディスク・グループとディスクのサイズが変更されたことを示します。

関連トピック

親トピック: グリッド・ディスクのサイズ変更

3.9 Oracle Exadata System Softwareのレスキュー手順の使用

システム・ディスクで同時に障害が発生するまれな事例の場合、Oracle Exadata Storage Serverレスキュー手順を使用してシステムをリカバリする必要があります。

親トピック: Oracle Exadata Storage Serverの保守

3.9.1 Oracle Exadata System Softwareのレスキュー手順について

システム・ディスクで障害が発生した場合、オペレーティング・システムに破損したファイル・システムがある場合またはブート領域が損傷している場合、レスキュー手順が必要です。

1つのシステム・ディスクのみで障害が発生した場合、リカバリにCellCLIコマンドを使用します。

通常の冗長性を使用している場合、レスキューされるセルのミラー・コピーは1つだけです。レスキュー手順の実行中にこのミラーでも障害が発生すると、リカバリできないデータの損失が発生する可能性があります。ミラー・コピーのデータの完全なバックアップを作成し、すぐにミラー・コピー・セルをオフラインにしてレスキュー前の新しいデータ変更を防止することをお薦めします。これにより、レスキュー・プロセス中は、障害が発生したセルのグリッド・ディスクのすべてのデータおよびそのミラー・コピーにアクセスできなくなります。

Oracle Automatic Storage Management (Oracle ASM)ディスク修復タイマーのデフォルトの修復時間は、3.6時間です。この時間内にレスキュー手順を実行できないことがわかった場合、レスキュー手順を実行できるまで、Oracle ASMリバランス手順を使用してディスクをリバランスする必要があります。

高冗長性ディスク・グループを使用している場合(たとえば、障害が発生したセルのすべてのグリッド・ディスクにOracle ASMの複数のミラー・コピーがある場合)は、障害が発生したセルをオフラインにします。構成したOracle ASMのタイムアウト後に、障害が発生したセルのグリッド・ディスクはOracle ASMによって自動的に削除され、ミラー・コピーを使用したデータのリバランスが開始されます。デフォルトのタイムアウトは2時間です。セルのレスキューに2時間以上かかる場合は、Oracle ASMでレスキューしたセルにグリッド・ディスクを再作成する必要があります。

注意:

十分に注意してレスキュー手順を使用してください。誤って手順を使用すると、データの損失が発生する可能性があります。

レスキュー手順を使用する場合、次の点に注意してください。

  • レスキュー手順により、セルの一部またはすべてのディスクが書き換えられる可能性があります。この場合、リカバリできずにそれらのディスクのすべての内容を失う可能性があります。

    この手順を使用する場合は十分に注意し、プロンプトを確認してください。レスキュー手順は、Oracleサポート・サービスの支援を受ける場合や、一部または全部のディスクのデータを失っても問題がない場合にのみ使用してください。

  • レスキュー手順の実行中に明示的に選択しないかぎり、レスキュー手順により、データ・ディスクの内容またはシステム・ディスクのデータ・パーティションの内容は破棄されません。

  • Oracle Exadata System Softwareリリース11.2以降では、レスキュー手順によりOracle Exadata System Softwareが同じリリースにリストアされます。これには、最後に正常にブートしたときのセルのパッチが含まれます。レスキュー手順の使用に関して、次の点に注意してください。

    • セル構成情報(アラート構成、SMTP情報、管理者の電子メール・アドレスなど)はリストアされません。

    • /usr/local/bin/ipconfユーティリティの実行が最後に成功したときに存在したネットワーク構成はリストアされます。

    • セルのSSH IDと、root、celladminおよびcellmonitorユーザーは復元されます。

    • Oracle Exadata Storage Serverに対するIntegrated Lights Out Manager (ILOM)の構成はリストアされません。通常、ILOM構成は、Oracle Exadata System Softwareに障害が発生しても損なわれません。

  • レスキュー手順により、データ・ディスクまたはシステム・ディスクのデータ・パーティションの確認または再構築は行われません。グリッド・ディスクにデータの破損がある場合、レスキュー手順は使用しないでください。かわりに、Oracle DatabaseおよびOracle ASMのレスキュー手順を使用してください。

正常なレスキューの実行後、セルを再構成し、データを保存する場合はセル・ディスクをインポートする必要があります。データを保存しない場合は、新しいセル・ディスクおよびグリッド・ディスクを作成する必要があります。

関連トピック

親トピック: Oracle Exadata System Softwareのレスキュー手順の使用

3.9.2 レスキュー手順の実行

レスキュー手順を使用して、Oracle Exadata Storage Serverシステム・ソフトウェアをリカバリできます。

  1. コンソールを使用して、Oracle Exadata Storage Serverに接続します。
  2. Oracle Exadata Storage Serverを起動し、レスキュー・モードで起動するオプションを選択します。

    • X7以降のサーバーでは、初期ブート・シーケンス中に次のブート・オプションのメニューが表示されます。

            Exadata_DBM_0: CELL_BOOT_trying_HD0
      Exadata_DBM_0: CELL_BOOT_trying_CELLBOOT
      Exadata_DBM_1: CELL_BOOT_in_rescue_mode

      Use the ^ and v keys to change the selection.
      Press 'e' to edit the selected item, or 'c' for a command prompt.

      ノート:

      上のメニューは、入力がない場合に短時間表示されます。したがって、メニューを保持するには、表示されたらすぐに上矢印キーまたは下矢印キーを押します。

      メニューで「Exadata_DBM_1:CELL_BOOT_in_rescue_mode」を選択し、[Enter]を押します。

    • X6以降のサーバーでは、初期ブート・シーケンス中に次のように表示されます。

      Press any key to enter the menu
Booting Exadata_DBM_0: CELL_USB_BOOT_trying_C0D0_as_HD1 in 4 seconds...
Booting Exadata_DBM_0: CELL_USB_BOOT_trying_C0D0_as_HD1 in 3 seconds...
Press any key to see the menu.

      上記が表示されたら、任意のキーを押してブート・オプション・メニューを入力します。

      ノート:

      Oracle Exadata System Softwareの古いバージョンの場合、"Oracle Exadata"スプラッシュ画面が表示されます。スプラッシュ画面が表示されたら、キーボードの任意のキーを押します。スプラッシュ画面の表示は、5秒間のみです。

      ブート・オプション・メニューで「CELL_USB_BOOT_CELLBOOT_usb_in_rescue_mode」を選択し、[Enter]を押します。

  3. プロンプトが表示されたら、Oracle Exadata System Softwareを再インストールするオプションを選択します。次に、選択内容を確認します。

    次に例を示します。

             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)einstall or try to recover damaged system, 
Select: r 
[INFO     ] Reinstall or try to recover damaged system
Continue (y/n) [n]: y
  4. プロンプトが表示されたら、レスキューのrootパスワードを指定します。
    必要なパスワードがない場合は、Oracleサポート・サービスに連絡してください。
  5. プロンプトが表示されたら、データ・パーティションおよびデータ・ディスクを消去するかどうかを指定します。

    ストレージ・サーバー上の既存のデータを保持するには、nを指定します。

    yを指定すると、ストレージ・サーバー上のすべてのデータが完全に消去されます。安全であることが確実でないかぎり、このオプションは指定しないでください。

    次に例を示します。

    Do you want to erase data partitions and data disks (y/n)  [n]: n
  6. プロンプトが表示されたら、rootパスワードを指定してレスキュー・シェルに入ります。

    必要なパスワードがない場合は、Oracleサポート・サービスに連絡してください。

    次に例を示します。

    [INFO     ] You are in the rescue mode.
[INFO     ] Imaging pre-boot phase finished with success.
[INFO     ] Installation will continue after reboot.
[INFO     ] Log in to the rescue shell as root with the rescue (Diagnostic shell) root password.

...

Welcome to Exadata Shell!
Give root password for maintenance
(or press Control-D to continue):
  7. レスキュー・プロンプトを使用して、ストレージ・サーバーを再起動し、レスキュー・プロセスを完了します。

    次に例を示します。

    sh-4.2# shutdown -r now

    通常、レスキュー・プロセスが完了するまでに45から90分かかります。レスキュー・プロセス中にストレージ・サーバーが数回再起動することがあります。画面上のメッセージに、レスキュー・プロセスが完了した時間が示されます。次に例を示します。

    Run validation checkconfigs - PASSED
2020-08-17 18:14:01 -0600 The first boot completed with SUCCESS

    最後に、ログイン・プロンプトも表示されます。

親トピック: Oracle Exadata System Softwareのレスキュー手順の使用

3.9.3 Exadata Database Machineストレージ・サーバーのレスキュー後の構成

レスキューが成功した後、セルを構成する必要があります。データ・パーティションを維持した場合は、レスキュー手順の実行時にセル・ディスクが自動的にインポートされています。

  1. レスキュー手順の実行中に交換されたディスクのセル・ディスクおよびグリッド・ディスクを再作成します。
    1. 次のコマンドを使用して、交換されたディスクにのみセル・ディスクを作成します。
      # cellcli -e create celldisk all harddisk
    2. 作成した新しいセル・ディスクの名前を取得します。
    3. グリッド・ディスクのマッピングを取得します。
      cellcli -e list griddisk attributes name,offset,size

      グリッド・ディスクの属性を既存のディスクから取得します。システム・ディスク(X6以前のサーバーのスロット0またはスロット1)を交換した場合は、別のシステム・ディスクから値を取得する必要があります。グリッド・ディスクのいずれかがSPARSEグリッド・ディスクである場合は、別のスパース・ディスクからもvirtualsize属性を取得します。

      たとえば、新しいグリッド・ディスクがCD_01*およびCD_08*の場合は、次のようなコマンドを使用します。

      # cellcli -e list griddisk attributes name,cachingpolicy,offset,size,virtualsize |
egrep '_CD_00|_CD_07'
DATAC1_CD_00_dbm01celadm04    default    32M                  779G
DATAC1_CD_07_dbm01celadm04    default    32M                  779G
DBFSC1_CD_07_dbm01celadm04    default    1.0575714111328125T  33.6875G
RECOC1_CD_00_dbm01celadm04    none       887.046875G          195.90625G
RECOC1_CD_07_dbm01celadm04    none       887.046875G          195.90625G
SPARSEC1_CD_00_dbm01celadm04  default    779.046875G          108G         1.0546875T
SPARSEC1_CD_07_dbm01celadm04  default    779.046875G          108G         1.0546875T
    4. 取得した属性を使用して、新しいセル・ディスクにグリッド・ディスクを作成します。

      たとえば、CD00について、前のステップで取得した属性を使用して、CD01に次のようにグリッド・ディスクを作成します。

      # cellcli -e create griddisk DATAC1_CD_01_dbm01celadm04 celldisk=CD_01_dbm01celadm04, 
size=779G, cachingpolicy=default

# cellcli -e create griddisk SPARSEC1_CD_01_dbm01celadm04 celldisk=CD_01_dbm01celadm04, 
size=108G, virtualsize=1.0546875T,cachingpolicy=default

# cellcli -e create griddisk RECOC1_CD_01_dbm01celadm04 celldisk=CD_01_dbm01celadm04 , 
size=195.90625G, cachingpolicy=none

      CD07について前のステップで取得した属性を使用して、CD08に次のようにグリッド・ディスクを作成します。

      # cellcli -e create griddisk DATAC1_CD_08_dbm01celadm04 celldisk=CD_08_dbm01celadm04, 
size=779G, cachingpolicy=default

# cellcli -e create griddisk SPARSEC1_CD_08_dbm01celadm04 celldisk=CD_08_dbm01celadm04, 
size=108G, virtualsize=1.0546875T,cachingpolicy=default

# cellcli -e create griddisk RECOC1_CD_08_dbm01celadm04 celldisk=CD_08_dbm01celadm04, 
size=195.90625G, cachingpolicy=none

# cellcli -e create griddisk DBFSC1_CD_08_dbm01celadm04 celldisk=CD_08_dbm01celadm04, 
size=33.6875G, cachingpolicy=default
  2. グリッド・ディスクのステータスをチェックします。
    いずれかのグリッド・ディスクが非アクティブの場合は、そのステータスをアクティブに変更します。 
    CellCLI> ALTER GRIDDISK ALL ACTIVE
  3. Oracle Automatic Storage Management (Oracle ASM)インスタンスにログインして、各ディスク・グループのディスクをONLINEに設定します。
    SQL> ALTER DISKGROUP disk_group_name ONLINE DISKS IN FAILGROUP \
cell_name WAIT;

    ノート:

    • ディスクがすでに強制削除されているため、コマンドが失敗する場合は、ディスクをOracle ASMディスク・グループに強制追加する必要があります。

    • グリッド・ディスクのasmmodestatus属性とasmdeactivationoutcome属性は、ALTER DISKGROUP文が完了するまで正しく報告されません。

  4. ALTER CELLコマンドを使用して、セルを再構成します。

    次の例では電子メール通知を、指定した通知ポリシーに従ってストレージ・サーバー管理者に通知メッセージを送信するように構成します。

    CellCLI> ALTER CELL                                     -
           mailServer='mail_relay.example.com',            -
           smtpFromAddr='john.doe@example.com',         -
           smtpToAddr='jane.smith@example.com',         -
           notificationPolicy='critical,warning,clear', -
           notificationMethod='mail,snmp'
  5. I/Oリソース管理(IORM)プランを再作成します。
  6. メトリックしきい値を再作成します。

関連トピック

親トピック: Oracle Exadata System Softwareのレスキュー手順の使用

3.9.4 Oracle Exadata Database Machineエイス・ラックのストレージ・サーバーのレスキュー後の構成

エイス・ラック・システムに含まれるストレージ・サーバーの場合は、レスキューの成功後に次のステップを使用してセルを構成する必要があります。

Oracle Exadata System Softwareリリース11.2.3.3以降では、セル・レスキュー後に追加のステップは必要ありません。

  1. 別のストレージ・サーバーにある/opt/oracle.SupportTools/resourcecontrolユーティリティを、リカバリしたサーバーの/opt/oracle.SupportTools/resourcecontrolディレクトリにコピーします。
  2. ユーティリティに対して適切な権限が設定されていることを確認します。
    # chmod 740 /opt/oracle.SupportTools/resourcecontrol
  3. 現在の構成を確認します。
    # /opt/oracle.SupprtTools/resourcecontrol -show

Validated hardware and OS. Proceed.
Number of cores active: 6
Number of harddisks active: 6
Number of flashdisks active: 8

    エイス・ラック構成の場合、出力はハードウェア・モデルによって異なります。

    • X3ストレージ・サーバー: 6個のアクティブCPU、6個のハード・ディスクおよび8個のフラッシュ・ディスクが有効になっている必要があります
    • X4ストレージ・サーバー: 6個のアクティブCPUコア、6個のハード・ディスクおよび8個のフラッシュ・ディスクが有効になっている必要があります
    • X5 HCストレージ・サーバー: 8個のアクティブCPUコア、6個のハード・ディスクおよび2個のフラッシュ・ディスクが有効になっている必要があります
    • X5 EFストレージ・サーバー: 8個のアクティブCPUコアおよび4個のフラッシュ・ディスクが有効になっている必要があります
    • X6 HCストレージ・サーバー: 10個のアクティブCPUコア、6個のハード・ディスクおよび2個のフラッシュ・ディスクが有効になっている必要があります
    • X6 EFストレージ・サーバー: 10個のアクティブCPUコアおよび4個のフラッシュ・ディスクが有効になっている必要があります
    • X7 HCストレージ・サーバー: 10個のアクティブCPUコア、6個のハード・ディスクおよび2個のフラッシュ・ディスクが有効になっている必要があります
    • X7 EFストレージ・サーバー: 10個のアクティブCPUコアおよび4個のフラッシュ・ディスクが有効になっている必要があります
    • X8 HCストレージ・サーバー: 16個のアクティブCPUコア、6個のハード・ディスクおよび2個のフラッシュ・ディスクが有効になっている必要があります
    • X8 EFストレージ・サーバー: 16個のアクティブCPUコアおよび4個のフラッシュ・ディスクが有効になっている必要があります
  4. この構成のすべてのコアおよびディスクが使用可能と表示されている場合は、エイス・ラック構成を有効にします。
    CellCLI> ALTER CELL eighthRack=true

親トピック: Oracle Exadata System Softwareのレスキュー手順の使用

3.9.5 損傷したCELLBOOT USBフラッシュ・ドライブの再作成

CELLBOOT USBフラッシュ・ドライブの紛失または損傷が発生した場合、次の手順を使用して新しいドライブを作成できます。

ノート:

Oracle Exadata Storage Server Softwareリリース12.1.2.1.0以上を実行するマシン用のUSBフラッシュ・ドライブを作成するには、Oracle Linux 6を実行するマシンが必要です。

  1. rootユーザーとしてセルにログインします。
  2. M.2システム・デバイスを含まないX6以前のサーバーのみ:
    1. 新しいUSBフラッシュ・ドライブを取り付けます。
      このフラッシュ・ドライブには、少なくとも1GBから最大8GBの容量が必要です。
    2. システムから他のUSBフラッシュ・ドライブを取り外します。
  3. 次のコマンドを実行します。
    # cd /opt/oracle.SupportTools
# ./make_cellboot_usb -rebuild -verbose

親トピック: Oracle Exadata System Softwareのレスキュー手順の使用

3.10 「ストレージ・セルの既存のエラスティック構成の変更」

Exadata Database Machineの容量はエラスティック構成を使用することで変更できます。

関連トピック

親トピック: Oracle Exadata Storage Serverの保守

3.10.1 セル・ノードの追加

このシナリオでは、ディスク・グループを含む既存のExadata Database Machineに新しいストレージ・サーバー(またはセル)を追加する必要があります。

  1. これが新しいストレージ・サーバーである場合、次のステップを実行します。
    1. 目的のストレージ・グリッドで新しいストレージ・サーバーを利用できるようにするために、必要なすべてのケーブル接続要件を完了します。

      Oracle Exadata Database Machineインストレーションおよび構成ガイドを参照してください。

    2. 適切なOracle Exadata System Softwareイメージを使用してストレージ・サーバーをイメージ化し、IPアドレスの入力を求めるプロンプトが表示されたら適切な情報を入力します。
    3. ステップ2にスキップします。
  2. ラック内の既存のストレージ・サーバーをRDMAネットワーク・ファブリック・ネットワーク内の別のクラスタに割り当てる場合は、追加するストレージ・サーバーのRDMAネットワーク・ファブリック・インタフェース(ib0とib1や、re0とre1など)に割り当てられているIPアドレスをノートにとります。

    すべてのOracle RACノードの/etc/oracle/cell/network-config/cellip.oraファイルに、IPアドレスを追加します。

    1. cd /etc/oracle/cell/network-config
    2. cp cellip.ora cellip.ora.orig
    3. cp cellip.ora cellip.ora-bak
    4. /etc/oracle/cell/network-config/cellip.ora-bakに新しいエントリを追加します。
    5. 次のコマンドを使用して、編集後のファイルをすべてのデータベース・ノードのcellip.oraファイルにコピーします。ここで、database_nodesは、クラスタ内の各データベース・サーバーの名前が個別の行として含まれたファイルを指します。
      /usr/local/bin/dcli -g database_nodes -l root -f cellip.ora-bak -d
 /etc/oracle/cell/network-config/cellip.ora
  3. 既存のストレージ・サーバーにOracle Auto Service Request (ASR)のアラートが設定されていた場合は、追加するストレージ・サーバー用にセルのOracle ASRアラートを構成します。
    1. いずれかの既存のストレージ・サーバーから、セルのsnmpsubscriber属性をリストします。
      cellcli -e LIST CELL ATTRIBUTES snmpsubscriber
    2. 次のコマンドをcelladminユーザーとして実行して、同じsnmpsubscriber属性値を新しいストレージ・サーバーに適用します。この際、snmpsubscriberを前のコマンドの値に置き換えてください。
      cellcli -e "ALTER CELL snmpsubscriber=snmpsubscriber"
    3. 既存のストレージ・サーバーから、セルのアラートを構成するために必要なセルの属性をリストします。
      cellcli -e LIST CELL ATTRIBUTES
 notificationMethod,notificationPolicy,mailServer,smtpToAddr,smtpFrom,
 smtpFromAddr,smtpUseSSL,smtpPort
    4. 次のコマンドをcelladminユーザーとして実行して、同じ値を新しいストレージ・サーバーに適用します。この際、プレースホルダを既存のストレージ・サーバーから検出された値に置き換えてください。
      cellcli -e "ALTER CELL
 notificationMethod='notificationMethod',
 notificationPolicy='notificationPolicy',
 mailServer='mailServer',
 smtpToAddr='smtpToAddr',
 smtpFrom='smtpFrom',
 smtpFromAddr='smtpFromAddr',
 smtpUseSSL=smtpUseSSL,
 smtpPort=smtpPort"
  4. 必要に応じて、追加するセルにセル・ディスクを作成します。
    1. セルにcelladminとしてログインし、セル・ディスクのリストを表示します。
      cellcli -e LIST CELLDISK
    2. セル・ディスクがメディア・タイプに存在していない場合は、セル・ディスクを作成します。
      cellcli -e CREATE CELLDISK ALL
    3. システムにPMEMデバイスがある場合は、デフォルトでPMEMログが作成されていたことを確認します。
      cellcli –e LIST PMEMLOG

      PMEMログの名前を確認しておきます。cellnodename_PMEMLOGのような名前で、ステータスがnormalになっていることを確認してください。

      PMEMログが存在していない場合は作成します。

      cellcli -e CREATE PMEMLOG ALL
    4. デフォルトでフラッシュ・ログが作成されたことを確認します。
      cellcli –e LIST FLASHLOG

      フラッシュ・ログの名前が表示されます。cellnodename_FLASHLOGのような名前で、ステータスがnormalになっていることを確認してください。

      フラッシュ・ログが存在しない場合は作成します。

      cellcli -e CREATE FLASHLOG ALL
    5. システムにPMEMデバイスがある場合は、現在のPMEMキャッシュ・モードを確認して、既存のセルのPMEMキャッシュ・モードと比較します。
      cellcli -e LIST CELL ATTRIBUTES pmemcachemode

      既存のセルのPMEMキャッシュ・モードと一致するようにPMEMキャッシュ・モードを変更するには、次の手順を実行します。

      1. PMEMキャッシュが存在し、セルがWriteBack PMEMキャッシュ・モードの場合は、最初にPMEMキャッシュをフラッシュしておく必要があります。 

        cellcli –e ALTER PMEMCACHE ALL FLUSH

        コマンドが戻るまで待機します。

        PMEMキャッシュ・モードがWriteThroughの場合は、最初にキャッシュをフラッシュする必要はありません。

      2. PMEMキャッシュを削除します。

        cellcli -e DROP PMEMCACHE ALL

      3. PMEMキャッシュ・モードを変更します。

        pmemCacheMode属性の値は、writebackまたはwritethroughのどちらかです。この値は、クラスタ内のその他のストレージ・セルのPMEMキャッシュ・モードと一致する必要があります。 

        cellcli -e "ALTER CELL PMEMCacheMode=writeback_or_writethrough"

      4. PMEMキャッシュを再作成します。

        cellcli -e CREATE PMEMCACHE ALL
    6. 現在のフラッシュ・キャッシュ・モードを、既存セルのフラッシュ・キャッシュ・モードと比較します。
      cellcli -e LIST CELL ATTRIBUTES flashcachemode

      フラッシュ・キャッシュ・モードを変更して既存のセルのフラッシュ・キャッシュ・モードに一致させるには、次の手順を実行します。

      1. フラッシュ・キャッシュが存在し、セルがWriteBackフラッシュ・キャッシュ・モードの場合、フラッシュ・キャッシュを最初にフラッシュする必要があります。 

        cellcli –e ALTER FLASHCACHE ALL FLUSH

        コマンドが戻るまで待機します。

      2. フラッシュ・キャッシュを削除します。

        cellcli -e DROP FLASHCACHE ALL

      3. フラッシュ・キャッシュ・モードを変更します。

        flashCacheMode属性の値は、writebackまたはwritethroughのいずれかです。クラスタ内の他のストレージ・セルと同じフラッシュ・キャッシュ・モードになるように、値を設定する必要があります。 

        cellcli -e "ALTER CELL flashCacheMode=writeback_or_writethrough"

      4. フラッシュ・キャッシュを作成します。

        cellcli -e CREATE FLASHCACHE ALL
  5. 追加するセルのグリッド・ディスクを作成します。
    1. 既存のセルからの既存のグリッド・ディスクのsizeとcachingpolicy属性を問い合せます。
      CellCLI> LIST GRIDDISK ATTRIBUTES name,asmDiskGroupName,cachingpolicy,size,offset
    2. 前述のコマンドで検出された各ディスク・グループについて、クラスタに追加する新しいセルのグリッド・ディスクを作成します。

      前述のコマンドで報告されたその特定のディスク・グループの既存のグリッド・ディスクのsizeとcachingpolicy属性を一致させます。既存のセルと同様のレイアウトおよびパフォーマンス特性になるように、グリッド・ディスクはオフセットの昇順で作成する必要があります。たとえば、LIST GRIDDISKコマンドで次のような出力が返されたとします。 

      DATAC1          default         2.15625T        32M
DBFS_DG         default         33.796875G      2.695465087890625T
RECOC1          none            552.109375G     2.1562957763671875T

      グリッド・ディスクを作成するときには、DATAC1、RECOC1、DBFS_DGの順序で次のコマンドを使用して作成します。 

      cellcli -e CREATE GRIDDISK ALL HARDDISK
 PREFIX=matching_prefix_of_the_corresponding_existing_diskgroup,
 size=size_followed_by_G_or_T,
 cachingPolicy=\'value_from_command_above_for_this_disk_group\',
 comment =\"Cluster cluster_name diskgroup diskgroup_name\"

      注意:

      次のように、EXACTサイズを単位(TまたはG)とともに指定してください
  6. 各Oracle RACノードにログインし、新しく作成されたグリッド・ディスクがOracle RACノードから参照できることを確認します。

    次の例では、Grid_homeは、Oracle Grid Infrastructureソフトウェアがインストールされているディレクトリを指します。 

    $Grid_home/bin/kfod op=disks disks=all | grep cellName_being_added

    kfodコマンドでは、前述のステップ5で作成したすべてのグリッド・ディスクがリストされる必要があります。

  7. 新しく作成されたグリッド・ディスクをそれぞれの既存のOracle ASMディスク・グループに追加します。

    この例では、comma_separated_disk_namesは、disk_group_nameに対応するステップ5のディスク名を指します。 

    SQL> ALTER DISKGROUP disk_group_name ADD DISK 'comma_separated_disk_names';

    このコマンドはデフォルトの電源レベルでOracle ASMリバランス操作を開始します。

  8. GV$ASM_OPERATIONの問合せにより、リバランスの進捗状況を監視します。
    SQL> SELECT * FROM GV$ASM_OPERATION;

    リバランスが完了すると、Oracle RACクラスタへのセルの追加は完了です。

  9. Oracle EXAchkの最新バージョンをダウンロードして実行し、結果の構成にExadata Database Machineの最新のベスト・プラクティスが実装されたことを確認します。

親トピック: ストレージ・セルの既存のエラスティック構成の変更

3.10.2 エイス・ラック・クラスタへの新しいストレージ・サーバーの追加

既存のExadata Database Machine X7以降のエイス・ラックに新しいExadata Database Machine X7以降のストレージ・サーバーを追加するには、次のステップを実行します。

  1. PMEMキャッシュとPMEMログを削除します(構成されている場合)。
    $ cellcli -e drop pmemcache all
$ cellcli -e drop pmemlog all
  2. 新しいストレージ・サーバーで、フラッシュ・キャッシュ、フラッシュ・ログおよびセル・ディスクを削除します。
    cellcli -e drop flashcache all
cellcli -e drop flashlog all
cellcli -e drop celldisk all
  3. 新しいストレージ・サーバーで、eighthrack属性を有効にします。
    cellcli -e alter cell eighthRack=true
  4. 新しいストレージ・サーバーで、セル・ディスクを作成します。
    cellcli -e create celldisk all
  5. 新しいストレージ・サーバーで、フラッシュ・ログを作成します。
    cellcli -e create flashlog all
  6. 新しいストレージ・サーバーでPMEMログを作成します(該当する場合)。
    cellcli -e create pmemlog all
  7. 既存のストレージ・サーバーで、セル属性flashcachemodeの値を取得します。
    cellcli -e list cell attributes flashcachemode

    新しいストレージ・サーバー上のflashcachemode属性はデフォルトでWriteThroughに設定されます。すべてのストレージ・サーバーでは、同じflashcachemode属性が設定されている必要があります。

    既存のストレージ・サーバーがWriteBackモードを使用している場合は、次に示すように、新しいストレージ・サーバーで属性flashcachemodeを変更する必要があります。 

    cellcli -e alter cell flashcachemode=writeback
  8. 新しいストレージ・サーバーで、フラッシュ・キャッシュを作成します。
    cellcli -e create flashcache all
  9. ストレージ・サーバーでPMEMキャッシュを使用している場合は、セル属性pmemcachemodeの値を取得します。
    cellcli -e list cell attributes pmemcachemode

    新しいストレージ・サーバーのpmemcachemode属性は、デフォルトでWriteThroughに設定されます。pmemcachemode属性は、すべてのストレージ・サーバーで同じ設定になっている必要があります。

    既存のストレージ・サーバーでWriteBackモードを使用している場合は、次に示すように、新しいストレージ・サーバーの属性pmemcachemodeを変更する必要があります。 

    cellcli -e alter cell pmemcachemode=writeback
  10. ストレージ・サーバーでPMEMキャッシュを使用する場合は、新しいストレージ・サーバーでPMEMキャッシュを作成します。
    cellcli -e create pmemcache all
  11. 既存のストレージ・サーバーで、グリッド・ディスクの構成に関する情報を取得します。
    cellcli -e list griddisk attributes name,offset,size,cachingpolicy
  12. 新しいストレージ・サーバーで、グリッド・ディスクを作成します(既存のストレージ・サーバーの構成と一致するよう一連のグリッド・ディスクごとに手順を繰り返します)。

    次のコマンドでは、斜体文字を、ステップ11で取得した対応する値に置き換えます。 

    cellcli -e CREATE GRIDDISK ALL HARDDISK PREFIX=matching_prefix_of_the_
corresponding_existing_diskgroup, size=size_followed_by_G_or_T, 
cachingPolicy=\'value_from_command_above_for_this_disk_group\', 
comment =\"Cluster cluster_name diskgroup diskgroup_name\"
  13. 新しいストレージ・サーバーで、(ステップ11で取得した情報と比較することにより)グリッド・ディスクの構成が既存のストレージ・サーバーのグリッド・ディスクの構成と同じであることを検証します。
    cellcli -e list griddisk attributes name,offset,size,cachingpolicy
  14. (X2からX8のサーバーのみ)パーティション・キー(pkey)を実装した環境の場合は、RDMAネットワーク・ファブリック・インタフェース用のpkeyを構成します。このタスクについては、「ExadataでのOVM RACクラスタ間のInfiniBandパーティションの実装」(My Oracle SupportのドキュメントID 2075398.1)のステップ6を参照してください。
  15. 新しいストレージ・サーバーでは、InfiniBandネットワーク・ファブリックまたはRoCEネットワーク・ファブリックの両方のポートのIPアドレスを特定します。
    cellcli -e list cell attributes name,ipaddress1,ipaddress2
  16. すべてのデータベース・サーバーの/etc/oracle/cell/network-config/cellip.oraファイルに、ステップ15のIPアドレスを追加します。

    クラスタ内の任意のデータベース・サーバー上で次のステップを実行します。

    1. cd /etc/oracle/cell/network-config
    2. cp cellip.ora cellip.ora.orig
    3. cp cellip.ora cellip.ora-bak
    4. /etc/oracle/cell/network-config/cellip.ora-bakに新しいエントリを追加します。
    5. 次のコマンドを使用して、編集後のファイルをすべてのデータベースのcellip.oraファイルにコピーします。ここで、database_nodesは、クラスタ内の各データベース・サーバーの名前が個別の行として含まれたファイルを指します。
      /usr/local/bin/dcli -g database_nodes -l root -f cellip.ora-bak -d /etc/oracle/cell/network-config/cellip.ora
  17. 任意のOracle ASMインスタンスに接続し、新しいストレージ・サーバーのグリッド・ディスクが検出可能であることを確認してください。
    SQL> set pagesize 30
SQL> set linesize 132
SQL> col path format a70
SQL> SELECT inst_id,path FROM gv$asm_disk WHERE header_status='CANDIDATE' 
  2> ORDER BY inst_id,path;

INST_ID    PATH
---------- ----------------------------------------------------------------------
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_00_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_01_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_02_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_03_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_04_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_05_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_00_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_01_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_02_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_03_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_04_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_05_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_00_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_01_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_02_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_03_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_04_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_05_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_00_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_01_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_02_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_03_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_04_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_05_celadm11
  18. Oracle ASMインスタンスの1つに接続し、新規ディスクを既存のディスク・グループに追加します。
    SQL> ALTER DISKGROUP datac1 ADD DISK ‘o/192.168.17.235;192.168.17.
236/DATAC1*’;
SQL> ALTER DISKGROUP recoc1 ADD DISK ‘o/192.168.17.235;192.168.17.
236/RECOC1*’;

    ノート:

    ディスクの追加によってトリガーされたリバランス操作は、デフォルトのOracle Maximum Availability Architecture (MAA)ベスト・プラクティス電源(4になります)で実行されます。アプリケーションのサービス・レベルのパフォーマンスに問題がない場合、高速リバランスのために電源を大きくすることを検討します。
  19. 障害グループごとにディスク数のレポートを取得します。High Capacity (HC) Storage Serverでは障害グループごとに6台のディスクが予想され、Extreme Flash (EF) Storage Serverでは障害グループごとに4台のディスクが予想されます。
    SQL> SELECT d.group_number,dg.name,failgroup,mode_status,COUNT(*)
  2> FROM v$asm_disk d,v$asm_diskgroup dg
  3> WHERE d.group_number=dg.group_number
  4> AND failgroup_type='REGULAR'
  5> GROUP BY d.group_number,dg.name,failgroup,mode_status;

GROUP_NUMBER NAME                FAILGROUP            MODE_ST COUNT(*)
------------ ------------------- -------------------- ------- --------
           1 DATAC1              CELADM08             ONLINE         6
           1 DATAC1              CELADM09             ONLINE         6
           1 DATAC1              CELADM10             ONLINE         6
           1 DATAC1              CELADM11             ONLINE         6
           2 RECOC1              CELADM08             ONLINE         6
           2 RECOC1              CELADM09             ONLINE         6
           2 RECOC1              CELADM10             ONLINE         6
           2 RECOC1              CELADM11             ONLINE         6
  20. 既存のストレージ・サーバーにOracle Auto Service Request (ASR)のアラートが設定されていた場合は、追加するストレージ・サーバー用にセルのOracle ASRアラートを構成します。
    1. いずれかの既存のストレージ・サーバーから、セルのsnmpsubscriber属性をリストします。
      cellcli -e LIST CELL ATTRIBUTES snmpsubscriber
    2. 次のコマンドをcelladminユーザーとして実行して、同じsnmpsubscriber属性値を新しいストレージ・サーバーに適用します。この際、snmpsubscriberを前のコマンドの値に置き換えてください。
      cellcli -e "ALTER CELL snmpsubscriber=snmpsubscriber"
    3. 既存のストレージ・サーバーから、セルのアラートを構成するために必要なセルの属性をリストします。
      cellcli -e LIST CELL ATTRIBUTES
 notificationMethod,notificationPolicy,mailServer,smtpToAddr,smtpFrom,
 smtpFromAddr,smtpUseSSL,smtpPort
    4. 次のコマンドをcelladminユーザーとして実行して、同じ値を新しいストレージ・サーバーに適用します。この際、プレースホルダを既存のストレージ・サーバーから検出された値に置き換えてください。
      cellcli -e "ALTER CELL
 notificationMethod='notificationMethod',
 notificationPolicy='notificationPolicy',
 mailServer='mailServer',
 smtpToAddr='smtpToAddr',
 smtpFrom='smtpFrom',
 smtpFromAddr='smtpFromAddr',
 smtpUseSSL=smtpUseSSL,
 smtpPort=smtpPort"

親トピック: ストレージ・セルの既存のエラスティック構成の変更

3.10.3 OEDACLIを使用したストレージ・セルの追加

OEDACLIには、様々な構成のエラスティック・ストレージ拡張(ベアメタル、単一のOracle VMまたは複数のOracle VMなど)を実行するためのインタフェースがあります。

OEDACLIによって、ストレージ・サーバーで必要なすべてのオブジェクトが作成され、新規のグリッド・ディスクがディスク・グループに追加されます。既存のストレージ・サーバーの1つは、新しいストレージ・サーバーの構成のガイドとして機能します。トリガーされるリバランス操作は、複数のストレージ・サーバーを追加した場合でも1回のみです。新しいサーバーのグリッド・ディスクは、構成したすべてのクラスタのディスク・グループに追加されます。

前提条件

  • すべての新しいストレージ・サーバーは物理ラックに設置されていて接続されている必要があります。
  • すべての新しいストレージ・サーバーは、管理およびRDMAネットワーク・ファブリックの構成が実行されている必要があります。
  • OEDACLIは、データベース・サーバー(ベアメタルまたはゲスト・ドメイン)およびストレージ・サーバーにネットワーク・アクセスできるマシンから実行する必要があります。
  1. 新しいOEDA XML構成ファイルを生成します。このファイルは、環境内で使用している現在のデータベース・サーバーとストレージ・サーバーの完全リストを反映しています。
    OEDAのDISCOVERコマンドを使用します。dirnameは、通常、OEDACLIのインストール・ディレクトリです。host_names_listは、検出するノードのカンマ区切りまたはスペース区切りのリストです(たとえば、'dbnode1,dbnode2,celadm01,celadm02')。 
    DISCOVER ES hostnames='host_names_list' location='dirname'

    Oracle VMが複数ある環境の場合は、このコマンドによりグローバルXML構成ファイルが生成されます。このファイルには、すべてのクラスタの情報とクラスタごとに1つのXML構成ファイルが含まれています。次のコマンドには、クラスタ固有の構成ファイルではなく、グローバルXML構成ファイルを使用する必要があります。

  2. OEDACLIを使用してXML構成ファイルを更新するOEDACLIスクリプトを作成します。

    追加するセルごとに、このスクリプトに必要な項目は次のとおりです。

    • 現在の構成に含まれる1つのセルの名前(ホスト名)。オブジェクト(セル・ディスク、グリッド・ディスク、フラッシュ・キャッシュなど)の作成の際に参照として使用されます
    • 管理およびRDMAネットワーク・ファブリック・インタフェースの名前(ホスト名)とIPアドレス。
    • ラック番号。相互接続されていない環境の場合は1になります。
    • ULOCは、物理ラックでの場所です。これはストレージ拡張には使用されませんが、『Oracle Exadata Database Machineシステム概要』の第2部にある配線図の参照情報に応じて値を選択してください。

    次のコマンドをadd_cell_script.cmdという名前のファイルに保存します。この例では、2台の新しいストレージ・サーバー(celadm04およびceladm05)を追加します。 

    CLONE NEWCELL SRCNAME=celadm01 tgtname=celadm04
SET ADMINNET NAME=celadm04, IP=203.0.113.35
SET PRIVNET NAME1=celadm04-priv1, IP1=192.168.216.235, NAME2=celadm04-priv2, IP2=192.168.216.236
SET ILOMNET NAME=celadm04-ilom, IP=203.0.113.135
SET RACK NUM=1, ULOC=39
SAVE ACTION FORCE
CLONE NEWCELL SRCNAME=celadm01 tgtname=celadm05
SET ADMINNET NAME=celadm05, IP=203.0.113.36
SET PRIVNET NAME1=celadm05-priv1, IP1=192.168.216.221, NAME2=celadm05-priv2, IP2=192.168.216.222
SET ILOMNET NAME=celadm05-ilom, IP=203.0.113.136
SET RACK NUM=1, ULOC=14
SAVE ACTION FORCE
SAVE FILE
  3. スクリプトadd_cell_script.cmdを実行します。

    この例のoeda_xml_fileは、最初のステップで生成したファイルです。また、add_cell_script.cmdは、前のステップで作成したスクリプトです。 

    $ oedacli -c oeda_xml_file -f add_cell_script.cmd

    このスクリプトを実行すると、OEDA XML構成ファイルが更新され、新しいストレージ・サーバーに関連するディレクティブと属性が追加されます。いずれのコンポーネント(ストレージ・サーバーまたはデータベース・サーバー)にもアクションはトリガーされません。

  4. 新しいストレージ・サーバー(セル)を構成するためのOEDACLIスクリプトを作成します。

    このスクリプトでは、次の設定を使用します。

    • リバランスのためのOracle ASM指数制限は、4に設定されています。これは、Oracle MAAのベスト・プラクティスです。
    • WAITオプションはFALSEに設定します。これは、ディスクのリバランス操作がクラスタ内のすべてのディスク・グループで並行実行されることを意味します。同時に実行可能な未処理のリバランス数は、データベース・サーバーの数に制限されます。WAITをTRUEに設定すると、各リバランス操作が順次実行されます。

    次のコマンドをconfig_cell_script.cmdという名前のファイルに保存します。この例では、クラスタ名はq1-vm01です。これを目的のクラスタ名に置き換えます。また、サンプルのセル名(celadm04,celadm05)を独自のものに置き換えます。 

    ALTER CLUSTER ADDCELLS='celadm04,celadm05' power=4, wait=false WHERE clustername='q1-vm01'
SAVE ACTION
MERGE ACTIONS
DEPLOY ACTIONS
SAVE FILE
  5. スクリプトconfig_cell_script.cmdを実行します。

    この例のoeda_xml_fileは、最初のステップで生成したファイルです。また、config_cell_script.cmdは、前のステップで作成したスクリプトです。 

    $ oedacli -c oeda_xml_file -f config_cell_script.cmd

    このスクリプトを実行すると、フラッシュ・キャッシュ、フラッシュ・ログ、セル・ディスクおよびグリッド・ディスクが作成されます。さらに、ディスクがOracle ASMディスク・グループに追加され、ストレージ・サーバーがクラスタに追加されます。

親トピック: ストレージ・セルの既存のエラスティック構成の変更

3.10.4 既存のExadataストレージ・グリッドの拡張

このシナリオでは、Exadataラック内にExadataストレージ・セルが存在し、最も拡張の必要なExadataストレージ・グリッドにストレージ・セルを追加します。

  1. 現在のクラスタからストレージ・セルを廃止します。これを実行するには、「既存のディスク・グループまたはストレージ・グリッドからのストレージ・サーバーの削除」の手順に従ってください。
  2. 目的のExadataストレージ・グリッドにストレージ・セルを追加します。これを実行するには、「セル・ノードの追加」の手順に従ってください。
  3. 最新のexachkをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。

親トピック: ストレージ・セルの既存のエラスティック構成の変更

3.10.5 既存のディスク・グループまたはストレージ・グリッドからのストレージ・サーバーの削除

既存のOracle Exadataラックからストレージ・サーバーを削除できます。

  1. Oracle Automatic Storage Management (Oracle ASM)から削除するストレージ・サーバーに属しているディスクを削除します。

    ノート:

    Exadata Database Machine VMデプロイメントでは、すべてのOracle VMクラスタから次のサブステップを実行する必要があります。
    1. クラスタ内の任意のノードにログインします。
    2. ターゲット・ストレージ・サーバーのクラスタで使用するグリッド・ディスクのリストを問い合せます。
      Grid_home/bin/asmcmd  lsdsk --suppressheader | grep cellName_being_removed | awk -F'/' '{print $NF}'

      ノート:

      削除するストレージ・サーバーのディスクが含まれているすべてのディスク・グループ内の使用可能な空き領域が、そのディスク・グループに割り当てられた記憶域の少なくとも15%であることを確認してください。
    3. 前述のコマンドで返されたOracle ASMディスクをそれぞれのディスク・グループから削除します。
      SQL> ALTER DISKGROUP diskgroup_name DROP DISKS IN FAILGROUP cellName_being_removed;
    4. このディスク削除操作により、デフォルトの電源レベルでリバランス操作が開始されます。次のコマンドを使用して、リバランスを監視します。
      SQL> SELECT * FROM gv$asm_operation;

      リバランスが完了するまで、つまり、gv$asm_operationから行が返されなくなるまで待ちます。

    5. すべてのディスク・グループが、削除するストレージ・サーバーのディスクを参照していないことを確認します。
      SQL> SELECT path, name, header_status, mode_status, mount_status, state,
 failgroup FROM v$asm_disk ORDER BY path;

      削除するストレージ・サーバーに属するすべてのディスクのheader_status列が、FORMERと表示されている必要があります。

      注意:

      Exadata Oracle VMデプロイメントでは、すべてのOracle VMクラスタから前述のサブステップを実行する必要があります。
  2. 削除するストレージ・サーバーをクリーン・アップします。

    ストレージ・サーバーにcelladminとしてログインし、次のコマンドを実行します。各グリッド・ディスクに対して次のコマンドを実行します。

    1. グリッド・ディスクを削除します。
      cellcli -e drop griddisk all prefix=prefix_of_the_grid_disk
    2. フラッシュ・キャッシュが存在していて、ストレージ・サーバーがWriteBackフラッシュ・キャッシュ・モードの場合、フラッシュ・キャッシュは削除の前にフラッシュしておく必要があります。
      cellcli -e alter flashcache all flush

      コマンドが戻るまで待機します。

    3. フラッシュ・キャッシュを削除します。
      cellcli -e drop flashcache all
    4. セル・ディスクを削除します。
      cellcli -e drop celldisk all

      データを安全に消去するには、DROP CELLDISKコマンドをeraseオプションを指定して実行するか、DROP CELLコマンドをeraseオプションを指定して実行します。

      DROP CELLコマンドの下の表内に消去操作の所要時間が表示されます。

  3. クラスタ内のすべてのデータベース・サーバー・ノードで、削除するストレージ・サーバーのエントリを/etc/oracle/cell/network-config/cellip.oraから削除します。
    クラスタ内の任意のデータベース・サーバー・ノードで次のステップを実行します。
    1. cellip.oraファイルのバックアップ・コピーを作成します。
      cd /etc/oracle/cell/network-config
cp cellip.ora cellip.ora.orig
cp cellip.ora cellip.ora-bak
    2. 削除するストレージ・サーバーのエントリを/etc/oracle/cell/network-config/cellip.ora-bakから削除します。
    3. dcliを使用して、更新したcellip.ora-bakファイルを別のデータベース・サーバーにコピーします。

      次のコマンドのdatabase_nodesは、クラスタ内の各データベース・サーバーの名前を格納しているファイルを表します。データベース・サーバーの名前は、それぞれファイル内の個別の行に記載します。 

      /usr/local/bin/dcli -g database_nodes -l root -f cellip.ora-bak -d 
/etc/oracle/cell/network-config/cellip.ora
  4. Oracle EXAchkの最新バージョンをダウンロードして実行し、結果の構成にExadata Database Machineの最新のベスト・プラクティスが実装されたことを確認します。

親トピック: ストレージ・セルの既存のエラスティック構成の変更

3.10.6 OEDACLIを使用したストレージ・サーバーの削除

OEDACLIには、様々な構成(ベアメタル、単一のOracle VMまたは複数のOracle VMなど)のストレージ・サーバーを削除するためのインタフェースがあります。

ディスク・グループからディスクを削除して、ストレージ・サーバーのオブジェクトを削除する手順は、わずかな数のコマンドで実施します。トリガーされるリバランス操作は、削除するストレージ・セルの数に関係なく1つのみです。

前提条件

  • 有効なOEDA XML構成ファイル(拡張する環境内で使用している計算ノードとストレージ・セルの完全リストを反映しているもの)。このタスクの最初のステップでは、新しいOEDA XML構成ファイルを生成することで、現在の構成が確実に使用されるようにしています。
  • OEDACLIは、データベース・サーバー(ベアメタルまたはゲスト・ドメイン)およびストレージ・サーバーにネットワーク・アクセスできるマシンから実行する必要があります。
  1. 新しいOEDA XML構成ファイルを生成します。このファイルは、環境内で使用している現在のデータベース・サーバーとストレージ・サーバーの完全リストを反映しています。
    OEDAのDISCOVERコマンドを使用します。dirnameは、通常、OEDACLIのインストール・ディレクトリです。host_names_listは、検出するノードのカンマ区切りまたはスペース区切りのリストです(たとえば、'dbnode1,dbnode2,celadm01,celadm02')。 
    DISCOVER ES hostnames='host_names_list' location='dirname'

    Oracle VMが複数ある環境の場合は、このコマンドによりグローバルXML構成ファイルが生成されます。このファイルには、すべてのクラスタの情報とクラスタごとに1つのXML構成ファイルが含まれています。次のコマンドには、クラスタ固有の構成ファイルではなく、グローバルXML構成ファイルを使用する必要があります。

  2. OEDACLIを使用してXML構成ファイルを更新するOEDACLIスクリプトを作成します。

    この例では、WAITオプションをTRUEに設定しています。これは、各リバランス操作が順次実行されることを意味します。最後のディスク・グループのリバランスが完了すると、構成からストレージ・サーバーが削除されます。

    次のコマンドをdrop_cell_cluster.cmdという名前のファイルに保存します。この例では、2台のストレージ・サーバー(celadm04およびceladm05)を削除します。この例では、クラスタ名q1-vm01が使用されています。この名前は、目的のクラスタ名に置き換える必要があります。 

    ALTER CLUSTER DROPCELLS='celadm04,celadm05' power=4, wait=true \
WHERE clustername=q1-vm01
SAVE ACTION
MERGE ACTIONS
DEPLOY ACTIONS
SAVE FILE
  3. スクリプトdrop_cell_cluster.cmdを実行します。

    この例のoeda_xml_fileは、最初のステップで生成したファイルです。また、drop_cell_cluster.cmdは、前のステップで作成したスクリプトです。 

    $ oedacli -c oeda_xml_file -f drop_cell_cluster.cmd

    このスクリプトを実行すると、クラスタ内で構成されているすべてのOracle ASMディスク・グループからグリッド・ディスクが削除され、セルの構成が解除されます(フラッシュ・キャッシュ、フラッシュ・ログ、セル・ディスク、グリッド・ディスクなどのオブジェクトが削除されます)。

  4. ストレージ・サーバー(セル)をOEDA XML構成ファイルから削除するOEDACLIスクリプトを作成します。

    次のコマンドをdrop_cell_xml.cmdという名前のファイルに保存します。 

    DELETE NEWCELL WHERE SRCNAME='celadm04 celadm05'
SAVE ACTION FORCE
SAVE FILE
  5. スクリプトdrop_cell_xml.cmdを実行します。

    この例のoeda_xml_fileは、最初のステップで生成したファイルです。また、drop_cell_xml.cmdは、前のステップで作成したスクリプトです。 

    $ oedacli -c oeda_xml_file -f drop_cell_xml.cmd

    このスクリプトを実行すると、OEDA XML構成ファイルからストレージ・サーバーの情報が削除されます。

親トピック: ストレージ・セルの既存のエラスティック構成の変更

3.11 ディスク・コントローラのバッテリの管理

この項は、バッテリを使用するX6より前のExadataシステムにのみ適用されます。より新しいシステムには、バッテリではなくスーパー・キャパシタのCVPM02 (Cache Vault)が備えられています。

親トピック: Oracle Exadata Storage Serverの保守

3.11.1 ディスク・コントローラのバッテリについて

Oracle Exadata Storage Serverおよびデータベース・サーバーのディスク・コントローラには、書込みパフォーマンスを高速化するバッテリ・バックアップ式の書込みキャッシュがあります。

ノート:

これは、バッテリを使用するX6より前のExadataシステムにのみ適用されます。より新しいシステムには、バッテリではなくスーパー・キャパシタのCVPM02 (Cache Vault)が備えられています。

充電容量が低下して48時間以上電力の供給されないキャッシュ・データをバッテリで保護できない場合、書込みキャッシュが無効になり、ディスク・コントローラがライトスルー・モードに切り替わります。これにより、書込みパフォーマンスが低下しますが、データは失われません。充電容量が不十分の場合や温度が高い場合、バッテリを交換する必要がある場合は、Oracle Exadata Storage Serverがアラートを生成します。

バッテリの充電容量は徐々に低下し、寿命は動作温度と反比例します。最低の条件下のOracle Exadataラックのバッテリ寿命は、次のとおりです。

インレット環境の温度 バッテリの寿命

< 摂氏25度(華氏77度)

3年

< 摂氏32度(華氏89.6度)

2年

親トピック: ディスク・コントローラのバッテリの管理

3.11.2 データベース・サーバーのバッテリの監視

ノート:

充電容量が不十分であるか温度が高い場合およびバッテリを交換する必要がある場合、Exadata Storage Serverがアラートを生成します。

データベース・サーバーのバッテリの充電容量と温度は、次のコマンドを使用して監視できます。

ノート:

Oracle Exadata System Software 19.1.0以上を実行している場合は、次のコマンドで/opt/MegaRAID/MegaCli/MegaCli64を/opt/MegaRAID/storcli/storcli64に置き換えます。 
# /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0 | grep "Full Charge" -A5 | sort \
| grep Full -A1
次に、コマンドの出力例を示します。
Full Charge Capacity: 1357 mAh
Max Error: 2 %
バッテリの事前交換は、バッテリの容量が800mAhを下回り、最大エラー率が10%を下回る場合に行います。容量が674mAhを下回るか、最大エラー率が10%を超えた場合は、ただちにバッテリを交換してください。
バッテリの温度は、次のコマンドを使用して監視できます。
/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0 | grep BatteryType; \
/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0 | grep -i temper
次に、コマンドの出力例を示します。
BatteryType: iBBU08
Temperature: 38 C
  Temperature                  : OK
  Over Temperature        : No
バッテリの温度が摂氏55度以上である場合は、原因を特定し、問題を解決してください。

親トピック: ディスク・コントローラのバッテリの管理

3.11.3 ディスク・コントローラのバッテリの交換

ディスク・コントローラの充電容量が最小しきい値を下回った場合、システムがOracle Premier Support for Systemsの対象または保証期間中であれば、故障したバッテリが無償で交換されます。

Premier Support for Systemsのお客様を対象に、ベスト・エフォート原則に基づいて寿命が終わる前にOracle Exadataラックのバッテリを事前に交換します。

親トピック: ディスク・コントローラのバッテリの管理

3.12 F20 PCIeエネルギー・ストレージ・モジュールの管理

Sun Flash Accelerator F20 PCIeカードは、Exadata Database Machine X3モデルで使用されています。

親トピック: Oracle Exadata Storage Serverの保守

3.12.1 F20 PCIeエネルギー・ストレージ・モジュールについて

Sun Flash Accelerator F20 PCIeカードには、停電時のデータ整合性を確保するために、バッテリ・バックアップと同様に機能するエネルギー・ストレージ・モジュール(ESM)が組み込まれています。

Sun Flash Accelerator F20 PCIeカードは、頻繁にアクセスされるOracleデータベース・データをキャッシュし、Exadata Storage Serverのディスクに対する物理I/Oを不要とすることで、Oracle Exadataラックのパフォーマンスを高速化します。フラッシュ・カードに対する書込み操作は、書込み操作を高速化するためにカード上の揮発性のローカルDRAMメモリーに一時的にステージングされます。DRAM内のデータは、エネルギー・ストレージ・モジュール(ESM)によって保護されています。このモジュールは、十分な電力を提供して、電源障害の際にDRAM内のデータをローカル・フラッシュに移動します。

Oracle Exadata X3システムで使用されているフラッシュ・モジュールの予想耐久期間は、書込み集中型のアプリケーションでも10年以上です。フラッシュの耐久期間は、主に、何年にもわたってフラッシュに書き込まれる合計データ量および書き込まれるデータのタイプによって決まります。何年もの間、常時最大フラッシュ書込みIOPSで実行されるアプリケーションはありません。また、アプリケーションでは多くの読取りが実行され、アクティビティが多い期間と少ない期間があります(日中と夜間、四半期末、取引日の終了間際など)。非常に高い書込み集中型のアプリケーションで数か月にわたって測定したところ、最大フラッシュ書込みIOPSの25%が平均となります。各Exadata X3ストレージ・サーバーの耐久期間中の合計フラッシュ書込みは、一般的なデータベース・データの場合で50PBを超えます。フル・ラックでは、アプリケーションの平均書込みが10年間で250,000 8KフラッシュIOPS (最大書込みの25%)である場合、各セルに合計41PBのデータが書き込まれます。これは、セルの耐久期間中の50PBを下回ります。

ESMの充電が十分ではない場合、F20 PCIeカードは、DRAMメモリーを回避してすべてのデータを直接フラッシュに書き込むフェイルセーフのライトスルー・モードで動作します。これにより、書込みパフォーマンスが低下しますが、データは失われません。ESM容量が不十分な場合およびESMを交換する必要がある場合、Exadata Storage Serverがアラートを生成します。

ESMの充電容量は徐々に低下し、寿命は動作温度と反比例します。最低の条件下のOracle ExadataラックのESMの寿命は、次のとおりです。

Exadata Storage Serverのタイプ 寿命

Sun Fire X4275 Serverを使用したExadata Storage Server

3年

Sun Fire X4270 M2 Serverを使用したExadata Storage Server

4年

関連トピック

親トピック: F20 PCIeエネルギー・ストレージ・モジュールの管理

3.12.2 フラッシュESMの交換

F20 PCIe ESMの充電容量が最小しきい値を下回った場合、システムがOracle Premier Support for Systemsの対象または保証期間中であれば、故障したESMモジュールが無償で交換されます。

Premier Support for Systemsのお客様を対象に、ベスト・エフォート原則に基づいて寿命が終わる前にOracle ExadataラックのF20 PCIe ESMを事前に交換します。

親トピック: F20 PCIeエネルギー・ストレージ・モジュールの管理

3.13 LEDステータスの説明

Oracle Exadataラックのコンポーネントに搭載されているLEDは、点検整備が必要なコンポーネントを特定する際に役立ちます。

親トピック: Oracle Exadata Storage Serverの保守

3.13.1 Exadata Storage Server X7-2以降のLED

次の表に、Exadata Storage Server X7-2以降のサーバーのLEDの色コードを示します。

表3-1 Exadata Storage Server X7-2以降のLEDステータスの説明

コンポーネント LEDステータス

ファン・モジュール

  • 上部ファン障害LEDが消灯: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

  • 上部ファン障害LEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルの障害サービス必須LEDも点灯します。

電源

  • 障害サービス必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルの障害サービス必須LEDも点灯します。

  • AC OK LEDが緑色: ホット・スワップ中に電源を取り外せます。

サーバー・シャーシ

  • 取外しOK LEDが青色: ホット・スワップ中にストレージ・デバイスを安全に取り外せます。

  • 障害サービス必須LEDが黄色: システムが実行中ですが、ストレージ・デバイスに障害があります。システムがストレージ・デバイスの障害を検出した場合、前面および背面パネルの障害サービス必須LEDも点灯します。

  • OK/アクティビティLEDが緑色: ストレージ・デバイスに対してデータの読取りまたは書込み中です。

  • サービス不可LEDが白色/点灯: データの可用性を維持するためにストレージ・サーバーをオンラインのままにする必要があることを示します。ストレージ・サーバーを再起動したり、電源を切ったりしないでください。それ以外の場合、Oracle Automatic Storage Management (Oracle ASM)ディスク・グループが強制的にディスマウントされ、データの可用性が損なわれる可能性があります。

    通常、サービス不可LEDは、パートナ・ストレージ・サーバーの問題に対応して点灯します。ただし、Oracle ASMクラスタのローリング・アップグレード中は、参加しているすべてのストレージ・サーバーでサービス不可LEDが同時に点灯します。さらに、影響を受けるグリッド・ディスクでは、asmDeactivationOutcome属性に値(Cannot deactivate because ASM is in rolling upgrade mode)が含まれます。

  • サービス不可LEDが消灯: サービスのためにストレージ・サーバーの電源を安全に切断できます。

次の表に、LEDに基づいたストレージ・デバイス・ステータスを示します。

表3-2 LEDに基づいたExadata Storage Server X7-2以降のストレージ・デバイス・ステータス

LED 予測障害 低いパフォーマンス クリティカル

障害サービス必須LED (黄色)

点灯

点灯

点灯

取外しOK LED (青色)

消灯

点灯

点灯

親トピック: LEDステータスの説明

3.13.2 Exadata Storage Server X5-2 Server

表3-3に、Exadata Storage Server X5-2 ServerのLEDの色コードを示します。

表3-3 LEDステータスの説明

コンポーネント LEDステータス

Exadata Storage Server X5-2 Serverのファン・モジュール

  • ファン・ステータスLEDが消灯: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

  • ファン・ステータスLEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Exadata Storage Server X5-2 Serverの電源

  • 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

  • サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

  • AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Exadata Storage Server X5-2 Server

  • 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

  • サービス・アクション必須LEDが黄色: 記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

  • OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表3-4に、LEDに基づいたディスク・ステータスを示します。

表3-4 LEDに基づいたExadata Storage Server X5-2 Serverのディスク・ステータス

LED 予測障害 低いパフォーマンス クリティカル

サービス・アクション必須(濃い黄色)

点灯

点灯

点灯

取外しOK(青色)

消灯

点灯

点灯

親トピック: LEDステータスの説明

3.13.3 Exadata Storage Server X4-2L Server

表3-5に、Exadata Storage Server X3-2 ServerのLEDの色コードを示します。

表3-5 LEDステータスの説明

コンポーネント LEDステータス

Exadata Storage Server X4-2L Serverのファン・モジュール

  • ファン・ステータスLEDが緑色: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

  • ファン・ステータスLEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Exadata Storage Server X4-2L Serverの電源

  • 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

  • サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

  • AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Exadata Storage Server X4-2L Server

  • 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

  • サービス・アクション必須LEDが黄色: 記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

  • OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表3-8に、LEDに基づいたディスク・ステータスを示します。

表3-6 LEDに基づいたExadata Storage Server X4-2L Serverのディスク・ステータス

LED 予測障害 低いパフォーマンス クリティカル

サービス・アクション必須(濃い黄色)

点灯

点灯

点灯

取外しOK(青色)

消灯

点灯

点灯

親トピック: LEDステータスの説明

3.13.4 Exadata Storage Server X3-2 Server

表3-7に、Exadata Storage Server X3-2 ServerのLEDの色コードを示します。

表3-7 LEDステータスの説明

コンポーネント LEDステータス

Exadata Storage Server X3-2 Serverのファン・モジュール

  • ファン・ステータスLEDが緑色: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

  • ファン・ステータスLEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Exadata Storage Server X3-2 Serverの電源

  • 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

  • サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

  • AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Exadata Storage Server X3-2 Server

  • 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

  • サービス・アクション必須LEDが黄色: 記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

  • OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表3-8に、LEDに基づいたディスク・ステータスを示します。

表3-8 LEDに基づいたExadata Storage Server X3-2 Serverのディスク・ステータス

LED 予測障害 低いパフォーマンス クリティカル

サービス・アクション必須(濃い黄色)

点灯

点灯

点灯

取外しOK(青色)

消灯

点灯

点灯

親トピック: LEDステータスの説明

3.13.5 Sun Fire X4270 M2 Serverを使用したExadata Storage Server

表3-9に、Sun Fire X4270 M2 Serverを使用したExadata Storage ServerのLEDの色コードを示します。

表3-9 LEDステータスの説明

コンポーネント LEDステータス

Sun Fire X4270 M2 Serverを使用したExadata Storage Serverのファン・モジュール

  • ファン・ステータスLEDが緑色: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

  • ファン・ステータスLEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの電源

  • 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

  • サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

  • AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Sun Fire X4270 M2 Serverを使用したExadata Storage Server

  • 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

  • サービス・アクション必須LEDが黄色: 記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

  • OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表3-10に、LEDに基づいたディスク・ステータスを示します。

表3-10 Sun Fire X4270 M2 Serverを使用したExadata Storage ServerのLEDに基づいたディスク・ステータス

LED 予測障害 低いパフォーマンス クリティカル

サービス・アクション必須(濃い黄色)

点灯

点灯

点灯

取外しOK(青色)

消灯

点灯

点灯

親トピック: LEDステータスの説明

3.13.6 Sun Fire X4275 Serverを使用したExadata Storage ServerのLED

表3-11に、Sun Fire X4275 Serverを使用したExadata Storage ServerのLEDの色コードを示します。

表3-11 Sun Fire X4275 Serverを使用したExadata Storage ServerのLEDステータスの説明

コンポーネント LEDステータス

Sun Fire X4275 Serverを使用したExadata Storage Server

  • 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

  • サービス・アクション必須LEDが黄色: 記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

  • OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

Sun Fire X4275 Serverを使用したExadata Storage Serverのファン・モジュール

  • 電源/OK LEDが緑色: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

  • サービス・アクション必須LEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Sun Fire X4275 Serverを使用したExadata Storage Serverの電源

  • AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

  • サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

  • 取外しOK LEDが青色: ホット・スワップ中に電源を安全に取外せます。

表3-12に、LEDに基づいたディスク・ステータスを示します。

表3-12 Sun Fire X4275 Serverを使用したExadata Storage ServerのLEDに基づいたディスク・ステータス

LED 予測障害 低いパフォーマンス クリティカル

サービス・アクション必須(濃い黄色)

点滅

点滅

点灯

取外しOK(青色)

消灯

点滅

点滅

親トピック: LEDステータスの説明

3.13.7 Sun Flash Accelerator F20 PCIeカードのLED

表3-13に、Sun Flash Accelerator F20 PCIeカードのLEDの色コードを示します。

表3-13 Sun Flash Accelerator F20 PCIeカードのLEDステータスの説明

コンポーネント LEDステータス

FMod 3、2、1、0

LEDが緑色:対応するFModに読取り/書込みアクティビティがあると点滅します。対応するFModが存在すると点滅します。

ESM OK LED

LEDが緑色:ESMが充電されていて、停電時にデータの整合性を保持する十分な緊急時電力を提供できる場合にオンになります。システムがダウンしていているとオフになり、ESMが充電中である場合は点滅します。

ESMサービス必須LED

LEDが黄色のとき、ESMがライトバック・モードのための十分な予備電力を保持していないことを示します。カードはライトスルー(キャッシュ)モードで機能しています。サービスが必要です。

電源LED

LEDがオン:カードの電源が投入されていることを示します。

親トピック: LEDステータスの説明

3.14 Exadata Storage Serverのイメージ

Exadata Storage Serverのモデルには、様々な外部レイアウトおよび物理的外観があります。

親トピック: Oracle Exadata Storage Serverの保守

3.14.1 Oracle Exadata Storage Server X9M-2 Extreme Flashサーバーのイメージ

次の図に、Oracle Exadata Storage Server X9M-2 Extreme Flash (EF)サーバーの前面図を示します。

図3-1 Oracle Exadata Storage Server X9M-2 Extreme Flashサーバーの前面図

図3-1の説明が続きます。
「図3-1 Oracle Exadata Storage Server X9M-2 Extreme Flashサーバーの前面図」の説明

次の図に、Oracle Exadata Storage Server X9M-2 Extreme Flashサーバーの背面図を示します。

図3-2 Oracle Exadata Storage Server X9M-2 Extreme Flashサーバーの背面図

図3-2の説明が続く
「図3-2 Oracle Exadata Storage Server X9M-2 Extreme Flashサーバーの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.14.2 Oracle Exadata Storage Server X9M-2 High Capacityサーバーのイメージ

次の図に、Oracle Exadata Storage Server X9M-2 High Capacity (HC)サーバーの前面図を示します。

図3-3 Oracle Exadata Storage Server X9M-2 High Capacityサーバーの前面図

図3-3の説明が続きます
「図3-3 Oracle Exadata Storage Server X9M-2 High Capacityサーバーの前面図」の説明

次の図に、Oracle Exadata Storage Server X9M-2 High Capacityサーバーの背面図を示します。

図3-4 Oracle Exadata Storage Server X9M-2 High Capacityサーバーの背面図

図3-4の説明が続く
「図3-4 Oracle Exadata Storage Server X9M-2 High Capacityサーバーの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.14.3 Oracle Exadata Storage Server X9M-2拡張サーバーのイメージ

次の図に、Oracle Exadata Storage Server X9M-2拡張(XT)サーバーの前面図を示します。

図3-5 Oracle Exadata Storage Server X9M-2拡張サーバーの前面図

図3-5の説明が続きます
「図3-5 Oracle Exadata Storage Server X9M-2拡張サーバーの前面図」の説明

次の図に、Oracle Exadata Storage Server X9M-2拡張サーバーの背面図を示します。

図3-6 Oracle Exadata Storage Server X9M-2拡張サーバーの背面図

図3-6の説明が続く
「図3-6 Oracle Exadata Storage Server X9M-2拡張サーバーの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.14.4 Oracle Exadata Storage Server X8M-2およびX8-2 High Capacityおよび拡張(XT)サーバーのイメージ

次の図に、Oracle Exadata Storage Server X8M-2およびX8-2 High CapacityおよびXTサーバーの前面図を示します。

図3-7 Oracle Exadata Storage Server X8M-2およびX8-2 High CapacityおよびXTサーバーの前面図

図3-7の説明が続く
「図3-7 Oracle Exadata Storage Server X8M-2およびX8-2 High CapacityおよびXTサーバーの前面図」の説明

次の図に、Oracle Exadata Storage Server X8M-2およびX8-2 High CapacityおよびXTサーバーの背面図を示します。

図3-8 Oracle Exadata Storage Server X8M-2およびX8-2 High CapacityおよびXTサーバーの背面図

図3-8の説明が続く
「図3-8 Oracle Exadata Storage Server X8M-2およびX8-2 High CapacityおよびXTサーバーの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.14.5 Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flashサーバーのイメージ

Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flashサーバーの前面図は、X7-2サーバーとほぼ同じです。主な違いは製品ロゴです。

図3-9 Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flash Serverの前面図

図3-9の説明が続きます
「図3-9 Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flash Serverの前面図」の説明

Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flashサーバーの背面図は、X7-2サーバーとほぼ同じです。主な違いは製品ロゴです。

図3-10 Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flash Serverの背面図

図3-10の説明が続きます
「図3-10 Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flash Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.14.6 Oracle Exadata Storage Server X7-2 High Capacityサーバーのイメージ

次の図に、Oracle Exadata Storage Server X7-2 High Capacity Serverの前面図を示します。

図3-11 Oracle Exadata Storage Server X7-2 High Capacity Serverの前面図

図3-11の説明が続きます
「図3-11 Oracle Exadata Storage Server X7-2 High Capacity Serverの前面図」の説明

次の図に、Oracle Exadata Storage Server X7-2 High Capacity Serverの背面図を示します。

図3-12 Oracle Exadata Storage Server X7-2 High Capacity Serverの背面図

図3-12の説明が続きます。
「図3-12 Oracle Exadata Storage Server X7-2 High Capacity Server背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.14.7 Oracle Exadata Storage Server X7-2 Extreme Flashサーバーのイメージ

次の図に、Oracle Exadata Storage Server X7-2 Extreme Flash Serverの前面図を示します。

図3-13 Oracle Exadata Storage Server X7-2 Extreme Flash Serverの前面図

図3-13の説明が続きます。
「図3-13 Oracle Exadata Storage Server X7-2 Extreme Flash Serverの前面図」の説明

次の図に、Oracle Exadata Storage Server X7-2 Extreme Flash Serverの背面図を示します。

図3-14 Oracle Exadata Storage Server X7-2 Extreme Flash Serverの背面図

図3-14の説明が続きます。
「図3-14 Oracle Exadata Storage Server X7-2 Extreme Flash Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.14.8 High Capacity Exadata Storage Server X6-2のイメージ

次の図に、Oracle Exadata Storage Server X6-2 High Capacityサーバーの前面図を示します。

図3-15 Oracle Exadata Storage Server X6-2 High Capacity Serverの前面図

図3-15の説明が続きます
「図3-15 Oracle Exadata Storage Server X6-2 High Capacity Serverの前面図」の説明

次の図に、Oracle Exadata Storage Server X6-2 High Capacityサーバーの背面図を示します。

図3-16 Oracle Exadata Storage Server X6-2 High Capacity Serverの背面図

図3-16の説明が続きます
「図3-16 Oracle Exadata Storage Server X6-2 High Capacity Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.14.9 Extreme Flash Exadata Storage Server X6-2のイメージ

次の図に、Oracle Exadata Storage Server X6-2 Extreme Flashサーバーの前面図を示します。

図3-17 Oracle Exadata Storage Server X6-2 Extreme Flash Serverの前面図

図3-17の説明が続きます
「3-17 Oracle Exadata Storage Server X6-2 Extreme Flash Serverの前面図」の説明

次の図に、Oracle Exadata Storage Server X6-2 Extreme Flashサーバーの背面図を示します。

図3-18 Oracle Exadata Storage Server X6-2 Extreme Flash Serverの背面図

図3-18の説明が続きます
「図3-18 Oracle Exadata Storage Server X6-2 Extreme Flash Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.14.10 High Capacity Exadata Storage Server X5-2のイメージ

次の図に、High Capacity Exadata Storage Server X5-2 Serverの前面図を示します。

図3-19 High Capacity Exadata Storage Server X5-2 Serverの前面図

図3-19の説明が続きます
「図3-19 High Capacity Exadata Storage Server X5-2 Serverの前面図」の説明

次の図に、High Capacity Exadata Storage Server X5-2 Serverの背面図を示します。

図3-20 High Capacity Exadata Storage Server X5-2 Serverの背面図

図3-20の説明は次にあります
「図3-20 High Capacity Exadata Storage Server X5-2 Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.14.11 Extreme Flash Exadata Storage Server X5-2のイメージ

次の図に、Extreme Flash Exadata Storage Server X5-2 Serverの前面図を示します。

図3-21 Extreme Flash Exadata Storage Server X5-2 Serverの前面図

図3-21の説明が続きます
「図3-21 Extreme Flash Exadata Storage Server X5-2 Serverの前面図」の説明

次の図に、Extreme Flash Exadata Storage Server X5-2 Serverの背面図を示します。

図3-22 Extreme Flash Exadata Storage Server X5-2 Serverの背面図

図3-22の説明が続きます
「図3-22 Extreme Flash Exadata Storage Server X5-2 Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.14.12 Exadata Storage Server X4-2Lのイメージ

次の図に、Exadata Storage Server X4-2L Serverの前面図を示します。ハード・ドライブには、左下から始まり左から右へと番号が付けられます。下段のドライブの番号は0、1、2および3です。中段のドライブの番号は4、5、6および7です。上段のドライブの番号は8、9、10および11です。

図3-23 Exadata Storage Server X4-2L Serverの前面図

図3-23の説明は次にあります
「図3-23 Exadata Storage Server X4-2L Serverの前面図」の説明

次の図に、Exadata Storage Server X4-2L Serverの背面図を示します。

図3-24 Exadata Storage Server X4-2L Serverの背面図

図3-24の説明が続きます
「図3-24 Exadata Storage Server X4-2L Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.14.13 Exadata Storage Server X3-2Lのイメージ

次の図に、Exadata Storage Server X3-2L Serverの前面図を示します。ハード・ドライブには、左下から始まり左から右へと番号が付けられます。下段のドライブの番号は0、1、2および3です。中段のドライブの番号は4、5、6および7です。上段のドライブの番号は8、9、10および11です。

図3-25 Exadata Storage Server X3-2L Serverの前面図

図3-25の説明は次にあります
「図3-25 Exadata Storage Server X3-2L Serverの前面図」の説明

次の図に、Exadata Storage Server X3-2L Serverの背面図を示します。

図3-26 Exadata Storage Server X3-2L Serverの背面図

図3-26の説明は次にあります
「図3-26 Exadata Storage Server X3-2L Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.14.14 Sun Fire X4270 M2を使用したExadata Storage Serverのイメージ

次の図に、Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの前面図を示します。

図3-27 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの前面図

図3-27の説明は次にあります
「図3-27 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの前面図」の説明

  1. ハード・ディスク・ドライブ。上位ドライブは、左から右にHDD2、HDD5、HDD8およびHDD11です。中位ドライブは、左から右にHDD1、HDD4、HDD7およびHDD10です。下位ドライブは、左から右にHDD0、HDD3、HDD6およびHDD9です。

次の図に、Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの背面図を示します。

図3-28 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの背面図

図3-28の説明は次にあります
「図3-28 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの背面図」の説明

  1. 電源。

  2. InfiniBandホスト・チャネル・アダプタPCI Expressモジュール。

  3. Sun Flash Accelerator F20 PCIeカード。

親トピック: Exadata Storage Serverのイメージ

3.14.15 Sun Fire X4275を使用したExadata Storage Serverのイメージ

次の図に、Sun Fire X4275 Serverの前面図を示します。

図3-29 Sun Fire X4275 Serverの前面図

図3-29の説明は次にあります
「図3-29 Sun Fire X4275 Serverの前面図」の説明

  1. ハード・ディスク・ドライブ。上位ドライブは、左から右にHDD2、HDD5、HDD8およびHDD11です。中位ドライブは、左から右にHDD1、HDD4、HDD7およびHDD10です。下位ドライブは、左から右にHDD0、HDD3、HDD6およびHDD9です。

次の図に、Sun Fire X4275 Serverの背面図を示します。

図3-30 Sun Fire X4275 Serverの背面図

図3-30の説明は次にあります
「図3-30 Sun Fire X4275 Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ