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

3 Oracle Exadata Storage Serverの保守

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

ノート:

  • この章のすべての手順は、Oracle ExadataおよびOracle Exadata Storage拡張ラックに適用されます。
  • 読みやすさを考慮して、Oracle Exadataと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 ASMリバランス操作のステータスのチェック

Oracle ASMリバランス操作のステータスを確認できます。

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

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

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

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

ノート:

Oracle Exadata System Softwareリリース12.1.2.0およびBP4のOracle Databaseリリース12.1.0.2以降では、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システム・ソフトウェアが常駐しています。Oracle Exadata X7以降のシステムでは、このシステム領域は2つの内蔵M.2デバイスにあります。その他すべてのシステムでは、Oracle Exadata Storage Serverの最初の2つのディスクがシステム・ディスクとなっています。これらのシステム・ディスクの一部はシステム領域と呼ばれています。

Oracle Exadata X7以降のシステムでは、セル内のハード・ディスクはすべてデータ・ディスクになっています。Oracle Exadata 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およびOracle Exadata 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 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はリバランス操作のステータスについての電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。

以前のリリースについては、「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.3 ディスクの問題によるハード・ディスクの交換

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

予測障害ステータスは、ハード・ディスクに障害が発生する可能性があり、できるだけすぐに交換する必要があることを示します。ハード・ドライブのグリッド・ディスクに関連する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はリバランス操作のステータスについての電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。

以前のリリースについては、「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.4 低いパフォーマンスによるハード・ディスクの交換

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.5 ハード・ディスクの事前交換

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.6 別の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.7 ハード・ディスクの再利用

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

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

