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

3 Oracle ExadataラックのOracle Exadata Storage Serverの保守

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

注意:

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

3.1 Oracle Exadata Storage Serverの保守

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

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

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

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

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

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

    注意:

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

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

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

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

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

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

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

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

    CellCLI> ALTER GRIDDISK ALL ACTIVE

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

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

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

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

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

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

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

注意:

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

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

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

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

このISOは、ストレージ・サーバーの/opt/oracle.SupportTools/diagnostics.isoにあります。USBの使用など、他のブート方法が機能しない場合は、診断ISOを使用してください。

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

  1. Webインタフェースまたはシリアル・コンソールを使用して、サービス・プロセッサで1回のCD-ROMブートを有効にします。次に、シリアル・コンソールを使用する場合のコマンドの例を示します。
    set boot_device=cdrom
  2. サービス・プロセッサ・インタフェースを使用して、diagnostics.isoのローカル・コピーをCD-ROMとしてマウントします。
  3. shutdown -r nowコマンドを使用して、セルを再起動します。
  4. rootユーザーとして診断ISOのパスワードを使用してセルにログインします。
  5. 次のコマンドを使用してpingを回避します。
    alias ping="ping -c"
  6. /etc/networkという名前のディレクトリを作成します。
  7. /etc/network/if-pre-up.dという名前のディレクトリを作成します。
  8. /etc/network/interfacesファイルに次の行を追加します。 
    iface eth0 inet static
address IP_address_of_cell
netmask netmask_of_cell
gateway gateway_IP_address_of_cell
  9. 次のコマンドを使用して、eth0インタフェースを起動します。
    ifup eth0

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

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

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

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

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

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

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

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

Oracle Exadata XTストレージ・サーバーごとに、12台の14TB SASディスク・ドライブ(合計168TBのRAWディスク容量)が組み込まれています。低コストを実現するために、フラッシュは組み込まれていません。また、Oracle Exadata System Softwareのライセンスはオプションです。ハイブリッド列圧縮はデフォルトで組み込まれていますが、ソフトウェア機能の一部はライセンスなしでは無効化されています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:

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

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

関連トピック

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

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

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

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

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

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

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

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

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

  • Oracle Exadata System Softwareリリース11.2.3.2:

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

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

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

関連トピック

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

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

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

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

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

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

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

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

    HDD disk controller battery on disk contoller 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.
  • バッテリのステータスを表示するには、次の例に示すようなコマンドを使用します。
    # /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuStatus -a0
BBU status for Adapter: 0
 
BatteryType: iBBU08
Voltage: 3721 mV
Current: 541 mA
Temperature: 43 C
 
BBU Firmware Status:
Charging Status : Charging
Voltage : OK
Temperature : OK
Learn Cycle Requested : No
Learn Cycle Active : No
Learn Cycle Status : OK
Learn Cycle Timeout : No
I2c Errors Detected : No
Battery Pack Missing : No
Battery Replacement required : No
Remaining Capacity Low : Yes
Periodic Learn Required : No
Transparent Learn : No
 
Battery state:
 
GasGuageStatus:
Fully Discharged : No
Fully Charged : No
Discharging : No
Initialized : No
Remaining Time Alarm : Yes
Remaining Capacity Alarm: No
Discharge Terminated : No
Over Temperature : No
Charging Terminated : No
Over Charged : No
 
Relative State of Charge: 7 %
Charger System State: 1
Charger System Ctrl: 0
Charging current: 541 mA
Absolute state of charge: 0 %
Max Error: 0 %
 
Exit Code: 0x00

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

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

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

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

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

注意:

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

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

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

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

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

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

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

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

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

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

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

関連項目:

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

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

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

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

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

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

注意:

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

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

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

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

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

    注意:

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

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

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

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

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

関連項目:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:

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

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

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

    次に例を示します。

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

    注意:

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

関連項目:

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

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

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

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

ハード・ディスクが交換または再有効化され、後続のリバランスが完了するまで、ディスク・グループの冗長性が損なわれます。このことは、標準冗長性を使用するディスク・グループにおいて特に重要です。

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

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

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

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

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

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

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

    CellCLI> list lun where deviceName='/dev/sdf/'
         0_5     0_5     normal
  2. 通常のモードで、Oracle ASMディスク・グループからグリッド・ディスクを削除します。
    SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name;
  3. リバランスが完了するまで待ちます。
  4. drop for replacementを実行します。

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

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

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

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

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

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

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

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

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

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

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

    • /etc/hosts

    • /etc/modprobe.conf

    • /etc/sysconfig/network

    • /etc/sysconfig/network-scripts

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

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

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

    注意:

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

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

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

    • /etc/hosts

    • /etc/modprobe.conf

    • /etc/sysconfig/network

    • /etc/sysconfig/network-scripts

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

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

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

関連項目:

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

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

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

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

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

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

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

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

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

    注意:

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

    CellCLI> DROP CELLDISK CD_03_cell01 ERASE=1pass NOWAIT

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

    注意:

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

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

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

関連トピック

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

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

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

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

注意:

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

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

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

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

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

注意:

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

CellCLI> ALTER PHYSICALDISK hard_disk_name reenable force

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

Physical disk 20:0 was reenabled.

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

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

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

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

親トピック: Oracle Exadataラックの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ストレージ・サーバーではホットプラグ対応ですが、HCストレージ・サーバーではホットプラグ対応ではありません。Oracle Exadata Database Machine X6以前のシステムのHCストレージ・サーバーの場合、フラッシュ・ディスクを交換する前にストレージ・サーバーの電源を切断する必要があります。

  1. フラッシュ・ディスクの交換が可能かどうかを調べます。
    Oracle Exadata Database Machine X7以降でフラッシュ・デバイスのホットプラグ交換を実行する場合は、ディスク・ステータスが交換のため切断になっている必要があり、このことは、フラッシュ・ディスクのオンライン交換が可能であることを示します。 
    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
  2. PCI番号およびFDOM番号に基づいて、障害が発生したフラッシュ・ディスクを特定します。
    白色のロケータLEDが点灯し、影響を受けているストレージ・サーバーを特定できます。黄色の障害サービス必須LEDが点灯し、影響を受けるフラッシュ・カードを特定できます。
  3. カードの電源LEDが消灯していることを確認します。

    注意:

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

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