システム・ディスク(ディスク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.8 同じハード・ディスクの取外しおよび交換

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

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

ノート:

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

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

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

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

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

注意:

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

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になります。キャッシュがライトスルー・モードになっている場合、障害が発生したデバイスのデータはデータ・グリッド・ディスクにすでに存在しているため、ミラー復元の必要はありません。

親トピック: 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 ライトバックPMEMキャッシュとライトバック・フラッシュ・キャッシュの無効化

Oracle Exadata System Softwareリリース23.1.0より前のリリースでは、ライトバックPMEMキャッシュはライトバック・フラッシュ・キャッシュとの組合せでのみサポートされています。したがって、ライトバックPMEMキャッシュが有効な場合、ライトバック・フラッシュ・キャッシュを無効にするには、ライトバックPMEMキャッシュも無効にする必要があります。

この要件は、Oracle Exadata System Softwareリリース23.1.0より前に対してのみ適用されます。これはPMEMキャッシュがOracle Exadata System Softwareリリース23.1.0以降のライトスルー・モードでのみ動作するためです。

ノート:

アプリケーションのパフォーマンスへの影響を抑えるには、ワークロードが低い期間にキャッシュ・モードを変更します。

次のコマンド例では、手順の対象となるストレージ・サーバーのホスト名を含むcell_groupという名前のテキスト・ファイルを使用します。

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

    フラッシュ・キャッシュが、すべての使用可能なフラッシュ・セル・ディスクを使用する場合は、フラッシュ・ディスクをリストするかわりに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"
  6. フラッシュ・キャッシュのフラッシュ操作の進行状況を確認します。

    メトリックFC_BY_DIRTYがゼロになると、フラッシュ・プロセスは完了します。 

    # 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
  7. フラッシュ・キャッシュがフラッシュされた後、フラッシュ・キャッシュを削除します。
    # dcli -g cell_group -l root cellcli -e "drop flashcache"
  8. フラッシュ・キャッシュをライトスルー・モードで使用するようにセルを構成します。
    # dcli -g cell_group -l root cellcli -e "ALTER CELL flashCacheMode=writethrough"
  9. フラッシュ・キャッシュを再作成します。

    フラッシュ・キャッシュが、すべての使用可能なフラッシュ・セル・ディスクを使用する場合は、セル・ディスクをリストするかわりに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\'
  10. 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デバイスの保守

永続メモリー(PMEM)デバイスは、大容量(HC)またはExtreme Flash (EF)ストレージを持つExadata X8M-2およびX9M-2ストレージ・サーバー・モデル内に存在します。

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

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

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

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

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

PMEMの障害は、サーバーの再起動の原因になることがあります。障害が発生したデバイスは、できるだけすぐに新しいPMEMデバイスに交換する必要があります。PMEMデバイスを交換するまでは、対応するキャッシュ・サイズが減少します。PMEMデバイスをコミット・アクセラレーション(XRMEMLOGまたはPMEMLOG)に使用すると、対応するコミット・アクセラレータのサイズも減少します。

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デバイスをコミット・アクセラレーションに使用すると、デバイス上でコミット・アクセラレーションが有効になります。

親トピック: 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デバイスからデータがフラッシュされていることを確認するには、すべてのグリッド・ディスクのcachedBy属性を調べて、影響を受けたPMEMデバイスがリストされていないことを確認します。

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

    注意:

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

    ノート:

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

新しいPMEMデバイスがシステムによって自動的に使用されています。キャッシュにPMEMデバイスを使用している場合は、有効なキャッシュ・サイズが増加します。PMEMデバイスをコミット・アクセラレーションに使用すると、デバイス上でコミット・アクセラレーションが有効になります。

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

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

Oracle Exadata System Softwareリリース23.1.0より前は、PMEMキャッシュをライトバック・モードで動作するように構成できます。このモードは、ライトバックPMEMキャッシュとも呼ばれ、キャッシュが書込み操作を処理できるようにします。

ノート:

ベスト・プラクティスの推奨事項は、PMEMキャッシュをライトスルー・モードで構成することです。この構成によって、最高のパフォーマンスと可用性が提供されます。

Oracle Exadata System Softwareリリース23.1.0以降、PMEMキャッシュはライトスルー・モードでのみ動作します。

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

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

ライトバックPMEMキャッシュは、ライトバック・フラッシュ・キャッシュとの組合せでのみサポートされます。したがって、ライトバックPMEMキャッシュを有効にするには、ライトバック・フラッシュ・キャッシュも有効にする必要があります。

ノート:

Oracle Exadata System Softwareリリース23.1.0以降では、PMEMキャッシュはライトスルー・モードでのみ動作するため、ライトバックPMEMキャッシュを有効にすることはできません。

ノート:

アプリケーションのパフォーマンスへの影響を抑えるには、ワークロードが低い期間にキャッシュ・モードを変更します。

次のコマンド例では、手順の対象となるストレージ・サーバーのホスト名を含むcell_groupという名前のテキスト・ファイルを使用します。

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

      フラッシュ・キャッシュが、すべての使用可能なフラッシュ・セル・ディスクを使用する場合は、フラッシュ・ディスクをリストするかわりに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"
    4. フラッシュ・キャッシュのフラッシュ操作の進行状況を確認します。

      メトリックFC_BY_DIRTYがゼロになると、フラッシュ・プロセスは完了します。 

      # 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. フラッシュ・キャッシュをライトバック・モードで使用するようにセルを変更します。
      # dcli -g cell_group -l root cellcli -e "ALTER CELL flashCacheMode=writeback"
    7. フラッシュ・キャッシュを再作成します。

      フラッシュ・キャッシュが、すべての使用可能なフラッシュ・セル・ディスクを使用する場合は、セル・ディスクをリストするかわりに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\'
    8. flashCacheModeがwritebackに設定されていることを確認します。
      # dcli –l root –g cell_group cellcli -e "list cell detail" | grep flashCacheMode
  3. PMEMキャッシュをフラッシュします。

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

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

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

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

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

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

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

    # dcli –l root –g cell_group cellcli -e "CREATE PMEMCACHE ALL"
  7. 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ディスクの保守

Oracle Exadata 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 Oracle Exadata System Softwareのレスキュー手順の使用

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

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

3.7.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.7.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.7.3 Oracle Exadata Storage Serverのレスキュー後の構成

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

  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.7.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.7.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.8 「ストレージ・セルの既存のエラスティック構成の変更」

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

関連トピック

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

3.8.1 ストレージ・サーバーの追加

このトピックでは、新しいストレージ・サーバー(またはセル)を既存のOracle Exadataエラスティック構成に追加するステップバイステップの手順について説明します。

  1. 新しいストレージ・サーバーを追加する場合は、次のステップを実行します:
    1. 目的のストレージ・グリッドで新しいストレージ・サーバーを利用できるようにするために、必要なすべてのケーブル接続要件を完了します。
    2. 適切なOracle Exadata System Softwareイメージを使用してストレージ・サーバーをイメージ化し、IPアドレスの入力を求めるプロンプトが表示されたら適切な情報を入力します。
  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> LIST CELL ATTRIBUTES snmpsubscriber
    2. 次のコマンドを実行して、同じsnmpsubscriber属性値を新しいストレージ・サーバーに適用します。この際、snmpsubscriberを前のコマンドの値に置き換えてください。
      CellCLI> ALTER CELL snmpsubscriber=snmpsubscriber

      ノート:

      snmpsubscriber値では、英数字以外の文字が含まれる場合は、ホスト名またはIPアドレスは引用符で囲みます。たとえば: 

      CellCLI> ALTER CELL snmpSubscriber=((host="asr-host.example.com",port=162,community=public,type=asr,asrmPort=16161))
    3. 既存のストレージ・サーバーから、セルのアラートを構成するために必要なセルの属性をリストします。
      CellCLI> LIST CELL ATTRIBUTES -
notificationMethod,notificationPolicy,mailServer,smtpToAddr, -
smtpFrom,smtpFromAddr,smtpUseSSL,smtpPort
    4. 次のコマンドを実行して、同じ値を新しいストレージ・サーバーに適用します。この際、プレースホルダを既存のストレージ・サーバーから検出された値に置き換えてください。
      CellCLI> ALTER CELL -
 notificationMethod='notificationMethod', -
 notificationPolicy='notificationPolicy', -
 mailServer='mailServer', -
 smtpToAddr='smtpToAddr', -
 smtpFrom='smtpFrom', -
 smtpFromAddr='smtpFromAddr', -
 smtpUseSSL=smtpUseSSL, -
 smtpPort=smtpPort
  4. 必要に応じて、追加するストレージ・サーバーにセル・ディスクを作成します。
    1. 新しいセルで、既存のセル・ディスクをリストします。
      CellCLI> LIST CELLDISK
    2. セル・ディスクが存在しない場合は、セル・ディスクを作成します。
      CellCLI> CREATE CELLDISK ALL
    3. システムにPMEMデバイスがある場合は、デフォルトでPMEMログが作成されていたことを確認します。
      CellCLI> LIST PMEMLOG

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

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

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

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

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

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

      ノート:

      Oracle Exadata System Softwareリリース23.1.0以降、PMEMキャッシュはライトスルー・モードでのみ動作します。

      新しいセルのPMEMキャッシュ・モードが既存のセルと一致しない場合は、次のようにPMEMキャッシュ・モードを変更します:

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

        CellCLI> ALTER PMEMCACHE ALL FLUSH

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

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

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

        CellCLI> DROP PMEMCACHE ALL

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

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

        CellCLI> ALTER CELL PMEMCacheMode=writeback_or_writethrough

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

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

      新しいセルのフラッシュ・キャッシュ・モードが既存のセルと一致しない場合は、次のようにフラッシュ・キャッシュ・モードを変更します:

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

        CellCLI> ALTER FLASHCACHE ALL FLUSH

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

      2. フラッシュ・キャッシュを削除します。

        CellCLI> DROP FLASHCACHE ALL

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

        flashCacheMode属性の値は、writebackまたはwritethroughのいずれかです。クラスタ内の他のストレージ・セルと同じフラッシュ・キャッシュ・モードになるように、値を設定する必要があります。 

        CellCLI> ALTER CELL flashCacheMode=writeback_or_writethrough

      4. フラッシュ・キャッシュを作成します。

        CellCLI> CREATE FLASHCACHE ALL
  5. 必要に応じて、新しいストレージ・サーバーにデータ・セキュリティを構成します。
    1. 既存のセルで、セキュリティ・キーの存在を確認します。

      たとえば;

      CellCLI> LIST KEY DETAIL

name:                             
key: 8217035e5ac8ed64503020a40c520848
type: CELL         

name: Cluster-c1
key: da88cbc5579d4179f89d00a44d0edae9
type: ASMCLUSTER

name: Cluster-c2
key: 77fb637d4267913f40449fa2c57c6cf9
type: ASMCLUSTER
    2. 既存のセルにセキュリティ・キーが含まれている場合は、それに応じて新しいセルを構成します。
  6. 追加するセルのグリッド・ディスクを作成します。
    1. 既存のセルからの既存のグリッド・ディスクの属性を問い合せます。
      CellCLI> LIST GRIDDISK ATTRIBUTES name,asmDiskGroupName,cachingPolicy,size,offset,availableTo
    2. 前述のコマンドで検出された各ディスク・グループについて、追加する新しいセルのグリッド・ディスクを作成します。

      前のLIST GRIDDISKコマンドで報告された、特定のディスク・グループの既存のグリッド・ディスクの属性を一致させます。

      既存のセルと同じレイアウトおよびパフォーマンス特性になるように、オフセットの昇順でグリッド・ディスクを作成します。

      たとえば、LIST GRIDDISKコマンドで次の特性を持つグリッド・ディスクを識別する場合、最初にDATAC1、次にRECOC1、最後にDBFS_DGのグリッド・ディスクを作成します。 

      asmDiskGroupName          size            offset
DATAC1                    2.15625T        32M
RECOC1                    552.109375G     2.1562957763671875T
DBFS_DG                   33.796875G      2.695465087890625T

      テンプレートとして次のコマンドを使用します:

      CellCLI> 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', -
 availableto='value_from_command_above_for_this_disk_group', -
 comment="Cluster cluster_name diskgroup diskgroup_name"

      注意:

      次のように、EXACTサイズを単位(TまたはG)とともに指定してください
  7. 各Oracle RACノードにログインし、新しく作成されたグリッド・ディスクがOracle RACノードから参照できることを確認します。

    Oracle Grid InfrastructureソフトウェアのOS所有者(通常はgridまたはoracle)として次のコマンドを実行します。コマンドでは、Grid_homeはOracle Grid Infrastructureソフトウェアのインストール・ホーム・ディレクトリを指し、cell_being_addedは追加される新しいセルの名前を指します。 

    $ Grid_home/bin/kfod op=disks disks=all | grep cell_being_added

    kfodコマンドの出力には、新しく追加されたストレージ・サーバー上のすべてのグリッド・ディスクが表示されます。

  8. 新しく作成されたグリッド・ディスクを対応するOracle ASMディスク・グループに追加します。

    この例では、comma_separated_disk_namesは、disk_group_nameに対応するステップ6のディスク名を指します。 

    SQL> ALTER DISKGROUP disk_group_name ADD DISK 'comma_separated_disk_names';

    このコマンドはデフォルトの電源レベルでOracle ASMリバランス操作を開始します。

  9. GV$ASM_OPERATIONの問合せにより、リバランスの進捗状況を監視します。
    SQL> SELECT * FROM GV$ASM_OPERATION;

    リバランスが完了すると、Oracle RACクラスタへのセルの追加は完了です。

  10. Oracle EXAchkの最新バージョンをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。

親トピック: ストレージ・セルの既存のエラスティック構成の変更

3.8.2 エイス・ラック・クラスタへの新しいストレージ・サーバーの追加

既存のOracle Exadata X7以降のエイス・ラックに新しいOracle Exadata 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> LIST CELL ATTRIBUTES snmpsubscriber
    2. 次のコマンドを実行して、同じsnmpsubscriber属性値を新しいストレージ・サーバーに適用します。この際、snmpsubscriberを前のコマンドの値に置き換えてください。
      CellCLI> ALTER CELL snmpsubscriber=snmpsubscriber

      ノート:

      snmpsubscriber値では、英数字以外の文字が含まれる場合は、ホスト名またはIPアドレスは引用符で囲みます。たとえば: 

      CellCLI> ALTER CELL snmpSubscriber=((host="asr-host.example.com",port=162,community=public,type=asr,asrmPort=16161))
    3. 既存のストレージ・サーバーから、セルのアラートを構成するために必要なセルの属性をリストします。
      CellCLI> LIST CELL ATTRIBUTES -
notificationMethod,notificationPolicy,mailServer,smtpToAddr, -
smtpFrom,smtpFromAddr,smtpUseSSL,smtpPort
    4. 次のコマンドを実行して、同じ値を新しいストレージ・サーバーに適用します。この際、プレースホルダを既存のストレージ・サーバーから検出された値に置き換えてください。
      CellCLI> ALTER CELL -
 notificationMethod='notificationMethod', -
 notificationPolicy='notificationPolicy', -
 mailServer='mailServer', -
 smtpToAddr='smtpToAddr', -
 smtpFrom='smtpFrom', -
 smtpFromAddr='smtpFromAddr', -
 smtpUseSSL=smtpUseSSL, -
 smtpPort=smtpPort

親トピック: ストレージ・セルの既存のエラスティック構成の変更

3.8.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.8.4 既存のExadataストレージ・グリッドの拡張

このシナリオでは、Exadataラック内にExadataストレージ・セルが存在し、最も拡張の必要なExadataストレージ・グリッドにストレージ・セルを追加します。

  1. 現在のクラスタからストレージ・セルを廃止します。これを実行するには、「既存のディスク・グループまたはストレージ・グリッドからのストレージ・サーバーの削除」の手順に従ってください。
  2. 目的のExadataストレージ・グリッドにストレージ・セルを追加します。これを実行するには、「ストレージ・サーバーの追加」の手順に従ってください。
  3. 最新のexachkをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。

親トピック: ストレージ・セルの既存のエラスティック構成の変更

3.8.5 既存のディスク・グループまたはストレージ・グリッドからのストレージ・サーバーの削除

既存のOracle Exadataラックからストレージ・サーバーを削除できます。

  1. Oracle Automatic Storage Management (Oracle ASM)から削除するストレージ・サーバーに属しているディスクを削除します。

    ノート:

    Oracle Exadata 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と表示されている必要があります。

      注意:

      Oracle Exadata 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の最新バージョンをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。

親トピック: ストレージ・セルの既存のエラスティック構成の変更

3.8.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.9 ディスク・コントローラのバッテリの管理

この項は、バッテリを使用してディスク・コントローラのキャッシュを保護するExadata X4以前のシステムにのみ適用されます。新しいディスク・コントローラは、メンテナンスや交換を必要としないスーパーキャパシタを使用します。

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

3.9.1 ディスク・コントローラのバッテリについて

Exadata X4以前のシステムのディスク・コントローラには、書込みパフォーマンスを高速化するバッテリ・バックアップ式の書込みキャッシュがあります。

ノート:

このトピックは、バッテリを使用してディスク・コントローラのキャッシュを保護するExadata X4以前のシステムにのみ適用されます。

充電容量が低下して48時間以上電力の供給されないキャッシュ・データをバッテリで保護できない場合、書込みキャッシュが無効になり、ディスク・コントローラがライトスルー・モードに切り替わります。これにより、書込みパフォーマンスが低下しますが、データは失われません。充電容量が不十分の場合や温度が高い場合、バッテリを交換する必要がある場合は、Oracle Exadata Storage Serverがアラートを生成します。

バッテリの充電容量は徐々に低下し、寿命は動作温度と反比例します。最低の条件下のOracle Exadataラックのバッテリ寿命は、次のとおりです。

インレット環境の温度 バッテリの寿命

< 摂氏25度(華氏77度)

3年

< 摂氏32度(華氏89.6度)

2年

親トピック: ディスク・コントローラのバッテリの管理

3.9.2 ストレージ・サーバーのハード・ディスク・コントローラのバッテリおよびキャッシュ・モードの監視

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

ノート:

このトピックは、バッテリを使用してディスク・コントローラのキャッシュを保護するExadata X4以前のシステムにのみ適用されます。

ライトスルー・キャッシュ・モードはライトバック・キャッシュ・モードより時間を要します。ただし、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

親トピック: ディスク・コントローラのバッテリの管理

3.9.3 データベース・サーバーのバッテリの監視

ノート:

このトピックは、バッテリを使用してディスク・コントローラのキャッシュを保護するExadata X4以前のシステムにのみ適用されます。

ノート:

充電容量が不十分であるか温度が高い場合およびバッテリを交換する必要がある場合、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.9.4 ディスク・コントローラのバッテリの交換

ノート:

このトピックは、バッテリを使用してディスク・コントローラのキャッシュを保護するExadata X4以前のシステムにのみ適用されます。

ディスク・コントローラの充電容量が最小しきい値を下回った場合、システムがOracle Premier Support for Systemsの対象または保証期間中であれば、故障したバッテリが無償で交換されます。

Premier Support for Systemsのお客様を対象に、ベスト・エフォート原則に基づいて寿命が終わる前にOracle Exadataラックのバッテリを事前に交換します。

親トピック: ディスク・コントローラのバッテリの管理

3.10 F20 PCIeエネルギー・ストレージ・モジュールの管理

Sun Flash Accelerator F20 PCIeカードは、Oracle Exadata X3モデルで使用されています。

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

3.10.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.10.2 フラッシュESMの交換

F20 PCIe ESMの充電容量が最小しきい値を下回った場合、システムがOracle Premier Support for Systemsの対象または保証期間中であれば、故障したESMモジュールが無償で交換されます。

Premier Support for Systemsのお客様を対象に、ベスト・エフォート原則に基づいて寿命が終わる前にOracle ExadataラックのF20 PCIe ESMを事前に交換します。

親トピック: F20 PCIeエネルギー・ストレージ・モジュールの管理

3.11 Exadata Storage ServerのLEDインジケータの説明

Oracle Exadataストレージ・サーバーのインジケータLEDは、システム・ステータスを確認し、保守が必要なコンポーネントを識別するために役立ちます。

Oracle Exadataストレージ・サーバーの様々なインジケータLEDについては、使用しているシステムのサーバー・サービス・マニュアルのサーバーのフロント・パネルおよびバック・パネルのステータス・インジケータを使用したトラブルシューティングの項を参照してください。

サーバー・サービス・マニュアルのリストについては、関連ドキュメントを参照してください。

また、サービス不可LEDは、Oracle Exadata X7-2以降のストレージ・サーバーにのみ含まれています。

Oracle Exadataストレージ・サーバーでは、サービス不可LEDの状態は次のとおりです:

  • サービス不可LEDが白色/点灯: データの可用性を維持するためにストレージ・サーバーをオンラインのままにする必要があることを示します。ストレージ・サーバーを再起動したり、電源を切ったりしないでください。そうでない場合、データの可用性が損なわれる可能性があります。

    通常、サービス不可LEDは、パートナ・ストレージ・サーバーの問題に対応して点灯します。ただし、サービス不可LEDも次の状況で点灯します:

    • Oracle ASMクラスタのローリング・アップグレード中は、参加しているすべてのストレージ・サーバーでサービス不可LEDが同時に点灯します。さらに、影響を受けるグリッド・ディスクでは、asmDeactivationOutcome属性に値(Cannot deactivate because ASM is in rolling upgrade mode)が含まれます。

    • 投票ディスクを含むデータベース・サーバーが停止すると、すべてのストレージ・サーバーでサービス不可LEDが同時に点灯し、クラスタ内の定数を保持するためにストレージ・サーバーを停止しないよう警告されます。

  • サービス不可LEDが消灯: サービスのためにストレージ・サーバーの電源を安全に切断できます。

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

3.12 Exadata Storage Serverのイメージ

Exadata Storage Serverのモデルには、様々な外部レイアウトおよび物理的外観があります。

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

3.12.1 Oracle Exadata Storage Server X10M Extreme Flashサーバーのイメージ

次の図に、Oracle Exadata Storage Server X10M Extreme Flash (EF)サーバーの前面図を示します。

図3-1 Oracle Exadata Storage Server X10M EFサーバーの前面図

図3-1の説明が続きます。
「図3-1 Oracle Exadata Storage Server X10M EFサーバーの前面図」の説明

次の図に、Oracle Exadata Storage Server X10M EFサーバーの背面図を示します。

図3-2 Oracle Exadata Storage Server X10M EFサーバーの背面図

図3-2の説明が続く
「図3-2 Oracle Exadata Storage Server X10M EFサーバーの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.2 Oracle Exadata Storage Server X10M High Capacityサーバーのイメージ

次の図に、Oracle Exadata Storage Server X10M High Capacity (HC)サーバーの前面図を示します。

図3-3 Oracle Exadata Storage Server X10M HCサーバーの前面図

図3-3の説明が続きます
「図3-3 Oracle Exadata Storage Server X10M HCサーバーの前面図」の説明

次の図に、Oracle Exadata Storage Server X10M HCサーバーの背面図を示します。

図3-4 Oracle Exadata Storage Server X10M HCサーバーの背面図

図3-4の説明が続く
「図3-4 Oracle Exadata Storage Server X10M HCサーバーの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.3 Oracle Exadata Storage Server X10M拡張サーバーのイメージ

次の図に、Oracle Exadata Storage Server X10M拡張(XT)サーバーの前面図を示します。

図3-5 Oracle Exadata Storage Server X10M XTサーバーの前面図

図3-5の説明が続きます
「図3-5 Oracle Exadata Storage Server X10M XTサーバーの前面図」の説明

次の図に、Oracle Exadata Storage Server X10M XTサーバーの背面図を示します。

図3-6 Oracle Exadata Storage Server X10M XTサーバーの背面図

図3-6の説明が続く
「図3-6 Oracle Exadata Storage Server X10M XTサーバーの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.4 Oracle Exadata Storage Server X9M-2 Extreme Flashサーバーのイメージ

次の図に、Oracle Exadata Storage Server X9M-2 Extreme Flash (EF)サーバーの前面図を示します。

図3-7 Oracle Exadata Storage Server X9M-2 Extreme Flashサーバーの前面図

図3-7の説明が続く
「図3-7 Oracle Exadata Storage Server X9M-2 Extreme Flashサーバーの前面図」の説明

次の図に、Oracle Exadata Storage Server X9M-2 Extreme Flashサーバーの背面図を示します。

図3-8 Oracle Exadata Storage Server X9M-2 Extreme Flashサーバーの背面図

図3-8の説明が続く
「図3-8 Oracle Exadata Storage Server X9M-2 Extreme Flashサーバーの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.5 Oracle Exadata Storage Server X9M-2 High Capacityサーバーのイメージ

次の図に、Oracle Exadata Storage Server X9M-2 High Capacity (HC)サーバーの前面図を示します。

図3-9 Oracle Exadata Storage Server X9M-2 High Capacityサーバーの前面図

図3-9の説明が続きます
「図3-9 Oracle Exadata Storage Server X9M-2 High Capacityサーバーの前面図」の説明

次の図に、Oracle Exadata Storage Server X9M-2 High Capacityサーバーの背面図を示します。

図3-10 Oracle Exadata Storage Server X9M-2 High Capacityサーバーの背面図

図3-10の説明が続きます
「図3-10 Oracle Exadata Storage Server X9M-2 High Capacityサーバーの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.6 Oracle Exadata Storage Server X9M-2拡張サーバーのイメージ

次の図に、Oracle Exadata Storage Server X9M-2拡張(XT)サーバーの前面図を示します。

図3-11 Oracle Exadata Storage Server X9M-2拡張サーバーの前面図

図3-11の説明が続きます
「図3-11 Oracle Exadata Storage Server X9M-2拡張サーバーの前面図」の説明

次の図に、Oracle Exadata Storage Server X9M-2拡張サーバーの背面図を示します。

図3-12 Oracle Exadata Storage Server X9M-2拡張サーバーの背面図

図3-12の説明が続きます。
「図3-12 Oracle Exadata Storage Server X9M-2拡張サーバーの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.7 Oracle Exadata Storage Server X8M-2およびX8-2 High Capacityおよび拡張(XT)サーバーのイメージ

次の図に、Oracle Exadata Storage Server X8M-2およびX8-2 High CapacityおよびXTサーバーの前面図を示します。

図3-13 Oracle Exadata Storage Server X8M-2およびX8-2 High CapacityおよびXTサーバーの前面図

図3-13の説明が続きます。
「図3-13 Oracle Exadata Storage Server X8M-2およびX8-2 High CapacityおよびXTサーバーの前面図」の説明

次の図に、Oracle Exadata Storage Server X8M-2およびX8-2 High CapacityおよびXTサーバーの背面図を示します。

図3-14 Oracle Exadata Storage Server X8M-2およびX8-2 High CapacityおよびXTサーバーの背面図

図3-14の説明が続きます。
「図3-14 Oracle Exadata Storage Server X8M-2およびX8-2 High CapacityおよびXTサーバーの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.8 Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flashサーバーのイメージ

Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flashサーバーの前面図は、X7-2サーバーとほぼ同じです。主な違いは製品ロゴです。

図3-15 Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flash Serverの前面図

図3-15の説明が続きます
「図3-15 Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flash Serverの前面図」の説明

Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flashサーバーの背面図は、X7-2サーバーとほぼ同じです。主な違いは製品ロゴです。

図3-16 Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flash Serverの背面図

図3-16の説明が続きます
「図3-16 Oracle Exadata Storage Server X8M-2およびX8-2 Extreme Flash Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.9 Oracle Exadata Storage Server X7-2 High Capacityサーバーのイメージ

次の図に、Oracle Exadata Storage Server X7-2 High Capacity Serverの前面図を示します。

図3-17 Oracle Exadata Storage Server X7-2 High Capacity Serverの前面図

図3-17の説明が続きます
「図3-17 Oracle Exadata Storage Server X7-2 High Capacity Serverの前面図」の説明

次の図に、Oracle Exadata Storage Server X7-2 High Capacity Serverの背面図を示します。

図3-18 Oracle Exadata Storage Server X7-2 High Capacity Serverの背面図

図3-18の説明が続きます
「図3-18 Oracle Exadata Storage Server X7-2 High Capacity Server背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.10 Oracle Exadata Storage Server X7-2 Extreme Flashサーバーのイメージ

次の図に、Oracle Exadata Storage Server X7-2 Extreme Flash Serverの前面図を示します。

図3-19 Oracle Exadata Storage Server X7-2 Extreme Flash Serverの前面図

図3-19の説明が続きます
「3-19 Oracle Exadata Storage Server X7-2 Extreme Flash Serverの前面図」の説明

次の図に、Oracle Exadata Storage Server X7-2 Extreme Flash Serverの背面図を示します。

図3-20 Oracle Exadata Storage Server X7-2 Extreme Flash Serverの背面図

図3-20の説明は次にあります
「図3-20 Oracle Exadata Storage Server X7-2 Extreme Flash Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.11 High Capacity Exadata Storage Server X6-2のイメージ

次の図に、Oracle Exadata Storage Server X6-2 High Capacityサーバーの前面図を示します。

図3-21 Oracle Exadata Storage Server X6-2 High Capacity Serverの前面図

図3-21の説明が続きます
「図3-21 Oracle Exadata Storage Server X6-2 High Capacity Serverの前面図」の説明

次の図に、Oracle Exadata Storage Server X6-2 High Capacityサーバーの背面図を示します。

図3-22 Oracle Exadata Storage Server X6-2 High Capacity Serverの背面図

図3-22の説明が続きます
「図3-22 Oracle Exadata Storage Server X6-2 High Capacity Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.12 Extreme Flash Exadata Storage Server X6-2のイメージ

次の図に、Oracle Exadata Storage Server X6-2 Extreme Flashサーバーの前面図を示します。

図3-23 Oracle Exadata Storage Server X6-2 Extreme Flash Serverの前面図

図3-23の説明は次にあります
「3-23 Oracle Exadata Storage Server X6-2 Extreme Flash Serverの前面図」の説明

次の図に、Oracle Exadata Storage Server X6-2 Extreme Flashサーバーの背面図を示します。

図3-24 Oracle Exadata Storage Server X6-2 Extreme Flash Serverの背面図

図3-24の説明が続きます
「図3-24 Oracle Exadata Storage Server X6-2 Extreme Flash Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.13 High Capacity Exadata Storage Server X5-2のイメージ

次の図に、High Capacity Exadata Storage Server X5-2 Serverの前面図を示します。

図3-25 High Capacity Exadata Storage Server X5-2 Serverの前面図

図3-25の説明は次にあります
「図3-25 High Capacity Exadata Storage Server X5-2 Serverの前面図」の説明

次の図に、High Capacity Exadata Storage Server X5-2 Serverの背面図を示します。

図3-26 High Capacity Exadata Storage Server X5-2 Serverの背面図

図3-26の説明は次にあります
「図3-26 High Capacity Exadata Storage Server X5-2 Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.14 Extreme Flash Exadata Storage Server X5-2のイメージ

次の図に、Extreme Flash Exadata Storage Server X5-2 Serverの前面図を示します。

図3-27 Extreme Flash Exadata Storage Server X5-2 Serverの前面図

図3-27の説明は次にあります
「図3-27 Extreme Flash Exadata Storage Server X5-2 Serverの前面図」の説明

次の図に、Extreme Flash Exadata Storage Server X5-2 Serverの背面図を示します。

図3-28 Extreme Flash Exadata Storage Server X5-2 Serverの背面図

図3-28の説明は次にあります
「図3-28 Extreme Flash Exadata Storage Server X5-2 Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.15 Exadata Storage Server X4-2Lのイメージ

次の図に、Exadata Storage Server X4-2L Serverの前面図を示します。ハード・ドライブには、左下から始まり左から右へと番号が付けられます。下段のドライブの番号は0、1、2および3です。中段のドライブの番号は4、5、6および7です。上段のドライブの番号は8、9、10および11です。

図3-29 Exadata Storage Server X4-2L Serverの前面図

図3-29の説明は次にあります
「図3-29 Exadata Storage Server X4-2L Serverの前面図」の説明

次の図に、Exadata Storage Server X4-2L Serverの背面図を示します。

図3-30 Exadata Storage Server X4-2L Serverの背面図

図3-30の説明は次にあります
「図3-30 Exadata Storage Server X4-2L Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.16 Exadata Storage Server X3-2Lのイメージ

次の図に、Exadata Storage Server X3-2L Serverの前面図を示します。ハード・ドライブには、左下から始まり左から右へと番号が付けられます。下段のドライブの番号は0、1、2および3です。中段のドライブの番号は4、5、6および7です。上段のドライブの番号は8、9、10および11です。

図3-31 Exadata Storage Server X3-2L Serverの前面図

図3-31の説明が続く
「図3-31 Exadata Storage Server X3-2L Serverの前面図」の説明

次の図に、Exadata Storage Server X3-2L Serverの背面図を示します。

図3-32 Exadata Storage Server X3-2L Serverの背面図

図3-32の説明が続く
「図3-32 Exadata Storage Server X3-2L Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ

3.12.17 Sun Fire X4270 M2を使用したExadata Storage Serverのイメージ

次の図に、Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの前面図を示します。

図3-33 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの前面図

図3-33の説明が続く
「図3-33 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-34 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの背面図

図3-34の説明が続く
「図3-34 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの背面図」の説明

  1. 電源。

  2. InfiniBandホスト・チャネル・アダプタPCI Expressモジュール。

  3. Sun Flash Accelerator F20 PCIeカード。

親トピック: Exadata Storage Serverのイメージ

3.12.18 Sun Fire X4275を使用したExadata Storage Serverのイメージ

次の図に、Sun Fire X4275 Serverの前面図を示します。

図3-35 Sun Fire X4275 Serverの前面図

図3-35の説明が続く
「図3-35 Sun Fire X4275 Serverの前面図」の説明

  1. ハード・ディスク・ドライブ。上位ドライブは、左から右にHDD2、HDD5、HDD8およびHDD11です。中位ドライブは、左から右にHDD1、HDD4、HDD7およびHDD10です。下位ドライブは、左から右にHDD0、HDD3、HDD6およびHDD9です。

次の図に、Sun Fire X4275 Serverの背面図を示します。

図3-36 Sun Fire X4275 Serverの背面図

図3-36の説明が続く
「図3-36 Sun Fire X4275 Serverの背面図」の説明

親トピック: Exadata Storage Serverのイメージ