3.4.5 ソフトウェア・バージョン11.2.3.3.1以上のライトバック・フラッシュ・キャッシュの有効化および無効化

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

ディスクではなくフラッシュによって処理される書込み操作は、ライトバック・フラッシュ・キャッシュと呼ばれます。この機能は必要に応じて有効または無効にできます。フラッシュ・キャッシュ・モードを変更する場合は、次の点に注意してください。

  • Oracle Exadata System Softwareリリース11.2.3.3.1以上では、セル・サービスを停止したり、グリッド・ディスクを非アクティブ化する必要はありません。

  • ライトバック・フラッシュ・キャッシュを使用するには、Oracle Grid InfrastructureホームおよびOracle Databaseホームをリリース11.2.0.3 BP9以上にする必要があります。

注意:

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

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

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

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

注意:

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

  • アプリケーションのパフォーマンスへの影響を抑えるには、ワークロードが低い期間にライトバック・フラッシュ・キャッシュを有効化します。

  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以上でのライトバック・フラッシュ・キャッシュの無効化

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

注意:

  • リリース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 11.2.3.3.1より前のソフトウェア・バージョンでのライトバック・フラッシュ・キャッシュの有効化および無効化

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

ディスクではなくフラッシュによって処理される書込み操作は、「ライトバック・フラッシュ・キャッシュ」と呼ばれます。この機能は必要に応じて有効または無効にできます。フラッシュ・キャッシュ・モードを変更する場合は、次の点に注意してください。

  • flashCacheMode属性を変更する前に、セル・サービスをシャットダウンする必要があります。セル・サービスは、ローリング形式または全体シャットダウンとしてシャットダウンできます。

  • 変更をローリング形式で行う場合は、セル・サービスの再同期が完了していることを確認してから、次のセルを変更してください。

  • フラッシュ・キャッシュ・モードをローリング形式で変更する場合は、次のセルに移る前に、現在のセルのすべてのグリッド・ディスクでasmDeactivationOutcome属性がyesに、asmModeStatus属性がonlineになっている必要があります。グリッド・ディスクの属性をチェックするには、次のコマンドを使用します。 

    LIST GRIDDISK ATTRIBUTES asmDeactivationOutcome, asmModeStatus

  • 変更を非ローリング形式で行う場合は、クラスタ全体を停止してから、変更を開始してください。

  • フラッシュ・キャッシュ・モードを非ローリング形式で変更する場合は、クラスタ全体(Oracle Clusterwareスタックとすべてのデータベースを)含むを停止してください。

  • ライトバック・フラッシュ・キャッシュを使用する場合は、Oracle Grid InfrastructureホームとOracle Databaseホームが、Oracle Database 11g リリース11.2.0.3 BP9以降になっている必要があります。

注意:

フラッシュ・キャッシュを削除し、再作成すると、キャッシュがウォームアップするまで、データベースの再起動の際にパフォーマンスに影響を与える可能性があります。

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

3.4.6.1 ローリング形式でのライトバック・フラッシュ・キャッシュの有効化

フラッシュ・キャッシュの属性をwritethroughからwritebackに変更するには、まず、そのフラッシュ・キャッシュを削除しておく必要があります。

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

注意:

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

関連項目:

My Oracle Supportノート888828.1には、Oracle Exadata System Software、Oracle Grid InfrastructureホームおよびOracle Databaseホームの最小リリース要件がまとめられています。

  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.6.2 非ローリング形式でのライトバック・フラッシュ・キャッシュの有効化

属性をwritethroughからwritebackに変更する場合は、属性を変更する前にフラッシュ・キャッシュを削除する必要があります。次の手順では、ライトバック・フラッシュ・キャッシュを非ローリング形式で有効にするステップについて説明します。

注意:

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

関連項目:

My Oracle Supportノート888828.1には、Oracle Exadata System Software、Oracle Grid InfrastructureホームおよびOracle Databaseホームの最小リリース要件がまとめられています。

  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.3 ローリング形式でのライトバック・フラッシュ・キャッシュの無効化

flashCacheMode属性をwritebackからwritethroughに変更したときに、既存のフラッシュ・キャッシュが存在していると、エラーが表示されます。属性を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"

    グリッド・ディスクが返された場合は、手順を進める前にこの問題を解決する必要があります。

  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 非ローリング形式でのライトバック・フラッシュ・キャッシュの無効化

flashCacheMode属性をwritebackからwritethroughに変更したときに、既存のフラッシュ・キャッシュが存在していると、エラーが表示されます。属性をwritethroughに変更する前に、フラッシュ・キャッシュをフラッシュして削除する必要があります。フラッシュ操作が開始されると、フラッシュ・キャッシュへのすべてのキャッシュが停止されます。次の手順では、ライトバック・フラッシュ・キャッシュを非ローリング形式で無効にするステップについて説明します。

注意:

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

  • フラッシュ・キャッシュのフラッシュ操作は、クラスタ全体を停止する前に実行できます。

  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 $GI_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 $GI_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スマート・フラッシュ・キャッシュの使用状況は次の方法で監視します。

  • ExaWatcherのレポート

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

  • AWRレポート(Exadata統計のセクション)。
    • 「パフォーマンス・サマリー」では、フラッシュ・キャッシュに関連する様々な統計とその効果を確認できます。
    • Exadataスマート統計には、Exadataスマート・フラッシュ・キャッシュの統計に関する複数のレポートが含まれているフラッシュ・キャッシュについてのセクションがあります。
  • 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デバイスに障害が発生した場合、データは自動的にリカバリされます。

PMEMデバイスに障害が発生すると、Oracle Exadata System Softwareは、残存ミラーからデータを読み取ってPMEMキャッシュ内のデータを確認します。障害が発生したPMEMキャッシュ内での損失データの場所が、Oracle Exadata System SoftwareによってPMEMの障害発生時に保存されます。

PMEMキャッシュがライトバック・モードの場合は、損失データをミラー・コピーで置き換えることでミラー復元が開始されます。復元中、グリッド・ディスクのステータスはACTIVE -- RESILVERING WORKINGになります。PMEMキャッシュがライトスルー・モードになっている場合、障害が発生したPMEMデバイスのデータはデータ・グリッド・ディスクにすでに存在しているため、ミラー復元の必要はありません。

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

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

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

Oracle Exadata Storage ServerモデルX8以降に装備した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スロット番号が表示されます。

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

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

  1. 障害が発生したPMEMデバイスを装備しているストレージ・サーバーの電源をオフにして、サーバーの電源コードを取り外します。
  2. アラート・メッセージに示されたソケット番号とDIMMスロット番号に基づいて、障害が発生したPMEMデバイスを交換します。白色のロケータLEDが点灯し、影響を受けているストレージ・サーバーを特定できます。サーバーを特定したら、障害検知ボタンを使用して障害が発生したDIMMを調べて、障害が発生したDIMMを取り外して交換します。

    注意:

    サービス不可LEDが点灯しているときには、障害が発生しているDCPMM DIMMを取り外さないでください。取り外すとサーバーのパフォーマンスに悪影響を与える可能性があります。

    DIMMの交換手順は、Oracle Exadata Storage Server X8-2 EF、HCおよびXTサービス・マニュアル(https://docs.oracle.com/cd/E93361_01/html/E93395/index.html)を参照してください。

  3. ストレージ・サーバーを再起動します。

    注意:

    再起動時に、ストレージ・サーバーは新しいPMEMデバイスの初期化を完了するために再度シャットダウンします。
  4. 交換したPMEMデバイスがグリッド・ディスクのキャッシュに使用されていることを確認します。
    次のコマンドを使用できます。このコマンドにより、使用中のフラッシュ・ディスク(FD)とPMEMデバイス(PM)が表示されます。
    CellCLI> LIST GRIDDISK ATTRIBUTES name, cachingPolicy, cachedBy
      DATA_CD_00_cel01     default     FD_00_cel01, PM_00_cel01
      DATA_CD_01_cel01     default     FD_01_cel01, PM_01_cel01
      DATA_CD_02_cel01     default     FD_02_cel01, PM_02_cel01
      DATA_CD_03_cel01     default     FD_03_cel01, PM_03_cel01
      DATA_CD_04_cel01     default     FD_00_cel01, PM_04_cel01
      ...

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

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

3.5.2 PMEMデバイスの低下したパフォーマンス・ステータスについて

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

PMEMデバイスは、モジュールが次のステータスになっているために交換が必要になることがあります。

  • 警告 - 予測障害

PMEMデバイスのステータスがpredictive failure (予測障害)のときに、アラートが生成されます。このアラートには、PMEMデバイスの交換に関する特定の手順が含まれています。システムのアラート通知を構成している場合、電子メール・メッセージでアラートが指定したアドレスに送信されます。

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

1台の不良PMEMデバイスのためにディスクがpredictive failure (予測障害)になっているときには、データがコピーされます。PMEMデバイスがライトバックPMEMキャッシュに使用されている場合、データはPMEMデバイスからフラッシュ・キャッシュにフラッシュされます。

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

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

         name:               PMEM_0_1
         diskType:           PMEM
         luns:               P0_D1
         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: 1"
         status:             warning - predictive failure

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

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

PMEMデバイスは、サーバーの電源をオフにして、サーバーの電源装置から電源コードを取り外してから交換してください。

PMEMデバイスが安全に交換できるようになると、アラートが送信されます。PMEMデバイスがライトバックPMEMキャッシュに使用されている場合は、そのPMEMデバイスでキャッシュされているグリッド・ディスクがなくなるまで待機します。すべてのグリッド・ディスクのcachedBy属性をチェックするには、次のコマンドを使用します。そのPMEMデバイスは、どのグリッド・ディスクのcachedBy属性にも表示されなくなっている必要があります。たとえば、PMEMデバイスのPM_06を交換すると、次のような出力が表示されます。 

CellCLI> LIST GRIDDISK ATTRIBUTES name, cachingPolicy, cachedBy
    DATA_CD_00_cel01     default         FD_00_cel01, PM_00_cel01
    DATA_CD_01_cel01     default         FD_01_cel01, PM_01_cel01
    DATA_CD_02_cel01     default         FD_02_cel01, PM_02_cel01
    DATA_CD_03_cel01     default         FD_03_cel01, PM_03_cel01
    DATA_CD_04_cel01     default         FD_00_cel01, PM_04_cel01
    DATA_CD_05_cel01     default         FD_01_cel01, PM_05_cel01
    DATA_CD_06_cel01     default         FD_02_cel01
    DATA_CD_07_cel01     default         FD_03_cel01, PM_07_cel01
    DATA_CD_08_cel01     default         FD_00_cel01, PM_08_cel01
    DATA_CD_09_cel01     default         FD_01_cel01, PM_09_cel01
    DATA_CD_10_cel01     default         FD_02_cel01, PM_10_cel01
    DATA_CD_11_cel01     default         FD_03_cel01, PM_11_cel01
  1. 障害が発生したPMEMデバイスが含まれているストレージ・サーバーを特定します。
    白色のロケータLEDが点灯し、影響を受けているストレージ・サーバーを特定できます。サーバーを特定したら、障害検知ボタンを使用して障害が発生したDIMMを調べます。

    注意:

    サービス不可LEDインジケータが点灯しているときに、障害が発生したDCPMM DIMMを取り外さないでください。
    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
  2. 障害が発生したPMEMデバイスを装備しているストレージ・サーバーの電源をオフにして、サーバーの電源コードを取り外します。
  3. アラート・メッセージまたはLIST DISKMAPの出力に示されたソケット番号とDIMMスロット番号に基づいて、障害が発生したPMEMデバイスを交換します。

    DIMMの交換手順は、Oracle Exadata Storage Server X8-2 EF、HCおよびXTサービス・マニュアル(https://docs.oracle.com/cd/E93361_01/html/E93395/index.html)を参照してください。

  4. ストレージ・サーバーを再起動します。

    注意:

    再起動時に、ストレージ・サーバーは新しいPMEMデバイスの初期化を完了するために再度シャットダウンします。
  5. 新しいPMEMデバイスがPMEMキャッシュに使用されていることを確認します。
    CellCLI> LIST GRIDDISK ATTRIBUTES name, cachingPolicy, cachedBy

新しいPMEMデバイスがシステムによって自動的に使用されています。PMEMキャッシュの有効サイズが増加します。

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

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

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

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

注意:

PMEMキャッシュを削除して再作成すると、データベース操作のパフォーマンスに影響します。PMEMキャッシュの再移入中には、データベースのパフォーマンスに影響するキャッシュ・ミスが増加します。
  • ライトバックPMEMキャッシュの有効化
    Oracle Exadata System Softwareリリース19.3以降、PMEMキャッシュでは、リモート・データ・メモリー・アクセス(RDMA)を使用して頻繁にアクセスするデータを透過的にキャッシュできるようになり、問合せの応答時間とスループットが向上します。
  • ライトバックPMEMキャッシュの無効化
    ストレージ・サーバーのライトバックPMEMキャッシュを無効化する必要がある場合は、次のステップを使用します。

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

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

Oracle Exadata System Softwareリリース19.3以降、PMEMキャッシュでは、リモート・データ・メモリー・アクセス(RDMA)を使用して頻繁にアクセスするデータを透過的にキャッシュできるようになり、問合せの応答時間とスループットが向上します。

PMEMキャッシュは、デフォルトでライトスルー・モードで実行します。

アプリケーションのパフォーマンスへの影響を抑えるには、ワークロードが低い期間にライトバックPMEMキャッシュを有効化します。

  1. PMEMキャッシュがライトスルー・モードになっていることを確認します。
    CellCLI> LIST CELL ATTRIBUTES pmemcachemode
   WriteThrough
  2. PMEMキャッシュを変更する前に、すべての物理ディスクが正常な状態であることを検証します。

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

    # dcli –l root –g cell_group cellcli –e “list physicaldisk attributes name,status”|grep –v NORMAL
  3. PMEMキャッシュを削除します。
    # dcli –l root –g cell_group cellcli -e drop pmemcache all
  4. ストレージ・サーバーのpmemCacheMode属性をwritebackに設定します。
    # dcli –l root – g cell_group cellcli -e "alter cell pmemcachemode=writeback"
  5. PMEMキャッシュを再作成します。
    # dcli –l root –g cell_group cellcli -e create pmemcache all
  6. pmemCacheModeがwritebackに設定されていることを確認します。
    CellCLI> LIST CELL ATTRIBUTES pmemcachemode
   WriteBack
3.5.4.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 Database Machine X7以降のシステムには、システム領域を含む2つの内蔵M.2デバイスが付属しています。

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

注意:

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

親トピック: Oracle Exadataラックの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 - dropped for replacement
  2. 白色のLEDが点灯しているセルを特定します。
  3. シャーシを開き、ステップ1のスロット番号でM.2ディスクを特定します。サービスが必要な場合は、このディスクの黄色のLEDが点灯します。

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

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

      注意:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連トピック

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

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

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

  • ExaWatcherのレポート

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

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

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

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

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

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

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

注意:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連トピック

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    注意:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連トピック

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

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

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

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

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

    注意:

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

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

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

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

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

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

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

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

関連トピック

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

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

両方のシステム・ディスクで同時に障害が発生するまれな事例の場合、Oracle Exadata System Software CELLBOOT USBフラッシュ・ドライブで提供されるOracle Exadata Storage Serverレスキュー機能を使用する必要があります。

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

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

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

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

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

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

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

注意:

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

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

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

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

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

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

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

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

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

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

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

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

関連トピック

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

3.9.2 CELLBOOT USBフラッシュ・ドライブを使用したレスキューの実行

レスキュー手順の実行には、CELLBOOT USBフラッシュ・ドライブを使用できます。

  1. コンソールを使用して、Oracle Exadata Storage Serverに接続します。
  2. Oracle Exadata Storage Serverを起動します。

    次のように表示されます。

    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秒間のみです。

  3. ブート・オプションの表示リストで、最後のオプションCELL_USB_BOOT_CELLBOOT_usb_in_rescue_modeまで下にスクロールして、[Enter]を押します。
  4. レスキュー・オプションを選択して、レスキュー手順に進みます。
  5. レスキューの最初のフェーズの最後に、システムの再起動またはシェルへの移行を要求された場合は、次のステップを実行します。
    1. 選択して、シェルを入力します。システムの再起動は選択しないでください。
    2. レスキューのrootパスワードを使用してシェルにログインします。
    3. シェルからshutdown -r nowコマンドを実行します。
    4. シェルが再起動したら、Oracle Exadataスプラッシュ画面が表示される前に[F8]を押します。
      F8キーを押すと、起動デバイス選択メニューが開きます。
    5. 起動デバイスとしてRAIDコントローラを選択します。
      これにより、セルがハード・ディスクからブートされるようになります。

      注意:

      機能が制限されたレスキュー・モードのLinuxログイン・シェルを入力できる追加オプションを使用できる場合があります。Oracleサポート・サービスから提供されたパスワードを使用してrootユーザーとしてシェルにログインし、セルの追加診断および修復を手動で実行できます。詳細は、オンラインで入手できるこのリリースのリリース・ノートまたは最新のドキュメントを参照するか、Oracleサポート・サービス担当者に問い合せてください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    注意:

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

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

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

    次に、最も一般的なパラメータの例を示します。

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

関連トピック

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

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

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

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

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

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

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

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

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

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

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

注意:

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

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

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

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

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

関連トピック

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

3.10.1 セル・ノードの追加

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

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

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

    2. 適切なOracle Exadata System Softwareイメージを使用してストレージ・サーバーをイメージ化し、IPアドレスの入力を求めるプロンプトが表示されたら適切な情報を入力します。
    3. ステップ3にスキップします。
  2. ラック内の既存のストレージ・サーバーをRDMAネットワーク・ファブリック・ネットワーク内の別のクラスタに割り当てる場合は、追加するストレージ・サーバーのRDMAネットワーク・ファブリック・インタフェース(ib0とib1や、re0とre1など)に割り当てられている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 RACノードの/etc/oracle/cell/network-config/cellip.oraファイルに、前述のステップからのIPアドレスを追加します。
  4. 既存のストレージ・サーバーにOracle Auto Service Request (ASR)のアラートが設定されていた場合は、追加するストレージ・サーバー用にセルのOracle ASRアラートを構成します。
    1. いずれかの既存のストレージ・サーバーから、セルのsnmpsubscriber属性をリストします。
      cellcli -e LIST CELL ATTRIBUTES snmpsubscriber
    2. 次のコマンドをcelladminユーザーとして実行して、同じsnmpsubscriber属性値を新しいストレージ・サーバーに適用します。この際、snmpsubscriberを前のコマンドの値に置き換えてください。
      cellcli -e "ALTER CELL snmpsubscriber=snmpsubscriber"
    3. 既存のストレージ・サーバーから、セルのアラートを構成するために必要なセルの属性をリストします。
      cellcli -e LIST CELL ATTRIBUTES
 notificationMethod,notificationPolicy,smtpToAddr,smtpFrom,
 smtpFromAddr,smtpServer,smtpUseSSL,smtpPort
    4. 次のコマンドをcelladminユーザーとして実行して、同じ値を新しいストレージ・サーバーに適用します。この際、プレースホルダを既存のストレージ・サーバーから検出された値に置き換えてください。
      cellcli -e "ALTER CELL
 notificationMethod='notificationMethod',
 notificationPolicy='notificationPolicy',
 smtpToAddr='smtpToAddr',
 smtpFrom='smtpFrom',
 smtpFromAddr='smtpFromAddr',
 smtpServer='smtpServer',
 smtpUseSSL=smtpUseSSL,
 smtpPort=smtpPort"
  5. 必要に応じて、追加するセルにセル・ディスクを作成します。
    1. セルにcelladminとしてログインし、セル・ディスクのリストを表示します。
      cellcli -e LIST CELLDISK
    2. セル・ディスクがメディア・タイプに存在していない場合は、セル・ディスクを作成します。
      cellcli -e CREATE CELLDISK ALL
    3. システムにPMEMデバイスがある場合は、デフォルトでPMEMログが作成されていたことを確認します。
      cellcli –e LIST PMEMLOG

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

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

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

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

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

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

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

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

        cellcli –e ALTER PMEMCACHE ALL FLUSH

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

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

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

        cellcli -e DROP PMEMCACHE ALL

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

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

        cellcli -e "ALTER CELL PMEMCacheMode=writeback_or_writethrough"

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

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

      フラッシュ・キャッシュ・モードを変更して既存のセルのフラッシュ・キャッシュ・モードに一致させるには、次の手順を実行します。

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

        cellcli –e ALTER FLASHCACHE ALL FLUSH

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

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

        cellcli -e DROP FLASHCACHE ALL

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

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

        cellcli -e "ALTER CELL flashCacheMode=writeback_or_writethrough"

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

        cellcli -e CREATE FLASHCACHE ALL
  6. 追加するセルのグリッド・ディスクを作成します。
    1. 既存のセルからの既存のグリッド・ディスクのsizeとcachingpolicy属性を問い合せます。
      CellCLI> LIST GRIDDISK ATTRIBUTES name,asmDiskGroupName,cachingpolicy,size,offset
    2. 前述のコマンドで検出された各ディスク・グループについて、クラスタに追加する新しいセルのグリッド・ディスクを作成します。

      前述のコマンドで報告されたその特定のディスク・グループの既存のグリッド・ディスクのsizeとcachingpolicy属性を一致させます。既存のセルと同様のレイアウトおよびパフォーマンス特性になるように、グリッド・ディスクはオフセットの昇順で作成する必要があります。たとえば、LIST GRIDDISKコマンドで次のような出力が返されたとします。 

      DATAC1          default         2.15625T        32M
DBFS_DG         default         33.796875G      2.695465087890625T
RECOC1          none            552.109375G     2.1562957763671875T

      グリッド・ディスクを作成するときには、DATAC1、RECOC1、DBFS_DGの順序で次のコマンドを使用して作成します。 

      cellcli -e CREATE GRIDDISK ALL HARDDISK
 PREFIX=matching_prefix_of_the_corresponding_existing_diskgroup,
 size=size_followed_by_G_or_T,
 cachingPolicy=\'value_from_command_above_for_this_disk_group\',
 comment =\"Cluster cluster_name diskgroup diskgroup_name\"

      注意:

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

    次の例では、Grid_homeは、Oracle Grid Infrastructureソフトウェアがインストールされているディレクトリを指します。 

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

    kfodコマンドでは、前述のステップ6で作成したすべてのグリッド・ディスクがリストされる必要があります。

  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 Database Machineの最新のベスト・プラクティスが実装されたことを確認します。

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

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

既存のOracle Exadata Database Machine X7以降のエイス・ラックに新しいOracle Exadata Database Machine X7以降のストレージ・サーバーを追加するには、次のステップを実行します。

  1. PMEMキャッシュとPMEMログを削除します(構成されている場合)。
    $ cellcli -e drop pmemcache all
$ cellcli -e drop pmemlog all
  2. 新しいストレージ・サーバーで、フラッシュ・キャッシュ、フラッシュ・ログおよびセル・ディスクを削除します。
    cellcli -e drop flashcache all
cellcli -e drop flashlog all
cellcli -e drop celldisk all
  3. 新しいストレージ・サーバーで、eighthrack属性を有効にします。
    cellcli -e alter cell eighthRack=true
  4. 新しいストレージ・サーバーで、セル・ディスクを作成します。
    cellcli -e create celldisk all
  5. 新しいストレージ・サーバーで、フラッシュ・ログを作成します。
    cellcli -e create flashlog all
  6. 新しいストレージ・サーバーでPMEMログを作成します(該当する場合)。
    cellcli -e create pmemlog all
  7. 既存のストレージ・サーバーで、セル属性flashcachemodeの値を取得します。
    cellcli -e list cell attributes flashcachemode

    新しいストレージ・サーバー上のflashcachemode属性はデフォルトでWriteThroughに設定されます。すべてのストレージ・サーバーでは、同じflashcachemode属性が設定されている必要があります。

    既存のストレージ・サーバーがWriteBackモードを使用している場合は、次に示すように、新しいストレージ・サーバーで属性flashcachemodeを変更する必要があります。 

    cellcli -e alter cell flashcachemode=writeback
  8. 新しいストレージ・サーバーで、フラッシュ・キャッシュを作成します。
    cellcli -e create flashcache all
  9. ストレージ・サーバーでPMEMキャッシュを使用している場合は、セル属性pmemcachemodeの値を取得します。
    cellcli -e list cell attributes pmemcachemode

    新しいストレージ・サーバーのpmemcachemode属性は、デフォルトでWriteThroughに設定されます。pmemcachemode属性は、すべてのストレージ・サーバーで同じ設定になっている必要があります。

    既存のストレージ・サーバーでWriteBackモードを使用している場合は、次に示すように、新しいストレージ・サーバーの属性pmemcachemodeを変更する必要があります。 

    cellcli -e alter cell pmemcachemode=writeback
  10. ストレージ・サーバーでPMEMキャッシュを使用する場合は、新しいストレージ・サーバーでPMEMキャッシュを作成します。
    cellcli -e create pmemcache all
  11. 既存のストレージ・サーバーで、グリッド・ディスクの構成に関する情報を取得します。
    cellcli -e list griddisk attributes name,offset,size,cachingpolicy
  12. 新しいストレージ・サーバーで、グリッド・ディスクを作成します(既存のストレージ・サーバーの構成と一致するよう一連のグリッド・ディスクごとに手順を繰り返します)。

    次のコマンドでは、斜体文字を、ステップ11で取得した対応する値に置き換えます。 

    cellcli -e CREATE GRIDDISK ALL HARDDISK PREFIX=matching_prefix_of_the_
corresponding_existing_diskgroup, size=size_followed_by_G_or_T, 
cachingPolicy=\'value_from_command_above_for_this_disk_group\', 
comment =\"Cluster cluster_name diskgroup diskgroup_name\"
  13. 新しいストレージ・サーバーで、(ステップ11で取得した情報と比較することにより)グリッド・ディスクの構成が既存のストレージ・サーバーのグリッド・ディスクの構成と同じであることを検証します。
    cellcli -e list griddisk attributes name,offset,size,cachingpolicy
  14. (X2からX8のサーバーのみ)パーティション・キー(pkey)を実装した環境の場合は、RDMAネットワーク・ファブリック・インタフェース用のpkeyを構成します。このタスクについては、「ExadataでのOVM RACクラスタ間のInfiniBandパーティションの実装」(My Oracle SupportのドキュメントID 2075398.1)のステップ6を参照してください。
  15. 新しいストレージ・サーバーでは、RDMA over InfiniBandネットワーク・ファブリックまたはRDMA over RoCEネットワーク・ファブリックの両方のポートのIPアドレスを特定します。
    cellcli -e list cell attributes name,ipaddress1,ipaddress2
  16. すべてのデータベース・サーバーの/etc/oracle/cell/network-config/cellip.oraファイルに、ステップ15のIPアドレスを追加します。

    クラスタ内の任意のデータベース・サーバー上で次のステップを実行します。

    1. cd /etc/oracle/cell/network-config
    2. cp cellip.ora cellip.ora.orig
    3. cp cellip.ora cellip.ora-bak
    4. /etc/oracle/cell/network-config/cellip.ora-bakに新しいエントリを追加します。
    5. 次のコマンドを使用して、編集後のファイルをすべてのデータベースのcellip.oraファイルにコピーします。ここで、database_nodesは、クラスタ内の各データベース・サーバーの名前が個別の行として含まれたファイルを指します。
      /usr/local/bin/dcli -g database_nodes -l root -f cellip.ora-bak -d /etc/oracle/cell/network-config/cellip.ora
  17. 任意のOracle ASMインスタンスに接続し、新しいストレージ・サーバーのグリッド・ディスクが検出可能であることを確認してください。
    SQL> set pagesize 30
SQL> set linesize 132
SQL> col path format a70
SQL> SELECT inst_id,path FROM gv$asm_disk WHERE header_status='CANDIDATE' 
  2> ORDER BY inst_id,path;

INST_ID    PATH
---------- ----------------------------------------------------------------------
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_00_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_01_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_02_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_03_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_04_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_05_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_00_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_01_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_02_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_03_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_04_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_05_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_00_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_01_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_02_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_03_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_04_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_05_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_00_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_01_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_02_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_03_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_04_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_05_celadm11
  18. Oracle ASMインスタンスの1つに接続し、新規ディスクを既存のディスク・グループに追加します。
    SQL> ALTER DISKGROUP datac1 ADD DISK ‘o/192.168.17.235;192.168.17.
236/DATAC1*’;
SQL> ALTER DISKGROUP recoc1 ADD DISK ‘o/192.168.17.235;192.168.17.
236/RECOC1*’;

    注意:

    ディスクの追加によってトリガーされたリバランス操作は、デフォルトのOracle Maximum Availability Architecture (MAA)ベスト・プラクティス電源(4になります)で実行されます。アプリケーションのサービス・レベルのパフォーマンスに問題がない場合、高速リバランスのために電源を大きくすることを検討します。
  19. 障害グループごとにディスク数のレポートを取得します。High Capacity (HC) Storage Serverでは障害グループごとに6台のディスクが予想され、Extreme Flash (EF) Storage Serverでは障害グループごとに4台のディスクが予想されます。
    SQL> SELECT d.group_number,dg.name,failgroup,mode_status,COUNT(*)
  2> FROM v$asm_disk d,v$asm_diskgroup dg
  3> WHERE d.group_number=dg.group_number
  4> AND failgroup_type='REGULAR'
  5> GROUP BY d.group_number,dg.name,failgroup,mode_status;

GROUP_NUMBER NAME                FAILGROUP            MODE_ST COUNT(*)
------------ ------------------- -------------------- ------- --------
           1 DATAC1              CELADM08             ONLINE         6
           1 DATAC1              CELADM09             ONLINE         6
           1 DATAC1              CELADM10             ONLINE         6
           1 DATAC1              CELADM11             ONLINE         6
           2 RECOC1              CELADM08             ONLINE         6
           2 RECOC1              CELADM09             ONLINE         6
           2 RECOC1              CELADM10             ONLINE         6
           2 RECOC1              CELADM11             ONLINE         6
  20. 既存のストレージ・サーバーにOracle Auto Service Request (ASR)のアラートが設定されていた場合は、追加するストレージ・サーバー用にセルのOracle ASRアラートを構成します。
    1. いずれかの既存のストレージ・サーバーから、セルのsnmpsubscriber属性をリストします。
      cellcli -e LIST CELL ATTRIBUTES snmpsubscriber
    2. 次のコマンドをcelladminユーザーとして実行して、同じsnmpsubscriber属性値を新しいストレージ・サーバーに適用します。この際、snmpsubscriberを前のコマンドの値に置き換えてください。
      cellcli -e "ALTER CELL snmpsubscriber=snmpsubscriber"
    3. 既存のストレージ・サーバーから、セルのアラートを構成するために必要なセルの属性をリストします。
      cellcli -e LIST CELL ATTRIBUTES
 notificationMethod,notificationPolicy,smtpToAddr,smtpFrom,
 smtpFromAddr,smtpServer,smtpUseSSL,smtpPort
    4. 次のコマンドをcelladminユーザーとして実行して、同じ値を新しいストレージ・サーバーに適用します。この際、プレースホルダを既存のストレージ・サーバーから検出された値に置き換えてください。
      cellcli -e "ALTER CELL
 notificationMethod='notificationMethod',
 notificationPolicy='notificationPolicy',
 smtpToAddr='smtpToAddr',
 smtpFrom='smtpFrom',
 smtpFromAddr='smtpFromAddr',
 smtpServer='smtpServer',
 smtpUseSSL=smtpUseSSL,
 smtpPort=smtpPort"

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

3.10.3 OEDACLIを使用したストレージ・セルの追加

OEDACLIには、様々な構成のエラスティック・ストレージ拡張(ベアメタル、単一のOracle VMまたは複数のOracle VMなど)を実行するためのインタフェースがあります。

OEDACLIは、ストレージ・サーバーで必要になるすべてのオブジェクトを作成して、新しいグリッド・ディスクをディスク・グループに追加します。既存のストレージ・サーバーのいずれかが、新しいストレージ・サーバーの構成のガイドとして機能します。トリガーされるリバランス操作は、複数のストレージ・サーバーを追加した場合でも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が使用されています。この名前は、目的のクラスタ名に置き換える必要があります。 

    ALTER CLUSTER ADDCELLS='celadm04,celadm05' power=4, wait=false \
WHERE clustername=q1-vm01
SAVE ACTION
MERGE ACTIONS
SAVE FILE
  5. スクリプトconfig_cell_script.cmdを実行します。

    この例のoeda_xml_fileは、最初のステップで生成したファイルです。また、config_cell_script.cmdは、前のステップで作成したスクリプトです。 

    $ oedacli -c oeda_xml_file -f config_cell_script.cmd

    このスクリプトを実行すると、フラッシュ・キャッシュ、フラッシュ・ログ、セル・ディスクおよびグリッド・ディスクが作成されます。さらに、ディスクがOracle ASMディスク・グループに追加され、ストレージ・サーバーがクラスタに追加されます。

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

3.10.4 既存のExadataストレージ・グリッドの拡張

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

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

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

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

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

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

    注意:

    Oracle Exadata Database Machine VMデプロイメントでは、すべてのOracle VMクラスタから次のサブステップを実行する必要があります。
    1. クラスタ内の任意のノードにログインします。
    2. ターゲット・ストレージ・サーバーのクラスタで使用するグリッド・ディスクのリストを問い合せます。
      Grid_home/bin/asmcmd  lsdsk --suppressheader | grep cellName_being_removed | awk -F'/' '{print $NF}'

      注意:

      削除するストレージ・サーバーのディスクが含まれているすべてのディスク・グループ内の使用可能な空き領域が、そのディスク・グループに割り当てられた記憶域の少なくとも15%であることを確認してください。
    3. 前述のコマンドで返されたOracle ASMディスクをそれぞれのディスク・グループから削除します。
      SQL> ALTER DISKGROUP diskgroup_name DROP DISKS IN FAILGROUP cellName_being_removed;
    4. このディスク削除操作により、デフォルトの電源レベルでリバランス操作が開始されます。次のコマンドを使用して、リバランスを監視します。
      SQL> SELECT * FROM gv$asm_operation;

      リバランスが完了するまで、つまり、gv$asm_operationから行が返されなくなるまで待ちます。

    5. すべてのディスク・グループが、削除するストレージ・サーバーのディスクを参照していないことを確認します。
      SQL> SELECT path, name, header_status, mode_status, mount_status, state,
 failgroup FROM v$asm_disk ORDER BY path;

      削除するストレージ・サーバーに属するすべてのディスクのheader_status列が、FORMERと表示されている必要があります。

      注意:

      Exadata Oracle VMデプロイメントでは、すべてのOracle VMクラスタから前述のサブステップを実行する必要があります。
  2. 削除するストレージ・サーバーをクリーン・アップします。

    ストレージ・サーバーにcelladminとしてログインし、次のコマンドを実行します。各グリッド・ディスクに対して次のコマンドを実行します。

    1. グリッド・ディスクを削除します。
      cellcli -e drop griddisk all prefix=prefix_of_the_grid_disk
    2. フラッシュ・キャッシュが存在していて、ストレージ・サーバーがWriteBackフラッシュ・キャッシュ・モードの場合、フラッシュ・キャッシュは削除の前にフラッシュしておく必要があります。
      cellcli -e alter flashcache all flush

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

    3. フラッシュ・キャッシュを削除します。
      cellcli -e drop flashcache all
    4. セル・ディスクを削除します。
      cellcli -e drop celldisk all

      データを安全に消去するには、DROP CELLDISKコマンドをeraseオプションを指定して実行するか、DROP CELLコマンドをeraseオプションを指定して実行します。

      DROP CELLコマンドの下の表内に消去操作の所要時間が表示されます。

  3. クラスタ内のすべてのデータベース・サーバー・ノードで、削除するストレージ・サーバーのエントリを/etc/oracle/cell/network-config/cellip.oraから削除します。
    クラスタ内の任意のデータベース・サーバー・ノードで次のステップを実行します。
    1. cellip.oraファイルのバックアップ・コピーを作成します。
      cd /etc/oracle/cell/network-config
cp cellip.ora cellip.ora.orig
cp cellip.ora cellip.ora-bak
    2. 削除するストレージ・サーバーのエントリを/etc/oracle/cell/network-config/cellip.ora-bakから削除します。
    3. dcliを使用して、更新したcellip.ora-bakファイルを別のデータベース・サーバーにコピーします。

      次のコマンドのdatabase_nodesは、クラスタ内の各データベース・サーバーの名前を格納しているファイルを表します。データベース・サーバーの名前は、それぞれファイル内の個別の行に記載します。 

      /usr/local/bin/dcli -g database_nodes -l root -f cellip.ora-bak -d 
/etc/oracle/cell/network-config/cellip.ora
  4. Oracle EXAchkの最新バージョンをダウンロードして実行し、結果の構成にOracle Exadata Database Machineの最新のベスト・プラクティスが実装されたことを確認します。

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

3.10.6 OEDACLIを使用したストレージ・サーバーの削除

OEDACLIには、様々な構成(ベアメタル、単一のOracle VMまたは複数のOracle VMなど)のストレージ・サーバーを削除するためのインタフェースがあります。

ディスク・グループからディスクを削除して、ストレージ・サーバーのオブジェクトを削除する手順は、わずかな数のコマンドで実施します。トリガーされるリバランス操作は、削除するストレージ・セルの数に関係なく1つのみです。

前提条件

  • 有効なOEDA XML構成ファイル(拡張する環境内で使用している計算ノードとストレージ・セルの完全リストを反映しているもの)。この作業の最初のステップでは、新しいOEDA XML構成ファイルを生成することで、現在の構成が確実に使用されるようにしています。
  • OEDACLIは、データベース・サーバー(ベアメタルまたはゲスト・ドメイン)およびストレージ・サーバーにネットワーク・アクセスできるマシンから実行する必要があります。
  1. 新しいOEDA XML構成ファイルを生成します。このファイルは、環境内で使用している現在のデータベース・サーバーとストレージ・サーバーの完全リストを反映しています。
    OEDAのDISCOVERコマンドを使用します。dirnameは、通常、OEDACLIのインストール・ディレクトリです。host_names_listは、検出するノードのカンマ区切りまたはスペース区切りのリストです(例: 'dbnode1,dbnode2,celadm01,celadm02')。 
    DISCOVER ES hostnames='host_names_list' location='dirname'

    Oracle VMが複数ある環境の場合は、このコマンドによりグローバルXML構成ファイルが生成されます。このファイルには、すべてのクラスタの情報とクラスタごとに1つのXML構成ファイルが含まれています。次のコマンドには、クラスタ固有の構成ファイルではなく、グローバルXML構成ファイルを使用する必要があります。

  2. OEDACLIを使用してXML構成ファイルを更新するOEDACLIスクリプトを作成します。

    この例では、WAITオプションをTRUEに設定しています。これは、各リバランス操作が順次実行されることを意味します。最後のディスク・グループのリバランスが完了すると、構成からストレージ・サーバーが削除されます。

    次のコマンドをdrop_cell_cluster.cmdという名前のファイルに保存します。この例では、2台のストレージ・サーバー(celadm04およびceladm05)を削除します。この例では、クラスタ名q1-vm01が使用されています。この名前は、目的のクラスタ名に置き換える必要があります。 

    ALTER CLUSTER DROPCELLS='celadm04,celadm05' power=4, wait=true \
WHERE clustername=q1-vm01
SAVE ACTION
MERGE ACTIONS
DEPLOY ACTIONS
SAVE FILE
  3. スクリプトdrop_cell_cluster.cmdを実行します。

    この例のoeda_xml_fileは、最初のステップで生成したファイルです。また、drop_cell_cluster.cmdは、前のステップで作成したスクリプトです。 

    $ oedacli -c oeda_xml_file -f drop_cell_cluster.cmd

    このスクリプトを実行すると、クラスタ内で構成されているすべてのOracle ASMディスク・グループからグリッド・ディスクが削除され、セルの構成が解除されます(フラッシュ・キャッシュ、フラッシュ・ログ、セル・ディスク、グリッド・ディスクなどのオブジェクトが削除されます)。

  4. ストレージ・サーバー(セル)をOEDA XML構成ファイルから削除するOEDACLIスクリプトを作成します。

    次のコマンドをdrop_cell_xml.cmdという名前のファイルに保存します。 

    DELETE NEWCELL WHERE SRCNAME='celadm04 celadm05'
SAVE ACTION FORCE
SAVE FILE
  5. スクリプトdrop_cell_xml.cmdを実行します。

    この例のoeda_xml_fileは、最初のステップで生成したファイルです。また、drop_cell_xml.cmdは、前のステップで作成したスクリプトです。 

    $ oedacli -c oeda_xml_file -f drop_cell_xml.cmd

    このスクリプトを実行すると、OEDA XML構成ファイルからストレージ・サーバーの情報が削除されます。

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